slarm64This forum is for the discussion of slarm64.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hmmm... alright. Now I am getting a different error in roughly the same spot:
Code:
MKIMAGE tpl/u-boot-tpl-rockchip.bin
CAT idbloader.img
CAT u-boot-rockchip.bin
UPD include/generated/timestamp_autogenerated.h
CC cmd/version.o
AR cmd/built-in.o
LD u-boot
OBJCOPY u-boot-nodtb.bin
./"arch/arm/mach-rockchip/make_fit_atf.py" \
arch/arm/dts/rk3328-rock64.dtb > u-boot.its
RELOC u-boot-nodtb.bin
MKIMAGE u-boot.itb
/hdd/slarm64/images_build_kit/build/source/u-boot /hdd/slarm64/images_build_kit/build/source/u-boot
Error: SPL image is too large (size 0x7800 than 0x7000)
Error: Bad parameters for image type
Usage: tools/mkimage -l image
-l ==> list image header information
tools/mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image
-A ==> set architecture to 'arch'
-O ==> set operating system to 'os'
-T ==> set image type to 'type'
-C ==> set compression type 'comp'
-a ==> set load address to 'addr' (hex)
-e ==> set entry point to 'ep' (hex)
-n ==> set image name to 'name'
-d ==> use image data from 'datafile'
-x ==> set XIP (execute in place)
tools/mkimage [-D dtc_options] [-f fit-image.its|-f auto|-F] [-b <dtb> [-b <dtb>]] [-E] [-B size] [-i <ramdisk.cpio.gz>] fit-image
<dtb> file is used with -f auto, it may occur multiple times.
-D => set all options for device tree compiler
-f => input filename for FIT source
-i => input filename for ramdisk file
-E => place data outside of the FIT structure
-B => align size in hex for FIT structure and header
Signing / verified boot options: [-k keydir] [-K dtb] [ -c <comment>] [-p addr] [-r] [-N engine]
-k => set directory containing private keys
-K => write public keys to this .dtb file
-G => use this signing key (in lieu of -k)
-c => add comment in signature node
-F => re-sign existing FIT image
-p => place external data at a static position
-r => mark keys used as 'required' in dtb
-N => openssl engine to use for signing
tools/mkimage -V ==> print version information and exit
Use '-T list' to see a list of available image types
I have tried switching between the two sources for rkbin as well as u-boot-tools in config/sources/rockchip.inc, but nothing lets me get past the u-boot compilation stage above.
FWIW, I am getting something similar when I try to build images for Quartz64 also. So, maybe something is going on with the rockchip boot sources and I just need to be more patient.
Just for your info, nothing critical. Thanks much.
Fixed, this is due to rk3328_ddr_333MHz_v1.19.bin, the size is larger than version 1.17.
first of all, thank you sndwvs for maintaining this. i'm a total n00b to SBCs. i bought one of these on a whim and am hoping to get some form of slackware ARM up and running on it. i thought this thread was the answer since it's the same chipset but i'm not having any luck so far. any tips?
first of all, thank you sndwvs for maintaining this. i'm a total n00b to SBCs. i bought one of these on a whim and am hoping to get some form of slackware ARM up and running on it. i thought this thread was the answer since it's the same chipset but i'm not having any luck so far. any tips?
the easiest way is to install a working image of any system (if there is no bootloader that can be written separately) and then just rewrite everything from the rock64 image and change the DTB name in the /boot/uEnv.txt file to rk3328-roc-cc.dtb
or try the image of the station m1, it is the closest.
I was trying to build a fresh set of kernel packages for the Rock64 (my only board left after a fire), and I ran into this error while downloading the sources:
Code:
|----------- delimiter ----------- "download" "linux-next" -----------|
HEAD is now at 6ab3eda15 Linux 6.2.2
error: pathspec 'linux-6.3.y' did not match any file(s) known to git
Seems like it's on the wrong branch now. What branch should this board be on for the next kernel, and where do I change that line? I checked in config/sources/rk3328.conf and config/sources/rockchip.inc, but the 6.3.y url must be coming from somewhere else. Any ideas?
I was trying to build a fresh set of kernel packages for the Rock64 (my only board left after a fire), and I ran into this error while downloading the sources:
Code:
|----------- delimiter ----------- "download" "linux-next" -----------|
HEAD is now at 6ab3eda15 Linux 6.2.2
error: pathspec 'linux-6.3.y' did not match any file(s) known to git
Seems like it's on the wrong branch now. What branch should this board be on for the next kernel, and where do I change that line? I checked in config/sources/rk3328.conf and config/sources/rockchip.inc, but the 6.3.y url must be coming from somewhere else. Any ideas?
thanks so much, keep up the great work!
Hi shelldweller,
It's very unfortunate that this happened to you.
So far so good thank you.
Very similar to the fact that in the images_build_kit/build/source kernel-next folder contains the old downloaded kernel, you need to delete the kernel-next folder
It's very unfortunate that this happened to you.
So far so good thank you.
Very similar to the fact that in the images_build_kit/build/source kernel-next folder contains the old downloaded kernel, you need to delete the kernel-next folder
Hi sndwvs. Perfect, that fixed the problem. I should have remembered to clean out the build directory, I've run into that before. It's been a while since I've messed around with the script though. Thanks for the tip, keep up the good work!
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
