some question about NAND partitions with QI

Andy Green andy at
Tue Aug 26 11:26:45 CEST 2008

Hash: SHA1

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
| commandline
|>    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
|>>>> flash_erase,
|>>>> 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

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


More information about the openmoko-kernel mailing list