Re: [edk2-devel] [PATCH v2] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Samer El-Haj-Mahmoud]

Thank you all!

> -Original Message-
> From: Ard Biesheuvel 
> Sent: Tuesday, December 19, 2023 8:59 AM
> To: devel@edk2.groups.io; gaolim...@byosoft.com.cn
> Cc: quic_llind...@quicinc.com; ngomp...@gmail.com; Michael Kinney
> ; Laszlo Ersek ; Jeremy Linton
> ; Pete Batard ; Daniel P . Berrangé
> ; Gerd Hoffmann ; Samer El-Haj-
> Mahmoud 
> Subject: Re: [edk2-devel] [PATCH v2] MdeModulePkg/UefiBootManagerLib:
> Signal ReadyToBoot on platform recovery
>
> On Tue, 19 Dec 2023 at 14:00, gaoliming via groups.io
>  wrote:
> >
> > Yes. The latest spec has clarified this behavior. So, this change is OK. 
> > Reviewed-
> by: Liming Gao 
> >
>
> Merged as #5165
>
> Thanks all
>
> > > -邮件原件-
> > > 发件人: devel@edk2.groups.io  代表 Leif Lindholm
> > > 发送时间: 2023年12月19日 19:51
> > > 收件人: devel@edk2.groups.io; a...@kernel.org
> > > 抄送: ngomp...@gmail.com; Liming Gao (Byosoft address)
> > > ; Michael Kinney
> ;
> > > Laszlo Ersek ; Jeremy Linton ;
> > > Pete Batard ; Daniel P . Berrangé ;
> > > Gerd Hoffmann ; Samer El-Haj-Mahmoud
> > > 
> > > 主题: Re: [edk2-devel] [PATCH v2] MdeModulePkg/UefiBootManagerLib:
> > > Signal ReadyToBoot on platform recovery
> > >
> > > On Mon, Dec 18, 2023 at 22:55:21 +0100, Ard Biesheuvel wrote:
> > > > Hello all,
> > > >
> > > > Same question again. Could we please make some progress on this?
> > > >
> > > > Full thread here:
> > > >
> > > https://openfw.io/edk2-devel/20231031173700.647004-1-
> ngompa@fedorap
> > > roject.org/
> > > >
> > > > If nobody objects, I will assume that the change is acceptable and
> > > > merge it by the end of the week.
> > >
> > > I'm OK with this.
> > >
> > > The last comment from Liming in
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=2831
> > > was that the fix could be merged after "the next UEFI is published",
> > > which it was - in August 2022.
> > >
> > > Reviewed-by: Leif Lindholm 
> > >
> > > Regards,
> > >
> > > Leif
> > >
> > >
> > > > Thanks,
> > > > Ard.
> > > >
> > > >
> > > >
> > > > On Tue, 12 Dec 2023 at 09:11, Ard Biesheuvel  wrote:
> > > > >
> > > > > (cc Mike, Leif)
> > > > >
> > > > > On Thu, 7 Dec 2023 at 08:40, Ard Biesheuvel  wrote:
> > > > > >
> > > > > > (cc Liming)
> > > > > >
> > > > > > On Thu, 7 Dec 2023 at 05:48, Neal Gompa 
> > > wrote:
> > > > > > >
> > > > > > > On Fri, Nov 24, 2023 at 6:36 PM Neal Gompa
> 
> > > wrote:
> > > > > > > >
> > > > > > > > On Thu, Nov 2, 2023 at 6:35 AM Laszlo Ersek 
> > > wrote:
> > > > > > > > >
> > > > > > > > > On 10/31/23 23:27, Jeremy Linton wrote:
> > > > > > > > > > On 10/31/23 12:37, Neal Gompa via groups.io wrote:
> > > > > > > > > >> From: Neal Gompa 
> > > > > > > > > >>
> > > > > > > > > >> Currently, the ReadyToBoot event is only signaled when a
> formal
> > > Boot
> > > > > > > > > >> Manager option is executed (in BmBoot.c ->
> > > EfiBootManagerBoot ()).
> > > > > > > > > >>
> > > > > > > > > >> However, the introduction of Platform Recovery in UEFI 2.5
> > > makes it
> > > > > > > > > >> necessary to signal ReadyToBoot when a Platform Recovery
> > > boot loader
> > > > > > > > > >> runs because otherwise it may lead to the execution of a 
> > > > > > > > > >> boot
> > > loader
> > > > > > > > > >> that has similar requirements to a regular one that is not
> > > launched
> > > > > > > > > >> as a Boot Manager option.
> > > > > > > > > >>
> > > > > > > > > >> This is especially critical to ensuring that the graphical 
> > > > > > > > > >> console
> > > > > > > > > >> is actually usable during platform recovery, as s

Re: [edk2-devel] [PATCH v1 4/8] MdePkg/Rng: Add GUIDs to describe Rng algorithms

[Samer El-Haj-Mahmoud]

Hi Jiewen,

There is an open ECR for UEFI spec review: 
https://bugzilla.tianocore.org/show_bug.cgi?id=4441. These patches can wait on 
the list until the ECR is reviewed by UEFI Forum and the decision is documented 
in the BZ. If approved, then the code patches should be able to proceed.

Thanks,
--Samer



> -Original Message-
> From: Yao, Jiewen 
> Sent: Tuesday, May 9, 2023 9:46 AM
> To: Pierre Gondois ; devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ; Wang,
> Jian J ; Ard Biesheuvel ;
> Sami Mujawar ; Jose Marinho
> ; Samer El-Haj-Mahmoud  mahm...@arm.com>
> Subject: RE: [PATCH v1 4/8] MdePkg/Rng: Add GUIDs to describe Rng algorithms
>
> Is this defined in UEFI spec? or approved in future UEFI spec?
>
> > -Original Message-
> > From: pierre.gond...@arm.com 
> > Sent: Tuesday, May 9, 2023 3:41 PM
> > To: devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Gao, Liming
> > ; Liu, Zhiguang ; Yao,
> > Jiewen ; Wang, Jian J ; Ard
> > Biesheuvel ; Sami Mujawar
> > ; Jose Marinho ;
> > Samer El-Haj-Mahmoud 
> > Subject: [PATCH v1 4/8] MdePkg/Rng: Add GUIDs to describe Rng algorithms
> >
> > From: Pierre Gondois 
> >
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4441
> >
> > The EFI_RNG_PROTOCOL can rely on the RngLib. The RngLib has multiple
> > implementations, some of them are unsafe (e.g. BaseRngLibTimerLib).
> > To allow the RngDxe to detect when such implementation is used,
> > a GetRngGuid() function is added in a following patch.
> >
> > Prepare GetRngGuid() return values and add GUIDs describing
> > Rng algorithms:
> > - gEfiRngAlgorithmArmRndr
> > to describe a Rng algorithm accessed through Arm's RNDR instruction.
> > [1] states that the implementation of this algorithm should be
> > compliant to NIST SP900-80. The compliance is not guaranteed.
> > - gEfiRngAlgorithmUnSafe
> > to describe an unsafe implementation, cf. the BaseRngLibTimerLib.
> >
> > [1] Arm Architecture Reference Manual Armv8, for A-profile architecture
> > sK12.1 'Properties of the generated random number'
> >
> > Signed-off-by: Pierre Gondois 
> > ---
> >  MdePkg/Include/Protocol/Rng.h | 20 
> >  MdePkg/MdePkg.dec |  2 ++
> >  2 files changed, 22 insertions(+)
> >
> > diff --git a/MdePkg/Include/Protocol/Rng.h
> > b/MdePkg/Include/Protocol/Rng.h
> > index baf425587b3c..dfdaf36e41dc 100644
> > --- a/MdePkg/Include/Protocol/Rng.h
> > +++ b/MdePkg/Include/Protocol/Rng.h
> > @@ -67,6 +67,24 @@ typedef EFI_GUID EFI_RNG_ALGORITHM;
> >{ \
> >  0xe43176d7, 0xb6e8, 0x4827, {0xb7, 0x84, 0x7f, 0xfd, 0xc4, 0xb6, 0x85,
> > 0x61 } \
> >}
> > +///
> > +/// The Arm Architecture states the RNDR that the DRBG algorithm should
> > be compliant
> > +/// with NIST SP800-90A, while not mandating a particular algorithm, so as
> > to be
> > +/// inclusive of different geographies.
> > +///
> > +#define EFI_RNG_ALGORITHM_ARM_RNDR \
> > +  { \
> > +0x43d2fde3, 0x9d4e, 0x4d79,  {0x02, 0x96, 0xa8, 0x9b, 0xca, 0x78, 0x08,
> > 0x41} \
> > +  }
> > +///
> > +/// The implementation of a Random Number Generator might be unsafe,
> > when using
> > +/// a dummy implementation for instance. Allow identifying such
> > implementation
> > +/// with this GUID.
> > +///
> > +#define EFI_RNG_ALGORITHM_UNSAFE \
> > +  { \
> > +0x869f728c, 0x409d, 0x4ab4, {0xac, 0x03, 0x71, 0xd3, 0x09, 0xc1, 0xb3,
> > 0xf4 } \
> > +  }
> >
> >  /**
> >Returns information about the random number generation implementation.
> > @@ -146,5 +164,7 @@ extern EFI_GUID
> > gEfiRngAlgorithmSp80090Ctr256Guid;
> >  extern EFI_GUID  gEfiRngAlgorithmX9313DesGuid;
> >  extern EFI_GUID  gEfiRngAlgorithmX931AesGuid;
> >  extern EFI_GUID  gEfiRngAlgorithmRaw;
> > +extern EFI_GUID  gEfiRngAlgorithmArmRndr;
> > +extern EFI_GUID  gEfiRngAlgorithmUnSafe;
> >
> >  #endif
> > diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
> > index 0ecfad5795e4..754085eaa55b 100644
> > --- a/MdePkg/MdePkg.dec
> > +++ b/MdePkg/MdePkg.dec
> > @@ -633,6 +633,8 @@ [Guids]
> >gEfiRngAlgorithmX9313DesGuid   = { 0x63c4785a, 0xca34, 0x4012, {0xa3,
> > 0xc8, 0x0b, 0x6a, 0x32, 0x4f, 0x55, 0x46 }}
> >gEfiRngAlgorithmX931AesGuid= { 0xacd03321, 0x777e, 0x4d3d, {0xb1,
> > 0xc8, 0x20, 0xcf, 0xd8, 0x88, 0x20, 0xc9 }}
> >gEfiRngAlgorithmRaw= { 0xe43176d7, 0xb6e8, 0x4827, {0xb7,
&

Re: [edk2-devel] [PATCH v1 1/1] ShellPkg: UefiShellDebug1CommandsLib: Uefi Config Tables in Dmem.c

[Samer El-Haj-Mahmoud]

Looks good to me.

Reviewed-by Samer El-Haj-Mahmoud 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Gao,
> Zhichao via groups.io
> Sent: Thursday, February 16, 2023 4:18 AM
> To: Sunny Wang ; devel@edk2.groups.io; Sam
> Kaynor 
> Cc: Ni, Ray 
> Subject: Re: [edk2-devel] [PATCH v1 1/1] ShellPkg:
> UefiShellDebug1CommandsLib: Uefi Config Tables in Dmem.c
>
> Reviewed-by: Zhichao Gao 
>
> Thanks,
> Zhichao
>
> > -Original Message-
> > From: Sunny Wang 
> > Sent: Tuesday, February 14, 2023 11:57 PM
> > To: devel@edk2.groups.io; Sam Kaynor 
> > Cc: Ni, Ray ; Gao, Zhichao ;
> > Sunny Wang 
> > Subject: RE: [edk2-devel] [PATCH v1 1/1] ShellPkg:
> > UefiShellDebug1CommandsLib: Uefi Config Tables in Dmem.c
> >
> > Looks good to me. Thanks for working on this, Sam.
> > Just for others' information, I also had an offline discussion with Sam.
> > - This is change is based on UEFI 2.10 section 4.6. EFI Configuration 
> > Table
> &
> > Properties Table
> > https://uefi.org/specs/UEFI/2.10/04_EFI_System_Table.html#efi-
> > configuration-table-properties-table.
> > - The link of pull request is 
> > https://github.com/tianocore/edk2/pull/4038
> >
> > Reviewed-by: Sunny Wang 
> >
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Sam
> > Kaynor via groups.io
> > Sent: 07 February 2023 21:20
> > To: devel@edk2.groups.io
> > Cc: Sam Kaynor ; Ray Ni ;
> > Zhichao Gao 
> > Subject: [edk2-devel] [PATCH v1 1/1] ShellPkg:
> > UefiShellDebug1CommandsLib: Uefi Config Tables in Dmem.c
> >
> > Added entries for UEFI Config Tables not present in current Dmem output.
> >
> > Cc: Ray Ni 
> > Cc: Zhichao Gao 
> > Signed-off-by: Sam Kaynor 
> > ---
> >
> >
> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Commands
> > Lib.inf |  9 ++
> >  ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c 
> > | 89
> > ++--
> >
> >
> ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Commands
> > Lib.uni | 28 --
> >  3 files changed, 112 insertions(+), 14 deletions(-)
> >
> > diff --git
> >
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> > dsLib.inf
> >
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> > dsLib.inf
> > index 74ad5facf6b1..3741dac5d94c 100644
> > ---
> >
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> > dsLib.inf
> > +++
> >
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1Comman
> > d
> > +++ sLib.inf
> > @@ -121,6 +121,7 @@ [Protocols]
> >gEfiBlockIoProtocolGuid ## SOMETIMES_CONSUMES
> >
> >gEfiSimplePointerProtocolGuid   ## SOMETIMES_CONSUMES
> >
> >gEfiCpuIo2ProtocolGuid  ## SOMETIMES_CONSUMES
> >
> > +  gEfiHiiDatabaseProtocolGuid ## SOMETIMES_CONSUMES
> >
> >
> >
> >  [Guids]
> >
> >gEfiGlobalVariableGuid  ## SOMETIMES_CONSUMES ## GUID
> >
> > @@ -130,3 +131,11 @@ [Guids]
> >gEfiAcpi10TableGuid ## SOMETIMES_CONSUMES ## SystemTable
> >
> >gEfiAcpi20TableGuid ## SOMETIMES_CONSUMES ## SystemTable
> >
> >gShellDebug1HiiGuid ## SOMETIMES_CONSUMES ## HII
> >
> > +  gEfiMemoryAttributesTableGuid   ## SOMETIMES_CONSUMES ##
> > SystemTable
> >
> > +  gEfiRtPropertiesTableGuid   ## SOMETIMES_CONSUMES ##
> SystemTable
> >
> > +  gEfiSystemResourceTableGuid ## SOMETIMES_CONSUMES ##
> > SystemTable
> >
> > +  gEfiDebugImageInfoTableGuid ## SOMETIMES_CONSUMES ##
> > SystemTable
> >
> > +  gEfiImageSecurityDatabaseGuid   ## SOMETIMES_CONSUMES ##
> > SystemTable
> >
> > +  gEfiJsonConfigDataTableGuid ## SOMETIMES_CONSUMES ##
> > SystemTable
> >
> > +  gEfiJsonCapsuleDataTableGuid## SOMETIMES_CONSUMES ##
> > SystemTable
> >
> > +  gEfiJsonCapsuleResultTableGuid  ## SOMETIMES_CONSUMES ##
> > SystemTable
> >
> > diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
> > b/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
> > index c52c212a56f8..e2aed306d466 100644
> > --- a/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
> > +++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/Dmem.c
> > @@ -10,9 +10,16 @@
> >
> >

Re: [edk2-devel] [edk2-platforms][PATCH V2 1/1] Silicon/ARM/NeoverseN1Soc: Update CCIX PNP ID

[Samer El-Haj-Mahmoud]

Acked-by: Samer El-Haj-Mahmoud 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of sahil via
> groups.io
> Sent: Wednesday, November 30, 2022 5:29 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Leif Lindholm
> ; Sami Mujawar ; Sahil
> 
> Subject: [edk2-devel] [edk2-platforms][PATCH V2 1/1]
> Silicon/ARM/NeoverseN1Soc: Update CCIX PNP ID
>
> There is no need for a separate ID for CCIX host bridge,
> therefore reusing PCIe PNP ID for CCIX.
>
> Signed-off-by: sahil 
> ---
>
> Notes:
> v2:
> - removed licence fix, to be pushed separately [Leif Lindholm]
>
>  Silicon/ARM/NeoverseN1Soc/Library/PciHostBridgeLib/PciHostBridgeLib.c | 4
> ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
> a/Silicon/ARM/NeoverseN1Soc/Library/PciHostBridgeLib/PciHostBridgeLib.c
> b/Silicon/ARM/NeoverseN1Soc/Library/PciHostBridgeLib/PciHostBridgeLib.c
> index 1f38f654a8ce..6a154d771126 100644
> --- a/Silicon/ARM/NeoverseN1Soc/Library/PciHostBridgeLib/PciHostBridgeLib.c
> +++ b/Silicon/ARM/NeoverseN1Soc/Library/PciHostBridgeLib/PciHostBridgeLib.c
> @@ -65,8 +65,8 @@ STATIC EFI_PCI_ROOT_BRIDGE_DEVICE_PATH
> mEfiPciRootBridgeDevicePath[ROOT_COMPLEX_
>(UINT8)(sizeof (ACPI_HID_DEVICE_PATH) >> 8)
>
>  }
>
>},
>
> -  EISA_PNP_ID(0x0A09), // CCIX
>
> -  0
>
> +  EISA_PNP_ID(0x0A08), // CCIX
>
> +  1
>
>  },
>
>  {
>
>END_DEVICE_PATH_TYPE,
>
> --
> 2.25.1
>
>
>
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#96732): https://edk2.groups.io/g/devel/message/96732
> Mute This Topic: https://groups.io/mt/95355253/1945644
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [samer.el-haj-
> mahm...@arm.com]
> -=-=-=-=-=-=
>

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#96733): https://edk2.groups.io/g/devel/message/96733
Mute This Topic: https://groups.io/mt/95355253/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] MiscBootServices: Stall_Func: Reduces the stall interval for Stall_Func

[Samer El-Haj-Mahmoud]

BZ ticket created: https://bugzilla.tianocore.org/show_bug.cgi?id=4105

Patch was at: https://edk2.groups.io/g/discuss/message/1115


From: devel@edk2.groups.io  On Behalf Of G Edhaya 
Chandran via groups.io
Sent: Thursday, October 6, 2022 10:37 AM
To: Robert Wood ; devel@edk2.groups.io
Subject: Re: [edk2-devel] [PATCH v1 1/1] MiscBootServices: Stall_Func: Reduces 
the stall interval for Stall_Func

On Fri, Sep 30, 2022 at 05:28 AM, Robert Wood wrote:
MiscBootServicesBBTestFunction.c
Hi Robert,

   Can you please also raise a Bugzilla ticket for this issue here: Bug List 
(tianocore.org)
Please do attach the failure logs in the ticket.

This issue was discussed in the forum. May we know how the value of 400 was 
arrived for the new Stall value?

With Warm Regards,
Edhay

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#95861): https://edk2.groups.io/g/devel/message/95861
Mute This Topic: https://groups.io/mt/94007106/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] uefi-sct/SctPkg: Incorrect instances of RANDOM_NAME_PROTOCOL

[Samer El-Haj-Mahmoud]

Reviewed-By: Samer El-Haj-Mahmoud <

samer.el-haj-mahm...@arm.com>


From: devel@edk2.groups.io  on behalf of Sam Kaynor via 
groups.io 
Sent: Tuesday, October 11, 2022 1:54:43 PM
To: devel@edk2.groups.io 
Subject: [edk2-devel] [PATCH v1 1/1] uefi-sct/SctPkg: Incorrect instances of 
RANDOM_NAME_PROTOCOL

Changed 4 incorrect instances of "RANDOM_NAME_PROTOCOL" in
RandomNumberBBTestConformance and RandomNumberBBTestFunction
to "RANDOM_NUMBER_PROTOCOL".

Cc: G Edhaya Chandran 
Cc: Barton Gao 
Cc: Carolyn Gjertsen 
Cc: Samer El-Haj-Mahmoud 
Cc: Eric Jin 
Cc: Arvin Chen 
Cc: Supreeth Venkatesh 
Signed-off-by: Sam Kaynor 
---
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestConformance.c
 | 4 ++--
 
uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestFunction.c
| 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestConformance.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestConformance.c
index 2738a4899457..364aaca925e0 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestConformance.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestConformance.c
@@ -160,7 +160,7 @@ BBTestGetInfoConformanceTestCheckpoint1 (
StandardLib,
EFI_TEST_ASSERTION_WARNING,
gConformanceTestAssertionGuid001,
-   L"RANDOM_NAME_PROTOCOL.GetInfo - GetInfo() is not supported 
or EFI_DEVICE_ERROR",
+   L"RANDOM_NUMBER_PROTOCOL.GetInfo - GetInfo() is not 
supported or EFI_DEVICE_ERROR",
L"%a:%d: Status - %r",
__FILE__,
(UINTN)__LINE__,
@@ -180,7 +180,7 @@ BBTestGetInfoConformanceTestCheckpoint1 (
  StandardLib,
  AssertionType,
  gConformanceTestAssertionGuid001,
- L"RANDOM_NAME_PROTOCOL.GetInfo - GetInfo() returns 
EFI_BUFFER_TOO_SMALL with small RNGAlgorithmListSize and returns valid size",
+ L"RANDOM_NUMBER_PROTOCOL.GetInfo - GetInfo() returns 
EFI_BUFFER_TOO_SMALL with small RNGAlgorithmListSize and returns valid size",
  L"%a:%d: Status - %r, RNGAlgorithmListSize - %d",
  __FILE__,
  (UINTN)__LINE__,
diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestFunction.c
index 3d41085d2243..0ba003449dc6 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestFunction.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/RandomNumber/BlackBoxTest/RandomNumberBBTestFunction.c
@@ -188,7 +188,7 @@ BBTestGetInfoFunctionTestCheckpoint1 (
StandardLib,
EFI_TEST_ASSERTION_FAILED,
gTestGenericFailureGuid,
-   L"RANDOM_NAME_PROTOCOL.GetInfo - GetInfo() is not supported 
or EFI_DEVICE_ERROR",
+   L"RANDOM_NUMBER_PROTOCOL.GetInfo - GetInfo() is not 
supported or EFI_DEVICE_ERROR",
L"%a:%d: Status - %r",
__FILE__,
(UINTN)__LINE__,
@@ -201,7 +201,7 @@ BBTestGetInfoFunctionTestCheckpoint1 (
StandardLib,
EFI_TEST_ASSERTION_FAILED,
gTestGenericFailureGuid,
-   L"RANDOM_NAME_PROTOCOL.GetInfo - GetInfo() could not return 
the correct RNGAlgorithmListSize",
+   L"RANDOM_NUMBER_PROTOCOL.GetInfo - GetInfo() could not 
return the correct RNGAlgorithmListSize",
L"%a:%d: Status - %r",
__FILE__,
(UINTN)__LINE__,
--
2.34.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#95008): https://edk2.groups.io/g/devel/message/95008
Mute This Topic: https://groups.io/mt/94264735/1945644
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [samer.el-haj-mahm...@arm.com]
-=-=-=-=-=-=


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#95013): https://edk2.groups.io/g/de

Re: [edk2-devel] [PATCH v1 1/1] OvmfPkg/VirtioNetDxe: Check ChildHandle argument in GetControllerName

[Samer El-Haj-Mahmoud]

Hi Ard,

Any luck getting this one merged?

Thanks,
--Samer

> -Original Message-
> From: Sunny Wang 
> Sent: Friday, August 19, 2022 10:47 AM
> To: Dimitrije Pavlov ; devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Jiewen Yao
> ; Liming Gao ; Jeff
> Booher-Kaeding ; Samer El-Haj-Mahmoud
> ; Sunny Wang 
> Subject: RE: [PATCH v1 1/1] OvmfPkg/VirtioNetDxe: Check ChildHandle argument
> in GetControllerName
>
> Looks good.
> Reviewed-by: Sunny Wang 
>
> -Original Message-
> From: Dimitrije Pavlov 
> Sent: 17 August 2022 15:35
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Jiewen Yao
> ; Liming Gao ; Sunny
> Wang ; Jeff Booher-Kaeding  kaed...@arm.com>; Samer El-Haj-Mahmoud  mahm...@arm.com>
> Subject: [PATCH v1 1/1] OvmfPkg/VirtioNetDxe: Check ChildHandle argument in
> GetControllerName
>
> Per the UEFI specification, a device driver implementation should return
> EFI_UNSUPPORTED if the ChildHandle argument in
> EFI_COMPONENT_NAME2_PROTOCOL.GetControllerName() is not NULL.
>
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Liming Gao 
> Cc: Sunny Wang 
> Cc: Jeff Booher-Kaeding 
> Cc: Samer El-Haj-Mahmoud 
>
> Signed-off-by: Dimitrije Pavlov 
> ---
>  OvmfPkg/VirtioNetDxe/ComponentName.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/OvmfPkg/VirtioNetDxe/ComponentName.c
> b/OvmfPkg/VirtioNetDxe/ComponentName.c
> index e340ca2f8fe4..718096630f6f 100644
> --- a/OvmfPkg/VirtioNetDxe/ComponentName.c
> +++ b/OvmfPkg/VirtioNetDxe/ComponentName.c
> @@ -129,6 +129,13 @@ VirtioNetGetControllerName (
>  return EFI_INVALID_PARAMETER;
>}
>
> +  //
> +  // This is a device driver, so ChildHandle must be NULL.
> +  //
> +  if (ChildHandle != NULL) {
> +return EFI_UNSUPPORTED;
> +  }
> +
>//
>// confirm that the device is managed by this driver, using the VirtIo
>// Protocol
> --
> 2.37.2
>

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#94464): https://edk2.groups.io/g/devel/message/94464
Mute This Topic: https://groups.io/mt/93082232/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] OvmfPkg/PlatformDxe: Handle all requests in ExtractConfig and RouteConfig

[Samer El-Haj-Mahmoud]

Hi Ard,

Yes, this was found during SCT testing:

HII_CONFIG_ACCESS_PROTOCOL.ExtractConfig- ExtractConfig() returns EFI_SUCCESS 
or EFI_NOT_FOUND with Request been NULL . -- FAILURE
603E52F0-2CE3-4E7A-A72E-DF8CA3FDB20D
/home/dpavlov/qemu-cert/custom-testing/arm-systemready/SR/scripts/edk2-test/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/HIIConfigAccess/BlackBoxTest/HIIConfigAccessBBTestFunction.c:448:
 Status - Invalid Parameter

Thanks,
--Samer



> -Original Message-
> From: Ard Biesheuvel 
> Sent: Monday, September 5, 2022 8:01 AM
> To: Dimitrije Pavlov 
> Cc: devel@edk2.groups.io; Ard Biesheuvel ;
> Jiewen Yao ; Liming Gao ;
> Sunny Wang ; Jeff Booher-Kaeding  kaed...@arm.com>; Samer El-Haj-Mahmoud  mahm...@arm.com>
> Subject: Re: [PATCH v1 1/1] OvmfPkg/PlatformDxe: Handle all requests in
> ExtractConfig and RouteConfig
> 
> On Thu, 18 Aug 2022 at 21:58, Dimitrije Pavlov 
> wrote:
> >
> > Per the UEFI specification, if the Request argument in
> > EFI_HII_CONFIG_ACCESS_PROTOCOL.ExtractConfig() is NULL or does not
> contain
> > any request elements, the implementation should return all of the settings
> > being abstracted for the particular ConfigHdr reference.
> >
> > The current implementation returns EFI_INVALID_PARAMETER if Request is
> > NULL or does not contain any request elements. Instead, construct
> > a new ConfigRequest to handle these cases per the specification.
> >
> > In addition, per the UEFI specification, if the Configuration argument in
> > EFI_HII_CONFIG_ACCESS_PROTOCOL.RouteConfig() has a ConfigHdr that
> > specifies a non-existing target, the implementation should return
> > EFI_NOT_FOUND.
> >
> > The current implementation returns EFI_INVALID_PARAMETER if Configuration
> > has a non-existing target in ConfigHdr. Instead, perform a check and
> > return EFI_NOT_FOUND in this case.
> >
> > Cc: Ard Biesheuvel 
> > Cc: Jiewen Yao 
> > Cc: Liming Gao 
> > Cc: Sunny Wang 
> > Cc: Jeff Booher-Kaeding 
> > Cc: Samer El-Haj-Mahmoud 
> >
> > Signed-off-by: Dimitrije Pavlov 
> 
> Was this issue caught in some kind of testing/validation?
> 
> > ---
> >  OvmfPkg/PlatformDxe/PlatformConfig.h |   2 +
> >  OvmfPkg/PlatformDxe/Platform.c   | 115 +++-
> >  OvmfPkg/PlatformDxe/PlatformConfig.c |   2 +-
> >  3 files changed, 116 insertions(+), 3 deletions(-)
> >
> > diff --git a/OvmfPkg/PlatformDxe/PlatformConfig.h
> b/OvmfPkg/PlatformDxe/PlatformConfig.h
> > index 902c9b2ce043..5d9b457b1b4b 100644
> > --- a/OvmfPkg/PlatformDxe/PlatformConfig.h
> > +++ b/OvmfPkg/PlatformDxe/PlatformConfig.h
> > @@ -50,4 +50,6 @@ PlatformConfigLoad (
> >  #define PLATFORM_CONFIG_F_GRAPHICS_RESOLUTION  BIT0
> >  #define PLATFORM_CONFIG_F_DOWNGRADEBIT63
> >
> > +extern CHAR16  mVariableName[];
> > +
> >  #endif // _PLATFORM_CONFIG_H_
> > diff --git a/OvmfPkg/PlatformDxe/Platform.c
> b/OvmfPkg/PlatformDxe/Platform.c
> > index a6d459f3dfd7..0e32c6e76037 100644
> > --- a/OvmfPkg/PlatformDxe/Platform.c
> > +++ b/OvmfPkg/PlatformDxe/Platform.c
> > @@ -108,6 +108,11 @@ STATIC EFI_EVENT  mGopEvent;
> >  //
> >  STATIC VOID  *mGopTracker;
> >
> > +//
> > +// The driver image handle, used to obtain the device path for .
> > +//
> > +STATIC EFI_HANDLE  mImageHandle;
> > +
> >  //
> >  // Cache the resolutions we get from the GOP.
> >  //
> > @@ -229,6 +234,10 @@ ExtractConfig (
> >  {
> >MAIN_FORM_STATE  MainFormState;
> >EFI_STATUS   Status;
> > +  EFI_STRING   ConfigRequestHdr;
> > +  EFI_STRING   ConfigRequest;
> > +  UINTNSize;
> > +  BOOLEAN  AllocatedRequest;
> >
> >DEBUG ((DEBUG_VERBOSE, "%a: Request=\"%s\"\n", __FUNCTION__,
> Request));
> >
> > @@ -236,18 +245,73 @@ ExtractConfig (
> >  return EFI_INVALID_PARAMETER;
> >}
> >
> > +  ConfigRequestHdr = NULL;
> > +  ConfigRequest= NULL;
> > +  Size = 0;
> > +  AllocatedRequest = FALSE;
> > +
> > +  //
> > +  // Check if  matches the GUID and name
> > +  //
> > +  *Progress = Request;
> > +  if ((Request != NULL) &&
> > +  !HiiIsConfigHdrMatch (
> > + Request,
> > + &gOvmfPlatformConfigGuid,
> > + mVariableName
> > + )
> > +  )
> > +  {
> > +return EFI_NOT_FOUND;
> > +  }
> > +
> >Status = PlatformConfigToFormState (&MainFormState);
> >if 

Re: [edk2-devel] [PATCH v1 1/1] OvmfPkg/VirtioNetDxe: Check ChildHandle argument in GetControllerName

[Samer El-Haj-Mahmoud]

Reviewed-By: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Dimitrije Pavlov 
> Sent: Wednesday, August 17, 2022 10:35 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Jiewen Yao
> ; Liming Gao ; Sunny
> Wang ; Jeff Booher-Kaeding  kaed...@arm.com>; Samer El-Haj-Mahmoud  mahm...@arm.com>
> Subject: [PATCH v1 1/1] OvmfPkg/VirtioNetDxe: Check ChildHandle argument in
> GetControllerName
>
> Per the UEFI specification, a device driver implementation should return
> EFI_UNSUPPORTED if the ChildHandle argument in
> EFI_COMPONENT_NAME2_PROTOCOL.GetControllerName() is not NULL.
>
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Liming Gao 
> Cc: Sunny Wang 
> Cc: Jeff Booher-Kaeding 
> Cc: Samer El-Haj-Mahmoud 
>
> Signed-off-by: Dimitrije Pavlov 
> ---
>  OvmfPkg/VirtioNetDxe/ComponentName.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/OvmfPkg/VirtioNetDxe/ComponentName.c
> b/OvmfPkg/VirtioNetDxe/ComponentName.c
> index e340ca2f8fe4..718096630f6f 100644
> --- a/OvmfPkg/VirtioNetDxe/ComponentName.c
> +++ b/OvmfPkg/VirtioNetDxe/ComponentName.c
> @@ -129,6 +129,13 @@ VirtioNetGetControllerName (
>  return EFI_INVALID_PARAMETER;
>}
>
> +  //
> +  // This is a device driver, so ChildHandle must be NULL.
> +  //
> +  if (ChildHandle != NULL) {
> +return EFI_UNSUPPORTED;
> +  }
> +
>//
>// confirm that the device is managed by this driver, using the VirtIo
>// Protocol
> --
> 2.37.2

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH] Add support for SMBIOS Spec 3.6.0 to SmBios.h

[Samer El-Haj-Mahmoud]

A quick compare against the SMBIOS 3.6.0. Looks good! Thanks for adding this.

Reviewed-By: Samer El-Haj-Mahmoud 


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Sainadh
> Nagolu via groups.io
> Sent: Wednesday, August 3, 2022 12:52 AM
> To: devel@edk2.groups.io; Sainadh Nagolu 
> Cc: Sundaresan S ; Vasudevan Sambandan
> ; gaolim...@byosoft.com.cn
> Subject: [edk2-devel] [PATCH] Add support for SMBIOS Spec 3.6.0 to SmBios.h
> 
> Updated SmBios.h with new fields added as part of SMBIOS 3.6.0 spec update.
> 
> Signed-off-by: Sainadh Nagolu 
> 
> CC: Vasudevan Sambandan 
> CC: Sundaresan S 
> 
> ---
>  MdePkg/Include/IndustryStandard/SmBios.h | 88 
>  1 file changed, 61 insertions(+), 27 deletions(-)
> 
> diff --git a/MdePkg/Include/IndustryStandard/SmBios.h
> b/MdePkg/Include/IndustryStandard/SmBios.h
> index c7a4971f14..3b296ab308 100644
> --- a/MdePkg/Include/IndustryStandard/SmBios.h
> +++ b/MdePkg/Include/IndustryStandard/SmBios.h
> @@ -1,5 +1,5 @@
>  /** @file
> 
> -  Industry Standard Definitions of SMBIOS Table Specification v3.5.0.
> 
> +  Industry Standard Definitions of SMBIOS Table Specification v3.6.0.
> 
> 
> 
>  Copyright (c) 2006 - 2021, Intel Corporation. All rights reserved.
> 
>  (C) Copyright 2015-2017 Hewlett Packard Enterprise Development LP
> 
> @@ -722,21 +722,39 @@ typedef enum {
>  /// Processor Information2 - Processor Family2.
> 
>  ///
> 
>  typedef enum {
> 
> -  ProcessorFamilyARMv7  = 0x0100,
> 
> -  ProcessorFamilyARMv8  = 0x0101,
> 
> -  ProcessorFamilySH3= 0x0104,
> 
> -  ProcessorFamilySH4= 0x0105,
> 
> -  ProcessorFamilyARM= 0x0118,
> 
> -  ProcessorFamilyStrongARM  = 0x0119,
> 
> -  ProcessorFamily6x86   = 0x012C,
> 
> -  ProcessorFamilyMediaGX= 0x012D,
> 
> -  ProcessorFamilyMII= 0x012E,
> 
> -  ProcessorFamilyWinChip= 0x0140,
> 
> -  ProcessorFamilyDSP= 0x015E,
> 
> -  ProcessorFamilyVideoProcessor = 0x01F4,
> 
> -  ProcessorFamilyRiscvRV32  = 0x0200,
> 
> -  ProcessorFamilyRiscVRV64  = 0x0201,
> 
> -  ProcessorFamilyRiscVRV128 = 0x0202
> 
> +  ProcessorFamilyARMv7= 0x0100,
> 
> +  ProcessorFamilyARMv8= 0x0101,
> 
> +  ProcessorFamilyARMv9= 0x0102,
> 
> +  ProcessorFamilySH3  = 0x0104,
> 
> +  ProcessorFamilySH4  = 0x0105,
> 
> +  ProcessorFamilyARM  = 0x0118,
> 
> +  ProcessorFamilyStrongARM= 0x0119,
> 
> +  ProcessorFamily6x86 = 0x012C,
> 
> +  ProcessorFamilyMediaGX  = 0x012D,
> 
> +  ProcessorFamilyMII  = 0x012E,
> 
> +  ProcessorFamilyWinChip  = 0x0140,
> 
> +  ProcessorFamilyDSP  = 0x015E,
> 
> +  ProcessorFamilyVideoProcessor   = 0x01F4,
> 
> +  ProcessorFamilyRiscvRV32= 0x0200,
> 
> +  ProcessorFamilyRiscVRV64= 0x0201,
> 
> +  ProcessorFamilyRiscVRV128   = 0x0202,
> 
> +  ProcessorFamilyLoongArch= 0x0258,
> 
> +  ProcessorFamilyLoongson1= 0x0259,
> 
> +  ProcessorFamilyLoongson2= 0x025A,
> 
> +  ProcessorFamilyLoongson3= 0x025B,
> 
> +  ProcessorFamilyLoongson2K   = 0x025C,
> 
> +  ProcessorFamilyLoongson3A   = 0x025D,
> 
> +  ProcessorFamilyLoongson3B   = 0x025E,
> 
> +  ProcessorFamilyLoongson3C   = 0x025F,
> 
> +  ProcessorFamilyLoongson3D   = 0x0260,
> 
> +  ProcessorFamilyLoongson3E   = 0x0261,
> 
> +  ProcessorFamilyDualCoreLoongson2K   = 0x0262,
> 
> +  ProcessorFamilyQuadCoreLoongson3A   = 0x026C,
> 
> +  ProcessorFamilyMultiCoreLoongson3A  = 0x026D,
> 
> +  ProcessorFamilyQuadCoreLoongson3B   = 0x026E,
> 
> +  ProcessorFamilyMultiCoreLoongson3B  = 0x026F,
> 
> +  ProcessorFamilyMultiCoreLoongson3C  = 0x0270,
> 
> +  ProcessorFamilyMultiCoreLoongson3D  = 0x0271
> 
>  } PROCESSOR_FAMILY2_DATA;
> 
> 
> 
>  ///
> 
> @@ -817,7 +835,16 @@ typedef enum {
>ProcessorUpgradeSocketBGA1528   = 0x3C,
> 
>ProcessorUpgradeSocketLGA4189   = 0x3D,
> 
>ProcessorUpgradeSocketLGA1200   = 0x3E,
> 
> -  ProcessorUpgradeSocketLGA4677   = 0x3F
> 
> +  ProcessorUpgradeSocketLGA4677   = 0x3F,
> 
> +  ProcessorUpgradeSocketLGA1700   = 0x40,
> 
> +  ProcessorUpgradeSocketBGA1744   = 0x41,
> 
> +  ProcessorUpgradeSocketBGA1781   = 0x42,
> 
> +  ProcessorUpgradeSocketBGA1211   = 0x43,
> 
> +  ProcessorUpgradeS

Re: [edk2-devel] [edk2-platforms][PATCH v1 1/1] Silicon/Qemu: Add SMBIOS tables of types 16, 17, and 19

[Samer El-Haj-Mahmoud]

Thanks Dimitrije for the patch!

Reviewed-By: Samer El-Haj-Mahmoud 


> -Original Message-
> From: Dimitrije Pavlov 
> Sent: Wednesday, July 20, 2022 6:05 PM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Leif Lindholm
> ; Graeme Gregory ;
> Radoslaw Biernacki ; Jeff Booher-Kaeding  kaed...@arm.com>; Samer El-Haj-Mahmoud  mahm...@arm.com>; Sunny Wang ; Jeremy Linton
> 
> Subject: [edk2-platforms][PATCH v1 1/1] Silicon/Qemu: Add SMBIOS tables of
> types 16, 17, and 19
> 
> Arm SBBR specification includes the list of required and recommended
> SMBIOS tables. Tables of types 16 (Physical Memory Array),
> 17 (Memory Device), and 19 (Memory Array Mapped Address) are required,
> but are not included in the current SbsaQemu SMBIOS driver. The current
> SMBIOS driver provides a limited number of tables using ArmPkg.
> 
> This patch adds SbsaQemu-specific tables of types 16, 17, and 19.
> 
> Cc: Ard Biesheuvel 
> Cc: Leif Lindholm 
> Cc: Graeme Gregory 
> Cc: Radoslaw Biernacki 
> Cc: Jeff Booher-Kaeding 
> Cc: Samer El-Haj-Mahmoud 
> Cc: Sunny Wang 
> Cc: Jeremy Linton 
> 
> Signed-off-by: Dimitrije Pavlov 
> ---
>  Platform/Qemu/SbsaQemu/SbsaQemu.dsc   |   1 +
>  Platform/Qemu/SbsaQemu/SbsaQemu.fdf   |   1 +
> 
> Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuSmbiosDxe/SbsaQemuSmbiosDxe.i
> nf |  48 +++
> 
> Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuSmbiosDxe/SbsaQemuSmbiosDxe.c
> | 405 
>  4 files changed, 455 insertions(+)
> 
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> index 97014e2fb630..b7050d911708 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
> @@ -721,6 +721,7 @@ [Components.common]
>ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
>EmbeddedPkg/Library/FdtLib/FdtLib.inf
>MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
> +
> Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuSmbiosDxe/SbsaQemuSmbiosDxe.i
> nf
> 
>#
># PCI support
> diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> index c35e3ed44054..9f031c3e6649 100644
> --- a/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> +++ b/Platform/Qemu/SbsaQemu/SbsaQemu.fdf
> @@ -242,6 +242,7 @@ [FV.FvMain]
>INF
> ArmPkg/Universal/Smbios/ProcessorSubClassDxe/ProcessorSubClassDxe.inf
>INF ArmPkg/Universal/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
>INF MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
> +  INF
> Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuSmbiosDxe/SbsaQemuSmbiosDxe.i
> nf
> 
>#
># PCI support
> diff --git
> a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuSmbiosDxe/SbsaQemuSmbiosDx
> e.inf
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuSmbiosDxe/SbsaQemuSmbiosDx
> e.inf
> new file mode 100644
> index ..b5d156f6654e
> --- /dev/null
> +++
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuSmbiosDxe/SbsaQemuSmbiosDx
> e.inf
> @@ -0,0 +1,48 @@
> +#/** @file
> +#
> +#  Static SMBIOS tables for the SbsaQemu platform.
> +#
> +#  Copyright (c) 2022, ARM Limited. All rights reserved.
> +#
> +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> +#
> +#**/
> +
> +[Defines]
> +  INF_VERSION= 0x0001001A
> +  BASE_NAME  = SbsaQemuSmbiosDxe
> +  FILE_GUID  = DDE1ACCB-0555-4CAA-85E7-3CBC8962026E
> +  MODULE_TYPE= DXE_DRIVER
> +  VERSION_STRING = 1.0
> +  ENTRY_POINT= SbsaQemuSmbiosDriverEntryPoint
> +
> +[Sources]
> +  SbsaQemuSmbiosDxe.c
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  MdeModulePkg/MdeModulePkg.dec
> +  ArmPlatformPkg/ArmPlatformPkg.dec
> +  ArmPkg/ArmPkg.dec
> +
> +[LibraryClasses]
> +  ArmLib
> +  ArmPlatformLib
> +  UefiBootServicesTableLib
> +  MemoryAllocationLib
> +  BaseMemoryLib
> +  BaseLib
> +  UefiLib
> +  UefiDriverEntryPoint
> +  DebugLib
> +  PrintLib
> +
> +[Protocols]
> +  gEfiSmbiosProtocolGuid
> +
> +[Depex]
> +  gEfiSmbiosProtocolGuid
> +
> +[Pcd]
> +  gArmTokenSpaceGuid.PcdSystemMemorySize
> +  gArmTokenSpaceGuid.PcdSystemMemoryBase
> diff --git
> a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuSmbiosDxe/SbsaQemuSmbiosDx
> e.c
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuSmbiosDxe/SbsaQemuSmbiosDx
> e.c
> new file mode 100644
> index ..9ef5168b79f6
> --- /dev/null
> +++
> b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuSmbiosDxe/SbsaQemuSmbiosDx
> e.c
> @@ -0,0 +1,405 @@
> +/** @file
> + *
> + *  Static SMBIOS tables for the SbsaQemu platform.
> + *
> + *  Note: Some

Re: [edk2-devel] [PATCH v1 1/1] OvmfPkg/QemuVideoDxe: Zero out PixelInformation in QueryMode

[Samer El-Haj-Mahmoud]

Reviewed-By: Samer El-Haj-Mahmoud 


Any chance we can get this pushed?

Thanks,
--Samer


> -Original Message-
> From: Dimitrije Pavlov 
> Sent: Tuesday, June 28, 2022 2:48 PM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Jiewen Yao
> ; Jordan Justen ;
> Gerd Hoffmann ; Jeff Booher-Kaeding  kaed...@arm.com>; Samer El-Haj-Mahmoud  mahm...@arm.com>; Sunny Wang ; Jeremy
> Linton 
> Subject: [PATCH v1 1/1] OvmfPkg/QemuVideoDxe: Zero out
> PixelInformation in QueryMode
> 
> Ensure that the PixelInformation field of the
> EFI_GRAPHICS_OUTPUT_MODE_INFORMATION structure is zeroed out in
> EFI_GRAPHICS_OUTPUT_PROTOCOL.QueryMode() and
> EFI_GRAPHICS_OUTPUT_PROTOCOL.SetMode() when PixelFormat is
> PixelBlueGreenRedReserved8BitPerColor.
> 
> According to UEFI 2.9 Section 12.9, PixelInformation field of the
> EFI_GRAPHICS_OUTPUT_MODE_INFORMATION structure is valid only if
> PixelFormat is PixelBitMask. This means that firmware is not required
> to fill out the PixelInformation field for other PixelFormat types,
> which implies that the QemuVideoDxe implementation is technically
> correct.
> 
> However, not zeroing out those fields will leak the contents of the
> memory returned by the memory allocator, so it is better to explicitly
> set them to zero.
> 
> In addition, the SCT test suite relies on PixelInformation always
> having a consistent value, which causes failures.
> 
> Cc: Ard Biesheuvel 
> Cc: Jiewen Yao 
> Cc: Jordan Justen 
> Cc: Gerd Hoffmann 
> Cc: Jeff Booher-Kaeding 
> Cc: Samer El-Haj-Mahmoud 
> Cc: Sunny Wang 
> Cc: Jeremy Linton 
> 
> Signed-off-by: Dimitrije Pavlov 
> ---
>  OvmfPkg/QemuVideoDxe/Gop.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/OvmfPkg/QemuVideoDxe/Gop.c
> b/OvmfPkg/QemuVideoDxe/Gop.c
> index 0c4dea7fb6f2..7a9fe208c99c 100644
> --- a/OvmfPkg/QemuVideoDxe/Gop.c
> +++ b/OvmfPkg/QemuVideoDxe/Gop.c
> @@ -31,7 +31,14 @@ QemuVideoCompleteModeInfo (
>  Info->PixelInformation.ReservedMask = 0;
>} else if (ModeData->ColorDepth == 32) {
>  DEBUG ((DEBUG_INFO, "PixelBlueGreenRedReserved8BitPerColor\n"));
> -Info->PixelFormat = PixelBlueGreenRedReserved8BitPerColor;
> +Info->PixelFormat   =
> PixelBlueGreenRedReserved8BitPerColor;
> +Info->PixelInformation.RedMask  = 0;
> +Info->PixelInformation.GreenMask= 0;
> +Info->PixelInformation.BlueMask = 0;
> +Info->PixelInformation.ReservedMask = 0;
> +  } else {
> +DEBUG ((DEBUG_ERROR, "%a: Invalid ColorDepth %u", __FUNCTION__,
> ModeData->ColorDepth));
> +ASSERT (FALSE);
>}
> 
>Info->PixelsPerScanLine = Info->HorizontalResolution;
> --
> 2.34.1



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

Re: [edk2-devel] [PATCH 5/8] MdePkg: Define CC Measure EventLog ACPI Table

[Samer El-Haj-Mahmoud]

Thanks Sami and Jiewen.

I will bring this to ASWG attention to confirm the change.



> -Original Message-
> From: Yao, Jiewen 
> Sent: Thursday, March 17, 2022 9:23 AM
> To: Sami Mujawar ; Xu, Min M
> ; devel@edk2.groups.io
> Cc: Kinney, Michael D ; Gao, Liming
> ; Liu, Zhiguang ; Wang,
> Jian J ; Lu, Ken ; Gerd Hoffmann
> ; nd ; Samer El-Haj-Mahmoud
> ; Thanu Rangarajan
> 
> Subject: RE: [PATCH 5/8] MdePkg: Define CC Measure EventLog ACPI Table
> 
> Thanks to remind me.
> 
> I uploaded version 2 in the same mantis.
> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Sami Mujawar 
> > Sent: Thursday, March 17, 2022 9:10 PM
> > To: Yao, Jiewen ; Xu, Min M
> ;
> > devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Gao, Liming
> > ; Liu, Zhiguang ;
> Wang,
> > Jian J ; Lu, Ken ; Gerd Hoffmann
> > ; nd ; Samer El-Haj-Mahmoud
>  > haj-mahm...@arm.com>; Thanu Rangarajan
> 
> > Subject: Re: [PATCH 5/8] MdePkg: Define CC Measure EventLog ACPI Table
> >
> > Hi Jiewen,
> >
> > I was informed there is an ASWG ECR
> > https://mantis.uefi.org/mantis/view.php?id=2177 for TDEL. I can see the
> > content has been approved for ACPI 6.5.
> >
> > Do you plan to update this ECR to reflect the changes for CCEL or this would
> be
> > a separate request?
> >
> > Regards,
> >
> > Sami Mujawar
> >
> > On 10/03/2022, 10:27, "Sami Mujawar"  wrote:
> >
> > Hi Jiewen,
> >
> > Please find my response inline marked [SAMI].
> >
> > Regards,
> >
> > Sami Mujawar
> >
> > On 10/03/2022, 05:49, "Yao, Jiewen"  wrote:
> >
> > HI Sami
> > I think it is OK to update signature to `CCEL`. That means it will 
> > be
> applicable
> > for other CC, right?
> > [SAMI] Yes, the same table can then be used by other CC.
> >
> > Then, I recommend we add CcType there.
> >
> > typedef struct {
> >   EFI_ACPI_DESCRIPTION_HEADERHeader;
> >   EFI_CC_TYPE   CcType; <== new field.
> >   UINT16 Rsvd;
> >   UINT64 Laml;
> >   UINT64 Lasa;
> > } EFI_CC_EVENTLOG_ACPI_TABLE;
> >
> > Do you agree?
> > [SAMI] Agree, the above suggestion looks good to me.
> >
> >     Thank you
> > Yao Jiewen
> >
> > > -Original Message-
> > > From: Sami Mujawar 
> > > Sent: Wednesday, March 9, 2022 11:35 PM
> > > To: Xu, Min M ; devel@edk2.groups.io
> > > Cc: Kinney, Michael D ; Gao, Liming
> > > ; Liu, Zhiguang
> ;
> > Yao,
> > > Jiewen ; Wang, Jian J
> ;
> > Lu, Ken
> > > ; Gerd Hoffmann ; nd
> > ;
> > > Samer El-Haj-Mahmoud ;
> > > thanu.rangara...@arm.com
> > > Subject: Re: [PATCH 5/8] MdePkg: Define CC Measure EventLog ACPI
> > Table
> > >
> > > Hi Min,
> > >
> > > Thank you for this patch.
> > >
> > > Please find my response inline marked [SAMI].
> > >
> > > Regards,
> > >
> > > Sami Mujawar
> > >
> > >
> > > On 02/03/2022 12:28 AM, Min Xu wrote:
> > > > RFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3853
> > > >
> > > > TDVF set up an ACPI table (EFI_CC_EVENTLOG_ACPI_TABLE) to pass
> the
> > > > event-log information. The event log created by the TD owner
> contains
> > > > the hashes to reconstruct the MRTD and RTMR registers.
> > > >
> > > > Please refer to Sec 4.3.3 in blow link:
> > > >
> > https://www.intel.com/content/dam/develop/external/us/en/documents/
> > > > intel-tdx-guest-hypervisor-communication-interface-1.0-344426-
> > 002.pdf
> > > >
> > > > Cc: Michael D Kinney 
> > > > Cc: Liming Gao 
> > > > Cc: Zhiguang Liu 
> > > > Cc: Jiewen Yao 
> > > > Cc: Jian J Wang 
> > > > Cc: Ken Lu 
> > > > Cc: Sami Mujawar 
> > > > Cc: Gerd Hoffmann 
> > > >

Re: [edk2-devel] [edk2-platforms PATCH] Platform/RaspberryPi: Fix miniuart base address and length

[Samer El-Haj-Mahmoud]

I see that DBG2/SPCR spec 
(https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-debug-port-table)
 defines 0x10 for Serial type for BCM2835:

0x0010
BCM2835

Should the spec be updated to make this more explicit? i.e. "BCM283x/BCM27xx 
MiniUART"



From: devel@edk2.groups.io  On Behalf Of Andrei Warkentin 
via groups.io
Sent: Tuesday, December 14, 2021 1:21 AM
To: Jeremy Linton ; devel@edk2.groups.io; Ard Biesheuvel 
; Adrien Thierry ; Pete Batard 

Cc: Ard Biesheuvel ; Leif Lindholm 

Subject: Re: [edk2-devel] [edk2-platforms PATCH] Platform/RaspberryPi: Fix 
miniuart base address and length

The Raspberry Pi support in edk2-platforms, including ACPI, is a direct 
ancestor of the original ms-iot tree (https://github.com/ms-iot/RPi-UEFI, by 
way of https://github.com/andreiw/RaspberryPiPkg).
The way the miniUART is described in ACPI came from Microsoft. Microsoft 
introduced DBG2/SPCR type 0x10 
(https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-debug-port-table)
 and the BCM2836 _HID to describe the miniUART, and the contract is that the 
base address includes all those crazy registers.

To the best of my knowledge, today there isn't any other way to correctly 
describe the miniUART in a DBG2, SPCR or DSDT. Moreover, because there's code 
out there in at least two operating systems coded against these specific 
definitions, you don't get to change how a _HID == BCM2836 device or SPCR/DBG2 
type 0x10 is described.

If you wanted to introduce an alternate mechanism to describe the miniUART - 
great. You'd have to pick a new _HID. And re-use one of the generic DBG2/SPCR 
types or cajole for a new one (I'm guessing in the ASWG but I really don't 
know). But you surely can't haphazardly change an existing firmware<->OS 
contract. Moreover, you can't deprecate the existing contract overnight as 
well, so you'd have to add an option to expose the miniUART using a presumably 
more-Linux friendly option.

If you do introduce a new mechanism to describe the miniUART in ACPI, I'm happy 
to add support for it in ESXi, paving the way for eventual deprecation of the 
current mechanism (assuming you get all the other OSes to play ball too...)

Still a NAK. It's not a fix because it's not broken. And it's not considered 
broken just because you don't like the definitions. I don't like the 
definitions either, but that's all we got.

A


From: Jeremy Linton mailto:jeremy.lin...@arm.com>>
Sent: Monday, December 13, 2021 11:39 PM
To: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>; Andrei Warkentin 
mailto:awarken...@vmware.com>>; Ard Biesheuvel 
mailto:a...@kernel.org>>; Adrien Thierry 
mailto:athie...@redhat.com>>; Pete Batard 
mailto:p...@akeo.ie>>
Cc: Ard Biesheuvel 
mailto:ardb+tianoc...@kernel.org>>; Leif Lindholm 
mailto:l...@nuviainc.com>>
Subject: Re: [edk2-devel] [edk2-platforms PATCH] Platform/RaspberryPi: Fix 
miniuart base address and length

Hi,

On 12/13/21 13:17, Andrei Warkentin via groups.io wrote:
> If I understand correctly, you want to describe the UART at 0x00215000 to be 
> at 0x00215040.
>
> This will break SPCR and DBG2 - so that's a regression for Windows, ESXi and 
> possibly the NetBSDs.
>
> I guess that's a NAK unless I misunderstood something.

Presumably the end goal is to get BT working, or are we trying to get
the console working too?

Either way, the historical SPCR definition is less than ideal because it
covers those AUX_IRQ/AUX_ENABLE registers which include information for
the SPI which isn't included in the "uart" definition here. So, IMHO it
is wrong, but its stuck that way unless we define another uart. Which if
all we wanted it for was BT then we could just create another device
under BCM2836 which is only the 8250 like registers. That is sorta ugly,
but not having a standard uart is ugly too. The other ugly thing is to
just use the address as is, and offset it by 0x40 in linux as part of
the clock and ACPI bindings linux patch. (i've got a patch to make it
work someone wants to bite into it. Lol).

For linux the base clock-rate is going to have to be added as a _DSD
too. Which I assume is a large part of why it has a custom SPCR id? Put
another way, is anyone using the extra AUX_ registers, and what else are
people (windows/etc) "quirking" with the SPCR id?

For linux I've not particularly felt the need to fix this because I had
BT working (although unreliably) this time last year when I was working
on the SD/SDIO drivers, and my answer at the time was that one either
gets a serial console using the pl011 or one gets BT with the pl011. But
it looks like at a minimum the linux-firmware project and the brcmfmac
firmware loader have been tweaked over the past year and getting BT
working isn't as simple as just taking the miniuart-bt line out of
config.txt as I have in my not particularly good notes from that time
period.

So, while its behaving like it did when it had bad firmware,

Re: [edk2-devel] [PATCH 0/4] SynQuacer drivers test the ControllerHandle correctly

[Samer El-Haj-Mahmoud]

For situations like this, maybe " Co-authored-by" can be used?

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Leif
> Lindholm via groups.io
> Sent: Wednesday, October 27, 2021 7:22 AM
> To: Masami Hiramatsu 
> Cc: Ard Biesheuvel ; devel@edk2.groups.io;
> Kazuhiko Sakamoto 
> Subject: Re: [edk2-devel] [PATCH 0/4] SynQuacer drivers test the
> ControllerHandle correctly
>
> Hi Masami,
>
> Apologies for delay.
>
> Thank you, this set looks good.
> However, you cannot make legal statements on behalf of Sakamoto-san,
> only yourself. If you are happy with that, I could drop their
> Signed-off-by: statements before I push. They would retain the
> authorship.
>
> Best Regards,
>
> Leif
>
> On Wed, Oct 13, 2021 at 14:36:43 +0900, Masami Hiramatsu wrote:
> > Hello,
> >
> > Here are the patches to fix the SynQuacer related drivers to test
> > whether the ControllerHandle is managed by that driver correctly.
> > These bugs are found by edk2-test.
> >
> > Thank you,
> >
> > ---
> >
> > Kazuhiko Sakamoto (4):
> >   Silicon/SynQuacerNetsecDxe: Test the ControllerHandle is managed by
> this driver
> >   Silicon/SynQuacerI2cDxe: Test the ControllerHandle is managed by this
> driver
> >   Silicon/AtSha204a: Test the ControllerHandle is managed by this driver
> >   Silicon/ChaosKeyDxe: Test the ControllerHandle is managed by this
> driver
> >
> >
> >  Silicon/Atmel/AtSha204a/AtSha204aDriver.h  |1 +
> >  Silicon/Atmel/AtSha204a/ComponentName.c|   13 +
> >  Silicon/Atmel/AtSha204a/DriverBinding.c|1 -
> >  Silicon/Openmoko/ChaosKeyDxe/ChaosKeyDriver.h  |1 +
> >  Silicon/Openmoko/ChaosKeyDxe/ComponentName.c   |   13
> +
> >  Silicon/Openmoko/ChaosKeyDxe/DriverBinding.c   |1 -
> >  .../Drivers/Net/NetsecDxe/ComponentName.c  |   13 +
> >  .../Drivers/Net/NetsecDxe/DriverBinding.c  |1 -
> >  .../SynQuacer/Drivers/Net/NetsecDxe/NetsecDxe.h|1 +
> >  .../Drivers/SynQuacerI2cDxe/ComponentName.c|   13
> +
> >  .../Drivers/SynQuacerI2cDxe/DriverBinding.c|2 +-
> >  .../Drivers/SynQuacerI2cDxe/SynQuacerI2cDxe.h  |1 +
> >  12 files changed, 57 insertions(+), 4 deletions(-)
> >
> > --
> > Masami Hiramatsu 
>
>
> 
>

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH 1/1] SecurityPkg/DxeImageVerificationLib: Set Action for failed unsigned image

[Samer El-Haj-Mahmoud]

Hi Jiewen, Jian, and Min,

Can you please review this patch? We have a corresponding UEFI Spec "code 
first" ECR (https://bugzilla.tianocore.org/show_bug.cgi?id=3561), and need to 
clarify a couple of cases in the code.

Thanks,
--Samer

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Joseph
> Hemann via groups.io
> Sent: Tuesday, October 12, 2021 12:57 PM
> To: devel@edk2.groups.io
> Cc: nd ; Joseph Hemann ; Jiewen
> Yao ; Jian J Wang ; Min Xu
> ; Joseph Hemann 
> Subject: [edk2-devel] [PATCH 1/1] SecurityPkg/DxeImageVerificationLib: Set
> Action for failed unsigned image
> 
> If the image is not signed and the hash of image is not found
> in DB/DBX, then the EFI_IMAGE_INFO_ACTION of the load of said
> image should be set to,
> EFI_IMAGE_EXECUTION_AUTH_SIG_NOT_FOUND, rather then being left
> unset as EFI_IMAGE_EXECUTION_AUTH_UNTESTED.
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Min Xu 
> 
> Signed-off-by: Joseph Hemann 
> Change-Id: Ia432ebf4ec811e36d67b80bc438a6aff60bc9b67
> ---
>  .../Library/DxeImageVerificationLib/DxeImageVerificationLib.c| 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git
> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
> b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
> index 0a804af2162f..e5fae732bb1f 100644
> --- a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
> +++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
> @@ -1848,6 +1848,7 @@ DxeImageVerificationHandler (
>  //
>  // Image Hash is not found in both forbidden and allowed database.
>  //
> +Action = EFI_IMAGE_EXECUTION_AUTH_SIG_NOT_FOUND;
>  DEBUG ((DEBUG_INFO, "DxeImageVerificationLib: Image is not signed and %s
> hash of image is not found in DB/DBX.\n", mHashTypeStr));
>  goto Failed;
>}
> --
> 2.17.1
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH 1/1] SecurityPkg/DxeImageVerificationLib: Set Action for failed signed image

[Samer El-Haj-Mahmoud]

Hi Jiewen, Jian, and Min,

Can you please review this patch? We have a corresponding UEFI Spec "code 
first" ECR (https://bugzilla.tianocore.org/show_bug.cgi?id=3561), and need to 
clarify a couple of cases in the code.

Thanks,
--Samer


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Joseph
> Hemann via groups.io
> Sent: Tuesday, October 12, 2021 12:59 PM
> To: devel@edk2.groups.io
> Cc: nd ; Joseph Hemann ; Jiewen
> Yao ; Jian J Wang ; Min Xu
> 
> Subject: [edk2-devel] [PATCH 1/1] SecurityPkg/DxeImageVerificationLib: Set
> Action for failed signed image
> 
> If the image is signed but not allowed by DB and the hash of
> image is not found in DB/DBX, then the EFI_IMAGE_INFO_ACTION
> of the load of said image should be set to,
> EFI_IMAGE_EXECUTION_AUTH_SIG_NOT_FOUND, rather then being left
> unset as EFI_IMAGE_EXECUTION_AUTH_UNTESTED.
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Min Xu 
> 
> Signed-off-by: Joseph Hemann 
> Change-Id: I6b2777bd7aeb57773b8876e44c2179ea7501bc8c
> ---
>  .../Library/DxeImageVerificationLib/DxeImageVerificationLib.c| 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git
> a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
> b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
> index c48861cd6496..0a804af2162f 100644
> --- a/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
> +++ b/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c
> @@ -1957,6 +1957,7 @@ DxeImageVerificationHandler (
>if (!EFI_ERROR (DbStatus) && IsFound) {
>  IsVerified = TRUE;
>} else {
> +Action = EFI_IMAGE_EXECUTION_AUTH_SIG_NOT_FOUND;
>  DEBUG ((DEBUG_INFO, "DxeImageVerificationLib: Image is signed but
> signature is not allowed by DB and %s hash of image is not found in 
> DB/DBX.\n",
> mHashTypeStr));
>}
>  }
> --
> 2.17.1
> 
> 
> 
> 
> 



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

Re: [edk2-devel] [PATCH v2 1/1] ArmPkg: Implement PlatformBootManagerLib for LinuxBoot

[Samer El-Haj-Mahmoud]

Ackd-by:  Samer El-Haj-Mahmoud 

Any update on getting this reviewed/merged? We have downstream platforms that 
depend on this and would like to avoid duplication of similar functionality in 
platform code.

Thanks!
--Samer


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ard
> Biesheuvel via groups.io
> Sent: Wednesday, September 22, 2021 7:49 AM
> To: Nhi Pham 
> Cc: edk2-devel-groups-io ;
> patc...@amperecomputing.com; Leif Lindholm ; Ard
> Biesheuvel 
> Subject: Re: [edk2-devel] [PATCH v2 1/1] ArmPkg: Implement
> PlatformBootManagerLib for LinuxBoot
>
> On Tue, 7 Sept 2021 at 05:40, Nhi Pham 
> wrote:
> >
> > LinuxBoot is a firmware that replaces specific firmware functionality
> > like the UEFI DXE phase with a Linux kernel and runtime. It is built-in
> > UEFI image like an application, which is executed at the end of DXE
> > phase.
> >
> > To achieve the LinuxBoot boot flow "SEC->PEI->DXE->BDS->LinuxBoot",
> > today we use the common well-known GUID of UEFI Shell for LinuxBoot
> > payload, so LinuxBoot developers can effortlessly find the UEFI Shell
> > Application and replace it with the LinuxBoot payload without
> > recompiling platform EDK2 (There might be an issue with a few systems
> > that don't have a UEFI Shell). Also, we have a hard requirement to force
> > the BDS to boot into the LinuxBoot as it is essentially required that
> > only the LinuxBoot boot option is permissible and UEFI is an
> > intermediate bootstrap phase. Considering all the above, it is
> > reasonable to just have a new GUID for LinuxBoot and require a LinuxBoot
> > specific BDS implementation. In addition, with making the BDS
> > implementation simpler, we can reduce many DXE drivers which we think it
> > is not necessary for LinuxBoot booting.
> >
> > This patch adds a new PlatformBootManagerLib implementation which
> > registers only the gArmTokenSpaceGuid.PcdLinuxBootFileGuid for
> LinuxBoot
> > payload as an active boot option. It allows BDS to jump to the LinuxBoot
> > quickly by skipping the UiApp and UEFI Shell.
> >
> > The PlatformBootManagerLib library derived from
> > ArmPkg/Library/PlatformBootManagerLib.
> >
> > Cc: Leif Lindholm 
> > Cc: Ard Biesheuvel 
> >
> > Signed-off-by: Nhi Pham 
>
> Acked-by: Ard Biesheuvel 
>
> > ---
> >  ArmPkg/ArmPkg.dec  |   8 +
> >  ArmPkg/ArmPkg.dsc  |   2 +
> >  ArmPkg/Library/LinuxBootBootManagerLib/LinuxBootBootManagerLib.inf
> |  58 +++
> >  ArmPkg/Library/LinuxBootBootManagerLib/LinuxBootBm.c   | 178
> 
> >  4 files changed, 246 insertions(+)
> >
> > diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
> > index 214b2f589217..f68e6ee00860 100644
> > --- a/ArmPkg/ArmPkg.dec
> > +++ b/ArmPkg/ArmPkg.dec
> > @@ -3,6 +3,7 @@
> >  #
> >  # Copyright (c) 2009 - 2010, Apple Inc. All rights reserved.
> >  # Copyright (c) 2011 - 2021, ARM Limited. All rights reserved.
> > +# Copyright (c) 2021, Ampere Computing LLC. All rights reserved.
> >  #
> >  #SPDX-License-Identifier: BSD-2-Clause-Patent
> >  #
> > @@ -382,3 +383,10 @@ [PcdsFixedAtBuild.common,
> PcdsDynamic.common]
> >#
> >gArmTokenSpaceGuid.PcdPciBusMin|0x0|UINT32|0x0059
> >gArmTokenSpaceGuid.PcdPciBusMax|0x0|UINT32|0x005A
> > +
> > +[PcdsDynamicEx]
> > +  #
> > +  # This dynamic PCD hold the GUID of a firmware FFS which contains
> > +  # the LinuxBoot payload.
> > +  #
> > +  gArmTokenSpaceGuid.PcdLinuxBootFileGuid|{0x0}|VOID*|0x005C
> > diff --git a/ArmPkg/ArmPkg.dsc b/ArmPkg/ArmPkg.dsc
> > index 926986cf7fbb..ffb1c261861e 100644
> > --- a/ArmPkg/ArmPkg.dsc
> > +++ b/ArmPkg/ArmPkg.dsc
> > @@ -5,6 +5,7 @@
> >  # Copyright (c) 2011 - 2021, Arm Limited. All rights reserved.
> >  # Copyright (c) 2016, Linaro Ltd. All rights reserved.
> >  # Copyright (c) Microsoft Corporation.
> > +# Copyright (c) 2021, Ampere Computing LLC. All rights reserved.
> >  #
> >  #SPDX-License-Identifier: BSD-2-Clause-Patent
> >  #
> > @@ -150,6 +151,7 @@ [Components.common]
> >
> ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.inf
> >
> ArmPkg/Library/PeiServicesTablePointerLib/PeiServicesTablePointerLib.inf
> >ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> > +
> ArmPkg/Library/LinuxBootBootManagerLib/LinuxBootBootManagerLib.inf
> >
> >ArmPkg/Drivers/

Re: [edk2-devel] [edk2-rfc] [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64

[Samer El-Haj-Mahmoud]

Hello Leif,

>
> > > But it might be good to hear something from ARM whether the use of
> this
> > > protocol which "must be produced on any system with more than one
> logical processor"
> > > *should* be able to rely on anything being set up for it, or whether we
> > > need an aforementioned helper library.
> >
> > This statement (from the PI spec) is overly ambitious. I bet that it
> > does not hold true today on most DXE-based UEFI implementations on
> > other architectures, not just AARCH64. If we agree, I will file an
> > ECR to remove this statement from the PI spec.
>
> That feels like a weird response to the submission of a patch set
> adding the functionality for AArch64.
>
Agree this comment is not directly related to the RFC, and should be directed 
to the UEFI Forum instead, so please ignore my comment.


> >
> > From AARCH64 SBBR systems point of view:
> >
> >   *   The requirements from Arm SBBR point of view are around using
> >   PSCI to online/offline Secondary cores, and leaving them
> >   offlined before ReadyToBoot is signaled.
>
> SBBR is not relevant here. PI covers firmware internals, not OS
> boot compatibility.
>
> >   *   PI-based UEFI implementations are not required. And even when
> >   they are implemented, the EFI_MP_SERVICES_PROTOCOL is not
> >   required
>
> So ARM's strategy is to encourage people not to us it *in* PI
> implementations, even when it is portably implemented on top of PSCI?
>
Arm does not have any PI specific requirements on platform firmware, beyond 
what is in the PI spec itself.  Arm's official requirements are only on OS boot 
interoperability (SBBR).

For the RFC itself, I personally do not have any objection, and welcome the 
addition of this protocol to AARCH64, as long as it utilizes the PSCI services 
to achieve the OS boot requirements.

It may be worth getting feedback from Sami since he is the EDK2 maintainer for 
Arm platforms.



> Regards,
>
> Leif
>
> >   *   I agree with the analysis in this thread. EFI_MP
> >   implementations on AARCh64 need to be severely limited in the
> >   general case. Platforms (upstream or downstream) can still
> >   innovate and write their own code to run in these services as
> >   they wish.
>
> >
> >
> > Thanks,
> > --Samer
> >
> >
> >
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#81777): https://edk2.groups.io/g/devel/message/81777
Mute This Topic: https://groups.io/mt/86239012/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 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support for AARCH64

[Samer El-Haj-Mahmoud]

> In PI, the only references I find to the protocol are in MM and SAL protocols.
> And we're not even looking at EFI_MP_SERVICES_PPI at this point.

The PI 1.7 spec defined the EFI_MP_SERVICES_PROTOCOL in page 2-180, with the 
PPI and MM versions in 1-193 and 4-57 respectively.


> But it might be good to hear something from ARM whether the use of this
> protocol which "must be produced on any system with more than one logical 
> processor"
> *should* be able to rely on anything being set up for it, or whether we
> need an aforementioned helper library.

This statement (from the PI spec) is overly ambitious. I bet that it does not 
hold true today on most DXE-based UEFI implementations on other architectures, 
not just AARCH64. If we agree, I will file an ECR to remove this statement from 
the PI spec.

From AARCH64 SBBR systems point of view:

  *   The requirements from Arm SBBR point of view are around using PSCI to 
online/offline Secondary cores, and leaving them offlined before ReadyToBoot is 
signaled.
  *   PI-based UEFI implementations are not required. And even when they are 
implemented, the EFI_MP_SERVICES_PROTOCOL is not required
  *   I agree with the analysis in this thread. EFI_MP implementations on 
AARCh64 need to be severely limited in the general case. Platforms (upstream or 
downstream) can still innovate and write their own code to run in these 
services as they wish.


Thanks,
--Samer



From: Leif Lindholm 
Sent: Monday, October 11, 2021 8:28 AM
To: Ard Biesheuvel ; Samer El-Haj-Mahmoud 

Cc: Ard Biesheuvel ; Sami Mujawar 
; edk2-devel-groups-io ; Rebecca 
Cran ; Gerd Hoffmann ; edk2 RFC list 

Subject: Re: [RFC] [PATCH 0/2] Proposal to add EFI_MP_SERVICES_PROTOCOL support 
for AARCH64

+Samer

On Fri, Oct 8, 2021 at 3:51 PM Ard Biesheuvel 
mailto:a...@kernel.org>> wrote:
> > So either we severely constrain the kind of code that we permit to run
> > on other cores, or we enable the MMU and caches on each core as it
> > comes out of reset, as well as do any other CPU specific
> > initialization that we do for the primary core as well.
>
> The description for StartupAllAPs() has a note:
> It is the responsibility of the consumer of the
> EFI_MP_SERVICES_PROTOCOL.StartupAllAPs() to make sure that the nature
> of the code that is executed on the BSP and the dispatched APs is well
> controlled. The MP Services Protocol does not guarantee that the
> Procedure function is MP-safe. Hence, the tasks that can be run in
> parallel are limited to certain independent tasks and well-controlled
> exclusive code. EFI services and protocols may not be called by APs
> unless otherwise specified.
>
> So I think this is actually fine, implementation-wise. *Except* for
> the SwitchBSP function (where we're currently bailing out anyway).

Ok, so that doesn't look as bad as I thought. But we'll have to be
more strict than other arches: even EFI services and protocols that
are marked as safe for execution under this MP protocol are likely to
explode if they rely on CopyMem() or SetMem() for in/outputs that are
not a multiple of 8 bytes in case the platform uses the
BaseMemoryLibOptDxe flavour of this library, since it relies heavily
on deliberately misaligned loads and stores.

I think there is no way a protocol defined in the UEFI specification could be
safe to use by non-BSP. In PI, the only references I find to the protocol are
in MM and SAL protocols.
And we're not even looking at EFI_MP_SERVICES_PPI at this point.

But it might be good to hear something from ARM whether the use of this
protocol which "must be produced on any system with more than one logical 
processor"
*should* be able to rely on anything being set up for it, or whether we
need an aforementioned helper library.

/
Leif

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Fix ACPI memory aggregator/device type mismatch

[Samer El-Haj-Mahmoud]

We did investigate this in the BZ, and the conclusion was it is safer to update 
the code to match the spec. The only OS implementation we have seen so far is 
in Linux, and it uses the spec defined values (although for limited usage). See 
https://bugzilla.tianocore.org/show_bug.cgi?id=3579




> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of
> gaoliming via groups.io
> Sent: Thursday, October 7, 2021 9:26 PM
> To: devel@edk2.groups.io; Christopher Jones
> 
> Cc: michael.d.kin...@intel.com; zhiguang@intel.com; Sami Mujawar
> ; Ben Adderson ;
> Akanksha Jain ; Matteo Carlini
> ; nd 
> Subject: 回复: [edk2-devel] [PATCH v1 1/1] MdePkg: Fix ACPI memory
> aggregator/device type mismatch
> 
> Jones:
>   Do you know what impact will be introduced by this change?
> 
> Thanks
> Liming
> > -邮件原件-
> > 发件人: devel@edk2.groups.io  代表 Chris Jones
> > 发送时间: 2021年10月6日 18:12
> > 收件人: devel@edk2.groups.io
> > 抄送: michael.d.kin...@intel.com; gaolim...@byosoft.com.cn;
> > zhiguang@intel.com; sami.muja...@arm.com;
> ben.adder...@arm.com;
> > akanksha.ja...@arm.com; matteo.carl...@arm.com; n...@arm.com
> > 主题: [edk2-devel] [PATCH v1 1/1] MdePkg: Fix ACPI memory
> > aggregator/device type mismatch
> >
> > Bugzilla: 3578 (https://bugzilla.tianocore.org/show_bug.cgi?id=3579)
> >
> > Since the Common Memory Device (formerly Memory Aggregator Device)
> > was
> > introduced in ACPI 5.0, the edk2 type values have not matched the
> > values defined in the ACPI specification.
> >
> > Fix this discrepancy by aligning the code to match the specification.
> >
> > Signed-off-by: Chris Jones 
> > ---
> >  MdePkg/Include/IndustryStandard/Acpi50.h | 6 +++---
> >  MdePkg/Include/IndustryStandard/Acpi51.h | 6 +++---
> >  MdePkg/Include/IndustryStandard/Acpi60.h | 6 +++---
> >  MdePkg/Include/IndustryStandard/Acpi61.h | 6 +++---
> >  MdePkg/Include/IndustryStandard/Acpi62.h | 6 +++---
> >  MdePkg/Include/IndustryStandard/Acpi63.h | 6 +++---
> >  MdePkg/Include/IndustryStandard/Acpi64.h | 6 +++---
> >  7 files changed, 21 insertions(+), 21 deletions(-)
> >
> > diff --git a/MdePkg/Include/IndustryStandard/Acpi50.h
> > b/MdePkg/Include/IndustryStandard/Acpi50.h
> > index
> > 31a47e6a2c4276d5b1ad7b834af84844090b64c5..83d787c7650cf649fe3d2e1
> > 2e7983bae86a2a114 100644
> > --- a/MdePkg/Include/IndustryStandard/Acpi50.h
> > +++ b/MdePkg/Include/IndustryStandard/Acpi50.h
> > @@ -996,9 +996,9 @@ typedef struct {
> >  ///
> >  /// Memory Aggregator Device Type
> >  ///
> > -#define
> > EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
> > 0x1
> > -#define
> >
> EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
> > ONTROLLER 0x2
> > -#define
> > EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
> > 0x3
> > +#define
> > EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
> > 0x0
> > +#define
> >
> EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
> > ONTROLLER 0x1
> > +#define
> > EFI_ACPI_5_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
> > 0x2
> >
> >  ///
> >  /// Socket Memory Aggregator Device Structure.
> > diff --git a/MdePkg/Include/IndustryStandard/Acpi51.h
> > b/MdePkg/Include/IndustryStandard/Acpi51.h
> > index
> > fc28ffa18fc6a22e52fda88fade6ad80b2817cc3..5fbf7c99f1f7d6ca9109f198bd
> > 3f25f12bd47961 100644
> > --- a/MdePkg/Include/IndustryStandard/Acpi51.h
> > +++ b/MdePkg/Include/IndustryStandard/Acpi51.h
> > @@ -951,9 +951,9 @@ typedef struct {
> >  ///
> >  /// Memory Aggregator Device Type
> >  ///
> > -#define
> > EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
> > 0x1
> > -#define
> >
> EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
> > ONTROLLER 0x2
> > -#define
> > EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
> > 0x3
> > +#define
> > EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
> > 0x0
> > +#define
> >
> EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
> > ONTROLLER 0x1
> > +#define
> > EFI_ACPI_5_1_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
> > 0x2
> >
> >  ///
> >  /// Socket Memory Aggregator Device Structure.
> > diff --git a/MdePkg/Include/IndustryStandard/Acpi60.h
> > b/MdePkg/Include/IndustryStandard/Acpi60.h
> > index
> > 5dcd73b6f1ec4bccc7fdae7d56c2963ab58764f9..eba4248e1d5733d21973f0d
> > ac2286e02238a0aae 100644
> > --- a/MdePkg/Include/IndustryStandard/Acpi60.h
> > +++ b/MdePkg/Include/IndustryStandard/Acpi60.h
> > @@ -966,9 +966,9 @@ typedef struct {
> >  ///
> >  /// Memory Aggregator Device Type
> >  ///
> > -#define
> > EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
> > 0x1
> > -#define
> >
> EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
> > ONTROLLER 0x2
> > -#define
> > EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
> > 0x3
> > +#define
> > EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_SOCKET
> > 0x0
> > +#define
> >
> EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_MEMORY_C
> > ONTROLLER 0x1
> > +#define
> > EFI_ACPI_6_0_PMMT_MEMORY_AGGREGATOR_DEVICE_TYPE_DIMM
> > 0x2
> >
> >  ///
> >  /// Soc

Re: [edk2-devel] MOM // RE: TianoCore edk2-test Bug Triage Meeting

[Samer El-Haj-Mahmoud]

+edk2 devel list

From: G Edhaya Chandran 
Sent: Thursday, September 2, 2021 11:43 AM
To: Samer El-Haj-Mahmoud ; Heinrich Schuchardt 
; Gjertsen, Carolyn ; Sunny Wang 
; Mark Woods ; Grant Likely 
; Joseph Hemann ; Stuart Yoder 
; Jeremy Linton ; Paul Yang 
; Vincent Stehle ; Rob Herring 
; Dong Wei 
Cc: Barton Gao ; gaoliming ; 
'Hsiung, Harry L' ; 'Guptha, Soumya K' 
; 'Kinney, Michael D' ; 
heinrich.schucha...@canonical.com; Venkatesh, Supreeth 

Subject: MOM // RE: TianoCore edk2-test Bug Triage Meeting

Hello All,


Thank you all for attending the first edk2-test bug triage meeting.
Also thank you for the introductions, active participation and volunteering to 
take up resolution of the open issues.

We did cover lot of ground today! We discussed and dispositioned 14 out the 27 
open issues on BZ.
They are presented as [1] for your reference.

Other updates:
1. Consensus to have the Bug triage meeting as a monthly meeting.
2. The medium of the meeting to be changed to Zoom


Thanks and Regards,
Edhay & Barton





[1]
ID▼<https://bugzilla.tianocore.org/buglist.cgi?component=UEFI-SCT&list_id=23465&product=EDK2%20Test&query_format=advanced&resolution=---&order=bug_id&query_based_on=>
Product<https://bugzilla.tianocore.org/buglist.cgi?component=UEFI-SCT&list_id=23465&product=EDK2%20Test&query_format=advanced&resolution=---&order=product%2Cchangeddate%20DESC%2Cbug_id%20DESC&query_based_on=>
Comp<https://bugzilla.tianocore.org/buglist.cgi?component=UEFI-SCT&list_id=23465&product=EDK2%20Test&query_format=advanced&resolution=---&order=component%2Cchangeddate%20DESC%2Cbug_id%20DESC&query_based_on=>
Assignee<https://bugzilla.tianocore.org/buglist.cgi?component=UEFI-SCT&list_id=23465&product=EDK2%20Test&query_format=advanced&resolution=---&order=assigned_to%2Cchangeddate%20DESC%2Cbug_id%20DESC&query_based_on=>
Status<https://bugzilla.tianocore.org/buglist.cgi?component=UEFI-SCT&list_id=23465&product=EDK2%20Test&query_format=advanced&resolution=---&order=bug_status%2Cchangeddate%20DESC%2Cbug_id%20DESC&query_based_on=>
Resolution<https://bugzilla.tianocore.org/buglist.cgi?component=UEFI-SCT&list_id=23465&product=EDK2%20Test&query_format=advanced&resolution=---&order=resolution%2Cchangeddate%20DESC%2Cbug_id%20DESC&query_based_on=>
Summary<https://bugzilla.tianocore.org/buglist.cgi?component=UEFI-SCT&list_id=23465&product=EDK2%20Test&query_format=advanced&resolution=---&order=short_desc%2Cchangeddate%20DESC%2Cbug_id%20DESC&query_based_on=>
Changed▼<https://bugzilla.tianocore.org/buglist.cgi?component=UEFI-SCT&list_id=23465&product=EDK2%20Test&query_format=advanced&resolution=---&order=changeddate%2Cbug_id%20DESC&query_based_on=>
2284<https://bugzilla.tianocore.org/show_bug.cgi?id=2284>
EDK2 Tes
UEFI-SCT
edhaya.chand...@arm.com<mailto:edhaya.chand...@arm.com>
IN_P
---
MemoryAllocationServicesBBTestFunction - some MemType print value is not 
correct<https://bugzilla.tianocore.org/show_bug.cgi?id=2284>
11:23:54
2239<https://bugzilla.tianocore.org/show_bug.cgi?id=2239>
EDK2 Tes
UEFI-SCT
vincent.ste...@arm.com<mailto:vincent.ste...@arm.com>
CONF
---
UpdateInfoFileName() returns random bytes from 
stack<https://bugzilla.tianocore.org/show_bug.cgi?id=2239>
11:15:00
2650<https://bugzilla.tianocore.org/show_bug.cgi?id=2650>
EDK2 Tes
UEFI-SCT
xypron.g...@gmx.de<mailto:xypron.g...@gmx.de>
CONF
---
SCT2.7 "BootServicesTest\ImageServicesTest" Test 
Fail<https://bugzilla.tianocore.org/show_bug.cgi?id=2650>
11:13:34
2774<https://bugzilla.tianocore.org/show_bug.cgi?id=2774>
EDK2 Tes
UEFI-SCT
edhaya.chand...@arm.com<mailto:edhaya.chand...@arm.com>
CONF
---
BS.GetNextMonotonicCount - high 32 bit increase by 1 
FAILURE.<https://bugzilla.tianocore.org/show_bug.cgi?id=2774>
11:08:09
3082<https://bugzilla.tianocore.org/show_bug.cgi?id=3082>
EDK2 Tes
UEFI-SCT
edhaya.chand...@arm.com<mailto:edhaya.chand...@arm.com>
IN_P
---
[SCT] RecordAssertion function parameter 
issue.<https://bugzilla.tianocore.org/show_bug.cgi?id=3082>
11:07:38
3270<https://bugzilla.tianocore.org/show_bug.cgi?id=3270>
EDK2 Tes
UEFI-SCT
edhaya.chand...@arm.com<mailto:edhaya.chand...@arm.com>
CONF
---
uefi-sct: DevicePathFromText test for Uart() is too 
strict<https://bugzilla.tianocore.org/show_bug.cgi?id=3270>
11:06:31
2156<https://bugzilla.tianocore.org/show_bug.cgi?id=2156>
EDK2 Tes
UEFI-SCT
sunny.w...@arm.com<mailto:sunny.w...@arm.com>
CONF
---
CheckGloballyDefinedVariables() does not consider UEFI specification 
version<https://bugzilla.tianocore.org/show_bug.cgi?id=2156>
11:00:16
2238<https://bugzilla.tianocore.org/show_bug.cgi?id=2238>
EDK2 Tes

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platform/RaspberryPi/RPi4: Add _DSM ACPI method for 32-bit MMIO xHCI access

[Samer El-Haj-Mahmoud]

Wonderful! Thank you Pete!!

> -Original Message-
> From: Pete Batard 
> Sent: Wednesday, September 1, 2021 12:46 PM
> To: devel@edk2.groups.io
> Cc: ardb+tianoc...@kernel.org; l...@nuviainc.com; Samer El-Haj-Mahmoud
> 
> Subject: [edk2-platforms][PATCH 1/1] Platform/RaspberryPi/RPi4: Add _DSM
> ACPI method for 32-bit MMIO xHCI access
>
> With the upcoming release of Windows 11, Microsoft has introduced a new
> USB
> Device-Specific Method (_DSM) function to enforce 64-bit xHCI registers to
> be accessed through two sequential 32-bit requests. The new function
> (Query
> controller register access type - Function 6) is documented at:
> https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/usb-
> device-specific-method---dsm-
>
> Support for this feature is required on the raspberry Pi 4 where there is
> a bug/limitation in the xHCI stack that prevents full range 64-bit access
> from working correctly. It should be noted that an equivalent for this _DSM
> is not required on Linux, as 64-bit xHCI register access is already broken
> down into 2x32-bit by the drivers there.
>
> With this _DSM, and unlike what is the case for Windows 10, Windows 11 can
> now be installed on the Raspberry Pi 4 without having to alter any of the
> installation files, as we were able to validate using the latest Windows 11
> Build 22000 Insider image.
>
> Signed-off-by: Pete Batard 
> Tested-by: Pete Batard 
> ---
>  Platform/RaspberryPi/AcpiTables/Xhci.asl | 21 
>  1 file changed, 21 insertions(+)
>
> diff --git a/Platform/RaspberryPi/AcpiTables/Xhci.asl
> b/Platform/RaspberryPi/AcpiTables/Xhci.asl
> index 9b37277956d9..00b0cd29c69c 100644
> --- a/Platform/RaspberryPi/AcpiTables/Xhci.asl
> +++ b/Platform/RaspberryPi/AcpiTables/Xhci.asl
> @@ -138,6 +138,27 @@ DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN",
> "RPI4XHCI", 2)
>  Debug = "xHCI enable"
>
>  Store (0x6, CMND)
>
>  }
>
> +
>
> +/*
>
> + * Microsoft's USB Device-Specific Methods. See:
>
> + * https://docs.microsoft.com/en-us/windows-
> hardware/drivers/bringup/usb-device-specific-method---dsm-
>
> + */
>
> +Name (DSMU, ToUUID ("ce2ee385-00e6-48cb-9f05-2edb927c4899"))
>
> +
>
> +Method (_DSM, 4, Serialized) {
>
> +If (LEqual (Arg0, DSMU)) {  // USB capabilities UUID
>
> +Switch (ToInteger (Arg2)) {
>
> +Case (0) {  // Function 0: List of 
> supported functions
>
> +Return (Buffer () { 0x41 }) // 0x41 - Functions 0 
> and 6 supported
>
> +}
>
> +Case (6) {  // Function 6: 
> RegisterAccessType
>
> +Return (Buffer () { 0x01 }) // 0x01 - Must use 32bit 
> register
> access
>
> +}
>
> +Default { } // Unsupported
>
> +}
>
> +}
>
> +return (Buffer () { 0x00 }) // Return 0x00 for 
> anything
> unsupported
>
> +}
>
>} // end XHC0
>
>  } //end SCB0
>
>} //end scope sb
>
> --
> 2.30.2.windows.1

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [RFC] Expose HII package list via C variables

[Samer El-Haj-Mahmoud]

I am aware of some proprietary tools (not open source) that depend on this 
functionality.

The feature has been used, especially on some server designs, to allow 
exporting HII packages and consuming them offline by out-of-band or OS-based 
management applications for instance. The need for this seems to be declining 
though, as implementations move to using standard Redfish data instead, which 
in turn can be produced from HII packages, either during boot (like what is 
done in EDK2 RedfishPkg), or at build / release time.

Thanks,
--Samer


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Marvin
> Häuser via groups.io
> Sent: Thursday, August 26, 2021 12:07 PM
> To: tim.le...@insyde.com; devel@edk2.groups.io;
> michael.d.kin...@intel.com
> Cc: 'Andrew Fish' ; l...@nuviainc.com; 'Ni, Ray'
> ; 'Gao, Zhichao' ; 'Wang, Jian J'
> ; 'Wu, Hao A' ; 'Bi, Dandan'
> ; 'Dong, Eric' ; 'Bret Barkelew'
> ; 'Vitaly Cheptsov'
> 
> Subject: Re: [edk2-devel] [RFC] Expose HII package list via C variables
>
> Hey Tim,
>
> Interesting, do you happen to have some tool or code that performs such
> edits at hand to take a look at? Seems like most modules already use
> variables and thus cannot be modified in such a way even right now?
>
> That's the kind of information I am looking for, thanks a lot!
>
> Best regards,
> Marvin
>
> On 26/08/2021 18:01, tim.le...@insyde.com wrote:
> > Hi Marvin --
> >
> > I would like to add some historical perspective on this. One of the design
> requirements back when HII was first introduced into the UEFI specification
> after Intel's initial contribution was that of binary editability. In order 
> to be
> able to reliably find, extract and then re-insert the HII data into the 
> binary, it
> needed to be discoverable and not affect the offsets of the code and data in
> the binary.
> >
> > While it was possible to put some sort of signature in the read-only data
> sections of the binary and leave padding for possible future edits, it was 
> felt
> that using a PE/COFF section similar to the resource sections was better.
> Resource sections are commonly in use for PE/COFF files (in Windows) and
> the similar idea existed in the then-extant Mac binary format (resource
> fork?).
> >
> > Thanks,
> >
> > Tim Lewis
> > CTO, Insyde Software
> > www.insyde.com
> >
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of
> Michael D Kinney
> > Sent: Thursday, August 26, 2021 7:37 AM
> > To: devel@edk2.groups.io; mhaeu...@posteo.de; Kinney, Michael D
> 
> > Cc: Andrew Fish ; l...@nuviainc.com; Ni, Ray
> ; Gao, Zhichao ; Wang, Jian J
> ; Wu, Hao A ; Bi, Dandan
> ; Dong, Eric ; Bret Barkelew
> ; Vitaly Cheptsov
> 
> > Subject: Re: [edk2-devel] [RFC] Expose HII package list via C variables
> >
> > Marvin,
> >
> > One constraint in this discussion is that the HII content in a PE/COFF
> resource section is defined in the UEFI Specification, Which means UEFI Apps
> and UEFI Drivers from media and option ROMs that are not part of the
> system FW image are allowed to use this feature,  This means the system FW
> PE/COFF loader must support loading HII content from this PE/COFF resource
> section to be UEFI conformant.  So we cannot remove this feature from the
> PE/COFF loader without changes to the UEFI Specification.  Even if changes to
> the UEFI Specification we made, we would have to continue to support this
> feature for backward compatibility with existing UEFI Apps/Drivers that may
> be using this feature.
> >
> > Thanks,
> >
> > Mike
> >
> >> -Original Message-
> >> From: devel@edk2.groups.io  On Behalf Of
> Marvin
> >> Häuser
> >> Sent: Thursday, August 26, 2021 1:51 AM
> >> To: devel@edk2.groups.io; Kinney, Michael D
> >> 
> >> Cc: devel@edk2.groups.io; Andrew Fish ;
> >> l...@nuviainc.com; Ni, Ray ; Gao, Zhichao
> >> ; Wang, Jian J ; Wu,
> Hao
> >> A ; Bi, Dandan ; Dong, Eric
> >> ; Bret Barkelew ;
> >> Vitaly Cheptsov 
> >> Subject: Re: [edk2-devel] [RFC] Expose HII package list via C
> >> variables
> >>
> >> Hey Mike,
> >>
> >> Thanks for your reply!
> >>
> >> Well, this switch is not well-documented. Looking now at both the
> >> generation code and the emitted code, it does not generate a package
> >> list like my code does, but separate data variables (strings and
> >> images) that cannot easily be passed to HiiDatabase as-is. However
> >> apparently there are drivers that use this functionality successfully
> >> by composing the package list at runtime [1].
> >>
> >> Looking with this information now at the pattern of using HII C
> >> variables (which I did not know existed before) vs the PE/COFF HII
> >> section, most that use latter are Shell applications, which I guess
> >> means the section has actually been introduced to resolve D.? There
> >> are exceptions such as LogoDxe [2], which use the PE/COFF section while
> D.
> >> is not a problem, hence I got confused, sorry. I think these modules
> >> should be updated in any case. Do you agree?

Re: [edk2-devel] [PATCH v3 6/7] Platform/RaspberryPi: Enable NVMe boot on CM4

[Samer El-Haj-Mahmoud]

Reviewed-By: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Jeremy Linton 
> Sent: Friday, August 20, 2021 12:16 AM
> To: devel@edk2.groups.io
> Cc: p...@akeo.ie; ardb+tianoc...@kernel.org; Andrei Warkentin
> (awarken...@vmware.com) ; Sunny Wang
> ; Samer El-Haj-Mahmoud  mahm...@arm.com>; Jeremy Linton 
> Subject: [PATCH v3 6/7] Platform/RaspberryPi: Enable NVMe boot on CM4
>
> The CM4 has a number of carrier boards with PCIe
> slots. With the PCIe changes in place its quite
> possible to utilize a NVMe root device. Lets allow
> people to boot from it.
>
> Reviewed-by: Andrei Warkentin 
> Signed-off-by: Jeremy Linton 
> ---
>  Platform/RaspberryPi/RPi4/RPi4.dsc | 5 +
>  Platform/RaspberryPi/RPi4/RPi4.fdf | 5 +
>  2 files changed, 10 insertions(+)
>
> diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc
> b/Platform/RaspberryPi/RPi4/RPi4.dsc
> index babcbb2f41..25c29a0fbf 100644
> --- a/Platform/RaspberryPi/RPi4/RPi4.dsc
> +++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
> @@ -754,6 +754,11 @@
>}
>
>#
> +  # NVMe boot devices
> +  #
> +  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
> +
> +  #
># UEFI application (Shell Embedded Boot Loader)
>#
>ShellPkg/Application/Shell/Shell.inf {
> diff --git a/Platform/RaspberryPi/RPi4/RPi4.fdf
> b/Platform/RaspberryPi/RPi4/RPi4.fdf
> index 3534cd3dc3..0c782d2f35 100644
> --- a/Platform/RaspberryPi/RPi4/RPi4.fdf
> +++ b/Platform/RaspberryPi/RPi4/RPi4.fdf
> @@ -283,6 +283,11 @@ READ_LOCK_STATUS   = TRUE
>INF
> EmbeddedPkg/Drivers/NonCoherentIoMmuDxe/NonCoherentIoMmuDxe.i
> nf
>
>#
> +  # NVMe boot devices
> +  #
> +  INF MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
> +
> +  #
># SCSI Bus and Disk Driver
>#
>INF MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
> --
> 2.13.7

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH v3 7/7] Platform/RaspberryPi: Add Linux quirk support

[Samer El-Haj-Mahmoud]

Reviewed-By: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Jeremy Linton 
> Sent: Friday, August 20, 2021 12:16 AM
> To: devel@edk2.groups.io
> Cc: p...@akeo.ie; ardb+tianoc...@kernel.org; Andrei Warkentin
> (awarken...@vmware.com) ; Sunny Wang
> ; Samer El-Haj-Mahmoud  mahm...@arm.com>; Jeremy Linton 
> Subject: [PATCH v3 7/7] Platform/RaspberryPi: Add Linux quirk support
>
> Linux, for the time being has refused to support the Arm
> standard SMCCC for PCIe configuration. Instead they
> want to continue to maintain per device "quirks".
>
> As the RPI isn't really ECAM this is a bit more
> involved because the MCFG can't really describe
> the root port+config registers situation. Further
> platforms which support the SMCCC shouldn't have
> a MCFG, so we need an additional way to tell linux
> what it needs to know about this platform.
>
> Signed-off-by: Jeremy Linton 
> ---
>  Platform/RaspberryPi/AcpiTables/Pci.asl | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/Platform/RaspberryPi/AcpiTables/Pci.asl
> b/Platform/RaspberryPi/AcpiTables/Pci.asl
> index dc2bd7bc9e..50fe2cbdf2 100644
> --- a/Platform/RaspberryPi/AcpiTables/Pci.asl
> +++ b/Platform/RaspberryPi/AcpiTables/Pci.asl
> @@ -62,6 +62,13 @@ DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN",
> "RPI4PCIE", 2)
>  Package (4) { 0x, 3, zero, 178 }
>})
>
> +  Name (_DSD, Package () {
> +ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> +  Package () {
> +Package () { "linux-ecam-quirk-id", "bcm2711" },
> +  }
> +  })
> +
>// Root complex resources
>Method (_CRS, 0, Serialized) {
>  Name (RBUF, ResourceTemplate () {
> --
> 2.13.7

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH v3 1/7] Platform/RaspberryPi: Add XHCI/PCI selection menu

[Samer El-Haj-Mahmoud]

One feedback is to add the new HII setting to the README. Otherwise, looks good!

Reviewed-By: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Jeremy Linton 
> Sent: Friday, August 20, 2021 12:16 AM
> To: devel@edk2.groups.io
> Cc: p...@akeo.ie; ardb+tianoc...@kernel.org; Andrei Warkentin
> (awarken...@vmware.com) ; Sunny Wang
> ; Samer El-Haj-Mahmoud  mahm...@arm.com>; Jeremy Linton 
> Subject: [PATCH v3 1/7] Platform/RaspberryPi: Add XHCI/PCI selection menu
>
> Arm has standardized a PCI SMC conduit that can be used
> to access the PCI config space in a standardized way. This
> functionality doesn't yet exist in many OS/Distro's. Lets
> add another advanced config item that allows the user
> to toggle between presenting the XHCI on the base RPi4
> as a platform device, or presenting this newer PCIe
> conduit. The CM4 doesn't have an attached XHCI controller
> soldered to the PCIe, so PCIe mode is the default.
>
> Signed-off-by: Jeremy Linton 
> ---
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 42
> ++
>  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|  1 +
>  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |  5 +++
>  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 17 +
>  Platform/RaspberryPi/Include/ConfigVars.h  |  4 +++
>  Platform/RaspberryPi/RPi3/RPi3.dsc |  6 
>  Platform/RaspberryPi/RPi4/RPi4.dsc |  8 +
>  Platform/RaspberryPi/RaspberryPi.dec   |  1 +
>  8 files changed, 84 insertions(+)
>
> diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> index 9e78cb47ad..87f6b4e7bb 100644
> --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> +++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> @@ -43,6 +43,7 @@ extern UINT8 ConfigDxeStrings[];
>  STATIC RASPBERRY_PI_FIRMWARE_PROTOCOL *mFwProtocol;
>  STATIC UINT32 mModelFamily = 0;
>  STATIC UINT32 mModelInstalledMB = 0;
> +STATIC UINT32 mModelRevision = 0;
>
>  STATIC EFI_MAC_ADDRESS  mMacAddress;
>
> @@ -271,6 +272,40 @@ SetupVariables (
>  ASSERT_EFI_ERROR (Status);
>}
>
> +  if (mModelFamily >= 4) {
> +if (((mModelRevision >> 4) & 0xFF) == 0x14) {
> +  /*
> +   * Enable PCIe by default on CM4
> +   */
> +  Status = PcdSet32S (PcdXhciPci, 2);
> +  ASSERT_EFI_ERROR (Status);
> +} else {
> +  Size = sizeof (UINT32);
> +  Status = gRT->GetVariable (L"XhciPci",
> + &gConfigDxeFormSetGuid,
> + NULL, &Size, &Var32);
> +  if (EFI_ERROR (Status) || (Var32 == 0)) {
> +/*
> + * Enable XHCI by default
> + */
> +Status = PcdSet32S (PcdXhciPci, 0);
> +ASSERT_EFI_ERROR (Status);
> +  } else {
> +/*
> + * Enable PCIe
> + */
> +Status = PcdSet32S (PcdXhciPci, 1);
> +ASSERT_EFI_ERROR (Status);
> +  }
> +}
> +  } else {
> +/*
> + * Disable PCIe and XHCI
> + */
> +Status = PcdSet32S (PcdXhciPci, 0);
> +ASSERT_EFI_ERROR (Status);
> +  }
> +
>Size = sizeof (AssetTagVar);
>Status = gRT->GetVariable (L"AssetTag",
>&gConfigDxeFormSetGuid,
> @@ -888,6 +923,13 @@ ConfigInitialize (
>  DEBUG ((DEBUG_INFO, "Current Raspberry Pi installed RAM size is %d MB\n",
> mModelInstalledMB));
>}
>
> +  Status = mFwProtocol->GetModelRevision (&mModelRevision);
> +  if (Status != EFI_SUCCESS) {
> +DEBUG ((DEBUG_ERROR, "Couldn't get the Raspberry Pi revision: %r\n",
> Status));
> +  } else {
> +DEBUG ((DEBUG_INFO, "Current Raspberry Pi revision %x\n",
> mModelRevision));
> +  }
> +
>Status = SetupVariables ();
>if (Status != EFI_SUCCESS) {
>  DEBUG ((DEBUG_ERROR, "Couldn't not setup NV vars: %r\n", Status));
> diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> index 4bb2d08550..e6e22ad82e 100644
> --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> +++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> @@ -94,6 +94,7 @@
>gRaspberryPiTokenSpaceGuid.PcdFanOnGpio
>gRaspberryPiTokenSpaceGuid.PcdFanTemp
>gRaspberryPiTokenSpaceGuid.PcdUartInUse
> +  gRaspberryPiTokenSpaceGuid.PcdXhciPci
>
>  [Depex]
>gPcdProtocolGuid AND gRaspberryPiFirmwareProtocolGuid
> diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
> b/Platform

Re: [edk2-devel] [PATCH v3 0/7] RPi4: Enable ACPI PCIe conduit

[Samer El-Haj-Mahmoud]

+Jared to review/test the series with NetBSD 10, which supports the DEN0115 
interface (https://www.netbsd.org/changes/changes-10.0.html#port-evbarm)



> -Original Message-
> From: Jeremy Linton 
> Sent: Friday, August 20, 2021 12:16 AM
> To: devel@edk2.groups.io
> Cc: p...@akeo.ie; ardb+tianoc...@kernel.org; Andrei Warkentin
> (awarken...@vmware.com) ; Sunny Wang
> ; Samer El-Haj-Mahmoud  mahm...@arm.com>; Jeremy Linton 
> Subject: [PATCH v3 0/7] RPi4: Enable ACPI PCIe conduit
>
> A new Arm standard DEN0115A specifies how platforms that don't have
> standard ECAM can use the firmware to handle config read/write
> operations. This is mostly implemented in TFA but UEFI needs to assure
> that there is a description of the root complex in the ACPI namespace.
>
> This set adds that description based on a new menu item which toggles
> between XHCI platform description and PCIe via a BDS menu selection on
> the RPi4. The CM4 is really the platform that needs this as it has a
> PCIe slot. On that platform PCIe is enabled by default.
>
> v2->v3:
> Remove ACPI0004 container around PCI root bridge along with some
> whitespace/tweaks to the Pci.asl file.
> Add Linux quirk _DSD patch at the end.
>
> v1->v2:
> Use global shared interrupts in PCI PRT which is a pretty
> significant simplification.
> Modify bus max to use the secondary side of the root port for
> enforcing device limits
> Various other AML cleanups per Ard (drop redundant _DMA, bump UID
> to make it unique, etc)
> Break link status move into its own patch
> MADT->MCFG typos in various comments
> Commit message tweaking
>
> Jeremy Linton (7):
>   Platform/RaspberryPi: Add XHCI/PCI selection menu
>   Platform/RaspberryPi: Break XHCI into its own SSDT
>   Platform/RaspberryPi: Add PCIe SSDT
>   Silicon/Broadcom/Bcm27xx: Relax PCIe device restriction
>   Silicon/Broadcom/Bcm27xx: Move linkup check into the cfg accessor
>   Platform/RaspberryPi: Enable NVMe boot on CM4
>   Platform/RaspberryPi: Add Linux quirk support
>
>  Platform/RaspberryPi/AcpiTables/AcpiTables.inf |   4 +
>  Platform/RaspberryPi/AcpiTables/Dsdt.asl   |   3 -
>  Platform/RaspberryPi/AcpiTables/Pci.asl| 168
> +
>  Platform/RaspberryPi/AcpiTables/Xhci.asl   |  35 +++--
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |  56 +++
>  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf|   1 +
>  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni |   5 +
>  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr |  17 +++
>  Platform/RaspberryPi/Include/ConfigVars.h  |   4 +
>  Platform/RaspberryPi/RPi3/RPi3.dsc |   6 +
>  Platform/RaspberryPi/RPi4/RPi4.dsc |  13 ++
>  Platform/RaspberryPi/RPi4/RPi4.fdf |   5 +
>  Platform/RaspberryPi/RaspberryPi.dec   |   1 +
>  .../Bcm2711PciHostBridgeLibConstructor.c   |   5 -
>  .../Library/Bcm2711PciSegmentLib/PciSegmentLib.c   |  28 +++-
>  15 files changed, 323 insertions(+), 28 deletions(-)
>  create mode 100644 Platform/RaspberryPi/AcpiTables/Pci.asl
>
> --
> 2.13.7

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [edk2-test] [PATCH v1 1/1] uefi-sct: Propose maintainers from AMD

[Samer El-Haj-Mahmoud]

Thanks Supreeth and Carolyn. It is nice to see AMD step up to help with SCT !

Reviewed-By: Samer El-Haj-Mahmoud 
samer.el-haj-mahm...@arm.com<mailto:samer.el-haj-mahm...@arm.com>





From: devel@edk2.groups.io  on behalf of Supreeth 
Venkatesh via groups.io 
Sent: Thursday, August 19, 2021 2:50:42 PM
To: devel@edk2.groups.io 
Cc: carolyn.gjert...@amd.com ; Supreeth Venkatesh 

Subject: [edk2-devel] [edk2-test] [PATCH v1 1/1] uefi-sct: Propose maintainers 
from AMD

This patch proposes Carolyn Gjertsen as maintainer of edk2-test
repository and Supreeth Venkatesh as reviewer from AMD.

Signed-off-by: Supreeth Venkatesh 
---
 uefi-sct/Maintainers.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/uefi-sct/Maintainers.txt b/uefi-sct/Maintainers.txt
index c93b83ec..a94255f0 100644
--- a/uefi-sct/Maintainers.txt
+++ b/uefi-sct/Maintainers.txt
@@ -41,10 +41,12 @@ UEFI-SCT:

 M: G Edhaya Chandran 
 M: Barton Gao 
+M: Carolyn Gjertsen 

 R: Samer El-Haj-Mahmoud 
 R: Eric Jin 
 R: Arvin Chen 
+R: Supreeth Venkatesh 

 General questions on UEFI-SCT with the subject [edk2-test] can be sent to
 L: edk2-devel 
--
2.25.1





IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79644): https://edk2.groups.io/g/devel/message/79644
Mute This Topic: https://groups.io/mt/85009511/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 v2] ArmPkg: Enable boot discovery policy for ARM package.

[Samer El-Haj-Mahmoud]

+ Sami for ArmPkg review

> -Original Message-
> From: Grzegorz Bernacki 
> Sent: Monday, August 16, 2021 6:09 AM
> To: devel@edk2.groups.io
> Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud
> ; Sunny Wang
> ; m...@semihalf.com; upstr...@semihalf.com;
> Grzegorz Bernacki 
> Subject: [edk2-platforms PATCH v2] ArmPkg: Enable boot discovery policy for
> ARM package.
>
> This commit adds code which check BootDiscoveryPolicy variable and
> calls Boot Policy Manager Protocol to connect device specified by
> the variable. To enable that mechanism for platform
> EfiMdeModulePkgTokenSpaceGuid.PcdBootDiscoveryPolicy PCD must be
> added to DSC file and BootDiscoveryPolicyUiLib should be added to
> UiApp libraries.
>
> Signed-off-by: Grzegorz Bernacki 
> ---
>  ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |  5
> +
>  ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c   | 96
> +++-
>  2 files changed, 100 insertions(+), 1 deletion(-)
>
> diff --git
> a/ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> b/ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> index 353d7a967b..86751b45f8 100644
> --- a/ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> +++
> b/ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> @@ -65,11 +65,15 @@
>
>  [Pcd]
>gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdBootDiscoveryPolicy
>
>  [Guids]
> +  gBootDiscoveryPolicyMgrFormsetGuid
>gEdkiiNonDiscoverableEhciDeviceGuid
>gEdkiiNonDiscoverableUhciDeviceGuid
>gEdkiiNonDiscoverableXhciDeviceGuid
> +  gEfiBootManagerPolicyNetworkGuid
> +  gEfiBootManagerPolicyConnectAllGuid
>gEfiFileInfoGuid
>gEfiFileSystemInfoGuid
>gEfiFileSystemVolumeLabelInfoIdGuid
> @@ -79,6 +83,7 @@
>
>  [Protocols]
>gEdkiiNonDiscoverableDeviceProtocolGuid
> +  gEfiBootManagerPolicyProtocolGuid
>gEfiDevicePathProtocolGuid
>gEfiGraphicsOutputProtocolGuid
>gEfiLoadedImageProtocolGuid
> diff --git a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> index 5ceb23d822..ef5c323743 100644
> --- a/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> +++ b/ArmPkg/Library/PlatformBootManagerLib/PlatformBm.c
> @@ -2,9 +2,10 @@
>Implementation for PlatformBootManagerLib library class interfaces.
>
>Copyright (C) 2015-2016, Red Hat, Inc.
> -  Copyright (c) 2014 - 2019, ARM Ltd. All rights reserved.
> +  Copyright (c) 2014 - 2021, ARM Ltd. All rights reserved.
>Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
>Copyright (c) 2016, Linaro Ltd. All rights reserved.
> +  Copyright (c) 2021, Semihalf All rights reserved.
>
>SPDX-License-Identifier: BSD-2-Clause-Patent
>
> @@ -19,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -27,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -703,6 +706,91 @@ HandleCapsules (
>
>  #define VERSION_STRING_PREFIXL"Tianocore/EDK2 firmware version "
>
> +/**
> +  This functions checks the value of BootDiscoverPolicy variable and
> +  connect devices of class specified by that variable. Then it refreshes
> +  Boot order for newly discovered boot device.
> +
> +  @retval  EFI_SUCCESS  Devices connected successfully or connection
> +not required.
> +  @retval  others   Return values from GetVariable(), LocateProtocol()
> +and ConnectDeviceClass().
> +**/
> +STATIC
> +EFI_STATUS
> +BootDiscoveryPolicyHandler (
> +  VOID
> +  )
> +{
> +  EFI_STATUS   Status;
> +  UINT32   DiscoveryPolicy;
> +  UINTNSize;
> +  EFI_BOOT_MANAGER_POLICY_PROTOCOL *BMPolicy;
> +  EFI_GUID *Class;
> +
> +  Size = sizeof (DiscoveryPolicy);
> +  Status = gRT->GetVariable (
> +  BOOT_DISCOVERY_POLICY_VAR,
> +  &gBootDiscoveryPolicyMgrFormsetGuid,
> +  NULL,
> +  &Size,
> +  &DiscoveryPolicy
> +  );
> +  if (Status == EFI_NOT_FOUND) {
> +Status = PcdSet32S (PcdBootDiscoveryPolicy, PcdGet32
> (PcdBootDiscoveryPolicy));
> +if (Status == EFI_NOT_FOUND) {
> +  return EFI_SUCCESS;
> +} else if (EFI_ERROR (Status)) {
> +  return Status;
> +}
> +DiscoveryPolicy = PcdGet32 (PcdB

Re: [edk2-devel] [PATCH] MdeModulePkg: Add BootDiscoveryPolicyOld variable.

[Samer El-Haj-Mahmoud]

Reviewed-By: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Grzegorz Bernacki 
> Sent: Wednesday, August 18, 2021 3:36 AM
> To: devel@edk2.groups.io
> Cc: jian.j.w...@intel.com; hao.a...@intel.com; Samer El-Haj-Mahmoud
> ; Sunny Wang
> ; m...@semihalf.com; upstr...@semihalf.com;
> Grzegorz Bernacki 
> Subject: [PATCH] MdeModulePkg: Add BootDiscoveryPolicyOld variable.
>
> This variable is needed to track the change to
> BootDiscoveryPolicy variable. Boot options should
> be refreshed only if BootDiscoveryPolicy has been
> changed.
>
> Signed-off-by: Grzegorz Bernacki 
> ---
>  MdeModulePkg/Include/Guid/BootDiscoveryPolicy.h | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/MdeModulePkg/Include/Guid/BootDiscoveryPolicy.h
> b/MdeModulePkg/Include/Guid/BootDiscoveryPolicy.h
> index 06e38921a0..f4e3b03ba1 100644
> --- a/MdeModulePkg/Include/Guid/BootDiscoveryPolicy.h
> +++ b/MdeModulePkg/Include/Guid/BootDiscoveryPolicy.h
> @@ -18,5 +18,6 @@
>  #define BOOT_DISCOVERY_POLICY_MGR_FORMSET_GUID  { 0x5b6f7107,
> 0xbb3c, 0x4660, { 0x92, 0xcd, 0x54, 0x26, 0x90, 0x28, 0x0b, 0xbd } }
>
>
>
>  #define BOOT_DISCOVERY_POLICY_VAR L"BootDiscoveryPolicy"
>
> +#define BOOT_DISCOVERY_POLICY_OLD_VAR L"BootDiscoveryPolicyOld"
>
>
>
>  #endif
>
> --
> 2.25.1

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79510): https://edk2.groups.io/g/devel/message/79510
Mute This Topic: https://groups.io/mt/84967542/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] Platform/RaspberryPi: Check for Boot Discovery Policy change.

[Samer El-Haj-Mahmoud]

Thanks for the patch!

Reviewed-By: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Grzegorz Bernacki 
> Sent: Wednesday, August 18, 2021 3:38 AM
> To: devel@edk2.groups.io
> Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud
> ; Sunny Wang
> ; m...@semihalf.com; upstr...@semihalf.com;
> p...@akeo.ie; Grzegorz Bernacki 
> Subject: [edk2-platforms PATCH] Platform/RaspberryPi: Check for Boot
> Discovery Policy change.
>
> This patch adds checks if Boot Discovery Policy has been
> changed. Only in that case EfiBootManagerRefreshAllBootOption()
> should be called.
>
> Signed-off-by: Grzegorz Bernacki 
> ---
>  Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c | 24
> +++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git
> a/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c
> b/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c
> index c8305ce4f5..378ba0ebf4 100644
> --- a/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c
> +++ b/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c
> @@ -617,6 +617,7 @@ BootDiscoveryPolicyHandler (
>  {
>EFI_STATUS   Status;
>UINT32   DiscoveryPolicy;
> +  UINT32   DiscoveryPolicyOld;
>UINTNSize;
>EFI_BOOT_MANAGER_POLICY_PROTOCOL *BMPolicy;
>EFI_GUID *Class;
> @@ -678,7 +679,28 @@ BootDiscoveryPolicyHandler (
>  return Status;
>}
>
> -  EfiBootManagerRefreshAllBootOption();
> +  //
> +  // Refresh Boot Options if Boot Discovery Policy has been changed
> +  //
> +  Size = sizeof (DiscoveryPolicyOld);
> +  Status = gRT->GetVariable (
> +  BOOT_DISCOVERY_POLICY_OLD_VAR,
> +  &gBootDiscoveryPolicyMgrFormsetGuid,
> +  NULL,
> +  &Size,
> +  &DiscoveryPolicyOld
> +  );
> +  if ((Status == EFI_NOT_FOUND) || (DiscoveryPolicyOld != DiscoveryPolicy))
> {
> +EfiBootManagerRefreshAllBootOption();
> +
> +Status = gRT->SetVariable (
> +BOOT_DISCOVERY_POLICY_OLD_VAR,
> +&gBootDiscoveryPolicyMgrFormsetGuid,
> +EFI_VARIABLE_NON_VOLATILE |
> EFI_VARIABLE_BOOTSERVICE_ACCESS,
> +sizeof (DiscoveryPolicyOld),
> +&DiscoveryPolicy
> +);
> +  }
>
>return EFI_SUCCESS;
>  }
> --
> 2.25.1

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79509): https://edk2.groups.io/g/devel/message/79509
Mute This Topic: https://groups.io/mt/84967553/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] Platform/RaspberryPi: Remove unnecessary files

[Samer El-Haj-Mahmoud]

Thanks!

Reviewed-by: Samer El-Haj-Mahmoud 


> -Original Message-
> From: Marcin Wojtas 
> Sent: Friday, August 13, 2021 10:42 AM
> To: devel@edk2.groups.io
> Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud
> ; Sunny Wang
> ; g...@semihalf.com; upstr...@semihalf.com;
> p...@akeo.ie; Marcin Wojtas 
> Subject: [edk2-platforms PATCH] Platform/RaspberryPi: Remove
> unnecessary files
>
> Commit 2f0188b56ef4 ("Revert "Platform/RaspberryPi: Setup option for...")
> mistakenly introduced to files which are residues from a
> conflict resolution. Fix that.
>
> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/RaspberryPi/RPi4/RPi4.dsc.orig | 760 
>  Platform/RaspberryPi/RPi4/RPi4.dsc.rej  |  29 -
>  2 files changed, 789 deletions(-)
>  delete mode 100644 Platform/RaspberryPi/RPi4/RPi4.dsc.orig
>  delete mode 100644 Platform/RaspberryPi/RPi4/RPi4.dsc.rej
>
> diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc.orig
> b/Platform/RaspberryPi/RPi4/RPi4.dsc.orig
> deleted file mode 100644
> index 2c05c31118..00
> --- a/Platform/RaspberryPi/RPi4/RPi4.dsc.orig
> +++ /dev/null
> @@ -1,760 +0,0 @@
> -# @file
>
> -#
>
> -#  Copyright (c) 2011 - 2020, ARM Limited. All rights reserved.
>
> -#  Copyright (c) 2017 - 2018, Andrei Warkentin
> 
>
> -#  Copyright (c) 2015 - 2021, 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
>
> -
>
> -  #
>
> -  # 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
>
> -
>
> -!ifndef TFA_BUILD_ARTIFACTS
>
> -  #
>
> -  # Default TF-A binary checked into edk2-non-osi.
>
> -  #
>
> -  DEFINE TFA_BUILD_BL31 =
> Platform/RaspberryPi/$(PLATFORM_NAME)/TrustedFirmware/bl31.bin
>
> -!else
>
> -  #
>
> -  # Usually we use the checked-in binaries, but for developers working
>
> -  # on the firmware, being able to use a local TF-A build without extra copy
>
> -  # operations ends up being very helpful.
>
> -  #
>
> -  DEFINE TFA_BUILD_BL31 = $(TFA_BUILD_ARTIFACTS)/bl31.bin
>
> -!endif
>
> -
>
> -
> ##
> ##
>
> -#
>
> -# Library Class section - list of all Library Classes needed by this 
> Platform.
>
> -#
>
> -
> ##
> ##
>
> -
>
> -!include MdePkg/MdeLibs.dsc.inc
>
> -
>
> -[LibraryClasses.common]
>
> -!if $(TARGET) == RELEASE
>
> -  DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
>
> -!else
>
> -
> DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.
> inf
>
> -!endif
>
> -
> DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/Bas
> eDebugPrintErrorLevelLib.inf
>
> -
>
> -  BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
>
> -  SafeIntLib|MdePkg/Library/BaseSafeIntLib/BaseSafeIntLib.inf
>
> -
> BmpSupportLib|MdeModulePkg/Library/BaseBmpSupportLib/BaseBmpSupp
> ortLib.inf
>
> -
> SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchroniz
> ationLib.inf
>
> -
> PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanc
> eLibNull.inf
>
> -
> ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseR
> eportStatusCodeLibNull.inf
>
> -  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
>

Re: [edk2-devel] [edk2-test][PATCH 1/1] SctPkg: Fix runtime access to boot services functions

[Samer El-Haj-Mahmoud]

Thanks for the catch Jeff!!

Reviewed-by: Samer El-Haj-Mahmoud 



> -Original Message-
> From: Jeff Brasen 
> Sent: Thursday, August 12, 2021 12:13 PM
> To: devel@edk2.groups.io
> Cc: G Edhaya Chandran ;
> gao...@byosoft.com.cn; Samer El-Haj-Mahmoud  mahm...@arm.com>; eric@intel.com; arvinx.c...@intel.com; Jeff
> Brasen (jbra...@nvidia.com) 
> Subject: [edk2-test][PATCH 1/1] SctPkg: Fix runtime access to boot services
> functions
>
> SctAPrint uses boot services functions but is called after
> ExitBootServices. Replace with call to Printf which is safe for use in
> runtime.
>
> Signed-off-by: Jeff Brasen 
> ---
>  .../SctPkg/SCRT/SCRTDriver/Aarch64/Dump.c | 52 +--
>  uefi-sct/SctPkg/SCRT/SCRTDriver/Arm/Dump.c| 52 +--
>  .../SctPkg/SCRT/SCRTDriver/Riscv64/Dump.c | 52 +--
>  3 files changed, 78 insertions(+), 78 deletions(-)
>
> diff --git a/uefi-sct/SctPkg/SCRT/SCRTDriver/Aarch64/Dump.c b/uefi-
> sct/SctPkg/SCRT/SCRTDriver/Aarch64/Dump.c
> index cc8d9869..5688849c 100644
> --- a/uefi-sct/SctPkg/SCRT/SCRTDriver/Aarch64/Dump.c
> +++ b/uefi-sct/SctPkg/SCRT/SCRTDriver/Aarch64/Dump.c
> @@ -26,43 +26,43 @@ Module Name:
>  VOID
>  DumpRuntimeTable()
>  {
> -  SctAPrint ("\nDump Runtime
> Table===\n");
> -  SctAPrint ("Header Signature = 0x%x\n", VRT->Hdr.Signature);
> +  Printf ("\nDump Runtime
> Table===\n");
> +  Printf ("Header Signature = 0x%x\n", VRT->Hdr.Signature);
>
> -  SctAPrint ("\nGetTime Service==\n");
> -  SctAPrint ("GetTime @ 0x%x\n", VRT->GetTime);
> +  Printf ("\nGetTime Service==\n");
> +  Printf ("GetTime @ 0x%x\n", VRT->GetTime);
>
> -  SctAPrint ("\nSetTime Service==\n");
> -  SctAPrint ("SetTime @ 0x%x\n", VRT->SetTime);
> +  Printf ("\nSetTime Service==\n");
> +  Printf ("SetTime @ 0x%x\n", VRT->SetTime);
>
> -  SctAPrint ("\nGetWakeupTime
> Service==\n");
> -  SctAPrint ("GetWakeupTime @ 0x%x\n", VRT->GetWakeupTime);
> +  Printf ("\nGetWakeupTime
> Service==\n");
> +  Printf ("GetWakeupTime @ 0x%x\n", VRT->GetWakeupTime);
>
> -  SctAPrint ("\nSetWakeupTime
> Service==\n");
> -  SctAPrint ("SetWakeupTime @ 0x%x\n", VRT->SetWakeupTime);
> +  Printf ("\nSetWakeupTime
> Service==\n");
> +  Printf ("SetWakeupTime @ 0x%x\n", VRT->SetWakeupTime);
>
> -  SctAPrint ("\nGetVariable
> Service==\n");
> -  SctAPrint ("GetVariable @ 0x%x\n", VRT->GetVariable);
> +  Printf ("\nGetVariable Service==\n");
> +  Printf ("GetVariable @ 0x%x\n", VRT->GetVariable);
>
> -  SctAPrint ("\nGetNextVariableName
> Service==\n");
> -  SctAPrint ("GetNextVariableName @ 0x%x\n", VRT-
> >GetNextVariableName);
> +  Printf ("\nGetNextVariableName
> Service==\n");
> +  Printf ("GetNextVariableName @ 0x%x\n", VRT->GetNextVariableName);
>
> -  SctAPrint ("\nSetVariable
> Service==\n");
> -  SctAPrint ("SetVariable @ 0x%x\n", VRT->SetVariable);
> +  Printf ("\nSetVariable Service==\n");
> +  Printf ("SetVariable @ 0x%x\n", VRT->SetVariable);
>
> -  SctAPrint ("\nGetNextHighMonotonicCount
> Service==\n");
> -  SctAPrint ("GetNextHighMonotonicCount @ 0x%x\n", VRT-
> >GetNextHighMonotonicCount);
> +  Printf ("\nGetNextHighMonotonicCount
> Service==\n");
> +  Printf ("GetNextHighMonotonicCount @ 0x%x\n", VRT-
> >GetNextHighMonotonicCount);
>
> -  SctAPrint ("\nResetSystem
> Service==\n");
> -  SctAPrint ("ResetSystem @ 0x%x\n", VRT->ResetSystem);
> +  Printf ("\nResetSystem
> Service==\n");
> +  Printf ("ResetSystem @ 0x%x\n", VRT->ResetSystem);
>  #if 0
> -  SctAPrint ("\nUpdateCapsule
> Service==\n");
> -  SctAPrint ("UpdateCapsule @ 0x%x\n", VRT->UpdateCapsule);
> +  Printf ("\nUpdate

Re: [edk2-devel] [edk2-platforms PATCH 2/7] Marvell: Armada7k8k/OcteonTx: Add missing _STA methods in ACPI tables

[Samer El-Haj-Mahmoud]

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ard
> Biesheuvel via groups.io
> Sent: Tuesday, August 10, 2021 10:41 AM
> To: edk2-devel-groups-io ; Samer El-Haj-Mahmoud
> 
> Cc: Marcin Wojtas ; Leif Lindholm ;
> Ard Biesheuvel ; Grzegorz Jaszczyk
> ; Grzegorz Bernacki ;
> upstr...@semihalf.com; Jon (j...@solid-run.com) 
> Subject: Re: [edk2-devel] [edk2-platforms PATCH 2/7] Marvell:
> Armada7k8k/OcteonTx: Add missing _STA methods in ACPI tables
>
> On Tue, 10 Aug 2021 at 16:36, Samer El-Haj-Mahmoud
>  wrote:
> >
> > Apologies for the tardiness in replying to this. Please see my comments
> below.
> >
> > > -Original Message-
> > > From: Marcin Wojtas 
> > > Sent: Friday, July 30, 2021 5:57 AM
> > > To: Ard Biesheuvel 
> > > Cc: Samer El-Haj-Mahmoud ; edk2-
> > > devel-groups-io ; Leif Lindholm
> > > ; Ard Biesheuvel ;
> > > Grzegorz Jaszczyk ; Grzegorz Bernacki
> > > ; upstr...@semihalf.com; Jon (jon@solid-
> run.com)
> > > 
> > > Subject: Re: [edk2-platforms PATCH 2/7] Marvell: Armada7k8k/OcteonTx:
> > > Add missing _STA methods in ACPI tables
> > >
> > > Hi Ard,
> > >
> > > czw., 29 lip 2021 o 11:58 Ard Biesheuvel  napisał(a):
> > > >
> > > > On Thu, 29 Jul 2021 at 11:46, Marcin Wojtas 
> wrote:
> > > > >
> > > > > Hi Ard,
> > > > >
> > > > > pon., 19 lip 2021 o 17:06 Marcin Wojtas 
> napisał(a):
> > > > > >
> > > > > > Hi Ard,
> > > > > >
> > > > > > pon., 19 lip 2021 o 11:54 Ard Biesheuvel 
> napisał(a):
> > > > > > >
> > > > > > > On Mon, 19 Jul 2021 at 11:31, Marcin Wojtas 
> > > wrote:
> > > > > > > >
> > > > > > > > BBR 1.0 spec says that _STA is required for each device in DSDT
> or
> > > SSDT.
> > > > > > > > Fix that for all platforms with the Marvell SoC's.
> > > > > > > >
> > > > > > >
> > > > > > > Can we fix the BBR instead? If ACPI itself does not require _STA,
> BBR
> > > > > > > should not require it either.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > I consulted with ARM on the matter. SBBR has requirements of
> things
> > > > > > that are otherwise optional in UEFI/ACPI/SMBIOS. Also some OS's
> may
> > > > > > require that and I can see those methods in most of the other ACPI
> > > > > > source files in the edk2-platfoms tree. I think the BBR requirements
> > > > > > discussions can follow, but it would be great if this change can be
> > > > > > applied, so that no to block other development.
> > > > > >
> > > > >
> > > > > Do you have any feedback to the patchset and the _STA methods
> > > concerns?
> > > > >
> > > >
> > > > Yes. I would like to understand why _STA methods are now mandated
> by
> > > BBR.
> > > >
> > >
> > > Understood. Providing an answer may not be immediate and may
> possibly
> > > require further discussion on the SystemArchAC level.
> > > How about we withdraw this single patch for now and process the
> > > remaining ones? We would come back to the _STA subject, as soon as
> > > there's more information available.
> > >
> > > Best regards,
> > > Marcin
> > >
> >
> > _STA has been required in SBBR since ver 1.0 (published 2016, with the 0.9
> draft since 2014)
> > https://developer.arm.com/documentation/den0044/b/?lang=en
> >
> > I do not have the history on why SBBR 1.0+ requires _STA, but it most likely
> has to do wit the Windows strong use case for it:
> https://docs.microsoft.com/en-us/windows-
> hardware/drivers/bringup/device-management-namespace-
> objects#device-status-changes . Windows is a key OS targeted by SBBR.
> >
>
> OK, I stand corrected again :-)
>
> Marcin,
>
> I won't object further to these additions -please respin the patch on
> top of current edk2-platform and I will apply it right away.
>

Thank you Ard! :-)

>
> 
>

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79033): https://edk2.groups.io/g/devel/message/79033
Mute This Topic: https://groups.io/mt/84304355/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 2/7] Marvell: Armada7k8k/OcteonTx: Add missing _STA methods in ACPI tables

[Samer El-Haj-Mahmoud]

Apologies for the tardiness in replying to this. Please see my comments below.

> -Original Message-
> From: Marcin Wojtas 
> Sent: Friday, July 30, 2021 5:57 AM
> To: Ard Biesheuvel 
> Cc: Samer El-Haj-Mahmoud ; edk2-
> devel-groups-io ; Leif Lindholm
> ; Ard Biesheuvel ;
> Grzegorz Jaszczyk ; Grzegorz Bernacki
> ; upstr...@semihalf.com; Jon (j...@solid-run.com)
> 
> Subject: Re: [edk2-platforms PATCH 2/7] Marvell: Armada7k8k/OcteonTx:
> Add missing _STA methods in ACPI tables
>
> Hi Ard,
>
> czw., 29 lip 2021 o 11:58 Ard Biesheuvel  napisał(a):
> >
> > On Thu, 29 Jul 2021 at 11:46, Marcin Wojtas  wrote:
> > >
> > > Hi Ard,
> > >
> > > pon., 19 lip 2021 o 17:06 Marcin Wojtas  napisał(a):
> > > >
> > > > Hi Ard,
> > > >
> > > > pon., 19 lip 2021 o 11:54 Ard Biesheuvel  napisał(a):
> > > > >
> > > > > On Mon, 19 Jul 2021 at 11:31, Marcin Wojtas 
> wrote:
> > > > > >
> > > > > > BBR 1.0 spec says that _STA is required for each device in DSDT or
> SSDT.
> > > > > > Fix that for all platforms with the Marvell SoC's.
> > > > > >
> > > > >
> > > > > Can we fix the BBR instead? If ACPI itself does not require _STA, BBR
> > > > > should not require it either.
> > > > >
> > > > >
> > > >
> > > > I consulted with ARM on the matter. SBBR has requirements of things
> > > > that are otherwise optional in UEFI/ACPI/SMBIOS. Also some OS's may
> > > > require that and I can see those methods in most of the other ACPI
> > > > source files in the edk2-platfoms tree. I think the BBR requirements
> > > > discussions can follow, but it would be great if this change can be
> > > > applied, so that no to block other development.
> > > >
> > >
> > > Do you have any feedback to the patchset and the _STA methods
> concerns?
> > >
> >
> > Yes. I would like to understand why _STA methods are now mandated by
> BBR.
> >
>
> Understood. Providing an answer may not be immediate and may possibly
> require further discussion on the SystemArchAC level.
> How about we withdraw this single patch for now and process the
> remaining ones? We would come back to the _STA subject, as soon as
> there's more information available.
>
> Best regards,
> Marcin
>

_STA has been required in SBBR since ver 1.0 (published 2016, with the 0.9 
draft since 2014)
https://developer.arm.com/documentation/den0044/b/?lang=en

I do not have the history on why SBBR 1.0+ requires _STA, but it most likely 
has to do wit the Windows strong use case for it: 
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/device-management-namespace-objects#device-status-changes
 . Windows is a key OS targeted by SBBR.





>
> >
> > > >
> > > > >
> > > > > > Signed-off-by: Marcin Wojtas 
> > > > > > ---
> > > > > >  Silicon/Marvell/Armada7k8k/AcpiTables/Armada70x0Db/Dsdt.asl
> | 56 +++
> > > > > >  Silicon/Marvell/Armada7k8k/AcpiTables/Armada80x0Db/Dsdt.asl
> | 76 
> > > > > >
> Silicon/Marvell/Armada7k8k/AcpiTables/Armada80x0McBin/Dsdt.asl | 72
> +++
> > > > > >  Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA/Ssdt.asl |
> 12 
> > > > > >  Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Dsdt.asl |
> 56 +++
> > > > > >  5 files changed, 272 insertions(+)
> > > > > >
> > > > > > diff --git
> a/Silicon/Marvell/Armada7k8k/AcpiTables/Armada70x0Db/Dsdt.asl
> b/Silicon/Marvell/Armada7k8k/AcpiTables/Armada70x0Db/Dsdt.asl
> > > > > > index 345c1e4dd6..88e38efeeb 100644
> > > > > > ---
> a/Silicon/Marvell/Armada7k8k/AcpiTables/Armada70x0Db/Dsdt.asl
> > > > > > +++
> b/Silicon/Marvell/Armada7k8k/AcpiTables/Armada70x0Db/Dsdt.asl
> > > > > > @@ -20,21 +20,37 @@ DefinitionBlock ("DSDT.aml", "DSDT", 2,
> "MVEBU ", "ARMADA7K", 3)
> > > > > >  {
> > > > > >  Name (_HID, "ACPI0007" /* Processor Device */)  // 
> > > > > > _HID:
> Hardware ID
> > > > > >  Name (_UID, 0x000)  // _UID: Unique ID
> > > > > > +Method (_STA)   // _STA: Device status
> 

Re: [edk2-devel] [PATCH edk2-test 1/1] uefi-sct/SctPkg: correct print code for EFI_MEMORY_TYPE

[Samer El-Haj-Mahmoud]

Reviewed-by: Samer El-Haj-Mahmoud 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Heinrich
> Schuchardt via groups.io
> Sent: Friday, April 30, 2021 3:40 PM
> To: EDK II Development 
> Cc: Eric Jin ; G Edhaya Chandran
> ; Barton Gao ; Arvin
> Chen ; Samer El-Haj-Mahmoud  mahm...@arm.com>; Heinrich Schuchardt 
> Subject: [edk2-devel] [PATCH edk2-test 1/1] uefi-sct/SctPkg: correct print 
> code
> for EFI_MEMORY_TYPE
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2284
>
> EFI_MEMORY_TYPE is an enum. SctPrint expects an UINTN when printing with
> %d. Add missing conversions in MemoryAllocationServicesBBTestFunction.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  .../MemoryAllocationServicesBBTestFunction.c  | 98 +--
>  1 file changed, 49 insertions(+), 49 deletions(-)
>
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/MemoryAllocationServices/BlackB
> oxTest/MemoryAllocationServicesBBTestFunction.c b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/MemoryAllocationServices/BlackB
> oxTest/MemoryAllocationServicesBBTestFunction.c
> index bf8cd3b3afa4..e545b3cfc5b8 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/MemoryAllocationServices/BlackB
> oxTest/MemoryAllocationServicesBBTestFunction.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/MemoryAllocationServices/BlackB
> oxTest/MemoryAllocationServicesBBTestFunction.c
> @@ -417,7 +417,7 @@ BBTestAllocatePagesInterfaceTest (
>   (UINTN)__LINE__,
>   Status,
>   TplArray[Index],
> - AllocatePagesMemoryType[TypeIndex]
> + (UINTN)AllocatePagesMemoryType[TypeIndex]
>   );
>if (!(Memory & EFI_PAGE_MASK)) {
>  AssertionType = EFI_TEST_ASSERTION_PASSED;
> @@ -437,7 +437,7 @@ BBTestAllocatePagesInterfaceTest (
>   __FILE__,
>   (UINTN)__LINE__,
>   TplArray[Index],
> - AllocatePagesMemoryType[TypeIndex]
> + (UINTN)AllocatePagesMemoryType[TypeIndex]
>   );
>if (Memory != 0) {
>  Status = gtBS->FreePages (
> @@ -455,7 +455,7 @@ BBTestAllocatePagesInterfaceTest (
>   (UINTN)__LINE__,
>   Status,
>   TplArray[Index],
> - AllocatePagesMemoryType[TypeIndex]
> + (UINTN)AllocatePagesMemoryType[TypeIndex]
>   );
>  }
>}
> @@ -478,7 +478,7 @@ BBTestAllocatePagesInterfaceTest (
> (UINTN)__LINE__,
> Status,
> TplArray[Index],
> -   AllocatePagesMemoryType[TypeIndex]
> +   (UINTN)AllocatePagesMemoryType[TypeIndex]
> );
>} else {
>  PageNum = (UINTN)Descriptor.NumberOfPages;
> @@ -512,7 +512,7 @@ BBTestAllocatePagesInterfaceTest (
> (UINTN)__LINE__,
> Status,
> TplArray[Index],
> -   AllocatePagesMemoryType[TypeIndex]
> +   (UINTN)AllocatePagesMemoryType[TypeIndex]
> );
>  if (!(Memory & EFI_PAGE_MASK)) {
>AssertionType = EFI_TEST_ASSERTION_PASSED;
> @@ -532,7 +532,7 @@ BBTestAllocatePagesInterfaceTest (
> __FILE__,
> (UINTN)__LINE__,
> TplArray[Index],
> -   AllocatePagesMemoryType[TypeIndex]
> +   (UINTN)AllocatePagesMemoryType[TypeIndex]
> );
>  if (Memory <= Descriptor.PhysicalStart +
>   SctLShiftU64 (Descriptor.NumberOfPages, EFI_PAGE_SHIFT) -
> @@ -554,7 +554,7 @@ BBTestAllocatePagesInterfaceTest (
> __FILE__,
> (UINTN)__LINE__,
> TplArray[Index],
> -   AllocatePagesMemoryType[TypeIndex],
> +   (UINTN)AllocatePagesMemoryType[TypeIndex],
> Descriptor.PhysicalStart,
> Descriptor.NumberOfPages,
> Memory
> @@ -589,7 +589,7 @@ BBTestAllocatePagesInterfaceTest (
> (UINTN)__LINE__,
> Status,
> TplArray[Index],
> -   AllocatePagesMemoryType[TypeIndex]
> +   (UINTN)AllocatePagesMe

Re: [edk2-devel] [edk2-test][PATCH v1 1/1] uefi-sct/SctPkg: Update page alignment calculations

[Samer El-Haj-Mahmoud]

+Heinrich

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Sunny
> Wang via groups.io
> Sent: Monday, July 19, 2021 4:08 AM
> To: devel@edk2.groups.io
> Cc: Sunny Wang ; Samer El-Haj-Mahmoud
> ; G Edhaya Chandran
> ; Barton Gao ;
> Sunny Wang 
> Subject: [edk2-devel] [edk2-test][PATCH v1 1/1] uefi-sct/SctPkg: Update
> page alignment calculations
>
> This is to fix the SCT BS.AllocatePages failures (not found) with the
> case that the Start address is not aligned to 64k.
> For example,
>   The following is available memory region for testing:
> 82012000-EB6D9FFF 000696C8
>   With the current page alignment calculation, we will get:
> Start address is 0x8202
> PageNum is 0x696B8
>   In BS.AllocatePages, it will make the end address align with 64k,
>   so PageNum will be changed from 0x696B8 to 0x696C0. Therefore, the
>   end address will become 0xEB6E which is larger than 0xEB6D9FFF,
>   so we get not found error in the end.
>
> Therefore, the calculation for getting the PageNum should be updated
> to PageNum - (2 * EFI_SIZE_TO_PAGES(0x1)) so that we won't get a
> wrong PageNum to allocate a memory with a size larger than available
> space's size.
>
> With this solution, the example above will get 0x696A8 as calculated
> PageNum. Then, in BS.AllocatePages, the PageNum will be changed from
> 0x696A8 to 0x696B0. Therefore, the end address will become 0xEB6D
> that is smaller than 0xEB6D9FFF, so we get not found error in the end.
>
> I also tested this solution on two ARM platforms (NXP1046A and RPi4).
>
> Cc: Samer El-Haj-Mahmoud 
> Cc: G Edhaya Chandran 
> Cc: Barton Gao 
> Signed-off-by: Sunny Wang 
> ---
>  .../MemoryAllocationServicesBBTestFunction.c  | 110 +++---
>  1 file changed, 66 insertions(+), 44 deletions(-)
>
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/MemoryAllocationServices/Blac
> kBoxTest/MemoryAllocationServicesBBTestFunction.c b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/MemoryAllocationServices/Blac
> kBoxTest/MemoryAllocationServicesBBTestFunction.c
> index bf8cd3b3..cdfac992 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/MemoryAllocationServices/Blac
> kBoxTest/MemoryAllocationServicesBBTestFunction.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/MemoryAllocationServices/Blac
> kBoxTest/MemoryAllocationServicesBBTestFunction.c
> @@ -2,6 +2,7 @@
>
>Copyright 2006 - 2013 Unified EFI, Inc.
>Copyright (c) 2010 - 2013, Intel Corporation. All rights reserved.
> +  Copyright (c) 2021, ARM Limited. All rights reserved.
>
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
> @@ -24,7 +25,7 @@ Abstract:
>
>  --*/
>
> -#include "SctLib.h"
> +#include "SctLib.h"
>  #include "MemoryAllocationServicesBBTestMain.h"
>
>  #define ALLOCATEPAGES_MEMORYTYPE_NUM 16
> @@ -700,14 +701,17 @@ BBTestAllocatePagesInterfaceTest (
>  PageNum = (UINTN)Descriptor.NumberOfPages;
>  Start   = Descriptor.PhysicalStart;
>
> -//
> -// Some memory types need more alignment than 4K, so
> -//
> -if (PageNum <= 0x10) {
> +//
> +// Calculate New Start address and PageNum with 64k alignment to
> +// cover the case that some memory types' alignment is more than
> +// 4k. If the available memory is less than 192k, the memory
> +// allocation call will be skipped.
> +//
> +if (PageNum < (3 * EFI_SIZE_TO_PAGES(0x1))) {
>break;
>  }
> -Start   = (Start + 0x) & 0x;
> -PageNum = PageNum - EFI_SIZE_TO_PAGES(0x1);
> +Start   = (Start + 0x) & 0x;
> +PageNum = PageNum - (2 * EFI_SIZE_TO_PAGES(0x1));
>
>  Memory  = Start;
>
> @@ -830,14 +834,17 @@ BBTestAllocatePagesInterfaceTest (
>  PageNum = (UINTN)Descriptor.NumberOfPages;
>  Start   = Descriptor.PhysicalStart;
>
> -//
> -// Some memory types need more alignment than 4K, so
> -//
> -if (PageNum <= 0x10) {
> +//
> +// Calculate New Start address and PageNum with 64k alignment to
> +// cover the case that some memory types' alignment is more than
> +// 4k. If the available memory is less than 192k, the memory
> +// allocation call will be skipped.
> +//
> +if (PageNum < (3 * EFI_SIZE_TO_PAGES(0x1))) {
>break;
>

Re: [edk2-devel] Proposing a new area of the edk2-test repository

[Samer El-Haj-Mahmoud]

I would think just sending the code contribution patch is sufficient.


From: Nelson, Eric 
Sent: Wednesday, July 28, 2021 3:05 PM
To: Samer El-Haj-Mahmoud ; Bret Barkelew 
; devel@edk2.groups.io; G Edhaya Chandran 
; gao...@byosoft.com.cn; Kinney, Michael D 

Subject: RE: Proposing a new area of the edk2-test repository


Adding ResumeOK.efi tool under /edk2-test/test-tools/TestToolsPkg would be 
great.

Should I propose this in the RFC and DEVEL mailing lists as a next step?

Thanks,
__e


From: Samer El-Haj-Mahmoud 
mailto:samer.el-haj-mahm...@arm.com>>
Sent: Friday, July 9, 2021 1:12 PM
To: Bret Barkelew 
mailto:bret.barke...@microsoft.com>>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Nelson, Eric 
mailto:eric.nel...@intel.com>>; G Edhaya Chandran 
mailto:edhaya.chand...@arm.com>>; 
gao...@byosoft.com.cn<mailto:gao...@byosoft.com.cn>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: RE: Proposing a new area of the edk2-test repository

Interesting, thanks for sharing Bret. Some of those tests seem to be x64 
specific (SMM tests), and some can be more generic like MorLockTestApp

Like I said earlier, I am not against adding test tools to edk2-test. That in 
fact is welcomed, especially if their usefulness in validating the solutions 
extend beyond specific implementations.

What would a good tree structure look like to accommodate misc tools? Today we 
have

/edk2-test/uefi-sct/SctPkg

How about something like this?
/edk2-test/test-tools/TestToolsPkg
or /edk2-test/ TestToolsPkg

The "ResumeOK" can be placed there

Any other ideas?


From: Bret Barkelew 
mailto:bret.barke...@microsoft.com>>
Sent: Thursday, June 24, 2021 12:25 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; 
eric.nel...@intel.com<mailto:eric.nel...@intel.com>; Samer El-Haj-Mahmoud 
mailto:samer.el-haj-mahm...@arm.com>>; G Edhaya 
Chandran mailto:edhaya.chand...@arm.com>>; 
gao...@byosoft.com.cn<mailto:gao...@byosoft.com.cn>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: RE: Proposing a new area of the edk2-test repository

Fun fact! Mu also has a number of apps and things that we could work on moving 
to EDK2 if there were a suitable location. Right now, many of them are here:
mu_plus/UefiTestingPkg at release/202102 * microsoft/mu_plus 
(github.com)<https://github.com/microsoft/mu_plus/tree/release/202102/UefiTestingPkg>

- Bret

From: Nelson, Eric via groups.io<mailto:eric.nelson=intel@groups.io>
Sent: Wednesday, June 23, 2021 3:38 PM
To: Samer El-Haj-Mahmoud<mailto:samer.el-haj-mahm...@arm.com>; G Edhaya 
Chandran<mailto:edhaya.chand...@arm.com>; 
gao...@byosoft.com.cn<mailto:gao...@byosoft.com.cn>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Kinney, Michael 
D<mailto:michael.d.kin...@intel.com>
Subject: [EXTERNAL] Re: [edk2-devel] Proposing a new area of the edk2-test 
repository


I have created a few other internal apps that build under WinTestPkg, although 
ResumeOK.efi is the only one I have received permissions to release sources for 
at this time.
And yes, they are primarily intended for validating Windows requirements.
I had some issues with my apps, needing to use different libraries than 
MdeModulePkg, and found it easier to create my own package, and use the libs I 
want.

__e


From: Samer El-Haj-Mahmoud 
mailto:samer.el-haj-mahm...@arm.com>>
Sent: Wednesday, June 23, 2021 1:56 PM
To: Nelson, Eric mailto:eric.nel...@intel.com>>; G 
Edhaya Chandran mailto:edhaya.chand...@arm.com>>; 
gao...@byosoft.com.cn<mailto:gao...@byosoft.com.cn>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Samer El-Haj-Mahmoud 
mailto:samer.el-haj-mahm...@arm.com>>
Subject: RE: Proposing a new area of the edk2-test repository

+edk2 list

I am not against adding additional test tools to edk2-test. Just feel like 
there is a need to organize and have a strategy, rather than just use edk2-test 
as a dumping group of miscellaneous tools.

There is already a place for apps under 
https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Application<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Ftree%2Fmaster%2FMdeModulePkg%2FApplication&data=04%7C01%7Cbret.barkelew%40microsoft.com%7C5516a3b7e8534f55f6a408d936977266%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637600846834570307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=699Ij2Qa2eOSFkqafXn87lEEAnWuyeZnDqotOMRdOvY%3D&reserved=0>

We also have a number of EDK2 misc applications that use edk2-libc in 
https://github.com/tianocore/edk2-libc/tree/master/AppPkg/Applications<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2-libc%

Re: [edk2-devel] [edk2-platforms PATCH v5 1/2] Platform/RaspberryPi: Enable Boot Discovery Policy.

[Samer El-Haj-Mahmoud]

Ard,

Now that the EDK2 changes are merged (aaecef38b9440a65809cbdaf9d97029f4eeb), I 
think these RPi specific changes are ready to be merged as well.

> -Original Message-
> From: Grzegorz Bernacki 
> Sent: Monday, August 2, 2021 8:19 AM
> To: devel@edk2.groups.io
> Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud
> ; Sunny Wang
> ; m...@semihalf.com; upstr...@semihalf.com;
> p...@akeo.ie; jian.j.w...@intel.com; hao.a...@intel.com;
> dandan...@intel.com; eric.d...@intel.com; Grzegorz Bernacki
> ; Sunny Wang 
> Subject: [edk2-platforms PATCH v5 1/2] Platform/RaspberryPi: Enable Boot
> Discovery Policy.
>
> This commit modify platform boot to check the value of
> BootDiscoveryPolicy variable and use BootPolicyManager
> Protocol to connect devices specified by the variable.
>
> Signed-off-by: Grzegorz Bernacki 
> Reviewed-by: Sunny Wang 
> ---
>  Platform/RaspberryPi/RPi4/RPi4.dsc   
>   |  3 +
>  Platform/RaspberryPi/RPi4/RPi4.fdf   
>   |  1 +
>
> Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBootManag
> erLib.inf |  5 ++
>  Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c
> | 91 
>  4 files changed, 100 insertions(+)
>
> diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc
> b/Platform/RaspberryPi/RPi4/RPi4.dsc
> index fd73c4d14b..8b9beac64a 100644
> --- a/Platform/RaspberryPi/RPi4/RPi4.dsc
> +++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
> @@ -555,6 +555,7 @@
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdConOutColumn|L"Columns"|gRasp
> berryPiTokenSpaceGuid|0x0|80
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdSetupConOutRow|L"Rows"|gRaspb
> erryPiTokenSpaceGuid|0x0|25
>
> gEfiMdeModulePkgTokenSpaceGuid.PcdConOutRow|L"Rows"|gRaspberryPi
> TokenSpaceGuid|0x0|25
> +
> gEfiMdeModulePkgTokenSpaceGuid.PcdBootDiscoveryPolicy|L"BootDiscove
> ryPolicy"|gBootDiscoveryPolicyMgrFormsetGuid|0
>
>  [PcdsDynamicDefault.common]
>#
> @@ -682,6 +683,7 @@
>#
># Bds
>#
> +
> MdeModulePkg/Universal/BootManagerPolicyDxe/BootManagerPolicyDxe.i
> nf
>MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
>MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> @@ -690,6 +692,7 @@
>Platform/RaspberryPi/Drivers/LogoDxe/LogoDxe.inf
>MdeModulePkg/Application/UiApp/UiApp.inf {
>  
> +
> NULL|MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolic
> yUiLib.inf
>
> NULL|MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
>NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
>
> NULL|Platform/RaspberryPi/Library/PlatformUiAppLib/PlatformUiAppLib.inf
> diff --git a/Platform/RaspberryPi/RPi4/RPi4.fdf
> b/Platform/RaspberryPi/RPi4/RPi4.fdf
> index 1e13909a57..371197a93e 100644
> --- a/Platform/RaspberryPi/RPi4/RPi4.fdf
> +++ b/Platform/RaspberryPi/RPi4/RPi4.fdf
> @@ -253,6 +253,7 @@ READ_LOCK_STATUS   = TRUE
>#
># Bds
>#
> +  INF
> MdeModulePkg/Universal/BootManagerPolicyDxe/BootManagerPolicyDxe.i
> nf
>INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
>INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
>INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> diff --git
> a/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBootMan
> agerLib.inf
> b/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBootMan
> agerLib.inf
> index fbf510ab96..4ef2f791ae 100644
> ---
> a/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBootMan
> agerLib.inf
> +++
> b/Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBootMan
> agerLib.inf
> @@ -61,11 +61,13 @@
>gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType
>
>  [Pcd]
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdBootDiscoveryPolicy
>gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
>gRaspberryPiTokenSpaceGuid.PcdSdIsArasan
>gRaspberryPiTokenSpaceGuid.PcdBootPolicy
>
>  [Guids]
> +  gBootDiscoveryPolicyMgrFormsetGuid
>gEfiFileInfoGuid
>gEfiFileSystemInfoGuid
>gEfiFileSystemVolumeLabelInfoIdGuid
> @@ -73,8 +75,11 @@
>gEfiTtyTermGuid
>gUefiShellFileGuid
>gEfiEventExitBootServicesGuid
> +  gEfiBootManagerPolicyNetworkGuid
> +  gEfiBootManagerPolicyConnectAllGuid
>
>  [Protocols]
> +  gEfiBootManagerPolicyProtocolGuid
>gEfiDevicePathProtocolGuid
>gEfiGraphicsOutputProtocolGuid
>gEfiLoadedImageProtocolGuid
> diff --git
> a/Platform/RaspberryPi/Library/PlatformBootManagerLib/Pl

[edk2-devel] [edk2-platform][PATCH v1 1/1] Platform/RaspberryPi/RPi4: Fix non-standard ACPI HIDs

[Samer El-Haj-Mahmoud]

Remove non-standard RPI ACPI _CIDs that are not needed.

This also fixes the FWTS failure reported in

https://github.com/pftf/RPi4/issues/67



The windows drivers at https://github.com/raspberrypi/windows-drivers

are still able to match the ACPI objects using the HIDs which

are supported in the drivers, with these two recent changes needed:

469702898789e555c6947e50216a3f79e0ddeb9

and

5c5e2742b4c983b3001c473b168b0dae2fcba0c2



Cc: Leif Lindholm 

Cc: Ard Biesheuvel 

Cc: Pete Batard 

Cc: Andrei Warkentin 

Cc: Mario Bălănică 

Signed-off-by: Samer El-Haj-Mahmoud 

Tested-by: Mario Bălănică 

---

 Platform/RaspberryPi/AcpiTables/GpuDevs.asl | 26 +++-

 Platform/RaspberryPi/AcpiTables/Sdhc.asl|  4 +--

 Platform/RaspberryPi/AcpiTables/Uart.asl|  2 +-

 3 files changed, 18 insertions(+), 14 deletions(-)



diff --git a/Platform/RaspberryPi/AcpiTables/GpuDevs.asl 
b/Platform/RaspberryPi/AcpiTables/GpuDevs.asl

index 966a94cdb5b5..9750dc25c07c 100644

--- a/Platform/RaspberryPi/AcpiTables/GpuDevs.asl

+++ b/Platform/RaspberryPi/AcpiTables/GpuDevs.asl

@@ -13,7 +13,11 @@

 Device (USB0)

 {

   Name (_HID, "BCM2848")

-  Name (_CID, Package() { "DWC_OTG", "DWC2_OTG" })

+#if (RPI_MODEL == 3)

+  Name (_CID, "DWC_OTG")

+#elif (RPI_MODEL == 4)

+  Name (_CID, "BCM2848")

+#endif

   Name (_UID, 0x0)

   Name (_CCA, 0x0)

   Method (_STA)

@@ -36,7 +40,7 @@ Device (USB0)

 Device (GPU0)

 {

   Name (_HID, "BCM2850")

-  Name (_CID, "VC4")

+  Name (_CID, "BCM2850")

   Name (_UID, 0x0)

   Name (_CCA, 0x0)

   Method (_STA)

@@ -140,7 +144,7 @@ Device (GPU0)

 Device (RPIQ)

 {

   Name (_HID, "BCM2849")

-  Name (_CID, "RPIQ")

+  Name (_CID, "BCM2849")

   Name (_UID, 0)

   Name (_CCA, 0x0)

   Method (_STA)

@@ -164,7 +168,7 @@ Device (RPIQ)

 Device (VCIQ)

 {

   Name (_HID, "BCM2835")

-  Name (_CID, "VCIQ")

+  Name (_CID, "BCM2835")

   Name (_UID, 0)

   Name (_CCA, 0x0)

   Name (_DEP, Package() { \_SB.GDV0.RPIQ })

@@ -189,7 +193,7 @@ Device (VCIQ)

 Device (VCSM)

 {

   Name (_HID, "BCM2856")

-  Name (_CID, "VCSM")

+  Name (_CID, "BCM2856")

   Name (_UID, 0)

   Name (_CCA, 0x0)

   Name (_DEP, Package() { \_SB.GDV0.VCIQ })

@@ -203,7 +207,7 @@ Device (VCSM)

 Device (GPI0)

 {

   Name (_HID, "BCM2845")

-  Name (_CID, "BCMGPIO")

+  Name (_CID, "BCM2845")

   Name (_UID, 0x0)

   Name (_CCA, 0x0)

   Method (_STA)

@@ -230,7 +234,7 @@ Device (GPI0)

 Device (I2C1)

 {

   Name (_HID, "BCM2841")

-  Name (_CID, "BCMI2C")

+  Name (_CID, "BCM2841")

   Name (_UID, 0x1)

   Name (_CCA, 0x0)

   Method (_STA)

@@ -254,7 +258,7 @@ Device (I2C1)

 Device (I2C2)

 {

   Name (_HID, "BCM2841")

-  Name (_CID, "BCMI2C")

+  Name (_CID, "BCM2841")

   Name (_UID, 0x2)

   Name (_CCA, 0x0)

   Method (_STA)

@@ -278,7 +282,7 @@ Device (I2C2)

 Device (SPI0)

 {

   Name (_HID, "BCM2838")

-  Name (_CID, "BCMSPI0")

+  Name (_CID, "BCM2838")

   Name (_UID, 0x0)

   Name (_CCA, 0x0)

   Method (_STA)

@@ -304,7 +308,7 @@ Device (SPI0)

 Device (SPI1)

 {

   Name (_HID, "BCM2839")

-  Name (_CID, "BCMAUXSPI")

+  Name (_CID, "BCM2839")

   Name (_UID, 0x1)

   Name (_CCA, 0x0)

   Name (_DEP, Package() { \_SB.GDV0.RPIQ })

@@ -331,7 +335,7 @@ Device (SPI1)

 // Device (SPI2)

 // {

 //   Name (_HID, "BCM2839")

-//   Name (_CID, "BCMAUXSPI")

+//   Name (_CID, "BCM2839")

 //   Name (_UID, 0x2)

 //   Name (_CCA, 0x0)

 //   Name (_DEP, Package() { \_SB.GDV0.RPIQ })

diff --git a/Platform/RaspberryPi/AcpiTables/Sdhc.asl 
b/Platform/RaspberryPi/AcpiTables/Sdhc.asl

index 42776e33bbc6..85d5053a338c 100644

--- a/Platform/RaspberryPi/AcpiTables/Sdhc.asl

+++ b/Platform/RaspberryPi/AcpiTables/Sdhc.asl

@@ -23,7 +23,7 @@

 Device (SDC1)

 {

   Name (_HID, "BCM2847")

-  Name (_CID, "ARASAN")

+  Name (_CID, "BCM2847")

   Name (_UID, 0x0)

   Name (_CCA, 0x0)

   Name (_S1D, 0x1)

@@ -78,7 +78,7 @@ Device (SDC1)

 Device (SDC2)

 {

   Name (_HID, "BCM2855")

-  Name (_CID, "SDHST")

+  Name (_CID, "BCM2855")

   Name (_UID, 0x0)

   Name (_CCA, 0x0)

   Name (_S1D, 0x1)

diff --git a/Platform/RaspberryPi/AcpiTables/Uart.asl 
b/Platform/RaspberryPi/AcpiTables/Uart.asl

index 167f94e8892b..974f06d3bc3f 100644

--- a/Platform/RaspberryPi/AcpiTables/Uart.asl

+++ b/Platform/RaspberryPi/AcpiTables/Uart.asl

@@ -59,7 +59,7 @@ Device (URT0)

 Device (URTM)

 {

   Name (_HID, "BCM2836")

-  Name (_CID, "MINIUART")

+  Name (_CID, "BCM2836")

   Name (_UID, 0x0)

   Name (_CCA, 0x0)

   Method (_STA)

-- 

2.25.1





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77928): https://edk2.groups.io/g/devel/message/77928
Mute This Topic: https://groups.io/mt/84318433/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 v3 0/2] Add BootDiscoveryPolicyUiLib

[Samer El-Haj-Mahmoud]

Yes this depends on https://edk2.groups.io/g/devel/message/77787

Which is still under review


From: Ard Biesheuvel 
Sent: Friday, July 16, 2021 1:31:04 PM
To: Samer El-Haj-Mahmoud 
Cc: Grzegorz Bernacki ; devel@edk2.groups.io 
; l...@nuviainc.com ; 
ardb+tianoc...@kernel.org ; Sunny Wang 
; m...@semihalf.com ; 
upstr...@semihalf.com ; p...@akeo.ie ; 
jian.j.w...@intel.com ; hao.a...@intel.com 
; dandan...@intel.com ; 
eric.d...@intel.com 
Subject: Re: [edk2-platforms PATCH v3 0/2] Add BootDiscoveryPolicyUiLib

On Fri, 16 Jul 2021 at 13:50, Samer El-Haj-Mahmoud
 wrote:
>
> Series Reviewed-By: Samer El-Haj-Mahmoud 
>

Does this series depend on core EDK2 changes, and if so, have they
been merged already?


> > -Original Message-
> > From: Grzegorz Bernacki 
> > Sent: Wednesday, July 14, 2021 9:21 AM
> > To: devel@edk2.groups.io
> > Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud
> > ; Sunny Wang ;
> > m...@semihalf.com; upstr...@semihalf.com; p...@akeo.ie;
> > jian.j.w...@intel.com; hao.a...@intel.com; dandan...@intel.com;
> > eric.d...@intel.com; Grzegorz Bernacki 
> > Subject: [edk2-platforms PATCH v3 0/2] Add BootDiscoveryPolicyUiLib
> >
> > This patchset extends Boot Maintenance Menu and allows to select
> > Boot Discovery Policy. Raspberry Pi platforms uses the variable to
> > connect specified class of devices on boot. This patchset also
> > removes efdc159e which has similar functionality.
> >
> > Discussion on design can be found at:
> > https://edk2.groups.io/g/rfc/topic/rfc_boot_discovery_policy/82450628
> >
> > Changes since v1:
> > - make 'Connect All' (0x2) default value for PcdBootDiscoveryPolicy
> > - initialize BootDiscoveryPolicy variable in platform code, if not found
> >
> > Changes since v2:
> > - add missing local variable initialization
> >
> > Grzegorz Bernacki (3):
> > edk2:
> >   MdeModulePkg: Add BootDiscoveryPolicyUiLib.
> > edk2-platform:
> >   Platform/RaspberryPi: Enable Boot Discovery Policy.
> >   Revert "Platform/RaspberryPi: Setup option for disabling Fast Boot"
> >
> >  Platform/RaspberryPi/RaspberryPi.dec   
> > |   2 -
> >  Platform/RaspberryPi/RPi3/RPi3.dsc 
> > |   9 +-
> >  Platform/RaspberryPi/RPi4/RPi4.dsc 
> > |  12 +--
> >  Platform/RaspberryPi/RPi4/RPi4.fdf 
> > |   1 +
> >  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf   
> > |   3 +-
> >
> > Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBootManager
> > Lib.inf |   6 +-
> >  Platform/RaspberryPi/Include/ConfigVars.h  
> > |  12 +--
> >  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr
> > |  16 +--
> >  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c 
> > |  11 +--
> >  Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c   
> > |
> > 102 +---
> >  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni
> > |  10 +-
> >  MdeModulePkg/MdeModulePkg.dec  
> >|   6 +
> >  MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.inf
> > |  52 +++
> >  MdeModulePkg/Include/Guid/BootDiscoveryPolicy.h
> >|  22
> > +++
> >  MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.c
> > | 160 
> >
> > MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.uni
> > |  18 +++
> >
> > MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLibStri
> > ngs.uni |  29 
> >
> > MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLibVfr.
> > Vfr |  44 ++
> >  18 files changed, 438 insertions(+), 77 deletions(-)
> >  create mode 100644
> > MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.inf
> >  create mode 100644 MdeModulePkg/Include/Guid/BootDiscoveryPolicy.h
> >  create mode 100644
> > MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.c
> >  create mode 100644
> > MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.uni
> >  create mode 100644
> > MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolic

Re: [edk2-devel] [PATCH v6 00/11] Secure Boot default keys

[Samer El-Haj-Mahmoud]

The v6 of this series seems to have all the necessary Reviewed-By (and some 
Tested-By) of all parts, except the following platform specific parts. Could we 
get help from maintainers to review these please?

Much appreciated!

- ArmVirtPkg : https://edk2.groups.io/g/devel/message/2
- ArmPlatformPkg: https://edk2.groups.io/g/devel/message/5
- EmulatorPkg: https://edk2.groups.io/g/devel/message/3
- Intel Platforms (Platform/Intel/QuarkPlatformPkg, 
Platform/Intel/MinPlatformPkg, Platform/Intel/Vlv2TbltDevicePkg): 
https://edk2.groups.io/g/devel/message/77781

Thanks,
--Samer





> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of
> Grzegorz Bernacki via groups.io
> Sent: Wednesday, July 14, 2021 8:30 AM
> To: devel@edk2.groups.io
> Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud
> ; Sunny Wang
> ; m...@semihalf.com; upstr...@semihalf.com;
> jiewen@intel.com; jian.j.w...@intel.com; min.m...@intel.com;
> ler...@redhat.com; Sami Mujawar ;
> af...@apple.com; ray...@intel.com; jordan.l.jus...@intel.com;
> rebe...@bsdio.com; gre...@freebsd.org; Thomas Abraham
> ; chasel.c...@intel.com;
> nathaniel.l.desim...@intel.com; gaolim...@byosoft.com.cn;
> eric.d...@intel.com; michael.d.kin...@intel.com; zailiang@intel.com;
> yi.q...@intel.com; gra...@nuviainc.com; r...@semihalf.com;
> p...@akeo.ie; Grzegorz Bernacki 
> Subject: [edk2-devel] [PATCH v6 00/11] Secure Boot default keys
>
> This patchset adds support for initialization of default
> Secure Boot variables based on keys content embedded in
> flash binary. This feature is active only if Secure Boot
> is enabled and DEFAULT_KEY is defined. The patchset
> consist also application to enroll keys from default
> variables and secure boot menu change to allow user
> to reset key content to default values.
> Discussion on design can be found at:
> https://edk2.groups.io/g/rfc/topic/82139806#600
>
> Built with:
> GCC
> - RISC-V (U500, U540) [requires fixes in dsc to build]
> - Intel (Vlv2TbltDevicePkg (X64/IA32), Quark, MinPlatformPkg,
>   EmulatorPkg (X64), Bhyve, OvmfPkg (X64/IA32))
> - ARM (Sgi75,SbsaQemu,DeveloperBox, RPi3/RPi4)
>
> RISC-V, Quark, Vlv2TbltDevicePkg, Bhyve requires additional fixes to be built,
> will be post on edk2 maillist later
>
> VS2019
> - Intel (OvmfPkgX64)
>
> Test with:
> GCC5/RPi4
> VS2019/OvmfX64 (requires changes to enable feature)
>
> Tests:
> 1. Try to enroll key in incorrect format.
> 2. Enroll with only PKDefault keys specified.
> 3. Enroll with all keys specified.
> 4. Enroll when keys are enrolled.
> 5. Reset keys values.
> 6. Running signed & unsigned app after enrollment.
>
> Changes since v1:
> - change names:
>   SecBootVariableLib => SecureBootVariableLib
>   SecBootDefaultKeysDxe => SecureBootDefaultKeysDxe
>   SecEnrollDefaultKeysApp => EnrollFromDefaultKeysApp
> - change name of function CheckSetupMode to GetSetupMode
> - remove ShellPkg dependecy from EnrollFromDefaultKeysApp
> - rebase to master
>
> Changes since v2:
> - fix coding style for functions headers in SecureBootVariableLib.h
> - add header to SecureBootDefaultKeys.fdf.inc
> - remove empty line spaces in SecureBootDefaultKeysDxe files
> - revert FAIL macro in EnrollFromDefaultKeysApp
> - remove functions duplicates and  add SecureBootVariableLib
>   to platforms which used it
>
> Changes since v3:
> - move SecureBootDefaultKeys.fdf.inc to ArmPlatformPkg
> - leave duplicate of CreateTimeBasedPayload in PlatformVarCleanupLib
> - fix typo in guid description
>
> Changes since v4:
> - reorder patches to make it bisectable
> - split commits related to more than one platform
> - move edk2-platform commits to separate patchset
>
> Changes since v5:
> - split SecureBootVariableLib into SecureBootVariableLib and
>   SecureBootVariableProvisionLib
>
> Grzegorz Bernacki (11):
>   SecurityPkg: Create SecureBootVariableLib.
>   SecurityPkg: Create library for enrolling Secure Boot variables.
>   ArmVirtPkg: add SecureBootVariableLib class resolution
>   OvmfPkg: add SecureBootVariableLib class resolution
>   EmulatorPkg: add SecureBootVariableLib class resolution
>   SecurityPkg: Remove duplicated functions from SecureBootConfigDxe.
>   ArmPlatformPkg: Create include file for default key content.
>   SecurityPkg: Add SecureBootDefaultKeysDxe driver
>   SecurityPkg: Add EnrollFromDefaultKeys application.
>   SecurityPkg: Add new modules to Security package.
>   SecurityPkg: Add option to reset secure boot keys.
>
>  SecurityPkg/SecurityPkg.dec  
>|  14 +
>  ArmVirtPkg/ArmVirt.dsc.inc   
>

Re: [edk2-devel] [edk2-platforms PATCH v3 0/2] Add BootDiscoveryPolicyUiLib

[Samer El-Haj-Mahmoud]

Series Reviewed-By: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Grzegorz Bernacki 
> Sent: Wednesday, July 14, 2021 9:21 AM
> To: devel@edk2.groups.io
> Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud
> ; Sunny Wang ;
> m...@semihalf.com; upstr...@semihalf.com; p...@akeo.ie;
> jian.j.w...@intel.com; hao.a...@intel.com; dandan...@intel.com;
> eric.d...@intel.com; Grzegorz Bernacki 
> Subject: [edk2-platforms PATCH v3 0/2] Add BootDiscoveryPolicyUiLib
>
> This patchset extends Boot Maintenance Menu and allows to select
> Boot Discovery Policy. Raspberry Pi platforms uses the variable to
> connect specified class of devices on boot. This patchset also
> removes efdc159e which has similar functionality.
>
> Discussion on design can be found at:
> https://edk2.groups.io/g/rfc/topic/rfc_boot_discovery_policy/82450628
>
> Changes since v1:
> - make 'Connect All' (0x2) default value for PcdBootDiscoveryPolicy
> - initialize BootDiscoveryPolicy variable in platform code, if not found
>
> Changes since v2:
> - add missing local variable initialization
>
> Grzegorz Bernacki (3):
> edk2:
>   MdeModulePkg: Add BootDiscoveryPolicyUiLib.
> edk2-platform:
>   Platform/RaspberryPi: Enable Boot Discovery Policy.
>   Revert "Platform/RaspberryPi: Setup option for disabling Fast Boot"
>
>  Platform/RaspberryPi/RaspberryPi.dec 
>   |   2 -
>  Platform/RaspberryPi/RPi3/RPi3.dsc   
>   |   9 +-
>  Platform/RaspberryPi/RPi4/RPi4.dsc   
>   |  12 +--
>  Platform/RaspberryPi/RPi4/RPi4.fdf   
>   |   1 +
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
>   |   3 +-
>
> Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBootManager
> Lib.inf |   6 +-
>  Platform/RaspberryPi/Include/ConfigVars.h
>   |  12 +--
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr  
>   |  16 +--
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c   
>   |  11 +--
>  Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c 
>   |
> 102 +---
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni  
>   |  10 +-
>  MdeModulePkg/MdeModulePkg.dec
>  |   6 +
>  MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.inf
> |  52 +++
>  MdeModulePkg/Include/Guid/BootDiscoveryPolicy.h  
>  |  22
> +++
>  MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.c
> | 160 
>
> MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.uni
> |  18 +++
>
> MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLibStri
> ngs.uni |  29 
>
> MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLibVfr.
> Vfr |  44 ++
>  18 files changed, 438 insertions(+), 77 deletions(-)
>  create mode 100644
> MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.inf
>  create mode 100644 MdeModulePkg/Include/Guid/BootDiscoveryPolicy.h
>  create mode 100644
> MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.c
>  create mode 100644
> MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLib.uni
>  create mode 100644
> MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLibStri
> ngs.uni
>  create mode 100644
> MdeModulePkg/Library/BootDiscoveryPolicyUiLib/BootDiscoveryPolicyUiLibVfr.
> Vfr
> --
> 2.25.1

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] Proposing a new area of the edk2-test repository

[Samer El-Haj-Mahmoud]

Interesting, thanks for sharing Bret. Some of those tests seem to be x64 
specific (SMM tests), and some can be more generic like MorLockTestApp

Like I said earlier, I am not against adding test tools to edk2-test. That in 
fact is welcomed, especially if their usefulness in validating the solutions 
extend beyond specific implementations.

What would a good tree structure look like to accommodate misc tools? Today we 
have

/edk2-test/uefi-sct/SctPkg

How about something like this?
/edk2-test/test-tools/TestToolsPkg
or /edk2-test/ TestToolsPkg

The "ResumeOK" can be placed there

Any other ideas?


From: Bret Barkelew 
Sent: Thursday, June 24, 2021 12:25 AM
To: devel@edk2.groups.io; eric.nel...@intel.com; Samer El-Haj-Mahmoud 
; G Edhaya Chandran ; 
gao...@byosoft.com.cn; Kinney, Michael D 
Subject: RE: Proposing a new area of the edk2-test repository

Fun fact! Mu also has a number of apps and things that we could work on moving 
to EDK2 if there were a suitable location. Right now, many of them are here:
mu_plus/UefiTestingPkg at release/202102 * microsoft/mu_plus 
(github.com)<https://github.com/microsoft/mu_plus/tree/release/202102/UefiTestingPkg>

- Bret

From: Nelson, Eric via groups.io<mailto:eric.nelson=intel@groups.io>
Sent: Wednesday, June 23, 2021 3:38 PM
To: Samer El-Haj-Mahmoud<mailto:samer.el-haj-mahm...@arm.com>; G Edhaya 
Chandran<mailto:edhaya.chand...@arm.com>; 
gao...@byosoft.com.cn<mailto:gao...@byosoft.com.cn>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Kinney, Michael 
D<mailto:michael.d.kin...@intel.com>
Subject: [EXTERNAL] Re: [edk2-devel] Proposing a new area of the edk2-test 
repository


I have created a few other internal apps that build under WinTestPkg, although 
ResumeOK.efi is the only one I have received permissions to release sources for 
at this time.
And yes, they are primarily intended for validating Windows requirements.
I had some issues with my apps, needing to use different libraries than 
MdeModulePkg, and found it easier to create my own package, and use the libs I 
want.

__e


From: Samer El-Haj-Mahmoud 
mailto:samer.el-haj-mahm...@arm.com>>
Sent: Wednesday, June 23, 2021 1:56 PM
To: Nelson, Eric mailto:eric.nel...@intel.com>>; G 
Edhaya Chandran mailto:edhaya.chand...@arm.com>>; 
gao...@byosoft.com.cn<mailto:gao...@byosoft.com.cn>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Samer El-Haj-Mahmoud 
mailto:samer.el-haj-mahm...@arm.com>>
Subject: RE: Proposing a new area of the edk2-test repository

+edk2 list

I am not against adding additional test tools to edk2-test. Just feel like 
there is a need to organize and have a strategy, rather than just use edk2-test 
as a dumping group of miscellaneous tools.

There is already a place for apps under 
https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Application<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Ftree%2Fmaster%2FMdeModulePkg%2FApplication&data=04%7C01%7Cbret.barkelew%40microsoft.com%7C5516a3b7e8534f55f6a408d936977266%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637600846834570307%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=699Ij2Qa2eOSFkqafXn87lEEAnWuyeZnDqotOMRdOvY%3D&reserved=0>

We also have a number of EDK2 misc applications that use edk2-libc in 
https://github.com/tianocore/edk2-libc/tree/master/AppPkg/Applications<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2-libc%2Ftree%2Fmaster%2FAppPkg%2FApplications&data=04%7C01%7Cbret.barkelew%40microsoft.com%7C5516a3b7e8534f55f6a408d936977266%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637600846834580263%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=VhLVlbh3TrVy%2FxserD%2BF1VYnj3pROD91CyLQD1Rmjko%3D&reserved=0>

A couple of questions:

  *   Do you expect more apps from WinTestPkg to be contributed to TianoCore? 
And are they all around testing specific Windows requirements? If so, then 
having an edk2-test/WinTestPkg makes sense to me, as you will have a collection 
of useful testing app targeting specific area.

 *   But what about other OSes?

  *   If this is a one-off test app and other WinTestPkg apps are not going to 
be contributed, then does it make sense to put this under 
MdeModulePkg/Application ?



From: Nelson, Eric mailto:eric.nel...@intel.com>>
Sent: Wednesday, June 23, 2021 3:10 PM
To: G Edhaya Chandran 
mailto:edhaya.chand...@arm.com>>; 
gao...@byosoft.com.cn<mailto:gao...@byosoft.com.cn>
Cc: Samer El-Haj-Mahmoud 
mailto:samer.el-haj-mahm...@arm.com>>
Subject: RE: Proposing a new area of the edk2-test repository


Hi Edhay,

Do you have any more questions?
What do you think of creating another directory in edk2-test, for other test

Re: [edk2-devel] [PATCH v5 00/10] Secure Boot default keys

[Samer El-Haj-Mahmoud]

Sean,

Thanks for the feedback. As you say, this is a design concern in SecurityPkg 
today, and the improvement you are suggesting is welcomed, especially for 
systems that rely on EDK2 (and lack a commercial FW solution). Considering that 
this patch series is at v5, and has accumulated enough reviews since RFC/v1 was 
sent to the list in April/May, is it possible to proceed with the current 
revision, and consider the feedback you suggested in future improvements to 
SecurityPkg?

Thanks,
--Samer


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Sean via
> groups.io
> Sent: Friday, July 9, 2021 2:23 PM
> To: devel@edk2.groups.io; g...@semihalf.com
> Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud
> ; Sunny Wang
> ; m...@semihalf.com; upstr...@semihalf.com;
> jiewen@intel.com; jian.j.w...@intel.com; min.m...@intel.com;
> ler...@redhat.com; Sami Mujawar ;
> af...@apple.com; ray...@intel.com; jordan.l.jus...@intel.com;
> rebe...@bsdio.com; gre...@freebsd.org; Thomas Abraham
> ; chasel.c...@intel.com;
> nathaniel.l.desim...@intel.com; gaolim...@byosoft.com.cn;
> eric.d...@intel.com; michael.d.kin...@intel.com; zailiang@intel.com;
> yi.q...@intel.com; gra...@nuviainc.com; r...@semihalf.com;
> p...@akeo.ie
> Subject: Re: [edk2-devel] [PATCH v5 00/10] Secure Boot default keys
>
> Grzegorz,
>
> It is a little late to the party to provide broad feedback (given you
> are on v5) but i'll do it anyway and if anything resonates maybe you can
> make a few changes.
>
>
> This patchset (for modules/libraries in SecurityPkg) does not resolve a
> major issue within the SecurityPkg design today.  Not that it has to,
> but when creating new abstractions/APIs it would be ideal this problem.
>   The SecurityPkg modules and libraries today mix platform
> policy/assumptions with generic data manipulation and specification
> defined behavior.
>
> For example the new SecureBootVariableLib.  This library contains
> functions that load default keys from flash (platform), delete the SB
> databases (platform policy), as well as helper functions for creating
> variable auth payloads, sig lists, etc (spec defined data manipulation).
>   If this library was refactored into two libraries (a pure data
> manipulation library and platform lib) it would significantly improve
> the usefulness of this library (to me and i suspect many other consumers
> of edk2).
>
> 1. Reduce the number of forks or instances other consumers would need.
> Other consumers of edk2 could use the data manipulation lib without
> taking on the burden of the platform config stuff that may or may not
> apply to their platform.  Other consumers might also then help maintain
> this library because they would be using it in their platform.
>
> 2. A data manipulation library could be easily unit tested using the
> host based unit test framework.  This would provide significantly higher
> confidence in code and changes and most likely reduce quality issues.
>
> 3. A platform lib would make clear the platform requirements for using
> the modules and applications and allow platform maintainers to focus on
> this API and dependencies.
>
> Anyway, given how long and tedious the edk2 contribution process is and
> that you already have most of the SecurityPkg RBs I can understand if
> this unwelcome feedback.
>
> Thanks
> Sean
>
>
>
>
> On 7/1/2021 2:17 AM, Grzegorz Bernacki wrote:
> > This patchset adds support for initialization of default
> > Secure Boot variables based on keys content embedded in
> > flash binary. This feature is active only if Secure Boot
> > is enabled and DEFAULT_KEY is defined. The patchset
> > consist also application to enroll keys from default
> > variables and secure boot menu change to allow user
> > to reset key content to default values.
> > Discussion on design can be found at:
> > https://edk2.groups.io/g/rfc/topic/82139806#600
> >
> > Built with:
> > GCC
> > - RISC-V (U500, U540) [requires fixes in dsc to build]
> > - Intel (Vlv2TbltDevicePkg (X64/IA32), Quark, MinPlatformPkg,
> >EmulatorPkg (X64), Bhyve, OvmfPkg (X64/IA32))
> > - ARM (Sgi75,SbsaQemu,DeveloperBox, RPi3/RPi4)
> >
> > RISC-V, Quark, Vlv2TbltDevicePkg, Bhyve requires additional fixes to be
> built,
> > will be post on edk2 maillist later
> >
> > VS2019
> > - Intel (OvmfPkgX64)
> >
> > Test with:
> > GCC5/RPi4
> > VS2019/OvmfX64 (requires changes to enable feature)
> >
> > Tests:
> > 1. Try to enroll key in incorrect format.
> > 2. Enroll with only PKDefault keys specified.
> > 3. Enroll with all keys specified.
> > 4. Enroll

Re: [edk2-devel] [edk2-platforms PATCH v2] Platform/RaspberryPi: Enable default Secure Boot variables initialization

[Samer El-Haj-Mahmoud]

Reviewed-By: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Grzegorz Bernacki 
> Sent: Tuesday, June 1, 2021 9:12 AM
> To: devel@edk2.groups.io
> Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud
> ; Sunny Wang
> ; m...@semihalf.com; upstr...@semihalf.com;
> jiewen@intel.com; jian.j.w...@intel.com; min.m...@intel.com;
> ler...@redhat.com; Grzegorz Bernacki 
> Subject: [edk2-platforms PATCH v2] Platform/RaspberryPi: Enable default
> Secure Boot variables initialization
>
> This commit allows to initialize Secure Boot default key
> and databases from data embedded in firmware binary.
>
> Signed-off-by: Grzegorz Bernacki 
> ---
>  Platform/RaspberryPi/RPi4/RPi4.dsc | 5 -
>  Platform/RaspberryPi/RPi4/RPi4.fdf | 2 ++
>  2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc
> b/Platform/RaspberryPi/RPi4/RPi4.dsc
> index d8c6fdd4bd..1fb4df0b81 100644
> --- a/Platform/RaspberryPi/RPi4/RPi4.dsc
> +++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
> @@ -164,7 +164,7 @@
>  !if $(SECURE_BOOT_ENABLE) == TRUE
>
> TpmMeasurementLib|SecurityPkg/Library/DxeTpmMeasurementLib/DxeTp
> mMeasurementLib.inf
>AuthVariableLib|SecurityPkg/Library/AuthVariableLib/AuthVariableLib.inf
> -
> +
> SecureBootVariableLib|SecurityPkg/Library/SecureBootVariableLib/SecureBo
> otVariableLib.inf
># re-use the UserPhysicalPresent() dummy implementation from the ovmf
> tree
>
> PlatformSecureLib|OvmfPkg/Library/PlatformSecureLib/PlatformSecureLib.in
> f
>  !else
> @@ -217,6 +217,7 @@
>
> MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemor
> yAllocationLib.inf
>HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
>ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> +  ShellCEntryLib|ShellPkg/Library/UefiShellCEntryLib/UefiShellCEntryLib.inf
>FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
>
>  [LibraryClasses.common.UEFI_DRIVER]
> @@ -612,6 +613,8 @@
>
> NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.i
> nf
>}
>
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig
> Dxe.inf
> +  SecurityPkg/EnrollFromDefaultKeysApp/EnrollFromDefaultKeysApp.inf
> +
> SecurityPkg/VariableAuthenticated/SecureBootDefaultKeysDxe/SecureBootD
> efaultKeysDxe.inf
>  !else
>MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
>  !endif
> diff --git a/Platform/RaspberryPi/RPi4/RPi4.fdf
> b/Platform/RaspberryPi/RPi4/RPi4.fdf
> index 1e13909a57..0e43d24c7a 100644
> --- a/Platform/RaspberryPi/RPi4/RPi4.fdf
> +++ b/Platform/RaspberryPi/RPi4/RPi4.fdf
> @@ -189,7 +189,9 @@ READ_LOCK_STATUS   = TRUE
>INF
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
>INF
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
>  !if $(SECURE_BOOT_ENABLE) == TRUE
> +!include SecurityPkg/SecureBootDefaultKeys.fdf.inc
>INF
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfig
> Dxe.inf
> +  INF
> SecurityPkg/VariableAuthenticated/SecureBootDefaultKeysDxe/SecureBootD
> efaultKeysDxe.inf
>  !endif
>INF
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCount
> erRuntimeDxe.inf
>INF EmbeddedPkg/ResetRuntimeDxe/ResetRuntimeDxe.inf
> --
> 2.25.1

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#77611): https://edk2.groups.io/g/devel/message/77611
Mute This Topic: https://groups.io/mt/83232294/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 v2 2/2] Revert "Platform/RaspberryPi: Setup option for disabling Fast Boot"

[Samer El-Haj-Mahmoud]

Reviewed-By: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Grzegorz Bernacki 
> Sent: Tuesday, July 6, 2021 6:45 AM
> To: devel@edk2.groups.io
> Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud
> ; Sunny Wang
> ; m...@semihalf.com; upstr...@semihalf.com;
> p...@akeo.ie; jian.j.w...@intel.com; hao.a...@intel.com;
> dandan...@intel.com; eric.d...@intel.com; Grzegorz Bernacki
> ; Sunny Wang 
> Subject: [edk2-platforms PATCH v2 2/2] Revert "Platform/RaspberryPi: Setup
> option for disabling Fast Boot"
>
> This reverts commit efdc159ef7c9f15581a0f63d755a1530ff475156.
>
> This commit is not longer required as Boot Discovery Policy has
> been implemented for RPi.
>
> Signed-off-by: Grzegorz Bernacki 
> Reviewed-by: Sunny Wang 
> ---
>  Platform/RaspberryPi/RaspberryPi.dec 
>   |  2 --
>  Platform/RaspberryPi/RPi3/RPi3.dsc   
>   |  9 +
>  Platform/RaspberryPi/RPi4/RPi4.dsc   
>   |  9 +
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf 
>   |  3 +-
> -
>
> Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBootManag
> erLib.inf |  1 -
>  Platform/RaspberryPi/Include/ConfigVars.h
>   | 12 +
> ---
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr  
>   | 16
> +---
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c   
>   | 11 +-
> -
>  Platform/RaspberryPi/Library/PlatformBootManagerLib/PlatformBm.c
> | 15 ++-
>  Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni  
>   | 10
> +-
>  10 files changed, 9 insertions(+), 79 deletions(-)
>
> diff --git a/Platform/RaspberryPi/RaspberryPi.dec
> b/Platform/RaspberryPi/RaspberryPi.dec
> index f1dd8ac0ed..2ca25ff9e6 100644
> --- a/Platform/RaspberryPi/RaspberryPi.dec
> +++ b/Platform/RaspberryPi/RaspberryPi.dec
> @@ -2,7 +2,6 @@
>  #
>  #  Copyright (c) 2016, Linaro, Ltd. All rights reserved.
>  #  Copyright (c) 2017-2018, Andrei Warkentin
> 
> -#  Copyright (c) 2021, ARM Limited. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -71,5 +70,4 @@
>gRaspberryPiTokenSpaceGuid.PcdFanTemp|0|UINT32|0x001D
>
> gRaspberryPiTokenSpaceGuid.PcdPlatformResetDelay|0|UINT32|0x001
> E
>gRaspberryPiTokenSpaceGuid.PcdMmcEnableDma|0|UINT32|0x001F
> -  gRaspberryPiTokenSpaceGuid.PcdBootPolicy|0|UINT32|0x0020
>gRaspberryPiTokenSpaceGuid.PcdUartInUse|1|UINT32|0x0021
> diff --git a/Platform/RaspberryPi/RPi3/RPi3.dsc
> b/Platform/RaspberryPi/RPi3/RPi3.dsc
> index 53825bcf62..b6e3372c61 100644
> --- a/Platform/RaspberryPi/RPi3/RPi3.dsc
> +++ b/Platform/RaspberryPi/RPi3/RPi3.dsc
> @@ -1,6 +1,6 @@
>  # @file
>  #
> -#  Copyright (c) 2011 - 2021, ARM Limited. All rights reserved.
> +#  Copyright (c) 2011 - 2020, ARM Limited. All rights reserved.
>  #  Copyright (c) 2014, Linaro Limited. All rights reserved.
>  #  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
>  #  Copyright (c) 2017 - 2018, Andrei Warkentin
> 
> @@ -512,13 +512,6 @@
>
> gRaspberryPiTokenSpaceGuid.PcdFanOnGpio|L"FanOnGpio"|gConfigDxeFor
> mSetGuid|0x0|0
>
> gRaspberryPiTokenSpaceGuid.PcdFanTemp|L"FanTemp"|gConfigDxeFormSet
> Guid|0x0|0
>
> -  #
> -  # Boot Policy
> -  # 0  - Fast Boot
> -  # 1  - Full Discovery (Connect All)
> -  #
> -
> gRaspberryPiTokenSpaceGuid.PcdBootPolicy|L"BootPolicy"|gConfigDxeForm
> SetGuid|0x0|1
> -
>#
># Reset-related.
>#
> diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc
> b/Platform/RaspberryPi/RPi4/RPi4.dsc
> index 8b9beac64a..07f36e7f1b 100644
> --- a/Platform/RaspberryPi/RPi4/RPi4.dsc
> +++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
> @@ -1,6 +1,6 @@
>  # @file
>  #
> -#  Copyright (c) 2011 - 2021, ARM Limited. All rights reserved.
> +#  Copyright (c) 2011 - 2020, ARM Limited. All rights reserved.
>  #  Copyright (c) 2017 - 2018, Andrei Warkentin
> 
>  #  Copyright (c) 2015 - 2021, Intel Corporation. All rights reserved.
>  #  Copyright (c) 2014, Linaro Limited. All rights reserved.
> @@ -528,13 +528,6 @@
>
> gRaspberryPiTokenSpaceGuid.PcdFanOnGpio|L"FanOnGpio"|gConfigDxeFor
> mSetGuid|0x0|0
>
> gRaspberryPiTokenSpaceGuid.PcdFanTemp|L"FanTemp"|gConfigDxeFormSet
> Guid|0x0|60
>
> -  #
> -  # Boot Policy
> -  # 0  - Fast Boot
> -  # 1  - Full Discovery (Connect All)
> -  #
> -
> gRaspberryPi

Re: [edk2-devel] Proposing a new area of the edk2-test repository

[Samer El-Haj-Mahmoud]

+edk2 list

I am not against adding additional test tools to edk2-test. Just feel like 
there is a need to organize and have a strategy, rather than just use edk2-test 
as a dumping group of miscellaneous tools.

There is already a place for apps under 
https://github.com/tianocore/edk2/tree/master/MdeModulePkg/Application

We also have a number of EDK2 misc applications that use edk2-libc in 
https://github.com/tianocore/edk2-libc/tree/master/AppPkg/Applications

A couple of questions:

  *   Do you expect more apps from WinTestPkg to be contributed to TianoCore? 
And are they all around testing specific Windows requirements? If so, then 
having an edk2-test/WinTestPkg makes sense to me, as you will have a collection 
of useful testing app targeting specific area.
 *   But what about other OSes?
  *   If this is a one-off test app and other WinTestPkg apps are not going to 
be contributed, then does it make sense to put this under 
MdeModulePkg/Application ?



From: Nelson, Eric 
Sent: Wednesday, June 23, 2021 3:10 PM
To: G Edhaya Chandran ; gao...@byosoft.com.cn
Cc: Samer El-Haj-Mahmoud 
Subject: RE: Proposing a new area of the edk2-test repository


Hi Edhay,

Do you have any more questions?
What do you think of creating another directory in edk2-test, for other test 
apps, in addition to uefi-sct, such as ResumeOK.efi?

Thanks,
__e


From: Nelson, Eric
Sent: Tuesday, June 15, 2021 12:00 PM
To: G Edhaya Chandran 
mailto:edhaya.chand...@arm.com>>; 
gao...@byosoft.com.cn<mailto:gao...@byosoft.com.cn>
Cc: Samer El-Haj-Mahmoud 
mailto:samer.el-haj-mahm...@arm.com>>
Subject: RE: Proposing a new area of the edk2-test repository


Hi Edhay,

ResumeOK.efi is a tool I wrote from the HelloWorld example, that validates 
Windows resume from S4 requirements, specifically that the memory-map run-time 
memory regions don't change, and secondly that PCI devices don't disappear from 
the system, both conditions would cause Windows to fail to resume from S4.

You install the tool to the root of the ESP, and set it as the default/top 
entry in the boot manager, and launch it.  (Disable Secure Boot.)

It runs warm, cold, and 60s ACPI RTC wake cycles, infinitely looking for errors.

ResumeOK.efi writes a file to the root of the ESP, ResumeOK.map, which contains 
the ACPI Facs->HardwareSignature, a list of the PCI devices in the system, and 
a copy of its memory map, from the first time it runs.

During each test pass, it runs a barrage of tests:


  1.  Free memory test - does the available memory match the memory map saved 
in ResumeOK.map
  2.  HW signature check - does the system still have the same HW signature as 
saved in the ResumeOK.map
  3.  Allocation test - all the available memory is allocated, and then the 
memory map is checked if the run-time regions match ResumeOK.map.

If any of the tests fail, then the new/missing PCI devices are listed (HW 
signature fail case), or the memory descriptor that changed, it's location, and 
current and previous type and size.

I have received permission from Intel to *try* to release the source under 
Edk2-test.

I've included a 64-bit binary, if you want to give it a test drive.

Make sure Secure Boot is off.
Also, it is required to manually delete any ResumeOK.map on the ESP, before 
beginning a new test pass.

The tool also supports a host of EFI Shell commands:

Resumeok.efi MEMMAP - displays Windows coalesced view of the current memory map
ResumeOK.efi ROKMAP - displays Windows coalesced view of the memory saved in 
ResumeOK.map
ResumeOK.efi RTDATA - displays an analysis of RT_Data pool usage
ResumeOK.efi NORESET - run one test pass, but suppress automatic SX cycling

These are the files that build it:

Edk2\WinTestPkg\Application
Edk2\WinTestPkg\WinTestPkg.dec
Edk2\WinTestPkg\WinTestPkg.dsc
Edk2\WinTestPkg\Application\ResumeOK
Edk2\WinTestPkg\Application\ResumeOK\AcpiTbl.c
Edk2\WinTestPkg\Application\ResumeOK\AcpiTbl.h
Edk2\WinTestPkg\Application\ResumeOK\AppSupport.c
Edk2\WinTestPkg\Application\ResumeOK\BitMap.c
Edk2\WinTestPkg\Application\ResumeOK\BitMap.h
Edk2\WinTestPkg\Application\ResumeOK\EfiFileLib.c
Edk2\WinTestPkg\Application\ResumeOK\EfiFileLib.h
Edk2\WinTestPkg\Application\ResumeOK\pci.c
Edk2\WinTestPkg\Application\ResumeOK\Pci.h
Edk2\WinTestPkg\Application\ResumeOK\ResumeOK.c
Edk2\WinTestPkg\Application\ResumeOK\ResumeOK.h
Edk2\WinTestPkg\Application\ResumeOK\ResumeOK.inf
Edk2\WinTestPkg\Application\ResumeOK\ResumeOK.uni
Edk2\WinTestPkg\Application\ResumeOK\ResumeOKExtra.uni
Edk2\WinTestPkg\Application\ResumeOK\RtData.c
Edk2\WinTestPkg\Application\ResumeOK\TimeBaseLib.c

Thanks,
__e


From: G Edhaya Chandran 
mailto:edhaya.chand...@arm.com>>
Sent: Monday, June 14, 2021 9:36 PM
To: Nelson, Eric mailto:eric.nel...@intel.com>>; 
gao...@byosoft.com.cn<mailto:gao...@byosoft.com.cn>
Cc: Samer El-Haj-Mahmoud 
mailto:samer.el-haj-mahm...@arm.com>>
Subject: RE: Proposing a new area of the edk2-tes

Re: [edk2-devel] [PATCH v3 3/8] SecurityPkg: Create include file for default key content.

[Samer El-Haj-Mahmoud]

Maybe use the MinPlatformPkg for Intel (like what Jiewen recommended) and 
ArmPlatformPkg for Arm?

At least this reduced the per-platform duplication for every platform. But it 
may not cover all architectures/platform families (e.g. AMD, RISC-V?)


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Yao,
> Jiewen via groups.io
> Sent: Tuesday, June 15, 2021 10:23 AM
> To: Grzegorz Bernacki ; devel@edk2.groups.io
> Subject: Re: [edk2-devel] [PATCH v3 3/8] SecurityPkg: Create include file for
> default key content.
>
> I don’t think it is a good idea to put it to security pkg, because it is a 
> platform
> configuration.
>
> If the goal is to create one include file, you can put it to other common
> platform pkg, such as https://github.com/tianocore/edk2-
> platforms/tree/master/Platform/Intel/MinPlatformPkg/Include/Fdf
>
> Thank you
> Yao Jiewen
>
>
> > -Original Message-
> > From: Grzegorz Bernacki 
> > Sent: Tuesday, June 15, 2021 9:40 PM
> > To: Yao, Jiewen ; devel@edk2.groups.io
> > Subject: Re: [PATCH v3 3/8] SecurityPkg: Create include file for default key
> > content.
> >
> > Hi,
> >
> > Adding edk-devel group back in the loop...
> > I removed it by mistake.
> >
> > greg
> >
> > wt., 15 cze 2021 o 14:16 Grzegorz Bernacki  napisał(a):
> > >
> > > It was the original design, but it was changed when RFC was reviewed.
> > > Please see:
> > > https://edk2.groups.io/g/rfc/topic/edk2_devel_rfc_secure/82139806
> > >
> > > I think that having an include file is better than duplicating the
> > > snippet in many platform files. If someone wants to use 1 key, then
> > > the include file can still be used. Of course, if someone wants to use
> > > more, then they must add entries in platform FDF, but still I like the
> > > idea of include file.
> > >
> > > thanks,
> > > greg
> > >
> > > wt., 15 cze 2021 o 13:59 Yao, Jiewen  napisał(a):
> > > >
> > > > I think it is platform policy to decide how many keys. (it could be 1 
> > > > or 3
> or 10).
> > > >
> > > > I recommend to move this to a platform fdf.
> > > >
> > > > Thank you
> > > > Yao Jiewen
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Grzegorz Bernacki 
> > > > > Sent: Tuesday, June 15, 2021 7:07 PM
> > > > > To: Yao, Jiewen 
> > > > > Subject: Re: [PATCH v3 3/8] SecurityPkg: Create include file for 
> > > > > default
> key
> > > > > content.
> > > > >
> > > > > Hi,
> > > > >
> > > > > Thanks for your comments.
> > > > > The idea was to allow the user to specify more than one key. One can
> > > > > use not only Microsoft or Canonical keys, but also generate new keys
> > > > > and use them.
> > > > > I can move the include file to another directory, but which place is
> > > > > the best for it. I thought that since the rest of the functionality is
> > > > > placed in SecurityPkg, I should also place that file there.
> > > > > thanks,
> > > > > greg
> > > > >
> > > > >
> > > > > wt., 15 cze 2021 o 02:52 Yao, Jiewen 
> napisał(a):
> > > > > >
> > > > > > Hi
> > > > > > I am not sure why we hardcode 3 items for each.
> > > > > >
> > > > > > Can we move this fdf to platform pkg, instead of security pkg ?
> > > > > >
> > > > > > Thank you
> > > > > > Yao Jiewen
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Grzegorz Bernacki 
> > > > > > > Sent: Monday, June 14, 2021 5:43 PM
> > > > > > > To: devel@edk2.groups.io
> > > > > > > Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer.El-Haj-
> > > > > > > mahm...@arm.com; sunny.w...@arm.com;
> m...@semihalf.com;
> > > > > > > upstr...@semihalf.com; Yao, Jiewen ;
> Wang,
> > Jian
> > > > > J
> > > > > > > ; Xu, Min M ;
> > > > > > > ler...@redhat.com; sami.muja...@arm.com; af...@apple.com;
> Ni,
> > Ray
> > > > > > > ; Justen, Jordan L
> ;
> > > > > > > rebe...@bsdio.com; gre...@freebsd.org;
> > thomas.abra...@arm.com;
> > > > > Chiu,
> > > > > > > Chasel ; Desimone, Nathaniel L
> > > > > > > ; gaolim...@byosoft.com.cn;
> Dong,
> > Eric
> > > > > > > ; Kinney, Michael D
> > ;
> > > > > Sun,
> > > > > > > Zailiang ; Qian, Yi ;
> > > > > > > gra...@nuviainc.com; r...@semihalf.com; p...@akeo.ie;
> Grzegorz
> > > > > Bernacki
> > > > > > > 
> > > > > > > Subject: [PATCH v3 3/8] SecurityPkg: Create include file for 
> > > > > > > default
> key
> > > > > content.
> > > > > > >
> > > > > > > This commits add file which can be included by platform Flash
> > > > > > > Description File. It allows to specify certificate files, which
> > > > > > > will be embedded into binary file. The content of these files
> > > > > > > can be used to initialize Secure Boot default keys and databases.
> > > > > > >
> > > > > > > Signed-off-by: Grzegorz Bernacki 
> > > > > > > ---
> > > > > > >  SecurityPkg/SecureBootDefaultKeys.fdf.inc | 70
> > 
> > > > > > >  1 file changed, 70 insertions(+)
> > > > > > >  create mode 100644 SecurityPkg/SecureBootDefaultKeys.fdf.inc
> > > > > > >
> > > > > > > diff --git a/SecurityPkg/SecureBootDefaultKeys.fdf.

Re: [edk2-devel] [edk2-non-osi][PATCH 1/1] Platform/RaspberryPi: Update TF-A to v2.5

[Samer El-Haj-Mahmoud]

Acked-by: Samer El-Haj-Mahmoud 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Pete
> Batard via groups.io
> Sent: Tuesday, June 15, 2021 11:27 AM
> To: devel@edk2.groups.io
> Cc: ardb+tianoc...@kernel.org; l...@nuviainc.com
> Subject: [edk2-devel] [edk2-non-osi][PATCH 1/1] Platform/RaspberryPi:
> Update TF-A to v2.5
>
> This is a run-of-the-mill update of the TF-A binaries used by the
> Raspberry Pi 3 and Raspberry Pi 4 platforms, based on the recently
> released TF-A 2.5.
>
> These binaries were built in an open and verifiable manner through
> a GitHub Actions build script (https://github.com/pftf/pitf).
>
> It should be noted that we are only updating the binaries due to the
> existing ones getting a bit old, in case some of the ARM erratas and
> changes, that have been included in the past two TF-A releases, may
> benefit us. However, unless there are changes of direct interest for
> the Pi platform, we are not planning to update these binaries for
> each TF-A release.
>
> Tested for regression on Pi 3 Model B and Pi 4 Model B.
>
> Signed-off-by: Pete Batard 
> ---
>  Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md |  10 +-
>  Platform/RaspberryPi/RPi3/TrustedFirmware/bl1.bin   | Bin 18837 -> 18853
> bytes
>  Platform/RaspberryPi/RPi3/TrustedFirmware/fip.bin   | Bin 53972 -> 53988
> bytes
>  Platform/RaspberryPi/RPi4/TrustedFirmware/Readme.md |   8 
>  Platform/RaspberryPi/RPi4/TrustedFirmware/bl31.bin  | Bin 41067 -> 41067
> bytes
>  5 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md
> b/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md
> index aafbbe9728f5..cd88e0345c91 100644
> --- a/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md
> +++ b/Platform/RaspberryPi/RPi3/TrustedFirmware/Readme.md
> @@ -2,14 +2,14 @@ ARM Trusted Firmware for Raspberry Pi 3
>  ===
>
>
>
>  The `bl1.bin` and `fip.bin` TF-A binaries found in this directory were built
> from the
>
> -[official TF-A 2.3 release](https://git.trustedfirmware.org/TF-A/trusted-
> firmware-a.git/tag/?h=v2.3)
>
> -through an [AppVeyor build
> script](https://github.com/pbatard/pitf/blob/master/appveyor.yml)
>
> +[official TF-A 2.5 release](https://git.trustedfirmware.org/TF-A/trusted-
> firmware-a.git/tag/?h=v2.5)
>
> +through a [GitHub build
> script](https://github.com/pftf/pitf/blob/master/.github/workflows/build.y
> ml)
>
>  that is designed to provide evidence that these binaries match the vanilla 
> TF-
> A source.
>
>
>
> -As per the [AppVeyor build
> log](https://ci.appveyor.com/project/pbatard/pitf/builds/32330098),
>
> +Per the [GitHub Actions
> log](https://github.com/pftf/pitf/runs/2822874196),
>
>  the SHA-256 sums for the blobs can be validated to be as follows:
>
> -- `bl1.bin`:
> `28d70adc6e7041582264874d342bcad992adb8d34c9de5813e661029d0189b3b`
>
> -- `fip.bin`:
> `02a8c3ea9227fbe60ecfc20999db6bb755d0b32fd757a596353e068e1814e171`
>
> +- `bl1.bin`:
> `5ba701a7e977d308a19928e19937107387677d52a1a4d628a5c2bb4e795aae8b`
>
> +- `fip.bin`:
> `0c3f8a3e8192e5dcb3bdc5867976e4277e9d948159a92ee71a54e92cb8dce9a3`
>
>
>
>  For Raspberry Pi 3 usage, TF-A was built using the command:
>
>  ```
>
> diff --git a/Platform/RaspberryPi/RPi3/TrustedFirmware/bl1.bin
> b/Platform/RaspberryPi/RPi3/TrustedFirmware/bl1.bin
> index
> cd3038990a7c9e45d18cde6198d087281b4b4490..edfb46702e801a102c9d18e4
> a52bb4ab9bd72a47 100644
> GIT binary patch
> delta 8026
> zcmZ`;4OCR;nSSrR0}Mh8%rN}x%m7B67(oR^n}!P*qe(VVoU9~i%kX1k)MG**
> ##Yi9
> z(9|@z*2_m?5B7x7)W(_ab`455?51_lB>mB|8!@=2-
> 976dnm^L6f z=;ix+zxRE=_y7BNT}X$7luGff1OCjPk5bCa!SiLx;Lo(w45?3>yDqhP8g+VzN?t+x
> za3Xc?)wGPP@1f(*pvy$09YE_ui| oH
> zzO6NbK5~SzG$~otYl)6Y@xFm4#8T;AufR&%!7Qz|Elay*CEaFH^{}G2o|36EOj
> Nvx
> ze3r0cb&ahp4_vdV`o#7R4u_PQbFGUj^$RCS^DL~?*GSYEx*aJA=cxMdFlj@Iq
> {*^x
> zU@zv!6mqE&l?+v?eGc+f`5x_kp^RvgB#}G(kZS1*fk^mqwa;&%?=gaQaZQ?&
> TU@F8
> zz!?=)>err@1J@Nfcui4)7l8dfu~g3ShV82U6!1HwNggrYg7FluPgevcw!d%i%CJL
> <
> zH8>1@FDU83Z^ifm&qE;TlhwWhGU-H8l24|-
> KSv@Nd~R+pDir)7I0>y@)#m}L9?56H
> z`Mu|MVA4}vspkQ37y6fc*_xf`N?2*j&Li4e;Q+DKie4AW)()D8;i^uoPV6HPZKzi
> C
> zSw#9@Kwx6~zXc`~(#F 4rxj(UdRP9xd2ID
> zB%InrCE 0LBG
> zABPpO)*y-EAthsKeiZZJiAYKJbkY}1XR`o8OH}0Iykc8?R`yx+NzvUv+YM13izj^)
> zeKtUXX_XZzI`_+pqitTbaGA2xJ7BSfjY7&3+xribiPkt)i>FMpC7) zsSysyCKzjXVr>WIXui;jKEh#UVf~em_#e|VCd{r8tKxEIjX_vxpwE(JL)y`%2GU7x
> zCsNw?;$TOi{x`&r;$|!(99Rm*G{XBj@7(u8HLw`_oY>bA+cz!BlL*H-
> 5+)fH3Gw%U
> z_4)CI-s)9-HP!j!#7C-z{=pqf$vCciRiE8VjfaWcSWk7h

Re: [edk2-devel] [edk2-test][PATCH v2 1/1] uefi-sct/SctPkg: Not create event with TPL_HIGH_LEVEL

[Samer El-Haj-Mahmoud]

Reviewed-By: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Heinrich Schuchardt 
> Sent: Friday, June 11, 2021 5:15 AM
> To: Sunny Wang ; devel@edk2.groups.io
> Cc: Samer El-Haj-Mahmoud ; G Edhaya
> Chandran ; Barton Gao
> ; Michael D Kinney 
> Subject: Re: [edk2-test][PATCH v2 1/1] uefi-sct/SctPkg: Not create event
> with TPL_HIGH_LEVEL
>
> On 11.06.21 10:35, Sunny Wang wrote:
> > The commits a9d1fb58 and ae7e5477b555 caused SCT BS.CreateEvent
> failures.
> >
> > Section 7.1 of the UEFI Spec states that TPL_HIGH_LEVEL is designed for
> > exclusive use by the firmware. The creation of events by UEFI
> > applications, UEFI drivers, and UEFI OS Loaders should not use this TPL
> > level.
> >
> > Therefore, revert TPL_HIGH_LEVEL change in commits a9d1fb58 and
> > ae7e5477b555 to not create event with TPL_HIGH_LEVEL to be compliant
> > with UEFI Spec and fix the failures.
> >
> > For more information, https://edk2.groups.io/g/devel/message/76338
> >
> > Cc: Samer El-Haj-Mahmoud 
> > Cc: G Edhaya Chandran 
> > Cc: Barton Gao 
> > Cc: Heinrich Schuchardt 
> > Cc: Michael D Kinney 
> > Signed-off-by: Sunny Wang 
>
> Acked-by: Heinrich Schuchardt 
>
> > ---
> >  .../EventTimerTaskPriorityServicesBBTestCreateEvent.c| 5 +
> >  .../EventTimerTaskPriorityServicesBBTestCreateEventEx.c  | 4 +---
> >  2 files changed, 2 insertions(+), 7 deletions(-)
> >
> > diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/
> BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEvent.c b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/
> BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEvent.c
> > index a7e7366e..d5c033f7 100644
> > --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/
> BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEvent.c
> > +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/
> BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEvent.c
> > @@ -2,6 +2,7 @@
> >
> >Copyright 2006 - 2012 Unified EFI, Inc.
> >Copyright (c) 2010 - 2012, Intel Corporation. All rights reserved.
> > +  Copyright (c) 2021, ARM Limited. All rights reserved.
> >
> >This program and the accompanying materials
> >are licensed and made available under the terms and conditions of the
> BSD License
> > @@ -190,7 +191,6 @@ BBTestCreateEvent_Conf_Sub1 (
> >EFI_TPL NotifyTpls[] = {
> >  TPL_CALLBACK,
> >  TPL_NOTIFY,
> > -TPL_HIGH_LEVEL,
> >  0
> >};
> >EFI_TEST_ASSERTION  AssertionType;
> > @@ -342,7 +342,6 @@ BBTestCreateEvent_Conf_Sub3 (
> >EFI_TPL NotifyTpls[] = {
> >  TPL_CALLBACK,
> >  TPL_NOTIFY,
> > -TPL_HIGH_LEVEL,
> >  0
> >};
> >EFI_TEST_ASSERTION  AssertionType;
> > @@ -407,7 +406,6 @@ BBTestCreateEvent_Conf_Sub4 (
> >EFI_TPL NotifyTpls[] = {
> >  TPL_CALLBACK,
> >  TPL_NOTIFY,
> > -TPL_HIGH_LEVEL,
> >  0
> >};
> >EFI_TEST_ASSERTION  AssertionType;
> > @@ -482,7 +480,6 @@ BBTestCreateEvent_Func_Sub1 (
> >EFI_TPL NotifyTpls[] = {
> >  TPL_CALLBACK,
> >  TPL_NOTIFY,
> > -TPL_HIGH_LEVEL,
> >  0
> >};
> >EFI_TEST_ASSERTION  AssertionType;
> > diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/
> BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEventEx.c b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/
> BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEventEx.c
> > index eb458de5..03b7ae6e 100644
> > --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/
> BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEventEx.c
> > +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/EventTimerTaskPriorityServices/
> BlackBoxTest/EventTimerTaskPriorityServicesBBTestCreateEventEx.c
> > @@ -2,6 +2,7 @@
> >
> >Co

Re: [edk2-devel] [PATCH v3 0/2] Dynamically build UARTs info in ACPI

[Samer El-Haj-Mahmoud]

CCing the maintainers and reviewers

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Sunny
> Wang via groups.io
> Sent: Monday, May 31, 2021 4:23 AM
> To: devel@edk2.groups.io
> Cc: Sunny Wang 
> Subject: [edk2-devel] [PATCH v3 0/2] Dynamically build UARTs info in ACPI
>
> In v3: Address comments given by Jeremy and Matio on v2.
> In v2: Address comments given by Pete on v1.
>
> Dynamically build UARTs info in ACPI so that it can match the UART
> related settings defined in config.txt
>
> Sunny Wang (2):
>   Platform/RaspberryPi: Dynamically build UARTs info in ACPI
>   Platform/RaspberryPi: Enable Bluetooth and UART in Windows OS
>
>  .../RaspberryPi/AcpiTables/AcpiTables.inf |   8 +-
>  .../RaspberryPi/AcpiTables/Dbg2MiniUart.aslc  |  81 +
>  .../AcpiTables/{Dbg2.aslc => Dbg2Pl011.aslc}  |  30 +---
>  .../RaspberryPi/AcpiTables/SpcrMiniUart.aslc  |  91 ++
>  .../AcpiTables/{Spcr.aslc => SpcrPl011.aslc}  |  10 +-
>  Platform/RaspberryPi/AcpiTables/Uart.asl  | 158 +-
>  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c |  48 +-
>  .../Drivers/ConfigDxe/ConfigDxe.inf   |   1 +
>  .../IndustryStandard/RpiDebugPort2Table.h |  33 
>  Platform/RaspberryPi/Include/UartSelection.h  |  20 +++
>  Platform/RaspberryPi/RPi3/RPi3.dsc|   8 +
>  Platform/RaspberryPi/RPi4/RPi4.dsc|   8 +
>  Platform/RaspberryPi/RaspberryPi.dec  |   1 +
>  13 files changed, 413 insertions(+), 84 deletions(-)
>  create mode 100644 Platform/RaspberryPi/AcpiTables/Dbg2MiniUart.aslc
>  rename Platform/RaspberryPi/AcpiTables/{Dbg2.aslc => Dbg2Pl011.aslc}
> (72%)
>  create mode 100644 Platform/RaspberryPi/AcpiTables/SpcrMiniUart.aslc
>  rename Platform/RaspberryPi/AcpiTables/{Spcr.aslc => SpcrPl011.aslc} (87%)
>  create mode 100644
> Platform/RaspberryPi/Include/IndustryStandard/RpiDebugPort2Table.h
>  create mode 100644 Platform/RaspberryPi/Include/UartSelection.h
>
> --
> 2.31.0.windows.1
>
>
>
> 
>

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#75967): https://edk2.groups.io/g/devel/message/75967
Mute This Topic: https://groups.io/mt/83205743/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 3/6] Marvell: Armada7k8k/OcteonTx: Switch SPCR UART subtype to 0x1

[Samer El-Haj-Mahmoud]

That being said, for this particular patch

Reviewed-By: Samer El-Haj-Mahmoud 


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Samer
> El-Haj-Mahmoud via groups.io
> Sent: Monday, May 24, 2021 7:07 AM
> To: Marcin Wojtas ; devel@edk2.groups.io
> Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Sunny Wang
> ; g...@semihalf.com; upstr...@semihalf.com;
> Samer El-Haj-Mahmoud 
> Subject: Re: [edk2-devel] [edk2-platforms PATCH 3/6] Marvell:
> Armada7k8k/OcteonTx: Switch SPCR UART subtype to 0x1
>
> Thanks for the patch.
>
> Not an issue with this patch specifically, but it seems this #define
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_
> 16450 should probably be renamed to reflect the latest spec (at
> https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-
> debug-port-table), which says:
>
> 0x0001  :  16550 subset compatible with DBGP Revision 1
>
> Maybe you could send another patch to do this in
> SerialPortConsoleRedirectionTable.h ? Hopefully before this value is used by
> other platforms (this patch introduces the first usage of this value in edk2
> and edk2-platforms)
>
>
>
> > -Original Message-
> > From: Marcin Wojtas 
> > Sent: Monday, May 24, 2021 1:29 AM
> > To: devel@edk2.groups.io
> > Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer El-Haj-
> Mahmoud
> > ; Sunny Wang
> > ; g...@semihalf.com; upstr...@semihalf.com;
> > Marcin Wojtas 
> > Subject: [edk2-platforms PATCH 3/6] Marvell: Armada7k8k/OcteonTx:
> Switch
> > SPCR UART subtype to 0x1
> >
> > DBG2 ACPI table description [1] specifies three subtypes
> > related to 16550 UART:
> > 0x0 - 16550 compatible
> > 0x1 - 16550 subset
> > 0x12 - 16550 compatible with parameters defined in
> >Generic Address Structure (GAS)
> >
> > It turned out however, that the Windows OS treats 0x0 subtype as
> > legacy x86 UART with 8-bit access. ARM SoCs can use types 0x1 (16550 with
> > fixed mmio32 access) or 0x12 (16550 with fully respected GAS contents).
> >
> > Switch Marvell SoCs ACPI UART subtype to 0x1 - thanks to that the
> > same firmware can run properly with UART output in Windows 10, Linux
> > and ESXI hypervisor.
> >
> > [1] https://docs.microsoft.com/en-us/windows-
> > hardware/drivers/bringup/acpi-debug-port-table
> >
> > Signed-off-by: Marcin Wojtas 
> > ---
> >  Silicon/Marvell/Armada7k8k/AcpiTables/Spcr.aslc   | 2 +-
> >  Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Silicon/Marvell/Armada7k8k/AcpiTables/Spcr.aslc
> > b/Silicon/Marvell/Armada7k8k/AcpiTables/Spcr.aslc
> > index 438cf7880e..6efc175bdf 100644
> > --- a/Silicon/Marvell/Armada7k8k/AcpiTables/Spcr.aslc
> > +++ b/Silicon/Marvell/Armada7k8k/AcpiTables/Spcr.aslc
> > @@ -22,7 +22,7 @@
> > EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE Spcr = {
> >  EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE,
> >
> >
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_REVISION
> >
> >),
> >
> > -
> >
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_
> > 16550,  // InterfaceType
> >
> > +
> >
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_
> > 16450,  // InterfaceType
> >
> >{ EFI_ACPI_RESERVED_BYTE,
> >
> >  EFI_ACPI_RESERVED_BYTE,
> >
> >  EFI_ACPI_RESERVED_BYTE },   // 
> > Reserved1[3]
> >
> > diff --git a/Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc
> > b/Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc
> > index f663d8ade8..2a3415f0a6 100644
> > --- a/Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc
> > +++ b/Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc
> > @@ -22,7 +22,7 @@
> > EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE Spcr = {
> >  EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE,
> >
> >
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_REVISION
> >
> >),
> >
> > -
> >
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_
> > 16550,  // InterfaceType
> >
> > +
> >
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_
> > 16450,  // InterfaceType
> >
> >{ EFI_ACPI_RESERVED_BYTE,
> >
> >  EFI_ACPI_RESERVED_BYTE,
> >
> >  EFI_ACPI_RESERVED_BYTE },   // 
> > Reserved1[3]
> >

Re: [edk2-devel] [edk2-platforms PATCH 1/6] Marvell/Drivers: SmbiosPlatformDxe: Align Type17 to SMBIOS v3.2

[Samer El-Haj-Mahmoud]

Reviewed-by: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Marcin Wojtas 
> Sent: Monday, May 24, 2021 1:29 AM
> To: devel@edk2.groups.io
> Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud
> ; Sunny Wang
> ; g...@semihalf.com; upstr...@semihalf.com;
> Marcin Wojtas 
> Subject: [edk2-platforms PATCH 1/6] Marvell/Drivers: SmbiosPlatformDxe:
> Align Type17 to SMBIOS v3.2
>
> This patch adds missing entries required for SMBIOS v3.2 compliance
> of the Type17 table. On the occasion improve Type4 table contents.
>
> Signed-off-by: Marcin Wojtas 
> ---
>  Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c | 39
> ++--
>  1 file changed, 35 insertions(+), 4 deletions(-)
>
> diff --git a/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> b/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> index 2ecaec2af5..a99291e902 100644
> --- a/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> +++ b/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
> @@ -181,7 +181,7 @@ STATIC SMBIOS_TABLE_TYPE4 mArmadaDefaultType4
> = {
>3, //version
>
>{0,0,0,0,0,1}, //voltage
>
>0, //external clock
>
> -  2000,  //max speed
>
> +  2200,  //max speed
>
>0, //current speed - requires update
>
>0x41,  //status
>
>ProcessorUpgradeOther,
>
> @@ -196,6 +196,9 @@ STATIC SMBIOS_TABLE_TYPE4 mArmadaDefaultType4
> = {
>4, //threads per socket
>
>0xEC,  //processor characteristics
>
>ProcessorFamilyARM, //ARM core
>
> +  0, // CoreCount2;
>
> +  0, // EnabledCoreCount2;
>
> +  0, // ThreadCount2;
>
>  };
>
>
>
>  STATIC CHAR8 CONST *mArmadaDefaultType4Strings[] = {
>
> @@ -457,7 +460,7 @@ STATIC SMBIOS_TABLE_TYPE17
> mArmadaDefaultType17 = {
>0,  //Memory size obtained dynamically
>
>MemoryFormFactorRowOfChips,  //Memory factor
>
>0,   //Not part of a set
>
> -  1,   //Right side of board
>
> +  1,   //Location
>
>2,   //Bank 0
>
>MemoryTypeDdr4,  //DDR4
>
>{0,0,0,0,0,0,0,0,0,0,0,0,0,0,1}, //unbuffered
>
> @@ -467,10 +470,36 @@ STATIC SMBIOS_TABLE_TYPE17
> mArmadaDefaultType17 = {
>0, //asset tag
>
>0, //part number
>
>0, //rank
>
> +  0, // ExtendedSize; (since Size < 32GB-1)
>
> +  0, // ConfiguredMemoryClockSpeed - initialized at runtime
>
> +  0, // MinimumVoltage; (unknown)
>
> +  0, // MaximumVoltage; (unknown)
>
> +  0, // ConfiguredVoltage; (unknown)
>
> +  MemoryTechnologyDram, // MemoryTechnology
>
> +  {{// MemoryOperatingModeCapability
>
> +0,  // Reserved:1;
>
> +0,  // Other   :1;
>
> +0,  // Unknown :1;
>
> +1,  // VolatileMemory  :1;
>
> +0,  // ByteAccessiblePersistentMemory  :1;
>
> +0,  // BlockAccessiblePersistentMemory :1;
>
> +0   // Reserved:10;
>
> +  }},
>
> +  0, // FirwareVersion
>
> +  0, // ModuleManufacturerID (unknown)
>
> +  0, // ModuleProductID (unknown)
>
> +  0, // MemorySubsystemControllerManufacturerID (unknown)
>
> +  0, // MemorySubsystemControllerProductID (unknown)
>
> +  0, // NonVolatileSize
>
> +  0, // VolatileSize - initialized at runtime
>
> +  0, // CacheSize
>
> +  0, // LogicalSize
>
> +  0, // ExtendedSpeed,
>
> +  0  // ExtendedConfiguredMemorySpeed
>
>  };
>
>
>
>  STATIC CHAR8 CONST *mArmadaDefaultType17Strings[] = {
>
> -  "RIGHT SIDE\0", /* location */
>
> +  "DIMM SLOT\0",  /* location */
>
>"BANK 0\0", /* bank description */
>
>NULL
>
>  };
>
> @@ -735,9 +764,10 @@ SmbiosMemoryInstall (
>}
>
>
>
>//
>
> -  // Update TYPE17 memory size field
>
> +  // Update TYPE17 memory size fields
>
>//
>
>mArmadaDefaultType17.Size = (UINT16)(MemorySize >> 20);
>
> +  mArmadaDefaultType17.VolatileSize = MemorySize;
>
>
>
>return EFI_SUCCESS;
>
>  }
>
> @@ -767,6 +797,7 @@ SmbiosInstallAllStructures (
>mArmadaDefaultType0.SystemBiosMinorRelease =
> FirmwareMinorRevisionNumber;
>
>mArmadaDefaultType4.CurrentSpeed =

Re: [edk2-devel] [edk2-platforms PATCH 5/6] Marvell: RealTimeClockLib: Fix daylight and timezone handling

[Samer El-Haj-Mahmoud]

Reviewed-by: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Marcin Wojtas 
> Sent: Monday, May 24, 2021 1:29 AM
> To: devel@edk2.groups.io
> Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud
> ; Sunny Wang
> ; g...@semihalf.com; upstr...@semihalf.com;
> Marcin Wojtas 
> Subject: [edk2-platforms PATCH 5/6] Marvell: RealTimeClockLib: Fix daylight
> and timezone handling
>
> The Marvell implementation of the RealTimeClockLib was unnecessarily
> overriding the daylight and timezone values, which are handled
> by non-volatile variables in the generic code. Fix that.
>
> Signed-off-by: Marcin Wojtas 
> ---
>  Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c |
> 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git
> a/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c
> b/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c
> index 40ab01ed41..a48d44ed83 100644
> ---
> a/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c
> +++
> b/Silicon/Marvell/Armada7k8k/Library/RealTimeClockLib/RealTimeClockLib.c
> @@ -79,9 +79,6 @@ LibGetTime (
>// Convert from internal 32-bit time to UEFI time
>
>EpochToEfiTime (RegVal, Time);
>
>
>
> -  Time->TimeZone = EFI_UNSPECIFIED_TIMEZONE;
>
> -  Time->Daylight = 0;
>
> -
>
>return Status;
>
>  }
>
>
>
> --
> 2.29.0

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#75511): https://edk2.groups.io/g/devel/message/75511
Mute This Topic: https://groups.io/mt/83044531/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 3/6] Marvell: Armada7k8k/OcteonTx: Switch SPCR UART subtype to 0x1

[Samer El-Haj-Mahmoud]

Thanks for the patch.

Not an issue with this patch specifically, but it seems this #define 
EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_16450 should 
probably be renamed to reflect the latest spec (at 
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/acpi-debug-port-table),
 which says:

0x0001  :  16550 subset compatible with DBGP Revision 1

Maybe you could send another patch to do this in 
SerialPortConsoleRedirectionTable.h ? Hopefully before this value is used by 
other platforms (this patch introduces the first usage of this value in edk2 
and edk2-platforms)



> -Original Message-
> From: Marcin Wojtas 
> Sent: Monday, May 24, 2021 1:29 AM
> To: devel@edk2.groups.io
> Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud
> ; Sunny Wang
> ; g...@semihalf.com; upstr...@semihalf.com;
> Marcin Wojtas 
> Subject: [edk2-platforms PATCH 3/6] Marvell: Armada7k8k/OcteonTx: Switch
> SPCR UART subtype to 0x1
>
> DBG2 ACPI table description [1] specifies three subtypes
> related to 16550 UART:
> 0x0 - 16550 compatible
> 0x1 - 16550 subset
> 0x12 - 16550 compatible with parameters defined in
>Generic Address Structure (GAS)
>
> It turned out however, that the Windows OS treats 0x0 subtype as
> legacy x86 UART with 8-bit access. ARM SoCs can use types 0x1 (16550 with
> fixed mmio32 access) or 0x12 (16550 with fully respected GAS contents).
>
> Switch Marvell SoCs ACPI UART subtype to 0x1 - thanks to that the
> same firmware can run properly with UART output in Windows 10, Linux
> and ESXI hypervisor.
>
> [1] https://docs.microsoft.com/en-us/windows-
> hardware/drivers/bringup/acpi-debug-port-table
>
> Signed-off-by: Marcin Wojtas 
> ---
>  Silicon/Marvell/Armada7k8k/AcpiTables/Spcr.aslc   | 2 +-
>  Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Silicon/Marvell/Armada7k8k/AcpiTables/Spcr.aslc
> b/Silicon/Marvell/Armada7k8k/AcpiTables/Spcr.aslc
> index 438cf7880e..6efc175bdf 100644
> --- a/Silicon/Marvell/Armada7k8k/AcpiTables/Spcr.aslc
> +++ b/Silicon/Marvell/Armada7k8k/AcpiTables/Spcr.aslc
> @@ -22,7 +22,7 @@
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE Spcr = {
>  EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE,
>
>  EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_REVISION
>
>),
>
> -
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_
> 16550,  // InterfaceType
>
> +
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_
> 16450,  // InterfaceType
>
>{ EFI_ACPI_RESERVED_BYTE,
>
>  EFI_ACPI_RESERVED_BYTE,
>
>  EFI_ACPI_RESERVED_BYTE },   // 
> Reserved1[3]
>
> diff --git a/Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc
> b/Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc
> index f663d8ade8..2a3415f0a6 100644
> --- a/Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc
> +++ b/Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc
> @@ -22,7 +22,7 @@
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE Spcr = {
>  EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE,
>
>  EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_REVISION
>
>),
>
> -
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_
> 16550,  // InterfaceType
>
> +
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_
> 16450,  // InterfaceType
>
>{ EFI_ACPI_RESERVED_BYTE,
>
>  EFI_ACPI_RESERVED_BYTE,
>
>  EFI_ACPI_RESERVED_BYTE },   // 
> Reserved1[3]
>
> --
> 2.29.0

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#75510): https://edk2.groups.io/g/devel/message/75510
Mute This Topic: https://groups.io/mt/83044529/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 4/6] Marvell/Cn913xDbA: AcpiTables: Use unique UID's

[Samer El-Haj-Mahmoud]

Reviewed-By: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Marcin Wojtas 
> Sent: Monday, May 24, 2021 1:29 AM
> To: devel@edk2.groups.io
> Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud
> ; Sunny Wang
> ; g...@semihalf.com; upstr...@semihalf.com;
> Marcin Wojtas 
> Subject: [edk2-platforms PATCH 4/6] Marvell/Cn913xDbA: AcpiTables: Use
> unique UID's
>
> The CN9131 variant's SSDT comprised UID's, whose values
> overlapped the ones used in the main DSDT file. Fix that.
>
> Signed-off-by: Marcin Wojtas 
> ---
>  Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA/Ssdt.asl | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA/Ssdt.asl
> b/Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA/Ssdt.asl
> index dc32fe836a..691a709c18 100644
> --- a/Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA/Ssdt.asl
> +++ b/Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA/Ssdt.asl
> @@ -18,7 +18,7 @@ DefinitionBlock ("Cn9131DbASsdt.aml", "SSDT", 2,
> "MVEBU ", "CN9131", 3)
>  Device (AHC1)
>
>  {
>
>  Name (_HID, "LNRO001E") // _HID: Hardware ID
>
> -Name (_UID, 0x00)   // _UID: Unique ID
>
> +Name (_UID, 0x01)   // _UID: Unique ID
>
>  Name (_CCA, 0x01)   // _CCA: Cache Coherency Attribute
>
>  Name (_CLS, Package (0x03)  // _CLS: Class Code
>
>  {
>
> @@ -43,7 +43,7 @@ DefinitionBlock ("Cn9131DbASsdt.aml", "SSDT", 2,
> "MVEBU ", "CN9131", 3)
>  Device (XHC2)
>
>  {
>
>  Name (_HID, "PNP0D10")  // _HID: Hardware ID
>
> -Name (_UID, 0x01)   // _UID: Unique ID
>
> +Name (_UID, 0x02)   // _UID: Unique ID
>
>  Name (_CCA, 0x01)   // _CCA: Cache Coherency Attribute
>
>
>
>  Name (_CRS, ResourceTemplate ()  // _CRS: Current Resource 
> Settings
>
> @@ -62,7 +62,7 @@ DefinitionBlock ("Cn9131DbASsdt.aml", "SSDT", 2,
> "MVEBU ", "CN9131", 3)
>  {
>
>  Name (_HID, "MRVL0110") // _HID: 
> Hardware ID
>
>  Name (_CCA, 0x01)   // 
> Cache-coherent controller
>
> -Name (_UID, 0x00)   // _UID: 
> Unique ID
>
> +Name (_UID, 0x01)   // _UID: 
> Unique ID
>
>  Name (_CRS, ResourceTemplate ()
>
>  {
>
>  Memory32Fixed (ReadWrite, 0xf400 , 0x10)
>
> --
> 2.29.0

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#75509): https://edk2.groups.io/g/devel/message/75509
Mute This Topic: https://groups.io/mt/83044530/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 2/6] Marvell: Armada7k8k/OcteonTx: Fix RT debug prints

[Samer El-Haj-Mahmoud]

Reviewed-By: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Marcin Wojtas 
> Sent: Monday, May 24, 2021 1:29 AM
> To: devel@edk2.groups.io
> Cc: l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud
> ; Sunny Wang
> ; g...@semihalf.com; upstr...@semihalf.com;
> Marcin Wojtas 
> Subject: [edk2-platforms PATCH 2/6] Marvell: Armada7k8k/OcteonTx: Fix RT
> debug prints
>
> Resolution of the DebugLib for the DXE_RUNTIME_DRIVER library
> class was limited to non-RELEASE builds. This caused crashes
> during FWTS in case the RT attempted to use UART. Fix that
> by allowing to use DxeRuntimeDebugLibSerialPort in all kind
> of builds.
>
> Signed-off-by: Marcin Wojtas 
> ---
>  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> index 4cdafe8b1f..939fbf14d9 100644
> --- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> +++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> @@ -195,9 +195,7 @@
>  !else
>
>
> CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.i
> nf
>
>  !endif
>
> -!if $(TARGET) != RELEASE
>
>
> DebugLib|MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDeb
> ugLibSerialPort.inf
>
> -!endif
>
>
> VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLi
> bRuntimeDxe.inf
>
>
>
>  [LibraryClasses.ARM, LibraryClasses.AARCH64]
>
> --
> 2.29.0

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH 1/1] MdePkg: Add new 16550-compatible Serial Port Subtypes to DBG2

[Samer El-Haj-Mahmoud]

Reviewed-by: Samer El-Haj-Mahmoud 


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Marcin
> Wojtas via groups.io
> Sent: Sunday, May 23, 2021 5:15 AM
> To: devel@edk2.groups.io
> Cc: liming@intel.com; michael.d.kin...@intel.com; l...@nuviainc.com;
> ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud  mahm...@arm.com>; Sunny Wang ;
> g...@semihalf.com; upstr...@semihalf.com; Marcin Wojtas
> 
> Subject: [edk2-devel] [PATCH 1/1] MdePkg: Add new 16550-compatible
> Serial Port Subtypes to DBG2
>
> The Microsoft Debug Port Table 2 (DBG2) specification revision
> May 31, 2017 adds support for 16550-compatible Serial Port
> Subtype with parameters defined in Generic Address Structure (GAS) [1]
>
> Reflect that in the EDK2 headers.
>
> [1] https://docs.microsoft.com/en-us/windows-
> hardware/drivers/bringup/acpi-debug-port-table
>
> Signed-off-by: Marcin Wojtas 
> ---
>  MdePkg/Include/IndustryStandard/DebugPort2Table.h   | 1 +
>  MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h | 5
> +
>  2 files changed, 6 insertions(+)
>
> diff --git a/MdePkg/Include/IndustryStandard/DebugPort2Table.h
> b/MdePkg/Include/IndustryStandard/DebugPort2Table.h
> index 3faa30b76a..9ccfc1b1ee 100644
> --- a/MdePkg/Include/IndustryStandard/DebugPort2Table.h
> +++ b/MdePkg/Include/IndustryStandard/DebugPort2Table.h
> @@ -47,6 +47,7 @@ typedef struct {
>  #define
> EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_ARM_SBSA_GENERIC_UART
> 0x000e
>
>  #define   EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_DCC
> 0x000f
>
>  #define   EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_BCM2835_UART
> 0x0010
>
> +#define   EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_16550_WITH_GAS
> 0x0012
>
>  #define EFI_ACPI_DBG2_PORT_TYPE_1394 
>   0x8001
>
>  #define   EFI_ACPI_DBG2_PORT_SUBTYPE_1394_STANDARD
> 0x
>
>  #define EFI_ACPI_DBG2_PORT_TYPE_USB  
>   0x8002
>
> diff --git
> a/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> b/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> index 2066c7895e..7796796afe 100644
> ---
> a/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> +++
> b/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> @@ -100,6 +100,11 @@ typedef struct {
>  ///
>
>  #define
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_
> BCM2835_UART  0x10
>
>
>
> +///
>
> +/// 16550-compatible with parameters defined in Generic Address Structure
>
> +///
>
> +#define
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_
> 16550_WITH_GAS0x12
>
> +
>
>  //
>
>  // Interrupt Type
>
>  //
>
> --
> 2.29.0
>
>
>
> -=-=-=-=-=-=
> Groups.io Links: You receive all messages sent to this group.
> View/Reply Online (#75464): https://edk2.groups.io/g/devel/message/75464
> Mute This Topic: https://groups.io/mt/83024903/1945644
> Group Owner: devel+ow...@edk2.groups.io
> Unsubscribe: https://edk2.groups.io/g/devel/unsub [samer.el-haj-
> mahm...@arm.com]
> -=-=-=-=-=-=
>

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH 1/1] MdePkg: Add new 16550-compatible Serial Port Subtypes to DBG2

[Samer El-Haj-Mahmoud]

Sunny,

I think the issue is outlook removing the extra line breaks. To disable this do 
the following (per 
https://docs.microsoft.com/en-us/outlook/troubleshoot/message-body/line-breaks-are-removed-in-posts-made-in-plain-text)

Open Outlook.
On the File tab, select Options.
In the Options dialog, select Mail.
In the Message format section, clear the Remove extra line breaks in plain text 
messages check box.
Select OK.


> -Original Message-
> From: Marcin Wojtas 
> Sent: Monday, May 24, 2021 4:51 AM
> To: edk2-devel-groups-io ;
> gaolim...@byosoft.com.cn
> Cc: Sunny Wang ; Kinney, Michael D
> ; Leif Lindholm ; Ard
> Biesheuvel ; Samer El-Haj-Mahmoud
> ; Grzegorz Bernacki
> ; upstr...@semihalf.com
> Subject: Re: [edk2-devel] [PATCH 1/1] MdePkg: Add new 16550-compatible
> Serial Port Subtypes to DBG2
>
> Hi Liming,
>
> pon., 24 maj 2021 o 10:42 gaoliming  napisał(a):
> >
> > You can run BaseTools\Scripts\PatchCheck.py -1 to check the patch format.
> >
>
> Sure, I ran it prior to submission.
>
> Best regards,
> Marcin
>
> > Thanks
> > Liming
> > > -邮件原件-
> > > 发件人: devel@edk2.groups.io  代表 Sunny
> Wang
> > > 发送时间: 2021年5月24日 11:21
> > > 收件人: Marcin Wojtas 
> > > 抄送: devel@edk2.groups.io; michael.d.kin...@intel.com;
> > > l...@nuviainc.com; ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud
> > > ; g...@semihalf.com;
> > > upstr...@semihalf.com; gaolim...@byosoft.com.cn; Sunny Wang
> > > 
> > > 主题: Re: [edk2-devel] [PATCH 1/1] MdePkg: Add new 16550-compatible
> > > Serial Port Subtypes to DBG2
> > >
> > > Add Liming's new email.
> > >
> > > Hi Marcin,
> > >
> > > There seems no LF (0A).
> > > 1. From the patch I got below in this email, several lines got merged into
> one
> > > line.
> > > >  #define
> > > EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_ARM_SBSA_GENERIC_UART
> > > 0x000e #define   EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_DCC
> > > 0x000f #define
> EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_BCM2835_UART
> > > 0x0010+#define
> > > EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_16550_WITH_GAS
> > > 0x0012 #define EFI_ACPI_DBG2_PORT_TYPE_1394
> > > 0x8001 #define   EFI_ACPI_DBG2_PORT_SUBTYPE_1394_STANDARD
> > > 0x #define EFI_ACPI_DBG2_PORT_TYPE_USB
> > >
> > > 2. In
> > >
> https://edk2.groups.io/g/devel/topic/patch_1_1_mdepkg_add_new/830249
> > > 03?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,83024903, I saw "=0D"
> > > appending to each line. I'm not sure if this is relevant.
> > >
> > > Moreover, I don't see #1 and #2 in another similar code change
> > >
> https://edk2.groups.io/g/devel/message/75283?p=,,,20,0,0,0::relevance,,M
> d
> > >
> ePkg%3A+Update+DBG2+and+SPCR+header+with+NVIDIA+16550+Subtype,
> 2
> > > 0,2,0,82919032.
> > >
> > > Of course, if this won't cause any issue with pushing the patch, I'm 
> > > totally
> fine
> > > with this.
> > >
> > > Reviewed-by: Sunny Wang 
> > >
> > >
> > > Best Regards,
> > > Sunny Wang
> > >
> > > -Original Message-
> > > From: Marcin Wojtas 
> > > Sent: Monday, May 24, 2021 10:21 AM
> > > To: Sunny Wang 
> > > Cc: devel@edk2.groups.io; michael.d.kin...@intel.com;
> l...@nuviainc.com;
> > > ardb+tianoc...@kernel.org; Samer El-Haj-Mahmoud
> > > ; g...@semihalf.com;
> > > upstr...@semihalf.com
> > > Subject: Re: [edk2-devel] [PATCH 1/1] MdePkg: Add new 16550-
> compatible
> > > Serial Port Subtypes to DBG2
> > >
> > > Hi Sunny,
> > >
> > >
> > > pon., 24 maj 2021 o 04:09 Sunny Wang 
> napisał(a):
> > > >
> > > > Looks good, Marcin.
> > > > However, it looks like something wrong with the line-ending. Could you
> > > check if your line-ending setting is CR/LF? Did you use
> > > /edk2/BaseTools/Scripts/PatchCheck.py tool to check your patch? If not,
> could
> > > you use it? I expect this tool can catch the line-ending problem.
> > >
> > > The line endings are fine in my repo, I generated and sent the patch as
> usual.
> > >
> > > And of course prior to sending I ran PatchCheck.py - it complains only
> about
> > > too long URL line in the commit message, but the line-endings are ok.
> > >
> > > $ python3
> > > /home/mw/git/edk2-workspace/edk2/BaseTools/Scripts/PatchCheck.py
>

Re: [edk2-devel] [PATCH 1/1] MdePkg: Update DBG2 and SPCR header with NVIDIA 16550 Subtype

[Samer El-Haj-Mahmoud]

Reviewed-by: Samer El-Haj-Mahmoud 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ashish
> Singhal via groups.io
> Sent: Tuesday, May 18, 2021 2:38 PM
> To: devel@edk2.groups.io; michael.d.kin...@intel.com;
> gaolim...@byosoft.com.cn; zhiguang@intel.com
> Cc: Ashish Singhal 
> Subject: [edk2-devel] [PATCH 1/1] MdePkg: Update DBG2 and SPCR header with
> NVIDIA 16550 Subtype
>
> Add macros for NVIDIA 16550 UART specific debug port subtype in both
> DBG2 as well as SPCR header file.
>
> Signed-off-by: Ashish Singhal 
>
> ---
>  MdePkg/Include/IndustryStandard/DebugPort2Table.h| 1 +
>  .../IndustryStandard/SerialPortConsoleRedirectionTable.h | 5 +
>  2 files changed, 6 insertions(+)
>
> diff --git a/MdePkg/Include/IndustryStandard/DebugPort2Table.h
> b/MdePkg/Include/IndustryStandard/DebugPort2Table.h
> index 3faa30b76a..6a6fd2590e 100644
> --- a/MdePkg/Include/IndustryStandard/DebugPort2Table.h
> +++ b/MdePkg/Include/IndustryStandard/DebugPort2Table.h
> @@ -43,6 +43,7 @@ typedef struct {
>  #define   EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_FULL_16550
> 0x
>  #define
> EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_16550_SUBSET_COMPATIBLE_WITH_
> MS_DBGP_SPEC  0x0001
>  #define   EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_ARM_PL011_UART
> 0x0003
> +#define   EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_NVIDIA_16550_UART
> 0x0005
>  #define
> EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_ARM_SBSA_GENERIC_UART_2X
> 0x000d
>  #define   EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_ARM_SBSA_GENERIC_UART
> 0x000e
>  #define   EFI_ACPI_DBG2_PORT_SUBTYPE_SERIAL_DCC
> 0x000f
> diff --git
> a/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> b/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> index 2066c7895e..ba19567f52 100644
> --- a/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.h
> +++ b/MdePkg/Include/IndustryStandard/SerialPortConsoleRedirectionTable.
> +++ h
> @@ -80,6 +80,11 @@ typedef struct {
>  ///
>  #define
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_AR
> M_PL011_UART0x03
>
> +///
> +/// NVIDIA 16550 UART
> +///
> +#define
> EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_NV
> IDIA_16550_UART 0x05
> +
>  ///
>  /// ARM SBSA Generic UART (2.x) supporting 32-bit only accesses [deprecated]
> ///
> --
> 2.17.1
>
>
>
> 
>

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH edk2-test 1/1] uefi-sct/SctPkg: correct print code for EFI_MEMORY_TYPE

[Samer El-Haj-Mahmoud]

Thanks!!

Reviewed-by: Samer El-Haj-Mahmoud 


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Heinrich
> Schuchardt via groups.io
> Sent: Friday, April 30, 2021 3:40 PM
> To: EDK II Development 
> Cc: Eric Jin ; G Edhaya Chandran
> ; Barton Gao ; Arvin
> Chen ; Samer El-Haj-Mahmoud  mahm...@arm.com>; Heinrich Schuchardt 
> Subject: [edk2-devel] [PATCH edk2-test 1/1] uefi-sct/SctPkg: correct print
> code for EFI_MEMORY_TYPE
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2284
>
> EFI_MEMORY_TYPE is an enum. SctPrint expects an UINTN when printing
> with %d. Add missing conversions in
> MemoryAllocationServicesBBTestFunction.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  .../MemoryAllocationServicesBBTestFunction.c  | 98 +--
>  1 file changed, 49 insertions(+), 49 deletions(-)
>
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/MemoryAllocationServices/Blac
> kBoxTest/MemoryAllocationServicesBBTestFunction.c b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/MemoryAllocationServices/Blac
> kBoxTest/MemoryAllocationServicesBBTestFunction.c
> index bf8cd3b3afa4..e545b3cfc5b8 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/MemoryAllocationServices/Blac
> kBoxTest/MemoryAllocationServicesBBTestFunction.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/BootServices/MemoryAllocationSer
> +++ vices/BlackBoxTest/MemoryAllocationServicesBBTestFunction.c
> @@ -417,7 +417,7 @@ BBTestAllocatePagesInterfaceTest (
>   (UINTN)__LINE__,
>   Status,
>   TplArray[Index],
> - AllocatePagesMemoryType[TypeIndex]
> + (UINTN)AllocatePagesMemoryType[TypeIndex]
>   );
>if (!(Memory & EFI_PAGE_MASK)) {
>  AssertionType = EFI_TEST_ASSERTION_PASSED; @@ -437,7 +437,7 @@
> BBTestAllocatePagesInterfaceTest (
>   __FILE__,
>   (UINTN)__LINE__,
>   TplArray[Index],
> - AllocatePagesMemoryType[TypeIndex]
> + (UINTN)AllocatePagesMemoryType[TypeIndex]
>   );
>if (Memory != 0) {
>  Status = gtBS->FreePages (
> @@ -455,7 +455,7 @@ BBTestAllocatePagesInterfaceTest (
>   (UINTN)__LINE__,
>   Status,
>   TplArray[Index],
> - AllocatePagesMemoryType[TypeIndex]
> + (UINTN)AllocatePagesMemoryType[TypeIndex]
>   );
>  }
>}
> @@ -478,7 +478,7 @@ BBTestAllocatePagesInterfaceTest (
> (UINTN)__LINE__,
> Status,
> TplArray[Index],
> -   AllocatePagesMemoryType[TypeIndex]
> +   (UINTN)AllocatePagesMemoryType[TypeIndex]
> );
>} else {
>  PageNum = (UINTN)Descriptor.NumberOfPages; @@ -512,7 +512,7 @@
> BBTestAllocatePagesInterfaceTest (
> (UINTN)__LINE__,
> Status,
> TplArray[Index],
> -   AllocatePagesMemoryType[TypeIndex]
> +   (UINTN)AllocatePagesMemoryType[TypeIndex]
> );
>  if (!(Memory & EFI_PAGE_MASK)) {
>AssertionType = EFI_TEST_ASSERTION_PASSED; @@ -532,7 +532,7 @@
> BBTestAllocatePagesInterfaceTest (
> __FILE__,
> (UINTN)__LINE__,
> TplArray[Index],
> -   AllocatePagesMemoryType[TypeIndex]
> +   (UINTN)AllocatePagesMemoryType[TypeIndex]
> );
>  if (Memory <= Descriptor.PhysicalStart +
>   SctLShiftU64 (Descriptor.NumberOfPages, EFI_PAGE_SHIFT) - @@ -
> 554,7 +554,7 @@ BBTestAllocatePagesInterfaceTest (
> __FILE__,
> (UINTN)__LINE__,
> TplArray[Index],
> -   AllocatePagesMemoryType[TypeIndex],
> +   (UINTN)AllocatePagesMemoryType[TypeIndex],
> Descriptor.PhysicalStart,
> Descriptor.NumberOfPages,
> Memory
> @@ -589,7 +589,7 @@ BBTestAllocatePagesInterfaceTest (
> (UINTN)__LINE__,
> Status,
> TplArray[Index],
> -   AllocatePagesMemoryType[TypeIndex]
> +   (UINTN)AllocatePagesMe

Re: [edk2-devel] [PATCH 1/2] Silicon/Broadcom/BcmGenetDxe: Delay for linkup in transmit

[Samer El-Haj-Mahmoud]

+Ard's new e-mail address

> -Original Message-
> From: Jeremy Linton 
> Sent: Thursday, April 15, 2021 3:22 PM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; l...@nuviainc.com;
> p...@akeo.ie; Samer El-Haj-Mahmoud  mahm...@arm.com>; Andrei Warkentin (awarken...@vmware.com)
> ; Jeremy Linton 
> Subject: [PATCH 1/2] Silicon/Broadcom/BcmGenetDxe: Delay for linkup in
> transmit
>
> Under normal circumstances GenetSimpleNetworkTransmit won't be called
> unless the rest of the network stack detects the link is up. So, during normal
> operation when the adapter is initialized the link naturally transitions to 
> link
> up, and then is ready for activity later in the boot sequence. If that hasn't
> happened by the time PXE runs then it will itself wait for the link.
>
> OTOH, the normal distro PXE sequence involves PXE loading shim which in
> turn loads grub, which tries to read machine specific configs, modules, and
> grub.cfg in order to prepare the boot menu.
> Then, once a grub selection is picked, it might try to load the
> kernel+initrd.
>
> In this sequence the network stack is shutdown and restarted multiple times.
> Grub though, starts up, notices its been network booted, reads saved
> network parameters and immediately tries to transmit data assuming the link
> is still up.
>
> When that happens grub will print "couldn't send network packet"
> and if that lasts long enough it fails to load grub.cfg and the user gets
> dropped to the grub prompt because no one in the path bothers to assure
> the link state has transitioned back up.
>
> For reference: https://github.com/pftf/RPi4/issues/113
>
> Signed-off-by: Jeremy Linton 
> ---
>  .../Drivers/Net/BcmGenetDxe/SimpleNetwork.c| 24
> --
>  1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c
> b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c
> index 1bda18f157..29c76d8495 100644
> --- a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c
> +++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c
> @@ -13,6 +13,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #include "BcmGenetDxe.h"
> @@ -590,9 +591,28 @@ GenetSimpleNetworkTransmit (
>
>if (!Genet->SnpMode.MediaPresent) {
>  //
> -// Don't bother transmitting if there's no link.
> +// We should only really get here if the link was up
> +// and is now down due to a stop/shutdown sequence, and
> +// the app (grub) doesn't bother to check link state
> +// because it was up a moment before.
> +// Lets wait a bit for the link to resume, rather than
> +// failing to send. In the case of grub it works either way
> +// but we can't be sure that is universally true, and
> +// hanging for a couple seconds is nicer than a screen of
> +// grub send failure messages.
>  //
> -return EFI_NOT_READY;
> +int retries = 1000;
> +DEBUG ((DEBUG_INFO, "%a: Waiting 10s for link\n", __FUNCTION__));
> +do {
> +  gBS->Stall (1);
> +  Status = GenericPhyUpdateConfig (&Genet->Phy);
> +} while (EFI_ERROR (Status) && retries--);
> +if (EFI_ERROR (Status)) {
> +  DEBUG ((DEBUG_ERROR, "%a: no link\n", __FUNCTION__));
> +  return EFI_NOT_READY;
> +} else {
> +  Genet->SnpMode.MediaPresent = TRUE;
> +}
>}
>
>if (HeaderSize != 0) {
> --
> 2.13.7

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH 2/2] Platform/RaspberryPi: Increase genet dma window

[Samer El-Haj-Mahmoud]

+Ard's new e-mail address

Jared, I assume your response can be taken as a "Reviewed-By", correct?

> -Original Message-
> From: Jared McNeill 
> Sent: Friday, April 30, 2021 9:08 PM
> To: Samer El-Haj-Mahmoud 
> Cc: Jeremy Linton ; devel@edk2.groups.io; Ard
> Biesheuvel ; l...@nuviainc.com; p...@akeo.ie;
> Andrei Warkentin (awarken...@vmware.com) 
> Subject: Re: [PATCH 2/2] Platform/RaspberryPi: Increase genet dma window
>
> LGTM!
>
> Take care,
> Jared
>
>
> > On Apr 30, 2021, at 3:15 PM, Samer El-Haj-Mahmoud  mahm...@arm.com> wrote:
> >
> > +Jared
> >
> > Reviewed-By: Samer El-Haj-Mahmoud  mahm...@arm.com>
> >
> >> -Original Message-
> >> From: Jeremy Linton 
> >> Sent: Thursday, April 15, 2021 3:22 PM
> >> To: devel@edk2.groups.io
> >> Cc: Ard Biesheuvel ; l...@nuviainc.com;
> >> p...@akeo.ie; Samer El-Haj-Mahmoud  mahm...@arm.com>;
> >> Andrei Warkentin (awarken...@vmware.com)
> ;
> >> Jeremy Linton 
> >> Subject: [PATCH 2/2] Platform/RaspberryPi: Increase genet dma window
> >>
> >> The genet is capable of addressing the entire memory space on the RPI4.
> >> Lets allow it to dma into those regions.
> >> This solves intermittent issues with grub/etc being able to
> >> communicate when the 3G limit is lifted on 8G boards.
> >>
> >> Signed-off-by: Jeremy Linton 
> >> ---
> >> Platform/RaspberryPi/RPi4/RPi4.dsc | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc
> >> b/Platform/RaspberryPi/RPi4/RPi4.dsc
> >> index ddf4dd6a41..facf34f034 100644
> >> --- a/Platform/RaspberryPi/RPi4/RPi4.dsc
> >> +++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
> >> @@ -698,7 +698,7 @@
> >>   Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.inf {
> >> 
> >>   gEmbeddedTokenSpaceGuid.PcdDmaDeviceOffset|0x
> >> -  gEmbeddedTokenSpaceGuid.PcdDmaDeviceLimit|0x
> >> +  gEmbeddedTokenSpaceGuid.PcdDmaDeviceLimit|0xff
> >>   }
> >>
> >>   #
> >> --
> >> 2.13.7
> >
> > IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended 
> recipient,
> please notify the sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the information in any
> medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH 1/2] Silicon/Broadcom/BcmGenetDxe: Delay for linkup in transmit

[Samer El-Haj-Mahmoud]

+Ard's new e-mail address

Jared, please confirm this is a "Reviewed-By"

> -Original Message-
> From: Jared McNeill 
> Sent: Friday, April 30, 2021 6:30 AM
> To: Jeremy Linton 
> Cc: devel@edk2.groups.io; Ard Biesheuvel ;
> l...@nuviainc.com; Pete Batard ; Samer El-Haj-Mahmoud
> ; Andrei Warkentin
> (awarken...@vmware.com) 
> Subject: Re: [PATCH 1/2] Silicon/Broadcom/BcmGenetDxe: Delay for linkup in
> transmit
>
> LGTM.
>
> Take care,
> Jared
>
>
> > On Apr 29, 2021, at 5:19 PM, Jeremy Linton 
> wrote:
> >
> > +Jared McNeill for review.
> >
> > Thanks,
> >
> > On 4/15/21 2:22 PM, Jeremy Linton wrote:
> >> Under normal circumstances GenetSimpleNetworkTransmit won't be
> called
> >> unless the rest of the network stack detects the link is up. So,
> >> during normal operation when the adapter is initialized the link
> >> naturally transitions to link up, and then is ready for activity
> >> later in the boot sequence. If that hasn't happened by the time PXE
> >> runs then it will itself wait for the link.
> >> OTOH, the normal distro PXE sequence involves PXE loading shim which
> >> in turn loads grub, which tries to read machine specific configs,
> >> modules, and grub.cfg in order to prepare the boot menu.
> >> Then, once a grub selection is picked, it might try to load the
> >> kernel+initrd.
> >> In this sequence the network stack is shutdown and restarted multiple
> >> times. Grub though, starts up, notices its been network booted, reads
> >> saved network parameters and immediately tries to transmit data
> >> assuming the link is still up.
> >> When that happens grub will print "couldn't send network packet"
> >> and if that lasts long enough it fails to load grub.cfg and the user
> >> gets dropped to the grub prompt because no one in the path bothers to
> >> assure the link state has transitioned back up.
> >> For reference: https://github.com/pftf/RPi4/issues/113
> >> Signed-off-by: Jeremy Linton 
> >> ---
> >>  .../Drivers/Net/BcmGenetDxe/SimpleNetwork.c| 24
> --
> >>  1 file changed, 22 insertions(+), 2 deletions(-) diff --git
> >> a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c
> >> b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c
> >> index 1bda18f157..29c76d8495 100644
> >> --- a/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c
> >> +++ b/Silicon/Broadcom/Drivers/Net/BcmGenetDxe/SimpleNetwork.c
> >> @@ -13,6 +13,7 @@
> >>  #include 
> >>  #include 
> >>  #include 
> >> +#include 
> >>  #include 
> >>#include "BcmGenetDxe.h"
> >> @@ -590,9 +591,28 @@ GenetSimpleNetworkTransmit (
> >>  if (!Genet->SnpMode.MediaPresent) {
> >>  //
> >> -// Don't bother transmitting if there's no link.
> >> +// We should only really get here if the link was up
> >> +// and is now down due to a stop/shutdown sequence, and
> >> +// the app (grub) doesn't bother to check link state
> >> +// because it was up a moment before.
> >> +// Lets wait a bit for the link to resume, rather than
> >> +// failing to send. In the case of grub it works either way
> >> +// but we can't be sure that is universally true, and
> >> +// hanging for a couple seconds is nicer than a screen of
> >> +// grub send failure messages.
> >>  //
> >> -return EFI_NOT_READY;
> >> +int retries = 1000;
> >> +DEBUG ((DEBUG_INFO, "%a: Waiting 10s for link\n", __FUNCTION__));
> >> +do {
> >> +  gBS->Stall (1);
> >> +  Status = GenericPhyUpdateConfig (&Genet->Phy);
> >> +} while (EFI_ERROR (Status) && retries--);
> >> +if (EFI_ERROR (Status)) {
> >> +  DEBUG ((DEBUG_ERROR, "%a: no link\n", __FUNCTION__));
> >> +  return EFI_NOT_READY;
> >> +} else {
> >> +  Genet->SnpMode.MediaPresent = TRUE;
> >> +}
> >>}
> >>  if (HeaderSize != 0) {
> >

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH BUG 0/2] rpi: Fix PXE issues with grub

[Samer El-Haj-Mahmoud]

+Ard's new e-mail address

> -Original Message-
> From: Jeremy Linton 
> Sent: Thursday, April 15, 2021 3:22 PM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; l...@nuviainc.com;
> p...@akeo.ie; Samer El-Haj-Mahmoud  mahm...@arm.com>; Andrei Warkentin (awarken...@vmware.com)
> ; Jeremy Linton 
> Subject: [PATCH BUG 0/2] rpi: Fix PXE issues with grub
>
> When PXE booting with grub the network link isn't given a chance to resume
> so grub's transmit calls fail. This results in failed boots. Similarly the DMA
> range for the adapter isn't right since it doesn't have a 32-bit restriction.
> Again this keeps grub from failing on 8G devices,
>
> Jeremy Linton (2):
>   Silicon/Broadcom/BcmGenetDxe: Delay for linkup in transmit
>   Platform/RaspberryPi: Increase genet dma window
>
>  Platform/RaspberryPi/RPi4/RPi4.dsc |  2 +-
>  .../Drivers/Net/BcmGenetDxe/SimpleNetwork.c| 24
> --
>  2 files changed, 23 insertions(+), 3 deletions(-)
>
> --
> 2.13.7

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH 2/2] Platform/RaspberryPi: Increase genet dma window

[Samer El-Haj-Mahmoud]

+Ard's new e-mail address

> -Original Message-
> From: Jeremy Linton 
> Sent: Thursday, April 15, 2021 3:22 PM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; l...@nuviainc.com;
> p...@akeo.ie; Samer El-Haj-Mahmoud  mahm...@arm.com>; Andrei Warkentin (awarken...@vmware.com)
> ; Jeremy Linton 
> Subject: [PATCH 2/2] Platform/RaspberryPi: Increase genet dma window
>
> The genet is capable of addressing the entire memory space on the RPI4.
> Lets allow it to dma into those regions.
> This solves intermittent issues with grub/etc being able to communicate
> when the 3G limit is lifted on 8G boards.
>
> Signed-off-by: Jeremy Linton 
> ---
>  Platform/RaspberryPi/RPi4/RPi4.dsc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc
> b/Platform/RaspberryPi/RPi4/RPi4.dsc
> index ddf4dd6a41..facf34f034 100644
> --- a/Platform/RaspberryPi/RPi4/RPi4.dsc
> +++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
> @@ -698,7 +698,7 @@
>Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.inf {
>  
>gEmbeddedTokenSpaceGuid.PcdDmaDeviceOffset|0x
> -  gEmbeddedTokenSpaceGuid.PcdDmaDeviceLimit|0x
> +  gEmbeddedTokenSpaceGuid.PcdDmaDeviceLimit|0xff
>}
>
>#
> --
> 2.13.7

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

[Samer El-Haj-Mahmoud]

+ Ard's new e-mail address


From: Samer El-Haj-Mahmoud 
Sent: Friday, April 30, 2021 2:05 PM
To: devel@edk2.groups.io; Samer El-Haj-Mahmoud ; 
Andrei Warkentin (awarken...@vmware.com) ; Jeremy Linton 

Cc: Ard Biesheuvel ; l...@nuviainc.com; p...@akeo.ie; 
Samer El-Haj-Mahmoud 
Subject: RE: [edk2-devel] [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct 
_DMA consumer

Update: UEFI Forum ASWG (ACPI spec working group) approved the submitted ECR as 
an errata for future ACPI 6.4 spec publication.

We can go ahead and proceed with this patch as submitted, based on that ECR 
clarification.

With that,

Reviewed-By: Samer El-Haj-Mahmoud 
samer.el-haj-mahm...@arm.com<mailto:samer.el-haj-mahm...@arm.com>

Thanks,
--Samer


From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
mailto:devel@edk2.groups.io>> On Behalf Of Samer 
El-Haj-Mahmoud via groups.io
Sent: Thursday, April 29, 2021 10:03 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io>; Samer El-Haj-Mahmoud 
mailto:samer.el-haj-mahm...@arm.com>>; Andrei 
Warkentin (awarken...@vmware.com<mailto:awarken...@vmware.com>) 
mailto:awarken...@vmware.com>>; Jeremy Linton 
mailto:jeremy.lin...@arm.com>>; 
r...@edk2.groups.io<mailto:r...@edk2.groups.io>
Cc: Ard Biesheuvel mailto:ard.biesheu...@arm.com>>; 
l...@nuviainc.com<mailto:l...@nuviainc.com>; p...@akeo.ie<mailto:p...@akeo.ie>; 
Samer El-Haj-Mahmoud 
mailto:samer.el-haj-mahm...@arm.com>>
Subject: Re: [edk2-devel] [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct 
_DMA consumer

Any further comments on the ACPI ECR documented in: 
https://bugzilla.tianocore.org/show_bug.cgi?id=3335 ?

I already have comments from Jeremey and Andrew saying it looks good. If there 
are no objections, I will let ASWG know to approve the ECR for future ACPI spec 
publication.

Thanks,
--Samer




From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
mailto:devel@edk2.groups.io>> On Behalf Of Samer 
El-Haj-Mahmoud via groups.io
Sent: Tuesday, April 13, 2021 12:45 PM
To: Andrei Warkentin (awarken...@vmware.com<mailto:awarken...@vmware.com>) 
mailto:awarken...@vmware.com>>; Jeremy Linton 
mailto:jeremy.lin...@arm.com>>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Ard Biesheuvel mailto:ard.biesheu...@arm.com>>; 
l...@nuviainc.com<mailto:l...@nuviainc.com>; p...@akeo.ie<mailto:p...@akeo.ie>; 
Samer El-Haj-Mahmoud 
mailto:samer.el-haj-mahm...@arm.com>>
Subject: Re: [edk2-devel] [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct 
_DMA consumer

I just got to this thread. Apologies for the delay.

I went through the ACPI spec. Here is what I see:

https://uefi.org/specs/ACPI/6.4/19_ASL_Reference/ACPI_Source_Language_Reference.html#qwordmemory-qword-memory-resource-descriptor-macro


"ResourceUsage specifies whether the Memory range is consumed by this device 
(ResourceConsumer) or passed on to child devices (ResourceProducer). If nothing 
is specified, then ResourceConsumer is assumed."



https://uefi.org/specs/ACPI/6.4/06_Device_Configuration/Device_Configuration.html#dma-direct-memory-access



" It specifies the ranges the bus controller (bridge) decodes on the child-side 
of its interface. (This is analogous to the _CRS object, which describes the 
resources that the bus controller decodes on the parent-side of its interface.) 
Any ranges described in the resources of a _DMA object can be used by child 
devices for DMA or bus master transactions.."



The way I read the spec, this wording in the _DMA definition "Any ranges 
described in the resources of a _DMA object can be used by child devices.." 
suggests that this should be a ResourceProducer, per the QWordMemory resource 
descriptor definition above


The _DMA example in section 6.2.4 uses a "ResourceConsumer", when it should 
really be "ResourceProducer" according to these definitions: It describes , the 
child devices view of the address range, so the "translation" added is the 
CPU's view of the same range.



I submitted a "code first" ECR to correct the ACPI spec example (here : 
https://bugzilla.tianocore.org/show_bug.cgi?id=3335). Please provide feedback 
on the BZ (or this thread) whether you agree or not, so we can take this to 
ASWG/UEFI Forum for discussion and approval



Thanks,

--Samer





From: Andrei Warkentin mailto:awarken...@vmware.com>>
Sent: Thursday, April 8, 2021 10:24 AM
To: Jeremy Linton mailto:jeremy.lin...@arm.com>>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Ard Biesheuvel mailto:ard.biesheu...@arm.com>>; 
l...@nuviainc.com<mailto:l...@nuviainc.com>; p...@akeo.ie<mailto:p...@akeo.ie>; 
Samer El-Haj-Mahmoud 
mailto:samer.el-haj-mahm...@arm.com>>
Subject: Re: [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

I don't know... the AC

Re: [edk2-devel] [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

[Samer El-Haj-Mahmoud]

+Ard's new e-mail address

> -Original Message-
> From: Jeremy Linton 
> Sent: Thursday, April 8, 2021 1:59 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; l...@nuviainc.com;
> p...@akeo.ie; Samer El-Haj-Mahmoud  mahm...@arm.com>; Andrei Warkentin (awarken...@vmware.com)
> ; Jeremy Linton 
> Subject: [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA
> consumer
>
> Bridge devices should be marked as producers so that their children can
> consume the resources. In linux if this isn't true then the translation gets
> ignored and the DMA values are incorrect. This fixes DMA on all the devices
> that need a translation.
>
> Signed-off-by: Jeremy Linton 
> ---
>  Platform/RaspberryPi/AcpiTables/Dsdt.asl | 2 +-
> Platform/RaspberryPi/AcpiTables/Emmc.asl | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
> b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
> index d116f965e1..32cd5fc9f9 100644
> --- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
> +++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
> @@ -205,7 +205,7 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 5, "RPIFDN",
> "RPI", 2)
>  // Only the first GB is available. // Bus 0xC000 -> CPU
> 0x. //-QWordMemory (ResourceConsumer,+
> QWordMemory (ResourceProducer,   ,   MinFixed,
> MaxFixed,diff --git a/Platform/RaspberryPi/AcpiTables/Emmc.asl
> b/Platform/RaspberryPi/AcpiTables/Emmc.asl
> index 179dd3ecdb..0fbc2a79ea 100644
> --- a/Platform/RaspberryPi/AcpiTables/Emmc.asl
> +++ b/Platform/RaspberryPi/AcpiTables/Emmc.asl
> @@ -32,7 +32,7 @@ DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN",
> "RPI4EMMC", 2)
>}Name (_DMA, ResourceTemplate() {-QWordMemory
> (ResourceConsumer,+QWordMemory (ResourceProducer,   ,
> MinFixed,   MaxFixed,--
> 2.13.7

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

[Samer El-Haj-Mahmoud]

+Ard's new e-mail address

> -Original Message-
> From: Pete Batard 
> Sent: Thursday, April 8, 2021 5:48 AM
> To: Jeremy Linton ; devel@edk2.groups.io
> Cc: Ard Biesheuvel ; l...@nuviainc.com; Samer
> El-Haj-Mahmoud ; Andrei Warkentin
> (awarken...@vmware.com) 
> Subject: Re: [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA
> consumer
>
> On 2021.04.08 06:58, Jeremy Linton wrote:
> > Bridge devices should be marked as producers so that their children
> > can consume the resources. In linux if this isn't true then the
> > translation gets ignored and the DMA values are incorrect. This fixes
> > DMA on all the devices that need a translation.
> >
> > Signed-off-by: Jeremy Linton 
> > ---
> >   Platform/RaspberryPi/AcpiTables/Dsdt.asl | 2 +-
> >   Platform/RaspberryPi/AcpiTables/Emmc.asl | 2 +-
> >   2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
> > b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
> > index d116f965e1..32cd5fc9f9 100644
> > --- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
> > +++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
> > @@ -205,7 +205,7 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 5, "RPIFDN",
> "RPI", 2)
> >   // Only the first GB is available.
> >
> >   // Bus 0xC000 -> CPU 0x.
> >
> >   //
> >
> > -QWordMemory (ResourceConsumer,
> >
> > +QWordMemory (ResourceProducer,
> >
> > ,
> >
> > MinFixed,
> >
> > MaxFixed,
> >
> > diff --git a/Platform/RaspberryPi/AcpiTables/Emmc.asl
> > b/Platform/RaspberryPi/AcpiTables/Emmc.asl
> > index 179dd3ecdb..0fbc2a79ea 100644
> > --- a/Platform/RaspberryPi/AcpiTables/Emmc.asl
> > +++ b/Platform/RaspberryPi/AcpiTables/Emmc.asl
> > @@ -32,7 +32,7 @@ DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN",
> "RPI4EMMC", 2)
> > }
> >
> >
> >
> > Name (_DMA, ResourceTemplate() {
> >
> > -QWordMemory (ResourceConsumer,
> >
> > +QWordMemory (ResourceProducer,
> >
> > ,
> >
> > MinFixed,
> >
> > MaxFixed,
> >
>
> Reviewed-by: Pete Batard 
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH 2/3] Platform/RaspberryPi/AcpiTables: Add further named components

[Samer El-Haj-Mahmoud]

+ Ard's new e-mail address


From: Andrei Warkentin 
Sent: Thursday, April 8, 2021 10:17 AM
To: Jeremy Linton ; devel@edk2.groups.io
Cc: Ard Biesheuvel ; l...@nuviainc.com; p...@akeo.ie; 
Samer El-Haj-Mahmoud 
Subject: Re: [PATCH 2/3] Platform/RaspberryPi/AcpiTables: Add further named 
components

Reviewed-by: Andrei Warkentin 
mailto:awarken...@vmware.com>>

From: Jeremy Linton mailto:jeremy.lin...@arm.com>>
Sent: Thursday, April 8, 2021 12:58 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
mailto:devel@edk2.groups.io>>
Cc: ard.biesheu...@arm.com<mailto:ard.biesheu...@arm.com> 
mailto:ard.biesheu...@arm.com>>; 
l...@nuviainc.com<mailto:l...@nuviainc.com> 
mailto:l...@nuviainc.com>>; 
p...@akeo.ie<mailto:p...@akeo.ie> mailto:p...@akeo.ie>>; 
samer.el-haj-mahm...@arm.com<mailto:samer.el-haj-mahm...@arm.com> 
mailto:samer.el-haj-mahm...@arm.com>>; Andrei 
Warkentin mailto:awarken...@vmware.com>>; Jeremy Linton 
mailto:jeremy.lin...@arm.com>>
Subject: [PATCH 2/3] Platform/RaspberryPi/AcpiTables: Add further named 
components

Add some additional IORT nodes for the USB & EMMC devices, realistically
we probably only need to have a single node with the lowest AddressSizeLimit
but this is conceptually "cleaner" should anyone actually try and use these
values rather than the _DMA provided ones.

Signed-off-by: Jeremy Linton 
mailto:jeremy.lin...@arm.com>>
---
 Platform/RaspberryPi/AcpiTables/Iort.aslc | 44 ++-
 1 file changed, 43 insertions(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Iort.aslc 
b/Platform/RaspberryPi/AcpiTables/Iort.aslc
index 00720194bb..810307ae37 100644
--- a/Platform/RaspberryPi/AcpiTables/Iort.aslc
+++ b/Platform/RaspberryPi/AcpiTables/Iort.aslc
@@ -20,6 +20,8 @@ typedef struct {
 typedef struct {

   EFI_ACPI_6_0_IO_REMAPPING_TABLE  Iort;

   RPI4_NC_NODE NamedCompNode;

+  RPI4_NC_NODE NamedCompNode2;

+  RPI4_NC_NODE NamedCompNode3;

 } RPI4_IO_REMAPPING_STRUCTURE;



 STATIC RPI4_IO_REMAPPING_STRUCTURE Iort = {

@@ -27,7 +29,7 @@ STATIC RPI4_IO_REMAPPING_STRUCTURE Iort = {
 ACPI_HEADER (EFI_ACPI_6_0_IO_REMAPPING_TABLE_SIGNATURE,

  RPI4_IO_REMAPPING_STRUCTURE,

  EFI_ACPI_IO_REMAPPING_TABLE_REVISION),

-1,  // NumNodes

+3,  // NumNodes

 sizeof (EFI_ACPI_6_0_IO_REMAPPING_TABLE),   // NodeOffset

 0   // Reserved

   }, {

@@ -50,6 +52,46 @@ STATIC RPI4_IO_REMAPPING_STRUCTURE Iort = {
 }, {

   "\\_SB_.SCB0.XHC0"// 
ObjectName

 }

+  }, {

+// gpu/dwc usb named component node

+{

+  {

+EFI_ACPI_IORT_TYPE_NAMED_COMP,  // Type

+sizeof (RPI4_NC_NODE),  // Length

+0x0,// Revision

+0x0,// Reserved

+0x0,// NumIdMappings

+0x0,// IdReference

+  },

+  0x0,  // Flags

+  0x0,  // CacheCoherent

+  0x0,  // AllocationHints

+  0x0,  // Reserved

+  0x0,  // MemoryAccessFlags

+  30,   // AddressSizeLimit

+}, {

+  "\\_SB_.GDV0.USB0"// 
ObjectName

+}

+  }, {

+// emmc2 named component node

+{

+  {

+EFI_ACPI_IORT_TYPE_NAMED_COMP,  // Type

+sizeof (RPI4_NC_NODE),  // Length

+0x0,// Revision

+0x0,// Reserved

+0x0,// NumIdMappings

+0x0,// IdReference

+  },

+  0x0,  // Flags

+  0x0,  // CacheCoherent

+  0x0,  // AllocationHints

+  0x0,  // Reserved

+  0x0,  // MemoryAccessFlags

+  30,   // AddressSizeLimit

+}, {

+  "\\_SB_.GDV1.SDC3"// 
ObjectName

+}

   }

 };



--
2.13.7
IMPORTANT NOTICE: The contents of this email and any attachments are 
co

Re: [edk2-devel] [PATCH 2/3] Platform/RaspberryPi/AcpiTables: Add further named components

[Samer El-Haj-Mahmoud]

+ Ard’s new e-mail address

> -Original Message-
> From: Pete Batard 
> Sent: Thursday, April 8, 2021 5:48 AM
> To: Jeremy Linton ; devel@edk2.groups.io
> Cc: Ard Biesheuvel ; l...@nuviainc.com; Samer
> El-Haj-Mahmoud ; Andrei Warkentin
> (awarken...@vmware.com) 
> Subject: Re: [PATCH 2/3] Platform/RaspberryPi/AcpiTables: Add further
> named components
>
> On 2021.04.08 06:58, Jeremy Linton wrote:
> > Add some additional IORT nodes for the USB & EMMC devices,
> > realistically we probably only need to have a single node with the
> > lowest AddressSizeLimit but this is conceptually "cleaner" should
> > anyone actually try and use these values rather than the _DMA provided
> ones.
> >
> > Signed-off-by: Jeremy Linton 
> > ---
> >   Platform/RaspberryPi/AcpiTables/Iort.aslc | 44
> ++-
> >   1 file changed, 43 insertions(+), 1 deletion(-)
> >
> > diff --git a/Platform/RaspberryPi/AcpiTables/Iort.aslc
> > b/Platform/RaspberryPi/AcpiTables/Iort.aslc
> > index 00720194bb..810307ae37 100644
> > --- a/Platform/RaspberryPi/AcpiTables/Iort.aslc
> > +++ b/Platform/RaspberryPi/AcpiTables/Iort.aslc
> > @@ -20,6 +20,8 @@ typedef struct {
> >   typedef struct {
> >
> > EFI_ACPI_6_0_IO_REMAPPING_TABLE  Iort;
> >
> > RPI4_NC_NODE NamedCompNode;
> >
> > +  RPI4_NC_NODE NamedCompNode2;
> >
> > +  RPI4_NC_NODE NamedCompNode3;
> >
> >   } RPI4_IO_REMAPPING_STRUCTURE;
> >
> >
> >
> >   STATIC RPI4_IO_REMAPPING_STRUCTURE Iort = {
> >
> > @@ -27,7 +29,7 @@ STATIC RPI4_IO_REMAPPING_STRUCTURE Iort = {
> >   ACPI_HEADER (EFI_ACPI_6_0_IO_REMAPPING_TABLE_SIGNATURE,
> >
> >RPI4_IO_REMAPPING_STRUCTURE,
> >
> >EFI_ACPI_IO_REMAPPING_TABLE_REVISION),
> >
> > -1,  // NumNodes
> >
> > +3,  // NumNodes
> >
> >   sizeof (EFI_ACPI_6_0_IO_REMAPPING_TABLE),   // NodeOffset
> >
> >   0   // Reserved
> >
> > }, {
> >
> > @@ -50,6 +52,46 @@ STATIC RPI4_IO_REMAPPING_STRUCTURE Iort = {
> >   }, {
> >
> > "\\_SB_.SCB0.XHC0"// ObjectName
> >
> >   }
> >
> > +  }, {
> >
> > +// gpu/dwc usb named component node
> >
> > +{
> >
> > +  {
> >
> > +EFI_ACPI_IORT_TYPE_NAMED_COMP,  // Type
> >
> > +sizeof (RPI4_NC_NODE),  // Length
> >
> > +0x0,// Revision
> >
> > +0x0,// Reserved
> >
> > +0x0,// NumIdMappings
> >
> > +0x0,// IdReference
> >
> > +  },
> >
> > +  0x0,  // Flags
> >
> > +  0x0,  // CacheCoherent
> >
> > +  0x0,  // AllocationHints
> >
> > +  0x0,  // Reserved
> >
> > +  0x0,  // MemoryAccessFlags
> >
> > +  30,   // AddressSizeLimit
> >
> > +}, {
> >
> > +  "\\_SB_.GDV0.USB0"// ObjectName
> >
> > +}
> >
> > +  }, {
> >
> > +// emmc2 named component node
> >
> > +{
> >
> > +  {
> >
> > +EFI_ACPI_IORT_TYPE_NAMED_COMP,  // Type
> >
> > +sizeof (RPI4_NC_NODE),  // Length
> >
> > +0x0,// Revision
> >
> > +0x0,// Reserved
> >
> > +0x0,// NumIdMappings
> >
> > +0x0,// IdReference
> >
> > +  },
> >
> > +  0x0,  // Flags
> >
> > +  0x0,  // CacheCoherent
> >
> > +  0x0,  //

Re: [edk2-devel] [PATCH 2/3] Platform/RaspberryPi/AcpiTables: Add further named components

[Samer El-Haj-Mahmoud]

+ Ard's new e-mail address

> -Original Message-
> From: Jeremy Linton 
> Sent: Thursday, April 8, 2021 1:59 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; l...@nuviainc.com;
> p...@akeo.ie; Samer El-Haj-Mahmoud  mahm...@arm.com>; Andrei Warkentin (awarken...@vmware.com)
> ; Jeremy Linton 
> Subject: [PATCH 2/3] Platform/RaspberryPi/AcpiTables: Add further named
> components
>
> Add some additional IORT nodes for the USB & EMMC devices, realistically
> we probably only need to have a single node with the lowest
> AddressSizeLimit
> but this is conceptually "cleaner" should anyone actually try and use these
> values rather than the _DMA provided ones.
>
> Signed-off-by: Jeremy Linton 
> ---
>  Platform/RaspberryPi/AcpiTables/Iort.aslc | 44
> ++-
>  1 file changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/Platform/RaspberryPi/AcpiTables/Iort.aslc
> b/Platform/RaspberryPi/AcpiTables/Iort.aslc
> index 00720194bb..810307ae37 100644
> --- a/Platform/RaspberryPi/AcpiTables/Iort.aslc
> +++ b/Platform/RaspberryPi/AcpiTables/Iort.aslc
> @@ -20,6 +20,8 @@ typedef struct {
>  typedef struct {
>
>EFI_ACPI_6_0_IO_REMAPPING_TABLE  Iort;
>
>RPI4_NC_NODE NamedCompNode;
>
> +  RPI4_NC_NODE NamedCompNode2;
>
> +  RPI4_NC_NODE NamedCompNode3;
>
>  } RPI4_IO_REMAPPING_STRUCTURE;
>
>
>
>  STATIC RPI4_IO_REMAPPING_STRUCTURE Iort = {
>
> @@ -27,7 +29,7 @@ STATIC RPI4_IO_REMAPPING_STRUCTURE Iort = {
>  ACPI_HEADER (EFI_ACPI_6_0_IO_REMAPPING_TABLE_SIGNATURE,
>
>   RPI4_IO_REMAPPING_STRUCTURE,
>
>   EFI_ACPI_IO_REMAPPING_TABLE_REVISION),
>
> -1,  // NumNodes
>
> +3,  // NumNodes
>
>  sizeof (EFI_ACPI_6_0_IO_REMAPPING_TABLE),   // NodeOffset
>
>  0   // Reserved
>
>}, {
>
> @@ -50,6 +52,46 @@ STATIC RPI4_IO_REMAPPING_STRUCTURE Iort = {
>  }, {
>
>"\\_SB_.SCB0.XHC0"// ObjectName
>
>  }
>
> +  }, {
>
> +// gpu/dwc usb named component node
>
> +{
>
> +  {
>
> +EFI_ACPI_IORT_TYPE_NAMED_COMP,  // Type
>
> +sizeof (RPI4_NC_NODE),  // Length
>
> +0x0,// Revision
>
> +0x0,// Reserved
>
> +0x0,// NumIdMappings
>
> +0x0,// IdReference
>
> +  },
>
> +  0x0,  // Flags
>
> +  0x0,  // CacheCoherent
>
> +  0x0,  // AllocationHints
>
> +  0x0,  // Reserved
>
> +  0x0,  // MemoryAccessFlags
>
> +  30,   // AddressSizeLimit
>
> +}, {
>
> +  "\\_SB_.GDV0.USB0"// ObjectName
>
> +}
>
> +  }, {
>
> +// emmc2 named component node
>
> +{
>
> +  {
>
> +EFI_ACPI_IORT_TYPE_NAMED_COMP,  // Type
>
> +sizeof (RPI4_NC_NODE),  // Length
>
> +0x0,// Revision
>
> +0x0,// Reserved
>
> +0x0,// NumIdMappings
>
> +0x0,// IdReference
>
> +  },
>
> +  0x0,  // Flags
>
> +  0x0,  // CacheCoherent
>
> +  0x0,  // AllocationHints
>
> +  0x0,  // Reserved
>
> +  0x0,  // MemoryAccessFlags
>
> +  30,   // AddressSizeLimit
>
> +}, {
>
> +  "\\_SB_.GDV1.SDC3"// ObjectName
>
> +}
>
>}
>
>  };
>
>
>
> --
> 2.13.7

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH 1/3] Platform/RaspberryPi/Acpitables: Enable Arasan hispeed mode

[Samer El-Haj-Mahmoud]

+ Ard's new e-mail address


From: Andrei Warkentin 
Sent: Thursday, April 8, 2021 10:18 AM
To: Pete Batard ; Jeremy Linton ; 
devel@edk2.groups.io
Cc: Ard Biesheuvel ; l...@nuviainc.com; Samer 
El-Haj-Mahmoud 
Subject: Re: [PATCH 1/3] Platform/RaspberryPi/Acpitables: Enable Arasan hispeed 
mode

Reviewed-by: Andrei Warkentin 
mailto:awarken...@vmware.com>>

From: Pete Batard mailto:p...@akeo.ie>>
Sent: Thursday, April 8, 2021 4:48 AM
To: Jeremy Linton mailto:jeremy.lin...@arm.com>>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
mailto:devel@edk2.groups.io>>
Cc: ard.biesheu...@arm.com<mailto:ard.biesheu...@arm.com> 
mailto:ard.biesheu...@arm.com>>; 
l...@nuviainc.com<mailto:l...@nuviainc.com> 
mailto:l...@nuviainc.com>>; 
samer.el-haj-mahm...@arm.com<mailto:samer.el-haj-mahm...@arm.com> 
mailto:samer.el-haj-mahm...@arm.com>>; Andrei 
Warkentin mailto:awarken...@vmware.com>>
Subject: Re: [PATCH 1/3] Platform/RaspberryPi/Acpitables: Enable Arasan hispeed 
mode

On 2021.04.08 06:58, Jeremy Linton wrote:
> The arasan caps registers are no longer being overridden by
> the brcm iproc driver, so we should be assuring that the
> "High Speed Support" bit 21 is set in the capability
> register. This significantly improves the wifi perf
> using linux.
>
> Signed-off-by: Jeremy Linton 
> mailto:jeremy.lin...@arm.com>>
> ---
>   Platform/RaspberryPi/AcpiTables/Sdhc.asl | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Platform/RaspberryPi/AcpiTables/Sdhc.asl 
> b/Platform/RaspberryPi/AcpiTables/Sdhc.asl
> index 0430ab7d2d..42776e33bb 100644
> --- a/Platform/RaspberryPi/AcpiTables/Sdhc.asl
> +++ b/Platform/RaspberryPi/AcpiTables/Sdhc.asl
> @@ -52,7 +52,7 @@ Device (SDC1)
> Name (_DSD, Package () {
>
>   ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
>
>   Package () {
>
> -  Package () { "sdhci-caps", 0x0100fa81 },
>
> +  Package () { "sdhci-caps", 0x0120fa81 },
>
>   }
>
> })
>
>
>

Reviewed-by: Pete Batard mailto:p...@akeo.ie>>
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH 1/3] Platform/RaspberryPi/Acpitables: Enable Arasan hispeed mode

[Samer El-Haj-Mahmoud]

+ Ard’s new e-mail address

> -Original Message-
> From: Pete Batard 
> Sent: Thursday, April 8, 2021 5:48 AM
> To: Jeremy Linton ; devel@edk2.groups.io
> Cc: Ard Biesheuvel ; l...@nuviainc.com; Samer
> El-Haj-Mahmoud ; Andrei Warkentin
> (awarken...@vmware.com) 
> Subject: Re: [PATCH 1/3] Platform/RaspberryPi/Acpitables: Enable Arasan
> hispeed mode
>
> On 2021.04.08 06:58, Jeremy Linton wrote:
> > The arasan caps registers are no longer being overridden by the brcm
> > iproc driver, so we should be assuring that the "High Speed Support"
> > bit 21 is set in the capability register. This significantly improves
> > the wifi perf using linux.
> >
> > Signed-off-by: Jeremy Linton 
> > ---
> >   Platform/RaspberryPi/AcpiTables/Sdhc.asl | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Platform/RaspberryPi/AcpiTables/Sdhc.asl
> > b/Platform/RaspberryPi/AcpiTables/Sdhc.asl
> > index 0430ab7d2d..42776e33bb 100644
> > --- a/Platform/RaspberryPi/AcpiTables/Sdhc.asl
> > +++ b/Platform/RaspberryPi/AcpiTables/Sdhc.asl
> > @@ -52,7 +52,7 @@ Device (SDC1)
> > Name (_DSD, Package () {
> >
> >   ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> >
> >   Package () {
> >
> > -  Package () { "sdhci-caps", 0x0100fa81 },
> >
> > +  Package () { "sdhci-caps", 0x0120fa81 },
> >
> >   }
> >
> > })
> >
> >
> >
>
> Reviewed-by: Pete Batard 
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH 1/3] Platform/RaspberryPi/Acpitables: Enable Arasan hispeed mode

[Samer El-Haj-Mahmoud]

+ Ard's new e-mail address

> -Original Message-
> From: Jeremy Linton 
> Sent: Thursday, April 8, 2021 1:59 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; l...@nuviainc.com;
> p...@akeo.ie; Samer El-Haj-Mahmoud  mahm...@arm.com>; Andrei Warkentin (awarken...@vmware.com)
> ; Jeremy Linton 
> Subject: [PATCH 1/3] Platform/RaspberryPi/Acpitables: Enable Arasan
> hispeed mode
>
> The arasan caps registers are no longer being overridden by the brcm iproc
> driver, so we should be assuring that the "High Speed Support" bit 21 is set 
> in
> the capability register. This significantly improves the wifi perf using 
> linux.
>
> Signed-off-by: Jeremy Linton 
> ---
>  Platform/RaspberryPi/AcpiTables/Sdhc.asl | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Platform/RaspberryPi/AcpiTables/Sdhc.asl
> b/Platform/RaspberryPi/AcpiTables/Sdhc.asl
> index 0430ab7d2d..42776e33bb 100644
> --- a/Platform/RaspberryPi/AcpiTables/Sdhc.asl
> +++ b/Platform/RaspberryPi/AcpiTables/Sdhc.asl
> @@ -52,7 +52,7 @@ Device (SDC1)
>Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-
> bc9bbf4aa301"), Package () {-  Package () { "sdhci-caps", 0x0100fa81 
> },+
> Package () { "sdhci-caps", 0x0120fa81 }, }   }) --
> 2.13.7

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH 0/3] SD+USB perf/DMA fixes

[Samer El-Haj-Mahmoud]

Adding Ard's new e-mail address

From: devel@edk2.groups.io  On Behalf Of Samer 
El-Haj-Mahmoud via groups.io
Sent: Friday, April 30, 2021 2:28 PM
To: Andrei Warkentin (awarken...@vmware.com) ; Jeremy 
Linton ; devel@edk2.groups.io
Cc: Ard Biesheuvel ; l...@nuviainc.com; p...@akeo.ie; 
Samer El-Haj-Mahmoud 
Subject: Re: [edk2-devel] [PATCH 0/3] SD+USB perf/DMA fixes

This is now clarified in an ACPI spec ECR 
(https://bugzilla.tianocore.org/show_bug.cgi?id=3335). The example will be 
updated in a future spec errata to use ResourceProducer.

I think this patch can resume as it is not gated by the spec anymore.



From: Andrei Warkentin mailto:awarken...@vmware.com>>
Sent: Thursday, April 8, 2021 10:25 AM
To: Jeremy Linton mailto:jeremy.lin...@arm.com>>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Ard Biesheuvel mailto:ard.biesheu...@arm.com>>; 
l...@nuviainc.com<mailto:l...@nuviainc.com>; p...@akeo.ie<mailto:p...@akeo.ie>; 
Samer El-Haj-Mahmoud 
mailto:samer.el-haj-mahm...@arm.com>>
Subject: Re: [PATCH 0/3] SD+USB perf/DMA fixes

I think Linux's behavior needs to be reconciled with the ACPI spec, which uses 
_DMA with ResourceConsumer, not ResourceProducer.

A

From: Jeremy Linton mailto:jeremy.lin...@arm.com>>
Sent: Thursday, April 8, 2021 12:58 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
mailto:devel@edk2.groups.io>>
Cc: ard.biesheu...@arm.com<mailto:ard.biesheu...@arm.com> 
mailto:ard.biesheu...@arm.com>>; 
l...@nuviainc.com<mailto:l...@nuviainc.com> 
mailto:l...@nuviainc.com>>; 
p...@akeo.ie<mailto:p...@akeo.ie> mailto:p...@akeo.ie>>; 
samer.el-haj-mahm...@arm.com<mailto:samer.el-haj-mahm...@arm.com> 
mailto:samer.el-haj-mahm...@arm.com>>; Andrei 
Warkentin mailto:awarken...@vmware.com>>; Jeremy Linton 
mailto:jeremy.lin...@arm.com>>
Subject: [PATCH 0/3] SD+USB perf/DMA fixes

A large part of why the emmc & dwc2 usb
controllers haven't been working properly is
because the "bus" _DMA was incorrectly tagged
as a consumer, when it needs to be a producer.

That is why linux has been dropping the
translation value portions of _DMA().

Since the emmc2 dma (with the old B0 SoC), and the
dwc2 is expected to work, lets add matching 30 bit
IORT entries for them.

Finally, in the shuffle the high speed cap bit override
was dropped from the linux patches, and I failed
to add it back to the firmware values, this caused
the wifi perf to be lower than it should have been.

Jeremy Linton (3):
  Platform/RaspberryPi/Acpitables: Enable Arasan hispeed mode
  Platform/RaspberryPi/AcpiTables: Add further named components
  Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

 Platform/RaspberryPi/AcpiTables/Dsdt.asl  |  2 +-
 Platform/RaspberryPi/AcpiTables/Emmc.asl  |  2 +-
 Platform/RaspberryPi/AcpiTables/Iort.aslc | 44 ++-
 Platform/RaspberryPi/AcpiTables/Sdhc.asl  |  2 +-
 4 files changed, 46 insertions(+), 4 deletions(-)

--
2.13.7
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH 0/3] SD+USB perf/DMA fixes

[Samer El-Haj-Mahmoud]

Adding Ard's new e-mail

From: devel@edk2.groups.io  On Behalf Of Andrei Warkentin 
via groups.io
Sent: Friday, April 30, 2021 4:30 PM
To: Jeremy Linton ; devel@edk2.groups.io
Cc: Ard Biesheuvel ; l...@nuviainc.com; p...@akeo.ie; 
Samer El-Haj-Mahmoud 
Subject: Re: [edk2-devel] [PATCH 0/3] SD+USB perf/DMA fixes

LGTM

Reviewed-by: Andrei Warkentin 
mailto:awarken...@vmware.com>>

From: Jeremy Linton mailto:jeremy.lin...@arm.com>>
Sent: Thursday, April 8, 2021 12:58 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
mailto:devel@edk2.groups.io>>
Cc: ard.biesheu...@arm.com<mailto:ard.biesheu...@arm.com> 
mailto:ard.biesheu...@arm.com>>; 
l...@nuviainc.com<mailto:l...@nuviainc.com> 
mailto:l...@nuviainc.com>>; 
p...@akeo.ie<mailto:p...@akeo.ie> mailto:p...@akeo.ie>>; 
samer.el-haj-mahm...@arm.com<mailto:samer.el-haj-mahm...@arm.com> 
mailto:samer.el-haj-mahm...@arm.com>>; Andrei 
Warkentin mailto:awarken...@vmware.com>>; Jeremy Linton 
mailto:jeremy.lin...@arm.com>>
Subject: [PATCH 0/3] SD+USB perf/DMA fixes

A large part of why the emmc & dwc2 usb
controllers haven't been working properly is
because the "bus" _DMA was incorrectly tagged
as a consumer, when it needs to be a producer.

That is why linux has been dropping the
translation value portions of _DMA().

Since the emmc2 dma (with the old B0 SoC), and the
dwc2 is expected to work, lets add matching 30 bit
IORT entries for them.

Finally, in the shuffle the high speed cap bit override
was dropped from the linux patches, and I failed
to add it back to the firmware values, this caused
the wifi perf to be lower than it should have been.

Jeremy Linton (3):
  Platform/RaspberryPi/Acpitables: Enable Arasan hispeed mode
  Platform/RaspberryPi/AcpiTables: Add further named components
  Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

 Platform/RaspberryPi/AcpiTables/Dsdt.asl  |  2 +-
 Platform/RaspberryPi/AcpiTables/Emmc.asl  |  2 +-
 Platform/RaspberryPi/AcpiTables/Iort.aslc | 44 ++-
 Platform/RaspberryPi/AcpiTables/Sdhc.asl  |  2 +-
 4 files changed, 46 insertions(+), 4 deletions(-)

--
2.13.7

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH edk2-test 1/1] uefi-sct/SctPkg: IHV: type mismatch in SimpleTextOut test

[Samer El-Haj-Mahmoud]

Reviewed-by: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Heinrich Schuchardt 
> Sent: Tuesday, March 30, 2021 11:09 AM
> To: EDK II Development 
> Cc: Eric Jin ; G Edhaya Chandran
> ; Barton Gao ; Arvin
> Chen ; Samer El-Haj-Mahmoud  mahm...@arm.com>; Heinrich Schuchardt ; G
> Edhaya Chandran 
> Subject: [PATCH edk2-test 1/1] uefi-sct/SctPkg: IHV: type mismatch in
> SimpleTextOut test
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3253
>
> SctPrint() requires that %d refers to an UINTN parameter.
>
> SimpleTextOutBBTestFunction_uefi.c has a lot of
> StandardLib->RecordAssertion() calls where an INT32 is passed
> as argument for a '%d' print code.
>
> This leads to incorrect output like:
>
> MaxMode=-549755813885,
>
> -549755813885 is 0x0xFF83. So MaxMode actually is an INT32
> with value 3 in this example.
>
> Convert the parameters to UINTN.
>
> Signed-off-by: Heinrich Schuchardt 
> Reviewed-by: G Edhaya Chandran
> ---
>  .../SimpleTextOutBBTestFunction_uefi.c| 624 +-
>  1 file changed, 312 insertions(+), 312 deletions(-)
>
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextOut/BlackBoxTest/Simpl
> eTextOutBBTestFunction_uefi.c b/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextOut/BlackBoxTest/Simpl
> eTextOutBBTestFunction_uefi.c
> index 2bc9bcdb51f9..a833498c2816 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextOut/BlackBoxTest/Simpl
> eTextOutBBTestFunction_uefi.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextOut/BlackBoxT
> +++ est/SimpleTextOutBBTestFunction_uefi.c
> @@ -176,12 +176,12 @@ BBTestResetFunctionManualTest (
>   L" Expected:Cursor Position(%d x %d), MaxMode=%d.",
>   __FILE__,
>   (UINTN)__LINE__,
> - SimpleOut->Mode->CursorColumn,
> - SimpleOut->Mode->CursorRow,
> - SimpleOut->Mode->MaxMode,
> - ModeExpected.CursorColumn,
> - ModeExpected.CursorRow,
> - ModeExpected.MaxMode
> + (UINTN)SimpleOut->Mode->CursorColumn,
> + (UINTN)SimpleOut->Mode->CursorRow,
> + (UINTN)SimpleOut->Mode->MaxMode,
> + (UINTN)ModeExpected.CursorColumn,
> + (UINTN)ModeExpected.CursorRow,
> + (UINTN)ModeExpected.MaxMode
>   );
>
>//
> @@ -272,12 +272,12 @@ BBTestResetFunctionManualTest (
>   L" Expected:Cursor Position(%d x %d), MaxMode=%d.",
>   __FILE__,
>   (UINTN)__LINE__,
> - SimpleOut->Mode->CursorColumn,
> - SimpleOut->Mode->CursorRow,
> - SimpleOut->Mode->MaxMode,
> - ModeExpected.CursorColumn,
> - ModeExpected.CursorRow,
> - ModeExpected.MaxMode
> + (UINTN)SimpleOut->Mode->CursorColumn,
> + (UINTN)SimpleOut->Mode->CursorRow,
> + (UINTN)SimpleOut->Mode->MaxMode,
> + (UINTN)ModeExpected.CursorColumn,
> + (UINTN)ModeExpected.CursorRow,
> + (UINTN)ModeExpected.MaxMode
>   );
>
>//
> @@ -505,12 +505,12 @@ BBTestResetFunctionAutoTest (
> L"Expected:Cursor Position(%d x %d), MaxMode=%d.",
> __FILE__,
> (UINTN)__LINE__,
> -   SimpleOut->Mode->CursorColumn,
> -   SimpleOut->Mode->CursorRow,
> -   SimpleOut->Mode->MaxMode,
> -   ModeExpected.CursorColumn,
> -   ModeExpected.CursorRow,
> -   ModeExpected.MaxMode
> +   (UINTN)SimpleOut->Mode->CursorColumn,
> +   (UINTN)SimpleOut->Mode->CursorRow,
> +   (UINTN)SimpleOut->Mode->MaxMode,
> +   (UINTN)ModeExpected.CursorColumn,
> +   (UINTN)ModeExpected.CursorRow,
> +   (UINTN)ModeExpected.MaxMode
> );
>
>  //
> @@ -582,12 +582,12 @@ BBTestResetFunctionAutoTest (
> L" Expected:Cursor Position(%d x %d), MaxMode=%d.",
> __FILE__,
> (UINTN)__LINE__,
> -   SimpleOut->Mode->CursorColumn,
> -   SimpleOut->Mode->CursorRow,
> -   SimpleOut->Mode->MaxMode,
> -

Re: [edk2-devel] [PATCH edk2-test 1/1] uefi-sct/SctPkg: type mismatch in Simple Network test

[Samer El-Haj-Mahmoud]

Reviewed-by: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Heinrich Schuchardt 
> Sent: Tuesday, March 30, 2021 11:04 AM
> To: EDK II Development 
> Cc: Eric Jin ; G Edhaya Chandran
> ; Barton Gao ; Arvin
> Chen ; Samer El-Haj-Mahmoud  mahm...@arm.com>; Heinrich Schuchardt 
> Subject: [PATCH edk2-test 1/1] uefi-sct/SctPkg: type mismatch in Simple
> Network test
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3257
>
> SctPrint() requires that %x and %d refers to an UINTN parameter.
>
> SimpleNetworkBBTestFunction.c tries to print INT32 using %x, %d without
> converting to UINTN resulting in corrupted output like:
>
> SimpleNetworkBBTestFunction.c:891:
> Status - Unsupported, Filter - 
>
> Mode->ReceiveFilterSetting has only 32 bit. The true value is 0.
>
> Convert the parameters to UINTN.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  .../SimpleNetworkBBTestFunction.c | 52 +--
>  1 file changed, 26 insertions(+), 26 deletions(-)
>
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Simpl
> eNetworkBBTestFunction.c b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Simpl
> eNetworkBBTestFunction.c
> index 8767e68e92d4..5fc01aadd96a 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxTest/Simpl
> eNetworkBBTestFunction.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/SimpleNetwork/BlackBoxT
> +++ est/SimpleNetworkBBTestFunction.c
> @@ -775,7 +775,7 @@ BBTestReceiveFilterFunctionTest (
> __FILE__,
> (UINTN)__LINE__,
> Status,
> -   SnpInterface->Mode->ReceiveFilterSetting
> +   (UINTN)SnpInterface->Mode->ReceiveFilterSetting
> );
>
>  // Check point A. Enable Specified bit.
> @@ -797,7 +797,7 @@ BBTestReceiveFilterFunctionTest (
> __FILE__,
> (UINTN)__LINE__,
> Status,
> -   SnpInterface->Mode->ReceiveFilterSetting
> +   (UINTN)SnpInterface->Mode->ReceiveFilterSetting
> );
>
>  // Check point C. Enable and Disable Specified bit together.
> @@ -819,7 +819,7 @@ BBTestReceiveFilterFunctionTest (
> __FILE__,
> (UINTN)__LINE__,
> Status,
> -   SnpInterface->Mode->ReceiveFilterSetting
> +   (UINTN)SnpInterface->Mode->ReceiveFilterSetting
> );
>}
>
> @@ -856,12 +856,12 @@ BBTestReceiveFilterFunctionTest (
> __FILE__,
> (UINTN)__LINE__,
> Status,
> -   SnpInterface->Mode->ReceiveFilterSetting,
> -   SnpInterface->Mode->ReceiveFilterMask,
> -   SnpInterface->Mode->MCastFilterCount,
> -   SnpInterface->Mode->MCastFilter[0].Addr[0],
> -   SnpInterface->Mode->MCastFilter[0].Addr[5],
> -   SnpInterface->Mode->MCastFilter[1].Addr[0]
> +   (UINTN)SnpInterface->Mode->ReceiveFilterSetting,
> +   (UINTN)SnpInterface->Mode->ReceiveFilterMask,
> +   (UINTN)SnpInterface->Mode->MCastFilterCount,
> +   (UINTN)SnpInterface->Mode->MCastFilter[0].Addr[0],
> +   (UINTN)SnpInterface->Mode->MCastFilter[0].Addr[5],
> +   (UINTN)SnpInterface->Mode->MCastFilter[1].Addr[0]
> );
>}
>
> @@ -885,17 +885,17 @@ BBTestReceiveFilterFunctionTest (
>   AssertionType,
>   gSimpleNetworkBBTestFunctionAssertionGuid012,
>   L"EFI_SIMPLE_NETWORK_PROTOCOL.ReceiveFilters - Invoke
> ReceiveFilters() to reset multicast receive filters list and verify interface
> correctness within test case",
> - L"%a:%d:Status - %r, Filter - %x, Mask - %x,Count - %d(%d),
> Address - %x, %x, %x",
> + L"%a:%d:Status - %r, Filter - %x, Mask - %x, Count -
> + %d(%d), Address - %x, %x, %x",
>   __FILE__,
>   (UINTN)__LINE__,
>   Status,
> - SnpInterface->Mode->ReceiveFilterSetting,
> - SnpInterface->Mode->ReceiveFilterMask,
> - SnpInterface->Mode->MCastFilterCount,
> - Mode.MCastFilterCount,
> - SnpInterface->Mode->MCastFilter[0].

Re: [EXTERNAL] Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Samer El-Haj-Mahmoud]

Resurrecting..

This continues to be a pain point.
At this point, it seems to me that we have multiple people and platforms in 
this community that are complaining about code not following the spec, but the 
maintainers are not agreeing because of "legacy implementation of some 
unidentified platforms". This is very unfortunate, but if the path forward is 
to fork the library, so be it.

I also recently opened an ECR against the UEFI spec to clarify the language in 
order to avoid any confusion: 
https://bugzilla.tianocore.org/show_bug.cgi?id=3336


Thanks,
--Samer






> -Original Message-
> From: Laszlo Ersek 
> Sent: Wednesday, February 17, 2021 9:26 AM
> To: Pete Batard ; Leif Lindholm ;
> devel@edk2.groups.io
> Cc: Samer El-Haj-Mahmoud ; Andrei
> Warkentin (awarken...@vmware.com) ; Wang,
> Sunny (HPS SW) ; zhichao@intel.com;
> ray...@intel.com; Ard Biesheuvel ; Andrew
> Fish ; Michael D Kinney ;
> Jian J Wang ; Hao A Wu 
> Subject: Re: [EXTERNAL] Re: [edk2-devel] [edk2][PATCH 1/1]
> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
> recovery
>
> On 02/17/21 13:18, Pete Batard wrote:
> > Hi Leif,
> >
> > Thanks for trying to resurrect this issue.
> >
> > At this stage, and despite some initial pushback in the bugzilla
> > ticket, I believe we can all agree with the consensus that
> > UefiBootManagerLib is not in fact specs-compliant and therefore needs
> > to be fixed, one way or another, to make it specs-compliant.
> >
> > My take on this is that, rather than propose a new patch, I'd much
> > rather have the current maintainers agree on the course of action to
> > fix the library (which, as Leif suggests, might very well be to split
> > the library into a specs-compliant and non-specs-compliant version),
> > as it would of course be better if the fix came from people who have
> > better understanding of the ramifications we might face with trying to
> > correct the current behaviour, and especially, who have knowledge of
> > the platforms that might be impacted from making the lib specs-compliant.
> >
> > Especially, I don't think that the patch that I originally submitted
> > for this, or the additional proposals we made, are still receivable,
> > as they seem to fall short of fixing the issue in a manner that all
> > platforms can be happy with. And that is why I'd like to hear from the
> > maintainers on what their preferred approach would be.
>
> A new Feature PCD could satisfy both sets of platforms, could it not?
>
> (Sorry if the original patch already had such a PCD; I don't remember.)
>
> Of course then we'd have a debate around the DEC default for the new PCD
> -- I'd say the default value of the PCD should match the spec-mandated
> behavior.
>
> I don't recall any specifics, but a bug-compat pattern that's sometimes used 
> is
> this:
>
>   if (BugCompatEnabled) {
> //
> // do the right thing in the wrong place, for legacy platforms' sake
> //
>Foo ();
>   }
>
>   //
>   // Do some stuff.
>   //
>   Bar ();
>
>   if (!BugCompatEnabled) {
> //
> // do the right thing in the right place, for conformant platforms
> //
>Foo ();
>   }
>
> Not sure if it applies here.
>
> Thanks
> Laszlo
>
>
> > On 2021.02.17 11:42, Leif Lindholm wrote:
> >> Hi Pete, +various
> >>
> >> Resurrecting this old thread since Ard pointed out an issue I ran
> >> into myself had already been encountered by Pete.
> >> And the bugzilla ticket (directly below this reply) has had no
> >> relevant progress since August.
> >>
> >> Executive summary:
> >> The current UefiBootManagerLib implementation of the
> PlatformRecovery
> >> path does not notify the EFI_EVENT_GROUP_READY_TO_BOOT event.
> >>
> >> The argument has been made that since changing this would affect an
> >> unnamed number of non-public platforms, the behaviour cannot be
> >> changed even though it violates the UEFI specification.
> >>
> >> I disagree with that statement. If we want to fork UefiBootManagerLib
> >> into a BrokenLegacyUefiBootManagerLib and an actually correct one,
> >> and have those platforms move to the BrokenLegacy variant, I'm OK
> >> with that.
> >>
> >> But using the default version should give specification-compliant
> >> behaviour.
> >>
> >> /
> >>  Leif
> >>
> >> On Tue, Jun 30, 2020 at 18:17:10 +0100, Pete Batard wrote:
> >>> Please note t

Re: [edk2-devel] [PATCH 0/3] SD+USB perf/DMA fixes

[Samer El-Haj-Mahmoud]

This is now clarified in an ACPI spec ECR 
(https://bugzilla.tianocore.org/show_bug.cgi?id=3335). The example will be 
updated in a future spec errata to use ResourceProducer.

I think this patch can resume as it is not gated by the spec anymore.



From: Andrei Warkentin 
Sent: Thursday, April 8, 2021 10:25 AM
To: Jeremy Linton ; devel@edk2.groups.io
Cc: Ard Biesheuvel ; l...@nuviainc.com; p...@akeo.ie; 
Samer El-Haj-Mahmoud 
Subject: Re: [PATCH 0/3] SD+USB perf/DMA fixes

I think Linux's behavior needs to be reconciled with the ACPI spec, which uses 
_DMA with ResourceConsumer, not ResourceProducer.

A

From: Jeremy Linton mailto:jeremy.lin...@arm.com>>
Sent: Thursday, April 8, 2021 12:58 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
mailto:devel@edk2.groups.io>>
Cc: ard.biesheu...@arm.com<mailto:ard.biesheu...@arm.com> 
mailto:ard.biesheu...@arm.com>>; 
l...@nuviainc.com<mailto:l...@nuviainc.com> 
mailto:l...@nuviainc.com>>; 
p...@akeo.ie<mailto:p...@akeo.ie> mailto:p...@akeo.ie>>; 
samer.el-haj-mahm...@arm.com<mailto:samer.el-haj-mahm...@arm.com> 
mailto:samer.el-haj-mahm...@arm.com>>; Andrei 
Warkentin mailto:awarken...@vmware.com>>; Jeremy Linton 
mailto:jeremy.lin...@arm.com>>
Subject: [PATCH 0/3] SD+USB perf/DMA fixes

A large part of why the emmc & dwc2 usb
controllers haven't been working properly is
because the "bus" _DMA was incorrectly tagged
as a consumer, when it needs to be a producer.

That is why linux has been dropping the
translation value portions of _DMA().

Since the emmc2 dma (with the old B0 SoC), and the
dwc2 is expected to work, lets add matching 30 bit
IORT entries for them.

Finally, in the shuffle the high speed cap bit override
was dropped from the linux patches, and I failed
to add it back to the firmware values, this caused
the wifi perf to be lower than it should have been.

Jeremy Linton (3):
  Platform/RaspberryPi/Acpitables: Enable Arasan hispeed mode
  Platform/RaspberryPi/AcpiTables: Add further named components
  Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

 Platform/RaspberryPi/AcpiTables/Dsdt.asl  |  2 +-
 Platform/RaspberryPi/AcpiTables/Emmc.asl  |  2 +-
 Platform/RaspberryPi/AcpiTables/Iort.aslc | 44 ++-
 Platform/RaspberryPi/AcpiTables/Sdhc.asl  |  2 +-
 4 files changed, 46 insertions(+), 4 deletions(-)

--
2.13.7
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH 2/2] Platform/RaspberryPi: Increase genet dma window

[Samer El-Haj-Mahmoud]

+Jared

Reviewed-By: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Jeremy Linton 
> Sent: Thursday, April 15, 2021 3:22 PM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; l...@nuviainc.com;
> p...@akeo.ie; Samer El-Haj-Mahmoud  mahm...@arm.com>; Andrei Warkentin (awarken...@vmware.com)
> ; Jeremy Linton 
> Subject: [PATCH 2/2] Platform/RaspberryPi: Increase genet dma window
>
> The genet is capable of addressing the entire memory space on the RPI4.
> Lets allow it to dma into those regions.
> This solves intermittent issues with grub/etc being able to communicate
> when the 3G limit is lifted on 8G boards.
>
> Signed-off-by: Jeremy Linton 
> ---
>  Platform/RaspberryPi/RPi4/RPi4.dsc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Platform/RaspberryPi/RPi4/RPi4.dsc
> b/Platform/RaspberryPi/RPi4/RPi4.dsc
> index ddf4dd6a41..facf34f034 100644
> --- a/Platform/RaspberryPi/RPi4/RPi4.dsc
> +++ b/Platform/RaspberryPi/RPi4/RPi4.dsc
> @@ -698,7 +698,7 @@
>Silicon/Broadcom/Drivers/Net/BcmGenetDxe/BcmGenetDxe.inf {
>  
>gEmbeddedTokenSpaceGuid.PcdDmaDeviceOffset|0x
> -  gEmbeddedTokenSpaceGuid.PcdDmaDeviceLimit|0x
> +  gEmbeddedTokenSpaceGuid.PcdDmaDeviceLimit|0xff
>}
>
>#
> --
> 2.13.7

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

[Samer El-Haj-Mahmoud]

Update: UEFI Forum ASWG (ACPI spec working group) approved the submitted ECR as 
an errata for future ACPI 6.4 spec publication.

We can go ahead and proceed with this patch as submitted, based on that ECR 
clarification.

With that,

Reviewed-By: Samer El-Haj-Mahmoud 
samer.el-haj-mahm...@arm.com<mailto:samer.el-haj-mahm...@arm.com>

Thanks,
--Samer


From: devel@edk2.groups.io  On Behalf Of Samer 
El-Haj-Mahmoud via groups.io
Sent: Thursday, April 29, 2021 10:03 AM
To: devel@edk2.groups.io; Samer El-Haj-Mahmoud ; 
Andrei Warkentin (awarken...@vmware.com) ; Jeremy Linton 
; r...@edk2.groups.io
Cc: Ard Biesheuvel ; l...@nuviainc.com; p...@akeo.ie; 
Samer El-Haj-Mahmoud 
Subject: Re: [edk2-devel] [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct 
_DMA consumer

Any further comments on the ACPI ECR documented in: 
https://bugzilla.tianocore.org/show_bug.cgi?id=3335 ?

I already have comments from Jeremey and Andrew saying it looks good. If there 
are no objections, I will let ASWG know to approve the ECR for future ACPI spec 
publication.

Thanks,
--Samer




From: devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
mailto:devel@edk2.groups.io>> On Behalf Of Samer 
El-Haj-Mahmoud via groups.io
Sent: Tuesday, April 13, 2021 12:45 PM
To: Andrei Warkentin (awarken...@vmware.com<mailto:awarken...@vmware.com>) 
mailto:awarken...@vmware.com>>; Jeremy Linton 
mailto:jeremy.lin...@arm.com>>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Ard Biesheuvel mailto:ard.biesheu...@arm.com>>; 
l...@nuviainc.com<mailto:l...@nuviainc.com>; p...@akeo.ie<mailto:p...@akeo.ie>; 
Samer El-Haj-Mahmoud 
mailto:samer.el-haj-mahm...@arm.com>>
Subject: Re: [edk2-devel] [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct 
_DMA consumer

I just got to this thread. Apologies for the delay.

I went through the ACPI spec. Here is what I see:

https://uefi.org/specs/ACPI/6.4/19_ASL_Reference/ACPI_Source_Language_Reference.html#qwordmemory-qword-memory-resource-descriptor-macro


"ResourceUsage specifies whether the Memory range is consumed by this device 
(ResourceConsumer) or passed on to child devices (ResourceProducer). If nothing 
is specified, then ResourceConsumer is assumed."



https://uefi.org/specs/ACPI/6.4/06_Device_Configuration/Device_Configuration.html#dma-direct-memory-access



" It specifies the ranges the bus controller (bridge) decodes on the child-side 
of its interface. (This is analogous to the _CRS object, which describes the 
resources that the bus controller decodes on the parent-side of its interface.) 
Any ranges described in the resources of a _DMA object can be used by child 
devices for DMA or bus master transactions.."



The way I read the spec, this wording in the _DMA definition "Any ranges 
described in the resources of a _DMA object can be used by child devices.." 
suggests that this should be a ResourceProducer, per the QWordMemory resource 
descriptor definition above


The _DMA example in section 6.2.4 uses a "ResourceConsumer", when it should 
really be "ResourceProducer" according to these definitions: It describes , the 
child devices view of the address range, so the "translation" added is the 
CPU's view of the same range.



I submitted a "code first" ECR to correct the ACPI spec example (here : 
https://bugzilla.tianocore.org/show_bug.cgi?id=3335). Please provide feedback 
on the BZ (or this thread) whether you agree or not, so we can take this to 
ASWG/UEFI Forum for discussion and approval



Thanks,

--Samer





From: Andrei Warkentin mailto:awarken...@vmware.com>>
Sent: Thursday, April 8, 2021 10:24 AM
To: Jeremy Linton mailto:jeremy.lin...@arm.com>>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Ard Biesheuvel mailto:ard.biesheu...@arm.com>>; 
l...@nuviainc.com<mailto:l...@nuviainc.com>; p...@akeo.ie<mailto:p...@akeo.ie>; 
Samer El-Haj-Mahmoud 
mailto:samer.el-haj-mahm...@arm.com>>
Subject: Re: [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

I don't know... the ACPI spec is weird.

https://uefi.org/specs/ACPI/6.4/06_Device_Configuration/Device_Configuration.html#dma-direct-memory-access

...lists ResourceConsumer for _DMA.

A


From: Jeremy Linton mailto:jeremy.lin...@arm.com>>
Sent: Thursday, April 8, 2021 12:58 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
mailto:devel@edk2.groups.io>>
Cc: ard.biesheu...@arm.com<mailto:ard.biesheu...@arm.com> 
mailto:ard.biesheu...@arm.com>>; 
l...@nuviainc.com<mailto:l...@nuviainc.com> 
mailto:l...@nuviainc.com>>; 
p...@akeo.ie<mailto:p...@akeo.ie> mailto:p...@akeo.ie>>; 
samer.el-haj-mahm...@arm.com<mailto:samer.el-haj-mahm...@arm.com> 
mailto:samer.el-haj-mahm...@arm.com>>; Andrei 
Warkentin mailto:awarken...@vmware.com

Re: [edk2-devel] [edk2][PATCH 1/1] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Samer El-Haj-Mahmoud]

All,

Please take a moment to add any comments to this UEFI ECR BZ. This is needed to 
UEFI Forum can make a decision and close the ECR.
https://bugzilla.tianocore.org/show_bug.cgi?id=3336


Thanks,
--Samer



> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Samer
> El-Haj-Mahmoud via groups.io
> Sent: Tuesday, April 13, 2021 3:48 PM
> To: devel@edk2.groups.io; p...@akeo.ie; Laszlo Ersek
> ; Leif Lindholm ; Ni, Ray
> ; zhichao@intel.com
> Cc: Andrei Warkentin (awarken...@vmware.com)
> ; Ard Biesheuvel ;
> Andrew Fish ; Michael D Kinney
> ; Jian J Wang ; Hao A
> Wu ; sunny.hsuanwen.w...@gmail.com; Samer El-
> Haj-Mahmoud ; Sunny Wang
> 
> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
> recovery
>
> In order to make progress on this, I opened a code-first ECR  against the UEFI
> spec to clarify the language around the Boot options processing.
>
> Code First ECR: https://bugzilla.tianocore.org/show_bug.cgi?id=3336
>
> Feedback on the proposed language is appreciated. Please provide the
> feedback directly in the BZ above.
>
> I will update the thread/BZ with results from USWG.
>
> Thanks,
> --Samer
>
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Pete
> > Batard via groups.io
> > Sent: Thursday, February 25, 2021 5:55 AM
> > To: Wang, Sunny (HPS SW) ; Laszlo Ersek
> > ; Leif Lindholm ;
> > devel@edk2.groups.io; Ni, Ray ;
> > zhichao@intel.com
> > Cc: Samer El-Haj-Mahmoud ; Andrei
> > Warkentin (awarken...@vmware.com) ; Ard
> > Biesheuvel ; Andrew Fish
> ;
> > Michael D Kinney ; Jian J Wang
> > ; Hao A Wu ;
> > sunny.hsuanwen.w...@gmail.com
> > Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
> > MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
> > recovery
> >
> > Hi Sunny,
> >
> > I appreciate the input, but seeing that it is clear that no consensus
> > has been reached with regards to how the specs should be interpreted,
> > and that at least 4 separate people have now indicated that their
> > interpretation is different from the one you are putting forward (i.e.
> > you assert that the current code implementation is specs compliant
> > whereas we assert that the current code implementation is not specs
> > compliant), I believe that any further work on this will have to be
> > conditioned, first, by a specs update, that removes any ambiguity as
> > to the scope in which ReadyToBoot should apply.
> >
> > Until that has happened, it seems very pointless to me to start
> > talking possible code workarounds, because we still can't appear to be
> > in agreement as to whether the current code implementation of
> > ReadyToBoot is specs compliant or not.
> >
> > Now, even as I am the one proposing it, I'm afraid that I am not
> > planning to be the one opening a formal specs update request, since
> > there really is only so much more time I am willing to devote to this
> > matter. But I am hoping somebody else will.
> >
> > Regards,
> >
> > /Pete
> >
> > On 2021.02.22 09:28, Wang, Sunny (HPS SW) wrote:
> > > Hi all,
> > >
> > > How about we signal ReadyToBoot ONLY for the default platform
> > > recovery
> > option?  The default platform recovery option here means the one
> > created by the code below in BdsEntry().
> > >Status = EfiBootManagerInitializeLoadOption (
> > >   &PlatformDefaultBootOption,
> > >   LoadOptionNumberUnassigned,
> > >   LoadOptionTypePlatformRecovery,
> > >   LOAD_OPTION_ACTIVE,
> > >   L"Default PlatformRecovery",
> > >   FilePath,
> > >   NULL,
> > >   0
> > >   );
> > >
> > > In other words, we just need to slightly update Pete's patch as the
> > following (adding the code below to EfiBootManagerProcessLoadOption()):
> > >
> > > +   if ((LoadOption->OptionType == LoadOptionTypePlatformRecovery)
> > > + &&
> > >StrCmp (LoadOption ->Description, L"Default
> > > PlatformRecovery")) {
> > > +//
> > > +// Signal the EVT_SIGNAL_READY_TO_BOOT event when we are
> about
> > to load and execute the boot option.
> > > +//
> > > +EfiSignalEventReadyToBoot ();
> > >
> > > +//
> > > +// Report Status Code to indicate ReadyToBoot was

Re: [edk2-devel] [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

[Samer El-Haj-Mahmoud]

Any further comments on the ACPI ECR documented in: 
https://bugzilla.tianocore.org/show_bug.cgi?id=3335 ?

I already have comments from Jeremey and Andrew saying it looks good. If there 
are no objections, I will let ASWG know to approve the ECR for future ACPI spec 
publication.

Thanks,
--Samer




From: devel@edk2.groups.io  On Behalf Of Samer 
El-Haj-Mahmoud via groups.io
Sent: Tuesday, April 13, 2021 12:45 PM
To: Andrei Warkentin (awarken...@vmware.com) ; Jeremy 
Linton ; devel@edk2.groups.io
Cc: Ard Biesheuvel ; l...@nuviainc.com; p...@akeo.ie; 
Samer El-Haj-Mahmoud 
Subject: Re: [edk2-devel] [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct 
_DMA consumer

I just got to this thread. Apologies for the delay.

I went through the ACPI spec. Here is what I see:

https://uefi.org/specs/ACPI/6.4/19_ASL_Reference/ACPI_Source_Language_Reference.html#qwordmemory-qword-memory-resource-descriptor-macro


"ResourceUsage specifies whether the Memory range is consumed by this device 
(ResourceConsumer) or passed on to child devices (ResourceProducer). If nothing 
is specified, then ResourceConsumer is assumed."



https://uefi.org/specs/ACPI/6.4/06_Device_Configuration/Device_Configuration.html#dma-direct-memory-access



" It specifies the ranges the bus controller (bridge) decodes on the child-side 
of its interface. (This is analogous to the _CRS object, which describes the 
resources that the bus controller decodes on the parent-side of its interface.) 
Any ranges described in the resources of a _DMA object can be used by child 
devices for DMA or bus master transactions.."



The way I read the spec, this wording in the _DMA definition "Any ranges 
described in the resources of a _DMA object can be used by child devices.." 
suggests that this should be a ResourceProducer, per the QWordMemory resource 
descriptor definition above


The _DMA example in section 6.2.4 uses a "ResourceConsumer", when it should 
really be "ResourceProducer" according to these definitions: It describes , the 
child devices view of the address range, so the "translation" added is the 
CPU's view of the same range.



I submitted a "code first" ECR to correct the ACPI spec example (here : 
https://bugzilla.tianocore.org/show_bug.cgi?id=3335). Please provide feedback 
on the BZ (or this thread) whether you agree or not, so we can take this to 
ASWG/UEFI Forum for discussion and approval



Thanks,

--Samer





From: Andrei Warkentin mailto:awarken...@vmware.com>>
Sent: Thursday, April 8, 2021 10:24 AM
To: Jeremy Linton mailto:jeremy.lin...@arm.com>>; 
devel@edk2.groups.io<mailto:devel@edk2.groups.io>
Cc: Ard Biesheuvel mailto:ard.biesheu...@arm.com>>; 
l...@nuviainc.com<mailto:l...@nuviainc.com>; p...@akeo.ie<mailto:p...@akeo.ie>; 
Samer El-Haj-Mahmoud 
mailto:samer.el-haj-mahm...@arm.com>>
Subject: Re: [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

I don't know... the ACPI spec is weird.

https://uefi.org/specs/ACPI/6.4/06_Device_Configuration/Device_Configuration.html#dma-direct-memory-access

...lists ResourceConsumer for _DMA.

A


From: Jeremy Linton mailto:jeremy.lin...@arm.com>>
Sent: Thursday, April 8, 2021 12:58 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
mailto:devel@edk2.groups.io>>
Cc: ard.biesheu...@arm.com<mailto:ard.biesheu...@arm.com> 
mailto:ard.biesheu...@arm.com>>; 
l...@nuviainc.com<mailto:l...@nuviainc.com> 
mailto:l...@nuviainc.com>>; 
p...@akeo.ie<mailto:p...@akeo.ie> mailto:p...@akeo.ie>>; 
samer.el-haj-mahm...@arm.com<mailto:samer.el-haj-mahm...@arm.com> 
mailto:samer.el-haj-mahm...@arm.com>>; Andrei 
Warkentin mailto:awarken...@vmware.com>>; Jeremy Linton 
mailto:jeremy.lin...@arm.com>>
Subject: [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

Bridge devices should be marked as producers so that their
children can consume the resources. In linux if this isn't
true then the translation gets ignored and the DMA values
are incorrect. This fixes DMA on all the devices that
need a translation.

Signed-off-by: Jeremy Linton 
mailto:jeremy.lin...@arm.com>>
---
 Platform/RaspberryPi/AcpiTables/Dsdt.asl | 2 +-
 Platform/RaspberryPi/AcpiTables/Emmc.asl | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl 
b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
index d116f965e1..32cd5fc9f9 100644
--- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
+++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
@@ -205,7 +205,7 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 5, "RPIFDN", "RPI", 2)
 // Only the first GB is available.

 // Bus 0xC000 -> CPU 0x.

 //

-QWordMemory (ResourceConsumer,

+QWordMemory (Res

Re: [edk2-devel] [edk2-sct PATCH] buildzip: Add CapsuleApp.efi to the SCT zip file

[Samer El-Haj-Mahmoud]

Reviewed-by: Samer El-Haj-Mahmoud 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Grant
> Likely via groups.io
> Sent: Tuesday, April 27, 2021 12:16 PM
> To: devel@edk2.groups.io
> Cc: nd ; Grant Likely ; G Edhaya
> Chandran ; Barton Gao
> 
> Subject: [edk2-devel] [edk2-sct PATCH] buildzip: Add CapsuleApp.efi to the
> SCT zip file
> 
> CapsuleApp.efi is necessary for testing capsule updates of the firmware.
> Add it into the default build.
> 
> Cc: G Edhaya Chandran 
> Cc: Barton Gao 
> Signed-off-by: Grant Likely 
> ---
>  uefi-sct/SctPkg/buildzip.sh | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/uefi-sct/SctPkg/buildzip.sh b/uefi-sct/SctPkg/buildzip.sh index
> 6dfb5aec..cdbe80d7 100755
> --- a/uefi-sct/SctPkg/buildzip.sh
> +++ b/uefi-sct/SctPkg/buildzip.sh
> @@ -39,8 +39,8 @@ NUM_CPUS=$((`getconf _NPROCESSORS_ONLN` + 2))
> 
>  make -j"$NUM_CPUS" -C edk2/BaseTools/
> 
> -# Build the SCT and the shell
> -DSC_EXTRA=ShellPkg/ShellPkg.dsc ./SctPkg/build.sh ${TARGET_ARCH} GCC
> RELEASE -j"$NUM_CPUS"
> +# Build the SCT, CapsuleApp.efi, and the shell
> +DSC_EXTRA="ShellPkg/ShellPkg.dsc MdeModulePkg/MdeModulePkg.dsc"
> ./SctPkg/build.sh ${TARGET_ARCH} GCC RELEASE -j"$NUM_CPUS"
> 
>  # Assemble all the files that need to be in the zip file  mkdir -p
> ${TARGET_ARCH}_SCT/EFI/BOOT @@ -50,6 +50,9 @@ mkdir -p
> ${TARGET_ARCH}_SCT/SCT  cp -r
> Build/UefiSct/RELEASE_GCC5/SctPackage${TARGET_ARCH}/${TARGET_ARCH
> }/* ${TARGET_ARCH}_SCT/SCT/  cp
> Build/UefiSct/RELEASE_GCC5/SctPackage${TARGET_ARCH}/SctStartup.nsh
> ${TARGET_ARCH}_SCT/Startup.nsh
> 
> +mkdir -p ${TARGET_ARCH}_SCT/Mde
> +cp Build/MdeModule/RELEASE_GCC5/${TARGET_ARCH}/CapsuleApp.efi
> +${TARGET_ARCH}_SCT/Mde
> +
>  # Copy the SCT Parser tool into the repo  cp sct_parser/*
> ${TARGET_ARCH}_SCT/SCT/Sequence/
> 
> --
> 2.20.1
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#74489): https://edk2.groups.io/g/devel/message/74489
Mute This Topic: https://groups.io/mt/82407764/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] MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform recovery

[Samer El-Haj-Mahmoud]

In order to make progress on this, I opened a code-first ECR  against the UEFI 
spec to clarify the language around the Boot options processing.

Code First ECR: https://bugzilla.tianocore.org/show_bug.cgi?id=3336

Feedback on the proposed language is appreciated. Please provide the feedback 
directly in the BZ above.

I will update the thread/BZ with results from USWG.

Thanks,
--Samer

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Pete
> Batard via groups.io
> Sent: Thursday, February 25, 2021 5:55 AM
> To: Wang, Sunny (HPS SW) ; Laszlo Ersek
> ; Leif Lindholm ;
> devel@edk2.groups.io; Ni, Ray ; zhichao@intel.com
> Cc: Samer El-Haj-Mahmoud ; Andrei
> Warkentin (awarken...@vmware.com) ; Ard
> Biesheuvel ; Andrew Fish ;
> Michael D Kinney ; Jian J Wang
> ; Hao A Wu ;
> sunny.hsuanwen.w...@gmail.com
> Subject: Re: [edk2-devel] [edk2][PATCH 1/1]
> MdeModulePkg/UefiBootManagerLib: Signal ReadyToBoot on platform
> recovery
>
> Hi Sunny,
>
> I appreciate the input, but seeing that it is clear that no consensus has been
> reached with regards to how the specs should be interpreted, and that at
> least 4 separate people have now indicated that their interpretation is
> different from the one you are putting forward (i.e.
> you assert that the current code implementation is specs compliant whereas
> we assert that the current code implementation is not specs compliant), I
> believe that any further work on this will have to be conditioned, first, by a
> specs update, that removes any ambiguity as to the scope in which
> ReadyToBoot should apply.
>
> Until that has happened, it seems very pointless to me to start talking
> possible code workarounds, because we still can't appear to be in agreement
> as to whether the current code implementation of ReadyToBoot is specs
> compliant or not.
>
> Now, even as I am the one proposing it, I'm afraid that I am not planning to
> be the one opening a formal specs update request, since there really is only
> so much more time I am willing to devote to this matter. But I am hoping
> somebody else will.
>
> Regards,
>
> /Pete
>
> On 2021.02.22 09:28, Wang, Sunny (HPS SW) wrote:
> > Hi all,
> >
> > How about we signal ReadyToBoot ONLY for the default platform recovery
> option?  The default platform recovery option here means the one created
> by the code below in BdsEntry().
> >Status = EfiBootManagerInitializeLoadOption (
> >   &PlatformDefaultBootOption,
> >   LoadOptionNumberUnassigned,
> >   LoadOptionTypePlatformRecovery,
> >   LOAD_OPTION_ACTIVE,
> >   L"Default PlatformRecovery",
> >   FilePath,
> >   NULL,
> >   0
> >   );
> >
> > In other words, we just need to slightly update Pete's patch as the
> following (adding the code below to EfiBootManagerProcessLoadOption()):
> >
> > +   if ((LoadOption->OptionType == LoadOptionTypePlatformRecovery) &&
> >StrCmp (LoadOption ->Description, L"Default
> > PlatformRecovery")) {
> > +//
> > +// Signal the EVT_SIGNAL_READY_TO_BOOT event when we are about
> to load and execute the boot option.
> > +//
> > +EfiSignalEventReadyToBoot ();
> >
> > +//
> > +// Report Status Code to indicate ReadyToBoot was signalled
> > +//
> > +REPORT_STATUS_CODE (EFI_PROGRESS_CODE,
> > + (EFI_SOFTWARE_DXE_BS_DRIVER |
> > + EFI_SW_DXE_BS_PC_READY_TO_BOOT_EVENT));
> > +  }
> >
> > I think the existing platforms that have their platform-specific
> PlatformRecovery option may also do either of the following things to make
> the system have no chance to load the default platform recovery option
> because they do have a better way to recover the boot options:
> >  1. Make their PlatformRecovery option have higher priority than the
> default platform recovery option (has a lower number () than the
> default platform recovery option)
> >  2. Remove the default platform recovery option.
> > Therefore, if we only signal ReadyToBoot for the default platform recovery
> option, this may not affect the existing platforms because the code may
> never be run on these platforms.
> >
> >
> >
> >
> >
> > If the solution above doesn't work, I think the suggestion (Solution 2:
> adding a new application as a PlatformRecovery) I mentioned, in the
> beginning, can be re-considered. The suggestion (solution 2) is based on the
> thoughts below:
> >   1.  I think th

Re: [edk2-devel] [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

[Samer El-Haj-Mahmoud]

I just got to this thread. Apologies for the delay.

I went through the ACPI spec. Here is what I see:

https://uefi.org/specs/ACPI/6.4/19_ASL_Reference/ACPI_Source_Language_Reference.html#qwordmemory-qword-memory-resource-descriptor-macro


"ResourceUsage specifies whether the Memory range is consumed by this device 
(ResourceConsumer) or passed on to child devices (ResourceProducer). If nothing 
is specified, then ResourceConsumer is assumed."



https://uefi.org/specs/ACPI/6.4/06_Device_Configuration/Device_Configuration.html#dma-direct-memory-access



" It specifies the ranges the bus controller (bridge) decodes on the child-side 
of its interface. (This is analogous to the _CRS object, which describes the 
resources that the bus controller decodes on the parent-side of its interface.) 
Any ranges described in the resources of a _DMA object can be used by child 
devices for DMA or bus master transactions.."



The way I read the spec, this wording in the _DMA definition "Any ranges 
described in the resources of a _DMA object can be used by child devices.." 
suggests that this should be a ResourceProducer, per the QWordMemory resource 
descriptor definition above


The _DMA example in section 6.2.4 uses a "ResourceConsumer", when it should 
really be "ResourceProducer" according to these definitions: It describes , the 
child devices view of the address range, so the "translation" added is the 
CPU's view of the same range.



I submitted a "code first" ECR to correct the ACPI spec example (here : 
https://bugzilla.tianocore.org/show_bug.cgi?id=3335). Please provide feedback 
on the BZ (or this thread) whether you agree or not, so we can take this to 
ASWG/UEFI Forum for discussion and approval



Thanks,

--Samer





From: Andrei Warkentin 
Sent: Thursday, April 8, 2021 10:24 AM
To: Jeremy Linton ; devel@edk2.groups.io
Cc: Ard Biesheuvel ; l...@nuviainc.com; p...@akeo.ie; 
Samer El-Haj-Mahmoud 
Subject: Re: [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

I don't know... the ACPI spec is weird.

https://uefi.org/specs/ACPI/6.4/06_Device_Configuration/Device_Configuration.html#dma-direct-memory-access

...lists ResourceConsumer for _DMA.

A


From: Jeremy Linton mailto:jeremy.lin...@arm.com>>
Sent: Thursday, April 8, 2021 12:58 AM
To: devel@edk2.groups.io<mailto:devel@edk2.groups.io> 
mailto:devel@edk2.groups.io>>
Cc: ard.biesheu...@arm.com<mailto:ard.biesheu...@arm.com> 
mailto:ard.biesheu...@arm.com>>; 
l...@nuviainc.com<mailto:l...@nuviainc.com> 
mailto:l...@nuviainc.com>>; 
p...@akeo.ie<mailto:p...@akeo.ie> mailto:p...@akeo.ie>>; 
samer.el-haj-mahm...@arm.com<mailto:samer.el-haj-mahm...@arm.com> 
mailto:samer.el-haj-mahm...@arm.com>>; Andrei 
Warkentin mailto:awarken...@vmware.com>>; Jeremy Linton 
mailto:jeremy.lin...@arm.com>>
Subject: [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

Bridge devices should be marked as producers so that their
children can consume the resources. In linux if this isn't
true then the translation gets ignored and the DMA values
are incorrect. This fixes DMA on all the devices that
need a translation.

Signed-off-by: Jeremy Linton 
mailto:jeremy.lin...@arm.com>>
---
 Platform/RaspberryPi/AcpiTables/Dsdt.asl | 2 +-
 Platform/RaspberryPi/AcpiTables/Emmc.asl | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl 
b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
index d116f965e1..32cd5fc9f9 100644
--- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
+++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
@@ -205,7 +205,7 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 5, "RPIFDN", "RPI", 2)
 // Only the first GB is available.

 // Bus 0xC000 -> CPU 0x.

 //

-QWordMemory (ResourceConsumer,

+QWordMemory (ResourceProducer,

   ,

   MinFixed,

   MaxFixed,

diff --git a/Platform/RaspberryPi/AcpiTables/Emmc.asl 
b/Platform/RaspberryPi/AcpiTables/Emmc.asl
index 179dd3ecdb..0fbc2a79ea 100644
--- a/Platform/RaspberryPi/AcpiTables/Emmc.asl
+++ b/Platform/RaspberryPi/AcpiTables/Emmc.asl
@@ -32,7 +32,7 @@ DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN", "RPI4EMMC", 2)
   }



   Name (_DMA, ResourceTemplate() {

-QWordMemory (ResourceConsumer,

+QWordMemory (ResourceProducer,

   ,

   MinFixed,

   MaxFixed,

--
2.13.7
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in a

Re: [edk2-devel] [PATCH 1/1] Platform/RaspberryPi: Setup option for disabling Fast Boot

[Samer El-Haj-Mahmoud]

Sunny,

Thanks for sending this!

This was tested by several RPi4 users and confirmed to fix at least the 
following issue:

https://github.com/pftf/RPi4/issues/144
https://github.com/pftf/RPi4/issues/114

It *may* also fix the following issues (to be confirmed):
https://github.com/pftf/RPi4/issues/117
https://github.com/pftf/RPi4/issues/136

Please add references to these issues (at least confirmed ones) in the commit 
message when you send the v2 of the patch.

With that,

Acked-by: Samer El-Haj-Mahmoud 



> -Original Message-
> From: Sunny Wang 
> Sent: Monday, April 12, 2021 5:06 AM
> To: devel@edk2.groups.io
> Cc: Sunny Wang ; Samer El-Haj-Mahmoud
> ; Jeremy Linton
> ; Pete Batard ; Ard Biesheuvel
> ; Sunny Wang 
> Subject: [PATCH 1/1] Platform/RaspberryPi: Setup option for disabling Fast
> Boot
>
> This is a fix for https://github.com/pftf/RPi4/issues/114.
>
> Changes:
>   1. Add a setup option called Boot Policy and consume the setting
>  during boot to whether perform or skip ConnectAll.
>   2. The Default setting is set to Full discovery because it is not
>  worth enabling Fast boot by default on RaspberryPi systems.
>  Enabling it just saves boot time about 1 second, but caused a
>  lot of issues.
>
> Testing Done:
>   - Booted to Standalone UEFI shell on SD card and use drivers
> command to check the result with Fast Boot and Full discovery
> settings. Then, child/device handles are created as expected.
>
> Note and to-do items:
>   - The root cause looks like that boot loaders and some tools like
> grub and iPXE haven't supported selective connect/Fast boot.
> However, system firmware should still provide a setup option for
> user to enable Fast boot with old version boot loaders and tools
> , which is why we proposed this change. We will also report this
> issue to boot loader and tool vendors/open source GitHubs.
>   - We Will add more options for connecting specific type devices so
> that we can still have the shortest boot time for all use cases.
>
> Cc: Samer El-Haj-Mahmoud 
> Cc: Jeremy Linton 
> Cc: Pete Batard 
> Cc: Ard Biesheuvel 
> Signed-off-by: Sunny Wang 
> ---
>  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c| 11 ++-
>  .../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf  |  3 ++-
>  .../Drivers/ConfigDxe/ConfigDxeHii.uni   | 10 +-
>  .../Drivers/ConfigDxe/ConfigDxeHii.vfr   | 15 ++-
>  Platform/RaspberryPi/Include/ConfigVars.h| 12 +++-
>  .../Library/PlatformBootManagerLib/PlatformBm.c  | 16 ++--
>  .../PlatformBootManagerLib.inf   |  1 +
>  Platform/RaspberryPi/RPi3/RPi3.dsc   | 10 +-
>  Platform/RaspberryPi/RPi4/RPi4.dsc   |  9 -
>  Platform/RaspberryPi/RaspberryPi.dec |  2 ++
>  10 files changed, 80 insertions(+), 9 deletions(-)
>
> diff --git a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> index 22f86d4d44..d3c5869949 100644
> --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> +++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c
> @@ -1,6 +1,6 @@
>  /** @file  *- *  Copyright (c) 2019 - 2020, ARM Limited. All rights 
> reserved.+ *
> Copyright (c) 2019 - 2021, ARM Limited. All rights reserved.  *  Copyright (c)
> 2018 - 2020, Andrei Warkentin   *  *  SPDX-
> License-Identifier: BSD-2-Clause-Patent@@ -281,6 +281,15 @@
> SetupVariables (
>  );   } +  Size = sizeof (UINT32);+  Status = 
> gRT->GetVariable
> (L"BootPolicy",+  &gConfigDxeFormSetGuid,+  
> NULL, &Size,
> &Var32);+  if (EFI_ERROR (Status)) {+Status = PcdSet32S (PcdBootPolicy,
> PcdGet32 (PcdBootPolicy));+ASSERT_EFI_ERROR (Status);+  }+   Size =
> sizeof (UINT32);   Status = gRT->GetVariable (L"SdIsArasan",
> &gConfigDxeFormSetGuid,diff --git
> a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> index d51e54e010..032e40b0c3 100644
> --- a/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> +++ b/Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf
> @@ -2,7 +2,7 @@
>  # #  Component description file for the RasbperryPi DXE platform config
> driver. #-#  Copyright (c) 2019 - 2020, ARM Limited. All rights reserved.+#
> Copyright (c) 2019 - 2021, ARM Limited. All rights reserved. #  Copyright (c)
> 2018 - 2020, Andrei Warkentin  # #  SPDX-
> License-Identifier: BSD-2-Clause-Patent@@ -93,6 +93,7 @@
>gRaspberryPiTokenSpaceGuid.PcdRamLimitTo3GB
> gRaspberryPiTokenSpaceGuid.PcdFanOnGpio
> gRaspberryPiTokenSpaceGuid.PcdFanT

Re: [edk2-devel] [PATCH 1/1] MdeModulePkg/VariableRuntimeDxe: avoid double VA conversion of FVB protocol

[Samer El-Haj-Mahmoud]

Late to the party, but I confirm that this fixes the SetVariable() runtime 
calls on Solid Run Honeycomb LX2 (confirmed from multiple distros)

Tested-by: Samer El-Haj-Mahmoud 



> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo
> Ersek via groups.io
> Sent: Tuesday, March 16, 2021 11:58 AM
> To: Ard Biesheuvel ; devel@edk2.groups.io
> Cc: liming@intel.com; Jon (j...@solid-run.com) ;
> l...@nuviainc.com
> Subject: Re: [edk2-devel] [PATCH 1/1] MdeModulePkg/VariableRuntimeDxe:
> avoid double VA conversion of FVB protocol
>
> On 03/13/21 00:05, Ard Biesheuvel wrote:
> > For historical reasons, the VariableRuntimeDxe performs virtual
> > address conversion on the FVB protocol member pointers of the protocol
> > instance that backs the EFI variable store. However, the driver that
> > produces the actual instance should be doing this, as it is the owner,
> > and provides the actual implementation of those methods.
> >
> > Unfortunately, we cannot simply change this: existing drivers may rely
> > on this behavior, and so the variable driver should take care to only
> > convert the pointers when necessary, but leave them alone when the
> > owner is taking care of this.
> >
> > The virtual address switch event can be delivered in arbitrary order,
> > and so we should take care of this in a way that does not rely on
> > whether this driver converts its pointers either before or after the
> > owner of the FVB protocol receives the event.
> >
> > So let's not convert the pointers at all when the event is delivered,
> > but record the converted addresses in a shadow FVB protocol. This way,
> > we can check when the variable driver is invoked at runtime whether
> > the switch has occurred or not, and perform the switch if it hasn't.
> >
> > Signed-off-by: Ard Biesheuvel 
> > ---
> > Build tested only.
> >
> >  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c | 50
> > +---
> >  1 file changed, 43 insertions(+), 7 deletions(-)
> >
> > diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> > b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> > index 0fca0bb2a9b5..3d83ac4452ee 100644
> > --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> > +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableDxe.c
> > @@ -37,6 +37,8 @@ EDKII_VAR_CHECK_PROTOCOLmVarCheck
> = { VarCheckRegis
> >  
> > VarCheckVariablePropertySet,
> >
> > VarCheckVariablePropertyGet };
> >
> > +STATIC EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL
> mFvbProtocolShadow;
> > +
> >  /**
> >Some Secure Boot Policy Variable may update following other variable
> changes(SecureBoot follows PK change, etc).
> >Record their initial State when variable write service is ready.
> > @@ -105,8 +107,26 @@ AcquireLockOnlyAtBootTime (
> >IN EFI_LOCK *Lock
> >)
> >  {
>
> (1) Why is AcquireLockOnlyAtBootTime() the best place to add this?
>
> (Considering especially the leading comment, "This is a temperary function
> that will be removed when EfiAcquireLock() in UefiLib can handle the call in
> UEFI Runtimer driver in RT phase".)
>
> Obviously, I don't want to create more work for you! I just feel that, if 
> this is
> not the best place, we shouldn't overload this function with a new
> responsibility.
>
> > +  EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL  *FvbInstance;
> > +
> >if (!AtRuntime ()) {
> >  EfiAcquireLock (Lock);
> > +  } else {
> > +//
> > +// Check whether we need to swap in the converted pointer values for
> the
> > +// FVB protocol methods
> > +//
> > +FvbInstance = mVariableModuleGlobal->FvbInstance;
> > +if (FvbInstance != NULL &&
> > +FvbInstance->GetBlockSize != mFvbProtocolShadow.GetBlockSize)
> > + {
>
> (2) It occurs to me that the following pattern (in a single-threaded
> environment):
>
> if (a != b) {
>   a = b;
> }
>
> is just:
>
>   a = b;
>
> (the small CPU cost notwithstanding).
>
> And that puts this patch in a bit different light: it's not that we may or may
> not convert. Instead, we *always* convert, the question is *when* we apply
> the result of the conversion.
>
> Functionally, there is no difference, but to me mentally, there'd be a
> difference, if we said "delay applying the runtime conversion until first 
> call&qu

Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platform/RaspberryPi: Fix dwc2 reset on raspberry pi boards

[Samer El-Haj-Mahmoud]

Reviewed-By: Samer El-Haj-Mahmoud 


Thanks again for this patch. This is reported to fix :

https://github.com/pftf/RPi4/issues/88#issuecomment-792370668
and
https://github.com/pftf/RPi4/issues/122
and possibly:
https://github.com/pftf/RPi4/issues/132

Thanks,
--Samer



> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Samer
> El-Haj-Mahmoud via groups.io
> Sent: Thursday, March 11, 2021 4:51 PM
> To: devel@edk2.groups.io; treffer+groups...@measite.de
> Cc: Pete Batard ; Leif Lindholm ; Ard
> Biesheuvel ; Andrei Warkentin
> (awarken...@vmware.com) ; Jeremy Linton
> ; Samer El-Haj-Mahmoud  mahm...@arm.com>
> Subject: Re: [edk2-devel] [edk2-platforms][PATCH 1/1]
> Platform/RaspberryPi: Fix dwc2 reset on raspberry pi boards
>
> Thanks for the patch!
>
> + Andrei and Jeremey for review
>
> I think this may be a side effect of https://github.com/tianocore/edk2-
> platforms/commit/f8958b86e8863432b815a132a0f0fe82950c6dd1
>
> Previously, the DwHcReset() function did not check for valid Attributes
> passed in as an argument. So if you pass in 0, the function will still happily
> reset the controller. That caused UEFI SCT issues (since the function will 
> take
> in garbage Attributes without checking for their validity, per UEFI spec). The
> change was to verify the Attributes are valid, and return EFI_UNSUPPORTED
> if they are not. The only valid attributes for resetting are
> EFI_USB_HC_RESET_GLOBAL and EFI_USB_HC_RESET_HOST_CONTROLLER.
>
> I think your change makes sense.  But I would like to run more tests.
>
> Acked-by: Samer El-Haj-Mahmoud 
>
>
>
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of René
> > Treffer via groups.io
> > Sent: Thursday, March 11, 2021 7:40 AM
> > To: devel@edk2.groups.io
> > Cc: Pete Batard ; Leif Lindholm ; Ard
> > Biesheuvel 
> > Subject: [edk2-devel] [edk2-platforms][PATCH 1/1] Platform/RaspberryPi:
> > Fix dwc2 reset on raspberry pi boards
> >
> > DwHcReset expects attributes as the second argument. A reset is
> > performed if the passed attribute is valid. However 0 is not a valid
> > attribute and will thus never cause a controller reset.
> >
> > Passing EFI_USB_HC_RESET_HOST_CONTROLLER will reset the dwc2
> > controller as expected.
> >
> > This enables the USB 2.0 port of the raspberry compute module 4.
> > ---
> >  Platform/RaspberryPi/Drivers/DwUsbHostDxe/DriverBinding.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Platform/RaspberryPi/Drivers/DwUsbHostDxe/DriverBinding.c
> > b/Platform/RaspberryPi/Drivers/DwUsbHostDxe/DriverBinding.c
> > index bada13a6cd..bb228e62d9 100644
> > --- a/Platform/RaspberryPi/Drivers/DwUsbHostDxe/DriverBinding.c
> > +++ b/Platform/RaspberryPi/Drivers/DwUsbHostDxe/DriverBinding.c
> > @@ -140,7 +140,7 @@ DriverStart (
> > * UsbBusDxe as of b4e96b82b4e2e47e95014b51787ba5b43abac784
> expects
> > * the HCD to do this. There is no agent invoking DwHcReset anymore.
> > */
> > -  DwHcReset (&DwHc->DwUsbOtgHc, 0);
> > +  DwHcReset (&DwHc->DwUsbOtgHc,
> > EFI_USB_HC_RESET_HOST_CONTROLLER);
> >DwHcSetState (&DwHc->DwUsbOtgHc, EfiUsbHcStateOperational);
> >
> >Status = gBS->InstallMultipleProtocolInterfaces (
> > --
> > 2.27.0
> >
> >
> >
> >
> >
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended 
> recipient,
> please notify the sender immediately and do not disclose the contents to any
> other person, use it for any purpose, or store or copy the information in any
> medium. Thank you.
>
>
> 
>

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#72716): https://edk2.groups.io/g/devel/message/72716
Mute This Topic: https://groups.io/mt/81260443/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/1] Platform/RaspberryPi: Fix dwc2 reset on raspberry pi boards

[Samer El-Haj-Mahmoud]

Thanks for the patch!

+ Andrei and Jeremey for review

I think this may be a side effect of 
https://github.com/tianocore/edk2-platforms/commit/f8958b86e8863432b815a132a0f0fe82950c6dd1

Previously, the DwHcReset() function did not check for valid Attributes passed 
in as an argument. So if you pass in 0, the function will still happily reset 
the controller. That caused UEFI SCT issues (since the function will take in 
garbage Attributes without checking for their validity, per UEFI spec). The 
change was to verify the Attributes are valid, and return EFI_UNSUPPORTED if 
they are not. The only valid attributes for resetting are 
EFI_USB_HC_RESET_GLOBAL and EFI_USB_HC_RESET_HOST_CONTROLLER.

I think your change makes sense.  But I would like to run more tests.

Acked-by: Samer El-Haj-Mahmoud 



> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of René
> Treffer via groups.io
> Sent: Thursday, March 11, 2021 7:40 AM
> To: devel@edk2.groups.io
> Cc: Pete Batard ; Leif Lindholm ; Ard
> Biesheuvel 
> Subject: [edk2-devel] [edk2-platforms][PATCH 1/1] Platform/RaspberryPi:
> Fix dwc2 reset on raspberry pi boards
>
> DwHcReset expects attributes as the second argument. A reset is performed
> if the passed attribute is valid. However 0 is not a valid attribute and will 
> thus
> never cause a controller reset.
>
> Passing EFI_USB_HC_RESET_HOST_CONTROLLER will reset the dwc2
> controller as expected.
>
> This enables the USB 2.0 port of the raspberry compute module 4.
> ---
>  Platform/RaspberryPi/Drivers/DwUsbHostDxe/DriverBinding.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Platform/RaspberryPi/Drivers/DwUsbHostDxe/DriverBinding.c
> b/Platform/RaspberryPi/Drivers/DwUsbHostDxe/DriverBinding.c
> index bada13a6cd..bb228e62d9 100644
> --- a/Platform/RaspberryPi/Drivers/DwUsbHostDxe/DriverBinding.c
> +++ b/Platform/RaspberryPi/Drivers/DwUsbHostDxe/DriverBinding.c
> @@ -140,7 +140,7 @@ DriverStart (
> * UsbBusDxe as of b4e96b82b4e2e47e95014b51787ba5b43abac784 expects
> * the HCD to do this. There is no agent invoking DwHcReset anymore.
> */
> -  DwHcReset (&DwHc->DwUsbOtgHc, 0);
> +  DwHcReset (&DwHc->DwUsbOtgHc,
> EFI_USB_HC_RESET_HOST_CONTROLLER);
>DwHcSetState (&DwHc->DwUsbOtgHc, EfiUsbHcStateOperational);
>
>Status = gBS->InstallMultipleProtocolInterfaces (
> --
> 2.27.0
>
>
>
> 
>

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [edk2-platform][PATCH v1 1/1] EmbeddedPkg/VirtualRealTimeClockLib : Reduce DEBUG message verbosity

[Samer El-Haj-Mahmoud]

Leif,

I admit, this is not *super* annoying on a normal DEBUG build boot. On the RPi4 
for instance, this shows up between 25-50 times until the OS boots (depending 
on the boot source).

On a test run (such as running SCT), this message is *EXTREMLY* annoying. I see 
~6600 instances on one run, accounting for ~60% of the entire debug output 
during the test. I agree we should not be optimizing for a test run, but this 
is just beyond being reasonable..

How useful is this message in non-verbose DEBUG output? Does it need to be 
repeated for every call to LibGetTime() ? I am open for suggestions on rate 
limiting the output.

--Samer

> -Original Message-
> From: Leif Lindholm 
> Sent: Saturday, February 20, 2021 4:46 PM
> To: Ard Biesheuvel 
> Cc: Samer El-Haj-Mahmoud ;
> devel@edk2.groups.io; Ard Biesheuvel ; Pete
> Batard 
> Subject: Re: [edk2-platform][PATCH v1 1/1]
> EmbeddedPkg/VirtualRealTimeClockLib : Reduce DEBUG message verbosity
>
> *How* annoying was this?
>
> This is kind of useful information, well at the "would be good to see in a
> regular DEBUG build" level.
>
> This change will have suddenly effectively hidden a message that was already
> present in many platforms, where they were not (very) annoyingly repetitive
> during a normal boot.
>
> It feels the test suite is not the thing that we need to optimise debug output
> for.
>
> Is there some alternative way we can rate limit this?
>
> /
> Leif
>
> On Sat, Feb 20, 2021 at 17:50:43 +0100, Ard Biesheuvel wrote:
> > On Sat, 20 Feb 2021 at 17:41, Samer El-Haj-Mahmoud
> >  wrote:
> > >
> > > the DEBUG message for using compilation time epoch is appearing very
> > > frequently on DEBUG firmware builds, for example during UEFI SCT runs.
> > > Reduce verbosity to avoid the annoying repetitive message.
> > >
> > > Cc: Ard Biesheuvel 
> > > Cc: Leif Lindholm 
> > > Cc: Pete Batard 
> > > Signed-off-by: Samer El-Haj-Mahmoud  mahm...@arm.com>
> >
> >
> > Reviewed-by: Ard Biesheuvel 
> >
> > Merged as #1434 into master.
> >
> > > ---
> > >
> > > EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.
> > > c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git
> > > a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLi
> > > b.c
> > > b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLi
> > > b.c index 5c13ed4cf190..4210708cff36 100644
> > > ---
> > > a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLi
> > > b.c
> > > +++ b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClo
> > > +++ ckLib.c
> > > @@ -88,7 +88,7 @@ LibGetTime (
> > >  //
> > >  EpochSeconds = BUILD_EPOCH;
> > >  DEBUG ((
> > > -  DEBUG_INFO,
> > > +  DEBUG_VERBOSE,
> > >"LibGetTime: %s non volatile variable was not found - Using
> compilation time epoch.\n",
> > >mEpochVariableName
> > >));
> > > --
> > > 2.25.1
> > >
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

Re: [edk2-devel] [edk2-platform][PATCH v1 1/1] EmbeddedPkg/VirtualRealTimeClockLib : Reduce DEBUG message verbosity

[Samer El-Haj-Mahmoud]

Thank you!

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Ard
> Biesheuvel via groups.io
> Sent: Saturday, February 20, 2021 11:51 AM
> To: Samer El-Haj-Mahmoud 
> Cc: devel@edk2.groups.io; Ard Biesheuvel ;
> Leif Lindholm ; Pete Batard 
> Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 1/1]
> EmbeddedPkg/VirtualRealTimeClockLib : Reduce DEBUG message verbosity
>
> On Sat, 20 Feb 2021 at 17:41, Samer El-Haj-Mahmoud  mahm...@arm.com> wrote:
> >
> > the DEBUG message for using compilation time epoch is appearing very
> > frequently on DEBUG firmware builds, for example during UEFI SCT runs.
> > Reduce verbosity to avoid the annoying repetitive message.
> >
> > Cc: Ard Biesheuvel 
> > Cc: Leif Lindholm 
> > Cc: Pete Batard 
> > Signed-off-by: Samer El-Haj-Mahmoud  mahm...@arm.com>
>
>
> Reviewed-by: Ard Biesheuvel 
>
> Merged as #1434 into master.
>
> > ---
> >  EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
> > | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git
> > a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.
> > c
> > b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.
> > c index 5c13ed4cf190..4210708cff36 100644
> > ---
> > a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.
> > c
> > +++
> b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClock
> > +++ Lib.c
> > @@ -88,7 +88,7 @@ LibGetTime (
> >  //
> >  EpochSeconds = BUILD_EPOCH;
> >  DEBUG ((
> > -  DEBUG_INFO,
> > +  DEBUG_VERBOSE,
> >"LibGetTime: %s non volatile variable was not found - Using 
> > compilation
> time epoch.\n",
> >mEpochVariableName
> >));
> > --
> > 2.25.1
> >
>
>
> 
>

IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.


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

[edk2-devel] [edk2-platform][PATCH v1 1/1] EmbeddedPkg/VirtualRealTimeClockLib : Reduce DEBUG message verbosity

[Samer El-Haj-Mahmoud]

the DEBUG message for using compilation time epoch is appearing very
frequently on DEBUG firmware builds, for example during UEFI SCT runs.
Reduce verbosity to avoid the annoying repetitive message.

Cc: Ard Biesheuvel 
Cc: Leif Lindholm 
Cc: Pete Batard 
Signed-off-by: Samer El-Haj-Mahmoud 
---
 EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c 
b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
index 5c13ed4cf190..4210708cff36 100644
--- a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
+++ b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
@@ -88,7 +88,7 @@ LibGetTime (
 //
 EpochSeconds = BUILD_EPOCH;
 DEBUG ((
-  DEBUG_INFO,
+  DEBUG_VERBOSE,
   "LibGetTime: %s non volatile variable was not found - Using compilation 
time epoch.\n",
   mEpochVariableName
   ));
-- 
2.25.1



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

Re: [edk2-devel] [edk2-platform][PATCH v1 1/1] EmbeddedPkg/VirtualRealTimeClockLib : Reduce DEBUG message verbosity

[Samer El-Haj-Mahmoud]

Resending with Ard's new e-mail address


> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Samer
> El-Haj-Mahmoud via groups.io
> Sent: Wednesday, January 6, 2021 9:37 AM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Pete Batard
> ; Leif Lindholm ; Samer El-Haj-
> Mahmoud 
> Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 1/1]
> EmbeddedPkg/VirtualRealTimeClockLib : Reduce DEBUG message verbosity
>
> resent
>
> > -Original Message-
> > From: Ard Biesheuvel 
> > Sent: Wednesday, January 6, 2021 5:34 AM
> > To: Samer El-Haj-Mahmoud ; Pete
> Batard
> > ; devel@edk2.groups.io; Leif Lindholm
> > 
> > Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 1/1]
> > EmbeddedPkg/VirtualRealTimeClockLib : Reduce DEBUG message
> verbosity
> >
> > On 1/5/21 9:46 PM, Samer El-Haj-Mahmoud wrote:
> > > Gentle reminder...
> > >
> >
> > Please resend this with me on cc so I have it in my mailbox.
> >
> > >> -Original Message-
> > >> From: Pete Batard 
> > >> Sent: Wednesday, December 23, 2020 11:37 AM
> > >> To: Samer El-Haj-Mahmoud ;
> > >> devel@edk2.groups.io
> > >> Cc: Leif Lindholm ; Ard Biesheuvel
> > >> 
> > >> Subject: Re: [edk2-devel] [edk2-platform][PATCH v1 1/1]
> > >> EmbeddedPkg/VirtualRealTimeClockLib : Reduce DEBUG message
> > verbosity
> > >>
> > >> On 2020.12.20 19:14, Samer El-Haj-Mahmoud wrote:
> > >>> Using Ard's correct e-mail
> > >>>
> > >>>> -Original Message-
> > >>>> From: devel@edk2.groups.io  On Behalf Of
> > >> Samer
> > >>>> El-Haj-Mahmoud via groups.io
> > >>>> Sent: Sunday, December 20, 2020 2:08 PM
> > >>>> To: devel@edk2.groups.io
> > >>>> Cc: Ard Biesheuvel ; Leif Lindholm
> > >>>> ; Pete Batard 
> > >>>> Subject: [edk2-devel] [edk2-platform][PATCH v1 1/1]
> > >>>> EmbeddedPkg/VirtualRealTimeClockLib : Reduce DEBUG message
> > >> verbosity
> > >>>>
> > >>>> the DEBUG message for using compilation time epoch is appearing
> > >>>> very frequently on DEBUG firmware builds, for example during UEFI
> > SCT runs.
> > >>>> Reduce verbosity to avoid the annoying repetitive message.
> > >>>>
> > >>>> Cc: Ard Biesheuvel 
> > >>>> Cc: Leif Lindholm 
> > >>>> Cc: Pete Batard 
> > >>>> Signed-off-by: Samer El-Haj-Mahmoud  > >> mahm...@arm.com>
> > >>>> ---
> > >>>>
> > >>>>
> > EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib
> > >>>> .c
> > >>>> |
> > >>>> 2 +-
> > >>>>   1 file changed, 1 insertion(+), 1 deletion(-)
> > >>>>
> > >>>> diff --git
> > >>>>
> > a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockL
> > >>>> ib
> > >>>> .c
> > >>>>
> > >>
> > b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib
> > >>>> .c index 5c13ed4cf190..4210708cff36 100644
> > >>>> ---
> > >>>>
> > a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockL
> > >>>> ib
> > >>>> .c
> > >>>> +++
> > >>>>
> > >>
> > b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib
> > >>>> .c
> > >>>> @@ -88,7 +88,7 @@ LibGetTime (
> > >>>>   //
> > >>>>
> > >>>>   EpochSeconds = BUILD_EPOCH;
> > >>>>
> > >>>>   DEBUG ((
> > >>>>
> > >>>> -  DEBUG_INFO,
> > >>>>
> > >>>> +  DEBUG_VERBOSE,
> > >>>>
> > >>>> "LibGetTime: %s non volatile variable was not found -
> > >>>> Using compilation time epoch.\n",
> > >>>>
> > >>>> mEpochVariableName
> > >>>>
> > >>>> ));
> > >>>>
> > >>>> --
> > >>>> 2.25.1
> > >>>>
> > >>>>
> > >>>>
> > >>>> -=-=-=

Re: [edk2-devel] [edk2-test PATCHv2 5/5] SctPkg: Remove trailing whitespace

[Samer El-Haj-Mahmoud]

Reviewed-by: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Daniel Schaefer 
> Sent: Tuesday, February 9, 2021 10:44 AM
> To: devel@edk2.groups.io
> Cc: G Edhaya Chandran ; Barton Gao
> ; Samer El-Haj-Mahmoud  mahm...@arm.com>; Eric Jin ; Arvin Chen
> ; Leif Lindholm ; Heinrich
> Schuchardt ; Abner Chang 
> Subject: [edk2-test PATCHv2 5/5] SctPkg: Remove trailing whitespace
>
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3042
>
> Cc: G Edhaya Chandran 
> Cc: Barton Gao 
> Cc: Samer El-Haj-Mahmoud 
> Cc: Eric Jin 
> Cc: Arvin Chen 
> Cc: Leif Lindholm 
> Cc: Heinrich Schuchardt 
> Cc: Abner Chang 
> Signed-off-by: Daniel Schaefer 
> ---
>  uefi-sct/SctPkg/Library/SctLib/Aarch64/SctLibPlat.h
> |  4 +--
>  uefi-sct/SctPkg/Library/SctLib/Aarch64/initplat.c
> |  6 ++---
>  uefi-sct/SctPkg/Library/SctLib/Riscv64/SctLibPlat.h
> |  7 +++--
>  uefi-sct/SctPkg/Library/SctLib/Riscv64/initplat.c
> |  6 ++---
>  uefi-sct/SctPkg/SCRT/SCRTApp/Aarch64/GoVirtual.S
> | 15 ++-
>  uefi-sct/SctPkg/SCRT/SCRTApp/Aarch64/VirtualMemory.c
> | 22 +++
>  uefi-sct/SctPkg/SCRT/SCRTApp/Riscv64/GoVirtual.S
> |  6 ++---
>  uefi-sct/SctPkg/SCRT/SCRTApp/Riscv64/VirtualMemory.c
> |  6 ++---
>  uefi-sct/SctPkg/SCRT/SCRTDriver/Aarch64/Debug.c
> | 28 +++-
>  uefi-sct/SctPkg/SCRT/SCRTDriver/Aarch64/Dump.c
> |  8 +++---
>  uefi-sct/SctPkg/SCRT/SCRTDriver/Aarch64/Io.c
> | 15 ++-
>  uefi-sct/SctPkg/SCRT/SCRTDriver/Aarch64/Io.h
> |  8 +++---
>  uefi-sct/SctPkg/SCRT/SCRTDriver/Riscv64/Debug.c
> |  6 ++---
>  uefi-sct/SctPkg/SCRT/SCRTDriver/Riscv64/Dump.c
> |  8 +++---
>  uefi-sct/SctPkg/SCRT/SCRTDriver/Riscv64/Io.c
> |  8 +++---
>  uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/DebugSupport/BlackBoxTest/Aarch6
> 4/DebugSupportBBTestCacheFunction.c |  6 ++---
>  uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/DebugSupport/BlackBoxTest/Aarch6
> 4/DebugSupportBBTestExceptionCallbackFunction.c | 18 ++---
>  uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/DebugSupport/BlackBoxTest/Aarch6
> 4/PlatformIsa.c | 10 +++
>  uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/DebugSupport/BlackBoxTest/Riscv64
> /DebugSupportBBTestCacheFunction.c |  6 ++---
>  uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/DebugSupport/BlackBoxTest/Riscv64
> /DebugSupportBBTestExceptionCallbackFunction.c |  6 ++---
>  uefi-
> sct/SctPkg/TestCase/UEFI/EFI/Protocol/DebugSupport/BlackBoxTest/Riscv64
> /PlatformIsa.c |  6 ++---
>  uefi-
> sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Aarch64/EntsLib
> Plat.h |  8 +++---
>  uefi-
> sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Aarch64/InitPlat
> .c|  6 ++---
>  uefi-
> sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Riscv64/EntsLib
> Plat.h |  6 ++---
>  uefi-
> sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Riscv64/InitPlat.
> c|  6 ++---
>  25 files changed, 109 insertions(+), 122 deletions(-)
>
> diff --git a/uefi-sct/SctPkg/Library/SctLib/Aarch64/SctLibPlat.h b/uefi-
> sct/SctPkg/Library/SctLib/Aarch64/SctLibPlat.h
> index ee7c656b..b7832e18 100644
> --- a/uefi-sct/SctPkg/Library/SctLib/Aarch64/SctLibPlat.h
> +++ b/uefi-sct/SctPkg/Library/SctLib/Aarch64/SctLibPlat.h
> @@ -5,12 +5,12 @@
>
>
>This program and the accompanying materials
>
>are licensed and made available under the terms and conditions of the BSD
> License
>
> -  which accompanies this distribution.  The full text of the license may be
> found at
>
> +  which accompanies this distribution.  The full text of the license may be
> found at
>
>http://opensource.org/licenses/bsd-license.php
>
>
>
>THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> BASIS,
>
>WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> EXPRESS OR IMPLIED.
>
> -
>
> +
>
>  **/
>
>  /*++
>
>
>
> diff --git a/uefi-sct/SctPkg/Library/SctLib/Aarch64/initplat.c b/uefi-
> sct/SctPkg/Library/SctLib/Aarch64/initplat.c
> index a48bb2f3..1c247c91 100644
> --- a/uefi-sct/SctPkg/Library/SctLib/Aarch64/initplat.c
> +++ b/uefi-sct/SctPkg/Library/SctLib/Aarch64/initplat.c
> @@ -5,12 +5,12 @@
>
>
>This program and the accompanying materials
>
>are licensed and made available under the terms and conditions of the BSD
> License
>
> -  which accompanies this distribution.  The full text of the license 

Re: [edk2-devel] [edk2-sct PATCH 1/3] edk2-test: Add support for building extra packages

[Samer El-Haj-Mahmoud]

Reviewed-by: Samer El-Haj-Mahmoud 

> -Original Message-
> From: Grant Likely 
> Sent: Thursday, February 11, 2021 12:46 PM
> To: devel@edk2.groups.io; G Edhaya Chandran
> ; Barton Gao 
> Cc: nd ; Samer El-Haj-Mahmoud  mahm...@arm.com>; Grant Likely ; Samer El-Haj-
> Mahmoud 
> Subject: [edk2-sct PATCH 1/3] edk2-test: Add support for building extra
> packages
> 
> The build.sh script is very useful for setting up the build environment before
> calling the package build. Sometimes additional packages are needed when
> building the SCT. (e.g., it is useful to build ShellPkg).
> Refactor the build code to allow additional DSCs to be added to the build.
> 
> This patch is useful when building a full SCT image that includes the
> EDK2 shell.
> 
> Signed-off-by: Grant Likely 
> Cc: G Edhaya Chandran 
> Cc: Barton Gao 
> Cc: Samer El-Haj-Mahmoud 
> ---
>  uefi-sct/SctPkg/build.sh | 34 +-
>  1 file changed, 13 insertions(+), 21 deletions(-)
> 
> diff --git a/uefi-sct/SctPkg/build.sh b/uefi-sct/SctPkg/build.sh index
> 37667711..22cf9667 100755
> --- a/uefi-sct/SctPkg/build.sh
> +++ b/uefi-sct/SctPkg/build.sh
> @@ -249,28 +249,20 @@ mkdir -p $DEST_DIR  cp
> $EDK_TOOLS_PATH/Source/C/bin/GenBin $DEST_DIR/GenBin
> 
>  #
> -# Build the SCT package
> +# Build the packages needed for the SCT # Set $DSC_EXTRA to any extra
> +packages needed for the build
>  #
> -build -p SctPkg/UEFI/UEFI_SCT.dsc -a $SCT_TARGET_ARCH -t
> $TARGET_TOOLS -b $SCT_BUILD $3 $4 $5 $6 $7 $8 $9
> -
> -# Check if there is any error
> -status=$?
> -if test $status -ne 0
> -then
> -  echo Could not build the UEFI SCT package
> -  exit -1
> -fi
> -
> -build -p SctPkg/UEFI/IHV_SCT.dsc -a $SCT_TARGET_ARCH -t
> $TARGET_TOOLS -b $SCT_BUILD $3 $4 $5 $6 $7 $8 $9
> -
> -# Check if there is any error
> -status=$?
> -if test $status -ne 0
> -then
> -  echo Could not build the IHV SCT package
> -  exit -1
> -fi
> -
> +for DSC in SctPkg/UEFI/UEFI_SCT.dsc SctPkg/UEFI/IHV_SCT.dsc
> $DSC_EXTRA
> +do
> + build -p $DSC -a $SCT_TARGET_ARCH -t $TARGET_TOOLS -b
> $SCT_BUILD $3 $4 $5 $6 $7 $8 $9
> + # Check if there is any error
> + status=$?
> + if test $status -ne 0
> + then
> + echo Could not build package $DSC
> + exit -1
> + fi
> +done
> 
>  #
>  # If the argument is clean, then don't have to generate Sct binary.
> --
> 2.20.1



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