Re: [edk2] [Patch 09/11] IntelFsp2Pkg: Update Section Name in INF files

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Gao, Liming
> Sent: Monday, September 25, 2017 7:06 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen 
> Subject: [Patch 09/11] IntelFsp2Pkg: Update Section Name in INF files
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao 
> Cc: Jiewen Yao 
> ---
>  IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.inf  | 3
> +--
>  .../Library/BaseCacheAsRamLibNull/BaseCacheAsRamLibNull.inf | 6
> +++---
>  IntelFsp2Pkg/Library/BaseCacheLib/BaseCacheLib.inf  | 6
> +++---
>  3 files changed, 7 insertions(+), 8 deletions(-)
> 
> diff --git a/IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.inf
> b/IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.inf
> index 75f7ae5..a0bc375 100644
> --- a/IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.inf
> +++ b/IntelFsp2Pkg/FspNotifyPhase/FspNotifyPhasePeim.inf
> @@ -1,8 +1,7 @@
>  ## @file
>  # Component information file for the FSP notify phase PEI module.
>  #
> -#@copyright
> -#  Copyright (c) 2016 Intel Corporation. All rights reserved.
> +#  Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD
> License
>  #  which accompanies this distribution.  The full text of the license may be
> found at
> diff --git
> a/IntelFsp2Pkg/Library/BaseCacheAsRamLibNull/BaseCacheAsRamLibNull.inf
> b/IntelFsp2Pkg/Library/BaseCacheAsRamLibNull/BaseCacheAsRamLibNull.inf
> index bdb6744..6a77ce7 100644
> --- a/IntelFsp2Pkg/Library/BaseCacheAsRamLibNull/BaseCacheAsRamLibNull.inf
> +++
> b/IntelFsp2Pkg/Library/BaseCacheAsRamLibNull/BaseCacheAsRamLibNull.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  #  NULL instance of Base cache as RAM.
>  #
> -#  Copyright (c) 2014 - 2015, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
>  #
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD
> License
> @@ -12,7 +12,7 @@
>  #
>  ##
> 
> -[defines]
> +[Defines]
>INF_VERSION= 0x00010005
>BASE_NAME  = BaseCacheAsRamLibNull
>FILE_GUID  =
> 630AEB10-2106-4234-9DB3-836A3663F50D
> @@ -20,7 +20,7 @@
>VERSION_STRING = 1.0
>LIBRARY_CLASS  = CacheAsRamLib
> 
> -[sources.common]
> +[Sources.common]
>DisableCacheAsRamNull.c
> 
>  [Packages]
> diff --git a/IntelFsp2Pkg/Library/BaseCacheLib/BaseCacheLib.inf
> b/IntelFsp2Pkg/Library/BaseCacheLib/BaseCacheLib.inf
> index 7b026b1..34df6ad 100644
> --- a/IntelFsp2Pkg/Library/BaseCacheLib/BaseCacheLib.inf
> +++ b/IntelFsp2Pkg/Library/BaseCacheLib/BaseCacheLib.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  #  Instance of BaseCache.
>  #
> -#  Copyright (c) 2014 - 2015, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
>  #
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD
> License
> @@ -12,7 +12,7 @@
>  #
>  ##
> 
> -[defines]
> +[Defines]
>INF_VERSION= 0x00010005
>BASE_NAME  = BaseCacheLib
>FILE_GUID  =
> 8EF3A653-DA8B-4FFA-BB85-FF47406DB9F0
> @@ -20,7 +20,7 @@
>VERSION_STRING = 1.0
>LIBRARY_CLASS  = CacheLib
> 
> -[sources.IA32]
> +[Sources.IA32]
>CacheLib.c
>CacheLibInternal.h
> 
> --
> 2.8.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 10/11] IntelFsp2WrapperPkg: Update Protocol/Guid usage in INF files

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Gao, Liming
> Sent: Monday, September 25, 2017 7:06 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen 
> Subject: [Patch 10/11] IntelFsp2WrapperPkg: Update Protocol/Guid usage in INF
> files
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao 
> Cc: Jiewen Yao 
> ---
>  IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.inf  | 6
> +++---
>  IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf  | 9
> ++---
>  IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf  | 6
> +++---
>  .../Library/PeiFspWrapperApiTestLib/PeiFspWrapperApiTestLib.inf  | 4 ++--
>  4 files changed, 10 insertions(+), 15 deletions(-)
> 
> diff --git
> a/IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.inf
> b/IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.inf
> index 54c2cbf..ce3bfa0 100644
> --- a/IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.inf
> +++ b/IntelFsp2WrapperPkg/FspWrapperNotifyDxe/FspWrapperNotifyDxe.inf
> @@ -3,7 +3,7 @@
>  #
>  # This driver will register two callbacks to call fsp's notifies.
>  #
> -#  Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
>  #
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD
> License
> @@ -53,10 +53,10 @@
> 
>  [Protocols]
>gEfiPciEnumerationCompleteProtocolGuid## CONSUMES
> -  gAddPerfRecordProtocolGuid## CONSUMES
> +  gAddPerfRecordProtocolGuid##
> SOMETIMES_CONSUMES
> 
>  [Guids]
> -  gFspApiPerformanceGuid## CONSUMES ##
> GUID
> +  gFspApiPerformanceGuid##
> SOMETIMES_CONSUMES ## GUID
>gEfiEventExitBootServicesGuid ## CONSUMES ##
> Event
>gFspHobGuid   ## CONSUMES ##
> HOB
> 
> diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> index 0901a14..2b3d240 100644
> --- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> +++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
> @@ -6,7 +6,7 @@
>  # register TemporaryRamDonePpi to call TempRamExit API, and register
> MemoryDiscoveredPpi
>  # notify to call FspSiliconInit API.
>  #
> -#  Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
>  #
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD
> License
> @@ -64,14 +64,9 @@
>  [Sources]
>FspmWrapperPeim.c
> 
> -[Ppis]
> -  gTopOfTemporaryRamPpiGuid ## PRODUCES
> -  gEfiEndOfPeiSignalPpiGuid ## PRODUCES
> -  gEfiPeiMemoryDiscoveredPpiGuid## PRODUCES
> -
>  [Guids]
>gFspHobGuid   ## PRODUCES ## HOB
> -  gFspApiPerformanceGuid## CONSUMES ## GUID
> +  gFspApiPerformanceGuid## SOMETIMES_CONSUMES ##
> GUID
> 
>  [Depex]
>gEfiPeiMasterBootModePpiGuid
> diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
> b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
> index 261278f..c858e70 100644
> --- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
> +++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
> @@ -6,7 +6,7 @@
>  # register TemporaryRamDonePpi to call TempRamExit API, and register
> MemoryDiscoveredPpi
>  # notify to call FspSiliconInit API.
>  #
> -#  Copyright (c) 2014 - 2016, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2014 - 2017, Intel Corporation. All rights reserved.
>  #
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD
> License
> @@ -63,14 +63,14 @@
>gFspSiliconInitDonePpiGuid## PRODUCES
>gEfiEndOfPeiSignalPpiGuid ## PRODUCES
>gEfiTemporaryRamDonePpiGuid   ## PRODUCES
> -  gEfiPeiMemoryDiscoveredPpiGuid## PRODUCES
> +  gEfiPeiMemoryDiscoveredPpiGuid## NOTIFY
> 
>  [Pcd]
>gIntelFsp2WrapperTokenSpaceGuid.PcdFspsBaseAddress  ## CONSUMES
> 
>  [Guids]
>gFspHobGuid   ## CONSUMES ## HOB
> -  gFspApiPerformanceGuid## CONSUMES ## GUID
> +  gFspApiPerformanceGuid## SOMETIMES_CONSUMES ##
> GUID
> 
>  [Sources]
>FspsWrapperPeim.c
> diff --git
> a/IntelFsp2WrapperPkg/Library/PeiFspWrapperApiTestLib/PeiFspWrapperApiTes
> tLib.inf
> b/IntelFsp2WrapperPkg/Library/PeiFspWrapperApiTestLib/PeiFspWrapperApiTe
> stLib.inf
> index fbbcf30..1a5029b 100644
> ---
> a/IntelFsp2WrapperPkg/Library/PeiFspWrapperApiTestLib/PeiFspWrapperApiTes
> tLib.inf
> +++
> b/IntelFsp2Wrap

Re: [edk2] [Patch 07/11] SignedCapsulePkg: Update Guid usage in INF file to match source code logic

[Yao, Jiewen]

Reviewed-by: jiewen@intel.com

> -Original Message-
> From: Gao, Liming
> Sent: Monday, September 25, 2017 7:06 PM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen 
> Subject: [Patch 07/11] SignedCapsulePkg: Update Guid usage in INF file to 
> match
> source code logic
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao 
> Cc: Jiewen Yao 
> ---
>  .../Library/EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.inf  | 12 
> ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git
> a/SignedCapsulePkg/Library/EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.inf
> b/SignedCapsulePkg/Library/EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.inf
> index a7c9607..a21e75c 100644
> ---
> a/SignedCapsulePkg/Library/EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.inf
> +++
> b/SignedCapsulePkg/Library/EdkiiSystemCapsuleLib/EdkiiSystemCapsuleLib.inf
> @@ -3,7 +3,7 @@
>  #
>  #  EDKII System Capsule library instance for DXE/PEI post memory phase.
>  #
> -#  Copyright (c) 2016, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2016 - 2017, Intel Corporation. All rights reserved.
>  #  This program and the accompanying materials
>  #  are licensed and made available under the terms and conditions of the BSD
> License
>  #  which accompanies this distribution.  The full text of the license may be
> found at
> @@ -53,9 +53,9 @@
>gEfiSecurityPkgTokenSpaceGuid.PcdPkcs7CertBuffer
> ## CONSUMES
> 
>  [Guids]
> -  gEdkiiSystemFirmwareImageDescriptorFileGuid  ## CONSUMES
> ## GUID
> -  gEdkiiSystemFmpCapsuleConfigFileGuid ## CONSUMES
> ## GUID
> -  gEdkiiSystemFmpCapsuleDriverFvFileGuid   ## CONSUMES
> ## GUID
> -  gEfiCertPkcs7Guid## CONSUMES
> ## GUID
> -  gEfiCertTypeRsa2048Sha256Guid## CONSUMES
> ## GUID
> +  gEdkiiSystemFirmwareImageDescriptorFileGuid  ##
> SOMETIMES_CONSUMES   ## GUID
> +  gEdkiiSystemFmpCapsuleConfigFileGuid ##
> SOMETIMES_CONSUMES   ## GUID
> +  gEdkiiSystemFmpCapsuleDriverFvFileGuid   ##
> SOMETIMES_CONSUMES   ## GUID
> +  gEfiCertPkcs7Guid##
> SOMETIMES_CONSUMES   ## GUID
> +  gEfiCertTypeRsa2048Sha256Guid##
> SOMETIMES_CONSUMES   ## GUID
> 
> --
> 2.8.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] TFTP : tftp fix for full volume case

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni 

Thanks/Ray

> -Original Message-
> From: Carsey, Jaben
> Sent: Monday, October 9, 2017 10:13 PM
> To: Meenakshi Aggarwal ; Fu, Siyuan
> ; edk2-devel@lists.01.org; Ni, Ruiyu
> ; Ye, Ting 
> Subject: RE: [PATCH v2] TFTP : tftp fix for full volume case
> 
> I am fine. Ray?
> 
> Reviewed-by: Jaben Carsey 
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Meenakshi Aggarwal
> > Sent: Sunday, October 08, 2017 11:28 PM
> > To: Fu, Siyuan ; edk2-devel@lists.01.org; Ni,
> > Ruiyu ; Carsey, Jaben ;
> > Ye, Ting 
> > Subject: Re: [edk2] [PATCH v2] TFTP : tftp fix for full volume case
> > Importance: High
> >
> > Hi Team,
> >
> >
> > Any further comments on this patch?
> >
> > Or is it ready to merge in edk2?
> >
> >
> > Thanks,
> > Meenakshi
> >
> > > -Original Message-
> > > From: Meenakshi Aggarwal
> > > Sent: Wednesday, September 27, 2017 9:01 AM
> > > To: 'Fu, Siyuan' ; edk2-devel@lists.01.org; Ni,
> > > Ruiyu ; Carsey, Jaben ;
> > > Ye, Ting 
> > > Cc: Udit Kumar ; Vabhav Sharma
> > > 
> > > Subject: RE: [PATCH v2] TFTP : tftp fix for full volume case
> > >
> > > Hi,
> > >
> > > Thanks for the review Siyuan.
> > >
> > >
> > > Ting,
> > >
> > > Any comment from your side?
> > >
> > > Thanks,
> > > Meenakshi
> > >
> > > > -Original Message-
> > > > From: Fu, Siyuan [mailto:siyuan...@intel.com]
> > > > Sent: Tuesday, September 26, 2017 6:12 AM
> > > > To: Meenakshi Aggarwal ; edk2-
> > > > de...@lists.01.org; Ni, Ruiyu ; Carsey, Jaben
> > > > 
> > > > Cc: ard.biesheu...@linaro.org; leif.lindh...@linaro.org; Ye, Ting
> > > > ; Udit Kumar ; Vabhav
> > Sharma
> > > > 
> > > > Subject: RE: [PATCH v2] TFTP : tftp fix for full volume case
> > > >
> > > > Reviewed-by: Fu Siyuan 
> > > >
> > > > -Original Message-
> > > > From: Meenakshi Aggarwal [mailto:meenakshi.aggar...@nxp.com]
> > > > Sent: Monday, September 25, 2017 11:06 PM
> > > > To: edk2-devel@lists.01.org; Ni, Ruiyu ;
> > > > Carsey, Jaben 
> > > > Cc: ard.biesheu...@linaro.org; leif.lindh...@linaro.org; Fu,
> > > > Siyuan ; Ye, Ting ;
> > > > Meenakshi Aggarwal ; Udit Kumar
> > > > ; Vabhav Sharma 
> > > > Subject: [PATCH v2] TFTP : tftp fix for full volume case
> > > >
> > > > Issue :
> > > > When storage media is full, tftp was resulting in ASSERT
> > > > MdeModulePkg/Core/Dxe/Mem/Page.c, because number of pages was
> > > zero.
> > > >
> > > > Reason:
> > > > While doing tftp, function call ShellWriteFile was modifying
> > > > FileSize
> > variable.
> > > > In case of full disk it was coming out to be Zero.
> > > >
> > > > Fix:
> > > > Storage the original filesize in local variable, and use this
> > > > variable while freeing the pages.
> > > >
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Udit Kumar 
> > > > Signed-off-by: Meenakshi Aggarwal 
> > > > Signed-off-by: Vabhav Sharma 
> > > > Signed-off-by: Meenakshi Aggarwal 
> > > > ---
> > > >  ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c | 5 -
> > > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > > > b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > > > index 5c50797..fbde3bf 100755
> > > > --- a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > > > +++ b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > > > @@ -284,6 +284,7 @@ ShellCommandRunTftp (
> > > >EFI_HANDLE  Mtftp4ChildHandle;
> > > >EFI_MTFTP4_PROTOCOL *Mtftp4;
> > > >UINTN   FileSize;
> > > > +  UINTN   DataSize;
> > > >VOID*Data;
> > > >SHELL_FILE_HANDLE   FileHandle;
> > > >UINT16  BlockSize;
> > > > @@ -294,6 +295,7 @@ ShellCommandRunTftp (
> > > >AsciiRemoteFilePath = NULL;
> > > >Handles = NULL;
> > > >FileSize= 0;
> > > > +  DataSize= 0;
> > > >BlockSize   = MTFTP_DEFAULT_BLKSIZE;
> > > >
> > > >//
> > > > @@ -537,6 +539,7 @@ ShellCommandRunTftp (
> > > >goto NextHandle;
> > > >  }
> > > >
> > > > +DataSize = FileSize;
> > > >  Status = ShellWriteFile (FileHandle, &FileSize, Data);
> > > >  if (!EFI_ERROR (Status)) {
> > > >ShellStatus = SHELL_SUCCESS; @@ -551,7 +554,7 @@
> > > > ShellCommandRunTftp (
> > > >  NextHandle:
> > > >
> > > >  if (Data != NULL) {
> > > > -  gBS->FreePages ((EFI_PHYSICAL_ADDRESS)(UINTN)Data,
> > > > EFI_SIZE_TO_PAGES (FileSize));
> > > > +  gBS->FreePages ((EFI_PHYSICAL_ADDRESS)(UINTN)Data,
> > > > + EFI_SIZE_TO_PAGES (DataSize));
> > > >  }
> > > >
> > > >  CloseProtocolAndDestroyServiceChild (
> > > > --
> > > > 1.9.1
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk

Re: [edk2] [PATCH 0/6] MdeModulePkg/VariableSmm: fix MOR / MorLock inconsistency

[Yao, Jiewen]

Thanks.
Please use ASSERT() when you check in.

Series Reviewed-by: jiewen@intel.com


From: Laszlo Ersek [mailto:ler...@redhat.com]
Sent: Wednesday, October 4, 2017 6:40 PM
To: Yao, Jiewen ; edk2-devel-01 
Cc: Dong, Eric ; Ladi Prosek ; Zeng, 
Star 
Subject: Re: [PATCH 0/6] MdeModulePkg/VariableSmm: fix MOR / MorLock 
inconsistency

On 10/04/17 03:18, Yao, Jiewen wrote:
> Thanks. Laszlo.
> This patch looks good to me in general.
>
> One minor comment is below:
> MorLockInitAtEndOfDxe()
> +  if (!mMorLockInitializationRequired) {
> +//
> +// The EFI_SMM_FAULT_TOLERANT_WRITE_PROTOCOL has never been installed, 
> thus
> +// the variable write service is unavailable. Do nothing.
> +//
> +return;
> +  }
> I think it is an illegal case. I would add ASSERT before return.

OK, I will replace the sentence "Do nothing." with "This should never
happen.", and also add ASSERT (FALSE) above the "return".

> And I hope Ladi can help us double confirm if this patch fixed the device 
> guard problem. :-)

Right!

Ladi stated in the RHBZ that he had built OVMF; I'll talk with him
off-list regardless, to see if I can help with anything.

Thank you Jiewen!
Laszlo


>
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Wednesday, October 4, 2017 5:28 AM
>> To: edk2-devel-01 mailto:edk2-devel@lists.01.org>>
>> Cc: Dong, Eric mailto:eric.d...@intel.com>>; Yao, 
>> Jiewen mailto:jiewen@intel.com>>; Ladi
>> Prosek mailto:lpro...@redhat.com>>; Zeng, Star 
>> mailto:star.z...@intel.com>>
>> Subject: [PATCH 0/6] MdeModulePkg/VariableSmm: fix MOR / MorLock
>> inconsistency
>>
>> Repo:   https://github.com/lersek/edk2.git
>> Branch: mor_lock_init_at_end_of_dxe
>>
>> This patch set fixes the issue reported in the following items:
>>
>> * Inconsistent MOR control variables exposed by OVMF, breaks Windows
>>   Device Guard
>>
>>   https://bugzilla.redhat.com/show_bug.cgi?id=1496170
>>
>> * VariableSmm MorLockInit(): create MORLock only if / after MOR exists
>>
>>   https://bugzilla.tianocore.org/show_bug.cgi?id=727
>>
>> Patches #1 through #3 are cleanups.
>>
>> Patch #4 is a small helper patch for patch #5.
>>
>> Patch #5 is the actual fix, following Jiewen's suggestions from the
>> edk2-devel thread
>>
>> * [edk2] multiple levels of support for MOR / MORLock
>>
>>   https://lists.01.org/pipermail/edk2-devel/2017-September/015444.html
>>   https://lists.01.org/pipermail/edk2-devel/2017-October/015530.html
>>
>> Patch #6 is a workaround for some OSes (minimally Fedora 24-26, and some
>> Debian versions) that create the MOR variable even if the platform
>> doesn't offer it up-front. This patch also follows Jiewen's suggestion
>> from the same edk2-devel thread.
>>
>> (
>>
>> BTW, at Paolo's recommendation, I've now reported this kernel issue for
>> Fedora, under
>>
>> * incorrect downstream-only Platform Reset Attack Mitigation patch in
>>   the F24-F26 kernels
>>
>>   https://bugzilla.redhat.com/show_bug.cgi?id=1498159
>>
>> )
>>
>> I've checked this set for basic regressions, using OVMF, normal boot and
>> S3 suspend/resume:
>>
>> * Q35, SMM, IA32:
>>   - Fedora 25 -- verified patch #6 specifically
>>
>> * i440fx, no SMM, X64:
>>   - Fedora 24
>>
>> * Q35, SMM, IA32X64:
>>   - Fedora 26 -- verified patch #6 specifically
>>   - Windows 7
>>   - Windows 8.1
>>   - Windows 10
>>   - Windows Server 2008 R2
>>   - Windows Server 2012 R2
>>
>> I didn't / couldn't test this set in the following two environments:
>>
>> - on platforms where TcgMor.inf is included in the firmware, and the MOR
>>   variable exists genuinely,
>>
>> - in the nested virt setup where Ladi reported the Device Guard
>>   breakage. (If I understand correctly, ATM this requires additional
>>   host kernel (KVM) patches.)
>>
>> Test results / feedback from those envs would be appreciated.
>>
>> Cc: Eric Dong mailto:eric.d...@intel.com>>
>> Cc: Jiewen Yao mailto:jiewen@intel.com>>
>> Cc: Ladi Prosek mailto:lpro...@redhat.com>>
>> Cc: Star Zeng mailto:star.z...@intel.com>>
>>
>> Thanks,
>> Laszlo
>>
>> Laszlo Ersek (6):
>>   MdeModulePkg/Variable/RuntimeDxe: move SecureBootHook() decl to new
>> header
>>   MdeModulePkg/Variable/RuntimeDxe: move MOR func. declarations to
>> header
>>   MdeModulePkg/Variable/RuntimeDxe: introduce MorLockInitAtEndOfDxe()
>> hook
>>   MdeModulePkg/Variable/RuntimeDxe: permit MorLock deletion for passthru
>> req
>>   MdeModulePkg/Variable/RuntimeDxe: delay MorLock creation until
>> EndOfDxe
>>   MdeModulePkg/Variable/RuntimeDxe: delete and lock OS-created MOR
>> variable
>>
>>  MdeModulePkg/Universal/Variable/RuntimeDxe/Measurement.c
>> |   2 +
>>  MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h|
>> 89 ++
>>  MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
>> |  45 +++--
>>  MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
>> | 173 ++--
>>  MdeModulePkg/Universa

Re: [edk2] [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and lock OS-created MOR variable

[Yao, Jiewen]

Yes, option a) looks good to me. A simple patch is good enough in this case.

In addition, this original patch passed our validation with MOR and MORL.
The series is reviewed-by: jiewen@intel.com

We can treat a) in another patch.

Thank you
Yao Jiewen

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Monday, October 9, 2017 11:21 PM
To: Zeng, Star ; edk2-devel-01 
Cc: Yao, Jiewen ; Dong, Eric 
Subject: Re: [edk2] [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and 
lock OS-created MOR variable

On 10/09/17 09:12, Zeng, Star wrote:
> Laszlo,
>
> Do you think VariableRuntimeDxe(TcgMorLockDxe.c) also needs to delete and 
> lock OS-created MOR variable?

Maybe -- I'm not sure.

If an edk2 platform uses "VariableRuntimeDxe", then it cannot securely
support MorLock, that's for sure. However, the same platform might still
support plain MOR.

How can we determine if the platform wants to support MOR? Should we
again look for the presence of the TCG / TCG2 protocols? I cannot tell
if TcgMor.inf, and other modules under SecurityPkg, intend to support a
"no-SMM" configuration.

So I can only give you a conditional answer:

(a) If an edk2 platform can *never* sensibly support plain MOR without
SMM, then yes, we should delete and lock the MOR variable in
"TcgMorLockDxe.c", function MorLockInit().

(b) If an edk2 platform *may* opt to support plain MOR (but not MorLock)
without SMM, then we should apply the same End-of-Dxe trick as in the
SMM case. This is however quite a bit of development and I suggest that
we postpone it -- file a BZ about it -- until an edk2 platform actually
needs this. (It looks like a quite unlikely use case though: MOR is a
security feature that is not really secure without MorLock, and MorLock
is insecure without SMM. So one might reason that MOR-without-SMM is
useless.)

(c) We can also say "we don't care", because, technically speaking, no
inconsistency between the MOR and MorLock variables can be created in
the "no-SMM" case (because it is never possible to create MorLock
without MOR -- since creating MorLock is prevented already).

So, I don't know. If Jiewen thinks that "MOR without SMM" is useless
(because it is inherently insecure --> option (a)), I can append a small
patch #7, in order to delete and lock MOR too, in MorLockInit()
[TcgMorLockDxe.c].


Here's another idea: if the "no SMM" case requires extra thinking and
regression testing (i.e. the patch would be more complex than simple MOR
deletion + locking) , can we go ahead with this series for now, and file
a TianoCore BZ about the "no SMM" case? (I should say in advance that
I'm not volunteering to address the "no SMM" Bugzilla any time soon; I
don't know much (yet) about the TCG modules in SecurityPkg, and I think
I won't have time for the investigation in the next weeks.)

Jiewen, what do you say?

Thanks!
Laszlo

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Wednesday, October 4, 2017 5:29 AM
> To: edk2-devel-01 mailto:edk2-devel@lists.01.org>>
> Cc: Dong, Eric mailto:eric.d...@intel.com>>; Yao, Jiewen 
> mailto:jiewen@intel.com>>; Ladi Prosek 
> mailto:lpro...@redhat.com>>; Zeng, Star 
> mailto:star.z...@intel.com>>
> Subject: [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and lock 
> OS-created MOR variable
>
> According to the TCG Platform Reset Attack Mitigation Specification (May 15, 
> 2008):
>
>> 5 Interface for UEFI
>> 5.1 UEFI Variable
>> 5.1.1 The MemoryOverwriteRequestControl
>>
>> Start of informative comment:
>>
>> [...] The OS loader should not create the variable. Rather, the
>> firmware is required to create it and must support the semantics described 
>> here.
>>
>> End of informative comment.
>
> However, some OS kernels create the MOR variable even if the platform 
> firmware does not support it (see one Bugzilla reference below). This OS 
> issue breaks the logic added in the last patch.
>
> Strengthen the MOR check by searching for the TCG or TCG2 protocols, as 
> edk2's implementation of MOR depends on (one of) those protocols.
>
> The protocols are defined under MdePkg, thus there's no inter-package 
> dependency issue. In addition, calling UEFI services in
> MorLockInitAtEndOfDxe() is safe, due to the following order of events /
> actions:
>
> - platform BDS signals the EndOfDxe event group,
> - the SMM core installs the SmmEndOfDxe protocol,
> - MorLockInitAtEndOfDxe() is invoked, and it calls UEFI services,
> - some time later, platform BDS installs the DxeSmmReadyToLock protocol,
> - SMM / SMRAM is locked down and UEFI services become unavailable to SMM
>   drivers.
>
> Cc: Eric Dong mailto:eric.d...@intel.com>>
> Cc: Jiewen Yao mailto:jiewen@intel.com>>
> Cc: Ladi Prosek mailto:lpro...@redhat.com>>
> Cc: Star Zeng mailto:star.z...@intel.com>>
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1498159
> Suggested-by: Jiewen Yao mailto:jiewen@intel.com>>
> Contribute

Re: [edk2] Request to display Initiator IP in ISCSI Attempt Page

[Karunakar P]

Hi Jiaxin,

Thanks for your support.

I've created a ticket in Bugzilla, and below are the details
https://bugzilla.tianocore.org/show_bug.cgi?id=732

Yeah we should  grayout the Initiator info to indicate it's un-configurable.

In case of IPv6

1.   Before trying for ISCSI connection(with IPv6 attempt), we'll configure 
the IP manually.

2.   While trying for ISCSI Connection(with IPv6 attempt), It may use the 
above Configured IP or link local address.

3.   Can we display the whatever IP used for ISCSI connection(with IPv6 
attempt) as Initiator IP In IP6 attempt Page? , So that we can know what 
Initiator IP used for ISCSI connection.


Could you please let me know if anything is wrong.

Thanks,
Karunakar

From: Wu, Jiaxin [mailto:jiaxin...@intel.com]
Sent: Tuesday, October 10, 2017 8:07 AM
To: Karunakar P; 'edk2-devel@lists.01.org'
Cc: Fu, Siyuan; Ye, Ting
Subject: RE: Request to display Initiator IP in ISCSI Attempt Page

Hi Karunakar,

We agree to add this feature for the Initiator info of IPv4 when DHCP enabled. 
Can you report it on Bugzilla first?

To achieve that,  we can grayout the Initiator IP/Subnet/Gateway if Initiator 
DHCP enabled to indicate it's un-configurable. For IPv6, since iSCSI only 
request the target info from DHCP server, so, it's unnecessary to display the 
info as IPv4.

Thanks,
Jiaxin


From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Friday, October 6, 2017 5:28 PM
To: 'edk2-devel@lists.01.org' 
mailto:edk2-devel@lists.01.org>>
Cc: Fu, Siyuan mailto:siyuan...@intel.com>>; Wu, Jiaxin 
mailto:jiaxin...@intel.com>>; Ye, Ting 
mailto:ting...@intel.com>>
Subject: RE: Request to display Initiator IP in ISCSI Attempt Page

Hello All,

We have a requirement to display Initiator IP in ISCSI Configuration Page when 
Initiator info is enabled for DHCP, find detailed description below.


1.   Add an Attempt with Initiator info Enabled for DHCP

2.   Save changes

3.   On next reboot, Previously added ISCSI attempt will be tried and ISCSI 
DHCP server will assign an IP to the client (Initiator IP).

4.   It is better to display Initiator IP in same attempt Page like below



Ex:- Initiator IP : 192.168.0.5 // DHCP Process was success

 Initiator IP : 0.0.0.0 // DHCP process failed

Could you please provide your comments to support this feature?

Thanks,
Karunakar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/PciHostBridgeDxe: Fixed PCI DMA Map/Umap bounce buffer

[Daniil Egranov]

Hi Ard, Ray,

Thanks for your comments.

On 10/09/2017 07:23 AM, Ard Biesheuvel wrote:

On 9 October 2017 at 11:40, Ard Biesheuvel  wrote:

On 9 October 2017 at 08:42, Ni, Ruiyu  wrote:

The "read"/"write" is from the Bus Master's point of view.


Thanks/Ray


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Daniil
Egranov
Sent: Monday, October 9, 2017 9:16 AM
To: edk2-devel@lists.01.org
Cc: leif.lindh...@linaro.org; Zeng, Star ;
ard.biesheu...@linaro.org
Subject: [edk2] [PATCH] MdeModulePkg/PciHostBridgeDxe: Fixed PCI DMA
Map/Umap bounce buffer

The patch corrects the logic of transferring data between a bounce buffer and a
real buffer above 4GB:
1. In the case of mapping a bounce buffer for the write operation, data from a
real buffer should be copied into a bounce buffer.
2.In the case of unmapping a bounce buffer for the read operation, data should
be copied from a bounce buffer into a real buffer.

The patch resolves a Juno board issue with the the grub and SATA drives.


I am intrigued by this.

So as I suggested, this has to do with 64-bit DMA, but not in the way
I suspected. UEFI itself never hits this code path, because it runs
entirely < 32 GB, but as soon as GRUB starts allocating loader data
and use it for DMA, the bounce buffering kicks in because apparently,
the SATA controller is not 64-bit DMA capable.

Are you using the SataSiI3132Dxe driver on Juno? Does this help at all?

diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
index 2fb5fd68db01..a938563ebdd6 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
@@ -104,7 +104,7 @@ SiI3132AtaPassThruCommand (
  }

  Status = PciIo->Map (
-   PciIo, EfiPciIoOperationBusMasterRead,
+   PciIo, EfiPciIoOperationBusMasterWrite,
 Packet->InDataBuffer, &InDataBufferLength,
&PhysInDataBuffer, &PciAllocMapping
 );
  if (EFI_ERROR (Status)) {
@@ -139,7 +139,7 @@ SiI3132AtaPassThruCommand (
  OutDataBufferLength = Packet->OutTransferLength * SataDevice->BlockSize;

  Status = PciIo->Map (
-   PciIo, EfiPciIoOperationBusMasterWrite,
+   PciIo, EfiPciIoOperationBusMasterRead,
 Packet->OutDataBuffer, &OutDataBufferLength,
&PhysOutDataBuffer, &PciAllocMapping
 );
  if (EFI_ERROR (Status)) {

Also, it might make sense to find out if the hardware is really not
64-bit DMA capable, or whether the driver simply fails to set the
EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
Swapping the EfiPciIoOperationBusMasterRead and 
EfiPciIoOperationBusMasterWrite operations in the SiI3132AtaPassThru.c 
fixes the problem as well. The driver's patch will be the correct fix 
for this issue. I think i missed the point what these operations are 
from the Bus Master's perspective.


The old PciHostBridge Juno driver was using NullDmaLib so it was direct 
mapping. That explains why the SataSiI3132Dxe worked with the original 
host bridge driver and failed with the new one.


Thanks,
Daniil
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Different ISCSI behavior when 2 attempts are added

[Karunakar P]

Will try with Updating to "Enabled for MPIO".

Thanks for your great support,
Karunakar

From: Ye, Ting [mailto:ting...@intel.com]
Sent: Tuesday, October 10, 2017 8:39 AM
To: Wu, Jiaxin; Karunakar P; 'edk2-devel@lists.01.org'
Cc: Fu, Siyuan
Subject: RE: Different ISCSI behavior when 2 attempts are added

Yes, I agree that it is the implementation's choice. If you need Attempt 1 in 
Case 2&4, try to update "Enabled" to "Enabled for MPIO".

Thanks,
Ting Ye

From: Wu, Jiaxin
Sent: Tuesday, October 10, 2017 11:01 AM
To: Karunakar P mailto:karunak...@amiindia.co.in>>; 
'edk2-devel@lists.01.org' 
mailto:edk2-devel@lists.01.org>>
Cc: Ye, Ting mailto:ting...@intel.com>>; Fu, Siyuan 
mailto:siyuan...@intel.com>>
Subject: RE: Different ISCSI behavior when 2 attempts are added

Hi Karunakar,

I think it's not the bug according the current  iSCSI implementation that the 
first login session will be selected while others are aborted directly. Here, 
IP4 is the first login session.

I didn't find any state that the first attempt should be connected. Ting and 
Siyuan, If anything wrong, please correct me.

Thanks,
Jiaxin

From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Monday, October 9, 2017 10:52 PM
To: 'edk2-devel@lists.01.org' 
mailto:edk2-devel@lists.01.org>>
Cc: Wu, Jiaxin mailto:jiaxin...@intel.com>>; Ye, Ting 
mailto:ting...@intel.com>>; Fu, Siyuan 
mailto:siyuan...@intel.com>>
Subject: Re: Different ISCSI behavior when 2 attempts are added

Hello All,

Found the below behavior when I try for ISCSI connection with 2 Valid attempts.

Case 1:
Attempt 1---Enabled(ISCSI Mode)---IP4Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP6Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but 
session does not exist

Case 2:
Attempt 1---Enabled(ISCSI Mode)---IP6Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP4Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but 
session does not exist

Case 3:
Attempt 1---Enabled(ISCSI Mode)---Autoconfigure --->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP6Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but 
session does not exist

Case 4:
Attempt 1---Enabled(ISCSI Mode)---IP6--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---Autoconfigure Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but 
session does not exist



1.   Case1 & Case3 looks fine as 1st valid attempt connected

2.   But Case2 & Case4 looks bit different, 1St attempt was valid but 
connection success with 2nd attempt

3.   As we found that IScsiIp4 Driver Binding Start is getting call first 
and processing the IP4 attempt first even though it is 2nd attempt

Could you please comment on this whether this is a bug or Not?

Thanks,
Karunakar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Different ISCSI behavior when 2 attempts are added

[Ye, Ting]

Yes, I agree that it is the implementation's choice. If you need Attempt 1 in 
Case 2&4, try to update "Enabled" to "Enabled for MPIO".

Thanks,
Ting Ye

From: Wu, Jiaxin
Sent: Tuesday, October 10, 2017 11:01 AM
To: Karunakar P ; 'edk2-devel@lists.01.org' 

Cc: Ye, Ting ; Fu, Siyuan 
Subject: RE: Different ISCSI behavior when 2 attempts are added

Hi Karunakar,

I think it's not the bug according the current  iSCSI implementation that the 
first login session will be selected while others are aborted directly. Here, 
IP4 is the first login session.

I didn't find any state that the first attempt should be connected. Ting and 
Siyuan, If anything wrong, please correct me.

Thanks,
Jiaxin

From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Monday, October 9, 2017 10:52 PM
To: 'edk2-devel@lists.01.org' 
mailto:edk2-devel@lists.01.org>>
Cc: Wu, Jiaxin mailto:jiaxin...@intel.com>>; Ye, Ting 
mailto:ting...@intel.com>>; Fu, Siyuan 
mailto:siyuan...@intel.com>>
Subject: Re: Different ISCSI behavior when 2 attempts are added

Hello All,

Found the below behavior when I try for ISCSI connection with 2 Valid attempts.

Case 1:
Attempt 1---Enabled(ISCSI Mode)---IP4Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP6Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but 
session does not exist

Case 2:
Attempt 1---Enabled(ISCSI Mode)---IP6Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP4Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but 
session does not exist

Case 3:
Attempt 1---Enabled(ISCSI Mode)---Autoconfigure --->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP6Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but 
session does not exist

Case 4:
Attempt 1---Enabled(ISCSI Mode)---IP6--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---Autoconfigure Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but 
session does not exist



1.   Case1 & Case3 looks fine as 1st valid attempt connected

2.   But Case2 & Case4 looks bit different, 1St attempt was valid but 
connection success with 2nd attempt

3.   As we found that IScsiIp4 Driver Binding Start is getting call first 
and processing the IP4 attempt first even though it is 2nd attempt

Could you please comment on this whether this is a bug or Not?

Thanks,
Karunakar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Different ISCSI behavior when 2 attempts are added

[Wu, Jiaxin]

Hi Karunakar,

I think it's not the bug according the current  iSCSI implementation that the 
first login session will be selected while others are aborted directly. Here, 
IP4 is the first login session.

I didn't find any state that the first attempt should be connected. Ting and 
Siyuan, If anything wrong, please correct me.

Thanks,
Jiaxin

From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Monday, October 9, 2017 10:52 PM
To: 'edk2-devel@lists.01.org' 
Cc: Wu, Jiaxin ; Ye, Ting ; Fu, Siyuan 

Subject: Re: Different ISCSI behavior when 2 attempts are added

Hello All,

Found the below behavior when I try for ISCSI connection with 2 Valid attempts.

Case 1:
Attempt 1---Enabled(ISCSI Mode)---IP4Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP6Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but 
session does not exist

Case 2:
Attempt 1---Enabled(ISCSI Mode)---IP6Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP4Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but 
session does not exist

Case 3:
Attempt 1---Enabled(ISCSI Mode)---Autoconfigure --->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP6Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but 
session does not exist

Case 4:
Attempt 1---Enabled(ISCSI Mode)---IP6--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---Autoconfigure Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but 
session does not exist



1.   Case1 & Case3 looks fine as 1st valid attempt connected

2.   But Case2 & Case4 looks bit different, 1St attempt was valid but 
connection success with 2nd attempt

3.   As we found that IScsiIp4 Driver Binding Start is getting call first 
and processing the IP4 attempt first even though it is 2nd attempt

Could you please comment on this whether this is a bug or Not?

Thanks,
Karunakar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] SecurityPkg/SecureBootConfigImpl.c: Fix coding style issue.

[Zhang, Chao B]

Reviewed-by: Chao Zhang 

-Original Message-
From: Chen, Chen A 
Sent: Tuesday, October 10, 2017 10:09 AM
To: edk2-devel@lists.01.org
Cc: Chen, Chen A ; Bi, Dandan ; 
Zhang, Chao B 
Subject: [PATCH] SecurityPkg/SecureBootConfigImpl.c: Fix coding style issue.

Fix coding style issue.

Cc: Bi Dandan 
Cc: Zhang Chao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: chenc2 
---
 .../SecureBootConfigDxe/SecureBootConfigImpl.c | 30 +++---
 .../SecureBootConfigDxe/SecureBootConfigImpl.h | 14 +-
 2 files changed, 22 insertions(+), 22 deletions(-)

diff --git 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
index 457e020ece..3e5012e21b 100644
--- 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
+++ b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCo
+++ nfigImpl.c
@@ -3098,11 +3098,11 @@ DeleteSignatureEx (
 goto ON_EXIT;
   }
 
-  if (PrivateData->VariableName == VARIABLE_DB) {
+  if (PrivateData->VariableName == Variable_DB) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE);
-  } else if (PrivateData->VariableName == VARIABLE_DBX) {
+  } else if (PrivateData->VariableName == Variable_DBX) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE1);
-  } else if (PrivateData->VariableName == VARIABLE_DBT) {
+  } else if (PrivateData->VariableName == Variable_DBT) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE2);
   } else {
 goto ON_EXIT;
@@ -3149,7 +3149,7 @@ DeleteSignatureEx (
 
   RemainingSize = VariableDataSize;
   ListWalker = (EFI_SIGNATURE_LIST *)(VariableData);
-  if (DelType == DELETE_SIGNATURE_LIST_ALL) {
+  if (DelType == Delete_Signature_List_All) {
 VariableDataSize = 0;
   } else {
 while ((RemainingSize > 0) && (RemainingSize >= 
ListWalker->SignatureListSize) && ListIndex < PrivateData->ListIndex) { @@ 
-3161,7 +3161,7 @@ DeleteSignatureEx (
   ListIndex++;
 }
 
-if (CheckedCount == SIGNATURE_DATA_COUNTS (ListWalker) || DelType == 
DELETE_SIGNATURE_LIST_ONE) {
+if (CheckedCount == SIGNATURE_DATA_COUNTS (ListWalker) || DelType 
+ == Delete_Signature_List_One) {
   RemainingSize -= ListWalker->SignatureListSize;
   ListWalker = (EFI_SIGNATURE_LIST *)((UINT8 *)ListWalker + 
ListWalker->SignatureListSize);
 } else {
@@ -3685,13 +3685,13 @@ LoadSignatureList (
 goto ON_EXIT;
   }
 
-  if (PrivateData->VariableName == VARIABLE_DB) {
+  if (PrivateData->VariableName == Variable_DB) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE);
 DstFormId = FORMID_SECURE_BOOT_DB_OPTION_FORM;
-  } else if (PrivateData->VariableName == VARIABLE_DBX) {
+  } else if (PrivateData->VariableName == Variable_DBX) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE1);
 DstFormId = FORMID_SECURE_BOOT_DBX_OPTION_FORM;
-  } else if (PrivateData->VariableName == VARIABLE_DBT) {
+  } else if (PrivateData->VariableName == Variable_DBT) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE2);
 DstFormId = FORMID_SECURE_BOOT_DBT_OPTION_FORM;
   } else {
@@ -4216,11 +4216,11 @@ LoadSignatureData (
 goto ON_EXIT;
   }
 
-  if (PrivateData->VariableName == VARIABLE_DB) {
+  if (PrivateData->VariableName == Variable_DB) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE);
-  } else if (PrivateData->VariableName == VARIABLE_DBX) {
+  } else if (PrivateData->VariableName == Variable_DBX) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE1);
-  } else if (PrivateData->VariableName == VARIABLE_DBT) {
+  } else if (PrivateData->VariableName == Variable_DBT) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE2);
   } else {
 goto ON_EXIT;
@@ -4618,7 +4618,7 @@ SecureBootCallback (
 // From DBX option to the level-1 form, display signature list.
 //
 case KEY_VALUE_FROM_DBX_TO_LIST_FORM:
-  Private->VariableName = VARIABLE_DBX;
+  Private->VariableName = Variable_DBX;
   LoadSignatureList (
 Private,
 LABEL_SIGNATURE_LIST_START,
@@ -4640,7 +4640,7 @@ SecureBootCallback (
   );
 
   if (Key.UnicodeChar == L'Y' || Key.UnicodeChar == L'y') {
-DeleteSignatureEx (Private, DELETE_SIGNATURE_LIST_ALL, 
IfrNvData->CheckedDataCount);
+DeleteSignatureEx (Private, Delete_Signature_List_All, 
+ IfrNvData->CheckedDataCount);
   }
 
   LoadSignatureList (
@@ -4664,7 +4664,7 @@ SecureBootCallback (
   );
 
   if (Key.UnicodeChar == L'Y' || Key.UnicodeChar == L'y') {
-DeleteSignatureEx (Private, DELETE_SIGNATURE_LIST_ONE, 
IfrNvData->CheckedDataCount);
+DeleteSignatureEx (Private, Delete_Signature_List_One, 
+ IfrNvData->CheckedDataCount);
   }
 
   LoadSignatureList (
@@ -4688,7 +4688,7 @@ SecureBootCallback (
   )

Re: [edk2] [PATCH] SecurityPkg/SecureBootConfigImpl.c: Fix the potential NULL dereference.

[Wu, Hao A]

Some comments below.

Best Regards,
Hao Wu

> -Original Message-
> From: Chen, Chen A
> Sent: Tuesday, October 10, 2017 10:08 AM
> To: edk2-devel@lists.01.org
> Cc: Chen, Chen A; Zhang, Chao B; Wu, Hao A
> Subject: [PATCH] SecurityPkg/SecureBootConfigImpl.c: Fix the potential NULL
> dereference.
> 
> Cc: Zhang Chao 
> Cc: Wu Hao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Chen A Chen 
> ---
>  .../SecureBootConfigDxe/SecureBootConfigImpl.c | 80 +++
> ---
>  1 file changed, 57 insertions(+), 23 deletions(-)
> 
> diff --git
> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigI
> mpl.c
> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigI
> mpl.c
> index 3e03be9738..457e020ece 100644
> ---
> a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigI
> mpl.c
> +++
> b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigI
> mpl.c
> @@ -3579,7 +3579,9 @@ LoadSignatureList (
>)
>  {
>EFI_STATUSStatus;
> -  EFI_STRING_ID ListType;
> +  EFI_STRINGEfiStringTemp1;
> +  EFI_STRINGEfiStringTemp2;
> +  EFI_STRING_ID ListType;;

An extra ';' is used here.

>EFI_SIGNATURE_LIST*ListWalker;
>EFI_IFR_GUID_LABEL*StartLabel;
>EFI_IFR_GUID_LABEL*EndLabel;
> @@ -3599,6 +3601,8 @@ LoadSignatureList (
>CHAR16*HelpBuffer;
> 
>Status= EFI_SUCCESS;
> +  EfiStringTemp1= NULL;
> +  EfiStringTemp2= NULL;
>StartOpCodeHandle = NULL;
>EndOpCodeHandle   = NULL;
>StartGotoHandle   = NULL;
> @@ -3755,17 +3759,19 @@ LoadSignatureList (
>ListType = STRING_TOKEN (STR_LIST_TYPE_UNKNOWN);
>  }
> 
> -UnicodeSPrint (NameBuffer,
> -  100,
> -  HiiGetString (PrivateData->HiiHandle, STRING_TOKEN
> (STR_SIGNATURE_LIST_NAME_FORMAT), NULL),
> -  Index + 1
> -);
> -UnicodeSPrint (HelpBuffer,
> -  100,
> -  HiiGetString (PrivateData->HiiHandle, STRING_TOKEN
> (STR_SIGNATURE_LIST_HELP_FORMAT), NULL),
> -  HiiGetString (PrivateData->HiiHandle, ListType, NULL),
> -  SIGNATURE_DATA_COUNTS (ListWalker)
> -);
> +EfiStringTemp1 = HiiGetString (PrivateData->HiiHandle, STRING_TOKEN
> (STR_SIGNATURE_LIST_NAME_FORMAT), NULL);
> +if (EfiStringTemp1 == NULL) {
> +  goto ON_EXIT;
> +}
> +UnicodeSPrint (NameBuffer, 100, EfiStringTemp1, Index + 1);
> +EfiStringTemp1 = NULL;

Before setting 'EfiStringTemp1' to NULL, I think the returned string from
HiiGetString() should be freed first. There are many similar cases in the
codes.

Also, could you help to replace the usages of '100' like:

*  VariableName = AllocateZeroPool (100);
*  NameBuffer = AllocateZeroPool (100);
*  UnicodeSPrint (NameBuffer, 100, EfiStringTemp1, Index + 1);
...

with a macro? It will be helpful for maintaining the codes.

And how about declaring string buffers like 'VariableName', 'NameBuffer'
as arrays instead of allocating them on the heap?

> +
> +EfiStringTemp1 = HiiGetString (PrivateData->HiiHandle, STRING_TOKEN
> (STR_SIGNATURE_LIST_HELP_FORMAT), NULL);
> +EfiStringTemp2 = HiiGetString (PrivateData->HiiHandle, ListType, NULL);
> +if (EfiStringTemp1 == NULL || EfiStringTemp2 == NULL) {
> +  goto ON_EXIT;
> +}
> +UnicodeSPrint (HelpBuffer, 100, EfiStringTemp1, EfiStringTemp2,
> SIGNATURE_DATA_COUNTS (ListWalker));
> 
>  HiiCreateGotoOpCode (
>StartOpCodeHandle,
> @@ -3953,6 +3959,8 @@ FormatHelpInfo (
>  {
>EFI_STATUS  Status;
>EFI_TIME*Time;
> +  EFI_STRING  EfiStringTemp1;
> +  EFI_STRING  EfiStringTemp2;
>EFI_STRING_ID   ListTypeId;
>UINTN   DataSize;
>UINTN   HelpInfoIndex;
> @@ -3964,6 +3972,8 @@ FormatHelpInfo (
>BOOLEAN IsCert;
> 
>Status  = EFI_SUCCESS;
> +  EfiStringTemp1  = NULL;
> +  EfiStringTemp2  = NULL;
>Time= NULL;
>HelpInfoIndex   = 0;
>GuidString  = NULL;
> @@ -4016,6 +4026,10 @@ FormatHelpInfo (
>  goto ON_EXIT;
>}
> 
> +  EfiStringTemp1 = HiiGetString (PrivateData->HiiHandle, STRING_TOKEN
> (STR_SIGNATURE_DATA_HELP_FORMAT_GUID), NULL);
> +  if (EfiStringTemp1 == NULL) {
> +goto ON_EXIT;
> +  }
>//
>// Format GUID part.
>//
> @@ -4023,20 +4037,29 @@ FormatHelpInfo (
>HelpInfoIndex += UnicodeSPrint (
>   &HelpInfoString[HelpInfoIndex],
>   TotalSize - sizeof(CHAR16) * HelpInfoIndex,
> - HiiGetString (PrivateData->HiiHandle, STRING_TOKEN
> (STR_SIGNATURE_DATA_HELP_FORMAT_GUID), NULL),
> + EfiStringTemp1,
>   GuidString
> );
> +  EfiStringTemp1 = NULL;
> 
> +  EfiStringTemp2 = HiiGetString (PrivateData->HiiHandle, ListTypeId, NULL);
> +  if (EfiStringTemp2 == NULL) {
> +goto ON_EXIT;
> +  }
>//
>// Format conte

Re: [edk2] Request to display Initiator IP in ISCSI Attempt Page

[Wu, Jiaxin]

Hi Karunakar,

We agree to add this feature for the Initiator info of IPv4 when DHCP enabled. 
Can you report it on Bugzilla first?

To achieve that,  we can grayout the Initiator IP/Subnet/Gateway if Initiator 
DHCP enabled to indicate it's un-configurable. For IPv6, since iSCSI only 
request the target info from DHCP server, so, it's unnecessary to display the 
info as IPv4.

Thanks,
Jiaxin


From: Karunakar P [mailto:karunak...@amiindia.co.in]
Sent: Friday, October 6, 2017 5:28 PM
To: 'edk2-devel@lists.01.org' 
Cc: Fu, Siyuan ; Wu, Jiaxin ; Ye, 
Ting 
Subject: RE: Request to display Initiator IP in ISCSI Attempt Page

Hello All,

We have a requirement to display Initiator IP in ISCSI Configuration Page when 
Initiator info is enabled for DHCP, find detailed description below.


1.   Add an Attempt with Initiator info Enabled for DHCP

2.   Save changes

3.   On next reboot, Previously added ISCSI attempt will be tried and ISCSI 
DHCP server will assign an IP to the client (Initiator IP).

4.   It is better to display Initiator IP in same attempt Page like below



Ex:- Initiator IP : 192.168.0.5 // DHCP Process was success

 Initiator IP : 0.0.0.0 // DHCP process failed

Could you please provide your comments to support this feature?

Thanks,
Karunakar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] SecurityPkg/SecureBootConfigImpl.c: Fix coding style issue.

[Bi, Dandan]

Reviewed-by: Bi Dandan 

Thanks,
Dandan

-Original Message-
From: Chen, Chen A 
Sent: Tuesday, October 10, 2017 10:09 AM
To: edk2-devel@lists.01.org
Cc: Chen, Chen A ; Bi, Dandan ; 
Zhang, Chao B 
Subject: [PATCH] SecurityPkg/SecureBootConfigImpl.c: Fix coding style issue.

Fix coding style issue.

Cc: Bi Dandan 
Cc: Zhang Chao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: chenc2 
---
 .../SecureBootConfigDxe/SecureBootConfigImpl.c | 30 +++---
 .../SecureBootConfigDxe/SecureBootConfigImpl.h | 14 +-
 2 files changed, 22 insertions(+), 22 deletions(-)

diff --git 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
index 457e020ece..3e5012e21b 100644
--- 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
+++ b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCo
+++ nfigImpl.c
@@ -3098,11 +3098,11 @@ DeleteSignatureEx (
 goto ON_EXIT;
   }
 
-  if (PrivateData->VariableName == VARIABLE_DB) {
+  if (PrivateData->VariableName == Variable_DB) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE);
-  } else if (PrivateData->VariableName == VARIABLE_DBX) {
+  } else if (PrivateData->VariableName == Variable_DBX) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE1);
-  } else if (PrivateData->VariableName == VARIABLE_DBT) {
+  } else if (PrivateData->VariableName == Variable_DBT) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE2);
   } else {
 goto ON_EXIT;
@@ -3149,7 +3149,7 @@ DeleteSignatureEx (
 
   RemainingSize = VariableDataSize;
   ListWalker = (EFI_SIGNATURE_LIST *)(VariableData);
-  if (DelType == DELETE_SIGNATURE_LIST_ALL) {
+  if (DelType == Delete_Signature_List_All) {
 VariableDataSize = 0;
   } else {
 while ((RemainingSize > 0) && (RemainingSize >= 
ListWalker->SignatureListSize) && ListIndex < PrivateData->ListIndex) { @@ 
-3161,7 +3161,7 @@ DeleteSignatureEx (
   ListIndex++;
 }
 
-if (CheckedCount == SIGNATURE_DATA_COUNTS (ListWalker) || DelType == 
DELETE_SIGNATURE_LIST_ONE) {
+if (CheckedCount == SIGNATURE_DATA_COUNTS (ListWalker) || DelType 
+ == Delete_Signature_List_One) {
   RemainingSize -= ListWalker->SignatureListSize;
   ListWalker = (EFI_SIGNATURE_LIST *)((UINT8 *)ListWalker + 
ListWalker->SignatureListSize);
 } else {
@@ -3685,13 +3685,13 @@ LoadSignatureList (
 goto ON_EXIT;
   }
 
-  if (PrivateData->VariableName == VARIABLE_DB) {
+  if (PrivateData->VariableName == Variable_DB) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE);
 DstFormId = FORMID_SECURE_BOOT_DB_OPTION_FORM;
-  } else if (PrivateData->VariableName == VARIABLE_DBX) {
+  } else if (PrivateData->VariableName == Variable_DBX) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE1);
 DstFormId = FORMID_SECURE_BOOT_DBX_OPTION_FORM;
-  } else if (PrivateData->VariableName == VARIABLE_DBT) {
+  } else if (PrivateData->VariableName == Variable_DBT) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE2);
 DstFormId = FORMID_SECURE_BOOT_DBT_OPTION_FORM;
   } else {
@@ -4216,11 +4216,11 @@ LoadSignatureData (
 goto ON_EXIT;
   }
 
-  if (PrivateData->VariableName == VARIABLE_DB) {
+  if (PrivateData->VariableName == Variable_DB) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE);
-  } else if (PrivateData->VariableName == VARIABLE_DBX) {
+  } else if (PrivateData->VariableName == Variable_DBX) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE1);
-  } else if (PrivateData->VariableName == VARIABLE_DBT) {
+  } else if (PrivateData->VariableName == Variable_DBT) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE2);
   } else {
 goto ON_EXIT;
@@ -4618,7 +4618,7 @@ SecureBootCallback (
 // From DBX option to the level-1 form, display signature list.
 //
 case KEY_VALUE_FROM_DBX_TO_LIST_FORM:
-  Private->VariableName = VARIABLE_DBX;
+  Private->VariableName = Variable_DBX;
   LoadSignatureList (
 Private,
 LABEL_SIGNATURE_LIST_START,
@@ -4640,7 +4640,7 @@ SecureBootCallback (
   );
 
   if (Key.UnicodeChar == L'Y' || Key.UnicodeChar == L'y') {
-DeleteSignatureEx (Private, DELETE_SIGNATURE_LIST_ALL, 
IfrNvData->CheckedDataCount);
+DeleteSignatureEx (Private, Delete_Signature_List_All, 
+ IfrNvData->CheckedDataCount);
   }
 
   LoadSignatureList (
@@ -4664,7 +4664,7 @@ SecureBootCallback (
   );
 
   if (Key.UnicodeChar == L'Y' || Key.UnicodeChar == L'y') {
-DeleteSignatureEx (Private, DELETE_SIGNATURE_LIST_ONE, 
IfrNvData->CheckedDataCount);
+DeleteSignatureEx (Private, Delete_Signature_List_One, 
+ IfrNvData->CheckedDataCount);
   }
 
   LoadSignatureList (
@@ -4688,7 +4688,7 @@ SecureBootCall

Re: [edk2] [PATCH 0/2] Dynamic Tables

[Yao, Jiewen]

HI Evan
Thanks for the contribution.

This is a very big feature. It may talk us more time to review and evaluate.
At same time, one of our key MdeModule package maintainer is in paternity 
leave. It may be longer than usual.

I notice you only defined ARM namespace in this patch, and implemented ARM 
library instance.
Also most consumers of ConfigurationManager are from ARM platform package. So 
if it urgent from ARM platform, you may consider to check into ArmPkg at first.



I only have a quick look at the patch. Would you please share more on the 
design philosophy?

1) It seems the final goal is still to generate ACPI table/SMBIOS 
table/DevTree. You just introduce a way to manage how these tables are 
generated, right?

2) Below definition is defined by the 
MdeModulePkg/Include/DynamicTables/ConfigurationManagerObject.h.
Is there any industry standard to define below index? Or it is just defined by 
EDKII, and anyone can add extension here?

+Object ID's in the ARM Namespace:
+   0 - Reserved
+   1 - Boot Architecture Info
+   2 - CPU Info
+   3 - Power Management Profile Info
+   4 - GICC Info
+   5 - GICD Info
+   6 - GIC MSI Frame Info
+   7 - GIC Redistributor Info
+   8 - GIC ITS Info
+   9 - Serial Console Port Info
+  10 - Serial Debug Port Info
+  12 - Generic Timer Info
+  13 - Platform GT Block Info
+  14 - Platform Generic Watchdog
+  15 - PCI Configuration Space Info
+  16 - Hypervisor Vendor Id

3) I am not sure if you have known about datahub protocol. 
(IntelFrameworkPkg\Include\Protocol\DataHub.h)
Long time ago, we have platform module filling the SMBIOS needed information to 
datahub (such as CPU INFO, Memory Info).
The SMBIOS table is derived from datahub protocol. The setup driver can also 
from datahub.
But later, we think it is an overdesign and datahub is no longer used in the 
new IA platform.
People feel it is easier to fill industry defined SMBIOS record directly, than 
to fill the EDK defined datahub record.
They do not need to learn 2 different styles of data record format.

To me, this seems similar to datahub. Please help us understand the key 
difference.

4) In addition, EDKII/PI defined PCD (platform configuration database). It is 
an architecture way to manage the configuration data.
We are also implementing structure PCD to let platform fill data easily. 
(https://github.com/tianocore/edk2-staging/tree/StructurePcd)

I found some configuration can be as simple as a PCD, such as
+  // Boot architecture information
+  { EFI_ACPI_6_1_ARM_PSCI_COMPLIANT },  // BootArchFlags
+
+  // Power management profile information
+  { EFI_ACPI_6_1_PM_PROFILE_ENTERPRISE_SERVER },// PowerManagement Profile

With the new structure PCD design, below definition can also be a structure PCD.
+  // SPCR Serial Port
+  {
+FixedPcdGet64 (PcdSerialRegisterBase),  // UINT64  BaseAddress
+FixedPcdGet32 (PL011UartInterrupt), // UINT32  Interrupt
+FixedPcdGet64 (PcdUartDefaultBaudRate), // UINT64  BaudRate
+FixedPcdGet32 (PL011UartClkInHz)// UINT32  Clock
+  },

+  // Debug Serial Port
+  {
+FixedPcdGet64 (PcdSerialDbgRegisterBase), // UINT64  BaseAddress
+38,   // UINT32  Interrupt
+FixedPcdGet64 (PcdSerialDbgUartBaudRate), // UINT64  BaudRate
+FixedPcdGet32 (PcdSerialDbgUartClkInHz)   // UINT32  Clock
+  },

What if we just use PCD to define these CPU info, GICC info? Do we really 
another ConfigurationManager?


All in all, if we can compare the difference of below design with pros/cons, 
that will be great.
That will help us understand more about the new design.
A) DataHub (IntelFrameworkPkg, do not recommend to use.)
B) PCD (MdePkg, in PI specification) and structure PCD (EDKII staging)
C) ConfigurationManager (this patch)


Thank you
Yao Jiewen

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> evan.ll...@arm.com
> Sent: Tuesday, October 3, 2017 3:48 AM
> To: edk2-devel@lists.01.org
> Cc: "matteo.carl...@arm.com"@arm.com; "n...@arm.com"@arm.com;
> "ard.biesheu...@linaro.org"@arm.com;
> "stephanie.hughes-f...@arm.com"@arm.com;
> "thomas.abra...@arm.com"@arm.com;
> "arvind.chau...@arm.com"@arm.com; "leif.lindh...@linaro.org"@arm.com;
> "daniil.egra...@arm.com"@arm.com
> Subject: [edk2] [PATCH 0/2] Dynamic Tables
> 
> From: EvanLloyd 
> 
> Historically, ACPI code, SMBIOS tables, and UEFI firmware were
> often developed in isolation from each other.  This introduced
> several problems, not least of which was duplication of platform
> information between the various source trees.
> In addition, variants of platforms introduced a plethora of
> alternative builds of ACPI, SMBIOS and EDK2, with the concomitant
> risk of getting the mixture wrong in a build.
> 
> In the effort to resolve these problems, the solution prototyped
> here was devised.  The basic idea is to obtain the "variant"
> information from a management node.  That means the firmware i

[edk2] [PATCH] SecurityPkg/SecureBootConfigImpl.c: Fix coding style issue.

[chenc2]

Fix coding style issue.

Cc: Bi Dandan 
Cc: Zhang Chao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: chenc2 
---
 .../SecureBootConfigDxe/SecureBootConfigImpl.c | 30 +++---
 .../SecureBootConfigDxe/SecureBootConfigImpl.h | 14 +-
 2 files changed, 22 insertions(+), 22 deletions(-)

diff --git 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
index 457e020ece..3e5012e21b 100644
--- 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
+++ 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
@@ -3098,11 +3098,11 @@ DeleteSignatureEx (
 goto ON_EXIT;
   }
 
-  if (PrivateData->VariableName == VARIABLE_DB) {
+  if (PrivateData->VariableName == Variable_DB) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE);
-  } else if (PrivateData->VariableName == VARIABLE_DBX) {
+  } else if (PrivateData->VariableName == Variable_DBX) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE1);
-  } else if (PrivateData->VariableName == VARIABLE_DBT) {
+  } else if (PrivateData->VariableName == Variable_DBT) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE2);
   } else {
 goto ON_EXIT;
@@ -3149,7 +3149,7 @@ DeleteSignatureEx (
 
   RemainingSize = VariableDataSize;
   ListWalker = (EFI_SIGNATURE_LIST *)(VariableData);
-  if (DelType == DELETE_SIGNATURE_LIST_ALL) {
+  if (DelType == Delete_Signature_List_All) {
 VariableDataSize = 0;
   } else {
 while ((RemainingSize > 0) && (RemainingSize >= 
ListWalker->SignatureListSize) && ListIndex < PrivateData->ListIndex) {
@@ -3161,7 +3161,7 @@ DeleteSignatureEx (
   ListIndex++;
 }
 
-if (CheckedCount == SIGNATURE_DATA_COUNTS (ListWalker) || DelType == 
DELETE_SIGNATURE_LIST_ONE) {
+if (CheckedCount == SIGNATURE_DATA_COUNTS (ListWalker) || DelType == 
Delete_Signature_List_One) {
   RemainingSize -= ListWalker->SignatureListSize;
   ListWalker = (EFI_SIGNATURE_LIST *)((UINT8 *)ListWalker + 
ListWalker->SignatureListSize);
 } else {
@@ -3685,13 +3685,13 @@ LoadSignatureList (
 goto ON_EXIT;
   }
 
-  if (PrivateData->VariableName == VARIABLE_DB) {
+  if (PrivateData->VariableName == Variable_DB) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE);
 DstFormId = FORMID_SECURE_BOOT_DB_OPTION_FORM;
-  } else if (PrivateData->VariableName == VARIABLE_DBX) {
+  } else if (PrivateData->VariableName == Variable_DBX) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE1);
 DstFormId = FORMID_SECURE_BOOT_DBX_OPTION_FORM;
-  } else if (PrivateData->VariableName == VARIABLE_DBT) {
+  } else if (PrivateData->VariableName == Variable_DBT) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE2);
 DstFormId = FORMID_SECURE_BOOT_DBT_OPTION_FORM;
   } else {
@@ -4216,11 +4216,11 @@ LoadSignatureData (
 goto ON_EXIT;
   }
 
-  if (PrivateData->VariableName == VARIABLE_DB) {
+  if (PrivateData->VariableName == Variable_DB) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE);
-  } else if (PrivateData->VariableName == VARIABLE_DBX) {
+  } else if (PrivateData->VariableName == Variable_DBX) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE1);
-  } else if (PrivateData->VariableName == VARIABLE_DBT) {
+  } else if (PrivateData->VariableName == Variable_DBT) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE2);
   } else {
 goto ON_EXIT;
@@ -4618,7 +4618,7 @@ SecureBootCallback (
 // From DBX option to the level-1 form, display signature list.
 //
 case KEY_VALUE_FROM_DBX_TO_LIST_FORM:
-  Private->VariableName = VARIABLE_DBX;
+  Private->VariableName = Variable_DBX;
   LoadSignatureList (
 Private,
 LABEL_SIGNATURE_LIST_START,
@@ -4640,7 +4640,7 @@ SecureBootCallback (
   );
 
   if (Key.UnicodeChar == L'Y' || Key.UnicodeChar == L'y') {
-DeleteSignatureEx (Private, DELETE_SIGNATURE_LIST_ALL, 
IfrNvData->CheckedDataCount);
+DeleteSignatureEx (Private, Delete_Signature_List_All, 
IfrNvData->CheckedDataCount);
   }
 
   LoadSignatureList (
@@ -4664,7 +4664,7 @@ SecureBootCallback (
   );
 
   if (Key.UnicodeChar == L'Y' || Key.UnicodeChar == L'y') {
-DeleteSignatureEx (Private, DELETE_SIGNATURE_LIST_ONE, 
IfrNvData->CheckedDataCount);
+DeleteSignatureEx (Private, Delete_Signature_List_One, 
IfrNvData->CheckedDataCount);
   }
 
   LoadSignatureList (
@@ -4688,7 +4688,7 @@ SecureBootCallback (
   );
 
   if (Key.UnicodeChar == L'Y' || Key.UnicodeChar == L'y') {
-DeleteSignatureEx (Private, DELETE_SIGNATURE_DATA, 
IfrNvData->CheckedDataCount);
+DeleteSignatureEx (Private, Delete_Signature_Data, 
IfrNvData->CheckedDataCount);
   }
 
   LoadSignat

[edk2] [PATCH] SecurityPkg/SecureBootConfigImpl.c: Fix the potential NULL dereference.

[chenc2]

Cc: Zhang Chao 
Cc: Wu Hao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chen A Chen 
---
 .../SecureBootConfigDxe/SecureBootConfigImpl.c | 80 +++---
 1 file changed, 57 insertions(+), 23 deletions(-)

diff --git 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
index 3e03be9738..457e020ece 100644
--- 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
+++ 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
@@ -3579,7 +3579,9 @@ LoadSignatureList (
   )
 {
   EFI_STATUSStatus;
-  EFI_STRING_ID ListType;
+  EFI_STRINGEfiStringTemp1;
+  EFI_STRINGEfiStringTemp2;
+  EFI_STRING_ID ListType;;
   EFI_SIGNATURE_LIST*ListWalker;
   EFI_IFR_GUID_LABEL*StartLabel;
   EFI_IFR_GUID_LABEL*EndLabel;
@@ -3599,6 +3601,8 @@ LoadSignatureList (
   CHAR16*HelpBuffer;
 
   Status= EFI_SUCCESS;
+  EfiStringTemp1= NULL;
+  EfiStringTemp2= NULL;
   StartOpCodeHandle = NULL;
   EndOpCodeHandle   = NULL;
   StartGotoHandle   = NULL;
@@ -3755,17 +3759,19 @@ LoadSignatureList (
   ListType = STRING_TOKEN (STR_LIST_TYPE_UNKNOWN);
 }
 
-UnicodeSPrint (NameBuffer,
-  100,
-  HiiGetString (PrivateData->HiiHandle, STRING_TOKEN 
(STR_SIGNATURE_LIST_NAME_FORMAT), NULL),
-  Index + 1
-);
-UnicodeSPrint (HelpBuffer,
-  100,
-  HiiGetString (PrivateData->HiiHandle, STRING_TOKEN 
(STR_SIGNATURE_LIST_HELP_FORMAT), NULL),
-  HiiGetString (PrivateData->HiiHandle, ListType, NULL),
-  SIGNATURE_DATA_COUNTS (ListWalker)
-);
+EfiStringTemp1 = HiiGetString (PrivateData->HiiHandle, STRING_TOKEN 
(STR_SIGNATURE_LIST_NAME_FORMAT), NULL);
+if (EfiStringTemp1 == NULL) {
+  goto ON_EXIT;
+}
+UnicodeSPrint (NameBuffer, 100, EfiStringTemp1, Index + 1);
+EfiStringTemp1 = NULL;
+
+EfiStringTemp1 = HiiGetString (PrivateData->HiiHandle, STRING_TOKEN 
(STR_SIGNATURE_LIST_HELP_FORMAT), NULL);
+EfiStringTemp2 = HiiGetString (PrivateData->HiiHandle, ListType, NULL);
+if (EfiStringTemp1 == NULL || EfiStringTemp2 == NULL) {
+  goto ON_EXIT;
+}
+UnicodeSPrint (HelpBuffer, 100, EfiStringTemp1, EfiStringTemp2, 
SIGNATURE_DATA_COUNTS (ListWalker));
 
 HiiCreateGotoOpCode (
   StartOpCodeHandle,
@@ -3953,6 +3959,8 @@ FormatHelpInfo (
 {
   EFI_STATUS  Status;
   EFI_TIME*Time;
+  EFI_STRING  EfiStringTemp1;
+  EFI_STRING  EfiStringTemp2;
   EFI_STRING_ID   ListTypeId;
   UINTN   DataSize;
   UINTN   HelpInfoIndex;
@@ -3964,6 +3972,8 @@ FormatHelpInfo (
   BOOLEAN IsCert;
 
   Status  = EFI_SUCCESS;
+  EfiStringTemp1  = NULL;
+  EfiStringTemp2  = NULL;
   Time= NULL;
   HelpInfoIndex   = 0;
   GuidString  = NULL;
@@ -4016,6 +4026,10 @@ FormatHelpInfo (
 goto ON_EXIT;
   }
 
+  EfiStringTemp1 = HiiGetString (PrivateData->HiiHandle, STRING_TOKEN 
(STR_SIGNATURE_DATA_HELP_FORMAT_GUID), NULL);
+  if (EfiStringTemp1 == NULL) {
+goto ON_EXIT;
+  }
   //
   // Format GUID part.
   //
@@ -4023,20 +4037,29 @@ FormatHelpInfo (
   HelpInfoIndex += UnicodeSPrint (
  &HelpInfoString[HelpInfoIndex],
  TotalSize - sizeof(CHAR16) * HelpInfoIndex,
- HiiGetString (PrivateData->HiiHandle, STRING_TOKEN 
(STR_SIGNATURE_DATA_HELP_FORMAT_GUID), NULL),
+ EfiStringTemp1,
  GuidString
);
+  EfiStringTemp1 = NULL;
 
+  EfiStringTemp2 = HiiGetString (PrivateData->HiiHandle, ListTypeId, NULL);
+  if (EfiStringTemp2 == NULL) {
+goto ON_EXIT;
+  }
   //
   // Format content part, it depends on the type of signature list, hash value 
or CN.
   //
   if (IsCert) {
 GetCommonNameFromX509 (ListEntry, DataEntry, &DataString);
+EfiStringTemp1 = HiiGetString (PrivateData->HiiHandle, STRING_TOKEN 
(STR_SIGNATURE_DATA_HELP_FORMAT_CN), NULL);
+if (EfiStringTemp1 == NULL) {
+  goto ON_EXIT;
+}
 HelpInfoIndex += UnicodeSPrint(
&HelpInfoString[HelpInfoIndex],
TotalSize - sizeof(CHAR16) * HelpInfoIndex,
-   HiiGetString (PrivateData->HiiHandle, STRING_TOKEN 
(STR_SIGNATURE_DATA_HELP_FORMAT_CN), NULL),
-   HiiGetString (PrivateData->HiiHandle, ListTypeId, NULL),
+   EfiStringTemp1,
+   EfiStringTemp2,
DataSize,
DataString
  );
@@ -4045,15 +4068,20 @@ FormatHelpInfo (
 //  Format hash value for each signature data entry.
 //
 ParseHashValue (ListEntry, DataEntry, &DataString);
+EfiStringTemp1 = HiiGetString (PrivateData->HiiHandle, STRING_TOKEN 
(STR_SIGNATU

Re: [edk2] [PATCH v4 6/6] OvmfPkg/QemuVideoDxe: Bypass NULL pointer detection during VBE SHIM installing

[Wang, Jian J]

I have summary in each patch email. I removed the CC of some patches because 
there's no update from v3 to v4. I thought this could remind you of this 
situation.
What's the recommended way? Keep the CC as-was and just add summaries in 
cover letter?

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, October 09, 2017 11:56 PM
> To: Wang, Jian J ; edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Wolman, Ayellet
> ; Yao, Jiewen ; Dong, Eric
> ; Zeng, Star 
> Subject: Re: [edk2] [PATCH v4 6/6] OvmfPkg/QemuVideoDxe: Bypass NULL
> pointer detection during VBE SHIM installing
> 
> On 10/09/17 17:54, Laszlo Ersek wrote:
> > On 10/09/17 16:17, Jian J Wang wrote:
> >> QemuVideoDxe driver will link VBE SHIM into page 0. If NULL pointer
> >> detection is enabled, this driver will fail to load. NULL pointer detection
> >> bypassing code is added to prevent such problem during boot.
> >>
> >> Please note that Windows 7 will try to access VBE SHIM during boot if it's
> >> installed, and then cause boot failure. This can be fixed by setting BIT7
> >> of PcdNullPointerDetectionPropertyMask to disable NULL pointer detection
> >> after EndOfDxe. As far as we know, there's no other OSs has such issue.
> >>
> >> Cc: Star Zeng 
> >> Cc: Eric Dong 
> >> Cc: Jiewen Yao 
> >> Cc: Michael Kinney 
> >> Cc: Ayellet Wolman 
> >> Suggested-by: Ayellet Wolman 
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Jian J Wang 
> >> ---
> >>  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf |  1 +
> >>  OvmfPkg/QemuVideoDxe/VbeShim.c| 14 ++
> >>  2 files changed, 15 insertions(+)
> >>
> >> diff --git a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> >> index 577e07b0a8..ff68c99e96 100644
> >> --- a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> >> +++ b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> >> @@ -77,3 +77,4 @@
> >>  [Pcd]
> >>gOptionRomPkgTokenSpaceGuid.PcdDriverSupportedEfiVersion
> >>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
> >> +
> gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask
> >> diff --git a/OvmfPkg/QemuVideoDxe/VbeShim.c
> b/OvmfPkg/QemuVideoDxe/VbeShim.c
> >> index e45a08e887..8ba5522cde 100644
> >> --- a/OvmfPkg/QemuVideoDxe/VbeShim.c
> >> +++ b/OvmfPkg/QemuVideoDxe/VbeShim.c
> >> @@ -75,6 +75,20 @@ InstallVbeShim (
> >>UINTNPrinted;
> >>VBE_MODE_INFO*VbeModeInfo;
> >>
> >> +  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & (BIT0|BIT7)) == 
> >> BIT0)
> {
> >> +DEBUG ((
> >> +  DEBUG_WARN,
> >> +  "%a: page 0 protected, not installing VBE shim\n",
> >> +  __FUNCTION__
> >> +  ));
> >> +DEBUG ((
> >> +  DEBUG_WARN,
> >> +  "%a: page 0 protection prevents Windows 7 from booting anyway\n",
> >> +  __FUNCTION__
> >> +  ));
> >> +return;
> >> +  }
> >> +
> >>Segment0 = 0x0;
> >>SegmentC = 0xC;
> >>SegmentF = 0xF;
> >>
> >
> > If this patch is entirely identical to the previous version (v3), then
> > you should have please picked up the review tags from Jordan and myself,
> > the ones that you got for v3:
> >
> > http://mid.mail-
> archive.com/150696711831.2454.16712170525103415248@jljusten-skl
> >
> > http://mid.mail-archive.com/d1a20be5-8dbf-8ce6-1738-
> d03b33004...@redhat.com
> >
> > This way we can quickly filter out already reviewed patches, and avoid
> > re-reviewing when there are no changes.
> >
> >
> > Your cover letter v4 0/6 also does not summarize the changes relative to
> > v3; in the future please don't forget about that.
> 
> ... personal CC's for OvmfPkg maintainers and reviewers are also missing
> from this patch. Please check "Maintainers.txt" every time.
> 
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Enable SueCreek

[Wei, David]

Reviewed-by: zwei4  

Thanks,
David  Wei

Intel SSG/STO/UEFI BIOS 

> -Original Message-
> From: Guo, Mang
> Sent: Tuesday, October 10, 2017 9:18 AM
> To: edk2-devel@lists.01.org
> Cc: Wei, David ; Rytkonen, Teemu S
> ; Yoon, Yeon Sil ;
> Jones, Mark L ; Loeppert, Anthony
> 
> Subject: [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Enable
> SueCreek
> 
> 1. Change SPI mode and speed for SueCreek
> 2. Update SueCreek HOST_IRQ and HOST_RST GPIO configuration
> 3. Add a PCD to make sure that SueCreek only reported to OS when it is
> actually present on the board.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Yeon Sil Yoon 
> Signed-off-by: Guo Mang 
> ---
>  .../Board/BensonGlacier/BoardInitPostMem/BoardGpios.h|  4 ++--
>  .../Board/BensonGlacier/BoardInitPostMem/BoardInit.c |  5 +
>  .../BensonGlacier/BoardInitPostMem/BoardInitPostMem.inf  |  1 +
>  .../Board/LeafHill/BoardInitPostMem/BoardInit.c  |  5 +
>  .../Board/LeafHill/BoardInitPostMem/BoardInitPostMem.inf |  1 +
>  .../Board/MinnowBoard3/BoardInitPostMem/BoardInit.c  |  5 +
>  .../Board/MinnowBoard3/BoardInitPostMem/BoardInitPostMem.inf |  1 +
>  .../Common/Acpi/AcpiPlatformDxe/AcpiPlatform.c   |  2 ++
>  .../Common/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf  |  1 +
>  .../Common/Acpi/AcpiTablesPCAT/GloblNvs.asl  |  8 +++-
>  .../Acpi/AcpiTablesPCAT/PlatformSsdt/SueCreek/SueCreek.asl   | 12
> +++-
>  Platform/BroxtonPlatformPkg/PlatformPkg.dec  |  2 ++
>  .../NorthCluster/Include/Protocol/GlobalNvsArea.h|  3 ++-
>  13 files changed, 41 insertions(+), 9 deletions(-)
> 
> diff --git
> a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/B
> oardGpios.h
> b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/B
> oardGpios.h
> index e0bdde8..d72cd80 100644
> ---
> a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/B
> oardGpios.h
> +++
> b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/B
> oardGpios.h
> @@ -80,13 +80,13 @@ BXT_GPIO_PAD_INIT  mBenson_GpioInitData_N[] =
>BXT_GPIO_PAD_CONF(L"GPIO_14",  M1   ,NA, NA,  
> NA,
> NA   , Wake_Disabled, P_20K_L,NA   ,NA ,NA   , NA,
> GPIO_PADBAR+0x0070,  NORTH),//Feature: LB
>BXT_GPIO_PAD_CONF(L"GPIO_15",  M1   ,NA, NA,  
> NA,
> NA   , Wake_Disabled, P_20K_L,NA   ,NA ,NA   , NA,
> GPIO_PADBAR+0x0078,  NORTH),//Feature: LB
>BXT_GPIO_PAD_CONF(L"GPIO_16",  M0   ,GPI   ,  NA   ,  
> NA,
> Edge , Wake_Disabled, P_20K_H, Inverted,IOAPIC,  HizRx0I ,DisPuPd,
> GPIO_PADBAR+0x0080,  NORTH),//Feature:SIM Card DetectNet in Sch:
> SIM_CON_CD1, falling edge trigger
> -  BXT_GPIO_PAD_CONF(L"GPIO_17",  M1   ,NA, NA,  
> NA,
> NA   , Wake_Disabled, P_20K_H,NA   ,NA, NA   , NA,
> GPIO_PADBAR+0x0088,  NORTH),//Feature: LB
> +  BXT_GPIO_PAD_CONF(L"GPIO_17",  M0   ,GPI   , GPIO_D,  
> NA,
> Edge , Wake_Disabled, P_NONE ,NA   ,IOAPIC, NA   ,DisPuPd,
> GPIO_PADBAR+0x0088, NORTH), // SOC_LSE_HOST_IRQ_N
>BXT_GPIO_PAD_CONF(L"GPIO_18",  M1   ,NA, NA,  
> NA,
> NA   , Wake_Disabled, P_20K_H,NA   ,NA, NA   , NA,
> GPIO_PADBAR+0x0090,  NORTH),//Feature: LB
>BXT_GPIO_PAD_CONF(L"GPIO_19",  M1   ,NA, NA,  
> NA,
> NA   , Wake_Disabled, P_20K_H,NA   ,NA, NA   , NA,
> GPIO_PADBAR+0x0098,  NORTH),//Feature: LB
>BXT_GPIO_PAD_CONF(L"GPIO_20",  M1   ,NA, NA,  
> NA,
> NA   , Wake_Disabled, P_20K_L,NA   ,NA, NA   , NA,
> GPIO_PADBAR+0x00A0,  NORTH),//Feature: LB
>BXT_GPIO_PAD_CONF(L"GPIO_21",  M1   ,NA, NA,  
> NA,
> NA   , Wake_Disabled, P_20K_L,NA   ,NA, NA   , NA,
> GPIO_PADBAR+0x00A8,  NORTH),//Feature: LB
>BXT_GPIO_PAD_CONF(L"GPIO_22",  M0   ,GPIO  ,GPIO_D ,  
> NA,
> NA   , Wake_Disabled, P_20K_L,NA   ,NA, NA   , NA,
> GPIO_PADBAR+0x00B0,  NORTH),//Feature: LB
> -  BXT_GPIO_PAD_CONF(L"GPIO_23",  M0   ,GPIO  ,GPIO_D ,  
> NA,
> NA  ,  Wake_Disabled, P_20K_L,NA   ,NA, NA   , NA,
> GPIO_PADBAR+0x00B8,  NORTH),//Feature: LB USB Power in LFH
> +  BXT_GPIO_PAD_CONF(L"GPIO_23",  M0   ,GPO   ,GPIO_D,   
> LO,
> NA   , Wake_Disabled, P_20K_H,NA   ,NA, NA   ,   EnPu,
> GPIO_PADBAR+0x00B8, NORTH), // SOC_SUE_RST_N
>BXT_GPIO_PAD_CONF(L"GPIO_24",  M0   ,GPO   ,GPIO_D ,  
> NA,
> NA   , Wake_Disabled, P_20K_H,   NA,NA, NA   , NA,
> GPIO_PADBAR+0x00C0,  NORTH),//SATA

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Enable SueCreek

[Guo, Mang]

1. Change SPI mode and speed for SueCreek
2. Update SueCreek HOST_IRQ and HOST_RST GPIO configuration
3. Add a PCD to make sure that SueCreek only reported to OS when it is actually 
present on the board.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yeon Sil Yoon 
Signed-off-by: Guo Mang 
---
 .../Board/BensonGlacier/BoardInitPostMem/BoardGpios.h|  4 ++--
 .../Board/BensonGlacier/BoardInitPostMem/BoardInit.c |  5 +
 .../BensonGlacier/BoardInitPostMem/BoardInitPostMem.inf  |  1 +
 .../Board/LeafHill/BoardInitPostMem/BoardInit.c  |  5 +
 .../Board/LeafHill/BoardInitPostMem/BoardInitPostMem.inf |  1 +
 .../Board/MinnowBoard3/BoardInitPostMem/BoardInit.c  |  5 +
 .../Board/MinnowBoard3/BoardInitPostMem/BoardInitPostMem.inf |  1 +
 .../Common/Acpi/AcpiPlatformDxe/AcpiPlatform.c   |  2 ++
 .../Common/Acpi/AcpiPlatformDxe/AcpiPlatformDxe.inf  |  1 +
 .../Common/Acpi/AcpiTablesPCAT/GloblNvs.asl  |  8 +++-
 .../Acpi/AcpiTablesPCAT/PlatformSsdt/SueCreek/SueCreek.asl   | 12 +++-
 Platform/BroxtonPlatformPkg/PlatformPkg.dec  |  2 ++
 .../NorthCluster/Include/Protocol/GlobalNvsArea.h|  3 ++-
 13 files changed, 41 insertions(+), 9 deletions(-)

diff --git 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardGpios.h 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardGpios.h
index e0bdde8..d72cd80 100644
--- 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardGpios.h
+++ 
b/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/BoardGpios.h
@@ -80,13 +80,13 @@ BXT_GPIO_PAD_INIT  mBenson_GpioInitData_N[] =
   BXT_GPIO_PAD_CONF(L"GPIO_14",  M1   ,NA, NA,  NA 
   ,   NA   , Wake_Disabled, P_20K_L,NA   ,NA ,NA   , NA, 
GPIO_PADBAR+0x0070,  NORTH),//Feature: LB
   BXT_GPIO_PAD_CONF(L"GPIO_15",  M1   ,NA, NA,  NA 
   ,   NA   , Wake_Disabled, P_20K_L,NA   ,NA ,NA   , NA, 
GPIO_PADBAR+0x0078,  NORTH),//Feature: LB
   BXT_GPIO_PAD_CONF(L"GPIO_16",  M0   ,GPI   ,  NA   ,  NA 
   ,   Edge , Wake_Disabled, P_20K_H, Inverted,IOAPIC,  HizRx0I ,DisPuPd, 
GPIO_PADBAR+0x0080,  NORTH),//Feature:SIM Card DetectNet in Sch: 
SIM_CON_CD1, falling edge trigger
-  BXT_GPIO_PAD_CONF(L"GPIO_17",  M1   ,NA, NA,  NA 
   ,   NA   , Wake_Disabled, P_20K_H,NA   ,NA, NA   , NA, 
GPIO_PADBAR+0x0088,  NORTH),//Feature: LB
+  BXT_GPIO_PAD_CONF(L"GPIO_17",  M0   ,GPI   , GPIO_D,  NA 
   ,   Edge , Wake_Disabled, P_NONE ,NA   ,IOAPIC, NA   ,DisPuPd, 
GPIO_PADBAR+0x0088, NORTH), // SOC_LSE_HOST_IRQ_N
   BXT_GPIO_PAD_CONF(L"GPIO_18",  M1   ,NA, NA,  NA 
   ,   NA   , Wake_Disabled, P_20K_H,NA   ,NA, NA   , NA, 
GPIO_PADBAR+0x0090,  NORTH),//Feature: LB
   BXT_GPIO_PAD_CONF(L"GPIO_19",  M1   ,NA, NA,  NA 
   ,   NA   , Wake_Disabled, P_20K_H,NA   ,NA, NA   , NA, 
GPIO_PADBAR+0x0098,  NORTH),//Feature: LB
   BXT_GPIO_PAD_CONF(L"GPIO_20",  M1   ,NA, NA,  NA 
   ,   NA   , Wake_Disabled, P_20K_L,NA   ,NA, NA   , NA, 
GPIO_PADBAR+0x00A0,  NORTH),//Feature: LB
   BXT_GPIO_PAD_CONF(L"GPIO_21",  M1   ,NA, NA,  NA 
   ,   NA   , Wake_Disabled, P_20K_L,NA   ,NA, NA   , NA, 
GPIO_PADBAR+0x00A8,  NORTH),//Feature: LB
   BXT_GPIO_PAD_CONF(L"GPIO_22",  M0   ,GPIO  ,GPIO_D ,  NA 
   ,   NA   , Wake_Disabled, P_20K_L,NA   ,NA, NA   , NA, 
GPIO_PADBAR+0x00B0,  NORTH),//Feature: LB
-  BXT_GPIO_PAD_CONF(L"GPIO_23",  M0   ,GPIO  ,GPIO_D ,  NA 
   ,   NA  ,  Wake_Disabled, P_20K_L,NA   ,NA, NA   , NA, 
GPIO_PADBAR+0x00B8,  NORTH),//Feature: LB USB Power in LFH
+  BXT_GPIO_PAD_CONF(L"GPIO_23",  M0   ,GPO   ,GPIO_D,   LO 
   ,   NA   , Wake_Disabled, P_20K_H,NA   ,NA, NA   ,   EnPu, 
GPIO_PADBAR+0x00B8, NORTH), // SOC_SUE_RST_N
   BXT_GPIO_PAD_CONF(L"GPIO_24",  M0   ,GPO   ,GPIO_D ,  NA 
   ,   NA   , Wake_Disabled, P_20K_H,   NA,NA, NA   , NA, 
GPIO_PADBAR+0x00C0,  NORTH),//SATA_DEVSLP0
   BXT_GPIO_PAD_CONF(L"GPIO_25",  M0   ,GPO   ,GPIO_D ,  NA 
   ,   Level, Wake_Disabled, P_20K_H, Inverted,   SCI, NA   , NA, 
GPIO_PADBAR+0x00C8,  NORTH),//Feature:ODD MD/DA SCI  Net in Sch: 
SATA_ODD_DA_IN
   BXT_GPIO_PAD_CONF(L"GPIO_26",  M0   ,GPIO  ,GPIO_D ,  NA 
   ,   NA   , Wake_Disabled, P_20K_L,   NA,NA, NA   , NA, 
GPIO_PADBAR+0x00D0,  NORTH),//SATA_LEDN
diff --git 
a/Platform/BroxtonPlatformPkg/Board/BensonGlacier/BoardInitPostMem/Boa

Re: [edk2] MTFTP file transfer timeout error

[Fu, Siyuan]

Hi, Vabhav

Yes the IP layer should discard the whole packet if any frame is lost during 
the transmit. Large TFTP blksize will reduce the the number of TFTP data/ack 
packets, but add more overhead and risk of IP fragmentation and reassembly. 

BestRegards
Fu Siyuan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Vabhav 
Sharma
Sent: Tuesday, October 10, 2017 1:13 AM
To: Fu, Siyuan 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] MTFTP file transfer timeout error

Hi Fu Siyuan,
Thank you for explanation and hope you enjoyed vacation.

I am using 32K block size for file transfer.
IP layer divides the 32K block size into 23 number of fragments(with last 
fragment of less size indicating no more fragments)

Using tcpdump and debug code the flow is:
NIC interface receives 23 fragments and pass it to upper layer.
Mtftp4 Client receives the data block 'x' with expected block number 'x+1'
Mtftp4 Client Sends ACK for received data block 'x'
After receiving approximate 900x block, NIC interface receive 22 fragments 
instead of 23(One packet drop),At this point function MnpReceivePacket() didn't 
receive more packets with status as 'EFI_NOT_READY' with
<>TFTP Server keeps on sending data(23 fragments) block 'x+1'(900) expecting 
ACK for data block 'x+1'(900),Whereas
<>Mtftp4 Client retransmit acknowledgement six times for data block 'x'(899) 
before going to timeout expecting next data block 'x+1'(900).

Added debug logs in the below code and Mtft4 client didn't receive data once 
MnpReceivePacket() status is set to 'EFI_NOT_READY'  causing timeout.
Is this expected if one frame is dropped at Ethernet Layer than whole packet 
will be discarded at IP layer?

Regards,
Vabhav

-Original Message-
From: Fu, Siyuan [mailto:siyuan...@intel.com] 
Sent: Monday, October 09, 2017 7:28 AM
To: Vabhav Sharma ; edk2-devel@lists.01.org
Subject: RE: MTFTP file transfer timeout error

Hi, Vabhav

Sorry for the late response, I just came back from the vacation.

The default retry count for tftp shell command is 6, which means the ACK packet 
will be retransmitted 6 times before the code goes to the 
Mtftp4CleanOperation() you marked below. The MTFTP driver always saves the last 
transmitted packet in Instance->LastPacket, and the Mtftp4Retransmit() will try 
to retransmit it if not reach the max retry count.

As you mentioned 1K block size is always success, I guess it's may because the 
IP fragment. A MTFTP(UDP) packet which is larger than 1.5K (the default MTU) 
will be fragmented to several IP frame. During the transmit, the whole UDP 
packet will be discarded by the IP layer if any of the IP fragment is lost in 
the network. As a result, using large MTFTP block size will increase the 
possibility of timeout in bad network connection.

I suggest you add some debug in Mtftp4RrqInput() in below lines to confirm if 
the EFI client can receive the MTFTP packet correctly, also you could use 
Wireshark in your server to check whether it receives the ACK from client.
switch (Opcode) {
case EFI_MTFTP4_OPCODE_DATA:
if ((Len > (UINT32) (MTFTP4_DATA_HEAD_LEN + Instance->BlkSize)) ||
 (Len < (UINT32) MTFTP4_DATA_HEAD_LEN)) {
goto ON_EXIT;
 }

 Status = Mtftp4RrqHandleData (Instance, Packet, Len, Multicast, 
&Completed);
 break;


BestRegards
Fu Siyuan


-Original Message-
From: Vabhav Sharma [mailto:vabhav.sha...@nxp.com]
Sent: Friday, October 6, 2017 1:26 AM
To: Fu, Siyuan ; edk2-devel@lists.01.org
Subject: RE: MTFTP file transfer timeout error

Dear Experts,

I traced that timeout error for different block size during file transfer using 
tftp(rrq opcode)  is returned from function  Mtftp4OnTimerTick() TFTP layer in 
UEFI network stack.
Mtftp4OnTimerTick()
//
// Retransmit the packet if haven't reach the maxmium retry count,
// otherwise exit the transfer.
//
if (++Instance->CurRetry < Instance->MaxRetry) {
  Mtftp4Retransmit (Instance);
  Mtftp4SetTimeout (Instance);
} else {
  Mtftp4CleanOperation (Instance, EFI_TIMEOUT);//Timeout is set
  continue;
}

Once this is set, It gets populated to downloadfile() function in tftp shellpkg 
library.
There seems to be issue(corruption) with tfp client state machine -Not sending 
ACK for received data blocks -Sending duplicate ACK

If server don't receive ACK, It stops sending data packets and timeout occurs 
after maximum retry.
Please suggest if this is new or known issue to be fixed?

Regards,
Vabhav

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Vabhav 
Sharma
Sent: Thursday, September 28, 2017 5:04 PM
To: siyuan...@intel.com
Cc: edk2-devel@lists.01.org; edk2-devel 
Subject: Re: [edk2] MTFTP file transfer timeout error

[This sender failed our fraud detection checks and may not be who they appear 
to be. Learn about spoofing at http://aka.ms/LearnAboutS

Re: [edk2] [PATCH v2 1/2] ArmPkg/Include: Add standard SMC function IDs for MM interface.

[Achin Gupta]

On Mon, Oct 09, 2017 at 04:15:27PM +0100, Supreeth Venkatesh wrote:
> I can do that.

Thanks!

> However, "-4" is missing in the specification. Is there a chance to rectify 
> specification to add "-4", so that I can do both the defines.

To indicate what error? Anyways, lets take this offline. For the time being, the
code should match the spec.

cheers,
Achin

>
> Thanks,
> Supreeth
> -Original Message-
> From: Achin Gupta
> Sent: Monday, October 9, 2017 3:52 AM
> To: Ard Biesheuvel ; Supreeth Venkatesh 
> 
> Cc: Supreeth Venkatesh ; edk2-devel@lists.01.org; 
> Leif Lindholm ; nd 
> Subject: Re: [PATCH v2 1/2] ArmPkg/Include: Add standard SMC function IDs for 
> MM interface.
>
> Hi Ard/Supreeth,
>
> On Fri, Oct 06, 2017 at 10:05:46PM +0100, Ard Biesheuvel wrote:
> > On 27 September 2017 at 19:58, Supreeth Venkatesh
> >  wrote:
> > > This patch adds a list of function IDs that fall under the standard
> > > SMC range as defined in
> > > http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf.
> > >
> > > SMCs associated with Management Mode are in the range 0xC440 -
> > > 0xC45f (64 bit) and 0x8440 - 0x845f (32 bit).
> > >
> > > The function(s) available to the normal world:
> > > 1. Request services from the secure MM environment using MM_COMMUNICATE.
> > >
> > > It also defines MM return codes.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Achin Gupta 
> > > Signed-off-by: Supreeth Venkatesh 
> >
> > Both patches applied. Thanks.
>
> I should have spotted this earlier but the following define is not spec. 
> compliant. It says:
>
> > +#define ARM_SMC_MM_RET_NO_MEMORY   -4
>
> but should be
>
> > +#define ARM_SMC_MM_RET_NO_MEMORY   -5
>
> Supreeth. Could you please submit a patch to rectify this?
>
> cheers,
> Achin
>
> >
> > > ---
> > >  ArmPkg/Include/IndustryStandard/ArmStdSmc.h | 20
> > > +++-
> > >  1 file changed, 19 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> > > b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> > > index 593a3ce729..37d0796649 100644
> > > --- a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> > > +++ b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> > > @@ -1,6 +1,6 @@
> > >  /** @file
> > >  *
> > > -*  Copyright (c) 2012-2014, ARM Limited. All rights reserved.
> > > +*  Copyright (c) 2012-2017, ARM Limited. All rights reserved.
> > >  *
> > >  *  This program and the accompanying materials
> > >  *  are licensed and made available under the terms and conditions
> > > of the BSD License @@ -40,6 +40,24 @@
> > >  #define ARM_SMC_STD_REVISION_MAJOR0x0
> > >  #define ARM_SMC_STD_REVISION_MINOR0x1
> > >
> > > +/*
> > > + * Management Mode (MM) calls cover a subset of the Standard Service 
> > > Call range.
> > > + * The list below is not exhaustive.
> > > + */
> > > +#define ARM_SMC_ID_MM_VERSION_AARCH32  0x8440
> > > +#define ARM_SMC_ID_MM_VERSION_AARCH64  0xC440
> > > +
> > > +// Request service from secure standalone MM environment
> > > +#define ARM_SMC_ID_MM_COMMUNICATE_AARCH32  0x8441
> > > +#define ARM_SMC_ID_MM_COMMUNICATE_AARCH64  0xC441
> > > +
> > > +/* MM return error codes */
> > > +#define ARM_SMC_MM_RET_SUCCESS  0
> > > +#define ARM_SMC_MM_RET_NOT_SUPPORTED   -1
> > > +#define ARM_SMC_MM_RET_INVALID_PARAMS  -2
> > > +#define ARM_SMC_MM_RET_DENIED  -3
> > > +#define ARM_SMC_MM_RET_NO_MEMORY   -4
> > > +
> > >  /*
> > >   * Power State Coordination Interface (PSCI) calls cover a subset of the
> > >   * Standard Service Call range.
> > > --
> > > 2.14.1
> > >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] SError Exception and HCR_EL2 Usage

[Ard Biesheuvel]

On 9 October 2017 at 18:33, Vabhav Sharma  wrote:
> Dear Experts,
>
> I am facing SError exception during UEFI bring-up.
> At boot , secure f/w starts in EL3 and loads UEFI image to DDR. After this 
> secure f/w passes control to UEFI in EL2.
>
> I debugged and manifest the problem by adding below lines in UEFI PrePi entry 
> point(ModuleEntryPoint.S)
>
> ASM_FUNC(_ModuleEntryPoint)
>
> +msr  daifclr,#4
>
> +isb
>
> +mrs x0, hcr_el2
>
> +ldr x1, =0x0800
>
> +orr x0, x0, x1
>
> +msr hcr_el2, x0
>
> +isb
>
>
>
> Once exception occurs than ELR_EL2 point to 'isb' instruction and ESR_EL2 is 
> SError Exception syndrome.
>
> Could you please suggest if this is UEFI problem or Secure f/w issue?
>

As I said before, if the SError hits as soon as you unmask it in EL2
(which appears what you are doing as the very first instruction when
entering EL2), it is very unlikely that it was triggered by code
running at EL2.

> Additionally, TGE bit is set in hcr_el2 three times during PrePei 
> phase(ArmPlatformPkg/PrePi/AArch64/ArchPrePi.c),DxeMain(),ArmCpuDxe.
> Please explain the purpose of setting it or require to be fixed?
>

IIRC this was added following a discussion with Eugene.

Eugene, do you remember the details? I think the general idea is that
no exceptions should be routed to EL1 before EL2 has had the chance of
setting it up.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPkg/ArmSmcPsciResetSystemLib: add support for warm reboot

[Ard Biesheuvel]

On 9 October 2017 at 19:22, Leif Lindholm  wrote:
> On Fri, Oct 06, 2017 at 09:41:52PM +0100, Ard Biesheuvel wrote:
>> PSCI SYSTEM_RESET is specified as a cold reboot, which does not
>> preserve the contents of DRAM. In version 1.1, a new reset method
>> was introduced that allows a warm reboot to be requested.
>>
>> This is especially relevant for capsule update, given that it will
>> invoke a warm reboot before processing the capsule, under the
>> assumption that the capsule will still be in memory when the PEI
>> phase is reentered.
>>
>> So wire up the [rather inaccurately named] EnterS3WithImmediateWake()
>> entry point that the capsule update runtime uses to the new PSCI 1.1
>> warm reboot. Note that many PSCI implementations will not support this
>> yet, so fall back to a cold reboot if warm reboot fails.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>
>> I don't actually need this code for Synquacer, but given that I had
>> already wrote it, we may just as well merge it.
>>
>>  ArmPkg/Include/IndustryStandard/ArmStdSmc.h| 10 
>> +++---
>>  ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c | 14 
>> --
>>  2 files changed, 19 insertions(+), 5 deletions(-)
>>
>> diff --git a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h 
>> b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
>> index 593a3ce729ce..41b086947eaa 100644
>> --- a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
>> +++ b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
>> @@ -57,10 +57,12 @@
>>  #define ARM_SMC_ID_PSCI_MIGRATE_AARCH320x8405
>>  #define ARM_SMC_ID_PSCI_SYSTEM_OFF 0x8408
>>  #define ARM_SMC_ID_PSCI_SYSTEM_RESET   0x8409
>> +#define ARM_SMC_ID_PSCI_SYSTEM_RESET2_AARCH64  0xc412
>> +#define ARM_SMC_ID_PSCI_SYSTEM_RESET2_AARCH32  0x8412
>
> If we're starting to add more of these, could we do some macro rather
> than duplication?
>
> (see below)
>
>> -/* The current PSCI version is:  0.2 */
>> -#define ARM_SMC_PSCI_VERSION_MAJOR  0
>> -#define ARM_SMC_PSCI_VERSION_MINOR  2
>> +/* The current PSCI version is:  1.1 */
>> +#define ARM_SMC_PSCI_VERSION_MAJOR  1
>> +#define ARM_SMC_PSCI_VERSION_MINOR  1
>>  #define ARM_SMC_PSCI_VERSION  \
>>((ARM_SMC_PSCI_VERSION_MAJOR << 16) | ARM_SMC_PSCI_VERSION_MINOR)
>>
>> @@ -93,4 +95,6 @@
>>  #define ARM_SMC_ID_PSCI_AFFINITY_INFO_OFF 1
>>  #define ARM_SMC_ID_PSCI_AFFINITY_INFO_ON_PENDING  2
>>
>> +#define ARM_SMC_ID_PSCI_SYSTEM_RESET2_WARM  0
>> +
>>  #endif
>> diff --git 
>> a/ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c 
>> b/ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c
>> index d6d26bce5009..ffd726554c0f 100644
>> --- a/ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c
>> +++ b/ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c
>> @@ -55,7 +55,17 @@ ResetWarm (
>>VOID
>>)
>>  {
>> -  // Map a warm reset into a cold reset
>> +  ARM_SMC_ARGS ArmSmcArgs;
>> +
>> +#if defined(MDE_CPU_AARCH64)
>> +  ArmSmcArgs.Arg0 = ARM_SMC_ID_PSCI_SYSTEM_RESET2_AARCH64;
>> +#else
>> +  ArmSmcArgs.Arg0 = ARM_SMC_ID_PSCI_SYSTEM_RESET2_AARCH32;
>> +#endif
>
> #define ARM_SMC64_VALUE 0x4000UL
> #define ARM_SMC64(x) ((x) | ARM_SMC64_VALUE)
> #define ARM_SMC32(x) ((x) & ~ARM_SMC64_VALUE)
>
> #if defined(MDE_CPU_AARCH64)
> #define ARM_SMC(x) ARM_SMC64(x)
> #else
> #define ARM_SMC(x) ARM_SMC32(x)
> #endif
>
> Want me to whip up a mini-set that does that and changes existing
> definitiions/invokations?
>

Yes please
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPkg/ArmSmcPsciResetSystemLib: add support for warm reboot

[Leif Lindholm]

On Fri, Oct 06, 2017 at 09:41:52PM +0100, Ard Biesheuvel wrote:
> PSCI SYSTEM_RESET is specified as a cold reboot, which does not
> preserve the contents of DRAM. In version 1.1, a new reset method
> was introduced that allows a warm reboot to be requested.
> 
> This is especially relevant for capsule update, given that it will
> invoke a warm reboot before processing the capsule, under the
> assumption that the capsule will still be in memory when the PEI
> phase is reentered.
> 
> So wire up the [rather inaccurately named] EnterS3WithImmediateWake()
> entry point that the capsule update runtime uses to the new PSCI 1.1
> warm reboot. Note that many PSCI implementations will not support this
> yet, so fall back to a cold reboot if warm reboot fails.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
> 
> I don't actually need this code for Synquacer, but given that I had
> already wrote it, we may just as well merge it.
> 
>  ArmPkg/Include/IndustryStandard/ArmStdSmc.h| 10 
> +++---
>  ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c | 14 
> --
>  2 files changed, 19 insertions(+), 5 deletions(-)
> 
> diff --git a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h 
> b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> index 593a3ce729ce..41b086947eaa 100644
> --- a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> +++ b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> @@ -57,10 +57,12 @@
>  #define ARM_SMC_ID_PSCI_MIGRATE_AARCH320x8405
>  #define ARM_SMC_ID_PSCI_SYSTEM_OFF 0x8408
>  #define ARM_SMC_ID_PSCI_SYSTEM_RESET   0x8409
> +#define ARM_SMC_ID_PSCI_SYSTEM_RESET2_AARCH64  0xc412
> +#define ARM_SMC_ID_PSCI_SYSTEM_RESET2_AARCH32  0x8412

If we're starting to add more of these, could we do some macro rather
than duplication?

(see below)

> -/* The current PSCI version is:  0.2 */
> -#define ARM_SMC_PSCI_VERSION_MAJOR  0
> -#define ARM_SMC_PSCI_VERSION_MINOR  2
> +/* The current PSCI version is:  1.1 */
> +#define ARM_SMC_PSCI_VERSION_MAJOR  1
> +#define ARM_SMC_PSCI_VERSION_MINOR  1
>  #define ARM_SMC_PSCI_VERSION  \
>((ARM_SMC_PSCI_VERSION_MAJOR << 16) | ARM_SMC_PSCI_VERSION_MINOR)
>  
> @@ -93,4 +95,6 @@
>  #define ARM_SMC_ID_PSCI_AFFINITY_INFO_OFF 1
>  #define ARM_SMC_ID_PSCI_AFFINITY_INFO_ON_PENDING  2
>  
> +#define ARM_SMC_ID_PSCI_SYSTEM_RESET2_WARM  0
> +
>  #endif
> diff --git 
> a/ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c 
> b/ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c
> index d6d26bce5009..ffd726554c0f 100644
> --- a/ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c
> +++ b/ArmPkg/Library/ArmSmcPsciResetSystemLib/ArmSmcPsciResetSystemLib.c
> @@ -55,7 +55,17 @@ ResetWarm (
>VOID
>)
>  {
> -  // Map a warm reset into a cold reset
> +  ARM_SMC_ARGS ArmSmcArgs;
> +
> +#if defined(MDE_CPU_AARCH64)
> +  ArmSmcArgs.Arg0 = ARM_SMC_ID_PSCI_SYSTEM_RESET2_AARCH64;
> +#else
> +  ArmSmcArgs.Arg0 = ARM_SMC_ID_PSCI_SYSTEM_RESET2_AARCH32;
> +#endif

#define ARM_SMC64_VALUE 0x4000UL
#define ARM_SMC64(x) ((x) | ARM_SMC64_VALUE)
#define ARM_SMC32(x) ((x) & ~ARM_SMC64_VALUE)

#if defined(MDE_CPU_AARCH64)
#define ARM_SMC(x) ARM_SMC64(x)
#else
#define ARM_SMC(x) ARM_SMC32(x)
#endif

Want me to whip up a mini-set that does that and changes existing
definitiions/invokations?

/
Leif

> +  ArmSmcArgs.Arg1 = ARM_SMC_ID_PSCI_SYSTEM_RESET2_WARM;
> +  ArmCallSmc (&ArmSmcArgs);
> +
> +  // Fall back to cold reset if unsupported
>ResetCold ();
>  }
>  
> @@ -89,7 +99,7 @@ EnterS3WithImmediateWake (
>VOID
>)
>  {
> -  // Not implemented
> +  ResetWarm ();
>  }
>  
>  /**
> -- 
> 2.11.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] SError Exception and HCR_EL2 Usage

[Vabhav Sharma]

Dear Experts,

I am facing SError exception during UEFI bring-up.
At boot , secure f/w starts in EL3 and loads UEFI image to DDR. After this 
secure f/w passes control to UEFI in EL2.

I debugged and manifest the problem by adding below lines in UEFI PrePi entry 
point(ModuleEntryPoint.S)

ASM_FUNC(_ModuleEntryPoint)

+msr  daifclr,#4

+isb

+mrs x0, hcr_el2

+ldr x1, =0x0800

+orr x0, x0, x1

+msr hcr_el2, x0

+isb



Once exception occurs than ELR_EL2 point to 'isb' instruction and ESR_EL2 is 
SError Exception syndrome.

Could you please suggest if this is UEFI problem or Secure f/w issue?

Additionally, TGE bit is set in hcr_el2 three times during PrePei 
phase(ArmPlatformPkg/PrePi/AArch64/ArchPrePi.c),DxeMain(),ArmCpuDxe.
Please explain the purpose of setting it or require to be fixed?

Regards,
Vabhav

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] MTFTP file transfer timeout error

[Vabhav Sharma]

Hi Fu Siyuan,
Thank you for explanation and hope you enjoyed vacation.

I am using 32K block size for file transfer.
IP layer divides the 32K block size into 23 number of fragments(with last 
fragment of less size indicating no more fragments)

Using tcpdump and debug code the flow is:
NIC interface receives 23 fragments and pass it to upper layer.
Mtftp4 Client receives the data block 'x' with expected block number 'x+1'
Mtftp4 Client Sends ACK for received data block 'x'
After receiving approximate 900x block, NIC interface receive 22 fragments 
instead of 23(One packet drop),At this point function MnpReceivePacket() didn't 
receive more packets with status as 'EFI_NOT_READY' with
<>TFTP Server keeps on sending data(23 fragments) block 'x+1'(900) expecting 
ACK for data block 'x+1'(900),Whereas
<>Mtftp4 Client retransmit acknowledgement six times for data block 'x'(899) 
before going to timeout expecting next data block 'x+1'(900).

Added debug logs in the below code and Mtft4 client didn't receive data once 
MnpReceivePacket() status is set to 'EFI_NOT_READY'  causing timeout.
Is this expected if one frame is dropped at Ethernet Layer than whole packet 
will be discarded at IP layer?

Regards,
Vabhav

-Original Message-
From: Fu, Siyuan [mailto:siyuan...@intel.com] 
Sent: Monday, October 09, 2017 7:28 AM
To: Vabhav Sharma ; edk2-devel@lists.01.org
Subject: RE: MTFTP file transfer timeout error

Hi, Vabhav

Sorry for the late response, I just came back from the vacation.

The default retry count for tftp shell command is 6, which means the ACK packet 
will be retransmitted 6 times before the code goes to the 
Mtftp4CleanOperation() you marked below. The MTFTP driver always saves the last 
transmitted packet in Instance->LastPacket, and the Mtftp4Retransmit() will try 
to retransmit it if not reach the max retry count.

As you mentioned 1K block size is always success, I guess it's may because the 
IP fragment. A MTFTP(UDP) packet which is larger than 1.5K (the default MTU) 
will be fragmented to several IP frame. During the transmit, the whole UDP 
packet will be discarded by the IP layer if any of the IP fragment is lost in 
the network. As a result, using large MTFTP block size will increase the 
possibility of timeout in bad network connection.

I suggest you add some debug in Mtftp4RrqInput() in below lines to confirm if 
the EFI client can receive the MTFTP packet correctly, also you could use 
Wireshark in your server to check whether it receives the ACK from client.
switch (Opcode) {
case EFI_MTFTP4_OPCODE_DATA:
if ((Len > (UINT32) (MTFTP4_DATA_HEAD_LEN + Instance->BlkSize)) ||
 (Len < (UINT32) MTFTP4_DATA_HEAD_LEN)) {
goto ON_EXIT;
 }

 Status = Mtftp4RrqHandleData (Instance, Packet, Len, Multicast, 
&Completed);
 break;


BestRegards
Fu Siyuan


-Original Message-
From: Vabhav Sharma [mailto:vabhav.sha...@nxp.com]
Sent: Friday, October 6, 2017 1:26 AM
To: Fu, Siyuan ; edk2-devel@lists.01.org
Subject: RE: MTFTP file transfer timeout error

Dear Experts,

I traced that timeout error for different block size during file transfer using 
tftp(rrq opcode)  is returned from function  Mtftp4OnTimerTick() TFTP layer in 
UEFI network stack.
Mtftp4OnTimerTick()
//
// Retransmit the packet if haven't reach the maxmium retry count,
// otherwise exit the transfer.
//
if (++Instance->CurRetry < Instance->MaxRetry) {
  Mtftp4Retransmit (Instance);
  Mtftp4SetTimeout (Instance);
} else {
  Mtftp4CleanOperation (Instance, EFI_TIMEOUT);//Timeout is set
  continue;
}

Once this is set, It gets populated to downloadfile() function in tftp shellpkg 
library.
There seems to be issue(corruption) with tfp client state machine -Not sending 
ACK for received data blocks -Sending duplicate ACK

If server don't receive ACK, It stops sending data packets and timeout occurs 
after maximum retry.
Please suggest if this is new or known issue to be fixed?

Regards,
Vabhav

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Vabhav 
Sharma
Sent: Thursday, September 28, 2017 5:04 PM
To: siyuan...@intel.com
Cc: edk2-devel@lists.01.org; edk2-devel 
Subject: Re: [edk2] MTFTP file transfer timeout error

[This sender failed our fraud detection checks and may not be who they appear 
to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]

Hello Fu Siyuan,
I see that blocksize option with tftp command is introduced with commit 
2be45bfe2779043bc3566e879e7ec279412012dc.
Could you please help me clarify with the timeout error behavior observed in 
previous mail

Please note the behavior varies for different file type(Attached sheet) 
Regards, Vabhav

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Vabhav 
Sharma
Sent: Saturday, September 23, 2017 4:21 PM
To: edk2-devel@lists.01.org; edk2-devel 

[edk2] [platforms: PATCH 12/13] Marvell/Armada: Add the UefiPxeBcDxe driver

[Marcin Wojtas]

From: Ard Biesheuvel 

This driver allows automatic booting via the network.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada/Armada.dsc.inc | 1 +
 Platform/Marvell/Armada/Armada70x0.fdf | 1 +
 2 files changed, 2 insertions(+)

diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
b/Platform/Marvell/Armada/Armada.dsc.inc
index 5a5fde9..1aa485c 100644
--- a/Platform/Marvell/Armada/Armada.dsc.inc
+++ b/Platform/Marvell/Armada/Armada.dsc.inc
@@ -412,6 +412,7 @@
   MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
   MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
   MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
+  MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
   Platform/Marvell/Drivers/Net/MvMdioDxe/MvMdioDxe.inf
   Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.inf
   Platform/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.inf
diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
b/Platform/Marvell/Armada/Armada70x0.fdf
index 15ae52b..bf54c6e 100644
--- a/Platform/Marvell/Armada/Armada70x0.fdf
+++ b/Platform/Marvell/Armada/Armada70x0.fdf
@@ -125,6 +125,7 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
   INF MdeModulePkg/Universal/Network/Mtftp4Dxe/Mtftp4Dxe.inf
   INF MdeModulePkg/Universal/Network/Udp4Dxe/Udp4Dxe.inf
   INF MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
+  INF MdeModulePkg/Universal/Network/UefiPxeBcDxe/UefiPxeBcDxe.inf
   INF Platform/Marvell/Drivers/Net/MvMdioDxe/MvMdioDxe.inf
   INF Platform/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.inf
   INF Platform/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.inf
-- 
1.8.3.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [platforms: PATCH 13/13] Marvell/Documentation: Follow EDK2 coding style in the PortingGuide

[Marcin Wojtas]

This patch removes tabs and wrong line endings in the file, maiking
it acceptable to the PatchCheck.py script.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Documentation/PortingGuide.txt | 800 ++--
 1 file changed, 400 insertions(+), 400 deletions(-)

diff --git a/Silicon/Marvell/Documentation/PortingGuide.txt 
b/Silicon/Marvell/Documentation/PortingGuide.txt
index f0da515..66ec918 100644
--- a/Silicon/Marvell/Documentation/PortingGuide.txt
+++ b/Silicon/Marvell/Documentation/PortingGuide.txt
@@ -1,400 +1,400 @@
-UEFI Porting Guide
-==
-
-This document provides instructions for adding support for new Marvell Armada
-board. For the sake of simplicity new Marvell board will be called "new_board".
-
-1. Create configuration files for new target
-   1.1 Create FDF file for new board
-
-- Copy and rename 
edk2-platforms/Platform/Marvell/Armada/Armada70x0.fdf to
-  edk2-platforms/Platform/Marvell/Armada/new_board.fdf
-- Change the first no-comment line:
-  [FD.Armada70x0_EFI] to [FD.{new_board}_EFI]
-
-   1.2 Create DSC file for new board
-
-- Add new_board.dsc file to edk2-platforms/Platform/Marvell/Armada 
directory
-- Insert following [Defines] section to new_board.dsc:
-
-   [Defines]
- PLATFORM_NAME  = {new_board}
- PLATFORM_GUID  = 
{newly_generated_GUID}
- PLATFORM_VERSION   = 0.1
- DSC_SPECIFICATION  = 0x00010019
- OUTPUT_DIRECTORY   = {output_directory}
- SUPPORTED_ARCHITECTURES= AARCH64
- BUILD_TARGETS  = DEBUG|RELEASE
- SKUID_IDENTIFIER   = DEFAULT
- FLASH_DEFINITION   = {path_to_fdf_file}
-
-- Add "!include Armada.dsc.inc" entry to new_board.dsc
-
-2. Driver support
- - According to content of files from
-   edk2-platforms/Silicon/Marvell/Documentation/PortingGuide.txt
-   insert PCD entries into new_board.dsc for every needed interface (as listed 
below).
-
-3. Compilation
- - Refer to edk2-platforms/Platform/Marvell/Readme.md. Remember to change
-   {platform} to new_board in order to point build system to newly created DSC 
file.
-
-4. Output file
- - Output files (and among others FD file, which may be used by ATF) are
-   generated under directory pointed by "OUTPUT_DIRECTORY" entry (see point 
1.2).
-
-
-COMPHY configuration
-
-In order to configure ComPhy library, following PCDs are available:
-
-  - gMarvellTokenSpaceGuid.PcdComPhyDevices
-
-This array indicates, which ones of the ComPhy chips defined in
-MVHW_COMPHY_DESC template will be configured.
-
-Every ComPhy PCD has  part where  stands for chip ID (order is not
-important, but configuration will be set for first PcdComPhyChipCount chips).
-
-Every chip has 3 ComPhy PCDs and three of them comprise per-board lanes
-settings for this chip. Their format is array of up to 10 values reflecting
-defined numbers for SPEED/TYPE/INVERT, whose description can be found in:
-
-  OpenPlatformPkg/Platforms/Marvell/Library/ComPhyLib/ComPhyLib.h
-
-  - gMarvellTokenSpaceGuid.PcdChip0ComPhyTypes
-   (Array of types - currently supported are:
-
-   CP_UNCONNECTED  0x0
-   CP_PCIE00x1
-   CP_PCIE10x2
-   CP_PCIE20x3
-   CP_PCIE30x4
-   CP_SATA00x5
-   CP_SATA10x6
-   CP_SATA20x7
-   CP_SATA30x8
-   CP_SGMII0   0x9
-   CP_SGMII1   0xA
-   CP_SGMII2   0xB
-   CP_SGMII3   0xC
-   CP_QSGMII   0xD
-   CP_USB3_HOST0   0xE
-   CP_USB3_HOST1   0xF
-   CP_USB3_DEVICE  0x10
-   CP_XAUI00x11
-   CP_XAUI10x12
-   CP_XAUI20x13
-   CP_XAUI30x14
-   CP_RXAUI0   0x15
-   CP_RXAUI1   0x16
-   CP_SFI  0x17 )
-
-  - gMarvellTokenSpaceGuid.PcdChip0ComPhySpeeds
-   (Array of speeds - currently supported are:
-
-   CP_1_25G0x1
-   CP_1_5G 0x2
-   CP_2_5G 0x3
-   CP_3G   0x4
-   CP_3_125G   0x5
- 

[edk2] [platforms: PATCH 11/13] Marvell/Armada: Remove outdated SEC alignment override

[Marcin Wojtas]

From: Ard Biesheuvel 

The FDFs no longer require explicit alignment for sections containing
aligned objects, so change it to 'Auto' and FIXED (which allows some
padding to be removed), and remove some other cruft while at it.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada/Armada70x0.fdf | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
b/Platform/Marvell/Armada/Armada70x0.fdf
index 2c3efe0..15ae52b 100644
--- a/Platform/Marvell/Armada/Armada70x0.fdf
+++ b/Platform/Marvell/Armada/Armada70x0.fdf
@@ -235,16 +235,9 @@ READ_LOCK_STATUS   = TRUE
 #
 
 
-[Rule.ARM.SEC]
-  FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
-TE  TEAlign = 32$(INF_OUTPUT)/$(MODULE_NAME).efi
-  }
-
-# The AArch64 Vector Table requires a 2K alignment that is not supported by 
the FDF specification.
-# It is the reason 4K is used instead of 2K for the module alignment.
 [Rule.AARCH64.SEC]
-  FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED {
-TE  TEAlign = 4K$(INF_OUTPUT)/$(MODULE_NAME).efi
+  FILE SEC = $(NAMED_GUID) RELOCS_STRIPPED FIXED {
+TE  TEAlign = Auto$(INF_OUTPUT)/$(MODULE_NAME).efi
   }
 
 [Rule.Common.PEI_CORE]
-- 
1.8.3.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [platforms: PATCH 08/13] Marvell/Armada: Modify GICC alias

[Marcin Wojtas]

From: Ard Biesheuvel 

The GIC architecture mandates that the CPU interface, which consists
of 2 consecutive 4 KB frames, can be mapped using separate mappings.
Since this is problematic on 64 KB pages, the MMU-400 aliases each
frame 16 times, and the two consecutive frames can be found at offset
0xf000. This patch is intended to expose correct GICC alias via
MADT, once ACPI support is added.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada/Armada.dsc.inc | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
b/Platform/Marvell/Armada/Armada.dsc.inc
index 5071bd5..bd2336f 100644
--- a/Platform/Marvell/Armada/Armada.dsc.inc
+++ b/Platform/Marvell/Armada/Armada.dsc.inc
@@ -263,7 +263,14 @@
 
   # ARM Generic Interrupt Controller
   gArmTokenSpaceGuid.PcdGicDistributorBase|0xF021
-  gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0xF022
+
+  #
+  # NOTE: the GIC architecture mandates that the CPU interface, which consists
+  # of 2 consecutive 4 KB frames, can be mapped using separate mappings.
+  # Since this is problematic on 64 KB pages, the MMU-400 aliases each frame
+  # 16 times, and the two consecutive frames can be found at offset 0xf000
+  #
+  gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase|0xF022F000
 
   # ARM Architectural Timer Support
   gArmTokenSpaceGuid.PcdArmArchTimerFreqInHz|2500
-- 
1.8.3.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [platforms: PATCH 09/13] Marvell/Armada: Disable PerformanceLibrary

[Marcin Wojtas]

From: Ard Biesheuvel 

Remove the gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask
setting so it reverts to its default of 0, and disables performance
profiling.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada/Armada.dsc.inc | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
b/Platform/Marvell/Armada/Armada.dsc.inc
index bd2336f..b718c60 100644
--- a/Platform/Marvell/Armada/Armada.dsc.inc
+++ b/Platform/Marvell/Armada/Armada.dsc.inc
@@ -251,7 +251,6 @@
   gEfiMdePkgTokenSpaceGuid.PcdMaximumLinkedListLength|100
   gEfiMdePkgTokenSpaceGuid.PcdSpinLockTimeout|1000
   gEfiMdePkgTokenSpaceGuid.PcdDebugClearMemoryValue|0xAF
-  gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask|1
   gEfiMdePkgTokenSpaceGuid.PcdPostCodePropertyMask|0
   gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|320
   gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|1
-- 
1.8.3.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [platforms: PATCH 10/13] Marvell/Armada: Switch to unicore PrePi

[Marcin Wojtas]

From: Ard Biesheuvel 

There is no point in using the MPCore PrePi, given that only the primary
core will enter UEFI at EL2, and the secondaries will be held in EL3
until summoned by the OS. So use the unicore flavour instead.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada/Armada.dsc.inc | 2 +-
 Platform/Marvell/Armada/Armada70x0.fdf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
b/Platform/Marvell/Armada/Armada.dsc.inc
index b718c60..5a5fde9 100644
--- a/Platform/Marvell/Armada/Armada.dsc.inc
+++ b/Platform/Marvell/Armada/Armada.dsc.inc
@@ -372,7 +372,7 @@
 [Components.common]
 
   # PEI Phase modules
-  ArmPlatformPkg/PrePi/PeiMPCore.inf
+  ArmPlatformPkg/PrePi/PeiUniCore.inf
 
   # DXE
   MdeModulePkg/Core/Dxe/DxeMain.inf {
diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
b/Platform/Marvell/Armada/Armada70x0.fdf
index 999b968..2c3efe0 100644
--- a/Platform/Marvell/Armada/Armada70x0.fdf
+++ b/Platform/Marvell/Armada/Armada70x0.fdf
@@ -199,7 +199,7 @@ READ_STATUS= TRUE
 READ_LOCK_CAP  = TRUE
 READ_LOCK_STATUS   = TRUE
 
-  INF ArmPlatformPkg/PrePi/PeiMPCore.inf
+  INF ArmPlatformPkg/PrePi/PeiUniCore.inf
 
   FILE FV_IMAGE = 9E21FD93-9C72-4c15-8C4B-E77F1DB2D792 {
 SECTION GUIDED EE4E5898-3914-4259-9D6E-DC7BD79403CF PROCESSING_REQUIRED = 
TRUE {
-- 
1.8.3.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [platforms: PATCH 06/13] Marvell/Armada: Switch to generic BDS

[Marcin Wojtas]

From: Ard Biesheuvel 

Switch from the Intel BDS to the generic BDS, which is preferred for
ARM platforms given that it is completely legacy free.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada/Armada.dsc.inc | 19 ---
 Platform/Marvell/Armada/Armada70x0.fdf |  3 ++-
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
b/Platform/Marvell/Armada/Armada.dsc.inc
index 1b4e713..e920461 100644
--- a/Platform/Marvell/Armada/Armada.dsc.inc
+++ b/Platform/Marvell/Armada/Armada.dsc.inc
@@ -126,8 +126,9 @@
 
   # BDS Libraries
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
-  GenericBdsLib|IntelFrameworkModulePkg/Library/GenericBdsLib/GenericBdsLib.inf
-  
PlatformBdsLib|ArmPlatformPkg/Library/PlatformIntelBdsLib/PlatformIntelBdsLib.inf
+  BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
+  FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
+  
PlatformBootManagerLib|ArmPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
   FdtLib|EmbeddedPkg/Library/FdtLib/FdtLib.inf
 
@@ -350,6 +351,12 @@
   # Shell.
   gEfiShellPkgTokenSpaceGuid.PcdShellLibAutoInitialize|FALSE
 
+  # GUID of the generic BDS UiApp
+  gEfiMdeModulePkgTokenSpaceGuid.PcdBootManagerMenuFile|{ 0x21, 0xaa, 0x2c, 
0x46, 0x14, 0x76, 0x03, 0x45, 0x83, 0x6e, 0x8a, 0xb6, 0xf4, 0x66, 0x23, 0x31 }
+
+  # use the 'TTYTERM' terminal type for optimal compatibility with Linux 
terminal emulators
+  gEfiMdePkgTokenSpaceGuid.PcdDefaultTerminalType|4
+
   # ARM Pcds
   gArmTokenSpaceGuid.PcdSystemMemoryBase|0
   gArmTokenSpaceGuid.PcdSystemMemorySize|0x4000
@@ -459,7 +466,13 @@
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
-  IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
+  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
+  MdeModulePkg/Application/UiApp/UiApp.inf {
+
+  NULL|MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
+  NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
+  
NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
+  }
 
   # UEFI application (Shell Embedded Boot Loader)
   ShellPkg/Application/Shell/Shell.inf {
diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
b/Platform/Marvell/Armada/Armada70x0.fdf
index b3d1c60..999b968 100644
--- a/Platform/Marvell/Armada/Armada70x0.fdf
+++ b/Platform/Marvell/Armada/Armada70x0.fdf
@@ -175,7 +175,8 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
   INF MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   INF MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   INF MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
-  INF IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf
+  INF MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
+  INF MdeModulePkg/Application/UiApp/UiApp.inf
 
 
 # PEI phase firmware volume
-- 
1.8.3.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [platforms: PATCH 07/13] Marvell/Armada: Re-enable driver model diagnostics PCDs

[Marcin Wojtas]

From: Ard Biesheuvel 

For some reason, one of the early ARM platforms disabled all the
diagnostics related to the UEFI driver model, resulting in the
output of UEFI shell utilities such as 'devices' or 'drivers' to
become completely useless. Armada's shared .DSC include file
inherited this for no good reason, so let's revert it.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada/Armada.dsc.inc | 4 
 1 file changed, 4 deletions(-)

diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
b/Platform/Marvell/Armada/Armada.dsc.inc
index e920461..5071bd5 100644
--- a/Platform/Marvell/Armada/Armada.dsc.inc
+++ b/Platform/Marvell/Armada/Armada.dsc.inc
@@ -207,10 +207,6 @@
 

 
 [PcdsFeatureFlag.common]
-  gEfiMdePkgTokenSpaceGuid.PcdComponentNameDisable|TRUE
-  gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnosticsDisable|TRUE
-  gEfiMdePkgTokenSpaceGuid.PcdComponentName2Disable|TRUE
-  gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnostics2Disable|TRUE
 
   #
   # Control what commands are supported from the UI
-- 
1.8.3.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [platforms: PATCH 04/13] Marvell/Armada: Armada70x0Lib: Clean FV in the D-cache before boot

[Marcin Wojtas]

From: Ard Biesheuvel 

To prevent cache coherency issues when chainloading via U-Boot, clean
and invalidate the FV image in the caches before re-enabling the MMU.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S | 15 
+++
 Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.inf   |  3 
+++
 2 files changed, 18 insertions(+)

diff --git 
a/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S 
b/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S
index 72f8cfc..7544361 100644
--- a/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S
+++ b/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S
@@ -17,6 +17,21 @@
 
 ASM_FUNC(ArmPlatformPeiBootAction)
   mov   x29, xzr
+
+  MOV32 (x0, FixedPcdGet64 (PcdFvBaseAddress))
+  MOV32 (x3, FixedPcdGet32 (PcdFvSize))
+  add   x3, x3, x0
+
+  mrs   x1, ctr_el0
+  and   x1, x1, #0xf  // Dminline
+  mov   x2, #4
+  lsl   x1, x2, x1// by-VA stride for D-cache maintenance
+
+0:dccivac, x0
+  add   x0, x0, x1
+  cmp   x0, x3
+  b.lt  0b
+
   ret
 
 //UINTN
diff --git a/Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.inf 
b/Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.inf
index 2e198c3..6966683 100644
--- a/Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.inf
+++ b/Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.inf
@@ -67,5 +67,8 @@
   gArmTokenSpaceGuid.PcdArmPrimaryCoreMask
   gArmTokenSpaceGuid.PcdArmPrimaryCore
 
+  gArmTokenSpaceGuid.PcdFvBaseAddress
+  gArmTokenSpaceGuid.PcdFvSize
+
 [Ppis]
   gArmMpCoreInfoPpiGuid
-- 
1.8.3.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [platforms: PATCH 00/13] Armada 7k/8k - misc improvements

[Marcin Wojtas]

Hi,

This patchset is a first part of general platform support improvements.
It consists of a series of short changes, maybe except for the
initialization phase DXE driver.

The patches are available in the github (from now on pushed as a branch):
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/misc-upstream-r20171009

I'm looking forward to your comments or remarks.

Best regards,
Marcin

Ard Biesheuvel (11):
  Marvell/Armada: Switch to dynamic PCDs
  Marvell/Armada: Armada70x0Lib: Terminate call stack list at entry
  Marvell/Armada: Armada70x0Lib: Clean FV in the D-cache before boot
  Marvell/Armada: Use 4k/64k aligned sections for DXE/DXE-rt modules
  Marvell/Armada: Switch to generic BDS
  Marvell/Armada: Re-enable driver model diagnostics PCDs
  Marvell/Armada: Modify GICC alias
  Marvell/Armada: Disable PerformanceLibrary
  Marvell/Armada: Switch to unicore PrePi
  Marvell/Armada: Remove outdated SEC alignment override
  Marvell/Armada: Add the UefiPxeBcDxe driver

Marcin Wojtas (2):
  Marvell/Armada: Introduce platform initialization driver
  Marvell/Documentation: Follow EDK2 coding style in the PortingGuide

 Platform/Marvell/Armada/Armada.dsc.inc|  
55 +-
 Platform/Marvell/Armada/Armada70x0.fdf|  
23 +-
 Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c |  
44 ++
 Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf   |  
44 ++
 Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S |  
16 +
 Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.c |  
11 -
 Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.inf   |   
3 +
 Platform/Marvell/Marvell.dec  |   
5 +
 Silicon/Marvell/Documentation/PortingGuide.txt| 
800 ++--
 9 files changed, 566 insertions(+), 435 deletions(-)
 create mode 100644 Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c
 create mode 100644 Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf

-- 
1.8.3.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [platforms: PATCH 03/13] Marvell/Armada: Armada70x0Lib: Terminate call stack list at entry

[Marcin Wojtas]

From: Ard Biesheuvel 

To avoid dereferencing junk when walking the call stack in exception
handlers (which may prevent us from getting a full backtrace), set
the frame pointer to 0x0 when first entering UEFI.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S 
b/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S
index 9265636..72f8cfc 100644
--- a/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S
+++ b/Platform/Marvell/Armada/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S
@@ -16,6 +16,7 @@
 #include 
 
 ASM_FUNC(ArmPlatformPeiBootAction)
+  mov   x29, xzr
   ret
 
 //UINTN
-- 
1.8.3.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [platforms: PATCH 05/13] Marvell/Armada: Use 4k/64k aligned sections for DXE/DXE-rt modules

[Marcin Wojtas]

From: Ard Biesheuvel 

Enable strict memory protection at boot time and under the OS, by using
4 KB section alignment for DXE_DRIVER, UEFI_DRIVER and UEFI_APPLICATION
modules, and 64 KB alignment for DXE_RUNTIME_DRIVER modules. Note that
the latter is mandated by the UEFI spec.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada/Armada.dsc.inc | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
b/Platform/Marvell/Armada/Armada.dsc.inc
index 433892e..1b4e713 100644
--- a/Platform/Marvell/Armada/Armada.dsc.inc
+++ b/Platform/Marvell/Armada/Armada.dsc.inc
@@ -486,6 +486,12 @@
   gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
   }
 
+[BuildOptions.common.EDKII.DXE_CORE,BuildOptions.common.EDKII.DXE_DRIVER,BuildOptions.common.EDKII.UEFI_DRIVER,BuildOptions.common.EDKII.UEFI_APPLICATION]
+  GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1000
+
+[BuildOptions.common.EDKII.DXE_RUNTIME_DRIVER]
+  GCC:*_*_*_DLINK_FLAGS = -z common-page-size=0x1
+
 

 #
 # Defines - platform description macros
-- 
1.8.3.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [platforms: PATCH 02/13] Marvell/Armada: Switch to dynamic PCDs

[Marcin Wojtas]

From: Ard Biesheuvel 

For full functionality, including HII forms wired to non-volatile UEFI
variables, we need dynamic PCDs as well. So let's enable those.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada/Armada.dsc.inc | 10 +++---
 Platform/Marvell/Armada/Armada70x0.fdf |  1 +
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
b/Platform/Marvell/Armada/Armada.dsc.inc
index 417bb0c..433892e 100644
--- a/Platform/Marvell/Armada/Armada.dsc.inc
+++ b/Platform/Marvell/Armada/Armada.dsc.inc
@@ -67,8 +67,7 @@
   
UefiHiiServicesLib|MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
   UefiRuntimeLib|MdePkg/Library/UefiRuntimeLib/UefiRuntimeLib.inf
 
-  # Assume everything is fixed at build. do not use runtime PCD feature
-  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+  PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
 
   BaseMemoryLib|MdePkg/Library/BaseMemoryLibOptDxe/BaseMemoryLibOptDxe.inf
 
@@ -150,6 +149,7 @@
   
PrePiHobListPointerLib|ArmPlatformPkg/Library/PrePiHobListPointerLib/PrePiHobListPointerLib.inf
   PlatformPeiLib|ArmPlatformPkg/PlatformPei/PlatformPeiLib.inf
   ArmGicArchLib|ArmPkg/Library/ArmGicArchSecLib/ArmGicArchSecLib.inf
+  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
 
 [LibraryClasses.common.SEC, LibraryClasses.common.PEIM]
   MemoryInitPeiLib|ArmPlatformPkg/MemoryInitPei/MemoryInitPeiLib.inf
@@ -368,10 +368,14 @@
   # DXE
   MdeModulePkg/Core/Dxe/DxeMain.inf {
 
-  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
   
NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32GuidedSectionExtractLib.inf
   }
 
+  MdeModulePkg/Universal/PCD/Dxe/Pcd.inf {
+
+  PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
+  }
+
   # Architectural Protocols DXE
   ArmPkg/Drivers/CpuDxe/CpuDxe.inf
   ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
b/Platform/Marvell/Armada/Armada70x0.fdf
index 763d76a..b3d1c60 100644
--- a/Platform/Marvell/Armada/Armada70x0.fdf
+++ b/Platform/Marvell/Armada/Armada70x0.fdf
@@ -95,6 +95,7 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
   INF Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf
 
   # PI DXE Drivers producing Architectural Protocols (EFI Services)
+  INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
   INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf
   INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
   INF ArmPkg/Drivers/TimerDxe/TimerDxe.inf
-- 
1.8.3.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [platforms: PATCH 01/13] Marvell/Armada: Introduce platform initialization driver

[Marcin Wojtas]

In order to enable modification of dynamic PCD's for the libraries
and DXE drivers, this patch introduces new driver. It is
executed prior to other drivers. Mpp, ComPhy and Utmi libraries
initialization were moved from PrePi stage to DXE.

To force the correct driver dispatch sequence, introduce a protocol GUID
and install the protocol as a NULL protocol when PlatInitDxe executes.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
Signed-off-by: Ard Biesheuvel 
---
 Platform/Marvell/Armada/Armada.dsc.inc|  3 ++
 Platform/Marvell/Armada/Armada70x0.fdf|  5 +++
 Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c | 44 

 Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf   | 44 

 Platform/Marvell/Armada/Library/Armada70x0Lib/Armada70x0Lib.c | 11 -
 Platform/Marvell/Marvell.dec  |  5 +++
 6 files changed, 101 insertions(+), 11 deletions(-)

diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
b/Platform/Marvell/Armada/Armada.dsc.inc
index 89fb7e7..417bb0c 100644
--- a/Platform/Marvell/Armada/Armada.dsc.inc
+++ b/Platform/Marvell/Armada/Armada.dsc.inc
@@ -378,6 +378,9 @@
   ArmPkg/Drivers/TimerDxe/TimerDxe.inf
   ArmPkg/Drivers/GenericWatchdogDxe/GenericWatchdogDxe.inf
 
+  # Platform Initialization
+  Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf
+
   # Platform drivers
   Platform/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
   MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
diff --git a/Platform/Marvell/Armada/Armada70x0.fdf 
b/Platform/Marvell/Armada/Armada70x0.fdf
index c861e78..763d76a 100644
--- a/Platform/Marvell/Armada/Armada70x0.fdf
+++ b/Platform/Marvell/Armada/Armada70x0.fdf
@@ -89,6 +89,11 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
 
   INF MdeModulePkg/Core/Dxe/DxeMain.inf
 
+  #
+  # Platform Initialization
+  #
+  INF Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf
+
   # PI DXE Drivers producing Architectural Protocols (EFI Services)
   INF ArmPkg/Drivers/CpuDxe/CpuDxe.inf
   INF ArmPkg/Drivers/ArmGic/ArmGicDxe.inf
diff --git a/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c 
b/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c
new file mode 100644
index 000..919454b
--- /dev/null
+++ b/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.c
@@ -0,0 +1,44 @@
+/** @file
+  Copyright (C) Marvell International Ltd. and its affiliates
+
+  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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+EFI_STATUS
+EFIAPI
+ArmadaPlatInitDxeEntryPoint (
+  IN EFI_HANDLE ImageHandle,
+  IN EFI_SYSTEM_TABLE   *SystemTable
+  )
+{
+  EFI_STATUSStatus;
+
+  DEBUG ((DEBUG_ERROR, "\nArmada Platform Init\n\n"));
+
+  Status = gBS->InstallProtocolInterface (&ImageHandle,
+  &gMarvellPlatformInitCompleteProtocolGuid,
+  EFI_NATIVE_INTERFACE,
+  NULL);
+  ASSERT_EFI_ERROR (Status);
+
+  MvComPhyInit ();
+  UtmiPhyInit ();
+  MppInitialize ();
+
+  return EFI_SUCCESS;
+}
diff --git a/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf 
b/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf
new file mode 100644
index 000..29abcaf
--- /dev/null
+++ b/Platform/Marvell/Armada/Drivers/PlatInitDxe/PlatInitDxe.inf
@@ -0,0 +1,44 @@
+#/* @file
+#  Copyright (C) Marvell International Ltd. and its affiliates
+#
+#  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]
+  INF_VERSION= 0x00010019
+  BASE_NAME  = PlatInitDxe
+  FILE_GUID  = 8c66f65b-08a6-4c91-b993-ff81e0adf818
+  MODULE_TYPE= DXE_DRIVER
+  VERSION_STRING = 1.0
+
+  ENTRY_POINT= ArmadaPlatInitDxeEntryPoint
+
+[Sources]
+  PlatInitDxe.c
+
+[Packages]
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+  Platform/Marvell/Marvell.dec
+
+[LibraryClasses]
+  ComPhyLib
+  DebugLib
+  MppLib
+  PcdLib
+  TimerLib
+  UefiDriverEntryPoint
+  UtmiPhyLib
+
+[Protocols]
+  gMarvellPlatformInitCompleteProtocolGuid#

Re: [edk2] [platforms: PATCH v2 3/5] Marvell/Library: UtmiLib: Move devices description to MvHwDescLib

[Leif Lindholm]

On Mon, Oct 09, 2017 at 06:25:18PM +0200, Marcin Wojtas wrote:
> 2017-10-09 18:23 GMT+02:00 Leif Lindholm :
> > On Mon, Oct 09, 2017 at 06:06:53PM +0200, Marcin Wojtas wrote:
> >> 2017-10-09 18:00 GMT+02:00 Leif Lindholm :
> >> > On Sun, Oct 08, 2017 at 12:56:50PM +0200, Marcin Wojtas wrote:
> >> >> This patch introduces UTMI description, using the new structures
> >> >> and template in MvHwDescLib. This change enables more flexible
> >> >> addition of multiple CP with UTMI PHY's and also significantly
> >> >> reduces amount of used PCD's for that purpose. Update PortingGuide
> >> >> documentation accordingly.
> >> >>
> >> >> This patch replaces string-based description of Utmi on
> >> >> Armada 70x0 DB with new, reduced format, which uses macros
> >> >> in Armada.dsc.inc file for better readability.
> >> >>
> >> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> >> Signed-off-by: Marcin Wojtas 
> >> >> ---
> >> >>  Platform/Marvell/Armada/Armada.dsc.inc |   5 +
> >> >>  Platform/Marvell/Armada/Armada70x0.dsc |   7 +-
> >> >>  Platform/Marvell/Include/Library/MvHwDescLib.h |  47 ++
> >> >>  Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.c   | 150 
> >> >> ++--
> >> >>  Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.h   |   1 -
> >> >>  Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.inf |  11 +-
> >> >>  Platform/Marvell/Marvell.dec   |   7 +-
> >> >>  Silicon/Marvell/Documentation/PortingGuide.txt |  30 ++--
> >> >>  8 files changed, 148 insertions(+), 110 deletions(-)
> >> >>
> >
> >> > This indentation does not appear to follow any of the patterns
> >> > permitted by the coding style. Please address here and in the two
> >> > instances below (calls to UtmiPhyConfig and UtmiPhyPowerUp).
> >> >
> >> > No need to resubmit the whole series - just the single patch.
> >>
> >> Sure, will send right away.
> >
> > Thx.
> 
> Rebased patches are available here:
> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/parsepcd-upstream-r20171009

Thanks - for the series: Reviewed-by: Leif Lindholm 
Pushed as 7f0f07968b..a1b8b22b97

/
Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH v2 3/5] Marvell/Library: UtmiLib: Move devices description to MvHwDescLib

[Marcin Wojtas]

2017-10-09 18:23 GMT+02:00 Leif Lindholm :
> On Mon, Oct 09, 2017 at 06:06:53PM +0200, Marcin Wojtas wrote:
>> 2017-10-09 18:00 GMT+02:00 Leif Lindholm :
>> > On Sun, Oct 08, 2017 at 12:56:50PM +0200, Marcin Wojtas wrote:
>> >> This patch introduces UTMI description, using the new structures
>> >> and template in MvHwDescLib. This change enables more flexible
>> >> addition of multiple CP with UTMI PHY's and also significantly
>> >> reduces amount of used PCD's for that purpose. Update PortingGuide
>> >> documentation accordingly.
>> >>
>> >> This patch replaces string-based description of Utmi on
>> >> Armada 70x0 DB with new, reduced format, which uses macros
>> >> in Armada.dsc.inc file for better readability.
>> >>
>> >> Contributed-under: TianoCore Contribution Agreement 1.1
>> >> Signed-off-by: Marcin Wojtas 
>> >> ---
>> >>  Platform/Marvell/Armada/Armada.dsc.inc |   5 +
>> >>  Platform/Marvell/Armada/Armada70x0.dsc |   7 +-
>> >>  Platform/Marvell/Include/Library/MvHwDescLib.h |  47 ++
>> >>  Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.c   | 150 
>> >> ++--
>> >>  Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.h   |   1 -
>> >>  Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.inf |  11 +-
>> >>  Platform/Marvell/Marvell.dec   |   7 +-
>> >>  Silicon/Marvell/Documentation/PortingGuide.txt |  30 ++--
>> >>  8 files changed, 148 insertions(+), 110 deletions(-)
>> >>
>
>> > This indentation does not appear to follow any of the patterns
>> > permitted by the coding style. Please address here and in the two
>> > instances below (calls to UtmiPhyConfig and UtmiPhyPowerUp).
>> >
>> > No need to resubmit the whole series - just the single patch.
>>
>> Sure, will send right away.
>
> Thx.

Rebased patches are available here:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/parsepcd-upstream-r20171009

>
>> >>  Example
>> >>  ---
>> >>
>> >>   # UtmiPhy
>> >> -   gMarvellTokenSpaceGuid.PcdUtmiPhyCount|2
>> >> -   
>> >> gMarvellTokenSpaceGuid.PcdUtmiPhyRegUtmiUnit|L"0xF258;0xF2581000"
>> >> -   
>> >> gMarvellTokenSpaceGuid.PcdUtmiPhyRegUsbCfg|L"0xF2440420;0xF2440420"
>> >> -   
>> >> gMarvellTokenSpaceGuid.PcdUtmiPhyRegUtmiCfg|L"0xF2440440;0xF2440444"
>> >> -   gMarvellTokenSpaceGuid.PcdUtmiPhyUtmiPort|L"0x0;0x1"
>> >> +   gMarvellTokenSpaceGuid.PcdUtmiControllersEnabled|{ 0x1, 
>> >> 0x1 }
>> >> +   gMarvellTokenSpaceGuid.PcdUtmiPortType|{ 
>> >> $(UTMI_USB_HOST0), $(UTMI_USB_HOST1) }
>> >
>> > Actually, looking at this bit made me realise the PortingGuide.txt
>> > uses tab characters and uses \n line endings.
>> >
>> > This is not caused by this set, so does not need to be addressed as
>> > part of this series, but if you could follow up with a patch adjusting
>> > the formating of documentation, I would be grateful.
>> >
>> > This is also made painfully clear when running CheckPatch.py.
>> >
>>
>> Well, yes. It's in Sphinx acceptable format
>
> Apart from a massive structure in Egypt, what is a Sphinx?
>
>> and it is generated into
>> Marvell documentation along with all other projects. If I align it to
>> edk2 coding style, I'd have to maintain 2 copies of this file... If
>> you insist, I'll change it, but I would be very grateful for accepting
>> this one exception, if possible:) Please let know your decision
>> (looking at my branch, there won't be much updates of this file).
>
> Well, I don't see how we can keep a file that makes PatchCheck.py
> barf whenever we touch it. If you want to keep this format, please
> send a proposal to exclude files of this type from said checks by
> PatchCheck.py to edk2-devel.
>
> Is there a default "Sphinx source" file extension that can be used to
> describe this format, rather than changing the rule for anything
> called ".txt"? (If not, should we make one?)
>

Ok, never mind - I'll change it.

Thanks,
Marcin
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH v2 3/5] Marvell/Library: UtmiLib: Move devices description to MvHwDescLib

[Leif Lindholm]

On Mon, Oct 09, 2017 at 06:06:53PM +0200, Marcin Wojtas wrote:
> 2017-10-09 18:00 GMT+02:00 Leif Lindholm :
> > On Sun, Oct 08, 2017 at 12:56:50PM +0200, Marcin Wojtas wrote:
> >> This patch introduces UTMI description, using the new structures
> >> and template in MvHwDescLib. This change enables more flexible
> >> addition of multiple CP with UTMI PHY's and also significantly
> >> reduces amount of used PCD's for that purpose. Update PortingGuide
> >> documentation accordingly.
> >>
> >> This patch replaces string-based description of Utmi on
> >> Armada 70x0 DB with new, reduced format, which uses macros
> >> in Armada.dsc.inc file for better readability.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Marcin Wojtas 
> >> ---
> >>  Platform/Marvell/Armada/Armada.dsc.inc |   5 +
> >>  Platform/Marvell/Armada/Armada70x0.dsc |   7 +-
> >>  Platform/Marvell/Include/Library/MvHwDescLib.h |  47 ++
> >>  Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.c   | 150 
> >> ++--
> >>  Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.h   |   1 -
> >>  Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.inf |  11 +-
> >>  Platform/Marvell/Marvell.dec   |   7 +-
> >>  Silicon/Marvell/Documentation/PortingGuide.txt |  30 ++--
> >>  8 files changed, 148 insertions(+), 110 deletions(-)
> >>

> > This indentation does not appear to follow any of the patterns
> > permitted by the coding style. Please address here and in the two
> > instances below (calls to UtmiPhyConfig and UtmiPhyPowerUp).
> >
> > No need to resubmit the whole series - just the single patch.
> 
> Sure, will send right away.

Thx.

> >>  Example
> >>  ---
> >>
> >>   # UtmiPhy
> >> -   gMarvellTokenSpaceGuid.PcdUtmiPhyCount|2
> >> -   
> >> gMarvellTokenSpaceGuid.PcdUtmiPhyRegUtmiUnit|L"0xF258;0xF2581000"
> >> -   
> >> gMarvellTokenSpaceGuid.PcdUtmiPhyRegUsbCfg|L"0xF2440420;0xF2440420"
> >> -   
> >> gMarvellTokenSpaceGuid.PcdUtmiPhyRegUtmiCfg|L"0xF2440440;0xF2440444"
> >> -   gMarvellTokenSpaceGuid.PcdUtmiPhyUtmiPort|L"0x0;0x1"
> >> +   gMarvellTokenSpaceGuid.PcdUtmiControllersEnabled|{ 0x1, 
> >> 0x1 }
> >> +   gMarvellTokenSpaceGuid.PcdUtmiPortType|{ 
> >> $(UTMI_USB_HOST0), $(UTMI_USB_HOST1) }
> >
> > Actually, looking at this bit made me realise the PortingGuide.txt
> > uses tab characters and uses \n line endings.
> >
> > This is not caused by this set, so does not need to be addressed as
> > part of this series, but if you could follow up with a patch adjusting
> > the formating of documentation, I would be grateful.
> >
> > This is also made painfully clear when running CheckPatch.py.
> >
> 
> Well, yes. It's in Sphinx acceptable format

Apart from a massive structure in Egypt, what is a Sphinx?

> and it is generated into
> Marvell documentation along with all other projects. If I align it to
> edk2 coding style, I'd have to maintain 2 copies of this file... If
> you insist, I'll change it, but I would be very grateful for accepting
> this one exception, if possible:) Please let know your decision
> (looking at my branch, there won't be much updates of this file).

Well, I don't see how we can keep a file that makes PatchCheck.py
barf whenever we touch it. If you want to keep this format, please
send a proposal to exclude files of this type from said checks by
PatchCheck.py to edk2-devel.

Is there a default "Sphinx source" file extension that can be used to
describe this format, rather than changing the rule for anything
called ".txt"? (If not, should we make one?)

/
Leif
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [platforms: PATCH v3 3/5] Marvell/Library: UtmiLib: Move devices description to MvHwDescLib

[Marcin Wojtas]

This patch introduces UTMI description, using the new structures
and template in MvHwDescLib. This change enables more flexible
addition of multiple CP with UTMI PHY's and also significantly
reduces amount of used PCD's for that purpose. Update PortingGuide
documentation accordingly.

This patch replaces string-based description of Utmi on
Armada 70x0 DB with new, reduced format, which uses macros
in Armada.dsc.inc file for better readability.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada/Armada.dsc.inc |   5 +
 Platform/Marvell/Armada/Armada70x0.dsc |   7 +-
 Platform/Marvell/Include/Library/MvHwDescLib.h |  47 +++
 Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.c   | 143 ++--
 Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.h   |   1 -
 Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.inf |  11 +-
 Platform/Marvell/Marvell.dec   |   7 +-
 Silicon/Marvell/Documentation/PortingGuide.txt |  30 ++--
 8 files changed, 142 insertions(+), 109 deletions(-)

diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
b/Platform/Marvell/Armada/Armada.dsc.inc
index cd26506..7d0dc39 100644
--- a/Platform/Marvell/Armada/Armada.dsc.inc
+++ b/Platform/Marvell/Armada/Armada.dsc.inc
@@ -523,3 +523,8 @@
   DEFINE CP_RXAUI0  = 0x15
   DEFINE CP_RXAUI1  = 0x16
   DEFINE CP_SFI = 0x17
+
+  #UTMI PHY connection type
+  DEFINE UTMI_USB_HOST0 = 0x0
+  DEFINE UTMI_USB_HOST1 = 0x1
+  DEFINE UTMI_USB_DEVICE0   = 0x2
diff --git a/Platform/Marvell/Armada/Armada70x0.dsc 
b/Platform/Marvell/Armada/Armada70x0.dsc
index c11a973..b40766b 100644
--- a/Platform/Marvell/Armada/Armada70x0.dsc
+++ b/Platform/Marvell/Armada/Armada70x0.dsc
@@ -111,11 +111,8 @@
   gMarvellTokenSpaceGuid.PcdChip0ComPhySpeeds|{ $(CP_1_25G), $(CP_5G), 
$(CP_10_3125G), $(CP_5G), $(CP_5G), $(CP_5G) }
 
   #UtmiPhy
-  gMarvellTokenSpaceGuid.PcdUtmiPhyCount|2
-  gMarvellTokenSpaceGuid.PcdUtmiPhyRegUsbCfg|L"0xF2440420;0xF2440420"
-  gMarvellTokenSpaceGuid.PcdUtmiPhyRegUtmiCfg|L"0xF2440440;0xF2440444"
-  gMarvellTokenSpaceGuid.PcdUtmiPhyRegUtmiUnit|L"0xF258;0xF2581000"
-  gMarvellTokenSpaceGuid.PcdUtmiPhyUtmiPort|L"0x0;0x1"
+  gMarvellTokenSpaceGuid.PcdUtmiControllersEnabled|{ 0x1, 0x1 }
+  gMarvellTokenSpaceGuid.PcdUtmiPortType|{ $(UTMI_USB_HOST0), 
$(UTMI_USB_HOST1) }
 
   #MDIO
   gMarvellTokenSpaceGuid.PcdMdioBaseAddress|0xF212A200
diff --git a/Platform/Marvell/Include/Library/MvHwDescLib.h 
b/Platform/Marvell/Include/Library/MvHwDescLib.h
index e029b50..6ad1bc2 100644
--- a/Platform/Marvell/Include/Library/MvHwDescLib.h
+++ b/Platform/Marvell/Include/Library/MvHwDescLib.h
@@ -117,6 +117,19 @@ typedef struct {
 } MVHW_RTC_DESC;
 
 //
+// UTMI PHY's description template definition
+//
+
+typedef struct {
+  UINT8 UtmiDevCount;
+  UINT32 UtmiPhyId[MVHW_MAX_XHCI_DEVS];
+  UINTN UtmiBaseAddresses[MVHW_MAX_XHCI_DEVS];
+  UINTN UtmiConfigAddresses[MVHW_MAX_XHCI_DEVS];
+  UINTN UtmiUsbConfigAddresses[MVHW_MAX_XHCI_DEVS];
+  UINTN UtmiMuxBitCount[MVHW_MAX_XHCI_DEVS];
+} MVHW_UTMI_DESC;
+
+//
 // Platform description of CommonPhy devices
 //
 #define MVHW_CP0_COMPHY_BASE   0xF2441000
@@ -217,4 +230,38 @@ MVHW_RTC_DESC mA7k8kRtcDescTemplate = {\
   { SIZE_4KB, SIZE_4KB }\
 }
 
+//
+// Platform description of UTMI PHY's
+//
+#define MVHW_CP0_UTMI0_BASE0xF258
+#define MVHW_CP0_UTMI0_CFG_BASE0xF2440440
+#define MVHW_CP0_UTMI0_USB_CFG_BASE0xF2440420
+#define MVHW_CP0_UTMI0_ID  0x0
+#define MVHW_CP0_UTMI1_BASE0xF2581000
+#define MVHW_CP0_UTMI1_CFG_BASE0xF2440444
+#define MVHW_CP0_UTMI1_USB_CFG_BASE0xF2440420
+#define MVHW_CP0_UTMI1_ID  0x1
+#define MVHW_CP1_UTMI0_BASE0xF458
+#define MVHW_CP1_UTMI0_CFG_BASE0xF4440440
+#define MVHW_CP1_UTMI0_USB_CFG_BASE0xF4440420
+#define MVHW_CP1_UTMI0_ID  0x0
+#define MVHW_CP1_UTMI1_BASE0xF4581000
+#define MVHW_CP1_UTMI1_CFG_BASE0xF4440444
+#define MVHW_CP1_UTMI1_USB_CFG_BASE0xF4440420
+#define MVHW_CP1_UTMI1_ID  0x1
+
+#define DECLARE_A7K8K_UTMI_TEMPLATE \
+STATIC \
+MVHW_UTMI_DESC mA7k8kUtmiDescTemplate = {\
+  4,\
+  { MVHW_CP0_UTMI0_ID, MVHW_CP0_UTMI1_ID,\
+MVHW_CP1_UTMI0_ID, MVHW_CP1_UTMI1_ID },\
+  { MVHW_CP0_UTMI0_BASE, MVHW_CP0_UTMI1_BASE,\
+MVHW_CP1_UTMI0_BASE, MVHW_CP1_UTMI1_BASE },\
+  { MVHW_CP0_UTMI0_CFG_BASE, MVHW_CP0_UTMI1_CFG_BASE,\
+MVHW_CP1_UTMI0_CFG_BASE, MVHW_CP1_UTMI1_CFG_BASE },\
+  { MVHW_CP0_UTMI0_USB_CFG_BASE, MVHW_CP0_UTMI1_USB_CFG_BASE,\
+MVHW_CP1_UTMI0_USB_CFG_BASE, MVHW_CP1_UTMI1_USB_CFG_BASE }\
+}
+
 #endif /* __MVHWDESCLIB_H__ */
diff --git a/Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.c 
b/Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.c
index 95b5698..2cd9cfa 100644
--- a/Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.c
+++ b/Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.c

Re: [edk2] [platforms: PATCH v2 3/5] Marvell/Library: UtmiLib: Move devices description to MvHwDescLib

[Marcin Wojtas]

2017-10-09 18:00 GMT+02:00 Leif Lindholm :
> On Sun, Oct 08, 2017 at 12:56:50PM +0200, Marcin Wojtas wrote:
>> This patch introduces UTMI description, using the new structures
>> and template in MvHwDescLib. This change enables more flexible
>> addition of multiple CP with UTMI PHY's and also significantly
>> reduces amount of used PCD's for that purpose. Update PortingGuide
>> documentation accordingly.
>>
>> This patch replaces string-based description of Utmi on
>> Armada 70x0 DB with new, reduced format, which uses macros
>> in Armada.dsc.inc file for better readability.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Marcin Wojtas 
>> ---
>>  Platform/Marvell/Armada/Armada.dsc.inc |   5 +
>>  Platform/Marvell/Armada/Armada70x0.dsc |   7 +-
>>  Platform/Marvell/Include/Library/MvHwDescLib.h |  47 ++
>>  Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.c   | 150 
>> ++--
>>  Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.h   |   1 -
>>  Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.inf |  11 +-
>>  Platform/Marvell/Marvell.dec   |   7 +-
>>  Silicon/Marvell/Documentation/PortingGuide.txt |  30 ++--
>>  8 files changed, 148 insertions(+), 110 deletions(-)
>>
>> diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
>> b/Platform/Marvell/Armada/Armada.dsc.inc
>> index cd26506..7d0dc39 100644
>> --- a/Platform/Marvell/Armada/Armada.dsc.inc
>> +++ b/Platform/Marvell/Armada/Armada.dsc.inc
>> @@ -523,3 +523,8 @@
>>DEFINE CP_RXAUI0  = 0x15
>>DEFINE CP_RXAUI1  = 0x16
>>DEFINE CP_SFI = 0x17
>> +
>> +  #UTMI PHY connection type
>> +  DEFINE UTMI_USB_HOST0 = 0x0
>> +  DEFINE UTMI_USB_HOST1 = 0x1
>> +  DEFINE UTMI_USB_DEVICE0   = 0x2
>> diff --git a/Platform/Marvell/Armada/Armada70x0.dsc 
>> b/Platform/Marvell/Armada/Armada70x0.dsc
>> index c11a973..b40766b 100644
>> --- a/Platform/Marvell/Armada/Armada70x0.dsc
>> +++ b/Platform/Marvell/Armada/Armada70x0.dsc
>> @@ -111,11 +111,8 @@
>>gMarvellTokenSpaceGuid.PcdChip0ComPhySpeeds|{ $(CP_1_25G), $(CP_5G), 
>> $(CP_10_3125G), $(CP_5G), $(CP_5G), $(CP_5G) }
>>
>>#UtmiPhy
>> -  gMarvellTokenSpaceGuid.PcdUtmiPhyCount|2
>> -  gMarvellTokenSpaceGuid.PcdUtmiPhyRegUsbCfg|L"0xF2440420;0xF2440420"
>> -  gMarvellTokenSpaceGuid.PcdUtmiPhyRegUtmiCfg|L"0xF2440440;0xF2440444"
>> -  gMarvellTokenSpaceGuid.PcdUtmiPhyRegUtmiUnit|L"0xF258;0xF2581000"
>> -  gMarvellTokenSpaceGuid.PcdUtmiPhyUtmiPort|L"0x0;0x1"
>> +  gMarvellTokenSpaceGuid.PcdUtmiControllersEnabled|{ 0x1, 0x1 }
>> +  gMarvellTokenSpaceGuid.PcdUtmiPortType|{ $(UTMI_USB_HOST0), 
>> $(UTMI_USB_HOST1) }
>>
>>#MDIO
>>gMarvellTokenSpaceGuid.PcdMdioBaseAddress|0xF212A200
>> diff --git a/Platform/Marvell/Include/Library/MvHwDescLib.h 
>> b/Platform/Marvell/Include/Library/MvHwDescLib.h
>> index e029b50..6ad1bc2 100644
>> --- a/Platform/Marvell/Include/Library/MvHwDescLib.h
>> +++ b/Platform/Marvell/Include/Library/MvHwDescLib.h
>> @@ -117,6 +117,19 @@ typedef struct {
>>  } MVHW_RTC_DESC;
>>
>>  //
>> +// UTMI PHY's description template definition
>> +//
>> +
>> +typedef struct {
>> +  UINT8 UtmiDevCount;
>> +  UINT32 UtmiPhyId[MVHW_MAX_XHCI_DEVS];
>> +  UINTN UtmiBaseAddresses[MVHW_MAX_XHCI_DEVS];
>> +  UINTN UtmiConfigAddresses[MVHW_MAX_XHCI_DEVS];
>> +  UINTN UtmiUsbConfigAddresses[MVHW_MAX_XHCI_DEVS];
>> +  UINTN UtmiMuxBitCount[MVHW_MAX_XHCI_DEVS];
>> +} MVHW_UTMI_DESC;
>> +
>> +//
>>  // Platform description of CommonPhy devices
>>  //
>>  #define MVHW_CP0_COMPHY_BASE   0xF2441000
>> @@ -217,4 +230,38 @@ MVHW_RTC_DESC mA7k8kRtcDescTemplate = {\
>>{ SIZE_4KB, SIZE_4KB }\
>>  }
>>
>> +//
>> +// Platform description of UTMI PHY's
>> +//
>> +#define MVHW_CP0_UTMI0_BASE0xF258
>> +#define MVHW_CP0_UTMI0_CFG_BASE0xF2440440
>> +#define MVHW_CP0_UTMI0_USB_CFG_BASE0xF2440420
>> +#define MVHW_CP0_UTMI0_ID  0x0
>> +#define MVHW_CP0_UTMI1_BASE0xF2581000
>> +#define MVHW_CP0_UTMI1_CFG_BASE0xF2440444
>> +#define MVHW_CP0_UTMI1_USB_CFG_BASE0xF2440420
>> +#define MVHW_CP0_UTMI1_ID  0x1
>> +#define MVHW_CP1_UTMI0_BASE0xF458
>> +#define MVHW_CP1_UTMI0_CFG_BASE0xF4440440
>> +#define MVHW_CP1_UTMI0_USB_CFG_BASE0xF4440420
>> +#define MVHW_CP1_UTMI0_ID  0x0
>> +#define MVHW_CP1_UTMI1_BASE0xF4581000
>> +#define MVHW_CP1_UTMI1_CFG_BASE0xF4440444
>> +#define MVHW_CP1_UTMI1_USB_CFG_BASE0xF4440420
>> +#define MVHW_CP1_UTMI1_ID  0x1
>> +
>> +#define DECLARE_A7K8K_UTMI_TEMPLATE \
>> +STATIC \
>> +MVHW_UTMI_DESC mA7k8kUtmiDescTemplate = {\
>> +  4,\
>> +  { MVHW_CP0_UTMI0_ID, MVHW_CP0_UTMI1_ID,\
>> +MVHW_CP1_UTMI0_ID, MVHW_CP1_UTMI1_ID },\
>> +  { MVHW_CP0_UTMI0_BASE, MVHW_CP0_UTMI1_BASE,\
>> +MVHW_CP1_UTMI0_BASE, MVHW_CP1_UTMI1_BASE },\
>> +  { MVHW_CP0_UTMI0_CFG_BASE, MVHW_CP0_UTMI1_CFG_BASE,\
>> +MVHW_CP1_UTMI0_CFG_BAS

Re: [edk2] [platforms: PATCH v2 3/5] Marvell/Library: UtmiLib: Move devices description to MvHwDescLib

[Leif Lindholm]

On Sun, Oct 08, 2017 at 12:56:50PM +0200, Marcin Wojtas wrote:
> This patch introduces UTMI description, using the new structures
> and template in MvHwDescLib. This change enables more flexible
> addition of multiple CP with UTMI PHY's and also significantly
> reduces amount of used PCD's for that purpose. Update PortingGuide
> documentation accordingly.
> 
> This patch replaces string-based description of Utmi on
> Armada 70x0 DB with new, reduced format, which uses macros
> in Armada.dsc.inc file for better readability.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Armada/Armada.dsc.inc |   5 +
>  Platform/Marvell/Armada/Armada70x0.dsc |   7 +-
>  Platform/Marvell/Include/Library/MvHwDescLib.h |  47 ++
>  Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.c   | 150 ++--
>  Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.h   |   1 -
>  Platform/Marvell/Library/UtmiPhyLib/UtmiPhyLib.inf |  11 +-
>  Platform/Marvell/Marvell.dec   |   7 +-
>  Silicon/Marvell/Documentation/PortingGuide.txt |  30 ++--
>  8 files changed, 148 insertions(+), 110 deletions(-)
> 
> diff --git a/Platform/Marvell/Armada/Armada.dsc.inc 
> b/Platform/Marvell/Armada/Armada.dsc.inc
> index cd26506..7d0dc39 100644
> --- a/Platform/Marvell/Armada/Armada.dsc.inc
> +++ b/Platform/Marvell/Armada/Armada.dsc.inc
> @@ -523,3 +523,8 @@
>DEFINE CP_RXAUI0  = 0x15
>DEFINE CP_RXAUI1  = 0x16
>DEFINE CP_SFI = 0x17
> +
> +  #UTMI PHY connection type
> +  DEFINE UTMI_USB_HOST0 = 0x0
> +  DEFINE UTMI_USB_HOST1 = 0x1
> +  DEFINE UTMI_USB_DEVICE0   = 0x2
> diff --git a/Platform/Marvell/Armada/Armada70x0.dsc 
> b/Platform/Marvell/Armada/Armada70x0.dsc
> index c11a973..b40766b 100644
> --- a/Platform/Marvell/Armada/Armada70x0.dsc
> +++ b/Platform/Marvell/Armada/Armada70x0.dsc
> @@ -111,11 +111,8 @@
>gMarvellTokenSpaceGuid.PcdChip0ComPhySpeeds|{ $(CP_1_25G), $(CP_5G), 
> $(CP_10_3125G), $(CP_5G), $(CP_5G), $(CP_5G) }
>  
>#UtmiPhy
> -  gMarvellTokenSpaceGuid.PcdUtmiPhyCount|2
> -  gMarvellTokenSpaceGuid.PcdUtmiPhyRegUsbCfg|L"0xF2440420;0xF2440420"
> -  gMarvellTokenSpaceGuid.PcdUtmiPhyRegUtmiCfg|L"0xF2440440;0xF2440444"
> -  gMarvellTokenSpaceGuid.PcdUtmiPhyRegUtmiUnit|L"0xF258;0xF2581000"
> -  gMarvellTokenSpaceGuid.PcdUtmiPhyUtmiPort|L"0x0;0x1"
> +  gMarvellTokenSpaceGuid.PcdUtmiControllersEnabled|{ 0x1, 0x1 }
> +  gMarvellTokenSpaceGuid.PcdUtmiPortType|{ $(UTMI_USB_HOST0), 
> $(UTMI_USB_HOST1) }
>  
>#MDIO
>gMarvellTokenSpaceGuid.PcdMdioBaseAddress|0xF212A200
> diff --git a/Platform/Marvell/Include/Library/MvHwDescLib.h 
> b/Platform/Marvell/Include/Library/MvHwDescLib.h
> index e029b50..6ad1bc2 100644
> --- a/Platform/Marvell/Include/Library/MvHwDescLib.h
> +++ b/Platform/Marvell/Include/Library/MvHwDescLib.h
> @@ -117,6 +117,19 @@ typedef struct {
>  } MVHW_RTC_DESC;
>  
>  //
> +// UTMI PHY's description template definition
> +//
> +
> +typedef struct {
> +  UINT8 UtmiDevCount;
> +  UINT32 UtmiPhyId[MVHW_MAX_XHCI_DEVS];
> +  UINTN UtmiBaseAddresses[MVHW_MAX_XHCI_DEVS];
> +  UINTN UtmiConfigAddresses[MVHW_MAX_XHCI_DEVS];
> +  UINTN UtmiUsbConfigAddresses[MVHW_MAX_XHCI_DEVS];
> +  UINTN UtmiMuxBitCount[MVHW_MAX_XHCI_DEVS];
> +} MVHW_UTMI_DESC;
> +
> +//
>  // Platform description of CommonPhy devices
>  //
>  #define MVHW_CP0_COMPHY_BASE   0xF2441000
> @@ -217,4 +230,38 @@ MVHW_RTC_DESC mA7k8kRtcDescTemplate = {\
>{ SIZE_4KB, SIZE_4KB }\
>  }
>  
> +//
> +// Platform description of UTMI PHY's
> +//
> +#define MVHW_CP0_UTMI0_BASE0xF258
> +#define MVHW_CP0_UTMI0_CFG_BASE0xF2440440
> +#define MVHW_CP0_UTMI0_USB_CFG_BASE0xF2440420
> +#define MVHW_CP0_UTMI0_ID  0x0
> +#define MVHW_CP0_UTMI1_BASE0xF2581000
> +#define MVHW_CP0_UTMI1_CFG_BASE0xF2440444
> +#define MVHW_CP0_UTMI1_USB_CFG_BASE0xF2440420
> +#define MVHW_CP0_UTMI1_ID  0x1
> +#define MVHW_CP1_UTMI0_BASE0xF458
> +#define MVHW_CP1_UTMI0_CFG_BASE0xF4440440
> +#define MVHW_CP1_UTMI0_USB_CFG_BASE0xF4440420
> +#define MVHW_CP1_UTMI0_ID  0x0
> +#define MVHW_CP1_UTMI1_BASE0xF4581000
> +#define MVHW_CP1_UTMI1_CFG_BASE0xF4440444
> +#define MVHW_CP1_UTMI1_USB_CFG_BASE0xF4440420
> +#define MVHW_CP1_UTMI1_ID  0x1
> +
> +#define DECLARE_A7K8K_UTMI_TEMPLATE \
> +STATIC \
> +MVHW_UTMI_DESC mA7k8kUtmiDescTemplate = {\
> +  4,\
> +  { MVHW_CP0_UTMI0_ID, MVHW_CP0_UTMI1_ID,\
> +MVHW_CP1_UTMI0_ID, MVHW_CP1_UTMI1_ID },\
> +  { MVHW_CP0_UTMI0_BASE, MVHW_CP0_UTMI1_BASE,\
> +MVHW_CP1_UTMI0_BASE, MVHW_CP1_UTMI1_BASE },\
> +  { MVHW_CP0_UTMI0_CFG_BASE, MVHW_CP0_UTMI1_CFG_BASE,\
> +MVHW_CP1_UTMI0_CFG_BASE, MVHW_CP1_UTMI1_CFG_BASE },\
> +  { MVHW_CP0_UTMI0_USB_CFG_BASE, MVHW_CP0_UTMI1_USB_CFG_BASE,\
> +MVHW_CP1_UTMI0_USB_CFG_BASE, MVHW_CP1_UTMI1_USB_CFG

Re: [edk2] [PATCH v4 6/6] OvmfPkg/QemuVideoDxe: Bypass NULL pointer detection during VBE SHIM installing

[Laszlo Ersek]

On 10/09/17 17:54, Laszlo Ersek wrote:
> On 10/09/17 16:17, Jian J Wang wrote:
>> QemuVideoDxe driver will link VBE SHIM into page 0. If NULL pointer
>> detection is enabled, this driver will fail to load. NULL pointer detection
>> bypassing code is added to prevent such problem during boot.
>>
>> Please note that Windows 7 will try to access VBE SHIM during boot if it's
>> installed, and then cause boot failure. This can be fixed by setting BIT7
>> of PcdNullPointerDetectionPropertyMask to disable NULL pointer detection
>> after EndOfDxe. As far as we know, there's no other OSs has such issue.
>>
>> Cc: Star Zeng 
>> Cc: Eric Dong 
>> Cc: Jiewen Yao 
>> Cc: Michael Kinney 
>> Cc: Ayellet Wolman 
>> Suggested-by: Ayellet Wolman 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Jian J Wang 
>> ---
>>  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf |  1 +
>>  OvmfPkg/QemuVideoDxe/VbeShim.c| 14 ++
>>  2 files changed, 15 insertions(+)
>>
>> diff --git a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf 
>> b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
>> index 577e07b0a8..ff68c99e96 100644
>> --- a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
>> +++ b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
>> @@ -77,3 +77,4 @@
>>  [Pcd]
>>gOptionRomPkgTokenSpaceGuid.PcdDriverSupportedEfiVersion
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
>> +  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask
>> diff --git a/OvmfPkg/QemuVideoDxe/VbeShim.c b/OvmfPkg/QemuVideoDxe/VbeShim.c
>> index e45a08e887..8ba5522cde 100644
>> --- a/OvmfPkg/QemuVideoDxe/VbeShim.c
>> +++ b/OvmfPkg/QemuVideoDxe/VbeShim.c
>> @@ -75,6 +75,20 @@ InstallVbeShim (
>>UINTNPrinted;
>>VBE_MODE_INFO*VbeModeInfo;
>>  
>> +  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & (BIT0|BIT7)) == 
>> BIT0) {
>> +DEBUG ((
>> +  DEBUG_WARN,
>> +  "%a: page 0 protected, not installing VBE shim\n",
>> +  __FUNCTION__
>> +  ));
>> +DEBUG ((
>> +  DEBUG_WARN,
>> +  "%a: page 0 protection prevents Windows 7 from booting anyway\n",
>> +  __FUNCTION__
>> +  ));
>> +return;
>> +  }
>> +
>>Segment0 = 0x0;
>>SegmentC = 0xC;
>>SegmentF = 0xF;
>>
> 
> If this patch is entirely identical to the previous version (v3), then
> you should have please picked up the review tags from Jordan and myself,
> the ones that you got for v3:
> 
> http://mid.mail-archive.com/150696711831.2454.16712170525103415248@jljusten-skl
> 
> d1a20be5-8dbf-8ce6-1738-d03b330047cc@redhat.com">http://mid.mail-archive.com/d1a20be5-8dbf-8ce6-1738-d03b330047cc@redhat.com
> 
> This way we can quickly filter out already reviewed patches, and avoid
> re-reviewing when there are no changes.
> 
> 
> Your cover letter v4 0/6 also does not summarize the changes relative to
> v3; in the future please don't forget about that.

... personal CC's for OvmfPkg maintainers and reviewers are also missing
from this patch. Please check "Maintainers.txt" every time.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v4 6/6] OvmfPkg/QemuVideoDxe: Bypass NULL pointer detection during VBE SHIM installing

[Laszlo Ersek]

On 10/09/17 16:17, Jian J Wang wrote:
> QemuVideoDxe driver will link VBE SHIM into page 0. If NULL pointer
> detection is enabled, this driver will fail to load. NULL pointer detection
> bypassing code is added to prevent such problem during boot.
> 
> Please note that Windows 7 will try to access VBE SHIM during boot if it's
> installed, and then cause boot failure. This can be fixed by setting BIT7
> of PcdNullPointerDetectionPropertyMask to disable NULL pointer detection
> after EndOfDxe. As far as we know, there's no other OSs has such issue.
> 
> Cc: Star Zeng 
> Cc: Eric Dong 
> Cc: Jiewen Yao 
> Cc: Michael Kinney 
> Cc: Ayellet Wolman 
> Suggested-by: Ayellet Wolman 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf |  1 +
>  OvmfPkg/QemuVideoDxe/VbeShim.c| 14 ++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf 
> b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> index 577e07b0a8..ff68c99e96 100644
> --- a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> +++ b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
> @@ -77,3 +77,4 @@
>  [Pcd]
>gOptionRomPkgTokenSpaceGuid.PcdDriverSupportedEfiVersion
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask
> diff --git a/OvmfPkg/QemuVideoDxe/VbeShim.c b/OvmfPkg/QemuVideoDxe/VbeShim.c
> index e45a08e887..8ba5522cde 100644
> --- a/OvmfPkg/QemuVideoDxe/VbeShim.c
> +++ b/OvmfPkg/QemuVideoDxe/VbeShim.c
> @@ -75,6 +75,20 @@ InstallVbeShim (
>UINTNPrinted;
>VBE_MODE_INFO*VbeModeInfo;
>  
> +  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & (BIT0|BIT7)) == BIT0) 
> {
> +DEBUG ((
> +  DEBUG_WARN,
> +  "%a: page 0 protected, not installing VBE shim\n",
> +  __FUNCTION__
> +  ));
> +DEBUG ((
> +  DEBUG_WARN,
> +  "%a: page 0 protection prevents Windows 7 from booting anyway\n",
> +  __FUNCTION__
> +  ));
> +return;
> +  }
> +
>Segment0 = 0x0;
>SegmentC = 0xC;
>SegmentF = 0xF;
> 

If this patch is entirely identical to the previous version (v3), then
you should have please picked up the review tags from Jordan and myself,
the ones that you got for v3:

http://mid.mail-archive.com/150696711831.2454.16712170525103415248@jljusten-skl

d1a20be5-8dbf-8ce6-1738-d03b330047cc@redhat.com">http://mid.mail-archive.com/d1a20be5-8dbf-8ce6-1738-d03b330047cc@redhat.com

This way we can quickly filter out already reviewed patches, and avoid
re-reviewing when there are no changes.


Your cover letter v4 0/6 also does not summarize the changes relative to
v3; in the future please don't forget about that.

Thanks
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and lock OS-created MOR variable

[Laszlo Ersek]

On 10/09/17 09:12, Zeng, Star wrote:
> Laszlo,
> 
> Do you think VariableRuntimeDxe(TcgMorLockDxe.c) also needs to delete and 
> lock OS-created MOR variable?

Maybe -- I'm not sure.

If an edk2 platform uses "VariableRuntimeDxe", then it cannot securely
support MorLock, that's for sure. However, the same platform might still
support plain MOR.

How can we determine if the platform wants to support MOR? Should we
again look for the presence of the TCG / TCG2 protocols? I cannot tell
if TcgMor.inf, and other modules under SecurityPkg, intend to support a
"no-SMM" configuration.

So I can only give you a conditional answer:

(a) If an edk2 platform can *never* sensibly support plain MOR without
SMM, then yes, we should delete and lock the MOR variable in
"TcgMorLockDxe.c", function MorLockInit().

(b) If an edk2 platform *may* opt to support plain MOR (but not MorLock)
without SMM, then we should apply the same End-of-Dxe trick as in the
SMM case. This is however quite a bit of development and I suggest that
we postpone it -- file a BZ about it -- until an edk2 platform actually
needs this. (It looks like a quite unlikely use case though: MOR is a
security feature that is not really secure without MorLock, and MorLock
is insecure without SMM. So one might reason that MOR-without-SMM is
useless.)

(c) We can also say "we don't care", because, technically speaking, no
inconsistency between the MOR and MorLock variables can be created in
the "no-SMM" case (because it is never possible to create MorLock
without MOR -- since creating MorLock is prevented already).

So, I don't know. If Jiewen thinks that "MOR without SMM" is useless
(because it is inherently insecure --> option (a)), I can append a small
patch #7, in order to delete and lock MOR too, in MorLockInit()
[TcgMorLockDxe.c].


Here's another idea: if the "no SMM" case requires extra thinking and
regression testing (i.e. the patch would be more complex than simple MOR
deletion + locking) , can we go ahead with this series for now, and file
a TianoCore BZ about the "no SMM" case? (I should say in advance that
I'm not volunteering to address the "no SMM" Bugzilla any time soon; I
don't know much (yet) about the TCG modules in SecurityPkg, and I think
I won't have time for the investigation in the next weeks.)

Jiewen, what do you say?

Thanks!
Laszlo

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com] 
> Sent: Wednesday, October 4, 2017 5:29 AM
> To: edk2-devel-01 
> Cc: Dong, Eric ; Yao, Jiewen ; 
> Ladi Prosek ; Zeng, Star 
> Subject: [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and lock 
> OS-created MOR variable
> 
> According to the TCG Platform Reset Attack Mitigation Specification (May 15, 
> 2008):
> 
>> 5 Interface for UEFI
>> 5.1 UEFI Variable
>> 5.1.1 The MemoryOverwriteRequestControl
>>
>> Start of informative comment:
>>
>> [...] The OS loader should not create the variable. Rather, the 
>> firmware is required to create it and must support the semantics described 
>> here.
>>
>> End of informative comment.
> 
> However, some OS kernels create the MOR variable even if the platform 
> firmware does not support it (see one Bugzilla reference below). This OS 
> issue breaks the logic added in the last patch.
> 
> Strengthen the MOR check by searching for the TCG or TCG2 protocols, as 
> edk2's implementation of MOR depends on (one of) those protocols.
> 
> The protocols are defined under MdePkg, thus there's no inter-package 
> dependency issue. In addition, calling UEFI services in
> MorLockInitAtEndOfDxe() is safe, due to the following order of events /
> actions:
> 
> - platform BDS signals the EndOfDxe event group,
> - the SMM core installs the SmmEndOfDxe protocol,
> - MorLockInitAtEndOfDxe() is invoked, and it calls UEFI services,
> - some time later, platform BDS installs the DxeSmmReadyToLock protocol,
> - SMM / SMRAM is locked down and UEFI services become unavailable to SMM
>   drivers.
> 
> Cc: Eric Dong 
> Cc: Jiewen Yao 
> Cc: Ladi Prosek 
> Cc: Star Zeng 
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1498159
> Suggested-by: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 
> ---
>  MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf |  3 +  
> MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c | 81 
> ++--
>  2 files changed, 77 insertions(+), 7 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf 
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> index 404164366579..69966f0d37ee 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
> @@ -74,6 +74,7 @@ [LibraryClasses]
>SmmMemLib
>AuthVariableLib
>VarCheckLib
> +  UefiBootServicesTableLib
>  
>  [Protocols]
>gEfiSmmFirmwareVolumeBlockProtocolGuid## CONSUMES
> @@ -85,6 +86,8 @@ [Protocols]
>gEfiSmmVa

Re: [edk2] [PATCH v2 1/2] ArmPkg/Include: Add standard SMC function IDs for MM interface.

[Supreeth Venkatesh]

I can do that.
However, "-4" is missing in the specification. Is there a chance to rectify 
specification to add "-4", so that I can do both the defines.

Thanks,
Supreeth
-Original Message-
From: Achin Gupta
Sent: Monday, October 9, 2017 3:52 AM
To: Ard Biesheuvel ; Supreeth Venkatesh 

Cc: Supreeth Venkatesh ; edk2-devel@lists.01.org; 
Leif Lindholm ; nd 
Subject: Re: [PATCH v2 1/2] ArmPkg/Include: Add standard SMC function IDs for 
MM interface.

Hi Ard/Supreeth,

On Fri, Oct 06, 2017 at 10:05:46PM +0100, Ard Biesheuvel wrote:
> On 27 September 2017 at 19:58, Supreeth Venkatesh
>  wrote:
> > This patch adds a list of function IDs that fall under the standard
> > SMC range as defined in
> > http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf.
> >
> > SMCs associated with Management Mode are in the range 0xC440 -
> > 0xC45f (64 bit) and 0x8440 - 0x845f (32 bit).
> >
> > The function(s) available to the normal world:
> > 1. Request services from the secure MM environment using MM_COMMUNICATE.
> >
> > It also defines MM return codes.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Achin Gupta 
> > Signed-off-by: Supreeth Venkatesh 
>
> Both patches applied. Thanks.

I should have spotted this earlier but the following define is not spec. 
compliant. It says:

> +#define ARM_SMC_MM_RET_NO_MEMORY   -4

but should be

> +#define ARM_SMC_MM_RET_NO_MEMORY   -5

Supreeth. Could you please submit a patch to rectify this?

cheers,
Achin

>
> > ---
> >  ArmPkg/Include/IndustryStandard/ArmStdSmc.h | 20
> > +++-
> >  1 file changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> > b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> > index 593a3ce729..37d0796649 100644
> > --- a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> > +++ b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> > @@ -1,6 +1,6 @@
> >  /** @file
> >  *
> > -*  Copyright (c) 2012-2014, ARM Limited. All rights reserved.
> > +*  Copyright (c) 2012-2017, ARM Limited. All rights reserved.
> >  *
> >  *  This program and the accompanying materials
> >  *  are licensed and made available under the terms and conditions
> > of the BSD License @@ -40,6 +40,24 @@
> >  #define ARM_SMC_STD_REVISION_MAJOR0x0
> >  #define ARM_SMC_STD_REVISION_MINOR0x1
> >
> > +/*
> > + * Management Mode (MM) calls cover a subset of the Standard Service Call 
> > range.
> > + * The list below is not exhaustive.
> > + */
> > +#define ARM_SMC_ID_MM_VERSION_AARCH32  0x8440
> > +#define ARM_SMC_ID_MM_VERSION_AARCH64  0xC440
> > +
> > +// Request service from secure standalone MM environment
> > +#define ARM_SMC_ID_MM_COMMUNICATE_AARCH32  0x8441
> > +#define ARM_SMC_ID_MM_COMMUNICATE_AARCH64  0xC441
> > +
> > +/* MM return error codes */
> > +#define ARM_SMC_MM_RET_SUCCESS  0
> > +#define ARM_SMC_MM_RET_NOT_SUPPORTED   -1
> > +#define ARM_SMC_MM_RET_INVALID_PARAMS  -2
> > +#define ARM_SMC_MM_RET_DENIED  -3
> > +#define ARM_SMC_MM_RET_NO_MEMORY   -4
> > +
> >  /*
> >   * Power State Coordination Interface (PSCI) calls cover a subset of the
> >   * Standard Service Call range.
> > --
> > 2.14.1
> >
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Different ISCSI behavior when 2 attempts are added

[Karunakar P]

Hello All,

Found the below behavior when I try for ISCSI connection with 2 Valid attempts.

Case 1:
Attempt 1---Enabled(ISCSI Mode)---IP4Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP6Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but 
session does not exist

Case 2:
Attempt 1---Enabled(ISCSI Mode)---IP6Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP4Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but 
session does not exist

Case 3:
Attempt 1---Enabled(ISCSI Mode)---Autoconfigure --->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---IP6Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt1(IP4) connected and shown in shell ,Attempt2 tried but 
session does not exist

Case 4:
Attempt 1---Enabled(ISCSI Mode)---IP6--->Valid Attempt
Attempt 2---Enabled(ISCSI Mode)---Autoconfigure Enabled(Initiator 
DHCP)---Disabled(Target DHCP)--->Valid Attempt
EDK2 RESULT:- Attempt2(IP4) connected and shown in shell ,Attempt1 tried but 
session does not exist



1.   Case1 & Case3 looks fine as 1st valid attempt connected

2.   But Case2 & Case4 looks bit different, 1St attempt was valid but 
connection success with 2nd attempt

3.   As we found that IScsiIp4 Driver Binding Start is getting call first 
and processing the IP4 attempt first even though it is 2nd attempt

Could you please comment on this whether this is a bug or Not?

Thanks,
Karunakar
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v4 6/6] OvmfPkg/QemuVideoDxe: Bypass NULL pointer detection during VBE SHIM installing

[Jian J Wang]

QemuVideoDxe driver will link VBE SHIM into page 0. If NULL pointer
detection is enabled, this driver will fail to load. NULL pointer detection
bypassing code is added to prevent such problem during boot.

Please note that Windows 7 will try to access VBE SHIM during boot if it's
installed, and then cause boot failure. This can be fixed by setting BIT7
of PcdNullPointerDetectionPropertyMask to disable NULL pointer detection
after EndOfDxe. As far as we know, there's no other OSs has such issue.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf |  1 +
 OvmfPkg/QemuVideoDxe/VbeShim.c| 14 ++
 2 files changed, 15 insertions(+)

diff --git a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf 
b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
index 577e07b0a8..ff68c99e96 100644
--- a/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
+++ b/OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf
@@ -77,3 +77,4 @@
 [Pcd]
   gOptionRomPkgTokenSpaceGuid.PcdDriverSupportedEfiVersion
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
+  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask
diff --git a/OvmfPkg/QemuVideoDxe/VbeShim.c b/OvmfPkg/QemuVideoDxe/VbeShim.c
index e45a08e887..8ba5522cde 100644
--- a/OvmfPkg/QemuVideoDxe/VbeShim.c
+++ b/OvmfPkg/QemuVideoDxe/VbeShim.c
@@ -75,6 +75,20 @@ InstallVbeShim (
   UINTNPrinted;
   VBE_MODE_INFO*VbeModeInfo;
 
+  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & (BIT0|BIT7)) == BIT0) {
+DEBUG ((
+  DEBUG_WARN,
+  "%a: page 0 protected, not installing VBE shim\n",
+  __FUNCTION__
+  ));
+DEBUG ((
+  DEBUG_WARN,
+  "%a: page 0 protection prevents Windows 7 from booting anyway\n",
+  __FUNCTION__
+  ));
+return;
+  }
+
   Segment0 = 0x0;
   SegmentC = 0xC;
   SegmentF = 0xF;
-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v4 5/6] IntelFrameworkModulePkg/Csm: Add code to bypass NULL pointer detection

[Jian J Wang]

Legacy has to access interrupt vector, BDA, etc. located in memory between
0-4095. To allow as much code as possible to be monitored by NULL pointer
detection, we add code to temporarily disable this feature right before
those memory access and enable it again afterwards.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c   | 101 ++
 .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h   |   2 +
 .../Csm/BiosThunk/KeyboardDxe/KeyboardDxe.inf  |   2 +
 .../Csm/LegacyBiosDxe/LegacyBda.c  |   4 +
 .../Csm/LegacyBiosDxe/LegacyBios.c | 152 +
 .../Csm/LegacyBiosDxe/LegacyBiosDxe.inf|   2 +
 .../Csm/LegacyBiosDxe/LegacyBiosInterface.h|  18 +++
 .../Csm/LegacyBiosDxe/LegacyBootSupport.c  |  23 +++-
 .../Csm/LegacyBiosDxe/LegacyPci.c  |  17 ++-
 IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c  |  27 +++-
 10 files changed, 338 insertions(+), 10 deletions(-)

diff --git a/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c 
b/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c
index 7308523ad8..d2224a20aa 100644
--- a/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c
+++ b/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c
@@ -1732,6 +1732,98 @@ CheckKeyboardConnect (
   }
 }
 
+/**
+   Disable NULL pointer detection
+*/
+VOID
+DisableNullDetection (
+  VOID
+  )
+{
+  EFI_STATUSStatus;
+  EFI_GCD_MEMORY_SPACE_DESCRIPTOR   Desc;
+
+  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT0) == 0) {
+return;
+  }
+
+  //
+  // Check current capabilities and attributes
+  //
+  Status = gDS->GetMemorySpaceDescriptor (0, &Desc);
+  ASSERT_EFI_ERROR (Status);
+
+  //
+  // Try to add EFI_MEMORY_RP support if necessary
+  //
+  if ((Desc.Capabilities & EFI_MEMORY_RP) == 0) {
+Desc.Capabilities |= EFI_MEMORY_RP;
+Status = gDS->SetMemorySpaceCapabilities (0, EFI_PAGES_TO_SIZE(1),
+  Desc.Capabilities);
+ASSERT_EFI_ERROR (Status);
+if (EFI_ERROR (Status)) {
+  return;
+}
+  }
+
+  //
+  // Don't bother if EFI_MEMORY_RP is already cleared.
+  //
+  if ((Desc.Attributes & EFI_MEMORY_RP) != 0) {
+Desc.Attributes &= ~EFI_MEMORY_RP;
+Status = gDS->SetMemorySpaceAttributes (0, EFI_PAGES_TO_SIZE(1),
+Desc.Attributes);
+ASSERT_EFI_ERROR (Status);
+  } else {
+DEBUG ((DEBUG_WARN, "!!! Page 0 is supposed to be disabled !!!\r\n"));
+  }
+}
+
+/**
+   Enable NULL pointer detection
+*/
+VOID
+EnableNullDetection (
+  VOID
+  )
+{
+  EFI_STATUSStatus;
+  EFI_GCD_MEMORY_SPACE_DESCRIPTOR   Desc;
+
+  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT0) == 0) {
+return;
+  }
+
+  //
+  // Check current capabilities and attributes
+  //
+  Status = gDS->GetMemorySpaceDescriptor (0, &Desc);
+  ASSERT_EFI_ERROR (Status);
+
+  //
+  // Try to add EFI_MEMORY_RP support if necessary
+  //
+  if ((Desc.Capabilities & EFI_MEMORY_RP) == 0) {
+Desc.Capabilities |= EFI_MEMORY_RP;
+Status = gDS->SetMemorySpaceCapabilities (0, EFI_PAGES_TO_SIZE(1),
+  Desc.Capabilities);
+ASSERT_EFI_ERROR (Status);
+if (EFI_ERROR (Status)) {
+  return;
+}
+  }
+
+  //
+  // Don't bother if EFI_MEMORY_RP is already set.
+  //
+  if ((Desc.Attributes & EFI_MEMORY_RP) == 0) {
+Desc.Attributes |= EFI_MEMORY_RP;
+Status = gDS->SetMemorySpaceAttributes (0, EFI_PAGES_TO_SIZE(1),
+Desc.Attributes);
+ASSERT_EFI_ERROR (Status);
+  }
+}
+
 /**
   Timer event handler: read a series of key stroke from 8042
   and put them into memory key buffer. 
@@ -1839,6 +1931,11 @@ BiosKeyboardTimerHandler (
   //   0 Right Shift pressed
 
 
+  //
+  // Disable NULL pointer detection temporarily
+  //
+  DisableNullDetection ();
+
   //
   // Clear the CTRL and ALT BDA flag
   //
@@ -1916,6 +2013,10 @@ BiosKeyboardTimerHandler (
   KbFlag1 &= ~0x0C;  
   *((UINT8 *) (UINTN) 0x417) = KbFlag1; 
 
+  //
+  // Restore NULL pointer detection
+  //
+  EnableNullDetection ();
   
   //
   // Output EFI input key and shift/toggle state
diff --git a/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h 
b/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h
index 0bf28ea140..c64ec0095e 100644
--- a/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h
+++ b/IntelFrameworkModulePkg/Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h
@@ -18,6 +18,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 
 
 #include 
+#include 
 
 #include 
 #include 

[edk2] [PATCH v4 3/6] MdeModulePkg/Core/Dxe: Add EndOfDxe workaround for NULL pointer detection

[Jian J Wang]

> According to Star's feedback, use GCD service instead of CPU arch
> protocol to change page attributes

One of issue caused by enabling NULL pointer detection is that some PCI
device OptionROM, binary drivers and binary OS boot loaders may have NULL
pointer access bugs, which will prevent BIOS from booting and is almost
impossible to fix. BIT7 of PCD PcdNullPointerDetectionPropertyMask is used
as a workaround to indicate BIOS to disable NULL pointer detection right
after event gEfiEndOfDxeEventGroupGuid, and then let boot continue.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/Dxe/DxeMain.inf |  1 +
 MdeModulePkg/Core/Dxe/Mem/Page.c  |  4 +-
 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c | 65 +++
 3 files changed, 69 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf 
b/MdeModulePkg/Core/Dxe/DxeMain.inf
index 30d5984f7c..0a161ffd71 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.inf
+++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
@@ -192,6 +192,7 @@
   gEfiMdeModulePkgTokenSpaceGuid.PcdPropertiesTableEnable   ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdImageProtectionPolicy   ## 
CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdDxeNxMemoryProtectionPolicy ## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask## 
CONSUMES
 
 # [Hob]
 # RESOURCE_DESCRIPTOR   ## CONSUMES
diff --git a/MdeModulePkg/Core/Dxe/Mem/Page.c b/MdeModulePkg/Core/Dxe/Mem/Page.c
index a142c79ee2..0468df3171 100644
--- a/MdeModulePkg/Core/Dxe/Mem/Page.c
+++ b/MdeModulePkg/Core/Dxe/Mem/Page.c
@@ -188,7 +188,9 @@ CoreAddRange (
   // used for other purposes.
   //  
   if (Type == EfiConventionalMemory && Start == 0 && (End >= EFI_PAGE_SIZE - 
1)) {
-SetMem ((VOID *)(UINTN)Start, EFI_PAGE_SIZE, 0);
+if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT0) == 0) {
+  SetMem ((VOID *)(UINTN)Start, EFI_PAGE_SIZE, 0);
+}
   }
   
   //
diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c 
b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
index a73c4ccd64..0fa89e4437 100644
--- a/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
+++ b/MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
@@ -995,6 +995,53 @@ MemoryProtectionExitBootServicesCallback (
   }
 }
 
+/**
+  Disable NULL pointer detection after EndOfDxe. This is a workaround resort in
+  order to skip unfixable NULL pointer access issues detected in OptionROM or
+  boot loaders.
+
+  @param[in]  Event The Event this notify function registered to.
+  @param[in]  Context   Pointer to the context data registered to the Event.
+**/
+VOID
+EFIAPI
+DisableNullDetectionAtTheEndOfDxe (
+  EFI_EVENT   Event,
+  VOID*Context
+  )
+{
+  EFI_STATUSStatus;
+  EFI_GCD_MEMORY_SPACE_DESCRIPTOR   Desc;
+
+  DEBUG ((DEBUG_INFO, "DisableNullDetectionAtTheEndOfDxe(): start\r\n"));
+  //
+  // Disable NULL pointer detection by enabling first 4K page
+  //
+  Status = CoreGetMemorySpaceDescriptor (0, &Desc);
+  ASSERT_EFI_ERROR (Status);
+
+  if ((Desc.Capabilities & EFI_MEMORY_RP) == 0) {
+Status = CoreSetMemorySpaceCapabilities (
+  0,
+  EFI_PAGE_SIZE,
+  Desc.Capabilities | EFI_MEMORY_RP
+  );
+ASSERT_EFI_ERROR (Status);
+  }
+
+  Status = CoreSetMemorySpaceAttributes (
+0,
+EFI_PAGE_SIZE,
+Desc.Attributes & ~EFI_MEMORY_RP
+);
+  ASSERT_EFI_ERROR (Status);
+
+  CoreCloseEvent (Event);
+  DEBUG ((DEBUG_INFO, "DisableNullDetectionAtTheEndOfDxe(): end\r\n"));
+
+  return;
+}
+
 /**
   Initialize Memory Protection support.
 **/
@@ -1006,6 +1053,7 @@ CoreInitializeMemoryProtection (
 {
   EFI_STATUS  Status;
   EFI_EVENT   Event;
+  EFI_EVENT   EndOfDxeEvent;
   VOID*Registration;
 
   mImageProtectionPolicy = PcdGet32(PcdImageProtectionPolicy);
@@ -1044,6 +1092,23 @@ CoreInitializeMemoryProtection (
);
 ASSERT_EFI_ERROR(Status);
   }
+
+  //
+  // Register a callback to disable NULL pointer detection at EndOfDxe
+  //
+  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & (BIT0|BIT7))
+   == (BIT0|BIT7)) {
+Status = CoreCreateEventEx (
+EVT_NOTIFY_SIGNAL,
+TPL_NOTIFY,
+DisableNullDetectionAtTheEndOfDxe,
+NULL,
+&gEfiEndOfDxeEventGroupGuid,
+&EndOfDxeEvent
+);
+ASSERT_EFI_ERROR (Status);
+  }
+
   return ;
 }
 
-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v4 4/6] UefiCpuPkg/PiSmmCpuDxeSmm: Implement NULL pointer detection for SMM code

[Jian J Wang]

The mechanism behind is the same as NULL pointer detection enabled in EDK-II
core. SMM has its own page table and we have to disable page 0 again in SMM
mode.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 12 
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c| 25 -
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf |  1 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c  | 12 
 4 files changed, 49 insertions(+), 1 deletion(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
index f295c2ebf2..641a1d69a2 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
@@ -155,6 +155,18 @@ SmiPFHandler (
 }
   }
 
+  //
+  // If NULL pointer was just accessed
+  //
+  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT1) != 0 &&
+  (PFAddress < EFI_PAGE_SIZE)) {
+DEBUG ((DEBUG_ERROR, "!!! NULL pointer access !!!\n"));
+DEBUG_CODE (
+  DumpModuleInfoByIp ((UINTN)SystemContext.SystemContextIa32->Eip);
+);
+CpuDeadLoop ();
+  }
+
   if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
 SmmProfilePFHandler (
   SystemContext.SystemContextIa32->Eip,
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
index f086b97c30..0d3223d714 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c
@@ -855,10 +855,10 @@ Gen4GPageTable (
 Pte[Index] = (Index << 21) | mAddressEncMask | IA32_PG_PS | 
PAGE_ATTRIBUTE_BITS;
   }
 
+  Pdpte = (UINT64*)PageTable;
   if (FeaturePcdGet (PcdCpuSmmStackGuard)) {
 Pages = (UINTN)PageTable + EFI_PAGES_TO_SIZE (5);
 GuardPage = mSmmStackArrayBase + EFI_PAGE_SIZE;
-Pdpte = (UINT64*)PageTable;
 for (PageIndex = Low2MBoundary; PageIndex <= High2MBoundary; PageIndex += 
SIZE_2MB) {
   Pte = (UINT64*)(UINTN)(Pdpte[BitFieldRead32 ((UINT32)PageIndex, 30, 31)] 
& ~mAddressEncMask & ~(EFI_PAGE_SIZE - 1));
   Pte[BitFieldRead32 ((UINT32)PageIndex, 21, 29)] = (UINT64)Pages | 
mAddressEncMask | PAGE_ATTRIBUTE_BITS;
@@ -886,6 +886,29 @@ Gen4GPageTable (
 }
   }
 
+  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT1) != 0) {
+Pte = (UINT64*)(UINTN)(Pdpte[0] & ~mAddressEncMask & ~(EFI_PAGE_SIZE - 1));
+if ((Pte[0] & IA32_PG_PS) == 0) {
+  // 4K-page entries are already mapped. Just hide the first one anyway.
+  Pte = (UINT64*)(UINTN)(Pte[0] & ~mAddressEncMask & ~(EFI_PAGE_SIZE - 1));
+  Pte[0] &= ~IA32_PG_P; // Hide page 0
+} else {
+  // Create 4K-page entries
+  Pages = (UINTN)AllocatePageTableMemory (1);
+  ASSERT (Pages != 0);
+
+  Pte[0] = (UINT64)(Pages | mAddressEncMask | PAGE_ATTRIBUTE_BITS);
+
+  Pte = (UINT64*)Pages;
+  PageAddress = 0;
+  Pte[0] = PageAddress | mAddressEncMask; // Hide page 0 but present left
+  for (Index = 1; Index < EFI_PAGE_SIZE / sizeof (*Pte); Index++) {
+PageAddress += EFI_PAGE_SIZE;
+Pte[Index] = PageAddress | mAddressEncMask | PAGE_ATTRIBUTE_BITS;
+  }
+}
+  }
+
   return (UINT32)(UINTN)PageTable;
 }
 
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf 
b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
index 099792e6ce..31cb215342 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf
@@ -159,6 +159,7 @@
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStaticPageTable   ## CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdAcpiS3Enable   ## CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask## 
CONSUMES
 
 [Depex]
   gEfiMpServiceProtocolGuid
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
index 3dde80f9ba..f3791ce897 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
@@ -872,6 +872,18 @@ SmiPFHandler (
 }
   }
 
+  //
+  // If NULL pointer was just accessed
+  //
+  if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT1) != 0 &&
+  (PFAddress < EFI_PAGE_SIZE)) {
+DEBUG ((DEBUG_ERROR, "!!! NULL pointer access !!!\n"));
+DEBUG_CODE (
+  DumpModuleInfoByIp ((UINTN)SystemContext.SystemContextX64->Rip);
+);
+CpuDeadLoop ();
+  }
+
   if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
 SmmProfilePFHandler (
   SystemContext.SystemContextX64->Rip,
-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v4 2/6] MdeModulePkg/DxeIpl: Implement NULL pointer detection

[Jian J Wang]

> According to Start's feedback
>   a. Change function ClearLegacyMemory to ClearFirst4KPage
>   b. Call ClearFirst4KPage only when NULL detection is enabled
>   c. Move ClearFirst4KPage to X64/Ia32 related files

NULL pointer detection is done by making use of paging mechanism of CPU.
During page table setup, if enabled, the first 4-K page (0-4095) will be
marked as NOT PRESENT. Any code which unintentionally access memory between
0-4095 will trigger a Page Fault exception which warns users that there's
potential illegal code in BIOS.

This also means that legacy code which has to access memory between 0-4095
should be cautious to temporarily disable this feature before the access
and re-enable it afterwards; or disalbe this feature at all.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.h| 25 +++
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf  |  1 +
 MdeModulePkg/Core/DxeIplPeim/DxeLoad.c   |  1 +
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  | 17 -
 MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c   |  4 +
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 93 ++--
 6 files changed, 131 insertions(+), 10 deletions(-)

diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h 
b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
index 72d2532f50..ecf186667a 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
@@ -240,4 +240,29 @@ Decompress (
   OUT   UINTN   *OutputSize
   );
 
+/**
+   Clear legacy memory located at the first 4K-page.
+
+   This function traverses the whole HOB list to check if memory from 0 to 4095
+   exists and has not been allocated, and then clear it if so.
+
+   @param HoStart The start of HobList passed to DxeCore.
+
+**/
+VOID
+ClearFirst4KPage (
+  IN  VOID *HobStart
+  );
+
+/**
+   Return configure status of NULL pointer detection feature
+
+   @return TRUE   NULL pointer detection feature is enabled
+   @return FALSE  NULL pointer detection feature is disabled
+**/
+BOOLEAN
+IsNullDetectionEnabled (
+  VOID
+  );
+
 #endif
diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf 
b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
index c54afe4aa6..9d0e76a293 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf
@@ -115,6 +115,7 @@
 [Pcd.IA32,Pcd.X64]
   gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable  ## 
SOMETIMES_CONSUMES
   gEfiMdeModulePkgTokenSpaceGuid.PcdPteMemoryEncryptionAddressOrMask## 
CONSUMES
+  gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask## 
CONSUMES
 
 [Pcd.IA32,Pcd.X64,Pcd.ARM,Pcd.AARCH64]
   gEfiMdeModulePkgTokenSpaceGuid.PcdSetNxForStack   ## 
SOMETIMES_CONSUMES
diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c 
b/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c
index 50b5440d15..1f626a9e86 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeLoad.c
@@ -825,3 +825,4 @@ UpdateStackHob (
 Hob.Raw = GET_NEXT_HOB (Hob);
   }
 }
+
diff --git a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c 
b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
index 1957326caf..96f5718444 100644
--- a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
+++ b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
@@ -123,7 +123,9 @@ Create4GPageTablesIa32Pae (
 PageDirectoryPointerEntry->Bits.Present = 1;
 
 for (IndexOfPageDirectoryEntries = 0; IndexOfPageDirectoryEntries < 512; 
IndexOfPageDirectoryEntries++, PageDirectoryEntry++, PhysicalAddress += 
SIZE_2MB) {
-  if ((PhysicalAddress < StackBase + StackSize) && ((PhysicalAddress + 
SIZE_2MB) > StackBase)) {
+  if ((IsNullDetectionEnabled () && PhysicalAddress == 0)
+  || ((PhysicalAddress < StackBase + StackSize)
+  && ((PhysicalAddress + SIZE_2MB) > StackBase))) {
 //
 // Need to split this 2M page that covers stack range.
 //
@@ -240,6 +242,10 @@ HandOffToDxeCore (
   EFI_PEI_VECTOR_HANDOFF_INFO_PPI *VectorHandoffInfoPpi;
   BOOLEAN   BuildPageTablesIa32Pae;
 
+  if (IsNullDetectionEnabled ()) {
+ClearFirst4KPage (HobList.Raw);
+  }
+
   Status = PeiServicesAllocatePages (EfiBootServicesData, EFI_SIZE_TO_PAGES 
(STACK_SIZE), &BaseOfStack);
   ASSERT_EFI_ERROR (Status);
 
@@ -379,10 +385,15 @@ HandOffToDxeCore (
 TopOfStack = (EFI_PHYSICAL_ADDRESS) (UINTN) ALIGN_POINTER (TopOfStack, 
CPU_STACK_ALIGNMENT);
 
 PageTables = 0;
-BuildPageTablesIa32Pae = (BOOLEAN) (PcdGetBool (PcdSetNxForStack) && 
IsIa32PaeSupport () && IsExecuteDisableBitAvailable ());
+BuildPageTablesIa32Pae = (BOOLEAN) (IsIa32PaeSupport () &&
+(IsNullDetectionEnabled () ||
+ (PcdGetB

[edk2] [PATCH v4 1/6] MdeModulePkg/MdeModulePkg.dec, .uni: Add NULL pointer detection PCD

[Jian J Wang]

From: "Wang, Jian J" 

PCD PcdNullPointerDetectionPropertyMask is a bitmask used to control the
NULL address detection functionality in code for different phases.

If enabled, accessing NULL address in UEFI or SMM code can be caught
as a page fault exception.

BIT0- Enable NULL pointer detection for UEFI.
BIT1- Enable NULL pointer detection for SMM.
BIT2..6 - Reserved for future uses.
BIT7- Disable NULL pointer detection just after EndOfDxe. This is a
  workaround for those unsolvable NULL access issues in
  OptionROM, boot loader, etc. It can also help to avoid
  unnecessary exception caused by legacy memory (0-4095) access
  after EndOfDxe, such as Windows 7 boot on Qemu.

Cc: Star Zeng 
Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Michael Kinney 
Cc: Ayellet Wolman 
Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/MdeModulePkg.dec | 13 +
 MdeModulePkg/MdeModulePkg.uni | 13 +
 2 files changed, 26 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index a3c0633ee1..9248d10da8 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -867,6 +867,19 @@
   # @ValidList  0x8006 | 0x03058002
   
gEfiMdeModulePkgTokenSpaceGuid.PcdErrorCodeSetVariable|0x03058002|UINT32|0x30001040
 
+  ## Mask to control the NULL address detection in code for different phases.
+  #  If enabled, accessing NULL address in UEFI or SMM code can be 
caught.
+  #BIT0- Enable NULL pointer detection for UEFI.
+  #BIT1- Enable NULL pointer detection for SMM.
+  #BIT2..6 - Reserved for future uses.
+  #BIT7- Disable NULL pointer detection just after EndOfDxe. 
+  #  This is a workaround for those unsolvable NULL access issues 
in
+  #  OptionROM, boot loader, etc. It can also help to avoid 
unnecessary
+  #  exception caused by legacy memory (0-4095) access after 
EndOfDxe,
+  #  such as Windows 7 boot on Qemu.
+  # @Prompt Enable NULL address detection.
+  
gEfiMdeModulePkgTokenSpaceGuid.PcdNullPointerDetectionPropertyMask|0x0|UINT8|0x30001050
+
 [PcdsFixedAtBuild, PcdsPatchableInModule]
   ## Dynamic type PCD can be registered callback function for Pcd setting 
action.
   #  PcdMaxPeiPcdCallBackNumberPerPcdEntry indicates the maximum number of 
callback function
diff --git a/MdeModulePkg/MdeModulePkg.uni b/MdeModulePkg/MdeModulePkg.uni
index d6015de75f..f8b31694ba 100644
--- a/MdeModulePkg/MdeModulePkg.uni
+++ b/MdeModulePkg/MdeModulePkg.uni
@@ -1127,3 +1127,16 @@

  "enabled on AMD processors supporting the Secure 
Encrypted Virtualization (SEV) feature.\n"

  "This mask should be applied when creating 1:1 virtual to 
physical mapping tables."
 
+#string 
STR_gEfiMdeModulePkgTokenSpaceGuid_PcdNullPointerDetectionPropertyMask_PROMPT  
#language en-US "Enable NULL pointer detection"
+
+#string 
STR_gEfiMdeModulePkgTokenSpaceGuid_PcdNullPointerDetectionPropertyMask_HELP
#language en-US "Mask to control the NULL address detection in code for 
different phases.\n"
+   
" If enabled, accessing NULL address in UEFI or SMM 
code can be caught.\n\n"
+   
"   BIT0- Enable NULL pointer detection for UEFI.\n"
+   
"   BIT1- Enable NULL pointer detection for SMM.\n"
+   
"   BIT2..6 - Reserved for future uses.\n"
+   
"   BIT7- Disable NULL pointer detection just after 
EndOfDxe."
+   
" This is a workaround for those unsolvable NULL access 
issues in"
+   
" OptionROM, boot loader, etc. It can also help to 
avoid unnecessary"
+   
" exception caused by legacy memory (0-4095) access 
after EndOfDxe,"
+   
" such as Windows 7 boot on Qemu.\n"
+
-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-deve

[edk2] [PATCH v4 0/6] Add NULL pointer detection feature

[Jian J Wang]

The mechanism behind is to trigger a page fault exception at address 0.
This can be made by disabling page 0 (0-4095) during page table setup.
So this feature can only be available on platform with paging enabled.

Once this feature is enabled, any code, like CSM, which has to access
memory in page 0 needs to enable this page temporarily in advance and
disable it afterwards.

PcdNullPointerDetectionPropertyMask is used to control and elaborate
the use cases. For example, BIT7 of this PCD must be set for Windows 7
boot on Qemu if BIT0 set; or boot will fail.

Suggested-by: Ayellet Wolman 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 

Jian J Wang (5):
  MdeModulePkg/DxeIpl: Implement NULL pointer detection
  MdeModulePkg/Core/Dxe: Add EndOfDxe workaround for NULL pointer
detection
  UefiCpuPkg/PiSmmCpuDxeSmm: Implement NULL pointer detection for SMM
code
  IntelFrameworkModulePkg/Csm: Add code to bypass NULL pointer detection
  OvmfPkg/QemuVideoDxe: Bypass NULL pointer detection during VBE SHIM
installing

Wang, Jian J (1):
  MdeModulePkg/MdeModulePkg.dec,.uni: Add NULL pointer detection PCD

 .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.c   | 101 ++
 .../Csm/BiosThunk/KeyboardDxe/BiosKeyboard.h   |   2 +
 .../Csm/BiosThunk/KeyboardDxe/KeyboardDxe.inf  |   2 +
 .../Csm/LegacyBiosDxe/LegacyBda.c  |   4 +
 .../Csm/LegacyBiosDxe/LegacyBios.c | 152 +
 .../Csm/LegacyBiosDxe/LegacyBiosDxe.inf|   2 +
 .../Csm/LegacyBiosDxe/LegacyBiosInterface.h|  18 +++
 .../Csm/LegacyBiosDxe/LegacyBootSupport.c  |  23 +++-
 .../Csm/LegacyBiosDxe/LegacyPci.c  |  17 ++-
 IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c  |  27 +++-
 MdeModulePkg/Core/Dxe/DxeMain.inf  |   1 +
 MdeModulePkg/Core/Dxe/Mem/Page.c   |   4 +-
 MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c  |  65 +
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.h  |  25 
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.inf|   1 +
 MdeModulePkg/Core/DxeIplPeim/DxeLoad.c |   1 +
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c|  17 ++-
 MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c |   4 +
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c   |  93 -
 MdeModulePkg/MdeModulePkg.dec  |  13 ++
 MdeModulePkg/MdeModulePkg.uni  |  13 ++
 OvmfPkg/QemuVideoDxe/QemuVideoDxe.inf  |   1 +
 OvmfPkg/QemuVideoDxe/VbeShim.c |  14 ++
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c   |  12 ++
 UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c  |  25 +++-
 UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.inf   |   1 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c|  12 ++
 27 files changed, 628 insertions(+), 22 deletions(-)

-- 
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2] TFTP : tftp fix for full volume case

[Carsey, Jaben]

I am fine. Ray?

Reviewed-by: Jaben Carsey 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Meenakshi Aggarwal
> Sent: Sunday, October 08, 2017 11:28 PM
> To: Fu, Siyuan ; edk2-devel@lists.01.org; Ni, Ruiyu
> ; Carsey, Jaben ; Ye, Ting
> 
> Subject: Re: [edk2] [PATCH v2] TFTP : tftp fix for full volume case
> Importance: High
> 
> Hi Team,
> 
> 
> Any further comments on this patch?
> 
> Or is it ready to merge in edk2?
> 
> 
> Thanks,
> Meenakshi
> 
> > -Original Message-
> > From: Meenakshi Aggarwal
> > Sent: Wednesday, September 27, 2017 9:01 AM
> > To: 'Fu, Siyuan' ; edk2-devel@lists.01.org; Ni, Ruiyu
> > ; Carsey, Jaben ; Ye, Ting
> > 
> > Cc: Udit Kumar ; Vabhav Sharma
> > 
> > Subject: RE: [PATCH v2] TFTP : tftp fix for full volume case
> >
> > Hi,
> >
> > Thanks for the review Siyuan.
> >
> >
> > Ting,
> >
> > Any comment from your side?
> >
> > Thanks,
> > Meenakshi
> >
> > > -Original Message-
> > > From: Fu, Siyuan [mailto:siyuan...@intel.com]
> > > Sent: Tuesday, September 26, 2017 6:12 AM
> > > To: Meenakshi Aggarwal ; edk2-
> > > de...@lists.01.org; Ni, Ruiyu ; Carsey, Jaben
> > > 
> > > Cc: ard.biesheu...@linaro.org; leif.lindh...@linaro.org; Ye, Ting
> > > ; Udit Kumar ; Vabhav
> Sharma
> > > 
> > > Subject: RE: [PATCH v2] TFTP : tftp fix for full volume case
> > >
> > > Reviewed-by: Fu Siyuan 
> > >
> > > -Original Message-
> > > From: Meenakshi Aggarwal [mailto:meenakshi.aggar...@nxp.com]
> > > Sent: Monday, September 25, 2017 11:06 PM
> > > To: edk2-devel@lists.01.org; Ni, Ruiyu ; Carsey,
> > > Jaben 
> > > Cc: ard.biesheu...@linaro.org; leif.lindh...@linaro.org; Fu, Siyuan
> > > ; Ye, Ting ; Meenakshi
> > > Aggarwal ; Udit Kumar
> > > ; Vabhav Sharma 
> > > Subject: [PATCH v2] TFTP : tftp fix for full volume case
> > >
> > > Issue :
> > > When storage media is full, tftp was resulting in ASSERT
> > > MdeModulePkg/Core/Dxe/Mem/Page.c, because number of pages was
> > zero.
> > >
> > > Reason:
> > > While doing tftp, function call ShellWriteFile was modifying FileSize
> variable.
> > > In case of full disk it was coming out to be Zero.
> > >
> > > Fix:
> > > Storage the original filesize in local variable, and use this variable
> > > while freeing the pages.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Udit Kumar 
> > > Signed-off-by: Meenakshi Aggarwal 
> > > Signed-off-by: Vabhav Sharma 
> > > Signed-off-by: Meenakshi Aggarwal 
> > > ---
> > >  ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c | 5 -
> > >  1 file changed, 4 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > > b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > > index 5c50797..fbde3bf 100755
> > > --- a/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > > +++ b/ShellPkg/Library/UefiShellTftpCommandLib/Tftp.c
> > > @@ -284,6 +284,7 @@ ShellCommandRunTftp (
> > >EFI_HANDLE  Mtftp4ChildHandle;
> > >EFI_MTFTP4_PROTOCOL *Mtftp4;
> > >UINTN   FileSize;
> > > +  UINTN   DataSize;
> > >VOID*Data;
> > >SHELL_FILE_HANDLE   FileHandle;
> > >UINT16  BlockSize;
> > > @@ -294,6 +295,7 @@ ShellCommandRunTftp (
> > >AsciiRemoteFilePath = NULL;
> > >Handles = NULL;
> > >FileSize= 0;
> > > +  DataSize= 0;
> > >BlockSize   = MTFTP_DEFAULT_BLKSIZE;
> > >
> > >//
> > > @@ -537,6 +539,7 @@ ShellCommandRunTftp (
> > >goto NextHandle;
> > >  }
> > >
> > > +DataSize = FileSize;
> > >  Status = ShellWriteFile (FileHandle, &FileSize, Data);
> > >  if (!EFI_ERROR (Status)) {
> > >ShellStatus = SHELL_SUCCESS;
> > > @@ -551,7 +554,7 @@ ShellCommandRunTftp (
> > >  NextHandle:
> > >
> > >  if (Data != NULL) {
> > > -  gBS->FreePages ((EFI_PHYSICAL_ADDRESS)(UINTN)Data,
> > > EFI_SIZE_TO_PAGES (FileSize));
> > > +  gBS->FreePages ((EFI_PHYSICAL_ADDRESS)(UINTN)Data,
> > > + EFI_SIZE_TO_PAGES (DataSize));
> > >  }
> > >
> > >  CloseProtocolAndDestroyServiceChild (
> > > --
> > > 1.9.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] BaseTools: Fix the bug 'DSC DEFAULT' in report wrongly use FDF value

[Yonghong Zhu]

current the PCD value in DSC file may be override by FDF file, then it
cause the 'DSC DEFAULT' in build report wrongly display the FDF value
but not the DSC file's value.
This patch add a attribute DscDefaultValue for PcdClassObject to save
the actual DSC file's PCD value and use this value to display for 'DSC
DEFAULT'.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/Workspace/BuildClassObject.py |  7 +--
 .../Source/Python/Workspace/WorkspaceDatabase.py  | 19 +--
 BaseTools/Source/Python/build/BuildReport.py  |  7 ---
 3 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/BaseTools/Source/Python/Workspace/BuildClassObject.py 
b/BaseTools/Source/Python/Workspace/BuildClassObject.py
index ea26e5e..5fa497b 100644
--- a/BaseTools/Source/Python/Workspace/BuildClassObject.py
+++ b/BaseTools/Source/Python/Workspace/BuildClassObject.py
@@ -1,9 +1,9 @@
 ## @file
 # This file is used to define each component of the build database
 #
-# Copyright (c) 2007 - 2015, Intel Corporation. All rights reserved.
+# Copyright (c) 2007 - 2017, Intel Corporation. All rights reserved.
 # This program and the accompanying materials
 # are licensed and made available under the terms and conditions of the BSD 
License
 # which accompanies this distribution.  The full text of the license may be 
found at
 # http://opensource.org/licenses/bsd-license.php
 #
@@ -42,11 +42,11 @@ from Common.BuildToolError import *
 # @var SkuInfoList:  To store value for SkuInfoList
 # @var IsOverrided:  To store value for IsOverrided
 # @var Phase:To store value for Phase, default is "DXE"
 #
 class PcdClassObject(object):
-def __init__(self, Name = None, Guid = None, Type = None, DatumType = 
None, Value = None, Token = None, MaxDatumSize = None, SkuInfoList = {}, 
IsOverrided = False, GuidValue = None, validateranges = [], validlists = [], 
expressions = []):
+def __init__(self, Name = None, Guid = None, Type = None, DatumType = 
None, Value = None, Token = None, MaxDatumSize = None, SkuInfoList = {}, 
IsOverrided = False, GuidValue = None, validateranges = [], validlists = [], 
expressions = [], IsDsc = False):
 self.TokenCName = Name
 self.TokenSpaceGuidCName = Guid
 self.TokenSpaceGuidValue = GuidValue
 self.Type = Type
 self.DatumType = DatumType
@@ -60,10 +60,13 @@ class PcdClassObject(object):
 self.IsFromBinaryInf = False
 self.IsFromDsc = False
 self.validateranges = validateranges
 self.validlists = validlists
 self.expressions = expressions
+self.DscDefaultValue = None
+if IsDsc:
+self.DscDefaultValue = Value
 
 ## Convert the class to a string
 #
 #  Convert each member of the class to string
 #  Organize to a signle line format string
diff --git a/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py 
b/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
index b617221..2c4b973 100644
--- a/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
+++ b/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
@@ -883,12 +883,12 @@ class DscBuildData(PlatformBuildClassObject):
 PcdValue,
 '',
 MaxDatumSize,
 {},
 False,
-None
-)
+None,
+IsDsc=True)
 return Pcds
 
 ## Retrieve dynamic PCD settings
 #
 #   @param  TypePCD type
@@ -948,13 +948,13 @@ class DscBuildData(PlatformBuildClassObject):
 PcdValue,
 '',
 MaxDatumSize,
 {SkuName : SkuInfo},
 False,
-None
-)
-
+None,
+IsDsc=True)
+
 for pcd in Pcds.values():
 pcdDecObject = 
self._DecPcds[pcd.TokenCName,pcd.TokenSpaceGuidCName]
 if 'DEFAULT' not in pcd.SkuInfoList.keys() and 'COMMON' not in 
pcd.SkuInfoList.keys():
 valuefromDec = pcdDecObject.DefaultValue
 SkuInfo = SkuInfoClass('DEFAULT', '0', '', '', '', '', '', 
valuefromDec)
@@ -1067,13 +1067,12 @@ class DscBuildData(PlatformBuildClassObject):
  

[edk2] [Patch] BaseTools: Fix the bug 'DSC DEFAULT' in report wrongly use FDF value

[Yonghong Zhu]

current the PCD value in DSC file may be override by FDF file, then it
cause the 'DSC DEFAULT' in build report wrongly display the FDF value
but not the DSC file's value.
This patch add a attribute DscDefaultValue for PcdClassObject to save
the actual DSC file's PCD value and use this value to display for 'DSC
DEFAULT'.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/Workspace/BuildClassObject.py |  7 +--
 .../Source/Python/Workspace/WorkspaceDatabase.py  | 19 +--
 BaseTools/Source/Python/build/BuildReport.py  |  7 ---
 3 files changed, 18 insertions(+), 15 deletions(-)

diff --git a/BaseTools/Source/Python/Workspace/BuildClassObject.py 
b/BaseTools/Source/Python/Workspace/BuildClassObject.py
index ea26e5e..5fa497b 100644
--- a/BaseTools/Source/Python/Workspace/BuildClassObject.py
+++ b/BaseTools/Source/Python/Workspace/BuildClassObject.py
@@ -1,9 +1,9 @@
 ## @file
 # This file is used to define each component of the build database
 #
-# Copyright (c) 2007 - 2015, Intel Corporation. All rights reserved.
+# Copyright (c) 2007 - 2017, Intel Corporation. All rights reserved.
 # This program and the accompanying materials
 # are licensed and made available under the terms and conditions of the BSD 
License
 # which accompanies this distribution.  The full text of the license may be 
found at
 # http://opensource.org/licenses/bsd-license.php
 #
@@ -42,11 +42,11 @@ from Common.BuildToolError import *
 # @var SkuInfoList:  To store value for SkuInfoList
 # @var IsOverrided:  To store value for IsOverrided
 # @var Phase:To store value for Phase, default is "DXE"
 #
 class PcdClassObject(object):
-def __init__(self, Name = None, Guid = None, Type = None, DatumType = 
None, Value = None, Token = None, MaxDatumSize = None, SkuInfoList = {}, 
IsOverrided = False, GuidValue = None, validateranges = [], validlists = [], 
expressions = []):
+def __init__(self, Name = None, Guid = None, Type = None, DatumType = 
None, Value = None, Token = None, MaxDatumSize = None, SkuInfoList = {}, 
IsOverrided = False, GuidValue = None, validateranges = [], validlists = [], 
expressions = [], IsDsc = False):
 self.TokenCName = Name
 self.TokenSpaceGuidCName = Guid
 self.TokenSpaceGuidValue = GuidValue
 self.Type = Type
 self.DatumType = DatumType
@@ -60,10 +60,13 @@ class PcdClassObject(object):
 self.IsFromBinaryInf = False
 self.IsFromDsc = False
 self.validateranges = validateranges
 self.validlists = validlists
 self.expressions = expressions
+self.DscDefaultValue = None
+if IsDsc:
+self.DscDefaultValue = Value
 
 ## Convert the class to a string
 #
 #  Convert each member of the class to string
 #  Organize to a signle line format string
diff --git a/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py 
b/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
index b617221..2c4b973 100644
--- a/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
+++ b/BaseTools/Source/Python/Workspace/WorkspaceDatabase.py
@@ -883,12 +883,12 @@ class DscBuildData(PlatformBuildClassObject):
 PcdValue,
 '',
 MaxDatumSize,
 {},
 False,
-None
-)
+None,
+IsDsc=True)
 return Pcds
 
 ## Retrieve dynamic PCD settings
 #
 #   @param  TypePCD type
@@ -948,13 +948,13 @@ class DscBuildData(PlatformBuildClassObject):
 PcdValue,
 '',
 MaxDatumSize,
 {SkuName : SkuInfo},
 False,
-None
-)
-
+None,
+IsDsc=True)
+
 for pcd in Pcds.values():
 pcdDecObject = 
self._DecPcds[pcd.TokenCName,pcd.TokenSpaceGuidCName]
 if 'DEFAULT' not in pcd.SkuInfoList.keys() and 'COMMON' not in 
pcd.SkuInfoList.keys():
 valuefromDec = pcdDecObject.DefaultValue
 SkuInfo = SkuInfoClass('DEFAULT', '0', '', '', '', '', '', 
valuefromDec)
@@ -1067,13 +1067,12 @@ class DscBuildData(PlatformBuildClassObject):
  

[edk2] [Patch] BaseTools: Fix the Keyword error for in FDF File

[Yonghong Zhu]

current in FDF spec 3.6 [FV] section it use "FV_EXT_ENTRY_TYPE" as
Keyword for , while in the code it use "FV_EXT_ENTRY".
To keep compatibility, this patch support both keyword in the code
first.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/GenFds/FdfParser.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/GenFds/FdfParser.py 
b/BaseTools/Source/Python/GenFds/FdfParser.py
index b95afc7..0190be8 100644
--- a/BaseTools/Source/Python/GenFds/FdfParser.py
+++ b/BaseTools/Source/Python/GenFds/FdfParser.py
@@ -2363,11 +2363,11 @@ class FdfParser:
 
 return True
 
 def __GetFvExtEntryStatement(self, FvObj):
 
-if not self.__IsKeyword( "FV_EXT_ENTRY"):
+if not (self.__IsKeyword( "FV_EXT_ENTRY") or self.__IsKeyword( 
"FV_EXT_ENTRY_TYPE")):
 return False
 
 if not self.__IsKeyword ("TYPE"):
 raise Warning("expected 'TYPE'", self.FileName, 
self.CurrentLineNumber)
 
-- 
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 2/6] MdeModulePkg/Variable/RuntimeDxe: move MOR func. declarations to header

[Laszlo Ersek]

On 10/09/17 08:55, Zeng, Star wrote:
> Minor comment:
> 
> How about also to fix the comment for Attributes parameter of 
> SetVariableCheckHandlerMor() like below?
> 
>   @param[in]  Attributes Attributes bitmask to set for the variable.

Right, I can do that.

Thanks!
Laszlo

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com] 
> Sent: Wednesday, October 4, 2017 5:29 AM
> To: edk2-devel-01 
> Cc: Dong, Eric ; Yao, Jiewen ; 
> Ladi Prosek ; Zeng, Star 
> Subject: [PATCH 2/6] MdeModulePkg/Variable/RuntimeDxe: move MOR func. 
> declarations to header
> 
> The MorLockInit() and SetVariableCheckHandlerMor() functions have separate 
> implementations for VariableRuntimeDxe (= unprivileged, unified DXE_RUNTIME 
> driver) and VariableSmm (= privileged, DXE_SMM back-end of the split variable 
> driver).
> 
> Move their declarations from "Variable.c" to "PrivilegePolymorphic.h", so 
> that the compiler enforce that the declarations and the definitions match.
> (All C source files with the call sites and the function definitions already 
> include "PrivilegePolymorphic.h" via "Variable.h".)
> 
> At the same time:
> 
> - replace two typos in the MorLockInit() description:
>   - replace "EFI_SUCEESS" with "EFI_SUCCESS",
>   - replace "MOR Lock Control" with "MOR Control Lock";
> 
> - in the SetVariableCheckHandlerMor() description:
>   - replace @param with @param[in],
>   - rewrap the comment to 80 columns.
> 
> This change cleans up commit 2f6aa774fe38 ("MdeModulePkg: Add MorLock to 
> variable driver.", 2016-01-19).
> 
> Cc: Eric Dong 
> Cc: Jiewen Yao 
> Cc: Ladi Prosek 
> Cc: Star Zeng 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 
> ---
>  MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h | 41 
> 
>  MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c| 30 
> +++---
>  MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c| 30 
> +++---
>  MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c | 37 
> --
>  4 files changed, 75 insertions(+), 63 deletions(-)
> 
> diff --git 
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h 
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> index 0aa0d4f48f10..1118f4b52e49 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> @@ -35,4 +35,45 @@ SecureBootHook (
>IN EFI_GUID   *VendorGuid
>);
>  
> +/**
> +  Initialization for MOR Control Lock.
> +
> +  @retval EFI_SUCCESS MorLock initialization success.
> +  @return Others  Some error occurs.
> +**/
> +EFI_STATUS
> +MorLockInit (
> +  VOID
> +  );
> +
> +/**
> +  This service is an MOR/MorLock checker handler for the SetVariable().
> +
> +  @param[in]  VariableName the name of the vendor's variable, as a
> +   Null-Terminated Unicode String
> +  @param[in]  VendorGuid   Unify identifier for vendor.
> +  @param[in]  Attributes   Point to memory location to return the attributes 
> of
> +   variable. If the point is NULL, the parameter 
> would
> +   be ignored.
> +  @param[in]  DataSize The size in bytes of Data-Buffer.
> +  @param[in]  Data Point to the content of the variable.
> +
> +  @retval  EFI_SUCCESSThe MOR/MorLock check pass, and Variable
> +  driver can store the variable data.
> +  @retval  EFI_INVALID_PARAMETER  The MOR/MorLock data or data size or
> +  attributes is not allowed for MOR variable.
> +  @retval  EFI_ACCESS_DENIED  The MOR/MorLock is locked.
> +  @retval  EFI_ALREADY_STARTEDThe MorLock variable is handled inside this
> +  function. Variable driver can just return
> +  EFI_SUCCESS.
> +**/
> +EFI_STATUS
> +SetVariableCheckHandlerMor (
> +  IN CHAR16 *VariableName,
> +  IN EFI_GUID   *VendorGuid,
> +  IN UINT32 Attributes,
> +  IN UINTN  DataSize,
> +  IN VOID   *Data
> +  );
> +
>  #endif
> diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c 
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
> index c32eb3b1ac4b..ab3e5d416cd4 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockDxe.c
> @@ -28,19 +28,23 @@ extern EDKII_VARIABLE_LOCK_PROTOCOL mVariableLock;
>  /**
>This service is an MOR/MorLock checker handler for the SetVariable().
>  
> -  @param  VariableName the name of the vendor's variable, as a
> -   Null-Terminated Unicode String
> -  @param  VendorGuid   Unify identifier for vendor.
> -  @param  Attributes   Point to memory location to return the a

Re: [edk2] [PATCH] MdeModulePkg/PciHostBridgeDxe: Fixed PCI DMA Map/Umap bounce buffer

[Ard Biesheuvel]

On 9 October 2017 at 11:40, Ard Biesheuvel  wrote:
> On 9 October 2017 at 08:42, Ni, Ruiyu  wrote:
>> The "read"/"write" is from the Bus Master's point of view.
>>
>>
>> Thanks/Ray
>>
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>>> Daniil
>>> Egranov
>>> Sent: Monday, October 9, 2017 9:16 AM
>>> To: edk2-devel@lists.01.org
>>> Cc: leif.lindh...@linaro.org; Zeng, Star ;
>>> ard.biesheu...@linaro.org
>>> Subject: [edk2] [PATCH] MdeModulePkg/PciHostBridgeDxe: Fixed PCI DMA
>>> Map/Umap bounce buffer
>>>
>>> The patch corrects the logic of transferring data between a bounce buffer 
>>> and a
>>> real buffer above 4GB:
>>> 1. In the case of mapping a bounce buffer for the write operation, data 
>>> from a
>>> real buffer should be copied into a bounce buffer.
>>> 2.In the case of unmapping a bounce buffer for the read operation, data 
>>> should
>>> be copied from a bounce buffer into a real buffer.
>>>
>>> The patch resolves a Juno board issue with the the grub and SATA drives.
>>>
>
> I am intrigued by this.
>
> So as I suggested, this has to do with 64-bit DMA, but not in the way
> I suspected. UEFI itself never hits this code path, because it runs
> entirely < 32 GB, but as soon as GRUB starts allocating loader data
> and use it for DMA, the bounce buffering kicks in because apparently,
> the SATA controller is not 64-bit DMA capable.
>
> Are you using the SataSiI3132Dxe driver on Juno? Does this help at all?
>
> diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
> b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
> index 2fb5fd68db01..a938563ebdd6 100644
> --- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
> +++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
> @@ -104,7 +104,7 @@ SiI3132AtaPassThruCommand (
>  }
>
>  Status = PciIo->Map (
> -   PciIo, EfiPciIoOperationBusMasterRead,
> +   PciIo, EfiPciIoOperationBusMasterWrite,
> Packet->InDataBuffer, &InDataBufferLength,
> &PhysInDataBuffer, &PciAllocMapping
> );
>  if (EFI_ERROR (Status)) {
> @@ -139,7 +139,7 @@ SiI3132AtaPassThruCommand (
>  OutDataBufferLength = Packet->OutTransferLength * SataDevice->BlockSize;
>
>  Status = PciIo->Map (
> -   PciIo, EfiPciIoOperationBusMasterWrite,
> +   PciIo, EfiPciIoOperationBusMasterRead,
> Packet->OutDataBuffer, &OutDataBufferLength,
> &PhysOutDataBuffer, &PciAllocMapping
> );
>  if (EFI_ERROR (Status)) {

Also, it might make sense to find out if the hardware is really not
64-bit DMA capable, or whether the driver simply fails to set the
EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE attribute.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/2] Add FPDT Acpi table

[Leif Lindholm]

On Fri, Sep 22, 2017 at 05:18:05PM +0100, evan.ll...@arm.com wrote:
> From: EvanLloyd 
> Paired patches for edk2 and edk2-platforms that add an FPDT
> acpi table.
> This is useful for monitoring firmware performance, etc.

With Graeme's Reviewed-by, I'm happy with thise series.
However, can you confirm your intent was to submit this series
under Tianocore Contribution Agreement 1.1?

I can fold that in when pushing.

Regards,

Leif

> Alexei Fedorov (1):
>   ArmPlatformPkg: Store initial timer value
> 
>  ArmPlatformPkg/PrePi/PeiMPCore.inf  |  3 ++-
>  ArmPlatformPkg/PrePi/PeiUniCore.inf |  3 ++-
>  ArmPlatformPkg/PrePi/PrePi.c| 10 +-
>  3 files changed, 13 insertions(+), 3 deletions(-)
> 
> See https://github.com/EvanLloyd/tianocore/tree/164_FPDT_v1
> 
> Alexei Fedorov (1):
>   ARM/JunoPkg: Add support for FPDT table.
> 
>  Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 9 -
>  Platform/ARM/JunoPkg/ArmJuno.dsc | 9 +
>  Platform/ARM/JunoPkg/ArmJuno.fdf | 6 ++
>  3 files changed, 23 insertions(+), 1 deletion(-)
> 
> See https://github.com/EvanLloyd/edk2-platforms/tree/164_FPDT_v1
> 
> -- 
> Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/PciHostBridgeDxe: Fixed PCI DMA Map/Umap bounce buffer

[Ard Biesheuvel]

On 9 October 2017 at 08:42, Ni, Ruiyu  wrote:
> The "read"/"write" is from the Bus Master's point of view.
>
>
> Thanks/Ray
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Daniil
>> Egranov
>> Sent: Monday, October 9, 2017 9:16 AM
>> To: edk2-devel@lists.01.org
>> Cc: leif.lindh...@linaro.org; Zeng, Star ;
>> ard.biesheu...@linaro.org
>> Subject: [edk2] [PATCH] MdeModulePkg/PciHostBridgeDxe: Fixed PCI DMA
>> Map/Umap bounce buffer
>>
>> The patch corrects the logic of transferring data between a bounce buffer 
>> and a
>> real buffer above 4GB:
>> 1. In the case of mapping a bounce buffer for the write operation, data from 
>> a
>> real buffer should be copied into a bounce buffer.
>> 2.In the case of unmapping a bounce buffer for the read operation, data 
>> should
>> be copied from a bounce buffer into a real buffer.
>>
>> The patch resolves a Juno board issue with the the grub and SATA drives.
>>

I am intrigued by this.

So as I suggested, this has to do with 64-bit DMA, but not in the way
I suspected. UEFI itself never hits this code path, because it runs
entirely < 32 GB, but as soon as GRUB starts allocating loader data
and use it for DMA, the bounce buffering kicks in because apparently,
the SATA controller is not 64-bit DMA capable.

Are you using the SataSiI3132Dxe driver on Juno? Does this help at all?

diff --git a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
index 2fb5fd68db01..a938563ebdd6 100644
--- a/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
+++ b/EmbeddedPkg/Drivers/SataSiI3132Dxe/SiI3132AtaPassThru.c
@@ -104,7 +104,7 @@ SiI3132AtaPassThruCommand (
 }

 Status = PciIo->Map (
-   PciIo, EfiPciIoOperationBusMasterRead,
+   PciIo, EfiPciIoOperationBusMasterWrite,
Packet->InDataBuffer, &InDataBufferLength,
&PhysInDataBuffer, &PciAllocMapping
);
 if (EFI_ERROR (Status)) {
@@ -139,7 +139,7 @@ SiI3132AtaPassThruCommand (
 OutDataBufferLength = Packet->OutTransferLength * SataDevice->BlockSize;

 Status = PciIo->Map (
-   PciIo, EfiPciIoOperationBusMasterWrite,
+   PciIo, EfiPciIoOperationBusMasterRead,
Packet->OutDataBuffer, &OutDataBufferLength,
&PhysOutDataBuffer, &PciAllocMapping
);
 if (EFI_ERROR (Status)) {
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/2] Add FPDT Acpi table

[Graeme Gregory]

On 22 September 2017 at 17:18,   wrote:
> From: EvanLloyd 
>
>
> Paired patches for edk2 and edk2-platforms that add an FPDT
> acpi table.
> This is useful for monitoring firmware performance, etc.
>
>From ACPI on ARM point of view this looks fine to me.

Reviewed-by: Graeme Gregory 

>
> Alexei Fedorov (1):
>   ArmPlatformPkg: Store initial timer value
>
>  ArmPlatformPkg/PrePi/PeiMPCore.inf  |  3 ++-
>  ArmPlatformPkg/PrePi/PeiUniCore.inf |  3 ++-
>  ArmPlatformPkg/PrePi/PrePi.c| 10 +-
>  3 files changed, 13 insertions(+), 3 deletions(-)
>
> See https://github.com/EvanLloyd/tianocore/tree/164_FPDT_v1
>
> Alexei Fedorov (1):
>   ARM/JunoPkg: Add support for FPDT table.
>
>  Platform/ARM/VExpressPkg/ArmVExpress.dsc.inc | 9 -
>  Platform/ARM/JunoPkg/ArmJuno.dsc | 9 +
>  Platform/ARM/JunoPkg/ArmJuno.fdf | 6 ++
>  3 files changed, 23 insertions(+), 1 deletion(-)
>
> See https://github.com/EvanLloyd/edk2-platforms/tree/164_FPDT_v1
>
> --
> Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 1/2] ArmPkg/Include: Add standard SMC function IDs for MM interface.

[Achin Gupta]

Hi Ard/Supreeth,

On Fri, Oct 06, 2017 at 10:05:46PM +0100, Ard Biesheuvel wrote:
> On 27 September 2017 at 19:58, Supreeth Venkatesh
>  wrote:
> > This patch adds a list of function IDs that fall under the standard
> > SMC range as defined in
> > http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf.
> >
> > SMCs associated with Management Mode are in the range 0xC440 -
> > 0xC45f (64 bit) and 0x8440 - 0x845f (32 bit).
> >
> > The function(s) available to the normal world:
> > 1. Request services from the secure MM environment using MM_COMMUNICATE.
> >
> > It also defines MM return codes.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Achin Gupta 
> > Signed-off-by: Supreeth Venkatesh 
>
> Both patches applied. Thanks.

I should have spotted this earlier but the following define is not
spec. compliant. It says:

> +#define ARM_SMC_MM_RET_NO_MEMORY   -4

but should be

> +#define ARM_SMC_MM_RET_NO_MEMORY   -5

Supreeth. Could you please submit a patch to rectify this?

cheers,
Achin

>
> > ---
> >  ArmPkg/Include/IndustryStandard/ArmStdSmc.h | 20 +++-
> >  1 file changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h 
> > b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> > index 593a3ce729..37d0796649 100644
> > --- a/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> > +++ b/ArmPkg/Include/IndustryStandard/ArmStdSmc.h
> > @@ -1,6 +1,6 @@
> >  /** @file
> >  *
> > -*  Copyright (c) 2012-2014, ARM Limited. All rights reserved.
> > +*  Copyright (c) 2012-2017, ARM Limited. All rights reserved.
> >  *
> >  *  This program and the accompanying materials
> >  *  are licensed and made available under the terms and conditions of the 
> > BSD License
> > @@ -40,6 +40,24 @@
> >  #define ARM_SMC_STD_REVISION_MAJOR0x0
> >  #define ARM_SMC_STD_REVISION_MINOR0x1
> >
> > +/*
> > + * Management Mode (MM) calls cover a subset of the Standard Service Call 
> > range.
> > + * The list below is not exhaustive.
> > + */
> > +#define ARM_SMC_ID_MM_VERSION_AARCH32  0x8440
> > +#define ARM_SMC_ID_MM_VERSION_AARCH64  0xC440
> > +
> > +// Request service from secure standalone MM environment
> > +#define ARM_SMC_ID_MM_COMMUNICATE_AARCH32  0x8441
> > +#define ARM_SMC_ID_MM_COMMUNICATE_AARCH64  0xC441
> > +
> > +/* MM return error codes */
> > +#define ARM_SMC_MM_RET_SUCCESS  0
> > +#define ARM_SMC_MM_RET_NOT_SUPPORTED   -1
> > +#define ARM_SMC_MM_RET_INVALID_PARAMS  -2
> > +#define ARM_SMC_MM_RET_DENIED  -3
> > +#define ARM_SMC_MM_RET_NO_MEMORY   -4
> > +
> >  /*
> >   * Power State Coordination Interface (PSCI) calls cover a subset of the
> >   * Standard Service Call range.
> > --
> > 2.14.1
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] SecurityPkg\Tcg2Pei: FV measure performance enhancement

[Zhang, Chao B]

1. Leverage Pre-Hashed FV PPI to reduce duplicated hash
2. Only measure BFV at the beginning. Other FVs are measured in FVinfo callback 
with nested
   FV check. https://bugzilla.tianocore.org/show_bug.cgi?id=662

Cc: Long Qin 
Cc: Yao Jiewen 
Cc: Sean Brogan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang 
---
 .../Include/Ppi/FirmwareVolumeInfoPrehashedFV.h|  70 ++
 SecurityPkg/SecurityPkg.dec|   7 +-
 SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.c  | 245 +++--
 SecurityPkg/Tcg/Tcg2Pei/Tcg2Pei.inf|   2 +
 4 files changed, 250 insertions(+), 74 deletions(-)
 create mode 100644 SecurityPkg/Include/Ppi/FirmwareVolumeInfoPrehashedFV.h

diff --git a/SecurityPkg/Include/Ppi/FirmwareVolumeInfoPrehashedFV.h 
b/SecurityPkg/Include/Ppi/FirmwareVolumeInfoPrehashedFV.h
new file mode 100644
index 000..2273357
--- /dev/null
+++ b/SecurityPkg/Include/Ppi/FirmwareVolumeInfoPrehashedFV.h
@@ -0,0 +1,70 @@
+/** @file
+PPI to describe all hash digests for a given FV
+
+Copyright (c) 2017, Intel Corporation. All rights reserved.
+This program and the accompanying materials
+are licensed and made available under the terms and conditions of the BSD 
License
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+/**
+PPI to describe all hash digests for a given FV
+
+Copyright (c) 2017, Microsoft Corporation
+
+All rights reserved.
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+1. Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+2. 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.
+
+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 HOLDER 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.
+
+**/
+
+#ifndef __PEI_FIRMWARE_VOLUME_INFO_PREHASHED_FV_H__
+#define __PEI_FIRMWARE_VOLUME_INFO_PREHASHED_FV_H__
+
+#define EDKII_PEI_FIRMWARE_VOLUME_INFO_PREHASHED_FV_PPI_GUID \
+ { 0x3ce1e631, 0x7008, 0x477c, { 0xad, 0xa7, 0x5d, 0xcf, 0xc7, 0xc1, 0x49, 
0x4b } }
+
+//
+// HashAlgoId is TPM_ALG_ID in Tpm20.h
+//
+typedef struct _HASH_INFO {
+  UINT16 HashAlgoId;
+  UINT16 HashSize;
+  //UINT8Hash[];
+} HASH_INFO;
+
+//
+// This PPI indicates a FV is already hashed, platform should ensure 1:1 
mapping between pre-hashed PPI and FV.
+// The Count field in PPI is followed by Count number of FV hash info entries, 
which can be extended to PCR and logged to TCG event log directly by TCG 
modules.
+//
+typedef struct {
+  UINT32 FvBase;
+  UINT32 FvLength;
+  UINT32 Count;
+  //HASH_INFOHashInfo[];
+} EDKII_PEI_FIRMWARE_VOLUME_INFO_PREHASHED_FV_PPI;
+
+extern EFI_GUID gEdkiiPeiFirmwareVolumeInfoPrehashedFvPpiGuid;
+
+#endif
+
diff --git a/SecurityPkg/SecurityPkg.dec b/SecurityPkg/SecurityPkg.dec
index 7a900dc..45d95c5 100644
--- a/SecurityPkg/SecurityPkg.dec
+++ b/SecurityPkg/SecurityPkg.dec
@@ -7,6 +7,7 @@
 #
 # Copyright (c) 2009 - 2017, Intel Corporation. All rights reserved.
 # (C) Copyright 2015 Hewlett Packard Enterprise Development LP 
+# Copyright (c) 2017, Microsoft Corporation.  All rights reserved. 
 # This program and the accompanying materials are licensed and made available 
under
 # the terms and conditions of the BSD License which accompanies this 
distribution.
 # The full text of the license may be found at
@@ -222,6 +223,9 @@
   ## Include/Ppi/FirmwareVolumeInfoMeasurementExcluded.h
   gEfiPeiFirmwareVolumeInfoMeasurementExcludedPpiGuid = { 0x6e056ff9, 0xc695, 
0x4364, { 0x9e, 0x2c, 0x61, 0x26, 0xf5, 0xce, 0xea, 0xae } }
 
+  ## Include/Ppi/FirmwareVolumeInfoPrehashedFV.h
+

Re: [edk2] [Patch] BaseTools: Fix a bug to use module's Name attribute as compare

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: Zhu, Yonghong
>Sent: Monday, October 09, 2017 4:14 PM
>To: edk2-devel@lists.01.org
>Cc: Gao, Liming 
>Subject: [Patch] BaseTools: Fix a bug to use module's Name attribute as
>compare
>
>Fix a bug to use module's Name attribute as compare for single module
>build. ModuleFile.File can't be used to compare INF file, because it
>is the relative path.
>
>Cc: Liming Gao 
>Contributed-under: TianoCore Contribution Agreement 1.1
>Signed-off-by: Yonghong Zhu 
>---
> BaseTools/Source/Python/build/build.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/BaseTools/Source/Python/build/build.py
>b/BaseTools/Source/Python/build/build.py
>index 13d8e50..a3bb632 100644
>--- a/BaseTools/Source/Python/build/build.py
>+++ b/BaseTools/Source/Python/build/build.py
>@@ -1827,11 +1827,11 @@ class Build():
> for Arch in Wa.ArchList:
> AutoGenStart = time.time()
> GlobalData.gGlobalDefines['ARCH'] = Arch
> Pa = PlatformAutoGen(Wa, self.PlatformFile, BuildTarget, 
> ToolChain,
>Arch)
> for Module in Pa.Platform.Modules:
>-if self.ModuleFile.Dir == Module.Dir and 
>self.ModuleFile.File ==
>Module.File:
>+if self.ModuleFile.Dir == Module.Dir and 
>self.ModuleFile.Name
>== Module.Name:
> Ma = ModuleAutoGen(Wa, Module, BuildTarget, 
> ToolChain,
>Arch, self.PlatformFile)
> if Ma == None: continue
> # Not to auto-gen for targets 'clean', 
> 'cleanlib', 'cleanall', 'run',
>'fds'
> if self.Target not in ['clean', 'cleanlib', 
> 'cleanall', 'run', 'fds']:
> # for target which must generate AutoGen code 
> and makefile
>--
>2.6.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch] BaseTools: Fix a bug to use module's Name attribute as compare

[Yonghong Zhu]

Fix a bug to use module's Name attribute as compare for single module
build. ModuleFile.File can't be used to compare INF file, because it
is the relative path.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/build/build.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/build/build.py 
b/BaseTools/Source/Python/build/build.py
index 13d8e50..a3bb632 100644
--- a/BaseTools/Source/Python/build/build.py
+++ b/BaseTools/Source/Python/build/build.py
@@ -1827,11 +1827,11 @@ class Build():
 for Arch in Wa.ArchList:
 AutoGenStart = time.time()
 GlobalData.gGlobalDefines['ARCH'] = Arch
 Pa = PlatformAutoGen(Wa, self.PlatformFile, BuildTarget, 
ToolChain, Arch)
 for Module in Pa.Platform.Modules:
-if self.ModuleFile.Dir == Module.Dir and 
self.ModuleFile.File == Module.File:
+if self.ModuleFile.Dir == Module.Dir and 
self.ModuleFile.Name == Module.Name:
 Ma = ModuleAutoGen(Wa, Module, BuildTarget, 
ToolChain, Arch, self.PlatformFile)
 if Ma == None: continue
 # Not to auto-gen for targets 'clean', 'cleanlib', 
'cleanall', 'run', 'fds'
 if self.Target not in ['clean', 'cleanlib', 
'cleanall', 'run', 'fds']:
 # for target which must generate AutoGen code 
and 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] MdePkg: Add definitions for ACPI 6.2

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: Zeng, Star
>Sent: Saturday, September 30, 2017 11:11 PM
>To: edk2-devel@lists.01.org
>Cc: Zeng, Star ; Yao, Jiewen ;
>Gao, Liming 
>Subject: [PATCH] MdePkg: Add definitions for ACPI 6.2
>
>Cc: Jiewen Yao 
>Cc: Liming Gao 
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Star Zeng 
>---
> MdePkg/Include/IndustryStandard/Acpi.h   |4 +-
> MdePkg/Include/IndustryStandard/Acpi62.h | 2942
>++
> 2 files changed, 2944 insertions(+), 2 deletions(-)
> create mode 100644 MdePkg/Include/IndustryStandard/Acpi62.h
>
>diff --git a/MdePkg/Include/IndustryStandard/Acpi.h
>b/MdePkg/Include/IndustryStandard/Acpi.h
>index ad8504a98f4f..7a26da5379aa 100644
>--- a/MdePkg/Include/IndustryStandard/Acpi.h
>+++ b/MdePkg/Include/IndustryStandard/Acpi.h
>@@ -2,7 +2,7 @@
>   This file contains the latest ACPI definitions that are
>   consumed by drivers that do not care about ACPI versions.
>
>-  Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
>+  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
>   This program and the accompanying materials
>   are licensed and made available under the terms and conditions of the BSD
>License
>   which accompanies this distribution.  The full text of the license may be
>found at
>@@ -16,6 +16,6 @@
> #ifndef _ACPI_H_
> #define _ACPI_H_
>
>-#include 
>+#include 
>
> #endif
>diff --git a/MdePkg/Include/IndustryStandard/Acpi62.h
>b/MdePkg/Include/IndustryStandard/Acpi62.h
>new file mode 100644
>index ..82d1425164ac
>--- /dev/null
>+++ b/MdePkg/Include/IndustryStandard/Acpi62.h
>@@ -0,0 +1,2942 @@
>+/** @file
>+  ACPI 6.2 definitions from the ACPI Specification Revision 6.2 May, 2017.
>+
>+  Copyright (c) 2017, Intel Corporation. All rights reserved.
>+  This program and the accompanying materials
>+  are licensed and made available under the terms and conditions of the BSD
>License
>+  which accompanies this distribution.  The full text of the license may be
>found at
>+  http://opensource.org/licenses/bsd-license.php
>+
>+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
>BASIS,
>+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
>EXPRESS OR IMPLIED.
>+**/
>+
>+#ifndef _ACPI_6_2_H_
>+#define _ACPI_6_2_H_
>+
>+#include 
>+
>+//
>+// Large Item Descriptor Name
>+//
>+#define ACPI_LARGE_PIN_FUNCTION_DESCRIPTOR_NAME  0x0D
>+#define ACPI_LARGE_PIN_CONFIGURATION_DESCRIPTOR_NAME 0x0F
>+#define ACPI_LARGE_PIN_GROUP_DESCRIPTOR_NAME 0x10
>+#define ACPI_LARGE_PIN_GROUP_FUNCTION_DESCRIPTOR_NAME
>0x11
>+#define ACPI_LARGE_PIN_GROUP_CONFIGURATION_DESCRIPTOR_NAME
>0x12
>+
>+//
>+// Large Item Descriptor Value
>+//
>+#define ACPI_PIN_FUNCTION_DESCRIPTOR 0x8D
>+#define ACPI_PIN_CONFIGURATION_DESCRIPTOR0x8F
>+#define ACPI_PIN_GROUP_DESCRIPTOR0x90
>+#define ACPI_PIN_GROUP_FUNCTION_DESCRIPTOR   0x91
>+#define ACPI_PIN_GROUP_CONFIGURATION_DESCRIPTOR  0x92
>+
>+#pragma pack(1)
>+
>+///
>+/// Pin Function Descriptor
>+///
>+typedef PACKED struct {
>+  ACPI_LARGE_RESOURCE_HEADERHeader;
>+  UINT8 RevisionId;
>+  UINT16Flags;
>+  UINT8 PinPullConfiguration;
>+  UINT16FunctionNumber;
>+  UINT16PinTableOffset;
>+  UINT8 ResourceSourceIndex;
>+  UINT16ResourceSourceNameOffset;
>+  UINT16VendorDataOffset;
>+  UINT16VendorDataLength;
>+} EFI_ACPI_PIN_FUNCTION_DESCRIPTOR;
>+
>+///
>+/// Pin Configuration Descriptor
>+///
>+typedef PACKED struct {
>+  ACPI_LARGE_RESOURCE_HEADERHeader;
>+  UINT8 RevisionId;
>+  UINT16Flags;
>+  UINT8 PinConfigurationType;
>+  UINT32PinConfigurationValue;
>+  UINT16PinTableOffset;
>+  UINT8 ResourceSourceIndex;
>+  UINT16ResourceSourceNameOffset;
>+  UINT16VendorDataOffset;
>+  UINT16VendorDataLength;
>+} EFI_ACPI_PIN_CONFIGURATION_DESCRIPTOR;
>+
>+///
>+/// Pin Group Descriptor
>+///
>+typedef PACKED struct {
>+  ACPI_LARGE_RESOURCE_HEADERHeader;
>+  UINT8 RevisionId;
>+  UINT16Flags;
>+  UINT16PinTableOffset;
>+  UINT16ResourceLabelOffset;
>+  UINT16VendorDataOffset;
>+  UINT16VendorDataLength;
>+} EFI_ACPI_PIN_GROUP_DESCRIPTOR;
>+
>+///
>+/// Pin Group Function Descriptor
>+///
>+typedef PACKED struct {
>+  ACPI_LARGE_RESOURCE_HEADERHeader;
>+  UINT8 RevisionId;
>+  UINT16   

Re: [edk2] [PATCH 0/5] Propagate PEI-phase FV authentication status to DXE

[Gao, Liming]

Reviewed-by: Liming Gao 

>-Original Message-
>From: Zeng, Star
>Sent: Wednesday, October 04, 2017 10:21 PM
>To: edk2-devel@lists.01.org
>Cc: Zeng, Star ; Gao, Liming 
>Subject: [PATCH 0/5] Propagate PEI-phase FV authentication status to DXE
>
>FV3 HOB was introduced by new (>= 1.5) PI spec, it is intended to
>be used to propagate PEI-phase FV authentication status to DXE.
>Check the separated patches for the details.
>
>
>Cc: Liming Gao 
>
>Star Zeng (5):
>  MdePkg PiHob.h: Add FV3 HOB definitions
>  MdePkg HobLib: Add BuildFv3Hob API
>  IntelFrameworkPkg PeiHobLibFramework: Implement BuildFv3Hob
>  MdeModulePkg Core: Propagate PEI-phase FV authentication status to DXE
>  IntelFrameworkModulePkg FwVolDxe: Get FV auth status propagated from
>PEI
>
> .../Universal/FirmwareVolume/FwVolDxe/FwVol.c  | 73
>--
> .../FirmwareVolume/FwVolDxe/FwVolDriver.h  |  3 +-
> .../Universal/FirmwareVolume/FwVolDxe/FwVolDxe.inf |  4 +-
> .../Library/PeiHobLibFramework/HobLib.c| 54 +++-
> MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c| 41 ++--
> MdeModulePkg/Core/Dxe/FwVol/FwVol.c| 13 ++--
> MdeModulePkg/Core/Dxe/FwVolBlock/FwVolBlock.c  | 23 +--
> MdeModulePkg/Core/Pei/FwVol/FwVol.c|  9 +++
> MdePkg/Include/Library/HobLib.h| 34 +-
> MdePkg/Include/Pi/PiHob.h  | 43 -
> MdePkg/Library/DxeCoreHobLib/HobLib.c  | 35 ++-
> MdePkg/Library/DxeHobLib/HobLib.c  | 32 ++
> MdePkg/Library/PeiHobLib/HobLib.c  | 54 +++-
> 13 files changed, 371 insertions(+), 47 deletions(-)
>
>--
>2.13.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/PciHostBridgeDxe: Fixed PCI DMA Map/Umap bounce buffer

[Ni, Ruiyu]

The "read"/"write" is from the Bus Master's point of view.


Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Daniil
> Egranov
> Sent: Monday, October 9, 2017 9:16 AM
> To: edk2-devel@lists.01.org
> Cc: leif.lindh...@linaro.org; Zeng, Star ;
> ard.biesheu...@linaro.org
> Subject: [edk2] [PATCH] MdeModulePkg/PciHostBridgeDxe: Fixed PCI DMA
> Map/Umap bounce buffer
> 
> The patch corrects the logic of transferring data between a bounce buffer and 
> a
> real buffer above 4GB:
> 1. In the case of mapping a bounce buffer for the write operation, data from a
> real buffer should be copied into a bounce buffer.
> 2.In the case of unmapping a bounce buffer for the read operation, data should
> be copied from a bounce buffer into a real buffer.
> 
> The patch resolves a Juno board issue with the the grub and SATA drives.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Daniil Egranov 
> ---
>  MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> index dc06c16dc0..877fa2fd13 100644
> --- a/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> +++ b/MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciRootBridgeIo.c
> @@ -1153,12 +1153,12 @@ RootBridgeIoMap (
>  }
> 
>  //
> -// If this is a read operation from the Bus Master's point of view,
> +// If this is a write operation from the Bus Master's point of
> + view,
>  // then copy the contents of the real buffer into the mapped buffer
>  // so the Bus Master can read the contents of the real buffer.
>  //
> -if (Operation == EfiPciOperationBusMasterRead ||
> -Operation == EfiPciOperationBusMasterRead64) {
> +if (Operation == EfiPciOperationBusMasterWrite ||
> +Operation == EfiPciOperationBusMasterWrite64) {
>CopyMem (
>  (VOID *) (UINTN) MapInfo->MappedHostAddress,
>  (VOID *) (UINTN) MapInfo->HostAddress, @@ -1256,12 +1256,12 @@
> RootBridgeIoUnmap (
>RemoveEntryList (&MapInfo->Link);
> 
>//
> -  // If this is a write operation from the Bus Master's point of view,
> +  // If this is a read operation from the Bus Master's point of view,
>// then copy the contents of the mapped buffer into the real buffer
>// so the processor can read the contents of the real buffer.
>//
> -  if (MapInfo->Operation == EfiPciOperationBusMasterWrite ||
> -  MapInfo->Operation == EfiPciOperationBusMasterWrite64) {
> +  if (MapInfo->Operation == EfiPciOperationBusMasterRead ||
> +  MapInfo->Operation == EfiPciOperationBusMasterRead64) {
>  CopyMem (
>(VOID *) (UINTN) MapInfo->HostAddress,
>(VOID *) (UINTN) MapInfo->MappedHostAddress,
> --
> 2.11.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] MdeModulePkg/S3SaveState: Extract arguments in correct order

[Zeng, Star]

Reviewed-by: Star Zeng 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni
Sent: Monday, October 9, 2017 3:13 PM
To: edk2-devel@lists.01.org
Cc: Zeng, Star 
Subject: [edk2] [PATCH] MdeModulePkg/S3SaveState: Extract arguments in correct 
order

EFI_BOOT_SCRIPT_WRITE() interface is a var-arg interface.

Spec defines the order of parameters for 
EFI_BOOT_SCRIPT_PCI_CONFIG2_WRITE_OPCODE as below:

  typedef
  EFI_STATUS
  (EFIAPI *EFI_BOOT_SCRIPT_WRITE) (
IN CONST EFI_S3_SAVE_STATE_PROTOCOL *This,
IN UINT16 OpCode,
IN EFI_BOOT_SCRIPT_WIDTH Width,
IN UINT16 Segment,
IN UINT64 Address,
IN UINTN Count,
IN VOID *Buffer
  );

But implementation assumes Segment is in the very end, after Buffer.
Similar spec/implementation gaps are also found for 
EFI_BOOT_SCRIPT_PCI_CONFIG2_READ_WRITE_OPCODE.

The patch fixes the implementation to extract the arguments in correct order.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Star Zeng 
---
 MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c| 6 +++---
 MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c 
b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
index efc0ef9140..d73005156c 100644
--- a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
+++ b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
@@ -1,7 +1,7 @@
 /** @file
   Implementation for S3 Boot Script Saver state driver.
 
-  Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2017, Intel Corporation. All rights 
+ reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions @@ -210,10 
+210,10 @@ BootScriptWritePciCfg2Write (
   UINT16Segment;
 
   Width   = VA_ARG (Marker, S3_BOOT_SCRIPT_LIB_WIDTH);
+  Segment = VA_ARG (Marker, UINT16);
   Address = VA_ARG (Marker, UINT64);
   Count   = VA_ARG (Marker, UINTN);
   Buffer  = VA_ARG (Marker, UINT8 *);
-  Segment = VA_ARG (Marker, UINT16);
 
   return S3BootScriptSavePciCfg2Write (Width, Segment, Address, Count, 
Buffer);  } @@ -240,8 +240,8 @@ BootScriptWritePciCfg2ReadWrite (
   UINT8 *DataMask;
  
   Width   = VA_ARG (Marker, S3_BOOT_SCRIPT_LIB_WIDTH);
-  Address = VA_ARG (Marker, UINT64);
   Segment = VA_ARG (Marker, UINT16);
+  Address = VA_ARG (Marker, UINT64);
   Data= VA_ARG (Marker, UINT8 *);
   DataMask= VA_ARG (Marker, UINT8 *);
  
diff --git a/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c 
b/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
index 0d1580dc35..f397db37fd 100644
--- a/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
+++ b/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
@@ -1,7 +1,7 @@
 /** @file
   Implementation for S3 SMM Boot Script Saver state driver.
 
-  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2017, Intel Corporation. All rights 
+ reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions @@ -209,10 
+209,10 @@ BootScriptWritePciCfg2Write (
   UINT16Segment;
 
   Width   = VA_ARG (Marker, S3_BOOT_SCRIPT_LIB_WIDTH);
+  Segment = VA_ARG (Marker, UINT16);
   Address = VA_ARG (Marker, UINT64);
   Count   = VA_ARG (Marker, UINTN);
   Buffer  = VA_ARG (Marker, UINT8 *);
-  Segment = VA_ARG (Marker, UINT16);
 
   return S3BootScriptSavePciCfg2Write (Width, Segment, Address, Count, 
Buffer);  } @@ -239,8 +239,8 @@ BootScriptWritePciCfg2ReadWrite (
   UINT8 *DataMask;
  
   Width   = VA_ARG (Marker, S3_BOOT_SCRIPT_LIB_WIDTH);
-  Address = VA_ARG (Marker, UINT64);
   Segment = VA_ARG (Marker, UINT16);
+  Address = VA_ARG (Marker, UINT64);
   Data= VA_ARG (Marker, UINT8 *);
   DataMask= VA_ARG (Marker, UINT8 *);
  
--
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 v1] MdePkg: Add definitions for the SPI protocols introduced in UEFI PI 1.6.

[Bi, Dandan]

Hi Marvin,

I have reviewed the remaining parts.
Here are the comments:
1. There is a typo in LegacySpiFlash.h
Typo:
#ifndef __SPI_CONFIGURATION_PROTOCOL_H__
#define __SPI_CONFIGURATION_PROTOCOL_H__
   The token __SPI_CONFIGURATION_PROTOCOL_H__ in LegacySpiFlash.h in duplicated 
with the one in SpiConfiguration.h, please update it.

2.  The type EFI_SPI_NOR_FLASH_PROTOCOL_LF_READ_DATA in SpiNorFlash.h is not 
used,  and it's also not defined in Spec, we may remove it.
  (1)typedef
   EFI_STATUS
   (EFIAPI *EFI_SPI_NOR_FLASH_PROTOCOL_LF_READ_DATA) (
 IN  CONST EFI_SPI_NOR_FLASH_PROTOCOL  *This,
 IN  UINT32FlashAddress,
 IN  UINT32LengthInBytes,
 OUT UINT8 *Buffer
 );
   ///
   /// Low frequency read data from the SPI flash.
   /// 
   EFI_SPI_NOR_FLASH_PROTOCOL_READ_DATALfReadData;

3. You could use patch check tool in BaseTools/Scripts/PatchCheck.py to verify 
the format of your updates.


Thanks,
Dandan

-Original Message-
From: Bi, Dandan 
Sent: Friday, September 15, 2017 4:22 PM
To: Ni, Ruiyu ; Marvin Häuser ; 
edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Gao, Liming 

Subject: RE: [PATCH v1] MdePkg: Add definitions for the SPI protocols 
introduced in UEFI PI 1.6.

Hi Marvin,

Thank you for your contribution. I am reviewing this patch now. Currently I 
just take a look at the SMM SPI part and find:

1. There is a typo in LegacySpiSmmController.h
The definition should be EFI_LEGACY_SPI_SMM_CONTROLLER_GUID, not 
EFI_LEGACY_SPI_SMM_FLASH_PROTOCOL_GUID.
Typo:
#define EFI_LEGACY_SPI_SMM_FLASH_PROTOCOL_GUID  \
  { 0x62331b78, 0xd8d0, 0x4c8c, \
{ 0x8c, 0xcb, 0xd2, 0x7d, 0xfe, 0x32, 0xdb, 0x9b }}
And it should  be:
#define EFI_LEGACY_SPI_SMM_CONTROLLER_GUID \
{ 0x62331b78, 0xd8d0, 0x4c8c, { 0x8c, 0xcb, 0xd2, 0x7d, \ 0xfe, 0x32, 0xdb, 
0x9b }}

2. EFI_SPI_SMM_NOR_FLASH_PROTOCOL definition seems to be missing.

I will review the remaining part. It may take some time. Sorry for the delay in 
my response

Thanks,
Dandan

-Original Message-
From: Ni, Ruiyu 
Sent: Thursday, September 7, 2017 3:13 PM
To: Marvin Häuser ; edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Gao, Liming 
; Bi, Dandan 
Subject: RE: [PATCH v1] MdePkg: Add definitions for the SPI protocols 
introduced in UEFI PI 1.6.

Marvin,
Thank you for your contribution. We will need some time to review the 
definitions against PI Spec.
If there is a need to post V2, it might be better to separate the header files 
in different groups.
For example, LegacySpi group, SPI group, SMM SPI group.

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Marvin Häuser
> Sent: Wednesday, September 6, 2017 5:21 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Gao, Liming
> 
> Subject: [edk2] [PATCH v1] MdePkg: Add definitions for the SPI protocols
> introduced in UEFI PI 1.6.
> 
> This commit adds header files for the SPI protocols introduced in the
> UEFI PI 1.6 specification, as well as their GUIDs to MdePkg.dec.
> 
> EFI_SPI_TRANSACTION_TYPE assumes an enum with its members ordered
> the
> way they are listed in the specification, as there are no values given
> explicitely.
> EFI_LEGACY_SPI_CONTROLLER_GUID assumes the character 'l' used in the
> specification was meant to be '1'.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marvin Haeuser 
> ---
>  MdePkg/Include/Protocol/LegacySpiController.h| 265
> ++
>  MdePkg/Include/Protocol/LegacySpiFlash.h | 201 ++
>  MdePkg/Include/Protocol/LegacySpiSmmController.h |  36 +++
>  MdePkg/Include/Protocol/LegacySpiSmmFlash.h  |  36 +++
>  MdePkg/Include/Protocol/SpiConfiguration.h   | 293
> 
>  MdePkg/Include/Protocol/SpiHc.h  | 194 +
>  MdePkg/Include/Protocol/SpiIo.h  | 292 +++
>  MdePkg/Include/Protocol/SpiNorFlash.h| 289
> +++
>  MdePkg/Include/Protocol/SpiSmmConfiguration.h|  36 +++
>  MdePkg/Include/Protocol/SpiSmmHc.h   |  36 +++
>  MdePkg/MdePkg.dec|  31 +++
>  11 files changed, 1709 insertions(+)
> 
> diff --git a/MdePkg/Include/Protocol/LegacySpiController.h
> b/MdePkg/Include/Protocol/LegacySpiController.h
> new file mode 100644
> index ..2d36eaefc0ee
> --- /dev/null
> +++ b/MdePkg/Include/Protocol/LegacySpiController.h
> @@ -0,0 +1,265 @@
> +/** @file
> +  This file defines the Legacy SPI Controller Protocol.
> +
> +  Copyright (c) 2017, Intel Corporation. All rights reserved.
> +  This program and the accompanying materials
> +  are licensed and made available under the terms and conditions of the BSD
> +  License which accompanies this distribution. The full text of the license
> may
> +  be found at http://opensource.org/licenses/bsd-license.p

[edk2] [PATCH] MdeModulePkg/S3SaveState: Extract arguments in correct order

[Ruiyu Ni]

EFI_BOOT_SCRIPT_WRITE() interface is a var-arg interface.

Spec defines the order of parameters for
EFI_BOOT_SCRIPT_PCI_CONFIG2_WRITE_OPCODE as below:

  typedef
  EFI_STATUS
  (EFIAPI *EFI_BOOT_SCRIPT_WRITE) (
IN CONST EFI_S3_SAVE_STATE_PROTOCOL *This,
IN UINT16 OpCode,
IN EFI_BOOT_SCRIPT_WIDTH Width,
IN UINT16 Segment,
IN UINT64 Address,
IN UINTN Count,
IN VOID *Buffer
  );

But implementation assumes Segment is in the very end, after Buffer.
Similar spec/implementation gaps are also found for
EFI_BOOT_SCRIPT_PCI_CONFIG2_READ_WRITE_OPCODE.

The patch fixes the implementation to extract the arguments in
correct order.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Star Zeng 
---
 MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c| 6 +++---
 MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c | 6 +++---
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c 
b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
index efc0ef9140..d73005156c 100644
--- a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
+++ b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
@@ -1,7 +1,7 @@
 /** @file
   Implementation for S3 Boot Script Saver state driver.
 
-  Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions
@@ -210,10 +210,10 @@ BootScriptWritePciCfg2Write (
   UINT16Segment;
 
   Width   = VA_ARG (Marker, S3_BOOT_SCRIPT_LIB_WIDTH);
+  Segment = VA_ARG (Marker, UINT16);
   Address = VA_ARG (Marker, UINT64);
   Count   = VA_ARG (Marker, UINTN);
   Buffer  = VA_ARG (Marker, UINT8 *);
-  Segment = VA_ARG (Marker, UINT16);
 
   return S3BootScriptSavePciCfg2Write (Width, Segment, Address, Count, Buffer);
 }
@@ -240,8 +240,8 @@ BootScriptWritePciCfg2ReadWrite (
   UINT8 *DataMask;
  
   Width   = VA_ARG (Marker, S3_BOOT_SCRIPT_LIB_WIDTH);
-  Address = VA_ARG (Marker, UINT64);
   Segment = VA_ARG (Marker, UINT16);
+  Address = VA_ARG (Marker, UINT64);
   Data= VA_ARG (Marker, UINT8 *);
   DataMask= VA_ARG (Marker, UINT8 *);
  
diff --git a/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c 
b/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
index 0d1580dc35..f397db37fd 100644
--- a/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
+++ b/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
@@ -1,7 +1,7 @@
 /** @file
   Implementation for S3 SMM Boot Script Saver state driver.
 
-  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 2017, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions
@@ -209,10 +209,10 @@ BootScriptWritePciCfg2Write (
   UINT16Segment;
 
   Width   = VA_ARG (Marker, S3_BOOT_SCRIPT_LIB_WIDTH);
+  Segment = VA_ARG (Marker, UINT16);
   Address = VA_ARG (Marker, UINT64);
   Count   = VA_ARG (Marker, UINTN);
   Buffer  = VA_ARG (Marker, UINT8 *);
-  Segment = VA_ARG (Marker, UINT16);
 
   return S3BootScriptSavePciCfg2Write (Width, Segment, Address, Count, Buffer);
 }
@@ -239,8 +239,8 @@ BootScriptWritePciCfg2ReadWrite (
   UINT8 *DataMask;
  
   Width   = VA_ARG (Marker, S3_BOOT_SCRIPT_LIB_WIDTH);
-  Address = VA_ARG (Marker, UINT64);
   Segment = VA_ARG (Marker, UINT16);
+  Address = VA_ARG (Marker, UINT64);
   Data= VA_ARG (Marker, UINT8 *);
   DataMask= VA_ARG (Marker, UINT8 *);
  
-- 
2.12.2.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and lock OS-created MOR variable

[Zeng, Star]

Laszlo,

Do you think VariableRuntimeDxe(TcgMorLockDxe.c) also needs to delete and lock 
OS-created MOR variable?


Thanks,
Star
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Wednesday, October 4, 2017 5:29 AM
To: edk2-devel-01 
Cc: Dong, Eric ; Yao, Jiewen ; Ladi 
Prosek ; Zeng, Star 
Subject: [PATCH 6/6] MdeModulePkg/Variable/RuntimeDxe: delete and lock 
OS-created MOR variable

According to the TCG Platform Reset Attack Mitigation Specification (May 15, 
2008):

> 5 Interface for UEFI
> 5.1 UEFI Variable
> 5.1.1 The MemoryOverwriteRequestControl
>
> Start of informative comment:
>
> [...] The OS loader should not create the variable. Rather, the 
> firmware is required to create it and must support the semantics described 
> here.
>
> End of informative comment.

However, some OS kernels create the MOR variable even if the platform firmware 
does not support it (see one Bugzilla reference below). This OS issue breaks 
the logic added in the last patch.

Strengthen the MOR check by searching for the TCG or TCG2 protocols, as edk2's 
implementation of MOR depends on (one of) those protocols.

The protocols are defined under MdePkg, thus there's no inter-package 
dependency issue. In addition, calling UEFI services in
MorLockInitAtEndOfDxe() is safe, due to the following order of events /
actions:

- platform BDS signals the EndOfDxe event group,
- the SMM core installs the SmmEndOfDxe protocol,
- MorLockInitAtEndOfDxe() is invoked, and it calls UEFI services,
- some time later, platform BDS installs the DxeSmmReadyToLock protocol,
- SMM / SMRAM is locked down and UEFI services become unavailable to SMM
  drivers.

Cc: Eric Dong 
Cc: Jiewen Yao 
Cc: Ladi Prosek 
Cc: Star Zeng 
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1498159
Suggested-by: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---
 MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf |  3 +  
MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c | 81 
++--
 2 files changed, 77 insertions(+), 7 deletions(-)

diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
index 404164366579..69966f0d37ee 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableSmm.inf
@@ -74,6 +74,7 @@ [LibraryClasses]
   SmmMemLib
   AuthVariableLib
   VarCheckLib
+  UefiBootServicesTableLib
 
 [Protocols]
   gEfiSmmFirmwareVolumeBlockProtocolGuid## CONSUMES
@@ -85,6 +86,8 @@ [Protocols]
   gEfiSmmVariableProtocolGuid
   gEfiSmmEndOfDxeProtocolGuid   ## NOTIFY
   gEdkiiSmmVarCheckProtocolGuid ## PRODUCES
+  gEfiTcgProtocolGuid   ## SOMETIMES_CONSUMES
+  gEfiTcg2ProtocolGuid  ## SOMETIMES_CONSUMES
 
 [Guids]
   ## SOMETIMES_CONSUMES   ## GUID # Signature of Variable store header
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
index 6d14b0042f4d..0a0281e44bc1 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/TcgMorLockSmm.c
@@ -21,6 +21,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
 #include "Variable.h"
 
 typedef struct {
@@ -33,6 +34,8 @@ VARIABLE_TYPE  mMorVariableType[] = {
   {MEMORY_OVERWRITE_REQUEST_CONTROL_LOCK_NAME,  
&gEfiMemoryOverwriteRequestControlLockGuid},
 };
 
+BOOLEAN mMorPassThru = FALSE;
+
 #define MOR_LOCK_DATA_UNLOCKED   0x0
 #define MOR_LOCK_DATA_LOCKED_WITHOUT_KEY 0x1
 #define MOR_LOCK_DATA_LOCKED_WITH_KEY0x2
@@ -364,6 +367,13 @@ SetVariableCheckHandlerMor (
   // Mor Variable
   //
 
+  //
+  // Permit deletion for passthru request.
+  //
+  if (((Attributes == 0) || (DataSize == 0)) && mMorPassThru) {
+return EFI_SUCCESS;
+  }
+
   //
   // Basic Check
   //
@@ -411,6 +421,8 @@ MorLockInitAtEndOfDxe (  {
   UINTN  MorSize;
   EFI_STATUS MorStatus;
+  EFI_STATUS TcgStatus;
+  VOID   *TcgInterface;
 
   if (!mMorLockInitializationRequired) {
 //
@@ -438,17 +450,72 @@ MorLockInitAtEndOfDxe (
 
   if (MorStatus == EFI_BUFFER_TOO_SMALL) {
 //
-// The MOR variable exists; set the MOR Control Lock variable to report the
-// capability to the OS.
+// The MOR variable exists.
 //
-SetMorLockVariable (0);
-return;
+// Some OSes don't follow the TCG's Platform Reset Attack Mitigation spec
+// in that the OS should never create the MOR variable, only read and write
+// it -- these OSes (unintentionally) create MOR if the platform firmware
+// does not produce it. Whether this is the case (from the last OS boot)
+// can be deduced from the absence of the TCG / TCG2 protocols, as edk2's
+// M