[PATCH 0/3] Qi booting control from rootfs

Werner Almesberger werner at openmoko.org
Tue Nov 25 15:37:48 CET 2008

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
not nearly as often as we do on Neos. Second, you still have parts
of your boot loader in the boot sector or the MBR, so all you'll get
is a system that behaves unpredictably until you replace that part
as well.

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

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

- Werner

More information about the openmoko-kernel mailing list