Re: Solved: cubox-i does not boot after upgrade to bullseye
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/
Reply to: