Re: [RFC] multiboot ammendment firmware info

[Seth Goldberg]

Quoting Vladimir 'phcoder' Serbinenko, who wrote the following on Tue, 1...:

> Hello I propose to define following additional structures for multiboot:
> If flags[11] is set the field in addresses 88-95 contains an address
> of RSDT as defined in ACPI specification
> If flags[12] is set the field in addresses 96-103 contains an address
> of SMBIOS anchor as defined in DMI specification

 Do you want these as separate flags, or do you want to define 1 new flag to 
indicate addresses 88-95 contains a pointer to a linked list of firmware table 
structures, each describing a specific table and how to find it (I know you're 
not a fan of indirection here -- I'm thinking of conserving flag bits).


> If flags[13] is set 2 fields are defined on addresses 104-107 resp 108-116
> First field is firmware type
> 0 - Unknown firmware or firmware unavailable. In this case only
> possible communication with firmware if any is possible only through
> multiboot information (e.g. vbe control pointer). Second field is in
> this case invalid
> 1 - Coreboot. Does coreboot provides any services other than vbe to
> make distinguishing between Coreboot and no firmware wothy?
> 2 - BIOS. 16-bit mode BIOS interrupts are available. Second field is invalid
> 3 - 32-bit OFW. Second field contains OFW call handle
> 4 - 64-bit OFW. Second field contains OFW call handle
> 5 - 32-bit EFI. Second field contains pointer to EFI system table.
> 6 - 64-bit EFI. Second field contains pointer to EFI system table.
> All other values are reserved for future expansion

  Looks good to me.

 --S