* Re: TianoCore Community Design Meeting Minutes - Mar 20, 2020 [not found] ` <TU4PR8401MB0429C3568F6923B936DAF0EBFFF00@TU4PR8401MB0429.NAMPRD84.PROD.OUTLOOK.COM> @ 2020-03-23 5:12 ` Ni, Ray 2020-03-23 6:39 ` Abner Chang 0 siblings, 1 reply; 4+ messages in thread From: Ni, Ray @ 2020-03-23 5:12 UTC (permalink / raw) To: Chang, Abner (HPS SW/FW Technologist), devel@edk2.groups.io Cc: Kinney, Michael D, Schaefer, Daniel (DualStudy), Chen, Gilbert [-- 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 --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: TianoCore Community Design Meeting Minutes - Mar 20, 2020 2020-03-23 5:12 ` TianoCore Community Design Meeting Minutes - Mar 20, 2020 Ni, Ray @ 2020-03-23 6:39 ` Abner Chang 2020-03-23 7:33 ` Ni, Ray 0 siblings, 1 reply; 4+ messages in thread From: Abner Chang @ 2020-03-23 6:39 UTC (permalink / raw) To: Ni, Ray, devel@edk2.groups.io Cc: Kinney, Michael D, Schaefer, Daniel (DualStudy), Chen, Gilbert [-- Attachment #1: Type: text/plain, Size: 8532 bytes --] From: Ni, Ray [mailto:ray.ni@intel.com] Sent: Monday, March 23, 2020 1:13 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>; devel@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 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. [Abner] Ok. I see. My response in below. From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com<mailto:abner.chang@hpe.com>> Sent: Monday, March 23, 2020 12:05 PM To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; announce@edk2.groups.io<mailto:announce@edk2.groups.io> Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Schaefer, Daniel (DualStudy) <daniel.schaefer@hpe.com<mailto:daniel.schaefer@hpe.com>>; Chen, Gilbert <gilbert.chen@hpe.com<mailto: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://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. 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 [-- Attachment #2: Type: text/html, Size: 18071 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: TianoCore Community Design Meeting Minutes - Mar 20, 2020 2020-03-23 6:39 ` Abner Chang @ 2020-03-23 7:33 ` Ni, Ray 2020-03-23 7:46 ` Abner Chang 0 siblings, 1 reply; 4+ messages in thread From: Ni, Ray @ 2020-03-23 7:33 UTC (permalink / raw) To: Chang, Abner (HPS SW/FW Technologist), devel@edk2.groups.io Cc: Kinney, Michael D, Schaefer, Daniel (DualStudy), Chen, Gilbert [-- Attachment #1: Type: text/plain, Size: 9857 bytes --] Please check one comment prefixed with [Ray-2]. From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com> Sent: Monday, March 23, 2020 2:40 PM To: Ni, Ray <ray.ni@intel.com>; devel@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 From: Ni, Ray [mailto:ray.ni@intel.com] Sent: Monday, March 23, 2020 1:13 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com<mailto:abner.chang@hpe.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Schaefer, Daniel (DualStudy) <daniel.schaefer@hpe.com<mailto:daniel.schaefer@hpe.com>>; Chen, Gilbert <gilbert.chen@hpe.com<mailto:gilbert.chen@hpe.com>> Subject: RE: TianoCore Community Design Meeting Minutes - Mar 20, 2020 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. [Abner] Ok. I see. My response in below. From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com<mailto:abner.chang@hpe.com>> Sent: Monday, March 23, 2020 12:05 PM To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; announce@edk2.groups.io<mailto:announce@edk2.groups.io> Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Schaefer, Daniel (DualStudy) <daniel.schaefer@hpe.com<mailto:daniel.schaefer@hpe.com>>; Chen, Gilbert <gilbert.chen@hpe.com<mailto: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] 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. 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://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. [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 [-- Attachment #2: Type: text/html, Size: 20238 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: TianoCore Community Design Meeting Minutes - Mar 20, 2020 2020-03-23 7:33 ` Ni, Ray @ 2020-03-23 7:46 ` Abner Chang 0 siblings, 0 replies; 4+ messages in thread From: Abner Chang @ 2020-03-23 7:46 UTC (permalink / raw) To: Ni, Ray, devel@edk2.groups.io Cc: Kinney, Michael D, Schaefer, Daniel (DualStudy), Chen, Gilbert [-- Attachment #1: Type: text/plain, Size: 10536 bytes --] From: Ni, Ray [mailto:ray.ni@intel.com] Sent: Monday, March 23, 2020 3:33 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com>; devel@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 Please check one comment prefixed with [Ray-2]. From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com<mailto:abner.chang@hpe.com>> Sent: Monday, March 23, 2020 2:40 PM To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Schaefer, Daniel (DualStudy) <daniel.schaefer@hpe.com<mailto:daniel.schaefer@hpe.com>>; Chen, Gilbert <gilbert.chen@hpe.com<mailto:gilbert.chen@hpe.com>> Subject: RE: TianoCore Community Design Meeting Minutes - Mar 20, 2020 From: Ni, Ray [mailto:ray.ni@intel.com] Sent: Monday, March 23, 2020 1:13 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com<mailto:abner.chang@hpe.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Schaefer, Daniel (DualStudy) <daniel.schaefer@hpe.com<mailto:daniel.schaefer@hpe.com>>; Chen, Gilbert <gilbert.chen@hpe.com<mailto:gilbert.chen@hpe.com>> Subject: RE: TianoCore Community Design Meeting Minutes - Mar 20, 2020 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. [Abner] Ok. I see. My response in below. From: Chang, Abner (HPS SW/FW Technologist) <abner.chang@hpe.com<mailto:abner.chang@hpe.com>> Sent: Monday, March 23, 2020 12:05 PM To: Ni, Ray <ray.ni@intel.com<mailto:ray.ni@intel.com>>; announce@edk2.groups.io<mailto:announce@edk2.groups.io> Cc: Kinney, Michael D <michael.d.kinney@intel.com<mailto:michael.d.kinney@intel.com>>; Schaefer, Daniel (DualStudy) <daniel.schaefer@hpe.com<mailto:daniel.schaefer@hpe.com>>; Chen, Gilbert <gilbert.chen@hpe.com<mailto: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://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 [-- Attachment #2: Type: text/html, Size: 22200 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-03-23 7:46 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <734D49CCEBEEF84792F5B80ED585239D5C4A2E4C@SHSMSX104.ccr.corp.intel.com>
[not found] ` <TU4PR8401MB0429C3568F6923B936DAF0EBFFF00@TU4PR8401MB0429.NAMPRD84.PROD.OUTLOOK.COM>
2020-03-23 5:12 ` TianoCore Community Design Meeting Minutes - Mar 20, 2020 Ni, Ray
2020-03-23 6:39 ` Abner Chang
2020-03-23 7:33 ` Ni, Ray
2020-03-23 7:46 ` Abner Chang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox