Hello!
I wish to introduce kexecboot software here. It would be great to see kexecboot in list of Linaro supported projects.
Feel free to contact me about this software by email or on irc.freenode.net, #kexecboot channel. My nickname is Jay7.
---------------- Kexecboot is a C program able to scan the partitions on available devices, offering a graphical framebuffer menu and allowing user to select from which one to boot. Specifically, kexecboot creates the command line for kexec.
Typically kexecboot resides together with kexec in a small initramfs, embedded in a custom-tailored kernel compiled with support for initramfs and kexec system call. Both binaries are built static, linked against klibc to optimize size.
Flashed on NAND and launched as first kernel by the original bootloader, this solution gives following advantages:
* multi machine support: we build for many architectures using OpenEmbedded (tested on arm and x86/x86_64) * zImage and uImage support * easy customization: just add machine-specific workarounds (see Zaurus raw read of bootparams from NAND) * small size: complete linux-kexecboot_2.6.x image (initramfs + kernel) is about 1Mb (less with lzma patches) * easy boot choice: boot from SD/CF/NAND/... even if bootloader doesn't support it * multiple fs detection: we support many filesystems e.g. ext2/3/4, jffs2, reiserfs, vfat and more (ubifs is work in progress) * kernel upgrade: no need to flash the device (kernel is in /boot of removable media) * rapid testing: different distributions can live in separate partitions on the same device
Thus, kexecboot is an interesting solution for embedded linux distributions, which can just rely on kexecboot whithout having to consider what the real bootloader can and cannot do.
About customization, initially the program has been developed for Sharp Zaurus PDA (armv5te). For the machines of that family there is specific code reading bootparams directly from NAND, circumventing the obsolete bootloader which is incompatible with modern 2.6.x kernels. ----------------
We are sponsored by CELF in this year to do following work: 1.Write user's and developer's guides. 2.Extend architecture and filesystems support. MIPS arch support and UBIFS support will be added. 3.Improve debugging ability. We should allow users to have ability to look for debugging information without special hardware (serial cable e.g.). 4.Implement text-mode UI. We have already patches against one of old releases. This can be used later to use kexecboot UI over serial line or telnet/ssh connection. 5.Improve GUI. Make GUI more clean and eye-candy (fonts and icons). 6.Add ability to use multiple kernels on same partition. Current implementation allows only one kernel per partition.
List of accessible hardware: - Sharp Zaurus'es: C860, C1000, C3200, SL-5500, SL-6000; - TouchBook (waiting for order, donated by CELF for this device support work). - Ben NanoNote (waiting for delivery, donated by CELF for MIPS support work);
Links: * Current project home (down at this moment, we are looking for hosting): http://projects.linuxtogo.org/projects/kexecboot * Project git tree: http://git.linuxtogo.org/?p=groups/kexecboot/kexecboot.git * OpenEmbedded recipes: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/kexecboot
Hi Yuri,
On Fri, Jun 04, 2010 at 01:58:46PM +0400, Yuri Bushmelev wrote:
Links:
- Current project home (down at this moment, we are looking for hosting):
http://projects.linuxtogo.org/projects/kexecboot
- Project git tree:
http://git.linuxtogo.org/?p=groups/kexecboot/kexecboot.git
- OpenEmbedded recipes:
http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/kexecboot
What's the checkout address of the git tree? Can you update the gitweb to contain that information?
The project looks interesting, do you have numbers about how much it does delay the actual boot?
rsc
Hello, Robert!
Sorry, first mail gone direct to Robert :)
What's the checkout address of the git tree? Can you update the gitweb to contain that information?
Ah, sorry. You can checkout it by following command: git clone git://git.linuxtogo.org/home/groups/kexecboot/kexecboot.git
Not sure about gitweb. I'm not familiar with it and seems it's property of LinuxToGo.
The project looks interesting, do you have numbers about how much it does delay the actual boot?
kexecboot is interactive. So we can measure only time from cold start to dislpaying kexecboot interface. But this depends on FS/media quantity, quality and types and on kernel used.
We have not done any special test but we can do some on Zauruses today.
Hello!
The project looks interesting, do you have numbers about how much it does delay the actual boot?
Andrea Adami have done a quick test. You can look at bootlog here: http://fr.pastebin.ca/1877331
This is Zaurus SL-C860 with two empty NAND partitions, one CF card with one partition, one SD card with 3 partitions. Kexecboot binary was build with debug enabled. Initramfs was lzma-compressed.
According to this kexecboot does about 9 seconds of delay. First (kexecboot) kernel is booted in 6 sec. Kexecboot devices processing does about 1.5 sec. Next was: - menu sorting; - event devices processing; - displaying GUI; - some time to select boot item and kexec it.
Anyway there is place for some improvements and speed optimizations.
On Mon, Jun 07, 2010 at 04:26:10PM +0400, Yuri Bushmelev wrote:
The project looks interesting, do you have numbers about how much it does delay the actual boot?
Andrea Adami have done a quick test. You can look at bootlog here: http://fr.pastebin.ca/1877331
Great, thanks!
This is Zaurus SL-C860 with two empty NAND partitions, one CF card with one partition, one SD card with 3 partitions. Kexecboot binary was build with debug enabled. Initramfs was lzma-compressed.
According to this kexecboot does about 9 seconds of delay. First (kexecboot) kernel is booted in 6 sec. Kexecboot devices processing does about 1.5 sec. Next was:
- menu sorting;
- event devices processing;
- displaying GUI;
- some time to select boot item and kexec it.
Anyway there is place for some improvements and speed optimizations.
Hmm, that's pretty long. I'll see if I can collect some numbers from our experiments.
Regards, Robert
-
Robert Schwebel -
Yuri Bushmelev