[PATCH 0/3] Qi booting control from rootfs

Andy Green andy at openmoko.com
Tue Nov 25 15:00:56 CET 2008

Hash: SHA1

Werner Almesberger wrote:
> Andy Green wrote:
>> I think we can get around it for now by checking for NULL filepath name
>> if it's RAW and erroring out if non-NULL.  I don't want to implement
>> "U-Boot environment in NAND".
> How about using the second erase page for the command line ? That
> way, it doesn't conflict with anything a u-boot based system puts
> into the NAND, and you have a reasonably good chance that the
> location will be usable.

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.  Legacy NAND
arrangements for that are inherently broken already with discrete raw
kernel arrangement and additional private state partition.  It's not
that Qi needs to follow the wrongness we have already but that it needs
to reject it so we can go on in a righteous way.

> NAND needs a command line if you want to allow people to switch
> back and forth between Qi and u-boot, i.e., share kernel and rootfs
> locations with u-boot, because of the evil dynamic partitions.

It's a problem with no right answer because the NOR U-Boot cannot change
in the field.

> The hard-coded defaults in Qi are only correct if you don't have
> any bad blocks in the first ~9MB, the probability of which may be
> as low as 24% if Samsung max out their bad block allowance.
> At least the chance that the kernel is at the expected place (but
> rootfs may not) is 94.4% or better.

Yeah, just agreeing it only works with NAND set up by U-Boot due to very
low bad block incidence, dunno about the numbers.

> In any case, I would recommend that anyone installing Qi should
> first check that their partition sizes are 0x40000, 0x40000,
> 0x800000, 0xa0000, and 0x40000. (Command "mtd" in u-boot or
> "cat /proc/mtd" in Linux.)

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.

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.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


More information about the openmoko-kernel mailing list