|
Re: ArmVirt and Self-Updating Code
Ard Biesheuvel
On Fri, 23 Jul 2021 at 12:47, Marvin Häuser <mhaeuser@posteo.de> wrote:
Correct. And this works really well for shared libraries, where all text and data sections can be shared between processes, as they will not be modified by the loader. All locations targeted by relocations will be nicely lumped together in the GOT. However, for bare metal style programs, there is no sharing, and there is no advantage to lumping anything together. It is much better to use relative references where possible, and simply apply relocations wherever needed across the text and data sections, If I understood the process right, but the term (GOT) is wrong, sorry,The GOT is a special data structure used for implicit variable accesses, i.e., global vars used in the code. Statically initialized pointer variables are the other category, which are not code, and for which the same considerations do not apply, given that the right value simply needs to be stored in the variable before the program starts. The selection of 'code model' as it is called is controlled by GCC'sFor instance, a statically initialized pointer always carries anAnd this is not forced by whatever table -fpie uses, as per my -mcmodel= argument, which defaults to 'small' on AArch64, regardless of whether you use PIC/PIE or not. That is what I meant to imply with the middle question (well, notIf the FFS SecCore section type is used here, it does not mean thatAs per your comments below, I think SecCore should not be located here.“Now, StandaloneMmPkg has similar (self-)relocation code too:https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c#L379-L386No.
|
|
|
|
Re: [PATCH 3/3] IntelSiliconPkg: Add IgdOpRegion30.h to support IGD OpRegion v3.0
Digant H Solanki
Gentle reminder to review this patch pls. Thanks..!!
toggle quoted messageShow quoted text
-----Original Message-----
From: Solanki, Digant H <digant.h.solanki@intel.com> Sent: Thursday, July 22, 2021 5:17 PM To: devel@edk2.groups.io Cc: Solanki, Digant H <digant.h.solanki@intel.com>; Ni, Ray <ray.ni@intel.com>; Chaganty, Rangasai V <rangasai.v.chaganty@intel.com>; S, Ashraf Ali <ashraf.ali.s@intel.com> Subject: [PATCH 3/3] IntelSiliconPkg: Add IgdOpRegion30.h to support IGD OpRegion v3.0 REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3426 - There are many OpRegion fields obsoleted in MBOX1 - MBOX2 is re-purposed for Backlight related fields for dual LFP. - Backlight related fields moved to MBOX2 from MBOX3 and some fields are obsoleted in MBOX3. Signed-off-by: Digant H Solanki <digant.h.solanki@intel.com> Cc: Ray Ni <ray.ni@intel.com> Cc: Rangasai V Chaganty <rangasai.v.chaganty@intel.com> Cc: Ashraf Ali S <ashraf.ali.s@intel.com> --- Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h | 101 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 101 insertions(+) diff --git a/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion30.h new file mode 100644 index 0000000000..c9948ab55f --- /dev/null +++ b/Silicon/Intel/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion +++ 30.h @@ -0,0 +1,101 @@ +/** @file + IGD OpRegion definition from Intel Integrated Graphics Device +OpRegion + Specification based on version 3.0. + + Copyright (c) 2021, Intel Corporation. All rights reserved.<BR> + SPDX-License-Identifier: BSD-2-Clause-Patent + +**/ +#ifndef _IGD_OPREGION_3_0_H_ +#define _IGD_OPREGION_3_0_H_ + +#include "IgdOpRegion.h" + +#define IGD_OPREGION_HEADER_MBOX2_VER_3_0 BIT5 + +#pragma pack(1) +/// +/// OpRegion Mailbox 1 - Public ACPI Methods /// Offset 0x100, Size +0x100 /// typedef struct { + UINT32 DRDY; ///< Offset 0x100 Driver Readiness + UINT32 CSTS; ///< Offset 0x104 Status + UINT32 CEVT; ///< Offset 0x108 Current Event + UINT8 RM11[0x14]; ///< Offset 0x10C Reserved Must be Zero + UINT32 DIDL[8]; ///< Offset 0x120 Supported Display Devices ID List + UINT32 CPDL[8]; ///< Offset 0x140 obsolete + UINT32 CADL[8]; ///< Offset 0x160 obsolete + UINT32 NADL[8]; ///< Offset 0x180 obsolete + UINT32 ASLP; ///< Offset 0x1A0 ASL Sleep Time Out + UINT32 TIDX; ///< Offset 0x1A4 obsolete + UINT32 CHPD; ///< Offset 0x1A8 obsolete + UINT32 CLID; ///< Offset 0x1AC Current Lid State Indicator + UINT32 CDCK; ///< Offset 0x1B0 Current Docking State Indicator + UINT32 SXSW; ///< Offset 0x1B4 obsolete + UINT32 EVTS; ///< Offset 0x1B8 obsolete + UINT32 CNOT; ///< Offset 0x1BC obsolete + UINT32 NRDY; ///< Offset 0x1C0 Driver Status + UINT8 DID2[0x1C]; ///< Offset 0x1C4 Extended Supported Devices ID List (DOD) + UINT8 CPD2[0x1C]; ///< Offset 0x1E0 obsolete + UINT8 RM12[4]; ///< Offset 0x1FC - 0x1FF Reserved Must be zero +} IGD_OPREGION_MBOX1_VER_3_0; + +/// +/// OpRegion Mailbox 2 - Backlight communication /// Offset 0x200, Size +0x100 /// typedef struct { + UINT32 BCL1; ///< Offset 0x200 Backlight Brightness for LFP1 + UINT32 BCL2; ///< Offset 0x204 Backlight Brightness for LFP2 + UINT32 CBL1; ///< Offset 0x208 Current User Brightness Level for LFP1 + UINT32 CBL2; ///< Offset 0x20C Current User Brightness Level for LFP2 + UINT32 BCM1[0x1E]; ///< Offset 0x210 Backlight Brightness Levels Duty Cycle Mapping Table for LFP1 + UINT32 BCM2[0x1E]; ///< Offset 0x288 Backlight Brightness Levels Duty Cycle Mapping Table for LFP2 +} IGD_OPREGION_MBOX2_VER_3_0; + +/// +/// OpRegion Mailbox 3 - BIOS/Driver Notification - ASLE Support /// +Offset 0x300, Size 0x100 /// typedef struct { + UINT32 ARDY; ///< Offset 0x300 obsolete + UINT32 ASLC; ///< Offset 0x304 obsolete + UINT32 TCHE; ///< Offset 0x308 obsolete + UINT32 ALSI; ///< Offset 0x30C obsolete + UINT32 BCLP; ///< Offset 0x310 obsoleted in ver 3.0, moved to Mailbox 2. + UINT32 PFIT; ///< Offset 0x314 obsolete + UINT32 CBLV; ///< Offset 0x318 obsoleted in ver 3.0, moved to Mailbox 2. + UINT16 BCLM[0x14]; ///< Offset 0x31C obsoleted in ver 3.0, moved to Mailbox 2. + UINT32 CPFM; ///< Offset 0x344 obsolete + UINT32 EPFM; ///< Offset 0x348 obsolete + UINT8 PLUT[0x4A]; ///< Offset 0x34C obsolete + UINT32 PFMB; ///< Offset 0x396 obsolete + UINT32 CCDV; ///< Offset 0x39A obsolete + UINT32 PCFT; ///< Offset 0x39E obsolete + UINT32 SROT; ///< Offset 0x3A2 obsolete + UINT32 IUER; ///< Offset 0x3A6 obsolete + UINT64 FDSS; ///< Offset 0x3AA obsolete + UINT32 FDSP; ///< Offset 0x3B2 obsolete + UINT32 STAT; ///< Offset 0x3B6 obsolete + UINT64 RVDA; ///< Offset 0x3BA Physical address of Raw VBT data. Added from Spec Version 0.90 to support VBT greater than 6KB. + UINT32 RVDS; ///< Offset 0x3C2 Size of Raw VBT data. Added from Spec Version 0.90 to support VBT greater than 6KB. + UINT8 VRSR; ///< Offset 0x3C6 Video RAM Self Refresh + UINT64 DLHP; ///< Offset 0x3C7 Dual LFP Hinge Alignment Parameters + UINT8 RM32[0x31]; ///< Offset 0x3CF - 0x3FF Reserved Must be zero. +} IGD_OPREGION_MBOX3_VER_3_0; + +/// +/// IGD OpRegion Structure +/// +typedef struct { + IGD_OPREGION_HEADER Header; ///< OpRegion header (Offset 0x0, Size 0x100) + IGD_OPREGION_MBOX1_VER_3_0 MBox1; ///< Mailbox 1: Public ACPI +Methods (Offset 0x100, Size 0x100) + IGD_OPREGION_MBOX2_VER_3_0 MBox2; ///< Mailbox 2: Backlight +communication (Offset 0x200, Size 0x100) + IGD_OPREGION_MBOX3_VER_3_0 MBox3; ///< Mailbox 3: BIOS to Driver Notification (Offset 0x300, Size 0x100) + IGD_OPREGION_MBOX4 MBox4; ///< Mailbox 4: Video BIOS Table (VBT) (Offset 0x400, Size 0x1800) + IGD_OPREGION_MBOX5 MBox5; ///< Mailbox 5: BIOS to Driver Notification Extension (Offset 0x1C00, Size 0x400) +} IGD_OPREGION_STRUCTURE_VER_3_0; +#pragma pack() + +#endif -- 2.30.2.windows.1
|
|
|
|
Re: [PATCH] UefiCpuPkg: ResetVector Tool Support for Python 3
Hi.,
toggle quoted messageShow quoted text
Based on Ray Feedback. I have sent the patchset includes 1 and 2. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3506 Regards, Ashraf Ali S Intel Technology India Pvt. Ltd.
-----Original Message-----
From: Ni, Ray <ray.ni@intel.com> Sent: Friday, July 23, 2021 8:03 AM To: S, Ashraf Ali <ashraf.ali.s@intel.com>; devel@edk2.groups.io Cc: Kumar, Rahul1 <rahul1.kumar@intel.com>; De, Debkumar <debkumar.de@intel.com>; Han, Harry <harry.han@intel.com>; West, Catharine <catharine.west@intel.com>; V, Sangeetha <sangeetha.v@intel.com> Subject: RE: [PATCH] UefiCpuPkg: ResetVector Tool Support for Python 3 Ashraf, I assume that your previous ResetVector patch can be dropped, and we just review this one that supports python3 first, right? Since this patch is for the feedbacks of patch separation, can you help to do it further? 1. only do minimal update to the python script to make it python3 capable. No additional printing. 2. add additional printing in 2nd patch 3. submit new .raw binary in a new patch serial because this binary update is not because of python3 but the out-of-dated binary. To make it clear, 1 and 2 are two patches that belong to the same patch set. 3 is a separate patch. Thanks, Ray -----Original Message-----
|
|
|
|
Re: [PATCH V2 4/4] OvmfPkg/ResetVector: Update ResetVector to support Tdx
Lendacky, Thomas
On 7/22/21 5:58 PM, Xu, Min M wrote:
On July 23, 2021 1:08 AM, Tom Lendacky wrote:I believe PcdOvmfSecGhcbBackupBase can be cleared early. For SEV-ES, itOn 7/22/21 12:52 AM, Min Xu wrote:TDX_WORK_AREA is piece of TdxMailbox which is located in the MEMFD startedRFC: https://bugzilla.tianocore.org/show_bug.cgi?id=3429Is the memory area guaranteed to be zeroed for legacy guests? Hopefully, isn't shared with the hypervisor, so clearing it before activating the pagetables can be done (it will be treated as encrypted before paging is enabled and mapped as encrypted after paging is enabled) and for a legacy guest the mapping doesn't matter. It isn't required to be cleared today, so if you do add something, be sure to put a comment in there about why it's being done. No need for a new area. The possibility of random data being there that matches 'TDXG' is extremely low. But better safe than sorry, I guess. Thanks, Tom
|
|
|
|
Re: ArmVirt and Self-Updating Code
Marvin Häuser <mhaeuser@...>
On 23.07.21 12:13, Ard Biesheuvel wrote:
On Fri, 23 Jul 2021 at 11:55, Marvin Häuser <mhaeuser@posteo.de> wrote:Hmm, the GCC docs say a GOT is used for "all constant addresses" (I took it as "absolute"?), it is kind of vague. I understood it this way:On 22.07.21 17:14, Ard Biesheuvel wrote:The primary reason to use -fpie and PIE linking is to ensure that theOn Thu, 22 Jul 2021 at 16:54, Bret Barkelew<Bret.Barkelew@microsoft.com> wrote:And I understood it right that the idea is to use "-fpie" toExpanding audience to the full dev list…"Mapping" implies that the MMU is on, but this code boots with the MMU 1) no-pie emits relocations that can target the .text and .data sections for instructions that embed and variables that hold an absolute address (I thought this was RELA?) 2) pie emits a GOT such that there are no relocations as described in 1), because all absolute addresses are indirected by GOT (just GOT references are relocated) If I understood the process right, but the term (GOT) is wrong, sorry, that is what I gathered from the docs. :) I have a x86 + PE background, so ARM + ELF is a bit of a learning curve... For instance, a statically initialized pointer always carries anAnd this is not forced by whatever table -fpie uses, as per my understanding above? That is what I meant to imply with the middle question (well, not necessarily "lazy", for ARM there simply seems to not be any reason to distinguish if the environments are fully separate), just wanted to make sure I understand what the code does before modifying it.If the FFS SecCore section type is used here, it does not mean thatAs per your comments below, I think SecCore should not be located here.“Now, StandaloneMmPkg has similar (self-)relocation code too:https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c#L379-L386No. Thank you again! Best regards, Marvin My pleasure.Interesting... this definitely is vastly different from the x86 side of“This yields the following questions to me:It is not spawned by the normal world code that runs UEFI. It is a
|
|
|
|
回复: [edk2-devel] [PATCH v1 5/6] UefiPayloadPkg: Add DISABLE_MMX_SSE to avoid generating floating points operation
gaoliming
How do you add this support in tools_def? Can you give the proposal for it?
Thanks Liming 发件人: Cheng-Chieh Huang <chengchieh@...>
I mean, I will submit a patch to support DISABLE_GCC_MMX_SSE in tools_def. What do you think?
-- Cheng-Chieh
On Thu, Jul 22, 2021 at 9:28 AM gaoliming <gaoliming@...> wrote:
|
|
|
|
Re: ArmVirt and Self-Updating Code
Ard Biesheuvel
On Fri, 23 Jul 2021 at 11:55, Marvin Häuser <mhaeuser@posteo.de> wrote:
The primary reason to use -fpie and PIE linking is to ensure that the resulting ELF executable contains a RELA section that describes every location in the binary where a memory address is stored that needs to be updated according to the actual placement in memory. The side effect of -fpie is that position independent global references are emitted (i.e., ADRP/ADD instructions which are relative to the program counter). However, the AArch64 compiler uses those by default anyway, so for this it is not strictly needed. 2) emit a GOT, which ends up being converted to PE/COFF Relocations (->It is not really a GOT. Actually, a GOT is undesirable, as it forces global variables to be referenced via an absolute address, even when a relative reference could be used. For instance, a statically initialized pointer always carries an absolute address, and so it always needs an entry in the RELA table E.g., int foo = 10; // external linkage static int *bar = &foo; In this case, there is no way to use relative addressing because the address of foo is taken at build time. However, if bar would be something like static int *bar() { return &foo; } the address is only taken at runtime, and the compiler can use a relative reference instead, and no RELA entry is needed. With a GOT, we force the compiler to allocate a variable that holds the absolute address, which we would prefer to avoid. If the FFS SecCore section type is used here, it does not mean thatAs per your comments below, I think SecCore should not be located here.“Now, StandaloneMmPkg has similar (self-)relocation code too:https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c#L379-L386No. the image is a SEC image in the strict PI sense. Perhaps we were just too lazy to add a new type to the FFS spec? My pleasure.Interesting... this definitely is vastly different from the x86 side of“This yields the following questions to me:It is not spawned by the normal world code that runs UEFI. It is a
|
|
|
|
Re: ArmVirt and Self-Updating Code
Marvin Häuser <mhaeuser@...>
On 22.07.21 17:14, Ard Biesheuvel wrote:
On Thu, 22 Jul 2021 at 16:54, Bret Barkelew<Bret.Barkelew@microsoft.com> wrote:And I understood it right that the idea is to use "-fpie" toExpanding audience to the full dev list…"Mapping" implies that the MMU is on, but this code boots with the MMU 1) have all control flow instructions be position-independent (i.e. jumps, calls, etc; ARM docs don't spill it out, but vaguely imply this always is possible?), and 2) emit a GOT, which ends up being converted to PE/COFF Relocations (-> self-relocation), for global data that cannot be referenced relatively? Is there any way to know/force that no symbol in GOT is accessed up until the end of the self-relocation process? As per your comments below, I think SecCore should not be located here. Is the Standalone MM core of *type* SecCore in the FFS (without *being* SecCore)? This confused me the most.“Now, StandaloneMmPkg has similar (self-)relocation code too:https://github.com/tianocore/edk2/blob/17143c4837393d42c484b42d1789b85b2cff1aaf/StandaloneMmPkg/Library/StandaloneMmCoreEntryPoint/AArch64/StandaloneMmCoreEntryPoint.c#L379-L386No. Interesting... this definitely is vastly different from the x86 side of things. I think most things became very clear. Thanks a lot!“This yields the following questions to me:It is not spawned by the normal world code that runs UEFI. It is a I'll check it some time, hopefully this weekend. Thanks!4) Is there maybe some high-level documented about the ARM boot flow? It seems to be significantly different from the x86 routes quite vastly.”trustedfirmware.org may have some useful documentation. Best regards, Marvin Hoping that one of you could get me closer to an answer for him. Also happy to take this to the greater mailing list, but thought I’d avoid churn.
|
|
|
|
[edk2-platform PATCH v1 1/1] Platform/RaspberryPi: Make SetVariable return EFI_UNSUPPORTED at runtime
Sunny Wang
The RPi does not support storing UEFI NV variables at runtime. For now,
gRT->SetVariable at runtime returns EFI_OUT_OF_RESOURCES which is not a proper error and would cause FWTS failures. Therefore, this patch is to make gRT->SetVariable at runtime return EFI_UNSUPPORTED. For more information, please check the issues below: -https://github.com/pftf/RPi4/issues/6 -https://github.com/pftf/RPi4/issues/93 -https://github.com/pftf/RPi4/issues/163 I also tested this with the ACS 3.0 FWTS. All the failures reported in issue 93 and 163 can be fixed by this patch. Cc: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Jeremy Linton <jeremy.linton@arm.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Pete Batard <pete@akeo.ie> Cc: Leif Lindholm <leif@nuviainc.com> Signed-off-by: Sunny Wang <sunny.wang@arm.com> --- .../Drivers/VarBlockServiceDxe/VarBlockService.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockServ= ice.c b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockService.c index 572309439a..16d4d4f178 100644 --- a/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockService.c +++ b/Platform/RaspberryPi/Drivers/VarBlockServiceDxe/VarBlockService.c @@ -2,6 +2,7 @@ * * Copyright (c) 2018, Andrei Warkentin <andrey.warkentin@gmail.com> * Copyright (c) 2006-2014, Intel Corporation. All rights reserved. + * Copyright (c) 2021, ARM Limited. All rights reserved. * * SPDX-License-Identifier: BSD-2-Clause-Patent * @@ -596,6 +597,7 @@ FvbProtocolWrite ( EFI_DEVICE_ERROR - The block device is not functioning correctl= y and could not be written EFI_INVALID_PARAMETER - NumBytes or Buffer are NULL + EFI_UNSUPPORTED This function is not supported at runtime =20 --*/ { @@ -605,6 +607,16 @@ FvbProtocolWrite ( EFI_STATUS Status; EFI_STATUS ReturnStatus; =20 + // + // The current variables support relies on modifying RPI_EFI.FD on SD + // card, which works fine at boot time. However, at runtime, the SD=20 + // controller is exposed via ACPI and subsequently owned by the OS. + // Therefore, we need to direclty return EFI_UNSUPPORTED. + // + if (EfiAtRuntime ()) { + return EFI_UNSUPPORTED; + } + // // Check for invalid conditions. // --=20 2.31.0.windows.1
|
|
|
|
Re: [edk2-platform][PATCH v1 1/1] EmbeddedPkg/VirtualRealTimeClockLib : Fix SetTime issues
Sunny Wang
Sorry, please ignore this one. I sent the patch with the wrong subject. This change is made in edk2 rather than the edk2-platform.
toggle quoted messageShow quoted text
Please review the later one "[edk2-devel] [PATCH 1/1] EmbeddedPkg/VirtualRealTimeClockLib : Fix SetTime issues". Thanks! https://edk2.groups.io/g/devel/topic/patch_1_1/84397263 Best Regards, Sunny Wang
-----Original Message-----
From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of Sunny Wang via groups.io Sent: Friday, July 23, 2021 5:01 PM To: devel@edk2.groups.io Cc: Sunny Wang <Sunny.Wang@arm.com>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Sami Mujawar <Sami.Mujawar@arm.com>; Jeremy Linton <Jeremy.Linton@arm.com>; Ard Biesheuvel <ardb+tianocore@kernel.org>; Pete Batard <pete@akeo.ie>; Leif Lindholm <leif@nuviainc.com>; Sunny Wang <Sunny.Wang@arm.com> Subject: [edk2-devel] [edk2-platform][PATCH v1 1/1] EmbeddedPkg/VirtualRealTimeClockLib : Fix SetTime issues This patch fixes two issues below: 1. SCT SetTime_Func failures. - https://github.com/pftf/RPi4/issues/164 2. Using shell time and date commands to set time can't work. The problem is that gRT->SetTime always returns EFI_INVALID_PARAMETER error status. The root cause is that LibSetTime() sets RtcEpochSeconds variable with inconsistent attributes. One is without EFI_VARIABLE_NON_VOLATILE, the other one is with EFI_VARIABLE_NON_VOLATILE. That caused that the variable driver returns EFI_INVALID_PARAMETER. Per UEFI spec, if a preexisting variable is rewritten with different attributes, SetVariable() shall not modify the variable and shall return EFI_INVALID_PARAMETER. Therefore, the solution is to add EFI_VARIABLE_NON_VOLATILE attribute to the first EfiSetVariable() call to make two calls consistent. By the way, this patch also fix a minor issue with a debug message. Cc: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Jeremy Linton <jeremy.linton@arm.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Pete Batard <pete@akeo.ie> Cc: Leif Lindholm <leif@nuviainc.com> Signed-off-by: Sunny Wang <sunny.wang@arm.com> --- .../VirtualRealTimeClockLib/VirtualRealTimeClockLib.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c index de6fbb40e6..c10c91bc75 100644 --- a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c +++ b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c @@ -4,7 +4,7 @@ * * Coypright (c) 2019, Pete Batard <pete@akeo.ie> * Copyright (c) 2018, Andrei Warkentin <andrey.warkentin@gmail.com> - * Copyright (c) 2011-2014, ARM Ltd. All rights reserved. + * Copyright (c) 2011-2021, ARM Ltd. All rights reserved. * Copyright (c) 2008-2010, Apple Inc. All rights reserved. * Copyright (c) Microsoft Corporation. All rights reserved. * @@ -96,7 +96,7 @@ LibGetTime ( EfiSetVariable ( (CHAR16 *)mEpochVariableName, &gEfiCallerIdGuid, - EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, + EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, sizeof (EpochSeconds), &EpochSeconds ); @@ -324,7 +324,7 @@ LibSetTime ( DEBUG (( DEBUG_ERROR, "LibSetTime: Failed to save %s variable to non-volatile storage, Status = %r\n", - mDaylightVariableName, + mEpochVariableName, Status )); return Status; -- 2.31.0.windows.1 -=-=-=-=-=-= Groups.io Links: You receive all messages sent to this group. View/Reply Online (#78123): https://edk2.groups.io/g/devel/message/78123 Mute This Topic: https://groups.io/mt/84397232/5985097 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [Sunny.Wang@arm.com] -=-=-=-=-=-= IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
|
|
|
|
[PATCH 1/1] EmbeddedPkg/VirtualRealTimeClockLib : Fix SetTime issues
Sunny Wang
This patch fixes two issues below:
1. SCT SetTime_Func failures. - https://github.com/pftf/RPi4/issues/164 2. Using shell time and date commands to set time can't work. The problem is that gRT->SetTime always returns EFI_INVALID_PARAMETER error status. The root cause is that LibSetTime() sets RtcEpochSeconds variable with inconsistent attributes. One is without EFI_VARIABLE_NON_VOLATILE, the other one is with EFI_VARIABLE_NON_VOLATILE. That caused that the variable driver returns EFI_INVALID_PARAMETER. Per UEFI spec, if a preexisting variable is rewritten with different attributes, SetVariable() shall not modify the variable and shall return EFI_INVALID_PARAMETER. Therefore, the solution is to add EFI_VARIABLE_NON_VOLATILE attribute to the first EfiSetVariable() call to make two calls consistent. By the way, this patch also fix a minor issue with a debug message. Cc: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Jeremy Linton <jeremy.linton@arm.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Pete Batard <pete@akeo.ie> Cc: Leif Lindholm <leif@nuviainc.com> Signed-off-by: Sunny Wang <sunny.wang@arm.com> --- .../VirtualRealTimeClockLib/VirtualRealTimeClockLib.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeC= lockLib.c b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeCl= ockLib.c index de6fbb40e6..c10c91bc75 100644 --- a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib= .c +++ b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib= .c @@ -4,7 +4,7 @@ * * Coypright (c) 2019, Pete Batard <pete@akeo.ie> * Copyright (c) 2018, Andrei Warkentin <andrey.warkentin@gmail.com> - * Copyright (c) 2011-2014, ARM Ltd. All rights reserved. + * Copyright (c) 2011-2021, ARM Ltd. All rights reserved. * Copyright (c) 2008-2010, Apple Inc. All rights reserved. * Copyright (c) Microsoft Corporation. All rights reserved. * @@ -96,7 +96,7 @@ LibGetTime ( EfiSetVariable ( (CHAR16 *)mEpochVariableName, &gEfiCallerIdGuid, - EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, + EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_= VARIABLE_RUNTIME_ACCESS, sizeof (EpochSeconds), &EpochSeconds ); @@ -324,7 +324,7 @@ LibSetTime ( DEBUG (( DEBUG_ERROR, "LibSetTime: Failed to save %s variable to non-volatile storage, S= tatus =3D %r\n", - mDaylightVariableName, + mEpochVariableName, Status )); return Status; --=20 2.31.0.windows.1
|
|
|
|
[edk2-platform][PATCH v1 1/1] EmbeddedPkg/VirtualRealTimeClockLib : Fix SetTime issues
Sunny Wang
This patch fixes two issues below:
1. SCT SetTime_Func failures. - https://github.com/pftf/RPi4/issues/164 2. Using shell time and date commands to set time can't work. The problem is that gRT->SetTime always returns EFI_INVALID_PARAMETER error status. The root cause is that LibSetTime() sets RtcEpochSeconds variable with inconsistent attributes. One is without EFI_VARIABLE_NON_VOLATILE, the other one is with EFI_VARIABLE_NON_VOLATILE. That caused that the variable driver returns EFI_INVALID_PARAMETER. Per UEFI spec, if a preexisting variable is rewritten with different attributes, SetVariable() shall not modify the variable and shall return EFI_INVALID_PARAMETER. Therefore, the solution is to add EFI_VARIABLE_NON_VOLATILE attribute to the first EfiSetVariable() call to make two calls consistent. By the way, this patch also fix a minor issue with a debug message. Cc: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@arm.com> Cc: Sami Mujawar <sami.mujawar@arm.com> Cc: Jeremy Linton <jeremy.linton@arm.com> Cc: Ard Biesheuvel <ardb+tianocore@kernel.org> Cc: Pete Batard <pete@akeo.ie> Cc: Leif Lindholm <leif@nuviainc.com> Signed-off-by: Sunny Wang <sunny.wang@arm.com> --- .../VirtualRealTimeClockLib/VirtualRealTimeClockLib.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeC= lockLib.c b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeCl= ockLib.c index de6fbb40e6..c10c91bc75 100644 --- a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib= .c +++ b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib= .c @@ -4,7 +4,7 @@ * * Coypright (c) 2019, Pete Batard <pete@akeo.ie> * Copyright (c) 2018, Andrei Warkentin <andrey.warkentin@gmail.com> - * Copyright (c) 2011-2014, ARM Ltd. All rights reserved. + * Copyright (c) 2011-2021, ARM Ltd. All rights reserved. * Copyright (c) 2008-2010, Apple Inc. All rights reserved. * Copyright (c) Microsoft Corporation. All rights reserved. * @@ -96,7 +96,7 @@ LibGetTime ( EfiSetVariable ( (CHAR16 *)mEpochVariableName, &gEfiCallerIdGuid, - EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS, + EFI_VARIABLE_NON_VOLATILE | EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_= VARIABLE_RUNTIME_ACCESS, sizeof (EpochSeconds), &EpochSeconds ); @@ -324,7 +324,7 @@ LibSetTime ( DEBUG (( DEBUG_ERROR, "LibSetTime: Failed to save %s variable to non-volatile storage, S= tatus =3D %r\n", - mDaylightVariableName, + mEpochVariableName, Status )); return Status; --=20 2.31.0.windows.1
|
|
|
|
[PATCH v2 2/2] UefiCpuPkg: ResetVector Tool additional debug prints
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3506
Before executing the nasm command, added print statement to know what commands are executing. before printing the output file need check the status of command which is executed. if the status is 0 then only print the output file name. Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Debkumar De <debkumar.de@intel.com> Cc: Harry Han <harry.han@intel.com> Cc: Catharine West <catharine.west@intel.com> Cc: Sangeetha V <sangeetha.v@intel.com> Signed-off-by: Ashraf Ali S <ashraf.ali.s@intel.com> --- UefiCpuPkg/ResetVector/Vtf0/Build.py | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/UefiCpuPkg/ResetVector/Vtf0/Build.py b/UefiCpuPkg/ResetVector/Vtf0/Build.py index 55f4edd87b..b791d32762 100644 --- a/UefiCpuPkg/ResetVector/Vtf0/Build.py +++ b/UefiCpuPkg/ResetVector/Vtf0/Build.py @@ -32,9 +32,12 @@ for arch in ('ia32', 'x64'): '-o', output, 'Vtf0.nasmb', ) + print(f"Command : {' '.join(commandLine)}") ret = RunCommand(commandLine) + if ret != 0: + print(f"something went wrong while executing {commandLine[-1]}") + sys.exit() print('\tASM\t' + output) - if ret != 0: sys.exit(ret) commandLine = ( 'python', -- 2.30.2.windows.1
|
|
|
|
[PATCH v2 1/2] UefiCpuPkg: ResetVector Tool Support for Python 3
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3506
Build Scrips for Reset Vector currently based on Python 2 which is already EOL, needs to modify the build script based on Python 3 Cc: Ray Ni <ray.ni@intel.com> Cc: Rahul Kumar <rahul1.kumar@intel.com> Cc: Debkumar De <debkumar.de@intel.com> Cc: Harry Han <harry.han@intel.com> Cc: Catharine West <catharine.west@intel.com> Cc: Sangeetha V <sangeetha.v@intel.com> Signed-off-by: Ashraf Ali S <ashraf.ali.s@intel.com> --- UefiCpuPkg/ResetVector/Vtf0/Build.py | 6 +++--- UefiCpuPkg/ResetVector/Vtf0/Tools/FixupForRawSection.py | 4 ++-- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/UefiCpuPkg/ResetVector/Vtf0/Build.py b/UefiCpuPkg/ResetVector/Vtf0/Build.py index 343c53b5ff..55f4edd87b 100644 --- a/UefiCpuPkg/ResetVector/Vtf0/Build.py +++ b/UefiCpuPkg/ResetVector/Vtf0/Build.py @@ -1,7 +1,7 @@ ## @file # Automate the process of building the various reset vector types # -# Copyright (c) 2009, Intel Corporation. All rights reserved.<BR> +# Copyright (c) 2009 - 2021, Intel Corporation. All rights reserved.<BR> # # SPDX-License-Identifier: BSD-2-Clause-Patent # @@ -33,7 +33,7 @@ for arch in ('ia32', 'x64'): 'Vtf0.nasmb', ) ret = RunCommand(commandLine) - print '\tASM\t' + output + print('\tASM\t' + output) if ret != 0: sys.exit(ret) commandLine = ( @@ -41,7 +41,7 @@ for arch in ('ia32', 'x64'): 'Tools/FixupForRawSection.py', output, ) - print '\tFIXUP\t' + output + print('\tFIXUP\t' + output) ret = RunCommand(commandLine) if ret != 0: sys.exit(ret) diff --git a/UefiCpuPkg/ResetVector/Vtf0/Tools/FixupForRawSection.py b/UefiCpuPkg/ResetVector/Vtf0/Tools/FixupForRawSection.py index c77438a0ce..de771eba22 100644 --- a/UefiCpuPkg/ResetVector/Vtf0/Tools/FixupForRawSection.py +++ b/UefiCpuPkg/ResetVector/Vtf0/Tools/FixupForRawSection.py @@ -1,7 +1,7 @@ ## @file # Apply fixup to VTF binary image for FFS Raw section # -# Copyright (c) 2008, Intel Corporation. All rights reserved.<BR> +# Copyright (c) 2008 - 2021, Intel Corporation. All rights reserved.<BR> # # SPDX-License-Identifier: BSD-2-Clause-Patent # @@ -15,6 +15,6 @@ c = ((len(d) + 4 + 7) & ~7) - 4 if c > len(d): c -= len(d) f = open(sys.argv[1], 'wb') - f.write('\x90' * c) + f.write(b'\x90' * c) f.write(d) f.close() -- 2.30.2.windows.1
|
|
|
|
Re: [PATCH EDK2 v1 1/1] MdeModulePkg: Modify PCD default value
wanghuiqiang
Dear all,
toggle quoted messageShow quoted text
Any comments for this change? Thanks!
-----Original Message-----
From: wanghuiqiang Sent: Monday, July 19, 2021 2:37 PM To: 'devel@edk2.groups.io' <devel@edk2.groups.io>; 'ray.ni@intel.com' <ray.ni@intel.com>; xiewenyi (A) <xiewenyi2@huawei.com>; 'Wang, Jian J' <jian.j.wang@intel.com>; 'Wu, Hao A' <hao.a.wu@intel.com>; 'Ard Biesheuvel' <ardb@kernel.org>; 'Leif Lindholm' <leif@nuviainc.com>; 'sami.mujawar@arm.com' <sami.mujawar@arm.com> Cc: Songdongkuang <songdongkuang@huawei.com> Subject: RE: [edk2-devel] [PATCH EDK2 v1 1/1] MdeModulePkg: Modify PCD default value + Ard, Leif, Sami. All OSes which use 64KB page size and the PCIe resource allocation rely on BIOS initialization will encounter VF BAR resource allocation issue. Thanks！ -----Original Message----- From: wanghuiqiang Sent: Monday, July 19, 2021 2:02 PM To: devel@edk2.groups.io; 'ray.ni@intel.com' <ray.ni@intel.com>; xiewenyi (A) <xiewenyi2@huawei.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com> Cc: Songdongkuang <songdongkuang@huawei.com> Subject: RE: [edk2-devel] [PATCH EDK2 v1 1/1] MdeModulePkg: Modify PCD default value Hi Ray, 52 bit address ranges are supported only when using the 64KB translation granule for ARM64 platform, this is another scenario using 64K page size. We need set PcdSrIovSystemPageSize to 0x10 in such case to make BIOS resource assignment still appropriate even PCI DSM#5 function set as 0 which means the operating system must preserve PCI resource assignments made by firmware at boot time. Please let me know if you have any other concern for this patch. Thanks! -----Original Message----- From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Ni, Ray Sent: Monday, July 19, 2021 10:35 AM To: devel@edk2.groups.io; xiewenyi (A) <xiewenyi2@huawei.com>; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com> Cc: Songdongkuang <songdongkuang@huawei.com>; wanghuiqiang <wanghuiqiang@huawei.com> Subject: Re: [edk2-devel] [PATCH EDK2 v1 1/1] MdeModulePkg: Modify PCD default value Wenyi, Can you explain a bit more about "if 52 bit physical address need to be supported, page size should also be set to 64KB alignment"? Can the platform DSC override this value instead of changing the default value in MdeModulePkg.dec which impacts all platforms? Thanks, Ray -----Original Message----- From: devel@edk2.groups.io <devel@edk2.groups.io> On Behalf Of wenyi,xie via groups.io Sent: Thursday, July 15, 2021 8:25 PM To: devel@edk2.groups.io; Wang, Jian J <jian.j.wang@intel.com>; Wu, Hao A <hao.a.wu@intel.com> Cc: songdongkuang@huawei.com; wanghuiqiang@huawei.com; xiewenyi2@huawei.com Subject: [edk2-devel] [PATCH EDK2 v1 1/1] MdeModulePkg: Modify PCD default value From: "wenyi.xie" <xiewenyi2@huawei.com> The default value of PcdSrIovSystemPageSize is 0x1, it means the memory BAR is 4KB alignment. When page size of OS is set to 64KB, as the resource partitions are different between OS and BIOS, it will cause pcie failture. And if 52 bit physical address need to be supported, page size should also be set to 64KB alignment. So modify the default vaule of PcdSrIovSystemPageSize to 0x10 can meet the requirement above. And even if the OS is 4KB alignment, new value of PCD is compatible for this situation. Cc: Jian J Wang <jian.j.wang@intel.com> Cc: Hao A Wu <hao.a.wu@intel.com> Signed-off-by: Wenyi Xie <xiewenyi2@huawei.com> --- MdeModulePkg/MdeModulePkg.dec | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec index ad84421cf3..426ea1b6cc 100644 --- a/MdeModulePkg/MdeModulePkg.dec +++ b/MdeModulePkg/MdeModulePkg.dec @@ -1853,7 +1853,7 @@ # BIT0 set indicates 4KB alignment<BR> # BIT1 set indicates 8KB alignment<BR> # @Prompt SRIOV system page size. - gEfiMdeModulePkgTokenSpaceGuid.PcdSrIovSystemPageSize|0x1|UINT32|0x10000047 + + gEfiMdeModulePkgTokenSpaceGuid.PcdSrIovSystemPageSize|0x10|UINT32|0x10 + 000047 ## SMBIOS version. # @Prompt SMBIOS version. -- 2.20.1.windows.1
|
|
|
|
Re: [EXT] RE: [PATCH V2 3/4] NXP/LS1046aFrwyPkg: Enable ConfigurationManager on LS1046AFRWY
Vikas Singh <vikas.singh@...>
Sunny, Thank you for reviewing my code. Here are my remarks. PSB
toggle quoted messageShow quoted text
-----Original Message-----
From: Sunny Wang <Sunny.Wang@arm.com> Sent: Monday, July 12, 2021 4:08 PM To: Vikas Singh <vikas.singh@puresoftware.com>; devel@edk2.groups.io Cc: Sami Mujawar <Sami.Mujawar@arm.com>; leif@nuviainc.com; Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; Varun Sethi <V.Sethi@nxp.com>; arokia.samy <arokia.samy@puresoftware.com>; kuldip dwivedi <kuldip.dwivedi@puresoftware.com>; Ard Biesheuvel <Ard.Biesheuvel@arm.com>; Vikas Singh <vikas.singh@nxp.com>; White Weng <white.weng@nxp.com>; Ran Wang <ran.wang_1@nxp.com>; Sunny Wang <Sunny.Wang@arm.com> Subject: [EXT] RE: [PATCH V2 3/4] NXP/LS1046aFrwyPkg: Enable ConfigurationManager on LS1046AFRWY Caution: EXT Email Hi Vikas, Just have two comments below. Others look good to me. 1. In LS1046aFrwyPkg.dsc, since you already include DynamicTablesPkg/DynamicTables.dsc.inc, I think we need to remove DynamicTableFactoryDxe.inf code block. Could you check this? [[VIKAS]] No, DynamicTableFactoryDxe.inf code block Is required to override, or I would say to choose what we want for our platform from DynamicTablesPkg. This block can expose different "inf" files for different platforms as per the need basis. 2. Remove " DEFINE DYNAMIC_ACPI_ENABLE = TRUE ". In our offline discussion, this would cause some build problems with the current CM implementation (Multiple NXP platforms share One CM folder). [[VIKAS]] I don't think "DEFINE DYNAMIC_ACPI_ENABLE = TRUE" should cause any problem while building other platforms. In fact this flag is to avoid any build issue with other platforms. CM is common for all layer scape platforms but it will be only visible to any platform if and only if "DEFINE DYNAMIC_ACPI_ENABLE = TRUE". Else platform must be building in old native mode. Could you share any scenario or something that I have missed out, will check this implementation and try to rectify. Best Regards, Sunny Wang -----Original Message----- From: Vikas Singh <vikas.singh@puresoftware.com> Sent: Friday, June 18, 2021 11:28 PM To: devel@edk2.groups.io Cc: Sami Mujawar <Sami.Mujawar@arm.com>; leif@nuviainc.com; Meenakshi Aggarwal (meenakshi.aggarwal@nxp.com) <meenakshi.aggarwal@nxp.com>; Samer El-Haj-Mahmoud <Samer.El-Haj-Mahmoud@arm.com>; V Sethi (v.sethi@nxp.com) <v.sethi@nxp.com>; arokia.samy <arokia.samy@puresoftware.com>; kuldip.dwivedi@puresoftware.com; Ard Biesheuvel <Ard.Biesheuvel@arm.com>; vikas.singh@nxp.com; Sunny Wang <Sunny.Wang@arm.com> Subject: [PATCH V2 3/4] NXP/LS1046aFrwyPkg: Enable ConfigurationManager on LS1046AFRWY This patch enables the use of ConfigurationManager (CM) and its services to leverage the Dynamic ACPI support for NXP's LS1046aFrwy platform. Signed-off-by: Vikas Singh <vikas.singh@puresoftware.com> --- Platform/NXP/LS1046aFrwyPkg/Include/Platform.h | 152 ++++++++++++++++++++ Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.dsc | 28 ++++ Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.fdf | 13 ++ Silicon/NXP/LS1046A/LS1046A.dsc.inc | 11 ++ 4 files changed, 204 insertions(+) diff --git a/Platform/NXP/LS1046aFrwyPkg/Include/Platform.h b/Platform/NXP/LS1046aFrwyPkg/Include/Platform.h new file mode 100644 index 0000000000..3c68d65cd3 --- /dev/null +++ b/Platform/NXP/LS1046aFrwyPkg/Include/Platform.h @@ -0,0 +1,152 @@ +/** @file + * Platform headers + * + * Copyright 2021 NXP + * Copyright 2021 Puresoftware Ltd + * + * SPDX-License-Identifier: BSD-2-Clause-Patent + * +**/ + + +#ifndef LS1046AFRWY_PLATFORM_H +#define LS1046AFRWY_PLATFORM_H + +#define EFI_ACPI_ARM_OEM_REVISION 0x00000000 + +// Soc defines +#define PLAT_SOC_NAME "LS1046AFRWY" + +// Gic +#define GIC_VERSION 2 +#define GICD_BASE 0x1410000 +#define GICC_BASE 0x142f000 +#define GICH_BASE 0x1440000 +#define GICV_BASE 0x1460000 + +// UART +#define UART0_BASE 0x21C0500 +#define UART0_IT 86 +#define UART0_LENGTH 0x100 +#define SPCR_FLOW_CONTROL_NONE 0 + +// Timer +#define TIMER_BLOCK_COUNT 1 +#define TIMER_FRAME_COUNT 4 +#define TIMER_WATCHDOG_COUNT 1 +#define TIMER_BASE_ADDRESS 0x23E0000 // a.k.a CNTControlBase +#define TIMER_READ_BASE_ADDRESS 0x23F0000 // a.k.a CNTReadBase +#define TIMER_SEC_IT 29 +#define TIMER_NON_SEC_IT 30 +#define TIMER_VIRT_IT 27 +#define TIMER_HYP_IT 26 +#define TIMER_FRAME0_IT 78 +#define TIMER_FRAME1_IT 79 +#define TIMER_FRAME2_IT 92 + +// Mcfg +#define LS1046A_PCI_SEG0_CONFIG_BASE 0x4000000000 +#define LS1046A_PCI_SEG0 0x0 +#define LS1046A_PCI_SEG_BUSNUM_MIN 0x0 +#define LS1046A_PCI_SEG_BUSNUM_MAX 0xff +#define LS1046A_PCI_SEG1_CONFIG_BASE 0x4800000000 +#define LS1046A_PCI_SEG2_CONFIG_BASE 0x5000000000 +#define LS1046A_PCI_SEG1 0x1 +#define LS1046A_PCI_SEG2 0x2 + +// Platform specific info needed by Configuration Manager + +#define CFG_MGR_TABLE_ID SIGNATURE_64 ('L','S','1','0','4','6',' ',' +') + +// Specify the OEM defined tables +#define OEM_ACPI_TABLES 0 + +#define PLAT_PCI_SEG0 LS1046A_PCI_SEG0 +#define PLAT_PCI_SEG1_CONFIG_BASE LS1046A_PCI_SEG1_CONFIG_BASE +#define PLAT_PCI_SEG1 LS1046A_PCI_SEG1 +#define PLAT_PCI_SEG_BUSNUM_MIN LS1046A_PCI_SEG_BUSNUM_MIN +#define PLAT_PCI_SEG_BUSNUM_MAX LS1046A_PCI_SEG_BUSNUM_MAX +#define PLAT_PCI_SEG2_CONFIG_BASE LS1046A_PCI_SEG2_CONFIG_BASE +#define PLAT_PCI_SEG2 LS1046A_PCI_SEG2 + +#define PLAT_GIC_VERSION GIC_VERSION +#define PLAT_GICD_BASE GICD_BASE +#define PLAT_GICI_BASE GICI_BASE +#define PLAT_GICR_BASE GICR_BASE +#define PLAT_GICR_LEN GICR_LEN +#define PLAT_GICC_BASE GICC_BASE +#define PLAT_GICH_BASE GICH_BASE +#define PLAT_GICV_BASE GICV_BASE + +#define PLAT_CPU_COUNT 4 +#define PLAT_GTBLOCK_COUNT 0 +#define PLAT_GTFRAME_COUNT 0 +#define PLAT_PCI_CONFG_COUNT 2 + +#define PLAT_WATCHDOG_COUNT 0 +#define PLAT_GIC_REDISTRIBUTOR_COUNT 0 +#define PLAT_GIC_ITS_COUNT 0 + +/* GIC CPU Interface information + GIC_ENTRY (CPUInterfaceNumber, Mpidr, PmuIrq, VGicIrq, + EnergyEfficiency) + */ +#define PLAT_GIC_CPU_INTERFACE { \ + GICC_ENTRY (0, GET_MPID (0, 0), 138, 0x19, 0), \ + GICC_ENTRY (1, GET_MPID (0, 1), 139, 0x19, 0), \ + GICC_ENTRY (2, GET_MPID (0, 2), 127, 0x19, 0), \ + GICC_ENTRY (3, GET_MPID (0, 3), 129, 0x19, 0), \ +} + +#define PLAT_WATCHDOG_INFO \ + { \ + } \ + +#define PLAT_TIMER_BLOCK_INFO \ + { \ + } \ + +#define PLAT_TIMER_FRAME_INFO \ + { \ + } \ + +#define PLAT_GIC_DISTRIBUTOR_INFO \ + { \ + PLAT_GICD_BASE, /* UINT64 PhysicalBaseAddress */ \ + 0, /* UINT32 SystemVectorBase */ \ + PLAT_GIC_VERSION /* UINT8 GicVersion */ \ + } \ + +#define PLAT_GIC_REDISTRIBUTOR_INFO \ + { \ + } \ + +#define PLAT_GIC_ITS_INFO \ + { \ + } \ + +#define PLAT_MCFG_INFO \ + { \ + { \ + PLAT_PCI_SEG1_CONFIG_BASE, \ + PLAT_PCI_SEG1, \ + PLAT_PCI_SEG_BUSNUM_MIN, \ + PLAT_PCI_SEG_BUSNUM_MAX, \ + }, \ + { \ + PLAT_PCI_SEG2_CONFIG_BASE, \ + PLAT_PCI_SEG2, \ + PLAT_PCI_SEG_BUSNUM_MIN, \ + PLAT_PCI_SEG_BUSNUM_MAX, \ + } \ + } \ + +#define PLAT_SPCR_INFO \ + { \ + UART0_BASE, \ + UART0_IT, \ + 115200, \ + 0, \ + EFI_ACPI_SERIAL_PORT_CONSOLE_REDIRECTION_TABLE_INTERFACE_TYPE_16550 \ + } \ + +#endif // LS1046AFRWY_PLATFORM_H diff --git a/Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.dsc b/Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.dsc index 67cf15cbe4..20111e6037 100755 --- a/Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.dsc +++ b/Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.dsc @@ -3,6 +3,7 @@ # LS1046AFRWY Board package. # # Copyright 2019-2020 NXP +# Copyright 2021 Puresoftware Ltd # # SPDX-License-Identifier: BSD-2-Clause-Patent # @@ -22,10 +23,18 @@ OUTPUT_DIRECTORY = Build/LS1046aFrwyPkg FLASH_DEFINITION = Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.fdf + # This flag controls the dynamic acpi generation + # + DEFINE DYNAMIC_ACPI_ENABLE = TRUE + !include Silicon/NXP/NxpQoriqLs.dsc.inc !include MdePkg/MdeLibs.dsc.inc !include Silicon/NXP/LS1046A/LS1046A.dsc.inc +!if $(DYNAMIC_ACPI_ENABLE) == TRUE + !include DynamicTablesPkg/DynamicTables.dsc.inc +!endif + [LibraryClasses.common] ArmPlatformLib|Platform/NXP/LS1046aFrwyPkg/Library/ArmPlatformLib/ArmPlatformLib.inf RealTimeClockLib|EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf @@ -46,4 +55,23 @@ Silicon/NXP/Drivers/UsbHcdInitDxe/UsbHcd.inf + # + # Dynamic Table Factory + !if $(DYNAMIC_ACPI_ENABLE) == TRUE + + DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/DynamicTableFactoryDxe + .inf { + <LibraryClasses> + + NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiFadtLibArm/AcpiFadtLibArm.i + nf + + NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiGtdtLibArm/AcpiGtdtLibArm.i + nf + + NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiMadtLibArm/AcpiMadtLibArm.i + nf + + NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiMcfgLibArm/AcpiMcfgLibArm.i + nf + + NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/AcpiSpcrLibArm.i + nf + } + !endif + + # + # Acpi Support + # + MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf + MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf + ## diff --git a/Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.fdf b/Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.fdf index 34c4e5a025..f3cac033bc 100755 --- a/Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.fdf +++ b/Platform/NXP/LS1046aFrwyPkg/LS1046aFrwyPkg.fdf @@ -3,6 +3,7 @@ # FLASH layout file for LS1046a board. # # Copyright 2019-2020 NXP +# Copyright 2021 Puresoftware Ltd # # SPDX-License-Identifier: BSD-2-Clause-Patent # @@ -99,6 +100,18 @@ READ_LOCK_STATUS = TRUE INF MdeModulePkg/Universal/Metronome/Metronome.inf INF MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf + + # + # Acpi Support + # + INF MdeModulePkg/Universal/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf + INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf + + !if $(DYNAMIC_ACPI_ENABLE) == TRUE + INF + Platform/NXP/ConfigurationManagerPkg/ConfigurationManagerDxe/Configura + tionManagerDxe.inf + !include DynamicTablesPkg/DynamicTables.fdf.inc + !endif + # # Multiple Console IO support # diff --git a/Silicon/NXP/LS1046A/LS1046A.dsc.inc b/Silicon/NXP/LS1046A/LS1046A.dsc.inc index 7004533ed5..caebb321d0 100644 --- a/Silicon/NXP/LS1046A/LS1046A.dsc.inc +++ b/Silicon/NXP/LS1046A/LS1046A.dsc.inc @@ -2,6 +2,7 @@ # LS1046A Soc package. # # Copyright 2017-2020 NXP +# Copyright 2021-2021 Puresoftware Ltd # # SPDX-License-Identifier: BSD-2-Clause-Patent # @@ -48,4 +49,14 @@ [Components.common] MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf +# +# Configuration Manager +!if $(DYNAMIC_ACPI_ENABLE) == TRUE + + Platform/NXP/ConfigurationManagerPkg/ConfigurationManagerDxe/Configura + tionManagerDxe.inf { + <BuildOptions> + *_*_*_PLATFORM_FLAGS = + -I$(WORKSPACE)/Platform/NXP/LS1046aFrwyPkg/Include + *_*_*_PLATFORM_FLAGS = + -I$(WORKSPACE)/Silicon/NXP/Chassis2/Include + } +!endif + ## -- 2.25.1 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
|
|
|
|
Re: [PATCH v2] MinPlatformPkg/PciHostBridgeLibSimple: Fix Mem.Limit assignment
Chiu, Chasel
Thanks for fixing this issue! Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
toggle quoted messageShow quoted text
-----Original Message-----
|
|
|
|
Re: RFC: EXT4 filesystem driver
The EFI System Partition is defined to be FAT32 by the UEFI Spec for interoperability. It defines the file system drivers required for the firmware and OS. So changing that is not really an option. You can still install the UEFI Shell to a read only file system, you just need to do it from the OS :). We actually do this on Macs quite often. You just run the macOS bless command and reboot to the UEFI Shell. Thanks, Andrew Fish
|
|
|
|
Adding HTTP boot IO timeout programmability from PcdHttpIoTimeout
Clark-williams, Zachary <zachary.clark-williams@...>
Hello,
Please review the attached filed EDK2 tracker for feature enablement of programmable timeout of the HTTP boot IO timer. NetworkPkg-HttpBoot: Making the HTTP IO timeout value programmable with PCD. HTTP boot has a default set forced timeout value of 5 seconds for getting the recovery image from a remote source. This change allows the HTTP boot flow to get the IO timeout value from the PcdHttpIoTimeout. PcdHttpIoTimeout value is set in the OneClickRecovery driver from the value provided by CSME.
Thank you, Zack
|
|
|
|
Re: [PATCH] UefiCpuPkg VTF0 X64: Build page tables using 1-GByte Page Granularity
Ni, Ray
Ashraf,
toggle quoted messageShow quoted text
Thanks for the summary. Can you send a V2 patch which only take cares the 1G page table assembly logic? Thanks, Ray
-----Original Message-----
|
|
|