[RFC] Qi Bootmenu
Marc Andre Tanner
openmoko at brain-dump.org
Wed Nov 18 13:10:29 CET 2009
On Thu, Oct 08, 2009 at 10:50:00PM +0200, Marc Andre Tanner wrote:
> Proof of Concept
Some updates on what I've done so far:
- ecore-con is no longer needed (It can be disabled during ./configure,
patch is in enlightenment svn)
- uclibc can be built with a minimal set of locale data (patch is in
- I streamlined freetype's configuration by disabling everything which
didn't seem necessary
- integrated openmoko kernel build, the om-gta02-2.6.31 kernel branch
- added some init script which should set up usb networking and start
- updated to latest FWL toolchain version, unfortunately the release
tarballs seem to have a problem I therefore uploaded the toolchain
which I' ve built and which seems to work here. For further
information see the my post to the FWL mailing list at:
My current build scripts can be found at:
It would be nice if someone could try it out by following the instructions
in the README and reporting back the results.
I also started a bootmenu application which scans the available partitions
for bootable images.
It doesn't yet include a GUI but Dave Ball started a prototype based on
evas which is basically option #2 from raster.
Things which I need to do:
- kexec doesn't have uImage support so either:
(a) implement it
(b) convince distros to also provide zImages
(c) strip the uImage header off at runtime with dd but this would
make it slower of course
- there seems to be a segfault in the color conversation code from evas
triggered by compiler optimizations (-O0 works everything else doesn't)
and the elementary dialog application. I have yet to check if this
also happens with the evas based GUI of qi-bootmenu.
- kernel config needs to be trimed down to the absolute minimum, don't
know whether it makes sense to look into gta02_micro_defconfig or start
- Qi's boot logic needs to be patched to load a custom kernel up on AUX
press instead of skipping one.
- actually build a decent GUI for qi-bootmenu
- Try random things to make it fast(er)...
- updating to 2.6.32 or backporting devtmpfs comes to mind because
it would make the call to mdev -s unecessary.
As always comments are appreciated.
Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
More information about the devel