[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Revised Amendment

From: Seth Goldberg
Subject: Revised Amendment
Date: Thu, 20 May 2010 17:32:38 -0700 (PDT)
User-agent: Alpine 2.00 (GSO 1167 2008-08-23)


I've revised the UEFI System Table portion of my previous amendment proposal to include flags that specify a 32- or 64-bit UEFI system (it's essential to know this if the OS is 64-bit and will be doing EFI Runtime calls). Vladimir suggested that instead of flags in this tag, another tag should be created that specifies the firmware type and architecture. I'm OK with either way.



@(#)mb2_amendment.txt [1.10  10/05/20]

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 + 12             |
   u64  | UEFI System Table address |
   u32  | flags                     |

   flags are (mutually-exclusive):
   GRUB_UEFI_INFO_UEFI32 = 0x00000001
   GRUB_UEFI_INFO_UEFI64 = 0x00000002

   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)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]