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.