Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

[Abner Chang]

> -Original Message-
> From: Leif Lindholm [mailto:l...@nuviainc.com]
> Sent: Friday, March 13, 2020 5:20 AM
> To: devel@edk2.groups.io; ler...@redhat.com
> Cc: Chang, Abner (HPS SW/FW Technologist) ;
> Schaefer, Daniel (DualStudy) ; Chen, Gilbert
> ; af...@apple.com; michael.d.kin...@intel.com;
> p...@akeo.ie; Ard Biesheuvel 
> Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem
> instead of GUID assignment

The current NULL instance of CompilerIntrinsicsLib is applied on every modules, 
this means it's not flexible for overwriting memcpy (for example) with the 
faster algorithm (such as SSEx instructions) for the specific module in the 
same DSC, right? That says we can't assign a special version of memcpy to just 
one particular module. 

> 
> On Thu, Mar 12, 2020 at 20:42:52 +0100, Laszlo Ersek wrote:
> > On 03/12/20 15:44, Leif Lindholm wrote:
> > > And what would you propose we do the next time the RISC-V toolchain
> > > generates a memcpy call based on some other completely valid change
> > > to core code?
> >
> > We could choose to enable the intrinsics library for RISC-V at that point.
and I would like to see the flexibility of overwriting memory library functions 
for particular modules. There is no special algorithm of memory manipulation so 
far in RISC-V spec, however, the working group of Vector extension does propose 
the new instruction sets.

> 
> We could. And have no time left for resolving any issues that may be
> triggered by that without slipping the next stable tag. I would prefer de-
> risking it.
> 
> > IIUC, the CreateDeviceManagerForm() code in question did break an edk2
> > rule ("don't use structure assignment") *prior* to commit 64a228f5f893.
> > The rule violation was in commit 32465d9ae7ee; RISC-V only exposed it.
> > This doesn't seem uncharted territory.
> 
> I don't understand, I've already said I'm not pushing to revert that patch, I
> have suggested that we don't put RISC-V on less stable ground than
> ARM/AARCH64.
> 
> But continuing on the unrelated topic:
> If the rule is "no structure assignments", then fine, that's part of the C 
> dialect
> you need to learn in order to contribute to TianoCore.
> I can separately start arguing for changing that rule.
> However, I can't easily find that in the coding style - could you give me a
> pointer?
> 
> /
> Leif

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55843): https://edk2.groups.io/g/devel/message/55843
Mute This Topic: https://groups.io/mt/71671270/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 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

[Abner Chang]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Leif Lindholm
> Sent: Thursday, March 12, 2020 10:57 PM
> To: Chang, Abner (HPS SW/FW Technologist) 
> Cc: Schaefer, Daniel (DualStudy) ;
> devel@edk2.groups.io; Chen, Gilbert ;
> af...@apple.com; michael.d.kin...@intel.com; p...@akeo.ie; Ard
> Biesheuvel ; Laszlo Ersek 
> Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem
> instead of GUID assignment
> 
> For clarity, I'm suggesting *I* take care of moving this into a generic 
> Intrinsics
> handling lib, and that HPE take care of including and using it.
Great to hear this.
> 
> I'm also not suggesting we revert the CopyMem patch before that is
> complete.
> 
> On Thu, Mar 12, 2020 at 14:44:52 +, Leif Lindholm wrote:
> > And what would you propose we do the next time the RISC-V toolchain
> > generates a memcpy call based on some other completely valid change to
> > core code?
> >
> > Doing this de-risks the RISC-V upstreaming effort.
> > It's also a trivial move/rename opetation - the only question is where
> > the library should live and be called.
> >
> > /
> > Leif
> >
> > On Thu, Mar 12, 2020 at 14:33:27 +, Chang, Abner (HPS SW/FW
> Technologist) wrote:
> > > I don't prefer to do this at this moment, Leif. I have no problem if
> > > we create a BZ for this and create BaseCompilerIntrinsicsLib in
> > > MdeModulePkg, but please don't bind it with RISC-V EDK2 port. You
> > > know my concern pretty well, we can't hold those RISC-V patches on
> > > hands like forever and address the code structure optimization. We
> > > can still work on BaseCompilerIntrinsicsLib but not part of this
> > > RISC-V submission. We can implement RISC-V variant if necessary
> > > after RISC-V edk2 get in edk2 master.
> > >
> > > Abner
> > >
> > > > -Original Message-
> > > > From: Leif Lindholm [mailto:l...@nuviainc.com]
> > > > Sent: Thursday, March 12, 2020 10:03 PM
> > > > To: Schaefer, Daniel (DualStudy) 
> > > > Cc: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
> > > > ; Chen, Gilbert ;
> > > > af...@apple.com; michael.d.kin...@intel.com; p...@akeo.ie; Ard
> > > > Biesheuvel ; Laszlo Ersek
> > > > 
> > > > Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use
> CopyMem
> > > > instead of GUID assignment
> > > >
> > > > +Ard, Laszlo.
> > > >
> > > > I think it would make sense to move it to MdeModulePkg (or MdePkg)
> > > > and rename it BaseCompilerIntrinsicsLib (it *is* a BASE library).
> > > >
> > > > As I alluded in my reply to Ray - x86 also have this problem, but
> > > > to a lesser extent, and ended up creating library functions to
> > > > call instead of using plain C for certain operations.
> > > > Which was probably the right decision when it was restricted to a
> > > > very few corner cases.
> > > >
> > > > /
> > > > Leif
> > > >
> > > > On Thu, Mar 12, 2020 at 13:24:30 +, Schaefer, Daniel (DualStudy)
> wrote:
> > > > > Hi Leif,
> > > > >
> > > > > you're right. If I revert my commit and include
> > > > >
> > > > > NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.
> > > > > inf without making any changes to it, the build succeeds.
> > > > >
> > > > > What do others think? (cc Michael, Pete, Andrew, Ard, who have
> > > > > made changes to this module) Is this a big hack or should we use
> > > > > it in RISC-V, too
> > > > and move the module to MdeModulePkg?
> > > > > Why isn't this a problem on x86? Was it fine on Itanium?
> > > > >
> > > > > - Daniel
> > > > >
> > > > > 
> > > > > From: devel@edk2.groups.io
> > > > >  on behalf
> of
> > > > > Leif Lindholm 
> > > > > Sent: Thursday, March 12, 2020 11:55
> > > > > To: devel@edk2.groups.io
> > > > > ; Schaefer,
> > > > > Daniel
> > > > > (DualStudy)
> > > > 
> > > > > Cc: Chang, Abner (HPS SW/FW Technologist)
> > > > > ; Chen,
> Gilbert
> > > > > ; Dandan Bi
> > > > > ; Eric Dong
> > > > > 
> > > > > Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use
> > > > > CopyMem instead of GUID assignment
> > > > >
> > > > > Hi Daniel,
> > > > >
> > > > > There is nothing wrong with this patch that just went in (and I
> > > > > should have called out sooner if I wanted to stop it), but I
> > > > > think a better solution is to implement a RISC-V variant of
> > > > > ArmPkg/Library/CompilerIntrinsicsLib/.
> > > > >
> > > > > It is perfectly valid for the compiler to generate memcpy calls
> > > > > in response to struct operations that are perfectly valid C.
> > > > >
> > > > > In fact, we could consider moving the ArmPkg one over into
> > > > > MdeModulePkg. I have a feeling that including a
> > > > >
> > > > > NULL|ArmPkg/Li

Re: [edk2-devel] [PATCH] Features/Intel/Readme.md: Document meaning of "Complete" for features

[Ni, Ray]

Isaac,
Thanks for the comments. Reply in below.

> -Original Message-
> From: Oram, Isaac W 
> Sent: Thursday, March 12, 2020 11:29 PM
> To: Ray Ni ; devel@edk2.groups.io
> Cc: Ni, Ray ; Dong, Eric ; Chan, Amy 
> ; Chaganty, Rangasai
> V 
> Subject: RE: [PATCH] Features/Intel/Readme.md: Document meaning of "Complete" 
> for features
> 
> Ray,
> 
> I don't think that this is a desirable rule.
> 
> I want to create feature packages that bundle frequently used together 
> existing capabilities.  See the NetworkFeaturePkg
> for an example.  I also want to make feature packages for the USB stack, 
> debug capabilities, and the like that are often
> aggregations of existing modules.

Thanks for reminding me the NetworkFeaturePkg case. NetworkFeaturePkg is a 
valid case.
I want to add this rule to avoid creating a feature package that only contains 
header files, but the implementations are
in each Board package. Do you agree this should be avoided?
How about:
"A feature package must not contain only interfaces which are implemented by 
board source code packages."

> 
> The Minimum Platform Architecture spec targets advanced features that are 
> easy to enable for relatively inexperienced
> developers.  One way of doing that is to leverage the UEFI PI arch and its 
> binary component support features.  The
> Minimum Platform Architecture aims to use this to enable a use case 
> leveraging Firmware Volumes that looks like:
> 1:  Build NetworkFeaturePkg (this produces an FV, customized via PCD and/or 
> static libraries as needed)
> 2:  Load FV (from shell, by injecting into an existing image using FMMT, 
> Fiano, etc)
> 3:  Use network features and functionality
> 
> The model where the only way people extend a UEFI firmware image is by 
> rebuilding a complete solution needs to end.  It
> is a misuse of the architecture in my estimation.  We have not had much 
> success with fine granularity component binary
> use, i.e. individual PEIM and drivers.  Perhaps there is too much expertise 
> needed.  Minimum Platform Architecture and
> Advanced Features aim to improve this by enabling larger granularity binary 
> components that require less UEFI knowledge
> to use effectively.

Is your concern that binary modularity may be not always practical today? If 
that's it, I agree with your concerns.
I do find that /Features/Intel/Debugging/Usb3DebugFeaturePkg only contains 
library. I think the goal is binary
modularity. Before that, source modularity is the bottom-line requirement for 
each feature package.

> 
> I recognize that there is a competing vision that wants to make many small 
> feature packages that are easy to build in or
> out based on simple PCD feature flags.  As that may improve developer's 
> experience, it is not something I am strongly
> contesting.  However, I just don't see it as any different than MdeModulePkg. 
>  It is the same strategy, just using packages
> to organize instead of directories.

The key difference I can see between package and module is that package groups 
the module and the accordingly public
interfaces together. While if putting lots of modules inside a combo package, 
all the public interfaces (like header files) are
together and it's hard to tell which interfaces are used by which modules.

> 
> The other consideration should include that we have a lot of existing users.  
> I don't want to move existing code around to
> make usable features.  If we move existing code to create the feature in the 
> first place, we affect all the existing users,
> often for no immediate benefit.  If features become successful and widely 
> used, then is a good time to refactor the code.
> The difference is that at that time, the change is essentially behind an 
> abstraction and so the change doesn't cause as
> much pointless work.

AdvancedFeaturePkg is the abstraction layer that aims to hide the future 
changes.

> 
> Regards,
> Isaac
> 
> 
> -Original Message-
> From: Ray Ni 
> Sent: Thursday, March 12, 2020 5:41 AM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Dong, Eric ; Chan, Amy 
> ; Chaganty, Rangasai
> V ; Oram, Isaac W 
> Subject: [PATCH] Features/Intel/Readme.md: Document meaning of "Complete" for 
> features
> 
> Today's document doesn't forbidden creation of a feature package with only 
> interfaces and no code to implement the
> interfaces. Such feature package is useless.
> 
> Signed-off-by: Ray Ni 
> Cc: Eric Dong 
> Cc: Amy Chan 
> Cc: Rangasai V Chaganty 
> Cc: Isaac W Oram 
> ---
>  Features/Intel/Readme.md | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Features/Intel/Readme.md b/Features/Intel/Readme.md index 
> 9729f90a41..f0923e3d56 100644
> --- a/Features/Intel/Readme.md
> +++ b/Features/Intel/Readme.md
> @@ -18,7 +18,7 @@ document as needed.
>  Advanced features should be:
>  * _Cohesive_, the feature should not contain any functionality unrelated to 
> the feature.
>  * _Complete_, the feature must have a complete design that 

[edk2-devel] [edk2-staging/Smbios34] ShellPkg/SmbiosView: Add DDR5 support

[Gao, Zhichao]

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2352

Refer to SMBIOS 3.4 spec, add new memory device type - DDR5
and LPDDR5 support for the shell command "smbiosview".

Cc: Ray Ni 
Signed-off-by: Zhichao Gao 
---
 .../UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c| 8 
 1 file changed, 8 insertions(+)

diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
index b80e16d56a..17a2a89d51 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
@@ -2550,6 +2550,14 @@ TABLE_ITEM  MemoryDeviceTypeTable[] = {
   {
 MemoryTypeHBM2,
 L"  HBM2 (High Bandwidth Memory Generation 2)"
+  },
+  {
+MemoryTypeDdr5,
+L"  DDR5"
+  },
+  {
+MemoryTypeLpddr5,
+L"  LPDDR5"
   }
 };
 
-- 
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55840): https://edk2.groups.io/g/devel/message/55840
Mute This Topic: https://groups.io/mt/71918374/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 0/2] OvmfPkg: miscellaneous readability improvements

[Laszlo Ersek]

Repo:   https://pagure.io/lersek/edk2.git
Branch: ovmfpkg_misc_readability

Implement two suggestions from Leif, from the

  [edk2-devel] [PATCH 0/5]
  OvmfPkg: improve SMM comms security with adaptive MemoryTypeInformation

  https://edk2.groups.io/g/devel/message/55726
  20200310222739.26717-1-lersek@redhat.com">http://mid.mail-archive.com/20200310222739.26717-1-lersek@redhat.com

review thread.

Thanks
Laszlo

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Julien Grall 
Cc: Leif Lindholm 
Cc: Philippe Mathieu-Daudé 

Laszlo Ersek (2):
  OvmfPkg/PlatformPei: explain EFI_MEMORY_TYPE_INFORMATION page counts
  OvmfPkg: give more telling names to some FDF include files

 OvmfPkg/OvmfPkgIa32.fdf| 4 ++--
 OvmfPkg/OvmfPkgIa32X64.fdf | 4 ++--
 OvmfPkg/OvmfPkgX64.fdf | 4 ++--
 OvmfPkg/OvmfXen.fdf| 4 ++--
 OvmfPkg/PlatformPei/MemTypeInfo.c  | 6 
++
 OvmfPkg/{DecomprScratchEnd.fdf.inc => FvmainCompactScratchEnd.fdf.inc} | 0
 OvmfPkg/{OvmfPkg.fdf.inc => OvmfPkgDefines.fdf.inc}| 0
 7 files changed, 14 insertions(+), 8 deletions(-)
 rename OvmfPkg/{DecomprScratchEnd.fdf.inc => FvmainCompactScratchEnd.fdf.inc} 
(100%)
 rename OvmfPkg/{OvmfPkg.fdf.inc => OvmfPkgDefines.fdf.inc} (100%)

-- 
2.19.1.3.g30247aa5d201


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55837): https://edk2.groups.io/g/devel/message/55837
Mute This Topic: https://groups.io/mt/71914081/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/2] OvmfPkg/PlatformPei: explain EFI_MEMORY_TYPE_INFORMATION page counts

[Laszlo Ersek]

Add a code comment that explains the nature of the NumberOfPages field
values. Including this kind of historical information was suggested by
Leif in  (alternative link:
<20200312104006.GB23627@bivouac.eciton.net">http://mid.mail-archive.com/20200312104006.GB23627@bivouac.eciton.net>).

Right now, the most recent commit updating the page counts has been commit
991d95636264 ("[...] Update default memory type information to reduce EFI
Memory Map fragmentation.", 2010-07-16).

Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Leif Lindholm 
Cc: Philippe Mathieu-Daudé 
Suggested-by: Leif Lindholm 
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/PlatformPei/MemTypeInfo.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/OvmfPkg/PlatformPei/MemTypeInfo.c 
b/OvmfPkg/PlatformPei/MemTypeInfo.c
index c709236a457a..863c6f382680 100644
--- a/OvmfPkg/PlatformPei/MemTypeInfo.c
+++ b/OvmfPkg/PlatformPei/MemTypeInfo.c
@@ -19,6 +19,12 @@
 
 #include "Platform.h"
 
+//
+// The NumberOfPages values below are ad-hoc. They are updated sporadically at
+// best (please refer to git-blame for past updates). The values capture a set
+// of BIN hints that made sense at a particular time, for some (now likely
+// unknown) workloads / boot paths.
+//
 STATIC EFI_MEMORY_TYPE_INFORMATION mDefaultMemoryTypeInformation[] = {
   { EfiACPIMemoryNVS,   0x004 },
   { EfiACPIReclaimMemory,   0x008 },
-- 
2.19.1.3.g30247aa5d201



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55838): https://edk2.groups.io/g/devel/message/55838
Mute This Topic: https://groups.io/mt/71914082/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 2/2] OvmfPkg: give more telling names to some FDF include files

[Laszlo Ersek]

Leif suggested that FDF include files should preferably refer with their
names to the FDF file sections from which they are included.

Therefore

- rename "OvmfPkg.fdf.inc" to "OvmfPkgDefines.fdf.inc" (included from the
  [Defines] section),

- rename "DecomprScratchEnd.fdf.inc" to "FvmainCompactScratchEnd.fdf.inc"
  (included under the [FV.FVMAIN_COMPACT] section).

Cc: Anthony Perard 
Cc: Ard Biesheuvel 
Cc: Jordan Justen 
Cc: Julien Grall 
Cc: Leif Lindholm 
Cc: Philippe Mathieu-Daudé 
Ref: 20200312142006.GG23627@bivouac.eciton.net">http://mid.mail-archive.com/20200312142006.GG23627@bivouac.eciton.net
Ref: https://edk2.groups.io/g/devel/message/55812
Suggested-by: Leif Lindholm 
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.fdf| 4 ++--
 OvmfPkg/OvmfPkgIa32X64.fdf | 4 ++--
 OvmfPkg/OvmfPkgX64.fdf | 4 ++--
 OvmfPkg/OvmfXen.fdf| 4 ++--
 OvmfPkg/{DecomprScratchEnd.fdf.inc => FvmainCompactScratchEnd.fdf.inc} | 0
 OvmfPkg/{OvmfPkg.fdf.inc => OvmfPkgDefines.fdf.inc}| 0
 6 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index f1a15de365fd..da5943769352 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -11,7 +11,7 @@
 

 
 [Defines]
-!include OvmfPkg.fdf.inc
+!include OvmfPkgDefines.fdf.inc
 
 #
 # Build the variable store and the firmware code as one unified flash device
@@ -397,7 +397,7 @@ [FV.FVMAIN_COMPACT]
}
  }
 
-!include DecomprScratchEnd.fdf.inc
+!include FvmainCompactScratchEnd.fdf.inc
 
 

 
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index 9e2eb78230e9..0e2a5caaf906 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -11,7 +11,7 @@
 

 
 [Defines]
-!include OvmfPkg.fdf.inc
+!include OvmfPkgDefines.fdf.inc
 
 #
 # Build the variable store and the firmware code as one unified flash device
@@ -400,7 +400,7 @@ [FV.FVMAIN_COMPACT]
}
  }
 
-!include DecomprScratchEnd.fdf.inc
+!include FvmainCompactScratchEnd.fdf.inc
 
 

 
diff --git a/OvmfPkg/OvmfPkgX64.fdf b/OvmfPkg/OvmfPkgX64.fdf
index 9e2eb78230e9..0e2a5caaf906 100644
--- a/OvmfPkg/OvmfPkgX64.fdf
+++ b/OvmfPkg/OvmfPkgX64.fdf
@@ -11,7 +11,7 @@
 

 
 [Defines]
-!include OvmfPkg.fdf.inc
+!include OvmfPkgDefines.fdf.inc
 
 #
 # Build the variable store and the firmware code as one unified flash device
@@ -400,7 +400,7 @@ [FV.FVMAIN_COMPACT]
}
  }
 
-!include DecomprScratchEnd.fdf.inc
+!include FvmainCompactScratchEnd.fdf.inc
 
 

 
diff --git a/OvmfPkg/OvmfXen.fdf b/OvmfPkg/OvmfXen.fdf
index 5ca8081c0265..3c4164a5f50e 100644
--- a/OvmfPkg/OvmfXen.fdf
+++ b/OvmfPkg/OvmfXen.fdf
@@ -12,7 +12,7 @@
 

 
 [Defines]
-!include OvmfPkg.fdf.inc
+!include OvmfPkgDefines.fdf.inc
 
 #
 # This will allow the flash device image to be recognize as an ELF, with first
@@ -442,7 +442,7 @@ [FV.FVMAIN_COMPACT]
}
  }
 
-!include DecomprScratchEnd.fdf.inc
+!include FvmainCompactScratchEnd.fdf.inc
 
 

 
diff --git a/OvmfPkg/DecomprScratchEnd.fdf.inc 
b/OvmfPkg/FvmainCompactScratchEnd.fdf.inc
similarity index 100%
rename from OvmfPkg/DecomprScratchEnd.fdf.inc
rename to OvmfPkg/FvmainCompactScratchEnd.fdf.inc
diff --git a/OvmfPkg/OvmfPkg.fdf.inc b/OvmfPkg/OvmfPkgDefines.fdf.inc
similarity index 100%
rename from OvmfPkg/OvmfPkg.fdf.inc
rename to OvmfPkg/OvmfPkgDefines.fdf.inc
-- 
2.19.1.3.g30247aa5d201


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55839): https://edk2.groups.io/g/devel/message/55839
Mute This Topic: https://groups.io/mt/71914083/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/5] OvmfPkg: set fixed FlashNvStorage base addresses with -D SMM_REQUIRE

[Laszlo Ersek]

On 03/12/20 15:20, Leif Lindholm wrote:
> On Wed, Mar 11, 2020 at 17:41:04 +0100, Laszlo Ersek wrote:
 A recent example of this was my request for NetworkPkg to expose its
 include snippets header-less, for DSC files. Please see the "!include
 NetworkPkg/..." directives in the OVMF DSC files; those are also by
 design header-less:

 NetworkPkg/NetworkComponents.dsc.inc
 NetworkPkg/NetworkDefines.dsc.inc
 NetworkPkg/NetworkLibs.dsc.inc
 NetworkPkg/NetworkPcds.dsc.inc
>>>
>>> ...could OvmfPkg use a similar naming scheme to this?
>>>
>>> That would also remove the drawback of not having the section name as
>>> part of the hunk header, as you'd have it anyway immediately above as
>>> part of the file name?
>>
>> There are three FDF include files:
>>
>> (1) DecomprScratchEnd.fdf.inc (included under [FV.FVMAIN_COMPACT], per
>> commit 9beac0d847bf9):
>>
>> ## @file
>> #  This FDF include file computes the end of the scratch buffer used in
>> #  DecompressMemFvs() [OvmfPkg/Sec/SecMain.c]. It is based on the 
>> decompressed
>> #  (ie. original) size of the LZMA-compressed section of the one FFS file in
>> #  the FVMAIN_COMPACT firmware volume.
>> #
>> #  Copyright (C) 2015, Red Hat, Inc.
>> #
>> #  SPDX-License-Identifier: BSD-2-Clause-Patent
>> ##
>>
>> This include file contains DEFINE and SET statements (for setting macros
>> and PCDs, accordingly). I don't think either a "Defines" or "Pcds"
>> suffix would apply.
> 
> Would FvmainCompactScratchEnd.fdf.inc be an option?
> 
>> (2) OvmfPkg.fdf.inc (included under [Defines]):
>>
>> ## @file
>> #  FDF include file that defines the main macros and sets the dependent PCDs.
>> #
>> #  Copyright (C) 2014, Red Hat, Inc.
>> #  Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
>> #
>> #  SPDX-License-Identifier: BSD-2-Clause-Patent
>> #
>> ##
>>
>> Same situation (both DEFINE and SET statements).
> 
> However, it *needs* to be included inside the [Defines] section, so
> there is no need to get philosofical:
> It's OvmfPkgDefines.fdf.inc (or OvmfDefines.fdf.inc).
> This aligns 100% with the NetworkPkg example.
> 
>> (3) VarStore.fdf.inc (included under [FD.OVMF] and [FD.OVMF_VARS]):
>>
>> ## @file
>> #  FDF include file with Layout Regions that define an empty variable store.
>> #
>> #  Copyright (C) 2014, Red Hat, Inc.
>> #  Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
>> #
>> #  SPDX-License-Identifier: BSD-2-Clause-Patent
>> #
>> ##
>>
>> I guess we could rename this to "VarStoreLayoutRegions.fdf.inc" -- but
>> would that really help?
> 
> OK, so this one is different because it can be included in more than
> one location. Also, it's not the sort of thing you need to touch if
> you're not already in the sixth circle of hell.
> 
>> I'm not against introducing helpful name suffixes, I just can't find
>> anything that really fits and significantly improves upon the current
>> names. I vaguely remember racking my brain when I was introducing these
>> files, for better names, and this is what I had come up with. :)
> 
> Sure, this all predates the NetworkPkg fragments (or really any
> fragments). It would just be nice to be able to start aligning this
> across packages. Splitting up the ARM fragment files is also totally
> on the table here.
> 
> /
> Leif
> 

I'll send a patch for (1) and (2).

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55836): https://edk2.groups.io/g/devel/message/55836
Mute This Topic: https://groups.io/mt/71867510/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] github PRs keep breaking for me

[Michael D Kinney]

Laszlo,

I understand your frustration.  Let's work on resolving 
these issues.

What browser are you using?  I would like the reproduce 
that issue and report to GitHub.  Do you a screen shot
where the labels button is not visibe?

Did you use the same branch name or a new branch name with
the same set of commits?  When I do a 2nd PR for the same
content, I use a new branch name.

The hub command is very flexible.  What commands did you try?

I want to root cause this issue.  I suspect it is more related
to Mergify than GitHub or Azure Pipelines.  There is a state 
machine that is watching statuses and the sequence of actions
you are using must be going into a state I did not test.
Are you able to provide the sequences of steps that got the
PR into a bad state and the approximate time between steps?

Thanks,

Mike

> -Original Message-
> From: devel@edk2.groups.io  On
> Behalf Of Laszlo Ersek
> Sent: Thursday, March 12, 2020 2:06 PM
> To: Kinney, Michael D 
> Cc: edk2-devel-groups-io ; Sean
> Brogan 
> Subject: [edk2-devel] github PRs keep breaking for me
> 
> Hi Mike,
> 
> (1) github stopped supporting my browser. I can no
> longer apply the push
> label using my current browser. The "hub" cmdline
> utility does not seem
> to support adding just a label to an existing PR.
> 
> (2) github closed my PR as a personal build (due to
> lack of the "push"
> label), and now it even denies me the option to reopen
> the pull request.
> I deleted and re-pushed the (identical) branch, which
> github noticed in
> the PR, but it still wouldn't re-launch the CI build,
> or honor the
> "push" label.
> 
> CI is good, but github+mergify have turned the merging
> of valid patch
> series from a 3-second git-push command into repeated
> half-hour
> nightmares. Sorry for the strong words, I'm livid.
> 
> Laszlo
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55835): https://edk2.groups.io/g/devel/message/55835
Mute This Topic: https://groups.io/mt/71912281/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 5/5] OvmfPkg: improve SMM comms security with adaptive MemoryTypeInformation

[Laszlo Ersek]

On 03/12/20 11:40, Leif Lindholm wrote:
> On Thu, Mar 12, 2020 at 01:30:10 +0100, Laszlo Ersek wrote:
>> On 03/11/20 20:36, Leif Lindholm wrote:
>>> On Wed, Mar 11, 2020 at 17:22:47 +0100, Laszlo Ersek wrote:
>> +STATIC EFI_MEMORY_TYPE_INFORMATION mDefaultMemoryTypeInformation[] = {
>> +  { EfiACPIMemoryNVS,   0x004 },
>> +  { EfiACPIReclaimMemory,   0x008 },
>> +  { EfiReservedMemoryType,  0x004 },
>> +  { EfiRuntimeServicesData, 0x024 },
>> +  { EfiRuntimeServicesCode, 0x030 },
>> +  { EfiBootServicesCode,0x180 },
>> +  { EfiBootServicesData,0xF00 },
>> +  { EfiMaxMemoryType,   0x000 }
>> +};
>
> Could you add a comment as to where these page counts come from?
> Oh, right, they're just moved across from OvmfPkg/PlatformPei/Platform.c.
>
> It *would* be nice if that could be cleaned up at the same time...

 Sorry, I don't understand -- what kind of cleanup do you have in mind
 precisely? The table is not copied, but moved from the original place,
 so I'm unsure what's left in "Platform.c" to clean up.
>>>
>>> Not left to clean up there, but something to consider addressing when
>>> moving it here. Yes, it's just a move, so we could argue it doesn't
>>> need fixing - but it's a struct with a bunch of live-coded numerical
>>> values completely without explanation.
>>>
>>> "I'd rather not" is an acceptable answer, but I figured I should point
>>> it out.
>>
>> Good point!
>>
>> Yet, I'd rather not :) Long read ahead:
>>
>> This table is used for priming the memory type BINs in the DXE Core.
>> After this set, in non-SMM builds, the functionality will remain the
>> same (the table stays in effect for every boot); in SMM builds, the
>> table is only a starting point for the feedback loop.
>>
>> What's important is that the numbers in the table are entirely ad-hoc.
>> They were last updated in commit 991d95636264, in 2010. They capture a
>> set of BIN hints that made sense at the time, for *some* (now unknown)
>> workloads / boot paths. That's the important trait of this table: it
>> made sense at some point in time, for some use case. That's the property
>> we should not regress.
>>
>> So let's consider the possible ways to improve the table.
> 
> There is fixing and there is improving.
> 
> The preceding paragraph as a comment block would prevent the next
> person who comes across it going "Where the $EXPLETIVE did these
> numbers come from?".
> 
> (Adding the preceding paragraph as well would have saved me another
> minute of grepping, but that is more down to the fact that this is a
> repeating pattern implemented differently for different platforms -
> for most ARM platforms partly hidden away in EmbeddedPkg:
> https://github.com/tianocore/edk2/blob/master/EmbeddedPkg/EmbeddedPkg.dec#L104)
> 
>> (1) Given that in SMM builds, the table will function only as a starting
>> point for the feedback loop, start using two tables. A new one (for the
>> SMM build) with nice numbers (everything 0x1, or everyting 0x1000,
>> whatever), and keep the old one for the non-SMM build.
>>
>> Unfortunately, this "improvement" is a net negative, because then we'd
>> have *more* stuff, on top of the *current* dump-of-obscure-numbers.
>>
>> (2) Keep the one table, but replace the values with nicer looking
>> numbers (see examples above). Unfortunately, larger numbers could waste
>> memory (stuck in BINs and hence in the UEFI memmap) for some boots, and
>> smaller page counts would increase memmap fragmentation.
>>
>> We might cause some (at best, superficial) regressions. And we'd lose
>> the property "this table made sense at some point in time" -- because
>> the new ad-hoc numbers wouldn't even be rooted in measurements.
>>
>> (3) Actually measure various boots and try to derive new page counts
>> from those.
>>
>> This is something I'm not prepared to do. The memory needs (considering
>> the various memory types too), depend on a bunch of stuff:
>>
>> - ACPI tables generated by QEMU (influences AcpiNVS, AcpiReclaim, and
>> even Reserved -- some opcodes in QEMU's ACPI linker/loader script
>> require the production of S3 boot script opcodes). For example if the
>> QEMU command line specifies the vmgenid device, then the S3 boot script
>> stuff applies.
>>
>> - S3 support enabled/disabled in general on the QEMU cmdline.
>>
>> - OS bootloader footprint.
> 
> - Separately loaded drivers (including Option ROMs?), making these
>   numers impossible to precisely determine statically.
> 
>> This approach would uphold the property "has been useful at some point
>> in time, for some workloads" -- but it's too much time to research, and
>> it's anyway obviated by the dynamic / adaptive approach that this series
>> enables for OVMF (in the SMM build).
>>
>> (4) OK, so let's not touch the numeric values, but move them out of the
>> table?
>>
>> (4a) Introduce macros.
>>
>> Not a good idea, as these numbers are never referenced anywhere else.
>> The f

Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

[Leif Lindholm]

On Thu, Mar 12, 2020 at 20:42:52 +0100, Laszlo Ersek wrote:
> On 03/12/20 15:44, Leif Lindholm wrote:
> > And what would you propose we do the next time the RISC-V toolchain
> > generates a memcpy call based on some other completely valid change to
> > core code?
> 
> We could choose to enable the intrinsics library for RISC-V at that point.

We could. And have no time left for resolving any issues that may be
triggered by that without slipping the next stable tag. I would prefer
de-risking it.

> IIUC, the CreateDeviceManagerForm() code in question did break an edk2
> rule ("don't use structure assignment") *prior* to commit 64a228f5f893.
> The rule violation was in commit 32465d9ae7ee; RISC-V only exposed it.
> This doesn't seem uncharted territory.

I don't understand, I've already said I'm not pushing to revert that
patch, I have suggested that we don't put RISC-V on less stable ground
than ARM/AARCH64.

But continuing on the unrelated topic:
If the rule is "no structure assignments", then fine, that's part of
the C dialect you need to learn in order to contribute to TianoCore.
I can separately start arguing for changing that rule.
However, I can't easily find that in the coding style - could you give
me a pointer?

/
Leif

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55833): https://edk2.groups.io/g/devel/message/55833
Mute This Topic: https://groups.io/mt/71671270/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] github PRs keep breaking for me

[Laszlo Ersek]

Hi Mike,

(1) github stopped supporting my browser. I can no longer apply the push
label using my current browser. The "hub" cmdline utility does not seem
to support adding just a label to an existing PR.

(2) github closed my PR as a personal build (due to lack of the "push"
label), and now it even denies me the option to reopen the pull request.
I deleted and re-pushed the (identical) branch, which github noticed in
the PR, but it still wouldn't re-launch the CI build, or honor the
"push" label.

CI is good, but github+mergify have turned the merging of valid patch
series from a 3-second git-push command into repeated half-hour
nightmares. Sorry for the strong words, I'm livid.

Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55832): https://edk2.groups.io/g/devel/message/55832
Mute This Topic: https://groups.io/mt/71912281/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 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

[Leif Lindholm]

On Thu, Mar 12, 2020 at 20:36:04 +0100, Laszlo Ersek wrote:
> On 03/12/20 15:03, Leif Lindholm wrote:
> > +Ard, Laszlo.
> > 
> > I think it would make sense to move it to MdeModulePkg (or MdePkg) and
> > rename it BaseCompilerIntrinsicsLib (it *is* a BASE library).
> > 
> > As I alluded in my reply to Ray - x86 also have this problem, but to a
> > lesser extent, and ended up creating library functions to call instead
> > of using plain C for certain operations.
> > Which was probably the right decision when it was restricted to a
> > very few corner cases.
> 
> I think people that are interested in IA32/X64 are happier with explicit
> CopyMem() calls that are optimized (via one of the several BaseMemoryLib
> instances, such as SSE2, REP + string instructions, MMX, "smart"
> (chunked) C code, etc), than with a naive loop, such as the one in
> "ArmPkg/Library/CompilerIntrinsicsLib/memcpy.c", that gets silently
> plugged into an intrinsic (such as a structure assignment).
> 
> I mean, compiler intrinsics exist in the first place because they
> implement language features in a fast / performant manner, behind the
> scenes.

That may have been the original intent. The end result is we *have*
them, so we must do something about them.

> If we replace the internals of an intrinsic with a slow / naive
> implementation, then the intrinsic has no more right to exist, the
> compiler could / should just generate the normal naive code.

Sure. That's a toolchain issue, which we don't always control.

In the case of CopyGuid() I would take some convincing that there was
a significant difference in performance across 16 bytes of cached
memory, performed occasionally.

But, if there was, we could do

--- a/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
+++ b/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
@@ -86,3 +86,4 @@ [Packages]
[BuildOptions]
   MSFT:*_*_*_CC_FLAGS = /GL-
   MSFT:*_*_ARM_ASM_FLAGS = /oldit
+  GCC:RELEASE_*_*_CC_FLAGS = -O3

and let idiom recognition take care of inserting the optimised
versions in place of the naive ones.

> I don't mind the code movement, but I'd like to avoid using
> BaseCompilerIntrinsicsLib on IA32/X64. On those arches, I think it would
> only be an improvement if it had a configurable backend, similarly how
> CopyMem() is currently configurable.

With less than making CompilerIntrinsicLib *not* a BASE library
(urgh), we can't have *it* depending on platform-specific optimised
versions.

The comment about IA32/X64 was more about the few instances we've seen
where new code has broken them due to things like dividing 64-bit
values withouy function calls, and how in the future it might make
sense catching that in other ways.

> ... I guess I've gotten very used to calling CopyMem(), in place of
> structure assignment.

Basically, I don't think having to learn a new dialect of C is
consistent with lowering the barrier of entry to the project.

Regards,

Leif

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55831): https://edk2.groups.io/g/devel/message/55831
Mute This Topic: https://groups.io/mt/71671270/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 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

[Andrew Fish via Groups.Io]

> On Mar 12, 2020, at 12:36 PM, Laszlo Ersek  wrote:
> 
> On 03/12/20 15:03, Leif Lindholm wrote:
>> +Ard, Laszlo.
>> 
>> I think it would make sense to move it to MdeModulePkg (or MdePkg) and
>> rename it BaseCompilerIntrinsicsLib (it *is* a BASE library).
>> 
>> As I alluded in my reply to Ray - x86 also have this problem, but to a
>> lesser extent, and ended up creating library functions to call instead
>> of using plain C for certain operations.
>> Which was probably the right decision when it was restricted to a
>> very few corner cases.
> 
> I think people that are interested in IA32/X64 are happier with explicit
> CopyMem() calls that are optimized (via one of the several BaseMemoryLib
> instances, such as SSE2, REP + string instructions, MMX, "smart"
> (chunked) C code, etc), than with a naive loop, such as the one in
> "ArmPkg/Library/CompilerIntrinsicsLib/memcpy.c", that gets silently
> plugged into an intrinsic (such as a structure assignment).
> 
> I mean, compiler intrinsics exist in the first place because they
> implement language features in a fast / performant manner, behind the
> scenes. If we replace the internals of an intrinsic with a slow / naive
> implementation, then the intrinsic has no more right to exist, the
> compiler could / should just generate the normal naive code.
> 
> I don't mind the code movement, but I'd like to avoid using
> BaseCompilerIntrinsicsLib on IA32/X64. On those arches, I think it would
> only be an improvement if it had a configurable backend, similarly how
> CopyMem() is currently configurable.
> 
> ... I guess I've gotten very used to calling CopyMem(), in place of
> structure assignment.
> 

Laszlo,

My brain has flipped too. 

For x86 I find smaller structure assignments can cause the optimizer to 
optimize away the memcpy/memset and you only see issue issues on a NOOPT build 
since DEBUG builds tend to be size optimized. I tend to hit  this issue when I 
try to turn off optimizations to try and walk vendor code in the debugger. So 
code review is the 1st line of defense. 

Thanks,

Andrew Fish


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55830): https://edk2.groups.io/g/devel/message/55830
Mute This Topic: https://groups.io/mt/71671270/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 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

[Laszlo Ersek]

On 03/12/20 15:44, Leif Lindholm wrote:
> And what would you propose we do the next time the RISC-V toolchain
> generates a memcpy call based on some other completely valid change to
> core code?

We could choose to enable the intrinsics library for RISC-V at that point.

IIUC, the CreateDeviceManagerForm() code in question did break an edk2
rule ("don't use structure assignment") *prior* to commit 64a228f5f893.
The rule violation was in commit 32465d9ae7ee; RISC-V only exposed it.
This doesn't seem uncharted territory.

Thanks
Laszlo

> Doing this de-risks the RISC-V upstreaming effort.
> It's also a trivial move/rename opetation - the only question is where
> the library should live and be called.
> 
> /
> Leif
> 
> On Thu, Mar 12, 2020 at 14:33:27 +, Chang, Abner (HPS SW/FW Technologist) 
> wrote:
>> I don't prefer to do this at this moment, Leif. I have no problem if
>> we create a BZ for this and create BaseCompilerIntrinsicsLib in
>> MdeModulePkg, but please don't bind it with RISC-V EDK2 port. You
>> know my concern pretty well, we can't hold those RISC-V patches on
>> hands like forever and address the code structure optimization. We
>> can still work on BaseCompilerIntrinsicsLib but not part of this
>> RISC-V submission. We can implement RISC-V variant if necessary
>> after RISC-V edk2 get in edk2 master.
>>
>> Abner
>>
>>> -Original Message-
>>> From: Leif Lindholm [mailto:l...@nuviainc.com]
>>> Sent: Thursday, March 12, 2020 10:03 PM
>>> To: Schaefer, Daniel (DualStudy) 
>>> Cc: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
>>> ; Chen, Gilbert ;
>>> af...@apple.com; michael.d.kin...@intel.com; p...@akeo.ie; Ard
>>> Biesheuvel ; Laszlo Ersek 
>>> Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem
>>> instead of GUID assignment
>>>
>>> +Ard, Laszlo.
>>>
>>> I think it would make sense to move it to MdeModulePkg (or MdePkg) and
>>> rename it BaseCompilerIntrinsicsLib (it *is* a BASE library).
>>>
>>> As I alluded in my reply to Ray - x86 also have this problem, but to a 
>>> lesser
>>> extent, and ended up creating library functions to call instead of using 
>>> plain C
>>> for certain operations.
>>> Which was probably the right decision when it was restricted to a very few
>>> corner cases.
>>>
>>> /
>>> Leif
>>>
>>> On Thu, Mar 12, 2020 at 13:24:30 +, Schaefer, Daniel (DualStudy) wrote:
 Hi Leif,

 you're right. If I revert my commit and include
   NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
 without making any changes to it, the build succeeds.

 What do others think? (cc Michael, Pete, Andrew, Ard, who have made
 changes to this module) Is this a big hack or should we use it in RISC-V, 
 too
>>> and move the module to MdeModulePkg?
 Why isn't this a problem on x86? Was it fine on Itanium?

 - Daniel

 
 From: devel@edk2.groups.io
  on behalf of Leif
 Lindholm 
 Sent: Thursday, March 12, 2020 11:55
 To: devel@edk2.groups.io
 ; Schaefer, Daniel
 (DualStudy)
>>> 
 Cc: Chang, Abner (HPS SW/FW Technologist)
 ; Chen, Gilbert
 ; Dandan Bi
 ; Eric Dong
 
 Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem
 instead of GUID assignment

 Hi Daniel,

 There is nothing wrong with this patch that just went in (and I should
 have called out sooner if I wanted to stop it), but I think a better
 solution is to implement a RISC-V variant of
 ArmPkg/Library/CompilerIntrinsicsLib/.

 It is perfectly valid for the compiler to generate memcpy calls in
 response to struct operations that are perfectly valid C.

 In fact, we could consider moving the ArmPkg one over into
 MdeModulePkg. I have a feeling that including a
   NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
 in your current build would be an alternative solution to your
 compilation error.

 /
 Leif

 On Mon, Mar 02, 2020 at 11:32:38 +0100, Daniel Schaefer wrote:
> GCC translates a simple assignment to memcpy, which EDKII doesn't
>>> provide.
> See:
> INVALID URI REMOVED
>>> 2Darch
> ive.com_edk2-2Ddevel-
>>> 40lists.01.org_msg11928.html&d=DwIBAg&c=C5b8zRQ
>
>>> O1miGmBeVZ2LFWg&r=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3
>>> E&m=wjlf
>
>>> QYZsXfc5WWDFmywLOEYlCKvrpYrnaXMIpJcLK7U&s=426yv7VvgHTtgtYaR0f0X
>>> NiaEA
> LgqZkxektjywEwPco&e=
>
> REF:INVALID URI REMOVED
> anocore.org_show-5Fbug.cgi-3Fid-
>>> 3D2547&d=DwIBAg&c=C5b8zRQO1miGmBeVZ2
>
>>> LFWg&r=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A

Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

[Laszlo Ersek]

On 03/12/20 15:03, Leif Lindholm wrote:
> +Ard, Laszlo.
> 
> I think it would make sense to move it to MdeModulePkg (or MdePkg) and
> rename it BaseCompilerIntrinsicsLib (it *is* a BASE library).
> 
> As I alluded in my reply to Ray - x86 also have this problem, but to a
> lesser extent, and ended up creating library functions to call instead
> of using plain C for certain operations.
> Which was probably the right decision when it was restricted to a
> very few corner cases.

I think people that are interested in IA32/X64 are happier with explicit
CopyMem() calls that are optimized (via one of the several BaseMemoryLib
instances, such as SSE2, REP + string instructions, MMX, "smart"
(chunked) C code, etc), than with a naive loop, such as the one in
"ArmPkg/Library/CompilerIntrinsicsLib/memcpy.c", that gets silently
plugged into an intrinsic (such as a structure assignment).

I mean, compiler intrinsics exist in the first place because they
implement language features in a fast / performant manner, behind the
scenes. If we replace the internals of an intrinsic with a slow / naive
implementation, then the intrinsic has no more right to exist, the
compiler could / should just generate the normal naive code.

I don't mind the code movement, but I'd like to avoid using
BaseCompilerIntrinsicsLib on IA32/X64. On those arches, I think it would
only be an improvement if it had a configurable backend, similarly how
CopyMem() is currently configurable.

... I guess I've gotten very used to calling CopyMem(), in place of
structure assignment.

Thanks
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55828): https://edk2.groups.io/g/devel/message/55828
Mute This Topic: https://groups.io/mt/71671270/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Extend TianoCore Bug Triage - APAC / NAMO Meeting from 0.5 hour to 1 hour

[Kevin@Insyde]

That conflicts for me for the first 30 minutes 

Kevin D Davis
Security Strategist
Insyde Software
Phone: 503-310-

> On Mar 12, 2020, at 9:29 AM, Gao, Liming  wrote:
> 
> 
> Hi, all
>   Recently, regular TianoCore Bug Triage meeting has no enough time to review 
> and discuss the existing bugzillas. I would propose to extend this meeting 
> from 0.5 hour to 1 hour. Now, Bug Triage, Tiano Design and Community meeting 
> are all in one day. I have met some conflict to those meeting. Some people 
> may also have the conflict. So, I suggest to move TianoCore Bug Triage - APAC 
> / NAMO Meeting to Wednesday morning 9:00AM ~ 10:00AM (UTC +8). If you have 
> comments, please reply this mail. If no more comments, I will set up the 
> first meeting from next week.
>
> Thanks
> Liming

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55827): https://edk2.groups.io/g/devel/message/55827
Mute This Topic: https://groups.io/mt/71903179/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] Features/Intel/Readme.md: Document meaning of "Complete" for features

[Oram, Isaac W]

Ray,

I don't think that this is a desirable rule.

I want to create feature packages that bundle frequently used together existing 
capabilities.  See the NetworkFeaturePkg for an example.  I also want to make 
feature packages for the USB stack, debug capabilities, and the like that are 
often aggregations of existing modules.

The Minimum Platform Architecture spec targets advanced features that are easy 
to enable for relatively inexperienced developers.  One way of doing that is to 
leverage the UEFI PI arch and its binary component support features.  The 
Minimum Platform Architecture aims to use this to enable a use case leveraging 
Firmware Volumes that looks like:
1:  Build NetworkFeaturePkg (this produces an FV, customized via PCD and/or 
static libraries as needed)
2:  Load FV (from shell, by injecting into an existing image using FMMT, Fiano, 
etc)
3:  Use network features and functionality

The model where the only way people extend a UEFI firmware image is by 
rebuilding a complete solution needs to end.  It is a misuse of the 
architecture in my estimation.  We have not had much success with fine 
granularity component binary use, i.e. individual PEIM and drivers.  Perhaps 
there is too much expertise needed.  Minimum Platform Architecture and Advanced 
Features aim to improve this by enabling larger granularity binary components 
that require less UEFI knowledge to use effectively.

I recognize that there is a competing vision that wants to make many small 
feature packages that are easy to build in or out based on simple PCD feature 
flags.  As that may improve developer's experience, it is not something I am 
strongly contesting.  However, I just don't see it as any different than 
MdeModulePkg.  It is the same strategy, just using packages to organize instead 
of directories.

The other consideration should include that we have a lot of existing users.  I 
don't want to move existing code around to make usable features.  If we move 
existing code to create the feature in the first place, we affect all the 
existing users, often for no immediate benefit.  If features become successful 
and widely used, then is a good time to refactor the code.  The difference is 
that at that time, the change is essentially behind an abstraction and so the 
change doesn't cause as much pointless work.

Regards,
Isaac


-Original Message-
From: Ray Ni  
Sent: Thursday, March 12, 2020 5:41 AM
To: devel@edk2.groups.io
Cc: Ni, Ray ; Dong, Eric ; Chan, Amy 
; Chaganty, Rangasai V ; 
Oram, Isaac W 
Subject: [PATCH] Features/Intel/Readme.md: Document meaning of "Complete" for 
features

Today's document doesn't forbidden creation of a feature package with only 
interfaces and no code to implement the interfaces. Such feature package is 
useless.

Signed-off-by: Ray Ni 
Cc: Eric Dong 
Cc: Amy Chan 
Cc: Rangasai V Chaganty 
Cc: Isaac W Oram 
---
 Features/Intel/Readme.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Features/Intel/Readme.md b/Features/Intel/Readme.md index 
9729f90a41..f0923e3d56 100644
--- a/Features/Intel/Readme.md
+++ b/Features/Intel/Readme.md
@@ -18,7 +18,7 @@ document as needed.
 Advanced features should be:
 * _Cohesive_, the feature should not contain any functionality unrelated to 
the feature.
 * _Complete_, the feature must have a complete design that minimizes 
dependencies. A feature package cannot directly
-  depend on another feature package.
+  depend on another feature package. A feature package must contain module(s) 
to implement the feature interfaces.
 * _Easy to Integrate_, the feature should expose well-defined software 
interfaces to use and configure the feature.
   * It should also present a set of simple and well-documented standard EDK II 
configuration options such as PCDs to
   configure the feature.
--
2.21.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55826): https://edk2.groups.io/g/devel/message/55826
Mute This Topic: https://groups.io/mt/71904631/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 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

[Leif Lindholm]

For clarity, I'm suggesting *I* take care of moving this into a
generic Intrinsics handling lib, and that HPE take care of including
and using it.

I'm also not suggesting we revert the CopyMem patch before that is
complete.

On Thu, Mar 12, 2020 at 14:44:52 +, Leif Lindholm wrote:
> And what would you propose we do the next time the RISC-V toolchain
> generates a memcpy call based on some other completely valid change to
> core code?
> 
> Doing this de-risks the RISC-V upstreaming effort.
> It's also a trivial move/rename opetation - the only question is where
> the library should live and be called.
> 
> /
> Leif
> 
> On Thu, Mar 12, 2020 at 14:33:27 +, Chang, Abner (HPS SW/FW Technologist) 
> wrote:
> > I don't prefer to do this at this moment, Leif. I have no problem if
> > we create a BZ for this and create BaseCompilerIntrinsicsLib in
> > MdeModulePkg, but please don't bind it with RISC-V EDK2 port. You
> > know my concern pretty well, we can't hold those RISC-V patches on
> > hands like forever and address the code structure optimization. We
> > can still work on BaseCompilerIntrinsicsLib but not part of this
> > RISC-V submission. We can implement RISC-V variant if necessary
> > after RISC-V edk2 get in edk2 master.
> > 
> > Abner
> > 
> > > -Original Message-
> > > From: Leif Lindholm [mailto:l...@nuviainc.com]
> > > Sent: Thursday, March 12, 2020 10:03 PM
> > > To: Schaefer, Daniel (DualStudy) 
> > > Cc: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
> > > ; Chen, Gilbert ;
> > > af...@apple.com; michael.d.kin...@intel.com; p...@akeo.ie; Ard
> > > Biesheuvel ; Laszlo Ersek 
> > > Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem
> > > instead of GUID assignment
> > > 
> > > +Ard, Laszlo.
> > > 
> > > I think it would make sense to move it to MdeModulePkg (or MdePkg) and
> > > rename it BaseCompilerIntrinsicsLib (it *is* a BASE library).
> > > 
> > > As I alluded in my reply to Ray - x86 also have this problem, but to a 
> > > lesser
> > > extent, and ended up creating library functions to call instead of using 
> > > plain C
> > > for certain operations.
> > > Which was probably the right decision when it was restricted to a very few
> > > corner cases.
> > > 
> > > /
> > > Leif
> > > 
> > > On Thu, Mar 12, 2020 at 13:24:30 +, Schaefer, Daniel (DualStudy) 
> > > wrote:
> > > > Hi Leif,
> > > >
> > > > you're right. If I revert my commit and include
> > > >   NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> > > > without making any changes to it, the build succeeds.
> > > >
> > > > What do others think? (cc Michael, Pete, Andrew, Ard, who have made
> > > > changes to this module) Is this a big hack or should we use it in 
> > > > RISC-V, too
> > > and move the module to MdeModulePkg?
> > > > Why isn't this a problem on x86? Was it fine on Itanium?
> > > >
> > > > - Daniel
> > > >
> > > > 
> > > > From: devel@edk2.groups.io
> > > >  on behalf of Leif
> > > > Lindholm 
> > > > Sent: Thursday, March 12, 2020 11:55
> > > > To: devel@edk2.groups.io
> > > > ; Schaefer, Daniel
> > > > (DualStudy)
> > > 
> > > > Cc: Chang, Abner (HPS SW/FW Technologist)
> > > > ; Chen, Gilbert
> > > > ; Dandan Bi
> > > > ; Eric Dong
> > > > 
> > > > Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem
> > > > instead of GUID assignment
> > > >
> > > > Hi Daniel,
> > > >
> > > > There is nothing wrong with this patch that just went in (and I should
> > > > have called out sooner if I wanted to stop it), but I think a better
> > > > solution is to implement a RISC-V variant of
> > > > ArmPkg/Library/CompilerIntrinsicsLib/.
> > > >
> > > > It is perfectly valid for the compiler to generate memcpy calls in
> > > > response to struct operations that are perfectly valid C.
> > > >
> > > > In fact, we could consider moving the ArmPkg one over into
> > > > MdeModulePkg. I have a feeling that including a
> > > >   NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> > > > in your current build would be an alternative solution to your
> > > > compilation error.
> > > >
> > > > /
> > > > Leif
> > > >
> > > > On Mon, Mar 02, 2020 at 11:32:38 +0100, Daniel Schaefer wrote:
> > > > > GCC translates a simple assignment to memcpy, which EDKII doesn't
> > > provide.
> > > > > See:
> > > > > INVALID URI REMOVED
> > > 2Darch
> > > > > ive.com_edk2-2Ddevel-
> > > 40lists.01.org_msg11928.html&d=DwIBAg&c=C5b8zRQ
> > > > >
> > > O1miGmBeVZ2LFWg&r=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3
> > > E&m=wjlf
> > > > >
> > > QYZsXfc5WWDFmywLOEYlCKvrpYrnaXMIpJcLK7U&s=426yv7VvgHTtgtYaR0f0X
> > > NiaEA
> > > > > LgqZkxektjywEwPco

Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

[Leif Lindholm]

And what would you propose we do the next time the RISC-V toolchain
generates a memcpy call based on some other completely valid change to
core code?

Doing this de-risks the RISC-V upstreaming effort.
It's also a trivial move/rename opetation - the only question is where
the library should live and be called.

/
Leif

On Thu, Mar 12, 2020 at 14:33:27 +, Chang, Abner (HPS SW/FW Technologist) 
wrote:
> I don't prefer to do this at this moment, Leif. I have no problem if
> we create a BZ for this and create BaseCompilerIntrinsicsLib in
> MdeModulePkg, but please don't bind it with RISC-V EDK2 port. You
> know my concern pretty well, we can't hold those RISC-V patches on
> hands like forever and address the code structure optimization. We
> can still work on BaseCompilerIntrinsicsLib but not part of this
> RISC-V submission. We can implement RISC-V variant if necessary
> after RISC-V edk2 get in edk2 master.
> 
> Abner
> 
> > -Original Message-
> > From: Leif Lindholm [mailto:l...@nuviainc.com]
> > Sent: Thursday, March 12, 2020 10:03 PM
> > To: Schaefer, Daniel (DualStudy) 
> > Cc: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
> > ; Chen, Gilbert ;
> > af...@apple.com; michael.d.kin...@intel.com; p...@akeo.ie; Ard
> > Biesheuvel ; Laszlo Ersek 
> > Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem
> > instead of GUID assignment
> > 
> > +Ard, Laszlo.
> > 
> > I think it would make sense to move it to MdeModulePkg (or MdePkg) and
> > rename it BaseCompilerIntrinsicsLib (it *is* a BASE library).
> > 
> > As I alluded in my reply to Ray - x86 also have this problem, but to a 
> > lesser
> > extent, and ended up creating library functions to call instead of using 
> > plain C
> > for certain operations.
> > Which was probably the right decision when it was restricted to a very few
> > corner cases.
> > 
> > /
> > Leif
> > 
> > On Thu, Mar 12, 2020 at 13:24:30 +, Schaefer, Daniel (DualStudy) wrote:
> > > Hi Leif,
> > >
> > > you're right. If I revert my commit and include
> > >   NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> > > without making any changes to it, the build succeeds.
> > >
> > > What do others think? (cc Michael, Pete, Andrew, Ard, who have made
> > > changes to this module) Is this a big hack or should we use it in RISC-V, 
> > > too
> > and move the module to MdeModulePkg?
> > > Why isn't this a problem on x86? Was it fine on Itanium?
> > >
> > > - Daniel
> > >
> > > 
> > > From: devel@edk2.groups.io
> > >  on behalf of Leif
> > > Lindholm 
> > > Sent: Thursday, March 12, 2020 11:55
> > > To: devel@edk2.groups.io
> > > ; Schaefer, Daniel
> > > (DualStudy)
> > 
> > > Cc: Chang, Abner (HPS SW/FW Technologist)
> > > ; Chen, Gilbert
> > > ; Dandan Bi
> > > ; Eric Dong
> > > 
> > > Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem
> > > instead of GUID assignment
> > >
> > > Hi Daniel,
> > >
> > > There is nothing wrong with this patch that just went in (and I should
> > > have called out sooner if I wanted to stop it), but I think a better
> > > solution is to implement a RISC-V variant of
> > > ArmPkg/Library/CompilerIntrinsicsLib/.
> > >
> > > It is perfectly valid for the compiler to generate memcpy calls in
> > > response to struct operations that are perfectly valid C.
> > >
> > > In fact, we could consider moving the ArmPkg one over into
> > > MdeModulePkg. I have a feeling that including a
> > >   NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> > > in your current build would be an alternative solution to your
> > > compilation error.
> > >
> > > /
> > > Leif
> > >
> > > On Mon, Mar 02, 2020 at 11:32:38 +0100, Daniel Schaefer wrote:
> > > > GCC translates a simple assignment to memcpy, which EDKII doesn't
> > provide.
> > > > See:
> > > > INVALID URI REMOVED
> > 2Darch
> > > > ive.com_edk2-2Ddevel-
> > 40lists.01.org_msg11928.html&d=DwIBAg&c=C5b8zRQ
> > > >
> > O1miGmBeVZ2LFWg&r=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3
> > E&m=wjlf
> > > >
> > QYZsXfc5WWDFmywLOEYlCKvrpYrnaXMIpJcLK7U&s=426yv7VvgHTtgtYaR0f0X
> > NiaEA
> > > > LgqZkxektjywEwPco&e=
> > > >
> > > > REF:INVALID URI REMOVED
> > > > anocore.org_show-5Fbug.cgi-3Fid-
> > 3D2547&d=DwIBAg&c=C5b8zRQO1miGmBeVZ2
> > > >
> > LFWg&r=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E&m=wjlfQYZsX
> > fc5WWD
> > > > FmywLOEYlCKvrpYrnaXMIpJcLK7U&s=PjC_mIwh0GhNy5np2h7K8l4l-
> > pLLBWt1FRuLB
> > > > UbULpc&e=
> > > >
> > > > Signed-off-by: Daniel Schaefer
> > > > 
> > > > Cc: Abner Chang
> > 
> > > > Cc: Gilbert Chen
> > 
> > > > Cc: 

[edk2-devel] [edk2-platforms][PATCH 3/8] Platform/ARM/SgiPkg: move common platform description to SSDT

[Aditya Angadi]

Move common platform description entries in platfrom specific DSDT to
a SSDT that can be reused on all SGI/RD platforms.

Signed-off-by: Aditya Angadi 
---
 .../ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl   | 70 +--
 .../SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf  |  3 +-
 .../ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl   | 69 +-
 .../SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf  |  3 +-
 .../AcpiTables/RdN1EdgeX2AcpiTables.inf   |  1 +
 Platform/ARM/SgiPkg/AcpiTables/SsdtRos.asl| 90 +++
 6 files changed, 97 insertions(+), 139 deletions(-)
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SsdtRos.asl

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl 
b/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl
index 5583e61097..d66c7cbf41 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl
@@ -1,7 +1,7 @@
 /** @file
 *  Differentiated System Description Table Fields (DSDT)
 *
-*  Copyright (c) 2018, ARM Ltd. All rights reserved.
+*  Copyright (c) 2018-2020, ARM Ltd. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -208,73 +208,5 @@ DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "ARMLTD", 
"ARMSGI",
   Name (_STA, 0xF)
 }
 
-// UART PL011
-Device (COM0) {
-  Name (_HID, "ARMH0011")
-  Name (_CID, "ARMH0011")
-  Name (_UID, Zero)
-  Name (_STA, 0xF)
-  Name (_CRS, ResourceTemplate() {
-Memory32Fixed (
-  ReadWrite,
-  FixedPcdGet64 (PcdSerialDbgRegisterBase),
-  0x1000
-)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { 147 }
-  })
-}
-
-// SMSC 91C111
-Device (ETH0) {
-  Name (_HID, "LNRO0003")
-  Name (_UID, Zero)
-  Name (_STA, 0xF)
-  Name (_CRS, ResourceTemplate() {
-Memory32Fixed (ReadWrite, 0x1800, 0x1000)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { 111 }
-  })
-  Name (_DSD, Package() {
-ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
-Package () {
-  Package (2) {"reg-io-width", 4 },
-}
-  })
-}
-
-// VIRTIO DISK
-Device (VR00) {
-  Name (_HID, "LNRO0005")
-  Name (_UID, 0)
-  Name (_CCA, 1)// mark the device coherent
-
-  Name (_CRS, ResourceTemplate() {
-Memory32Fixed (
-  ReadWrite,
-  FixedPcdGet32 (PcdVirtioBlkBaseAddress),
-  FixedPcdGet32 (PcdVirtioBlkSize)
-)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) {
-  FixedPcdGet32 (PcdVirtioBlkInterrupt)
-}
-  })
-}
-
-// VIRTIO NET
-Device (VR01) {
-  Name (_HID, "LNRO0005")
-  Name (_UID, 1)
-  Name (_CCA, 1)// mark the device coherent
-
-  Name (_CRS, ResourceTemplate() {
-Memory32Fixed (
-  ReadWrite,
-  FixedPcdGet32 (PcdVirtioNetBaseAddress),
-  FixedPcdGet32 (PcdVirtioNetSize)
-)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) {
-  FixedPcdGet32 (PcdVirtioNetInterrupt)
-}
-  })
-}
   } // Scope(_SB)
 }
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf 
b/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf
index 3a4d4e7b95..b08d7c2df5 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf
@@ -1,7 +1,7 @@
 ## @file
 #  ACPI table data and ASL sources required to boot the platform.
 #
-#  Copyright (c) 2018, ARM Ltd. All rights reserved.
+#  Copyright (c) 2018-2020, ARM Ltd. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -16,6 +16,7 @@
 
 [Sources]
   Dbg2.aslc
+  SsdtRos.asl
   Fadt.aslc
   Gtdt.aslc
   Iort.aslc
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl 
b/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl
index 45316d5005..cb05eed358 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl
@@ -1,7 +1,7 @@
 /** @file
 *  Differentiated System Description Table Fields (DSDT)
 *
-*  Copyright (c) 2018, ARM Ltd. All rights reserved.
+*  Copyright (c) 2018-2020, ARM Ltd. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -62,72 +62,5 @@ DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "ARMLTD", 
"ARMSGI",
   Name (_STA, 0xF)
 }
 
-// UART PL011
-Device (COM0) {
-  Name (_HID, "ARMH0011")
-  Name (_CID, "ARMH0011")
-  Name (_UID, Zero)
-  Name (_STA, 0xF)
-  Name (_CRS, ResourceTemplate () {
-Memory32Fixed (
-  ReadWrite,
-  FixedPcdGet64 (PcdSerialDbgRegisterBase),
-  0x1000
-  )
-Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { 147 }
-  })
-}
-
-// SMSC 91C111
-Device (ETH0) {
-  Name (_HID, "LNRO0003")
-  Name (_UID, Zero)
-  Name (_STA, 0xF

[edk2-devel] [edk2-platforms][PATCH 5/8] Platform/ARM/SgiPkg: Add ACPI tables for Rd-Daniel Config-M

[Aditya Angadi]

Add Madt and Dsdt ACPI tables for RD-Daniel Config-M platform.

Signed-off-by: Aditya Angadi 
---
 .../SgiPkg/AcpiTables/RdDanielCfgM/Dsdt.asl   | 118 +++
 .../SgiPkg/AcpiTables/RdDanielCfgM/Madt.aslc  | 134 ++
 .../AcpiTables/RdDanielCfgMAcpiTables.inf |  63 
 Platform/ARM/SgiPkg/SgiPlatform.dec   |   1 +
 Platform/ARM/SgiPkg/SgiPlatform.dsc   |   1 +
 Platform/ARM/SgiPkg/SgiPlatform.fdf   |   1 +
 6 files changed, 318 insertions(+)
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Dsdt.asl
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Madt.aslc
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgMAcpiTables.inf

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Dsdt.asl 
b/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Dsdt.asl
new file mode 100644
index 00..57873ef5cf
--- /dev/null
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Dsdt.asl
@@ -0,0 +1,118 @@
+/** @file
+*  Differentiated System Description Table Fields (DSDT)
+*
+*  Copyright (c) 2020, ARM Ltd. All rights reserved.
+*
+*  This program and the accompanying materials are licensed and made available
+*  under the terms and conditions of the BSD License which accompanies this
+*  distribution.  The full text of the license may be found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+
+#include "SgiPlatform.h"
+#include "SgiAcpiHeader.h"
+
+DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "ARMLTD", "ARMSGI",
+ EFI_ACPI_ARM_OEM_REVISION) {
+  Scope (_SB) {
+Device (CP00) { // Zeus core 0
+  Name (_HID, "ACPI0007")
+  Name (_UID, 0)
+  Name (_STA, 0xF)
+}
+
+Device (CP01) { // Zeus core 1
+  Name (_HID, "ACPI0007")
+  Name (_UID, 1)
+  Name (_STA, 0xF)
+}
+
+Device (CP02) { // Zeus core 2
+  Name (_HID, "ACPI0007")
+  Name (_UID, 2)
+  Name (_STA, 0xF)
+}
+
+Device (CP03) { // Zeus core 3
+  Name (_HID, "ACPI0007")
+  Name (_UID, 3)
+  Name (_STA, 0xF)
+}
+
+Device (CP04) { // Zeus core 4
+  Name (_HID, "ACPI0007")
+  Name (_UID, 4)
+  Name (_STA, 0xF)
+}
+
+Device (CP05) { // Zeus core 5
+  Name (_HID, "ACPI0007")
+  Name (_UID, 5)
+  Name (_STA, 0xF)
+}
+
+Device (CP06) { // Zeus core 6
+  Name (_HID, "ACPI0007")
+  Name (_UID, 6)
+  Name (_STA, 0xF)
+}
+
+Device (CP07) { // Zeus core 7
+  Name (_HID, "ACPI0007")
+  Name (_UID, 7)
+  Name (_STA, 0xF)
+}
+
+Device (CP08) { // Zeus core 8
+  Name (_HID, "ACPI0007")
+  Name (_UID, 8)
+  Name (_STA, 0xF)
+}
+
+   Device (CP09) { // Zeus core 9
+  Name (_HID, "ACPI0007")
+  Name (_UID, 9)
+  Name (_STA, 0xF)
+}
+
+   Device (CP10) { // Zeus core 10
+  Name (_HID, "ACPI0007")
+  Name (_UID, 10)
+  Name (_STA, 0xF)
+}
+
+   Device (CP11) { // Zeus core 11
+  Name (_HID, "ACPI0007")
+  Name (_UID, 11)
+  Name (_STA, 0xF)
+}
+
+Device (CP12) { // Zeus core 12
+  Name (_HID, "ACPI0007")
+  Name (_UID, 12)
+  Name (_STA, 0xF)
+}
+
+   Device (CP13) { // Zeus core 13
+  Name (_HID, "ACPI0007")
+  Name (_UID, 13)
+  Name (_STA, 0xF)
+}
+
+   Device (CP14) { // Zeus core 14
+  Name (_HID, "ACPI0007")
+  Name (_UID, 14)
+  Name (_STA, 0xF)
+}
+
+   Device (CP15) { // Zeus core 15
+  Name (_HID, "ACPI0007")
+  Name (_UID, 15)
+  Name (_STA, 0xF)
+}
+  } // Scope(_SB)
+}
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Madt.aslc 
b/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Madt.aslc
new file mode 100644
index 00..3027b8d223
--- /dev/null
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Madt.aslc
@@ -0,0 +1,134 @@
+/** @file
+*  Multiple APIC Description Table (MADT)
+*
+*  Copyright (c) 2020, ARM Limited. All rights reserved.
+*
+*  This program and the accompanying materials are licensed and made available
+*  under the terms and conditions of the BSD License which accompanies this
+*  distribution.  The full text of the license may be found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+
+#include "SgiPlatform.h"
+#include "SgiAcpiHeader.h"
+#include 
+#include 
+#include 
+#include 
+
+#define CLUSTER_COUNT   16
+#define CORES_PER_CLUSTER   1
+#define CORE_COUNT  (CLUSTER_COUNT * CORES_PER_CLUSTER)
+
+// Multiple APIC Description Table
+#pragma pack (1)
+
+typedef struct {
+  EFI_ACPI_6_2_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER   Header;
+  EFI_ACPI_6_2_GIC_STRUCTURE
GicInter

[edk2-devel] [edk2-platforms][PATCH 2/8] Platform/ARM/SgiPkg: move the GIC related ACPI helper macros

[Aditya Angadi]

Move the ACPI helper macros defines related to GIC structure,
distributor, redistributor and ITS to SgiAcpiHeader.h as these are
common across ARM SGI/RD platforms.

Signed-off-by: Aditya Angadi 
---
 .../ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc  | 68 +-
 .../ARM/SgiPkg/AcpiTables/RdN1Edge/Madt.aslc  | 68 +-
 .../SgiPkg/AcpiTables/RdN1EdgeX2/Madt.aslc| 57 +--
 Platform/ARM/SgiPkg/Include/SgiAcpiHeader.h   | 70 ++-
 4 files changed, 72 insertions(+), 191 deletions(-)

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc 
b/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc
index 48e7a61478..9872549285 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc
@@ -1,7 +1,7 @@
 /** @file
 *  Multiple APIC Description Table (MADT)
 *
-*  Copyright (c) 2018, ARM Limited. All rights reserved.
+*  Copyright (c) 2018-2020, ARM Limited. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -14,72 +14,6 @@
 #include 
 #include 
 
-// EFI_ACPI_6_2_GIC_STRUCTURE
-#define EFI_ACPI_6_2_GICC_STRUCTURE_INIT(GicId, AcpiCpuUid, Mpidr, Flags,  
\
-  PmuIrq, GicBase, GicVBase, GicHBase, GsivId, GicRBase, Efficiency)   
\
-  {
\
-EFI_ACPI_6_2_GIC, /* Type */   
\
-sizeof (EFI_ACPI_6_2_GIC_STRUCTURE),  /* Length */ 
\
-EFI_ACPI_RESERVED_WORD,   /* Reserved */   
\
-GicId,/* CPUInterfaceNumber */ 
\
-AcpiCpuUid,   /* AcpiProcessorUid */   
\
-Flags,/* Flags */  
\
-0,/* ParkingProtocolVersion */ 
\
-PmuIrq,   /* PerformanceInterruptGsiv */   
\
-0,/* ParkedAddress */  
\
-GicBase,  /* PhysicalBaseAddress */
\
-GicVBase, /* GICV */   
\
-GicHBase, /* GICH */   
\
-GsivId,   /* VGICMaintenanceInterrupt */   
\
-GicRBase, /* GICRBaseAddress */
\
-Mpidr,/* MPIDR */  
\
-Efficiency,   /* ProcessorPowerEfficiencyClass */  
\
-{  
\
-  EFI_ACPI_RESERVED_BYTE, /* Reserved2[0] */   
\
-  EFI_ACPI_RESERVED_BYTE, /* Reserved2[1] */   
\
-  EFI_ACPI_RESERVED_BYTE  /* Reserved2[2] */   
\
-}  
\
-  }
-
-// EFI_ACPI_6_2_GIC_DISTRIBUTOR_STRUCTURE
-#define EFI_ACPI_6_2_GIC_DISTRIBUTOR_INIT(GicDistHwId, GicDistBase,
\
-  GicDistVector, GicVersion)   
\
-  {
\
-EFI_ACPI_6_2_GICD,/* Type */   
\
-sizeof (EFI_ACPI_6_2_GIC_DISTRIBUTOR_STRUCTURE),   
\
-EFI_ACPI_RESERVED_WORD,   /* Reserved1 */  
\
-GicDistHwId,  /* GicId */  
\
-GicDistBase,  /* PhysicalBaseAddress */
\
-GicDistVector,/* SystemVectorBase */   
\
-GicVersion,   /* GicVersion */ 
\
-{  
\
-  EFI_ACPI_RESERVED_BYTE, /* Reserved2[0] */   
\
-  EFI_ACPI_RESERVED_BYTE, /* Reserved2[1] */   
\
-  EFI_ACPI_RESERVED_BYTE  /* Reserved2[2] */   
\
-}  
\
-  }
-
-// EFI_ACPI_6_2_GICR_STRUCTURE
-#define EFI_ACPI_6_2_GIC_REDISTRIBUTOR_INIT(RedisRegionAddr, RedisDiscLength)  
\
-  {
\
-EFI_ACPI_6_2_GICR,/* Type */   
\
-sizeof (EFI_ACPI_6_2_GICR_STRUCTURE), /* Length */ 
\
-EFI_ACPI_RESERVED_WORD,   /* Reserved */   
\
-RedisRegionAddr,  /* DiscoveryRangeBaseAddress */  
\
-RedisDiscLength   /* Discov

[edk2-devel] [edk2-platforms][PATCH 4/8] Platform/ARM/SgiPkg: remove PcdCoreCount and PcdClusterCount

[Aditya Angadi]

The number of CPUs depend on the SGI/RD platform. So instead of
defining a Fixed PCD to specify the value of core and cluster count,
let each platform define these values.

Signed-off-by: Aditya Angadi 
---
 Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc|  7 ++-
 .../ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf |  2 --
 Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Madt.aslc|  7 ---
 .../ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf |  2 --
 Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2/Madt.aslc  | 12 ++--
 .../ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf   |  2 --
 Platform/ARM/SgiPkg/AcpiTables/Sgi575/Madt.aslc  |  9 +
 Platform/ARM/SgiPkg/AcpiTables/Sgi575AcpiTables.inf  |  4 +---
 .../ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf   |  3 ---
 Platform/ARM/SgiPkg/SgiPlatform.dsc  |  4 
 10 files changed, 22 insertions(+), 30 deletions(-)

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc 
b/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc
index 9872549285..a9540f2e03 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc
@@ -14,12 +14,17 @@
 #include 
 #include 
 
+#define CLUSTER_COUNT 2
+#define CORES_PER_CLUSTER 8
+#define THREADS_PER_CORE  2
+#define CORE_COUNT(CLUSTER_COUNT * CORES_PER_CLUSTER * 
THREADS_PER_CORE)
+
 // Multiple APIC Description Table
 #pragma pack (1)
 
 typedef struct {
   EFI_ACPI_6_2_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER   Header;
-  EFI_ACPI_6_2_GIC_STRUCTUREGicInterfaces[32];
+  EFI_ACPI_6_2_GIC_STRUCTURE
GicInterfaces[CORE_COUNT];
   EFI_ACPI_6_2_GIC_DISTRIBUTOR_STRUCTUREGicDistributor;
   EFI_ACPI_6_2_GICR_STRUCTURE   GicRedistributor;
   EFI_ACPI_6_2_GIC_ITS_STRUCTUREGicIts;
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf 
b/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf
index b08d7c2df5..742ca9e683 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf
@@ -34,8 +34,6 @@
   Platform/ARM/SgiPkg/SgiPlatform.dec
 
 [FixedPcd]
-  gArmPlatformTokenSpaceGuid.PcdCoreCount
-  gArmPlatformTokenSpaceGuid.PcdClusterCount
   gArmPlatformTokenSpaceGuid.PcdSerialDbgRegisterBase
   gArmPlatformTokenSpaceGuid.PL011UartInterrupt
 
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Madt.aslc 
b/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Madt.aslc
index 05eb78c561..d8ec0ce421 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Madt.aslc
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Madt.aslc
@@ -14,15 +14,16 @@
 #include 
 #include 
 
-#define CORE_CNT   (FixedPcdGet32 (PcdClusterCount) * \
-FixedPcdGet32 (PcdCoreCount))
+#define CLUSTER_COUNT 2
+#define CORES_PER_CLUSTER 4
+#define CORE_COUNT(CLUSTER_COUNT * CORES_PER_CLUSTER)
 
 // Multiple APIC Description Table
 #pragma pack (1)
 
 typedef struct {
   EFI_ACPI_6_2_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER   Header;
-  EFI_ACPI_6_2_GIC_STRUCTURE
GicInterfaces[CORE_CNT];
+  EFI_ACPI_6_2_GIC_STRUCTURE
GicInterfaces[CORE_COUNT];
   EFI_ACPI_6_2_GIC_DISTRIBUTOR_STRUCTUREGicDistributor;
   EFI_ACPI_6_2_GICR_STRUCTURE   GicRedistributor;
   EFI_ACPI_6_2_GIC_ITS_STRUCTUREGicIts;
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf 
b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf
index 61b07bffcc..206479f942 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf
@@ -34,8 +34,6 @@
   Platform/ARM/SgiPkg/SgiPlatform.dec
 
 [FixedPcd]
-  gArmPlatformTokenSpaceGuid.PcdCoreCount
-  gArmPlatformTokenSpaceGuid.PcdClusterCount
   gArmPlatformTokenSpaceGuid.PcdSerialDbgRegisterBase
   gArmPlatformTokenSpaceGuid.PL011UartInterrupt
 
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2/Madt.aslc 
b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2/Madt.aslc
index 47368931e3..add9724374 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2/Madt.aslc
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2/Madt.aslc
@@ -14,19 +14,19 @@
 #include 
 #include 
 
-#define CORE_CNT   (FixedPcdGet32 (PcdClusterCount) * \
-FixedPcdGet32 (PcdCoreCount))
-
-#define CHIP_CNT   2
+#define CLUSTER_COUNT 2
+#define CORES_PER_CLUSTER 4
+#define CORE_COUNT(CLUSTER_COUNT * CORES_PER_CLUSTER)
+#define CHIP_COUNT   2
 
 // Multiple APIC Description Table
 #pragma pack (1)
 
 typedef struct {
   EFI_ACPI_6_2_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER  Header;
-  EFI_ACPI_6_2_GIC_STRUCTURE   GicInterfaces[CORE_CNT 
* CHIP_CN

[edk2-devel] [edk2-platforms][PATCH 6/8] Platform/ARM/Sgi: Add initial support for RD-Daniel Config-M platform

[Aditya Angadi]

Add information in the SGI platform descriptor HOB to pick the correct
ACPI table to install for RD-Daniel Config-M

Signed-off-by: Aditya Angadi 
---
 .../SgiPkg/Drivers/PlatformDxe/PlatformDxe.c  |  5 +++
 .../Drivers/PlatformDxe/PlatformDxe.inf   |  1 +
 Platform/ARM/SgiPkg/Include/SgiPlatform.h |  4 ++
 Platform/ARM/SgiPkg/RdDaniel.dsc  | 38 +++
 4 files changed, 48 insertions(+)
 create mode 100644 Platform/ARM/SgiPkg/RdDaniel.dsc

diff --git a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c 
b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
index 387397d745..7e0de765f7 100644
--- a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
+++ b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
@@ -46,6 +46,11 @@ STATIC SGI_PLATFORM_ACPI_TABLE_GUID_LOOKUP 
AcpiTableGuidLookup[] = {
   RD_E1_EDGE_CONF_ID,
   MULTI_CHIP_MODE_DISABLED,
   &gRdE1EdgeAcpiTablesFileGuid),
+  ACPI_GUID_LOOKUP (
+  RD_DANIEL_PART_NUM,
+  RD_DANIEL_CFGM_CONF_ID,
+  MULTI_CHIP_MODE_DISABLED,
+  &gRdDanielCfgMAcpiTablesFileGuid),
 };
 
 VOID
diff --git a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf 
b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
index 741dcc75ed..82569820b7 100644
--- a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
+++ b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
@@ -34,6 +34,7 @@
   gRdN1EdgeAcpiTablesFileGuid
   gRdN1EdgeX2AcpiTablesFileGuid
   gRdE1EdgeAcpiTablesFileGuid
+  gRdDanielCfgMAcpiTablesFileGuid
 
 [FeaturePcd]
   gArmSgiTokenSpaceGuid.PcdVirtioBlkSupported
diff --git a/Platform/ARM/SgiPkg/Include/SgiPlatform.h 
b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
index d87fb2b540..b6a427b8b6 100644
--- a/Platform/ARM/SgiPkg/Include/SgiPlatform.h
+++ b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
@@ -70,6 +70,10 @@
 #define RD_N1_EDGE_CONF_ID0x1
 #define RD_E1_EDGE_CONF_ID0x2
 
+//RDDANIEL Platform Identification values
+#define RD_DANIEL_PART_NUM0x78A
+#define RD_DANIEL_CFGM_CONF_ID0x1
+
 #define SGI_CONFIG_MASK   0x0F
 #define SGI_CONFIG_SHIFT  0x1C
 #define SGI_PART_NUM_MASK 0xFFF
diff --git a/Platform/ARM/SgiPkg/RdDaniel.dsc b/Platform/ARM/SgiPkg/RdDaniel.dsc
new file mode 100644
index 00..09607004ed
--- /dev/null
+++ b/Platform/ARM/SgiPkg/RdDaniel.dsc
@@ -0,0 +1,38 @@
+#
+#  Copyright (c) 2020, ARM Limited. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+[Defines]
+  PLATFORM_NAME  = ArmSgi
+  PLATFORM_GUID  = d301ac4e-0828-4cef-b754-34ca9b6781b5
+  PLATFORM_VERSION   = 0.1
+  DSC_SPECIFICATION  = 0x0001001B
+  OUTPUT_DIRECTORY   = Build/$(PLATFORM_NAME)
+  SUPPORTED_ARCHITECTURES= AARCH64|ARM
+  BUILD_TARGETS  = NOOPT|DEBUG|RELEASE
+  SKUID_IDENTIFIER   = DEFAULT
+  FLASH_DEFINITION   = Platform/ARM/SgiPkg/SgiPlatform.fdf
+  BUILD_NUMBER   = 1
+
+# include common definitions from SgiPlatform.dsc
+!include Platform/ARM/SgiPkg/SgiPlatform.dsc
+
+
+#
+# Pcd Section - list of all EDK II PCD Entries defined by this Platform
+#
+
+
+[PcdsFixedAtBuild.common]
+  # GIC Base Addresses
+  gArmTokenSpaceGuid.PcdGicDistributorBase|0x3000
+  gArmTokenSpaceGuid.PcdGicRedistributorsBase|0x3014
+  gArmSgiTokenSpaceGuid.PcdGicSize|0x20
+
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55821): https://edk2.groups.io/g/devel/message/55821
Mute This Topic: https://groups.io/mt/71903351/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH 7/8] Platform/ARM/SgiPkg: add ACPI tables for RD-Daniel Config-XLR

[Aditya Angadi]

RD-Daniel Config-XLR is a platform in which four identical chips are connected
via a high speed CCIX link. Add Madt and Dsdt tables for the same.

Signed-off-by: Aditya Angadi 
---
 .../SgiPkg/AcpiTables/RdDanielCfgXlr/Dsdt.asl | 125 +++
 .../AcpiTables/RdDanielCfgXlr/Madt.aslc   | 150 ++
 .../AcpiTables/RdDanielCfgXlrAcpiTables.inf   |  63 
 Platform/ARM/SgiPkg/SgiPlatform.dec   |   1 +
 Platform/ARM/SgiPkg/SgiPlatform.dsc   |   1 +
 Platform/ARM/SgiPkg/SgiPlatform.fdf   |   1 +
 6 files changed, 341 insertions(+)
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Dsdt.asl
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Madt.aslc
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlrAcpiTables.inf

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Dsdt.asl 
b/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Dsdt.asl
new file mode 100644
index 00..23ada55ec4
--- /dev/null
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Dsdt.asl
@@ -0,0 +1,125 @@
+/** @file
+*  Differentiated System Description Table Fields (DSDT)
+*
+*  Copyright (c) 2020, ARM Limited. All rights reserved.
+*
+*  This program and the accompanying materials are licensed and made available
+*  under the terms and conditions of the BSD License which accompanies this
+*  distribution.  The full text of the license may be found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+
+#include "SgiPlatform.h"
+#include "SgiAcpiHeader.h"
+
+DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "ARMLTD", "ARMSGI",
+ EFI_ACPI_ARM_OEM_REVISION) {
+  Scope (_SB) {
+
+Device (CP00) { // Zeus core 0
+  Name (_HID, "ACPI0007")
+  Name (_UID, 0)
+  Name (_STA, 0xF)
+}
+
+Device (CP01) { // Zeus core 1
+  Name (_HID, "ACPI0007")
+  Name (_UID, 1)
+  Name (_STA, 0xF)
+}
+
+Device (CP02) { // Zeus core 2
+  Name (_HID, "ACPI0007")
+  Name (_UID, 2)
+  Name (_STA, 0xF)
+}
+
+Device (CP03) { // Zeus core 3
+  Name (_HID, "ACPI0007")
+  Name (_UID, 3)
+  Name (_STA, 0xF)
+}
+
+Device (CP04) { // Zeus core 4
+  Name (_HID, "ACPI0007")
+  Name (_UID, 4)
+  Name (_STA, 0xF)
+}
+
+Device (CP05) { // Zeus core 5
+  Name (_HID, "ACPI0007")
+  Name (_UID, 5)
+  Name (_STA, 0xF)
+}
+
+Device (CP06) { // Zeus core 6
+  Name (_HID, "ACPI0007")
+  Name (_UID, 6)
+  Name (_STA, 0xF)
+}
+
+Device (CP07) { // Zeus core 7
+  Name (_HID, "ACPI0007")
+  Name (_UID, 7)
+  Name (_STA, 0xF)
+}
+
+Device (CP08) { // Zeus core 8
+  Name (_HID, "ACPI0007")
+  Name (_UID, 8)
+  Name (_STA, 0xF)
+}
+
+Device (CP09) { // Zeus core 9
+  Name (_HID, "ACPI0007")
+  Name (_UID, 9)
+  Name (_STA, 0xF)
+}
+
+Device (CP10) { // Zeus core 10
+  Name (_HID, "ACPI0007")
+  Name (_UID, 10)
+  Name (_STA, 0xF)
+}
+
+Device (CP11) { // Zeus core 11
+  Name (_HID, "ACPI0007")
+  Name (_UID, 11)
+  Name (_STA, 0xF)
+}
+
+Device (CP12) { // Zeus core 12
+  Name (_HID, "ACPI0007")
+  Name (_UID, 12)
+  Name (_STA, 0xF)
+}
+
+Device (CP13) { // Zeus core 13
+  Name (_HID, "ACPI0007")
+  Name (_UID, 13)
+  Name (_STA, 0xF)
+}
+
+Device (CP14) { // Zeus core 14
+  Name (_HID, "ACPI0007")
+  Name (_UID, 14)
+  Name (_STA, 0xF)
+}
+
+Device (CP15) { // Zeus core 15
+  Name (_HID, "ACPI0007")
+  Name (_UID, 15)
+  Name (_STA, 0xF)
+}
+
+Device (CP16) { // Zeus core 16
+  Name (_HID, "ACPI0007")
+  Name (_UID, 16)
+  Name (_STA, 0xF)
+}
+  } // Scope(_SB)
+}
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Madt.aslc 
b/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Madt.aslc
new file mode 100644
index 00..e3784b55f2
--- /dev/null
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Madt.aslc
@@ -0,0 +1,150 @@
+/** @file
+*  Multiple APIC Description Table (MADT)
+*
+*  Copyright (c) 2020, ARM Limited. All rights reserved.
+*
+*  This program and the accompanying materials are licensed and made available
+*  under the terms and conditions of the BSD License which accompanies this
+*  distribution.  The full text of the license may be found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+
+#include "SgiPlatform.h"
+#include "SgiAcpiHeader.h"
+#include 
+#include 
+#include 
+#include 
+
+#define CLUSTER_COUNT 4
+#define CORES_PER_CLUSTER 1
+#define CORE_COUNT 

[edk2-devel] [edk2-platforms][PATCH 0/8] Add platform support for RD-Daniel

[Aditya Angadi]

This patch series adds support for Arm's RD-Daniel platform. There are two
configurations of this platform being added in this series - Config-M and
Config-XLR. RD-Daniel is the next Arm's reference design subsystem.

The first four patches consolidate the code in SgiPkg in preparation for
adding support for the RD-Daniel platform. The next four patches add support
for the RD-Daniel platforms.

Aditya Angadi (7):
  Platform/ARM/SgiPkg: move the GIC related ACPI helper macros
  Platform/ARM/SgiPkg: move common platform description to SSDT
  Platform/ARM/SgiPkg: remove PcdCoreCount and PcdClusterCount
  Platform/ARM/SgiPkg: Add ACPI tables for Rd-Daniel Config-M
  Platform/ARM/Sgi: Add initial support for RD-Daniel Config-M platform
  Platform/ARM/SgiPkg: add ACPI tables for RD-Daniel Config-XLR
  Platform/ARM/Sgi: Add initial support for RD-Daniel Config-XLR platform

Vijayenthiran Subramaniam (1):
  Platform/ARM/SgiPkg: Create individual Platform Description File

 .../SgiPkg/AcpiTables/RdDanielCfgM/Dsdt.asl   | 118 ++
 .../SgiPkg/AcpiTables/RdDanielCfgM/Madt.aslc  | 134 
 .../AcpiTables/RdDanielCfgMAcpiTables.inf |  63 
 .../SgiPkg/AcpiTables/RdDanielCfgXlr/Dsdt.asl | 125 +++
 .../AcpiTables/RdDanielCfgXlr/Madt.aslc   | 150 ++
 .../AcpiTables/RdDanielCfgXlrAcpiTables.inf   |  63 
 .../ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl   |  70 +---
 .../ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc  |  73 +
 .../SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf  |   5 +-
 .../ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl   |  69 +---
 .../ARM/SgiPkg/AcpiTables/RdN1Edge/Madt.aslc  |  75 +
 .../SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf  |   5 +-
 .../SgiPkg/AcpiTables/RdN1EdgeX2/Madt.aslc|  69 +---
 .../AcpiTables/RdN1EdgeX2AcpiTables.inf   |   3 +-
 .../ARM/SgiPkg/AcpiTables/Sgi575/Madt.aslc|   9 +-
 .../SgiPkg/AcpiTables/Sgi575AcpiTables.inf|   4 +-
 Platform/ARM/SgiPkg/AcpiTables/SsdtRos.asl|  90 +++
 .../SgiPkg/Drivers/PlatformDxe/PlatformDxe.c  |  10 ++
 .../Drivers/PlatformDxe/PlatformDxe.inf   |   2 +
 Platform/ARM/SgiPkg/Include/SgiAcpiHeader.h   |  70 +++-
 Platform/ARM/SgiPkg/Include/SgiPlatform.h |  12 +-
 .../Library/PlatformLib/PlatformLib.inf   |   6 +-
 .../Library/PlatformLib/PlatformLibMem.c  |   8 +-
 Platform/ARM/SgiPkg/RdDaniel.dsc  |  38 +
 Platform/ARM/SgiPkg/RdE1Edge.dsc  |  37 +
 Platform/ARM/SgiPkg/RdN1Edge.dsc  |  37 +
 Platform/ARM/SgiPkg/Sgi575.dsc|  37 +
 Platform/ARM/SgiPkg/SgiPlatform.dec   |   7 +-
 Platform/ARM/SgiPkg/SgiPlatform.dsc   |  31 +---
 Platform/ARM/SgiPkg/SgiPlatform.fdf   |   2 +
 30 files changed, 1028 insertions(+), 394 deletions(-)
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Dsdt.asl
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Madt.aslc
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgMAcpiTables.inf
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Dsdt.asl
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Madt.aslc
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlrAcpiTables.inf
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SsdtRos.asl
 create mode 100644 Platform/ARM/SgiPkg/RdDaniel.dsc
 create mode 100644 Platform/ARM/SgiPkg/RdE1Edge.dsc
 create mode 100644 Platform/ARM/SgiPkg/RdN1Edge.dsc
 create mode 100644 Platform/ARM/SgiPkg/Sgi575.dsc

-- 
2.17.1




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55815): https://edk2.groups.io/g/devel/message/55815
Mute This Topic: https://groups.io/mt/71902045/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH 8/8] Platform/ARM/Sgi: Add initial support for RD-Daniel Config-XLR platform

[Aditya Angadi]

For RD-Daniel Config-XLR, use multichip mode information from the SGI
platform descriptor HOB to pick the correct ACPI table to be installed.

Signed-off-by: Aditya Angadi 
---
 Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c   | 5 +
 Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf | 1 +
 Platform/ARM/SgiPkg/Include/SgiPlatform.h   | 1 +
 3 files changed, 7 insertions(+)

diff --git a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c 
b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
index 7e0de765f7..b1f5714b93 100644
--- a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
+++ b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
@@ -51,6 +51,11 @@ STATIC SGI_PLATFORM_ACPI_TABLE_GUID_LOOKUP 
AcpiTableGuidLookup[] = {
   RD_DANIEL_CFGM_CONF_ID,
   MULTI_CHIP_MODE_DISABLED,
   &gRdDanielCfgMAcpiTablesFileGuid),
+  ACPI_GUID_LOOKUP (
+  RD_DANIEL_PART_NUM,
+  RD_DANIEL_CFGXLR_CONF_ID,
+  MULTI_CHIP_MODE_ENABLED,
+  &gRdDanielCfgXlrAcpiTablesFileGuid),
 };
 
 VOID
diff --git a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf 
b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
index 82569820b7..00cbe608c2 100644
--- a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
+++ b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
@@ -35,6 +35,7 @@
   gRdN1EdgeX2AcpiTablesFileGuid
   gRdE1EdgeAcpiTablesFileGuid
   gRdDanielCfgMAcpiTablesFileGuid
+  gRdDanielCfgXlrAcpiTablesFileGuid
 
 [FeaturePcd]
   gArmSgiTokenSpaceGuid.PcdVirtioBlkSupported
diff --git a/Platform/ARM/SgiPkg/Include/SgiPlatform.h 
b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
index b6a427b8b6..9822858f6e 100644
--- a/Platform/ARM/SgiPkg/Include/SgiPlatform.h
+++ b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
@@ -73,6 +73,7 @@
 //RDDANIEL Platform Identification values
 #define RD_DANIEL_PART_NUM0x78A
 #define RD_DANIEL_CFGM_CONF_ID0x1
+#define RD_DANIEL_CFGXLR_CONF_ID  0x2
 
 #define SGI_CONFIG_MASK   0x0F
 #define SGI_CONFIG_SHIFT  0x1C
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55823): https://edk2.groups.io/g/devel/message/55823
Mute This Topic: https://groups.io/mt/71903356/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH 1/8] Platform/ARM/SgiPkg: Create individual Platform Description File

[Aditya Angadi]

From: Vijayenthiran Subramaniam 

In preparation for adding support for Reference Design (RD) platforms
that have different base addresses for GIC distributor or redistributor,
create individual platform description files for all SGI/RD platforms
and move GIC related base addresses from the common SGI/RD platform
description file to individual platform description files.
The existing platform description is then included by individual
platform description files.

Signed-off-by: Vijayenthiran Subramaniam 
---
 Platform/ARM/SgiPkg/Include/SgiPlatform.h |  7 +---
 .../Library/PlatformLib/PlatformLib.inf   |  3 +-
 .../Library/PlatformLib/PlatformLibMem.c  |  8 ++--
 Platform/ARM/SgiPkg/RdE1Edge.dsc  | 37 +++
 Platform/ARM/SgiPkg/RdN1Edge.dsc  | 37 +++
 Platform/ARM/SgiPkg/Sgi575.dsc| 37 +++
 Platform/ARM/SgiPkg/SgiPlatform.dec   |  5 ++-
 Platform/ARM/SgiPkg/SgiPlatform.dsc   | 25 +
 8 files changed, 124 insertions(+), 35 deletions(-)
 create mode 100644 Platform/ARM/SgiPkg/RdE1Edge.dsc
 create mode 100644 Platform/ARM/SgiPkg/RdN1Edge.dsc
 create mode 100644 Platform/ARM/SgiPkg/Sgi575.dsc

diff --git a/Platform/ARM/SgiPkg/Include/SgiPlatform.h 
b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
index e36a412155..d87fb2b540 100644
--- a/Platform/ARM/SgiPkg/Include/SgiPlatform.h
+++ b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
@@ -1,6 +1,6 @@
 /** @file
 *
-*  Copyright (c) 2018, ARM Limited. All rights reserved.
+*  Copyright (c) 2018-2020, ARM Limited. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -45,11 +45,6 @@
 #define SGI_SUBSYS_GENERIC_WDOG_BASE  0x2A44
 #define SGI_SUBSYS_GENERIC_WDOG_SZSIZE_128KB
 
-// Sub System Peripherals - GIC
-#define SGI_SUBSYS_GENERIC_GIC_BASE   0x3000
-#define SGI_SUBSYS_GENERIC_GICR_BASE  0x300C
-#define SGI_SUBSYS_GENERIC_GIC_SZ SIZE_1MB
-
 // Expansion AXI - Platform Peripherals - HDLCD1
 #define SGI_EXP_PLAT_PERIPH_HDLCD1_BASE   0x7FF6
 #define SGI_EXP_PLAT_PERIPH_HDLCD1_SZ SIZE_64KB
diff --git a/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf 
b/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf
index 3db70e900d..a918afef5f 100644
--- a/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf
+++ b/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf
@@ -1,5 +1,5 @@
 #
-#  Copyright (c) 2018, ARM Limited. All rights reserved.
+#  Copyright (c) 2018-2020, ARM Limited. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -42,6 +42,7 @@
 
   gArmSgiTokenSpaceGuid.PcdDramBlock2Base
   gArmSgiTokenSpaceGuid.PcdDramBlock2Size
+  gArmSgiTokenSpaceGuid.PcdGicSize
 
   gArmTokenSpaceGuid.PcdSystemMemoryBase
   gArmTokenSpaceGuid.PcdSystemMemorySize
diff --git a/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLibMem.c 
b/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLibMem.c
index 845aeaf4dd..8d0ad4ec9c 100644
--- a/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLibMem.c
+++ b/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLibMem.c
@@ -1,6 +1,6 @@
 /** @file
 *
-*  Copyright (c) 2018, ARM Limited. All rights reserved.
+*  Copyright (c) 2018-2020, ARM Limited. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -93,9 +93,9 @@ ArmPlatformGetVirtualMemoryMap (
   VirtualMemoryTable[Index].Attributes  = 
ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
 
   // Sub System Peripherals - GIC-600
-  VirtualMemoryTable[++Index].PhysicalBase  = SGI_SUBSYS_GENERIC_GIC_BASE;
-  VirtualMemoryTable[Index].VirtualBase = SGI_SUBSYS_GENERIC_GIC_BASE;
-  VirtualMemoryTable[Index].Length  = SGI_SUBSYS_GENERIC_GIC_SZ;
+  VirtualMemoryTable[++Index].PhysicalBase  = 
FixedPcdGet64(PcdGicDistributorBase);
+  VirtualMemoryTable[Index].VirtualBase = 
FixedPcdGet64(PcdGicDistributorBase);
+  VirtualMemoryTable[Index].Length  = FixedPcdGet64(PcdGicSize);
   VirtualMemoryTable[Index].Attributes  = 
ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
 
   // Expansion AXI - Platform Peripherals - HDLCD1
diff --git a/Platform/ARM/SgiPkg/RdE1Edge.dsc b/Platform/ARM/SgiPkg/RdE1Edge.dsc
new file mode 100644
index 00..082cbb0157
--- /dev/null
+++ b/Platform/ARM/SgiPkg/RdE1Edge.dsc
@@ -0,0 +1,37 @@
+#
+#  Copyright (c) 2020, ARM Limited. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+[Defines]
+  PLATFORM_NAME  = ArmSgi
+  PLATFORM_GUID  = c834de39-c5b0-458b-8ea3-882427179b8a
+  PLATFORM_VERSION   = 0.1
+  DSC_SPECIFICATION  = 0x0001001B
+  OUTPUT_DIRECTO

Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

[Abner Chang]

I don't prefer to do this at this moment, Leif. I have no problem if we create 
a BZ for this and create BaseCompilerIntrinsicsLib in MdeModulePkg, but please 
don't bind it with RISC-V EDK2 port. You know my concern pretty well, we can't 
hold those RISC-V patches on hands like forever and address the code structure 
optimization. We can still work on BaseCompilerIntrinsicsLib but not part of 
this RISC-V submission. We can implement RISC-V variant if necessary after 
RISC-V edk2 get in edk2 master.

Abner

> -Original Message-
> From: Leif Lindholm [mailto:l...@nuviainc.com]
> Sent: Thursday, March 12, 2020 10:03 PM
> To: Schaefer, Daniel (DualStudy) 
> Cc: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
> ; Chen, Gilbert ;
> af...@apple.com; michael.d.kin...@intel.com; p...@akeo.ie; Ard
> Biesheuvel ; Laszlo Ersek 
> Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem
> instead of GUID assignment
> 
> +Ard, Laszlo.
> 
> I think it would make sense to move it to MdeModulePkg (or MdePkg) and
> rename it BaseCompilerIntrinsicsLib (it *is* a BASE library).
> 
> As I alluded in my reply to Ray - x86 also have this problem, but to a lesser
> extent, and ended up creating library functions to call instead of using 
> plain C
> for certain operations.
> Which was probably the right decision when it was restricted to a very few
> corner cases.
> 
> /
> Leif
> 
> On Thu, Mar 12, 2020 at 13:24:30 +, Schaefer, Daniel (DualStudy) wrote:
> > Hi Leif,
> >
> > you're right. If I revert my commit and include
> >   NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> > without making any changes to it, the build succeeds.
> >
> > What do others think? (cc Michael, Pete, Andrew, Ard, who have made
> > changes to this module) Is this a big hack or should we use it in RISC-V, 
> > too
> and move the module to MdeModulePkg?
> > Why isn't this a problem on x86? Was it fine on Itanium?
> >
> > - Daniel
> >
> > 
> > From: devel@edk2.groups.io
> >  on behalf of Leif
> > Lindholm 
> > Sent: Thursday, March 12, 2020 11:55
> > To: devel@edk2.groups.io
> > ; Schaefer, Daniel
> > (DualStudy)
> 
> > Cc: Chang, Abner (HPS SW/FW Technologist)
> > ; Chen, Gilbert
> > ; Dandan Bi
> > ; Eric Dong
> > 
> > Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem
> > instead of GUID assignment
> >
> > Hi Daniel,
> >
> > There is nothing wrong with this patch that just went in (and I should
> > have called out sooner if I wanted to stop it), but I think a better
> > solution is to implement a RISC-V variant of
> > ArmPkg/Library/CompilerIntrinsicsLib/.
> >
> > It is perfectly valid for the compiler to generate memcpy calls in
> > response to struct operations that are perfectly valid C.
> >
> > In fact, we could consider moving the ArmPkg one over into
> > MdeModulePkg. I have a feeling that including a
> >   NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> > in your current build would be an alternative solution to your
> > compilation error.
> >
> > /
> > Leif
> >
> > On Mon, Mar 02, 2020 at 11:32:38 +0100, Daniel Schaefer wrote:
> > > GCC translates a simple assignment to memcpy, which EDKII doesn't
> provide.
> > > See:
> > > INVALID URI REMOVED
> 2Darch
> > > ive.com_edk2-2Ddevel-
> 40lists.01.org_msg11928.html&d=DwIBAg&c=C5b8zRQ
> > >
> O1miGmBeVZ2LFWg&r=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3
> E&m=wjlf
> > >
> QYZsXfc5WWDFmywLOEYlCKvrpYrnaXMIpJcLK7U&s=426yv7VvgHTtgtYaR0f0X
> NiaEA
> > > LgqZkxektjywEwPco&e=
> > >
> > > REF:INVALID URI REMOVED
> > > anocore.org_show-5Fbug.cgi-3Fid-
> 3D2547&d=DwIBAg&c=C5b8zRQO1miGmBeVZ2
> > >
> LFWg&r=_SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E&m=wjlfQYZsX
> fc5WWD
> > > FmywLOEYlCKvrpYrnaXMIpJcLK7U&s=PjC_mIwh0GhNy5np2h7K8l4l-
> pLLBWt1FRuLB
> > > UbULpc&e=
> > >
> > > Signed-off-by: Daniel Schaefer
> > > 
> > > Cc: Abner Chang
> 
> > > Cc: Gilbert Chen
> 
> > > Cc: Leif Lindholm 
> > > Cc: Dandan Bi 
> > > Cc: Eric Dong 
> > > ---
> > >
> > > Notes:
> > > v2:
> > >   - Use CopyMem instead of CopyGuid [Dandan]
> > >
> > >  MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git
> a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> > > b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> > > index 5cc527679a78..0540e6fa8a44 100644
> > > --- a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> > > +++ b/MdeModulePkg/

[edk2-devel] Extend TianoCore Bug Triage - APAC / NAMO Meeting from 0.5 hour to 1 hour

[Liming Gao]

Hi, all
  Recently, regular TianoCore Bug Triage meeting has no enough time to review 
and discuss the existing bugzillas. I would propose to extend this meeting from 
0.5 hour to 1 hour. Now, Bug Triage, Tiano Design and Community meeting are all 
in one day. I have met some conflict to those meeting. Some people may also 
have the conflict. So, I suggest to move TianoCore Bug Triage - APAC / NAMO 
Meeting to Wednesday morning 9:00AM ~ 10:00AM (UTC +8). If you have comments, 
please reply this mail. If no more comments, I will set up the first meeting 
from next week.

Thanks
Liming

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55813): https://edk2.groups.io/g/devel/message/55813
Mute This Topic: https://groups.io/mt/71903179/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/5] OvmfPkg: set fixed FlashNvStorage base addresses with -D SMM_REQUIRE

[Leif Lindholm]

On Wed, Mar 11, 2020 at 17:41:04 +0100, Laszlo Ersek wrote:
> >> A recent example of this was my request for NetworkPkg to expose its
> >> include snippets header-less, for DSC files. Please see the "!include
> >> NetworkPkg/..." directives in the OVMF DSC files; those are also by
> >> design header-less:
> >>
> >> NetworkPkg/NetworkComponents.dsc.inc
> >> NetworkPkg/NetworkDefines.dsc.inc
> >> NetworkPkg/NetworkLibs.dsc.inc
> >> NetworkPkg/NetworkPcds.dsc.inc
> >
> > ...could OvmfPkg use a similar naming scheme to this?
> >
> > That would also remove the drawback of not having the section name as
> > part of the hunk header, as you'd have it anyway immediately above as
> > part of the file name?
> 
> There are three FDF include files:
> 
> (1) DecomprScratchEnd.fdf.inc (included under [FV.FVMAIN_COMPACT], per
> commit 9beac0d847bf9):
>
> ## @file
> #  This FDF include file computes the end of the scratch buffer used in
> #  DecompressMemFvs() [OvmfPkg/Sec/SecMain.c]. It is based on the decompressed
> #  (ie. original) size of the LZMA-compressed section of the one FFS file in
> #  the FVMAIN_COMPACT firmware volume.
> #
> #  Copyright (C) 2015, Red Hat, Inc.
> #
> #  SPDX-License-Identifier: BSD-2-Clause-Patent
> ##
> 
> This include file contains DEFINE and SET statements (for setting macros
> and PCDs, accordingly). I don't think either a "Defines" or "Pcds"
> suffix would apply.

Would FvmainCompactScratchEnd.fdf.inc be an option?

> (2) OvmfPkg.fdf.inc (included under [Defines]):
>
> ## @file
> #  FDF include file that defines the main macros and sets the dependent PCDs.
> #
> #  Copyright (C) 2014, Red Hat, Inc.
> #  Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
> #
> #  SPDX-License-Identifier: BSD-2-Clause-Patent
> #
> ##
> 
> Same situation (both DEFINE and SET statements).

However, it *needs* to be included inside the [Defines] section, so
there is no need to get philosofical:
It's OvmfPkgDefines.fdf.inc (or OvmfDefines.fdf.inc).
This aligns 100% with the NetworkPkg example.

> (3) VarStore.fdf.inc (included under [FD.OVMF] and [FD.OVMF_VARS]):
>
> ## @file
> #  FDF include file with Layout Regions that define an empty variable store.
> #
> #  Copyright (C) 2014, Red Hat, Inc.
> #  Copyright (c) 2006 - 2013, Intel Corporation. All rights reserved.
> #
> #  SPDX-License-Identifier: BSD-2-Clause-Patent
> #
> ##
> 
> I guess we could rename this to "VarStoreLayoutRegions.fdf.inc" -- but
> would that really help?

OK, so this one is different because it can be included in more than
one location. Also, it's not the sort of thing you need to touch if
you're not already in the sixth circle of hell.

> I'm not against introducing helpful name suffixes, I just can't find
> anything that really fits and significantly improves upon the current
> names. I vaguely remember racking my brain when I was introducing these
> files, for better names, and this is what I had come up with. :)

Sure, this all predates the NetworkPkg fragments (or really any
fragments). It would just be nice to be able to start aligning this
across packages. Splitting up the ARM fragment files is also totally
on the table here.

/
Leif

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55812): https://edk2.groups.io/g/devel/message/55812
Mute This Topic: https://groups.io/mt/71867510/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 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

[Leif Lindholm]

+Ard, Laszlo.

I think it would make sense to move it to MdeModulePkg (or MdePkg) and
rename it BaseCompilerIntrinsicsLib (it *is* a BASE library).

As I alluded in my reply to Ray - x86 also have this problem, but to a
lesser extent, and ended up creating library functions to call instead
of using plain C for certain operations.
Which was probably the right decision when it was restricted to a
very few corner cases.

/
Leif

On Thu, Mar 12, 2020 at 13:24:30 +, Schaefer, Daniel (DualStudy) wrote:
> Hi Leif,
> 
> you're right. If I revert my commit and include
>   NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> without making any changes to it, the build succeeds.
> 
> What do others think? (cc Michael, Pete, Andrew, Ard, who have made changes 
> to this module)
> Is this a big hack or should we use it in RISC-V, too and move the module to 
> MdeModulePkg?
> Why isn't this a problem on x86? Was it fine on Itanium?
> 
> - Daniel
> 
> 
> From: devel@edk2.groups.io 
>  on behalf of Leif 
> Lindholm 
> Sent: Thursday, March 12, 2020 11:55
> To: devel@edk2.groups.io 
> ; Schaefer, Daniel 
> (DualStudy) 
> Cc: Chang, Abner (HPS SW/FW Technologist) 
> ; Chen, Gilbert 
> ; Dandan Bi 
> ; Eric Dong 
> 
> Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of 
> GUID assignment
> 
> Hi Daniel,
> 
> There is nothing wrong with this patch that just went in (and I should
> have called out sooner if I wanted to stop it), but I think a better
> solution is to implement a RISC-V variant of
> ArmPkg/Library/CompilerIntrinsicsLib/.
> 
> It is perfectly valid for the compiler to generate memcpy calls in
> response to struct operations that are perfectly valid C.
> 
> In fact, we could consider moving the ArmPkg one over into
> MdeModulePkg. I have a feeling that including a
>   NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> in your current build would be an alternative solution to your
> compilation error.
> 
> /
> Leif
> 
> On Mon, Mar 02, 2020 at 11:32:38 +0100, Daniel Schaefer wrote:
> > GCC translates a simple assignment to memcpy, which EDKII doesn't provide.
> > See: https://www.mail-archive.com/edk2-devel@lists.01.org/msg11928.html
> >
> > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2547
> >
> > Signed-off-by: Daniel Schaefer 
> > 
> > Cc: Abner Chang 
> > Cc: Gilbert Chen 
> > Cc: Leif Lindholm 
> > Cc: Dandan Bi 
> > Cc: Eric Dong 
> > ---
> >
> > Notes:
> > v2:
> >   - Use CopyMem instead of CopyGuid [Dandan]
> >
> >  MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c 
> > b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> > index 5cc527679a78..0540e6fa8a44 100644
> > --- a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> > +++ b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> > @@ -619,7 +619,7 @@ CreateDeviceManagerForm(
> >  TokenHelp = HiiSetString (HiiHandle, 0, String, NULL);
> >  FreePool (String);
> >
> > -FormSetGuid = ((EFI_IFR_FORM_SET *)Ptr)->Guid;
> > +CopyMem (&FormSetGuid, &((EFI_IFR_FORM_SET *) Ptr)->Guid, sizeof 
> > (EFI_GUID));
> >
> >  //
> >  // Network device process
> > --
> > 2.25.0
> >
> >
> >
> >
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55811): https://edk2.groups.io/g/devel/message/55811
Mute This Topic: https://groups.io/mt/71671270/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [EXTERNAL] RE: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

[Leif Lindholm]

Hi Ray,

On Thu, Mar 12, 2020 at 12:21 PM Ni, Ray  wrote:
> Does CompilerIntrinsicsLib exist because GCC doesn't support to disable
intrinsic?

It is not possible to disable all intrinsics on 32-bit ARM, and it's not
necessarily desirable to do so for AArch64 (so I don't think it's
implemented).

Note that this is somewhat true for x86 too - leading to things like
DivU64x32 in BaseLib.

> How does the linker find the CompilerInstrinsicsLib in linking phase?

For example:
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/MdeModulePkg.dsc#L172

Regards,

Leif

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55810): https://edk2.groups.io/g/devel/message/55810
Mute This Topic: https://groups.io/mt/71902327/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH 4/8] Platform/ARM/SgiPkg: remove PcdCoreCount and PcdClusterCount

[Aditya Angadi]

The number of CPUs depend on the SGI/RD platform. So instead of
defining a Fixed PCD to specify the value of core and cluster count,
let each platform define these values.

Change-Id: Ieb872616aa37a1a977f99d9ffd3fe4c761ae4e39
Signed-off-by: Aditya Angadi 
---
 Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc|  7 ++-
 .../ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf |  2 --
 Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Madt.aslc|  7 ---
 .../ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf |  2 --
 Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2/Madt.aslc  | 12 ++--
 .../ARM/SgiPkg/AcpiTables/RdN1EdgeX2AcpiTables.inf   |  2 --
 Platform/ARM/SgiPkg/AcpiTables/Sgi575/Madt.aslc  |  9 +
 Platform/ARM/SgiPkg/AcpiTables/Sgi575AcpiTables.inf  |  4 +---
 .../ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf   |  3 ---
 Platform/ARM/SgiPkg/SgiPlatform.dsc  |  4 
 10 files changed, 22 insertions(+), 30 deletions(-)

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc 
b/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc
index 9872549285..a9540f2e03 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc
@@ -14,12 +14,17 @@
 #include 
 #include 
 
+#define CLUSTER_COUNT 2
+#define CORES_PER_CLUSTER 8
+#define THREADS_PER_CORE  2
+#define CORE_COUNT(CLUSTER_COUNT * CORES_PER_CLUSTER * 
THREADS_PER_CORE)
+
 // Multiple APIC Description Table
 #pragma pack (1)
 
 typedef struct {
   EFI_ACPI_6_2_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER   Header;
-  EFI_ACPI_6_2_GIC_STRUCTUREGicInterfaces[32];
+  EFI_ACPI_6_2_GIC_STRUCTURE
GicInterfaces[CORE_COUNT];
   EFI_ACPI_6_2_GIC_DISTRIBUTOR_STRUCTUREGicDistributor;
   EFI_ACPI_6_2_GICR_STRUCTURE   GicRedistributor;
   EFI_ACPI_6_2_GIC_ITS_STRUCTUREGicIts;
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf 
b/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf
index b08d7c2df5..742ca9e683 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf
@@ -34,8 +34,6 @@
   Platform/ARM/SgiPkg/SgiPlatform.dec
 
 [FixedPcd]
-  gArmPlatformTokenSpaceGuid.PcdCoreCount
-  gArmPlatformTokenSpaceGuid.PcdClusterCount
   gArmPlatformTokenSpaceGuid.PcdSerialDbgRegisterBase
   gArmPlatformTokenSpaceGuid.PL011UartInterrupt
 
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Madt.aslc 
b/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Madt.aslc
index 05eb78c561..d8ec0ce421 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Madt.aslc
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Madt.aslc
@@ -14,15 +14,16 @@
 #include 
 #include 
 
-#define CORE_CNT   (FixedPcdGet32 (PcdClusterCount) * \
-FixedPcdGet32 (PcdCoreCount))
+#define CLUSTER_COUNT 2
+#define CORES_PER_CLUSTER 4
+#define CORE_COUNT(CLUSTER_COUNT * CORES_PER_CLUSTER)
 
 // Multiple APIC Description Table
 #pragma pack (1)
 
 typedef struct {
   EFI_ACPI_6_2_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER   Header;
-  EFI_ACPI_6_2_GIC_STRUCTURE
GicInterfaces[CORE_CNT];
+  EFI_ACPI_6_2_GIC_STRUCTURE
GicInterfaces[CORE_COUNT];
   EFI_ACPI_6_2_GIC_DISTRIBUTOR_STRUCTUREGicDistributor;
   EFI_ACPI_6_2_GICR_STRUCTURE   GicRedistributor;
   EFI_ACPI_6_2_GIC_ITS_STRUCTUREGicIts;
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf 
b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf
index 61b07bffcc..206479f942 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf
@@ -34,8 +34,6 @@
   Platform/ARM/SgiPkg/SgiPlatform.dec
 
 [FixedPcd]
-  gArmPlatformTokenSpaceGuid.PcdCoreCount
-  gArmPlatformTokenSpaceGuid.PcdClusterCount
   gArmPlatformTokenSpaceGuid.PcdSerialDbgRegisterBase
   gArmPlatformTokenSpaceGuid.PL011UartInterrupt
 
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2/Madt.aslc 
b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2/Madt.aslc
index 47368931e3..add9724374 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2/Madt.aslc
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2/Madt.aslc
@@ -14,19 +14,19 @@
 #include 
 #include 
 
-#define CORE_CNT   (FixedPcdGet32 (PcdClusterCount) * \
-FixedPcdGet32 (PcdCoreCount))
-
-#define CHIP_CNT   2
+#define CLUSTER_COUNT 2
+#define CORES_PER_CLUSTER 4
+#define CORE_COUNT(CLUSTER_COUNT * CORES_PER_CLUSTER)
+#define CHIP_COUNT   2
 
 // Multiple APIC Description Table
 #pragma pack (1)
 
 typedef struct {
   EFI_ACPI_6_2_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER  Header;
-  EFI_ACPI_6_2_GIC_STRUCTURE   

[edk2-devel] [edk2-platforms][PATCH 1/8] Platform/ARM/SgiPkg: Create individual Platform Description File

[Aditya Angadi]

From: Vijayenthiran Subramaniam 

In preparation for adding support for Reference Design (RD) platforms
that have different base addresses for GIC distributor or redistributor,
create individual platform description files for all SGI/RD platforms
and move GIC related base addresses from the common SGI/RD platform
description file to individual platform description files.
The existing platform description is then included by individual
platform description files.

Change-Id: Ic8b420b13dac574b940be6b526817066df60d45d
Signed-off-by: Vijayenthiran Subramaniam 
---
 Platform/ARM/SgiPkg/Include/SgiPlatform.h |  7 +---
 .../Library/PlatformLib/PlatformLib.inf   |  3 +-
 .../Library/PlatformLib/PlatformLibMem.c  |  8 ++--
 Platform/ARM/SgiPkg/RdE1Edge.dsc  | 37 +++
 Platform/ARM/SgiPkg/RdN1Edge.dsc  | 37 +++
 Platform/ARM/SgiPkg/Sgi575.dsc| 37 +++
 Platform/ARM/SgiPkg/SgiPlatform.dec   |  5 ++-
 Platform/ARM/SgiPkg/SgiPlatform.dsc   | 25 +
 8 files changed, 124 insertions(+), 35 deletions(-)
 create mode 100644 Platform/ARM/SgiPkg/RdE1Edge.dsc
 create mode 100644 Platform/ARM/SgiPkg/RdN1Edge.dsc
 create mode 100644 Platform/ARM/SgiPkg/Sgi575.dsc

diff --git a/Platform/ARM/SgiPkg/Include/SgiPlatform.h 
b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
index e36a412155..d87fb2b540 100644
--- a/Platform/ARM/SgiPkg/Include/SgiPlatform.h
+++ b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
@@ -1,6 +1,6 @@
 /** @file
 *
-*  Copyright (c) 2018, ARM Limited. All rights reserved.
+*  Copyright (c) 2018-2020, ARM Limited. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -45,11 +45,6 @@
 #define SGI_SUBSYS_GENERIC_WDOG_BASE  0x2A44
 #define SGI_SUBSYS_GENERIC_WDOG_SZSIZE_128KB
 
-// Sub System Peripherals - GIC
-#define SGI_SUBSYS_GENERIC_GIC_BASE   0x3000
-#define SGI_SUBSYS_GENERIC_GICR_BASE  0x300C
-#define SGI_SUBSYS_GENERIC_GIC_SZ SIZE_1MB
-
 // Expansion AXI - Platform Peripherals - HDLCD1
 #define SGI_EXP_PLAT_PERIPH_HDLCD1_BASE   0x7FF6
 #define SGI_EXP_PLAT_PERIPH_HDLCD1_SZ SIZE_64KB
diff --git a/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf 
b/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf
index 3db70e900d..a918afef5f 100644
--- a/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf
+++ b/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLib.inf
@@ -1,5 +1,5 @@
 #
-#  Copyright (c) 2018, ARM Limited. All rights reserved.
+#  Copyright (c) 2018-2020, ARM Limited. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -42,6 +42,7 @@
 
   gArmSgiTokenSpaceGuid.PcdDramBlock2Base
   gArmSgiTokenSpaceGuid.PcdDramBlock2Size
+  gArmSgiTokenSpaceGuid.PcdGicSize
 
   gArmTokenSpaceGuid.PcdSystemMemoryBase
   gArmTokenSpaceGuid.PcdSystemMemorySize
diff --git a/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLibMem.c 
b/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLibMem.c
index 845aeaf4dd..8d0ad4ec9c 100644
--- a/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLibMem.c
+++ b/Platform/ARM/SgiPkg/Library/PlatformLib/PlatformLibMem.c
@@ -1,6 +1,6 @@
 /** @file
 *
-*  Copyright (c) 2018, ARM Limited. All rights reserved.
+*  Copyright (c) 2018-2020, ARM Limited. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -93,9 +93,9 @@ ArmPlatformGetVirtualMemoryMap (
   VirtualMemoryTable[Index].Attributes  = 
ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
 
   // Sub System Peripherals - GIC-600
-  VirtualMemoryTable[++Index].PhysicalBase  = SGI_SUBSYS_GENERIC_GIC_BASE;
-  VirtualMemoryTable[Index].VirtualBase = SGI_SUBSYS_GENERIC_GIC_BASE;
-  VirtualMemoryTable[Index].Length  = SGI_SUBSYS_GENERIC_GIC_SZ;
+  VirtualMemoryTable[++Index].PhysicalBase  = 
FixedPcdGet64(PcdGicDistributorBase);
+  VirtualMemoryTable[Index].VirtualBase = 
FixedPcdGet64(PcdGicDistributorBase);
+  VirtualMemoryTable[Index].Length  = FixedPcdGet64(PcdGicSize);
   VirtualMemoryTable[Index].Attributes  = 
ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
 
   // Expansion AXI - Platform Peripherals - HDLCD1
diff --git a/Platform/ARM/SgiPkg/RdE1Edge.dsc b/Platform/ARM/SgiPkg/RdE1Edge.dsc
new file mode 100644
index 00..082cbb0157
--- /dev/null
+++ b/Platform/ARM/SgiPkg/RdE1Edge.dsc
@@ -0,0 +1,37 @@
+#
+#  Copyright (c) 2020, ARM Limited. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+[Defines]
+  PLATFORM_NAME  = ArmSgi
+  PLATFORM_GUID  = c834de39-c5b0-458b-8ea3-882427179b8a
+  PLATFORM_VERSION   = 0.1
+  DSC_SPEC

[edk2-devel] [edk2-platforms][PATCH 0/8] Add platform support for RD-Daniel

[Aditya Angadi]

This patch series adds support for Arm's RD-Daniel platform. There are two
configurations of this platform being added in this series - Config-M and
Config-XLR. RD-Daniel is the next Arm's reference design subsystem.

The first four patches consolidate the code in SgiPkg in preparation for
adding support for the RD-Daniel platform. The next four patches add support
for the RD-Daniel platforms.

Aditya Angadi (7):
  Platform/ARM/SgiPkg: move the GIC related ACPI helper macros
  Platform/ARM/SgiPkg: move common platform description to SSDT
  Platform/ARM/SgiPkg: remove PcdCoreCount and PcdClusterCount
  Platform/ARM/SgiPkg: Add ACPI tables for Rd-Daniel Config-M
  Platform/ARM/Sgi: Add initial support for RD-Daniel Config-M platform
  Platform/ARM/SgiPkg: add ACPI tables for RD-Daniel Config-XLR
  Platform/ARM/Sgi: Add initial support for RD-Daniel Config-XLR platform

Vijayenthiran Subramaniam (1):
  Platform/ARM/SgiPkg: Create individual Platform Description File

 .../SgiPkg/AcpiTables/RdDanielCfgM/Dsdt.asl   | 118 ++
 .../SgiPkg/AcpiTables/RdDanielCfgM/Madt.aslc  | 134 
 .../AcpiTables/RdDanielCfgMAcpiTables.inf |  63 
 .../SgiPkg/AcpiTables/RdDanielCfgXlr/Dsdt.asl | 125 +++
 .../AcpiTables/RdDanielCfgXlr/Madt.aslc   | 150 ++
 .../AcpiTables/RdDanielCfgXlrAcpiTables.inf   |  63 
 .../ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl   |  70 +---
 .../ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc  |  73 +
 .../SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf  |   5 +-
 .../ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl   |  69 +---
 .../ARM/SgiPkg/AcpiTables/RdN1Edge/Madt.aslc  |  75 +
 .../SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf  |   5 +-
 .../SgiPkg/AcpiTables/RdN1EdgeX2/Madt.aslc|  69 +---
 .../AcpiTables/RdN1EdgeX2AcpiTables.inf   |   3 +-
 .../ARM/SgiPkg/AcpiTables/Sgi575/Madt.aslc|   9 +-
 .../SgiPkg/AcpiTables/Sgi575AcpiTables.inf|   4 +-
 Platform/ARM/SgiPkg/AcpiTables/SsdtRos.asl|  90 +++
 .../SgiPkg/Drivers/PlatformDxe/PlatformDxe.c  |  10 ++
 .../Drivers/PlatformDxe/PlatformDxe.inf   |   2 +
 Platform/ARM/SgiPkg/Include/SgiAcpiHeader.h   |  70 +++-
 Platform/ARM/SgiPkg/Include/SgiPlatform.h |  12 +-
 .../Library/PlatformLib/PlatformLib.inf   |   6 +-
 .../Library/PlatformLib/PlatformLibMem.c  |   8 +-
 Platform/ARM/SgiPkg/RdDaniel.dsc  |  38 +
 Platform/ARM/SgiPkg/RdE1Edge.dsc  |  37 +
 Platform/ARM/SgiPkg/RdN1Edge.dsc  |  37 +
 Platform/ARM/SgiPkg/Sgi575.dsc|  37 +
 Platform/ARM/SgiPkg/SgiPlatform.dec   |   7 +-
 Platform/ARM/SgiPkg/SgiPlatform.dsc   |  31 +---
 Platform/ARM/SgiPkg/SgiPlatform.fdf   |   2 +
 30 files changed, 1028 insertions(+), 394 deletions(-)
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Dsdt.asl
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Madt.aslc
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgMAcpiTables.inf
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Dsdt.asl
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Madt.aslc
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlrAcpiTables.inf
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SsdtRos.asl
 create mode 100644 Platform/ARM/SgiPkg/RdDaniel.dsc
 create mode 100644 Platform/ARM/SgiPkg/RdE1Edge.dsc
 create mode 100644 Platform/ARM/SgiPkg/RdN1Edge.dsc
 create mode 100644 Platform/ARM/SgiPkg/Sgi575.dsc

-- 
2.17.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55801): https://edk2.groups.io/g/devel/message/55801
Mute This Topic: https://groups.io/mt/71902045/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH 6/8] Platform/ARM/Sgi: Add initial support for RD-Daniel Config-M platform

[Aditya Angadi]

Add information in the SGI platform descriptor HOB to pick the correct
ACPI table to install for RD-Daniel Config-M

Change-Id: I6f16b71527e1ec13511917b6cb3a46a9458e88cc
Signed-off-by: Aditya Angadi 
---
 .../SgiPkg/Drivers/PlatformDxe/PlatformDxe.c  |  5 +++
 .../Drivers/PlatformDxe/PlatformDxe.inf   |  1 +
 Platform/ARM/SgiPkg/Include/SgiPlatform.h |  4 ++
 Platform/ARM/SgiPkg/RdDaniel.dsc  | 38 +++
 4 files changed, 48 insertions(+)
 create mode 100644 Platform/ARM/SgiPkg/RdDaniel.dsc

diff --git a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c 
b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
index 387397d745..7e0de765f7 100644
--- a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
+++ b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
@@ -46,6 +46,11 @@ STATIC SGI_PLATFORM_ACPI_TABLE_GUID_LOOKUP 
AcpiTableGuidLookup[] = {
   RD_E1_EDGE_CONF_ID,
   MULTI_CHIP_MODE_DISABLED,
   &gRdE1EdgeAcpiTablesFileGuid),
+  ACPI_GUID_LOOKUP (
+  RD_DANIEL_PART_NUM,
+  RD_DANIEL_CFGM_CONF_ID,
+  MULTI_CHIP_MODE_DISABLED,
+  &gRdDanielCfgMAcpiTablesFileGuid),
 };
 
 VOID
diff --git a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf 
b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
index 741dcc75ed..82569820b7 100644
--- a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
+++ b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
@@ -34,6 +34,7 @@
   gRdN1EdgeAcpiTablesFileGuid
   gRdN1EdgeX2AcpiTablesFileGuid
   gRdE1EdgeAcpiTablesFileGuid
+  gRdDanielCfgMAcpiTablesFileGuid
 
 [FeaturePcd]
   gArmSgiTokenSpaceGuid.PcdVirtioBlkSupported
diff --git a/Platform/ARM/SgiPkg/Include/SgiPlatform.h 
b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
index d87fb2b540..b6a427b8b6 100644
--- a/Platform/ARM/SgiPkg/Include/SgiPlatform.h
+++ b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
@@ -70,6 +70,10 @@
 #define RD_N1_EDGE_CONF_ID0x1
 #define RD_E1_EDGE_CONF_ID0x2
 
+//RDDANIEL Platform Identification values
+#define RD_DANIEL_PART_NUM0x78A
+#define RD_DANIEL_CFGM_CONF_ID0x1
+
 #define SGI_CONFIG_MASK   0x0F
 #define SGI_CONFIG_SHIFT  0x1C
 #define SGI_PART_NUM_MASK 0xFFF
diff --git a/Platform/ARM/SgiPkg/RdDaniel.dsc b/Platform/ARM/SgiPkg/RdDaniel.dsc
new file mode 100644
index 00..09607004ed
--- /dev/null
+++ b/Platform/ARM/SgiPkg/RdDaniel.dsc
@@ -0,0 +1,38 @@
+#
+#  Copyright (c) 2020, ARM Limited. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+[Defines]
+  PLATFORM_NAME  = ArmSgi
+  PLATFORM_GUID  = d301ac4e-0828-4cef-b754-34ca9b6781b5
+  PLATFORM_VERSION   = 0.1
+  DSC_SPECIFICATION  = 0x0001001B
+  OUTPUT_DIRECTORY   = Build/$(PLATFORM_NAME)
+  SUPPORTED_ARCHITECTURES= AARCH64|ARM
+  BUILD_TARGETS  = NOOPT|DEBUG|RELEASE
+  SKUID_IDENTIFIER   = DEFAULT
+  FLASH_DEFINITION   = Platform/ARM/SgiPkg/SgiPlatform.fdf
+  BUILD_NUMBER   = 1
+
+# include common definitions from SgiPlatform.dsc
+!include Platform/ARM/SgiPkg/SgiPlatform.dsc
+
+
+#
+# Pcd Section - list of all EDK II PCD Entries defined by this Platform
+#
+
+
+[PcdsFixedAtBuild.common]
+  # GIC Base Addresses
+  gArmTokenSpaceGuid.PcdGicDistributorBase|0x3000
+  gArmTokenSpaceGuid.PcdGicRedistributorsBase|0x3014
+  gArmSgiTokenSpaceGuid.PcdGicSize|0x20
+
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55804): https://edk2.groups.io/g/devel/message/55804
Mute This Topic: https://groups.io/mt/71902048/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms][PATCH 7/8] Platform/ARM/SgiPkg: add ACPI tables for RD-Daniel Config-XLR

[Aditya Angadi]

RD-Daniel Config-XLR is a platform in which four identical chips are connected
via a high speed CCIX link. Add Madt and Dsdt tables for the same.

Change-Id: I5bcaa5863f38cd36a4ef1524ce460a9033303d34
Signed-off-by: Aditya Angadi 
---
 .../SgiPkg/AcpiTables/RdDanielCfgXlr/Dsdt.asl | 125 +++
 .../AcpiTables/RdDanielCfgXlr/Madt.aslc   | 150 ++
 .../AcpiTables/RdDanielCfgXlrAcpiTables.inf   |  63 
 Platform/ARM/SgiPkg/SgiPlatform.dec   |   1 +
 Platform/ARM/SgiPkg/SgiPlatform.dsc   |   1 +
 Platform/ARM/SgiPkg/SgiPlatform.fdf   |   1 +
 6 files changed, 341 insertions(+)
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Dsdt.asl
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Madt.aslc
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlrAcpiTables.inf

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Dsdt.asl 
b/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Dsdt.asl
new file mode 100644
index 00..23ada55ec4
--- /dev/null
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Dsdt.asl
@@ -0,0 +1,125 @@
+/** @file
+*  Differentiated System Description Table Fields (DSDT)
+*
+*  Copyright (c) 2020, ARM Limited. All rights reserved.
+*
+*  This program and the accompanying materials are licensed and made available
+*  under the terms and conditions of the BSD License which accompanies this
+*  distribution.  The full text of the license may be found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+
+#include "SgiPlatform.h"
+#include "SgiAcpiHeader.h"
+
+DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "ARMLTD", "ARMSGI",
+ EFI_ACPI_ARM_OEM_REVISION) {
+  Scope (_SB) {
+
+Device (CP00) { // Zeus core 0
+  Name (_HID, "ACPI0007")
+  Name (_UID, 0)
+  Name (_STA, 0xF)
+}
+
+Device (CP01) { // Zeus core 1
+  Name (_HID, "ACPI0007")
+  Name (_UID, 1)
+  Name (_STA, 0xF)
+}
+
+Device (CP02) { // Zeus core 2
+  Name (_HID, "ACPI0007")
+  Name (_UID, 2)
+  Name (_STA, 0xF)
+}
+
+Device (CP03) { // Zeus core 3
+  Name (_HID, "ACPI0007")
+  Name (_UID, 3)
+  Name (_STA, 0xF)
+}
+
+Device (CP04) { // Zeus core 4
+  Name (_HID, "ACPI0007")
+  Name (_UID, 4)
+  Name (_STA, 0xF)
+}
+
+Device (CP05) { // Zeus core 5
+  Name (_HID, "ACPI0007")
+  Name (_UID, 5)
+  Name (_STA, 0xF)
+}
+
+Device (CP06) { // Zeus core 6
+  Name (_HID, "ACPI0007")
+  Name (_UID, 6)
+  Name (_STA, 0xF)
+}
+
+Device (CP07) { // Zeus core 7
+  Name (_HID, "ACPI0007")
+  Name (_UID, 7)
+  Name (_STA, 0xF)
+}
+
+Device (CP08) { // Zeus core 8
+  Name (_HID, "ACPI0007")
+  Name (_UID, 8)
+  Name (_STA, 0xF)
+}
+
+Device (CP09) { // Zeus core 9
+  Name (_HID, "ACPI0007")
+  Name (_UID, 9)
+  Name (_STA, 0xF)
+}
+
+Device (CP10) { // Zeus core 10
+  Name (_HID, "ACPI0007")
+  Name (_UID, 10)
+  Name (_STA, 0xF)
+}
+
+Device (CP11) { // Zeus core 11
+  Name (_HID, "ACPI0007")
+  Name (_UID, 11)
+  Name (_STA, 0xF)
+}
+
+Device (CP12) { // Zeus core 12
+  Name (_HID, "ACPI0007")
+  Name (_UID, 12)
+  Name (_STA, 0xF)
+}
+
+Device (CP13) { // Zeus core 13
+  Name (_HID, "ACPI0007")
+  Name (_UID, 13)
+  Name (_STA, 0xF)
+}
+
+Device (CP14) { // Zeus core 14
+  Name (_HID, "ACPI0007")
+  Name (_UID, 14)
+  Name (_STA, 0xF)
+}
+
+Device (CP15) { // Zeus core 15
+  Name (_HID, "ACPI0007")
+  Name (_UID, 15)
+  Name (_STA, 0xF)
+}
+
+Device (CP16) { // Zeus core 16
+  Name (_HID, "ACPI0007")
+  Name (_UID, 16)
+  Name (_STA, 0xF)
+}
+  } // Scope(_SB)
+}
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Madt.aslc 
b/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Madt.aslc
new file mode 100644
index 00..e3784b55f2
--- /dev/null
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgXlr/Madt.aslc
@@ -0,0 +1,150 @@
+/** @file
+*  Multiple APIC Description Table (MADT)
+*
+*  Copyright (c) 2020, ARM Limited. All rights reserved.
+*
+*  This program and the accompanying materials are licensed and made available
+*  under the terms and conditions of the BSD License which accompanies this
+*  distribution.  The full text of the license may be found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+
+#include "SgiPlatform.h"
+#include "SgiAcpiHeader.h"
+#include 
+#include 
+#include 
+#include 
+
+#define CLUSTER_COUNT 4
+#define CORES_P

[edk2-devel] [edk2-platforms][PATCH 2/8] Platform/ARM/SgiPkg: move the GIC related ACPI helper macros

[Aditya Angadi]

Move the ACPI helper macros defines related to GIC structure,
distributor, redistributor and ITS to SgiAcpiHeader.h as these are
common across ARM SGI/RD platforms.

Change-Id: I9bed6753e30e344b0eff7bd3d0e2290c8b8a46f0
Signed-off-by: Aditya Angadi 
---
 .../ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc  | 68 +-
 .../ARM/SgiPkg/AcpiTables/RdN1Edge/Madt.aslc  | 68 +-
 .../SgiPkg/AcpiTables/RdN1EdgeX2/Madt.aslc| 57 +--
 Platform/ARM/SgiPkg/Include/SgiAcpiHeader.h   | 70 ++-
 4 files changed, 72 insertions(+), 191 deletions(-)

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc 
b/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc
index 48e7a61478..9872549285 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Madt.aslc
@@ -1,7 +1,7 @@
 /** @file
 *  Multiple APIC Description Table (MADT)
 *
-*  Copyright (c) 2018, ARM Limited. All rights reserved.
+*  Copyright (c) 2018-2020, ARM Limited. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -14,72 +14,6 @@
 #include 
 #include 
 
-// EFI_ACPI_6_2_GIC_STRUCTURE
-#define EFI_ACPI_6_2_GICC_STRUCTURE_INIT(GicId, AcpiCpuUid, Mpidr, Flags,  
\
-  PmuIrq, GicBase, GicVBase, GicHBase, GsivId, GicRBase, Efficiency)   
\
-  {
\
-EFI_ACPI_6_2_GIC, /* Type */   
\
-sizeof (EFI_ACPI_6_2_GIC_STRUCTURE),  /* Length */ 
\
-EFI_ACPI_RESERVED_WORD,   /* Reserved */   
\
-GicId,/* CPUInterfaceNumber */ 
\
-AcpiCpuUid,   /* AcpiProcessorUid */   
\
-Flags,/* Flags */  
\
-0,/* ParkingProtocolVersion */ 
\
-PmuIrq,   /* PerformanceInterruptGsiv */   
\
-0,/* ParkedAddress */  
\
-GicBase,  /* PhysicalBaseAddress */
\
-GicVBase, /* GICV */   
\
-GicHBase, /* GICH */   
\
-GsivId,   /* VGICMaintenanceInterrupt */   
\
-GicRBase, /* GICRBaseAddress */
\
-Mpidr,/* MPIDR */  
\
-Efficiency,   /* ProcessorPowerEfficiencyClass */  
\
-{  
\
-  EFI_ACPI_RESERVED_BYTE, /* Reserved2[0] */   
\
-  EFI_ACPI_RESERVED_BYTE, /* Reserved2[1] */   
\
-  EFI_ACPI_RESERVED_BYTE  /* Reserved2[2] */   
\
-}  
\
-  }
-
-// EFI_ACPI_6_2_GIC_DISTRIBUTOR_STRUCTURE
-#define EFI_ACPI_6_2_GIC_DISTRIBUTOR_INIT(GicDistHwId, GicDistBase,
\
-  GicDistVector, GicVersion)   
\
-  {
\
-EFI_ACPI_6_2_GICD,/* Type */   
\
-sizeof (EFI_ACPI_6_2_GIC_DISTRIBUTOR_STRUCTURE),   
\
-EFI_ACPI_RESERVED_WORD,   /* Reserved1 */  
\
-GicDistHwId,  /* GicId */  
\
-GicDistBase,  /* PhysicalBaseAddress */
\
-GicDistVector,/* SystemVectorBase */   
\
-GicVersion,   /* GicVersion */ 
\
-{  
\
-  EFI_ACPI_RESERVED_BYTE, /* Reserved2[0] */   
\
-  EFI_ACPI_RESERVED_BYTE, /* Reserved2[1] */   
\
-  EFI_ACPI_RESERVED_BYTE  /* Reserved2[2] */   
\
-}  
\
-  }
-
-// EFI_ACPI_6_2_GICR_STRUCTURE
-#define EFI_ACPI_6_2_GIC_REDISTRIBUTOR_INIT(RedisRegionAddr, RedisDiscLength)  
\
-  {
\
-EFI_ACPI_6_2_GICR,/* Type */   
\
-sizeof (EFI_ACPI_6_2_GICR_STRUCTURE), /* Length */ 
\
-EFI_ACPI_RESERVED_WORD,   /* Reserved */   
\
-RedisRegionAddr,  /* DiscoveryRangeBaseAddress */  
\

[edk2-devel] [edk2-platforms][PATCH 5/8] Platform/ARM/SgiPkg: Add ACPI tables for Rd-Daniel Config-M

[Aditya Angadi]

Add Madt and Dsdt ACPI tables for RD-Daniel Config-M platform.

Change-Id: I82f0eaaae6bb4cd515e04ed0a6f8a039c63cf557
Signed-off-by: Aditya Angadi 
---
 .../SgiPkg/AcpiTables/RdDanielCfgM/Dsdt.asl   | 118 +++
 .../SgiPkg/AcpiTables/RdDanielCfgM/Madt.aslc  | 134 ++
 .../AcpiTables/RdDanielCfgMAcpiTables.inf |  63 
 Platform/ARM/SgiPkg/SgiPlatform.dec   |   1 +
 Platform/ARM/SgiPkg/SgiPlatform.dsc   |   1 +
 Platform/ARM/SgiPkg/SgiPlatform.fdf   |   1 +
 6 files changed, 318 insertions(+)
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Dsdt.asl
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Madt.aslc
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgMAcpiTables.inf

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Dsdt.asl 
b/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Dsdt.asl
new file mode 100644
index 00..57873ef5cf
--- /dev/null
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Dsdt.asl
@@ -0,0 +1,118 @@
+/** @file
+*  Differentiated System Description Table Fields (DSDT)
+*
+*  Copyright (c) 2020, ARM Ltd. All rights reserved.
+*
+*  This program and the accompanying materials are licensed and made available
+*  under the terms and conditions of the BSD License which accompanies this
+*  distribution.  The full text of the license may be found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+
+#include "SgiPlatform.h"
+#include "SgiAcpiHeader.h"
+
+DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "ARMLTD", "ARMSGI",
+ EFI_ACPI_ARM_OEM_REVISION) {
+  Scope (_SB) {
+Device (CP00) { // Zeus core 0
+  Name (_HID, "ACPI0007")
+  Name (_UID, 0)
+  Name (_STA, 0xF)
+}
+
+Device (CP01) { // Zeus core 1
+  Name (_HID, "ACPI0007")
+  Name (_UID, 1)
+  Name (_STA, 0xF)
+}
+
+Device (CP02) { // Zeus core 2
+  Name (_HID, "ACPI0007")
+  Name (_UID, 2)
+  Name (_STA, 0xF)
+}
+
+Device (CP03) { // Zeus core 3
+  Name (_HID, "ACPI0007")
+  Name (_UID, 3)
+  Name (_STA, 0xF)
+}
+
+Device (CP04) { // Zeus core 4
+  Name (_HID, "ACPI0007")
+  Name (_UID, 4)
+  Name (_STA, 0xF)
+}
+
+Device (CP05) { // Zeus core 5
+  Name (_HID, "ACPI0007")
+  Name (_UID, 5)
+  Name (_STA, 0xF)
+}
+
+Device (CP06) { // Zeus core 6
+  Name (_HID, "ACPI0007")
+  Name (_UID, 6)
+  Name (_STA, 0xF)
+}
+
+Device (CP07) { // Zeus core 7
+  Name (_HID, "ACPI0007")
+  Name (_UID, 7)
+  Name (_STA, 0xF)
+}
+
+Device (CP08) { // Zeus core 8
+  Name (_HID, "ACPI0007")
+  Name (_UID, 8)
+  Name (_STA, 0xF)
+}
+
+   Device (CP09) { // Zeus core 9
+  Name (_HID, "ACPI0007")
+  Name (_UID, 9)
+  Name (_STA, 0xF)
+}
+
+   Device (CP10) { // Zeus core 10
+  Name (_HID, "ACPI0007")
+  Name (_UID, 10)
+  Name (_STA, 0xF)
+}
+
+   Device (CP11) { // Zeus core 11
+  Name (_HID, "ACPI0007")
+  Name (_UID, 11)
+  Name (_STA, 0xF)
+}
+
+Device (CP12) { // Zeus core 12
+  Name (_HID, "ACPI0007")
+  Name (_UID, 12)
+  Name (_STA, 0xF)
+}
+
+   Device (CP13) { // Zeus core 13
+  Name (_HID, "ACPI0007")
+  Name (_UID, 13)
+  Name (_STA, 0xF)
+}
+
+   Device (CP14) { // Zeus core 14
+  Name (_HID, "ACPI0007")
+  Name (_UID, 14)
+  Name (_STA, 0xF)
+}
+
+   Device (CP15) { // Zeus core 15
+  Name (_HID, "ACPI0007")
+  Name (_UID, 15)
+  Name (_STA, 0xF)
+}
+  } // Scope(_SB)
+}
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Madt.aslc 
b/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Madt.aslc
new file mode 100644
index 00..3027b8d223
--- /dev/null
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdDanielCfgM/Madt.aslc
@@ -0,0 +1,134 @@
+/** @file
+*  Multiple APIC Description Table (MADT)
+*
+*  Copyright (c) 2020, ARM Limited. All rights reserved.
+*
+*  This program and the accompanying materials are licensed and made available
+*  under the terms and conditions of the BSD License which accompanies this
+*  distribution.  The full text of the license may be found at
+*  http://opensource.org/licenses/bsd-license.php
+*
+*  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+*  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+*
+**/
+
+#include "SgiPlatform.h"
+#include "SgiAcpiHeader.h"
+#include 
+#include 
+#include 
+#include 
+
+#define CLUSTER_COUNT   16
+#define CORES_PER_CLUSTER   1
+#define CORE_COUNT  (CLUSTER_COUNT * CORES_PER_CLUSTER)
+
+// Multiple APIC Description Table
+#pragma pack (1)
+
+typedef struct {
+  EFI_ACPI_6_2_MULTIPLE_APIC_DESCRIPTION_TABLE_HEADER   Header;
+  EFI_ACPI_6

[edk2-devel] [edk2-platforms][PATCH 3/8] Platform/ARM/SgiPkg: move common platform description to SSDT

[Aditya Angadi]

Move common platform description entries in platfrom specific DSDT to
a SSDT that can be reused on all SGI/RD platforms.

Change-Id: I958298ffc0f454db52728276a3ae6b92b144e544
Signed-off-by: Aditya Angadi 
---
 .../ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl   | 70 +--
 .../SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf  |  3 +-
 .../ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl   | 69 +-
 .../SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf  |  3 +-
 .../AcpiTables/RdN1EdgeX2AcpiTables.inf   |  1 +
 Platform/ARM/SgiPkg/AcpiTables/SsdtRos.asl| 90 +++
 6 files changed, 97 insertions(+), 139 deletions(-)
 create mode 100644 Platform/ARM/SgiPkg/AcpiTables/SsdtRos.asl

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl 
b/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl
index 5583e61097..d66c7cbf41 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Dsdt.asl
@@ -1,7 +1,7 @@
 /** @file
 *  Differentiated System Description Table Fields (DSDT)
 *
-*  Copyright (c) 2018, ARM Ltd. All rights reserved.
+*  Copyright (c) 2018-2020, ARM Ltd. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -208,73 +208,5 @@ DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "ARMLTD", 
"ARMSGI",
   Name (_STA, 0xF)
 }
 
-// UART PL011
-Device (COM0) {
-  Name (_HID, "ARMH0011")
-  Name (_CID, "ARMH0011")
-  Name (_UID, Zero)
-  Name (_STA, 0xF)
-  Name (_CRS, ResourceTemplate() {
-Memory32Fixed (
-  ReadWrite,
-  FixedPcdGet64 (PcdSerialDbgRegisterBase),
-  0x1000
-)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { 147 }
-  })
-}
-
-// SMSC 91C111
-Device (ETH0) {
-  Name (_HID, "LNRO0003")
-  Name (_UID, Zero)
-  Name (_STA, 0xF)
-  Name (_CRS, ResourceTemplate() {
-Memory32Fixed (ReadWrite, 0x1800, 0x1000)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { 111 }
-  })
-  Name (_DSD, Package() {
-ToUUID ("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
-Package () {
-  Package (2) {"reg-io-width", 4 },
-}
-  })
-}
-
-// VIRTIO DISK
-Device (VR00) {
-  Name (_HID, "LNRO0005")
-  Name (_UID, 0)
-  Name (_CCA, 1)// mark the device coherent
-
-  Name (_CRS, ResourceTemplate() {
-Memory32Fixed (
-  ReadWrite,
-  FixedPcdGet32 (PcdVirtioBlkBaseAddress),
-  FixedPcdGet32 (PcdVirtioBlkSize)
-)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) {
-  FixedPcdGet32 (PcdVirtioBlkInterrupt)
-}
-  })
-}
-
-// VIRTIO NET
-Device (VR01) {
-  Name (_HID, "LNRO0005")
-  Name (_UID, 1)
-  Name (_CCA, 1)// mark the device coherent
-
-  Name (_CRS, ResourceTemplate() {
-Memory32Fixed (
-  ReadWrite,
-  FixedPcdGet32 (PcdVirtioNetBaseAddress),
-  FixedPcdGet32 (PcdVirtioNetSize)
-)
-Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) {
-  FixedPcdGet32 (PcdVirtioNetInterrupt)
-}
-  })
-}
   } // Scope(_SB)
 }
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf 
b/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf
index 3a4d4e7b95..b08d7c2df5 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf
@@ -1,7 +1,7 @@
 ## @file
 #  ACPI table data and ASL sources required to boot the platform.
 #
-#  Copyright (c) 2018, ARM Ltd. All rights reserved.
+#  Copyright (c) 2018-2020, ARM Ltd. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -16,6 +16,7 @@
 
 [Sources]
   Dbg2.aslc
+  SsdtRos.asl
   Fadt.aslc
   Gtdt.aslc
   Iort.aslc
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl 
b/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl
index 45316d5005..cb05eed358 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl
@@ -1,7 +1,7 @@
 /** @file
 *  Differentiated System Description Table Fields (DSDT)
 *
-*  Copyright (c) 2018, ARM Ltd. All rights reserved.
+*  Copyright (c) 2018-2020, ARM Ltd. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -62,72 +62,5 @@ DefinitionBlock ("DsdtTable.aml", "DSDT", 1, "ARMLTD", 
"ARMSGI",
   Name (_STA, 0xF)
 }
 
-// UART PL011
-Device (COM0) {
-  Name (_HID, "ARMH0011")
-  Name (_CID, "ARMH0011")
-  Name (_UID, Zero)
-  Name (_STA, 0xF)
-  Name (_CRS, ResourceTemplate () {
-Memory32Fixed (
-  ReadWrite,
-  FixedPcdGet64 (PcdSerialDbgRegisterBase),
-  0x1000
-  )
-Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { 147 }
-  })
-}
-
-// SMSC 91C111
-Device (ETH0) {
-  Name (_HID, "LNRO0

[edk2-devel] [edk2-platforms][PATCH 8/8] Platform/ARM/Sgi: Add initial support for RD-Daniel Config-XLR platform

[Aditya Angadi]

For RD-Daniel Config-XLR, use multichip mode information from the SGI
platform descriptor HOB to pick the correct ACPI table to be installed.

Change-Id: Ide397344a064a267333aed5e0b58499ee8f8439c
Signed-off-by: Aditya Angadi 
---
 Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c   | 5 +
 Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf | 1 +
 Platform/ARM/SgiPkg/Include/SgiPlatform.h   | 1 +
 3 files changed, 7 insertions(+)

diff --git a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c 
b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
index 7e0de765f7..b1f5714b93 100644
--- a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
+++ b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.c
@@ -51,6 +51,11 @@ STATIC SGI_PLATFORM_ACPI_TABLE_GUID_LOOKUP 
AcpiTableGuidLookup[] = {
   RD_DANIEL_CFGM_CONF_ID,
   MULTI_CHIP_MODE_DISABLED,
   &gRdDanielCfgMAcpiTablesFileGuid),
+  ACPI_GUID_LOOKUP (
+  RD_DANIEL_PART_NUM,
+  RD_DANIEL_CFGXLR_CONF_ID,
+  MULTI_CHIP_MODE_ENABLED,
+  &gRdDanielCfgXlrAcpiTablesFileGuid),
 };
 
 VOID
diff --git a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf 
b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
index 82569820b7..00cbe608c2 100644
--- a/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
+++ b/Platform/ARM/SgiPkg/Drivers/PlatformDxe/PlatformDxe.inf
@@ -35,6 +35,7 @@
   gRdN1EdgeX2AcpiTablesFileGuid
   gRdE1EdgeAcpiTablesFileGuid
   gRdDanielCfgMAcpiTablesFileGuid
+  gRdDanielCfgXlrAcpiTablesFileGuid
 
 [FeaturePcd]
   gArmSgiTokenSpaceGuid.PcdVirtioBlkSupported
diff --git a/Platform/ARM/SgiPkg/Include/SgiPlatform.h 
b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
index b6a427b8b6..9822858f6e 100644
--- a/Platform/ARM/SgiPkg/Include/SgiPlatform.h
+++ b/Platform/ARM/SgiPkg/Include/SgiPlatform.h
@@ -73,6 +73,7 @@
 //RDDANIEL Platform Identification values
 #define RD_DANIEL_PART_NUM0x78A
 #define RD_DANIEL_CFGM_CONF_ID0x1
+#define RD_DANIEL_CFGXLR_CONF_ID  0x2
 
 #define SGI_CONFIG_MASK   0x0F
 #define SGI_CONFIG_SHIFT  0x1C
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55806): https://edk2.groups.io/g/devel/message/55806
Mute This Topic: https://groups.io/mt/71902050/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 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

[Daniel Schaefer]

Hi Leif,

you're right. If I revert my commit and include
  NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
without making any changes to it, the build succeeds.

What do others think? (cc Michael, Pete, Andrew, Ard, who have made changes to 
this module)
Is this a big hack or should we use it in RISC-V, too and move the module to 
MdeModulePkg?
Why isn't this a problem on x86? Was it fine on Itanium?

- Daniel


From: devel@edk2.groups.io 
 on behalf of Leif Lindholm 

Sent: Thursday, March 12, 2020 11:55
To: devel@edk2.groups.io 
; Schaefer, Daniel 
(DualStudy) 
Cc: Chang, Abner (HPS SW/FW Technologist) 
; Chen, Gilbert 
; Dandan Bi 
; Eric Dong 

Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of 
GUID assignment

Hi Daniel,

There is nothing wrong with this patch that just went in (and I should
have called out sooner if I wanted to stop it), but I think a better
solution is to implement a RISC-V variant of
ArmPkg/Library/CompilerIntrinsicsLib/.

It is perfectly valid for the compiler to generate memcpy calls in
response to struct operations that are perfectly valid C.

In fact, we could consider moving the ArmPkg one over into
MdeModulePkg. I have a feeling that including a
  NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
in your current build would be an alternative solution to your
compilation error.

/
Leif

On Mon, Mar 02, 2020 at 11:32:38 +0100, Daniel Schaefer wrote:
> GCC translates a simple assignment to memcpy, which EDKII doesn't provide.
> See: https://www.mail-archive.com/edk2-devel@lists.01.org/msg11928.html
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2547
>
> Signed-off-by: Daniel Schaefer 
> 
> Cc: Abner Chang 
> Cc: Gilbert Chen 
> Cc: Leif Lindholm 
> Cc: Dandan Bi 
> Cc: Eric Dong 
> ---
>
> Notes:
> v2:
>   - Use CopyMem instead of CopyGuid [Dandan]
>
>  MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c 
> b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> index 5cc527679a78..0540e6fa8a44 100644
> --- a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> +++ b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> @@ -619,7 +619,7 @@ CreateDeviceManagerForm(
>  TokenHelp = HiiSetString (HiiHandle, 0, String, NULL);
>  FreePool (String);
>
> -FormSetGuid = ((EFI_IFR_FORM_SET *)Ptr)->Guid;
> +CopyMem (&FormSetGuid, &((EFI_IFR_FORM_SET *) Ptr)->Guid, sizeof 
> (EFI_GUID));
>
>  //
>  // Network device process
> --
> 2.25.0
>
>
>
>




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55800): https://edk2.groups.io/g/devel/message/55800
Mute This Topic: https://groups.io/mt/71671270/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 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

[Ni, Ray]

Leif,
Does CompilerIntrinsicsLib exist because GCC doesn't support to disable 
intrinsic?
How does the linker find the CompilerInstrinsicsLib in linking phase?

Thanks,
Ray

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Leif
> Lindholm
> Sent: Thursday, March 12, 2020 6:55 PM
> To: devel@edk2.groups.io; daniel.schae...@hpe.com
> Cc: Abner Chang ; Gilbert Chen
> ; Bi, Dandan ; Dong, Eric
> 
> Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem
> instead of GUID assignment
> 
> Hi Daniel,
> 
> There is nothing wrong with this patch that just went in (and I should
> have called out sooner if I wanted to stop it), but I think a better
> solution is to implement a RISC-V variant of
> ArmPkg/Library/CompilerIntrinsicsLib/.
> 
> It is perfectly valid for the compiler to generate memcpy calls in
> response to struct operations that are perfectly valid C.
> 
> In fact, we could consider moving the ArmPkg one over into
> MdeModulePkg. I have a feeling that including a
>   NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> in your current build would be an alternative solution to your
> compilation error.
> 
> /
> Leif
> 
> On Mon, Mar 02, 2020 at 11:32:38 +0100, Daniel Schaefer wrote:
> > GCC translates a simple assignment to memcpy, which EDKII doesn't
> provide.
> > See: https://www.mail-archive.com/edk2-
> de...@lists.01.org/msg11928.html
> >
> > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2547
> >
> > Signed-off-by: Daniel Schaefer 
> > Cc: Abner Chang 
> > Cc: Gilbert Chen 
> > Cc: Leif Lindholm 
> > Cc: Dandan Bi 
> > Cc: Eric Dong 
> > ---
> >
> > Notes:
> > v2:
> >   - Use CopyMem instead of CopyGuid [Dandan]
> >
> >  MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> > index 5cc527679a78..0540e6fa8a44 100644
> > --- a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> > +++ b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> > @@ -619,7 +619,7 @@ CreateDeviceManagerForm(
> >  TokenHelp = HiiSetString (HiiHandle, 0, String, NULL);
> >  FreePool (String);
> >
> > -FormSetGuid = ((EFI_IFR_FORM_SET *)Ptr)->Guid;
> > +CopyMem (&FormSetGuid, &((EFI_IFR_FORM_SET *) Ptr)->Guid,
> sizeof (EFI_GUID));
> >
> >  //
> >  // Network device process
> > --
> > 2.25.0
> >
> >
> >
> >
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55799): https://edk2.groups.io/g/devel/message/55799
Mute This Topic: https://groups.io/mt/71671270/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 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment

[Leif Lindholm]

Hi Daniel,

There is nothing wrong with this patch that just went in (and I should
have called out sooner if I wanted to stop it), but I think a better
solution is to implement a RISC-V variant of
ArmPkg/Library/CompilerIntrinsicsLib/.

It is perfectly valid for the compiler to generate memcpy calls in
response to struct operations that are perfectly valid C.

In fact, we could consider moving the ArmPkg one over into
MdeModulePkg. I have a feeling that including a
  NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
in your current build would be an alternative solution to your
compilation error.

/
Leif

On Mon, Mar 02, 2020 at 11:32:38 +0100, Daniel Schaefer wrote:
> GCC translates a simple assignment to memcpy, which EDKII doesn't provide.
> See: https://www.mail-archive.com/edk2-devel@lists.01.org/msg11928.html
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2547
> 
> Signed-off-by: Daniel Schaefer 
> Cc: Abner Chang 
> Cc: Gilbert Chen 
> Cc: Leif Lindholm 
> Cc: Dandan Bi 
> Cc: Eric Dong 
> ---
> 
> Notes:
> v2:
>   - Use CopyMem instead of CopyGuid [Dandan]
> 
>  MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c 
> b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> index 5cc527679a78..0540e6fa8a44 100644
> --- a/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> +++ b/MdeModulePkg/Library/DeviceManagerUiLib/DeviceManager.c
> @@ -619,7 +619,7 @@ CreateDeviceManagerForm(
>  TokenHelp = HiiSetString (HiiHandle, 0, String, NULL);
>  FreePool (String);
>  
> -FormSetGuid = ((EFI_IFR_FORM_SET *)Ptr)->Guid;
> +CopyMem (&FormSetGuid, &((EFI_IFR_FORM_SET *) Ptr)->Guid, sizeof 
> (EFI_GUID));
>  
>  //
>  // Network device process
> -- 
> 2.25.0
> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55798): https://edk2.groups.io/g/devel/message/55798
Mute This Topic: https://groups.io/mt/71671270/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 5/5] OvmfPkg: improve SMM comms security with adaptive MemoryTypeInformation

[Leif Lindholm]

On Thu, Mar 12, 2020 at 01:30:10 +0100, Laszlo Ersek wrote:
> On 03/11/20 20:36, Leif Lindholm wrote:
> > On Wed, Mar 11, 2020 at 17:22:47 +0100, Laszlo Ersek wrote:
>  +STATIC EFI_MEMORY_TYPE_INFORMATION mDefaultMemoryTypeInformation[] = {
>  +  { EfiACPIMemoryNVS,   0x004 },
>  +  { EfiACPIReclaimMemory,   0x008 },
>  +  { EfiReservedMemoryType,  0x004 },
>  +  { EfiRuntimeServicesData, 0x024 },
>  +  { EfiRuntimeServicesCode, 0x030 },
>  +  { EfiBootServicesCode,0x180 },
>  +  { EfiBootServicesData,0xF00 },
>  +  { EfiMaxMemoryType,   0x000 }
>  +};
> >>>
> >>> Could you add a comment as to where these page counts come from?
> >>> Oh, right, they're just moved across from OvmfPkg/PlatformPei/Platform.c.
> >>>
> >>> It *would* be nice if that could be cleaned up at the same time...
> >>
> >> Sorry, I don't understand -- what kind of cleanup do you have in mind
> >> precisely? The table is not copied, but moved from the original place,
> >> so I'm unsure what's left in "Platform.c" to clean up.
> > 
> > Not left to clean up there, but something to consider addressing when
> > moving it here. Yes, it's just a move, so we could argue it doesn't
> > need fixing - but it's a struct with a bunch of live-coded numerical
> > values completely without explanation.
> > 
> > "I'd rather not" is an acceptable answer, but I figured I should point
> > it out.
> 
> Good point!
> 
> Yet, I'd rather not :) Long read ahead:
> 
> This table is used for priming the memory type BINs in the DXE Core.
> After this set, in non-SMM builds, the functionality will remain the
> same (the table stays in effect for every boot); in SMM builds, the
> table is only a starting point for the feedback loop.
> 
> What's important is that the numbers in the table are entirely ad-hoc.
> They were last updated in commit 991d95636264, in 2010. They capture a
> set of BIN hints that made sense at the time, for *some* (now unknown)
> workloads / boot paths. That's the important trait of this table: it
> made sense at some point in time, for some use case. That's the property
> we should not regress.
> 
> So let's consider the possible ways to improve the table.

There is fixing and there is improving.

The preceding paragraph as a comment block would prevent the next
person who comes across it going "Where the $EXPLETIVE did these
numbers come from?".

(Adding the preceding paragraph as well would have saved me another
minute of grepping, but that is more down to the fact that this is a
repeating pattern implemented differently for different platforms -
for most ARM platforms partly hidden away in EmbeddedPkg:
https://github.com/tianocore/edk2/blob/master/EmbeddedPkg/EmbeddedPkg.dec#L104)

> (1) Given that in SMM builds, the table will function only as a starting
> point for the feedback loop, start using two tables. A new one (for the
> SMM build) with nice numbers (everything 0x1, or everyting 0x1000,
> whatever), and keep the old one for the non-SMM build.
> 
> Unfortunately, this "improvement" is a net negative, because then we'd
> have *more* stuff, on top of the *current* dump-of-obscure-numbers.
> 
> (2) Keep the one table, but replace the values with nicer looking
> numbers (see examples above). Unfortunately, larger numbers could waste
> memory (stuck in BINs and hence in the UEFI memmap) for some boots, and
> smaller page counts would increase memmap fragmentation.
> 
> We might cause some (at best, superficial) regressions. And we'd lose
> the property "this table made sense at some point in time" -- because
> the new ad-hoc numbers wouldn't even be rooted in measurements.
> 
> (3) Actually measure various boots and try to derive new page counts
> from those.
> 
> This is something I'm not prepared to do. The memory needs (considering
> the various memory types too), depend on a bunch of stuff:
> 
> - ACPI tables generated by QEMU (influences AcpiNVS, AcpiReclaim, and
> even Reserved -- some opcodes in QEMU's ACPI linker/loader script
> require the production of S3 boot script opcodes). For example if the
> QEMU command line specifies the vmgenid device, then the S3 boot script
> stuff applies.
> 
> - S3 support enabled/disabled in general on the QEMU cmdline.
> 
> - OS bootloader footprint.

- Separately loaded drivers (including Option ROMs?), making these
  numers impossible to precisely determine statically.

> This approach would uphold the property "has been useful at some point
> in time, for some workloads" -- but it's too much time to research, and
> it's anyway obviated by the dynamic / adaptive approach that this series
> enables for OVMF (in the SMM build).
> 
> (4) OK, so let's not touch the numeric values, but move them out of the
> table?
> 
> (4a) Introduce macros.
> 
> Not a good idea, as these numbers are never referenced anywhere else.
> The following:
> 
> #define MTI_RT_DATA_PAGE_COUNT 0x024
> ...
>   { EfiRuntimeServicesData, MTI_RT_DATA_PAGE_COUNT },
> 
> is

Re: [edk2-devel] [patch v2] OvmfPkg: Fix build failure with VS2015 tool chain

[Laszlo Ersek]

Hello Liming,

(adding Michael)

On 03/12/20 05:30, Liming Gao wrote:
> warning C4244: '=': conversion from 'UINTN' to 'UINT32', possible loss of data
> With this fix, OvmfIa32, OvmfX64 and OvmfIa32X64 can pass build.
> 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Liming Gao 
> ---
>  OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c 
> b/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c
> index 1868c9fcaf..1f02da2503 100644
> --- a/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c
> +++ b/OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.c
> @@ -384,7 +384,7 @@ QemuLoadKernelImage (
>  //
>  // Drop the terminating NUL, convert to UTF-16.
>  //
> -KernelLoadedImage->LoadOptionsSize = (CommandLineSize - 1) * 2;
> +KernelLoadedImage->LoadOptionsSize = (UINT32) ((CommandLineSize - 1) * 
> 2);
>}
>  
>QemuFwCfgSelectItem (QemuFwCfgItemInitrdSize);
> 

This patch seems to be fixing the pre-existent TianoCore ticket

https://bugzilla.tianocore.org/show_bug.cgi?id=2582

Can you please coordinate with Michael?

BTW, I prefer this patch to the one that Michael attached to the ticket
in .

So my suggestion is for Liming to reassign the BZ to himself please,
reference the BZ in the commit message, and then merge this patch.

Reviewed-by: Laszlo Ersek 

Thanks,
Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55796): https://edk2.groups.io/g/devel/message/55796
Mute This Topic: https://groups.io/mt/71896179/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2/master PATCH RISC-V CI Code Changes v1 01/11] FatPkg: Add RISC-V architecture for EDK2 CI.

[Ni, Ray]

Reviewed-by: Ray Ni 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Abner Chang
> Sent: Friday, March 6, 2020 1:36 PM
> To: devel@edk2.groups.io
> Cc: abner.ch...@hpe.com; Ni, Ray ; Leif Lindholm 
> ; Gilbert Chen
> ; Daniel Schaefer 
> Subject: [edk2-devel] [edk2/master PATCH RISC-V CI Code Changes v1 01/11] 
> FatPkg: Add RISC-V architecture for EDK2 CI.
> 
> BZ:2562:
> https://bugzilla.tianocore.org/show_bug.cgi?id=2562
> 
> Add RISC-V architecture for EDK2 CI testing.
> 
> Signed-off-by: Abner Chang 
> 
> Cc: Ray Ni 
> Cc: Leif Lindholm 
> Cc: Gilbert Chen 
> Cc: Daniel Schaefer 
> ---
>  FatPkg/FatPkg.dsc | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/FatPkg/FatPkg.dsc b/FatPkg/FatPkg.dsc
> index 1676c2eb8f..d86256068b 100644
> --- a/FatPkg/FatPkg.dsc
> +++ b/FatPkg/FatPkg.dsc
> @@ -4,6 +4,7 @@
>  #  This Platform file is used to generate the Binary Fat Drivers
> 
>  #  for EDK II Prime release.
> 
>  #  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
> 
> +#  Copyright (c) 2020, Hewlett Packard Enterprise Development LP. All rights 
> reserved.
> 
>  #
> 
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  #
> 
> @@ -14,7 +15,7 @@
>PLATFORM_GUID  = 25b55dbc-9d0b-4a32-80da-46e1273d622c
> 
>PLATFORM_VERSION   = 0.3
> 
>DSC_SPECIFICATION  = 0x00010005
> 
> -  SUPPORTED_ARCHITECTURES= IA32|X64|EBC|ARM|AARCH64
> 
> +  SUPPORTED_ARCHITECTURES= IA32|X64|EBC|ARM|AARCH64|RISCV64
> 
>OUTPUT_DIRECTORY   = Build/Fat
> 
>BUILD_TARGETS  = DEBUG|RELEASE|NOOPT
> 
>SKUID_IDENTIFIER   = DEFAULT
> 
> --
> 2.25.0
> 
> 
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> 
> View/Reply Online (#55584): https://edk2.groups.io/g/devel/message/55584
> Mute This Topic: https://groups.io/mt/71767323/1712937
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub  [ray...@intel.com]
> -=-=-=-=-=-=


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#55795): https://edk2.groups.io/g/devel/message/55795
Mute This Topic: https://groups.io/mt/71767323/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-