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
Attachment:
signature.asc
Description: PGP signature