some question about / adding commandline files from rootfs

Andy Green andy at
Wed Aug 27 01:18:42 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:
| Andy Green wrote:
|> Instead of loading the full kernel size in one call, Xiangfu can make a
|> while() loop there loading 64KByte units for example, and inside the
|> loop we check for AUX press.
| Good idea. And we just don't care about NOR in qi, eliminating the
| "AUX still pressed from selecting NOR" case.
|   If seen we always abort the loop and jump
|> to the last kernel source for the board, which is the backup one (and no
|> longer look for AUX).
| Jumping to the last would force you to use NAND for the backup system.
| Better just skip the first group, so that you can also have the backup
| system on SD. You get an automatic fallback to NAND anyway, by removing
| the SD card.

How about using this generically for selecting between multiboot
partitions too.  So it defaults to your first SD partition, click AUX
once after a moment to get second partition boot, or NAND backup thing
when you run out of partitions with kernels in.  That way people can run
FSO and Debian etc on the same SD Card and share /home partition, etc
and select really easily.

|> I just see it as more special pleading for NAND, it is "unusual file
|> system".  But, large NAND is currently a fact and then it means we ought
|> to have fs for it that does wear levelling.  By default that is going to
|> be jffs2.
| Alright, having a "real" file system there is certainly nicer for
| the user, although it makes the task quite a bit harder for qi.

It's just another fs port from U-Boot AIUI.

|> Many other users now are booting SD
|> for Debian and other rootfs and I didn't notice complaints about insane
|> speed loss.  So I think it is OK for customers.
| Perfect. Let's treat GTA02 and GTA03 the same then. Their different
| unbricking mechanisms are a second-order problem.

I'm OK with it but this is quite a major change for GTA02, folks should
get their opinion out about it now if they feel one coming.

|> What I meant is that we do not want function of backup system to have
|> dependency to anything it doesn't have to... there's zero legitimate
|> case for end user to touch backup kernel commandline.
| Hmm, whenever the word "NOR" comes up, you remind me of its read-only
| nature. There's also zero legitimate case for end users to ever have

It's not actually aimed at you: I found being quiet about the things
that make trouble led to people continuing to support them blissfully
unaware of what goes on because "that's the way it is done".  So now I
take care to note when we cover a problem that comes out of something I
don't like to see any more in the hope there will be more understanding
of why I don't want to see it, or want to see another way when the time
for those raging arguments come.

| to touch the NOR. Yet here we are, plotting massive changes that
| completely rearrange that little world, even less than two months
| after selling the first GTA02 :-)

Shipped NOR content is a "fly in amber" representing where we got to at
that time.  But in two months, we got a lot of better plans becoming
implemented.  And they contradict what is in "write-once NOR".  It's not
true there's no legitimate reason for them to update it -- we just
provided one with desire for ECC-driven NAND content change that it
ain't going to understand.  Further in another two months maybe we got
even more awesome improvements it will conflict with.

Once again this is the dichotomy of updatable firmware vs debrickability
and once again it only gets truly solved by implementing JTAG interface
by USB on the phone.  That way ALL firmware is always safely updateable
without any brickability angle to consider.

| If we already have a real file system to load the kernel from, it
| would be pretty easy to also search it for the command line at the
| same time, thus making all cases (SD-ext2, SD-FAT, and NAND) look
| the same.

Sure, but that's a separate issue.  Well, someone has to put the
commandline thing in the backup rootfs to make a problem so I guess this
is a small corner case, but still it is better if it ignores any
commandline file for the actual backup system kernel.

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


More information about the openmoko-kernel mailing list