On 25/09/2018 14:02, Peter Robinson wrote:
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?
I'm kind of going on the assumption that if it is in the UEFI spec, and is uncontroversial then just leave it unmentioned. However, if anyone feels strongly about it, then I'll add the UEFI Spec reference.
Signed-off-by: Grant Likely grant.likely@arm.com
Reviewed-by: Peter Robinson pbrobinson@gmail.com
Thanks, g.
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