The idea is to put the kernel image files in separate directories so that you won’t mess up everything beneath /boot. u-boot is able to follow symbolic links while loading files. Therefore I usually create a symbolic link /boot/kernel.d/default pointing to the real kernel directory, e.g. /boot/kernel.d/linux-5.3.0-rc5-gx-gfce02bef9. The u-boot variables and/or boot.scr only refer to /boot/kernel.d/default/Image etc.
I’ve just finished rebuilding all files from your repo, this time using your gx_defconfig;
it took me more than 280 minutes to do the Image and modules on the VIM1 and w/ gcc 7.4.0 !
I’ll soon try again to build the symbolic links and uboot macros according to your recommendations;
and then boot the beast on that;
but before using my own files, I’ll try to use your prebuilt ones that I did not try yet.
You should better build the kernel on a vim2 or a vim3 or make use of distcc.
What I didn’t mention before: You are free to relocate the kernel image files wherever you want, they are not restricted to be loaded from a specific path. If you don’t want to adopt this /boot/kernel.d/... thing just adjust the corresponding lines within the build script. But if you adopt it, you will get some flexibility, e.g. have installed different kernels in parallel (very useful if you want to test your freshly compiled mainline kernel while having a well known default kernel) or boot different os versions from the same media.
i usually build my distros and kernels on x86 + SSD ubuntu that are much faster that those arm boards , but i wanted to give it a “purist” try and i’ll switch back to x86 after a 1st success.
The initial idea still was to be able to choose between multiple kernel version, like we can do on x86 with grub and ukuu as both tools seem to be missing in arm linuxes in general…
I now better understand what “does not boot” means in my case, in facts, the system boots but fails to access the rootfs as seen in the xtended logs below (I believe I previously could not see it without the earlyprintk=aml-uart,0xc81004c0)
...
[ 7.154247] xor: using function: 32regs (3339.600 MB/sec)
[ 7.193139] Btrfs loaded, crc32c=crc32c-generic
Scanning for Btrfs filesystems
done.
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root file system device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/mmcblk1 does not exist. Dropping to a shell!
BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3.2) built-in shell (ash)
Enter 'help' for a list of built-in commands.
be it root=LABEL=ROOTFS
or
root=UUID=eb0ce16e…
or
root=/dev/mmcblk1
the result is always the same : I end up into busibox with the message saying
ALERT! [whatever root value as before] does not exist. Dropping to a shell!
[ 4.777729] meson-drm d0100000.vpu: bound c883a000.hdmi-tx (ops cleanup_module [meson_dw_hdmi])
[ 4.785693] [drm] Initialized meson 1.0.0 20161109 for d0100000.vpu on minor 0
[ 4.792527] [drm] Cannot find any crtc or sizes
Begin: Loading essential drivers ... done.
Begin: Running /scripts/init-premount ... done.
Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done.
Begin: Running /scripts/local-premount ... done.
Begin: Waiting for root file system ... Begin: Running /scripts/local-block ... done.
done.
Gave up waiting for root file system device. Common problems:
- Boot args (cat /proc/cmdline)
- Check rootdelay= (did the system wait long enough?)
- Missing modules (cat /proc/modules; ls /dev)
ALERT! LABEL=ROOTFS does not exist. Dropping to a shell!
BusyBox v1.27.2 (Ubuntu 1:1.27.2-2ubuntu3.2) built-in shell (ash)
Enter 'help' for a list of built-in commands.
(initramfs)
(initramfs) blkid
(initramfs) ls /dev/mmcblk*
/dev/mmcblk1rpmb /dev/mmcblk1boot1 /dev/mmcblk1boot0 /dev/mmcblk1
(initramfs)
This is the trace from your latest precombiled binaries (they also fall into busibox like mine !)
The issue is really the rootfs (which is the same emmc block 1 partition 5 as the bootfs, as per uboot…)
@numbqq, do you think kernel 5.3 is able to boot and mount rootfs partition (the one resulting from flashing fenix 0.6 bionic) from emmc ? maybe some khadas patch are still needed for that !?
we can see that this a SD/USB image according to the file name, but the question was about booting directly from emmc with a rootfs (and all the distro) on the emmc itself : i will ask again my question differently :
“how to build a kernel 5.3 which is able to start ubuntu (or other linux) from the emmc of the vim1 ?”. thank you.
@umiddelb : is there a chance to understand emmc partitionning on vim1 and how to change it to something that can help us w/ our current issues before, and using the RadixLinux forum info below, that you mentionned back in 2017 in eMMC Flash Layout ?
It seems that the only git repo containing something related to amlogic emmc (and khadas partitions in it) support by a mainline kernel is back in this 4.12.RC6 branch here : linux/drivers at 4.12-rc6 · numbqq/linux · GitHub
So let’s try to reapply the few customization needed back then and described in this old post of mine…
The partitioning scheme is mainly determined by the firmware (u-boot, etc.) you are using. Android has its own scheme and doesn’t make use of mbr or gpt tables. IMHO there is a configuration switch to make the linux kernel aware of the Android partitioning scheme.
If you don’t run Android on your SBC, you usually want to use a mbr or gpt scheme instead. On the VIM1 and VIM2 I figured out what areas are occupied by the Android firmware and created the Linux rootfs partitions with the right offsets (696320 sectors on the VIM1 and 1302528 on the VIM2). Other SBCs with mainline u-boot firmware use an offset of 2048 or 3072 sectors.
I think I zapped my EMMC before burning my current official ubuntu image on it (using the amlogic windoze burning tool and remove bootloader & erase flash options, iirc), so I do not want, need, have or use anything android on my board.
I do not know what kind of partition scheme the amlogic burning tools writes to the EMMC, but the mainline linux kernel (at least yours and chewitt’s) cannot make use of it, thus probably the rootfs not being found despite it is really in there (and vendor ubuntu is ok with it).
Yes, this offset thing you mention could be the key here; did you test anything to confirm it works ?
and i’ll switch back to x86 after a 1st success.