Qi multi-boot: will it be supported?

Andy Green andy at openmoko.com
Sat Nov 1 01:05:26 CET 2008

Hash: SHA1

Somebody in the thread at some point said:
| Marco Trevisan (Treviño) wrote:
|> Hello, actually I'm generally turning on my phone trough an uBoot that
|> I've configured to support booting from about 4 different distro using
|> one uSD ext2 partition for all the kernels (named like
|> "uImage-<distro>.bin") and 4 ext2 partitions for all the distros
|> installed (Om2008, FSO, Debian, Qt Extended...).
|> Also if I generally use the first one, I'd like to keep the ability of
|> booting in a such way other distros using Qi too.
|> If I've not read(/remember) wrong, Qi actually supports just booting
|> from flash and from uSD (keeping the default way: one partition for
|> kernel, another for the rootfs), but will it ever support a multi-boot
|> like the uBoot does (with a configurable menu)?

What I plan for Qi directly is ability to click a button and have it
abort current kernel load and move to next option.  There's no menu in
that picture, maybe flick an LED to confirm it moved on.  However the
extended stuff via a secondary kernel and rootfs is perfectly fine too -->

| This sort of functionality should be handled by a special kernel/rootfs.

Right, bootloader == "loader" to "boot", everything else belongs in a
world set up for it.  Linux has great support for the whole stack of
doing menus and libs for framebuffer and so on in a normal, hackable and
maintainable way.  A way that can accept contributons from mortals too.

| OE already has support for this for other devices, and the current
| kernel/hardware also has full support for this, so it's just a matter of
| doing the work to build it.
| What you describe is minimal support.  What I'd like to see would be a
| set of "advanced" or "developer" configurations, that would allow (for
| example) the kernel to be pulled in via NFS, or TFTP.  We should explore
| using loopback mounts for the rootfs so that the SD card can be entirely

Yeah all this is open to just being done.  In GTA03 I currently set
aside 10MB ext2 backup rootfs on the SD Card for this purpose.

We already do something like this for the new test framework that Chris
Hall in .tw has done, we make such a rootfs entirely from stock package
contents so there is no reinventing the wheel.  He even got the host
opkg app to compose it and keep a record inside the composed filesystem
of the patchlevel on packages.  This works out great -- he basically got
that part running in a day -- so this is what is needed for the backup /
recovery partition rootfs too.

| We have 4MB of flash for the kernel -- a minimal solution should be able
| to fit such a kernel with initrd easily, leaving the entire rootfs
| portion of flash exactly as it is today -- with the exception that such
| a kernel would actually read the real kernel from the jffs2 rootfs
| (which would make simple upgrades of the kernel easier, too...)
| The benefits of such an approach are obvious; the only real drawback is
| that it would be slower than Qi booting the real kernel directly.  But I
| think that can be fixed too.

So long as the most common default path is fast, it's less critical that
it takes extra time to do something unusual like boot into partition 3
or whatever, I'm sure all this will fall out nicely one way or the
other.  What we need to resist though is any out of scope bloat in Qi

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


More information about the openmoko-kernel mailing list