Re: [edk2-devel] [edk2][PATCH 1/1] MdePkg/Include: Add DCC and BCM2835 SPCR UART types

[Ard Biesheuvel]

On Thu, 12 Dec 2019 at 01:26, Gao, Liming  wrote:
>
> Reviewed-by: Liming Gao 
>

Thanks

Pushed as bfb141cf19dd6f9b8df8b9d0914a5b3b15e1a798


> > -Original Message-
> > From: Ard Biesheuvel 
> > Sent: Wednesday, December 11, 2019 6:01 PM
> > To: Pete Batard ; Kinney, Michael D 
> > ; Gao, Liming 
> > Cc: edk2-devel-groups-io ; Leif Lindholm 
> > ; Philippe Mathieu-Daudé
> > 
> > Subject: Re: [edk2][PATCH 1/1] MdePkg/Include: Add DCC and BCM2835 SPCR 
> > UART types
> >
> > (add MdePkg maintainers)
> >
> > On Tue, 10 Dec 2019 at 19:23, Pete Batard  wrote:
> > >
> > > As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
> > > can be found online, we are missing 2 serial interface types for
> > > Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).
> > >
> > > These same types are present in DebugPort2Table.h so add them to
> > > SerialPortConsoleRedirectionTable.h too.
> > >
> > > Note that we followed the same idiosyncrasies as DebugPort2Table
> > > for naming these new macros.
> > >
> > > Signed-off-by: Pete Batard 
> >
> > Acked-by: Ard Biesheuvel 
> >
> > > ---
> > >  MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h | 10 
> > > ++
> > >  1 file changed, 10 insertions(+)
> > >
> > > diff --git 
> > > a/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> > b/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> > > index b069fb2be97f..2066c7895e59 100644
> > > --- a/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> > > +++ b/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> > > @@ -90,6 +90,16 @@ typedef struct {
> > >  ///
> > >  #define 
> > > EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_ARM_SBSA_GENERIC_UART
> > >  0x0e
> > >
> > > +///
> > > +/// ARM DCC
> > > +///
> > > +#define 
> > > EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_DCC 
> > >   0x0f
> > > +
> > > +///
> > > +/// BCM2835 UART
> > > +///
> > > +#define 
> > > EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_BCM2835_UART
> > >   0x10
> > > +
> > >  //
> > >  // Interrupt Type
> > >  //
> > > --
> > > 2.21.0.windows.1
> > >

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

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

Re: [edk2-devel] [PATCH] ShellPkg/ShellProtocol: Return error code while fail parsing cmd-line

[Ni, Ray]

Reviewed-by: Ray Ni 

> -Original Message-
> From: Gao, Zhichao 
> Sent: Monday, December 2, 2019 8:54 AM
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Augustine, Linson 
> Subject: [PATCH] ShellPkg/ShellProtocol: Return error code while fail parsing 
> cmd-line
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2395
> 
> Errors happened in the arguments parsing is not a critical error.
> And it would miss the error status code in the release version of shell.
> So replace the ASSERT with returning error status code while fail
> parsing command-line in UpdateArgcArgv.
> 
> Cc: Ray Ni 
> Cc: Linson Augustine 
> Signed-off-by: Zhichao Gao 
> ---
>  ShellPkg/Application/Shell/ShellProtocol.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/ShellPkg/Application/Shell/ShellProtocol.c 
> b/ShellPkg/Application/Shell/ShellProtocol.c
> index 5e529b6568..f0362a42d8 100644
> --- a/ShellPkg/Application/Shell/ShellProtocol.c
> +++ b/ShellPkg/Application/Shell/ShellProtocol.c
> @@ -1497,7 +1497,10 @@ InternalShellExecuteDevicePath(
>  ShellParamsProtocol.StdOut  = 
> ShellInfoObject.NewShellParametersProtocol->StdOut;
>  ShellParamsProtocol.StdErr  = 
> ShellInfoObject.NewShellParametersProtocol->StdErr;
>  Status = UpdateArgcArgv(&ShellParamsProtocol, NewCmdLine, 
> Efi_Application, NULL, NULL);
> -ASSERT_EFI_ERROR(Status);
> +if (EFI_ERROR (Status)) {
> +  goto UnloadImage;
> +}
> +
>  //
>  // Replace Argv[0] with the full path of the binary we're executing:
>  // If the command line was "foo", the binary might be called "foo.efi".
> --
> 2.21.0.windows.1


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

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

Re: [edk2-devel] [RFC PATCH v3 35/43] UefiCpuPkg/MpInitLib: Add a CPU MP data flag to indicate if SEV-ES is enabled

[Ni, Ray]

OK I see now the Enable PCD is defined in MdeModulePkg, produced in platform 
and consumed in MpInitLib.

Is there a way to easily detect whether SEV-ES is enabled? (without triggering 
CPUID as what SEC does)

If no, can you define the PCD in UefiCpuPkg?


> -Original Message-
> From: Tom Lendacky 
> Sent: Thursday, November 21, 2019 4:07 AM
> To: devel@edk2.groups.io
> Cc: Justen, Jordan L ; Laszlo Ersek 
> ; Ard Biesheuvel
> ; Kinney, Michael D ; 
> Gao, Liming ; Dong,
> Eric ; Ni, Ray ; Brijesh Singh 
> 
> Subject: [RFC PATCH v3 35/43] UefiCpuPkg/MpInitLib: Add a CPU MP data flag to 
> indicate if SEV-ES is enabled
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
> 
> When starting APs in an SMP configuration, the AP needs to know if it is
> running as an SEV-ES guest in order to assign a GHCB page.
> 
> Add a field to the CPU_MP_DATA structure that will indicate if SEV-ES is
> enabled. This new field is set during MP library initialization with the
> PCD value PcdSevEsIsEnabled. This flag can then be used to determine if
> SEV-ES is enabled.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Signed-off-by: Tom Lendacky 
> ---
>  UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf | 1 +
>  UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf | 1 +
>  UefiCpuPkg/Library/MpInitLib/MpLib.h  | 2 ++
>  UefiCpuPkg/Library/MpInitLib/MpLib.c  | 1 +
>  4 files changed, 5 insertions(+)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf 
> b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> index cd912ab0c5ee..f84dbb09ae49 100644
> --- a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
> @@ -69,4 +69,5 @@ [Pcd]
>gUefiCpuPkgTokenSpaceGuid.PcdCpuApLoopMode   ## 
> CONSUMES
>gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate   ## 
> SOMETIMES_CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard  ## 
> CONSUMES
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSevEsIsEnabled ## 
> CONSUMES
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf 
> b/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
> index 1538185ef99a..9c1215ec75d0 100644
> --- a/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
> +++ b/UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf
> @@ -60,6 +60,7 @@ [Pcd]
>gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchRegionSize ## 
> CONSUMES
>gUefiCpuPkgTokenSpaceGuid.PcdCpuApLoopMode   ## 
> CONSUMES
>gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate   ## 
> SOMETIMES_CONSUMES
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSevEsIsEnabled ## 
> CONSUMES
> 
>  [Guids]
>gEdkiiS3SmmInitDoneGuid
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.h 
> b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> index 8fa07b12c5e1..c10fe894cf9b 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.h
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.h
> @@ -259,6 +259,8 @@ struct _CPU_MP_DATA {
>// driver.
>//
>BOOLEANWakeUpByInitSipiSipi;
> +
> +  BOOLEANSevEsIsEnabled;
>  };
> 
>  extern EFI_GUID mCpuInitMpLibHobGuid;
> diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
> b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> index 49be5d5385d9..aa25bf9b3671 100644
> --- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
> +++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
> @@ -1708,6 +1708,7 @@ MpInitLibInitialize (
>  CpuMpData->MicrocodePatchAddress= 
> OldCpuMpData->MicrocodePatchAddress;
>}
>InitializeSpinLock(&CpuMpData->MpLock);
> +  CpuMpData->SevEsIsEnabled = PcdGetBool (PcdSevEsIsEnabled);
> 
>//
>// Make sure no memory usage outside of the allocated buffer.
> --
> 2.17.1


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

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

Re: [edk2-devel] [RFC PATCH v3 33/43] MdeModulePkg: Reserve a 16-bit protected mode code segment descriptor

[Ni, Ray]

Is the 16bit code segment descriptor needed in early DXE before CpuDxe (DXE MP)?

> -Original Message-
> From: Tom Lendacky 
> Sent: Thursday, November 21, 2019 4:07 AM
> To: devel@edk2.groups.io
> Cc: Justen, Jordan L ; Laszlo Ersek 
> ; Ard Biesheuvel
> ; Kinney, Michael D ; 
> Gao, Liming ; Dong,
> Eric ; Ni, Ray ; Brijesh Singh 
> ; Wang, Jian J
> ; Wu, Hao A ; Bi, Dandan 
> 
> Subject: [RFC PATCH v3 33/43] MdeModulePkg: Reserve a 16-bit protected mode 
> code segment descriptor
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
> 
> SEV-ES guest AP boot support needs to transition from 64-bit long mode
> into 16-bit real mode. This will require a 16-bit code segment descriptor.
> Reserve one of the spare segment descriptors (0x28) for this purpose.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Dandan Bi 
> Cc: Liming Gao 
> Signed-off-by: Tom Lendacky 
> ---
>  MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c 
> b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
> index 284b34818ca7..c9cf2e36214f 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
> +++ b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
> @@ -33,7 +33,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED IA32_GDT gGdtEntries[] = {
>  /* 0x10 */  {{0x, 0,  0,  0xf,  1,  0,  1,  0xf,  0,  0, 1,  1,  0}}, 
> //linear code segment descriptor
>  /* 0x18 */  {{0x, 0,  0,  0x3,  1,  0,  1,  0xf,  0,  0, 1,  1,  0}}, 
> //system data segment descriptor
>  /* 0x20 */  {{0x, 0,  0,  0xa,  1,  0,  1,  0xf,  0,  0, 1,  1,  0}}, 
> //system code segment descriptor
> -/* 0x28 */  {{0,  0,  0,  0,0,  0,  0,  0,0,  0, 0,  0,  0}}, 
> //spare segment descriptor
> +/* 0x28 */  {{0x, 0,  0,  0xa,  1,  0,  1,  0xf,  0,  0, 0,  1,  0}}, 
> //system code16 segment descriptor
>  /* 0x30 */  {{0x, 0,  0,  0x2,  1,  0,  1,  0xf,  0,  0, 1,  1,  0}}, 
> //system data segment descriptor
>  /* 0x38 */  {{0x, 0,  0,  0xa,  1,  0,  1,  0xf,  0,  1, 0,  1,  0}}, 
> //system code segment descriptor
>  /* 0x40 */  {{0,  0,  0,  0,0,  0,  0,  0,0,  0, 0,  0,  0}}, 
> //spare segment descriptor
> --
> 2.17.1


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

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

Re: [edk2-devel] [RFC PATCH v3 28/43] OvmfPkg: Create GHCB pages for use during Pei and Dxe phase

[Ni, Ray]

> +  // Allocate GHCB and per-CPU variable pages.
> +  //
> +  GhcbPageCount = mMaxCpuCount * 2;
> +  GhcbBase = AllocatePages (GhcbPageCount);
> +  ASSERT (GhcbBase != NULL);
> +
> +  GhcbBasePa = (PHYSICAL_ADDRESS)(UINTN) GhcbBase;
> +
> +  DecryptStatus = MemEncryptSevClearPageEncMask (
> +0,
> +GhcbBasePa,
> +GhcbPageCount,
> +TRUE
> +);
> +  ASSERT_RETURN_ERROR (DecryptStatus);
> +
> +  ZeroMem (GhcbBase, EFI_PAGES_TO_SIZE (GhcbPageCount));
> +
> +  PcdStatus = PcdSet64S (PcdGhcbBase, GhcbBasePa);
> +  ASSERT_RETURN_ERROR (PcdStatus);
> +  PcdStatus = PcdSet64S (PcdGhcbSize, EFI_PAGES_TO_SIZE (GhcbPageCount));
> +  ASSERT_RETURN_ERROR (PcdStatus);
> +
> +  DEBUG ((DEBUG_INFO,
> +"SEV-ES is enabled, %lu GHCB pages allocated starting at 0x%p\n",
> +(UINT64)GhcbPageCount, GhcbBase));
> +
> +  AsmWriteMsr64 (MSR_SEV_ES_GHCB, GhcbBasePa);

As I said in the comments to PcdGhcbBase/Size, can all PCD consumers read the 
GHCB MSR instead?

Does the GHCB buffer contains size information? If no, how does CPU know the 
GHCB buffer size?
I am asking this because I want to see a way to remove the PcdGhcbSize.

Thanks,
Ray

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

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

Re: [edk2-devel] [RFC PATCH v3 04/43] MdeModulePkg/DxeIplPeim: Support GHCB pages when creating page tables

[Ni, Ray]

Tom,
When are GHCP pages are allocated? Can DxeIpl gets the address by reading the 
GHCB MSR?

Can the GHCB PCD be eliminated by updating all GHCB address consumer to read 
the GHCB MSR?

Thanks,
Ray

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Lendacky, 
> Thomas
> Sent: Thursday, November 21, 2019 4:06 AM
> To: devel@edk2.groups.io
> Cc: Justen, Jordan L ; Laszlo Ersek 
> ; Ard Biesheuvel
> ; Kinney, Michael D ; 
> Gao, Liming ; Dong,
> Eric ; Ni, Ray ; Brijesh Singh 
> ; Wang, Jian J
> ; Wu, Hao A ; Bi, Dandan 
> 
> Subject: [edk2-devel] [RFC PATCH v3 04/43] MdeModulePkg/DxeIplPeim: Support 
> GHCB pages when creating page tables
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
> 
> GHCB pages must be mapped as shared pages, so modify the process of
> creating identity mapped pagetable entries so that GHCB entries are
> created without the encryption bit set.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Dandan Bi 
> Cc: Liming Gao 
> Signed-off-by: Tom Lendacky 
> ---
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf   |  2 +
>  .../Core/DxeIplPeim/X64/VirtualMemory.h   | 12 -
>  .../Core/DxeIplPeim/Ia32/DxeLoadFunc.c|  4 +-
>  .../Core/DxeIplPeim/X64/DxeLoadFunc.c | 11 -
>  .../Core/DxeIplPeim/X64/VirtualMemory.c   | 49 ++-
>  5 files changed, 62 insertions(+), 16 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf 
> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> index 98bc17fc9d1f..5e6b78e295e6 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
> @@ -111,6 +111,8 @@ [Pcd.IA32,Pcd.X64]
>gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask   ## 
> CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard   ## 
> CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdUse5LevelPageTable  ## 
> SOMETIMES_CONSUMES
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase## 
> CONSUMES
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbSize## 
> CONSUMES
> 
>  [Pcd.IA32,Pcd.X64,Pcd.ARM,Pcd.AARCH64]
>gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack   ## 
> SOMETIMES_CONSUMES
> diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
> b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
> index 2d0493f109e8..6b7c38a441d6 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
> +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
> @@ -201,6 +201,8 @@ EnableExecuteDisableBit (
>@param[in, out] PageEntry2M   Pointer to 2M page entry.
>@param[in]  StackBase Stack base address.
>@param[in]  StackSize Stack size.
> +  @param[in]  GhcbBase  GHCB page area base address.
> +  @param[in]  GhcbSize  GHCB page area size.
> 
>  **/
>  VOID
> @@ -208,7 +210,9 @@ Split2MPageTo4K (
>IN EFI_PHYSICAL_ADDRESS   PhysicalAddress,
>IN OUT UINT64 *PageEntry2M,
>IN EFI_PHYSICAL_ADDRESS   StackBase,
> -  IN UINTN  StackSize
> +  IN UINTN  StackSize,
> +  IN EFI_PHYSICAL_ADDRESS   GhcbBase,
> +  IN UINTN  GhcbSize
>);
> 
>  /**
> @@ -217,6 +221,8 @@ Split2MPageTo4K (
> 
>@param[in] StackBase  Stack base address.
>@param[in] StackSize  Stack size.
> +  @param[in] GhcbBase   GHCB page area base address.
> +  @param[in] GhcbSize   GHCB page area size.
> 
>@return The address of 4 level page map.
> 
> @@ -224,7 +230,9 @@ Split2MPageTo4K (
>  UINTN
>  CreateIdentityMappingPageTables (
>IN EFI_PHYSICAL_ADDRESS   StackBase,
> -  IN UINTN  StackSize
> +  IN UINTN  StackSize,
> +  IN EFI_PHYSICAL_ADDRESS   GhcbBase,
> +  IN UINTN  GhcbkSize
>);
> 
> 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c 
> b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
> index 6e8ca824d469..284b34818ca7 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
> +++ b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
> @@ -123,7 +123,7 @@ Create4GPageTablesIa32Pae (
>  //
>  // Need to split this 2M page that covers stack range.
>  //
> -Split2MPageTo4K (PhysicalAddress, (UINT64 *) PageDirectoryEntry, 
> StackBase, StackSize);
> +Split2MPageTo4K (PhysicalAddress, (UINT64 *) PageDirectoryEntry, 
> StackBase, StackSize, 0, 0);
>} else {
>  //
>  // Fill in the Page Directory entries
> @@ -282,7 +282,7 @@ HandOffToDxeCore (
>  //
>  // Create page table and save PageMapLevel4 to CR3
>  //
> -PageTables = CreateIdentityMappingPageTables (BaseOfStack, STACK_SIZE);
> +PageTables = CreateIdentityMappingPageTables (BaseOfStack, STACK_SIZE, 
> 0, 0);
> 
>  //
>  // End of PEI phase signal
>

Re: [edk2-devel] [RFC PATCH v3 22/43] UefiCpuPkg/CpuExceptionHandler: Add support for DR7 Read/Write NAE events

[Ni, Ray]

Tom,
Why all DR registers are not pushed to stack in VC handler?
I thought only DR7 pushing is skipped.

Thanks,
Ray

> -Original Message-
> From: Tom Lendacky 
> Sent: Thursday, November 21, 2019 4:07 AM
> To: devel@edk2.groups.io
> Cc: Justen, Jordan L ; Laszlo Ersek 
> ; Ard Biesheuvel
> ; Kinney, Michael D ; 
> Gao, Liming ; Dong,
> Eric ; Ni, Ray ; Brijesh Singh 
> 
> Subject: [RFC PATCH v3 22/43] UefiCpuPkg/CpuExceptionHandler: Add support for 
> DR7 Read/Write NAE events
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
> 
> Under SEV-ES, a DR7 read or write intercept generates a #VC exception.
> The #VC handler must provide special support to the guest for this. On
> a DR7 write, the #VC handler must cache the value and issue a VMGEXIT
> to notify the hypervisor of the write. However, the #VC handler must
> not actually set the value of the DR7 register. On a DR7 read, the #VC
> handler must return the cached value of the DR7 register to the guest.
> VMGEXIT is not invoked for a DR7 register read.
> 
> To avoid exception recursion, a #VC exception will not try to read and
> push the actual debug registers into the EFI_SYSTEM_CONTEXT_X64 struct
> and instead push zeroes. The #VC exception handler does not make use of
> the debug registers from saved context.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Signed-off-by: Tom Lendacky 
> ---
>  .../X64/AMDSevVcCommon.c  | 68 +++
>  .../X64/ExceptionHandlerAsm.nasm  | 15 
>  2 files changed, 83 insertions(+)
> 
> diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
> index 1d7c34e7e442..22393f72d795 100644
> --- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
> +++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/AMDSevVcCommon.c
> @@ -13,6 +13,12 @@
> 
>  #define CR4_OSXSAVE (1 << 18)
> 
> +#define DR7_RESET_VALUE 0x400
> +typedef struct {
> +  BOOLEAN  Dr7Cached;
> +  UINT64   Dr7;
> +} SEV_ES_PER_CPU_DATA;
> +
>  typedef enum {
>LongMode64Bit= 0,
>LongModeCompat32Bit,
> @@ -1081,6 +1087,60 @@ RdtscExit (
>return 0;
>  }
> 
> +STATIC
> +UINTN
> +Dr7WriteExit (
> +  GHCB *Ghcb,
> +  EFI_SYSTEM_CONTEXT_X64   *Regs,
> +  SEV_ES_INSTRUCTION_DATA  *InstructionData
> +  )
> +{
> +  SEV_ES_INSTRUCTION_OPCODE_EXT  *Ext = &InstructionData->Ext;
> +  SEV_ES_PER_CPU_DATA*SevEsData = (SEV_ES_PER_CPU_DATA *) (Ghcb 
> + 1);
> +  INTN   *Register;
> +  UINTN  Status;
> +
> +  DecodeModRm (Regs, InstructionData);
> +
> +  /* MOV DRn always treats MOD == 3 no matter how encoded */
> +  Register = GetRegisterPointer (Regs, Ext->ModRm.Rm);
> +
> +  /* Using a value of 0 for ExitInfo1 means RAX holds the value */
> +  Ghcb->SaveArea.Rax = *Register;
> +  GhcbSetRegValid (Ghcb, GhcbRax);
> +
> +  Status = VmgExit (Ghcb, SvmExitDr7Write, 0, 0);
> +  if (Status) {
> +return Status;
> +  }
> +
> +  SevEsData->Dr7 = *Register;
> +  SevEsData->Dr7Cached = TRUE;
> +
> +  return 0;
> +}
> +
> +STATIC
> +UINTN
> +Dr7ReadExit (
> +  GHCB *Ghcb,
> +  EFI_SYSTEM_CONTEXT_X64   *Regs,
> +  SEV_ES_INSTRUCTION_DATA  *InstructionData
> +  )
> +{
> +  SEV_ES_INSTRUCTION_OPCODE_EXT  *Ext = &InstructionData->Ext;
> +  SEV_ES_PER_CPU_DATA*SevEsData = (SEV_ES_PER_CPU_DATA *) (Ghcb 
> + 1);
> +  INTN   *Register;
> +
> +  DecodeModRm (Regs, InstructionData);
> +
> +  /* MOV DRn always treats MOD == 3 no matter how encoded */
> +  Register = GetRegisterPointer (Regs, Ext->ModRm.Rm);
> +  *Register = (SevEsData->Dr7Cached) ? SevEsData->Dr7 : DR7_RESET_VALUE;
> +
> +  return 0;
> +}
> +
>  UINTN
>  DoVcCommon (
>GHCB*Ghcb,
> @@ -1097,6 +1157,14 @@ DoVcCommon (
> 
>ExitCode = Regs->ExceptionData;
>switch (ExitCode) {
> +  case SvmExitDr7Read:
> +NaeExit = Dr7ReadExit;
> +break;
> +
> +  case SvmExitDr7Write:
> +NaeExit = Dr7WriteExit;
> +break;
> +
>case SvmExitRdtsc:
>  NaeExit = RdtscExit;
>  break;
> diff --git 
> a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
> b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
> index 19198f273137..a0549f7ae6bd 100644
> --- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
> +++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ExceptionHandlerAsm.nasm
> @@ -225,6 +225,9 @@ HasErrorCode:
>  pushrax
> 
>  ;; UINT64  Dr0, Dr1, Dr2, Dr3, Dr6, Dr7;
> +cmp qword [rbp + 8], 29
> +je  VcDebugRegs  ; For SEV-ES (#VC) Debug registers ignored
> +
>  mov rax, dr7
>  pushrax
>  mov rax, dr6
> @@ -237,7 +240,19 @@ HasErrorCode:
>  pushrax
>  mov rax, dr0
>  pushrax
> +jmp DrFinish
> 
> +VcDebugRegs:
> +;; UINT64  Dr0, Dr1, 

Re: [edk2-devel] [RFC PATCH v3 01/43] MdePkg: Create PCDs to be used in support of SEV-ES

[Ni, Ray]

Do you really need to define the PCD in MdePkg?
General guide lines are:
1. Avoid UefiCpuPkg depend on MdeModulePkg.
2. Do not define platform level PCD in core pkgs (MdePkg, MdeModulePkg, 
UefiCpuPkg, etc)


PcdSevEsIsEnabled seems to be used in OVMF pkg only so how about define that in 
OvmfPkg.dec?

Thanks,
Ray

> -Original Message-
> From: Tom Lendacky 
> Sent: Thursday, November 21, 2019 4:06 AM
> To: devel@edk2.groups.io
> Cc: Justen, Jordan L ; Laszlo Ersek 
> ; Ard Biesheuvel
> ; Kinney, Michael D ; 
> Gao, Liming ; Dong,
> Eric ; Ni, Ray ; Brijesh Singh 
> ; Wang, Jian J
> ; Wu, Hao A 
> Subject: [RFC PATCH v3 01/43] MdePkg: Create PCDs to be used in support of 
> SEV-ES
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2198
> 
> Two new fixed PCSs are needed to support SEV-ES under OVMF:
>   - PcdSecGhcbBase  UINT64 value that is the base address of the GHCB
> used during the SEC phase.
>   - PcdSecGhcbSize  UINT64 value that is the size, in bytes, of the GHCB
> area used during the SEC phase.
> 
> Three new dynamic PCDs are needed to support SEV-ES under OVMF:
>   - PcdSevEsIsEnabled: BOOLEAN value used to indicate if SEV-ES is enabled
>   - PcdGhcbBase:   UINT64 value that is the base address of the GHCB
>allocation.
>   - PcdGhcbSize:   UINT64 value that is the size, in bytes, of the
>GHCB allocation (size is dependent on the number of
>APs).
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Signed-off-by: Tom Lendacky 
> ---
>  MdeModulePkg/MdeModulePkg.dec | 23 +++
>  1 file changed, 23 insertions(+)
> 
> diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
> index 41b9e70a1ac8..c3bdfcc80971 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -1037,6 +1037,14 @@ [PcdsFixedAtBuild]
># @Prompt Enable UEFI Stack Guard.
>gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard|FALSE|BOOLEAN|0x30001055
> 
> +  ## The base address of the SEC GHCB page.
> +  # @Prompt SEC GHCB Base Address
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSecGhcbBase|0|UINT32|0x30001056
> +
> +  ## The total size of the SEC GHCB page.
> +  # @Prompt SEC GHCB Size
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSecGhcbSize|0|UINT32|0x30001057
> +
>  [PcdsFixedAtBuild, PcdsPatchableInModule]
>## Dynamic type PCD can be registered callback function for Pcd setting 
> action.
>#  PcdMaxPeiPcdCallBackNumberPerPcdEntry indicates the maximum number of 
> callback function
> @@ -2053,6 +2061,21 @@ [PcdsDynamic, PcdsDynamicEx]
># @Prompt If there is any test key used by the platform.
>gEfiMdeModulePkgTokenSpaceGuid.PcdTestKeyUsed|FALSE|BOOLEAN|0x00030003
> 
> +  ## This dynamic PCD indicates whether SEV-ES is enabled
> +  #   TRUE  - SEV-ES is enabled
> +  #   FALSE - SEV-ES is not enabled
> +  # @Prompt SEV-ES Status
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdSevEsIsEnabled|FALSE|BOOLEAN|0x00030007
> +
> +  ## This dynamic PCD holds the base address of the GHCB pool allocation.
> +  # @Prompt GHCB Pool Base Address
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbBase|0|UINT64|0x00030008
> +
> +  ## This dynamic PCD holds the total size of the GHCB pool allocation.
> +  #  The amount of memory allocated for GHCBs is dependent on the number of 
> APs.
> +  # @Prompt GHCB Pool Size
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdGhcbSize|0|UINT64|0x00030009
> +
>  [PcdsDynamicEx]
>## This dynamic PCD enables the default variable setting.
>#  Its value is the default store ID value. The default value is zero as 
> Standard default.
> --
> 2.17.1


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

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

Re: [edk2-devel] [RFC PATCH v3 22/43] UefiCpuPkg/CpuExceptionHandler: Add support for DR7 Read/Write NAE events

[Ni, Ray]

> 
>  ;; UINT64  Dr0, Dr1, Dr2, Dr3, Dr6, Dr7;
> +cmp qword [rbp + 8], 29

Can you define a macro instead of using 29?

> +je  VcDebugRegs  ; For SEV-ES (#VC) Debug registers ignored



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

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

Re: [edk2-devel] [PATCH] ShellPkg/ShellProtocol: Return error code while fail parsing cmd-line

[Gao, Zhichao]

Hi Ray,

Can you help to review the patch?

Thanks,
Zhichao

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Philippe Mathieu-Daudé
> Sent: Monday, December 2, 2019 7:10 PM
> To: Gao, Zhichao ; devel@edk2.groups.io
> Cc: Ni, Ray ; Augustine, Linson
> 
> Subject: Re: [edk2-devel] [PATCH] ShellPkg/ShellProtocol: Return error code
> while fail parsing cmd-line
> 
> Hi Zhichao,
> 
> On 12/2/19 12:04 PM, Gao, Zhichao wrote:
> >> -Original Message-
> >> From: Philippe Mathieu-Daudé [mailto:phi...@redhat.com]
> >> Sent: Monday, December 2, 2019 6:21 PM
> >> To: devel@edk2.groups.io; Gao, Zhichao 
> >> Cc: Ni, Ray ; Augustine, Linson
> >> 
> >> Subject: Re: [edk2-devel] [PATCH] ShellPkg/ShellProtocol: Return
> >> error code while fail parsing cmd-line
> >>
> >> On 12/2/19 1:53 AM, Gao, Zhichao via Groups.Io wrote:
> >>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2395
> >>>
> >>> Errors happened in the arguments parsing is not a critical error.
> >>> And it would miss the error status code in the release version of shell.
> >>> So replace the ASSERT with returning error status code while fail
> >>> parsing command-line in UpdateArgcArgv.
> >>>
> >>> Cc: Ray Ni 
> >>> Cc: Linson Augustine 
> >>> Signed-off-by: Zhichao Gao 
> >>> ---
> >>>ShellPkg/Application/Shell/ShellProtocol.c | 5 -
> >>>1 file changed, 4 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/ShellPkg/Application/Shell/ShellProtocol.c
> >>> b/ShellPkg/Application/Shell/ShellProtocol.c
> >>> index 5e529b6568..f0362a42d8 100644
> >>> --- a/ShellPkg/Application/Shell/ShellProtocol.c
> >>> +++ b/ShellPkg/Application/Shell/ShellProtocol.c
> >>> @@ -1497,7 +1497,10 @@ InternalShellExecuteDevicePath(
> >>>ShellParamsProtocol.StdOut  =
> >> ShellInfoObject.NewShellParametersProtocol->StdOut;
> >>>ShellParamsProtocol.StdErr  =
> >> ShellInfoObject.NewShellParametersProtocol->StdErr;
> >>>Status = UpdateArgcArgv(&ShellParamsProtocol, NewCmdLine,
> >> Efi_Application, NULL, NULL);
> >>> -ASSERT_EFI_ERROR(Status);
> >>> +if (EFI_ERROR (Status)) {
> >>
> >> UpdateArgcArgv() is documented to only return
> EFI_OUT_OF_RESOURCES as
> >> error, however it calls ParseCommandLineToArgs() which - also not
> >> documented
> >> - returns EFI_INVALID_PARAMETER.
> >> I suppose this is the "not critical" error this BZ is trying to catch.
> >>
> >> Should we force Status to EFI_INVALID_PARAMETER before returning, is
> >> it safer to return EFI_OUT_OF_RESOURCES if it ever occurs? Should we
> >> assert if Status is EFI_OUT_OF_RESOURCES?
> >
> > It is fine to return EFI_OUT_OF_RESOURCES of this function as it descripts
> in its function comments. And all the EFI_OUT_OF_RESOURCES is returned
> due to the failure of memory allocating.
> 
> OK, thanks for clearing that with me.
> 
> > And here is an issue of this patch, missing add the return description
> "EFI_INVALID_PARAMETER" of UpdateArgcArgv  and
> ParseCommandLineToArgs.
> > I would add that in the V2 version.
> 
> This is not related to the BZ you are trying to solve, so no need for a
> v2 IMO (and I prepared those patches locally).
> 
> Reviewed-by: Philippe Mathieu-Daude 
> 
> >>
> >>> +  goto UnloadImage;
> >>> +}
> >>> +
> >>>//
> >>>// Replace Argv[0] with the full path of the binary we're 
> >>> executing:
> >>>// If the command line was "foo", the binary might be called
> "foo.efi".
> >>>
> >
> 
> 
> 


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

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

Re: [edk2-devel] [PATCH V2 0/2] MdePkg/UefiDevicePathLib: Separate the lib instances

[Gao, Zhichao]

Actually I didn't do the functionality test of Mandatory one, only do the build 
test and logic check. It is part of the Optional one. I assume the optional one 
is working fine. Then there would be no problem with Mandatory one.
I would write a test for both of them to make sure they are both fine.

Thanks,
Zhichao

> -Original Message-
> From: Gao, Liming
> Sent: Thursday, December 12, 2019 1:05 PM
> To: Gao, Zhichao ; devel@edk2.groups.io
> Cc: Kinney, Michael D ; Vitaly Cheptsov
> 
> Subject: RE: [PATCH V2 0/2] MdePkg/UefiDevicePathLib: Separate the lib
> instances
> 
> Zhichao:
>The change is good. What functionality test is done?
> 
> Thanks
> Liming
> >-Original Message-
> >From: Gao, Zhichao
> >Sent: Thursday, December 12, 2019 10:09 AM
> >To: devel@edk2.groups.io
> >Cc: Kinney, Michael D ; Gao, Liming
> >; Vitaly Cheptsov 
> >Subject: [PATCH V2 0/2] MdePkg/UefiDevicePathLib: Separate the lib
> >instances
> >
> >REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2298
> >
> >The UefiDevicePathLibOptionalDevicePathProtocolConstructor's
> >implementation
> >isn't match with its instance name.
> >Remove the ASSERT and depex of the gEfiDevicePathUtilitiesProtocolGuid
> >because of "Optional".
> >
> >Add a mandatory instance to force using the DevicePathUtilities,
> >DevicePathToText and DevicePathFromText protocol with the ASSERT and
> >depex.
> >
> >V2:
> >The optional lib instance's construction should return success all the
> >time.
> >Change the desciption of the optional lib uni file.
> >Change the copyright date of the mandatory one's uni file.
> >
> >Cc: Michael D Kinney 
> >Cc: Liming Gao 
> >Cc: Vitaly Cheptsov 
> >Signed-off-by: Zhichao Gao 
> >
> >Zhichao Gao (2):
> >  MdePkg/UefiDevicePathLib: Separate the device path lib
> >  MdePkg/dsc: Add UefiDevicePathLibMandatoryDevicePathProtocol for
> >build
> >
> > ...DevicePathLibMandatoryDevicePathProtocol.c | 469
> >++
> > ...vicePathLibMandatoryDevicePathProtocol.inf |  86 
> >...vicePathLibMandatoryDevicePathProtocol.uni |  18 +
> > ...iDevicePathLibOptionalDevicePathProtocol.c |   9 +-
> > ...evicePathLibOptionalDevicePathProtocol.inf |   5 +-
> > ...evicePathLibOptionalDevicePathProtocol.uni |   6 +-
> > MdePkg/MdePkg.dsc |   3 +-
> > 7 files changed, 582 insertions(+), 14 deletions(-)  create mode
> >100644
> >MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibMandatoryDevicePa
> th
> >Protocol.c
> > create mode 100644
> >MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibMandatoryDevicePa
> th
> >Protocol.inf
> > create mode 100644
> >MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibMandatoryDevicePa
> th
> >Protocol.uni
> >
> >--
> >2.21.0.windows.1


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

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

Re: [edk2-devel] [PATCH V2 0/2] MdePkg/UefiDevicePathLib: Separate the lib instances

[Liming Gao]

Zhichao:
   The change is good. What functionality test is done?

Thanks
Liming
>-Original Message-
>From: Gao, Zhichao
>Sent: Thursday, December 12, 2019 10:09 AM
>To: devel@edk2.groups.io
>Cc: Kinney, Michael D ; Gao, Liming
>; Vitaly Cheptsov 
>Subject: [PATCH V2 0/2] MdePkg/UefiDevicePathLib: Separate the lib
>instances
>
>REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2298
>
>The UefiDevicePathLibOptionalDevicePathProtocolConstructor's
>implementation
>isn't match with its instance name.
>Remove the ASSERT and depex of the gEfiDevicePathUtilitiesProtocolGuid
>because of "Optional".
>
>Add a mandatory instance to force using the DevicePathUtilities,
>DevicePathToText and DevicePathFromText protocol with the ASSERT
>and depex.
>
>V2:
>The optional lib instance's construction should return success all the
>time.
>Change the desciption of the optional lib uni file.
>Change the copyright date of the mandatory one's uni file.
>
>Cc: Michael D Kinney 
>Cc: Liming Gao 
>Cc: Vitaly Cheptsov 
>Signed-off-by: Zhichao Gao 
>
>Zhichao Gao (2):
>  MdePkg/UefiDevicePathLib: Separate the device path lib
>  MdePkg/dsc: Add UefiDevicePathLibMandatoryDevicePathProtocol for build
>
> ...DevicePathLibMandatoryDevicePathProtocol.c | 469
>++
> ...vicePathLibMandatoryDevicePathProtocol.inf |  86 
> ...vicePathLibMandatoryDevicePathProtocol.uni |  18 +
> ...iDevicePathLibOptionalDevicePathProtocol.c |   9 +-
> ...evicePathLibOptionalDevicePathProtocol.inf |   5 +-
> ...evicePathLibOptionalDevicePathProtocol.uni |   6 +-
> MdePkg/MdePkg.dsc |   3 +-
> 7 files changed, 582 insertions(+), 14 deletions(-)
> create mode 100644
>MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibMandatoryDevicePath
>Protocol.c
> create mode 100644
>MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibMandatoryDevicePath
>Protocol.inf
> create mode 100644
>MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibMandatoryDevicePath
>Protocol.uni
>
>--
>2.21.0.windows.1


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

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

[edk2-devel] [PATCH V2 0/2] MdePkg/UefiDevicePathLib: Separate the lib instances

[Gao, Zhichao]

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

The UefiDevicePathLibOptionalDevicePathProtocolConstructor's implementation
isn't match with its instance name.
Remove the ASSERT and depex of the gEfiDevicePathUtilitiesProtocolGuid
because of "Optional".

Add a mandatory instance to force using the DevicePathUtilities,
DevicePathToText and DevicePathFromText protocol with the ASSERT
and depex.

V2:
The optional lib instance's construction should return success all the
time.
Change the desciption of the optional lib uni file.
Change the copyright date of the mandatory one's uni file.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Vitaly Cheptsov 
Signed-off-by: Zhichao Gao 

Zhichao Gao (2):
  MdePkg/UefiDevicePathLib: Separate the device path lib
  MdePkg/dsc: Add UefiDevicePathLibMandatoryDevicePathProtocol for build

 ...DevicePathLibMandatoryDevicePathProtocol.c | 469 ++
 ...vicePathLibMandatoryDevicePathProtocol.inf |  86 
 ...vicePathLibMandatoryDevicePathProtocol.uni |  18 +
 ...iDevicePathLibOptionalDevicePathProtocol.c |   9 +-
 ...evicePathLibOptionalDevicePathProtocol.inf |   5 +-
 ...evicePathLibOptionalDevicePathProtocol.uni |   6 +-
 MdePkg/MdePkg.dsc |   3 +-
 7 files changed, 582 insertions(+), 14 deletions(-)
 create mode 100644 
MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibMandatoryDevicePathProtocol.c
 create mode 100644 
MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibMandatoryDevicePathProtocol.inf
 create mode 100644 
MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibMandatoryDevicePathProtocol.uni

-- 
2.21.0.windows.1


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

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

[edk2-devel] [PATCH V2 1/2] MdePkg/UefiDevicePathLib: Separate the device path lib

[Gao, Zhichao]

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

UefiDevicePathLibOptionalDevicePathProtocol's implementation isn't
fit its description. It should be implement as blow:
Try to find the DevicePathProtocol, if found then use it to implement
the interface. Else, use the local interface. It should not have the
depex and ASSERT of gEfiDevicePathUtilitiesProtocolGuid when not find
the DevicePathProtocol.

Add a mandatory one to force using the DevicePathUtilities,
DevicePathToText and DevicePathFromText protocol.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Vitaly Cheptsov 
Signed-off-by: Zhichao Gao 
---

V2:
Optional one should always return EFI_SUCCESS in its constructor.
Change the description of optional one's uni file.
Fix the copyright date of mandatory one's uni file.

 ...DevicePathLibMandatoryDevicePathProtocol.c | 469 ++
 ...vicePathLibMandatoryDevicePathProtocol.inf |  86 
 ...vicePathLibMandatoryDevicePathProtocol.uni |  18 +
 ...iDevicePathLibOptionalDevicePathProtocol.c |   9 +-
 ...evicePathLibOptionalDevicePathProtocol.inf |   5 +-
 ...evicePathLibOptionalDevicePathProtocol.uni |   6 +-
 6 files changed, 580 insertions(+), 13 deletions(-)
 create mode 100644 
MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibMandatoryDevicePathProtocol.c
 create mode 100644 
MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibMandatoryDevicePathProtocol.inf
 create mode 100644 
MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibMandatoryDevicePathProtocol.uni

diff --git 
a/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibMandatoryDevicePathProtocol.c
 
b/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibMandatoryDevicePathProtocol.c
new file mode 100644
index 00..fa27110fd4
--- /dev/null
+++ 
b/MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibMandatoryDevicePathProtocol.c
@@ -0,0 +1,469 @@
+/** @file
+  Device Path services. The thing to remember is device paths are built out of
+  nodes. The device path is terminated by an end node that is length
+  sizeof(EFI_DEVICE_PATH_PROTOCOL). That would be why there is 
sizeof(EFI_DEVICE_PATH_PROTOCOL)
+  all over this file.
+
+  The only place where multi-instance device paths are supported is in
+  environment varibles. Multi-instance device paths should never be placed
+  on a Handle.
+
+  Copyright (c) 2019, Intel Corporation. All rights reserved.
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+
+#include "UefiDevicePathLib.h"
+
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_DEVICE_PATH_UTILITIES_PROTOCOL 
*mDevicePathLibDevicePathUtilities = NULL;
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_DEVICE_PATH_TO_TEXT_PROTOCOL   
*mDevicePathLibDevicePathToText= NULL;
+GLOBAL_REMOVE_IF_UNREFERENCED EFI_DEVICE_PATH_FROM_TEXT_PROTOCOL 
*mDevicePathLibDevicePathFromText  = NULL;
+
+/**
+  The constructor function caches the pointer to DevicePathUtilites protocol,
+  DevicePathToText protocol and DevicePathFromText protocol.
+
+  The constructor function locates these three protocols from protocol 
database.
+  It will caches the pointer to local protocol instance if that operation fails
+  and it will always return EFI_SUCCESS.
+
+  @param  ImageHandle   The firmware allocated handle for the EFI image.
+  @param  SystemTable   A pointer to the EFI System Table.
+
+  @retval EFI_SUCCESS   The constructor always returns EFI_SUCCESS.
+
+**/
+EFI_STATUS
+EFIAPI
+UefiDevicePathLibMandatoryDevicePathProtocolConstructor (
+  IN  EFI_HANDLEImageHandle,
+  IN  EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  EFI_STATUSStatus;
+
+  Status = gBS->LocateProtocol (
+  &gEfiDevicePathUtilitiesProtocolGuid,
+  NULL,
+  (VOID**) &mDevicePathLibDevicePathUtilities
+  );
+  ASSERT_EFI_ERROR (Status);
+  ASSERT (mDevicePathLibDevicePathUtilities != NULL);
+
+  Status = gBS->LocateProtocol (
+  &gEfiDevicePathToTextProtocolGuid,
+  NULL,
+  (VOID**) &mDevicePathLibDevicePathToText
+  );
+  ASSERT_EFI_ERROR (Status);
+  ASSERT (mDevicePathLibDevicePathToText != NULL);
+
+  Status = gBS->LocateProtocol (
+  &gEfiDevicePathFromTextProtocolGuid,
+  NULL,
+  (VOID**) &mDevicePathLibDevicePathFromText
+  );
+  ASSERT_EFI_ERROR (Status);
+  ASSERT (mDevicePathLibDevicePathFromText != NULL);
+
+  return Status;
+}
+
+/**
+  Returns the size of a device path in bytes.
+
+  This function returns the size, in bytes, of the device path data structure
+  specified by DevicePath including the end of device path node.
+  If DevicePath is NULL or invalid, then 0 is returned.
+
+  @param  DevicePath  A pointer to a device path data structure.
+
+  @retval 0   If DevicePath is NULL or invalid.
+  @retval Others  The size of a device path in bytes.
+
+**/
+UINTN
+EFIAPI
+GetDevicePathSize (
+  IN CONST EFI_DEVICE_PATH_PROTOCOL  *DevicePath

[edk2-devel] [PATCH V2 2/2] MdePkg/dsc: Add UefiDevicePathLibMandatoryDevicePathProtocol for build

[Gao, Zhichao]

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

Add the new instance lib for build.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Vitaly Cheptsov 
Signed-off-by: Zhichao Gao 
---
 MdePkg/MdePkg.dsc | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/MdePkg/MdePkg.dsc b/MdePkg/MdePkg.dsc
index 0aeafaaacc..9e9813dd27 100644
--- a/MdePkg/MdePkg.dsc
+++ b/MdePkg/MdePkg.dsc
@@ -1,7 +1,7 @@
 ## @file
 # EFI/PI MdePkg Package
 #
-# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
+# Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
 # Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
 #
 #SPDX-License-Identifier: BSD-2-Clause-Patent
@@ -99,6 +99,7 @@
   MdePkg/Library/UefiDebugLibStdErr/UefiDebugLibStdErr.inf
   MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
   
MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibOptionalDevicePathProtocol.inf
+  
MdePkg/Library/UefiDevicePathLib/UefiDevicePathLibMandatoryDevicePathProtocol.inf
   
MdePkg/Library/UefiDevicePathLibDevicePathProtocol/UefiDevicePathLibDevicePathProtocol.inf
   MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
   MdePkg/Library/UefiLib/UefiLib.inf
-- 
2.21.0.windows.1


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

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

Re: [edk2-devel] [PATCH] SimicsOpenBoardPkg: Replace CMOS Hardcoded Addresses

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

-Original Message-
From: Agyeman, Prince  
Sent: Friday, December 6, 2019 9:32 AM
To: devel@edk2.groups.io
Cc: Desimone, Nathaniel L ; Kubacki, Michael A 

Subject: [PATCH] SimicsOpenBoardPkg: Replace CMOS Hardcoded Addresses

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

Changes:
* Added CmosMap.h that defines CMOS addresses used in
  SimicsOpenBoardPkg as macros

* Replaced hardcoded CMOS addresses with the macros
  defined in CmosMap.h

Cc: Nate DeSimone 
Cc: Michael Kubacki 

Signed-off-by: Prince Agyeman 
---
 .../SimicsOpenBoardPkg/Include/CmosMap.h  | 35 +++
 .../SimicsOpenBoardPkg/SimicsPei/MemDetect.c  | 23 
 .../SmbiosPlatformDxe/SmbiosPlatformDxe.c | 24 -
 .../SmbiosPlatformDxe/SmbiosPlatformDxe.h |  1 +
 4 files changed, 68 insertions(+), 15 deletions(-)  create mode 100644 
Platform/Intel/SimicsOpenBoardPkg/Include/CmosMap.h

diff --git a/Platform/Intel/SimicsOpenBoardPkg/Include/CmosMap.h 
b/Platform/Intel/SimicsOpenBoardPkg/Include/CmosMap.h
new file mode 100644
index 00..3221ce9a5b
--- /dev/null
+++ b/Platform/Intel/SimicsOpenBoardPkg/Include/CmosMap.h
@@ -0,0 +1,35 @@
+/** @file
+Cmos address definition macros header file.
+
+Copyright (c) 2019, Intel Corporation. All rights reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#ifndef _CMOS_MAP_H_
+#define _CMOS_MAP_H_
+
+//
+// CMOS 0x34/0x35 specifies the system memory above 16 MB.
+// * CMOS(0x35) is the high byte
+// * CMOS(0x34) is the low byte
+// * The size is specified in 64kb chunks // * Since this is memory 
+above 16MB, the 16MB must be added
+//   into the calculation to get the total memory size.
+//
+#define CMOS_SYSTEM_MEM_ABOVE_16MB_LOW_BYTE 0x34
+#define CMOS_SYSTEM_MEM_ABOVE_16MB_HIGH_BYTE0x35
+
+//
+// CMOS 0x5b-0x5d specifies the system memory above 4GB MB.
+// * CMOS(0x5d) is the most significant size byte // * CMOS(0x5c) is 
+the middle size byte // * CMOS(0x5b) is the least significant size byte 
+// * The size is specified in 64kb chunks //
+#define CMOS_SYSTEM_MEM_ABOVE_4GB_LOW_BYTE  0x5b
+#define CMOS_SYSTEM_MEM_ABOVE_4GB_MIDDLE_BYTE   0x5c
+#define CMOS_SYSTEM_MEM_ABOVE_4GB_HIGH_BYTE 0x5d
+
+
+#endif // _CMOS_MAP_H_
diff --git a/Platform/Intel/SimicsOpenBoardPkg/SimicsPei/MemDetect.c 
b/Platform/Intel/SimicsOpenBoardPkg/SimicsPei/MemDetect.c
index e547de0045..60aa54be9e 100644
--- a/Platform/Intel/SimicsOpenBoardPkg/SimicsPei/MemDetect.c
+++ b/Platform/Intel/SimicsOpenBoardPkg/SimicsPei/MemDetect.c
@@ -26,6 +26,8 @@
 #include 
 #include 
 
+#include 
+
 #include "Platform.h"
 
 UINT8 mPhysMemAddressWidth;
@@ -74,24 +76,33 @@ X58TsegMbytesInitialization(
   return;
 }
 
+/**
+  Get the system memory size below 4GB
 
+  @return The size of system memory below 4GB **/
 UINT32
 GetSystemMemorySizeBelow4gb (
   VOID
   )
 {
+  UINT32 Size;
   //
   // CMOS 0x34/0x35 specifies the system memory above 16 MB.
-  // * CMOS(0x35) is the high byte
-  // * CMOS(0x34) is the low byte
   // * The size is specified in 64kb chunks
   // * Since this is memory above 16MB, the 16MB must be added
   //   into the calculation to get the total memory size.
   //
-  return (UINT32) (((UINTN)CmosRead16 (0x34) << 16) + SIZE_16MB);
+  Size = (UINT32) ((CmosRead16 (CMOS_SYSTEM_MEM_ABOVE_16MB_LOW_BYTE) << 16)
+   + SIZE_16MB);
+  return Size;
 }
 
+/**
+  Get the system memory size  above 4GB
 
+  @return The size of system memory above 4GB **/
 STATIC
 UINT64
 GetSystemMemorySizeAbove4gb (
@@ -100,12 +111,10 @@ GetSystemMemorySizeAbove4gb (
   UINT32 Size;
   //
   // CMOS 0x5b-0x5d specifies the system memory above 4GB MB.
-  // * CMOS(0x5d) is the most significant size byte
-  // * CMOS(0x5c) is the middle size byte
-  // * CMOS(0x5b) is the least significant size byte
   // * The size is specified in 64kb chunks
   //
-  Size = (CmosRead16 (0x5c) << 8) + CmosRead8 (0x5b);
+  Size = (CmosRead16 (CMOS_SYSTEM_MEM_ABOVE_4GB_MIDDLE_BYTE) << 8)
+   + CmosRead8 (CMOS_SYSTEM_MEM_ABOVE_4GB_LOW_BYTE);
 
   return LShiftU64 (Size, 16);
 }
diff --git 
a/Platform/Intel/SimicsOpenBoardPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c 
b/Platform/Intel/SimicsOpenBoardPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c
index 37c659e275..23b284d2fa 100644
--- a/Platform/Intel/SimicsOpenBoardPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.c
+++ b/Platform/Intel/SimicsOpenBoardPkg/SmbiosPlatformDxe/SmbiosPlatform
+++ Dxe.c
@@ -9,23 +9,33 @@
 
 #include "SmbiosPlatformDxe.h"
 
+/**
+  Get the system memory size below 4GB
 
+  @return The size of system memory below 4GB **/
 UINT32
 GetSystemMemorySizeBelow4gb(
   VOID
   )
 {
+  UINT32 Size;
   //
   // CMOS 0x34/0x35 specifies the system memory above 16 MB.
-  // * CMOS(0x35) is the high byte
-  // * CMOS(0x34) is the low byte
   // * The size is specified in 64kb chunks
   // * Since this is memory above 16MB, the 16MB must be added
   //   into the calculat

[edk2-devel] [edk2-platforms] [PATCH] WhiskeylakeOpenBoardPkg: Update PCDs to enable stack sharing

[Agyeman, Prince]

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

Updated WhiskeylakeURvp PCDs to enable FSP/BL stack sharing.
This fixes the boot failure seen with the latest Coffee Lake (CFL)
FSP binary (v 7.0.68.41)

Cc: Chasel Chiu 
Cc: Nate DeSimone 
Cc: Michael Kubacki 

Signed-off-by: Prince Agyeman 
---
 .../WhiskeylakeURvp/OpenBoardPkgPcd.dsc   | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git 
a/Platform/Intel/WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/OpenBoardPkgPcd.dsc 
b/Platform/Intel/WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/OpenBoardPkgPcd.dsc
index 906f7b7ade..b3e1da3970 100644
--- a/Platform/Intel/WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/OpenBoardPkgPcd.dsc
+++ b/Platform/Intel/WhiskeylakeOpenBoardPkg/WhiskeylakeURvp/OpenBoardPkgPcd.dsc
@@ -54,15 +54,14 @@
   gSiPkgTokenSpaceGuid.PcdTsegSize|0x100
 
   #
-  # FSP API mode does not share stack with the boot loader,
-  # so FSP needs more temporary memory for FSP heap + stack size.
+  # When sharing stack with boot loader, FSP only needs small temp ram for heap
   #
-  gIntelFsp2PkgTokenSpaceGuid.PcdFspTemporaryRamSize|0x26000
+  gIntelFsp2PkgTokenSpaceGuid.PcdFspTemporaryRamSize|0x1
+
   #
-  # FSP API mode does not need to enlarge the boot loader stack size
-  # since the stacks are separate.
+  # Boot loader stack size has to be big enough to executing FSP
   #
-  gSiPkgTokenSpaceGuid.PcdPeiTemporaryRamStackSize|0x2
+  gSiPkgTokenSpaceGuid.PcdPeiTemporaryRamStackSize|0x4
 
   gEfiMdePkgTokenSpaceGuid.PcdPciExpressBaseAddress|0xE000
   gMinPlatformPkgTokenSpaceGuid.PcdPciExpressRegionLength|0x1000
-- 
2.19.1.windows.1


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

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

Re: [edk2-devel] [PATCH] SimicsOpenBoardPkg: Replace CMOS Hardcoded Addresses

[Kubacki, Michael A]

Please include [edk2-platforms] in the subject in the future.

Reviewed-by: Michael Kubacki 

> -Original Message-
> From: Agyeman, Prince 
> Sent: Friday, December 6, 2019 9:32 AM
> To: devel@edk2.groups.io
> Cc: Desimone, Nathaniel L ; Kubacki,
> Michael A 
> Subject: [PATCH] SimicsOpenBoardPkg: Replace CMOS Hardcoded Addresses
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2330
> 
> Changes:
> * Added CmosMap.h that defines CMOS addresses used in
>   SimicsOpenBoardPkg as macros
> 
> * Replaced hardcoded CMOS addresses with the macros
>   defined in CmosMap.h
> 
> Cc: Nate DeSimone 
> Cc: Michael Kubacki 
> 
> Signed-off-by: Prince Agyeman 
> ---
>  .../SimicsOpenBoardPkg/Include/CmosMap.h  | 35
> +++
>  .../SimicsOpenBoardPkg/SimicsPei/MemDetect.c  | 23 
>  .../SmbiosPlatformDxe/SmbiosPlatformDxe.c | 24 -
>  .../SmbiosPlatformDxe/SmbiosPlatformDxe.h |  1 +
>  4 files changed, 68 insertions(+), 15 deletions(-)  create mode 100644
> Platform/Intel/SimicsOpenBoardPkg/Include/CmosMap.h
> 
> diff --git a/Platform/Intel/SimicsOpenBoardPkg/Include/CmosMap.h
> b/Platform/Intel/SimicsOpenBoardPkg/Include/CmosMap.h
> new file mode 100644
> index 00..3221ce9a5b
> --- /dev/null
> +++ b/Platform/Intel/SimicsOpenBoardPkg/Include/CmosMap.h
> @@ -0,0 +1,35 @@
> +/** @file
> +Cmos address definition macros header file.
> +
> +Copyright (c) 2019, Intel Corporation. All rights reserved.
> +SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +**/
> +
> +#ifndef _CMOS_MAP_H_
> +#define _CMOS_MAP_H_
> +
> +//
> +// CMOS 0x34/0x35 specifies the system memory above 16 MB.
> +// * CMOS(0x35) is the high byte
> +// * CMOS(0x34) is the low byte
> +// * The size is specified in 64kb chunks // * Since this is memory
> +above 16MB, the 16MB must be added
> +//   into the calculation to get the total memory size.
> +//
> +#define CMOS_SYSTEM_MEM_ABOVE_16MB_LOW_BYTE 0x34
> +#define CMOS_SYSTEM_MEM_ABOVE_16MB_HIGH_BYTE0x35
> +
> +//
> +// CMOS 0x5b-0x5d specifies the system memory above 4GB MB.
> +// * CMOS(0x5d) is the most significant size byte // * CMOS(0x5c) is
> +the middle size byte // * CMOS(0x5b) is the least significant size byte
> +// * The size is specified in 64kb chunks //
> +#define CMOS_SYSTEM_MEM_ABOVE_4GB_LOW_BYTE  0x5b
> +#define CMOS_SYSTEM_MEM_ABOVE_4GB_MIDDLE_BYTE   0x5c
> +#define CMOS_SYSTEM_MEM_ABOVE_4GB_HIGH_BYTE 0x5d
> +
> +
> +#endif // _CMOS_MAP_H_
> diff --git a/Platform/Intel/SimicsOpenBoardPkg/SimicsPei/MemDetect.c
> b/Platform/Intel/SimicsOpenBoardPkg/SimicsPei/MemDetect.c
> index e547de0045..60aa54be9e 100644
> --- a/Platform/Intel/SimicsOpenBoardPkg/SimicsPei/MemDetect.c
> +++ b/Platform/Intel/SimicsOpenBoardPkg/SimicsPei/MemDetect.c
> @@ -26,6 +26,8 @@
>  #include 
>  #include 
> 
> +#include 
> +
>  #include "Platform.h"
> 
>  UINT8 mPhysMemAddressWidth;
> @@ -74,24 +76,33 @@ X58TsegMbytesInitialization(
>return;
>  }
> 
> +/**
> +  Get the system memory size below 4GB
> 
> +  @return The size of system memory below 4GB **/
>  UINT32
>  GetSystemMemorySizeBelow4gb (
>VOID
>)
>  {
> +  UINT32 Size;
>//
>// CMOS 0x34/0x35 specifies the system memory above 16 MB.
> -  // * CMOS(0x35) is the high byte
> -  // * CMOS(0x34) is the low byte
>// * The size is specified in 64kb chunks
>// * Since this is memory above 16MB, the 16MB must be added
>//   into the calculation to get the total memory size.
>//
> -  return (UINT32) (((UINTN)CmosRead16 (0x34) << 16) + SIZE_16MB);
> +  Size = (UINT32) ((CmosRead16
> (CMOS_SYSTEM_MEM_ABOVE_16MB_LOW_BYTE) << 16)
> +   + SIZE_16MB);
> +  return Size;
>  }
> 
> +/**
> +  Get the system memory size  above 4GB
> 
> +  @return The size of system memory above 4GB **/
>  STATIC
>  UINT64
>  GetSystemMemorySizeAbove4gb (
> @@ -100,12 +111,10 @@ GetSystemMemorySizeAbove4gb (
>UINT32 Size;
>//
>// CMOS 0x5b-0x5d specifies the system memory above 4GB MB.
> -  // * CMOS(0x5d) is the most significant size byte
> -  // * CMOS(0x5c) is the middle size byte
> -  // * CMOS(0x5b) is the least significant size byte
>// * The size is specified in 64kb chunks
>//
> -  Size = (CmosRead16 (0x5c) << 8) + CmosRead8 (0x5b);
> +  Size = (CmosRead16 (CMOS_SYSTEM_MEM_ABOVE_4GB_MIDDLE_BYTE)
> << 8)
> +   + CmosRead8 (CMOS_SYSTEM_MEM_ABOVE_4GB_LOW_BYTE);
> 
>return LShiftU64 (Size, 16);
>  }
> diff --git
> a/Platform/Intel/SimicsOpenBoardPkg/SmbiosPlatformDxe/SmbiosPlatform
> Dxe.c
> b/Platform/Intel/SimicsOpenBoardPkg/SmbiosPlatformDxe/SmbiosPlatform
> Dxe.c
> index 37c659e275..23b284d2fa 100644
> ---
> a/Platform/Intel/SimicsOpenBoardPkg/SmbiosPlatformDxe/SmbiosPlatform
> Dxe.c
> +++
> b/Platform/Intel/SimicsOpenBoardPkg/SmbiosPlatformDxe/SmbiosPlatform
> +++ Dxe.c
> @@ -9,23 +9,33 @@
> 
>  #include "SmbiosPlatformDxe.h"
> 
> +/**
> +  Get the system memory size below 4GB
> 
> +  @return The size of system memo

Re: [edk2-devel] [edk2][PATCH 1/1] MdePkg/Include: Add DCC and BCM2835 SPCR UART types

[Liming Gao]

Reviewed-by: Liming Gao 

> -Original Message-
> From: Ard Biesheuvel 
> Sent: Wednesday, December 11, 2019 6:01 PM
> To: Pete Batard ; Kinney, Michael D 
> ; Gao, Liming 
> Cc: edk2-devel-groups-io ; Leif Lindholm 
> ; Philippe Mathieu-Daudé
> 
> Subject: Re: [edk2][PATCH 1/1] MdePkg/Include: Add DCC and BCM2835 SPCR UART 
> types
> 
> (add MdePkg maintainers)
> 
> On Tue, 10 Dec 2019 at 19:23, Pete Batard  wrote:
> >
> > As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
> > can be found online, we are missing 2 serial interface types for
> > Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).
> >
> > These same types are present in DebugPort2Table.h so add them to
> > SerialPortConsoleRedirectionTable.h too.
> >
> > Note that we followed the same idiosyncrasies as DebugPort2Table
> > for naming these new macros.
> >
> > Signed-off-by: Pete Batard 
> 
> Acked-by: Ard Biesheuvel 
> 
> > ---
> >  MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h | 10 
> > ++
> >  1 file changed, 10 insertions(+)
> >
> > diff --git 
> > a/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> b/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> > index b069fb2be97f..2066c7895e59 100644
> > --- a/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> > +++ b/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> > @@ -90,6 +90,16 @@ typedef struct {
> >  ///
> >  #define 
> > EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_ARM_SBSA_GENERIC_UART
> >  0x0e
> >
> > +///
> > +/// ARM DCC
> > +///
> > +#define EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_DCC  
> >  0x0f
> > +
> > +///
> > +/// BCM2835 UART
> > +///
> > +#define 
> > EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_BCM2835_UART  
> > 0x10
> > +
> >  //
> >  // Interrupt Type
> >  //
> > --
> > 2.21.0.windows.1
> >

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

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

Re: [edk2-devel] [edk2-staging/EdkRepo] [PATCH] EdkRepo: Support uninstalling packages with '_' in their name.

[Desimone, Ashley E]

Reviewed-by: Ashley DeSimone 

-Original Message-
From: Desimone, Nathaniel L 
Sent: Tuesday, December 10, 2019 1:56 AM
To: devel@edk2.groups.io
Cc: Desimone, Ashley E ; Pandya, Puja 
; Bret Barkelew 
Subject: [edk2-staging/EdkRepo] [PATCH] EdkRepo: Support uninstalling packages 
with '_' in their name.

pip does not support '_' in package names and converts them to '-' after 
installing the wheel. In order to uninstall affected packages the '_' needs to 
be converted to a '-' when calculating the package name.

Cc: Ashley DeSimone 
Cc: Puja Pandya 
Cc: Bret Barkelew 
Signed-off-by: Nate DeSimone 
---
 edkrepo_installer/linux-scripts/install.py | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/edkrepo_installer/linux-scripts/install.py 
b/edkrepo_installer/linux-scripts/install.py
index a05ce6a..66421ba 100755
--- a/edkrepo_installer/linux-scripts/install.py
+++ b/edkrepo_installer/linux-scripts/install.py
@@ -93,8 +93,9 @@ def get_required_wheels():
 continue
 installed_modules[name] = version
 for name in ret_val:
-if name in installed_modules:
-version = installed_modules[name]
+#pip doesn't understand the difference between '_' and '-'
+if name.replace('_','-') in installed_modules:
+version = installed_modules[name.replace('_','-')]
 if _check_version(version, ret_val[name]['version']) >= 0 and not 
ret_val[name]['uninstall']:
 ret_val[name]['install'] = False
 else:
@@ -294,9 +295,8 @@ def do_install():
 log.info('- Missing wheel file directory')
 return 1
 for whl_name in wheels_to_install:
-whl = wheels_to_install[whl_name]['wheel']
-install_whl = wheels_to_install[whl_name]['install']
 uninstall_whl = wheels_to_install[whl_name]['uninstall']
+whl_name = whl_name.replace('_','-')  #pip doesn't understand the 
difference between '_' and '-'
 if uninstall_whl:
 try:
 res = default_run(['python3', '-m', 'pip', 'uninstall', 
'--yes', whl_name]) @@ -304,6 +304,9 @@ def do_install():
 log.info('- Failed to uninstall {}'.format(whl_name))
 return 1
 log.info('+ Uninstalled {}'.format(whl_name))
+for whl_name in wheels_to_install:
+whl = wheels_to_install[whl_name]['wheel']
+install_whl = wheels_to_install[whl_name]['install']
 if install_whl:
 install_cmd = ['python3', '-m', 'pip', 'install']
 if args.local:
--
2.20.1


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

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

Re: [edk2-devel] [edk2-staging/EdkRepo] [PATCH] EdkRepo: Allow user to override python command

[Desimone, Ashley E]

Reviewed-by: Ashley DeSimone 

-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Nate 
DeSimone
Sent: Tuesday, December 10, 2019 1:55 AM
To: devel@edk2.groups.io
Cc: Desimone, Ashley E ; Pandya, Puja 
; Bret Barkelew 
Subject: [edk2-devel] [edk2-staging/EdkRepo] [PATCH] EdkRepo: Allow user to 
override python command

The --py flag will allow the user to specify a specific version of python 
removing the need for the python3 sym-link on some systems.

Cc: Ashley DeSimone 
Cc: Puja Pandya 
Cc: Bret Barkelew 
Signed-off-by: Nate DeSimone 
---
 edkrepo_installer/linux-scripts/install.py | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/edkrepo_installer/linux-scripts/install.py 
b/edkrepo_installer/linux-scripts/install.py
index a05ce6a..e7d3f91 100755
--- a/edkrepo_installer/linux-scripts/install.py
+++ b/edkrepo_installer/linux-scripts/install.py
@@ -27,6 +27,7 @@ tool_sign_on = 'Installer for edkrepo version 
{}\nCopyright(c) Intel Corporation  cfg_dir = '.edkrepo'
 cfg_src_dir = os.path.abspath('config')  whl_src_dir = 
os.path.abspath('wheels')
+def_python = 'python3'

 def default_run(cmd):
 return subprocess.run(cmd, universal_newlines=True, 
stdout=subprocess.PIPE, stderr=subprocess.STDOUT, check=True) @@ -45,6 +46,7 @@ 
def init_logger(verbose):
 def get_args():
 parser = ArgumentParser()
 parser.add_argument('-l', '--local', action='store_true', default=False, 
help='Install edkrepo to the user directory instead of system wide')
+parser.add_argument('-p', '--py', action='store', default=None, 
+ help='Specify the python command to use when installing')
 parser.add_argument('-u', '--user', action='store', default=None, 
help='Specify user account to install edkrepo support on')
 parser.add_argument('-v', '--verbose', action='store_true', default=False, 
help='Enables verbose output')
 return parser.parse_args()
@@ -75,7 +77,7 @@ def get_required_wheels():
  
'version':wheel.attrib['Version'],
  'install':True}
 break
-pip_cmd = ['python3', '-m', 'pip', 'list', '--legacy']
+pip_cmd = [def_python, '-m', 'pip', 'list', '--legacy']
 try:
 res = default_run(pip_cmd)
 except:
@@ -117,8 +119,14 @@ def _check_version(current, expected):
 return 0

 def do_install():
+global def_python
+org_python = None
+
 # Parse command line
 args = get_args()
+if args.py is not None:
+org_python = def_python
+def_python = args.py

 # Enable logging output
 log = init_logger(args.verbose)
@@ -132,6 +140,9 @@ def do_install():
 except:
 log.error('ERROR: Missing installer configuration file.')
 return 1
+if org_python is not None:
+cfg['req_tools'][def_python] = cfg['req_tools'][org_python]
+cfg['req_tools'].pop(org_python)
 try:
 sha_data = configparser.ConfigParser(allow_no_value=True)
 sha_data.read(os.path.join(cfg_src_dir, 'sha_data.cfg')) @@ -299,13 
+310,13 @@ def do_install():
 uninstall_whl = wheels_to_install[whl_name]['uninstall']
 if uninstall_whl:
 try:
-res = default_run(['python3', '-m', 'pip', 'uninstall', 
'--yes', whl_name])
+res = default_run([def_python, '-m', 'pip', 
+ 'uninstall', '--yes', whl_name])
 except:
 log.info('- Failed to uninstall {}'.format(whl_name))
 return 1
 log.info('+ Uninstalled {}'.format(whl_name))
 if install_whl:
-install_cmd = ['python3', '-m', 'pip', 'install']
+install_cmd = [def_python, '-m', 'pip', 'install']
 if args.local:
 install_cmd.append('--user')
 install_cmd.append(os.path.join(whl_src_dir, whl))
--
2.20.1





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

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

[edk2-devel] [PATCH] [edk2/BaseTools] edksetup.bat stuck on unicode locale Windows

[Park, Aiden]

This issue happens under two conditions.
  1. Unicode language environment in Windows
  2. Call 'edksetup.bat forcerebuild' with python subprocess.call()

Steps to reproduce
  C:\edk2>python
  Python 2.7.12 (v2.7.12:d33e0cf91556, Jun 27 2016, 15:24:40)
  Type help, copyright, credits or license for more information.
  >>> import subprocess
  >>> subprocess.call(['edksetup.bat', 'forcerebuild'])

  The edksetup.bat stuck at 'nmake cleanall'.

One of multi-threads is on deadlock when python handles stdout and
stderr in a subprocess pipe only if the outputs include unicode chars.
Only stderr will be handled in the pipe same as a single thread call.

Reported in Slim Bootloader.
  https://github.com/slimbootloader/slimbootloader/issues/478
Local fix has been made in Slim Bootloader.
  https://github.com/slimbootloader/slimbootloader/pull/490

Signed-off-by: Aiden Park 
---
 BaseTools/Source/C/Makefiles/NmakeSubdirs.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/C/Makefiles/NmakeSubdirs.py 
b/BaseTools/Source/C/Makefiles/NmakeSubdirs.py
index 356f5ac..c77bfb0 100644
--- a/BaseTools/Source/C/Makefiles/NmakeSubdirs.py
+++ b/BaseTools/Source/C/Makefiles/NmakeSubdirs.py
@@ -33,7 +33,7 @@ def RunCommand(WorkDir=None, *Args, **kwargs):
 if "stderr" not in kwargs:
 kwargs["stderr"] = subprocess.STDOUT
 if "stdout" not in kwargs:
-kwargs["stdout"] = subprocess.PIPE
+kwargs["stdout"] = sys.stdout
 p = subprocess.Popen(Args, cwd=WorkDir, stderr=kwargs["stderr"], 
stdout=kwargs["stdout"])
 stdout, stderr = p.communicate()
 message = ""
-- 
2.10.2.windows.1

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

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

[edk2-devel] [TLS][HTTPS] TLS Server support

[davysouza94]

Hi everyone,

I'm working on a HTTPS server on EFI using EDK II, but I found the following 
code on *\edk2\CryptoPkg\Library\TlsLib\TlsConfig.c:

* if ( ! IsServer) {
//
// Set TLS to work in Client mode.
//
SSL_set_connect_state (TlsConn->Ssl) ;
} else {
//
// Set TLS to work in Server mode.
// It is unsupported for UEFI version currently.
//
//SSL_set_accept_state (TlsConn->Ssl);
return EFI_UNSUPPORTED;
}

Why is not possible to create a TLS server? What is the limitation?

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

View/Reply Online (#52132): https://edk2.groups.io/g/devel/message/52132
Mute This Topic: https://groups.io/mt/68170720/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/1] Platform/RPi: Inhibit serial output for all runtime drivers

[Pete Batard]

From: Ard Biesheuvel 

This is an improvement of e9db04631b63574b090aeab769cc47dcb75a29f7
where we inhibit serial output of MMIO mapped UARTs to all runtime
drivers rather than just RTC, as other drivers may crash the OS
just the same.

Also add it to the Pi 4 platform where it was missing altogether.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/RPi3/RPi3.dsc | 3 ++-
 Platform/RaspberryPi/RPi4/RPi4.dsc | 2 ++
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/RPi3/RPi3.dsc 
b/Platform/RaspberryPi/RPi3/RPi3.dsc
index 945baa5021f8..2368b04f40a4 100644
--- a/Platform/RaspberryPi/RPi3/RPi3.dsc
+++ b/Platform/RaspberryPi/RPi3/RPi3.dsc
@@ -200,6 +200,8 @@ [LibraryClasses.common.UEFI_DRIVER]
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
 
 [LibraryClasses.common.DXE_RUNTIME_DRIVER]
+  # Runtime debug messages may crash an OS unless serial output to MMIO mapped 
UARTs is inhibited
+  
DebugLib|MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.inf
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   EfiResetSystemLib|Platform/RaspberryPi/Library/ResetLib/ResetLib.inf
@@ -505,7 +507,6 @@ [Components.common]
   EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
   EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf {
 
-  
DebugLib|MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.inf
   
RealTimeClockLib|EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf
   }
   EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
index 3764d1b3d794..03139e57a8db 100644
--- a/Platform/RaspberryPi/RPi4/RPi4.dsc
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -202,6 +202,8 @@ [LibraryClasses.common.UEFI_DRIVER]
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
 
 [LibraryClasses.common.DXE_RUNTIME_DRIVER]
+  # Runtime debug messages may crash an OS unless serial output to MMIO mapped 
UARTs is inhibited
+  
DebugLib|MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.inf
   
MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   EfiResetSystemLib|Platform/RaspberryPi/Library/ResetLib/ResetLib.inf
-- 
2.21.0.windows.1


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

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

Re: [edk2-devel] [edk2-platforms][PATCH 0/5] Add initial Raspberry Pi 4 platform

[Ard Biesheuvel]

On Wed, 11 Dec 2019 at 12:26, Pete Batard  wrote:
>
> This series adds basic support to build the Raspberry Pi 4 platform.
>
> It requires the earlier series, that add binary files for the platform,
> to have been applied to edk2-non-osi.
>
> For the introduction of the platform, USB support is not yet enabled
> which means that user I/O has to be carried out through serial.
>
> The first two patches of the series are fixes for the common RPi
> platform that will become relevant when we introduce support for
> PCIe/xHCI.
>
> The second two patch deal with the specific ACPI changes for the
> Pi 4 platform. To make these clearer, an intermediate patch, that
> simply enacts a straight unaltered copy of the Pi 3 ACPI files is
> added, so that the changes we apply can be made obvious. We also
> use this opportunity to switch the source of some tables (GTDT,
> MADT) to proper aslc.
>
> Finally, the last patch in this series adds the platform files
> along with a Readme detailing the installation requirements and
> current state of the platform.
>
> Andrei Warkentin (2):
>   Platform/RPi4: Update ACPI tables for the new platform
>   Platform/RPi4: Add base platform files
>

Reviewed-by: Ard Biesheuvel 

> Ard Biesheuvel (2):
>   Platform/RPi: Fix overlap of SoC registers and RAM
>   Platform/RPi: Don't describe MMIO regions as memory
>


> Samer El-Haj-Mahmoud (1):
>   Platform/RPi4: Add initial ACPI tables
>

Reviewed-by: Ard Biesheuvel 


Pushed as c5a2065ee8c2..065a5597f36a

Thanks!



>  Platform/RaspberryPi/Include/Library/RPiMem.h|   7 +-
>  Platform/RaspberryPi/Library/MemoryInitPeiLib/MemoryInitPeiLib.c |  10 +
>  Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c|  42 +-
>  Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.h|  92 +++
>  Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.inf  |  49 ++
>  Platform/RaspberryPi/RPi4/AcpiTables/Csrt.aslc   | 327 
> ++
>  Platform/RaspberryPi/RPi4/AcpiTables/Dbg2.aslc   |  28 +
>  Platform/RaspberryPi/RPi4/AcpiTables/Dsdt.asl| 505 
> 
>  Platform/RaspberryPi/RPi4/AcpiTables/Fadt.aslc   |  46 ++
>  Platform/RaspberryPi/RPi4/AcpiTables/Gtdt.aslc   |  56 ++
>  Platform/RaspberryPi/RPi4/AcpiTables/Madt.aslc   |  64 ++
>  Platform/RaspberryPi/RPi4/AcpiTables/Pep.asl |  90 +++
>  Platform/RaspberryPi/RPi4/AcpiTables/Pep.c   |  79 +++
>  Platform/RaspberryPi/RPi4/AcpiTables/Pep.h   | 121 
>  Platform/RaspberryPi/RPi4/AcpiTables/Rhpx.asl| 195 ++
>  Platform/RaspberryPi/RPi4/AcpiTables/Sdhc.asl|  99 +++
>  Platform/RaspberryPi/RPi4/AcpiTables/Spcr.asl|  48 ++
>  Platform/RaspberryPi/RPi4/AcpiTables/Uart.asl| 152 +
>  Platform/RaspberryPi/RPi4/RPi4.dsc   | 637 
> 
>  Platform/RaspberryPi/RPi4/RPi4.fdf   | 432 
> +
>  Platform/RaspberryPi/RPi4/Readme.md  | 110 
>  21 files changed, 3170 insertions(+), 19 deletions(-)
>  create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.h
>  create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.inf
>  create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Csrt.aslc
>  create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Dbg2.aslc
>  create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Dsdt.asl
>  create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Fadt.aslc
>  create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Gtdt.aslc
>  create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Madt.aslc
>  create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Pep.asl
>  create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Pep.c
>  create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Pep.h
>  create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Rhpx.asl
>  create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Sdhc.asl
>  create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Spcr.asl
>  create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Uart.asl
>  create mode 100644 Platform/RaspberryPi/RPi4/RPi4.dsc
>  create mode 100644 Platform/RaspberryPi/RPi4/RPi4.fdf
>  create mode 100644 Platform/RaspberryPi/RPi4/Readme.md
>
> --
> 2.21.0.windows.1
>

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

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

Re: [edk2-devel] [edk2-non-osi][PATCH 2/2] Platforms/RPi4: Add Trusted Firmware binaries

[Pete Batard]

Hi Leif,

On 2019.12.11 14:14, Leif Lindholm wrote:

On Wed, Dec 11, 2019 at 11:24:00 +, Pete Batard wrote:

Similar to what is the case with the Raspberry Pi 3, the Raspberry Pi
4 UEFI firmware requires the provision of a Trusted Firmware binary
(TF-A).

The binary is built for a dtb base address of 0x0002 and a UEFI
payload base address of 0x0003.

Binaries are built using a custom version of TF-A (the source of which
is documented in the Readme), since the official repository is missing
a fix to get proper baudrate when using a recent version of start4.elf,
as we as the ability to switch between PL011 and mini UART. We are
currently working with TF-A to upstream both these fixes so that we can
switch to binaries built from official source at a later date.

In order to provide the ability to switch serial I/O controllers, a
feature we will be adding to the RPi4 UEFI Firmware, and not lose TF-A
output, two binaries are provided, one for mini UART output and one for
PL011 output.

Signed-off-by: Pete Batard 
---
  Platform/RaspberryPi/RPi4/TrustedFirmware/License.txt   |  26 

  Platform/RaspberryPi/RPi4/TrustedFirmware/Readme.md |  12 +
  Platform/RaspberryPi/RPi4/TrustedFirmware/bl31_miniuart.bin | Bin 0 -> 41072 
bytes
  Platform/RaspberryPi/RPi4/TrustedFirmware/bl31_pl011.bin| Bin 0 -> 41072 
bytes
  4 files changed, 38 insertions(+)




new file mode 100644
index ..7f1749dfc3a0
--- /dev/null
+++ b/Platform/RaspberryPi/RPi4/TrustedFirmware/Readme.md
@@ -0,0 +1,12 @@
+ARM Trusted Firmware for Raspberry Pi 4
+===
+
+The `bl31_#.bin` TF-A binaries found in this repository were built on a 
Debian 10.2 system
+from https://github.com/pbatard/arm-trusted-firmware/tree/pi4 (pi4 branch) 
using the command:
+
+```
+make PLAT=rpi4 RPI3_PRELOADED_DTB_BASE=0x2 PRELOADED_BL33_BASE=0x3 
SUPPORT_VFP=1 [RPI3_USE_PL011_UART=1] DEBUG=0 all
+```
+
+The only difference between these firmwares is that the 
`RPI3_USE_PL011_UART=1` option was added
+to build `bl31_pl011.bin` so that it uses PL011 for serial output rather than the 
"mini UART".


Sanity check: do the build commands still use RPI3_ options for rpi4?


That's correct. This is an option that's meant to apply to both Pi 3 and 
Pi 4, and for now, I'm keeping everything in line with the current RPi 
common options that are still prefixed with RPI3_.


There are some vague talks about merging the Pi 3 and Pi 4 TF-A 
platforms, so maybe we'll drop RPI3_ prefixed options then, but for now, 
pretty much all of the Pi 4 build options I know of use RPI3_ as a prefix.


Regards,

/Pete



Best Regards,

Leif




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

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

[edk2-devel] [Patch 1/1] BaseTools: Fix build failure when multiple build targets given

[Bob Feng]

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

This patch is to fix a regression issue that build fails
if multiple build targets given.

Two changes cause this regression issue.
One is AutoGen object __hash__ function only
hash file path and arch, missing ToolChain and build target.

The other is changing the multiple-thread-genfds function as default
build behavior. To generate the genffs command to Makefile, there
is a global data set is used, GenFdsGlobalVariable, which cause build
tool use the data of first build-target build in
the second build-target build.

Cc: Liming Gao 
Cc: Steven Shi 
Cc: Ard Biesheuvel 
Signed-off-by: Bob Feng 
---
 BaseTools/Source/Python/AutoGen/ModuleAutoGen.py   | 2 +-
 BaseTools/Source/Python/AutoGen/PlatformAutoGen.py | 2 +-
 BaseTools/Source/Python/build/build.py | 2 ++
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py 
b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
index 74662d1b52bc..aad591de65f0 100755
--- a/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/ModuleAutoGen.py
@@ -268,11 +268,11 @@ class ModuleAutoGen(AutoGen):
 #
 #   @retval   int Hash value of the module file path and arch
 #
 @cached_class_function
 def __hash__(self):
-return hash((self.MetaFile, self.Arch))
+return hash((self.MetaFile, self.Arch, 
self.ToolChain,self.BuildTarget))
 def __repr__(self):
 return "%s [%s]" % (self.MetaFile, self.Arch)
 
 # Get FixedAtBuild Pcds of this Module
 @cached_property
diff --git a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py 
b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
index 4c3cdf82d57f..7bd24dad42f8 100644
--- a/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/PlatformAutoGen.py
@@ -146,11 +146,11 @@ class PlatformAutoGen(AutoGen):
 #
 #   @retval   int Hash value of the platform file path and arch
 #
 @cached_class_function
 def __hash__(self):
-return hash((self.MetaFile, self.Arch))
+return hash((self.MetaFile, self.Arch,self.ToolChain,self.BuildTarget))
 @cached_class_function
 def __repr__(self):
 return "%s [%s]" % (self.MetaFile, self.Arch)
 
 ## Create autogen code for platform and modules
diff --git a/BaseTools/Source/Python/build/build.py 
b/BaseTools/Source/Python/build/build.py
index 8a8e32e496f8..77b46341b5ad 100755
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -56,10 +56,11 @@ import multiprocessing as mp
 from multiprocessing import Manager
 from AutoGen.DataPipe import MemoryDataPipe
 from AutoGen.ModuleAutoGenHelper import WorkSpaceInfo, PlatformInfo
 from GenFds.FdfParser import FdfParser
 from AutoGen.IncludesAutoGen import IncludesAutoGen
+from GenFds.GenFds import resetFdsGlobalVariable
 
 ## standard targets of build command
 gSupportedTarget = ['all', 'genc', 'genmake', 'modules', 'libraries', 'fds', 
'clean', 'cleanall', 'cleanlib', 'run']
 
 ## build configuration file
@@ -2205,10 +2206,11 @@ class Build():
 SaveFileOnChange(self.PlatformBuildPath, '# DO NOT EDIT \n# FILE 
auto-generated\n', False)
 for BuildTarget in self.BuildTargetList:
 GlobalData.gGlobalDefines['TARGET'] = BuildTarget
 index = 0
 for ToolChain in self.ToolChainList:
+resetFdsGlobalVariable()
 GlobalData.gGlobalDefines['TOOLCHAIN'] = ToolChain
 GlobalData.gGlobalDefines['TOOL_CHAIN_TAG'] = ToolChain
 GlobalData.gGlobalDefines['FAMILY'] = 
self.ToolChainFamily[index]
 index += 1
 ExitFlag = threading.Event()
-- 
2.20.1.windows.1


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

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

Re: [edk2-devel] [edk2-discuss] Design discussion for SEV-ES

[Lendacky, Thomas]

On 12/10/19 9:04 PM, Ni, Ray wrote:
> Can you please have your slides ready in 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fedk2.groups.io%2Fg%2Fdevel%2Ffiles%2FDesigns%2F2019&data=02%7C01%7Cthomas.lendacky%40amd.com%7Cc96e7c2ec5de4d16fc8b08d77de72902%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637116304085351984&sdata=6dYXpZxV%2BFgAMIIKSbcqO2H4934ohtjYuigD8dW%2BL8M%3D&reserved=0
>  before the meeting?
> The earlier, the better.

I'll put the slides up now. They are the slides from KVM Forum at the end
of 2018 that give a quick review of SEV and then an overview of SEV-ES.
Based on that, during the call I can highlight the areas within EDK2 that
are effected.

> 
> How much time do you think it will need? I am thinking whether there is time 
> for a second topic.

That all depends. I can go through the slides quickly if there's a general
understanding of everything, but it will depend on the discussion. I hope
it would only take 30 minutes at the most.

Thanks,
Tom

> 
> 
>> -Original Message-
>> From: Tom Lendacky 
>> Sent: Tuesday, December 10, 2019 10:28 PM
>> To: Ni, Ray 
>> Cc: Gao, Liming ; edk2-devel-groups-io
>> ; Kinney, Michael D 
>> Subject: Re: [edk2-discuss] Design discussion for SEV-ES
>>
>> On 12/10/19 2:09 AM, Ni, Ray wrote:
>>> Tom,
>>> I may not in the discuss mailing list. Liming forwarded your request to me.
>> Sorry I acked so late.
>>>
>>> This week's open design meeting is vacant. Is that still your plan to use 
>>> this
>> week's open design meeting to discuss SEV-ES?
>>
>> Yes, I would like to, if that still works for everyone.
>>
>> Thanks,
>> Tom
>>
>>>
>>> Thanks,
>>> Ray
>>>
 -Original Message-
 From: Gao, Liming 
 Sent: Monday, November 25, 2019 9:18 PM
 To: Ni, Ray 
 Subject: FW: [edk2-discuss] Design discussion for SEV-ES

 FYI

 -Original Message-
 From: disc...@edk2.groups.io  On Behalf Of
>> Tom
 Lendacky
 Sent: Thursday, November 21, 2019 4:22 AM
 To: disc...@edk2.groups.io
 Subject: [edk2-discuss] Design discussion for SEV-ES

 I'd like to be added to the TianoCore Design Meeting to discuss support
 SEV-ES in OVMF.

 Looking at the calendar, the meeting scheduled for December 12, 2019
>> would
 be best.

 Discussion length will depend on how much everyone understands the
 current
 SEV support and the additional requirements of SEV-ES.

 Thank you,
 Tom Lendacky

 
>>>

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

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

Re: [edk2-devel] Debugging aarch64 edk2 built with gcc-8.x 64-bit arm compiler

[Ard Biesheuvel]

On Tue, 10 Dec 2019 at 18:25, Vladimir Olovyannikov
 wrote:
>
> > -Original Message-
> > From: Ard Biesheuvel 
> > Sent: Tuesday, December 10, 2019 9:13 AM
> > To: Vladimir Olovyannikov ; Sami
> > Mujawar 
> > Cc: edk2-devel-groups-io 
> > Subject: Re: Debugging aarch64 edk2 built with gcc-8.x 64-bit arm compiler
> >
> > On Sat, 7 Dec 2019 at 00:50, Vladimir Olovyannikov
> >  wrote:
> > >
> > > Hi Ard,
> > >
> > >
> > >
> > > We are about to switch to the latest Yocto. It is shipped with gcc-8.3
> > aarch64-linux-gnu compiler.
> > >
> > > We use DS5 for bare metal debugging.
> > >
> > > When I build edk2 with gcc-7-x/gcc-8.x, DS5 complains on DWARF format.
> > > I tried to explicitly set it to DWARF2, but still cannot even get the
> > > stack or local variables (even though DS5 does not complain), even for
> > > edk2
> > NOOPT build.
> > >
> > >
> > >
> > > Using gcc-6.3 from Linaro, I don’t see any issue with DS5 debugging.
> > >
> > > Am I missing any steps?
> > >
> > > Build is done with GCC5_AARCH64_PREFIX=aarch64-linux-gnu
> > >
> > >
> > >
> > > Another question: it seems that the DS5 scripts limit the path size with
> > > 255
> > chars. With a source built by Yocto, it can easily be more than that.
> > >
> > > Attempt to add symbols for such modules ends up with error message in
> > the DS5 command window that it could not add those symbols.
> > >
> > > Is there a procedure to increase the path length limit?
> > >
> >
> > I have never in my life used a DS-5 to debug EDK2 running on bare metal,
> > so
> > unfortunately, I won't be able to help you.
> >
> How do you normally debug edk2 with DS5? Or, are you using a different
> mechanism?
> Debugging with DS5 was/is very convenient.
>

I do my prototyping mainly in QEMU, using GDB for debug.

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

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

Re: [edk2-devel] [edk2-non-osi][PATCH 2/2] Platforms/RPi4: Add Trusted Firmware binaries

[Leif Lindholm]

On Wed, Dec 11, 2019 at 11:24:00 +, Pete Batard wrote:
> Similar to what is the case with the Raspberry Pi 3, the Raspberry Pi
> 4 UEFI firmware requires the provision of a Trusted Firmware binary
> (TF-A).
> 
> The binary is built for a dtb base address of 0x0002 and a UEFI
> payload base address of 0x0003.
> 
> Binaries are built using a custom version of TF-A (the source of which
> is documented in the Readme), since the official repository is missing
> a fix to get proper baudrate when using a recent version of start4.elf,
> as we as the ability to switch between PL011 and mini UART. We are
> currently working with TF-A to upstream both these fixes so that we can
> switch to binaries built from official source at a later date.
> 
> In order to provide the ability to switch serial I/O controllers, a
> feature we will be adding to the RPi4 UEFI Firmware, and not lose TF-A
> output, two binaries are provided, one for mini UART output and one for
> PL011 output.
> 
> Signed-off-by: Pete Batard 
> ---
>  Platform/RaspberryPi/RPi4/TrustedFirmware/License.txt   |  26 
> 
>  Platform/RaspberryPi/RPi4/TrustedFirmware/Readme.md |  12 +
>  Platform/RaspberryPi/RPi4/TrustedFirmware/bl31_miniuart.bin | Bin 0 -> 41072 
> bytes
>  Platform/RaspberryPi/RPi4/TrustedFirmware/bl31_pl011.bin| Bin 0 -> 41072 
> bytes
>  4 files changed, 38 insertions(+)
> 

> new file mode 100644
> index ..7f1749dfc3a0
> --- /dev/null
> +++ b/Platform/RaspberryPi/RPi4/TrustedFirmware/Readme.md
> @@ -0,0 +1,12 @@
> +ARM Trusted Firmware for Raspberry Pi 4
> +===
> +
> +The `bl31_#.bin` TF-A binaries found in this repository were built on a 
> Debian 10.2 system
> +from https://github.com/pbatard/arm-trusted-firmware/tree/pi4 (pi4 branch) 
> using the command:
> +
> +```
> +make PLAT=rpi4 RPI3_PRELOADED_DTB_BASE=0x2 PRELOADED_BL33_BASE=0x3 
> SUPPORT_VFP=1 [RPI3_USE_PL011_UART=1] DEBUG=0 all
> +```
> +
> +The only difference between these firmwares is that the 
> `RPI3_USE_PL011_UART=1` option was added
> +to build `bl31_pl011.bin` so that it uses PL011 for serial output rather 
> than the "mini UART".

Sanity check: do the build commands still use RPI3_ options for rpi4?

Best Regards,

Leif

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

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

Re: [edk2-devel] [edk2-non-osi][PATCH 0/2] Add prerequisite binary files for RPi4 platform

[Ard Biesheuvel]

On Wed, 11 Dec 2019 at 12:24, Pete Batard  wrote:
>
> This series of patches adds the binaries we need available to introduce
> Raspberry Pi 4 support.
>
> Similar to the Pi 3, we must have TF-A and Device Tree binaries we can embed.
>
> Pete Batard (2):
>   Platforms/RPi4: Add Device Tree
>   Platforms/RPi4: Add Trusted Firmware binaries
>

Thanks Pete

Pushed as d580026dbbe8..a2484c34ceba


>  Platform/RaspberryPi/RPi4/DeviceTree/License.txt| 340 
> 
>  Platform/RaspberryPi/RPi4/DeviceTree/Readme.md  |  13 +
>  Platform/RaspberryPi/RPi4/DeviceTree/bcm2711-rpi-4-b.dtb| Bin 0 -> 40697 
> bytes
>  Platform/RaspberryPi/RPi4/TrustedFirmware/License.txt   |  26 ++
>  Platform/RaspberryPi/RPi4/TrustedFirmware/Readme.md |  12 +
>  Platform/RaspberryPi/RPi4/TrustedFirmware/bl31_miniuart.bin | Bin 0 -> 41072 
> bytes
>  Platform/RaspberryPi/RPi4/TrustedFirmware/bl31_pl011.bin| Bin 0 -> 41072 
> bytes
>  7 files changed, 391 insertions(+)
>  create mode 100644 Platform/RaspberryPi/RPi4/DeviceTree/License.txt
>  create mode 100644 Platform/RaspberryPi/RPi4/DeviceTree/Readme.md
>  create mode 100644 Platform/RaspberryPi/RPi4/DeviceTree/bcm2711-rpi-4-b.dtb
>  create mode 100644 Platform/RaspberryPi/RPi4/TrustedFirmware/License.txt
>  create mode 100644 Platform/RaspberryPi/RPi4/TrustedFirmware/Readme.md
>  create mode 100644 
> Platform/RaspberryPi/RPi4/TrustedFirmware/bl31_miniuart.bin
>  create mode 100644 Platform/RaspberryPi/RPi4/TrustedFirmware/bl31_pl011.bin
>
> --
> 2.21.0.windows.1
>

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

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

Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

[Ni, Ray]

Jeff,

Tom from AMD booked the meeting for SEV discussion months ago. I am afraid 
there is no time for this discussion.

Let's try to resolve it in mails.



Firstly, let me rephase the problem and your proposed solutions here 
(subjective + verb + objective). Sunny's input is also included. Hope Mike K 
and others can provide inputs.

Personally, I agree with 2.b. It helps us to gradually migrate the 
PlatformBootManagerLib to PlatformBootManager protocol. Protocol with Revision 
field helps to reduce the impact to old platforms with new APIs added.



**Problem:

   Platform requires certain BlockIo/SimpleFileSystem/LoadFile 
instances don't cause Boot created. It's a need of platform customization.



**Details:

   Boot for BlockIo/SimpleFileSystem/LoadFile are created by 
API EfiBootMangerRefreshAllBootOptions(). There are 2 places that call this API:

  1.  Platform Boot Manager calls the API (usually in the full configuration 
boot path)
  2.  UiApp calls the API when entering "Boot Manager" page and "Boot 
Maintenance Manager" page.



Platform can change Platform Boot Manager to remove the unneeded Boot in 
case #1.

But platform has no way to remove the Boot created in case #2 .



**Potential solutions:

  1.  Update UiApp
 *   Define a new PCD and a new event group.

If PCD is TRUE, UiApp signals the event. Event callback creates the Boot. 
Otherwise, EfiBootManagerRefreshAllBootOptions() is called.

 *   Add a new PlatformBootManagerLib API (implemented by platform).

UiApp calls the new API instead of EfiBootManagerRefreshAllBootOption. (need to 
coordinate rollout with updates to all platforms).

 *   Add a new protocol (implemented by platform).

UiApp calls the new protocol if it exists otherwise calls 
EfiBootManagerRefreshAllBootOption.



  1.  Update EfiBootManagerRefreshAllBootOptions()
 *   Add a new library class (implemented by platform).

EfiBootManagerRefreshAllBootOption() calls the new library class.

 *   Add a new PlatformBootManager protocol (implemented by platform).

EfiBootManagerRefreshAllBootOption() calls the new protocol if it exists.

Thanks,
Ray

From: Jeff Brasen 
Sent: Wednesday, December 11, 2019 4:46 AM
To: Ni, Ray ; devel@edk2.groups.io; Laszlo Ersek 
; af...@apple.com; disc...@edk2.groups.io
Cc: Ashish Singhal ; Wang, Jian J 
; Wu, Hao A ; Gao, Zhichao 
; Kinney, Michael D 
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration

Can we discuss this at the design meeting this week (12/12)?


Thanks,

Jeff


From: Jeff Brasen
Sent: Thursday, November 14, 2019 10:04 AM
To: Ni, Ray mailto:ray...@intel.com>>; 
devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>; Laszlo Ersek 
mailto:ler...@redhat.com>>; 
af...@apple.com 
mailto:af...@apple.com>>
Cc: Ashish Singhal mailto:ashishsin...@nvidia.com>>; 
Wang, Jian J mailto:jian.j.w...@intel.com>>; Wu, Hao A 
mailto:hao.a...@intel.com>>; Gao, Zhichao 
mailto:zhichao@intel.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration


Yes, I think that would be good.



Summarizing everything in this thread



Problem: Platform needs to customize the boot options, this can be done for 
normal boot but the UiApp calls EfiBootManagerRefreshAllBootOption in a couple 
places.



Potential solutions:

1 - Define new PCD and event group if PCD is set true then signal event instead 
of calling EfiBootManagerRefreshAllBootOption in UiApp

2 - Add new function to boot manager library and replace call to 
EfiBootManagerRefreshAllBootOption in UiApp (need to coordinate rollout with 
updates to all platform.

3 - Add new protocol with new function, if supported call this otherwise call 
EfiBootManagerRefreshAllBootOption as is done now

4 - For 2/3 use  generic function so we don't need new APIs for future expansion

5 - Update EfiBootManagerRefreshAllBootOption to call platform specific 
function.



Thanks,
Jeff





From: Ni, Ray mailto:ray...@intel.com>>
Sent: Wednesday, November 13, 2019 7:09 PM
To: devel@edk2.groups.io; Jeff Brasen 
mailto:jbra...@nvidia.com>>; Laszlo Ersek 
mailto:ler...@redhat.com>>; 
af...@apple.com
Cc: Ashish Singhal mailto:ashishsin...@nvidia.com>>; 
Wang, Jian J mailto:jian.j.w...@intel.com>>; Wu, Hao A 
mailto:hao.a...@intel.com>>; Gao, Zhichao 
mailto:zhichao@intel.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Jeff,

I think it's a good topic that we could discuss in the open design meeting.

Are you ok to present the problem you have and discuss the potential solutions 
in that meeting?

https://github.com/tianocore/tianocore.github.io/wiki/Design-Meeting



Thanks,

Ray



From: devel@edk2.groups.io

Re: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V6] MdePkg/Protocols: New PCI Express Platform Protocol, EFI encodings

[Javeed, Ashraf]

This change is pushed in to the following EDK Repo for review:-
https://github.com/ashrafj/edk2-staging/commit/560b6c1dd5b7eae8c49bd43e83335c7d13fef4a3

Please review and provide your feedback.
Thanks
Ashraf

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Javeed,
> Ashraf
> Sent: Wednesday, December 11, 2019 4:41 PM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Ni, Ray 
> Subject: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V6]
> MdePkg/Protocols: New PCI Express Platform Protocol, EFI encodings
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1954
> 
> Two interfaces added to PCI Express Platform Protocol:-
> (1) GetDevicePolicy() -> to retrieve device-specific platform policies
> (2) NotifyDeviceState -> to notify platform about device PCI Express
> configuration state
> PCI Express Override Protocol is made alias to PCI Express Platform
> Protocol.
> EFI encodings introduced for the following PCI Express features, are:
> 1.Maximum Payload Size (MPS)
> 2.Maximum Read Request Size (MRRS)
> 3.Extended Tag
> 4.Relax Order Enable
> 5.No Snoop Enable
> 6.ASPM support
> 7.Common Clock Configuration
> 8.Extended SYNC
> 9.Atomic Op
> 10.   LTR Enable
> 11.   PTM support
> 12.   CTO support
> 13.   CPM
> 14.   L1 PM Substates
> 
> New source files with unique definitions are:
> MdePkg/Include/Protocol/PciExpressPlatform.h,
> MdePkg/Include/Protocol/PciExpressOverride.h
> 
> Signed-off-by: Ashraf Javeed 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Ray Ni 
> ---
> 
> In V6: renamed the protocol definition source files, remove PCD comments,
> and renamed NotifyDeviceConfiguration -> NotifyDeviceState
> 
> In V5: Revised ECR to define new PCI Platform Protocol to support the
> PCI Express capability features:-
> EFI_PCI_EXPRESS_PLATFORM_PROTOCOL,
> EFI_PCI_EXPRESS_OVERRIDE_PROTOCOL.
> Added new interface -> NotifyDeviceConfiguration
> Added new EFI encodings / data types for PCIe features:-
> CPM, L1 PM substates.
> Enhance the definition of the PCIe feature AtomicOp to support additional
> attribute - Egress blocking of the port.
> 
> In V4: Redefinition of the existing interfaces in the EFI_PCI_PLATFORM_-
> PROTOCOL2, to avoid type casting and to avoid further future change
> 
> In V3: License update in the header sections of source files
> 
> In V2: Correction made to header sections of source files
> ---
>  MdePkg/Include/Protocol/PciExpressOverride.h |  37
> +
>  MdePkg/Include/Protocol/PciExpressPlatform.h | 547
> +
> +
> +
> +
> +
> +
> +
> +
> +++
>  MdePkg/Include/Protocol/PciOverride2.h   |  37 
> ---
> --
>  MdePkg/Include/Protocol/PciPlatform2.h   | 524 
> --
> --
> --
> --
> --
> --
>  MdePkg/MdePkg.dec|   8 
>  5 files changed, 588 insertions(+), 565 deletions(-)
> 
> diff --git a/MdePkg/Include/Protocol/PciExpressOverride.h
> b/MdePkg/Include/Protocol/PciExpressOverride.h
> new file mode 100644
> index 000..aab9375
> --- /dev/null
> +++ b/MdePkg/Include/Protocol/PciExpressOverride.h
> @@ -0,0 +1,37 @@
> +/** @file
> +  This file declares EFI PCI Express Override protocol which provides the
> interface between
> +  the PCI bus driver/PCI Host Bridge Resource Allocation driver and an
> implementation's
> +  driver to describe the unique features of a platform.
> +  This protocol is optional.
> +
> +Copyright (c) 2019, Intel Corporation. All rights reserved.
> +SPDX-License-Identifier: BSD-2-Clause-Patent
> +
> +
> +**/
> +
> +#ifndef _PCI_EXPRESS_OVERRIDE_H_
> +#define _PCI_EXPRESS_OVERRIDE_H_
> +
> +///
> +/// EFI_PCI_EXPRESS_OVERRIDE_PROTOCOL has the same structure as of
> EFI_PCI_EXPRESS_PLATFORM_PROTOCOL
> +///
> +#include "PciExpressPlatform.h"
> +
> +///
> +/// Global ID for the  EFI_PCI_EXPRESS_OVERRIDE_PROTOCOL
> +///
> +#define EFI_PCI_EXPRESS_OVERR

Re: [edk2-devel] [edk2-platforms][PATCH 1/5] Platform/RPi: Fix overlap of SoC registers and RAM

[Pete Batard]

Hi Philippe, thanks for reviewing these.

On 2019.12.11 12:21, Philippe Mathieu-Daudé wrote:

On 12/11/19 12:25 PM, Pete Batard wrote:

From: Ard Biesheuvel 

Having RAM and SoC register regions overlap is problematic for MMIO,
since, at the very least, we don't want these regions to be declared
as cacheable.

Signed-off-by: Pete Batard 
---
  Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c | 36 
+---

  1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c 
b/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c

index cc761bea1307..781cf78b83d3 100644
--- a/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
+++ b/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
@@ -60,7 +60,7 @@ ArmPlatformGetVirtualMemoryMap (
  {
    UINTN Index = 0;
    UINTN GpuIndex;
-  INT64 ExtendedMemorySize;
+  INT64 SystemMemorySize;
    ARM_MEMORY_REGION_DESCRIPTOR  *VirtualMemoryTable;
    // Early output of the info we got from VideoCore can prove valuable.
@@ -120,21 +120,21 @@ ArmPlatformGetVirtualMemoryMap (
    VirtualMemoryInfo[Index].Type = RPI_MEM_RESERVED_REGION;
    VirtualMemoryInfo[Index++].Name   = L"GPU Reserved";
-  // Compute the amount of extended RAM available on this platform
-  ExtendedMemorySize = SIZE_256MB;
-  ExtendedMemorySize <<= (mBoardRevision >> 20) & 0x07;
-  ExtendedMemorySize -= SIZE_1GB;
-  if (ExtendedMemorySize > 0) {
-    VirtualMemoryTable[Index].PhysicalBase  = FixedPcdGet64 
(PcdExtendedMemoryBase);
-    VirtualMemoryTable[Index].VirtualBase   = 
VirtualMemoryTable[Index].PhysicalBase;

-    VirtualMemoryTable[Index].Length    = ExtendedMemorySize;
-    VirtualMemoryTable[Index].Attributes    = 
ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;

-    VirtualMemoryInfo[Index].Type   = RPI_MEM_BASIC_REGION;
-    VirtualMemoryInfo[Index++].Name = L"Extended System RAM";
-  }
+  // Compute the total RAM size available on this platform
+  SystemMemorySize = SIZE_256MB;
+  SystemMemorySize <<= (mBoardRevision >> 20) & 0x07;


TIL I learn this field is 3 bits (I thought it was 4).


"32 GB should be enough for everybody" (which is the max RAM you'll be 
able to declare in 3 bits with the current scheme).


Unless RAM becomes very very cheap, I doubt the Raspberry Pi foundation 
considers the current limit as much of a problem...





+
+  //
+  // Ensure that what we declare as System Memory doesn't overlap 
with the
+  // Bcm2836 SoC registers. This can be achieved through a MIN () 
with the

+  // base address since SystemMemoryBase is 0 (we assert if it isn't).


Is the later comment "// On the Pi 3 the SoC registers may overlap 
VideoCore => fix this

" still accurate?


It is. We read the size of the GPU region (mVideoCoreSize) and the size 
of the System RAM from different queries. The thing is actually that 
VideoCore on the Pi 3 considers that its region should encompass the SoC 
registers, so it reports a size that does so, whereas we want to report 
them as separate regions (like they are reported on the Pi 4).


Regards,

/Pete


+  //
+  SystemMemorySize = MIN(SystemMemorySize, BCM2836_SOC_REGISTERS);
    // Extended SoC registers (PCIe, genet, ...)
    if (BCM2711_SOC_REGISTERS > 0) {
+    // Same overlap protection as above for the Bcm2711 SoC registers
+    SystemMemorySize    = MIN(SystemMemorySize, 
BCM2711_SOC_REGISTERS);

  VirtualMemoryTable[Index].PhysicalBase  = BCM2711_SOC_REGISTERS;
  VirtualMemoryTable[Index].VirtualBase   = 
VirtualMemoryTable[Index].PhysicalBase;
  VirtualMemoryTable[Index].Length    = 
BCM2711_SOC_REGISTER_LENGTH;

@@ -155,6 +155,16 @@ ArmPlatformGetVirtualMemoryMap (
    VirtualMemoryInfo[Index].Type = RPI_MEM_RESERVED_REGION;
    VirtualMemoryInfo[Index++].Name   = L"SoC Reserved (283x)";


Sigh, the 2711/2838 naming is very confusing.


+  // If we have RAM above the 1 GB mark, declare it
+  if (SystemMemorySize - SIZE_1GB > 0) {
+    VirtualMemoryTable[Index].PhysicalBase  = FixedPcdGet64 
(PcdExtendedMemoryBase);
+    VirtualMemoryTable[Index].VirtualBase   = 
VirtualMemoryTable[Index].PhysicalBase;
+    VirtualMemoryTable[Index].Length    = SystemMemorySize - 
SIZE_1GB;
+    VirtualMemoryTable[Index].Attributes    = 
ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;

+    VirtualMemoryInfo[Index].Type   = RPI_MEM_BASIC_REGION;
+    VirtualMemoryInfo[Index++].Name = L"Extended System RAM";
+  }
+
    // End of Table
    VirtualMemoryTable[Index].PhysicalBase    = 0;
    VirtualMemoryTable[Index].VirtualBase = 0;



Reviewed-by: Philippe Mathieu-Daude 




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

View/Reply Online (#52121): https://edk2.groups.io/g/devel/message/52121
Mute This Topic: https://gro

Re: [edk2-devel] [edk2-platforms][PATCH 2/5] Platform/RPi: Don't describe MMIO regions as memory

[Philippe Mathieu-Daudé]

On 12/11/19 12:25 PM, Pete Batard wrote:

From: Ard Biesheuvel 

When using ACPI OpRegions to poke device registers, Linux will use
the UEFI memory map to decide which memory attributes to use, and
so they should not be described as cacheable memory.

Since MMIO regions that don't require an OS virtual mapping at runtime
don't really belong in the UEFI memory map to begin with, omit them
entirely.

Signed-off-by: Pete Batard 
---
  Platform/RaspberryPi/Include/Library/RPiMem.h|  7 ---
  Platform/RaspberryPi/Library/MemoryInitPeiLib/MemoryInitPeiLib.c | 10 
++
  Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c|  6 +++---
  3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/Platform/RaspberryPi/Include/Library/RPiMem.h 
b/Platform/RaspberryPi/Include/Library/RPiMem.h
index 9d38e4b6cfb3..a033af369bb0 100644
--- a/Platform/RaspberryPi/Include/Library/RPiMem.h
+++ b/Platform/RaspberryPi/Include/Library/RPiMem.h
@@ -9,9 +9,10 @@
  #ifndef RPI_MEM_H__
  #define RPI_MEM_H__
  
-#define RPI_MEM_BASIC_REGION0

-#define RPI_MEM_RUNTIME_REGION  1
-#define RPI_MEM_RESERVED_REGION 2
+#define RPI_MEM_UNMAPPED_REGION 0
+#define RPI_MEM_BASIC_REGION1
+#define RPI_MEM_RUNTIME_REGION  2
+#define RPI_MEM_RESERVED_REGION 3
  
  typedef struct {

CONST CHAR16* Name;
diff --git a/Platform/RaspberryPi/Library/MemoryInitPeiLib/MemoryInitPeiLib.c 
b/Platform/RaspberryPi/Library/MemoryInitPeiLib/MemoryInitPeiLib.c
index 3a0f7e19e993..7ba1cc5602d2 100644
--- a/Platform/RaspberryPi/Library/MemoryInitPeiLib/MemoryInitPeiLib.c
+++ b/Platform/RaspberryPi/Library/MemoryInitPeiLib/MemoryInitPeiLib.c
@@ -72,6 +72,15 @@ AddRuntimeServicesRegion (
);
  }
  
+STATIC

+VOID
+AddUnmappedMemoryRegion (
+  IN ARM_MEMORY_REGION_DESCRIPTOR *Desc
+  )
+{
+  // Do nothing
+}
+
  STATIC
  VOID
  AddReservedMemoryRegion (
@@ -88,6 +97,7 @@ AddReservedMemoryRegion (
  }
  
  void (*AddRegion[]) (IN ARM_MEMORY_REGION_DESCRIPTOR *Desc) = {

+  AddUnmappedMemoryRegion,
AddBasicMemoryRegion,
AddRuntimeServicesRegion,
AddReservedMemoryRegion,
diff --git a/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c 
b/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
index 781cf78b83d3..f8223d1b94e8 100644
--- a/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
+++ b/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
@@ -117,7 +117,7 @@ ArmPlatformGetVirtualMemoryMap (
VirtualMemoryTable[Index].VirtualBase = 
VirtualMemoryTable[Index].PhysicalBase;
VirtualMemoryTable[Index].Length  = mVideoCoreSize;
VirtualMemoryTable[Index].Attributes  = 
ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
-  VirtualMemoryInfo[Index].Type = RPI_MEM_RESERVED_REGION;
+  VirtualMemoryInfo[Index].Type = RPI_MEM_UNMAPPED_REGION;
VirtualMemoryInfo[Index++].Name   = L"GPU Reserved";
  
// Compute the total RAM size available on this platform

@@ -139,7 +139,7 @@ ArmPlatformGetVirtualMemoryMap (
  VirtualMemoryTable[Index].VirtualBase   = 
VirtualMemoryTable[Index].PhysicalBase;
  VirtualMemoryTable[Index].Length= BCM2711_SOC_REGISTER_LENGTH;
  VirtualMemoryTable[Index].Attributes= 
ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
-VirtualMemoryInfo[Index].Type   = RPI_MEM_RESERVED_REGION;
+VirtualMemoryInfo[Index].Type   = RPI_MEM_UNMAPPED_REGION;
  VirtualMemoryInfo[Index++].Name = L"SoC Reserved (27xx)";
}
  
@@ -152,7 +152,7 @@ ArmPlatformGetVirtualMemoryMap (

VirtualMemoryTable[Index].VirtualBase = 
VirtualMemoryTable[Index].PhysicalBase;
VirtualMemoryTable[Index].Length  = BCM2836_SOC_REGISTER_LENGTH;
VirtualMemoryTable[Index].Attributes  = 
ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
-  VirtualMemoryInfo[Index].Type = RPI_MEM_RESERVED_REGION;
+  VirtualMemoryInfo[Index].Type = RPI_MEM_UNMAPPED_REGION;
VirtualMemoryInfo[Index++].Name   = L"SoC Reserved (283x)";
  
// If we have RAM above the 1 GB mark, declare it




Reviewed-by: Philippe Mathieu-Daude 


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

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

Re: [edk2-devel] [edk2-platforms][PATCH 1/5] Platform/RPi: Fix overlap of SoC registers and RAM

[Philippe Mathieu-Daudé]

On 12/11/19 12:25 PM, Pete Batard wrote:

From: Ard Biesheuvel 

Having RAM and SoC register regions overlap is problematic for MMIO,
since, at the very least, we don't want these regions to be declared
as cacheable.

Signed-off-by: Pete Batard 
---
  Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c | 36 
+---
  1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c 
b/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
index cc761bea1307..781cf78b83d3 100644
--- a/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
+++ b/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
@@ -60,7 +60,7 @@ ArmPlatformGetVirtualMemoryMap (
  {
UINTN Index = 0;
UINTN GpuIndex;
-  INT64 ExtendedMemorySize;
+  INT64 SystemMemorySize;
ARM_MEMORY_REGION_DESCRIPTOR  *VirtualMemoryTable;
  
// Early output of the info we got from VideoCore can prove valuable.

@@ -120,21 +120,21 @@ ArmPlatformGetVirtualMemoryMap (
VirtualMemoryInfo[Index].Type = RPI_MEM_RESERVED_REGION;
VirtualMemoryInfo[Index++].Name   = L"GPU Reserved";
  
-  // Compute the amount of extended RAM available on this platform

-  ExtendedMemorySize = SIZE_256MB;
-  ExtendedMemorySize <<= (mBoardRevision >> 20) & 0x07;
-  ExtendedMemorySize -= SIZE_1GB;
-  if (ExtendedMemorySize > 0) {
-VirtualMemoryTable[Index].PhysicalBase  = FixedPcdGet64 
(PcdExtendedMemoryBase);
-VirtualMemoryTable[Index].VirtualBase   = 
VirtualMemoryTable[Index].PhysicalBase;
-VirtualMemoryTable[Index].Length= ExtendedMemorySize;
-VirtualMemoryTable[Index].Attributes= 
ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
-VirtualMemoryInfo[Index].Type   = RPI_MEM_BASIC_REGION;
-VirtualMemoryInfo[Index++].Name = L"Extended System RAM";
-  }
+  // Compute the total RAM size available on this platform
+  SystemMemorySize = SIZE_256MB;
+  SystemMemorySize <<= (mBoardRevision >> 20) & 0x07;


TIL I learn this field is 3 bits (I thought it was 4).


+
+  //
+  // Ensure that what we declare as System Memory doesn't overlap with the
+  // Bcm2836 SoC registers. This can be achieved through a MIN () with the
+  // base address since SystemMemoryBase is 0 (we assert if it isn't).


Is the later comment "// On the Pi 3 the SoC registers may overlap 
VideoCore => fix this

" still accurate?


+  //
+  SystemMemorySize = MIN(SystemMemorySize, BCM2836_SOC_REGISTERS);
  
// Extended SoC registers (PCIe, genet, ...)

if (BCM2711_SOC_REGISTERS > 0) {
+// Same overlap protection as above for the Bcm2711 SoC registers
+SystemMemorySize= MIN(SystemMemorySize, 
BCM2711_SOC_REGISTERS);
  VirtualMemoryTable[Index].PhysicalBase  = BCM2711_SOC_REGISTERS;
  VirtualMemoryTable[Index].VirtualBase   = 
VirtualMemoryTable[Index].PhysicalBase;
  VirtualMemoryTable[Index].Length= BCM2711_SOC_REGISTER_LENGTH;
@@ -155,6 +155,16 @@ ArmPlatformGetVirtualMemoryMap (
VirtualMemoryInfo[Index].Type = RPI_MEM_RESERVED_REGION;
VirtualMemoryInfo[Index++].Name   = L"SoC Reserved (283x)";


Sigh, the 2711/2838 naming is very confusing.

  
+  // If we have RAM above the 1 GB mark, declare it

+  if (SystemMemorySize - SIZE_1GB > 0) {
+VirtualMemoryTable[Index].PhysicalBase  = FixedPcdGet64 
(PcdExtendedMemoryBase);
+VirtualMemoryTable[Index].VirtualBase   = 
VirtualMemoryTable[Index].PhysicalBase;
+VirtualMemoryTable[Index].Length= SystemMemorySize - SIZE_1GB;
+VirtualMemoryTable[Index].Attributes= 
ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
+VirtualMemoryInfo[Index].Type   = RPI_MEM_BASIC_REGION;
+VirtualMemoryInfo[Index++].Name = L"Extended System RAM";
+  }
+
// End of Table
VirtualMemoryTable[Index].PhysicalBase= 0;
VirtualMemoryTable[Index].VirtualBase = 0;



Reviewed-by: Philippe Mathieu-Daude 


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

View/Reply Online (#52119): https://edk2.groups.io/g/devel/message/52119
Mute This Topic: https://groups.io/mt/68147481/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 2/5] Platform/RPi: Don't describe MMIO regions as memory

[Pete Batard]

From: Ard Biesheuvel 

When using ACPI OpRegions to poke device registers, Linux will use
the UEFI memory map to decide which memory attributes to use, and
so they should not be described as cacheable memory.

Since MMIO regions that don't require an OS virtual mapping at runtime
don't really belong in the UEFI memory map to begin with, omit them
entirely.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Include/Library/RPiMem.h|  7 ---
 Platform/RaspberryPi/Library/MemoryInitPeiLib/MemoryInitPeiLib.c | 10 
++
 Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c|  6 +++---
 3 files changed, 17 insertions(+), 6 deletions(-)

diff --git a/Platform/RaspberryPi/Include/Library/RPiMem.h 
b/Platform/RaspberryPi/Include/Library/RPiMem.h
index 9d38e4b6cfb3..a033af369bb0 100644
--- a/Platform/RaspberryPi/Include/Library/RPiMem.h
+++ b/Platform/RaspberryPi/Include/Library/RPiMem.h
@@ -9,9 +9,10 @@
 #ifndef RPI_MEM_H__
 #define RPI_MEM_H__
 
-#define RPI_MEM_BASIC_REGION0
-#define RPI_MEM_RUNTIME_REGION  1
-#define RPI_MEM_RESERVED_REGION 2
+#define RPI_MEM_UNMAPPED_REGION 0
+#define RPI_MEM_BASIC_REGION1
+#define RPI_MEM_RUNTIME_REGION  2
+#define RPI_MEM_RESERVED_REGION 3
 
 typedef struct {
   CONST CHAR16* Name;
diff --git a/Platform/RaspberryPi/Library/MemoryInitPeiLib/MemoryInitPeiLib.c 
b/Platform/RaspberryPi/Library/MemoryInitPeiLib/MemoryInitPeiLib.c
index 3a0f7e19e993..7ba1cc5602d2 100644
--- a/Platform/RaspberryPi/Library/MemoryInitPeiLib/MemoryInitPeiLib.c
+++ b/Platform/RaspberryPi/Library/MemoryInitPeiLib/MemoryInitPeiLib.c
@@ -72,6 +72,15 @@ AddRuntimeServicesRegion (
   );
 }
 
+STATIC
+VOID
+AddUnmappedMemoryRegion (
+  IN ARM_MEMORY_REGION_DESCRIPTOR *Desc
+  )
+{
+  // Do nothing
+}
+
 STATIC
 VOID
 AddReservedMemoryRegion (
@@ -88,6 +97,7 @@ AddReservedMemoryRegion (
 }
 
 void (*AddRegion[]) (IN ARM_MEMORY_REGION_DESCRIPTOR *Desc) = {
+  AddUnmappedMemoryRegion,
   AddBasicMemoryRegion,
   AddRuntimeServicesRegion,
   AddReservedMemoryRegion,
diff --git a/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c 
b/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
index 781cf78b83d3..f8223d1b94e8 100644
--- a/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
+++ b/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
@@ -117,7 +117,7 @@ ArmPlatformGetVirtualMemoryMap (
   VirtualMemoryTable[Index].VirtualBase = 
VirtualMemoryTable[Index].PhysicalBase;
   VirtualMemoryTable[Index].Length  = mVideoCoreSize;
   VirtualMemoryTable[Index].Attributes  = 
ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
-  VirtualMemoryInfo[Index].Type = RPI_MEM_RESERVED_REGION;
+  VirtualMemoryInfo[Index].Type = RPI_MEM_UNMAPPED_REGION;
   VirtualMemoryInfo[Index++].Name   = L"GPU Reserved";
 
   // Compute the total RAM size available on this platform
@@ -139,7 +139,7 @@ ArmPlatformGetVirtualMemoryMap (
 VirtualMemoryTable[Index].VirtualBase   = 
VirtualMemoryTable[Index].PhysicalBase;
 VirtualMemoryTable[Index].Length= BCM2711_SOC_REGISTER_LENGTH;
 VirtualMemoryTable[Index].Attributes= 
ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
-VirtualMemoryInfo[Index].Type   = RPI_MEM_RESERVED_REGION;
+VirtualMemoryInfo[Index].Type   = RPI_MEM_UNMAPPED_REGION;
 VirtualMemoryInfo[Index++].Name = L"SoC Reserved (27xx)";
   }
 
@@ -152,7 +152,7 @@ ArmPlatformGetVirtualMemoryMap (
   VirtualMemoryTable[Index].VirtualBase = 
VirtualMemoryTable[Index].PhysicalBase;
   VirtualMemoryTable[Index].Length  = BCM2836_SOC_REGISTER_LENGTH;
   VirtualMemoryTable[Index].Attributes  = 
ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
-  VirtualMemoryInfo[Index].Type = RPI_MEM_RESERVED_REGION;
+  VirtualMemoryInfo[Index].Type = RPI_MEM_UNMAPPED_REGION;
   VirtualMemoryInfo[Index++].Name   = L"SoC Reserved (283x)";
 
   // If we have RAM above the 1 GB mark, declare it
-- 
2.21.0.windows.1


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

View/Reply Online (#52115): https://edk2.groups.io/g/devel/message/52115
Mute This Topic: https://groups.io/mt/68147483/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 0/5] Add initial Raspberry Pi 4 platform

[Pete Batard]

This series adds basic support to build the Raspberry Pi 4 platform.

It requires the earlier series, that add binary files for the platform,
to have been applied to edk2-non-osi.

For the introduction of the platform, USB support is not yet enabled
which means that user I/O has to be carried out through serial.

The first two patches of the series are fixes for the common RPi
platform that will become relevant when we introduce support for
PCIe/xHCI.

The second two patch deal with the specific ACPI changes for the
Pi 4 platform. To make these clearer, an intermediate patch, that
simply enacts a straight unaltered copy of the Pi 3 ACPI files is
added, so that the changes we apply can be made obvious. We also
use this opportunity to switch the source of some tables (GTDT,
MADT) to proper aslc.

Finally, the last patch in this series adds the platform files
along with a Readme detailing the installation requirements and
current state of the platform.

Andrei Warkentin (2):
  Platform/RPi4: Update ACPI tables for the new platform
  Platform/RPi4: Add base platform files

Ard Biesheuvel (2):
  Platform/RPi: Fix overlap of SoC registers and RAM
  Platform/RPi: Don't describe MMIO regions as memory

Samer El-Haj-Mahmoud (1):
  Platform/RPi4: Add initial ACPI tables

 Platform/RaspberryPi/Include/Library/RPiMem.h|   7 +-
 Platform/RaspberryPi/Library/MemoryInitPeiLib/MemoryInitPeiLib.c |  10 +
 Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c|  42 +-
 Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.h|  92 +++
 Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.inf  |  49 ++
 Platform/RaspberryPi/RPi4/AcpiTables/Csrt.aslc   | 327 
++
 Platform/RaspberryPi/RPi4/AcpiTables/Dbg2.aslc   |  28 +
 Platform/RaspberryPi/RPi4/AcpiTables/Dsdt.asl| 505 

 Platform/RaspberryPi/RPi4/AcpiTables/Fadt.aslc   |  46 ++
 Platform/RaspberryPi/RPi4/AcpiTables/Gtdt.aslc   |  56 ++
 Platform/RaspberryPi/RPi4/AcpiTables/Madt.aslc   |  64 ++
 Platform/RaspberryPi/RPi4/AcpiTables/Pep.asl |  90 +++
 Platform/RaspberryPi/RPi4/AcpiTables/Pep.c   |  79 +++
 Platform/RaspberryPi/RPi4/AcpiTables/Pep.h   | 121 
 Platform/RaspberryPi/RPi4/AcpiTables/Rhpx.asl| 195 ++
 Platform/RaspberryPi/RPi4/AcpiTables/Sdhc.asl|  99 +++
 Platform/RaspberryPi/RPi4/AcpiTables/Spcr.asl|  48 ++
 Platform/RaspberryPi/RPi4/AcpiTables/Uart.asl| 152 +
 Platform/RaspberryPi/RPi4/RPi4.dsc   | 637 

 Platform/RaspberryPi/RPi4/RPi4.fdf   | 432 
+
 Platform/RaspberryPi/RPi4/Readme.md  | 110 
 21 files changed, 3170 insertions(+), 19 deletions(-)
 create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.h
 create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.inf
 create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Csrt.aslc
 create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Dbg2.aslc
 create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Dsdt.asl
 create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Fadt.aslc
 create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Gtdt.aslc
 create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Madt.aslc
 create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Pep.asl
 create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Pep.c
 create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Pep.h
 create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Rhpx.asl
 create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Sdhc.asl
 create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Spcr.asl
 create mode 100644 Platform/RaspberryPi/RPi4/AcpiTables/Uart.asl
 create mode 100644 Platform/RaspberryPi/RPi4/RPi4.dsc
 create mode 100644 Platform/RaspberryPi/RPi4/RPi4.fdf
 create mode 100644 Platform/RaspberryPi/RPi4/Readme.md

-- 
2.21.0.windows.1


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

View/Reply Online (#52113): https://edk2.groups.io/g/devel/message/52113
Mute This Topic: https://groups.io/mt/68147480/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 5/5] Platform/RPi4: Add base platform files

[Pete Batard]

From: Andrei Warkentin 

This enables building the initial RPi4 platform firmware.

Note that PCIe and xHCI are missing at this stage and that this
version of the firmware uses miniUART for serial I/O. PCIe and
xHCI support will be added in a later patch series as well as
the ability to switch between PL011 and miniUART for serial.

Details on how to use the resulting firmware, and especially how
to configure the media for boot, are provided in the Readme.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/RPi4/RPi4.dsc  | 637 
 Platform/RaspberryPi/RPi4/RPi4.fdf  | 432 +
 Platform/RaspberryPi/RPi4/Readme.md | 110 
 3 files changed, 1179 insertions(+)

diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc 
b/Platform/RaspberryPi/RPi4/RPi4.dsc
new file mode 100644
index ..3764d1b3d794
--- /dev/null
+++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
@@ -0,0 +1,637 @@
+# @file
+#
+#  Copyright (c) 2011 - 2019, ARM Limited. All rights reserved.
+#  Copyright (c) 2017 - 2018, Andrei Warkentin 
+#  Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved.
+#  Copyright (c) 2014, Linaro 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  = RPi4
+  PLATFORM_GUID  = a7eca3b4-21b0-4989-8c18-c08f3ae87837
+  PLATFORM_VERSION   = 1.0
+  DSC_SPECIFICATION  = 0x0001001A
+  OUTPUT_DIRECTORY   = Build/$(PLATFORM_NAME)
+  SUPPORTED_ARCHITECTURES= AARCH64
+  BUILD_TARGETS  = DEBUG|RELEASE|NOOPT
+  SKUID_IDENTIFIER   = DEFAULT
+  FLASH_DEFINITION   = 
Platform/RaspberryPi/$(PLATFORM_NAME)/$(PLATFORM_NAME).fdf
+
+  #
+  # Network definition
+  #
+  DEFINE NETWORK_TLS_ENABLE   = FALSE
+  DEFINE NETWORK_HTTP_BOOT_ENABLE = FALSE
+
+  #
+  # Defines for default states.  These can be changed on the command line.
+  # -D FLAG=VALUE
+  #
+  DEFINE SECURE_BOOT_ENABLE  = FALSE
+  DEFINE INCLUDE_TFTP_COMMAND= FALSE
+  DEFINE DEBUG_PRINT_ERROR_LEVEL = 0x804F
+
+
+#
+# Library Class section - list of all Library Classes needed by this Platform.
+#
+
+[LibraryClasses.common]
+!if $(TARGET) == RELEASE
+  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
+!else
+  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
+!endif
+  
DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
+
+  BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
+  SafeIntLib|MdePkg/Library/BaseSafeIntLib/BaseSafeIntLib.inf
+  BmpSupportLib|MdeModulePkg/Library/BaseBmpSupportLib/BaseBmpSupportLib.inf
+  
SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
+  
PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf
+  
ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseReportStatusCodeLibNull.inf
+  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
+  
PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
+  PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
+  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
+  
UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf
+  CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
+
+  UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
+  HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
+  
UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
+  DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
+  
UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
+  
DxeServicesTableLib|MdePkg/Library/DxeServicesTableLib/DxeServicesTableLib.inf
+  DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
+  
UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
+  
UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf
+  HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
+  
UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
+  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
+
+  UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
+  
OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
+
+  #
+  # Ramdisk Requirements
+  #
+  FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplore

[edk2-devel] [edk2-platforms][PATCH 3/5] Platform/RPi4: Add initial ACPI tables

[Pete Batard]

From: Samer El-Haj-Mahmoud 

For this initial commit, we duplicate the RPi3 ones.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.h   |  76 +++
 Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.inf |  40 ++
 Platform/RaspberryPi/RPi4/AcpiTables/Csrt.aslc  | 326 +
 Platform/RaspberryPi/RPi4/AcpiTables/Dbg2.aslc  |  28 ++
 Platform/RaspberryPi/RPi4/AcpiTables/Dsdt.asl   | 505 
 Platform/RaspberryPi/RPi4/AcpiTables/Fadt.aslc  |  46 ++
 Platform/RaspberryPi/RPi4/AcpiTables/Gtdt.aslc  |  27 ++
 Platform/RaspberryPi/RPi4/AcpiTables/Madt.aslc  |  56 +++
 Platform/RaspberryPi/RPi4/AcpiTables/Pep.asl|  89 
 Platform/RaspberryPi/RPi4/AcpiTables/Pep.c  |  78 +++
 Platform/RaspberryPi/RPi4/AcpiTables/Pep.h  | 120 +
 Platform/RaspberryPi/RPi4/AcpiTables/Rhpx.asl   | 195 
 Platform/RaspberryPi/RPi4/AcpiTables/Sdhc.asl   |  99 
 Platform/RaspberryPi/RPi4/AcpiTables/Spcr.asl   |  47 ++
 Platform/RaspberryPi/RPi4/AcpiTables/Uart.asl   | 152 ++
 15 files changed, 1884 insertions(+)

diff --git a/Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.h 
b/Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.h
new file mode 100644
index ..958af026c8a3
--- /dev/null
+++ b/Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.h
@@ -0,0 +1,76 @@
+/** @file
+ *
+ *  RPi3 defines for constructing ACPI tables
+ *
+ *  Copyright (c) 2018, Andrei Warkentin 
+ *  Copyright (c) Microsoft Corporation. All rights reserved.
+ *
+ *  SPDX-License-Identifier: BSD-2-Clause-Patent
+ *
+ **/
+
+#ifndef __ACPITABLES_H__
+#define __ACPITABLES_H__
+
+#include 
+
+#define EFI_ACPI_OEM_ID   {'M','C','R','S','F','T'} // 
OEMID 6 bytes long
+#define EFI_ACPI_OEM_TABLE_ID SIGNATURE_64 
('R','P','I','3','E','D','K','2') // OEM table id 8 bytes long
+#define EFI_ACPI_OEM_REVISION 0x02000820
+#define EFI_ACPI_CREATOR_ID   SIGNATURE_32 ('R','P','I','3')
+#define EFI_ACPI_CREATOR_REVISION 0x0097
+
+#define EFI_ACPI_VENDOR_IDSIGNATURE_32 ('M','S','F','T')
+#define EFI_ACPI_CSRT_REVISION0x0005
+#define EFI_ACPI_CSRT_DEVICE_ID_DMA   0x0009 // Fixed id
+#define EFI_ACPI_CSRT_RESOURCE_ID_IN_DMA_GRP  0x0 // Count up from 0
+
+#define RPI3_DMA_CHANNEL_COUNT10 // All 10 DMA channels are 
listed, including the reserved ones
+#define RPI3_DMA_USED_CHANNEL_COUNT   5  // Use 5 DMA channels
+
+#define EFI_ACPI_5_0_CSRT_REVISION0x
+
+typedef enum
+{
+  EFI_ACPI_CSRT_RESOURCE_TYPE_RESERVED,   // 0
+  EFI_ACPI_CSRT_RESOURCE_TYPE_INTERRUPT,  // 1
+  EFI_ACPI_CSRT_RESOURCE_TYPE_TIMER,  // 2
+  EFI_ACPI_CSRT_RESOURCE_TYPE_DMA,// 3
+  EFI_ACPI_CSRT_RESOURCE_TYPE_CACHE,  // 4
+}
+CSRT_RESOURCE_TYPE;
+
+typedef enum
+{
+  EFI_ACPI_CSRT_RESOURCE_SUBTYPE_DMA_CHANNEL, // 0
+  EFI_ACPI_CSRT_RESOURCE_SUBTYPE_DMA_CONTROLLER   // 1
+}
+CSRT_DMA_SUBTYPE;
+
+//
+// CSRT Resource Group header 24 bytes long
+//
+typedef struct
+{
+  UINT32 Length;  // Length
+  UINT32 VendorID;// 4 bytes
+  UINT32 SubVendorId; // 4 bytes
+  UINT16 DeviceId;// 2 bytes
+  UINT16 SubdeviceId; // 2 bytes
+  UINT16 Revision;// 2 bytes
+  UINT16 Reserved;// 2 bytes
+  UINT32 SharedInfoLength;// 4 bytes
+} EFI_ACPI_5_0_CSRT_RESOURCE_GROUP_HEADER;
+
+//
+// CSRT Resource Descriptor 12 bytes total
+//
+typedef struct
+{
+  UINT32 Length;  // 4 bytes
+  UINT16 ResourceType;// 2 bytes
+  UINT16 ResourceSubType; // 2 bytes
+  UINT32 UID; // 4 bytes
+} EFI_ACPI_5_0_CSRT_RESOURCE_DESCRIPTOR_HEADER;
+
+#endif // __ACPITABLES_H__
diff --git a/Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.inf 
b/Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.inf
new file mode 100644
index ..7ef41e79ad46
--- /dev/null
+++ b/Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.inf
@@ -0,0 +1,40 @@
+#/** @file
+#
+#  ACPI table data and ASL sources required to boot the platform.
+#
+#  Copyright (c) 2017, Andrey Warkentin 
+#  Copyright (c) Microsoft Corporation. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#**/
+
+[Defines]
+  INF_VERSION= 0x0001001A
+  BASE_NAME  = AcpiTables
+  FILE_GUID  = 7E374E25-8E01-4FEE-87F2-390C23C606CD
+  MODULE_TYPE= USER_DEFINED
+  VERSION_STRING = 1

[edk2-devel] [edk2-platforms][PATCH 4/5] Platform/RPi4: Update ACPI tables for the new platform

[Pete Batard]

From: Andrei Warkentin 

Update CSRT, DSDT, GTDT, MADT, SDHC and serial tables for the new
base addresses and switch ACPI to GIC.

We use ACPI 5.1 for MADT because older versions of the Linux kernel
can be finicky when it comes to checking the size of the GICC entries
the table: depending on the FADT version (either 5, or 6 or later),
the size must be exactly 76 or 80 bytes, respectively. However, using
the ACPI 6.0 or 6.1 GICC macros results in 80 byte entries, which
triggers a mismatch error since the FADT we are exposing is 5.1.

Since GICv2 doesn't care about any of the fields that were added
after ACPI 5.1, we can simply use that version to keep Linux happy.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.h   |  26 -
 Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.inf |  12 ++-
 Platform/RaspberryPi/RPi4/AcpiTables/Csrt.aslc  |  25 ++---
 Platform/RaspberryPi/RPi4/AcpiTables/Dbg2.aslc  |   2 +-
 Platform/RaspberryPi/RPi4/AcpiTables/Dsdt.asl   |  40 
 Platform/RaspberryPi/RPi4/AcpiTables/Gtdt.aslc  |  69 +
 Platform/RaspberryPi/RPi4/AcpiTables/Madt.aslc  | 102 +++-
 Platform/RaspberryPi/RPi4/AcpiTables/Pep.asl|   5 +-
 Platform/RaspberryPi/RPi4/AcpiTables/Pep.c  |   7 +-
 Platform/RaspberryPi/RPi4/AcpiTables/Pep.h  |   7 +-
 Platform/RaspberryPi/RPi4/AcpiTables/Sdhc.asl   |   4 +-
 Platform/RaspberryPi/RPi4/AcpiTables/Spcr.asl   |  15 +--
 Platform/RaspberryPi/RPi4/AcpiTables/Uart.asl   |  12 +--
 13 files changed, 197 insertions(+), 129 deletions(-)

diff --git a/Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.h 
b/Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.h
index 958af026c8a3..e61f3fa0bcfa 100644
--- a/Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.h
+++ b/Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.h
@@ -1,7 +1,8 @@
 /** @file
  *
- *  RPi3 defines for constructing ACPI tables
+ *  RPi4 defines for constructing ACPI tables
  *
+ *  Copyright (c) 2019, ARM Ltd. All rights reserved.
  *  Copyright (c) 2018, Andrei Warkentin 
  *  Copyright (c) Microsoft Corporation. All rights reserved.
  *
@@ -15,18 +16,33 @@
 #include 
 
 #define EFI_ACPI_OEM_ID   {'M','C','R','S','F','T'} // 
OEMID 6 bytes long
-#define EFI_ACPI_OEM_TABLE_ID SIGNATURE_64 
('R','P','I','3','E','D','K','2') // OEM table id 8 bytes long
+#define EFI_ACPI_OEM_TABLE_ID SIGNATURE_64 
('R','P','I','4','E','D','K','2') // OEM table id 8 bytes long
 #define EFI_ACPI_OEM_REVISION 0x02000820
-#define EFI_ACPI_CREATOR_ID   SIGNATURE_32 ('R','P','I','3')
+#define EFI_ACPI_CREATOR_ID   SIGNATURE_32 ('R','P','I','4')
 #define EFI_ACPI_CREATOR_REVISION 0x0097
 
 #define EFI_ACPI_VENDOR_IDSIGNATURE_32 ('M','S','F','T')
+
+// A macro to initialise the common header part of EFI ACPI tables as defined 
by
+// EFI_ACPI_DESCRIPTION_HEADER structure.
+#define ACPI_HEADER(Signature, Type, Revision) {  \
+Signature,  /* UINT32  Signature */   \
+sizeof (Type),  /* UINT32  Length */  \
+Revision,   /* UINT8   Revision */\
+0,  /* UINT8   Checksum */\
+EFI_ACPI_OEM_ID,/* UINT8   OemId[6] */\
+EFI_ACPI_OEM_TABLE_ID,  /* UINT64  OemTableId */  \
+EFI_ACPI_OEM_REVISION,  /* UINT32  OemRevision */ \
+EFI_ACPI_CREATOR_ID,/* UINT32  CreatorId */   \
+EFI_ACPI_CREATOR_REVISION   /* UINT32  CreatorRevision */ \
+  }
+
 #define EFI_ACPI_CSRT_REVISION0x0005
 #define EFI_ACPI_CSRT_DEVICE_ID_DMA   0x0009 // Fixed id
 #define EFI_ACPI_CSRT_RESOURCE_ID_IN_DMA_GRP  0x0 // Count up from 0
 
-#define RPI3_DMA_CHANNEL_COUNT10 // All 10 DMA channels are 
listed, including the reserved ones
-#define RPI3_DMA_USED_CHANNEL_COUNT   5  // Use 5 DMA channels
+#define RPI4_DMA_CHANNEL_COUNT10 // All 10 DMA channels are 
listed, including the reserved ones
+#define RPI4_DMA_USED_CHANNEL_COUNT   5  // Use 5 DMA channels
 
 #define EFI_ACPI_5_0_CSRT_REVISION0x
 
diff --git a/Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.inf 
b/Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.inf
index 7ef41e79ad46..50c9f7694d84 100644
--- a/Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.inf
+++ b/Platform/RaspberryPi/RPi4/AcpiTables/AcpiTables.inf
@@ -2,6 +2,7 @@
 #
 #  ACPI table data and ASL sources required to boot the platform.
 #
+#  Copyright (c) 2019, ARM Limited. All rights reserved.
 #  Copyright (c) 2017, Andrey Warkentin 
 #  Copyright (c) Microsoft Corporation. All rights reserved.
 #
@@ -33,8 +34,17 @@ [Sources]
   Spcr.asl
 
 [Packages]
-  MdePkg/MdePkg.dec
+  ArmPkg/ArmPkg.dec
+  ArmPlatf

[edk2-devel] [edk2-platforms][PATCH 1/5] Platform/RPi: Fix overlap of SoC registers and RAM

[Pete Batard]

From: Ard Biesheuvel 

Having RAM and SoC register regions overlap is problematic for MMIO,
since, at the very least, we don't want these regions to be declared
as cacheable.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c | 36 
+---
 1 file changed, 23 insertions(+), 13 deletions(-)

diff --git a/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c 
b/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
index cc761bea1307..781cf78b83d3 100644
--- a/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
+++ b/Platform/RaspberryPi/Library/PlatformLib/RaspberryPiMem.c
@@ -60,7 +60,7 @@ ArmPlatformGetVirtualMemoryMap (
 {
   UINTN Index = 0;
   UINTN GpuIndex;
-  INT64 ExtendedMemorySize;
+  INT64 SystemMemorySize;
   ARM_MEMORY_REGION_DESCRIPTOR  *VirtualMemoryTable;
 
   // Early output of the info we got from VideoCore can prove valuable.
@@ -120,21 +120,21 @@ ArmPlatformGetVirtualMemoryMap (
   VirtualMemoryInfo[Index].Type = RPI_MEM_RESERVED_REGION;
   VirtualMemoryInfo[Index++].Name   = L"GPU Reserved";
 
-  // Compute the amount of extended RAM available on this platform
-  ExtendedMemorySize = SIZE_256MB;
-  ExtendedMemorySize <<= (mBoardRevision >> 20) & 0x07;
-  ExtendedMemorySize -= SIZE_1GB;
-  if (ExtendedMemorySize > 0) {
-VirtualMemoryTable[Index].PhysicalBase  = FixedPcdGet64 
(PcdExtendedMemoryBase);
-VirtualMemoryTable[Index].VirtualBase   = 
VirtualMemoryTable[Index].PhysicalBase;
-VirtualMemoryTable[Index].Length= ExtendedMemorySize;
-VirtualMemoryTable[Index].Attributes= 
ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
-VirtualMemoryInfo[Index].Type   = RPI_MEM_BASIC_REGION;
-VirtualMemoryInfo[Index++].Name = L"Extended System RAM";
-  }
+  // Compute the total RAM size available on this platform
+  SystemMemorySize = SIZE_256MB;
+  SystemMemorySize <<= (mBoardRevision >> 20) & 0x07;
+
+  //
+  // Ensure that what we declare as System Memory doesn't overlap with the
+  // Bcm2836 SoC registers. This can be achieved through a MIN () with the
+  // base address since SystemMemoryBase is 0 (we assert if it isn't).
+  //
+  SystemMemorySize = MIN(SystemMemorySize, BCM2836_SOC_REGISTERS);
 
   // Extended SoC registers (PCIe, genet, ...)
   if (BCM2711_SOC_REGISTERS > 0) {
+// Same overlap protection as above for the Bcm2711 SoC registers
+SystemMemorySize= MIN(SystemMemorySize, 
BCM2711_SOC_REGISTERS);
 VirtualMemoryTable[Index].PhysicalBase  = BCM2711_SOC_REGISTERS;
 VirtualMemoryTable[Index].VirtualBase   = 
VirtualMemoryTable[Index].PhysicalBase;
 VirtualMemoryTable[Index].Length= BCM2711_SOC_REGISTER_LENGTH;
@@ -155,6 +155,16 @@ ArmPlatformGetVirtualMemoryMap (
   VirtualMemoryInfo[Index].Type = RPI_MEM_RESERVED_REGION;
   VirtualMemoryInfo[Index++].Name   = L"SoC Reserved (283x)";
 
+  // If we have RAM above the 1 GB mark, declare it
+  if (SystemMemorySize - SIZE_1GB > 0) {
+VirtualMemoryTable[Index].PhysicalBase  = FixedPcdGet64 
(PcdExtendedMemoryBase);
+VirtualMemoryTable[Index].VirtualBase   = 
VirtualMemoryTable[Index].PhysicalBase;
+VirtualMemoryTable[Index].Length= SystemMemorySize - SIZE_1GB;
+VirtualMemoryTable[Index].Attributes= 
ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
+VirtualMemoryInfo[Index].Type   = RPI_MEM_BASIC_REGION;
+VirtualMemoryInfo[Index++].Name = L"Extended System RAM";
+  }
+
   // End of Table
   VirtualMemoryTable[Index].PhysicalBase= 0;
   VirtualMemoryTable[Index].VirtualBase = 0;
-- 
2.21.0.windows.1


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

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

[edk2-devel] [edk2-non-osi][PATCH 2/2] Platforms/RPi4: Add Trusted Firmware binaries

[Pete Batard]

Similar to what is the case with the Raspberry Pi 3, the Raspberry Pi
4 UEFI firmware requires the provision of a Trusted Firmware binary
(TF-A).

The binary is built for a dtb base address of 0x0002 and a UEFI
payload base address of 0x0003.

Binaries are built using a custom version of TF-A (the source of which
is documented in the Readme), since the official repository is missing
a fix to get proper baudrate when using a recent version of start4.elf,
as we as the ability to switch between PL011 and mini UART. We are
currently working with TF-A to upstream both these fixes so that we can
switch to binaries built from official source at a later date.

In order to provide the ability to switch serial I/O controllers, a
feature we will be adding to the RPi4 UEFI Firmware, and not lose TF-A
output, two binaries are provided, one for mini UART output and one for
PL011 output.

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/RPi4/TrustedFirmware/License.txt   |  26 

 Platform/RaspberryPi/RPi4/TrustedFirmware/Readme.md |  12 +
 Platform/RaspberryPi/RPi4/TrustedFirmware/bl31_miniuart.bin | Bin 0 -> 41072 
bytes
 Platform/RaspberryPi/RPi4/TrustedFirmware/bl31_pl011.bin| Bin 0 -> 41072 
bytes
 4 files changed, 38 insertions(+)

diff --git a/Platform/RaspberryPi/RPi4/TrustedFirmware/License.txt 
b/Platform/RaspberryPi/RPi4/TrustedFirmware/License.txt
new file mode 100644
index ..48429979fec2
--- /dev/null
+++ b/Platform/RaspberryPi/RPi4/TrustedFirmware/License.txt
@@ -0,0 +1,26 @@
+Copyright (c) 2013-2019, ARM Limited and Contributors. All rights reserved.
+
+Redistribution and use in source and binary forms, with or without 
modification,
+are permitted provided that the following conditions are met:
+
+* Redistributions of source code must retain the above copyright notice, this
+  list of conditions and the following disclaimer.
+
+* Redistributions in binary form must reproduce the above copyright notice, 
this
+  list of conditions and the following disclaimer in the documentation and/or
+  other materials provided with the distribution.
+
+* Neither the name of ARM nor the names of its contributors may be used to
+  endorse or promote products derived from this software without specific prior
+  written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE 
FOR
+ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
diff --git a/Platform/RaspberryPi/RPi4/TrustedFirmware/Readme.md 
b/Platform/RaspberryPi/RPi4/TrustedFirmware/Readme.md
new file mode 100644
index ..7f1749dfc3a0
--- /dev/null
+++ b/Platform/RaspberryPi/RPi4/TrustedFirmware/Readme.md
@@ -0,0 +1,12 @@
+ARM Trusted Firmware for Raspberry Pi 4
+===
+
+The `bl31_#.bin` TF-A binaries found in this repository were built on a 
Debian 10.2 system
+from https://github.com/pbatard/arm-trusted-firmware/tree/pi4 (pi4 branch) 
using the command:
+
+```
+make PLAT=rpi4 RPI3_PRELOADED_DTB_BASE=0x2 PRELOADED_BL33_BASE=0x3 
SUPPORT_VFP=1 [RPI3_USE_PL011_UART=1] DEBUG=0 all
+```
+
+The only difference between these firmwares is that the 
`RPI3_USE_PL011_UART=1` option was added
+to build `bl31_pl011.bin` so that it uses PL011 for serial output rather than 
the "mini UART".
diff --git a/Platform/RaspberryPi/RPi4/TrustedFirmware/bl31_miniuart.bin 
b/Platform/RaspberryPi/RPi4/TrustedFirmware/bl31_miniuart.bin
new file mode 100644
index 
..e53aa0ef40fd2a8a66fee22439de2860813aa42f
GIT binary patch
literal 41072
zcmeHw3wTuJng4svnOsOBl$(ewP)2dtoB-Waf2`H#l3~B4%y3GtB3Iw?%(IQea
z0jjp??lKTd7v0T(+A`zrmPKgIZo34$)Rt}+k`256-kcEcaa#x~83pqH{k}6N8PKk7
zclYu6Kbt%r&N<)Z{oe0=-|xMB-x#NyMvNBx%Z_Cqxb1t
zX}3i7i4-3TU29}Ymt8(5PueTBjop%YZLf$HaoS&sa=AXxEm@OMzNOpD3=Nt&crHTO
zW0QJ^=NTvubX%-vw+ub
zxN*mI_)`;AJCy4|^xxx-&Q;}0Q63OE5^sOR?X%l|1?2}U>5TziE^x@hH4#@nuBee4
z=`->o$Bl`Rej`6JZJe~v!zEvJW%}2-@PGeF=^ml_CSxh%=b)}QG3k2!G*HvLHEkU
zve9-W%glH?mbp~l^UIRYFKd2at4L;Ww9P1dr|j(g2g3b^<~eIf@MXx=FNcS>mq?(x
z&oDe^??1TPYd%}3OG#SPa7BJIJeO&p
zoTltai<>q|R)?O`P^U=^>-qd_!t)eeYECV#48N0O#m?UU>~7-JXXJWx31mkhEA8n2
z6!7^y#$x&LXSJECJX^B%q5Q3QIoemNa<63VMfn>S;Knt03TyD4FYDnvF@tj!l(egtsM_fF1k(q$%bS^#*gOB`cGyv%MdouuJ~a5=vF^;i
z4$`t|qY=C|llnf??Ms%}J$%lVPG7Rs+46uMZYdPdNM@q0(_)+P5_9k;UJ}^a9eVX|
z2mc*oMu&$_P_Gb

[edk2-devel] [edk2-non-osi][PATCH 0/2] Add prerequisite binary files for RPi4 platform

[Pete Batard]

This series of patches adds the binaries we need available to introduce
Raspberry Pi 4 support.

Similar to the Pi 3, we must have TF-A and Device Tree binaries we can embed.

Pete Batard (2):
  Platforms/RPi4: Add Device Tree
  Platforms/RPi4: Add Trusted Firmware binaries

 Platform/RaspberryPi/RPi4/DeviceTree/License.txt| 340 

 Platform/RaspberryPi/RPi4/DeviceTree/Readme.md  |  13 +
 Platform/RaspberryPi/RPi4/DeviceTree/bcm2711-rpi-4-b.dtb| Bin 0 -> 40697 
bytes
 Platform/RaspberryPi/RPi4/TrustedFirmware/License.txt   |  26 ++
 Platform/RaspberryPi/RPi4/TrustedFirmware/Readme.md |  12 +
 Platform/RaspberryPi/RPi4/TrustedFirmware/bl31_miniuart.bin | Bin 0 -> 41072 
bytes
 Platform/RaspberryPi/RPi4/TrustedFirmware/bl31_pl011.bin| Bin 0 -> 41072 
bytes
 7 files changed, 391 insertions(+)
 create mode 100644 Platform/RaspberryPi/RPi4/DeviceTree/License.txt
 create mode 100644 Platform/RaspberryPi/RPi4/DeviceTree/Readme.md
 create mode 100644 Platform/RaspberryPi/RPi4/DeviceTree/bcm2711-rpi-4-b.dtb
 create mode 100644 Platform/RaspberryPi/RPi4/TrustedFirmware/License.txt
 create mode 100644 Platform/RaspberryPi/RPi4/TrustedFirmware/Readme.md
 create mode 100644 Platform/RaspberryPi/RPi4/TrustedFirmware/bl31_miniuart.bin
 create mode 100644 Platform/RaspberryPi/RPi4/TrustedFirmware/bl31_pl011.bin

-- 
2.21.0.windows.1


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

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

Re: [edk2-devel] [PATCH v1 1/1] BaseTools: Build ASL files before C files

[PierreGondois]

Hello Bob and Liming,
I am coming back to you after re-reading Bob's answer:
> I meet another problem related to .asl file. In one of platforms build 
> process, there is a step which need to compile a .asl file a .h file firstly 
> and that .h file will be included by a module’s source code.
> That step cannot be handled in edk2 build since the compilation command use 
> different build option, so it’s done in a pre-build script. I want to make 
> edk2 build be able to handle such case. So together with your case,  I think 
> we may need a solution that can do:
> 1.   Create a module which contains the .asl file and the build option to 
> compile that .asl file.
> 2.   Find a way to describe the dependency relation between the module 
> contains .asl and the corresponding module contains .c file

I split my module into one module containing the .asl file, and a second module 
containing .c source files. However I could not find a way to describe a 
dependency between the two modules (as suggested in the second step).
This part of Bob's answer makes me think it's not possible using current edk2 
build system:
> That step cannot be handled in edk2 build since the compilation command use 
> different build option, so it’s done in a pre-build script.

I will have to reproduce the solution to multiple folders and for multiple 
platforms. Using a pre-build script would not be a scalable solution.
I would need to create a dependency between file extensions (or between modules 
which are edk2 library classes) using the build system.
Would you have an idea of how to do it, or if this is currently not possible 
and this implies modification in the build system, is there a way I could help?

Regards,
Pierre

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

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

[edk2-devel] [edk2-non-osi][PATCH 1/2] Platforms/RPi4: Add Device Tree

[Pete Batard]

Similar to what is the case with the Raspberry Pi 3, the Raspberry Pi 4
UEFI firmware requires a binary Device Tree for the Broadcom 2711 SoC.

This patch adds the most up to date Device Tree binary, as published
with commit 601d36df3aa541560e4cf9b571105d20db2b4b7c from
https://github.com/raspberrypi/firmware/tree/master/boot

Signed-off-by: Pete Batard 
---
 Platform/RaspberryPi/RPi4/DeviceTree/License.txt | 340 

 Platform/RaspberryPi/RPi4/DeviceTree/Readme.md   |  13 +
 Platform/RaspberryPi/RPi4/DeviceTree/bcm2711-rpi-4-b.dtb | Bin 0 -> 40697 bytes
 3 files changed, 353 insertions(+)

diff --git a/Platform/RaspberryPi/RPi4/DeviceTree/License.txt 
b/Platform/RaspberryPi/RPi4/DeviceTree/License.txt
new file mode 100644
index ..1603937dad82
--- /dev/null
+++ b/Platform/RaspberryPi/RPi4/DeviceTree/License.txt
@@ -0,0 +1,340 @@
+GNU GENERAL PUBLIC LICENSE
+   Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+   51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users.  This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it.  (Some other Free Software Foundation software is covered by
+the GNU Library General Public License instead.)  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+  We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+  Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software.  If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary.  To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+GNU GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License.  The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language.  (Hereinafter, translation is included without limitation in
+the term "modification".)  Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.

[edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V6] MdePkg/Protocols: New PCI Express Platform Protocol, EFI encodings

[Javeed, Ashraf]

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

Two interfaces added to PCI Express Platform Protocol:-
(1) GetDevicePolicy() -> to retrieve device-specific platform policies
(2) NotifyDeviceState -> to notify platform about device PCI Express
configuration state
PCI Express Override Protocol is made alias to PCI Express Platform
Protocol.
EFI encodings introduced for the following PCI Express features, are:
1.  Maximum Payload Size (MPS)
2.  Maximum Read Request Size (MRRS)
3.  Extended Tag
4.  Relax Order Enable
5.  No Snoop Enable
6.  ASPM support
7.  Common Clock Configuration
8.  Extended SYNC
9.  Atomic Op
10. LTR Enable
11. PTM support
12. CTO support
13. CPM
14. L1 PM Substates

New source files with unique definitions are:
MdePkg/Include/Protocol/PciExpressPlatform.h,
MdePkg/Include/Protocol/PciExpressOverride.h

Signed-off-by: Ashraf Javeed 
Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Ray Ni 
---

In V6: renamed the protocol definition source files, remove PCD comments,
and renamed NotifyDeviceConfiguration -> NotifyDeviceState

In V5: Revised ECR to define new PCI Platform Protocol to support the
PCI Express capability features:-
EFI_PCI_EXPRESS_PLATFORM_PROTOCOL, EFI_PCI_EXPRESS_OVERRIDE_PROTOCOL.
Added new interface -> NotifyDeviceConfiguration
Added new EFI encodings / data types for PCIe features:-
CPM, L1 PM substates.
Enhance the definition of the PCIe feature AtomicOp to support additional
attribute - Egress blocking of the port.

In V4: Redefinition of the existing interfaces in the EFI_PCI_PLATFORM_-
PROTOCOL2, to avoid type casting and to avoid further future change

In V3: License update in the header sections of source files

In V2: Correction made to header sections of source files
---
 MdePkg/Include/Protocol/PciExpressOverride.h |  37 
+
 MdePkg/Include/Protocol/PciExpressPlatform.h | 547 
+++
 MdePkg/Include/Protocol/PciOverride2.h   |  37 
-
 MdePkg/Include/Protocol/PciPlatform2.h   | 524 

 MdePkg/MdePkg.dec|   8 
 5 files changed, 588 insertions(+), 565 deletions(-)

diff --git a/MdePkg/Include/Protocol/PciExpressOverride.h 
b/MdePkg/Include/Protocol/PciExpressOverride.h
new file mode 100644
index 000..aab9375
--- /dev/null
+++ b/MdePkg/Include/Protocol/PciExpressOverride.h
@@ -0,0 +1,37 @@
+/** @file
+  This file declares EFI PCI Express Override protocol which provides the 
interface between
+  the PCI bus driver/PCI Host Bridge Resource Allocation driver and an 
implementation's
+  driver to describe the unique features of a platform.
+  This protocol is optional.
+
+Copyright (c) 2019, Intel Corporation. All rights reserved.
+SPDX-License-Identifier: BSD-2-Clause-Patent
+
+
+**/
+
+#ifndef _PCI_EXPRESS_OVERRIDE_H_
+#define _PCI_EXPRESS_OVERRIDE_H_
+
+///
+/// EFI_PCI_EXPRESS_OVERRIDE_PROTOCOL has the same structure as of 
EFI_PCI_EXPRESS_PLATFORM_PROTOCOL
+///
+#include "PciExpressPlatform.h"
+
+///
+/// Global ID for the  EFI_PCI_EXPRESS_OVERRIDE_PROTOCOL
+///
+#define EFI_PCI_EXPRESS_OVERRIDE_GUID \
+  { \
+0xb9d5ea1, 0x66cb, 0x4546, {0xb0, 0xbb, 0x5c, 0x6d, 0xae, 0xd9, 0x42, 
0x47} \
+  }
+
+///
+/// Declaration for EFI_PCI_EXPRESS_OVERRIDE_PROTOCOL
+///
+typedef  EFI_PCI_EXPRESS_PLATFORM_PROTOCOL  EFI_PCI_EXPRESS_OVERRIDE_PROTOCOL;
+
+
+extern EFI_GUID   gEfiPciExpressOverrideProtocolGuid;
+
+#endif
diff --git a/MdePkg/Include/Protocol/PciExpressPlatform.h 
b/MdePkg/Include/Protocol/PciExpressPlatform.h
new file mode 100644
index 000..d8f9647
--- /dev/null
+++ b/MdePkg/Include/Protocol/PciExpressPlatform.h
@@ -0,0 +1,547 @@
+/** @file
+  This file declares EFI PCI Express Platform Protocol that provide the 
interface between
+  the PCI bus driver/PCI Host Bridge Resource Allocation driver and a 
platform-specific
+  driver to desc

Re: [edk2-devel] [RFC PATCH 2/2] MdeModulePkg/BdsDxe: allow consoles on drivers loaded via Driver####

[Ard Biesheuvel]

On Mon, 9 Dec 2019 at 09:42, Ard Biesheuvel  wrote:
>
> On Mon, 9 Dec 2019 at 03:12, Ni, Ray  wrote:
> >
> > > Exactly. This flow is identical to how option ROMs are processed if
> > > they are discovered before EndOfDxe signalling completes (which is why
> > > the Juno platform was broken without the call to
> > > EfiBootManagerDispatchDeferredImages() in
> > > PlatformBootManagerBeforeConsole())
> > >
> >
> > Ard,
> > I checked ArmPkg's PlatformBootManagerLib and found it doesn't
> > call *DispatchDeferredImages() after signaling EndOfDxe.
> >
>
> It does. We just added this in 0f9395d7c5cc6ae2beaa2d87008fe158d04a8069
>
> > The deferred image dispatch mechanism assumes the platform
> > needs to call the *DispatchDeferredImages() after signaling EndOfDxe.
> >
>
> Indeed.
>
> > I don't understand why the deferred image can be loaded with your patch.
> > They are still deferred because the loading time is before EndOfDxe.
> >
>
> Yes, but because PlatformBootManagerBeforeConsole () does all of this,
> the only way to get Driver to work for consoles on GOP drivers, we
> need to move it before that call.

Any further comments on this patch?

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

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

Re: [edk2-devel] [edk2][PATCH 1/1] MdePkg/Include: Add DCC and BCM2835 SPCR UART types

[Ard Biesheuvel]

(add MdePkg maintainers)

On Tue, 10 Dec 2019 at 19:23, Pete Batard  wrote:
>
> As per the Microsoft Debug Port Table 2 (DBG2) documentation, that
> can be found online, we are missing 2 serial interface types for
> Arm DCC and Bcm2835 (the latter being used with the Raspberry Pi).
>
> These same types are present in DebugPort2Table.h so add them to
> SerialPortConsoleRedirectionTable.h too.
>
> Note that we followed the same idiosyncrasies as DebugPort2Table
> for naming these new macros.
>
> Signed-off-by: Pete Batard 

Acked-by: Ard Biesheuvel 

> ---
>  MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h | 10 
> ++
>  1 file changed, 10 insertions(+)
>
> diff --git 
> a/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h 
> b/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> index b069fb2be97f..2066c7895e59 100644
> --- a/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> +++ b/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> @@ -90,6 +90,16 @@ typedef struct {
>  ///
>  #define 
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_ARM_SBSA_GENERIC_UART
>  0x0e
>
> +///
> +/// ARM DCC
> +///
> +#define EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_DCC
>0x0f
> +
> +///
> +/// BCM2835 UART
> +///
> +#define 
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_BCM2835_UART
>   0x10
> +
>  //
>  // Interrupt Type
>  //
> --
> 2.21.0.windows.1
>

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

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

[edk2-devel] [PATCH v2] Maintainers.txt: Update email address and role

[Maciej Rabeda]

Created new email account that will not append legal disclaimers to
my responses/patches.

Switching to NetworkPkg maintainer.

Cc: Jiaxin Wu 
Cc: Siyuan Fu 
Signed-off-by: Maciej Rabeda 
---
 Maintainers.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index d6e8d5d5c797..146d8aca93f0 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -378,8 +378,8 @@ NetworkPkg
 F: NetworkPkg/
 W: https://github.com/tianocore/tianocore.github.io/wiki/NetworkPkg
 M: Jiaxin Wu 
+M: Maciej Rabeda 
 R: Siyuan Fu 
-R: Maciej Rabeda 
 
 OvmfPkg
 F: OvmfPkg/
-- 
2.24.0.windows.2


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

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

Re: [edk2-discuss] [edk2-devel] [PATCH] Support skipping automatic BM enumeration

[Wang, Sunny (HPS SW)]

Hi all, 

Since I can't attend the design meeting (EMEA), I would like to add some use 
cases and a suggestion for your guys' reference before this topic being 
discussed:

We had similar needs (use cases) as Ashish like the following, so making this 
code change would be definitely good for system vendors like us. 
- Disabling a specific boot option like a PXE boot option for a 
specific NIC port.
- Hiding a partition that is used for special purpose rather than 
booting.   

If we don't have a strong reason to prevent creating a platform hook function 
(solution 5), I will prefer to use it because it is the simplest solution and 
can be easily extended and maintained. Also, solution 5 is our current 
implementation. We can even contribute our implementation to EDK2 if you guys 
need it. Moreover, if we finally choose solution 5, I will prefer to create a 
new platform library instead of adding a new function into the 
PlatformBootManagerLib, and let this new platform library only be called by 
UefiBootManagerLib. This would avoid a potential circular dependency problem.

For solutions 1, 2, 3, and 4, if I understand them correctly, they all require 
making changes in the EfiBootManagerRefreshAllBootOption callers. UiApp may not 
be the only application to call EfiBootManagerRefreshAllBootOption, so this may 
cause additional maintenance effort. However, if we still need to choose a 
solution other than solution 5, can we make the change directly in 
EfiBootManagerRefreshAllBootOption instead of UiApp? 

By the way, if we still need to discuss this further at a meeting, I will be at 
the other design meeting (APAC).

Regards,
Sunny Wang

-Original Message-
From: disc...@edk2.groups.io [mailto:disc...@edk2.groups.io] On Behalf Of Jeff 
Brasen
Sent: Wednesday, December 11, 2019 4:46 AM
To: Ni, Ray ; devel@edk2.groups.io; Laszlo Ersek 
; af...@apple.com; disc...@edk2.groups.io
Cc: Ashish Singhal ; Wang, Jian J 
; Wu, Hao A ; Gao, Zhichao 
; Kinney, Michael D 
Subject: Re: [edk2-discuss] [edk2-devel] [PATCH] Support skipping automatic BM 
enumeration

Can we discuss this at the design meeting this week (12/12)?


Thanks,

Jeff


From: Jeff Brasen
Sent: Thursday, November 14, 2019 10:04 AM
To: Ni, Ray ; devel@edk2.groups.io ; 
Laszlo Ersek ; af...@apple.com 
Cc: Ashish Singhal ; Wang, Jian J 
; Wu, Hao A ; Gao, Zhichao 
; Kinney, Michael D 
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration


Yes, I think that would be good.



Summarizing everything in this thread



Problem: Platform needs to customize the boot options, this can be done for 
normal boot but the UiApp calls EfiBootManagerRefreshAllBootOption in a couple 
places.



Potential solutions:

1 - Define new PCD and event group if PCD is set true then signal event instead 
of calling EfiBootManagerRefreshAllBootOption in UiApp

2 - Add new function to boot manager library and replace call to 
EfiBootManagerRefreshAllBootOption in UiApp (need to coordinate rollout with 
updates to all platform.

3 - Add new protocol with new function, if supported call this otherwise call 
EfiBootManagerRefreshAllBootOption as is done now

4 - For 2/3 use  generic function so we don't need new APIs for future expansion

5 - Update EfiBootManagerRefreshAllBootOption to call platform specific 
function.



Thanks,
Jeff





From: Ni, Ray 
Sent: Wednesday, November 13, 2019 7:09 PM
To: devel@edk2.groups.io; Jeff Brasen ; Laszlo Ersek 
; af...@apple.com
Cc: Ashish Singhal ; Wang, Jian J 
; Wu, Hao A ; Gao, Zhichao 
; Kinney, Michael D 
Subject: RE: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Jeff,

I think it's a good topic that we could discuss in the open design meeting.

Are you ok to present the problem you have and discuss the potential solutions 
in that meeting?

https://github.com/tianocore/tianocore.github.io/wiki/Design-Meeting



Thanks,

Ray



From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> On Behalf Of Jeff Brasen
Sent: Thursday, November 14, 2019 2:43 AM
To: Ni, Ray mailto:ray...@intel.com>>; 
devel@edk2.groups.io; Laszlo Ersek 
mailto:ler...@redhat.com>>; 
af...@apple.com
Cc: Ashish Singhal mailto:ashishsin...@nvidia.com>>; 
Wang, Jian J mailto:jian.j.w...@intel.com>>; Wu, Hao A 
mailto:hao.a...@intel.com>>; Gao, Zhichao 
mailto:zhichao@intel.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: Re: [edk2-devel] [PATCH] Support skipping automatic BM enumeration



Thinking about this more I think we could do this with a PCD and a new group 
event without having to define any new function interfaces.



We could change UiApp and BootManagerMenuApp (and any others that are relevant) 
from



EfiBootManagerRefreshAllBootOption ();



to



if (FeaturePcdGet (PcdEventBasedRefreshAllBootOptionSupport) {

  EFI_EVENT Event;

  gBS->CreateEventEx ( 0

Re: [edk2-devel] [PATCH v2 103/105] .mailmap: Add an entry for Yonghong Zhu

[Zhu, Yonghong]

Reviewed-by: Yonghong Zhu 

Best Regards,
Zhu Yonghong

-Original Message-
From: Philippe Mathieu-Daude [mailto:phi...@redhat.com] 
Sent: Friday, December 6, 2019 7:27 PM
To: devel@edk2.groups.io
Cc: Philippe Mathieu-Daude ; Zhu, Yonghong 

Subject: [PATCH v2 103/105] .mailmap: Add an entry for Yonghong Zhu

We use .mailmap to display contributors email addresses in an uniform format.

Add an entry for Yonghong Zhu to have his name and email address displayed 
properly in the git history.

Cc: Yonghong Zhu 
Signed-off-by: Philippe Mathieu-Daude 
---
[Due to MTA restricting the recipient list to 100, I can not Cc all the  named 
developers in the cover. Therefore I'm adapting the explaination  from the 
cover in each patch]

This patch won't get merged if Yonghong Zhu doesn't give his approval, by 
replying to this patch with:
  Reviewed-by: Yonghong Zhu 

If you think this patch is inappropriate, you don't need to justify, reply with:
  NAcked-by: Yonghong Zhu  or simply:
  NACK

If your Firstname Lastname order is incorrect, tell me and I will fix it.

You can also ignore this mail, but I might resend it and keep bothering you.

Regards,

Phil.
---
 .mailmap | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/.mailmap b/.mailmap
index 34e9c09fc20c..dc0e59705f6c 100644
--- a/.mailmap
+++ b/.mailmap
@@ -194,3 +194,5 @@ Yao Jiewen  

 Yao JiewenYeh Greg  
GregX Yeh   Yingke Liu  

+Yonghong Zhu 
+Yonghong Zhu  
--
2.21.0


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

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