[RFC] Qi Bootmenu

Sander van Grieken sander at 3v8.net
Thu Oct 8 23:55:06 CEST 2009

On Thursday 08 October 2009 22:50:00 Marc Andre Tanner wrote:
> Goals
> =====
>  - The user should be able to select which image to boot from
>    (surprised heh ;)

I like this idea. Right now the U-boot menu is fixed and not easy to change, but with this 
idea the available images can be dynamically scanned, and also the kernel command line can 
be moved from the u-boot environment to the image itself, in a file or somesuch. You can 
even define multiple kernel command lines and show them as a sub-option to an image, e.g. 
to be able to select verbose logging when needed.

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

Yep, nice, that would free the flash partition I keep for this.

>  - 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
>    approval.
>    Maybe the idea to use elementary is overkill but what are the
>    alternatives?

Maybe just use evas, ecore and libpng (and their deps). You'd then have to do the whole 
GUI programmatically, because you'd only have a canvas and will have to do some more 
housekeeping yourself, but how fancy do you want a bootselector to be? :)

An alternative would be to look for a really minimal graphical toolkit that even has a 
smaller memory footprint than E.

Also compile the bunch above statically, It'll show in startup speed.

> Comments and/or contributions are welcome and appreciated.

There you have it :)


More information about the devel mailing list