Re: TianoCore Community Design Meeting Minutes - Mar 20, 2020

["Ni, Ray" <ray.ni@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 6109 bytes --]

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

announce@edk2.groups.io<mailto:announce@edk2.groups.io> is not for tech discussion and only few people have post permission.

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

Ray, my responses in line.

From: Ni, Ray [mailto:ray.ni@intel.com]
Sent: Friday, March 20, 2020 5:05 PM
To: announce@edk2.groups.io<mailto:announce@edk2.groups.io>
Cc: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com<mailto:abner.chang@hpe.com>>; Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Ni, Ray <ray.ni@intel.com<mailto:ray.ni@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://urldefense.proofpoint.com/v2/url?u=https-3A__edk2.groups.io_g_devel_files_Designs_2020_0320_EDK2-2520DxeIpl-2520Abstraction.pdf&d=DwQFAg&c=C5b8zRQO1miGmBeVZ2LFWg&r=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E&m=5PAdWDpkKDNG1gE667yjm6cZ1OlWB66X0jM9RaTmN60&s=eQdzLPrUx9IKIqTmy0BrbK8Zk3UMdGhrpaLzLsUWVrw&e=>



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'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://urldefense.proofpoint.com/v2/url?u=https-3A__edk2.groups.io_g_devel_files_Designs_2020_0320_EDK2-2520DxeIpl-2520Abstraction.pdf&d=DwQFAg&c=C5b8zRQO1miGmBeVZ2LFWg&r=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E&m=5PAdWDpkKDNG1gE667yjm6cZ1OlWB66X0jM9RaTmN60&s=eQdzLPrUx9IKIqTmy0BrbK8Zk3UMdGhrpaLzLsUWVrw&e=>)
   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.

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.

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


[-- Attachment #2: Type: text/html, Size: 14215 bytes --]