Date   

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

Samer El-Haj-Mahmoud
 

+Ard's new e-mail address

-----Original Message-----
From: Jeremy Linton <jeremy.linton@...>
Sent: Thursday, April 8, 2021 1:59 AM
To: devel@edk2.groups.io
Cc: Ard Biesheuvel <Ard.Biesheuvel@...>; leif@...;
pete@...; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@...>; Andrei Warkentin (awarkentin@...)
<awarkentin@...>; Jeremy Linton <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 <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 0xC0000000 -> CPU
0x00000000. //- 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.


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

Samer El-Haj-Mahmoud
 

+ Ard’s new e-mail address

 

 

From: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
Sent: Friday, April 30, 2021 2:05 PM
To: devel@edk2.groups.io; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>; Andrei Warkentin (awarkentin@...) <awarkentin@...>; Jeremy Linton <Jeremy.Linton@...>
Cc: Ard Biesheuvel <Ard.Biesheuvel@...>; leif@...; pete@...; Samer El-Haj-Mahmoud <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-Mahmoud@...

 

Thanks,

--Samer

 

 

From: devel@edk2.groups.io <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 <Samer.El-Haj-Mahmoud@...>; Andrei Warkentin (awarkentin@...) <awarkentin@...>; Jeremy Linton <Jeremy.Linton@...>; rfc@edk2.groups.io
Cc: Ard Biesheuvel <Ard.Biesheuvel@...>; leif@...; pete@...; Samer El-Haj-Mahmoud <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 <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 (awarkentin@...) <awarkentin@...>; Jeremy Linton <Jeremy.Linton@...>; devel@edk2.groups.io
Cc: Ard Biesheuvel <Ard.Biesheuvel@...>; leif@...; pete@...; Samer El-Haj-Mahmoud <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 <awarkentin@...>
Sent: Thursday, April 8, 2021 10:24 AM
To: Jeremy Linton <Jeremy.Linton@...>; devel@edk2.groups.io
Cc: Ard Biesheuvel <Ard.Biesheuvel@...>; leif@...; pete@...; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>
Subject: Re: [PATCH 3/3] Platform/RaspberryPi/AcpiTables: Correct _DMA consumer

 

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

 

 

...lists ResourceConsumer for _DMA.

 

A

 


From: Jeremy Linton <jeremy.linton@...>
Sent: Thursday, April 8, 2021 12:58 AM
To: devel@edk2.groups.io <devel@edk2.groups.io>
Cc: ard.biesheuvel@... <ard.biesheuvel@...>; leif@... <leif@...>; pete@... <pete@...>; samer.el-haj-mahmoud@... <samer.el-haj-mahmoud@...>; Andrei Warkentin <awarkentin@...>; Jeremy Linton <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 <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 0xC0000000 -> CPU 0x00000000.

         //

-        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.

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.


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

Samer El-Haj-Mahmoud
 

+ Ard’s new e-mail address

 

 

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

 

Reviewed-by: Andrei Warkentin <awarkentin@...>


From: Jeremy Linton <jeremy.linton@...>
Sent: Thursday, April 8, 2021 12:58 AM
To: devel@edk2.groups.io <devel@edk2.groups.io>
Cc: ard.biesheuvel@... <ard.biesheuvel@...>; leif@... <leif@...>; pete@... <pete@...>; samer.el-haj-mahmoud@... <samer.el-haj-mahmoud@...>; Andrei Warkentin <awarkentin@...>; Jeremy Linton <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 <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.


Re: [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 <pete@...>
Sent: Thursday, April 8, 2021 5:48 AM
To: Jeremy Linton <Jeremy.Linton@...>; devel@edk2.groups.io
Cc: Ard Biesheuvel <Ard.Biesheuvel@...>; leif@...; Samer
El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>; Andrei Warkentin
(awarkentin@...) <awarkentin@...>
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 <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

+ }

}

};


Reviewed-by: Pete Batard <pete@...>
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.


Re: [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 <jeremy.linton@...>
Sent: Thursday, April 8, 2021 1:59 AM
To: devel@edk2.groups.io
Cc: Ard Biesheuvel <Ard.Biesheuvel@...>; leif@...;
pete@...; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@...>; Andrei Warkentin (awarkentin@...)
<awarkentin@...>; Jeremy Linton <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 <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.


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

Samer El-Haj-Mahmoud
 

+ Ard’s new e-mail address

 

 

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

 

Reviewed-by: Andrei Warkentin <awarkentin@...>


From: Pete Batard <pete@...>
Sent: Thursday, April 8, 2021 4:48 AM
To: Jeremy Linton <jeremy.linton@...>; devel@edk2.groups.io <devel@edk2.groups.io>
Cc: ard.biesheuvel@... <ard.biesheuvel@...>; leif@... <leif@...>; samer.el-haj-mahmoud@... <samer.el-haj-mahmoud@...>; Andrei Warkentin <awarkentin@...>
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 <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 <pete@...>

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.


Re: [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 <pete@...>
Sent: Thursday, April 8, 2021 5:48 AM
To: Jeremy Linton <Jeremy.Linton@...>; devel@edk2.groups.io
Cc: Ard Biesheuvel <Ard.Biesheuvel@...>; leif@...; Samer
El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@...>; Andrei Warkentin
(awarkentin@...) <awarkentin@...>
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 <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 <pete@...>
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.


Re: [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 <jeremy.linton@...>
Sent: Thursday, April 8, 2021 1:59 AM
To: devel@edk2.groups.io
Cc: Ard Biesheuvel <Ard.Biesheuvel@...>; leif@...;
pete@...; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@...>; Andrei Warkentin (awarkentin@...)
<awarkentin@...>; Jeremy Linton <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 <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.


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

Samer El-Haj-Mahmoud
 

Adding Ard’s new e-mail address

 

From: devel@edk2.groups.io <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 (awarkentin@...) <awarkentin@...>; Jeremy Linton <Jeremy.Linton@...>; devel@edk2.groups.io
Cc: Ard Biesheuvel <Ard.Biesheuvel@...>; leif@...; pete@...; Samer El-Haj-Mahmoud <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 <awarkentin@...>
Sent: Thursday, April 8, 2021 10:25 AM
To: Jeremy Linton <Jeremy.Linton@...>; devel@edk2.groups.io
Cc: Ard Biesheuvel <Ard.Biesheuvel@...>; leif@...; pete@...; Samer El-Haj-Mahmoud <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 <jeremy.linton@...>
Sent: Thursday, April 8, 2021 12:58 AM
To:
devel@edk2.groups.io <devel@edk2.groups.io>
Cc:
ard.biesheuvel@... <ard.biesheuvel@...>; leif@... <leif@...>; pete@... <pete@...>; samer.el-haj-mahmoud@... <samer.el-haj-mahmoud@...>; Andrei Warkentin <awarkentin@...>; Jeremy Linton <jeremy.linton@...>
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.


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

Samer El-Haj-Mahmoud
 

Adding Ard’s new e-mail

 

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

 

LGTM 

 

Reviewed-by: Andrei Warkentin <awarkentin@...>


From: Jeremy Linton <jeremy.linton@...>
Sent: Thursday, April 8, 2021 12:58 AM
To: devel@edk2.groups.io <devel@edk2.groups.io>
Cc: ard.biesheuvel@... <ard.biesheuvel@...>; leif@... <leif@...>; pete@... <pete@...>; samer.el-haj-mahmoud@... <samer.el-haj-mahmoud@...>; Andrei Warkentin <awarkentin@...>; Jeremy Linton <jeremy.linton@...>
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.


Re: [edk2-platforms PATCH 0/6] Marvell SD/MMC updates

Marcin Wojtas
 

pon., 10 maj 2021 o 18:07 Ard Biesheuvel <ardb@...> napisał(a):

On Fri, 30 Apr 2021 at 20:04, Marcin Wojtas <mw@...> wrote:

Hi,


pon., 19 kwi 2021 o 10:52 Marcin Wojtas <mw@...> napisał(a):

pon., 19 kwi 2021 o 10:49 Marcin Wojtas <mw@...> napisał(a):

Hi,

This series applies modifications to the MMC settings
on the platforms based on the Marvell SoCs.
Where possible, higher speeds are enabled.
Moreover a DSDT description is added, which allows
to make use of the SD/MMC in the OS booted with ACPI.

More details can be found in the commit logs.
The patchest is publicly available in the github:
https://github.com/semihalf-wojtas-marcin/edk2-platforms/commits/misc-uspstream-r20210416
Correct link:
https://github.com/semihalf-wojtas-marcin/edk2-platforms/commits/mmc-upstream-r20210419

I am looking forward to your review.
Do you have any comments/remarks to the patchset?
For the series,

Acked-by: Ard Biesheuvel <ardb@...>


Pushed as 7661dfff1528..c7e1631a673f
Thanks!
Marcin

thanks,


Best regards,
Marcin

Marcin Wojtas (6):
Marvell/Armada80x0Db: Update CP0 MMC settings
Marvell/Armada80x0Db: Introduce SD/MMC ACPI description
Marvell/Armada70x0Db: Update CP0 MMC settings
Marvell/Armada70x0Db: Introduce SD/MMC ACPI description
Marvell/Cn913xDb: Update AP807 MMC settings
Marvell/Cn913xDb: Introduce SD/MMC ACPI description

Platform/Marvell/Armada70x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.h | 1 +
Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.h | 1 +
Platform/Marvell/Armada70x0Db/Armada70x0DbBoardDescLib/Armada70x0DbBoardDescLib.c | 2 +-
Platform/Marvell/Armada70x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.c | 79 +++++++++++++++-----
Platform/Marvell/Armada80x0Db/Armada80x0DbBoardDescLib/Armada80x0DbBoardDescLib.c | 2 +-
Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.c | 8 +-
Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.c | 23 ++++++
Silicon/Marvell/Armada7k8k/AcpiTables/Armada70x0Db/Dsdt.asl | 56 ++++++++++++++
Silicon/Marvell/Armada7k8k/AcpiTables/Armada80x0Db/Dsdt.asl | 59 +++++++++++++++
Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Dsdt.asl | 59 +++++++++++++++
10 files changed, 266 insertions(+), 24 deletions(-)

--
2.29.0


Re: [edk2-platforms PATCH 0/6] Marvell SD/MMC updates

Ard Biesheuvel
 

On Fri, 30 Apr 2021 at 20:04, Marcin Wojtas <mw@...> wrote:

Hi,


pon., 19 kwi 2021 o 10:52 Marcin Wojtas <mw@...> napisał(a):

pon., 19 kwi 2021 o 10:49 Marcin Wojtas <mw@...> napisał(a):

Hi,

This series applies modifications to the MMC settings
on the platforms based on the Marvell SoCs.
Where possible, higher speeds are enabled.
Moreover a DSDT description is added, which allows
to make use of the SD/MMC in the OS booted with ACPI.

More details can be found in the commit logs.
The patchest is publicly available in the github:
https://github.com/semihalf-wojtas-marcin/edk2-platforms/commits/misc-uspstream-r20210416
Correct link:
https://github.com/semihalf-wojtas-marcin/edk2-platforms/commits/mmc-upstream-r20210419

I am looking forward to your review.
Do you have any comments/remarks to the patchset?
For the series,

Acked-by: Ard Biesheuvel <ardb@...>


Pushed as 7661dfff1528..c7e1631a673f

thanks,


Best regards,
Marcin

Marcin Wojtas (6):
Marvell/Armada80x0Db: Update CP0 MMC settings
Marvell/Armada80x0Db: Introduce SD/MMC ACPI description
Marvell/Armada70x0Db: Update CP0 MMC settings
Marvell/Armada70x0Db: Introduce SD/MMC ACPI description
Marvell/Cn913xDb: Update AP807 MMC settings
Marvell/Cn913xDb: Introduce SD/MMC ACPI description

Platform/Marvell/Armada70x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.h | 1 +
Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.h | 1 +
Platform/Marvell/Armada70x0Db/Armada70x0DbBoardDescLib/Armada70x0DbBoardDescLib.c | 2 +-
Platform/Marvell/Armada70x0Db/NonDiscoverableInitLib/NonDiscoverableInitLib.c | 79 +++++++++++++++-----
Platform/Marvell/Armada80x0Db/Armada80x0DbBoardDescLib/Armada80x0DbBoardDescLib.c | 2 +-
Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.c | 8 +-
Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.c | 23 ++++++
Silicon/Marvell/Armada7k8k/AcpiTables/Armada70x0Db/Dsdt.asl | 56 ++++++++++++++
Silicon/Marvell/Armada7k8k/AcpiTables/Armada80x0Db/Dsdt.asl | 59 +++++++++++++++
Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Dsdt.asl | 59 +++++++++++++++
10 files changed, 266 insertions(+), 24 deletions(-)

--
2.29.0


Re: [edk2-platforms][PATCH 0/4] Arm 32bit support in StandaloneMmRpmb

Ard Biesheuvel
 

On Mon, 10 May 2021 at 09:53, Etienne Carriere
<etienne.carriere@...> wrote:

This series brings support for building PlatformStandaloneMmRpmb for
32bit Arm architectures. This series is based on series [1] in edk2
that allows to build StandaloneMm package for 32bit Arm. This series
starts by syncing with paths changes from [1] series, then comes
changes for Arm 32bit support in OpTee drivers and last updates
PlatformStandaloneMmRpmb.dsc for 32bit the ARM architure.

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

Etienne Carriere (4):
sync with edk2 where StandaloneMmCpu moved to AArch64/ parent
directory
Drivers/OpTee: Add Aarch32 SVC IDs for 32bit Arm targets
Drivers/OpTee: address cast build warning issue in 32b mode
Platform/StandaloneMm: build StandaloneMmRpmb for 32bit architectures
This looks fine to me

Acked-by: Ard Biesheuvel <ardb@...>

I'll pick these up once the EDK2 side is merged.

Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.c | 23 ++++++++++++-------
Drivers/OpTee/OpteeRpmbPkg/OpTeeRpmbFvb.h | 16 +++++++++++--
Platform/ARM/SgiPkg/PlatformStandaloneMm.dsc | 2 +-
Platform/ARM/SgiPkg/PlatformStandaloneMm.fdf | 2 +-
.../Socionext/DeveloperBox/DeveloperBoxMm.dsc | 2 +-
.../Socionext/DeveloperBox/DeveloperBoxMm.fdf | 2 +-
.../PlatformStandaloneMmRpmb.dsc | 14 +++++++++--
.../PlatformStandaloneMmRpmb.fdf | 3 ++-
8 files changed, 47 insertions(+), 17 deletions(-)

--
2.17.1


Re: [PATCH 3/5] GenGv: Arm: support images entered in Thumb mode

Ard Biesheuvel
 

On Tue, 4 May 2021 at 17:20, Etienne Carriere
<etienne.carriere@...> wrote:

Change GenFv for Arm architecture to generate a specific jump
instruction as image entry instruction, when the target entry label
is assembled with Thumb instruction set. This is possible since
SecCoreEntryAddress value fetched from the PE32 as its LSBit set when
the entry instruction executes in Thumb mode.

Cc: Bob Feng <bob.c.feng@...>
Cc: Liming Gao <gaoliming@...>
Cc: Achin Gupta <achin.gupta@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Leif Lindholm <leif@...>
Cc: Sughosh Ganu <sughosh.ganu@...>
Signed-off-by: Etienne Carriere <etienne.carriere@...>
This looks fine to me (modulo a couple of typos: GenGv, enry) but this
needs an ack from the BaseTools maintainers.

Bob, Liming?

---
BaseTools/Source/C/GenFv/GenFvInternalLib.c | 38 +++++++++++++++-----
1 file changed, 29 insertions(+), 9 deletions(-)

diff --git a/BaseTools/Source/C/GenFv/GenFvInternalLib.c b/BaseTools/Source/C/GenFv/GenFvInternalLib.c
index 6e296b8ad6..3af65146f6 100644
--- a/BaseTools/Source/C/GenFv/GenFvInternalLib.c
+++ b/BaseTools/Source/C/GenFv/GenFvInternalLib.c
@@ -34,9 +34,27 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
#include "FvLib.h"
#include "PeCoffLib.h"

-#define ARMT_UNCONDITIONAL_JUMP_INSTRUCTION 0xEB000000
#define ARM64_UNCONDITIONAL_JUMP_INSTRUCTION 0x14000000

+/*
+ * Arm instruction to jump to Fv enry instruction in Arm or Thumb mode.
+ * From ARM Arch Ref Manual versions b/c/d, section A8.8.25 BL, BLX (immediate)
+ * BLX (encoding A2) branches to offset in Thumb instruction set mode.
+ * BL (encoding A1) branches to offset in Arm instruction set mode.
+ */
+#define ARM_JUMP_OFFSET_MAX 0xffffff
+#define ARM_JUMP_TO_ARM(Offset) (0xeb000000 | ((Offset - 8) >> 2))
+
+#define _ARM_JUMP_TO_THUMB(Imm32) (0xfa000000 | \
+ (((Imm32) & (1 << 1)) << (24 - 1)) | \
+ (((Imm32) >> 2) & 0x7fffff))
+#define ARM_JUMP_TO_THUMB(Offset) _ARM_JUMP_TO_THUMB((Offset) - 8)
+
+/*
+ * Arm instruction to retrun from exception (MOVS PC, LR)
+ */
+#define ARM_RETURN_FROM_EXCEPTION 0xE1B0F07E
+
BOOLEAN mArm = FALSE;
BOOLEAN mRiscV = FALSE;
STATIC UINT32 MaxFfsAlignment = 0;
@@ -2203,23 +2221,25 @@ Returns:
// if we found an SEC core entry point then generate a branch instruction
// to it and populate a debugger SWI entry as well
if (UpdateVectorSec) {
+ UINT32 EntryOffset;

VerboseMsg("UpdateArmResetVectorIfNeeded updating ARM SEC vector");

- // B SecEntryPoint - signed_immed_24 part +/-32MB offset
- // on ARM, the PC is always 8 ahead, so we're not really jumping from the base address, but from base address + 8
- ResetVector[0] = (INT32)(SecCoreEntryAddress - FvInfo->BaseAddress - 8) >> 2;
+ EntryOffset = (INT32)(SecCoreEntryAddress - FvInfo->BaseAddress);

- if (ResetVector[0] > 0x00FFFFFF) {
- Error(NULL, 0, 3000, "Invalid", "SEC Entry point must be within 32MB of the start of the FV");
+ if (EntryOffset > ARM_JUMP_OFFSET_MAX) {
+ Error(NULL, 0, 3000, "Invalid", "SEC Entry point offset above 1MB of the start of the FV");
return EFI_ABORTED;
}

- // Add opcode for an unconditional branch with no link. i.e.: " B SecEntryPoint"
- ResetVector[0] |= ARMT_UNCONDITIONAL_JUMP_INSTRUCTION;
+ if (SecCoreEntryAddress & 1) {
+ ResetVector[0] = ARM_JUMP_TO_THUMB(EntryOffset);
+ } else {
+ ResetVector[0] = ARM_JUMP_TO_ARM(EntryOffset);
+ }

// SWI handler movs pc,lr. Just in case a debugger uses SWI
- ResetVector[2] = 0xE1B0F07E;
+ ResetVector[2] = ARM_RETURN_FROM_EXCEPTION;

// Place holder to support a common interrupt handler from ROM.
// Currently not supported. For this to be used the reset vector would not be in this FV
--
2.17.1


Re: [PATCH 4/5] StandaloneMmPkg: fix pointer/int casts against 32bit architectures

Ard Biesheuvel
 

On Wed, 5 May 2021 at 04:10, Yao, Jiewen <jiewen.yao@...> wrote:

Acked-by: Jiewen Yao <Jiewen.yao@...>

Need ARM expert to comment if it is OK to refer AArch64 for ARM?
This looks fine to me.



-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Etienne
Carriere
Sent: Tuesday, May 4, 2021 11:21 PM
To: devel@edk2.groups.io
Cc: Achin Gupta <achin.gupta@...>; Ard Biesheuvel
<ardb+tianocore@...>; Yao, Jiewen <jiewen.yao@...>; Leif
Lindholm <leif@...>; Sami Mujawar <sami.mujawar@...>;
Sughosh Ganu <sughosh.ganu@...>; Etienne Carriere
<etienne.carriere@...>
Subject: [edk2-devel] [PATCH 4/5] StandaloneMmPkg: fix pointer/int casts
against 32bit architectures

Use intermediate (UINTN) cast when casting int from/to pointer. This
is needed as UINT64 values cast from/to 32bit pointer for 32bit
architectures.

Cc: Achin Gupta <achin.gupta@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>
Cc: Jiewen Yao <jiewen.yao@...>
Cc: Leif Lindholm <leif@...>
Cc: Sami Mujawar <sami.mujawar@...>
Cc: Sughosh Ganu <sughosh.ganu@...>
Signed-off-by: Etienne Carriere <etienne.carriere@...>
---
StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.c
| 8 ++++----

StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/CreateHobL
ist.c | 14 +++++++-------

StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/Standalone
MmCoreEntryPoint.c | 2 +-
3 files changed, 12 insertions(+), 12 deletions(-)

diff --git
a/StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.c
b/StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.c
index 6884095c49..d4590bcd19 100644
---
a/StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.c
+++
b/StandaloneMmPkg/Drivers/StandaloneMmCpu/AArch64/StandaloneMmCpu.c
@@ -164,8 +164,8 @@ StandaloneMmCpuInitialize (

// Share the entry point of the CPU driver
DEBUG ((DEBUG_INFO, "Sharing Cpu Driver EP *0x%lx = 0x%lx\n",
- (UINT64) CpuDriverEntryPointDesc->ArmTfCpuDriverEpPtr,
- (UINT64) PiMmStandaloneArmTfCpuDriverEntry));
+ (UINTN) CpuDriverEntryPointDesc->ArmTfCpuDriverEpPtr,
+ (UINTN) PiMmStandaloneArmTfCpuDriverEntry));
*(CpuDriverEntryPointDesc->ArmTfCpuDriverEpPtr) =
PiMmStandaloneArmTfCpuDriverEntry;

// Find the descriptor that contains the whereabouts of the buffer for
@@ -180,8 +180,8 @@ StandaloneMmCpuInitialize (
return Status;
}

- DEBUG ((DEBUG_INFO, "mNsCommBuffer.PhysicalStart - 0x%lx\n", (UINT64)
NsCommBufMmramRange->PhysicalStart));
- DEBUG ((DEBUG_INFO, "mNsCommBuffer.PhysicalSize - 0x%lx\n", (UINT64)
NsCommBufMmramRange->PhysicalSize));
+ DEBUG ((DEBUG_INFO, "mNsCommBuffer.PhysicalStart - 0x%lx\n", (UINTN)
NsCommBufMmramRange->PhysicalStart));
+ DEBUG ((DEBUG_INFO, "mNsCommBuffer.PhysicalSize - 0x%lx\n", (UINTN)
NsCommBufMmramRange->PhysicalSize));

CopyMem (&mNsCommBuffer, NsCommBufMmramRange,
sizeof(EFI_MMRAM_DESCRIPTOR));
DEBUG ((DEBUG_INFO, "mNsCommBuffer: 0x%016lx - 0x%lx\n",
mNsCommBuffer.CpuStart, mNsCommBuffer.PhysicalSize));
diff --git
a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/CreateHo
bList.c
b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/CreateHo
bList.c
index e8fb96bd6e..4d4cf3d5ff 100644
---
a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/CreateHo
bList.c
+++
b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/CreateHo
bList.c
@@ -72,14 +72,14 @@ CreateHobListFromBootInfo (

// Create a hoblist with a PHIT and EOH
HobStart = HobConstructor (
- (VOID *) PayloadBootInfo->SpMemBase,
+ (VOID *) (UINTN) PayloadBootInfo->SpMemBase,
(UINTN) PayloadBootInfo->SpMemLimit - PayloadBootInfo-
SpMemBase,
- (VOID *) PayloadBootInfo->SpHeapBase,
- (VOID *) (PayloadBootInfo->SpHeapBase + PayloadBootInfo-
SpHeapSize)
+ (VOID *) (UINTN) PayloadBootInfo->SpHeapBase,
+ (VOID *) (UINTN) (PayloadBootInfo->SpHeapBase + PayloadBootInfo-
SpHeapSize)
);

// Check that the Hoblist starts at the bottom of the Heap
- ASSERT (HobStart == (VOID *) PayloadBootInfo->SpHeapBase);
+ ASSERT (HobStart == (VOID *) (UINTN) PayloadBootInfo->SpHeapBase);

// Build a Boot Firmware Volume HOB
BuildFvHob (PayloadBootInfo->SpImageBase, PayloadBootInfo->SpImageSize);
@@ -190,9 +190,9 @@ CreateHobListFromBootInfo (
MmramRanges[3].RegionState = EFI_CACHEABLE | EFI_ALLOCATED;

// Base and size of heap memory shared by all cpus
- MmramRanges[4].PhysicalStart = (EFI_PHYSICAL_ADDRESS) HobStart;
- MmramRanges[4].CpuStart = (EFI_PHYSICAL_ADDRESS) HobStart;
- MmramRanges[4].PhysicalSize = HobStart->EfiFreeMemoryBottom -
(EFI_PHYSICAL_ADDRESS) HobStart;
+ MmramRanges[4].PhysicalStart = (EFI_PHYSICAL_ADDRESS) (UINTN) HobStart;
+ MmramRanges[4].CpuStart = (EFI_PHYSICAL_ADDRESS) (UINTN) HobStart;
+ MmramRanges[4].PhysicalSize = HobStart->EfiFreeMemoryBottom -
(EFI_PHYSICAL_ADDRESS) (UINTN) HobStart;
MmramRanges[4].RegionState = EFI_CACHEABLE | EFI_ALLOCATED;

// Base and size of heap memory shared by all cpus
diff --git
a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/Standalon
eMmCoreEntryPoint.c
b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/Standalon
eMmCoreEntryPoint.c
index 6c50f470aa..b445d6942e 100644
---
a/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/Standalon
eMmCoreEntryPoint.c
+++
b/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/Standalon
eMmCoreEntryPoint.c
@@ -328,7 +328,7 @@ _ModuleEntryPoint (

// Locate PE/COFF File information for the Standalone MM core module
Status = LocateStandaloneMmCorePeCoffData (
- (EFI_FIRMWARE_VOLUME_HEADER *) PayloadBootInfo->SpImageBase,
+ (EFI_FIRMWARE_VOLUME_HEADER *) (UINTN) PayloadBootInfo-
SpImageBase,
&TeData,
&TeDataSize
);
--
2.17.1





Re: [PATCH RESEND v1 1/1] ArmPkg: Update SCMI Base Protocol version to 0x20000

Ard Biesheuvel
 

On Mon, 10 May 2021 at 10:51, Sami Mujawar <Sami.Mujawar@...> wrote:

Hi All,

I have tested this patch on Juno R2.

Tested-by: Sami Mujawar <sami.mujawar@...>
Reviewed-by: Sami Mujawar <sami.mujawar@...>
Merged as #1630

Thanks all.




On 10/05/2021, 09:26, "Pierre.Gondois@..." <Pierre.Gondois@...> wrote:

From: Nicola Mazzucato <nicola.mazzucato@...>

The SCP-firmware has moved to full support for SCMIv2 which means that
the base protocol can be either compliant with SCMI v1 or v2.

Allow any version between SCMI v1.0 and SCMI v2.0 to be compatible
with the current implementation.

Signed-off-by: Nicola Mazzucato <nicola.mazzucato@...>
Signed-off-by: Pierre Gondois <Pierre.Gondois@...>
---
The changes can be seen at: https://github.com/PierreARM/edk2/tree/1732_Update_SCMI_version_v1

ArmPkg/Drivers/ArmScmiDxe/ScmiDxe.c | 10 ++++++----
ArmPkg/Include/Protocol/ArmScmiBaseProtocol.h | 10 +++++-----
2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/ArmPkg/Drivers/ArmScmiDxe/ScmiDxe.c b/ArmPkg/Drivers/ArmScmiDxe/ScmiDxe.c
index d5890a7633a2..fb4e79aa3610 100644
--- a/ArmPkg/Drivers/ArmScmiDxe/ScmiDxe.c
+++ b/ArmPkg/Drivers/ArmScmiDxe/ScmiDxe.c
@@ -4,9 +4,9 @@

SPDX-License-Identifier: BSD-2-Clause-Patent

- System Control and Management Interface V1.0
- http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/
- DEN0056A_System_Control_and_Management_Interface.pdf
+ @par Specification Reference:
+ - Arm System Control and Management Interface - Platform Design Document
+ (https://developer.arm.com/documentation/den0056/)
**/

#include <Base.h>
@@ -86,7 +86,9 @@ ArmScmiDxeEntryPoint (
return Status;
}

- if (Version != BASE_PROTOCOL_VERSION) {
+ // Accept any version between SCMI v1.0 and SCMI v2.0
+ if ((Version < BASE_PROTOCOL_VERSION_V1) ||
+ (Version > BASE_PROTOCOL_VERSION_V2)) {
ASSERT (FALSE);
return EFI_UNSUPPORTED;
}
diff --git a/ArmPkg/Include/Protocol/ArmScmiBaseProtocol.h b/ArmPkg/Include/Protocol/ArmScmiBaseProtocol.h
index 73ad3e32a2f5..c4b81c0f56d3 100644
--- a/ArmPkg/Include/Protocol/ArmScmiBaseProtocol.h
+++ b/ArmPkg/Include/Protocol/ArmScmiBaseProtocol.h
@@ -4,9 +4,9 @@

SPDX-License-Identifier: BSD-2-Clause-Patent

- System Control and Management Interface V1.0
- http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/
- DEN0056A_System_Control_and_Management_Interface.pdf
+ @par Specification Reference:
+ - Arm System Control and Management Interface - Platform Design Document
+ (https://developer.arm.com/documentation/den0056/)
**/

#ifndef ARM_SCMI_BASE_PROTOCOL_H_
@@ -14,7 +14,8 @@

#include <Protocol/ArmScmi.h>

-#define BASE_PROTOCOL_VERSION 0x10000
+#define BASE_PROTOCOL_VERSION_V1 0x10000
+#define BASE_PROTOCOL_VERSION_V2 0x20000

#define NUM_PROTOCOL_MASK 0xFFU
#define NUM_AGENT_MASK 0xFFU
@@ -165,4 +166,3 @@ typedef enum {
} SCMI_MESSAGE_ID_BASE;

#endif /* ARM_SCMI_BASE_PROTOCOL_H_ */
-
--
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.


Re: [PATCH 1/1] Platform/RaspberryPi: Update ACPI table revision

Ard Biesheuvel
 

On Mon, 10 May 2021 at 13:13, Pete Batard <pete@...> wrote:

On 2021.05.10 10:08, Sunny Wang wrote:
As per ACPI 6.3 specification, the DSDT/SSDT table should use revision 2
, so update the revision numbers to 2.
This also fixes https://github.com/pftf/RPi4/issues/94 (FWTS failures).

Testing Done:
- Booted to UEFI Shell and used apciview command to check all ACPI
tables' revision.
- Ran FWTS test and no longer see the ACPI DSDT and SSDT revision
failures. Note that the XSDT revision failure is caused by the FWTS
tool's issue that got fixed in
commit c522bfedc9839a474b8d590ba36bec77436d2e90

Cc: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@...>
Cc: Jeremy Linton <jeremy.linton@...>
Cc: Sami Mujawar <sami.mujawar@...>
Cc: Pete Batard <pete@...>
Cc: Ard Biesheuvel <ardb+tianocore@...>
Signed-off-by: Sunny Wang <sunny.wang@...>
---
Platform/RaspberryPi/AcpiTables/Dsdt.asl | 3 ++-
Platform/RaspberryPi/AcpiTables/Emmc.asl | 4 ++--
Platform/RaspberryPi/AcpiTables/SsdtThermal.asl | 4 ++--
3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
index d116f965e1..54fa3eca7b 100644
--- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
+++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
@@ -5,6 +5,7 @@
* Copyright (c) 2020, Pete Batard <pete@...>
* Copyright (c) 2018-2020, Andrey Warkentin <andrey.warkentin@...>
* Copyright (c) Microsoft Corporation. All rights reserved.
+ * Copyright (c) 2021, ARM Limited. All rights reserved.
*
* SPDX-License-Identifier: BSD-2-Clause-Patent
*
@@ -58,7 +59,7 @@
Store (Length, LE ## Index) \
Add (MI ## Index, LE ## Index - 1, MA ## Index)

-DefinitionBlock ("Dsdt.aml", "DSDT", 5, "RPIFDN", "RPI", 2)
+DefinitionBlock ("Dsdt.aml", "DSDT", 2, "RPIFDN", "RPI", 2)
{
Scope (\_SB_)
{
diff --git a/Platform/RaspberryPi/AcpiTables/Emmc.asl b/Platform/RaspberryPi/AcpiTables/Emmc.asl
index 179dd3ecdb..88811eb354 100644
--- a/Platform/RaspberryPi/AcpiTables/Emmc.asl
+++ b/Platform/RaspberryPi/AcpiTables/Emmc.asl
@@ -1,6 +1,6 @@
/** @file
*
- * Copyright (c) 2021 Arm. All rights reserved.
+ * Copyright (c) 2021, ARM Limited. All rights reserved.
*
* SPDX-License-Identifier: BSD-2-Clause-Patent
*
@@ -11,7 +11,7 @@

#include "AcpiTables.h"

-DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN", "RPI4EMMC", 2)
+DefinitionBlock (__FILE__, "SSDT", 2, "RPIFDN", "RPI4EMMC", 2)
{
Scope (\_SB_)
{
diff --git a/Platform/RaspberryPi/AcpiTables/SsdtThermal.asl b/Platform/RaspberryPi/AcpiTables/SsdtThermal.asl
index acfa4699bb..e82f55bebd 100644
--- a/Platform/RaspberryPi/AcpiTables/SsdtThermal.asl
+++ b/Platform/RaspberryPi/AcpiTables/SsdtThermal.asl
@@ -2,7 +2,7 @@
*
* Secondary System Description Table (SSDT) for active (fan) cooling
*
- * Copyright (c) 2020, Arm Ltd. All rights reserved.
+ * Copyright (c) 2020 - 2021, ARM Limited. All rights reserved.
*
* SPDX-License-Identifier: BSD-2-Clause-Patent
*
@@ -14,7 +14,7 @@

#include <IndustryStandard/Acpi.h>

-DefinitionBlock (__FILE__, "SSDT", 5, "RPIFDN", "RPITHFAN", 2)
+DefinitionBlock (__FILE__, "SSDT", 2, "RPIFDN", "RPITHFAN", 2)
{
External (\_SB_.EC00, DeviceObj)
External (\_SB_.EC00.TZ00, DeviceObj)
Reviewed-by: Pete Batard <pete@...>
Tested-by: Pete Batard <pete@...> (Windows 10 boot)
Thanks all.

Pushed as

a996c765008d..7661dfff1528

(I added a preceding patch to change the line endings of
SsdtThermal.asl to CR/LF, or the patch wouldn't apply)


[PATCH] UefiCpuPkg/MpInitLib: Properly cast from PCD to SEV-ES jump table pointer

Lendacky, Thomas
 

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

A VS2012 build fails with a cast conversion warning when the SEV-ES work
area PCD is cast as a pointer to the SEV_ES_AP_JMP_FAR type.

When casting from a PCD value to a pointer, the cast should first be done
to a UINTN and then to the pointer. Update the code to perform a cast to
a UINTN before casting to a pointer to the SEV_ES_AP_JMP_FAR type.

Cc: Eric Dong <eric.dong@...>
Cc: Ray Ni <ray.ni@...>
Cc: Laszlo Ersek <lersek@...>
Cc: Rahul Kumar <rahul1.kumar@...>
Signed-off-by: Tom Lendacky <thomas.lendacky@...>
---
UefiCpuPkg/Library/MpInitLib/MpLib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c b/UefiCpuPkg/Library/MpInitLib/MpLib.c
index 3d945972a025..dc2a54aa31e8 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
@@ -1265,7 +1265,7 @@ SetSevEsJumpTable (
UINT32 Offset, InsnByte;
UINT8 LoNib, HiNib;

- JmpFar = (SEV_ES_AP_JMP_FAR *) FixedPcdGet32 (PcdSevEsWorkAreaBase);
+ JmpFar = (SEV_ES_AP_JMP_FAR *) (UINTN) FixedPcdGet32 (PcdSevEsWorkAreaBase);
ASSERT (JmpFar != NULL);

//
--
2.31.0


Re: Build fails with VS2012

Rebecca Cran <rebecca@...>
 

On 5/10/21 5:56 AM, Laszlo Ersek wrote:
Hi Rebecca
+Tom
On 05/08/21 21:47, Rebecca Cran wrote:
I'm setting up a new Jenkins server to do Bhyve builds and run on
platforms that aren't currently tested with the GitHub/Azure system.

Since VS2012 appears to be a supported toolchain, I tried building
OvmfPkgX64 with it (I'm also planning on testing VS2013, VS2015, VS2017
and VS2019), but it fails with:


Building ...
c:\users\administrator\src\edk2\NetworkPkg\Library\DxeUdpIoLib\DxeUdpIoLib.inf
[X64]
c:\users\administrator\src\edk2\UefiCpuPkg\Library\MpInitLib\MpLib.c(1268)
: error C2220: warning treated as error - no 'object' file generated
c:\users\administrator\src\edk2\UefiCpuPkg\Library\MpInitLib\MpLib.c(1268)
: warning C4306: 'type cast' : conversion from 'int' to
'SEV_ES_AP_JMP_FAR *' of greater size
I think the compiler is justified to complain here:
7b7508ad784d1 (Tom Lendacky 2020-08-12 15:21:42 -0500 1268) JmpFar = (SEV_ES_AP_JMP_FAR *) FixedPcdGet32 (PcdSevEsWorkAreaBase);
The proper way to spell such casts is with (UINTN) in the middle.
Can you please file a new BZ?
I've created https://bugzilla.tianocore.org/show_bug.cgi?id=3385

I know the GitHub/Azure system only tests with VS2017 and VS2019: are
there plans to drop the older VS versions, or should they still work?
And would it be considered useful to _check_ that they still work, or
should they be considered unsupported?
I'd suggest dropping them.
Earlier, Ard raised a similar question for gcc too -- IIRC, Ard suggested that GCC4* be removed. I agree with the idea.
Thanks. If we're ready to go ahead, should I create a patch to remove them?

Do you know what the new minimum version of gcc should then be? I'd like to run builds with it so we can catch any issues.

Would we remove all VS versions except VS2017 and VS2019, or would we keep others like VS2015 for now?

--
Rebecca Cran


Re: Build fails with VS2012

Laszlo Ersek
 

On 05/09/21 19:42, Rebecca Cran wrote:
Similarly the build is also failing with GCC49, using gcc 4.9.2:

/edk2/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c: In
function 'ShellSortFileList':
Building ...
/edk2/OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf [X64]
/edk2/ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.c:2202:19: error:
'Dupes' may be used uninitialized in this function
[-Werror=maybe-uninitialized]
       *Duplicates = Dupes;
                   ^

This was reported earlier in:

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

and Sergei proposed a patch for nulling "Dupes" (among other things) in
an attachment on that BZ.

See my feedback in <https://bugzilla.tianocore.org/show_bug.cgi?id=3228#c6>.

Thanks
Laszlo