From: Stephen Early <[EMAIL PROTECTED]>
Subject: Problems with GRUB and the Multiboot standard
Date: Sat, 11 Sep 1999 14:57:53 +0100 (BST)
> The problems that I have with the standard are mainly that it is
> imprecise, and poorly worded in places.
If you send patches for them, that would be much better.
> XXX First paragraph: it's probably a good idea to constrain where a
> kernel image can be loaded; most boot loaders will be unhappy with
> images below 0x100000, for example. Specifying 0x100000 as the minimum
> link address would be good.
Probably.
> XXX Bit 16: GRUB gets this wrong; if the image is ELF then it ignores
> bit 16.
I'm afraid that this bug still remains in the current, but I'm not
planning to fix it in the near future, because I don't think any real
problem occurs due to it.
> XXX I suggest that you specify that the Multiboot information will
> always be below 640K, and that boot modules will always be loaded
> immediately after the kernel image. The kernel can then do a simple
> scan of the modules list to find out the lowest available address, and
> a scan of the memory list to find out how much contiguous memory is
> available there. This can be done in O(1) space, and the kernel can
> then start dynamic memory allocation in the area it's discovered.
Maybe that would be better, but I'm not sure. Anyway, the OSKit
already provides a convenient library to support the Multiboot
information, so it may be better that we leave it unchanged.
> XXX Bit 1: GRUB gets this wrong. GRUB-0.5 loaded from floppy, loading
> a Multiboot kernel from (hd0,2)/boot/mbtest sets the field to
> 0x00020000, which is obviously bogus. GRUB loaded from the boot sector
> of (hd0,2) gets it right, and sets the field to 0x8002ffff.
Thanks for your report. I've fixed this.
> The network bootloader I mentioned at the start of this message is
> 'Netboot'; see //http://www.han.de/~gero/netboot/
I have an unrelated question: What is the relationship between
Netboot and other network bootloader, such as NILO? I'm wondering why
there are two distinct projects for the same goal, though both are
GPLed.
----------------------------------------------------------------------
OKUJI Yoshinori <[EMAIL PROTECTED]> ^o-o^
http://duff.kuicr.kyoto-u.ac.jp/~okuji (in English) m /
