[PATCH 0/3] Qi booting control from rootfs

Andy Green andy at openmoko.com
Tue Nov 25 16:48:54 CET 2008


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


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


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

> Sure there is, if you tell it to boot from JFFS2. But why would
> this affect the problem we have with the dynamic partitions ?

Excessive snippage got methinking this was about the ubifs thread also
today.

Still, we would actually have to parse U-Boot env partition completely
with U-Boot rules and pass it to kernel to fulfil the sharing aspect,
that's no good.  Let U-Boot boot according to its rules that Qi won't
impact, and U-Boot rules won't impact Qi.

> You could consider it a feature: if you change your rootfs, you
> don't have to restore the Qi parameter line :-)

No it's definitely evil.

> It actually fits nicely if you think of the usage pattern: if you
> maintain distinct root file systems on an SD card, you'll probably
> just have multiple cards and switch them. However, with NAND, you
> have to wipe out the old rootfs, but you keep boot loader and
> kernel out-of-band.

That's not what people are doing, they have multiple partitions /
distros on one increasingly large SD card, and it is useful that each
can have a boot context attached to it rather than one instance of some
magic partition that contains it.

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

iEYEARECAAYFAkksHmUACgkQOjLpvpq7dMp9awCgj59YimhU5nB9soTxmfSBaju0
2WEAn3wbGQhZR3vIfA0oJxXbKK0DvSfL
=yjmE
-----END PGP SIGNATURE-----



More information about the openmoko-kernel mailing list