On Mon, Sep 24, 2018 at 2:54 PM Grant Likely grant.likely@arm.com wrote:
The UEFI spec already covers the requirements on the runtime memory map. No need to have a whole section on it here.
Is it worth just referring to the relevant section in the UEFI spec?
Signed-off-by: Grant Likely grant.likely@arm.com
Reviewed-by: Peter Robinson pbrobinson@gmail.com
source/chapter2-uefi.rst | 23 ----------------------- 1 file changed, 23 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 7fd8aa6..6f7d260 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -125,29 +125,6 @@ EL1 or EL2, with appropriate virtual address mappings. When called, subsequent runtime service calls must be from the same Exception level.
-Runtime Memory Map
-Before calling ExitBootServices(), the final call to GetMemoryMap() returns a -description of the entire UEFI memory map, that includes the persistent Runtime -Services mappings.
-After the call to ExitBootServices(), the Runtime Services page mappings can be -relocated in virtual address space by calling SetVirtualAddressMap(). -This call allows the Runtime Services to assign virtual addresses that are -compatible with the incoming Operating System memory map.
-A UEFI runtime environment compliant with this specification must not be -written with any assumption of an identity mapping between virtual and physical -memory maps.
-UEFI operates with a 4K page size. With Runtime Services, these pages are -mapped into the Operating System address space.
-To allow Operating Systems to use 64K page mappings, UEFI 2.7, constrains all -mapped 4K memory pages to have identical page attributes, within the same -physical 64K page.
Runtime Device Mappings
-- 2.13.0
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com