Re: [edk2] [PATCH v2 1/3] IntelFrameworkPkg/LegacyBios.h: Add a macro to guarantee page 0 access
Thanks for the comment. The {} will be added.
Sincerely,
Jian
> -Original Message-
> From: Ni, Ruiyu
> Sent: Thursday, December 07, 2017 3:00 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Gao, Liming ; Kinney, Michael D
>
> Subject: Re: [PATCH v2 1/3] IntelFrameworkPkg/LegacyBios.h: Add a macro to
> guarantee page 0 access
>
> On 12/7/2017 1:40 PM, Jian J Wang wrote:
> >> v2:
> >> a. Fix a typo in expression in the macro ACCESS_PAGE0_CODE
> >> b. Fix GCC49 build error
> >
> > ue to the introduction of NULL pointer detection feature, page 0 will be
> > disabled if the feature is enabled, which will cause legacy code failed to
> > update legacy data in page 0. This macro is introduced to make sure the
> > page 0 is enabled before those code and restore the original status of it
> > afterwards.
> >
> > Another reason to introduce this macro is to eliminate the dependency on
> > the PcdNullPointerDetectionPropertyMask. Because this is a new PCD, it
> > could cause some backward compatibility issue for some old packages.
> >
> > This macro will simply check if the page 0 is disabled or not. If it's
> > disabled, it will enable it before code updating page 0 and disable it
> > afterwards. Otherwise, this macro will do nothing to page 0.
> >
> > The usage of the macro will be look like (similar to DEBUG_CODE macro):
> >
> > ACCESS_PAGE0_CODE(
> >
> > );
> >
> > Cc: Liming Gao
> > Cc: Michael D Kinney
> > Cc: Ruiyu Ni
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jian J Wang
> > ---
> > IntelFrameworkPkg/Include/Protocol/LegacyBios.h | 34
> +
> > 1 file changed, 34 insertions(+)
> >
> > diff --git a/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
> b/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
> > index 641f101bce..6a5f5464e7 100644
> > --- a/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
> > +++ b/IntelFrameworkPkg/Include/Protocol/LegacyBios.h
> > @@ -1518,6 +1518,40 @@ struct _EFI_LEGACY_BIOS_PROTOCOL {
> > EFI_LEGACY_BIOS_BOOT_UNCONVENTIONAL_DEVICE
> BootUnconventionalDevice;
> > };
> >
> > +//
> > +// Legacy BIOS needs to access memory in page 0 (0-4095), which is disabled
> if
> > +// NULL pointer detection feature is enabled. Following macro can be used
> > to
> > +// enable/disable page 0 before/after accessing it.
> > +//
> > +#define ACCESS_PAGE0_CODE(statements) \
> > + do { \
> > +EFI_STATUSStatus_; \
> > +EFI_GCD_MEMORY_SPACE_DESCRIPTOR Desc_;\
> > +\
> > +Desc_.Attributes = 0; \
> > +Status_ = gDS->GetMemorySpaceDescriptor (0, &Desc_);\
> > +ASSERT_EFI_ERROR (Status_); \
> > +if ((Desc_.Attributes & EFI_MEMORY_RP) != 0) { \
> > + Status_ = gDS->SetMemorySpaceAttributes ( \
> > + 0,\
> > + EFI_PAGES_TO_SIZE(1), \
> > + Desc_.Attributes & ~(UINT64)EFI_MEMORY_RP \
> > + );\
> > + ASSERT_EFI_ERROR (Status_); \
> > +} \
> > +\
> > +statements; \
>
> It's better to surrounded statements with {}.
> So that when statements contains variable declaration, C compiler
> doesn't complain.
>
> > +\
> > +if ((Desc_.Attributes & EFI_MEMORY_RP) != 0) { \
> > + Status_ = gDS->SetMemorySpaceAttributes ( \
> > + 0,\
> > + EFI_PAGES_TO_SIZE(1), \
> > + Desc_.Attributes \
> > + );\
> > + ASSERT_EFI_ERROR (Status_); \
> > +} \
> > + } while (FALSE)
> > +
> > extern EFI_GUID gEfiLegacyBiosProtocolGuid;
> >
> > #endif
> >
>
> With the above suggested changes,
>Reviewed-by: Ruiyu Ni
>
> --
> Thanks,
> Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 0/2] Follow PI spec to update EFI_MM_COMMUNICATE
Reviewed-by: jiewen@intel.com > -Original Message- > From: Zeng, Star > Sent: Wednesday, December 6, 2017 5:18 PM > To: edk2-devel@lists.01.org > Cc: Zeng, Star ; Yao, Jiewen ; Gao, > Liming ; Kinney, Michael D > > Subject: [PATCH 0/2] Follow PI spec to update EFI_MM_COMMUNICATE > > Follow PI spec (>= 1.5) to add new return status code description > and make CommSize OPTIONAL. > > Handle CommSize OPTIONAL case for SmmCommunicate. > And return EFI_ACCESS_DENIED when CommunicationBuffer > is not valid for SMM to access. > > Cc: Jiewen Yao > Cc: Liming Gao > Cc: Michael D Kinney > > Star Zeng (2): > MdePkg MmCommunication.h: Follow PI spec to update > EFI_MM_COMMUNICATE > MdeModulePkg PiSmmIpl: Handle CommSize OPTIONAL case > > MdeModulePkg/Core/PiSmmCore/PiSmmCore.c | 2 +- > MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c| 61 > --- > MdePkg/Include/Protocol/MmCommunication.h | 14 ++- > 3 files changed, 52 insertions(+), 25 deletions(-) > > -- > 2.7.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] SignedCapsulePkg: Update EdkiiSystemCapsuleLib to check PCD value
Reviewed-by: jiewen@intel.com
> -Original Message-
> From: Gao, Liming
> Sent: Tuesday, November 28, 2017 11:27 AM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen
> Subject: [Patch] SignedCapsulePkg: Update EdkiiSystemCapsuleLib to check PCD
> value
>
> If PCD value is not set, register PcdCallBack to hook PCD value set
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao
> Cc: Jiewen Yao
> ---
> .../EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.c | 86
> +-
> .../EdkiiSystemCapsuleLib.inf | 3 +
> 2 files changed, 87 insertions(+), 2 deletions(-)
>
> diff --git
> a/SignedCapsulePkg/Library/EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.c
> b/SignedCapsulePkg/Library/EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.c
> index 62be8eb..876d225 100644
> --- a/SignedCapsulePkg/Library/EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.c
> +++
> b/SignedCapsulePkg/Library/EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.c
> @@ -29,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -600,6 +601,10 @@ CapsuleAuthenticateSystemFirmware (
>// NOTE: This function need run in an isolated environment.
>// Do not touch FMP protocol and its private structure.
>//
> + if (mImageFmpInfo == NULL) {
> +DEBUG((DEBUG_INFO, "ImageFmpInfo is not set\n"));
> +return EFI_SECURITY_VIOLATION;
> + }
>
>Result = ExtractAuthenticatedImage((VOID *)Image, ImageSize,
> LastAttemptStatus, AuthenticatedImage, AuthenticatedImageSize);
>if (!Result) {
> @@ -655,6 +660,53 @@ CapsuleAuthenticateSystemFirmware (
> }
>
> /**
> + PcdCallBack gets the real set PCD value
> +
> + @param[in] CallBackGuidThe PCD token GUID being set.
> + @param[in] CallBackToken The PCD token number being set.
> + @param[in, out] TokenData A pointer to the token data being set.
> + @param[in] TokenDataSize The size, in bytes, of the data being set.
> +
> +**/
> +VOID
> +EFIAPI
> +EdkiiSystemCapsuleLibPcdCallBack (
> + INCONST GUID*CallBackGuid, OPTIONAL
> + INUINTN CallBackToken,
> + IN OUT VOID *TokenData,
> + INUINTN TokenDataSize
> + )
> +{
> + if (CompareGuid (CallBackGuid, &gEfiSignedCapsulePkgTokenSpaceGuid) &&
> + CallBackToken == PcdToken (PcdEdkiiSystemFirmwareImageDescriptor))
> {
> +mImageFmpInfoSize = TokenDataSize;
> +mImageFmpInfo = AllocateCopyPool (mImageFmpInfoSize, TokenData);
> +ASSERT(mImageFmpInfo != NULL);
> +//
> +// Cancel Callback after get the real set value
> +//
> +LibPcdCancelCallback (
> + &gEfiSignedCapsulePkgTokenSpaceGuid,
> + PcdToken (PcdEdkiiSystemFirmwareImageDescriptor),
> + EdkiiSystemCapsuleLibPcdCallBack
> + );
> + }
> +
> + if (CompareGuid (CallBackGuid, &gEfiSignedCapsulePkgTokenSpaceGuid) &&
> + CallBackToken == PcdToken (PcdEdkiiSystemFirmwareFileGuid)) {
> +CopyGuid(&mEdkiiSystemFirmwareFileGuid, TokenData);
> +//
> +// Cancel Callback after get the real set value
> +//
> +LibPcdCancelCallback (
> + &gEfiSignedCapsulePkgTokenSpaceGuid,
> + PcdToken (PcdEdkiiSystemFirmwareFileGuid),
> + EdkiiSystemCapsuleLibPcdCallBack
> + );
> + }
> +}
> +
> +/**
>The constructor function.
>
>@retval EFI_SUCCESS The constructor successfully .
> @@ -666,8 +718,38 @@ EdkiiSystemCapsuleLibConstructor (
>)
> {
>mImageFmpInfoSize =
> PcdGetSize(PcdEdkiiSystemFirmwareImageDescriptor);
> - mImageFmpInfo = AllocateCopyPool (mImageFmpInfoSize,
> PcdGetPtr(PcdEdkiiSystemFirmwareImageDescriptor));
> - ASSERT(mImageFmpInfo != NULL);
> + mImageFmpInfo =
> PcdGetPtr(PcdEdkiiSystemFirmwareImageDescriptor);
> + //
> + // Verify Firmware Image Descriptor first
> + //
> + if (mImageFmpInfoSize < sizeof
> (EDKII_SYSTEM_FIRMWARE_IMAGE_DESCRIPTOR) ||
> + mImageFmpInfo->Signature !=
> EDKII_SYSTEM_FIRMWARE_IMAGE_DESCRIPTOR_SIGNATURE) {
> +//
> +// SystemFirmwareImageDescriptor is not set.
> +// Register PCD set callback to hook PCD value set.
> +//
> +mImageFmpInfo = NULL;
> +mImageFmpInfoSize = 0;
> +LibPcdCallbackOnSet (
> + &gEfiSignedCapsulePkgTokenSpaceGuid,
> + PcdToken (PcdEdkiiSystemFirmwareImageDescriptor),
> + EdkiiSystemCapsuleLibPcdCallBack
> + );
> + } else {
> +mImageFmpInfo = AllocateCopyPool (mImageFmpInfoSize,
> mImageFmpInfo);
> +ASSERT(mImageFmpInfo != NULL);
> + }
> +
>CopyGuid(&mEdkiiSystemFirmwareFileGuid,
> PcdGetPtr(PcdEdkiiSystemFirmwareFileGuid));
> + //
> + // Verify GUID value first
> + //
> + if (CompareGuid (&mEdkiiSystemFirmwareFileGuid, &gZeroGuid)) {
> +LibPcdCallbackOnSet (
> + &gEfiSignedCapsulePkgTokenSpaceGuid,
> + PcdToken (PcdEdkiiSystemFirmwareFileGuid),
> + EdkiiSystemCapsuleLibPcdCallBack
> + );
> + }
>return EFI_SUC
Re: [edk2] [PATCH v4 00/11] Implement stack guard feature
Thanks. I still think we should add version field, just in case we need add more in this CPU_EXCEPTION_INIT_DATA. With version field added, reviewed-by: jiewen@intel.com I suggest CpuModulePkg can double check the patch. Thank you Yao Jiewen > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J > Wang > Sent: Wednesday, December 6, 2017 4:50 PM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH v4 00/11] Implement stack guard feature > > > v4: > > a. Change name of new data structure from CPU_EXCEPTION_INIT_DATA_EX > > to CPU_EXCEPTION_INIT_DATA > > b. Add "size" field for all "buffer" fields in CPU_EXCEPTION_INIT_DATA > > c. Add separate fields for IA32 and X64 in CPU_EXCEPTION_INIT_DATA > > d. Change related code per changes in CPU_EXCEPTION_INIT_DATA > > > v3: > > a. Change new API InitializeCpuExceptionStackSwitchHandlers() to > > InitializeCpuExceptionHandlersEx(). Related code are updated > accordingly. > > b. Move EXCEPTION_STACK_SWITCH_DATA to CpuExceptionHandlerLib.h > > and change the name to CPU_EXCEPTION_INIT_DATA_EX for the sake > > of the API name change. > > c. Add more general macros in BaseLib.h. > > d. Add dummy implementation of InitializeCpuExceptionHandlersEx for > > SEC, PEI and SMM but implement a full version for DXE. > > e. Add dummy InitializeCpuExceptionHandlersEx for ARM's > CpuExceptionHandlerLib > > and NULL version of CpuExceptionHandlerLib > > f. Call InitializeCpuExceptionHandlersEx() in DxeMain instead of > > InitializeCpuExceptionHandlers(). > > > > v2: > > a. Introduce and implement new API > InitializeCpuExceptionStackSwitchHandlers(). > > b. Add stack switch related general definitions of IA32 in BaseLib.h. > > c. Add two new PCDs to configure exception vector list and stack size. > > d. Add code to save/restore GDTR, IDTR and TR for AP. > > e. Refactor exception handler code for stack switch. > > f. Add code to setup stack switch for AP besides BSP. > > Stack guard feature makes use of paging mechanism to monitor if there's a > stack overflow occurred during boot. A new PCD PcdCpuStackGuard is added to > enable/disable this feature. PCD PcdCpuStackSwitchExceptionList and > PcdCpuKnownGoodStackSize are introduced to configure the required > exceptions > and stack size. > > If this feature is enabled, DxeIpl will setup page tables and set page where > the stack bottom is at to be NON-PRESENT. If stack overflow occurs, Page > Fault exception will be triggered. > > In order to make sure exception handler works normally even when the stack > is corrupted, stack switching is implemented in exception library. > > Due to the mechanism behind Stack Guard, this feature is only avaiable for > UEFI drivers (memory avaiable). That also means it doesn't support NT32 > emulated platform (paging not supported). > > Jian J Wang (11): > MdeModulePkg/metafile: Add PCD PcdCpuStackGuard > UefiCpuPkg/UefiCpuPkg.dec: Add two new PCDs for stack switch > MdeModulePkg/CpuExceptionHandlerLib.h: Add a new API > InitializeCpuExceptionHandlersEx > MdePkg/BaseLib: Add stack switch related definitions for IA32 > UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support > MdeModulePkg/CpuExceptionHandlerLibNull: Add new API implementation > ArmPkg/ArmExceptionLib: Add implementation of new API > UefiCpuPkg/MpLib: Add GDTR, IDTR and TR in saved AP data > UefiCpuPkg/CpuDxe: Initialize stack switch for MP > MdeModulePkg/Core/Dxe: Call new API InitializeCpuExceptionHandlersEx > instead > MdeModulePkg/DxeIpl: Enable paging for Stack Guard > > ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.c | 33 ++ > MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c| 2 +- > MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf| 5 +- > MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c| 4 + > MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c | 1 + > MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 51 ++- > .../Include/Library/CpuExceptionHandlerLib.h | 91 + > .../CpuExceptionHandlerLibNull.c | 34 ++ > MdeModulePkg/MdeModulePkg.dec | 7 + > MdeModulePkg/MdeModulePkg.uni | 7 + > MdePkg/Include/Library/BaseLib.h | 117 ++ > MdePkg/Library/BaseLib/BaseLib.inf | 3 + > MdePkg/Library/BaseLib/Ia32/WriteTr.nasm | 36 ++ > MdePkg/Library/BaseLib/X64/WriteTr.nasm| 37 ++ > UefiCpuPkg/CpuDxe/CpuDxe.inf | 3 + > UefiCpuPkg/CpuDxe/CpuMp.c | 188 > ++ > .../CpuExceptionHandlerLib/CpuExceptionCommon.h| 39 ++ > .../DxeCpuExceptionHandlerLib.inf | 6 + > .../Library/CpuExceptionHandlerLib/DxeException.c | 83 + > .../Ia32/ArchExceptionHandler.c| 187 ++ > .../Ia32/ArchInterruptDefs.h |
Re: [edk2] MdeModulePkg/UefiPxeBcDxe: Question about IcmpErrorListenHandler in PxeBcImpl.c
Hi Jiaxin,
Thanks for your reply.
You say "IcmpErrorRcvToken is only used to get ICMP error from IP
layer", does that mean only ICMP error packets will go to
IcmpErrorListenHandler?
If it is the case, how do we make it? I can only find a simple
Ip4->Receive is called to receive IP4 packets; how are other types of
IP4 packets filtered out?
If it is not, why don't we need to filter the packets in
IcmpErrorListenHandler? If we recycle the packets in
IcmpErrorListenHandler, will it cause the upper layer of protocols fail
to fetch RxData?
Please forgive me if my questions are too stupid :)
Regards,
Gary (Heyi Guo)
在 12/7/2017 3:48 PM, Wu, Jiaxin 写道:
Hi Gary,
IcmpErrorRcvToken is only used to get ICMP error from IP layer, and the data will
be copied to Mode->IcmpError. So, I think the RxData should be recycled.
Besides, EFI_IP_PROTO_ICMP should be also checked in the call function but
currently it's not:
if (!EFI_IP4_EQUAL (&RxData->Header->DestinationAddress,
&Mode->StationIp.v4)) {
//
// The dest address is not equal to Station Ip address, discard it.
//
goto CleanUp;
}
+if (&RxData->Header->Protocol != EFI_IP_PROTO_ICMP) {
+//
+// The protocol value in the header of the receveid packet should be
EFI_IP_PROTO_ICMP.
+//
+goto CleanUp;
+}
Thanks the report.
Thanks,
Jiaxin
-Original Message-
From: Guo Heyi [mailto:heyi@linaro.org]
Sent: Thursday, December 7, 2017 12:07 PM
To: edk2-devel@lists.01.org
Cc: Zeng, Star ; Dong, Eric ; Ni,
Ruiyu ; Fu, Siyuan ; Wu, Jiaxin
Subject: MdeModulePkg/UefiPxeBcDxe: Question about
IcmpErrorListenHandler in PxeBcImpl.c
Hi folks,
In PxeBcImpl.c, we have IcmpErrorListenHandler which seems to process
ICMP errors. But in EfiPxeBcStart function, we can see Private-
IcmpErrorRcvToken.Event is only a common event and Ip4->Receive is
called to receive IP4 packets. So will IcmpErrorListenHandler receive all IP4
packets belonging to this network interface, or will it only receive ICMP error
packets? If it is the latter situation, how do we make it?
The background of this question is that when we flush the network with
deprecated ICMP packets (type 15, 16, ...), RxData will not be recycled and
the list of UEFI events becomes longer and longer, which finally impacts
system performance a lot. If only error ICMP will be received by
IcmpErrorListenHandler, we'd like to patch it as below:
diff --git a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
index 6d4f33f..f74b264 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
@@ -216,8 +216,6 @@ IcmpErrorListenHandlerDpc (
CopiedPointer += CopiedLen;
}
- goto Resume;
-
CleanUp:
gBS->SignalEvent (RxData->RecycleSignal);
We tested and it worked, but we are still not sure whether it will impact
other code in the network stack.
Please let me know your comments.
Thanks,
Gary (Heyi Guo)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v4 00/11] Implement stack guard feature
I missed that part. I'll add it. Thanks. Regards, Jian > -Original Message- > From: Yao, Jiewen > Sent: Thursday, December 07, 2017 4:17 PM > To: Wang, Jian J ; edk2-devel@lists.01.org > Subject: RE: [edk2] [PATCH v4 00/11] Implement stack guard feature > > Thanks. I still think we should add version field, just in case we need add > more in > this CPU_EXCEPTION_INIT_DATA. > > With version field added, reviewed-by: jiewen@intel.com > > I suggest CpuModulePkg can double check the patch. > > Thank you > Yao Jiewen > > > -Original Message- > > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian > J > > Wang > > Sent: Wednesday, December 6, 2017 4:50 PM > > To: edk2-devel@lists.01.org > > Subject: [edk2] [PATCH v4 00/11] Implement stack guard feature > > > > > v4: > > > a. Change name of new data structure from > CPU_EXCEPTION_INIT_DATA_EX > > > to CPU_EXCEPTION_INIT_DATA > > > b. Add "size" field for all "buffer" fields in CPU_EXCEPTION_INIT_DATA > > > c. Add separate fields for IA32 and X64 in CPU_EXCEPTION_INIT_DATA > > > d. Change related code per changes in CPU_EXCEPTION_INIT_DATA > > > > > v3: > > > a. Change new API InitializeCpuExceptionStackSwitchHandlers() to > > > InitializeCpuExceptionHandlersEx(). Related code are updated > > accordingly. > > > b. Move EXCEPTION_STACK_SWITCH_DATA to CpuExceptionHandlerLib.h > > > and change the name to CPU_EXCEPTION_INIT_DATA_EX for the sake > > > of the API name change. > > > c. Add more general macros in BaseLib.h. > > > d. Add dummy implementation of InitializeCpuExceptionHandlersEx for > > > SEC, PEI and SMM but implement a full version for DXE. > > > e. Add dummy InitializeCpuExceptionHandlersEx for ARM's > > CpuExceptionHandlerLib > > > and NULL version of CpuExceptionHandlerLib > > > f. Call InitializeCpuExceptionHandlersEx() in DxeMain instead of > > > InitializeCpuExceptionHandlers(). > > > > > > > v2: > > > a. Introduce and implement new API > > InitializeCpuExceptionStackSwitchHandlers(). > > > b. Add stack switch related general definitions of IA32 in BaseLib.h. > > > c. Add two new PCDs to configure exception vector list and stack size. > > > d. Add code to save/restore GDTR, IDTR and TR for AP. > > > e. Refactor exception handler code for stack switch. > > > f. Add code to setup stack switch for AP besides BSP. > > > > Stack guard feature makes use of paging mechanism to monitor if there's a > > stack overflow occurred during boot. A new PCD PcdCpuStackGuard is added > to > > enable/disable this feature. PCD PcdCpuStackSwitchExceptionList and > > PcdCpuKnownGoodStackSize are introduced to configure the required > > exceptions > > and stack size. > > > > If this feature is enabled, DxeIpl will setup page tables and set page where > > the stack bottom is at to be NON-PRESENT. If stack overflow occurs, Page > > Fault exception will be triggered. > > > > In order to make sure exception handler works normally even when the stack > > is corrupted, stack switching is implemented in exception library. > > > > Due to the mechanism behind Stack Guard, this feature is only avaiable for > > UEFI drivers (memory avaiable). That also means it doesn't support NT32 > > emulated platform (paging not supported). > > > > Jian J Wang (11): > > MdeModulePkg/metafile: Add PCD PcdCpuStackGuard > > UefiCpuPkg/UefiCpuPkg.dec: Add two new PCDs for stack switch > > MdeModulePkg/CpuExceptionHandlerLib.h: Add a new API > > InitializeCpuExceptionHandlersEx > > MdePkg/BaseLib: Add stack switch related definitions for IA32 > > UefiCpuPkg/CpuExceptionHandlerLib: Add stack switch support > > MdeModulePkg/CpuExceptionHandlerLibNull: Add new API implementation > > ArmPkg/ArmExceptionLib: Add implementation of new API > > UefiCpuPkg/MpLib: Add GDTR, IDTR and TR in saved AP data > > UefiCpuPkg/CpuDxe: Initialize stack switch for MP > > MdeModulePkg/Core/Dxe: Call new API InitializeCpuExceptionHandlersEx > > instead > > MdeModulePkg/DxeIpl: Enable paging for Stack Guard > > > > ArmPkg/Library/ArmExceptionLib/ArmExceptionLib.c | 33 ++ > > MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c| 2 +- > > MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf| 5 +- > > MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c| 4 + > > MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c | 1 + > > MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 51 ++- > > .../Include/Library/CpuExceptionHandlerLib.h | 91 + > > .../CpuExceptionHandlerLibNull.c | 34 ++ > > MdeModulePkg/MdeModulePkg.dec | 7 + > > MdeModulePkg/MdeModulePkg.uni | 7 + > > MdePkg/Include/Library/BaseLib.h | 117 ++ > > MdePkg/Library/BaseLib/BaseLib.inf | 3 + > > MdePkg/Library/BaseLib/Ia32/WriteTr.nasm | 36 ++ > > MdePkg/Library/BaseLib/X64/WriteTr.nasm| 3
Re: [edk2] [Patch] SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix duplicate symbol
Reviewed-by: Hao Wu
Best Regards,
Hao Wu
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Liming Gao
> Sent: Thursday, December 07, 2017 3:48 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D; Wu, Hao A; Laszlo Ersek; Andrew Fish; Jeff Fan
> Subject: [edk2] [Patch] SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix
> duplicate symbol
>
> From: Michael Kinney
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=573
> https://bugzilla.tianocore.org/show_bug.cgi?id=796
>
> The same issue is reported again by GCC. Resend this patch again.
> This patch renames the duplicated function name to fix it.
>
> The SecPeiDebugAgentLib uses the global variable
> mMemoryDiscoveredNotifyList for a PPI notification on
> the Memory Discovered PPI. This same variable name is
> used in the DxeIplPeim for the same PPI notification.
>
> The XCODE5 tool chain detects this duplicate symbol
> when the OVMF platform is built with the flag
> -D SOURCE_DEBUG_ENABLE.
>
> The fix is to rename this global variable in the
> SecPeiDebugAgentLib library.
>
> Cc: Andrew Fish
> Cc: Jeff Fan
> Cc: Hao Wu
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael D Kinney
> Reviewed-by: Jeff Fan
> ---
> .../Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c | 4
> ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebug
> AgentLib.c
> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebug
> AgentLib.c
> index b717e33..9f5223a 100644
> ---
> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebug
> AgentLib.c
> +++
> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebug
> AgentLib.c
> @@ -32,7 +32,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED
> EFI_PEI_PPI_DESCRIPTOR mVectorHandoffInf
>}
> };
>
> -GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR
> mMemoryDiscoveredNotifyList[1] = {
> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR
> mDebugAgentMemoryDiscoveredNotifyList[1] = {
>{
> (EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK |
> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
> &gEfiPeiMemoryDiscoveredPpiGuid,
> @@ -554,7 +554,7 @@ InitializeDebugAgent (
> // Register for a callback once memory has been initialized.
> // If memery has been ready, the callback funtion will be invoked
> immediately
> //
> -Status = PeiServicesNotifyPpi (&mMemoryDiscoveredNotifyList[0]);
> +Status = PeiServicesNotifyPpi
> (&mDebugAgentMemoryDiscoveredNotifyList[0]);
> if (EFI_ERROR (Status)) {
>DEBUG ((EFI_D_ERROR, "DebugAgent: Failed to register memory
> discovered callback function!\n"));
>CpuDeadLoop ();
> --
> 2.6.3.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> GitPatchExtractor 1.1
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [RFC] MdePkg/Spi : Modify SPI Protocol strctures to make it more generic
Issue_1: Currenty SPI IO and SPI HC protocol strcture is not equipped
to handle all type of SPI commands
e.g. QuadIo Read Command (0xEBh) in spansion flash S25FS512S will not
work.
Cause: Currenty SPI protocol describes a SPI transaction as combination
of data and address and command, which would all be transmitted on
same data bus (1 or 2 or 4).
BUT when we have a case in which command is send one single data bus and
address and data is sent one 4 data bus (like 0xEB in spansion), then
this will not work with current strcture.
Fix: Instead of making a single transaction, we can specify a group of
transactions (called packet, terminology borrowed from I2c Protocol) in
which each transaction specifies the data width, frequency, delay and
read/write info.
Issue_2: Specify additional data about SPI transaction (i.e. transaction
is of type cmd, address, data, dummy etc). some controllers need this
info to communicate with SPI peripheral. others can ignore this info.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pankaj Bansal
---
MdePkg/Include/Protocol/SpiHc.h | 15 +-
MdePkg/Include/Protocol/SpiIo.h | 250 --
2 files changed, 104 insertions(+), 161 deletions(-)
diff --git a/MdePkg/Include/Protocol/SpiHc.h b/MdePkg/Include/Protocol/SpiHc.h
index 12fe5d2..65964bc 100644
--- a/MdePkg/Include/Protocol/SpiHc.h
+++ b/MdePkg/Include/Protocol/SpiHc.h
@@ -110,8 +110,11 @@ typedef EFI_STATUS
status.
@param[in] ThisPointer to an EFI_SPI_HC_PROTOCOL structure.
- @param[in] BusTransaction Pointer to a EFI_SPI_BUS_ TRANSACTION containing
- the description of the SPI transaction to perform.
+ @param[in] SpiPeripheral The address of an EFI_SPI_PERIPHERAL data
structure
+ describing the SPI peripheral from(to) which
+ read(write) transactions to be performed.
+ @param[in] RequestPacket Pointer to a EFI_SPI_REQUEST_PACKET containing
+ the description of the SPI transactions to
perform.
@retval EFI_SUCCESS The transaction completed successfully
@retval EFI_BAD_BUFFER_SIZE The BusTransaction->WriteBytes value is invalid,
@@ -124,7 +127,8 @@ typedef EFI_STATUS
typedef EFI_STATUS
(EFIAPI *EFI_SPI_HC_PROTOCOL_TRANSACTION) (
IN CONST EFI_SPI_HC_PROTOCOL *This,
- IN EFI_SPI_BUS_TRANSACTION*BusTransaction
+ IN CONST EFI_SPI_PERIPHERAL *SpiPeripheral;
+ IN EFI_SPI_REQUEST_PACKET *RequestPacket
);
///
@@ -135,7 +139,6 @@ struct _EFI_SPI_HC_PROTOCOL {
/// Host control attributes, may have zero or more of the following set:
/// * HC_SUPPORTS_WRITE_ONLY_OPERATIONS
/// * HC_SUPPORTS_READ_ONLY_OPERATIONS
- /// * HC_SUPPORTS_WRITE_THEN_READ_OPERATIONS
/// * HC_TX_FRAME_IN_MOST_SIGNIFICANT_BITS
/// - The SPI host controller requires the transmit frame to be in most
/// significant bits instead of least significant bits.The host driver
@@ -149,10 +152,6 @@ struct _EFI_SPI_HC_PROTOCOL {
/// - The SPI controller supports a 2 - bit data bus
/// * HC_SUPPORTS_4_B1T_DATA_BUS_WIDTH
/// - The SPI controller supports a 4 - bit data bus
- /// * HC_TRANSFER_SIZE_INCLUDES_OPCODE
- /// - Transfer size includes the opcode byte
- /// * HC_TRANSFER_SIZE_INCLUDES_ADDRESS
- /// - Transfer size includes the 3 address bytes
/// The SPI host controller must support full - duplex (receive while
/// sending) operation.The SPI host controller must support a 1 - bit bus
/// width.
diff --git a/MdePkg/Include/Protocol/SpiIo.h b/MdePkg/Include/Protocol/SpiIo.h
index 43e8045..507abb5 100644
--- a/MdePkg/Include/Protocol/SpiIo.h
+++ b/MdePkg/Include/Protocol/SpiIo.h
@@ -27,147 +27,33 @@ typedef struct _EFI_SPI_IO_PROTOCOL EFI_SPI_IO_PROTOCOL;
/// Note: The UEFI PI 1.6 specification does not specify values for the
/// members below. The order matches the specification.
///
+///
+/// SPI peripheral transfer type
+///
+/// The EFI_SPI_TRANSACTION_TYPE describes the type of SPI transaction to
either
+/// send or recievce from SPI peripheral.
+/// some SPI controllers need this information to complete a SPI operation
+/// (which consists of one or many transactions)
+///
+/// for other controllers this field may be left 0 (SPI_TRANSACTION_NONE)
+///
typedef enum {
- ///
- /// Data flowing in both direction between the host and
- /// SPI peripheral.ReadBytes must equal WriteBytes and both ReadBuffer and
- /// WriteBuffer must be provided.
- ///
- SPI_TRANSACTION_FULL_DUPLEX,
-
- ///
- /// Data flowing from the host to the SPI peripheral.ReadBytes must be
- /// zero.WriteBytes must be non - zero and WriteBuffer must be provided.
- ///
- SPI_TRANSACTION_WRITE_ONLY,
-
- ///
- /// Data flowing from the SPI peripheral to the host.WriteBytes must be
- /// zero.ReadBytes must be non - zero and ReadBuffer must be provided.
- ///
- SPI_TRANSACTION_READ_ONLY,
-
-
Re: [edk2] [Patch] SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix duplicate symbol
On 7 December 2017 at 07:48, Liming Gao wrote:
> From: Michael Kinney
>
> https://bugzilla.tianocore.org/show_bug.cgi?id=573
> https://bugzilla.tianocore.org/show_bug.cgi?id=796
>
> The same issue is reported again by GCC. Resend this patch again.
> This patch renames the duplicated function name to fix it.
>
> The SecPeiDebugAgentLib uses the global variable
> mMemoryDiscoveredNotifyList for a PPI notification on
> the Memory Discovered PPI. This same variable name is
> used in the DxeIplPeim for the same PPI notification.
>
> The XCODE5 tool chain detects this duplicate symbol
> when the OVMF platform is built with the flag
> -D SOURCE_DEBUG_ENABLE.
>
> The fix is to rename this global variable in the
> SecPeiDebugAgentLib library.
>
No, the fix is to make it STATIC unless it *needs* to be a global.
Is that the case here?
> Cc: Andrew Fish
> Cc: Jeff Fan
> Cc: Hao Wu
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael D Kinney
> Reviewed-by: Jeff Fan
> ---
> .../Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c | 4
> ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>
> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
> index b717e33..9f5223a 100644
> ---
> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
> +++
> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
> @@ -32,7 +32,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_PPI_DESCRIPTOR
>mVectorHandoffInf
>}
> };
>
> -GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR
> mMemoryDiscoveredNotifyList[1] = {
> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR
> mDebugAgentMemoryDiscoveredNotifyList[1] = {
>{
> (EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK |
> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
> &gEfiPeiMemoryDiscoveredPpiGuid,
> @@ -554,7 +554,7 @@ InitializeDebugAgent (
> // Register for a callback once memory has been initialized.
> // If memery has been ready, the callback funtion will be invoked
> immediately
> //
> -Status = PeiServicesNotifyPpi (&mMemoryDiscoveredNotifyList[0]);
> +Status = PeiServicesNotifyPpi
> (&mDebugAgentMemoryDiscoveredNotifyList[0]);
> if (EFI_ERROR (Status)) {
>DEBUG ((EFI_D_ERROR, "DebugAgent: Failed to register memory discovered
> callback function!\n"));
>CpuDeadLoop ();
> --
> 2.6.3.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> GitPatchExtractor 1.1
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 0/3] BaseTools/tools_def: GCC5/CLANG38 toolchain updates
Some toolchain updates for CLANG38 and GCC5: - introduce CLANG38+LTO for ARM and AARCH64 - disable a warning on CLANG38 - enable optimization for GCC5 DEBUG builds Ard Biesheuvel (3): BaseTools/tools_def: add CLANG38 LTO versions for AARCH64 and ARM BaseTools/tools_def CLANG38: add -Wno-unused-const-variable BaseTool/tools_def GCC5: enable optimization for ARM/AARCH64 DEBUG builds BaseTools/Conf/tools_def.template | 106 ++-- 1 file changed, 99 insertions(+), 7 deletions(-) -- 2.11.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 3/3] BaseTool/tools_def GCC5: enable optimization for ARM/AARCH64 DEBUG builds
Enable optimization for DEBUG builds, to make it more usable in terms of performance, and to give more coverage to the LTO builds. Also, some diagnostics are only enabled when optimization is enabled. NOOPT builds can now also be created, which will retain the behavior DEBUG builds had previously. Note that this aligns ARM and AARCH64 with the x86 architectures, which already use optimization for DEBUG builds. In order to preserve existing behavior for users of older toolchains, keep GCC49 and older as-is. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel --- v2: new patch BaseTools/Conf/tools_def.template | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 703884fc49a7..aec390f8eeb1 100755 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -5517,8 +5517,8 @@ RELEASE_GCC5_X64_DLINK_FLAGS = DEF(GCC5_X64_DLINK_FLAGS) -flto -Os *_GCC5_ARM_VFRPP_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_VFRPP_FLAGS) *_GCC5_ARM_CC_XIPFLAGS = DEF(GCC5_ARM_CC_XIPFLAGS) - DEBUG_GCC5_ARM_CC_FLAGS= DEF(GCC5_ARM_CC_FLAGS) -O0 - DEBUG_GCC5_ARM_DLINK_FLAGS = DEF(GCC5_ARM_DLINK_FLAGS) + DEBUG_GCC5_ARM_CC_FLAGS= DEF(GCC5_ARM_CC_FLAGS) -flto -Wno-unused-but-set-variable -Wno-unused-const-variable + DEBUG_GCC5_ARM_DLINK_FLAGS = DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-arm -Wl,-plugin-opt=-pass-through=-llto-arm RELEASE_GCC5_ARM_CC_FLAGS= DEF(GCC5_ARM_CC_FLAGS) -flto -Wno-unused-but-set-variable -Wno-unused-const-variable RELEASE_GCC5_ARM_DLINK_FLAGS = DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-arm -Wl,-plugin-opt=-pass-through=-llto-arm @@ -5551,8 +5551,8 @@ RELEASE_GCC5_ARM_DLINK_FLAGS = DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os -L$(WORKS *_GCC5_AARCH64_VFRPP_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_VFRPP_FLAGS) *_GCC5_AARCH64_CC_XIPFLAGS = DEF(GCC5_AARCH64_CC_XIPFLAGS) - DEBUG_GCC5_AARCH64_CC_FLAGS= DEF(GCC5_AARCH64_CC_FLAGS) -O0 -mcmodel=small - DEBUG_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -z common-page-size=0x1000 + DEBUG_GCC5_AARCH64_CC_FLAGS= DEF(GCC5_AARCH64_CC_FLAGS) -flto -Wno-unused-but-set-variable -Wno-unused-const-variable -mcmodel=small + DEBUG_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -z common-page-size=0x1000 -flto -Os -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-aarch64 -Wl,-plugin-opt=-pass-through=-llto-aarch64 -Wno-lto-type-mismatch -mcmodel=small DEBUG_GCC5_AARCH64_DLINK_XIPFLAGS = -z common-page-size=0x20 RELEASE_GCC5_AARCH64_CC_FLAGS= DEF(GCC5_AARCH64_CC_FLAGS) -flto -Wno-unused-but-set-variable -Wno-unused-const-variable -mcmodel=tiny -- 2.11.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 2/3] BaseTools/tools_def CLANG38: add -Wno-unused-const-variable
Commit 8b6366f87584 ("BaseTools/GCC: set -Wno-unused-const-variable
on RELEASE builds") suppresses warnings about unused constant
variables in RELEASE builds when building with GCC, given that they
break the build under our warnings-as-errors policy.
Do the same for CLANG38.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=790
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
v2: new patch
BaseTools/Conf/tools_def.template | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/BaseTools/Conf/tools_def.template
b/BaseTools/Conf/tools_def.template
index c0189d4c8d30..703884fc49a7 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -5664,7 +5664,7 @@ DEFINE CLANG38_X64_PREFIX = ENV(CLANG38_BIN)
DEFINE CLANG38_IA32_TARGET = -target i686-pc-linux-gnu
DEFINE CLANG38_X64_TARGET = -target x86_64-pc-linux-gnu
-DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality
-Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare
-Wno-empty-body -Wno-varargs
+DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality
-Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare
-Wno-empty-body -Wno-unused-const-variable -Wno-varargs
DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS)
DEF(CLANG38_WARNING_OVERRIDES) -fno-stack-protector -mms-bitfields -Wno-address
-Wno-shift-negative-value -Wno-unknown-pragmas
-Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables
-mno-sse -mno-mmx -msoft-float -mno-implicit-float
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang
-funsigned-char -fno-ms-extensions -Wno-null-dereference
-Wno-unknown-warning-option
###
--
2.11.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 1/3] BaseTools/tools_def: add CLANG38 LTO versions for AARCH64 and ARM
Extend the CLANG38 toolchain definition so it can be used for ARM and AARCH64 as well. Note that this requires llvm-ar and the LLVMgold.so linker plugin. In preparation of doing the same for GCC5, this toolchain version also departs from the custom of using -O0 for DEBUG builds, which makes them needlessly slow. Instead, let's add a NOOPT flavor as well, and enable optimization for DEBUG like the other architectures do. (Note that this will require some trivial changes to the platform description files) Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel Acked-by: Laszlo Ersek --- v2: add missing -flto to CC flags, without that LTO is not actually enabled (which is why I did not take Leif's Tested-by) add -fno-lto to ASLC CC flags BaseTools/Conf/tools_def.template | 98 +++- 1 file changed, 95 insertions(+), 3 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 91b135c2e569..c0189d4c8d30 100755 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -399,8 +399,8 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc # Intel(r) ACPI Compiler from # https://acpica.org/downloads # CLANG38 -Linux- Requires: -# Clang v3.8, LLVMgold plugin and GNU binutils 2.26 targeting x86_64-linux-gnu -# Clang v3.9 or later, LLVMgold plugin and GNU binutils 2.28 targeting x86_64-linux-gnu +# Clang v3.8, LLVMgold plugin and GNU binutils 2.26 targeting x86_64-linux-gnu, aarch64-linux-gnu or arm-linux-gnueabi +# Clang v3.9 or later, LLVMgold plugin and GNU binutils 2.28 targeting x86_64-linux-gnu, aarch64-linux-gnu or arm-linux-gnueabi #Optional: # Required to build platforms or ACPI tables: # Intel(r) ACPI Compiler from @@ -5652,6 +5652,7 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS) *_CLANG38_*_MAKE_PATH = make *_CLANG38_*_*_DLL = ENV(CLANG38_DLL) *_CLANG38_*_ASL_PATH= DEF(UNIX_IASL_BIN) +*_CLANG38_*_DTC_PATH= DEF(DTC_BIN) *_CLANG38_*_APP_FLAGS = *_CLANG38_*_ASL_FLAGS = DEF(IASL_FLAGS) @@ -5663,7 +5664,8 @@ DEFINE CLANG38_X64_PREFIX = ENV(CLANG38_BIN) DEFINE CLANG38_IA32_TARGET = -target i686-pc-linux-gnu DEFINE CLANG38_X64_TARGET = -target x86_64-pc-linux-gnu -DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -Wno-empty-body -fno-stack-protector -mms-bitfields -Wno-address -Wno-shift-negative-value -Wno-parentheses-equality -Wno-unknown-pragmas -Wno-tautological-constant-out-of-range-compare -Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -msoft-float -mno-implicit-float -ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -funsigned-char -fno-ms-extensions -Wno-null-dereference -Wno-tautological-compare -Wno-unknown-warning-option -Wno-varargs +DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality -Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare -Wno-empty-body -Wno-varargs +DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) DEF(CLANG38_WARNING_OVERRIDES) -fno-stack-protector -mms-bitfields -Wno-address -Wno-shift-negative-value -Wno-unknown-pragmas -Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -msoft-float -mno-implicit-float -ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -funsigned-char -fno-ms-extensions -Wno-null-dereference -Wno-unknown-warning-option ### # CLANG38 IA32 definitions @@ -5739,6 +5741,96 @@ NOOPT_CLANG38_X64_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m64 "-DEFIAPI=__ NOOPT_CLANG38_X64_DLINK_FLAGS = DEF(GCC5_IA32_X64_DLINK_FLAGS) -Wl,-O0 -Wl,-melf_x86_64 -Wl,--oformat=elf64-x86-64 -Wl,-pie -mcmodel=small NOOPT_CLANG38_X64_DLINK2_FLAGS = DEF(GCC5_X64_DLINK2_FLAGS) -O0 +## +# CLANG38 ARM definitions +## +DEFINE CLANG38_ARM_TARGET= -target arm-linux-gnueabihf +DEFINE CLANG38_ARM_CC_FLAGS = DEF(GCC_ARM_CC_FLAGS) DEF(CLANG38_ARM_TARGET) DEF(CLANG38_WARNING_OVERRIDES) -mno-movt +DEFINE CLANG38_ARM_DLINK_FLAGS = DEF(CLANG38_ARM_TARGET) DEF(GCC_ARM_DLINK_FLAGS) + +*_CLANG38_ARM_PP_FLAGS = DEF(GCC_PP_FLAGS) +*_CLANG38_ARM_ASLCC_FLAGS= DEF(GCC_ASLCC_FLAGS) +*_CLANG38_ARM_APP_FLAGS = +*_CLANG38_ARM_ASL_FLAGS = DEF(IASL_FLAGS) +*_CLANG38_ARM_ASL_OUTFLAGS = DEF(IASL_OUTFLAGS) +*_CLANG38_ARM_DTCPP_FLAGS= DEF(GCC_DTCPP_FLAGS) + +*_CLANG38_ARM_CC_PATH= ENV(CLANG38_BIN)clang +*_CLANG38_ARM_ASM_PATH
[edk2] [Patch] MdeModulePkg/NetLib: Fix an error when AIP doesn't support network media state detection
AIP may not support detecting network media state, in this case,
should call NetLibDetectMedia to get media state. This patch is to
fix this issue.
Cc: Fu Siyuan
Cc: Ye Ting
Cc: Jiaxin Wu
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wang Fan
---
MdeModulePkg/Library/DxeNetLib/DxeNetLib.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
index 1bfa33d..d75cca2 100644
--- a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
+++ b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
@@ -2603,10 +2603,28 @@ NetLibDetectMediaWaitTimeout (
} else {
if (MediaInfo != NULL) {
FreePool (MediaInfo);
}
+
+if (Status == EFI_UNSUPPORTED) {
+
+ //
+ // If gEfiAdapterInfoMediaStateGuid is not supported, call
NetLibDetectMedia to get media state!
+ //
+ MediaPresent = TRUE;
+ Status = NetLibDetectMedia (ServiceHandle, &MediaPresent);
+ if (!EFI_ERROR (Status)) {
+if (MediaPresent == TRUE) {
+ *MediaState = EFI_SUCCESS;
+} else {
+ *MediaState = EFI_NO_MEDIA;
+}
+ }
+ return Status;
+}
+
return Status;
}
//
// Loop to check media state
--
1.9.5.msysgit.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] MdeModulePkg/ScsiDisk: Return EFI_NO_MEDIA when no media presents
Current code always return EFI_MEDIA_CHANGED no matter the media
is removed from CD/DVD drive or the media is changed.
It doesn't strictly follow the UEFI Spec.
Update code to return EFI_NO_MEDIA when media is removed.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni
Cc: Star Zeng
Cc: Hao A Wu
---
MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c | 41
1 file changed, 30 insertions(+), 11 deletions(-)
diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
index 2289f20152..6a0a193556 100644
--- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
+++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
@@ -568,6 +568,7 @@ ScsiDiskReadBlocks (
MediaChange= FALSE;
OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
ScsiDiskDevice = SCSI_DISK_DEV_FROM_BLKIO (This);
+ Media = ScsiDiskDevice->BlkIo.Media;
if (!IS_DEVICE_FIXED(ScsiDiskDevice)) {
@@ -598,14 +599,17 @@ ScsiDiskReadBlocks (
&ScsiDiskDevice->EraseBlock
);
}
- Status = EFI_MEDIA_CHANGED;
+ if (Media->MediaPresent) {
+Status = EFI_MEDIA_CHANGED;
+ } else {
+Status = EFI_NO_MEDIA;
+ }
goto Done;
}
}
//
// Get the intrinsic block size
//
- Media = ScsiDiskDevice->BlkIo.Media;
BlockSize = Media->BlockSize;
NumberOfBlocks = BufferSize / BlockSize;
@@ -700,6 +704,7 @@ ScsiDiskWriteBlocks (
MediaChange= FALSE;
OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
ScsiDiskDevice = SCSI_DISK_DEV_FROM_BLKIO (This);
+ Media = ScsiDiskDevice->BlkIo.Media;
if (!IS_DEVICE_FIXED(ScsiDiskDevice)) {
@@ -730,14 +735,17 @@ ScsiDiskWriteBlocks (
&ScsiDiskDevice->EraseBlock
);
}
- Status = EFI_MEDIA_CHANGED;
+ if (Media->MediaPresent) {
+Status = EFI_MEDIA_CHANGED;
+ } else {
+Status = EFI_NO_MEDIA;
+ }
goto Done;
}
}
//
// Get the intrinsic block size
//
- Media = ScsiDiskDevice->BlkIo.Media;
BlockSize = Media->BlockSize;
NumberOfBlocks = BufferSize / BlockSize;
@@ -922,6 +930,7 @@ ScsiDiskReadBlocksEx (
MediaChange= FALSE;
OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
ScsiDiskDevice = SCSI_DISK_DEV_FROM_BLKIO2 (This);
+ Media = ScsiDiskDevice->BlkIo.Media;
if (!IS_DEVICE_FIXED(ScsiDiskDevice)) {
@@ -952,14 +961,17 @@ ScsiDiskReadBlocksEx (
&ScsiDiskDevice->EraseBlock
);
}
- Status = EFI_MEDIA_CHANGED;
+ if (Media->MediaPresent) {
+Status = EFI_MEDIA_CHANGED;
+ } else {
+Status = EFI_NO_MEDIA;
+ }
goto Done;
}
}
//
// Get the intrinsic block size
//
- Media = ScsiDiskDevice->BlkIo2.Media;
BlockSize = Media->BlockSize;
NumberOfBlocks = BufferSize / BlockSize;
@@ -1081,6 +1093,7 @@ ScsiDiskWriteBlocksEx (
MediaChange= FALSE;
OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
ScsiDiskDevice = SCSI_DISK_DEV_FROM_BLKIO2 (This);
+ Media = ScsiDiskDevice->BlkIo.Media;
if (!IS_DEVICE_FIXED(ScsiDiskDevice)) {
@@ -,14 +1124,17 @@ ScsiDiskWriteBlocksEx (
&ScsiDiskDevice->EraseBlock
);
}
- Status = EFI_MEDIA_CHANGED;
+ if (Media->MediaPresent) {
+Status = EFI_MEDIA_CHANGED;
+ } else {
+Status = EFI_NO_MEDIA;
+ }
goto Done;
}
}
//
// Get the intrinsic block size
//
- Media = ScsiDiskDevice->BlkIo2.Media;
BlockSize = Media->BlockSize;
NumberOfBlocks = BufferSize / BlockSize;
@@ -1230,6 +1246,7 @@ ScsiDiskFlushBlocksEx (
MediaChange= FALSE;
OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
ScsiDiskDevice = SCSI_DISK_DEV_FROM_BLKIO2 (This);
+ Media = ScsiDiskDevice->BlkIo.Media;
if (!IS_DEVICE_FIXED(ScsiDiskDevice)) {
@@ -1260,13 +1277,15 @@ ScsiDiskFlushBlocksEx (
&ScsiDiskDevice->EraseBlock
);
}
- Status = EFI_MEDIA_CHANGED;
+ if (Media->MediaPresent) {
+Status = EFI_MEDIA_CHANGED;
+ } else {
+Status = EFI_NO_MEDIA;
+ }
goto Done;
}
}
- Media = ScsiDiskDevice->BlkIo2.Media;
-
if (!(Media->MediaPresent)) {
Status = EFI_NO_MEDIA;
goto Done;
--
2.15.0.gvfs.1.preview.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch 4/4 V3] BaseTools: Update Makefile to support FFS file generation
Hi Leif, Please help to check whether this patch " [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file" can fix it. thanks a lot. Best Regards, Zhu Yonghong -Original Message- From: Zhu, Yonghong Sent: Thursday, December 07, 2017 9:00 AM To: Leif Lindholm Cc: edk2-devel@lists.01.org; Feng, YunhuaX ; Gao, Liming ; Zhu, Yonghong Subject: RE: [edk2] [Patch 4/4 V3] BaseTools: Update Makefile to support FFS file generation Thanks Leif. I will provide patch to fix it soon. Best Regards, Zhu Yonghong -Original Message- From: Leif Lindholm [mailto:leif.lindh...@linaro.org] Sent: Thursday, December 07, 2017 2:24 AM To: Zhu, Yonghong Cc: edk2-devel@lists.01.org; Feng, YunhuaX ; Gao, Liming Subject: Re: [edk2] [Patch 4/4 V3] BaseTools: Update Makefile to support FFS file generation Hi Yonghong, I'm afraid I have come across an issue with this one as well: When trying to build OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b into a platform (edk2-platforms/Platform/Hisilicon/HiKey/), GenSec fails with: Generating FVMAIN FV Return Value = 2 GenSec: ERROR 0001: Error opening file /work/git/tianocore/Build/HiKey/RELEASE_GCC5/AARCH64/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772b/OUTPUT/Ax88772b.depex GenSec: ERROR 2000: Status is not successful If I revert commit 37de70b7, the platform builds successfully again. D03 and D05 platforms also appear to have issues with this, but in that case due to drivers in edk2-non-osi. / Leif On Wed, Nov 29, 2017 at 10:02:06PM +0800, Yonghong Zhu wrote: > Update Makefile to support FFS file generation with new build option > --genfds-multi-thread. > > Cc: Liming Gao > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Yonghong Zhu > Signed-off-by: Yunhua Feng > --- > BaseTools/Source/Python/AutoGen/AutoGen.py | 23 ++- > BaseTools/Source/Python/AutoGen/GenMake.py | 90 - > BaseTools/Source/Python/Common/GlobalData.py | 1 + > BaseTools/Source/Python/GenFds/AprioriSection.py | 14 +- > BaseTools/Source/Python/GenFds/CompressSection.py | 10 +- > BaseTools/Source/Python/GenFds/DataSection.py | 37 ++-- > BaseTools/Source/Python/GenFds/DepexSection.py | 6 +- > BaseTools/Source/Python/GenFds/EfiSection.py | 78 +--- > BaseTools/Source/Python/GenFds/Fd.py | 24 ++- > BaseTools/Source/Python/GenFds/FfsFileStatement.py | 4 +- > BaseTools/Source/Python/GenFds/FfsInfStatement.py | 202 > - > BaseTools/Source/Python/GenFds/Fv.py | 189 ++- > BaseTools/Source/Python/GenFds/FvImageSection.py | 8 +- > BaseTools/Source/Python/GenFds/GenFds.py | 20 ++ > .../Source/Python/GenFds/GenFdsGlobalVariable.py | 174 ++ > BaseTools/Source/Python/GenFds/GuidSection.py | 168 + > .../Source/Python/GenFds/OptRomFileStatement.py| 4 +- > .../Source/Python/GenFds/OptRomInfStatement.py | 12 +- > BaseTools/Source/Python/GenFds/OptionRom.py| 25 +-- > BaseTools/Source/Python/GenFds/Region.py | 49 +++-- > BaseTools/Source/Python/GenFds/Section.py | 4 +- > BaseTools/Source/Python/GenFds/UiSection.py| 5 +- > BaseTools/Source/Python/GenFds/VerSection.py | 9 +- > BaseTools/Source/Python/build/build.py | 48 - > 24 files changed, 793 insertions(+), 411 deletions(-) ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] MdeModulePkg/UefiPxeBcDxe: Question about IcmpErrorListenHandler in PxeBcImpl.c
> You say "IcmpErrorRcvToken is only used to get ICMP error from IP
> layer", does that mean only ICMP error packets will go to
> IcmpErrorListenHandler?
> If it is the case, how do we make it? I can only find a simple
> Ip4->Receive is called to receive IP4 packets; how are other types of
> IP4 packets filtered out?
No, all of the *ICMP* packets with the same station IP address will go to
IcmpErrorListenHandler() callback function. Because PXE driver has already
configured the current IP protocol only receive the ICMP packets:
ZeroMem (&Private->Ip4ConfigData, sizeof (EFI_IP4_CONFIG_DATA));
Private->Ip4ConfigData.DefaultProtocol = EFI_IP_PROTO_ICMP;
Private->Ip4ConfigData.AcceptIcmpErrors = TRUE;
Ip4ConfigData.DefaultProtocol = EFI_IP_PROTO_ICMP;
So, it is only used to capture background ICMP packets (Including the ICMP
error message) with the same station IP address.
> If it is not, why don't we need to filter the packets in
> IcmpErrorListenHandler? If we recycle the packets in
> IcmpErrorListenHandler, will it cause the upper layer of protocols fail
> to fetch RxData?
IcmpErrorListenHandler() should filter the packets and only handle the ICMP
error message. But currently, the code logic is incorrect. I generated one
patch as attached one for your reference, can you help to verify whether it
works or not? (Ignore my previous suggestion check).
In my opinion, the RxData should be recycled since it has been recorded in
Mode->IcmpError.
Thanks,
Jiaxin
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Heyi Guo
> Sent: Thursday, December 7, 2017 4:18 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Fu, Siyuan ; Dong,
> Eric ; Zeng, Star
> Subject: Re: [edk2] MdeModulePkg/UefiPxeBcDxe: Question about
> IcmpErrorListenHandler in PxeBcImpl.c
>
> Hi Jiaxin,
>
> Thanks for your reply.
>
> You say "IcmpErrorRcvToken is only used to get ICMP error from IP
> layer", does that mean only ICMP error packets will go to
> IcmpErrorListenHandler?
>
> If it is the case, how do we make it? I can only find a simple
> Ip4->Receive is called to receive IP4 packets; how are other types of
> IP4 packets filtered out?
>
> If it is not, why don't we need to filter the packets in
> IcmpErrorListenHandler? If we recycle the packets in
> IcmpErrorListenHandler, will it cause the upper layer of protocols fail
> to fetch RxData?
>
> Please forgive me if my questions are too stupid :)
>
> Regards,
>
> Gary (Heyi Guo)
>
>
> 在 12/7/2017 3:48 PM, Wu, Jiaxin 写道:
> > Hi Gary,
> >
> > IcmpErrorRcvToken is only used to get ICMP error from IP layer, and the
> data will be copied to Mode->IcmpError. So, I think the RxData should be
> recycled.
> >
> > Besides, EFI_IP_PROTO_ICMP should be also checked in the call function
> but currently it's not:
> >
> >if (!EFI_IP4_EQUAL (&RxData->Header->DestinationAddress, &Mode-
> >StationIp.v4)) {
> > //
> > // The dest address is not equal to Station Ip address, discard it.
> > //
> > goto CleanUp;
> >}
> >
> >+if (&RxData->Header->Protocol != EFI_IP_PROTO_ICMP) {
> >+//
> >+// The protocol value in the header of the receveid packet should be
> EFI_IP_PROTO_ICMP.
> >+//
> >+goto CleanUp;
> >+}
> >
> > Thanks the report.
> >
> > Thanks,
> > Jiaxin
> >
> >
> >
> >> -Original Message-
> >> From: Guo Heyi [mailto:heyi@linaro.org]
> >> Sent: Thursday, December 7, 2017 12:07 PM
> >> To: edk2-devel@lists.01.org
> >> Cc: Zeng, Star ; Dong, Eric ;
> Ni,
> >> Ruiyu ; Fu, Siyuan ; Wu, Jiaxin
> >>
> >> Subject: MdeModulePkg/UefiPxeBcDxe: Question about
> >> IcmpErrorListenHandler in PxeBcImpl.c
> >>
> >> Hi folks,
> >>
> >> In PxeBcImpl.c, we have IcmpErrorListenHandler which seems to process
> >> ICMP errors. But in EfiPxeBcStart function, we can see Private-
> >>> IcmpErrorRcvToken.Event is only a common event and Ip4->Receive is
> >> called to receive IP4 packets. So will IcmpErrorListenHandler receive all
> >> IP4
> >> packets belonging to this network interface, or will it only receive ICMP
> error
> >> packets? If it is the latter situation, how do we make it?
> >>
> >> The background of this question is that when we flush the network with
> >> deprecated ICMP packets (type 15, 16, ...), RxData will not be recycled and
> >> the list of UEFI events becomes longer and longer, which finally impacts
> >> system performance a lot. If only error ICMP will be received by
> >> IcmpErrorListenHandler, we'd like to patch it as below:
> >>
> >> diff --git
> a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
> >> b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
> >> index 6d4f33f..f74b264 100644
> >> --- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
> >> +++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
> >> @@ -216,8 +216,6 @@ IcmpErrorListenHandlerDpc (
> >> CopiedPointer +=
Re: [edk2] [Patch] MdeModulePkg/NetLib: Fix an error when AIP doesn't support network media state detection
Reviewed-by: Jiaxin Wu
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> fanwang2
> Sent: Thursday, December 7, 2017 5:51 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wang, Fan ; Fu,
> Siyuan ; Wu, Jiaxin
> Subject: [edk2] [Patch] MdeModulePkg/NetLib: Fix an error when AIP
> doesn't support network media state detection
>
> AIP may not support detecting network media state, in this case,
> should call NetLibDetectMedia to get media state. This patch is to
> fix this issue.
>
> Cc: Fu Siyuan
> Cc: Ye Ting
> Cc: Jiaxin Wu
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wang Fan
> ---
> MdeModulePkg/Library/DxeNetLib/DxeNetLib.c | 18
> ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> index 1bfa33d..d75cca2 100644
> --- a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> +++ b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> @@ -2603,10 +2603,28 @@ NetLibDetectMediaWaitTimeout (
>} else {
>
> if (MediaInfo != NULL) {
>FreePool (MediaInfo);
> }
> +
> +if (Status == EFI_UNSUPPORTED) {
> +
> + //
> + // If gEfiAdapterInfoMediaStateGuid is not supported, call
> NetLibDetectMedia to get media state!
> + //
> + MediaPresent = TRUE;
> + Status = NetLibDetectMedia (ServiceHandle, &MediaPresent);
> + if (!EFI_ERROR (Status)) {
> +if (MediaPresent == TRUE) {
> + *MediaState = EFI_SUCCESS;
> +} else {
> + *MediaState = EFI_NO_MEDIA;
> +}
> + }
> + return Status;
> +}
> +
> return Status;
>}
>
>//
>// Loop to check media state
> --
> 1.9.5.msysgit.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] UefiCpuPkg PiSmmCpuDxeSmm: SMM profile and static paging mutual exclusion
SMM profile and static paging could not enabled at the same time,
this patch is add check and comments to make sure it.
Similar comments are also added for the case of static paging and
heap guard for SMM.
Cc: Jiewen Yao
Cc: Eric Dong
Cc: Ruiyu Ni
Cc: Jian J Wang
Cc: Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng
---
UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 9 +
UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c | 13 ++---
UefiCpuPkg/UefiCpuPkg.dec| 6 +-
UefiCpuPkg/UefiCpuPkg.uni| 10 --
4 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
index 6e1ffe7c6287..939ac25a506c 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
@@ -205,6 +205,15 @@ SetPageTableAttributes (
// BIT3: SMM pool guard enabled
//
if ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
+DEBUG ((DEBUG_INFO, "Don't mark page table as read-only as heap guard is
enabled\n"));
+return ;
+ }
+
+ //
+ // Don't mark page table as read-only if SMM profile is enabled.
+ //
+ if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
+DEBUG ((DEBUG_INFO, "Don't mark page table as read-only as SMM profile is
enabled\n"));
return ;
}
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
index 6478c6c3e355..0fe944fc18cc 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
@@ -919,17 +919,24 @@ SetPageTableAttributes (
//
// Don't do this if
// - no static page table; or
- // - SMM heap guard feature enabled
+ // - SMM heap guard feature enabled; or
// BIT2: SMM page guard enabled
// BIT3: SMM pool guard enabled
+ // - SMM profile feature enabled
//
if (!mCpuSmmStaticPageTable ||
- (PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
+ ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) ||
+ FeaturePcdGet (PcdCpuSmmProfileEnable)) {
//
-// Static paging and heap guard should not be enabled at the same time.
+// Static paging and heap guard could not be enabled at the same time.
//
ASSERT (!(mCpuSmmStaticPageTable &&
(PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0));
+
+//
+// Static paging and SMM profile could not be enabled at the same time.
+//
+ASSERT (!(mCpuSmmStaticPageTable && FeaturePcdGet
(PcdCpuSmmProfileEnable)));
return ;
}
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index d2965ba14c2d..36205ab63796 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -84,6 +84,7 @@ [Protocols]
[PcdsFeatureFlag]
## Indicates if SMM Profile will be enabled.
# If enabled, instruction executions in and data accesses to memory outside
of SMRAM will be logged.
+ # It could not be enabled at the same time with SMM profile feature
(PcdCpuSmmStaticPageTable).
# This PCD is only for validation purpose. It should be set to false in
production.
# TRUE - SMM Profile will be enabled.
# FALSE - SMM Profile will be disabled.
@@ -225,8 +226,11 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic,
PcdsDynamicEx]
gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate|0|UINT8|0x0007
## Indicates if SMM uses static page table.
- # If enabled, SMM will not use on-demand paging. SMM will build static page
table for all memory.
+ # If enabled, SMM will not use on-demand paging. SMM will build static page
table for all memory.
# This flag only impacts X64 build, because SMM alway builds static page
table for IA32.
+ # It could not be enabled at the same time with SMM profile feature
(PcdCpuSmmProfileEnable).
+ # It could not be enabled also at the same time with heap guard feature for
SMM
+ # (PcdHeapGuardPropertyMask in MdeModulePkg).
# TRUE - SMM uses static page table for all memory.
# FALSE - SMM uses static page table for below 4G memory and use on-demand
paging for above 4G memory.
# @Prompt Use static page table for all memory in SMM.
diff --git a/UefiCpuPkg/UefiCpuPkg.uni b/UefiCpuPkg/UefiCpuPkg.uni
index 9472b185e46e..013d2870a682 100644
--- a/UefiCpuPkg/UefiCpuPkg.uni
+++ b/UefiCpuPkg/UefiCpuPkg.uni
@@ -53,7 +53,10 @@
#string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuSmmProfileEnable_PROMPT #language
en-US "Enable SMM Profile"
-#string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuSmmProfileEnable_HELP #language
en-US "Indicates if SMM Profile will be enabled. If enabled, instruction
executions in and data accesses to memory outside of SMRAM will be logged. This
PCD is only for validation purpose. It should be set to false in
production.\n"
+#string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuSmmProfileEnable_HELP #language
en-US "Indicates if SMM
Re: [edk2] [PATCH] UefiCpuPkg PiSmmCpuDxeSmm: SMM profile and static paging mutual exclusion
Star,
Reviewed-by: Eric Dong
Below typo you can change when you push the code.
+ # It could not be enabled at the same time with SMM profile feature
(PcdCpuSmmStaticPageTable).
" SMM profile feature " should be "Static page table feature"?
Thanks,
Eric
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng
Sent: Thursday, December 7, 2017 6:48 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu; Dong, Eric; Yao, Jiewen; Laszlo Ersek; Zeng, Star
Subject: [edk2] [PATCH] UefiCpuPkg PiSmmCpuDxeSmm: SMM profile and static
paging mutual exclusion
SMM profile and static paging could not enabled at the same time, this patch is
add check and comments to make sure it.
Similar comments are also added for the case of static paging and heap guard
for SMM.
Cc: Jiewen Yao
Cc: Eric Dong
Cc: Ruiyu Ni
Cc: Jian J Wang
Cc: Laszlo Ersek
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng
---
UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 9 +
UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c | 13 ++---
UefiCpuPkg/UefiCpuPkg.dec| 6 +-
UefiCpuPkg/UefiCpuPkg.uni| 10 --
4 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
index 6e1ffe7c6287..939ac25a506c 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
@@ -205,6 +205,15 @@ SetPageTableAttributes (
// BIT3: SMM pool guard enabled
//
if ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
+DEBUG ((DEBUG_INFO, "Don't mark page table as read-only as heap guard is
enabled\n"));
+return ;
+ }
+
+ //
+ // Don't mark page table as read-only if SMM profile is enabled.
+ //
+ if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
+DEBUG ((DEBUG_INFO, "Don't mark page table as read-only as SMM
+ profile is enabled\n"));
return ;
}
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
index 6478c6c3e355..0fe944fc18cc 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
@@ -919,17 +919,24 @@ SetPageTableAttributes (
//
// Don't do this if
// - no static page table; or
- // - SMM heap guard feature enabled
+ // - SMM heap guard feature enabled; or
// BIT2: SMM page guard enabled
// BIT3: SMM pool guard enabled
+ // - SMM profile feature enabled
//
if (!mCpuSmmStaticPageTable ||
- (PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
+ ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) ||
+ FeaturePcdGet (PcdCpuSmmProfileEnable)) {
//
-// Static paging and heap guard should not be enabled at the same time.
+// Static paging and heap guard could not be enabled at the same time.
//
ASSERT (!(mCpuSmmStaticPageTable &&
(PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0));
+
+//
+// Static paging and SMM profile could not be enabled at the same time.
+//
+ASSERT (!(mCpuSmmStaticPageTable && FeaturePcdGet
+ (PcdCpuSmmProfileEnable)));
return ;
}
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec index
d2965ba14c2d..36205ab63796 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -84,6 +84,7 @@ [Protocols]
[PcdsFeatureFlag]
## Indicates if SMM Profile will be enabled.
# If enabled, instruction executions in and data accesses to memory outside
of SMRAM will be logged.
+ # It could not be enabled at the same time with SMM profile feature
(PcdCpuSmmStaticPageTable).
# This PCD is only for validation purpose. It should be set to false in
production.
# TRUE - SMM Profile will be enabled.
# FALSE - SMM Profile will be disabled.
@@ -225,8 +226,11 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic,
PcdsDynamicEx]
gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate|0|UINT8|0x0007
## Indicates if SMM uses static page table.
- # If enabled, SMM will not use on-demand paging. SMM will build static page
table for all memory.
+ # If enabled, SMM will not use on-demand paging. SMM will build static page
table for all memory.
# This flag only impacts X64 build, because SMM alway builds static page
table for IA32.
+ # It could not be enabled at the same time with SMM profile feature
(PcdCpuSmmProfileEnable).
+ # It could not be enabled also at the same time with heap guard
+ feature for SMM # (PcdHeapGuardPropertyMask in
+ MdeModulePkg).
# TRUE - SMM uses static page table for all memory.
# FALSE - SMM uses static page table for below 4G memory and use on-demand
paging for above 4G memory.
# @Prompt Use static page table for all memory in SMM.
diff --git a/UefiCpuPkg/UefiCpuPkg.uni b/UefiCpuPkg/UefiCpuPkg.uni index
9472b185e46e..013d2870a682 10
Re: [edk2] [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support for Watchdog driver
Hi Liming,
On Thu, Dec 07, 2017 at 07:11:38AM +, Gao, Liming wrote:
> Leif:
> I don't see the core driver uses
> WatchdogTimer->RegisterHandler(). When it returns unsupported, it
> means the additional handler can't be registered. DxeCore uses
> WatchdogTimer->SetTimerPeriod(). This service is implemented in
> your driver.
>
> Watchdog protocol is defined in PI spec. Spec describes that this
> protocol provides the services required to implement the Boot
> Service SetWatchdogTimer(). It provides a service to set the
> amount of time to wait before firing the watchdog timer, and it
> also provides a service to register a handler that is invoked when
> the watchdog timer fires. This protocol can implement the watchdog
> timer by using the event and timer Boot Services, or it can make
> use of custom hardware. If no handler has been registered, or the
> registered handler returns, then the system will be reset by
> calling the Runtime Service ResetSystem(). So, this protocol is
> required.
I am not disputing that the protocol is not required. I am suggesting
that this hardware watchdog _cannot_ be used to register a handler.
If this hardware watchdog does not get updated in time, that causes an
immediate hardware reset of the processor.
Because of this, I believe EFI_WATCHDOG_TIMER_ARCH_PROTOCOL is not the
appropriate way to make use of it.
Please let me know whether you agree.
Regards,
Leif
> Thanks
> Liming
> >-Original Message-
> >From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> >Sent: Tuesday, December 05, 2017 7:06 PM
> >To: Udit Kumar
> >Cc: Gao, Liming ; Kinney, Michael D
> >; Meenakshi Aggarwal
> >; ard.biesheu...@linaro.org; edk2-
> >de...@lists.01.org; Varun Sethi
> >Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> >support for Watchdog driver
> >
> >On Tue, Dec 05, 2017 at 05:07:00AM +, Udit Kumar wrote:
> >> > I suggest return EFI_UNSUPPORTED for this case. The protocol
> >implementation
> >> > could return its status besides spec defined status.
> >>
> >> Thanks to help me , how core will treat this error
> >> 1/ Wdt not available
> >> 2/ ignoring this error
> >> 3/ core is not registering handler
> >> I guess 3 is valid,
> >
> >Looking at Core/Dxe/Misc/SetWatchdogTimer.c:
> > //
> > // Attempt to set the timeout
> > //
> > Status = gWatchdogTimer->SetTimerPeriod (gWatchdogTimer,
> > MultU64x32 (Timeout, WATCHDOG_TIMER_CALIBRATE_PER_SECOND));
> >
> > //
> > // Check for errors
> > //
> > if (EFI_ERROR (Status)) {
> >return EFI_DEVICE_ERROR;
> > }
> >
> >The SetWatchdogTimer() call would always return EFI_DEVICE_ERROR.
> >
> >> On side track, looks wdt is not used by core services then do we
> >> really need this as part of arch protocol ?
> >
> >Yes, that was ultimately what I was implying with my question
> >regarding whether this protocol is relevant for a watchdog that can
> >only ever reset the system on timeout.
> >
> >The protocol looks to me to be designed to use a dedicated generic
> >timer as backing for a software watchdog.
> >
> >Liming, Mike?
> >
> >If that is the case, then I agree this driver should probably not
> >implement this protocol, but rather set up a timer event (or a
> >dedicated timer) to stroke the watchdog.
> >
> >Regards,
> >
> >Leif
> >
> >> regards
> >> Udit
> >>
> >> > -Original Message-
> >> > From: Gao, Liming [mailto:liming@intel.com]
> >> > Sent: Monday, December 04, 2017 8:53 PM
> >> > To: Leif Lindholm ; Kinney, Michael D
> >> >
> >> > Cc: Meenakshi Aggarwal ;
> >> > ard.biesheu...@linaro.org; edk2-devel@lists.01.org; Udit Kumar
> >> > ; Varun Sethi
> >> > Subject: RE: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> >support
> >> > for Watchdog driver
> >> >
> >> > Leif:
> >> > I suggest return EFI_UNSUPPORTED for this case. The protocol
> >implementation
> >> > could return its status besides spec defined status.
> >> >
> >> > Thanks
> >> > Liming
> >> > > -Original Message-
> >> > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> >> > > Sent: Monday, December 4, 2017 10:36 PM
> >> > > To: Kinney, Michael D ; Gao, Liming
> >> > >
> >> > > Cc: Meenakshi Aggarwal ;
> >> > > ard.biesheu...@linaro.org; edk2-devel@lists.01.org;
> >> > > udit.ku...@nxp.com; v.se...@nxp.com
> >> > > Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> >> > > support for Watchdog driver
> >> > >
> >> > > Mike, Liming, as MdePkg mainteiners - one question below:
> >> > >
> >> > > On Mon, Nov 27, 2017 at 04:21:50PM +0530, Meenakshi Aggarwal wrote:
> >> > > > diff --git a/Platform/NXP/Drivers/WatchDog/WatchDog.c
> >> > > > b/Platform/NXP/Drivers/WatchDog/WatchDog.c
> >> > > > new file mode 100644
> >> > > > index 000..a9c70ef
> >> > > > --- /dev/null
> >> > > > +++ b/Platform/NXP/Drivers/WatchDog/WatchDog.c
> >> > > > @@ -0,0 +1,421 @@
> >> > >
> >> > > ...
> >> > >
> >> > > > +/**
> >> > > > + This function registe
Re: [edk2] [PATCH] BaseTools/tools_def: add CLANG38 LTO versions for AARCH64 and ARM
On 12/07/17 03:05, Shi, Steven wrote: > Hi Ard, > I'm OK for the patch. > BTW, would you mind to help add the "-Wno-unused-const-variable" in the > CLANG38_WARNING_OVERRIDES? I happen to need add it in CLANG38 > (https://bugzilla.tianocore.org/show_bug.cgi?id=790) and I see it seems a > shared flag for ARM/AARCH64 as well. I suggest we handle that flag / BZ separately from this patch. (If Ard feels very generous, he could append a separate patch to this series, for adding the flag, but I don't think we can *ask* for that. It's a totally separate topic.) Thanks! Laszlo > > Steven Shi > Intel\SSG\STO\UEFI Firmware > > Tel: +86 021-61166522 > iNet: 821-6522 > > >> -Original Message- >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >> Sent: Wednesday, December 6, 2017 7:39 PM >> To: edk2-devel@lists.01.org >> Cc: leif.lindh...@linaro.org; Gao, Liming ; Zhu, >> Yonghong ; Shi, Steven ; >> evan.ll...@arm.com; ler...@redhat.com; Ard Biesheuvel >> >> Subject: [PATCH] BaseTools/tools_def: add CLANG38 LTO versions for >> AARCH64 and ARM >> >> Extend the CLANG38 toolchain definition so it can be used for >> ARM and AARCH64 as well. Note that this requires llvm-ar and >> the LLVMgold.so linker plugin. >> >> In preparation of doing the same for GCC5, this toolchain version >> also departs from the custom of using -O0 for DEBUG builds, which >> makes them needlessly slow. Instead, let's add a NOOPT flavor as >> well, and enable optimization for DEBUG like the other architectures >> do. (Note that this will require some trivial changes to the platform >> description files) >> >> Contributed-under: TianoCore Contribution Agreement 1.1 >> Signed-off-by: Ard Biesheuvel >> --- >> BaseTools/Conf/tools_def.template | 98 +++- >> 1 file changed, 95 insertions(+), 3 deletions(-) >> >> diff --git a/BaseTools/Conf/tools_def.template >> b/BaseTools/Conf/tools_def.template >> index 91b135c2e569..6ee720d7586e 100755 >> --- a/BaseTools/Conf/tools_def.template >> +++ b/BaseTools/Conf/tools_def.template >> @@ -399,8 +399,8 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc >> # Intel(r) ACPI Compiler from >> # https://acpica.org/downloads >> # CLANG38 -Linux- Requires: >> -# Clang v3.8, LLVMgold plugin and GNU binutils >> 2.26 >> targeting x86_64-linux-gnu >> -# Clang v3.9 or later, LLVMgold plugin and GNU >> binutils 2.28 >> targeting x86_64-linux-gnu >> +# Clang v3.8, LLVMgold plugin and GNU binutils >> 2.26 >> targeting x86_64-linux-gnu, aarch64-linux-gnu or arm-linux-gnueabi >> +# Clang v3.9 or later, LLVMgold plugin and GNU >> binutils 2.28 >> targeting x86_64-linux-gnu, aarch64-linux-gnu or arm-linux-gnueabi >> #Optional: >> # Required to build platforms or ACPI tables: >> # Intel(r) ACPI Compiler from >> @@ -5652,6 +5652,7 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = >> DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS) >> *_CLANG38_*_MAKE_PATH = make >> *_CLANG38_*_*_DLL = ENV(CLANG38_DLL) >> *_CLANG38_*_ASL_PATH= DEF(UNIX_IASL_BIN) >> +*_CLANG38_*_DTC_PATH= DEF(DTC_BIN) >> >> *_CLANG38_*_APP_FLAGS = >> *_CLANG38_*_ASL_FLAGS = DEF(IASL_FLAGS) >> @@ -5663,7 +5664,8 @@ DEFINE CLANG38_X64_PREFIX = >> ENV(CLANG38_BIN) >> DEFINE CLANG38_IA32_TARGET = -target i686-pc-linux-gnu >> DEFINE CLANG38_X64_TARGET = -target x86_64-pc-linux-gnu >> >> -DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -Wno- >> empty-body -fno-stack-protector -mms-bitfields -Wno-address -Wno-shift- >> negative-value -Wno-parentheses-equality -Wno-unknown-pragmas -Wno- >> tautological-constant-out-of-range-compare -Wno-incompatible-library- >> redeclaration -fno-asynchronous-unwind-tables -mno-sse -mno-mmx - >> msoft-float -mno-implicit-float -ftrap- >> function=undefined_behavior_has_been_optimized_away_by_clang - >> funsigned-char -fno-ms-extensions -Wno-null-dereference -Wno- >> tautological-compare -Wno-unknown-warning-option -Wno-varargs >> +DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality - >> Wno-tautological-compare -Wno-tautological-constant-out-of-range- >> compare -Wno-empty-body -Wno-varargs >> +DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) >> DEF(CLANG38_WARNING_OVERRIDES) -fno-stack-protector -mms-bitfields - >> Wno-address -Wno-shift-negative-value -Wno-unknown-pragmas -Wno- >> incompatible-library-redeclaration -fno-asynchronous-unwind-tables -mno- >> sse -mno-mmx -msoft-float -mno-implicit-float -ftrap- >> function=undefined_behavior_has_been_optimized_away_by_clang - >> funsigned-char -fno-ms-extensions -Wno-null-dereference -Wno-unknown- >> warning-option >> >> ###
Re: [edk2] [PATCH] UefiCpuPkg PiSmmCpuDxeSmm: Only DumpCpuContext in error case
On 12/07/17 02:49, Star Zeng wrote:
> Only DumpCpuContext in error case, otherwise there will be too many
> debug messages from DumpCpuContext() when SmmProfile feature is enabled
> by setting PcdCpuSmmProfileEnable to TRUE. Those debug messages are not
> needed for SmmProfile feature as it will record those information to
> buffer for further dump.
>
> Cc: Jiewen Yao
> Cc: Eric Dong
> Cc: Laszlo Ersek
> Cc: Ruiyu Ni
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 6 --
> UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c | 6 --
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> index 0396f2daaaed..6e1ffe7c6287 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> @@ -134,12 +134,12 @@ SmiPFHandler (
>}
>
>//
> - // If a page fault occurs in SMM range
> + // If a page fault occurs in non-SMRAM range.
>//
>if ((PFAddress < mCpuHotPlugData.SmrrBase) ||
>(PFAddress >= mCpuHotPlugData.SmrrBase + mCpuHotPlugData.SmrrSize)) {
> -DumpCpuContext (InterruptType, SystemContext);
> if ((SystemContext.SystemContextIa32->ExceptionData & IA32_PF_EC_ID) !=
> 0) {
> + DumpCpuContext (InterruptType, SystemContext);
>DEBUG ((DEBUG_ERROR, "Code executed on IP(0x%x) out of SMM range after
> SMM is locked!\n", PFAddress));
>DEBUG_CODE (
> DumpModuleInfoByIp (*(UINTN
> *)(UINTN)SystemContext.SystemContextIa32->Esp);
> @@ -147,6 +147,7 @@ SmiPFHandler (
>CpuDeadLoop ();
> }
> if (IsSmmCommBufferForbiddenAddress (PFAddress)) {
> + DumpCpuContext (InterruptType, SystemContext);
>DEBUG ((DEBUG_ERROR, "Access SMM communication forbidden address
> (0x%x)!\n", PFAddress));
>DEBUG_CODE (
> DumpModuleInfoByIp ((UINTN)SystemContext.SystemContextIa32->Eip);
> @@ -160,6 +161,7 @@ SmiPFHandler (
>//
>if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT1) != 0 &&
>(PFAddress < EFI_PAGE_SIZE)) {
> +DumpCpuContext (InterruptType, SystemContext);
> DEBUG ((DEBUG_ERROR, "!!! NULL pointer access !!!\n"));
> DEBUG_CODE (
>DumpModuleInfoByIp ((UINTN)SystemContext.SystemContextIa32->Eip);
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> index 79a26d7ec6a3..6478c6c3e355 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> @@ -851,12 +851,12 @@ SmiPFHandler (
>}
>
>//
> - // If a page fault occurs in SMM range
> + // If a page fault occurs in non-SMRAM range.
>//
>if ((PFAddress < mCpuHotPlugData.SmrrBase) ||
>(PFAddress >= mCpuHotPlugData.SmrrBase + mCpuHotPlugData.SmrrSize)) {
> -DumpCpuContext (InterruptType, SystemContext);
> if ((SystemContext.SystemContextX64->ExceptionData & IA32_PF_EC_ID) !=
> 0) {
> + DumpCpuContext (InterruptType, SystemContext);
>DEBUG ((DEBUG_ERROR, "Code executed on IP(0x%lx) out of SMM range
> after SMM is locked!\n", PFAddress));
>DEBUG_CODE (
> DumpModuleInfoByIp (*(UINTN
> *)(UINTN)SystemContext.SystemContextX64->Rsp);
> @@ -864,6 +864,7 @@ SmiPFHandler (
>CpuDeadLoop ();
> }
> if (IsSmmCommBufferForbiddenAddress (PFAddress)) {
> + DumpCpuContext (InterruptType, SystemContext);
>DEBUG ((DEBUG_ERROR, "Access SMM communication forbidden address
> (0x%lx)!\n", PFAddress));
>DEBUG_CODE (
> DumpModuleInfoByIp ((UINTN)SystemContext.SystemContextX64->Rip);
> @@ -877,6 +878,7 @@ SmiPFHandler (
>//
>if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT1) != 0 &&
>(PFAddress < EFI_PAGE_SIZE)) {
> +DumpCpuContext (InterruptType, SystemContext);
> DEBUG ((DEBUG_ERROR, "!!! NULL pointer access !!!\n"));
> DEBUG_CODE (
>DumpModuleInfoByIp ((UINTN)SystemContext.SystemContextX64->Rip);
>
Looks reasonable to me.
Acked-by: Laszlo Ersek
Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support for Watchdog driver
Hi Liming,
> DxeCore uses WatchdogTimer->SetTimerPeriod(). This service is implemented in
> your driver.
Callers of SetTimerPeriod are ignoring error reported.
Is they assume this call will be perfect or they are ok in case some error on
watchdog service.
Regards
Udit
> -Original Message-
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Thursday, December 07, 2017 12:42 PM
> To: Leif Lindholm ; Udit Kumar
>
> Cc: Kinney, Michael D ; Meenakshi Aggarwal
> ; ard.biesheu...@linaro.org; edk2-
> de...@lists.01.org; Varun Sethi
> Subject: RE: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support
> for Watchdog driver
>
> Leif:
> I don't see the core driver uses WatchdogTimer->RegisterHandler(). When it
> returns unsupported, it means the additional handler can't be registered.
> DxeCore uses WatchdogTimer->SetTimerPeriod(). This service is implemented in
> your driver.
>
> Watchdog protocol is defined in PI spec. Spec describes that this protocol
> provides the services required to implement the Boot Service
> SetWatchdogTimer(). It provides a service to set the amount of time to wait
> before firing the watchdog timer, and it also provides a service to register a
> handler that is invoked when the watchdog timer fires. This protocol can
> implement the watchdog timer by using the event and timer Boot Services, or it
> can make use of custom hardware. If no handler has been registered, or the
> registered handler returns, then the system will be reset by calling the
> Runtime
> Service ResetSystem(). So, this protocol is required.
>
> Thanks
> Liming
> >-Original Message-
> >From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> >Sent: Tuesday, December 05, 2017 7:06 PM
> >To: Udit Kumar
> >Cc: Gao, Liming ; Kinney, Michael D
> >; Meenakshi Aggarwal
> >; ard.biesheu...@linaro.org; edk2-
> >de...@lists.01.org; Varun Sethi
> >Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> >support for Watchdog driver
> >
> >On Tue, Dec 05, 2017 at 05:07:00AM +, Udit Kumar wrote:
> >> > I suggest return EFI_UNSUPPORTED for this case. The protocol
> >implementation
> >> > could return its status besides spec defined status.
> >>
> >> Thanks to help me , how core will treat this error 1/ Wdt not
> >> available 2/ ignoring this error 3/ core is not registering handler I
> >> guess 3 is valid,
> >
> >Looking at Core/Dxe/Misc/SetWatchdogTimer.c:
> > //
> > // Attempt to set the timeout
> > //
> > Status = gWatchdogTimer->SetTimerPeriod (gWatchdogTimer,
> > MultU64x32 (Timeout, WATCHDOG_TIMER_CALIBRATE_PER_SECOND));
> >
> > //
> > // Check for errors
> > //
> > if (EFI_ERROR (Status)) {
> >return EFI_DEVICE_ERROR;
> > }
> >
> >The SetWatchdogTimer() call would always return EFI_DEVICE_ERROR.
> >
> >> On side track, looks wdt is not used by core services then do we
> >> really need this as part of arch protocol ?
> >
> >Yes, that was ultimately what I was implying with my question regarding
> >whether this protocol is relevant for a watchdog that can only ever
> >reset the system on timeout.
> >
> >The protocol looks to me to be designed to use a dedicated generic
> >timer as backing for a software watchdog.
> >
> >Liming, Mike?
> >
> >If that is the case, then I agree this driver should probably not
> >implement this protocol, but rather set up a timer event (or a
> >dedicated timer) to stroke the watchdog.
> >
> >Regards,
> >
> >Leif
> >
> >> regards
> >> Udit
> >>
> >> > -Original Message-
> >> > From: Gao, Liming [mailto:liming@intel.com]
> >> > Sent: Monday, December 04, 2017 8:53 PM
> >> > To: Leif Lindholm ; Kinney, Michael D
> >> >
> >> > Cc: Meenakshi Aggarwal ;
> >> > ard.biesheu...@linaro.org; edk2-devel@lists.01.org; Udit Kumar
> >> > ; Varun Sethi
> >> > Subject: RE: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP :
> >> > Add
> >support
> >> > for Watchdog driver
> >> >
> >> > Leif:
> >> > I suggest return EFI_UNSUPPORTED for this case. The protocol
> >implementation
> >> > could return its status besides spec defined status.
> >> >
> >> > Thanks
> >> > Liming
> >> > > -Original Message-
> >> > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> >> > > Sent: Monday, December 4, 2017 10:36 PM
> >> > > To: Kinney, Michael D ; Gao, Liming
> >> > >
> >> > > Cc: Meenakshi Aggarwal ;
> >> > > ard.biesheu...@linaro.org; edk2-devel@lists.01.org;
> >> > > udit.ku...@nxp.com; v.se...@nxp.com
> >> > > Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP :
> >> > > Add support for Watchdog driver
> >> > >
> >> > > Mike, Liming, as MdePkg mainteiners - one question below:
> >> > >
> >> > > On Mon, Nov 27, 2017 at 04:21:50PM +0530, Meenakshi Aggarwal wrote:
> >> > > > diff --git a/Platform/NXP/Drivers/WatchDog/WatchDog.c
> >> > > > b/Platform/NXP/Drivers/WatchDog/WatchDog.c
> >> > > > new file mode 100644
> >> > > > index 000..a9c70ef
> >> > > > --- /dev/null
> >> > > > +++ b/Platform/NX
Re: [edk2] [Patch] SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix duplicate symbol
On 12/07/17 09:46, Ard Biesheuvel wrote:
> On 7 December 2017 at 07:48, Liming Gao wrote:
>> From: Michael Kinney
>>
>> https://bugzilla.tianocore.org/show_bug.cgi?id=573
>> https://bugzilla.tianocore.org/show_bug.cgi?id=796
>>
>> The same issue is reported again by GCC. Resend this patch again.
>> This patch renames the duplicated function name to fix it.
>>
>> The SecPeiDebugAgentLib uses the global variable
>> mMemoryDiscoveredNotifyList for a PPI notification on
>> the Memory Discovered PPI. This same variable name is
>> used in the DxeIplPeim for the same PPI notification.
>>
>> The XCODE5 tool chain detects this duplicate symbol
>> when the OVMF platform is built with the flag
>> -D SOURCE_DEBUG_ENABLE.
>>
>> The fix is to rename this global variable in the
>> SecPeiDebugAgentLib library.
>>
>
> No, the fix is to make it STATIC unless it *needs* to be a global.
> Is that the case here?
I agree with you (of course), but Mike explained earlier (if I recall
correctly -- and perhaps you remember too) that giving internal linkage
to global variables (i.e., making them STATIC) messes either with
debuggability under VS, or else defeats "GLOBAL_REMOVE_IF_UNREFERENCED".
(I'm not sure which one of the two.)
So, I've settled on considering "extern by default" just another
peculiarity of edk2. *shrug* I'm just glad -fno-common catches bugs like
this!
Reviewed-by: Laszlo Ersek
(Obviously I'm not trying to dismiss your objection at all! Just stating
my view. If the patch is changed to STATIC, I'll R-b that version *more
happily* than this one.)
Thanks!
Laszlo
>
>
>> Cc: Andrew Fish
>> Cc: Jeff Fan
>> Cc: Hao Wu
>> Cc: Laszlo Ersek
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Michael D Kinney
>> Reviewed-by: Jeff Fan
>> ---
>> .../Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c | 4
>> ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git
>> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>>
>> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>> index b717e33..9f5223a 100644
>> ---
>> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>> +++
>> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>> @@ -32,7 +32,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_PPI_DESCRIPTOR
>> mVectorHandoffInf
>>}
>> };
>>
>> -GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR
>> mMemoryDiscoveredNotifyList[1] = {
>> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR
>> mDebugAgentMemoryDiscoveredNotifyList[1] = {
>>{
>> (EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK |
>> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
>> &gEfiPeiMemoryDiscoveredPpiGuid,
>> @@ -554,7 +554,7 @@ InitializeDebugAgent (
>> // Register for a callback once memory has been initialized.
>> // If memery has been ready, the callback funtion will be invoked
>> immediately
>> //
>> -Status = PeiServicesNotifyPpi (&mMemoryDiscoveredNotifyList[0]);
>> +Status = PeiServicesNotifyPpi
>> (&mDebugAgentMemoryDiscoveredNotifyList[0]);
>> if (EFI_ERROR (Status)) {
>>DEBUG ((EFI_D_ERROR, "DebugAgent: Failed to register memory
>> discovered callback function!\n"));
>>CpuDeadLoop ();
>> --
>> 2.6.3.windows.1
>>
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>> GitPatchExtractor 1.1
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] BaseTools/tools_def: add CLANG38 LTO versions for AARCH64 and ARM
On 7 December 2017 at 11:09, Laszlo Ersek wrote: > On 12/07/17 03:05, Shi, Steven wrote: >> Hi Ard, >> I'm OK for the patch. >> BTW, would you mind to help add the "-Wno-unused-const-variable" in the >> CLANG38_WARNING_OVERRIDES? I happen to need add it in CLANG38 >> (https://bugzilla.tianocore.org/show_bug.cgi?id=790) and I see it seems a >> shared flag for ARM/AARCH64 as well. > > I suggest we handle that flag / BZ separately from this patch. (If Ard > feels very generous, he could append a separate patch to this series, > for adding the flag, but I don't think we can *ask* for that. It's a > totally separate topic.) > Yes, it is. But guess what, I was feeling very generous, so I did exactly that. (I am guessing Steven is very busy, so I don't mind doing his work :-)) -- Ard. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file
Hi Yonghong, This patch resolves the issue for the hikey platform, but not for (edk2-platforms/Platform/Hisilicon/)D03/D05. They fail with --- Generating FVMAIN FV ## #Return Value = 2 GenSec: ERROR 0001: Error opening file /work/git/tianocore/Build/D03/DEBUG_GCC5/AARCH64/Platform/Hisilicon/D03/Drivers/Net/SnpPlatform/SnpPlatform/OUTPUT/SnpPlatform.depex GenSec: ERROR 2000: Status is not successful --- and --- Generating FVMAIN FV ## Return Value = 2 GenSec: ERROR 0001: Error opening file /work/git/tianocore/Build/D05/RELEASE_GCC5/AARCH64/Platform/Hisilicon/D05/Drivers/Net/SnpPlatform/SnpPlatform/OUTPUT/SnpPlatform.depex GenFds.py... : error 7000: Failed to generate section GenSec: ERROR 2000: Status is not successful --- respectively. Again, reverting 37de70b7 makes the build successful again. Note that the failing drivers are binary, held in edk2-non-osi. Regards, Leif On Thu, Dec 07, 2017 at 02:51:17PM +0800, Yonghong Zhu wrote: > From: Yunhua Feng > > Filter the FileList when multiple genfds thread options is not enabled. > > Cc: Liming Gao > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Yunhua Feng > --- > BaseTools/Source/Python/GenFds/EfiSection.py | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/BaseTools/Source/Python/GenFds/EfiSection.py > b/BaseTools/Source/Python/GenFds/EfiSection.py > index 7b3b717191..4276945a10 100644 > --- a/BaseTools/Source/Python/GenFds/EfiSection.py > +++ b/BaseTools/Source/Python/GenFds/EfiSection.py > @@ -92,7 +92,8 @@ class EfiSection (EfiSectionClassObject): > elif os.path.exists(Filename): > FileList.append(Filename) > elif '.depex' in FfsInf.FinalTargetSuffixMap or FfsInf.Depex: > -FileList.append(Filename) > +if IsMakefile: > +FileList.append(Filename) > else: > FileList, IsSect = Section.Section.GetFileList(FfsInf, > self.FileType, self.FileExtension, Dict) > if IsSect : > -- > 2.12.2.windows.2 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v4 0/2] Enable page table write protection
> v4 changes:
>MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 22 ++---
> MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h | 2 +-
> UefiCpuPkg/CpuDxe/CpuPageTable.c | 25 +++-
> UefiCpuPkg/CpuDxe/CpuPageTable.h | 2 +-
> 4 files changed, 23 insertions(+), 28 deletions(-)
>
>diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>index 4ef3521224..038aa0d127 100644
>--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>@@ -126,12 +126,13 @@ EnableExecuteDisableBit (
> Initialize a buffer pool for page table use only.
>
> To reduce the potential split operation on page table, the pages reserved
> for
>- page table should be allocated in the times of 512 (= SIZE_2MB) and at the
>- boundary of SIZE_2MB. So the page pool is always initialized with number of
>- pages greater than or equal to the given PoolPages.
>+ page table should be allocated in the times of PAGE_TABLE_POOL_UNIT_PAGES
>and
>+ at the boundary of PAGE_TABLE_POOL_ALIGNMENT. So the page pool is always
>+ initialized with number of pages greater than or equal to the given
>PoolPages.
>
> Once the pages in the pool are used up, this method should be called again
> to
>- reserve at least another 512 pages. But usually this won't happen in
>practice.
>+ reserve at least another PAGE_TABLE_POOL_UNIT_PAGES. But usually this won't
>+ happen in practice.
>
> @param PoolPages The least page number of the pool to be created.
>
>@@ -146,15 +147,12 @@ InitializePageTablePool (
> VOID *Buffer;
>
> //
>- // Always reserve at least PAGE_TABLE_POOL_UNIT_PAGES (512).
>+ // Always reserve at least PAGE_TABLE_POOL_UNIT_PAGES, including one page
>for
>+ // header.
> //
>- if (PoolPages <= PAGE_TABLE_POOL_UNIT_PAGES) {
>-PoolPages = PAGE_TABLE_POOL_UNIT_PAGES;
>- } else {
>-PoolPages = ((PoolPages + PAGE_TABLE_POOL_UNIT_PAGES) %
>- PAGE_TABLE_POOL_UNIT_PAGES) * PAGE_TABLE_POOL_UNIT_PAGES;
>- }
>-
>+ PoolPages += 1; // Add one page for header.
>+ PoolPages = ((PoolPages - 1) / PAGE_TABLE_POOL_UNIT_PAGES + 1) *
>+ PAGE_TABLE_POOL_UNIT_PAGES;
> Buffer = AllocateAlignedPages (PoolPages, PAGE_TABLE_POOL_ALIGNMENT);
> if (Buffer == NULL) {
> DEBUG ((DEBUG_ERROR, "ERROR: Out of aligned pages\r\n"));
>diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
>b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
>index 9f14ac6007..b8cf43104e 100644
>--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
>+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
>@@ -169,7 +169,7 @@ typedef union {
>
> #define PAGE_TABLE_POOL_ALIGNMENT BASE_2MB
> #define PAGE_TABLE_POOL_UNIT_SIZE SIZE_2MB
>-#define PAGE_TABLE_POOL_UNIT_PAGES EFI_SIZE_TO_PAGES (SIZE_2MB)
>+#define PAGE_TABLE_POOL_UNIT_PAGES EFI_SIZE_TO_PAGES
>(PAGE_TABLE_POOL_UNIT_SIZE)
> #define PAGE_TABLE_POOL_ALIGN_MASK \
> (~(EFI_PHYSICAL_ADDRESS)(PAGE_TABLE_POOL_ALIGNMENT - 1))
>
>diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c
>b/UefiCpuPkg/CpuDxe/CpuPageTable.c
>index 57ec76378a..a9c9bc9d5e 100644
>--- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
>+++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
>@@ -1000,13 +1000,13 @@ RefreshGcdMemoryAttributesFromPaging (
> Initialize a buffer pool for page table use only.
>
> To reduce the potential split operation on page table, the pages reserved
> for
>- page table should be allocated in the times of 512 (= SIZE_2MB) and at the
>- boundary of SIZE_2MB. So the page pool is always initialized with number of
>- pages greater than or equal to the given PoolPages.
>+ page table should be allocated in the times of PAGE_TABLE_POOL_UNIT_PAGES
>and
>+ at the boundary of PAGE_TABLE_POOL_ALIGNMENT. So the page pool is always
>+ initialized with number of pages greater than or equal to the given
>PoolPages.
>
> Once the pages in the pool are used up, this method should be called again
> to
>- reserve at least another 512 pages. Usually this won't happen often in
>- practice.
>+ reserve at least another PAGE_TABLE_POOL_UNIT_PAGES. Usually this won't
>happen
>+ often in practice.
>
> @param[in] PoolPages The least page number of the pool to be created.
>
>@@ -1022,15 +1022,12 @@ InitializePageTablePool (
> BOOLEAN IsModified;
>
> //
>- // Always reserve at least PAGE_TABLE_POOL_UNIT_PAGES (512).
>+ // Always reserve at least PAGE_TABLE_POOL_UNIT_PAGES, including one page
>for
>+ // header.
> //
>- if (PoolPages <= PAGE_TABLE_POOL_UNIT_PAGES) {
>-PoolPages = PAGE_TABLE_POOL_UNIT_PAGES;
>- } else {
>-PoolPages = ((PoolPages + PAGE_TABLE_POOL_UNIT_PAGES) %
>- PAGE_TABLE_POOL_UNIT_PAGES) * PAGE_TABLE_POOL_UNIT_PAGES;
>- }
>-
>+ PoolPages += 1; // Add one page for header.
>+ PoolPages = ((PoolPages - 1) / PAGE_TABLE_POOL_UNIT_PAGES + 1
Re: [edk2] [PATCH] UefiCpuPkg PiSmmCpuDxeSmm: SMM profile and static paging mutual exclusion
Hi Star,
On 12/07/17 11:47, Star Zeng wrote:
> SMM profile and static paging could not enabled at the same time,
> this patch is add check and comments to make sure it.
>
> Similar comments are also added for the case of static paging and
> heap guard for SMM.
>
> Cc: Jiewen Yao
> Cc: Eric Dong
> Cc: Ruiyu Ni
> Cc: Jian J Wang
> Cc: Laszlo Ersek
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng
> ---
> UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 9 +
> UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c | 13 ++---
> UefiCpuPkg/UefiCpuPkg.dec| 6 +-
> UefiCpuPkg/UefiCpuPkg.uni| 10 --
> 4 files changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> index 6e1ffe7c6287..939ac25a506c 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> @@ -205,6 +205,15 @@ SetPageTableAttributes (
>// BIT3: SMM pool guard enabled
>//
>if ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
> +DEBUG ((DEBUG_INFO, "Don't mark page table as read-only as heap guard is
> enabled\n"));
> +return ;
> + }
> +
> + //
> + // Don't mark page table as read-only if SMM profile is enabled.
> + //
> + if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
> +DEBUG ((DEBUG_INFO, "Don't mark page table as read-only as SMM profile
> is enabled\n"));
> return ;
>}
>
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> index 6478c6c3e355..0fe944fc18cc 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> @@ -919,17 +919,24 @@ SetPageTableAttributes (
>//
>// Don't do this if
>// - no static page table; or
> - // - SMM heap guard feature enabled
> + // - SMM heap guard feature enabled; or
>// BIT2: SMM page guard enabled
>// BIT3: SMM pool guard enabled
> + // - SMM profile feature enabled
>//
>if (!mCpuSmmStaticPageTable ||
> - (PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
> + ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) ||
> + FeaturePcdGet (PcdCpuSmmProfileEnable)) {
> //
> -// Static paging and heap guard should not be enabled at the same time.
> +// Static paging and heap guard could not be enabled at the same time.
> //
> ASSERT (!(mCpuSmmStaticPageTable &&
>(PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0));
> +
> +//
> +// Static paging and SMM profile could not be enabled at the same time.
> +//
> +ASSERT (!(mCpuSmmStaticPageTable && FeaturePcdGet
> (PcdCpuSmmProfileEnable)));
> return ;
>}
>
> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
> index d2965ba14c2d..36205ab63796 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dec
> +++ b/UefiCpuPkg/UefiCpuPkg.dec
> @@ -84,6 +84,7 @@ [Protocols]
> [PcdsFeatureFlag]
>## Indicates if SMM Profile will be enabled.
># If enabled, instruction executions in and data accesses to memory
> outside of SMRAM will be logged.
> + # It could not be enabled at the same time with SMM profile feature
> (PcdCpuSmmStaticPageTable).
># This PCD is only for validation purpose. It should be set to false in
> production.
># TRUE - SMM Profile will be enabled.
># FALSE - SMM Profile will be disabled.
> @@ -225,8 +226,11 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic,
> PcdsDynamicEx]
>gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate|0|UINT8|0x0007
>
>## Indicates if SMM uses static page table.
> - # If enabled, SMM will not use on-demand paging. SMM will build static
> page table for all memory.
> + # If enabled, SMM will not use on-demand paging. SMM will build static
> page table for all memory.
># This flag only impacts X64 build, because SMM alway builds static page
> table for IA32.
> + # It could not be enabled at the same time with SMM profile feature
> (PcdCpuSmmProfileEnable).
> + # It could not be enabled also at the same time with heap guard feature
> for SMM
> + # (PcdHeapGuardPropertyMask in MdeModulePkg).
># TRUE - SMM uses static page table for all memory.
># FALSE - SMM uses static page table for below 4G memory and use
> on-demand paging for above 4G memory.
># @Prompt Use static page table for all memory in SMM.
> diff --git a/UefiCpuPkg/UefiCpuPkg.uni b/UefiCpuPkg/UefiCpuPkg.uni
> index 9472b185e46e..013d2870a682 100644
> --- a/UefiCpuPkg/UefiCpuPkg.uni
> +++ b/UefiCpuPkg/UefiCpuPkg.uni
> @@ -53,7 +53,10 @@
>
> #string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuSmmProfileEnable_PROMPT
> #language en-US "Enable SMM Profile"
>
> -#string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuSmmProfileEnable_HELP #language
> en-US "Indicates if SMM Profile will be enable
[edk2] [PATCH v4 1/2] MdeModulePkg/DxeIpl: Mark page table as read-only
> v4: > a. Fix a calculation error in pool page number during initialization > b. Change comments to remove constants in description > v3: >Remove the public definition of PAGE_TABLE_POOL_HEADER but keep similar >concept locally. CpuDxe has its own page table pool. > v2: >Introduce page table pool to ease the page table memory allocation and >protection, which replaces the direct calling of AllocatePages(). This patch will set the memory pages used for page table as read-only memory after the paging is setup. CR0.WP must set to let it take into effect. A simple page table memory management mechanism, page table pool concept, is introduced to simplify the page table memory allocation and protection. It will also help to reduce the potential recursive "split" action during updating memory paging attributes. The basic idea is to allocate a bunch of continuous pages of memory in advance as one or more page table pools, and all future page tables consumption will happen in those pool instead of system memory. If the page pool is reserved at the boundary of 2MB page and with same size of 2MB page, there's no page granularity "split" operation will be needed, because the memory of new page tables (if needed) will be usually in the same page as target page table you're working on. And since we have centralized page tables (a few 2MB pages), it's easier to protect them by changing their attributes to be read-only once and for all. There's no need to apply the protection for new page tables any more as long as the pool has free pages available. Once current page table pool has been used up, one can allocate another 2MB memory pool and just set this new 2MB memory block to be read-only instead of setting the new page tables one page by one page. Two new PCDs PcdPageTablePoolUnitSize and PcdPageTablePoolAlignment are used to specify the size and alignment for page table pool. For IA32 processor 0x20 (2MB) is the only choice for both of them to meet the requirement of page table pool. Cc: Jiewen Yao Cc: Star Zeng Cc: Eric Dong Cc: Ruiyu Ni Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang --- MdeModulePkg/Core/DxeIplPeim/DxeIpl.h| 34 +++ MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c | 8 +- MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 299 ++- MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h | 26 ++ 4 files changed, 363 insertions(+), 4 deletions(-) diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h index f3aabdb7e0..9dc80b1508 100644 --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h @@ -265,4 +265,38 @@ IsNullDetectionEnabled ( VOID ); +/** + Prevent the memory pages used for page table from been overwritten. + + @param[in] PageTableBaseBase address of page table (CR3). + +**/ +VOID +EnablePageTableProtection ( + IN UINTN PageTableBase, + IN BOOLEAN Level4Paging + ); + +/** + This API provides a way to allocate memory for page table. + + This API can be called more than once to allocate memory for page tables. + + Allocates the number of 4KB pages and returns a pointer to the allocated + buffer. The buffer returned is aligned on a 4KB boundary. + + If Pages is 0, then NULL is returned. + If there is not enough memory remaining to satisfy the request, then NULL is + returned. + + @param Pages The number of 4 KB pages to allocate. + + @return A pointer to the allocated buffer or NULL if allocation fails. + +**/ +VOID * +AllocatePageTableMemory ( + IN UINTN Pages + ); + #endif diff --git a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c index 5649265367..13fff28e93 100644 --- a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c +++ b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c @@ -99,7 +99,7 @@ Create4GPageTablesIa32Pae ( NumberOfPdpEntriesNeeded = (UINT32) LShiftU64 (1, (PhysicalAddressBits - 30)); TotalPagesNum = NumberOfPdpEntriesNeeded + 1; - PageAddress = (UINTN) AllocatePages (TotalPagesNum); + PageAddress = (UINTN) AllocatePageTableMemory (TotalPagesNum); ASSERT (PageAddress != 0); PageMap = (VOID *) PageAddress; @@ -149,6 +149,12 @@ Create4GPageTablesIa32Pae ( ); } + // + // Protect the page table by marking the memory used for page table to be + // read-only. + // + EnablePageTableProtection ((UINTN)PageMap, FALSE); + return (UINTN) PageMap; } diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c index 29b6205e88..038aa0d127 100644 --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c @@ -31,6 +31,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. #include "DxeIpl.h" #include "VirtualMemory.h" +// +// Global variab
[edk2] [PATCH v4 2/2] UefiCpuPkg/CpuDxe: Enable protection for newly added page table
> v4:
> a. Fix an error in calculating/passing pool page number during initialization
> b. Change comments to remove constants in description
> v3:
>Create driver's own page table pool instead of inheriting from DxeIpl.
> v2:
>Use the page table pool to allocate new page tables and save code
>to enable protection for them separately.
One of the functionalities of CpuDxe is to update memory paging attributes.
If page table protection is applied, it must be disabled temporarily before
any attributes update and enabled again afterwards.
This patch makes use of the same way as DxeIpl to allocate page table memory
from reserved memory pool, which helps to reduce potential "split" operation
and recursive calling of SetMemorySpaceAttributes().
Cc: Jiewen Yao
Cc: Eric Dong
Cc: Laszlo Ersek
Cc: Ruiyu Ni
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang
---
UefiCpuPkg/CpuDxe/CpuDxe.c | 17 ++-
UefiCpuPkg/CpuDxe/CpuDxe.h | 2 +
UefiCpuPkg/CpuDxe/CpuPageTable.c | 223 +--
UefiCpuPkg/CpuDxe/CpuPageTable.h | 34 ++
4 files changed, 267 insertions(+), 9 deletions(-)
diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.c b/UefiCpuPkg/CpuDxe/CpuDxe.c
index 8ddebabd02..6ae2dcd1c7 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.c
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.c
@@ -25,6 +25,7 @@
BOOLEAN InterruptState = FALSE;
EFI_HANDLEmCpuHandle = NULL;
BOOLEAN mIsFlushingGCD;
+BOOLEAN mIsAllocatingPageTable = FALSE;
UINT64mValidMtrrAddressMask;
UINT64mValidMtrrBitsMask;
UINT64mTimerPeriod = 0;
@@ -407,6 +408,20 @@ CpuSetMemoryAttributes (
return EFI_SUCCESS;
}
+ //
+ // During memory attributes updating, new pages may be allocated to setup
+ // smaller granularity of page table. Page allocation action might then cause
+ // another calling of CpuSetMemoryAttributes() recursively, due to memory
+ // protection policy configured (such as PcdDxeNxMemoryProtectionPolicy).
+ // Since this driver will always protect memory used as page table by itself,
+ // there's no need to apply protection policy requested from memory service.
+ // So it's safe to just return EFI_SUCCESS if this time of calling is caused
+ // by page table memory allocation.
+ //
+ if (mIsAllocatingPageTable) {
+DEBUG((DEBUG_VERBOSE, " Allocating page table memory\n"));
+return EFI_SUCCESS;
+ }
CacheAttributes = Attributes & CACHE_ATTRIBUTE_MASK;
MemoryAttributes = Attributes & MEMORY_ATTRIBUTE_MASK;
@@ -487,7 +502,7 @@ CpuSetMemoryAttributes (
//
// Set memory attribute by page table
//
- return AssignMemoryPageAttributes (NULL, BaseAddress, Length,
MemoryAttributes, AllocatePages);
+ return AssignMemoryPageAttributes (NULL, BaseAddress, Length,
MemoryAttributes, NULL);
}
/**
diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.h b/UefiCpuPkg/CpuDxe/CpuDxe.h
index 9c0d22359d..540f5f2dbf 100644
--- a/UefiCpuPkg/CpuDxe/CpuDxe.h
+++ b/UefiCpuPkg/CpuDxe/CpuDxe.h
@@ -273,5 +273,7 @@ RefreshGcdMemoryAttributesFromPaging (
VOID
);
+extern BOOLEAN mIsAllocatingPageTable;
+
#endif
diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c b/UefiCpuPkg/CpuDxe/CpuPageTable.c
index 9658ed74c5..a9c9bc9d5e 100644
--- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
+++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
@@ -87,6 +87,8 @@ PAGE_ATTRIBUTE_TABLE mPageAttributeTable[] = {
{Page1G, SIZE_1GB, PAGING_1G_ADDRESS_MASK_64},
};
+PAGE_TABLE_POOL *mPageTablePool = NULL;
+
/**
Enable write protection function for AP.
@@ -172,10 +174,6 @@ GetCurrentPagingContext (
}
if ((AsmReadCr0 () & BIT31) != 0) {
PagingContext->ContextData.X64.PageTableBase = (AsmReadCr3 () &
PAGING_4K_ADDRESS_MASK_64);
-if ((AsmReadCr0 () & BIT16) == 0) {
- AsmWriteCr0 (AsmReadCr0 () | BIT16);
- SyncMemoryPageAttributesAp (SyncCpuEnableWriteProtection);
-}
} else {
PagingContext->ContextData.X64.PageTableBase = 0;
}
@@ -561,6 +559,59 @@ SplitPage (
}
}
+/**
+ Check the WP status in CR0 register. This bit is used to lock or unlock write
+ access to pages marked as read-only.
+
+ @retval TRUEWrite protection is enabled.
+ @retval FALSE Write protection is disabled.
+**/
+BOOLEAN
+IsReadOnlyPageWriteProtected (
+ VOID
+ )
+{
+ return ((AsmReadCr0 () & BIT16) != 0);
+}
+
+/**
+ Disable write protection function for AP.
+
+ @param[in,out] Buffer The pointer to private data buffer.
+**/
+VOID
+EFIAPI
+SyncCpuDisableWriteProtection (
+ IN OUT VOID *Buffer
+ )
+{
+ AsmWriteCr0 (AsmReadCr0() & ~BIT16);
+}
+
+/**
+ Disable Write Protect on pages marked as read-only.
+**/
+VOID
+DisableReadOnlyPageWriteProtect (
+ VOID
+ )
+{
+ AsmWriteCr0 (AsmReadCr0() & ~BIT16);
+ SyncMemoryPageAttributesAp (SyncCpuDisableWriteProtection);
+}
+
+/**
+ Enable Write Protect on pages marked as read-only.
+**/
+VOID
+EnableReadOnlyPag
Re: [edk2] [PATCH] MdePkg: Arm/AArch64 - filter #pragma pack() when __ASSEMBLER__
On Thu, Dec 07, 2017 at 03:09:17AM +, Gao, Liming wrote: > Reviewed-by: Liming Gao Thanks! Pushed as 5b8766bb92. > >-Original Message- > >From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > >Sent: Thursday, December 07, 2017 1:08 AM > >To: edk2-devel@lists.01.org > >Cc: Kinney, Michael D ; Gao, Liming > >; ard.biesheu...@linaro.org > >Subject: [PATCH] MdePkg: Arm/AArch64 - filter #pragma pack() when > >__ASSEMBLER__ > > > >clang, when used as a preprocessor for dtc, does not discard #pragma > >statements although -x assembler-with-cpp is specified. This causes dtc > >to barf at a #pragma pack() statement that is already filtered out for > >__GNUC__. So add a check to also filter this out if __ASSEMBLER__. > > > >Contributed-under: TianoCore Contribution Agreement 1.1 > >Signed-off-by: Leif Lindholm > >--- > > MdePkg/Include/AArch64/ProcessorBind.h | 2 +- > > MdePkg/Include/Arm/ProcessorBind.h | 2 +- > > 2 files changed, 2 insertions(+), 2 deletions(-) > > > >diff --git a/MdePkg/Include/AArch64/ProcessorBind.h > >b/MdePkg/Include/AArch64/ProcessorBind.h > >index 775e7498c5..7b0f0ff32f 100644 > >--- a/MdePkg/Include/AArch64/ProcessorBind.h > >+++ b/MdePkg/Include/AArch64/ProcessorBind.h > >@@ -26,7 +26,7 @@ > > // > > // Make sure we are using the correct packing rules per EFI specification > > // > >-#ifndef __GNUC__ > >+#if !defined(__GNUC__) && !defined(__ASSEMBLER__) > > #pragma pack() > > #endif > > > >diff --git a/MdePkg/Include/Arm/ProcessorBind.h > >b/MdePkg/Include/Arm/ProcessorBind.h > >index dde1fd1152..42ea2f3055 100644 > >--- a/MdePkg/Include/Arm/ProcessorBind.h > >+++ b/MdePkg/Include/Arm/ProcessorBind.h > >@@ -24,7 +24,7 @@ > > // > > // Make sure we are using the correct packing rules per EFI specification > > // > >-#ifndef __GNUC__ > >+#if !defined(__GNUC__) && !defined(__ASSEMBLER__) > > #pragma pack() > > #endif > > > >-- > >2.11.0 > ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 2/3] BaseTools/tools_def CLANG38: add -Wno-unused-const-variable
On 12/07/17 10:28, Ard Biesheuvel wrote:
> Commit 8b6366f87584 ("BaseTools/GCC: set -Wno-unused-const-variable
> on RELEASE builds") suppresses warnings about unused constant
> variables in RELEASE builds when building with GCC, given that they
> break the build under our warnings-as-errors policy.
>
> Do the same for CLANG38.
>
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=790
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> ---
> v2: new patch
>
> BaseTools/Conf/tools_def.template | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> index c0189d4c8d30..703884fc49a7 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -5664,7 +5664,7 @@ DEFINE CLANG38_X64_PREFIX = ENV(CLANG38_BIN)
> DEFINE CLANG38_IA32_TARGET = -target i686-pc-linux-gnu
> DEFINE CLANG38_X64_TARGET = -target x86_64-pc-linux-gnu
>
> -DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality
> -Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare
> -Wno-empty-body -Wno-varargs
> +DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality
> -Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare
> -Wno-empty-body -Wno-unused-const-variable -Wno-varargs
> DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS)
> DEF(CLANG38_WARNING_OVERRIDES) -fno-stack-protector -mms-bitfields
> -Wno-address -Wno-shift-negative-value -Wno-unknown-pragmas
> -Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables
> -mno-sse -mno-mmx -msoft-float -mno-implicit-float
> -ftrap-function=undefined_behavior_has_been_optimized_away_by_clang
> -funsigned-char -fno-ms-extensions -Wno-null-dereference
> -Wno-unknown-warning-option
>
> ###
>
Very kind of you.
Reviewed-by: Laszlo Ersek
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 3/3] BaseTool/tools_def GCC5: enable optimization for ARM/AARCH64 DEBUG builds
On 12/07/17 10:28, Ard Biesheuvel wrote: > Enable optimization for DEBUG builds, to make it more usable in terms of > performance, and to give more coverage to the LTO builds. Also, some > diagnostics are only enabled when optimization is enabled. > NOOPT builds can now also be created, which will retain the behavior DEBUG > builds had previously. > > Note that this aligns ARM and AARCH64 with the x86 architectures, which > already use optimization for DEBUG builds. > > In order to preserve existing behavior for users of older toolchains, > keep GCC49 and older as-is. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > --- > v2: new patch > > BaseTools/Conf/tools_def.template | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/BaseTools/Conf/tools_def.template > b/BaseTools/Conf/tools_def.template > index 703884fc49a7..aec390f8eeb1 100755 > --- a/BaseTools/Conf/tools_def.template > +++ b/BaseTools/Conf/tools_def.template > @@ -5517,8 +5517,8 @@ RELEASE_GCC5_X64_DLINK_FLAGS = > DEF(GCC5_X64_DLINK_FLAGS) -flto -Os > *_GCC5_ARM_VFRPP_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) > DEF(GCC_VFRPP_FLAGS) > *_GCC5_ARM_CC_XIPFLAGS = DEF(GCC5_ARM_CC_XIPFLAGS) > > - DEBUG_GCC5_ARM_CC_FLAGS= DEF(GCC5_ARM_CC_FLAGS) -O0 > - DEBUG_GCC5_ARM_DLINK_FLAGS = DEF(GCC5_ARM_DLINK_FLAGS) > + DEBUG_GCC5_ARM_CC_FLAGS= DEF(GCC5_ARM_CC_FLAGS) -flto > -Wno-unused-but-set-variable -Wno-unused-const-variable > + DEBUG_GCC5_ARM_DLINK_FLAGS = DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os > -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-arm > -Wl,-plugin-opt=-pass-through=-llto-arm > > RELEASE_GCC5_ARM_CC_FLAGS= DEF(GCC5_ARM_CC_FLAGS) -flto > -Wno-unused-but-set-variable -Wno-unused-const-variable > RELEASE_GCC5_ARM_DLINK_FLAGS = DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os > -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-arm > -Wl,-plugin-opt=-pass-through=-llto-arm > @@ -5551,8 +5551,8 @@ RELEASE_GCC5_ARM_DLINK_FLAGS = > DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os -L$(WORKS > *_GCC5_AARCH64_VFRPP_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) > DEF(GCC_VFRPP_FLAGS) > *_GCC5_AARCH64_CC_XIPFLAGS = DEF(GCC5_AARCH64_CC_XIPFLAGS) > > - DEBUG_GCC5_AARCH64_CC_FLAGS= DEF(GCC5_AARCH64_CC_FLAGS) -O0 > -mcmodel=small > - DEBUG_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -z > common-page-size=0x1000 > + DEBUG_GCC5_AARCH64_CC_FLAGS= DEF(GCC5_AARCH64_CC_FLAGS) -flto > -Wno-unused-but-set-variable -Wno-unused-const-variable -mcmodel=small > + DEBUG_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -z > common-page-size=0x1000 -flto -Os -L$(WORKSPACE)/ArmPkg/Library/GccLto > -llto-aarch64 -Wl,-plugin-opt=-pass-through=-llto-aarch64 > -Wno-lto-type-mismatch -mcmodel=small >DEBUG_GCC5_AARCH64_DLINK_XIPFLAGS = -z common-page-size=0x20 > > RELEASE_GCC5_AARCH64_CC_FLAGS= DEF(GCC5_AARCH64_CC_FLAGS) -flto > -Wno-unused-but-set-variable -Wno-unused-const-variable -mcmodel=tiny > If it compiles, ship it. :) Acked-by: Laszlo Ersek ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix duplicate symbol
On 7 December 2017 at 11:18, Laszlo Ersek wrote:
> On 12/07/17 09:46, Ard Biesheuvel wrote:
>> On 7 December 2017 at 07:48, Liming Gao wrote:
>>> From: Michael Kinney
>>>
>>> https://bugzilla.tianocore.org/show_bug.cgi?id=573
>>> https://bugzilla.tianocore.org/show_bug.cgi?id=796
>>>
>>> The same issue is reported again by GCC. Resend this patch again.
>>> This patch renames the duplicated function name to fix it.
>>>
>>> The SecPeiDebugAgentLib uses the global variable
>>> mMemoryDiscoveredNotifyList for a PPI notification on
>>> the Memory Discovered PPI. This same variable name is
>>> used in the DxeIplPeim for the same PPI notification.
>>>
>>> The XCODE5 tool chain detects this duplicate symbol
>>> when the OVMF platform is built with the flag
>>> -D SOURCE_DEBUG_ENABLE.
>>>
>>> The fix is to rename this global variable in the
>>> SecPeiDebugAgentLib library.
>>>
>>
>> No, the fix is to make it STATIC unless it *needs* to be a global.
>> Is that the case here?
>
> I agree with you (of course), but Mike explained earlier (if I recall
> correctly -- and perhaps you remember too) that giving internal linkage
> to global variables (i.e., making them STATIC) messes either with
> debuggability under VS, or else defeats "GLOBAL_REMOVE_IF_UNREFERENCED".
> (I'm not sure which one of the two.)
>
That doesn't quite ring a bell, but if that is the case, it deserves a mention.
Note that STATIC variables are also removed when unreferenced (but may
require a warning override like we have for GCC if it is only used
from DEBUG () code). In any case, polluting the global namespace in a
heterogeneous project like EDK2 is something that should only be done
with good reason IMO.
> So, I've settled on considering "extern by default" just another
> peculiarity of edk2. *shrug* I'm just glad -fno-common catches bugs like
> this!
>
Well, the thing is, external linkage defeats optimizations in the
compiler, and also prevents it from emitting the variable into a
read-only section even if it would otherwise be able to infer from the
usage that the variable is never modified.
> Reviewed-by: Laszlo Ersek
>
> (Obviously I'm not trying to dismiss your objection at all! Just stating
> my view. If the patch is changed to STATIC, I'll R-b that version *more
> happily* than this one.)
>
> Thanks!
> Laszlo
>
>>
>>
>>> Cc: Andrew Fish
>>> Cc: Jeff Fan
>>> Cc: Hao Wu
>>> Cc: Laszlo Ersek
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Michael D Kinney
>>> Reviewed-by: Jeff Fan
>>> ---
>>> .../Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c | 4
>>> ++--
>>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git
>>> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>>>
>>> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>>> index b717e33..9f5223a 100644
>>> ---
>>> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>>> +++
>>> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>>> @@ -32,7 +32,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_PPI_DESCRIPTOR
>>> mVectorHandoffInf
>>>}
>>> };
>>>
>>> -GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR
>>> mMemoryDiscoveredNotifyList[1] = {
>>> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR
>>> mDebugAgentMemoryDiscoveredNotifyList[1] = {
>>>{
>>> (EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK |
>>> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
>>> &gEfiPeiMemoryDiscoveredPpiGuid,
>>> @@ -554,7 +554,7 @@ InitializeDebugAgent (
>>> // Register for a callback once memory has been initialized.
>>> // If memery has been ready, the callback funtion will be invoked
>>> immediately
>>> //
>>> -Status = PeiServicesNotifyPpi (&mMemoryDiscoveredNotifyList[0]);
>>> +Status = PeiServicesNotifyPpi
>>> (&mDebugAgentMemoryDiscoveredNotifyList[0]);
>>> if (EFI_ERROR (Status)) {
>>>DEBUG ((EFI_D_ERROR, "DebugAgent: Failed to register memory
>>> discovered callback function!\n"));
>>>CpuDeadLoop ();
>>> --
>>> 2.6.3.windows.1
>>>
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>> GitPatchExtractor 1.1
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] MdeModulePkg/UefiPxeBcDxe: Question about IcmpErrorListenHandler in PxeBcImpl.c
在 12/7/2017 6:40 PM, Wu, Jiaxin 写道:
You say "IcmpErrorRcvToken is only used to get ICMP error from IP
layer", does that mean only ICMP error packets will go to
IcmpErrorListenHandler?
If it is the case, how do we make it? I can only find a simple
Ip4->Receive is called to receive IP4 packets; how are other types of
IP4 packets filtered out?
No, all of the *ICMP* packets with the same station IP address will go to
IcmpErrorListenHandler() callback function. Because PXE driver has already
configured the current IP protocol only receive the ICMP packets:
ZeroMem (&Private->Ip4ConfigData, sizeof (EFI_IP4_CONFIG_DATA));
Private->Ip4ConfigData.DefaultProtocol = EFI_IP_PROTO_ICMP;
Private->Ip4ConfigData.AcceptIcmpErrors = TRUE;
Ip4ConfigData.DefaultProtocol = EFI_IP_PROTO_ICMP;
So, it is only used to capture background ICMP packets (Including the ICMP
error message) with the same station IP address.
Many thanks; it explains my question clearly.
If it is not, why don't we need to filter the packets in
IcmpErrorListenHandler? If we recycle the packets in
IcmpErrorListenHandler, will it cause the upper layer of protocols fail
to fetch RxData?
IcmpErrorListenHandler() should filter the packets and only handle the ICMP
error message. But currently, the code logic is incorrect. I generated one
patch as attached one for your reference, can you help to verify whether it
works or not? (Ignore my previous suggestion check).
Sure we can verify it.
In my opinion, the RxData should be recycled since it has been recorded in
Mode->IcmpError.
Agree.
Thanks,
Gary (Heyi Guo)
Thanks,
Jiaxin
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Heyi Guo
Sent: Thursday, December 7, 2017 4:18 PM
To: Wu, Jiaxin ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Fu, Siyuan ; Dong,
Eric ; Zeng, Star
Subject: Re: [edk2] MdeModulePkg/UefiPxeBcDxe: Question about
IcmpErrorListenHandler in PxeBcImpl.c
Hi Jiaxin,
Thanks for your reply.
You say "IcmpErrorRcvToken is only used to get ICMP error from IP
layer", does that mean only ICMP error packets will go to
IcmpErrorListenHandler?
If it is the case, how do we make it? I can only find a simple
Ip4->Receive is called to receive IP4 packets; how are other types of
IP4 packets filtered out?
If it is not, why don't we need to filter the packets in
IcmpErrorListenHandler? If we recycle the packets in
IcmpErrorListenHandler, will it cause the upper layer of protocols fail
to fetch RxData?
Please forgive me if my questions are too stupid :)
Regards,
Gary (Heyi Guo)
在 12/7/2017 3:48 PM, Wu, Jiaxin 写道:
Hi Gary,
IcmpErrorRcvToken is only used to get ICMP error from IP layer, and the
data will be copied to Mode->IcmpError. So, I think the RxData should be
recycled.
Besides, EFI_IP_PROTO_ICMP should be also checked in the call function
but currently it's not:
if (!EFI_IP4_EQUAL (&RxData->Header->DestinationAddress, &Mode-
StationIp.v4)) {
//
// The dest address is not equal to Station Ip address, discard it.
//
goto CleanUp;
}
+if (&RxData->Header->Protocol != EFI_IP_PROTO_ICMP) {
+//
+// The protocol value in the header of the receveid packet should be
EFI_IP_PROTO_ICMP.
+//
+goto CleanUp;
+}
Thanks the report.
Thanks,
Jiaxin
-Original Message-
From: Guo Heyi [mailto:heyi@linaro.org]
Sent: Thursday, December 7, 2017 12:07 PM
To: edk2-devel@lists.01.org
Cc: Zeng, Star ; Dong, Eric ;
Ni,
Ruiyu ; Fu, Siyuan ; Wu, Jiaxin
Subject: MdeModulePkg/UefiPxeBcDxe: Question about
IcmpErrorListenHandler in PxeBcImpl.c
Hi folks,
In PxeBcImpl.c, we have IcmpErrorListenHandler which seems to process
ICMP errors. But in EfiPxeBcStart function, we can see Private-
IcmpErrorRcvToken.Event is only a common event and Ip4->Receive is
called to receive IP4 packets. So will IcmpErrorListenHandler receive all IP4
packets belonging to this network interface, or will it only receive ICMP
error
packets? If it is the latter situation, how do we make it?
The background of this question is that when we flush the network with
deprecated ICMP packets (type 15, 16, ...), RxData will not be recycled and
the list of UEFI events becomes longer and longer, which finally impacts
system performance a lot. If only error ICMP will be received by
IcmpErrorListenHandler, we'd like to patch it as below:
diff --git
a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
index 6d4f33f..f74b264 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
@@ -216,8 +216,6 @@ IcmpErrorListenHandlerDpc (
CopiedPointer += CopiedLen;
}
- goto Resume;
-
CleanUp:
gBS->SignalEvent (RxData->RecycleSignal);
We tested and it worked, but we are still not sure whether it will impact
other code in the net
Re: [edk2] [RFC] MdeModulePkg/Ip4Dxe: fix ICMP echo reply memory leak
Hi Siyuan and Jiaxin,
Thanks for your review; shall I generate a formal patch and post it
again, as well as making some commit message refinement?
Regards,
Gary (Heyi Guo)
在 12/7/2017 3:01 PM, Wu, Jiaxin 写道:
It's is good to me.
Reviewed-by: Jiaxin Wu
Thanks,
Jiaxin
-Original Message-
From: Heyi Guo [mailto:heyi@linaro.org]
Sent: Thursday, December 7, 2017 10:22 AM
To: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org
Cc: Heyi Guo ; Junbiao Hong
; Zeng, Star ; Dong, Eric
; Ni, Ruiyu ; Fu, Siyuan
; Wu, Jiaxin
Subject: [RFC] MdeModulePkg/Ip4Dxe: fix ICMP echo reply memory leak
When UEFI receives IPMP echo packets it will enter Ip4IcmpReplyEcho
function, and then call Ip4Output. However, if Ip4Output gets some
error and exits early, e.g. fails to find the route entry, memory
buffer of "Data" gets no chance to be freed and memory leak will be
caused. If there is such an attacker in the network, we will see UEFI
runs out of memory and system hangs.
Network stack code is so complicated that this is just a RFC to fix
this issue. Please provide your comments about this.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Junbiao Hong
Signed-off-by: Heyi Guo
Cc: Star Zeng
Cc: Eric Dong
Cc: Ruiyu Ni
Cc: Siyuan Fu
Cc: Jiaxin Wu
---
MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
index b4b0864..ed6bdbe 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
@@ -267,6 +267,9 @@ Ip4IcmpReplyEcho (
Ip4SysPacketSent,
NULL
);
+ if (EFI_ERROR (Status)) {
+NetbufFree (Data);
+ }
ON_EXIT:
NetbufFree (Packet);
--
2.7.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file
Hi Leif, May I know how this binary driver is described in DSC file and FDF file, and the [Rule.Common.DXE_DRIVER.BINARY] section ? I tried to add this driver into OvmfPkg, but failed to reproduce this failure. Thanks. Best Regards, Zhu Yonghong -Original Message- From: Leif Lindholm [mailto:leif.lindh...@linaro.org] Sent: Thursday, December 07, 2017 7:30 PM To: Zhu, Yonghong Cc: edk2-devel@lists.01.org; Feng, YunhuaX ; Gao, Liming Subject: Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file Hi Yonghong, This patch resolves the issue for the hikey platform, but not for (edk2-platforms/Platform/Hisilicon/)D03/D05. They fail with --- Generating FVMAIN FV ## #Return Value = 2 GenSec: ERROR 0001: Error opening file /work/git/tianocore/Build/D03/DEBUG_GCC5/AARCH64/Platform/Hisilicon/D03/Drivers/Net/SnpPlatform/SnpPlatform/OUTPUT/SnpPlatform.depex GenSec: ERROR 2000: Status is not successful --- and --- Generating FVMAIN FV ## Return Value = 2 GenSec: ERROR 0001: Error opening file /work/git/tianocore/Build/D05/RELEASE_GCC5/AARCH64/Platform/Hisilicon/D05/Drivers/Net/SnpPlatform/SnpPlatform/OUTPUT/SnpPlatform.depex GenFds.py... : error 7000: Failed to generate section GenSec: ERROR 2000: Status is not successful --- respectively. Again, reverting 37de70b7 makes the build successful again. Note that the failing drivers are binary, held in edk2-non-osi. Regards, Leif On Thu, Dec 07, 2017 at 02:51:17PM +0800, Yonghong Zhu wrote: > From: Yunhua Feng > > Filter the FileList when multiple genfds thread options is not enabled. > > Cc: Liming Gao > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Yunhua Feng > --- > BaseTools/Source/Python/GenFds/EfiSection.py | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/BaseTools/Source/Python/GenFds/EfiSection.py > b/BaseTools/Source/Python/GenFds/EfiSection.py > index 7b3b717191..4276945a10 100644 > --- a/BaseTools/Source/Python/GenFds/EfiSection.py > +++ b/BaseTools/Source/Python/GenFds/EfiSection.py > @@ -92,7 +92,8 @@ class EfiSection (EfiSectionClassObject): > elif os.path.exists(Filename): > FileList.append(Filename) > elif '.depex' in FfsInf.FinalTargetSuffixMap or FfsInf.Depex: > -FileList.append(Filename) > +if IsMakefile: > +FileList.append(Filename) > else: > FileList, IsSect = Section.Section.GetFileList(FfsInf, > self.FileType, self.FileExtension, Dict) > if IsSect : > -- > 2.12.2.windows.2 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 1/3] [edk2 EmbeddedPkg]:Implementation of secure boot and HTTP Image download
Linaro and RDK are working on standardizing the boot process for RDK STB
boxes using Uefi, as part of that implemented secure boot and HTTP image
download functionality.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: kalyan-nagabhirava
---
EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.dec | 52 ++
EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.inf | 81 +++
EmbeddedPkg/Library/RdkBootManagerLib/Include/DiskIo.h| 20 +
EmbeddedPkg/Library/RdkBootManagerLib/Include/HttpBoot.h | 7 +
EmbeddedPkg/Library/RdkBootManagerLib/Include/List.h | 52 ++
EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkBootManagerLib.h | 31 ++
EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkFile.h | 20 +
EmbeddedPkg/Library/RdkBootManagerLib/Include/SecureBoot.h| 40 ++
EmbeddedPkg/Library/RdkBootManagerLib/DiskIo.c| 536
++
EmbeddedPkg/Library/RdkBootManagerLib/HttpBoot.c | 315
+++
EmbeddedPkg/Library/RdkBootManagerLib/RdkFile.c | 259
+
EmbeddedPkg/Library/RdkBootManagerLib/SecureBoot.c| 577
12 files changed, 1990 insertions(+)
diff --git a/EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.dec
b/EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.dec
new file mode 100644
index ..2f84d1c56db3
--- /dev/null
+++ b/EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.dec
@@ -0,0 +1,52 @@
+#
+# Copyright (c) 2014-2017, Linaro Limited. All rights reserved.
+#
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD
License
+# which accompanies this distribution. The full text of the license may be
found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
+#
+
+[Defines]
+ DEC_SPECIFICATION = 0x00010019
+ PACKAGE_NAME = RdkPkg
+ PACKAGE_GUID = 2f1f2d5e-d9e1-4aa1-8eb9-fed94682e140
+ PACKAGE_VERSION= 0.1
+
+
+#
+# Include Section - list of Include Paths that are provided by this package.
+# Comments are used for Keywords and Module Types.
+#
+# Supported Module Types:
+# BASE SEC PEI_CORE PEIM DXE_CORE DXE_DRIVER DXE_RUNTIME_DRIVER
DXE_SMM_DRIVER DXE_SAL_DRIVER UEFI_DRIVER UEFI_APPLICATION
+#
+
+[Includes.common]
+ Include# Root include for the package
+
+[Guids.common]
+ gRdkTokenSpaceGuid= { 0x408c1892, 0xf11a, 0x40c7, { 0xaa, 0x5f,
0x0d, 0x16, 0xc8, 0xb2, 0x52, 0x59 } }
+ gRdkGlobalVariableGuid= { 0xc3253c90, 0xa24f, 0x4599, { 0xa6, 0x64,
0x1f, 0x88, 0x13, 0x77, 0x8f, 0xc9 } }
+
+[PcdsFixedAtBuild.common]
+ # Rdk Library
+ gRdkTokenSpaceGuid.PcdRdkRsvdReadSize|0x2000|UINT32|0x0201
+ gRdkTokenSpaceGuid.PcdRdkRsvdPartitionName|""|VOID*|0x0202
+ gRdkTokenSpaceGuid.PcdRdkSystemPartitionName|""|VOID*|0x0203
+ gRdkTokenSpaceGuid.PcdRdkConfFileName|""|VOID*|0x0204
+ gRdkTokenSpaceGuid.PcdRdkCmdLineArgs|""|VOID*|0x0213
+ gRdkTokenSpaceGuid.PcdRdkConfFileDevicePath|L""|VOID*|0x0214
+ gRdkTokenSpaceGuid.PcdAndroidFastbootNvmDevicePath|L""|VOID*|0x00300013
+
+ # GUID of RdkSecureBootLoader
+ gRdkTokenSpaceGuid.PcdRdkSecureBootFile|{ 0x0f, 0x93, 0xc7, 0xb2, 0xef,
0x07, 0x05, 0x43, 0xac, 0x4e, 0x1c, 0xe2, 0x08, 0x5a, 0x70, 0x31
}|VOID*|0x0100
+
+ # GUID of RdkDri
+ gRdkTokenSpaceGuid.PcdRdkDriFile|{ 0x8a, 0xa1, 0x1b, 0x08, 0x1e, 0xd7, 0xa7,
0x40, 0x99, 0xa9, 0xcd, 0xb8, 0x64, 0x63, 0x96, 0x6d }|VOID*|0x1000
+
+ # GUID of RdkDriSecureBootLoader
+ gRdkTokenSpaceGuid.PcdRdkDriSecureBootFile|{ 0xd7, 0xd1, 0x52, 0xdd, 0xe2,
0x0d, 0x52, 0x45, 0x98, 0xe0, 0x8d, 0xbe, 0xe4, 0x58, 0xa5, 0x02
}|VOID*|0x0010
diff --git a/EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.inf
b/EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.inf
new file mode 100644
index ..aee849db2333
--- /dev/null
+++ b/EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.inf
@@ -0,0 +1,81 @@
+#
+# Copyright (c) 2016-2017, Linaro Limited. All rights reserved.
+# Copyright (c) 2016-2017, comcast . All rights reserved.
+#
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD
License
+# which accompanies this distribution. The full text of the license may be
found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF AN
[edk2] [PATCH v2 0/3] Adding secure boot and HTTP image download features for Linux based platform
Linaro and RDK are working on standardizing the boot process for RDK STB boxes using Uefi. Added applications are reference implementation of RDK STB boot process on Arm platforms kalyan-nagabhirava (3): [edk2 EmbeddedPkg]:Implementation of secure boot and HTTP Image download EmbeddedPkg: secureboot application using RdkBootManagerLib EmbeddedPkg: Httpimage downlaod application EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.dec | 52 ++ EmbeddedPkg/Application/Dri/Dri.inf | 56 ++ EmbeddedPkg/Application/SecureBoot/SecureBoot.inf | 57 ++ EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.inf | 81 +++ EmbeddedPkg/Library/RdkBootManagerLib/Include/DiskIo.h| 20 + EmbeddedPkg/Library/RdkBootManagerLib/Include/HttpBoot.h | 7 + EmbeddedPkg/Library/RdkBootManagerLib/Include/List.h | 52 ++ EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkBootManagerLib.h | 31 ++ EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkFile.h | 20 + EmbeddedPkg/Library/RdkBootManagerLib/Include/SecureBoot.h| 40 ++ EmbeddedPkg/Application/Dri/Dri.c | 26 + EmbeddedPkg/Application/SecureBoot/SecureBoot.c | 30 + EmbeddedPkg/Library/RdkBootManagerLib/DiskIo.c| 536 ++ EmbeddedPkg/Library/RdkBootManagerLib/HttpBoot.c | 315 +++ EmbeddedPkg/Library/RdkBootManagerLib/RdkFile.c | 259 + EmbeddedPkg/Library/RdkBootManagerLib/SecureBoot.c| 577 16 files changed, 2159 insertions(+) create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.dec create mode 100644 EmbeddedPkg/Application/Dri/Dri.inf create mode 100644 EmbeddedPkg/Application/SecureBoot/SecureBoot.inf create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.inf create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/DiskIo.h create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/HttpBoot.h create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/List.h create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkBootManagerLib.h create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkFile.h create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/SecureBoot.h create mode 100644 EmbeddedPkg/Application/Dri/Dri.c create mode 100644 EmbeddedPkg/Application/SecureBoot/SecureBoot.c create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/DiskIo.c create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/HttpBoot.c create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/RdkFile.c create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/SecureBoot.c -- 2.15.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 2/3] EmbeddedPkg: secureboot application using RdkBootManagerLib
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: kalyan-nagabhirava
---
EmbeddedPkg/Application/SecureBoot/SecureBoot.inf | 57
EmbeddedPkg/Application/SecureBoot/SecureBoot.c | 30 +++
2 files changed, 87 insertions(+)
diff --git a/EmbeddedPkg/Application/SecureBoot/SecureBoot.inf
b/EmbeddedPkg/Application/SecureBoot/SecureBoot.inf
new file mode 100644
index ..90d1ee677f6a
--- /dev/null
+++ b/EmbeddedPkg/Application/SecureBoot/SecureBoot.inf
@@ -0,0 +1,57 @@
+#
+# Copyright (c) 2016-2017, Linaro Limited. All rights reserved.
+# Copyright (c) 2016-2017, comcast . All rights reserved.
+#
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD
License
+# which accompanies this distribution. The full text of the license may be
found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
+#
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+
+[Defines]
+ INF_VERSION = 0x00010006
+ BASE_NAME = RdkSecureLoader
+ FILE_GUID = b2c7930f-07ef-4305-ac4e-1ce2085a7031
+ MODULE_TYPE = UEFI_APPLICATION
+ VERSION_STRING = 1.0
+ ENTRY_POINT = SecureBootEntryPoint
+
+[Sources]
+ SecureBoot.c
+
+[Packages]
+ ArmPkg/ArmPkg.dec
+ ArmPlatformPkg/ArmPlatformPkg.dec
+ EmbeddedPkg/EmbeddedPkg.dec
+ MdePkg/MdePkg.dec
+ MdeModulePkg/MdeModulePkg.dec
+ ShellPkg/ShellPkg.dec
+ SecurityPkg/SecurityPkg.dec
+ CryptoPkg/CryptoPkg.dec
+ NetworkPkg/NetworkPkg.dec
+ EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.dec
+
+[Guids]
+ gEfiCertX509Guid
+ gEfiCertPkcs7Guid
+ gEfiCustomModeEnableGuid
+ gEfiImageSecurityDatabaseGuid
+ gFdtTableGuid
+ gRdkGlobalVariableGuid
+
+[LibraryClasses]
+ RdkBootManagerLib
+ UefiApplicationEntryPoint
+
+[Protocols]
+ gEfiBlockIoProtocolGuid
+ gEfiDevicePathToTextProtocolGuid
diff --git a/EmbeddedPkg/Application/SecureBoot/SecureBoot.c
b/EmbeddedPkg/Application/SecureBoot/SecureBoot.c
new file mode 100644
index ..51ac75835fd0
--- /dev/null
+++ b/EmbeddedPkg/Application/SecureBoot/SecureBoot.c
@@ -0,0 +1,30 @@
+/*
+# Copyright (c) 2016-2017, Linaro Limited. All rights reserved.
+#
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD
License
+# which accompanies this distribution. The full text of the license may be
found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
+#
+ */
+#include
+
+EFI_STATUS
+EFIAPI
+SecureBootEntryPoint (
+ IN EFI_HANDLEImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ EFI_STATUS Status;
+
+ Status = RdkSecureBoot (
+ImageHandle,
+SystemTable->BootServices
+ );
+
+ return Status;
+}
--
2.15.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2 3/3] EmbeddedPkg: Httpimage downlaod application
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: kalyan-nagabhirava
---
EmbeddedPkg/Application/Dri/Dri.inf | 56
EmbeddedPkg/Application/Dri/Dri.c | 26 +
2 files changed, 82 insertions(+)
diff --git a/EmbeddedPkg/Application/Dri/Dri.inf
b/EmbeddedPkg/Application/Dri/Dri.inf
new file mode 100644
index ..d6f24b48a6b3
--- /dev/null
+++ b/EmbeddedPkg/Application/Dri/Dri.inf
@@ -0,0 +1,56 @@
+#
+# Copyright (c) 2016-2017, Linaro Limited. All rights reserved.
+# Copyright (c) 2016-2017, comcast . All rights reserved.
+#
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD
License
+# which accompanies this distribution. The full text of the license may be
found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
+#
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+
+[Defines]
+ INF_VERSION = 0x00010006
+ BASE_NAME = RdkDriLoader
+ FILE_GUID = 081ba18a-d71e-40a7-99a9-cdb86463966d
+ MODULE_TYPE = UEFI_APPLICATION
+ VERSION_STRING = 1.0
+ ENTRY_POINT = DriEntryPoint
+
+[Sources]
+ Dri.c
+
+[Packages]
+ ArmPkg/ArmPkg.dec
+ ArmPlatformPkg/ArmPlatformPkg.dec
+ EmbeddedPkg/EmbeddedPkg.dec
+ MdePkg/MdePkg.dec
+ MdeModulePkg/MdeModulePkg.dec
+ ShellPkg/ShellPkg.dec
+ SecurityPkg/SecurityPkg.dec
+ CryptoPkg/CryptoPkg.dec
+ NetworkPkg/NetworkPkg.dec
+ EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.dec
+
+[Guids]
+ gEfiCertX509Guid
+ gEfiCertPkcs7Guid
+ gEfiCustomModeEnableGuid
+ gEfiImageSecurityDatabaseGuid
+ gFdtTableGuid
+
+[LibraryClasses]
+ RdkBootManagerLib
+ UefiApplicationEntryPoint
+
+[Protocols]
+ gEfiBlockIoProtocolGuid
+ gEfiDevicePathToTextProtocolGuid
diff --git a/EmbeddedPkg/Application/Dri/Dri.c
b/EmbeddedPkg/Application/Dri/Dri.c
new file mode 100644
index ..affbac08b602
--- /dev/null
+++ b/EmbeddedPkg/Application/Dri/Dri.c
@@ -0,0 +1,26 @@
+/*
+# Copyright (c) 2016-2017, Linaro Limited. All rights reserved.
+#
+# This program and the accompanying materials
+# are licensed and made available under the terms and conditions of the BSD
License
+# which accompanies this distribution. The full text of the license may be
found at
+# http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR
IMPLIED.
+#
+ */
+#include
+
+EFI_STATUS
+EFIAPI
+DriEntryPoint (
+ IN EFI_HANDLEImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ EFI_STATUS Status;
+
+ Status = RdkHttpBoot ();
+ return Status;
+}
--
2.15.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH edk2-platforms v2] Silicon/SynQuacer: enable coherent DMA for NETSEC and eMMC
On 1 December 2017 at 17:53, Ard Biesheuvel wrote: > On 1 December 2017 at 12:57, Leif Lindholm wrote: >> On Thu, Nov 30, 2017 at 06:53:55PM +, Ard Biesheuvel wrote: >>> As it turns out, it is surprisingly easy to configure both the NETSEC >>> and eMMC devices as cache coherent for DMA, given that they are both >>> behind the same SMMU which is already configured in passthrough mode >>> by the firmware running on the SCP. >>> >>> So update the static SMMU configuration to make memory accesses performed >>> by these devices inner shareable inner/outer writeback cacheable, which >>> makes them cache coherent with the CPUs. >>> >>> Contributed-under: TianoCore Contribution Agreement 1.1 >>> Signed-off-by: Ard Biesheuvel >> >> Looks fine to me: >> Reviewed-by: Leif Lindholm >> (If you want to hold back for Tested-by:s, feel free to.) >> > > Thanks. It actually depends on the patch that adds the EMMC driver > stack, which depends on the SD/MMC override patches for EDK2, so it > needs to wait anyway. Pushed as ce95ec196da05885844afb79bd2570c5cd9f6b27. I have reordered this with the EMMC driver patch, which will simply be DMA coherent from the start (but I kept the DT bit so the EMMC reference in the commit log is still relevant) ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH v2 0/3] Adding secure boot and HTTP image download features for Linux based platform
On 7 December 2017 at 13:34, kalyan-nagabhirava wrote: > Linaro and RDK are working on standardizing the boot process for RDK STB > boxes using Uefi. > Added applications are reference implementation of RDK STB boot process on > Arm platforms > Please don't add this to EmbeddedPkg. I thought we agreed to put this in edk2-platforms/Platform/Comcast? > kalyan-nagabhirava (3): > [edk2 EmbeddedPkg]:Implementation of secure boot and HTTP Image > download > EmbeddedPkg: secureboot application using RdkBootManagerLib > EmbeddedPkg: Httpimage downlaod application > > EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.dec | 52 ++ > EmbeddedPkg/Application/Dri/Dri.inf | 56 ++ > EmbeddedPkg/Application/SecureBoot/SecureBoot.inf | 57 ++ > EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.inf | 81 +++ > EmbeddedPkg/Library/RdkBootManagerLib/Include/DiskIo.h| 20 + > EmbeddedPkg/Library/RdkBootManagerLib/Include/HttpBoot.h | 7 + > EmbeddedPkg/Library/RdkBootManagerLib/Include/List.h | 52 ++ > EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkBootManagerLib.h | 31 ++ > EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkFile.h | 20 + > EmbeddedPkg/Library/RdkBootManagerLib/Include/SecureBoot.h| 40 ++ > EmbeddedPkg/Application/Dri/Dri.c | 26 + > EmbeddedPkg/Application/SecureBoot/SecureBoot.c | 30 + > EmbeddedPkg/Library/RdkBootManagerLib/DiskIo.c| 536 > ++ > EmbeddedPkg/Library/RdkBootManagerLib/HttpBoot.c | 315 > +++ > EmbeddedPkg/Library/RdkBootManagerLib/RdkFile.c | 259 > + > EmbeddedPkg/Library/RdkBootManagerLib/SecureBoot.c| 577 > > 16 files changed, 2159 insertions(+) > create mode 100644 > EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.dec > create mode 100644 EmbeddedPkg/Application/Dri/Dri.inf > create mode 100644 EmbeddedPkg/Application/SecureBoot/SecureBoot.inf > create mode 100644 > EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.inf > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/DiskIo.h > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/HttpBoot.h > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/List.h > create mode 100644 > EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkBootManagerLib.h > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkFile.h > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/SecureBoot.h > create mode 100644 EmbeddedPkg/Application/Dri/Dri.c > create mode 100644 EmbeddedPkg/Application/SecureBoot/SecureBoot.c > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/DiskIo.c > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/HttpBoot.c > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/RdkFile.c > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/SecureBoot.c > > -- > 2.15.0 > > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix duplicate symbol
Ard and Ersek:
On VS, static may make debug become hard. And, STATIC +
GLOBAL_REMOVE_IF_UNREFERENCED may failure on old VS before VS supports /Gw
option. So, I don't add static here.
I would like to separate static usage topic. We could discuss more and
summary the rule on how to use static in code. But for this build failure
issue, I prefer to fix it with this solution first. Is it OK to you?
Thanks
Liming
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, December 7, 2017 7:41 PM
> To: Laszlo Ersek
> Cc: Gao, Liming ; edk2-devel@lists.01.org; Kinney,
> Michael D ; Wu, Hao A
> ; Andrew Fish ; Jeff Fan
>
> Subject: Re: [edk2] [Patch] SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix
> duplicate symbol
>
> On 7 December 2017 at 11:18, Laszlo Ersek wrote:
> > On 12/07/17 09:46, Ard Biesheuvel wrote:
> >> On 7 December 2017 at 07:48, Liming Gao wrote:
> >>> From: Michael Kinney
> >>>
> >>> https://bugzilla.tianocore.org/show_bug.cgi?id=573
> >>> https://bugzilla.tianocore.org/show_bug.cgi?id=796
> >>>
> >>> The same issue is reported again by GCC. Resend this patch again.
> >>> This patch renames the duplicated function name to fix it.
> >>>
> >>> The SecPeiDebugAgentLib uses the global variable
> >>> mMemoryDiscoveredNotifyList for a PPI notification on
> >>> the Memory Discovered PPI. This same variable name is
> >>> used in the DxeIplPeim for the same PPI notification.
> >>>
> >>> The XCODE5 tool chain detects this duplicate symbol
> >>> when the OVMF platform is built with the flag
> >>> -D SOURCE_DEBUG_ENABLE.
> >>>
> >>> The fix is to rename this global variable in the
> >>> SecPeiDebugAgentLib library.
> >>>
> >>
> >> No, the fix is to make it STATIC unless it *needs* to be a global.
> >> Is that the case here?
> >
> > I agree with you (of course), but Mike explained earlier (if I recall
> > correctly -- and perhaps you remember too) that giving internal linkage
> > to global variables (i.e., making them STATIC) messes either with
> > debuggability under VS, or else defeats "GLOBAL_REMOVE_IF_UNREFERENCED".
> > (I'm not sure which one of the two.)
> >
>
> That doesn't quite ring a bell, but if that is the case, it deserves a
> mention.
>
> Note that STATIC variables are also removed when unreferenced (but may
> require a warning override like we have for GCC if it is only used
> from DEBUG () code). In any case, polluting the global namespace in a
> heterogeneous project like EDK2 is something that should only be done
> with good reason IMO.
>
> > So, I've settled on considering "extern by default" just another
> > peculiarity of edk2. *shrug* I'm just glad -fno-common catches bugs like
> > this!
> >
>
> Well, the thing is, external linkage defeats optimizations in the
> compiler, and also prevents it from emitting the variable into a
> read-only section even if it would otherwise be able to infer from the
> usage that the variable is never modified.
>
> > Reviewed-by: Laszlo Ersek
> >
> > (Obviously I'm not trying to dismiss your objection at all! Just stating
> > my view. If the patch is changed to STATIC, I'll R-b that version *more
> > happily* than this one.)
> >
> > Thanks!
> > Laszlo
> >
> >>
> >>
> >>> Cc: Andrew Fish
> >>> Cc: Jeff Fan
> >>> Cc: Hao Wu
> >>> Cc: Laszlo Ersek
> >>> Contributed-under: TianoCore Contribution Agreement 1.0
> >>> Signed-off-by: Michael D Kinney
> >>> Reviewed-by: Jeff Fan
> >>> ---
> >>> .../Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c |
> >>> 4 ++--
> >>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git
> >>> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
> >>> index b717e33..9f5223a 100644
> >>> ---
> >>> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
> >>> +++
> >>> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
> >>> @@ -32,7 +32,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_PPI_DESCRIPTOR
> >>>mVectorHandoffInf
> >>>}
> >>> };
> >>>
> >>> -GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR
> >>> mMemoryDiscoveredNotifyList[1] = {
> >>> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR
> >>> mDebugAgentMemoryDiscoveredNotifyList[1] = {
> >>>{
> >>> (EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK |
> >>> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
> >>> &gEfiPeiMemoryDiscoveredPpiGuid,
> >>> @@ -554,7 +554,7 @@ InitializeDebugAgent (
> >>> // Register for a callback once memory has been initialized.
> >>> // If memery has been ready, the callback funtion will be invoked
> >>> immediately
> >>> //
> >>> -Status = PeiServicesNotifyPpi (&mMemoryDiscoveredNotifyList[0]);
> >>> +Status = PeiServicesNotifyPpi
> >>> (&mDebugAgentMemoryDiscoveredNotifyList[0]);
> >>> if (EFI_ERROR (Status)) {
> >>>
Re: [edk2] [Patch] SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix duplicate symbol
On 7 December 2017 at 14:19, Gao, Liming wrote:
> Ard and Ersek:
> On VS, static may make debug become hard. And, STATIC +
> GLOBAL_REMOVE_IF_UNREFERENCED may failure on old VS before VS supports /Gw
> option. So, I don't add static here.
> I would like to separate static usage topic. We could discuss more and
> summary the rule on how to use static in code. But for this build failure
> issue, I prefer to fix it with this solution first. Is it OK to you?
>
Yes that is fine.
--
Ard.
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Thursday, December 7, 2017 7:41 PM
>> To: Laszlo Ersek
>> Cc: Gao, Liming ; edk2-devel@lists.01.org; Kinney,
>> Michael D ; Wu, Hao A
>> ; Andrew Fish ; Jeff Fan
>>
>> Subject: Re: [edk2] [Patch] SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix
>> duplicate symbol
>>
>> On 7 December 2017 at 11:18, Laszlo Ersek wrote:
>> > On 12/07/17 09:46, Ard Biesheuvel wrote:
>> >> On 7 December 2017 at 07:48, Liming Gao wrote:
>> >>> From: Michael Kinney
>> >>>
>> >>> https://bugzilla.tianocore.org/show_bug.cgi?id=573
>> >>> https://bugzilla.tianocore.org/show_bug.cgi?id=796
>> >>>
>> >>> The same issue is reported again by GCC. Resend this patch again.
>> >>> This patch renames the duplicated function name to fix it.
>> >>>
>> >>> The SecPeiDebugAgentLib uses the global variable
>> >>> mMemoryDiscoveredNotifyList for a PPI notification on
>> >>> the Memory Discovered PPI. This same variable name is
>> >>> used in the DxeIplPeim for the same PPI notification.
>> >>>
>> >>> The XCODE5 tool chain detects this duplicate symbol
>> >>> when the OVMF platform is built with the flag
>> >>> -D SOURCE_DEBUG_ENABLE.
>> >>>
>> >>> The fix is to rename this global variable in the
>> >>> SecPeiDebugAgentLib library.
>> >>>
>> >>
>> >> No, the fix is to make it STATIC unless it *needs* to be a global.
>> >> Is that the case here?
>> >
>> > I agree with you (of course), but Mike explained earlier (if I recall
>> > correctly -- and perhaps you remember too) that giving internal linkage
>> > to global variables (i.e., making them STATIC) messes either with
>> > debuggability under VS, or else defeats "GLOBAL_REMOVE_IF_UNREFERENCED".
>> > (I'm not sure which one of the two.)
>> >
>>
>> That doesn't quite ring a bell, but if that is the case, it deserves a
>> mention.
>>
>> Note that STATIC variables are also removed when unreferenced (but may
>> require a warning override like we have for GCC if it is only used
>> from DEBUG () code). In any case, polluting the global namespace in a
>> heterogeneous project like EDK2 is something that should only be done
>> with good reason IMO.
>>
>> > So, I've settled on considering "extern by default" just another
>> > peculiarity of edk2. *shrug* I'm just glad -fno-common catches bugs like
>> > this!
>> >
>>
>> Well, the thing is, external linkage defeats optimizations in the
>> compiler, and also prevents it from emitting the variable into a
>> read-only section even if it would otherwise be able to infer from the
>> usage that the variable is never modified.
>>
>> > Reviewed-by: Laszlo Ersek
>> >
>> > (Obviously I'm not trying to dismiss your objection at all! Just stating
>> > my view. If the patch is changed to STATIC, I'll R-b that version *more
>> > happily* than this one.)
>> >
>> > Thanks!
>> > Laszlo
>> >
>> >>
>> >>
>> >>> Cc: Andrew Fish
>> >>> Cc: Jeff Fan
>> >>> Cc: Hao Wu
>> >>> Cc: Laszlo Ersek
>> >>> Contributed-under: TianoCore Contribution Agreement 1.0
>> >>> Signed-off-by: Michael D Kinney
>> >>> Reviewed-by: Jeff Fan
>> >>> ---
>> >>> .../Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c |
>> >>> 4 ++--
>> >>> 1 file changed, 2 insertions(+), 2 deletions(-)
>> >>>
>> >>> diff --git
>> >>> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>> >>> index b717e33..9f5223a 100644
>> >>> ---
>> >>> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>> >>> +++
>> >>> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>> >>> @@ -32,7 +32,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_PPI_DESCRIPTOR
>> >>> mVectorHandoffInf
>> >>>}
>> >>> };
>> >>>
>> >>> -GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR
>> >>> mMemoryDiscoveredNotifyList[1] = {
>> >>> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR
>> >>> mDebugAgentMemoryDiscoveredNotifyList[1] = {
>> >>>{
>> >>> (EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK |
>> >>> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
>> >>> &gEfiPeiMemoryDiscoveredPpiGuid,
>> >>> @@ -554,7 +554,7 @@ InitializeDebugAgent (
>> >>> // Register for a callback once memory has been initialized.
>> >>> // If memery has been ready, the callback funtion will be invoked
>> >>> immediately
>> >>> //
>> >>> -Status = PeiServices
Re: [edk2] [PATCH v2 0/3] Adding secure boot and HTTP image download features for Linux based platform
yes Ard, but this is not platform sepecfic only application code, leif has given comments on this application , addressed his comments and send the patch. On 7 December 2017 at 19:36, Ard Biesheuvel wrote: > On 7 December 2017 at 13:34, kalyan-nagabhirava > wrote: > > Linaro and RDK are working on standardizing the boot process for RDK > STB boxes using Uefi. > > Added applications are reference implementation of RDK STB boot process > on Arm platforms > > > > Please don't add this to EmbeddedPkg. I thought we agreed to put this > in edk2-platforms/Platform/Comcast? > > > kalyan-nagabhirava (3): > > [edk2 EmbeddedPkg]:Implementation of secure boot and HTTP Image > > download > > EmbeddedPkg: secureboot application using RdkBootManagerLib > > EmbeddedPkg: Httpimage downlaod application > > > > EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.dec | > 52 ++ > > EmbeddedPkg/Application/Dri/Dri.inf | > 56 ++ > > EmbeddedPkg/Application/SecureBoot/SecureBoot.inf | > 57 ++ > > EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.inf | > 81 +++ > > EmbeddedPkg/Library/RdkBootManagerLib/Include/DiskIo.h| > 20 + > > EmbeddedPkg/Library/RdkBootManagerLib/Include/HttpBoot.h | > 7 + > > EmbeddedPkg/Library/RdkBootManagerLib/Include/List.h | > 52 ++ > > EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkBootManagerLib.h | > 31 ++ > > EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkFile.h | > 20 + > > EmbeddedPkg/Library/RdkBootManagerLib/Include/SecureBoot.h| > 40 ++ > > EmbeddedPkg/Application/Dri/Dri.c | > 26 + > > EmbeddedPkg/Application/SecureBoot/SecureBoot.c | > 30 + > > EmbeddedPkg/Library/RdkBootManagerLib/DiskIo.c| > 536 ++ > > EmbeddedPkg/Library/RdkBootManagerLib/HttpBoot.c | > 315 +++ > > EmbeddedPkg/Library/RdkBootManagerLib/RdkFile.c | > 259 + > > EmbeddedPkg/Library/RdkBootManagerLib/SecureBoot.c| > 577 > > 16 files changed, 2159 insertions(+) > > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/ > RdkBootManagerLib.dec > > create mode 100644 EmbeddedPkg/Application/Dri/Dri.inf > > create mode 100644 EmbeddedPkg/Application/SecureBoot/SecureBoot.inf > > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/ > RdkBootManagerLib.inf > > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/ > DiskIo.h > > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/ > HttpBoot.h > > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/List.h > > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/ > RdkBootManagerLib.h > > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/ > RdkFile.h > > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/ > SecureBoot.h > > create mode 100644 EmbeddedPkg/Application/Dri/Dri.c > > create mode 100644 EmbeddedPkg/Application/SecureBoot/SecureBoot.c > > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/DiskIo.c > > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/HttpBoot.c > > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/RdkFile.c > > create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/SecureBoot.c > > > > -- > > 2.15.0 > > > > ___ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel > -- regards, kalyan. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file
Hi Yonghong, I do not have the DSC that was used to build it. The FDF is https://github.com/tianocore/edk2-platforms/blob/master/Platform/Hisilicon/D05/D05.fdf#L250 Jason (cc) may be able to provide more information on the binary. Best Regards, Leif On Thu, Dec 07, 2017 at 12:55:48PM +, Zhu, Yonghong wrote: > Hi Leif, > > May I know how this binary driver is described in DSC file and FDF > file, and the [Rule.Common.DXE_DRIVER.BINARY] section ? > I tried to add this driver into OvmfPkg, but failed to reproduce > this failure. Thanks. > > Best Regards, > Zhu Yonghong > > > -Original Message- > From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > Sent: Thursday, December 07, 2017 7:30 PM > To: Zhu, Yonghong > Cc: edk2-devel@lists.01.org; Feng, YunhuaX ; Gao, > Liming > Subject: Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file > > Hi Yonghong, > > This patch resolves the issue for the hikey platform, but not for > (edk2-platforms/Platform/Hisilicon/)D03/D05. They fail with > > --- > Generating FVMAIN FV > ## > > #Return Value = 2 > GenSec: ERROR 0001: Error opening file > > > /work/git/tianocore/Build/D03/DEBUG_GCC5/AARCH64/Platform/Hisilicon/D03/Drivers/Net/SnpPlatform/SnpPlatform/OUTPUT/SnpPlatform.depex > GenSec: ERROR 2000: Status is not successful > --- > > and > > --- > Generating FVMAIN FV > ## > > > Return Value = 2 > GenSec: ERROR 0001: Error opening file > > > > /work/git/tianocore/Build/D05/RELEASE_GCC5/AARCH64/Platform/Hisilicon/D05/Drivers/Net/SnpPlatform/SnpPlatform/OUTPUT/SnpPlatform.depex > GenFds.py... > : error 7000: Failed to generate section > GenSec: ERROR 2000: Status is not successful > --- > > respectively. > > Again, reverting 37de70b7 makes the build successful again. > > Note that the failing drivers are binary, held in edk2-non-osi. > > Regards, > > Leif > > On Thu, Dec 07, 2017 at 02:51:17PM +0800, Yonghong Zhu wrote: > > From: Yunhua Feng > > > > Filter the FileList when multiple genfds thread options is not enabled. > > > > Cc: Liming Gao > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Yunhua Feng > > --- > > BaseTools/Source/Python/GenFds/EfiSection.py | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/BaseTools/Source/Python/GenFds/EfiSection.py > > b/BaseTools/Source/Python/GenFds/EfiSection.py > > index 7b3b717191..4276945a10 100644 > > --- a/BaseTools/Source/Python/GenFds/EfiSection.py > > +++ b/BaseTools/Source/Python/GenFds/EfiSection.py > > @@ -92,7 +92,8 @@ class EfiSection (EfiSectionClassObject): > > elif os.path.exists(Filename): > > FileList.append(Filename) > > elif '.depex' in FfsInf.FinalTargetSuffixMap or FfsInf.Depex: > > -FileList.append(Filename) > > +if IsMakefile: > > +FileList.append(Filename) > > else: > > FileList, IsSect = Section.Section.GetFileList(FfsInf, > > self.FileType, self.FileExtension, Dict) > > if IsSect : > > -- > > 2.12.2.windows.2 > > > > ___ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file
Hi Leif, I reproduced this issue. Thanks. I will try to fix it ASAP. Best Regards, Zhu Yonghong -Original Message- From: Leif Lindholm [mailto:leif.lindh...@linaro.org] Sent: Thursday, December 07, 2017 10:36 PM To: Zhu, Yonghong Cc: edk2-devel@lists.01.org; Feng, YunhuaX ; Gao, Liming ; jason.zh...@linaro.org Subject: Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file Hi Yonghong, I do not have the DSC that was used to build it. The FDF is https://github.com/tianocore/edk2-platforms/blob/master/Platform/Hisilicon/D05/D05.fdf#L250 Jason (cc) may be able to provide more information on the binary. Best Regards, Leif On Thu, Dec 07, 2017 at 12:55:48PM +, Zhu, Yonghong wrote: > Hi Leif, > > May I know how this binary driver is described in DSC file and FDF > file, and the [Rule.Common.DXE_DRIVER.BINARY] section ? > I tried to add this driver into OvmfPkg, but failed to reproduce this > failure. Thanks. > > Best Regards, > Zhu Yonghong > > > -Original Message- > From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > Sent: Thursday, December 07, 2017 7:30 PM > To: Zhu, Yonghong > Cc: edk2-devel@lists.01.org; Feng, YunhuaX ; > Gao, Liming > Subject: Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the > depex file > > Hi Yonghong, > > This patch resolves the issue for the hikey platform, but not for > (edk2-platforms/Platform/Hisilicon/)D03/D05. They fail with > > --- > Generating FVMAIN FV > ## > > #Return Value = 2 > GenSec: ERROR 0001: Error opening file > > > /work/git/tianocore/Build/D03/DEBUG_GCC5/AARCH64/Platform/Hisilicon/D0 > 3/Drivers/Net/SnpPlatform/SnpPlatform/OUTPUT/SnpPlatform.depex > GenSec: ERROR 2000: Status is not successful > --- > > and > > --- > Generating FVMAIN FV > ## > > > Return Value = 2 > GenSec: ERROR 0001: Error opening file > > > > /work/git/tianocore/Build/D05/RELEASE_GCC5/AARCH64/Platform/Hisilicon/ > D05/Drivers/Net/SnpPlatform/SnpPlatform/OUTPUT/SnpPlatform.depex > GenFds.py... > : error 7000: Failed to generate section > GenSec: ERROR 2000: Status is not successful > --- > > respectively. > > Again, reverting 37de70b7 makes the build successful again. > > Note that the failing drivers are binary, held in edk2-non-osi. > > Regards, > > Leif > > On Thu, Dec 07, 2017 at 02:51:17PM +0800, Yonghong Zhu wrote: > > From: Yunhua Feng > > > > Filter the FileList when multiple genfds thread options is not enabled. > > > > Cc: Liming Gao > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Yunhua Feng > > --- > > BaseTools/Source/Python/GenFds/EfiSection.py | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/BaseTools/Source/Python/GenFds/EfiSection.py > > b/BaseTools/Source/Python/GenFds/EfiSection.py > > index 7b3b717191..4276945a10 100644 > > --- a/BaseTools/Source/Python/GenFds/EfiSection.py > > +++ b/BaseTools/Source/Python/GenFds/EfiSection.py > > @@ -92,7 +92,8 @@ class EfiSection (EfiSectionClassObject): > > elif os.path.exists(Filename): > > FileList.append(Filename) > > elif '.depex' in FfsInf.FinalTargetSuffixMap or FfsInf.Depex: > > -FileList.append(Filename) > > +if IsMakefile: > > +FileList.append(Filename) > > else: > > FileList, IsSect = Section.Section.GetFileList(FfsInf, > > self.FileType, self.FileExtension, Dict) > > if IsSect : > > -- > > 2.12.2.windows.2 > > > > ___ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [RFC] MdePkg/Spi : Modify SPI Protocol strctures to make it more generic
Adding MdePkg maintainers: Mike and Liming.
Please always cc package maintainers (listed in Maintainers.txt).
/
Leif
On Thu, Dec 07, 2017 at 02:05:19PM +0530, Pankaj Bansal wrote:
> Issue_1: Currenty SPI IO and SPI HC protocol strcture is not equipped
> to handle all type of SPI commands
> e.g. QuadIo Read Command (0xEBh) in spansion flash S25FS512S will not
> work.
>
> Cause: Currenty SPI protocol describes a SPI transaction as combination
> of data and address and command, which would all be transmitted on
> same data bus (1 or 2 or 4).
>
> BUT when we have a case in which command is send one single data bus and
> address and data is sent one 4 data bus (like 0xEB in spansion), then
> this will not work with current strcture.
>
> Fix: Instead of making a single transaction, we can specify a group of
> transactions (called packet, terminology borrowed from I2c Protocol) in
> which each transaction specifies the data width, frequency, delay and
> read/write info.
>
> Issue_2: Specify additional data about SPI transaction (i.e. transaction
> is of type cmd, address, data, dummy etc). some controllers need this
> info to communicate with SPI peripheral. others can ignore this info.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Pankaj Bansal
> ---
> MdePkg/Include/Protocol/SpiHc.h | 15 +-
> MdePkg/Include/Protocol/SpiIo.h | 250 --
> 2 files changed, 104 insertions(+), 161 deletions(-)
>
> diff --git a/MdePkg/Include/Protocol/SpiHc.h b/MdePkg/Include/Protocol/SpiHc.h
> index 12fe5d2..65964bc 100644
> --- a/MdePkg/Include/Protocol/SpiHc.h
> +++ b/MdePkg/Include/Protocol/SpiHc.h
> @@ -110,8 +110,11 @@ typedef EFI_STATUS
>status.
>
>@param[in] ThisPointer to an EFI_SPI_HC_PROTOCOL structure.
> - @param[in] BusTransaction Pointer to a EFI_SPI_BUS_ TRANSACTION containing
> - the description of the SPI transaction to
> perform.
> + @param[in] SpiPeripheral The address of an EFI_SPI_PERIPHERAL data
> structure
> + describing the SPI peripheral from(to) which
> + read(write) transactions to be performed.
> + @param[in] RequestPacket Pointer to a EFI_SPI_REQUEST_PACKET containing
> + the description of the SPI transactions to
> perform.
>
>@retval EFI_SUCCESS The transaction completed successfully
>@retval EFI_BAD_BUFFER_SIZE The BusTransaction->WriteBytes value is
> invalid,
> @@ -124,7 +127,8 @@ typedef EFI_STATUS
> typedef EFI_STATUS
> (EFIAPI *EFI_SPI_HC_PROTOCOL_TRANSACTION) (
>IN CONST EFI_SPI_HC_PROTOCOL *This,
> - IN EFI_SPI_BUS_TRANSACTION*BusTransaction
> + IN CONST EFI_SPI_PERIPHERAL *SpiPeripheral;
> + IN EFI_SPI_REQUEST_PACKET *RequestPacket
>);
>
> ///
> @@ -135,7 +139,6 @@ struct _EFI_SPI_HC_PROTOCOL {
>/// Host control attributes, may have zero or more of the following set:
>/// * HC_SUPPORTS_WRITE_ONLY_OPERATIONS
>/// * HC_SUPPORTS_READ_ONLY_OPERATIONS
> - /// * HC_SUPPORTS_WRITE_THEN_READ_OPERATIONS
>/// * HC_TX_FRAME_IN_MOST_SIGNIFICANT_BITS
>/// - The SPI host controller requires the transmit frame to be in most
>/// significant bits instead of least significant bits.The host driver
> @@ -149,10 +152,6 @@ struct _EFI_SPI_HC_PROTOCOL {
>/// - The SPI controller supports a 2 - bit data bus
>/// * HC_SUPPORTS_4_B1T_DATA_BUS_WIDTH
>/// - The SPI controller supports a 4 - bit data bus
> - /// * HC_TRANSFER_SIZE_INCLUDES_OPCODE
> - /// - Transfer size includes the opcode byte
> - /// * HC_TRANSFER_SIZE_INCLUDES_ADDRESS
> - /// - Transfer size includes the 3 address bytes
>/// The SPI host controller must support full - duplex (receive while
>/// sending) operation.The SPI host controller must support a 1 - bit bus
>/// width.
> diff --git a/MdePkg/Include/Protocol/SpiIo.h b/MdePkg/Include/Protocol/SpiIo.h
> index 43e8045..507abb5 100644
> --- a/MdePkg/Include/Protocol/SpiIo.h
> +++ b/MdePkg/Include/Protocol/SpiIo.h
> @@ -27,147 +27,33 @@ typedef struct _EFI_SPI_IO_PROTOCOL EFI_SPI_IO_PROTOCOL;
> /// Note: The UEFI PI 1.6 specification does not specify values for the
> /// members below. The order matches the specification.
> ///
> +///
> +/// SPI peripheral transfer type
> +///
> +/// The EFI_SPI_TRANSACTION_TYPE describes the type of SPI transaction to
> either
> +/// send or recievce from SPI peripheral.
> +/// some SPI controllers need this information to complete a SPI operation
> +/// (which consists of one or many transactions)
> +///
> +/// for other controllers this field may be left 0 (SPI_TRANSACTION_NONE)
> +///
> typedef enum {
> - ///
> - /// Data flowing in both direction between the host and
> - /// SPI peripheral.ReadBytes must equal WriteBytes and both ReadBuffer and
> - /// WriteBuffer must be provided.
> - ///
> - SPI_TRANSACTION_FULL_DUPL
Re: [edk2] [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support for Watchdog driver
CoreSetWatchdogTimer() allows the error status for watchdog service.
> -Original Message-
> From: Udit Kumar [mailto:udit.ku...@nxp.com]
> Sent: Thursday, December 7, 2017 7:15 PM
> To: Gao, Liming ; Leif Lindholm
>
> Cc: Kinney, Michael D ; Meenakshi Aggarwal
> ;
> ard.biesheu...@linaro.org; edk2-devel@lists.01.org; Varun Sethi
>
> Subject: RE: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support
> for Watchdog driver
>
> Hi Liming,
>
> > DxeCore uses WatchdogTimer->SetTimerPeriod(). This service is implemented in
> > your driver.
>
> Callers of SetTimerPeriod are ignoring error reported.
> Is they assume this call will be perfect or they are ok in case some error on
> watchdog service.
>
>
> Regards
> Udit
>
> > -Original Message-
> > From: Gao, Liming [mailto:liming@intel.com]
> > Sent: Thursday, December 07, 2017 12:42 PM
> > To: Leif Lindholm ; Udit Kumar
> >
> > Cc: Kinney, Michael D ; Meenakshi Aggarwal
> > ; ard.biesheu...@linaro.org; edk2-
> > de...@lists.01.org; Varun Sethi
> > Subject: RE: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> > support
> > for Watchdog driver
> >
> > Leif:
> > I don't see the core driver uses WatchdogTimer->RegisterHandler(). When it
> > returns unsupported, it means the additional handler can't be registered.
> > DxeCore uses WatchdogTimer->SetTimerPeriod(). This service is implemented in
> > your driver.
> >
> > Watchdog protocol is defined in PI spec. Spec describes that this protocol
> > provides the services required to implement the Boot Service
> > SetWatchdogTimer(). It provides a service to set the amount of time to wait
> > before firing the watchdog timer, and it also provides a service to
> > register a
> > handler that is invoked when the watchdog timer fires. This protocol can
> > implement the watchdog timer by using the event and timer Boot Services, or
> > it
> > can make use of custom hardware. If no handler has been registered, or the
> > registered handler returns, then the system will be reset by calling the
> > Runtime
> > Service ResetSystem(). So, this protocol is required.
> >
> > Thanks
> > Liming
> > >-Original Message-
> > >From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > >Sent: Tuesday, December 05, 2017 7:06 PM
> > >To: Udit Kumar
> > >Cc: Gao, Liming ; Kinney, Michael D
> > >; Meenakshi Aggarwal
> > >; ard.biesheu...@linaro.org; edk2-
> > >de...@lists.01.org; Varun Sethi
> > >Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> > >support for Watchdog driver
> > >
> > >On Tue, Dec 05, 2017 at 05:07:00AM +, Udit Kumar wrote:
> > >> > I suggest return EFI_UNSUPPORTED for this case. The protocol
> > >implementation
> > >> > could return its status besides spec defined status.
> > >>
> > >> Thanks to help me , how core will treat this error 1/ Wdt not
> > >> available 2/ ignoring this error 3/ core is not registering handler I
> > >> guess 3 is valid,
> > >
> > >Looking at Core/Dxe/Misc/SetWatchdogTimer.c:
> > > //
> > > // Attempt to set the timeout
> > > //
> > > Status = gWatchdogTimer->SetTimerPeriod (gWatchdogTimer,
> > > MultU64x32 (Timeout, WATCHDOG_TIMER_CALIBRATE_PER_SECOND));
> > >
> > > //
> > > // Check for errors
> > > //
> > > if (EFI_ERROR (Status)) {
> > >return EFI_DEVICE_ERROR;
> > > }
> > >
> > >The SetWatchdogTimer() call would always return EFI_DEVICE_ERROR.
> > >
> > >> On side track, looks wdt is not used by core services then do we
> > >> really need this as part of arch protocol ?
> > >
> > >Yes, that was ultimately what I was implying with my question regarding
> > >whether this protocol is relevant for a watchdog that can only ever
> > >reset the system on timeout.
> > >
> > >The protocol looks to me to be designed to use a dedicated generic
> > >timer as backing for a software watchdog.
> > >
> > >Liming, Mike?
> > >
> > >If that is the case, then I agree this driver should probably not
> > >implement this protocol, but rather set up a timer event (or a
> > >dedicated timer) to stroke the watchdog.
> > >
> > >Regards,
> > >
> > >Leif
> > >
> > >> regards
> > >> Udit
> > >>
> > >> > -Original Message-
> > >> > From: Gao, Liming [mailto:liming@intel.com]
> > >> > Sent: Monday, December 04, 2017 8:53 PM
> > >> > To: Leif Lindholm ; Kinney, Michael D
> > >> >
> > >> > Cc: Meenakshi Aggarwal ;
> > >> > ard.biesheu...@linaro.org; edk2-devel@lists.01.org; Udit Kumar
> > >> > ; Varun Sethi
> > >> > Subject: RE: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP :
> > >> > Add
> > >support
> > >> > for Watchdog driver
> > >> >
> > >> > Leif:
> > >> > I suggest return EFI_UNSUPPORTED for this case. The protocol
> > >implementation
> > >> > could return its status besides spec defined status.
> > >> >
> > >> > Thanks
> > >> > Liming
> > >> > > -Original Message-
> > >> > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > >> > > Sent: Monday, December 4, 2017 10:36 PM
>
Re: [edk2] [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support for Watchdog driver
Leif:
I don't review the whole patch serial. Could you point your usage case on
watch dog timer protocol?
Thanks
Liming
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Thursday, December 7, 2017 7:04 PM
> To: Gao, Liming
> Cc: Udit Kumar ; Kinney, Michael D
> ; Meenakshi Aggarwal
> ; ard.biesheu...@linaro.org;
> edk2-devel@lists.01.org; Varun Sethi
> Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support
> for Watchdog driver
>
> Hi Liming,
>
> On Thu, Dec 07, 2017 at 07:11:38AM +, Gao, Liming wrote:
> > Leif:
> > I don't see the core driver uses
> > WatchdogTimer->RegisterHandler(). When it returns unsupported, it
> > means the additional handler can't be registered. DxeCore uses
> > WatchdogTimer->SetTimerPeriod(). This service is implemented in
> > your driver.
> >
> > Watchdog protocol is defined in PI spec. Spec describes that this
> > protocol provides the services required to implement the Boot
> > Service SetWatchdogTimer(). It provides a service to set the
> > amount of time to wait before firing the watchdog timer, and it
> > also provides a service to register a handler that is invoked when
> > the watchdog timer fires. This protocol can implement the watchdog
> > timer by using the event and timer Boot Services, or it can make
> > use of custom hardware. If no handler has been registered, or the
> > registered handler returns, then the system will be reset by
> > calling the Runtime Service ResetSystem(). So, this protocol is
> > required.
>
> I am not disputing that the protocol is not required. I am suggesting
> that this hardware watchdog _cannot_ be used to register a handler.
>
> If this hardware watchdog does not get updated in time, that causes an
> immediate hardware reset of the processor.
>
> Because of this, I believe EFI_WATCHDOG_TIMER_ARCH_PROTOCOL is not the
> appropriate way to make use of it.
>
> Please let me know whether you agree.
>
> Regards,
>
> Leif
>
> > Thanks
> > Liming
> > >-Original Message-
> > >From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > >Sent: Tuesday, December 05, 2017 7:06 PM
> > >To: Udit Kumar
> > >Cc: Gao, Liming ; Kinney, Michael D
> > >; Meenakshi Aggarwal
> > >; ard.biesheu...@linaro.org; edk2-
> > >de...@lists.01.org; Varun Sethi
> > >Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> > >support for Watchdog driver
> > >
> > >On Tue, Dec 05, 2017 at 05:07:00AM +, Udit Kumar wrote:
> > >> > I suggest return EFI_UNSUPPORTED for this case. The protocol
> > >implementation
> > >> > could return its status besides spec defined status.
> > >>
> > >> Thanks to help me , how core will treat this error
> > >> 1/ Wdt not available
> > >> 2/ ignoring this error
> > >> 3/ core is not registering handler
> > >> I guess 3 is valid,
> > >
> > >Looking at Core/Dxe/Misc/SetWatchdogTimer.c:
> > > //
> > > // Attempt to set the timeout
> > > //
> > > Status = gWatchdogTimer->SetTimerPeriod (gWatchdogTimer,
> > > MultU64x32 (Timeout, WATCHDOG_TIMER_CALIBRATE_PER_SECOND));
> > >
> > > //
> > > // Check for errors
> > > //
> > > if (EFI_ERROR (Status)) {
> > >return EFI_DEVICE_ERROR;
> > > }
> > >
> > >The SetWatchdogTimer() call would always return EFI_DEVICE_ERROR.
> > >
> > >> On side track, looks wdt is not used by core services then do we
> > >> really need this as part of arch protocol ?
> > >
> > >Yes, that was ultimately what I was implying with my question
> > >regarding whether this protocol is relevant for a watchdog that can
> > >only ever reset the system on timeout.
> > >
> > >The protocol looks to me to be designed to use a dedicated generic
> > >timer as backing for a software watchdog.
> > >
> > >Liming, Mike?
> > >
> > >If that is the case, then I agree this driver should probably not
> > >implement this protocol, but rather set up a timer event (or a
> > >dedicated timer) to stroke the watchdog.
> > >
> > >Regards,
> > >
> > >Leif
> > >
> > >> regards
> > >> Udit
> > >>
> > >> > -Original Message-
> > >> > From: Gao, Liming [mailto:liming@intel.com]
> > >> > Sent: Monday, December 04, 2017 8:53 PM
> > >> > To: Leif Lindholm ; Kinney, Michael D
> > >> >
> > >> > Cc: Meenakshi Aggarwal ;
> > >> > ard.biesheu...@linaro.org; edk2-devel@lists.01.org; Udit Kumar
> > >> > ; Varun Sethi
> > >> > Subject: RE: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> > >support
> > >> > for Watchdog driver
> > >> >
> > >> > Leif:
> > >> > I suggest return EFI_UNSUPPORTED for this case. The protocol
> > >implementation
> > >> > could return its status besides spec defined status.
> > >> >
> > >> > Thanks
> > >> > Liming
> > >> > > -Original Message-
> > >> > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > >> > > Sent: Monday, December 4, 2017 10:36 PM
> > >> > > To: Kinney, Michael D ; Gao, Liming
> > >> > >
> > >> > > Cc: Meenakshi Aggarwal ;
> >
Re: [edk2] [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add debug asserts
Hi,
I've compiled current HdLcd.c code with different optimisation levels for DEBUG
build using GCC 7.2.1, and the assembler code below was generated for:
ASSERT_EFI_ERROR (Status);
if (EFI_ERROR( Status )) {
return EFI_DEVICE_ERROR;
}
1. -O0 (default DEBUG option for AARCH64 before Ard's patch):
strx0, [x29, 72]//, Status
// r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:
ASSERT_EFI_ERROR (Status);
.loc 1 79 0
blDebugAssertEnabled//
andw0, w0, 255// _1, tmp150
cmpw0, 0// _1,
beq.L4//,
ldrx0, [x29, 72]// Status.9_2, Status
cmpx0, 0// Status.9_2,
bge.L4//,
2. -Os:
movx19, x0// Status,
// r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:
ASSERT_EFI_ERROR (Status);
.loc 1 79 0
blDebugAssertEnabled//
.LVL15:
tstw0, 255//
beq.L4//,
tbzx19, #63, .L8// Status,
3. -O3:
movx19, x0// Status,
.LVL14:
// r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:
ASSERT_EFI_ERROR (Status);
blDebugAssertEnabled//
.LVL15:
tstw0, 255//
beq.L5//,
tbnzx19, #63, .L26// Status,
with DebugAssertEnabled() compiled as:
DebugAssertEnabled:
.LFB4:
.loc 1 203 0
.cfi_startproc
// r:\edk2\MdePkg\Library\BaseDebugLibSerialPort\DebugLib.c:204: return
(BOOLEAN) ((PcdGet8(PcdDebugPropertyMask) &
DEBUG_PROPERTY_DEBUG_ASSERT_ENABLED) != 0);
.loc 1 204 0
adrpx0, _gPcd_FixedAtBuild_PcdDebugPropertyMask// tmp80,
addx0, x0, :lo12:_gPcd_FixedAtBuild_PcdDebugPropertyMask// tmp79,
tmp80,
ldrbw0, [x0]// _gPcd_FixedAtBuild_PcdDebugPropertyMask.4_1,
_gPcd_FixedAtBuild_PcdDebugPropertyMask
andw0, w0, 1// _3, _2,
cmpw0, 0// _3,
csetw0, ne// tmp82,
andw0, w0, 255// _4, tmp81
// r:\edk2\MdePkg\Library\BaseDebugLibSerialPort\DebugLib.c:205: }
.loc 1 205 0
ret
As you can see each "ASSERT_EFI_ERROR (Status)" macro requires
DebugAssertEnabled() call taking 8 instructions by itself + minimum 3
instructions (for -Os, -O3) for Status check, which will be performed by "if
(EFI_ERROR( Status ))" anyway.
Please correct me if I'm wrong assuming that placing
ASSERT_EFI_ERROR (Status)
inside
if (EFI_ERROR( Status )) {
statement is an optimisation improvement.
Thank you for your cooperation.
Alexei.
> >> > - ASSERT_EFI_ERROR (Status);
> >> >if (EFI_ERROR (Status)) {
> >> > +ASSERT_EFI_ERROR (Status);
> >>
> >> What is the point of this change?
> > [[Evan Lloyd]] It is a minor efficiency improvement. Since the ASSERT can
> only fire when the if condition is true, it removes a duplicated test from the
> main (non-error) code flow. This is irrelevant on hardware, but actually
> significant when running debug builds on an emulator environment.
> >
>
> Fair enough. But I'd prefer to finally fix the DEBUG vs NOOPT build targets
> for ARM/AARCH64. DEBUG was never intended to be -O0 (and it is not on
> X86 either).
>
> Code is complex enough as it is, and how to move trivial tests like this
> around for 'performance' reasons is a dimension I would like to avoid.
>[[Evan Lloyd]] I have no objection to the DEBUG build being updated from -O0.
>I strongly suspect that it was set to that because it reduced the incidence of
>the r18 problem that has now been fixed.
>However, I can certainly envisage circumstances when we might need to do an
>emulator run with -O0 used for the build - so the >
>reordering would still be beneficial.
From: edk2-devel on behalf of Evan Lloyd
Sent: 05 December 2017 20:46
To: Ard Biesheuvel
Cc: edk2-devel@lists.01.org; leif.lindh...@linaro.org@arm.com;
n...@arm.com@arm.com; ard.biesheu...@linaro.org@arm.com;
matteo.carl...@arm.com@arm.com
Subject: Re: [edk2] [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add
debug asserts
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 01 December 2017 17:35
> To: Evan Lloyd
> Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org@arm.com
> <"ard.biesheu...@linaro.org"@arm.com>;
> leif.lindh...@linaro.org@arm.com <"leif.lindh...@linaro.org"@arm.com>;
> matteo.carl...@arm.com@arm.com
> <"matteo.carl...@arm.com"@arm.com>; n...@arm.com@arm.com
> <"n...@arm.com"@arm.com>
> Subject: Re: [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add
> debug asserts
>
> On 1 December 2017 at 16:33, Evan Lloyd wrote:
> > Responses inline:
> >
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: 13 October 2017 08:33
> >> To: Evan Lloyd
> >> Cc: edk2-devel@lists.01.org; "ard.biesheu...@linaro.org"@arm.com;
> >> "leif.lindh...@linaro.org"@arm.com;
> >> "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com
> >> Subject: Re: [PATCH 04/19] ArmPlatformPkg: LcdGraph
Re: [edk2] [PATCH 1/2] MdePkg MmCommunication.h: Follow PI spec to update EFI_MM_COMMUNICATE
Reviewed-by: Liming Gao > -Original Message- > From: Zeng, Star > Sent: Wednesday, December 6, 2017 5:18 PM > To: edk2-devel@lists.01.org > Cc: Zeng, Star ; Yao, Jiewen ; > Gao, Liming ; Kinney, Michael D > > Subject: [PATCH 1/2] MdePkg MmCommunication.h: Follow PI spec to update > EFI_MM_COMMUNICATE > > Follow PI spec (>= 1.5) to add new return status code description > and make CommSize OPTIONAL. > > Cc: Jiewen Yao > Cc: Liming Gao > Cc: Michael D Kinney > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Star Zeng > --- > MdePkg/Include/Protocol/MmCommunication.h | 14 -- > 1 file changed, 12 insertions(+), 2 deletions(-) > > diff --git a/MdePkg/Include/Protocol/MmCommunication.h > b/MdePkg/Include/Protocol/MmCommunication.h > index 16450e3445b0..774686ba3e7f 100644 > --- a/MdePkg/Include/Protocol/MmCommunication.h > +++ b/MdePkg/Include/Protocol/MmCommunication.h > @@ -55,18 +55,28 @@ typedef struct _EFI_MM_COMMUNICATION_PROTOCOL > EFI_MM_COMMUNICATION_PROTOCOL; > >@param[in] ThisThe EFI_MM_COMMUNICATION_PROTOCOL instance. >@param[in] CommBuffer A pointer to the buffer to convey into > MMRAM. > - @param[in] CommSizeThe size of the data buffer being passed > in.On exit, the size of data > + @param[in] CommSizeThe size of the data buffer being passed > in. On exit, the size of data > being returned. Zero if the handler does > not wish to reply with any data. > + This parameter is optional and may be NULL. > >@retval EFI_SUCCESSThe message was successfully posted. >@retval EFI_INVALID_PARAMETER The CommBuffer was NULL. > + @retval EFI_BAD_BUFFER_SIZEThe buffer is too large for the MM > implementation. > + If this error is returned, the > MessageLength field > + in the CommBuffer header or the integer > pointed by > + CommSize, are updated to reflect the > maximum payload > + size the implementation can accommodate. > + @retval EFI_ACCESS_DENIED The CommunicateBuffer parameter or CommSize > parameter, > + if not omitted, are in address range that > cannot be > + accessed by the MM environment. > + > **/ > typedef > EFI_STATUS > (EFIAPI *EFI_MM_COMMUNICATE)( >IN CONST EFI_MM_COMMUNICATION_PROTOCOL *This, >IN OUT VOID *CommBuffer, > - IN OUT UINTN *CommSize > + IN OUT UINTN *CommSize OPTIONAL >); > > /// > -- > 2.7.0.windows.1 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add debug asserts
On 7 December 2017 at 14:55, Alexei Fedorov wrote:
> Hi,
>
> I've compiled current HdLcd.c code with different optimisation levels for
> DEBUG build using GCC 7.2.1, and the assembler code below was generated for:
>
> ASSERT_EFI_ERROR (Status);
> if (EFI_ERROR( Status )) {
> return EFI_DEVICE_ERROR;
> }
>
> -O0 (default DEBUG option for AARCH64 before Ard's patch):
>
>
> strx0, [x29, 72]//, Status
>
> // r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:
> ASSERT_EFI_ERROR (Status);
> .loc 1 79 0
> blDebugAssertEnabled//
> andw0, w0, 255// _1, tmp150
> cmpw0, 0// _1,
> beq.L4//,
> ldrx0, [x29, 72]// Status.9_2, Status
> cmpx0, 0// Status.9_2,
> bge.L4//,
>
> 2. -Os:
>
> movx19, x0// Status,
> // r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:
> ASSERT_EFI_ERROR (Status);
> .loc 1 79 0
> blDebugAssertEnabled//
> .LVL15:
> tstw0, 255//
> beq.L4//,
> tbzx19, #63, .L8// Status,
>
> 3. -O3:
>
> movx19, x0// Status,
> .LVL14:
> // r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:
> ASSERT_EFI_ERROR (Status);
> blDebugAssertEnabled//
> .LVL15:
> tstw0, 255//
> beq.L5//,
> tbnzx19, #63, .L26// Status,
>
> with DebugAssertEnabled() compiled as:
>
> DebugAssertEnabled:
> .LFB4:
> .loc 1 203 0
> .cfi_startproc
> // r:\edk2\MdePkg\Library\BaseDebugLibSerialPort\DebugLib.c:204: return
> (BOOLEAN) ((PcdGet8(PcdDebugPropertyMask) &
> DEBUG_PROPERTY_DEBUG_ASSERT_ENABLED) != 0);
> .loc 1 204 0
> adrpx0, _gPcd_FixedAtBuild_PcdDebugPropertyMask// tmp80,
> addx0, x0, :lo12:_gPcd_FixedAtBuild_PcdDebugPropertyMask//
> tmp79, tmp80,
> ldrbw0, [x0]// _gPcd_FixedAtBuild_PcdDebugPropertyMask.4_1,
> _gPcd_FixedAtBuild_PcdDebugPropertyMask
> andw0, w0, 1// _3, _2,
> cmpw0, 0// _3,
> csetw0, ne// tmp82,
> andw0, w0, 255// _4, tmp81
> // r:\edk2\MdePkg\Library\BaseDebugLibSerialPort\DebugLib.c:205: }
> .loc 1 205 0
> ret
>
> As you can see each "ASSERT_EFI_ERROR (Status)" macro requires
> DebugAssertEnabled() call taking 8 instructions by itself + minimum 3
> instructions (for -Os, -O3) for Status check, which will be performed by "if
> (EFI_ERROR( Status ))" anyway.
> Please correct me if I'm wrong assuming that placing
> ASSERT_EFI_ERROR (Status)
> inside
> if (EFI_ERROR( Status )) {
> statement is an optimisation improvement.
>
Thanks for digging this up. This appears to be an oversight in the
definition of the ASSERT_EFI_ERROR () macro, which is currently
defined as
#if !defined(MDEPKG_NDEBUG)
#define ASSERT_EFI_ERROR(StatusParameter) \
do { \
if (DebugAssertEnabled ()) { \
if (EFI_ERROR (StatusParameter)) { \
which is obviously the wrong way around, given that the compiler can
never optimize away the function call, due to its potential side
effects (which it doesn't have)
So I will propose to fix this, by swapping the two if () statements.
Please let me know if the issue is still reproducible with that patch
applied.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR
ASSERT_EFI_ERROR () is currently defined as
#if !defined(MDEPKG_NDEBUG)
#define ASSERT_EFI_ERROR(StatusParameter)
\
do {
\
if (DebugAssertEnabled ()) {
\
if (EFI_ERROR (StatusParameter)) {
\
DEBUG ((EFI_D_ERROR, "\nASSERT_EFI_ERROR (Status = %r)\n",
StatusParameter)); \
_ASSERT (!EFI_ERROR (StatusParameter));
\
}
\
}
\
} while (FALSE)
#else
#define ASSERT_EFI_ERROR(StatusParameter)
#endif
This is suboptimal, given that the DebugAssertEnabled () call in the
outer if must be executed unconditionally, since the compiler does not
know that it does not have any side effects. Instead, let's swap the
two ifs, and only call DebugAssertEnabled () if StatusParameter contains
an error value to begin with. Do the same for ASSERT_RETURN_ERROR
as well.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Reported-by: Alexei Fedorov
---
MdePkg/Include/Library/DebugLib.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/MdePkg/Include/Library/DebugLib.h
b/MdePkg/Include/Library/DebugLib.h
index 3a910e6a208b..8369c378e79c 100644
--- a/MdePkg/Include/Library/DebugLib.h
+++ b/MdePkg/Include/Library/DebugLib.h
@@ -337,8 +337,8 @@ DebugPrintLevelEnabled (
#if !defined(MDEPKG_NDEBUG)
#define ASSERT_EFI_ERROR(StatusParameter)
\
do {
\
- if (DebugAssertEnabled ()) {
\
-if (EFI_ERROR (StatusParameter)) {
\
+ if (EFI_ERROR (StatusParameter)) {
\
+if (DebugAssertEnabled ()) {
\
DEBUG ((EFI_D_ERROR, "\nASSERT_EFI_ERROR (Status = %r)\n",
StatusParameter)); \
_ASSERT (!EFI_ERROR (StatusParameter));
\
}
\
@@ -363,8 +363,8 @@ DebugPrintLevelEnabled (
#if !defined(MDEPKG_NDEBUG)
#define ASSERT_RETURN_ERROR(StatusParameter) \
do {\
- if (DebugAssertEnabled ()) { \
-if (RETURN_ERROR (StatusParameter)) { \
+ if (RETURN_ERROR (StatusParameter)) { \
+if (DebugAssertEnabled ()) {\
DEBUG ((DEBUG_ERROR, "\nASSERT_RETURN_ERROR (Status = %r)\n", \
StatusParameter)); \
_ASSERT (!RETURN_ERROR (StatusParameter));\
--
2.11.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR
On 7 December 2017 at 15:12, Ard Biesheuvel wrote:
> ASSERT_EFI_ERROR () is currently defined as
>
> #if !defined(MDEPKG_NDEBUG)
> #define ASSERT_EFI_ERROR(StatusParameter)
> \
> do {
> \
> if (DebugAssertEnabled ()) {
> \
> if (EFI_ERROR (StatusParameter)) {
> \
> DEBUG ((EFI_D_ERROR, "\nASSERT_EFI_ERROR (Status = %r)\n",
> StatusParameter)); \
> _ASSERT (!EFI_ERROR (StatusParameter));
> \
> }
> \
> }
> \
> } while (FALSE)
> #else
> #define ASSERT_EFI_ERROR(StatusParameter)
> #endif
>
> This is suboptimal, given that the DebugAssertEnabled () call in the
> outer if must be executed unconditionally, since the compiler does not
> know that it does not have any side effects. Instead, let's swap the
> two ifs, and only call DebugAssertEnabled () if StatusParameter contains
> an error value to begin with. Do the same for ASSERT_RETURN_ERROR
> as well.
>
I just noticed we could do the same for ASSERT () as well.
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel
> Reported-by: Alexei Fedorov
> ---
> MdePkg/Include/Library/DebugLib.h | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/MdePkg/Include/Library/DebugLib.h
> b/MdePkg/Include/Library/DebugLib.h
> index 3a910e6a208b..8369c378e79c 100644
> --- a/MdePkg/Include/Library/DebugLib.h
> +++ b/MdePkg/Include/Library/DebugLib.h
> @@ -337,8 +337,8 @@ DebugPrintLevelEnabled (
> #if !defined(MDEPKG_NDEBUG)
>#define ASSERT_EFI_ERROR(StatusParameter)
> \
> do {
> \
> - if (DebugAssertEnabled ()) {
> \
> -if (EFI_ERROR (StatusParameter)) {
> \
> + if (EFI_ERROR (StatusParameter)) {
> \
> +if (DebugAssertEnabled ()) {
> \
>DEBUG ((EFI_D_ERROR, "\nASSERT_EFI_ERROR (Status = %r)\n",
> StatusParameter)); \
>_ASSERT (!EFI_ERROR (StatusParameter));
> \
> }
> \
> @@ -363,8 +363,8 @@ DebugPrintLevelEnabled (
> #if !defined(MDEPKG_NDEBUG)
>#define ASSERT_RETURN_ERROR(StatusParameter) \
> do {\
> - if (DebugAssertEnabled ()) { \
> -if (RETURN_ERROR (StatusParameter)) { \
> + if (RETURN_ERROR (StatusParameter)) { \
> +if (DebugAssertEnabled ()) {\
>DEBUG ((DEBUG_ERROR, "\nASSERT_RETURN_ERROR (Status = %r)\n", \
> StatusParameter)); \
>_ASSERT (!RETURN_ERROR (StatusParameter));\
> --
> 2.11.0
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [RFC] Update EDKII Performance infrastructure based on ACPI FPDT table
From: "Gao, Liming" Current EDKII performance implementation bases on performance protocol to log and dump performance entry. There is no way to get the performance data in OS. ACPI FPDT table allows to insert the firmware extension record. If so, the detail boot performance data can be stored as FPDT record in ACPI FPDT table. It supports to dump performance data in UEFI Shell and OS both. This proposal is to update EDKII performance infrastructure to log and dump the performance entry as FPDT record in ACPI FPDT table. This RFC defines 5 edk2 FPDT records. Three of them are used for current Perf entry. Other two will be used with new Perf APIs. Now, this proposal focus on the performance internal implementation, but doesn't impact PerformanceLib interfaces and DP application output. So, there is no change required to any consumer code and platform DSC/FDF. New Perf APIs will be introduced later. The detail changes are list here. 0. Introduce PCD PcdEdkiiFpdtStringRecordEnableOnly to generate two style edk2 extended FPDT records. 1. When PCD PcdEdkiiFpdtStringRecordEnableOnly is set to FALSE, the different records will be used to store the different performance entry. EDKII provides two pair PERF APIs. PERF_START()/PERF_END() and PERF_START_EX()/PERF_END_EX(). Every PERF_START or PERF_END will be saved into one record. Every record has ProgressId to identify the perf entry. It has Guid to store the module GUID. Some records have String for Token/Module name. PERF_START_EX()/PERF_END_EX() has ProgressId parameter. They will be converted based on their ProgressId. PERF_START()/PERF_END() have no ProgressId parameter. Its token name will be converted to ProgressId. Below is the detail mapping between perf token name and records. "StartImage:" --> GUID_EVENT_RECORD with ProgressId 0x01~0x02 "PEIM"--> GUID_EVENT_RECORD with ProgressId 0x01~0x02 "LoadImage:" --> GUID_QWORD_EVENT_RECORD with ProgressId 0x03~0x04, its Qword is the loaded image count. "DB:Start:" START --> GUID_QWORD_EVENT_RECORD with ProgressId 0x05, its Qword is the controller handle. "DB:Start:" END --> GUID_QWORD_STRING_EVENT_RECORD with ProgressId 0x06, its Qword is the controller handle, its String is the device path of the controller handle. "DB:Support:" --> GUID_QWORD_EVENT_RECORD with ProgressId 0x07~0x08, its Qword is the controller handle. "DB:Stop:"--> GUID_QWORD_EVENT_RECORD with ProgressId 0x09~0x0A, its Qword is the controller handle. "SEC", "PEI" --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x50~0x51 (cross module), its String is the token name. "DXE", "BDS" --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x50~0x51 (cross module), its String is the token name. Non-null token--> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x40~0x41 (in module), its String is the token name. Non-null module --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x40~0x41 (in module), its String is the module name. Non-null Handle --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x40~0x41 (in module), its String is the module name from Handle Others are ignored. 2. When PCD PcdEdkiiFpdtStringRecordEnableOnly is set to TRUE, DYNAMIC_STRING_EVENT_RECORD will be used to store all performance entry. Every record has ProgressId to identify the perf entry. Its Guid stores the module or caller GUID. Its String stores Token/Module name. PERF_START_EX()/PERF_END_EX() has ProgressId parameter. They will be converted based on their ProgressId. PERF_START()/PERF_END() have no ProgressId parameter. Its token name will be converted to ProgressId. Below is the detail mapping. "StartImage:" --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x01~0x02 "PEIM" --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x01~0x02 "LoadImage:"--> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x03~0x04 "DB:Start:" --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x05~0x06 "DB:Support:" --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x07~0x08 "DB:Stop:" --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x09~0x0A "SEC", "PEI"--> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x50~0x51 (cross module), its String is the token name. "DXE", "BDS"--> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x50~0x51 (cross module), its String is the token name. Non-null token --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x40~0x41 (in module), its String is the token name. Non-null module --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x40~0x41
Re: [edk2] [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support for Watchdog driver
Liming,
https://www.mail-archive.com/edk2-devel@lists.01.org/msg32761.html
Search for WdogRegisterHandler.
This topic is entirely unrelated to any _usage_ of watchdog timer
protocol.
The topic is only whether it is reasonable to _implement_
EFI_WATCHDOG_TIMER_ARCH_PROTOCOL for a hardware watchdog that *cannot*
cause a callback to a handler function.
Because when the hardware watchdog times out, it triggers a hard
system reset, without any software interaction.
/
Leif
On Thu, Dec 07, 2017 at 02:54:08PM +, Gao, Liming wrote:
> Leif:
> I don't review the whole patch serial. Could you point your usage
> case on watch dog timer protocol?
>
> Thanks
> Liming
> > -Original Message-
> > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > Sent: Thursday, December 7, 2017 7:04 PM
> > To: Gao, Liming
> > Cc: Udit Kumar ; Kinney, Michael D
> > ; Meenakshi Aggarwal
> > ; ard.biesheu...@linaro.org;
> > edk2-devel@lists.01.org; Varun Sethi
> > Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> > support for Watchdog driver
> >
> > Hi Liming,
> >
> > On Thu, Dec 07, 2017 at 07:11:38AM +, Gao, Liming wrote:
> > > Leif:
> > > I don't see the core driver uses
> > > WatchdogTimer->RegisterHandler(). When it returns unsupported, it
> > > means the additional handler can't be registered. DxeCore uses
> > > WatchdogTimer->SetTimerPeriod(). This service is implemented in
> > > your driver.
> > >
> > > Watchdog protocol is defined in PI spec. Spec describes that this
> > > protocol provides the services required to implement the Boot
> > > Service SetWatchdogTimer(). It provides a service to set the
> > > amount of time to wait before firing the watchdog timer, and it
> > > also provides a service to register a handler that is invoked when
> > > the watchdog timer fires. This protocol can implement the watchdog
> > > timer by using the event and timer Boot Services, or it can make
> > > use of custom hardware. If no handler has been registered, or the
> > > registered handler returns, then the system will be reset by
> > > calling the Runtime Service ResetSystem(). So, this protocol is
> > > required.
> >
> > I am not disputing that the protocol is not required. I am suggesting
> > that this hardware watchdog _cannot_ be used to register a handler.
> >
> > If this hardware watchdog does not get updated in time, that causes an
> > immediate hardware reset of the processor.
> >
> > Because of this, I believe EFI_WATCHDOG_TIMER_ARCH_PROTOCOL is not the
> > appropriate way to make use of it.
> >
> > Please let me know whether you agree.
> >
> > Regards,
> >
> > Leif
> >
> > > Thanks
> > > Liming
> > > >-Original Message-
> > > >From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > > >Sent: Tuesday, December 05, 2017 7:06 PM
> > > >To: Udit Kumar
> > > >Cc: Gao, Liming ; Kinney, Michael D
> > > >; Meenakshi Aggarwal
> > > >; ard.biesheu...@linaro.org; edk2-
> > > >de...@lists.01.org; Varun Sethi
> > > >Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> > > >support for Watchdog driver
> > > >
> > > >On Tue, Dec 05, 2017 at 05:07:00AM +, Udit Kumar wrote:
> > > >> > I suggest return EFI_UNSUPPORTED for this case. The protocol
> > > >implementation
> > > >> > could return its status besides spec defined status.
> > > >>
> > > >> Thanks to help me , how core will treat this error
> > > >> 1/ Wdt not available
> > > >> 2/ ignoring this error
> > > >> 3/ core is not registering handler
> > > >> I guess 3 is valid,
> > > >
> > > >Looking at Core/Dxe/Misc/SetWatchdogTimer.c:
> > > > //
> > > > // Attempt to set the timeout
> > > > //
> > > > Status = gWatchdogTimer->SetTimerPeriod (gWatchdogTimer,
> > > > MultU64x32 (Timeout, WATCHDOG_TIMER_CALIBRATE_PER_SECOND));
> > > >
> > > > //
> > > > // Check for errors
> > > > //
> > > > if (EFI_ERROR (Status)) {
> > > >return EFI_DEVICE_ERROR;
> > > > }
> > > >
> > > >The SetWatchdogTimer() call would always return EFI_DEVICE_ERROR.
> > > >
> > > >> On side track, looks wdt is not used by core services then do we
> > > >> really need this as part of arch protocol ?
> > > >
> > > >Yes, that was ultimately what I was implying with my question
> > > >regarding whether this protocol is relevant for a watchdog that can
> > > >only ever reset the system on timeout.
> > > >
> > > >The protocol looks to me to be designed to use a dedicated generic
> > > >timer as backing for a software watchdog.
> > > >
> > > >Liming, Mike?
> > > >
> > > >If that is the case, then I agree this driver should probably not
> > > >implement this protocol, but rather set up a timer event (or a
> > > >dedicated timer) to stroke the watchdog.
> > > >
> > > >Regards,
> > > >
> > > >Leif
> > > >
> > > >> regards
> > > >> Udit
> > > >>
> > > >> > -Original Message-
> > > >> > From: Gao, Liming [mailto:liming@intel.com]
> > > >> > Sent: Monday, December 04, 2017 8:53
Re: [edk2] [PATCH v2 0/6] Add ARM support for VS2017
Hi Liming, On 2017.12.07 03:02, Gao, Liming wrote: This is the base step to enable VS2017 ARM tool chain. Then, user could use it and build ARM application first. Yes. Here, I have one question. VS2017 ARM requires 4096 alignment. So, why not add /FILEALIGN:4096 into tools_def.txt as the default linker option for ARM? I don't think we want to do that on account that this option does not need to be specified when building regular applications, and is currently only needed when building the QEMU firmware. So it's probably better to only specify it in the context where it is needed, rather than globally, especially as the documentation for /FILEALIGN [1] indicates that "By default, the linker does not use a fixed alignment size" which would tend to indicate that we might be better off letting the compiler decide what it should use on its own. Especially, forcing /FILEALIGN to 4K everywhere does appear to increase the size of the generated binaries. For instance, I'm seeing a RELEASE Shell.efi with a size of 762 KB without /FILEALIGN, vs. 792 KB with /FILEALIGN:4096. Thus, I think we should be conservative with regards to the global compiler options we add: if an option only seems to be needed for a single module (and especially, if that module has not yet been patched and reviewed for compilation), it should probably be specified for that module alone. As such, unless you or other people on this list have a strong opinion that /FILEALIGN:4096 should be global, I am currently not planning to resubmit a new patch that adds that option. Please let me know if you still think the patch should be altered. Regards, /Pete [1] https://docs.microsoft.com/en-gb/cpp/build/reference/filealign ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [Patch V2] BaseTools: Fix GenSec can't found the depex file
From: Yunhua Feng
Filter the FileList when multiple genfds thread options is not enabled.
Cc: Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng
Signed-off-by: Yonghong Zhu
---
BaseTools/Source/Python/GenFds/EfiSection.py | 5 +++--
BaseTools/Source/Python/GenFds/Section.py| 4 ++--
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/BaseTools/Source/Python/GenFds/EfiSection.py
b/BaseTools/Source/Python/GenFds/EfiSection.py
index 7b3b717..5029ec7 100644
--- a/BaseTools/Source/Python/GenFds/EfiSection.py
+++ b/BaseTools/Source/Python/GenFds/EfiSection.py
@@ -90,13 +90,14 @@ class EfiSection (EfiSectionClassObject):
if not self.Optional:
FileList.append(Filename)
elif os.path.exists(Filename):
FileList.append(Filename)
elif '.depex' in FfsInf.FinalTargetSuffixMap or FfsInf.Depex:
-FileList.append(Filename)
+if IsMakefile:
+FileList.append(Filename)
else:
-FileList, IsSect = Section.Section.GetFileList(FfsInf,
self.FileType, self.FileExtension, Dict)
+FileList, IsSect = Section.Section.GetFileList(FfsInf,
self.FileType, self.FileExtension, Dict, IsMakefile=IsMakefile)
if IsSect :
return FileList, self.Alignment
Index = 0
Align = self.Alignment
diff --git a/BaseTools/Source/Python/GenFds/Section.py
b/BaseTools/Source/Python/GenFds/Section.py
index 4c1aaac..463faa3 100644
--- a/BaseTools/Source/Python/GenFds/Section.py
+++ b/BaseTools/Source/Python/GenFds/Section.py
@@ -108,11 +108,11 @@ class Section (SectionClassObject):
# @param FileTypeFile type to get
# @param FileExtension File extension to get
# @param Dictdictionary contains macro and its value
# @retval tuple (File list, boolean)
#
-def GetFileList(FfsInf, FileType, FileExtension, Dict = {}):
+def GetFileList(FfsInf, FileType, FileExtension, Dict = {},
IsMakefile=False):
if FileType in Section.SectFileType.keys() :
IsSect = True
else :
IsSect = False
@@ -139,11 +139,11 @@ class Section (SectionClassObject):
else:
GenFdsGlobalVariable.VerboseLogger ("\nFile Type
\'%s\' of File %s in %s is not same with file type \'%s\' from Rule in FDF"
%(File.Type, File.File, FfsInf.InfFileName, FileType))
else:
GenFdsGlobalVariable.InfLogger ("\nCurrent ARCH \'%s\' of
File %s is not in the Support Arch Scope of %s specified by INF %s in FDF"
%(FfsInf.CurrentArch, File.File, File.Arch, FfsInf.InfFileName))
-if Suffix != None:
+if (not IsMakefile and Suffix != None and
os.path.exists(FfsInf.EfiOutputPath)) or (IsMakefile and Suffix != None):
#
# Get Makefile path and time stamp
#
MakefileDir = FfsInf.EfiOutputPath[:-len('OUTPUT')]
Makefile = os.path.join(MakefileDir, 'Makefile')
--
2.6.1.windows.1
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file
Hi Leif, I just sent out V2 patch. thanks. Best Regards, Zhu Yonghong -Original Message- From: Zhu, Yonghong Sent: Thursday, December 07, 2017 10:42 PM To: 'Leif Lindholm' Cc: edk2-devel@lists.01.org; Feng, YunhuaX ; Gao, Liming ; jason.zh...@linaro.org; Zhu, Yonghong Subject: RE: [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file Hi Leif, I reproduced this issue. Thanks. I will try to fix it ASAP. Best Regards, Zhu Yonghong -Original Message- From: Leif Lindholm [mailto:leif.lindh...@linaro.org] Sent: Thursday, December 07, 2017 10:36 PM To: Zhu, Yonghong Cc: edk2-devel@lists.01.org; Feng, YunhuaX ; Gao, Liming ; jason.zh...@linaro.org Subject: Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file Hi Yonghong, I do not have the DSC that was used to build it. The FDF is https://github.com/tianocore/edk2-platforms/blob/master/Platform/Hisilicon/D05/D05.fdf#L250 Jason (cc) may be able to provide more information on the binary. Best Regards, Leif On Thu, Dec 07, 2017 at 12:55:48PM +, Zhu, Yonghong wrote: > Hi Leif, > > May I know how this binary driver is described in DSC file and FDF > file, and the [Rule.Common.DXE_DRIVER.BINARY] section ? > I tried to add this driver into OvmfPkg, but failed to reproduce this > failure. Thanks. > > Best Regards, > Zhu Yonghong > > > -Original Message- > From: Leif Lindholm [mailto:leif.lindh...@linaro.org] > Sent: Thursday, December 07, 2017 7:30 PM > To: Zhu, Yonghong > Cc: edk2-devel@lists.01.org; Feng, YunhuaX ; > Gao, Liming > Subject: Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the > depex file > > Hi Yonghong, > > This patch resolves the issue for the hikey platform, but not for > (edk2-platforms/Platform/Hisilicon/)D03/D05. They fail with > > --- > Generating FVMAIN FV > ## > > #Return Value = 2 > GenSec: ERROR 0001: Error opening file > > > /work/git/tianocore/Build/D03/DEBUG_GCC5/AARCH64/Platform/Hisilicon/D0 > 3/Drivers/Net/SnpPlatform/SnpPlatform/OUTPUT/SnpPlatform.depex > GenSec: ERROR 2000: Status is not successful > --- > > and > > --- > Generating FVMAIN FV > ## > > > Return Value = 2 > GenSec: ERROR 0001: Error opening file > > > > /work/git/tianocore/Build/D05/RELEASE_GCC5/AARCH64/Platform/Hisilicon/ > D05/Drivers/Net/SnpPlatform/SnpPlatform/OUTPUT/SnpPlatform.depex > GenFds.py... > : error 7000: Failed to generate section > GenSec: ERROR 2000: Status is not successful > --- > > respectively. > > Again, reverting 37de70b7 makes the build successful again. > > Note that the failing drivers are binary, held in edk2-non-osi. > > Regards, > > Leif > > On Thu, Dec 07, 2017 at 02:51:17PM +0800, Yonghong Zhu wrote: > > From: Yunhua Feng > > > > Filter the FileList when multiple genfds thread options is not enabled. > > > > Cc: Liming Gao > > Contributed-under: TianoCore Contribution Agreement 1.1 > > Signed-off-by: Yunhua Feng > > --- > > BaseTools/Source/Python/GenFds/EfiSection.py | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/BaseTools/Source/Python/GenFds/EfiSection.py > > b/BaseTools/Source/Python/GenFds/EfiSection.py > > index 7b3b717191..4276945a10 100644 > > --- a/BaseTools/Source/Python/GenFds/EfiSection.py > > +++ b/BaseTools/Source/Python/GenFds/EfiSection.py > > @@ -92,7 +92,8 @@ class EfiSection (EfiSectionClassObject): > > elif os.path.exists(Filename): > > FileList.append(Filename) > > elif '.depex' in FfsInf.FinalTargetSuffixMap or FfsInf.Depex: > > -FileList.append(Filename) > > +if IsMakefile: > > +FileList.append(Filename) > > else: > > FileList, IsSect = Section.Section.GetFileList(FfsInf, > > self.FileType, self.FileExtension, Dict) > > if IsSect : > > -- > > 2.12.2.windows.2 > > > > ___ > > edk2-devel mailing list > > edk2-devel@lists.01.org > > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [platforms: PATCH 0/5] Armada 7k/8k files reorganization
Hi, I submit a long awaited file reorganization of Marvell Armada 7k/8k SoC family support. Armada 70x0 DB files remained in 'Platform/Marvell', SoC files, drivers, libraries, etc. were shifted to 'Silicon/Marvell'. Although there are no functional changes, other most significant modifications are: - use 'Armada7k8k' name/prefix, reflecting the SoC family properly - use 'Armada70x0Db' for a board files - move and rename the SPI master driver - move and rename the PciEmulation driver - rename output fd file for Armada70x0Db More details can be found in the commit log. In order to get a better overview, please check 'tree' command outputs below. The code is available in the github: https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/reorg-upstream-r20171207 I'm looking forward to your feedback. Best regards, Marcin NEW FILE STRUCTURE: == tree Platform/Marvell/ Platform/Marvell/ └── Armada70x0Db ├── Armada70x0Db.dsc └── Armada70x0Db.fdf == tree Silicon/Marvell/ Silicon/Marvell/ ├── Applications │ ├── EepromCmd │ │ ├── EepromCmd.c │ │ ├── EepromCmd.inf │ │ └── EepromCmd.uni │ ├── FirmwareUpdate │ │ ├── FUpdate.c │ │ ├── FUpdate.inf │ │ └── FUpdate.uni │ └── SpiTool │ ├── SpiFlashCmd.c │ ├── SpiFlashCmd.inf │ └── SpiFlashCmd.uni ├── Armada7k8k │ ├── Armada7k8k.dsc.inc │ ├── Drivers │ │ ├── Armada7k8kRngDxe │ │ │ ├── Armada7k8kRngDxe.c │ │ │ └── Armada7k8kRngDxe.inf │ │ └── PlatInitDxe │ │ ├── PlatInitDxe.c │ │ └── PlatInitDxe.inf │ └── Library │ ├── Armada7k8kLib │ │ ├── AArch64 │ │ │ └── ArmPlatformHelper.S │ │ ├── ARM │ │ │ └── ArmPlatformHelper.S │ │ ├── Armada7k8kLib.c │ │ ├── Armada7k8kLib.inf │ │ ├── Armada7k8kLibMem.c │ │ └── Armada7k8kLibMem.h │ ├── Armada7k8kMemoryInitPeiLib │ │ ├── Armada7k8kMemoryInitPeiLib.c │ │ └── Armada7k8kMemoryInitPeiLib.inf │ └── RealTimeClockLib │ ├── RealTimeClockLib.c │ ├── RealTimeClockLib.h │ └── RealTimeClockLib.inf ├── Documentation │ ├── Drivers │ │ ├── EepromDriver.txt │ │ ├── I2cDriver.txt │ │ └── SpiDriver.txt │ └── PortingGuide.txt ├── Drivers │ ├── I2c │ │ ├── Devices │ │ │ └── MvEeprom │ │ │ ├── MvEeprom.c │ │ │ ├── MvEeprom.h │ │ │ └── MvEeprom.inf │ │ └── MvI2cDxe │ │ ├── MvI2cDxe.c │ │ ├── MvI2cDxe.h │ │ └── MvI2cDxe.inf │ ├── Net │ │ ├── MvMdioDxe │ │ │ ├── MvMdioDxe.c │ │ │ ├── MvMdioDxe.h │ │ │ └── MvMdioDxe.inf │ │ ├── Phy │ │ │ └── MvPhyDxe │ │ │ ├── MvPhyDxe.c │ │ │ ├── MvPhyDxe.h │ │ │ └── MvPhyDxe.inf │ │ └── Pp2Dxe │ │ ├── Mvpp2Lib.c │ │ ├── Mvpp2Lib.h │ │ ├── Mvpp2LibHw.h │ │ ├── Pp2Dxe.c │ │ ├── Pp2Dxe.h │ │ └── Pp2Dxe.inf │ ├── NonDiscoverableDevices │ │ ├── MvNonDiscoverableDxe.c │ │ ├── MvNonDiscoverableDxe.inf │ │ └── NonDiscoverableDevicesDxe.inf │ ├── SdMmc │ │ └── XenonDxe │ │ ├── ComponentName.c │ │ ├── EmmcDevice.c │ │ ├── SdDevice.c │ │ ├── SdMmcPciHcDxe.c │ │ ├── SdMmcPciHcDxeExtra.uni │ │ ├── SdMmcPciHcDxe.h │ │ ├── SdMmcPciHcDxe.inf │ │ ├── SdMmcPciHcDxe.uni │ │ ├── SdMmcPciHci.c │ │ ├── SdMmcPciHci.h │ │ ├── XenonSdhci.c │ │ └── XenonSdhci.h │ └── Spi │ ├── Controllers │ │ ├── MvSpiOrionDxe.c │ │ ├── MvSpiOrionDxe.h │ │ └── MvSpiOrionDxe.inf │ ├── Devices │ │ ├── MvSpiFlash.c │ │ ├── MvSpiFlash.h │ │ └── MvSpiFlash.inf │ └── Variables │ ├── MvFvbDxe.c │ ├── MvFvbDxe.h │ └── MvFvbDxe.inf ├── Include │ ├── Library │ │ ├── MppLib.h │ │ ├── MvComPhyLib.h │ │ ├── MvHwDescLib.h │ │ └── UtmiPhyLib.h │ └── Protocol │ ├── Eeprom.h │ ├── Mdio.h │ ├── MvPhy.h │ ├── SpiFlash.h │ └── Spi.h ├── Library │ ├── ComPhyLib │ │ ├── ComPhyCp110.c │ │ ├── ComPhyLib.c │ │ ├── ComPhyLib.h │ │ ├── ComPhyLib.inf │ │ └── ComPhyMux.c │ ├── MppLib │ │ ├── MppLib.c │ │ └── MppLib.inf │ └── UtmiPhyLib │ ├── UtmiPhyLib.c │ ├── UtmiPhyLib.h │ └── UtmiPhyLib.inf └── Marvell.dec == Marcin Wojtas (5): Marvell: Reorganize file structure Marvell/Armada7k8k: Use '7k8k' prefix in the SoC drivers/libraries Marvell/Armada70x0Db: Rename fd file Marvell/Drivers: Rename SPI master driver Marvell/Drivers: Drop 'PciEmulation' naming Platform/Marvell/Applications/EepromCmd/EepromCmd.c | 397 -- Platform/Marvell/Applications/EepromCmd/EepromCmd.inf | 71
[edk2] [platforms: PATCH 3/5] Marvell/Armada70x0Db: Rename fd file
Hitherto fd file name was pretty generic, so use one, which reflects actual board model. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marcin Wojtas --- Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf index bba449a..3b0646e 100644 --- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf +++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf @@ -24,7 +24,7 @@ # -[FD.Armada70x0_EFI] +[FD.Armada70x0Db_EFI] BaseAddress = 0x|gArmTokenSpaceGuid.PcdFdBaseAddress # The base address of the Firmware in NOR Flash. Size = 0x0040|gArmTokenSpaceGuid.PcdFdSize # The size in bytes of the FLASH Device ErasePolarity = 1 -- 2.7.4 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [platforms: PATCH 4/5] Marvell/Drivers: Rename SPI master driver
Hitherto driver name was very generic. In order to be ready
for adding new SPI master drivers, use the controller's
traditional name (it's called SPI Orion in linux and
U-Boot) for files and the entry point.
Additionally, move the files to new 'Controllers' directory,
which is paralel to existing 'Devices' and 'Variables', so
that to make the separation more clear.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas
---
Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf| 2 +-
Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc | 2 +-
Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c | 432
Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.h | 148 +++
Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf | 73
Silicon/Marvell/Drivers/Spi/MvSpiDxe.c| 432
Silicon/Marvell/Drivers/Spi/MvSpiDxe.h| 148 ---
Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf | 73
8 files changed, 655 insertions(+), 655 deletions(-)
diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
index 3b0646e..6d57b9a 100644
--- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
+++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
@@ -110,7 +110,7 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
INF Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
INF MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
INF Silicon/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf
- INF Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
+ INF Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
INF Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
INF Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.inf
diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index 7d87766..0eb3ef3 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -411,7 +411,7 @@
Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
Silicon/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf
- Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
+ Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.inf
diff --git a/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c
b/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c
new file mode 100755
index 000..c657daf
--- /dev/null
+++ b/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c
@@ -0,0 +1,432 @@
+/***
+Copyright (C) 2016 Marvell International Ltd.
+
+Marvell BSD License Option
+
+If you received this File from Marvell, you may opt to use, redistribute and/or
+modify this File under the following licensing terms.
+Redistribution and use in source and binary forms, with or without
modification,
+are permitted provided that the following conditions are met:
+
+* Redistributions of source code must retain the above copyright notice,
+ this list of conditions and the following disclaimer.
+
+* Redistributions in binary form must reproduce the above copyright
+ notice, this list of conditions and the following disclaimer in the
+ documentation and/or other materials provided with the distribution.
+
+* Neither the name of Marvell nor the names of its contributors may be
+ used to endorse or promote products derived from this software without
+ specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
+ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+***/
+#include "MvSpiOrionDxe.h"
+
+SPI_MASTER *mSpiMasterInstance;
+
+STATIC
+EFI_STATUS
+SpiSetBaudRate (
+ IN SPI_DEVICE *Slave,
+ IN UINT32 CpuClock,
+ IN UINT32 MaxFreq
+ )
+{
+ UINT32 Spr, BestSpr, Sppr, BestSppr, ClockDivider, Match, Reg, MinBaudDiff;
+ UINTN SpiRegBase = Slave->HostRegisterBaseAddress;
+
+ MinBaudDiff = 0x;
+ BestSppr = 0;
+
+ //Spr is in range 1-15 and Sp
[edk2] [platforms: PATCH 2/5] Marvell/Armada7k8k: Use '7k8k' prefix in the SoC drivers/libraries
As a part of files reorganization, switch to using '7k8k' in all SoC-specific driver/library code instead of '70x0'/'7040', so that to ensure consistent naming for entire SoC family. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marcin Wojtas --- Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf | 2 +- Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc | 6 +- Silicon/Marvell/Armada7k8k/Drivers/Armada70x0RngDxe/Armada70x0RngDxe.c | 255 Silicon/Marvell/Armada7k8k/Drivers/Armada70x0RngDxe/Armada70x0RngDxe.inf | 47 Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.c | 255 Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.inf | 47 Silicon/Marvell/Armada7k8k/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S | 51 Silicon/Marvell/Armada7k8k/Library/Armada70x0Lib/ARM/ArmPlatformHelper.S | 77 -- Silicon/Marvell/Armada7k8k/Library/Armada70x0Lib/Armada70x0Lib.c | 132 -- Silicon/Marvell/Armada7k8k/Library/Armada70x0Lib/Armada70x0Lib.inf | 76 -- Silicon/Marvell/Armada7k8k/Library/Armada70x0Lib/Armada70x0LibMem.c | 204 Silicon/Marvell/Armada7k8k/Library/Armada70x0Lib/Armada70x0LibMem.h | 73 -- Silicon/Marvell/Armada7k8k/Library/Armada70x0MemoryInitPeiLib/Armada70x0MemoryInitPeiLib.c | 158 Silicon/Marvell/Armada7k8k/Library/Armada70x0MemoryInitPeiLib/Armada70x0MemoryInitPeiLib.inf | 46 Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/AArch64/ArmPlatformHelper.S | 51 Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/ARM/ArmPlatformHelper.S | 77 ++ Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLib.c | 132 ++ Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLib.inf | 76 ++ Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c | 204 Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.h | 73 ++ Silicon/Marvell/Armada7k8k/Library/Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.c | 158 Silicon/Marvell/Armada7k8k/Library/Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.inf | 46 22 files changed, 1123 insertions(+), 1123 deletions(-) diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf index f63f42d..bba449a 100644 --- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf +++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf @@ -112,7 +112,7 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c INF Silicon/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf INF Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf INF Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf - INF Silicon/Marvell/Armada7k8k/Drivers/Armada70x0RngDxe/Armada70x0RngDxe.inf + INF Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.inf # Variable services INF Silicon/Marvell/Drivers/Spi/Variables/MvFvbDxe.inf diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc index 75717e9..7d87766 100644 --- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc +++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc @@ -32,7 +32,7 @@ #SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. # [LibraryClasses.common] - ArmPlatformLib|Silicon/Marvell/Armada7k8k/Library/Armada70x0Lib/Armada70x0Lib.inf + ArmPlatformLib|Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLib.inf ComPhyLib|Silicon/Marvell/Library/ComPhyLib/ComPhyLib.inf MppLib|Silicon/Marvell/Library/MppLib/MppLib.inf NorFlashInfoLib|EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.inf @@ -149,7 +149,7 @@ PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf [LibraryClasses.common.SEC, LibraryClasses.common.PEIM] - MemoryInitPeiLib|Silicon/Marvell/Armada7k8k/Library/Armada70x0MemoryInitPeiLib/Armada70x0MemoryInitPeiLib.inf + MemoryInitPeiLib|Silicon/Marvell/Armada7k8k/Library/Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.inf BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf [LibraryClasses.common.DXE_CORE] @@ -413,7 +413,7 @@ Silicon/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf - Silicon/Marvell/Armada7k8k/Drivers/Armada70x0RngDxe/Armada70x0RngDxe.inf + Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngD
[edk2] [platforms: PATCH 5/5] Marvell/Drivers: Drop 'PciEmulation' naming
'PciEmulation' is not a proper naming for a driver, which
uses NonDiscoverableDeviceRegistrationLib for handling
the devices attached via internal bus of the SoC.
Rename it to MvNonDiscoverableDxe and move under
Silicon/Marvell/Drivers directory.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas
---
Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf | 4
+-
Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc | 4
+-
Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c | 195
Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf | 61
++
Silicon/Marvell/PciEmulation/PciEmulation.c | 195
Silicon/Marvell/PciEmulation/PciEmulation.inf | 61
--
6 files changed, 260 insertions(+), 260 deletions(-)
diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
index 6d57b9a..2bf409e 100644
--- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
+++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
@@ -135,8 +135,8 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
INF Silicon/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.inf
INF Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.inf
- # PciEmulation
- INF Silicon/Marvell/PciEmulation/PciEmulation.inf
+ # NonDiscoverableDevices
+ INF Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf
INF
MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
# SCSI
diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index 0eb3ef3..598810e 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -440,8 +440,8 @@
EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
- # PciEmulation
- Silicon/Marvell/PciEmulation/PciEmulation.inf
+ # NonDiscoverableDevices
+ Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf
MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
# SCSI
diff --git
a/Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
b/Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
new file mode 100644
index 000..abb2940
--- /dev/null
+++ b/Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
@@ -0,0 +1,195 @@
+/
+Copyright (C) 2016 Marvell International Ltd.
+
+Marvell BSD License Option
+
+If you received this File from Marvell, you may opt to use, redistribute and/or
+modify this File under the following licensing terms.
+Redistribution and use in source and binary forms, with or without
modification,
+are permitted provided that the following conditions are met:
+
+ * Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+
+ * Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in the
+documentation and/or other materials provided with the distribution.
+
+ * Neither the name of Marvell nor the names of its contributors may be
+used to endorse or promote products derived from this software without
+specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
+ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+***/
+
+#include
+
+#include
+#include
+#include
+#include
+
+#include
+
+DECLARE_A7K8K_NONDISCOVERABLE_TEMPLATE;
+
+//
+// Tables with used devices
+//
+STATIC UINT8 * CONST XhciDeviceTable = FixedPcdGetPtr (PcdPciEXhci);
+STATIC UINT8 * CONST AhciDeviceTable = FixedPcdGetPtr (PcdPciEAhci);
+STATIC UINT8 * CONST SdhciDeviceTable = FixedPcdGetPtr (PcdPciESdhci);
+
+//
+// NonDiscoverable devices registration
+//
+STATIC
+EFI_STATUS
+MvNonDiscoverableInitXhci (
+ )
+{
+ MVHW_NONDISCOVERABLE_DESC *Desc = &mA7k8kNonDiscoverableDescTemplate;
+
Re: [edk2] [platforms: PATCH 0/5] Armada 7k/8k files reorganization
On 7 December 2017 at 16:31, Marcin Wojtas wrote: > Hi, > > I submit a long awaited file reorganization of Marvell Armada 7k/8k > SoC family support. Armada 70x0 DB files remained in > 'Platform/Marvell', SoC files, drivers, libraries, etc. were > shifted to 'Silicon/Marvell'. > > Although there are no functional changes, other most significant > modifications are: > - use 'Armada7k8k' name/prefix, reflecting the SoC family properly > - use 'Armada70x0Db' for a board files > - move and rename the SPI master driver > - move and rename the PciEmulation driver > - rename output fd file for Armada70x0Db > > More details can be found in the commit log. In order to get a > better overview, please check 'tree' command outputs below. > > The code is available in the github: > https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/reorg-upstream-r20171207 > > I'm looking forward to your feedback. > Hi Marcin, Could you regenerate these patches with rename detection please? Thanks, Ard. > > NEW FILE STRUCTURE: > == > tree Platform/Marvell/ > > Platform/Marvell/ > └── Armada70x0Db > ├── Armada70x0Db.dsc > └── Armada70x0Db.fdf > > == > tree Silicon/Marvell/ > > Silicon/Marvell/ > ├── Applications > │ ├── EepromCmd > │ │ ├── EepromCmd.c > │ │ ├── EepromCmd.inf > │ │ └── EepromCmd.uni > │ ├── FirmwareUpdate > │ │ ├── FUpdate.c > │ │ ├── FUpdate.inf > │ │ └── FUpdate.uni > │ └── SpiTool > │ ├── SpiFlashCmd.c > │ ├── SpiFlashCmd.inf > │ └── SpiFlashCmd.uni > ├── Armada7k8k > │ ├── Armada7k8k.dsc.inc > │ ├── Drivers > │ │ ├── Armada7k8kRngDxe > │ │ │ ├── Armada7k8kRngDxe.c > │ │ │ └── Armada7k8kRngDxe.inf > │ │ └── PlatInitDxe > │ │ ├── PlatInitDxe.c > │ │ └── PlatInitDxe.inf > │ └── Library > │ ├── Armada7k8kLib > │ │ ├── AArch64 > │ │ │ └── ArmPlatformHelper.S > │ │ ├── ARM > │ │ │ └── ArmPlatformHelper.S > │ │ ├── Armada7k8kLib.c > │ │ ├── Armada7k8kLib.inf > │ │ ├── Armada7k8kLibMem.c > │ │ └── Armada7k8kLibMem.h > │ ├── Armada7k8kMemoryInitPeiLib > │ │ ├── Armada7k8kMemoryInitPeiLib.c > │ │ └── Armada7k8kMemoryInitPeiLib.inf > │ └── RealTimeClockLib > │ ├── RealTimeClockLib.c > │ ├── RealTimeClockLib.h > │ └── RealTimeClockLib.inf > ├── Documentation > │ ├── Drivers > │ │ ├── EepromDriver.txt > │ │ ├── I2cDriver.txt > │ │ └── SpiDriver.txt > │ └── PortingGuide.txt > ├── Drivers > │ ├── I2c > │ │ ├── Devices > │ │ │ └── MvEeprom > │ │ │ ├── MvEeprom.c > │ │ │ ├── MvEeprom.h > │ │ │ └── MvEeprom.inf > │ │ └── MvI2cDxe > │ │ ├── MvI2cDxe.c > │ │ ├── MvI2cDxe.h > │ │ └── MvI2cDxe.inf > │ ├── Net > │ │ ├── MvMdioDxe > │ │ │ ├── MvMdioDxe.c > │ │ │ ├── MvMdioDxe.h > │ │ │ └── MvMdioDxe.inf > │ │ ├── Phy > │ │ │ └── MvPhyDxe > │ │ │ ├── MvPhyDxe.c > │ │ │ ├── MvPhyDxe.h > │ │ │ └── MvPhyDxe.inf > │ │ └── Pp2Dxe > │ │ ├── Mvpp2Lib.c > │ │ ├── Mvpp2Lib.h > │ │ ├── Mvpp2LibHw.h > │ │ ├── Pp2Dxe.c > │ │ ├── Pp2Dxe.h > │ │ └── Pp2Dxe.inf > │ ├── NonDiscoverableDevices > │ │ ├── MvNonDiscoverableDxe.c > │ │ ├── MvNonDiscoverableDxe.inf > │ │ └── NonDiscoverableDevicesDxe.inf > │ ├── SdMmc > │ │ └── XenonDxe > │ │ ├── ComponentName.c > │ │ ├── EmmcDevice.c > │ │ ├── SdDevice.c > │ │ ├── SdMmcPciHcDxe.c > │ │ ├── SdMmcPciHcDxeExtra.uni > │ │ ├── SdMmcPciHcDxe.h > │ │ ├── SdMmcPciHcDxe.inf > │ │ ├── SdMmcPciHcDxe.uni > │ │ ├── SdMmcPciHci.c > │ │ ├── SdMmcPciHci.h > │ │ ├── XenonSdhci.c > │ │ └── XenonSdhci.h > │ └── Spi > │ ├── Controllers > │ │ ├── MvSpiOrionDxe.c > │ │ ├── MvSpiOrionDxe.h > │ │ └── MvSpiOrionDxe.inf > │ ├── Devices > │ │ ├── MvSpiFlash.c > │ │ ├── MvSpiFlash.h > │ │ └── MvSpiFlash.inf > │ └── Variables > │ ├── MvFvbDxe.c > │ ├── MvFvbDxe.h > │ └── MvFvbDxe.inf > ├── Include > │ ├── Library > │ │ ├── MppLib.h > │ │ ├── MvComPhyLib.h > │ │ ├── MvHwDescLib.h > │ │ └── UtmiPhyLib.h > │ └── Protocol > │ ├── Eeprom.h > │ ├── Mdio.h > │ ├── MvPhy.h > │ ├── SpiFlash.h > │ └── Spi.h > ├── Library > │ ├── ComPhyLib > │ │ ├── ComPhyCp110.c > │ │ ├── ComPhyLib.c > │ │ ├── ComPhyLib.h > │ │ ├── ComPhyLib.inf > │ │ └── ComPhyMux.c > │ ├── MppLib > │ │ ├── MppLib.c > │ │ └── MppLib.inf > │ └── UtmiPhyLib > │ ├── UtmiPhyLib.c > │ ├── UtmiPhyLib.h > │ └── UtmiPhyLib.inf > └── Marvell.dec > > == > > Marc
Re: [edk2] [Patch V2] BaseTools: Fix GenSec can't found the depex file
Thanks - with this patch all of my platforms build again.
On Thu, Dec 07, 2017 at 11:59:44PM +0800, Yonghong Zhu wrote:
> From: Yunhua Feng
>
> Filter the FileList when multiple genfds thread options is not enabled.
>
> Cc: Liming Gao
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Yunhua Feng
> Signed-off-by: Yonghong Zhu
Tested-by: Leif Lindholm
> ---
> BaseTools/Source/Python/GenFds/EfiSection.py | 5 +++--
> BaseTools/Source/Python/GenFds/Section.py| 4 ++--
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/BaseTools/Source/Python/GenFds/EfiSection.py
> b/BaseTools/Source/Python/GenFds/EfiSection.py
> index 7b3b717..5029ec7 100644
> --- a/BaseTools/Source/Python/GenFds/EfiSection.py
> +++ b/BaseTools/Source/Python/GenFds/EfiSection.py
> @@ -90,13 +90,14 @@ class EfiSection (EfiSectionClassObject):
> if not self.Optional:
> FileList.append(Filename)
> elif os.path.exists(Filename):
> FileList.append(Filename)
> elif '.depex' in FfsInf.FinalTargetSuffixMap or FfsInf.Depex:
> -FileList.append(Filename)
> +if IsMakefile:
> +FileList.append(Filename)
> else:
> -FileList, IsSect = Section.Section.GetFileList(FfsInf,
> self.FileType, self.FileExtension, Dict)
> +FileList, IsSect = Section.Section.GetFileList(FfsInf,
> self.FileType, self.FileExtension, Dict, IsMakefile=IsMakefile)
> if IsSect :
> return FileList, self.Alignment
>
> Index = 0
> Align = self.Alignment
> diff --git a/BaseTools/Source/Python/GenFds/Section.py
> b/BaseTools/Source/Python/GenFds/Section.py
> index 4c1aaac..463faa3 100644
> --- a/BaseTools/Source/Python/GenFds/Section.py
> +++ b/BaseTools/Source/Python/GenFds/Section.py
> @@ -108,11 +108,11 @@ class Section (SectionClassObject):
> # @param FileTypeFile type to get
> # @param FileExtension File extension to get
> # @param Dictdictionary contains macro and its value
> # @retval tuple (File list, boolean)
> #
> -def GetFileList(FfsInf, FileType, FileExtension, Dict = {}):
> +def GetFileList(FfsInf, FileType, FileExtension, Dict = {},
> IsMakefile=False):
> if FileType in Section.SectFileType.keys() :
> IsSect = True
> else :
> IsSect = False
>
> @@ -139,11 +139,11 @@ class Section (SectionClassObject):
> else:
> GenFdsGlobalVariable.VerboseLogger ("\nFile Type
> \'%s\' of File %s in %s is not same with file type \'%s\' from Rule in FDF"
> %(File.Type, File.File, FfsInf.InfFileName, FileType))
> else:
> GenFdsGlobalVariable.InfLogger ("\nCurrent ARCH \'%s\'
> of File %s is not in the Support Arch Scope of %s specified by INF %s in FDF"
> %(FfsInf.CurrentArch, File.File, File.Arch, FfsInf.InfFileName))
>
> -if Suffix != None:
> +if (not IsMakefile and Suffix != None and
> os.path.exists(FfsInf.EfiOutputPath)) or (IsMakefile and Suffix != None):
> #
> # Get Makefile path and time stamp
> #
> MakefileDir = FfsInf.EfiOutputPath[:-len('OUTPUT')]
> Makefile = os.path.join(MakefileDir, 'Makefile')
> --
> 2.6.1.windows.1
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [Patch] SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix duplicate symbol
Ard,
If the variable was not prepended with GLOBAL_REMOVE_IF_UNREFERENCED, I would
agree.
GLOBAL_REMOVE_IF_UNREFERENCED for some compilers is not compatible with static.
Mike
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of Ard Biesheuvel
> Sent: Thursday, December 7, 2017 12:47 AM
> To: Gao, Liming
> Cc: Wu, Hao A ; edk2-
> de...@lists.01.org; Andrew Fish ;
> Kinney, Michael D ; Laszlo
> Ersek ; Jeff Fan
> Subject: Re: [edk2] [Patch]
> SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix duplicate
> symbol
>
> On 7 December 2017 at 07:48, Liming Gao
> wrote:
> > From: Michael Kinney
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=573
> > https://bugzilla.tianocore.org/show_bug.cgi?id=796
> >
> > The same issue is reported again by GCC. Resend this
> patch again.
> > This patch renames the duplicated function name to fix
> it.
> >
> > The SecPeiDebugAgentLib uses the global variable
> > mMemoryDiscoveredNotifyList for a PPI notification on
> > the Memory Discovered PPI. This same variable name is
> > used in the DxeIplPeim for the same PPI notification.
> >
> > The XCODE5 tool chain detects this duplicate symbol
> > when the OVMF platform is built with the flag
> > -D SOURCE_DEBUG_ENABLE.
> >
> > The fix is to rename this global variable in the
> > SecPeiDebugAgentLib library.
> >
>
> No, the fix is to make it STATIC unless it *needs* to be
> a global.
> Is that the case here?
>
>
> > Cc: Andrew Fish
> > Cc: Jeff Fan
> > Cc: Hao Wu
> > Cc: Laszlo Ersek
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Michael D Kinney
>
> > Reviewed-by: Jeff Fan
> > ---
> >
> .../Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentL
> ib.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git
> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent
> /SecPeiDebugAgentLib.c
> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent
> /SecPeiDebugAgentLib.c
> > index b717e33..9f5223a 100644
> > ---
> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent
> /SecPeiDebugAgentLib.c
> > +++
> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent
> /SecPeiDebugAgentLib.c
> > @@ -32,7 +32,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED
> EFI_PEI_PPI_DESCRIPTOR mVectorHandoffInf
> >}
> > };
> >
> > -GLOBAL_REMOVE_IF_UNREFERENCED
> EFI_PEI_NOTIFY_DESCRIPTOR mMemoryDiscoveredNotifyList[1]
> = {
> > +GLOBAL_REMOVE_IF_UNREFERENCED
> EFI_PEI_NOTIFY_DESCRIPTOR
> mDebugAgentMemoryDiscoveredNotifyList[1] = {
> >{
> > (EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK |
> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
> > &gEfiPeiMemoryDiscoveredPpiGuid,
> > @@ -554,7 +554,7 @@ InitializeDebugAgent (
> > // Register for a callback once memory has been
> initialized.
> > // If memery has been ready, the callback funtion
> will be invoked immediately
> > //
> > -Status = PeiServicesNotifyPpi
> (&mMemoryDiscoveredNotifyList[0]);
> > +Status = PeiServicesNotifyPpi
> (&mDebugAgentMemoryDiscoveredNotifyList[0]);
> > if (EFI_ERROR (Status)) {
> >DEBUG ((EFI_D_ERROR, "DebugAgent: Failed to
> register memory discovered callback function!\n"));
> >CpuDeadLoop ();
> > --
> > 2.6.3.windows.1
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> > GitPatchExtractor 1.1
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add debug asserts
As expected with new ASSERT_EFI_ERROR () definition compiler generates 1
conditional branch at the start:
// r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:
ASSERT_EFI_ERROR (Status);
.loc 1 79 0
tbzx0, #63, .L4// Status,
From: Ard Biesheuvel
Sent: 07 December 2017 15:10:05
To: Alexei Fedorov
Cc: Evan Lloyd; edk2-devel@lists.01.org; leif.lindh...@linaro.org@arm.com;
n...@arm.com@arm.com; ard.biesheu...@linaro.org@arm.com;
matteo.carl...@arm.com@arm.com
Subject: Re: [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add debug
asserts
On 7 December 2017 at 14:55, Alexei Fedorov wrote:
> Hi,
>
> I've compiled current HdLcd.c code with different optimisation levels for
> DEBUG build using GCC 7.2.1, and the assembler code below was generated for:
>
> ASSERT_EFI_ERROR (Status);
> if (EFI_ERROR( Status )) {
> return EFI_DEVICE_ERROR;
> }
>
> -O0 (default DEBUG option for AARCH64 before Ard's patch):
>
>
> strx0, [x29, 72]//, Status
>
> // r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:
> ASSERT_EFI_ERROR (Status);
> .loc 1 79 0
> blDebugAssertEnabled//
> andw0, w0, 255// _1, tmp150
> cmpw0, 0// _1,
> beq.L4//,
> ldrx0, [x29, 72]// Status.9_2, Status
> cmpx0, 0// Status.9_2,
> bge.L4//,
>
> 2. -Os:
>
> movx19, x0// Status,
> // r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:
> ASSERT_EFI_ERROR (Status);
> .loc 1 79 0
> blDebugAssertEnabled//
> .LVL15:
> tstw0, 255//
> beq.L4//,
> tbzx19, #63, .L8// Status,
>
> 3. -O3:
>
> movx19, x0// Status,
> .LVL14:
> // r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:
> ASSERT_EFI_ERROR (Status);
> blDebugAssertEnabled//
> .LVL15:
> tstw0, 255//
> beq.L5//,
> tbnzx19, #63, .L26// Status,
>
> with DebugAssertEnabled() compiled as:
>
> DebugAssertEnabled:
> .LFB4:
> .loc 1 203 0
> .cfi_startproc
> // r:\edk2\MdePkg\Library\BaseDebugLibSerialPort\DebugLib.c:204: return
> (BOOLEAN) ((PcdGet8(PcdDebugPropertyMask) &
> DEBUG_PROPERTY_DEBUG_ASSERT_ENABLED) != 0);
> .loc 1 204 0
> adrpx0, _gPcd_FixedAtBuild_PcdDebugPropertyMask// tmp80,
> addx0, x0, :lo12:_gPcd_FixedAtBuild_PcdDebugPropertyMask//
> tmp79, tmp80,
> ldrbw0, [x0]// _gPcd_FixedAtBuild_PcdDebugPropertyMask.4_1,
> _gPcd_FixedAtBuild_PcdDebugPropertyMask
> andw0, w0, 1// _3, _2,
> cmpw0, 0// _3,
> csetw0, ne// tmp82,
> andw0, w0, 255// _4, tmp81
> // r:\edk2\MdePkg\Library\BaseDebugLibSerialPort\DebugLib.c:205: }
> .loc 1 205 0
> ret
>
> As you can see each "ASSERT_EFI_ERROR (Status)" macro requires
> DebugAssertEnabled() call taking 8 instructions by itself + minimum 3
> instructions (for -Os, -O3) for Status check, which will be performed by "if
> (EFI_ERROR( Status ))" anyway.
> Please correct me if I'm wrong assuming that placing
> ASSERT_EFI_ERROR (Status)
> inside
> if (EFI_ERROR( Status )) {
> statement is an optimisation improvement.
>
Thanks for digging this up. This appears to be an oversight in the
definition of the ASSERT_EFI_ERROR () macro, which is currently
defined as
#if !defined(MDEPKG_NDEBUG)
#define ASSERT_EFI_ERROR(StatusParameter) \
do { \
if (DebugAssertEnabled ()) { \
if (EFI_ERROR (StatusParameter)) { \
which is obviously the wrong way around, given that the compiler can
never optimize away the function call, due to its potential side
effects (which it doesn't have)
So I will propose to fix this, by swapping the two if () statements.
Please let me know if the issue is still reproducible with that patch
applied.
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.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR
Ard,
The reason for the current ordering is for size optimization.
The most common implementation of DebugAssertEnabled() uses
a FixedAtBuild PCD to determine if these are enabled. The
check of status can be optimized away if they are disabled.
If you reverse them, then the status check is always performed.
Mike
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, December 7, 2017 7:26 AM
> To: edk2-devel@lists.01.org
> Cc: Leif Lindholm ; Gao, Liming
> ; Evan Lloyd ;
> Kinney, Michael D ; Alexei
> Fedorov ; Ard Biesheuvel
>
> Subject: Re: [PATCH] MdePkg/DebugLib; swap if conditions
> in ASSERT_[EFI|RETURN]_ERROR
>
> On 7 December 2017 at 15:12, Ard Biesheuvel
> wrote:
> > ASSERT_EFI_ERROR () is currently defined as
> >
> > #if !defined(MDEPKG_NDEBUG)
> > #define ASSERT_EFI_ERROR(StatusParameter)
> \
> > do {
> \
> > if (DebugAssertEnabled ()) {
> \
> > if (EFI_ERROR (StatusParameter)) {
> \
> > DEBUG ((EFI_D_ERROR, "\nASSERT_EFI_ERROR
> (Status = %r)\n", StatusParameter)); \
> > _ASSERT (!EFI_ERROR (StatusParameter));
> \
> > }
> \
> > }
> \
> > } while (FALSE)
> > #else
> > #define ASSERT_EFI_ERROR(StatusParameter)
> > #endif
> >
> > This is suboptimal, given that the DebugAssertEnabled
> () call in the
> > outer if must be executed unconditionally, since the
> compiler does not
> > know that it does not have any side effects. Instead,
> let's swap the
> > two ifs, and only call DebugAssertEnabled () if
> StatusParameter contains
> > an error value to begin with. Do the same for
> ASSERT_RETURN_ERROR
> > as well.
> >
>
> I just noticed we could do the same for ASSERT () as
> well.
>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel
>
> > Reported-by: Alexei Fedorov
> > ---
> > MdePkg/Include/Library/DebugLib.h | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/MdePkg/Include/Library/DebugLib.h
> b/MdePkg/Include/Library/DebugLib.h
> > index 3a910e6a208b..8369c378e79c 100644
> > --- a/MdePkg/Include/Library/DebugLib.h
> > +++ b/MdePkg/Include/Library/DebugLib.h
> > @@ -337,8 +337,8 @@ DebugPrintLevelEnabled (
> > #if !defined(MDEPKG_NDEBUG)
> >#define ASSERT_EFI_ERROR(StatusParameter)
> \
> > do {
> \
> > - if (DebugAssertEnabled ()) {
> \
> > -if (EFI_ERROR (StatusParameter)) {
> \
> > + if (EFI_ERROR (StatusParameter)) {
> \
> > +if (DebugAssertEnabled ()) {
> \
> >DEBUG ((EFI_D_ERROR, "\nASSERT_EFI_ERROR
> (Status = %r)\n", StatusParameter)); \
> >_ASSERT (!EFI_ERROR (StatusParameter));
> \
> > }
> \
> > @@ -363,8 +363,8 @@ DebugPrintLevelEnabled (
> > #if !defined(MDEPKG_NDEBUG)
> >#define ASSERT_RETURN_ERROR(StatusParameter)
> \
> > do {
> \
> > - if (DebugAssertEnabled ()) {
> \
> > -if (RETURN_ERROR (StatusParameter)) {
> \
> > + if (RETURN_ERROR (StatusParameter)) {
> \
> > +if (DebugAssertEnabled ()) {
> \
> >DEBUG ((DEBUG_ERROR, "\nASSERT_RETURN_ERROR
> (Status = %r)\n", \
> > StatusParameter));
> \
> >_ASSERT (!RETURN_ERROR (StatusParameter));
> \
> > --
> > 2.11.0
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR
On 7 December 2017 at 17:01, Kinney, Michael D wrote: > Ard, > > The reason for the current ordering is for size optimization. > > The most common implementation of DebugAssertEnabled() uses > a FixedAtBuild PCD to determine if these are enabled. The > check of status can be optimized away if they are disabled. > If you reverse them, then the status check is always performed. > DebugAssertEnabled() is a function call that gets resolved at link time, and is not annotated as being free of side effects. So I agree that the implementation of that function could be optimized into a 'return true' or 'return false' depending on the compile time values of those PCDs, but the way the macro is defined currently, it still requires the function call to be made, and the conditional compare with a constant that follows will still be present in the code. What I am suggesting is to replace it with a comparison with a constant, and a conditional function call instead. This will not affect code size, but will only remove needless function calls at runtime. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR
On 7 December 2017 at 17:09, Ard Biesheuvel wrote: > On 7 December 2017 at 17:01, Kinney, Michael D > wrote: >> Ard, >> >> The reason for the current ordering is for size optimization. >> >> The most common implementation of DebugAssertEnabled() uses >> a FixedAtBuild PCD to determine if these are enabled. The >> check of status can be optimized away if they are disabled. >> If you reverse them, then the status check is always performed. >> > > DebugAssertEnabled() is a function call that gets resolved at link > time, and is not annotated as being free of side effects. So I agree > that the implementation of that function could be optimized into a > 'return true' or 'return false' depending on the compile time values > of those PCDs, but the way the macro is defined currently, it still > requires the function call to be made, and the conditional compare > with a constant that follows will still be present in the code. > > What I am suggesting is to replace it with a comparison with a > constant, and a conditional function call instead. This will not > affect code size, but will only remove needless function calls at > runtime. Please refer to these threads for details: https://lists.01.org/pipermail/edk2-devel/2017-December/018790.html https://lists.01.org/pipermail/edk2-devel/2017-December/018809.html ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR
Ard, With link time optimization, the current order produces smaller code. Without link time optimization, your patch will produce smaller code, but not as small as link time optimized code. Mike > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] > On Behalf Of Ard Biesheuvel > Sent: Thursday, December 7, 2017 9:13 AM > To: Kinney, Michael D > Cc: Alexei Fedorov ; edk2- > de...@lists.01.org; Gao, Liming ; > Leif Lindholm > Subject: Re: [edk2] [PATCH] MdePkg/DebugLib; swap if > conditions in ASSERT_[EFI|RETURN]_ERROR > > On 7 December 2017 at 17:09, Ard Biesheuvel > wrote: > > On 7 December 2017 at 17:01, Kinney, Michael D > > wrote: > >> Ard, > >> > >> The reason for the current ordering is for size > optimization. > >> > >> The most common implementation of DebugAssertEnabled() > uses > >> a FixedAtBuild PCD to determine if these are enabled. > The > >> check of status can be optimized away if they are > disabled. > >> If you reverse them, then the status check is always > performed. > >> > > > > DebugAssertEnabled() is a function call that gets > resolved at link > > time, and is not annotated as being free of side > effects. So I agree > > that the implementation of that function could be > optimized into a > > 'return true' or 'return false' depending on the > compile time values > > of those PCDs, but the way the macro is defined > currently, it still > > requires the function call to be made, and the > conditional compare > > with a constant that follows will still be present in > the code. > > > > What I am suggesting is to replace it with a comparison > with a > > constant, and a conditional function call instead. This > will not > > affect code size, but will only remove needless > function calls at > > runtime. > > Please refer to these threads for details: > https://lists.01.org/pipermail/edk2-devel/2017- > December/018790.html > https://lists.01.org/pipermail/edk2-devel/2017- > December/018809.html > ___ > edk2-devel mailing list > edk2-devel@lists.01.org > https://lists.01.org/mailman/listinfo/edk2-devel ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v2] BaseTools: align ERROR/WARNING/RETURN macros with MdePkg versions
BaseTools' BaseTypes.h defined the ENCODE_ERROR macro as #define ENCODE_ERROR(a) ((RETURN_STATUS)(MAX_BIT | (a))) whereas MdePkg defines it as #define ENCODE_ERROR(StatusCode) ((RETURN_STATUS)(MAX_BIT | (StatusCode))) When building with GCC 6.3 (at least) the former triggers "error: overflow in implicit constant conversion [-Werror=overflow]" Resolve this by aligning it with the latter one. This also requires aligning the BaseTools typedef of RETURN_STATUS with the MdePkg one: INTN -> UINTN. While at it, update adjacent ENCODE_WARNING and RETURN_ERROR as well. Add an explicit initialization of *Alignment to 0 in GenFfs.c GetAlignmentFromFile to get rid of a warning occuring with GCC after this change (-Werror=maybe-uninitialized). Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Leif Lindholm --- v2 updated for ENCODE_WARNING and RETURN_ERROR, as requested by Liming. BaseTools/Source/C/GenFfs/GenFfs.c| 1 + BaseTools/Source/C/Include/Common/BaseTypes.h | 8 2 files changed, 5 insertions(+), 4 deletions(-) diff --git a/BaseTools/Source/C/GenFfs/GenFfs.c b/BaseTools/Source/C/GenFfs/GenFfs.c index e2fb3e0d1e..3b4a9b7761 100644 --- a/BaseTools/Source/C/GenFfs/GenFfs.c +++ b/BaseTools/Source/C/GenFfs/GenFfs.c @@ -529,6 +529,7 @@ GetAlignmentFromFile(char *InFile, UINT32 *Alignment) InFileHandle= NULL; PeFileBuffer= NULL; + *Alignment = 0; memset (&ImageContext, 0, sizeof (ImageContext)); diff --git a/BaseTools/Source/C/Include/Common/BaseTypes.h b/BaseTools/Source/C/Include/Common/BaseTypes.h index 198647ab95..08b60bae11 100644 --- a/BaseTools/Source/C/Include/Common/BaseTypes.h +++ b/BaseTools/Source/C/Include/Common/BaseTypes.h @@ -170,15 +170,15 @@ // EFI Error Codes common to all execution phases // -typedef INTN RETURN_STATUS; +typedef UINTN RETURN_STATUS; /// /// Set the upper bit to indicate EFI Error. /// -#define ENCODE_ERROR(a) (MAX_BIT | (a)) +#define ENCODE_ERROR(a) ((RETURN_STATUS)(MAX_BIT | (a))) -#define ENCODE_WARNING(a)(a) -#define RETURN_ERROR(a) ((a) < 0) +#define ENCODE_WARNING(a)((RETURN_STATUS)(a)) +#define RETURN_ERROR(a) (((INTN)(RETURN_STATUS)(a)) < 0) #define RETURN_SUCCESS 0 #define RETURN_LOAD_ERRORENCODE_ERROR (1) -- 2.11.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR
On 7 December 2017 at 17:36, Kinney, Michael D
wrote:
> Ard,
>
> With link time optimization, the current order produces
> smaller code.
>
I don't think it does. You are essentially saying that
DebugAssertEnabled() may resolve to a link time constant FALSE under
LTO.
In that case, why would the following two statement not be equivalent?
if (FALSE && EFI_ERROR (StatusParameter)) {}
if (EFI_ERROR (StatusParameter) && FALSE) {}
(which is essentially what a nested if () resolves to)
In other words, the compiler is smart enough to drop the status check
in the second case, because it can see there are no side effects, and
the condition can never be made true anyway.
> Without link time optimization, your patch will produce
> smaller code, but not as small as link time optimized code.
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [platforms: PATCH 0/5] Armada 7k/8k files reorganization
Hi Ard, 2017-12-07 17:48 GMT+01:00 Ard Biesheuvel : > On 7 December 2017 at 16:31, Marcin Wojtas wrote: >> Hi, >> >> I submit a long awaited file reorganization of Marvell Armada 7k/8k >> SoC family support. Armada 70x0 DB files remained in >> 'Platform/Marvell', SoC files, drivers, libraries, etc. were >> shifted to 'Silicon/Marvell'. >> >> Although there are no functional changes, other most significant >> modifications are: >> - use 'Armada7k8k' name/prefix, reflecting the SoC family properly >> - use 'Armada70x0Db' for a board files >> - move and rename the SPI master driver >> - move and rename the PciEmulation driver >> - rename output fd file for Armada70x0Db >> >> More details can be found in the commit log. In order to get a >> better overview, please check 'tree' command outputs below. >> >> The code is available in the github: >> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/reorg-upstream-r20171207 >> >> I'm looking forward to your feedback. >> > > Hi Marcin, > > Could you regenerate these patches with rename detection please? > For every single operation I used 'git mv'. 'git status' showed the renaming properly and so does 'git show -M' on my branch. I'll search for better 'git format-patch' generation, but if you know the trick, please share. Best regards, Marcin > > > >> >> NEW FILE STRUCTURE: >> == >> tree Platform/Marvell/ >> >> Platform/Marvell/ >> └── Armada70x0Db >> ├── Armada70x0Db.dsc >> └── Armada70x0Db.fdf >> >> == >> tree Silicon/Marvell/ >> >> Silicon/Marvell/ >> ├── Applications >> │ ├── EepromCmd >> │ │ ├── EepromCmd.c >> │ │ ├── EepromCmd.inf >> │ │ └── EepromCmd.uni >> │ ├── FirmwareUpdate >> │ │ ├── FUpdate.c >> │ │ ├── FUpdate.inf >> │ │ └── FUpdate.uni >> │ └── SpiTool >> │ ├── SpiFlashCmd.c >> │ ├── SpiFlashCmd.inf >> │ └── SpiFlashCmd.uni >> ├── Armada7k8k >> │ ├── Armada7k8k.dsc.inc >> │ ├── Drivers >> │ │ ├── Armada7k8kRngDxe >> │ │ │ ├── Armada7k8kRngDxe.c >> │ │ │ └── Armada7k8kRngDxe.inf >> │ │ └── PlatInitDxe >> │ │ ├── PlatInitDxe.c >> │ │ └── PlatInitDxe.inf >> │ └── Library >> │ ├── Armada7k8kLib >> │ │ ├── AArch64 >> │ │ │ └── ArmPlatformHelper.S >> │ │ ├── ARM >> │ │ │ └── ArmPlatformHelper.S >> │ │ ├── Armada7k8kLib.c >> │ │ ├── Armada7k8kLib.inf >> │ │ ├── Armada7k8kLibMem.c >> │ │ └── Armada7k8kLibMem.h >> │ ├── Armada7k8kMemoryInitPeiLib >> │ │ ├── Armada7k8kMemoryInitPeiLib.c >> │ │ └── Armada7k8kMemoryInitPeiLib.inf >> │ └── RealTimeClockLib >> │ ├── RealTimeClockLib.c >> │ ├── RealTimeClockLib.h >> │ └── RealTimeClockLib.inf >> ├── Documentation >> │ ├── Drivers >> │ │ ├── EepromDriver.txt >> │ │ ├── I2cDriver.txt >> │ │ └── SpiDriver.txt >> │ └── PortingGuide.txt >> ├── Drivers >> │ ├── I2c >> │ │ ├── Devices >> │ │ │ └── MvEeprom >> │ │ │ ├── MvEeprom.c >> │ │ │ ├── MvEeprom.h >> │ │ │ └── MvEeprom.inf >> │ │ └── MvI2cDxe >> │ │ ├── MvI2cDxe.c >> │ │ ├── MvI2cDxe.h >> │ │ └── MvI2cDxe.inf >> │ ├── Net >> │ │ ├── MvMdioDxe >> │ │ │ ├── MvMdioDxe.c >> │ │ │ ├── MvMdioDxe.h >> │ │ │ └── MvMdioDxe.inf >> │ │ ├── Phy >> │ │ │ └── MvPhyDxe >> │ │ │ ├── MvPhyDxe.c >> │ │ │ ├── MvPhyDxe.h >> │ │ │ └── MvPhyDxe.inf >> │ │ └── Pp2Dxe >> │ │ ├── Mvpp2Lib.c >> │ │ ├── Mvpp2Lib.h >> │ │ ├── Mvpp2LibHw.h >> │ │ ├── Pp2Dxe.c >> │ │ ├── Pp2Dxe.h >> │ │ └── Pp2Dxe.inf >> │ ├── NonDiscoverableDevices >> │ │ ├── MvNonDiscoverableDxe.c >> │ │ ├── MvNonDiscoverableDxe.inf >> │ │ └── NonDiscoverableDevicesDxe.inf >> │ ├── SdMmc >> │ │ └── XenonDxe >> │ │ ├── ComponentName.c >> │ │ ├── EmmcDevice.c >> │ │ ├── SdDevice.c >> │ │ ├── SdMmcPciHcDxe.c >> │ │ ├── SdMmcPciHcDxeExtra.uni >> │ │ ├── SdMmcPciHcDxe.h >> │ │ ├── SdMmcPciHcDxe.inf >> │ │ ├── SdMmcPciHcDxe.uni >> │ │ ├── SdMmcPciHci.c >> │ │ ├── SdMmcPciHci.h >> │ │ ├── XenonSdhci.c >> │ │ └── XenonSdhci.h >> │ └── Spi >> │ ├── Controllers >> │ │ ├── MvSpiOrionDxe.c >> │ │ ├── MvSpiOrionDxe.h >> │ │ └── MvSpiOrionDxe.inf >> │ ├── Devices >> │ │ ├── MvSpiFlash.c >> │ │ ├── MvSpiFlash.h >> │ │ └── MvSpiFlash.inf >> │ └── Variables >> │ ├── MvFvbDxe.c >> │ ├── MvFvbDxe.h >> │ └── MvFvbDxe.inf >> ├── Include >> │ ├── Library >> │ │ ├── MppLib.h >> │ │ ├── MvComPhyLib.h >> │ │ ├── MvHwDescLib.h >> │ │ └── UtmiPhyLib.h >> │ └── Protocol >> │ ├── Eeprom.h >> │ ├── Mdio.h >> │ ├
Re: [edk2] [platforms: PATCH 0/5] Armada 7k/8k files reorganization
On 7 December 2017 at 19:06, Marcin Wojtas wrote: > Hi Ard, > > 2017-12-07 17:48 GMT+01:00 Ard Biesheuvel : >> On 7 December 2017 at 16:31, Marcin Wojtas wrote: >>> Hi, >>> >>> I submit a long awaited file reorganization of Marvell Armada 7k/8k >>> SoC family support. Armada 70x0 DB files remained in >>> 'Platform/Marvell', SoC files, drivers, libraries, etc. were >>> shifted to 'Silicon/Marvell'. >>> >>> Although there are no functional changes, other most significant >>> modifications are: >>> - use 'Armada7k8k' name/prefix, reflecting the SoC family properly >>> - use 'Armada70x0Db' for a board files >>> - move and rename the SPI master driver >>> - move and rename the PciEmulation driver >>> - rename output fd file for Armada70x0Db >>> >>> More details can be found in the commit log. In order to get a >>> better overview, please check 'tree' command outputs below. >>> >>> The code is available in the github: >>> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/reorg-upstream-r20171207 >>> >>> I'm looking forward to your feedback. >>> >> >> Hi Marcin, >> >> Could you regenerate these patches with rename detection please? >> > > For every single operation I used 'git mv'. 'git status' showed the > renaming properly and so does 'git show -M' on my branch. I'll search > for better 'git format-patch' generation, but if you know the trick, > please share. > git format-patch -M does not work for you? ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [platforms: PATCH 0/5] Armada 7k/8k files reorganization
2017-12-07 20:07 GMT+01:00 Ard Biesheuvel : > On 7 December 2017 at 19:06, Marcin Wojtas wrote: >> Hi Ard, >> >> 2017-12-07 17:48 GMT+01:00 Ard Biesheuvel : >>> On 7 December 2017 at 16:31, Marcin Wojtas wrote: Hi, I submit a long awaited file reorganization of Marvell Armada 7k/8k SoC family support. Armada 70x0 DB files remained in 'Platform/Marvell', SoC files, drivers, libraries, etc. were shifted to 'Silicon/Marvell'. Although there are no functional changes, other most significant modifications are: - use 'Armada7k8k' name/prefix, reflecting the SoC family properly - use 'Armada70x0Db' for a board files - move and rename the SPI master driver - move and rename the PciEmulation driver - rename output fd file for Armada70x0Db More details can be found in the commit log. In order to get a better overview, please check 'tree' command outputs below. The code is available in the github: https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/reorg-upstream-r20171207 I'm looking forward to your feedback. >>> >>> Hi Marcin, >>> >>> Could you regenerate these patches with rename detection please? >>> >> >> For every single operation I used 'git mv'. 'git status' showed the >> renaming properly and so does 'git show -M' on my branch. I'll search >> for better 'git format-patch' generation, but if you know the trick, >> please share. >> > > git format-patch -M does not work for you? 'git format-patch --find-renames' works fine. I'll issue v2 right away. Thanks, Marcin ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [platforms: PATCH v2 3/5] Marvell/Armada70x0Db: Rename fd file
Hitherto fd file name was pretty generic, so use one, which reflects actual board model. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marcin Wojtas --- Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf index bba449a..3b0646e 100644 --- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf +++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf @@ -24,7 +24,7 @@ # -[FD.Armada70x0_EFI] +[FD.Armada70x0Db_EFI] BaseAddress = 0x|gArmTokenSpaceGuid.PcdFdBaseAddress # The base address of the Firmware in NOR Flash. Size = 0x0040|gArmTokenSpaceGuid.PcdFdSize # The size in bytes of the FLASH Device ErasePolarity = 1 -- 2.7.4 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [platforms: PATCH v2 0/5] Armada 7k/8k files reorganization
Hi,
This is v2 of the reorganization - same commits with rename-aware
patch generation.
I submit a long awaited file reorganization of Marvell Armada 7k/8k
SoC family support. Armada 70x0 DB files remained in
'Platform/Marvell', SoC files, drivers, libraries, etc. were
shifted to 'Silicon/Marvell'.
Although there are no functional changes, other most significant
modifications are:
- use 'Armada7k8k' name/prefix, reflecting the SoC family properly
- use 'Armada70x0Db' for a board files
- move and rename the SPI master driver
- move and rename the PciEmulation driver
- rename output fd file for Armada70x0Db
More details can be found in the commit log. In order to get a
better overview, please check 'tree' command outputs below.
The code is available in the github:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/reorg-upstream-r20171207
I'm looking forward to your feedback.
Best regards,
Marcin
NEW FILE STRUCTURE:
==
tree Platform/Marvell/
Platform/Marvell/
└── Armada70x0Db
├── Armada70x0Db.dsc
└── Armada70x0Db.fdf
==
tree Silicon/Marvell/
Silicon/Marvell/
├── Applications
│ ├── EepromCmd
│ │ ├── EepromCmd.c
│ │ ├── EepromCmd.inf
│ │ └── EepromCmd.uni
│ ├── FirmwareUpdate
│ │ ├── FUpdate.c
│ │ ├── FUpdate.inf
│ │ └── FUpdate.uni
│ └── SpiTool
│ ├── SpiFlashCmd.c
│ ├── SpiFlashCmd.inf
│ └── SpiFlashCmd.uni
├── Armada7k8k
│ ├── Armada7k8k.dsc.inc
│ ├── Drivers
│ │ ├── Armada7k8kRngDxe
│ │ │ ├── Armada7k8kRngDxe.c
│ │ │ └── Armada7k8kRngDxe.inf
│ │ └── PlatInitDxe
│ │ ├── PlatInitDxe.c
│ │ └── PlatInitDxe.inf
│ └── Library
│ ├── Armada7k8kLib
│ │ ├── AArch64
│ │ │ └── ArmPlatformHelper.S
│ │ ├── ARM
│ │ │ └── ArmPlatformHelper.S
│ │ ├── Armada7k8kLib.c
│ │ ├── Armada7k8kLib.inf
│ │ ├── Armada7k8kLibMem.c
│ │ └── Armada7k8kLibMem.h
│ ├── Armada7k8kMemoryInitPeiLib
│ │ ├── Armada7k8kMemoryInitPeiLib.c
│ │ └── Armada7k8kMemoryInitPeiLib.inf
│ └── RealTimeClockLib
│ ├── RealTimeClockLib.c
│ ├── RealTimeClockLib.h
│ └── RealTimeClockLib.inf
├── Documentation
│ ├── Drivers
│ │ ├── EepromDriver.txt
│ │ ├── I2cDriver.txt
│ │ └── SpiDriver.txt
│ └── PortingGuide.txt
├── Drivers
│ ├── I2c
│ │ ├── Devices
│ │ │ └── MvEeprom
│ │ │ ├── MvEeprom.c
│ │ │ ├── MvEeprom.h
│ │ │ └── MvEeprom.inf
│ │ └── MvI2cDxe
│ │ ├── MvI2cDxe.c
│ │ ├── MvI2cDxe.h
│ │ └── MvI2cDxe.inf
│ ├── Net
│ │ ├── MvMdioDxe
│ │ │ ├── MvMdioDxe.c
│ │ │ ├── MvMdioDxe.h
│ │ │ └── MvMdioDxe.inf
│ │ ├── Phy
│ │ │ └── MvPhyDxe
│ │ │ ├── MvPhyDxe.c
│ │ │ ├── MvPhyDxe.h
│ │ │ └── MvPhyDxe.inf
│ │ └── Pp2Dxe
│ │ ├── Mvpp2Lib.c
│ │ ├── Mvpp2Lib.h
│ │ ├── Mvpp2LibHw.h
│ │ ├── Pp2Dxe.c
│ │ ├── Pp2Dxe.h
│ │ └── Pp2Dxe.inf
│ ├── NonDiscoverableDevices
│ │ ├── MvNonDiscoverableDxe.c
│ │ └── MvNonDiscoverableDxe.inf
│ ├── SdMmc
│ │ └── XenonDxe
│ │ ├── ComponentName.c
│ │ ├── EmmcDevice.c
│ │ ├── SdDevice.c
│ │ ├── SdMmcPciHcDxe.c
│ │ ├── SdMmcPciHcDxeExtra.uni
│ │ ├── SdMmcPciHcDxe.h
│ │ ├── SdMmcPciHcDxe.inf
│ │ ├── SdMmcPciHcDxe.uni
│ │ ├── SdMmcPciHci.c
│ │ ├── SdMmcPciHci.h
│ │ ├── XenonSdhci.c
│ │ └── XenonSdhci.h
│ └── Spi
│ ├── Controllers
│ │ ├── MvSpiOrionDxe.c
│ │ ├── MvSpiOrionDxe.h
│ │ └── MvSpiOrionDxe.inf
│ ├── Devices
│ │ ├── MvSpiFlash.c
│ │ ├── MvSpiFlash.h
│ │ └── MvSpiFlash.inf
│ └── Variables
│ ├── MvFvbDxe.c
│ ├── MvFvbDxe.h
│ └── MvFvbDxe.inf
├── Include
│ ├── Library
│ │ ├── MppLib.h
│ │ ├── MvComPhyLib.h
│ │ ├── MvHwDescLib.h
│ │ └── UtmiPhyLib.h
│ └── Protocol
│ ├── Eeprom.h
│ ├── Mdio.h
│ ├── MvPhy.h
│ ├── SpiFlash.h
│ └── Spi.h
├── Library
│ ├── ComPhyLib
│ │ ├── ComPhyCp110.c
│ │ ├── ComPhyLib.c
│ │ ├── ComPhyLib.h
│ │ ├── ComPhyLib.inf
│ │ └── ComPhyMux.c
│ ├── MppLib
│ │ ├── MppLib.c
│ │ └── MppLib.inf
│ └── UtmiPhyLib
│ ├── UtmiPhyLib.c
│ ├── UtmiPhyLib.h
│ └── UtmiPhyLib.inf
└── Marvell.dec
==
Marcin Wojtas (5):
Marvell: Reorganize file structure
Marvell/Armada7k8k: Use '7k8k' prefix in the SoC drivers/libraries
Marvell/Armada70x0Db: Rename fd file
Marvell/Drivers: Rename SPI master driver
Marvell/Drivers: Drop 'PciEmulation' naming
Platform/Marvell/{Armada/Armada70x0.dsc => Armada70x0Db/Armada70x0Db.dsc}
[edk2] [platforms: PATCH v2 4/5] Marvell/Drivers: Rename SPI master driver
Hitherto driver name was very generic. In order to be ready
for adding new SPI master drivers, use the controller's
traditional name (it's called SPI Orion in Linux and
U-Boot) for files and the entry point.
Additionally, move the files to new 'Controllers' directory,
which is paralel to existing 'Devices' and 'Variables', so
that to make the separation more clear.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas
---
Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf |
2 +-
Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc |
2 +-
Silicon/Marvell/Drivers/Spi/{MvSpiDxe.c => Controllers/MvSpiOrionDxe.c} |
4 ++--
Silicon/Marvell/Drivers/Spi/{MvSpiDxe.h => Controllers/MvSpiOrionDxe.h} | 0
Silicon/Marvell/Drivers/Spi/{MvSpiDxe.inf => Controllers/MvSpiOrionDxe.inf} |
8
5 files changed, 8 insertions(+), 8 deletions(-)
rename Silicon/Marvell/Drivers/Spi/{MvSpiDxe.c => Controllers/MvSpiOrionDxe.c}
(95%)
rename Silicon/Marvell/Drivers/Spi/{MvSpiDxe.h => Controllers/MvSpiOrionDxe.h}
(100%)
rename Silicon/Marvell/Drivers/Spi/{MvSpiDxe.inf =>
Controllers/MvSpiOrionDxe.inf} (92%)
diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
index 3b0646e..6d57b9a 100644
--- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
+++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
@@ -110,7 +110,7 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
INF Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
INF MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
INF Silicon/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf
- INF Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
+ INF Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
INF Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
INF Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.inf
diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index 7d87766..0eb3ef3 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -411,7 +411,7 @@
Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
Silicon/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf
- Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
+ Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.inf
diff --git a/Silicon/Marvell/Drivers/Spi/MvSpiDxe.c
b/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c
similarity index 95%
rename from Silicon/Marvell/Drivers/Spi/MvSpiDxe.c
rename to Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c
index bab6cf4..c657daf 100755
--- a/Silicon/Marvell/Drivers/Spi/MvSpiDxe.c
+++ b/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c
@@ -31,7 +31,7 @@ ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
***/
-#include "MvSpiDxe.h"
+#include "MvSpiOrionDxe.h"
SPI_MASTER *mSpiMasterInstance;
@@ -399,7 +399,7 @@ SpiMasterInitProtocol (
EFI_STATUS
EFIAPI
-SpiMasterEntryPoint (
+SpiOrionEntryPoint (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
diff --git a/Silicon/Marvell/Drivers/Spi/MvSpiDxe.h
b/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.h
similarity index 100%
rename from Silicon/Marvell/Drivers/Spi/MvSpiDxe.h
rename to Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.h
diff --git a/Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
b/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
similarity index 92%
rename from Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
rename to Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
index e7bc170..3f85b40 100644
--- a/Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
+++ b/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
@@ -31,15 +31,15 @@
[Defines]
INF_VERSION= 0x00010005
- BASE_NAME = SpiMasterDxe
+ BASE_NAME = SpiOrionDxe
FILE_GUID = c19dbc8a-f4f9-43b0-aee5-802e3ed03d15
MODULE_TYPE= DXE_RUNTIME_DRIVER
VERSION_STRING = 1.0
- ENTRY_POINT= SpiMasterEntryPoint
+ ENTRY_POINT= SpiOrionEntryPoint
[Sources]
- MvSpiDxe.c
- MvSpiDxe.h
+ MvSpiOrionDxe.c
+ MvSpiOrionDxe.h
[Packages]
EmbeddedPkg/EmbeddedPkg.dec
--
2.7.4
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [platforms: PATCH v2 5/5] Marvell/Drivers: Drop 'PciEmulation' naming
'PciEmulation' is not a proper naming for a driver, which
uses NonDiscoverableDeviceRegistrationLib for handling
the devices attached via internal bus of the SoC.
Rename it to MvNonDiscoverableDxe and move under
Silicon/Marvell/Drivers directory.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas
---
Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
| 4 +--
Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
| 4 +--
Silicon/Marvell/{PciEmulation/PciEmulation.c =>
Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c} | 26
++--
Silicon/Marvell/{PciEmulation/PciEmulation.inf =>
Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf} | 8 +++---
4 files changed, 21 insertions(+), 21 deletions(-)
rename Silicon/Marvell/{PciEmulation/PciEmulation.c =>
Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c} (84%)
rename Silicon/Marvell/{PciEmulation/PciEmulation.inf =>
Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf} (91%)
diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
index 6d57b9a..2bf409e 100644
--- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
+++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
@@ -135,8 +135,8 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
INF Silicon/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.inf
INF Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.inf
- # PciEmulation
- INF Silicon/Marvell/PciEmulation/PciEmulation.inf
+ # NonDiscoverableDevices
+ INF Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf
INF
MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
# SCSI
diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index 0eb3ef3..598810e 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -440,8 +440,8 @@
EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
- # PciEmulation
- Silicon/Marvell/PciEmulation/PciEmulation.inf
+ # NonDiscoverableDevices
+ Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf
MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
# SCSI
diff --git a/Silicon/Marvell/PciEmulation/PciEmulation.c
b/Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
similarity index 84%
rename from Silicon/Marvell/PciEmulation/PciEmulation.c
rename to Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
index 35f1a87..abb2940 100644
--- a/Silicon/Marvell/PciEmulation/PciEmulation.c
+++ b/Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
@@ -55,7 +55,7 @@ STATIC UINT8 * CONST SdhciDeviceTable = FixedPcdGetPtr
(PcdPciESdhci);
//
STATIC
EFI_STATUS
-PciEmulationInitXhci (
+MvNonDiscoverableInitXhci (
)
{
MVHW_NONDISCOVERABLE_DESC *Desc = &mA7k8kNonDiscoverableDescTemplate;
@@ -63,7 +63,7 @@ PciEmulationInitXhci (
UINT8 i;
if (PcdGetSize (PcdPciEXhci) < Desc->XhciDevCount) {
-DEBUG((DEBUG_ERROR, "PciEmulation: Wrong PcdPciEXhci format\n"));
+DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Wrong PcdPciEXhci format\n"));
return EFI_INVALID_PARAMETER;
}
@@ -82,7 +82,7 @@ PciEmulationInitXhci (
);
if (EFI_ERROR(Status)) {
- DEBUG((DEBUG_ERROR, "PciEmulation: Cannot install Xhci device %d\n", i));
+ DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Cannot install Xhci device
%d\n", i));
return Status;
}
}
@@ -92,7 +92,7 @@ PciEmulationInitXhci (
STATIC
EFI_STATUS
-PciEmulationInitAhci (
+MvNonDiscoverableInitAhci (
)
{
MVHW_NONDISCOVERABLE_DESC *Desc = &mA7k8kNonDiscoverableDescTemplate;
@@ -100,7 +100,7 @@ PciEmulationInitAhci (
UINT8 i;
if (PcdGetSize (PcdPciEAhci) < Desc->AhciDevCount) {
-DEBUG((DEBUG_ERROR, "PciEmulation: Wrong PcdPciEAhci format\n"));
+DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Wrong PcdPciEAhci format\n"));
return EFI_INVALID_PARAMETER;
}
@@ -119,7 +119,7 @@ PciEmulationInitAhci (
);
if (EFI_ERROR(Status)) {
- DEBUG((DEBUG_ERROR, "PciEmulation: Cannot install Ahci device %d\n", i));
+ DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Cannot install Ahci device
%d\n", i));
return Status;
}
}
@@ -129,7 +129,7 @@ PciEmulationInitAhci (
STATIC
EFI_STATUS
-PciEmulationInitSdhci (
+MvNonDiscoverableInitSdhci (
)
{
MVHW_NONDISCOVERABLE_DESC *Desc = &mA7k8kNonDiscoverableDescTemplate;
@@ -137,7 +137,7 @@ PciEmulationInitSdhci (
UINT8 i;
if (PcdGetSize (PcdPciESdhci) < Desc->SdhciDevCount) {
-DEBUG((DEBUG_ERROR, "PciEmulation: Wrong PcdPciESdhci format\n"));
+DEBUG((DEBUG_ERROR, "MvNonDisco
[edk2] [platforms: PATCH v2 1/5] Marvell: Reorganize file structure
In edk2-platforms it is expected to provide a separation between
SoC and boards files in 'Silicon' and 'Platform' directories
accordingly.
This patch aligns Marvell code to this requirement with no functional
changes in the actual source files, unless required due to modified
paths. Change the supported board's files names to proper Armada70x0Db.
Also rename 'Armada' directory to 'Armada7k8k' in order to properly
refer to the SoC family and prevent confusion in future, when
adding new Armada machines. On the occasion add ARM copyright,
which was wrongly missing in the dsc.inc file.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas
---
Platform/Marvell/{Armada/Armada70x0.dsc => Armada70x0Db/Armada70x0Db.dsc}
| 6 +--
Platform/Marvell/{Armada/Armada70x0.fdf => Armada70x0Db/Armada70x0Db.fdf}
| 24 +--
{Platform => Silicon}/Marvell/Applications/EepromCmd/EepromCmd.c
| 0
{Platform => Silicon}/Marvell/Applications/EepromCmd/EepromCmd.inf
| 2 +-
{Platform => Silicon}/Marvell/Applications/EepromCmd/EepromCmd.uni
| Bin
{Platform => Silicon}/Marvell/Applications/FirmwareUpdate/FUpdate.c
| 0
{Platform => Silicon}/Marvell/Applications/FirmwareUpdate/FUpdate.inf
| 2 +-
{Platform => Silicon}/Marvell/Applications/FirmwareUpdate/FUpdate.uni
| Bin
{Platform => Silicon}/Marvell/Applications/SpiTool/SpiFlashCmd.c
| 0
{Platform => Silicon}/Marvell/Applications/SpiTool/SpiFlashCmd.inf
| 2 +-
{Platform => Silicon}/Marvell/Applications/SpiTool/SpiFlashCmd.uni
| Bin
Platform/Marvell/Armada/Armada.dsc.inc =>
Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
| 44 ++--
{Platform/Marvell/Armada =>
Silicon/Marvell/Armada7k8k}/Drivers/Armada70x0RngDxe/Armada70x0RngDxe.c
| 0
{Platform/Marvell/Armada =>
Silicon/Marvell/Armada7k8k}/Drivers/Armada70x0RngDxe/Armada70x0RngDxe.inf
| 2 +-
{Platform/Marvell/Armada =>
Silicon/Marvell/Armada7k8k}/Drivers/PlatInitDxe/PlatInitDxe.c
| 0
{Platform/Marvell/Armada =>
Silicon/Marvell/Armada7k8k}/Drivers/PlatInitDxe/PlatInitDxe.inf
| 2 +-
{Platform/Marvell/Armada =>
Silicon/Marvell/Armada7k8k}/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S
| 0
{Platform/Marvell/Armada =>
Silicon/Marvell/Armada7k8k}/Library/Armada70x0Lib/ARM/ArmPlatformHelper.S
| 0
{Platform/Marvell/Armada =>
Silicon/Marvell/Armada7k8k}/Library/Armada70x0Lib/Armada70x0Lib.c
| 0
{Platform/Marvell/Armada =>
Silicon/Marvell/Armada7k8k}/Library/Armada70x0Lib/Armada70x0Lib.inf
| 2 +-
{Platform/Marvell/Armada =>
Silicon/Marvell/Armada7k8k}/Library/Armada70x0Lib/Armada70x0LibMem.c
| 0
{Platform/Marvell/Armada =>
Silicon/Marvell/Armada7k8k}/Library/Armada70x0Lib/Armada70x0LibMem.h
| 0
{Platform/Marvell/Armada =>
Silicon/Marvell/Armada7k8k}/Library/Armada70x0MemoryInitPeiLib/Armada70x0MemoryInitPeiLib.c
| 0
{Platform/Marvell/Armada =>
Silicon/Marvell/Armada7k8k}/Library/Armada70x0MemoryInitPeiLib/Armada70x0MemoryInitPeiLib.inf
| 2 +-
{Platform/Marvell/Armada =>
Silicon/Marvell/Armada7k8k}/Library/RealTimeClockLib/RealTimeClockLib.c
| 0
{Platform/Marvell/Armada =>
Silicon/Marvell/Armada7k8k}/Library/RealTimeClockLib/RealTimeClockLib.h
| 0
{Platform/Marvell/Armada =>
Silicon/Marvell/Armada7k8k}/Library/RealTimeClockLib/RealTimeClockLib.inf
| 2 +-
{Platform => Silicon}/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.c
| 0
{Platform => Silicon}/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.h
| 0
{Platform => Silicon}/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf
| 2 +-
{Platform => Silicon}/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c
| 0
{Platform => Silicon}/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.h
| 0
{Platform => Silicon}/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
[edk2] [platforms: PATCH v2 2/5] Marvell/Armada7k8k: Use '7k8k' prefix in the SoC drivers/libraries
As a part of files reorganization, switch to using '7k8k'
in all SoC-specific driver/library code instead of
'70x0'/'7040', so that to ensure consistent naming for
entire SoC family.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas
---
Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
|
2 +-
Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
|
6 +++---
Silicon/Marvell/Armada7k8k/Drivers/{Armada70x0RngDxe/Armada70x0RngDxe.c =>
Armada7k8kRngDxe/Armada7k8kRngDxe.c}
| 14 +++---
Silicon/Marvell/Armada7k8k/Drivers/{Armada70x0RngDxe/Armada70x0RngDxe.inf =>
Armada7k8kRngDxe/Armada7k8kRngDxe.inf}
| 6 +++---
Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib =>
Armada7k8kLib}/AArch64/ArmPlatformHelper.S
| 0
Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib =>
Armada7k8kLib}/ARM/ArmPlatformHelper.S
| 0
Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib/Armada70x0Lib.c =>
Armada7k8kLib/Armada7k8kLib.c}
| 6 +++---
Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib/Armada70x0Lib.inf =>
Armada7k8kLib/Armada7k8kLib.inf}
| 10 +-
Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib/Armada70x0LibMem.c =>
Armada7k8kLib/Armada7k8kLibMem.c}
| 2 +-
Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib/Armada70x0LibMem.h =>
Armada7k8kLib/Armada7k8kLibMem.h}
| 0
Silicon/Marvell/Armada7k8k/Library/{Armada70x0MemoryInitPeiLib/Armada70x0MemoryInitPeiLib.c
=> Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.c} | 0
Silicon/Marvell/Armada7k8k/Library/{Armada70x0MemoryInitPeiLib/Armada70x0MemoryInitPeiLib.inf
=> Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.inf} | 4 ++--
12 files changed, 25 insertions(+), 25 deletions(-)
rename Silicon/Marvell/Armada7k8k/Drivers/{Armada70x0RngDxe/Armada70x0RngDxe.c
=> Armada7k8kRngDxe/Armada7k8kRngDxe.c} (94%)
rename
Silicon/Marvell/Armada7k8k/Drivers/{Armada70x0RngDxe/Armada70x0RngDxe.inf =>
Armada7k8kRngDxe/Armada7k8kRngDxe.inf} (85%)
rename Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib =>
Armada7k8kLib}/AArch64/ArmPlatformHelper.S (100%)
rename Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib =>
Armada7k8kLib}/ARM/ArmPlatformHelper.S (100%)
rename Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib/Armada70x0Lib.c =>
Armada7k8kLib/Armada7k8kLib.c} (90%)
rename Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib/Armada70x0Lib.inf =>
Armada7k8kLib/Armada7k8kLib.inf} (93%)
rename Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib/Armada70x0LibMem.c =>
Armada7k8kLib/Armada7k8kLibMem.c} (96%)
rename Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib/Armada70x0LibMem.h =>
Armada7k8kLib/Armada7k8kLibMem.h} (100%)
rename
Silicon/Marvell/Armada7k8k/Library/{Armada70x0MemoryInitPeiLib/Armada70x0MemoryInitPeiLib.c
=> Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.c} (100%)
rename
Silicon/Marvell/Armada7k8k/Library/{Armada70x0MemoryInitPeiLib/Armada70x0MemoryInitPeiLib.inf
=> Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.inf} (90%)
diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
index f63f42d..bba449a 100644
--- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
+++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
@@ -112,7 +112,7 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
INF Silicon/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf
INF Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
INF Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
- INF Silicon/Marvell/Armada7k8k/Drivers/Armada70x0RngDxe/Armada70x0RngDxe.inf
+ INF Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.inf
# Variable services
INF Silicon/Marvell/Drivers/Spi/Variables/MvFvbDxe.inf
diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index 75717e9..7d87766 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -32,7 +32,7 @@
#SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
[LibraryClasses.common]
-
ArmPlatformLib|Silicon/Marvell/Armada7k8k/Library/Armada70x0Lib/Armada70x0Lib.inf
+
ArmPlatformLib|Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLib.inf
ComPhyLib|Silicon/Marvell/Library/ComPhyLib/ComPhyLib.inf
MppLib|Silicon/Marvell/
Re: [edk2] [platforms: PATCH v2 4/5] Marvell/Drivers: Rename SPI master driver
Hi Marcin,
On 7 December 2017 at 19:20, Marcin Wojtas wrote:
> Hitherto driver name was very generic. In order to be ready
> for adding new SPI master drivers, use the controller's
> traditional name (it's called SPI Orion in Linux and
> U-Boot) for files and the entry point.
>
> Additionally, move the files to new 'Controllers' directory,
> which is paralel to existing 'Devices' and 'Variables', so
> that to make the separation more clear.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas
> ---
> Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
> | 2 +-
> Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> | 2 +-
> Silicon/Marvell/Drivers/Spi/{MvSpiDxe.c => Controllers/MvSpiOrionDxe.c}
> | 4 ++--
> Silicon/Marvell/Drivers/Spi/{MvSpiDxe.h => Controllers/MvSpiOrionDxe.h}
> | 0
> Silicon/Marvell/Drivers/Spi/{MvSpiDxe.inf => Controllers/MvSpiOrionDxe.inf}
> | 8
> 5 files changed, 8 insertions(+), 8 deletions(-)
> rename Silicon/Marvell/Drivers/Spi/{MvSpiDxe.c =>
> Controllers/MvSpiOrionDxe.c} (95%)
> rename Silicon/Marvell/Drivers/Spi/{MvSpiDxe.h =>
> Controllers/MvSpiOrionDxe.h} (100%)
> rename Silicon/Marvell/Drivers/Spi/{MvSpiDxe.inf =>
> Controllers/MvSpiOrionDxe.inf} (92%)
I think this is not entirely correct. With these patches applied, we have
Silicon/Marvell/Drivers/Spi/Variables
Silicon/Marvell/Drivers/Spi/Variables/MvFvbDxe.h
Silicon/Marvell/Drivers/Spi/Variables/MvFvbDxe.inf
Silicon/Marvell/Drivers/Spi/Variables/MvFvbDxe.c
Silicon/Marvell/Drivers/Spi/Devices
Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.h
Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.c
Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
Silicon/Marvell/Drivers/Spi/Controllers
Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.h
Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c
where each directory is named as if it could contain multiple drivers,
but given that each driver belongs in its own directory, we are
missing one directory level.
To be honest (but I will let Leif comment as well), I think you can
remove the Variables/Devices/Controllers distinction, and just have
Silicon/Marvell/Drivers/Spi/MvFvbDxe
Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.h
Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf
Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.c
Silicon/Marvell/Drivers/Spi/MvSpiFlash
Silicon/Marvell/Drivers/Spi/MvSpiFlash/MvSpiFlash.h
Silicon/Marvell/Drivers/Spi/MvSpiFlash/MvSpiFlash.c
Silicon/Marvell/Drivers/Spi/MvSpiFlash/MvSpiFlash.inf
Silicon/Marvell/Drivers/Spi/MvSpiOrionDxe
Silicon/Marvell/Drivers/Spi/MvSpiOrionDxe/MvSpiOrionDxe.h
Silicon/Marvell/Drivers/Spi/MvSpiOrionDxe/MvSpiOrionDxe.inf
Silicon/Marvell/Drivers/Spi/MvSpiOrionDxe/MvSpiOrionDxe.c
>
> diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
> b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
> index 3b0646e..6d57b9a 100644
> --- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
> +++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
> @@ -110,7 +110,7 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
>INF Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
>INF MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
>INF Silicon/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf
> - INF Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
> + INF Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
>INF Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
>INF
> Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.inf
>
> diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> index 7d87766..0eb3ef3 100644
> --- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> +++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> @@ -411,7 +411,7 @@
>Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
>MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
>Silicon/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf
> - Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
> + Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
>Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
>Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.inf
>
> diff --git a/Silicon/Marvell/Drivers/Spi/MvSpiDxe.c
> b/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c
> similarity index 95%
> rename from Silicon/Marvell/Drivers/Spi/MvSpiDxe.c
> rename to Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c
> index bab6cf4..c657daf 100755
> --- a/Silicon/Marvell/Drivers/Spi/MvSpiDxe.c
> +++ b/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c
> @@ -31,7 +31,7 @@ ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> LIABILITY, OR TORT
> SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
>
> ***/
> -#in
Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR
Ard,
I do not disagree with your logic.
The current algorithm is based on data from a long
time ago using what are now very old tool chains.
I will do some experiments on the currently supported
toolchains to see if the optimization is the same either
way.
I think the change you are suggesting is to improve
performance for optimization disabled builds by removing
an extra call. Is that correct?
Mike
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, December 7, 2017 9:43 AM
> To: Kinney, Michael D
> Cc: Alexei Fedorov ; edk2-
> de...@lists.01.org; Gao, Liming ;
> Leif Lindholm
> Subject: Re: [edk2] [PATCH] MdePkg/DebugLib; swap if
> conditions in ASSERT_[EFI|RETURN]_ERROR
>
> On 7 December 2017 at 17:36, Kinney, Michael D
> wrote:
> > Ard,
> >
> > With link time optimization, the current order produces
> > smaller code.
> >
>
> I don't think it does. You are essentially saying that
> DebugAssertEnabled() may resolve to a link time constant
> FALSE under
> LTO.
>
> In that case, why would the following two statement not
> be equivalent?
>
> if (FALSE && EFI_ERROR (StatusParameter)) {}
>
> if (EFI_ERROR (StatusParameter) && FALSE) {}
>
> (which is essentially what a nested if () resolves to)
>
> In other words, the compiler is smart enough to drop the
> status check
> in the second case, because it can see there are no side
> effects, and
> the condition can never be made true anyway.
>
> > Without link time optimization, your patch will produce
> > smaller code, but not as small as link time optimized
> code.
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [platforms: PATCH v2 5/5] Marvell/Drivers: Drop 'PciEmulation' naming
Hi Marcin,
On 7 December 2017 at 19:20, Marcin Wojtas wrote:
> 'PciEmulation' is not a proper naming for a driver, which
> uses NonDiscoverableDeviceRegistrationLib for handling
> the devices attached via internal bus of the SoC.
> Rename it to MvNonDiscoverableDxe and move under
> Silicon/Marvell/Drivers directory.
>
Thank you!
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas
> ---
> Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
> | 4 +--
> Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> | 4 +--
> Silicon/Marvell/{PciEmulation/PciEmulation.c =>
> Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c} | 26
> ++--
> Silicon/Marvell/{PciEmulation/PciEmulation.inf =>
> Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf} | 8 +++---
> 4 files changed, 21 insertions(+), 21 deletions(-)
> rename Silicon/Marvell/{PciEmulation/PciEmulation.c =>
> Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c} (84%)
> rename Silicon/Marvell/{PciEmulation/PciEmulation.inf =>
> Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf} (91%)
>
Could we please have
Drivers/MvNonDiscoverableDxe/MvNonDiscoverableDxe.inf
instead?
> diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
> b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
> index 6d57b9a..2bf409e 100644
> --- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
> +++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
> @@ -135,8 +135,8 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
>INF Silicon/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.inf
>INF Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.inf
>
> - # PciEmulation
> - INF Silicon/Marvell/PciEmulation/PciEmulation.inf
> + # NonDiscoverableDevices
> + INF Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf
>INF
> MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
>
># SCSI
> diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> index 0eb3ef3..598810e 100644
> --- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> +++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> @@ -440,8 +440,8 @@
>EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
>EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
>
> - # PciEmulation
> - Silicon/Marvell/PciEmulation/PciEmulation.inf
> + # NonDiscoverableDevices
> + Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf
>
> MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
>
># SCSI
> diff --git a/Silicon/Marvell/PciEmulation/PciEmulation.c
> b/Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
> similarity index 84%
> rename from Silicon/Marvell/PciEmulation/PciEmulation.c
> rename to
> Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
> index 35f1a87..abb2940 100644
> --- a/Silicon/Marvell/PciEmulation/PciEmulation.c
> +++ b/Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
> @@ -55,7 +55,7 @@ STATIC UINT8 * CONST SdhciDeviceTable = FixedPcdGetPtr
> (PcdPciESdhci);
> //
> STATIC
> EFI_STATUS
> -PciEmulationInitXhci (
> +MvNonDiscoverableInitXhci (
>)
> {
>MVHW_NONDISCOVERABLE_DESC *Desc = &mA7k8kNonDiscoverableDescTemplate;
> @@ -63,7 +63,7 @@ PciEmulationInitXhci (
>UINT8 i;
>
>if (PcdGetSize (PcdPciEXhci) < Desc->XhciDevCount) {
> -DEBUG((DEBUG_ERROR, "PciEmulation: Wrong PcdPciEXhci format\n"));
> +DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Wrong PcdPciEXhci format\n"));
> return EFI_INVALID_PARAMETER;
>}
>
> @@ -82,7 +82,7 @@ PciEmulationInitXhci (
> );
>
> if (EFI_ERROR(Status)) {
> - DEBUG((DEBUG_ERROR, "PciEmulation: Cannot install Xhci device %d\n",
> i));
> + DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Cannot install Xhci device
> %d\n", i));
>return Status;
> }
>}
> @@ -92,7 +92,7 @@ PciEmulationInitXhci (
>
> STATIC
> EFI_STATUS
> -PciEmulationInitAhci (
> +MvNonDiscoverableInitAhci (
>)
> {
>MVHW_NONDISCOVERABLE_DESC *Desc = &mA7k8kNonDiscoverableDescTemplate;
> @@ -100,7 +100,7 @@ PciEmulationInitAhci (
>UINT8 i;
>
>if (PcdGetSize (PcdPciEAhci) < Desc->AhciDevCount) {
> -DEBUG((DEBUG_ERROR, "PciEmulation: Wrong PcdPciEAhci format\n"));
> +DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Wrong PcdPciEAhci format\n"));
> return EFI_INVALID_PARAMETER;
>}
>
> @@ -119,7 +119,7 @@ PciEmulationInitAhci (
> );
>
> if (EFI_ERROR(Status)) {
> - DEBUG((DEBUG_ERROR, "PciEmulation: Cannot install Ahci device %d\n",
> i));
> + DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Cannot install Ahci device
> %d\n", i));
>return Status;
> }
>}
> @@ -129,7 +129,7 @@ PciEm
Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR
On 7 December 2017 at 19:49, Kinney, Michael D
wrote:
> Ard,
>
> I do not disagree with your logic.
>
> The current algorithm is based on data from a long
> time ago using what are now very old tool chains.
>
With LTO?
> I will do some experiments on the currently supported
> toolchains to see if the optimization is the same either
> way.
>
Thank you.
> I think the change you are suggesting is to improve
> performance for optimization disabled builds by removing
> an extra call. Is that correct?
>
Well, for DEBUG builds, yes. But given that the function call cannot
be optimized away (on non-LTO builds), it affects optimized builds as
well.
--
Ard.
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Thursday, December 7, 2017 9:43 AM
>> To: Kinney, Michael D
>> Cc: Alexei Fedorov ; edk2-
>> de...@lists.01.org; Gao, Liming ;
>> Leif Lindholm
>> Subject: Re: [edk2] [PATCH] MdePkg/DebugLib; swap if
>> conditions in ASSERT_[EFI|RETURN]_ERROR
>>
>> On 7 December 2017 at 17:36, Kinney, Michael D
>> wrote:
>> > Ard,
>> >
>> > With link time optimization, the current order produces
>> > smaller code.
>> >
>>
>> I don't think it does. You are essentially saying that
>> DebugAssertEnabled() may resolve to a link time constant
>> FALSE under
>> LTO.
>>
>> In that case, why would the following two statement not
>> be equivalent?
>>
>> if (FALSE && EFI_ERROR (StatusParameter)) {}
>>
>> if (EFI_ERROR (StatusParameter) && FALSE) {}
>>
>> (which is essentially what a nested if () resolves to)
>>
>> In other words, the compiler is smart enough to drop the
>> status check
>> in the second case, because it can see there are no side
>> effects, and
>> the condition can never be made true anyway.
>>
>> > Without link time optimization, your patch will produce
>> > smaller code, but not as small as link time optimized
>> code.
>> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650 GOP driver.
Hi Ard. > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: 05 December 2017 21:28 > To: Evan Lloyd > Cc: edk2-devel@lists.01.org; Matteo Carlini ; > Leif Lindholm ; Girish Pathak > > Subject: Re: [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650 > GOP driver. > > On 5 December 2017 at 20:03, Evan Lloyd wrote: > > > > > >> -Original Message- > >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > >> Sent: 01 December 2017 17:19 > >> To: Evan Lloyd > >> Cc: edk2-devel@lists.01.org; Matteo Carlini ; > >> Leif Lindholm ; Girish Pathak > >> > >> Subject: Re: [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650 > GOP > >> driver. > >> ... > >> > > >> >> whatsoever. If you introduce any library classes that abstract > >> >> away the differences between platforms, you can include a Null > >> >> version of such a library that simply does ASSERT (FALSE) in every > function: > >> >> this > >> > > >> > [[Evan Lloyd]] One could, indeed, do that. We, however, would be > >> > very > >> reluctant to incur the overhead of rework in response to spurious > >> cavils from a maintainer when it is of no direct relevance to us. > >> > > >> > >> I don't think the suggestion that we evil maintainers are nothing but > >> an impediment to the likes of you and your team members doing the > >> actual work is justified. > >> > >> We are all on the same team here, and the goal is to make UEFI code > >> reusable for the customers of /your/ employer. Throwing stuff over > >> the fence != upstreaming, and it is my job as a maintainer to ensure > >> that code is still maintainable long after the original authors have > >> moved on to something else. > >> > >> ArmPlatformPkg is a perfect example where code reuse is much more > >> difficult than it needs to be, and we as maintainers need to deal > >> with contributors from other companies that have used it as > >> 'guidance' for how to architect their UEFI firmware, which is usually > >> filled with vexpress-isms that date back to before anyone currently > involved with UEFI can remember. > >> > >> This is why I have taken the time to sit down, go through all the > >> crap code, clean it up, refactor it and propose it on the list as > >> improvements. I even went so far as taking the preparatory Mali work > >> of your team and rebase it so that we can keep the bits that we may > >> share, and move the bits out that should not be kept in main EDK2 > >> because they are being taken as gospel by engineers that are new to > >> ARM+UEFI. > >> > >> If this is too much to deal with for you, then fine, don't upstream your > code. > >> But if you do, you are going to have to play nice with the others, > >> including the maintainers. > >> > > [[Evan Lloyd]] Hi Ard. Firstly, I apologize, I assumed from your name that > you were Dutch and would therefore probably have a lively sense of > humour. Of course, if I have touched a nerve, that is unfortunate and I'm > sorry. > > No, the apparently blatantly obvious tongue-in-cheek nature of your > response was completely lost on me. But I know a person who does have a > lively sense of humour, so next time I will ask him for help. [[Evan Lloyd]] I would like to extend my apology. From comments others have made it is apparent that my wording was too easily interpreted as just offensive. I shall try and resist the temptation to make such points with dubious attempts at humour in the future, at least on fora like this where they are out of place. Het spijt me. > > > I agree that cleaning up the code is important, worthwhile, and an > objective for us all. What can be a difficulty is our very different > conceptions of what clean means. > > > > Fair enough. But as maintainers, we take ownership of your code, with the > implied promise to keep it in a working state. I don't think it is > unreasonable that we get to dictate some of the terms under which that > occurs. > > > You should be aware though that a certain amount of whingeing is to be > > expected when dealing with Brits. (Ask Leif - he knows! Or any Australian.) > I do not disagree with your intent - but I do sometimes feel that the criteria > applied do not take into account the cost/benefit aspects, and seek to air > that point. I shall endeavour to make such points in a less bantering way in > future. > > > > Thanks. > > I think one of the misconceptions may be that upstreaming is something > one does once the code is completely finished. Instead, please involve us > much sooner if you intend to upstream your code (or just Leif for > confidential stuff). That way, any effort invested in the code benefits your > product as well as the open source, rather than shipping one version, and > having to go back and change stuff for the version that ends up upstream. 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 th
Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of Ard Biesheuvel
> Sent: Thursday, December 7, 2017 11:53 AM
> To: Kinney, Michael D
> Cc: Alexei Fedorov ; edk2-
> de...@lists.01.org; Leif Lindholm
> ; Gao, Liming
>
> Subject: Re: [edk2] [PATCH] MdePkg/DebugLib; swap if
> conditions in ASSERT_[EFI|RETURN]_ERROR
>
> On 7 December 2017 at 19:49, Kinney, Michael D
> wrote:
> > Ard,
> >
> > I do not disagree with your logic.
> >
> > The current algorithm is based on data from a long
> > time ago using what are now very old tool chains.
> >
>
> With LTO?
Yes. The LTCG feature for VS tool chains.
>
> > I will do some experiments on the currently supported
> > toolchains to see if the optimization is the same
> either
> > way.
> >
>
> Thank you.
>
> > I think the change you are suggesting is to improve
> > performance for optimization disabled builds by
> removing
> > an extra call. Is that correct?
> >
>
> Well, for DEBUG builds, yes. But given that the function
> call cannot
> be optimized away (on non-LTO builds), it affects
> optimized builds as
> well.
Do you mean compiler optimizations enabled, but linker
optimizations disabled.
>
> --
> Ard.
>
>
> >> -Original Message-
> >> From: Ard Biesheuvel
> [mailto:ard.biesheu...@linaro.org]
> >> Sent: Thursday, December 7, 2017 9:43 AM
> >> To: Kinney, Michael D
> >> Cc: Alexei Fedorov ; edk2-
> >> de...@lists.01.org; Gao, Liming
> ;
> >> Leif Lindholm
> >> Subject: Re: [edk2] [PATCH] MdePkg/DebugLib; swap if
> >> conditions in ASSERT_[EFI|RETURN]_ERROR
> >>
> >> On 7 December 2017 at 17:36, Kinney, Michael D
> >> wrote:
> >> > Ard,
> >> >
> >> > With link time optimization, the current order
> produces
> >> > smaller code.
> >> >
> >>
> >> I don't think it does. You are essentially saying that
> >> DebugAssertEnabled() may resolve to a link time
> constant
> >> FALSE under
> >> LTO.
> >>
> >> In that case, why would the following two statement
> not
> >> be equivalent?
> >>
> >> if (FALSE && EFI_ERROR (StatusParameter)) {}
> >>
> >> if (EFI_ERROR (StatusParameter) && FALSE) {}
> >>
> >> (which is essentially what a nested if () resolves to)
> >>
> >> In other words, the compiler is smart enough to drop
> the
> >> status check
> >> in the second case, because it can see there are no
> side
> >> effects, and
> >> the condition can never be made true anyway.
> >>
> >> > Without link time optimization, your patch will
> produce
> >> > smaller code, but not as small as link time
> optimized
> >> code.
> >> >
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR
On 7 December 2017 at 20:33, Kinney, Michael D wrote: >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] >> On Behalf Of Ard Biesheuvel >> Sent: Thursday, December 7, 2017 11:53 AM >> To: Kinney, Michael D >> Cc: Alexei Fedorov ; edk2- >> de...@lists.01.org; Leif Lindholm >> ; Gao, Liming >> >> Subject: Re: [edk2] [PATCH] MdePkg/DebugLib; swap if >> conditions in ASSERT_[EFI|RETURN]_ERROR >> >> On 7 December 2017 at 19:49, Kinney, Michael D >> wrote: >> > Ard, >> > >> > I do not disagree with your logic. >> > >> > The current algorithm is based on data from a long >> > time ago using what are now very old tool chains. >> > >> >> With LTO? > > Yes. The LTCG feature for VS tool chains. > >> >> > I will do some experiments on the currently supported >> > toolchains to see if the optimization is the same >> either >> > way. >> > >> >> Thank you. >> >> > I think the change you are suggesting is to improve >> > performance for optimization disabled builds by >> removing >> > an extra call. Is that correct? >> > >> >> Well, for DEBUG builds, yes. But given that the function >> call cannot >> be optimized away (on non-LTO builds), it affects >> optimized builds as >> well. > > Do you mean compiler optimizations enabled, but linker > optimizations disabled. > Basically, yes. LTO has only been added recently for GCC5 on ARM/AARCH64, and we are currently adding support for CLANG38 as well. CLANG35 and RVCT do not support LTO. So non-LTO still needs to be supported as well, and in some debugging/tracing contexts, having lots of needless function calls is making our lives difficult. (Hence my additional comment regarding ASSERT (), although I suppose in some cases, calculating the result of the expression could be more costly than the actual function call) ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 3/3] BaseTool/tools_def GCC5: enable optimization for ARM/AARCH64 DEBUG builds
Enable optimization for DEBUG builds, to make it more usable in terms of performance, and to give more coverage to the LTO builds. Also, some diagnostics are only enabled when optimization is enabled. NOOPT builds can now also be created, which will retain the behavior DEBUG builds had previously. Note that this aligns ARM and AARCH64 with the x86 architectures, which already use optimization for DEBUG builds. In order to preserve existing behavior for users of older toolchains, keep GCC49 and older as-is. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel Acked-by: Laszlo Ersek --- v3: add Laszlo's ack BaseTools/Conf/tools_def.template | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 896ec1a9f077..98ab6dd45e81 100755 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -5517,8 +5517,8 @@ RELEASE_GCC5_X64_DLINK_FLAGS = DEF(GCC5_X64_DLINK_FLAGS) -flto -Os *_GCC5_ARM_VFRPP_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_VFRPP_FLAGS) *_GCC5_ARM_CC_XIPFLAGS = DEF(GCC5_ARM_CC_XIPFLAGS) - DEBUG_GCC5_ARM_CC_FLAGS= DEF(GCC5_ARM_CC_FLAGS) -O0 - DEBUG_GCC5_ARM_DLINK_FLAGS = DEF(GCC5_ARM_DLINK_FLAGS) + DEBUG_GCC5_ARM_CC_FLAGS= DEF(GCC5_ARM_CC_FLAGS) -flto -Wno-unused-but-set-variable -Wno-unused-const-variable + DEBUG_GCC5_ARM_DLINK_FLAGS = DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-arm -Wl,-plugin-opt=-pass-through=-llto-arm RELEASE_GCC5_ARM_CC_FLAGS= DEF(GCC5_ARM_CC_FLAGS) -flto -Wno-unused-but-set-variable -Wno-unused-const-variable RELEASE_GCC5_ARM_DLINK_FLAGS = DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-arm -Wl,-plugin-opt=-pass-through=-llto-arm @@ -5551,8 +5551,8 @@ RELEASE_GCC5_ARM_DLINK_FLAGS = DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os -L$(WORKS *_GCC5_AARCH64_VFRPP_FLAGS = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) DEF(GCC_VFRPP_FLAGS) *_GCC5_AARCH64_CC_XIPFLAGS = DEF(GCC5_AARCH64_CC_XIPFLAGS) - DEBUG_GCC5_AARCH64_CC_FLAGS= DEF(GCC5_AARCH64_CC_FLAGS) -O0 -mcmodel=small - DEBUG_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -z common-page-size=0x1000 + DEBUG_GCC5_AARCH64_CC_FLAGS= DEF(GCC5_AARCH64_CC_FLAGS) -flto -Wno-unused-but-set-variable -Wno-unused-const-variable -mcmodel=small + DEBUG_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -z common-page-size=0x1000 -flto -Os -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-aarch64 -Wl,-plugin-opt=-pass-through=-llto-aarch64 -Wno-lto-type-mismatch -mcmodel=small DEBUG_GCC5_AARCH64_DLINK_XIPFLAGS = -z common-page-size=0x20 RELEASE_GCC5_AARCH64_CC_FLAGS= DEF(GCC5_AARCH64_CC_FLAGS) -flto -Wno-unused-but-set-variable -Wno-unused-const-variable -mcmodel=tiny -- 2.11.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 2/3] BaseTools/tools_def CLANG38: add -Wno-unused-const-variable
Commit 8b6366f87584 ("BaseTools/GCC: set -Wno-unused-const-variable
on RELEASE builds") suppresses warnings about unused constant
variables in RELEASE builds when building with GCC, given that they
break the build under our warnings-as-errors policy.
Do the same for CLANG38.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=790
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
Reviewed-by: Laszlo Ersek
---
v3: add Laszlo's R-b
BaseTools/Conf/tools_def.template | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/BaseTools/Conf/tools_def.template
b/BaseTools/Conf/tools_def.template
index 8889f1bc488a..896ec1a9f077 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -5664,7 +5664,7 @@ DEFINE CLANG38_X64_PREFIX = ENV(CLANG38_BIN)
DEFINE CLANG38_IA32_TARGET = -target i686-pc-linux-gnu
DEFINE CLANG38_X64_TARGET = -target x86_64-pc-linux-gnu
-DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality
-Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare
-Wno-empty-body -Wno-varargs
+DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality
-Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare
-Wno-empty-body -Wno-unused-const-variable -Wno-varargs
DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS)
DEF(CLANG38_WARNING_OVERRIDES) -fno-stack-protector -mms-bitfields -Wno-address
-Wno-shift-negative-value -Wno-unknown-pragmas
-Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables
-mno-sse -mno-mmx -msoft-float -mno-implicit-float
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang
-funsigned-char -fno-ms-extensions -Wno-null-dereference
-Wno-unknown-warning-option
###
--
2.11.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 0/3] BaseTools/tools_def: GCC5/CLANG38 toolchain updates
Some toolchain updates for CLANG38 and GCC5: - introduce CLANG38+LTO for ARM and AARCH64 - disable a warning on CLANG38 - enable optimization for GCC5 DEBUG builds Ard Biesheuvel (3): BaseTools/tools_def: add CLANG38 LTO versions for AARCH64 and ARM BaseTools/tools_def CLANG38: add -Wno-unused-const-variable BaseTool/tools_def GCC5: enable optimization for ARM/AARCH64 DEBUG builds BaseTools/Conf/tools_def.template | 106 ++-- 1 file changed, 99 insertions(+), 7 deletions(-) -- 2.11.0 ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v3 1/3] BaseTools/tools_def: add CLANG38 LTO versions for AARCH64 and ARM
Extend the CLANG38 toolchain definition so it can be used for ARM and AARCH64 as well. Note that this requires llvm-ar and the LLVMgold.so linker plugin. In preparation of doing the same for GCC5, this toolchain version also departs from the custom of using -O0 for DEBUG builds, which makes them needlessly slow. Instead, let's add a NOOPT flavor as well, and enable optimization for DEBUG like the other architectures do. (Note that this will require some trivial changes to the platform description files) Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel Acked-by: Laszlo Ersek --- v3: add workaround for CLANG 3.8, which suffers from the same issue with intrinsics as GCC/LTO (in a nutshell, LTO processing may emit function calls to intrinsics that have already been pruned from the input objects) use -O1 for DEBUG instead of -O3, to reduce code size increase v2: add missing -flto to CC flags, without that LTO is not actually enabled (which is why I did not take Leif's Tested-by) add -fno-lto to ASLC CC flags BaseTools/Conf/tools_def.template | 98 +++- 1 file changed, 95 insertions(+), 3 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/tools_def.template index 91b135c2e569..8889f1bc488a 100755 --- a/BaseTools/Conf/tools_def.template +++ b/BaseTools/Conf/tools_def.template @@ -399,8 +399,8 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc # Intel(r) ACPI Compiler from # https://acpica.org/downloads # CLANG38 -Linux- Requires: -# Clang v3.8, LLVMgold plugin and GNU binutils 2.26 targeting x86_64-linux-gnu -# Clang v3.9 or later, LLVMgold plugin and GNU binutils 2.28 targeting x86_64-linux-gnu +# Clang v3.8, LLVMgold plugin and GNU binutils 2.26 targeting x86_64-linux-gnu, aarch64-linux-gnu or arm-linux-gnueabi +# Clang v3.9 or later, LLVMgold plugin and GNU binutils 2.28 targeting x86_64-linux-gnu, aarch64-linux-gnu or arm-linux-gnueabi #Optional: # Required to build platforms or ACPI tables: # Intel(r) ACPI Compiler from @@ -5652,6 +5652,7 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS) *_CLANG38_*_MAKE_PATH = make *_CLANG38_*_*_DLL = ENV(CLANG38_DLL) *_CLANG38_*_ASL_PATH= DEF(UNIX_IASL_BIN) +*_CLANG38_*_DTC_PATH= DEF(DTC_BIN) *_CLANG38_*_APP_FLAGS = *_CLANG38_*_ASL_FLAGS = DEF(IASL_FLAGS) @@ -5663,7 +5664,8 @@ DEFINE CLANG38_X64_PREFIX = ENV(CLANG38_BIN) DEFINE CLANG38_IA32_TARGET = -target i686-pc-linux-gnu DEFINE CLANG38_X64_TARGET = -target x86_64-pc-linux-gnu -DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -Wno-empty-body -fno-stack-protector -mms-bitfields -Wno-address -Wno-shift-negative-value -Wno-parentheses-equality -Wno-unknown-pragmas -Wno-tautological-constant-out-of-range-compare -Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -msoft-float -mno-implicit-float -ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -funsigned-char -fno-ms-extensions -Wno-null-dereference -Wno-tautological-compare -Wno-unknown-warning-option -Wno-varargs +DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality -Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare -Wno-empty-body -Wno-varargs +DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) DEF(CLANG38_WARNING_OVERRIDES) -fno-stack-protector -mms-bitfields -Wno-address -Wno-shift-negative-value -Wno-unknown-pragmas -Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -msoft-float -mno-implicit-float -ftrap-function=undefined_behavior_has_been_optimized_away_by_clang -funsigned-char -fno-ms-extensions -Wno-null-dereference -Wno-unknown-warning-option ### # CLANG38 IA32 definitions @@ -5739,6 +5741,96 @@ NOOPT_CLANG38_X64_CC_FLAGS = DEF(CLANG38_ALL_CC_FLAGS) -m64 "-DEFIAPI=__ NOOPT_CLANG38_X64_DLINK_FLAGS = DEF(GCC5_IA32_X64_DLINK_FLAGS) -Wl,-O0 -Wl,-melf_x86_64 -Wl,--oformat=elf64-x86-64 -Wl,-pie -mcmodel=small NOOPT_CLANG38_X64_DLINK2_FLAGS = DEF(GCC5_X64_DLINK2_FLAGS) -O0 +## +# CLANG38 ARM definitions +## +DEFINE CLANG38_ARM_TARGET= -target arm-linux-gnueabihf +DEFINE CLANG38_ARM_CC_FLAGS = DEF(GCC_ARM_CC_FLAGS) DEF(CLANG38_ARM_TARGET) DEF(CLANG38_WARNING_OVERRIDES) -mno-movt +DEFINE CLANG38_ARM_DLINK_FLAGS = DEF(CLANG38_ARM_TARGET) DEF(GCC_ARM_DLINK_FLAGS) + +*_CLANG38_ARM_PP_FLAGS = DEF(GCC_PP_FLAGS) +*_CLANG38_ARM_ASLCC_FLAGS= DEF(GCC_ASLCC_
Re: [edk2] [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650 GOP driver.
On 7 December 2017 at 20:21, Evan Lloyd wrote: > Hi Ard. > >> -Original Message- >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >> Sent: 05 December 2017 21:28 >> To: Evan Lloyd >> Cc: edk2-devel@lists.01.org; Matteo Carlini ; >> Leif Lindholm ; Girish Pathak >> >> Subject: Re: [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650 >> GOP driver. >> >> On 5 December 2017 at 20:03, Evan Lloyd wrote: >> > >> > >> >> -Original Message- >> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] >> >> Sent: 01 December 2017 17:19 >> >> To: Evan Lloyd >> >> Cc: edk2-devel@lists.01.org; Matteo Carlini ; >> >> Leif Lindholm ; Girish Pathak >> >> >> >> Subject: Re: [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650 >> GOP >> >> driver. >> >> > ... >> >> > >> >> >> whatsoever. If you introduce any library classes that abstract >> >> >> away the differences between platforms, you can include a Null >> >> >> version of such a library that simply does ASSERT (FALSE) in every >> function: >> >> >> this >> >> > >> >> > [[Evan Lloyd]] One could, indeed, do that. We, however, would be >> >> > very >> >> reluctant to incur the overhead of rework in response to spurious >> >> cavils from a maintainer when it is of no direct relevance to us. >> >> > >> >> >> >> I don't think the suggestion that we evil maintainers are nothing but >> >> an impediment to the likes of you and your team members doing the >> >> actual work is justified. >> >> >> >> We are all on the same team here, and the goal is to make UEFI code >> >> reusable for the customers of /your/ employer. Throwing stuff over >> >> the fence != upstreaming, and it is my job as a maintainer to ensure >> >> that code is still maintainable long after the original authors have >> >> moved on to something else. >> >> >> >> ArmPlatformPkg is a perfect example where code reuse is much more >> >> difficult than it needs to be, and we as maintainers need to deal >> >> with contributors from other companies that have used it as >> >> 'guidance' for how to architect their UEFI firmware, which is usually >> >> filled with vexpress-isms that date back to before anyone currently >> involved with UEFI can remember. >> >> >> >> This is why I have taken the time to sit down, go through all the >> >> crap code, clean it up, refactor it and propose it on the list as >> >> improvements. I even went so far as taking the preparatory Mali work >> >> of your team and rebase it so that we can keep the bits that we may >> >> share, and move the bits out that should not be kept in main EDK2 >> >> because they are being taken as gospel by engineers that are new to >> >> ARM+UEFI. >> >> >> >> If this is too much to deal with for you, then fine, don't upstream your >> code. >> >> But if you do, you are going to have to play nice with the others, >> >> including the maintainers. >> >> >> > [[Evan Lloyd]] Hi Ard. Firstly, I apologize, I assumed from your name that >> you were Dutch and would therefore probably have a lively sense of >> humour. Of course, if I have touched a nerve, that is unfortunate and I'm >> sorry. >> >> No, the apparently blatantly obvious tongue-in-cheek nature of your >> response was completely lost on me. But I know a person who does have a >> lively sense of humour, so next time I will ask him for help. > > [[Evan Lloyd]] I would like to extend my apology. From comments others have > made it is apparent that my wording was too easily interpreted as just > offensive. I shall try and resist the temptation to make such points with > dubious attempts at humour in the future, at least on fora like this where > they are out of place. Het spijt me. > Thanks Evan, I appreciate that. Courier 10pt simply does not convey the nuance in your writing, and I suppose the open source world may have its own idiosyncrasies that are not always obvious to people who are working on the outside. And for the record, you're wrong about me not having a sense of humour: according to my mother, both my jokes are hilarious. ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
[edk2] [PATCH v4 2/2] MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden
Invoke the newly introduced SD/MMC override protocol to override
the capabilities register after reading it from the device registers,
and to call the pre/post host init and reset hooks at the appropriate
times.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c | 35 +++-
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h | 36
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf | 2 +
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 95 ++--
MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 35
5 files changed, 157 insertions(+), 46 deletions(-)
diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
index 0be8828abfcc..f923930bbae9 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
@@ -17,6 +17,8 @@
#include "SdMmcPciHcDxe.h"
+EDKII_SD_MMC_OVERRIDE *mOverride;
+
//
// Driver Global Variables
//
@@ -281,14 +283,14 @@ SdMmcPciHcEnumerateDevice (
//
// Reset the specified slot of the SD/MMC Pci Host Controller
//
-Status = SdMmcHcReset (Private->PciIo, Slot);
+Status = SdMmcHcReset (Private, Slot);
if (EFI_ERROR (Status)) {
continue;
}
//
// Reinitialize slot and restart identification process for the new
attached device
//
-Status = SdMmcHcInitHost (Private->PciIo, Slot,
Private->Capability[Slot]);
+Status = SdMmcHcInitHost (Private, Slot);
if (EFI_ERROR (Status)) {
continue;
}
@@ -601,6 +603,20 @@ SdMmcPciHcDriverBindingStart (
goto Done;
}
+ //
+ // Attempt to locate the singleton instance of the SD/MMC override protocol,
+ // which implements platform specific workarounds for non-standard SDHCI
+ // implementations.
+ //
+ if (mOverride == NULL) {
+Status = gBS->LocateProtocol (&gEdkiiSdMmcOverrideProtocolGuid, NULL,
+(VOID **)&mOverride);
+if (!EFI_ERROR (Status)) {
+ DEBUG ((DEBUG_INFO, "%a: found SD/MMC override protocol\n",
+__FUNCTION__));
+}
+ }
+
Support64BitDma = TRUE;
for (Slot = FirstBar; Slot < (FirstBar + SlotNum); Slot++) {
Private->Slot[Slot].Enable = TRUE;
@@ -609,6 +625,17 @@ SdMmcPciHcDriverBindingStart (
if (EFI_ERROR (Status)) {
continue;
}
+if (mOverride != NULL && mOverride->Capability != NULL) {
+ Status = mOverride->Capability (
+Controller,
+Slot,
+&Private->Capability[Slot]);
+ if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_WARN, "%a: Failed to override capability - %r\n",
+ __FUNCTION__, Status));
+continue;
+ }
+}
DumpCapabilityReg (Slot, &Private->Capability[Slot]);
Support64BitDma &= Private->Capability[Slot].SysBus64;
@@ -627,7 +654,7 @@ SdMmcPciHcDriverBindingStart (
//
// Reset the specified slot of the SD/MMC Pci Host Controller
//
-Status = SdMmcHcReset (PciIo, Slot);
+Status = SdMmcHcReset (Private, Slot);
if (EFI_ERROR (Status)) {
continue;
}
@@ -642,7 +669,7 @@ SdMmcPciHcDriverBindingStart (
continue;
}
-Status = SdMmcHcInitHost (PciIo, Slot, Private->Capability[Slot]);
+Status = SdMmcHcInitHost (Private, Slot);
if (EFI_ERROR (Status)) {
continue;
}
diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
index 6a2a27969936..c683600f2ef2 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
@@ -35,6 +35,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
EXPRESS OR IMPLIED.
#include
#include
#include
+#include
#include
#include "SdMmcPciHci.h"
@@ -43,6 +44,8 @@ extern EFI_COMPONENT_NAME_PROTOCOL gSdMmcPciHcComponentName;
extern EFI_COMPONENT_NAME2_PROTOCOL gSdMmcPciHcComponentName2;
extern EFI_DRIVER_BINDING_PROTOCOL gSdMmcPciHcDriverBinding;
+extern EDKII_SD_MMC_OVERRIDE*mOverride;
+
#define SD_MMC_HC_PRIVATE_SIGNATURE SIGNATURE_32 ('s', 'd', 't', 'f')
#define SD_MMC_HC_PRIVATE_FROM_THIS(a) \
@@ -782,4 +785,37 @@ SdCardIdentification (
IN UINT8 Slot
);
+/**
+ Software reset the specified SD/MMC host controller.
+
+ @param[in] PrivateA pointer to the SD_MMC_HC_PRIVATE_DATA instance.
+ @param[in] Slot The slot number of the SD card to send the command
to.
+
+ @retval EFI_SUCCESS The software reset executes successfully.
+ @retval OthersThe software reset fails.
+
+**/
+EFI_STATUS
+SdMmcHcReset (
+ IN SD_MMC_HC_PRIVATE_DATA *Private,
+ IN UINT8 Slot
+ );
+
+/**
+ I
[edk2] [PATCH v4 1/2] MdeModulePkg: introduce SD/MMC override protocol
Many ARM based SoCs have integrated SDHCI controllers, and often,
these implementations deviate in subtle ways from the pertinent
specifications. On the one hand, these deviations are quite easy
to work around, but on the other hand, having a collection of SoC
specific workarounds in the generic driver stack is undesirable.
So let's introduce an optional SD/MMC override protocol that we
can invoke at the appropriate moments in the device initialization.
That way, the workaround itself remains platform specific, but we
can still use the generic driver stack on such platforms.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel
---
MdeModulePkg/Include/Protocol/SdMmcOverride.h | 97
MdeModulePkg/MdeModulePkg.dec | 3 +
2 files changed, 100 insertions(+)
diff --git a/MdeModulePkg/Include/Protocol/SdMmcOverride.h
b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
new file mode 100644
index ..0d070023f9d3
--- /dev/null
+++ b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
@@ -0,0 +1,97 @@
+/** @file
+ Protocol to describe overrides required to support non-standard SDHCI
+ implementations
+
+ Copyright (c) 2017, Linaro, Ltd. All rights reserved.
+
+ This program and the accompanying materials
+ are licensed and made available under the terms and conditions of the BSD
License
+ which accompanies this distribution. The full text of the license may be
found at
+ http://opensource.org/licenses/bsd-license.php
+
+ THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __SD_MMC_OVERRIDE_H__
+#define __SD_MMC_OVERRIDE_H__
+
+#include
+
+#define EDKII_SD_MMC_OVERRIDE_PROTOCOL_GUID \
+ { 0xeaf9e3c1, 0xc9cd, 0x46db, { 0xa5, 0xe5, 0x5a, 0x12, 0x4c, 0x83, 0x23,
0x23 } }
+
+#define EDKII_SD_MMC_OVERRIDE_PROTOCOL_VERSION0x1
+
+typedef struct _EDKII_SD_MMC_OVERRIDE EDKII_SD_MMC_OVERRIDE;
+
+typedef enum {
+ EdkiiSdMmcResetPre,
+ EdkiiSdMmcResetPost,
+ EdkiiSdMmcInitHostPre,
+ EdkiiSdMmcInitHostPost,
+} EDKII_SD_MMC_PHASE_TYPE;
+
+/**
+
+ Override function for SDHCI capability bits
+
+ @param[in] ControllerHandle The EFI_HANDLE of the controller.
+ @param[in] Slot The 0 based slot index.
+ @param[in,out] SdMmcHcSlotCapability The SDHCI capability structure.
+
+ @retval EFI_SUCCESS The override function completed successfully.
+ @retval EFI_NOT_FOUND The specified controller or slot does not
exist.
+ @retval EFI_INVALID_PARAMETER SdMmcHcSlotCapability is NULL
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI * EDKII_SD_MMC_CAPABILITY) (
+ IN EFI_HANDLE ControllerHandle,
+ IN UINT8 Slot,
+ IN OUT VOID*SdMmcHcSlotCapability
+ );
+
+/**
+
+ Override function for SDHCI controller operations
+
+ @param[in] ControllerHandle The EFI_HANDLE of the controller.
+ @param[in] Slot The 0 based slot index.
+ @param[in] PhaseType The type of operation and whether the
+hook is invoked right before (pre) or
+right after (post)
+
+ @retval EFI_SUCCESS The override function completed successfully.
+ @retval EFI_NOT_FOUND The specified controller or slot does not
exist.
+ @retval EFI_INVALID_PARAMETER PhaseType is invalid
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI * EDKII_SD_MMC_NOTIFY_PHASE) (
+ IN EFI_HANDLE ControllerHandle,
+ IN UINT8 Slot,
+ IN EDKII_SD_MMC_PHASE_TYPE PhaseType
+ );
+
+struct _EDKII_SD_MMC_OVERRIDE {
+ //
+ // Protocol version of this implementation
+ //
+ UINTN Version;
+ //
+ // Callback to override SD/MMC host controller capability bits
+ //
+ EDKII_SD_MMC_CAPABILITY Capability;
+ //
+ // Callback to invoke SD/MMC override hooks
+ //
+ EDKII_SD_MMC_NOTIFY_PHASE NotifyPhase;
+};
+
+extern EFI_GUID gEdkiiSdMmcOverrideProtocolGuid;
+
+#endif
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 856d67aceb21..64ceea029f94 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -562,6 +562,9 @@ [Protocols]
## Include/Protocol/SmmMemoryAttribute.h
gEdkiiSmmMemoryAttributeProtocolGuid = { 0x69b792ea, 0x39ce, 0x402d, { 0xa2,
0xa6, 0xf7, 0x21, 0xde, 0x35, 0x1d, 0xfe } }
+ ## Include/Protocol/SdMmcOverride.h
+ gEdkiiSdMmcOverrideProtocolGuid = { 0xeaf9e3c1, 0xc9cd, 0x46db, { 0xa5,
0xe5, 0x5a, 0x12, 0x4c, 0x83, 0x23, 0x23 } }
+
#
# [Error.gEfiMdeModulePkgTokenSpaceGuid]
# 0x8001 | Invalid value provided.
--
2.11.0
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/
