[PATCH 0/5] Enable Qi / backup rootfs

Werner Almesberger werner at openmoko.org
Tue Aug 26 02:16:28 CEST 2008


Andy Green wrote:
> Lacking that, we should
> allow Qi update under special user action on GTA03 working through the
> nWP system and not lock users out

Yes, but we should still refrain from requiring users to upgrade qi,
because if they do and anything goes wrong, then all they've left
is a brick.

> What do we actually need this backup NAND fs for in the context that we
> can pop the SD Card and nuke the "system partition" in a PC?

That's a good question :-) If we assume that we have a fully-featured
support environment at hand, then putting the uSD card there and
fixing whatever broke seems like the easiest choice.

Now, what if the fully-featured support system isn't available or if
it can do everything we need, except accessing uSD cards ? In this
case, we need some communication that can be brought up even if the
uSD is hosed.

How much communication again depends on how much external support
we have, but also on how much we really expect to be able to do from
our machine. The latter is limited by keyboard input and such, and
what shrink-wrapped recovery procedures we can offer.

The bare practical minimum of communication would be Ethernet over
USB. That gives access from basically any Linux PC (or GTA02 and
above :-), and also many non-Linux systems.

For stand-alone recovery, access to WLAN or even GPRS/EDGE would be
highly desirable. But they also add a lot of complexity, require
configuration data, and it's not quite clear whether one would
really want to use them in real life.

A "feature-rich" usage scenario could be a boot menu option that
initializes a uSD card over the network, possibly even including
configuration files from some backup service/location.

A slightly less demanding scenario would be just doing a file system
check and replacing a few key files on uSD, e.g., kernel and modules.

There's also the question of how far the shrink-wrapping should go,
and from where the user is expected to bring up a shell and peck at
the on-screen keyboard.

> What kind
> of functionality do we think about putting in there then?  I guess
> failsafe network access is good but it all seems secondary if you have
> direct access to the SD Card if surgery is needed.

Yes, I think that should be the main recovery path. If it's possible,
it's fast and there's a lot of flexibility. Disadvantages include
that one may not have a uSD reader (e.g., when traveling), that no
suitable host may be around, and that the recovery process then
includes the host environment.

A standalone ("kboot") environment in NAND could do things like list
all kernels in /boot and let the user select one, provide shell and
keyboard, and it could easily provide EoUSB and SSH access (after
manual activation).

I think that would be a nice enough feature set to keep everyone
happy, and we can probably steal all the key components from our
regular user space, with very little extra glue needed.

Now, having said all that, I learned that people are a lot more
creative about what they want to do in the boot process than I
could be in my wildest dreams. So we might just see what happens
after we unleash qi onto GTA02, and pick any goodies that emerge.

What do you think ?

- Werner



More information about the openmoko-kernel mailing list