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 > _______________________________________________ devel mailing list devel@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/devel
