some question about NAND partitions with QI
andy at openmoko.com
Tue Aug 26 11:20:38 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
| is that mean the QI must deal with two commandline
| one is for kboot kernel
| another is for normal kernel.
| and both of them easy to modify by end user?
Yes it selects a canned commandline that belongs to the "kernel source"
that worked. Normal kernel now lives in SD Card. Backup kernel lives
in NAND. So this is enough to choose.
No, they are not modifiable by end user. The best reason I heard for
needing it is setting log level. But I don't think it is enough reason
to destroy simple and deterministic bootloader approach.
Mike Westerhof proposed a workaround concept, to deal with special
commandline by Qi --> backup kernel / rootfs --> kexec. Then special
commandline is someone else's problem they can deal with in Linux
context. So I think that is the way if people want it.
|> We need to think about how we want to do it, what is your plan? Hold
|> down a button?
| 1. how about hold down AUX, the same as nand uboot way.
| and Werner mention two another ways:
| Werner wrote:
|> The user indication could be the user pressing on the touch screen.
|> Or we could also load the default kernel first(whick will take a bit
|> of thime), then check if POWER is held, if yes, load and start the
|> kboot system, otherwise start the default system we've already loaded.
They don't sound better than the AUX plan to me, I think you had the
right idea. But we need to be aware that really only one or two "magic
keys" in bootloader make sense and we just used 50 or 100% of them.
-----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