On 2021-12-27, Rainer Dorsch wrote: > Am Montag, 27. Dezember 2021, 18:22:43 CET schrieb Vagrant Cascadian: >> Very likely; it is not promised to remain constant even between boots >> with the same kernel, unfortunately! >> >> You really want to use root=UUID=abcde-12345... or partition labels, or >> anything that isn't going to have surprise changes... > > Hmm...I think the problem is something different. > > I inserted the SDcard in a different Linux-System and I extracted the UUID: > > root@h370:~# lsblk --fs /dev/sdc2 > NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% > MOUNTPOINT > sdc2 ext4 1.0 233113e0-67d1-409f-b2c0-57bd496213de > root@h370:~# > > > I manually loaded now the kernel in uboot (does the manual sequence look > reasonable?): ... > CuBox-i U-Boot > load mmc 0:1 0x10800000 vmlinuz-5.10.0-10-armmp > 4960768 bytes read in 380 ms (12.4 MiB/s) > CuBox-i U-Boot > load mmc 0:1 0x18000000 dtbs/5.10.0-10-armmp/imx6q-cubox- > i.dtb > 37880 bytes read in 254 ms (145.5 KiB/s) > CuBox-i U-Boot > load mmc 0:1 0x11800000 initrd.img-5.10.0-10-armmp > 24040022 bytes read in 1551 ms (14.8 MiB/s)
I would use $kernel_addr_r, $fdt_addr_r and $ramdisk_addr_r instead of
hard-coded values.
> CuBox-i U-Boot > setenv bootargs " ${bootargs} enable_wait_mode=off
> root=UUID=233113e0-67d1-409f-b2c0-57bd496213de rootfstype=ext4 ro rootwait
> console=ttymxc0,115200 console=tty1 break"
> CuBox-i U-Boot > printenv bootargs
> bootargs= enable_wait_mode=off
> root=UUID=233113e0-67d1-409f-b2c0-57bd496213de
> rootfstype=ext4 ro rootwait console=ttymxc0,115200 console=tty1 break
All you should really need are:
root=UUID=... console=ttymxc0,115200 console=tty1
> CuBox-i U-Boot > bootz 0x10800000 0x11800000: 0x18000000
You might want instead:
bootz $kernel_addr_r $ramdisk_addr_r:$filesize $fdt_addr_r
The $filesize is (or at least used to be) important, and should be set
to the size of the last file loaded with "load" or similar commands.
> Kernel image @ 0x10800000 [ 0x000000 - 0x4bb200 ]
> ## Flattened Device Tree blob at 18000000
> Booting using the fdt blob at 0x18000000
> EHCI failed to shut down host controller.
> Using Device Tree in place at 18000000, end 1800c3f7
It looks like it did not load the initramfs, possibly due to not using
$filesize above ... though I would expect an error, because the raw
initrd doesn't contain headers to detect the size, but maybe passing the
empty value after the colon silences that error?
I have several cubox-i systems all running bullseye, so it certainly is
possible! I think they're all using eSATA for both /boot and rootfs,
though I checked that one does detect /dev/mmcblk1 and relevent
partitions for the microSD.
It *might* be possible that there are some missing modules in the
initrd/initramfs to use mmcblk devices, but based on the above it looks
more likely that you're not passing the initrd/initramfs at boot.
live well,
vagrant
signature.asc
Description: PGP signature
