[RFC] Qi Bootmenu

Al Johnson openmoko at mazikeen.demon.co.uk
Wed Nov 18 23:30:17 CET 2009


I'm certainly interested as multibooting is the reason I stick with uboot. I 
won't have a chance to look at it before next week though. 

On Wednesday 18 November 2009, Marc Andre Tanner wrote:
> 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
>    upstream git)
> 
>  - 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
>    is used
> 
>  - added some init script which should set up usb networking and start
>    dropbear
> 
>  - 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:
> 
>    
>  http://lists.impactlinux.com/pipermail/firmware-impactlinux.com/2009-Novem
> ber/000443.html
> 
> My current build scripts can be found at:
> 
>   git://repo.or.cz/qi-bootmenu-system.git
> 
> 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.
> 
>   git://repo.or.cz/qi-bootmenu.git
> 
> 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
>    from scratch.
> 
>  - 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.
> 
> Thanks,
> Marc
> 




More information about the devel mailing list