Re: [edk2-devel] [Patch] SecurityPkg: Fix spelling errors
Reviewed-by: Jiewen Yao > -Original Message- > From: Wang, Jian J > Sent: Tuesday, October 22, 2019 12:39 PM > To: Kinney, Michael D ; devel@edk2.groups.io > Cc: Sean Brogan ; Yao, Jiewen > ; Zhang, Chao B > Subject: RE: [Patch] SecurityPkg: Fix spelling errors > > > Reviewed-by: Jian J Wang > > > -Original Message- > > From: Kinney, Michael D > > Sent: Saturday, October 19, 2019 3:02 AM > > To: devel@edk2.groups.io > > Cc: Sean Brogan ; Yao, Jiewen > > ; Wang, Jian J ; Zhang, Chao > B > > > > Subject: [Patch] SecurityPkg: Fix spelling errors > > > > From: Sean Brogan > > > > https://bugzilla.tianocore.org/show_bug.cgi?id=2265 > > > > Cc: Jiewen Yao > > Cc: Jian J Wang > > Cc: Chao Zhang > > Signed-off-by: Michael D Kinney > > --- > > SecurityPkg/FvReportPei/FvReportPei.c | 4 ++-- > > SecurityPkg/Hash2DxeCrypto/Driver.c | 6 ++--- > > SecurityPkg/Hash2DxeCrypto/Driver.h | 4 ++-- > > SecurityPkg/HddPassword/HddPasswordDxe.c | 10 > > SecurityPkg/HddPassword/HddPasswordDxe.h | 2 +- > > .../HddPassword/HddPasswordStrings.uni| 2 +- > > .../Guid/AuthenticatedVariableFormat.h| 2 +- > > .../Include/Library/Tcg2PhysicalPresenceLib.h | 4 ++-- > > .../Include/Library/TcgStorageCoreLib.h | 12 +- > > SecurityPkg/Include/Library/Tpm2CommandLib.h | 2 +- > > SecurityPkg/Include/Library/TpmCommLib.h | 2 +- > > .../Ppi/FirmwareVolumeInfoPrehashedFV.h | 4 ++-- > > .../Library/AuthVariableLib/AuthService.c | 4 ++-- > > .../AuthVariableLib/AuthServiceInternal.h | 2 +- > > .../Library/AuthVariableLib/AuthVariableLib.c | 4 ++-- > > .../DxeImageAuthenticationStatusLib.c | 2 +- > > .../DxeImageVerificationLib.c | 10 > > .../DxeRsa2048Sha256GuidedSectionExtractLib.c | 4 ++-- > > ...xeRsa2048Sha256GuidedSectionExtractLib.inf | 2 +- > > ...xeRsa2048Sha256GuidedSectionExtractLib.uni | 2 +- > > .../DxeTpm2MeasureBootLib.c | 4 ++-- > > .../DxeTpmMeasureBootLib.c| 4 ++-- > > .../DxeTpmMeasurementLib.c| 2 +- > > .../HashInstanceLibSha1/HashInstanceLibSha1.c | 2 +- > > .../HashInstanceLibSha256.c | 2 +- > > .../HashInstanceLibSha384.c | 2 +- > > .../HashInstanceLibSha512.c | 2 +- > > SecurityPkg/Library/HashLibTpm2/HashLibTpm2.c | 2 +- > > .../PeiRsa2048Sha256GuidedSectionExtractLib.c | 4 ++-- > > ...eiRsa2048Sha256GuidedSectionExtractLib.inf | 2 +- > > ...eiRsa2048Sha256GuidedSectionExtractLib.uni | 2 +- > > .../TcgStorageCoreLib/TcgStorageCore.c| 10 > > .../TcgStorageCoreLib/TcgStorageUtil.c| 2 +- > > .../TcgStorageOpalLib/TcgStorageOpalUtil.c| 6 ++--- > > .../Library/Tpm12CommandLib/Tpm12NvStorage.c | 2 +- > > .../Library/Tpm12DeviceLibDTpm/Tpm12Tis.c | 2 +- > > .../Library/Tpm2CommandLib/Tpm2Capability.c | 4 ++-- > > .../Library/Tpm2CommandLib/Tpm2Hierarchy.c| 2 +- > > .../Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.c | 2 +- > > .../Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.c | 2 +- > > .../Library/Tpm2DeviceLibDTpm/Tpm2Ptp.c | 4 ++-- > > .../Library/Tpm2DeviceLibDTpm/Tpm2Tis.c | 4 ++-- > > SecurityPkg/Library/TpmCommLib/CommonHeader.h | 2 +- > > SecurityPkg/Library/TpmCommLib/TisPc.c| 2 +- > > .../Pkcs7VerifyDxe/Pkcs7VerifyDxe.c | 18 +++--- > > .../RandomNumberGenerator/RngDxe/RdRand.c | 2 +- > > SecurityPkg/SecurityPkg.dec | 18 +++--- > > SecurityPkg/SecurityPkg.dsc | 2 +- > > SecurityPkg/SecurityPkg.uni | 12 +- > > .../Tcg/MemoryOverwriteControl/TcgMor.c | 6 ++--- > > .../Tcg/MemoryOverwriteControl/TcgMor.inf | 2 +- > > .../Tcg/MemoryOverwriteControl/TcgMor.uni | 2 +- > > .../TcgMorLock.c | 4 ++-- > > .../TcgMorLock.h | 2 +- > > .../TcgMorLock.uni| 4 ++-- > > .../TcgMorLockSmm.inf | 2 +- > > .../Tcg/Opal/OpalPassword/OpalDriver.c| 6 ++--- > > .../Tcg/Opal/OpalPassword/OpalDriver.h| 6 ++--- > > SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c | 10 > > SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.h | 8 +++ > > .../PhysicalPresencePei/PhysicalPresencePei.c | 2 +- > > SecurityPkg/Tcg/Tcg2Config/Tcg2Config.vfr | 6 ++--- > > SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c | 2 +- > > SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigPeim.c | 4 ++-- > > SecurityPkg/Tcg/Tcg2Dxe/MeasureBootPeCoff.c | 2 +- > > SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c | 2 +- > > SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c | 16 ++--- > > SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c | 22 - > > SecurityPkg/Tcg/Tcg2Smm/Tpm.asl | 6 ++--- > >
Re: [edk2-devel] [Patch] SecurityPkg: Fix spelling errors
Reviewed-by: Jian J Wang > -Original Message- > From: Kinney, Michael D > Sent: Saturday, October 19, 2019 3:02 AM > To: devel@edk2.groups.io > Cc: Sean Brogan ; Yao, Jiewen > ; Wang, Jian J ; Zhang, Chao B > > Subject: [Patch] SecurityPkg: Fix spelling errors > > From: Sean Brogan > > https://bugzilla.tianocore.org/show_bug.cgi?id=2265 > > Cc: Jiewen Yao > Cc: Jian J Wang > Cc: Chao Zhang > Signed-off-by: Michael D Kinney > --- > SecurityPkg/FvReportPei/FvReportPei.c | 4 ++-- > SecurityPkg/Hash2DxeCrypto/Driver.c | 6 ++--- > SecurityPkg/Hash2DxeCrypto/Driver.h | 4 ++-- > SecurityPkg/HddPassword/HddPasswordDxe.c | 10 > SecurityPkg/HddPassword/HddPasswordDxe.h | 2 +- > .../HddPassword/HddPasswordStrings.uni| 2 +- > .../Guid/AuthenticatedVariableFormat.h| 2 +- > .../Include/Library/Tcg2PhysicalPresenceLib.h | 4 ++-- > .../Include/Library/TcgStorageCoreLib.h | 12 +- > SecurityPkg/Include/Library/Tpm2CommandLib.h | 2 +- > SecurityPkg/Include/Library/TpmCommLib.h | 2 +- > .../Ppi/FirmwareVolumeInfoPrehashedFV.h | 4 ++-- > .../Library/AuthVariableLib/AuthService.c | 4 ++-- > .../AuthVariableLib/AuthServiceInternal.h | 2 +- > .../Library/AuthVariableLib/AuthVariableLib.c | 4 ++-- > .../DxeImageAuthenticationStatusLib.c | 2 +- > .../DxeImageVerificationLib.c | 10 > .../DxeRsa2048Sha256GuidedSectionExtractLib.c | 4 ++-- > ...xeRsa2048Sha256GuidedSectionExtractLib.inf | 2 +- > ...xeRsa2048Sha256GuidedSectionExtractLib.uni | 2 +- > .../DxeTpm2MeasureBootLib.c | 4 ++-- > .../DxeTpmMeasureBootLib.c| 4 ++-- > .../DxeTpmMeasurementLib.c| 2 +- > .../HashInstanceLibSha1/HashInstanceLibSha1.c | 2 +- > .../HashInstanceLibSha256.c | 2 +- > .../HashInstanceLibSha384.c | 2 +- > .../HashInstanceLibSha512.c | 2 +- > SecurityPkg/Library/HashLibTpm2/HashLibTpm2.c | 2 +- > .../PeiRsa2048Sha256GuidedSectionExtractLib.c | 4 ++-- > ...eiRsa2048Sha256GuidedSectionExtractLib.inf | 2 +- > ...eiRsa2048Sha256GuidedSectionExtractLib.uni | 2 +- > .../TcgStorageCoreLib/TcgStorageCore.c| 10 > .../TcgStorageCoreLib/TcgStorageUtil.c| 2 +- > .../TcgStorageOpalLib/TcgStorageOpalUtil.c| 6 ++--- > .../Library/Tpm12CommandLib/Tpm12NvStorage.c | 2 +- > .../Library/Tpm12DeviceLibDTpm/Tpm12Tis.c | 2 +- > .../Library/Tpm2CommandLib/Tpm2Capability.c | 4 ++-- > .../Library/Tpm2CommandLib/Tpm2Hierarchy.c| 2 +- > .../Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.c | 2 +- > .../Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.c | 2 +- > .../Library/Tpm2DeviceLibDTpm/Tpm2Ptp.c | 4 ++-- > .../Library/Tpm2DeviceLibDTpm/Tpm2Tis.c | 4 ++-- > SecurityPkg/Library/TpmCommLib/CommonHeader.h | 2 +- > SecurityPkg/Library/TpmCommLib/TisPc.c| 2 +- > .../Pkcs7VerifyDxe/Pkcs7VerifyDxe.c | 18 +++--- > .../RandomNumberGenerator/RngDxe/RdRand.c | 2 +- > SecurityPkg/SecurityPkg.dec | 18 +++--- > SecurityPkg/SecurityPkg.dsc | 2 +- > SecurityPkg/SecurityPkg.uni | 12 +- > .../Tcg/MemoryOverwriteControl/TcgMor.c | 6 ++--- > .../Tcg/MemoryOverwriteControl/TcgMor.inf | 2 +- > .../Tcg/MemoryOverwriteControl/TcgMor.uni | 2 +- > .../TcgMorLock.c | 4 ++-- > .../TcgMorLock.h | 2 +- > .../TcgMorLock.uni| 4 ++-- > .../TcgMorLockSmm.inf | 2 +- > .../Tcg/Opal/OpalPassword/OpalDriver.c| 6 ++--- > .../Tcg/Opal/OpalPassword/OpalDriver.h| 6 ++--- > SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c | 10 > SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.h | 8 +++ > .../PhysicalPresencePei/PhysicalPresencePei.c | 2 +- > SecurityPkg/Tcg/Tcg2Config/Tcg2Config.vfr | 6 ++--- > SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigDriver.c | 2 +- > SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigPeim.c | 4 ++-- > SecurityPkg/Tcg/Tcg2Dxe/MeasureBootPeCoff.c | 2 +- > SecurityPkg/Tcg/Tcg2Dxe/Tcg2Dxe.c | 2 +- > SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c | 16 ++--- > SecurityPkg/Tcg/Tcg2Smm/Tcg2Smm.c | 22 - > SecurityPkg/Tcg/Tcg2Smm/Tpm.asl | 6 ++--- > .../Tcg/TcgConfigDxe/TcgConfigDriver.c| 2 +- > SecurityPkg/Tcg/TcgDxe/TcgDxe.c | 6 ++--- > SecurityPkg/Tcg/TcgPei/TcgPei.c | 18 +++--- > SecurityPkg/Tcg/TcgSmm/Tpm.asl| 6 ++--- > .../SecureBootConfigDriver.c | 2 +- > .../SecureBootConfigDxe.inf | 2 +- > .../SecureBootConfigDxe.uni | 2 +- > .../SecureBootConfigImpl.c
Re: [edk2-devel] Use a pcd to control PlatformRecovery
Sean, Do you have any comments from MS side? Thanks, Ray > -Original Message- > From: Wang, Sunny (HPS SW) > Sent: Monday, October 21, 2019 8:45 PM > To: Ni, Ray ; devel@edk2.groups.io; Gao, Zhichao > ; pjo...@redhat.com > Cc: Wang, Jian J ; Wu, Hao A ; > Zeng, Star ; Gao, Liming ; > Sean Brogan ; Michael Turner > ; Bret Barkelew > ; Li, Walon ; Wei, Kent > (HPS SW) ; Spottswood, Jason > ; Wang, Sunny (HPS SW) > > Subject: RE: [edk2-devel] Use a pcd to control PlatformRecovery > > Sorry for the delay and thanks for checking my question, Ray. > > Since the OS recovery and platform recovery options were added to UEFI > specification at the same time, I thought we will also implement it and push > the code regardless of the OS support. > > No, I didn't see a real need of using the OS recovery option. If my memory > serves me well, I have only seen a need of using "One-Time" OS recovery, > but it can be done by creating, adjusting, and removing a boot option in boot > order. > However, I can still imagine that the OS recovery option is needed for the use > of "persistent" OS recovery. Therefore, if we don't have any concern about > adding OS recovery option support, I think it is still better to push the code > because the UEFI specification mentioned it. Add Peter. He may know more > information about this. > > By the way, I think if no one works on the task below, there will be no OS or > OS tool supporting it. :) >- https://github.com/rhboot/efibootmgr/issues/41 > > > Regards, > Sunny Wang > > -Original Message- > From: Ni, Ray [mailto:ray...@intel.com] > Sent: Wednesday, October 16, 2019 4:43 PM > To: Wang, Sunny (HPS SW) ; devel@edk2.groups.io; > Gao, Zhichao > Cc: Wang, Jian J ; Wu, Hao A ; > Zeng, Star ; Gao, Liming ; > Sean Brogan ; Michael Turner > ; Bret Barkelew > ; Li, Walon ; Wei, Kent > (HPS SW) ; Spottswood, Jason > > Subject: RE: [edk2-devel] Use a pcd to control PlatformRecovery > Importance: High > > Sunny, > For the OS recovery question, I had the code change in > https://github.com/niruiyu/edk2/tree/bds/osrecovery. > > Due to there is no OS support for OS recovery yet, the code was not pushed. > > Do you see any needs of the OS recovery? > > Thanks, > Ray > > > -Original Message- > > From: Wang, Sunny (HPS SW) > > Sent: Wednesday, October 16, 2019 3:42 PM > > To: devel@edk2.groups.io; Gao, Zhichao ; Ni, > > Ray > > Cc: Wang, Jian J ; Wu, Hao A > > ; Zeng, Star ; Gao, Liming > > ; Sean Brogan ; > > Michael Turner ; Bret Barkelew > > ; Li, Walon ; Wei, > Kent > > (HPS SW) ; Spottswood, Jason > > ; Wang, Sunny (HPS SW) > > > Subject: RE: [edk2-devel] Use a pcd to control PlatformRecovery > > > > Thanks for checking this, Zhichao and Ray. > > I just sent a patch to fix it with the subject " [edk2-devel] [PATCH] > > MdeModulePkg/BdsDxe: Make PlatformRecovery work regardless of > > OsIndications" > > > > Regards, > > Sunny Wang > > > > -Original Message- > > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of > > Gao, Zhichao > > Sent: Wednesday, October 16, 2019 1:57 PM > > To: Wang, Sunny (HPS SW) ; > devel@edk2.groups.io; > > Ni, Ray > > Cc: Wang, Jian J ; Wu, Hao A > > ; Zeng, Star ; Gao, Liming > > ; Sean Brogan ; > > Michael Turner ; Bret Barkelew > > ; Li, Walon ; Wei, > Kent > > (HPS SW) > > Subject: Re: [edk2-devel] Use a pcd to control PlatformRecovery > > Importance: High > > > > > > > -Original Message- > > > From: Gao, Zhichao > > > Sent: Wednesday, October 16, 2019 10:09 AM > > > To: 'Wang, Sunny (HPS SW)' ; > > devel@edk2.groups.io; > > > Ni, Ray > > > Cc: Wang, Jian J ; Wu, Hao A > > > ; Zeng, Star ; Gao, Liming > > > ; Sean Brogan ; > > > Michael Turner ; Bret Barkelew > > > ; Li, Walon ; Wei, > > Kent > > > (HPS SW) > > > Subject: RE: Use a pcd to control PlatformRecovery > > > > > > First of all, the patch didn't aim to change the other part of the > > > boot flow except PlatformRecovery. > > > > > > Local variable PlatformRecovery is controlled by OsIndications > > > variable. When the EFI_OS_INDICATIONS_START_PLATFORM_RECOVERY > is > > set, > > > the firmware should try to platform specific recovery. But that > > > doesn't mean the platform must support the specific recovery. i.e. > > > local PlatformRecovery is controlling the boot flow and the Pcd just > > > indicated whether the platform support recovery or not. > > > So, on my opinion, I don't agree with your change. > > > > After discuss with Sunny and Ray, and refer to the spec section 3.4.1 > > and 3.4.2, the OsRecovery and PlatformRecovery should always be > > operated regardless of the value of OsIndication variable if fail to > > boot the BootOrder. I am wrong. We should change to use the > > PcdPlatformRecoverySupport to control the PlatformRecovery. Please > > help to send a patch to fix it. Thanks a lot. > > > > > > > > Default Platform Recovery refer to the short file path to boot the OS. > > > If the firmware supports
Re: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-2 PATCH V4] MdePkg/Protocols: New interface, EFI encodings to PCI Plat protocol
Just resending by correcting the edk2-staging branch name in the subject line. Kindly review and provide your feedback. Thanks Ashraf > -Original Message- > From: devel@edk2.groups.io On Behalf Of Javeed, > Ashraf > Sent: Thursday, October 17, 2019 10:24 PM > To: devel@edk2.groups.io > Cc: Kinney, Michael D ; Gao, Liming > ; Ni, Ray > Subject: [edk2-devel] [edk2-staging/UEFI_PCI_ENHANCE-1 PATCH V4] > MdePkg/Protocols: New interface, EFI encodings to PCI Plat protocol > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1954 > > New interface added to PCI Platform Protocol / PCI Override Protocol to > retrieve device-specific platform policy for the following PCI standard > features, > like Maximum Payload Size (MPS), Maximum Read Request Size > (MRRS),Extended Tags, Relax Order, No-Snoop, Active State Power > Management (ASPM),Latency Time Reporting (LTR), AtomicOp, Reference Clock > Configuration, Extended SYNCH, PTM support, and Completion Timeout (CTO). > New source files added with enhanced definitions are in: > MdePkg/Include/Protocol/PciPlatform2.h, > MdePkg/Include/Protocol/PciOverride2.h > > Signed-off-by: Ashraf Javeed > Cc: Michael D Kinney > Cc: Liming Gao > Cc: Ray Ni > --- > > In V4: Redefinition of the existing interfaces in the EFI_PCI_PLATFORM_- > PROTOCOL2, to avoid type casting and to avoid further future change > > In V3: License update in the header sections of source files > > In V2: Correction made to header sections of source files > --- > MdePkg/Include/Protocol/PciOverride2.h | 37 > + > MdePkg/Include/Protocol/PciPlatform2.h | 524 > + > + > + > + > + > + > + > + > > MdePkg/MdePkg.dec | 6 ++ > 3 files changed, 567 insertions(+) > > diff --git a/MdePkg/Include/Protocol/PciOverride2.h > b/MdePkg/Include/Protocol/PciOverride2.h > new file mode 100644 > index 00..7e878a4f1e > --- /dev/null > +++ b/MdePkg/Include/Protocol/PciOverride2.h > @@ -0,0 +1,37 @@ > +/** @file > + This file declares EFI PCI Override protocol which provides the > +interface between > + the PCI bus driver/PCI Host Bridge Resource Allocation driver and an > +implementation's > + driver to describe the unique features of a platform. > + This protocol is optional. > + > +Copyright (c) 2019, Intel Corporation. All rights reserved. > +SPDX-License-Identifier: BSD-2-Clause-Patent > + > + > +**/ > + > +#ifndef _PCI_OVERRIDE2_H_ > +#define _PCI_OVERRIDE2_H_ > + > +/// > +/// EFI_PCI_OVERRIDE_PROTOCOL has the same structure with > +EFI_PCI_PLATFORM_PROTOCOL /// #include > + > +/// > +/// Global ID for the EFI_PCI_OVERRIDE_PROTOCOL /// #define > +EFI_PCI_OVERRIDE2_GUID \ > + { \ > +0xb9d5ea1, 0x66cb, 0x4546, {0xb0, 0xbb, 0x5c, 0x6d, 0xae, 0xd9, > +0x42, 0x47} \ > + } > + > +/// > +/// Declaration for EFI_PCI_OVERRIDE_PROTOCOL /// typedef > +EFI_PCI_PLATFORM_PROTOCOL2 EFI_PCI_OVERRIDE_PROTOCOL2; > + > + > +extern EFI_GUID gEfiPciOverrideProtocol2Guid; > + > +#endif > diff --git a/MdePkg/Include/Protocol/PciPlatform2.h > b/MdePkg/Include/Protocol/PciPlatform2.h > new file mode 100644 > index 00..6dcae70d6d > --- /dev/null > +++ b/MdePkg/Include/Protocol/PciPlatform2.h > @@ -0,0 +1,524 @@ > +/** @file > + This file declares PCI Platform Protocol that provide the interface > +between > + the PCI bus driver/PCI Host Bridge Resource Allocation driver and a > +platform-specific > + driver to describe the unique features of a platform. > + This protocol is optional. > + > +Copyright (c) 2019, Intel Corporation. All rights reserved. > +SPDX-License-Identifier: BSD-2-Clause-Patent > + > + > +**/ > + > +#ifndef _PCI_PLATFORM2_H_ > +#define _PCI_PLATFORM2_H_ > + > +/// > +/// This file must be included because the EFI_PCI_PLATFORM_PROTOCOL2 > +uses /// EFI_PCI_HOST_BRIDGE_RESOURCE_ALLOCATION_PHASE. > +/// > +#include > + > +/// > +/// This file is included to reuse the existing PCI Platform data > +structure /// definitions of > +EFI_PCI_EXECUTION_PHASE,EFI_PCI_PLATFORM_POLICY > +/// > +#include > + > +/// > +/// Global ID for the EFI_PCI_PLATFORM_PROTOCOL2. > +/// > +#define EFI_PCI_PLATFORM_PROTOCOL2_GUID \ > + { \ > +0x787b0367, 0xa945, 0x4d60, {0x8d, 0x34, 0xb9, 0xd1, 0x88, 0xd2, > +0xd0, 0xb6} \ > + } > + > +/// > +/// As per the present definition and specification of this protocol, > +the major /// version is 1, and minor version is 1. Any driver > +utilizing this protocol /// shall use
Re: [edk2-devel] [Patch v3 04/11] MdePkg Base.h: Add definition for CLANG9 tool chain
Reviewed-by: Michael D Kinney > -Original Message- > From: devel@edk2.groups.io On > Behalf Of Liming Gao > Sent: Wednesday, October 16, 2019 11:56 PM > To: devel@edk2.groups.io > Cc: Kinney, Michael D > Subject: [edk2-devel] [Patch v3 04/11] MdePkg Base.h: > Add definition for CLANG9 tool chain > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603 > CLANG9 tool chain defines __clang__ macro only, doesn't > define __GNUC__ macro. But, it uses some same > definitions with GCC. > So, update base definition for CLANG9 tool chain. > > Signed-off-by: Liming Gao > Cc: Michael Kinney > Reviewed-by: Philippe Mathieu-Daude > --- > MdePkg/Include/Base.h | 6 +++--- > MdePkg/Include/Ia32/ProcessorBind.h | 4 ++-- > MdePkg/Include/X64/ProcessorBind.h | 2 +- > 3 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/MdePkg/Include/Base.h > b/MdePkg/Include/Base.h index d94b8a5f93..4680e64136 > 100644 > --- a/MdePkg/Include/Base.h > +++ b/MdePkg/Include/Base.h > @@ -621,9 +621,9 @@ typedef char* VA_LIST; > #define VA_END(Marker) (Marker = > (VA_LIST) 0) > #define VA_COPY(Dest, Start)((void)((Dest) > = (Start))) > > -#elif defined(__GNUC__) > +#elif defined(__GNUC__) || defined(__clang__) > > -#if defined(MDE_CPU_X64) && > !defined(NO_MSABI_VA_FUNCS) > +#if defined(MDE_CPU_X64) && > !defined(NO_MSABI_VA_FUNCS) && > +!defined(__clang__) > // > // X64 only. Use MS ABI version of GCC built-in macros > for variable argument lists. > // > @@ -1274,7 +1274,7 @@ typedef UINTN RETURN_STATUS; > >**/ >#define RETURN_ADDRESS(L) ((L == 0) ? > _ReturnAddress() : (VOID *) 0) > -#elif defined(__GNUC__) > +#elif defined (__GNUC__) || defined (__clang__) >void * __builtin_return_address (unsigned int > level); >/** > Get the return address of the calling function. > diff --git a/MdePkg/Include/Ia32/ProcessorBind.h > b/MdePkg/Include/Ia32/ProcessorBind.h > index 497c58b33b..fa4b7e8e98 100644 > --- a/MdePkg/Include/Ia32/ProcessorBind.h > +++ b/MdePkg/Include/Ia32/ProcessorBind.h > @@ -281,7 +281,7 @@ typedef INT32 INTN; >/// Microsoft* compiler specific method for EFIAPI > calling convention. >/// >#define EFIAPI __cdecl > -#elif defined(__GNUC__) > +#elif defined(__GNUC__) || defined(__clang__) >/// >/// GCC specific method for EFIAPI calling > convention. >/// > @@ -294,7 +294,7 @@ typedef INT32 INTN; >#define EFIAPI > #endif > > -#if defined(__GNUC__) > +#if defined(__GNUC__) || defined(__clang__) >/// >/// For GNU assembly code, .global or .globl can > declare global symbols. >/// Define this macro to unify the usage. > diff --git a/MdePkg/Include/X64/ProcessorBind.h > b/MdePkg/Include/X64/ProcessorBind.h > index 6f65acd609..387e9c5c9c 100644 > --- a/MdePkg/Include/X64/ProcessorBind.h > +++ b/MdePkg/Include/X64/ProcessorBind.h > @@ -313,7 +313,7 @@ typedef INT64 INTN; >#define EFIAPI > #endif > > -#if defined(__GNUC__) > +#if defined(__GNUC__) || defined(__clang__) >/// >/// For GNU assembly code, .global or .globl can > declare global symbols. >/// Define this macro to unify the usage. > -- > 2.13.0.windows.1 > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49322): https://edk2.groups.io/g/devel/message/49322 Mute This Topic: https://groups.io/mt/34694443/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [Patch v2 05/11] MdePkg BaseIoLibIntrinsic: Remove __inline__ attribute for IO functions
Reviewed-by: Michael D Kinney > -Original Message- > From: devel@edk2.groups.io On > Behalf Of Liming Gao > Sent: Monday, October 14, 2019 5:27 PM > To: devel@edk2.groups.io > Subject: [edk2-devel] [Patch v2 05/11] MdePkg > BaseIoLibIntrinsic: Remove __inline__ attribute for IO > functions > > __inline__ has no functional difference effect with the > GCC48 / GCC49 / GCC5 toolchains, but it breaks the > build with CLANG9. Remove __inline__. > > Signed-off-by: Liming Gao > Acked-by: Laszlo Ersek > --- > MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c | 6 - > - > 1 file changed, 6 deletions(-) > > diff --git > a/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c > b/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c > index 055f0a947e..b3a1a20256 100644 > --- a/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c > +++ b/MdePkg/Library/BaseIoLibIntrinsic/IoLibGcc.c > @@ -32,7 +32,6 @@ >@return The value read. > > **/ > -__inline__ > UINT8 > EFIAPI > IoRead8 ( > @@ -60,7 +59,6 @@ IoRead8 ( >@return The value written the I/O port. > > **/ > -__inline__ > UINT8 > EFIAPI > IoWrite8 ( > @@ -87,7 +85,6 @@ IoWrite8 ( >@return The value read. > > **/ > -__inline__ > UINT16 > EFIAPI > IoRead16 ( > @@ -117,7 +114,6 @@ IoRead16 ( >@return The value written the I/O port. > > **/ > -__inline__ > UINT16 > EFIAPI > IoWrite16 ( > @@ -145,7 +141,6 @@ IoWrite16 ( >@return The value read. > > **/ > -__inline__ > UINT32 > EFIAPI > IoRead32 ( > @@ -175,7 +170,6 @@ IoRead32 ( >@return The value written the I/O port. > > **/ > -__inline__ > UINT32 > EFIAPI > IoWrite32 ( > -- > 2.13.0.windows.1 > > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49321): https://edk2.groups.io/g/devel/message/49321 Mute This Topic: https://groups.io/mt/34540587/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v2] OvmfPkg: Make SOURCE_DEBUG_ENABLE actually need to be set to TRUE
Reviewed-by: Jordan Justen On 2019-10-21 13:13:20, Laszlo Ersek wrote: > From: Peter Jones > > Currently some tests check the value of SOURCE_DEBUG_ENABLE, and some > tests check if it's defined or not. Additionally, in UefiPayloadPkg as > well as some other trees, we define it as FALSE in the .dsc file. > > This patch changes all of the Ovmf platforms to explicitly define it as > FALSE by default, and changes all of the checks to test if the value is > TRUE. > > Signed-off-by: Peter Jones > Message-Id: <20190920184507.909884-1-pjo...@redhat.com> > [ler...@redhat.com: drop Contributed-under line, per TianoCore BZ#1373] > [ler...@redhat.com: replace "!= TRUE" with more idiomatic "== FALSE"] > Cc: Andrew Fish > Cc: Anthony Perard > Cc: Ard Biesheuvel > Cc: Jordan Justen > Cc: Julien Grall > Cc: Leif Lindholm > Cc: Michael Kinney > Cc: Peter Jones > Signed-off-by: Laszlo Ersek > --- > > Notes: > v2: > > - repo: https://github.com/lersek/edk2.git > branch: src_dbg_true_v2 > > - repost the patch in Peter's stead, with the updates requested at > > <9c6d70b5-fcd6-373f-973f-044d1338e47b@redhat.com">http://mid.mail-archive.com/9c6d70b5-fcd6-373f-973f-044d1338e47b@redhat.com> > > - per discussion with the other stewards, it's OK to explicitly resubmit > the patch (noting the original authorship) with the Contributed-under > line removed > > OvmfPkg/OvmfPkgIa32.dsc| 17 + > OvmfPkg/OvmfPkgIa32X64.dsc | 19 ++- > OvmfPkg/OvmfPkgX64.dsc | 19 ++- > OvmfPkg/OvmfXen.dsc| 17 + > OvmfPkg/OvmfPkgIa32.fdf| 2 +- > OvmfPkg/OvmfPkgIa32X64.fdf | 2 +- > OvmfPkg/OvmfPkgX64.fdf | 2 +- > OvmfPkg/OvmfXen.fdf| 2 +- > 8 files changed, 42 insertions(+), 38 deletions(-) > > diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc > index 66e944436a69..4301e7821902 100644 > --- a/OvmfPkg/OvmfPkgIa32.dsc > +++ b/OvmfPkg/OvmfPkgIa32.dsc > @@ -30,6 +30,7 @@ [Defines] ># >DEFINE SECURE_BOOT_ENABLE = FALSE >DEFINE SMM_REQUIRE = FALSE > + DEFINE SOURCE_DEBUG_ENABLE = FALSE >DEFINE TPM2_ENABLE = FALSE >DEFINE TPM2_CONFIG_ENABLE = FALSE > > @@ -157,7 +158,7 @@ [LibraryClasses] > > CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf > > FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf > > -!ifdef $(SOURCE_DEBUG_ENABLE) > +!if $(SOURCE_DEBUG_ENABLE) == TRUE > > PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLibDebug.inf > > DebugCommunicationLib|SourceLevelDebugPkg/Library/DebugCommunicationLibSerialPort/DebugCommunicationLibSerialPort.inf > !else > @@ -225,7 +226,7 @@ [LibraryClasses.common.SEC] > !endif > > ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf > > ExtractGuidedSectionLib|MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.inf > -!ifdef $(SOURCE_DEBUG_ENABLE) > +!if $(SOURCE_DEBUG_ENABLE) == TRUE > > DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf > !endif >HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf > @@ -267,7 +268,7 @@ [LibraryClasses.common.PEIM] >PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf > > ResourcePublicationLib|MdePkg/Library/PeiResourcePublicationLib/PeiResourcePublicationLib.inf > > ExtractGuidedSectionLib|MdePkg/Library/PeiExtractGuidedSectionLib/PeiExtractGuidedSectionLib.inf > -!ifdef $(SOURCE_DEBUG_ENABLE) > +!if $(SOURCE_DEBUG_ENABLE) == TRUE > > DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf > !endif > > CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf > @@ -292,7 +293,7 @@ [LibraryClasses.common.DXE_CORE] >DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf > !endif > > ExtractGuidedSectionLib|MdePkg/Library/DxeExtractGuidedSectionLib/DxeExtractGuidedSectionLib.inf > -!ifdef $(SOURCE_DEBUG_ENABLE) > +!if $(SOURCE_DEBUG_ENABLE) == TRUE >DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf > !endif > > CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf > @@ -351,7 +352,7 @@ [LibraryClasses.common.DXE_DRIVER] > !else >LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf > !endif > -!ifdef $(SOURCE_DEBUG_ENABLE) > +!if $(SOURCE_DEBUG_ENABLE) == TRUE >DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf > !endif >PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf > @@ -389,7 +390,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER] >DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf > !endif > >
[edk2-devel] [Patch] NetworkPkg: Add missing components to DSC file
From: Sean Brogan https://bugzilla.tianocore.org/show_bug.cgi?id=2259 Update DSC file to build all libraries and modules in the NetworkPkg. Cc: Siyuan Fu Cc: Jiaxin Wu Signed-off-by: Michael D Kinney --- NetworkPkg/NetworkPkg.dsc | 6 ++ 1 file changed, 6 insertions(+) diff --git a/NetworkPkg/NetworkPkg.dsc b/NetworkPkg/NetworkPkg.dsc index fe2fcf7b3c..11a2981261 100644 --- a/NetworkPkg/NetworkPkg.dsc +++ b/NetworkPkg/NetworkPkg.dsc @@ -99,6 +99,12 @@ [PcdsFixedAtBuild] [Components] NetworkPkg/WifiConnectionManagerDxe/WifiConnectionManagerDxe.inf NetworkPkg/Application/VConfig/VConfig.inf + NetworkPkg/Library/DxeDpcLib/DxeDpcLib.inf + NetworkPkg/Library/DxeHttpLib/DxeHttpLib.inf + NetworkPkg/Library/DxeIpIoLib/DxeIpIoLib.inf + NetworkPkg/Library/DxeNetLib/DxeNetLib.inf + NetworkPkg/Library/DxeTcpIoLib/DxeTcpIoLib.inf + NetworkPkg/Library/DxeUdpIoLib/DxeUdpIoLib.inf !include NetworkPkg/Network.dsc.inc -- 2.21.0.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49319): https://edk2.groups.io/g/devel/message/49319 Mute This Topic: https://groups.io/mt/36370898/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v2] OvmfPkg: Make SOURCE_DEBUG_ENABLE actually need to be set to TRUE
From: Peter Jones Currently some tests check the value of SOURCE_DEBUG_ENABLE, and some tests check if it's defined or not. Additionally, in UefiPayloadPkg as well as some other trees, we define it as FALSE in the .dsc file. This patch changes all of the Ovmf platforms to explicitly define it as FALSE by default, and changes all of the checks to test if the value is TRUE. Signed-off-by: Peter Jones Message-Id: <20190920184507.909884-1-pjo...@redhat.com> [ler...@redhat.com: drop Contributed-under line, per TianoCore BZ#1373] [ler...@redhat.com: replace "!= TRUE" with more idiomatic "== FALSE"] Cc: Andrew Fish Cc: Anthony Perard Cc: Ard Biesheuvel Cc: Jordan Justen Cc: Julien Grall Cc: Leif Lindholm Cc: Michael Kinney Cc: Peter Jones Signed-off-by: Laszlo Ersek --- Notes: v2: - repo: https://github.com/lersek/edk2.git branch: src_dbg_true_v2 - repost the patch in Peter's stead, with the updates requested at <9c6d70b5-fcd6-373f-973f-044d1338e47b@redhat.com">http://mid.mail-archive.com/9c6d70b5-fcd6-373f-973f-044d1338e47b@redhat.com> - per discussion with the other stewards, it's OK to explicitly resubmit the patch (noting the original authorship) with the Contributed-under line removed OvmfPkg/OvmfPkgIa32.dsc| 17 + OvmfPkg/OvmfPkgIa32X64.dsc | 19 ++- OvmfPkg/OvmfPkgX64.dsc | 19 ++- OvmfPkg/OvmfXen.dsc| 17 + OvmfPkg/OvmfPkgIa32.fdf| 2 +- OvmfPkg/OvmfPkgIa32X64.fdf | 2 +- OvmfPkg/OvmfPkgX64.fdf | 2 +- OvmfPkg/OvmfXen.fdf| 2 +- 8 files changed, 42 insertions(+), 38 deletions(-) diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index 66e944436a69..4301e7821902 100644 --- a/OvmfPkg/OvmfPkgIa32.dsc +++ b/OvmfPkg/OvmfPkgIa32.dsc @@ -30,6 +30,7 @@ [Defines] # DEFINE SECURE_BOOT_ENABLE = FALSE DEFINE SMM_REQUIRE = FALSE + DEFINE SOURCE_DEBUG_ENABLE = FALSE DEFINE TPM2_ENABLE = FALSE DEFINE TPM2_CONFIG_ENABLE = FALSE @@ -157,7 +158,7 @@ [LibraryClasses] CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf FrameBufferBltLib|MdeModulePkg/Library/FrameBufferBltLib/FrameBufferBltLib.inf -!ifdef $(SOURCE_DEBUG_ENABLE) +!if $(SOURCE_DEBUG_ENABLE) == TRUE PeCoffExtraActionLib|SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActionLibDebug.inf DebugCommunicationLib|SourceLevelDebugPkg/Library/DebugCommunicationLibSerialPort/DebugCommunicationLibSerialPort.inf !else @@ -225,7 +226,7 @@ [LibraryClasses.common.SEC] !endif ReportStatusCodeLib|MdeModulePkg/Library/PeiReportStatusCodeLib/PeiReportStatusCodeLib.inf ExtractGuidedSectionLib|MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.inf -!ifdef $(SOURCE_DEBUG_ENABLE) +!if $(SOURCE_DEBUG_ENABLE) == TRUE DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf !endif HobLib|MdePkg/Library/PeiHobLib/PeiHobLib.inf @@ -267,7 +268,7 @@ [LibraryClasses.common.PEIM] PeCoffLib|MdePkg/Library/BasePeCoffLib/BasePeCoffLib.inf ResourcePublicationLib|MdePkg/Library/PeiResourcePublicationLib/PeiResourcePublicationLib.inf ExtractGuidedSectionLib|MdePkg/Library/PeiExtractGuidedSectionLib/PeiExtractGuidedSectionLib.inf -!ifdef $(SOURCE_DEBUG_ENABLE) +!if $(SOURCE_DEBUG_ENABLE) == TRUE DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgentLib.inf !endif CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuExceptionHandlerLib.inf @@ -292,7 +293,7 @@ [LibraryClasses.common.DXE_CORE] DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf !endif ExtractGuidedSectionLib|MdePkg/Library/DxeExtractGuidedSectionLib/DxeExtractGuidedSectionLib.inf -!ifdef $(SOURCE_DEBUG_ENABLE) +!if $(SOURCE_DEBUG_ENABLE) == TRUE DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf !endif CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/DxeCpuExceptionHandlerLib.inf @@ -351,7 +352,7 @@ [LibraryClasses.common.DXE_DRIVER] !else LockBoxLib|OvmfPkg/Library/LockBoxLib/LockBoxDxeLib.inf !endif -!ifdef $(SOURCE_DEBUG_ENABLE) +!if $(SOURCE_DEBUG_ENABLE) == TRUE DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/DxeDebugAgentLib.inf !endif PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf @@ -389,7 +390,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER] DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf !endif CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf -!ifdef $(SOURCE_DEBUG_ENABLE) +!if $(SOURCE_DEBUG_ENABLE) == TRUE DebugAgentLib|SourceLevelDebugPkg/Library/DebugAgent/SmmDebugAgentLib.inf !endif BaseCryptLib|CryptoPkg/Library/BaseCryptLib/SmmCryptLib.inf @@ -481,7 +482,7 @@ [PcdsFixedAtBuild] # DEBUG_ERROR 0x8000 // Error
Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platforms/RPi3: Restructure platform in preparation for Pi 4
On 2019.10.21 15:39, Leif Lindholm wrote: On Mon, Oct 21, 2019 at 03:28:37PM +0100, Pete Batard wrote: Hi Leif, On 2019.10.21 14:46, Leif Lindholm wrote: On Mon, Oct 21, 2019 at 03:24:47PM +0200, Ard Biesheuvel wrote: On Mon, 21 Oct 2019 at 15:09, Philippe Mathieu-Daudé wrote: If anything, I guess we could consider that the non-osi patch should come first. Still, whatever we do here, as long as only one of non-osi and platform is applied, builds are going to be broken, and there is no way to fix that unless you do consider the set of platforms + non-osi as a single patch. Agreed, this is a egg/chicken problem. I dealt with this in the past by just making sure the non-osi and platform changes are applied at the same time. So it is good to make note of this in the cover letter, but other than that, there is no way we can apply interdependent changes to two separate repositories at the same time without either breaking bisect for one of them, or making a huge effort to add temporary code, defines etc that will be removed again right after the changes have landed. Agreed. My preference would be to treat edk2-non-osi as the chicken, and edk2-platforms the egg. I could put the requisite edk2-non-osi hash into the edk2-platforms commit message before pushing, adding a line like: "This commit requires the edk2-non-osi in use to contain commit in order to build." If I'm feeling nitpicky, that could replace the comment "No other changes are being applied at this stage." Pete: would you be OK with those two changes? Sounds good. Feel free to go ahead with these changes, thanks. In that case: Reviewed-by: Leif Lindholm Pushed as 03f36b8fcfb7. Thanks! Great, thanks! Do you know when the Pi4 upstreaming is likely to start? Well, as opposed to what was the case for the Pi 3 when we started upstreaming, we don't have a fully working Pi 4 platform yet (or at least, there's a fair amount of work left before we can put a checkmark against all the major elements we would like to see checked). So what we'll probably be aiming at is figure out some kind of minimum viable platform that can be officially submitted, that may not do much, but that we can then build upon in a more public and official manner. Now, since there are quite a few people involved on this one, and we need to discuss this internally, I doubt we're going to start publicly submitting anything Pi 4 related before one week at least. Figuring out what we want to submit, or even if we're truly at a stage where we have something proper to submit, is the current next step for us, as we wanted to make sure mainline was okay with the structure we are planning to go with before moving further (which makes the quick turnover on this patchset much appreciated!). For the record, we have a couple of staging repos at: https://github.com/samerhaj/edk2-platforms/tree/pi4_staging https://github.com/samerhaj/edk2-non-osi/tree/pi4_staging as well as Andrei Warkentin's main development tree (over which the repos above are based) at: https://github.com/andreiw/lampone-edk2-platforms/commits/pi4-hack https://github.com/andreiw/lampone-edk2-platforms/commits/master Of course, these are very much WIP still, and not something we can use to generate a patchset from. At this stage, I would say that our biggest issue, apart from various drivers not being finalized, is that mainline ARM Trusted Firmware has recently integrated support for the Pi 4 in a way that is completely different from what we went for (because there was no Trusted Firmware to start with, Andrei had to figure out his own, which was based on extending the Pi 3's). For starters they went for a BL31 only approach: https://github.com/ARM-software/arm-trusted-firmware/commit/f5cb15b0c886afaa41c5d3dad8e859b6a41f76ab. This means that, depending on how complex it might be to retrofit official ATF, we may submit an initial patchset that relies on our own binaries, and leave the switching to official ATF done at a later date... As you may have seen from my autoresponder, I'm traveling this week and next. Yes. We'll take that into account. I believe you might also meet with Samer (El-Haj-Mahmoud), who is participating in the Pi 4 porting effort (the first repos above are his). So feel free to ask for his views as well. I guess I'll wish you some pleasant and safe travels then. Regards, /Pete -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49317): https://edk2.groups.io/g/devel/message/49317 Mute This Topic: https://groups.io/mt/36312720/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] CryptoPkg: Upgrade OpenSSL to 1.1.1d
On 10/21/19 15:37, Liming Gao wrote: > Shenglei: > Those header files are added as the missing header file > @8906f076de35b222a7d62bcf6ed1a4a2498a5791. > Please keep them in INF file. If we needed to add those files manually to the INF file, then: - either the perl script ("process_files.pl") is wrong -- it should generate those file names too, - or we should have added the files *outside* of the following comments: # Autogenerated files list starts here # Autogenerated files list ends here Laszlo >> -Original Message- >> From: devel@edk2.groups.io On Behalf Of Zhang, >> Shenglei >> Sent: Monday, October 21, 2019 4:07 PM >> To: devel@edk2.groups.io >> Cc: Wang, Jian J ; Lu, XiaoyuX >> Subject: [edk2-devel] [PATCH] CryptoPkg: Upgrade OpenSSL to 1.1.1d >> >> Update openssl from 1.1.1b to 1.1.1d. >> Something needs to be noticed is that, there is a bug existing in the >> released 1_1_1d version(894da2fb7ed5d314ee5c2fc9fd2d9b8b74111596), >> which causes build failure. So we switch the code base to a usable >> version, which is 2 commits later than the stable tag. >> Now we use the version c3656cc594daac8167721dde7220f0e59ae146fc. >> This log is to fix the build failure. >> https://bugzilla.tianocore.org/show_bug.cgi?id=2226 >> >> Cc: Jian J Wang >> Cc: Xiaoyu Lu >> Signed-off-by: Shenglei Zhang >> --- >> CryptoPkg/Library/OpensslLib/OpensslLib.inf | 57 --- >> .../Library/OpensslLib/OpensslLibCrypto.inf | 49 >> CryptoPkg/Library/OpensslLib/openssl | 2 +- >> 3 files changed, 1 insertion(+), 107 deletions(-) >> >> diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf >> b/CryptoPkg/Library/OpensslLib/OpensslLib.inf >> index 7432321fd431..07c21ebeaa21 100644 >> --- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf >> +++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf >> @@ -34,9 +34,7 @@ [Sources] >>$(OPENSSL_PATH)/crypto/aes/aes_misc.c >>$(OPENSSL_PATH)/crypto/aes/aes_ofb.c >>$(OPENSSL_PATH)/crypto/aes/aes_wrap.c >> - $(OPENSSL_PATH)/crypto/aes/aes_locl.h >>$(OPENSSL_PATH)/crypto/aria/aria.c >> - $(OPENSSL_PATH)/crypto/arm_arch.h >>$(OPENSSL_PATH)/crypto/asn1/a_bitstr.c >>$(OPENSSL_PATH)/crypto/asn1/a_d2i_fp.c >>$(OPENSSL_PATH)/crypto/asn1/a_digest.c >> @@ -101,21 +99,12 @@ [Sources] >>$(OPENSSL_PATH)/crypto/asn1/x_sig.c >>$(OPENSSL_PATH)/crypto/asn1/x_spki.c >>$(OPENSSL_PATH)/crypto/asn1/x_val.c >> - $(OPENSSL_PATH)/crypto/asn1/standard_methods.h >> - $(OPENSSL_PATH)/crypto/asn1/charmap.h >> - $(OPENSSL_PATH)/crypto/asn1/tbl_standard.h >> - $(OPENSSL_PATH)/crypto/asn1/asn1_item_list.h >> - $(OPENSSL_PATH)/crypto/asn1/asn1_locl.h >>$(OPENSSL_PATH)/crypto/async/arch/async_null.c >>$(OPENSSL_PATH)/crypto/async/arch/async_posix.c >>$(OPENSSL_PATH)/crypto/async/arch/async_win.c >>$(OPENSSL_PATH)/crypto/async/async.c >>$(OPENSSL_PATH)/crypto/async/async_err.c >>$(OPENSSL_PATH)/crypto/async/async_wait.c >> - $(OPENSSL_PATH)/crypto/async/arch/async_win.h >> - $(OPENSSL_PATH)/crypto/async/async_locl.h >> - $(OPENSSL_PATH)/crypto/async/arch/async_posix.h >> - $(OPENSSL_PATH)/crypto/async/arch/async_null.h >>$(OPENSSL_PATH)/crypto/bio/b_addr.c >>$(OPENSSL_PATH)/crypto/bio/b_dump.c >>$(OPENSSL_PATH)/crypto/bio/b_sock.c >> @@ -138,7 +127,6 @@ [Sources] >>$(OPENSSL_PATH)/crypto/bio/bss_mem.c >>$(OPENSSL_PATH)/crypto/bio/bss_null.c >>$(OPENSSL_PATH)/crypto/bio/bss_sock.c >> - $(OPENSSL_PATH)/crypto/bio/bio_lcl.h >>$(OPENSSL_PATH)/crypto/bn/bn_add.c >>$(OPENSSL_PATH)/crypto/bn/bn_asm.c >>$(OPENSSL_PATH)/crypto/bn/bn_blind.c >> @@ -170,9 +158,6 @@ [Sources] >>$(OPENSSL_PATH)/crypto/bn/bn_srp.c >>$(OPENSSL_PATH)/crypto/bn/bn_word.c >>$(OPENSSL_PATH)/crypto/bn/bn_x931p.c >> - $(OPENSSL_PATH)/crypto/bn/rsaz_exp.h >> - $(OPENSSL_PATH)/crypto/bn/bn_prime.h >> - $(OPENSSL_PATH)/crypto/bn/bn_lcl.h >>$(OPENSSL_PATH)/crypto/buffer/buf_err.c >>$(OPENSSL_PATH)/crypto/buffer/buffer.c >>$(OPENSSL_PATH)/crypto/cmac/cm_ameth.c >> @@ -181,7 +166,6 @@ [Sources] >>$(OPENSSL_PATH)/crypto/comp/c_zlib.c >>$(OPENSSL_PATH)/crypto/comp/comp_err.c >>$(OPENSSL_PATH)/crypto/comp/comp_lib.c >> - $(OPENSSL_PATH)/crypto/comp/comp_lcl.h >>$(OPENSSL_PATH)/crypto/conf/conf_api.c >>$(OPENSSL_PATH)/crypto/conf/conf_def.c >>$(OPENSSL_PATH)/crypto/conf/conf_err.c >> @@ -190,8 +174,6 @@ [Sources] >>$(OPENSSL_PATH)/crypto/conf/conf_mod.c >>$(OPENSSL_PATH)/crypto/conf/conf_sap.c >>$(OPENSSL_PATH)/crypto/conf/conf_ssl.c >> - $(OPENSSL_PATH)/crypto/conf/conf_lcl.h >> - $(OPENSSL_PATH)/crypto/conf/conf_def.h >>$(OPENSSL_PATH)/crypto/cpt_err.c >>$(OPENSSL_PATH)/crypto/cryptlib.c >>$(OPENSSL_PATH)/crypto/ctype.c >> @@ -215,8 +197,6 @@ [Sources] >>$(OPENSSL_PATH)/crypto/des/set_key.c >>$(OPENSSL_PATH)/crypto/des/str2key.c >>$(OPENSSL_PATH)/crypto/des/xcbc_enc.c >> -
Re: [edk2-devel] [PATCH v2 1/1] NetworkPkg/SnpDxe: Remove ExitBootServices event
Siyuan, One comment on this patch is that the C code is using FixedPcdGetPool() instead of PcdGetBool(). The FixedPcdGetBool() is only recommended when the PCD type is guaranteed to be FixedAtBuild and the PCD value must be known at compile, with a constant value, usually to initialize fields in data structures or when the PCD value is used in assembly code. Since this PCD supports both Fixed and Patchable and is used in if statements, I recommend PcdGetBool() be used. Thanks, Mike > -Original Message- > From: devel@edk2.groups.io On > Behalf Of Siyuan, Fu > Sent: Sunday, October 20, 2019 7:42 PM > To: Rabeda, Maciej ; > devel@edk2.groups.io > Cc: Wu, Jiaxin > Subject: Re: [edk2-devel] [PATCH v2 1/1] > NetworkPkg/SnpDxe: Remove ExitBootServices event > > Reviewed-by: Siyuan Fu > > > -Original Message- > > From: Rabeda, Maciej > > Sent: 2019年10月14日 20:37 > > To: devel@edk2.groups.io > > Cc: Fu, Siyuan ; Wu, Jiaxin > > > Subject: [PATCH v2 1/1] NetworkPkg/SnpDxe: Remove > ExitBootServices > > event > > > > Patch addresses Bugzilla #1972. > > During ExitBootServices stage, drivers should not > call any functions > > known to use Memory Allocation Services. One of such > functions (as per > > UEFI spec) is UNDI->Shutdown(). > > > > Since UNDI drivers during ExitBootServices phase are > expected to put > > the adapter to such a state that it will not perform > any DMA > > operations, there is no need to interface UNDI by SNP > driver during > > that phase. > > > > Finally, since ExitBootServices event notification > function in SNP > > only calls UNDI->Shutdown() and Stop() functions, > there is no need to > > create this event at all. Adding PCD to control > creation of event > > reacting to ExitBootServices() call so that systems > with UNDIs relying > > on SNP to call their Shutdown() and Stop() can still > work. > > > > Signed-off-by: Maciej Rabeda > > > Cc: Siyuan Fu > > Cc: Jiaxin Wu > > --- > > > > Notes: > > v2: > > - modified commit message > > - added PCD to control ExitBootServices() > creation event in SnpDxe > > > > NetworkPkg/SnpDxe/Snp.c | 38 +++--- > -- > > NetworkPkg/NetworkPkg.dec| 7 > > NetworkPkg/SnpDxe/Snp.h | 1 + > > NetworkPkg/SnpDxe/SnpDxe.inf | 3 ++ > > 4 files changed, 32 insertions(+), 17 deletions(-) > > > > diff --git a/NetworkPkg/SnpDxe/Snp.c > b/NetworkPkg/SnpDxe/Snp.c index > > a23af05078bc..03317ffa26f1 100644 > > --- a/NetworkPkg/SnpDxe/Snp.c > > +++ b/NetworkPkg/SnpDxe/Snp.c > > @@ -647,19 +647,21 @@ SimpleNetworkDriverStart ( > >PxeShutdown (Snp); > >PxeStop (Snp); > > > > - // > > - // Create EXIT_BOOT_SERIVES Event > > - // > > - Status = gBS->CreateEventEx ( > > - EVT_NOTIFY_SIGNAL, > > - TPL_NOTIFY, > > - SnpNotifyExitBootServices, > > - Snp, > > - , > > - >ExitBootServicesEvent > > - ); > > - if (EFI_ERROR (Status)) { > > -goto Error_DeleteSNP; > > + if (FixedPcdGetBool > (PcdSnpCreateExitBootServicesEvent)) { > > +// > > +// Create EXIT_BOOT_SERIVES Event > > +// > > +Status = gBS->CreateEventEx ( > > +EVT_NOTIFY_SIGNAL, > > +TPL_NOTIFY, > > +SnpNotifyExitBootServices, > > +Snp, > > +, > > +>ExitBootServicesEvent > > +); > > +if (EFI_ERROR (Status)) { > > + goto Error_DeleteSNP; > > +} > >} > > > >// > > @@ -778,10 +780,12 @@ SimpleNetworkDriverStop ( > > return Status; > >} > > > > - // > > - // Close EXIT_BOOT_SERIVES Event > > - // > > - gBS->CloseEvent (Snp->ExitBootServicesEvent); > > + if (FixedPcdGetBool > (PcdSnpCreateExitBootServicesEvent)) { > > +// > > +// Close EXIT_BOOT_SERIVES Event > > +// > > +gBS->CloseEvent (Snp->ExitBootServicesEvent); } > > > >Status = gBS->CloseProtocol ( > >Controller, > > diff --git a/NetworkPkg/NetworkPkg.dec > b/NetworkPkg/NetworkPkg.dec > > index 944b1d1501c0..66e500cbeaf7 100644 > > --- a/NetworkPkg/NetworkPkg.dec > > +++ b/NetworkPkg/NetworkPkg.dec > > @@ -109,6 +109,13 @@ > ># @Prompt TFTP block size. > > > > > gEfiNetworkPkgTokenSpaceGuid.PcdTftpBlockSize|0x0|UINT6 > 4|0x100B > > > > + ## Indicates whether SnpDxe driver will create an > event that will > > + be > > notified > > + # upon gBS->ExitBootServices() call. > > + # TRUE - Event being triggered upon > ExitBootServices call will be > > + created # FALSE - Event being triggered upon > ExitBootServices call > > + will NOT be > > created > > + # @Prompt Indicates whether SnpDxe creates event > for > > + ExitBootServices() > > call. > > + > > > gEfiNetworkPkgTokenSpaceGuid.PcdSnpCreateExitBootServic > esEvent|TRUE| > > BOOLEAN|0x100C > > + > > [PcdsFixedAtBuild, PcdsPatchableInModule, > PcdsDynamic,
Re: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs
Hi Scott, I would agree that the current logic that checks for uniqueness applies to V3+ of an EFI_FIRMWARE_IMAGE_DESCRITOR. Below V3, the HardwareInstance field does not exist, so I agree that the uniqueness check and ASSERT can not be done. The language around V3 that introduced fields like HardwareInstance sites examples like PCI add-in cards as to why the field was added. So I would not expect to see an FMP instance from a PCI add-in card that is below V3. If we remove the uniqueness check and ASSERT at versions below V2, then we need to also review the capsule processing to determine how capsules are processed. If the capsule has a non zero HardwareInstance and the FMP with the matching GUID is below V3, is the capsule ignored? Perhaps only capsules with a zero HardwareInstance value can be dispatched to an FMP with version below V3? Thanks, Mike From: scott.wigin...@hpe.com Sent: Monday, October 21, 2019 6:12 AM To: Kinney, Michael D ; devel@edk2.groups.io Subject: Re: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs Michael, Wouldn't the current implementation ASSERT if there are different plug-in cards by the same vendor using the same GUID in their FMP? They are managing different hardware and have no knowledge of the existence of the other FMP instance. Each FMP is only aware of the specific device on whose handle they are installed. If they use FW image descriptors below version 2 (or they cannot determine a unique HW instance), this would always be 0. Why would we want to ASSERT in this case? What error condition is being caught? Thanks, SWig -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49314): https://edk2.groups.io/g/devel/message/49314 Mute This Topic: https://groups.io/mt/34350126/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] CryptoPkg: Upgrade OpenSSL to 1.1.1d
On 10/21/19 10:06, Zhang, Shenglei wrote: > Update openssl from 1.1.1b to 1.1.1d. > Something needs to be noticed is that, there is a bug existing in the > released 1_1_1d version(894da2fb7ed5d314ee5c2fc9fd2d9b8b74111596), > which causes build failure. So we switch the code base to a usable > version, which is 2 commits later than the stable tag. > Now we use the version c3656cc594daac8167721dde7220f0e59ae146fc. > This log is to fix the build failure. > https://bugzilla.tianocore.org/show_bug.cgi?id=2226 > > Cc: Jian J Wang > Cc: Xiaoyu Lu > Signed-off-by: Shenglei Zhang > --- > CryptoPkg/Library/OpensslLib/OpensslLib.inf | 57 --- > .../Library/OpensslLib/OpensslLibCrypto.inf | 49 > CryptoPkg/Library/OpensslLib/openssl | 2 +- > 3 files changed, 1 insertion(+), 107 deletions(-) When I try to apply this patch manually, on top of current master (91f98c908627), then "git am" fails. However, if I try to reproduce this patch myself (advancing the submodule to c3656cc594da, and then running "process_files.pl"), then the result ("git diff") matches the code changes in the patch -- not counting CRLF vs. LF, anyway. (It seems like the "git am" failure is due to mixed line-endings within the patch -- the submodule reference hunk uses LFs, not CRLFs. I can live with that.) Having to use openssl at c3656cc594da is unfortunate, but I think it's justified. Unfortunately, with this update, the following build command fails for me (it may fail for other OVMF builds as well, this was simply my first attempt): $ nice build \ -a IA32 \ -p OvmfPkg/OvmfPkgIa32.dsc \ -t GCC48 \ -b DEBUG \ -D SMM_REQUIRE \ -D SECURE_BOOT_ENABLE \ -D NETWORK_IP6_ENABLE \ -D NETWORK_TLS_ENABLE \ -D NETWORK_HTTP_BOOT_ENABLE \ -D E1000_ENABLE \ -n 4 \ --report-file=$HOME/tmp/build.ovmf.32.report \ --log=$HOME/tmp/build.ovmf.32.log \ --cmd-len=65536 \ --genfds-multi-thread The directly failing command is: "gcc" \ -o Build/OvmfIa32/DEBUG_GCC48/IA32/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm/DEBUG/VariableSmm.dll \ -nostdlib \ -Wl,-n,-q,--gc-sections \ -z common-page-size=0x20 \ -Wl,--entry,_ModuleEntryPoint \ -u _ModuleEntryPoint \ -Wl,-Map,Build/OvmfIa32/DEBUG_GCC48/IA32/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm/DEBUG/VariableSmm.map,--whole-archive \ -Wl,-m,elf_i386,--oformat=elf32-i386 \ -z common-page-size=0x1000 \ -Wl,--start-group,@Build/OvmfIa32/DEBUG_GCC48/IA32/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm/OUTPUT/static_library_files.lst,--end-group \ -g \ -fshort-wchar \ -fno-builtin \ -fno-strict-aliasing \ -Wall \ -Werror \ -Wno-array-bounds \ -ffunction-sections \ -fdata-sections \ -include AutoGen.h \ -fno-common \ -DSTRING_ARRAY_NAME=VariableSmmStrings \ -m32 \ -march=i586 \ -malign-double \ -fno-stack-protector \ -D EFI32 \ -fno-asynchronous-unwind-tables \ -Wno-address \ -Os \ -mno-mmx \ -mno-sse \ -D DISABLE_NEW_DEPRECATED_INTERFACES \ -Wl,--defsym=PECOFF_HEADER_SIZE=0x220 \ -Wl,--script=BaseTools/Scripts/GccBase.lds And the error message: > Build/OvmfIa32/DEBUG_GCC48/IA32/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(dso_lib.obj): > In function `DSO_new_method': > CryptoPkg/Library/OpensslLib/openssl/crypto/dso/dso_lib.c:25: undefined > reference to `DSO_METHOD_openssl' > Build/OvmfIa32/DEBUG_GCC48/IA32/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib(dso_lib.obj): > In function `DSO_pathbyaddr': > CryptoPkg/Library/OpensslLib/openssl/crypto/dso/dso_lib.c:314: undefined > reference to `DSO_METHOD_openssl' This is strange, because the missing function is provided by "crypto/dso/dso_openssl.c", which is listed in the INF files. Hmmm. I ran the following command too: $ build \ -p CryptoPkg/CryptoPkg.dsc \ -a IA32 \ -b NOOPT \ -t GCC48 \ -m CryptoPkg/Library/OpensslLib/OpensslLib.inf This compiles OK. The last commands are: > rm -f > Build/CryptoPkg/NOOPT_GCC48/IA32/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib > > "ar" cr \ > > Build/CryptoPkg/NOOPT_GCC48/IA32/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib > \ > > @Build/CryptoPkg/NOOPT_GCC48/IA32/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/object_files.lst If I check the file Build/CryptoPkg/NOOPT_GCC48/IA32/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/object_files.lst I definitely see Build/CryptoPkg/NOOPT_GCC48/IA32/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/openssl/crypto/dso/dso_openssl.obj there. However, if I run nm Build/CryptoPkg/NOOPT_GCC48/IA32/CryptoPkg/Library/OpensslLib/OpensslLib/OUTPUT/OpensslLib.lib then the DSO_METHOD_openssl() symbol is reported as undefined: >
Re: [edk2-devel] [PATCH v1 0/2] Update the SRAT Acpiview parser to ACPI 6.3
Reviewed-by: Sami Mujawar Regards, Sami Mujawar -Original Message- From: Krzysztof Koch Sent: 12 June 2019 03:10 PM To: devel@edk2.groups.io Cc: jaben.car...@intel.com; ray...@intel.com; zhichao@intel.com; michael.d.kin...@intel.com; liming@intel.com; Sami Mujawar ; Matteo Carlini ; Stephanie Hughes-Fitt ; nd Subject: [PATCH v1 0/2] Update the SRAT Acpiview parser to ACPI 6.3 This patch adds a number of definitions to the ACPI 6.3 header file for the purpose of parsing Revision 3 of the System Resource Affinity Table (SRAT) in the Acpiview UEFI shell tool. By defining the Generic Initiator Affinity Structure's Type ID and the allowed Device Handle Types for the structure, it is possible to dump and validate the contents of the latest version of the SRAT table in acpiview. References: - ACPI 6.3 January 2019, Section 5.2.16.6 Changes can be seen at: https://github.com/KrzysztofKoch1/edk2/tree/582_acpiview_6_3_srat_v1 Krzysztof Koch (2): MdePkg: Add Generic Initiator Affinity Structure definitions to SRAT ShellPkg: acpiview: Update SRAT parser to ACPI 6.3 MdePkg/Include/IndustryStandard/Acpi63.h | 11 +- ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c | 35 ++- ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.h | 16 ++ ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Srat/SratParser.c | 256 +++- 4 files changed, 309 insertions(+), 9 deletions(-) -- 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)' -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49312): https://edk2.groups.io/g/devel/message/49312 Mute This Topic: https://groups.io/mt/32042460/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] EDK2 UEFI Specification and Revision
The header in the EFI_SYSTEM_TABLE (gST) carries the UEFI Specification version. It is filled in by the DXE Core when it produces the EFI System Table. $ git grep EFI_SYSTEM_TABLE_REVISION MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c:126:EFI_SYSTEM_TABLE_REVISION, // Revision MdeModulePkg/Universal/SetupBrowserDxe/Setup.h:74:#define EFI_IFR_SPECIFICATION_VERSION (UINT16) (((EFI_SYSTEM_TABLE_REVISION >> 16) << 8) | (((EFI_SYSTEM_TABLE_REVISION & 0x) / 10) << 4) | ((EFI_SYSTEM_TABLE_REVISION & 0x) % 10)) MdePkg/Include/Uefi/UefiSpec.h:1780:#define EFI_SYSTEM_TABLE_REVISION EFI_2_70_SYSTEM_TABLE_REVISION MdePkg/Include/Uefi/UefiSpec.h:1781:#define EFI_SPECIFICATION_VERSION EFI_SYSTEM_TABLE_REVISION $ git grep EFI_2_70_SYSTEM_TABLE_REVISION MdePkg/Include/Uefi/UefiSpec.h:1769:#define EFI_2_70_SYSTEM_TABLE_REVISION ((2 << 16) | (70)) MdePkg/Include/Uefi/UefiSpec.h:1780:#define EFI_SYSTEM_TABLE_REVISION EFI_2_70_SYSTEM_TABLE_REVISION Thanks, Andrew Fish > On Oct 21, 2019, at 1:15 AM, serges...@yandex.ru wrote: > > When runs "ver" command in EFI Shell command line it shows UEFI specification > and revision. The question is how to find out what UEFI specification and > revision does EDK2 support? > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49311): https://edk2.groups.io/g/devel/message/49311 Mute This Topic: https://groups.io/mt/36319430/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] EDK2 UEFI Specification and Revision
When runs "ver" command in EFI Shell command line it shows UEFI specification and revision. The question is how to find out what UEFI specification and revision does EDK2 support? -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49309): https://edk2.groups.io/g/devel/message/49309 Mute This Topic: https://groups.io/mt/36319430/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH] MdePkg/UefiDebugLibStdErr: Pass the correct buffer size
From: Marvin Haeuser REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2302 The second argument of "UnicodeVSPrintAsciiFormat" is "BufferSize", which takes the size of the buffer in bytes. Replace the currently used MAX_DEBUG_MESSAGE_LENGTH usage, which is the buffer's length, with the actual buffer size. Cc: Michael D Kinney Cc: Liming Gao Signed-off-by: Marvin Haeuser --- MdePkg/Library/UefiDebugLibStdErr/DebugLib.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/MdePkg/Library/UefiDebugLibStdErr/DebugLib.c b/MdePkg/Library/UefiDebugLibStdErr/DebugLib.c index 40eb697e7e2c..fcfdafede08f 100644 --- a/MdePkg/Library/UefiDebugLibStdErr/DebugLib.c +++ b/MdePkg/Library/UefiDebugLibStdErr/DebugLib.c @@ -106,9 +106,9 @@ DebugPrintMarker ( // Convert the DEBUG() message to a Unicode String // if (BaseListMarker == NULL) { - UnicodeVSPrintAsciiFormat (Buffer, MAX_DEBUG_MESSAGE_LENGTH, Format, VaListMarker); + UnicodeVSPrintAsciiFormat (Buffer, sizeof (Buffer), Format, VaListMarker); } else { - UnicodeBSPrintAsciiFormat (Buffer, MAX_DEBUG_MESSAGE_LENGTH, Format, BaseListMarker); + UnicodeBSPrintAsciiFormat (Buffer, sizeof (Buffer), Format, BaseListMarker); } // -- 2.23.0.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49310): https://edk2.groups.io/g/devel/message/49310 Mute This Topic: https://groups.io/mt/36272499/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [plaforms/devel-riscv-v2 PATCHv2 09/14] U500Pkg/Library: Initial version of PlatformBootManagerLib
On Fri, Oct 18, 2019 at 06:23:05AM +, Abner Chang wrote: > > -Original Message- > > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of > > Leif Lindholm > > Sent: Thursday, October 3, 2019 6:03 AM > > To: devel@edk2.groups.io; Chen, Gilbert > > Cc: Palmer Dabbelt > > Subject: Re: [edk2-devel] [plaforms/devel-riscv-v2 PATCHv2 09/14] > > U500Pkg/Library: Initial version of PlatformBootManagerLib > > > > On Thu, Sep 19, 2019 at 11:51:26AM +0800, Gilbert Chen wrote: > > > SiFive RISC-V U500 Platform Boot Manager library. > > > > First of all, let me say that I think before upstreaming to master, you > > ought to > > look into merging PlatformBootManagerLibs for all Risc-V platforms. Like we > > have for *most* ARM/AARCH64 platforms with > > ArmPkg/Library/PlatformBootManagerLib/. > > > > (Longer-term we should merge them all together into a single one.) > > > > > Signed-off-by: Gilbert Chen > > > --- > > > .../Library/PlatformBootManagerLib/MemoryTest.c| 682 > > + > > > .../PlatformBootManagerLib/PlatformBootManager.c | 274 + > > > .../PlatformBootManagerLib/PlatformBootManager.h | 135 > > > .../PlatformBootManagerLib.inf | 63 ++ > > > .../Library/PlatformBootManagerLib/PlatformData.c | 49 ++ > > > .../Library/PlatformBootManagerLib/Strings.uni | 28 + > > > 6 files changed, 1231 insertions(+) > > > create mode 100644 > > > > > Platform/RiscV/SiFive/U500Pkg/Library/PlatformBootManagerLib/MemoryT > > es > > > t.c create mode 100644 > > > > > Platform/RiscV/SiFive/U500Pkg/Library/PlatformBootManagerLib/PlatformB > > > ootManager.c create mode 100644 > > > > > Platform/RiscV/SiFive/U500Pkg/Library/PlatformBootManagerLib/PlatformB > > > ootManager.h create mode 100644 > > > > > Platform/RiscV/SiFive/U500Pkg/Library/PlatformBootManagerLib/PlatformB > > > ootManagerLib.inf create mode 100644 > > > > > Platform/RiscV/SiFive/U500Pkg/Library/PlatformBootManagerLib/PlatformD > > > ata.c create mode 100644 > > > Platform/RiscV/SiFive/U500Pkg/Library/PlatformBootManagerLib/Strings.u > > > ni > > > > > > diff --git > > > > > a/Platform/RiscV/SiFive/U500Pkg/Library/PlatformBootManagerLib/Memory > > T > > > est.c > > > > > b/Platform/RiscV/SiFive/U500Pkg/Library/PlatformBootManagerLib/Memor > > yT > > > est.c > > > new file mode 100644 > > > index ..8c6d89e9 > > > --- /dev/null > > > +++ > > b/Platform/RiscV/SiFive/U500Pkg/Library/PlatformBootManagerLib/Mem > > > +++ oryTest.c > > > > Why build a MemoryTest into the PlatformBootManagerLib? > > Why not to do memory if platform provides memory test protocol? The question was why build it into the PlatformBootManagerLib? I would much prefer something like what is done in existing plaforms with gEfiGenericMemTestProtocolGuid. > > > > > @@ -0,0 +1,682 @@ > > > +/** @file > > > + Perform the RISC-V platform memory test > > > + > > > +Copyright (c) 2019, Hewlett Packard Enterprise Development LP. All > > > +rights reserved. Copyright (c) 2004 - 2015, Intel Corporation. > > > +All rights reserved. > > > + > > > +SPDX-License-Identifier: BSD-2-Clause-Patent > > > + > > > +**/ > > > + > > > +#include "PlatformBootManager.h" > > > + > > > +EFI_HII_HANDLE gStringPackHandle = NULL; > > > +EFI_GUID mPlatformBootManagerStringPackGuid = { > > > + 0x154dd51, 0x9079, 0x4a10, { 0x89, 0x5c, 0x9c, 0x7, 0x72, 0x81, > > > +0x57, 0x88 } > > > + }; > > > +// extern UINT8 BdsDxeStrings[]; > > > > No need to keep commented-out code in. > > > > > + > > > +// > > > +// BDS Platform Functions > > > +// > > > +/** > > > + > > > + Show progress bar with title above it. It only works in Graphics mode. > > > + > > > + @param TitleForeground Foreground color for Title. > > > + @param TitleBackground Background color for Title. > > > + @param Title Title above progress bar. > > > + @param ProgressColor Progress bar color. > > > + @param ProgressProgress (0-100) > > > + @param PreviousValue The previous value of the progress. > > > + > > > + @retval EFI_STATUS Success update the progress bar > > > + > > > +**/ > > > +EFI_STATUS > > > +PlatformBootManagerShowProgress ( > > > > I'm not a super fan of how this file integrates a custom memory test with a > > direct (copy) graphical progress indicator. There are both common memory > > test and common progress indicators - please use those instead. And > > improve them if they are currently insufficient for your needs. > > Could you indicate where are those common libraries? Thanks. There is MdeModulePkg/Library/DisplayUpdateProgressLibGraphics and MdeModulePkg/Library/DisplayUpdateProgressLibText. / Leif -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49308): https://edk2.groups.io/g/devel/message/49308 Mute This Topic: https://groups.io/mt/34196357/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe:
Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platforms/RPi3: Restructure platform in preparation for Pi 4
On Mon, Oct 21, 2019 at 03:28:37PM +0100, Pete Batard wrote: > Hi Leif, > > On 2019.10.21 14:46, Leif Lindholm wrote: > > On Mon, Oct 21, 2019 at 03:24:47PM +0200, Ard Biesheuvel wrote: > > > On Mon, 21 Oct 2019 at 15:09, Philippe Mathieu-Daudé > > > wrote: > > > > > If anything, I guess we could consider that the non-osi patch should > > > > > come first. Still, whatever we do here, as long as only one of non-osi > > > > > and platform is applied, builds are going to be broken, and there is > > > > > no > > > > > way to fix that unless you do consider the set of platforms + non-osi > > > > > as > > > > > a single patch. > > > > > > > > Agreed, this is a egg/chicken problem. > > > > > > I dealt with this in the past by just making sure the non-osi and > > > platform changes are applied at the same time. So it is good to make > > > note of this in the cover letter, but other than that, there is no way > > > we can apply interdependent changes to two separate repositories at > > > the same time without either breaking bisect for one of them, or > > > making a huge effort to add temporary code, defines etc that will be > > > removed again right after the changes have landed. > > > > Agreed. My preference would be to treat edk2-non-osi as the chicken, > > and edk2-platforms the egg. I could put the requisite edk2-non-osi > > hash into the edk2-platforms commit message before pushing, adding a > > line like: > > > > "This commit requires the edk2-non-osi in use to contain commit > > in order to build." > > > > If I'm feeling nitpicky, that could replace the comment > > "No other changes are being applied at this stage." > > > > Pete: would you be OK with those two changes? > > Sounds good. Feel free to go ahead with these changes, thanks. In that case: Reviewed-by: Leif Lindholm Pushed as 03f36b8fcfb7. Thanks! Do you know when the Pi4 upstreaming is likely to start? As you may have seen from my autoresponder, I'm traveling this week and next. Best Regards, Leif (from the backseat of a car going down the M25) -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49307): https://edk2.groups.io/g/devel/message/49307 Mute This Topic: https://groups.io/mt/36312720/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-non-osi][PATCH 1/1] Platforms/RPi3: Restructure platform in preparation for Pi 4
On Mon, Oct 21, 2019 at 03:09:58PM +0200, Philippe Mathieu-Daudé wrote: > On 10/21/19 1:25 PM, Pete Batard wrote: > > Similar to what is being done in edk2-platforms, elements of the Pi 3 > > platform that can be factorized for use with the Pi 4 are factorized. > > > > For non-OSI this only applies to the Logo driver, as the Device Tree > > and the Trusted Firmware are of course too platform specific to be > > factorized. > > > > Signed-off-by: Pete Batard > > --- > > Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/License.txt | 0 > > Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/Logo.bmp | Bin > > Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/Logo.c | 0 > > Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/Logo.eps | Bin > > Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/Logo.idf | 0 > > Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/Logo.inf | 0 > > Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/Logo.uni | 0 > > Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/LogoDxe.inf | 0 > > Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/LogoDxe.uni | 0 > > Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/LogoDxeExtra.uni | 0 > > Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/LogoExtra.uni| 0 > > 11 files changed, 0 insertions(+), 0 deletions(-) > > > > Reviewed-by: Philippe Mathieu-Daude Reviewed-by: Leif Lindholm Pushed as 243e55f622ea. / Leif -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49306): https://edk2.groups.io/g/devel/message/49306 Mute This Topic: https://groups.io/mt/36312724/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platforms/RPi3: Restructure platform in preparation for Pi 4
Hi Leif, On 2019.10.21 14:46, Leif Lindholm wrote: On Mon, Oct 21, 2019 at 03:24:47PM +0200, Ard Biesheuvel wrote: On Mon, 21 Oct 2019 at 15:09, Philippe Mathieu-Daudé wrote: On 10/21/19 2:52 PM, Pete Batard wrote: Hi Philippe, On 2019.10.21 13:28, Philippe Mathieu-Daudé wrote: Hi Pete, On 10/21/19 1:25 PM, Pete Batard wrote: In preparation for adding Raspberry Pi 4 support, the Pi 3 platform is restructured by factorizing all the drivers and libraries that are going to be commonly used by the two platforms. Because much of the Pi 4 SoC is an extension of the Pi 3 one this means that almost everything, except the ACPI tables, is moved up into a new common RaspberryPi/ subdirectory that will serve both platforms. The .dec is also moved to this directory, under a new RaspberryPi.dec name, and existing references to it are updated. ... This change seems not related to the rest of your refactor. It is. See https://edk2.groups.io/g/devel/message/49288 The problem is we have no choice but to break the patch in two sections, one that applies to edk2-platforms and the other to edk2-non-osi, since these are separate repos, and the LogoDxe changes belong to non-osi. We need to have part of the non-osi patch that is applied to edk2-platforms, and it would make little sense to break it down into the non-osi related and platforms related, since it still relies on the non-osi changes having been applied. I see. If anything, I guess we could consider that the non-osi patch should come first. Still, whatever we do here, as long as only one of non-osi and platform is applied, builds are going to be broken, and there is no way to fix that unless you do consider the set of platforms + non-osi as a single patch. Agreed, this is a egg/chicken problem. I dealt with this in the past by just making sure the non-osi and platform changes are applied at the same time. So it is good to make note of this in the cover letter, but other than that, there is no way we can apply interdependent changes to two separate repositories at the same time without either breaking bisect for one of them, or making a huge effort to add temporary code, defines etc that will be removed again right after the changes have landed. Agreed. My preference would be to treat edk2-non-osi as the chicken, and edk2-platforms the egg. I could put the requisite edk2-non-osi hash into the edk2-platforms commit message before pushing, adding a line like: "This commit requires the edk2-non-osi in use to contain commit in order to build." If I'm feeling nitpicky, that could replace the comment "No other changes are being applied at this stage." Pete: would you be OK with those two changes? Sounds good. Feel free to go ahead with these changes, thanks. /Pete Best Regards, Leif -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49305): https://edk2.groups.io/g/devel/message/49305 Mute This Topic: https://groups.io/mt/36312720/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 1/1] DynamicTablesPkg: Arm SRAT Table Generator
Reviewed-by: Alexei Fedorov alexei.fedo...@arm.com -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49304): https://edk2.groups.io/g/devel/message/49304 Mute This Topic: https://groups.io/mt/36317090/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [PATCH v1 1/1] DynamicTablesPkg: Arm SRAT Table Generator
The SRAT generator uses the configuration manager protocol to obtain the affinity information for the GICC, GIC ITS, Memory, Generic Initiator, etc. and generates the SRAT table. The table generator supports ACPI 6.3, SRAT table revision 3. The ACPI and PCI device handles of the Generic Initiator Affinity structures are represented using tokens. The generator invokes the configuration manager protocol interfaces and requests for objects referenced by tokens to get the device handle information. The Configuration Manager object definition for the GICC has been updated to include the Proximity Domain, Clock Domain and associated flag information. Similarly the Configuration Manager object for the GIC ITS has been updated to include the Proximity Domain information. These changes should not impact any existing implementations as the new fields have been added towards the end of the Configuration Manager Objects. Signed-off-by: Sami Mujawar --- The changes can be seen at https://github.com/samimujawar/edk2/tree/672_dynamic_tables_srat_generator_v1 Notes: v1: - Added support for SRAT table generation using Dynamic Tables[SAMI] DynamicTablesPkg/DynamicTables.dsc.inc | 1 + DynamicTablesPkg/Include/AcpiTableGenerator.h | 3 + DynamicTablesPkg/Include/ArmNameSpaceObjects.h | 157 +++- DynamicTablesPkg/Library/Acpi/Arm/AcpiSratLibArm/AcpiSratLibArm.inf | 29 + DynamicTablesPkg/Library/Acpi/Arm/AcpiSratLibArm/SratGenerator.c| 835 5 files changed, 994 insertions(+), 31 deletions(-) diff --git a/DynamicTablesPkg/DynamicTables.dsc.inc b/DynamicTablesPkg/DynamicTables.dsc.inc index 142832b9fa9c2cd4b73935abf4114c3fa7b26d95..0bf7a77cf2dcf82135f52a834774769bb06ba21a 100644 --- a/DynamicTablesPkg/DynamicTables.dsc.inc +++ b/DynamicTablesPkg/DynamicTables.dsc.inc @@ -30,6 +30,7 @@ [Components.common] NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiPpttLibArm/AcpiPpttLibArm.inf NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiRawLibArm/AcpiRawLibArm.inf NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiSpcrLibArm/AcpiSpcrLibArm.inf + NULL|DynamicTablesPkg/Library/Acpi/Arm/AcpiSratLibArm/AcpiSratLibArm.inf } # diff --git a/DynamicTablesPkg/Include/AcpiTableGenerator.h b/DynamicTablesPkg/Include/AcpiTableGenerator.h index 7d6d3442276db7b4abaeb3b053ba489258adea0b..e46717e6e8442ec516ef79ea979bd29e070f6d0a 100644 --- a/DynamicTablesPkg/Include/AcpiTableGenerator.h +++ b/DynamicTablesPkg/Include/AcpiTableGenerator.h @@ -53,6 +53,8 @@ The Dynamic Tables Framework implements the following ACPI table generators: Configuration Manager and builds the IORT table. - PPTT : The PPTT generator collates the processor topology information from the Configuration Manager and builds the PPTT table. + - SRAT : The SRAT generator collates the system resource affinity information +from the Configuration Manager and builds the SRAT table. */ /** The ACPI_TABLE_GENERATOR_ID type describes ACPI table generator ID. @@ -75,6 +77,7 @@ typedef enum StdAcpiTableId { EStdAcpiTableIdMcfg, ///< MCFG Generator EStdAcpiTableIdIort, ///< IORT Generator EStdAcpiTableIdPptt, ///< PPTT Generator + EStdAcpiTableIdSrat, ///< SRAT Generator EStdAcpiTableIdMax } ESTD_ACPI_TABLE_ID; diff --git a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h index ac451b306dfd7ba299a83209675b21696be235be..da70cba2037592f02c72c026dc32f90b67bec8db 100644 --- a/DynamicTablesPkg/Include/ArmNameSpaceObjects.h +++ b/DynamicTablesPkg/Include/ArmNameSpaceObjects.h @@ -21,37 +21,41 @@ in the ARM Namespace */ typedef enum ArmObjectID { - EArmObjReserved,///< 0 - Reserved - EArmObjBootArchInfo,///< 1 - Boot Architecture Info - EArmObjCpuInfo, ///< 2 - CPU Info - EArmObjPowerManagementProfileInfo, ///< 3 - Power Management Profile Info - EArmObjGicCInfo,///< 4 - GIC CPU Interface Info - EArmObjGicDInfo,///< 5 - GIC Distributor Info - EArmObjGicMsiFrameInfo, ///< 6 - GIC MSI Frame Info - EArmObjGicRedistributorInfo,///< 7 - GIC Redistributor Info - EArmObjGicItsInfo, ///< 8 - GIC ITS Info - EArmObjSerialConsolePortInfo, ///< 9 - Serial Console Port Info - EArmObjSerialDebugPortInfo, ///< 10 - Serial Debug Port Info - EArmObjGenericTimerInfo,///< 11 - Generic Timer Info - EArmObjPlatformGTBlockInfo, ///< 12 - Platform GT Block Info - EArmObjGTBlockTimerFrameInfo, ///< 13 - Generic Timer Block Frame Info - EArmObjPlatformGenericWatchdogInfo, ///< 14 - Platform Generic Watchdog - EArmObjPciConfigSpaceInfo, ///< 15 - PCI
Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe string constraint assertions
On 10/21/19 11:58, Vitaly Cheptsov via Groups.Io wrote: > Jiewen, > > We are aware of all these nuances, and you are right that both of them > (strlcpy/strcpy_s) have their downsides. Our opinion is that strlcpy > is more practical, but that is a personal choice, and we do nor care > much on what is available as long as it is documented. > > Our primary issues are not really with string copying, but rather with > other interfaces. For example: > - We use AsciiStrToGuid to convert a string to a GUID in the user > configuration file, and any intentional or unintentionsl typo there > may result in halting the entire app due to length assertion in > DEBUG builds. > - We use AsciiStrCats to append messages to the log buffer as long as > they fit. We do not care what happens when they stop to fit, for us > that means we will have a cut log and a handled error that some > messages did not fit. However, in DEBUG builds that once again > results in halts. > > I am pretty sure there were more, but the use cases are be pretty > similar, so you most likely get an idea. We do handle the error where > necessary, yet we do not expect the code to halt before we can handle > the error. (Since I've been CC'd somewhere mid-thread, I'll offer an opinion...) - For copying strings, I'm with Ulrich Drepper: http://www.sourceware.org/ml/libc-alpha/2000-08/msg00061.html "Every program which is handling strings has to know how long they are." Because I share that opinion, I've never considered the "safe string" functions extremely helpful. - For formatting strings, and especially for parsing strings, I tend to consider functions that cannot deal, by design, with untrusted input, more or less useless. When I was initially working on OvmfPkg/Library/QemuBootOrderLib, and had to parse some hex strings (as parts of OpenFirmware device paths exported by QEMU), I believe I looked for suitable utility functions in edk2 elsewhere. Ultimately I wrote my own ParseUnitAddressHexList() function. A note specific to my use case (= guest firmware): in theory, the host has complete control over the guest, so one might claim that the guest should never sanity check input from the host (= the guest should always blindly trust input from the host). That has never sat well with me, although I couldn't really tell why; it's just always felt wrong. Later, my concern has been vindicated in two ways: first, in the ACPI linker/loader client, those sanity checks helped identify QEMU issues (not malicious intent for sure, but mistakes nonetheless); and then, we now have SEV (Secure Encrypted Virtualization), where host software does not have full control over the guest. IMO all parser functions (exposed as general utility functions) should expect malicious input by default. (Another example I've been involved with: the base64 decoder.) Thanks Laszlo -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49302): https://edk2.groups.io/g/devel/message/49302 Mute This Topic: https://groups.io/mt/35943317/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platforms/RPi3: Restructure platform in preparation for Pi 4
On Mon, Oct 21, 2019 at 03:24:47PM +0200, Ard Biesheuvel wrote: > On Mon, 21 Oct 2019 at 15:09, Philippe Mathieu-Daudé > wrote: > > > > On 10/21/19 2:52 PM, Pete Batard wrote: > > > Hi Philippe, > > > > > > On 2019.10.21 13:28, Philippe Mathieu-Daudé wrote: > > >> Hi Pete, > > >> > > >> On 10/21/19 1:25 PM, Pete Batard wrote: > > >>> In preparation for adding Raspberry Pi 4 support, the Pi 3 platform > > >>> is restructured by factorizing all the drivers and libraries that are > > >>> going to be commonly used by the two platforms. > > >>> > > >>> Because much of the Pi 4 SoC is an extension of the Pi 3 one this > > >>> means that almost everything, except the ACPI tables, is moved up > > >>> into a new common RaspberryPi/ subdirectory that will serve both > > >>> platforms. The .dec is also moved to this directory, under a new > > >>> RaspberryPi.dec name, and existing references to it are updated. > > >>> > ... > > >> > > >> This change seems not related to the rest of your refactor. > > > > > > It is. See https://edk2.groups.io/g/devel/message/49288 > > > > > > The problem is we have no choice but to break the patch in two sections, > > > one that applies to edk2-platforms and the other to edk2-non-osi, since > > > these are separate repos, and the LogoDxe changes belong to non-osi. > > > > > > We need to have part of the non-osi patch that is applied to > > > edk2-platforms, and it would make little sense to break it down into the > > > non-osi related and platforms related, since it still relies on the > > > non-osi changes having been applied. > > > > I see. > > > > > > > > If anything, I guess we could consider that the non-osi patch should > > > come first. Still, whatever we do here, as long as only one of non-osi > > > and platform is applied, builds are going to be broken, and there is no > > > way to fix that unless you do consider the set of platforms + non-osi as > > > a single patch. > > > > Agreed, this is a egg/chicken problem. > > > > I dealt with this in the past by just making sure the non-osi and > platform changes are applied at the same time. So it is good to make > note of this in the cover letter, but other than that, there is no way > we can apply interdependent changes to two separate repositories at > the same time without either breaking bisect for one of them, or > making a huge effort to add temporary code, defines etc that will be > removed again right after the changes have landed. Agreed. My preference would be to treat edk2-non-osi as the chicken, and edk2-platforms the egg. I could put the requisite edk2-non-osi hash into the edk2-platforms commit message before pushing, adding a line like: "This commit requires the edk2-non-osi in use to contain commit in order to build." If I'm feeling nitpicky, that could replace the comment "No other changes are being applied at this stage." Pete: would you be OK with those two changes? Best Regards, Leif -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49301): https://edk2.groups.io/g/devel/message/49301 Mute This Topic: https://groups.io/mt/36312720/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platforms/RPi3: Restructure platform in preparation for Pi 4
Hi Ard, On 2019.10.21 14:24, Ard Biesheuvel wrote: On Mon, 21 Oct 2019 at 15:09, Philippe Mathieu-Daudé wrote: On 10/21/19 2:52 PM, Pete Batard wrote: Hi Philippe, On 2019.10.21 13:28, Philippe Mathieu-Daudé wrote: Hi Pete, On 10/21/19 1:25 PM, Pete Batard wrote: In preparation for adding Raspberry Pi 4 support, the Pi 3 platform is restructured by factorizing all the drivers and libraries that are going to be commonly used by the two platforms. Because much of the Pi 4 SoC is an extension of the Pi 3 one this means that almost everything, except the ACPI tables, is moved up into a new common RaspberryPi/ subdirectory that will serve both platforms. The .dec is also moved to this directory, under a new RaspberryPi.dec name, and existing references to it are updated. ... This change seems not related to the rest of your refactor. It is. See https://edk2.groups.io/g/devel/message/49288 The problem is we have no choice but to break the patch in two sections, one that applies to edk2-platforms and the other to edk2-non-osi, since these are separate repos, and the LogoDxe changes belong to non-osi. We need to have part of the non-osi patch that is applied to edk2-platforms, and it would make little sense to break it down into the non-osi related and platforms related, since it still relies on the non-osi changes having been applied. I see. If anything, I guess we could consider that the non-osi patch should come first. Still, whatever we do here, as long as only one of non-osi and platform is applied, builds are going to be broken, and there is no way to fix that unless you do consider the set of platforms + non-osi as a single patch. Agreed, this is a egg/chicken problem. I dealt with this in the past by just making sure the non-osi and platform changes are applied at the same time. So it is good to make note of this in the cover letter, That is good advice. I'll make sure to follow that next time I have a non-osi + platforms dual patchset to submit, as it should indeed ease the review process. Regards, /Pete but other than that, there is no way we can apply interdependent changes to two separate repositories at the same time without either breaking bisect for one of them, or making a huge effort to add temporary code, defines etc that will be removed again right after the changes have landed. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49299): https://edk2.groups.io/g/devel/message/49299 Mute This Topic: https://groups.io/mt/36312720/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH] CryptoPkg: Upgrade OpenSSL to 1.1.1d
Shenglei: Those header files are added as the missing header file @8906f076de35b222a7d62bcf6ed1a4a2498a5791. Please keep them in INF file. Thanks Liming > -Original Message- > From: devel@edk2.groups.io On Behalf Of Zhang, Shenglei > Sent: Monday, October 21, 2019 4:07 PM > To: devel@edk2.groups.io > Cc: Wang, Jian J ; Lu, XiaoyuX > Subject: [edk2-devel] [PATCH] CryptoPkg: Upgrade OpenSSL to 1.1.1d > > Update openssl from 1.1.1b to 1.1.1d. > Something needs to be noticed is that, there is a bug existing in the > released 1_1_1d version(894da2fb7ed5d314ee5c2fc9fd2d9b8b74111596), > which causes build failure. So we switch the code base to a usable > version, which is 2 commits later than the stable tag. > Now we use the version c3656cc594daac8167721dde7220f0e59ae146fc. > This log is to fix the build failure. > https://bugzilla.tianocore.org/show_bug.cgi?id=2226 > > Cc: Jian J Wang > Cc: Xiaoyu Lu > Signed-off-by: Shenglei Zhang > --- > CryptoPkg/Library/OpensslLib/OpensslLib.inf | 57 --- > .../Library/OpensslLib/OpensslLibCrypto.inf | 49 > CryptoPkg/Library/OpensslLib/openssl | 2 +- > 3 files changed, 1 insertion(+), 107 deletions(-) > > diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf > b/CryptoPkg/Library/OpensslLib/OpensslLib.inf > index 7432321fd431..07c21ebeaa21 100644 > --- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf > +++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf > @@ -34,9 +34,7 @@ [Sources] >$(OPENSSL_PATH)/crypto/aes/aes_misc.c >$(OPENSSL_PATH)/crypto/aes/aes_ofb.c >$(OPENSSL_PATH)/crypto/aes/aes_wrap.c > - $(OPENSSL_PATH)/crypto/aes/aes_locl.h >$(OPENSSL_PATH)/crypto/aria/aria.c > - $(OPENSSL_PATH)/crypto/arm_arch.h >$(OPENSSL_PATH)/crypto/asn1/a_bitstr.c >$(OPENSSL_PATH)/crypto/asn1/a_d2i_fp.c >$(OPENSSL_PATH)/crypto/asn1/a_digest.c > @@ -101,21 +99,12 @@ [Sources] >$(OPENSSL_PATH)/crypto/asn1/x_sig.c >$(OPENSSL_PATH)/crypto/asn1/x_spki.c >$(OPENSSL_PATH)/crypto/asn1/x_val.c > - $(OPENSSL_PATH)/crypto/asn1/standard_methods.h > - $(OPENSSL_PATH)/crypto/asn1/charmap.h > - $(OPENSSL_PATH)/crypto/asn1/tbl_standard.h > - $(OPENSSL_PATH)/crypto/asn1/asn1_item_list.h > - $(OPENSSL_PATH)/crypto/asn1/asn1_locl.h >$(OPENSSL_PATH)/crypto/async/arch/async_null.c >$(OPENSSL_PATH)/crypto/async/arch/async_posix.c >$(OPENSSL_PATH)/crypto/async/arch/async_win.c >$(OPENSSL_PATH)/crypto/async/async.c >$(OPENSSL_PATH)/crypto/async/async_err.c >$(OPENSSL_PATH)/crypto/async/async_wait.c > - $(OPENSSL_PATH)/crypto/async/arch/async_win.h > - $(OPENSSL_PATH)/crypto/async/async_locl.h > - $(OPENSSL_PATH)/crypto/async/arch/async_posix.h > - $(OPENSSL_PATH)/crypto/async/arch/async_null.h >$(OPENSSL_PATH)/crypto/bio/b_addr.c >$(OPENSSL_PATH)/crypto/bio/b_dump.c >$(OPENSSL_PATH)/crypto/bio/b_sock.c > @@ -138,7 +127,6 @@ [Sources] >$(OPENSSL_PATH)/crypto/bio/bss_mem.c >$(OPENSSL_PATH)/crypto/bio/bss_null.c >$(OPENSSL_PATH)/crypto/bio/bss_sock.c > - $(OPENSSL_PATH)/crypto/bio/bio_lcl.h >$(OPENSSL_PATH)/crypto/bn/bn_add.c >$(OPENSSL_PATH)/crypto/bn/bn_asm.c >$(OPENSSL_PATH)/crypto/bn/bn_blind.c > @@ -170,9 +158,6 @@ [Sources] >$(OPENSSL_PATH)/crypto/bn/bn_srp.c >$(OPENSSL_PATH)/crypto/bn/bn_word.c >$(OPENSSL_PATH)/crypto/bn/bn_x931p.c > - $(OPENSSL_PATH)/crypto/bn/rsaz_exp.h > - $(OPENSSL_PATH)/crypto/bn/bn_prime.h > - $(OPENSSL_PATH)/crypto/bn/bn_lcl.h >$(OPENSSL_PATH)/crypto/buffer/buf_err.c >$(OPENSSL_PATH)/crypto/buffer/buffer.c >$(OPENSSL_PATH)/crypto/cmac/cm_ameth.c > @@ -181,7 +166,6 @@ [Sources] >$(OPENSSL_PATH)/crypto/comp/c_zlib.c >$(OPENSSL_PATH)/crypto/comp/comp_err.c >$(OPENSSL_PATH)/crypto/comp/comp_lib.c > - $(OPENSSL_PATH)/crypto/comp/comp_lcl.h >$(OPENSSL_PATH)/crypto/conf/conf_api.c >$(OPENSSL_PATH)/crypto/conf/conf_def.c >$(OPENSSL_PATH)/crypto/conf/conf_err.c > @@ -190,8 +174,6 @@ [Sources] >$(OPENSSL_PATH)/crypto/conf/conf_mod.c >$(OPENSSL_PATH)/crypto/conf/conf_sap.c >$(OPENSSL_PATH)/crypto/conf/conf_ssl.c > - $(OPENSSL_PATH)/crypto/conf/conf_lcl.h > - $(OPENSSL_PATH)/crypto/conf/conf_def.h >$(OPENSSL_PATH)/crypto/cpt_err.c >$(OPENSSL_PATH)/crypto/cryptlib.c >$(OPENSSL_PATH)/crypto/ctype.c > @@ -215,8 +197,6 @@ [Sources] >$(OPENSSL_PATH)/crypto/des/set_key.c >$(OPENSSL_PATH)/crypto/des/str2key.c >$(OPENSSL_PATH)/crypto/des/xcbc_enc.c > - $(OPENSSL_PATH)/crypto/des/spr.h > - $(OPENSSL_PATH)/crypto/des/des_locl.h >$(OPENSSL_PATH)/crypto/dh/dh_ameth.c >$(OPENSSL_PATH)/crypto/dh/dh_asn1.c >$(OPENSSL_PATH)/crypto/dh/dh_check.c > @@ -231,7 +211,6 @@ [Sources] >$(OPENSSL_PATH)/crypto/dh/dh_prn.c >$(OPENSSL_PATH)/crypto/dh/dh_rfc5114.c >$(OPENSSL_PATH)/crypto/dh/dh_rfc7919.c > - $(OPENSSL_PATH)/crypto/dh/dh_locl.h >$(OPENSSL_PATH)/crypto/dso/dso_dl.c >$(OPENSSL_PATH)/crypto/dso/dso_dlfcn.c >
Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platforms/RPi3: Restructure platform in preparation for Pi 4
On Mon, 21 Oct 2019 at 15:09, Philippe Mathieu-Daudé wrote: > > On 10/21/19 2:52 PM, Pete Batard wrote: > > Hi Philippe, > > > > On 2019.10.21 13:28, Philippe Mathieu-Daudé wrote: > >> Hi Pete, > >> > >> On 10/21/19 1:25 PM, Pete Batard wrote: > >>> In preparation for adding Raspberry Pi 4 support, the Pi 3 platform > >>> is restructured by factorizing all the drivers and libraries that are > >>> going to be commonly used by the two platforms. > >>> > >>> Because much of the Pi 4 SoC is an extension of the Pi 3 one this > >>> means that almost everything, except the ACPI tables, is moved up > >>> into a new common RaspberryPi/ subdirectory that will serve both > >>> platforms. The .dec is also moved to this directory, under a new > >>> RaspberryPi.dec name, and existing references to it are updated. > >>> ... > >> > >> This change seems not related to the rest of your refactor. > > > > It is. See https://edk2.groups.io/g/devel/message/49288 > > > > The problem is we have no choice but to break the patch in two sections, > > one that applies to edk2-platforms and the other to edk2-non-osi, since > > these are separate repos, and the LogoDxe changes belong to non-osi. > > > > We need to have part of the non-osi patch that is applied to > > edk2-platforms, and it would make little sense to break it down into the > > non-osi related and platforms related, since it still relies on the > > non-osi changes having been applied. > > I see. > > > > > If anything, I guess we could consider that the non-osi patch should > > come first. Still, whatever we do here, as long as only one of non-osi > > and platform is applied, builds are going to be broken, and there is no > > way to fix that unless you do consider the set of platforms + non-osi as > > a single patch. > > Agreed, this is a egg/chicken problem. > I dealt with this in the past by just making sure the non-osi and platform changes are applied at the same time. So it is good to make note of this in the cover letter, but other than that, there is no way we can apply interdependent changes to two separate repositories at the same time without either breaking bisect for one of them, or making a huge effort to add temporary code, defines etc that will be removed again right after the changes have landed. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49298): https://edk2.groups.io/g/devel/message/49298 Mute This Topic: https://groups.io/mt/36312720/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [Patch] PcAtChipsetPkg: Fix spelling errors
On 10/18/19 9:34 PM, Michael D Kinney wrote: From: Sean Brogan https://bugzilla.tianocore.org/show_bug.cgi?id=2263 Cc: Ray Ni Signed-off-by: Michael D Kinney --- PcAtChipsetPkg/HpetTimerDxe/HpetTimer.c | 12 ++-- PcAtChipsetPkg/HpetTimerDxe/HpetTimerDxe.inf | 2 +- PcAtChipsetPkg/HpetTimerDxe/HpetTimerDxe.uni | 2 +- PcAtChipsetPkg/Include/Library/IoApicLib.h | 2 +- PcAtChipsetPkg/Include/Register/Hpet.h | 6 +++--- PcAtChipsetPkg/Library/BaseIoApicLib/IoApicLib.c | 2 +- PcAtChipsetPkg/Library/SerialIoLib/SerialPortLib.c | 8 PcAtChipsetPkg/PcAtChipsetPkg.dec| 2 +- PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.c | 4 ++-- PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcRtc.h | 8 .../PcatRealTimeClockRuntimeDxe/PcRtcEntry.c | 2 +- 11 files changed, 25 insertions(+), 25 deletions(-) diff --git a/PcAtChipsetPkg/HpetTimerDxe/HpetTimer.c b/PcAtChipsetPkg/HpetTimerDxe/HpetTimer.c index ded3b53619..cbe986ebfd 100644 --- a/PcAtChipsetPkg/HpetTimerDxe/HpetTimer.c +++ b/PcAtChipsetPkg/HpetTimerDxe/HpetTimer.c @@ -1,5 +1,5 @@ /** @file - Timer Architectural Protocol module using High Precesion Event Timer (HPET) + Timer Architectural Protocol module using High Precision Event Timer (HPET) Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved. SPDX-License-Identifier: BSD-2-Clause-Patent @@ -246,7 +246,7 @@ HpetRead ( /** Write a 64-bit HPET register. - @param Offset Specifies the ofsfert of the HPET register to write. + @param Offset Specifies the offset of the HPET register to write. @param Value Specifies the value to write to the HPET register specified by Offset. @return The 64-bit value written to HPET register specified by Offset. @@ -530,7 +530,7 @@ TimerDriverSetTimerPeriod ( // If TimerPeriod is 0, then mask HPET Timer interrupts // -if (mTimerConfiguration.Bits.MsiInterruptCapablity != 0 && FeaturePcdGet (PcdHpetMsiEnable)) { +if (mTimerConfiguration.Bits.MsiInterruptCapability != 0 && FeaturePcdGet (PcdHpetMsiEnable)) { Ah, this changes are not present in the previous patch version (https://edk2.groups.io/g/devel/message/43354) so I now realize we had 2 person doing the same work, and failed at noticing because we kinda ignored the previous patches :| // // Disable HPET MSI interrupt generation // @@ -576,7 +576,7 @@ TimerDriverSetTimerPeriod ( // // Enable HPET Timer interrupt generation // -if (mTimerConfiguration.Bits.MsiInterruptCapablity != 0 && FeaturePcdGet (PcdHpetMsiEnable)) { +if (mTimerConfiguration.Bits.MsiInterruptCapability != 0 && FeaturePcdGet (PcdHpetMsiEnable)) { // // Program MSI Address and MSI Data values in the selected HPET Timer // Program HPET register with APIC ID of current BSP in case BSP has been switched @@ -834,7 +834,7 @@ TimerDriverInitialize ( // // Check to see if this HPET Timer supports MSI // -if (mTimerConfiguration.Bits.MsiInterruptCapablity != 0) { +if (mTimerConfiguration.Bits.MsiInterruptCapability != 0) { // // Save the index of the first HPET Timer that supports MSI interrupts // @@ -959,7 +959,7 @@ TimerDriverInitialize ( // Show state of enabled HPET timer // DEBUG_CODE ( -if (mTimerConfiguration.Bits.MsiInterruptCapablity != 0 && FeaturePcdGet (PcdHpetMsiEnable)) { +if (mTimerConfiguration.Bits.MsiInterruptCapability != 0 && FeaturePcdGet (PcdHpetMsiEnable)) { DEBUG ((DEBUG_INFO, "HPET Interrupt Mode MSI\n")); } else { DEBUG ((DEBUG_INFO, "HPET Interrupt Mode I/O APIC\n")); diff --git a/PcAtChipsetPkg/HpetTimerDxe/HpetTimerDxe.inf b/PcAtChipsetPkg/HpetTimerDxe/HpetTimerDxe.inf index ba2e075118..125eea0aab 100644 --- a/PcAtChipsetPkg/HpetTimerDxe/HpetTimerDxe.inf +++ b/PcAtChipsetPkg/HpetTimerDxe/HpetTimerDxe.inf @@ -1,5 +1,5 @@ ## @file -# Timer Architectural Protocol module using High Precesion Event Timer (HPET). +# Timer Architectural Protocol module using High Precision Event Timer (HPET). # # Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved. # SPDX-License-Identifier: BSD-2-Clause-Patent diff --git a/PcAtChipsetPkg/HpetTimerDxe/HpetTimerDxe.uni b/PcAtChipsetPkg/HpetTimerDxe/HpetTimerDxe.uni index e2320653b6..7d1797b1df 100644 --- a/PcAtChipsetPkg/HpetTimerDxe/HpetTimerDxe.uni +++ b/PcAtChipsetPkg/HpetTimerDxe/HpetTimerDxe.uni @@ -1,5 +1,5 @@ // /** @file -// Timer Architectural Protocol module using High Precesion Event Timer (HPET). +// Timer Architectural Protocol module using High Precision Event Timer (HPET). // // Timer Architectural Protocol module using High Precision Event Timer (HPET). // diff --git a/PcAtChipsetPkg/Include/Library/IoApicLib.h b/PcAtChipsetPkg/Include/Library/IoApicLib.h index
Re: [edk2-devel] [Patch] FatPkg: Fix spelling errors
Hi Michael, On 10/18/19 9:15 PM, Michael D Kinney wrote: From: Sean Brogan Is a different patch than https://edk2.groups.io/g/devel/topic/32250614 or simply the patch author got messed up? It should be: Antoine Cœur https://bugzilla.tianocore.org/show_bug.cgi?id=2264 Cc: Ray Ni Signed-off-by: Michael D Kinney --- FatPkg/EnhancedFatDxe/DirectoryManage.c | 8 FatPkg/EnhancedFatDxe/DiskCache.c | 2 +- FatPkg/EnhancedFatDxe/Fat.h | 20 ++-- FatPkg/EnhancedFatDxe/FileName.c| 2 +- FatPkg/EnhancedFatDxe/FileSpace.c | 6 +++--- FatPkg/EnhancedFatDxe/Info.c| 2 +- FatPkg/EnhancedFatDxe/Init.c| 2 +- FatPkg/EnhancedFatDxe/Misc.c| 6 +++--- FatPkg/EnhancedFatDxe/Open.c| 2 +- FatPkg/FatPei/FatLiteApi.c | 6 +++--- FatPkg/FatPei/FatLitePeim.h | 4 ++-- FatPkg/FatPei/Gpt.c | 2 +- FatPkg/FatPei/Mbr.c | 2 +- 13 files changed, 32 insertions(+), 32 deletions(-) diff --git a/FatPkg/EnhancedFatDxe/DirectoryManage.c b/FatPkg/EnhancedFatDxe/DirectoryManage.c index 21656883bd..93772dba09 100644 --- a/FatPkg/EnhancedFatDxe/DirectoryManage.c +++ b/FatPkg/EnhancedFatDxe/DirectoryManage.c @@ -17,7 +17,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent @param EntryPos - The position of the directory entry to be accessed. @param Entry - The directory entry read or written. - @retval EFI_SUCCESS - Access the directory entry sucessfully. + @retval EFI_SUCCESS - Access the directory entry successfully. @return other - An error occurred when reading the directory entry. **/ @@ -896,7 +896,7 @@ FatNewEntryPos ( @param Volume- FAT file system volume. @param Name - The file name of the volume. - @retval EFI_SUCCESS - Update the volume with the directory entry sucessfully. + @retval EFI_SUCCESS - Update the volume with the directory entry successfully. @return others- An error occurred when getting volume label. **/ @@ -927,7 +927,7 @@ FatGetVolumeEntry ( @param Volume - FAT file system volume. @param Name- The new file name of the volume. - @retval EFI_SUCCESS - Update the Volume sucessfully. + @retval EFI_SUCCESS - Update the Volume successfully. @retval EFI_UNSUPPORTED - The input label is not a valid volume label. @return other - An error occurred when setting volume label. @@ -1246,7 +1246,7 @@ FatCloseDirEnt ( not be created either). @retval EFI_INVALID_PARAMETER - The parameter is not valid. @retval EFI_SUCCESS - Open the file successfully. - @return other - An error occured when locating the OFile. + @return other - An error occurred when locating the OFile. **/ EFI_STATUS diff --git a/FatPkg/EnhancedFatDxe/DiskCache.c b/FatPkg/EnhancedFatDxe/DiskCache.c index 2df0aa09f1..df587810fb 100644 --- a/FatPkg/EnhancedFatDxe/DiskCache.c +++ b/FatPkg/EnhancedFatDxe/DiskCache.c @@ -16,7 +16,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent are older than the contents in disk, so they are invalid; just mark them invalid. When this function is called by read command, if any entry in this range - is dirty, it means that the relative info directly readed from media is older than + is dirty, it means that the relative info directly read from media is older than than the info in the cache; So need to update the relative info in the Buffer. @param Volume- FAT file system volume. diff --git a/FatPkg/EnhancedFatDxe/Fat.h b/FatPkg/EnhancedFatDxe/Fat.h index 98ead5a0fb..46c185c3a9 100644 --- a/FatPkg/EnhancedFatDxe/Fat.h +++ b/FatPkg/EnhancedFatDxe/Fat.h @@ -865,7 +865,7 @@ FatCleanupVolume ( @param OFile - The open file. - @retval EFI_SUCCESS - Shrinked sucessfully. + @retval EFI_SUCCESS - Shrinked successfully. @retval EFI_VOLUME_CORRUPTED - There are errors in the file's clusters. **/ @@ -881,7 +881,7 @@ FatShrinkEof ( @param OFile - The open file. @param NewSizeInBytes- The new size in bytes of the open file. - @retval EFI_SUCCESS - The file is grown sucessfully. + @retval EFI_SUCCESS - The file is grown successfully. @retval EFI_UNSUPPORTED - The file size is larger than 4GB. @retval EFI_VOLUME_CORRUPTED - There are errors in the files' clusters. @retval EFI_VOLUME_FULL - The volume is full and can not grow the file. @@ -969,7 +969,7 @@ FatComputeFreeInfo ( @param Handle- The handle of parent device. @param DiskIo- The DiskIo of parent
Re: [edk2-devel] Recent changes to EsrtFmp causing ASSERTs
Michael, Wouldn't the current implementation ASSERT if there are different plug-in cards by the same vendor using the same GUID in their FMP? They are managing different hardware and have no knowledge of the existence of the other FMP instance. Each FMP is only aware of the specific device on whose handle they are installed. If they use FW image descriptors below version 2 (or they cannot determine a unique HW instance), this would always be 0. Why would we want to ASSERT in this case? What error condition is being caught? Thanks, SWig -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49295): https://edk2.groups.io/g/devel/message/49295 Mute This Topic: https://groups.io/mt/34350126/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platforms/RPi3: Restructure platform in preparation for Pi 4
On 10/21/19 2:52 PM, Pete Batard wrote: Hi Philippe, On 2019.10.21 13:28, Philippe Mathieu-Daudé wrote: Hi Pete, On 10/21/19 1:25 PM, Pete Batard wrote: In preparation for adding Raspberry Pi 4 support, the Pi 3 platform is restructured by factorizing all the drivers and libraries that are going to be commonly used by the two platforms. Because much of the Pi 4 SoC is an extension of the Pi 3 one this means that almost everything, except the ACPI tables, is moved up into a new common RaspberryPi/ subdirectory that will serve both platforms. The .dec is also moved to this directory, under a new RaspberryPi.dec name, and existing references to it are updated. No other changes are being applied at this stage. Signed-off-by: Pete Batard --- Platform/RaspberryPi/{RPi3 => }/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxeFormSetGuid.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxeHii.uni | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxeHii.vfr | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/ComponentName.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/DisplayDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/DisplayDxe.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/DisplayDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/Screenshot.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/ComponentName.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DriverBinding.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DwUsbHostDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DwUsbHostDxe.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DwUsbHostDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DwcHw.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/FdtDxe/FdtDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/FdtDxe/FdtDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/ComponentName.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsole.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsole.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsoleDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsoleDxe.uni | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsoleDxeExtra.uni | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/NewFont.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/ComponentName.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/Diagnostics.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/Mmc.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/Mmc.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/MmcBlockIo.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/MmcDebug.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/MmcDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/MmcIdentification.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/SdHostDxe/SdHostDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/SdHostDxe/SdHostDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/VarBlockServiceDxe/FileIo.c |
Re: [edk2-devel] [edk2-non-osi][PATCH 1/1] Platforms/RPi3: Restructure platform in preparation for Pi 4
On 10/21/19 1:25 PM, Pete Batard wrote: Similar to what is being done in edk2-platforms, elements of the Pi 3 platform that can be factorized for use with the Pi 4 are factorized. For non-OSI this only applies to the Logo driver, as the Device Tree and the Trusted Firmware are of course too platform specific to be factorized. Signed-off-by: Pete Batard --- Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/License.txt | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/Logo.bmp | Bin Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/Logo.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/Logo.eps | Bin Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/Logo.idf | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/Logo.inf | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/Logo.uni | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/LogoDxe.inf | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/LogoDxe.uni | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/LogoDxeExtra.uni | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/LogoExtra.uni| 0 11 files changed, 0 insertions(+), 0 deletions(-) diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/License.txt b/Platform/RaspberryPi/Drivers/LogoDxe/License.txt similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/License.txt rename to Platform/RaspberryPi/Drivers/LogoDxe/License.txt diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.bmp b/Platform/RaspberryPi/Drivers/LogoDxe/Logo.bmp similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.bmp rename to Platform/RaspberryPi/Drivers/LogoDxe/Logo.bmp diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.c b/Platform/RaspberryPi/Drivers/LogoDxe/Logo.c similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.c rename to Platform/RaspberryPi/Drivers/LogoDxe/Logo.c diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.eps b/Platform/RaspberryPi/Drivers/LogoDxe/Logo.eps similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.eps rename to Platform/RaspberryPi/Drivers/LogoDxe/Logo.eps diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.idf b/Platform/RaspberryPi/Drivers/LogoDxe/Logo.idf similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.idf rename to Platform/RaspberryPi/Drivers/LogoDxe/Logo.idf diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.inf b/Platform/RaspberryPi/Drivers/LogoDxe/Logo.inf similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.inf rename to Platform/RaspberryPi/Drivers/LogoDxe/Logo.inf diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.uni b/Platform/RaspberryPi/Drivers/LogoDxe/Logo.uni similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.uni rename to Platform/RaspberryPi/Drivers/LogoDxe/Logo.uni diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/LogoDxe.inf b/Platform/RaspberryPi/Drivers/LogoDxe/LogoDxe.inf similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/LogoDxe.inf rename to Platform/RaspberryPi/Drivers/LogoDxe/LogoDxe.inf diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/LogoDxe.uni b/Platform/RaspberryPi/Drivers/LogoDxe/LogoDxe.uni similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/LogoDxe.uni rename to Platform/RaspberryPi/Drivers/LogoDxe/LogoDxe.uni diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/LogoDxeExtra.uni b/Platform/RaspberryPi/Drivers/LogoDxe/LogoDxeExtra.uni similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/LogoDxeExtra.uni rename to Platform/RaspberryPi/Drivers/LogoDxe/LogoDxeExtra.uni diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/LogoExtra.uni b/Platform/RaspberryPi/Drivers/LogoDxe/LogoExtra.uni similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/LogoExtra.uni rename to Platform/RaspberryPi/Drivers/LogoDxe/LogoExtra.uni Reviewed-by: Philippe Mathieu-Daude -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49294): https://edk2.groups.io/g/devel/message/49294 Mute This Topic: https://groups.io/mt/36312724/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platforms/RPi3: Restructure platform in preparation for Pi 4
Hi Philippe, On 2019.10.21 13:28, Philippe Mathieu-Daudé wrote: Hi Pete, On 10/21/19 1:25 PM, Pete Batard wrote: In preparation for adding Raspberry Pi 4 support, the Pi 3 platform is restructured by factorizing all the drivers and libraries that are going to be commonly used by the two platforms. Because much of the Pi 4 SoC is an extension of the Pi 3 one this means that almost everything, except the ACPI tables, is moved up into a new common RaspberryPi/ subdirectory that will serve both platforms. The .dec is also moved to this directory, under a new RaspberryPi.dec name, and existing references to it are updated. No other changes are being applied at this stage. Signed-off-by: Pete Batard --- Platform/RaspberryPi/{RPi3 => }/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxeFormSetGuid.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxeHii.uni | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxeHii.vfr | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/ComponentName.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/DisplayDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/DisplayDxe.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/DisplayDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/Screenshot.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/ComponentName.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DriverBinding.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DwUsbHostDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DwUsbHostDxe.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DwUsbHostDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DwcHw.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/FdtDxe/FdtDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/FdtDxe/FdtDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/ComponentName.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsole.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsole.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsoleDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsoleDxe.uni | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsoleDxeExtra.uni | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/NewFont.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/ComponentName.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/Diagnostics.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/Mmc.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/Mmc.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/MmcBlockIo.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/MmcDebug.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/MmcDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/MmcIdentification.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/SdHostDxe/SdHostDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/SdHostDxe/SdHostDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/VarBlockServiceDxe/FileIo.c | 0 Platform/RaspberryPi/{RPi3 =>
Re: [edk2-devel] Use a pcd to control PlatformRecovery
Sorry for the delay and thanks for checking my question, Ray. Since the OS recovery and platform recovery options were added to UEFI specification at the same time, I thought we will also implement it and push the code regardless of the OS support. No, I didn't see a real need of using the OS recovery option. If my memory serves me well, I have only seen a need of using "One-Time" OS recovery, but it can be done by creating, adjusting, and removing a boot option in boot order. However, I can still imagine that the OS recovery option is needed for the use of "persistent" OS recovery. Therefore, if we don't have any concern about adding OS recovery option support, I think it is still better to push the code because the UEFI specification mentioned it. Add Peter. He may know more information about this. By the way, I think if no one works on the task below, there will be no OS or OS tool supporting it. :) - https://github.com/rhboot/efibootmgr/issues/41 Regards, Sunny Wang -Original Message- From: Ni, Ray [mailto:ray...@intel.com] Sent: Wednesday, October 16, 2019 4:43 PM To: Wang, Sunny (HPS SW) ; devel@edk2.groups.io; Gao, Zhichao Cc: Wang, Jian J ; Wu, Hao A ; Zeng, Star ; Gao, Liming ; Sean Brogan ; Michael Turner ; Bret Barkelew ; Li, Walon ; Wei, Kent (HPS SW) ; Spottswood, Jason Subject: RE: [edk2-devel] Use a pcd to control PlatformRecovery Importance: High Sunny, For the OS recovery question, I had the code change in https://github.com/niruiyu/edk2/tree/bds/osrecovery. Due to there is no OS support for OS recovery yet, the code was not pushed. Do you see any needs of the OS recovery? Thanks, Ray > -Original Message- > From: Wang, Sunny (HPS SW) > Sent: Wednesday, October 16, 2019 3:42 PM > To: devel@edk2.groups.io; Gao, Zhichao ; Ni, > Ray > Cc: Wang, Jian J ; Wu, Hao A > ; Zeng, Star ; Gao, Liming > ; Sean Brogan ; > Michael Turner ; Bret Barkelew > ; Li, Walon ; Wei, Kent > (HPS SW) ; Spottswood, Jason > ; Wang, Sunny (HPS SW) > Subject: RE: [edk2-devel] Use a pcd to control PlatformRecovery > > Thanks for checking this, Zhichao and Ray. > I just sent a patch to fix it with the subject " [edk2-devel] [PATCH] > MdeModulePkg/BdsDxe: Make PlatformRecovery work regardless of > OsIndications" > > Regards, > Sunny Wang > > -Original Message- > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of > Gao, Zhichao > Sent: Wednesday, October 16, 2019 1:57 PM > To: Wang, Sunny (HPS SW) ; devel@edk2.groups.io; > Ni, Ray > Cc: Wang, Jian J ; Wu, Hao A > ; Zeng, Star ; Gao, Liming > ; Sean Brogan ; > Michael Turner ; Bret Barkelew > ; Li, Walon ; Wei, Kent > (HPS SW) > Subject: Re: [edk2-devel] Use a pcd to control PlatformRecovery > Importance: High > > > > -Original Message- > > From: Gao, Zhichao > > Sent: Wednesday, October 16, 2019 10:09 AM > > To: 'Wang, Sunny (HPS SW)' ; > devel@edk2.groups.io; > > Ni, Ray > > Cc: Wang, Jian J ; Wu, Hao A > > ; Zeng, Star ; Gao, Liming > > ; Sean Brogan ; > > Michael Turner ; Bret Barkelew > > ; Li, Walon ; Wei, > Kent > > (HPS SW) > > Subject: RE: Use a pcd to control PlatformRecovery > > > > First of all, the patch didn't aim to change the other part of the > > boot flow except PlatformRecovery. > > > > Local variable PlatformRecovery is controlled by OsIndications > > variable. When the EFI_OS_INDICATIONS_START_PLATFORM_RECOVERY is > set, > > the firmware should try to platform specific recovery. But that > > doesn't mean the platform must support the specific recovery. i.e. > > local PlatformRecovery is controlling the boot flow and the Pcd just > > indicated whether the platform support recovery or not. > > So, on my opinion, I don't agree with your change. > > After discuss with Sunny and Ray, and refer to the spec section 3.4.1 > and 3.4.2, the OsRecovery and PlatformRecovery should always be > operated regardless of the value of OsIndication variable if fail to > boot the BootOrder. I am wrong. We should change to use the > PcdPlatformRecoverySupport to control the PlatformRecovery. Please > help to send a patch to fix it. Thanks a lot. > > > > > Default Platform Recovery refer to the short file path to boot the OS. > > If the firmware supports platform recovery, then *short file path* > > option would be one part of the PlatformRecovery in case there > > are no other boot options. If the firmware doesn't support platform > > recovery, we still need this default boot thru a short file path and > > it should not depend on the PlatformRecovery variable for the > compatibility thinking. > > > > Thanks, > > Zhichao > > > > > -Original Message- > > > From: Wang, Sunny (HPS SW) [mailto:sunnyw...@hpe.com] > > > Sent: Tuesday, October 15, 2019 4:53 PM > > > To: devel@edk2.groups.io; Gao, Zhichao ; > > > Ni, Ray > > > Cc: Wang, Jian J ; Wu, Hao A > > > ; Zeng, Star ; Gao, > > > Liming ; Sean Brogan > > > ; Michael Turner > >
Re: [edk2-devel] [edk2-platforms][PATCH 1/1] Platforms/RPi3: Restructure platform in preparation for Pi 4
Hi Pete, On 10/21/19 1:25 PM, Pete Batard wrote: In preparation for adding Raspberry Pi 4 support, the Pi 3 platform is restructured by factorizing all the drivers and libraries that are going to be commonly used by the two platforms. Because much of the Pi 4 SoC is an extension of the Pi 3 one this means that almost everything, except the ACPI tables, is moved up into a new common RaspberryPi/ subdirectory that will serve both platforms. The .dec is also moved to this directory, under a new RaspberryPi.dec name, and existing references to it are updated. No other changes are being applied at this stage. Signed-off-by: Pete Batard --- Platform/RaspberryPi/{RPi3 => }/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxeFormSetGuid.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxeHii.uni | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxeHii.vfr | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/ComponentName.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/DisplayDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/DisplayDxe.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/DisplayDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/Screenshot.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/ComponentName.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DriverBinding.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DwUsbHostDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DwUsbHostDxe.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DwUsbHostDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DwcHw.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/FdtDxe/FdtDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/FdtDxe/FdtDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/ComponentName.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsole.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsole.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsoleDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsoleDxe.uni | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsoleDxeExtra.uni| 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/NewFont.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/ComponentName.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/Diagnostics.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/Mmc.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/Mmc.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/MmcBlockIo.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/MmcDebug.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/MmcDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/MmcIdentification.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/SdHostDxe/SdHostDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/SdHostDxe/SdHostDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/VarBlockServiceDxe/FileIo.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/VarBlockServiceDxe/FvbInfo.c | 0
Re: [edk2-devel] [PATCH 1/1] DynamicTablesPkg: include ARM intrinsics library to fix 32-bit build
Pushed as : 61bb6eeb4d93..91f98c908627 Thanks. Regards, Sami Mujawar -Original Message- From: Ard Biesheuvel Sent: 15 October 2019 12:08 PM To: devel@edk2.groups.io Cc: ler...@redhat.com; Sami Mujawar ; leif.lindh...@linaro.org; Ard Biesheuvel Subject: [PATCH 1/1] DynamicTablesPkg: include ARM intrinsics library to fix 32-bit build DynamicTablesPkg can be built for ARM as well as for AARCH64, but on the former, doing so will result in a build failure due to the lack of 64-bit division helpers provided by the ArmPkg intrinsics library. So add the missing reference, for both ARM and AARCH64 (which may start relying on intrinsics due to future changes) Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2269 Reported-by: Laszlo Ersek Signed-off-by: Ard Biesheuvel --- DynamicTablesPkg/DynamicTablesPkg.dsc | 1 + 1 file changed, 1 insertion(+) diff --git a/DynamicTablesPkg/DynamicTablesPkg.dsc b/DynamicTablesPkg/DynamicTablesPkg.dsc index ef958077ed48..19beaaf370f8 100644 --- a/DynamicTablesPkg/DynamicTablesPkg.dsc +++ b/DynamicTablesPkg/DynamicTablesPkg.dsc @@ -32,6 +32,7 @@ [LibraryClasses] UefiDriverEntryPoint|MdePkg/Library/UefiDriverEntryPoint/UefiDriverEntryPoint.inf [LibraryClasses.ARM, LibraryClasses.AARCH64] + NULL|ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf PL011UartLib|ArmPlatformPkg/Library/PL011UartLib/PL011UartLib.inf [Components.common] -- 2.17.1 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49289): https://edk2.groups.io/g/devel/message/49289 Mute This Topic: https://groups.io/mt/34544264/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [edk2-non-osi][PATCH 1/1] Platforms/RPi3: Restructure platform in preparation for Pi 4
Similar to what is being done in edk2-platforms, elements of the Pi 3 platform that can be factorized for use with the Pi 4 are factorized. For non-OSI this only applies to the Logo driver, as the Device Tree and the Trusted Firmware are of course too platform specific to be factorized. Signed-off-by: Pete Batard --- Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/License.txt | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/Logo.bmp | Bin Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/Logo.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/Logo.eps | Bin Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/Logo.idf | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/Logo.inf | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/Logo.uni | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/LogoDxe.inf | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/LogoDxe.uni | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/LogoDxeExtra.uni | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/LogoDxe/LogoExtra.uni| 0 11 files changed, 0 insertions(+), 0 deletions(-) diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/License.txt b/Platform/RaspberryPi/Drivers/LogoDxe/License.txt similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/License.txt rename to Platform/RaspberryPi/Drivers/LogoDxe/License.txt diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.bmp b/Platform/RaspberryPi/Drivers/LogoDxe/Logo.bmp similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.bmp rename to Platform/RaspberryPi/Drivers/LogoDxe/Logo.bmp diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.c b/Platform/RaspberryPi/Drivers/LogoDxe/Logo.c similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.c rename to Platform/RaspberryPi/Drivers/LogoDxe/Logo.c diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.eps b/Platform/RaspberryPi/Drivers/LogoDxe/Logo.eps similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.eps rename to Platform/RaspberryPi/Drivers/LogoDxe/Logo.eps diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.idf b/Platform/RaspberryPi/Drivers/LogoDxe/Logo.idf similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.idf rename to Platform/RaspberryPi/Drivers/LogoDxe/Logo.idf diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.inf b/Platform/RaspberryPi/Drivers/LogoDxe/Logo.inf similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.inf rename to Platform/RaspberryPi/Drivers/LogoDxe/Logo.inf diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.uni b/Platform/RaspberryPi/Drivers/LogoDxe/Logo.uni similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/Logo.uni rename to Platform/RaspberryPi/Drivers/LogoDxe/Logo.uni diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/LogoDxe.inf b/Platform/RaspberryPi/Drivers/LogoDxe/LogoDxe.inf similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/LogoDxe.inf rename to Platform/RaspberryPi/Drivers/LogoDxe/LogoDxe.inf diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/LogoDxe.uni b/Platform/RaspberryPi/Drivers/LogoDxe/LogoDxe.uni similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/LogoDxe.uni rename to Platform/RaspberryPi/Drivers/LogoDxe/LogoDxe.uni diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/LogoDxeExtra.uni b/Platform/RaspberryPi/Drivers/LogoDxe/LogoDxeExtra.uni similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/LogoDxeExtra.uni rename to Platform/RaspberryPi/Drivers/LogoDxe/LogoDxeExtra.uni diff --git a/Platform/RaspberryPi/RPi3/Drivers/LogoDxe/LogoExtra.uni b/Platform/RaspberryPi/Drivers/LogoDxe/LogoExtra.uni similarity index 100% rename from Platform/RaspberryPi/RPi3/Drivers/LogoDxe/LogoExtra.uni rename to Platform/RaspberryPi/Drivers/LogoDxe/LogoExtra.uni -- 2.21.0.windows.1 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49288): https://edk2.groups.io/g/devel/message/49288 Mute This Topic: https://groups.io/mt/36312724/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[edk2-devel] [edk2-platforms][PATCH 1/1] Platforms/RPi3: Restructure platform in preparation for Pi 4
In preparation for adding Raspberry Pi 4 support, the Pi 3 platform is restructured by factorizing all the drivers and libraries that are going to be commonly used by the two platforms. Because much of the Pi 4 SoC is an extension of the Pi 3 one this means that almost everything, except the ACPI tables, is moved up into a new common RaspberryPi/ subdirectory that will serve both platforms. The .dec is also moved to this directory, under a new RaspberryPi.dec name, and existing references to it are updated. No other changes are being applied at this stage. Signed-off-by: Pete Batard --- Platform/RaspberryPi/{RPi3 => }/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ArasanMmcHostDxe/ArasanMmcHostDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxeFormSetGuid.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxeHii.uni | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/ConfigDxe/ConfigDxeHii.vfr | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/ComponentName.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/DisplayDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/DisplayDxe.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/DisplayDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/DisplayDxe/Screenshot.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/ComponentName.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DriverBinding.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DwUsbHostDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DwUsbHostDxe.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DwUsbHostDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/DwUsbHostDxe/DwcHw.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/FdtDxe/FdtDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/FdtDxe/FdtDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/ComponentName.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsole.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsole.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsoleDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsoleDxe.uni | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/GraphicsConsoleDxeExtra.uni| 0 Platform/RaspberryPi/{RPi3 => }/Drivers/GraphicsConsoleDxe/NewFont.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/ComponentName.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/Diagnostics.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/Mmc.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/Mmc.h | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/MmcBlockIo.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/MmcDebug.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/MmcDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/MmcDxe/MmcIdentification.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/PlatformSmbiosDxe/PlatformSmbiosDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/RpiFirmwareDxe/RpiFirmwareDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/SdHostDxe/SdHostDxe.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/SdHostDxe/SdHostDxe.inf | 2 +- Platform/RaspberryPi/{RPi3 => }/Drivers/VarBlockServiceDxe/FileIo.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/VarBlockServiceDxe/FvbInfo.c | 0 Platform/RaspberryPi/{RPi3 => }/Drivers/VarBlockServiceDxe/VarBlockService.c | 0
Re: [edk2-devel] [PATCH 1/1] DynamicTablesPkg: include ARM intrinsics library to fix 32-bit build
Reviewed-by: Alexei Fedorov -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#49286): https://edk2.groups.io/g/devel/message/49286 Mute This Topic: https://groups.io/mt/34544264/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe string constraint assertions
Jiewen, We are aware of all these nuances, and you are right that both of them (strlcpy/strcpy_s) have their downsides. Our opinion is that strlcpy is more practical, but that is a personal choice, and we do nor care much on what is available as long as it is documented. Our primary issues are not really with string copying, but rather with other interfaces. For example: - We use AsciiStrToGuid to convert a string to a GUID in the user configuration file, and any intentional or unintentionsl typo there may result in halting the entire app due to length assertion in DEBUG builds. - We use AsciiStrCats to append messages to the log buffer as long as they fit. We do not care what happens when they stop to fit, for us that means we will have a cut log and a handled error that some messages did not fit. However, in DEBUG builds that once again results in halts. I am pretty sure there were more, but the use cases are be pretty similar, so you most likely get an idea. We do handle the error where necessary, yet we do not expect the code to halt before we can handle the error. Best wishes, Vitaly В пн, окт. 21, 2019 в 11:51, Yao, Jiewen пишет: > Hi Vitaly > Before we introduce EDKII version safe string, we did investigate the > behavior of below APIs: > 1) strcpy - We all know that... > 2) strncpy - The problem is that this API cannot guarantee a string is NULL > terminated. > 3) strlcpy - It is null terminated, but the result is truncated. That data > loss might be a problem - https://lwn.net/Articles/507319/ > 4) strcpy_s - Return zero string, if there is violation. > > We discussed and decide to follow 4), with a minor update - we just return > error without zero the original string. > > As such, if you want to use strlcpy, I suggest you had better invent a new > API, instead of current StrCpy_S. > > Would you please share a real use case on how you use this API verify the > untrusted input? > I am very curious on the usage. > > Thank you > Yao Jiewen > >> -Original Message- >> From: vit9696 >> Sent: Monday, October 21, 2019 4:30 PM >> To: Yao, Jiewen >> Cc: devel@edk2.groups.io; Gao, Liming ; Wang, Jian J >> ; Kinney, Michael D ; >> Laszlo Ersek ; marvin.haeu...@outlook.com >> Subject: Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe >> string >> constraint assertions >> >> Jiewen, >> >> Your explanation makes good sense in the context of "This API is NOT design >> to >> handle untrusted input.", however, I believe this is not how it is should >> work or >> at least this is not how we would like it to behave. >> >> In Unix world there are similar hardened interfaces, for example, strlcpy or >> strlcat[1]. These interfaces behave quite similar to what you have in BaseLib >> SafeString, but in the first place they are meant to handle untrusted input. >> To my >> experience this situation happens no less often (and in fact much more) than >> the >> need to do extra error checking in trusted code, and I expect EDK2 to follow >> suit. >> I.e. implement something that can be used not only to check for programmer >> errors within the module, but also perform the validation of external data. >> After >> all, if these were just the assertions, I would have expected for return >> value to >> be void not RETURN_STATUS. >> >> If we consider all the options we need to do either of the following: >> - reimplement most of the functions in the caller code, which is non-trivial, >> increases code size, reduces readability, is more prone to errors, makes >> reviewing more time consuming, etc. >> - reimplement all these functions in a separate library, which solves some >> of the >> issues, but still increases code size and results in separate interfaces with >> different contracts >> - add a pcd to disable assertions, which will disable the debugging handlers >> and >> will effectively make these functions behave as runtime checks for untrusted >> data, numerous people me included expect them do. >> >> Last suggestion makes most sense to me. Therefore, I believe that even in the >> situation we have different opinions on whether this should be on by >> default, we >> should at least see the benefit for having an option to make this >> configurable in >> other projects. In this case I can update the patch in the next days to >> preserve >> the original behaviour and resubmit it as a v2. >> >> Best wishes, >> Vitaly >> >> [1] https://linux.die.net/man/3/strlcpy >> >> > 21 окт. 2019 г., в 11:07, Yao, Jiewen написал(а): >> > >> > >> > Hi Vitaly >> > We have discussed the ASSERT usage when we added the first version of code. >> > >> > C11 standard supports runtime violation handler registration. >> > We investigated the behavior of >> > (1) MS Visual Studio - >> > http://msdn.microsoft.com/en-us/library/bb288454.aspx >> > (2) SafeCLib - http://sourceforge.net/projects/safeclib/ >> > (3) Slibc - https://code.google.com/p/slibc/ >> > >> > The default behavior is: >> >
Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe string constraint assertions
Hi Vitaly Before we introduce EDKII version safe string, we did investigate the behavior of below APIs: 1) strcpy - We all know that... 2) strncpy - The problem is that this API cannot guarantee a string is NULL terminated. 3) strlcpy - It is null terminated, but the result is truncated. That data loss might be a problem - https://lwn.net/Articles/507319/ 4) strcpy_s - Return zero string, if there is violation. We discussed and decide to follow 4), with a minor update - we just return error without zero the original string. As such, if you want to use strlcpy, I suggest you had better invent a new API, instead of current StrCpy_S. Would you please share a real use case on how you use this API verify the untrusted input? I am very curious on the usage. Thank you Yao Jiewen > -Original Message- > From: vit9696 > Sent: Monday, October 21, 2019 4:30 PM > To: Yao, Jiewen > Cc: devel@edk2.groups.io; Gao, Liming ; Wang, Jian J > ; Kinney, Michael D ; > Laszlo Ersek ; marvin.haeu...@outlook.com > Subject: Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe > string > constraint assertions > > Jiewen, > > Your explanation makes good sense in the context of "This API is NOT design to > handle untrusted input.", however, I believe this is not how it is should > work or > at least this is not how we would like it to behave. > > In Unix world there are similar hardened interfaces, for example, strlcpy or > strlcat[1]. These interfaces behave quite similar to what you have in BaseLib > SafeString, but in the first place they are meant to handle untrusted input. > To my > experience this situation happens no less often (and in fact much more) than > the > need to do extra error checking in trusted code, and I expect EDK2 to follow > suit. > I.e. implement something that can be used not only to check for programmer > errors within the module, but also perform the validation of external data. > After > all, if these were just the assertions, I would have expected for return > value to > be void not RETURN_STATUS. > > If we consider all the options we need to do either of the following: > - reimplement most of the functions in the caller code, which is non-trivial, > increases code size, reduces readability, is more prone to errors, makes > reviewing more time consuming, etc. > - reimplement all these functions in a separate library, which solves some of > the > issues, but still increases code size and results in separate interfaces with > different contracts > - add a pcd to disable assertions, which will disable the debugging handlers > and > will effectively make these functions behave as runtime checks for untrusted > data, numerous people me included expect them do. > > Last suggestion makes most sense to me. Therefore, I believe that even in the > situation we have different opinions on whether this should be on by default, > we > should at least see the benefit for having an option to make this > configurable in > other projects. In this case I can update the patch in the next days to > preserve > the original behaviour and resubmit it as a v2. > > Best wishes, > Vitaly > > [1] https://linux.die.net/man/3/strlcpy > > > 21 окт. 2019 г., в 11:07, Yao, Jiewen написал(а): > > > > > > Hi Vitaly > > We have discussed the ASSERT usage when we added the first version of code. > > > > C11 standard supports runtime violation handler registration. > > We investigated the behavior of > > (1) MS Visual Studio - http://msdn.microsoft.com/en-us/library/bb288454.aspx > > (2) SafeCLib - http://sourceforge.net/projects/safeclib/ > > (3) Slibc - https://code.google.com/p/slibc/ > > > > The default behavior is: > > (1) Call Debugger > > (2) Print error > > (3) Call abort() > > > > As conclusion, we believe it is *caller's responsibility* to make sure the > > caller > inputs right parameter, instead of let callee check and return error. > > > > In order to catch such error as early as possible, we decide to use ASSERT, > because it is something never happen. (We still use error handling followed > by to > handle the release build.) > > > > This API is NOT design to handle untrusted input. As such, we believe it is > expected ASSERT behavior. > > > > > > We have other debate, such as if we need ASSERT 2 bytes alignment CHAR16 > process, or if we need ASSERT address alignment for MMIO access. > > Per our experience, it is much better to let caller guarantee that, instead > > of > callee check that. And ASSERT is a good way to catch the issue as early as > possible. > > > > > > > > Thank you > > Yao Jiewen > > > >> -Original Message- > >> From: devel@edk2.groups.io On Behalf Of Vitaly > >> Cheptsov via Groups.Io > >> Sent: Monday, October 21, 2019 3:28 PM > >> To: Yao, Jiewen ; Gao, Liming > > >> Cc: devel@edk2.groups.io; Wang, Jian J ; Kinney, > >> Michael D > >> Subject: Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe > string > >> constraint
Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe string constraint assertions
Jiewen, Your explanation makes good sense in the context of "This API is NOT design to handle untrusted input.", however, I believe this is not how it is should work or at least this is not how we would like it to behave. In Unix world there are similar hardened interfaces, for example, strlcpy or strlcat[1]. These interfaces behave quite similar to what you have in BaseLib SafeString, but in the first place they are meant to handle untrusted input. To my experience this situation happens no less often (and in fact much more) than the need to do extra error checking in trusted code, and I expect EDK2 to follow suit. I.e. implement something that can be used not only to check for programmer errors within the module, but also perform the validation of external data. After all, if these were just the assertions, I would have expected for return value to be void not RETURN_STATUS. If we consider all the options we need to do either of the following: - reimplement most of the functions in the caller code, which is non-trivial, increases code size, reduces readability, is more prone to errors, makes reviewing more time consuming, etc. - reimplement all these functions in a separate library, which solves some of the issues, but still increases code size and results in separate interfaces with different contracts - add a pcd to disable assertions, which will disable the debugging handlers and will effectively make these functions behave as runtime checks for untrusted data, numerous people me included expect them do. Last suggestion makes most sense to me. Therefore, I believe that even in the situation we have different opinions on whether this should be on by default, we should at least see the benefit for having an option to make this configurable in other projects. In this case I can update the patch in the next days to preserve the original behaviour and resubmit it as a v2. Best wishes, Vitaly [1] https://linux.die.net/man/3/strlcpy > 21 окт. 2019 г., в 11:07, Yao, Jiewen написал(а): > > > Hi Vitaly > We have discussed the ASSERT usage when we added the first version of code. > > C11 standard supports runtime violation handler registration. > We investigated the behavior of > (1) MS Visual Studio - http://msdn.microsoft.com/en-us/library/bb288454.aspx > (2) SafeCLib - http://sourceforge.net/projects/safeclib/ > (3) Slibc - https://code.google.com/p/slibc/ > > The default behavior is: > (1) Call Debugger > (2) Print error > (3) Call abort() > > As conclusion, we believe it is *caller's responsibility* to make sure the > caller inputs right parameter, instead of let callee check and return error. > > In order to catch such error as early as possible, we decide to use ASSERT, > because it is something never happen. (We still use error handling followed > by to handle the release build.) > > This API is NOT design to handle untrusted input. As such, we believe it is > expected ASSERT behavior. > > > We have other debate, such as if we need ASSERT 2 bytes alignment CHAR16 > process, or if we need ASSERT address alignment for MMIO access. > Per our experience, it is much better to let caller guarantee that, instead > of callee check that. And ASSERT is a good way to catch the issue as early as > possible. > > > > Thank you > Yao Jiewen > >> -Original Message- >> From: devel@edk2.groups.io On Behalf Of Vitaly >> Cheptsov via Groups.Io >> Sent: Monday, October 21, 2019 3:28 PM >> To: Yao, Jiewen ; Gao, Liming >> Cc: devel@edk2.groups.io; Wang, Jian J ; Kinney, >> Michael D >> Subject: Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe >> string >> constraint assertions >> >> Liming, Jiewen, >> >> I am personally fine to resubmit the patch changing the defaults to TRUE, but >> does it actually make sense in any other environment but some special testing >> platform? I cannot imagine any production platform that would need it >> enabled, >> the only use case is to perform analysis on the trusted data usage or >> something >> similar, as I explained on BZ. >> >> As for assertions, I would expect that all PCDs we introduce are meant to >> control unexpected ASSERT behaviour. I.e. where ASSERTs are potentially used >> to signalise about issues coming not only from trusted sources (usage >> contract >> violation) but also from untrusted sources (external data). Such assertions >> cannot be used in production environments, as they may break software, and >> thus we have to implement code to disable them. >> >> Best regards, >> Vitaly >> >>> 21 окт. 2019 г., в 7:28, Yao, Jiewen написал(а): >>> >>> >>> Hi Mike >>> I remember we have discussed it before. >>> >>> The general concern is that: how many additional PCD we need introduce, to >> control different ASSERT in different modules ? >>> >>> We may want to enable *some* assert in some modules, but disable *some >> other* assert. >>> E.g. the assert for linkedlist in base lib is another
Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe string constraint assertions
Hi Vitaly We have discussed the ASSERT usage when we added the first version of code. C11 standard supports runtime violation handler registration. We investigated the behavior of (1) MS Visual Studio - http://msdn.microsoft.com/en-us/library/bb288454.aspx (2) SafeCLib - http://sourceforge.net/projects/safeclib/ (3) Slibc - https://code.google.com/p/slibc/ The default behavior is: (1) Call Debugger (2) Print error (3) Call abort() As conclusion, we believe it is *caller's responsibility* to make sure the caller inputs right parameter, instead of let callee check and return error. In order to catch such error as early as possible, we decide to use ASSERT, because it is something never happen. (We still use error handling followed by to handle the release build.) This API is NOT design to handle untrusted input. As such, we believe it is expected ASSERT behavior. We have other debate, such as if we need ASSERT 2 bytes alignment CHAR16 process, or if we need ASSERT address alignment for MMIO access. Per our experience, it is much better to let caller guarantee that, instead of callee check that. And ASSERT is a good way to catch the issue as early as possible. Thank you Yao Jiewen > -Original Message- > From: devel@edk2.groups.io On Behalf Of Vitaly > Cheptsov via Groups.Io > Sent: Monday, October 21, 2019 3:28 PM > To: Yao, Jiewen ; Gao, Liming > Cc: devel@edk2.groups.io; Wang, Jian J ; Kinney, > Michael D > Subject: Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe > string > constraint assertions > > Liming, Jiewen, > > I am personally fine to resubmit the patch changing the defaults to TRUE, but > does it actually make sense in any other environment but some special testing > platform? I cannot imagine any production platform that would need it enabled, > the only use case is to perform analysis on the trusted data usage or > something > similar, as I explained on BZ. > > As for assertions, I would expect that all PCDs we introduce are meant to > control unexpected ASSERT behaviour. I.e. where ASSERTs are potentially used > to signalise about issues coming not only from trusted sources (usage contract > violation) but also from untrusted sources (external data). Such assertions > cannot be used in production environments, as they may break software, and > thus we have to implement code to disable them. > > Best regards, > Vitaly > > > 21 окт. 2019 г., в 7:28, Yao, Jiewen написал(а): > > > > > > Hi Mike > > I remember we have discussed it before. > > > > The general concern is that: how many additional PCD we need introduce, to > control different ASSERT in different modules ? > > > > We may want to enable *some* assert in some modules, but disable *some > other* assert. > > E.g. the assert for linkedlist in base lib is another example... > > > > What is your thought? > > > > Thank you > > Yao Jiewen > > > >> -Original Message- > >> From: Gao, Liming > >> Sent: Monday, October 21, 2019 11:17 AM > >> To: devel@edk2.groups.io; vit9...@protonmail.com > >> Cc: Yao, Jiewen ; Wang, Jian J > ; > >> Gao, Liming ; Kinney, Michael D > >> > >> Subject: RE: [edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe > string > >> constraint assertions > >> > >> Include more people. > >> > >> Basically, to keep the compatible behavior, > PcdAssertOnSafeStringConstraints > >> default value should be TRUE. > >> The different platform can configure it. > >> > >> Thanks > >> Liming > >>> -Original Message- > >>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of > >>> Vitaly Cheptsov via Groups.Io > >>> Sent: Sunday, October 20, 2019 9:06 PM > >>> To: devel@edk2.groups.io > >>> Subject: [edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe > string > >>> constraint assertions > >>> > >>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2054 > >>> > >>> Runtime data checks are not meant to cause debug assertions > >>> unless explicitly needed by some debug code (thus the PCD) > >>> as this breaks debug builds validating data with BaseLib. > >>> > >>> Signed-off-by: Vitaly Cheptsov > > >>> --- > >>> MdePkg/MdePkg.dec | 6 ++ > >>> MdePkg/Library/BaseLib/BaseLib.inf | 11 ++- > >>> MdePkg/Library/BaseLib/SafeString.c | 4 +++- > >>> MdePkg/MdePkg.uni | 6 ++ > >>> 4 files changed, 21 insertions(+), 6 deletions(-) > >>> > >>> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec > >>> index 3fd7d1634c..dda2cdf401 100644 > >>> --- a/MdePkg/MdePkg.dec > >>> +++ b/MdePkg/MdePkg.dec > >>> @@ -2221,6 +2221,12 @@ [PcdsFixedAtBuild,PcdsPatchableInModule] > >>> # @Prompt Memory Address of GuidedExtractHandler Table. > >>> > >>> > gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|0x1 > >>> 00|UINT64|0x30001015 > >>> > >>> + ## Indicates if safe string constraint violation should assert. > >>> + # TRUE - Safe string constraint violation causes assertion. > >>> + #
[edk2-devel] [PATCH] CryptoPkg: Upgrade OpenSSL to 1.1.1d
Update openssl from 1.1.1b to 1.1.1d. Something needs to be noticed is that, there is a bug existing in the released 1_1_1d version(894da2fb7ed5d314ee5c2fc9fd2d9b8b74111596), which causes build failure. So we switch the code base to a usable version, which is 2 commits later than the stable tag. Now we use the version c3656cc594daac8167721dde7220f0e59ae146fc. This log is to fix the build failure. https://bugzilla.tianocore.org/show_bug.cgi?id=2226 Cc: Jian J Wang Cc: Xiaoyu Lu Signed-off-by: Shenglei Zhang --- CryptoPkg/Library/OpensslLib/OpensslLib.inf | 57 --- .../Library/OpensslLib/OpensslLibCrypto.inf | 49 CryptoPkg/Library/OpensslLib/openssl | 2 +- 3 files changed, 1 insertion(+), 107 deletions(-) diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf b/CryptoPkg/Library/OpensslLib/OpensslLib.inf index 7432321fd431..07c21ebeaa21 100644 --- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf +++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf @@ -34,9 +34,7 @@ [Sources] $(OPENSSL_PATH)/crypto/aes/aes_misc.c $(OPENSSL_PATH)/crypto/aes/aes_ofb.c $(OPENSSL_PATH)/crypto/aes/aes_wrap.c - $(OPENSSL_PATH)/crypto/aes/aes_locl.h $(OPENSSL_PATH)/crypto/aria/aria.c - $(OPENSSL_PATH)/crypto/arm_arch.h $(OPENSSL_PATH)/crypto/asn1/a_bitstr.c $(OPENSSL_PATH)/crypto/asn1/a_d2i_fp.c $(OPENSSL_PATH)/crypto/asn1/a_digest.c @@ -101,21 +99,12 @@ [Sources] $(OPENSSL_PATH)/crypto/asn1/x_sig.c $(OPENSSL_PATH)/crypto/asn1/x_spki.c $(OPENSSL_PATH)/crypto/asn1/x_val.c - $(OPENSSL_PATH)/crypto/asn1/standard_methods.h - $(OPENSSL_PATH)/crypto/asn1/charmap.h - $(OPENSSL_PATH)/crypto/asn1/tbl_standard.h - $(OPENSSL_PATH)/crypto/asn1/asn1_item_list.h - $(OPENSSL_PATH)/crypto/asn1/asn1_locl.h $(OPENSSL_PATH)/crypto/async/arch/async_null.c $(OPENSSL_PATH)/crypto/async/arch/async_posix.c $(OPENSSL_PATH)/crypto/async/arch/async_win.c $(OPENSSL_PATH)/crypto/async/async.c $(OPENSSL_PATH)/crypto/async/async_err.c $(OPENSSL_PATH)/crypto/async/async_wait.c - $(OPENSSL_PATH)/crypto/async/arch/async_win.h - $(OPENSSL_PATH)/crypto/async/async_locl.h - $(OPENSSL_PATH)/crypto/async/arch/async_posix.h - $(OPENSSL_PATH)/crypto/async/arch/async_null.h $(OPENSSL_PATH)/crypto/bio/b_addr.c $(OPENSSL_PATH)/crypto/bio/b_dump.c $(OPENSSL_PATH)/crypto/bio/b_sock.c @@ -138,7 +127,6 @@ [Sources] $(OPENSSL_PATH)/crypto/bio/bss_mem.c $(OPENSSL_PATH)/crypto/bio/bss_null.c $(OPENSSL_PATH)/crypto/bio/bss_sock.c - $(OPENSSL_PATH)/crypto/bio/bio_lcl.h $(OPENSSL_PATH)/crypto/bn/bn_add.c $(OPENSSL_PATH)/crypto/bn/bn_asm.c $(OPENSSL_PATH)/crypto/bn/bn_blind.c @@ -170,9 +158,6 @@ [Sources] $(OPENSSL_PATH)/crypto/bn/bn_srp.c $(OPENSSL_PATH)/crypto/bn/bn_word.c $(OPENSSL_PATH)/crypto/bn/bn_x931p.c - $(OPENSSL_PATH)/crypto/bn/rsaz_exp.h - $(OPENSSL_PATH)/crypto/bn/bn_prime.h - $(OPENSSL_PATH)/crypto/bn/bn_lcl.h $(OPENSSL_PATH)/crypto/buffer/buf_err.c $(OPENSSL_PATH)/crypto/buffer/buffer.c $(OPENSSL_PATH)/crypto/cmac/cm_ameth.c @@ -181,7 +166,6 @@ [Sources] $(OPENSSL_PATH)/crypto/comp/c_zlib.c $(OPENSSL_PATH)/crypto/comp/comp_err.c $(OPENSSL_PATH)/crypto/comp/comp_lib.c - $(OPENSSL_PATH)/crypto/comp/comp_lcl.h $(OPENSSL_PATH)/crypto/conf/conf_api.c $(OPENSSL_PATH)/crypto/conf/conf_def.c $(OPENSSL_PATH)/crypto/conf/conf_err.c @@ -190,8 +174,6 @@ [Sources] $(OPENSSL_PATH)/crypto/conf/conf_mod.c $(OPENSSL_PATH)/crypto/conf/conf_sap.c $(OPENSSL_PATH)/crypto/conf/conf_ssl.c - $(OPENSSL_PATH)/crypto/conf/conf_lcl.h - $(OPENSSL_PATH)/crypto/conf/conf_def.h $(OPENSSL_PATH)/crypto/cpt_err.c $(OPENSSL_PATH)/crypto/cryptlib.c $(OPENSSL_PATH)/crypto/ctype.c @@ -215,8 +197,6 @@ [Sources] $(OPENSSL_PATH)/crypto/des/set_key.c $(OPENSSL_PATH)/crypto/des/str2key.c $(OPENSSL_PATH)/crypto/des/xcbc_enc.c - $(OPENSSL_PATH)/crypto/des/spr.h - $(OPENSSL_PATH)/crypto/des/des_locl.h $(OPENSSL_PATH)/crypto/dh/dh_ameth.c $(OPENSSL_PATH)/crypto/dh/dh_asn1.c $(OPENSSL_PATH)/crypto/dh/dh_check.c @@ -231,7 +211,6 @@ [Sources] $(OPENSSL_PATH)/crypto/dh/dh_prn.c $(OPENSSL_PATH)/crypto/dh/dh_rfc5114.c $(OPENSSL_PATH)/crypto/dh/dh_rfc7919.c - $(OPENSSL_PATH)/crypto/dh/dh_locl.h $(OPENSSL_PATH)/crypto/dso/dso_dl.c $(OPENSSL_PATH)/crypto/dso/dso_dlfcn.c $(OPENSSL_PATH)/crypto/dso/dso_err.c @@ -239,7 +218,6 @@ [Sources] $(OPENSSL_PATH)/crypto/dso/dso_openssl.c $(OPENSSL_PATH)/crypto/dso/dso_vms.c $(OPENSSL_PATH)/crypto/dso/dso_win32.c - $(OPENSSL_PATH)/crypto/dso/dso_locl.h $(OPENSSL_PATH)/crypto/ebcdic.c $(OPENSSL_PATH)/crypto/err/err.c $(OPENSSL_PATH)/crypto/err/err_prn.c @@ -304,13 +282,11 @@ [Sources] $(OPENSSL_PATH)/crypto/evp/pmeth_fn.c $(OPENSSL_PATH)/crypto/evp/pmeth_gn.c $(OPENSSL_PATH)/crypto/evp/pmeth_lib.c - $(OPENSSL_PATH)/crypto/evp/evp_locl.h $(OPENSSL_PATH)/crypto/ex_data.c $(OPENSSL_PATH)/crypto/getenv.c
Re: [edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe string constraint assertions
Liming, Jiewen, I am personally fine to resubmit the patch changing the defaults to TRUE, but does it actually make sense in any other environment but some special testing platform? I cannot imagine any production platform that would need it enabled, the only use case is to perform analysis on the trusted data usage or something similar, as I explained on BZ. As for assertions, I would expect that all PCDs we introduce are meant to control unexpected ASSERT behaviour. I.e. where ASSERTs are potentially used to signalise about issues coming not only from trusted sources (usage contract violation) but also from untrusted sources (external data). Such assertions cannot be used in production environments, as they may break software, and thus we have to implement code to disable them. Best regards, Vitaly > 21 окт. 2019 г., в 7:28, Yao, Jiewen написал(а): > > > Hi Mike > I remember we have discussed it before. > > The general concern is that: how many additional PCD we need introduce, to > control different ASSERT in different modules ? > > We may want to enable *some* assert in some modules, but disable *some other* > assert. > E.g. the assert for linkedlist in base lib is another example... > > What is your thought? > > Thank you > Yao Jiewen > >> -Original Message- >> From: Gao, Liming >> Sent: Monday, October 21, 2019 11:17 AM >> To: devel@edk2.groups.io; vit9...@protonmail.com >> Cc: Yao, Jiewen ; Wang, Jian J ; >> Gao, Liming ; Kinney, Michael D >> >> Subject: RE: [edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe >> string >> constraint assertions >> >> Include more people. >> >> Basically, to keep the compatible behavior, PcdAssertOnSafeStringConstraints >> default value should be TRUE. >> The different platform can configure it. >> >> Thanks >> Liming >>> -Original Message- >>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of >>> Vitaly Cheptsov via Groups.Io >>> Sent: Sunday, October 20, 2019 9:06 PM >>> To: devel@edk2.groups.io >>> Subject: [edk2-devel] [PATCH v1 1/1] MdePkg: Add PCD to disable safe string >>> constraint assertions >>> >>> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2054 >>> >>> Runtime data checks are not meant to cause debug assertions >>> unless explicitly needed by some debug code (thus the PCD) >>> as this breaks debug builds validating data with BaseLib. >>> >>> Signed-off-by: Vitaly Cheptsov > >>> --- >>> MdePkg/MdePkg.dec | 6 ++ >>> MdePkg/Library/BaseLib/BaseLib.inf | 11 ++- >>> MdePkg/Library/BaseLib/SafeString.c | 4 +++- >>> MdePkg/MdePkg.uni | 6 ++ >>> 4 files changed, 21 insertions(+), 6 deletions(-) >>> >>> diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec >>> index 3fd7d1634c..dda2cdf401 100644 >>> --- a/MdePkg/MdePkg.dec >>> +++ b/MdePkg/MdePkg.dec >>> @@ -2221,6 +2221,12 @@ [PcdsFixedAtBuild,PcdsPatchableInModule] >>> # @Prompt Memory Address of GuidedExtractHandler Table. >>> >>> gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress|0x1 >>> 00|UINT64|0x30001015 >>> >>> + ## Indicates if safe string constraint violation should assert. >>> + # TRUE - Safe string constraint violation causes assertion. >>> + # FALSE - Safe string constraint violation does not cause >>> assertion. >>> + # @Prompt Enable safe string constraint violation assertions. >>> + >>> gEfiMdePkgTokenSpaceGuid.PcdAssertOnSafeStringConstraints|FALSE|BOOL >>> EAN|0x002e >>> + >>> [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, PcdsDynamicEx] >>> ## This value is used to set the base address of PCI express hierarchy. >>> # @Prompt PCI Express Base Address. >>> diff --git a/MdePkg/Library/BaseLib/BaseLib.inf >>> b/MdePkg/Library/BaseLib/BaseLib.inf >>> index 3586beb0ab..bc98bc6134 100644 >>> --- a/MdePkg/Library/BaseLib/BaseLib.inf >>> +++ b/MdePkg/Library/BaseLib/BaseLib.inf >>> @@ -390,11 +390,12 @@ [LibraryClasses] >>> BaseMemoryLib >>> >>> [Pcd] >>> - gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength ## >>> SOMETIMES_CONSUMES >>> - gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength ## >>> SOMETIMES_CONSUMES >>> - gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength ## >>> SOMETIMES_CONSUMES >>> - gEfiMdePkgTokenSpaceGuid.PcdControlFlowEnforcementPropertyMask >>> ## SOMETIMES_CONSUMES >>> - gEfiMdePkgTokenSpaceGuid.PcdSpeculationBarrierType ## >>> SOMETIMES_CONSUMES >>> + gEfiMdePkgTokenSpaceGuid.PcdAssertOnSafeStringConstraints ## >>> SOMETIMES_CONSUMES >>> + gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength ## >>> SOMETIMES_CONSUMES >>> + gEfiMdePkgTokenSpaceGuid.PcdMaximumAsciiStringLength## >>> SOMETIMES_CONSUMES >>> + gEfiMdePkgTokenSpaceGuid.PcdMaximumUnicodeStringLength ## >>> SOMETIMES_CONSUMES >>> + gEfiMdePkgTokenSpaceGuid.PcdControlFlowEnforcementPropertyMask >>> ## SOMETIMES_CONSUMES >>> +