Request for comments: relaxing time services requirements

[vstehle]

This is a request-for-comments which is meant as a support to start the discussion.

Allow firmware to ignore time services timezone and daylight, and allow time and alarm to not persist across reset.

This change break compatibility and therefore necessitates a change of the major version of this specification.

This is something that U-Boot is doing in practice with e.g. RTC emulation,
and that is allowed de-facto since a while on Arm ACS side.

• Should we relax the requirements clearly?
• Is it the right time to do it?
• Would we bump EBBR major number "just" for that?

[xypron]

The daylight saving time flag is considered in U-Boot's EFI layer. But some device drivers may not support it. The timezone is always returned as unspecified as the RTC typically cannot store that information. I am not sure that we have a gap to the UEFI spec here.

Linux expects the hardware clock to be set to UTC, while Windows expects it to be in local time. A registry entry in Windows allows using UTC in the RTC. BSD also prefers UTC.

Both timezone as well as dst support are not needed when using UTC in the hardware clock.

Using UTC looks like the sane choice for EBBR devices.

RTC alerts are currently not supported in U-Boot. Programming the RTC alerts is typically done by the OS. As we have no U-Boot drivers for the RTC at runtime, the OS will always have to use its own drivers. I don't see a need to access RTC alerts at boot time.

[xypron]

The problem in U-Boot is not persistence. There is no support in the hardware driver framework at all for wakeup times though the hardware support might exist.

So the current suggestion won't help to make U-Boot compliant.

[vstehle]

Hi @xypron,

Thanks for the review.

For wakeup we are somewhat covered already as those services are only conditionally required:

EFI_RUNTIME_SERVICES function	Before ExitBootServices()	After ExitBootServices()
..	..	..
GetWakeupTime	Required if wakeup supported.	Optional
SetWakeupTime	Required if wakeup supported.	Optional

Persistence of e.g. time or daylight settings is still a small issue here, I think, as it is indeed tested by the SCT and it will not work on platforms using RTC emulation.

[vstehle]

Hi, here are the results of some more investigations on the time services, to follow up with our EBBR call of May 20.

EDK II does not rely on the RTC to store either daylight saving time (DST) or timezone. Those informations are saved in a UEFI Variable instead.

Some RTCs are actually capable of dealing with DST, such as the MC146818A, but some are not.

Typical components on the boot path such as Shim, GRUB or Systemd only rarely use time services. Example usages in addition to date and time are crypto and randomness.

The Linux EFI rtc driver can handle DST, but not timezone.

I think we could in fact keep the requirement to persist DST + timezone across reset.

[vstehle]

Let's discuss this table during today's EBBR call:

Time functional at boot time	Time persists	DST and Timezone persist	EBBR should allow?
No	-	-	No?
Yes	No	No	Yes?
Yes	Yes	Yes	Yes (UEFI)

Is it useful to detail more intermediate cases?