Re: [edk2-devel] [PATCH v2] XiangshanSeriesPkg:Add BOSC NanhuDev platform

[Sunil V L]

On Wed, May 22, 2024 at 03:25:37PM +0800, WangYang via groups.io wrote:
> Hi,Suni V L 
> 
> Are you willing to serve as edk2-platforms/Platform/Bosc/* and 
> edk2-platforms/Silicon/Bosc/* platform maintainer?
> 
Hi Yang Wang,

Please have someone who has knowledge about the platform code as the
mandatory reviewer. I can help with merging but I will depend upon that
reviewer.

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#119116): https://edk2.groups.io/g/devel/message/119116
Mute This Topic: https://groups.io/mt/105437172/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: 回复：[Internet]Re: [edk2-devel] [PATCH] Added support for ACPI related data structures for RISC_V64 platform

[Sunil V L]

On Mon, May 06, 2024 at 10:54:45AM +0800, dylanlhdu(杜林恒) wrote:
> Hi Sunil,
> 
> 
> 
> We mainly want to use UEFI+ACPI mode to start RISCV64 server. However, during 
> the development process, we found that ACPI(6.5) in the current version of 
> UEFI does not support riscv for the time being. In order to solve this 
> problem, We refer to the upstream RISC-V ACPI platform specification provided 
> by Ventana to implement RISC-V ACPI support, so adding this header file can 
> make ACPI support RISCV architecture until the new version of ACPI 
> specification supports RISCV architecture.
> 
Understood. But adding as 6_5* doesn't make sense.

I will let maintainers of MdePkg to comment. I don't know
whether they can accept approved ECRs but not yet released spec.

Thanks,
Sunil

> 
> 
> 
> 
> 
> 
> Thanks
> 
> 
> 
> 
> 发自我的企业微信
> 
> 
> 
> 
> 
>  --回复的邮件信息--
>Sunil V L 
> Hi Lingheng Du,
> 
> What is the use of adding this header file and how did you create it? I
> think EDK2 needs ACPI spec to be released to get these definitions
> added. Also, these are not part of 6.5 and hence names like
> EFI_ACPI_6_5* are incorrect. So, it will be helpful if you add some
> commit message why do we need this header.
> 
> Thanks,
> Sunil
> On Mon, Apr 29, 2024 at 05:53:55PM +0800, gaoliming via groups.io wrote:
>  From: dylanlhdu   
>  Signed-off-by: Lingheng 
> Du   Reviewed-by: Song 
> Huang   Reviewed-by: Bing Fan 
>   ---
>  .../Include/IndustryStandard/AcpiRiscv64.h | 176 
> ++
>  1 file changed, 176 insertions(+)
>  create mode 100644 
> edk2/MdePkg/Include/IndustryStandard/AcpiRiscv64.h
>  
>  diff --git a/edk2/MdePkg/Include/IndustryStandard/AcpiRiscv64.h 
> b/edk2/MdePkg/Include/IndustryStandard/AcpiRiscv64.h
>  new file mode 100644
>  index ..4111b3ea
>  --- /dev/null
>  +++ b/edk2/MdePkg/Include/IndustryStandard/AcpiRiscv64.h
>  @@ -0,0 +1,176 @@
>  +/** @file
>  + RISCV64 platform ACPI related support April, 2022.
>  +
>  + SPDX-License-Identifier: BSD-2-Clause-Patent
>  +**/
>  +
>  +#ifndef ACPI_RISCV64_H_
>  +#define ACPI_RISCV64_H_
>  +
>  +//
>  +// Ensure proper structure formats
>  +//
>  +#pragma pack(1)
>  +
>  +///
>  +/// RISC-V Interrupt Type
>  +///
>  +#define EFI_ACPI_6_5_INC_RINTC_TYPE 0x18
>  +#define EFI_ACPI_6_5_INC_IMSIC_TYPE 0x19
>  +#define EFI_ACPI_6_5_INC_APLIC_TYPE 0x1A
>  +#define EFI_ACPI_6_5_INC_PLIC_TYPE 0x1B
>  +
>  +///
>  +/// RISC-V Interrupt Controller (RINTC)
>  +///
>  +typedef struct {
>  + UINT8 Type;
>  + UINT8 Length;
>  + UINT8 Version;
>  + UINT8 Reserved;
>  + UINT32 Flags;
>  + UINT64 HartId;
>  + UINT32 Uid;
>  + UINT32 ExtIntcId;
>  + UINT64 ImsicAddr;
>  + UINT32 ImsicSize;
>  +} EFI_ACPI_6_5_INC_RINTC_STRUCTURE;
>  +
>  +///
>  +/// Incoming MSI Controller (IMSIC)
>  +///
>  +typedef struct {
>  + UINT8 Type;
>  + UINT8 Length;
>  + UINT8 Version;
>  + UINT8 Reserved;
>  + UINT32 Flags;
>  + UINT16 NumIds;
>  + UINT16 NumGuestIds;
>  + UINT8 GuestIndexBits;
>  + UINT8 HartIndexBits;
>  + UINT8 GroupIndexBits;
>  + UINT8 GroupIndexShift;
>  +} EFI_ACPI_6_5_INC_IMSIC_STRUCTURE;
>  +
>  +///
>  +/// RISC-V Advanced Platform Level Interrupt Controller (APLIC)
>  +///
>  +typedef struct {
>  + UINT8 Type;
>  + UINT8 Length;
>  + UINT8 Version;
>  + UINT8 AplicId;
>  + UINT32 Flags;
>  + UINT8 HW_ID[8];
>  + UINT16 NumIdc;
>  + UINT16 ExternSoureceSupport;
>  + UINT32 GSysInterruptBase;
>  + UINT64 AplicAddress;
>  + UINT32 AplicSize;
>  +} EFI_ACPI_6_5_INC_APLIC_STRUCTURE;
>  +
>  +///
>  +/// RISC-V Platform Level Interrupt Controller (PLIC)
>  +///
>  +typedef struct {
>  + UINT8 Type;
>  + UINT8 Length;
>  + UINT8 Version;
>  + UINT8 PlicId;
>  + UINT8 HwId[8];
>  + UINT16 NumIrqs;
>  + UINT16 MaxPrio;
>  + UINT32 Flags;
>  + UINT32 PlicSize;
>  + UINT64 PlicAddress;
>  + UINT32 GsiBase;
>  +} EFI_ACPI_6_5_INC_PLIC_STRUCTURE;
>  +
>  +///
>  +/// RISC-V Hart Capabilities Table (RHCT)
>  +///
>  +typedef struct {
>  + EFI_ACPI_DESCRIPTION_HEADER Header;
>  +} EFI_ACPI_6_5_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE_HEADER;
>  +
>  +///
>  +/// RHCT Revision
>  +///
>  +#define EFI_ACPI_6_5_RHCT_APIC_DESCRIPTION_TABLE_REVISION 0x05
>  +
>  +///
>  +/// RHCT types
>  +///
>  +#define EFI_ACPI_6_5_NODE_ISA_TYPE 
> 0x0
>  +#define EFI_ACPI_6_5_NODE_CM0_TYPE 
> 0x1
>  +#define EFI_ACPI_6_5_NODE_MMU_TYPE 
> 0x2
>  +#define EFI_ACPI_6_5_NODE_RESERVED_TYPE 0x3
>  +#define EFI_ACPI_6_5_NODE_HART_TYPE 0

Re: [edk2-devel] [PATCH] Added support for ACPI related data structures for RISC_V64 platform

[Sunil V L]

Hi Lingheng Du,

What is the use of adding this header file and how did you create it? I
think EDK2 needs ACPI spec to be released to get these definitions
added. Also, these are not part of 6.5 and hence names like
EFI_ACPI_6_5* are incorrect. So, it will be helpful if you add some
commit message why do we need this header.

Thanks,
Sunil
On Mon, Apr 29, 2024 at 05:53:55PM +0800, gaoliming via groups.io wrote:
> From: dylanlhdu 
> 
> Signed-off-by: Lingheng Du 
> Reviewed-by: Song Huang  
> Reviewed-by: Bing Fan 
> ---
>  .../Include/IndustryStandard/AcpiRiscv64.h| 176 ++
>  1 file changed, 176 insertions(+)
>  create mode 100644 edk2/MdePkg/Include/IndustryStandard/AcpiRiscv64.h
> 
> diff --git a/edk2/MdePkg/Include/IndustryStandard/AcpiRiscv64.h 
> b/edk2/MdePkg/Include/IndustryStandard/AcpiRiscv64.h
> new file mode 100644
> index ..4111b3ea
> --- /dev/null
> +++ b/edk2/MdePkg/Include/IndustryStandard/AcpiRiscv64.h
> @@ -0,0 +1,176 @@
> +/** @file
> +  RISCV64 platform ACPI related support April, 2022.
> +
> +  SPDX-License-Identifier: BSD-2-Clause-Patent
> +**/
> +
> +#ifndef ACPI_RISCV64_H_
> +#define ACPI_RISCV64_H_
> +
> +//
> +// Ensure proper structure formats
> +//
> +#pragma pack(1)
> +
> +///
> +/// RISC-V Interrupt Type
> +///
> +#define EFI_ACPI_6_5_INC_RINTC_TYPE  0x18
> +#define EFI_ACPI_6_5_INC_IMSIC_TYPE  0x19
> +#define EFI_ACPI_6_5_INC_APLIC_TYPE  0x1A
> +#define EFI_ACPI_6_5_INC_PLIC_TYPE   0x1B
> +
> +///
> +///  RISC-V Interrupt Controller (RINTC)
> +///
> +typedef struct {
> +  UINT8 Type;
> +  UINT8 Length;
> +  UINT8 Version;
> +  UINT8 Reserved;
> +  UINT32Flags;
> +  UINT64HartId;
> +  UINT32Uid;
> +  UINT32ExtIntcId;
> +  UINT64ImsicAddr;
> +  UINT32ImsicSize;
> +} EFI_ACPI_6_5_INC_RINTC_STRUCTURE;
> +
> +///
> +///  Incoming MSI Controller (IMSIC)
> +///
> +typedef struct {
> +  UINT8 Type;
> +  UINT8 Length;
> +  UINT8 Version;
> +  UINT8 Reserved;
> +  UINT32Flags;
> +  UINT16NumIds;
> +  UINT16NumGuestIds;
> +  UINT8 GuestIndexBits;
> +  UINT8 HartIndexBits;
> +  UINT8 GroupIndexBits;
> +  UINT8 GroupIndexShift;
> +} EFI_ACPI_6_5_INC_IMSIC_STRUCTURE;
> +
> +///
> +///  RISC-V Advanced Platform Level Interrupt Controller (APLIC)
> +///
> +typedef struct {
> +  UINT8 Type;
> +  UINT8 Length;
> +  UINT8 Version;
> +  UINT8 AplicId;
> +  UINT32Flags;
> +  UINT8 HW_ID[8];
> +  UINT16NumIdc;
> +  UINT16ExternSoureceSupport;
> +  UINT32GSysInterruptBase;
> +  UINT64AplicAddress;
> +  UINT32AplicSize;
> +} EFI_ACPI_6_5_INC_APLIC_STRUCTURE;
> +
> +///
> +///   RISC-V Platform Level Interrupt Controller (PLIC)
> +///
> +typedef struct {
> +  UINT8 Type;
> +  UINT8 Length;
> +  UINT8 Version;
> +  UINT8 PlicId;
> +  UINT8 HwId[8];
> +  UINT16NumIrqs;
> +  UINT16MaxPrio;
> +  UINT32Flags;
> +  UINT32PlicSize;
> +  UINT64PlicAddress;
> +  UINT32GsiBase;
> +} EFI_ACPI_6_5_INC_PLIC_STRUCTURE;
> +
> +///
> +/// RISC-V Hart Capabilities Table (RHCT)
> +///
> +typedef struct {
> +  EFI_ACPI_DESCRIPTION_HEADERHeader;
> +} EFI_ACPI_6_5_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE_HEADER;
> +
> +///
> +/// RHCT Revision
> +///
> +#define EFI_ACPI_6_5_RHCT_APIC_DESCRIPTION_TABLE_REVISION  0x05
> +
> +///
> +/// RHCT types
> +///
> +#define EFI_ACPI_6_5_NODE_ISA_TYPE   0x0
> +#define EFI_ACPI_6_5_NODE_CM0_TYPE   0x1
> +#define EFI_ACPI_6_5_NODE_MMU_TYPE   0x2
> +#define EFI_ACPI_6_5_NODE_RESERVED_TYPE  0x3
> +#define EFI_ACPI_6_5_NODE_HART_TYPE  0x
> +
> +///
> +/// RHCT Flags
> +///
> +#define ACPI_RHCT_TIMER_CANNOT_WAKEUP_CPU  (1)
> +
> +///
> +/// ISA string node
> +///
> +typedef struct {
> +  UINT16Type;
> +  UINT16Length;
> +  UINT16Revision;
> +  UINT16IsaLength;
> +  UINT8 IsaString[];
> +} EFI_ACPI_6_5_NODE_ISA_STRING_STRUCTURE;
> +
> +///
> +/// CM0 node
> +///
> +typedef struct {
> +  UINT16Type;
> +  UINT16Length;
> +  UINT16Revision;
> +  UINT8 Reserved;
> +  UINT8 CbomSize;
> +  UINT8 CbopSize;
> +  UINT8 CbozSize;
> +} EFI_ACPI_6_5_NODE_CM0_STRUCTURE;
> +
> +///
> +/// MMU node
> +///
> +typedef struct {
> +  UINT16Type;
> +  UINT16Length;
> +  UINT16Revision;
> +  UINT8 Reserved;
> +  UINT8 MmuType;
> +} EFI_ACPI_6_5_NODE_MMU_STRUCTURE;
> +
> +///
> +/// MMU type
> +///
> +#define EFI_ACPI_6_5_MMU_SV39_TYPE  0x0
> +#define EFI_ACPI_6_5_MMU_SV48_TYPE  0x1
> +#define EFI_ACPI_6_5_MMU_SV57_TYPE  0x2
> +
> +///
> +/// Hart Info Node
> +///
> +typedef struct {
> +  UINT16Type;
> +  UINT16Length;
> +  UINT16Revision;
> +  UINT16NumOffsets;
> +  UINT32Uid;
> +} EFI_ACPI_6_5_NODE_HARTINFO_STRUCTURE;
> +
> +///
> +/// "RHCT" RISC-V Hart Capabilities Table
> +///
> +#define EFI_ACPI_6_5_RHCT_HART_DESCRIPTION_TABLE_SIGNATURE  
> SIGNATURE_32('R', 'H', 'C', 'T')
> +
> 

Re: [edk2-devel] [PATCH v2] XiangshanSeriesPkg:Add BOSC NanhuDev platform

[Sunil V L]

On Wed, Apr 10, 2024 at 01:50:12PM +0800, WangYang wrote:
> This commit adds the initial support for BOSC's
> nanhu platform which provides up to 2 RISC-V RV64
> processor cores.
> 
> Signed-off-by: Yang Wang 
> Signed-off-by: Ran Wang 
> Signed-off-by: YunFeng Yang 
> Signed-off-by: YaXing Guo 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Sunil V L 
> Cc: Daniel Schaefer 
> 
> ---
>  V2:This solution is changed to EDK2 as the payload of opensbi.
> 
>  Platform/Bosc/Readme.md   |  61 ++
>  .../XiangshanSeriesPkg/NanhuDev/NanhuDev.dsc  | 552 ++
>  .../XiangshanSeriesPkg/NanhuDev/NanhuDev.fdf  | 241 
>  .../NanhuDev/NanhuDev.fdf.inc |  62 ++
>  .../NanhuDev/VarStore.fdf.inc |  77 +++
>  Silicon/Bosc/NanHuPkg/NanHuDevPkg.dec |  31 +
>  Silicon/Bosc/NanHuPkg/NanHuPkg.uni|  13 +
>  Silicon/Bosc/NanHuPkg/NanHuPkgExtra.uni   |  13 +
>  8 files changed, 1050 insertions(+)
>  create mode 100644 Platform/Bosc/Readme.md
>  create mode 100644 Platform/Bosc/XiangshanSeriesPkg/NanhuDev/NanhuDev.dsc
>  create mode 100644 Platform/Bosc/XiangshanSeriesPkg/NanhuDev/NanhuDev.fdf
>  create mode 100644 Platform/Bosc/XiangshanSeriesPkg/NanhuDev/NanhuDev.fdf.inc
>  create mode 100644 Platform/Bosc/XiangshanSeriesPkg/NanhuDev/VarStore.fdf.inc
>  create mode 100644 Silicon/Bosc/NanHuPkg/NanHuDevPkg.dec
>  create mode 100644 Silicon/Bosc/NanHuPkg/NanHuPkg.uni
>  create mode 100644 Silicon/Bosc/NanHuPkg/NanHuPkgExtra.uni
> 
Acked-by: Sunil V L  


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#118017): https://edk2.groups.io/g/devel/message/118017
Mute This Topic: https://groups.io/mt/105437172/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 0/4] RISC-V: Support Svpbmt extension

[Sunil V L]

On Thu, Mar 14, 2024 at 01:19:13PM -0700, Tuan Phan wrote:
> This series adds support for RISC-V Svpbmt extension.
> 
> The GCD EFI_MEMORY_UC and EFI_MEMORY_WC attributes will
> be mapped to IO and NC mode defined in PBMT field.
> 
> v4:
>   - Changed UINTN to UINT64.
>   - Fixed format error.
>   - Addressed Andrei's comment.
> v3:
>   - Addressed Laszlo's comments.
> v2:
>   - Generated patch for each package.
> 
> Tuan Phan (4):
>   MdePkg.dec: RISC-V: Define override bit for Svpbmt extension
>   UefiCpuPkg: RISC-V: MMU: Explictly use UINT64 instead of UINTN
>   UefiCpuPkg: RISC-V: MMU: Support Svpbmt extension
>   OvmfPkg/RiscVVirt: Disable Svpbmt extension
> 
>  MdePkg/MdePkg.dec |   2 +
>  OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc   |   2 +-
>  .../Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c | 252 +++---
>  .../BaseRiscVMmuLib/BaseRiscVMmuLib.inf   |   1 +
>  4 files changed, 159 insertions(+), 98 deletions(-)
> 
> -- 
Merged as #5535

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117491): https://edk2.groups.io/g/devel/message/117491
Mute This Topic: https://groups.io/mt/104934682/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 3/4] UefiCpuPkg: RISC-V: MMU: Support Svpbmt extension

[Sunil V L]

On Tue, Apr 02, 2024 at 03:42:19PM -0700, Tuan Phan wrote:
> On Tue, Mar 19, 2024 at 9:45 AM Tuan Phan via groups.io  ventanamicro@groups.io> wrote:
> 
> > Hi Sunil,
> >
> > On Mon, Mar 18, 2024 at 6:00 AM Sunil V L 
> > wrote:
> >
> >> Hi Tuan,
> >>
> >> On Thu, Mar 14, 2024 at 01:19:16PM -0700, Tuan Phan wrote:
> >> > The GCD EFI_MEMORY_UC and EFI_MEMORY_WC memory attributes will be
> >> > supported when Svpbmt extension available.
> >> >
> >> > Cc: Gerd Hoffmann 
> >> > Cc: Laszlo Ersek 
> >> > Cc: Rahul Kumar 
> >> > Cc: Ray Ni 
> >> > Signed-off-by: Tuan Phan 
> >> > ---
> >> >  .../Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c | 106 ++
> >> >  .../BaseRiscVMmuLib/BaseRiscVMmuLib.inf   |   1 +
> >> >  2 files changed, 86 insertions(+), 21 deletions(-)
> >> >
> >> > diff --git a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> >> b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> >> > index 46ba4b4709b1..34300dca5c34 100644
> >> > --- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> >> > +++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> >> > @@ -36,6 +36,11 @@
> >> >  #define PTE_PPN_SHIFT 10
> >> >  #define RISCV_MMU_PAGE_SHIFT  12
> >> >
> >> > +#define RISCV_CPU_FEATURE_PBMT_BITMASK  BIT2
> >> > +#define PTE_PBMT_NC BIT61
> >> > +#define PTE_PBMT_IO BIT62
> >> > +#define PTE_PBMT_MASK   (PTE_PBMT_NC | PTE_PBMT_IO)
> >> > +
> >> >  STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57, SATP_MODE_SV48,
> >> SATP_MODE_SV39, SATP_MODE_OFF };
> >> >  STATIC UINTN  mMaxRootTableLevel;
> >> >  STATIC UINTN  mBitPerLevel;
> >> > @@ -487,32 +492,82 @@ UpdateRegionMapping (
> >> >  /**
> >> >Convert GCD attribute to RISC-V page attribute.
> >> >
> >> > -  @param  GcdAttributes The GCD attribute.
> >> > +  @param  GcdAttributes   The GCD attribute.
> >> > +  @param  RiscVAttributes The pointer of RISC-V page attribute.
> >> >
> >> > -  @return   The RISC-V page attribute.
> >> > +  @retval EFI_INVALID_PARAMETER   The RiscVAttributes is NULL or cache
> >> type mask not valid.
> >> > +  @retval EFI_SUCCESS The operation succesfully.
> >> >
> >> >  **/
> >> >  STATIC
> >> > -UINT64
> >> > +EFI_STATUS
> >> >  GcdAttributeToPageAttribute (
> >> > -  IN UINT64  GcdAttributes
> >> > +  IN UINT64   GcdAttributes,
> >> > +  OUT UINT64  *RiscVAttributes
> >> >)
> >> >  {
> >> > -  UINT64  RiscVAttributes;
> >> > +  UINT64   CacheTypeMask;
> >> > +  BOOLEAN  PmbtExtEnabled;
> >> >
> >> Why not read the PCD once and save in a static variable?
> >>
> > I can put it into a static variable if you think it is more clean.
> >
> Looks like PcdRiscVFeatureOverride can be a patchable PCD so putting it to
> a static variable may not work.
> 
I don't think that will be an issue for this use case. But I don't have
major issue keeping like this itself.

> >
> >> > -  RiscVAttributes = RISCV_PG_R | RISCV_PG_W | RISCV_PG_X;
> >> > +  if (RiscVAttributes == NULL) {
> >> > +return EFI_INVALID_PARAMETER;
> >> > +  }
> >> > +
> >> > +  *RiscVAttributes = RISCV_PG_R | RISCV_PG_W | RISCV_PG_X;
> >> > +
> >> > +  PmbtExtEnabled = FALSE;
> >> > +  if ((PcdGet64 (PcdRiscVFeatureOverride) &
> >> RISCV_CPU_FEATURE_PBMT_BITMASK) != 0) {
> >> > +PmbtExtEnabled = TRUE;
> >> > +  }
> >> >
> >> >// Determine protection attributes
> >> >if ((GcdAttributes & EFI_MEMORY_RO) != 0) {
> >> > -RiscVAttributes &= ~(UINT64)(RISCV_PG_W);
> >> > +*RiscVAttributes &= ~(UINT64)(RISCV_PG_W);
> >> >}
> >> >
> >> >// Process eXecute Never attribute
> >> >if ((GcdAttributes & EFI_MEMORY_XP) != 0) {
> >> > -RiscVAttributes &= ~(UINT64)RISCV_PG_X;
> >> > +*RiscVAttributes &= ~(UINT64)RISCV_PG_X;
> >> > +  }
> >> > +
> >> > +  CacheTypeMas

Re: [edk2-devel] [PATCH] SG2042Pkg/Sec:Modify Calculation LowestMemSize

[Sunil V L]

On Mon, Apr 08, 2024 at 11:00:47AM +0800, WangYang wrote:
> Hi, Sunil V L
>Do I still need to send a v2 version of the RB tag with “Jingyu Li 
> ”? 
>Or did you help add RB tag with “Jingyu Li ” 
> during the merger?
> 
Never mind. I have updated the RB tags and merged as #134.

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117489): https://edk2.groups.io/g/devel/message/117489
Mute This Topic: https://groups.io/mt/105131337/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 00/16] DynamicTablesPkg: Move objects to Arch Common NameSpace (first)

[Sunil V L]

On Thu, Mar 21, 2024 at 04:53:03PM +0100, Pierre Gondois wrote:
> Following [1] and [2], other architectures than Arm aim to leverage
> the DynamicTablesPkg. The package uses namespaces/domains to split
> objects IDs. Currently most of the objects are part of the Arm
> namespace. Some objects are generic enough to be re-used by other
> architectures.
> 
> In [2], an Arch Common namespace Id was created and some objects
> present in the Arm namespace were identified to be moved to this
> Arch Common namespace.
> Continue the effort by moving these objects to this new namespace.
> 
> Some platforms rely on the DynamicTablesPkg and its namespace
> organization. Additional patches matching this change for the:
> - Juno
> - VExpress
> platforms will be submitted along this patchset.
> 
> As the actual patchset is more than 20 patches, split it in
> two parts to avoid being detected as a spam/fraudulous activity.
> 
> [1] Branch to reorg Dynamic Tables & support other arch
> https://edk2.groups.io/g/devel/topic/104054584#116308
> [2] DynamicTablesPkg: Arch Common Namespace
> https://edk2.groups.io/g/devel/message/116330
> 
> Cc: Sami Mujawar 
> Cc: Pierre Gondois 
> Cc: Yeo Reum Yun 
> Cc: Sunil V L 
> Cc: AbdulLateef Attar 
> Cc: Jeshua Smith 
> Cc: Jeff Brasen 
> Cc: Girish Mahadevan 
> Cc: Leif Lindholm 
> Cc: Meenakshi Aggarwal 
> 
Hi Pierre, Sami,

Thank you very much for doing this!. The series look good to me.

Reviewed-by: Sunil V L 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117422): https://edk2.groups.io/g/devel/message/117422
Mute This Topic: https://groups.io/mt/105067964/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] SG2042Pkg/Sec:Modify Calculation LowestMemSize

[Sunil V L]

On Mon, Mar 25, 2024 at 10:09:28AM +0800, Yang Wang wrote:
> Adapting memory addresses may not start from 0x0,
> for example, the starting memory address starts
> from 0x8000_.
> 
> I understand: LowestMemBase is the lowest DDR
> address in the system.
> 
> UefiMemoryBase = LowestMemBase +
> CodeSize(opensbi+UEFI);
> 
> LowestMemSize -= CodeSize(UefiMemoryBase -
> LowestMemBase)
> 
> Cc: Sunil V L 
> Cc: USER0FISH 
> Cc: caiyuqing379 
> Cc: dahogn 
> Cc: meng-cz 
> 
> Signed-off-by: Yang Wang 
> ---
>  Silicon/Sophgo/SG2042Pkg/Sec/Memory.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Silicon/Sophgo/SG2042Pkg/Sec/Memory.c 
> b/Silicon/Sophgo/SG2042Pkg/Sec/Memory.c
> index df49a17695..a160278eaa 100644
> --- a/Silicon/Sophgo/SG2042Pkg/Sec/Memory.c
> +++ b/Silicon/Sophgo/SG2042Pkg/Sec/Memory.c
> @@ -301,8 +301,8 @@ MemoryPeimInitialization (
>}
>  
>if (UefiMemoryBase > LowestMemBase) {
> +LowestMemSize -= (UefiMemoryBase - LowestMemBase);
>  LowestMemBase = UefiMemoryBase;
> -    LowestMemSize -= UefiMemoryBase;
>}
>  
LGTM.

Jingyu, Do you mind adding RB tag?

Reviewed-by: Sunil V L 

Thanks!


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117341): https://edk2.groups.io/g/devel/message/117341
Mute This Topic: https://groups.io/mt/105131337/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 1/4] MdePkg.dec: RISC-V: Define override bit for Svpbmt extension

[Sunil V L]

On Thu, Mar 14, 2024 at 01:19:14PM -0700, Tuan Phan wrote:
> Define the BIT 2 as the override bit for Svpbmt extension. This will
> be used by RISC-V MMU library to support EFI_MEMORY_UC and
> EFI_MEMORY_WC.
> 
Reviewed-by: Sunil V L 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116841): https://edk2.groups.io/g/devel/message/116841
Mute This Topic: https://groups.io/mt/104934687/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 4/4] OvmfPkg/RiscVVirt: Disable Svpbmt extension

[Sunil V L]

On Thu, Mar 14, 2024 at 01:19:17PM -0700, Tuan Phan wrote:
> Disable Svpbmt extension as QEMU not enables it in default config.
> 
Reviewed-by: Sunil V L 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116840): https://edk2.groups.io/g/devel/message/116840
Mute This Topic: https://groups.io/mt/104934689/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 3/4] UefiCpuPkg: RISC-V: MMU: Support Svpbmt extension

[Sunil V L]

Hi Tuan,

On Thu, Mar 14, 2024 at 01:19:16PM -0700, Tuan Phan wrote:
> The GCD EFI_MEMORY_UC and EFI_MEMORY_WC memory attributes will be
> supported when Svpbmt extension available.
> 
> Cc: Gerd Hoffmann 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> Cc: Ray Ni 
> Signed-off-by: Tuan Phan 
> ---
>  .../Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c | 106 ++
>  .../BaseRiscVMmuLib/BaseRiscVMmuLib.inf   |   1 +
>  2 files changed, 86 insertions(+), 21 deletions(-)
> 
> diff --git a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c 
> b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> index 46ba4b4709b1..34300dca5c34 100644
> --- a/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> +++ b/UefiCpuPkg/Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c
> @@ -36,6 +36,11 @@
>  #define PTE_PPN_SHIFT 10
>  #define RISCV_MMU_PAGE_SHIFT  12
>  
> +#define RISCV_CPU_FEATURE_PBMT_BITMASK  BIT2
> +#define PTE_PBMT_NC BIT61
> +#define PTE_PBMT_IO BIT62
> +#define PTE_PBMT_MASK   (PTE_PBMT_NC | PTE_PBMT_IO)
> +
>  STATIC UINTN  mModeSupport[] = { SATP_MODE_SV57, SATP_MODE_SV48, 
> SATP_MODE_SV39, SATP_MODE_OFF };
>  STATIC UINTN  mMaxRootTableLevel;
>  STATIC UINTN  mBitPerLevel;
> @@ -487,32 +492,82 @@ UpdateRegionMapping (
>  /**
>Convert GCD attribute to RISC-V page attribute.
>  
> -  @param  GcdAttributes The GCD attribute.
> +  @param  GcdAttributes   The GCD attribute.
> +  @param  RiscVAttributes The pointer of RISC-V page attribute.
>  
> -  @return   The RISC-V page attribute.
> +  @retval EFI_INVALID_PARAMETER   The RiscVAttributes is NULL or cache type 
> mask not valid.
> +  @retval EFI_SUCCESS The operation succesfully.
>  
>  **/
>  STATIC
> -UINT64
> +EFI_STATUS
>  GcdAttributeToPageAttribute (
> -  IN UINT64  GcdAttributes
> +  IN UINT64   GcdAttributes,
> +  OUT UINT64  *RiscVAttributes
>)
>  {
> -  UINT64  RiscVAttributes;
> +  UINT64   CacheTypeMask;
> +  BOOLEAN  PmbtExtEnabled;
>  
Why not read the PCD once and save in a static variable?

> -  RiscVAttributes = RISCV_PG_R | RISCV_PG_W | RISCV_PG_X;
> +  if (RiscVAttributes == NULL) {
> +return EFI_INVALID_PARAMETER;
> +  }
> +
> +  *RiscVAttributes = RISCV_PG_R | RISCV_PG_W | RISCV_PG_X;
> +
> +  PmbtExtEnabled = FALSE;
> +  if ((PcdGet64 (PcdRiscVFeatureOverride) & RISCV_CPU_FEATURE_PBMT_BITMASK) 
> != 0) {
> +PmbtExtEnabled = TRUE;
> +  }
>  
>// Determine protection attributes
>if ((GcdAttributes & EFI_MEMORY_RO) != 0) {
> -RiscVAttributes &= ~(UINT64)(RISCV_PG_W);
> +*RiscVAttributes &= ~(UINT64)(RISCV_PG_W);
>}
>  
>// Process eXecute Never attribute
>if ((GcdAttributes & EFI_MEMORY_XP) != 0) {
> -RiscVAttributes &= ~(UINT64)RISCV_PG_X;
> +*RiscVAttributes &= ~(UINT64)RISCV_PG_X;
> +  }
> +
> +  CacheTypeMask = GcdAttributes & EFI_CACHE_ATTRIBUTE_MASK;
> +  if ((CacheTypeMask != 0) &&
> +  (((CacheTypeMask - 1) & CacheTypeMask) != 0))
> +  {
> +DEBUG ((
> +  DEBUG_ERROR,
> +  "%a: More than one bit set in cache type mask (0x%LX)\n",
> +  __func__,
> +  CacheTypeMask
> +  ));
> +return EFI_INVALID_PARAMETER;
> +  }
> +
> +  switch (CacheTypeMask) {
> +case EFI_MEMORY_UC:
> +  if (PmbtExtEnabled) {
> +*RiscVAttributes |= PTE_PBMT_IO;
> +  }
> +
> +  break;
> +case EFI_MEMORY_WC:
> +  if (PmbtExtEnabled) {
> +*RiscVAttributes |= PTE_PBMT_NC;
> +  } else {
> +DEBUG ((
> +  DEBUG_VERBOSE,
> +  "%a: EFI_MEMORY_WC set but Pmbt extension not available\n",
> +  __func__
> +  ));
> +  }
> +
> +  break;
> +default:
> +  // Default PMA mode
> +  break;
>}
>  
> -  return RiscVAttributes;
> +  return EFI_SUCCESS;
>  }
>  
>  /**
> @@ -535,29 +590,38 @@ RiscVSetMemoryAttributes (
>IN UINT64Attributes
>)
>  {
> -  UINT64  PageAttributesSet;
> +  UINT64  PageAttributesSet;
> +  UINT64  PageAttributesClear;
> +  EFI_STATUS  Status;
>  
> -  PageAttributesSet = GcdAttributeToPageAttribute (Attributes);
> +  Status = GcdAttributeToPageAttribute (Attributes, );
> +  if (EFI_ERROR (Status)) {
> +return Status;
> +  }
>
Is there a reason to do this prior to checking RiscVMmuEnabled()?

>if (!RiscVMmuEnabled ()) {
>  return EFI_SUCCESS;
>}
>  
> -  DEBUG (
> -(
> - DEBUG_VERBOSE,
> - "%a: Set %llX page attribute 0x%X\n",
> - __func__,
> - BaseAddress,
> - PageAttributesSet
> -)
> -);
> +  PageAttributesClear = PTE_ATTRIBUTES_MASK;
> +  if ((PcdGet64 (PcdRiscVFeatureOverride) & RISCV_CPU_FEATURE_PBMT_BITMASK) 
> != 0) {
> +PageAttributesClear |= PTE_PBMT_MASK;
> +  }
> +
I think static variable would be better.

> +  DEBUG ((
> +DEBUG_VERBOSE,
> +"%a: %LX: set attributes 0x%LX, clear attributes 0x%LX\n",
> +__func__,
> +BaseAddress,
> +PageAttributesSet,
> +

Re: [edk2-devel] [PATCH] NanhuDev:Add BOSC NanhuDev platform

[Sunil V L]

Hi Ran,

On Mon, Mar 11, 2024 at 12:29:53PM +0800, Ran Wang wrote:
> Hi Sunil,
> 
> On 2024/3/8 19:44, Sunil V L wrote:
> > On Fri, Mar 08, 2024 at 12:31:26AM -0800, WangYang wrote:
> > > Hi,Sunil V L
> > > 
> > >  How about this status.
> > > 
> > > 
> > > > -原始邮件-
> > > > 发件人: WangYang 
> > > > 发送时间: 2024-02-28 14:34:11 (星期三)
> > > > 收件人: devel@edk2.groups.io, suni...@ventanamicro.com
> > > > 抄送: "Yang Wang" , "Ran Wang" , 
> > > > "YunFeng Yang" , "YaXing Guo" 
> > > > , "Bamvor Jian ZHANG" 
> > > > 主题: [edk2-devel] [PATCH] NanhuDev:Add BOSC NanhuDev platform
> > > > 
> > > > This commit adds the initial support for BOSC's
> > > > nanhu platform which provides up to 2 RISC-V RV64
> > > > processor cores.
> > > > 
> > Somehow I missed this when you sent first. What do you mean by "initial
> > support" here?
> > 
> 
> The "initial" means so far we only support minimal system (CPU + UART), will
> integrate more periphrals in the future.
> 
Okay. Can you boot an OS with this minimal support? Why not add full
support itself? Since the structure needs to be reviewed, it would be
better to have complete picture IMO.

> > Looks like you are following old integrated opensbi approach.
> > If so, I recommend you to look at payload design. You can see Sophgo
> > board as reference.
> 
> Thanks for advices, so we need to rebase our work on
> Silicon/Sophgo/SG2042Pkg/Sec/Sec* rather than
> RISC-V/PlatformPkg/Universal/Sec/Riscv64/Sec*, right?
> 
Yes. It is better to use edk2 as a payload for opensbi.

> > Also, please remember to CC all maintainers as per Maintainers.txt.
> 
> Does the "all maintainers" mean all mentioned in Maintainers.txt, or just
> RISC-V related?
> 
You need to copy the overall maintainers for edk2-platforms repo (Mike
and Leif). They need to approve the structure for your platforms. Then
you can copy RISC-V maintainers. Add one patch to update the maintainers
for your platform as well.

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116732): https://edk2.groups.io/g/devel/message/116732
Mute This Topic: https://groups.io/mt/104619268/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [staging/dynamictables-reorg PATCH v1 0/2] DynamicTablesPkg: Arch Common Namespace

[Sunil V L]

On Mon, Mar 11, 2024 at 07:35:28AM -0700, Sami Mujawar wrote:
> Hi Sunil,
> 
> > How do we plan creating further patches? I am fine with any approach you
> > suggest but don't want to duplicate effort. I think it would be helpful
> > to know whether someone is already working on it.
> [SAMI] I am working on a patch series that moves the common objects from Arm 
> Namespace to Arch Common Namespace.
> Pierre is going to create a patch series for the corresponding edk2-platforms 
> updates for FVP & Juno.
> I think once we have reviewed and merged those, we can start looking at 
> reorganising the files and directory structure.
> Once this is completed, I think the arch specific patches can start being 
> reviewed and merged.
>
Hi Sami,
Great!. Thanks!

-Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116667): https://edk2.groups.io/g/devel/message/116667
Mute This Topic: https://groups.io/mt/104726066/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] NanhuDev:Add BOSC NanhuDev platform

[Sunil V L]

On Fri, Mar 08, 2024 at 12:31:26AM -0800, WangYang wrote:
> Hi,Sunil V L
> 
> How about this status.
> 
> 
> > -原始邮件-
> > 发件人: WangYang 
> > 发送时间: 2024-02-28 14:34:11 (星期三)
> > 收件人: devel@edk2.groups.io, suni...@ventanamicro.com
> > 抄送: "Yang Wang" , "Ran Wang" , 
> > "YunFeng Yang" , "YaXing Guo" 
> > , "Bamvor Jian ZHANG" 
> > 主题: [edk2-devel] [PATCH] NanhuDev:Add BOSC NanhuDev platform
> > 
> > This commit adds the initial support for BOSC's
> > nanhu platform which provides up to 2 RISC-V RV64
> > processor cores.
> > 
Somehow I missed this when you sent first. What do you mean by "initial
support" here?

Looks like you are following old integrated opensbi approach.
If so, I recommend you to look at payload design. You can see Sophgo
board as reference.

Also, please remember to CC all maintainers as per Maintainers.txt.

Thanks
Sunil
> 
> > 
> > Signed-off-by: Yang Wang 
> > Signed-off-by: Ran Wang 
> > Signed-off-by: YunFeng Yang 
> > Signed-off-by: YaXing Guo 
> > Cc: Bamvor Jian ZHANG 
> > Cc: Sunil V L 
> > ---
> >  .../NanhuDev/DeviceTree.fdf.inc   |  36 ++
> >  .../NanhuDev/DeviceTree/NanhuDev.dts  | 120 
> >  .../NanhuDev/DeviceTree/NanhuDeviceTree.inf   |  22 +
> >  .../XiangshanSeriesPkg/NanhuDev/NanhuDev.dec  |  24 +
> >  .../XiangshanSeriesPkg/NanhuDev/NanhuDev.dsc  | 547 ++
> >  .../XiangshanSeriesPkg/NanhuDev/NanhuDev.fdf  | 326 +++
> >  .../NanhuDev/NanhuDev.fdf.inc | 108 
> >  .../XiangshanSeriesPkg/NanhuDev/NanhuDev.uni  |  13 +
> >  .../NanhuDev/NanhuDevPkgExtra.uni |  12 +
> >  .../NanhuDev/Universal/Sec/SecMain.inf|  82 +++
> >  .../NanhuDev/VarStore.fdf.inc |  70 +++
> >  Platform/Bosc/XiangshanSeriesPkg/Readme.md|  59 ++
> >  .../XiangshanSeriesPkg/XiangshanSeriesPkg.dec |  29 +
> >  .../XiangshanSeriesPkg/XiangshanSeriesPkg.uni |  12 +
> >  .../XiangshanSeriesPkgExtra.uni   |  12 +
> >  Silicon/Bosc/NanHuPkg/NanHuPkg.dec|  33 ++
> >  16 files changed, 1505 insertions(+)
> >  create mode 100644 
> > Platform/Bosc/XiangshanSeriesPkg/NanhuDev/DeviceTree.fdf.inc
> >  create mode 100644 
> > Platform/Bosc/XiangshanSeriesPkg/NanhuDev/DeviceTree/NanhuDev.dts
> >  create mode 100644 
> > Platform/Bosc/XiangshanSeriesPkg/NanhuDev/DeviceTree/NanhuDeviceTree.inf
> >  create mode 100644 Platform/Bosc/XiangshanSeriesPkg/NanhuDev/NanhuDev.dec
> >  create mode 100644 Platform/Bosc/XiangshanSeriesPkg/NanhuDev/NanhuDev.dsc
> >  create mode 100644 Platform/Bosc/XiangshanSeriesPkg/NanhuDev/NanhuDev.fdf
> >  create mode 100644 
> > Platform/Bosc/XiangshanSeriesPkg/NanhuDev/NanhuDev.fdf.inc
> >  create mode 100644 Platform/Bosc/XiangshanSeriesPkg/NanhuDev/NanhuDev.uni
> >  create mode 100644 
> > Platform/Bosc/XiangshanSeriesPkg/NanhuDev/NanhuDevPkgExtra.uni
> >  create mode 100644 
> > Platform/Bosc/XiangshanSeriesPkg/NanhuDev/Universal/Sec/SecMain.inf
> >  create mode 100644 
> > Platform/Bosc/XiangshanSeriesPkg/NanhuDev/VarStore.fdf.inc
> >  create mode 100644 Platform/Bosc/XiangshanSeriesPkg/Readme.md
> >  create mode 100644 Platform/Bosc/XiangshanSeriesPkg/XiangshanSeriesPkg.dec
> >  create mode 100644 Platform/Bosc/XiangshanSeriesPkg/XiangshanSeriesPkg.uni
> >  create mode 100644 
> > Platform/Bosc/XiangshanSeriesPkg/XiangshanSeriesPkgExtra.uni
> >  create mode 100644 Silicon/Bosc/NanHuPkg/NanHuPkg.dec
> > 
> > diff --git a/Platform/Bosc/XiangshanSeriesPkg/NanhuDev/DeviceTree.fdf.inc 
> > b/Platform/Bosc/XiangshanSeriesPkg/NanhuDev/DeviceTree.fdf.inc
> > new file mode 100644
> > index 00..f489e5631f
> > --- /dev/null
> > +++ b/Platform/Bosc/XiangshanSeriesPkg/NanhuDev/DeviceTree.fdf.inc
> > @@ -0,0 +1,36 @@
> > +## @file
> > +#  FDF include file with Layout Regions that define an empty variable 
> > store.
> > +#
> > +#  Copyright (c) 2019, Hewlett Packard Enterprise Development LP. All 
> > rights reserved.
> > +#  Copyright (C) 2014, Red Hat, Inc.
> > +#  Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
> > +#  Copyright (c) 2024, BOSC. All rights reserved.
> > +#
> > +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> > +#
> > +##
> > +
> > +$(DTB_OFFSET)|$(DTB_SIZE)
> > +gUefiRiscVPlatformPkgTokenSpaceGuid.PcdRiscVDtbFvBase|gUefiRiscVPlatformPkgTokenSpaceGuid.PcdRiscVDtbFvSize
> > +FV = DTBFV
> > +
> > +[FV.DTBFV]
>

Re: [edk2-devel] [edk2-platforms PATCH v2 4/4] SG2042Pkg/Sec: clean up ProcessLibraryConstructorList() decl

[Sunil V L]

On Tue, Mar 05, 2024 at 01:01:26PM +0100, Laszlo Ersek wrote:
>  declares a bogus
> ProcessLibraryConstructorList() for the SG2042Pkg SEC module. Rely on
> AutoGen for (properly) declaring ProcessLibraryConstructorList(). Remove
> the correct, but superfluous, declaration as well.
> 
> Build-tested with:
> 
>   build -a RISCV64 -b DEBUG -m Silicon/Sophgo/SG2042Pkg/Sec/SecMain.inf \
> -p Platform/Sophgo/SG2042_EVB_Board/SG2042.dsc -t GCC5
> 
> Cc: Sunil V L 
> Cc: USER0FISH 
> Cc: caiyuqing379 
> Cc: dahogn 
> Cc: meng-cz 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=990
> Signed-off-by: Laszlo Ersek 
> ---
>  Silicon/Sophgo/SG2042Pkg/Sec/SecMain.inf |  2 +-
>  Silicon/Sophgo/SG2042Pkg/Sec/SecMain.h   | 12 
>  Silicon/Sophgo/SG2042Pkg/Sec/Memory.c|  1 -
>  3 files changed, 1 insertion(+), 14 deletions(-)
> 
Reviewed-by: Sunil V L 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116393): https://edk2.groups.io/g/devel/message/116393
Mute This Topic: https://groups.io/mt/104742763/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 04/10] OvmfPkg/RiscVVirt/Sec: clean up ProcessLibraryConstructorList() decl

[Sunil V L]

On Tue, Mar 05, 2024 at 12:38:37PM +0100, Laszlo Ersek wrote:
>  declares a bogus
> ProcessLibraryConstructorList() for the OvmfPkg/RiscVVirt SEC module. Rely
> on AutoGen for (properly) declaring ProcessLibraryConstructorList().
> Remove the correct, but superfluous, declaration as well.
> 
> Build-tested with:
> 
>   build -a RISCV64 -b DEBUG -m OvmfPkg/RiscVVirt/Sec/SecMain.inf \
> -p OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc -t GCC5
> 
> Cc: Andrei Warkentin 
> Cc: Ard Biesheuvel 
> Cc: Gerd Hoffmann 
> Cc: Jiewen Yao 
> Cc: Sunil V L 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=990
> Signed-off-by: Laszlo Ersek 
> ---
>  OvmfPkg/RiscVVirt/Sec/SecMain.inf |  2 +-
>  OvmfPkg/RiscVVirt/Sec/SecMain.h   | 12 
>  OvmfPkg/RiscVVirt/Sec/Memory.c|  1 -
>  3 files changed, 1 insertion(+), 14 deletions(-)
> 
Reviewed-by: Sunil V L 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116392): https://edk2.groups.io/g/devel/message/116392
Mute This Topic: https://groups.io/mt/104742524/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [staging/dynamictables-reorg PATCH v1 0/2] DynamicTablesPkg: Arch Common Namespace

[Sunil V L]

Hi Sami,

On Mon, Mar 04, 2024 at 04:46:15PM +, Sami Mujawar wrote:
> This series is an initial proposal for introducing an Arch Common
> namespace. Based on the mailing list discussions, further patch
> series to move the configuration manager objects to the Arch
> Common namespace and the corresponding platform support patches
> shall be submitted for review.
> 
> The changes can be seen at:
> https://github.com/samimujawar/edk2/tree/3007_dynamictables_reorg_arch_namespace_v1
> 
Looks good to me.

Reviewed-by: Sunil V L 

How do we plan creating further patches? I am fine with any approach you
suggest but don't want to duplicate effort. I think it would be helpful
to know whether someone is already working on it.

Thanks!
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116360): https://edk2.groups.io/g/devel/message/116360
Mute This Topic: https://groups.io/mt/104726066/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [staging/dynamictables-reorg PATCH v1 1/2] DynamicTablesPkg: Introduce an Arch Common Namespace

[Sunil V L]

On Mon, Mar 04, 2024 at 04:46:16PM +, Sami Mujawar wrote:
> Introduce an Arch Common Namespace so that the common
> architectural objects can be defined under this namespace
> in the Configuration manager. Also rearrange the namespace
> IDs so that the Arch Common Namespace has a value of 0x1,
> the Arm Namespace ID has a value of 0x2, and the Custom/OEM
> namespace ID has a value of 0xF. Also introduce a helper
> macro to create configuration manager objects in the Arch
> Common Namespace.
> 
> The Arch Common Namespace shall contain objects like
> Serial Port, PCI Bus information etc. It must not contain
> Architecture specific components e.g. GICC which is Arm
> architecture specific component and therefore must be
> defined in the Arm Namespace.
> 
> Cc: Pierre Gondois 
> Cc: Yeo Reum Yun 
> Cc: Sunil V L 
> Cc: AbdulLateef Attar 
> Cc: Jeshua Smith 
> Cc: Jeff Brasen 
> Cc: Girish Mahadevan 
> Cc: Leif Lindholm 
> Cc: Meenakshi Aggarwal 
> Signed-off-by: Sami Mujawar 
> ---
>  DynamicTablesPkg/Include/ConfigurationManagerObject.h | 26 --
>  DynamicTablesPkg/Readme.md| 98 
> 
>  2 files changed, 117 insertions(+), 7 deletions(-)
> 
> diff --git a/DynamicTablesPkg/Include/ConfigurationManagerObject.h 
> b/DynamicTablesPkg/Include/ConfigurationManagerObject.h
> index 
> 74ad25d5d94a34da39e6c8dd909f9863e223d086..4255c82b42aefb52148a14a44c91328ec82f1550
>  100644
> --- a/DynamicTablesPkg/Include/ConfigurationManagerObject.h
> +++ b/DynamicTablesPkg/Include/ConfigurationManagerObject.h
> @@ -1,6 +1,6 @@
>  /** @file
>  
> -  Copyright (c) 2017 - 2022, ARM Limited. All rights reserved.
> +  Copyright (c) 2017 - 2024, Arm Limited. All rights reserved.
>  
>SPDX-License-Identifier: BSD-2-Clause-Patent
>  
> @@ -29,8 +29,9 @@ 
> ___
>  
>  Bits: [31:28] - Name Space ID
>   - Standard
> -0001 - ARM
> -1000 - Custom/OEM
> +0001 - Arch Common
> +0010 - ARM
> + - Custom/OEM
>  All other values are reserved.
>  
>  Bits: [27:16] - Reserved.
> @@ -105,10 +106,11 @@ typedef UINT32 CM_OBJECT_ID;
>  for the Configuration Manager Objects.
>  */
>  typedef enum ObjectNameSpaceID {
> -  EObjNameSpaceStandard,  ///< Standard Objects Namespace
> -  EObjNameSpaceArm,   ///< ARM Objects Namespace
> -  EObjNameSpaceOem = 0x8, ///< OEM Objects Namespace
> -  EObjNameSpaceMax
> +  EObjNameSpaceStandard,  ///< Standard Objects Namespace
> +  EObjNameSpaceArchCommon,///< Arch Common Objects Namespace
> +  EObjNameSpaceArm,   ///< ARM Objects Namespace
> +  EObjNameSpaceOem = 0xF, ///< OEM Objects Namespace
> +  EObjNameSpaceMax,
>  } EOBJECT_NAMESPACE_ID;
>  
>  /** A descriptor for Configuration Manager Objects.
> @@ -182,6 +184,16 @@ typedef struct CmObjDescriptor {
>  #define CREATE_CM_ARM_OBJECT_ID(ObjectId) \
>(CREATE_CM_OBJECT_ID (EObjNameSpaceArm, ObjectId))
>  
> +/** This macro returns a Configuration Manager Object ID
> +in the Arch Common Object Namespace.
> +
> +  @param [in] ObjectIdThe Object ID.
> +
> +  @retval Returns an Arch Common Configuration Manager Object ID.
> +**/
> +#define CREATE_CM_ARCH_COMMON_OBJECT_ID(ObjectId) \
> +  (CREATE_CM_OBJECT_ID (EObjNameSpaceArchCommon, ObjectId))
> +
>  /** This macro returns a Configuration Manager Object ID
>  in the OEM Object Namespace.
>  
> diff --git a/DynamicTablesPkg/Readme.md b/DynamicTablesPkg/Readme.md
> index 
> c1cdc5e17326709e811a2f3fe530316e95dec7ee..ba4ae7155f13a77298ece74cc567bb3e9dfc303d
>  100644
> --- a/DynamicTablesPkg/Readme.md
> +++ b/DynamicTablesPkg/Readme.md
> @@ -402,3 +402,101 @@ Refer to the following presentation from *UEFI Plugfest 
> Seattle 2018*:
>  
>  [Dynamic Tables Framework: A Step Towards Automatic Generation of Advanced 
> Configuration and Power Interface (ACPI) & System Management BIOS (SMBIOS) 
> Tables](http://www.uefi.org/sites/default/files/resources/Arm_Dynamic%20Tables%20Framework%20A%20Step%20Towards%20Automatic%20Generation%20of%20Advanced%20Configuration%20and%20Power%20Interface%20%28ACPI%29%20%26%20System%20Management%20BIOS%20%28SMBIOS%29%20Tables%20_0.pdf)
>  
> +## Configuration Manager Objects
> +
> +The CM_OBJECT_ID type is used to identify the Configuration Manager
> +objects.
> +
> +## Description of Configuration Manager Object ID
> +
> +| 31 30 29 28 | 27 | 26 | 25 | 24 | 23 | 22 | 21 

Re: [edk2-devel] [staging/dynamictables-reorg PATCH v1 1/1] Branch to reorg Dynamic Tables & support other arch

[Sunil V L]

On Wed, Feb 14, 2024 at 08:20:24AM +, Sami Mujawar wrote:
> Hi Abdul,
> 
> The dynamictables-reorg branch is not yet created see 
> https://github.com/tianocore/edk2-staging/branches
> I am not sure I have permissions to create a new branch under the 
> edk2-staging repo.
> 
> I will follow up and check if the maintainers can create the branches for us.
> 
Hi Sami,

I think I have permission to create branch in edk2-staging since I had
created one for RISC-V sometime back. Do you want me to create?

Thanks,
Sunil
> Regards,
> 
> Sami Mujawar
> 
> 
> On 14/02/2024, 04:15, "Attar, AbdulLateef (Abdul Lateef)" 
> mailto:abdullateef.at...@amd.com>> wrote:
> 
> 
> [AMD Official Use Only - General]
> 
> 
> Hi Sami Mujawar,
> Could you please rebase the branch.
> I have a patch which was built on top of the edk2 master branch.
> 
> 
> master branch changes: https://github.com/tianocore/edk2/pull/5374 
> 
> 
> 
> When I try to apply the same patch(on this branch) getting below errors.
> 
> 
> Checking patch DynamicTablesPkg/DynamicTables.dsc.inc...
> error: while searching for:
> DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf?
> ?
> [Components.IA32, Components.X64]?
> #?
> # Dynamic Table Factory Dxe?
> #?
> DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryDxe.inf?
> ?
> [Components.ARM, Components.AARCH64]?
> #?
> 
> 
> error: patch failed: DynamicTablesPkg/DynamicTables.dsc.inc:31
> error: DynamicTablesPkg/DynamicTables.dsc.inc: patch does not apply
> Checking patch DynamicTablesPkg/Include/ArchNameSpaceObjects.h...
> Checking patch DynamicTablesPkg/Include/ConfigurationManagerObject.h...
> error: while searching for:
> /** @file?
> ?
> Copyright (c) 2017 - 2022, ARM Limited. All rights reserved.?
> ?
> SPDX-License-Identifier: BSD-2-Clause-Patent?
> ?
> 
> 
> error: patch failed: DynamicTablesPkg/Include/ConfigurationManagerObject.h:1
> error: DynamicTablesPkg/Include/ConfigurationManagerObject.h: patch does not 
> apply
> 
> 
> 
> 
> Thanks
> AbduL
> 
> 
> 
> 
> -Original Message-
> From: Sami Mujawar mailto:sami.muja...@arm.com>>
> Sent: Tuesday, January 30, 2024 8:21 PM
> To: devel@edk2.groups.io 
> Cc: Sami Mujawar mailto:sami.muja...@arm.com>>; 
> michael.d.kin...@intel.com ; 
> quic_llind...@quicinc.com ; 
> ardb+tianoc...@kernel.org ; 
> ler...@redhat.com ; pierre.gond...@arm.com 
> ; yeoreum@arm.com 
> ; akanksha.ja...@arm.com 
> ; sibel.allin...@arm.com 
> ; suni...@ventanamicro.com 
> ; andrei.warken...@intel.com 
> ; Attar, AbdulLateef (Abdul Lateef) 
> mailto:abdullateef.at...@amd.com>>; 
> gmahade...@nvidia.com ; jesh...@nvidia.com 
> ; jbra...@nvidia.com ; 
> meenakshi.aggar...@nxp.com ; n...@arm.com 
> 
> Subject: [staging/dynamictables-reorg PATCH v1 1/1] Branch to reorg Dynamic 
> Tables & support other arch
> 
> 
> Caution: This message originated from an External Source. Use proper caution 
> when opening attachments, clicking links, or responding.
> 
> 
> 
> 
> Dynamic Tables Framework currently supports Arm Architecture.
> This patch introduces a new staging branch for Dynamic Tables Framework to:
> - Reorganise the code to streamline adoption by other architectures
> - Introduce Dynamic Tables support for RISC-V architecture
> - Integrate Dynamic SMBIOS support.
> 
> 
> The description is in the Readme.md file.
> 
> 
> Please create the following branches:
> 1. edk2-staging Repo
> URL: https://github.com/tianocore/edk2-staging.git 
> 
> Branch Name: dynamictables-reorg
> 
> 
> 2. edk2-platforms Repo
> URL: https://github.com/tianocore/edk2-platforms.git 
> 
> Branch Name: devel-dynamictables-reorg
> 
> 
> Signed-off-by: Sami Mujawar  >
> ---
> Readme.md | 237 
> 1 file changed, 237 insertions(+)
> 
> 
> diff --git a/Readme.md b/Readme.md
> new file mode 100644
> index 
> ..3031a8967785a2ef90f05b5b0d77053aa82364d3
> --- /dev/null
> +++ b/Readme.md
> @@ -0,0 +1,237 @@
> +# Introduction
> +
> +**DynamicTablesPkg** currently supports Arm architecture, and we
> +welcome the adoption by other architectures.
> +
> +This branch will be used to:
> + - Reorganise the code to streamline adoption by other architectures.
> + - Introduce Dynamic Tables support for RISC-V architecture
> + - Integrate Dynamic SMBIOS support
> + 

Re: [edk2-devel] [PATCH v2 0/3] RISC-V: Support Svpbmt extension

[Sunil V L]

Hi Tuan,

On Mon, Feb 26, 2024 at 08:34:22PM -0800, Tuan Phan wrote:
> Hi Sunil/ Andrei,
> Any comments on this series?
> 
Did I miss your response to Laszlo's feedback on PATCH 2 - [1]? Apart
from that, don't we need to handle EFI_MEMORY_WT similar to
EFI_MEMORY_WC?

[1] - https://edk2.groups.io/g/devel/message/115243

Thanks,
Sunil
> Regards,
> 
> On Wed, Feb 14, 2024 at 10:16 PM Tuan Phan via groups.io  ventanamicro@groups.io> wrote:
> 
> >
> >
> > On Wed, Feb 14, 2024 at 9:43 PM Warkentin, Andrei <
> > andrei.warken...@intel.com> wrote:
> >
> >> Do you mind sharing a GH branch with the patch set?
> >>
> > https://github.com/pttuan/edk2/tree/tphan/riscv_mmu_svpbmt
> > Tuan
> >
> >>
> >> A
> >>
> >> > -Original Message-
> >> > From: Tuan Phan 
> >> > Sent: Tuesday, February 6, 2024 7:29 PM
> >> > To: devel@edk2.groups.io
> >> > Cc: Kinney, Michael D ;
> >> > gaolim...@byosoft.com.cn; Liu, Zhiguang ;
> >> > kra...@redhat.com; ler...@redhat.com; Kumar, Rahul R
> >> > ; Ni, Ray ;
> >> > suni...@ventanamicro.com; Yao, Jiewen ;
> >> Warkentin,
> >> > Andrei ; ardb+tianoc...@kernel.org; Tuan
> >> Phan
> >> > 
> >> > Subject: [PATCH v2 0/3] RISC-V: Support Svpbmt extension
> >> >
> >> > This patchset adds support for RISC-V Svpbmt extension.
> >> >
> >> > The GCD EFI_MEMORY_UC and EFI_MEMORY_WC attributes will be mapped to
> >> > IO and NC mode defined in PBMT field.
> >> >
> >> > v2:
> >> >   - Generated patch for each package.
> >> >
> >> > Tuan Phan (3):
> >> >   MdePkg.dec: RISC-V: Define override bit for Svpbmt extension
> >> >   UefiCpuPkg: RISC-V: MMU: Support Svpbmt extension
> >> >   OvmfPkg/RiscVVirt: Override Svpbmt extension
> >> >
> >> >  MdePkg/MdePkg.dec |  2 ++
> >> >  OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc   |  2 +-
> >> >  .../Library/BaseRiscVMmuLib/BaseRiscVMmuLib.c | 25 ++-
> >> >  .../BaseRiscVMmuLib/BaseRiscVMmuLib.inf   |  1 +
> >> >  4 files changed, 28 insertions(+), 2 deletions(-)
> >> >
> >> > --
> >> > 2.25.1
> >>
> >> 
> >
> >


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116083): https://edk2.groups.io/g/devel/message/116083
Mute This Topic: https://groups.io/mt/104211191/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] MdePkg/BaseCacheMaintenanceLib: RV64 replace asserts with logs

[Sunil V L]

On Wed, Jan 24, 2024 at 07:57:27PM +0530, Dhaval Sharma wrote:
> "The CpuDxe interface will be the wrapper." Yes, of course. It needs to be
> added. I was just saying that maybe any CMO checking is not required there
> as cmo library will take care of it.
> 
That's correct.

> On Tue, Jan 23, 2024 at 10:24 PM Sunil V L  wrote:
> 
> > On Tue, Jan 23, 2024 at 11:42:57AM +0530, Dhaval Sharma wrote:
> > > Sunil,
> > > I thought "WriteBackDataCacheRange not supported" is more explicit over
> > > "CMO not available".
> > >
> > Okay.
> >
> > > @Pedro Falcato  For the example you mentioned,
> > is
> > > your concern more about someone not being able to notice the problem
> > (that
> > > the system is non-coherent) at the time of development and later ending
> > up
> > > with corrupted data during production? And you are suggesting that an
> > > Assert helps address that problem by making that problem more visible to
> > > the developer and a verbose warning does not?
> > >
> > > I can create a patch for CpuFlushCpuDataCache but I think we should avoid
> > > CMO based return in there. Because in case of InvalidateDataCacheRange we
> > > have an alternate implementation of fence in the absence of CMO. So it is
> > > better to let riscvcache decide the right implementation.
> > >
> > The CpuDxe interface will be the wrapper. See Arm's implementation.
> > Since CMO support is added now, the CpuDxe interface should be updated.
> >
> > Thanks,
> > Sunil
> >
> 
> 
> -- 
> Thanks!
> =D


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114303): https://edk2.groups.io/g/devel/message/114303
Mute This Topic: https://groups.io/mt/103805230/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] MdePkg/BaseCacheMaintenanceLib: RV64 replace asserts with logs

[Sunil V L]

On Tue, Jan 23, 2024 at 11:42:57AM +0530, Dhaval Sharma wrote:
> Sunil,
> I thought "WriteBackDataCacheRange not supported" is more explicit over
> "CMO not available".
> 
Okay.

> @Pedro Falcato  For the example you mentioned, is
> your concern more about someone not being able to notice the problem (that
> the system is non-coherent) at the time of development and later ending up
> with corrupted data during production? And you are suggesting that an
> Assert helps address that problem by making that problem more visible to
> the developer and a verbose warning does not?
> 
> I can create a patch for CpuFlushCpuDataCache but I think we should avoid
> CMO based return in there. Because in case of InvalidateDataCacheRange we
> have an alternate implementation of fence in the absence of CMO. So it is
> better to let riscvcache decide the right implementation.
>
The CpuDxe interface will be the wrapper. See Arm's implementation.
Since CMO support is added now, the CpuDxe interface should be updated.

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114218): https://edk2.groups.io/g/devel/message/114218
Mute This Topic: https://groups.io/mt/103805230/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [RFC PATCH v1 00/20] DynamicTablesPkg: Prepare to add RISC-V support

[Sunil V L]

Hi Sami,

On Mon, Jan 22, 2024 at 05:15:44PM +, Sami Mujawar wrote:
> Hi All,
> 
> DynamicTablesPkg currently supports Arm architecture, and we welcome the 
> adoption by other architectures.
> 
> Following is my proposal for moving forward.
> 
> Goals:
> - reuse common code
> - streamline the adoption by other architectures
> - minimise the impact on migration of the existing platforms
> - maintain flexibility across architectural components
> - use this opportunity to integrate Dynamic SMBIOS support
>   (Ref: https://edk2.groups.io/g/devel/message/107254)
> 
> The following steps would help in achieving the goals:
> 1.  Create an edk2 staging branch. For the edk2-platforms updates, I will 
> create a branch on my Github fork (note this is required as there is no 
> staging repo for edk2-platforms).
> 2. The design aspects and changes shall be discussed on the mailing list with 
> patches to support the details.
> 3. A new section in DynamicTablesPkg\Readme.md shall be added to reflect the 
> design updates, e.g. changes to CM Objects, Namespace definitions, etc.
> 4.  The design changes should typically be supported by patches for the 
> DynamicTables core framework and demonstrate the impact on the existing 
> platform code by typically providing patches for at least one existing 
> platform (possibly edk2-platforms/Platform/ARM/[Juno | FVP]).
> 5. The design changes should be small and typically be reflected in separate 
> patch series.
> 6. The first phase would be to partition the codebase into common code vs 
> architectural specific code. This would involve moving files and reflecting 
> the associated changes such that the build does not break.
> 7. Define a new namespace e.g. “ArchCommon” for the common architectural 
> components.
> 8. Identify the CM_ARM_OBJECTs that can be moved to the “ArchCommon” 
> namespace. As part of this identify if any object needs to be dropped, e.g. 
> EArmObjReserved29
> 9. Identify overlap of SMBIOS objects with existing CM Objects.
> 10. Submit patches to move CM objects from Arm Namespace to ArchCommon 
> Namespace. Ideally one object (and any dependencies) should be moved at a 
> time.
> 11. Submit patches to migrate upstream platforms that use DynamicTablesPkg
> 12. Define a new namespace for RISCV specific objects
> 13. Submit patches for enabling RISCV
> 14. In the next phase support for Dynamic SMBIOS can be enabled.
> 
> Notes: 
> a. Periodically rebase with edk2 & edk2-platforms master branch to sync with 
> latest changes.
> b. We can decide to merge the updates after point 11 above to edk2 & 
> edk2-platforms master branch.
> c. Similarly, the RISCV support can be merged after point 13.
> 
> I will send out a request for creating the staging branch shortly.
> 
This is great!. I think staging branches is a great idea considering the
amount of changes this work needs. Thank you very much!.

I can send small patch sets to partition the code base as per #6 along
with documentation changes. Let me know once staging branches are
created.

Thanks!
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114181): https://edk2.groups.io/g/devel/message/114181
Mute This Topic: https://groups.io/mt/103622702/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] MdePkg/BaseCacheMaintenanceLib: RV64 replace asserts with logs

[Sunil V L]

On Thu, Jan 18, 2024 at 03:20:18PM +0530, Dhaval wrote:
> Some platforms do not implement cache management operations. Especially
> for DMA drivers have code to manage data cache. The code seem to depend
> on the underlying CPU/cache drivers to enact functionality and simply
> return if such functionality is not implemented. However this causes
> issue with CMO implementation which has an assert causing flow to
> hang within debug environment. While it is not an issue in production
> environment there is a recommendation to conver this assert in to
> a harmless logger message. Eventually platform/drivers need to have
> better guard for such functionality.
> 
> Signed-off-by: Dhaval Sharma 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Cc: Zhiguang Liu 
> Cc: Sunil V L 
> Cc: Andrei Warkentin 
> Cc: Laszlo Ersek 
> Cc: Pedro Falcato 
> Cc: Yang Cheng 
> ---
>  MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c | 11 ++-
>  1 file changed, 6 insertions(+), 5 deletions(-)
> 
> diff --git a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c 
> b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> index 73a5a6b6b5d6..d99515bcf38b 100644
> --- a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> +++ b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> @@ -183,9 +183,8 @@ WriteBackInvalidateDataCache (
>VOID
>)
>  {
> -  ASSERT (FALSE);
>DEBUG ((
> -DEBUG_ERROR,
> +DEBUG_VERBOSE,
>  "WriteBackInvalidateDataCache: RISC-V unsupported function.\n"
>  ));
>  }
> @@ -226,7 +225,9 @@ WriteBackInvalidateDataCacheRange (
>if (RiscVIsCMOEnabled ()) {
>  CacheOpCacheRange (Address, Length, CacheOpFlush);
>} else {
> -ASSERT (FALSE);
> +DEBUG (
> +  (DEBUG_VERBOSE, "WriteBackInvalidateDataCacheRange not supported \n")

Should this be CMO not enabled?

> +  );
>}
>  
>return Address;
> @@ -248,7 +249,7 @@ WriteBackDataCache (
>VOID
>)
>  {
> -  ASSERT (FALSE);
> +  DEBUG ((DEBUG_VERBOSE, "WriteBackDataCache not supported \n"));
>  }
>  
>  /**
> @@ -283,7 +284,7 @@ WriteBackDataCacheRange (
>if (RiscVIsCMOEnabled ()) {
>  CacheOpCacheRange (Address, Length, CacheOpClean);
>} else {
> -ASSERT (FALSE);
> +DEBUG ((DEBUG_VERBOSE, "WriteBackDataCacheRange not supported \n"));
Same comment as earlier.

>}
>  
>return Address;
> -- 
> 2.39.2
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114027): https://edk2.groups.io/g/devel/message/114027
Mute This Topic: https://groups.io/mt/103805230/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] MdePkg/BaseCacheMaintenanceLib: RV64 replace asserts with logs

[Sunil V L]

On Thu, Jan 18, 2024 at 03:58:04PM +, Pedro Falcato wrote:
> On Thu, Jan 18, 2024 at 9:50 AM Dhaval  wrote:
> >
> > Some platforms do not implement cache management operations. Especially
> > for DMA drivers have code to manage data cache. The code seem to depend
> > on the underlying CPU/cache drivers to enact functionality and simply
> > return if such functionality is not implemented. However this causes
> > issue with CMO implementation which has an assert causing flow to
> > hang within debug environment. While it is not an issue in production
> > environment there is a recommendation to conver this assert in to
> 
> I don't agree with this patch. As I see it, the library has a simple
> contract: Do cache operation X and return. We cannot safely return if
> we don't know how to do cache operation X. Say, with a Thead core and
> Xtheadcmo.
> Any other concerns wrt DMA are, in my view, somewhat separate.
> 
> One can easily theorize a way this change can come to bite us, say, a
> storage controller writes bogus data to storage (because the platform
> needs explicit cache coherency, and we don't know how to do that) and
> causes data corruption.
> 
I understand your point. It is an issue for sure if the device is
non cache coherent but there is no way to flush the cache. However, if
CMO is not there, the driver should use NonCacheCoherent library which
uses UC memory. These interfaces will be called for UC memory in that case
which should be NO-OP instead of assertion.

For custom CMO extension, the silicon vendor needs to implement
different cache management library in edk2-platforms.

Having said that, I notice that the interface in CpuDxe needs to be
updated now. Dhaval, would you be able to add that patch also?

Thanks,
Sunil

> > a harmless logger message. Eventually platform/drivers need to have
> > better guard for such functionality.
> 
> Like an ASSERT? :)
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#114026): https://edk2.groups.io/g/devel/message/114026
Mute This Topic: https://groups.io/mt/103805230/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 1/1] Sophgo/SG2042Pkg: Disable CMO and Sstc features

[Sunil V L]

On Mon, Jan 15, 2024 at 04:11:44PM +0800, caiyuqing...@163.com wrote:
> From: caiyuqing379 
> 
> Disable CMO and Sstc features because they are not supported by the
> platform. And use SBI calls itself by default for Sophgo SG2042 platform.
> 
Merged as #118.



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113872): https://edk2.groups.io/g/devel/message/113872
Mute This Topic: https://groups.io/mt/103752457/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2] OvmfPkg: RiscVVirt: Fix network drivers not be built

[Sunil V L]

On Fri, Jan 12, 2024 at 05:05:26PM -0800, Tuan Phan wrote:
> Only need to include Network.dsc.inc to have all network
> drivers/components be built. Otherwise, there were missing definition
> that prevent them from be built for RiscVVirt platform.
> 
> Signed-off-by: Tuan Phan 
> ---
> v2:
>  - Rebase
> 
>  OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc | 15 +--
>  1 file changed, 1 insertion(+), 14 deletions(-)
> 
Merged as #5260.

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113798): https://edk2.groups.io/g/devel/message/113798
Mute This Topic: https://groups.io/mt/103695672/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] RFC: Folder layout change in UefiCpuPkg

[Sunil V L]

On Mon, Jan 15, 2024 at 02:17:09PM +0800, Chao Li wrote:
> Ray and Sunil,
> 
> I plan send two example PRs to github to  show how to deal the INFs, one to
> adjust current INF, and another PR to move the libraris to the current
> folders. I hope after these two PRs are sent we can decide what to do with
> the INF. What do you think of this plan?
> 
> 
Hi Chao, That's fine with me.

Thanks,
Sunil
> Thanks,
> Chao
> On 2024/1/15 13:44, Ni, Ray wrote:
> > That will be great!
> > 
> > Thanks,
> > Ray
> > > -Original Message-
> > > From: Sunil V L
> > > Sent: Monday, January 15, 2024 12:44 PM
> > > To: Ni, Ray
> > > Cc:devel@edk2.groups.io;lic...@loongson.cn; Kinney, Michael D
> > > ; Laszlo Ersek; Gerd
> > > Hoffmann
> > > Subject: Re: RFC: Folder layout change in UefiCpuPkg
> > > 
> > > On Mon, Jan 15, 2024 at 01:13:03AM +, Ni, Ray wrote:
> > > > Sunil,
> > > > I am glad that you don't have concern about the direction.
> > > > 
> > > > "RiscV" is good to me.
> > > > 
> > > > 
> > > Thanks!, Ray. So, shall I send patches to reorganize this?
> > > 
> > > Thanks,
> > > Sunil
> > 
> > 
> > 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113797): https://edk2.groups.io/g/devel/message/113797
Mute This Topic: https://groups.io/mt/103679850/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] RFC: Folder layout change in UefiCpuPkg

[Sunil V L]

On Mon, Jan 15, 2024 at 01:13:03AM +, Ni, Ray wrote:
> Sunil,
> I am glad that you don't have concern about the direction.
> 
> "RiscV" is good to me.
> 
> 
Thanks!, Ray. So, shall I send patches to reorganize this?

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113791): https://edk2.groups.io/g/devel/message/113791
Mute This Topic: https://groups.io/mt/103679850/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 1/1] Sophgo/SG2042Pkg: Override Sstc extension

[Sunil V L]

On Sat, Jan 13, 2024 at 10:39:16AM +0800, caiyuqing...@163.com wrote:
> From: caiyuqing379 
> 
> Override Sstc extension and use SBI calls itself by default for RISC-V
> Sophgo SG2042 platform.
> 
Since the change disables CMO also (BIT 0) which is expected, could you
update the commit message to reflect it? 

Otherwise,
Reviewed-by: Sunil V L 

Thanks,
Sunil
> Cc: dahogn 
> Cc: meng-cz 
> Cc: USER0FISH 
> Cc: Sunil V L 
> Signed-off-by: caiyuqing379 
> ---
>  Platform/Sophgo/SG2042_EVB_Board/SG2042.dsc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/Platform/Sophgo/SG2042_EVB_Board/SG2042.dsc 
> b/Platform/Sophgo/SG2042_EVB_Board/SG2042.dsc
> index 3bbaeca16970..127182487126 100644
> --- a/Platform/Sophgo/SG2042_EVB_Board/SG2042.dsc
> +++ b/Platform/Sophgo/SG2042_EVB_Board/SG2042.dsc
> @@ -265,6 +265,7 @@
>gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeUseSerial|TRUE
>gEfiMdeModulePkgTokenSpaceGuid.PcdStatusCodeMemorySize|1
>gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
> +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0xFFFC
>gEfiMdePkgTokenSpaceGuid.PcdMaximumGuidedExtractHandler|0x10
>gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x2000
>gEfiMdeModulePkgTokenSpaceGuid.PcdMaxHardwareErrorVariableSize|0x8000
> -- 
> 2.34.1
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113790): https://edk2.groups.io/g/devel/message/113790
Mute This Topic: https://groups.io/mt/103733215/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2] OvmfPkg: RiscVVirt: Fix network drivers not be built

[Sunil V L]

On Fri, Jan 12, 2024 at 05:05:26PM -0800, Tuan Phan wrote:
> Only need to include Network.dsc.inc to have all network
> drivers/components be built. Otherwise, there were missing definition
> that prevent them from be built for RiscVVirt platform.
> 
> Signed-off-by: Tuan Phan 
> ---
> v2:
>  - Rebase
> 
>  OvmfPkg/RiscVVirt/RiscVVirtQemu.dsc | 15 +--
>  1 file changed, 1 insertion(+), 14 deletions(-)
> 
Thanks for the patch, Tuan. Sorry, I missed to merge earlier.

Reviewed-by: Sunil V L 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113789): https://edk2.groups.io/g/devel/message/113789
Mute This Topic: https://groups.io/mt/103695672/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] RFC: Folder layout change in UefiCpuPkg

[Sunil V L]

Hi Ray,

On Fri, Jan 12, 2024 at 09:12:34AM +, Ni, Ray wrote:
> Sunil,
> I would like to hear your feedback regarding locations of following RiscV64 
> components in UefiCpuPkg:
> * UefiCpuPkg/Library/BaseRiscV64CpuExceptionHandlerLib/
> * UefiCpuPkg/Library/BaseRiscV64CpuTimerLib/
> * UefiCpuPkg/CpuDxeRiscV64/
> * UefiCpuPkg/CpuTimerDxeRiscV64/
> 
> I would like to move them to the following new locations accordingly:
> * UefiCpuPkg/Library/CpuExceptionHandlerLib/RiscV64/
> * UefiCpuPkg/Library/CpuTimerLib/RiscV64/
> * UefiCpuPkg/CpuDxe/RiscV64/
> * UefiCpuPkg/CpuTimerDxe/RiscV64/
> 
> 
> I want to avoid too many similar drivers in root folder, and too many 
> libraries in Library folder.
> 
> Movement of the first 3 ones put the RiscV components under existing folders.
> Movement of the last one creates the UefiCpuPkg/CpuTimerDxe folder, that 
> could be potentially shared by other archs as well.
> 
> I raised similar comments to Chao Li who is working on LoongArch upstream.
> 
> The location movement follows the 2nd pattern defined by edk2 coding standard:
> Driver's location could be:
> [[]]
>   or
> [/[/]]
> 
> Library's location could be:
> 
> [[]][]
> 
>   or
> 
> []/[[/]]
> 
> 
Your proposal looks good to me except better to keep directory name as
RiscV as in other packages.

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113707): https://edk2.groups.io/g/devel/message/113707
Mute This Topic: https://groups.io/mt/103679850/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2] MdePkg/BaseLib:Fix boot DxeCore hang on riscv platform

[Sunil V L]

On Fri, Jan 05, 2024 at 03:47:07PM +, Andrei Warkentin wrote:
> Looks reasonable to me.
> 
> Reviewed-by: Andrei Warkentin 
> 
> > -Original Message-
> > From: Yang Wang 
> > Sent: Wednesday, December 27, 2023 8:57 PM
> > To: Warkentin, Andrei ; devel@edk2.groups.io
> > Cc: Yang Wang ; Ran Wang ;
> > Bamvor Jian ZHANG ; Gao, Liming
> > ; Kinney, Michael D
> > ; Sunil V L ; Liu,
> > Zhiguang 
> > Subject: [PATCH v2] MdePkg/BaseLib:Fix boot DxeCore hang on riscv platform
> > 
> > For scene of
> > HandOffToDxeCore()->SwitchStack(DxeCoreEntryPoint)->
> > InternalSwitchStack()->LongJump(),Variable HobList.Raw
> > will be passed (from *Context1 to register a0) to
> > DxeMain() in parameter *HobStart.
> > 
> > However, meanwhile the function LongJump() overrides
> > register a0 with a1 (-1)  due to commit (ea628f28e5 "RISCV: Fix
> > InternalLongJump to return correct value"), then cause hang.
> > 
> > Replacing calling LongJump() with new InternalSwitchStackAsm() to pass
> > addres data in register s0 to register a0 could fix this issue (just
> > like the solution in MdePkg/Library/BaseLib/AArch64/SwitchStack.S)
> > 
> > Signed-off-by: Yang Wang 
> > Reviewed-by: Ran Wang 
> > Cc: Bamvor Jian ZHANG 
> > Cc: Andrei Warkentin 
> > Cc: Liming Gao 
> > Cc: Michael D Kinney 
> > Cc: Sunil V L 
> > Cc: Zhiguang Liu 
> > ---
Thanks for the patch!. Merged this as #5255 after fixing a minor
formatting issue.

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113624): https://edk2.groups.io/g/devel/message/113624
Mute This Topic: https://groups.io/mt/103395756/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v2 0/4] RISC-V: Add support for Sstc extension

[Sunil V L]

On Mon, Jan 08, 2024 at 05:06:46PM +0530, Sunil V L wrote:
> This series adds the support for RISC-V Sstc extension in EDK2 timer
> implementation. Sstc extension allows S-mode software to program the
> timer directly without using SBI calls.
> 
> Currently, PCD variable is used to detect whether feature is enabled. By
> default the feature is enabled and platforms need to set the PCD to
> disable the feature if Sstc is not supported.
> 
> For RiscVVirtQemu, it is disabled by default (until extension discovery
> feature is enabled).
> 
> Changes since v1:
>   1) Updated "PATCH 3" to address Laszlo's comments.
>   2) Updated RB tag for PATCH 4.
> 
> Cc: Andrei Warkentin 
> Cc: Ard Biesheuvel 
> Cc: Gerd Hoffmann 
> Cc: Jiewen Yao 
> Cc: Laszlo Ersek 
> Cc: Rahul Kumar 
> Cc: Ray Ni 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> 
Thank you very much for reviews!. Merged as #5232.

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113616): https://edk2.groups.io/g/devel/message/113616
Mute This Topic: https://groups.io/mt/103595207/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [RFC PATCH v1 00/20] DynamicTablesPkg: Prepare to add RISC-V support

[Sunil V L]

Hi Jeshua,

On Tue, Jan 09, 2024 at 06:37:43PM +, Jeshua Smith wrote:
> > From: devel@edk2.groups.io  On Behalf Of Sunil V L
> > via groups.io
> > Sent: Tuesday, January 9, 2024 9:29 AM
> > DynamicTablesPkg can be used by RISC-V platforms to generate ACPI tables
> > from FDT passed from previous stage FW. However, DynamicTablesPkg
> > currently is ARM specific even though several parsers and ACPI generators 
> > can
> > be used across architectures. For ex: SSDT (PCIe), SSDT (CPU), MCFG, SPCR,
> > DBG2, FADT, SRAT, Raw (DSDT) are mostly common across architectures. Only
> > MADT, IORT and GTDT are ARM specific.
> > 
> > This series tries to refactor the DynamicTablesPkg so that RISC-V support 
> > can
> > be added fairly easily later.
> 
> It looks like instead of moving the common code to EObjNameSpaceStandard 
> namespace or a new (Arch? Common?) namespace, you're renaming the entire 
> EObjNameSpaceArm namespace to EObjNameSpaceArch. It seems to me that if ARM 
> code vs. common code is being separated out, then the EObjNameSpaceArm 
> namespace should continue to be used for the ARM-specific code and a common 
> namespace should be used for the common code.

I agree. I started with separating common things into new common space
and create one for risc-v. However, I dropped that approach for two
reasons.

1) The commit "b2bbe3df5470 DynamicTablesPkg: Remove PPTT ID structure
from ACPI 6.4 generator" when removed one of the enums from ArmObjectID,
didn't change the other values for other enums but reserved the removed
one. So, I thought there may be some assumptions which will break if the
enum value changes.

2) DynamicPlatformRepositoryInfo structure has ArmCmObjList and
ArmCmObjArray. With separate spaces for Arm, RiscV and Common, list
management needs some redesign and I was not sure it is worth it.

Hence, I thought a single list of all possible Obj Ids for all
architectures and common things would be a good trade off. But I can go
back to that approach in v2 if above issues are fine.

Thanks!
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113511): https://edk2.groups.io/g/devel/message/113511
Mute This Topic: https://groups.io/mt/103622702/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [RFC PATCH v1 20/20] DynamicTablesPkg.ci.yaml: Update exception and ignore list

[Sunil V L]

GICV, GICH and MPIDR are variables defined in GicCInfo structure which
probably needs to match AcpiTable.g to be all capital. But this is
against EDK2 coding standards and somehow CI gives error now though it
exists currently also. Add them to ignore list unless there is a better
way.

Add EARCH and NAMESPACEID to ignore list of the spell checker to keep CI
happy.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 DynamicTablesPkg/DynamicTablesPkg.ci.yaml | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/DynamicTablesPkg/DynamicTablesPkg.ci.yaml 
b/DynamicTablesPkg/DynamicTablesPkg.ci.yaml
index 42829f393e69..2bf8859d6c9e 100644
--- a/DynamicTablesPkg/DynamicTablesPkg.ci.yaml
+++ b/DynamicTablesPkg/DynamicTablesPkg.ci.yaml
@@ -24,6 +24,9 @@
 "9005", "@ingroup",   # Use extra Doxygen commands
 "9005", "@mainpage",  # Use extra Doxygen commands
 "9005", "@ref",   # Use extra Doxygen commands
+"8005", "CM_ARCH_GICC_INFO.GICV",
+"8005", "CM_ARCH_GICC_INFO.GICH",
+"8005", "CM_ARCH_GICC_INFO.MPIDR",
 ],
 ## Both file path and directory path are accepted.
 "IgnoreFiles": [
@@ -128,7 +131,9 @@
"TABLEEX",
"TNSID",
"Vatos",
-   "WBINVD"
+   "WBINVD",
+   "EARCH",
+   "NAMESPACEID"
],   # words to extend to the dictionary for this package
 "IgnoreStandardPaths": [],   # Standard Plugin defined paths that
  # should be ignore
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113482): https://edk2.groups.io/g/devel/message/113482
Mute This Topic: https://groups.io/mt/103622750/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [RFC PATCH v1 19/20] DynamicTablesPkg/AmlLib: Fix typo

[Sunil V L]

For some reason, spell checker in CI finds this typo though it existed
earlier.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 DynamicTablesPkg/Library/Common/AmlLib/Parser/AmlParser.c | 2 +-
 DynamicTablesPkg/Library/Common/AmlLib/Tree/AmlNode.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/DynamicTablesPkg/Library/Common/AmlLib/Parser/AmlParser.c 
b/DynamicTablesPkg/Library/Common/AmlLib/Parser/AmlParser.c
index d3a51a94c70c..3762441c7a71 100644
--- a/DynamicTablesPkg/Library/Common/AmlLib/Parser/AmlParser.c
+++ b/DynamicTablesPkg/Library/Common/AmlLib/Parser/AmlParser.c
@@ -330,7 +330,7 @@ AmlParseString (
   StrSize = 0;
   // AML String is NULL terminated.
   do {
-// Reading the stream moves the stream forward aswell.
+// Reading the stream moves the stream forward as well.
 Status = AmlStreamReadByte (FStream, );
 if (EFI_ERROR (Status)) {
   ASSERT (0);
diff --git a/DynamicTablesPkg/Library/Common/AmlLib/Tree/AmlNode.c 
b/DynamicTablesPkg/Library/Common/AmlLib/Tree/AmlNode.c
index 1404a2182b65..0a744f1ff3fa 100644
--- a/DynamicTablesPkg/Library/Common/AmlLib/Tree/AmlNode.c
+++ b/DynamicTablesPkg/Library/Common/AmlLib/Tree/AmlNode.c
@@ -573,7 +573,7 @@ AmlIsMethodDefinitionNode (
 {
   AML_DATA_NODE  *ObjectType;
 
-  // Node is checked to be an object node aswell.
+  // Node is checked to be an object node as well.
   if (AmlNodeCompareOpCode (Node, AML_METHOD_OP, 0)) {
 return TRUE;
   } else if (AmlNodeCompareOpCode (Node, AML_EXTERNAL_OP, 0)) {
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113481): https://edk2.groups.io/g/devel/message/113481
Mute This Topic: https://groups.io/mt/103622747/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [RFC PATCH v1 18/20] DynamicTablesPkg: X86: Add interfaces to succeed CI tests

[Sunil V L]

CI tests builds DynamicTablesPkg even for X86. Though the current ACPI
table list is very ARM specific, it looks like there is a value in
building it for x86. So, add dummy interfaces to help CI tests to
succeed.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 .../DynamicTableManagerDxe.inf|  5 ++-
 .../X86DynamicTableManagerDxe.c   | 44 +++
 2 files changed, 48 insertions(+), 1 deletion(-)
 create mode 100644 
DynamicTablesPkg/Drivers/DynamicTableManagerDxe/X86DynamicTableManagerDxe.c

diff --git 
a/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf 
b/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf
index b49f6b811691..646454a64bc2 100644
--- a/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf
+++ b/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf
@@ -17,7 +17,7 @@ [Defines]
 #
 # The following information is for reference only and not required by the 
build tools.
 #
-#  VALID_ARCHITECTURES   = ARM AARCH64
+#  VALID_ARCHITECTURES   = ARM AARCH64 IA32 X64
 #
 
 [Sources]
@@ -27,6 +27,9 @@ [Sources]
 [Sources.ARM, Sources.AARCH64]
   ArmDynamicTableManagerDxe.c
 
+[Sources.IA32, Sources.X64]
+  X86DynamicTableManagerDxe.c
+
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
diff --git 
a/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/X86DynamicTableManagerDxe.c 
b/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/X86DynamicTableManagerDxe.c
new file mode 100644
index ..f8b35eeb1c3c
--- /dev/null
+++ 
b/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/X86DynamicTableManagerDxe.c
@@ -0,0 +1,44 @@
+/** @file
+  X86 Dynamic Table Manager Dxe
+
+  Copyright (c) 2024, Ventana Micro Systems Inc. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include "DynamicTableManagerDxe.h"
+
+// TODO: Dummy interfaces for X86 for now.
+
+/** The function checks if the Configuration Manager has provided the
+mandatory ACPI tables for installation.
+
+  @param [in]  AcpiTableInfo  Pointer to the ACPI Table Info list.
+  @param [in]  AcpiTableCount Count of ACPI Table Info.
+
+  @retval EFI_SUCCESS Success.
+**/
+EFI_STATUS
+EFIAPI
+VerifyMandatoryTablesArePresent (
+  IN CONST CM_STD_OBJ_ACPI_TABLE_INFO  *CONST  AcpiTableInfo,
+  IN   UINT32  AcpiTableCount
+  )
+{
+  return EFI_SUCCESS;
+}
+
+/** The function checks if the FADT table is present and installed
+
+  @retval TRUE  FADT is present and installed.
+**/
+BOOLEAN
+IsFadtPresentInstalled (
+  VOID
+  )
+{
+  return TRUE;
+}
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113480): https://edk2.groups.io/g/devel/message/113480
Mute This Topic: https://groups.io/mt/103622745/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [RFC PATCH v1 17/20] DynamicTablesPkg: DynamicTableManagerDxe: Refactor to allow other archs

[Sunil V L]

mAcpiVerifyTables is an arch specific structure. So, move the structure
and the function which refers this structure to ARM specific file.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 .../DynamicTableManagerDxe.inf|   4 +
 .../DynamicTableManagerDxe.h  |  65 
 .../ArmDynamicTableManagerDxe.c   | 154 ++
 .../DynamicTableManagerDxe.c  | 145 +
 4 files changed, 225 insertions(+), 143 deletions(-)
 create mode 100644 
DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.h
 create mode 100644 
DynamicTablesPkg/Drivers/DynamicTableManagerDxe/ArmDynamicTableManagerDxe.c

diff --git 
a/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf 
b/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf
index ad8b3d037c16..b49f6b811691 100644
--- a/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf
+++ b/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.inf
@@ -22,6 +22,10 @@ [Defines]
 
 [Sources]
   DynamicTableManagerDxe.c
+  DynamicTableManagerDxe.h
+
+[Sources.ARM, Sources.AARCH64]
+  ArmDynamicTableManagerDxe.c
 
 [Packages]
   MdePkg/MdePkg.dec
diff --git 
a/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.h 
b/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.h
new file mode 100644
index ..0149d9de1bdc
--- /dev/null
+++ b/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.h
@@ -0,0 +1,65 @@
+/** @file
+
+  Copyright (c) 2017 - 2023, Arm Limited. All rights reserved.
+  Copyright (c) 2024, Ventana Micro Systems Inc. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef DYNAMIC_TABLE_MANAGER_DXE_H_
+#define DYNAMIC_TABLE_MANAGER_DXE_H_
+
+#include 
+
+///
+/// Bit definitions for acceptable ACPI table presence formats.
+/// Currently only ACPI tables present in the ACPI info list and
+/// already installed will count towards "Table Present" during
+/// verification routine.
+///
+#define ACPI_TABLE_PRESENT_INFO_LIST  BIT0
+#define ACPI_TABLE_PRESENT_INSTALLED  BIT1
+
+///
+/// Private data structure to verify the presence of mandatory
+/// or optional ACPI tables.
+///
+typedef struct {
+  /// ESTD ID for the ACPI table of interest.
+  ESTD_ACPI_TABLE_IDEstdTableId;
+  /// Standard UINT32 ACPI signature.
+  UINT32AcpiTableSignature;
+  /// 4 character ACPI table name (the 5th char8 is for null terminator).
+  CHAR8 AcpiTableName[sizeof (UINT32) + 1];
+  /// Indicator on whether the ACPI table is required.
+  BOOLEAN   IsMandatory;
+  /// Formats of verified presences, as defined by ACPI_TABLE_PRESENT_*
+  /// This field should be initialized to 0 and will be populated during
+  /// verification routine.
+  UINT16Presence;
+} ACPI_TABLE_PRESENCE_INFO;
+
+BOOLEAN
+IsFadtPresentInstalled (
+  VOID
+  );
+
+/** The function checks if the Configuration Manager has provided the
+mandatory ACPI tables for installation.
+
+  @param [in]  AcpiTableInfo  Pointer to the ACPI Table Info list.
+  @param [in]  AcpiTableCount Count of ACPI Table Info.
+
+  @retval EFI_SUCCESS   Success.
+  @retval EFI_NOT_FOUND If mandatory table is not found.
+  @retval EFI_ALREADY_STARTED   If mandatory table found in AcpiTableInfo is 
already installed.
+**/
+EFI_STATUS
+EFIAPI
+VerifyMandatoryTablesArePresent (
+  IN CONST CM_STD_OBJ_ACPI_TABLE_INFO  *CONST  AcpiTableInfo,
+  IN   UINT32  AcpiTableCount
+  );
+
+#endif // DYNAMIC_TABLE_MANAGER_DXE_H_
diff --git 
a/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/ArmDynamicTableManagerDxe.c 
b/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/ArmDynamicTableManagerDxe.c
new file mode 100644
index ..19ba501752b9
--- /dev/null
+++ 
b/DynamicTablesPkg/Drivers/DynamicTableManagerDxe/ArmDynamicTableManagerDxe.c
@@ -0,0 +1,154 @@
+/** @file
+  ARM Dynamic Table Manager Dxe
+
+  Copyright (c) 2017 - 2019, ARM Limited. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+// Module specific include files.
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "DynamicTableManagerDxe.h"
+
+///
+/// Order of ACPI table being verified during presence inspection.
+///
+#define ACPI_TABLE_VERIFY_FADT   0
+#define ACPI_TABLE_VERIFY_MADT   1
+#define ACPI_TABLE_VERIFY_GTDT   2
+#define ACPI_TABLE_VERIFY_DSDT   3
+#define ACPI_TABLE_VERIFY_DBG2   4
+#define ACPI_TABLE_VERIFY_SPCR   5
+#define ACPI_TABLE_VERIFY_COUNT  6
+
+///
+/// We require the FADT, MADT, GTDT and the DSDT tables to boot.
+/// This list also include optional ACPI tables: DBG2, SPCR.
+///
+ACPI

[edk2-devel] [RFC PATCH v1 15/20] DynamicTablesPkg: AcpiSsdtCpuTopologyLib: Move GICC from common code

[Sunil V L]

GICC is ARM specific structure. Different architectures have different
local interrupt controller structures from which CPU topology can be
created. Avoid the GICC reference in common code by,

- creating a wrapper CreateTopologyFromIntC() instead of
  CreateTopologyFromGicC() so that different archs can implement
  it differently.
- Implement arch specific functions to get AcpiProcessorUid,
  CpcToken, EtToken and use them instead of using GICC directly.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 .../SsdtCpuTopologyLib.inf|   3 +
 .../SsdtCpuTopologyGenerator.h|  48 +
 .../ArmSsdtCpuTopologyGenerator.c | 179 +
 .../SsdtCpuTopologyGenerator.c| 184 +-
 4 files changed, 274 insertions(+), 140 deletions(-)
 create mode 100644 
DynamicTablesPkg/Library/Acpi/Common/AcpiSsdtCpuTopologyLib/ArmSsdtCpuTopologyGenerator.c

diff --git 
a/DynamicTablesPkg/Library/Acpi/Common/AcpiSsdtCpuTopologyLib/SsdtCpuTopologyLib.inf
 
b/DynamicTablesPkg/Library/Acpi/Common/AcpiSsdtCpuTopologyLib/SsdtCpuTopologyLib.inf
index 2d38fb30fb09..6ec4aeeae159 100644
--- 
a/DynamicTablesPkg/Library/Acpi/Common/AcpiSsdtCpuTopologyLib/SsdtCpuTopologyLib.inf
+++ 
b/DynamicTablesPkg/Library/Acpi/Common/AcpiSsdtCpuTopologyLib/SsdtCpuTopologyLib.inf
@@ -16,6 +16,9 @@ [Defines]
   CONSTRUCTOR= AcpiSsdtCpuTopologyLibConstructor
   DESTRUCTOR = AcpiSsdtCpuTopologyLibDestructor
 
+[Sources.ARM, Sources.AARCH64]
+  ArmSsdtCpuTopologyGenerator.c
+
 [Sources]
   SsdtCpuTopologyGenerator.c
   SsdtCpuTopologyGenerator.h
diff --git 
a/DynamicTablesPkg/Library/Acpi/Common/AcpiSsdtCpuTopologyLib/SsdtCpuTopologyGenerator.h
 
b/DynamicTablesPkg/Library/Acpi/Common/AcpiSsdtCpuTopologyLib/SsdtCpuTopologyGenerator.h
index 57ff8009b59d..872c5c010d5c 100644
--- 
a/DynamicTablesPkg/Library/Acpi/Common/AcpiSsdtCpuTopologyLib/SsdtCpuTopologyGenerator.h
+++ 
b/DynamicTablesPkg/Library/Acpi/Common/AcpiSsdtCpuTopologyLib/SsdtCpuTopologyGenerator.h
@@ -144,4 +144,52 @@ typedef struct AcpiCpuTopologyGenerator {
 
 #pragma pack()
 
+EFI_STATUS
+EFIAPI
+GetIntCUidTokens (
+  IN  CONST EDKII_CONFIGURATION_MANAGER_PROTOCOL  *CONST  CfgMgrProtocol,
+  IN  CM_OBJECT_TOKEN IntCToken,
+  OUT UINT32  *AcpiProcessorUid,
+  OUT CM_OBJECT_TOKEN *CpcToken,
+  OUT CM_OBJECT_TOKEN *EtToken
+  );
+
+EFI_STATUS
+EFIAPI
+CreateAmlEtNode (
+  IN  ACPI_CPU_TOPOLOGY_GENERATOR *Generator,
+  IN  CONST EDKII_CONFIGURATION_MANAGER_PROTOCOL  *CONST  CfgMgrProtocol,
+  IN  UINT32  AcpiProcessorUid,
+  IN  CM_OBJECT_TOKEN EtToken,
+  IN  UINT32  CpuName,
+  IN  AML_OBJECT_NODE_HANDLE  *Node
+  );
+
+EFI_STATUS
+EFIAPI
+CreateAmlCpcNode (
+  IN  ACPI_CPU_TOPOLOGY_GENERATOR *Generator,
+  IN  CONST EDKII_CONFIGURATION_MANAGER_PROTOCOL  *CONST  CfgMgrProtocol,
+  IN  CM_OBJECT_TOKEN CpcToken,
+  IN  AML_OBJECT_NODE_HANDLE  *Node
+  );
+
+EFI_STATUS
+EFIAPI
+CreateAmlCpu (
+  IN   ACPI_CPU_TOPOLOGY_GENERATOR  *Generator,
+  IN   AML_NODE_HANDLE  ParentNode,
+  IN   UINT32   Uid,
+  IN   UINT32   CpuName,
+  OUT  AML_OBJECT_NODE_HANDLE   *CpuNodePtr OPTIONAL
+  );
+
+EFI_STATUS
+EFIAPI
+CreateTopologyFromIntC (
+  INACPI_CPU_TOPOLOGY_GENERATOR   *Generator,
+  IN  CONST EDKII_CONFIGURATION_MANAGER_PROTOCOL  *CONST  CfgMgrProtocol,
+  INAML_OBJECT_NODE_HANDLEScopeNode
+  );
+
 #endif // SSDT_CPU_TOPOLOGY_GENERATOR_H_
diff --git 
a/DynamicTablesPkg/Library/Acpi/Common/AcpiSsdtCpuTopologyLib/ArmSsdtCpuTopologyGenerator.c
 
b/DynamicTablesPkg/Library/Acpi/Common/AcpiSsdtCpuTopologyLib/ArmSsdtCpuTopologyGenerator.c
new file mode 100644
index ..3078c206224f
--- /dev/null
+++ 
b/DynamicTablesPkg/Library/Acpi/Common/AcpiSsdtCpuTopologyLib/ArmSsdtCpuTopologyGenerator.c
@@ -0,0 +1,179 @@
+/** @file
+  ARM SSDT Cpu Topology Table Generator Helpers.
+
+  Copyright (c) 2021 - 2023, Arm Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+- ACPI 6.3 Specification - January 2019 - s8.4 Declaring Processors
+- ACPI for CoreSight version 1.2 Platform Design Document
+  (https://developer.arm.com/documentation/den0067/a/?lang=en)
+
+  @par Glossary:
+- ETE - Embedded Trace Extension.
+- ETM - Embedded Trace Macrocell.
+**/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+// Module specific include files.
+#include 
+#include

[edk2-devel] [RFC PATCH v1 16/20] DynamicTablesPkg: AcpiFadtLib: Move ArmBootArch to ARM specific file

[Sunil V L]

ArmBootArch field in FADT is specific to ARM. To leverage most of the
code in FADT generator for other architectures, this needs to be moved
into ARM specific file. There may be other fields in future (ex:
IA_PC_BOOT_ARCH) that need to be created in similar way. So, instead of
adding the function only to create BootArch, make this function generic
to add all arch specific functions into FADT.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 .../Acpi/Common/AcpiFadtLib/AcpiFadtLib.inf   |  4 +
 .../Acpi/Common/AcpiFadtLib/FadtGenerator.h   | 32 
 .../Common/AcpiFadtLib/ArmFadtGenerator.c | 80 +++
 .../Acpi/Common/AcpiFadtLib/FadtGenerator.c   | 71 ++--
 .../Arm/BootArch/ArmBootArchParser.c  |  8 +-
 5 files changed, 125 insertions(+), 70 deletions(-)
 create mode 100644 
DynamicTablesPkg/Library/Acpi/Common/AcpiFadtLib/FadtGenerator.h
 create mode 100644 
DynamicTablesPkg/Library/Acpi/Common/AcpiFadtLib/ArmFadtGenerator.c

diff --git a/DynamicTablesPkg/Library/Acpi/Common/AcpiFadtLib/AcpiFadtLib.inf 
b/DynamicTablesPkg/Library/Acpi/Common/AcpiFadtLib/AcpiFadtLib.inf
index c9cd850faac0..1ea47aefc3e1 100644
--- a/DynamicTablesPkg/Library/Acpi/Common/AcpiFadtLib/AcpiFadtLib.inf
+++ b/DynamicTablesPkg/Library/Acpi/Common/AcpiFadtLib/AcpiFadtLib.inf
@@ -18,6 +18,10 @@ [Defines]
 
 [Sources]
   FadtGenerator.c
+  FadtGenerator.h
+
+[Sources.ARM, Sources.AARCH64]
+  ArmFadtGenerator.c
 
 [Packages]
   MdePkg/MdePkg.dec
diff --git a/DynamicTablesPkg/Library/Acpi/Common/AcpiFadtLib/FadtGenerator.h 
b/DynamicTablesPkg/Library/Acpi/Common/AcpiFadtLib/FadtGenerator.h
new file mode 100644
index ..bb98ea4c8854
--- /dev/null
+++ b/DynamicTablesPkg/Library/Acpi/Common/AcpiFadtLib/FadtGenerator.h
@@ -0,0 +1,32 @@
+/** @file
+
+  Copyright (c) 2017 - 2023, Arm Limited. All rights reserved.
+  Copyright (c) 2024, Ventana Micro Systems Inc. All rights reserved.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef FADT_GENERATOR_H_
+#define FADT_GENERATOR_H_
+
+/** Updates the Architecture specific information in the FADT Table.
+
+  @param [in]  CfgMgrProtocol Pointer to the Configuration Manager
+  Protocol Interface.
+
+  @retval EFI_SUCCESS   Success.
+  @retval EFI_INVALID_PARAMETER A parameter is invalid.
+  @retval EFI_NOT_FOUND The required object was not found.
+  @retval EFI_BAD_BUFFER_SIZE   The size returned by the Configuration
+Manager is less than the Object size for the
+requested object.
+**/
+EFI_STATUS
+EFIAPI
+FadtAddArchInfo (
+  IN  CONST EDKII_CONFIGURATION_MANAGER_PROTOCOL  *CONST  CfgMgrProtocol,
+  OUT EFI_ACPI_6_5_FIXED_ACPI_DESCRIPTION_TABLE   *Fadt
+  );
+
+#endif // FADT_GENERATOR_H_
diff --git 
a/DynamicTablesPkg/Library/Acpi/Common/AcpiFadtLib/ArmFadtGenerator.c 
b/DynamicTablesPkg/Library/Acpi/Common/AcpiFadtLib/ArmFadtGenerator.c
new file mode 100644
index ..ca4f6958a5b9
--- /dev/null
+++ b/DynamicTablesPkg/Library/Acpi/Common/AcpiFadtLib/ArmFadtGenerator.c
@@ -0,0 +1,80 @@
+/** @file
+  ARM FADT Table Helpers
+
+  Copyright (c) 2017 - 2023, Arm Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+  - ACPI 6.5 Specification, Aug 29, 2022
+
+**/
+
+#include 
+#include 
+#include 
+
+// Module specific include files.
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "FadtGenerator.h"
+
+/** This macro expands to a function that retrieves the Boot
+Architecture Information from the Configuration Manager.
+*/
+GET_OBJECT_LIST (
+  EObjNameSpaceArch,
+  EArchObjBootArchInfo,
+  CM_ARCH_BOOT_ARCH_INFO
+  );
+
+/** Updates the Architecture specific information in the FADT Table.
+
+  @param [in]  CfgMgrProtocol Pointer to the Configuration Manager
+  Protocol Interface.
+  @param [out] Fadt   Pointer to the FADT table
+
+  @retval EFI_SUCCESS   Success.
+  @retval EFI_NOT_FOUND The required object was not found.
+**/
+EFI_STATUS
+EFIAPI
+FadtAddArchInfo (
+  IN  CONST EDKII_CONFIGURATION_MANAGER_PROTOCOL  *CONST  CfgMgrProtocol,
+  OUT EFI_ACPI_6_5_FIXED_ACPI_DESCRIPTION_TABLE   *Fadt
+  )
+{
+  EFI_STATUS  Status;
+  CM_ARCH_BOOT_ARCH_INFO  *BootArchInfo;
+
+  ASSERT (CfgMgrProtocol != NULL);
+
+  // Get the Boot Architecture flags from the Platform Configuration Manager
+  Status = GetEArchObjBootArchInfo (
+ CfgMgrProtocol,
+ CM_NULL_TOKEN,
+ ,
+ NULL
+ );
+  if (EFI_ERROR (Status)) {
+DEBUG ((
+  DEBUG_ERROR,
+  "ERROR: FADT: Failed to get Boot Architecture flags. Status = %r\n",
+  Status
+  ));
+goto error_handler;
+  }
+
+  DEBUG ((
+DEBUG_INFO,
+"FADT BootArchFlag = 0

[edk2-devel] [RFC PATCH v1 14/20] DynamicTablesPkg/FdtHwInfoParserLib: Add function for INTC address cells

[Sunil V L]

Parent interrupt controller's address cells is arch specific. So,
create a function which can be implemented differently for
different archs. Move current implementation to ARM specific file.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 .../Library/FdtHwInfoParserLib/FdtUtility.h   |  9 ++
 .../FdtHwInfoParserLib/Arm/ArmFdtUtility.c| 29 +++
 .../Pci/PciConfigSpaceParser.c|  2 +-
 3 files changed, 39 insertions(+), 1 deletion(-)

diff --git a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtUtility.h 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtUtility.h
index 3f5d131d9ae5..1d56d044a73e 100644
--- a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtUtility.h
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtUtility.h
@@ -455,4 +455,13 @@ FdtGetParentAddressInfo (
   OUT   INT32 *SizeCells   OPTIONAL
   );
 
+EFI_STATUS
+EFIAPI
+FdtGetIntcAddressCells (
+  IN  CONST VOID *Fdt,
+  ININT32 Node,
+  OUT   INT32 *AddressCells, OPTIONAL
+  OUT   INT32 *SizeCells   OPTIONAL
+  );
+
 #endif // FDT_UTILITY_H_
diff --git a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtUtility.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtUtility.c
index 21b1306e577d..1b2196ef1734 100644
--- a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtUtility.c
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtUtility.c
@@ -83,3 +83,32 @@ FdtGetInterruptFlags (
 
   return AcpiIrqFlags;
 }
+
+/** Get the Address cell info of the INTC node
+
+  @param [in]  Fdt  Pointer to a Flattened Device Tree.
+  @param [in]  Node Offset of the node having to get the
+"#address-cells" and "#size-cells"
+properties from.
+  @param [out] AddressCells If success, number of address-cells.
+If the property is not available,
+default value is 2.
+  @param [out] SizeCellsIf success, number of size-cells.
+If the property is not available,
+default value is 1.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_ABORTED An error occurred.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+**/
+EFI_STATUS
+EFIAPI
+FdtGetIntcAddressCells (
+  IN  CONST VOID *Fdt,
+  ININT32 Node,
+  OUT   INT32 *AddressCells, OPTIONAL
+  OUT   INT32 *SizeCells OPTIONAL
+  )
+{
+  return FdtGetAddressInfo (Fdt, Node, AddressCells, SizeCells);
+}
diff --git 
a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/PciConfigSpaceParser.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/PciConfigSpaceParser.c
index afe756bcedab..766f784da13c 100644
--- a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/PciConfigSpaceParser.c
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/PciConfigSpaceParser.c
@@ -365,7 +365,7 @@ ParseIrqMap (
   }
 
   // Get the "address-cells" property of the IntcNode.
-  Status = FdtGetAddressInfo (Fdt, IntcNode, , NULL);
+  Status = FdtGetIntcAddressCells (Fdt, IntcNode, , NULL);
   if (EFI_ERROR (Status)) {
 ASSERT (0);
 return Status;
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113476): https://edk2.groups.io/g/devel/message/113476
Mute This Topic: https://groups.io/mt/103622734/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [RFC PATCH v1 13/20] DynamicTablesPkg: FdtHwInfoParserLib: Move ARM utilities to separate file

[Sunil V L]

The SPI/PPI ranges are ARM specific and the number of entries in
"interrupt-map" property can be different across architectures. Hence,
move these utility functions to ARM specific file so that common code is
clean and other architectures can easily implement their version.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 .../FdtHwInfoParserLib/FdtHwInfoParserLib.inf |  1 +
 .../FdtHwInfoParserLib/Arm/ArmFdtUtility.c| 85 +++
 .../Library/FdtHwInfoParserLib/FdtUtility.c   | 71 
 3 files changed, 86 insertions(+), 71 deletions(-)
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtUtility.c

diff --git a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
index d3010af527c1..8e1ea100bd34 100644
--- a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
@@ -28,6 +28,7 @@ [Sources]
   Serial/SerialPortParser.h
 
 [Sources.ARM, Sources.AARCH64]
+  Arm/ArmFdtUtility.c
   Arm/ArmFdtHwInfoParser.c
   Arm/BootArch/ArmBootArchParser.c
   Arm/BootArch/ArmBootArchParser.h
diff --git a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtUtility.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtUtility.c
new file mode 100644
index ..21b1306e577d
--- /dev/null
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtUtility.c
@@ -0,0 +1,85 @@
+/** @file
+  Flattened device tree utility.
+
+  Copyright (c) 2021, ARM Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+  @par Reference(s):
+  - Device tree Specification - Release v0.3
+  - linux/Documentation/devicetree/bindings/interrupt-controller/arm%2Cgic.yaml
+  - 
linux//Documentation/devicetree/bindings/interrupt-controller/arm%2Cgic.yaml
+**/
+
+#include 
+#include "FdtUtility.h"
+
+/** Get the interrupt Id of an interrupt described in a fdt.
+
+  Data must describe a GIC interrupt. A GIC interrupt is on at least
+  3 UINT32 cells.
+  This function DOES NOT SUPPORT extended SPI range and extended PPI range.
+
+  @param [in]  Data   Pointer to the first cell of an "interrupts" property.
+
+  @retval  The interrupt id.
+**/
+UINT32
+EFIAPI
+FdtGetInterruptId (
+  UINT32 CONST  *Data
+  )
+{
+  UINT32  IrqType;
+  UINT32  IrqId;
+
+  ASSERT (Data != NULL);
+
+  IrqType = fdt32_to_cpu (Data[IRQ_TYPE_OFFSET]);
+  IrqId   = fdt32_to_cpu (Data[IRQ_NUMBER_OFFSET]);
+
+  switch (IrqType) {
+case DT_SPI_IRQ:
+  IrqId += SPI_OFFSET;
+  break;
+
+case DT_PPI_IRQ:
+  IrqId += PPI_OFFSET;
+  break;
+
+default:
+  ASSERT (0);
+  IrqId = 0;
+  }
+
+  return IrqId;
+}
+
+/** Get the ACPI interrupt flags of an interrupt described in a fdt.
+
+  Data must describe a GIC interrupt. A GIC interrupt is on at least
+  3 UINT32 cells.
+
+  PPI interrupt cpu mask on bits [15:8] are ignored.
+
+  @param [in]  Data   Pointer to the first cell of an "interrupts" property.
+
+  @retval  The interrupt flags (for ACPI).
+**/
+UINT32
+EFIAPI
+FdtGetInterruptFlags (
+  UINT32 CONST  *Data
+  )
+{
+  UINT32  IrqFlags;
+  UINT32  AcpiIrqFlags;
+
+  ASSERT (Data != NULL);
+
+  IrqFlags = fdt32_to_cpu (Data[IRQ_FLAGS_OFFSET]);
+
+  AcpiIrqFlags  = DT_IRQ_IS_EDGE_TRIGGERED (IrqFlags) ? BIT0 : 0;
+  AcpiIrqFlags |= DT_IRQ_IS_ACTIVE_LOW (IrqFlags) ? BIT1 : 0;
+
+  return AcpiIrqFlags;
+}
diff --git a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtUtility.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtUtility.c
index 5314cf3808c2..bab228575938 100644
--- a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtUtility.c
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtUtility.c
@@ -13,77 +13,6 @@
 #include 
 #include "FdtUtility.h"
 
-/** Get the interrupt Id of an interrupt described in a fdt.
-
-  Data must describe a GIC interrupt. A GIC interrupt is on at least
-  3 UINT32 cells.
-  This function DOES NOT SUPPORT extended SPI range and extended PPI range.
-
-  @param [in]  Data   Pointer to the first cell of an "interrupts" property.
-
-  @retval  The interrupt id.
-**/
-UINT32
-EFIAPI
-FdtGetInterruptId (
-  UINT32 CONST  *Data
-  )
-{
-  UINT32  IrqType;
-  UINT32  IrqId;
-
-  ASSERT (Data != NULL);
-
-  IrqType = fdt32_to_cpu (Data[IRQ_TYPE_OFFSET]);
-  IrqId   = fdt32_to_cpu (Data[IRQ_NUMBER_OFFSET]);
-
-  switch (IrqType) {
-case DT_SPI_IRQ:
-  IrqId += SPI_OFFSET;
-  break;
-
-case DT_PPI_IRQ:
-  IrqId += PPI_OFFSET;
-  break;
-
-default:
-  ASSERT (0);
-  IrqId = 0;
-  }
-
-  return IrqId;
-}
-
-/** Get the ACPI interrupt flags of an interrupt described in a fdt.
-
-  Data must describe a GIC interrupt. A GIC interrupt is on at least
-  3 UINT32 cells.
-
-  PPI interrupt cpu mask on bits [15:8] are ignored.
-
-  @pa

[edk2-devel] [RFC PATCH v1 12/20] DynamicTablesPkg: Add CreatorId in CM_STD_OBJ_CONFIGURATION_MANAGER_INFO

[Sunil V L]

To support multiple CPU architectures and platforms, it is better to
have the flexibility for the platforms to define their Creator ID in the
ACPI tables. So, add a new field in the structure and use it while
creating the ACPI tables instead of default ARM.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h  | 1 +
 DynamicTablesPkg/Include/StandardNameSpaceObjects.h   | 1 +
 .../Library/Common/AmlLib/CodeGen/AmlCodeGen.c| 3 ++-
 .../Library/Common/TableHelperLib/TableHelper.c   | 8 +++-
 4 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h 
b/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
index 043ec3d8428f..dc1fab534030 100644
--- a/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
+++ b/DynamicTablesPkg/Include/Library/AmlLib/AmlLib.h
@@ -1061,6 +1061,7 @@ AmlCodeGenDefinitionBlock (
   IN  CONST CHAR8 *OemId,
   IN  CONST CHAR8 *OemTableId,
   INUINT32OemRevision,
+  IN  CONST CHAR8 *CreatorId,
   OUT   AML_ROOT_NODE_HANDLE  *NewRootNode
   );
 
diff --git a/DynamicTablesPkg/Include/StandardNameSpaceObjects.h 
b/DynamicTablesPkg/Include/StandardNameSpaceObjects.h
index 8ec3238225ab..d894b9cbb6f9 100644
--- a/DynamicTablesPkg/Include/StandardNameSpaceObjects.h
+++ b/DynamicTablesPkg/Include/StandardNameSpaceObjects.h
@@ -60,6 +60,7 @@ typedef struct CmStdObjConfigurationManagerInfo {
   populate the ACPI table header information.
   */
   UINT8 OemId[6];
+  UINT8 CreatorId[4];
 } CM_STD_OBJ_CONFIGURATION_MANAGER_INFO;
 
 /** A structure used to describe the ACPI table generators to be invoked.
diff --git a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c 
b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
index d4e3e252cbe6..e1d72ec9444e 100644
--- a/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
+++ b/DynamicTablesPkg/Library/Common/AmlLib/CodeGen/AmlCodeGen.c
@@ -95,6 +95,7 @@ AmlCodeGenDefinitionBlock (
   IN  CONST CHAR8  *OemId,
   IN  CONST CHAR8  *OemTableId,
   INUINT32 OemRevision,
+  IN  CONST CHAR8  *CreatorId,
   OUT   AML_ROOT_NODE  **NewRootNode
   )
 {
@@ -115,8 +116,8 @@ AmlCodeGenDefinitionBlock (
   AcpiHeader.Revision = 2;
   CopyMem (, OemId, 6);
   CopyMem (, OemTableId, 8);
+  CopyMem (, CreatorId, 4);
   AcpiHeader.OemRevision = OemRevision;
-  AcpiHeader.CreatorId   = TABLE_GENERATOR_CREATOR_ID_ARM;
   AcpiHeader.CreatorRevision = CREATE_REVISION (1, 0);
 
   Status = AmlCreateRootNode (, NewRootNode);
diff --git a/DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c 
b/DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c
index 219f94e0dbcc..a2ad480b9b3b 100644
--- a/DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c
+++ b/DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c
@@ -180,7 +180,12 @@ AddAcpiHeader (
   }
 
   // UINT32  CreatorId
-  AcpiHeader->CreatorId = Generator->CreatorId;
+  AcpiHeader->CreatorId = SIGNATURE_32 (
+CfgMfrInfo->CreatorId[0],
+CfgMfrInfo->CreatorId[1],
+CfgMfrInfo->CreatorId[2],
+CfgMfrInfo->CreatorId[3]
+);
   // UINT32  CreatorRevision
   AcpiHeader->CreatorRevision = Generator->CreatorRevision;
 
@@ -270,6 +275,7 @@ AddSsdtAcpiHeader (
  (CONST CHAR8 *)>OemId,
  (CONST CHAR8 *),
  OemRevision,
+ (CONST CHAR8 *)>CreatorId,
  RootNode
  );
   ASSERT_EFI_ERROR (Status);
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113474): https://edk2.groups.io/g/devel/message/113474
Mute This Topic: https://groups.io/mt/103622728/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [RFC PATCH v1 11/20] DynamicTablesPkg: TableHelperLib: Populate OemTableId using ConfigManager

[Sunil V L]

To support multiple CPU architectures/vendors, it is better to create
OemTableId using the platform provided value instead of default ARM.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 .../Common/TableHelperLib/TableHelper.c   | 24 ---
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c 
b/DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c
index 549cee1b3fd5..219f94e0dbcc 100644
--- a/DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c
+++ b/DynamicTablesPkg/Library/Common/TableHelperLib/TableHelper.c
@@ -161,20 +161,16 @@ AddAcpiHeader (
   CopyMem (AcpiHeader->OemId, CfgMfrInfo->OemId, sizeof (AcpiHeader->OemId));
 
   // UINT64  OemTableId
-  if (AcpiTableInfo->OemTableId != 0) {
-AcpiHeader->OemTableId = AcpiTableInfo->OemTableId;
-  } else {
-AcpiHeader->OemTableId = SIGNATURE_32 (
-   CfgMfrInfo->OemId[0],
-   CfgMfrInfo->OemId[1],
-   CfgMfrInfo->OemId[2],
-   CfgMfrInfo->OemId[3]
-   ) |
- LShiftU64 (
-   (UINT64)Generator->AcpiTableSignature,
-   32
-   );
-  }
+  AcpiHeader->OemTableId = SIGNATURE_32 (
+ CfgMfrInfo->OemId[0],
+ CfgMfrInfo->OemId[1],
+ CfgMfrInfo->OemId[2],
+ CfgMfrInfo->OemId[3]
+ ) |
+   LShiftU64 (
+ (UINT64)Generator->AcpiTableSignature,
+ 32
+ );
 
   // UINT32  OemRevision
   if (AcpiTableInfo->OemRevision != 0) {
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113473): https://edk2.groups.io/g/devel/message/113473
Mute This Topic: https://groups.io/mt/103622727/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [RFC PATCH v1 10/20] DynamicTablesPkg: FdtHwInfoParserLib: Move ArmLib.h to ArmGicCParser.c

[Sunil V L]

ArmLib.h is required only for building GIC in ARM. So, move it to ARM
specific file. Otherwise, FdtHwInfoParserInclude.h being a common header
across architectures will have issue on other architectures.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 .../Library/FdtHwInfoParserLib/FdtHwInfoParserInclude.h  | 1 -
 .../Library/FdtHwInfoParserLib/Arm/Gic/ArmGicCParser.c   | 1 +
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserInclude.h 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserInclude.h
index 583f290095d9..60f671eccc3f 100644
--- a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserInclude.h
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserInclude.h
@@ -10,7 +10,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git 
a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/Gic/ArmGicCParser.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/Gic/ArmGicCParser.c
index e5cf5c776d0f..bd4de8811963 100644
--- a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/Gic/ArmGicCParser.c
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/Gic/ArmGicCParser.c
@@ -11,6 +11,7 @@
   - linux/Documentation/devicetree/bindings/arm/pmu.yaml
 **/
 
+#include 
 #include "FdtHwInfoParser.h"
 #include "CmObjectDescUtility.h"
 #include "Arm/Gic/ArmGicCParser.h"
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113472): https://edk2.groups.io/g/devel/message/113472
Mute This Topic: https://groups.io/mt/103622725/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [RFC PATCH v1 09/20] DynamicTablesPkg: FdtHwInfoParserLib: Make Serial parser arch neutral

[Sunil V L]

SerialPortParser is a generic concept and can be used by other
architectures. Hence, rename to reflect it is common and updates the
consumers.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 .../FdtHwInfoParserLib/FdtHwInfoParserLib.inf  |  4 ++--
 ...rmSerialPortParser.h => SerialPortParser.h} |  8 
 .../Arm/ArmFdtHwInfoParser.c   |  2 +-
 ...rmSerialPortParser.c => SerialPortParser.c} | 18 +-
 4 files changed, 16 insertions(+), 16 deletions(-)
 rename 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/{ArmSerialPortParser.h => 
SerialPortParser.h} (89%)
 rename 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/{ArmSerialPortParser.c => 
SerialPortParser.c} (94%)

diff --git a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
index 55ec7d97fa18..d3010af527c1 100644
--- a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
@@ -24,8 +24,8 @@ [Sources]
   FdtUtility.h
   Pci/PciConfigSpaceParser.c
   Pci/PciConfigSpaceParser.h
-  Serial/ArmSerialPortParser.c
-  Serial/ArmSerialPortParser.h
+  Serial/SerialPortParser.c
+  Serial/SerialPortParser.h
 
 [Sources.ARM, Sources.AARCH64]
   Arm/ArmFdtHwInfoParser.c
diff --git 
a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/ArmSerialPortParser.h 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/SerialPortParser.h
similarity index 89%
rename from 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/ArmSerialPortParser.h
rename to DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/SerialPortParser.h
index b3e227472772..e5f151ded329 100644
--- a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/ArmSerialPortParser.h
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/SerialPortParser.h
@@ -1,5 +1,5 @@
 /** @file
-  Arm Serial Port Parser.
+  Serial Port Parser.
 
   Copyright (c) 2021, ARM Limited. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -9,8 +9,8 @@
   - linux/Documentation/devicetree/bindings/serial/8250.txt
 **/
 
-#ifndef ARM_SERIAL_PORT_PARSER_H_
-#define ARM_SERIAL_PORT_PARSER_H_
+#ifndef SERIAL_PORT_PARSER_H_
+#define SERIAL_PORT_PARSER_H_
 
 /** SerialPort dispatcher.
 
@@ -44,4 +44,4 @@ SerialPortDispatcher (
   ININT32  FdtBranch
   );
 
-#endif // ARM_SERIAL_PORT_PARSER_H_
+#endif // SERIAL_PORT_PARSER_H_
diff --git 
a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtHwInfoParser.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtHwInfoParser.c
index 8dd6546e62f0..2700e9a2a5fe 100644
--- a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtHwInfoParser.c
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtHwInfoParser.c
@@ -10,7 +10,7 @@
 #include "Arm/GenericTimer/ArmGenericTimerParser.h"
 #include "Arm/Gic/ArmGicDispatcher.h"
 #include "Pci/PciConfigSpaceParser.h"
-#include "Serial/ArmSerialPortParser.h"
+#include "Serial/SerialPortParser.h"
 
 /** Ordered table of parsers/dispatchers.
 
diff --git 
a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/ArmSerialPortParser.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/SerialPortParser.c
similarity index 94%
rename from 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/ArmSerialPortParser.c
rename to DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/SerialPortParser.c
index 47df82c4ba63..6d233fefa85f 100644
--- a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/ArmSerialPortParser.c
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Serial/SerialPortParser.c
@@ -1,5 +1,5 @@
 /** @file
-  Arm Serial Port Parser.
+  Serial Port Parser.
 
   Copyright (c) 2021 - 2023, Arm Limited. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -15,7 +15,7 @@
 
 #include "CmObjectDescUtility.h"
 #include "FdtHwInfoParser.h"
-#include "Serial/ArmSerialPortParser.h"
+#include "Serial/SerialPortParser.h"
 
 /** List of "compatible" property values for serial port nodes.
 
@@ -329,7 +329,7 @@ GetSerialConsoleNode (
 STATIC
 EFI_STATUS
 EFIAPI
-ArmSerialPortInfoDispatch (
+SerialPortInfoDispatch (
   IN  CONST FDT_HW_INFO_PARSER_HANDLE  FdtParserHandle,
   IN  CM_ARCH_SERIAL_PORT_INFO *GenericSerialInfo,
   IN  INT32NodeCount,
@@ -396,7 +396,7 @@ ArmSerialPortInfoDispatch (
   @param [in]  FdtParserHandle A handle to the parser instance.
   @param [in]  FdtBranch   When searching for DT node name, restrict
the search to this Device Tree branch.
-  @param [in]  SerialObjectId  ArmNamespace Object ID for the serial port.
+  @param [in]  SerialObjectId  ArchNamespace Object ID for the serial port.
 
   @retval EFI_SUCCESS

[edk2-devel] [RFC PATCH v1 08/20] DynamicTablesPkg: FdtHwInfoParserLib: Pci: Make it common for architectures

[Sunil V L]

PciConfigParser is a generic concept and can be used by other
architectures. Hence, rename to reflect it is common and updates the
consumers.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 .../FdtHwInfoParserLib/FdtHwInfoParserLib.inf   |  4 ++--
 ...nfigSpaceParser.h => PciConfigSpaceParser.h} | 10 +-
 .../FdtHwInfoParserLib/Arm/ArmFdtHwInfoParser.c |  4 ++--
 ...nfigSpaceParser.c => PciConfigSpaceParser.c} | 17 -
 4 files changed, 13 insertions(+), 22 deletions(-)
 rename 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/{ArmPciConfigSpaceParser.h => 
PciConfigSpaceParser.h} (93%)
 rename 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/{ArmPciConfigSpaceParser.c => 
PciConfigSpaceParser.c} (95%)

diff --git a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
index 3abc6a0fd274..55ec7d97fa18 100644
--- a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
@@ -22,8 +22,8 @@ [Sources]
   FdtHwInfoParser.h
   FdtUtility.c
   FdtUtility.h
-  Pci/ArmPciConfigSpaceParser.c
-  Pci/ArmPciConfigSpaceParser.h
+  Pci/PciConfigSpaceParser.c
+  Pci/PciConfigSpaceParser.h
   Serial/ArmSerialPortParser.c
   Serial/ArmSerialPortParser.h
 
diff --git 
a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/ArmPciConfigSpaceParser.h 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/PciConfigSpaceParser.h
similarity index 93%
rename from 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/ArmPciConfigSpaceParser.h
rename to DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/PciConfigSpaceParser.h
index bfe724a69e55..106a7a92af47 100644
--- a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/ArmPciConfigSpaceParser.h
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/PciConfigSpaceParser.h
@@ -1,5 +1,5 @@
 /** @file
-  Arm PCI Configuration Space Parser.
+  PCI Configuration Space Parser.
 
   Copyright (c) 2021, ARM Limited. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -12,8 +12,8 @@
   - linux kernel code
 **/
 
-#ifndef ARM_PCI_CONFIG_SPACE_PARSER_H_
-#define ARM_PCI_CONFIG_SPACE_PARSER_H_
+#ifndef PCI_CONFIG_SPACE_PARSER_H_
+#define PCI_CONFIG_SPACE_PARSER_H_
 
 /** Read LEN bits at OFF offsets bits of the ADDR.
 
@@ -135,9 +135,9 @@ typedef struct PciParserTable {
 **/
 EFI_STATUS
 EFIAPI
-ArmPciConfigInfoParser (
+PciConfigInfoParser (
   IN  CONST FDT_HW_INFO_PARSER_HANDLE  FdtParserHandle,
   ININT32  FdtBranch
   );
 
-#endif // ARM_PCI_CONFIG_SPACE_PARSER_H_
+#endif // PCI_CONFIG_SPACE_PARSER_H_
diff --git 
a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtHwInfoParser.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtHwInfoParser.c
index 4b1f5eeea423..8dd6546e62f0 100644
--- a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtHwInfoParser.c
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtHwInfoParser.c
@@ -9,7 +9,7 @@
 #include "Arm/BootArch/ArmBootArchParser.h"
 #include "Arm/GenericTimer/ArmGenericTimerParser.h"
 #include "Arm/Gic/ArmGicDispatcher.h"
-#include "Pci/ArmPciConfigSpaceParser.h"
+#include "Pci/PciConfigSpaceParser.h"
 #include "Serial/ArmSerialPortParser.h"
 
 /** Ordered table of parsers/dispatchers.
@@ -25,7 +25,7 @@ STATIC CONST FDT_HW_INFO_PARSER_FUNC  HwInfoParserTable[] = {
   ArmBootArchInfoParser,
   ArmGenericTimerInfoParser,
   ArmGicDispatcher,
-  ArmPciConfigInfoParser,
+  PciConfigInfoParser,
   SerialPortDispatcher
 };
 
diff --git 
a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/ArmPciConfigSpaceParser.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/PciConfigSpaceParser.c
similarity index 95%
rename from 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/ArmPciConfigSpaceParser.c
rename to DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/PciConfigSpaceParser.c
index d6a08c47b7d5..afe756bcedab 100644
--- a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/ArmPciConfigSpaceParser.c
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Pci/PciConfigSpaceParser.c
@@ -1,5 +1,5 @@
 /** @file
-  Arm PCI Configuration Space Parser.
+  PCI Configuration Space Parser.
 
   Copyright (c) 2021, ARM Limited. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -16,8 +16,7 @@
 #include 
 
 #include "FdtHwInfoParser.h"
-#include "Pci/ArmPciConfigSpaceParser.h"
-#include "Arm/Gic/ArmGicDispatcher.h"
+#include "Pci/PciConfigSpaceParser.h"
 
 /** List of "compatible" property values for host PCIe bridges nodes.
 
@@ -306,8 +305,7 @@ ParseIrqMap (
   CONST UINT8  *IrqMapMask;
   INT32IrqMapMaskSize;
 
-  INT32   PHandleOffset;
-  UINT32  GicVersion;
+  INT32  PHandleOffset;
 
   UINT32  PciAddressAttr;
 
@@ -366,13 +364,6 @@

[edk2-devel] [RFC PATCH v1 07/20] DynamicTablesPkg: FdtHwInfoParserLib: Separate ARM specific code

[Sunil V L]

HwInfoParserTable is an architecture specific structure. Hence, move it
and the MainDispatcher function to ARCH specific file. Update INF file.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 .../FdtHwInfoParserLib/FdtHwInfoParserLib.inf | 15 ++--
 .../FdtHwInfoParserLib/FdtHwInfoParser.h  | 27 ++
 .../Arm/ArmFdtHwInfoParser.c  | 83 +++
 .../FdtHwInfoParserLib/FdtHwInfoParser.c  | 78 +
 4 files changed, 121 insertions(+), 82 deletions(-)
 create mode 100644 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtHwInfoParser.c

diff --git a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
index fa768cf664df..3abc6a0fd274 100644
--- a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
@@ -22,6 +22,13 @@ [Sources]
   FdtHwInfoParser.h
   FdtUtility.c
   FdtUtility.h
+  Pci/ArmPciConfigSpaceParser.c
+  Pci/ArmPciConfigSpaceParser.h
+  Serial/ArmSerialPortParser.c
+  Serial/ArmSerialPortParser.h
+
+[Sources.ARM, Sources.AARCH64]
+  Arm/ArmFdtHwInfoParser.c
   Arm/BootArch/ArmBootArchParser.c
   Arm/BootArch/ArmBootArchParser.h
   Arm/GenericTimer/ArmGenericTimerParser.c
@@ -38,13 +45,11 @@ [Sources]
   Arm/Gic/ArmGicMsiFrameParser.h
   Arm/Gic/ArmGicRParser.c
   Arm/Gic/ArmGicRParser.h
-  Pci/ArmPciConfigSpaceParser.c
-  Pci/ArmPciConfigSpaceParser.h
-  Serial/ArmSerialPortParser.c
-  Serial/ArmSerialPortParser.h
 
-[Packages]
+[Packages.ARM, Packages.AARCH64]
   ArmPkg/ArmPkg.dec
+
+[Packages]
   DynamicTablesPkg/DynamicTablesPkg.dec
   EmbeddedPkg/EmbeddedPkg.dec
   MdeModulePkg/MdeModulePkg.dec
diff --git a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParser.h 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParser.h
index 8a8cf38581e0..f8766236c492 100644
--- a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParser.h
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParser.h
@@ -60,4 +60,31 @@ EFI_STATUS
   ININT32 FdtBranch
   );
 
+/** Main dispatcher: sequentially call the parsers/dispatchers
+of the HwInfoParserTable.
+
+  A parser parses a Device Tree to populate a specific CmObj type. None,
+  one or many CmObj can be created by the parser.
+  The created CmObj are then handed to the parser's caller through the
+  HW_INFO_ADD_OBJECT interface.
+  This can also be a dispatcher. I.e. a function that not parsing a
+  Device Tree but calling other parsers.
+
+  @param [in]  FdtParserHandle A handle to the parser instance.
+  @param [in]  FdtBranch   When searching for DT node name, restrict
+   the search to this Device Tree branch.
+
+  @retval EFI_SUCCESS The function completed successfully.
+  @retval EFI_ABORTED An error occurred.
+  @retval EFI_INVALID_PARAMETER   Invalid parameter.
+  @retval EFI_NOT_FOUND   Not found.
+  @retval EFI_UNSUPPORTED Unsupported.
+**/
+EFI_STATUS
+EFIAPI
+FdtHwInfoMainDispatcher (
+  IN  CONST FDT_HW_INFO_PARSER_HANDLE  FdtParserHandle,
+  ININT32  FdtBranch
+  );
+
 #endif // FDT_HW_INFO_PARSER_H_
diff --git 
a/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtHwInfoParser.c 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtHwInfoParser.c
new file mode 100644
index ..4b1f5eeea423
--- /dev/null
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/ArmFdtHwInfoParser.c
@@ -0,0 +1,83 @@
+/** @file
+  Flattened Device Tree parser library for KvmTool.
+
+  Copyright (c) 2021, ARM Limited. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+**/
+
+#include "FdtHwInfoParser.h"
+#include "Arm/BootArch/ArmBootArchParser.h"
+#include "Arm/GenericTimer/ArmGenericTimerParser.h"
+#include "Arm/Gic/ArmGicDispatcher.h"
+#include "Pci/ArmPciConfigSpaceParser.h"
+#include "Serial/ArmSerialPortParser.h"
+
+/** Ordered table of parsers/dispatchers.
+
+  A parser parses a Device Tree to populate a specific CmObj type. None,
+  one or many CmObj can be created by the parser.
+  The created CmObj are then handed to the parser's caller through the
+  HW_INFO_ADD_OBJECT interface.
+  This can also be a dispatcher. I.e. a function that not parsing a
+  Device Tree but calling other parsers.
+*/
+STATIC CONST FDT_HW_INFO_PARSER_FUNC  HwInfoParserTable[] = {
+  ArmBootArchInfoParser,
+  ArmGenericTimerInfoParser,
+  ArmGicDispatcher,
+  ArmPciConfigInfoParser,
+  SerialPortDispatcher
+};
+
+/** Main dispatcher: sequentially call the parsers/dispatchers
+of the HwInfoParserTable.
+
+  A parser parses a Device Tree to populate a specific CmObj type. None,
+  one or many CmObj can be created by the parser.
+  The created CmObj are then han

[edk2-devel] [RFC PATCH v1 06/20] DynamicTablesPkg: Rename EObjNameSpaceArm to EObjNameSpaceArch

[Sunil V L]

To support other architectures, it is better to use an architecture
neutral name instead of EObjNameSpaceArm. Rename it as EObjNameSpaceArch
and update its consumers.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 .../Include/ConfigurationManagerObject.h  |  4 ++--
 .../KvmtoolCfgMgrDxe/ConfigurationManager.c   |  2 +-
 .../Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c   |  8 +++
 .../Acpi/Arm/AcpiIortLibArm/IortGenerator.c   | 22 +--
 .../Acpi/Arm/AcpiMadtLibArm/MadtGenerator.c   | 10 -
 .../SsdtCmn600Generator.c |  2 +-
 .../Acpi/Common/AcpiDbg2Lib/Dbg2Generator.c   |  2 +-
 .../Acpi/Common/AcpiFadtLib/FadtGenerator.c   |  8 +++
 .../Acpi/Common/AcpiMcfgLib/McfgGenerator.c   |  2 +-
 .../Acpi/Common/AcpiPcctLib/PcctGenerator.c   | 12 +-
 .../Acpi/Common/AcpiPpttLib/PpttGenerator.c   |  8 +++
 .../Acpi/Common/AcpiSpcrLib/SpcrGenerator.c   |  2 +-
 .../Acpi/Common/AcpiSratLib/SratGenerator.c   | 12 +-
 .../SsdtCpuTopologyGenerator.c| 12 +-
 .../AcpiSsdtPcieLib/SsdtPcieGenerator.c   |  8 +++
 .../SsdtSerialPortGenerator.c |  2 +-
 .../DynamicPlatRepoLib/CmObjectTokenFixer.c   |  2 +-
 .../DynamicPlatRepoLib/DynamicPlatRepo.c  |  2 +-
 .../Common/DynamicPlatRepoLib/TokenMapper.c   |  2 +-
 .../ConfigurationManagerObjectParser.c|  2 +-
 20 files changed, 62 insertions(+), 62 deletions(-)

diff --git a/DynamicTablesPkg/Include/ConfigurationManagerObject.h 
b/DynamicTablesPkg/Include/ConfigurationManagerObject.h
index e7f888f12eee..b0254b3ad4e5 100644
--- a/DynamicTablesPkg/Include/ConfigurationManagerObject.h
+++ b/DynamicTablesPkg/Include/ConfigurationManagerObject.h
@@ -106,7 +106,7 @@ typedef UINT32 CM_OBJECT_ID;
 */
 typedef enum ObjectNameSpaceID {
   EObjNameSpaceStandard,  ///< Standard Objects Namespace
-  EObjNameSpaceArm,   ///< ARM Objects Namespace
+  EObjNameSpaceArch,  ///< ARCH Objects Namespace
   EObjNameSpaceOem = 0x8, ///< OEM Objects Namespace
   EObjNameSpaceMax
 } EOBJECT_NAMESPACE_ID;
@@ -180,7 +180,7 @@ typedef struct CmObjDescriptor {
   @retval Returns an ARM Configuration Manager Object ID.
 **/
 #define CREATE_CM_ARCH_OBJECT_ID(ObjectId) \
-  (CREATE_CM_OBJECT_ID (EObjNameSpaceArm, ObjectId))
+  (CREATE_CM_OBJECT_ID (EObjNameSpaceArch, ObjectId))
 
 /** This macro returns a Configuration Manager Object ID
 in the OEM Object Namespace.
diff --git a/ArmVirtPkg/KvmtoolCfgMgrDxe/ConfigurationManager.c 
b/ArmVirtPkg/KvmtoolCfgMgrDxe/ConfigurationManager.c
index 342d068f94fc..ede776fe9a46 100644
--- a/ArmVirtPkg/KvmtoolCfgMgrDxe/ConfigurationManager.c
+++ b/ArmVirtPkg/KvmtoolCfgMgrDxe/ConfigurationManager.c
@@ -929,7 +929,7 @@ ArmKvmtoolPlatformGetObject (
 case EObjNameSpaceStandard:
   Status = GetStandardNameSpaceObject (This, CmObjectId, Token, CmObject);
   break;
-case EObjNameSpaceArm:
+case EObjNameSpaceArch:
   Status = GetArmNameSpaceObject (This, CmObjectId, Token, CmObject);
   break;
 case EObjNameSpaceOem:
diff --git a/DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c 
b/DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c
index a9b9d30d9f73..77c913190f78 100644
--- a/DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c
+++ b/DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/GtdtGenerator.c
@@ -36,7 +36,7 @@
 Timer Information from the Configuration Manager.
 */
 GET_OBJECT_LIST (
-  EObjNameSpaceArm,
+  EObjNameSpaceArch,
   EArchObjGenericTimerInfo,
   CM_ARCH_GENERIC_TIMER_INFO
   );
@@ -45,7 +45,7 @@ GET_OBJECT_LIST (
 Watchdog Timer Information from the Configuration Manager.
 */
 GET_OBJECT_LIST (
-  EObjNameSpaceArm,
+  EObjNameSpaceArch,
   EArchObjPlatformGenericWatchdogInfo,
   CM_ARCH_GENERIC_WATCHDOG_INFO
   );
@@ -54,7 +54,7 @@ GET_OBJECT_LIST (
 Timer Block Information from the Configuration Manager.
 */
 GET_OBJECT_LIST (
-  EObjNameSpaceArm,
+  EObjNameSpaceArch,
   EArchObjPlatformGTBlockInfo,
   CM_ARCH_GTBLOCK_INFO
   );
@@ -63,7 +63,7 @@ GET_OBJECT_LIST (
   Timer Block Timer Frame Information from the Configuration Manager.
 */
 GET_OBJECT_LIST (
-  EObjNameSpaceArm,
+  EObjNameSpaceArch,
   EArchObjGTBlockTimerFrameInfo,
   CM_ARCH_GTBLOCK_TIMER_FRAME_INFO
   );
diff --git a/DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/IortGenerator.c 
b/DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/IortGenerator.c
index 3075b6a137b3..c0c68fcc26da 100644
--- a/DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/IortGenerator.c
+++ b/DynamicTablesPkg/Library/Acpi/Arm/AcpiIortLibArm/IortGenerator.c
@@ -48,7 +48,7 @@
 Group node information from the Configuration Manager.
 */
 GET_OBJECT_LIST (
-  EObjNameSpaceArm,
+  EObjNameSpaceArch,
   EArchObjItsGroup,
   CM_ARCH_ITS_GROUP_NODE
   );
@@ -57,7 +57,7 @@ GET_OBJECT_LIST (
 Named Co

[edk2-devel] [RFC PATCH v1 05/20] DynamicTablesPkg: DynamicPlatRepoLib: Rename ArmObjList as ArchObjList

[Sunil V L]

DynamicPlatRepoLib maintains list of CmObjs and named as ArmObjList.
However, to support other architectures, it is better to name this in a
architecture neutral way.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 .../DynamicPlatRepoLib/DynamicPlatRepoInternal.h   |  4 ++--
 .../Common/DynamicPlatRepoLib/DynamicPlatRepo.c| 14 +++---
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git 
a/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepoInternal.h 
b/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepoInternal.h
index 2b09f2ad882d..cc0acfffecbb 100644
--- 
a/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepoInternal.h
+++ 
b/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepoInternal.h
@@ -60,12 +60,12 @@ typedef struct DynamicPlatformRepositoryInfo {
 
   /// Link lists of CmObj from the ArmNameSpace
   /// that are added in the Transient state.
-  LIST_ENTRY ArmCmObjList[EArchObjMax];
+  LIST_ENTRY ArchCmObjList[EArchObjMax];
 
   /// Structure Members used in Finalized state.
   /// An array of CmObj Descriptors from the ArmNameSpace
   /// This array is populated when the Repo is finalized.
-  CM_OBJ_DESCRIPTOR  ArmCmObjArray[EArchObjMax];
+  CM_OBJ_DESCRIPTOR  ArchCmObjArray[EArchObjMax];
 
   /// A token mapper for the objects in the ArmNamespaceObjectArray
   /// The Token mapper is populated when the Repo is finalized in
diff --git 
a/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepo.c 
b/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepo.c
index ae5c18bb..e095e358dc82 100644
--- a/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepo.c
+++ b/DynamicTablesPkg/Library/Common/DynamicPlatRepoLib/DynamicPlatRepo.c
@@ -174,7 +174,7 @@ DynPlatRepoAddObject (
   }
 
   // Add to link list.
-  InsertTailList (>ArmCmObjList[ArmNamespaceObjId], >Link);
+  InsertTailList (>ArchCmObjList[ArmNamespaceObjId], >Link);
   This->ObjectCount += 1;
 
   if (Token != NULL) {
@@ -223,7 +223,7 @@ GroupCmObjNodes (
   Count= 0;
   Size = 0;
   CmObjId  = CREATE_CM_ARCH_OBJECT_ID (ArchObjIndex);
-  ListHead = >ArmCmObjList[ArchObjIndex];
+  ListHead = >ArchCmObjList[ArchObjIndex];
   Link = GetFirstNode (ListHead);
 
   // Compute the total count and size of the CmObj in the list.
@@ -286,7 +286,7 @@ GroupCmObjNodes (
 Link  = GetNextNode (ListHead, Link);
   } // while
 
-  CmObjDesc   = >ArmCmObjArray[ArchObjIndex];
+  CmObjDesc   = >ArchCmObjArray[ArchObjIndex];
   CmObjDesc->ObjectId = CmObjId;
   CmObjDesc->Size = (UINT32)Size;
   CmObjDesc->Count= (UINT32)Count;
@@ -412,7 +412,7 @@ DynamicPlatRepoGetObject (
 return EFI_INVALID_PARAMETER;
   }
 
-  Desc = >ArmCmObjArray[ArmNamespaceObjId];
+  Desc = >ArchCmObjArray[ArmNamespaceObjId];
 
   // Nothing here.
   if (Desc->Count == 0) {
@@ -459,7 +459,7 @@ DynamicPlatRepoInit (
 
   // Initialise the CmObject List.
   for (Index = 0; Index < EArchObjMax; Index++) {
-InitializeListHead (>ArmCmObjList[Index]);
+InitializeListHead (>ArchCmObjList[Index]);
   }
 
   Repo->ObjectCount = 0;
@@ -499,14 +499,14 @@ DynamicPlatRepoShutdown (
   // Free the list of objects.
   for (Index = 0; Index < EArchObjMax; Index++) {
 // Free all the nodes with this object Id.
-ListHead = >ArmCmObjList[Index];
+ListHead = >ArchCmObjList[Index];
 while (!IsListEmpty (ListHead)) {
   FreeCmObjNode ((CM_OBJ_NODE *)GetFirstNode (ListHead));
 } // while
   } // for
 
   // Free the arrays.
-  CmObjDesc = DynPlatRepo->ArmCmObjArray;
+  CmObjDesc = DynPlatRepo->ArchCmObjArray;
   for (Index = 0; Index < EArchObjMax; Index++) {
 Data = CmObjDesc[Index].Data;
 if (Data != NULL) {
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113467): https://edk2.groups.io/g/devel/message/113467
Mute This Topic: https://groups.io/mt/103622715/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [RFC PATCH v1 03/20] DynamicTablesPkg: Update ACPI common libraries BASE_NAME

[Sunil V L]

Update the BASE_NAME in the libraries moved out of ARM.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 .../Acpi/Common/AcpiDbg2Lib/AcpiDbg2Lib.inf   | 15 +++
 .../Acpi/Common/AcpiFadtLib/AcpiFadtLib.inf   |  9 +
 .../Acpi/Common/AcpiMcfgLib/AcpiMcfgLib.inf   |  9 +
 .../Acpi/Common/AcpiPcctLib/AcpiPcctLib.inf   |  2 +-
 .../Acpi/Common/AcpiPpttLib/AcpiPpttLib.inf   |  2 +-
 .../Library/Acpi/Common/AcpiRawLib/AcpiRawLib.inf |  9 +
 .../Acpi/Common/AcpiSpcrLib/AcpiSpcrLib.inf   |  9 +
 .../Acpi/Common/AcpiSratLib/AcpiSratLib.inf   |  2 +-
 .../AcpiSsdtCpuTopologyLib/SsdtCpuTopologyLib.inf |  6 --
 .../Acpi/Common/AcpiSsdtPcieLib/SsdtPcieLib.inf   |  2 +-
 .../AcpiSsdtSerialPortLib/SsdtSerialPortLib.inf   |  6 --
 11 files changed, 23 insertions(+), 48 deletions(-)

diff --git a/DynamicTablesPkg/Library/Acpi/Common/AcpiDbg2Lib/AcpiDbg2Lib.inf 
b/DynamicTablesPkg/Library/Acpi/Common/AcpiDbg2Lib/AcpiDbg2Lib.inf
index f7b7c1c025a6..32dcd20c082b 100644
--- a/DynamicTablesPkg/Library/Acpi/Common/AcpiDbg2Lib/AcpiDbg2Lib.inf
+++ b/DynamicTablesPkg/Library/Acpi/Common/AcpiDbg2Lib/AcpiDbg2Lib.inf
@@ -8,7 +8,7 @@
 
 [Defines]
   INF_VERSION= 0x00010019
-  BASE_NAME  = AcpiDbg2LibArm
+  BASE_NAME  = AcpiDbg2Lib
   FILE_GUID  = A17BA4F0-3DEB-4FE5-BD27-EC008E541B22
   VERSION_STRING = 1.0
   MODULE_TYPE= DXE_DRIVER
@@ -19,16 +19,20 @@ [Defines]
 [Sources]
   Dbg2Generator.c
 
+[Packages.ARM, Packages.AARCH64]
+  ArmPlatformPkg/ArmPlatformPkg.dec
+
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
   EmbeddedPkg/EmbeddedPkg.dec
-  ArmPlatformPkg/ArmPlatformPkg.dec
   DynamicTablesPkg/DynamicTablesPkg.dec
 
+[LibraryClasses.ARM, LibraryClasses.AARCH64]
+  PL011UartLib
+
 [LibraryClasses]
   BaseLib
-  PL011UartLib
   SsdtSerialPortFixupLib
 
 [FixedPcd]
@@ -36,8 +40,3 @@ [FixedPcd]
   gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits
   gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity
   gEfiMdePkgTokenSpaceGuid.PcdUartDefaultStopBits
-
-[Protocols]
-
-[Guids]
-
diff --git a/DynamicTablesPkg/Library/Acpi/Common/AcpiFadtLib/AcpiFadtLib.inf 
b/DynamicTablesPkg/Library/Acpi/Common/AcpiFadtLib/AcpiFadtLib.inf
index 8fe34013d420..c9cd850faac0 100644
--- a/DynamicTablesPkg/Library/Acpi/Common/AcpiFadtLib/AcpiFadtLib.inf
+++ b/DynamicTablesPkg/Library/Acpi/Common/AcpiFadtLib/AcpiFadtLib.inf
@@ -8,7 +8,7 @@
 
 [Defines]
   INF_VERSION= 0x00010019
-  BASE_NAME  = AcpiFadtLibArm
+  BASE_NAME  = AcpiFadtLib
   FILE_GUID  = 686FE5FE-B944-485F-8B1C-7D60E0056487
   VERSION_STRING = 1.0
   MODULE_TYPE= DXE_DRIVER
@@ -27,10 +27,3 @@ [Packages]
 
 [LibraryClasses]
   BaseLib
-
-[Pcd]
-
-[Protocols]
-
-[Guids]
-
diff --git a/DynamicTablesPkg/Library/Acpi/Common/AcpiMcfgLib/AcpiMcfgLib.inf 
b/DynamicTablesPkg/Library/Acpi/Common/AcpiMcfgLib/AcpiMcfgLib.inf
index 1c7f085274e6..36c343d3875a 100644
--- a/DynamicTablesPkg/Library/Acpi/Common/AcpiMcfgLib/AcpiMcfgLib.inf
+++ b/DynamicTablesPkg/Library/Acpi/Common/AcpiMcfgLib/AcpiMcfgLib.inf
@@ -8,7 +8,7 @@
 
 [Defines]
   INF_VERSION= 0x00010019
-  BASE_NAME  = AcpiMcfgLibArm
+  BASE_NAME  = AcpiMcfgLib
   FILE_GUID  = 8C9BDCB2-72D4-4F30-A12D-1145C3807FF7
   VERSION_STRING = 1.0
   MODULE_TYPE= DXE_DRIVER
@@ -27,10 +27,3 @@ [Packages]
 
 [LibraryClasses]
   BaseLib
-
-[Pcd]
-
-[Protocols]
-
-[Guids]
-
diff --git a/DynamicTablesPkg/Library/Acpi/Common/AcpiPcctLib/AcpiPcctLib.inf 
b/DynamicTablesPkg/Library/Acpi/Common/AcpiPcctLib/AcpiPcctLib.inf
index da54585c2dd9..666bdcab2225 100644
--- a/DynamicTablesPkg/Library/Acpi/Common/AcpiPcctLib/AcpiPcctLib.inf
+++ b/DynamicTablesPkg/Library/Acpi/Common/AcpiPcctLib/AcpiPcctLib.inf
@@ -8,7 +8,7 @@
 
 [Defines]
   INF_VERSION= 0x0001001B
-  BASE_NAME  = AcpiPcctLibArm
+  BASE_NAME  = AcpiPcctLib
   FILE_GUID  = 38FE945C-D6ED-4CD6-8D20-FCEF3260D15A
   VERSION_STRING = 1.0
   MODULE_TYPE= DXE_DRIVER
diff --git a/DynamicTablesPkg/Library/Acpi/Common/AcpiPpttLib/AcpiPpttLib.inf 
b/DynamicTablesPkg/Library/Acpi/Common/AcpiPpttLib/AcpiPpttLib.inf
index 2c7d19513d6c..a1c91a6eab74 100644
--- a/DynamicTablesPkg/Library/Acpi/Common/AcpiPpttLib/AcpiPpttLib.inf
+++ b/DynamicTablesPkg/Library/Acpi/Common/AcpiPpttLib/AcpiPpttLib.inf
@@ -8,7 +8,7 @@
 
 [Defines]
   INF_VERSION= 0x0001001B
-  BASE_NAME  = AcpiPpttLibArm
+  BASE_NAME  = AcpiPpttLib
   FILE_GUID  = FA102D52-5A92-4F95-A097-1D53F9CF5959
   VERSION_STRING = 1.0
   MODULE_TYPE= DXE_DRIVER
diff --git a/DynamicTablesPkg/Library/Acpi/Common/AcpiRawLib/AcpiRawLib.inf 
b/DynamicTablesPkg/Library/Acpi/Common/AcpiRawLib/AcpiRawLib.inf
index f2ab1b7111fb..8b461ea05b86 100644
--- a/DynamicTablesPkg/Library/Acpi/Common/AcpiRawLib/AcpiRawLib.inf
+++ b/DynamicTablesPkg/Library/Acpi/Common/AcpiRawLib/AcpiRawLib.inf
@@ -8,7 +8,7 @@
 
 [Defines]
   INF_VERSION= 0x00010019

[edk2-devel] [RFC PATCH v1 02/20] DynamicTablesPkg: Move common ACPI libraries from folder

[Sunil V L]

Several ACPI tables are common across architectures. Move below common
ACPI table generator libraries which are common for architectures out of
Arm folder so that they can be used by other architectures like RISC-V.

Common tables are: DBG2, FADT, MCFG, PCCT, PPTT, SPCR, SRAT, SSDT (CPU,
PCIe)

Arm specific are: MADT, GTDT, IORT

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 DynamicTablesPkg/DynamicTables.dsc.inc| 45 +--
 .../AcpiDbg2Lib/AcpiDbg2Lib.inf}  |  0
 .../AcpiFadtLib/AcpiFadtLib.inf}  |  0
 .../AcpiMcfgLib/AcpiMcfgLib.inf}  |  0
 .../AcpiPcctLib/AcpiPcctLib.inf}  |  0
 .../AcpiPpttLib/AcpiPpttLib.inf}  |  0
 .../AcpiRawLib/AcpiRawLib.inf}|  0
 .../AcpiSpcrLib/AcpiSpcrLib.inf}  |  0
 .../AcpiSratLib/AcpiSratLib.inf}  |  0
 .../SsdtCpuTopologyLib.inf}   |  0
 .../AcpiSsdtPcieLib/SsdtPcieLib.inf}  |  0
 .../SsdtSerialPortLib.inf}|  0
 .../AcpiPcctLib}/PcctGenerator.h  |  0
 .../AcpiPpttLib}/PpttGenerator.h  |  0
 .../SsdtCpuTopologyGenerator.h|  0
 .../AcpiSsdtPcieLib}/SsdtPcieGenerator.h  |  0
 .../AcpiDbg2Lib}/Dbg2Generator.c  |  0
 .../AcpiFadtLib}/FadtGenerator.c  |  0
 .../AcpiMcfgLib}/McfgGenerator.c  |  0
 .../AcpiPcctLib}/PcctGenerator.c  |  0
 .../AcpiPpttLib}/PpttGenerator.c  |  0
 .../AcpiRawLib}/RawGenerator.c|  0
 .../AcpiSpcrLib}/SpcrGenerator.c  |  0
 .../AcpiSratLib}/SratGenerator.c  |  0
 .../SsdtCpuTopologyGenerator.c|  0
 .../AcpiSsdtPcieLib}/SsdtPcieGenerator.c  |  0
 .../SsdtSerialPortGenerator.c |  0
 27 files changed, 22 insertions(+), 23 deletions(-)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiDbg2LibArm/AcpiDbg2LibArm.inf => 
Common/AcpiDbg2Lib/AcpiDbg2Lib.inf} (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiFadtLibArm/AcpiFadtLibArm.inf => 
Common/AcpiFadtLib/AcpiFadtLib.inf} (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiMcfgLibArm/AcpiMcfgLibArm.inf => 
Common/AcpiMcfgLib/AcpiMcfgLib.inf} (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiPcctLibArm/AcpiPcctLibArm.inf => 
Common/AcpiPcctLib/AcpiPcctLib.inf} (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiPpttLibArm/AcpiPpttLibArm.inf => 
Common/AcpiPpttLib/AcpiPpttLib.inf} (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiRawLibArm/AcpiRawLibArm.inf => 
Common/AcpiRawLib/AcpiRawLib.inf} (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiSpcrLibArm/AcpiSpcrLibArm.inf => 
Common/AcpiSpcrLib/AcpiSpcrLib.inf} (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiSratLibArm/AcpiSratLibArm.inf => 
Common/AcpiSratLib/AcpiSratLib.inf} (100%)
 rename 
DynamicTablesPkg/Library/Acpi/{Arm/AcpiSsdtCpuTopologyLibArm/SsdtCpuTopologyLibArm.inf
 => Common/AcpiSsdtCpuTopologyLib/SsdtCpuTopologyLib.inf} (100%)
 rename 
DynamicTablesPkg/Library/Acpi/{Arm/AcpiSsdtPcieLibArm/SsdtPcieLibArm.inf => 
Common/AcpiSsdtPcieLib/SsdtPcieLib.inf} (100%)
 rename 
DynamicTablesPkg/Library/Acpi/{Arm/AcpiSsdtSerialPortLibArm/SsdtSerialPortLibArm.inf
 => Common/AcpiSsdtSerialPortLib/SsdtSerialPortLib.inf} (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiPcctLibArm => 
Common/AcpiPcctLib}/PcctGenerator.h (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiPpttLibArm => 
Common/AcpiPpttLib}/PpttGenerator.h (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiSsdtCpuTopologyLibArm => 
Common/AcpiSsdtCpuTopologyLib}/SsdtCpuTopologyGenerator.h (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiSsdtPcieLibArm => 
Common/AcpiSsdtPcieLib}/SsdtPcieGenerator.h (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiDbg2LibArm => 
Common/AcpiDbg2Lib}/Dbg2Generator.c (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiFadtLibArm => 
Common/AcpiFadtLib}/FadtGenerator.c (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiMcfgLibArm => 
Common/AcpiMcfgLib}/McfgGenerator.c (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiPcctLibArm => 
Common/AcpiPcctLib}/PcctGenerator.c (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiPpttLibArm => 
Common/AcpiPpttLib}/PpttGenerator.c (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiRawLibArm => 
Common/AcpiRawLib}/RawGenerator.c (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiSpcrLibArm => 
Common/AcpiSpcrLib}/SpcrGenerator.c (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiSratLibArm => 
Common/AcpiSratLib}/SratGenerator.c (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiSsdtCpuTopologyLibArm => 
Common/AcpiSsdtCpuTopologyLib}/SsdtCpuTopologyGenerator.c (100%)
 rename DynamicTablesPkg/Library/Acpi/{Arm/AcpiSsdtPcieLibArm => 
Common/AcpiSsdtPcieLib}/SsdtPcieGenerator.c (100%)
 re

[edk2-devel] [RFC PATCH v1 01/20] DynamicTablesPkg: FdtHwInfoParserLib: Move ARM parsers to Arm directory

[Sunil V L]

GIC, GenericTimer and BootArch are ARM specific concepts. Move them to
Arm folder and update the references.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Signed-off-by: Sunil V L 
---
 .../FdtHwInfoParserLib/FdtHwInfoParserLib.inf | 32 +--
 .../{ => Arm}/BootArch/ArmBootArchParser.h|  0
 .../GenericTimer/ArmGenericTimerParser.h  |  0
 .../{ => Arm}/Gic/ArmGicCParser.h |  0
 .../{ => Arm}/Gic/ArmGicDParser.h |  0
 .../{ => Arm}/Gic/ArmGicDispatcher.h  |  0
 .../{ => Arm}/Gic/ArmGicItsParser.h   |  0
 .../{ => Arm}/Gic/ArmGicMsiFrameParser.h  |  0
 .../{ => Arm}/Gic/ArmGicRParser.h |  0
 .../{ => Arm}/BootArch/ArmBootArchParser.c|  2 +-
 .../GenericTimer/ArmGenericTimerParser.c  |  4 +--
 .../{ => Arm}/Gic/ArmGicCParser.c |  4 +--
 .../{ => Arm}/Gic/ArmGicDParser.c |  4 +--
 .../{ => Arm}/Gic/ArmGicDispatcher.c  | 12 +++
 .../{ => Arm}/Gic/ArmGicItsParser.c   |  4 +--
 .../{ => Arm}/Gic/ArmGicMsiFrameParser.c  |  4 +--
 .../{ => Arm}/Gic/ArmGicRParser.c |  4 +--
 .../FdtHwInfoParserLib/FdtHwInfoParser.c  |  6 ++--
 .../Pci/ArmPciConfigSpaceParser.c |  2 +-
 19 files changed, 39 insertions(+), 39 deletions(-)
 rename DynamicTablesPkg/Library/FdtHwInfoParserLib/{ => 
Arm}/BootArch/ArmBootArchParser.h (100%)
 rename DynamicTablesPkg/Library/FdtHwInfoParserLib/{ => 
Arm}/GenericTimer/ArmGenericTimerParser.h (100%)
 rename DynamicTablesPkg/Library/FdtHwInfoParserLib/{ => 
Arm}/Gic/ArmGicCParser.h (100%)
 rename DynamicTablesPkg/Library/FdtHwInfoParserLib/{ => 
Arm}/Gic/ArmGicDParser.h (100%)
 rename DynamicTablesPkg/Library/FdtHwInfoParserLib/{ => 
Arm}/Gic/ArmGicDispatcher.h (100%)
 rename DynamicTablesPkg/Library/FdtHwInfoParserLib/{ => 
Arm}/Gic/ArmGicItsParser.h (100%)
 rename DynamicTablesPkg/Library/FdtHwInfoParserLib/{ => 
Arm}/Gic/ArmGicMsiFrameParser.h (100%)
 rename DynamicTablesPkg/Library/FdtHwInfoParserLib/{ => 
Arm}/Gic/ArmGicRParser.h (100%)
 rename DynamicTablesPkg/Library/FdtHwInfoParserLib/{ => 
Arm}/BootArch/ArmBootArchParser.c (95%)
 rename DynamicTablesPkg/Library/FdtHwInfoParserLib/{ => 
Arm}/GenericTimer/ArmGenericTimerParser.c (95%)
 rename DynamicTablesPkg/Library/FdtHwInfoParserLib/{ => 
Arm}/Gic/ArmGicCParser.c (96%)
 rename DynamicTablesPkg/Library/FdtHwInfoParserLib/{ => 
Arm}/Gic/ArmGicDParser.c (95%)
 rename DynamicTablesPkg/Library/FdtHwInfoParserLib/{ => 
Arm}/Gic/ArmGicDispatcher.c (92%)
 rename DynamicTablesPkg/Library/FdtHwInfoParserLib/{ => 
Arm}/Gic/ArmGicItsParser.c (95%)
 rename DynamicTablesPkg/Library/FdtHwInfoParserLib/{ => 
Arm}/Gic/ArmGicMsiFrameParser.c (95%)
 rename DynamicTablesPkg/Library/FdtHwInfoParserLib/{ => 
Arm}/Gic/ArmGicRParser.c (95%)

diff --git a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
index d2c171accaa5..fa768cf664df 100644
--- a/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
+++ b/DynamicTablesPkg/Library/FdtHwInfoParserLib/FdtHwInfoParserLib.inf
@@ -22,22 +22,22 @@ [Sources]
   FdtHwInfoParser.h
   FdtUtility.c
   FdtUtility.h
-  BootArch/ArmBootArchParser.c
-  BootArch/ArmBootArchParser.h
-  GenericTimer/ArmGenericTimerParser.c
-  GenericTimer/ArmGenericTimerParser.h
-  Gic/ArmGicCParser.c
-  Gic/ArmGicCParser.h
-  Gic/ArmGicDispatcher.c
-  Gic/ArmGicDispatcher.h
-  Gic/ArmGicDParser.c
-  Gic/ArmGicDParser.h
-  Gic/ArmGicItsParser.c
-  Gic/ArmGicItsParser.h
-  Gic/ArmGicMsiFrameParser.c
-  Gic/ArmGicMsiFrameParser.h
-  Gic/ArmGicRParser.c
-  Gic/ArmGicRParser.h
+  Arm/BootArch/ArmBootArchParser.c
+  Arm/BootArch/ArmBootArchParser.h
+  Arm/GenericTimer/ArmGenericTimerParser.c
+  Arm/GenericTimer/ArmGenericTimerParser.h
+  Arm/Gic/ArmGicCParser.c
+  Arm/Gic/ArmGicCParser.h
+  Arm/Gic/ArmGicDispatcher.c
+  Arm/Gic/ArmGicDispatcher.h
+  Arm/Gic/ArmGicDParser.c
+  Arm/Gic/ArmGicDParser.h
+  Arm/Gic/ArmGicItsParser.c
+  Arm/Gic/ArmGicItsParser.h
+  Arm/Gic/ArmGicMsiFrameParser.c
+  Arm/Gic/ArmGicMsiFrameParser.h
+  Arm/Gic/ArmGicRParser.c
+  Arm/Gic/ArmGicRParser.h
   Pci/ArmPciConfigSpaceParser.c
   Pci/ArmPciConfigSpaceParser.h
   Serial/ArmSerialPortParser.c
diff --git 
a/DynamicTablesPkg/Library/FdtHwInfoParserLib/BootArch/ArmBootArchParser.h 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/BootArch/ArmBootArchParser.h
similarity index 100%
rename from 
DynamicTablesPkg/Library/FdtHwInfoParserLib/BootArch/ArmBootArchParser.h
rename to 
DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/BootArch/ArmBootArchParser.h
diff --git 
a/DynamicTablesPkg/Library/FdtHwInfoParserLib/GenericTimer/ArmGenericTimerParser.h
 
b/DynamicTablesPkg/Library/FdtHwInfoParserLib/Arm/GenericTimer/ArmGenericTimerParser.h
similarity index 100%
rename from 
DynamicTablesPkg/Library/F

[edk2-devel] [RFC PATCH v1 00/20] DynamicTablesPkg: Prepare to add RISC-V support

[Sunil V L]

DynamicTablesPkg can be used by RISC-V platforms to generate ACPI tables
from FDT passed from previous stage FW. However, DynamicTablesPkg
currently is ARM specific even though several parsers and ACPI
generators can be used across architectures. For ex: SSDT (PCIe), SSDT
(CPU), MCFG, SPCR, DBG2, FADT, SRAT, Raw (DSDT) are mostly common across
architectures. Only MADT, IORT and GTDT are ARM specific.

This series tries to refactor the DynamicTablesPkg so that RISC-V
support can be added fairly easily later.

While the approach taken in this series reduces the code duplication as
much as possible, it has the side effect of large changes and impacts
platforms that support DynamicTablesPkg today (ex: JunoPkg,
ArmKvmTool etc). Other approach I tried initially was to duplicate most
of the things from Arm to RISC-V. But it was too much of
code duplication which is bad in my opinion.

To help the review, the series is also available at
https://github.com/vlsunil/edk2/tree/dyn_tables_refactor_rfc_v1

Corresponding changes in edk2-platforms are at
https://github.com/vlsunil/edk2-platforms/tree/dyn_tables_approach2_v1

I have built tested the changes for following platforms enabling
DYNAMIC_TABLES_FRAMEWORK.
  - ArmJuno.dsc
  - ArmVExpress-FVP-AArch64.dsc 
  - ArmVirtKvmTool.dsc

But due to the nature of the changes, if the approach is fine, I will
need some help to test those platforms which support DynamicTables.

The series passes CI tests.

Looking forward for your feedback!. I am happy to try if there are any
better methods to add support for other architectures.

Addition of RISC-V support PoC code (on top of this series) is available
at 
https://github.com/vlsunil/edk2/tree/dyn_tables_riscv_rfc_v1

PS: PoC code for the code duplication approach is available at
https://github.com/vlsunil/edk2/commits/dyn_tables_approch1_v1/.
This was just quick work. It has the advantage of lesser impact on
existing ARM platforms. But looks too bad to me because of code
duplication.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pierre Gondois 
Cc: Sami Mujawar 
Cc: Andrei Warkentin 
Cc: Laszlo Ersek 
Cc: AbdulLateef Attar (Abdul Lateef) 
Cc: Jeff Brasen 

Sunil V L (20):
  DynamicTablesPkg: FdtHwInfoParserLib: Move ARM parsers to Arm
directory
  DynamicTablesPkg: Move common ACPI libraries from folder
  DynamicTablesPkg: Update ACPI common libraries BASE_NAME
  DynamicTablesPkg: Rename ArmNameSpaceObjects to ArchNameSpaceObjects
  DynamicTablesPkg: DynamicPlatRepoLib: Rename ArmObjList as ArchObjList
  DynamicTablesPkg: Rename EObjNameSpaceArm to EObjNameSpaceArch
  DynamicTablesPkg: FdtHwInfoParserLib: Separate ARM specific code
  DynamicTablesPkg: FdtHwInfoParserLib: Pci: Make it common for
architectures
  DynamicTablesPkg: FdtHwInfoParserLib: Make Serial parser arch neutral
  DynamicTablesPkg: FdtHwInfoParserLib: Move ArmLib.h to ArmGicCParser.c
  DynamicTablesPkg: TableHelperLib: Populate OemTableId using
ConfigManager
  DynamicTablesPkg: Add CreatorId in
CM_STD_OBJ_CONFIGURATION_MANAGER_INFO
  DynamicTablesPkg: FdtHwInfoParserLib: Move ARM utilities to separate
file
  DynamicTablesPkg/FdtHwInfoParserLib: Add function for INTC address
cells
  DynamicTablesPkg: AcpiSsdtCpuTopologyLib: Move GICC from common code
  DynamicTablesPkg: AcpiFadtLib: Move ArmBootArch to ARM specific file
  DynamicTablesPkg: DynamicTableManagerDxe: Refactor to allow other
archs
  DynamicTablesPkg: X86: Add interfaces to succeed CI tests
  DynamicTablesPkg/AmlLib: Fix typo
  DynamicTablesPkg.ci.yaml: Update exception and ignore list

 DynamicTablesPkg/DynamicTables.dsc.inc|  45 +-
 .../DynamicTableManagerDxe.inf|   9 +-
 .../AcpiDbg2Lib/AcpiDbg2Lib.inf}  |  15 +-
 .../AcpiFadtLib/AcpiFadtLib.inf}  |  13 +-
 .../AcpiMcfgLib/AcpiMcfgLib.inf}  |   9 +-
 .../AcpiPcctLib/AcpiPcctLib.inf}  |   2 +-
 .../AcpiPpttLib/AcpiPpttLib.inf}  |   2 +-
 .../AcpiRawLib/AcpiRawLib.inf}|   9 +-
 .../AcpiSpcrLib/AcpiSpcrLib.inf}  |   9 +-
 .../AcpiSratLib/AcpiSratLib.inf}  |   2 +-
 .../SsdtCpuTopologyLib.inf}   |   9 +-
 .../AcpiSsdtPcieLib/SsdtPcieLib.inf}  |   2 +-
 .../SsdtSerialPortLib.inf}|   6 +-
 .../FdtHwInfoParserLib/FdtHwInfoParserLib.inf |  48 +-
 .../KvmtoolCfgMgrDxe/ConfigurationManager.h   |  10 +-
 .../DynamicTableManagerDxe.h  |  65 +++
 ...eSpaceObjects.h => ArchNameSpaceObjects.h} | 428 
 .../Include/ConfigurationManagerObject.h  |   8 +-
 .../Include/Library/AmlLib/AmlLib.h   |   1 +
 .../Include/Library/SsdtPcieSupportLib.h  |  12 +-
 .../Include/Library/SsdtSerialPortFixupLib.h  |   8 +-
 .../Include/StandardNameSpaceObjects.h|   1 +
 .../Acpi/Common/AcpiFadtLib/FadtGenerator.h   |  32 ++
 .../AcpiPcctLib}/PcctGenerator.h  |   4 +-
 .../AcpiPpttLib}/PpttGenerator.h  | 

Re: [edk2-devel] [PATCH v4 1/3] OvmfPkg/RiscVVirt: use gEfiAuthenticatedVariableGuid unconditionally

[Sunil V L]

On Mon, Jan 08, 2024 at 08:21:21PM +0100, Gerd Hoffmann wrote:
> ArmVirt and OVMF are doing the same.
> 
> See commit d92eaabefbe0 ("OvmfPkg: simplify VARIABLE_STORE_HEADER
> generation") for details.
> 
> Suggested-by: László Érsek 
> Signed-off-by: Gerd Hoffmann 
> ---
Thanks!, Gerd. Looks good to me.

Reviewed-by: Sunil V L 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113425): https://edk2.groups.io/g/devel/message/113425
Mute This Topic: https://groups.io/mt/103605055/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v10 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Sunil V L]

On Mon, Jan 08, 2024 at 09:53:46PM +, Pedro Falcato wrote:
> On Mon, Jan 8, 2024 at 4:23 PM Dhaval Sharma  wrote:
> >
> > Hi yangcheng/Pedro,
> 
> +CC a bunch of relevant people
> 
> Hi, (FYI you did not CC me)
> 
> Looking at yangcheng's example:
> 
>   Status = PrepareDmaData (gpIdmacDesc, Length, Buffer); <-- We write
> to the IDMAC desc
>   if (EFI_ERROR (Status)) {
> goto out;
>   }
> 
>   WriteBackDataCacheRange (gpIdmacDesc, DescPages * EFI_PAGE_SIZE);
> <-- Make sure it's DMA-coherent
>   StartDma (Length); <-- We've flushed the cache, everything is now in
> DRAM and DMA-coherent, start DMA
> 
> which screams of "bad abstractions" because you don't actually need to
> write data back, if the device and platform are DMA coherent.
> 
> So what we want here really depends. My local "Volume I: RISC-V
> Unprivileged ISA V20191213" says, section A.5:
> 
> "Table A.5 provides a mapping of Linux memory ordering macros onto
> RISC-V memory instructions.
> The Linux fences dma rmb() and dma wmb() map onto FENCE R,R and FENCE
> W,W, respectively,
> since the RISC-V Unix Platform requires coherent DMA, but would be
> mapped onto FENCE RI,RI
> and FENCE WO,WO, respectively, on a platform with non-coherent DMA.
> Platforms with non-
> coherent DMA may also require a mechanism by which cache lines can be
> flushed and/or invalidated.
> Such mechanisms will be device-specific and/or standardized in a
> future extension to the ISA."
> 
> The (current date) RISCV Platform Spec also says: "Memory accesses by
> I/O masters can be coherent or non-coherent with respect to all
> hart-related caches."
> which is brilliantly useless.
> 
> so I think the best solution here is to:
> 
> 1) Add a new PCD for platform DMA coherency, and test that on
> WriteBackDataCacheRange's ASSERT (if (!Coherent) ASSERT() else
> return;)
> 2) Add a more abstracting API that doesn't necessarily map to
> WriteBackDataCache when all we wanted was to assert DMA coherency
> 
> but, alas, I've seen a lot less funky platforms than many of you, and
> DMA/cache-coherency is not really my thing, so I'll defer to others..
> 
My preference is just remove the assertion and add the debug verbose
message instead of changing drivers/introduce new interfaces. It is a
nop in linux as well if CMO is not present.

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113422): https://edk2.groups.io/g/devel/message/113422
Mute This Topic: https://groups.io/mt/103150435/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 4/4] OvmfPkg/RiscVVirt: Override Sstc extension

[Sunil V L]

Override Sstc extension and use SBI calls itself by default for RISC-V
qemu virt platform.

Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Laszlo Ersek 
Signed-off-by: Sunil V L 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc 
b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
index d3624e899e8d..6bc7c90f31dc 100644
--- a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
+++ b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
@@ -203,7 +203,7 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
 
 [PcdsFixedAtBuild.common]
-  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0xFFFE
+  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0xFFFC
   gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|100
   gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength|100
   gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength|0
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113385): https://edk2.groups.io/g/devel/message/113385
Mute This Topic: https://groups.io/mt/103595212/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 3/4] UefiCpuPkg/CpuTimerDxeRiscV64: Add support for Sstc

[Sunil V L]

Sstc extension allows to program the timer and receive the interrupt
without using an SBI call. This reduces the latency to generate the timer
interrupt. So, detect whether Sstc extension is supported and use the
stimecmp register directly to program the timer interrupt.

Cc: Gerd Hoffmann 
Cc: Rahul Kumar 
Cc: Laszlo Ersek 
Cc: Ray Ni 
Cc: Andrei Warkentin 
Signed-off-by: Sunil V L 
---
 .../CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf |  1 +
 UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h |  2 +
 UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c | 49 +--
 3 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf 
b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
index aba660186dc0..f2a2cf12caef 100644
--- a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
+++ b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
@@ -41,6 +41,7 @@ [Sources.RISCV64]
   Timer.c
 
 [Pcd]
+  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride   ## CONSUMES
   gUefiCpuPkgTokenSpaceGuid.PcdCpuCoreCrystalClockFrequency  ## CONSUMES
 
 [Protocols]
diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h 
b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
index 9b3542230cb5..067bbd29f377 100644
--- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
+++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
@@ -26,6 +26,8 @@
 //
 #define DEFAULT_TIMER_TICK_DURATION  10
 
+#define RISCV_CPU_FEATURE_SSTC_BITMASK  BIT1
+
 extern VOID
 RiscvSetTimerPeriod (
   UINT32  TimerPeriod
diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c 
b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
index 30e48061cd06..216f48a52931 100644
--- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
+++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
@@ -44,6 +44,45 @@ STATIC EFI_TIMER_NOTIFY  mTimerNotifyFunction;
 STATIC UINT64  mTimerPeriod = 0;
 STATIC UINT64  mLastPeriodStart = 0;
 
+//
+// Sstc support
+//
+STATIC BOOLEAN  mSstcEnabled = FALSE;
+
+/**
+  Program the timer.
+
+  Program either using stimecmp (when Sstc extension is enabled) or using SBI
+  TIME call.
+
+  @param NextValue Core tick value the timer should expire.
+**/
+STATIC
+VOID
+RiscVProgramTimer (
+  UINT64  NextValue
+  )
+{
+  if (mSstcEnabled) {
+RiscVSetSupervisorTimeCompareRegister (NextValue);
+  } else {
+SbiSetTimer (NextValue);
+  }
+}
+
+/**
+  Check whether Sstc is enabled in PCD.
+
+**/
+STATIC
+BOOLEAN
+RiscVIsSstcEnabled (
+  VOID
+  )
+{
+  return ((PcdGet64 (PcdRiscVFeatureOverride) & 
RISCV_CPU_FEATURE_SSTC_BITMASK) != 0);
+}
+
 /**
   Timer Interrupt Handler.
 
@@ -94,7 +133,7 @@ TimerInterruptHandler (
  ),
100u
);  // convert to tick
-  SbiSetTimer (PeriodStart);
+  RiscVProgramTimer (PeriodStart);
   RiscVEnableTimerInterrupt (); // enable SMode timer int
   gBS->RestoreTPL (OriginalTPL);
 }
@@ -197,8 +236,7 @@ TimerDriverSetTimerPeriod (
  ),
100u
); // convert to tick
-  SbiSetTimer (PeriodStart);
-
+  RiscVProgramTimer (PeriodStart);
   mCpu->EnableInterrupt (mCpu);
   RiscVEnableTimerInterrupt (); // enable SMode timer int
   return EFI_SUCCESS;
@@ -282,6 +320,11 @@ TimerDriverInitialize (
   //
   mTimerNotifyFunction = NULL;
 
+  if (RiscVIsSstcEnabled ()) {
+mSstcEnabled = TRUE;
+DEBUG ((DEBUG_INFO, "TimerDriverInitialize: Timer interrupt is via Sstc 
extension\n"));
+  }
+
   //
   // Make sure the Timer Architectural Protocol is not already installed in 
the system
   //
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113384): https://edk2.groups.io/g/devel/message/113384
Mute This Topic: https://groups.io/mt/103595210/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 2/4] MdePkg/BaseLib: RISC-V: Add function to update stimecmp register

[Sunil V L]

stimecmp is a CSR supported only when Sstc extension is supported by the
platform. This register can be used to set the timer interrupt directly in
S-mode instead of going via SBI call. Add a function to update this
register.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Andrei Warkentin 
Signed-off-by: Sunil V L 
---
 MdePkg/Include/Library/BaseLib.h| 5 +
 MdePkg/Include/Register/RiscV64/RiscVEncoding.h | 3 +++
 MdePkg/Library/BaseLib/RiscV64/ReadTimer.S  | 7 +++
 3 files changed, 15 insertions(+)

diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index b71e47f41b7f..ca0d06c7f335 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -191,6 +191,11 @@ RiscVReadTimer (
   VOID
   );
 
+VOID
+RiscVSetSupervisorTimeCompareRegister (
+  IN UINT64
+  );
+
 VOID
 RiscVEnableTimerInterrupt (
   VOID
diff --git a/MdePkg/Include/Register/RiscV64/RiscVEncoding.h 
b/MdePkg/Include/Register/RiscV64/RiscVEncoding.h
index 2bde8db478ff..8ccdea2f4fcd 100644
--- a/MdePkg/Include/Register/RiscV64/RiscVEncoding.h
+++ b/MdePkg/Include/Register/RiscV64/RiscVEncoding.h
@@ -96,6 +96,9 @@
 /* Supervisor Protection and Translation */
 #define CSR_SATP  0x180
 
+/* Sstc extension */
+#define CSR_STIMECMP  0x14D
+
 /* Trap/Exception Causes */
 #define CAUSE_MISALIGNED_FETCH  0x0
 #define CAUSE_FETCH_ACCESS  0x1
diff --git a/MdePkg/Library/BaseLib/RiscV64/ReadTimer.S 
b/MdePkg/Library/BaseLib/RiscV64/ReadTimer.S
index 39a06efa51ef..36781c29c0b9 100644
--- a/MdePkg/Library/BaseLib/RiscV64/ReadTimer.S
+++ b/MdePkg/Library/BaseLib/RiscV64/ReadTimer.S
@@ -21,3 +21,10 @@
 ASM_FUNC (RiscVReadTimer)
 csrr a0, CSR_TIME
 ret
+
+//
+// Set Supervisor Time Compare Register
+//
+ASM_FUNC (RiscVSetSupervisorTimeCompareRegister)
+csrw  CSR_STIMECMP, a0
+ret
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113383): https://edk2.groups.io/g/devel/message/113383
Mute This Topic: https://groups.io/mt/103595209/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 1/4] MdePkg.dec: RISC-V: Define override bit for Sstc extension

[Sunil V L]

Define the BIT 1 as the override bit for Sstc extension. This will be
used by the timer driver to decide whether to use SBI calls or direct
CSR access to configure the timer.

Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Zhiguang Liu 
Cc: Andrei Warkentin 
Signed-off-by: Sunil V L 
---
 MdePkg/MdePkg.dec | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 2ee112cc087a..0459418906f8 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2405,6 +2405,8 @@ [PcdsFixedAtBuild.RISCV64, PcdsPatchableInModule.RISCV64]
   # Configurability to override RISC-V CPU Features
   # BIT 0 = Cache Management Operations. This bit is relevant only if
   # previous stage has feature enabled and user wants to disable it.
+  # BIT 1 = Supervisor Time Compare (Sstc). This bit is relevant only if
+  # previous stage has feature enabled and user wants to disable it.
   #
   
gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0x|UINT64|0x69
 
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113382): https://edk2.groups.io/g/devel/message/113382
Mute This Topic: https://groups.io/mt/103595208/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 0/4] RISC-V: Add support for Sstc extension

[Sunil V L]

This series adds the support for RISC-V Sstc extension in EDK2 timer
implementation. Sstc extension allows S-mode software to program the
timer directly without using SBI calls.

Currently, PCD variable is used to detect whether feature is enabled. By
default the feature is enabled and platforms need to set the PCD to
disable the feature if Sstc is not supported.

For RiscVVirtQemu, it is disabled by default (until extension discovery
feature is enabled).

Changes since v1:
1) Updated "PATCH 3" to address Laszlo's comments.
2) Updated RB tag for PATCH 4.

Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Laszlo Ersek 
Cc: Rahul Kumar 
Cc: Ray Ni 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 

Sunil V L (4):
  MdePkg.dec: RISC-V: Define override bit for Sstc extension
  MdePkg/BaseLib: RISC-V: Add function to update stimecmp register
  UefiCpuPkg/CpuTimerDxeRiscV64: Add support for Sstc
  OvmfPkg/RiscVVirt: Override Sstc extension

 MdePkg/MdePkg.dec |  2 +
 OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc   |  2 +-
 .../CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf |  1 +
 MdePkg/Include/Library/BaseLib.h  |  5 ++
 .../Include/Register/RiscV64/RiscVEncoding.h  |  3 ++
 UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h |  2 +
 UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c | 49 +--
 MdePkg/Library/BaseLib/RiscV64/ReadTimer.S|  7 +++
 8 files changed, 67 insertions(+), 4 deletions(-)

-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113381): https://edk2.groups.io/g/devel/message/113381
Mute This Topic: https://groups.io/mt/103595207/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 0/4] RISC-V: Add support for Sstc extension

[Sunil V L]

Hi Pedro,

On Fri, Jan 05, 2024 at 07:10:40PM +, Pedro Falcato wrote:
> On Wed, Jan 3, 2024 at 1:59 PM Sunil V L  wrote:
> >
> > This series adds the support for RISV-V Sstc extension in EDK2 timer
> 
> nit: RISC-V
> > implementation. Sstc extension allows S-mode software to program the
> > timer directly without using SBI calls.
> >
> > Currently, PCD variable is used to detect whether feature is enabled. By
> > default the feature is enabled and platforms need to set the PCD to
> > disable the feature if Sstc is not supported.
> >
> > For RiscVVirtQemu, it is disabled by default (until extension discovery
> > feature is enabled).
> 
> I'm curious, what do you want Sstc for? Is the performance difference
> measurable (if so, please post numbers, and add them to the commit)?
> Does it have any other advantages?
> 
Good question.

Without Sstc, timer needs to be programmed using SBI call. The number of
instructions via SBI call is way more than a simple CSR access. So, when
the CPU supports Sstc, there is no point in using SBI call. The issue
with SBI call will be worse under KVM since it has to emulate the timer.

Supporting Sstc is futuristic. The platforms can decide not to implement
SBI TIME interface at all since they have Sstc. In that case, EDK2 needs
to have option to support either.

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113353): https://edk2.groups.io/g/devel/message/113353
Mute This Topic: https://groups.io/mt/103501836/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 3/4] UefiCpuPkg/CpuTimerDxeRiscV64: Add support for Sstc

[Sunil V L]

On Thu, Jan 04, 2024 at 03:38:17PM +0100, Laszlo Ersek wrote:
> On 1/3/24 14:58, Sunil V L wrote:
> > Sstc extension allows to program the timer and receive the interrupt
> > without using an SBI call. This reduces the latency to generate the timer
> > interrupt. So, detect whether Sstc extension is supported and use the
> > stimecmp register directly to program the timer interrupt.
> > 
> > Cc: Gerd Hoffmann 
> > Cc: Rahul Kumar 
> > Cc: Laszlo Ersek 
> > Cc: Ray Ni 
> > Cc: Andrei Warkentin 
> > Signed-off-by: Sunil V L 
> > ---
> >  .../CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf |  1 +
> >  UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h |  2 ++
> >  UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c | 30 +--
> >  3 files changed, 31 insertions(+), 2 deletions(-)
> > 
> > diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf 
> > b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
> > index aba660186dc0..f2a2cf12caef 100644
> > --- a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
> > +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
> > @@ -41,6 +41,7 @@ [Sources.RISCV64]
> >Timer.c
> >  
> >  [Pcd]
> > +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride   ## CONSUMES
> >gUefiCpuPkgTokenSpaceGuid.PcdCpuCoreCrystalClockFrequency  ## CONSUMES
> >  
> >  [Protocols]
> > diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h 
> > b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
> > index 9b3542230cb5..5e5071b3f0b2 100644
> > --- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
> > +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
> > @@ -26,6 +26,8 @@
> >  //
> >  #define DEFAULT_TIMER_TICK_DURATION  10
> >  
> > +#define RISCV_CPU_FEATURE_SSTC_BITMASK  0x2
> 
> (1) Not a bug by any means, but BIT1 might read more idiomatic.
> 
I misunderstood your comment. Will use BIT1 instead of 0x2.

Thanks!
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113184): https://edk2.groups.io/g/devel/message/113184
Mute This Topic: https://groups.io/mt/103501843/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 3/4] UefiCpuPkg/CpuTimerDxeRiscV64: Add support for Sstc

[Sunil V L]

Hi Laszlo,

Thank you very much for the review!.

On Thu, Jan 04, 2024 at 03:38:17PM +0100, Laszlo Ersek wrote:
> On 1/3/24 14:58, Sunil V L wrote:
> > Sstc extension allows to program the timer and receive the interrupt
> > without using an SBI call. This reduces the latency to generate the timer
> > interrupt. So, detect whether Sstc extension is supported and use the
> > stimecmp register directly to program the timer interrupt.
> > 
> > Cc: Gerd Hoffmann 
> > Cc: Rahul Kumar 
> > Cc: Laszlo Ersek 
> > Cc: Ray Ni 
> > Cc: Andrei Warkentin 
> > Signed-off-by: Sunil V L 
> > ---
> >  .../CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf |  1 +
> >  UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h |  2 ++
> >  UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c | 30 +--
> >  3 files changed, 31 insertions(+), 2 deletions(-)
> > 
> > diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf 
> > b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
> > index aba660186dc0..f2a2cf12caef 100644
> > --- a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
> > +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
> > @@ -41,6 +41,7 @@ [Sources.RISCV64]
> >Timer.c
> >  
> >  [Pcd]
> > +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride   ## CONSUMES
> >gUefiCpuPkgTokenSpaceGuid.PcdCpuCoreCrystalClockFrequency  ## CONSUMES
> >  
> >  [Protocols]
> > diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h 
> > b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
> > index 9b3542230cb5..5e5071b3f0b2 100644
> > --- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
> > +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
> > @@ -26,6 +26,8 @@
> >  //
> >  #define DEFAULT_TIMER_TICK_DURATION  10
> >  
> > +#define RISCV_CPU_FEATURE_SSTC_BITMASK  0x2
> 
> (1) Not a bug by any means, but BIT1 might read more idiomatic.
> 
Agree. Would RISCV_CPU_FEATURE_BIT1_SSTC be better?

> > +
> >  extern VOID
> >  RiscvSetTimerPeriod (
> >UINT32  TimerPeriod
> > diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c 
> > b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
> > index 30e48061cd06..4babfb4bfc60 100644
> > --- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
> > +++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
> > @@ -44,6 +44,19 @@ STATIC EFI_TIMER_NOTIFY  mTimerNotifyFunction;
> >  STATIC UINT64  mTimerPeriod = 0;
> >  STATIC UINT64  mLastPeriodStart = 0;
> >  
> > +/**
> > +  Check whether Sstc is enabled in PCD.
> > +
> > +**/
> > +STATIC
> > +BOOLEAN
> > +RiscVIsSstcEnabled (
> > +  VOID
> > +  )
> > +{
> > +  return ((PcdGet64 (PcdRiscVFeatureOverride) & 
> > RISCV_CPU_FEATURE_SSTC_BITMASK) != 0);
> > +}
> > +
> >  /**
> >Timer Interrupt Handler.
> >  
> > @@ -94,7 +107,12 @@ TimerInterruptHandler (
> >   ),
> > 100u
> > );  // convert to tick
> > -  SbiSetTimer (PeriodStart);
> > +  if (RiscVIsSstcEnabled ()) {
> 
> (2) Even though the PCD is currently declared as fixed or
> patchable-in-module, seeing a PcdGet64() call on the call stack of the
> timer interrupt handler (and at a high TPL) makes me uncomfortable. It
> carries a risk that later on we relax the PCD decl to dynamic, and then
> this code would become brittle.
> 
> I propose: either replace the PcdGet64 call above with FixedPcdGet64 (so
> it can never land in the runtime / dynamic PCD protocol), or perform the
> PCD check in the entry point function of the driver, and store the
> result in a STATIC BOOLEAN variable. Then further PCD accesses (dynamic
> or otherwise) will not be needed.
> 
Ahh yes. Good point. Let me use a static variable as you suggested.

> > +RiscVSetSupervisorTimeCompareRegister (PeriodStart);
> > +  } else {
> > +SbiSetTimer (PeriodStart);
> > +  }
> > +
> >RiscVEnableTimerInterrupt (); // enable SMode timer int
> >gBS->RestoreTPL (OriginalTPL);
> >  }
> > @@ -197,7 +215,11 @@ TimerDriverSetTimerPeriod (
> >   ),
> > 100u
> > ); // convert to tick
> > -  SbiSetTimer (PeriodStart);
> > +  if (RiscVIsSstcEnabled ()) {
> > +RiscVSetSupervisorTimeCompareRegister (PeriodStart);
> > +  } else {
> > +SbiSetTimer (PeriodStart);
> > +  }
> >  
> >mCpu->EnableInterrupt (mCpu);
> >RiscVEnableTimerInterrupt (); // enable SMode timer int
> 
> 

[edk2-devel] [PATCH 4/4] OvmfPkg/RiscVVirt: Override Sstc extension

[Sunil V L]

Override Sstc extension and use SBI calls itself by default for RISC-V
qemu virt platform.

Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Laszlo Ersek 
Signed-off-by: Sunil V L 
---
 OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc 
b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
index d3624e899e8d..6bc7c90f31dc 100644
--- a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
+++ b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
@@ -203,7 +203,7 @@ [PcdsFeatureFlag]
   gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
 
 [PcdsFixedAtBuild.common]
-  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0xFFFE
+  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0xFFFC
   gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|100
   gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength|100
   gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength|0
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113096): https://edk2.groups.io/g/devel/message/113096
Mute This Topic: https://groups.io/mt/103501846/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 3/4] UefiCpuPkg/CpuTimerDxeRiscV64: Add support for Sstc

[Sunil V L]

Sstc extension allows to program the timer and receive the interrupt
without using an SBI call. This reduces the latency to generate the timer
interrupt. So, detect whether Sstc extension is supported and use the
stimecmp register directly to program the timer interrupt.

Cc: Gerd Hoffmann 
Cc: Rahul Kumar 
Cc: Laszlo Ersek 
Cc: Ray Ni 
Cc: Andrei Warkentin 
Signed-off-by: Sunil V L 
---
 .../CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf |  1 +
 UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h |  2 ++
 UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c | 30 +--
 3 files changed, 31 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf 
b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
index aba660186dc0..f2a2cf12caef 100644
--- a/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
+++ b/UefiCpuPkg/CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf
@@ -41,6 +41,7 @@ [Sources.RISCV64]
   Timer.c
 
 [Pcd]
+  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride   ## CONSUMES
   gUefiCpuPkgTokenSpaceGuid.PcdCpuCoreCrystalClockFrequency  ## CONSUMES
 
 [Protocols]
diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h 
b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
index 9b3542230cb5..5e5071b3f0b2 100644
--- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
+++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h
@@ -26,6 +26,8 @@
 //
 #define DEFAULT_TIMER_TICK_DURATION  10
 
+#define RISCV_CPU_FEATURE_SSTC_BITMASK  0x2
+
 extern VOID
 RiscvSetTimerPeriod (
   UINT32  TimerPeriod
diff --git a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c 
b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
index 30e48061cd06..4babfb4bfc60 100644
--- a/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
+++ b/UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c
@@ -44,6 +44,19 @@ STATIC EFI_TIMER_NOTIFY  mTimerNotifyFunction;
 STATIC UINT64  mTimerPeriod = 0;
 STATIC UINT64  mLastPeriodStart = 0;
 
+/**
+  Check whether Sstc is enabled in PCD.
+
+**/
+STATIC
+BOOLEAN
+RiscVIsSstcEnabled (
+  VOID
+  )
+{
+  return ((PcdGet64 (PcdRiscVFeatureOverride) & 
RISCV_CPU_FEATURE_SSTC_BITMASK) != 0);
+}
+
 /**
   Timer Interrupt Handler.
 
@@ -94,7 +107,12 @@ TimerInterruptHandler (
  ),
100u
);  // convert to tick
-  SbiSetTimer (PeriodStart);
+  if (RiscVIsSstcEnabled ()) {
+RiscVSetSupervisorTimeCompareRegister (PeriodStart);
+  } else {
+SbiSetTimer (PeriodStart);
+  }
+
   RiscVEnableTimerInterrupt (); // enable SMode timer int
   gBS->RestoreTPL (OriginalTPL);
 }
@@ -197,7 +215,11 @@ TimerDriverSetTimerPeriod (
  ),
100u
); // convert to tick
-  SbiSetTimer (PeriodStart);
+  if (RiscVIsSstcEnabled ()) {
+RiscVSetSupervisorTimeCompareRegister (PeriodStart);
+  } else {
+SbiSetTimer (PeriodStart);
+  }
 
   mCpu->EnableInterrupt (mCpu);
   RiscVEnableTimerInterrupt (); // enable SMode timer int
@@ -282,6 +304,10 @@ TimerDriverInitialize (
   //
   mTimerNotifyFunction = NULL;
 
+  if (RiscVIsSstcEnabled ()) {
+DEBUG ((DEBUG_INFO, "%a: Timer interrupt is via Sstc extension\n", 
__func__));
+  }
+
   //
   // Make sure the Timer Architectural Protocol is not already installed in 
the system
   //
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113095): https://edk2.groups.io/g/devel/message/113095
Mute This Topic: https://groups.io/mt/103501843/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 2/4] MdePkg/BaseLib: RISC-V: Add function to update stimecmp register

[Sunil V L]

stimecmp is a CSR supported only when Sstc extension is supported by the
platform. This register can be used to set the timer interrupt directly in
S-mode instead of going via SBI call. Add a function to update this
register.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 
Cc: Andrei Warkentin 
Signed-off-by: Sunil V L 
---
 MdePkg/Include/Library/BaseLib.h| 5 +
 MdePkg/Include/Register/RiscV64/RiscVEncoding.h | 3 +++
 MdePkg/Library/BaseLib/RiscV64/ReadTimer.S  | 7 +++
 3 files changed, 15 insertions(+)

diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index b71e47f41b7f..ca0d06c7f335 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -191,6 +191,11 @@ RiscVReadTimer (
   VOID
   );
 
+VOID
+RiscVSetSupervisorTimeCompareRegister (
+  IN UINT64
+  );
+
 VOID
 RiscVEnableTimerInterrupt (
   VOID
diff --git a/MdePkg/Include/Register/RiscV64/RiscVEncoding.h 
b/MdePkg/Include/Register/RiscV64/RiscVEncoding.h
index 2bde8db478ff..8ccdea2f4fcd 100644
--- a/MdePkg/Include/Register/RiscV64/RiscVEncoding.h
+++ b/MdePkg/Include/Register/RiscV64/RiscVEncoding.h
@@ -96,6 +96,9 @@
 /* Supervisor Protection and Translation */
 #define CSR_SATP  0x180
 
+/* Sstc extension */
+#define CSR_STIMECMP  0x14D
+
 /* Trap/Exception Causes */
 #define CAUSE_MISALIGNED_FETCH  0x0
 #define CAUSE_FETCH_ACCESS  0x1
diff --git a/MdePkg/Library/BaseLib/RiscV64/ReadTimer.S 
b/MdePkg/Library/BaseLib/RiscV64/ReadTimer.S
index 39a06efa51ef..36781c29c0b9 100644
--- a/MdePkg/Library/BaseLib/RiscV64/ReadTimer.S
+++ b/MdePkg/Library/BaseLib/RiscV64/ReadTimer.S
@@ -21,3 +21,10 @@
 ASM_FUNC (RiscVReadTimer)
 csrr a0, CSR_TIME
 ret
+
+//
+// Set Supervisor Time Compare Register
+//
+ASM_FUNC (RiscVSetSupervisorTimeCompareRegister)
+csrw  CSR_STIMECMP, a0
+ret
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113094): https://edk2.groups.io/g/devel/message/113094
Mute This Topic: https://groups.io/mt/103501841/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/4] MdePkg.dec: RISC-V: Define override bit for Sstc extension

[Sunil V L]

Define the BIT 1 as the override bit for Sstc extension. This will be
used by the timer driver to decide whether to use SBI calls or direct
CSR access to configure the timer.

Cc: Liming Gao 
Cc: Michael D Kinney 
Cc: Zhiguang Liu 
Cc: Andrei Warkentin 
Signed-off-by: Sunil V L 
---
 MdePkg/MdePkg.dec | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 2ee112cc087a..0459418906f8 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2405,6 +2405,8 @@ [PcdsFixedAtBuild.RISCV64, PcdsPatchableInModule.RISCV64]
   # Configurability to override RISC-V CPU Features
   # BIT 0 = Cache Management Operations. This bit is relevant only if
   # previous stage has feature enabled and user wants to disable it.
+  # BIT 1 = Supervisor Time Compare (Sstc). This bit is relevant only if
+  # previous stage has feature enabled and user wants to disable it.
   #
   
gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0x|UINT64|0x69
 
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113093): https://edk2.groups.io/g/devel/message/113093
Mute This Topic: https://groups.io/mt/103501838/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 0/4] RISC-V: Add support for Sstc extension

[Sunil V L]

This series adds the support for RISV-V Sstc extension in EDK2 timer
implementation. Sstc extension allows S-mode software to program the
timer directly without using SBI calls.

Currently, PCD variable is used to detect whether feature is enabled. By
default the feature is enabled and platforms need to set the PCD to
disable the feature if Sstc is not supported.

For RiscVVirtQemu, it is disabled by default (until extension discovery
feature is enabled).

Cc: Andrei Warkentin 
Cc: Ard Biesheuvel 
Cc: Gerd Hoffmann 
Cc: Jiewen Yao 
Cc: Laszlo Ersek 
Cc: Rahul Kumar 
Cc: Ray Ni 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Zhiguang Liu 

Sunil V L (4):
  MdePkg.dec: RISC-V: Define override bit for Sstc extension
  MdePkg/BaseLib: RISC-V: Add function to update stimecmp register
  UefiCpuPkg/CpuTimerDxeRiscV64: Add support for Sstc
  OvmfPkg/RiscVVirt: Override Sstc extension

 MdePkg/MdePkg.dec |  2 ++
 OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc   |  2 +-
 .../CpuTimerDxeRiscV64/CpuTimerDxeRiscV64.inf |  1 +
 MdePkg/Include/Library/BaseLib.h  |  5 
 .../Include/Register/RiscV64/RiscVEncoding.h  |  3 ++
 UefiCpuPkg/CpuTimerDxeRiscV64/Timer.h |  2 ++
 UefiCpuPkg/CpuTimerDxeRiscV64/Timer.c | 30 +--
 MdePkg/Library/BaseLib/RiscV64/ReadTimer.S|  7 +
 8 files changed, 49 insertions(+), 3 deletions(-)

-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#113092): https://edk2.groups.io/g/devel/message/113092
Mute This Topic: https://groups.io/mt/103501836/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 22/37] OvmfPkg/RiscVVirt: Remove PciCpuIo2Dxe from RiscVVirt

[Sunil V L]

On Tue, Dec 12, 2023 at 09:13:14PM +0800, Chao Li wrote:
> CpuIo2Dxe is already used by RiscVVirt, so remove it.
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
> 
> Cc: Sunil V L 
> Cc: Andrei Warkentin 
> Signed-off-by: Chao Li 
> ---
Reviewed-by: Sunil V L 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112747): https://edk2.groups.io/g/devel/message/112747
Mute This Topic: https://groups.io/mt/103129122/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 21/37] OvmfPkg/RiscVVirt: Enable UefiCpuPkg version CpuIo2Dxe

[Sunil V L]

On Tue, Dec 12, 2023 at 09:13:08PM +0800, Chao Li wrote:
> Since the UefiCpuPkg/CpuIo2Dxe already supports MMIO, it is enabled at
> this thime.
> 
> Build-tested only (with "RiscVVirtQemu.dsc").
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4584
> 
> Cc: Sunil V L 
> Cc: Andrei Warkentin 
> ---
Hi Chao,

Thank you very much for taking care of this. The changes look good to
me. I understand you will probably send one more version of the series.
Let me do boot test once with these changes and will provide the
Tested-by.

Otherwise,
Reviewed-by: Sunil V L 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112746): https://edk2.groups.io/g/devel/message/112746
Mute This Topic: https://groups.io/mt/103142121/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v10 0/5] Cache Management Operations Support For RISC-V

[Sunil V L]

On Wed, Dec 13, 2023 at 08:29:26PM +0530, Dhaval wrote:
> Implementing code to support Cache Management Operations (CMO) defined by
> RISC-V CMO instructions.https://github.com/riscv/riscv-CMOs
> This is a re-write of original series v5.
> The patchset contains 5 patches- created based on V5 feedback.
> 1. Restructuring of existing code and move instruction declarations into 
> BaseLib
> 2. Renaming existing functions to denote type of instruction used to maanage 
> cache.
>This is useful for further patches where more cache management 
> instructions are added.
> 3. Add the new cache maintenance operations to BaseLib, including the
>new assembly instruction encodings.
> 4. Update BaseCacheMaintenanceLib (utilizing the new BaseLib primitives)
> 5. Add platform level PCD to allow overriding of RISC-V features.
> 
Merged as #5164

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112730): https://edk2.groups.io/g/devel/message/112730
Mute This Topic: https://groups.io/mt/103150381/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v10 5/5] OvmfPkg/RiscVVirt: Override for RISC-V CPU Features

[Sunil V L]

On Wed, Dec 13, 2023 at 08:29:31PM +0530, Dhaval wrote:
> This PCD provides a way for platform to override any
> HW features that are default enabled by previous stages
> of FW (like OpenSBI). For the case where previous/prev
> stage has disabled the feature, this override is not
> useful and its usage should be avoided.
> 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Gerd Hoffmann 
> Cc: Sunil V L 
> Cc: Andrei Warkentin 
> Cc: Laszlo Ersek 
> Cc: Pedro Falcato 
> 
> Signed-off-by: Dhaval Sharma 
> Acked-by: Laszlo Ersek 
> Reviewed-by: Andrei Warkentin 
> ---
> 
> Notes:
> V10:
> - Only keep CMO feature bitmask bit to disabled. Unimplemented bits
>   remain 1.
> V8:
> - Added RV tag
> V7:
> - Added RB tag
> v6:
> - Modify PCD name according to changes made in Baselib implementation
> V5:
> - Introduce PCD for platform
> 
>  OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc 
> b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
> index fe320525153f..a050f1ffc1d4 100644
> --- a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
> +++ b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
> @@ -203,6 +203,7 @@ [PcdsFeatureFlag]
>gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
>  
>  [PcdsFixedAtBuild.common]
> +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0xFFFE
This needs to be a 64-bit value. Again, I will fix it before merging.

Reviewed-by: Sunil V L 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112711): https://edk2.groups.io/g/devel/message/112711
Mute This Topic: https://groups.io/mt/103150443/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v10 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Sunil V L]

+  VOID
> +  )
> +{
> +  // If CMO is disabled in HW, skip Override check
> +  // Otherwise this PCD can override settings
> +  return ((PcdGet64 (PcdRiscVFeatureOverride) & 
> RISCV_CPU_FEATURE_CMO_BITMASK) != 0);
> +}
> +
> +/**
> +  Performs required opeartion on cache lines in the cache coherency domain
> +  of the calling CPU. If Address is not aligned on a cache line boundary,
> +  then entire cache line containing Address is operated. If Address + Length
> +  is not aligned on a cache line boundary, then the entire cache line
> +  containing Address + Length -1 is operated.
> +  If Length is greater than (MAX_ADDRESS - Address + 1), then ASSERT().
> +  @param  Address The base address of the cache lines to
> +  invalidate.
> +  @param  Length  The number of bytes to invalidate from the instruction
> +  cache.
> +  @param  Op  Type of CMO operation to be performed
> +  @return Address.
> +
> +**/
> +STATIC
> +VOID
> +CacheOpCacheRange (
> +  IN VOID  *Address,
> +  IN UINTN Length,
> +  IN CACHE_OP  Op
> +  )
> +{
> +  UINTN  CacheLineSize;
> +  UINTN  Start;
> +  UINTN  End;
> +
> +  if (Length == 0) {
> +return;
> +  }
> +
> +  if ((Op != CacheOpInvld) && (Op != CacheOpFlush) && (Op != CacheOpClean)) {
> +return;
> +  }
> +
> +  ASSERT ((Length - 1) <= (MAX_ADDRESS - (UINTN)Address));
> +
> +  CacheLineSize = RISCV_CACHE_BLOCK_SIZE;
> +
> +  Start = (UINTN)Address;
> +  //
> +  // Calculate the cache line alignment
> +  //
> +  End= (Start + Length + (CacheLineSize - 1)) & ~(CacheLineSize - 1);
> +  Start &= ~((UINTN)CacheLineSize - 1);
> +
> +  DEBUG (
> +(DEBUG_VERBOSE,
> + "CacheOpCacheRange: Performing Cache Management Operation %d \n", Op)
> +);
> +
> +  do {
> +switch (Op) {
> +  case CacheOpInvld:
> +RiscVCpuCacheInvalCmoAsm (Start);
> +break;
> +  case CacheOpFlush:
> +RiscVCpuCacheFlushCmoAsm (Start);
> +break;
> +  case CacheOpClean:
> +RiscVCpuCacheCleanCmoAsm (Start);
> +break;
> +  default:
> +break;
> +}
> +
> +Start = Start + CacheLineSize;
> +  } while (Start != End);
> +}
>  
>  /**
>Invalidates the entire instruction cache in cache coherency domain of the
> -  calling CPU.
> +  calling CPU. Risc-V does not have currently an CBO implementation which can
> +  invalidate the entire I-cache. Hence using Fence instruction for now. P.S.
> +  Fence instruction may or may not implement full I-cache invd functionality
> +  on all implementations.
>  
>  **/
>  VOID
> @@ -28,17 +135,11 @@ InvalidateInstructionCache (
>Invalidates a range of instruction cache lines in the cache coherency 
> domain
>of the calling CPU.
>  
> -  Invalidates the instruction cache lines specified by Address and Length. If
> -  Address is not aligned on a cache line boundary, then entire instruction
> -  cache line containing Address is invalidated. If Address + Length is not
> -  aligned on a cache line boundary, then the entire instruction cache line
> -  containing Address + Length -1 is invalidated. This function may choose to
> -  invalidate the entire instruction cache if that is more efficient than
> -  invalidating the specified range. If Length is 0, then no instruction cache
> -  lines are invalidated. Address is returned.
> -
> -  If Length is greater than (MAX_ADDRESS - Address + 1), then ASSERT().
> -
> +  An operation from a CMO instruction is defined to operate only on the 
> copies
> +  of a cache block that are cached in the caches accessible by the explicit
> +  memory accesses performed by the set of coherent agents.In other words CMO
> +  operations are not applicable to instruction cache. Use fence.i instruction
> +  instead to achieve the same purpose.
>@param  Address The base address of the instruction cache lines to
>invalidate. If the CPU is in a physical addressing mode, 
> then
>Address is a physical address. If the CPU is in a virtual
> @@ -57,9 +158,10 @@ InvalidateInstructionCacheRange (
>)
>  {
>DEBUG (
> -(DEBUG_WARN,
> - "%a:RISC-V unsupported function.\n"
> - "Invalidating the whole instruction cache instead.\n", __func__)
> +(DEBUG_VERBOSE,
> + "InvalidateInstructionCacheRange: RISC-V unsupported function.\n"
> + "Invalidating the whole instruction cache instead.\n"
> +)
>  );
>InvalidateInstructionCache ();
>return Address;
> @@ -81,7 +183,12 @@ WriteBackInvalidateDataCache (
>VOID
>)
>  {
> -  DEBUG ((DEBUG_ERROR, "%a:RISC-V unsupported function.\n", __func__));
> +  ASSERT (FALSE);
> +  DEBUG ((
> +DEBUG_ERROR,
> +"WriteBackInvalidateDataCache:" \
> +"RISC-V unsupported function.\n"
I guess this formatting was pointed by Pedro earlier. This can be made
single line. Let me fix it before merging so that you don't need to send
another version.

Reviewed-by: Sunil V L 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112710): https://edk2.groups.io/g/devel/message/112710
Mute This Topic: https://groups.io/mt/103150435/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v9 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Sunil V L]

On Mon, Dec 11, 2023 at 03:09:19PM +, Pedro Falcato wrote:
> On Mon, Dec 11, 2023 at 1:12 PM Sunil V L  wrote:
> >
> > On Sun, Dec 10, 2023 at 07:51:12PM +0530, Dhaval Sharma wrote:
> [...]
> > > nit: Can we pick a log style here? Like : 
> > > In this case, "CacheOpCacheRange: Performing ...". It's just prettier
> > > and more greppable.
> > > My interpretation of this was removing __func__ and instead having some
> > > relevant text would make it more searchable.
> > > And it kind of did make sense to me. I know many places __func__ is used
> > > but this is just a perspective.
> > >
> > I think the comment meant to follow a standard logging format since
> > there was no ":" and a space in original change. I prefer __func__ over
> > this so that we don't need to update multiple lines in case function
> > name gets changed.
> 
> I definitely meant that __func__ should not be used for this as well.
> You can't really search for an error message if you're doing
> gratuitous printf formatting for no reason.
> Linux even has a policy where user-facing strings (i.e logs) cannot
> get broken up, even if you run out of line width.
> 
Thanks Pedro. Do you mean __func__ should not be used at all in any
of logging? Or is there a case where it is allowed vs not allowed? 

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112307): https://edk2.groups.io/g/devel/message/112307
Mute This Topic: https://groups.io/mt/102967058/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v9 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Sunil V L]

On Sun, Dec 10, 2023 at 07:51:12PM +0530, Dhaval Sharma wrote:
> Thanks for the review. My comments inline:
> 
> On Fri, Dec 8, 2023 at 9:58 AM Sunil V L  wrote:
> 
> > On Thu, Dec 07, 2023 at 10:31:48AM +0530, Dhaval Sharma wrote:
> > > Comments inline:
> > >
> > >
> > > On Wed, Dec 6, 2023 at 7:50 PM Sunil V L 
> > wrote:
> > >
> > > > Hi Dhaval,
> > > >
> > > > Thank you very much for fixing the issue with instruction cache
> > > > invalidation and confirming with the spec owner. Few minor comments
> > > > below.
> > > >
> > > > On Mon, Dec 04, 2023 at 01:59:49PM +0530, Dhaval Sharma wrote:
> > > > > Use newly defined cache management operations for RISC-V where
> > possible
> > > > > It builds up on the support added for RISC-V cache management
> > > > > instructions in BaseLib.
> > > > > Cc: Michael D Kinney 
> > > > > Cc: Liming Gao 
> > > > > Cc: Zhiguang Liu 
> > > > > Cc: Laszlo Ersek 
> > > > >
> > > > > Signed-off-by: Dhaval Sharma 
> > > > > Acked-by: Laszlo Ersek 
> > > > > ---
> > > > >
> > > > > Notes:
> > > > > V9:
> > > > > - Fixed an issue with Instruction cache invalidation. Use fence.i
> > > > >   instruction as CMO does not support i-cache operations.
> > > > > V8:
> > > > > - Added note to convert PCD into RISC-V feature bitmap pointer
> > > > > - Modified function names to be more explicit about cache ops
> > > > > - Added RB tag
> > > > > V7:
> > > > > - Added PcdLib
> > > > > - Restructure DEBUG message based on feedback on V6
> > > > > - Make naming consistent to CMO, remove all CBO references
> > > > > - Add ASSERT for not supported functions instead of plain debug
> > > > message
> > > > > - Added RB tag
> > > > > V6:
> > > > > - Utilize cache management instructions if HW supports it
> > > > >   This patch is part of restructuring on top of v5
> > > > >
> > > > IMO, it is better to keep the change log in the cover letter. Since not
> > > > all patches may be CC'd to every one apart from the cover letter, it is
> > > > difficult to understand from the cover letter what has changed in the
> > new
> > > > series.
> > > >
> > > [Dhaval] AFAIU notes are tied to specific commits. But it makes sense, I
> > > can add an update to the cover letter.
> > >
> > > >
> > > > >  MdePkg/MdePkg.dec  |
> > > >  8 +
> > > > >  MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf |
> > > >  5 +
> > > > >  MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c|
> > > > 173 
> > > > >  MdePkg/MdePkg.uni  |
> > > >  4 +
> > > > >  4 files changed, 160 insertions(+), 30 deletions(-)
> > > > >
> > > > > diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> > > > > index ac54338089e8..fa92673ff633 100644
> > > > > --- a/MdePkg/MdePkg.dec
> > > > > +++ b/MdePkg/MdePkg.dec
> > > > > @@ -2399,6 +2399,14 @@ [PcdsFixedAtBuild.AARCH64,
> > > > PcdsPatchableInModule.AARCH64]
> > > > ># @Prompt CPU Rng algorithm's GUID.
> > > > >
> > > >
> > gEfiMdePkgTokenSpaceGuid.PcdCpuRngSupportedAlgorithm|{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}|VOID*|0x0037
> > > > >
> > > > > +[PcdsFixedAtBuild.RISCV64, PcdsPatchableInModule.RISCV64]
> > > > > +  #
> > > > > +  # Configurability to override RISC-V CPU Features
> > > > > +  # BIT 0 = Cache Management Operations. This bit is relevant only
> > if
> > > > > +  # previous stage has feature enabled and user wants to disable it.
> > > > > +  #
> > > > > +
> > > >
> > gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0x|UINT64|0x69
> > > > > +
> > > > >  [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic,
> > PcdsDynamicEx]
> > > > >#

Re: [edk2-devel] [PATCH v9 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Sunil V L]

On Thu, Dec 07, 2023 at 10:31:48AM +0530, Dhaval Sharma wrote:
> Comments inline:
> 
> 
> On Wed, Dec 6, 2023 at 7:50 PM Sunil V L  wrote:
> 
> > Hi Dhaval,
> >
> > Thank you very much for fixing the issue with instruction cache
> > invalidation and confirming with the spec owner. Few minor comments
> > below.
> >
> > On Mon, Dec 04, 2023 at 01:59:49PM +0530, Dhaval Sharma wrote:
> > > Use newly defined cache management operations for RISC-V where possible
> > > It builds up on the support added for RISC-V cache management
> > > instructions in BaseLib.
> > > Cc: Michael D Kinney 
> > > Cc: Liming Gao 
> > > Cc: Zhiguang Liu 
> > > Cc: Laszlo Ersek 
> > >
> > > Signed-off-by: Dhaval Sharma 
> > > Acked-by: Laszlo Ersek 
> > > ---
> > >
> > > Notes:
> > > V9:
> > > - Fixed an issue with Instruction cache invalidation. Use fence.i
> > >   instruction as CMO does not support i-cache operations.
> > > V8:
> > > - Added note to convert PCD into RISC-V feature bitmap pointer
> > > - Modified function names to be more explicit about cache ops
> > > - Added RB tag
> > > V7:
> > > - Added PcdLib
> > > - Restructure DEBUG message based on feedback on V6
> > > - Make naming consistent to CMO, remove all CBO references
> > > - Add ASSERT for not supported functions instead of plain debug
> > message
> > > - Added RB tag
> > > V6:
> > > - Utilize cache management instructions if HW supports it
> > >   This patch is part of restructuring on top of v5
> > >
> > IMO, it is better to keep the change log in the cover letter. Since not
> > all patches may be CC'd to every one apart from the cover letter, it is
> > difficult to understand from the cover letter what has changed in the new
> > series.
> >
> [Dhaval] AFAIU notes are tied to specific commits. But it makes sense, I
> can add an update to the cover letter.
> 
> >
> > >  MdePkg/MdePkg.dec  |
> >  8 +
> > >  MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf |
> >  5 +
> > >  MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c|
> > 173 
> > >  MdePkg/MdePkg.uni  |
> >  4 +
> > >  4 files changed, 160 insertions(+), 30 deletions(-)
> > >
> > > diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> > > index ac54338089e8..fa92673ff633 100644
> > > --- a/MdePkg/MdePkg.dec
> > > +++ b/MdePkg/MdePkg.dec
> > > @@ -2399,6 +2399,14 @@ [PcdsFixedAtBuild.AARCH64,
> > PcdsPatchableInModule.AARCH64]
> > ># @Prompt CPU Rng algorithm's GUID.
> > >
> > gEfiMdePkgTokenSpaceGuid.PcdCpuRngSupportedAlgorithm|{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}|VOID*|0x0037
> > >
> > > +[PcdsFixedAtBuild.RISCV64, PcdsPatchableInModule.RISCV64]
> > > +  #
> > > +  # Configurability to override RISC-V CPU Features
> > > +  # BIT 0 = Cache Management Operations. This bit is relevant only if
> > > +  # previous stage has feature enabled and user wants to disable it.
> > > +  #
> > > +
> > gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0x|UINT64|0x69
> > > +
> > >  [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
> > >## This value is used to set the base address of PCI express
> > hierarchy.
> > ># @Prompt PCI Express Base Address.
> > > diff --git
> > a/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> > b/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> > > index 6fd9cbe5f6c9..601a38d6c109 100644
> > > --- a/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> > > +++ b/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> > > @@ -56,3 +56,8 @@ [LibraryClasses]
> > >BaseLib
> > >DebugLib
> > >
> > > +[LibraryClasses.RISCV64]
> > > +  PcdLib
> > > +
> > > +[Pcd.RISCV64]
> > > +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride  ## CONSUMES
> > > diff --git a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> > b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> > > index ac2a3c23a249..cacc38eff4f4 100644
> > >

Re: [edk2-devel] [PATCH v9 5/5] OvmfPkg/RiscVVirt: Override for RV CPU Features

[Sunil V L]

Hi Dhaval,

Few minor comments.

1) Please use RISC-V instead of RV every where.

On Mon, Dec 04, 2023 at 01:59:50PM +0530, Dhaval wrote:
> This PCD provides a way for platform to override any
> HW features that are default enabled by previous stages
> of FW (like OpenSBI). For the case where previous/prev
> stage has disabled the feature, this override is not
> useful and its usage should be avoided.
> 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Gerd Hoffmann 
> Cc: Sunil V L 
> Cc: Andrei Warkentin 
> Cc: Laszlo Ersek 
> 
> Signed-off-by: Dhaval Sharma 
> Acked-by: Laszlo Ersek 
> Reviewed-by: Andrei Warkentin 
> ---
> 
> Notes:
> V8:
> - Added RV tag
> V7:
> - Added RB tag
> v6:
> - Modify PCD name according to changes made in Baselib implementation
> V5:
> - Introduce PCD for platform
> 
>  OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc 
> b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
> index fe320525153f..5d66f7fe6ae6 100644
> --- a/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
> +++ b/OvmfPkg/RiscVVirt/RiscVVirt.dsc.inc
> @@ -203,6 +203,7 @@ [PcdsFeatureFlag]
>gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
>  
>  [PcdsFixedAtBuild.common]
> +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0
Could you set this to 0xFFFE? Just disable only CMO?

Thanks,
Snil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#112127): https://edk2.groups.io/g/devel/message/112127
Mute This Topic: https://groups.io/mt/102967059/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v9 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Sunil V L]

Hi Dhaval,

Thank you very much for fixing the issue with instruction cache
invalidation and confirming with the spec owner. Few minor comments
below.

On Mon, Dec 04, 2023 at 01:59:49PM +0530, Dhaval Sharma wrote:
> Use newly defined cache management operations for RISC-V where possible
> It builds up on the support added for RISC-V cache management
> instructions in BaseLib.
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Laszlo Ersek 
> 
> Signed-off-by: Dhaval Sharma 
> Acked-by: Laszlo Ersek 
> ---
> 
> Notes:
> V9:
> - Fixed an issue with Instruction cache invalidation. Use fence.i
>   instruction as CMO does not support i-cache operations.
> V8:
> - Added note to convert PCD into RISC-V feature bitmap pointer
> - Modified function names to be more explicit about cache ops
> - Added RB tag
> V7:
> - Added PcdLib
> - Restructure DEBUG message based on feedback on V6
> - Make naming consistent to CMO, remove all CBO references
> - Add ASSERT for not supported functions instead of plain debug message
> - Added RB tag
> V6:
> - Utilize cache management instructions if HW supports it
>   This patch is part of restructuring on top of v5
> 
IMO, it is better to keep the change log in the cover letter. Since not
all patches may be CC'd to every one apart from the cover letter, it is
difficult to understand from the cover letter what has changed in the new
series.

>  MdePkg/MdePkg.dec  |   8 +
>  MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf |   5 +
>  MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c| 173 
> 
>  MdePkg/MdePkg.uni  |   4 +
>  4 files changed, 160 insertions(+), 30 deletions(-)
> 
> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> index ac54338089e8..fa92673ff633 100644
> --- a/MdePkg/MdePkg.dec
> +++ b/MdePkg/MdePkg.dec
> @@ -2399,6 +2399,14 @@ [PcdsFixedAtBuild.AARCH64, 
> PcdsPatchableInModule.AARCH64]
># @Prompt CPU Rng algorithm's GUID.
>
> gEfiMdePkgTokenSpaceGuid.PcdCpuRngSupportedAlgorithm|{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}|VOID*|0x0037
>  
> +[PcdsFixedAtBuild.RISCV64, PcdsPatchableInModule.RISCV64]
> +  #
> +  # Configurability to override RISC-V CPU Features
> +  # BIT 0 = Cache Management Operations. This bit is relevant only if
> +  # previous stage has feature enabled and user wants to disable it.
> +  #
> +  
> gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0x|UINT64|0x69
> +
>  [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
>## This value is used to set the base address of PCI express hierarchy.
># @Prompt PCI Express Base Address.
> diff --git 
> a/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf 
> b/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> index 6fd9cbe5f6c9..601a38d6c109 100644
> --- a/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> +++ b/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> @@ -56,3 +56,8 @@ [LibraryClasses]
>BaseLib
>DebugLib
>  
> +[LibraryClasses.RISCV64]
> +  PcdLib
> +
> +[Pcd.RISCV64]
> +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride  ## CONSUMES
> diff --git a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c 
> b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> index ac2a3c23a249..cacc38eff4f4 100644
> --- a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> +++ b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> @@ -2,6 +2,7 @@
>RISC-V specific functionality for cache.
>  
>Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
> +  Copyright (c) 2023, Rivos Inc. All rights reserved.
>  
>SPDX-License-Identifier: BSD-2-Clause-Patent
>  **/
> @@ -9,10 +10,117 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +//
> +// TODO: Grab cache block size and make Cache Management Operation
> +// enabling decision based on RISC-V CPU HOB in
> +// future when it is available and convert PcdRiscVFeatureOverride
> +// PCD to a pointer that contains pointer to bitmap structure
> +// which can be operated more elegantly.
> +//
> +#define RISCV_CACHE_BLOCK_SIZE 64
Can we make this also as a PCD?

> +#define RISCV_CPU_FEATURE_CMO_BITMASK  0x1
> +
> +typedef enum {
> +  CacheOpClean,
> +  CacheOpFlush,
> +  CacheOpInvld,
> +} CACHE_OP;
> +
> +/**
> +Verify CBOs are supported by this HW
> +TODO: Use RISC-V CPU HOB once available.
> +
> +**/
> +STATIC
> +BOOLEAN
> +RiscVIsCMOEnabled (
> +  VOID
> +  )
> +{
> +  // If CMO is disabled in HW, skip Override check
> +  // Otherwise this PCD can override settings
> +  return ((PcdGet64 (PcdRiscVFeatureOverride) & 
> RISCV_CPU_FEATURE_CMO_BITMASK) != 0);
> +}
> +
> +/**
> +  Performs required opeartion on cache 

Re: [edk2-devel] [PATCH v2 17/30] OvmfPkg/LoongArchVirt: Add PciCpuIo2Dxe module

[Sunil V L]

On Tue, Nov 07, 2023 at 06:03:43PM +0800, Chao Li wrote:
> Hi Gerd,
> 
> Yes, you are right, this driver could probably be located somewhere else
> where other ARCH can easily use it, but I can not find the right place,
> maybe MdeModulePkg or MdePkg? I also feel that something is not quite right
> about these two places...
> 
Hi Chao,

It was in my TODO list and somehow never got time, is to migrate some of
these drivers and libraries to common place and use them instead of
copy.

For ex: Move ArmPciCpuIo2Dxe to UefiCpuPkg/CpuIo2Dxe. Either merge with
CpuIo2Dxe or add something like MmioCpuIo2Dxe. I think you can take this
approach.

The recommendation I got from Mike earlier was:
MdePkg for libraries, UefiCpuPkg for drivers and OvmfPkg for purely
Qemu specific. Adding new things in MdeModulePkg was not recommended.

Thanks,
Sunil

> 
> Thanks,
> Chao
> 在 2023/11/7 17:42, Gerd Hoffmann 写道:
> > On Mon, Nov 06, 2023 at 11:29:20AM +0800, Chao Li wrote:
> > > Add PciCpuIo2Dxe for LoongArch, this module is similar to
> > > ArmPciCpuIo2Dxe drvier.
> > What are the differences to ArmPciCpuIo2Dxe?
> > On a quick glance I can't see anything arch-specific here.
> > 
> > Maybe we should find a better place for ArmPciCpuIo2Dxe so loongarch
> > can use it without copying the code?
> > 
> > take care,
> >Gerd
> > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110934): https://edk2.groups.io/g/devel/message/110934
Mute This Topic: https://groups.io/mt/102413880/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v8 0/5] Cache Management Operations Support For RISC-V

[Sunil V L]

On Tue, Nov 07, 2023 at 07:04:58PM +0100, Laszlo Ersek wrote:
> On 11/7/23 08:15, Sunil V L wrote:
> > On Mon, Nov 06, 2023 at 08:23:51AM +0530, Dhaval wrote:
> >> Implementing code to support Cache Management Operations (CMO) defined by
> >> RISC-V CMO instructions.https://github.com/riscv/riscv-CMOs
> >> This is a re-write of original series v5.
> >> The patchset contains 5 patches- created based on V5 feedback.
> >> 1. Restructuring of existing code and move instruction declarations into 
> >> BaseLib
> >> 2. Renaming existing functions to denote type of instruction used to 
> >> maanage cache.
> >>This is useful for further patches where more cache management 
> >> instructions are added.
> >> 3. Add the new cache maintenance operations to BaseLib, including the
> >> new assembly instruction encodings.
> >> 4. Update BaseCacheMaintenanceLib (utilizing the new BaseLib primitives)
> >> 5. Add platform level PCD to allow overriding of RISC-V features.
> >>
> >> Code Link: https://github.com/tianocore/edk2/pull/5002
> >>
> >> Cc: Ard Biesheuvel 
> >> Cc: Jiewen Yao 
> >> Cc: Jordan Justen 
> >> Cc: Gerd Hoffmann 
> >> Cc: Sunil V L 
> >> Cc: Andrei Warkentin 
> >> Cc: Laszlo Ersek 
> >> Cc: Michael D Kinney 
> >> Cc: Liming Gao 
> >> Cc: Zhiguang Liu 
> >> Cc: Daniel Schaefer 
> >>
> >> Dhaval (5):
> >>   MdePkg: Move RISC-V Cache Management Declarations Into BaseLib
> >>   MdePkg: Rename Cache Management Function To Clarify Fence Based Op
> >>   MdePkg: Implement RISC-V Cache Management Operations
> >>   MdePkg: Utilize Cache Management Operations Implementation For RISC-V
> >>   OvmfPkg/RiscVVirt: Override for RV CPU Features
> > 
> > If nobody objects,  I will merge this tomorrow  with or without ack from
> > MdePkg maintainers. The changes are related to RISC-V only anyway.
> 
> I think you'll have to ask Mike or Liming to do the merge, given that
> we're now in soft feature freeze. I do agree though that the series's
> review completed in time for the merge; v8 picked up tags given previously.
> 
Ahh, yes. Thanks for reminding me.

Hi Liming, Mike,

Could you help merging this series?

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110888): https://edk2.groups.io/g/devel/message/110888
Mute This Topic: https://groups.io/mt/102413464/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v8 0/5] Cache Management Operations Support For RISC-V

[Sunil V L]

On Mon, Nov 06, 2023 at 08:23:51AM +0530, Dhaval wrote:
> Implementing code to support Cache Management Operations (CMO) defined by
> RISC-V CMO instructions.https://github.com/riscv/riscv-CMOs
> This is a re-write of original series v5.
> The patchset contains 5 patches- created based on V5 feedback.
> 1. Restructuring of existing code and move instruction declarations into 
> BaseLib
> 2. Renaming existing functions to denote type of instruction used to maanage 
> cache.
>This is useful for further patches where more cache management 
> instructions are added.
> 3. Add the new cache maintenance operations to BaseLib, including the
>new assembly instruction encodings.
> 4. Update BaseCacheMaintenanceLib (utilizing the new BaseLib primitives)
> 5. Add platform level PCD to allow overriding of RISC-V features.
> 
> Code Link: https://github.com/tianocore/edk2/pull/5002
> 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Gerd Hoffmann 
> Cc: Sunil V L 
> Cc: Andrei Warkentin 
> Cc: Laszlo Ersek 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Daniel Schaefer 
> 
> Dhaval (5):
>   MdePkg: Move RISC-V Cache Management Declarations Into BaseLib
>   MdePkg: Rename Cache Management Function To Clarify Fence Based Op
>   MdePkg: Implement RISC-V Cache Management Operations
>   MdePkg: Utilize Cache Management Operations Implementation For RISC-V
>   OvmfPkg/RiscVVirt: Override for RV CPU Features

If nobody objects,  I will merge this tomorrow  with or without ack from
MdePkg maintainers. The changes are related to RISC-V only anyway.

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110820): https://edk2.groups.io/g/devel/message/110820
Mute This Topic: https://groups.io/mt/102413464/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 0/5] StarFive/VisionFive2: Add VisionFive 2 platform

[Sunil V L]

On Tue, Oct 31, 2023 at 06:17:05PM -0700, John Chew wrote:
> Hi Sunil,
> 
> Okay, I will update the "Maintainers.txt" file in patch v4.
> 
> By the way, I wonder if you also review this series?
> 
> [PATCH v2 0/5] Designware MMCDXE changes and enhancement
> 
Hi John,

Ard and Leif are maintainers for this module and will have better
knowledge. So, you need them to review the Designware series.

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110501): https://edk2.groups.io/g/devel/message/110501
Mute This Topic: https://groups.io/mt/102214516/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v3 0/5] StarFive/VisionFive2: Add VisionFive 2 platform

[Sunil V L]

Hi John,

I forgot to mention that you need one more patch to add the maintainer
entry for the platform.

Otherwise, for the series,
Acked-by: Sunil V L 

Thanks,
Sunil
On Fri, Oct 27, 2023 at 11:19:01AM +0800, John Chew wrote:
> v3:
>   - Combine "Add VisionFive 2 platform" patch series with
> "Patches for JH7110 SoC platform" patch series [Sunil]
>   - Change commit message for [1/5], [4/5], [5/5] in this patch series
> [Sunil]
> 
> v2:
>   - Change PlatformBootManagerLib to:
>   Platform/RISC-V/PlatformPkg/.../PlatformBootManagerLib.inf
> [Sunil]
>   - Added PCIE PCDs
> PcdPciBusMin, PcdPciBusMax, PcdPciIoBase, PcdPciIoSize
> PcdPciIoOffset, PcdPci0Mmio32Base, PcdPci0Mmio32Size
> PcdPci0Mmio64Base, PcdPci0Mmio64Size, PcdPci1Mmio32Base
> PcdPci1Mmio32Size, PcdPci1Mmio64Base, PcdPci1Mmio64Size
> [John Chew]
>   - Include all maintainer in all patches in this series [Sunil]
>   - Added missing commit message to patches 1/6, 2/6, 6/6 [Sunil]
>   - Remove commented code in JH7110.h [Sunil]
>   - Remove BootServicesDxe/BootServicesDxe.inf, as it is not required 
> anymore because memory allocation is handle by MMC driver [Sunil]
>   - Remove PlatformBootManagerLib.inf and change PlatformBootManagerLib to
> "Platform/RISC-V/PlatformPkg/.../PlatformBootManagerLib.inf" [Sunil] 
>   - Added PCDs for PCIE (Please refer to patch 0001 for details) [John Chew]
> 
> v1:
>   - Added new platform support for VisionFive2 SBC.
>   - Boot flow in VF2 using EDK2 as bootloader:
> BootROM -> U-Boot SPL -> OpenSBI -> EDK2 -> Linux -> OS
>   - Supported boot source for Linux from EDK2:
>   - SD Card
>   - eMMC
>   - NVMe
>   - USB
>   - In this patches it include all the platform specific drivers/protocol
> that is being use for JH7110 SoC platform. All the drivers includes:
>   1. PCIE driver for NVME and USB (GT710 graphic in progress)
>   2. QSPI Flash driver for efi variable
>       3. FVB driver for efi variable
>   4. Boot service memory allocation driver
>   5. Platform boot manager for graphical console display
> 
> Cc: Sunil V L 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Li Yong 
> Cc: mindachen1987 
> 
> John Chew (2):
>   StarFive/JH7110Pkg: Add SPI protocol and driver support
>   StarFive/JH7110Pkg: Add firmware volume block protocol
> 
> mindachen1987 (3):
>   StarFive/JH7110Pkg: Add Pci controller driver
>   StarFive/JH7110Pkg: Add JH7110 Silicon Package
>   StarFive/VisionFive2: Add VisionFive 2 platform
> 
>  Platform/StarFive/VisionFive2/DeviceTree/Gpio.h  
>  |   42 +
>  Platform/StarFive/VisionFive2/DeviceTree/Irq.h   
>  |   20 +
>  Platform/StarFive/VisionFive2/DeviceTree/JH7110ClkGen.h  
>  |  398 +
>  Platform/StarFive/VisionFive2/DeviceTree/JH7110ClkIsp.h  
>  |   57 +
>  Platform/StarFive/VisionFive2/DeviceTree/JH7110ClkVout.h 
>  |   68 +
>  Platform/StarFive/VisionFive2/DeviceTree/JH7110PinCtrl.h 
>  | 1573 +
>  Platform/StarFive/VisionFive2/DeviceTree/JH7110Power.h   
>  |   22 +
>  Platform/StarFive/VisionFive2/DeviceTree/JH7110Rst.h 
>  |  228 +++
>  Platform/StarFive/VisionFive2/DeviceTree/Led.h   
>  |   90 +
>  Platform/StarFive/VisionFive2/DeviceTree/StarFiveClk.dtsi
>  |  130 ++
>  Platform/StarFive/VisionFive2/DeviceTree/StarFiveHdmi.dtsi   
>  |   28 +
>  Platform/StarFive/VisionFive2/DeviceTree/StarFiveJH7110.dtsi 
>  | 1812 
>  Platform/StarFive/VisionFive2/DeviceTree/StarFivePwmDac.dtsi 
>  |   26 +
>  Platform/StarFive/VisionFive2/DeviceTree/StarFiveVisionFive2.dts 
>  |  211 +++
>  Platform/StarFive/VisionFive2/DeviceTree/StarFiveVisionFive2.dtsi
>  |  838 +
>  Platform/StarFive/VisionFive2/DeviceTree/Thermal.h   
>  |   16 +
>  Platform/StarFive/VisionFive2/DeviceTree/VisionFive2DeviceTree.inf   
>  |   36 +
>  Platform/StarFive/VisionFive2/VarStore.fdf.inc   
>  |   77 +
>  Platform/StarFive/VisionFive2/VisionFive2.dsc
>  |  596 +++
>  Platform/StarFive/VisionFive2/VisionFive2.fdf
>  |  284 +++
>  Platform/StarFive/VisionFive2/VisionFive2.fdf.inc
>  |   48 +
>  Silicon/StarFi

Re: [edk2-devel] [PATCH v7 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Sunil V L]

On Mon, Oct 30, 2023 at 11:24:15PM -0700, Dhaval Sharma wrote:
> Can we define these bits in the header file so that the definitions can
> be used by multiple modules?
> [Dhaval] I could put it un Baselib.h (MDE_CPU_RISCV64) but sounds like right 
> now BaseLib.h is free of such #defines. If you think it is still better would 
> do it. I do not have any preference.
Right, fine then.

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110378): https://edk2.groups.io/g/devel/message/110378
Mute This Topic: https://groups.io/mt/102256468/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v7 3/5] MdePkg: Implement RISC-V Cache Management Operations

[Sunil V L]

On Mon, Oct 30, 2023 at 10:38:21AM +0100, Laszlo Ersek wrote:
> On 10/29/23 20:12, Pedro Falcato wrote:
> > On Sun, Oct 29, 2023 at 2:46 PM Dhaval Sharma  wrote:
> >>
> >> Implement Cache Management Operations (CMO) defined by
> >> RISC-V spec https://github.com/riscv/riscv-CMOs.
> >>
> >> Notes:
> >> 1. CMO only supports block based Operations. Meaning cache
> >>flush/invd/clean Operations are not available for the entire
> >>range. In that case we fallback on fence.i instructions.
> >> 2. Operations are implemented using Opcodes to make them compiler
> >>independent. binutils 2.39+ compilers support CMO instructions.
> >>
> >> Test:
> >> 1. Ensured correct instructions are refelecting in asm
> > 
> > nit: reflecting
> > 
> >> 2. Not able to verify actual instruction in HW as Qemu ignores
> >>any actual cache operations.
> > 
> > Do you have no way to test this in hardware? Since Rivos is a RISCV
> > vendor and all ;)
> > I don't like inviting the idea of merging CPU architectural changes
> > without actually testing them in something resembling real silicon
> > (i.e QEMU KVM is _fine_, QEMU TCG really isn't).
> > 
> 
> Hopefully I'm not drawing an incorrect parallel here, but, as I recall
> arm64 enablement in 2014, nearly all initial enablement in RHEL occurred
> on software emulators (ARM Foundation Model, ARM FVP, then QEMU TCG).
> You need to start somewhere. In particular, qemu-system-aarch64 was a
> huge step forward (performance-wise) once it *existed*, relative to the
> Foundation Model / FVP, even though qemu-system-aarch64 wouldn't emulate
> CPU caches (IIRC).
> 
I agree. As per my knowledge, we don't have a publicly available silicon
implementing these features as of today. So, we are taking the approach
of how linux merged these features when the code adhered to the spec. It
will be great for downstream to get these patches merged.

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110312): https://edk2.groups.io/g/devel/message/110312
Mute This Topic: https://groups.io/mt/102256466/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v7 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Sunil V L]

On Mon, Oct 30, 2023 at 04:48:18PM +0530, Sunil V L wrote:
> On Sun, Oct 29, 2023 at 08:16:12PM +0530, Dhaval Sharma wrote:
> > Use newly defined cache management operations for RISC-V where possible
> > It builds up on the support added for RISC-V cache management
> > instructions in BaseLib.
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Cc: Zhiguang Liu 
> > Cc: Laszlo Ersek 
> > 
> > Signed-off-by: Dhaval Sharma 
> > Acked-by: Laszlo Ersek 
> > ---
> > 
> > Notes:
> > V7:
> > - Added PcdLib
> > - Restructure DEBUG message based on feedback on V6
> > - Make naming consistent to CMO, remove all CBO references
> > - Add ASSERT for not supported functions instead of plain debug message
> > - Added RB tag
> > V6:
> > - Utilize cache management instructions if HW supports it
> >   This patch is part of restructuring on top of v5
> > 
> >  MdePkg/MdePkg.dec  |   8 +
> >  MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf |   5 +
> >  MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c| 168 
> > +---
> >  MdePkg/MdePkg.uni  |   4 +
> >  4 files changed, 165 insertions(+), 20 deletions(-)
> > 
> > diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> > index ac54338089e8..fa92673ff633 100644
> > --- a/MdePkg/MdePkg.dec
> > +++ b/MdePkg/MdePkg.dec
> > @@ -2399,6 +2399,14 @@ [PcdsFixedAtBuild.AARCH64, 
> > PcdsPatchableInModule.AARCH64]
> ># @Prompt CPU Rng algorithm's GUID.
> >
> > gEfiMdePkgTokenSpaceGuid.PcdCpuRngSupportedAlgorithm|{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}|VOID*|0x0037
> >  
> > +[PcdsFixedAtBuild.RISCV64, PcdsPatchableInModule.RISCV64]
> > +  #
> > +  # Configurability to override RISC-V CPU Features
> > +  # BIT 0 = Cache Management Operations. This bit is relevant only if
> > +  # previous stage has feature enabled and user wants to disable it.
> NIT: I am wondering whether PcdRiscVCpuFeatureDisable is better so that
> it is explicit.
> 
> > +  #
> > +  
> > gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0x|UINT64|0x69
> > +
> Instead of this, can default value match only those features which are
> enabled by default for qemu virt machine? That way, I think we can avoid
> having this PCD defined again in RiscVVirt.
> 
Sorry, I take back. This is common for all platforms. So, we can't take
qemu as reference.

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110309): https://edk2.groups.io/g/devel/message/110309
Mute This Topic: https://groups.io/mt/102256468/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v7 4/5] MdePkg: Utilize Cache Management Operations Implementation For RISC-V

[Sunil V L]

On Sun, Oct 29, 2023 at 08:16:12PM +0530, Dhaval Sharma wrote:
> Use newly defined cache management operations for RISC-V where possible
> It builds up on the support added for RISC-V cache management
> instructions in BaseLib.
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Laszlo Ersek 
> 
> Signed-off-by: Dhaval Sharma 
> Acked-by: Laszlo Ersek 
> ---
> 
> Notes:
> V7:
> - Added PcdLib
> - Restructure DEBUG message based on feedback on V6
> - Make naming consistent to CMO, remove all CBO references
> - Add ASSERT for not supported functions instead of plain debug message
> - Added RB tag
> V6:
> - Utilize cache management instructions if HW supports it
>   This patch is part of restructuring on top of v5
> 
>  MdePkg/MdePkg.dec  |   8 +
>  MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf |   5 +
>  MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c| 168 
> +---
>  MdePkg/MdePkg.uni  |   4 +
>  4 files changed, 165 insertions(+), 20 deletions(-)
> 
> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> index ac54338089e8..fa92673ff633 100644
> --- a/MdePkg/MdePkg.dec
> +++ b/MdePkg/MdePkg.dec
> @@ -2399,6 +2399,14 @@ [PcdsFixedAtBuild.AARCH64, 
> PcdsPatchableInModule.AARCH64]
># @Prompt CPU Rng algorithm's GUID.
>
> gEfiMdePkgTokenSpaceGuid.PcdCpuRngSupportedAlgorithm|{0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00}|VOID*|0x0037
>  
> +[PcdsFixedAtBuild.RISCV64, PcdsPatchableInModule.RISCV64]
> +  #
> +  # Configurability to override RISC-V CPU Features
> +  # BIT 0 = Cache Management Operations. This bit is relevant only if
> +  # previous stage has feature enabled and user wants to disable it.
NIT: I am wondering whether PcdRiscVCpuFeatureDisable is better so that
it is explicit.

> +  #
> +  
> gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride|0x|UINT64|0x69
> +
Instead of this, can default value match only those features which are
enabled by default for qemu virt machine? That way, I think we can avoid
having this PCD defined again in RiscVVirt.

>  [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
>## This value is used to set the base address of PCI express hierarchy.
># @Prompt PCI Express Base Address.
> diff --git 
> a/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf 
> b/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> index 6fd9cbe5f6c9..601a38d6c109 100644
> --- a/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> +++ b/MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
> @@ -56,3 +56,8 @@ [LibraryClasses]
>BaseLib
>DebugLib
>  
> +[LibraryClasses.RISCV64]
> +  PcdLib
> +
> +[Pcd.RISCV64]
> +  gEfiMdePkgTokenSpaceGuid.PcdRiscVFeatureOverride  ## CONSUMES
> diff --git a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c 
> b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> index 4eb18edb9aa7..5b3104afb67e 100644
> --- a/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> +++ b/MdePkg/Library/BaseCacheMaintenanceLib/RiscVCache.c
> @@ -2,6 +2,7 @@
>RISC-V specific functionality for cache.
>  
>Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
> +  Copyright (c) 2023, Rivos Inc. All rights reserved.
>  
>SPDX-License-Identifier: BSD-2-Clause-Patent
>  **/
> @@ -9,10 +10,115 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +//
> +// TODO: Grab cache block size and make Cache Management Operation
> +// enabling decision based on RISC-V CPU HOB in
> +// future when it is available.
> +//
> +#define RISCV_CACHE_BLOCK_SIZE 64
> +#define RISCV_CPU_FEATURE_CMO_BITMASK  0x1
> +
Can we define these bits in the header file so that the definitions can
be used by multiple modules?

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110308): https://edk2.groups.io/g/devel/message/110308
Mute This Topic: https://groups.io/mt/102256468/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v7 3/5] MdePkg: Implement RISC-V Cache Management Operations

[Sunil V L]

On Sun, Oct 29, 2023 at 08:16:11PM +0530, Dhaval wrote:
> Implement Cache Management Operations (CMO) defined by
> RISC-V spec https://github.com/riscv/riscv-CMOs.
> 
> Notes:
> 1. CMO only supports block based Operations. Meaning cache
>flush/invd/clean Operations are not available for the entire
>range. In that case we fallback on fence.i instructions.
> 2. Operations are implemented using Opcodes to make them compiler
>independent. binutils 2.39+ compilers support CMO instructions.
> 
> Test:
> 1. Ensured correct instructions are refelecting in asm
> 2. Not able to verify actual instruction in HW as Qemu ignores
>any actual cache operations.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Zhiguang Liu 
> Cc: Sunil V L 
> Cc: Daniel Schaefer 
> Cc: Laszlo Ersek 
> 
> Signed-off-by: Dhaval Sharma 
> Reviewed-by: Laszlo Ersek 
> ---
> 
> Notes:
> V7:
> - Modify instruction names as per feedback from V6
> - Added RB
> V6:
> - Implement Cache management instructions in Baselib
> 
>  MdePkg/Library/BaseLib/BaseLib.inf|  2 +-
>  MdePkg/Include/Library/BaseLib.h  | 33 
> 
>  MdePkg/Include/RiscV64/RiscVasm.inc   | 19 
> +++
>  MdePkg/Library/BaseLib/RiscV64/{FlushCache.S => RiscVCacheMgmt.S} | 17 
> ++
>  4 files changed, 70 insertions(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Library/BaseLib/BaseLib.inf 
> b/MdePkg/Library/BaseLib/BaseLib.inf
> index 03c7b02e828b..53389389448c 100644
> --- a/MdePkg/Library/BaseLib/BaseLib.inf
> +++ b/MdePkg/Library/BaseLib/BaseLib.inf
> @@ -400,7 +400,7 @@ [Sources.RISCV64]
>RiscV64/RiscVCpuBreakpoint.S  | GCC
>RiscV64/RiscVCpuPause.S   | GCC
>RiscV64/RiscVInterrupt.S  | GCC
> -  RiscV64/FlushCache.S  | GCC
> +  RiscV64/RiscVCacheMgmt.S  | GCC
>RiscV64/CpuScratch.S  | GCC
>RiscV64/ReadTimer.S   | GCC
>RiscV64/RiscVMmu.S| GCC
> diff --git a/MdePkg/Include/Library/BaseLib.h 
> b/MdePkg/Include/Library/BaseLib.h
> index d4b56a9601da..c42cc165dc82 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -226,6 +226,39 @@ RiscVInvalidateDataCacheAsmFence (
>VOID
>);
>  
> +/**
> +  RISC-V flush cache block. Atomically perform a clean operation
> +  followed by an invalidate operation
> +
> +**/
> +VOID
> +EFIAPI
> +RiscVCpuCacheFlushAsmCmo (

NIT: I would keep Asm at the end for these interface names.

Otherwise,
Reviewed-by: Sunil V L 

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110307): https://edk2.groups.io/g/devel/message/110307
Mute This Topic: https://groups.io/mt/102256466/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] Maintainers.txt: Add maintainers for Sophgo platform

[Sunil V L]

On Thu, Oct 19, 2023 at 04:11:46PM +0200, Laszlo Ersek wrote:
> On 10/19/23 15:48, caiyuqing...@163.com wrote:
> > From: caiyuqing379 
> > 
> > This "Platform/Sophgo/Maintainers.md" file format is useless with
> > edk2's "BaseTools/Scripts/GetMaintainer.py" utility, so delete this
> > file. Add add the maintainers to the "Maintainers.txt" file.
> > 
> > Cc: dahogn 
> > Cc: meng-cz 
> > Cc: USER0FISH 
> > Cc: Sunil V L 
> > Cc: Leif Lindholm 
> > Cc: Michael D Kinney 
> > Cc: Laszlo Ersek 
> > Signed-off-by: caiyuqing379 
> > ---
> >  Maintainers.txt|   9 ++
> >  Platform/Sophgo/Maintainers.md | 105 
> >  2 files changed, 9 insertions(+), 105 deletions(-)
> 
> Acked-by: Laszlo Ersek 
> 
Merged as PR #105.

Thanks!
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109888): https://edk2.groups.io/g/devel/message/109888
Mute This Topic: https://groups.io/mt/102060744/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] Maintainers.txt: Add maintainers for Sophgo platform

[Sunil V L]

On Thu, Oct 19, 2023 at 09:48:15PM +0800, caiyuqing...@163.com wrote:
> From: caiyuqing379 
> 
> This "Platform/Sophgo/Maintainers.md" file format is useless with
> edk2's "BaseTools/Scripts/GetMaintainer.py" utility, so delete this
> file. Add add the maintainers to the "Maintainers.txt" file.
> 
> Cc: dahogn 
> Cc: meng-cz 
> Cc: USER0FISH 
> Cc: Sunil V L 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> Cc: Laszlo Ersek 
> Signed-off-by: caiyuqing379 
> ---
>  Maintainers.txt|   9 ++
>  Platform/Sophgo/Maintainers.md | 105 
>  2 files changed, 9 insertions(+), 105 deletions(-)
> 

Thanks!

Reviewed-by: Sunil V L 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109824): https://edk2.groups.io/g/devel/message/109824
Mute This Topic: https://groups.io/mt/102060867/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 6/6] StarFive/JH7110Pkg: Add JH7110 Silicon Package

[Sunil V L]

Hi John,
On Thu, Oct 19, 2023 at 10:59:21AM +0800, John Chew wrote:
> From: mindachen1987 
> 
The patch should have commit message more than one liner. Same comment
for PATCH 1/6 and 2/6.

Also, there should be a patch in the series to add maintainer entry for
your platform.

> Cc: Sunil V L 
> Co-authored-by: John Chew 
> Signed-off-by: mindachen1987 
> ---
>  Silicon/StarFive/JH7110Pkg/Include/IndustryStandard/JH7110.h | 24 +++
>  Silicon/StarFive/JH7110Pkg/JH7110Pkg.dec | 45 
> 
>  2 files changed, 69 insertions(+)
> 
> diff --git a/Silicon/StarFive/JH7110Pkg/Include/IndustryStandard/JH7110.h 
> b/Silicon/StarFive/JH7110Pkg/Include/IndustryStandard/JH7110.h
> new file mode 100644
> index ..b6875f6aa82b
> --- /dev/null
> +++ b/Silicon/StarFive/JH7110Pkg/Include/IndustryStandard/JH7110.h
> @@ -0,0 +1,24 @@
> +/** @file
> + *
> + *  Copyright (c) 2023, StarFive Technology Co., Ltd. All rights 
> reserved.
> + *
> + *  SPDX-License-Identifier: BSD-2-Clause-Patent
> + *
> + **/
> +
> +#ifndef JH7110_H__
> +#define JH7110_H__
> +
> +// #define JH7110_SOC_REGISTERS   (FixedPcdGet64 
> (PcdJH7110RegistersAddress))
> +// #define JH7110_SOC_REGISTER_LENGTH 0x0200
> +
Could you remove these commented code?

Thanks,
Sunil

> +/* Generic PCI addresses */
> +#define PCIE_TOP_OF_MEM_WIN   (FixedPcdGet64 (PcdJH7110PciBusMmioAdr))
> +#define PCIE_CPU_MMIO_WINDOW  (FixedPcdGet64 (PcdJH7110PciCpuMmioAdr))
> +#define PCIE_BRIDGE_MMIO_LEN  (FixedPcdGet32 (PcdJH7110PciBusMmioLen))
> +
> +/* PCI root bridge control registers location */
> +#define PCIE_REG_BASE (FixedPcdGet64 (PcdJH7110PciRegBase))
> +#define PCIE_CONFIG_BASE  (FixedPcdGet64 (PcdJH7110PciConfigRegBase))
> +
> +#endif /* JH7110_H__ */
> diff --git a/Silicon/StarFive/JH7110Pkg/JH7110Pkg.dec 
> b/Silicon/StarFive/JH7110Pkg/JH7110Pkg.dec
> new file mode 100644
> index ..438557a15500
> --- /dev/null
> +++ b/Silicon/StarFive/JH7110Pkg/JH7110Pkg.dec
> @@ -0,0 +1,45 @@
> +## @file
> +#
> +#  Copyright (c) 2023, StarFive Technology Co., Ltd. All rights reserved.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +##
> +
> +[Defines]
> +  DEC_SPECIFICATION  = 0x0001001A
> +  PACKAGE_NAME   = JH7110Pkg
> +  PACKAGE_GUID   = D4B585C5-EBCA-4779-B974-05A3CF2F10C4
> +  PACKAGE_VERSION= 1.0
> +
> +[Includes]
> +  Include
> +
> +[Guids]
> +  gJH7110TokenSpaceGuid = {0x44045e56, 0x7056, 0x4be6, {0x88, 0xc0, 0x49, 
> 0x0c, 0x67, 0x90, 0x2f, 0xba}}
> +
> +[PcdsFixedAtBuild.common]
> +# Memory map
> +  gJH7110TokenSpaceGuid.PcdJH7110FlashVarOffset|0x0|UINT32|0x0001
> +
> +# PCIe
> +  gJH7110TokenSpaceGuid.PcdJH7110RegistersAddress|0|UINT32|0x0002
> +  gJH7110TokenSpaceGuid.PcdJH7110PciRegBase|0x2b00|UINT64|0x0003
> +  gJH7110TokenSpaceGuid.PcdJH7110PciBusMmioAdr|0x0|UINT64|0x0004
> +  gJH7110TokenSpaceGuid.PcdJH7110PciBusMmioLen|0x0|UINT32|0x0005
> +  gJH7110TokenSpaceGuid.PcdJH7110PciCpuMmioAdr|0x0|UINT64|0x0006
> +  
> gJH7110TokenSpaceGuid.PcdJH7110PciConfigRegBase|0x94000|UINT64|0x0007
> +
> +# SPI
> +  gJH7110TokenSpaceGuid.PcdSpiFlashRegBase|0|UINT32|0x1008
> +  gJH7110TokenSpaceGuid.PcdSpiFlashAhbBase|0|UINT64|0x1009
> +  gJH7110TokenSpaceGuid.PcdSpiFlashFifoWidth|0|UINT8|0x1010
> +  gJH7110TokenSpaceGuid.PcdSpiFlashRefClkHz|0|UINT32|0x1011
> +  gJH7110TokenSpaceGuid.PcdSpiFlashTshslNs|0|UINT32|0x1012
> +  gJH7110TokenSpaceGuid.PcdSpiFlashTsd2dNs|0|UINT32|0x113
> +  gJH7110TokenSpaceGuid.PcdSpiFlashTchshNs|0|UINT32|0x114
> +  gJH7110TokenSpaceGuid.PcdSpiFlashTslchNs|0|UINT32|0x115
> +
> +[Protocols]
> +  gJH7110SpiMasterProtocolGuid = { 0xA33C46E0, 0x4FB6, 0x4AA3, { 0x8E, 0x66, 
> 0x00, 0x06, 0x9F, 0x3A, 0x11, 0x81 }}
> +  gJH7110SpiFlashProtocolGuid  = { 0x5ECECDF6, 0x81DA, 0x4E10, { 0x9D, 0x4B, 
> 0x26, 0x65, 0x8C, 0x03, 0xAB, 0xBC }}
> -- 
> 2.34.1
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109803): https://edk2.groups.io/g/devel/message/109803
Mute This Topic: https://groups.io/mt/102053687/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 5/6] StarFive/JH7110Pkg: Implement boot services memory allocation driver

[Sunil V L]

On Thu, Oct 19, 2023 at 10:59:20AM +0800, John Chew wrote:
> Some DXE drivers such as MMC's DMA can only work with 32-bit addressing.
> So, EfiBootServicesData need to set within 32-bit range only.
> 
> This is achieved by setting all EfiConventionalMemory to
> EfiBootServicesData before any memory allocations in the early stage of
> DXE.
> 
Hi John,

I think this is a fragile workaround. Why not MMC driver allocate 32-bit
memory using EFI API?

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109801): https://edk2.groups.io/g/devel/message/109801
Mute This Topic: https://groups.io/mt/102053685/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 4/6] StarFive/JH7110Pkg: Add PlatformBootManagerLib library

[Sunil V L]

Hi John,

On Thu, Oct 19, 2023 at 10:59:19AM +0800, John Chew wrote:
> From: JohnChew 
> 
> For JH7110 with graphic console
>
This commit message needs to be improved. From the code, I can't find
why this library needs to be copied for your platform. Why not migrate
and use the library in ArmPkg to MdePkg?

> Cc: Sunil V L 
> Co-authored-by: Yong Li 
> Signed-off-by: John Chew 
> ---
>  Silicon/StarFive/JH7110Pkg/Library/PlatformBootManagerLib/PlatformBm.c   
> | 1014 
>  Silicon/StarFive/JH7110Pkg/Library/PlatformBootManagerLib/PlatformBm.h   
> |   46 +
>  
> Silicon/StarFive/JH7110Pkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
>  |   71 ++
>  3 files changed, 1131 insertions(+)
> 
> diff --git 
> a/Silicon/StarFive/JH7110Pkg/Library/PlatformBootManagerLib/PlatformBm.c 
> b/Silicon/StarFive/JH7110Pkg/Library/PlatformBootManagerLib/PlatformBm.c
> new file mode 100755
> index ..b58d2c7cbcd5
> --- /dev/null
> +++ b/Silicon/StarFive/JH7110Pkg/Library/PlatformBootManagerLib/PlatformBm.c
> @@ -0,0 +1,1014 @@
> +/** @file
> +*  Implementation for PlatformBootManagerLib library class interfaces.
> +*
> +*  Copyright (C) 2015-2016, Red Hat, Inc.
> +*  Copyright (c) 2014, ARM Ltd. All rights reserved.
> +*  Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
> +*  Copyright (c) 2023, StarFive Technology Co., Ltd. All rights reserved.
> +*
> +*  SPDX-License-Identifier: BSD-2-Clause-Patent
> +*
> +**/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "PlatformBm.h"
> +
> +#define DP_NODE_LEN(Type)  { (UINT8)sizeof (Type), (UINT8)(sizeof (Type) >> 
> 8) }
> +
> +#define VERSION_STRING_PREFIX  L"RISC-V EDK2 firmware version "
> +
> +#pragma pack (1)
> +typedef struct {
> +  VENDOR_DEVICE_PATHSerialDxe;
> +  UART_DEVICE_PATH  Uart;
> +  VENDOR_DEFINED_DEVICE_PATHTermType;
> +  EFI_DEVICE_PATH_PROTOCOL  End;
> +} PLATFORM_SERIAL_CONSOLE;
> +#pragma pack ()
> +
> +STATIC PLATFORM_SERIAL_CONSOLE  mSerialConsole = {
> +  //
> +  // VENDOR_DEVICE_PATH SerialDxe
> +  //
> +  {
> +{ HARDWARE_DEVICE_PATH,  HW_VENDOR_DP, DP_NODE_LEN (VENDOR_DEVICE_PATH) 
> },
> +EDKII_SERIAL_PORT_LIB_VENDOR_GUID
> +  },
> +
> +  //
> +  // UART_DEVICE_PATH Uart
> +  //
> +  {
> +{ MESSAGING_DEVICE_PATH, MSG_UART_DP,  DP_NODE_LEN (UART_DEVICE_PATH)   
> },
> +0,  // Reserved
> +FixedPcdGet64 (PcdUartDefaultBaudRate), // BaudRate
> +FixedPcdGet8 (PcdUartDefaultDataBits),  // DataBits
> +FixedPcdGet8 (PcdUartDefaultParity),// Parity
> +FixedPcdGet8 (PcdUartDefaultStopBits)   // StopBits
> +  },
> +
> +  //
> +  // VENDOR_DEFINED_DEVICE_PATH TermType
> +  //
> +  {
> +{
> +  MESSAGING_DEVICE_PATH, MSG_VENDOR_DP,
> +  DP_NODE_LEN (VENDOR_DEFINED_DEVICE_PATH)
> +}
> +//
> +// Guid to be filled in dynamically
> +//
> +  },
> +
> +  //
> +  // EFI_DEVICE_PATH_PROTOCOL End
> +  //
> +  {
> +END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
> +DP_NODE_LEN (EFI_DEVICE_PATH_PROTOCOL)
> +  }
> +};
> +
> +#pragma pack (1)
> +typedef struct {
> +  USB_CLASS_DEVICE_PATH   Keyboard;
> +  EFI_DEVICE_PATH_PROTOCOLEnd;
> +} PLATFORM_USB_KEYBOARD;
> +#pragma pack ()
> +
> +STATIC PLATFORM_USB_KEYBOARD  mUsbKeyboard = {
> +  //
> +  // USB_CLASS_DEVICE_PATH Keyboard
> +  //
> +  {
> +{
> +  MESSAGING_DEVICE_PATH, MSG_USB_CLASS_DP,
> +  DP_NODE_LEN (USB_CLASS_DEVICE_PATH)
> +},
> +0x, // VendorId: any
> +0x, // ProductId: any
> +3,  // DeviceClass: HID
> +1,  // DeviceSubClass: boot
> +1   // DeviceProtocol: keyboard
> +  },
> +
> +  //
> +  // EFI_DEVICE_PATH_PROTOCOL End
> +  //
> +  {
> +END_DEVICE_PATH_TYPE, END_ENTIRE_DEVICE_PATH_SUBTYPE,
> +DP_NODE_LEN (EFI_DEVICE_PATH_PROTOCOL)
> +  }
> +};
> +
> +/**
> +  Check if the handle satisfies a particular condition.
> +
> +  @param[in] Handle  The handle to check.
> +  @param[in] ReportText  A caller-allocated string passed in for reporting
> + purposes. It must never be NULL.
> +
> +  @retval TRUE   The condition is satisfied.
> +  @retval FALSE  Otherw

Re: [edk2-devel] [PATCH v1 0/6] Patches for JH7110 SoC platform

[Sunil V L]

On Thu, Oct 19, 2023 at 10:57:30AM +0800, John Chew wrote:
> In this patches it include all the platform specific drivers/protocol
> that is being use for JH7110 SoC platform. All the drivers includes:
> 1. PCIE driver for NVME and USB (GT710 graphic in progress)
> 2. QSPI Flash driver for efi variable
> 3. FVB driver for efi variable
> 4. Boot service memory allocation driver
> 5. Platform boot manager for graphical console display
> 
> Reference branch: 
> https://github.com/johnchewyy/edkii-platforms/tree/vf2_jh7110_devel_upstream
> 
> Cc: Sunil V L 
> Cc: Li Yong 
> 
Hi John,

Please copy Leif and Mike for all patches. They are the maintainers for
overall edk2-platforms repo [1].

Also, I recommend to follow Laszlo's documentation [2] regarding
formatting patches.

[1] - 
https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt#L68
[2] - 
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo%27s-unkempt-git-guide-for-edk2-contributors-and-maintainers

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109799): https://edk2.groups.io/g/devel/message/109799
Mute This Topic: https://groups.io/mt/102053672/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v5 7/7] Sophgo/SG2042Pkg: Add platform readme and document.

[Sunil V L]

On Wed, Oct 18, 2023 at 02:11:17PM +0200, Laszlo Ersek wrote:
> On 10/18/23 13:21, 蔡雨晴 wrote:
> > Hi Laszlo,
> > 
> > Thank you for your comments. I will commit a new patch to add the
> > maintainers to the "Maintainers.txt" file in the root directory of the
> > edk2-platforms project.
> > 
> > Please let us know if you have more suggestions.
> 
> I do have one, but it's not specifically for this patch set, but for all
> future edk2(-platforms) patches you may post -- please add "--stat=1000
> --stat-graph-width=20" to your git-format-patch command line.
> Edk2(-platforms) use(s) long pathnames, and so the cumulative diffstat
> tends to be truncated, and on the left side at that. That fact makes it
> hard to see the extent of a patchset. If you add these options, then the
> cumulative diffstat is going to be just as wide as it needs to be -- no
> truncation, and no needless padding.
> 
> The "BaseTools/Scripts/SetupGit.py" utility creates a git-format-patch
> alias called "fp" that includes these options.
> 
> BTW I could help Ard out by pushing this patch set (well, v4, with the
> Maintainers.txt fix), I'm just not clear when a patch set counts as
> "sufficiently reviewed" for edk2-platforms.
> 
> Laszlo
> 
Hi Laszlo,

I have pushed the v5 series since they looked decent. Leif had given
some feedback which are taken care and they looked decent. Maintainer
entry needs to be added as separate patch. I know there are further
improvements planned.

BTW, I have recommended many people to read your guide [1] which I also
refer every time. Though few things like Setup.py can be added, I found
your document is really good for any one working on EDK2 patches.
Thanks!

[1] -
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo%27s-unkempt-git-guide-for-edk2-contributors-and-maintainers




> > 
> > Thanks,
> > Yuqing Cai
> > 
> > 
> > 
> > 
> > 
> > At 2023-10-18 17:47:04, "Laszlo Ersek"  wrote:
> >>On 10/13/23 05:03, caiyuqing...@163.com wrote:
> >>> diff --git a/Platform/Sophgo/Maintainers.md 
> >>> b/Platform/Sophgo/Maintainers.md
> >>> new file mode 100644
> >>> index ..4cb32c359a31
> >>> --- /dev/null
> >>> +++ b/Platform/Sophgo/Maintainers.md
> >>> @@ -0,0 +1,105 @@
> >>> +##Project Name: EDK2 Sophgo SG2042
> >>> +
> >>> +##Maintainers:
> >>> +1. dahogn - dah...@hotmail.com
> >>> +2. caiyuqing379 - 
> >>> +3. meng-cz - mengcz1...@gmail.com
> >>> +4. USER0FISH - 
> >>> +
> >>
> >>This "Platform/Sophgo/Maintainers.md" file / format is useless with
> >>edk2's "BaseTools/Scripts/GetMaintainer.py" utility. For that utility to
> >>work, you need to add the maintainers to the "Maintainers.txt" file in
> >>the edk2-platforms project root dir (... as well).
> >>
> >>Laszlo
> 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109742): https://edk2.groups.io/g/devel/message/109742
Mute This Topic: https://groups.io/mt/101944473/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms v5 0/7] EDK2 on RISC-V Sophgo SG2042 platform

[Sunil V L]

For the series,
Acked-by: Sunil V L 

On Fri, Oct 13, 2023 at 11:01:09AM +0800, caiyuqing...@163.com wrote:
> From: caiyuqing379 
> 
> Description:
>   Deploy EDK2 to run on 64-core CPU under RISC-V architecture, and 
> successfully boot to OS.
>   Implementation can be seen at:
> 
> https://github.com/AII-SDU/edk2-platforms/tree/devel-Sophgo/SG2042Pkg/Platform/Sophgo.
> 
> Current status:
>   1) Adopted the scheme of separating OpenSBI and EDK2. It follows PEI less 
> design.
>   2) The boot flow is: ZSBL + FSBL + OpenSBI + EDK2 + GRUB2 + Linux OS.
>  ZSBL initializes DDR and loads OpenSBI and EDK2 into memory from the SD 
> card.
>  Boot Linux from SD Card, NVMe SSD.
>   3) Clang toolchain support
>  Build the port using the CLANGDWARF toolchain and the built binary can 
> boot Linux OS.
>   4) Milk-V Pioneer board support
>  The latest firmware type of opensbi provided by Sophgo is replaced from 
> fw_jump.bin
>  to fw_dynamic.bin. Currently, Sophgo/SG2042_EVB_Board has been tested 
> and proven
>  to be compatible with Milk-V Pioneer board.
> 
> Work in progress:
>   1) Add PCIe driver support
>  Sophgo's engineer have added PCIe drivers, NVMe SSD over PCIe has been 
> tested on EVB
>  and Milk-V with no problems, and other PCIe devices are doing 
> workaround. The PCIe
>  driver should be upstreamed by Sophgo after completion of this patch 
> series submission.
>   4) Enable MMU
>  Currently, set PcdCpuRiscVMmuMaxSatpMode to bare mode to avoid memory 
> map issues.
> 
> Revision History:
> Patch v5:
>   This patch series provides the changes:
> 1) Dropped PlatformUpdateMmuDxe patch.
>We tested Tuan's patch and currently set PcdCpuRiscVMmuMaxSatpMode to 
> bare mode.
> 2) Currently add memory nodes to zsbl's code, which makes the memory 
> node's in the
>dt reverse-ordered by address. So add only lowest memory node in SEC 
> module.
> 
> Patch v4:
>   The patch series can be seen at:
> https://edk2.groups.io/g/devel/message/108756
> (Between message 108756 and message 108764, total of nine patches)
>   The patch series provides the changes:
> 1) The patch 3&4 fix INF_VERSION to 1.27.
> 2) Some of the code in patch 3&4 is based on the open source code 
> provided by Sophgo,
>which is licensed under BDS-3. The patch 3&4 change license from BDS-3 
> to BDS-2 by
>confirming with Sophgo.
> 3) Add comments to the patch 5 indicates that OpenSBI 1.3/1.3.1 should be 
> used, which
>fixed the no-mapping issue. The current OpenSBI provided by Sophgo is 
> v1.2, and the
>dt provided by Sophgo does not use no-map, v1.3 is being actively 
> upgraded.
> 4) This version already supports Clang toolchain, which can be seen at 
> README.md.
> 
> Patch v3:
>   The patch series can be seen at:
> https://edk2.groups.io/g/devel/message/108376
> (Between message 108376 and message 108384, total of nine patches)
>   The patch series provides the changes:
> 1) Remove firmware context
>Reference to Andrei's branch, in the SEC module, the patch 5 avoids 
> getting the FDT
>pointer from the firmware.
> 2) Blurb
>The patch 0 adds some descriptions in Blurb to explain the current 
> status, testing
>situation, and limitations of the project.
> 3) Milk-V Pioneer board
>Running EDK2 on the Milk-V Pioneer board boots into UEFI shell 
> normally, but the SD
>driver can't recognize all the partitions correctly and can't boot 
> Linux OS.
> 4) Layout
>Based on Leif's comment, we moved most of the code in the port from
>Platform/Sophgo/SG2042Pkg/
>to
>Silicon/Sophgo/SG2042Pkg/
> 5) Clang toolchain support
>Our team tried to build the port using the CLANGDWARF toolchain (clang 
> version 18.0.0),
>and updated README.md for CLANGDWARF support. It's able to build 
> successfully but the
>built binary is not fully work.
> 
> Patch v2:
>   The patch series can be seen at:
> https://edk2.groups.io/g/devel/message/108216
> (Between message 108210 and message 108218, total of nine patches)
>   The patch series provides the following changes:
> 1) To avoid further duplication, the patch 2 adds a PlatformUpdateMmuDxe 
> which contains two
>main features. The first feature is to change the page attributes 
> corresponding to memory.
>The second feature is to introduce a PCD variable PcdForceNoMMU to 
> disable MMU. Currently,
>enabling MMU results in a timeout for reading data blocks from the SD 
> card, so MMU is
>   

Re: [edk2-devel] [PATCH v2] UefiCpuPkg: RISC-V: MMU: Introduce a PCD for SATP mode

[Sunil V L]

On Thu, Oct 12, 2023 at 07:29:59PM +0100, Pedro Falcato wrote:
> On Thu, Oct 12, 2023 at 1:12 PM Sunil V L  wrote:
> >
> > Hi Ray,
> >
> > On Wed, Oct 04, 2023 at 11:34:26AM -0700, Tuan Phan wrote:
> > > Introduce a PCD to control the maximum SATP mode that MMU allowed
> > > to use. This PCD helps RISC-V platform set bare or minimum SATP mode
> > > during bring up to debug memory map issue.
> > >
> > Could you help with review of this?
> 
> It seems glaring to me that Maintainers.txt needs some sort of
> 
> RISCV
> F: */*RiscV*/
> 
> pattern for riscv architectural changes across all packages - I'm not
> sure how much value the x86 Intel folks can add to RISCV or ARM code
> review and merging, apart from the traditional UEFI/tianocore
> feedback.
> 
I agree. For RISC-V only changes, I don't bother the PKG maintainers.
But like in this case, UefiCpuPkg.dec is modified, I think it is my duty
to make sure PKG maintainers are notified and sufficient time given for
them to ACK. I consider "no response" after few days as "no objection" and
merge the changes.

Thanks,
Sunil


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#109582): https://edk2.groups.io/g/devel/message/109582
Mute This Topic: https://groups.io/mt/101761642/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-