Date   

[edk2-platforms][PATCH V3 05/14] Platform/Sgi: ACPI PPTT table for RD-N1-Edge platform

Pranav Madhu
 

The RD-N1-Edge platform includes two clusters with four single-thread
CPUS. Each of the CPUs include 64KB L1 Data cache, 64KB L1 Instruction
cache and 512KB L2 cache. Each cluster includes a 2MB L3 cache. The
platform also includes a system level cache of 8MB. Add PPTT table for
RD-N1-Edge platform with this information.

Signed-off-by: Pranav Madhu <pranav.madhu@arm.com>
---
Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf | 3 +-
Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Pptt.aslc | 186 ++++++++++++=
++++++++
2 files changed, 188 insertions(+), 1 deletion(-)

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf b/Plat=
form/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf
index 22e33239070b..eecb64186473 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf
@@ -1,7 +1,7 @@
## @file
# ACPI table data and ASL sources required to boot the platform.
#
-# Copyright (c) 2018-2020, ARM Ltd. All rights reserved.
+# Copyright (c) 2018-2021, ARM Ltd. All rights reserved.
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -23,6 +23,7 @@
Mcfg.aslc
RdN1Edge/Dsdt.asl
RdN1Edge/Madt.aslc
+ RdN1Edge/Pptt.aslc
Spcr.aslc
Ssdt.asl
=20
diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Pptt.aslc b/Platform=
/ARM/SgiPkg/AcpiTables/RdN1Edge/Pptt.aslc
new file mode 100644
index 000000000000..028efa908c54
--- /dev/null
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Pptt.aslc
@@ -0,0 +1,186 @@
+/** @file
+* Processor Properties Topology Table (PPTT) for RD-N1-Edge single-chip =
platform
+*
+* This file describes the topological structure of the processor block o=
n the
+* RD-N1-Edge single-chip platform in the form as defined by ACPI PPTT ta=
ble. The
+* RD-N1-Edge platform includes two clusters with four single-thread CPUS=
. Each
+* of the CPUs include 64KB L1 Data cache, 64KB L1 Instruction cache and =
512KB L2
+* cache. Each cluster includes a 2MB L3 cache. The platform also include=
s a
+* system level cache of 8MB.
+*
+* Copyright (c) 2021, ARM Limited. All rights reserved.
+*
+* SPDX-License-Identifier: BSD-2-Clause-Patent
+*
+* @par Specification Reference:
+* - ACPI 6.3, Chapter 5, Section 5.2.29, Processor Properties Topology=
Table
+**/
+
+#include <IndustryStandard/Acpi.h>
+#include <Library/AcpiLib.h>
+#include <Library/ArmLib.h>
+#include <Library/PcdLib.h>
+
+#include "SgiPlatform.h"
+#include "SgiAcpiHeader.h"
+
+/*!
+ \brief Define helper macro for populating processor core information.
+ \param PackageId Package instance number.
+ \param ClusterId Cluster instance number.
+ \param CpuId CPU instance number.
+*/
+#define PPTT_CORE_INIT(PackageId, ClusterId, CpuId) =
\
+ { =
\
+ /* Parameters for CPU Core */ =
\
+ EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR_INIT ( =
\
+ OFFSET_OF (RD_PPTT_CORE, DCache), /* Length */ =
\
+ PPTT_PROCESSOR_CORE_FLAGS, /* Flag */ =
\
+ OFFSET_OF (EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE, =
\
+ Package.Cluster[ClusterId]), /* Parent */ =
\
+ ((PackageId << 3) | (ClusterId << 2) | CpuId), /* ACPI Id */ =
\
+ 2 /* Num of private resource *=
/ \
+ ), =
\
+ =
\
+ /* Offsets of the private resources */ =
\
+ { =
\
+ OFFSET_OF (EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE, =
\
+ Package.Cluster[ClusterId].Core[CpuId].DCache), =
\
+ OFFSET_OF (EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE, =
\
+ Package.Cluster[ClusterId].Core[CpuId].ICache) =
\
+ }, =
\
+ =
\
+ /* L1 data cache parameters */ =
\
+ EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE_INIT ( =
\
+ PPTT_CACHE_STRUCTURE_FLAGS, /* Flag */ =
\
+ OFFSET_OF (EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE, =
\
+ Package.Cluster[ClusterId].Core[CpuId].L2Cache), =
\
+ /* Next level of cache */ =
\
+ SIZE_64KB, /* Size */ =
\
+ 256, /* Num of sets */ =
\
+ 4, /* Associativity */ =
\
+ PPTT_DATA_CACHE_ATTR, /* Attributes */ =
\
+ 64 /* Line size */ =
\
+ ), =
\
+ =
\
+ /* L1 instruction cache parameters */ =
\
+ EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE_INIT ( =
\
+ PPTT_CACHE_STRUCTURE_FLAGS, /* Flag */ =
\
+ OFFSET_OF (EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE, =
\
+ Package.Cluster[ClusterId].Core[CpuId].L2Cache), =
\
+ /* Next level of cache */ =
\
+ SIZE_64KB, /* Size */ =
\
+ 256, /* Num of sets */ =
\
+ 4, /* Associativity */ =
\
+ PPTT_INST_CACHE_ATTR, /* Attributes */ =
\
+ 64 /* Line size */ =
\
+ ), =
\
+ =
\
+ /* L2 cache parameters */ =
\
+ EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE_INIT ( =
\
+ PPTT_CACHE_STRUCTURE_FLAGS, /* Flag */ =
\
+ 0, /* Next level of cache */ =
\
+ SIZE_512KB, /* Size */ =
\
+ 1024, /* Num of sets */ =
\
+ 8, /* Associativity */ =
\
+ PPTT_UNIFIED_CACHE_ATTR, /* Attributes */ =
\
+ 64 /* Line size */ =
\
+ ), =
\
+ }
+
+/*!
+ \brief Define helper macro for populating processor container informa=
tion.
+ \param PackageId Package instance number.
+ \param ClusterId Cluster instance number.
+*/
+#define PPTT_CLUSTER_INIT(PackageId, ClusterId) =
\
+ { =
\
+ /* Parameters for Cluster */ =
\
+ EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR_INIT ( =
\
+ OFFSET_OF (RD_PPTT_CLUSTER, L3Cache), /* Length */ =
\
+ PPTT_PROCESSOR_CLUSTER_FLAGS, /* Flag */ =
\
+ OFFSET_OF (EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE, =
\
+ Package), /* Parent */ =
\
+ ((PackageId << 1) | ClusterId), /* ACPI Id */ =
\
+ 1 /* Num of private resource *=
/ \
+ ), =
\
+ =
\
+ /* Offsets of the private resources */ =
\
+ OFFSET_OF (EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE, =
\
+ Package.Cluster[ClusterId].L3Cache), =
\
+ =
\
+ /* L3 cache parameters */ =
\
+ EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE_INIT ( =
\
+ PPTT_CACHE_STRUCTURE_FLAGS, /* Flag */ =
\
+ 0, /* Next level of cache */ =
\
+ SIZE_2MB, /* Size */ =
\
+ 2048, /* Num of sets */ =
\
+ 16, /* Associativity */ =
\
+ PPTT_UNIFIED_CACHE_ATTR, /* Attributes */ =
\
+ 64 /* Line size */ =
\
+ ), =
\
+ =
\
+ /* Initialize child cores */ =
\
+ { =
\
+ PPTT_CORE_INIT (PackageId, ClusterId, 0), =
\
+ PPTT_CORE_INIT (PackageId, ClusterId, 1), =
\
+ PPTT_CORE_INIT (PackageId, ClusterId, 2), =
\
+ PPTT_CORE_INIT (PackageId, ClusterId, 3) =
\
+ } =
\
+ }
+
+#pragma pack(1)
+typedef struct {
+ EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR Package;
+ UINT32 Offset;
+ EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE Slc;
+ RD_PPTT_CLUSTER Cluster[CLUSTER_COUNT];
+} RDN1EDGE_PPTT_PACKAGE ;
+
+/*
+ * Processor Properties Topology Table
+ */
+typedef struct {
+ EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE_HEADER Header;
+ RDN1EDGE_PPTT_PACKAGE Package;
+} EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE;
+#pragma pack ()
+
+STATIC EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE Pptt =3D {
+ {
+ ARM_ACPI_HEADER (
+ EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE_STRUCTURE_SIGNATU=
RE,
+ EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE,
+ EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE_REVISION
+ )
+ },
+
+ {
+ EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR_INIT (
+ OFFSET_OF (RDN1EDGE_PPTT_PACKAGE , Slc),
+ PPTT_PROCESSOR_PACKAGE_FLAGS, 0, 0, 1),
+
+ OFFSET_OF (EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE,
+ Package.Slc),
+
+ EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE_INIT (
+ PPTT_CACHE_STRUCTURE_FLAGS, /* Flag */
+ 0, /* Next level of cache */
+ SIZE_8MB, /* Size */
+ 8192, /* Num of sets */
+ 16, /* Associativity */
+ PPTT_UNIFIED_CACHE_ATTR, /* Attributes */
+ 64 /* Line size */
+ ),
+ {
+ PPTT_CLUSTER_INIT (0, 0),
+ PPTT_CLUSTER_INIT (0, 1),
+ }
+ }
+};
+
+/*
+ * Reference the table being generated to prevent the optimizer from rem=
oving
+ * the data structure from the executable
+ */
+VOID* CONST ReferenceAcpiTable =3D &Pptt;
--=20
2.17.1


[edk2-platforms][PATCH V3 04/14] Platform/Sgi: Add CPU container for RD-N1-Edge

Pranav Madhu
 

The RD-N1-Edge platform includes two clusters with four single-thread
CPUs. Add processor container devices for the two clusters on the
RD-N1-Edge platform and move the existing processor devices into
respective processor containers.

Signed-off-by: Pranav Madhu <pranav.madhu@arm.com>
---
Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl | 88 +++++++++++-------=
--
1 file changed, 48 insertions(+), 40 deletions(-)

diff --git a/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl b/Platform/=
ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl
index d9bac33898b1..b88344c3a7ba 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl
+++ b/Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl
@@ -13,54 +13,62 @@
DefinitionBlock ("DsdtTable.aml", "DSDT", 2, "ARMLTD", "ARMSGI",
EFI_ACPI_ARM_OEM_REVISION) {
Scope (_SB) {
-
- Device (CP00) { // Neoverse-N1: Cluster 0, Cpu 0
- Name (_HID, "ACPI0007")
+ Device (CLU0) { // Cluster 0
+ Name (_HID, "ACPI0010")
Name (_UID, 0)
- Name (_STA, 0xF)
+
+ Device (CP00) { // Neoverse-N1: Cluster 0, Cpu 0
+ Name (_HID, "ACPI0007")
+ Name (_UID, 0)
+ Name (_STA, 0xF)
+ }
+
+ Device (CP01) { // Neoverse-N1: Cluster 0, Cpu 1
+ Name (_HID, "ACPI0007")
+ Name (_UID, 1)
+ Name (_STA, 0xF)
+ }
+
+ Device (CP02) { // Neoverse-N1: Cluster 0, Cpu 2
+ Name (_HID, "ACPI0007")
+ Name (_UID, 2)
+ Name (_STA, 0xF)
+ }
+
+ Device (CP03) { // Neoverse-N1: Cluster 0, Cpu 3
+ Name (_HID, "ACPI0007")
+ Name (_UID, 3)
+ Name (_STA, 0xF)
+ }
}
=20
- Device (CP01) { // Neoverse-N1: Cluster 0, Cpu 1
- Name (_HID, "ACPI0007")
+ Device (CLU1) { // Cluster 1
+ Name (_HID, "ACPI0010")
Name (_UID, 1)
- Name (_STA, 0xF)
- }
=20
- Device (CP02) { // Neoverse-N1: Cluster 0, Cpu 2
- Name (_HID, "ACPI0007")
- Name (_UID, 2)
- Name (_STA, 0xF)
- }
+ Device (CP04) { // Neoverse-N1: Cluster 1, Cpu 0
+ Name (_HID, "ACPI0007")
+ Name (_UID, 4)
+ Name (_STA, 0xF)
+ }
=20
- Device (CP03) { // Neoverse-N1: Cluster 0, Cpu 3
- Name (_HID, "ACPI0007")
- Name (_UID, 3)
- Name (_STA, 0xF)
- }
+ Device (CP05) { // Neoverse-N1: Cluster 1, Cpu 1
+ Name (_HID, "ACPI0007")
+ Name (_UID, 5)
+ Name (_STA, 0xF)
+ }
=20
- Device (CP04) { // Neoverse-N1: Cluster 1, Cpu 0
- Name (_HID, "ACPI0007")
- Name (_UID, 4)
- Name (_STA, 0xF)
- }
+ Device (CP06) { // Neoverse-N1: Cluster 1, Cpu 2
+ Name (_HID, "ACPI0007")
+ Name (_UID, 6)
+ Name (_STA, 0xF)
+ }
=20
- Device (CP05) { // Neoverse-N1: Cluster 1, Cpu 1
- Name (_HID, "ACPI0007")
- Name (_UID, 5)
- Name (_STA, 0xF)
+ Device (CP07) { // Neoverse-N1: Cluster 1, Cpu 3
+ Name (_HID, "ACPI0007")
+ Name (_UID, 7)
+ Name (_STA, 0xF)
+ }
}
-
- Device (CP06) { // Neoverse-N1: Cluster 1, Cpu 2
- Name (_HID, "ACPI0007")
- Name (_UID, 6)
- Name (_STA, 0xF)
- }
-
- Device (CP07) { // Neoverse-N1: Cluster 1, Cpu 3
- Name (_HID, "ACPI0007")
- Name (_UID, 7)
- Name (_STA, 0xF)
- }
-
} // Scope(_SB)
}
--=20
2.17.1


[edk2-platforms][PATCH V3 03/14] Platform/Sgi: ACPI PPTT table for SGI-575 platform

Pranav Madhu
 

The SGI-575 platform includes two clusters with four single-thread CPUs.
Each of the CPUs include 64KB L1 Data cache, 64KB L1 Instruction cache
and 512KB L2 cache. Each cluster includes a 2MB L3 cache. Add PPTT table
for SGI-575 platform with this information.

Signed-off-by: Pranav Madhu <pranav.madhu@arm.com>
---
Platform/ARM/SgiPkg/AcpiTables/Sgi575AcpiTables.inf | 3 +-
Platform/ARM/SgiPkg/AcpiTables/Sgi575/Pptt.aslc | 172 ++++++++++++++=
++++++
2 files changed, 174 insertions(+), 1 deletion(-)

diff --git a/Platform/ARM/SgiPkg/AcpiTables/Sgi575AcpiTables.inf b/Platfo=
rm/ARM/SgiPkg/AcpiTables/Sgi575AcpiTables.inf
index 2121fd39f2f0..b1ee16e98ea3 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/Sgi575AcpiTables.inf
+++ b/Platform/ARM/SgiPkg/AcpiTables/Sgi575AcpiTables.inf
@@ -1,7 +1,7 @@
## @file
# ACPI table data and ASL sources required to boot the platform.
#
-# Copyright (c) 2018, ARM Ltd. All rights reserved.
+# Copyright (c) 2018 - 2021, ARM Ltd. All rights reserved.
#
# SPDX-License-Identifier: BSD-2-Clause-Patent
#
@@ -22,6 +22,7 @@
Mcfg.aslc
Sgi575/Dsdt.asl
Sgi575/Madt.aslc
+ Sgi575/Pptt.aslc
Spcr.aslc
Ssdt.asl
=20
diff --git a/Platform/ARM/SgiPkg/AcpiTables/Sgi575/Pptt.aslc b/Platform/A=
RM/SgiPkg/AcpiTables/Sgi575/Pptt.aslc
new file mode 100644
index 000000000000..f3032b7e4cdc
--- /dev/null
+++ b/Platform/ARM/SgiPkg/AcpiTables/Sgi575/Pptt.aslc
@@ -0,0 +1,172 @@
+/** @file
+* Processor Properties Topology Table (PPTT) for SGI-575 platform
+*
+* This file describes the topological structure of the processor block o=
n the
+* SGI-575 platform in the form as defined by ACPI PPTT table. The SGI-57=
5
+* platform includes two clusters with four single-thread CPUS. Each of t=
he CPUs
+* include 64KB L1 Data cache, 64KB L1 Instruction cache and 512KB L2 cac=
he.
+* Each cluster includes a 2MB L3 cache.
+*
+* Copyright (c) 2021, ARM Limited. All rights reserved.
+*
+* SPDX-License-Identifier: BSD-2-Clause-Patent
+*
+* @par Specification Reference:
+* - ACPI 6.3, Chapter 5, Section 5.2.29, Processor Properties Topology=
Table
+**/
+
+#include <IndustryStandard/Acpi.h>
+#include <Library/AcpiLib.h>
+#include <Library/ArmLib.h>
+#include <Library/PcdLib.h>
+
+#include "SgiPlatform.h"
+#include "SgiAcpiHeader.h"
+
+/*!
+ \brief Define helper macro for populating processor core information.
+ \param PackageId Package instance number.
+ \param ClusterId Cluster instance number.
+ \param CpuId CPU instance number.
+*/
+#define PPTT_CORE_INIT(PackageId, ClusterId, CpuId) =
\
+ { =
\
+ /* Parameters for CPU Core */ =
\
+ EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR_INIT ( =
\
+ OFFSET_OF (RD_PPTT_CORE, DCache), /* Length */ =
\
+ PPTT_PROCESSOR_CORE_FLAGS, /* Flag */ =
\
+ OFFSET_OF (EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE, =
\
+ Package.Cluster[ClusterId]), /* Parent */ =
\
+ ((PackageId << 3) | (ClusterId << 2) | CpuId), /* ACPI Id */ =
\
+ 2 /* Num of private resource *=
/ \
+ ), =
\
+ =
\
+ /* Offsets of the private resources */ =
\
+ { =
\
+ OFFSET_OF (EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE, =
\
+ Package.Cluster[ClusterId].Core[CpuId].DCache), =
\
+ OFFSET_OF (EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE, =
\
+ Package.Cluster[ClusterId].Core[CpuId].ICache) =
\
+ }, =
\
+ =
\
+ /* L1 data cache parameters */ =
\
+ EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE_INIT ( =
\
+ PPTT_CACHE_STRUCTURE_FLAGS, /* Flag */ =
\
+ OFFSET_OF (EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE, =
\
+ Package.Cluster[ClusterId].Core[CpuId].L2Cache), =
\
+ /* Next level of cache */ =
\
+ SIZE_64KB, /* Size */ =
\
+ 64, /* Num of sets */ =
\
+ 16, /* Associativity */ =
\
+ PPTT_DATA_CACHE_ATTR, /* Attributes */ =
\
+ 64 /* Line size */ =
\
+ ), =
\
+ =
\
+ /* L1 instruction cache parameters */ =
\
+ EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE_INIT ( =
\
+ PPTT_CACHE_STRUCTURE_FLAGS, /* Flag */ =
\
+ OFFSET_OF (EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE, =
\
+ Package.Cluster[ClusterId].Core[CpuId].L2Cache), =
\
+ /* Next level of cache */ =
\
+ SIZE_64KB, /* Size */ =
\
+ 256, /* Num of sets */ =
\
+ 4, /* Associativity */ =
\
+ PPTT_INST_CACHE_ATTR, /* Attributes */ =
\
+ 64 /* Line size */ =
\
+ ), =
\
+ =
\
+ /* L2 cache parameters */ =
\
+ EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE_INIT ( =
\
+ PPTT_CACHE_STRUCTURE_FLAGS, /* Flag */ =
\
+ 0, /* Next level of cache */ =
\
+ SIZE_512KB, /* Size */ =
\
+ 1024, /* Num of sets */ =
\
+ 8, /* Associativity */ =
\
+ PPTT_UNIFIED_CACHE_ATTR, /* Attributes */ =
\
+ 64 /* Line size */ =
\
+ ), =
\
+ }
+
+/*!
+ \brief Define helper macro for populating processor container informa=
tion.
+ \param PackageId Package instance number.
+ \param ClusterId Cluster instance number.
+*/
+#define PPTT_CLUSTER_INIT(PackageId, ClusterId) =
\
+ { =
\
+ /* Parameters for Cluster */ =
\
+ EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR_INIT ( =
\
+ OFFSET_OF (RD_PPTT_CLUSTER, L3Cache), =
\
+ /* Length */ =
\
+ PPTT_PROCESSOR_CLUSTER_FLAGS, /* Flag */ =
\
+ OFFSET_OF (EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE, =
\
+ Package), /* Parent */ =
\
+ ((PackageId << 1) | ClusterId), /* ACPI Id */ =
\
+ 1 /* Num of private resource *=
/ \
+ ), =
\
+ =
\
+ /* Offsets of the private resources */ =
\
+ OFFSET_OF (EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE, =
\
+ Package.Cluster[ClusterId].L3Cache), =
\
+ =
\
+ /* L3 cache parameters */ =
\
+ EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE_INIT ( =
\
+ PPTT_CACHE_STRUCTURE_FLAGS, /* Flag */ =
\
+ 0, /* Next level of cache */ =
\
+ SIZE_2MB, /* Size */ =
\
+ 2048, /* Num of sets */ =
\
+ 16, /* Associativity */ =
\
+ PPTT_UNIFIED_CACHE_ATTR, /* Attributes */ =
\
+ 64 /* Line size */ =
\
+ ), =
\
+ =
\
+ /* Initialize child cores */ =
\
+ { =
\
+ PPTT_CORE_INIT (PackageId, ClusterId, 0), =
\
+ PPTT_CORE_INIT (PackageId, ClusterId, 1), =
\
+ PPTT_CORE_INIT (PackageId, ClusterId, 2), =
\
+ PPTT_CORE_INIT (PackageId, ClusterId, 3) =
\
+ } =
\
+ }
+
+#pragma pack(1)
+typedef struct {
+ EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR Package;
+ RD_PPTT_CLUSTER Cluster[CLUSTER_COUNT];
+} SGI575_PPTT_PACKAGE;
+
+/*
+ * Processor Properties Topology Table
+ */
+typedef struct {
+ EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE_HEADER Header;
+ SGI575_PPTT_PACKAGE Package;
+} EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE;
+#pragma pack ()
+
+STATIC EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE Pptt =3D {
+ {
+ ARM_ACPI_HEADER (
+ EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE_STRUCTURE_SIGNATU=
RE,
+ EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE,
+ EFI_ACPI_6_3_PROCESSOR_PROPERTIES_TOPOLOGY_TABLE_REVISION
+ )
+ },
+
+ {
+ EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR_INIT (
+ OFFSET_OF (SGI575_PPTT_PACKAGE, Cluster[0]),
+ PPTT_PROCESSOR_PACKAGE_FLAGS, 0, 0, 0
+ ),
+ {
+ PPTT_CLUSTER_INIT (0, 0),
+ PPTT_CLUSTER_INIT (0, 1)
+ }
+ }
+};
+
+/*
+ * Reference the table being generated to prevent the optimizer from rem=
oving
+ * the data structure from the executable
+ */
+VOID* CONST ReferenceAcpiTable =3D &Pptt;
--=20
2.17.1


[edk2-platforms][PATCH V3 02/14] Platform/Sgi: Add CPU container for SGI-575

Pranav Madhu
 

The SGI-575 platform includes two clusters with four single-thread CPUs.
Add processor container devices for the two clusters on the SGI-575
platform and move the existing processor devices into respective
processor containers.

Signed-off-by: Pranav Madhu <pranav.madhu@arm.com>
---
Platform/ARM/SgiPkg/AcpiTables/Sgi575/Dsdt.asl | 99 +++++++++++---------
1 file changed, 54 insertions(+), 45 deletions(-)

diff --git a/Platform/ARM/SgiPkg/AcpiTables/Sgi575/Dsdt.asl b/Platform/AR=
M/SgiPkg/AcpiTables/Sgi575/Dsdt.asl
index fe0b92137bde..7390849e6231 100644
--- a/Platform/ARM/SgiPkg/AcpiTables/Sgi575/Dsdt.asl
+++ b/Platform/ARM/SgiPkg/AcpiTables/Sgi575/Dsdt.asl
@@ -12,53 +12,62 @@
=20
DefinitionBlock("DsdtTable.aml", "DSDT", 2, "ARMLTD", "ARMSGI", EFI_ACPI=
_ARM_OEM_REVISION) {
Scope(_SB) {
-
- Device(CP00) { // A75-0: Cluster 0, Cpu 0
- Name(_HID, "ACPI0007")
- Name(_UID, 0)
- Name(_STA, 0xF)
- }
-
- Device(CP01) { // A75-0: Cluster 0, Cpu 1
- Name(_HID, "ACPI0007")
- Name(_UID, 1)
- Name(_STA, 0xF)
- }
-
- Device(CP02) { // A75-0: Cluster 0, Cpu 2
- Name(_HID, "ACPI0007")
- Name(_UID, 2)
- Name(_STA, 0xF)
- }
-
- Device(CP03) { // A75-0: Cluster 0, Cpu 3
- Name(_HID, "ACPI0007")
- Name(_UID, 3)
- Name(_STA, 0xF)
- }
-
- Device(CP04) { // A75-0: Cluster 1, Cpu 0
- Name(_HID, "ACPI0007")
- Name(_UID, 4)
- Name(_STA, 0xF)
- }
-
- Device(CP05) { // A75-0: Cluster 1, Cpu 1
- Name(_HID, "ACPI0007")
- Name(_UID, 5)
- Name(_STA, 0xF)
- }
-
- Device(CP06) { // A75-0: Cluster 1, Cpu 2
- Name(_HID, "ACPI0007")
- Name(_UID, 6)
- Name(_STA, 0xF)
+ Device (CLU0) { // Cluster 0
+ Name (_HID, "ACPI0010")
+ Name (_UID, 0)
+
+ Device (CP00) { // A75-0: Cluster 0, Cpu 0
+ Name (_HID, "ACPI0007")
+ Name (_UID, 0)
+ Name (_STA, 0xF)
+ }
+
+ Device (CP01) { // A75-0: Cluster 0, Cpu 1
+ Name (_HID, "ACPI0007")
+ Name (_UID, 1)
+ Name (_STA, 0xF)
+ }
+
+ Device (CP02) { // A75-0: Cluster 0, Cpu 2
+ Name (_HID, "ACPI0007")
+ Name (_UID, 2)
+ Name (_STA, 0xF)
+ }
+
+ Device (CP03) { // A75-0: Cluster 0, Cpu 3
+ Name (_HID, "ACPI0007")
+ Name (_UID, 3)
+ Name (_STA, 0xF)
+ }
}
=20
- Device(CP07) { // A75-0: Cluster 1, Cpu 3
- Name(_HID, "ACPI0007")
- Name(_UID, 7)
- Name(_STA, 0xF)
+ Device (CLU1) { // Cluster 1
+ Name (_HID, "ACPI0010")
+ Name (_UID, 1)
+
+ Device (CP04) { // A75-0: Cluster 1, Cpu 0
+ Name (_HID, "ACPI0007")
+ Name (_UID, 4)
+ Name (_STA, 0xF)
+ }
+
+ Device (CP05) { // A75-0: Cluster 1, Cpu 1
+ Name (_HID, "ACPI0007")
+ Name (_UID, 5)
+ Name (_STA, 0xF)
+ }
+
+ Device (CP06) { // A75-0: Cluster 1, Cpu 2
+ Name (_HID, "ACPI0007")
+ Name (_UID, 6)
+ Name (_STA, 0xF)
+ }
+
+ Device (CP07) { // A75-0: Cluster 1, Cpu 3
+ Name (_HID, "ACPI0007")
+ Name (_UID, 7)
+ Name (_STA, 0xF)
+ }
}
=20
// UART PL011
--=20
2.17.1


[edk2-platforms][PATCH V3 01/14] Platform/Sgi: Helper macros for PPTT Table

Pranav Madhu
 

Add helper macros for the creation for PPTT table. These macros help
with initializing processor hierarchy node structure, cache type
structure and ID structure.

Signed-off-by: Pranav Madhu <pranav.madhu@arm.com>
---
Platform/ARM/SgiPkg/Include/SgiAcpiHeader.h | 170 ++++++++++++++++++++
1 file changed, 170 insertions(+)

diff --git a/Platform/ARM/SgiPkg/Include/SgiAcpiHeader.h b/Platform/ARM/S=
giPkg/Include/SgiAcpiHeader.h
index dcb4e6c77a74..23e6ee14a761 100644
--- a/Platform/ARM/SgiPkg/Include/SgiAcpiHeader.h
+++ b/Platform/ARM/SgiPkg/Include/SgiAcpiHeader.h
@@ -20,6 +20,141 @@
#define EFI_ACPI_ARM_CREATOR_ID SIGNATURE_32('A','R','M',' ')
#define EFI_ACPI_ARM_CREATOR_REVISION 0x00000099
=20
+#define CORE_COUNT FixedPcdGet32 (PcdCoreCount)
+#define CLUSTER_COUNT FixedPcdGet32 (PcdClusterCount)
+
+#pragma pack(1)
+// PPTT processor core structure
+typedef struct {
+ EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR Core;
+ UINT32 ResourceOffset[2];
+ EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE DCache;
+ EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE ICache;
+ EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE L2Cache;
+} RD_PPTT_CORE;
+
+// PPTT processor cluster structure
+typedef struct {
+ EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR Cluster;
+ UINT32 ResourceOffset;
+ EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE L3Cache;
+ RD_PPTT_CORE Core[CORE_COUNT];
+} RD_PPTT_CLUSTER;
+
+// PPTT processor cluster structure without cache
+typedef struct {
+ EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR Cluster;
+ RD_PPTT_CORE Core[CORE_COUNT];
+} RD_PPTT_MINIMAL_CLUSTER;
+
+// PPTT processor package structure
+typedef struct {
+ EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR Package;
+ UINT32 ResourceOffset;
+ EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE Slc;
+ RD_PPTT_MINIMAL_CLUSTER Cluster[CLUSTER_COUNT];
+} RD_PPTT_SLC_PACKAGE;
+#pragma pack ()
+
+//
+// PPTT processor structure flags for different SoC components as define=
d in
+// ACPI 6.3 specification
+//
+
+// Processor structure flags for SoC package
+#define PPTT_PROCESSOR_PACKAGE_FLAGS =
\
+ { =
\
+ EFI_ACPI_6_3_PPTT_PACKAGE_PHYSICAL, =
\
+ EFI_ACPI_6_3_PPTT_PROCESSOR_ID_INVALID, =
\
+ EFI_ACPI_6_3_PPTT_PROCESSOR_IS_NOT_THREAD, =
\
+ EFI_ACPI_6_3_PPTT_NODE_IS_NOT_LEAF, =
\
+ EFI_ACPI_6_3_PPTT_IMPLEMENTATION_IDENTICAL =
\
+ }
+
+// Processor structure flags for cluster
+#define PPTT_PROCESSOR_CLUSTER_FLAGS =
\
+ { =
\
+ EFI_ACPI_6_3_PPTT_PACKAGE_NOT_PHYSICAL, =
\
+ EFI_ACPI_6_3_PPTT_PROCESSOR_ID_VALID, =
\
+ EFI_ACPI_6_3_PPTT_PROCESSOR_IS_NOT_THREAD, =
\
+ EFI_ACPI_6_3_PPTT_NODE_IS_NOT_LEAF, =
\
+ EFI_ACPI_6_3_PPTT_IMPLEMENTATION_IDENTICAL =
\
+ }
+
+// Processor structure flags for cluster with multi-thread core
+#define PPTT_PROCESSOR_CLUSTER_THREADED_FLAGS =
\
+ { =
\
+ EFI_ACPI_6_3_PPTT_PACKAGE_NOT_PHYSICAL, =
\
+ EFI_ACPI_6_3_PPTT_PROCESSOR_ID_INVALID, =
\
+ EFI_ACPI_6_3_PPTT_PROCESSOR_IS_NOT_THREAD, =
\
+ EFI_ACPI_6_3_PPTT_NODE_IS_NOT_LEAF, =
\
+ EFI_ACPI_6_3_PPTT_IMPLEMENTATION_IDENTICAL =
\
+ }
+
+// Processor structure flags for single-thread core
+#define PPTT_PROCESSOR_CORE_FLAGS =
\
+ { =
\
+ EFI_ACPI_6_3_PPTT_PACKAGE_NOT_PHYSICAL, =
\
+ EFI_ACPI_6_3_PPTT_PROCESSOR_ID_VALID, =
\
+ EFI_ACPI_6_3_PPTT_PROCESSOR_IS_NOT_THREAD, =
\
+ EFI_ACPI_6_3_PPTT_NODE_IS_LEAF =
\
+ }
+
+// Processor structure flags for multi-thread core
+#define PPTT_PROCESSOR_CORE_THREADED_FLAGS =
\
+ { =
\
+ EFI_ACPI_6_3_PPTT_PACKAGE_NOT_PHYSICAL, =
\
+ EFI_ACPI_6_3_PPTT_PROCESSOR_ID_INVALID, =
\
+ EFI_ACPI_6_3_PPTT_PROCESSOR_IS_NOT_THREAD, =
\
+ EFI_ACPI_6_3_PPTT_NODE_IS_NOT_LEAF, =
\
+ EFI_ACPI_6_3_PPTT_IMPLEMENTATION_IDENTICAL =
\
+ }
+
+// Processor structure flags for CPU thread
+#define PPTT_PROCESSOR_THREAD_FLAGS =
\
+ { =
\
+ EFI_ACPI_6_3_PPTT_PACKAGE_NOT_PHYSICAL, =
\
+ EFI_ACPI_6_3_PPTT_PROCESSOR_ID_VALID, =
\
+ EFI_ACPI_6_3_PPTT_PROCESSOR_IS_THREAD, =
\
+ EFI_ACPI_6_3_PPTT_NODE_IS_LEAF =
\
+ }
+
+// PPTT cache structure flags as defined in ACPI 6.3 Specification
+#define PPTT_CACHE_STRUCTURE_FLAGS =
\
+ { =
\
+ EFI_ACPI_6_3_PPTT_CACHE_SIZE_VALID, =
\
+ EFI_ACPI_6_3_PPTT_NUMBER_OF_SETS_VALID, =
\
+ EFI_ACPI_6_3_PPTT_ASSOCIATIVITY_VALID, =
\
+ EFI_ACPI_6_3_PPTT_ALLOCATION_TYPE_VALID, =
\
+ EFI_ACPI_6_3_PPTT_CACHE_TYPE_VALID, =
\
+ EFI_ACPI_6_3_PPTT_WRITE_POLICY_VALID, =
\
+ EFI_ACPI_6_3_PPTT_LINE_SIZE_VALID =
\
+ }
+
+// PPTT cache attributes for data cache
+#define PPTT_DATA_CACHE_ATTR =
\
+ { =
\
+ EFI_ACPI_6_3_CACHE_ATTRIBUTES_ALLOCATION_READ_WRITE, =
\
+ EFI_ACPI_6_3_CACHE_ATTRIBUTES_CACHE_TYPE_DATA, =
\
+ EFI_ACPI_6_3_CACHE_ATTRIBUTES_WRITE_POLICY_WRITE_BACK =
\
+ }
+
+// PPTT cache attributes for instruction cache
+#define PPTT_INST_CACHE_ATTR =
\
+ { =
\
+ EFI_ACPI_6_3_CACHE_ATTRIBUTES_ALLOCATION_READ, =
\
+ EFI_ACPI_6_3_CACHE_ATTRIBUTES_CACHE_TYPE_INSTRUCTION, =
\
+ EFI_ACPI_6_3_CACHE_ATTRIBUTES_WRITE_POLICY_WRITE_BACK =
\
+ }
+
+// PPTT cache attributes for unified cache
+#define PPTT_UNIFIED_CACHE_ATTR =
\
+ { =
\
+ EFI_ACPI_6_3_CACHE_ATTRIBUTES_ALLOCATION_READ_WRITE, =
\
+ EFI_ACPI_6_3_CACHE_ATTRIBUTES_CACHE_TYPE_UNIFIED, =
\
+ EFI_ACPI_6_3_CACHE_ATTRIBUTES_WRITE_POLICY_WRITE_BACK =
\
+ }
+
// A macro to initialise the common header part of EFI ACPI tables as de=
fined by
// EFI_ACPI_DESCRIPTION_HEADER structure.
#define ARM_ACPI_HEADER(Signature, Type, Revision) { \
@@ -246,4 +381,39 @@
TotalCacheLevels, CacheLevel, CacheAssociativity, WritePolicy, CacheLi=
neSize \
}
=20
+// EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR
+#define EFI_ACPI_6_3_PPTT_STRUCTURE_PROCESSOR_INIT(Length, Flag, Parent,=
\
+ ACPIProcessorID, NumberOfPrivateResource) =
\
+ { =
\
+ EFI_ACPI_6_3_PPTT_TYPE_PROCESSOR, /* Type 0 */ =
\
+ Length, /* Length */ =
\
+ { =
\
+ EFI_ACPI_RESERVED_BYTE, =
\
+ EFI_ACPI_RESERVED_BYTE, =
\
+ }, =
\
+ Flag, /* Processor flags=
*/ \
+ Parent, /* Ref to parent n=
ode */ \
+ ACPIProcessorID, /* UID, as per MAD=
T */ \
+ NumberOfPrivateResource /* Resource count =
*/ \
+ }
+
+// EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE
+#define EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE_INIT(Flag, NextLevelCache, Siz=
e, \
+ NoOfSets, Associativity, Attributes, LineSize) =
\
+ { =
\
+ EFI_ACPI_6_3_PPTT_TYPE_CACHE, /* Type 1 */ =
\
+ sizeof (EFI_ACPI_6_3_PPTT_STRUCTURE_CACHE), /* Length */ =
\
+ { =
\
+ EFI_ACPI_RESERVED_BYTE, =
\
+ EFI_ACPI_RESERVED_BYTE, =
\
+ }, =
\
+ Flag, /* Cache flags */ =
\
+ NextLevelCache, /* Ref to next lev=
el */ \
+ Size, /* Size in bytes *=
/ \
+ NoOfSets, /* Num of sets */ =
\
+ Associativity, /* Num of ways */ =
\
+ Attributes, /* Cache attribute=
s */ \
+ LineSize /* Line size in by=
tes */ \
+ }
+
#endif /* __SGI_ACPI_HEADER__ */
--=20
2.17.1


[edk2-platforms][PATCH V3 00/14] Platform/Sgi: Add PPTT table for Neoverse Reference Design platforms

Pranav Madhu
 

Changes since V2:
- Introduced CPU container object into DSDT
- Addressed comments from Sami

Changes since V1:
- Rebase the patches on top of latest master branch
- Addressed comments from Pierre

Processor Properties Topology Table (PPTT) describes the topological
structure of processors, and their shared resources such as caches.
This patch series adds PPTT table for Arm's Neoverse Reference Design
platforms.

The first patch in this series adds helper macros for PPTT table, and
the subsequent patches in this series adds PPTT table for Neoverse
Reference Design platforms which is mandatory as per Arm SystemReady SR
specification.

Link to github branch with the patches in this series -
https://github.com/Pranav-Madhu/edk2-platforms/tree/topics/rd_pptt

Pranav Madhu (14):
Platform/Sgi: Helper macros for PPTT Table
Platform/Sgi: Add CPU container for SGI-575
Platform/Sgi: ACPI PPTT table for SGI-575 platform
Platform/Sgi: Add CPU container for RD-N1-Edge
Platform/Sgi: ACPI PPTT table for RD-N1-Edge platform
Platform/Sgi: Add DSDT ACPI table for RD-N1-Edge dual-chip platform
Platform/Sgi: ACPI PPTT table for RD-N1-Edge dual-chip
Platform/Sgi: ACPI PPTT table for RD-E1-Edge platform
Platform/Sgi: Add CPU container for RD-V1 platform
Platform/Sgi: ACPI PPTT Table for RD-V1 platform
Platform/Sgi: Add CPU container for RD-V1 quad-chip platform
Platform/Sgi: ACPI PPTT Table for RD-V1 quad-chip platform
Platform/Sgi: Add CPU container for RD-N2 platform
Platform/Sgi: ACPI PPTT table for RD-N2 platform

.../SgiPkg/AcpiTables/RdE1EdgeAcpiTables.inf | 3 +-
.../SgiPkg/AcpiTables/RdN1EdgeAcpiTables.inf | 3 +-
.../AcpiTables/RdN1EdgeX2AcpiTables.inf | 3 +-
.../ARM/SgiPkg/AcpiTables/RdN2AcpiTables.inf | 3 +-
.../ARM/SgiPkg/AcpiTables/RdV1AcpiTables.inf | 3 +-
.../SgiPkg/AcpiTables/RdV1McAcpiTables.inf | 1 +
.../SgiPkg/AcpiTables/Sgi575AcpiTables.inf | 3 +-
Platform/ARM/SgiPkg/Include/SgiAcpiHeader.h | 170 ++++++++++++
.../ARM/SgiPkg/AcpiTables/RdE1Edge/Pptt.aslc | 252 ++++++++++++++++++
.../ARM/SgiPkg/AcpiTables/RdN1Edge/Dsdt.asl | 88 +++---
.../ARM/SgiPkg/AcpiTables/RdN1Edge/Pptt.aslc | 186 +++++++++++++
.../ARM/SgiPkg/AcpiTables/RdN1EdgeX2/Dsdt.asl | 136 ++++++++++
.../SgiPkg/AcpiTables/RdN1EdgeX2/Pptt.aslc | 207 ++++++++++++++
Platform/ARM/SgiPkg/AcpiTables/RdN2/Dsdt.asl | 176 ++++++++----
Platform/ARM/SgiPkg/AcpiTables/RdN2/Pptt.aslc | 175 ++++++++++++
Platform/ARM/SgiPkg/AcpiTables/RdV1/Dsdt.asl | 176 ++++++++----
Platform/ARM/SgiPkg/AcpiTables/RdV1/Pptt.aslc | 175 ++++++++++++
.../ARM/SgiPkg/AcpiTables/RdV1Mc/Dsdt.asl | 177 ++++++++----
.../ARM/SgiPkg/AcpiTables/RdV1Mc/Pptt.aslc | 184 +++++++++++++
.../ARM/SgiPkg/AcpiTables/Sgi575/Dsdt.asl | 99 +++----
.../ARM/SgiPkg/AcpiTables/Sgi575/Pptt.aslc | 172 ++++++++++++
21 files changed, 2156 insertions(+), 236 deletions(-)
create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdE1Edge/Pptt.aslc
create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdN1Edge/Pptt.aslc
create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2/Dsdt.asl
create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdN1EdgeX2/Pptt.aslc
create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdN2/Pptt.aslc
create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdV1/Pptt.aslc
create mode 100644 Platform/ARM/SgiPkg/AcpiTables/RdV1Mc/Pptt.aslc
create mode 100644 Platform/ARM/SgiPkg/AcpiTables/Sgi575/Pptt.aslc

--=20
2.17.1


DSC POSTBUILD problem/question

Kirkendall, Garrett
 

I'm checking out the PREBUILD and POSTBUILD option in a DSC.  I can launch my scripts, etc.

 

When there is a POSTBUILD error,  build.py properly says the build failed, but build.py is still returning 0 (success).  MyBuild.LaunchPostBuild() execution does not look like it affects ReturnCode which is returned at the end of Main.  "Conclusion" is updated though to indicate a failure.  Any ideas?  I assume build.py should return non-zero if POSTBUILD fails.

 

 

 

 

From end of edk-stable202011build.py:Main()

 

    if ReturnCode == 0:

        try:

            MyBuild.LaunchPostbuild()

            Conclusion = "Done"

        except:

            Conclusion = "Failed"

    elif ReturnCode == ABORT_ERROR:

        Conclusion = "Aborted"

    else:

        Conclusion = "Failed"

    FinishTime = time.time()

    BuildDuration = time.gmtime(int(round(FinishTime - StartTime)))

    BuildDurationStr = ""

    if BuildDuration.tm_yday > 1:

        BuildDurationStr = time.strftime("%H:%M:%S", BuildDuration) + ", %d day(s)" % (BuildDuration.tm_yday - 1)

    else:

        BuildDurationStr = time.strftime("%H:%M:%S", BuildDuration)

    if MyBuild is not None:

        if not BuildError:

            MyBuild.BuildReport.GenerateReport(BuildDurationStr, LogBuildTime(MyBuild.AutoGenTime), LogBuildTime(MyBuild.MakeTime), LogBuildTime(MyBuild.GenFdsTime))

 

    EdkLogger.SetLevel(EdkLogger.QUIET)

    EdkLogger.quiet("\n- %s -" % Conclusion)

    EdkLogger.quiet(time.strftime("Build end time: %H:%M:%S, %b.%d %Y", time.localtime()))

    EdkLogger.quiet("Build total time: %s\n" % BuildDurationStr)

    Log_Agent.kill()

    Log_Agent.join()

    return ReturnCode

 

master is the same code:

https://github.com/tianocore/edk2/blob/master/BaseTools/Source/Python/build/build.py#L2738

 

 

Garrett Kirkendall
SMTS Firmware Engineer
7171 Southwest Parkway, Austin, TX 78735 USA
AMD   facebook  |  amd.com

 


Re: [tianocore.github.io.wiki PATCH 1/1] Xcode.md: Update instructions to work on modern macOS and Xcode versions

Rebecca Cran
 

I forgot to say, this fixes https://bugzilla.tianocore.org/show_bug.cgi?id=3116 .

--
Rebecca Cran

On 5/9/21 1:18 PM, Rebecca Cran wrote:
The existing instructions no longer work on macOS Big Sur and Xcode 12.5.
Update them to include for example using lldb instead of gdb, installing
XQuartz, and using modern names such as macOS instead of Mac OS X.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
---
Xcode.md | 142 +++++++++++---------
1 file changed, 78 insertions(+), 64 deletions(-)
diff --git a/Xcode.md b/Xcode.md
index 3d220a5..c494d9d 100644
--- a/Xcode.md
+++ b/Xcode.md
@@ -1,12 +1,12 @@
-This page provides step-by-step instructions for setting up a [http://www.tianocore.org/edk2/ EDK II] build environment on Mac OS X systems using the Xcode development tools. These steps have been verified with macOS Sierra Version 10.12.4
+This page provides step-by-step instructions for setting up a [EDK II](https://github.com/tianocore/tianocore.github.io/wiki/EDK-II) build environment on macOS systems using the Xcode development tools. These steps have been verified with macOS Big Sur 11.3.1
-# Mac OS X Xcode
-Download the latest version of [Xcode](https://developer.apple.com/xcode) (9.4.1 as of this writing) from the Mac App Store. After installing Xcode, you will additionally need to install the extra command-line tools. To do this, at a Terminal prompt, enter:
+# macOS Xcode
+Download the latest version of [Xcode](https://developer.apple.com/xcode) (12.5 as of 2021-05-09) from the Mac App Store. After installing Xcode, you will additionally need to install the extra command-line tools. To do this, at a Terminal prompt, enter:
```
$ xcode-select --install
```
## Additional Development Tools
-While Xcode provides a full development environment as well as a suite of different utilities, it does not provide all tools required for Tianocore development. These tools can be provided in a number of ways, but the two most popular ways come from [Brew](https://brew.sh) and [MacPorts](https://www.macports.org/install.php). Installation information is provided at the previous links.
+While Xcode provides a full development environment as well as a suite of different utilities, it does not provide all tools required for TianoCore development. These tools can be provided in a number of ways, but the two most popular ways come from [Brew](https://brew.sh) and [MacPorts](https://www.macports.org/install.php). Installation information is provided at the previous links.
### MacPorts Tips
* If you work behind a firewall and need to pass your network traffic through a proxy, ensure you set the environment variable RSYNC_PROXY to your http proxy in the form of `proxy.dns.name:port_number`.
@@ -18,7 +18,7 @@ The mtoc utility is required to convert from the macOS Mach-O image format to th
### Brew Instructions
```
-$ brew install mtoc
+$ brew install mtoc
```
## MacPorts Instructions
```
@@ -27,7 +27,7 @@ $ sudo port install cctools
By default, this will install `mtoc` at `/opt/local/bin/mtoc`.
# Install NASM
-The assembler used for EDK II builds is Netwide Assembler (NASM). The latest version of NASM is available from http://www.nasm.us/.
+The assembler used for EDK II builds is Netwide Assembler (NASM). The latest version of NASM is available from https://nasm.us/.
## Brew Instructions
```
$ brew install nasm
@@ -53,9 +53,13 @@ $ sudo port install acpica
```
By default this installs `iasl` at `/opt/local/bin/iasl`
+# Install XQuartz
+
+The EmulatorPkg requires headers from X11, which are provided by the XQuartz project. Install it from https://www.xquartz.org/.
+
# Install QEMU Emulator
-On order to support running the OVMF platforms from the OvmfPkg, the QEMU emulator from http://www.qemu.org/ must be installed.
+On order to support running the OVMF platforms from the OvmfPkg, the QEMU emulator from https://www.qemu.org/ must be installed.
## Brew Install
```
@@ -97,84 +101,94 @@ Pick the location you want to down load the files to and `cd` to that directory:
```
cd ~/work
git clone https://github.com/tianocore/edk2.git
+cd edk2
+git submodule update --init
```
-# Build from Command Line/Debug with gdb
+# Build from Command Line/Debug with lldb
-Build the UnixPkg:
+Build the EmulatorPkg:
```
-cd ~/work/edk2/UnixPkg
+cd ~/work/edk2/EmulatorPkg
./build.sh
```
-Debug the UnixPkg
+Debug the EmulatorPkg
```
./build.sh run
-Building from: /Users/fish/work/edk2
+Initializing workspace
+/Users/bcran/src/edk2/BaseTools
+Loading previous configuration from /Users/bcran/src/edk2/Conf/BuildEnv.sh
+Using EDK2 in-source Basetools
+WORKSPACE: /Users/bcran/src/edk2
+EDK_TOOLS_PATH: /Users/bcran/src/edk2/BaseTools
+CONF_PATH: /Users/bcran/src/edk2/Conf
using prebuilt tools
-Reading symbols for shared libraries ...... done
-Breakpoint 1 at 0xce84: file /Users/fish/work/edk2/UnixPkg/Sec/SecMain.c, line 1070.
-(gdb)
-```
-
-Type `r` at the gdb prompt (don't forget to hit carriage return) to boot the emulator. Ctrl-c in the terminal window will break in to gdb. bt is the stack backtrace command:
-
-```
-^C
-Program received signal SIGINT, Interrupt.
-0x92423806 in __semwait_signal ()
-(gdb) bt
-#0 0x92423806 in __semwait_signal ()
-#1 0x9244f441 in nanosleep$UNIX2003 ()
-#2 0x0000b989 in msSleep (Milliseconds=0x14) at /Users/fish/work/Migration/edk2/UnixPkg/Sec/UnixThunk.c:102
-#3 0x0000acf5 in UgaCheckKey (UgaIo=0x2078d0) at /Users/fish/work/Migration/edk2/UnixPkg/Sec/UgaX11.c:380
-#4 0x0000d8b7 in _GasketUintn () at /Users/fish/work/Migration/edk2/Build/Unix/DEBUG_XCODE32/IA32/UnixPkg/Sec/SecMain/OUTPUT/Ia32/Gasket.iii:63
-#5 0x0000d801 in GasketUgaCheckKey (UgaIo=0x2078d0) at /Users/fish/work/Migration/edk2/UnixPkg/Sec/Gasket.c:406
-#6 0x454a25fb in UnixUgaSimpleTextInWaitForKey (Event=0x45603610, Context=0x45382110) at /Users/fish/work/Migration/edk2/UnixPkg/UnixUgaDxe/UnixUgaInput.c:169
-#7 0x45faad3a in CoreDispatchEventNotifies (Priority=0x10) at /Users/fish/work/Migration/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:185
-#8 0x45faa639 in CoreRestoreTpl (NewTpl=0x4) at /Users/fish/work/Migration/edk2/MdeModulePkg/Core/Dxe/Event/Tpl.c:114
-#9 0x45f9f197 in CoreReleaseLock (Lock=0x45fb1024) at /Users/fish/work/Migration/edk2/MdeModulePkg/Core/Dxe/Library/Library.c:102
-#10 0x45faabd6 in CoreReleaseEventLock () at /Users/fish/work/Migration/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:113
-#11 0x45fab26c in CoreCheckEvent (UserEvent=0x45603210) at /Users/fish/work/Migration/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:562
-#12 0x45fab2db in CoreWaitForEvent (NumberOfEvents=0x1, UserEvents=0x45f94cc4, UserIndex=0x45f94cb8) at /Users/fish/work/Migration/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:621
-#13 0x49ce9557 in ?? ()
-#14 0x49cf0344 in ?? ()
-#15 0x49ce3bc2 in ?? ()
-#16 0x49ce3ae1 in ?? ()
-#17 0x45f9e4e3 in CoreStartImage (ImageHandle=0x49e31e10, ExitDataSize=0x45f94eec, ExitData=0x45f94ee8) at /Users/fish/work/Migration/edk2/MdeModulePkg/Core/Dxe/Image/Image.c:1260
-#18 0x4550cccc in BdsLibBootViaBootOption (Option=0x49ffa110, DevicePath=0x49ffa190, ExitDataSize=0x45f94eec, ExitData=0x45f94ee8) at /Users/fish/work/Migration/edk2/IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c:382
-#19 0x455252a9 in BdsBootDeviceSelect () at /Users/fish/work/Migration/edk2/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:214
-#20 0x455255bc in BdsEntry (This=0x4552d01c) at /Users/fish/work/Migration/edk2/IntelFrameworkModulePkg/Universal/BdsDxe/BdsEntry.c:356
-#21 0x45fad7e8 in DxeMain (HobStart=0x45f70010) at /Users/fish/work/Migration/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:425
-#22 0x45fadd1d in ProcessModuleEntryPointList (HobStart=0x42020000) at /Users/fish/work/Migration/edk2/Build/Unix/DEBUG_XCODE32/IA32/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/AutoGen.c:287
-#23 0x45f97773 in _ModuleEntryPoint (HobStart=0x42020000) at /Users/fish/work/Migration/edk2/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.c:54
-(gdb)
+(lldb) target create "./Host"
+Current executable set to '/Users/bcran/src/edk2/Build/EmulatorX64/DEBUG_XCODE5/X64/Host' (x86_64).
+(lldb) command script import /Users/bcran/src/edk2/EmulatorPkg/Unix/lldbefi.py
+Type r to run emulator. SecLldbScriptBreak armed. EFI modules should now get source level debugging in the emulator.
+(lldb) script lldb.debugger.SetAsync(True)
+(lldb) run
+Process 12155 launched: '/Users/bcran/src/edk2/Build/EmulatorX64/DEBUG_XCODE5/X64/Host' (x86_64)
+
+EDK II UNIX Host Emulation Environment from http://www.tianocore.org/edk2/
+ BootMode 0x00
+ OS Emulator passing in 128 KB of temp RAM at 0x102000000 to SEC
+ FD loaded from ../FV/FV_RECOVERY.fd at 0x102020000 contains SEC Core
+...
+```
+
+Type `process interrupt` at the lldb prompt (don't forget to hit carriage return) to pause execution. Ctrl-c in the terminal window will quit lldb. `bt` is the stack backtrace command:
+
+```
+Process 12420 stopped
+* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
+ frame #0: 0x00007fff2033cc22 libsystem_kernel.dylib:__semwait_signal() + 10
+libsystem_kernel.dylib`__semwait_signal:
+-> 0x7fff2033cc22 <+10>: jae 0x7fff2033cc2c ; <+20>
+ 0x7fff2033cc24 <+12>: movq %rax, %rdi
+ 0x7fff2033cc27 <+15>: jmp 0x7fff2033b72d ; cerror
+ 0x7fff2033cc2c <+20>: retq
+Target 0: (Host) stopped.
+(lldb) bt
+* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
+ * frame #0: 0x00007fff2033cc22 libsystem_kernel.dylib:__semwait_signal() + 10
+ frame #1: 0x00007fff202bcc2a libsystem_c.dylib:nanosleep() + 196
+ frame #2: 0x0000000100005e55 Host:SecCpuSleep() + 37 at /Users/bcran/src/edk2/EmulatorPkg/Unix/Host/EmuThunk.c:334
+ frame #3: 0x000000010000e96e Host:GasketSecCpuSleep() + 11 at /Users/bcran/src/edk2/Build/EmulatorX64/DEBUG_XCODE5/X64/EmulatorPkg/Unix/Host/Host/OUTPUT/X64/Gasket.iiii:283
+ frame #4: 0x0000000106f985e9 DxeCore.dll:CoreDispatchEventNotifies() + 264 at /Users/bcran/src/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:194
+ frame #5: 0x0000000106f97fce DxeCore.dll:CoreRestoreTpl() + 227 at /Users/bcran/src/edk2/MdeModulePkg/Core/Dxe/Event/Tpl.c:131
+ frame #6: 0x0000000106f989db DxeCore.dll:CoreSignalEvent() + 111 at /Users/bcran/src/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:566
+ frame #7: 0x0000000106f98b01 DxeCore.dll:CoreWaitForEvent() + 94 at /Users/bcran/src/edk2/MdeModulePkg/Core/Dxe/Event/Event.c:707
+ frame #8: 0x0000000113e8e54c BdsDxe.dll:BdsWaitForSingleEvent() + 127 at /Users/bcran/src/edk2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c:250
+ frame #9: 0x0000000113e8e70b BdsDxe.dll:BdsWait() + 215 at /Users/bcran/src/edk2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c:328
+ frame #10: 0x0000000113e8dffb BdsDxe.dll:BdsEntry() + 2612 at /Users/bcran/src/edk2/MdeModulePkg/Universal/BdsDxe/BdsEntry.c:1012
+ frame #11: 0x0000000106f9bbd6 DxeCore.dll:DxeMain() + 2791 at /Users/bcran/src/edk2/MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:551
+ frame #12: 0x0000000106f9ed8f DxeCore.dll:_ModuleEntryPoint() + 20 at /Users/bcran/src/edk2/MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.c:48
+ frame #13: 0x0000000106fdd02f DxeIpl.dll:InternalSwitchStack() + 15
+ frame #14: 0x0000000106fdc0b6 DxeIpl.dll:HandOffToDxeCore() + 546 at /Users/bcran/src/edk2/MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c:126
+ frame #15: 0x0000000106fda78a DxeIpl.dll:DxeLoadCore() + 1354 at /Users/bcran/src/edk2/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c:449
+ frame #16: 0x0000000106ff1d7c
+ frame #17: 0x00000001020255c6 PeiCore.dll:PeiCore() + 1982 at /Users/bcran/src/edk2/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c:331
+ frame #18: 0x000000010202a82c PeiCore.dll:PeiCheckAndSwitchStack() + 1171 at /Users/bcran/src/edk2/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c:842
+ frame #19: 0x000000010202b853 PeiCore.dll:PeiDispatcher() + 1206 at /Users/bcran/src/edk2/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c:1609
+(lldb)
+
```
# Build and Debug from Xcode
-To build from the Xcode GUI open ~/work/edk2/UnixPkg/Xcode/xcode_project/xcode_project.xcodeproj. You can build, clean, and source level debug from the Xcode GUI. You can hit the Build and Debug button to start the build process. You need to need to hit command-shift-B to show the output of the build. Click Pause to break into the debugger.
-
-[[File:Xcode.jpg]]
+To build from the Xcode GUI open ~/work/edk2/EmulatorPkg/Unix/Xcode/xcode_project64/xcode_project.xcodeproj. You can build, clean, and source level debug from the Xcode GUI. You can hit the Build and Debug button to start the build process. You need to need to hit command-shift-B to show the output of the build. Click Pause to break into the debugger.
The stack trace contains items that show as ?? since the default shell is checked in as a binary. `nanosleep$UNIX2003` and `__semwait_signal` are POSIX library calls and you do not get C source debug with these symbols.
-# Source Level Debug Shell
-
-It is possible to get source level debug for the EFI Shell by pulling these projects from source control and building them.
-
-Instructions for building and hooking in the shell are located in the [https://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Gcc-shell gcc-shell] project.
-
-Please note the gcc-shell and UnixPkg build separately, so if you update shell code you need to build the shell to see the changes. The following screen shot shows being able to source level debug the shell:
-
-[[File:Xcode_good.jpg]]
+*Note* The Xcode project is currently (as of 2021-05-09) broken.
# See Also
-* [[Step-by-step instructions]]
-
# Continue with common instructions
-The [remaining instructions](../Common-instructions) are common for most UNIX-like systems.
+The [remaining instructions](https://github.com/tianocore/tianocore.github.io/wiki/Common-instructions-for-Unix) are common for most UNIX-like systems.


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

Lendacky, Thomas
 

On 5/10/21 9:24 AM, Lendacky, Thomas via groups.io wrote:
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.
I should have included a Fixes: 7b7508ad784d16a5208c8d12dff43aef6df0835b tag.

Tom

Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
---
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);

//


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

Ilias Apalodimas
 

On Mon, May 10, 2021 at 05:57:08PM +0200, Ard Biesheuvel wrote:
On Mon, 10 May 2021 at 09:53, Etienne Carriere
<etienne.carriere@linaro.org> 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@kernel.org>

I'll pick these up once the EDK2 side is merged.
Acked-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
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 1/2] Silicon/Broadcom/BcmGenetDxe: Delay for linkup in transmit

Ard Biesheuvel
 

On Mon, 10 May 2021 at 19:26, Jeremy Linton <jeremy.linton@arm.com> wrote:

Hi,

On 5/10/21 11:56 AM, Ard Biesheuvel wrote:
On Thu, 15 Apr 2021 at 21:22, Jeremy Linton <jeremy.linton@arm.com> 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.
This is an excellent problem description. Could we dedicate a couple
of paragraphs to the solution as well? Especially given that 'wait for
random # of seconds' seems to be the taken approach here, which seems
a bit sloppy to me, given that we should be able to detect whether the
link is up, no?
Isn't that what GenericPhyUpdateConfig is doing? Checking for linkup,
and updating the phy state? So once the link goes up, it return
EFI_SUCCESS and the loop terminates.
OK. Could you dedicate some prose to this logic in the commit log please?

I was actually a bit concerned that the 10s wasn't enough since AFAIK a
large part of the delay is the remote side.
The remote side of what? The Ethernet cable?






For reference: https://github.com/pftf/RPi4/issues/113

Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
.../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 <Library/DebugLib.h>
#include <Library/DmaLib.h>
#include <Library/NetLib.h>
+#include <Library/UefiBootServicesTableLib.h>
#include <Protocol/SimpleNetwork.h>

#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 (10000);
+ 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






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

Jeremy Linton
 

Hi,

On 5/10/21 11:56 AM, Ard Biesheuvel wrote:
On Thu, 15 Apr 2021 at 21:22, Jeremy Linton <jeremy.linton@arm.com> 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.
This is an excellent problem description. Could we dedicate a couple
of paragraphs to the solution as well? Especially given that 'wait for
random # of seconds' seems to be the taken approach here, which seems
a bit sloppy to me, given that we should be able to detect whether the
link is up, no?
Isn't that what GenericPhyUpdateConfig is doing? Checking for linkup, and updating the phy state? So once the link goes up, it return EFI_SUCCESS and the loop terminates.

I was actually a bit concerned that the 10s wasn't enough since AFAIK a large part of the delay is the remote side.




For reference: https://github.com/pftf/RPi4/issues/113

Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
.../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 <Library/DebugLib.h>
#include <Library/DmaLib.h>
#include <Library/NetLib.h>
+#include <Library/UefiBootServicesTableLib.h>
#include <Protocol/SimpleNetwork.h>

#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 (10000);
+ 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





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

Ard Biesheuvel
 

On Thu, 15 Apr 2021 at 21:22, Jeremy Linton <jeremy.linton@arm.com> wrote:

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 <jeremy.linton@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>


---
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 {
<PcdsFixedAtBuild>
gEmbeddedTokenSpaceGuid.PcdDmaDeviceOffset|0x00000000
- gEmbeddedTokenSpaceGuid.PcdDmaDeviceLimit|0xffffffff
+ gEmbeddedTokenSpaceGuid.PcdDmaDeviceLimit|0xffffffffff
}

#
--
2.13.7






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

Ard Biesheuvel
 

On Thu, 15 Apr 2021 at 21:22, Jeremy Linton <jeremy.linton@arm.com> 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.
This is an excellent problem description. Could we dedicate a couple
of paragraphs to the solution as well? Especially given that 'wait for
random # of seconds' seems to be the taken approach here, which seems
a bit sloppy to me, given that we should be able to detect whether the
link is up, no?



For reference: https://github.com/pftf/RPi4/issues/113

Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
---
.../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 <Library/DebugLib.h>
#include <Library/DmaLib.h>
#include <Library/NetLib.h>
+#include <Library/UefiBootServicesTableLib.h>
#include <Protocol/SimpleNetwork.h>

#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 (10000);
+ 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






Re: [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 <jmcneill@invisible.ca>
Sent: Friday, April 30, 2021 6:30 AM
To: Jeremy Linton <Jeremy.Linton@arm.com>
Cc: devel@edk2.groups.io; Ard Biesheuvel <Ard.Biesheuvel@arm.com>;
leif@nuviainc.com; Pete Batard <pete@akeo.ie>; Samer El-Haj-Mahmoud
<Samer.El-Haj-Mahmoud@arm.com>; Andrei Warkentin
(awarkentin@vmware.com) <awarkentin@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 <jeremy.linton@arm.com>
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 <jeremy.linton@arm.com>
---
.../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 <Library/DebugLib.h>
#include <Library/DmaLib.h>
#include <Library/NetLib.h>
+#include <Library/UefiBootServicesTableLib.h>
#include <Protocol/SimpleNetwork.h>
#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 (10000);
+ 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.


Re: [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 <jeremy.linton@arm.com>
Sent: Thursday, April 15, 2021 3:22 PM
To: devel@edk2.groups.io
Cc: Ard Biesheuvel <Ard.Biesheuvel@arm.com>; leif@nuviainc.com;
pete@akeo.ie; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@arm.com>; Andrei Warkentin (awarkentin@vmware.com)
<awarkentin@vmware.com>; Jeremy Linton <Jeremy.Linton@arm.com>
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 <jeremy.linton@arm.com>
---
.../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 <Library/DebugLib.h>
#include <Library/DmaLib.h>
#include <Library/NetLib.h>
+#include <Library/UefiBootServicesTableLib.h>
#include <Protocol/SimpleNetwork.h>

#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 (10000);
+ 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.


Re: [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 <jeremy.linton@arm.com>
Sent: Thursday, April 15, 2021 3:22 PM
To: devel@edk2.groups.io
Cc: Ard Biesheuvel <Ard.Biesheuvel@arm.com>; leif@nuviainc.com;
pete@akeo.ie; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@arm.com>; Andrei Warkentin (awarkentin@vmware.com)
<awarkentin@vmware.com>; Jeremy Linton <Jeremy.Linton@arm.com>
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.


Re: [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 <jmcneill@invisible.ca>
Sent: Friday, April 30, 2021 9:08 PM
To: Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>
Cc: Jeremy Linton <Jeremy.Linton@arm.com>; devel@edk2.groups.io; Ard
Biesheuvel <Ard.Biesheuvel@arm.com>; leif@nuviainc.com; pete@akeo.ie;
Andrei Warkentin (awarkentin@vmware.com) <awarkentin@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 <Samer.El-Haj-
Mahmoud@arm.com> wrote:

+Jared

Reviewed-By: Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@arm.com>

-----Original Message-----
From: Jeremy Linton <jeremy.linton@arm.com>
Sent: Thursday, April 15, 2021 3:22 PM
To: devel@edk2.groups.io
Cc: Ard Biesheuvel <Ard.Biesheuvel@arm.com>; leif@nuviainc.com;
pete@akeo.ie; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@arm.com>;
Andrei Warkentin (awarkentin@vmware.com)
<awarkentin@vmware.com>;
Jeremy Linton <Jeremy.Linton@arm.com>
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 <jeremy.linton@arm.com>
---
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 {
<PcdsFixedAtBuild>
gEmbeddedTokenSpaceGuid.PcdDmaDeviceOffset|0x00000000
- gEmbeddedTokenSpaceGuid.PcdDmaDeviceLimit|0xffffffff
+ gEmbeddedTokenSpaceGuid.PcdDmaDeviceLimit|0xffffffffff
}

#
--
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 2/2] Platform/RaspberryPi: Increase genet dma window

Samer El-Haj-Mahmoud
 

+Ard's new e-mail address

-----Original Message-----
From: Jeremy Linton <jeremy.linton@arm.com>
Sent: Thursday, April 15, 2021 3:22 PM
To: devel@edk2.groups.io
Cc: Ard Biesheuvel <Ard.Biesheuvel@arm.com>; leif@nuviainc.com;
pete@akeo.ie; Samer El-Haj-Mahmoud <Samer.El-Haj-
Mahmoud@arm.com>; Andrei Warkentin (awarkentin@vmware.com)
<awarkentin@vmware.com>; Jeremy Linton <Jeremy.Linton@arm.com>
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 <jeremy.linton@arm.com>
---
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 {
<PcdsFixedAtBuild>
gEmbeddedTokenSpaceGuid.PcdDmaDeviceOffset|0x00000000
- gEmbeddedTokenSpaceGuid.PcdDmaDeviceLimit|0xffffffff
+ gEmbeddedTokenSpaceGuid.PcdDmaDeviceLimit|0xffffffffff
}

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

-----Original Message-----
From: Pete Batard <pete@akeo.ie>
Sent: Thursday, April 8, 2021 5:48 AM
To: Jeremy Linton <Jeremy.Linton@arm.com>; devel@edk2.groups.io
Cc: Ard Biesheuvel <Ard.Biesheuvel@arm.com>; leif@nuviainc.com; Samer
El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Andrei Warkentin
(awarkentin@vmware.com) <awarkentin@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 <jeremy.linton@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 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,
Reviewed-by: Pete Batard <pete@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.

7741 - 7760 of 82581