Coreboot multiboot breakage. Splitting of multiboot port

Coreboot multiboot breakage. Splitting of multiboot port

[Vladimir 'φ-coder/phcoder' Serbinenko]

[-- Attachment #1: Type: text/plain, Size: 303 bytes --]

Hello, I discovered that coreboot gives a chunk of 0xff instead of
correct mbi which breaks grub2. So I decided to split multiboot and
coreboot ports and now coreboot port uses LBIO. Please retest bzr trunk
if you were hitting coreboot issues

--=20
Regards
Vladimir '=CF=86-coder/phcoder' Serbinenko



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 293 bytes --]

Multiboot2 Amendment Proposal

[Seth Goldberg]

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)