[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