qi-bootmenu / qi-bootmenu-system

qi-bootmenu is a second stage userspace bootloader which scans the available devices (SD card and NAND normally) for bootable systems, displays a nice looking GUI and then loads the selected image via kexec. It was originally intented to be used with Qi a minimalistic bootloader for Openmoko phones, thus it's name. This boot menu application is embedded into a stripped down kernel + initramfs which is loaded by the first stage bootloader (Qi) and can be generated by a couple of shell scripts called qi-bootmenu-system.

What is wrong with uboot?

uBoot is a bloated over complicated piece of software which tries to do all sort of things which it shouldn't, in contrast Qi is a very lightweight bootloader which follows the basic Unix philosophy of doing one thing and doing it well. In case of a bootloader that is to load the kernel as fast as possible. As a consequence of this goal it doesn't bother to initialize video output and thus doesn't provide a user interface in the traditional sense. This keeps the bootloader code relatively simple. Except for the access to I/O devices and filesystems to read the kernel from there are no drivers which need to be maintained in both the kernel and the bootloader.

However users nowadays expect a comfortable way to chose which system image to boot and that is where qi-bootmenu comes in. By moving the complexity out of the bootloader into userspace things become much easier one could for example load a kernel from an exported NFS/TFTP server over a WPA encrypted WLAN connection something which you surely don't want to deal with in a bootloader.


GTA02 / Freerunner

Source Tarballs


You can always fetch the current codebase from the following git repositories.

If you have comments, suggestions, ideas, a bug report, a patch or something else related to either qi-bootmenu or the build scripts then feel free to write to the distro devel mailing list or contact me directly mat[at]brain-dump.org.


After downloading the kernel and bootloader they can be flashed to your device like any other distribution with dfu-util.


The initscripts of qi-bootmenu-system are checking /proc/cmdline for a variable called qi-bootmenu-args and pass it to qi-bootmenu upon it's execution. This can be used to tweak the behaviour of the boot menu application via first stage bootloader arguments. Currently the flash partition /dev/mtdblock6 is ignored using this method.


If you want to rebuild the kernel + initramfs you will need an armv4tl uclibc cross toolchain add it's bin subdirectory to your $PATH and run the build.sh shell script from qi-bootmenu-system. Check out the README from the source tarball for detailed instructions.

Rescue System

The initramfs also contains the dropbear ssh server and busybox which can be used as a rescue system to fix certain things on the SD-card. Configure usb networking as usual and ssh into your phone, by default the ssh server is configured to allow logins with empty passwords.


Why didn't you just use kexecboot or another existing project?

At the time I looked at them they didn't have touchscreen support and I wanted to build upon the EFL stack. See also this thread for some early early history of the project.

Why do I have to use a special toolchain to build the initramfs?

In order to save some space and thus speed up the boot process the initramfs is uclibc based. The openmoko toolchain however is built against glibc by default thus you need another one.


qi-bootmenu screenshot


Below are some links which are in one way or another related to qi-bootmenu / qi-bootmenu-system.


qi-bootmenu and the build scripts are both released under the GNU GPL.