On 6/28/21 8:39 AM, Abner Chang wrote:
Jonathan Behrens <behrensj@... <mailto:behrensj@...>> 於 2021年6
月25日 週五 下午11:11寫道：
Any chance that we can ban EFI_UNSPECIFIED_TIMEZONE and/or require
that time is always UTC?
That depends on how do you implement GetTime/SetTime functions for the
platform. You can always not returning EFI_UNSPECIFIED_TIMEZONE in the
implementation and just return the offset to UTC for the local time.
Abner
The way that UEFI reports local time zones is unsatisfactory:
There is an offset to UTC and a daylight savings flag but this does not
allow to derive on which day daylight saving switches (you could be on
the southern or on the northern hemisphere) nor the daylight savings
offset which historically has been one hour or two hours.
Furthermore many RTC chips do not store timezone related information.
EDK II stores it in UEFI variables. There is no handling of daylight
savings switches in EDK II.
With this background allowing anything else but UTC just creates ambiguity.
Jonathan
On Fri, Jun 25, 2021 at 10:35 AM Abner Chang via lists.riscv.org
<http://lists.riscv.org> <renba.chang=gmail.com@...
<mailto:gmail.com@...>> wrote:
From: Abner Chang <abner.chang@... <mailto:abner.chang@...>>
RTC (Real-time Clock)
Real-time clock is the server basic system peripheral to
provide the real date/time information for server to manage the
system date, time and time zones settings for different regions
through the local POST time firmware utility, NTP or the remote
management such as Redfish.
Signed-off-by: Abner Chang <renba.chang@...
<mailto:renba.chang@...>>
Signed-off-by: Abner Chang <abner.chang@...
<mailto:abner.chang@...>>
---
riscv-platform-spec.adoc | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
index 87ea6d5..d611d69 100644
--- a/riscv-platform-spec.adoc
+++ b/riscv-platform-spec.adoc
@@ -442,9 +442,9 @@ The UEFI run time services listed below are
required to be implemented.
|SetVariable | 8.2 | A dedicated storage
for firmware is
required so that there is no conflict in access by both
firmware and the OS.
|QueryVariableInfo | 8.2 |
-|GetTime | 8.3 | RTC Access by the OS
-|SetTime | 8.3 | If it is not possible
to set the RTC,
-the SetTime() can return an error.
+|GetTime | 8.3 | RTC Access by the OS
and firmware
+|SetTime | 8.3 | RTC configured by the
OS and
+firmware
|GetWakeupTime | 8.3 | Interface is
required to be
implemented but it can return EFI_UNSUPPORTED.
|SetWakeupTime | 8.3 | Interface is
required to be
@@ -469,6 +469,17 @@
https://lists.riscv.org/g/tech-privileged/message/404[Sstc]
<https://lists.riscv.org/g/tech-privileged/message/404%5BSstc%5D> extension.
** Platforms are required to delegate the supervisor timer
interrupt to 'S'
mode. If the 'H' extension is implemented then the platforms
are required to
delegate the virtual supervisor timer interrupt to 'VS' mode.
+
+* Real-time Clock (RTC)
+The Real-time clock must be provided to the server extension
platform to
+facilitate the time management (Date, time and the time zone)
and RTC wake up
+when the server is in the power down state for the server
manageability.
+The GetTime()and SetTime() UEFI runtime services must be
implemented by
+firmware to incorporate with RTC and flexibly support RTC use
cases.
+GetWakeupTime() and SetWakeupTime() UEFI runtime services are
required to be
+implemented but it can return EFI_UNSUPPORTED if the wake up
from RTC is not
+supported.
This paragraph is self-contradictory:
It requires RTC to facilitate "RTC wake up" but allows SetWakeupTime()
to report EFI_UNSUPPORTED.
Best regards
Heinrich
+
* PCI-E
==== Secure Boot
--
2.19.0.windows.1
