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 <[email protected]> > --- > 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 <[email protected]> > +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 > [email protected] _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
