Date   

[edk2-platforms v2 2/3] SbsaQemu: Update SbsaQemuAcpiDxe to use FdtHelperLib

Rebecca Cran
 

Use the copy of the CountCpusFromFdt function from FdtHelperLib.

Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
---
Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 50 +-------------------
Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf | 1 +
2 files changed, 2 insertions(+), 49 deletions(-)

diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
index fb7c1835c3d7..02ba3e452c06 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c
@@ -12,6 +12,7 @@
#include <Library/AcpiLib.h>
#include <Library/BaseMemoryLib.h>
#include <Library/DebugLib.h>
+#include <Library/FdtHelperLib.h>
#include <Library/MemoryAllocationLib.h>
#include <Library/PcdLib.h>
#include <Library/PrintLib.h>
@@ -25,55 +26,6 @@
STATIC INT32 FdtFirstCpuOffset;
STATIC INT32 FdtCpuNodeSize;

-/*
- * A function that walks through the Device Tree created
- * by Qemu and counts the number of CPUs present in it.
- */
-STATIC
-VOID
-CountCpusFromFdt (
- VOID
-)
-{
- VOID *DeviceTreeBase;
- INT32 Node, Prev;
- RETURN_STATUS PcdStatus;
- INT32 CpuNode;
- INT32 CpuCount;
-
- DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeBaseAddress);
- ASSERT (DeviceTreeBase != NULL);
-
- // Make sure we have a valid device tree blob
- ASSERT (fdt_check_header (DeviceTreeBase) == 0);
-
- CpuNode = fdt_path_offset (DeviceTreeBase, "/cpus");
- if (CpuNode <= 0) {
- DEBUG ((DEBUG_ERROR, "Unable to locate /cpus in device tree\n"));
- return;
- }
-
- CpuCount = 0;
-
- // Walk through /cpus node and count the number of subnodes.
- // The count of these subnodes corresponds to the number of
- // CPUs created by Qemu.
- Prev = fdt_first_subnode (DeviceTreeBase, CpuNode);
- FdtFirstCpuOffset = Prev;
- while (1) {
- CpuCount++;
- Node = fdt_next_subnode (DeviceTreeBase, Prev);
- if (Node < 0) {
- break;
- }
- FdtCpuNodeSize = Node - Prev;
- Prev = Node;
- }
-
- PcdStatus = PcdSet32S (PcdCoreCount, CpuCount);
- ASSERT_RETURN_ERROR (PcdStatus);
-}
-
/*
* Get MPIDR from device tree passed by Qemu
*/
diff --git a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
index 127eef029f3c..a32c1d91e834 100644
--- a/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
+++ b/Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf
@@ -35,6 +35,7 @@
DebugLib
DxeServicesLib
FdtLib
+ FdtHelperLib
PcdLib
PrintLib
UefiDriverEntryPoint
--
2.26.2


[edk2-platforms v2 1/3] SbsaQemu: Add FdtHelperLib

Rebecca Cran
 

The CountCpusFromFdt function is now used in two places. Create
FdtHelperLib for this and similar functions.

Signed-off-by: Rebecca Cran <rebecca@nuviainc.com>
---
Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 2 +
Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h | 24 +++++++
Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c | 69 ++++++++++++++++++++
Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf | 28 ++++++++
4 files changed, 123 insertions(+)

diff --git a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
index f6af3f9111ee..8faad3eda217 100644
--- a/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
+++ b/Platform/Qemu/SbsaQemu/SbsaQemu.dsc
@@ -121,6 +121,8 @@ DEFINE NETWORK_HTTP_BOOT_ENABLE = FALSE
# ARM PL011 UART Driver
PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf

+ FdtHelperLib|Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
+
# Debug Support
PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf
DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
diff --git a/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h b/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
new file mode 100644
index 000000000000..eac47349a3d7
--- /dev/null
+++ b/Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
@@ -0,0 +1,24 @@
+/** @file
+* FdtHelperLib.h
+*
+* Copyright (c) 2021, NUVIA Inc. All rights reserved.
+*
+* SPDX-License-Identifier: BSD-2-Clause-Patent
+*
+**/
+
+#ifndef FDT_HELPER_LIB_
+#define FDT_HELPER_LIB_
+
+/** Walks through the Device Tree created by Qemu and counts the number
+ of CPUs present in it.
+
+ @return The number of CPUs present.
+**/
+EFIAPI
+UINT16
+CountCpusFromFdt (
+ VOID
+ );
+
+#endif /* FDT_HELPER_LIB_ */
diff --git a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c
new file mode 100644
index 000000000000..c399fec5f9c7
--- /dev/null
+++ b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c
@@ -0,0 +1,69 @@
+/** @file
+* FdtHelperLib.c
+*
+* Copyright (c) 2021, NUVIA Inc. All rights reserved.
+* Copyright (c) 2020, Linaro Ltd. All rights reserved.
+*
+* SPDX-License-Identifier: BSD-2-Clause-Patent
+*
+**/
+
+
+/** Walks through the Device Tree created by Qemu and counts the number
+ of CPUs present in it.
+
+ @return The number of CPUs present.
+**/
+
+#include <Uefi.h>
+#include <Library/DebugLib.h>
+#include <Library/FdtHelperLib.h>
+#include <Library/PcdLib.h>
+#include <libfdt.h>
+
+/** Walks through the Device Tree created by Qemu and counts the number
+ of CPUs present in it.
+
+ @return The number of CPUs present.
+**/
+EFIAPI
+UINT16
+CountCpusFromFdt (
+ VOID
+ )
+{
+ VOID *DeviceTreeBase;
+ INT32 Node;
+ INT32 Prev;
+ INT32 CpuNode;
+ INT32 CpuCount;
+
+ DeviceTreeBase = (VOID *)(UINTN)PcdGet64 (PcdDeviceTreeBaseAddress);
+ ASSERT (DeviceTreeBase != NULL);
+
+ // Make sure we have a valid device tree blob
+ ASSERT (fdt_check_header (DeviceTreeBase) == 0);
+
+ CpuNode = fdt_path_offset (DeviceTreeBase, "/cpus");
+ if (CpuNode <= 0) {
+ DEBUG ((DEBUG_ERROR, "Unable to locate /cpus in device tree\n"));
+ return 0;
+ }
+
+ CpuCount = 0;
+
+ // Walk through /cpus node and count the number of subnodes.
+ // The count of these subnodes corresponds to the number of
+ // CPUs created by Qemu.
+ Prev = fdt_first_subnode (DeviceTreeBase, CpuNode);
+ while (1) {
+ CpuCount++;
+ Node = fdt_next_subnode (DeviceTreeBase, Prev);
+ if (Node < 0) {
+ break;
+ }
+ Prev = Node;
+ }
+
+ return CpuCount;
+}
diff --git a/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
new file mode 100644
index 000000000000..d84c16f888d1
--- /dev/null
+++ b/Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf
@@ -0,0 +1,28 @@
+#/** @file
+#
+# Component description file for FdtHelperLib module
+#
+# Copyright (c) 2021, NUVIA Inc. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+#**/
+
+[Defines]
+ INF_VERSION = 1.29
+ BASE_NAME = FdtHelperLib
+ FILE_GUID = 34e4396f-c2fc-4f9e-ad58-0f98e99e3875
+ MODULE_TYPE = BASE
+ VERSION_STRING = 1.0
+ LIBRARY_CLASS = FdtHelperLib
+
+[Sources.common]
+ FdtHelperLib.c
+
+[Packages]
+ EmbeddedPkg/EmbeddedPkg.dec
+ MdePkg/MdePkg.dec
+ Silicon/Qemu/SbsaQemu/SbsaQemu.dec
+
+[FixedPcd]
+ gArmVirtSbsaQemuPlatformTokenSpaceGuid.PcdDeviceTreeBaseAddress
--
2.26.2


[edk2-platforms v2 0/3] Platform/Qemu/SbsaQemu: Add SMBIOS tables

Rebecca Cran
 

o Add SMBIOS 3.4.0 tables using ArmPkg/Universal/Smbios.
o Bump the PcdSmbiosVersion PCD from 0x300 to 0x304 to indicate support
for SMBIOS 3.4.0, as is required by SBBR.
o Add an implementation of OemMiscLib that provides the system
information. The serial numbers, asset tags etc. are currently all
fixed strings, to allow fwts to pass without errors.
o Add SMBIOS PCDs to identify the platform. The processor serial
number, asset tag and part number are populated because otherwise
fwts reports errors.

Changes between v1 and v2:

o Renamed OemMiscLib 'socket' functions to 'processor'.
o Added PCDs for the various strings (SN, SKU etc.).
o Added FdtHelperLib.
o Updated SBSA ACPI Dxe to use FdtHelperLib.
o Changed SBSA SMBIOS Processor information to create multiple CPUs,
instead of a single multi-core CPU.
o Updated cache level to be 1-based.
o Fixed/moved/added EFIAPI specifiers.

This series requires associated changes to the edk2 repo, so will
need some coordination to reduce the amount of time the build is
broken.


Rebecca Cran (3):
SbsaQemu: Add FdtHelperLib
SbsaQemu: Update SbsaQemuAcpiDxe to use FdtHelperLib
Platform/Qemu/SbsaQemu: Add SMBIOS tables

Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c | 242 ++++++++++++++++++++
Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf | 53 +++++
Platform/Qemu/SbsaQemu/SbsaQemu.dsc | 50 +++-
Platform/Qemu/SbsaQemu/SbsaQemu.fdf | 7 +
Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.c | 50 +---
Silicon/Qemu/SbsaQemu/Drivers/SbsaQemuAcpiDxe/SbsaQemuAcpiDxe.inf | 1 +
Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h | 24 ++
Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c | 69 ++++++
Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf | 28 +++
Silicon/Qemu/SbsaQemu/SbsaQemu.dec | 18 ++
10 files changed, 492 insertions(+), 50 deletions(-)
create mode 100644 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.c
create mode 100644 Platform/Qemu/SbsaQemu/OemMiscLib/OemMiscLib.inf
create mode 100644 Silicon/Qemu/SbsaQemu/Include/Library/FdtHelperLib.h
create mode 100644 Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.c
create mode 100644 Silicon/Qemu/SbsaQemu/Library/FdtHelperLib/FdtHelperLib.inf

--
2.26.2


Re: [PATCH] UefiPayloadPkg/UefiPayloadEntry: Remove 4GB memory WA

Ma, Maurice
 

Reviewed-by: Maurice Ma <maurice.ma@intel.com>

Regards
Maurice

-----Original Message-----
From: Dong, Guo <guo.dong@intel.com>
Sent: Sunday, February 14, 2021 21:13
To: devel@edk2.groups.io
Cc: Ma, Maurice <maurice.ma@intel.com>; You, Benjamin
<benjamin.you@intel.com>
Subject: [edk2-devel] [PATCH] UefiPayloadPkg/UefiPayloadEntry: Remove
4GB memory WA

Previous it would hang in CpuDxe if DXE drivers are dispatched above 4GB.
Now remove the work around since the fixed in CpuDxe are merged.

Signed-off-by: Guo Dong <guo.dong@intel.com>
---
UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c | 5 -----
1 file changed, 5 deletions(-)

diff --git a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
index 805f5448d9..c403b0a80a 100644
--- a/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
+++ b/UefiPayloadPkg/UefiPayloadEntry/UefiPayloadEntry.c
@@ -40,11 +40,6 @@ MemInfoCallback (
EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE;

- if (Base >= BASE_4GB ) {
- // Remove tested attribute to avoid DXE core to dispatch driver to
memory above 4GB
- Attribue &= ~EFI_RESOURCE_ATTRIBUTE_TESTED;
- }
-
BuildResourceDescriptorHob (Type, Attribue,
(EFI_PHYSICAL_ADDRESS)Base, Size);
DEBUG ((DEBUG_INFO , "buildhob: base = 0x%lx, size = 0x%lx, type =
0x%x\n", Base, Size, Type));

--
2.16.2.windows.1


Re: Does EDK2 ArmVirtPkg has support for a virtio-mmio-blk device

Ying Fang
 



On 2021/2/10 2:32 上午, Laszlo Ersek wrote:
> On 02/09/21 16:28, Ard Biesheuvel wrote:
>> On Tue, 9 Feb 2021 at 14:41, Laszlo Ersek <lersek@...> wrote:
>>>
>>> On 02/09/21 03:54, Ying Fang wrote:
>>>
>>>> I now realize that we emulate the virtio-blk-device over mmio, and we
>>>> only emulate virtio-1.0 spec.
>>>> As mentioned in (1c) , EDK2 only supports virtio-0.95 spec for now, so
>>>> this maybe a big problem.
>>>> Since it may not handshake ok if we only emulate virtio-1.0.
>>>
>>> Yes.
>>>
>>> First, the MMIO transport (as I remember from checking it last time,
>>> which was quite some time ago) is very different between 0.9.5 and 1.0.
>>>
>>> Second, device initialization steps differ:
>>> - between 0.9.5 MMIO and 0.9.5 PCI,
>>> - between 0.9.5 and 1.0, regardless of transport.
>>>
>>> This means that the device driver code has *some* specifics (=
>>> abstraction leaks) that relate to the underlying transport (MMIO vs.
>>> PCI, and 0.9.5 vs. 1.0). See:
>>>
>>> OvmfPkg/VirtioBlkDxe/VirtioBlk.c
>>>
>>> 752 //
>>> 753 // Set Page Size - MMIO VirtIo Specific
>>> 754 //
>>> 755 Status = Dev->VirtIo->SetPageSize (Dev->VirtIo, EFI_PAGE_SIZE);
>>>
>>> 822 //
>>> 823 // In virtio-1.0, feature negotiation is expected to complete before queue
>>> 824 // discovery, and the device can also reject the selected set of features.
>>> 825 //
>>> 826 if (Dev->VirtIo->Revision >= VIRTIO_SPEC_REVISION (1, 0, 0)) {
>>> 827 Status = Virtio10WriteFeatures (Dev->VirtIo, Features, &NextDevStat);
>>>
>>> 867 //
>>> 868 // Additional steps for MMIO: align the queue appropriately, and set the
>>> 869 // size. If anything fails from here on, we must unmap the ring resources.
>>> 870 //
>>> 871 Status = Dev->VirtIo->SetQueueNum (Dev->VirtIo, QueueSize);
>>>
>>> 894 //
>>> 895 // step 5 -- Report understood features.
>>> 896 //
>>> 897 if (Dev->VirtIo->Revision < VIRTIO_SPEC_REVISION (1, 0, 0)) {
>>> 898 Features &= ~(UINT64)(VIRTIO_F_VERSION_1 | VIRTIO_F_IOMMU_PLATFORM);
>>> 899 Status = Dev->VirtIo->SetGuestFeatures (Dev->VirtIo, Features);
>>>
>>> We tried to make these "abstraction leaks" as small as possible; for
>>> example the MMIO specific operations (SetPageSize, SetQueueNum) are
>>> performed unconditionally, and it's only the PCI transport backends that
>>> simply ignore those actions (after performing some sanity checks).
>>> However, the different order of initialization steps couldn't really be
>>> hidden (I wasn't comfortable with simply regression-testing the new 1.0
>>> order against 0.9.5 transports of QEMU, so we kept both init orders).
>>>
>>> Virtio MMIO was always classified as "temporary" and "legacy", needed
>>> only until PCI support would be brought about on ARM. So given the
>>> increased complexity of Virtio MMIO in the 1.0 spec, I always believed
>>> that designing and implementing the latter in OVMF would be a waste of
>>> effort.

Agreed, for most use cases we should first implement PCI stuff before
using EDK2 on ARM platform.

For now we are building StratoVirt [1] (a light weight VMM) using Rust
language just like firecracker does.

Futher we are planing to bring EDK2 boot and ACPI features for it.
However the PCI feature is WIP, so we are using Virtio MMIO as a
temporary approach. We will switch to PCI when the PCI feature is done,
so it won't be a problem. I am just trying to test the EDK2
functionality using ArmVirtPkg QEMU desgin before PCI support.

[1] https://gitee.com/openeuler/stratovirt

>>>
>>>
>>>> I will try to emulate the virtio-0.95 later to see if it is the root
>>>> cause.
>>>
>>> Yes, please either do that, or please add a PCI host.
>>>
>>> Given that you do get a BLK0: alias in the UEFI shell, the
>>> initialization of the device might even *appear* to complete, to OVMF;
>>> however, the actual virtio transfers likely fail.
>>>
>>
>> That BLK0: alias in the UEFI shell is the NOR flash not a virtio block device.

Thanks for pointing it out. I was once recognizing it as the Virtio
Block device by mistake.

>>
>
> Sigh, thanks.
>
> In the original message, only "VenHw(xxx, 00)" was included, and I
> couldn't tell at once whether the vendor GUID was indeed
> gVirtioMmioTransportGuid (837DCA9E-E874-4D82-B29A-23FE0E23D1E2). So I
> assumed. :/
>
> Ying Fang: in the future, please only paste actual logs. If you edit the
> log, you may render it useless. In this instance, you managed to edit
> out a relatively important log detail.

Thanks, I will follow your guide.

>
> Thanks, Ard!
> Laszlo
>
>

Many Thanks.
Ying Fang.

>
>
>


Re: [PATCH] MdeModulePkg/UefiBootManagerLib: Put BootMenu at the end of BootOrder

Li, Walon
 

Hi Liming,

As edk2 design, any new boot options should be put at the end of BootOrder because these are NEW . That means system should "append" BootOrder instead of override original order.
For example, if system has three boot options currently - Boot0001, Boot0002, Boot0003 and then one new option - Boot0000 will be added. The order should become Boot0001,Boot0002,Boot0003,Boot0000. However, in this case, BootmanagerMenu doesn't follow this rule. We set "zero" priority so system would put BootManagerMenu boot option at start.
This case is a corner case because the symptom only be gotten when user delete BootManagerMenu on OS or EFI shell. But it's a possible case. For keeping behavior consistent, we should keep BootManagerMenu option behavior as same as others boot option.

Thanks
Walon

-----Original Message-----
From: gaoliming <gaoliming@byosoft.com.cn>
Sent: Friday, February 19, 2021 8:59 AM
To: devel@edk2.groups.io; Li, Walon <walon.li@hpe.com>
Cc: Wang, Sunny (HPS SW) <sunnywang@hpe.com>; lersek@redhat.com; ray.ni@intel.com; hao.a.wu@intel.com
Subject: 回复: [edk2-devel] [PATCH] MdeModulePkg/UefiBootManagerLib: Put BootMenu at the end of BootOrder

Walon:
Can you specify the detail reason why BootManagerMenu should be placed at end of BootOrder?

Thanks
Liming
-----邮件原件-----
发件人: bounce+27952+71766+4905953+8761045@groups.io
<bounce+27952+71766+4905953+8761045@groups.io> 代表 Li, Walon
发送时间: 2021年2月18日 11:26
收件人: devel@edk2.groups.io
抄送: walon.li@hpe.com; sunnywang@hpe.com; lersek@redhat.com;
ray.ni@intel.com; hao.a.wu@intel.com
主题: [edk2-devel] [PATCH] MdeModulePkg/UefiBootManagerLib: Put BootMenu
at the end of BootOrder

REF:INVALID URI REMOVED
ocore.org_show-5Fbug.cgi-3Fid-3D3135&d=DwIFbw&c=C5b8zRQO1miGmBeVZ2LFWg
&r=nGx4G_nX3rQG_ai3uSb52w&m=4xka-z98KYmCRK888F4f_O1i7tKha1xqkOolDMIoMN
w&s=G7KN5FPIan9u09Esxr73N0cT6RHiEP7pdQQqikPiss4&e=

When Boot Menu does not exist in the BootOrder,
BmRegisterBootManagerMenu will create one into list. However, it
should be put at the "end" of BootOrder instead of "start" of
BootOrder. Replace 0 by -1 to adjust order of load options.

Signed-off-by: Walon Li <walon.li@hpe.com>
---
MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index aff620ad52..26d1fb0ea0 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -2505,7 +2505,7 @@ BmRegisterBootManagerMenu (
EfiBootManagerFreeLoadOptions (BootOptions, BootOptionCount);

);



- return EfiBootManagerAddLoadOptionVariable (BootOption, 0);

+ return EfiBootManagerAddLoadOptionVariable (BootOption, (UINTN)
+ -1));

}



/**

--
2.23.0.windows.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#71766):
INVALID URI REMOVED
devel_message_71766&d=DwIFbw&c=C5b8zRQO1miGmBeVZ2LFWg&r=nGx4G_nX3rQG_a
i3uSb52w&m=4xka-z98KYmCRK888F4f_O1i7tKha1xqkOolDMIoMNw&s=FNeonYnzA5fhg
h2S6hfP4kY5-gdgPq0eocZbLoguHso&e= Mute This Topic:
INVALID URI REMOVED
1971_4905953&d=DwIFbw&c=C5b8zRQO1miGmBeVZ2LFWg&r=nGx4G_nX3rQG_ai3uSb52
w&m=4xka-z98KYmCRK888F4f_O1i7tKha1xqkOolDMIoMNw&s=PHg6v0w7mvUp-SA38Cx9
dzS9IaedUWvbERQszTLJ3w0&e= Group Owner: devel+owner@edk2.groups.io
Unsubscribe:
INVALID URI REMOVED
devel_unsub&d=DwIFbw&c=C5b8zRQO1miGmBeVZ2LFWg&r=nGx4G_nX3rQG_ai3uSb52w
&m=4xka-z98KYmCRK888F4f_O1i7tKha1xqkOolDMIoMNw&s=wDph98KE_DgEz55q-XSWy
-RmRDLGolPPOyZFgp01r0Y&e=
[gaoliming@byosoft.com.cn]
-=-=-=-=-=-=


回复: 回复: [edk2-devel] [PATCH v4 13/14] MdeModulePkg/VariableStandaloneMm: Set PcdFlashNvStorageVariableBase to Pcd

gaoliming
 

Ilias:
If you check other Variable module INF file, you can find they all use [Pcd] section. Module provides the flexibility instead of the limitation. In fact, variable module code has no fixed pcd usage. Platform can decide which PCD type should be used. In future, if other PCD is required to be configured as patchable in module, you don't need to modify variable INF again.

Thanks
Liming

-----邮件原件-----
发件人: Ilias Apalodimas <ilias.apalodimas@linaro.org>
发送时间: 2021年2月18日 17:17
收件人: devel@edk2.groups.io; gaoliming@byosoft.com.cn
抄送: sughosh.ganu@linaro.org; 'Sami Mujawar' <sami.mujawar@arm.com>;
'Ard Biesheuvel' <ardb+tianocore@kernel.org>
主题: Re: 回复: [edk2-devel] [PATCH v4 13/14]
MdeModulePkg/VariableStandaloneMm: Set PcdFlashNvStorageVariableBase
to Pcd

On Thu, Feb 18, 2021 at 11:13:21AM +0800, gaoliming wrote:
I suggest to directly change [FixedPcd] to [Pcd] section. All Pcds can
support FixedAtBuild and PatchableInModule.
We can, but is there a reason to do that?
Wouldn't we be better of being more strict on the Pcd context we define for
each variable?

The values that were swapped from FixedPcd to Pcd are expected to change
in
runtime, while the rest don't.

Thanks
/Ilias


With this change, Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>

Thanks
Liming
-----邮件原件-----
发件人: bounce+27952+71734+4905953+8761045@groups.io
<bounce+27952+71734+4905953+8761045@groups.io> 代表 Sughosh
Ganu
发送时间: 2021年2月17日 19:27
收件人: devel@edk2.groups.io
抄送: Sami Mujawar <sami.mujawar@arm.com>; Ilias Apalodimas
<ilias.apalodimas@linaro.org>; Ard Biesheuvel
<ardb+tianocore@kernel.org>
主题: [edk2-devel] [PATCH v4 13/14]
MdeModulePkg/VariableStandaloneMm:
Set PcdFlashNvStorageVariableBase to Pcd

From: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Instead of running StMM in SPM, OP-TEE creates a new secure partition,
which emulates SPM and isolates StMM from the rest of the Trusted
Applications (TAs). We can then compile StMM as an FD image and run it
in OP-TEE. With the addition of a new RPMB driver, we can leverage
OP-TEE
and store variables to an RPMB device.

Since EDK2 upper layers expect byte addressable code, for the RPMB to
work, we need to allocate memory and sync it with the hardware on
read/writes. Since DynamicPCDs are not supported in that context we
can only use PatchablePCDs. So let's switch them to Pcd instead of
FixedPcd and accomodate the new driver.

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
---

Changes since V3: None

MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
| 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git
a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.in
f
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.in
f
index fada0bf3c5..2a25fbdada 100644
---
a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.in
f
+++
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.in
f
@@ -119,10 +119,12 @@
## SOMETIMES_PRODUCES ## Variable:L"VarErrorFlag"
gEdkiiVarErrorFlagGuid

-[FixedPcd]
- gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
## CONSUMES
+[Pcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase
## SOMETIMES_CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
## CONSUMES
+ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
## CONSUMES
+
+[FixedPcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize
## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize
## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVolatileVariableSize
## CONSUMES
--
2.17.1











回复: [edk2-devel] [PATCH] MdeModulePkg/UefiBootManagerLib: Put BootMenu at the end of BootOrder

gaoliming
 

Walon:
Can you specify the detail reason why BootManagerMenu should be placed at
end of BootOrder?

Thanks
Liming

-----邮件原件-----
发件人: bounce+27952+71766+4905953+8761045@groups.io
<bounce+27952+71766+4905953+8761045@groups.io> 代表 Li, Walon
发送时间: 2021年2月18日 11:26
收件人: devel@edk2.groups.io
抄送: walon.li@hpe.com; sunnywang@hpe.com; lersek@redhat.com;
ray.ni@intel.com; hao.a.wu@intel.com
主题: [edk2-devel] [PATCH] MdeModulePkg/UefiBootManagerLib: Put
BootMenu at the end of BootOrder

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

When Boot Menu does not exist in the BootOrder,
BmRegisterBootManagerMenu
will create one into list. However, it should be put at the "end" of
BootOrder instead of "start" of BootOrder. Replace 0 by -1 to adjust
order of load options.

Signed-off-by: Walon Li <walon.li@hpe.com>
---
MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
index aff620ad52..26d1fb0ea0 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
@@ -2505,7 +2505,7 @@ BmRegisterBootManagerMenu (
EfiBootManagerFreeLoadOptions (BootOptions, BootOptionCount);

);



- return EfiBootManagerAddLoadOptionVariable (BootOption, 0);

+ return EfiBootManagerAddLoadOptionVariable (BootOption, (UINTN) -1));

}



/**

--
2.23.0.windows.1



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#71766): https://edk2.groups.io/g/devel/message/71766
Mute This Topic: https://groups.io/mt/80721971/4905953
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub
[gaoliming@byosoft.com.cn]
-=-=-=-=-=-=


Re: [PATCH 1/2] MdeModulePkg/Core/Dxe: Allow to force runtime allocations at separate range

Michael D Kinney
 

Hi Alex,

This feature is already available from the DXE Core using the MemoryTypeInformation and was
specifically added to support hibernation use case.

There is an optional HOB that is passed into DXE Core that can provide bin sizes for any supported memory types. Not just Runtime and ACPI.

This feature can use a fixed HOB or use a dynamic HOB from a UEFI Variable, so that changes in the memory usage of
the critical memory types for hibernation can be tracked and stored in the UEFI Variables and be used to populate
the HOB. It is a platform choice to use fixed or dynamic HOB.

https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Include/Guid/MemoryTypeInformation.h

https://github.com/tianocore/edk2/blob/978b9d511f5b9cb7bc5b09749f86c39bec51525d/MdeModulePkg/Core/Dxe/Gcd/Gcd.c#L2233

https://github.com/tianocore/edk2/blob/978b9d511f5b9cb7bc5b09749f86c39bec51525d/MdeModulePkg/Core/Dxe/Mem/Page.c#L45

The DXE Core use the HOB to pre-allocate bins for the memory types and do allocations from those bins.

The UEFI Memory Map provides an entry for the entire bin (no just the allocated space), so small
differences in allocations from boot to boot do not change the UEFI memory map. This also
reduces the total number of memory map entries in the UEFI memory map.

If dynamic HOB is used, then the Boot Manager compares the actual memory usage to the HOB.
If the usage is larger or smaller by more than a threshold, then the UEFI Variable is
updated. The platform has the choice to reboot or continue booting after this UEIF Variable
update based on a PCD. The reboot can help make sure the first boot to the OS has the right
bin sizes to support future hibernate boot flows.


Mike

-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Alexander Graf via groups.io
Sent: Thursday, February 18, 2021 12:10 PM
To: devel@edk2.groups.io
Cc: Leif Lindholm <leif@nuviainc.com>; Laszlo Ersek <lersek@redhat.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>;
Justen, Jordan L <jordan.l.justen@intel.com>; Woodhouse, David <dwmw@amazon.co.uk>; Hendrik Borghorst <hborghor@amazon.de>
Subject: [edk2-devel] [PATCH 1/2] MdeModulePkg/Core/Dxe: Allow to force runtime allocations at separate range

Operating Systems that get hibernated expect all non-boot-time allocations
to be identical before and after hibernation.

In edk2, we create pools and allocate pages starting from the highest
allowed address for the allocation, usually 0xFFFFFFFF. Typically, that
means we allocate a few pages of boot time data, then a few pages of
runtime data, then another few pages of boot time data and again runtime
data. Every allocation has direct impact on the following allocations.

The problem with this scheme is that small code changes in boot time code
already can have significant impact on runtime allocations, which then
break hibernation.

This patch adds a mechanism to override the MaxAddress for runtime
allocations with a target defined Pcd value. With this feature enabled,
we can have different allocation ranges for runtime and boot time
allocations.

This allows us to determine at boot time whether to load an old,
hibernation compatible runtime allocation path or a new, hibernation
unsafe runtime allocation. All within the same edk2 target binary.
It also allows us to modify boot time behavior, such as modifying
buffer allocation mechanisms without compromising on hibernation safety.

Signed-off-by: Alexander Graf <graf@amazon.com>
---
MdeModulePkg/Core/Dxe/DxeMain.inf | 4 +++
MdeModulePkg/Core/Dxe/Mem/Page.c | 70 +++++++++++++++++++++++++++++++++++++++
MdeModulePkg/MdeModulePkg.dec | 16 +++++++++
MdeModulePkg/MdeModulePkg.uni | 12 +++++++
4 files changed, 102 insertions(+)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf b/MdeModulePkg/Core/Dxe/DxeMain.inf
index e4bca89577..0696246970 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.inf
+++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
@@ -186,6 +186,10 @@
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdFwVolDxeMaxEncapsulationDepth ## CONSUMES
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIReclaimMemory ## CONSUMES
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIMemoryNVS ## CONSUMES
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesCode ## CONSUMES
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesData ## CONSUMES

# [Hob]
# RESOURCE_DESCRIPTOR ## CONSUMES
diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index 731bf08bc9..91599adccb 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -1007,6 +1007,74 @@ CoreUpdateMemoryAttributes (
CoreReleaseMemoryLock ();
}

+UINT64
+EnforceMaxAddress (
+ IN UINT64 MaxAddress,
+ IN EFI_MEMORY_TYPE NewType,
+ IN UINT64 NumberOfPages
+ )
+{
+ UINT64 NumberOfBytes = LShiftU64 (NumberOfPages, EFI_PAGE_SHIFT);
+ UINT64 LowestPossible = MaxAddress;
+ UINT64 ForceMaxAddress;
+ LIST_ENTRY *Link;
+ MEMORY_MAP *Entry;
+
+ switch (NewType) {
+ case EfiACPIReclaimMemory:
+ ForceMaxAddress = PcdGet64(PcdEnforceMaxACPIReclaimMemory);
+ break;
+ case EfiACPIMemoryNVS:
+ ForceMaxAddress = PcdGet64(PcdEnforceMaxACPIMemoryNVS);
+ break;
+ case EfiRuntimeServicesCode:
+ ForceMaxAddress = PcdGet64(PcdEnforceMaxEfiRuntimeServicesCode);
+ break;
+ case EfiRuntimeServicesData:
+ ForceMaxAddress = PcdGet64(PcdEnforceMaxEfiRuntimeServicesData);
+ break;
+ default:
+ ForceMaxAddress = MaxAddress;
+ break;
+ }
+
+ //
+ // The currently requested address already fits our forced max constraint?
+ // Great, let's use that then.
+ //
+ if (ForceMaxAddress >= MaxAddress) {
+ return MaxAddress;
+ }
+
+ //
+ // Check if the allocation would fit. If not, don't force it.
+ //
+ for (Link = gMemoryMap.ForwardLink; Link != &gMemoryMap; Link = Link->ForwardLink) {
+ Entry = CR (Link, MEMORY_MAP, Link, MEMORY_MAP_SIGNATURE);
+
+ //
+ // If it's not a free entry, don't bother with it
+ //
+ if (Entry->Type != EfiConventionalMemory) {
+ continue;
+ }
+
+ if ((Entry->Start < LowestPossible) &&
+ ((Entry->End - Entry->Start) >= NumberOfBytes)) {
+ LowestPossible = Entry->End;
+ }
+ }
+ DEBUG ((DEBUG_ERROR | DEBUG_PAGE, "Force=%lx Lowest=%lx Max=%lx\n", ForceMaxAddress, LowestPossible, MaxAddress));
+
+ //
+ // We don't have free RAM available in the desired target area? Bail out!
+ //
+ if (ForceMaxAddress < LowestPossible) {
+ return MaxAddress;
+ }
+
+ return ForceMaxAddress;
+}

/**
Internal function. Finds a consecutive free page range below
@@ -1041,6 +1109,8 @@ CoreFindFreePagesI (
LIST_ENTRY *Link;
MEMORY_MAP *Entry;

+ MaxAddress = EnforceMaxAddress(MaxAddress, NewType, NumberOfPages);
+
if ((MaxAddress < EFI_PAGE_MASK) ||(NumberOfPages == 0)) {
return 0;
}
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 1483955110..cbad48af5e 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -1535,6 +1535,22 @@
# @Prompt Maximum permitted FwVol section nesting depth (exclusive).
gEfiMdeModulePkgTokenSpaceGuid.PcdFwVolDxeMaxEncapsulationDepth|0x10|UINT32|0x00000030

+ ## Maximum address that a dynamic EfiACPIReclaimMemory allocation can be requested at
+ # @Prompt Maximum address for EfiACPIReclaimMemory allocations
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIReclaimMemory|0xFFFFFFFFFFFFFFFF|UINT64|0x30001016
+
+ ## Maximum address that a dynamic EfiACPIMemoryNVS allocation can be requested at
+ # @Prompt Maximum address for EfiACPIMemoryNVS allocations
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIMemoryNVS|0xFFFFFFFFFFFFFFFF|UINT64|0x30001017
+
+ ## Maximum address that a dynamic EfiRuntimeServicesCode allocation can be requested at
+ # @Prompt Maximum address for EfiRuntimeServicesCode allocations
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesCode|0xFFFFFFFFFFFFFFFF|UINT64|0x30001018
+
+ ## Maximum address that a dynamic EfiRuntimeServicesData allocation can be requested at
+ # @Prompt Maximum address for EfiRuntimeServicesData allocations
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesData|0xFFFFFFFFFFFFFFFF|UINT64|0x30001019
+
[PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
## This PCD defines the Console output row. The default value is 25 according to UEFI spec.
# This PCD could be set to 0 then console output would be at max column and max row.
diff --git a/MdeModulePkg/MdeModulePkg.uni b/MdeModulePkg/MdeModulePkg.uni
index ef9f4d97b9..0dc5c1960b 100644
--- a/MdeModulePkg/MdeModulePkg.uni
+++ b/MdeModulePkg/MdeModulePkg.uni
@@ -1330,3 +1330,15 @@
#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdPcieResizableBarSupport_HELP #language en-US "Indicates if the PCIe
Resizable BAR Capability Supported.<BR><BR>\n"
"TRUE - PCIe Resizable BAR
Capability is supported.<BR>\n"
"FALSE - PCIe Resizable BAR
Capability is not supported.<BR>"
+
+#string STR_gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIReclaimMemory_PROMPT #language en-US "Maximum address for
EfiACPIReclaimMemory allocations"
+#string STR_gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIReclaimMemory_HELP #language en-US "Maximum address that a
dynamic EfiACPIReclaimMemory allocation can be requested at"
+
+#string STR_gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIMemoryNVS_PROMPT #language en-US "Maximum address for
EfiACPIMemoryNVS allocations"
+#string STR_gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIMemoryNVS_HELP #language en-US "Maximum address that a
dynamic EfiACPIMemoryNVS allocation can be requested at"
+
+#string STR_gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesCode_PROMPT #language en-US "Maximum address
for EfiRuntimeServicesCode allocations"
+#string STR_gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesCode_HELP #language en-US "Maximum address that
a dynamic EfiRuntimeServicesCode allocation can be requested at"
+
+#string STR_gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesData_PROMPT #language en-US "Maximum address
for EfiRuntimeServicesData allocations"
+#string STR_gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesData_HELP #language en-US "Maximum address that
a dynamic EfiRuntimeServicesData allocation can be requested at"
--
2.16.4




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879







[PATCH 1/2] MdeModulePkg/Core/Dxe: Allow to force runtime allocations at separate range

Alexander Graf
 

Operating Systems that get hibernated expect all non-boot-time allocations
to be identical before and after hibernation.

In edk2, we create pools and allocate pages starting from the highest
allowed address for the allocation, usually 0xFFFFFFFF. Typically, that
means we allocate a few pages of boot time data, then a few pages of
runtime data, then another few pages of boot time data and again runtime
data. Every allocation has direct impact on the following allocations.

The problem with this scheme is that small code changes in boot time code
already can have significant impact on runtime allocations, which then
break hibernation.

This patch adds a mechanism to override the MaxAddress for runtime
allocations with a target defined Pcd value. With this feature enabled,
we can have different allocation ranges for runtime and boot time
allocations.

This allows us to determine at boot time whether to load an old,
hibernation compatible runtime allocation path or a new, hibernation
unsafe runtime allocation. All within the same edk2 target binary.
It also allows us to modify boot time behavior, such as modifying
buffer allocation mechanisms without compromising on hibernation safety.

Signed-off-by: Alexander Graf <graf@amazon.com>
---
MdeModulePkg/Core/Dxe/DxeMain.inf | 4 +++
MdeModulePkg/Core/Dxe/Mem/Page.c | 70 +++++++++++++++++++++++++++++++++++++++
MdeModulePkg/MdeModulePkg.dec | 16 +++++++++
MdeModulePkg/MdeModulePkg.uni | 12 +++++++
4 files changed, 102 insertions(+)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf b/MdeModulePkg/Core/Dxe/DxeMain.inf
index e4bca89577..0696246970 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.inf
+++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
@@ -186,6 +186,10 @@
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdCpuStackGuard ## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdFwVolDxeMaxEncapsulationDepth ## CONSUMES
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIReclaimMemory ## CONSUMES
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIMemoryNVS ## CONSUMES
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesCode ## CONSUMES
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesData ## CONSUMES

# [Hob]
# RESOURCE_DESCRIPTOR ## CONSUMES
diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index 731bf08bc9..91599adccb 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -1007,6 +1007,74 @@ CoreUpdateMemoryAttributes (
CoreReleaseMemoryLock ();
}

+UINT64
+EnforceMaxAddress (
+ IN UINT64 MaxAddress,
+ IN EFI_MEMORY_TYPE NewType,
+ IN UINT64 NumberOfPages
+ )
+{
+ UINT64 NumberOfBytes = LShiftU64 (NumberOfPages, EFI_PAGE_SHIFT);
+ UINT64 LowestPossible = MaxAddress;
+ UINT64 ForceMaxAddress;
+ LIST_ENTRY *Link;
+ MEMORY_MAP *Entry;
+
+ switch (NewType) {
+ case EfiACPIReclaimMemory:
+ ForceMaxAddress = PcdGet64(PcdEnforceMaxACPIReclaimMemory);
+ break;
+ case EfiACPIMemoryNVS:
+ ForceMaxAddress = PcdGet64(PcdEnforceMaxACPIMemoryNVS);
+ break;
+ case EfiRuntimeServicesCode:
+ ForceMaxAddress = PcdGet64(PcdEnforceMaxEfiRuntimeServicesCode);
+ break;
+ case EfiRuntimeServicesData:
+ ForceMaxAddress = PcdGet64(PcdEnforceMaxEfiRuntimeServicesData);
+ break;
+ default:
+ ForceMaxAddress = MaxAddress;
+ break;
+ }
+
+ //
+ // The currently requested address already fits our forced max constraint?
+ // Great, let's use that then.
+ //
+ if (ForceMaxAddress >= MaxAddress) {
+ return MaxAddress;
+ }
+
+ //
+ // Check if the allocation would fit. If not, don't force it.
+ //
+ for (Link = gMemoryMap.ForwardLink; Link != &gMemoryMap; Link = Link->ForwardLink) {
+ Entry = CR (Link, MEMORY_MAP, Link, MEMORY_MAP_SIGNATURE);
+
+ //
+ // If it's not a free entry, don't bother with it
+ //
+ if (Entry->Type != EfiConventionalMemory) {
+ continue;
+ }
+
+ if ((Entry->Start < LowestPossible) &&
+ ((Entry->End - Entry->Start) >= NumberOfBytes)) {
+ LowestPossible = Entry->End;
+ }
+ }
+ DEBUG ((DEBUG_ERROR | DEBUG_PAGE, "Force=%lx Lowest=%lx Max=%lx\n", ForceMaxAddress, LowestPossible, MaxAddress));
+
+ //
+ // We don't have free RAM available in the desired target area? Bail out!
+ //
+ if (ForceMaxAddress < LowestPossible) {
+ return MaxAddress;
+ }
+
+ return ForceMaxAddress;
+}

/**
Internal function. Finds a consecutive free page range below
@@ -1041,6 +1109,8 @@ CoreFindFreePagesI (
LIST_ENTRY *Link;
MEMORY_MAP *Entry;

+ MaxAddress = EnforceMaxAddress(MaxAddress, NewType, NumberOfPages);
+
if ((MaxAddress < EFI_PAGE_MASK) ||(NumberOfPages == 0)) {
return 0;
}
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 1483955110..cbad48af5e 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -1535,6 +1535,22 @@
# @Prompt Maximum permitted FwVol section nesting depth (exclusive).
gEfiMdeModulePkgTokenSpaceGuid.PcdFwVolDxeMaxEncapsulationDepth|0x10|UINT32|0x00000030

+ ## Maximum address that a dynamic EfiACPIReclaimMemory allocation can be requested at
+ # @Prompt Maximum address for EfiACPIReclaimMemory allocations
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIReclaimMemory|0xFFFFFFFFFFFFFFFF|UINT64|0x30001016
+
+ ## Maximum address that a dynamic EfiACPIMemoryNVS allocation can be requested at
+ # @Prompt Maximum address for EfiACPIMemoryNVS allocations
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIMemoryNVS|0xFFFFFFFFFFFFFFFF|UINT64|0x30001017
+
+ ## Maximum address that a dynamic EfiRuntimeServicesCode allocation can be requested at
+ # @Prompt Maximum address for EfiRuntimeServicesCode allocations
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesCode|0xFFFFFFFFFFFFFFFF|UINT64|0x30001018
+
+ ## Maximum address that a dynamic EfiRuntimeServicesData allocation can be requested at
+ # @Prompt Maximum address for EfiRuntimeServicesData allocations
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesData|0xFFFFFFFFFFFFFFFF|UINT64|0x30001019
+
[PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx]
## This PCD defines the Console output row. The default value is 25 according to UEFI spec.
# This PCD could be set to 0 then console output would be at max column and max row.
diff --git a/MdeModulePkg/MdeModulePkg.uni b/MdeModulePkg/MdeModulePkg.uni
index ef9f4d97b9..0dc5c1960b 100644
--- a/MdeModulePkg/MdeModulePkg.uni
+++ b/MdeModulePkg/MdeModulePkg.uni
@@ -1330,3 +1330,15 @@
#string STR_gEfiMdeModulePkgTokenSpaceGuid_PcdPcieResizableBarSupport_HELP #language en-US "Indicates if the PCIe Resizable BAR Capability Supported.<BR><BR>\n"
"TRUE - PCIe Resizable BAR Capability is supported.<BR>\n"
"FALSE - PCIe Resizable BAR Capability is not supported.<BR>"
+
+#string STR_gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIReclaimMemory_PROMPT #language en-US "Maximum address for EfiACPIReclaimMemory allocations"
+#string STR_gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIReclaimMemory_HELP #language en-US "Maximum address that a dynamic EfiACPIReclaimMemory allocation can be requested at"
+
+#string STR_gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIMemoryNVS_PROMPT #language en-US "Maximum address for EfiACPIMemoryNVS allocations"
+#string STR_gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIMemoryNVS_HELP #language en-US "Maximum address that a dynamic EfiACPIMemoryNVS allocation can be requested at"
+
+#string STR_gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesCode_PROMPT #language en-US "Maximum address for EfiRuntimeServicesCode allocations"
+#string STR_gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesCode_HELP #language en-US "Maximum address that a dynamic EfiRuntimeServicesCode allocation can be requested at"
+
+#string STR_gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesData_PROMPT #language en-US "Maximum address for EfiRuntimeServicesData allocations"
+#string STR_gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesData_HELP #language en-US "Maximum address that a dynamic EfiRuntimeServicesData allocation can be requested at"
--
2.16.4




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


[PATCH 2/2] OvmfPkg: Make hibernation critical allocations at own ranges

Alexander Graf
 

Now that we have a framework available to set memory ranges for
allocations that break hibernation if they move, let's push them
to their own respective memory ranges. This way, they will be
unaffected by boot time data allocation changes and we can thus
still resume hibernated systems.

Signed-off-by: Alexander Graf <graf@amazon.com>
---
OvmfPkg/OvmfPkgIa32.dsc | 6 ++++++
OvmfPkg/OvmfPkgIa32X64.dsc | 6 ++++++
OvmfPkg/OvmfPkgX64.dsc | 6 ++++++
3 files changed, 18 insertions(+)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 1b8d34052b..afea65254d 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -575,6 +575,12 @@
# Point to the MdeModulePkg/Application/UiApp/UiApp.inf
gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }

+ # Simplify hibernation safety by putting relevant data into its own memory ranges
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIReclaimMemory|0x19000000
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIMemoryNVS|0x19100000
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesCode|0x19200000
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesData|0x19300000
+
################################################################################
#
# Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 9c1aee87e7..4d1334554a 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -581,6 +581,12 @@
# Point to the MdeModulePkg/Application/UiApp/UiApp.inf
gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }

+ # Simplify hibernation safety by putting relevant data into its own memory ranges
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIReclaimMemory|0x19000000
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIMemoryNVS|0x19100000
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesCode|0x19200000
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesData|0x19300000
+
################################################################################
#
# Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index fabb8b2f29..22cdf71f1e 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -581,6 +581,12 @@
# Point to the MdeModulePkg/Application/UiApp/UiApp.inf
gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }

+ # Simplify hibernation safety by putting relevant data into its own memory ranges
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIReclaimMemory|0x19000000
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxACPIMemoryNVS|0x19100000
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesCode|0x19200000
+ gEfiMdeModulePkgTokenSpaceGuid.PcdEnforceMaxEfiRuntimeServicesData|0x19300000
+
################################################################################
#
# Pcd Dynamic Section - list of all EDK II PCD Entries defined by this Platform
--
2.16.4




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


[PATCH 0/2] Improve hibernation safety

Alexander Graf
 

Operating Systems that get hibernated expect all non-boot-time allocations
to be identical before and after hibernation.

In edk2, we create pools and allocate pages starting from the highest
allowed address for the allocation, usually 0xFFFFFFFF. Typically, that
means we allocate a few pages of boot time data, then a few pages of
runtime data, then another few pages of boot time data and again runtime
data. Every allocation has direct impact on the following allocations.

The problem with this scheme is that small code changes in boot time code
already can have significant impact on runtime allocations, which then
break hibernation.

This patch set adds a mechanism to set an upper bound to dynamic memory
allocations for different allocation types. This allows us to move data
that has to stay at the same place across firmware changes at the same
place. The patch set also enables this on OVMF by default.

Alex

Alexander Graf (2):
MdeModulePkg/Core/Dxe: Allow to force runtime allocations at separate
range
OvmfPkg: Make hibernation critical allocations at own ranges

MdeModulePkg/Core/Dxe/DxeMain.inf | 4 +++
MdeModulePkg/Core/Dxe/Mem/Page.c | 70 +++++++++++++++++++++++++++++++++++++++
MdeModulePkg/MdeModulePkg.dec | 16 +++++++++
MdeModulePkg/MdeModulePkg.uni | 12 +++++++
OvmfPkg/OvmfPkgIa32.dsc | 6 ++++
OvmfPkg/OvmfPkgIa32X64.dsc | 6 ++++
OvmfPkg/OvmfPkgX64.dsc | 6 ++++
7 files changed, 120 insertions(+)

--
2.16.4




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879


Re: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

Jeremy Linton
 

Hi,

On 2/18/21 10:52 AM, Ard Biesheuvel wrote:
On Thu, 18 Feb 2021 at 17:47, Jeremy Linton <jeremy.linton@arm.com> wrote:

Hi,

On 2/17/21 11:57 AM, Ard Biesheuvel wrote:
On Wed, 17 Feb 2021 at 18:16, Jeremy Linton <jeremy.linton@arm.com> wrote:

Hi,

On 2/17/21 1:55 AM, Ard Biesheuvel via groups.io wrote:
On Wed, 17 Feb 2021 at 08:30, Jeremy Linton <jeremy.linton@arm.com> wrote:

Hi,

On 2/17/21 12:56 AM, Ard Biesheuvel wrote:
On Wed, 17 Feb 2021 at 07:18, jlinton <lintonrjeremy@gmail.com> wrote:

From: Jeremy Linton <jeremy.linton@arm.com>

The existing RPi3 ACPI entries for the Arasan
and SDHCI controllers need updating to work
with the RPi4. This is done by adding a caps
override for the legacy Arasan controller and
then adding an entirely new entry for the newer
eMMC2 controller.

Then we flip the default routing to make the eMMC2
the default for the SD card, so that the WiFi can
start working on the Arasan.

Additional we add a menu item to enable the SDMA/ADMA2
modes on the controller.

v2->v3: Various small review tweaks, whitespace, wording
spelling, etc.
What happened to the IORT change? Don't we need that to ensure that
Linux sizes ZONE_DMA appropriately?
Ha, I gave up! There are more important things to fix, especially when I
found another case that couldn't just be fixed by the IORT tweaking
without more kernel patches.
Which case is that?
Some of these firmware/board revisions appear to need the 3G
translation. The EMMC seems to be one of the devices who's DT
descriptions are being modified by the lower level firmware (like the PCI).
Considering that the reason for the 1 GB device limit is the -3 GB DMA
translation, I'd assume that the former and the latter apply to the
same set of peripherals.

But are you saying the dma-ranges properties are manipulated by the VC
firmware? Or other DT properties related to DMA translation?
Yes, Its changing dma-range property associated with the emmc in the DT
its being handed which is then shared with atf/etc.
But the translation is always the same, no?
No, the newer SOC with the newer (broken xhci) firmware does away with it, and widens the window. I haven't tried the newer SOC with the experimental firmware that now boots uefi except to validate that the emmc works in PIO mode. It might "just work" with DMA enabled, but in that case we should probably do a SOC detection and flip the PIO/DMA default, but that needs to be done with the pi400 or an actual released product rather than this "special" one off device I have.







The default in this set is PIO mode, no DMA, same as the Arasan. If I
get motivated (or someone else does) they can pick up the pieces to
finish turning the DMA on in linux. It also simplifies that IORT disable
patch I posted separately since I don't have to worry about enabling it
for a limit <2G.
But having a 1 GB limit for only the eMMC2 in the IORT and a matching
_DMA method in its container should not trigger this error, I'd
assume.
Well with stock linux, the device will configure, startup and corrupt data.
By 'this error', I mean the splat resulting from mismatching DMA
limits for XHCI between IORT and _DMA.
No, I don't see that. The PCI/XHCI is fine with the IORT changes.
Then why do you need
[PATCH v2] Platform/RaspberryPi: Only enable IORT when 3G limit is disabled
?
Oh, I guess I misunderstood what you were asking since this set is no longer dependent on the IORT change. I thought you were asking if the XHCI was having issues with the IORT when it had a 1G limit?

So the answer should have been depends on the kernel.

The older kernels don't work with SD/Wifi since we aren't using the standard pnp ID, but they have problems with the IORT regardless of of what its limits are when a device tries to use a buffer that exists between the 1G/2G IORT and the 3G mem limit.

The newer kernel's WRT the IORT don't care what the limit is, but we would have needed to have the IORT in place even with the 3G limit applied to assure the SD/Wifi work. Its this latter case that influenced the original version of that patch which tied the IORT directly to the mem limit, and would have required the user to lift the 3G limit on a 2G device to enable the IORT.

All these flags and options are failing KISS and part of the reason I think the PIO is a reasonable choice. Lets start with the lowest common denominator, and then worry about getting fancy.









Is the reason for the data corruption understood?
It runs but appears to the address translation portion doesn't get
applied (the command rings appear to be ok/etc) to FS buffers reliably
so garbage gets written to the disk as the wrong bus locations get used.
Its somewhat odd because at a first glance the directory structure/etc
come back so if one just mounts the FS and ls's it, then unmounts it all
appears to be ok. The first indications something is wrong are usually
FS corruption messages. I have an instrumented sdhci/etc driver
splatting on addrs > 1G so that all looks ok.




The sdhci_caps_mask choice is what flags the device as not supporting
DMA modes unless the user enables it. Yes this hurts perf, but not
nearly as badly as disabling UHS mode because we can't lower the card
voltage with the standard sdhci registers (rather having to depend on a
nonstandard rpi mailbox call which isn't available without a _DSM() or
something equally undesirable).
Are you saying switching to the Arasan disabled UHS mode, and this is
why this is an improvement nonetheless?
? I'm not sure I understand. Right now in linux we don't have SD or
wifi. With just the caps _DSD entry the arasan will configure but it
runs PIO mode all the time (including with DT). The cap is needed
because the arasan returns 0 in the standard SDHCI caps registers.

The emmc2 supports faster modes, but we can't easily switch the voltage
to support them because the standard voltage control registers aren't
wired correctly (AFAIK). Given the change detection doesn't work right
either (AFAIK), we could hack up the linux sdhci subsystem to not reset
the card at startup and leave faster cards at 1.8V, but that is uglier
than adding a _DSM() to forward the voltage change request to the rpi
mailbox. But again we are hacking up the iproc (or sdhci_acpi) driver.

IMHO, Given its just a perf thing, and this whole board is compromised
in so many ways, it just isn't worth trying to support low voltage/UHS.
Since the card is already running at the slower speeds, using PIO
instead of DMA isn't a huge hit.
I could also argue that PIO at low speeds is worse then PIO at high
speeds, given that the CPU will be tied up for longer to transfer the
same amount of data. >
So then we don't have to have a 1G
IORT, or dynamic _DMA translation.
Yes, that is obviously a win.

But this set is about enabling both the SD and WiFi. The latter requires
the SD to be bound to the emmc2. At the moment there isn't much in the
way of a perf advantage to switching the SD from the Arasan to the
emmc2, the benefit comes from being able to use the wifi..

Fair enough. I'm just slightly disappointed that we cannot use the
eMMC2 in DMA mode even for the lower speed, but I guess it is not the
end of the world.
Well its never done, at some point it can be revisited to make it
faster. Maybe someone will come up with a clever way to do the voltage
switching too. The platform has an easy way to trap to el3, but I can't
see how to utilize that without sdhci driver changes at the moment.


If everyone else is on board with this approach, I'll pick these up tomorrow.

Thanks,
Ard.


Re: [PATCH v1 01/10] Silicon/Phytium: Added PlatformLib to FT2000/4

Leif Lindholm
 

Hi Ling,

My comments are included inline in the replies, please scroll down to find them.

I had some minor further comments on some of the early patches, and some more detailed comments on things like the flash driver that I did not review for v1.
For any patches where I added
Reviewed-by: Leif Lindholm <leif@...>
please include this in the commit message of that patch for v3, just below your Signed-off-by. That patch is now considered done.

When there are no further comments below, I end with:

/
    Leif

Just like here :)



On Thu, Feb 18, 2021 at 2:47 AM 贾玲 <jialing@...> wrote:
Hi Leif,

Thank you for your reply.  I'm glad to hear from you!

I received a total of ten replies, and the contents of the reply seems to be quoted from the original. Is there any problems with our code submission? Please advise us what to do next. Thank you very much!

Best Regards,

Ling


> -----原始邮件-----
> 发件人: "Leif Lindholm" <leif@...>
> 发送时间: 2021-02-10 23:24:45 (星期三)
> 收件人: "Ling Jia" <jialing@...>
> 抄送: devel@edk2.groups.io
> 主题: Re: [PATCH v1 01/10] Silicon/Phytium: Added PlatformLib to FT2000/4
>
> On Fri, Feb 05, 2021 at 18:06:21 +0800, Ling Jia wrote:
> > The PlatformLib supported the system
> > library for FT2000/4 chip.
> > Platform/Phytium: Added the dsc and fdf files of DurianPkg.
> >
> > Signed-off-by: Ling Jia <jialing@...>
> > ---
> >  Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec                           |  41 +++
> >  Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dsc.inc                       | 345 ++++++++++++++++++++
> >  Platform/Phytium/DurianPkg/DurianPkg.dsc                                        | 278 ++++++++++++++++
> >  Platform/Phytium/DurianPkg/DurianPkg.fdf                                        | 199 +++++++++++
> >  Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.inf                 |  55 ++++
> >  Silicon/Phytium/PhytiumCommonPkg/Include/SystemServiceInterface.h               | 112 +++++++
> >  Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.c                   | 137 ++++++++
> >  Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLibMem.c                | 156 +++++++++
> >  Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/AArch64/PhytiumPlatformHelper.S |  76 +++++
> >  Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.fdf.inc                       | 119 +++++++
> >  10 files changed, 1518 insertions(+)
> >
> > diff --git a/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec b/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec
> > new file mode 100644
> > index 000000000000..48f430c88de6
> > --- /dev/null
> > +++ b/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec
> > @@ -0,0 +1,41 @@
> > +## @file
> > +# This package provides common Phytium silicon modules.
> > +#
> > +# Copyright (C) 2020, Phytium Technology Co,Ltd. All rights reserved.
> > +#
> > +# SPDX-License-Identifier:BSD-2-Clause-Patent
> > +#
> > +##
> > +
> > +[Defines]
> > +  DEC_SPECIFICATION              = 0x0001001b
> > +  PACKAGE_NAME                   = PhytiumCommnonPkg
> > +  PACKAGE_GUID                   = b34af0b4-3e7c-11eb-a9d0-0738806d2dec
> > +  PACKAGE_VERSION                = 0.1
> > +
> > +################################################################################
> > +#
> > +# Include Section - list of Include Paths that are provided by this package.
> > +#                   Comments are used for Keywords and Module Types.
> > +#
> > +# Supported Module Types:
> > +#  BASE SEC PEI_CORE PEIM DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER DXE_SMM_DRIVER DXE_SAL_DRIVER UEFI_DRIVER UEFI_APPLICATION
> > +#
> > +################################################################################
> > +[Includes]
> > +  Include             # Root include for the package
> > +
> > +[Guids.common]
> > +  gPhytiumPlatformTokenSpaceGuid = { 0x8c3abed4, 0x1fc8, 0x46d3, { 0xb4, 0x17, 0xa3, 0x22, 0x38, 0x14, 0xde, 0x76 } }
> > +
> > +[PcdsFixedAtBuild.common]
> > +  gPhytiumPlatformTokenSpaceGuid.PcdSystemIoBase|0x0|UINT64|0x00000000
> > +  gPhytiumPlatformTokenSpaceGuid.PcdSystemIoSize|0x0|UINT64|0x00000001
> > +
> > +  #
> > +  # PCI configuration address space
> > +  #
> > +  gPhytiumPlatformTokenSpaceGuid.PcdPciConfigBase|0x0|UINT64|0x00000002
> > +  gPhytiumPlatformTokenSpaceGuid.PcdPciConfigSize|0x0|UINT64|0x00000003
> > +
> > +[Protocols]
> > diff --git a/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dsc.inc b/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dsc.inc
> > new file mode 100644
> > index 000000000000..121fe0e7c549
> > --- /dev/null
> > +++ b/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dsc.inc
> > @@ -0,0 +1,345 @@
> > +## @file
> > +# This package provides common open source Phytium silicon modules.
> > +#
> > +# Copyright (C) 2020, Phytium Technology Co, Ltd. All rights reserved.
> > +#
> > +# SPDX-License-Identifier:BSD-2-Clause-Patent
> > +#
> > +##
> > +
> > +
> > +[LibraryClasses.common]
> > +  #
> > +  # ARM Architectural Libraries
> > +  #
> > +  ArmDisassemblerLib|ArmPkg/Library/ArmDisassemblerLib/ArmDisassemblerLib.inf
> > +  ArmGicLib|ArmPkg/Drivers/ArmGic/ArmGicLib.inf
> > +  ArmGicArchLib|ArmPkg/Library/ArmGicArchLib/ArmGicArchLib.inf
> > +  ArmPlatformStackLib|ArmPlatformPkg/Library/ArmPlatformStackLib/ArmPlatformStackLib.inf
> > +  ArmSmcLib|ArmPkg/Library/ArmSmcLib/ArmSmcLib.inf
> > +  ArmGenericTimerCounterLib|ArmPkg/Library/ArmGenericTimerPhyCounterLib/ArmGenericTimerPhyCounterLib.inf
> > +  ArmMmuLib|ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf
> > +  ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
> > +
> > +  AcpiLib|EmbeddedPkg/Library/AcpiLib/AcpiLib.inf
> > +  AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
> > +
> > +  BaseLib|MdePkg/Library/BaseLib/BaseLib.inf
> > +  BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
> > +  BaseCryptLib|CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf
> > +  BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
> > +  BmpSupportLib|MdeModulePkg/Library/BaseBmpSupportLib/BaseBmpSupportLib.inf
> > +
> > +  CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
> > +  CpuLib|MdePkg/Library/BaseCpuLib/BaseCpuLib.inf
> > +  CpuExceptionHandlerLib|ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.inf
> > +  CacheMaintenanceLib|ArmPkg/Library/ArmCacheMaintenanceLib/ArmCacheMaintenanceLib.inf
> > +  CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
> > +  !if $(TARGET) == RELEASE
> > +    DebugLib|MdePkg/Library/BaseDebugLibNull/BaseDebugLibNull.inf
> > +  !else
> > +    DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> > +  !endif
> > +
> > +  DevicePathLib|MdePkg/Library/UefiDevicePathLib/UefiDevicePathLib.inf
> > +  DxeServicesTableLib|MdePkg/Library/DxeServicesTableLib/DxeServicesTableLib.inf
> > +  DebugPrintErrorLevelLib|MdePkg/Library/BaseDebugPrintErrorLevelLib/BaseDebugPrintErrorLevelLib.inf
> > +  DefaultExceptionHandlerLib|ArmPkg/Library/DefaultExceptionHandlerLib/DefaultExceptionHandlerLib.inf
> > +  DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
> > +  DebugAgentTimerLib|EmbeddedPkg/Library/DebugAgentTimerLibNull/DebugAgentTimerLibNull.inf
> > +  DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
> > +
> > +  FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
> > +  FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
> > +  FileHandleLib|MdePkg/Library/UefiFileHandleLib/UefiFileHandleLib.inf
> > +
> > +  HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> > +  HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
> > +  HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> > +
> > +  IoLib|MdePkg/Library/BaseIoLibIntrinsic/BaseIoLibIntrinsic.inf
> > +  IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
> > +
> > +  OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
> > +
> > +  PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
> > +  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
> > +  PeCoffGetEntryPointLib|MdePkg/Library/BasePeCoffGetEntryPointLib/BasePeCoffGetEntryPointLib.inf
> > +  PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf
> > +  PeCoffExtraActionLib|MdePkg/Library/BasePeCoffExtraActionLibNull/BasePeCoffExtraActionLibNull.inf
> > +  PlatformPeiLib|ArmPlatformPkg/PlatformPei/PlatformPeiLib.inf
> > +  PlatformSecureLib|SecurityPkg/Library/PlatformSecureLibNull/PlatformSecureLibNull.inf
> > +  PlatformBootManagerLib|ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
> > +  PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf
> > +
> > +  RngLib|MdePkg/Library/BaseRngLibTimerLib/BaseRngLibTimerLib.inf
> > +  ReportStatusCodeLib|MdePkg/Library/BaseReportStatusCodeLibNull/BaseReportStatusCodeLibNull.inf
> > +
> > +  SynchronizationLib|MdePkg/Library/BaseSynchronizationLib/BaseSynchronizationLib.inf
> > +  ShellLib|ShellPkg/Library/UefiShellLib/UefiShellLib.inf
> > +  SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
> > +  ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
> > +  SafeIntLib|MdePkg/Library/BaseSafeIntLib/BaseSafeIntLib.inf
> > +
> > +  TimerLib|ArmPkg/Library/ArmArchTimerLib/ArmArchTimerLib.inf
> > +  TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
> > +
> > +  UefiLib|MdePkg/Library/UefiLib/UefiLib.inf
> > +  UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
> > +  UefiDecompressLib|MdePkg/Library/BaseUefiDecompressLib/BaseUefiDecompressLib.inf
> > +  UefiRuntimeServicesTableLib|MdePkg/Library/UefiRuntimeServicesTableLib/UefiRuntimeServicesTableLib.inf
> > +  UefiBootServicesTableLib|MdePkg/Library/UefiBootServicesTableLib/UefiBootServicesTableLib.inf
> > +  UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf
> > +  UefiApplicationEntryPoint|MdePkg/Library/UefiApplicationEntryPoint/UefiApplicationEntryPoint.inf
> > +  UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
> > +  UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
> > +
> > +  VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
> > +  VariablePolicyHelperLib|MdeModulePkg/Library/VariablePolicyHelperLib/VariablePolicyHelperLib.inf
> > +
> > +  #
> > +  # Scsi Requirements
> > +  #
> > +  UefiScsiLib|MdePkg/Library/UefiScsiLib/UefiScsiLib.inf
> > +
> > +  #
> > +  # USB Requirements
> > +  #
> > +  UefiUsbLib|MdePkg/Library/UefiUsbLib/UefiUsbLib.inf
> > +
> > +  #
> > +  # Networking Requirements
> > +  #
> > +  DpcLib|NetworkPkg/Library/DxeDpcLib/DxeDpcLib.inf
> > +  IpIoLib|NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib.inf
> > +  NetLib|NetworkPkg/Library/DxeNetLib/DxeNetLib.inf
> > +  UdpIoLib|NetworkPkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf
> > +  HttpLib|NetworkPkg/Library/DxeHttpLib/DxeHttpLib.inf
> > +
> > +[LibraryClasses.common.SEC]
> > +  ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
> > +  DebugAgentLib|ArmPkg/Library/DebugAgentSymbolsBaseLib/DebugAgentSymbolsBaseLib.inf
> > +  ExtractGuidedSectionLib|EmbeddedPkg/Library/PrePiExtractGuidedSectionLib/PrePiExtractGuidedSectionLib.inf
> > +  LzmaDecompressLib|MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaCustomDecompressLib.inf
> > +  MemoryAllocationLib|EmbeddedPkg/Library/PrePiMemoryAllocationLib/PrePiMemoryAllocationLib.inf
> > +  HobLib|EmbeddedPkg/Library/PrePiHobLib/PrePiHobLib.inf
> > +  PrePiLib|EmbeddedPkg/Library/PrePiLib/PrePiLib.inf
> > +  PrePiHobListPointerLib|ArmPlatformPkg/Library/PrePiHobListPointerLib/PrePiHobListPointerLib.inf
> > +  PerformanceLib|MdeModulePkg/Library/PeiPerformanceLib/PeiPerformanceLib.inf
> > +
> > +[LibraryClasses.common.SEC, LibraryClasses.common.PEIM]
> > +  MemoryInitPeiLib|ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf
> > +
> > +[LibraryClasses.common.DXE_CORE]
> > +  DxeCoreEntryPoint|MdePkg/Library/DxeCoreEntryPoint/DxeCoreEntryPoint.inf
> > +  DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
> > +  ExtractGuidedSectionLib|MdePkg/Library/DxeExtractGuidedSectionLib/DxeExtractGuidedSectionLib.inf
> > +  HobLib|MdePkg/Library/DxeCoreHobLib/DxeCoreHobLib.inf
> > +  MemoryAllocationLib|MdeModulePkg/Library/DxeCoreMemoryAllocationLib/DxeCoreMemoryAllocationLib.inf
> > +  PerformanceLib|MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.inf
> > +
> > +[LibraryClasses.common.DXE_DRIVER]
> > +  DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
> > +  MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
> > +  SecurityManagementLib|MdeModulePkg/Library/DxeSecurityManagementLib/DxeSecurityManagementLib.inf
> > +  PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
> > +  VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLib.inf
> > +
> > +[LibraryClasses.common.UEFI_APPLICATION]
> > +  DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
> > +  HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
> > +  MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
> > +
> > +  #
> > +  # UiApp dependencies
> > +  #
> > +  FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
> > +  PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
> > +
> > +[LibraryClasses.common.UEFI_DRIVER]
> > +  ExtractGuidedSectionLib|MdePkg/Library/DxeExtractGuidedSectionLib/DxeExtractGuidedSectionLib.inf
> > +  PerformanceLib|MdeModulePkg/Library/DxePerformanceLib/DxePerformanceLib.inf
> > +  DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
> > +  MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
> > +
> > +[LibraryClasses.common.DXE_RUNTIME_DRIVER]
> > +  !if $(SECURE_BOOT_ENABLE) == TRUE
> > +    BaseCryptLib|CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf
> > +  !endif
> > +
> > +  CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
> > +
> > +  !if $(TARGET) != RELEASE
> > +    DebugLib|MdePkg/Library/DxeRuntimeDebugLibSerialPort/DxeRuntimeDebugLibSerialPort.inf
> > +  !endif
> > +
> > +  HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> > +  MemoryAllocationLib|MdePkg/Library/UefiMemoryAllocationLib/UefiMemoryAllocationLib.inf
> > +  ReportStatusCodeLib|MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/RuntimeDxeReportStatusCodeLib.inf
> > +  VariablePolicyLib|MdeModulePkg/Library/VariablePolicyLib/VariablePolicyLibRuntimeDxe.inf
> > +
> > +[LibraryClasses.AARCH64.DXE_RUNTIME_DRIVER]
> > +  EfiResetSystemLib|ArmPkg/Library/ArmPsciResetSystemLib/ArmPsciResetSystemLib.inf
> > +
> > +[LibraryClasses.ARM, LibraryClasses.AARCH64]
> > +  NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf
> > +
> > +  #
> > +  # Add support for GCC stack protector
> > +  #
> > +  NULL|MdePkg/Library/BaseStackCheckLib/BaseStackCheckLib.inf
> > +
> > +[LibraryClasses.common.UEFI_DRIVER, LibraryClasses.common.UEFI_APPLICATION, LibraryClasses.common.DXE_RUNTIME_DRIVER, LibraryClasses.common.DXE_DRIVER]
> > +  PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> > +
> > +[BuildOptions]
> > +  RVCT:RELEASE_*_*_CC_FLAGS  = -DMDEPKG_NDEBUG
> > +  GCC:RELEASE_*_*_CC_FLAGS  = -DMDEPKG_NDEBUG
> > +
> > +[BuildOptions.AARCH64.EDKII.DXE_RUNTIME_DRIVER]
> > +  GCC:*_*_AARCH64_DLINK_FLAGS = -z common-page-size=0x10000
> > +
> > +################################################################################
> > +#
> > +# Pcd Section - list of all EDK II PCD Entries defined by this Platform
> > +#
> > +################################################################################
> > +
> > +[PcdsFeatureFlag.common]
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
> > +  gArmTokenSpaceGuid.PcdArmGicV3WithV2Legacy|FALSE
> > +  gEfiMdePkgTokenSpaceGuid.PcdComponentNameDisable|FALSE
> > +  gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnosticsDisable|TRUE
> > +  gEfiMdePkgTokenSpaceGuid.PcdComponentName2Disable|TRUE
> > +  gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnostics2Disable|TRUE
> > +
> > +  gEmbeddedTokenSpaceGuid.PcdPrePiProduceMemoryTypeInformationHob|TRUE
> > +
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdTurnOffUsbLegacySupport|TRUE
> > +
> > +  # Use the Vector Table location in CpuDxe. We will not copy the Vector Table at PcdCpuVectorBaseAddress
> > +  gArmTokenSpaceGuid.PcdRelocateVectorTable|FALSE
> > +
> > +  gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultLangDeprecate|TRUE
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdInstallAcpiSdtProtocol|TRUE
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdPciBusHotplugDeviceSupport|FALSE
> > +
> > +[PcdsFixedAtBuild.common]
> > +  gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength|1000000
> > +  gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength|1000000
> > +  gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength|1000000
> > +  gEfiMdePkgTokenSpaceGuid.PcdSpinLockTimeout|10000000
> > +  gEfiMdePkgTokenSpaceGuid.PcdDebugClearMemoryValue|0xAF
> > +  gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|0
> > +  gEfiMdePkgTokenSpaceGuid.PcdPostCodePropertyMask|0
> > +  gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|320
> > +  gEfiNetworkPkgTokenSpaceGuid.PcdAllowHttpConnections|TRUE
> > +
> > +!if $(TARGET) == RELEASE
> > +  gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x21
> > +!else
> > +  gEfiMdePkgTokenSpaceGuid.PcdDebugPropertyMask|0x2f
> > +!endif
> > +
> > +  #  DEBUG_INIT      0x00000001  // Initialization
> > +  #  DEBUG_WARN      0x00000002  // Warnings
> > +  #  DEBUG_LOAD      0x00000004  // Load events
> > +  #  DEBUG_FS        0x00000008  // EFI File system
> > +  #  DEBUG_POOL      0x00000010  // Alloc & Free's
> > +  #  DEBUG_PAGE      0x00000020  // Alloc & Free's
> > +  #  DEBUG_INFO      0x00000040  // Verbose
> > +  #  DEBUG_DISPATCH  0x00000080  // PEI/DXE Dispatchers
> > +  #  DEBUG_VARIABLE  0x00000100  // Variable
> > +  #  DEBUG_BM        0x00000400  // Boot Manager
> > +  #  DEBUG_BLKIO     0x00001000  // BlkIo Driver
> > +  #  DEBUG_NET       0x00004000  // SNI Driver
> > +  #  DEBUG_UNDI      0x00010000  // UNDI Driver
> > +  #  DEBUG_LOADFILE  0x00020000  // UNDI Driver
> > +  #  DEBUG_EVENT     0x00080000  // Event messages
> > +  #  DEBUG_GCD       0x00100000  // Global Coherency Database changes
> > +  #  DEBUG_CACHE     0x00200000  // Memory range cachability changes
> > +  #  DEBUG_ERROR     0x80000000  // Error
> > +  gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel|0x80000046
> > +
> > +  gEfiMdePkgTokenSpaceGuid.PcdReportStatusCodePropertyMask|0x07
> > +
> > +  gEmbeddedTokenSpaceGuid.PcdTimerPeriod|200000
> > +
> > +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory|0
> > +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIMemoryNVS|0
> > +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiReservedMemoryType|0
> > +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesData|80
> > +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiRuntimeServicesCode|65
> > +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesCode|400
> > +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiBootServicesData|20000
> > +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderCode|20
> > +  gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiLoaderData|0
> > +
> > +  gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
> > +
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationChange|FALSE
> > +
> > +!if $(SECURE_BOOT_ENABLE) == TRUE
> > +  gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x04
> > +  gEfiSecurityPkgTokenSpaceGuid.PcdFixedMediaImageVerificationPolicy|0x04
> > +  gEfiSecurityPkgTokenSpaceGuid.PcdRemovableMediaImageVerificationPolicy|0x04
> > +!endif
> > +
> > +!if $(SECURE_BOOT_ENABLE) == TRUE
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x10000
> > +!else
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize|0x4000
> > +!endif
> > +
> > +  # Default platform supported RFC 4646 languages: English & French & Chinese Simplified.
> > +  # Default Value of PlatformLangCodes Variable.
> > +  gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultPlatformLangCodes|"en-US;zh-Hans"
> > +
> > +  # Default current RFC 4646 language: Chinese Simplified.
> > +  # Default Value of PlatformLang Variable.
> > +  gEfiMdePkgTokenSpaceGuid.PcdUefiVariableDefaultPlatformLang|"en-US"
> > +  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|4
> > +
> > +  #
> > +  # ACPI Table Version
> > +  #
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiExposedTableVersions|0x20
> > +
> > +  gArmPlatformTokenSpaceGuid.PL011UartInterrupt|67
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdSrIovSupport|FALSE
> > +
> > +[PcdsDynamicDefault.common.DEFAULT]
> > +  ## This PCD defines the video horizontal resolution.
> > +  #  This PCD could be set to 0 then video resolution could be at highest resolution.
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution|640
> > +  ## This PCD defines the video vertical resolution.
> > +  #  This PCD could be set to 0 then video resolution could be at highest resolution.
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution|480
> > +
> > +  ## This PCD defines the Console output row and the default value is 80 according to UEFI spec.
> > +  #  This PCD could be set to 0 then console output could be at max column and max row.
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdConOutColumn|128
> > +  ## This PCD defines the Console output column and the default value is 25 according to UEFI spec.
> > +  #  This PCD could be set to 0 then console output could be at max column and max row.
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdConOutRow|40
> > +
> > +  ## Specify the video horizontal resolution of text setup.
> > +  # @Prompt Video Horizontal Resolution of Text Setup
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoHorizontalResolution|640
> > +
> > +  ## Specify the video vertical resolution of text setup.
> > +  # @Prompt Video Vertical Resolution of Text Setup
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdSetupVideoVerticalResolution|480
> > +
> > +  ## Specify the console output column of text setup.
> > +  # @Prompt Console Output Column of Text Setup
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdSetupConOutColumn|128
> > +  ## Specify the console output row of text setup.
> > +  # @Prompt Console Output Row of Text Setup
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdSetupConOutRow|40
> > +
> > +  ## The number of seconds that the firmware will wait before initiating the original default boot selection.
> > +  #  A value of 0 indicates that the default boot selection is to be initiated immediately on boot.
> > +  #  The value of 0xFFFF then firmware will wait for user input before booting.
> > +  # @Prompt Boot Timeout (s)
> > +  gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut|5
> > diff --git a/Platform/Phytium/DurianPkg/DurianPkg.dsc b/Platform/Phytium/DurianPkg/DurianPkg.dsc
> > new file mode 100644
> > index 000000000000..55eafa2e3a83
> > --- /dev/null
> > +++ b/Platform/Phytium/DurianPkg/DurianPkg.dsc
> > @@ -0,0 +1,278 @@
> > +## @file
> > +# This package provides common open source Phytium Platform modules.
> > +#
> > +# Copyright (C) 2020, Phytium Technology Co, Ltd. All rights reserved.
> > +#
> > +# SPDX-License-Identifier:BSD-2-Clause-Patent
> > +#
> > +##
> > +
> > +################################################################################
> > +#
> > +# Defines Section - statements that will be processed to create a Makefile.
> > +#
> > +################################################################################
> > +[Defines]
> > +  PLATFORM_NAME                  = DurianPkg
> > +  PLATFORM_GUID                  = 8f7ac876-3e7c-11eb-86cb-33f68535d613
> > +  PLATFORM_VERSION               = 0.1
> > +  DSC_SPECIFICATION              = 0x0001001c
> > +  OUTPUT_DIRECTORY               = Build/$(PLATFORM_NAME)
> > +  SUPPORTED_ARCHITECTURES        = AARCH64
> > +  BUILD_TARGETS                  = DEBUG|RELEASE|NOOPT
> > +  SKUID_IDENTIFIER               = DEFAULT
> > +  FLASH_DEFINITION               = Platform/Phytium/DurianPkg/DurianPkg.fdf
> > +
> > +!include Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dsc.inc
> > +
> > +[LibraryClasses.common]
> > +  # Phytium Platform library
> > +  ArmPlatformLib|Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.inf
> > +
> > +  # PL011 UART Driver and Dependency Libraries
> > +  SerialPortLib|ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> > +  PL011UartClockLib|ArmPlatformPkg/Library/PL011UartClockLib/PL011UartClockLib.inf
> > +  PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf
> > +
> > +[LibraryClasses.common.DXE_DRIVER]
> > +
> > +
> > +################################################################################
> > +#
> > +# Pcd Section - list of all EDK II PCD Entries defined by this Platform
> > +#
> > +################################################################################
> > +[PcdsFixedAtBuild.common]
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVendor|L"Durian Platform"
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareVersionString|L"V1.0"
> > +
> > +  gArmTokenSpaceGuid.PcdVFPEnabled|1
> > +  gArmTokenSpaceGuid.PcdArmPrimaryCoreMask|0x101
> > +  gArmTokenSpaceGuid.PcdArmPrimaryCore|0x0
> > +  gArmPlatformTokenSpaceGuid.PcdCoreCount|4
> > +
> > +  #
> > +  # NV Storage PCDs.
> > +  #
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64|0xe00000
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize|0x00010000
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingBase64|0xe10000
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwWorkingSize|0x00010000
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareBase64|0xe20000
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageFtwSpareSize|0x00010000
> > +
> > +  # Size of the region used by UEFI in permanent memory (Reserved 64MB)
> > +  gArmPlatformTokenSpaceGuid.PcdSystemMemoryUefiRegionSize|0x04000000
> > +
> > +  #
> > +  # PL011 - Serial Terminal
> > +  #
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x28001000
> > +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth|0
> > +  gArmPlatformTokenSpaceGuid.PL011UartClkInHz|48000000
> > +  gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200
> > +
> > +  #
> > +  # ARM General Interrupt Controller
> > +  #
> > +  gArmTokenSpaceGuid.PcdGicDistributorBase|0x29900000
> > +  gArmTokenSpaceGuid.PcdGicRedistributorsBase|0x29980000
> > +  gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0x29c00000
> > +
> > +  # System IO space
> > +  gPhytiumPlatformTokenSpaceGuid.PcdSystemIoBase|0x0
> > +  gPhytiumPlatformTokenSpaceGuid.PcdSystemIoSize|0x40000000
> > +
> > +  #
> > +  # System Memory (2GB ~ 4GB - 64MB), the top 64MB is reserved for
> > +  # PBF(the processor basic firmware, Mainly deals the initialization
> > +  # of the chip).
> > +  #
> > +  gArmTokenSpaceGuid.PcdSystemMemoryBase|0x80000000
> > +  gArmTokenSpaceGuid.PcdSystemMemorySize|0x7B000000
> > +
> > +  # Stack Size
> > +  gArmPlatformTokenSpaceGuid.PcdCPUCorePrimaryStackSize|0x4000
> > +
> > +################################################################################
> > +#
> > +# Components Section - list of all EDK II Modules needed by this Platform
> > +#
> > +################################################################################
> > +[Components.common]
> > +  #
> > +  # PCD database
> > +  #
> > +  MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
> > +
> > +  ShellPkg/DynamicCommand/TftpDynamicCommand/TftpDynamicCommand.inf
> > +  ShellPkg/Application/Shell/Shell.inf {
> > +    <LibraryClasses>
> > +      ShellCommandLib|ShellPkg/Library/UefiShellCommandLib/UefiShellCommandLib.inf
> > +      NULL|ShellPkg/Library/UefiShellLevel2CommandsLib/UefiShellLevel2CommandsLib.inf
> > +      NULL|ShellPkg/Library/UefiShellLevel1CommandsLib/UefiShellLevel1CommandsLib.inf
> > +      NULL|ShellPkg/Library/UefiShellLevel3CommandsLib/UefiShellLevel3CommandsLib.inf
> > +      NULL|ShellPkg/Library/UefiShellDriver1CommandsLib/UefiShellDriver1CommandsLib.inf
> > +      NULL|ShellPkg/Library/UefiShellAcpiViewCommandLib/UefiShellAcpiViewCommandLib.inf
> > +      NULL|ShellPkg/Library/UefiShellDebug1CommandsLib/UefiShellDebug1CommandsLib.inf
> > +      NULL|ShellPkg/Library/UefiShellInstall1CommandsLib/UefiShellInstall1CommandsLib.inf
> > +      NULL|ShellPkg/Library/UefiShellNetwork1CommandsLib/UefiShellNetwork1CommandsLib.inf
> > +      HandleParsingLib|ShellPkg/Library/UefiHandleParsingLib/UefiHandleParsingLib.inf
> > +      PrintLib|MdePkg/Library/BasePrintLib/BasePrintLib.inf
> > +      BcfgCommandLib|ShellPkg/Library/UefiShellBcfgCommandLib/UefiShellBcfgCommandLib.inf
>
> Due to upstream changes in edk2, you now also need to add
>          OrderedCollectionLib|MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.inf
> in this location.
>
> With this:
> Reviewed-by: Leif Lindholm <leif@...>
>
> /
>     Leif
>
> > +  }
> > +
> > +  ArmPlatformPkg/PrePi/PeiMPCore.inf {
> > +    <LibraryClasses>
> > +      ArmLib|ArmPkg/Library/ArmLib/ArmBaseLib.inf
> > +  }
> > +
> > +  #
> > +  # Dxe core entry
> > +  #
> > +  MdeModulePkg/Core/Dxe/DxeMain.inf {
> > +    <LibraryClasses>
> > +      PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
> > +      NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32GuidedSectionExtractLib.inf
> > +  }
> > +
> > +  #
> > +  # DXE driver
> > +  #
> > +  MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
> > +  MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
> > +  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf {
> > +    <LibraryClasses>
> > +      NULL|MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf
> > +  }
> > +  MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
> > +
> > +  #
> > +  # Common Arm Timer and Gic Components
> > +  #
> > +  ArmPkg/Drivers/CpuDxe/CpuDxe.inf
> > +  ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
> > +  EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
> > +  ArmPkg/Drivers/TimerDxe/TimerDxe.inf
> > +
> > +  #
> > +  # security system
> > +  #
> > +  MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf {
> > +    <LibraryClasses>
> > +      NULL|SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.inf
> > +  }
> > +
> > +  #
> > +  # network,  mod for https boot.
> > +  #
> > +  NetworkPkg/SnpDxe/SnpDxe.inf
> > +  NetworkPkg/DpcDxe/DpcDxe.inf
> > +  NetworkPkg/MnpDxe/MnpDxe.inf
> > +  NetworkPkg/ArpDxe/ArpDxe.inf
> > +  NetworkPkg/Dhcp4Dxe/Dhcp4Dxe.inf
> > +  NetworkPkg/Ip4Dxe/Ip4Dxe.inf
> > +  NetworkPkg/Mtftp4Dxe/Mtftp4Dxe.inf
> > +  NetworkPkg/Udp4Dxe/Udp4Dxe.inf
> > +  NetworkPkg/VlanConfigDxe/VlanConfigDxe.inf
> > +
> > +  NetworkPkg/Ip6Dxe/Ip6Dxe.inf
> > +  NetworkPkg/Udp6Dxe/Udp6Dxe.inf
> > +  NetworkPkg/Dhcp6Dxe/Dhcp6Dxe.inf
> > +  NetworkPkg/Mtftp6Dxe/Mtftp6Dxe.inf
> > +  NetworkPkg/TcpDxe/TcpDxe.inf
> > +
> > +  NetworkPkg/UefiPxeBcDxe/UefiPxeBcDxe.inf
> > +
> > +  NetworkPkg/DnsDxe/DnsDxe.inf
> > +  NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesDxe.inf
> > +  NetworkPkg/HttpDxe/HttpDxe.inf
> > +
> > +  #
> > +  # FV Filesystem
> > +  #
> > +  MdeModulePkg/Universal/FvSimpleFileSystemDxe/FvSimpleFileSystemDxe.inf
> > +
> > +  #
> > +  # Common Console Components
> > +  # ConIn,ConOut,StdErr
> > +  MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
> > +  MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
> > +  MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
> > +  MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
> > +  MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
> > +
> > +  SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
> > +
> > +  #
> > +  # Hii database init
> > +  #
> > +  MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
> > +
> > +  #
> > +  # FAT filesystem + GPT/MBR partitioning
> > +  #
> > +  MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
> > +  MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
> > +  MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
> > +  FatPkg/EnhancedFatDxe/Fat.inf
> > +
> > +  #
> > +  # Generic Watchdog Timer
> > +  #
> > +  ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
> > +
> > +  #
> > +  # Usb Support
> > +  #
> > +  MdeModulePkg/Bus/Pci/UhciDxe/UhciDxe.inf
> > +  MdeModulePkg/Bus/Pci/EhciDxe/EhciDxe.inf
> > +  MdeModulePkg/Bus/Pci/XhciDxe/XhciDxe.inf
> > +  MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
> > +  MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
> > +  MdeModulePkg/Bus/Usb/UsbMouseDxe/UsbMouseDxe.inf
> > +  MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
> > +
> > +  #
> > +  # IDE/AHCI Support
> > +  #
> > +  MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
> > +  MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
> > +  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
> > +  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
> > +  MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
> > +
> > +  #
> > +  # PCI Support
> > +  #
> > +  ArmPkg/Drivers/ArmPciCpuIo2Dxe/ArmPciCpuIo2Dxe.inf
> > +  MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
> > +
> > +  #
> > +  # The following 2 module perform the same work except one operate variable.
> > +  # Only one of both should be put into fdf.
> > +  #
> > +  MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
> > +
> > +  #
> > +  # NVME Support
> > +  #
> > +  MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
> > +
> > +
> > +  #
> > +  # Bds
> > +  #
> > +  MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> > +  MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
> > +  MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> > +  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
> > +  MdeModulePkg/Universal/DriverSampleDxe/DriverSampleDxe.inf
> > +  MdeModulePkg/Application/UiApp/UiApp.inf {
> > +    <LibraryClasses>
> > +      NULL|MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
> > +      NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
> > +      NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
> > +  }
> > +  MdeModulePkg/Application/BootManagerMenuApp/BootManagerMenuApp.inf
> > +
> > diff --git a/Platform/Phytium/DurianPkg/DurianPkg.fdf b/Platform/Phytium/DurianPkg/DurianPkg.fdf
> > new file mode 100644
> > index 000000000000..6470d53532df
> > --- /dev/null
> > +++ b/Platform/Phytium/DurianPkg/DurianPkg.fdf
> > @@ -0,0 +1,199 @@
> > +## @file
> > +# This package provides common open source Phytium Platform modules.
> > +#
> > +# Copyright (C) 2020, Phytium Technology Co, Ltd. All rights reserved.
> > +#
> > +# SPDX-License-Identifier:BSD-2-Clause-Patent
> > +#
> > +##
> > +
> > +################################################################################
> > +#
> > +# FD Section
> > +# The [FD] Section is made up of the definition statements and a
> > +# description of what goes into  the Flash Device Image.  Each FD section
> > +# defines one flash "device" image.  A flash device image may be one of
> > +# the following: Removable media bootable image (like a boot floppy
> > +# image,) an Option ROM image (that would be "flashed" into an add-in
> > +# card,) a System "Flash"  image (that would be burned into a system's
> > +# flash) or an Update ("Capsule") image that will be used to update and
> > +# existing system flash.
> > +#
> > +################################################################################
> > +
> > +[FD.PHYTIUM]
> > +BaseAddress   = 0x88000000|gArmTokenSpaceGuid.PcdFdBaseAddress
> > +Size          = 0x01000000|gArmTokenSpaceGuid.PcdFdSize
> > +ErasePolarity = 1
> > +
> > +# This one is tricky, it must be: BlockSize * NumBlocks = Size
> > +BlockSize     = 0x10000
> > +NumBlocks     = 0x100
> > +
> > +################################################################################
> > +#
> > +# Following are lists of FD Region layout which correspond to the locations of different
> > +# images within the flash device.
> > +#
> > +# Regions must be defined in ascending order and may not overlap.
> > +#
> > +# A Layout Region start with a eight digit hex offset (leading "0x" required) followed by
> > +# the pipe "|" character, followed by the size of the region, also in hex with the leading
> > +# "0x" characters. Like:
> > +# Offset|Size
> > +# PcdOffsetCName|PcdSizeCName
> > +# RegionType <FV, DATA, or FILE>
> > +#
> > +################################################################################
> > +
> > +0x00000000|0x200000
> > +gArmTokenSpaceGuid.PcdFvBaseAddress|gArmTokenSpaceGuid.PcdFvSize
> > +FV = FVMAIN_COMPACT
> > +
> > +################################################################################
> > +#
> > +# FV Section
> > +#
> > +# [FV] section is used to define what components or modules are placed within a flash
> > +# device file.  This section also defines order the components and modules are positioned
> > +# within the image.  The [FV] section consists of define statements, set statements and
> > +# module statements.
> > +#
> > +################################################################################
> > +
> > +[FV.FvMain]
> > +BlockSize          = 0x40
> > +NumBlocks          = 0         # This FV gets compressed so make it just big enough
> > +FvAlignment        = 16         # FV alignment and FV attributes setting.
> > +ERASE_POLARITY     = 1
> > +MEMORY_MAPPED      = TRUE
> > +STICKY_WRITE       = TRUE
> > +LOCK_CAP           = TRUE
> > +LOCK_STATUS        = TRUE
> > +WRITE_DISABLED_CAP = TRUE
> > +WRITE_ENABLED_CAP  = TRUE
> > +WRITE_STATUS       = TRUE
> > +WRITE_LOCK_CAP     = TRUE
> > +WRITE_LOCK_STATUS  = TRUE
> > +READ_DISABLED_CAP  = TRUE
> > +READ_ENABLED_CAP   = TRUE
> > +READ_STATUS        = TRUE
> > +READ_LOCK_CAP      = TRUE
> > +READ_LOCK_STATUS   = TRUE
> > +
> > +  APRIORI DXE {
> > +    INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
> > +  }
> > +
> > +  INF MdeModulePkg/Core/Dxe/DxeMain.inf
> > +  INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
> > +
> > +  #
> > +  # PI DXE Drivers producing Architectural Protocols (EFI Services)
> > +  #
> > +  INF MdeModulePkg/Core/RuntimeDxe/RuntimeDxe.inf
> > +  INF MdeModulePkg/Universal/SecurityStubDxe/SecurityStubDxe.inf
> > +  INF EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
> > +
> > +  INF MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
> > +  INF MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
> > +
> > +  INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
> > +  INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf
> > +  INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
> > +  INF ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
> > +
> > +  #
> > +  # Variable services
> > +  #
> > +  INF MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf
> > +  INF MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteDxe.inf
> > +
> > +  INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
> > +
> > +  #
> > +  # Multiple Console IO support
> > +  #
> > +  INF MdeModulePkg/Universal/Console/ConPlatformDxe/ConPlatformDxe.inf
> > +  INF MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
> > +  INF MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
> > +  INF MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
> > +  INF MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
> > +
> > +  #
> > +  # FAT filesystem + GPT/MBR partitioning
> > +  #
> > +  INF MdeModulePkg/Universal/Disk/DiskIoDxe/DiskIoDxe.inf
> > +  INF MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
> > +  INF FatPkg/EnhancedFatDxe/Fat.inf
> > +  INF MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
> > +
> > +  #
> > +  # SATA Controller
> > +  #
> > +  INF MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
> > +  INF MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
> > +  INF MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBusDxe.inf
> > +  INF MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf
> > +  INF MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
> > +
> > +  #
> > +  # NVMe boot devices
> > +  #
> > +  INF MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
> > +
> > +  #
> > +  # NetWork
> > +  #
> > +  INF NetworkPkg/SnpDxe/SnpDxe.inf
> > +  INF NetworkPkg/DpcDxe/DpcDxe.inf
> > +  INF NetworkPkg/MnpDxe/MnpDxe.inf
> > +  INF NetworkPkg/ArpDxe/ArpDxe.inf
> > +  INF NetworkPkg/Dhcp4Dxe/Dhcp4Dxe.inf
> > +  INF NetworkPkg/Ip4Dxe/Ip4Dxe.inf
> > +  INF NetworkPkg/Mtftp4Dxe/Mtftp4Dxe.inf
> > +  INF NetworkPkg/Udp4Dxe/Udp4Dxe.inf
> > +  INF NetworkPkg/VlanConfigDxe/VlanConfigDxe.inf
> > +
> > +  #
> > +  # UEFI applications
> > +  #
> > +  INF ShellPkg/Application/Shell/Shell.inf
> > +
> > +  #
> > +  # Bds
> > +  #
> > +  INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
> > +  INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
> > +  INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
> > +  INF MdeModulePkg/Universal/DriverSampleDxe/DriverSampleDxe.inf
> > +  INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
> > +  INF MdeModulePkg/Application/UiApp/UiApp.inf
> > +
> > +[FV.FVMAIN_COMPACT]
> > +FvAlignment        = 16
> > +ERASE_POLARITY     = 1
> > +MEMORY_MAPPED      = TRUE
> > +STICKY_WRITE       = TRUE
> > +LOCK_CAP           = TRUE
> > +LOCK_STATUS        = TRUE
> > +WRITE_DISABLED_CAP = TRUE
> > +WRITE_ENABLED_CAP  = TRUE
> > +WRITE_STATUS       = TRUE
> > +WRITE_LOCK_CAP     = TRUE
> > +WRITE_LOCK_STATUS  = TRUE
> > +READ_DISABLED_CAP  = TRUE
> > +READ_ENABLED_CAP   = TRUE
> > +READ_STATUS        = TRUE
> > +READ_LOCK_CAP      = TRUE
> > +READ_LOCK_STATUS   = TRUE
> > +
> > +  INF ArmPlatformPkg/PrePi/PeiMPCore.inf
> > +
> > +  FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
> > +    SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF PROCESSING_REQUIRED = TRUE {
> > +      SECTION FV_IMAGE = FVMAIN
> > +    }
> > +  }
> > +
> > +!include Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.fdf.inc
> > diff --git a/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.inf b/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.inf
> > new file mode 100644
> > index 000000000000..40c070767a96
> > --- /dev/null
> > +++ b/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.inf
> > @@ -0,0 +1,55 @@
> > +#/** @file
> > +#  Library for Phytium Platform.
> > +#
> > +#  Copyright (C) 2020, Phytium Technology Co, Ltd. All rights reserved.<BR>
> > +#
> > +#  SPDX-License-Identifier: BSD-2-Clause-Patent
> > +#
> > +#**/
> > +
> > +[Defines]
> > +  INF_VERSION                    = 0x0001001b
> > +  BASE_NAME                      = PlatformLib
> > +  FILE_GUID                      = fac08f56-40fe-11eb-a2a3-27b46864b1f3
> > +  MODULE_TYPE                    = BASE
> > +  VERSION_STRING                 = 1.0
> > +  LIBRARY_CLASS                  = ArmPlatformLib
> > +
> > +[Packages]
> > +  ArmPkg/ArmPkg.dec
> > +  ArmPlatformPkg/ArmPlatformPkg.dec
> > +  MdePkg/MdePkg.dec
> > +  MdeModulePkg/MdeModulePkg.dec
> > +  Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.dec
> > +
> > +[LibraryClasses]
> > +  ArmSmcLib
> > +  HobLib
> > +
> > +[Sources.common]
> > +  PlatformLib.c
> > +  PlatformLibMem.c
> > +
> > +[Sources.AARCH64]
> > +  AArch64/PhytiumPlatformHelper.S
> > +
> > +[Guids]
> > +
> > +[FixedPcd]
> > +  gPhytiumPlatformTokenSpaceGuid.PcdSystemIoBase
> > +  gPhytiumPlatformTokenSpaceGuid.PcdSystemIoSize
> > +  gPhytiumPlatformTokenSpaceGuid.PcdPciConfigBase
> > +  gPhytiumPlatformTokenSpaceGuid.PcdPciConfigSize
> > +  gArmTokenSpaceGuid.PcdPciBusMin
> > +  gArmTokenSpaceGuid.PcdPciBusMax
> > +  gArmTokenSpaceGuid.PcdPciIoBase
> > +  gArmTokenSpaceGuid.PcdPciIoSize
> > +  gArmTokenSpaceGuid.PcdPciIoTranslation
> > +  gArmTokenSpaceGuid.PcdPciMmio32Base
> > +  gArmTokenSpaceGuid.PcdPciMmio32Size
> > +  gArmTokenSpaceGuid.PcdPciMmio32Translation
> > +  gArmTokenSpaceGuid.PcdPciMmio64Base
> > +  gArmTokenSpaceGuid.PcdPciMmio64Size
> > +
> > +[Pcd]
> > +  gArmPlatformTokenSpaceGuid.PcdCoreCount
> > diff --git a/Silicon/Phytium/PhytiumCommonPkg/Include/SystemServiceInterface.h b/Silicon/Phytium/PhytiumCommonPkg/Include/SystemServiceInterface.h
> > new file mode 100644
> > index 000000000000..c4395153a3de
> > --- /dev/null
> > +++ b/Silicon/Phytium/PhytiumCommonPkg/Include/SystemServiceInterface.h
> > @@ -0,0 +1,112 @@
> > +/** @file
> > +
> > +  Copyright (C) 2020, Phytium Technology Co Ltd. All rights reserved.<BR>
> > +
> > +  SPDX-License-Identifier: BSD-2-Clause-Patent
> > +
> > +**/
> > +
> > +#ifndef SYSTEM_SERVICE_INTERFACE_H_
> > +#define SYSTEM_SERVICE_INTERFACE_H_
> > +
> > +/* SMC function IDs for OEM Service queries */
> > +#define PHYTIUM_OEM_SVC_PSSI_VERSION   0x8200ff03
> > +#define PHYTIUM_OEM_SVC_PBF_VERSION    0x82000001
> > +#define PHYTIUM_OEM_SVC_CPU_VERSION    0xc2000002
> > +#define PHYTIUM_OEM_SVC_CPU_MAPS       0xc2000003
> > +#define PHYTIUM_OEM_SVC_CPU_CONF       0xc2000004
> > +#define PHYTIUM_OEM_SVC_MEM_REGIONS    0xc2000005
> > +#define PHYTIUM_OEM_SVC_MCU_DIMMS      0xc2000006
> > +#define PHYTIUM_OEM_SVC_PCI_CONTROLLER 0xc2000007
> > +#define PHYTIUM_OEM_SVC_HOST_BRIDGE    0xc2000008
> > +#define PHYTIUM_OEM_SVC_GET_FLASH_CMD  0xC200000C
> > +
> > +#define PHYTIUM_IOBASE_MASK           0xfffffff
> > +#define PHYTIUM_MEMIO32_MASK          0xffffffff
> > +#define PHYTIUM_MEMIO64_MASK          0xffffffffff
> > +
> > +#pragma pack(1)
> > +
> > +typedef struct {
> > +  UINT64     CpuMapCount;
> > +  UINT64     CpuMap[1];
> > +} PHYTIUM_CPU_MAP_INFO;
> > +
> > +
> > +typedef struct {
> > +  UINT64     CpuFreq;             // Hz
> > +  UINT64     CpuL3CacheSize;      // Byte
> > +  UINT64     CpuL3CacheLineSize;  // Byte
> > +} PHYTIUM_CPU_COURE_INFO;
> > +
> > +typedef struct {
> > +  UINT64    CupVersion;       //cpu version
> > +  PHYTIUM_CPU_COURE_INFO CpuCoreInfo;    //cpu core info
> > +  PHYTIUM_CPU_MAP_INFO   CpuMapInfo;     //cpu map info
> > +}PHYTIUM_CPU_INFO;
> > +
> > +typedef struct {
> > +  UINT64     MemSize;    // MB
> > +  UINT64     MemDramId;
> > +  UINT64     MemModuleId;
> > +  UINT64     MemSerial;
> > +  UINT64     MemSlotNumber;
> > +  UINT64     MemFeatures;
> > +} MCU_DIMM;
> > +
> > +#define MCU_DIMM_MAXCOUNT 2
> > +
> > +typedef struct {
> > +  UINT64     MemFreq;    // MHz
> > +  UINT64     MemDimmCount;
> > +  MCU_DIMM   McuDimm[1];
> > +} MCU_DIMMS;
> > +
> > +typedef struct {
> > +  UINT64     MemStart;
> > +  UINT64     MemSize;
> > +  UINT64     MemNodeId;
> > +} MEMORY_BLOCK;
> > +
> > +typedef struct {
> > +  UINT64       MemBlockCount;
> > +  MEMORY_BLOCK MemBlock[1];
> > +} MEMORY_INFO;
> > +
> > +typedef struct {
> > +  UINT8    PciLane;
> > +  UINT8    PciSpeed;
> > +  UINT8    Reserved[6];
> > +} PCI_BLOCK;
> > +
> > +typedef struct {
> > +  UINT64       PciCount;
> > +  PCI_BLOCK    PciBlock[1];
> > +} PHYTIUM_PCI_CONTROLLER;
> > +
> > +typedef struct {
> > +  UINT8    BusStart;
> > +  UINT8    BusEnd;
> > +  UINT8    Reserved[6];
> > +  UINT64   PciConfigBase;
> > +  UINT64   IoBase;
> > +  UINT64   IoSize;
> > +  UINT64   Mem32Base;
> > +  UINT64   Mem32Size;
> > +  UINT64   Mem64Base;
> > +  UINT64   Mem64Size;
> > +  UINT16   IntA;
> > +  UINT16   IntB;
> > +  UINT16   IntC;
> > +  UINT16   IntD;
> > +} PCI_HOST_BLOCK;
> > +
> > +typedef struct {
> > +  UINT64          PciHostCount;
> > +  PCI_HOST_BLOCK  PciHostBlock[1];
> > +} PHYTIUM_PCI_HOST_BRIDGE;
> > +
> > +#pragma pack ()
> > +
> > +
> > +#endif // SYSTEM_SERVICE_INTERFACE_H_
> > diff --git a/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.c b/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.c
> > new file mode 100644
> > index 000000000000..6a8d22657489
> > --- /dev/null
> > +++ b/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLib.c
> > @@ -0,0 +1,137 @@
> > +/** @file
> > +  Library for Phytium platform.
> > +
> > +  Copyright (C) 2020, Phytium Technology Co Ltd. All rights reserved.<BR>
> > +
> > +  SPDX-License-Identifier: BSD-2-Clause-Patent
> > +
> > +**/
> > +
> > +#include <Library/ArmPlatformLib.h>
> > +#include <Library/DebugLib.h>
> > +#include <Library/IoLib.h>
> > +#include <Library/PcdLib.h>
> > +#include <Ppi/ArmMpCoreInfo.h>
> > +
> > +ARM_CORE_INFO mPhytiumMpCoreInfoTable[] = {
> > +  {
> > +    0x0, 0x0,              // Cluster 0, Core 0
> > +
> > +    // MP Core MailBox Set/Get/Clear Addresses and Clear Value
> > +    (EFI_PHYSICAL_ADDRESS)0,
> > +    (EFI_PHYSICAL_ADDRESS)0,
> > +    (EFI_PHYSICAL_ADDRESS)0,
> > +    (UINT64)0xFFFFFFFF
> > +  }
> > +};
> > +
> > +/*
> > +  This function geted the current Boot Mode.
> > +
> > +  This function returns the boot reason on the platform.
> > +
> > +  @return   Return the current Boot Mode of the platform.
> > +
> > +*/
> > +EFI_BOOT_MODE
> > +ArmPlatformGetBootMode (
> > +  VOID
> > +  )
> > +{
> > +  return BOOT_WITH_FULL_CONFIGURATION;
> > +}
> > +
> > +
> > +/**
> > +  Initialize controllers that must setup in the normal world.
> > +
> > +  This function is called by the ArmPlatformPkg/Pei or ArmPlatformPkg/Pei/PlatformPeim
> > +  in the PEI phase.
> > +
> > +  @retval      EFI_SUCCESS    ArmPlatformInitialize() is executed successfully.
> > +
> > +**/
> > +RETURN_STATUS
> > +ArmPlatformInitialize (
> > +  IN  UINTN                     MpId
> > +  )
> > +{
> > +  return RETURN_SUCCESS;
> > +}
> > +
> > +
> > +/**
> > +  This function Inited the system (or sometimes called permanent) memory.
> > +
> > +  This memory is generally represented by the DRAM.
> > +
> > +  @param[in]   None.
> > +
> > +  @retval      None.
> > +
> > +**/
> > +VOID
> > +ArmPlatformInitializeSystemMemory (
> > +  VOID
> > +  )
> > +{
> > +  // Nothing to do here
> > +}
> > +
> > +
> > +/**
> > +  This function geted the information of core.
> > +
> > +  @param[out]  CoreCount      The count of CoreInfoTable.
> > +  @param[out]  ArmCoreTable   The pointer of CoreInfoTable.
> > +
> > +  @retval      EFI_SUCCESS    PrePeiCoreGetMpCoreInfo() is executed successfully.
> > +
> > +**/
> > +EFI_STATUS
> > +PrePeiCoreGetMpCoreInfo (
> > +  OUT UINTN                   *CoreCount,
> > +  OUT ARM_CORE_INFO           **ArmCoreTable
> > +  )
> > +{
> > +  *CoreCount    = PcdGet32 (PcdCoreCount);
> > +  *ArmCoreTable = mPhytiumMpCoreInfoTable;
> > +
> > +  return EFI_SUCCESS;
> > +}
> > +
> > +//
> > +// Needs to be declared in the file. Otherwise gArmMpCoreInfoPpiGuid is
> > +// undefined in the contect of PrePeiCore
> > +//
> > +EFI_GUID mArmMpCoreInfoPpiGuid = ARM_MP_CORE_INFO_PPI_GUID;
> > +ARM_MP_CORE_INFO_PPI mMpCoreInfoPpi = { PrePeiCoreGetMpCoreInfo };
> > +
> > +EFI_PEI_PPI_DESCRIPTOR gPlatformPpiTable[] =
> > +{
> > +  {
> > +    EFI_PEI_PPI_DESCRIPTOR_PPI,
> > +    &mArmMpCoreInfoPpiGuid,
> > +    &mMpCoreInfoPpi
> > +  }
> > +};
> > +
> > +
> > +/**
> > +  This function geted the information of Ppitable.
> > +
> > +  @param[out]  PpiListSize      The size of Ppitable.
> > +  @param[out]  PpiList          The pointer of Ppitable.
> > +
> > +  @retval      None.
> > +
> > +**/
> > +VOID
> > +ArmPlatformGetPlatformPpiList (
> > +  OUT UINTN                   *PpiListSize,
> > +  OUT EFI_PEI_PPI_DESCRIPTOR  **PpiList
> > +  )
> > +{
> > +  *PpiListSize = sizeof (gPlatformPpiTable);
> > +  *PpiList = gPlatformPpiTable;
> > +}
> > diff --git a/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLibMem.c b/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLibMem.c
> > new file mode 100644
> > index 000000000000..7e54cb6e744f
> > --- /dev/null
> > +++ b/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/PlatformLibMem.c
> > @@ -0,0 +1,156 @@
> > +/** @file
> > +  Library of memory map for Phytium platform.
> > +
> > +  Copyright (C) 2020, Phytium Technology Co Ltd. All rights reserved.<BR>
> > +
> > +  SPDX-License-Identifier: BSD-2-Clause-Patent
> > +
> > +**/
> > +
> > +#include <Library/ArmPlatformLib.h>
> > +#include <Library/DebugLib.h>
> > +#include <Library/HobLib.h>
> > +#include <Library/PcdLib.h>
> > +#include <Library/MemoryAllocationLib.h>
> > +#include <Library/ArmSmcLib.h>
> > +#include <SystemServiceInterface.h>
> > +
> > +// Number of Virtual Memory Map Descriptors
> > +#define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS 32
> > +
> > +// DDR attributes
> > +#define DDR_ATTRIBUTES_CACHED      ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK
> > +#define DDR_ATTRIBUTES_UNCACHED    ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED
> > +
> > +/**
> > +  Return the Virtual Memory Map of your platform
> > +
> > +  This Virtual Memory Map is used by MemoryInitPei Module to initialize the MMU on your platform.
> > +
> > +  @param[out]  VirtualMemoryMap  Array of ARM_MEMORY_REGION_DESCRIPTOR describing a Physical-to-
> > +                                 Virtual Memory mapping. This array must be ended by a zero-filled
> > +                                 entry
> > +**/
> > +VOID
> > +ArmPlatformGetVirtualMemoryMap (
> > +  IN ARM_MEMORY_REGION_DESCRIPTOR** VirtualMemoryMap
> > +  )
> > +{
> > +  ARM_MEMORY_REGION_ATTRIBUTES  CacheAttributes;
> > +  ARM_MEMORY_REGION_DESCRIPTOR  *VirtualMemoryTable;
> > +  EFI_RESOURCE_ATTRIBUTE_TYPE   ResourceAttributes;
> > +  MEMORY_BLOCK                  *MemBlock;
> > +  MEMORY_INFO                   *MemInfo;
> > +  ARM_SMC_ARGS                  ArmSmcArgs;
> > +  UINT32                        MemBlockCnt;
> > +  UINT32                        Index1;
> > +  UINT32                        Index2;
> > +
> > +  MemBlock = NULL;
> > +  MemInfo  = NULL;
> > +  MemBlockCnt = 0;
> > +  Index1      = 0;
> > +  Index2      = 0;
> > +  CacheAttributes = ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
> > +
> > +  ASSERT (VirtualMemoryMap != NULL);
> > +  VirtualMemoryTable = (ARM_MEMORY_REGION_DESCRIPTOR*)AllocatePages \
> > +                         (EFI_SIZE_TO_PAGES (sizeof (ARM_MEMORY_REGION_DESCRIPTOR) * \
> > +                         MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS));
> > +  if (VirtualMemoryTable == NULL) {
> > +    return;
> > +  }
> > +
> > +  ResourceAttributes =
> > +    EFI_RESOURCE_ATTRIBUTE_PRESENT |
> > +    EFI_RESOURCE_ATTRIBUTE_INITIALIZED |
> > +    EFI_RESOURCE_ATTRIBUTE_UNCACHEABLE |
> > +    EFI_RESOURCE_ATTRIBUTE_WRITE_COMBINEABLE |
> > +    EFI_RESOURCE_ATTRIBUTE_WRITE_THROUGH_CACHEABLE |
> > +    EFI_RESOURCE_ATTRIBUTE_WRITE_BACK_CACHEABLE |
> > +    EFI_RESOURCE_ATTRIBUTE_TESTED;
> > +
> > +  MemInfo = AllocatePages (1);
> > +  ASSERT (MemInfo != NULL);
> > +
> > +  ArmSmcArgs.Arg0 = PHYTIUM_OEM_SVC_MEM_REGIONS;
> > +  ArmSmcArgs.Arg1 = (UINTN) MemInfo;
> > +  ArmSmcArgs.Arg2 = EFI_PAGE_SIZE;
> > +  ArmCallSmc (&ArmSmcArgs);
> > +  if (ArmSmcArgs.Arg0 == 0) {
> > +    MemBlockCnt = MemInfo->MemBlockCount;
> > +    MemBlock = MemInfo->MemBlock;
> > +  } else {
> > +    ASSERT (FALSE);
> > +  }
> > +
> > +  //Soc Io Space
> > +  VirtualMemoryTable[Index1].PhysicalBase   = PcdGet64 (PcdSystemIoBase);
> > +  VirtualMemoryTable[Index1].VirtualBase    = PcdGet64 (PcdSystemIoBase);
> > +  VirtualMemoryTable[Index1].Length         = PcdGet64 (PcdSystemIoSize);
> > +  VirtualMemoryTable[Index1].Attributes     = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> > +
> > +  //
> > +  // PCI Configuration Space
> > +  //
> > +  VirtualMemoryTable[++Index1].PhysicalBase  = PcdGet64 (PcdPciConfigBase);
> > +  VirtualMemoryTable[Index1].VirtualBase     = PcdGet64 (PcdPciConfigBase);
> > +  VirtualMemoryTable[Index1].Length          = PcdGet64 (PcdPciConfigSize);
> > +  VirtualMemoryTable[Index1].Attributes      = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> > +
> > +  //
> > +  // PCI Memory Space
> > +  //
> > +  VirtualMemoryTable[++Index1].PhysicalBase  = PcdGet64 (PcdPciIoBase) + PcdGet64 (PcdPciIoTranslation);
> > +  VirtualMemoryTable[Index1].VirtualBase     = PcdGet64 (PcdPciIoBase) + PcdGet64 (PcdPciIoTranslation);
> > +  VirtualMemoryTable[Index1].Length          = PcdGet64 (PcdPciIoSize);
> > +  VirtualMemoryTable[Index1].Attributes      = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> > +
> > +  //
> > +  // PCI Memory Space
> > +  //
> > +  VirtualMemoryTable[++Index1].PhysicalBase  = PcdGet32 (PcdPciMmio32Base);
> > +  VirtualMemoryTable[Index1].VirtualBase     = PcdGet32 (PcdPciMmio32Base);
> > +  VirtualMemoryTable[Index1].Length          = PcdGet32 (PcdPciMmio32Size);
> > +  VirtualMemoryTable[Index1].Attributes      = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> > +
> > +  //
> > +  // 64-bit PCI Memory Space
> > +  //
> > +  VirtualMemoryTable[++Index1].PhysicalBase  = PcdGet64 (PcdPciMmio64Base);
> > +  VirtualMemoryTable[Index1].VirtualBase     = PcdGet64 (PcdPciMmio64Base);
> > +  VirtualMemoryTable[Index1].Length          = PcdGet64 (PcdPciMmio64Size);
> > +  VirtualMemoryTable[Index1].Attributes      = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> > +
> > +  //DDR
> > +  for (Index2 = 0; Index2 < MemBlockCnt; Index2++) {
> > +    VirtualMemoryTable[++Index1].PhysicalBase = MemBlock->MemStart;
> > +    VirtualMemoryTable[Index1].VirtualBase    = MemBlock->MemStart;
> > +    VirtualMemoryTable[Index1].Length         = MemBlock->MemSize;
> > +    VirtualMemoryTable[Index1].Attributes     = CacheAttributes;
> > +
> > +    BuildResourceDescriptorHob (
> > +      EFI_RESOURCE_SYSTEM_MEMORY,
> > +      ResourceAttributes,
> > +      MemBlock->MemStart,
> > +      MemBlock->MemSize
> > +      );
> > +
> > +    MemBlock++;
> > +  }
> > +
> > +  // End of Table
> > +  VirtualMemoryTable[++Index1].PhysicalBase = 0;
> > +  VirtualMemoryTable[Index1].VirtualBase    = 0;
> > +  VirtualMemoryTable[Index1].Length         = 0;
> > +  VirtualMemoryTable[Index1].Attributes     = (ARM_MEMORY_REGION_ATTRIBUTES)0;
> > +
> > +
> > +  for (Index2 = 0; Index2 < Index1; Index2++) {
> > +    DEBUG ((DEBUG_ERROR, "PhysicalBase %12lx VirtualBase %12lx Length %12lx Attributes %12lx\n",\
> > +      VirtualMemoryTable[Index2].PhysicalBase, VirtualMemoryTable[Index2].VirtualBase, \
> > +      VirtualMemoryTable[Index2].Length, VirtualMemoryTable[Index2].Attributes));
> > +  }
> > +
> > +  *VirtualMemoryMap = VirtualMemoryTable;
> > +}
> > diff --git a/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/AArch64/PhytiumPlatformHelper.S b/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/AArch64/PhytiumPlatformHelper.S
> > new file mode 100644
> > index 000000000000..cce23b786197
> > --- /dev/null
> > +++ b/Silicon/Phytium/FT2000-4Pkg/Library/PlatformLib/AArch64/PhytiumPlatformHelper.S
> > @@ -0,0 +1,76 @@
> > +#
> > +#  Copyright (c) 2011-2013, ARM Limited. All rights reserved.
> > +#
> > +#  This program and the accompanying materials
> > +#  are licensed and made available under the terms and conditions of the BSD License
> > +#  which accompanies this distribution.  The full text of the license may be found at
> > +#  http://opensource.org/licenses/bsd-license.php
> > +#
> > +#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> > +#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
> > +#
> > +#
> > +
> > +#include <AsmMacroIoLibV8.h>
> > +#include <Base.h>
> > +#include <Library/ArmLib.h>
> > +#include <Library/PcdLib.h>
> > +#include <AutoGen.h>
> > +
> > +.text
> > +.align 2
> > +
> > +GCC_ASM_EXPORT(ArmPlatformPeiBootAction)
> > +GCC_ASM_EXPORT(ArmPlatformIsPrimaryCore)
> > +GCC_ASM_EXPORT(ArmPlatformGetPrimaryCoreMpId)
> > +GCC_ASM_EXPORT(ArmPlatformGetCorePosition)
> > +
> > +PrimaryCoreMpid:  .word    0x0
> > +
> > +
> > +ASM_PFX(ArmPlatformPeiBootAction):
> > +  // Save MPIDR_EL1[23:0] in a variable.
> > +  mov   x20, x30
> > +  bl    ASM_PFX(ArmReadMpidr)
> > +  lsl   w0, w0, #8
> > +  lsr   w0, w0, #8
> > +  ldr   x1, =PrimaryCoreMpid
> > +  str   w0, [x1]
> > +  ret   x20
> > +
> > +//UINTN
> > +//ArmPlatformGetPrimaryCoreMpId (
> > +//  VOID
> > +//  );
> > +ASM_PFX(ArmPlatformGetPrimaryCoreMpId):
> > +  ldr   x0, =PrimaryCoreMpid
> > +  ldr   w0, [x0]
> > +  ret
> > +
> > +//UINTN
> > +//ArmPlatformIsPrimaryCore (
> > +//  IN UINTN MpId
> > +//  );
> > +ASM_PFX(ArmPlatformIsPrimaryCore):
> > +  mov   x20, x30
> > +  bl    ASM_PFX(ArmReadMpidr)
> > +  lsl   w0, w0, #8
> > +  lsr   w0, w0, #8
> > +  ldr   x1, =PrimaryCoreMpid
> > +  ldr   w1, [x1]
> > +  cmp   w0, w1
> > +  cset  x0, eq
> > +  ret   x20
> > +
> > +//UINTN
> > +//ArmPlatformGetCorePosition (
> > +//  IN UINTN MpId
> > +//  );
> > +// With this function: CorePos = (ClusterId * 4) + CoreId
> > +ASM_PFX(ArmPlatformGetCorePosition):
> > +  and   x1, x0, #ARM_CORE_MASK
> > +  and   x0, x0, #ARM_CLUSTER_MASK
> > +  add   x0, x1, x0, LSR #6
> > +  ret
> > +
> > +ASM_FUNCTION_REMOVE_IF_UNREFERENCED
> > diff --git a/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.fdf.inc b/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.fdf.inc
> > new file mode 100644
> > index 000000000000..641266c6012f
> > --- /dev/null
> > +++ b/Silicon/Phytium/PhytiumCommonPkg/PhytiumCommonPkg.fdf.inc
> > @@ -0,0 +1,119 @@
> > +## @file
> > +# This package provides common open source Phytium silicon modules.
> > +#
> > +# Copyright (C) 2020, Phytium Technology Co, Ltd. All rights reserved.
> > +#
> > +# SPDX-License-Identifier:BSD-2-Clause-Patent
> > +#
> > +##
> > +
> > +############################################################################
> > +# Example of a DXE_DRIVER FFS file with a Checksum encapsulation section   #
> > +############################################################################
> > +#
> > +#[Rule.Common.DXE_DRIVER]
> > +#  FILE DRIVER = $(NAMED_GUID) {
> > +#    DXE_DEPEX    DXE_DEPEX               Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
> > +#    COMPRESS PI_STD {
> > +#      GUIDED {
> > +#        PE32     PE32                    $(INF_OUTPUT)/$(MODULE_NAME).efi
> > +#        UI       STRING="$(MODULE_NAME)" Optional
> > +#        VERSION  STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
> > +#      }
> > +#    }
> > +#  }
> > +#
> > +############################################################################
> > +
> > +[Rule.Common.SEC]
> > +  FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
> > +    TE  TE Align = Auto                 $(INF_OUTPUT)/$(MODULE_NAME).efi
> > +  }
> > +
> > +[Rule.Common.PEI_CORE]
> > +  FILE PEI_CORE = $(NAMED_GUID) FIXED {
> > +    TE     TE Align = Auto              $(INF_OUTPUT)/$(MODULE_NAME).efi
> > +    UI     STRING ="$(MODULE_NAME)" Optional
> > +  }
> > +
> > +[Rule.Common.PEIM]
> > +  FILE PEIM = $(NAMED_GUID) FIXED {
> > +     PEI_DEPEX PEI_DEPEX Optional       $(INF_OUTPUT)/$(MODULE_NAME).depex
> > +     TE       TE Align = Auto           $(INF_OUTPUT)/$(MODULE_NAME).efi
> > +     UI       STRING="$(MODULE_NAME)" Optional
> > +  }
> > +
> > +[Rule.Common.PEIM.TIANOCOMPRESSED]
> > +  FILE PEIM = $(NAMED_GUID) DEBUG_MYTOOLS_IA32 {
> > +    PEI_DEPEX PEI_DEPEX Optional        $(INF_OUTPUT)/$(MODULE_NAME).depex
> > +    GUIDED A31280AD-481E-41B6-95E8-127F4C984779 PROCESSING_REQUIRED = TRUE {
> > +      PE32      PE32                    $(INF_OUTPUT)/$(MODULE_NAME).efi
> > +      UI        STRING="$(MODULE_NAME)" Optional
> > +    }
> > +  }
> > +
> > +[Rule.Common.DXE_CORE]
> > +  FILE DXE_CORE = $(NAMED_GUID) {
> > +    PE32     PE32                       $(INF_OUTPUT)/$(MODULE_NAME).efi
> > +    UI       STRING="$(MODULE_NAME)" Optional
> > +  }
> > +
> > +[Rule.Common.UEFI_DRIVER]
> > +  FILE DRIVER = $(NAMED_GUID) {
> > +    DXE_DEPEX    DXE_DEPEX              Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
> > +    PE32         PE32                   $(INF_OUTPUT)/$(MODULE_NAME).efi
> > +    UI           STRING="$(MODULE_NAME)" Optional
> > +  }
> > +
> > +[Rule.Common.DXE_DRIVER]
> > +  FILE DRIVER = $(NAMED_GUID) {
> > +    DXE_DEPEX    DXE_DEPEX              Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
> > +    PE32         PE32                   $(INF_OUTPUT)/$(MODULE_NAME).efi
> > +    UI           STRING="$(MODULE_NAME)" Optional
> > +  }
> > +
> > +[Rule.Common.DXE_RUNTIME_DRIVER]
> > +  FILE DRIVER = $(NAMED_GUID) {
> > +    DXE_DEPEX    DXE_DEPEX              Optional $(INF_OUTPUT)/$(MODULE_NAME).depex
> > +    PE32         PE32                   $(INF_OUTPUT)/$(MODULE_NAME).efi
> > +    UI           STRING="$(MODULE_NAME)" Optional
> > +  }
> > +
> > +[Rule.Common.UEFI_APPLICATION]
> > +  FILE APPLICATION = $(NAMED_GUID) {
> > +    UI     STRING ="$(MODULE_NAME)"     Optional
> > +    PE32   PE32                         $(INF_OUTPUT)/$(MODULE_NAME).efi
> > +  }
> > +
> > +[Rule.Common.UEFI_DRIVER.BINARY]
> > +  FILE DRIVER = $(NAMED_GUID) {
> > +    DXE_DEPEX DXE_DEPEX Optional      |.depex
> > +    PE32      PE32                    |.efi
> > +    UI        STRING="$(MODULE_NAME)" Optional
> > +    VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
> > +  }
> > +
> > +[Rule.Common.UEFI_APPLICATION.BINARY]
> > +  FILE APPLICATION = $(NAMED_GUID) {
> > +    PE32      PE32                    |.efi
> > +    UI        STRING="$(MODULE_NAME)" Optional
> > +    VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
> > +  }
> > +
> > +[Rule.Common.USER_DEFINED.BIOSINFO]
> > +  FILE FREEFORM = $(NAMED_GUID) {
> > +    RAW BIN Align = 16 $(INF_OUTPUT)/$(MODULE_NAME).acpi
> > +  }
> > +
> > +[Rule.Common.UEFI_APPLICATION.UI]
> > +  FILE APPLICATION = $(NAMED_GUID) {
> > +    PE32      PE32                     $(INF_OUTPUT)/$(MODULE_NAME).efi
> > +    UI        STRING="Enter Setup"
> > +    VERSION   STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
> > +  }
> > +
> > +[Rule.Common.USER_DEFINED.ACPITABLE]
> > +  FILE FREEFORM = $(NAMED_GUID) {
> > +    RAW ACPI               |.acpi
> > +    RAW ASL                |.aml
> > +  }
> > --
> > 2.25.1
> >






Re: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

Ard Biesheuvel
 

On Wed, 17 Feb 2021 at 07:18, jlinton <lintonrjeremy@gmail.com> wrote:

From: Jeremy Linton <jeremy.linton@arm.com>

The existing RPi3 ACPI entries for the Arasan
and SDHCI controllers need updating to work
with the RPi4. This is done by adding a caps
override for the legacy Arasan controller and
then adding an entirely new entry for the newer
eMMC2 controller.

Then we flip the default routing to make the eMMC2
the default for the SD card, so that the WiFi can
start working on the Arasan.

Additional we add a menu item to enable the SDMA/ADMA2
modes on the controller.

v2->v3: Various small review tweaks, whitespace, wording
spelling, etc.

v1->v2: Add option for user to enable/disable eMMC DMA
Only enable the emmc2 table on rpi4 &
!Arasan routing
Move emmc2 into its own SSDT and drop
second _DMA entry

Jeremy Linton (4):
Platform/RaspberryPi: Add Negative table check
Platform/RaspberryPi/Acpitables: Add eMMC2 device and tweak Arasan
Platform/RaspberryPi: User control of eMMC2 DMA
Platform/RaspberryPi: Invert default Arasan, eMMC2 routing
Could you please resend these in a way that I can apply them? They
seem to have gone through some QP mangling filter, with long lines
broken and newlines doubled in some cases (depending on the line
ending mode of the file, it seems)

https://pastebin.com/yG74aygV


Platform/RaspberryPi/AcpiTables/AcpiTables.inf | 1 +
Platform/RaspberryPi/AcpiTables/Emmc.asl | 129 +++++++++++++++++++++
Platform/RaspberryPi/AcpiTables/Sdhc.asl | 18 ++-
Platform/RaspberryPi/Drivers/ConfigDxe/ConfigDxe.c | 26 +++++
.../RaspberryPi/Drivers/ConfigDxe/ConfigDxe.inf | 1 +
.../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.uni | 4 +
.../RaspberryPi/Drivers/ConfigDxe/ConfigDxeHii.vfr | 17 +++
Platform/RaspberryPi/Include/ConfigVars.h | 8 ++
Platform/RaspberryPi/RPi3/RPi3.dsc | 1 +
Platform/RaspberryPi/RPi4/RPi4.dsc | 3 +-
Platform/RaspberryPi/RPi4/Readme.md | 2 +-
Platform/RaspberryPi/RaspberryPi.dec | 1 +
12 files changed, 206 insertions(+), 5 deletions(-)
create mode 100644 Platform/RaspberryPi/AcpiTables/Emmc.asl

--
2.13.7


Re: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

Ard Biesheuvel
 

On Thu, 18 Feb 2021 at 17:47, Jeremy Linton <jeremy.linton@arm.com> wrote:

Hi,

On 2/17/21 11:57 AM, Ard Biesheuvel wrote:
On Wed, 17 Feb 2021 at 18:16, Jeremy Linton <jeremy.linton@arm.com> wrote:

Hi,

On 2/17/21 1:55 AM, Ard Biesheuvel via groups.io wrote:
On Wed, 17 Feb 2021 at 08:30, Jeremy Linton <jeremy.linton@arm.com> wrote:

Hi,

On 2/17/21 12:56 AM, Ard Biesheuvel wrote:
On Wed, 17 Feb 2021 at 07:18, jlinton <lintonrjeremy@gmail.com> wrote:

From: Jeremy Linton <jeremy.linton@arm.com>

The existing RPi3 ACPI entries for the Arasan
and SDHCI controllers need updating to work
with the RPi4. This is done by adding a caps
override for the legacy Arasan controller and
then adding an entirely new entry for the newer
eMMC2 controller.

Then we flip the default routing to make the eMMC2
the default for the SD card, so that the WiFi can
start working on the Arasan.

Additional we add a menu item to enable the SDMA/ADMA2
modes on the controller.

v2->v3: Various small review tweaks, whitespace, wording
spelling, etc.
What happened to the IORT change? Don't we need that to ensure that
Linux sizes ZONE_DMA appropriately?
Ha, I gave up! There are more important things to fix, especially when I
found another case that couldn't just be fixed by the IORT tweaking
without more kernel patches.
Which case is that?
Some of these firmware/board revisions appear to need the 3G
translation. The EMMC seems to be one of the devices who's DT
descriptions are being modified by the lower level firmware (like the PCI).
Considering that the reason for the 1 GB device limit is the -3 GB DMA
translation, I'd assume that the former and the latter apply to the
same set of peripherals.

But are you saying the dma-ranges properties are manipulated by the VC
firmware? Or other DT properties related to DMA translation?
Yes, Its changing dma-range property associated with the emmc in the DT
its being handed which is then shared with atf/etc.
But the translation is always the same, no?





The default in this set is PIO mode, no DMA, same as the Arasan. If I
get motivated (or someone else does) they can pick up the pieces to
finish turning the DMA on in linux. It also simplifies that IORT disable
patch I posted separately since I don't have to worry about enabling it
for a limit <2G.
But having a 1 GB limit for only the eMMC2 in the IORT and a matching
_DMA method in its container should not trigger this error, I'd
assume.
Well with stock linux, the device will configure, startup and corrupt data.
By 'this error', I mean the splat resulting from mismatching DMA
limits for XHCI between IORT and _DMA.
No, I don't see that. The PCI/XHCI is fine with the IORT changes.
Then why do you need

[PATCH v2] Platform/RaspberryPi: Only enable IORT when 3G limit is disabled

?


Is the reason for the data corruption understood?
It runs but appears to the address translation portion doesn't get
applied (the command rings appear to be ok/etc) to FS buffers reliably
so garbage gets written to the disk as the wrong bus locations get used.
Its somewhat odd because at a first glance the directory structure/etc
come back so if one just mounts the FS and ls's it, then unmounts it all
appears to be ok. The first indications something is wrong are usually
FS corruption messages. I have an instrumented sdhci/etc driver
splatting on addrs > 1G so that all looks ok.




The sdhci_caps_mask choice is what flags the device as not supporting
DMA modes unless the user enables it. Yes this hurts perf, but not
nearly as badly as disabling UHS mode because we can't lower the card
voltage with the standard sdhci registers (rather having to depend on a
nonstandard rpi mailbox call which isn't available without a _DSM() or
something equally undesirable).
Are you saying switching to the Arasan disabled UHS mode, and this is
why this is an improvement nonetheless?
? I'm not sure I understand. Right now in linux we don't have SD or
wifi. With just the caps _DSD entry the arasan will configure but it
runs PIO mode all the time (including with DT). The cap is needed
because the arasan returns 0 in the standard SDHCI caps registers.

The emmc2 supports faster modes, but we can't easily switch the voltage
to support them because the standard voltage control registers aren't
wired correctly (AFAIK). Given the change detection doesn't work right
either (AFAIK), we could hack up the linux sdhci subsystem to not reset
the card at startup and leave faster cards at 1.8V, but that is uglier
than adding a _DSM() to forward the voltage change request to the rpi
mailbox. But again we are hacking up the iproc (or sdhci_acpi) driver.

IMHO, Given its just a perf thing, and this whole board is compromised
in so many ways, it just isn't worth trying to support low voltage/UHS.
Since the card is already running at the slower speeds, using PIO
instead of DMA isn't a huge hit.
I could also argue that PIO at low speeds is worse then PIO at high
speeds, given that the CPU will be tied up for longer to transfer the
same amount of data. >
So then we don't have to have a 1G
IORT, or dynamic _DMA translation.
Yes, that is obviously a win.

But this set is about enabling both the SD and WiFi. The latter requires
the SD to be bound to the emmc2. At the moment there isn't much in the
way of a perf advantage to switching the SD from the Arasan to the
emmc2, the benefit comes from being able to use the wifi..

Fair enough. I'm just slightly disappointed that we cannot use the
eMMC2 in DMA mode even for the lower speed, but I guess it is not the
end of the world.
Well its never done, at some point it can be revisited to make it
faster. Maybe someone will come up with a clever way to do the voltage
switching too. The platform has an easy way to trap to el3, but I can't
see how to utilize that without sdhci driver changes at the moment.


If everyone else is on board with this approach, I'll pick these up tomorrow.

Thanks,
Ard.


Re: [PATCH v3 0/4] RPi: SD/WiFi ACPI updates

Jeremy Linton
 

Hi,

On 2/17/21 11:57 AM, Ard Biesheuvel wrote:
On Wed, 17 Feb 2021 at 18:16, Jeremy Linton <jeremy.linton@arm.com> wrote:

Hi,

On 2/17/21 1:55 AM, Ard Biesheuvel via groups.io wrote:
On Wed, 17 Feb 2021 at 08:30, Jeremy Linton <jeremy.linton@arm.com> wrote:

Hi,

On 2/17/21 12:56 AM, Ard Biesheuvel wrote:
On Wed, 17 Feb 2021 at 07:18, jlinton <lintonrjeremy@gmail.com> wrote:

From: Jeremy Linton <jeremy.linton@arm.com>

The existing RPi3 ACPI entries for the Arasan
and SDHCI controllers need updating to work
with the RPi4. This is done by adding a caps
override for the legacy Arasan controller and
then adding an entirely new entry for the newer
eMMC2 controller.

Then we flip the default routing to make the eMMC2
the default for the SD card, so that the WiFi can
start working on the Arasan.

Additional we add a menu item to enable the SDMA/ADMA2
modes on the controller.

v2->v3: Various small review tweaks, whitespace, wording
spelling, etc.
What happened to the IORT change? Don't we need that to ensure that
Linux sizes ZONE_DMA appropriately?
Ha, I gave up! There are more important things to fix, especially when I
found another case that couldn't just be fixed by the IORT tweaking
without more kernel patches.
Which case is that?
Some of these firmware/board revisions appear to need the 3G
translation. The EMMC seems to be one of the devices who's DT
descriptions are being modified by the lower level firmware (like the PCI).
Considering that the reason for the 1 GB device limit is the -3 GB DMA
translation, I'd assume that the former and the latter apply to the
same set of peripherals.
But are you saying the dma-ranges properties are manipulated by the VC
firmware? Or other DT properties related to DMA translation?
Yes, Its changing dma-range property associated with the emmc in the DT its being handed which is then shared with atf/etc.





The default in this set is PIO mode, no DMA, same as the Arasan. If I
get motivated (or someone else does) they can pick up the pieces to
finish turning the DMA on in linux. It also simplifies that IORT disable
patch I posted separately since I don't have to worry about enabling it
for a limit <2G.
But having a 1 GB limit for only the eMMC2 in the IORT and a matching
_DMA method in its container should not trigger this error, I'd
assume.
Well with stock linux, the device will configure, startup and corrupt data.
By 'this error', I mean the splat resulting from mismatching DMA
limits for XHCI between IORT and _DMA.
No, I don't see that. The PCI/XHCI is fine with the IORT changes.

Is the reason for the data corruption understood?
It runs but appears to the address translation portion doesn't get applied (the command rings appear to be ok/etc) to FS buffers reliably so garbage gets written to the disk as the wrong bus locations get used. Its somewhat odd because at a first glance the directory structure/etc come back so if one just mounts the FS and ls's it, then unmounts it all appears to be ok. The first indications something is wrong are usually FS corruption messages. I have an instrumented sdhci/etc driver splatting on addrs > 1G so that all looks ok.




The sdhci_caps_mask choice is what flags the device as not supporting
DMA modes unless the user enables it. Yes this hurts perf, but not
nearly as badly as disabling UHS mode because we can't lower the card
voltage with the standard sdhci registers (rather having to depend on a
nonstandard rpi mailbox call which isn't available without a _DSM() or
something equally undesirable).
Are you saying switching to the Arasan disabled UHS mode, and this is
why this is an improvement nonetheless?
? I'm not sure I understand. Right now in linux we don't have SD or
wifi. With just the caps _DSD entry the arasan will configure but it
runs PIO mode all the time (including with DT). The cap is needed
because the arasan returns 0 in the standard SDHCI caps registers.

The emmc2 supports faster modes, but we can't easily switch the voltage
to support them because the standard voltage control registers aren't
wired correctly (AFAIK). Given the change detection doesn't work right
either (AFAIK), we could hack up the linux sdhci subsystem to not reset
the card at startup and leave faster cards at 1.8V, but that is uglier
than adding a _DSM() to forward the voltage change request to the rpi
mailbox. But again we are hacking up the iproc (or sdhci_acpi) driver.

IMHO, Given its just a perf thing, and this whole board is compromised
in so many ways, it just isn't worth trying to support low voltage/UHS.
Since the card is already running at the slower speeds, using PIO
instead of DMA isn't a huge hit.
I could also argue that PIO at low speeds is worse then PIO at high
speeds, given that the CPU will be tied up for longer to transfer the
same amount of data. >
So then we don't have to have a 1G
IORT, or dynamic _DMA translation.
Yes, that is obviously a win.

But this set is about enabling both the SD and WiFi. The latter requires
the SD to be bound to the emmc2. At the moment there isn't much in the
way of a perf advantage to switching the SD from the Arasan to the
emmc2, the benefit comes from being able to use the wifi..

Fair enough. I'm just slightly disappointed that we cannot use the
eMMC2 in DMA mode even for the lower speed, but I guess it is not the
end of the world.
Well its never done, at some point it can be revisited to make it faster. Maybe someone will come up with a clever way to do the voltage switching too. The platform has an easy way to trap to el3, but I can't see how to utilize that without sdhci driver changes at the moment.

If everyone else is on board with this approach, I'll pick these up tomorrow.
Thanks,
Ard.


Re: [PATCH - resend] MdeModulePkg/BootLogoLib: Center logo 38.2% from top of screen

Patrick Rudolph
 

Hi,
Please find the issue created here:
https://bugzilla.tianocore.org/show_bug.cgi?id=3226

On Thu, Feb 18, 2021 at 4:32 AM gaoliming <gaoliming@byosoft.com.cn> wrote:

Patrick:
I am OK for this extension to meet with Microsoft recommendation. This
change is a new feature. Can you submit one BZ
(https://bugzilla.tianocore.org/) for it?

Thanks
Liming
-----邮件原件-----
发件人: bounce+27952+71716+4905953+8761045@groups.io
<bounce+27952+71716+4905953+8761045@groups.io> 代表 Patrick
Rudolph
发送时间: 2021年2月17日 18:11
收件人: devel@edk2.groups.io
抄送: tcrawford@system76.com; jian.j.wang@intel.com;
hao.a.wu@intel.com; zhichao.gao@intel.com; ray.ni@intel.com
主题: [edk2-devel] [PATCH - resend] MdeModulePkg/BootLogoLib: Center
logo 38.2% from top of screen

From: Tim Crawford <tcrawford@system76.com>

Use Microsoft's recommended positioning [1] for the boot logo.

We recommend that the logo is placed with its center at 38.2% from the
screen's top edge. This positioning is based on the golden ratio's
visual aesthetics and matches the Windows 10 design proportions.
[1]:
https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/boot-s
creen-components#position-the-logo-during-post

Based on Tim Crawford <tcrawford@system76.com> initial commit.

Signed-off-by: Patrick Rudolph <patrick.rudolph@9elements.com>
---
MdeModulePkg/Include/Protocol/PlatformLogo.h | 3 ++-
MdeModulePkg/Library/BootLogoLib/BootLogoLib.c | 4 ++++
MdeModulePkg/Logo/Logo.c | 2 +-
3 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Include/Protocol/PlatformLogo.h
b/MdeModulePkg/Include/Protocol/PlatformLogo.h
index 55c9e08696..21a4c79e1d 100644
--- a/MdeModulePkg/Include/Protocol/PlatformLogo.h
+++ b/MdeModulePkg/Include/Protocol/PlatformLogo.h
@@ -29,7 +29,8 @@ typedef enum {
EdkiiPlatformLogoDisplayAttributeCenterBottom,

EdkiiPlatformLogoDisplayAttributeLeftBottom,

EdkiiPlatformLogoDisplayAttributeCenterLeft,

- EdkiiPlatformLogoDisplayAttributeCenter

+ EdkiiPlatformLogoDisplayAttributeCenter,

+ EdkiiPlatformLogoDisplayAttributeMicrosoftRecommended

} EDKII_PLATFORM_LOGO_DISPLAY_ATTRIBUTE;



/**

diff --git a/MdeModulePkg/Library/BootLogoLib/BootLogoLib.c
b/MdeModulePkg/Library/BootLogoLib/BootLogoLib.c
index 134660f28d..d40c65b59f 100644
--- a/MdeModulePkg/Library/BootLogoLib/BootLogoLib.c
+++ b/MdeModulePkg/Library/BootLogoLib/BootLogoLib.c
@@ -173,6 +173,10 @@ BootLogoEnableLogo (
DestX = 0;

DestY = (SizeOfY - Image.Height) / 2;

break;

+ case EdkiiPlatformLogoDisplayAttributeMicrosoftRecommended:

+ DestX = (SizeOfX - Image.Width) / 2;

+ DestY = (SizeOfY * 382) / 1000 - Image.Height / 2;

+ break;

case EdkiiPlatformLogoDisplayAttributeCenter:

DestX = (SizeOfX - Image.Width) / 2;

DestY = (SizeOfY - Image.Height) / 2;

diff --git a/MdeModulePkg/Logo/Logo.c b/MdeModulePkg/Logo/Logo.c
index c647253ecd..131a1b456a 100644
--- a/MdeModulePkg/Logo/Logo.c
+++ b/MdeModulePkg/Logo/Logo.c
@@ -26,7 +26,7 @@ EFI_HII_HANDLE mHiiHandle;
LOGO_ENTRY mLogos[] = {

{

IMAGE_TOKEN (IMG_LOGO),

- EdkiiPlatformLogoDisplayAttributeCenter,

+ EdkiiPlatformLogoDisplayAttributeMicrosoftRecommended,

0,

0

}

--
2.26.2



-=-=-=-=-=-=
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#71716): https://edk2.groups.io/g/devel/message/71716
Mute This Topic: https://groups.io/mt/80700289/4905953
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub
[gaoliming@byosoft.com.cn]
-=-=-=-=-=-=


Re: 回复: [edk2-devel] [PATCH v4 13/14] MdeModulePkg/VariableStandaloneMm: Set PcdFlashNvStorageVariableBase to Pcd

Ilias Apalodimas
 

On Thu, Feb 18, 2021 at 11:13:21AM +0800, gaoliming wrote:
I suggest to directly change [FixedPcd] to [Pcd] section. All Pcds can
support FixedAtBuild and PatchableInModule.
We can, but is there a reason to do that?
Wouldn't we be better of being more strict on the Pcd context we define for
each variable?

The values that were swapped from FixedPcd to Pcd are expected to change in
runtime, while the rest don't.

Thanks
/Ilias


With this change, Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>

Thanks
Liming
-----邮件原件-----
发件人: bounce+27952+71734+4905953+8761045@groups.io
<bounce+27952+71734+4905953+8761045@groups.io> 代表 Sughosh Ganu
发送时间: 2021年2月17日 19:27
收件人: devel@edk2.groups.io
抄送: Sami Mujawar <sami.mujawar@arm.com>; Ilias Apalodimas
<ilias.apalodimas@linaro.org>; Ard Biesheuvel <ardb+tianocore@kernel.org>
主题: [edk2-devel] [PATCH v4 13/14] MdeModulePkg/VariableStandaloneMm:
Set PcdFlashNvStorageVariableBase to Pcd

From: Ilias Apalodimas <ilias.apalodimas@linaro.org>

Instead of running StMM in SPM, OP-TEE creates a new secure partition,
which emulates SPM and isolates StMM from the rest of the Trusted
Applications (TAs). We can then compile StMM as an FD image and run it
in OP-TEE. With the addition of a new RPMB driver, we can leverage OP-TEE
and store variables to an RPMB device.

Since EDK2 upper layers expect byte addressable code, for the RPMB to
work, we need to allocate memory and sync it with the hardware on
read/writes. Since DynamicPCDs are not supported in that context we
can only use PatchablePCDs. So let's switch them to Pcd instead of
FixedPcd and accomodate the new driver.

Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Sami Mujawar <sami.mujawar@arm.com>
---

Changes since V3: None

MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
| 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git
a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.in
f
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.in
f
index fada0bf3c5..2a25fbdada 100644
---
a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.in
f
+++
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.in
f
@@ -119,10 +119,12 @@
## SOMETIMES_PRODUCES ## Variable:L"VarErrorFlag"
gEdkiiVarErrorFlagGuid

-[FixedPcd]
- gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
## CONSUMES
+[Pcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase
## SOMETIMES_CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableBase64
## CONSUMES
+ gEfiMdeModulePkgTokenSpaceGuid.PcdFlashNvStorageVariableSize
## CONSUMES
+
+[FixedPcd]
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVariableSize
## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxAuthVariableSize
## CONSUMES
gEfiMdeModulePkgTokenSpaceGuid.PcdMaxVolatileVariableSize
## CONSUMES
--
2.17.1











Re: 回复: [edk2-devel] [PATCH 1/1] ArmPkg: Fix ARM ProcessorSubClassDxe build

Sami Mujawar
 

Hi Liming,

We are working to get EDK2 Open CI enabled for ArmPkg and ArmPlatformPkg. We are doing some initial cleanup before the CI is enabled.

Regards,

Sami Mujawar


From: devel@edk2.groups.io <devel@edk2.groups.io> on behalf of Rebecca Cran via groups.io <rebecca@...>
Sent: Thursday, 18 February 2021, 3:42 am
To: devel@edk2.groups.io; gaoliming@...; rebecca@...
Cc: 'Leif Lindholm'; 'Ard Biesheuvel'
Subject: Re: 回复: [edk2-devel] [PATCH 1/1] ArmPkg: Fix ARM ProcessorSubClassDxe build

Liming,

It was found via Linaro's CI environment, but not EDK2's.
I'm planning to set up my own Jenkins server to run CI to catch problems
like this before they're committed. It'll also let me test OvmfPkg/Bhyve
builds too.

--
Rebecca Cran

On 2/17/21 8:33 PM, gaoliming wrote:
> Rebecca:
>    Is this issue detected in open CI environment?
>
> Thanks
> Liming
>> -----�ʼ�ԭ��-----
>> ������: bounce+27952+71573+4905953+8761045@groups.io
>> <bounce+27952+71573+4905953+8761045@groups.io> ���� Rebecca Cran
>> ����ʱ��: 2021��2��10�� 23:05
>> �ռ���: devel@edk2.groups.io
>> ����: Rebecca Cran <rebecca@...>; Leif Lindholm
>> <leif@...>; Ard Biesheuvel <ardb+tianocore@...>
>> ����: [edk2-devel] [PATCH 1/1] ArmPkg: Fix ARM ProcessorSubClassDxe build
>>
>> The ARM ProcessorSubClassDxe build was broken due to changes in the
>> SmbiosProcessor API and an unused variable.
>>
>> Signed-off-by: Rebecca Cran <rebecca@...>
>> ---
>>   ArmPkg/Universal/Smbios/ProcessorSubClassDxe/SmbiosProcessorArm.c | 6
>> ++----
>>   1 file changed, 2 insertions(+), 4 deletions(-)
>>
>> diff --git
>> a/ArmPkg/Universal/Smbios/ProcessorSubClassDxe/SmbiosProcessorArm.c
>> b/ArmPkg/Universal/Smbios/ProcessorSubClassDxe/SmbiosProcessorArm.c
>> index 0be4403c765f..c78bd41a7e06 100644
>> ---
>> a/ArmPkg/Universal/Smbios/ProcessorSubClassDxe/SmbiosProcessorArm.c
>> +++
>> b/ArmPkg/Universal/Smbios/ProcessorSubClassDxe/SmbiosProcessorArm.c
>> @@ -22,7 +22,7 @@
>>       @return The cache size.
>>   **/
>>   UINT64
>> -ArmGetCacheSize (
>> +SmbiosProcessorGetCacheSize (
>>     IN UINT8   CacheLevel,
>>     IN BOOLEAN DataCache,
>>     IN BOOLEAN UnifiedCache
>> @@ -66,14 +66,13 @@ ArmGetCacheSize (
>>       @return The cache associativity.
>>   **/
>>   UINT32
>> -ArmGetCacheAssociativity (
>> +SmbiosProcessorGetCacheAssociativity (
>>     IN UINT8   CacheLevel,
>>     IN BOOLEAN DataCache,
>>     IN BOOLEAN UnifiedCache
>>     )
>>   {
>>     CCSIDR_DATA  Ccsidr;
>> -  CCSIDR2_DATA Ccsidr2;
>>     CSSELR_DATA  Csselr;
>>     BOOLEAN      CcidxSupported;
>>     UINT32       Associativity;
>> @@ -88,7 +87,6 @@ ArmGetCacheAssociativity (
>>     CcidxSupported = ArmHasCcidx ();
>>
>>     if (CcidxSupported) {
>> -    Ccsidr2.Data = ReadCCSIDR2 (Csselr.Data);
>>       Associativity = Ccsidr.BitsCcidxAA32.Associativity + 1;
>>     } else {
>>       Associativity = Ccsidr.BitsNonCcidx.Associativity + 1;
>> --
>> 2.26.2
>>
>>
>>
>>
>>
>
>
>
>
>
>
>
>








12761 - 12780 of 84490