cubox-i does not boot after upgrade to bullseye

[Rainer Dorsch]

Hi,
I upgraded a cubox-i from buster to bullseye. The upgrade went through
without any issues. But after the upgrade the system does not boot anymore.
The output of the serial console is below. The boot process hangs at
[ 3.816424] Waiting for root device /dev/mmcblk1p2...
Did the device enumeration change?
How would I find out the new device name and how would I change the boot
parameters (which apparently specifies /dev/mmcblk1p2 according to the
output below)?

I tried to get an initramfs shell to better debug, but failed:

I understood from

https://wiki.debian.org/InitramfsDebug

that I should add

break=mountroot

as kernel parameter.

Then from

https://wiki.debian.org/U-boot

I understand that I can add the kernel parameters by

=> setenv bootargs ${bootargs} break=mountroot
=> boot

u-boot passes the parameter

[ 0.000000] Kernel command line: break=mountroot console=ttymxc0,115200
enable_wait_mode=off root=/dev/mmcblk1p2 rootfstype=ext4 ro rootwait
console=ttymxc0,115200 console=tty1

but the kernel seems to ignore the parameter and ends up again in

[ 3.818950] Waiting for root device /dev/mmcblk1p2...



Even if I copy the example literally,

=> setenv bootargs ${bootargs} init=/bin/bash
=> boot

u-boot passes the parameters

init=/bin/bash console=ttymxc0,115200 enable_wait_mode=off root=/dev/mmcblk1p2
rootfstype=ext4 ro rootwait console=ttymxc0,115200 console=tty1

but the kernel seems to ignore the parameter and ends up again in

[ 3.818950] Waiting for root device /dev/mmcblk1p2...


Any hint or advise how I get a debug shell is welcome.

Thanks
Rainer

[Vagrant Cascadian]

I upgraded a cubox-i from buster to bullseye. The upgrade went through without
any issues. But after the upgrade the system does not boot anymore. The output
of the serial console is below. The boot process hangs at
[ 3.816424] Waiting for root device /dev/mmcblk1p2...
Did the device enumeration change?

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...

How would I find out the new device name and how would I change the boot
parameters (which apparently specifies /dev/mmcblk1p2 according to the output
below)?

If you can insert the microSD into another Debian machine, you can get
the UUID by looking in /dev/disk/by-uuid/ to find the matching device
or:

lsblk --fs /dev/DEVICE

It might be possible to discover from u-boot as well, but I forget off
the top of my head.


Once you have the UUID, try passing root=UUID=$uuid in bootparams
instead of root=/dev/mmcblk...


live well,
vagrant

[Rainer Dorsch]

Thanks for your quick reply Vagrant.

Post by Vagrant Cascadian

I upgraded a cubox-i from buster to bullseye. The upgrade went through
without any issues. But after the upgrade the system does not boot
anymore. The output of the serial console is below. The boot process
hangs at
[ 3.816424] Waiting for root device /dev/mmcblk1p2...
Did the device enumeration change?

Very likely; it is not promised to remain constant even between boots
with the same kernel, unfortunately!

Wow. I installed bullseye on a second cubox-i and there I get

Post by Vagrant Cascadian
You really want to use root=UUID=abcde-12345... or partition labels, or
anything that isn't going to have surprise changes...

Makes perfect sense.

Post by Vagrant Cascadian

How would I find out the new device name and how would I change the boot
parameters (which apparently specifies /dev/mmcblk1p2 according to the
output below)?

If you can insert the microSD into another Debian machine, you can get
the UUID by looking in /dev/disk/by-uuid/ to find the matching device
lsblk --fs /dev/DEVICE
It might be possible to discover from u-boot as well, but I forget off
the top of my head.

I realized that ext4ls uses dev 0 for the root filesystem
CuBox-i U-Boot > ext4ls mmc 0:2 /
<DIR> 4096 .
<DIR> 4096 ..
<DIR> 16384 lost+found
<DIR> 4096 boot
<DIR> 12288 etc
<DIR> 4096 media
<DIR> 4096 var
<DIR> 4096 usr
<DIR> 4096 bin
<DIR> 4096 lib
<DIR> 176128 tmp
<DIR> 4096 sys
<DIR> 12288 sbin
<DIR> 4096 run
<DIR> 4096 root
<DIR> 4096 proc
<DIR> 4096 home
<DIR> 4096 dev
<DIR> 4096 mnt
<DIR> 4096 srv
<DIR> 4096 opt
CuBox-i U-Boot >
also mmcroot implies dev 0
mmcroot=/dev/mmcblk0p2 rootwait rw
Waiting for root device /dev/mmcblk1p2
But figuring out the uuid should also be not problem.

Post by Vagrant Cascadian
Once you have the UUID, try passing root=UUID=$uuid in bootparams
instead of root=/dev/mmcblk...

- I do not find any reference to bootparam in udev or boot.scr
- In boot.scr I see an unconditional assignment
setenv bootargs " ${bootargs} enable_wait_mode=off root=/dev/mmcblk1p2
rootfstype=ext4 ro rootwait console=ttymxc0,115200 console=tty1"
(for reference https://paste.debian.net/1224931/ )
i.e. I see no way to overwrite root there.
Is there a way to modify boot.scr itself?

Is it safe to use the boot.scr from a second device with

***@h370:~$ diff -u /tmp/boot.cmd ~/tmp.nobackup/boot.cmd
--- /tmp/boot.cmd 2021-12-27 19:43:58.174529197 +0100
+++ /home/rd/tmp.nobackup/boot.cmd 2021-12-27 19:57:22.144927257 +0100
@@ -72,7 +72,7 @@
setenv bootargs "${bootargs} console=${console}"
fi

-setenv bootargs " ${bootargs} enable_wait_mode=off root=/dev/mmcblk1p2
rootfstype=ext4 ro rootwait console=ttymxc0,115200 console=tty1"
+setenv bootargs " ${bootargs} quiet"


if test -z "${fk_kvers}"; then
***@h370:~$

Where boot.cmd was generated by

dd if=/boot/boot.scr bs=72 skip=1 of=/tmp/boot.cmd

?

Or are there some device specific addresses encoded in the first 72 bytes?

Thanks
Rainer

[Vagrant Cascadian]

Post by 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.
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE%
MOUNTPOINT
sdc2 ext4 1.0 233113e0-67d1-409f-b2c0-57bd496213de
I manually loaded now the kernel in uboot (does the manual sequence look

...

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.

## 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

[Rainer Dorsch]

Post by Vagrant Cascadian
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.

I have on my second cubox-i also bullseye running, it works perfectly and
boots from microSD.

What I noticed though: the one which does not boot has different u-boot env
variables. The one which does not boot has seen the third distribution upgrade
now, i.e. I think I installed there initially Debian 9.

Now the boot process looks at least different, instead of waiting for the root
filesystem, it does not find anything:

[ 3.764843] AppArmor: AppArmor sha1 policy hashing enabled
[ 3.796946] vcc_3v3: supplied by v_5v0
[ 3.813579] List of all partitions:
[ 3.817141] No filesystem could mount root, tried:
[ 3.817146]
[ 3.823575] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
[ 3.831868] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.10.0-10-armmp #1
Debian 5.10.84-1
[ 3.840066] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 3.846608] Backtrace:
[ 3.849090] [<c0cf9144>] (dump_backtrace) from [<c0cf94f0>]
(show_stack+0x20/0x24)


I did the setup which you proposed:
CuBox-i U-Boot > setenv bootargs "root=UUID=233113e0-67d1-409f-
b2c0-57bd496213de console=ttymxc0,115200 console=tty1"
CuBox-i U-Boot > printenv bootargs
bootargs=root=UUID=233113e0-67d1-409f-b2c0-57bd496213de console=ttymxc0,115200
console=tty1
CuBox-i U-Boot > ext4ls mmc 0:1
<DIR> 4096 .
<DIR> 4096 ..
<DIR> 12288 lost+found
<SYM> 23 vmlinuz
209257 config-4.19.0-0.bpo.5-armmp
<SYM> 43 dtb-4.19.0-0.bpo.5-armmp
209279 config-4.19.0-17-armmp
<SYM> 23 vmlinuz.old
<SYM> 26 initrd.img.old
4960768 vmlinuz-5.10.0-10-armmp
<DIR> 1024 dtbs
4235776 vmlinuz-4.19.0-0.bpo.5-armmp
3124796 System.map-4.19.0-0.bpo.5-armmp
3145625 System.map-4.19.0-18-armmp
209332 config-4.19.0-18-armmp
<SYM> 40 dtb-5.10.0-10-armmp
35234 dtb-4.9.0-0.bpo.1-armmp.bak
83 System.map-5.10.0-10-armmp
19574146 initrd.img-4.19.0-0.bpo.5-armmp
250465 config-5.10.0-10-armmp
24040022 initrd.img-5.10.0-10-armmp
34350 dtb-4.6.0-0.bpo.1-armmp.bak
4272640 vmlinuz-4.19.0-18-armmp
29346 dtb-3.16.0-4-armmp.bak
<SYM> 40 dtb-4.19.0-17-armmp
34450 dtb-4.8.0-0.bpo.2-armmp.bak
34402 dtb-4.7.0-0.bpo.1-armmp.bak
<SYM> 26 initrd.img
<SYM> 40 dtb
3721 boot.scr
3721 boot.scr.orig
34233 dtb-4.5.0-0.bpo.2-armmp.bak
4272640 vmlinuz-4.19.0-17-armmp
35234 dtb-4.9.0-0.bpo.2-armmp.bak
3144170 System.map-4.19.0-17-armmp
22182359 initrd.img-4.19.0-17-armmp
<SYM> 40 dtb-4.19.0-18-armmp
22794613 initrd.img-4.19.0-18-armmp
CuBox-i U-Boot > load mmc 0:1 ${kernel_addr_r} vmlinuz-5.10.0-10-armmp
4960768 bytes read in 377 ms (12.5 MiB/s)
CuBox-i U-Boot > load mmc 0:1 ${fdt_addr_r} 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 ${ramdisk_addr_r} initrd.img-5.10.0-10-armmp
24040022 bytes read in 1553 ms (14.8 MiB/s)
CuBox-i U-Boot > bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} $
{fdt_addr_r}
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



In order to exclude that I got something wrong with the UUID:
Does root=/dev/mmcblk0p2 also work if ext4ls mmc 0:2 shows the rootfs?

Thanks.

Rainer

[Rainer Dorsch]

Post by Rainer Dorsch
Does root=/dev/mmcblk0p2 also work if ext4ls mmc 0:2 shows the rootfs?

At least the result is the same for /dev/mmcblk0p2:

[...]
[ 3.743918] zswap: loaded using pool lzo/zbud
[ 3.749114] Key type ._fscrypt registered
[ 3.753212] Key type .fscrypt registered
[ 3.757174] Key type fscrypt-provisioning registered
[ 3.762439] AppArmor: AppArmor sha1 policy hashing enabled
[ 3.794654] vcc_3v3: supplied by v_5v0
[ 3.811521] List of all partitions:
[ 3.815075] No filesystem could mount root, tried:
[ 3.815079]
[ 3.821507] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
[ 3.829798] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.0-10-armmp #1
Debian 5.10.84-1
[ 3.837995] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 3.844536] Backtrace:

If a module is missing, would that be different for a new installation and an
upgrade?

Thanks
Rainer

[Rainer Dorsch]

Post by Rainer Dorsch

Post by Rainer Dorsch
Does root=/dev/mmcblk0p2 also work if ext4ls mmc 0:2 shows the rootfs?

[...]
[ 3.743918] zswap: loaded using pool lzo/zbud
[ 3.749114] Key type ._fscrypt registered
[ 3.753212] Key type .fscrypt registered
[ 3.757174] Key type fscrypt-provisioning registered
[ 3.762439] AppArmor: AppArmor sha1 policy hashing enabled
[ 3.794654] vcc_3v3: supplied by v_5v0
[ 3.815079]
[ 3.821507] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
[ 3.829798] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.0-10-armmp #1
Debian 5.10.84-1
[ 3.837995] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
If a module is missing, would that be different for a new installation and
an upgrade?

I did a few more experiments, good news is that the old kernel starts the
system flawless:

mmc dev 0;
mmc rescan

setenv bootargs "root=UUID=233113e0-67d1-409f-b2c0-57bd496213de
console=ttymxc0,115200 console=tty1"

ext4ls mmc 0:1

load mmc 0:1 ${kernel_addr_r} vmlinux-4.19.0-18-armmp
load mmc 0:1 ${fdt_addr_r} dtb-4.19.0-18-armmp
load mmc 0:1 ${ramdisk_addr_r} initrd.img-4.19.0-18-armmp
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

Now I am trying to get the 5.10.0 kernel up. It failed with

[ 3.338109] registered taskstats version 1
[ 3.342254] Loading compiled-in X.509 certificates
[ 3.742380] Loaded X.509 cert 'Debian Secure Boot CA:
6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
[ 3.751231] Loaded X.509 cert 'Debian Secure Boot Signer 2021 - linux:
4b6ef5abca669825178e052c84667ccbc0531f8c'
[ 3.761594] zswap: loaded using pool lzo/zbud
[ 3.766833] Key type ._fscrypt registered
[ 3.770885] Key type .fscrypt registered
[ 3.774839] Key type fscrypt-provisioning registered
[ 3.780060] AppArmor: AppArmor sha1 policy hashing enabled
[ 3.812034] vcc_3v3: supplied by v_5v0
[ 3.828312] Waiting for root device UUID=233113e0-67d1-409f-
b2c0-57bd496213de...

That the new system runs with the old kernel is very impressive work of the
Debian/Linux Kernel team and very useful for me in this case, a big thank you
for that!

I am struggling to boot the 5.10.0 kernel manually.

I decided to start experimenting on the system with a fresh bullseye
installation (debugging one problem at a time :-)):

I defined a few environment variables to get to a more efficient testing:

=> printenv localbootcmd
localbootcmd=mmc dev 1; mmc rescan; setenv bootargs ${rootfs}
console=ttymxc0,115200 console=tty1; load mmc 1:2 ${kernel_addr_r} vmlinuz-$
{ver}; load mmc 1:2 ${fdt_addr_r} dtbs/${ver}/imx6q-cubox-i.dtb; load mmc 1:2
${ramdisk_addr_r} initrd.img-${ver}; bootz ${kernel_addr_r} $
{ramdisk_addr_r}::${filesize} ${fdt_addr_r}
=> printenv rootfs
rootfs=root=UUID=08d60447-3547-4fd3-9231-33d884e139eb
=> printenv ver
ver=5.10.0-10-armmp
=> run localbootcmd
switch to partitions #0, OK
mmc1 is current device
4960768 bytes read in 245 ms (19.3 MiB/s)
37880 bytes read in 6 ms (6 MiB/s)
23951051 bytes read in 1158 ms (19.7 MiB/s)
## Flattened Device Tree blob at 18000000
Booting using the fdt blob at 0x18000000
Loading Device Tree to 1fff3000, end 1ffff3f7 ... OK

Starting kernel ...

[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.10.0-10-armmp (debian-***@lists.debian.org)
(gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian)
2.35.2) #1 SMP Debian 5.10.84-1 (2021-12-08)
[ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7),
cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[ 0.000000] OF: fdt: Machine model: SolidRun Cubox-i Dual/Quad
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] efi: UEFI not found.
[ 0.000000] cma: Reserved 16 MiB at 0x4f000000
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000010000000-0x000000003fffffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem [mem 0x0000000040000000-0x000000004fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000010000000-0x000000004fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000010000000-0x000000004fffffff]
[ 0.000000] percpu: Embedded 21 pages/cpu s54604 r8192 d23220 u86016
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 260416
[ 0.000000] Kernel command line:
root=UUID=08d60447-3547-4fd3-9231-33d884e139eb console=ttymxc0,115200
console=tty1

[...]

[ 3.667632] Loaded X.509 cert 'Debian Secure Boot CA:
6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
[ 3.676520] Loaded X.509 cert 'Debian Secure Boot Signer 2021 - linux:
4b6ef5abca669825178e052c84667ccbc0531f8c'
[ 3.686926] zswap: loaded using pool lzo/zbud
[ 3.692099] Key type ._fscrypt registered
[ 3.696193] Key type .fscrypt registered
[ 3.700156] Key type fscrypt-provisioning registered
[ 3.705407] AppArmor: AppArmor sha1 policy hashing enabled
[ 3.740196] vcc_3v3: supplied by v_5v0
[ 3.756987] List of all partitions:
[ 3.760500] No filesystem could mount root, tried:
[ 3.760506]
[ 3.766947] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
[ 3.775239] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.10.0-10-armmp #1
Debian 5.10.84-1
[ 3.783436] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 3.789977] Backtrace:
[ 3.792460] [<c0cf9144>] (dump_backtrace) from [<c0cf94f0>]
(show_stack+0x20/0x24)
[ 3.800053] r7:c19e9000 r6:60000093 r5:00000000 r4:c14cdd2c
[ 3.805737] [<c0cf94d0>] (show_stack) from [<c0cfe6ac>]
(dump_stack+0xc8/0xdc)
[ 3.812984] [<c0cfe5e4>] (dump_stack) from [<c0cfa000>] (panic+0x11c/0x340)
[ 3.819963] r7:c19e9000 r6:c0fb85d8 r5:00000000 r4:c15a5920
[ 3.825650] [<c0cf9ee4>] (panic) from [<c1201a00>]
(mount_block_root+0x368/0x374)
[ 3.833155] r3:00000000 r2:00000000 r1:c197fec4 r0:c0fb85d8
[ 3.838827] r7:c19e9000
[ 3.841380] [<c1201698>] (mount_block_root) from [<c1201a90>]
(mount_root+0x84/0x88)
[ 3.849146] r10:c111c4d8 r9:c129a858 r8:c15a2000 r7:c129a838 r6:00000008
r5:c129a868
[ 3.856993] r4:00000000
[ 3.859547] [<c1201a0c>] (mount_root) from [<c1201bf4>]
(prepare_namespace+0x160/0x19c)
[ 3.867569] r5:c129a868 r4:c15a2028
[ 3.871167] [<c1201a94>] (prepare_namespace) from [<c1201468>]
(kernel_init_freeable+0x2bc/0x2d4)
[ 3.880056] r5:c192f100 r4:c1409a90
[ 3.883659] [<c12011ac>] (kernel_init_freeable) from [<c0d086e4>]
(kernel_init+0x18/0x130)
[ 3.891945] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000
r5:c0d086cc
[ 3.899791] r4:00000000
[ 3.902345] [<c0d086cc>] (kernel_init) from [<c03001a8>]
(ret_from_fork+0x14/0x2c)
[ 3.909933] Exception stack(0xc197ffb0 to 0xc197fff8)
[ 3.914999] ffa0: 00000000 00000000
00000000 00000000
[ 3.923198] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
[ 3.931396] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 3.938026] r5:c0d086cc r4:00000000

[...]

When I boot the system with the standard "run boodcmd", I can confirm that the
UUID is correct:

***@bc-text:~$ mount|grep mmc
/dev/mmcblk1p3 on / type ext4 (rw,relatime,errors=remount-ro)
/dev/mmcblk1p2 on /boot type ext2 (rw,relatime)
***@bc-text:~$ ls -l /dev/disk/by-uuid/|grep p3
lrwxrwxrwx 1 root root 15 Jul 13 19:29 08d60447-3547-4fd3-9231-33d884e139eb ->
../../mmcblk1p3
***@bc-text:~$

I echoed the parameters which run bootcmd uses in /etc/flash-kernel/bootscript/
bootscr.uboot-generic:

echo bootargs: ${bootargs}
echo "load ${devtype} ${devnum}:${partition} ${kernel_addr_r} ${pathprefix}
vmlinuz-${fk_kvers} \
&& load ${devtype} ${devnum}:${partition} ${fdt_addr_r} ${pathprefix}$
{fdtpath} \
&& load ${devtype} ${devnum}:${partition} ${ramdisk_addr_r} ${pathprefix}
initrd.img-${fk_kvers} \
&& echo Booting Debian ${fk_kvers} from ${devtype} ${devnum}:$
{partition}... \
&& bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}"

and get

## Executing script at 12000000
bootargs: root=UUID=08d60447-3547-4fd3-9231-33d884e139eb
console=ttymxc0,115200 console=tty1 console=ttymxc0,115200 quiet
load mmc 1:2 0x12000000 /vmlinuz-5.10.0-10-armmp && load mmc 1:2
0x18000000 /dtbs/5.10.0-10-armmp/imx6q-cubox-i.dtb && load mmc 1:2
0x13000000 /initrd.img-5.10.0-10-armmp && echo Booting Debian 5.10.0-10-
armmp from mmc 1:2... && bootz 0x12000000 0x13000000:1198 0x18000000

I use these directly, I run in a different issue:

=> setenv bootargs "root=UUID=08d60447-3547-4fd3-9231-33d884e139eb
console=ttymxc0,115200 console=tty1 console=ttymxc0,115200"
=> load mmc 1:2 0x12000000 /vmlinuz-5.10.0-10-armmp && load mmc 1:2
0x18000000 /dtbs/5.10.0-10-armmp/imx6q-cubox-i.dtb && load mmc 1:2
0x13000000 /initrd.img-5.10.0-10-armmp && echo Booting Debian 5.10.0-10-
armmp from mmc 1:2... && bootz 0x12000000 0x13000000:1198 0x18000000
4960768 bytes read in 244 ms (19.4 MiB/s)
37880 bytes read in 6 ms (6 MiB/s)
23951051 bytes read in 1155 ms (19.8 MiB/s)
Booting Debian 5.10.0-10-armmp from mmc 1:2...
## Flattened Device Tree blob at 18000000
Booting using the fdt blob at 0x18000000
Loading Device Tree to 1fff3000, end 1ffff3f7 ... OK

Starting kernel ...

[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.10.0-10-armmp (debian-***@lists.debian.org)
(gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian)
2.35.2) #1 SMP Debian 5.10.84-1 (2021-12-08)
[ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7),
cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[ 0.000000] OF: fdt: Machine model: SolidRun Cubox-i Dual/Quad
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] efi: UEFI not found.
[ 0.000000] cma: Reserved 16 MiB at 0x4f000000
[ 0.000000] Zone ranges:
[ 0.000000] DMA [mem 0x0000000010000000-0x000000003fffffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem [mem 0x0000000040000000-0x000000004fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000010000000-0x000000004fffffff]
[ 0.000000] Initmem setup node 0 [mem 0x0000000010000000-0x000000004fffffff]
[ 0.000000] percpu: Embedded 21 pages/cpu s54604 r8192 d23220 u86016
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 260416
[ 0.000000] Kernel command line:
root=UUID=08d60447-3547-4fd3-9231-33d884e139eb console=ttymxc0,115200
console=tty1 console=ttymxc0,115200
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288
bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes,
linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:on, heap free:off
[ 0.000000] Memory: 1002428K/1048576K available (11264K kernel code, 1668K
rwdata, 3192K rodata, 2048K init, 337K bss, 29764K reserved, 16384K cma-
reserved, 245760K highmem)
[ 0.000000] random: get_random_u32 called from
__kmem_cache_create+0x30/0x450 with crng_init=0
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[ 0.000000] ftrace: allocating 37402 entries in 110 pages
[ 0.000000] ftrace: allocated 110 pages with 5 groups
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
[ 0.000000] Rude variant of Tasks RCU enabled.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25
jiffies.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] L2C-310 errata 752271 769419 enabled
[ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
[ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[ 0.000000] L2C-310 ID prefetch enabled, offset 16 lines
[ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[ 0.000000] L2C-310 cache controller enabled, 16 ways, 1024 kB
[ 0.000000] L2C-310: CACHE_ID 0x410000c7, AUX_CTRL 0x76470001
[ 0.000000] Switching to timer-based delay loop, resolution 333ns
[ 0.000007] sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps every
715827882841ns
[ 0.000028] clocksource: mxc_timer1: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 637086815595 ns
[ 0.003000] Console: colour dummy device 80x30
[ 0.003590] printk: console [tty1] enabled
[ 0.003651] Calibrating delay loop (skipped), value calculated using timer
frequency.. 6.00 BogoMIPS (lpj=12000)
[ 0.003689] pid_max: default: 32768 minimum: 301
[ 0.004055] LSM: Security Framework initializing
[ 0.004174] Yama: disabled by default; enable with sysctl kernel.yama.*
[ 0.004473] AppArmor: AppArmor initialized
[ 0.004505] TOMOYO Linux initialized
[ 0.004628] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes,
linear)
[ 0.004669] Mountpoint-cache hash table entries: 2048 (order: 1, 8192
bytes, linear)
[ 0.005992] CPU: Testing write buffer coherency: ok
[ 0.006062] CPU0: Spectre v2: using BPIALL workaround
[ 0.006493] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.007717] Setting up static identity map for 0x10300000 - 0x103000ac
[ 0.009109] rcu: Hierarchical SRCU implementation.
[ 0.011803] EFI services will not be available.
[ 0.012286] smp: Bringing up secondary CPUs ...
[ 0.013447] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.013457] CPU1: Spectre v2: using BPIALL workaround
[ 0.013675] smp: Brought up 1 node, 2 CPUs
[ 0.013703] SMP: Total of 2 processors activated (12.00 BogoMIPS).
[ 0.013724] CPU: All CPU(s) started in SVC mode.
[ 0.014588] devtmpfs: initialized
[ 0.025168] VFP support v0.3: implementor 41 architecture 3 part 30 variant
9 rev 4
[ 0.025543] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff,
max_idle_ns: 7645041785100000 ns
[ 0.025652] futex hash table entries: 512 (order: 3, 32768 bytes, linear)
[ 0.026900] pinctrl core: initialized pinctrl subsystem
[ 0.028313] DMI not present or invalid.
[ 0.028767] NET: Registered protocol family 16
[ 0.032516] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.033521] audit: initializing netlink subsys (disabled)
[ 0.035250] thermal_sys: Registered thermal governor 'fair_share'
[ 0.035259] thermal_sys: Registered thermal governor 'bang_bang'
[ 0.035285] thermal_sys: Registered thermal governor 'step_wise'
[ 0.035307] thermal_sys: Registered thermal governor 'user_space'
[ 0.035328] thermal_sys: Registered thermal governor 'power_allocator'
[ 0.035639] CPU identified as i.MX6Q, silicon rev 1.2
[ 0.037487] audit: type=2000 audit(0.032:1): state=initialized
audit_enabled=0 res=1
[ 0.473662] No ATAGs?
[ 0.473818] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1
watchpoint registers.
[ 0.473849] hw-breakpoint: maximum watchpoint size is 4 bytes.
[ 0.475628] debugfs: Directory 'dummy-iomuxc-***@20e0000' with parent
'regmap' already present!
[ 0.476014] imx6q-pinctrl 20e0000.pinctrl: initialized IMX pinctrl driver
[ 0.477798] Serial: AMBA PL011 UART driver
[ 0.485859] Kprobes globally optimized
[ 2.203038] mxs-dma 110000.dma-apbh: initialized
[ 2.204779] reg-fixed-voltage regulator-vcc-3v3: Failed to register
regulator: -517
[ 2.207660] iommu: Default domain type: Translated
[ 2.208875] vgaarb: loaded
[ 2.210045] mc: Linux media interface: v0.10
[ 2.210106] videodev: Linux video capture interface: v2.00
[ 2.212076] NetLabel: Initializing
[ 2.212103] NetLabel: domain hash size = 128
[ 2.212121] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO
[ 2.212232] NetLabel: unlabeled traffic allowed by default
[ 2.212631] clocksource: Switched to clocksource mxc_timer1
[ 2.304880] VFS: Disk quotas dquot_6.6.0
[ 2.305052] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 2.305979] AppArmor: AppArmor Filesystem Enabled
[ 2.319926] NET: Registered protocol family 2
[ 2.320351] IP idents hash table entries: 16384 (order: 5, 131072 bytes,
linear)
[ 2.322134] tcp_listen_portaddr_hash hash table entries: 512 (order: 0,
6144 bytes, linear)
[ 2.322267] TCP established hash table entries: 8192 (order: 3, 32768
bytes, linear)
[ 2.322509] TCP bind hash table entries: 8192 (order: 4, 65536 bytes,
linear)
[ 2.322657] TCP: Hash tables configured (established 8192 bind 8192)
[ 2.322981] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 2.323073] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes,
linear)
[ 2.323902] NET: Registered protocol family 1
[ 2.323975] NET: Registered protocol family 44
[ 2.324012] PCI: CLS 0 bytes, default 64
[ 2.324926] Trying to unpack rootfs image as initramfs...
[ 2.327535] Initramfs unpacking failed: read error
[ 2.327582] Freeing initrd memory: 8K
[ 2.327952] hw perfevents: no interrupt-affinity property for /pmu, guessing.
[ 2.328222] hw perfevents: enabled with armv7_cortex_a9 PMU driver, 7
counters available
[ 2.331042] Initialise system trusted keyrings
[ 2.331119] Key type blacklist registered
[ 2.331409] workingset: timestamp_bits=14 max_order=18 bucket_order=4
[ 2.339404] zbud: loaded
[ 2.340779] integrity: Platform Keyring initialized
[ 2.340818] Key type asymmetric registered
[ 2.340838] Asymmetric key parser 'x509' registered
[ 2.341448] bounce: pool size: 64 pages
[ 2.341630] Block layer SCSI generic (bsg) driver version 0.4 loaded (major
250)
[ 2.341979] io scheduler mq-deadline registered
[ 2.362169] imx-sdma 20ec000.sdma: firmware: failed to load imx/sdma/sdma-
imx6q.bin (-2)
[ 2.362211] firmware_class: See https://wiki.debian.org/Firmware for
information about missing firmware
[ 2.362242] imx-sdma 20ec000.sdma: Direct firmware load for imx/sdma/sdma-
imx6q.bin failed with error -2
[ 2.369818] Serial: 8250/16550 driver, 5 ports, IRQ sharing enabled
[ 2.373383] Serial: AMBA driver
[ 2.374251] 2020000.serial: ttymxc0 at MMIO 0x2020000 (irq = 33, base_baud
= 5000000) is a IMX
[ 3.174669] printk: console [ttymxc0] enabled
[ 3.180755] 21f0000.serial: ttymxc3 at MMIO 0x21f0000 (irq = 73, base_baud
= 5000000) is a IMX
[ 3.191893] STM32 USART driver initialized
[ 3.199418] libphy: Fixed MDIO Bus: probed
[ 3.205411] mousedev: PS/2 mouse device common for all mice
[ 3.214187] snvs_rtc 20cc000.snvs:snvs-rtc-lp: registered as rtc0
[ 3.220367] snvs_rtc 20cc000.snvs:snvs-rtc-lp: setting system clock to
2021-12-28T12:41:55 UTC (1640695315)
[ 3.235562] ledtrig-cpu: registered to indicate activity on CPUs
[ 3.243723] NET: Registered protocol family 10
[ 3.256936] Segment Routing with IPv6
[ 3.260798] mip6: Mobile IPv6
[ 3.263786] NET: Registered protocol family 17
[ 3.268483] mpls_gso: MPLS GSO support
[ 3.272846] ThumbEE CPU extension supported.
[ 3.277200] Registering SWP/SWPB emulation handler
[ 3.282227] registered taskstats version 1
[ 3.286421] Loading compiled-in X.509 certificates
[ 3.686339] Loaded X.509 cert 'Debian Secure Boot CA:
6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
[ 3.695206] Loaded X.509 cert 'Debian Secure Boot Signer 2021 - linux:
4b6ef5abca669825178e052c84667ccbc0531f8c'
[ 3.705623] zswap: loaded using pool lzo/zbud
[ 3.710787] Key type ._fscrypt registered
[ 3.714870] Key type .fscrypt registered
[ 3.718832] Key type fscrypt-provisioning registered
[ 3.724055] AppArmor: AppArmor sha1 policy hashing enabled
[ 3.758655] vcc_3v3: supplied by v_5v0
[ 3.787824] Freeing unused kernel memory: 2048K
[ 3.805347] ------------[ cut here ]------------
[ 3.810055] WARNING: CPU: 1 PID: 1 at arch/arm/mm/dump.c:248
note_page+0x3d0/0x3dc
[ 3.817688] arm/mm: Found insecure W+X mapping at address 0xf0879000
[ 3.824078] Modules linked in:
[ 3.827180] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.10.0-10-armmp #1
Debian 5.10.84-1
[ 3.835378] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 3.841920] Backtrace:
[ 3.844399] [<c0cf9144>] (dump_backtrace) from [<c0cf94f0>]
(show_stack+0x20/0x24)
[ 3.851994] r7:000000f8 r6:60000013 r5:00000000 r4:c14cdd2c
[ 3.857677] [<c0cf94d0>] (show_stack) from [<c0cfe6ac>]
(dump_stack+0xc8/0xdc)
[ 3.864932] [<c0cfe5e4>] (dump_stack) from [<c034d880>] (__warn+0xfc/0x158)
[ 3.871913] r7:000000f8 r6:00000009 r5:c031f740 r4:c0fbcd10
[ 3.877595] [<c034d784>] (__warn) from [<c0cfa2c8>]
(warn_slowpath_fmt+0xa4/0xe4)
[ 3.885098] r7:c031f740 r6:000000f8 r5:c0fbcd10 r4:c0fbccdc
[ 3.890778] [<c0cfa228>] (warn_slowpath_fmt) from [<c031f740>]
(note_page+0x3d0/0x3dc)
[ 3.898716] r8:00000000 r7:00000000 r6:00000005 r5:c140c4a0 r4:c197ff28
[ 3.905439] [<c031f370>] (note_page) from [<c031f834>]
(walk_pmd+0xe8/0x1a4)
[ 3.912507] r10:c197ff28 r9:c0207c20 r8:c1900800 r7:00000000 r6:c0fbcd58
r5:f087b000
[ 3.920354] r4:c19001ec
[ 3.922904] [<c031f74c>] (walk_pmd) from [<c031fa34>]
(ptdump_check_wx+0x88/0x104)
[ 3.930496] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:c0208000
r5:f0800000
[ 3.938342] r4:c0207c28
[ 3.940899] [<c031f9ac>] (ptdump_check_wx) from [<c0319938>]
(mark_rodata_ro+0x3c/0x40)
[ 3.948924] r6:00000000 r5:c0d086cc r4:00000000
[ 3.953567] [<c03198fc>] (mark_rodata_ro) from [<c0d08710>]
(kernel_init+0x44/0x130)
[ 3.961338] [<c0d086cc>] (kernel_init) from [<c03001a8>]
(ret_from_fork+0x14/0x2c)
[ 3.968926] Exception stack(0xc197ffb0 to 0xc197fff8)
[ 3.973994] ffa0: 00000000 00000000
00000000 00000000
[ 3.982196] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
[ 3.990393] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 3.997021] r5:c0d086cc r4:00000000
[ 4.000640] ---[ end trace 64b0299d9e194c40 ]---
[ 4.005524] Checked W+X mappings: FAILED, 1 W+X pages found
[ 4.011206] Run /init as init process
[ 4.015593] Failed to execute /init (error -2)
[ 4.020113] Run /sbin/init as init process
[ 4.024490] Run /etc/init as init process
[ 4.028764] Run /bin/init as init process
[ 4.033002] Run /bin/sh as init process
[ 4.037080] Kernel panic - not syncing: No working init found. Try passing
init= option to kernel. See Linux Documentation/admin-guide/init.rst for
guidance.
[ 4.051288] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W
5.10.0-10-armmp #1 Debian 5.10.84-1
[ 4.060874] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 4.067414] Backtrace:
[ 4.069892] [<c0cf9144>] (dump_backtrace) from [<c0cf94f0>]
(show_stack+0x20/0x24)
[ 4.077486] r7:00000000 r6:60000093 r5:00000000 r4:c14cdd2c
[ 4.083168] [<c0cf94d0>] (show_stack) from [<c0cfe6ac>]
(dump_stack+0xc8/0xdc)
[ 4.090415] [<c0cfe5e4>] (dump_stack) from [<c0cfa000>] (panic+0x11c/0x340)
[ 4.097395] r7:00000000 r6:c0fb8318 r5:00000000 r4:c15a5920
[ 4.103081] [<c0cf9ee4>] (panic) from [<c0d087f4>]
(kernel_init+0x128/0x130)
[ 4.110146] r3:00000000 r2:00000000 r1:ef6c4524 r0:c0fb8318
[ 4.115817] r7:00000000
[ 4.118370] [<c0d086cc>] (kernel_init) from [<c03001a8>]
(ret_from_fork+0x14/0x2c)
[ 4.125956] Exception stack(0xc197ffb0 to 0xc197fff8)
[ 4.131023] ffa0: 00000000 00000000
00000000 00000000
[ 4.139221] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
[ 4.147418] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 4.154047] r5:c0d086cc r4:00000000
[ 4.157649] CPU1: stopping
[ 4.160380] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G W
5.10.0-10-armmp #1 Debian 5.10.84-1
[ 4.169965] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 4.176505] Backtrace:
[ 4.178976] [<c0cf9144>] (dump_backtrace) from [<c0cf94f0>]
(show_stack+0x20/0x24)
[ 4.186568] r7:00000001 r6:60000193 r5:00000000 r4:c14cdd2c
[ 4.192249] [<c0cf94d0>] (show_stack) from [<c0cfe6ac>]
(dump_stack+0xc8/0xdc)
[ 4.199503] [<c0cfe5e4>] (dump_stack) from [<c0312030>]
(do_handle_IPI+0x320/0x358)
[ 4.207181] r7:00000001 r6:2e39d000 r5:00000001 r4:c15a2d58
[ 4.212860] [<c0311d10>] (do_handle_IPI) from [<c0312090>]
(ipi_handler+0x28/0x30)
[ 4.220451] r9:c19b6000 r8:c1907000 r7:00000001 r6:2e39d000 r5:c1901380
r4:00000014
[ 4.228224] [<c0312068>] (ipi_handler) from [<c03ce194>]
(handle_percpu_devid_fasteoi_ipi+0x80/0x154)
[ 4.237474] [<c03ce114>] (handle_percpu_devid_fasteoi_ipi) from
[<c03c7454>] (__handle_domain_irq+0x8c/0xe0)
[ 4.247324] r7:00000001 r6:00000000 r5:00000000 r4:c13372c0
[ 4.253005] [<c03c73c8>] (__handle_domain_irq) from [<c030175c>]
(gic_handle_irq+0x80/0xac)
[ 4.261379] r9:c19b6000 r8:f400010c r7:c13372cc r6:f4000100 r5:c19b7f38
r4:c14068a0
[ 4.269146] [<c03016dc>] (gic_handle_irq) from [<c0300b8c>]
(__irq_svc+0x6c/0x90)
[ 4.276645] Exception stack(0xc19b7f38 to 0xc19b7f80)
[ 4.281710] 7f20:
00000000 00002fa0
[ 4.289911] 7f40: ef6d61c4 c0321cc0 c19b6000 00000001 c1405e9c c1405ee4
c1581f43 c0fcc220
[ 4.298111] 7f60: 00000000 c19b7f94 c19b7f98 c19b7f88 c030a5f0 c030a5f4
60000013 ffffffff
[ 4.306310] r9:c19b6000 r8:c1581f43 r7:c19b7f6c r6:ffffffff r5:60000013
r4:c030a5f4
[ 4.314081] [<c030a5ac>] (arch_cpu_idle) from [<c0d0fd6c>]
(default_idle_call+0x38/0x108)
[ 4.322289] [<c0d0fd34>] (default_idle_call) from [<c038a3f8>]
(do_idle+0xdc/0x148)
[ 4.329972] [<c038a31c>] (do_idle) from [<c038a744>]
(cpu_startup_entry+0x28/0x2c)
[ 4.337563] r9:412fc09a r8:1020406a r7:c15a2d68 r6:10c0387d r5:00000001
r4:00000092
[ 4.345333] [<c038a71c>] (cpu_startup_entry) from [<c031262c>]
(secondary_start_kernel+0x160/0x188)
[ 4.354406] [<c03124cc>] (secondary_start_kernel) from [<10301ecc>]
(0x10301ecc)
[ 4.361820] r5:00000051 r4:119a806a
[ 4.365424] ---[ end Kernel panic - not syncing: No working init found.
Try passing init= option to kernel. See Linux Documentation/admin-guide/
init.rst for guidance. ]---

What am I missing?



Thanks
Rainer

[Rainer Dorsch]

Hi,

to make the long story short:

The root cause of the new kernel not booting was that the memory addresses for
kernel and initrd.img in the u-boot environment have probably changed during
this or a previous Debian release.

A new installed bullseye system uses

kernel_addr_r=0x12000000
ramdisk_addr_r=0x13000000
fdt_addr_r=0x18000000

On the upgraded system
kernel_addr_r=0x10800000
ramdisk_addr_r=0x11800000
fdt_addr_r=0x18000000

was used. Changing these variable to the new values fixed the issue. Many
thanks for all the advice I got.

I assume this is because the u-boot environment variables are not changed
during an upgrade of u-boot or to a new Debian release.

Judging from the upgrade typescripts, the system was originally installed with
Jessie (Debian 8).

The u-boot environment variables of the newly installed system are very
different from the ones in the upgraded system.

Is there an easy way to copy all the u-boot environment variables from the old
system to the new system?

Does SPL get upgraded with the u-boot upgrade?

I summarized my learnings in the Debian Wiki:
https://wiki.debian.org/InstallingDebianOn/SolidRun/CuBox-i#Boot_Process
and checked it on a second cubox-i device.

I think it would be useful if somebody would read through it and confirm that
there are not grave issues in the description.

Many thanks
Rainer

Post by Rainer Dorsch

Post by Rainer Dorsch

Post by Rainer Dorsch
Does root=/dev/mmcblk0p2 also work if ext4ls mmc 0:2 shows the rootfs?

[...]
[ 3.743918] zswap: loaded using pool lzo/zbud
[ 3.749114] Key type ._fscrypt registered
[ 3.753212] Key type .fscrypt registered
[ 3.757174] Key type fscrypt-provisioning registered
[ 3.762439] AppArmor: AppArmor sha1 policy hashing enabled
[ 3.794654] vcc_3v3: supplied by v_5v0
[ 3.815079]
[ 3.821507] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
[ 3.829798] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.10.0-10-armmp #1
Debian 5.10.84-1
[ 3.837995] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
If a module is missing, would that be different for a new installation and
an upgrade?

I did a few more experiments, good news is that the old kernel starts the
mmc dev 0;
mmc rescan
setenv bootargs "root=UUID=233113e0-67d1-409f-b2c0-57bd496213de
console=ttymxc0,115200 console=tty1"
ext4ls mmc 0:1
load mmc 0:1 ${kernel_addr_r} vmlinux-4.19.0-18-armmp
load mmc 0:1 ${fdt_addr_r} dtb-4.19.0-18-armmp
load mmc 0:1 ${ramdisk_addr_r} initrd.img-4.19.0-18-armmp
bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}
Now I am trying to get the 5.10.0 kernel up. It failed with
[ 3.338109] registered taskstats version 1
[ 3.342254] Loading compiled-in X.509 certificates
6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
4b6ef5abca669825178e052c84667ccbc0531f8c'
[ 3.761594] zswap: loaded using pool lzo/zbud
[ 3.766833] Key type ._fscrypt registered
[ 3.770885] Key type .fscrypt registered
[ 3.774839] Key type fscrypt-provisioning registered
[ 3.780060] AppArmor: AppArmor sha1 policy hashing enabled
[ 3.812034] vcc_3v3: supplied by v_5v0
[ 3.828312] Waiting for root device UUID=233113e0-67d1-409f-
b2c0-57bd496213de...
That the new system runs with the old kernel is very impressive work of the
Debian/Linux Kernel team and very useful for me in this case, a big thank
you for that!
I am struggling to boot the 5.10.0 kernel manually.
I decided to start experimenting on the system with a fresh bullseye
=> printenv localbootcmd
localbootcmd=mmc dev 1; mmc rescan; setenv bootargs ${rootfs}
console=ttymxc0,115200 console=tty1; load mmc 1:2 ${kernel_addr_r} vmlinuz-$
{ver}; load mmc 1:2 ${fdt_addr_r} dtbs/${ver}/imx6q-cubox-i.dtb; load mmc
1:2 ${ramdisk_addr_r} initrd.img-${ver}; bootz ${kernel_addr_r} $
{ramdisk_addr_r}::${filesize} ${fdt_addr_r}
=> printenv rootfs
rootfs=root=UUID=08d60447-3547-4fd3-9231-33d884e139eb
=> printenv ver
ver=5.10.0-10-armmp
=> run localbootcmd
switch to partitions #0, OK
mmc1 is current device
4960768 bytes read in 245 ms (19.3 MiB/s)
37880 bytes read in 6 ms (6 MiB/s)
23951051 bytes read in 1158 ms (19.7 MiB/s)
## Flattened Device Tree blob at 18000000
Booting using the fdt blob at 0x18000000
Loading Device Tree to 1fff3000, end 1ffff3f7 ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.10.0-10-armmp
GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.84-1
(2021-12-08)
[ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7),
cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[ 0.000000] OF: fdt: Machine model: SolidRun Cubox-i Dual/Quad
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] efi: UEFI not found.
[ 0.000000] cma: Reserved 16 MiB at 0x4f000000
[ 0.000000] DMA [mem 0x0000000010000000-0x000000003fffffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem [mem 0x0000000040000000-0x000000004fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000010000000-0x000000004fffffff]
[ 0.000000] Initmem setup node 0 [mem
0x0000000010000000-0x000000004fffffff] [ 0.000000] percpu: Embedded 21
pages/cpu s54604 r8192 d23220 u86016 [ 0.000000] Built 1 zonelists,
mobility grouping on. Total pages: 260416 [ 0.000000] Kernel command
root=UUID=08d60447-3547-4fd3-9231-33d884e139eb console=ttymxc0,115200
console=tty1
[...]
6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
4b6ef5abca669825178e052c84667ccbc0531f8c'
[ 3.686926] zswap: loaded using pool lzo/zbud
[ 3.692099] Key type ._fscrypt registered
[ 3.696193] Key type .fscrypt registered
[ 3.700156] Key type fscrypt-provisioning registered
[ 3.705407] AppArmor: AppArmor sha1 policy hashing enabled
[ 3.740196] vcc_3v3: supplied by v_5v0
[ 3.760506]
[ 3.766947] Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
[ 3.775239] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.10.0-10-armmp #1
Debian 5.10.84-1
[ 3.783436] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 3.792460] [<c0cf9144>] (dump_backtrace) from [<c0cf94f0>]
(show_stack+0x20/0x24)
[ 3.800053] r7:c19e9000 r6:60000093 r5:00000000 r4:c14cdd2c
[ 3.805737] [<c0cf94d0>] (show_stack) from [<c0cfe6ac>]
(dump_stack+0xc8/0xdc)
[ 3.812984] [<c0cfe5e4>] (dump_stack) from [<c0cfa000>]
(panic+0x11c/0x340) [ 3.819963] r7:c19e9000 r6:c0fb85d8 r5:00000000
r4:c15a5920
[ 3.825650] [<c0cf9ee4>] (panic) from [<c1201a00>]
(mount_block_root+0x368/0x374)
[ 3.833155] r3:00000000 r2:00000000 r1:c197fec4 r0:c0fb85d8
[ 3.838827] r7:c19e9000
[ 3.841380] [<c1201698>] (mount_block_root) from [<c1201a90>]
(mount_root+0x84/0x88)
[ 3.849146] r10:c111c4d8 r9:c129a858 r8:c15a2000 r7:c129a838 r6:00000008
r5:c129a868
[ 3.856993] r4:00000000
[ 3.859547] [<c1201a0c>] (mount_root) from [<c1201bf4>]
(prepare_namespace+0x160/0x19c)
[ 3.867569] r5:c129a868 r4:c15a2028
[ 3.871167] [<c1201a94>] (prepare_namespace) from [<c1201468>]
(kernel_init_freeable+0x2bc/0x2d4)
[ 3.880056] r5:c192f100 r4:c1409a90
[ 3.883659] [<c12011ac>] (kernel_init_freeable) from [<c0d086e4>]
(kernel_init+0x18/0x130)
[ 3.891945] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:00000000
r5:c0d086cc
[ 3.899791] r4:00000000
[ 3.902345] [<c0d086cc>] (kernel_init) from [<c03001a8>]
(ret_from_fork+0x14/0x2c)
[ 3.909933] Exception stack(0xc197ffb0 to 0xc197fff8)
[ 3.914999] ffa0: 00000000 00000000
00000000 00000000
[ 3.923198] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
[ 3.931396] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 3.938026] r5:c0d086cc r4:00000000
[...]
When I boot the system with the standard "run boodcmd", I can confirm that
/dev/mmcblk1p3 on / type ext4 (rw,relatime,errors=remount-ro)
/dev/mmcblk1p2 on /boot type ext2 (rw,relatime)
lrwxrwxrwx 1 root root 15 Jul 13 19:29 08d60447-3547-4fd3-9231-33d884e139eb
-> ../../mmcblk1p3
I echoed the parameters which run bootcmd uses in
echo bootargs: ${bootargs}
echo "load ${devtype} ${devnum}:${partition} ${kernel_addr_r}
${pathprefix} vmlinuz-${fk_kvers} \
&& load ${devtype} ${devnum}:${partition} ${fdt_addr_r} ${pathprefix}$
{fdtpath} \
&& load ${devtype} ${devnum}:${partition} ${ramdisk_addr_r}
${pathprefix} initrd.img-${fk_kvers} \
&& echo Booting Debian ${fk_kvers} from ${devtype} ${devnum}:$
{partition}... \
&& bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}"
and get
## Executing script at 12000000
bootargs: root=UUID=08d60447-3547-4fd3-9231-33d884e139eb
console=ttymxc0,115200 console=tty1 console=ttymxc0,115200 quiet
load mmc 1:2 0x12000000 /vmlinuz-5.10.0-10-armmp && load mmc 1:2
0x18000000 /dtbs/5.10.0-10-armmp/imx6q-cubox-i.dtb && load mmc 1:2
0x13000000 /initrd.img-5.10.0-10-armmp && echo Booting Debian
5.10.0-10- armmp from mmc 1:2... && bootz 0x12000000 0x13000000:1198
0x18000000
=> setenv bootargs "root=UUID=08d60447-3547-4fd3-9231-33d884e139eb
console=ttymxc0,115200 console=tty1 console=ttymxc0,115200"
=> load mmc 1:2 0x12000000 /vmlinuz-5.10.0-10-armmp && load mmc 1:2
0x18000000 /dtbs/5.10.0-10-armmp/imx6q-cubox-i.dtb && load mmc 1:2
0x13000000 /initrd.img-5.10.0-10-armmp && echo Booting Debian
5.10.0-10- armmp from mmc 1:2... && bootz 0x12000000 0x13000000:1198
0x18000000 4960768 bytes read in 244 ms (19.4 MiB/s)
37880 bytes read in 6 ms (6 MiB/s)
23951051 bytes read in 1155 ms (19.8 MiB/s)
Booting Debian 5.10.0-10-armmp from mmc 1:2...
## Flattened Device Tree blob at 18000000
Booting using the fdt blob at 0x18000000
Loading Device Tree to 1fff3000, end 1ffff3f7 ... OK
Starting kernel ...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.10.0-10-armmp
GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.84-1
(2021-12-08)
[ 0.000000] CPU: ARMv7 Processor [412fc09a] revision 10 (ARMv7),
cr=10c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[ 0.000000] OF: fdt: Machine model: SolidRun Cubox-i Dual/Quad
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] efi: UEFI not found.
[ 0.000000] cma: Reserved 16 MiB at 0x4f000000
[ 0.000000] DMA [mem 0x0000000010000000-0x000000003fffffff]
[ 0.000000] Normal empty
[ 0.000000] HighMem [mem 0x0000000040000000-0x000000004fffffff]
[ 0.000000] Movable zone start for each node
[ 0.000000] Early memory node ranges
[ 0.000000] node 0: [mem 0x0000000010000000-0x000000004fffffff]
[ 0.000000] Initmem setup node 0 [mem
0x0000000010000000-0x000000004fffffff] [ 0.000000] percpu: Embedded 21
pages/cpu s54604 r8192 d23220 u86016 [ 0.000000] Built 1 zonelists,
mobility grouping on. Total pages: 260416 [ 0.000000] Kernel command
root=UUID=08d60447-3547-4fd3-9231-33d884e139eb console=ttymxc0,115200
console=tty1 console=ttymxc0,115200
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7, 524288
bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144
bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:on, heap free:off
[ 0.000000] Memory: 1002428K/1048576K available (11264K kernel code,
1668K rwdata, 3192K rodata, 2048K init, 337K bss, 29764K reserved, 16384K
cma- reserved, 245760K highmem)
[ 0.000000] random: get_random_u32 called from
__kmem_cache_create+0x30/0x450 with crng_init=0
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=2, Nodes=1
[ 0.000000] ftrace: allocating 37402 entries in 110 pages
[ 0.000000] ftrace: allocated 110 pages with 5 groups
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=2.
[ 0.000000] Rude variant of Tasks RCU enabled.
[ 0.000000] Tracing variant of Tasks RCU enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay is 25
jiffies.
[ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=2
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] L2C-310 errata 752271 769419 enabled
[ 0.000000] L2C-310 enabling early BRESP for Cortex-A9
[ 0.000000] L2C-310 full line of zeros enabled for Cortex-A9
[ 0.000000] L2C-310 ID prefetch enabled, offset 16 lines
[ 0.000000] L2C-310 dynamic clock gating enabled, standby mode enabled
[ 0.000000] L2C-310 cache controller enabled, 16 ways, 1024 kB
[ 0.000000] L2C-310: CACHE_ID 0x410000c7, AUX_CTRL 0x76470001
[ 0.000000] Switching to timer-based delay loop, resolution 333ns
[ 0.000007] sched_clock: 32 bits at 3000kHz, resolution 333ns, wraps
every 715827882841ns
0xffffffff, max_idle_ns: 637086815595 ns
[ 0.003000] Console: colour dummy device 80x30
[ 0.003590] printk: console [tty1] enabled
[ 0.003651] Calibrating delay loop (skipped), value calculated using
timer frequency.. 6.00 BogoMIPS (lpj=12000)
[ 0.003689] pid_max: default: 32768 minimum: 301
[ 0.004055] LSM: Security Framework initializing
[ 0.004174] Yama: disabled by default; enable with sysctl kernel.yama.*
[ 0.004473] AppArmor: AppArmor initialized
[ 0.004505] TOMOYO Linux initialized
[ 0.004628] Mount-cache hash table entries: 2048 (order: 1, 8192 bytes,
linear)
[ 0.004669] Mountpoint-cache hash table entries: 2048 (order: 1, 8192
bytes, linear)
[ 0.005992] CPU: Testing write buffer coherency: ok
[ 0.006062] CPU0: Spectre v2: using BPIALL workaround
[ 0.006493] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.007717] Setting up static identity map for 0x10300000 - 0x103000ac
[ 0.009109] rcu: Hierarchical SRCU implementation.
[ 0.011803] EFI services will not be available.
[ 0.012286] smp: Bringing up secondary CPUs ...
[ 0.013447] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.013457] CPU1: Spectre v2: using BPIALL workaround
[ 0.013675] smp: Brought up 1 node, 2 CPUs
[ 0.013703] SMP: Total of 2 processors activated (12.00 BogoMIPS).
[ 0.013724] CPU: All CPU(s) started in SVC mode.
[ 0.014588] devtmpfs: initialized
[ 0.025168] VFP support v0.3: implementor 41 architecture 3 part 30
variant 9 rev 4
0xffffffff, max_idle_ns: 7645041785100000 ns
[ 0.025652] futex hash table entries: 512 (order: 3, 32768 bytes, linear)
[ 0.026900] pinctrl core: initialized pinctrl subsystem
[ 0.028313] DMI not present or invalid.
[ 0.028767] NET: Registered protocol family 16
[ 0.032516] DMA: preallocated 256 KiB pool for atomic coherent
allocations [ 0.033521] audit: initializing netlink subsys (disabled)
[ 0.035250] thermal_sys: Registered thermal governor 'fair_share'
[ 0.035259] thermal_sys: Registered thermal governor 'bang_bang'
[ 0.035285] thermal_sys: Registered thermal governor 'step_wise'
[ 0.035307] thermal_sys: Registered thermal governor 'user_space'
[ 0.035328] thermal_sys: Registered thermal governor 'power_allocator'
[ 0.035639] CPU identified as i.MX6Q, silicon rev 1.2
[ 0.037487] audit: type=2000 audit(0.032:1): state=initialized
audit_enabled=0 res=1
[ 0.473662] No ATAGs?
[ 0.473818] hw-breakpoint: found 5 (+1 reserved) breakpoint and 1
watchpoint registers.
[ 0.473849] hw-breakpoint: maximum watchpoint size is 4 bytes.
'regmap' already present!
[ 0.476014] imx6q-pinctrl 20e0000.pinctrl: initialized IMX pinctrl driver
[ 0.477798] Serial: AMBA PL011 UART driver
[ 0.485859] Kprobes globally optimized
[ 2.203038] mxs-dma 110000.dma-apbh: initialized
[ 2.204779] reg-fixed-voltage regulator-vcc-3v3: Failed to register
regulator: -517
[ 2.207660] iommu: Default domain type: Translated
[ 2.208875] vgaarb: loaded
[ 2.210045] mc: Linux media interface: v0.10
[ 2.210106] videodev: Linux video capture interface: v2.00
[ 2.212076] NetLabel: Initializing
[ 2.212103] NetLabel: domain hash size = 128
[ 2.212121] NetLabel: protocols = UNLABELED CIPSOv4 CALIPSO
[ 2.212232] NetLabel: unlabeled traffic allowed by default
[ 2.212631] clocksource: Switched to clocksource mxc_timer1
[ 2.304880] VFS: Disk quotas dquot_6.6.0
[ 2.305052] VFS: Dquot-cache hash table entries: 1024 (order 0, 4096
bytes) [ 2.305979] AppArmor: AppArmor Filesystem Enabled
[ 2.319926] NET: Registered protocol family 2
[ 2.320351] IP idents hash table entries: 16384 (order: 5, 131072 bytes,
linear)
[ 2.322134] tcp_listen_portaddr_hash hash table entries: 512 (order: 0,
6144 bytes, linear)
[ 2.322267] TCP established hash table entries: 8192 (order: 3, 32768
bytes, linear)
[ 2.322509] TCP bind hash table entries: 8192 (order: 4, 65536 bytes,
linear)
[ 2.322657] TCP: Hash tables configured (established 8192 bind 8192)
[ 2.322981] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 2.323073] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes,
linear)
[ 2.323902] NET: Registered protocol family 1
[ 2.323975] NET: Registered protocol family 44
[ 2.324012] PCI: CLS 0 bytes, default 64
[ 2.324926] Trying to unpack rootfs image as initramfs...
[ 2.327535] Initramfs unpacking failed: read error
[ 2.327582] Freeing initrd memory: 8K
[ 2.327952] hw perfevents: no interrupt-affinity property for /pmu,
guessing. [ 2.328222] hw perfevents: enabled with armv7_cortex_a9 PMU
driver, 7 counters available
[ 2.331042] Initialise system trusted keyrings
[ 2.331119] Key type blacklist registered
[ 2.331409] workingset: timestamp_bits=14 max_order=18 bucket_order=4
[ 2.339404] zbud: loaded
[ 2.340779] integrity: Platform Keyring initialized
[ 2.340818] Key type asymmetric registered
[ 2.340838] Asymmetric key parser 'x509' registered
[ 2.341448] bounce: pool size: 64 pages
[ 2.341630] Block layer SCSI generic (bsg) driver version 0.4 loaded
(major 250)
[ 2.341979] io scheduler mq-deadline registered
[ 2.362169] imx-sdma 20ec000.sdma: firmware: failed to load
imx/sdma/sdma- imx6q.bin (-2)
[ 2.362211] firmware_class: See https://wiki.debian.org/Firmware for
information about missing firmware
[ 2.362242] imx-sdma 20ec000.sdma: Direct firmware load for
imx/sdma/sdma- imx6q.bin failed with error -2
[ 2.369818] Serial: 8250/16550 driver, 5 ports, IRQ sharing enabled
[ 2.373383] Serial: AMBA driver
[ 2.374251] 2020000.serial: ttymxc0 at MMIO 0x2020000 (irq = 33,
base_baud = 5000000) is a IMX
[ 3.174669] printk: console [ttymxc0] enabled
[ 3.180755] 21f0000.serial: ttymxc3 at MMIO 0x21f0000 (irq = 73,
base_baud = 5000000) is a IMX
[ 3.191893] STM32 USART driver initialized
[ 3.199418] libphy: Fixed MDIO Bus: probed
[ 3.205411] mousedev: PS/2 mouse device common for all mice
[ 3.214187] snvs_rtc 20cc000.snvs:snvs-rtc-lp: registered as rtc0
[ 3.220367] snvs_rtc 20cc000.snvs:snvs-rtc-lp: setting system clock to
2021-12-28T12:41:55 UTC (1640695315)
[ 3.235562] ledtrig-cpu: registered to indicate activity on CPUs
[ 3.243723] NET: Registered protocol family 10
[ 3.256936] Segment Routing with IPv6
[ 3.260798] mip6: Mobile IPv6
[ 3.263786] NET: Registered protocol family 17
[ 3.268483] mpls_gso: MPLS GSO support
[ 3.272846] ThumbEE CPU extension supported.
[ 3.277200] Registering SWP/SWPB emulation handler
[ 3.282227] registered taskstats version 1
[ 3.286421] Loading compiled-in X.509 certificates
6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
4b6ef5abca669825178e052c84667ccbc0531f8c'
[ 3.705623] zswap: loaded using pool lzo/zbud
[ 3.710787] Key type ._fscrypt registered
[ 3.714870] Key type .fscrypt registered
[ 3.718832] Key type fscrypt-provisioning registered
[ 3.724055] AppArmor: AppArmor sha1 policy hashing enabled
[ 3.758655] vcc_3v3: supplied by v_5v0
[ 3.787824] Freeing unused kernel memory: 2048K
[ 3.805347] ------------[ cut here ]------------
[ 3.810055] WARNING: CPU: 1 PID: 1 at arch/arm/mm/dump.c:248
note_page+0x3d0/0x3dc
[ 3.817688] arm/mm: Found insecure W+X mapping at address 0xf0879000
[ 3.827180] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.10.0-10-armmp #1
Debian 5.10.84-1
[ 3.835378] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 3.844399] [<c0cf9144>] (dump_backtrace) from [<c0cf94f0>]
(show_stack+0x20/0x24)
[ 3.851994] r7:000000f8 r6:60000013 r5:00000000 r4:c14cdd2c
[ 3.857677] [<c0cf94d0>] (show_stack) from [<c0cfe6ac>]
(dump_stack+0xc8/0xdc)
[ 3.864932] [<c0cfe5e4>] (dump_stack) from [<c034d880>]
(__warn+0xfc/0x158) [ 3.871913] r7:000000f8 r6:00000009 r5:c031f740
r4:c0fbcd10
[ 3.877595] [<c034d784>] (__warn) from [<c0cfa2c8>]
(warn_slowpath_fmt+0xa4/0xe4)
[ 3.885098] r7:c031f740 r6:000000f8 r5:c0fbcd10 r4:c0fbccdc
[ 3.890778] [<c0cfa228>] (warn_slowpath_fmt) from [<c031f740>]
(note_page+0x3d0/0x3dc)
[ 3.898716] r8:00000000 r7:00000000 r6:00000005 r5:c140c4a0 r4:c197ff28
[ 3.905439] [<c031f370>] (note_page) from [<c031f834>]
(walk_pmd+0xe8/0x1a4)
[ 3.912507] r10:c197ff28 r9:c0207c20 r8:c1900800 r7:00000000 r6:c0fbcd58
r5:f087b000
[ 3.920354] r4:c19001ec
[ 3.922904] [<c031f74c>] (walk_pmd) from [<c031fa34>]
(ptdump_check_wx+0x88/0x104)
[ 3.930496] r10:00000000 r9:00000000 r8:00000000 r7:00000000 r6:c0208000
r5:f0800000
[ 3.938342] r4:c0207c28
[ 3.940899] [<c031f9ac>] (ptdump_check_wx) from [<c0319938>]
(mark_rodata_ro+0x3c/0x40)
[ 3.948924] r6:00000000 r5:c0d086cc r4:00000000
[ 3.953567] [<c03198fc>] (mark_rodata_ro) from [<c0d08710>]
(kernel_init+0x44/0x130)
[ 3.961338] [<c0d086cc>] (kernel_init) from [<c03001a8>]
(ret_from_fork+0x14/0x2c)
[ 3.968926] Exception stack(0xc197ffb0 to 0xc197fff8)
[ 3.973994] ffa0: 00000000 00000000
00000000 00000000
[ 3.982196] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
[ 3.990393] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 3.997021] r5:c0d086cc r4:00000000
[ 4.000640] ---[ end trace 64b0299d9e194c40 ]---
[ 4.005524] Checked W+X mappings: FAILED, 1 W+X pages found
[ 4.011206] Run /init as init process
[ 4.015593] Failed to execute /init (error -2)
[ 4.020113] Run /sbin/init as init process
[ 4.024490] Run /etc/init as init process
[ 4.028764] Run /bin/init as init process
[ 4.033002] Run /bin/sh as init process
[ 4.037080] Kernel panic - not syncing: No working init found. Try
passing init= option to kernel. See Linux
Documentation/admin-guide/init.rst for guidance.
[ 4.051288] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W
5.10.0-10-armmp #1 Debian 5.10.84-1
[ 4.060874] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 4.069892] [<c0cf9144>] (dump_backtrace) from [<c0cf94f0>]
(show_stack+0x20/0x24)
[ 4.077486] r7:00000000 r6:60000093 r5:00000000 r4:c14cdd2c
[ 4.083168] [<c0cf94d0>] (show_stack) from [<c0cfe6ac>]
(dump_stack+0xc8/0xdc)
[ 4.090415] [<c0cfe5e4>] (dump_stack) from [<c0cfa000>]
(panic+0x11c/0x340) [ 4.097395] r7:00000000 r6:c0fb8318 r5:00000000
r4:c15a5920
[ 4.103081] [<c0cf9ee4>] (panic) from [<c0d087f4>]
(kernel_init+0x128/0x130)
[ 4.110146] r3:00000000 r2:00000000 r1:ef6c4524 r0:c0fb8318
[ 4.115817] r7:00000000
[ 4.118370] [<c0d086cc>] (kernel_init) from [<c03001a8>]
(ret_from_fork+0x14/0x2c)
[ 4.125956] Exception stack(0xc197ffb0 to 0xc197fff8)
[ 4.131023] ffa0: 00000000 00000000
00000000 00000000
[ 4.139221] ffc0: 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000
[ 4.147418] ffe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 4.154047] r5:c0d086cc r4:00000000
[ 4.157649] CPU1: stopping
[ 4.160380] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G W
5.10.0-10-armmp #1 Debian 5.10.84-1
[ 4.169965] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 4.178976] [<c0cf9144>] (dump_backtrace) from [<c0cf94f0>]
(show_stack+0x20/0x24)
[ 4.186568] r7:00000001 r6:60000193 r5:00000000 r4:c14cdd2c
[ 4.192249] [<c0cf94d0>] (show_stack) from [<c0cfe6ac>]
(dump_stack+0xc8/0xdc)
[ 4.199503] [<c0cfe5e4>] (dump_stack) from [<c0312030>]
(do_handle_IPI+0x320/0x358)
[ 4.207181] r7:00000001 r6:2e39d000 r5:00000001 r4:c15a2d58
[ 4.212860] [<c0311d10>] (do_handle_IPI) from [<c0312090>]
(ipi_handler+0x28/0x30)
[ 4.220451] r9:c19b6000 r8:c1907000 r7:00000001 r6:2e39d000 r5:c1901380
r4:00000014
[ 4.228224] [<c0312068>] (ipi_handler) from [<c03ce194>]
(handle_percpu_devid_fasteoi_ipi+0x80/0x154)
[ 4.237474] [<c03ce114>] (handle_percpu_devid_fasteoi_ipi) from
[<c03c7454>] (__handle_domain_irq+0x8c/0xe0)
[ 4.247324] r7:00000001 r6:00000000 r5:00000000 r4:c13372c0
[ 4.253005] [<c03c73c8>] (__handle_domain_irq) from [<c030175c>]
(gic_handle_irq+0x80/0xac)
[ 4.261379] r9:c19b6000 r8:f400010c r7:c13372cc r6:f4000100 r5:c19b7f38
r4:c14068a0
[ 4.269146] [<c03016dc>] (gic_handle_irq) from [<c0300b8c>]
(__irq_svc+0x6c/0x90)
[ 4.276645] Exception stack(0xc19b7f38 to 0xc19b7f80)
00000000 00002fa0
[ 4.289911] 7f40: ef6d61c4 c0321cc0 c19b6000 00000001 c1405e9c c1405ee4
c1581f43 c0fcc220
[ 4.298111] 7f60: 00000000 c19b7f94 c19b7f98 c19b7f88 c030a5f0 c030a5f4
60000013 ffffffff
[ 4.306310] r9:c19b6000 r8:c1581f43 r7:c19b7f6c r6:ffffffff r5:60000013
r4:c030a5f4
[ 4.314081] [<c030a5ac>] (arch_cpu_idle) from [<c0d0fd6c>]
(default_idle_call+0x38/0x108)
[ 4.322289] [<c0d0fd34>] (default_idle_call) from [<c038a3f8>]
(do_idle+0xdc/0x148)
[ 4.329972] [<c038a31c>] (do_idle) from [<c038a744>]
(cpu_startup_entry+0x28/0x2c)
[ 4.337563] r9:412fc09a r8:1020406a r7:c15a2d68 r6:10c0387d r5:00000001
r4:00000092
[ 4.345333] [<c038a71c>] (cpu_startup_entry) from [<c031262c>]
(secondary_start_kernel+0x160/0x188)
[ 4.354406] [<c03124cc>] (secondary_start_kernel) from [<10301ecc>]
(0x10301ecc)
[ 4.361820] r5:00000051 r4:119a806a
[ 4.365424] ---[ end Kernel panic - not syncing: No working init found.
Try passing init= option to kernel. See Linux Documentation/admin-guide/
init.rst for guidance. ]---
What am I missing?
Thanks
Rainer

[Vagrant Cascadian]

Post by Rainer Dorsch
The root cause of the new kernel not booting was that the memory addresses for
kernel and initrd.img in the u-boot environment have probably changed during
this or a previous Debian release.
A new installed bullseye system uses
kernel_addr_r=0x12000000
ramdisk_addr_r=0x13000000
fdt_addr_r=0x18000000
On the upgraded system
kernel_addr_r=0x10800000
ramdisk_addr_r=0x11800000
fdt_addr_r=0x18000000
was used. Changing these variable to the new values fixed the issue. Many
thanks for all the advice I got.

Glad you figured it out!


From your original report:

U-Boot SPL 2014.10+dfsg1-5 (Apr 07 2015 - 22:16:43)
U-Boot 2014.10+dfsg1-5 (Apr 07 2015 - 22:16:43)

Looks like you never upgraded u-boot. The u-boot packages do not upgrade
u-boot on your boot media; you have to manually install u-boot when you
want to upgrade it.

There's a discussion about the challenges of automatically installing or
upgrading u-boot:

https://bugs.debian.org/812611

The short of it is, some boards are trickier than others and it is
difficult to detect which environments are reasonable safe to do so
automatically.

Post by Rainer Dorsch
I assume this is because the u-boot environment variables are not changed
during an upgrade of u-boot or to a new Debian release.

Yes, neither u-boot components nor the saved environment are
(re)installed on upgrade.

Post by Rainer Dorsch
Judging from the upgrade typescripts, the system was originally installed with
Jessie (Debian 8).
The u-boot environment variables of the newly installed system are very
different from the ones in the upgraded system.
Is there an easy way to copy all the u-boot environment variables from the old
system to the new system?

If you've used "saveenv" to save the u-boot environment variables, even
if you upgrade u-boot, the environment will remain frozen in the state
when you ran "saveenv".

I strongly discourage using "saveenv" as this makes upgrading u-boot
more difficult as you end up with inconsistent values between the u-boot
version you're running and the environment you've saved. This will
often work fine, although as you've discovered, sometimes updates to the
environment fixes bugs.

You have to erase or overwrite the environment area on the microSD to
get new defaults; not sure off the top of my head where exactly this is
for the cubox-i.

If there is no saved environment, u-boot uses built-in defaults from the
version of u-boot you're running.

Post by Rainer Dorsch
Does SPL get upgraded with the u-boot upgrade?

Also a manual upgrade process.

Post by Rainer Dorsch
https://wiki.debian.org/InstallingDebianOn/SolidRun/CuBox-i#Boot_Process
and checked it on a second cubox-i device.

Most of what you've written is not specific to cubox-i, but kind of how
to navigate u-boot in general.

I would not recommend the use of saveenv for the reasons described
above.

The mmc device enumeration may not be the same across u-boot and linux;
e.g. mmc 0 in u-boot will not necessarily be /dev/mmcblk0 in
linux. Sometimes it even varies by boot.


live well,
vagrant

[Rainer Dorsch]

Post by Vagrant Cascadian

Post by Rainer Dorsch
The root cause of the new kernel not booting was that the memory addresses
for kernel and initrd.img in the u-boot environment have probably changed
during this or a previous Debian release.
A new installed bullseye system uses
kernel_addr_r=0x12000000
ramdisk_addr_r=0x13000000
fdt_addr_r=0x18000000
On the upgraded system
kernel_addr_r=0x10800000
ramdisk_addr_r=0x11800000
fdt_addr_r=0x18000000
was used. Changing these variable to the new values fixed the issue. Many
thanks for all the advice I got.

Glad you figured it out!
U-Boot SPL 2014.10+dfsg1-5 (Apr 07 2015 - 22:16:43)
U-Boot 2014.10+dfsg1-5 (Apr 07 2015 - 22:16:43)

Sounds reasonable. I think that was the version release with Jessie.

Post by Vagrant Cascadian
Looks like you never upgraded u-boot. The u-boot packages do not upgrade
u-boot on your boot media; you have to manually install u-boot when you
want to upgrade it.
There's a discussion about the challenges of automatically installing or
https://bugs.debian.org/812611
The short of it is, some boards are trickier than others and it is
difficult to detect which environments are reasonable safe to do so
automatically.

Ok, I understand it is not an easy process. And it is also not urgent, I was
just hoping to avoid to get in a similar situation again in future, by having
an uptodate u-boot installation.

Post by Vagrant Cascadian

Post by Rainer Dorsch
I assume this is because the u-boot environment variables are not changed
during an upgrade of u-boot or to a new Debian release.

Yes, neither u-boot components nor the saved environment are
(re)installed on upgrade.

Post by Rainer Dorsch
Judging from the upgrade typescripts, the system was originally installed
with Jessie (Debian 8).
The u-boot environment variables of the newly installed system are very
different from the ones in the upgraded system.
Is there an easy way to copy all the u-boot environment variables from the
old system to the new system?

If you've used "saveenv" to save the u-boot environment variables, even
if you upgrade u-boot, the environment will remain frozen in the state
when you ran "saveenv".
I strongly discourage using "saveenv" as this makes upgrading u-boot
more difficult as you end up with inconsistent values between the u-boot
version you're running and the environment you've saved. This will
often work fine, although as you've discovered, sometimes updates to the
environment fixes bugs.

ok, I understand, I brought myself in a "bad" position.

Post by Vagrant Cascadian
You have to erase or overwrite the environment area on the microSD to
get new defaults; not sure off the top of my head where exactly this is
for the cubox-i.

Seems to be a well protected secret, not even the provided example works :-)

***@bc-text:~# cat /usr/share/doc/u-boot-tools/examples/mx6cuboxi.config
# Configuration file for fw_(printenv/saveenv) utility.
# Up to two entries are valid, in this case the redundant
# environment sector is assumed present.
#
# XXX this configuration might miss a fifth parameter for the "Number of
# sectors"

# MTD device name Device offset Env. size Flash sector size
/dev/mmcblk0 0x80000 0x2000
***@bc-text:~# fw_printenv --help
fw_printenv (compiled May 4 2021)
Usage fw_printenv [OPTION]
-h, : print this help
-c, --config <filename> : configuration file (old fw_env.config)
-f, --defenv <filename> : default environment if no one found
-V, : print version and exit
-n, --no-header : do not print variable name
***@bc-text:~# fw_printenv --config /usr/share/doc/u-boot-tools/examples/
mx6cuboxi.config
Configuration file wrong or corrupted
***@bc-text:~#

Changing to /dev/mmcblk1 unfortunately does not help either.

Post by Vagrant Cascadian
If there is no saved environment, u-boot uses built-in defaults from the
version of u-boot you're running.

Post by Rainer Dorsch
Does SPL get upgraded with the u-boot upgrade?

Also a manual upgrade process.

Post by Rainer Dorsch
https://wiki.debian.org/InstallingDebianOn/SolidRun/CuBox-i#Boot_Process
and checked it on a second cubox-i device.

Most of what you've written is not specific to cubox-i, but kind of how
to navigate u-boot in general.

Yes, I understood that. But I felt uncomfortable adding it as general, when I
have only I single device I could test with. Therefore I thought it is better
to keep it on the device specific page. If somebody with more insight wants to
move (part of) it to a more general place and put a link to the new place, he
is more than welcome.

Post by Vagrant Cascadian
I would not recommend the use of saveenv for the reasons described
above.

I was not aware on these side effects, I remove the saveenv again from the
description to bring nobody in trouble.

Post by Vagrant Cascadian
The mmc device enumeration may not be the same across u-boot and linux;
e.g. mmc 0 in u-boot will not necessarily be /dev/mmcblk0 in
linux. Sometimes it even varies by boot.

Yes, I changed it to PARTUUID, that seems to be a good path, since it can be
detected from u-boot and seems to be reliable.

Is uEnv.txt still supported by the implemented u-boot environment?

Thanks
Rainer

[Rainer Dorsch]

Post by Vagrant Cascadian
If you've used "saveenv" to save the u-boot environment variables, even
if you upgrade u-boot, the environment will remain frozen in the state
when you ran "saveenv".
I strongly discourage using "saveenv" as this makes upgrading u-boot
more difficult as you end up with inconsistent values between the u-boot
version you're running and the environment you've saved. This will
often work fine, although as you've discovered, sometimes updates to the
environment fixes bugs.
You have to erase or overwrite the environment area on the microSD to
get new defaults; not sure off the top of my head where exactly this is
for the cubox-i.
If there is no saved environment, u-boot uses built-in defaults from the
version of u-boot you're running.

Wouldn't

=> env default -a

enforce a reset to a default environment

https://www.vermasachin.com/posts/3-u-boot-environment-variables/

?

Thanks
Rainer

[Vagrant Cascadian]

Post by Rainer Dorsch

Post by Vagrant Cascadian
If you've used "saveenv" to save the u-boot environment variables, even
if you upgrade u-boot, the environment will remain frozen in the state
when you ran "saveenv".
I strongly discourage using "saveenv" as this makes upgrading u-boot
more difficult as you end up with inconsistent values between the u-boot
version you're running and the environment you've saved. This will
often work fine, although as you've discovered, sometimes updates to the
environment fixes bugs.
You have to erase or overwrite the environment area on the microSD to
get new defaults; not sure off the top of my head where exactly this is
for the cubox-i.
If there is no saved environment, u-boot uses built-in defaults from the
version of u-boot you're running.

Wouldn't
=> env default -a
enforce a reset to a default environment
https://www.vermasachin.com/posts/3-u-boot-environment-variables/

Only for the running u-boot, it will load from the environment at next
boot... and if you use saveenv, it will save exactly that
environment... and possibly some other quirks such as missing or changed
auto-detected environment variables at boot which can cause
inconsistancies if you then run saveenv.

To really reset it for the cubox-i, you need to overwrite at least the
beginning of address 0xFE000 on your boot media:

$ grep ENV configs/mx6cuboxi_defconfig
CONFIG_ENV_SIZE=0x2000
CONFIG_ENV_OFFSET=0xFE000

The mx6cuboxi defconfig should also be findable in
/usr/share/doc/u-boot-imx/configs/ if you have u-boot-imx:armhf
installed.


live well,
vagrant

[Rainer Dorsch]

Post by Vagrant Cascadian

Post by Rainer Dorsch

Post by Vagrant Cascadian
If you've used "saveenv" to save the u-boot environment variables, even
if you upgrade u-boot, the environment will remain frozen in the state
when you ran "saveenv".
I strongly discourage using "saveenv" as this makes upgrading u-boot
more difficult as you end up with inconsistent values between the u-boot
version you're running and the environment you've saved. This will
often work fine, although as you've discovered, sometimes updates to the
environment fixes bugs.
You have to erase or overwrite the environment area on the microSD to
get new defaults; not sure off the top of my head where exactly this is
for the cubox-i.
If there is no saved environment, u-boot uses built-in defaults from the
version of u-boot you're running.

Wouldn't
=> env default -a
enforce a reset to a default environment
https://www.vermasachin.com/posts/3-u-boot-environment-variables/

Only for the running u-boot, it will load from the environment at next
boot... and if you use saveenv, it will save exactly that
environment... and possibly some other quirks such as missing or changed
auto-detected environment variables at boot which can cause
inconsistancies if you then run saveenv.
To really reset it for the cubox-i, you need to overwrite at least the
$ grep ENV configs/mx6cuboxi_defconfig
CONFIG_ENV_SIZE=0x2000
CONFIG_ENV_OFFSET=0xFE000
The mx6cuboxi defconfig should also be findable in
/usr/share/doc/u-boot-imx/configs/ if you have u-boot-imx:armhf

Hmm....to delete the user environment I tried:

# dd if=/dev/zero of=/dev/mmcblk1 bs=512 seek=127 count=16 conv=fsync

(for reference:
***@bc-text:~# ls -l /dev/mmcblk1
brw-rw---- 1 root disk 179, 0 Jul 13 19:29 /dev/mmcblk1
***@bc-text:~# ls -l /dev/mmcblk0
ls: cannot access '/dev/mmcblk0': No such file or directory
***@bc-text:~#

***@bc-text:/usr/share/doc/u-boot-imx# zgrep CONFIG_ENV_OFFSET /usr/share/
doc/u-boot-imx/configs/config.mx6cuboxi.gz
CONFIG_ENV_OFFSET=0xFE000
***@bc-text:/usr/share/doc/u-boot-imx# zgrep CONFIG_ENV_SIZE /usr/share/doc/
u-boot-imx/configs/config.mx6cuboxi.gz
CONFIG_ENV_SIZE=0x2000

Post by Vagrant Cascadian

Post by Rainer Dorsch

Post by Vagrant Cascadian
0xFE00/512

127.0
)

and ended with

U-Boot SPL 2021.01+dfsg-5 (May 23 2021 - 04:32:45 +0000)
WDT: Not found!
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
spl_load_image_ext: ext4fs mount err - 0
SPL: Unsupported Boot Device!
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

(I tried this on a test microSD, so it does not matter if I break the
installation)

Do you see what went wrong?


Thanks
Rainer

[Rainer Dorsch]

Post by Rainer Dorsch

Post by Vagrant Cascadian

Post by Rainer Dorsch

Post by Vagrant Cascadian
If you've used "saveenv" to save the u-boot environment variables, even
if you upgrade u-boot, the environment will remain frozen in the state
when you ran "saveenv".
I strongly discourage using "saveenv" as this makes upgrading u-boot
more difficult as you end up with inconsistent values between the u-boot
version you're running and the environment you've saved. This will
often work fine, although as you've discovered, sometimes updates to the
environment fixes bugs.
You have to erase or overwrite the environment area on the microSD to
get new defaults; not sure off the top of my head where exactly this is
for the cubox-i.
If there is no saved environment, u-boot uses built-in defaults from the
version of u-boot you're running.

Wouldn't
=> env default -a
enforce a reset to a default environment
https://www.vermasachin.com/posts/3-u-boot-environment-variables/

Only for the running u-boot, it will load from the environment at next
boot... and if you use saveenv, it will save exactly that
environment... and possibly some other quirks such as missing or changed
auto-detected environment variables at boot which can cause
inconsistancies if you then run saveenv.
To really reset it for the cubox-i, you need to overwrite at least the
$ grep ENV configs/mx6cuboxi_defconfig
CONFIG_ENV_SIZE=0x2000
CONFIG_ENV_OFFSET=0xFE000
The mx6cuboxi defconfig should also be findable in
/usr/share/doc/u-boot-imx/configs/ if you have u-boot-imx:armhf

# dd if=/dev/zero of=/dev/mmcblk1 bs=512 seek=127 count=16 conv=fsync
brw-rw---- 1 root disk 179, 0 Jul 13 19:29 /dev/mmcblk1
ls: cannot access '/dev/mmcblk0': No such file or directory
doc/u-boot-imx/configs/config.mx6cuboxi.gz
CONFIG_ENV_OFFSET=0xFE000
/usr/share/doc/ u-boot-imx/configs/config.mx6cuboxi.gz
CONFIG_ENV_SIZE=0x2000

Post by Vagrant Cascadian

Post by Rainer Dorsch

Post by Vagrant Cascadian
0xFE00/512

127.0
)
and ended with
U-Boot SPL 2021.01+dfsg-5 (May 23 2021 - 04:32:45 +0000)
WDT: Not found!
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
spl_load_image_ext: ext4fs mount err - 0
SPL: Unsupported Boot Device!
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###
(I tried this on a test microSD, so it does not matter if I break the
installation)
Do you see what went wrong?

I digged somewhat further and found


https://elixir.bootlin.com/u-boot/latest/source/env/Kconfig

config ENV_IS_IN_MMC
bool "Environment in an MMC device"
depends on !CHAIN_OF_TRUST
depends on MMC
default y if ARCH_EXYNOS4
default y if MX6SX || MX7D
default y if TEGRA30 || TEGRA124
default y if TEGRA_ARMV8_COMMON
help
Define this if you have an MMC device which you want to use for the
environment.

CONFIG_SYS_MMC_ENV_DEV:

Specifies which MMC device the environment is stored in.

CONFIG_SYS_MMC_ENV_PART (optional):

Specifies which MMC partition the environment is stored in. If not
set, defaults to partition 0, the user area. Common values might be
1 (first MMC boot partition), 2 (second MMC boot partition).

CONFIG_ENV_OFFSET:
CONFIG_ENV_SIZE:

These two #defines specify the offset and size of the environment
area within the specified MMC device.

If offset is positive (the usual case), it is treated as relative to
the start of the MMC partition. If offset is negative, it is treated
as relative to the end of the MMC partition. This can be useful if
your board may be fitted with different MMC devices, which have
different sizes for the MMC partitions, and you always want the
environment placed at the very end of the partition, to leave the
maximum possible space before it, to store other data.

These two values are in units of bytes, but must be aligned to an
MMC sector boundary.

CONFIG_ENV_OFFSET_REDUND (optional):

Specifies a second storage area, of CONFIG_ENV_SIZE size, used to
hold a redundant copy of the environment data. This provides a
valid backup copy in case the other copy is corrupted, e.g. due
to a power failure during a "saveenv" operation.

This value may also be positive or negative; this is handled in the
same way as CONFIG_ENV_OFFSET.

This value is also in units of bytes, but must also be aligned to
an MMC sector boundary.

U-Boot config is in
/usr/share/doc/u-boot-imx/configs/config.mx6cuboxi.gz

***@bc-text:~# zgrep ENV_IS_IN_MMC /usr/share/doc/u-boot-imx/configs/
config.mx6cuboxi.gz
CONFIG_ENV_IS_IN_MMC=y
***@bc-text:~# zgrep CONFIG_SYS_MMC_ENV_DEV /usr/share/doc/u-boot-imx/configs/
config.mx6cuboxi.gz
CONFIG_SYS_MMC_ENV_DEV=0
***@bc-text:~# zgrep CONFIG_SYS_MMC_ENV_PART /usr/share/doc/u-boot-imx/
configs/config.mx6cuboxi.gz
CONFIG_SYS_MMC_ENV_PART=0
***@bc-text:~# zgrep CONFIG_ENV_OFFSET /usr/share/doc/u-boot-imx/configs/
config.mx6cuboxi.gz
CONFIG_ENV_OFFSET=0xFE000
***@bc-text:~# zgrep CONFIG_ENV_SIZE /usr/share/doc/u-boot-imx/configs/
config.mx6cuboxi.gz
CONFIG_ENV_SIZE=0x2000
***@bc-text:~#


***@bc-text:~# sfdisk -l /dev/mmcblk1
Disk /dev/mmcblk1: 58.56 GiB, 62878384128 bytes, 122809344 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8ad3fb70

Device Boot Start End Sectors Size Id Type
/dev/mmcblk1p1 32768 299999 267232 130.5M c W95 FAT32 (LBA)
/dev/mmcblk1p2 * 301056 1300479 999424 488M 83 Linux
/dev/mmcblk1p3 1300480 120815615 119515136 57G 83 Linux
/dev/mmcblk1p4 120817662 122808319 1990658 972M 5 Extended
/dev/mmcblk1p5 120817664 122808319 1990656 972M 82 Linux swap /
Solaris
***@bc-text:~# sfdisk -F /dev/mmcblk1
Unpartitioned space /dev/mmcblk1: 15 MiB, 15728640 bytes, 30720 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes

Start End Sectors Size
2048 32767 30720 15M
***@bc-text:~#


But what is partition 0 specified in CONFIG_SYS_MMC_ENV_PART ? The free space
starting at 2048?

If yes, would that imply that I need

# dd if=/dev/zero of=/dev/mmcblk1 bs=512 seek=127 count=16 conv=fsync

to delete the user environment?

Thanks
Rainer

[Rainer Dorsch]

Post by Vagrant Cascadian

I upgraded a cubox-i from buster to bullseye. The upgrade went through without

any issues. But after the upgrade the system does not boot

Post by Vagrant Cascadian

anymore. The output of the serial console is below. The boot process
hangs at
[ 3.816424] Waiting for root device /dev/mmcblk1p2...
Did the device enumeration change?

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...

How would I find out the new device name and how would I change the boot
parameters (which apparently specifies /dev/mmcblk1p2 according to the output

below)?

Post by Vagrant Cascadian
If you can insert the microSD into another Debian machine, you can get
the UUID by looking in /dev/disk/by-uuid/ to find the matching device
lsblk --fs /dev/DEVICE
It might be possible to discover from u-boot as well, but I forget off
the top of my head.

I can recommend barebox here instead of U-Boot. i.MX is the probably
best supported platform for it and I would expect the cubox-i to be
directly supported.
Barebox can mount various filesystems and if there is a bootspec entry
boot /mnt/mmc0.0
to let barebox pick the kernel, initrd and dtb from the filesystem on
mmc0.0 and pass root=UUID=$therightone.

Thanks for the advice. Is barebox already packaged for Debian and I just don't
find it or do I need to install it from non-Debian sources?

Thanks
Rainer

[Uwe Kleine-König]

Hi Rainer,

Post by Rainer Dorsch

I can recommend barebox here instead of U-Boot. i.MX is the probably
best supported platform for it and I would expect the cubox-i to be
directly supported.
Barebox can mount various filesystems and if there is a bootspec entry
boot /mnt/mmc0.0
to let barebox pick the kernel, initrd and dtb from the filesystem on
mmc0.0 and pass root=UUID=$therightone.

Thanks for the advice. Is barebox already packaged for Debian and I just don't
find it or do I need to install it from non-Debian sources?

It's not yet packaged, there is only an ITP, which waits for some effort
to convert barebox to SPDX. https://bugs.debian.org/900958

Best regards
Uwe

[Vagrant Cascadian]

Post by Uwe Kleine-König

Post by Rainer Dorsch

I can recommend barebox here instead of U-Boot. i.MX is the probably
best supported platform for it and I would expect the cubox-i to be
directly supported.
Barebox can mount various filesystems and if there is a bootspec entry
boot /mnt/mmc0.0
to let barebox pick the kernel, initrd and dtb from the filesystem on
mmc0.0 and pass root=UUID=$therightone.

Thanks for the advice. Is barebox already packaged for Debian and I just don't
find it or do I need to install it from non-Debian sources?

I briefly tried barebox and must say I liked it; if it's supported by a
platform you use I can definitely recommend trying barebox! The shell
felt more like a bourne shell (e.g. bash) than u-boot and maybe a bit
more comfortable for someone not already familiar with u-boot...

Post by Uwe Kleine-König
It's not yet packaged, there is only an ITP, which waits for some effort
to convert barebox to SPDX. https://bugs.debian.org/900958

That looks to be *mostly* done, from a quick glance.

Looking forward to seeing it in Debian!


live well,
vagrant

[Rainer Dorsch]

Post by Vagrant Cascadian
If you can insert the microSD into another Debian machine, you can get
the UUID by looking in /dev/disk/by-uuid/ to find the matching device
lsblk --fs /dev/DEVICE
It might be possible to discover from u-boot as well, but I forget off
the top of my head.

There is

=> part uuid mmc 1:2
8ad3fb70-02
=> part uuid mmc 1:3
8ad3fb70-03
=>

but "root=UUID=8ad3fb70-03" is not working for mounting the rootfs.

In the bullseye installation, there is also a variable defined finduuid

finduuid=part uuid mmc 0:1 uuid

which is even called by bootcmd, but I am not sure if that is doing anything
useful.

Rainer

[Vagrant Cascadian]

Post by Rainer Dorsch

Post by Vagrant Cascadian
If you can insert the microSD into another Debian machine, you can get
the UUID by looking in /dev/disk/by-uuid/ to find the matching device
lsblk --fs /dev/DEVICE
It might be possible to discover from u-boot as well, but I forget off
the top of my head.

There is
=> part uuid mmc 1:2
8ad3fb70-02
=> part uuid mmc 1:3
8ad3fb70-03
=>
but "root=UUID=8ad3fb70-03" is not working for mounting the rootfs.
In the bullseye installation, there is also a variable defined finduuid
finduuid=part uuid mmc 0:1 uuid
which is even called by bootcmd, but I am not sure if that is doing anything
useful.

That *may* be a partition UUID, rather than a filesystem
UUID... initramfs-tools 0.121 and newer supports using
root=PARTUUID=...

You can see the available partition uuids on linux in
/dev/disk/by-partuuid/


live well,
vagrant

[gene heskett]

Post by Vagrant Cascadian

Post by Rainer Dorsch

Post by Vagrant Cascadian
If you can insert the microSD into another Debian machine, you can get
the UUID by looking in /dev/disk/by-uuid/ to find the matching device
lsblk --fs /dev/DEVICE
It might be possible to discover from u-boot as well, but I forget off
the top of my head.

There is
=> part uuid mmc 1:2
8ad3fb70-02
=> part uuid mmc 1:3
8ad3fb70-03
=>
but "root=UUID=8ad3fb70-03" is not working for mounting the rootfs.
In the bullseye installation, there is also a variable defined finduuid
finduuid=part uuid mmc 0:1 uuid
which is even called by bootcmd, but I am not sure if that is doing
anything useful.

That *may* be a partition UUID, rather than a filesystem
UUID... initramfs-tools 0.121 and newer supports using
root=PARTUUID=...
You can see the available partition uuids on linux in
/dev/disk/by-partuuid/

Thank you very very much, vagrant. I've been wondering how those were
married, but a much more informative answer is from ls -l + the above path.

Post by Vagrant Cascadian
From my 2 gig rpi4, serving as a buildbot, and heavily modified to move much

of the buildbot traffic off the u-sd:

***@rpi4:~/linuxcnc/configs/sheldon-lathe $ ls -l /dev/disk/by-partuuid/
total 0
lrwxrwxrwx 1 root root 15 Oct 18 06:55 5e3da3da-01 -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 15 Oct 18 06:55 5e3da3da-02 -> ../../mmcblk0p2
lrwxrwxrwx 1 root root 10 Oct 18 06:55 c2cbc1a6-01 -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 18 06:55 c2cbc1a6-02 -> ../../sda2
lrwxrwxrwx 1 root root 10 Oct 18 06:55 c2cbc1a6-03 -> ../../sda3
lrwxrwxrwx 1 root root 10 Oct 18 06:55 c2cbc1a6-04 -> ../../sda4
lrwxrwxrwx 1 root root 10 Oct 18 06:55 c61252a1-01 -> ../../sdb1

sda/sdb are SSD's on usb3-sata adapters

Post by Vagrant Cascadian
live well,

You too,

Post by Vagrant Cascadian
vagrant

Cheers, Gene Heskett.

[Rainer Dorsch]

Post by Vagrant Cascadian

Post by Rainer Dorsch

Post by Vagrant Cascadian
If you can insert the microSD into another Debian machine, you can get
the UUID by looking in /dev/disk/by-uuid/ to find the matching device
lsblk --fs /dev/DEVICE
It might be possible to discover from u-boot as well, but I forget off
the top of my head.

There is
=> part uuid mmc 1:2
8ad3fb70-02
=> part uuid mmc 1:3
8ad3fb70-03
=>
but "root=UUID=8ad3fb70-03" is not working for mounting the rootfs.
In the bullseye installation, there is also a variable defined finduuid
finduuid=part uuid mmc 0:1 uuid
which is even called by bootcmd, but I am not sure if that is doing
anything useful.

That *may* be a partition UUID, rather than a filesystem
UUID... initramfs-tools 0.121 and newer supports using
root=PARTUUID=...
You can see the available partition uuids on linux in
/dev/disk/by-partuuid/

Indeed that works.

Many thanks
Rainer