To make it absolutely clear that runtime services cannot retain access to devices that are 'owned' by the OS, add a section spelling the situation out. Devices may be owned by the OS, or owned by runtime services, but not both.
Also rework the RTC clock section to allow for the RTC being inaccessible for exactly that reason.
Resolves: #1, "Need policy on sharing devices between FW and OS" Resolves: #14, "RTC should be optional"
Signed-off-by: Grant Likely grant.likely@arm.com --- source/chapter2-uefi.rst | 33 +++++++++++++++++++++++++-------- 1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 05230d2..1f37944 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -143,17 +143,34 @@ 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.
-Real-time Clock ---------------- +Runtime Device Mappings +----------------------- + +Firmware shall not create runtime mappings, or perform any runtime IO that will +conflict with device access. +Normally this means a device may be controlled by firmware, or controlled by +the OS, but not both. +e.g. If firmware attempts to access an eMMC device at runtime then it will +conflict with transactions being performed by the OS. + +Devices that are provided to the OS (i.e., via PCIe discovery or ACPI/DT +description) shall not be access by firmware at runtime. +Similarly, devices retained by firmware (i.e., not discoverable by the OS) +shall not be accessed by the OS. + +Only devices that explicitly support concurrent access by both firmware and an +OS may be mapped at runtime by both firmware and the OS.
-The Real-time Clock must be accessible via the UEFI runtime firmware, and the -following services must be provided: +Real-time Clock (RTC) +^^^^^^^^^^^^^^^^^^^^^
-- GetTime() -- SetTime() +In an embedded system design, it may not be possible to dedicate the RTC to +runtime services. e.g., The RTC may be on a shared I2C bus which runtime +services cannot access because it will conflict with the OS.
-It is permissible for SetTime() to return an error on systems where the -Real-time Clock cannot be set by this call. +Firmware must provide the UEFI GetTime() and SetTime() runtime service calls, +but if an RTC isn't present, or cannot be accessed at runtime, then both calls +shall return EFI_DEVICE_ERROR.
UEFI Reset and Shutdown -----------------------
On Thu, Jul 05, 2018 at 12:09:23PM +0100, Grant Likely wrote:
To make it absolutely clear that runtime services cannot retain access to devices that are 'owned' by the OS, add a section spelling the situation out. Devices may be owned by the OS, or owned by runtime services, but not both.
Also rework the RTC clock section to allow for the RTC being inaccessible for exactly that reason.
Resolves: #1, "Need policy on sharing devices between FW and OS" Resolves: #14, "RTC should be optional"
Signed-off-by: Grant Likely grant.likely@arm.com
source/chapter2-uefi.rst | 33 +++++++++++++++++++++++++-------- 1 file changed, 25 insertions(+), 8 deletions(-)
diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 05230d2..1f37944 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -143,17 +143,34 @@ 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.
-Real-time Clock
+Runtime Device Mappings +-----------------------
+Firmware shall not create runtime mappings, or perform any runtime IO that will +conflict with device access. +Normally this means a device may be controlled by firmware, or controlled by +the OS, but not both. +e.g. If firmware attempts to access an eMMC device at runtime then it will +conflict with transactions being performed by the OS.
+Devices that are provided to the OS (i.e., via PCIe discovery or ACPI/DT +description) shall not be access by firmware at runtime. +Similarly, devices retained by firmware (i.e., not discoverable by the OS) +shall not be accessed by the OS.
+Only devices that explicitly support concurrent access by both firmware and an +OS may be mapped at runtime by both firmware and the OS. -The Real-time Clock must be accessible via the UEFI runtime firmware, and the -following services must be provided: +Real-time Clock (RTC) +^^^^^^^^^^^^^^^^^^^^^ -- GetTime() -- SetTime() +In an embedded system design, it may not be possible to dedicate the RTC to
^^^^ Perhaps insert: the RTC may not be implemented or,
I know we acknowledge that the RTC may not be present in the next paragraph but its hard to read the opening paragraph without an early admission that RTC is optional ;-).
Other than that:
Reviewed-by: Daniel Thompson daniel.thompson@linaro.org
+runtime services. e.g., The RTC may be on a shared I2C bus which runtime +services cannot access because it will conflict with the OS.
-It is permissible for SetTime() to return an error on systems where the -Real-time Clock cannot be set by this call. +Firmware must provide the UEFI GetTime() and SetTime() runtime service calls, +but if an RTC isn't present, or cannot be accessed at runtime, then both calls +shall return EFI_DEVICE_ERROR. UEFI Reset and Shutdown
-- 2.13.0
Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
boot-architecture@lists.linaro.org
-
Daniel Thompson -
Grant Likely