3. 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.

On Mon, May 10, 2021 at 6:48 PM Abner Chang <renba.chang@...> wrote:

3. 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.

I notice that ARM SBSA does not specify an RTC nor does it even make any mention of requiring some form of RTC. That suggests that an RTC mandate is maybe not necessary in RISC-V's rough equivalent of SBSA?

In other words, why does RISC-V's server platform spec need to mandate an RTC, yet ARM's SBSA spec doesn't need to?

Greg

Greg Favor <gfavor@...> 於 2021年5月11日 週二 上午9:55寫道：

On Mon, May 10, 2021 at 6:48 PM Abner Chang <renba.chang@...> wrote:

3. 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.

I notice that ARM SBSA does not specify an RTC nor does it even make any mention of requiring some form of RTC. That suggests that an RTC mandate is maybe not necessary in RISC-V's rough equivalent of SBSA?

In other words, why does RISC-V's server platform spec need to mandate an RTC, yet ARM's SBSA spec doesn't need to?

It does mention Real-time clock must be accessed by EFI GetTime/SetTime runtime service, but it allows SetTime() to return errors if the RTC can't be set.

Abner

Greg

On Tue, May 11, 2021 at 8:55 AM Abner Chang <renba.chang@...> wrote:

Greg Favor <gfavor@...> 於 2021年5月11日 週二 上午9:55寫道：

On Mon, May 10, 2021 at 6:48 PM Abner Chang <renba.chang@...> wrote:

3. 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.

I notice that ARM SBSA does not specify an RTC nor does it even make any mention of requiring some form of RTC. That suggests that an RTC mandate is maybe not necessary in RISC-V's rough equivalent of SBSA?

In other words, why does RISC-V's server platform spec need to mandate an RTC, yet ARM's SBSA spec doesn't need to?

It does mention Real-time clock must be accessed by EFI GetTime/SetTime runtime service, but it allows SetTime() to return errors if the RTC can't be set.

Abner

Are you mandating RTC in hardware or just UEFI RTC Interfaces in case RTC is present? We need to make this clear.

Greg

It does mention Real-time clock must be accessed by EFI GetTime/SetTime runtime service, but it allows SetTime() to return errors if the RTC can't be set.

Abner

On Mon, May 10, 2021 at 8:53 PM Rahul Pathak <rpathak@...> wrote:

It does mention Real-time clock must be accessed by EFI GetTime/SetTime runtime service, but it allows SetTime() to return errors if the RTC can't be set.

Abner

Where are you seeing this?  The latest SBSA 7.0 and BSA 1.0 make no mention of this (or any RTC-related requirement).

Greg

Hi Abner,

On Tue, May 11, 2021 at 09:48:42AM +0800, renba.chang@... wrote:
> From: Abner Chang <renba.chang@...>
>
> Add more server extensions to align with current server firmware implementation and the future technology.
>
> @Sunil, I would like to add below placeholders to server extension in order to align with the server platform implementation.
>
> 1. RISC-V port of Management Mode EFI protocols, most of servers had implemented EFI MM driver to handle the critical errors, security, in-band BMC operations, remote management and etc features.
> Some of those features have dependencies with chipset or processor-arch, but some of those are chipset and processor-arch agnostic. Having RISC-V EFI MM protocols as the server extension to support the latter use case for cross platform FW MM driver implementation.
>
> 2. PRM (Platform Runtime Mechanism)
>    Addition to the use cases implemented based on #1, UEFI PRM is provided to enable OS capability to invoke OS agnostic FW procedures for ACPI or error handling directly without generating software management mode event. Leverage ePMP shared code/data regions for M-Mode/S-Mode entities to co-manage PRM data/code region.
>

My understanding is, these features are introduced to reduce some of the
issues with SMM mode in x86. I am not sure whether we will have similar
issues in risc-v and need to make this feature mandatory. I think each
of these need a separate discussion involving SBI experts. I understand
your intention here is to have a section to trigger further
investigation. If so, it looks fine to me unless someone else have an
objection.

> 3. 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.
>
Agree.

Regards
Sunil

> Signed-off-by: Abner Chang <renba.chang@...>
> Cc: Sunil V L <sunilvl@...>
> ---
>  riscv-platform-spec.adoc | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
> index 160c74a..55c5735 100644
> --- a/riscv-platform-spec.adoc
> +++ b/riscv-platform-spec.adoc
> @@ -245,8 +245,15 @@ implemented but it can return EFI_UNSUPPORTED.
>  implemented but it can return EFI_UNSUPPORTED.
>  |===
> 
> +====== Management Mode
> +====== UEFI Platform Runtime Mechanism
> +* PRM Module
> +* ACPI PRMT Table
> +* Enhanced PMP Shared Memory Region
> +
>  ==== System Peripherals
>  * PCI-E
> +* Real Time Clock
> 
>  ==== Secure Boot
>  * TEE
> --
> 2.19.0.windows.1
>

On 5/17/21 5:41 AM, Anup Patel wrote:
>
>
>> -----Original Message-----
>> From: Heinrich Schuchardt <xypron.glpk@...>
>> Sent: 17 May 2021 01:27
>> To: tech-unixplatformspec@...; Anup Patel
>> <Anup.Patel@...>; Sunil V L <sunilvl@...>;
>> renba.chang@...
>> Cc: tech-unixplatformspec@...
>> Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH] riscv-platform-spec:
>> Additional requirements to server extension
>>
>> Am 16. Mai 2021 19:13:47 MESZ schrieb Anup Patel <anup.patel@...>:
>>> Hi,
>>>
>>> Please note that we should consider that Guest/VM will be directly
>>> running in VS-mode (S-mode without hypervisor capabilities) so UEFI
>>> firmware will be running entirely in S-mode inside Guest/VM for
>>> virtualization. In other words, Guest/VM will not have any M-mode
>>> resources such as PMP, ePMP, etc. Various distros will expect UEFI
>>> services to work fine inside Guest/VM.
>>
>> At least U-Boot relies on OpemSBI for unaligned memory access and may use
>> it for sytem reset. Where will ecalls and exceptions be handled when running
>> in VS mode?
>
> The SBI calls for VS-mode will be provided by the HS-mode (KVM, Xvisor,
> Xen and other hypervisors).
>
> The OpenSBI provides SBI calls for HS-mode and provides other runtime
> features such as misaligned load/store emulation, TIME CSR emulations, etc.
>
> The boot-flow followed by U-Boot take care of virtualization as well.
> Particularly, the U-Boot S-mode is intended to run as-is unmodified in
> VS-mode.
>
> My point is that any UEFI implementation should consider this fact that
> inside Guest/VM there is no M-mode. This means any UEFI related
> requirements should only expect SBI calls and it should not matter who
> provides the SBI calls (OpenSBI or Hypervisors).
>
> Based on my understanding of EDK2 boot-flow, currently it is not as
> flexible as U-Boot + OpenSBI boot-flow. Since EDK2 is widely used
> as UEFI implementation, running directly in VS-mode should be
> supported by EDK2. Please correct me if I am wrong here.

Currently EDK II provides OpenSBI as part of its SEC (Security) code in
edk2-platforms/Silicon/RISC-V/ProcessorPkg/Library/RiscVOpensbiLib/opensbi.

When the hypervisor provides the SEC code we will need to enter directly
into the PEI (Pre-EFI Initialization Environment).

Cf.
https://gblobscdn.gitbook.com/assets%2F-M5spcVt2sqlUZOWmnXY%2F-M5sphJDWD7_iUuoREya%2F-M5spjTOFjRbcY8ckkSh%2Fimage3.png?alt=media

This will require a new platform variant but should not require changes
is main EDK II.

Best regards

Heinrich

>
> Regards,
> Anup
>
>>
>> Best regards
>>
>> Heinrich
>>
>>>
>>> Regards,
>>> Anup
>>>
>>> Get Outlook for Android<https://aka.ms/AAb9ysg>
>>> ________________________________
>>> From: tech-unixplatformspec@...
>>> <tech-unixplatformspec@...> on behalf of Sunil V L
>>> <sunilvl@...>
>>> Sent: Sunday, May 16, 2021 7:17:56 PM
>>> To: renba.chang@... <renba.chang@...>
>>> Cc: tech-unixplatformspec@...
>>> <tech-unixplatformspec@...>
>>> Subject: Re: [RISC-V] [tech-unixplatformspec] [PATCH]
>>> riscv-platform-spec: Additional requirements to server extension
>>>
>>> Hi Abner,
>>>
>>> On Tue, May 11, 2021 at 09:48:42AM +0800, renba.chang@... wrote:
>>>> From: Abner Chang <renba.chang@...>
>>>>
>>>> Add more server extensions to align with current server firmware
>>> implementation and the future technology.
>>>>
>>>> @Sunil, I would like to add below placeholders to server extension in
>>> order to align with the server platform implementation.
>>>>
>>>> 1. RISC-V port of Management Mode EFI protocols, most of servers had
>>> implemented EFI MM driver to handle the critical errors, security,
>>> in-band BMC operations, remote management and etc features.
>>>> Some of those features have dependencies with chipset or
>>> processor-arch, but some of those are chipset and processor-arch
>>> agnostic. Having RISC-V EFI MM protocols as the server extension to
>>> support the latter use case for cross platform FW MM driver
>>> implementation.
>>>>
>>>> 2. PRM (Platform Runtime Mechanism)
>>>>     Addition to the use cases implemented based on #1, UEFI PRM is
>>> provided to enable OS capability to invoke OS agnostic FW procedures
>>> for ACPI or error handling directly without generating software
>>> management mode event. Leverage ePMP shared code/data regions for
>>> M-Mode/S-Mode entities to co-manage PRM data/code region.
>>>>
>>>
>>> My understanding is, these features are introduced to reduce some of
>>> the issues with SMM mode in x86. I am not sure whether we will have
>>> similar issues in risc-v and need to make this feature mandatory. I
>>> think each of these need a separate discussion involving SBI experts. I
>>> understand your intention here is to have a section to trigger further
>>> investigation. If so, it looks fine to me unless someone else have an
>>> objection.
>>>
>>>> 3. 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.
>>>>
>>> Agree.
>>>
>>> Regards
>>> Sunil
>>>
>>>> Signed-off-by: Abner Chang <renba.chang@...>
>>>> Cc: Sunil V L <sunilvl@...>
>>>> ---
>>>>   riscv-platform-spec.adoc | 7 +++++++
>>>>   1 file changed, 7 insertions(+)
>>>>
>>>> diff --git a/riscv-platform-spec.adoc b/riscv-platform-spec.adoc
>>>> index 160c74a..55c5735 100644
>>>> --- a/riscv-platform-spec.adoc
>>>> +++ b/riscv-platform-spec.adoc
>>>> @@ -245,8 +245,15 @@ implemented but it can return
>> EFI_UNSUPPORTED.
>>>>   implemented but it can return EFI_UNSUPPORTED.
>>>>   |===
>>>>
>>>> +====== Management Mode
>>>> +====== UEFI Platform Runtime Mechanism
>>>> +* PRM Module
>>>> +* ACPI PRMT Table
>>>> +* Enhanced PMP Shared Memory Region
>>>> +
>>>>   ==== System Peripherals
>>>>   * PCI-E
>>>> +* Real Time Clock
>>>>
>>>>   ==== Secure Boot
>>>>   * TEE
>>>> --
>>>> 2.19.0.windows.1
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
>
>
>
>