some question about NAND partitions with QI
andy at openmoko.com
Tue Aug 26 11:26:45 CEST 2008
-----BEGIN PGP SIGNED MESSAGE-----
Somebody in the thread at some point said:
| xiangfu wrote:
| matt_hsu wrote:
|>>> is that mean the QI must deal with two commandline
|>>> one is for kboot kernel
|>>>> I think Andy's saying is to add extra structure in board_api_info
|>>>> such as
|>>>> .commandline = ""
|>>>> .alt_commandline = ""
|>>>> Qi can detect the external events such as AUX key pressing
|>>>> to select
|>>>> proper commandline to pass into kernel.
| i think that AUX key pressing or something is to choose kernel not
|> Both of they are the same thing.
|> It means, according to the external event, qi can select proper
|> kernel and corresponding kernel command line.
Yes by luck backup kernel == NAND and normal kernel == SD, so we are OK.
~ We can add structure member like ".depends_on_aux" so 0 = always tries
to boot it, 1 is needs aux down to try it and 2 is needs aux up to try it.
|>>> another is for normal kernel.
|>>> and both of them easy to modify by end user?
|>>>> If we want to program the cmdline partition, you can use
|>>>> nand_write to modify this mtdparts.
|>>>> The problem is, do we need to provide this feature?
| i think Andy mean we should find a better way then cmdline partition in
|> Now qi does not have any method to update the content in NAND unless
|> you boot into kernel.
|> My question is, do we need to provide this kind flexibility to let
|> user update cmdline partition?
|> If yes, we need to use mtd utility or find something else to program
|> this partition.
|> If no, we can just provide couple boot scenarios in qi.
I think we can ignore custom command line support in Qi. When the
backup kernel has kexec, we can handle and store custom commandline in
Backup rootfs context which is normal Linux, so nand_write and so on are
-----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