OSDev.org

Posted: **Thu May 29, 2008 3:01 am**

kexec-loader is a Linux-based bootloader which has a target selection menu and other features such as GRUB menu.lst+device.map support, it loads the selected kernel using kexec and the TODO for v1.4 is code cleanup and a command-line.

It aims to support multiboot kernels since kexec claims to, although booting Exclaim apparently doesn't work, so testing of various multiboot kernels would be appreciated.

http://www.solemnwarning.net/kexec-loader/
http://www.solemnwarning.net/kexec-loader/release-images/kexec-loader-1.3.1.img.gz

Any comments/suggestions?

Posted: **Thu May 29, 2008 4:24 am**

If I get a bit of time this evening I'll try poking pedigree in there and see what happens.

Does it support x64 too or just 32-bit?

Posted: **Thu May 29, 2008 4:39 am**

Just curious, what is the benefit of this over GRUB?

It surely can't be size... a 1.15MiB floppy image for the boot loader?

Posted: **Thu May 29, 2008 5:16 am**

Yayyak wrote:Just curious, what is the benefit of this over GRUB?

It surely can't be size... a 1.15MiB floppy image for the boot loader?

It uses kexec, so can load from any filesystem that linux supports. (I've been lurking in #exclaim where solemnwarning loiters)

Posted: **Thu May 29, 2008 7:34 am**

JamesM wrote:
Yayyak wrote:Just curious, what is the benefit of this over GRUB?

It surely can't be size... a 1.15MiB floppy image for the boot loader?
It uses kexec, so can load from any filesystem that linux supports. (I've been lurking in #exclaim where solemnwarning loiters)

And any device, the standard image supports PATA, SATA and USB mass storage

Posted: **Fri May 30, 2008 1:12 am**

It doesn't work well with higher half Multiboot kernels seemingly due to a kexec/kexec-tools bug - the sections in the ELF image are loaded to the correct physical location however it attempts to jump into the kernel at the virtual address, resulting in QEMU dying with "tried to execute code outside RAM or ROM".

Anyway, the benefit of kexec-loader is that it can boot off any device you configure the kernel to support. It's useful, for example, for booting off a CD or USB mass storage device if the BIOS doesn't support it.

Posted: **Fri May 30, 2008 2:42 am**

r293 commited to SVN with working command-line code!

kexec-loader-r293.img.gz

No docs yet, there's a "help" command though

Posted: **Fri May 30, 2008 5:06 am**

Does it support gzipped kernel images yet? Which binary formats are supported for the kernel image?

Posted: **Fri May 30, 2008 5:37 am**

It supports any kernel images which can be loaded by kexec-tools

Posted: **Fri May 30, 2008 2:16 pm**

Right, so we discovered on IRC that using a physical address as an entry point in a multiboot kernel isn't actually part of the Multiboot specification, however GRUB does have a workaround for it which is why it works. The kexec program from kexec-tools, however, does not support it, therefore tries to use the virtual address. To fix this I defined a symbol __phys_start which points to the physical entry address in the linker script, and set the entry point to it:

Code: Select all

ENTRY (__phys_start)
OUTPUT_FORMAT("elf32-i386")
OUTPUT_ARCH("i386")

VirtBase = 0xC0000000;
PhysBase = 0x100000;
PageSize = 0x1000;

SECTIONS
{
        . = VirtBase + PhysBase;
        __phys_start = _start - VirtBase;

This allows kexec-loader to load the kernel, and it still works in GRUB.

Also, I discovered that Linux uses hardware VGA scrolling, so output wasn't being displayed on the screen properly when control was passed to my kernel. In kexec-loader revision 297 there's a new configuration directive reset-vga which passes the --reset-vga option to kexec, which makes VGA output display properly.

EDIT: Image of r297: http://www.solemnwarning.net/kexec-loader-r297.img.gz