Multiboot2 Suggestions

[Brendan Trotter]

Hi,

2010/3/28 Vladimir 'φ-coder/phcoder' Serbinenko <address@hidden>:
> Also I'm aware that at least some people want more tags. Feel free to
> propose new ones.
> In short all ammendment ideas are welcome.

Here's my list.. :-)

1) If GRUB was using a serial port as a console device (e.g. on a
headless system) it'd be nice if the OS could continue using the same
serial port with the same configuration instead of resetting the
serial port, etc. A new tag (for 80x86, "8250/6550 compatible" serial
ports) would include base I/O port, the serial line configuration
(e.g. 8 data bits, no stop bit, no parity), the baud rate (e.g. 9600),
the IRQ number (if known/used by the boot loader) and the protocol
being used (ASCII, VT100, etc). If the boot loader doesn't know which
IRQ the serial port uses (e.g. it uses polling) then it sets the IRQ
number to 0xFFFFFFFF. Where the serial port has a different interface
(e.g. if the serial port uses MMIO or if it's not "8250/6550
compatible") a different tag with different fields are used to
describe it. The same idea should be used for any other console device
in future. For example, if a boot loader supports parallel ports or
"telnet+ethernet" or something in future then a new tag describing it
is created; and if a boot loader supports new protocols for existing
devices then they should added to the documentation (e.g. if a boot
loader supports a Braille terminal connected to serial port, then a
new protocol type is added to the existing serial port tags).

2) The "OS image format" information should be expanded, so that the
OS can tell the boot loader if it supports "8250/6550 compatible"
serial ports (and which protocols), and any other console devices (for
the same reason the "OS image format" already has flags, etc for
video).

3) There should be an (optional?) "critical error notification method"
tag that tells the OS which method/s it can/should use to tell the
user it encountered a problem before it was able to setup it's console
output. For example, can/should the OS return to the boot loader, or
use the "PC speaker" to beep, or make a PS/2 keyboard's LEDs flash, or
something else.

4) The section on "Machine State" is missing lots of information, and
needs to indicate the state of *all* hardware on all architectures
(regardles of firmware type). For example; for 80x86/PC it should say
that PCI devices are left in an undefined state (so that the boot
loader is not responsible for configuring PCI devices if the firmware
didn't for any reason), except for any PCI device that is indirectly
mentioned in the multi-boot information (e.g. if there's a serial port
tag then the OS can assume that serial port is configured, if there's
a video information tag then the OS can assume the video cards is
configured, etc).

5) The boot loader should always provide a "memory map". If the boot
loader is unable to get a memory map from the firmware then the boot
loader constructs a fake memory map from any/all information it can
find, including known areas that aren't RAM. For e.g. on "80x86 BIOS"
if "int 0x15, eax=0xE820" isn't supported, then other BIOS functions
are used to find usable RAM and the boot loader creates an entry that
marks the area from 0x000A0000 to 0x000FFFFF as "system" or "unknown".
The "mem_upper/mem_lower" tag should removed from the specification.

6) For any areas that aren't mentioned in the memory map, the OS can
assume these areas are safe to use when configuring memory mapped PCI
device's BARs. For 80x86 this means that if "int 0x15, eax=0xE820"
leaves holes in the area from 0x000A0000 to 0x000FFFFF (which is
almost always the case) then the boot loader creates entries that
describe these areas as "unknown", so that the area/s are mentioned in
the memory map and the OS doesn't assume the area can be used for PCI
devices.

7) The memory map needs more "area types". Any RAM that is reported by
firmware as faulty should use "area type 5" so that the OS can know
that some RAM is faulty, and (for e.g.) could tell a system
administrator about it. Also, "area type 0xFFFFFFFF" should be used
for "unknown", as this allows the OS to determine the difference
between "boot loader doesn't know what the area is" and "boot loader
does know what the area is but the area type is defined in a newer
version of the multi-boot specification".

8) Any RAM that is not immediately usable by the OS should not be
reported as "usable RAM" in the memory map. An example of this is the
"ACPI reclaimable" area (which is RAM that isn't usable until the OS
has finished using the ACPI tables). RAM used to store the multi-boot
information, RAM used to store the "kernel" and RAM used to store any
modules should be treated in the same way. I suggest using "area type
0xFFFFFFFE = RAM used for multi-boot information" and "area type
0xFFFFFFFD = RAM used for kernel/modules". This makes it much easier
to write a kernel's early initialisation code, because it can use RAM
without worrying about trashing data that is needed by the kernel/OS
later.

9) The "boot device" tag needs to be revised. If the firmware was not
"PC BIOS" it doesn't make any sense; and even if the firmware was "PC
BIOS" the OS is unlikely to care (and there's cases where the BIOS
device number still doesn't make sense if the OS does care - e.g. "El
Torito" boot CD emulating a floppy disk or hard disk). The "boot
device" tag should be removed, and (potentially) replaced by one or
more new tags that describes how the boot device is accessed - e.g.
one tag for "PCI_bus/device/function then controller_device_number and
partition", another tag for "PCI_bus/device/function then
protocol/IP_address/port", etc.

10) The word used for "kernel" should be changed. There is currently
no reason why the boot loader couldn't be used to load an extra (OS
specific) stage which in turn starts (one of) the OSs real kernel/s;
and no reason why the real kernel/s couldn't be loaded by the boot
loader as a module. Unfortunately, because the specification uses the
word "kernel" people who are new to OS development and/or multi-boot
make the mistake of assuming that "kernel" must be the OS's kernel. I
propose the world "kernel" should be changed to "initial module" (or
something else) to avoid confusion.

11) The multi-boot specification should say which tags are required
(e.g. "boot loader name", "memory map"); which tags must be present
under certain circumstances (e.g. "serial port" must be present *if*
the boot loader used a serial port as a console device); and which
tags are optional (and may be included or omitted by the boot loader).
For the current draft this is unclear.


Cheers

Brendan