[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Multiboot2 Amendment Proposal
From: |
Seth Goldberg |
Subject: |
Multiboot2 Amendment Proposal |
Date: |
Thu, 13 May 2010 14:09:53 -0700 (PDT) |
User-agent: |
Alpine 2.00 (GSO 1167 2008-08-23) |
Hi,
Below, please find a proposal for amending the multiboot2 spec to add some
new tags that will be useful for passing essential information to a
multiboot2-compliant OS. I welcome your comments.
Thanks,
--S
-------------------8<-----------------------
@(#)mb2_amendment.txt [1.9 10/05/13]
Multiboot 2 Amendment Proposal
------------------------------
1. Firmware-provided Data Structures
GRUB2 should be able to include information in the multiboot information
structure that specifies the addresses of certain firmware data structures
that the platform makes available. To support this, I propose 3 new tags,
__types 11-13__ with the following form:
a. UEFI System Table
+---------------------------+
u32 | type = 11 |
u32 | size = 8 + 8 |
u64 | UEFI System Table address |
+---------------------------+
b. ACPI Table
+---------------------------+
u32 | type = 12 |
u32 | size = 8 + 8 |
u64 | RSDP structure address |
+---------------------------+
c. SMBIOS Information
+--------------------------------------+
u32 | type = 13 |
u32 | size = 8 + 8 |
u64 | SMBIOS Entry Point structure address |
+--------------------------------------+
See section 2.1.1 of the SMBIOS Reference Specification (DSP0134)
version 2.6.1 (dated March 17, 2009) for details of the SMBIOS
entry point structure.
Note: On UEFI systems, the ACPI RSDP and SMBIOS entry point structure are
available via the UEFI System Table.
2. Memory tags for UEFI (or, more generally, "Firmware runtime support")
Some firmware types support providing extended information on memory
regions, including cacheability attributes as well as denoting
regions as being required for runtime firmware invokations.
To support runtime firmware invocations, the operating system must carefully
construct a proper virtual address environment. To construct the proper
environment for runtime firmware calls, the operating system needs to know
which memory areas firmware defines as required for runtime. This proposal
adds a new entry version and format to the existing tag 6 (Memory Map) to
identify these regions.
a. entry_version = 1
Memory regions that are described by system firmware with details
such as cacheability attributes and/or firmware runtime memory must
use this entry_version and format to convey the information to the
operating system.
+------------------------------------+
u32 | type = 6 (Memory Map) |
u32 | size = 8 + entry_size * <N> |
u32 | entry_size = 24 |
u32 | entry_version = 1 |
u64 | entry#1:base_physaddr |
u64 | entry#1:length |
u32 | entry#1:type |
u32 | entry#1:attributes |
... ...
u64 | entry#N:base_physaddr |
u64 | entry#N:length |
u32 | entry#N:type |
u32 | entry#N:attributes |
+------------------------------------+
attributes are a set of flags, bitwise-ORed together (the meaning of each
flag is that the memory region _supports_ the particular attribute (not that
one MUST use that attribute when accessing it)):
MB2_MEMATTR_CACHE_UC = 0x00000001 (Uncacheable)
MB2_MEMATTR_CACHE_WC = 0x00000002 (Write combining)
MB2_MEMATTR_CACHE_WT = 0x00000004 (Write through)
MB2_MEMATTR_CACHE_WB = 0x00000008 (Write back)
MB2_MEMATTR_PROT_WP = 0x00000100 (Write-protected)
MB2_MEMATTR_PROT_RP = 0x00000200 (Read-protected)
MB2_MEMATTR_PROT_XP = 0x00000400 (Execute-protected)
MB2_MEMATTR_FW_RUNTIME = 0x00010000 (Required for runtime firmware calls)
Note that the form of the entry is such that code that only knows how
to deal with entry_version 0 entries should still work (assuming that
code uses entry_size to traverse the entries).
3. Network information
Network information is noticeable absent from the multiboot specs. This
proposal aims to start its inclusion by enabling the boot loader to pass
information about the network configuration via a DHCP ACK structure (which
may be real or faked). This proposal adds a new tag, __type=14__.
b. DHCP ACK packet
+--------------------------+
u32 | type = 14 |
u32 | size = 8 + 4 + <N> | <N> is the packet length, rounded up to
u32 | flags | a 4-byte boundary.
u8[1]| DHCP ACK packet - Byte 1 |
... ...
u8[N]| DHCP ACK packet - Byte N |
+--------------------------+
The packet is stored in network byte order. Note that this can be a DHCPv4
or DHCPv6 packet. It is the consumer's responsibility to decode the packet.
flags are currently defined as:
0 = Real DHCP ACK (this DHCP ACK was received during system boot)
1 = Fake DHCP ACK (this DHCP ACK contains information that should be used
to statically configure the packet-specified NIC)