Brendan Trotter wrote: > Hi, > > 2010/3/28 Vladimir 'φ-coder/phcoder' Serbinenko <phco...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel