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


Am Dienstag, 28. Dezember 2021, 13:47:01 CET schrieb Rainer Dorsch:

Am Dienstag, 28. Dezember 2021, 01:24:41 CET schrieb Rainer Dorsch:

Am Dienstag, 28. Dezember 2021, 01:10:39 CET schrieb Rainer Dorsch:

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?

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?

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-kernel@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:

rd@bc-text:~$ mount|grep mmc
/dev/mmcblk1p3 on / type ext4 (rw,relatime,errors=remount-ro)
/dev/mmcblk1p2 on /boot type ext2 (rw,relatime)
rd@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

rd@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-kernel@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-gpr@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
http://bokomoko.de/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-12-29, Rainer Dorsch wrote:

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.

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.

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.

Does SPL get upgraded with the u-boot upgrade?

Also a manual upgrade process.

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.

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

--=-=-Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCYcyp9QAKCRDcUY/If5cW qhakAP480RgXRWGcHWz/Jks9ciZL9bF18yIjdDbtgFL7UtQ4cQD+NSTs7e8aTrg8 VgygzAoy+J6dR6usyuncG9XFtQNTCw4=kjy2
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Mittwoch, 29. Dezember 2021, 19:33:20 CET schrieb 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

--
Rainer Dorsch
http://bokomoko.de/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Mittwoch, 29. Dezember 2021, 19:33:20 CET schrieb Vagrant Cascadian:

On 2021-12-29, Rainer Dorsch wrote:

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)

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

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.

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.

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.

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.

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 :-)

root@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
root@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
root@bc-text:~# fw_printenv --config /usr/share/doc/u-boot-tools/examples/ mx6cuboxi.config
Configuration file wrong or corrupted
root@bc-text:~#

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

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

Does SPL get upgraded with the u-boot upgrade?

Also a manual upgrade process.

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.

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.

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.

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
http://bokomoko.de/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2021-12-29, Rainer Dorsch wrote:

Am Mittwoch, 29. Dezember 2021, 19:33:20 CET schrieb 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Mittwoch, 29. Dezember 2021, 22:18:31 CET schrieb Vagrant Cascadian:

On 2021-12-29, Rainer Dorsch wrote:

Am Mittwoch, 29. Dezember 2021, 19:33:20 CET schrieb 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

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:
root@bc-text:~# ls -l /dev/mmcblk1
brw-rw---- 1 root disk 179, 0 Jul 13 19:29 /dev/mmcblk1
root@bc-text:~# ls -l /dev/mmcblk0
ls: cannot access '/dev/mmcblk0': No such file or directory
root@bc-text:~#

root@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
root@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
root@bc-text:/usr/share/doc/u-boot-imx#

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
http://bokomoko.de/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Donnerstag, 30. Dezember 2021, 14:16:14 CET schrieb Rainer Dorsch:

Am Mittwoch, 29. Dezember 2021, 22:18:31 CET schrieb Vagrant Cascadian:

On 2021-12-29, Rainer Dorsch wrote:

Am Mittwoch, 29. Dezember 2021, 19:33:20 CET schrieb 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

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:
root@bc-text:~# ls -l /dev/mmcblk1
brw-rw---- 1 root disk 179, 0 Jul 13 19:29 /dev/mmcblk1
root@bc-text:~# ls -l /dev/mmcblk0
ls: cannot access '/dev/mmcblk0': No such file or directory
root@bc-text:~#

root@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
root@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
root@bc-text:/usr/share/doc/u-boot-imx#

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

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


root@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
root@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
root@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
http://bokomoko.de/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)