Multiboot and NetBSD

[Julio M. Merino Vidal]

Hello,

I'm trying to adapt the NetBSD kernel to follow the Multiboot specification
(I'll shorten in to MB in the rest of this mail).  But, unfortunately,
I have found
several problems that make it quite difficult (and, by far, less powerful than
the native boot method).

The very first problem comes to a misfeature (or bug?) in GRUB-Legacy.
The MB spec says that ELF binaries can optionally have the 16th bit in
the MB header active.  If this happens, they can later specify explicit load
addresses and other interesting stuff.  The problem is that GRUB-Legacy
does not take into account any of these fields when the binary is ELF;
only when it's a.out.

I need this feature because the NetBSD kernel's text segment is mapped
into the 0xC0100000 virtual address but it must be loaded into the
0x00100000 physical address.  (It then "rebootstraps" itself after paging
is active and the virtual address is valid.)  Currently, GRUB insists in loading
it into the virtual address, so it raises a "won't fit" error.

This aside, I have some problems while parsing the MB info structure.
Possibly the most annoying is that the cmdline field is too GRUB-specific.
What do I mean?  At this moment, the kernel receives a verbatim copy of
the command line used in the boot loader.  This line includes the kernel
arguments (which is fine) but also includes the exact and GRUB-specific
syntax used to specify the boot file.

For example, I'm currently getting:

    (fd0)/netbsd -d

I want to get to the -d flag... how do I know where it is?  Do I have to skip
the first word or...?  What if there were spaces embedded in the kernel file
name, or in the device?  That part is specific to GRUB, so the kernel
shouldn't see it (at least not this way).

Similarly, I need to get the kernel's file name.  How do I safely derive it
from the cmdline field?  I could skip the (fd0) part, but that is also GRUB
specific.  It'd fail with any other MB boot loader if it changed the boot
syntax.

In order to fix this, two new fields could be added to the MB info structure:
kernel_file, containing the path to the file (/netbsd) relative to the fs
specified in boot_device; and kernel_options, containing all the flags that
were given to the kernel file (-d blah blah).

Then I'd like to propose another addition.  The NetBSD kernel receives a
hint from the boot loader which specifies where the console is.  For example,
if the boot loader was executed through a serial line, the kernel sees that
and also uses the serial line as the console; similarly, if the boot loader was
executed on the "BIOS screen", the kernel will use the video card and the
keyboard by default.  Of course, the kernel is free to bypass this suggestion
and do whatever it wants (e.g., if it lacks drivers), but this has proven to be
quite useful and simplifies things a bit.

This is impossible to do based on the current MB info structure (or at least
I can't see how).  And it is also impossible to do from NetBSD's side because
the kernel does not recognize boot options other than some simple flags
(such as the -d shown above) -- of course, I'd hack something for the MB
case, but that's ugly.  Therefore, what about adding three new fields:
- console_name: Either "physical" or "serial", for example.
- console_speed: Baud rate, if console_name=serial.
- console_addr: I/O address, if console_name=serial.

Note that, with a little patch to GRUB-Legacy, I'm already able to boot NetBSD
kernels with the MB "technique".  Also note that I haven't finished gathering
all the info it requires, so I may find other problems similar to the
above ones.

However, I'm not sure it will be accepted by the other developers given all
the drawbacks exposed above :-(

Any comments?

Thanks,

--
Julio M. Merino Vidal <address@hidden>
The Julipedia - http://julipedia.blogspot.com/
The NetBSD Project - http://www.NetBSD.org/