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 (#87125): https://edk2.groups.io/g/devel/message/87125
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]
-=-=-=-=-=-=-=-=-=-=-=-


Reply via email to