[RFC] Qi Bootmenu

Marc Andre Tanner openmoko at brain-dump.org
Thu Oct 8 22:50:00 CEST 2009

Hi all,

I have been lurking around on various openmoko mailing lists for quite 
some time (about 1.5 years) but so far I didn't have the time to actually 
contribute anything useful because of study and work related activities. 
However during the last few days I actually had some time to waste.

I therefore looked around for possible projects and found the boot menu
thingy which interested me for quite some time because it involves various
different system parts.

I have seen in the mailing list archives that some people have actually 
already started to work on projects[0] with similar goals but as far as I know 
they weren't really finished and/or customized for the Freerunner.
The closest thing to a working solution is probably kexecboot[1].

So here are my random thoughts on the subject, comments are appreciated.


 - The user should be able to select which image to boot from 
   (surprised heh ;)

 - The image could also provide a minimal system rescue environment
   that is a sshd server which allows remote access to fix certain

 - In order for this to be useful it needs to be fast. Nobody wants
   to wait 10+ seconds just to select which image to boot. Speed is
   therefore the most important factor.


 - The whole system could be packaged into an initramfs

 - Ideally I would like to store the boot menu image in NAND flash. 
   This would ensure that it is always around and different SD
   based images could be booted with it.

   The boot sequence would look something like this:

    - Bootloader (Qi) loads minimal kernel

    - kernel extracts initramfs /init is executed

    - application scans for system images on SD card, presents boot menu

    - selected kernel is started via kexec

Bootloader (Qi)

 - I would like to change the default boot sequence to first look
   for the special bootmenu image in the kernel NAND flash partition, 
   if this is not found the boot sequence should proceed with the SD card.

   The user can of course still use the hardware buttons to skip the 
   NAND boot and by pass the bootmenu system.

   The NAND kernel partition is 8MB large so we need to fit the kernel +
   initramfs in there.


 - optimized for size just the absolutely necessary tings
   should be compiled in. The gta02_micro_defconfig will be starting
   point for this. Is it still up to date/maintained?

 - compress? Recent kernels can be compressed using LZMA

   Question is if this would actually speed up anything?
   Answer depends on where the bottleneck is in data throughput
   or computing power. What is the expected data transfer rate
   from NAND flash?

 - disable console output completely


 - uClibc

 - stripped down busybox

 - kexec-tools

   They only support zImages however distros ship uImages so
   we would either have to strip off the uImage header which is
   probably slow or add uImage support to kexec-tools.

 - dropbear sshd

 - bootmenu application (see next section)

Bootmenu application

 - should be something like kexecboot, however It should be finger friendly.

 - functionality should be something like this (taken from kexecboot):

    - read available filesystems from /proc/filesystems
    - read available partitions from /proc/partitions
    - try to mount each partition, search for zImage in /boot
    - present menu
    - kexec selected kernel

 - GUI based on elementary with framebuffer support?

   In theory this would be the best solution because we would
   use the same technology as in a normal system just with a 
   different backend.  This should ensure that it's actually
   finger friendly. Although text entry remains a problem 
   because the illume keyboard can't be used. But I hope that
   text entry won't be necessary anyway (no kernel command line
   changes through the GUI, sorry ;) In practice I don't know 
   how mature the framebuffer backend actually is and it has 
   quite a few dependcies[2]:

    * eina
    * eet
          o zlib
          o libjpeg
    * evas
          o freetype
    * ecore
          o ecore-file
          o ecore-evas
          o ecore-input
          o ecore-job
          o ecore-txt
          o libiconv (functionality can be provided by uClibc)
          o tslib
    * edje
          o embryo
          o lua
    * libpng
   I have cross compiled all this and without any special optimisation
   (I just disabled everything in ./configure which seemed not critical)
   the whole system is about 6-7MB large this is without the kernel.

   I am not familiar with the EFL code base but what I have seen
   so far seems like it isn't really optimized for size. So there could
   be some potential although it would require some work and upstream 

   Maybe the idea to use elementary is overkill but what are the 

Proof of Concept

As a proof of concept I started to write a simple shell script (well
in the beginning it was simple in the meantime it evolved in kind of 
mini build system, maybe something like OpenWRT could be used but I
wanted a simple solution where I actually understand what's going on) 
which downloads and cross compiles everything with an uclibc based 

So far I have cross compiled all the components mentioned in this 
post the result is about 6-7MB large.

I then tried to run the elementary dialog application from the 
elementary wiki page[3] in a chrooted system and this works
(although there seems to be a problem with the touchscreen which
doesn't quite work right and sometimes even causes a segfault).

Another issue is that I currently don't get any console output when
booting from flash with Qi. Although I've added loglevel=8 to Qi's
kernel parameters and recompiled+reflashed. Something with the init 
script and/or missing device nodes might be the problem.

If you want to help then download the scripts and read the README
file of the source tarball.


Once you have a rootfs.tar.gz file generated (after ./build.sh &&
./initramfs.sh && ./package.sh) copy it over to your Freerunner.
Bind mount /proc and /dev to the corresponding directories and try 
it out:

 mkdir rootfs
 tar -C rootfs -xzf rootfs.tar.gz 
 mount -t proc /proc rootfs/proc
 mount -o bind /dev rootfs/dev
 chroot rootfs /usr/bin/ash
 export ELM_ENGINE=fb
 export ELM_FONT_PATH=/usr/share/fonts
 dialog "Hello world, works?"

My current plan is to fix the initramfs console output (ideas what might
be wrong?). Next step is to launch the elementary dialog app from the init
script. Then shrink/optimize everything until the boot time is acceptable 
(or give up if we don't reach that point). And only then start to program 
the elementary based kexecboot replacement. This would be my first EFL
application which means I will have to do some research first.

Comments and/or contributions are welcome and appreciated.

Happy Hacking,

[0] http://thread.gmane.org/gmane.comp.handhelds.openmoko.devel/2011
[1] http://git.linuxtogo.org/?p=groups/kexecboot/kexecboot.git
[2] http://www.brain-dump.org/blog/entry/132/On_the_way_towards_a_minimal_elementary_based_boot_system
[3] http://trac.enlightenment.org/e/wiki/Elementary
 Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0

More information about the devel mailing list