[Top][All Lists]

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

RFC: New multiboot2 memory map entry type

From: Seth Goldberg
Subject: RFC: New multiboot2 memory map entry type
Date: Tue, 8 Nov 2011 21:25:15 -0800 (PST)
User-agent: Alpine 2.00 (GSO 1167 2008-08-23)


The multiboot2 spec currently says the following regarding memory map entries (tag type 6 in the multiboot2 info tag stack):

     u64     | base_addr         |
     u64     | length            |
     u32     | type              |
     u32     | reserved          |

   `size' contains the size of current entry including this field
itself. It may be bigger than 24 bytes in future versions but is
guaranteed to be `base_addr' is the starting physical address. `length'
is the size of the memory region in bytes.  `type' is the variety of
address range represented, where a value of 1 indicates available RAM,
value of 3 indicates usable memory holding ACPI information, value of 4
indicates reserved memory which needs to be preserved on hibernation,
value of 5 indicates a memory which is occupied by defective RAM
modules and all other values currently indicated a reserved area.
`reserved' is set to `0' by bootloader and must be ignored by the OS

The proposal is to add an additional type (value = 6) that denotes runtime memory that some firmware marks as required to be mapped to take advantage of services after the end of boot (UEFI is the canonical example). Without this information, it's impossible for a multiboot2-compliant OS to set up proper mappings for this memory.


reply via email to

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