some question about / adding commandline files from rootfs

Werner Almesberger werner at
Wed Aug 27 03:02:22 CEST 2008

Andy Green wrote:
> How about using this generically for selecting between multiboot
> partitions too.

Something like this ?

- first choice: the first one that exists and is valid in

  - SD, first partition, ext2, primary kernel
  - SD, first partition, FAT, primary kernel

- second choice or fallback: the first from

  - SD, first partition, ext2, secondary kernel
  - SD, first partition, FAT, secondary kernel
  - SD, second partition, ext2, primary kernel
  - SD, second partition, FAT, primary kernel
  - SD, second partition, ext2, secondary kernel ?
  - SD, second partition, FAT, secondary kernel ?
  - NAND

For kernel hackers, the main choice is between primary and secondary
kernel. E.g., when your latest creation blows up, you can quickly go
back to something that works.

For distribution hackers, different root file systems definitely seem
to have their appeal.

Chances are that people who have two user spaces might still want
to have a single kernel, and just change the command line to pick
the other partition for the root file system.

Not sure if having a second kernel on the second partition would be
useful. A broken primary kernel will normally still be accepted by
qi, so you can't usefully select that secondary kernel anyway.

Yep, sounds good then.

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

Yeah, that's what worries me a little ;-) If we end up just bringing
half of u-boot over into qi, then we've just recreated much of the
mess we moved away from.

> 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.

Yup, comments, please ! :)

> 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".

Ah yes, we've seen that happen a number of times, haven't we ? ;-)

> It's not
> true there's no legitimate reason for them to update it -- we just
> provided one

Yep, I meant the part of there being no legitimate reason ironically,
because we actually found a rather compelling one.

> 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.

Yup. There's also the level of suffering that debricking causes,
e.g., even with JTAG on board, I wouldn't recommend lightly to
upgrade qi, because recovering from a broken qi may force people
to deal with complexity they would otherwise have avoided.

Speaking of NAND updates, how do we disable the read-only trap ?
Something like the four quadrants tap sequence to get out of FSO's
screen saver may be nice, but implementing it may also be a bit on
the complicated side. (For me, that's less about "hard to do" but
more about "more code to maintain".)

> but still it is better if it ignores any
> commandline file for the actual backup system kernel.

How about looking at this from a risk assessment point of view ?

a) If some time in the future, something needs changes in the command
   line and we don't support setting the command line from NAND, then
   you need either

   1) from then on, a separate build of the kernel (with the new
      command line hard-coded and set to ignore anything passed by
      the boot loader), or

   2) an update of qi, with the issues discussed above (note that
      this gets even worse if people have to roll back for some
      reason, because they then need another qi update)

b) If we do support changing the command line, someone may change it
   for no good reason, run into problems, and cause us trouble, e.g.,
   by posting scathing reviews, giving us a support puzzle, etc.

We just have an unexpected and sweeping change in the boot process,
that - among many other things - changes the command line. Drawing
from the mediocrity principle, i.e., that there's nothing special
about the present state, we can quite expect similar things to happen
again in the lifetime of GTA03. And the consequences of not being
able to change the command line then mean increased maintenance
and/or support cost. (And the riskiness of the upgrade may actually
prevent people from attempting it, forking the user base.)

On the other hand, people who make changes they don't understand
and who do this for no good reason, will probably find a gazillion
other ways to make our lives miserable, so the difference should
be minimal.

- Werner

More information about the openmoko-kernel mailing list