Re: The clarifications to 4/19 meeting
Atish Patra <Atish.Patra@...> 於 2021年4月22日 週四 上午5:33寫道：
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.
Don't get me wrong. I also agree with this point. I never thought to
spec
Linuxboot out in platform spec at this moment. I just argue that why to have "UEFI must be the firmware" in the spec in the server extension.
> >
> > 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.
>
Hmm ok. I thought (also expect) U-Boot would be also one of the UEFI implementations for the server industry. Then it says UEFI/EDK2 would be the only firmware solution for the RISC-V server.
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.
There is a question mark in my mind for this,
Linux2020 section seems to be a generic/base spec
with the minimum requirements for all kinds of platforms. However, we have many links to EBBR, and EBBR is for embedded systems with ARM-specific sections in the spec.
Can I just implement it in this way, the Linux2020 is defined for an embedded system?
> 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).
Good information.
>
> Best regards
>
> Heinrich
I understand the U-Boot situation
Now
, earlier I thought the server platform spec should be able to accommodate different firmware solutions (e.g. UEFI/Linux boot) and also different UEFI implementations (e.g. U-Boot/EDK2) for the RISC-V server platform as part of the RISC-V ecosystem, seems it is not for now. I will reply to @Sunil V L patches.
Thanks
Abner
>
> >
> > 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