Re: RFC: New multiboot2 memory map entry type

["Vladimir 'φ-coder/phcoder' Serbinenko" <phcoder@gmail.com>]

On 09.11.2011 06:25, Seth Goldberg wrote:
> Hi,
>
> 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
> image.
>
>
>  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.
Fine with it. Can you supply the patch for texinfo and GRUB?
>
>  --S
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko