Re: Multiboot2 Suggestions

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 8124 bytes --]

Brendan Trotter wrote:
> Hi,
>
> 2010/3/28 Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com>:
>   
>> 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 kernel can read data bits, stop bits, parity and divisor from
registers itself. I think it's more useful to supply a base frequency
since there are a lot of "almost compatible" cards which differ only in
base frequency.

> the IRQ number (if known/used by the boot loader) and the protocol
> being used (ASCII, VT100, etc).
I think it's more useful to supply directly usable strings termcap
strings rather than an abstract ID
>  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. 
I think it's more useful to have an I/O selector since yeeloong serial interface is basically the same, just attached differently

I think we need following fields:
1) I/O space selector (e.g. 0 = 32-bit MMIO, 1 = 64-bit MMIO, 2 = i386 I/O)
2) IRQ type selector (0 = None, 1 = standard platform interrupt)
3) 16-bit padding
4) address in I/O space (up to 64-bits)
5) Base frequency in Hz (32-bit)
6) IRQ (32-bit or even 64-bit since it's not excluded some platforms would use 64-bit IRQ ids, though I'm not aware of such).




> "telnet+ethernet"
It would need network tag first
> 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).
>   
Console flags tag is for this
> 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.
>   
Processing such a selector may prove as difficult as setting up a
console based on console tags. So I doubt its usefullness
> 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).
>   
Everything not said explicitly is undefined. However I would like to add
a sentence that some basic PCI initialisation OS usually expects and
which is done by firmware to be present.
> 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".
>   
Where bootloader gets memory map from isn't part of specification and I
see no reason to change that
> The "mem_upper/mem_lower" tag should removed from the specification.
>
>   
If more people speak against this tag then yes.
> 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".
>   
What's the difference between type 2 and "type 5"
> 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.
>   
kernel should know itself what it asked bootloader to do. MBI now is a
single chunk. Further than that there are only elf section tag and
module tags which refer to external memory. I think it should be easily
trackable now.
> 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.
>
>   
I agree that current tag is quite useless but I'm not sure how to do a
new one cleanly
> 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.
>   
I added a remark to Terminology section but I think that "Initial
module" will be more confusing.
> 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.
>
>   
Only the ones OS image explicitly declared as required.


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]