Hi Mike, Do you have any feedback on this? Or we just bring this topic to the design meeting? That would be good if any of you can give other thoughts, so I can have some POC code before the design meeting.
Thanks Abner ________________________________ From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Abner Chang <abner.ch...@hpe.com> Sent: Tuesday, March 1, 2022 5:56 PM To: Ni, Ray <ray...@intel.com>; Kinney, Michael D <michael.d.kin...@intel.com>; Leif Lindholm <l...@nuviainc.com>; devel@edk2.groups.io <devel@edk2.groups.io>; LiChao <lic...@loongson.cn> Cc: Andrew Fish <af...@apple.com>; Sami Mujawar <sami.muja...@arm.com>; Schaefer, Daniel (ROM Janitor) <daniel.schae...@hpe.com>; Sunil V L <suni...@ventanamicro.com> Subject: Re: [edk2-devel] RFC: UefiCpuPkg for all processor archs Hi Ray, RISC-V doesn't have the similar functions as those are provided in BaseUefiCpuLib.c. In this case, what we can do is just leverage the library class but different implementation for archs? At least we don't need another library class for RISC-V. We can have the common source file if all archs provided the same functionality later. Regards, Abner ________________________________ From: Ni, Ray <ray...@intel.com> Sent: Tuesday, March 1, 2022 3:07 PM To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com>; Kinney, Michael D <michael.d.kin...@intel.com>; Leif Lindholm <l...@nuviainc.com>; devel@edk2.groups.io <devel@edk2.groups.io>; LiChao <lic...@loongson.cn> Cc: Andrew Fish <af...@apple.com>; Sami Mujawar <sami.muja...@arm.com>; LiChao <lic...@loongson.cn>; Schaefer, Daniel (ROM Janitor) <daniel.schae...@hpe.com>; Sunil V L <suni...@ventanamicro.com> Subject: RE: RFC: UefiCpuPkg for all processor archs Abner, UefiCpuPkg\SecCore\SecCoreNative.inf is a module that might not depend on X86. It assumes the UefiCpuPkg/ResetVector inits the CPU well. UefiCpuPKg/BaseUefiCpuLib 1. Rename BaseUefiCpuLib.c to BaseUefiCpuLibIa32X64.c BaseUefiCpuLibRiscV64.c for RISC-V arch and assembly code under /RISCV64 2. Or move all X86 source files to under BaseUefiCpuLib/X86, BaseUefiCpuLib/RISC-V for RISC-V arch (I prefer this way, the directory looks clean) That depends on whether the RISC-V or LoongArch can implement the same API as that in X86 version. Maybe some of the APIs are too X86 specific that makes it hard for implementing for other ARCHs. That might lead to a more abstraction. Without the concrete implementation available, I have no idea what abstraction is. Thanks, Ray From: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com> Sent: Tuesday, March 1, 2022 9:26 AM To: Kinney, Michael D <michael.d.kin...@intel.com>; Leif Lindholm <l...@nuviainc.com>; devel@edk2.groups.io; Ni, Ray <ray...@intel.com>; LiChao <lic...@loongson.cn> Cc: Andrew Fish <af...@apple.com>; Sami Mujawar <sami.muja...@arm.com>; LiChao <lic...@loongson.cn>; Schaefer, Daniel <daniel.schae...@hpe.com>; Sunil V L <suni...@ventanamicro.com> Subject: RFC: UefiCpuPkg for all processor archs Hi Mike and Ray, I just got a chance to back on this topic and below are few questions regarding the UefiCpuPkg for all processor archs. I change the subject and loop Chao Li from Loongsoon who is contributing Loongarch64 to Uefi/edk2. He may have to handle the similar things for Loongarch64. I went through RISC-V modules that currently located on edk2-platforms repo (Platform/RISC-V/PlatformPKg and Silicon/RISC-V/ProcessorPkg) and figure out the modules we would move to under UefiCpuPkg and MdeModulePkg. We could go through the proposal in the design meeting later, however I would like to confirm the proposal of revising modules under /UEfiCpuPkg those were implemented in X86 oriented before we get to that point. * UefiCpuPKg\SecCore * The implementation of this module is very x86 oriented. There is likely nothing to leverage between archs. My thought was * 1. Having RISC-V SecCore in its own folder, e.g. UefiCpuPkg/RISC-V/SecCore and create the individual INF for archs. * However, 2. We can also consider having the separate section in SecCore/SecCore.inf. Move all X86 source files to under UefiCpuPkg/SecCore/X86 and have /RISC-V folder under UefiCpuPkg/SecCore for RISC-V arch. (I prefer this way) * * UefiCpuPKg/BaseUefiCpuLib * 1. Rename BaseUefiCpuLib.c to BaseUefiCpuLibIa32X64.c * BaseUefiCpuLibRiscV64.c for RISC-V arch and assembly code under /RISCV64 * 2. Or move all X86 source files to under BaseUefiCpuLib/X86, BaseUefiCpuLib/RISC-V for RISC-V arch (I prefer this way, the directory looks clean) * * UefiCpuPKg/CpuExceptionHandlerLib Too many X86 source files, move all X86 source files to under CpuExecptionHander/X86, CpuExecptionHander/RISC-V for RISC-V arch * Having abstract level under /CpuExecptionHander, e.g. INF, PeiException.c, DxeException.c and etc. * * UefiCpuPKg\Library\CpuTimerLib * 1. Rename BaseCpuTimerLib.c to BaseCpuTimerLibIa32X64.c, BaseCpuTimerLibRiscV64.c for RISC-V arch. * 2. Or move all X86 source files to under BaseUefiCpuLib/X86, BaseUefiCpuLib/RISC-V for RISC-V arch (I prefer this way) * * UefiCpuPKg/CpuDxe * Revise CpuDxe.c and CpuDxe.h to be abstract for the processor archs. * Move all x86 implementations to under /X86, CpuDxe/RISC-V for RISC-V CpuDxe implementation Let me know your thoughts, I can initiate the PoC code after we get on the same page. Thanks Abner ________________________________ From: Chang, Abner (HPS SW/FW Technologist) Sent: Saturday, February 5, 2022 10:56 PM To: Kinney, Michael D <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>; Leif Lindholm <l...@nuviainc.com<mailto:l...@nuviainc.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Ni, Ray <ray...@intel.com<mailto:ray...@intel.com>> Cc: Andrew Fish <af...@apple.com<mailto:af...@apple.com>>; Sami Mujawar <sami.muja...@arm.com<mailto:sami.muja...@arm.com>> Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header files of RISC-V processor package Thanks Mike. The reason I asked this question is we are working on the OvmfRiscV64 as you suggested. However as you know that both RISC-V processor and platform packages are currently stay in edk2-platforms. We have to make sure CI won’t throw errors if we use the edk2 modules in edk2-platforms. We are in rush to have RISC-V edk2 OVMF for RISC-V community. We will start to move RISC-V edk2 port to UefiCpuPkg or MdePkg once RISC-V OVMF port is upstream. Abner From: Kinney, Michael D <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>> Sent: Saturday, February 5, 2022 4:22 AM To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com<mailto:abner.ch...@hpe.com>>; Leif Lindholm <l...@nuviainc.com<mailto:l...@nuviainc.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Ni, Ray <ray...@intel.com<mailto:ray...@intel.com>> Cc: Andrew Fish <af...@apple.com<mailto:af...@apple.com>>; Sami Mujawar <sami.muja...@arm.com<mailto:sami.muja...@arm.com>> Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header files of RISC-V processor package Abner, I do not know if this patter is being used yet, but there is great value in it for all platforms that are intended to be synced with edk2. The idea of testing an edk2 change against all available open source platforms that use edk2 would increase confidence in the edk2 change. >From a CI agent perspective, there are no issues with pulling more repos and >running tests and providing results that can block an edk2 change if it breaks >a specific platform. Mike From: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com<mailto:abner.ch...@hpe.com>> Sent: Friday, February 4, 2022 8:15 AM To: Kinney, Michael D <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>; Leif Lindholm <l...@nuviainc.com<mailto:l...@nuviainc.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Ni, Ray <ray...@intel.com<mailto:ray...@intel.com>> Cc: Andrew Fish <af...@apple.com<mailto:af...@apple.com>>; Sami Mujawar <sami.muja...@arm.com<mailto:sami.muja...@arm.com>> Subject: Re: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header files of RISC-V processor package BTW Mike, Can Core CI on edk2 repo allow the modules referred in the DSC/FDF (e.g., OvmgRiscV64.dsc) to stay in edk2-platform? Abner ________________________________ From: Kinney, Michael D <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>> Sent: Saturday, January 22, 2022 1:37 AM To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com<mailto:abner.ch...@hpe.com>>; Leif Lindholm <l...@nuviainc.com<mailto:l...@nuviainc.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Ni, Ray <ray...@intel.com<mailto:ray...@intel.com>>; Kinney, Michael D <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>> Cc: Andrew Fish <af...@apple.com<mailto:af...@apple.com>>; Sami Mujawar <sami.muja...@arm.com<mailto:sami.muja...@arm.com>> Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header files of RISC-V processor package I would recommend adding the Platform DSC required to run RISC-V with QEMU to OvmfPkg so it can be part of CI for edk2 repo so any change to edk2 that is used by RISC-V can be verified by build and boot to shell. I would like to see the ArmVirtPkg merged into OvmfPkg too so OvmfPkg providse FW build for all support CPU Archs running through QEMU to support edk2 CI that can build and boot to shell in an Azure Pipelines agent. Mike From: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com<mailto:abner.ch...@hpe.com>> Sent: Friday, January 21, 2022 9:13 AM To: Kinney, Michael D <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>; Leif Lindholm <l...@nuviainc.com<mailto:l...@nuviainc.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Ni, Ray <ray...@intel.com<mailto:ray...@intel.com>> Cc: Andrew Fish <af...@apple.com<mailto:af...@apple.com>>; Sami Mujawar <sami.muja...@arm.com<mailto:sami.muja...@arm.com>> Subject: Re: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header files of RISC-V processor package Ok Mike and Leif, Another question regarding to the location of RISC-V Virtual package for QEMU. What is the location and package you think RISC-V or other processor architectures should stay with? Thanks Abner ________________________________ From: Kinney, Michael D <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>> Sent: Saturday, January 15, 2022 12:21 AM To: Chang, Abner (HPS SW/FW Technologist) <abner.ch...@hpe.com<mailto:abner.ch...@hpe.com>>; Leif Lindholm <l...@nuviainc.com<mailto:l...@nuviainc.com>>; devel@edk2.groups.io<mailto:devel@edk2.groups.io> <devel@edk2.groups.io<mailto:devel@edk2.groups.io>>; Ni, Ray <ray...@intel.com<mailto:ray...@intel.com>>; Kinney, Michael D <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>> Cc: Andrew Fish <af...@apple.com<mailto:af...@apple.com>>; Sami Mujawar <sami.muja...@arm.com<mailto:sami.muja...@arm.com>> Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header files of RISC-V processor package Hi Abner, We already have a package for common platform content in the edk2 repo. This is the MdeModulePkg. However, the number of common platform features added to the MdeModulePkg over time has made this a very large package, and this can be measured by how complex the Maintainer.txt rules are for this package. The revised approach is to create feature packages that platforms can add if their platform requires that specific feature category. Examples are NetworkPkg, SecurityPkg, FmpDevicePkg, FatPkg, RedfishPkg, SourceLevelDebugPkg. Instead of adding another generic package such as CommonPlatformPkg, I would prefer to see the libs/modules either added to existing packages that match the feature category, or create new feature packages if there is a new feature category. We also try to limit the edk2 repo to components that are directly related the UEFI/PI specifications and are not Si/Platform specific. Si/Platform specific features go into the edk2-platforms repo. An example of a generic feature in the edk2-platforms repo is Features/Ext4. The UEFI spec only specifies FAT for UEFI boot from file system. There are a number of other feature packages in edk2-platforms in the Features directory, so you should review those as well to see if there is natural landing zone for any of your components. Mike > -----Original Message----- > From: Chang, Abner (HPS SW/FW Technologist) > <abner.ch...@hpe.com<mailto:abner.ch...@hpe.com>> > Sent: Friday, January 14, 2022 3:15 AM > To: Kinney, Michael D > <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>; Leif > Lindholm <l...@nuviainc.com<mailto:l...@nuviainc.com>>; > devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Ni, Ray > <ray...@intel.com<mailto:ray...@intel.com>> > Cc: Andrew Fish <af...@apple.com<mailto:af...@apple.com>>; Sami Mujawar > <sami.muja...@arm.com<mailto:sami.muja...@arm.com>> > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header > files of RISC-V processor package > > > > > -----Original Message----- > > From: Kinney, Michael D > > <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>> > > Sent: Friday, January 14, 2022 12:38 AM > > To: Chang, Abner (HPS SW/FW Technologist) > > <abner.ch...@hpe.com<mailto:abner.ch...@hpe.com>>; Leif > > Lindholm <l...@nuviainc.com<mailto:l...@nuviainc.com>>; > > devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Ni, Ray > > <ray...@intel.com<mailto:ray...@intel.com>>; Kinney, Michael D > > <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>> > > Cc: Andrew Fish <af...@apple.com<mailto:af...@apple.com>>; Sami Mujawar > > <sami.muja...@arm.com<mailto:sami.muja...@arm.com>> > > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header > > files of RISC-V processor package > > > > Hi Abner, > > > > General recommendations included below. Of course each > > lib/modules/include needs to be reviewed and the > > best location selected. I am aware that there are components in edk2 that > > do not follow these general > > recommendations. This is due to content that was added before these > > recommendations were established > > and we have work to do to get everything aligned. > > > > Mike > > > > > -----Original Message----- > > > From: Chang, Abner (HPS SW/FW Technologist) > > > <abner.ch...@hpe.com<mailto:abner.ch...@hpe.com>> > > > Sent: Wednesday, January 12, 2022 9:34 PM > > > To: Kinney, Michael D > > > <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>; Leif > > > Lindholm > > <l...@nuviainc.com<mailto:l...@nuviainc.com>>; > > devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Ni, Ray > > > <ray...@intel.com<mailto:ray...@intel.com>> > > > Cc: Andrew Fish <af...@apple.com<mailto:af...@apple.com>>; Sami Mujawar > > <sami.muja...@arm.com<mailto:sami.muja...@arm.com>> > > > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add > > header files of RISC-V processor package > > > > > > HI Mike, > > > It is no problem to meet there. However, I am not available to join the > > design meeting in the next two weeks. Before we can get > > > together to discuss the best locations, do you have information regarding > > the rationale of driver/library location? > > > > > > What is the best location for, > > > - Processor ARCH dependent modules > > > > MdePkg for libs > > UefiCpuPkg for modules > > > > > - Common modules for all processor ARCHs > > > > Feature Packages based on the common feature. Add to existing if it fits. > > Create new for completely new feature area. > > > > > - Platform module that is specific to processor ARCH? > > > > edk2-platform repository > How about Leif's suggestion? The CommonPlatformPkg on edk2? > > Abner > > > > > The only exception so far are platform modules used to support > > OvmfPkg/QEMU to support CI. > > In this case the modules are added to OvmfPkg. > > > > > - Platform module that is common to processor ARCHs? > > > > edk2-platform repository > > > > The only exception so far are platform modules used to support > > OvmfPkg/QEMU to support CI. > > In this case the modules are added to OvmfPkg. > > > > > > > > Thanks > > > Abner > > > > > > > -----Original Message----- > > > > From: Kinney, Michael D > > > > <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>> > > > > Sent: Monday, January 10, 2022 11:58 PM > > > > To: Leif Lindholm <l...@nuviainc.com<mailto:l...@nuviainc.com>>; > > > > devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Chang, > > Abner > > > > (HPS SW/FW Technologist) > > > > <abner.ch...@hpe.com<mailto:abner.ch...@hpe.com>>; Kinney, Michael D > > > > <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>; Ni, > > > > Ray <ray...@intel.com<mailto:ray...@intel.com>> > > > > Cc: Andrew Fish <af...@apple.com<mailto:af...@apple.com>>; Sami Mujawar > > > > <sami.muja...@arm.com<mailto:sami.muja...@arm.com>> > > > > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add > > header > > > > files of RISC-V processor package > > > > > > > > Hi Abner, > > > > > > > > I see comments from Leif as well. > > > > > > > > Do you think a discussion in the design meeting Ray Ni runs would be > > > > valuable > > > > to review all the modules/libs/includes and discuss options for the best > > > > location for them to reside in the edk2 repos? > > > > > > > > Thanks, > > > > > > > > Mike > > > > > > > > > -----Original Message----- > > > > > From: Kinney, Michael D > > > > > <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>> > > > > > Sent: Monday, January 10, 2022 7:55 AM > > > > > To: Leif Lindholm <l...@nuviainc.com<mailto:l...@nuviainc.com>>; > > > > > devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Chang, > > > > Abner <abner.ch...@hpe.com<mailto:abner.ch...@hpe.com>>; Kinney, > > > > Michael D > > > > > <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>> > > > > > Cc: Andrew Fish <af...@apple.com<mailto:af...@apple.com>>; Sami > > > > > Mujawar > > > > <sami.muja...@arm.com<mailto:sami.muja...@arm.com>> > > > > > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add > > > > header files of RISC-V processor package > > > > > > > > > > Hi Abner, > > > > > > > > > > I would also like to see some proposals on adding the RiscV CPU scoped > > > > content > > > > > to the existing MdePkg/UefiCpuPkg instead of adding a new top level > > CPU > > > > package. > > > > > > > > > > There is already some work started to move some of the ARM specific > > > > content > > > > > from ARM CPU packages into MdePkg. > > > > > > > > > > Thanks, > > > > > > > > > > Mike > > > > > > > > > > > -----Original Message----- > > > > > > From: Leif Lindholm <l...@nuviainc.com<mailto:l...@nuviainc.com>> > > > > > > Sent: Monday, January 10, 2022 5:11 AM > > > > > > To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Chang, Abner > > > > > > <abner.ch...@hpe.com<mailto:abner.ch...@hpe.com>> > > > > > > Cc: Andrew Fish <af...@apple.com<mailto:af...@apple.com>>; Kinney, > > > > > > Michael D > > > > <michael.d.kin...@intel.com<mailto:michael.d.kin...@intel.com>>; Sami > > > > Mujawar > > <sami.muja...@arm.com<mailto:sami.muja...@arm.com>> > > > > > > Subject: Re: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add > > > > header files of RISC-V processor package > > > > > > > > > > > > On Sat, Jan 08, 2022 at 12:07:53 +0800, Abner Chang wrote: > > > > > > > (This is migrated from edk2-platforms:Silicon/RISC-V) > > > > > > > > > > > > > > RISC-V processor package library definitions. > > > > > > > > > > > > > > IndustryStandard/RiscV.h > > > > > > > -Add RiscV.h which conform with RISC-V Privilege Spec v1.10. > > > > > > > > > > > > > > RiscVImpl.h > > > > > > > -Definition of EDK2 RISC-V implementation. > > > > > > > > > > > > > > Signed-off-by: Abner Chang > > > > > > > <abner.ch...@hpe.com<mailto:abner.ch...@hpe.com>> > > > > > > > Co-authored-by: Daniel Schaefer > > > > > > > <daniel.schae...@hpe.com<mailto:daniel.schae...@hpe.com>> > > > > > > > Co-authored-by: Gilbert Chen > > > > > > > <gilbert.c...@hpe.com<mailto:gilbert.c...@hpe.com>> > > > > > > > Reviewed-by: Leif Lindholm > > > > > > > <leif.lindh...@linaro.org<mailto:leif.lindh...@linaro.org>> > > > > > > > > > > > > Hmm, no. > > > > > > I gave a reviewed-by for that patch to be merged into edk2-platforms > > > > > > once upon a time. This is not relevant for migration to edk2. > > > > > > > > > > > > My proposal for migrating this code would be as follows: > > > > > > - Announce a hold on merging new code to RiscV portions of > > > > > > edk2-platforms. > > > > > > - Apply any and all bugfixes and CI/uncrustify fixes in place in > > > > > > edk2-platforms. > > > > > > - Get some level of agreement for what to do instead of > > > > > > RiscVPlatformPkg - i.e. slot into MdeModulePkg instead. > > > > > > - If that cannot be reached within a few days, create a new > > > > > > top-level directory called "CommonPlatformPkg" or something, > > > > > > with you, Daniel(/Gilbert?), Sami, me as maintainers. > > > > > > - Move all of the RiscVPlatformPkg code under there instead. > > > > > > - I'll follow with ArmPlatformPkg. > > > > > > - PC/AT code should move across too over time. > > > > > > - Move the rest of the code across unmodified as massive single > > > > > > patches per package (potentially more patches than that for > > > > > > RiscVPlatformPkg). > > > > > > - Drop all existing Reviewed-by/Acked-by. > > > > > > - After each "move" patch, insert a "fixup" patch to address the > > > > > > things that need fixing due to path/name changes. > > > > > > > > > > > > / > > > > > > Leif > > > > > > > > > > > > > Cc: Leif Lindholm > > > > > > > <leif.lindh...@linaro.org<mailto:leif.lindh...@linaro.org>> > > > > > > > Cc: Gilbert Chen > > > > > > > <gilbert.c...@hpe.com<mailto:gilbert.c...@hpe.com>> > > > > > > > --- > > > > > > > .../Include/IndustryStandard/RiscV.h | 156 > > ++++++++++++++++++ > > > > > > > .../RISC-V/ProcessorPkg/Include/RiscVImpl.h | 87 ++++++++++ > > > > > > > 2 files changed, 243 insertions(+) > > > > > > > create mode 100644 Silicon/RISC- > > > > V/ProcessorPkg/Include/IndustryStandard/RiscV.h > > > > > > > create mode 100644 Silicon/RISC- > > V/ProcessorPkg/Include/RiscVImpl.h > > > > > > > > > > > > > > diff --git a/Silicon/RISC- > > > > V/ProcessorPkg/Include/IndustryStandard/RiscV.h b/Silicon/RISC- > > > > > > V/ProcessorPkg/Include/IndustryStandard/RiscV.h > > > > > > > new file mode 100644 > > > > > > > index 0000000000..2a992394ed > > > > > > > --- /dev/null > > > > > > > +++ b/Silicon/RISC- > > V/ProcessorPkg/Include/IndustryStandard/RiscV.h > > > > > > > @@ -0,0 +1,156 @@ > > > > > > > +/** @file > > > > > > > + RISC-V package definitions. > > > > > > > + > > > > > > > + Copyright (c) 2019, Hewlett Packard Enterprise Development LP. > > All > > > > rights reserved.<BR> > > > > > > > + > > > > > > > + SPDX-License-Identifier: BSD-2-Clause-Patent > > > > > > > + > > > > > > > +**/ > > > > > > > + > > > > > > > +#ifndef RISCV_INDUSTRY_STANDARD_H_ > > > > > > > +#define RISCV_INDUSTRY_STANDARD_H_ > > > > > > > + > > > > > > > +#if defined (MDE_CPU_RISCV64) > > > > > > > +#define RISC_V_XLEN_BITS 64 > > > > > > > +#else > > > > > > > +#endif > > > > > > > + > > > > > > > +#define RISC_V_ISA_ATOMIC_EXTENSION (0x00000001 > > > > > > > << > > 0) > > > > > > > +#define RISC_V_ISA_BIT_OPERATION_EXTENSION > > (0x00000001 > > > > << 1) > > > > > > > +#define RISC_V_ISA_COMPRESSED_EXTENSION (0x00000001 > > << > > > > 2) > > > > > > > +#define RISC_V_ISA_DOUBLE_PRECISION_FP_EXTENSION > > > > (0x00000001 << 3) > > > > > > > +#define RISC_V_ISA_RV32E_ISA (0x00000001 > > > > > > > << 4) > > > > > > > +#define RISC_V_ISA_SINGLE_PRECISION_FP_EXTENSION > > > > (0x00000001 << 5) > > > > > > > +#define RISC_V_ISA_ADDITIONAL_STANDARD_EXTENSION > > > > (0x00000001 << 6) > > > > > > > +#define RISC_V_ISA_RESERVED_1 (0x00000001 > > > > > > > << 7) > > > > > > > +#define RISC_V_ISA_INTEGER_ISA_EXTENSION (0x00000001 > > << > > > > 8) > > > > > > > +#define > > > > RISC_V_ISA_DYNAMICALLY_TRANSLATED_LANGUAGE_EXTENSION > > > > (0x00000001 << 9) > > > > > > > +#define RISC_V_ISA_RESERVED_2 (0x00000001 > > > > > > > << 10) > > > > > > > +#define RISC_V_ISA_DECIMAL_FP_EXTENSION (0x00000001 > > << > > > > 11) > > > > > > > +#define RISC_V_ISA_INTEGER_MUL_DIV_EXTENSION > > (0x00000001 > > > > << 12) > > > > > > > +#define RISC_V_ISA_USER_LEVEL_INTERRUPT_SUPPORTED > > > > (0x00000001 << 13) > > > > > > > +#define RISC_V_ISA_RESERVED_3 (0x00000001 > > > > > > > << 14) > > > > > > > +#define RISC_V_ISA_PACKED_SIMD_EXTENSION > > (0x00000001 << > > > > 15) > > > > > > > +#define RISC_V_ISA_QUAD_PRECISION_FP_EXTENSION > > > > (0x00000001 << 16) > > > > > > > +#define RISC_V_ISA_RESERVED_4 (0x00000001 > > > > > > > << 17) > > > > > > > +#define RISC_V_ISA_SUPERVISOR_MODE_IMPLEMENTED > > > > (0x00000001 << 18) > > > > > > > +#define RISC_V_ISA_TRANSATIONAL_MEMORY_EXTENSION > > > > (0x00000001 << 19) > > > > > > > +#define RISC_V_ISA_USER_MODE_IMPLEMENTED > > (0x00000001 > > > > << 20) > > > > > > > +#define RISC_V_ISA_VECTOR_EXTENSION (0x00000001 > > > > > > > << > > 21) > > > > > > > +#define RISC_V_ISA_RESERVED_5 (0x00000001 > > > > > > > << 22) > > > > > > > +#define RISC_V_ISA_NON_STANDARD_EXTENSION > > (0x00000001 > > > > << 23) > > > > > > > +#define RISC_V_ISA_RESERVED_6 (0x00000001 > > > > > > > << 24) > > > > > > > +#define RISC_V_ISA_RESERVED_7 (0x00000001 > > > > > > > << 25) > > > > > > > + > > > > > > > +// > > > > > > > +// RISC-V CSR definitions. > > > > > > > +// > > > > > > > +// > > > > > > > +// Machine information > > > > > > > +// > > > > > > > +#define RISCV_CSR_MACHINE_MVENDORID 0xF11 > > > > > > > +#define RISCV_CSR_MACHINE_MARCHID 0xF12 > > > > > > > +#define RISCV_CSR_MACHINE_MIMPID 0xF13 > > > > > > > +#define RISCV_CSR_MACHINE_HARRID 0xF14 > > > > > > > +// > > > > > > > +// Machine Trap Setup. > > > > > > > +// > > > > > > > +#define RISCV_CSR_MACHINE_MSTATUS 0x300 > > > > > > > +#define RISCV_CSR_MACHINE_MISA 0x301 > > > > > > > +#define RISCV_CSR_MACHINE_MEDELEG 0x302 > > > > > > > +#define RISCV_CSR_MACHINE_MIDELEG 0x303 > > > > > > > +#define RISCV_CSR_MACHINE_MIE 0x304 > > > > > > > +#define RISCV_CSR_MACHINE_MTVEC 0x305 > > > > > > > + > > > > > > > +#define RISCV_TIMER_COMPARE_BITS 32 > > > > > > > +// > > > > > > > +// Machine Timer and Counter. > > > > > > > +// > > > > > > > +//#define RISCV_CSR_MACHINE_MTIME 0x701 > > > > > > > +//#define RISCV_CSR_MACHINE_MTIMEH 0x741 > > > > > > > +// > > > > > > > +// Machine Trap Handling. > > > > > > > +// > > > > > > > +#define RISCV_CSR_MACHINE_MSCRATCH 0x340 > > > > > > > +#define RISCV_CSR_MACHINE_MEPC 0x341 > > > > > > > +#define RISCV_CSR_MACHINE_MCAUSE 0x342 > > > > > > > + #define MACHINE_MCAUSE_EXCEPTION_ MASK 0x0f > > > > > > > + #define MACHINE_MCAUSE_INTERRUPT (RISC_V_XLEN_BITS - > > 1) > > > > > > > +#define RISCV_CSR_MACHINE_MBADADDR 0x343 > > > > > > > +#define RISCV_CSR_MACHINE_MIP 0x344 > > > > > > > + > > > > > > > +// > > > > > > > +// Machine Protection and Translation. > > > > > > > +// > > > > > > > +#define RISCV_CSR_MACHINE_MBASE 0x380 > > > > > > > +#define RISCV_CSR_MACHINE_MBOUND 0x381 > > > > > > > +#define RISCV_CSR_MACHINE_MIBASE 0x382 > > > > > > > +#define RISCV_CSR_MACHINE_MIBOUND 0x383 > > > > > > > +#define RISCV_CSR_MACHINE_MDBASE 0x384 > > > > > > > +#define RISCV_CSR_MACHINE_MDBOUND 0x385 > > > > > > > + > > > > > > > +// > > > > > > > +// Supervisor mode CSR. > > > > > > > +// > > > > > > > +#define RISCV_CSR_SUPERVISOR_SSTATUS 0x100 > > > > > > > + #define SSTATUS_SIE_BIT_POSITION 1 > > > > > > > + #define SSTATUS_SPP_BIT_POSITION 8 > > > > > > > +#define RISCV_CSR_SUPERVISOR_SIE 0x104 > > > > > > > +#define RISCV_CSR_SUPERVISOR_SSCRATCH 0x140 > > > > > > > +#define RISCV_CSR_SUPERVISOR_SEPC 0x141 > > > > > > > +#define RISCV_CSR_SUPERVISOR_SCAUSE 0x142 > > > > > > > + #define SCAUSE_USER_SOFTWARE_INT 0 > > > > > > > + #define SCAUSE_SUPERVISOR_SOFTWARE_INT 1 > > > > > > > + #define SCAUSE_USER_TIMER_INT 4 > > > > > > > + #define SCAUSE_SUPERVISOR_TIMER_INT 5 > > > > > > > + #define SCAUSE_USER_EXTERNAL_INT 8 > > > > > > > + #define SCAUSE_SUPERVISOR_EXTERNAL_INT 9 > > > > > > > +#define RISCV_CSR_SUPERVISOR_STVAL 0x143 > > > > > > > +#define RISCV_CSR_SUPERVISOR_SIP 0x144 > > > > > > > +#define RISCV_CSR_SUPERVISOR_SATP 0x180 > > > > > > > + > > > > > > > +#if defined (MDE_CPU_RISCV64) > > > > > > > + #define RISCV_SATP_MODE_MASK 0xF000000000000000 > > > > > > > + #define RISCV_SATP_MODE_BIT_POSITION 60 > > > > > > > +#endif > > > > > > > + #define RISCV_SATP_MODE_OFF 0 > > > > > > > + #define RISCV_SATP_MODE_SV32 1 > > > > > > > + #define RISCV_SATP_MODE_SV39 8 > > > > > > > + #define RISCV_SATP_MODE_SV48 9 > > > > > > > + #define RISCV_SATP_MODE_SV57 10 > > > > > > > + #define RISCV_SATP_MODE_SV64 11 > > > > > > > + > > > > > > > + #define SATP64_ASID_MASK 0x0FFFF00000000000 > > > > > > > + #define SATP64_PPN_MASK 0x00000FFFFFFFFFFF > > > > > > > + > > > > > > > +#define RISCV_CAUSE_MISALIGNED_FETCH 0x0 > > > > > > > +#define RISCV_CAUSE_FETCH_ACCESS 0x1 > > > > > > > +#define RISCV_CAUSE_ILLEGAL_INSTRUCTION 0x2 > > > > > > > +#define RISCV_CAUSE_BREAKPOINT 0x3 > > > > > > > +#define RISCV_CAUSE_MISALIGNED_LOAD 0x4 > > > > > > > +#define RISCV_CAUSE_LOAD_ACCESS 0x5 > > > > > > > +#define RISCV_CAUSE_MISALIGNED_STORE 0x6 > > > > > > > +#define RISCV_CAUSE_STORE_ACCESS 0x7 > > > > > > > +#define RISCV_CAUSE_USER_ECALL 0x8 > > > > > > > +#define RISCV_CAUSE_HYPERVISOR_ECALL 0x9 > > > > > > > +#define RISCV_CAUSE_SUPERVISOR_ECALL 0xa > > > > > > > +#define RISCV_CAUSE_MACHINE_ECALL 0xb > > > > > > > +#define RISCV_CAUSE_FETCH_PAGE_FAULT 0xc > > > > > > > +#define RISCV_CAUSE_LOAD_PAGE_FAULT 0xd > > > > > > > +#define RISCV_CAUSE_STORE_PAGE_FAULT 0xf > > > > > > > +#define RISCV_CAUSE_FETCH_GUEST_PAGE_FAULT 0x14 > > > > > > > +#define RISCV_CAUSE_LOAD_GUEST_PAGE_FAULT 0x15 > > > > > > > +#define RISCV_CAUSE_STORE_GUEST_PAGE_FAULT 0x17 > > > > > > > + > > > > > > > +// > > > > > > > +// Machine Read-Write Shadow of Hypervisor Read-Only Registers > > > > > > > +// > > > > > > > +#define RISCV_CSR_HTIMEW 0xB01 > > > > > > > +#define RISCV_CSR_HTIMEHW 0xB81 > > > > > > > +// > > > > > > > +// Machine Host-Target Interface (Non-Standard Berkeley > > Extension) > > > > > > > +// > > > > > > > +#define RISCV_CSR_MTOHOST 0x780 > > > > > > > +#define RISCV_CSR_MFROMHOST 0x781 > > > > > > > + > > > > > > > +#endif > > > > > > > diff --git a/Silicon/RISC-V/ProcessorPkg/Include/RiscVImpl.h > > > > b/Silicon/RISC-V/ProcessorPkg/Include/RiscVImpl.h > > > > > > > new file mode 100644 > > > > > > > index 0000000000..14092df174 > > > > > > > --- /dev/null > > > > > > > +++ b/Silicon/RISC-V/ProcessorPkg/Include/RiscVImpl.h > > > > > > > @@ -0,0 +1,87 @@ > > > > > > > +/** @file > > > > > > > + RISC-V package definitions. > > > > > > > + > > > > > > > + Copyright (c) 2016 - 2019, Hewlett Packard Enterprise > > Development > > > > LP. All rights reserved.<BR> > > > > > > > + > > > > > > > + SPDX-License-Identifier: BSD-2-Clause-Patent > > > > > > > + > > > > > > > +**/ > > > > > > > + > > > > > > > +#ifndef RISCV_H_ > > > > > > > +#define RISCV_H_ > > > > > > > + > > > > > > > +#include <Uefi.h> > > > > > > > +#include <IndustryStandard/RiscV.h> > > > > > > > + > > > > > > > +#define _ASM_FUNC(Name, Section) \ > > > > > > > + .global Name ; \ > > > > > > > + .section #Section, "ax" ; \ > > > > > > > + .type Name, %function ; \ > > > > > > > + .p2align 2 ; \ > > > > > > > + Name: > > > > > > > + > > > > > > > +#define ASM_FUNC(Name) _ASM_FUNC(ASM_PFX(Name), .text. > > ## > > > > Name) > > > > > > > + > > > > > > > +#if defined (MDE_CPU_RISCV64) > > > > > > > +typedef UINT64 RISC_V_REGS_PROTOTYPE; > > > > > > > +#else > > > > > > > +#endif > > > > > > > + > > > > > > > +// > > > > > > > +// Structure for 128-bit value > > > > > > > +// > > > > > > > +typedef struct { > > > > > > > + UINT64 Value64_L; > > > > > > > + UINT64 Value64_H; > > > > > > > +} RISCV_UINT128; > > > > > > > + > > > > > > > +#define RISCV_MACHINE_CONTEXT_SIZE 0x1000 > > > > > > > +typedef struct _RISCV_MACHINE_MODE_CONTEXT > > > > RISCV_MACHINE_MODE_CONTEXT; > > > > > > > + > > > > > > > +/// > > > > > > > +/// Exception handlers in context. > > > > > > > +/// > > > > > > > +typedef struct _EXCEPTION_HANDLER_CONTEXT { > > > > > > > + EFI_PHYSICAL_ADDRESS InstAddressMisalignedHander; > > > > > > > + EFI_PHYSICAL_ADDRESS InstAccessFaultHander; > > > > > > > + EFI_PHYSICAL_ADDRESS IllegalInstHander; > > > > > > > + EFI_PHYSICAL_ADDRESS BreakpointHander; > > > > > > > + EFI_PHYSICAL_ADDRESS LoadAddrMisalignedHander; > > > > > > > + EFI_PHYSICAL_ADDRESS LoadAccessFaultHander; > > > > > > > + EFI_PHYSICAL_ADDRESS StoreAmoAddrMisalignedHander; > > > > > > > + EFI_PHYSICAL_ADDRESS StoreAmoAccessFaultHander; > > > > > > > + EFI_PHYSICAL_ADDRESS EnvCallFromUModeHander; > > > > > > > + EFI_PHYSICAL_ADDRESS EnvCallFromSModeHander; > > > > > > > + EFI_PHYSICAL_ADDRESS EnvCallFromHModeHander; > > > > > > > + EFI_PHYSICAL_ADDRESS EnvCallFromMModeHander; > > > > > > > +} EXCEPTION_HANDLER_CONTEXT; > > > > > > > + > > > > > > > +/// > > > > > > > +/// Exception handlers in context. > > > > > > > +/// > > > > > > > +typedef struct _INTERRUPT_HANDLER_CONTEXT { > > > > > > > + EFI_PHYSICAL_ADDRESS SoftwareIntHandler; > > > > > > > + EFI_PHYSICAL_ADDRESS TimerIntHandler; > > > > > > > +} INTERRUPT_HANDLER_CONTEXT; > > > > > > > + > > > > > > > +/// > > > > > > > +/// Interrupt handlers in context. > > > > > > > +/// > > > > > > > +typedef struct _TRAP_HANDLER_CONTEXT { > > > > > > > + EXCEPTION_HANDLER_CONTEXT ExceptionHandlerContext; > > > > > > > + INTERRUPT_HANDLER_CONTEXT IntHandlerContext; > > > > > > > +} TRAP_HANDLER_CONTEXT; > > > > > > > + > > > > > > > +/// > > > > > > > +/// Machine mode context used for saveing hart-local context. > > > > > > > +/// > > > > > > > +typedef struct _RISCV_MACHINE_MODE_CONTEXT { > > > > > > > + EFI_PHYSICAL_ADDRESS PeiService; /// PEI > > > > > > > service. > > > > > > > + EFI_PHYSICAL_ADDRESS MachineModeTrapHandler; /// > > Machine > > > > mode trap handler. > > > > > > > + EFI_PHYSICAL_ADDRESS HypervisorModeTrapHandler; /// > > Hypervisor > > > > mode trap handler. > > > > > > > + EFI_PHYSICAL_ADDRESS SupervisorModeTrapHandler; /// > > Supervisor > > > > mode trap handler. > > > > > > > + EFI_PHYSICAL_ADDRESS UserModeTrapHandler; /// USer > > mode > > > > trap handler. > > > > > > > + TRAP_HANDLER_CONTEXT MModeHandler; /// Handler for > > > > machine mode. > > > > > > > +} RISCV_MACHINE_MODE_CONTEXT; > > > > > > > + > > > > > > > +#endif > > > > > > > -- > > > > > > > 2.31.1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#87263): https://edk2.groups.io/g/devel/message/87263 Mute This Topic: https://groups.io/mt/89466486/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
