Re: [edk2] [edk2-test][Patch 1/1] SctPkg/UEFI: Remove redefined macro
On 4/2/19 5:16 PM, Eric Jin wrote:
> Remove the macros which are already defined in
> MdePkg/Include/Uefi/UefiInternalFormRepersentation.h
>
> Cc: Supreeth Venkatesh
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Jin
> ---
> uefi-sct/SctPkg/UEFI/Protocol/HiiDef.h | 44
> +---
> 1 file changed, 1 insertion(+), 43 deletions(-)
>
> diff --git a/uefi-sct/SctPkg/UEFI/Protocol/HiiDef.h
> b/uefi-sct/SctPkg/UEFI/Protocol/HiiDef.h
> index 33340ae60d41..b20d2a1b4162 100644
> --- a/uefi-sct/SctPkg/UEFI/Protocol/HiiDef.h
> +++ b/uefi-sct/SctPkg/UEFI/Protocol/HiiDef.h
> @@ -1,7 +1,7 @@
> /** @file
>
>Copyright 2006 - 2017 Unified EFI, Inc.
> - Copyright (c) 2010, Intel Corporation. All rights reserved.
> + Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
>(C) Copyright 2017 Hewlett Packard Enterprise Development LP
>Copyright (c) 2019, ARM Ltd. All rights reserved.
>
> @@ -156,13 +156,6 @@ typedef struct _EFI_HII_DEVICE_PATH_PACKAGE {
>EFI_DEVICE_PATH_PROTOCOL *DevicePath;
> } EFI_HII_DEVICE_PATH_PACKAGE;
>
> -//
> -// String Package
> -//
> -
> -#define UEFI_CONFIG_LANG L"x-UEFI"
> -#define UEFI_CONFIG_LANG2 L"x-i-UEFI" // BUGBUG, spec need to be
> updated.
This one is weirdly defined as UEFI_CONFIG_LANG_2 in
BaseTools/Source/C/Include/Common/UefiInternalFormRepresentation.h.
> -
> #define EFI_HII_SIBT_END 0x00
> #define EFI_HII_SIBT_STRING_SCSU 0x10
> #define EFI_HII_SIBT_STRING_SCSU_FONT0x11
> @@ -330,39 +323,4 @@ EFI_STATUS
>IN EFI_HII_DATABASE_NOTIFY_TYPENotifyType
> );
>
> -#define EFI_NULL_MODIFIER 0x
> -#define EFI_LEFT_CONTROL_MODIFIER 0x0001
> -#define EFI_RIGHT_CONTROL_MODIFIER 0x0002
> -#define EFI_LEFT_ALT_MODIFIER 0x0003
> -#define EFI_RIGHT_ALT_MODIFIER 0x0004
> -#define EFI_ALT_GR_MODIFIER0x0005
> -#define EFI_INSERT_MODIFIER0x0006
> -#define EFI_DELETE_MODIFIER0x0007
> -#define EFI_PAGE_DOWN_MODIFIER 0x0008
> -#define EFI_PAGE_UP_MODIFIER 0x0009
> -#define EFI_HOME_MODIFIER 0x000A
> -#define EFI_END_MODIFIER 0x000B
> -#define EFI_LEFT_SHIFT_MODIFIER0x000C
> -#define EFI_RIGHT_SHIFT_MODIFIER 0x000D
> -#define EFI_CAPS_LOCK_MODIFIER 0x000E
> -#define EFI_NUM_LOCK _MODIFIER 0x000F
Eh this one is definitively broken...
> -#define EFI_LEFT_ARROW_MODIFIER0x0010
> -#define EFI_RIGHT_ARROW_MODIFIER 0x0011
> -#define EFI_DOWN_ARROW_MODIFIER0x0012
> -#define EFI_UP_ARROW_MODIFIER 0X0013
> -#define EFI_NS_KEY_MODIFIER0x0014
> -#define EFI_NS_KEY_DEPENDENCY_MODIFIER 0x0015
> -#define EFI_FUNCTION_KEY_ONE_MODIFIER 0x0016
> -#define EFI_FUNCTION_KEY_TWO_MODIFIER 0x0017
> -#define EFI_FUNCTION_KEY_THREE_MODIFIER0x0018
> -#define EFI_FUNCTION_KEY_FOUR_MODIFIER 0x0019
> -#define EFI_FUNCTION_KEY_FIVE_MODIFIER 0x001A
> -#define EFI_FUNCTION_KEY_SIX_MODIFIER 0x001B
> -#define EFI_FUNCTION_KEY_SEVEN_MODIFIER0x001C
> -#define EFI_FUNCTION_KEY_EIGHT_MODIFIER0x001D
> -#define EFI_FUNCTION_KEY_NINE_MODIFIER 0x001E
> -#define EFI_FUNCTION_KEY_TEN_MODIFIER 0x001F
> -#define EFI_FUNCTION_KEY_ELEVEN_MODIFIER 0x0020
> -#define EFI_FUNCTION_KEY_TWELVE_MODIFIER 0x0021
> -
> #endif
>
Reviewed-by: Philippe Mathieu-Daude
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/CapsulePei: Update the debug code to print 64bit data
Hi Bret,
On 4/2/19 7:50 AM, Zhichao Gao wrote:
> From: Bret Barkelew
>
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1677
>
> For some pointer and UINT64 data, the debug code print with '%x'.
> Which would loss the upper 32bit data. So update '%x' to '%lx'
> for these data.
Some are UINTN. Per Laszlo answer on this thread:
https://lists.01.org/pipermail/edk2-devel/2016-September/002093.html
for those, casting and changing format is the accepted way.
However this is a change,
> Change the DEBUG PrintLevel from EFI_D_ version to DEBUG_ version.
> DEBUG_ version is recommended to use.
and this is another change.
Splitting this patch in 2 would make it more digestable.
>
> Cc: Jian J Wang
> Cc: Ray Ni
> Cc: Star Zeng
> Cc: Liming Gao
> Cc: Sean Brogan
> Cc: Michael Turner
> Cc: Bret Barkelew
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Zhichao Gao
> ---
> .../CapsulePei/Common/CapsuleCoalesce.c | 90 +--
> .../Universal/CapsulePei/UefiCapsule.c| 46 +-
> .../Universal/CapsulePei/X64/X64Entry.c | 2 +-
> 3 files changed, 69 insertions(+), 69 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c
> b/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c
> index 3575a94d0f..2a527054bd 100644
> --- a/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c
> +++ b/MdeModulePkg/Universal/CapsulePei/Common/CapsuleCoalesce.c
> @@ -258,7 +258,7 @@ ValidateCapsuleByMemoryResource (
>// Sanity Check
>//
>if (Size > MAX_ADDRESS) {
> -DEBUG ((EFI_D_ERROR, "ERROR: Size(0x%lx) > MAX_ADDRESS\n", Size));
> +DEBUG ((DEBUG_ERROR, "ERROR: Size(0x%lx) > MAX_ADDRESS\n", Size));
> return FALSE;
>}
>
> @@ -266,7 +266,7 @@ ValidateCapsuleByMemoryResource (
>// Sanity Check
>//
>if (Address > (MAX_ADDRESS - Size)) {
> -DEBUG ((EFI_D_ERROR, "ERROR: Address(0x%lx) > (MAX_ADDRESS -
> Size(0x%lx))\n", Address, Size));
> +DEBUG ((DEBUG_ERROR, "ERROR: Address(0x%lx) > (MAX_ADDRESS -
> Size(0x%lx))\n", Address, Size));
> return FALSE;
>}
>
> @@ -280,14 +280,14 @@ ValidateCapsuleByMemoryResource (
>for (Index = 0; MemoryResource[Index].ResourceLength != 0; Index++) {
> if ((Address >= MemoryResource[Index].PhysicalStart) &&
> ((Address + Size) <= (MemoryResource[Index].PhysicalStart +
> MemoryResource[Index].ResourceLength))) {
> - DEBUG ((EFI_D_INFO, "Address(0x%lx) Size(0x%lx) in
> MemoryResource[0x%x] - Start(0x%lx) Length(0x%lx)\n",
> + DEBUG ((DEBUG_INFO, "Address(0x%lx) Size(0x%lx) in
> MemoryResource[0x%x] - Start(0x%lx) Length(0x%lx)\n",
>Address, Size,
>Index, MemoryResource[Index].PhysicalStart,
> MemoryResource[Index].ResourceLength));
>return TRUE;
> }
>}
>
> - DEBUG ((EFI_D_ERROR, "ERROR: Address(0x%lx) Size(0x%lx) not in any
> MemoryResource\n", Address, Size));
> + DEBUG ((DEBUG_ERROR, "ERROR: Address(0x%lx) Size(0x%lx) not in any
> MemoryResource\n", Address, Size));
>return FALSE;
> }
>
> @@ -312,7 +312,7 @@ ValidateCapsuleIntegrity (
>UINTN CapsuleCount;
>EFI_CAPSULE_BLOCK_DESCRIPTOR *Ptr;
>
> - DEBUG ((EFI_D_INFO, "ValidateCapsuleIntegrity\n"));
> + DEBUG ((DEBUG_INFO, "ValidateCapsuleIntegrity\n"));
>
>//
>// Go through the list to look for inconsistencies. Check for:
> @@ -333,15 +333,15 @@ ValidateCapsuleIntegrity (
> return NULL;
>}
>
> - DEBUG ((EFI_D_INFO, "Ptr - 0x%x\n", Ptr));
> - DEBUG ((EFI_D_INFO, "Ptr->Length - 0x%x\n", Ptr->Length));
> - DEBUG ((EFI_D_INFO, "Ptr->Union - 0x%x\n",
> Ptr->Union.ContinuationPointer));
> + DEBUG ((DEBUG_INFO, "Ptr - 0x%lx\n", (UINT64)Ptr));
> + DEBUG ((DEBUG_INFO, "Ptr->Length - 0x%lx\n", Ptr->Length));
> + DEBUG ((DEBUG_INFO, "Ptr->Union - 0x%lx\n",
> Ptr->Union.ContinuationPointer));
>while ((Ptr->Length != 0) || (Ptr->Union.ContinuationPointer !=
> (EFI_PHYSICAL_ADDRESS) (UINTN) NULL)) {
> //
> // Make sure the descriptor is aligned at UINT64 in memory
> //
> if ((UINTN) Ptr & (sizeof(UINT64) - 1)) {
> - DEBUG ((EFI_D_ERROR, "ERROR: BlockList address failed alignment
> check\n"));
> + DEBUG ((DEBUG_ERROR, "ERROR: BlockList address failed alignment
> check\n"));
>return NULL;
> }
>
> @@ -354,9 +354,9 @@ ValidateCapsuleIntegrity (
>if (!ValidateCapsuleByMemoryResource (MemoryResource,
> (EFI_PHYSICAL_ADDRESS) (UINTN) Ptr, sizeof (EFI_CAPSULE_BLOCK_DESCRIPTOR))) {
> return NULL;
>}
> - DEBUG ((EFI_D_INFO, "Ptr(C) - 0x%x\n", Ptr));
> - DEBUG ((EFI_D_INFO, "Ptr->Length - 0x%x\n", Ptr->Length));
> - DEBUG ((EFI_D_INFO, "Ptr->Union - 0x%x\n",
> Ptr->Union.ContinuationPointer));
> + DEBUG ((DEBUG_INFO, "Ptr(C) - 0x%lx\n", (UINT64)Ptr));
> + DEBUG ((DEBUG_INFO, "Ptr->Length - 0x%lx\n", Ptr->Length
Re: [edk2] [Patch V3] BaseTools: Add python3-distutils Ubuntu package checking
On 2/28/19 2:29 PM, Feng, Bob C wrote:
> Hi Phil,
>
> Your suggested code is good but it still print the call stack. I changed it a
> little, it only print the error message now.
>
> Thanks,
> Bob
>
> -Original Message-
> From: Feng, Bob C
> Sent: Thursday, February 28, 2019 9:19 PM
> To: edk2-devel@lists.01.org
> Cc: Feng, Bob C ; Gao, Liming
> Subject: [Patch V3] BaseTools: Add python3-distutils Ubuntu package checking
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=1509
>
> Add python3-distutils Ubuntu package checking.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng
> Cc: Liming Gao
> ---
> BaseTools/Tests/RunTests.py | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/BaseTools/Tests/RunTests.py b/BaseTools/Tests/RunTests.py index
> 0dd65632d0..356c1d600c 100644
> --- a/BaseTools/Tests/RunTests.py
> +++ b/BaseTools/Tests/RunTests.py
> @@ -17,10 +17,17 @@
> #
> import os
> import sys
> import unittest
>
> +try:
> +import distutils.util
> +except ModuleNotFoundError:
> +sys.exit('''
> +Python reported: "No module named 'distutils.uitl'"
Again: 'uitl' -> 'util'
Can the maintainer fix that typo before applying?
Although I find the current error message a bit opaque for the user.
To be clearer and tell the user this is not a problem within EDK2 but in
his setup, I suggest a more explicit "Required module 'distutils.util'
not found".
Regardless, with the 'uitl' typo fixed:
Reviewed-by: Philippe Mathieu-Daude
Thanks,
Phil.
> +''')
> +
> import TestTools
>
> def GetCTestSuite():
> import CToolsTests
> return CToolsTests.TheTestSuite()
> --
> 2.20.1.windows.1
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch V2] BaseTools: Add python3-distutils Ubuntu package checking
On 2/28/19 3:04 AM, Feng, Bob C wrote:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1509
> V2:
> Remove OS/Package specific words. Print the error info which
> is from python error message.
>
> Add python3-distutils Ubuntu package checking.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng
> Cc: Liming Gao
> ---
> BaseTools/Tests/RunTests.py | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/BaseTools/Tests/RunTests.py b/BaseTools/Tests/RunTests.py
> index 0dd65632d0..f6d3f43653 100644
> --- a/BaseTools/Tests/RunTests.py
> +++ b/BaseTools/Tests/RunTests.py
> @@ -17,10 +17,22 @@
> #
> import os
> import sys
> import unittest
>
> +distutils_exist = True
Why this variable? You can achieve the same without adding variables in
the global namespace.
> +try:
> +import distutils.util
> +except:
I'd restrict that to ImportError, just in case.
> +distutils_exist = False
> +
> +if not distutils_exist:
> +print("""
> +Python report "No module named 'distutils.uitl'"
'distutils.util' ;)
> +""")
> +sys.exit(-1)
Per the sys.exit doc:
The optional argument arg can be an integer giving the exit status
(defaulting to zero), or another type of object. If it is an integer,
zero is considered “successful termination” and any nonzero value is
considered “abnormal termination” by shells and the like. Most systems
require it to be in the range 0–127, and produce undefined results
otherwise.
Can we avoid to use negative return values?
I suggest to simply use this snippet:
try:
import distutils.util
except ImportError as error:
sys.exit("Python reported: " + error.message)
Note the difference with your patch are:
- no global namespace variable used
- exception not Import related still display stack dump
- the error message is displayed on stderr rather than stdout
- the return value is 1 instead of -1
Regards,
Phil.
> import TestTools
>
> def GetCTestSuite():
> import CToolsTests
> return CToolsTests.TheTestSuite()
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Maintainers.txt: clarify Reviewer requirements and responsibilities
On 2/27/19 10:21 PM, Laszlo Ersek wrote: > The current language for "Package Reviewer" only vaguely hints that > Package Reviewers should be able to provide guidance and directions. > Make this more obvious. > > Cc: Andrew Fish > Cc: Ard Biesheuvel > Cc: Leif Lindholm > Cc: Liming Gao > Cc: Michael D Kinney > Cc: Philippe Mathieu-Daude > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Laszlo Ersek > --- > > Notes: > - this is clearly a political patch; feel free to disagree > - I'm proposing this for the next development cycle > > Maintainers.txt | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/Maintainers.txt b/Maintainers.txt > index 7772926b2fb1..ed090aeb4bdb 100644 > --- a/Maintainers.txt > +++ b/Maintainers.txt > @@ -20,7 +20,10 @@ Descriptions of section entries: >M: Package Maintainer: Cc address for patches and questions. Responsible > for reviewing and pushing package changes to source control. >R: Package Reviewer: Cc address for patches and questions. Reviewers help > - maintainers review code, but don't have push access. > + maintainers review code, but don't have push access. A designated > Package > + Reviewer is reasonably familiar with the Package (or some modules > + thereof), and/or provides testing or regression testing for the Package > + (or some modules thereof), in certain platforms and environments. Definitively an improvement, thanks for clarifying this. Reviewed-by: Philippe Mathieu-Daude >W: Web-page with status/info >T: SCM tree type and location. Type is one of: git, svn. >S: Status, one of the following: > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Maintainers.txt: Register myself as OvmfPkg/ArmVirtPkg reviewer
Hi, On 2/21/19 10:13 PM, Philippe Mathieu-Daude wrote: > Part of my assignment is to review OVMF and ArmVirt patches, > having my address listed will help me to catch the related > patches. I had a misunderstanding regarding how EDK2 treats a 'R:' tag, as I understood it as similar to Linux/QEMU, which is simply "reviewers should be CCed on patches". Since EDK2 R: tag seems somehow different, but the description is not explicit: R: Package Reviewer: Cc address for patches and questions. Reviewers help maintainers review code, but don't have push access. Can someone improve the documentation? Meanwhile please disregard this inappropriate patch. Thanks, Phil. > > Signed-off-by: Philippe Mathieu-Daude > --- > Maintainers.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Maintainers.txt b/Maintainers.txt > index 7772926b2f..3c17038fab 100644 > --- a/Maintainers.txt > +++ b/Maintainers.txt > @@ -82,6 +82,7 @@ M: Laszlo Ersek > M: Ard Biesheuvel > R: Julien Grall > (Xen modules) > +R: Philippe Mathieu-Daudé > > BaseTools > W: https://github.com/tianocore/tianocore.github.io/wiki/BaseTools > @@ -225,6 +226,7 @@ R: Marc-André Lureau > (TPM2 modules) > R: Stefan Berger > (TPM2 modules) > +R: Philippe Mathieu-Daudé > S: Maintained > > PcAtChipsetPkg > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCHv2 1/1] MdeModulePkg/SdMmcPciHcDxe Fix eMMC HS400 switch sequence
Hi Hao A,
On 2/20/19 2:11 AM, Wu, Hao A wrote:
> Thanks Mateusz,
>
> Reviewed-by: Hao Wu
> And pushed via commit 68c67d3a2a33261e41ff0123129b4e9759617f71.
I think you mean "pushed 'after' commit
68c67d3a2a33261e41ff0123129b4e9759617f71".
Commit 68c67d3a2a33261e41ff0123129b4e9759617f71 is:
"BaseTools: Fixed a code bug for Pcd Array", while
this patch is commited as 195f673f6270aaf73dd34b75f1da26451b63c316.
Now about this commit 195f673f6270aaf, I think you have an issue with
your configuration, as the patch author was remplaced from:
Albecki, Mateusz
to:
Albecki, Mateusz
Regards,
Phil.
>
> Best Regards,
> Hao Wu
>
>
>> -Original Message-
>> From: Albecki, Mateusz
>> Sent: Monday, February 18, 2019 7:12 PM
>> To: edk2-devel@lists.01.org
>> Cc: Albecki, Mateusz; Wu, Hao A
>> Subject: [PATCHv2 1/1] MdeModulePkg/SdMmcPciHcDxe Fix eMMC HS400
>> switch sequence
>>
>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1140
>>
>> In eMMC HS400 switch sequence flow eMMC driver attempted
>> to execute SEND_STATUS just after switching bus timing to high
>> speed and before downgrading clock frequency to 52MHz. Since link
>> was at that time in incorrect state SEND_STATUS was failing which
>> made driver think switch to HS400 failed.
>> This change makes driver always change clock frequency after
>> switching bus timing and before executing SEND_STATUS.
>>
>> Cc: Hao Wu
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Albecki Mateusz
>> ---
>> MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c | 39
>> +
>> 1 file changed, 20 insertions(+), 19 deletions(-)
>>
>> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
>> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
>> index 4ef849fd0962..15db8a87a5c4 100644
>> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
>> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
>> @@ -642,7 +642,7 @@ EmmcSwitchBusWidth (
>> }
>>
>> /**
>> - Switch the clock frequency to the specified value.
>> + Switch the bus timing and clock frequency.
>>
>>Refer to EMMC Electrical Standard Spec 5.1 Section 6.6 and SD Host
>> Controller
>>Simplified Spec 3.0 Figure 3-3 for details.
>> @@ -660,7 +660,7 @@ EmmcSwitchBusWidth (
>>
>> **/
>> EFI_STATUS
>> -EmmcSwitchClockFreq (
>> +EmmcSwitchBusTiming (
>>IN EFI_PCI_IO_PROTOCOL*PciIo,
>>IN EFI_SD_MMC_PASS_THRU_PROTOCOL *PassThru,
>>IN UINT8 Slot,
>> @@ -689,22 +689,10 @@ EmmcSwitchClockFreq (
>>
>>Status = EmmcSwitch (PassThru, Slot, Access, Index, Value, CmdSet);
>>if (EFI_ERROR (Status)) {
>> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: Switch to hstiming %d
>> fails with %r\n", HsTiming, Status));
>> +DEBUG ((DEBUG_ERROR, "EmmcSwitchBusTiming: Switch to hstiming %d
>> fails with %r\n", HsTiming, Status));
>> return Status;
>>}
>>
>> - Status = EmmcSendStatus (PassThru, Slot, Rca, &DevStatus);
>> - if (EFI_ERROR (Status)) {
>> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: Send status fails
>> with %r\n", Status));
>> -return Status;
>> - }
>> - //
>> - // Check the switch operation is really successful or not.
>> - //
>> - if ((DevStatus & BIT7) != 0) {
>> -DEBUG ((DEBUG_ERROR, "EmmcSwitchClockFreq: The switch operation
>> fails as DevStatus is 0x%08x\n", DevStatus));
>> -return EFI_DEVICE_ERROR;
>> - }
>>//
>>// Convert the clock freq unit from MHz to KHz.
>>//
>> @@ -713,6 +701,19 @@ EmmcSwitchClockFreq (
>> return Status;
>>}
>>
>> + Status = EmmcSendStatus (PassThru, Slot, Rca, &DevStatus);
>> + if (EFI_ERROR (Status)) {
>> +DEBUG ((DEBUG_ERROR, "EmmcSwitchBusTiming: Send status fails
>> with %r\n", Status));
>> +return Status;
>> + }
>> + //
>> + // Check the switch operation is really successful or not.
>> + //
>> + if ((DevStatus & BIT7) != 0) {
>> +DEBUG ((DEBUG_ERROR, "EmmcSwitchBusTiming: The switch operation
>> fails as DevStatus is 0x%08x\n", DevStatus));
>> +return EFI_DEVICE_ERROR;
>> + }
>> +
>>if (mOverride != NULL && mOverride->NotifyPhase != NULL) {
>> Status = mOverride->NotifyPhase (
>>Private->ControllerHandle,
>> @@ -799,7 +800,7 @@ EmmcSwitchToHighSpeed (
>>}
>>
>>HsTiming = 1;
>> - Status = EmmcSwitchClockFreq (PciIo, PassThru, Slot, Rca, HsTiming,
>> Timing,
>> ClockFreq);
>> + Status = EmmcSwitchBusTiming (PciIo, PassThru, Slot, Rca, HsTiming,
>> Timing, ClockFreq);
>>
>>return Status;
>> }
>> @@ -887,7 +888,7 @@ EmmcSwitchToHS200 (
>>Status = SdMmcHcOrMmio (PciIo, Slot, SD_MMC_HC_CLOCK_CTRL, sizeof
>> (ClockCtrl), &ClockCtrl);
>>
>>HsTiming = 2;
>> - Status = EmmcSwitchClockFreq (PciIo, PassThru, Slot, Rca, HsTiming,
>> Timing,
>> ClockFreq);
>> + Status = EmmcSwitchBusTiming (PciIo, PassThru, Slot, Rca, HsTiming,
>> Timing, ClockFreq);
>>if (EFI_ERROR (Status)) {
>> return Status;
>>}
>> @@ -937
Re: [edk2] nonzero LUN on USB Bulk Only Transfer fails with QEMU+edk2
Hi Laszlo,
On 2/13/19 9:37 AM, Laszlo Ersek wrote:
> Hi,
>
> using QEMU, when I specify a nonzero LUN for the hard disk that sits on
> the "SCSI bus" that embodies the USB Bulk Only Transfer device, then
> UsbMassStorageDxe fails to recognize the hard disk.
>
> (1) Consider the following QEMU command line snippet:
>
> -drive id=disk1,if=none,format=raw,readonly,file=$APPDISK \
> -device qemu-xhci,id=xhci1,p3=15,addr=02.0 \
> -device usb-bot,bus=xhci1.0,port=3,id=bot1 \
Do you have a specific need to use the 'usb-bot' device?
> -device scsi-hd,drive=disk1,bus=bot1.0,lun=0,bootindex=1 \
>
> For this (i.e., lun=0), I see the following INQUIRY exchange between
> UsbMassStorageDxe and QEMU:
>
>> Lun=0 InquiryCmd {
>> Lun=0 InquiryCmd 00 12 00 00 00 24 00 00 00 00 00 00 00
>> Lun=0 InquiryCmd }
>> Lun=0 InquiryData {
>> Lun=0 InquiryData 00 00 00 05 12 1F 00 00 10 51 45 4D 55 20 20 20 20
>> Lun=0 InquiryData 10 51 45 4D 55 20 48 41 52 44 44 49 53 4B 20 20 20
>> Lun=0 InquiryData 20 32 2E 35 2B
>> Lun=0 InquiryData }
>
> The vendor and product ID fields translate to "QEMU" and
> "QEMU_HARDDISK___", respectively. (For easier reading, I replaced the
> space characters with underscores, for the sake of better
> readability/wrapping.)
>
> In this case, edk2 recognizes the disk and things work fine.
>
> (In fact, for lun=0, the QemuBootOrderLib pattern matching / translation
> works fine as well -- verifying which was my original goal, before I ran
> into the issues below, for nonzero LUNs. But, I digress.)
>
>
> (2) If I change the cmdline to "lun=5", then the exchange is:
>From qemu/docs/usb-storage.txt:
The LUN numbers must be continuous, i.e. for three devices you must
use 0+1+2. The 0+1+5 numbering from the "usb-uas" example isn't going
to work with "usb-bot".
A failure is expected :/
>
>> Lun=0 InquiryCmd {
>> Lun=0 InquiryCmd 00 12 00 00 00 24 00 00 00 00 00 00 00
>> Lun=0 InquiryCmd }
>> Lun=0 InquiryData {
>> Lun=0 InquiryData 00 3F 00 05 12 1F 00 00 10 51 45 4D 55 20 20 20 20
>> Lun=0 InquiryData 10 51 45 4D 55 20 54 41 52 47 45 54 20 20 20 20 20
>> Lun=0 InquiryData 20 32 2E 35 00
>> Lun=0 InquiryData }
>
> Here the product ID is unchanged, but the vendor ID becomes
> "QEMU_TARGET_".
>
> And, edk2 fails to recognize the device:
>
>> UsbBootGetParams: Found an unsupported peripheral type[31]
>> UsbMassInitMedia: UsbBootGetParams (Unsupported)
>> UsbMassInitNonLun: UsbMassInitMedia (Unsupported)
>> USBMassDriverBindingStart: UsbMassInitNonLun (Unsupported)
>
> This happens because the first byte in the response is 0x3F. QEMU sets
> this byte in
>
>> r->buf[0] = TYPE_NOT_PRESENT | TYPE_INACTIVE;
>
> in function scsi_target_emulate_inquiry(), file "hw/scsi/scsi-bus.c".
>
> And edk2 parses the byte in UsbBootInquiry() and UsbBootGetParams()
> (file "MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.c"):
>
>> typedef struct {
>> UINT8 Pdt;///< Peripheral Device Type (low 5 bits)
>> UINT8 Removable; ///< Removable Media (highest bit)
>> UINT8 Reserved0[2];
>> UINT8 AddLen; ///< Additional length
>> UINT8 Reserved1[3];
>> UINT8 VendorID[8];
>> UINT8 ProductID[16];
>> UINT8 ProductRevision[4];
>> } USB_BOOT_INQUIRY_DATA;
>
>> #define USB_BOOT_PDT(Pdt) ((Pdt) & 0x1f)
>
>> UsbMass->Pdt = (UINT8) (USB_BOOT_PDT (UsbMass->InquiryData.Pdt));
>
>> //
>> // According to USB Mass Storage Specification for Bootability, only
>> following
>> // 4 Peripheral Device Types are in spec.
>> //
>> if ((UsbMass->Pdt != USB_PDT_DIRECT_ACCESS) &&
>>(UsbMass->Pdt != USB_PDT_CDROM) &&
>>(UsbMass->Pdt != USB_PDT_OPTICAL) &&
>>(UsbMass->Pdt != USB_PDT_SIMPLE_DIRECT)) {
>> DEBUG ((EFI_D_ERROR, "UsbBootGetParams: Found an unsupported peripheral
>> type[%d]\n", UsbMass->Pdt));
>> return EFI_UNSUPPORTED;
>> }
>
> It looks likely that at least one of edk2 and QEMU has a bug. Which one
> is it?
Both implementation looks correct at first glance, QEMU replies a
standard SCSI INQUIRY format, while EDK2 expects a "USB Mass Storage
Specification
for Bootability, Revision 1.0" INQUIRY format.
> Or is the command line incorrect perhaps? (I.e., is it invalid to
> specify *only* lun=5? Does the LUN space have to be contiguous?)
>
>
> (3) Starting again from the original command line, if I change "lun=0"
> to "lun=1" (rather than to "lun=5"), then OVMF even hangs, with the
> following log:
>
>> UsbMassInitMultiLun: Start to initialize No.0 logic unit
>> Lun=0 InquiryCmd {
>> Lun=0 InquiryCmd 00 12 00 00 00 24 00 00 00 00 00 00 00
>> Lun=0 InquiryCmd }
>> Lun=0 InquiryData {
>> Lun=0 InquiryData 00 3F 00 05 12 1F 00 00 10 51 45 4D 55 20 20 20 20
>> Lun=0 InquiryData 10 51 45 4D 55 20 54 41 52 47 45 54 20 20 20 20 20
>> Lun=0 InquiryData 20 32 2
Re: [edk2] [Patch 0/3] BaseTools: Implement splitquoted function
On 2/12/19 3:02 PM, Laszlo Ersek wrote: > On 02/12/19 14:33, Gao, Liming wrote: >> Laszlo: >> To install python3-distutils should resolve this issue. I expect BaseTools >> build functionality doesn't depend on the third party python lib. > > I completely agree with your expectation, regarding *3rd party* python > packages. We shouldn't expect developers to install packages from > repositories that fall outside of their normal distro repos. > > However, my understanding was that python3-distutils should be available > as a normal (not 3rd party) component on Ubuntu 18. I think we can > expect developers to install additional packages if those packages are > readily available in their normal (distro-provided) repos. The documentation is not precise about the python package to install, it simply states "Install Python 2.7.10": https://github.com/tianocore/tianocore.github.io/wiki/Getting-Started-with-EDK-II -- Except python, there is a precise list of packages to install for this distro: "sudo apt-get install build-essential uuid-dev iasl git gcc-5 nasm", per: https://github.com/tianocore/tianocore.github.io/wiki/Using-EDK-II-with-Native-GCC#Install_required_software_from_apt Maybe we simply need to update the doc to ask python3 and add python3-distutils in the list? > >> So, I suggest to check whether python3-distutils is the native python >> library. If it is native python library, why Ubuntu18 doesn't include it. I >> will work with Dandan to collect more information. > > Right, that's exactly what I'm asking for. Thank you very much! > Laszlo > >>> -Original Message- >>> From: Laszlo Ersek [mailto:ler...@redhat.com] >>> Sent: Tuesday, February 12, 2019 8:24 PM >>> To: Feng, Bob C ; Bi, Dandan >>> Cc: edk2-devel@lists.01.org; Gao, Liming >>> Subject: Re: [edk2] [Patch 0/3] BaseTools: Implement splitquoted function >>> >>> On 02/04/19 20:12, Laszlo Ersek wrote: On 02/03/19 06:55, Feng, Bob C wrote: > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1509 > On some Linux environment, there may be no distutils.util > library for python3 that will cause build tool crash. > This patch implement distutils.util.split_quoted > in BaseTools so that the Basetools will be independent with > distutils.util library. > > Feng, Bob C (3): > BaseTools: Implement splitquoted function in Build tool > BaseTools: Implement splitquoted function in UPT > BaseTools: unit test for splitquoted function > > BaseTools/Source/Python/AutoGen/UniClassObject.py | 50 > ++ > BaseTools/Source/Python/UPT/Library/UniClassObject.py | 47 > --- > BaseTools/Tests/TestStringSplit.py| 38 > ++ > 3 files changed, 128 insertions(+), 7 deletions(-) > create mode 100644 BaseTools/Tests/TestStringSplit.py > Is this really necessary? BZ#1509 references Ubuntu18; however it looks like the issue can be resolved by a simple package installation on Ubuntu 18: https://superuser.com/questions/1319047/cant-install-virtual-interpreter-in-pycharm-in-linux """ sudo apt-get install python3-distutils """ I'm not a Ubuntu user myself; so all I can do here (without installing a Ubuntu18 VM) is check the Ubuntu package directory: https://packages.ubuntu.com/search?keywords=python3-distutils&searchon=names&suite=all§ion=all python3-distutils appears available for both "bionic (18.04LTS)" and "cosmic (18.10)". Dandan, if you install python3-distutils, does that solve the issue for you? >>> >>> I'd still like to get an answer to my question, before the series is pushed. >>> >>> Thanks, >>> Laszlo > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] ArmVirtPkg: Fix various typos
Hi Antoine, On 2/7/19 6:13 PM, Antoine Coeur wrote: > Thank you Laszlo. > > Do you have any recommendations regarding the maximum size of a patch for > smooth reviewing on this mailing list? > I have about 9000 lines of additional typos corrections in queue at > https://github.com/Coeur/edk2/tree/typo, but I'm afraid that big patches will > simply be ignored. I tagged your "BaseTools: Fix various typos" patch for review, but it is true than after reading the diff stats "172 files changed, 513 insertions(+), 518 deletions(-)" I procrastinated and skipped to the next patch to review... The rule of thumb I learned is the limit to the magic number 20, probably related to our number of fingers/toes :P For example you could split the previous patch in: BaseTools/Source/C/Common BaseTools/Source/C/VfrCompile BaseTools/Source/C/* (other) BaseTools/Source/Python And it would be more digest. > If I split them in small patches, how many patches can I post every day? Or > should I post a hundred patches at the same time and reviewers won't freak > out? The list shouldn't have limition in how many patches you can send, the bottleneck here is the human brain and how many patches a reviewer can take. Since your patches are related (all fixes typos), what would help is if you group your patches in series, instead of sending separately. Same here, I recommend the 20 limit. For example you can send various series of up-to 20 patches, like: - Board X + Y - Board Z - Package X - Module Y - Arm - Intel > Or could we exceptionally allow pull requests on GitHub for those typos > changes, as it doesn't involve actual code-change? That could be an > interesting experiment that would prevent cluttering the mailing-list. There is a study in progress to use another workflow than mailing list, but we are not there yet. Anyway, don't worry about stressing the mailing list ;) Regards, Phil. > > Coeur > > > > Gesendet: Donnerstag, 07. Februar 2019 um 21:33 Uhr > Von: "Laszlo Ersek" > An: "Antoine Coeur" , edk2-devel@lists.01.org > Betreff: Re: [edk2] [PATCH v2] ArmVirtPkg: Fix various typos > > Pushed as commit 7a90895306ac. > > Thanks, > Laszlo > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] CryptoPkg: Fix various typos
On 2/7/19 2:04 PM, Ryszard Knop wrote: > Hi Philippe, Antoine, > > On Wed, 2019-02-06 at 23:30 +0100, Philippe Mathieu-Daudé wrote: >> Hi Antoine, >> >> On 2/6/19 6:24 PM, Antoine Coeur wrote: >>> Fix various typos in CryptoPkg. >>> >>> Contributed-under: TianoCore Contribution Agreement 1.1 >>> Signed-off-by: Coeur >>> --- >>> CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c | 2 +- >>> CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c | 4 ++-- >>> 2 files changed, 3 insertions(+), 3 deletions(-) >>> >>> diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c >>> b/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c >>> index d63c23df09..540c5715cb 100644 >>> --- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c >>> +++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c >>> @@ -142,7 +142,7 @@ IMPLEMENT_ASN1_FUNCTIONS (TS_TST_INFO) >>>@param[in] Asn1Time Pointer to the ASN.1 >>> GeneralizedTime to be converted. >>>@param[out] SigningTime Return the corresponding EFI Time. >>> >>> - @retval TRUE The time convertion succeeds. >>> + @retval TRUE The time conversion succeeds. >> >> The typos are indeed fixed, so: >> Reviewed-by: Philippe Mathieu-Daude >> >> However reading this description makes me suspicious, I'd have >> written >> "The time convertion succeeded.", but I'm not native English speaker >> so >> I'll let someone with more insurance opinate. > > I'm not a native speaker either, but I'd write "conversion" as well. > (Like revert -> reversion, subvert -> subversion, avert -> aversion, > and so on.) Oops, I copy/pasted the wrong line :S Indeed the correct word is "conversion", thanks for correcting me. My wonder is about what is the correct use between succeeds/succeeded, I'd expect the following diff: - @retval TRUE The time convertion succeeds. + @retval TRUE The time conversion succeeded. >> >> Regards, >> >> Phil. >> >>>@retval FALSE Invalid parameters. >>> >>> **/ >>> diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c >>> b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c >>> index 9510a4a383..929e3fcd1e 100644 >>> --- a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c >>> +++ b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c >>> @@ -84,14 +84,14 @@ QuickSortWorker ( >>> } >>>} >>>// >>> - // Swap pivot to it's final position (NextSwapLocaiton) >>> + // Swap pivot to it's final position (NextSwapLocation) >>>// >>>CopyMem (Buffer, Pivot, ElementSize); >>>CopyMem (Pivot, (UINT8 *)BufferToSort + (NextSwapLocation * >>> ElementSize), ElementSize); >>>CopyMem ((UINT8 *)BufferToSort + (NextSwapLocation * >>> ElementSize), Buffer, ElementSize); >>> >>>// >>> - // Now recurse on 2 paritial lists. Neither of these will have >>> the 'pivot' element. >>> + // Now recurse on 2 partial lists. Neither of these will have >>> the 'pivot' element. >>>// IE list is sorted left half, pivot element, sorted right >>> half... >>>// >>>QuickSortWorker ( >>> >> ___ >> edk2-devel mailing list >> edk2-devel@lists.01.org >> https://lists.01.org/mailman/listinfo/edk2-devel > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] BaseTools: Fix build failure when specifying multiple BUILDTARGET
On 2/6/19 10:11 PM, Carsey, Jaben wrote:
> Reviewed-by: Jaben Carsey
>
> And pushed.
Thanks!
And I learned the hard way git config 'user.name' is obviously different
than 'sendemail.from'...
Liming asked me to not use non-ASCII character in commit message so I
fixed my user.name, but forgot the sendemail.from, and now I see my
lastname got mojibaked :S
No worry, my bad.
Regards,
Phil.
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Wednesday, February 06, 2019 8:26 AM
>> To: Philippe Mathieu-Daudé ; Kinney, Michael D
>> ; edk2-devel@lists.01.org; Carsey, Jaben
>>
>> Cc: Leif Lindholm
>> Subject: Re: [PATCH v2] BaseTools: Fix build failure when specifying multiple
>> BUILDTARGET
>>
>> On 02/06/19 13:03, Philippe Mathieu-Daudé wrote:
>>> With Python3, the dict.value() method returns an iterator.
>>> If a dictionary is updated while an iterator on its keys is used,
>>> a RuntimeError is generated.
>>> Converting the iterator to a list() forces a copy of the mutable
>>> keys in an immutable list which can be safely iterated.
>>>
>>> Commit f8d11e5a4aaa converted various uses but missed one:
>>> When specifying multiple BUILDTARGET, the first target builds
>>> successfully, but then the PGen.BuildDatabase._CACHE_ dictionary is
>>> updated, and accessing the next target triggers a RuntimeError.
>>>
>>> Convert this iterator to an immutable list, to solve this build error:
>>>
>>> $ build -a IA32 -t GCC5 -b RELEASE -b NOOPT -p
>> OvmfPkg/OvmfPkgIa32.dsc
>>> [...]
>>> Processing meta-data ...
>>> build.py...
>>> : error C0DE: Unknown fatal error when processing
>> [OvmfPkg/OvmfPkgIa32.dsc]
>>>
>>> (Please send email to edk2-devel@lists.01.org for help, attaching
>> following call stack trace!)
>>>
>>> (Python 3.5.3 on linux) Traceback (most recent call last):
>>> File
>> "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line
>> 2387, in Main
>>> MyBuild.Launch()
>>> File
>> "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line
>> 2141, in Launch
>>> self._MultiThreadBuildPlatform()
>>> File
>> "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line
>> 1921, in _MultiThreadBuildPlatform
>>> self.Progress
>>> File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 304, in
>> __init__
>>> self._InitWorker(Workspace, MetaFile, Target, Toolchain, Arch,
>>> *args,
>> **kwargs)
>>> File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 477, in
>> _InitWorker
>>> for BuildData in PGen.BuildDatabase._CACHE_.values():
>>> RuntimeError: dictionary changed size during iteration
>>>
>>> Note: The culprit commit (f8d11e5a4aaa) can not be found with bisection.
>>> In 9c2d68c0a299 the build tools default to the python version provided
>>> by the ${PYTHON} environment variable, however the Python3 transition is
>>> not functional before d943b0c339fe. f8d11e5a4aaa falls between the
>>> previous two.
>>>
>>> Reported-by: Leif Lindholm
>>> Fixes: f8d11e5a4aaa90bf63b4789f3993dd6d16c60787
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Philippe Mathieu-Daude
>>> Tested-by: Leif Lindholm
>>> Acked-by: Laszlo Ersek
>>> ---
>>> v2:
>>> - fixed English errors (Laszlo)
>>> - the paragraph about bisection not working is not relevant to
>>>the fix, keep it as background info but move it after (Laszlo)
>>> Signed-off-by: Philippe Mathieu-Daudé
>>> ---
>>> BaseTools/Source/Python/AutoGen/AutoGen.py | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
>> b/BaseTools/Source/Python/AutoGen/AutoGen.py
>>> index a95d2c710e..12592a2a46 100644
>>> --- a/BaseTools/Source/Python/AutoGen/AutoGen.py
>>> +++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
>>> @@ -474,7 +474,7 @@ class WorkspaceAutoGen(AutoGen):
>>>
>>> # generate the SourcePcdDict and BinaryPcdDict
>>> PGen = PlatformAutoGen(self, self.MetaFile, Target, Toolchain,
>> Arch)
>>> -for BuildData in PGen.BuildDatabase._CACHE_.values():
>>> +for BuildData in list(PGen.BuildDatabase._CACHE_.values()):
>>> if BuildData.Arch != Arch:
>>> continue
>>> if BuildData.MetaFile.Ext == '.inf':
>>>
>>
>> Looks nice, thanks! My A-b stands.
>>
>> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] ArmPlatformPkg: Fix various typos
On 2/6/19 4:46 PM, Antoine Coeur wrote: > Fix various typos in ArmPlatformPkg. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Coeur > --- > ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c | 4 ++-- > ArmPlatformPkg/Include/Library/ArmPlatformLib.h| 2 +- > ArmPlatformPkg/Include/Library/PL011UartLib.h | 2 +- > ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c | 2 +- > ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c | 2 +- > ArmPlatformPkg/PlatformPei/PlatformPeim.c | 2 +- > ArmPlatformPkg/PrePeiCore/PrePeiCore.c | 2 +- > ArmPlatformPkg/PrePi/PrePi.c | 2 +- > 8 files changed, 9 insertions(+), 9 deletions(-) > > diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c > b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c > index af40a4c884..73d389c811 100644 > --- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c > +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c > @@ -1115,7 +1115,7 @@ NorFlashWriteSingleBlock ( >@retval EFI_SUCCESS The data was read correctly from the device. >@retval EFI_DEVICE_ERROR The device reported an error while > performing the read. >@retval EFI_NO_MEDIA There is no media in the device. > - @retval EFI_MEDIA_CHNAGED The MediaId does not matched the current > device. > + @retval EFI_MEDIA_CHANGED The MediaId does not match the current > device. We could argue if this one is strictly a *typo* ;) >@retval EFI_INVALID_PARAMETER The read request contains device addresses > that are not > valid for the device. > > @@ -1160,7 +1160,7 @@ NorFlashDiskIoReadDisk ( >@retval EFI_WRITE_PROTECTED The device can not be written to. >@retval EFI_DEVICE_ERROR The device reported an error while > performing the write. >@retval EFI_NO_MEDIA There is no media in the device. > - @retval EFI_MEDIA_CHNAGED The MediaId does not matched the current > device. > + @retval EFI_MEDIA_CHANGED The MediaId does not match the current > device. >@retval EFI_INVALID_PARAMETER The write request contains device addresses > that are not > valid for the device. > > diff --git a/ArmPlatformPkg/Include/Library/ArmPlatformLib.h > b/ArmPlatformPkg/Include/Library/ArmPlatformLib.h > index 3ad4c16066..fd264b31f7 100644 > --- a/ArmPlatformPkg/Include/Library/ArmPlatformLib.h > +++ b/ArmPlatformPkg/Include/Library/ArmPlatformLib.h > @@ -20,7 +20,7 @@ > // > #include > // > -// The protocols, PPI and GUID defintions for this module > +// The protocols, PPI and GUID definitions for this module > // > #include > #include > diff --git a/ArmPlatformPkg/Include/Library/PL011UartLib.h > b/ArmPlatformPkg/Include/Library/PL011UartLib.h > index 8cfc3d118a..495def8d7d 100644 > --- a/ArmPlatformPkg/Include/Library/PL011UartLib.h > +++ b/ArmPlatformPkg/Include/Library/PL011UartLib.h > @@ -118,7 +118,7 @@ PL011UartSetControl ( > . EFI_SERIAL_OUTPUT_BUFFER_EMPTY : equal to one if > the > transmit buffer is empty, 0 otherwise. > . EFI_SERIAL_HARDWARE_LOOPBACK_ENABLE : equal to > one if > - the hardware loopback is enabled (the ouput feeds > the > + the hardware loopback is enabled (the output > feeds the > receive buffer), 0 otherwise. > . EFI_SERIAL_SOFTWARE_LOOPBACK_ENABLE : equal to > one if > a loopback is accomplished by software, 0 > otherwise. > diff --git a/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c > b/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c > index 61a34fda0b..60c06a63a4 100644 > --- a/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c > +++ b/ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.c > @@ -327,7 +327,7 @@ PL011UartSetControl ( > . EFI_SERIAL_OUTPUT_BUFFER_EMPTY : equal to one if > the > transmit buffer is empty, 0 otherwise. > . EFI_SERIAL_HARDWARE_LOOPBACK_ENABLE : equal to > one if > - the hardware loopback is enabled (the ouput feeds > the > + the hardware loopback is enabled (the output > feeds the > receive buffer), 0 otherwise. > . EFI_SERIAL_SOFTWARE_LOOPBACK_ENABLE : equal to > one if > a loopback is accomplished by software, 0 > otherwise. Which makes me wonder what is the benefit of copying the same doc twice, in the header and the source? > diff --git a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c > b/ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c > index 010f93add7..6f2a357b96 100644 > --- a/ArmPlatformPkg/MemoryInitPei/MemoryInitPeim.c > +++ b/ArmPlatformPkg/MemoryIni
Re: [edk2] [PATCH v2] ArmVirtPkg: Fix various typos
On 2/6/19 4:48 PM, Antoine Coeur wrote: > Fix various typos in ArmVirtPkg. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Coeur Reviewed-by: Philippe Mathieu-Daude > --- > ArmVirtPkg/ArmVirt.dsc.inc | 2 +- > ArmVirtPkg/Library/ArmVirtDxeHobLib/HobLib.c| 2 +- > ArmVirtPkg/Library/BaseCachingPciExpressLib/PciExpressLib.c | 4 ++-- > .../FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c | 6 +++--- > .../Library/FdtPL011SerialPortLib/FdtPL011SerialPortLib.c | 6 +++--- > ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c | 4 ++-- > 6 files changed, 12 insertions(+), 12 deletions(-) > > diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc > index c47955be94..304a4b4d21 100644 > --- a/ArmVirtPkg/ArmVirt.dsc.inc > +++ b/ArmVirtPkg/ArmVirt.dsc.inc > @@ -333,7 +333,7 @@ ># Values are in EFI Pages (4K). DXE Core will make sure that ># at least this much of each type of memory can be allocated ># from a single memory range. This way you only end up with > - # maximum of two fragements for each type in the memory map > + # maximum of two fragments for each type in the memory map ># (the memory used, and the free memory that was prereserved ># but not used). ># > diff --git a/ArmVirtPkg/Library/ArmVirtDxeHobLib/HobLib.c > b/ArmVirtPkg/Library/ArmVirtDxeHobLib/HobLib.c > index 73a0fbd8a4..758bc91ab1 100644 > --- a/ArmVirtPkg/Library/ArmVirtDxeHobLib/HobLib.c > +++ b/ArmVirtPkg/Library/ArmVirtDxeHobLib/HobLib.c > @@ -1,5 +1,5 @@ > /** @file > - HOB Library implemenation for Dxe Phase with DebugLib dependency removed > + HOB Library implementation for Dxe Phase with DebugLib dependency removed > > Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved. > Copyright (c) 2014, Linaro Ltd. All rights reserved. > diff --git a/ArmVirtPkg/Library/BaseCachingPciExpressLib/PciExpressLib.c > b/ArmVirtPkg/Library/BaseCachingPciExpressLib/PciExpressLib.c > index 6479f53b37..a083826bab 100644 > --- a/ArmVirtPkg/Library/BaseCachingPciExpressLib/PciExpressLib.c > +++ b/ArmVirtPkg/Library/BaseCachingPciExpressLib/PciExpressLib.c > @@ -1238,7 +1238,7 @@ PciExpressBitFieldAndThenOr32 ( >Size into the buffer specified by Buffer. This function only allows the PCI >configuration registers from a single PCI function to be read. Size is >returned. When possible 32-bit PCI configuration read cycles are used to > read > - from StartAdress to StartAddress + Size. Due to alignment restrictions, > 8-bit > + from StartAddress to StartAddress + Size. Due to alignment restrictions, > 8-bit >and 16-bit PCI configuration read cycles may be used at the beginning and > the >end of the range. > > @@ -1338,7 +1338,7 @@ PciExpressReadBuffer ( >Size from the buffer specified by Buffer. This function only allows the PCI >configuration registers from a single PCI function to be written. Size is >returned. When possible 32-bit PCI configuration write cycles are used to > - write from StartAdress to StartAddress + Size. Due to alignment > restrictions, > + write from StartAddress to StartAddress + Size. Due to alignment > restrictions, >8-bit and 16-bit PCI configuration write cycles may be used at the > beginning >and the end of the range. > > diff --git > a/ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c > b/ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c > index f0924dacbc..16c0e61816 100644 > --- a/ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c > +++ b/ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c > @@ -234,13 +234,13 @@ SerialPortGetControl ( > } > > /** > - Sets the baud rate, receive FIFO depth, transmit/receice time out, parity, > + Sets the baud rate, receive FIFO depth, transmit/receive time out, parity, >data bits, and stop bits on a serial device. > >@param BaudRate The requested baud rate. A BaudRate value of 0 > will use the > device's default interface speed. > On output, the value actually set. > - @param ReveiveFifoDepth The requested depth of the FIFO on the receive > side of the > + @param ReceiveFifoDepth The requested depth of the FIFO on the receive > side of the > serial interface. A ReceiveFifoDepth value of 0 > will use > the device's default FIFO depth. > On output, the value actually set. > @@ -253,7 +253,7 @@ SerialPortGetControl ( > DefaultParity will use the device's default > parity value. > On output, the value actually set. >@param DataBits The number of data bits to use on the serial > device. A DataBits > -vaule of 0 will use the device's de
Re: [edk2] [PATCH] CryptoPkg: Fix various typos
Hi Antoine, On 2/6/19 6:24 PM, Antoine Coeur wrote: > Fix various typos in CryptoPkg. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Coeur > --- > CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c | 2 +- > CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c | 4 ++-- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > b/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > index d63c23df09..540c5715cb 100644 > --- a/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > +++ b/CryptoPkg/Library/BaseCryptLib/Pk/CryptTs.c > @@ -142,7 +142,7 @@ IMPLEMENT_ASN1_FUNCTIONS (TS_TST_INFO) >@param[in] Asn1Time Pointer to the ASN.1 GeneralizedTime to be > converted. >@param[out] SigningTime Return the corresponding EFI Time. > > - @retval TRUE The time convertion succeeds. > + @retval TRUE The time conversion succeeds. The typos are indeed fixed, so: Reviewed-by: Philippe Mathieu-Daude However reading this description makes me suspicious, I'd have written "The time convertion succeeded.", but I'm not native English speaker so I'll let someone with more insurance opinate. Regards, Phil. >@retval FALSE Invalid parameters. > > **/ > diff --git a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > index 9510a4a383..929e3fcd1e 100644 > --- a/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > +++ b/CryptoPkg/Library/BaseCryptLib/SysCall/CrtWrapper.c > @@ -84,14 +84,14 @@ QuickSortWorker ( > } >} >// > - // Swap pivot to it's final position (NextSwapLocaiton) > + // Swap pivot to it's final position (NextSwapLocation) >// >CopyMem (Buffer, Pivot, ElementSize); >CopyMem (Pivot, (UINT8 *)BufferToSort + (NextSwapLocation * ElementSize), > ElementSize); >CopyMem ((UINT8 *)BufferToSort + (NextSwapLocation * ElementSize), Buffer, > ElementSize); > >// > - // Now recurse on 2 paritial lists. Neither of these will have the > 'pivot' element. > + // Now recurse on 2 partial lists. Neither of these will have the 'pivot' > element. >// IE list is sorted left half, pivot element, sorted right half... >// >QuickSortWorker ( > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] BeagleBoardPkg: Fix various typos
On 2/6/19 4:51 PM, Antoine Coeur wrote: > Fix various typos in BeagleBoardPkg. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Coeur Reviewed-by: Philippe Mathieu-Daude > --- > BeagleBoardPkg/BeagleBoardPkg.dsc | 4 ++-- > BeagleBoardPkg/Library/BeagleBoardLib/Clock.c | 2 +- > BeagleBoardPkg/Library/DxeHobPeCoffLib/DxeHobPeCoff.c | 4 ++-- > BeagleBoardPkg/PrePi/LzmaDecompress.h | 2 +- > BeagleBoardPkg/Tools/replace.c| 6 +++--- > 5 files changed, 9 insertions(+), 9 deletions(-) > > diff --git a/BeagleBoardPkg/BeagleBoardPkg.dsc > b/BeagleBoardPkg/BeagleBoardPkg.dsc > index e0fee3692f..d677ab3eed 100644 > --- a/BeagleBoardPkg/BeagleBoardPkg.dsc > +++ b/BeagleBoardPkg/BeagleBoardPkg.dsc > @@ -71,7 +71,7 @@ ># Uncomment (and comment out the next line) For RealView Debugger. The > Standard IO window ># in the debugger will show load and unload commands for symbols. You can > cut and paste this ># into the command window to load symbols. We should be able to use a > script to do this, but > - # the version of RVD I have does not support scipts accessing system > memory. > + # the version of RVD I have does not support scripts accessing system > memory. ># > # > PeCoffExtraActionLib|ArmPkg/Library/RvdPeCoffExtraActionLib/RvdPeCoffExtraActionLib.inf > > PeCoffExtraActionLib|ArmPkg/Library/DebugPeCoffExtraActionLib/DebugPeCoffExtraActionLib.inf > @@ -303,7 +303,7 @@ > # Values are in EFI Pages (4K). DXE Core will make sure that > # at least this much of each type of memory can be allocated > # from a single memory range. This way you only end up with > -# maximum of two fragements for each type in the memory map > +# maximum of two fragments for each type in the memory map > # (the memory used, and the free memory that was prereserved > # but not used). > # > diff --git a/BeagleBoardPkg/Library/BeagleBoardLib/Clock.c > b/BeagleBoardPkg/Library/BeagleBoardLib/Clock.c > index 6ca48e0c9f..4ca07ce7bc 100644 > --- a/BeagleBoardPkg/Library/BeagleBoardLib/Clock.c > +++ b/BeagleBoardPkg/Library/BeagleBoardLib/Clock.c > @@ -61,7 +61,7 @@ ClockInit ( >| CM_ICLKEN_PER_EN_GPIO5_ENABLE >| CM_ICLKEN_PER_EN_GPIO6_ENABLE); > > - // Turn on functional & inteface clocks to various wakeup modules. > + // Turn on functional & interface clocks to various wakeup modules. >MmioOr32(CM_FCLKEN_WKUP, CM_FCLKEN_WKUP_EN_GPIO1_ENABLE > | CM_FCLKEN_WKUP_EN_WDT2_ENABLE); >MmioOr32(CM_ICLKEN_WKUP, CM_ICLKEN_WKUP_EN_GPIO1_ENABLE > diff --git a/BeagleBoardPkg/Library/DxeHobPeCoffLib/DxeHobPeCoff.c > b/BeagleBoardPkg/Library/DxeHobPeCoffLib/DxeHobPeCoff.c > index bcc694816a..0e81536ca6 100644 > --- a/BeagleBoardPkg/Library/DxeHobPeCoffLib/DxeHobPeCoff.c > +++ b/BeagleBoardPkg/Library/DxeHobPeCoffLib/DxeHobPeCoff.c > @@ -182,13 +182,13 @@ PeCoffLoaderImageReadFromMemory ( > > > /** > - Reapply fixups on a fixed up PE32/PE32+ image to allow virutal calling at > EFI > + Reapply fixups on a fixed up PE32/PE32+ image to allow virtual calling at > EFI >runtime. > >This function reapplies relocation fixups to the PE/COFF image specified > by ImageBase >and ImageSize so the image will execute correctly when the PE/COFF image > is mapped >to the address specified by VirtualImageBase. RelocationData must be > identical > - to the FiuxupData buffer from the PE_COFF_LOADER_IMAGE_CONTEXT structure > + to the FixupData buffer from the PE_COFF_LOADER_IMAGE_CONTEXT structure >after this PE/COFF image was relocated with PeCoffLoaderRelocateImage(). > >Note that if the platform does not maintain coherency between the > instruction cache(s) and the data > diff --git a/BeagleBoardPkg/PrePi/LzmaDecompress.h > b/BeagleBoardPkg/PrePi/LzmaDecompress.h > index a79ff343d2..3b67ee05cc 100644 > --- a/BeagleBoardPkg/PrePi/LzmaDecompress.h > +++ b/BeagleBoardPkg/PrePi/LzmaDecompress.h > @@ -25,7 +25,7 @@ >If the required information can not be retrieved from InputSection, >then RETURN_INVALID_PARAMETER is returned. >If the GUID of InputSection does match the GUID that this handler supports, > - then the size required to hold the decoded buffer is returned in > OututBufferSize, > + then the size required to hold the decoded buffer is returned in > OutputBufferSize, >the size of an optional scratch buffer is returned in ScratchSize, and the > Attributes field >from EFI_GUID_DEFINED_SECTION header of InputSection is returned in > SectionAttribute. > > diff --git a/BeagleBoardPkg/Tools/replace.c b/BeagleBoardPkg/Tools/replace.c > index 00f4249592..d974ac1bcd 100644 > --- a/BeagleBoardPkg/Tools/replace.c > +++ b/BeagleBoardPkg/Tools/replace.c > @@ -102,7 +102,7 @@ main (int argc, char **argv) > return -5; >} > > - // Search for a match by reading every possition
Re: [edk2] [PATCH v2] AppPkg: Fix various typos
Hi Antoine,
On 2/6/19 4:37 PM, Antoine Coeur wrote:
> Fix various typos in AppPkg.
Thanks for updating the title and description.
The content looks the same than v1, so you could have kept my R-b tag.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Coeur
Reviewed-by: Philippe Mathieu-Daude
> ---
> AppPkg/Applications/Enquire/Enquire.c | 2 +-
> AppPkg/Applications/Sockets/DataSource/DataSource.c | 4 ++--
> AppPkg/Applications/Sockets/SetHostName/SetHostName.c | 2 +-
> AppPkg/Applications/Sockets/TftpServer/TftpServer.c | 10 +-
> AppPkg/Applications/Sockets/TftpServer/TftpServer.h | 6 +++---
> AppPkg/Applications/Sockets/WebServer/HTTP.c | 2 +-
> AppPkg/Applications/Sockets/WebServer/PageList.c | 2 +-
> AppPkg/Applications/Sockets/WebServer/Reboot.c| 2 +-
> AppPkg/ReadMe.txt | 2 +-
> 9 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/AppPkg/Applications/Enquire/Enquire.c
> b/AppPkg/Applications/Enquire/Enquire.c
> index 1e1db69a57..fdf4fe05e5 100644
> --- a/AppPkg/Applications/Enquire/Enquire.c
> +++ b/AppPkg/Applications/Enquire/Enquire.c
> @@ -619,7 +619,7 @@ tell.c, uncomment the following and change enquire.c to
> tell.c.
> //#include /* if this fails, define NO_SIG */
> //#endif
>
> -/* Kludge around the possiblity that includes */
> +/* Kludge around the possibility that includes */
> #ifdef CHAR_BIT
> #undef CHAR_BIT
> #undef CHAR_MAX
> diff --git a/AppPkg/Applications/Sockets/DataSource/DataSource.c
> b/AppPkg/Applications/Sockets/DataSource/DataSource.c
> index 0dcd882edf..678a052a12 100644
> --- a/AppPkg/Applications/Sockets/DataSource/DataSource.c
> +++ b/AppPkg/Applications/Sockets/DataSource/DataSource.c
> @@ -873,7 +873,7 @@ Tcp4Close (
>Locate TCP protocol
>
>@retval EFI_SUCCESS Protocol found
> - @retval other Protocl not found
> + @retval other Protocol not found
> **/
> EFI_STATUS
> Tcp4Locate (
> @@ -970,7 +970,7 @@ Tcp4Locate (
>Tcp4Handle ));
>
> //
> -// Locate the TCP protcol
> +// Locate the TCP protocol
> //
> Status = gBS->OpenProtocol ( Tcp4Handle,
> &gEfiTcp4ProtocolGuid,
> diff --git a/AppPkg/Applications/Sockets/SetHostName/SetHostName.c
> b/AppPkg/Applications/Sockets/SetHostName/SetHostName.c
> index 2c8001e205..15785e3fee 100644
> --- a/AppPkg/Applications/Sockets/SetHostName/SetHostName.c
> +++ b/AppPkg/Applications/Sockets/SetHostName/SetHostName.c
> @@ -62,7 +62,7 @@ main (
> break;
>
>case ENODEV:
> -Print ( L"WARNING - Plarform does not support permanent
> storage!\r\n" );
> +Print ( L"WARNING - Platform does not support permanent
> storage!\r\n" );
> break;
>
>case ENOMEM:
> diff --git a/AppPkg/Applications/Sockets/TftpServer/TftpServer.c
> b/AppPkg/Applications/Sockets/TftpServer/TftpServer.c
> index 30d9dae41d..40f986ff92 100644
> --- a/AppPkg/Applications/Sockets/TftpServer/TftpServer.c
> +++ b/AppPkg/Applications/Sockets/TftpServer/TftpServer.c
> @@ -76,7 +76,7 @@ BufferFill (
> pContext->BytesRemaining -= BytesRead;
> pContext->ValidBytes += BytesRead;
> DEBUG (( DEBUG_FILE_BUFFER,
> - "0x%08x: Buffer filled with %Ld bytes, %Ld bytes
> ramaining\r\n",
> + "0x%08x: Buffer filled with %Ld bytes, %Ld bytes
> remaining\r\n",
>pContext->pFill,
>BytesRead,
>pContext->BytesRemaining ));
> @@ -659,7 +659,7 @@ PacketTx (
> // Display the operation
> //
> DEBUG (( DEBUG_TX_PACKET,
> - "0x%08x: Packet transmiting\r\n",
> + "0x%08x: Packet transmitting\r\n",
>pPacket ));
> DEBUG (( DEBUG_TX,
>"0x%08x: pContext sending 0x%08x bytes\r\n",
> @@ -1224,7 +1224,7 @@ TftpOptionSet (
>NextValue = Value / 10;
>
>//
> - // Supress leading zeros
> + // Suppress leading zeros
>//
>if ( 0 != NextValue ) {
> pOack = TftpOptionSet ( pOack, NextValue );
> @@ -1884,7 +1884,7 @@ TftpRead (
>the network stack.
>
>@param [in] pTftpServer Address of the ::TSDT_TFTP_SERVER structure
> - @param [in] AddressFamily The address family to use for the conection.
> + @param [in] AddressFamily The address family to use for the connection.
>@param [in] pIndexAddress of the index into the port array
>
> **/
> @@ -2297,7 +2297,7 @@ main (
> TFTP_PACKET * pPacket;
>
> //
> -// High speed TFTP uses an agressive retransmit to
> +// High speed TFTP uses an aggressive retransmit to
> // get the TFTP client moving again when the ACK or
> // previous data packet was lost.
> //
> diff --git a/AppPkg/Applications/Sockets/TftpServer/TftpServer.h
> b/AppPkg/Applicati
Re: [edk2] [PATCH v2] BaseTools: Fix build failure when specifying multiple BUILDTARGET
On 2/6/19 1:03 PM, Philippe Mathieu-Daudé wrote: [...] > > Reported-by: Leif Lindholm > Fixes: f8d11e5a4aaa90bf63b4789f3993dd6d16c60787 > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Philippe Mathieu-Daude > Tested-by: Leif Lindholm > Acked-by: Laszlo Ersek > --- > v2: > - fixed English errors (Laszlo) > - the paragraph about bisection not working is not relevant to >the fix, keep it as background info but move it after (Laszlo) > Signed-off-by: Philippe Mathieu-Daudé ^ Oops I notice the tool I'm using (git publish) added this S-o-b line, due to an incomplete config. Anyway this is in part of the patch stripped out when applied, so no need to resend a v3 for this detail. > --- ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2] BaseTools: Fix build failure when specifying multiple BUILDTARGET
With Python3, the dict.value() method returns an iterator.
If a dictionary is updated while an iterator on its keys is used,
a RuntimeError is generated.
Converting the iterator to a list() forces a copy of the mutable
keys in an immutable list which can be safely iterated.
Commit f8d11e5a4aaa converted various uses but missed one:
When specifying multiple BUILDTARGET, the first target builds
successfully, but then the PGen.BuildDatabase._CACHE_ dictionary is
updated, and accessing the next target triggers a RuntimeError.
Convert this iterator to an immutable list, to solve this build error:
$ build -a IA32 -t GCC5 -b RELEASE -b NOOPT -p OvmfPkg/OvmfPkgIa32.dsc
[...]
Processing meta-data ...
build.py...
: error C0DE: Unknown fatal error when processing [OvmfPkg/OvmfPkgIa32.dsc]
(Please send email to edk2-devel@lists.01.org for help, attaching following
call stack trace!)
(Python 3.5.3 on linux) Traceback (most recent call last):
File
"BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line
2387, in Main
MyBuild.Launch()
File
"BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line
2141, in Launch
self._MultiThreadBuildPlatform()
File
"BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line
1921, in _MultiThreadBuildPlatform
self.Progress
File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 304, in __init__
self._InitWorker(Workspace, MetaFile, Target, Toolchain, Arch, *args,
**kwargs)
File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 477, in
_InitWorker
for BuildData in PGen.BuildDatabase._CACHE_.values():
RuntimeError: dictionary changed size during iteration
Note: The culprit commit (f8d11e5a4aaa) can not be found with bisection.
In 9c2d68c0a299 the build tools default to the python version provided
by the ${PYTHON} environment variable, however the Python3 transition is
not functional before d943b0c339fe. f8d11e5a4aaa falls between the
previous two.
Reported-by: Leif Lindholm
Fixes: f8d11e5a4aaa90bf63b4789f3993dd6d16c60787
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Philippe Mathieu-Daude
Tested-by: Leif Lindholm
Acked-by: Laszlo Ersek
---
v2:
- fixed English errors (Laszlo)
- the paragraph about bisection not working is not relevant to
the fix, keep it as background info but move it after (Laszlo)
Signed-off-by: Philippe Mathieu-Daudé
---
BaseTools/Source/Python/AutoGen/AutoGen.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index a95d2c710e..12592a2a46 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -474,7 +474,7 @@ class WorkspaceAutoGen(AutoGen):
# generate the SourcePcdDict and BinaryPcdDict
PGen = PlatformAutoGen(self, self.MetaFile, Target, Toolchain,
Arch)
-for BuildData in PGen.BuildDatabase._CACHE_.values():
+for BuildData in list(PGen.BuildDatabase._CACHE_.values()):
if BuildData.Arch != Arch:
continue
if BuildData.MetaFile.Ext == '.inf':
--
2.20.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] AppPkg: Various typo
Hi Antoine,
I'd rename the patch subject as "AppPkg: Fix various typos"
On 2/6/19 7:10 AM, Antoine Coeur wrote:
> Various typo in AppPkg, ignoring Python folder.
Ditto.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Coeur
Reviewed-by: Philippe Mathieu-Daude
> ---
> AppPkg/Applications/Enquire/Enquire.c | 2 +-
> AppPkg/Applications/Sockets/DataSource/DataSource.c | 4 ++--
> AppPkg/Applications/Sockets/SetHostName/SetHostName.c | 2 +-
> AppPkg/Applications/Sockets/TftpServer/TftpServer.c | 10 +-
> AppPkg/Applications/Sockets/TftpServer/TftpServer.h | 6 +++---
> AppPkg/Applications/Sockets/WebServer/HTTP.c | 2 +-
> AppPkg/Applications/Sockets/WebServer/PageList.c | 2 +-
> AppPkg/Applications/Sockets/WebServer/Reboot.c| 2 +-
> AppPkg/ReadMe.txt | 2 +-
> 9 files changed, 16 insertions(+), 16 deletions(-)
>
> diff --git a/AppPkg/Applications/Enquire/Enquire.c
> b/AppPkg/Applications/Enquire/Enquire.c
> index 1e1db69a57..fdf4fe05e5 100644
> --- a/AppPkg/Applications/Enquire/Enquire.c
> +++ b/AppPkg/Applications/Enquire/Enquire.c
> @@ -619,7 +619,7 @@ tell.c, uncomment the following and change enquire.c to
> tell.c.
> //#include /* if this fails, define NO_SIG */
> //#endif
>
> -/* Kludge around the possiblity that includes */
> +/* Kludge around the possibility that includes */
> #ifdef CHAR_BIT
> #undef CHAR_BIT
> #undef CHAR_MAX
> diff --git a/AppPkg/Applications/Sockets/DataSource/DataSource.c
> b/AppPkg/Applications/Sockets/DataSource/DataSource.c
> index 0dcd882edf..678a052a12 100644
> --- a/AppPkg/Applications/Sockets/DataSource/DataSource.c
> +++ b/AppPkg/Applications/Sockets/DataSource/DataSource.c
> @@ -873,7 +873,7 @@ Tcp4Close (
>Locate TCP protocol
>
>@retval EFI_SUCCESS Protocol found
> - @retval other Protocl not found
> + @retval other Protocol not found
> **/
> EFI_STATUS
> Tcp4Locate (
> @@ -970,7 +970,7 @@ Tcp4Locate (
>Tcp4Handle ));
>
> //
> -// Locate the TCP protcol
> +// Locate the TCP protocol
> //
> Status = gBS->OpenProtocol ( Tcp4Handle,
> &gEfiTcp4ProtocolGuid,
> diff --git a/AppPkg/Applications/Sockets/SetHostName/SetHostName.c
> b/AppPkg/Applications/Sockets/SetHostName/SetHostName.c
> index 2c8001e205..15785e3fee 100644
> --- a/AppPkg/Applications/Sockets/SetHostName/SetHostName.c
> +++ b/AppPkg/Applications/Sockets/SetHostName/SetHostName.c
> @@ -62,7 +62,7 @@ main (
> break;
>
>case ENODEV:
> -Print ( L"WARNING - Plarform does not support permanent
> storage!\r\n" );
> +Print ( L"WARNING - Platform does not support permanent
> storage!\r\n" );
> break;
>
>case ENOMEM:
> diff --git a/AppPkg/Applications/Sockets/TftpServer/TftpServer.c
> b/AppPkg/Applications/Sockets/TftpServer/TftpServer.c
> index 30d9dae41d..40f986ff92 100644
> --- a/AppPkg/Applications/Sockets/TftpServer/TftpServer.c
> +++ b/AppPkg/Applications/Sockets/TftpServer/TftpServer.c
> @@ -76,7 +76,7 @@ BufferFill (
> pContext->BytesRemaining -= BytesRead;
> pContext->ValidBytes += BytesRead;
> DEBUG (( DEBUG_FILE_BUFFER,
> - "0x%08x: Buffer filled with %Ld bytes, %Ld bytes
> ramaining\r\n",
> + "0x%08x: Buffer filled with %Ld bytes, %Ld bytes
> remaining\r\n",
>pContext->pFill,
>BytesRead,
>pContext->BytesRemaining ));
> @@ -659,7 +659,7 @@ PacketTx (
> // Display the operation
> //
> DEBUG (( DEBUG_TX_PACKET,
> - "0x%08x: Packet transmiting\r\n",
> + "0x%08x: Packet transmitting\r\n",
>pPacket ));
> DEBUG (( DEBUG_TX,
>"0x%08x: pContext sending 0x%08x bytes\r\n",
> @@ -1224,7 +1224,7 @@ TftpOptionSet (
>NextValue = Value / 10;
>
>//
> - // Supress leading zeros
> + // Suppress leading zeros
>//
>if ( 0 != NextValue ) {
> pOack = TftpOptionSet ( pOack, NextValue );
> @@ -1884,7 +1884,7 @@ TftpRead (
>the network stack.
>
>@param [in] pTftpServer Address of the ::TSDT_TFTP_SERVER structure
> - @param [in] AddressFamily The address family to use for the conection.
> + @param [in] AddressFamily The address family to use for the connection.
>@param [in] pIndexAddress of the index into the port array
>
> **/
> @@ -2297,7 +2297,7 @@ main (
> TFTP_PACKET * pPacket;
>
> //
> -// High speed TFTP uses an agressive retransmit to
> +// High speed TFTP uses an aggressive retransmit to
> // get the TFTP client moving again when the ACK or
> // previous data packet was lost.
> //
> diff --git a/AppPkg/Applications/Sockets/TftpServer/TftpServer.h
> b/AppPkg/Applications/Sockets/TftpServer/TftpServ
Re: [edk2] [PATCH 1/1] EmbeddedPkg/Library: Add VirtualRealTimeClockLib
Hi Pete,
On 2/4/19 1:47 PM, Pete Batard wrote:
> This is designed to be used on platforms where a a real RTC is not
> available and relies on an RtcEpochSeconds variable having been set or,
> if that is not the case, falls back to using the epoch embedded at
> compilation time.
>
> Note that, in order to keep things simple for the setting of the
> compilation time variable, only GCC environments with UNIX-like shells
> and where a 'date' command is available are meant to be supported for
> now.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Pete Batard
> ---
> EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c |
> 400
> EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf |
> 43 +++
> 2 files changed, 443 insertions(+)
>
> diff --git
> a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
> b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
> new file mode 100644
> index ..4c354730d02b
> --- /dev/null
> +++ b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
> @@ -0,0 +1,400 @@
> +/** @file
> + *
> + * Implement virtual EFI RealTimeClock runtime services.
> + *
> + * Coypright (c) 2019, Pete Batard
> + * Copyright (c) 2018, Andrei Warkentin
> + * Copyright (c) 2011-2014, ARM Ltd. All rights reserved.
> + * Copyright (c) 2008-2010, Apple Inc. All rights reserved.
> + * Copyright (c) Microsoft Corporation. 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.
> + *
> + * Based on
> ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
> + *
> + **/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +STATIC CONST CHAR16 mEpochVariableName[] = L"RtcEpochSeconds";
> +STATIC CONST CHAR16 mTimeZoneVariableName[] = L"RtcTimeZone";
> +STATIC CONST CHAR16 mDaylightVariableName[] = L"RtcDaylight";
> +
> +/**
> + Returns the current time and date information, and the time-keeping
> capabilities
> + of the virtual RTC.
> +
> + @param Time A pointer to storage to receive a snapshot
> of the current time.
> + @param Capabilities An optional pointer to a buffer to receive
> the real time clock
> + device's capabilities.
> +
> + @retval EFI_SUCCESS The operation completed successfully.
> + @retval EFI_INVALID_PARAMETER Time is NULL.
> + @retval EFI_DEVICE_ERROR The time could not be retrieved due to
> hardware error.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +LibGetTime (
> + OUT EFI_TIME *Time,
> + OUT EFI_TIME_CAPABILITIES *Capabilities
> + )
> +{
> + EFI_STATUS Status;
> + UINT32 EpochSeconds;
> + INT16 TimeZone;
> + UINT8 Daylight;
> + UINT64 Freq;
> + UINT64 Counter;
> + UINT64 Remainder;
> + UINTN ElapsedSeconds;
> + UINTN Size;
> +
> + if (Time == NULL) {
> +return EFI_INVALID_PARAMETER;
> + }
> +
> + // Get the counter frequency
> + Freq = GetPerformanceCounterProperties (NULL, NULL);
> + if (Freq == 0) {
> +return EFI_DEVICE_ERROR;
> + }
> +
> + // Get the epoch time from non-volatile storage
> + Size = sizeof (UINTN);
> + ElapsedSeconds = 0;
> + Status = EfiGetVariable (
> + (CHAR16 *)mEpochVariableName,
> + &gEfiCallerIdGuid,
> + NULL,
> + &Size,
> + (VOID *)&ElapsedSeconds
> + );
> + // Fall back to compilation-time epoch if not set
> + if (EFI_ERROR (Status)) {
> +ASSERT(Status != EFI_INVALID_PARAMETER);
> +ASSERT(Status != EFI_BUFFER_TOO_SMALL);
> +//
> +// The following is intended to produce a compilation error on build
> +// environments where BUILD_EPOCH can not be set from inline shell.
> +// If you are attempting to use this library on such an environment,
> please
> +// contact the edk2 mailing list, so we can try to add support for it.
> +//
What about:
#ifndef BUILD_EPOCH
#define BUILD_EPOCH 1549396000 /* As of this commit */
#endif
> +ElapsedSeconds = BUILD_EPOCH;
> +DEBUG ((
> + DEBUG_INFO,
> + "LibGetTime: %s non volatile variable was not found - Using
> compilation time epoch.\n",
> + mEpochVariableName
> + ));
> + }
> + Counter = GetPerformanceCounter ();
> + ElapsedSeconds += DivU64x64Remainder (Counter, Freq, &Remainder);
> +
> + // Get the current time zone information from non-volat
Re: [edk2] [PATCH] BaseTools: Fix build failure when specifying multiple BUILDTARGET
On 2/5/19 10:03 AM, Laszlo Ersek wrote:
> On 02/05/19 02:23, Philippe Mathieu-Daudé wrote:
>> Since 9c2d68c0a299 the build tools default to the python version
>> provided by the ${PYTHON} environment variable.
>> However the Python3 transition is not effective before d943b0c339fe.
>
> (1) Do you mean "functional" rather than "effective"?
Probably :)
> (2) Why is this information relevant for this commit? I see that commit
> f8d11e5a4aaa, referenced below, falls between the above two, but I'm
> unsure if that has any special relevance.
>
> If the above paragraph is just background info, that's OK with me, of
> course.
Yes, I'll reword to explain the tree isn't bisectable there, or drop
that background info.
>> With Python3, the dict.value() method returns an iterator.
>> If a dictionary is updated while an iterator on his keys is used,
>
> (3) s/his/its/
>
>> a RuntimeError is generated.
>> Converting the iterator to a list() forces a copy of the mutable
>> keys in an immutable list which can be safely iterated.
>>
>> Commit f8d11e5a4aaa converted various uses but missed one:
>> When specifying multiple BUILDTARGET, the first target builds
>> successfully, but then the PGen.BuildDatabase._CACHE_ dictionary is
>> updated, and the next target accessing it triggers a RuntimeError.
>
> (4) Can we clarify this please; I think it's not the "next target" that
> accesses the dictionary, instead the code accesses the next target in
> the dictionary. How about
>
> s/the next target accessing it/accessing the next target/
>
> ?
Sure.
>>
>> Convert this iterator to an immutable list, to solve this build error:
>>
>> $ build -a IA32 -t GCC5 -b RELEASE -b NOOPT -p OvmfPkg/OvmfPkgIa32.dsc
>> [...]
>> Processing meta-data ...
>> build.py...
>> : error C0DE: Unknown fatal error when processing
>> [OvmfPkg/OvmfPkgIa32.dsc]
>>
>> (Please send email to edk2-devel@lists.01.org for help, attaching
>> following call stack trace!)
>>
>> (Python 3.5.3 on linux) Traceback (most recent call last):
>> File
>> "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line
>> 2387, in Main
>> MyBuild.Launch()
>> File
>> "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line
>> 2141, in Launch
>> self._MultiThreadBuildPlatform()
>> File
>> "BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line
>> 1921, in _MultiThreadBuildPlatform
>> self.Progress
>> File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 304, in
>> __init__
>> self._InitWorker(Workspace, MetaFile, Target, Toolchain, Arch,
>> *args, **kwargs)
>> File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 477, in
>> _InitWorker
>> for BuildData in PGen.BuildDatabase._CACHE_.values():
>> RuntimeError: dictionary changed size during iteration
>>
>> Reported-by: Leif Lindholm
>> Fixes: f8d11e5a4aaa90bf63b4789f3993dd6d16c60787
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Philippe Mathieu-Daude
>> Tested-by: Leif Lindholm
>> ---
>> BaseTools/Source/Python/AutoGen/AutoGen.py | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
>> b/BaseTools/Source/Python/AutoGen/AutoGen.py
>> index a95d2c710e..12592a2a46 100644
>> --- a/BaseTools/Source/Python/AutoGen/AutoGen.py
>> +++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
>> @@ -474,7 +474,7 @@ class WorkspaceAutoGen(AutoGen):
>>
>> # generate the SourcePcdDict and BinaryPcdDict
>> PGen = PlatformAutoGen(self, self.MetaFile, Target, Toolchain,
>> Arch)
>> -for BuildData in PGen.BuildDatabase._CACHE_.values():
>> +for BuildData in list(PGen.BuildDatabase._CACHE_.values()):
>> if BuildData.Arch != Arch:
>> continue
>> if BuildData.MetaFile.Ext == '.inf':
>>
>
> LGTM :)
>
> With the commit message updated (as you prefer):
>
> Acked-by: Laszlo Ersek
Thanks!
Regards,
Phil.
>
> Thanks
> Laszlo
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] BaseTools: Fix build failure when specifying multiple BUILDTARGET
Since 9c2d68c0a299 the build tools default to the python version
provided by the ${PYTHON} environment variable.
However the Python3 transition is not effective before d943b0c339fe.
With Python3, the dict.value() method returns an iterator.
If a dictionary is updated while an iterator on his keys is used,
a RuntimeError is generated.
Converting the iterator to a list() forces a copy of the mutable
keys in an immutable list which can be safely iterated.
Commit f8d11e5a4aaa converted various uses but missed one:
When specifying multiple BUILDTARGET, the first target builds
successfully, but then the PGen.BuildDatabase._CACHE_ dictionary is
updated, and the next target accessing it triggers a RuntimeError.
Convert this iterator to an immutable list, to solve this build error:
$ build -a IA32 -t GCC5 -b RELEASE -b NOOPT -p OvmfPkg/OvmfPkgIa32.dsc
[...]
Processing meta-data ...
build.py...
: error C0DE: Unknown fatal error when processing [OvmfPkg/OvmfPkgIa32.dsc]
(Please send email to edk2-devel@lists.01.org for help, attaching following
call stack trace!)
(Python 3.5.3 on linux) Traceback (most recent call last):
File
"BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line
2387, in Main
MyBuild.Launch()
File
"BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line
2141, in Launch
self._MultiThreadBuildPlatform()
File
"BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", line
1921, in _MultiThreadBuildPlatform
self.Progress
File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 304, in __init__
self._InitWorker(Workspace, MetaFile, Target, Toolchain, Arch, *args,
**kwargs)
File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 477, in
_InitWorker
for BuildData in PGen.BuildDatabase._CACHE_.values():
RuntimeError: dictionary changed size during iteration
Reported-by: Leif Lindholm
Fixes: f8d11e5a4aaa90bf63b4789f3993dd6d16c60787
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Philippe Mathieu-Daude
Tested-by: Leif Lindholm
---
BaseTools/Source/Python/AutoGen/AutoGen.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/BaseTools/Source/Python/AutoGen/AutoGen.py
b/BaseTools/Source/Python/AutoGen/AutoGen.py
index a95d2c710e..12592a2a46 100644
--- a/BaseTools/Source/Python/AutoGen/AutoGen.py
+++ b/BaseTools/Source/Python/AutoGen/AutoGen.py
@@ -474,7 +474,7 @@ class WorkspaceAutoGen(AutoGen):
# generate the SourcePcdDict and BinaryPcdDict
PGen = PlatformAutoGen(self, self.MetaFile, Target, Toolchain,
Arch)
-for BuildData in PGen.BuildDatabase._CACHE_.values():
+for BuildData in list(PGen.BuildDatabase._CACHE_.values()):
if BuildData.Arch != Arch:
continue
if BuildData.MetaFile.Ext == '.inf':
--
2.20.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] BaseTools: build failure when specifying multiple BUILDTARGET
On 2/4/19 12:54 PM, Philippe Mathieu-Daudé wrote: > On 2/4/19 10:58 AM, Leif Lindholm wrote: >> Hi Bob, Liming, >> >> With the latest BaseTools (current HEAD, 6c61ec4c62), building >> multiple targets from a single command line crashes. >> >> To reproduce: >> build -a IA32 -t GCC5 -b RELEASE -b NOOPT -p OvmfPkg/OvmfPkgIa32.dsc >> (I first built with -n32, but dropped that to see if it would make a >> difference - it does not.) >> >> The first target specified builds successfully. When starting on the >> second, the output is as below, and build exits. >> >> / >> Leif >> >> Architecture(s) = IA32 >> Build target = NOOPT >> Toolchain= GCC5 >> >> Active Platform = /work/git/edk2/OvmfPkg/OvmfPkgIa32.dsc >> Flash Image Definition = /work/git/edk2/OvmfPkg/OvmfPkgIa32.fdf >> >> Processing meta-data ... >> >> >> build.py... >> : error C0DE: Unknown fatal error when processing >> [/work/git/edk2/OvmfPkg/OvmfPkgIa32.dsc] >> >> (Please send email to edk2-devel@lists.01.org for help, attaching following >> call stack trace!) >> >> (Python 3.5.3 on linux) Traceback (most recent call last): >> File >> "/work/git/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", >> line 2387, in Main >> MyBuild.Launch() >> File >> "/work/git/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", >> line 2141, in Launch >> self._MultiThreadBuildPlatform() >> File >> "/work/git/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py", >> line 1921, in _MultiThreadBuildPlatform >> self.Progress >> File "/work/git/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", line >> 304, in __init__ >> self._InitWorker(Workspace, MetaFile, Target, Toolchain, Arch, *args, >> **kwargs) >> File "/work/git/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", line >> 477, in _InitWorker >> for BuildData in PGen.BuildDatabase._CACHE_.values(): >> RuntimeError: dictionary changed size during iteration > > I believe the culprit is f8d11e5a4aaa. With Python3 the dict.value() method returns an iterator. Using list() to force a copy works for me. Since I'm not a Python expert (and less with joys of py2/py3 conversion), I'll start sharing a snippet rather than a formal patch :) -- >8 -- --- a/BaseTools/Source/Python/AutoGen/AutoGen.py +++ b/BaseTools/Source/Python/AutoGen/AutoGen.py @@ -475,5 +475,5 @@ class WorkspaceAutoGen(AutoGen): # generate the SourcePcdDict and BinaryPcdDict PGen = PlatformAutoGen(self, self.MetaFile, Target, Toolchain, Arch) -for BuildData in PGen.BuildDatabase._CACHE_.values(): +for BuildData in list(PGen.BuildDatabase._CACHE_.values()): if BuildData.Arch != Arch: continue --- signature.asc Description: OpenPGP digital signature ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2] AppPkg: fix webserver build for !Ia32/X64
On 11/2/18 11:50 AM, Leif Lindholm wrote: > The WebServer application is not meant to be Ia32/X64 specific, and would > build for other architectures, if it wasn't for the > #include > in WebServer.h. Move that statement to Mtrr.c instead, which is the only > consumer, and is already being filtered out for other architectures. > > Cc: Daryl McDaniel > Cc: Jaben Carsey > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Leif Lindholm Reviewed-by: Philippe Mathieu-Daudé > --- > > Resending only 1/6, since the others got R-b already. > Looking at PageList.c, the app was clearly intended to be portable, > so updated commit message to reflect this. > > AppPkg/Applications/Sockets/WebServer/WebServer.h | 1 - > AppPkg/Applications/Sockets/WebServer/Mtrr.c | 1 + > 2 files changed, 1 insertion(+), 1 deletion(-) > > diff --git a/AppPkg/Applications/Sockets/WebServer/WebServer.h > b/AppPkg/Applications/Sockets/WebServer/WebServer.h > index 21b07b63df..16c30c8d6d 100644 > --- a/AppPkg/Applications/Sockets/WebServer/WebServer.h > +++ b/AppPkg/Applications/Sockets/WebServer/WebServer.h > @@ -20,7 +20,6 @@ > > #include > > -#include > #include > #include > #include > diff --git a/AppPkg/Applications/Sockets/WebServer/Mtrr.c > b/AppPkg/Applications/Sockets/WebServer/Mtrr.c > index 54356bde64..4b8482d4e2 100644 > --- a/AppPkg/Applications/Sockets/WebServer/Mtrr.c > +++ b/AppPkg/Applications/Sockets/WebServer/Mtrr.c > @@ -15,6 +15,7 @@ > > #include > #include > +#include > > #define VARIABLE_MTRR_VALID 0x800 > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] BaseTools: build failure when specifying multiple BUILDTARGET
Hi,
On 2/4/19 10:58 AM, Leif Lindholm wrote:
> Hi Bob, Liming,
>
> With the latest BaseTools (current HEAD, 6c61ec4c62), building
> multiple targets from a single command line crashes.
>
> To reproduce:
> build -a IA32 -t GCC5 -b RELEASE -b NOOPT -p OvmfPkg/OvmfPkgIa32.dsc
> (I first built with -n32, but dropped that to see if it would make a
> difference - it does not.)
>
> The first target specified builds successfully. When starting on the
> second, the output is as below, and build exits.
>
> /
> Leif
>
> Architecture(s) = IA32
> Build target = NOOPT
> Toolchain= GCC5
>
> Active Platform = /work/git/edk2/OvmfPkg/OvmfPkgIa32.dsc
> Flash Image Definition = /work/git/edk2/OvmfPkg/OvmfPkgIa32.fdf
>
> Processing meta-data ...
>
>
> build.py...
> : error C0DE: Unknown fatal error when processing
> [/work/git/edk2/OvmfPkg/OvmfPkgIa32.dsc]
>
> (Please send email to edk2-devel@lists.01.org for help, attaching following
> call stack trace!)
>
> (Python 3.5.3 on linux) Traceback (most recent call last):
> File
> "/work/git/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
> line 2387, in Main
> MyBuild.Launch()
> File
> "/work/git/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
> line 2141, in Launch
> self._MultiThreadBuildPlatform()
> File
> "/work/git/edk2/BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
> line 1921, in _MultiThreadBuildPlatform
> self.Progress
> File "/work/git/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", line 304,
> in __init__
> self._InitWorker(Workspace, MetaFile, Target, Toolchain, Arch, *args,
> **kwargs)
> File "/work/git/edk2/BaseTools/Source/Python/AutoGen/AutoGen.py", line 477,
> in _InitWorker
> for BuildData in PGen.BuildDatabase._CACHE_.values():
> RuntimeError: dictionary changed size during iteration
I believe the culprit is f8d11e5a4aaa.
Sadly the tree isn't bisectable around that commit:
HEAD is now at fd2d74007b BaseTools:Update build tool to print python
version information
$ build -a IA32 -t GCC5 -b RELEASE -b NOOPT -p OvmfPkg/OvmfPkgIa32.dsc
build.py...
: error C0DE: Unknown fatal error when processing []
(Python 2.7.15 on linux2) Traceback (most recent call last):
File
"BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
line 2385, in Main
MyBuild = Build(Target, Workspace, Option)
File
"BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
line 799, in __init__
EdkLogger.quiet("%-16s = %s" % ("PYTHON", os.environ["PYTHON"]))
File "/usr/lib64/python2.7/UserDict.py", line 40, in __getitem__
raise KeyError(key)
KeyError: 'PYTHON'
HEAD is now at 4a3773e578 BaseTools:Fixed Rsa issue and a set define issue.
$ build -a IA32 -t GCC5 -b RELEASE -b NOOPT -p OvmfPkg/OvmfPkgIa32.dsc
Traceback (most recent call last):
File
"BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
line 44, in
from AutoGen.AutoGen import *
File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 27, in
from . import GenC
File "BaseTools/Source/Python/AutoGen/GenC.py", line 26, in
from .StrGather import *
File "BaseTools/Source/Python/AutoGen/StrGather.py", line 21, in
from .UniClassObject import *
File "BaseTools/Source/Python/AutoGen/UniClassObject.py", line 430
UniStr = ('\u' + (Line[StartPos + 2 : EndPos])).decode('unicode_escape')
^
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in
position 0-1: truncated \u escape
HEAD is now at 7fa0e68afd BaseTools:ord() don't match in py2 and py3
$ build -a IA32 -t GCC5 -b RELEASE -b NOOPT -p OvmfPkg/OvmfPkgIa32.dsc
build.py...
(Python 3.7.2 on linux) Traceback (most recent call last):
File
"BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
line 2387, in Main
MyBuild.Launch()
File
"BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
line 2141, in Launch
self._MultiThreadBuildPlatform()
File
"BaseTools/BinWrappers/PosixLike/../../Source/Python/build/build.py",
line 1921, in _MultiThreadBuildPlatform
self.Progress
File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 304, in __init__
self._InitWorker(Workspace, MetaFile, Target, Toolchain, Arch,
*args, **kwargs)
File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 501, in
_InitWorker
if MGen in PGen.LibraryAutoGenList:
File "BaseTools/Source/Python/Common/caching.py", line 34, in __get__
Value = obj.__dict__[self._function.__name__] = self._function(obj)
File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 2092, in
LibraryAutoGenList
for La in Ma.LibraryAutoGenList:
File "BaseTools/Source/Python/Common/caching.py", line 34, in __get__
Value = obj.__dict__[self._function.__name__] = self._function(obj)
File "BaseTools/Source/Python/AutoGen/AutoGen.py", line 4087, in
LibraryAutoGenList
for Lib in La.CodaTargetList:
File "Bas
Re: [edk2] [PATCH 06/10] OvmfPkg/README: Remove UNIXGCC
Hi,
On 2/1/19 6:34 AM, Shenglei Zhang wrote:
> Remove content related to UNIXGCC in README.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1377
>
> Cc: Jordan Justen
> Cc: Laszlo Ersek
> Cc: Ard Biesheuvel
> Cc: Anthony Perard
> Cc: Julien Grall
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang
> ---
> OvmfPkg/README | 19 ---
> 1 file changed, 19 deletions(-)
>
> diff --git a/OvmfPkg/README b/OvmfPkg/README
> index 68ce0750af..c014d07bfb 100644
> --- a/OvmfPkg/README
> +++ b/OvmfPkg/README
> @@ -402,25 +402,6 @@ main firmware (MAINFV) into RAM memory at address
> 0x80. The
> remaining OVMF firmware then uses this decompressed firmware
> volume image.
>
> -=== UNIXGCC Debug ===
> -
> -If you build with the UNIXGCC toolchain, then debugging will be disabled
> -due to larger image sizes being produced by the UNIXGCC toolchain. The
> -first choice recommendation is to use GCC48 or newer instead.
> -
> -If you must use UNIXGCC, then you can override the build options for
> -particular libraries and modules in the .dsc to re-enable debugging
> -selectively. For example:
> - [Components]
> - OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf {
> -
> - GCC:*_*_*_CC_FLAGS = -UMDEPKG_NDEBUG
> - }
> - MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
> -
> - GCC:*_*_*_CC_FLAGS = -UMDEPKG_NDEBUG
> - }
> -
> === UEFI Windows 7 & Windows 2008 Server ===
>
> * One of the '-vga std' and '-vga qxl' QEMU options should be used.
>
Doesn't it make sense to squash this commit with the previous one as
"OvmfPkg: Remove UNIXGCC"?
Regards,
Phil.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove unnecessary NULL pointer check.
On 1/21/19 10:21 PM, Laszlo Ersek wrote: > Hi Phil, > > On 01/21/19 14:26, Philippe Mathieu-Daudé wrote: >> Hi, >> >> On 1/21/19 1:53 PM, Gao, Liming wrote: >>> Thanks Ard and Laszlo. For the minor change in single patch, the patch may >>> be sent separately with the clear subject. Or, the patch set can be sent >>> again. >> >> Since it is hard to follow technical discussion when top-posted (see >> https://www.caliburn.nl/topposting.html) without scrolling and sometime >> loosing context, can we gently suggest bottom-posting in edk2-devel >> etiquette? (No offence, this is a humble suggestion from a not very >> active reviewer to a highly active contributor, but this might ease the >> on-list review workflow). > > top vs. bottom posting have been mentioned multiple times on edk2-devel; > it's just a fact that most corporate email environments don't support > bottom posting at all. > > I'm unhappy about it (obviously), but it's an uphill battle. Sometimes > the poster would actually *like* to bottom post, but the tooling (which > may not be their own choice) gets in their way. > > I suggest always scrolling to the bottom, or at least until you see a > signature. Oh, I was not aware of that, it makes now sense (there is a common pattern in companies/location with top-posts). Sorry for the noise, at least I tried ;) Regards, Phil. > > Thanks, > Laszlo > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmPkg: delete unused ArmTrustZoneSmc.h
On 1/21/19 2:07 PM, Ard Biesheuvel wrote: > On Mon, 21 Jan 2019 at 14:07, Leif Lindholm wrote: >> >> ArmPkg/Include/IndustryStandard/ArmTrustZoneSmc.h contains definitions >> contradicting the SMC Calling Convention (ARM DEN0028B). >> >> It also has no users in public trees. So delete before it can cause >> damage. >> >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Leif Lindholm > > Reviewed-by: Ard Biesheuvel Reviewed-by: Philippe Mathieu-Daudé > >> --- >> ArmPkg/Include/IndustryStandard/ArmTrustZoneSmc.h | 161 >> -- >> 1 file changed, 161 deletions(-) >> delete mode 100644 ArmPkg/Include/IndustryStandard/ArmTrustZoneSmc.h >> >> diff --git a/ArmPkg/Include/IndustryStandard/ArmTrustZoneSmc.h >> b/ArmPkg/Include/IndustryStandard/ArmTrustZoneSmc.h >> deleted file mode 100644 >> index 71b4327ebf..00 >> --- a/ArmPkg/Include/IndustryStandard/ArmTrustZoneSmc.h >> +++ /dev/null >> @@ -1,161 +0,0 @@ >> -/** @file >> -* >> -* Copyright (c) 2012-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. >> -* >> -**/ >> - >> -#ifndef __ARM_TRUSTZONE_SMC_H__ >> -#define __ARM_TRUSTZONE_SMC_H__ >> - >> -#define ARM_TRUSTZONE_UID_4LETTERID 0x1 >> -#define ARM_TRUSTZONE_UID_MD5 0x2 >> - >> -#define ARM_TRUSTZONE_ARM_UID 0x40524d48 // "ARMH" >> - >> -#define IS_ARM_TRUSTZONE_SUPPORTED_SMC(Rx,Region) (((UINTN)(Rx) >= >> (UINTN)ARM_TRUSTZONE_##Region##_SMC_ID_START) && ((UINTN)(Rx) <= >> (UINTN)ARM_TRUSTZONE_##Region##_SMC_ID_END)) >> - >> -#define IS_ARM_TRUSTZONE_DEPRECIATED_SMC(Rx)((UINTN)(Rx) <= >> (UINTN)ARM_TRUSTZONE_DEPRECIATED_SMC_ID_END) >> -#define IS_ARM_TRUSTZONE_TRUSTED_OS_SMC(Rx) >> IS_ARM_TRUSTZONE_SUPPORTED_SMC(Rx,TRUSTED_OS) >> -#define IS_ARM_TRUSTZONE_ARM_FAST_SMC(Rx) >> IS_ARM_TRUSTZONE_SUPPORTED_SMC(Rx,ARM_FAST) >> -#define IS_ARM_TRUSTZONE_SIP_FAST_SMC(Rx) >> IS_ARM_TRUSTZONE_SUPPORTED_SMC(Rx,SIP_FAST) >> -#define IS_ARM_TRUSTZONE_ODM_FAST_SMC(Rx) >> IS_ARM_TRUSTZONE_SUPPORTED_SMC(Rx,ODM_FAST) >> -#define IS_ARM_TRUSTZONE_OEM_FAST_SMC(Rx) >> IS_ARM_TRUSTZONE_SUPPORTED_SMC(Rx,OEM_FAST) >> -#define IS_ARM_TRUSTZONE_TRUSTED_USER_FAST_SMC(Rx) >> IS_ARM_TRUSTZONE_SUPPORTED_SMC(Rx,TRUSTED_USER_FAST) >> -#define IS_ARM_TRUSTZONE_TRUSTED_OS_FAST_SMC(Rx) >> IS_ARM_TRUSTZONE_SUPPORTED_SMC(Rx,TRUSTED_OS_FAST) >> - >> -#define IS_ARM_TRUSTZONE_SUPPORTED_SMC_ID_PRESENCE(Rx,Region) ((Rx) == >> ARM_TRUSTZONE_##Region##_SMC_ID_PRESENCE) >> -#define IS_ARM_TRUSTZONE_SUPPORTED_SMC_ID_UID(Rx,Region) (((Rx) == >> ARM_TRUSTZONE_##Region##_SMC_ID_UID) || \ >> - ((Rx) == >> ARM_TRUSTZONE_##Region##_SMC_ID_UID+1) || \ >> - ((Rx) == >> ARM_TRUSTZONE_##Region##_SMC_ID_UID+2) || \ >> - ((Rx) == >> ARM_TRUSTZONE_##Region##_SMC_ID_UID+3) || \ >> - ((Rx) == >> ARM_TRUSTZONE_##Region##_SMC_ID_UID+4)) >> -#define IS_ARM_TRUSTZONE_SUPPORTED_SMC_ID_REVISION(Rx,Region) (((Rx) == >> ARM_TRUSTZONE_##Region##_SMC_ID_REVISION) || \ >> - ((Rx) == >> ARM_TRUSTZONE_##Region##_SMC_ID_REVISION+1)) >> -#define IS_ARM_TRUSTZONE_SUPPORTED_SMC_ID_RPC(Rx,Region) (((Rx) >= >> ARM_TRUSTZONE_##Region##_SMC_ID_RPC_START) && \ >> - ((Rx) <= >> ARM_TRUSTZONE_##Region##_SMC_ID_RPC_END)) >> - >> -#define ARM_TRUSTZONE_SUPPORTED_SMC_ID_UID_INDEX(Rx,Region) ((Rx) - >> ARM_TRUSTZONE_##Region##_SMC_ID_UID) >> -#define ARM_TRUSTZONE_SUPPORTED_SMC_ID_REVISION_INDEX(Rx,Region) ((Rx) - >> ARM_TRUSTZONE_##Region##_SMC_ID_R
Re: [edk2] [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove unnecessary NULL pointer check.
Hi, On 1/21/19 1:53 PM, Gao, Liming wrote: > Thanks Ard and Laszlo. For the minor change in single patch, the patch may be > sent separately with the clear subject. Or, the patch set can be sent again. Since it is hard to follow technical discussion when top-posted (see https://www.caliburn.nl/topposting.html) without scrolling and sometime loosing context, can we gently suggest bottom-posting in edk2-devel etiquette? (No offence, this is a humble suggestion from a not very active reviewer to a highly active contributor, but this might ease the on-list review workflow). >> -Original Message- >> From: Laszlo Ersek [mailto:ler...@redhat.com] >> Sent: Saturday, January 19, 2019 9:17 AM >> To: Ard Biesheuvel ; Gao, Liming >> >> Cc: Wu, Jiaxin ; Fu, Siyuan ; Wu, >> Hao A ; edk2-devel@lists.01.org; Ye, >> Ting >> Subject: Re: [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove unnecessary NULL >> pointer check. >> >> On 01/18/19 12:09, Ard Biesheuvel wrote: >>> On Fri, 18 Jan 2019 at 06:38, Gao, Liming wrote: This is my idea to avoid the duplicated mail. I also include Ard and Laszlo to collect the feedback on how to handle the partial update in >> the patchset. >>> >>> Laszlo may disagree with me, but I think that it is not always >>> necessary to resend the entire series when only a single patch >>> changes. It does depend on the situation, though: if it is a trivial >>> patch in a more complicated series then it might make little sense. In >>> other case, just resending the whole thing is probably better. >> >> I think resending one patch can be acceptable, but the subject line >> (patch nr) and the threading have to be correct. Also, I don't think >> this approach scales beyond exactly one patch-update; it's easy to lose >> track of version numbers etc. So "use sparingly" I guess? :) For a 3 patches series, I wouldn't worry resending the whole series... The 'git backport-diff' tool is very powerful to resume differencies between 2 series, in particular when the project evolved between versions of a series (simplest example: a rebase): https://github.com/codyprime/git-scripts/blob/master/git-backport-diff#L27 Sadly I can't find a distribution handy package that provides it, so it has to be installed manually. Regards, Phil. > -Original Message- > From: Wu, Jiaxin > Sent: Friday, January 18, 2019 1:32 PM > To: Fu, Siyuan ; Wu, Hao A ; > edk2-devel@lists.01.org > Cc: Ye, Ting ; Gao, Liming > Subject: RE: [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove unnecessary > NULL pointer check. > > Just confirmed with Liming, we don't need to seed the full series patches > if only one is updated. > > Thanks, > jiaxin > >> -Original Message- >> From: Fu, Siyuan >> Sent: Friday, January 18, 2019 1:29 PM >> To: Wu, Hao A ; Wu, Jiaxin ; >> edk2-devel@lists.01.org >> Cc: Ye, Ting ; Gao, Liming >> Subject: RE: [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove >> unnecessary NULL pointer check. >> >> Hi, Jiaxin >> >> Yes the full patch series is needed for a v2 version. >> >> And also, why you removed the "(Instance->Token != NULL)" check in the if >> condition? >> >> BestRegards >> Fu Siyuan >> >> >>> -Original Message- >>> From: Wu, Hao A >>> Sent: Friday, January 18, 2019 1:22 PM >>> To: Wu, Jiaxin ; edk2-devel@lists.01.org >>> Cc: Ye, Ting ; Fu, Siyuan ; Gao, >>> Liming >>> Subject: RE: [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove >> unnecessary NULL >>> pointer check. >>> >>> Hi Jiaxin, >>> >>> A comment that is not related with the content of the patch itself: >>> Please help to send the full patch series when a new version is needed. >>> >>> Best Regards, >>> Hao Wu >>> -Original Message- From: Wu, Jiaxin Sent: Friday, January 18, 2019 1:16 PM To: edk2-devel@lists.01.org Cc: Ye, Ting; Fu, Siyuan; Wu, Hao A; Gao, Liming; Wu, Jiaxin Subject: [PATCH v2 1/3] MdeModulePkg/Dhcp4Dxe: Remove >> unnecessary NULL pointer check. v2: The DHCP Instance might be destroyed in PxeDhcpDone. So, we need safe-delete. REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1469 Since the value of Instance is retrieved from the list Entry, it can't be the NULL pointer, so just remove the unnecessary check. Cc: Ye Ting Cc: Fu Siyuan Cc: Wu Hao A Cc: Gao Liming Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Wu Jiaxin --- MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Io.c | 11 - >> -- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/MdeModulePkg/Universal/Network/Dhcp4
Re: [edk2] [PATCH v2] BaseTools/tools_def GCC5: disable LTO for ASLC invocations
On 1/14/19 3:04 PM, Ard Biesheuvel wrote: > GCC for 32-bit ARM chokes on .aslc files when running with LTO > enabled. Since LTO has no benefit whatsoever here, just disable > it globally for GCC5 and up when building .aslc files. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > Reviewed-by: Leif Lindholm Reviewed-by: Philippe Mathieu-Daudé > --- > BaseTools/Conf/tools_def.template | 27 +++- > 1 file changed, 15 insertions(+), 12 deletions(-) > > diff --git a/BaseTools/Conf/tools_def.template > b/BaseTools/Conf/tools_def.template > index 4d74816837ab..2bd098287219 100755 > --- a/BaseTools/Conf/tools_def.template > +++ b/BaseTools/Conf/tools_def.template > @@ -4155,6 +4155,7 @@ DEFINE GCC48_AARCH64_DLINK_FLAGS = > DEF(GCC_AARCH64_DLINK_FLAGS) > DEFINE GCC48_AARCH64_DLINK2_FLAGS= DEF(GCC_DLINK2_FLAGS_COMMON) > -Wl,--defsym=PECOFF_HEADER_SIZE=0x228 > DEFINE GCC48_ARM_ASLDLINK_FLAGS = DEF(GCC_ARM_ASLDLINK_FLAGS) > -Wl,--oformat=elf32-littlearm > DEFINE GCC48_AARCH64_ASLDLINK_FLAGS = DEF(GCC_AARCH64_ASLDLINK_FLAGS) > +DEFINE GCC48_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) > > DEFINE GCC49_IA32_CC_FLAGS = DEF(GCC48_IA32_CC_FLAGS) > DEFINE GCC49_X64_CC_FLAGS= DEF(GCC48_X64_CC_FLAGS) > @@ -4177,6 +4178,7 @@ DEFINE GCC49_AARCH64_DLINK_FLAGS = > DEF(GCC48_AARCH64_DLINK_FLAGS) -z common- > DEFINE GCC49_AARCH64_DLINK2_FLAGS= DEF(GCC48_AARCH64_DLINK2_FLAGS) > DEFINE GCC49_ARM_ASLDLINK_FLAGS = DEF(GCC48_ARM_ASLDLINK_FLAGS) > DEFINE GCC49_AARCH64_ASLDLINK_FLAGS = DEF(GCC48_AARCH64_ASLDLINK_FLAGS) > +DEFINE GCC49_ASLCC_FLAGS = DEF(GCC48_ASLCC_FLAGS) > > DEFINE GCC5_IA32_CC_FLAGS= DEF(GCC49_IA32_CC_FLAGS) -fno-pic > -fno-pie > DEFINE GCC5_X64_CC_FLAGS = DEF(GCC49_X64_CC_FLAGS) > @@ -4199,6 +4201,7 @@ DEFINE GCC5_AARCH64_DLINK_FLAGS = > DEF(GCC49_AARCH64_DLINK_FLAGS) > DEFINE GCC5_AARCH64_DLINK2_FLAGS = DEF(GCC49_AARCH64_DLINK2_FLAGS) > -Wno-error > DEFINE GCC5_ARM_ASLDLINK_FLAGS = DEF(GCC49_ARM_ASLDLINK_FLAGS) > DEFINE GCC5_AARCH64_ASLDLINK_FLAGS = DEF(GCC49_AARCH64_ASLDLINK_FLAGS) > +DEFINE GCC5_ASLCC_FLAGS = DEF(GCC49_ASLCC_FLAGS) -fno-lto > > > > # > @@ -4301,7 +4304,7 @@ DEFINE GCC5_AARCH64_ASLDLINK_FLAGS = > DEF(GCC49_AARCH64_ASLDLINK_FLAGS) > *_GCC48_IA32_ASLPP_PATH = DEF(GCC48_IA32_PREFIX)gcc > *_GCC48_IA32_RC_PATH = DEF(GCC48_IA32_PREFIX)objcopy > > -*_GCC48_IA32_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) -m32 > +*_GCC48_IA32_ASLCC_FLAGS = DEF(GCC48_ASLCC_FLAGS) -m32 > *_GCC48_IA32_ASLDLINK_FLAGS = DEF(GCC48_IA32_X64_ASLDLINK_FLAGS) > -Wl,-m,elf_i386 > *_GCC48_IA32_ASM_FLAGS= DEF(GCC48_ASM_FLAGS) -m32 -march=i386 > *_GCC48_IA32_DLINK_FLAGS = DEF(GCC48_IA32_X64_DLINK_FLAGS) > -Wl,-m,elf_i386,--oformat=elf32-i386 > @@ -4329,7 +4332,7 @@ RELEASE_GCC48_IA32_CC_FLAGS = > DEF(GCC48_IA32_CC_FLAGS) -Os -Wno-unused-but > *_GCC48_X64_ASLPP_PATH = DEF(GCC48_X64_PREFIX)gcc > *_GCC48_X64_RC_PATH = DEF(GCC48_X64_PREFIX)objcopy > > -*_GCC48_X64_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) -m64 > +*_GCC48_X64_ASLCC_FLAGS = DEF(GCC48_ASLCC_FLAGS) -m64 > *_GCC48_X64_ASLDLINK_FLAGS = DEF(GCC48_IA32_X64_ASLDLINK_FLAGS) > -Wl,-m,elf_x86_64 > *_GCC48_X64_ASM_FLAGS= DEF(GCC48_ASM_FLAGS) -m64 > *_GCC48_X64_DLINK_FLAGS = DEF(GCC48_X64_DLINK_FLAGS) > @@ -4359,7 +4362,7 @@ RELEASE_GCC48_X64_CC_FLAGS = > DEF(GCC48_X64_CC_FLAGS) -Os -Wno-unused-but-s > *_GCC48_ARM_ARCHCC_FLAGS = -mthumb > *_GCC48_ARM_PLATFORM_FLAGS = -march=armv7-a > > -*_GCC48_ARM_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) > +*_GCC48_ARM_ASLCC_FLAGS = DEF(GCC48_ASLCC_FLAGS) > *_GCC48_ARM_ASLDLINK_FLAGS = DEF(GCC48_ARM_ASLDLINK_FLAGS) > *_GCC48_ARM_ASM_FLAGS= DEF(GCC48_ARM_ASM_FLAGS) > *_GCC48_ARM_DLINK_FLAGS = DEF(GCC48_ARM_DLINK_FLAGS) > @@ -4389,7 +4392,7 @@ RELEASE_GCC48_ARM_CC_FLAGS = > DEF(GCC48_ARM_CC_FLAGS) -Wno-unused-but-set-v > *_GCC48_AARCH64_ASLPP_PATH = ENV(GCC48_AARCH64_PREFIX)gcc > *_GCC48_AARCH64_RC_PATH = ENV(GCC48_AARCH64_PREFIX)objcopy > > -*_GCC48_AARCH64_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) > +*_GCC48_AARCH64_ASLCC_FLAGS = DEF(GCC48_ASLCC_FLAGS) > *_GCC48_AARCH64_ASLDLINK_FLAGS = DEF(GCC48_AARCH64_ASLDLINK_FLAGS) > *_GCC48_AARCH64_ASM_FLAGS= DEF(GCC48_AARCH64_ASM_FLAGS) > *_GCC48_AARCH64_DLINK_FLAGS =
Re: [edk2] [PATCH] BaseTools/tools_def ARM GCC5: disable LTO for ASLC invocations
On 1/14/19 2:18 PM, Gao, Liming wrote: > Ard: > Could you consider the suggestion from > https://lists.01.org/pipermail/edk2-devel/2019-January/034698.html? There might be a special case for Aarch64, but I'm not seeing it. > > Thanks > Liming >> -Original Message- >> From: Leif Lindholm [mailto:leif.lindh...@linaro.org] >> Sent: Monday, January 14, 2019 7:42 PM >> To: Ard Biesheuvel >> Cc: edk2-devel@lists.01.org; Gao, Liming ; Feng, Bob C >> >> Subject: Re: [PATCH] BaseTools/tools_def ARM GCC5: disable LTO for ASLC >> invocations >> >> On Mon, Jan 07, 2019 at 07:55:41AM +0100, Ard Biesheuvel wrote: >>> GCC for 32-bit ARM chokes on .aslc files when running with LTO >>> enabled. Since LTO has no benefit whatsoever here, just disable >>> it. >>> >>> Contributed-under: TianoCore Contribution Agreement 1.1 >>> Signed-off-by: Ard Biesheuvel >> >> Looks sensible. >> Reviewed-by: Leif Lindholm >> >>> --- >>> BaseTools/Conf/tools_def.template | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/BaseTools/Conf/tools_def.template >>> b/BaseTools/Conf/tools_def.template >>> index f7eb87af14c2..e68cfd9a4997 100755 >>> --- a/BaseTools/Conf/tools_def.template >>> +++ b/BaseTools/Conf/tools_def.template >>> @@ -5145,7 +5145,7 @@ RELEASE_GCC5_X64_DLINK_FLAGS = >>> DEF(GCC5_X64_DLINK_FLAGS) -flto -Os >>> *_GCC5_ARM_RC_PATH = ENV(GCC5_ARM_PREFIX)objcopy >>> >>> *_GCC5_ARM_ARCHCC_FLAGS = -mthumb >>> -*_GCC5_ARM_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) >>> +*_GCC5_ARM_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) -fno-lto >>> *_GCC5_ARM_ASLDLINK_FLAGS= DEF(GCC5_ARM_ASLDLINK_FLAGS) >>> *_GCC5_ARM_ASM_FLAGS = DEF(GCC5_ARM_ASM_FLAGS) >>> *_GCC5_ARM_DLINK2_FLAGS = DEF(GCC5_ARM_DLINK2_FLAGS) >>> -- >>> 2.20.1 >>> > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] BaseTools/tools_def ARM GCC5: disable LTO for ASLC invocations
Hi Ard, On 1/7/19 7:55 AM, Ard Biesheuvel wrote: > GCC for 32-bit ARM chokes on .aslc files when running with LTO > enabled. Since LTO has no benefit whatsoever here, just disable > it. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > BaseTools/Conf/tools_def.template | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/BaseTools/Conf/tools_def.template > b/BaseTools/Conf/tools_def.template > index f7eb87af14c2..e68cfd9a4997 100755 > --- a/BaseTools/Conf/tools_def.template > +++ b/BaseTools/Conf/tools_def.template > @@ -5145,7 +5145,7 @@ RELEASE_GCC5_X64_DLINK_FLAGS = > DEF(GCC5_X64_DLINK_FLAGS) -flto -Os > *_GCC5_ARM_RC_PATH = ENV(GCC5_ARM_PREFIX)objcopy > > *_GCC5_ARM_ARCHCC_FLAGS = -mthumb > -*_GCC5_ARM_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) > +*_GCC5_ARM_ASLCC_FLAGS = DEF(GCC_ASLCC_FLAGS) -fno-lto Why not add it globally to GCC5_ASLCC_FLAGS? > *_GCC5_ARM_ASLDLINK_FLAGS= DEF(GCC5_ARM_ASLDLINK_FLAGS) > *_GCC5_ARM_ASM_FLAGS = DEF(GCC5_ARM_ASM_FLAGS) > *_GCC5_ARM_DLINK2_FLAGS = DEF(GCC5_ARM_DLINK2_FLAGS) > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdePkg/BaseLib: Add Base64Encode() and Base64Decode()
Hi Shenglei,
On 1/7/19 9:35 AM, Shenglei Zhang wrote:
> Introduce public functions Base64Encode and Base64Decode.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1370
>
> Cc: Michael D Kinney
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang
> ---
> MdePkg/Include/Library/BaseLib.h | 56 +
> MdePkg/Library/BaseLib/String.c | 345 +++
> 2 files changed, 401 insertions(+)
>
> diff --git a/MdePkg/Include/Library/BaseLib.h
> b/MdePkg/Include/Library/BaseLib.h
> index 1eb842384e..e5bd054875 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -2720,6 +2720,62 @@ AsciiStrnToUnicodeStrS (
>OUT UINTN *DestinationLength
>);
>
> +/**
> + Convert binary data to a Base64 encoded ascii string based on RFC4648.
> +
> + Produce a Null-terminated Ascii string in the output buffer specified by
> AsciiPtr and AsciiSize.
> + The Ascii string is produced by converting the data string specified by
> DataPtr and DataLen.
> +
> + @param DataPtr Input UINT8 data
> + @param DataLenNumber of UINT8 bytes of data
> + @param AsciiPtr Pointer to output string buffer
> + @param AsciiSize Size of ascii buffer. Set to 0 to get the size needed.
> + Caller is responsible for passing in buffer
> of AsciiSize
> +
> + @retval RETURN_SUCCESSWhen ascii buffer is filled in.
> + @retval RETURN_INVALID_PARAMETER If DataPtr is NULL or AsciiSize is NULL.
> + @retval RETURN_INVALID_PARAMETER If DataLen or AsciiSize is too big.
> + @retval RETURN_BUFFER_TOO_SMALL If DataLen is 0 and AsciiSize is <1.
> + @retval RETURN_BUFFER_TOO_SMALL If AsciiPtr is NULL or too small.
> +
> +**/
> +RETURN_STATUS
> +EFIAPI
> +Base64Encode (
> + IN CONST UINT8 *DataPtr,
> + INUINTN DataLen,
> + OUT CHAR8 *AsciiPtr OPTIONAL,
> + IN OUTUINTN *AsciiSize
> + );
> +
> +/**
> + Convert Base64 ascii string to binary data based on RFC4648.
> +
> + Produce Null-terminated binary data in the output buffer specified by
> BinPtr and BinSize.
> + The binary data is produced by converting the Base64 ascii string
> specified by DataPtr and DataLen.
> +
> + @param DataPtr Input ASCII characters
> + @param DataLen Number of ASCII characters
> + @param BinPtrPointer to output buffer
> + @param BinSize Caller is responsible for passing in buffer of at
> least BinSize.
> +Set 0 to get the size needed. Set to bytes
> stored on return.
> +
> + @retval RETURN_SUCCESSWhen binary buffer is filled in.
> + @retval RETURN_INVALID_PARAMETER If DataPtr is NULL or BinSize is NULL.
> + @retval RETURN_INVALID_PARAMETER If DataLen or BinSize is too big.
> + @retval RETURN_INVALID_PARAMETER If BinPtr NULL and BinSize != 0.
> + @retval RETURN_INVALID_PARAMETER If there is any Invalid character in
> input stream.
> + @retval RETURN_BUFFER_TOO_SMALL If Buffer length is too small.
> + **/
> +RETURN_STATUS
> +EFIAPI
> +Base64Decode (
> + IN CONST CHAR8 *DataPtr,
> + INUINTN DataLen,
> + OUT UINT8 *BinPtr OPTIONAL,
> + IN OUTUINTN *BinSize
> + );
> +
> /**
>Converts an 8-bit value to an 8-bit BCD value.
>
> diff --git a/MdePkg/Library/BaseLib/String.c b/MdePkg/Library/BaseLib/String.c
> index e6df12797d..e491489559 100644
> --- a/MdePkg/Library/BaseLib/String.c
> +++ b/MdePkg/Library/BaseLib/String.c
> @@ -1763,6 +1763,351 @@ AsciiStrToUnicodeStr (
>
> #endif
>
> +//
> +// The basis for Base64 encoding is RFC 4686
> https://tools.ietf.org/html/rfc4648
> +//
> +// RFC 4686 has a number of MAY and SHOULD cases. This implementation
> chooses
> +// the more restrictive versions for security concerns (see RFC 4686 section
> 3.3).
> +//
> +// A invalid character, if encountered during the decode operation, causes
> the data
> +// to be rejected. In addition, the '=' padding character is only allowed at
> the end
> +// of the Base64 encoded string.
> +//
> +#define BAD_V 99
> +
> +STATIC CHAR8 Encoding_table[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ"
> +"abcdefghijklmnopqrstuvwxyz"
> +"0123456789+/";
> +
> +STATIC UINT8 Decoding_table[] = {
> + //
> + // Valid characters
> ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
> + // Also, set '=' as a zero for decoding
> + // 0 ,1, 2, 3,4, 5,
>6, 7, 8,9, a,
> b,c, d,e,f
> + BAD_V, BAD_V, BAD_V, BAD_V, BAD_V, BAD_V, BAD_V, BAD_V, BAD_V,
> BAD_V, BAD_V, BAD_V, BAD_V, BAD_V, BAD_V, BAD_V, // 0
> + BAD_V, BAD_V, BAD_V, BAD_V, BAD_V, BAD_V, BAD_V, BAD_V, BAD_V,
> BAD_V,
Re: [edk2] [PATCH 00/26] remove the GCC44 through GCC47 toolchains
C44 leaf definitions > BaseTools/tools_def.template: propagate loss of GCC44 references > BaseTools/tools_def.template: rename GCC44_ALL_CC_FLAGS to > GCC48_ALL_CC_FLAGS > BaseTools/tools_def.template: eliminate GCC44_IA32_X64_DLINK_FLAGS > BaseTools/tools_def.template: rename GCC44_IA32_X64_DLINK_COMMON to > GCC48_IA32_X64_DLINK_COMMON > BaseTools/tools_def.template: remove comment about GCC44 + > LzmaF86Compress > BaseTools/tools_def.template: remove GCC44 documentation > ArmPkg/ArmSoftFloatLib: drop build flags specific to GCC46/GCC47 > CryptoPkg/BaseCryptLib: drop build flags specific to GCC44 > Revert "MdePkg: avoid __builtin_unreachable() on GCC v4.4" > > ArmPkg/Library/ArmSoftFloatLib/ArmSoftFloatLib.inf | 2 - > BaseTools/Conf/tools_def.template | 638 +++- > CryptoPkg/Library/BaseCryptLib/BaseCryptLib.inf| 2 - > CryptoPkg/Library/BaseCryptLib/PeiCryptLib.inf | 2 - > CryptoPkg/Library/BaseCryptLib/RuntimeCryptLib.inf | 2 - > CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf | 1 - > EmulatorPkg/Unix/Host/Host.inf | 4 - > EmulatorPkg/build.sh | 18 +- > MdePkg/Include/Base.h | 3 +- > OvmfPkg/README | 6 +- > OvmfPkg/build.sh | 16 +- > Vlv2TbltDevicePkg/bld_vlv.sh | 14 +- > 12 files changed, 81 insertions(+), 627 deletions(-) > Series: Reviewed-by: Philippe Mathieu-Daudé ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ArmPlatformPkg/PL011SerialPortLib: use untyped PCD for register base
On 12/17/18 7:51 PM, Ard Biesheuvel wrote:
> Use an untyped PCD reference for PcdSerialRegisterBase, so that the
> library gets built without hardcoded values, permitting modules to
> override the default serial port. This allows SerialDxe to use a
> different serial port from the one used for DEBUG output (which
> often gets occluded due to the console driver clearing the screen)
You missed the trailing '.' :)
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Philippe Mathieu-Daudé
> ---
> ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c | 14
> +++---
> ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf | 4 +++-
> 2 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> index 212991d63859..d576f79c3e6e 100644
> --- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> +++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.c
> @@ -48,7 +48,7 @@ SerialPortInitialize (
>StopBits = (EFI_STOP_BITS_TYPE) FixedPcdGet8 (PcdUartDefaultStopBits);
>
>return PL011UartInitializePort (
> - (UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> + (UINTN)PcdGet64 (PcdSerialRegisterBase),
> PL011UartClockGetFreq(),
> &BaudRate,
> &ReceiveFifoDepth,
> @@ -75,7 +75,7 @@ SerialPortWrite (
>IN UINTN NumberOfBytes
>)
> {
> - return PL011UartWrite ((UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> Buffer, NumberOfBytes);
> + return PL011UartWrite ((UINTN)PcdGet64 (PcdSerialRegisterBase), Buffer,
> NumberOfBytes);
> }
>
> /**
> @@ -95,7 +95,7 @@ SerialPortRead (
>IN UINTN NumberOfBytes
> )
> {
> - return PL011UartRead ((UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> Buffer, NumberOfBytes);
> + return PL011UartRead ((UINTN)PcdGet64 (PcdSerialRegisterBase), Buffer,
> NumberOfBytes);
> }
>
> /**
> @@ -111,7 +111,7 @@ SerialPortPoll (
>VOID
>)
> {
> - return PL011UartPoll ((UINTN)FixedPcdGet64 (PcdSerialRegisterBase));
> + return PL011UartPoll ((UINTN)PcdGet64 (PcdSerialRegisterBase));
> }
> /**
>Set new attributes to PL011.
> @@ -156,7 +156,7 @@ SerialPortSetAttributes (
>)
> {
>return PL011UartInitializePort (
> - (UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> + (UINTN)PcdGet64 (PcdSerialRegisterBase),
> PL011UartClockGetFreq(),
> BaudRate,
> ReceiveFifoDepth,
> @@ -198,7 +198,7 @@ SerialPortSetControl (
>IN UINT32 Control
>)
> {
> - return PL011UartSetControl ((UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> Control);
> + return PL011UartSetControl ((UINTN)PcdGet64 (PcdSerialRegisterBase),
> Control);
> }
>
> /**
> @@ -239,5 +239,5 @@ SerialPortGetControl (
>OUT UINT32 *Control
>)
> {
> - return PL011UartGetControl ((UINTN)FixedPcdGet64 (PcdSerialRegisterBase),
> Control);
> + return PL011UartGetControl ((UINTN)PcdGet64 (PcdSerialRegisterBase),
> Control);
> }
> diff --git a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> index 5ce5b2f5304c..bca7bed875c6 100644
> --- a/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> +++ b/ArmPlatformPkg/Library/PL011SerialPortLib/PL011SerialPortLib.inf
> @@ -36,8 +36,10 @@
>MdeModulePkg/MdeModulePkg.dec
>ArmPlatformPkg/ArmPlatformPkg.dec
>
> -[FixedPcd]
> +[Pcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase
> +
> +[FixedPcd]
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultDataBits
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultParity
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] Platform/FVP-AArch64: use different serial ports for DEBUG and console
On 12/17/18 7:53 PM, Ard Biesheuvel wrote:
> The FVP models expose several emulated serial ports, and always start with
> Xterm windows connected to at least two of them. So let's switch to the
> second one for DEBUG output, leaving the original one for console output
> via SerialDxe.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Philippe Mathieu-Daudé
> ---
> Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> index 7094e57ee13a..7db1c675c3d9 100644
> --- a/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> +++ b/Platform/ARM/VExpressPkg/ArmVExpress-FVP-AArch64.dsc
> @@ -125,7 +125,7 @@
>gArmPlatformTokenSpaceGuid.PcdSP805WatchdogClockFrequencyInHz|2400
>
>## PL011 - Serial Terminal
> - gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x1c09
> + gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x1c0a
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultBaudRate|115200
>gEfiMdePkgTokenSpaceGuid.PcdUartDefaultReceiveFifoDepth|0
>
> @@ -239,7 +239,10 @@
>MdeModulePkg/Universal/Console/ConSplitterDxe/ConSplitterDxe.inf
>MdeModulePkg/Universal/Console/GraphicsConsoleDxe/GraphicsConsoleDxe.inf
>MdeModulePkg/Universal/Console/TerminalDxe/TerminalDxe.inf
> - MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
> + MdeModulePkg/Universal/SerialDxe/SerialDxe.inf {
> +
> + gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase|0x1c09
> + }
>
>MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/2] Fix typos in MdePkg and SecurityPkg
On 12/17/18 11:27 AM, Laszlo Ersek wrote: > On 12/17/18 11:08, Philippe Mathieu-Daudé wrote: >> Hi, >> >> On 12/11/18 2:31 AM, Shenglei Zhang wrote: >>> Change EFI_RETURNING_FROM_EFI_APPLICATOIN to >>> EFI_RETURNING_FROM_EFI_APPLICATION. >>> >>> Cc: Michael D Kinney >>> Cc: Liming Gao >>> Cc: Chao Zhang >>> Cc: Jiewen Yao >>> Shenglei Zhang (2): >>> MdePkg/IndustryStandard: Fix a typo in UefiTcgPlatform.h >>> SecurityPkg/Tcg: Fix typos in TcgDxe.c and Tcg2Dxe.c >>> >>> MdePkg/Include/IndustryStandard/UefiTcgPlatform.h | 2 +- >>> SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c | 4 ++-- >>> SecurityPkg/Tcg/TcgDxe/TcgDxe.c | 4 ++-- >>> 3 files changed, 5 insertions(+), 5 deletions(-) >>> >> >> NACK, this change has to be in the same patch to be bisectable. >> >> However, if you resend the same change squashed in a single patch, you >> can directly add my: >> Reviewed-by: Philippe Mathieu-Daudé > > Good catch! Bisectability is important! > > An alternative approach to yours could be: first, introduce the > correctly spelled macro (with the same value); second, update the > references; third, remove the misspelled macro. This would be *slightly* > more idiomatic for edk2, where we tend to avoid cross-package patches, > if we can. TIL "avoid cross-package patches" (for edk2). While Laszlo's alternative looks overkill, it is also perfect =) ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/2] Fix typos in MdePkg and SecurityPkg
Hi, On 12/11/18 2:31 AM, Shenglei Zhang wrote: > Change EFI_RETURNING_FROM_EFI_APPLICATOIN to > EFI_RETURNING_FROM_EFI_APPLICATION. > > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Chao Zhang > Cc: Jiewen Yao > Shenglei Zhang (2): > MdePkg/IndustryStandard: Fix a typo in UefiTcgPlatform.h > SecurityPkg/Tcg: Fix typos in TcgDxe.c and Tcg2Dxe.c > > MdePkg/Include/IndustryStandard/UefiTcgPlatform.h | 2 +- > SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c | 4 ++-- > SecurityPkg/Tcg/TcgDxe/TcgDxe.c | 4 ++-- > 3 files changed, 5 insertions(+), 5 deletions(-) > NACK, this change has to be in the same patch to be bisectable. However, if you resend the same change squashed in a single patch, you can directly add my: Reviewed-by: Philippe Mathieu-Daudé Regards, Phil. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch V2] BaseTools: Fix PcdArray issue
On 12/14/18 5:15 PM, BobCF wrote:
> From: "Feng, Bob C"
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=1390
>
> 1. support hex number for array index
> 2. support Non-Dynamic Pcd for array data type
> 3. support {} and {CODE()} for array data type
> 4. Change GetStructurePcdMaxSize to be a static function since it need to
> be called in another static function. And this function does not depend on
> it's class instance.
> 5. Add unittest for RemoveCComments function and
> ArrayIndex regular expression.
Thanks for this Bob!
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng
> Cc: Liming Gao
> Cc: Ard Biesheuvel
> Cc: Philippe Mathieu-Daudé
Reviewed-by: Philippe Mathieu-Daudé
> ---
> BaseTools/Source/Python/Common/Misc.py| 6 ++
> .../Python/Workspace/BuildClassObject.py | 3 +-
> .../Source/Python/Workspace/DscBuildData.py | 59 ---
> BaseTools/Tests/TestRegularExpression.py | 54 +
> 4 files changed, 99 insertions(+), 23 deletions(-)
> create mode 100644 BaseTools/Tests/TestRegularExpression.py
>
> diff --git a/BaseTools/Source/Python/Common/Misc.py
> b/BaseTools/Source/Python/Common/Misc.py
> index b063f064fb..ea09f85e70 100644
> --- a/BaseTools/Source/Python/Common/Misc.py
> +++ b/BaseTools/Source/Python/Common/Misc.py
> @@ -2144,10 +2144,16 @@ def CopyDict(ori_dict):
> if isinstance(ori_dict[key],(dict,OrderedDict)):
> new_dict[key] = CopyDict(ori_dict[key])
> else:
> new_dict[key] = ori_dict[key]
> return new_dict
> +
> +#
> +# Remove the c/c++ comments: // and /* */
> +#
> +def RemoveCComments(ctext):
> +return re.sub('//.*?\n|/\*.*?\*/', '\n', ctext, flags=re.S)
> ##
> #
> # This acts like the main() function for the script, unless it is 'import'ed
> into another
> # script.
> #
> diff --git a/BaseTools/Source/Python/Workspace/BuildClassObject.py
> b/BaseTools/Source/Python/Workspace/BuildClassObject.py
> index 008eee1a16..e9a1195fd2 100644
> --- a/BaseTools/Source/Python/Workspace/BuildClassObject.py
> +++ b/BaseTools/Source/Python/Workspace/BuildClassObject.py
> @@ -17,11 +17,11 @@ import collections
> import re
> from collections import OrderedDict
> from Common.Misc import CopyDict
> import copy
> StructPattern = re.compile(r'[_a-zA-Z][0-9A-Za-z_\[\]]*$')
> -ArrayIndex = re.compile("\[\s*\d{0,1}\s*\]")
> +ArrayIndex = re.compile("\[\s*[0-9a-fA-FxX]*\s*\]")
> ## PcdClassObject
> #
> # This Class is used for PcdObject
> #
> # @param object: Inherited from object class
> @@ -82,10 +82,11 @@ class PcdClassObject(object):
> dimension = ArrayIndex.findall(self._DatumType)
> for item in dimension:
> maxsize = item.lstrip("[").rstrip("]").strip()
> if not maxsize:
> maxsize = "-1"
> +maxsize = str(int(maxsize,16)) if
> maxsize.startswith(("0x","0X")) else maxsize
> self._Capacity.append(maxsize)
> if hasattr(self, "SkuOverrideValues"):
> for sku in self.SkuOverrideValues:
> for defaultstore in self.SkuOverrideValues[sku]:
> fields = self.SkuOverrideValues[sku][defaultstore]
> diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py
> b/BaseTools/Source/Python/Workspace/DscBuildData.py
> index b485c75a84..37fb8d56b6 100644
> --- a/BaseTools/Source/Python/Workspace/DscBuildData.py
> +++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
> @@ -31,11 +31,11 @@ from .MetaDataTable import *
> from .MetaFileTable import *
> from .MetaFileParser import *
>
> from .WorkspaceCommon import GetDeclaredPcd
> from Common.Misc import AnalyzeDscPcd
> -from Common.Misc import ProcessDuplicatedInf
> +from Common.Misc import ProcessDuplicatedInf,RemoveCComments
> import re
> from Common.Parsing import IsValidWord
> from Common.VariableAttributes import VariableAttributes
> import Common.GlobalData as GlobalData
> import subprocess
> @@ -1573,11 +1573,11 @@ class DscBuildData(PlatformBuildClassObject):
> mindefaultstorename =
> DefaultStoreObj.GetMin(PcdDefaultStoreSet)
>
> str_pcd_obj.SkuInfoList[self.SkuIdMgr.SystemSkuId].HiiDefaultValue =
> str_pcd_obj.SkuInfoList[self.SkuIdMgr.SystemSkuId].DefaultStoreDict[mindefaultstorename]
>
> for str_pcd_obj in S_pcd_set.values():
>
> -str_pcd_obj.MaxDatumSize =
> self.GetStructurePcdMaxSize(str_pcd_
Re: [edk2] [PATCH v2 edk2-platforms 00/20] Platform/Broadcom: Add Raspberry Pi 3 support
-
# Steps to reproduce an image:
#
# 1/ build the Docker image:
# $ docker build -t atf-raspi3-builder .
#
# 2/ build the firmware:
# The image will store the built files into the /build directory (within
Docker).
# You can mount a host directory using the '-v :/build'
option.
# For example, using the 'build' directory in your current directory:
# $ docker run --rm -v $PWD/build:/build atf-raspi3-builder
# [...]
# AS lib/xlat_tables_v2/aarch64/enable_mmu.S
# PP bl1/bl1.ld.S
# LD /build/rpi3/release/bl1/bl1.elf
# BIN /build/rpi3/release/bl1.bin
# Built /build/rpi3/release/bl1.bin successfully
# [...]
# OD /build/rpi3/release/bl2/bl2.dump
# OD /build/rpi3/release/bl31/bl31.dump
#
# You can now access the binaries:
# $ ls --numeric-uid-gid -l $PWD/build/rpi3/release/fip.bin
$PWD/build/rpi3/release/bl1.bin
# -rwxr-xr-x. 1 0 0 18785 Dec 14 16:31 build/rpi3/release/bl1.bin
# -rw-r--r--. 1 0 0 41714 Dec 14 16:31 build/rpi3/release/fip.bin
#
# 3/ Run other commands
# Simply add the command after the image name:
# $ docker run --rm -v $PWD/build:/build atf-raspi3-builder fiptool info
build/rpi3/release/fip.bin
# Trusted Boot Firmware BL2: offset=0x88, size=0x41F1, cmdline="--tb-fw"
# EL3 Runtime Firmware BL31: offset=0x4279, size=0x6079, cmdline="--soc-fw"
#
# 4/ Enter the Docker image
# Use 'bash' as the command name.
# $ docker run --rm -it -v $PWD/build:/build atf-raspi3-builder bash
#
# 5/ Use another ATF repository
# Mount the repository under /source:
# $ docker run --rm -v $PWD/build:/build -v
~/source/arm-trusted-firmware:/source atf-raspi3-builder
# -
# Linaro GCC 5.5-2017.10 Final Release is based on Ubuntu
FROM ubuntu:17.10
MAINTAINER Philippe Mathieu-Daudé
# Install the required packages to build TF-A
#
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/user-guide.rst#tools
RUN apt update && \
DEBIAN_FRONTEND=noninteractive apt-get install -yy eatmydata && \
DEBIAN_FRONTEND=noninteractive eatmydata \
apt-get install -y --no-install-recommends \
build-essential \
ca-certificates \
curl \
device-tree-compiler \
gcc \
git \
libssl-dev \
make && \
rm -rf /var/lib/apt/lists/*
# Install Linaro GCC 5.5-2017.10 Final Release
RUN curl -sSL
http://releases.linaro.org/components/toolchain/binaries/5.5-2017.10/aarch64-elf/gcc-linaro-5.5.0-2017.10-x86_64_aarch64-elf.tar.xz
\
| tar -xJC /opt
ENV
CROSS_COMPILE=/opt/gcc-linaro-5.5.0-2017.10-x86_64_aarch64-elf/bin/aarch64-elf-
# Clone the latest stable release (v2.0) of TF-A
RUN git clone \
--quiet \
--depth 1 \
--branch v2.0 \
https://github.com/ARM-software/arm-trusted-firmware.git /source
# Build the FIP tool
#
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/user-guide.rst#building-and-using-the-fip-tool
RUN make -C /source fiptool
ENV PATH=${PATH}:/source/tools/fiptool
# The default command to run when calling this image without argument:
CMD make -C /source BUILD_BASE=/build \
PLAT=rpi3 \
PRELOADED_BL33_BASE=0x3 \
RPI3_PRELOADED_DTB_BASE=0x1 \
SUPPORT_VFP=1 \
RPI3_USE_UEFI_MAP=1 \
fip all
---
If you have docker installed, you can test using:
# build image
$ docker build \
-t atf-raspi3-builder \
https://gitlab.com/philmd/edk2-platforms/raw/raspi3-atf/Platform/RaspberryPi/RPi3/Arm-Tf/Dockerfile
# build firmware
$ docker run --rm -v $PWD/test-raspi3-build:/build atf-raspi3-builder
# check built binaries
$ ls -1 test-raspi3-build/rpi3/release/*.bin
test-raspi3-build/rpi3/release/armstub8.bin
test-raspi3-build/rpi3/release/bl1.bin
test-raspi3-build/rpi3/release/bl1_pad.bin
test-raspi3-build/rpi3/release/bl2.bin
test-raspi3-build/rpi3/release/bl31.bin
test-raspi3-build/rpi3/release/fip.bin
Regards,
Phil.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdeModulePkg/PciBus: Fix system hang when no PCI Option ROM exists
On 12/12/18 4:10 PM, Ruiyu Ni wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1394
>
> When there is no PCI option ROM exists, today's logic still creates
> virtual BAR for option ROM using Length = 0, Alignment = (-1).
> It causes the final MEM32 alignment requirement is as big as
> 0x_.
>
> The patch fixes this issue by only creating virtual BAR for option
> ROM when there is PCI option ROM.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni
> Cc: Chiu Chasel
> Cc: Hao A Wu
> Cc: Jian J Wang
> ---
> MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> index 7255bcfbbc..ee5c77147e 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c
> @@ -515,10 +515,12 @@ PciHostBridgeResourceAllocator (
>// All devices' Option ROM share the same MEM32 resource.
>//
>MaxOptionRomSize = GetMaxOptionRomSize (RootBridgeDev);
> - RootBridgeDev->PciBar[0].BarType = PciBarTypeOpRom;
> - RootBridgeDev->PciBar[0].Length= MaxOptionRomSize;
> - RootBridgeDev->PciBar[0].Alignment = MaxOptionRomSize - 1;
> - GetResourceFromDevice (RootBridgeDev, IoBridge, Mem32Bridge,
> PMem32Bridge, Mem64Bridge, PMem64Bridge);
> + if (MaxOptionRomSize != 0) {
> +RootBridgeDev->PciBar[0].BarType = PciBarTypeOpRom;
> +RootBridgeDev->PciBar[0].Length= MaxOptionRomSize;
> +RootBridgeDev->PciBar[0].Alignment = MaxOptionRomSize - 1;
> +GetResourceFromDevice (RootBridgeDev, IoBridge, Mem32Bridge,
> PMem32Bridge, Mem64Bridge, PMem64Bridge);
> + }
>
>//
>// Create resourcemap by going through all the devices subject to this
> root bridge
>
Reviewed-by: Philippe Mathieu-Daudé
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] BaseTools: Fix PcdArray issue
Hi Bob,
On 12/14/18 10:55 AM, BobCF wrote:
> https://bugzilla.tianocore.org/show_bug.cgi?id=1390
> 1. support hex number for array index
> 2. support Non-Dynamic Pcd for array data type
> 3. support {} and {CODE()} for array data type
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Bob Feng
> Cc: Liming Gao
> Cc: Ard Biesheuvel
> ---
> BaseTools/Source/Python/Common/Misc.py| 6 ++
> .../Python/Workspace/BuildClassObject.py | 3 +-
> .../Source/Python/Workspace/DscBuildData.py | 59 ---
> 3 files changed, 45 insertions(+), 23 deletions(-)
>
> diff --git a/BaseTools/Source/Python/Common/Misc.py
> b/BaseTools/Source/Python/Common/Misc.py
> index b063f064fb..ea09f85e70 100644
> --- a/BaseTools/Source/Python/Common/Misc.py
> +++ b/BaseTools/Source/Python/Common/Misc.py
> @@ -2144,10 +2144,16 @@ def CopyDict(ori_dict):
> if isinstance(ori_dict[key],(dict,OrderedDict)):
> new_dict[key] = CopyDict(ori_dict[key])
> else:
> new_dict[key] = ori_dict[key]
> return new_dict
> +
> +#
> +# Remove the c/c++ comments: // and /* */
> +#
> +def RemoveCComments(ctext):
> +return re.sub('//.*?\n|/\*.*?\*/', '\n', ctext, flags=re.S)
What about multi-line comments?
> ##
> #
> # This acts like the main() function for the script, unless it is 'import'ed
> into another
> # script.
> #
> diff --git a/BaseTools/Source/Python/Workspace/BuildClassObject.py
> b/BaseTools/Source/Python/Workspace/BuildClassObject.py
> index 008eee1a16..e9a1195fd2 100644
> --- a/BaseTools/Source/Python/Workspace/BuildClassObject.py
> +++ b/BaseTools/Source/Python/Workspace/BuildClassObject.py
> @@ -17,11 +17,11 @@ import collections
> import re
> from collections import OrderedDict
> from Common.Misc import CopyDict
> import copy
> StructPattern = re.compile(r'[_a-zA-Z][0-9A-Za-z_\[\]]*$')
> -ArrayIndex = re.compile("\[\s*\d{0,1}\s*\]")
> +ArrayIndex = re.compile("\[\s*[0-9a-fA-FxX]*\s*\]")
These regex changes seems easily unit-testable, is it possible to add
some tests? In particular the RemoveCComments() seems fragile.
> ## PcdClassObject
> #
> # This Class is used for PcdObject
> #
> # @param object: Inherited from object class
> @@ -82,10 +82,11 @@ class PcdClassObject(object):
> dimension = ArrayIndex.findall(self._DatumType)
> for item in dimension:
> maxsize = item.lstrip("[").rstrip("]").strip()
> if not maxsize:
> maxsize = "-1"
> +maxsize = str(int(maxsize,16)) if
> maxsize.startswith(("0x","0X")) else maxsize
> self._Capacity.append(maxsize)
> if hasattr(self, "SkuOverrideValues"):
> for sku in self.SkuOverrideValues:
> for defaultstore in self.SkuOverrideValues[sku]:
> fields = self.SkuOverrideValues[sku][defaultstore]
> diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py
> b/BaseTools/Source/Python/Workspace/DscBuildData.py
> index b485c75a84..37fb8d56b6 100644
> --- a/BaseTools/Source/Python/Workspace/DscBuildData.py
> +++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
> @@ -31,11 +31,11 @@ from .MetaDataTable import *
> from .MetaFileTable import *
> from .MetaFileParser import *
>
> from .WorkspaceCommon import GetDeclaredPcd
> from Common.Misc import AnalyzeDscPcd
> -from Common.Misc import ProcessDuplicatedInf
> +from Common.Misc import ProcessDuplicatedInf,RemoveCComments
> import re
> from Common.Parsing import IsValidWord
> from Common.VariableAttributes import VariableAttributes
> import Common.GlobalData as GlobalData
> import subprocess
> @@ -1573,11 +1573,11 @@ class DscBuildData(PlatformBuildClassObject):
> mindefaultstorename =
> DefaultStoreObj.GetMin(PcdDefaultStoreSet)
>
> str_pcd_obj.SkuInfoList[self.SkuIdMgr.SystemSkuId].HiiDefaultValue =
> str_pcd_obj.SkuInfoList[self.SkuIdMgr.SystemSkuId].DefaultStoreDict[mindefaultstorename]
>
> for str_pcd_obj in S_pcd_set.values():
>
> -str_pcd_obj.MaxDatumSize =
> self.GetStructurePcdMaxSize(str_pcd_obj)
> +str_pcd_obj.MaxDatumSize =
> DscBuildData.GetStructurePcdMaxSize(str_pcd_obj)
This static change isn't described in the commit, if you think this
isn't worth a separate commit, can you add a note about it?
> Pcds[str_pcd_obj.TokenCName,
> str_pcd_obj.TokenSpaceGuidCName] = str_pcd_obj
> Pcds[str_pcd_obj.TokenCName,
> str_pcd_obj.TokenSpaceGuidCName].CustomAttribute['IsStru']=True
>
> for pcdkey in Pcds:
> pcd = Pcds[pcdkey]
> @@ -1687,13 +1687,14 @@ class DscBuildData(PlatformBuildClassObject):
> if SkuName not in Pcds[PcdCName, TokenSpaceGuid].DscRawValue:
> Pcds[PcdCName, TokenSpaceGuid].DscRawValue[SkuName] = {}
> Pcds[PcdCName,
> TokenSpaceGuid
Re: [edk2] [PATCH] BaseTools/tools_def ARM: emit PIC veneers
On 12/12/18 1:19 PM, Ard Biesheuvel wrote: > The ARM linker may emit veneers, i.e., trampolines, when ordinary > direct relative branches cannot be used, e.g., for Thumb interworking > or branch targets that are out of range. > > Usually, such veneers carry an absolute reference to the branch > target, which is problematic for us, since these absolute references > are not covered by annotations that are visible to GenFw in the > PE/COFF conversion, and so these absolute references are not fixed > up by the PE/COFF loader at runtime. > > So switch to all ARM GNU ld toolchains to position independent veneers. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Reviewed-by: Philippe Mathieu-Daudé > --- > BaseTools/Conf/tools_def.template | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/BaseTools/Conf/tools_def.template > b/BaseTools/Conf/tools_def.template > index 2ba833e1fb06..902680c24c85 100755 > --- a/BaseTools/Conf/tools_def.template > +++ b/BaseTools/Conf/tools_def.template > @@ -4150,7 +4150,7 @@ DEFINE GCC_DLINK_FLAGS_COMMON = -nostdlib --pie > DEFINE GCC_DLINK2_FLAGS_COMMON = > -Wl,--script=$(EDK_TOOLS_PATH)/Scripts/GccBase.lds > DEFINE GCC_IA32_X64_DLINK_COMMON = DEF(GCC_DLINK_FLAGS_COMMON) > --gc-sections > DEFINE GCC_ARM_AARCH64_DLINK_COMMON= -Wl,--emit-relocs -nostdlib > -Wl,--gc-sections -u $(IMAGE_ENTRY_POINT) > -Wl,-e,$(IMAGE_ENTRY_POINT),-Map,$(DEST_DIR_DEBUG)/$(BASE_NAME).map > -DEFINE GCC_ARM_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -z > common-page-size=0x20 > +DEFINE GCC_ARM_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -z > common-page-size=0x20 -Wl,--pic-veneer > DEFINE GCC_AARCH64_DLINK_FLAGS = DEF(GCC_ARM_AARCH64_DLINK_COMMON) -z > common-page-size=0x20 > DEFINE GCC_ARM_AARCH64_ASLDLINK_FLAGS = -Wl,--defsym=PECOFF_HEADER_SIZE=0 > DEF(GCC_DLINK2_FLAGS_COMMON) -z common-page-size=0x20 > DEFINE GCC_IA32_X64_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_DLINK_COMMON) --entry > _ReferenceAcpiTable -u $(IMAGE_ENTRY_POINT) > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] BaseTools/CommonLib: drop the use of MAX_ADDRESS
On 5/12/18 9:24, Ard Biesheuvel wrote:
> The macro MAX_ADDRESS represents the largest virtual address that
> is valid for a certain architecture. For the BaseTools, this quantity
> is irrelevant, since the same tools can be used to build for different
> targets.
>
> Since we only refer to it in a single place, which is an ASSERT() that
> doesn't seem particularly useful (it ensures that memcpy() will not
> be called with arguments that will make it read beyond the end of the
> address space and wrap around), let's drop the ASSERT and all references
> to MAX_ADDRESS.
This looks to me best this way, thanks for cleaning this.
>
> Cc: Bob Feng
> Cc: Liming Gao
> Cc: Yonghong Zhu
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Philippe Mathieu-Daudé
> ---
> BaseTools/Source/C/Include/AArch64/ProcessorBind.h | 5 -
> BaseTools/Source/C/Include/Arm/ProcessorBind.h | 5 -
> BaseTools/Source/C/Include/Common/UefiBaseTypes.h | 1 -
> BaseTools/Source/C/Include/Ia32/ProcessorBind.h| 5 -
> BaseTools/Source/C/Include/X64/ProcessorBind.h | 5 -
> BaseTools/Source/C/Common/CommonLib.c | 1 -
> 6 files changed, 22 deletions(-)
>
> diff --git a/BaseTools/Source/C/Include/AArch64/ProcessorBind.h
> b/BaseTools/Source/C/Include/AArch64/ProcessorBind.h
> index e7e9d83198a6..f956cab453f0 100644
> --- a/BaseTools/Source/C/Include/AArch64/ProcessorBind.h
> +++ b/BaseTools/Source/C/Include/AArch64/ProcessorBind.h
> @@ -90,11 +90,6 @@ typedef INT64 INTN;
> ///
> #define MAX_2_BITS 0xC000
>
> -///
> -/// Maximum legal AARCH64 address
> -///
> -#define MAX_ADDRESS 0x
> -
> ///
> /// The stack alignment required for AARCH64
> ///
> diff --git a/BaseTools/Source/C/Include/Arm/ProcessorBind.h
> b/BaseTools/Source/C/Include/Arm/ProcessorBind.h
> index be4aac97664d..856d2bd9eff7 100644
> --- a/BaseTools/Source/C/Include/Arm/ProcessorBind.h
> +++ b/BaseTools/Source/C/Include/Arm/ProcessorBind.h
> @@ -88,11 +88,6 @@ typedef INT32 INTN;
> ///
> #define MAX_2_BITS 0xC000
>
> -///
> -/// Maximum legal ARM address
> -///
> -#define MAX_ADDRESS 0x
> -
> ///
> /// The stack alignment required for ARM
> ///
> diff --git a/BaseTools/Source/C/Include/Common/UefiBaseTypes.h
> b/BaseTools/Source/C/Include/Common/UefiBaseTypes.h
> index aa1aef3ce638..696ac15e4cd5 100644
> --- a/BaseTools/Source/C/Include/Common/UefiBaseTypes.h
> +++ b/BaseTools/Source/C/Include/Common/UefiBaseTypes.h
> @@ -170,6 +170,5 @@ typedef union {
>
>
> #define EFI_MAX_BIT MAX_BIT
> -#define EFI_MAX_ADDRESS MAX_ADDRESS
>
> #endif
> diff --git a/BaseTools/Source/C/Include/Ia32/ProcessorBind.h
> b/BaseTools/Source/C/Include/Ia32/ProcessorBind.h
> index 4719b53d37fa..96ac691df042 100644
> --- a/BaseTools/Source/C/Include/Ia32/ProcessorBind.h
> +++ b/BaseTools/Source/C/Include/Ia32/ProcessorBind.h
> @@ -131,11 +131,6 @@ typedef INT32 INTN;
> #define MAX_BIT 0x8000
> #define MAX_2_BITS 0xC000
>
> -//
> -// Maximum legal IA-32 address
> -//
> -#define MAX_ADDRESS 0x
> -
> //
> // Modifier to ensure that all protocol member functions and EFI intrinsics
> // use the correct C calling convention. All protocol member functions and
> diff --git a/BaseTools/Source/C/Include/X64/ProcessorBind.h
> b/BaseTools/Source/C/Include/X64/ProcessorBind.h
> index c625f8cef4a1..987738508333 100644
> --- a/BaseTools/Source/C/Include/X64/ProcessorBind.h
> +++ b/BaseTools/Source/C/Include/X64/ProcessorBind.h
> @@ -150,11 +150,6 @@ typedef INT64 INTN;
> #define MAX_BIT 0x8000ULL
> #define MAX_2_BITS 0xC000ULL
>
> -//
> -// Maximum legal Itanium-based address
> -//
> -#define MAX_ADDRESS 0xULL
> -
> //
> // Modifier to ensure that all protocol member functions and EFI intrinsics
> // use the correct C calling convention. All protocol member functions and
> diff --git a/BaseTools/Source/C/Common/CommonLib.c
> b/BaseTools/Source/C/Common/CommonLib.c
> index 42dfa821624d..5c40fdb5fd49 100644
> --- a/BaseTools/Source/C/Common/CommonLib.c
> +++ b/BaseTools/Source/C/Common/CommonLib.c
> @@ -1236,7 +1236,6 @@ InternalAllocateCopyPool (
>VOID *Memory;
>
>ASSERT (Buffer != NULL);
> - ASSERT (AllocationSize <= (MAX_ADDRESS - (UINTN) Buffer + 1));
>
>Memory = malloc (AllocationSize);
>if (Memory != NULL) {
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce] Research Request
Hi Stephano, On 14/11/18 19:34, stephano wrote: > We are currently researching several different options to help make > contributing to TianoCore easier for the community. A big part of this > effort will be enabling pull requests and allowing for a more > customizable code review process. > > I am looking for members of the community willing to answer a few > questions about these solutions to allow us to evaluate our options > quickly. The options are: > > System/Tool Investigator > Phabricator Rebecca Cran (thank you again :) ) > Github ??? > Gerrit ??? > Gitlab ??? > > I have a list of questions that I can send out to each investigator. > Assuming you are familiar with the software/system, these questions > should be answerable with a couple hours of research, writing, and > screenshots / examples. I'll run your checklist [*] with GitLab on Thursday. [*] https://lists.01.org/pipermail/edk2-devel/2018-November/032462.html > > Thanks in advance for your help! > > -Stephano > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 1/4] ArmPkg/ArmMmuLib ARM: handle unmapped section in GetMemoryRegion()
On 30/11/18 12:28, Ard Biesheuvel wrote:
> GetMemoryRegion() is used to obtain the attributes of an existing
> mapping, to permit permission attribute changes to be optimized
> away if the attributes don't actually change.
>
> The current ARM code assumes that a section mapping or a page mapping
> exists for any region passed into GetMemoryRegion(), but the region
> may be unmapped entirely, in which case the code will crash. So check
> if a section mapping exists before dereferencing it.
Good catch!
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Philippe Mathieu-Daudé
> ---
> ArmPkg/Drivers/CpuDxe/Arm/Mmu.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c b/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
> index 12ca5b26673e..3b29d33d0a9c 100644
> --- a/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
> +++ b/ArmPkg/Drivers/CpuDxe/Arm/Mmu.c
> @@ -457,6 +457,9 @@ GetMemoryRegion (
>
>// Get the section at the given index
>SectionDescriptor = FirstLevelTable[TableIndex];
> + if (!SectionDescriptor) {
> +return EFI_NOT_FOUND;
> + }
>
>// If 'BaseAddress' belongs to the section then round it to the section
> boundary
>if (((SectionDescriptor & TT_DESCRIPTOR_SECTION_TYPE_MASK) ==
> TT_DESCRIPTOR_SECTION_TYPE_SECTION) ||
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 6/6] BaseTools/CommonLib: drop definition of MAX_UINTN
On 30/11/18 23:45, Ard Biesheuvel wrote: > The maximum value that can be represented by the native word size > of the *target* should be irrelevant when compiling tools that > run on the build *host*. So drop the definition of MAX_UINTN, now > that we no longer use it. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > Reviewed-by: Jaben Carsey Reviewed-by: Philippe Mathieu-Daudé > --- > BaseTools/Source/C/Common/CommonLib.h | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/BaseTools/Source/C/Common/CommonLib.h > b/BaseTools/Source/C/Common/CommonLib.h > index 6930d9227b87..b1c6c00a3478 100644 > --- a/BaseTools/Source/C/Common/CommonLib.h > +++ b/BaseTools/Source/C/Common/CommonLib.h > @@ -22,7 +22,6 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER > EXPRESS OR IMPLIED. > > #define MAX_LONG_FILE_PATH 500 > > -#define MAX_UINTN MAX_ADDRESS > #define MAX_UINT64 ((UINT64)0xULL) > #define MAX_UINT16 ((UINT16)0x) > #define MAX_UINT8 ((UINT8)0xFF) > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 5/6] BaseTools/CommonLib: get rid of 'native' type string parsing routines
On 30/11/18 23:45, Ard Biesheuvel wrote:
> Parsing a string into an integer variable of the native word size
> is not defined for the BaseTools, since the same tools may be used
> to build firmware for different targets with different native word
> sizes.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Philippe Mathieu-Daudé
> ---
> BaseTools/Source/C/Common/CommonLib.h | 24 ---
> BaseTools/Source/C/Common/CommonLib.c | 174 +---
> 2 files changed, 5 insertions(+), 193 deletions(-)
>
> diff --git a/BaseTools/Source/C/Common/CommonLib.h
> b/BaseTools/Source/C/Common/CommonLib.h
> index fa10fac4682a..6930d9227b87 100644
> --- a/BaseTools/Source/C/Common/CommonLib.h
> +++ b/BaseTools/Source/C/Common/CommonLib.h
> @@ -250,16 +250,6 @@ StrSize (
>CONST CHAR16 *String
>);
>
> -UINTN
> -StrHexToUintn (
> - CONST CHAR16 *String
> - );
> -
> -UINTN
> -StrDecimalToUintn (
> - CONST CHAR16 *String
> - );
> -
> UINT64
> StrHexToUint64 (
>CONST CHAR16 *String
> @@ -277,13 +267,6 @@ StrHexToUint64S (
> UINT64 *Data
>);
>
> -RETURN_STATUS
> -StrHexToUintnS (
> -CONST CHAR16 *String,
> - CHAR16 **EndPointer, OPTIONAL
> - UINTN *Data
> - );
> -
> RETURN_STATUS
> StrDecimalToUint64S (
> CONST CHAR16 *String,
> @@ -291,13 +274,6 @@ StrDecimalToUint64S (
> UINT64 *Data
>);
>
> -RETURN_STATUS
> -StrDecimalToUintnS (
> -CONST CHAR16 *String,
> - CHAR16 **EndPointer, OPTIONAL
> - UINTN *Data
> - );
> -
> VOID *
> ReallocatePool (
> UINTN OldSize,
> diff --git a/BaseTools/Source/C/Common/CommonLib.c
> b/BaseTools/Source/C/Common/CommonLib.c
> index 4a28f635f3a8..42dfa821624d 100644
> --- a/BaseTools/Source/C/Common/CommonLib.c
> +++ b/BaseTools/Source/C/Common/CommonLib.c
> @@ -882,72 +882,6 @@ InternalSafeStringNoStrOverlap (
>return !InternalSafeStringIsOverlap (Str1, Size1 * sizeof(CHAR16), Str2,
> Size2 * sizeof(CHAR16));
> }
>
> -RETURN_STATUS
> -StrDecimalToUintnS (
> -CONST CHAR16 *String,
> - CHAR16 **EndPointer, OPTIONAL
> - UINTN *Data
> - )
> -{
> - ASSERT (((UINTN) String & BIT0) == 0);
> -
> - //
> - // 1. Neither String nor Data shall be a null pointer.
> - //
> - SAFE_STRING_CONSTRAINT_CHECK ((String != NULL), RETURN_INVALID_PARAMETER);
> - SAFE_STRING_CONSTRAINT_CHECK ((Data != NULL), RETURN_INVALID_PARAMETER);
> -
> - //
> - // 2. The length of String shall not be greater than RSIZE_MAX.
> - //
> - if (RSIZE_MAX != 0) {
> -SAFE_STRING_CONSTRAINT_CHECK ((StrnLenS (String, RSIZE_MAX + 1) <=
> RSIZE_MAX), RETURN_INVALID_PARAMETER);
> - }
> -
> - if (EndPointer != NULL) {
> -*EndPointer = (CHAR16 *) String;
> - }
> -
> - //
> - // Ignore the pad spaces (space or tab)
> - //
> - while ((*String == L' ') || (*String == L'\t')) {
> -String++;
> - }
> -
> - //
> - // Ignore leading Zeros after the spaces
> - //
> - while (*String == L'0') {
> -String++;
> - }
> -
> - *Data = 0;
> -
> - while (InternalIsDecimalDigitCharacter (*String)) {
> -//
> -// If the number represented by String overflows according to the range
> -// defined by UINTN, then MAX_UINTN is stored in *Data and
> -// RETURN_UNSUPPORTED is returned.
> -//
> -if (*Data > ((MAX_UINTN - (*String - L'0')) / 10)) {
> - *Data = MAX_UINTN;
> - if (EndPointer != NULL) {
> -*EndPointer = (CHAR16 *) String;
> - }
> - return RETURN_UNSUPPORTED;
> -}
> -
> -*Data = *Data * 10 + (*String - L'0');
> -String++;
> - }
> -
> - if (EndPointer != NULL) {
> -*EndPointer = (CHAR16 *) String;
> - }
> - return RETURN_SUCCESS;
> -}
> -
> /**
>Convert a Null-terminated Unicode decimal string to a value of type UINT64.
>
> @@ -1064,9 +998,9 @@ StrDecimalToUint64S (
>
> /**
>Convert a Null-terminated Unicode hexadecimal string to a value of type
> - UINTN.
> + UINT64.
>
> - This function outputs a value of type UINTN by interpreting the contents of
> + This function outputs a value of type UINT64 by interpreting the contents
> of
>the Unicode string specified by String as a hexadecimal number. The format
> of
>
Re: [edk2] [PATCH v2 2/6] BaseTools/CommonLib: use explicit 64-bit type in Strtoi()
On 30/11/18 23:45, Ard Biesheuvel wrote:
> Don't use the native word size string to number parsing routines,
> but instead, use the 64-bit one and cast to UINTN.
>
> Currently, the only user is in Source/C/DevicePath/DevicePathFromText.c
> which takes care to use Strtoi64 () unless it assumes the value fits
> in 32-bit, so this change is a no-op even on 32-bit build hosts.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> Reviewed-by: Jaben Carsey
Reviewed-by: Philippe Mathieu-Daudé
> ---
> BaseTools/Source/C/Common/CommonLib.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/BaseTools/Source/C/Common/CommonLib.c
> b/BaseTools/Source/C/Common/CommonLib.c
> index 7c559bc3c222..4a28f635f3a8 100644
> --- a/BaseTools/Source/C/Common/CommonLib.c
> +++ b/BaseTools/Source/C/Common/CommonLib.c
> @@ -2252,9 +2252,9 @@ Strtoi (
>)
> {
>if (IsHexStr (Str)) {
> -return StrHexToUintn (Str);
> +return (UINTN)StrHexToUint64 (Str);
>} else {
> -return StrDecimalToUintn (Str);
> +return (UINTN)StrDecimalToUint64 (Str);
>}
> }
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 3/6] BaseTools/DevicePath: use explicit 64-bit number parsing routines
On 30/11/18 23:45, Ard Biesheuvel wrote:
> Replace invocations of StrHexToUintn() with StrHexToUint64(), so
> that we can drop the former.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> Reviewed-by: Jaben Carsey
Reviewed-by: Philippe Mathieu-Daudé
> ---
> BaseTools/Source/C/DevicePath/DevicePathFromText.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/BaseTools/Source/C/DevicePath/DevicePathFromText.c
> b/BaseTools/Source/C/DevicePath/DevicePathFromText.c
> index 555efa1acdde..6151926af9aa 100644
> --- a/BaseTools/Source/C/DevicePath/DevicePathFromText.c
> +++ b/BaseTools/Source/C/DevicePath/DevicePathFromText.c
> @@ -520,7 +520,7 @@ EisaIdFromText (
>return (((Text[0] - 'A' + 1) & 0x1f) << 10)
> + (((Text[1] - 'A' + 1) & 0x1f) << 5)
> + (((Text[2] - 'A' + 1) & 0x1f) << 0)
> - + (UINT32) (StrHexToUintn (&Text[3]) << 16)
> + + (UINT32) (StrHexToUint64 (&Text[3]) << 16)
> ;
> }
>
> @@ -1506,7 +1506,7 @@ DevPathFromTextNVMe (
>
>Index = sizeof (Nvme->NamespaceUuid) / sizeof (UINT8);
>while (Index-- != 0) {
> -Uuid[Index] = (UINT8) StrHexToUintn (SplitStr (&NamespaceUuidStr, L'-'));
> +Uuid[Index] = (UINT8) StrHexToUint64 (SplitStr (&NamespaceUuidStr,
> L'-'));
>}
>
>return (EFI_DEVICE_PATH_PROTOCOL *) Nvme;
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 1/6] BaseTools/CommonLib: avoid using 'native' word size in IP address handling
On 30/11/18 23:45, Ard Biesheuvel wrote:
> In the context of the BaseTools, there is no such thing as a native word
> size, given that the same set of tools may be used to build a firmware
> image consisting of both 32-bit and 64-bit modules.
>
> So update StrToIpv4Address() and StrToIpv6Address() to use UINT64
> types instead of UINTN types when parsing strings.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Philippe Mathieu-Daudé
> ---
> BaseTools/Source/C/Common/CommonLib.c | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/BaseTools/Source/C/Common/CommonLib.c
> b/BaseTools/Source/C/Common/CommonLib.c
> index 618aadac781a..7c559bc3c222 100644
> --- a/BaseTools/Source/C/Common/CommonLib.c
> +++ b/BaseTools/Source/C/Common/CommonLib.c
> @@ -1785,7 +1785,7 @@ StrToIpv4Address (
> {
>RETURN_STATUS Status;
>UINTN AddressIndex;
> - UINTN Uintn;
> + UINT64 Uint64;
>EFI_IPv4_ADDRESS LocalAddress;
>UINT8 LocalPrefixLength;
>CHAR16 *Pointer;
> @@ -1812,7 +1812,7 @@ StrToIpv4Address (
> //
> // Get D or P.
> //
> -Status = StrDecimalToUintnS ((CONST CHAR16 *) Pointer, &Pointer, &Uintn);
> +Status = StrDecimalToUint64S ((CONST CHAR16 *) Pointer, &Pointer,
> &Uint64);
> if (RETURN_ERROR (Status)) {
>return RETURN_UNSUPPORTED;
> }
> @@ -1820,18 +1820,18 @@ StrToIpv4Address (
>//
>// It's P.
>//
> - if (Uintn > 32) {
> + if (Uint64 > 32) {
> return RETURN_UNSUPPORTED;
>}
> - LocalPrefixLength = (UINT8) Uintn;
> + LocalPrefixLength = (UINT8) Uint64;
> } else {
>//
>// It's D.
>//
> - if (Uintn > MAX_UINT8) {
> + if (Uint64 > MAX_UINT8) {
> return RETURN_UNSUPPORTED;
>}
> - LocalAddress.Addr[AddressIndex] = (UINT8) Uintn;
> + LocalAddress.Addr[AddressIndex] = (UINT8) Uint64;
>AddressIndex++;
> }
>
> @@ -1888,7 +1888,7 @@ StrToIpv6Address (
> {
>RETURN_STATUS Status;
>UINTN AddressIndex;
> - UINTN Uintn;
> + UINT64 Uint64;
>EFI_IPv6_ADDRESS LocalAddress;
>UINT8 LocalPrefixLength;
>CONST CHAR16 *Pointer;
> @@ -1969,7 +1969,7 @@ StrToIpv6Address (
> //
> // Get X.
> //
> -Status = StrHexToUintnS (Pointer, &End, &Uintn);
> +Status = StrHexToUint64S (Pointer, &End, &Uint64);
> if (RETURN_ERROR (Status) || End - Pointer > 4) {
>//
>// Number of hexadecimal digit characters is no more than 4.
> @@ -1978,24 +1978,24 @@ StrToIpv6Address (
> }
> Pointer = End;
> //
> -// Uintn won't exceed MAX_UINT16 if number of hexadecimal digit
> characters is no more than 4.
> +// Uint64 won't exceed MAX_UINT16 if number of hexadecimal digit
> characters is no more than 4.
> //
> ASSERT (AddressIndex + 1 < ARRAY_SIZE (Address->Addr));
> -LocalAddress.Addr[AddressIndex] = (UINT8) ((UINT16) Uintn >> 8);
> -LocalAddress.Addr[AddressIndex + 1] = (UINT8) Uintn;
> +LocalAddress.Addr[AddressIndex] = (UINT8) ((UINT16) Uint64 >> 8);
> +LocalAddress.Addr[AddressIndex + 1] = (UINT8) Uint64;
> AddressIndex += 2;
>} else {
> //
> // Get P, then exit the loop.
> //
> -Status = StrDecimalToUintnS (Pointer, &End, &Uintn);
> -if (RETURN_ERROR (Status) || End == Pointer || Uintn > 128) {
> +Status = StrDecimalToUint64S (Pointer, &End, &Uint64);
> +if (RETURN_ERROR (Status) || End == Pointer || Uint64 > 128) {
>//
>// Prefix length should not exceed 128.
>//
>return RETURN_UNSUPPORTED;
> }
> -LocalPrefixLength = (UINT8) Uintn;
> +LocalPrefixLength = (UINT8) Uint64;
> Pointer = End;
> break;
>}
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch v2] Maintainers.txt: Add the rule to hand over the package maintain role
Hi, On 28/11/18 15:03, Liming Gao wrote: > In V2, change his to the, and add new maintainers follow up. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Liming Gao > --- > Maintainers.txt | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/Maintainers.txt b/Maintainers.txt > index 91a4657adc..e102114c34 100644 > --- a/Maintainers.txt > +++ b/Maintainers.txt > @@ -6,7 +6,10 @@ EDK II. > > In general, you should not privately email the maintainer. You should > email the edk2-devel list, and Cc the package maintainers and > -reviewers. > +reviewers. If the package maintainer wants to hand over the role to I'd move this to another paragraph, the first one is directed to contributors, the second one would be to maintainers. > +other people, the package maintainer should send the patch to update > +Maintainers.txt with new maintainer, and the new maintainer should > +follow up with an Acked-by or a Reviewed-by. I noticed an extra space at the end of the lines you added, which resulted in the following errors when applying: Applying: Maintainers.txt: Add the rule to hand over the package maintain role .git/rebase-apply/patch:14: trailing whitespace. reviewers. If the package maintainer wants to hand over the role to .git/rebase-apply/patch:15: trailing whitespace. other people, the package maintainer should send the patch to update .git/rebase-apply/patch:16: trailing whitespace. Maintainers.txt with new maintainer, and the new maintainer should error: patch failed: Maintainers.txt:6 error: Maintainers.txt: patch does not apply Thanks for adding the maintainership handover clarification, I appreciate :) With space fixed (same or another paragraphs): Reviewed-by: Philippe Mathieu-Daudé > > Descriptions of section entries: > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 04/16] ArmVirtPkg/QemuVirtMemInfoLib: remove 1:1 mapping of top of PA range
On 28/11/18 15:33, Ard Biesheuvel wrote:
> Currently, we map DRAM as EFI_MEMORY_WB, and the remainder of the
> entire virtual address space is mapped with EFI_MEMORY_UC attributes,
> regardless of whether any devices actually reside there.
>
> Now that we are relaxing the address space limit to more than 40 bits,
> mapping all that address space actually takes up more space in page
> tables than we have so far made available as temporary RAM. So let's
> get rid of the mapping rather than increasing the available RAM, given
> that the mapping is not particularly useful anyway.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Philippe Mathieu-Daudé
> ---
> ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf| 7
> ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf | 7
> ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c | 25
> +++--
> ArmVirtPkg/Library/QemuVirtMemInfoLib/AArch64/PhysAddrTop.S | 39
>
> ArmVirtPkg/Library/QemuVirtMemInfoLib/Arm/PhysAddrTop.S | 24
>
> 5 files changed, 5 insertions(+), 97 deletions(-)
>
> diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf
> b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf
> index c72a97f9e78a..5c5b841051ad 100644
> --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf
> +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.inf
> @@ -24,12 +24,6 @@ [Defines]
> [Sources]
>QemuVirtMemInfoLib.c
>
> -[Sources.ARM]
> - Arm/PhysAddrTop.S
> -
> -[Sources.AARCH64]
> - AArch64/PhysAddrTop.S
> -
> [Packages]
>ArmPkg/ArmPkg.dec
>ArmVirtPkg/ArmVirtPkg.dec
> @@ -51,4 +45,3 @@ [Pcd]
>
> [FixedPcd]
>gArmTokenSpaceGuid.PcdFdSize
> - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize
> diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
> b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
> index e4032d3efb53..d12089760b22 100644
> --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
> +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoPeiLib.inf
> @@ -26,12 +26,6 @@ [Sources]
>QemuVirtMemInfoLib.c
>QemuVirtMemInfoPeiLibConstructor.c
>
> -[Sources.ARM]
> - Arm/PhysAddrTop.S
> -
> -[Sources.AARCH64]
> - AArch64/PhysAddrTop.S
> -
> [Packages]
>ArmPkg/ArmPkg.dec
>ArmVirtPkg/ArmVirtPkg.dec
> @@ -55,4 +49,3 @@ [Pcd]
> [FixedPcd]
>gArmTokenSpaceGuid.PcdFdSize
>gArmVirtTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress
> - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize
> diff --git a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> index 760bcc169cf4..0285a11b1d77 100644
> --- a/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> +++ b/ArmVirtPkg/Library/QemuVirtMemInfoLib/QemuVirtMemInfoLib.c
> @@ -21,11 +21,6 @@
> // Number of Virtual Memory Map Descriptors
> #define MAX_VIRTUAL_MEMORY_MAP_DESCRIPTORS 5
>
> -EFI_PHYSICAL_ADDRESS
> -ArmGetPhysAddrTop (
> - VOID
> - );
> -
> /**
>Return the Virtual Memory Map of your platform
>
> @@ -45,7 +40,6 @@ ArmVirtGetMemoryMap (
>)
> {
>ARM_MEMORY_REGION_DESCRIPTOR *VirtualMemoryTable;
> - UINT64TopOfMemory;
>
>ASSERT (VirtualMemoryMap != NULL);
>
> @@ -78,23 +72,14 @@ ArmVirtGetMemoryMap (
>VirtualMemoryTable[1].Length = VirtualMemoryTable[0].PhysicalBase;
>VirtualMemoryTable[1].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
>
> - // Peripheral space after DRAM
> - TopOfMemory = MIN (1ULL << FixedPcdGet8 (PcdPrePiCpuMemorySize),
> - ArmGetPhysAddrTop ());
> - VirtualMemoryTable[2].PhysicalBase = VirtualMemoryTable[0].Length +
> VirtualMemoryTable[1].Length;
> - VirtualMemoryTable[2].VirtualBase = VirtualMemoryTable[2].PhysicalBase;
> - VirtualMemoryTable[2].Length = TopOfMemory -
> - VirtualMemoryTable[2].PhysicalBase;
> - VirtualMemoryTable[2].Attributes = ARM_MEMORY_REGION_ATTRIBUTE_DEVICE;
> -
>// Remap the FD region as normal executable memory
> - VirtualMemoryTable[3].PhysicalBase = PcdGet64 (PcdFdBaseAddress);
> - VirtualMemoryTable[3].VirtualBase = VirtualMemoryTable[3].PhysicalBase;
> - VirtualMemoryTable[3].Length = FixedPcdGet32 (PcdFdSize);
> - VirtualMemoryTable[3].Attributes =
> ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
> + VirtualMemoryTable[2].PhysicalBase = PcdGet64 (PcdFdBaseA
Re: [edk2] [PATCH v3 11/16] ArmVirtPkg/PrePi: base GCD memory space size on CPU's PA range
On 28/11/18 15:33, Ard Biesheuvel wrote: > Derive the size of the GCD memory space map directly from the CPU's > information registers rather than from the PcdPrePiCpuMemorySize PCD, > which will be removed. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Reviewed-by: Philippe Mathieu-Daudé > --- > ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf | 1 - > ArmVirtPkg/PrePi/PrePi.c| 2 +- > 2 files changed, 1 insertion(+), 2 deletions(-) > > diff --git a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf > b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf > index 1587bd92f206..034ddb41cb48 100755 > --- a/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf > +++ b/ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf > @@ -85,7 +85,6 @@ [FixedPcd] > >gArmPlatformTokenSpaceGuid.PcdCoreCount > > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize > >gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory > diff --git a/ArmVirtPkg/PrePi/PrePi.c b/ArmVirtPkg/PrePi/PrePi.c > index f6abe2f2016b..61de6cfd4ae6 100755 > --- a/ArmVirtPkg/PrePi/PrePi.c > +++ b/ArmVirtPkg/PrePi/PrePi.c > @@ -80,7 +80,7 @@ PrePiMain ( >BuildStackHob (StacksBase, StacksSize); > >//TODO: Call CpuPei as a library > - BuildCpuHob (PcdGet8 (PcdPrePiCpuMemorySize), PcdGet8 (PcdPrePiCpuIoSize)); > + BuildCpuHob (ArmGetPhysicalAddressBits (), PcdGet8 (PcdPrePiCpuIoSize)); > >// Set the Boot Mode >SetBootMode (BOOT_WITH_FULL_CONFIGURATION); > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 10/16] ArmPlatformPkg/PrePi: base GCD memory space size on CPU's PA range
On 28/11/18 15:33, Ard Biesheuvel wrote:
> Derive the size of the GCD memory space map directly from the CPU's
> information registers rather than from the PcdPrePiCpuMemorySize PCD,
> which will be removed.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Philippe Mathieu-Daudé
> ---
> ArmPlatformPkg/PrePi/PeiMPCore.inf | 1 -
> ArmPlatformPkg/PrePi/PeiUniCore.inf | 1 -
> ArmPlatformPkg/PrePi/PrePi.c| 2 +-
> 3 files changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/ArmPlatformPkg/PrePi/PeiMPCore.inf
> b/ArmPlatformPkg/PrePi/PeiMPCore.inf
> index 242b03175536..7e2ad6fc483d 100644
> --- a/ArmPlatformPkg/PrePi/PeiMPCore.inf
> +++ b/ArmPlatformPkg/PrePi/PeiMPCore.inf
> @@ -97,7 +97,6 @@ [FixedPcd]
>
>gArmPlatformTokenSpaceGuid.PcdCoreCount
>
> - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize
>gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize
>
>gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory
> diff --git a/ArmPlatformPkg/PrePi/PeiUniCore.inf
> b/ArmPlatformPkg/PrePi/PeiUniCore.inf
> index a45cdef4ed91..26328b7e8f67 100644
> --- a/ArmPlatformPkg/PrePi/PeiUniCore.inf
> +++ b/ArmPlatformPkg/PrePi/PeiUniCore.inf
> @@ -90,7 +90,6 @@ [FixedPcd]
>
>gArmPlatformTokenSpaceGuid.PcdCoreCount
>
> - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize
>gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize
>
>gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory
> diff --git a/ArmPlatformPkg/PrePi/PrePi.c b/ArmPlatformPkg/PrePi/PrePi.c
> index 02cff7ddc204..245bdded1eb3 100644
> --- a/ArmPlatformPkg/PrePi/PrePi.c
> +++ b/ArmPlatformPkg/PrePi/PrePi.c
> @@ -115,7 +115,7 @@ PrePiMain (
>BuildStackHob (StacksBase, StacksSize);
>
>//TODO: Call CpuPei as a library
> - BuildCpuHob (PcdGet8 (PcdPrePiCpuMemorySize), PcdGet8 (PcdPrePiCpuIoSize));
> + BuildCpuHob (ArmGetPhysicalAddressBits (), PcdGet8 (PcdPrePiCpuIoSize));
>
>if (ArmIsMpCore ()) {
> // Only MP Core platform need to produce gArmMpCoreInfoPpiGuid
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 12/16] BeagleBoardPkg/PrePi: base GCD memory space size on CPU's PA range
On 28/11/18 15:33, Ard Biesheuvel wrote: > Derive the size of the GCD memory space map directly from the CPU's > information registers rather than from the PcdPrePiCpuMemorySize PCD, > which will be removed. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Reviewed-by: Philippe Mathieu-Daudé > --- > BeagleBoardPkg/PrePi/PeiUniCore.inf | 1 - > BeagleBoardPkg/PrePi/PrePi.c| 2 +- > 2 files changed, 1 insertion(+), 2 deletions(-) > > diff --git a/BeagleBoardPkg/PrePi/PeiUniCore.inf > b/BeagleBoardPkg/PrePi/PeiUniCore.inf > index 3d72bc5b46e1..53c71d8eafc2 100644 > --- a/BeagleBoardPkg/PrePi/PeiUniCore.inf > +++ b/BeagleBoardPkg/PrePi/PeiUniCore.inf > @@ -86,7 +86,6 @@ [FixedPcd] > >gArmPlatformTokenSpaceGuid.PcdCoreCount > > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize > >gEmbeddedTokenSpaceGuid.PcdMemoryTypeEfiACPIReclaimMemory > diff --git a/BeagleBoardPkg/PrePi/PrePi.c b/BeagleBoardPkg/PrePi/PrePi.c > index 46f63f40c46e..bc9b0c80b84c 100644 > --- a/BeagleBoardPkg/PrePi/PrePi.c > +++ b/BeagleBoardPkg/PrePi/PrePi.c > @@ -110,7 +110,7 @@ PrePiMain ( >BuildStackHob (StacksBase, StacksSize); > >//TODO: Call CpuPei as a library > - BuildCpuHob (PcdGet8 (PcdPrePiCpuMemorySize), PcdGet8 (PcdPrePiCpuIoSize)); > + BuildCpuHob (ArmGetPhysicalAddressBits (), PcdGet8 (PcdPrePiCpuIoSize)); > >// Store timer value logged at the beginning of firmware image execution >Performance.ResetEnd = GetTimeInNanoSecond (StartTimeStamp); > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 09/16] ArmPkg/CpuPei: base GCD memory space size on CPU's PA range
On 28/11/18 15:33, Ard Biesheuvel wrote: > Derive the size of the GCD memory space map directly from the CPU's > information registers rather than from the PcdPrePiCpuMemorySize PCD, > which will be removed. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > ArmPkg/Drivers/CpuPei/CpuPei.inf | 1 - > ArmPkg/Drivers/CpuPei/CpuPei.c | 2 +- > 2 files changed, 1 insertion(+), 2 deletions(-) > > diff --git a/ArmPkg/Drivers/CpuPei/CpuPei.inf > b/ArmPkg/Drivers/CpuPei/CpuPei.inf > index eafccd600983..dcea012fd8f9 100644 > --- a/ArmPkg/Drivers/CpuPei/CpuPei.inf > +++ b/ArmPkg/Drivers/CpuPei/CpuPei.inf > @@ -50,7 +50,6 @@ [Guids] >gArmMpCoreInfoGuid > > [FixedPcd] > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize >gEmbeddedTokenSpaceGuid.PcdPrePiCpuIoSize > > [Depex] > diff --git a/ArmPkg/Drivers/CpuPei/CpuPei.c b/ArmPkg/Drivers/CpuPei/CpuPei.c > index d54f42acfcc8..e63519ff6481 100644 > --- a/ArmPkg/Drivers/CpuPei/CpuPei.c > +++ b/ArmPkg/Drivers/CpuPei/CpuPei.c > @@ -73,7 +73,7 @@ InitializeCpuPeim ( >ArmEnableBranchPrediction (); > >// Publish the CPU memory and io spaces sizes This comment is misleading, maybe 'sizes' -> 'addressable bits'? (not related to this series) > - BuildCpuHob (PcdGet8 (PcdPrePiCpuMemorySize), PcdGet8 (PcdPrePiCpuIoSize)); > + BuildCpuHob (ArmGetPhysicalAddressBits (), PcdGet8 (PcdPrePiCpuIoSize)); Reviewed-by: Philippe Mathieu-Daudé > >// Only MP Core platform need to produce gArmMpCoreInfoPpiGuid >Status = PeiServicesLocatePpi (&gArmMpCoreInfoPpiGuid, 0, NULL, > (VOID**)&ArmMpCoreInfoPpi); > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 08/16] ArmPkg/ArmMmuLib: take the CPU supported maximum PA space into account
On 28/11/18 15:33, Ard Biesheuvel wrote: > In preparation of dropping PcdPrePiCpuMemorySize entirely, base the > maximum size of the identity map on the capabilities of the CPU. > Since that may exceed what is architecturally permitted when using > 4 KB pages, take MAX_ADDRESS into account as well. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Reviewed-by: Philippe Mathieu-Daudé > --- > ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf | 3 --- > ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf| 3 --- > ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c | 11 +-- > 3 files changed, 9 insertions(+), 8 deletions(-) > > diff --git a/ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf > b/ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf > index b9f264de8d26..246963361e45 100644 > --- a/ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf > +++ b/ArmPkg/Library/ArmMmuLib/ArmMmuBaseLib.inf > @@ -40,8 +40,5 @@ [LibraryClasses] >CacheMaintenanceLib >MemoryAllocationLib > > -[Pcd.AARCH64] > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize > - > [Pcd.ARM] >gArmTokenSpaceGuid.PcdNormalMemoryNonshareableOverride > diff --git a/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf > b/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf > index ecf13f790734..f689c193b862 100644 > --- a/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf > +++ b/ArmPkg/Library/ArmMmuLib/ArmMmuPeiLib.inf > @@ -35,6 +35,3 @@ [LibraryClasses] >ArmLib >CacheMaintenanceLib >MemoryAllocationLib > - > -[Pcd.AARCH64] > - gEmbeddedTokenSpaceGuid.PcdPrePiCpuMemorySize > diff --git a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c > b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c > index 4b62ecb6a476..5403b8d4070e 100644 > --- a/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c > +++ b/ArmPkg/Library/ArmMmuLib/AArch64/ArmMmuLibCore.c > @@ -604,8 +604,15 @@ ArmConfigureMmu ( > return EFI_INVALID_PARAMETER; >} > > - // Cover the entire GCD memory space > - MaxAddress = (1UL << PcdGet8 (PcdPrePiCpuMemorySize)) - 1; > + // > + // Limit the virtual address space to what we can actually use: UEFI > + // mandates a 1:1 mapping, so no point in making the virtual address > + // space larger than the physical address space. We also have to take > + // into account the architectural limitations that result from UEFI's > + // use of 4 KB pages. > + // > + MaxAddress = MIN (LShiftU64 (1ULL, ArmGetPhysicalAddressBits ()) - 1, > +MAX_ADDRESS); > >// Lookup the Table Level to get the information >LookupAddresstoRootTable (MaxAddress, &T0SZ, &RootTableEntryCount); > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v3 07/16] ArmVirtPkg/XenVirtMemInfoLib: refactor reading of the PA space size
On 28/11/18 15:33, Ard Biesheuvel wrote:
> Use the new ArmLib helper to read the CPU's physical address limit
> so we can drop our own homecooked one.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf | 6 ---
> ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c | 11 +++---
> ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S | 39
>
> ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S | 24 ----
Good diffstat :)
Reviewed-by: Philippe Mathieu-Daudé
> 4 files changed, 5 insertions(+), 75 deletions(-)
>
> diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf
> b/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf
> index cd4c805a4db9..ae107810e927 100644
> --- a/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf
> +++ b/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.inf
> @@ -24,12 +24,6 @@ [Defines]
> [Sources]
>XenVirtMemInfoLib.c
>
> -[Sources.ARM]
> - Arm/PhysAddrTop.S
> -
> -[Sources.AARCH64]
> - AArch64/PhysAddrTop.S
> -
> [Packages]
>ArmPkg/ArmPkg.dec
>ArmVirtPkg/ArmVirtPkg.dec
> diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c
> b/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c
> index 88ff3167cbfd..6701dec50ea8 100644
> --- a/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c
> +++ b/ArmVirtPkg/Library/XenVirtMemInfoLib/XenVirtMemInfoLib.c
> @@ -18,11 +18,6 @@
>
> STATIC ARM_MEMORY_REGION_DESCRIPTOR mVirtualMemoryTable[2];
>
> -EFI_PHYSICAL_ADDRESS
> -ArmGetPhysAddrTop (
> - VOID
> - );
> -
> /**
>Return the Virtual Memory Map of your platform
>
> @@ -42,8 +37,12 @@ ArmVirtGetMemoryMap (
>OUT ARM_MEMORY_REGION_DESCRIPTOR **VirtualMemoryMap
>)
> {
> + EFI_PHYSICAL_ADDRESS TopOfAddressSpace;
> +
>ASSERT (VirtualMemoryMap != NULL);
>
> + TopOfAddressSpace = LShiftU64 (1ULL, ArmGetPhysicalAddressBits ());
> +
>//
>// Map the entire physical memory space as cached. The only device
>// we care about is the GIC, which will be stage 2 mapped as a device
> @@ -51,7 +50,7 @@ ArmVirtGetMemoryMap (
>//
>mVirtualMemoryTable[0].PhysicalBase = 0x0;
>mVirtualMemoryTable[0].VirtualBase = 0x0;
> - mVirtualMemoryTable[0].Length = ArmGetPhysAddrTop ();
> + mVirtualMemoryTable[0].Length = TopOfAddressSpace;
>mVirtualMemoryTable[0].Attributes =
> ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK;
>
>mVirtualMemoryTable[1].PhysicalBase = 0x0;
> diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S
> b/ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S
> deleted file mode 100644
> index a1f6a194d59b..
> --- a/ArmVirtPkg/Library/XenVirtMemInfoLib/AArch64/PhysAddrTop.S
> +++ /dev/null
> @@ -1,39 +0,0 @@
> -#
> -# Copyright (c) 2011-2013, ARM Limited. All rights reserved.
> -# Copyright (c) 2016-2017, Linaro 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
> -
> -//EFI_PHYSICAL_ADDRESS
> -//GetPhysAddrTop (
> -// VOID
> -// );
> -ASM_FUNC(ArmGetPhysAddrTop)
> - mrs x0, id_aa64mmfr0_el1
> - adr x1, .LPARanges
> - and x0, x0, #7
> - ldrb w1, [x1, x0]
> - mov x0, #1
> - lsl x0, x0, x1
> - ret
> -
> -//
> -// Bits 0..2 of the AA64MFR0_EL1 system register encode the size of the
> -// physical address space support on this CPU:
> -// 0 == 32 bits, 1 == 36 bits, etc etc
> -// 6 and 7 are reserved
> -//
> -.LPARanges:
> - .byte 32, 36, 40, 42, 44, 48, -1, -1
> -
> -ASM_FUNCTION_REMOVE_IF_UNREFERENCED
> diff --git a/ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S
> b/ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S
> deleted file mode 100644
> index 9cd81529fb3d..
> --- a/ArmVirtPkg/Library/XenVirtMemInfoLib/Arm/PhysAddrTop.S
> +++ /dev/null
> @@ -1,24 +0,0 @@
> -#
> -# Copyright (c) 2011-2013, ARM Limited. All rights reserved.
> -# Copyright (c) 2014-2017, Linaro Limited. All rights reserved.
> -#
> -# This program and the accompanying m
Re: [edk2] [PATCH v3 06/16] ArmPkg/ArmLib: add support for reading the max physical address space size
On 28/11/18 15:33, Ard Biesheuvel wrote: > Add a helper function that returns the maximum physical address space > size as supported by the current CPU. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Reviewed-by: Philippe Mathieu-Daudé > --- > ArmPkg/Include/Library/ArmLib.h | 6 ++ > ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S | 17 + > ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S | 8 > ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm | 8 > 4 files changed, 39 insertions(+) > > diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h > index ffda50e9d767..9a804c15fdb6 100644 > --- a/ArmPkg/Include/Library/ArmLib.h > +++ b/ArmPkg/Include/Library/ArmLib.h > @@ -733,4 +733,10 @@ ArmWriteCntvOff ( >UINT64 Val >); > > +UINTN > +EFIAPI > +ArmGetPhysicalAddressBits ( > + VOID > + ); > + > #endif // __ARM_LIB__ > diff --git a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > index 1ef2f61f5979..b7173e00b039 100644 > --- a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > +++ b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > @@ -196,4 +196,21 @@ ASM_FUNC(ArmWriteSctlr) > 3:msr sctlr_el3, x0 > 4:ret > > +ASM_FUNC(ArmGetPhysicalAddressBits) > + mrs x0, id_aa64mmfr0_el1 > + adr x1, .LPARanges > + and x0, x0, #0xf > + ldrb w0, [x1, x0] > + ret > + > +// > +// Bits 0..3 of the AA64MFR0_EL1 system register encode the size of the > +// physical address space support on this CPU: > +// 0 == 32 bits, 1 == 36 bits, etc etc > +// 7 and up are reserved > +// > +.LPARanges: > + .byte 32, 36, 40, 42, 44, 48, 52, 0 > + .byte 0, 0, 0, 0, 0, 0, 0, 0 > + > ASM_FUNCTION_REMOVE_IF_UNREFERENCED > diff --git a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > index f2a517671f0a..0e9f9d0453e4 100644 > --- a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > +++ b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > @@ -165,4 +165,12 @@ ASM_FUNC(ArmWriteCpuActlr) >isb >bx lr > > +ASM_FUNC (ArmGetPhysicalAddressBits) > + mrc p15, 0, r0, c0, c1, 4 // MMFR0 > + and r0, r0, #0xf// VMSA [3:0] > + cmp r0, #5 // >= 5 implies LPAE support > + movlt r0, #32 // 32 bits if no LPAE > + movge r0, #40 // 40 bits if LPAE > + bx lr > + > ASM_FUNCTION_REMOVE_IF_UNREFERENCED > diff --git a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm > b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm > index 219140c22b13..3eb52875971d 100644 > --- a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm > +++ b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.asm > @@ -169,4 +169,12 @@ >isb >bx lr > > + RVCT_ASM_EXPORT ArmGetPhysicalAddressBits > + mrc p15, 0, r0, c0, c1, 4 ; MMFR0 > + and r0, r0, #0xf; VMSA [3:0] > + cmp r0, #5 ; >= 5 implies LPAE support > + movlt r0, #32 ; 32 bits if no LPAE > + movge r0, #40 ; 40 bits if LPAE > + bx lr > + >END > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 1/2] ArmVirtPkg/FdtPciHostBridgeLib: map ECAM and I/O spaces in GCD memory map
On 27/11/18 15:54, Ard Biesheuvel wrote:
> Up until now, we have been getting away with not declaring the ECAM
> and translated I/O spaces at all in the GCD memory map, simply because
> we map the entire address space with device attributes in the early PEI
> code, and so these regions will be mapped wherever they end up.
>
> Now that we are about to make changes to how ArmVirtQemu reasons
> about the size of the address space, it would be better to get rid
> of this mapping of the entire address space, since it can get
> arbitrarily large without real benefit.
>
> So start by mapping the ECAM and translated I/O spaces explicitly,
> instead of relying on the early PEI mapping.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf | 1 +
> ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c | 46
> +++-
> 2 files changed, 46 insertions(+), 1 deletion(-)
>
> diff --git a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
> b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
> index 0995f4b7a156..4011336a353b 100644
> --- a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
> +++ b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.inf
> @@ -42,6 +42,7 @@ [Packages]
> [LibraryClasses]
>DebugLib
>DevicePathLib
> + DxeServicesTableLib
>MemoryAllocationLib
>PciPcdProducerLib
>
> diff --git a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> index 5b9c887db35d..ba177353122e 100644
> --- a/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> +++ b/ArmVirtPkg/Library/FdtPciHostBridgeLib/FdtPciHostBridgeLib.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -82,6 +83,33 @@ typedef struct {
> #define DTB_PCI_HOST_RANGE_IO BIT24
> #define DTB_PCI_HOST_RANGE_TYPEMASK (BIT31 | BIT30 | BIT29 | BIT25 |
> BIT24)
>
> +STATIC
> +EFI_STATUS
> +MapGcdMmioSpace (
> + INUINT64Base,
> + INUINT64Size
> + )
> +{
> + EFI_STATUSStatus;
> +
> + Status = gDS->AddMemorySpace (EfiGcdMemoryTypeMemoryMappedIo, Base, Size,
> + EFI_MEMORY_UC);
> + if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_WARN,
> + "%a: failed to add GCD memory space for region [0x%Lx+0x%Lx)\n",
> + __FUNCTION__, Base, Size));
> +return Status;
> + }
> +
> + Status = gDS->SetMemorySpaceAttributes (Base, Size, EFI_MEMORY_UC);
> + if (EFI_ERROR (Status)) {
> +DEBUG ((DEBUG_WARN,
> + "%a: failed to set memory space attributes for region [0x%Lx+0x%Lx)\n",
> + __FUNCTION__, Base, Size));
> + }
> + return Status;
> +}
> +
> STATIC
> EFI_STATUS
> ProcessPciHost (
> @@ -266,7 +294,23 @@ ProcessPciHost (
> "Io[0x%Lx+0x%Lx)@0x%Lx Mem32[0x%Lx+0x%Lx)@0x0 Mem64[0x%Lx+0x%Lx)@0x0\n",
> __FUNCTION__, ConfigBase, ConfigSize, *BusMin, *BusMax, *IoBase, *IoSize,
> IoTranslation, *Mmio32Base, *Mmio32Size, *Mmio64Base, *Mmio64Size));
> - return EFI_SUCCESS;
> +
> + // Map the ECAM space in the GCD memory map
> + Status = MapGcdMmioSpace (ConfigBase, ConfigSize);
> + ASSERT_EFI_ERROR (Status);
> + if (EFI_ERROR (Status)) {
> +return Status;
> + }
> +
> + //
> + // Map the MMIO window that provides I/O access - the PCI host bridge code
> + // is not aware of this translation and so it will only map the I/O view
> + // in the GCD I/O map.
> + //
> + Status = MapGcdMmioSpace (IoTranslation, *IoSize);
> + ASSERT_EFI_ERROR (Status);
> +
> + return Status;
> }
>
> STATIC PCI_ROOT_BRIDGE mRootBridge;
>
LGTM:
Reviewed-by: Philippe Mathieu-Daudé
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] Edk2: Update FmpDevicePkg Maintainers
Hi, On 27/11/18 15:59, Liming Gao wrote: > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Liming Gao > Cc: Star Zeng The usual workflow to hand over is the previous maintainer send the patch, and you Ack-by it. Exceptions are acceptable but require an explanation in the commit message. Regards, Phil. > --- > Maintainers.txt | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Maintainers.txt b/Maintainers.txt > index 9a36f0232b..91a4657adc 100644 > --- a/Maintainers.txt > +++ b/Maintainers.txt > @@ -133,7 +133,7 @@ T: git - https://github.com/tianocore/edk2-FatPkg.git > > FmpDevicePkg > W: https://github.com/tianocore/tianocore.github.io/wiki/FmpDevicePkg > -M: Star Zeng > +M: Liming Gao > M: Michael D Kinney > > IntelFrameworkModulePkg > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] [edk2-test][PATCH v2] SctPkg/build: Add support for GenBin tool build
Hi,
On 27/11/18 9:35, Lokesh B V wrote:
> As the GenBin tool is necessary for SCT build, it is appropriate to
> support it's build in the SCT build procedure.
>
> SctPkg/Tools: Fix incorrect line ending detection by GenBin tool
>
> Some windows editors uses "\r\n" for line feed. While processing uefi testcase
> info file, the GenBin tool logic to skip line feed doesn't consider the
> presence
> of carraige return(\r) in line feed. So this results in incorrect format
> error.
Minor typo: "carriage"
>
> Cc: Supreeth Venkatesh
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Lokesh B V
> ---
> .gitignore | 1 +
> uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c | 3 +++
> uefi-sct/SctPkg/build.sh | 31
>
> 3 files changed, 22 insertions(+), 13 deletions(-)
>
> diff --git a/.gitignore b/.gitignore
> index 821ed66..3b8d818 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -1,2 +1,3 @@
> Build/
> tags/
> +*.[od]
> diff --git a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
> b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
> index 61bb35b..4eaefcc 100644
> --- a/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
> +++ b/uefi-sct/SctPkg/Tools/Source/GenBin/GenBin.c
> @@ -2,6 +2,7 @@
>
>Copyright 2006 - 2010 Unified EFI, Inc.
>Copyright (c) 2010 Intel Corporation. All rights reserved.
> + Copyright (c) 2018 ARM Ltd. All rights reserved.
>
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
> @@ -176,6 +177,7 @@ Trim (
>for (Index1 = 0; Index1 < Length; Index1++) {
> if ((String[Index1] != ' ' ) &&
> (String[Index1] != '\t') &&
> +(String[Index1] != '\r') &&
> (String[Index1] != '\n')) {
>break;
> }
> @@ -193,6 +195,7 @@ Trim (
>for (Index1 = 0; Index1 < Length; Index1++) {
> if ((String[Length - 1 - Index1] != ' ' ) &&
> (String[Length - 1 - Index1] != '\t') &&
> +(String[Length - 1 - Index1] != '\r') &&
> (String[Length - 1 - Index1] != '\n')) {
>break;
> }
> diff --git a/uefi-sct/SctPkg/build.sh b/uefi-sct/SctPkg/build.sh
> index 73581c9..6198532 100755
> --- a/uefi-sct/SctPkg/build.sh
> +++ b/uefi-sct/SctPkg/build.sh
> @@ -1,7 +1,7 @@
> #!/bin/bash
> #
> # Copyright 2006 - 2015 Unified EFI, Inc.
> -# Copyright (c) 2011 - 2015, ARM Ltd. All rights reserved.
> +# Copyright (c) 2011 - 2018, ARM Ltd. All rights reserved.
> #
> # This program and the accompanying materials
> # are licensed and made available under the terms and conditions of the BSD
> License
> @@ -228,21 +228,26 @@ else
>echo using prebuilt tools
> fi
>
> -# Copy GenBin file to Base tools directory
> +if [[ ! -e $EDK_TOOLS_PATH/Source/C/bin/GenBin ]]
> +then
> + # build the GenBin if it doesn't yet exist
> + echo Building GenBin
> + make -C $EDK_TOOLS_PATH/../SctPkg/Tools/Source/GenBin
> + status=$?
> + if test $status -ne 0
> + then
> + echo Error while building GenBin
> +exit -1
> + fi
> +else
> + echo using prebuilt GenBin
> +fi
> +
> +# Copy GenBin file to Base tools bin directory
> DEST_DIR=`GetEdkToolsPathBinDirectory`
> # Ensure the directory exist
> mkdir -p $DEST_DIR
> -case `uname -m` in
> - x86_64)
> - cp SctPkg/Tools/Bin/GenBin_lin_64 $DEST_DIR/GenBin
> - ;;
> - x86_32)
> - cp SctPkg/Tools/Bin/GenBin_lin_32 $DEST_DIR/GenBin
> - ;;
> - *)
> - cp SctPkg/Tools/Bin/GenBin_lin_32 $DEST_DIR/GenBin
> - ;;
> -esac
> +cp $EDK_TOOLS_PATH/Source/C/bin/GenBin $DEST_DIR/GenBin
>
> #
> # Build the SCT package
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 01/13] ArmPkg/ArmLib: add support for reading the max physical address space size
On Mon, Nov 26, 2018 at 11:43 PM Philippe Mathieu-Daudé wrote: > > On 26/11/18 23:37, Ard Biesheuvel wrote: > > Add a helper function that returns the maximum physical address space > > size as supported by the current CPU. > > > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Ard Biesheuvel > > Reviewed-by: Philippe Mathieu-Daudé > > > --- > > ArmPkg/Include/Library/ArmLib.h | 17 + > > ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S | 16 > > ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S | 8 > > 3 files changed, 41 insertions(+) > > > > diff --git a/ArmPkg/Include/Library/ArmLib.h > > b/ArmPkg/Include/Library/ArmLib.h > > index ffda50e9d767..b22879fe6e94 100644 > > --- a/ArmPkg/Include/Library/ArmLib.h > > +++ b/ArmPkg/Include/Library/ArmLib.h > > @@ -29,6 +29,17 @@ > > #define EFI_MEMORY_CACHETYPE_MASK (EFI_MEMORY_UC | EFI_MEMORY_WC | \ > > EFI_MEMORY_WT | EFI_MEMORY_WB | \ > > EFI_MEMORY_UCE) > > +// > > +// ARM_MMU_IDMAP_RANGE defines the maximum size of the identity mapping > > +// that covers the entire address space when running in UEFI. This is > > +// limited to what can architecturally be mapped using a 4 KB granule, > > +// even if the hardware is capable of mapping more using larger pages. > > +// > > +#ifdef MDE_CPU_ARM > > +#define ARM_MMU_IDMAP_RANGE (1ULL << 32) > > +#else > > +#define ARM_MMU_IDMAP_RANGE (1ULL << 48) > > +#endif > > > > /** > > * The UEFI firmware must not use the > > ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_* attributes. > > @@ -733,4 +744,10 @@ ArmWriteCntvOff ( > >UINT64 Val > >); > > > > +UINTN > > +EFIAPI > > +ArmGetPhysicalAddressBits ( > > + VOID > > + ); > > + > > #endif // __ARM_LIB__ > > diff --git a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > > b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > > index 1ef2f61f5979..7332601241aa 100644 > > --- a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > > +++ b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > > @@ -196,4 +196,20 @@ ASM_FUNC(ArmWriteSctlr) > > 3:msr sctlr_el3, x0 > > 4:ret > > > > +ASM_FUNC(ArmGetPhysicalAddressBits) > > + mrs x0, id_aa64mmfr0_el1 > > + adr x1, .LPARanges > > + and x0, x0, #7 > > + ldrb w0, [x1, x0] > > + ret > > + > > +// > > +// Bits 0..2 of the AA64MFR0_EL1 system register encode the size of the > > +// physical address space support on this CPU: > > +// 0 == 32 bits, 1 == 36 bits, etc etc > > +// 6 and 7 are reserved Oops the comment is now invalid for the index == 6. > > +// > > +.LPARanges: > > + .byte 32, 36, 40, 42, 44, 48, 52, -1 > > + > > ASM_FUNCTION_REMOVE_IF_UNREFERENCED > > diff --git a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > > b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > > index f2a517671f0a..f2f3c9a25991 100644 > > --- a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > > +++ b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > > @@ -165,4 +165,12 @@ ASM_FUNC(ArmWriteCpuActlr) > >isb > >bx lr > > > > +ASM_FUNC (ArmGetPhysicalAddressBits) > > + mrc p15, 0, r0, c0, c1, 4 // MMFR0 > > + and r0, r0, #0xf// VMSA [3:0] > > + cmp r0, #5 // >5 implies LPAE support > > + movlt r0, #32 // 32 bits if no LPAE > > + movge r0, #40 // 40 bits if LPAE > > + bx lr > > + > > ASM_FUNCTION_REMOVE_IF_UNREFERENCED > > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 01/13] ArmPkg/ArmLib: add support for reading the max physical address space size
On 26/11/18 23:37, Ard Biesheuvel wrote: > Add a helper function that returns the maximum physical address space > size as supported by the current CPU. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel Reviewed-by: Philippe Mathieu-Daudé > --- > ArmPkg/Include/Library/ArmLib.h | 17 + > ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S | 16 > ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S | 8 > 3 files changed, 41 insertions(+) > > diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h > index ffda50e9d767..b22879fe6e94 100644 > --- a/ArmPkg/Include/Library/ArmLib.h > +++ b/ArmPkg/Include/Library/ArmLib.h > @@ -29,6 +29,17 @@ > #define EFI_MEMORY_CACHETYPE_MASK (EFI_MEMORY_UC | EFI_MEMORY_WC | \ > EFI_MEMORY_WT | EFI_MEMORY_WB | \ > EFI_MEMORY_UCE) > +// > +// ARM_MMU_IDMAP_RANGE defines the maximum size of the identity mapping > +// that covers the entire address space when running in UEFI. This is > +// limited to what can architecturally be mapped using a 4 KB granule, > +// even if the hardware is capable of mapping more using larger pages. > +// > +#ifdef MDE_CPU_ARM > +#define ARM_MMU_IDMAP_RANGE (1ULL << 32) > +#else > +#define ARM_MMU_IDMAP_RANGE (1ULL << 48) > +#endif > > /** > * The UEFI firmware must not use the > ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_* attributes. > @@ -733,4 +744,10 @@ ArmWriteCntvOff ( >UINT64 Val >); > > +UINTN > +EFIAPI > +ArmGetPhysicalAddressBits ( > + VOID > + ); > + > #endif // __ARM_LIB__ > diff --git a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > index 1ef2f61f5979..7332601241aa 100644 > --- a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > +++ b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S > @@ -196,4 +196,20 @@ ASM_FUNC(ArmWriteSctlr) > 3:msr sctlr_el3, x0 > 4:ret > > +ASM_FUNC(ArmGetPhysicalAddressBits) > + mrs x0, id_aa64mmfr0_el1 > + adr x1, .LPARanges > + and x0, x0, #7 > + ldrb w0, [x1, x0] > + ret > + > +// > +// Bits 0..2 of the AA64MFR0_EL1 system register encode the size of the > +// physical address space support on this CPU: > +// 0 == 32 bits, 1 == 36 bits, etc etc > +// 6 and 7 are reserved > +// > +.LPARanges: > + .byte 32, 36, 40, 42, 44, 48, 52, -1 > + > ASM_FUNCTION_REMOVE_IF_UNREFERENCED > diff --git a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > index f2a517671f0a..f2f3c9a25991 100644 > --- a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > +++ b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S > @@ -165,4 +165,12 @@ ASM_FUNC(ArmWriteCpuActlr) >isb >bx lr > > +ASM_FUNC (ArmGetPhysicalAddressBits) > + mrc p15, 0, r0, c0, c1, 4 // MMFR0 > + and r0, r0, #0xf// VMSA [3:0] > + cmp r0, #5 // >5 implies LPAE support > + movlt r0, #32 // 32 bits if no LPAE > + movge r0, #40 // 40 bits if LPAE > + bx lr > + > ASM_FUNCTION_REMOVE_IF_UNREFERENCED > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/4] OvmfPkg: introduce ACPI Test Support data structure and GUID
Hi Laszlo,
On 25/11/18 11:01, Laszlo Ersek wrote:
> QEMU's test suite includes a set of cases called "BIOS tables test". Among
> other things, it locates the RSD PTR ACPI table in guest RAM, and then
> (chasing pointers to other ACPI tables) performs various sanity checks on
> the QEMU-generated and firmware-installed tables.
>
> Currently this set of test cases doesn't work with UEFI guests, because
> the ACPI spec's definition for locating the RSD PTR in UEFI guests is a
> lot harder to implement from the hypervisor side -- just with raw guest
> memory access -- than it is when scraping the memory of BIOS guests.
>
> Introduce a signature GUID, and a small, MB-aligned structure, identified
> by the GUID. The hypervisor should loop over all MB-aligned pages in guest
> RAM until one matches the signature GUID at offset 0, at which point the
> hypervisor can fetch the RSDP address field(s) from the structure.
>
> QEMU's test logic currently spins on a pre-determined guest address, until
> that address assumes a magic value. The method described in this patch is
> conceptually the same ("busy loop until match is found"), except there is
> no hard-coded address. This plays a lot more nicely with UEFI guest
> firmware (we'll be able to use the normal page allocation UEFI service).
> Given the size of EFI_GUID (16 bytes -- 128 bits), mismatches should be
> astronomically unlikely. In addition, given the typical guest RAM size for
> such tests (128 MB), there are 128 locations to check in one iteration of
> the "outer" loop, which shouldn't introduce an intolerable delay after the
> guest stores the RSDP address(es), and then the GUID.
I applied/build your series, but keep failing trying to test it with QEMU :/
I modified a bit tests/bios-tables-test.c to use the OVMF.fd build for
the Q35 machine tests, but still pass the "OnRootBridgesConnected: root
bridges have been connected, installing ACPI tables".
Do you have a QEMU companion patch for this series?
>
> The GUID that the hypervisor should search for is
>
> AB87A6B1-2034-BDA0-71BD-375007757785
>
> Expressed as a byte array:
>
> {
> 0xb1, 0xa6, 0x87, 0xab,
> 0x34, 0x20,
> 0xa0, 0xbd,
> 0x71, 0xbd, 0x37, 0x50, 0x07, 0x75, 0x77, 0x85
> }
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/5] ArmPkg/ArmLib: add support for reading the max physical address space size
On 26/11/18 12:46, Ard Biesheuvel wrote: > On Fri, 23 Nov 2018 at 13:14, Ard Biesheuvel > wrote: >> >> Add a helper function that returns the maximum physical address space >> size as supported by the current CPU. >> >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Ard Biesheuvel >> --- >> ArmPkg/Include/Library/ArmLib.h | 6 ++ >> ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S | 16 >> ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S | 8 >> 3 files changed, 30 insertions(+) >> >> diff --git a/ArmPkg/Include/Library/ArmLib.h >> b/ArmPkg/Include/Library/ArmLib.h >> index ffda50e9d767..9a804c15fdb6 100644 >> --- a/ArmPkg/Include/Library/ArmLib.h >> +++ b/ArmPkg/Include/Library/ArmLib.h >> @@ -733,4 +733,10 @@ ArmWriteCntvOff ( >>UINT64 Val >>); >> >> +UINTN >> +EFIAPI >> +ArmGetPhysicalAddressBits ( >> + VOID >> + ); >> + >> #endif // __ARM_LIB__ >> diff --git a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S >> b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S >> index 1ef2f61f5979..75ab8dade485 100644 >> --- a/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S >> +++ b/ArmPkg/Library/ArmLib/AArch64/ArmLibSupport.S >> @@ -196,4 +196,20 @@ ASM_FUNC(ArmWriteSctlr) >> 3:msr sctlr_el3, x0 >> 4:ret >> >> +ASM_FUNC(ArmGetPhysicalAddressBits) >> + mrs x0, id_aa64mmfr0_el1 >> + adr x1, .LPARanges >> + and x0, x0, #7 >> + ldrb w0, [x1, x0] >> + ret >> + >> +// >> +// Bits 0..2 of the AA64MFR0_EL1 system register encode the size of the >> +// physical address space support on this CPU: >> +// 0 == 32 bits, 1 == 36 bits, etc etc >> +// 6 and 7 are reserved >> +// >> +.LPARanges: >> + .byte 32, 36, 40, 42, 44, 48, -1, -1 >> + > > Note: as Drew pointed out, we want 52 bits included as well in this > enumeration. I will fix that up when applying (unless anyone objects) Using index 6 == 52 and updating the comment: Reviewed-by: Philippe Mathieu-Daudé > >> ASM_FUNCTION_REMOVE_IF_UNREFERENCED >> diff --git a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S >> b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S >> index f2a517671f0a..f2f3c9a25991 100644 >> --- a/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S >> +++ b/ArmPkg/Library/ArmLib/Arm/ArmLibSupport.S >> @@ -165,4 +165,12 @@ ASM_FUNC(ArmWriteCpuActlr) >>isb >>bx lr >> >> +ASM_FUNC (ArmGetPhysicalAddressBits) >> + mrc p15, 0, r0, c0, c1, 4 // MMFR0 >> + and r0, r0, #0xf// VMSA [3:0] >> + cmp r0, #5 // >5 implies LPAE support >> + movlt r0, #32 // 32 bits if no LPAE >> + movge r0, #40 // 40 bits if LPAE >> + bx lr >> + >> ASM_FUNCTION_REMOVE_IF_UNREFERENCED >> -- >> 2.17.1 >> ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 1/5] ArmPlatformPkg/NorFlashDxe: prepare for devicepath format change
On 21/11/18 12:58, Ard Biesheuvel wrote:
> A subsequent patch will change the layout of devicepath nodes
> produced by this driver. In preparation, make some tweaks to
> the code to use a packed struct for the devicepath and to pass
> the device index to NorFlashCreateInstance(). These are cosmetic
> changes only, the resulting binaries should be identical.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> Reviewed-by: Laszlo Ersek
Reviewed-by: Philippe Mathieu-Daudé
> ---
> ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c | 9 ++---
> ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h | 2 ++
> 2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> index 46e815beb343..53753a4721ac 100644
> --- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> @@ -82,7 +82,10 @@ NOR_FLASH_INSTANCE mNorFlashInstanceTemplate = {
>{
> HARDWARE_DEVICE_PATH,
> HW_VENDOR_DP,
> -{ (UINT8)sizeof(VENDOR_DEVICE_PATH),
> (UINT8)((sizeof(VENDOR_DEVICE_PATH)) >> 8) }
> +{
> + (UINT8)(OFFSET_OF (NOR_FLASH_DEVICE_PATH, End)),
> + (UINT8)(OFFSET_OF (NOR_FLASH_DEVICE_PATH, End) >> 8)
> +}
>},
>{ 0x0, 0x0, 0x0, { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 } }, // GUID
> ... NEED TO BE FILLED
> },
> @@ -99,7 +102,7 @@ NorFlashCreateInstance (
>IN UINTN NorFlashDeviceBase,
>IN UINTN NorFlashRegionBase,
>IN UINTN NorFlashSize,
> - IN UINT32 MediaId,
> + IN UINT32 Index,
>IN UINT32 BlockSize,
>IN BOOLEANSupportFvb,
>IN CONST GUID *NorFlashGuid,
> @@ -121,7 +124,7 @@ NorFlashCreateInstance (
>Instance->Size = NorFlashSize;
>
>Instance->BlockIoProtocol.Media = &Instance->Media;
> - Instance->Media.MediaId = MediaId;
> + Instance->Media.MediaId = Index;
>Instance->Media.BlockSize = BlockSize;
>Instance->Media.LastBlock = (NorFlashSize / BlockSize)-1;
>
> diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> index 5c07694fbfaa..910681fd4412 100644
> --- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> @@ -122,10 +122,12 @@
>
> typedef struct _NOR_FLASH_INSTANCENOR_FLASH_INSTANCE;
>
> +#pragma pack(1)
> typedef struct {
>VENDOR_DEVICE_PATH Vendor;
>EFI_DEVICE_PATH_PROTOCOLEnd;
> } NOR_FLASH_DEVICE_PATH;
> +#pragma pack()
>
> struct _NOR_FLASH_INSTANCE {
>UINT32 Signature;
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 3/5] ArmVirtPkg/FdtClientDxe: take DT node 'status' properties into account
On 21/11/18 12:58, Ard Biesheuvel wrote:
> DT has a [pseudo-]standardized 'status' property that can be set on
> any node, and which signifies that a node should be treated as
> absent unless it is set to 'ok' or 'okay'. So take this into account
> when iterating over nodes.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
Reviewed-by: Philippe Mathieu-Daudé
> ---
> ArmVirtPkg/FdtClientDxe/FdtClientDxe.c | 38 +---
> 1 file changed, 33 insertions(+), 5 deletions(-)
>
> diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
> b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
> index fb6e0aeb9215..5bfde381ecd0 100644
> --- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
> +++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
> @@ -78,6 +78,33 @@ SetNodeProperty (
>return EFI_SUCCESS;
> }
>
> +STATIC
> +BOOLEAN
> +IsNodeEnabled (
> + INT32 Node
> + )
> +{
> + CONST CHAR8 *NodeStatus;
> + INT32 Len;
> +
> + //
> + // A missing status property implies 'ok' so ignore any errors that
> + // may occur here. If the status property is present, check whether
> + // it is set to 'ok' or 'okay', anything else is treated as 'disabled'.
> + //
> + NodeStatus = fdt_getprop (mDeviceTreeBase, Node, "status", &Len);
> + if (NodeStatus == NULL) {
> +return TRUE;
> + }
> + if (Len >= 5 && AsciiStrCmp (NodeStatus, "okay") == 0) {
> +return TRUE;
> + }
> + if (Len >= 3 && AsciiStrCmp (NodeStatus, "ok") == 0) {
> +return TRUE;
> + }
> + return FALSE;
> +}
> +
> STATIC
> EFI_STATUS
> EFIAPI
> @@ -101,6 +128,10 @@ FindNextCompatibleNode (
>break;
> }
>
> +if (!IsNodeEnabled (Next)) {
> + continue;
> +}
> +
> Type = fdt_getprop (mDeviceTreeBase, Next, "compatible", &Len);
> if (Type == NULL) {
>continue;
> @@ -210,7 +241,6 @@ FindNextMemoryNodeReg (
> {
>INT32 Prev, Next;
>CONST CHAR8*DeviceType;
> - CONST CHAR8*NodeStatus;
>INT32 Len;
>EFI_STATUS Status;
>
> @@ -223,10 +253,8 @@ FindNextMemoryNodeReg (
>break;
> }
>
> -NodeStatus = fdt_getprop (mDeviceTreeBase, Next, "status", &Len);
> -if (NodeStatus != NULL && AsciiStrCmp (NodeStatus, "okay") != 0) {
> - DEBUG ((DEBUG_WARN, "%a: ignoring memory node with status \"%a\"\n",
> -__FUNCTION__, NodeStatus));
> +if (!IsNodeEnabled (Next)) {
> + DEBUG ((DEBUG_WARN, "%a: ignoring disabled memory node\n",
> __FUNCTION__));
>continue;
> }
>
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 2/5] ArmPlatformPkg/NorFlashDxe: use one GUID plus index to identify flash banks
On 21/11/18 12:58, Ard Biesheuvel wrote:
> Currently, each flash bank controlled by ArmPlatformPkg/NorFlashDxe
> has its own VendorHw GUID, and instances of NorFlashPlatformLib
> describe each bank to the driver, along with the GUID for each.
>
> This works ok for bare metal platforms, but it would be useful for
> virtual platforms if we could obtain this information from a
> device tree, which would require us to invent GUIDs on the fly,
> given that the 'cfi-flash' binding does not include a GUID.
>
> So instead, let's switch to a single GUID for all flash banks,
> and update the driver's device path handling to include an index
> to identify each bank uniquely.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> Reviewed-by: Laszlo Ersek
> Reviewed-by: Leif Lindholm
Reviewed-by: Philippe Mathieu-Daudé
> ---
> ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c | 6 +++---
> ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h | 1 +
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> index 53753a4721ac..af40a4c88412 100644
> --- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.c
> @@ -89,6 +89,7 @@ NOR_FLASH_INSTANCE mNorFlashInstanceTemplate = {
>},
>{ 0x0, 0x0, 0x0, { 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0 } }, // GUID
> ... NEED TO BE FILLED
> },
> +0, // Index
> {
>END_DEVICE_PATH_TYPE,
>END_ENTIRE_DEVICE_PATH_SUBTYPE,
> @@ -105,7 +106,6 @@ NorFlashCreateInstance (
>IN UINT32 Index,
>IN UINT32 BlockSize,
>IN BOOLEANSupportFvb,
> - IN CONST GUID *NorFlashGuid,
>OUT NOR_FLASH_INSTANCE** NorFlashInstance
>)
> {
> @@ -128,7 +128,8 @@ NorFlashCreateInstance (
>Instance->Media.BlockSize = BlockSize;
>Instance->Media.LastBlock = (NorFlashSize / BlockSize)-1;
>
> - CopyGuid (&Instance->DevicePath.Vendor.Guid, NorFlashGuid);
> + CopyGuid (&Instance->DevicePath.Vendor.Guid, &gEfiCallerIdGuid);
> + Instance->DevicePath.Index = (UINT8)Index;
>
>Instance->ShadowBuffer = AllocateRuntimePool (BlockSize);;
>if (Instance->ShadowBuffer == NULL) {
> @@ -1314,7 +1315,6 @@ NorFlashInitialise (
>Index,
>NorFlashDevices[Index].BlockSize,
>ContainVariableStorage,
> - &NorFlashDevices[Index].Guid,
>&mNorFlashInstances[Index]
> );
> if (EFI_ERROR(Status)) {
> diff --git a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> index 910681fd4412..8886aa43d9f3 100644
> --- a/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> +++ b/ArmPlatformPkg/Drivers/NorFlashDxe/NorFlashDxe.h
> @@ -125,6 +125,7 @@ typedef struct _NOR_FLASH_INSTANCE
> NOR_FLASH_INSTANCE;
> #pragma pack(1)
> typedef struct {
>VENDOR_DEVICE_PATH Vendor;
> + UINT8 Index;
>EFI_DEVICE_PATH_PROTOCOLEnd;
> } NOR_FLASH_DEVICE_PATH;
> #pragma pack()
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [edk2-announce][RFC] Collaboration Software
On 16/11/18 21:46, stephano wrote: This looks great. I'm going to dig in a bit and see if we can export discussions for logging purposes or if they are locked into Github. For people on the move, having bad internet (3rd world countries), email system is very powerful, you can download once and work offline, reading/answering. You can also download the list archive and refers to it offline. You also have access to all patches and can apply them offline too. Is this possible with GitHub? Maybe the open source alternative, GitLab, offers a such feature. Googling "gitlab offline" I get: "Many of our customers do not have regular Internet access and many of them, being highly regulated, cannot install local copies of GitLab to be able to run against the provided API. [...] The work, published as the gitlab-ci-yaml_lint gem, is my attempt at a start to solving the issue." This is not what I expected, but it confirms some people have troubles working with online-only services. Regards, Phil. git clone git://tianocore.discussion ? :) On 11/16/2018 11:55 AM, Kinney, Michael D wrote: Hi Stephano, GitHub supports discussions for teams. If we added a new team to the GitHub TianoCore organization for all developers that want to be involved in community topics and design discussions (which should closely match the current members of edk2-devel) then that may be a simple option that uses services that already there. Another option is to use discussions for one of the exiting teams (e.g. Tianocore Maintainers) and make posts for these discussion topics public. https://blog.github.com/2017-11-20-introducing-team-discussions/ https://help.github.com/articles/about-team-discussions/ Best regards, Mike -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of stephano Sent: Friday, November 16, 2018 11:14 AM To: Zimmer, Vincent ; edk2- de...@lists.01.org Subject: Re: [edk2] [edk2-announce][RFC] Collaboration Software The only reason I didn't include Slack is that it will only log so much information before things start falling off into the ether. Does anyone in the community currently use Slack and know of an easy way of archiving conversations publicly? On 11/16/2018 9:56 AM, Zimmer, Vincent wrote: https://slack.com/ -Original Message- From: edk2-devel [mailto:edk2-devel- boun...@lists.01.org] On Behalf Of Kevin D Davis Sent: Friday, November 16, 2018 9:35 AM To: stephano ; edk2- de...@lists.01.org Subject: Re: [edk2] [edk2-announce][RFC] Collaboration Software If we get to vote, I’d vote against Google Groups. Their interface is very geared toward their internal work flow and seems to change on a whim. Thanks,Kevin On Fri, Nov 16, 2018 at 11:08 AM -0600, "stephano" wrote: We are looking to augment our current communication methods (mailing list / IRC) with a modern solution for group collaboration. The goal is to allow folks to communicate effectively without interrupting the current patch review system, as well as enabling any future systems with more robust options. Specific features we are looking for include attachments (currently blocked by the list), robust logging, modern chat, and integration with tools like bug trackers and source repositories (APIs, or better yet, pre-rolled plugins). Our current contenders are Google Groups and Groups.io. This RFC is in hopes of finding other options to evaluate. Cheers, Stephano ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [OVMF+VIFO+QEMU] Large VM RAM allocation = Long Boot Times
Cc'ing qemu-devel@ On 15/11/18 6:58, A Z wrote: This is an issue that involves a combination of different software packages, so my apologies in advance if this is the wrong list to post on. I'm experiencing terrible boot times when I assign a large amount of RAM to a VM when used in combination with VIFO/PCI-passthrough. On a VM with a Nvidia GTX 970 + USB controller and 24GiB of RAM assigned, the time to the TianoCore splash screen is ~5 minutes. It's then ~30 seconds before Windows 10 begins to boot (spinning dots). During this time, the QEMU CPU core threads are 100% busy. According to `perf`, the QMU CPU core threads are spending most of their time waiting on a spinlock over kvm->mmu_lock that's created by kvm_zap_gfn_range. I'm fairly certain that ~1 year ago (if not longer) the same configuration didn't take this long to boot. Regards, Adam ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v1 1/1] MdeModulePkg/NvmExpressPei: Refine data buffer & len check in PassThru
On 13/11/18 2:02, Wu, Hao A wrote:
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo
Ersek
Sent: Monday, November 12, 2018 6:15 PM
To: Wu, Hao A; edk2-devel@lists.01.org
Cc: Ni, Ruiyu; Gao, Liming; Yao, Jiewen; Kinney, Michael D; Zeng, Star
Subject: Re: [edk2] [PATCH v1 1/1] MdeModulePkg/NvmExpressPei: Refine data
buffer & len check in PassThru
On 11/12/18 02:34, Hao Wu wrote:
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1142
The fix is similar to commit ebb6c7633bca47fcd5b460a67e18e4a717ea91cc.
We found that a similar fix should be applied to the NVMe PEI driver as
well. Hence, this one is for the PEI counterpart driver.
According to the the NVM Express spec Revision 1.1, for some commands
(like Get/Set Feature Command, Figure 89 & 90 of the spec), the Memory
Buffer maybe optional although the command opcode indicates there is a
data transfer between host & controller (Get/Set Feature Command, Figure
38 of the spec).
Hence, this commit refine the checks for the 'TransferLength' and
'TransferBuffer' field of the
EDKII_PEI_NVM_EXPRESS_PASS_THRU_COMMAND_PACKET structure to
address this
issue.
I agree that this change qualifies as a bugfix for the hard feature
freeze. From that perspective, without checking any technical details:
Acked-by: Laszlo Ersek
I checked NVM Express spec Revision 1.3c.
Reviewed-by: Philippe Mathieu-Daudé
*However*, please clean up the description in the bugzilla (BZ#1142). In
the bugzilla, both the title and the initial description say that the
check is "unnecessar" / "not necessary".
If the problem were only that the check was "superfluous", then this
patch would *not* qualify as a bugfix. Because, there would be *no bug*.
And a patch to remove a superfluous (and otherwise harmless) check would
be called a "cleanup", or a "trivial optimization".
Instead, the check is *wrong*. It breaks valid behavior. That's why
there is a bug, and that's why the patch is a bugfix.
Please be clear about this distinction, and update the BZ.
Thanks Laszlo,
I have updated the description of BZ 1142 to better reflect the issue.
Best Regards,
Hao Wu
Thanks
Laszlo
Cc: Andrew Fish
Cc: Laszlo Ersek
Cc: Leif Lindholm
Cc: Michael D Kinney
Cc: Liming Gao
Cc: Ruiyu Ni
Cc: Jiewen Yao
Cc: Star Zeng
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu
---
MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiPassThru.c | 33
+++-
1 file changed, 18 insertions(+), 15 deletions(-)
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiPassThru.c
b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiPassThru.c
index 81ad01b7ee..ddcfe03998 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiPassThru.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiPassThru.c
@@ -442,7 +442,8 @@ NvmePassThru (
// specific addresses.
//
if ((Sq->Opc & (BIT0 | BIT1)) != 0) {
-if ((Packet->TransferLength == 0) || (Packet->TransferBuffer == NULL)) {
+if (((Packet->TransferLength != 0) && (Packet->TransferBuffer == NULL))
||
+((Packet->TransferLength == 0) && (Packet->TransferBuffer != NULL)))
{
return EFI_INVALID_PARAMETER;
}
@@ -468,21 +469,23 @@ NvmePassThru (
MapOp = EdkiiIoMmuOperationBusMasterWrite;
}
- MapLength = Packet->TransferLength;
- Status = IoMmuMap (
- MapOp,
- Packet->TransferBuffer,
- &MapLength,
- &PhyAddr,
- &MapData
- );
- if (EFI_ERROR (Status) || (MapLength != Packet->TransferLength)) {
-Status = EFI_OUT_OF_RESOURCES;
-DEBUG ((DEBUG_ERROR, "%a: Fail to map data buffer.\n",
__FUNCTION__));
-goto Exit;
- }
+ if ((Packet->TransferLength != 0) && (Packet->TransferBuffer != NULL)) {
+MapLength = Packet->TransferLength;
+Status = IoMmuMap (
+ MapOp,
+ Packet->TransferBuffer,
+ &MapLength,
+ &PhyAddr,
+ &MapData
+ );
+if (EFI_ERROR (Status) || (MapLength != Packet->TransferLength)) {
+ Status = EFI_OUT_OF_RESOURCES;
+ DEBUG ((DEBUG_ERROR, "%a: Fail to map data buffer.\n",
__FUNCTION__));
+ goto Exit;
+}
- Sq->Prp[0] = PhyAddr;
+Sq->Prp[0] = PhyAddr;
+ }
if((Packet->MetadataLength != 0) && (Packet->MetadataBuffer != NULL))
{
MapLength = Packet->MetadataLength;
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 0/5] OvmfPkg: simply use the Bochs interface for vmsvga
On 2/11/18 4:23, yuchen...@synology.com wrote: From: yuchenlin In this series, replace the original vmsvga driver to Bochs interface. Simply revert vmsvga driver implementation. After it, use Bochs interface for initializing vmsvga. Because of the PCI BARs difference between std vga and vmsvga. We can not simply recognize the "QEMU VMWare SVGA" as the QEMU_VIDEO_BOCHS_MMIO variant. BAR |std vga | vmsvga - 0| Framebuffer | I/O space 1| Reserved | Framebuffer 2| MMIO | FIFO To overcome this problem, we remain variant QEMU_VIDEO_VMWARE_SVGA, and use it for: (1) Get framebuffer from correct PCI BAR (2) Prevent using BAR2 for MMIO We have tested on qemu before and after commit 104bd1dc70 and all worked. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: yuchenlin Changelog: v1 -> v2 * use 'else' clause (Thanks Philippe). * add more comment in revert patches (Thanks Philippe). * reorder the revert patches, we should revert the last commit first. * use correct framebuffer to ClearScreen. * revert VMWare svga definitions. yuchenlin (5): Revert "OvmfPkg/QemuVideoDxe: list "UnalignedIoInternal.h" in the INF file" Revert "OvmfPkg/QemuVideoDxe: VMWare SVGA device support" Revert "OvmfPkg/QemuVideoDxe: Helper functions for unaligned port I/O." Revert "OvmfPkg: VMWare SVGA display device register definitions" OvmfPkg: simply use the Bochs interface for vmsvga FWIW Patches 1-4: Reviewed-by: Philippe Mathieu-Daudé Patch 5 (not yet merged) is still on my TODO because I want to run detailed testing. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 5/5] OvmfPkg: simply use the Bochs interface for vmsvga
On 12/11/18 13:21, Laszlo Ersek wrote: On 11/12/18 12:28, Philippe Mathieu-Daudé wrote: On Mon, Nov 12, 2018 at 12:20 PM Laszlo Ersek wrote: On 11/06/18 14:44, Philippe Mathieu-Daudé wrote: On 6/11/18 14:36, Laszlo Ersek wrote: On 11/06/18 12:47, Laszlo Ersek wrote: ... While we discuss this, I'll go ahead and push the first four patches. The code being reverted is dead anyway. I'll report back about the commit hashes. Before pushing the first four patches, I regression-tested them as well. Using: Cirrus, stdvga, and QXL. My QEMU version was v3.0.0-1763-gb2f7a038bb4c. The machine type was "pc-q35-3.0". For the first four patches: - Regression-tested-by: Laszlo Ersek , - pushed them as commit range 62ea70e31285..328409ce8de7. Thanks Laszlo! A bit late, but 1-4 reviewed too. can you please formally state your R-b, for the first four patches? For when I apply them again, after edk2-stable201811. Sure, I was not aware the "reply to cover" option was not formal for this list, I'll do. (TIL: "reply to cover" is list CoC specific) "reply to cover letter" is perfectly fine on this list as well (it never occurred to me that it would be unacceptable for any list in the first place) -- but where did you respond to: [edk2] [PATCH v2 0/5] OvmfPkg: simply use the Bochs interface for vmsvga 20181102032402.19686-1-yuchenlin@synology.com">http://mid.mail-archive.com/20181102032402.19686-1-yuchenlin@synology.com ? ... Ahhh, wait, now I see where our misunderstanding is. :) By "formally", I did not mean that you should respond to every single patch (#1 through #4) separately, with your R-b. Responding under the cover letter, or even just in this thread, is perfectly fine. What I'm asking for instead is that you please "formally" spell out your Reviewed-by tag. In edk2 we strongly prefer carrying R-b tags from the mailing list to commit messages verbatim (i.e. with the clipboard). We dislike synthesizing formal R-b tags from messages like "sure, reviewed by me too". So, again, in this context, "formally" only means that you please repeat your "reviewed too" message "formally" with an R-b tag, spelled out. A response in this thread is perfectly fine. Oh you are right, I did not send my formal R-b :) My bad, sorry! ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/2] MdePkg/UefiDebugLibConOut: Pass the correct buffer size.
Hi Marvin, I just noticed the trailing '.' in the patch subject, you should remove it (also in the 2nd patch). Regards, Phil. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 5/5] OvmfPkg: simply use the Bochs interface for vmsvga
On Mon, Nov 12, 2018 at 12:20 PM Laszlo Ersek wrote: > On 11/06/18 14:44, Philippe Mathieu-Daudé wrote: > > On 6/11/18 14:36, Laszlo Ersek wrote: > >> On 11/06/18 12:47, Laszlo Ersek wrote: > >> > >>> ... While we discuss this, I'll go ahead and push the first four > >>> patches. The code being reverted is dead anyway. I'll report back about > >>> the commit hashes. > >> > >> Before pushing the first four patches, I regression-tested them as well. > >> Using: Cirrus, stdvga, and QXL. My QEMU version was > >> v3.0.0-1763-gb2f7a038bb4c. The machine type was "pc-q35-3.0". > >> > >> For the first four patches: > >> - Regression-tested-by: Laszlo Ersek , > >> - pushed them as commit range 62ea70e31285..328409ce8de7. > > > > Thanks Laszlo! > > A bit late, but 1-4 reviewed too. > > can you please formally state your R-b, for the first four patches? For > when I apply them again, after edk2-stable201811. Sure, I was not aware the "reply to cover" option was not formal for this list, I'll do. (TIL: "reply to cover" is list CoC specific) ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/4] OvmfPkg: revert some untimely pushed VMW SVGA reverts
On 9/11/18 20:44, Laszlo Ersek wrote: Repo: https://github.com/lersek/edk2.git Branch: revert_revert_bz_1319 Not much to say here, I've written it up in <https://bugzilla.tianocore.org/show_bug.cgi?id=1319>. One way to verify this series quickly is: $ git diff 62ea70e31285..revert_revert_bz_1319 -- OvmfPkg/ [nothing] Thanks, and sorry about the churn Laszlo Cc: Anthony Perard Cc: Ard Biesheuvel Cc: Jordan Justen Cc: Julien Grall Cc: Philippe Mathieu-Daudé Cc: yuchenlin Laszlo Ersek (4): Reapply "OvmfPkg: VMWare SVGA display device register definitions" Reapply "OvmfPkg/QemuVideoDxe: Helper functions for unaligned port I/O." Reapply "OvmfPkg/QemuVideoDxe: VMWare SVGA device support" Reapply "OvmfPkg/QemuVideoDxe: list "UnalignedIoInternal.h" in the INF file" Series: Reviewed-by: Philippe Mathieu-Daudé ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 2/2] MdePkg/UefiDebugLibStdErr: Pass the correct buffer size.
On 5/11/18 13:54, Marvin Häuser wrote: The second argument of "UnicodeVSPrintAsciiFormat" is "BufferSize", which takes the size of the buffer in bytes. Replace the currently used MAX_DEBUG_MESSAGE_LENGTH reference, which is the buffer's length, with the actual buffer size. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marvin Haeuser Reviewed-by: Philippe Mathieu-Daudé --- MdePkg/Library/UefiDebugLibStdErr/DebugLib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MdePkg/Library/UefiDebugLibStdErr/DebugLib.c b/MdePkg/Library/UefiDebugLibStdErr/DebugLib.c index 6830a3caa1fe..837fb49b3a21 100644 --- a/MdePkg/Library/UefiDebugLibStdErr/DebugLib.c +++ b/MdePkg/Library/UefiDebugLibStdErr/DebugLib.c @@ -71,7 +71,7 @@ DebugPrint ( // Convert the DEBUG() message to a Unicode String // VA_START (Marker, Format); - UnicodeVSPrintAsciiFormat (Buffer, MAX_DEBUG_MESSAGE_LENGTH, Format, Marker); + UnicodeVSPrintAsciiFormat (Buffer, sizeof (Buffer), Format, Marker); VA_END (Marker); // ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/2] MdePkg/UefiDebugLibConOut: Pass the correct buffer size.
On 5/11/18 13:54, Marvin Häuser wrote: The second argument of "UnicodeVSPrintAsciiFormat" is "BufferSize", which takes the size of the buffer in bytes. Replace the currently used MAX_DEBUG_MESSAGE_LENGTH reference, which is the buffer's length, with the actual buffer size. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marvin Haeuser Reviewed-by: Philippe Mathieu-Daudé --- MdePkg/Library/UefiDebugLibConOut/DebugLib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MdePkg/Library/UefiDebugLibConOut/DebugLib.c b/MdePkg/Library/UefiDebugLibConOut/DebugLib.c index f04207c93fe8..5aaf106762ea 100644 --- a/MdePkg/Library/UefiDebugLibConOut/DebugLib.c +++ b/MdePkg/Library/UefiDebugLibConOut/DebugLib.c @@ -69,7 +69,7 @@ DebugPrint ( // Convert the DEBUG() message to a Unicode String // VA_START (Marker, Format); - UnicodeVSPrintAsciiFormat (Buffer, MAX_DEBUG_MESSAGE_LENGTH, Format, Marker); + UnicodeVSPrintAsciiFormat (Buffer, sizeof (Buffer), Format, Marker); VA_END (Marker); ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] ShellPkg/ShellLib: Fix potential NULL deference issue
On 7/11/18 10:36, Ruiyu Ni wrote:
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni
Cc: Jim Dailey
Cc: Hao A Wu
Reviewed-by: Philippe Mathieu-Daudé
---
ShellPkg/Library/UefiShellLib/UefiShellLib.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
index 580a1ee612..b17266d623 100644
--- a/ShellPkg/Library/UefiShellLib/UefiShellLib.c
+++ b/ShellPkg/Library/UefiShellLib/UefiShellLib.c
@@ -72,6 +72,7 @@ FullyQualifyPath(
{
CONST CHAR16 *WorkingPath;
CONST CHAR16 *InputPath;
+ CHAR16 *CharPtr;
CHAR16 *InputFileSystem;
UINTNFileSystemCharCount;
CHAR16 *FullyQualifiedPath;
@@ -131,7 +132,10 @@ FullyQualifyPath(
// truncate the new path after the file system part.
//
StrCpyS(FullyQualifiedPath, Size/sizeof(CHAR16), WorkingPath);
-*(StrStr(FullyQualifiedPath, L":") + 1) = CHAR_NULL;
+CharPtr = StrStr(FullyQualifiedPath, L":");
+if (CharPtr != NULL) {
+ *(CharPtr + 1) = CHAR_NULL;
+}
} else {
//
// Relative path: start with the working directory and append "\".
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdePkg/BaseIoLibIntrinsicArmVirt ARM: avoid double word loads and stores
On 7/11/18 14:38, Ard Biesheuvel wrote: On 7 November 2018 at 14:13, Ard Biesheuvel wrote: BaseIoLibIntrinsicArmVirt was created to prevent LTO from merging accesses to MMIO regions, resulting in instructions with multiple output registers that KVM on ARM cannot emulate (since the exception syndrome information that KVM relies on can only describe a single output register) However, using double word loads on ARM amounts to the same thing, and so code that relies on doing 64-bit MMIO to regions that are emulated under KVM (such as the GICv3 TYPER register) will still suffer from the original issue. So replace ldrd and strd with equivalent two instruction sequences. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel Please consider this patch with the hunk below appended --- MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.S | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.S b/MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.S index 3ad22bd5706d..0d802d6928d6 100644 --- a/MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.S +++ b/MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.S @@ -125,7 +125,8 @@ ASM_PFX(MmioWrite32Internal): // @return The value read. // ASM_PFX(MmioRead64Internal): - ldrdr0, r1, [r0] + ldr r1, [r0, #4] + ldr r0, [r0] Ard remembered me UEFI is little-endian only :) Thus this code is safe. With the hunk appended: Reviewed-by: Philippe Mathieu-Daudé dmb bx lr @@ -141,5 +142,6 @@ ASM_PFX(MmioRead64Internal): // ASM_PFX(MmioWrite64Internal): dmb st - strdr2, r3, [r0] + str r2, [r0] + str r3, [r0, #4] bx lr diff --git a/MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.asm b/MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.asm index e1a3d68a430c..deba8c1f0c59 100644 --- a/MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.asm +++ b/MdePkg/Library/BaseIoLibIntrinsic/Arm/ArmVirtMmio.asm @@ -127,7 +127,8 @@ MmioWrite32Internal ; @return The value read. ; MmioRead64Internal - ldrdr0, r1, [r0] + ldr r1, [r0, #4] + ldr r0, [r0] dmb bx lr @@ -143,7 +144,8 @@ MmioRead64Internal ; MmioWrite64Internal dmb st - strdr2, r3, [r0] + str r2, [r0] + str r3, [r0, #4] bx lr END ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-staging 08/19] IntelUndiPkg/GigUndiDxe: add missing VOID** cast
On 6/11/18 18:58, Ard Biesheuvel wrote:
Unlike Visual Studio, GCC does not permit implicit conversion between
a pointer-to-void-pointer and pointer to a typed pointer. So add the
explicit casts where necessary.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Reviewed-by: Philippe Mathieu-Daudé
---
IntelUndiPkg/GigUndiDxe/Hii.c | 8
IntelUndiPkg/GigUndiDxe/Init.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/IntelUndiPkg/GigUndiDxe/Hii.c b/IntelUndiPkg/GigUndiDxe/Hii.c
index 43c184cb03c8..a5d8ae207819 100644
--- a/IntelUndiPkg/GigUndiDxe/Hii.c
+++ b/IntelUndiPkg/GigUndiDxe/Hii.c
@@ -459,7 +459,7 @@ HiiOpenProtocol (
Status = gBS->LocateProtocol (
&gEfiHiiDatabaseProtocolGuid,
NULL,
- &UndiPrivateData->HiiDatabase
+ (VOID **)&UndiPrivateData->HiiDatabase
);
if (EFI_ERROR (Status)) {
DEBUGPRINT (CRITICAL, ("Error finding HII protocol: %r\n", Status));
@@ -472,7 +472,7 @@ HiiOpenProtocol (
Status = gBS->LocateProtocol (
&gEfiHiiStringProtocolGuid,
NULL,
- &UndiPrivateData->HiiString
+ (VOID **)&UndiPrivateData->HiiString
);
if (EFI_ERROR (Status)) {
DEBUGPRINT (CRITICAL, ("Error finding HII String protocol: %r\n",
Status));
@@ -485,7 +485,7 @@ HiiOpenProtocol (
Status = gBS->LocateProtocol (
&gEfiFormBrowser2ProtocolGuid,
NULL,
- &UndiPrivateData->FormBrowser2
+ (VOID **)&UndiPrivateData->FormBrowser2
);
if (EFI_ERROR (Status)) {
DEBUGPRINT (CRITICAL, ("Error finding HII form browser protocol: %r\n",
Status));
@@ -498,7 +498,7 @@ HiiOpenProtocol (
Status = gBS->LocateProtocol (
&gEfiHiiConfigRoutingProtocolGuid,
NULL,
- &UndiPrivateData->HiiConfigRouting
+ (VOID **)&UndiPrivateData->HiiConfigRouting
);
if (EFI_ERROR (Status)) {
DEBUGPRINT (CRITICAL, ("Error finding HII ConfigRouting protocol: %r\n",
Status));
diff --git a/IntelUndiPkg/GigUndiDxe/Init.c b/IntelUndiPkg/GigUndiDxe/Init.c
index f99734d72823..1de424c26fe2 100644
--- a/IntelUndiPkg/GigUndiDxe/Init.c
+++ b/IntelUndiPkg/GigUndiDxe/Init.c
@@ -177,7 +177,7 @@ GigAppendMac2DevPath (
Status = gBS->AllocatePool (
EfiBootServicesData, // EfiRuntimeServicesData,
TotalPathLen,
- &DevicePtr
+ (VOID **)&DevicePtr
);
if (Status != EFI_SUCCESS) {
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-staging 08/19] IntelUndiPkg/GigUndiDxe: add missing VOID** cast
On 6/11/18 18:58, Ard Biesheuvel wrote:
Unlike Visual Studio, GCC does not permit implicit conversion between
a pointer-to-void-pointer and pointer to a typed pointer. So add the
explicit casts where necessary.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Reviewed-by: Philippe Mathieu-Daudé
---
IntelUndiPkg/GigUndiDxe/Hii.c | 8
IntelUndiPkg/GigUndiDxe/Init.c | 2 +-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/IntelUndiPkg/GigUndiDxe/Hii.c b/IntelUndiPkg/GigUndiDxe/Hii.c
index 43c184cb03c8..a5d8ae207819 100644
--- a/IntelUndiPkg/GigUndiDxe/Hii.c
+++ b/IntelUndiPkg/GigUndiDxe/Hii.c
@@ -459,7 +459,7 @@ HiiOpenProtocol (
Status = gBS->LocateProtocol (
&gEfiHiiDatabaseProtocolGuid,
NULL,
- &UndiPrivateData->HiiDatabase
+ (VOID **)&UndiPrivateData->HiiDatabase
);
if (EFI_ERROR (Status)) {
DEBUGPRINT (CRITICAL, ("Error finding HII protocol: %r\n", Status));
@@ -472,7 +472,7 @@ HiiOpenProtocol (
Status = gBS->LocateProtocol (
&gEfiHiiStringProtocolGuid,
NULL,
- &UndiPrivateData->HiiString
+ (VOID **)&UndiPrivateData->HiiString
);
if (EFI_ERROR (Status)) {
DEBUGPRINT (CRITICAL, ("Error finding HII String protocol: %r\n",
Status));
@@ -485,7 +485,7 @@ HiiOpenProtocol (
Status = gBS->LocateProtocol (
&gEfiFormBrowser2ProtocolGuid,
NULL,
- &UndiPrivateData->FormBrowser2
+ (VOID **)&UndiPrivateData->FormBrowser2
);
if (EFI_ERROR (Status)) {
DEBUGPRINT (CRITICAL, ("Error finding HII form browser protocol: %r\n",
Status));
@@ -498,7 +498,7 @@ HiiOpenProtocol (
Status = gBS->LocateProtocol (
&gEfiHiiConfigRoutingProtocolGuid,
NULL,
- &UndiPrivateData->HiiConfigRouting
+ (VOID **)&UndiPrivateData->HiiConfigRouting
);
if (EFI_ERROR (Status)) {
DEBUGPRINT (CRITICAL, ("Error finding HII ConfigRouting protocol: %r\n",
Status));
diff --git a/IntelUndiPkg/GigUndiDxe/Init.c b/IntelUndiPkg/GigUndiDxe/Init.c
index f99734d72823..1de424c26fe2 100644
--- a/IntelUndiPkg/GigUndiDxe/Init.c
+++ b/IntelUndiPkg/GigUndiDxe/Init.c
@@ -177,7 +177,7 @@ GigAppendMac2DevPath (
Status = gBS->AllocatePool (
EfiBootServicesData, // EfiRuntimeServicesData,
TotalPathLen,
- &DevicePtr
+ (VOID **)&DevicePtr
);
if (Status != EFI_SUCCESS) {
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-staging 09/19] IntelUndiPkg/GigUndiDxe: add missing UINT8* cast
On 6/11/18 21:35, Ard Biesheuvel wrote:
On 6 November 2018 at 21:31, Philippe Mathieu-Daudé wrote:
Hi Ard,
On 6/11/18 18:58, Ard Biesheuvel wrote:
UINT8 and CHAR8 are not the same underlying type on all architectures,
so add an explicit cast where necessary.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
IntelUndiPkg/GigUndiDxe/Hii.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/IntelUndiPkg/GigUndiDxe/Hii.c b/IntelUndiPkg/GigUndiDxe/Hii.c
index a5d8ae207819..737a59fbbbac 100644
--- a/IntelUndiPkg/GigUndiDxe/Hii.c
+++ b/IntelUndiPkg/GigUndiDxe/Hii.c
@@ -817,7 +817,7 @@ HiiSetMenuStrings (
Status = ReadPbaString (
&UndiPrivateData->NicInfo,
- PBAString8,
+ (UINT8 *)PBAString8,
MAX_PBA_STR_LENGTH
);
if (Status == EFI_SUCCESS) {
I'm not sure why ReadPbaString() takes UINT8* instead of CHAR8*.
Having the device part number stored into a CHAR8[] seems correct, what do
you think?
I guess. But that just moves the bubble in the waterbed to elsewhere:
EFI_STATUS
ReadPbaString (
IN GIG_DRIVER_DATA *GigAdapter,
IN OUT UINT8 * PbaNumber,
IN UINT32 PbaNumberSize
)
{
if (e1000_read_pba_string (&GigAdapter->Hw, PbaNumber,
PbaNumberSize) == E1000_SUCCESS) {
return EFI_SUCCESS;
} else {
return EFI_DEVICE_ERROR;
}
}
and
$ git grep e1000_read_pba_string
IntelUndiPkg/GigUndiDxe/e1000.c: if (e1000_read_pba_string
(&GigAdapter->Hw, PbaNumber, PbaNumberSize) == E1000_SUCCESS) {
IntelUndiPkg/GigUndiDxe/e1000_api.c: * e1000_read_pba_string - Read
device part number string
IntelUndiPkg/GigUndiDxe/e1000_api.c:s32 e1000_read_pba_string(struct
e1000_hw *hw, u8 *pba_num, u32 pba_num_size)
IntelUndiPkg/GigUndiDxe/e1000_api.c:return
e1000_read_pba_string_generic(hw, pba_num, pba_num_size);
IntelUndiPkg/GigUndiDxe/e1000_api.h:s32 e1000_read_pba_string(struct
e1000_hw *hw, u8 *pba_num, u32 pba_num_size);
IntelUndiPkg/GigUndiDxe/e1000_nvm.c: * e1000_read_pba_string_generic
- Read device part number
IntelUndiPkg/GigUndiDxe/e1000_nvm.c:s32
e1000_read_pba_string_generic(struct e1000_hw *hw, u8 *pba_num,
IntelUndiPkg/GigUndiDxe/e1000_nvm.c:
DEBUGFUNC("e1000_read_pba_string_generic");
IntelUndiPkg/GigUndiDxe/e1000_nvm.h:s32
e1000_read_pba_string_generic(struct e1000_hw *hw, u8 *pba_num,
(unless you want to add a cast in ReadPbaString() instead)
Hmm I now see the inconsistency.
Since the goal of this series is not to sort it out, then I'm OK with
your patch.
Reviewed-by: Philippe Mathieu-Daudé
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-staging 19/19] IntelUndiPkg/GigUndiDxe: remove or reorganize unused variables
On 6/11/18 18:58, Ard Biesheuvel wrote:
Drop variables that are assigned but never used, or move them into
a conditional preprocessor block if the only references occur from
such code.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c | 2 --
IntelUndiPkg/GigUndiDxe/HiiInternalLib.c| 2 --
IntelUndiPkg/GigUndiDxe/e1000.c | 16 +++-
3 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
b/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
index f6152cd24c59..af8aaa797e68 100644
--- a/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
+++ b/IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c
@@ -1123,11 +1123,9 @@ GigUndiRunPhyLoopback (
UINT64 FreeTxBuffer[DEFAULT_TX_DESCRIPTORS];
UINT32 j;
UINT32 i;
- struct e1000_hw *Hw;
Status = EFI_SUCCESS;
j = 0;
- Hw = &GigAdapterInfo->Hw;
while (j < PHY_LOOPBACK_ITERATIONS) {
Status = E1000Transmit (
diff --git a/IntelUndiPkg/GigUndiDxe/HiiInternalLib.c
b/IntelUndiPkg/GigUndiDxe/HiiInternalLib.c
index 2aacb63ca158..690d8314be74 100644
--- a/IntelUndiPkg/GigUndiDxe/HiiInternalLib.c
+++ b/IntelUndiPkg/GigUndiDxe/HiiInternalLib.c
@@ -197,7 +197,6 @@ GetNextRequestElement (
)
{
EFI_STRING StringPtr;
- EFI_STRING TmpPtr;
EFI_STATUS Status;
UINTN Length;
UINT8 *TmpBuffer;
@@ -227,7 +226,6 @@ GetNextRequestElement (
}
// Back up the header of one
- TmpPtr = StringPtr;
StringPtr += StrLen (L"OFFSET=");
diff --git a/IntelUndiPkg/GigUndiDxe/e1000.c b/IntelUndiPkg/GigUndiDxe/e1000.c
index 28c900e3ad63..3d4a21c62d77 100644
--- a/IntelUndiPkg/GigUndiDxe/e1000.c
+++ b/IntelUndiPkg/GigUndiDxe/e1000.c
@@ -412,7 +412,6 @@ E1000Transmit (
E1000_TRANSMIT_DESCRIPTOR *TransmitDescriptor;
UINT32 i;
INT16 WaitMsec;
- EFI_STATUS Status;
UNDI_DMA_MAPPING*TxBufMapping;
TxBufMapping = &GigAdapter->TxBufferMappings[GigAdapter->CurTxInd];
@@ -483,7 +482,7 @@ E1000Transmit (
TxBufMapping->Size = TxBuffer->DataLen + TxBuffer->MediaheaderLen;
// Make the Tx buffer accessible for adapter over DMA
-Status = UndiDmaMapMemoryRead (
+UndiDmaMapMemoryRead (
GigAdapter->PciIo,
TxBufMapping
);
@@ -594,20 +593,21 @@ E1000Receive (
E1000_RECEIVE_DESCRIPTOR *ReceiveDescriptor;
ETHER_HEADER *EtherHeader;
PXE_STATCODE StatCode;
- UINT16i;
UINT16TempLen;
+#if (DBG_LVL & RX)
+ UINT16i;
UINT8 * PacketPtr;
#if (DBG_LVL & CRITICAL)
-#if (DBG_LVL & RX)
UINT32 Rdh;
UINT32 Rdt;
-#endif /* (DBG_LVL & RX) */
+
#endif /* (DBG_LVL & CRITICAL) */
+ i = 0;
+#endif /* (DBG_LVL & RX) */
This context is easier to understand when looking at the whole function.
Reviewed-by: Philippe Mathieu-Daudé
PacketType = PXE_FRAME_TYPE_NONE;
StatCode= PXE_STATCODE_NO_DATA;
- i = 0;
// acknowledge the interrupts
E1000_READ_REG (&GigAdapter->Hw, E1000_ICR);
@@ -679,9 +679,9 @@ E1000Receive (
TempLen
);
+#if (DBG_LVL & RX)
PacketPtr = (UINT8 *) (UINTN) CpbReceive->BufferAddr;
-#if (DBG_LVL & RX)
DEBUGPRINT (RX, ("Packet Data \n"));
for (i = 0; i < TempLen; i++) {
DEBUGPRINT (RX, ("%x ", PacketPtr[i]));
@@ -1569,13 +1569,11 @@ E1000Inititialize (
GIG_DRIVER_DATA *GigAdapter
)
{
- UINT32 * TempBar;
PXE_STATCODE PxeStatcode;
DEBUGPRINT (E1000, ("E1000Inititialize\n"));
PxeStatcode = PXE_STATCODE_SUCCESS;
- TempBar = NULL;
ZeroMem (
(VOID *)(UINTN)GigAdapter->RxRing.UnmappedAddress,
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-staging 16/19] IntelUndiPkg/GigUndiDxe: fix incorrect indentation
On 6/11/18 18:58, Ard Biesheuvel wrote:
Silence a 'misleading indentation' GCC warning by fixing the
incorrect indentation.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Reviewed-by: Philippe Mathieu-Daudé
Tested-by: Philippe Mathieu-Daudé
---
IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c
b/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c
index e9fc5394ab28..6ce9ac3c5195 100644
--- a/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c
+++ b/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c
@@ -1102,13 +1102,13 @@ STATIC s32 e1000_check_for_copper_link_ich8lan(struct
e1000_hw *hw)
if (!mac->get_link_status)
return E1000_SUCCESS;
- /* First we want to see if the MII Status Register reports
-* link. If so, then we want to get the current speed/duplex
-* of the PHY.
-*/
- ret_val = e1000_phy_has_link_generic(hw, 1, 0, &link);
- if (ret_val)
- return ret_val;
+ /* First we want to see if the MII Status Register reports
+* link. If so, then we want to get the current speed/duplex
+* of the PHY.
+*/
+ ret_val = e1000_phy_has_link_generic(hw, 1, 0, &link);
+ if (ret_val)
+ return ret_val;
if (hw->mac.type == e1000_pchlan) {
ret_val = e1000_k1_gig_workaround_hv(hw, link);
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-staging 15/19] IntelUndiPkg/GigUndiDxe: remove forward declaration of non-existent function
On 6/11/18 18:58, Ard Biesheuvel wrote: Remove the forward declaration of e1000_disable_ulp_lpt_lp (), which is never defined anywhere in the code. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel Reviewed-by: Philippe Mathieu-Daudé Tested-by: Philippe Mathieu-Daudé (Not tested with Visual Studio) --- IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c b/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c index 7669630a5c03..e9fc5394ab28 100644 --- a/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c +++ b/IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c @@ -103,9 +103,6 @@ STATIC s32 e1000_reset_hw_ich8lan(struct e1000_hw *hw); STATIC s32 e1000_init_hw_ich8lan(struct e1000_hw *hw); STATIC s32 e1000_setup_link_ich8lan(struct e1000_hw *hw); STATIC s32 e1000_setup_copper_link_ich8lan(struct e1000_hw *hw); -#if !defined(NO_ULP_IN_S5_SUPPORT) -STATIC s32 e1000_disable_ulp_lpt_lp(struct e1000_hw *hw, bool force); -#endif /* !NO_ULP_IN_S5_SUPPORT && !ULP_IN_D0_SUPPORT */ STATIC s32 e1000_setup_copper_link_pch_lpt(struct e1000_hw *hw); STATIC s32 e1000_get_link_up_info_ich8lan(struct e1000_hw *hw, u16 *speed, u16 *duplex); ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-staging 13/19] IntelUndiPkg/GigUndiDxe: don't take address of cast expression
On 6/11/18 18:58, Ard Biesheuvel wrote:
Taking the address of a cast expression is not permitted in C. Instead,
take the address of the variable, and cast the pointer to the desired
pointer type.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Reviewed-by: Philippe Mathieu-Daudé
---
IntelUndiPkg/GigUndiDxe/e1000.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/IntelUndiPkg/GigUndiDxe/e1000.c b/IntelUndiPkg/GigUndiDxe/e1000.c
index 4c9a06b8cf73..28c900e3ad63 100644
--- a/IntelUndiPkg/GigUndiDxe/e1000.c
+++ b/IntelUndiPkg/GigUndiDxe/e1000.c
@@ -1107,7 +1107,7 @@ E1000TxRxConfigure (
// Set the MemPtr to the high dword of the rx_ring so we can store it in
RDBAH0.
// Right shifts do not seem to work with the EFI compiler so we do it like
this for now.
MemAddr = (UINT64) (UINTN) GigAdapter->RxRing.PhysicalAddress;
- MemPtr = &((UINT32) MemAddr);
+ MemPtr = (UINT32 *)&MemAddr;
MemPtr++;
E1000_WRITE_REG (&GigAdapter->Hw, E1000_RDBAH (0), *MemPtr);
@@ -1185,7 +1185,7 @@ E1000TxRxConfigure (
E1000_WRITE_REG (&GigAdapter->Hw, E1000_TDBAL (0), (UINT32) (UINTN) (GigAdapter->TxRing.PhysicalAddress));
MemAddr = (UINT64) (UINTN) GigAdapter->TxRing.PhysicalAddress;
- MemPtr = &((UINT32) MemAddr);
+ MemPtr = (UINT32 *)&MemAddr;
MemPtr++;
E1000_WRITE_REG (&GigAdapter->Hw, E1000_TDBAH (0), *MemPtr);
DEBUGPRINT (E1000, ("TdBah0 %X\n", *MemPtr));
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-staging 12/19] IntelUndiPkg/GigUndiDxe: cast E1000MemCopy () args to correct pointer type
On 6/11/18 18:58, Ard Biesheuvel wrote: E1000MemCopy () takes UINT8 pointers not INT8 pointers, so cast the arguments to the correct type. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel Reviewed-by: Philippe Mathieu-Daudé --- IntelUndiPkg/GigUndiDxe/e1000.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/IntelUndiPkg/GigUndiDxe/e1000.c b/IntelUndiPkg/GigUndiDxe/e1000.c index 1f08a5d67b2d..4c9a06b8cf73 100644 --- a/IntelUndiPkg/GigUndiDxe/e1000.c +++ b/IntelUndiPkg/GigUndiDxe/e1000.c @@ -674,8 +674,8 @@ E1000Receive ( // Copy the packet from our list to the EFI buffer. E1000MemCopy ( -(INT8 *) (UINTN) CpbReceive->BufferAddr, -(INT8 *) (UINTN) ReceiveDescriptor->buffer_addr, +(UINT8 *) (UINTN) CpbReceive->BufferAddr, +(UINT8 *) (UINTN) ReceiveDescriptor->buffer_addr, TempLen ); ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-staging 10/19] IntelUndiPkg/GigUndiDxe: add missing braces to GUID literals
On 6/11/18 18:58, Ard Biesheuvel wrote:
The Data4 member of the GUID/EFI_GUID struct type is an array of
UINT8, so literals require two sets of { } braces. Add them where
missing.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Reviewed-by: Philippe Mathieu-Daudé
---
IntelUndiPkg/GigUndiDxe/NVDataStruc.h | 4 ++--
IntelUndiPkg/GigUndiDxe/StartStop.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
b/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
index bd7d4defc9a3..72f6a95ccb6d 100644
--- a/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
+++ b/IntelUndiPkg/GigUndiDxe/NVDataStruc.h
@@ -34,12 +34,12 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE.
#define E1000_HII_FORM_GUID \
{ \
-0x77f2ea2f, 0x4312, 0x4569, 0x85, 0xc4, 0x58, 0x3a, 0xcd, 0x8d, 0xb7, 0xe2
\
+0x77f2ea2f, 0x4312, 0x4569, { 0x85, 0xc4, 0x58, 0x3a, 0xcd, 0x8d, 0xb7,
0xe2 } \
}
#define E1000_HII_DATA_GUID \
{ \
-0xa31abb16, 0xc627, 0x475b, 0x98, 0x8e, 0x7e, 0xe0, 0x77, 0x67, 0x40, 0xf3
\
+0xa31abb16, 0xc627, 0x475b, { 0x98, 0x8e, 0x7e, 0xe0, 0x77, 0x67, 0x40,
0xf3 } \
}
diff --git a/IntelUndiPkg/GigUndiDxe/StartStop.h b/IntelUndiPkg/GigUndiDxe/StartStop.h
index 255f17aabaa4..b29a5002bb8e 100644
--- a/IntelUndiPkg/GigUndiDxe/StartStop.h
+++ b/IntelUndiPkg/GigUndiDxe/StartStop.h
@@ -32,8 +32,8 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
#include "e1000.h"
#define EFI_DRIVER_STOP_PROTOCOL_GUID \
-{ 0x34d59603, 0x1428, 0x4429, 0xa4, 0x14, 0xe6, 0xb3, \
-0xb5, 0xfd, 0x7d, 0xc1 }
+{ 0x34d59603, 0x1428, 0x4429, { 0xa4, 0x14, 0xe6, 0xb3, \
+0xb5, 0xfd, 0x7d, 0xc1 } }
typedef struct EFI_DRIVER_STOP_PROTOCOL_S EFI_DRIVER_STOP_PROTOCOL;
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-staging 09/19] IntelUndiPkg/GigUndiDxe: add missing UINT8* cast
Hi Ard,
On 6/11/18 18:58, Ard Biesheuvel wrote:
UINT8 and CHAR8 are not the same underlying type on all architectures,
so add an explicit cast where necessary.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
IntelUndiPkg/GigUndiDxe/Hii.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/IntelUndiPkg/GigUndiDxe/Hii.c b/IntelUndiPkg/GigUndiDxe/Hii.c
index a5d8ae207819..737a59fbbbac 100644
--- a/IntelUndiPkg/GigUndiDxe/Hii.c
+++ b/IntelUndiPkg/GigUndiDxe/Hii.c
@@ -817,7 +817,7 @@ HiiSetMenuStrings (
Status = ReadPbaString (
&UndiPrivateData->NicInfo,
- PBAString8,
+ (UINT8 *)PBAString8,
MAX_PBA_STR_LENGTH
);
if (Status == EFI_SUCCESS) {
I'm not sure why ReadPbaString() takes UINT8* instead of CHAR8*.
Having the device part number stored into a CHAR8[] seems correct, what
do you think?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-staging 04/19] IntelUndiPkg/GigUndiDxe: consistently use forward slashes as path separators
On 6/11/18 18:58, Ard Biesheuvel wrote: Replace backslashes in paths with forward slashes to be compatible with non-Windows OSes. I thought the Windows format expected escaped backslashes... Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel Reviewed-by: Philippe Mathieu-Daudé --- IntelUndiPkg/GigUndiDxe/Decode.c | 2 +- IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf | 14 +++--- IntelUndiPkg/GigUndiDxe/e1000_osdep.h | 4 ++-- 3 files changed, 10 insertions(+), 10 deletions(-) diff --git a/IntelUndiPkg/GigUndiDxe/Decode.c b/IntelUndiPkg/GigUndiDxe/Decode.c index 14060db0d050..9f8a5a8c1c81 100644 --- a/IntelUndiPkg/GigUndiDxe/Decode.c +++ b/IntelUndiPkg/GigUndiDxe/Decode.c @@ -27,7 +27,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ***/ #include "e1000.h" -#include +#include /** This routine determines the operational state of the UNDI. It updates the state flags in the Command Descriptor Block based on information derived from the GigAdapter instance data. diff --git a/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf b/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf index 0e4462733df6..6c195872c00f 100644 --- a/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf +++ b/IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf @@ -115,13 +115,13 @@ AdapterInformation.c AdapterInformation.h Version.h -wol\wol.h -wol\wol.c -wol\wolimpl.h -wol\wolimpl.c -wol\wolfamily.c -wol\wolinfo.c -wol\wol_1G.c +wol/wol.h +wol/wol.c +wol/wolimpl.h +wol/wolimpl.c +wol/wolfamily.c +wol/wolinfo.c +wol/wol_1G.c [sources.X64] diff --git a/IntelUndiPkg/GigUndiDxe/e1000_osdep.h b/IntelUndiPkg/GigUndiDxe/e1000_osdep.h index 01c0843a2c9a..4408b409a445 100644 --- a/IntelUndiPkg/GigUndiDxe/e1000_osdep.h +++ b/IntelUndiPkg/GigUndiDxe/e1000_osdep.h @@ -31,8 +31,8 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. #include #include -#include -#include +#include +#include #pragma warning(disable : 4244) #pragma warning(disable : 4206) ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-staging 03/19] IntelUndiPkg/GigUndiDxe: consistently use lowercase for e1000 in filenames
On 6/11/18 18:58, Ard Biesheuvel wrote:
Rename E1000.[ch] and E1000_osdep.[ch] to all lowercase, and replace
all #include references with lowercase ones as well.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Reviewed-by: Philippe Mathieu-Daudé
---
IntelUndiPkg/GigUndiDxe/AdapterInformation.c | 2 +-
IntelUndiPkg/GigUndiDxe/ComponentName.c | 2 +-
IntelUndiPkg/GigUndiDxe/Decode.c | 2 +-
IntelUndiPkg/GigUndiDxe/DeviceSupport.h | 2 +-
IntelUndiPkg/GigUndiDxe/Dma.c| 2 +-
IntelUndiPkg/GigUndiDxe/DriverConfiguration.c| 2 +-
IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c | 2 +-
IntelUndiPkg/GigUndiDxe/DriverHealth.c | 2 +-
IntelUndiPkg/GigUndiDxe/EepromConfig.h | 2 +-
IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf | 8
IntelUndiPkg/GigUndiDxe/Init.c | 2 +-
IntelUndiPkg/GigUndiDxe/StartStop.c | 2 +-
IntelUndiPkg/GigUndiDxe/StartStop.h | 2 +-
IntelUndiPkg/GigUndiDxe/{E1000.c => e1000.c} | 2 +-
IntelUndiPkg/GigUndiDxe/{E1000.h => e1000.h} | 0
IntelUndiPkg/GigUndiDxe/{E1000_osdep.c => e1000_osdep.c} | 2 +-
IntelUndiPkg/GigUndiDxe/{E1000_osdep.h => e1000_osdep.h} | 0
IntelUndiPkg/GigUndiDxe/wol/wolimpl.h| 2 +-
18 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
b/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
index b0320b11839b..8918c538e447 100644
--- a/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
+++ b/IntelUndiPkg/GigUndiDxe/AdapterInformation.c
@@ -28,7 +28,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
***/
#include "Uefi.h"
-#include "E1000.h"
+#include "e1000.h"
#include "AdapterInformation.h"
diff --git a/IntelUndiPkg/GigUndiDxe/ComponentName.c
b/IntelUndiPkg/GigUndiDxe/ComponentName.c
index 1473bfbed0af..70baf00f4a5d 100644
--- a/IntelUndiPkg/GigUndiDxe/ComponentName.c
+++ b/IntelUndiPkg/GigUndiDxe/ComponentName.c
@@ -26,7 +26,7 @@ OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
***/
-#include "E1000.h"
+#include "e1000.h"
#include "ComponentName.h"
#include "DeviceSupport.h"
diff --git a/IntelUndiPkg/GigUndiDxe/Decode.c b/IntelUndiPkg/GigUndiDxe/Decode.c
index 88e8be315bd1..14060db0d050 100644
--- a/IntelUndiPkg/GigUndiDxe/Decode.c
+++ b/IntelUndiPkg/GigUndiDxe/Decode.c
@@ -26,7 +26,7 @@ OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
***/
-#include "E1000.h"
+#include "e1000.h"
#include
/** This routine determines the operational state of the UNDI. It updates the state flags in the
diff --git a/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
b/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
index f309044d9b9d..e156b587f6a7 100644
--- a/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
+++ b/IntelUndiPkg/GigUndiDxe/DeviceSupport.h
@@ -29,7 +29,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
#ifndef DEVICE_SUPPORT_H_
#define DEVICE_SUPPORT_H_
-#include "E1000.h"
+#include "e1000.h"
typedef struct BRAND_STRUCT_S BRAND_STRUCT;
diff --git a/IntelUndiPkg/GigUndiDxe/Dma.c b/IntelUndiPkg/GigUndiDxe/Dma.c
index 76a3fcf69601..bf94c1e2fd54 100644
--- a/IntelUndiPkg/GigUndiDxe/Dma.c
+++ b/IntelUndiPkg/GigUndiDxe/Dma.c
@@ -27,7 +27,7 @@ OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
***/
-#include "E1000.h"
+#include "e1000.h"
#include "Dma.h"
diff --git a/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c b/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
index 118c1b2b9b04..20d40ab672ef 100644
--- a/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
+++ b/IntelUndiPkg/GigUndiDxe/DriverConfiguration.c
@@ -26,7 +26,7 @@ OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY
WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
***/
-#include "E1000.h"
+#include "e1000.h"
#include "DriverConfiguration.h"
/* Protocol structure tentative definition */
diff --git a/IntelUndiPkg/GigUn
Re: [edk2] [PATCH edk2-staging 02/19] IntelUndiPkg: remove EOF markers
On 6/11/18 18:58, Ard Biesheuvel wrote: Remove the Ctrl-Z markers at the end of each file: these break the GCC build on Linux. Weird... Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel Reviewed-by: Philippe Mathieu-Daudé --- IntelUndiPkg/GigUndiDxe/AdapterInformation.c | 1 - IntelUndiPkg/GigUndiDxe/AdapterInformation.h | 1 - IntelUndiPkg/GigUndiDxe/Brand.c | 1 - IntelUndiPkg/GigUndiDxe/ComponentName.c | 1 - IntelUndiPkg/GigUndiDxe/ComponentName.h | 1 - IntelUndiPkg/GigUndiDxe/Decode.c | 1 - IntelUndiPkg/GigUndiDxe/Decode.h | 1 - IntelUndiPkg/GigUndiDxe/DeviceSupport.c | 1 - IntelUndiPkg/GigUndiDxe/DeviceSupport.h | 1 - IntelUndiPkg/GigUndiDxe/Dma.c | 1 - IntelUndiPkg/GigUndiDxe/Dma.h | 1 - IntelUndiPkg/GigUndiDxe/DriverConfiguration.c | 1 - IntelUndiPkg/GigUndiDxe/DriverConfiguration.h | 1 - IntelUndiPkg/GigUndiDxe/DriverDiagnostics.c | 1 - IntelUndiPkg/GigUndiDxe/DriverDiagnostics.h | 1 - IntelUndiPkg/GigUndiDxe/DriverHealth.c| 1 - IntelUndiPkg/GigUndiDxe/E1000.c | 1 - IntelUndiPkg/GigUndiDxe/E1000.h | 1 - IntelUndiPkg/GigUndiDxe/E1000_osdep.c | 1 - IntelUndiPkg/GigUndiDxe/E1000_osdep.h | 1 - IntelUndiPkg/GigUndiDxe/EepromConfig.c| 1 - IntelUndiPkg/GigUndiDxe/EepromConfig.h| 1 - IntelUndiPkg/GigUndiDxe/GigUndiDxe.inf| 1 - IntelUndiPkg/GigUndiDxe/Hii.c | 1 - IntelUndiPkg/GigUndiDxe/Hii.h | 1 - IntelUndiPkg/GigUndiDxe/HiiInternalLib.c | 1 - IntelUndiPkg/GigUndiDxe/HiiInternalLib.h | 1 - IntelUndiPkg/GigUndiDxe/Init.c| 1 - IntelUndiPkg/GigUndiDxe/Init.h| 1 - IntelUndiPkg/GigUndiDxe/Inventory.vfr | 1 - IntelUndiPkg/GigUndiDxe/NVDataStruc.h | 1 - IntelUndiPkg/GigUndiDxe/StartStop.c | 1 - IntelUndiPkg/GigUndiDxe/StartStop.h | 1 - IntelUndiPkg/GigUndiDxe/Version.h | 1 - IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.c | 1 - IntelUndiPkg/GigUndiDxe/e1000_80003es2lan.h | 1 - IntelUndiPkg/GigUndiDxe/e1000_82571.c | 1 - IntelUndiPkg/GigUndiDxe/e1000_82571.h | 1 - IntelUndiPkg/GigUndiDxe/e1000_82575.c | 1 - IntelUndiPkg/GigUndiDxe/e1000_82575.h | 1 - IntelUndiPkg/GigUndiDxe/e1000_api.c | 1 - IntelUndiPkg/GigUndiDxe/e1000_api.h | 1 - IntelUndiPkg/GigUndiDxe/e1000_defines.h | 1 - IntelUndiPkg/GigUndiDxe/e1000_hw.h| 1 - IntelUndiPkg/GigUndiDxe/e1000_i210.c | 1 - IntelUndiPkg/GigUndiDxe/e1000_i210.h | 1 - IntelUndiPkg/GigUndiDxe/e1000_ich8lan.c | 1 - IntelUndiPkg/GigUndiDxe/e1000_ich8lan.h | 1 - IntelUndiPkg/GigUndiDxe/e1000_mac.c | 1 - IntelUndiPkg/GigUndiDxe/e1000_mac.h | 1 - IntelUndiPkg/GigUndiDxe/e1000_manage.c| 1 - IntelUndiPkg/GigUndiDxe/e1000_manage.h| 1 - IntelUndiPkg/GigUndiDxe/e1000_nvm.c | 1 - IntelUndiPkg/GigUndiDxe/e1000_nvm.h | 1 - IntelUndiPkg/GigUndiDxe/e1000_phy.c | 1 - IntelUndiPkg/GigUndiDxe/e1000_phy.h | 1 - IntelUndiPkg/GigUndiDxe/e1000_regs.h | 1 - IntelUndiPkg/GigUndiDxe/wol/wol.c | 1 - IntelUndiPkg/GigUndiDxe/wol/wol.h | 1 - IntelUndiPkg/GigUndiDxe/wol/wol_1G.c | 1 - IntelUndiPkg/GigUndiDxe/wol/wolfamily.c | 1 - IntelUndiPkg/GigUndiDxe/wol/wolimpl.c | 1 - IntelUndiPkg/GigUndiDxe/wol/wolimpl.h | 1 - IntelUndiPkg/GigUndiDxe/wol/wolinfo.c | 1 - IntelUndiPkg/I40eUndiDxe/AdapterInformation.c | 1 - IntelUndiPkg/I40eUndiDxe/AdapterInformation.h | 1 - IntelUndiPkg/I40eUndiDxe/Brand.c | 1 - IntelUndiPkg/I40eUndiDxe/ComponentName.c | 1 - IntelUndiPkg/I40eUndiDxe/ComponentName.h | 1 - IntelUndiPkg/I40eUndiDxe/Decode.c | 1 - IntelUndiPkg/I40eUndiDxe/Decode.h | 1 - IntelUndiPkg/I40eUndiDxe/DeviceSupport.c | 1 - IntelUndiPkg/I40eUndiDxe/DeviceSupport.h | 1 - IntelUndiPkg/I40eUndiDxe/Dma.c| 1 - IntelUndiPkg/I40eUndiDxe/Dma.h| 1 - IntelUndiPkg/I40eUndiDxe/DriverDiagnostics.c | 1 - IntelUndiPkg/I40eUndiDxe/DriverDiagnostics.h | 1 - IntelUndiPkg/I40eUndiDxe/DriverHealth.c | 1 - IntelUndiPkg/I40eUndiDxe/DriverHealthCommon.h | 1 - IntelUndiPkg/I40eUndiDxe/EepromConfig.c | 1 - IntelUndiPkg/I40eUndiDxe/EepromConfig.h | 1 - IntelUndiPkg/I40eUndiDxe/Hii.c| 1 - IntelUndiPkg/I40eUndiDxe/Hii.h| 1 - IntelUndiPkg/I40eUndiDxe/HiiInternalLib.c | 1 - IntelUndiPkg/I40eUndiDxe/HiiInternalLib.h | 1 - IntelUndiPkg/I40eUndiDxe/I40e.c | 1 - IntelUndiPkg/I40eUndiDxe/I40e.h | 1 - IntelUndiPkg
Re: [edk2] [PATCH v2 5/5] OvmfPkg: simply use the Bochs interface for vmsvga
On 6/11/18 14:36, Laszlo Ersek wrote: On 11/06/18 12:47, Laszlo Ersek wrote: ... While we discuss this, I'll go ahead and push the first four patches. The code being reverted is dead anyway. I'll report back about the commit hashes. Before pushing the first four patches, I regression-tested them as well. Using: Cirrus, stdvga, and QXL. My QEMU version was v3.0.0-1763-gb2f7a038bb4c. The machine type was "pc-q35-3.0". For the first four patches: - Regression-tested-by: Laszlo Ersek , - pushed them as commit range 62ea70e31285..328409ce8de7. Thanks Laszlo! A bit late, but 1-4 reviewed too. Thanks Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/4] OvmfPkg: simply use the Bochs interface for vmsvga
Hi Yu-chen Lin, On 24/10/18 8:40, yuchen...@synology.com wrote: From: yuchenlin In this series, replace the original vmsvga driver to Bochs interface. This is the 'v2' of your previous patch 'OvmfPkg: initialize bochs when initializing vmsvga': https://lists.01.org/pipermail/edk2-devel/2018-October/031235.html Keeping different versions and referencing previous series helps when reviewing. Simply revert vmsvga driver implementation. After it, use Bochs interface for initializing vmsvga. Because of the PCI BARs difference between std vga and vmsvga. We can not simply recognize the "QEMU VMWare SVGA" as the QEMU_VIDEO_BOCHS_MMIO variant. BAR |std vga | vmsvga - 0| Framebuffer | I/O space 1| Reserved | Framebuffer 2| MMIO | FIFO To overcome this problem, we remain variant QEMU_VIDEO_VMWARE_SVGA, and use it for: (1) Get framebuffer from correct PCI BAR (2) Prevent using BAR2 for MMIO We have tested on qemu before and after commit 104bd1dc70 and all worked. Did you also test against QEMU v2.9.1? Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: yuchenlin yuchenlin (4): Revert "OvmfPkg/QemuVideoDxe: VMWare SVGA device support" Revert "OvmfPkg/QemuVideoDxe: Helper functions for unaligned port I/O." Revert "OvmfPkg/QemuVideoDxe: list "UnalignedIoInternal.h" in the INF file" OvmfPkg: simply use the Bochs interface for vmsvga OvmfPkg/QemuVideoDxe/Driver.c | 137 ++- OvmfPkg/QemuVideoDxe/Gop.c| 68 +--- OvmfPkg/QemuVideoDxe/Initialize.c | 157 -- OvmfPkg/QemuVideoDxe/Qemu.h | 27 --- OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf | 7 - OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c | 70 OvmfPkg/QemuVideoDxe/UnalignedIoIcc.c | 80 - OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h| 59 --- OvmfPkg/QemuVideoDxe/UnalignedIoMsc.c | 78 - OvmfPkg/QemuVideoDxe/UnalignedIoUnsupported.c | 66 10 files changed, 17 insertions(+), 732 deletions(-) delete mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoGcc.c delete mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoIcc.c delete mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoInternal.h delete mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoMsc.c delete mode 100644 OvmfPkg/QemuVideoDxe/UnalignedIoUnsupported.c ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 1/4] Revert "OvmfPkg/QemuVideoDxe: VMWare SVGA device support"
Hi Yu-chen Lin,
On 24/10/18 8:40, yuchen...@synology.com wrote:
From: yuchenlin
This reverts commit c137d95081690d4877fbeb5f1856972e84ac32f2.
Can we have a comment here about why we need to revert this patch?
(same for patches 2 and 3).
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin
---
OvmfPkg/QemuVideoDxe/Driver.c | 135 +
OvmfPkg/QemuVideoDxe/Gop.c| 65 +
OvmfPkg/QemuVideoDxe/Initialize.c | 157 --
OvmfPkg/QemuVideoDxe/Qemu.h | 29 --
4 files changed, 7 insertions(+), 379 deletions(-)
diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
index 73eb2cad05..2304afd1e6 100644
--- a/OvmfPkg/QemuVideoDxe/Driver.c
+++ b/OvmfPkg/QemuVideoDxe/Driver.c
@@ -14,10 +14,8 @@
**/
-#include
-#include
#include "Qemu.h"
-#include "UnalignedIoInternal.h"
+#include
EFI_DRIVER_BINDING_PROTOCOL gQemuVideoDriverBinding = {
QemuVideoControllerDriverSupported,
@@ -71,12 +69,6 @@ QEMU_VIDEO_CARD gQemuVideoCardList[] = {
0x1050,
QEMU_VIDEO_BOCHS_MMIO,
L"QEMU VirtIO VGA"
-},{
-PCI_CLASS_DISPLAY_VGA,
-VMWARE_PCI_VENDOR_ID_VMWARE,
-VMWARE_PCI_DEVICE_ID_VMWARE_SVGA2,
-QEMU_VIDEO_VMWARE_SVGA,
-L"QEMU VMWare SVGA"
},{
0 /* end of list */
}
@@ -264,7 +256,6 @@ QemuVideoControllerDriverStart (
goto ClosePciIo;
}
Private->Variant = Card->Variant;
- Private->FrameBufferVramBarIndex = PCI_BAR_IDX0;
//
// IsQxl is based on the detected Card->Variant, which at a later point
might
@@ -339,58 +330,6 @@ QemuVideoControllerDriverStart (
}
}
- //
- // Check if accessing Vmware SVGA interface works
- //
- if (Private->Variant == QEMU_VIDEO_VMWARE_SVGA) {
-EFI_ACPI_ADDRESS_SPACE_DESCRIPTOR *IoDesc;
-UINT32TargetId;
-UINT32SvgaIdRead;
-
-IoDesc = NULL;
-Status = Private->PciIo->GetBarAttributes (
- Private->PciIo,
- PCI_BAR_IDX0,
- NULL,
- (VOID**) &IoDesc
- );
-if (EFI_ERROR (Status) ||
-IoDesc->ResType != ACPI_ADDRESS_SPACE_TYPE_IO ||
-IoDesc->AddrRangeMin > MAX_UINT16 + 1 - (VMWARE_SVGA_VALUE_PORT + 4)) {
- if (IoDesc != NULL) {
-FreePool (IoDesc);
- }
- Status = EFI_DEVICE_ERROR;
- goto RestoreAttributes;
-}
-Private->VmwareSvgaBasePort = (UINT16) IoDesc->AddrRangeMin;
-FreePool (IoDesc);
-
-TargetId = VMWARE_SVGA_ID_2;
-while (TRUE) {
- VmwareSvgaWrite (Private, VmwareSvgaRegId, TargetId);
- SvgaIdRead = VmwareSvgaRead (Private, VmwareSvgaRegId);
- if ((SvgaIdRead == TargetId) || (TargetId <= VMWARE_SVGA_ID_0)) {
-break;
- }
- TargetId--;
-}
-
-if (SvgaIdRead != TargetId) {
- DEBUG ((
-DEBUG_ERROR,
-"QemuVideo: QEMU_VIDEO_VMWARE_SVGA ID mismatch "
-"(got 0x%x, base address 0x%x)\n",
-SvgaIdRead,
-Private->VmwareSvgaBasePort
-));
- Status = EFI_DEVICE_ERROR;
- goto RestoreAttributes;
-}
-
-Private->FrameBufferVramBarIndex = PCI_BAR_IDX1;
- }
-
//
// Get ParentDevicePath
//
@@ -446,9 +385,6 @@ QemuVideoControllerDriverStart (
case QEMU_VIDEO_BOCHS:
Status = QemuVideoBochsModeSetup (Private, IsQxl);
break;
- case QEMU_VIDEO_VMWARE_SVGA:
-Status = QemuVideoVmwareSvgaModeSetup (Private);
-break;
default:
ASSERT (FALSE);
Status = EFI_DEVICE_ERROR;
@@ -510,9 +446,6 @@ DestructQemuVideoGraphics:
FreeModeData:
FreePool (Private->ModeData);
- if (Private->VmwareSvgaModeInfo != NULL) {
-FreePool (Private->VmwareSvgaModeInfo);
- }
UninstallGopDevicePath:
gBS->UninstallProtocolInterface (Private->Handle,
@@ -634,9 +567,6 @@ QemuVideoControllerDriverStop (
);
FreePool (Private->ModeData);
- if (Private->VmwareSvgaModeInfo != NULL) {
-FreePool (Private->VmwareSvgaModeInfo);
- }
gBS->UninstallProtocolInterface (Private->Handle,
&gEfiDevicePathProtocolGuid, Private->GopDevicePath);
FreePool (Private->GopDevicePath);
@@ -834,7 +764,7 @@ ClearScreen (
Private->PciIo->Mem.Write (
Private->PciIo,
EfiPciIoWidthFillUint32,
-Private->FrameBufferVramBarIndex,
+0,
0,
0x40 >> 2,
&Color
@@ -971,38 +901,6 @@ BochsRead (
return Data;
}
-VOID
-VmwareSvgaWrite (
- QEMU_VIDEO_PRIVATE_DATA *Private,
- UINT16Register,
- UINT32Value
- )
-{
- UnalignedIoWrite32 (
-Private->VmwareSvgaBasePort + VMWAR
Re: [edk2] [PATCH 4/4] OvmfPkg: simply use the Bochs interface for vmsvga
Hi Yu-chen Lin,
On 24/10/18 8:40, yuchen...@synology.com wrote:
From: yuchenlin
BAR |std vga | vmsvga
-
0| Framebuffer | I/O space
1| Reserved | Framebuffer
2| MMIO | FIFO
Because of the PCI BARs difference between std vga and
vmsvga, we can not simply recognize the "QEMU VMWare SVGA"
as the QEMU_VIDEO_BOCHS_MMIO variant.
Instead, we remain variant QEMU_VIDEO_VMWARE_SVGA, and use
it for:
(1) Get framebuffer from correct PCI BAR
(2) Prevent using BAR2 for MMIO
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: yuchenlin
---
OvmfPkg/QemuVideoDxe/Driver.c | 16 +++-
OvmfPkg/QemuVideoDxe/Gop.c| 3 ++-
OvmfPkg/QemuVideoDxe/Qemu.h | 2 ++
3 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/OvmfPkg/QemuVideoDxe/Driver.c b/OvmfPkg/QemuVideoDxe/Driver.c
index 2304afd1e6..a1785c2285 100644
--- a/OvmfPkg/QemuVideoDxe/Driver.c
+++ b/OvmfPkg/QemuVideoDxe/Driver.c
@@ -16,6 +16,7 @@
#include "Qemu.h"
#include
+#include
EFI_DRIVER_BINDING_PROTOCOL gQemuVideoDriverBinding = {
QemuVideoControllerDriverSupported,
@@ -69,6 +70,12 @@ QEMU_VIDEO_CARD gQemuVideoCardList[] = {
0x1050,
QEMU_VIDEO_BOCHS_MMIO,
L"QEMU VirtIO VGA"
+},{
+PCI_CLASS_DISPLAY_VGA,
+VMWARE_PCI_VENDOR_ID_VMWARE,
+VMWARE_PCI_DEVICE_ID_VMWARE_SVGA2,
+QEMU_VIDEO_VMWARE_SVGA,
+L"QEMU VMWare SVGA"
Looks OK.
},{
0 /* end of list */
}
@@ -256,6 +263,11 @@ QemuVideoControllerDriverStart (
goto ClosePciIo;
}
Private->Variant = Card->Variant;
+ Private->FrameBufferVramBarIndex = PCI_BAR_IDX0;
+ if (Private->Variant == QEMU_VIDEO_VMWARE_SVGA) {
+Private->FrameBufferVramBarIndex = PCI_BAR_IDX1;
OK, but why not use an 'else' clause?
+ }
+
//
// IsQxl is based on the detected Card->Variant, which at a later point
might
@@ -320,7 +332,8 @@ QemuVideoControllerDriverStart (
// Check if accessing the bochs interface works.
//
if (Private->Variant == QEMU_VIDEO_BOCHS_MMIO ||
- Private->Variant == QEMU_VIDEO_BOCHS) {
+ Private->Variant == QEMU_VIDEO_BOCHS ||
+ Private->Variant == QEMU_VIDEO_VMWARE_SVGA) {
UINT16 BochsId;
BochsId = BochsRead(Private, VBE_DISPI_INDEX_ID);
if ((BochsId & 0xFFF0) != VBE_DISPI_ID0) {
@@ -383,6 +396,7 @@ QemuVideoControllerDriverStart (
break;
case QEMU_VIDEO_BOCHS_MMIO:
case QEMU_VIDEO_BOCHS:
+ case QEMU_VIDEO_VMWARE_SVGA:
Status = QemuVideoBochsModeSetup (Private, IsQxl);
break;
default:
diff --git a/OvmfPkg/QemuVideoDxe/Gop.c b/OvmfPkg/QemuVideoDxe/Gop.c
index d490fa7a2e..3abc5eeb36 100644
--- a/OvmfPkg/QemuVideoDxe/Gop.c
+++ b/OvmfPkg/QemuVideoDxe/Gop.c
@@ -60,7 +60,7 @@ QemuVideoCompleteModeData (
Private->PciIo->GetBarAttributes (
Private->PciIo,
-0,
+Private->FrameBufferVramBarIndex,
OK
NULL,
(VOID**) &FrameBufDesc
);
@@ -177,6 +177,7 @@ Routine Description:
break;
case QEMU_VIDEO_BOCHS_MMIO:
case QEMU_VIDEO_BOCHS:
+ case QEMU_VIDEO_VMWARE_SVGA:
InitializeBochsGraphicsMode (Private,
&QemuVideoBochsModes[ModeData->InternalModeIndex]);
break;
default:
diff --git a/OvmfPkg/QemuVideoDxe/Qemu.h b/OvmfPkg/QemuVideoDxe/Qemu.h
index d7da761705..3aac9eeca6 100644
--- a/OvmfPkg/QemuVideoDxe/Qemu.h
+++ b/OvmfPkg/QemuVideoDxe/Qemu.h
@@ -92,6 +92,7 @@ typedef enum {
QEMU_VIDEO_CIRRUS_5446,
QEMU_VIDEO_BOCHS,
QEMU_VIDEO_BOCHS_MMIO,
+ QEMU_VIDEO_VMWARE_SVGA,
} QEMU_VIDEO_VARIANT;
typedef struct {
@@ -120,6 +121,7 @@ typedef struct {
QEMU_VIDEO_VARIANTVariant;
FRAME_BUFFER_CONFIGURE*FrameBufferBltConfigure;
UINTN FrameBufferBltConfigureSize;
+ UINT8 FrameBufferVramBarIndex;
} QEMU_VIDEO_PRIVATE_DATA;
///
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
