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 forEDK II is available for RISC-V. So there is at least one compliant
Server2022 platform without knowing what firmware framework will be
On Wed, Apr 21, 2021 at 3:29 AM Abner Chang via lists.riscv.org
I would like to give clarifications to some of the discussions
this week's meeting.
1. UEFI as the mandatory firmware.
I brought up this because it is not necessary to mention we
use UEFI in the server extension section although UEFI is the
mainstream firmware used on the server platform. As the
RISC-V, we could be open to any other possible firmware
Use "if the UEFI firmware system is adopted to RISC-V server
platform ..." seems better IMO.
LinuxBoot might be used to boot into a Linux via kexec instead of
but kexec excludes running any other operating systems like BSD.
I would prefer to see the UEFI stuff finalized first. This does not
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.
The U-Boot UEFI implementation targets the EBBR. To meet the server
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
Does uboot RISC-V has fully support UEFI? Most PCI expansion
firmware is in UEFI format, which requires more UEFI protocols.
Those option cards may require UEFI_DRIVER_BINDING,
EFI HII for the configuration page, and etc.
BTW, is uboot targeted as server firmware?
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
x86 code. The X86EmulatorDxe package can be ported to RISC-V with
limited effort (just two small files to replace).
3. UEFI and TEE
TEE would be in the scope of UEFI PI spec volume 4 the
Mode and the recent spec PRM (Platform Runtime Mechanism). I
followed TEE discussion before for the management mode on RISC-
however, I lose that track.
4. The server levels,
I raised this question but not proposing this. The context
this question is because we have the "Server Extensions"
under Linux2022. How can we accommodate different scales of
if the server features in "Server Extension" are all mandatory?
example, RV128 would be used in the very large scale sever for
memory-centric composable architecture such as Gen-Z. The Edge
server or the servers for small and medium businesses need
neither. We should somehow categorize the server class, Like
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