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.
Goals
=====
- 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
things.
- 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.
Overview
========
- 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.
Kernel
======
- 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
Userland
========
- 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
approval.
Maybe the idea to use elementary is overkill but what are the
alternatives?
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
toolchain.
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.
http://www.brain-dump.org/tmp/qi-bootmenu-system/qi-bootmenu-system.tar.bz2
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,
Marc
[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
_______________________________________________
devel mailing list
devel@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/devel
