Re: [RFC] multiboot ammendment firmware info

[Vladimir 'phcoder' Serbinenko]

On Tue, Sep 1, 2009 at 5:45 PM, Vladimir 'phcoder'
Serbinenko<address@hidden> wrote:
> 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
> 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 - 32-bit OFW. Second field contains OFW call handle
> 3 - 64-bit OFW. Second field contains OFW call handle
> 4 - 32-bit EFI. Second field contains pointer to EFI system table.
> 5 - 64-bit EFI. Second field contains pointer to EFI system table.
> All other values are reserved for future expansion
Sorry I forgot BIOS. So my proposition is:

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
Remark 1: firmware type only speaks about type and not quality of
firmware. Any firmware call may hang, crash, malfunction or corrupt
memory. Relying on firmware especially for non-firmware tasks is
discouraged
Remark 2: In case of EFI booter has to call EfiExitBootServices
Another subject for discussion - if OS wants to make calls to EFI from
protected mode it has to call set_virtual_address_map and for this it
needs information about memory occupied by firmware do we add an
additional pointer which contains an array of efi_memory_descriptors
describing just the firmware or do we try to add this information to
multiboot memory map?

> --
> Regards
> Vladimir 'phcoder' Serbinenko
>
> Personal git repository: http://repo.or.cz/w/grub2/phcoder.git
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git