[PATCH 0/3] Qi booting control from rootfs
andy at openmoko.com
Tue Nov 25 16:13:00 CET 2008
-----BEGIN PGP SIGNED MESSAGE-----
Werner Almesberger wrote:
> Andy Green wrote:
>> No it's not "U-Boot" as a trigger word that's the problem, just this
>> issue of private bootloader state. At least in the other incarnations,
>> if you nuke the rootfs you also fully controlled any change to
>> bootloader actions for sure, so it's deterministic.
> Hmm, if you're referring to a PC or such, then that isn't really the
> case. First of all, you rarely nuke your rootfs on a PC - at least
No I mean the rootfs that is containing kernel and append-* for Qi. If
you nuke that, in one step you changed what will boot and how it will boot.
>> It's a problem with no right answer because the NOR U-Boot cannot change
>> in the field.
> But this doesn't matter, does it ? It's about where the data is in
> the NAND and whether what you tell the kernel is correct or not.
There's no rootfstype=jffs2 floating around with NOR?
>> Well it will just fail to boot if not and they can stick U-Boot back in
>> there, so it's not necessary unless you have problems and then you can
>> back out.
> If the rootfs location is wrong, which is the most likely outcome,
> you get subtle file system corruption. Things like deleted files
> coming back from the dead and such. This happens in real life. I've
> seen it enough times when "upgrading" devices after we made the
> fateful decision to change our partition layout on HXD8. I can tell
> you, those revenant ghosts can really drive you nuts ...
>> The best solution -- as arrived at for a while -- is to extol the
>> virtues of the non-raw NAND found in SD Card (on GTA02 too), since
>> that's already the way forward it means we're going backwards if we
>> focus too heavily on raw NAND issues.
> Just using the 2nd erasepage shouldn't be too horrible, should it ?
> That way, Qi has a homogenous feature set across all configurations.
Yeah but it's absolutely not homogenous, that's the whole reason I am
allergic to it. For NAND, if you blow the rootfs, weird outcomes can
still happen depending on the secret "2nd erasepage" state that is not
impacted by rootfs: not so for SD. It's not worth servicing the need
for append and noboot on NAND by bringing back the private state monster.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the openmoko-kernel