On Saturday 11 February 2006 01:51, Pavel Cahyna wrote:
> On Wed, Dec 28, 2005 at 05:25:34PM +0100, Julio M. Merino Vidal wrote:
> > Hi all,
> >
> > [ I'm not sure if this is the correct list to send this message or if it
> >   should have gone to port-i386... ]
> >
> > The GRUB [1] developers came up with the idea of designing a
> > "standard" protocol between boot loaders and OS kernels, known
> > as the Multiboot Specification [2] (I'll use MB for simplicity).  The
> > idea behind this protocol is to enable any MB-compliant boot loader
> > to execute a MB-compliant kernel without knowing any of its
> > internal details.  (This way, you'd install your boot loader of choice
> > and have it load any OS without "dirty tricks".)
> >
> > I think the idea is quite interesting and it could simplify the boot
> > process on machines with multiple OSes installed in them (think of
> > chainloading several bootloaders, one after the other).  This is
> > why I've spent the last two days trying to adapt the NetBSD kernel
> > to support MB.
> >
> > Basically, the following is needed:
> >
> > - Add a little header within the first 8K of the kernel.
> > - Add some new code to process the MB information structure passed
> >   by the loader and generate the appropriate information required by
> >   the NetBSD kernel (aka, bootinfo structures and such).
> > - Fix a bug in GRUB, heh.
>
> I think this bug
> (https://savannah.gnu.org/bugs/?func=detailitem&item_id=15590) is more a
> deficiency in NetBSD. The ELF format has the ability to tell the boot
> loader where the program should be loaded (the p_paddr field, see PhysAddr
> in the output of readelf). But the NetBSD kernel has this field set to the
> virtual address, which is incorrect. Instead of using a not very well
> defined feature of the multiboot specification, why not use a standard
> way? If the paddr fields are set correctly, unpatched grub (from Debian
> 3.1) can load a multiboot NetBSD kernel.

Thanks for the info.  But note that NetBSD also uses the Multiboot
header to reserve some extra space after the BSS so that it can later
copy the symbol table there.  It tells the boot loader that the
BSS is actually longer than it is so that the loader will leave that
space untouched (grep for MULTIBOOT_SYMTAB_SPACE).  How could we do
this (without reserving space in the data section, that is)?

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>
The Julipedia - http://julipedia.blogspot.com/