15. System Address Map Interfaces¶
This section explains how an ACPI-compatible system conveys its memory resources/type mappings to OSPM. There are three ways for the system to convey memory resources /mappings to OSPM. The first is an INT 15 BIOS interface that is used in IA-PC-based systems to convey the system’s initial memory map. UEFI enabled systems use the UEFI GetMemoryMap() boot services function to convey memory resources to the OS loader. These resources must then be conveyed by the OS loader to OSPM. See the UEFI Specification for more information on UEFI services.
Lastly, if memory resources may be added or removed dynamically, memory devices are defined in the ACPI Namespace conveying the resource information described by the memory device (see Memory Devices ).
ACPI defines the following address range types.
Value |
Mnemonic |
Save in S4 |
Description |
|---|---|---|---|
1 |
AddressRangeMemory |
Yes |
This range is available RAM usable by the operating system. |
2 |
AddressRangeReserved |
No |
This range of addresses is in use or reserved by the system and is not to be included in the allocatable memory pool of the operating system’s memory manager. |
3 |
AddressRangeACPI |
Yes |
ACPI Reclaim Memory. This range is available RAM usable by the OS after it reads the ACPI tables. |
4 |
AddressRangeNVS |
Yes |
ACPI NVS Memory. This range of addresses is in use or reserved by the system and must not be used by the operating system. This range is required to be saved and restored across an NVS sleep. |
5 |
AddressRangeUnusable |
No |
This range of addresses contains memory in which errors have been detected. This range must not be used by OSPM. |
6 |
AddressRangeDisabled |
No |
This range of addresses contains memory that is not enabled. This range must not be used by OSPM. |
7 |
AddressRangePersistent-Memory |
No |
OSPM must comprehend this memory as having non-volatile attributes and handle distinct from conventional volatile memory. The memory region supports byte-addressable non-volatility. NOTE: Extended Attributes for the memory reported using AddressRangePersistentMemory should set Bit [0] to 1 (see Extended Attributes for Address Range Descriptor Structure). |
8 - 11 |
Undefined |
No |
Reserved for future use. OSPM must treat any range of this type as if the type returned was AddressRangeRe served . |
12 |
OEM defined |
No |
An OS should not use a memory type in the vendor-defined range because collisions may occur between different vendors. |
13 to 0xEFFFFFFF |
Undefined |
No |
Reserved for future use. OSPM must treat any range of this type as if the type returned was AddressRangeRe served . |
0xF0000000 to 0xFFFFFFFF |
OEM defined |
No |
An OS should not use a memory type in the vendor-defined range because collisions may occur between different vendors. |
Platform runtime firmware can use the AddressRangeReserved address range type to block out various addresses as not suitable for use by a programmable device. Some of the reasons a platform runtime firmware would do this are:
The address range contains system ROM.
The address range contains RAM in use by the ROM.
The address range is in use by a memory-mapped system device.
The address range is, for whatever reason, unsuitable for a standard device to use as a device memory space.
The address range is within an NVRAM device where reads and writes to memory locations are no longer successful, that is, the device was worn out.
OSPM will not save or restore memory reported as AddressRangeReserved, AddressRangeUnusable, AddressRangeDisabled, or AddressRangePersistentMemory when transitioning to or from the S4 sleeping state.
Platform boot firmware must ensure that contents of memory that is reported as AddressRangePersistentMemory is retained after a system reset or a power cycle event.