Multiboot for ARM

Multiboot situation today (on x86 mostly)

There is a multiboot specification defined for x86 which defines a generic boot protocol to boot a kernel and give it some basic information about the system to get started easily. The aim of this specification was partly to ease development of new kernels by freeing them from the tedious burden of getting loaded properly and focus on the actual OS development.

Part of this specification is a way to present multiple binary images to a kernel, which the kernel can use at it's own discretion. Use-cases are initial RAM disks, firmware blobs, splash screens or a "poor-mans" filesystem.

The Xen hypervisor uses this facility on x86 to load the Dom0 kernel and an initial RAM disk beside the actual Xen hypervisor kernel. Grub as the predominant bootloader on x86 implements this protocol, so deployment of multi-boot capable kernels is easy on x86.

Multiboot on ARM ?

The multiboot specification in version 2 does not describe an ARM port, but talks only about x86 and MIPS. The actual "port" to ARM would be trivial (use r0 for %eax and r1 for %ebx, maybe r2 for device tree), but for several reasons this seems to be overkill:

multiboot v2 tags on x86

On x86 the multiboot information data structure is used as a mean to transport information from the bootloader to the OS. The multiboot spec v2 defines the following types of information passed from the bootloader to the OS:

  • tag 1: boot command line
  • tag 2: boot loader name
  • tag 3: modules
  • tag 4: basic memory information: lower and upper memory, only sizes
  • tag 5: BIOS boot device
  • tag 6: memory map
  • tag 7: VBE info
  • tag 8: framebuffer info
  • tag 9: ELF symbols
  • tag 10: APM table

multiboot v2 tag mappings to ARM

  • Tag 4, 5, 7 and 10 do not apply to ARM at all.
  • Tag 8 I am not sure about, I don't have any graphics on my devices and am not sure if this information would be used by ARM kernels at all.
  • Tag 9 seems to be for some early debugging only, I guess it is unused currently.
  • Tag 6 information (the memory map) is already provided via the device tree, and it wouldn't make sense to repeat this information here.
  • Tag 2 (bootloader name) is nice to have, but not required, I think.

So eventually it boils down to having command lines and modules information transported. On Linux we have the command line already in the device tree, also kind of a modules thing if you take initrd into account.

So implementing the multiboot protocol would actually end up having all the information twice, since we need the device tree anyway.

Also we need to pass a second blob from bootloader into the kernel. Trying to implement this in Xen actually showed that the whole approach is moot, as one would copy much code handling the device tree blob in memory (mapping, relocation) and move information from within there into the same data structures in Xen.

So why not just use what is already there (in terms of libfdt in u-boot and the kernels)? All we need to get Xen booted is some kind of device tree binding for binary images to be interpreted by the kernel (Xen for instance):

I'd suggest to come up with some "clever" compatible strings like:

/chosen {

  • module@0 {
    • compatible = "xen,linux-zimage", "xen,dom0-kernel", "boot,kernel", "boot,module";

AndrePrzywara/Multiboot (last modified 2013-09-04 09:13:44)