On Wed, 2021-04-21 at 14:30 +0200, Heinrich Schuchardt wrote:

On 21.04.21 13:16, Jonathan Behrens wrote:

I'm not sure I follow #1. How can I write an operating system for
the
Server2022 platform without knowing what firmware framework will be
in use?

Jonathan

On Wed, Apr 21, 2021 at 3:29 AM Abner Chang via lists.riscv.org
<http://lists.riscv.org> <renba.chang=gmail.com@...
<mailto:gmail.com@...>> wrote:

    Hi all,
    I would like to give clarifications to some of the discussions
in
    this week's meeting.

    1. UEFI as the mandatory firmware.
        I brought up this because it is not necessary to mention we
must
    use UEFI in the server extension section although UEFI is the
    mainstream firmware used on the server platform. As the
ecosystem of
    RISC-V, we could be open to any other possible firmware
frameworks. 
    Use "if the UEFI firmware system is adopted to RISC-V server
    platform ..." seems better IMO.

EDK II is available for RISC-V. So there is at least one compliant
UEFI
implementation.

LinuxBoot might be used to boot into a Linux via kexec instead of
UEFI
but kexec excludes running any other operating systems like BSD.

I would prefer to see the UEFI stuff finalized first. This does not
stop
us from defining separate requirements for LinuxBoot later on.

Agreed. There are lot of moving pieces with LinuxBoot for RISC-V at
this moment. I would suggest to have the Linux-2022 version with UEFI.

We can include LinuxBoot in the future version as an alternative.
However, we need more assertive text than what Abner suggested.
Otherwise, there is not advantage of standardization.

    2. Is PCI mandatory
    Same thought as the #1, there are some other bus protocols.
    And we also mentioned EFI_PCI_BUS_ related protocol in the
patch.
    Does uboot RISC-V has fully support UEFI? Most PCI expansion
ROM
    firmware is in UEFI format, which requires more UEFI protocols.
    Those option cards may require UEFI_DRIVER_BINDING,
DRIVER_HEALTH,
    FIRMWARE_MANAGEMENT, DEVICE_PATH,
PLATFORM_TO_DRIVER_CONFIGURATION,
    EFI HII for the configuration page, and etc.
    BTW, is uboot targeted as server firmware?

The U-Boot UEFI implementation targets the EBBR. To meet the server
platform specification you would have to use EDK II. This is just the
same situation as for ARM's SBBR.

Yes. Base platform will only include a minimum subset of UEFI as a
mandatory requirement similar to EBBR. That allows U-boot to be the
compliant UEFI implementation for the base specification.

On ARMv8 EDK II can use an integrated QEMU library to run PCI ROMs
with
x86 code. The X86EmulatorDxe package can be ported to RISC-V with
limited effort (just two small files to replace).

Best regards

Heinrich

    3. UEFI and TEE 
      TEE would be in the scope of UEFI PI spec volume 4 the
Management
    Mode and the recent spec PRM (Platform Runtime Mechanism). I
had
    followed TEE discussion before for the management mode on RISC-
V,
    however, I lose that track.

    4. The server levels,
        I raised this question but not proposing this. The context
of
    this question is because we have the "Server Extensions"
section
    under Linux2022. How can we accommodate different scales of
server
    if the server features in "Server Extension" are all mandatory?
for
    example, RV128 would be used in the very large scale sever for
the
    memory-centric composable architecture such as Gen-Z. The Edge
    server or the servers for small and medium businesses need
RV128
    neither. We should somehow categorize the server class, Like
what
    Anup mentioned, the Server2022 or above.
    Maybe something like Server.Standard.2022, Server.Edge.2022 and
    Server.HPC.2022.  But Server2022  is good enough for now
though.

    Regards,
    Abner

--
Regards,
Atish