[edk2-devel] TianoCore Community Design Meeting Minutes - Mar 20, 2020

Mon Mar 23 07:46:39 UTC 2020

From: Ni, Ray [mailto:ray.ni at intel.com]
Sent: Monday, March 23, 2020 3:33 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang at hpe.com>; devel at edk2.groups.io
Cc: Kinney, Michael D <michael.d.kinney at intel.com>; Schaefer, Daniel (DualStudy) <daniel.schaefer at hpe.com>; Chen, Gilbert <gilbert.chen at hpe.com>
Subject: RE: TianoCore Community Design Meeting Minutes - Mar 20, 2020

Please check one comment prefixed with [Ray-2].

From: Chang, Abner (HPS SW/FW Technologist) <abner.chang at hpe.com<mailto:abner.chang at hpe.com>>
Sent: Monday, March 23, 2020 2:40 PM
To: Ni, Ray <ray.ni at intel.com<mailto:ray.ni at intel.com>>; devel at edk2.groups.io<mailto:devel at edk2.groups.io>
Cc: Kinney, Michael D <michael.d.kinney at intel.com<mailto:michael.d.kinney at intel.com>>; Schaefer, Daniel (DualStudy) <daniel.schaefer at hpe.com<mailto:daniel.schaefer at hpe.com>>; Chen, Gilbert <gilbert.chen at hpe.com<mailto:gilbert.chen at hpe.com>>
Subject: RE: TianoCore Community Design Meeting Minutes - Mar 20, 2020

From: Ni, Ray [mailto:ray.ni at intel.com]
Sent: Monday, March 23, 2020 1:13 PM
To: Chang, Abner (HPS SW/FW Technologist) <abner.chang at hpe.com<mailto:abner.chang at hpe.com>>; devel at edk2.groups.io<mailto:devel at edk2.groups.io>
Cc: Kinney, Michael D <michael.d.kinney at intel.com<mailto:michael.d.kinney at intel.com>>; Schaefer, Daniel (DualStudy) <daniel.schaefer at hpe.com<mailto:daniel.schaefer at hpe.com>>; Chen, Gilbert <gilbert.chen at hpe.com<mailto:gilbert.chen at hpe.com>>
Subject: RE: TianoCore Community Design Meeting Minutes - Mar 20, 2020

Resend to devel at edk2.groups.io<mailto:devel at edk2.groups.io> with my responses.

announce at edk2.groups.io<mailto:announce at edk2.groups.io> is not for tech discussion and only few people have post permission.
[Abner] Ok. I see. My response in below.

From: Chang, Abner (HPS SW/FW Technologist) <abner.chang at hpe.com<mailto:abner.chang at hpe.com>>
Sent: Monday, March 23, 2020 12:05 PM
To: Ni, Ray <ray.ni at intel.com<mailto:ray.ni at intel.com>>; announce at edk2.groups.io<mailto:announce at edk2.groups.io>
Cc: Kinney, Michael D <michael.d.kinney at intel.com<mailto:michael.d.kinney at intel.com>>; Schaefer, Daniel (DualStudy) <daniel.schaefer at hpe.com<mailto:daniel.schaefer at hpe.com>>; Chen, Gilbert <gilbert.chen at hpe.com<mailto:gilbert.chen at hpe.com>>
Subject: RE: TianoCore Community Design Meeting Minutes - Mar 20, 2020

Ray, my responses in line.

From: Ni, Ray [mailto:ray.ni at intel.com]
Sent: Friday, March 20, 2020 5:05 PM
To: announce at edk2.groups.io<mailto:announce at edk2.groups.io>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang at hpe.com<mailto:abner.chang at hpe.com>>; Kinney, Michael D <michael.d.kinney at intel.com<mailto:michael.d.kinney at intel.com>>; Ni, Ray <ray.ni at intel.com<mailto:ray.ni at intel.com>>
Subject: TianoCore Community Design Meeting Minutes - Mar 20, 2020

Topic:

1. EDK2 DxeIpl Abstraction (Abner Chang/HPE)

   Slides: https://edk2.groups.io/g/devel/files/Designs/2020/0320/EDK2%20DxeIpl%20Abstraction.pdf<https://edk2.groups.io/g/devel/files/Designs/2020/0320/EDK2%20DxeIpl%20Abstraction.pdf>

Today's meeting was extended to 2 hours to discuss the overall RISC-V support in EDKII. It makes sense because low-level design depends on the finalize of high-level design.

Today's RISC-V enabling in EDKII work is to provide a UEFI wrapper over RISC-V OpenSBI (Open Source Supervisor Binary Interface), which is an open-source reference implementation (https://github.com/riscv/opensbi) of RISC-V SBI specification (https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc).

OpenSBI itself is a boot loader. If RISC-V SBI specification is treated as UEFI spec and OpenSBI is treated as the EDKII.

Right now, Abner's work is the only effort that enables UEFI in RISC-V platforms.

The EDKII RISC-V environment consists of three phases: SEC-PEI-DXE. A RISC-V specific SEC module statically linked with OpenSBI exposes all interfaces required by the UEFI wrapper.

There are 3 sub-topics discussed in the meeting:

1. Which mode DXE phase is running at?

   RISC-V defines three privileged modes: Machine/Supervisor/User Mode.
   SEC and PEI run in M mode and DXE can run either in M mode or S mode which is the platform's choice.
   If DXE runs in S mode, some of the resources cannot be accessed.
   UEFI spec says RISC-V only runs in M mode during post including DXE. Spec needs update.
[Abner] Yes, this must be updated. I will take this.

2. How to resolve MdeModulePkg's dependency on RiscVPkg?

   The dependency is because the M to S mode switch
[Abner] This may not accurate. I think you mean the dependency is exposed due to we rely on RISC-V OpenSBI execution mode switch function to put DXE phase in Supervisor mode. We should fix the issue which DXE IPL mixes up the processor architecture in itself, but not to fix switch mode itself.
[Ray] Your words are more accurate. But if we split the change to 2 parts: one requires DXE phase runs in M mode, the other requires DXE phase runs in S mode. Only the 2nd part introduces the MdeModulePkg's dependency on RiscVPkg. We could potentially work on the first part (when the final conclusion is RISC-V does need SEC and PEI phases for UEFI).
[Abner] We actually do not have to split DXE phase into two modes. This is actually a very simple DXEIPL dependency issue but seems to me we led this to even far. DXE phase could be just in M-mode or S-mode depends on platform requirements and processor capability. To split DXE phases into two different modes is unnecessary and not much value. Separate SEC/PEI and DXE/BDS into two modes (or in the same mode) is good enough. DXE phases has M-mode actually, that is when the OpenSBI function is trigger in SMode and executed in MMode.
[Ray-2] https://github.com/tianocore/edk2-staging/commit/33a9bd8984163ca2a7cc50627c15087f7574e203 adds two library instances. One of them is to simply call SwitchStack() to DXE phase which means DXE phase runs in the same mode as PEI phase. The other one calls to OpenSBI to switch to S mode.
[Abner] Yes. the NULL instance one (Simple call to SwitchStack()) will never been used and it is there just for building RiscVPkg package. I think I should remove it as Ard mentioned in his comment (I can't remember who exactly mentioned that).
The second one is used for RISC-V platforms, ThisScratch->next_mode = PRV_S is the parameters to switch to either SMode or MMode. Currently it is hardcoded but could be an PCD defined in RiscVPlatformPkg and override by platform dsc.
Sorry, I thought "DXE phase" you mentioned refers to the entire DXE phase.

This project is targeted on having RISC-V edk2 port to align with edk2 different execution phases since 2016 and presented in UEFI plugfest 2016. This is also the current most use cases of PC and server (HPE are focusing on PC/Server area), to skip SEC and PEI is not the initial goal of this project. We can raise another project for skipping SEC and PEI, I assume you were saying the UefiPayloadPkg?

   Abner's solution tries to address this dependency issue by introducing another abstract layer. (see slides: https://edk2.groups.io/g/devel/files/Designs/2020/0320/EDK2%20DxeIpl%20Abstraction.pdf<https://edk2.groups.io/g/devel/files/Designs/2020/0320/EDK2%20DxeIpl%20Abstraction.pdf>)
   Mike proposes another solution: RiskVPkg exposes the mode switch interfaces (sbi_init ?) through PPI and the PPI definition can be in MdePkg which might be included by PI spec.
[Abner] This may not work if the PPI/Protocol still have dependency with RISC-V definitions. But it is ok if could we define a generic PPI/Protocol such as EFI_EXECUTION_MODE_PROTOCOL(PPI) under MdePkg. Then arch provides the implementation, however, this is our midterm plan not for now though. NULL instance of DxeIplHadndoffLib is still a neat choice IMO.
[Ray] The original plan was to expose OpenSBI interfaces through PPI/Protocol defined in PI spec and MdePkg. But given the fact OpenSBI is an under-development project and your change is a UEFI wrapper over OpenSBI, it may be hard to propose the OpenSBI interfaces to PI spec. There was an idea raised in the meeting which is to extend UefiPayloadPkg for RISC-V.
[Abner] Actually we don't intend to have OpenSBI EFI protocol defined in PI nor UEFI spec. The EFI version OpenSBI interface is only for RISC-V arch, the spec will be in RISC-V github instead.

UefiplayloadPkg is the firmware payload for CoreBoot or other boot loader.  This approach could be classified as another project and different from our approach which is the regular EDK2 implementation aligns with x86 PC/Server firmware arch. And this is the goal of this initial edk2 RISC-V port as well, which is based on edk2 boot phases. For HPE, we won't use CoreBoot, LinuxBoot or other boot mechanisms for now or even in the future (I can't see any chance so far) in our mainstream server products. Whether to use UefiPayloadPkg is determined by system vendors, also depends on the demands of firmware support and corporate strategy. We should not mixed up these different firmware mechanisms. Again, we are fine to create another project for UefiPayloadPkg though, but that is far from HPE system firmware direction.

3. Location of RiscVPkg and RiscVPlatformPkg

   RiscVPkg in @edk2-platforms/Silicon/... directory.
   RiscVPlatformPkg in @edk2-platforms/Platform/... directory.
   Long term goal is to put all CPU implementation that follows industry standard to UefiCpuPkg, including ARM and RISC-V.
[Abner] We can consider this solution to put RISC-V packages in edk2-platforms in temporary. However, the final decision should be made accroding,

  1.  The plan for refining UefiCpuPkg. It is meaningless to put RISC-V packages in edk2-platforms if the plan of UefiCpuPkg refining is something like one or two years.
  2.  How far it is from current UefiCpuPkg implementation to the ideal generic UefiCpuPkg for all archs?
[Ray] RiscVPlatformPkg in @edk2-platforms doesn't depend on above 2 questions.
[Abner] RiscVPlatformPkg still has dependency with RiscVPkg. To speak frankly, that is not a good idea to separate RiscVPkg and RiscVPlatform packages into two repos, that is a nightmare and burdens to maintain changes in two different repos even the commit in both repos fix the same issue.

4. Which changes can be in edk2

   Need Abner to look at all the changes again. But at least the INF/C changes that enable individual drivers to be built by RISC-V compiler can.
[Abner] yes.

Thanks,
Ray

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#56098): https://edk2.groups.io/g/devel/message/56098
Mute This Topic: https://groups.io/mt/72485353/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/edk2-devel-archive/attachments/20200323/cee06aa0/attachment.htm>