Re: [edk2] [PATCH v2 0/6] Add ARM support for VS2017

[Gao, Liming]

Pete:
  I get your point. I suggest to add it in VS2017 tool chain comment. To build 
XIP firmware image, /FILEALIGN:4096 are required. Now, SEC, PEI_CORE and PEIM 
module require it. 

Thanks
Liming
>-Original Message-
>From: Pete Batard [mailto:p...@akeo.ie]
>Sent: Thursday, December 07, 2017 11:56 PM
>To: edk2-devel@lists.01.org; Gao, Liming 
>Subject: Re: [PATCH v2 0/6] Add ARM support for VS2017
>
>Hi Liming,
>
>On 2017.12.07 03:02, Gao, Liming wrote:
>>This is the base step to enable VS2017 ARM tool chain. Then, user could
>use it and build ARM application first.
>
>Yes.
>
>>Here, I have one question. VS2017 ARM requires 4096 alignment. So, why
>not add /FILEALIGN:4096 into tools_def.txt as the default linker option for
>ARM?
>
>I don't think we want to do that on account that this option does not
>need to be specified when building regular applications, and is
>currently only needed when building the QEMU firmware.
>
>So it's probably better to only specify it in the context where it is
>needed, rather than globally, especially as the documentation for
>/FILEALIGN [1] indicates that "By default, the linker does not use a
>fixed alignment size" which would tend to indicate that we might be
>better off letting the compiler decide what it should use on its own.
>
>Especially, forcing /FILEALIGN to 4K everywhere does appear to increase
>the size of the generated binaries. For instance, I'm seeing a RELEASE
>Shell.efi  with a size of 762 KB without /FILEALIGN, vs. 792 KB with
>/FILEALIGN:4096.
>
>Thus, I think we should be conservative with regards to the global
>compiler options we add: if an option only seems to be needed for a
>single module (and especially, if that module has not yet been patched
>and reviewed for compilation), it should probably be specified for that
>module alone.
>
>As such, unless you or other people on this list have a strong opinion
>that /FILEALIGN:4096 should be global, I am currently not planning to
>resubmit a new patch that adds that option.
>
>Please let me know if you still think the patch should be altered.
>
>Regards,
>
>/Pete
>
>[1] https://docs.microsoft.com/en-gb/cpp/build/reference/filealign
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] MdeModulePkg/Ip4Dxe: fix ICMP echo reply memory leak

[Guo Heyi]

Hi Jiaxin,

We are still having our QA to finally verify the patches (including the ICMP 
error listener bug fix), so I will post the formal patch after regression test 
completes.

Regards,

Gary (Heyi Guo)


On Fri, Dec 08, 2017 at 10:04:20AM +0800, Guo Heyi wrote:
> On Fri, Dec 08, 2017 at 12:39:30AM +, Wu, Jiaxin wrote:
> > Hi Gary,
> > 
> > Agree to generate a formal patch. You can attach the reviewed-by tag at the 
> > same time.
> > 
> > Can you help to file one Bugzilla for this issue?
> 
> No Problem.
> 
> > 
> > BTW, Do you need us commit the patch or by yourself?
> 
> Yes, for I can't commit by myself :)
> 
> Thanks and regards,
> 
> Gary (Heyi Guo)
> 
> > 
> > Thanks,
> > Jiaxin
> > 
> > > -Original Message-
> > > From: Heyi Guo [mailto:heyi@linaro.org]
> > > Sent: Thursday, December 7, 2017 8:23 PM
> > > To: Wu, Jiaxin ; linaro-u...@lists.linaro.org; edk2-
> > > de...@lists.01.org; Fu, Siyuan 
> > > Cc: Junbiao Hong ; Zeng, Star
> > > ; Dong, Eric ; Ni, Ruiyu
> > > 
> > > Subject: Re: [RFC] MdeModulePkg/Ip4Dxe: fix ICMP echo reply memory leak
> > > 
> > > Hi Siyuan and Jiaxin,
> > > 
> > > Thanks for your review; shall I generate a formal patch and post it
> > > again, as well as making some commit message refinement?
> > > 
> > > Regards,
> > > 
> > > 
> > > Gary (Heyi Guo)
> > > 
> > > 
> > > 在 12/7/2017 3:01 PM, Wu, Jiaxin 写道:
> > > > It's is good to me.
> > > >
> > > > Reviewed-by: Jiaxin Wu 
> > > >
> > > > Thanks,
> > > > Jiaxin
> > > >
> > > >
> > > >> -Original Message-
> > > >> From: Heyi Guo [mailto:heyi@linaro.org]
> > > >> Sent: Thursday, December 7, 2017 10:22 AM
> > > >> To: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org
> > > >> Cc: Heyi Guo ; Junbiao Hong
> > > >> ; Zeng, Star ; Dong,
> > > Eric
> > > >> ; Ni, Ruiyu ; Fu, Siyuan
> > > >> ; Wu, Jiaxin 
> > > >> Subject: [RFC] MdeModulePkg/Ip4Dxe: fix ICMP echo reply memory leak
> > > >>
> > > >> When UEFI receives IPMP echo packets it will enter Ip4IcmpReplyEcho
> > > >> function, and then call Ip4Output. However, if Ip4Output gets some
> > > >> error and exits early, e.g. fails to find the route entry, memory
> > > >> buffer of "Data" gets no chance to be freed and memory leak will be
> > > >> caused. If there is such an attacker in the network, we will see UEFI
> > > >> runs out of memory and system hangs.
> > > >>
> > > >> Network stack code is so complicated that this is just a RFC to fix
> > > >> this issue. Please provide your comments about this.
> > > >>
> > > >> Contributed-under: TianoCore Contribution Agreement 1.1
> > > >> Signed-off-by: Junbiao Hong 
> > > >> Signed-off-by: Heyi Guo 
> > > >> Cc: Star Zeng 
> > > >> Cc: Eric Dong 
> > > >> Cc: Ruiyu Ni 
> > > >> Cc: Siyuan Fu 
> > > >> Cc: Jiaxin Wu 
> > > >> ---
> > > >>   MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c | 3 +++
> > > >>   1 file changed, 3 insertions(+)
> > > >>
> > > >> diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
> > > >> b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
> > > >> index b4b0864..ed6bdbe 100644
> > > >> --- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
> > > >> +++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
> > > >> @@ -267,6 +267,9 @@ Ip4IcmpReplyEcho (
> > > >>Ip4SysPacketSent,
> > > >>NULL
> > > >>);
> > > >> +  if (EFI_ERROR (Status)) {
> > > >> +NetbufFree (Data);
> > > >> +  }
> > > >>
> > > >>   ON_EXIT:
> > > >> NetbufFree (Packet);
> > > >> --
> > > >> 2.7.4
> > 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] MdePkg/Spi : Modify SPI Protocol strctures to make it more generic

[Bi, Dandan]

Hi Pankaj Bansal,

Current  SPI header files follow PI 1.6 Spec, if you find any issue in PI spec, 
current process is to raise them to PIWG for discussion firstly, then PIWG will 
discuss the issue and decide whether update the spec, at last update the code 
if needed.


Thanks,
Dandan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif 
Lindholm
Sent: Thursday, December 7, 2017 10:49 PM
To: Pankaj Bansal 
Cc: Kinney, Michael D ; edk2-devel@lists.01.org; 
Gao, Liming 
Subject: Re: [edk2] [RFC] MdePkg/Spi : Modify SPI Protocol strctures to make it 
more generic

Adding MdePkg maintainers: Mike and Liming.

Please always cc package maintainers (listed in Maintainers.txt).

/
Leif

On Thu, Dec 07, 2017 at 02:05:19PM +0530, Pankaj Bansal wrote:
> Issue_1: Currenty SPI IO and SPI HC protocol strcture is not equipped 
> to handle all type of SPI commands e.g. QuadIo Read Command (0xEBh) in 
> spansion flash S25FS512S will not work.
> 
> Cause: Currenty SPI protocol describes a SPI transaction as 
> combination of data and address and command, which would all be 
> transmitted on same data bus (1 or 2 or 4).
> 
> BUT when we have a case in which command is send one single data bus 
> and address and data is sent one 4 data bus (like 0xEB in spansion), 
> then this will not work with current strcture.
> 
> Fix: Instead of making a single transaction, we can specify a group of 
> transactions (called packet, terminology borrowed from I2c Protocol) 
> in which each transaction specifies the data width, frequency, delay 
> and read/write info.
> 
> Issue_2: Specify additional data about SPI transaction (i.e. 
> transaction is of type cmd, address, data, dummy etc). some 
> controllers need this info to communicate with SPI peripheral. others can 
> ignore this info.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Pankaj Bansal 
> ---
>  MdePkg/Include/Protocol/SpiHc.h |  15 +-  
> MdePkg/Include/Protocol/SpiIo.h | 250 --
>  2 files changed, 104 insertions(+), 161 deletions(-)
> 
> diff --git a/MdePkg/Include/Protocol/SpiHc.h 
> b/MdePkg/Include/Protocol/SpiHc.h index 12fe5d2..65964bc 100644
> --- a/MdePkg/Include/Protocol/SpiHc.h
> +++ b/MdePkg/Include/Protocol/SpiHc.h
> @@ -110,8 +110,11 @@ typedef EFI_STATUS
>status.
>  
>@param[in] ThisPointer to an EFI_SPI_HC_PROTOCOL structure.
> -  @param[in] BusTransaction  Pointer to a EFI_SPI_BUS_ TRANSACTION containing
> - the description of the SPI transaction to 
> perform.
> +  @param[in] SpiPeripheral   The address of an EFI_SPI_PERIPHERAL data 
> structure
> + describing the SPI peripheral from(to) which
> + read(write) transactions to be performed.
> +  @param[in] RequestPacket   Pointer to a EFI_SPI_REQUEST_PACKET containing
> + the description of the SPI transactions to 
> perform.
>  
>@retval EFI_SUCCESS  The transaction completed successfully
>@retval EFI_BAD_BUFFER_SIZE  The BusTransaction->WriteBytes value 
> is invalid, @@ -124,7 +127,8 @@ typedef EFI_STATUS  typedef EFI_STATUS  
> (EFIAPI *EFI_SPI_HC_PROTOCOL_TRANSACTION) (
>IN CONST EFI_SPI_HC_PROTOCOL  *This,
> -  IN EFI_SPI_BUS_TRANSACTION*BusTransaction
> +  IN CONST EFI_SPI_PERIPHERAL   *SpiPeripheral;
> +  IN EFI_SPI_REQUEST_PACKET *RequestPacket
>);
>  
>  ///
> @@ -135,7 +139,6 @@ struct _EFI_SPI_HC_PROTOCOL {
>/// Host control attributes, may have zero or more of the following set:
>/// * HC_SUPPORTS_WRITE_ONLY_OPERATIONS
>/// * HC_SUPPORTS_READ_ONLY_OPERATIONS
> -  /// * HC_SUPPORTS_WRITE_THEN_READ_OPERATIONS
>/// * HC_TX_FRAME_IN_MOST_SIGNIFICANT_BITS
>///   - The SPI host controller requires the transmit frame to be in most
>/// significant bits instead of least significant bits.The host driver
> @@ -149,10 +152,6 @@ struct _EFI_SPI_HC_PROTOCOL {
>///   - The SPI controller supports a 2 - bit data bus
>/// * HC_SUPPORTS_4_B1T_DATA_BUS_WIDTH
>///   - The SPI controller supports a 4 - bit data bus
> -  /// * HC_TRANSFER_SIZE_INCLUDES_OPCODE
> -  ///   - Transfer size includes the opcode byte
> -  /// * HC_TRANSFER_SIZE_INCLUDES_ADDRESS
> -  ///   - Transfer size includes the 3 address bytes
>/// The SPI host controller must support full - duplex (receive while
>/// sending) operation.The SPI host controller must support a 1 - bit bus
>/// width.
> diff --git a/MdePkg/Include/Protocol/SpiIo.h 
> b/MdePkg/Include/Protocol/SpiIo.h index 43e8045..507abb5 100644
> --- a/MdePkg/Include/Protocol/SpiIo.h
> +++ b/MdePkg/Include/Protocol/SpiIo.h
> @@ -27,147 +27,33 @@ typedef struct _EFI_SPI_IO_PROTOCOL 
> EFI_SPI_IO_PROTOCOL;  /// Note: The UEFI PI 1.6 specification does not 
> specify 

Re: [edk2] [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support for Watchdog driver

[Udit Kumar]

> Because when the hardware watchdog times out, it triggers a hard system reset,
> without any software interaction.

Little more complexity around this piece of h/w
e.g once watchdog is started it cannot be stopped. 
Most caller seems to set timeout of 5 mins and later stopping watchdog. 
But actually watchdog is not stopped and OS needs to be loaded within this time 
or some
specific application needs to ping it.

Thx
Udit


> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Thursday, December 07, 2017 9:04 PM
> To: Gao, Liming 
> Cc: Udit Kumar ; Kinney, Michael D
> ; Meenakshi Aggarwal
> ; ard.biesheu...@linaro.org; edk2-
> de...@lists.01.org; Varun Sethi 
> Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support
> for Watchdog driver
> 
> Liming,
> 
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> mail-archive.com%2Fedk2-
> devel%40lists.01.org%2Fmsg32761.html=02%7C01%7Cudit.kumar%40nxp
> .com%7Cb5a84bfc5cdc435a605e08d53d87ff95%7C686ea1d3bc2b4c6fa92cd99c
> 5c301635%7C0%7C0%7C636482576674878205=w3k%2B7Aw6D78uaTty
> GOh%2F8JUSiHVIdpCPkBudMth6m%2Fw%3D=0
> Search for WdogRegisterHandler.
> 
> This topic is entirely unrelated to any _usage_ of watchdog timer protocol.
> 
> The topic is only whether it is reasonable to _implement_
> EFI_WATCHDOG_TIMER_ARCH_PROTOCOL for a hardware watchdog that
> *cannot* cause a callback to a handler function.
> Because when the hardware watchdog times out, it triggers a hard system reset,
> without any software interaction.
> 
> /
> Leif
> 
> On Thu, Dec 07, 2017 at 02:54:08PM +, Gao, Liming wrote:
> > Leif:
> >   I don't review the whole patch serial. Could you point your usage
> >   case on watch dog timer protocol?
> >
> > Thanks
> > Liming
> > > -Original Message-
> > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > > Sent: Thursday, December 7, 2017 7:04 PM
> > > To: Gao, Liming 
> > > Cc: Udit Kumar ; Kinney, Michael D
> > > ; Meenakshi Aggarwal
> > > ; ard.biesheu...@linaro.org;
> > > edk2-devel@lists.01.org; Varun Sethi 
> > > Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP :
> > > Add support for Watchdog driver
> > >
> > > Hi Liming,
> > >
> > > On Thu, Dec 07, 2017 at 07:11:38AM +, Gao, Liming wrote:
> > > > Leif:
> > > >   I don't see the core driver uses
> > > >   WatchdogTimer->RegisterHandler(). When it returns unsupported, it
> > > >   means the additional handler can't be registered. DxeCore uses
> > > >   WatchdogTimer->SetTimerPeriod(). This service is implemented in
> > > >   your driver.
> > > >
> > > >   Watchdog protocol is defined in PI spec. Spec describes that this
> > > >   protocol provides the services required to implement the Boot
> > > >   Service SetWatchdogTimer(). It provides a service to set the
> > > >   amount of time to wait before firing the watchdog timer, and it
> > > >   also provides a service to register a handler that is invoked when
> > > >   the watchdog timer fires. This protocol can implement the watchdog
> > > >   timer by using the event and timer Boot Services, or it can make
> > > >   use of custom hardware. If no handler has been registered, or the
> > > >   registered handler returns, then the system will be reset by
> > > >   calling the Runtime Service ResetSystem(). So, this protocol is
> > > >   required.
> > >
> > > I am not disputing that the protocol is not required. I am
> > > suggesting that this hardware watchdog _cannot_ be used to register a
> handler.
> > >
> > > If this hardware watchdog does not get updated in time, that causes
> > > an immediate hardware reset of the processor.
> > >
> > > Because of this, I believe EFI_WATCHDOG_TIMER_ARCH_PROTOCOL is not
> > > the appropriate way to make use of it.
> > >
> > > Please let me know whether you agree.
> > >
> > > Regards,
> > >
> > > Leif
> > >
> > > > Thanks
> > > > Liming
> > > > >-Original Message-
> > > > >From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > > > >Sent: Tuesday, December 05, 2017 7:06 PM
> > > > >To: Udit Kumar 
> > > > >Cc: Gao, Liming ; Kinney, Michael D
> > > > >; Meenakshi Aggarwal
> > > > >; ard.biesheu...@linaro.org; edk2-
> > > > >de...@lists.01.org; Varun Sethi 
> > > > >Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP :
> > > > >Add support for Watchdog driver
> > > > >
> > > > >On Tue, Dec 05, 2017 at 05:07:00AM +, Udit Kumar wrote:
> > > > >> >   I suggest return EFI_UNSUPPORTED for this case. The
> > > > >> > protocol
> > > > >implementation
> > > > >> > could return its status besides spec defined status.
> > > > >>

[edk2] [Patch] BaseTools: Update BrotliCompress script to handle the different input format

[Liming Gao]

After this update, BrotliCompress can support below styles.
BrotliCompress -e InputFile -o OutputFile
BrotliCompress -e -o OutputFile InputFile

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao 
---
 BaseTools/BinWrappers/PosixLike/BrotliCompress | 61 +-
 .../Source/C/BrotliCompress/BrotliCompress.bat | 18 ---
 2 files changed, 34 insertions(+), 45 deletions(-)

diff --git a/BaseTools/BinWrappers/PosixLike/BrotliCompress 
b/BaseTools/BinWrappers/PosixLike/BrotliCompress
index ca32d6a..6e4c8c9 100755
--- a/BaseTools/BinWrappers/PosixLike/BrotliCompress
+++ b/BaseTools/BinWrappers/PosixLike/BrotliCompress
@@ -1,6 +1,6 @@
 #!/usr/bin/env bash
 #
-# This script will exec Brotli tool.
+# This script will exec Brotli tool with -e/-d options.
 #
 # Copyright (c) 2017, Intel Corporation. All rights reserved.
 # This program and the accompanying materials
@@ -13,50 +13,37 @@
 #
 QLT="-q 9"
 INPUTFLAG=0
+ARGS=
 
-for arg; do
-  if [ $1 = -d ]
-then
+while test $# -gt 0
+do
+  case $1 in
+-e)
   INPUTFLAG=1
-  fi
-  if [ $1 = -e ]
-then
+  ;;
+-d)
   INPUTFLAG=1
-  shift
-  continue;
-  fi
-  if [ $1 = -g ]
-then
-  ARGS+="$1 $2 "
-  shift
-  shift
-  continue;
-  fi
-  if [ $1 = -o ]
-then
+  ARGS+="$1 "
+  ;;
+-o|-g)
   ARGS+="$1 $2 "
   shift
-  shift
-  continue;
-  fi
-  if [ $1 = -q ]
-then
+  ;;
+-q)
   QLT="$1 $2 "
   shift
-  shift
-  continue;
-  fi
-  if [ $INPUTFLAG -eq 1 ]
-then
-  if [ -z $2 ]
+  ;;
+*)
+  if [ $INPUTFLAG -eq 1 ]
 then
-  ARGS+="$QLT -i $1 "
-  break;
+  ARGS+="-i $1 "
+  INPUTFLAG=0
+else
+  ARGS+="$1 "
   fi
-  fi
-
-ARGS+="$1 "
-shift
+  ;;
+  esac
+  shift
 done
 
-exec Brotli $ARGS
+exec Brotli $ARGS $QLT
diff --git a/BaseTools/Source/C/BrotliCompress/BrotliCompress.bat 
b/BaseTools/Source/C/BrotliCompress/BrotliCompress.bat
index b291ff0..b1b4985 100644
--- a/BaseTools/Source/C/BrotliCompress/BrotliCompress.bat
+++ b/BaseTools/Source/C/BrotliCompress/BrotliCompress.bat
@@ -16,12 +16,16 @@
 
 set QLT=-q 9
 set INPUTFLAG=0
+set ARGS=
 
 :Begin
 if "%1"=="" goto End
 
 if "%1"=="-d" (
   set INPUTFLAG=1
+  set ARGS=%ARGS% %1
+  shift
+  goto Begin
 )
 
 if "%1"=="-e" (
@@ -51,17 +55,15 @@ if "%1"=="-q" (
   goto Begin
 )
 
-if %INPUTFLAG%==1 (
- if "%2"=="" (
-set ARGS=%ARGS% %QLT% -i %1
-goto End
-  )
+if %INPUTFLAG% == 1 (
+  set ARGS=%ARGS% -i %1
+  set INPUTFLAG=0
+) else (
+  set ARGS=%ARGS% %1
 )
-
-set ARGS=%ARGS% %1
 shift
 goto Begin
 
 :End
-Brotli %ARGS%
+Brotli %ARGS% %QLT%
 @echo on
-- 
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] MdeModulePkg DxeIpl: Move ClearFirst4KPage/IsNullDetectionEnabled definition

[Wang, Jian J]

Looks good to me.

Reviewed-by: Jian J Wang 

> -Original Message-
> From: Zeng, Star
> Sent: Friday, December 08, 2017 11:03 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Wang, Jian J 
> Subject: [PATCH] MdeModulePkg DxeIpl: Move
> ClearFirst4KPage/IsNullDetectionEnabled definition
> 
> Move ClearFirst4KPage/IsNullDetectionEnabled definition from DxeIpl.h to
> VirtualMemory.h as they are implemented in VirtualMemory.c and only used
> in IA32/X64 ARCH.
> 
> Cc: Jian J Wang 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng 
> ---
>  MdeModulePkg/Core/DxeIplPeim/DxeIpl.h| 27 
> +---
>  MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h | 26
> ++-
>  2 files changed, 26 insertions(+), 27 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> index f3aabdb7e0f0..6f8e13d21335 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> +++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
> @@ -2,7 +2,7 @@
>Master header file for DxeIpl PEIM. All source files in this module should
>include this file for common definitions.
> 
> -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
> @@ -240,29 +240,4 @@ 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 HobStart 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/X64/VirtualMemory.h
> b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
> index 7c9bb49e3e2c..26a2100f0b80 100644
> --- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
> +++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
> @@ -7,7 +7,7 @@
>  3) IA-32 Intel(R) Architecture Software Developer's Manual Volume 
> 3:System
> Programmer's Guide, Intel
>  4) AMD64 Architecture Programmer's Manual Volume 2: System
> Programming
> 
> -Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
>  Copyright (c) 2017, AMD Incorporated. All rights reserved.
> 
>  This program and the accompanying materials
> @@ -227,5 +227,29 @@ AsmGetVectorTemplatInfo (
>OUT   VOID  **TemplateBase
>);
> 
> +/**
> +  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 HobStart 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
> --
> 2.7.0.windows.1

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

[edk2] [PATCH] MdeModulePkg DxeIpl: Move ClearFirst4KPage/IsNullDetectionEnabled definition

[Star Zeng]

Move ClearFirst4KPage/IsNullDetectionEnabled definition from DxeIpl.h to
VirtualMemory.h as they are implemented in VirtualMemory.c and only used
in IA32/X64 ARCH.

Cc: Jian J Wang 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.h| 27 +---
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h | 26 ++-
 2 files changed, 26 insertions(+), 27 deletions(-)

diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h 
b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
index f3aabdb7e0f0..6f8e13d21335 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
@@ -2,7 +2,7 @@
   Master header file for DxeIpl PEIM. All source files in this module should
   include this file for common definitions.
 
-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
@@ -240,29 +240,4 @@ 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 HobStart 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/X64/VirtualMemory.h 
b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
index 7c9bb49e3e2c..26a2100f0b80 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
@@ -7,7 +7,7 @@
 3) IA-32 Intel(R) Architecture Software Developer's Manual Volume 3:System 
Programmer's Guide, Intel
 4) AMD64 Architecture Programmer's Manual Volume 2: System Programming
 
-Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
 Copyright (c) 2017, AMD Incorporated. All rights reserved.
 
 This program and the accompanying materials
@@ -227,5 +227,29 @@ AsmGetVectorTemplatInfo (
   OUT   VOID  **TemplateBase
   );
 
+/**
+  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 HobStart 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 
-- 
2.7.0.windows.1

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

Re: [edk2] [PATCH] SecurityPkg:Tcg2Smm:Enabling TPM SIRQ interrupt support

[Zhang, Chao B]

Hi Jiewen & All:
   We verified Infineon(TIS + LPC,  TIS +SPI) & Nuvoton(CRB+SPI, FIFO +LPC) 
TPM2.0 chip on  Intel Kabylake Platform. TPM can work well both in boot & OS 
phase.


-Original Message-
From: Yao, Jiewen 
Sent: Friday, December 8, 2017 9:22 AM
To: Zhang, Chao B ; edk2-devel@lists.01.org
Cc: Zhang, Chao B ; Long, Qin 
Subject: RE: [edk2] [PATCH] SecurityPkg:Tcg2Smm:Enabling TPM SIRQ interrupt 
support

Thanks.
Would you please also provide the information on what platform and TPM chip we 
have validated?

Reviewed-by: jiewen@intel.com

Thank you
Yao Jiewen

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Zhang, Chao B
> Sent: Friday, December 8, 2017 8:45 AM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Zhang, Chao B 
> ; Long, Qin 
> Subject: [edk2] [PATCH] SecurityPkg:Tcg2Smm:Enabling TPM SIRQ 
> interrupt support
> 
> 1. Report TPM SIRQ interrupt resource through _CRS 2. Expose _SRS to 
> update interrupt resource & FIFO/TIS interrupt related registers
>defined in TCG PC Client Platform TPM Profile (PTP) Specification 
> spec 
> https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specifi
> c-Platf orm-TPM-Profile-for-TPM-2-0-v43-150126.pdf
> Note: IHV/OEM need to carefully verify this feature with OS TPM driver 
> to make sure there is no impact to system/HW
> 
> Cc: Long Qin 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chao Zhang 
> ---
>  SecurityPkg/Tcg/Tcg2Smm/Tpm.asl | 112
> +---
>  1 file changed, 104 insertions(+), 8 deletions(-)
> 
> diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl 
> b/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl index cf0642e..68b5073 100644
> --- a/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
> +++ b/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
> @@ -44,13 +44,6 @@ DefinitionBlock (
>Name (_STR, Unicode ("TPM 2.0 Device"))
> 
>//
> -  // Return the resource consumed by TPM device
> -  //
> -  Name (_CRS, ResourceTemplate () {
> -Memory32Fixed (ReadWrite, 0xfed4, 0x5000)
> -  })
> -
> -  //
>// Operational region for Smi port access
>//
>OperationRegion (SMIP, SystemIO, 0xB2, 1) @@ -65,7 +58,19 @@ 
> DefinitionBlock (
>OperationRegion (TPMR, SystemMemory, 0xfed4, 0x5000)
>Field (TPMR, AnyAcc, NoLock, Preserve)
>{
> -ACC0, 8,
> +ACC0, 8,  // TPM_ACCESS_0
> +Offset(0x8),
> +INTE, 32, // TPM_INT_ENABLE_0
> +INTV, 8,  // TPM_INT_VECTOR_0
> +Offset(0x10),
> +INTS, 32, // TPM_INT_STATUS_0
> +INTF, 32, // TPM_INTF_CAPABILITY_0
> +STS0, 32, // TPM_STS_0
> +Offset(0x24),
> +FIFO, 32, // TPM_DATA_FIFO_0
> +Offset(0x30),
> +TID0, 32, // TPM_INTERFACE_ID_0
> +  // ignore the rest
>}
> 
>//
> @@ -89,6 +94,97 @@ DefinitionBlock (
>  UCRQ,   32  //   Phyical Presence request operation to Get User
> Confirmation Status
>}
> 
> +  Name(RESO, ResourceTemplate () {
> +Memory32Fixed (ReadWrite, 0xfed4, 0x5000, REGS)
> +Interrupt(ResourceConsumer, Level, ActiveLow, Shared, , , IRQ) {12}
> +  })
> +
> +  //
> +  // Return the resource consumed by TPM device.
> +  //
> +  Method(_CRS,0,Serialized)
> +  {
> +Return(RESO)
> +  }
> +
> +  //
> +  // Set resources consumed by the TPM device. This is used to
> +  // assign an interrupt number to the device. The input byte stream
> +  // has to be the same as returned by _CRS (according to ACPI spec).
> +  //
> +  Method(_SRS,1,Serialized)
> +  {
> +//
> +// Update resource descriptor
> +// Use the field name to identify the offsets in the argument
> +// buffer and RESO buffer.
> +//
> +CreateDWordField(Arg0, ^IRQ._INT, IRQ0)
> +CreateDWordField(RESO, ^IRQ._INT, LIRQ)
> +Store(IRQ0, LIRQ)
> +
> +CreateBitField(Arg0, ^IRQ._HE, ITRG)
> +CreateBitField(RESO, ^IRQ._HE, LTRG)
> +Store(ITRG, LTRG)
> +
> +CreateBitField(Arg0, ^IRQ._LL, ILVL)
> +CreateBitField(RESO, ^IRQ._LL, LLVL)
> +Store(ILVL, LLVL)
> +
> +//
> +// Update TPM FIFO PTP/TIS interface only, identified by
> TPM_INTERFACE_ID_x lowest
> +// nibble.
> +//  - FIFO interface as defined in PTP for TPM 2.0 is active
> +//  - FIFO interface as defined in TIS1.3 is active
> +//
> +If (LOr(LEqual (And (TID0, 0x0F), 0x00), LEqual (And (TID0, 
> + 0x0F),
> 0x0F))) {
> +  //
> +  // If FIFO interface, interrupt vector register is
> +  // 

Re: [edk2] [RFC] MdeModulePkg/Ip4Dxe: fix ICMP echo reply memory leak

[Guo Heyi]

On Fri, Dec 08, 2017 at 12:39:30AM +, Wu, Jiaxin wrote:
> Hi Gary,
> 
> Agree to generate a formal patch. You can attach the reviewed-by tag at the 
> same time.
> 
> Can you help to file one Bugzilla for this issue?

No Problem.

> 
> BTW, Do you need us commit the patch or by yourself?

Yes, for I can't commit by myself :)

Thanks and regards,

Gary (Heyi Guo)

> 
> Thanks,
> Jiaxin
> 
> > -Original Message-
> > From: Heyi Guo [mailto:heyi@linaro.org]
> > Sent: Thursday, December 7, 2017 8:23 PM
> > To: Wu, Jiaxin ; linaro-u...@lists.linaro.org; edk2-
> > de...@lists.01.org; Fu, Siyuan 
> > Cc: Junbiao Hong ; Zeng, Star
> > ; Dong, Eric ; Ni, Ruiyu
> > 
> > Subject: Re: [RFC] MdeModulePkg/Ip4Dxe: fix ICMP echo reply memory leak
> > 
> > Hi Siyuan and Jiaxin,
> > 
> > Thanks for your review; shall I generate a formal patch and post it
> > again, as well as making some commit message refinement?
> > 
> > Regards,
> > 
> > 
> > Gary (Heyi Guo)
> > 
> > 
> > 在 12/7/2017 3:01 PM, Wu, Jiaxin 写道:
> > > It's is good to me.
> > >
> > > Reviewed-by: Jiaxin Wu 
> > >
> > > Thanks,
> > > Jiaxin
> > >
> > >
> > >> -Original Message-
> > >> From: Heyi Guo [mailto:heyi@linaro.org]
> > >> Sent: Thursday, December 7, 2017 10:22 AM
> > >> To: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org
> > >> Cc: Heyi Guo ; Junbiao Hong
> > >> ; Zeng, Star ; Dong,
> > Eric
> > >> ; Ni, Ruiyu ; Fu, Siyuan
> > >> ; Wu, Jiaxin 
> > >> Subject: [RFC] MdeModulePkg/Ip4Dxe: fix ICMP echo reply memory leak
> > >>
> > >> When UEFI receives IPMP echo packets it will enter Ip4IcmpReplyEcho
> > >> function, and then call Ip4Output. However, if Ip4Output gets some
> > >> error and exits early, e.g. fails to find the route entry, memory
> > >> buffer of "Data" gets no chance to be freed and memory leak will be
> > >> caused. If there is such an attacker in the network, we will see UEFI
> > >> runs out of memory and system hangs.
> > >>
> > >> Network stack code is so complicated that this is just a RFC to fix
> > >> this issue. Please provide your comments about this.
> > >>
> > >> Contributed-under: TianoCore Contribution Agreement 1.1
> > >> Signed-off-by: Junbiao Hong 
> > >> Signed-off-by: Heyi Guo 
> > >> Cc: Star Zeng 
> > >> Cc: Eric Dong 
> > >> Cc: Ruiyu Ni 
> > >> Cc: Siyuan Fu 
> > >> Cc: Jiaxin Wu 
> > >> ---
> > >>   MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c | 3 +++
> > >>   1 file changed, 3 insertions(+)
> > >>
> > >> diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
> > >> b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
> > >> index b4b0864..ed6bdbe 100644
> > >> --- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
> > >> +++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
> > >> @@ -267,6 +267,9 @@ Ip4IcmpReplyEcho (
> > >>Ip4SysPacketSent,
> > >>NULL
> > >>);
> > >> +  if (EFI_ERROR (Status)) {
> > >> +NetbufFree (Data);
> > >> +  }
> > >>
> > >>   ON_EXIT:
> > >> NetbufFree (Packet);
> > >> --
> > >> 2.7.4
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/ScsiDisk: Return EFI_NO_MEDIA when no media presents

[Wu, Hao A]

Reviewed-by: Hao Wu 

Best Regards,
Hao Wu


> -Original Message-
> From: Ni, Ruiyu
> Sent: Thursday, December 07, 2017 5:55 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star; Wu, Hao A
> Subject: [PATCH] MdeModulePkg/ScsiDisk: Return EFI_NO_MEDIA when no
> media presents
> 
> Current code always return EFI_MEDIA_CHANGED no matter the media
> is removed from CD/DVD drive or the media is changed.
> It doesn't strictly follow the UEFI Spec.
> Update code to return EFI_NO_MEDIA when media is removed.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ruiyu Ni 
> Cc: Star Zeng 
> Cc: Hao A Wu 
> ---
>  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c | 41 -
> ---
>  1 file changed, 30 insertions(+), 11 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
> b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
> index 2289f20152..6a0a193556 100644
> --- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
> +++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
> @@ -568,6 +568,7 @@ ScsiDiskReadBlocks (
>MediaChange= FALSE;
>OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
>ScsiDiskDevice = SCSI_DISK_DEV_FROM_BLKIO (This);
> +  Media  = ScsiDiskDevice->BlkIo.Media;
> 
>if (!IS_DEVICE_FIXED(ScsiDiskDevice)) {
> 
> @@ -598,14 +599,17 @@ ScsiDiskReadBlocks (
> >EraseBlock
> );
>}
> -  Status = EFI_MEDIA_CHANGED;
> +  if (Media->MediaPresent) {
> +Status = EFI_MEDIA_CHANGED;
> +  } else {
> +Status = EFI_NO_MEDIA;
> +  }
>goto Done;
>  }
>}
>//
>// Get the intrinsic block size
>//
> -  Media   = ScsiDiskDevice->BlkIo.Media;
>BlockSize   = Media->BlockSize;
> 
>NumberOfBlocks  = BufferSize / BlockSize;
> @@ -700,6 +704,7 @@ ScsiDiskWriteBlocks (
>MediaChange= FALSE;
>OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
>ScsiDiskDevice = SCSI_DISK_DEV_FROM_BLKIO (This);
> +  Media  = ScsiDiskDevice->BlkIo.Media;
> 
>if (!IS_DEVICE_FIXED(ScsiDiskDevice)) {
> 
> @@ -730,14 +735,17 @@ ScsiDiskWriteBlocks (
> >EraseBlock
> );
>}
> -  Status = EFI_MEDIA_CHANGED;
> +  if (Media->MediaPresent) {
> +Status = EFI_MEDIA_CHANGED;
> +  } else {
> +Status = EFI_NO_MEDIA;
> +  }
>goto Done;
>  }
>}
>//
>// Get the intrinsic block size
>//
> -  Media   = ScsiDiskDevice->BlkIo.Media;
>BlockSize   = Media->BlockSize;
> 
>NumberOfBlocks  = BufferSize / BlockSize;
> @@ -922,6 +930,7 @@ ScsiDiskReadBlocksEx (
>MediaChange= FALSE;
>OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
>ScsiDiskDevice = SCSI_DISK_DEV_FROM_BLKIO2 (This);
> +  Media  = ScsiDiskDevice->BlkIo.Media;
> 
>if (!IS_DEVICE_FIXED(ScsiDiskDevice)) {
> 
> @@ -952,14 +961,17 @@ ScsiDiskReadBlocksEx (
> >EraseBlock
> );
>}
> -  Status = EFI_MEDIA_CHANGED;
> +  if (Media->MediaPresent) {
> +Status = EFI_MEDIA_CHANGED;
> +  } else {
> +Status = EFI_NO_MEDIA;
> +  }
>goto Done;
>  }
>}
>//
>// Get the intrinsic block size
>//
> -  Media   = ScsiDiskDevice->BlkIo2.Media;
>BlockSize   = Media->BlockSize;
> 
>NumberOfBlocks  = BufferSize / BlockSize;
> @@ -1081,6 +1093,7 @@ ScsiDiskWriteBlocksEx (
>MediaChange= FALSE;
>OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
>ScsiDiskDevice = SCSI_DISK_DEV_FROM_BLKIO2 (This);
> +  Media  = ScsiDiskDevice->BlkIo.Media;
> 
>if (!IS_DEVICE_FIXED(ScsiDiskDevice)) {
> 
> @@ -,14 +1124,17 @@ ScsiDiskWriteBlocksEx (
> >EraseBlock
> );
>}
> -  Status = EFI_MEDIA_CHANGED;
> +  if (Media->MediaPresent) {
> +Status = EFI_MEDIA_CHANGED;
> +  } else {
> +Status = EFI_NO_MEDIA;
> +  }
>goto Done;
>  }
>}
>//
>// Get the intrinsic block size
>//
> -  Media   = ScsiDiskDevice->BlkIo2.Media;
>BlockSize   = Media->BlockSize;
> 
>NumberOfBlocks  = BufferSize / BlockSize;
> @@ -1230,6 +1246,7 @@ ScsiDiskFlushBlocksEx (
>MediaChange= FALSE;
>OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
>ScsiDiskDevice = SCSI_DISK_DEV_FROM_BLKIO2 (This);
> +  Media  = ScsiDiskDevice->BlkIo.Media;
> 
>if (!IS_DEVICE_FIXED(ScsiDiskDevice)) {
> 
> @@ -1260,13 +1277,15 @@ ScsiDiskFlushBlocksEx (
> >EraseBlock
> );
>}
> -  Status = EFI_MEDIA_CHANGED;
> +  if (Media->MediaPresent) {
> +Status = EFI_MEDIA_CHANGED;
> +  } else {
> +Status = EFI_NO_MEDIA;
> +  }
>goto Done;
>  }
>}
> 
> -  Media = ScsiDiskDevice->BlkIo2.Media;
> -
>if 

Re: [edk2] [PATCH v2 2/3] BaseTools/tools_def CLANG38: add -Wno-unused-const-variable

[Shi, Steven]

Thank you!

Reviewed-by: Shi Steven 


Steven Shi
Intel\SSG\STO\UEFI Firmware

Tel: +86 021-61166522
iNet: 821-6522

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, December 7, 2017 5:29 PM
> To: edk2-devel@lists.01.org
> Cc: leif.lindh...@linaro.org; Gao, Liming ; Zhu,
> Yonghong ; Shi, Steven ;
> evan.ll...@arm.com; ler...@redhat.com; Ard Biesheuvel
> 
> Subject: [PATCH v2 2/3] BaseTools/tools_def CLANG38: add -Wno-unused-
> const-variable
> 
> Commit 8b6366f87584 ("BaseTools/GCC: set -Wno-unused-const-variable
> on RELEASE builds") suppresses warnings about unused constant
> variables in RELEASE builds when building with GCC, given that they
> break the build under our warnings-as-errors policy.
> 
> Do the same for CLANG38.
> 
> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=790
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
> v2: new patch
> 
>  BaseTools/Conf/tools_def.template | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/BaseTools/Conf/tools_def.template
> b/BaseTools/Conf/tools_def.template
> index c0189d4c8d30..703884fc49a7 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -5664,7 +5664,7 @@ DEFINE CLANG38_X64_PREFIX   =
> ENV(CLANG38_BIN)
>  DEFINE CLANG38_IA32_TARGET  = -target i686-pc-linux-gnu
>  DEFINE CLANG38_X64_TARGET   = -target x86_64-pc-linux-gnu
> 
> -DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality -
> Wno-tautological-compare -Wno-tautological-constant-out-of-range-
> compare -Wno-empty-body  -Wno-varargs
> +DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality -
> Wno-tautological-compare -Wno-tautological-constant-out-of-range-
> compare -Wno-empty-body -Wno-unused-const-variable -Wno-varargs
>  DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS)
> DEF(CLANG38_WARNING_OVERRIDES) -fno-stack-protector -mms-bitfields -
> Wno-address -Wno-shift-negative-value -Wno-unknown-pragmas -Wno-
> incompatible-library-redeclaration -fno-asynchronous-unwind-tables -mno-
> sse -mno-mmx -msoft-float -mno-implicit-float  -ftrap-
> function=undefined_behavior_has_been_optimized_away_by_clang -
> funsigned-char -fno-ms-extensions -Wno-null-dereference -Wno-unknown-
> warning-option
> 
>  ###
> --
> 2.11.0

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

Re: [edk2] [PATCH] SecurityPkg:Tcg2Smm:Enabling TPM SIRQ interrupt support

[Yao, Jiewen]

Thanks.
Would you please also provide the information on what platform and TPM chip we 
have validated?

Reviewed-by: jiewen@intel.com

Thank you
Yao Jiewen

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zhang,
> Chao B
> Sent: Friday, December 8, 2017 8:45 AM
> To: edk2-devel@lists.01.org
> Cc: Yao, Jiewen ; Zhang, Chao B
> ; Long, Qin 
> Subject: [edk2] [PATCH] SecurityPkg:Tcg2Smm:Enabling TPM SIRQ interrupt
> support
> 
> 1. Report TPM SIRQ interrupt resource through _CRS
> 2. Expose _SRS to update interrupt resource & FIFO/TIS interrupt related
> registers
>defined in TCG PC Client Platform TPM Profile (PTP) Specification spec
> https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platf
> orm-TPM-Profile-for-TPM-2-0-v43-150126.pdf
> Note: IHV/OEM need to carefully verify this feature with OS TPM driver to make
> sure there is no impact to system/HW
> 
> Cc: Long Qin 
> Cc: Jiewen Yao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chao Zhang 
> ---
>  SecurityPkg/Tcg/Tcg2Smm/Tpm.asl | 112
> +---
>  1 file changed, 104 insertions(+), 8 deletions(-)
> 
> diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
> b/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
> index cf0642e..68b5073 100644
> --- a/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
> +++ b/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
> @@ -44,13 +44,6 @@ DefinitionBlock (
>Name (_STR, Unicode ("TPM 2.0 Device"))
> 
>//
> -  // Return the resource consumed by TPM device
> -  //
> -  Name (_CRS, ResourceTemplate () {
> -Memory32Fixed (ReadWrite, 0xfed4, 0x5000)
> -  })
> -
> -  //
>// Operational region for Smi port access
>//
>OperationRegion (SMIP, SystemIO, 0xB2, 1)
> @@ -65,7 +58,19 @@ DefinitionBlock (
>OperationRegion (TPMR, SystemMemory, 0xfed4, 0x5000)
>Field (TPMR, AnyAcc, NoLock, Preserve)
>{
> -ACC0, 8,
> +ACC0, 8,  // TPM_ACCESS_0
> +Offset(0x8),
> +INTE, 32, // TPM_INT_ENABLE_0
> +INTV, 8,  // TPM_INT_VECTOR_0
> +Offset(0x10),
> +INTS, 32, // TPM_INT_STATUS_0
> +INTF, 32, // TPM_INTF_CAPABILITY_0
> +STS0, 32, // TPM_STS_0
> +Offset(0x24),
> +FIFO, 32, // TPM_DATA_FIFO_0
> +Offset(0x30),
> +TID0, 32, // TPM_INTERFACE_ID_0
> +  // ignore the rest
>}
> 
>//
> @@ -89,6 +94,97 @@ DefinitionBlock (
>  UCRQ,   32  //   Phyical Presence request operation to Get User
> Confirmation Status
>}
> 
> +  Name(RESO, ResourceTemplate () {
> +Memory32Fixed (ReadWrite, 0xfed4, 0x5000, REGS)
> +Interrupt(ResourceConsumer, Level, ActiveLow, Shared, , , IRQ) {12}
> +  })
> +
> +  //
> +  // Return the resource consumed by TPM device.
> +  //
> +  Method(_CRS,0,Serialized)
> +  {
> +Return(RESO)
> +  }
> +
> +  //
> +  // Set resources consumed by the TPM device. This is used to
> +  // assign an interrupt number to the device. The input byte stream
> +  // has to be the same as returned by _CRS (according to ACPI spec).
> +  //
> +  Method(_SRS,1,Serialized)
> +  {
> +//
> +// Update resource descriptor
> +// Use the field name to identify the offsets in the argument
> +// buffer and RESO buffer.
> +//
> +CreateDWordField(Arg0, ^IRQ._INT, IRQ0)
> +CreateDWordField(RESO, ^IRQ._INT, LIRQ)
> +Store(IRQ0, LIRQ)
> +
> +CreateBitField(Arg0, ^IRQ._HE, ITRG)
> +CreateBitField(RESO, ^IRQ._HE, LTRG)
> +Store(ITRG, LTRG)
> +
> +CreateBitField(Arg0, ^IRQ._LL, ILVL)
> +CreateBitField(RESO, ^IRQ._LL, LLVL)
> +Store(ILVL, LLVL)
> +
> +//
> +// Update TPM FIFO PTP/TIS interface only, identified by
> TPM_INTERFACE_ID_x lowest
> +// nibble.
> +//  - FIFO interface as defined in PTP for TPM 2.0 is active
> +//  - FIFO interface as defined in TIS1.3 is active
> +//
> +If (LOr(LEqual (And (TID0, 0x0F), 0x00), LEqual (And (TID0, 0x0F),
> 0x0F))) {
> +  //
> +  // If FIFO interface, interrupt vector register is
> +  // available. TCG PTP specification allows only
> +  // values 1..15 in this field. For other interrupts
> +  // the field should stay 0.
> +  //
> +  If (LLess (IRQ0, 16)) {
> +Store (And(IRQ0, 0xF), INTV)
> +  }
> +  //
> +  // Interrupt enable register (TPM_INT_ENABLE_x) bits 3:4
> +  // contains settings for interrupt polarity.
> +  // The other bits of the byte enable individual interrupts.
> +  // They should be 

Re: [edk2] [PATCH] UefiCpuPkg PiSmmCpuDxeSmm: SMM profile and static paging mutual exclusion

[Zeng, Star]

Thanks and the RB to Laszlo and Eric.
And  I agree and will handle them when pushing the patch. :)


Thanks,
Star
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Thursday, December 7, 2017 7:32 PM
To: Zeng, Star ; edk2-devel@lists.01.org
Cc: Yao, Jiewen ; Dong, Eric ; Ni, 
Ruiyu ; Wang, Jian J 
Subject: Re: [PATCH] UefiCpuPkg PiSmmCpuDxeSmm: SMM profile and static paging 
mutual exclusion

Hi Star,

On 12/07/17 11:47, Star Zeng wrote:
> SMM profile and static paging could not enabled at the same time, this 
> patch is add check and comments to make sure it.
> 
> Similar comments are also added for the case of static paging and heap 
> guard for SMM.
> 
> Cc: Jiewen Yao 
> Cc: Eric Dong 
> Cc: Ruiyu Ni 
> Cc: Jian J Wang 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c |  9 +  
> UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c  | 13 ++---
>  UefiCpuPkg/UefiCpuPkg.dec|  6 +-
>  UefiCpuPkg/UefiCpuPkg.uni| 10 --
>  4 files changed, 32 insertions(+), 6 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> index 6e1ffe7c6287..939ac25a506c 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> @@ -205,6 +205,15 @@ SetPageTableAttributes (
>//  BIT3: SMM pool guard enabled
>//
>if ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
> +DEBUG ((DEBUG_INFO, "Don't mark page table as read-only as heap guard is 
> enabled\n"));
> +return ;
> +  }
> +
> +  //
> +  // Don't mark page table as read-only if SMM profile is enabled.
> +  //
> +  if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
> +DEBUG ((DEBUG_INFO, "Don't mark page table as read-only as SMM 
> + profile is enabled\n"));
>  return ;
>}
>  
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> index 6478c6c3e355..0fe944fc18cc 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> @@ -919,17 +919,24 @@ SetPageTableAttributes (
>//
>// Don't do this if
>//  - no static page table; or
> -  //  - SMM heap guard feature enabled
> +  //  - SMM heap guard feature enabled; or
>//  BIT2: SMM page guard enabled
>//  BIT3: SMM pool guard enabled
> +  //  - SMM profile feature enabled
>//
>if (!mCpuSmmStaticPageTable ||
> -  (PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
> +  ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) ||
> +  FeaturePcdGet (PcdCpuSmmProfileEnable)) {
>  //
> -// Static paging and heap guard should not be enabled at the same time.
> +// Static paging and heap guard could not be enabled at the same time.
>  //
>  ASSERT (!(mCpuSmmStaticPageTable &&
>(PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 
> 0));
> +
> +//
> +// Static paging and SMM profile could not be enabled at the same time.
> +//
> +ASSERT (!(mCpuSmmStaticPageTable && FeaturePcdGet 
> + (PcdCpuSmmProfileEnable)));
>  return ;
>}
>  
> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec 
> index d2965ba14c2d..36205ab63796 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dec
> +++ b/UefiCpuPkg/UefiCpuPkg.dec
> @@ -84,6 +84,7 @@ [Protocols]
>  [PcdsFeatureFlag]
>## Indicates if SMM Profile will be enabled.
>#  If enabled, instruction executions in and data accesses to memory 
> outside of SMRAM will be logged.
> +  #  It could not be enabled at the same time with SMM profile feature 
> (PcdCpuSmmStaticPageTable).
>#  This PCD is only for validation purpose. It should be set to false in 
> production.
>#   TRUE  - SMM Profile will be enabled.
>#   FALSE - SMM Profile will be disabled.
> @@ -225,8 +226,11 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, 
> PcdsDynamicEx]
>gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate|0|UINT8|0x0007
>  
>## Indicates if SMM uses static page table.
> -  #  If enabled, SMM will not use on-demand paging. SMM will build 
> static page table for all memory.
> +  #  If enabled, SMM will not use on-demand paging. SMM will build static 
> page table for all memory.
>#  This flag only impacts X64 build, because SMM alway builds static page 
> table for IA32.
> +  #  It could not be enabled at the same time with SMM profile feature 
> (PcdCpuSmmProfileEnable).
> +  #  It could not be enabled also at the same time with heap guard 
> + feature for SMM  #  (PcdHeapGuardPropertyMask in 
> + MdeModulePkg).
>#   

Re: [edk2] [Patch V2] BaseTools: Fix GenSec can't found the depex file

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: Zhu, Yonghong
> Sent: Friday, December 8, 2017 12:00 AM
> To: edk2-devel@lists.01.org
> Cc: Feng, YunhuaX ; Gao, Liming 
> Subject: [Patch V2] BaseTools: Fix GenSec can't found the depex file
> 
> From: Yunhua Feng 
> 
> Filter the FileList when multiple genfds thread options is not enabled.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Yunhua Feng 
> Signed-off-by: Yonghong Zhu 
> ---
>  BaseTools/Source/Python/GenFds/EfiSection.py | 5 +++--
>  BaseTools/Source/Python/GenFds/Section.py| 4 ++--
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/GenFds/EfiSection.py 
> b/BaseTools/Source/Python/GenFds/EfiSection.py
> index 7b3b717..5029ec7 100644
> --- a/BaseTools/Source/Python/GenFds/EfiSection.py
> +++ b/BaseTools/Source/Python/GenFds/EfiSection.py
> @@ -90,13 +90,14 @@ class EfiSection (EfiSectionClassObject):
>  if not self.Optional:
>  FileList.append(Filename)
>  elif os.path.exists(Filename):
>  FileList.append(Filename)
>  elif '.depex' in FfsInf.FinalTargetSuffixMap or FfsInf.Depex:
> -FileList.append(Filename)
> +if IsMakefile:
> +FileList.append(Filename)
>  else:
> -FileList, IsSect = Section.Section.GetFileList(FfsInf, 
> self.FileType, self.FileExtension, Dict)
> +FileList, IsSect = Section.Section.GetFileList(FfsInf, 
> self.FileType, self.FileExtension, Dict, IsMakefile=IsMakefile)
>  if IsSect :
>  return FileList, self.Alignment
> 
>  Index = 0
>  Align = self.Alignment
> diff --git a/BaseTools/Source/Python/GenFds/Section.py 
> b/BaseTools/Source/Python/GenFds/Section.py
> index 4c1aaac..463faa3 100644
> --- a/BaseTools/Source/Python/GenFds/Section.py
> +++ b/BaseTools/Source/Python/GenFds/Section.py
> @@ -108,11 +108,11 @@ class Section (SectionClassObject):
>  #   @param  FileTypeFile type to get
>  #   @param  FileExtension  File extension to get
>  #   @param  Dictdictionary contains macro and its value
>  #   @retval tuple   (File list, boolean)
>  #
> -def GetFileList(FfsInf, FileType, FileExtension, Dict = {}):
> +def GetFileList(FfsInf, FileType, FileExtension, Dict = {}, 
> IsMakefile=False):
>  if FileType in Section.SectFileType.keys() :
>  IsSect = True
>  else :
>  IsSect = False
> 
> @@ -139,11 +139,11 @@ class Section (SectionClassObject):
>  else:
>  GenFdsGlobalVariable.VerboseLogger ("\nFile Type 
> \'%s\' of File %s in %s is not same with file type \'%s\'
> from Rule in FDF" %(File.Type, File.File, FfsInf.InfFileName, FileType))
>  else:
>  GenFdsGlobalVariable.InfLogger ("\nCurrent ARCH \'%s\' 
> of File %s is not in the Support Arch Scope of %s
> specified by INF %s in FDF" %(FfsInf.CurrentArch, File.File, File.Arch, 
> FfsInf.InfFileName))
> 
> -if Suffix != None:
> +if (not IsMakefile and Suffix != None and 
> os.path.exists(FfsInf.EfiOutputPath)) or (IsMakefile and Suffix != None):
>  #
>  # Get Makefile path and time stamp
>  #
>  MakefileDir = FfsInf.EfiOutputPath[:-len('OUTPUT')]
>  Makefile = os.path.join(MakefileDir, 'Makefile')
> --
> 2.6.1.windows.1

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

[edk2] [PATCH] SecurityPkg:Tcg2Smm:Enabling TPM SIRQ interrupt support

[Zhang, Chao B]

1. Report TPM SIRQ interrupt resource through _CRS
2. Expose _SRS to update interrupt resource & FIFO/TIS interrupt related 
registers
   defined in TCG PC Client Platform TPM Profile (PTP) Specification spec
https://trustedcomputinggroup.org/wp-content/uploads/PC-Client-Specific-Platform-TPM-Profile-for-TPM-2-0-v43-150126.pdf
Note: IHV/OEM need to carefully verify this feature with OS TPM driver to make 
sure there is no impact to system/HW

Cc: Long Qin 
Cc: Jiewen Yao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chao Zhang 
---
 SecurityPkg/Tcg/Tcg2Smm/Tpm.asl | 112 +---
 1 file changed, 104 insertions(+), 8 deletions(-)

diff --git a/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl b/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
index cf0642e..68b5073 100644
--- a/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
+++ b/SecurityPkg/Tcg/Tcg2Smm/Tpm.asl
@@ -44,13 +44,6 @@ DefinitionBlock (
   Name (_STR, Unicode ("TPM 2.0 Device"))
 
   //
-  // Return the resource consumed by TPM device
-  //
-  Name (_CRS, ResourceTemplate () {
-Memory32Fixed (ReadWrite, 0xfed4, 0x5000)
-  })
-
-  //
   // Operational region for Smi port access
   //
   OperationRegion (SMIP, SystemIO, 0xB2, 1)
@@ -65,7 +58,19 @@ DefinitionBlock (
   OperationRegion (TPMR, SystemMemory, 0xfed4, 0x5000)
   Field (TPMR, AnyAcc, NoLock, Preserve)
   {
-ACC0, 8,
+ACC0, 8,  // TPM_ACCESS_0
+Offset(0x8),
+INTE, 32, // TPM_INT_ENABLE_0
+INTV, 8,  // TPM_INT_VECTOR_0
+Offset(0x10),
+INTS, 32, // TPM_INT_STATUS_0
+INTF, 32, // TPM_INTF_CAPABILITY_0
+STS0, 32, // TPM_STS_0
+Offset(0x24),
+FIFO, 32, // TPM_DATA_FIFO_0
+Offset(0x30),
+TID0, 32, // TPM_INTERFACE_ID_0
+  // ignore the rest
   }
 
   //
@@ -89,6 +94,97 @@ DefinitionBlock (
 UCRQ,   32  //   Phyical Presence request operation to Get User 
Confirmation Status 
   }
 
+  Name(RESO, ResourceTemplate () {
+Memory32Fixed (ReadWrite, 0xfed4, 0x5000, REGS)
+Interrupt(ResourceConsumer, Level, ActiveLow, Shared, , , IRQ) {12}
+  })
+
+  //
+  // Return the resource consumed by TPM device.
+  //
+  Method(_CRS,0,Serialized)
+  {
+Return(RESO)
+  }
+
+  //
+  // Set resources consumed by the TPM device. This is used to
+  // assign an interrupt number to the device. The input byte stream
+  // has to be the same as returned by _CRS (according to ACPI spec).
+  //
+  Method(_SRS,1,Serialized)
+  {
+//
+// Update resource descriptor
+// Use the field name to identify the offsets in the argument
+// buffer and RESO buffer.
+//
+CreateDWordField(Arg0, ^IRQ._INT, IRQ0)
+CreateDWordField(RESO, ^IRQ._INT, LIRQ)
+Store(IRQ0, LIRQ)
+
+CreateBitField(Arg0, ^IRQ._HE, ITRG)
+CreateBitField(RESO, ^IRQ._HE, LTRG)
+Store(ITRG, LTRG)
+
+CreateBitField(Arg0, ^IRQ._LL, ILVL)
+CreateBitField(RESO, ^IRQ._LL, LLVL)
+Store(ILVL, LLVL)
+
+//
+// Update TPM FIFO PTP/TIS interface only, identified by 
TPM_INTERFACE_ID_x lowest
+// nibble.
+//  - FIFO interface as defined in PTP for TPM 2.0 is active
+//  - FIFO interface as defined in TIS1.3 is active
+//
+If (LOr(LEqual (And (TID0, 0x0F), 0x00), LEqual (And (TID0, 0x0F), 
0x0F))) {
+  //
+  // If FIFO interface, interrupt vector register is
+  // available. TCG PTP specification allows only
+  // values 1..15 in this field. For other interrupts
+  // the field should stay 0.
+  //
+  If (LLess (IRQ0, 16)) {
+Store (And(IRQ0, 0xF), INTV)
+  }
+  //
+  // Interrupt enable register (TPM_INT_ENABLE_x) bits 3:4
+  // contains settings for interrupt polarity.
+  // The other bits of the byte enable individual interrupts.
+  // They should be all be zero, but to avoid changing the
+  // configuration, the other bits are be preserved.
+  // 00 - high level
+  // 01 - low level
+  // 10 - rising edge
+  // 11 - falling edge
+  //
+  // ACPI spec definitions:
+  // _HE: '1' is Edge, '0' is Level
+  // _LL: '1' is ActiveHigh, '0' is ActiveLow (inverted from TCG spec)
+  //
+  If (LEqual (ITRG, 1)) {
+Or(INTE, 0x0010, INTE)
+  } Else {
+And(INTE, 0xFFEF, INTE)
+  }
+  if (LEqual (ILVL, 0)) {
+Or(INTE, 0x0008, INTE)
+  } Else {
+And(INTE, 0xFFF7, INTE)
+  }
+}
+  }
+
+  //
+  // Possible resource settings.
+  // 

Re: [edk2] [RFC] MdeModulePkg/Ip4Dxe: fix ICMP echo reply memory leak

[Wu, Jiaxin]

Hi Gary,

Agree to generate a formal patch. You can attach the reviewed-by tag at the 
same time.

Can you help to file one Bugzilla for this issue?

BTW, Do you need us commit the patch or by yourself?

Thanks,
Jiaxin

> -Original Message-
> From: Heyi Guo [mailto:heyi@linaro.org]
> Sent: Thursday, December 7, 2017 8:23 PM
> To: Wu, Jiaxin ; linaro-u...@lists.linaro.org; edk2-
> de...@lists.01.org; Fu, Siyuan 
> Cc: Junbiao Hong ; Zeng, Star
> ; Dong, Eric ; Ni, Ruiyu
> 
> Subject: Re: [RFC] MdeModulePkg/Ip4Dxe: fix ICMP echo reply memory leak
> 
> Hi Siyuan and Jiaxin,
> 
> Thanks for your review; shall I generate a formal patch and post it
> again, as well as making some commit message refinement?
> 
> Regards,
> 
> 
> Gary (Heyi Guo)
> 
> 
> 在 12/7/2017 3:01 PM, Wu, Jiaxin 写道:
> > It's is good to me.
> >
> > Reviewed-by: Jiaxin Wu 
> >
> > Thanks,
> > Jiaxin
> >
> >
> >> -Original Message-
> >> From: Heyi Guo [mailto:heyi@linaro.org]
> >> Sent: Thursday, December 7, 2017 10:22 AM
> >> To: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org
> >> Cc: Heyi Guo ; Junbiao Hong
> >> ; Zeng, Star ; Dong,
> Eric
> >> ; Ni, Ruiyu ; Fu, Siyuan
> >> ; Wu, Jiaxin 
> >> Subject: [RFC] MdeModulePkg/Ip4Dxe: fix ICMP echo reply memory leak
> >>
> >> When UEFI receives IPMP echo packets it will enter Ip4IcmpReplyEcho
> >> function, and then call Ip4Output. However, if Ip4Output gets some
> >> error and exits early, e.g. fails to find the route entry, memory
> >> buffer of "Data" gets no chance to be freed and memory leak will be
> >> caused. If there is such an attacker in the network, we will see UEFI
> >> runs out of memory and system hangs.
> >>
> >> Network stack code is so complicated that this is just a RFC to fix
> >> this issue. Please provide your comments about this.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Junbiao Hong 
> >> Signed-off-by: Heyi Guo 
> >> Cc: Star Zeng 
> >> Cc: Eric Dong 
> >> Cc: Ruiyu Ni 
> >> Cc: Siyuan Fu 
> >> Cc: Jiaxin Wu 
> >> ---
> >>   MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c | 3 +++
> >>   1 file changed, 3 insertions(+)
> >>
> >> diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
> >> b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
> >> index b4b0864..ed6bdbe 100644
> >> --- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
> >> +++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
> >> @@ -267,6 +267,9 @@ Ip4IcmpReplyEcho (
> >>Ip4SysPacketSent,
> >>NULL
> >>);
> >> +  if (EFI_ERROR (Status)) {
> >> +NetbufFree (Data);
> >> +  }
> >>
> >>   ON_EXIT:
> >> NetbufFree (Packet);
> >> --
> >> 2.7.4

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

Re: [edk2] [platforms: PATCH v2 5/5] Marvell/Drivers: Drop 'PciEmulation' naming

[Marcin Wojtas]

Hi Ard,

2017-12-07 20:49 GMT+01:00 Ard Biesheuvel :
> Hi Marcin,
>
> On 7 December 2017 at 19:20, Marcin Wojtas  wrote:
>> 'PciEmulation' is not a proper naming for a driver, which
>> uses NonDiscoverableDeviceRegistrationLib for handling
>> the devices attached via internal bus of the SoC.
>> Rename it to MvNonDiscoverableDxe and move under
>> Silicon/Marvell/Drivers directory.
>>
>
> Thank you!
>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Marcin Wojtas 
>> ---
>>  Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf  
>>|  4 +--
>>  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc   
>>|  4 +--
>>  Silicon/Marvell/{PciEmulation/PciEmulation.c => 
>> Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c} | 26 
>> ++--
>>  Silicon/Marvell/{PciEmulation/PciEmulation.inf => 
>> Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf} |  8 +++---
>>  4 files changed, 21 insertions(+), 21 deletions(-)
>>  rename Silicon/Marvell/{PciEmulation/PciEmulation.c => 
>> Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c} (84%)
>>  rename Silicon/Marvell/{PciEmulation/PciEmulation.inf => 
>> Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf} (91%)
>>
>
> Could we please have
>
> Drivers/MvNonDiscoverableDxe/MvNonDiscoverableDxe.inf
>
> instead?
>

My intention was to keep a generic naming at the first level inside
the Silicon/Drivers/Marvell:
I2c  Net SdMmc  Spi

I can change it in a way you want, but to my taste
MvNonDiscoverableDxe doesn't fully fit the company above. Do you see
any possible compromise? :)

Best regards,
Marcin

>
>
>
>> diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf 
>> b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
>> index 6d57b9a..2bf409e 100644
>> --- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
>> +++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
>> @@ -135,8 +135,8 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
>>INF Silicon/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.inf
>>INF Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.inf
>>
>> -  # PciEmulation
>> -  INF Silicon/Marvell/PciEmulation/PciEmulation.inf
>> +  # NonDiscoverableDevices
>> +  INF 
>> Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf
>>INF 
>> MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
>>
>># SCSI
>> diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
>> b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
>> index 0eb3ef3..598810e 100644
>> --- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
>> +++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
>> @@ -440,8 +440,8 @@
>>EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
>>EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
>>
>> -  # PciEmulation
>> -  Silicon/Marvell/PciEmulation/PciEmulation.inf
>> +  # NonDiscoverableDevices
>> +  Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf
>>
>> MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
>>
>># SCSI
>> diff --git a/Silicon/Marvell/PciEmulation/PciEmulation.c 
>> b/Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
>> similarity index 84%
>> rename from Silicon/Marvell/PciEmulation/PciEmulation.c
>> rename to 
>> Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
>> index 35f1a87..abb2940 100644
>> --- a/Silicon/Marvell/PciEmulation/PciEmulation.c
>> +++ b/Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
>> @@ -55,7 +55,7 @@ STATIC UINT8 * CONST SdhciDeviceTable = FixedPcdGetPtr 
>> (PcdPciESdhci);
>>  //
>>  STATIC
>>  EFI_STATUS
>> -PciEmulationInitXhci (
>> +MvNonDiscoverableInitXhci (
>>)
>>  {
>>MVHW_NONDISCOVERABLE_DESC *Desc = 
>> @@ -63,7 +63,7 @@ PciEmulationInitXhci (
>>UINT8 i;
>>
>>if (PcdGetSize (PcdPciEXhci) < Desc->XhciDevCount) {
>> -DEBUG((DEBUG_ERROR, "PciEmulation: Wrong PcdPciEXhci format\n"));
>> +DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Wrong PcdPciEXhci format\n"));
>>  return EFI_INVALID_PARAMETER;
>>}
>>
>> @@ -82,7 +82,7 @@ PciEmulationInitXhci (
>> );
>>
>>  if (EFI_ERROR(Status)) {
>> -  DEBUG((DEBUG_ERROR, "PciEmulation: Cannot install Xhci device %d\n", 
>> i));
>> +  DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Cannot install Xhci device 
>> %d\n", i));
>>return Status;
>>  }
>>}
>> @@ -92,7 +92,7 @@ PciEmulationInitXhci (
>>
>>  STATIC
>>  EFI_STATUS
>> -PciEmulationInitAhci (
>> +MvNonDiscoverableInitAhci (
>>)
>>  {
>>MVHW_NONDISCOVERABLE_DESC *Desc = 
>> @@ -100,7 +100,7 @@ PciEmulationInitAhci (
>>UINT8 i;
>>
>>if (PcdGetSize (PcdPciEAhci) < Desc->AhciDevCount) {
>> -DEBUG((DEBUG_ERROR, "PciEmulation: Wrong PcdPciEAhci 

[edk2] [PATCH v4 0/2] quirks handling for SDHCI controllers

[Ard Biesheuvel]

Many SDHCI implementations exist that are almost spec complicant, and
could be driven by the generic SD/MMC host controller driver except
for some minimal necessary init time tweaks.

Adding such tweaks to the generic driver is undesirable. On the other
hand, forking the driver for every platform that has such a SDHCI
controller is problematic when it comes to upstreaming and ongoing
maintenance (which is arguably the point of upstreaming in the first
place).

So these patches propose a workaround that is minimally invasive on the
EDK2 side, but gives platforms a lot of leeway when it comes to applying
SDHCI quirks.

Changes since v3:
- remove PassThru argument from protocol members: it is unclear whether the
  protocol is available when the override protocol is invoked, and my
  example use case does not need it
- replace incorrect HandleProtocol with LocateProtocol, given that the override
  protocol is now a singleton instance
- merge notifier calls into SdMmcHcReset() and SdMmcHcInitHost (), this
  required changing the prototype to take a SD_MMC_HC_PRIVATE_DATA* argument
  and so the prototypes no longer belong in SdMmcPciHci.h and have been moved
  to SdMmcPciHcDxe.h
- use VOID* type for capability not UINT64* since we don't know its alignment

Changes since v2:
- use a singleton instance of the SD/MMC protocol rather than one per
  controller; this is needed to support 'reconnect -r', as pointed out
  by Ray
- use EDKII prefixes for all types defined by the protocol
- replace 'hook' with 'notify', and tweak some other identifiers
- add missing function comment headers for factored out functions

Changes since RFC/v1:
- add EFI_SD_MMC_PASS_THRU_PROTOCOL* member to override methods
- use UINT64* not VOID* to pass capability structure (which is always 64 bits
  in size)

Ard Biesheuvel (2):
  MdeModulePkg: introduce SD/MMC override protocol
  MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden

 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c   | 35 ++-
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h   | 36 
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf |  2 +
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 95 +--
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 35 ---
 MdeModulePkg/Include/Protocol/SdMmcOverride.h| 97 
 MdeModulePkg/MdeModulePkg.dec|  3 +
 7 files changed, 257 insertions(+), 46 deletions(-)
 create mode 100644 MdeModulePkg/Include/Protocol/SdMmcOverride.h

-- 
2.11.0

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

[edk2] [PATCH v4 1/2] MdeModulePkg: introduce SD/MMC override protocol

[Ard Biesheuvel]

Many ARM based SoCs have integrated SDHCI controllers, and often,
these implementations deviate in subtle ways from the pertinent
specifications. On the one hand, these deviations are quite easy
to work around, but on the other hand, having a collection of SoC
specific workarounds in the generic driver stack is undesirable.

So let's introduce an optional SD/MMC override protocol that we
can invoke at the appropriate moments in the device initialization.
That way, the workaround itself remains platform specific, but we
can still use the generic driver stack on such platforms.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/Include/Protocol/SdMmcOverride.h | 97 
 MdeModulePkg/MdeModulePkg.dec |  3 +
 2 files changed, 100 insertions(+)

diff --git a/MdeModulePkg/Include/Protocol/SdMmcOverride.h 
b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
new file mode 100644
index ..0d070023f9d3
--- /dev/null
+++ b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
@@ -0,0 +1,97 @@
+/** @file
+  Protocol to describe overrides required to support non-standard SDHCI
+  implementations
+
+  Copyright (c) 2017, Linaro, Ltd. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __SD_MMC_OVERRIDE_H__
+#define __SD_MMC_OVERRIDE_H__
+
+#include 
+
+#define EDKII_SD_MMC_OVERRIDE_PROTOCOL_GUID \
+  { 0xeaf9e3c1, 0xc9cd, 0x46db, { 0xa5, 0xe5, 0x5a, 0x12, 0x4c, 0x83, 0x23, 
0x23 } }
+
+#define EDKII_SD_MMC_OVERRIDE_PROTOCOL_VERSION0x1
+
+typedef struct _EDKII_SD_MMC_OVERRIDE EDKII_SD_MMC_OVERRIDE;
+
+typedef enum {
+  EdkiiSdMmcResetPre,
+  EdkiiSdMmcResetPost,
+  EdkiiSdMmcInitHostPre,
+  EdkiiSdMmcInitHostPost,
+} EDKII_SD_MMC_PHASE_TYPE;
+
+/**
+
+  Override function for SDHCI capability bits
+
+  @param[in]  ControllerHandle  The EFI_HANDLE of the controller.
+  @param[in]  Slot  The 0 based slot index.
+  @param[in,out]  SdMmcHcSlotCapability The SDHCI capability structure.
+
+  @retval EFI_SUCCESS   The override function completed successfully.
+  @retval EFI_NOT_FOUND The specified controller or slot does not 
exist.
+  @retval EFI_INVALID_PARAMETER SdMmcHcSlotCapability is NULL
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI * EDKII_SD_MMC_CAPABILITY) (
+  IN  EFI_HANDLE  ControllerHandle,
+  IN  UINT8   Slot,
+  IN  OUT VOID*SdMmcHcSlotCapability
+  );
+
+/**
+
+  Override function for SDHCI controller operations
+
+  @param[in]  ControllerHandle  The EFI_HANDLE of the controller.
+  @param[in]  Slot  The 0 based slot index.
+  @param[in]  PhaseType The type of operation and whether the
+hook is invoked right before (pre) or
+right after (post)
+
+  @retval EFI_SUCCESS   The override function completed successfully.
+  @retval EFI_NOT_FOUND The specified controller or slot does not 
exist.
+  @retval EFI_INVALID_PARAMETER PhaseType is invalid
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI * EDKII_SD_MMC_NOTIFY_PHASE) (
+  IN  EFI_HANDLE  ControllerHandle,
+  IN  UINT8   Slot,
+  IN  EDKII_SD_MMC_PHASE_TYPE PhaseType
+  );
+
+struct _EDKII_SD_MMC_OVERRIDE {
+  //
+  // Protocol version of this implementation
+  //
+  UINTN Version;
+  //
+  // Callback to override SD/MMC host controller capability bits
+  //
+  EDKII_SD_MMC_CAPABILITY   Capability;
+  //
+  // Callback to invoke SD/MMC override hooks
+  //
+  EDKII_SD_MMC_NOTIFY_PHASE NotifyPhase;
+};
+
+extern EFI_GUID gEdkiiSdMmcOverrideProtocolGuid;
+
+#endif
diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 856d67aceb21..64ceea029f94 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -562,6 +562,9 @@ [Protocols]
   ## Include/Protocol/SmmMemoryAttribute.h
   gEdkiiSmmMemoryAttributeProtocolGuid = { 0x69b792ea, 0x39ce, 0x402d, { 0xa2, 
0xa6, 0xf7, 0x21, 0xde, 0x35, 0x1d, 0xfe } }
 
+  ## Include/Protocol/SdMmcOverride.h
+  gEdkiiSdMmcOverrideProtocolGuid = { 0xeaf9e3c1, 0xc9cd, 0x46db, { 0xa5, 
0xe5, 0x5a, 0x12, 0x4c, 0x83, 0x23, 0x23 } }
+
 #
 # [Error.gEfiMdeModulePkgTokenSpaceGuid]
 #   0x8001 | Invalid value provided.
-- 
2.11.0

___
edk2-devel mailing list
edk2-devel@lists.01.org

[edk2] [PATCH v4 2/2] MdeModulePkg/SdMmcPciHcDxe: allow HC capabilities to be overridden

[Ard Biesheuvel]

Invoke the newly introduced SD/MMC override protocol to override
the capabilities register after reading it from the device registers,
and to call the pre/post host init and reset hooks at the appropriate
times.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
---
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c   | 35 +++-
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h   | 36 
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.inf |  2 +
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 95 ++--
 MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h | 35 
 5 files changed, 157 insertions(+), 46 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c 
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
index 0be8828abfcc..f923930bbae9 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c
@@ -17,6 +17,8 @@
 
 #include "SdMmcPciHcDxe.h"
 
+EDKII_SD_MMC_OVERRIDE   *mOverride;
+
 //
 // Driver Global Variables
 //
@@ -281,14 +283,14 @@ SdMmcPciHcEnumerateDevice (
 //
 // Reset the specified slot of the SD/MMC Pci Host Controller
 //
-Status = SdMmcHcReset (Private->PciIo, Slot);
+Status = SdMmcHcReset (Private, Slot);
 if (EFI_ERROR (Status)) {
   continue;
 }
 //
 // Reinitialize slot and restart identification process for the new 
attached device
 //
-Status = SdMmcHcInitHost (Private->PciIo, Slot, 
Private->Capability[Slot]);
+Status = SdMmcHcInitHost (Private, Slot);
 if (EFI_ERROR (Status)) {
   continue;
 }
@@ -601,6 +603,20 @@ SdMmcPciHcDriverBindingStart (
 goto Done;
   }
 
+  //
+  // Attempt to locate the singleton instance of the SD/MMC override protocol,
+  // which implements platform specific workarounds for non-standard SDHCI
+  // implementations.
+  //
+  if (mOverride == NULL) {
+Status = gBS->LocateProtocol (, NULL,
+(VOID **));
+if (!EFI_ERROR (Status)) {
+  DEBUG ((DEBUG_INFO, "%a: found SD/MMC override protocol\n",
+__FUNCTION__));
+}
+  }
+
   Support64BitDma = TRUE;
   for (Slot = FirstBar; Slot < (FirstBar + SlotNum); Slot++) {
 Private->Slot[Slot].Enable = TRUE;
@@ -609,6 +625,17 @@ SdMmcPciHcDriverBindingStart (
 if (EFI_ERROR (Status)) {
   continue;
 }
+if (mOverride != NULL && mOverride->Capability != NULL) {
+  Status = mOverride->Capability (
+Controller,
+Slot,
+>Capability[Slot]);
+  if (EFI_ERROR (Status)) {
+DEBUG ((DEBUG_WARN, "%a: Failed to override capability - %r\n",
+  __FUNCTION__, Status));
+continue;
+  }
+}
 DumpCapabilityReg (Slot, >Capability[Slot]);
 
 Support64BitDma &= Private->Capability[Slot].SysBus64;
@@ -627,7 +654,7 @@ SdMmcPciHcDriverBindingStart (
 //
 // Reset the specified slot of the SD/MMC Pci Host Controller
 //
-Status = SdMmcHcReset (PciIo, Slot);
+Status = SdMmcHcReset (Private, Slot);
 if (EFI_ERROR (Status)) {
   continue;
 }
@@ -642,7 +669,7 @@ SdMmcPciHcDriverBindingStart (
   continue;
 }
 
-Status = SdMmcHcInitHost (PciIo, Slot, Private->Capability[Slot]);
+Status = SdMmcHcInitHost (Private, Slot);
 if (EFI_ERROR (Status)) {
   continue;
 }
diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h 
b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
index 6a2a27969936..c683600f2ef2 100644
--- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
+++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h
@@ -35,6 +35,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "SdMmcPciHci.h"
@@ -43,6 +44,8 @@ extern EFI_COMPONENT_NAME_PROTOCOL  gSdMmcPciHcComponentName;
 extern EFI_COMPONENT_NAME2_PROTOCOL gSdMmcPciHcComponentName2;
 extern EFI_DRIVER_BINDING_PROTOCOL  gSdMmcPciHcDriverBinding;
 
+extern EDKII_SD_MMC_OVERRIDE*mOverride;
+
 #define SD_MMC_HC_PRIVATE_SIGNATURE  SIGNATURE_32 ('s', 'd', 't', 'f')
 
 #define SD_MMC_HC_PRIVATE_FROM_THIS(a) \
@@ -782,4 +785,37 @@ SdCardIdentification (
   IN UINT8  Slot
   );
 
+/**
+  Software reset the specified SD/MMC host controller.
+
+  @param[in] PrivateA pointer to the SD_MMC_HC_PRIVATE_DATA instance.
+  @param[in] Slot   The slot number of the SD card to send the command 
to.
+
+  @retval EFI_SUCCESS   The software reset executes successfully.
+  @retval OthersThe software reset fails.
+
+**/
+EFI_STATUS
+SdMmcHcReset (
+  IN SD_MMC_HC_PRIVATE_DATA *Private,
+  IN UINT8  Slot
+  );
+
+/**
+  Initial SD/MMC host controller 

Re: [edk2] [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650 GOP driver.

[Ard Biesheuvel]

On 7 December 2017 at 20:21, Evan Lloyd  wrote:
> Hi Ard.
>
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: 05 December 2017 21:28
>> To: Evan Lloyd 
>> Cc: edk2-devel@lists.01.org; Matteo Carlini ;
>> Leif Lindholm ; Girish Pathak
>> 
>> Subject: Re: [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650
>> GOP driver.
>>
>> On 5 December 2017 at 20:03, Evan Lloyd  wrote:
>> >
>> >
>> >> -Original Message-
>> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> >> Sent: 01 December 2017 17:19
>> >> To: Evan Lloyd 
>> >> Cc: edk2-devel@lists.01.org; Matteo Carlini ;
>> >> Leif Lindholm ; Girish Pathak
>> >> 
>> >> Subject: Re: [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650
>> GOP
>> >> driver.
>> >>
> ...
>> >> >
>> >> >> whatsoever. If you introduce any library classes that abstract
>> >> >> away the differences between platforms, you can include a Null
>> >> >> version of such a library that simply does ASSERT (FALSE) in every
>> function:
>> >> >> this
>> >> >
>> >> >  [[Evan Lloyd]] One could, indeed, do that.  We, however, would be
>> >> > very
>> >> reluctant to incur the overhead of rework in response to spurious
>> >> cavils from a maintainer when it is of no direct relevance to us.
>> >> >
>> >>
>> >> I don't think the suggestion that we evil maintainers are nothing but
>> >> an impediment to the likes of you and your team members doing the
>> >> actual work is justified.
>> >>
>> >> We are all on the same team here, and the goal is to make UEFI code
>> >> reusable for the customers of /your/ employer. Throwing stuff over
>> >> the fence != upstreaming, and it is my job as a maintainer to ensure
>> >> that code is still maintainable long after the original authors have
>> >> moved on to something else.
>> >>
>> >> ArmPlatformPkg is a perfect example where code reuse is much more
>> >> difficult than it needs to be, and we as maintainers need to deal
>> >> with contributors from other companies that have used it as
>> >> 'guidance' for how to architect their UEFI firmware, which is usually
>> >> filled with vexpress-isms that date back to before anyone currently
>> involved with UEFI can remember.
>> >>
>> >> This is why I have taken the time to sit down, go through all the
>> >> crap code, clean it up, refactor it and propose it on the list as
>> >> improvements. I even went so far as taking the preparatory Mali work
>> >> of your team and rebase it so that we can keep the bits that we may
>> >> share, and move the bits out that should not be kept in main EDK2
>> >> because they are being taken as gospel by engineers that are new to
>> >> ARM+UEFI.
>> >>
>> >> If this is too much to deal with for you, then fine, don't upstream your
>> code.
>> >> But if you do, you are going to have to play nice with the others,
>> >> including the maintainers.
>> >>
>> > [[Evan Lloyd]] Hi Ard.  Firstly, I apologize, I assumed from your name that
>> you were Dutch and would therefore probably have a lively sense of
>> humour.  Of course, if I have touched a nerve, that is unfortunate and I'm
>> sorry.
>>
>> No, the apparently blatantly obvious tongue-in-cheek nature of your
>> response was completely lost on me. But I know a person who does have a
>> lively sense of humour, so next time I will ask him for help.
>
>  [[Evan Lloyd]] I would like to extend my apology.  From comments others have 
> made it is apparent that my wording was too easily interpreted as just 
> offensive.  I shall try and resist the temptation to make such points with 
> dubious attempts at humour in the future, at least on fora like this where 
> they are out of place.  Het spijt me.
>

Thanks Evan, I appreciate that. Courier 10pt simply does not convey
the nuance in your writing, and I suppose the open source world may
have its own idiosyncrasies that are not always obvious to people who
are working on the outside. And for the record, you're wrong about me
not having a sense of humour: according to my mother, both my jokes
are hilarious.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v3 1/3] BaseTools/tools_def: add CLANG38 LTO versions for AARCH64 and ARM

[Ard Biesheuvel]

Extend the CLANG38 toolchain definition so it can be used for
ARM and AARCH64 as well. Note that this requires llvm-ar and
the LLVMgold.so linker plugin.

In preparation of doing the same for GCC5, this toolchain version
also departs from the custom of using -O0 for DEBUG builds, which
makes them needlessly slow. Instead, let's add a NOOPT flavor as
well, and enable optimization for DEBUG like the other architectures
do. (Note that this will require some trivial changes to the platform
description files)

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
---
v3: add workaround for CLANG 3.8, which suffers from the same issue with
intrinsics as GCC/LTO (in a nutshell, LTO processing may emit function
calls to intrinsics that have already been pruned from the input objects)
use -O1 for DEBUG instead of -O3, to reduce code size increase

v2: add missing -flto to CC flags, without that LTO is not actually enabled
(which is why I did not take Leif's Tested-by)
add -fno-lto to ASLC CC flags

 BaseTools/Conf/tools_def.template | 98 +++-
 1 file changed, 95 insertions(+), 3 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 91b135c2e569..8889f1bc488a 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -399,8 +399,8 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 #   Intel(r) ACPI Compiler from
 #   https://acpica.org/downloads
 #   CLANG38  -Linux-  Requires:
-# Clang v3.8, LLVMgold plugin and GNU binutils 
2.26 targeting x86_64-linux-gnu
-# Clang v3.9 or later, LLVMgold plugin and GNU 
binutils 2.28 targeting x86_64-linux-gnu
+# Clang v3.8, LLVMgold plugin and GNU binutils 
2.26 targeting x86_64-linux-gnu, aarch64-linux-gnu or arm-linux-gnueabi
+# Clang v3.9 or later, LLVMgold plugin and GNU 
binutils 2.28 targeting x86_64-linux-gnu, aarch64-linux-gnu or arm-linux-gnueabi
 #Optional:
 # Required to build platforms or ACPI tables:
 #   Intel(r) ACPI Compiler from
@@ -5652,6 +5652,7 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS = 
DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)
 *_CLANG38_*_MAKE_PATH   = make
 *_CLANG38_*_*_DLL   = ENV(CLANG38_DLL)
 *_CLANG38_*_ASL_PATH= DEF(UNIX_IASL_BIN)
+*_CLANG38_*_DTC_PATH= DEF(DTC_BIN)
 
 *_CLANG38_*_APP_FLAGS   =
 *_CLANG38_*_ASL_FLAGS   = DEF(IASL_FLAGS)
@@ -5663,7 +5664,8 @@ DEFINE CLANG38_X64_PREFIX   = ENV(CLANG38_BIN)
 DEFINE CLANG38_IA32_TARGET  = -target i686-pc-linux-gnu
 DEFINE CLANG38_X64_TARGET   = -target x86_64-pc-linux-gnu
 
-DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -Wno-empty-body 
-fno-stack-protector -mms-bitfields -Wno-address -Wno-shift-negative-value 
-Wno-parentheses-equality -Wno-unknown-pragmas 
-Wno-tautological-constant-out-of-range-compare 
-Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables 
-mno-sse -mno-mmx -msoft-float -mno-implicit-float  
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang 
-funsigned-char -fno-ms-extensions -Wno-null-dereference 
-Wno-tautological-compare -Wno-unknown-warning-option -Wno-varargs
+DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality 
-Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare 
-Wno-empty-body  -Wno-varargs
+DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) 
DEF(CLANG38_WARNING_OVERRIDES) -fno-stack-protector -mms-bitfields -Wno-address 
-Wno-shift-negative-value -Wno-unknown-pragmas 
-Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables 
-mno-sse -mno-mmx -msoft-float -mno-implicit-float  
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang 
-funsigned-char -fno-ms-extensions -Wno-null-dereference 
-Wno-unknown-warning-option
 
 ###
 # CLANG38 IA32 definitions
@@ -5739,6 +5741,96 @@ NOOPT_CLANG38_X64_CC_FLAGS = 
DEF(CLANG38_ALL_CC_FLAGS) -m64 "-DEFIAPI=__
 NOOPT_CLANG38_X64_DLINK_FLAGS  = DEF(GCC5_IA32_X64_DLINK_FLAGS) -Wl,-O0 
-Wl,-melf_x86_64 -Wl,--oformat=elf64-x86-64 -Wl,-pie -mcmodel=small
 NOOPT_CLANG38_X64_DLINK2_FLAGS = DEF(GCC5_X64_DLINK2_FLAGS) -O0
 
+##
+# CLANG38 ARM definitions
+##
+DEFINE CLANG38_ARM_TARGET= -target arm-linux-gnueabihf
+DEFINE CLANG38_ARM_CC_FLAGS  = DEF(GCC_ARM_CC_FLAGS) 
DEF(CLANG38_ARM_TARGET) DEF(CLANG38_WARNING_OVERRIDES) -mno-movt
+DEFINE CLANG38_ARM_DLINK_FLAGS   = DEF(CLANG38_ARM_TARGET) 
DEF(GCC_ARM_DLINK_FLAGS)
+
+*_CLANG38_ARM_PP_FLAGS   = DEF(GCC_PP_FLAGS)

[edk2] [PATCH v3 2/3] BaseTools/tools_def CLANG38: add -Wno-unused-const-variable

[Ard Biesheuvel]

Commit 8b6366f87584 ("BaseTools/GCC: set -Wno-unused-const-variable
on RELEASE builds") suppresses warnings about unused constant
variables in RELEASE builds when building with GCC, given that they
break the build under our warnings-as-errors policy.

Do the same for CLANG38.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=790
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Laszlo Ersek 
---
v3: add Laszlo's R-b

 BaseTools/Conf/tools_def.template | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 8889f1bc488a..896ec1a9f077 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -5664,7 +5664,7 @@ DEFINE CLANG38_X64_PREFIX   = ENV(CLANG38_BIN)
 DEFINE CLANG38_IA32_TARGET  = -target i686-pc-linux-gnu
 DEFINE CLANG38_X64_TARGET   = -target x86_64-pc-linux-gnu
 
-DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality 
-Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare 
-Wno-empty-body  -Wno-varargs
+DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality 
-Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare 
-Wno-empty-body -Wno-unused-const-variable -Wno-varargs
 DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) 
DEF(CLANG38_WARNING_OVERRIDES) -fno-stack-protector -mms-bitfields -Wno-address 
-Wno-shift-negative-value -Wno-unknown-pragmas 
-Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables 
-mno-sse -mno-mmx -msoft-float -mno-implicit-float  
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang 
-funsigned-char -fno-ms-extensions -Wno-null-dereference 
-Wno-unknown-warning-option
 
 ###
-- 
2.11.0

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

[edk2] [PATCH v3 3/3] BaseTool/tools_def GCC5: enable optimization for ARM/AARCH64 DEBUG builds

[Ard Biesheuvel]

Enable optimization for DEBUG builds, to make it more usable in terms of
performance, and to give more coverage to the LTO builds. Also, some
diagnostics are only enabled when optimization is enabled.
NOOPT builds can now also be created, which will retain the behavior DEBUG
builds had previously.

Note that this aligns ARM and AARCH64 with the x86 architectures, which
already use optimization for DEBUG builds.

In order to preserve existing behavior for users of older toolchains,
keep GCC49 and older as-is.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Acked-by: Laszlo Ersek 
---
v3: add Laszlo's ack

 BaseTools/Conf/tools_def.template | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 896ec1a9f077..98ab6dd45e81 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -5517,8 +5517,8 @@ RELEASE_GCC5_X64_DLINK_FLAGS = 
DEF(GCC5_X64_DLINK_FLAGS) -flto -Os
 *_GCC5_ARM_VFRPP_FLAGS   = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_VFRPP_FLAGS)
 *_GCC5_ARM_CC_XIPFLAGS   = DEF(GCC5_ARM_CC_XIPFLAGS)
 
-  DEBUG_GCC5_ARM_CC_FLAGS= DEF(GCC5_ARM_CC_FLAGS) -O0
-  DEBUG_GCC5_ARM_DLINK_FLAGS = DEF(GCC5_ARM_DLINK_FLAGS)
+  DEBUG_GCC5_ARM_CC_FLAGS= DEF(GCC5_ARM_CC_FLAGS) -flto 
-Wno-unused-but-set-variable -Wno-unused-const-variable
+  DEBUG_GCC5_ARM_DLINK_FLAGS = DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os 
-L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-arm 
-Wl,-plugin-opt=-pass-through=-llto-arm
 
 RELEASE_GCC5_ARM_CC_FLAGS= DEF(GCC5_ARM_CC_FLAGS) -flto 
-Wno-unused-but-set-variable -Wno-unused-const-variable
 RELEASE_GCC5_ARM_DLINK_FLAGS = DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os 
-L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-arm 
-Wl,-plugin-opt=-pass-through=-llto-arm
@@ -5551,8 +5551,8 @@ RELEASE_GCC5_ARM_DLINK_FLAGS = 
DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os -L$(WORKS
 *_GCC5_AARCH64_VFRPP_FLAGS   = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
DEF(GCC_VFRPP_FLAGS)
 *_GCC5_AARCH64_CC_XIPFLAGS   = DEF(GCC5_AARCH64_CC_XIPFLAGS)
 
-  DEBUG_GCC5_AARCH64_CC_FLAGS= DEF(GCC5_AARCH64_CC_FLAGS) -O0 
-mcmodel=small
-  DEBUG_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -z 
common-page-size=0x1000
+  DEBUG_GCC5_AARCH64_CC_FLAGS= DEF(GCC5_AARCH64_CC_FLAGS) -flto 
-Wno-unused-but-set-variable -Wno-unused-const-variable -mcmodel=small
+  DEBUG_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -z 
common-page-size=0x1000 -flto -Os -L$(WORKSPACE)/ArmPkg/Library/GccLto 
-llto-aarch64 -Wl,-plugin-opt=-pass-through=-llto-aarch64 
-Wno-lto-type-mismatch -mcmodel=small
   DEBUG_GCC5_AARCH64_DLINK_XIPFLAGS = -z common-page-size=0x20
 
 RELEASE_GCC5_AARCH64_CC_FLAGS= DEF(GCC5_AARCH64_CC_FLAGS) -flto 
-Wno-unused-but-set-variable -Wno-unused-const-variable -mcmodel=tiny
-- 
2.11.0

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

[edk2] [PATCH v3 0/3] BaseTools/tools_def: GCC5/CLANG38 toolchain updates

[Ard Biesheuvel]

Some toolchain updates for CLANG38 and GCC5:
- introduce CLANG38+LTO for ARM and AARCH64
- disable a warning on CLANG38
- enable optimization for GCC5 DEBUG builds

Ard Biesheuvel (3):
  BaseTools/tools_def: add CLANG38 LTO versions for AARCH64 and ARM
  BaseTools/tools_def CLANG38: add -Wno-unused-const-variable
  BaseTool/tools_def GCC5: enable optimization for ARM/AARCH64 DEBUG
builds

 BaseTools/Conf/tools_def.template | 106 ++--
 1 file changed, 99 insertions(+), 7 deletions(-)

-- 
2.11.0

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

Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR

[Ard Biesheuvel]

On 7 December 2017 at 20:33, Kinney, Michael D
 wrote:
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
>> On Behalf Of Ard Biesheuvel
>> Sent: Thursday, December 7, 2017 11:53 AM
>> To: Kinney, Michael D 
>> Cc: Alexei Fedorov ; edk2-
>> de...@lists.01.org; Leif Lindholm
>> ; Gao, Liming
>> 
>> Subject: Re: [edk2] [PATCH] MdePkg/DebugLib; swap if
>> conditions in ASSERT_[EFI|RETURN]_ERROR
>>
>> On 7 December 2017 at 19:49, Kinney, Michael D
>>  wrote:
>> > Ard,
>> >
>> > I do not disagree with your logic.
>> >
>> > The current algorithm is based on data from a long
>> > time ago using what are now very old tool chains.
>> >
>>
>> With LTO?
>
> Yes.  The LTCG feature for VS tool chains.
>
>>
>> > I will do some experiments on the currently supported
>> > toolchains to see if the optimization is the same
>> either
>> > way.
>> >
>>
>> Thank you.
>>
>> > I think the change you are suggesting is to improve
>> > performance for optimization disabled builds by
>> removing
>> > an extra call.  Is that correct?
>> >
>>
>> Well, for DEBUG builds, yes. But given that the function
>> call cannot
>> be optimized away (on non-LTO builds), it affects
>> optimized builds as
>> well.
>
> Do you mean compiler optimizations enabled, but linker
> optimizations disabled.
>

Basically, yes. LTO has only been added recently for GCC5 on
ARM/AARCH64, and we are currently adding support for CLANG38 as well.
CLANG35 and RVCT do not support LTO.

So non-LTO still needs to be supported as well, and in some
debugging/tracing contexts, having lots of needless function calls is
making our lives difficult. (Hence my additional comment regarding
ASSERT (), although I suppose in some cases, calculating the result of
the expression could be more costly than the actual function call)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR

[Kinney, Michael D]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of Ard Biesheuvel
> Sent: Thursday, December 7, 2017 11:53 AM
> To: Kinney, Michael D 
> Cc: Alexei Fedorov ; edk2-
> de...@lists.01.org; Leif Lindholm
> ; Gao, Liming
> 
> Subject: Re: [edk2] [PATCH] MdePkg/DebugLib; swap if
> conditions in ASSERT_[EFI|RETURN]_ERROR
> 
> On 7 December 2017 at 19:49, Kinney, Michael D
>  wrote:
> > Ard,
> >
> > I do not disagree with your logic.
> >
> > The current algorithm is based on data from a long
> > time ago using what are now very old tool chains.
> >
> 
> With LTO?

Yes.  The LTCG feature for VS tool chains.

> 
> > I will do some experiments on the currently supported
> > toolchains to see if the optimization is the same
> either
> > way.
> >
> 
> Thank you.
> 
> > I think the change you are suggesting is to improve
> > performance for optimization disabled builds by
> removing
> > an extra call.  Is that correct?
> >
> 
> Well, for DEBUG builds, yes. But given that the function
> call cannot
> be optimized away (on non-LTO builds), it affects
> optimized builds as
> well.

Do you mean compiler optimizations enabled, but linker
optimizations disabled.

> 
> --
> Ard.
> 
> 
> >> -Original Message-
> >> From: Ard Biesheuvel
> [mailto:ard.biesheu...@linaro.org]
> >> Sent: Thursday, December 7, 2017 9:43 AM
> >> To: Kinney, Michael D 
> >> Cc: Alexei Fedorov ; edk2-
> >> de...@lists.01.org; Gao, Liming
> ;
> >> Leif Lindholm 
> >> Subject: Re: [edk2] [PATCH] MdePkg/DebugLib; swap if
> >> conditions in ASSERT_[EFI|RETURN]_ERROR
> >>
> >> On 7 December 2017 at 17:36, Kinney, Michael D
> >>  wrote:
> >> > Ard,
> >> >
> >> > With link time optimization, the current order
> produces
> >> > smaller code.
> >> >
> >>
> >> I don't think it does. You are essentially saying that
> >> DebugAssertEnabled() may resolve to a link time
> constant
> >> FALSE under
> >> LTO.
> >>
> >> In that case, why would the following two statement
> not
> >> be equivalent?
> >>
> >> if (FALSE && EFI_ERROR (StatusParameter)) {}
> >>
> >> if (EFI_ERROR (StatusParameter) && FALSE) {}
> >>
> >> (which is essentially what a nested if () resolves to)
> >>
> >> In other words, the compiler is smart enough to drop
> the
> >> status check
> >> in the second case, because it can see there are no
> side
> >> effects, and
> >> the condition can never be made true anyway.
> >>
> >> > Without link time optimization, your patch will
> produce
> >> > smaller code, but not as small as link time
> optimized
> >> code.
> >> >
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650 GOP driver.

[Evan Lloyd]

Hi Ard.

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 05 December 2017 21:28
> To: Evan Lloyd 
> Cc: edk2-devel@lists.01.org; Matteo Carlini ;
> Leif Lindholm ; Girish Pathak
> 
> Subject: Re: [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650
> GOP driver.
>
> On 5 December 2017 at 20:03, Evan Lloyd  wrote:
> >
> >
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: 01 December 2017 17:19
> >> To: Evan Lloyd 
> >> Cc: edk2-devel@lists.01.org; Matteo Carlini ;
> >> Leif Lindholm ; Girish Pathak
> >> 
> >> Subject: Re: [PATCH 19/19] ArmPlatformPkg: New DP500/DP550/DP650
> GOP
> >> driver.
> >>
...
> >> >
> >> >> whatsoever. If you introduce any library classes that abstract
> >> >> away the differences between platforms, you can include a Null
> >> >> version of such a library that simply does ASSERT (FALSE) in every
> function:
> >> >> this
> >> >
> >> >  [[Evan Lloyd]] One could, indeed, do that.  We, however, would be
> >> > very
> >> reluctant to incur the overhead of rework in response to spurious
> >> cavils from a maintainer when it is of no direct relevance to us.
> >> >
> >>
> >> I don't think the suggestion that we evil maintainers are nothing but
> >> an impediment to the likes of you and your team members doing the
> >> actual work is justified.
> >>
> >> We are all on the same team here, and the goal is to make UEFI code
> >> reusable for the customers of /your/ employer. Throwing stuff over
> >> the fence != upstreaming, and it is my job as a maintainer to ensure
> >> that code is still maintainable long after the original authors have
> >> moved on to something else.
> >>
> >> ArmPlatformPkg is a perfect example where code reuse is much more
> >> difficult than it needs to be, and we as maintainers need to deal
> >> with contributors from other companies that have used it as
> >> 'guidance' for how to architect their UEFI firmware, which is usually
> >> filled with vexpress-isms that date back to before anyone currently
> involved with UEFI can remember.
> >>
> >> This is why I have taken the time to sit down, go through all the
> >> crap code, clean it up, refactor it and propose it on the list as
> >> improvements. I even went so far as taking the preparatory Mali work
> >> of your team and rebase it so that we can keep the bits that we may
> >> share, and move the bits out that should not be kept in main EDK2
> >> because they are being taken as gospel by engineers that are new to
> >> ARM+UEFI.
> >>
> >> If this is too much to deal with for you, then fine, don't upstream your
> code.
> >> But if you do, you are going to have to play nice with the others,
> >> including the maintainers.
> >>
> > [[Evan Lloyd]] Hi Ard.  Firstly, I apologize, I assumed from your name that
> you were Dutch and would therefore probably have a lively sense of
> humour.  Of course, if I have touched a nerve, that is unfortunate and I'm
> sorry.
>
> No, the apparently blatantly obvious tongue-in-cheek nature of your
> response was completely lost on me. But I know a person who does have a
> lively sense of humour, so next time I will ask him for help.

 [[Evan Lloyd]] I would like to extend my apology.  From comments others have 
made it is apparent that my wording was too easily interpreted as just 
offensive.  I shall try and resist the temptation to make such points with 
dubious attempts at humour in the future, at least on fora like this where they 
are out of place.  Het spijt me.

>
> > I agree that cleaning up the code is important, worthwhile, and an
> objective for us all.  What can be a difficulty is our very different
> conceptions of what clean means.
> >
>
> Fair enough. But as maintainers, we take ownership of your code, with the
> implied promise to keep it in a working state. I don't think it is
> unreasonable that we get to dictate some of the terms under which that
> occurs.
>
> > You should be aware though that a certain amount of whingeing is to be
> > expected when dealing with Brits. (Ask Leif - he knows! Or any Australian.)
> I do not disagree with your intent - but I do sometimes feel that the criteria
> applied do not take into account the cost/benefit aspects, and seek to air
> that point.  I shall endeavour to make such points in a less bantering way in
> future.
> >
>
> Thanks.
>
> I think one of the misconceptions may be that upstreaming is something
> one does once the code is completely finished. Instead, please involve us
> much sooner if you intend to upstream your code (or just Leif for
> confidential stuff). That way, any effort invested in the code benefits your
> product as well as the open source, rather than shipping one version, and
> having to go back and change stuff 

Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR

[Ard Biesheuvel]

On 7 December 2017 at 19:49, Kinney, Michael D
 wrote:
> Ard,
>
> I do not disagree with your logic.
>
> The current algorithm is based on data from a long
> time ago using what are now very old tool chains.
>

With LTO?

> I will do some experiments on the currently supported
> toolchains to see if the optimization is the same either
> way.
>

Thank you.

> I think the change you are suggesting is to improve
> performance for optimization disabled builds by removing
> an extra call.  Is that correct?
>

Well, for DEBUG builds, yes. But given that the function call cannot
be optimized away (on non-LTO builds), it affects optimized builds as
well.

-- 
Ard.


>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Thursday, December 7, 2017 9:43 AM
>> To: Kinney, Michael D 
>> Cc: Alexei Fedorov ; edk2-
>> de...@lists.01.org; Gao, Liming ;
>> Leif Lindholm 
>> Subject: Re: [edk2] [PATCH] MdePkg/DebugLib; swap if
>> conditions in ASSERT_[EFI|RETURN]_ERROR
>>
>> On 7 December 2017 at 17:36, Kinney, Michael D
>>  wrote:
>> > Ard,
>> >
>> > With link time optimization, the current order produces
>> > smaller code.
>> >
>>
>> I don't think it does. You are essentially saying that
>> DebugAssertEnabled() may resolve to a link time constant
>> FALSE under
>> LTO.
>>
>> In that case, why would the following two statement not
>> be equivalent?
>>
>> if (FALSE && EFI_ERROR (StatusParameter)) {}
>>
>> if (EFI_ERROR (StatusParameter) && FALSE) {}
>>
>> (which is essentially what a nested if () resolves to)
>>
>> In other words, the compiler is smart enough to drop the
>> status check
>> in the second case, because it can see there are no side
>> effects, and
>> the condition can never be made true anyway.
>>
>> > Without link time optimization, your patch will produce
>> > smaller code, but not as small as link time optimized
>> code.
>> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH v2 5/5] Marvell/Drivers: Drop 'PciEmulation' naming

[Ard Biesheuvel]

Hi Marcin,

On 7 December 2017 at 19:20, Marcin Wojtas  wrote:
> 'PciEmulation' is not a proper naming for a driver, which
> uses NonDiscoverableDeviceRegistrationLib for handling
> the devices attached via internal bus of the SoC.
> Rename it to MvNonDiscoverableDxe and move under
> Silicon/Marvell/Drivers directory.
>

Thank you!

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf   
>   |  4 +--
>  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
>   |  4 +--
>  Silicon/Marvell/{PciEmulation/PciEmulation.c => 
> Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c} | 26 
> ++--
>  Silicon/Marvell/{PciEmulation/PciEmulation.inf => 
> Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf} |  8 +++---
>  4 files changed, 21 insertions(+), 21 deletions(-)
>  rename Silicon/Marvell/{PciEmulation/PciEmulation.c => 
> Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c} (84%)
>  rename Silicon/Marvell/{PciEmulation/PciEmulation.inf => 
> Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf} (91%)
>

Could we please have

Drivers/MvNonDiscoverableDxe/MvNonDiscoverableDxe.inf

instead?




> diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf 
> b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
> index 6d57b9a..2bf409e 100644
> --- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
> +++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
> @@ -135,8 +135,8 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
>INF Silicon/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.inf
>INF Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.inf
>
> -  # PciEmulation
> -  INF Silicon/Marvell/PciEmulation/PciEmulation.inf
> +  # NonDiscoverableDevices
> +  INF Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf
>INF 
> MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
>
># SCSI
> diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
> b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> index 0eb3ef3..598810e 100644
> --- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> +++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> @@ -440,8 +440,8 @@
>EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
>EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
>
> -  # PciEmulation
> -  Silicon/Marvell/PciEmulation/PciEmulation.inf
> +  # NonDiscoverableDevices
> +  Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf
>
> MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
>
># SCSI
> diff --git a/Silicon/Marvell/PciEmulation/PciEmulation.c 
> b/Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
> similarity index 84%
> rename from Silicon/Marvell/PciEmulation/PciEmulation.c
> rename to 
> Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
> index 35f1a87..abb2940 100644
> --- a/Silicon/Marvell/PciEmulation/PciEmulation.c
> +++ b/Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
> @@ -55,7 +55,7 @@ STATIC UINT8 * CONST SdhciDeviceTable = FixedPcdGetPtr 
> (PcdPciESdhci);
>  //
>  STATIC
>  EFI_STATUS
> -PciEmulationInitXhci (
> +MvNonDiscoverableInitXhci (
>)
>  {
>MVHW_NONDISCOVERABLE_DESC *Desc = 
> @@ -63,7 +63,7 @@ PciEmulationInitXhci (
>UINT8 i;
>
>if (PcdGetSize (PcdPciEXhci) < Desc->XhciDevCount) {
> -DEBUG((DEBUG_ERROR, "PciEmulation: Wrong PcdPciEXhci format\n"));
> +DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Wrong PcdPciEXhci format\n"));
>  return EFI_INVALID_PARAMETER;
>}
>
> @@ -82,7 +82,7 @@ PciEmulationInitXhci (
> );
>
>  if (EFI_ERROR(Status)) {
> -  DEBUG((DEBUG_ERROR, "PciEmulation: Cannot install Xhci device %d\n", 
> i));
> +  DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Cannot install Xhci device 
> %d\n", i));
>return Status;
>  }
>}
> @@ -92,7 +92,7 @@ PciEmulationInitXhci (
>
>  STATIC
>  EFI_STATUS
> -PciEmulationInitAhci (
> +MvNonDiscoverableInitAhci (
>)
>  {
>MVHW_NONDISCOVERABLE_DESC *Desc = 
> @@ -100,7 +100,7 @@ PciEmulationInitAhci (
>UINT8 i;
>
>if (PcdGetSize (PcdPciEAhci) < Desc->AhciDevCount) {
> -DEBUG((DEBUG_ERROR, "PciEmulation: Wrong PcdPciEAhci format\n"));
> +DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Wrong PcdPciEAhci format\n"));
>  return EFI_INVALID_PARAMETER;
>}
>
> @@ -119,7 +119,7 @@ PciEmulationInitAhci (
> );
>
>  if (EFI_ERROR(Status)) {
> -  DEBUG((DEBUG_ERROR, "PciEmulation: Cannot install Ahci device %d\n", 
> i));
> +  DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Cannot install Ahci device 
> %d\n", i));
>return Status;
>  }
>}
> @@ -129,7 +129,7 @@ PciEmulationInitAhci (
>
>  STATIC
> 

Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR

[Kinney, Michael D]

Ard,

I do not disagree with your logic.

The current algorithm is based on data from a long
time ago using what are now very old tool chains.

I will do some experiments on the currently supported
toolchains to see if the optimization is the same either
way.

I think the change you are suggesting is to improve 
performance for optimization disabled builds by removing
an extra call.  Is that correct?

Mike

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, December 7, 2017 9:43 AM
> To: Kinney, Michael D 
> Cc: Alexei Fedorov ; edk2-
> de...@lists.01.org; Gao, Liming ;
> Leif Lindholm 
> Subject: Re: [edk2] [PATCH] MdePkg/DebugLib; swap if
> conditions in ASSERT_[EFI|RETURN]_ERROR
> 
> On 7 December 2017 at 17:36, Kinney, Michael D
>  wrote:
> > Ard,
> >
> > With link time optimization, the current order produces
> > smaller code.
> >
> 
> I don't think it does. You are essentially saying that
> DebugAssertEnabled() may resolve to a link time constant
> FALSE under
> LTO.
> 
> In that case, why would the following two statement not
> be equivalent?
> 
> if (FALSE && EFI_ERROR (StatusParameter)) {}
> 
> if (EFI_ERROR (StatusParameter) && FALSE) {}
> 
> (which is essentially what a nested if () resolves to)
> 
> In other words, the compiler is smart enough to drop the
> status check
> in the second case, because it can see there are no side
> effects, and
> the condition can never be made true anyway.
> 
> > Without link time optimization, your patch will produce
> > smaller code, but not as small as link time optimized
> code.
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH v2 4/5] Marvell/Drivers: Rename SPI master driver

[Ard Biesheuvel]

Hi Marcin,

On 7 December 2017 at 19:20, Marcin Wojtas  wrote:
> Hitherto driver name was very generic. In order to be ready
> for adding new SPI master drivers, use the controller's
> traditional name (it's called SPI Orion in Linux and
> U-Boot) for files and the entry point.
>
> Additionally, move the files to new 'Controllers' directory,
> which is paralel to existing 'Devices' and 'Variables', so
> that to make the separation more clear.
>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marcin Wojtas 
> ---
>  Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf  
> | 2 +-
>  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc   
> | 2 +-
>  Silicon/Marvell/Drivers/Spi/{MvSpiDxe.c => Controllers/MvSpiOrionDxe.c} 
> | 4 ++--
>  Silicon/Marvell/Drivers/Spi/{MvSpiDxe.h => Controllers/MvSpiOrionDxe.h} 
> | 0
>  Silicon/Marvell/Drivers/Spi/{MvSpiDxe.inf => Controllers/MvSpiOrionDxe.inf} 
> | 8 
>  5 files changed, 8 insertions(+), 8 deletions(-)
>  rename Silicon/Marvell/Drivers/Spi/{MvSpiDxe.c => 
> Controllers/MvSpiOrionDxe.c} (95%)
>  rename Silicon/Marvell/Drivers/Spi/{MvSpiDxe.h => 
> Controllers/MvSpiOrionDxe.h} (100%)
>  rename Silicon/Marvell/Drivers/Spi/{MvSpiDxe.inf => 
> Controllers/MvSpiOrionDxe.inf} (92%)

I think this is not entirely correct. With these patches applied, we have

Silicon/Marvell/Drivers/Spi/Variables
Silicon/Marvell/Drivers/Spi/Variables/MvFvbDxe.h
Silicon/Marvell/Drivers/Spi/Variables/MvFvbDxe.inf
Silicon/Marvell/Drivers/Spi/Variables/MvFvbDxe.c
Silicon/Marvell/Drivers/Spi/Devices
Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.h
Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.c
Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
Silicon/Marvell/Drivers/Spi/Controllers
Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.h
Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c

where each directory is named as if it could contain multiple drivers,
but given that each driver belongs in its own directory, we are
missing one directory level.

To be honest (but I will let Leif comment as well), I think you can
remove the Variables/Devices/Controllers distinction, and just have

Silicon/Marvell/Drivers/Spi/MvFvbDxe
Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.h
Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.inf
Silicon/Marvell/Drivers/Spi/MvFvbDxe/MvFvbDxe.c
Silicon/Marvell/Drivers/Spi/MvSpiFlash
Silicon/Marvell/Drivers/Spi/MvSpiFlash/MvSpiFlash.h
Silicon/Marvell/Drivers/Spi/MvSpiFlash/MvSpiFlash.c
Silicon/Marvell/Drivers/Spi/MvSpiFlash/MvSpiFlash.inf
Silicon/Marvell/Drivers/Spi/MvSpiOrionDxe
Silicon/Marvell/Drivers/Spi/MvSpiOrionDxe/MvSpiOrionDxe.h
Silicon/Marvell/Drivers/Spi/MvSpiOrionDxe/MvSpiOrionDxe.inf
Silicon/Marvell/Drivers/Spi/MvSpiOrionDxe/MvSpiOrionDxe.c


>
> diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf 
> b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
> index 3b0646e..6d57b9a 100644
> --- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
> +++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
> @@ -110,7 +110,7 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
>INF Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
>INF MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
>INF Silicon/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf
> -  INF Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
> +  INF Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
>INF Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
>INF 
> Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.inf
>
> diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
> b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> index 7d87766..0eb3ef3 100644
> --- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> +++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> @@ -411,7 +411,7 @@
>Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
>MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
>Silicon/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf
> -  Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
> +  Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
>Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
>Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.inf
>
> diff --git a/Silicon/Marvell/Drivers/Spi/MvSpiDxe.c 
> b/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c
> similarity index 95%
> rename from Silicon/Marvell/Drivers/Spi/MvSpiDxe.c
> rename to Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c
> index bab6cf4..c657daf 100755
> --- a/Silicon/Marvell/Drivers/Spi/MvSpiDxe.c
> +++ b/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c
> @@ -31,7 +31,7 @@ ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
> LIABILITY, OR TORT
>  SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>
>  
> 

[edk2] [platforms: PATCH v2 2/5] Marvell/Armada7k8k: Use '7k8k' prefix in the SoC drivers/libraries

[Marcin Wojtas]

As a part of files reorganization, switch to using '7k8k'
in all SoC-specific driver/library code instead of
'70x0'/'7040', so that to ensure consistent naming for
entire SoC family.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf 
 |  
2 +-
 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc  
 |  
6 +++---
 Silicon/Marvell/Armada7k8k/Drivers/{Armada70x0RngDxe/Armada70x0RngDxe.c => 
Armada7k8kRngDxe/Armada7k8kRngDxe.c}
 | 14 +++---
 Silicon/Marvell/Armada7k8k/Drivers/{Armada70x0RngDxe/Armada70x0RngDxe.inf => 
Armada7k8kRngDxe/Armada7k8kRngDxe.inf} 
|  6 +++---
 Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib => 
Armada7k8kLib}/AArch64/ArmPlatformHelper.S  
   |  0
 Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib => 
Armada7k8kLib}/ARM/ArmPlatformHelper.S  
   |  0
 Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib/Armada70x0Lib.c => 
Armada7k8kLib/Armada7k8kLib.c}  
   |  6 +++---
 Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib/Armada70x0Lib.inf => 
Armada7k8kLib/Armada7k8kLib.inf}
 | 10 +-
 Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib/Armada70x0LibMem.c => 
Armada7k8kLib/Armada7k8kLibMem.c}   
|  2 +-
 Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib/Armada70x0LibMem.h => 
Armada7k8kLib/Armada7k8kLibMem.h}   
|  0
 
Silicon/Marvell/Armada7k8k/Library/{Armada70x0MemoryInitPeiLib/Armada70x0MemoryInitPeiLib.c
 => Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.c} |  0
 
Silicon/Marvell/Armada7k8k/Library/{Armada70x0MemoryInitPeiLib/Armada70x0MemoryInitPeiLib.inf
 => Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.inf} |  4 ++--
 12 files changed, 25 insertions(+), 25 deletions(-)
 rename Silicon/Marvell/Armada7k8k/Drivers/{Armada70x0RngDxe/Armada70x0RngDxe.c 
=> Armada7k8kRngDxe/Armada7k8kRngDxe.c} (94%)
 rename 
Silicon/Marvell/Armada7k8k/Drivers/{Armada70x0RngDxe/Armada70x0RngDxe.inf => 
Armada7k8kRngDxe/Armada7k8kRngDxe.inf} (85%)
 rename Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib => 
Armada7k8kLib}/AArch64/ArmPlatformHelper.S (100%)
 rename Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib => 
Armada7k8kLib}/ARM/ArmPlatformHelper.S (100%)
 rename Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib/Armada70x0Lib.c => 
Armada7k8kLib/Armada7k8kLib.c} (90%)
 rename Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib/Armada70x0Lib.inf => 
Armada7k8kLib/Armada7k8kLib.inf} (93%)
 rename Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib/Armada70x0LibMem.c => 
Armada7k8kLib/Armada7k8kLibMem.c} (96%)
 rename Silicon/Marvell/Armada7k8k/Library/{Armada70x0Lib/Armada70x0LibMem.h => 
Armada7k8kLib/Armada7k8kLibMem.h} (100%)
 rename 
Silicon/Marvell/Armada7k8k/Library/{Armada70x0MemoryInitPeiLib/Armada70x0MemoryInitPeiLib.c
 => Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.c} (100%)
 rename 
Silicon/Marvell/Armada7k8k/Library/{Armada70x0MemoryInitPeiLib/Armada70x0MemoryInitPeiLib.inf
 => Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.inf} (90%)

diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf 
b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
index f63f42d..bba449a 100644
--- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
+++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
@@ -112,7 +112,7 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
   INF Silicon/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf
   INF Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
   INF Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
-  INF Silicon/Marvell/Armada7k8k/Drivers/Armada70x0RngDxe/Armada70x0RngDxe.inf
+  INF Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.inf
 
   # Variable services
   INF Silicon/Marvell/Drivers/Spi/Variables/MvFvbDxe.inf
diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index 75717e9..7d87766 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -32,7 +32,7 @@
 #SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #
 [LibraryClasses.common]
-  
ArmPlatformLib|Silicon/Marvell/Armada7k8k/Library/Armada70x0Lib/Armada70x0Lib.inf
+  
ArmPlatformLib|Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLib.inf
   ComPhyLib|Silicon/Marvell/Library/ComPhyLib/ComPhyLib.inf
   

[edk2] [platforms: PATCH v2 4/5] Marvell/Drivers: Rename SPI master driver

[Marcin Wojtas]

Hitherto driver name was very generic. In order to be ready
for adding new SPI master drivers, use the controller's
traditional name (it's called SPI Orion in Linux and
U-Boot) for files and the entry point.

Additionally, move the files to new 'Controllers' directory,
which is paralel to existing 'Devices' and 'Variables', so
that to make the separation more clear.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf  | 
2 +-
 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc   | 
2 +-
 Silicon/Marvell/Drivers/Spi/{MvSpiDxe.c => Controllers/MvSpiOrionDxe.c} | 
4 ++--
 Silicon/Marvell/Drivers/Spi/{MvSpiDxe.h => Controllers/MvSpiOrionDxe.h} | 0
 Silicon/Marvell/Drivers/Spi/{MvSpiDxe.inf => Controllers/MvSpiOrionDxe.inf} | 
8 
 5 files changed, 8 insertions(+), 8 deletions(-)
 rename Silicon/Marvell/Drivers/Spi/{MvSpiDxe.c => Controllers/MvSpiOrionDxe.c} 
(95%)
 rename Silicon/Marvell/Drivers/Spi/{MvSpiDxe.h => Controllers/MvSpiOrionDxe.h} 
(100%)
 rename Silicon/Marvell/Drivers/Spi/{MvSpiDxe.inf => 
Controllers/MvSpiOrionDxe.inf} (92%)

diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf 
b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
index 3b0646e..6d57b9a 100644
--- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
+++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
@@ -110,7 +110,7 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
   INF Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
   INF MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
   INF Silicon/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf
-  INF Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
+  INF Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
   INF Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
   INF Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.inf
 
diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index 7d87766..0eb3ef3 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -411,7 +411,7 @@
   Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
   MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
   Silicon/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf
-  Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
+  Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
   Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
   Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.inf
 
diff --git a/Silicon/Marvell/Drivers/Spi/MvSpiDxe.c 
b/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c
similarity index 95%
rename from Silicon/Marvell/Drivers/Spi/MvSpiDxe.c
rename to Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c
index bab6cf4..c657daf 100755
--- a/Silicon/Marvell/Drivers/Spi/MvSpiDxe.c
+++ b/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c
@@ -31,7 +31,7 @@ ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
LIABILITY, OR TORT
 SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 
 
***/
-#include "MvSpiDxe.h"
+#include "MvSpiOrionDxe.h"
 
 SPI_MASTER *mSpiMasterInstance;
 
@@ -399,7 +399,7 @@ SpiMasterInitProtocol (
 
 EFI_STATUS
 EFIAPI
-SpiMasterEntryPoint (
+SpiOrionEntryPoint (
   IN EFI_HANDLE   ImageHandle,
   IN EFI_SYSTEM_TABLE *SystemTable
   )
diff --git a/Silicon/Marvell/Drivers/Spi/MvSpiDxe.h 
b/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.h
similarity index 100%
rename from Silicon/Marvell/Drivers/Spi/MvSpiDxe.h
rename to Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.h
diff --git a/Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf 
b/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
similarity index 92%
rename from Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
rename to Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
index e7bc170..3f85b40 100644
--- a/Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
+++ b/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
@@ -31,15 +31,15 @@
 
 [Defines]
   INF_VERSION= 0x00010005
-  BASE_NAME  = SpiMasterDxe
+  BASE_NAME  = SpiOrionDxe
   FILE_GUID  = c19dbc8a-f4f9-43b0-aee5-802e3ed03d15
   MODULE_TYPE= DXE_RUNTIME_DRIVER
   VERSION_STRING = 1.0
-  ENTRY_POINT= SpiMasterEntryPoint
+  ENTRY_POINT= SpiOrionEntryPoint
 
 [Sources]
-  MvSpiDxe.c
-  MvSpiDxe.h
+  MvSpiOrionDxe.c
+  MvSpiOrionDxe.h
 
 [Packages]
   EmbeddedPkg/EmbeddedPkg.dec
-- 
2.7.4

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

[edk2] [platforms: PATCH v2 5/5] Marvell/Drivers: Drop 'PciEmulation' naming

[Marcin Wojtas]

'PciEmulation' is not a proper naming for a driver, which
uses NonDiscoverableDeviceRegistrationLib for handling
the devices attached via internal bus of the SoC.
Rename it to MvNonDiscoverableDxe and move under
Silicon/Marvell/Drivers directory.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf 
|  4 +--
 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc  
|  4 +--
 Silicon/Marvell/{PciEmulation/PciEmulation.c => 
Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c} | 26 
++--
 Silicon/Marvell/{PciEmulation/PciEmulation.inf => 
Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf} |  8 +++---
 4 files changed, 21 insertions(+), 21 deletions(-)
 rename Silicon/Marvell/{PciEmulation/PciEmulation.c => 
Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c} (84%)
 rename Silicon/Marvell/{PciEmulation/PciEmulation.inf => 
Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf} (91%)

diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf 
b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
index 6d57b9a..2bf409e 100644
--- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
+++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
@@ -135,8 +135,8 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
   INF Silicon/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.inf
   INF Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.inf
 
-  # PciEmulation
-  INF Silicon/Marvell/PciEmulation/PciEmulation.inf
+  # NonDiscoverableDevices
+  INF Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf
   INF 
MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
 
   # SCSI
diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index 0eb3ef3..598810e 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -440,8 +440,8 @@
   EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
   EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
 
-  # PciEmulation
-  Silicon/Marvell/PciEmulation/PciEmulation.inf
+  # NonDiscoverableDevices
+  Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf
   
MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
 
   # SCSI
diff --git a/Silicon/Marvell/PciEmulation/PciEmulation.c 
b/Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
similarity index 84%
rename from Silicon/Marvell/PciEmulation/PciEmulation.c
rename to Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
index 35f1a87..abb2940 100644
--- a/Silicon/Marvell/PciEmulation/PciEmulation.c
+++ b/Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
@@ -55,7 +55,7 @@ STATIC UINT8 * CONST SdhciDeviceTable = FixedPcdGetPtr 
(PcdPciESdhci);
 //
 STATIC
 EFI_STATUS
-PciEmulationInitXhci (
+MvNonDiscoverableInitXhci (
   )
 {
   MVHW_NONDISCOVERABLE_DESC *Desc = 
@@ -63,7 +63,7 @@ PciEmulationInitXhci (
   UINT8 i;
 
   if (PcdGetSize (PcdPciEXhci) < Desc->XhciDevCount) {
-DEBUG((DEBUG_ERROR, "PciEmulation: Wrong PcdPciEXhci format\n"));
+DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Wrong PcdPciEXhci format\n"));
 return EFI_INVALID_PARAMETER;
   }
 
@@ -82,7 +82,7 @@ PciEmulationInitXhci (
);
 
 if (EFI_ERROR(Status)) {
-  DEBUG((DEBUG_ERROR, "PciEmulation: Cannot install Xhci device %d\n", i));
+  DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Cannot install Xhci device 
%d\n", i));
   return Status;
 }
   }
@@ -92,7 +92,7 @@ PciEmulationInitXhci (
 
 STATIC
 EFI_STATUS
-PciEmulationInitAhci (
+MvNonDiscoverableInitAhci (
   )
 {
   MVHW_NONDISCOVERABLE_DESC *Desc = 
@@ -100,7 +100,7 @@ PciEmulationInitAhci (
   UINT8 i;
 
   if (PcdGetSize (PcdPciEAhci) < Desc->AhciDevCount) {
-DEBUG((DEBUG_ERROR, "PciEmulation: Wrong PcdPciEAhci format\n"));
+DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Wrong PcdPciEAhci format\n"));
 return EFI_INVALID_PARAMETER;
   }
 
@@ -119,7 +119,7 @@ PciEmulationInitAhci (
);
 
 if (EFI_ERROR(Status)) {
-  DEBUG((DEBUG_ERROR, "PciEmulation: Cannot install Ahci device %d\n", i));
+  DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Cannot install Ahci device 
%d\n", i));
   return Status;
 }
   }
@@ -129,7 +129,7 @@ PciEmulationInitAhci (
 
 STATIC
 EFI_STATUS
-PciEmulationInitSdhci (
+MvNonDiscoverableInitSdhci (
   )
 {
   MVHW_NONDISCOVERABLE_DESC *Desc = 
@@ -137,7 +137,7 @@ PciEmulationInitSdhci (
   UINT8 i;
 
   if (PcdGetSize (PcdPciESdhci) < Desc->SdhciDevCount) {
-DEBUG((DEBUG_ERROR, "PciEmulation: Wrong PcdPciESdhci format\n"));
+DEBUG((DEBUG_ERROR, "MvNonDiscoverable: Wrong PcdPciESdhci format\n"));
 return EFI_INVALID_PARAMETER;
   }
 
@@ 

[edk2] [platforms: PATCH v2 3/5] Marvell/Armada70x0Db: Rename fd file

[Marcin Wojtas]

Hitherto fd file name was pretty generic, so use one,
which reflects actual board model.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf 
b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
index bba449a..3b0646e 100644
--- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
+++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
@@ -24,7 +24,7 @@
 #
 

 
-[FD.Armada70x0_EFI]
+[FD.Armada70x0Db_EFI]
 BaseAddress   = 0x|gArmTokenSpaceGuid.PcdFdBaseAddress  # The base 
address of the Firmware in NOR Flash.
 Size  = 0x0040|gArmTokenSpaceGuid.PcdFdSize # The size in 
bytes of the FLASH Device
 ErasePolarity = 1
-- 
2.7.4

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

[edk2] [platforms: PATCH v2 0/5] Armada 7k/8k files reorganization

[Marcin Wojtas]

Hi,

This is v2 of the reorganization - same commits with rename-aware
patch generation.

I submit a long awaited file reorganization of Marvell Armada 7k/8k
SoC family support. Armada 70x0 DB files remained in
'Platform/Marvell', SoC files, drivers, libraries, etc. were
shifted to 'Silicon/Marvell'.

Although there are no functional changes, other most significant
modifications are:
- use 'Armada7k8k' name/prefix, reflecting the SoC family properly
- use 'Armada70x0Db' for a board files
- move and rename the SPI master driver
- move and rename the PciEmulation driver
- rename output fd file for Armada70x0Db

More details can be found in the commit log. In order to get a
better overview, please check 'tree' command outputs below.

The code is available in the github:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/reorg-upstream-r20171207

I'm looking forward to your feedback.

Best regards,
Marcin

NEW FILE STRUCTURE:
==
tree Platform/Marvell/

Platform/Marvell/
└── Armada70x0Db
├── Armada70x0Db.dsc
└── Armada70x0Db.fdf

==
tree Silicon/Marvell/

Silicon/Marvell/
├── Applications
│   ├── EepromCmd
│   │   ├── EepromCmd.c
│   │   ├── EepromCmd.inf
│   │   └── EepromCmd.uni
│   ├── FirmwareUpdate
│   │   ├── FUpdate.c
│   │   ├── FUpdate.inf
│   │   └── FUpdate.uni
│   └── SpiTool
│   ├── SpiFlashCmd.c
│   ├── SpiFlashCmd.inf
│   └── SpiFlashCmd.uni
├── Armada7k8k
│   ├── Armada7k8k.dsc.inc
│   ├── Drivers
│   │   ├── Armada7k8kRngDxe
│   │   │   ├── Armada7k8kRngDxe.c
│   │   │   └── Armada7k8kRngDxe.inf
│   │   └── PlatInitDxe
│   │   ├── PlatInitDxe.c
│   │   └── PlatInitDxe.inf
│   └── Library
│   ├── Armada7k8kLib
│   │   ├── AArch64
│   │   │   └── ArmPlatformHelper.S
│   │   ├── ARM
│   │   │   └── ArmPlatformHelper.S
│   │   ├── Armada7k8kLib.c
│   │   ├── Armada7k8kLib.inf
│   │   ├── Armada7k8kLibMem.c
│   │   └── Armada7k8kLibMem.h
│   ├── Armada7k8kMemoryInitPeiLib
│   │   ├── Armada7k8kMemoryInitPeiLib.c
│   │   └── Armada7k8kMemoryInitPeiLib.inf
│   └── RealTimeClockLib
│   ├── RealTimeClockLib.c
│   ├── RealTimeClockLib.h
│   └── RealTimeClockLib.inf
├── Documentation
│   ├── Drivers
│   │   ├── EepromDriver.txt
│   │   ├── I2cDriver.txt
│   │   └── SpiDriver.txt
│   └── PortingGuide.txt
├── Drivers
│   ├── I2c
│   │   ├── Devices
│   │   │   └── MvEeprom
│   │   │   ├── MvEeprom.c
│   │   │   ├── MvEeprom.h
│   │   │   └── MvEeprom.inf
│   │   └── MvI2cDxe
│   │   ├── MvI2cDxe.c
│   │   ├── MvI2cDxe.h
│   │   └── MvI2cDxe.inf
│   ├── Net
│   │   ├── MvMdioDxe
│   │   │   ├── MvMdioDxe.c
│   │   │   ├── MvMdioDxe.h
│   │   │   └── MvMdioDxe.inf
│   │   ├── Phy
│   │   │   └── MvPhyDxe
│   │   │   ├── MvPhyDxe.c
│   │   │   ├── MvPhyDxe.h
│   │   │   └── MvPhyDxe.inf
│   │   └── Pp2Dxe
│   │   ├── Mvpp2Lib.c
│   │   ├── Mvpp2Lib.h
│   │   ├── Mvpp2LibHw.h
│   │   ├── Pp2Dxe.c
│   │   ├── Pp2Dxe.h
│   │   └── Pp2Dxe.inf
│   ├── NonDiscoverableDevices
│   │   ├── MvNonDiscoverableDxe.c
│   │   └── MvNonDiscoverableDxe.inf
│   ├── SdMmc
│   │   └── XenonDxe
│   │   ├── ComponentName.c
│   │   ├── EmmcDevice.c
│   │   ├── SdDevice.c
│   │   ├── SdMmcPciHcDxe.c
│   │   ├── SdMmcPciHcDxeExtra.uni
│   │   ├── SdMmcPciHcDxe.h
│   │   ├── SdMmcPciHcDxe.inf
│   │   ├── SdMmcPciHcDxe.uni
│   │   ├── SdMmcPciHci.c
│   │   ├── SdMmcPciHci.h
│   │   ├── XenonSdhci.c
│   │   └── XenonSdhci.h
│   └── Spi
│   ├── Controllers
│   │   ├── MvSpiOrionDxe.c
│   │   ├── MvSpiOrionDxe.h
│   │   └── MvSpiOrionDxe.inf
│   ├── Devices
│   │   ├── MvSpiFlash.c
│   │   ├── MvSpiFlash.h
│   │   └── MvSpiFlash.inf
│   └── Variables
│   ├── MvFvbDxe.c
│   ├── MvFvbDxe.h
│   └── MvFvbDxe.inf
├── Include
│   ├── Library
│   │   ├── MppLib.h
│   │   ├── MvComPhyLib.h
│   │   ├── MvHwDescLib.h
│   │   └── UtmiPhyLib.h
│   └── Protocol
│   ├── Eeprom.h
│   ├── Mdio.h
│   ├── MvPhy.h
│   ├── SpiFlash.h
│   └── Spi.h
├── Library
│   ├── ComPhyLib
│   │   ├── ComPhyCp110.c
│   │   ├── ComPhyLib.c
│   │   ├── ComPhyLib.h
│   │   ├── ComPhyLib.inf
│   │   └── ComPhyMux.c
│   ├── MppLib
│   │   ├── MppLib.c
│   │   └── MppLib.inf
│   └── UtmiPhyLib
│   ├── UtmiPhyLib.c
│   ├── UtmiPhyLib.h
│   └── UtmiPhyLib.inf
└── Marvell.dec

==

Marcin Wojtas (5):
  Marvell: Reorganize file structure
  Marvell/Armada7k8k: Use '7k8k' prefix in the SoC drivers/libraries
  Marvell/Armada70x0Db: Rename fd file
  Marvell/Drivers: Rename SPI master driver
  Marvell/Drivers: Drop 'PciEmulation' naming

 Platform/Marvell/{Armada/Armada70x0.dsc => Armada70x0Db/Armada70x0Db.dsc}  

 

[edk2] [platforms: PATCH v2 1/5] Marvell: Reorganize file structure

[Marcin Wojtas]

In edk2-platforms it is expected to provide a separation between
SoC and boards files in 'Silicon' and 'Platform' directories
accordingly.

This patch aligns Marvell code to this requirement with no functional
changes in the actual source files, unless required due to modified
paths. Change the supported board's files names to proper Armada70x0Db.

Also rename 'Armada' directory to 'Armada7k8k' in order to properly
refer to the SoC family and prevent confusion in future, when
adding new Armada machines. On the occasion add ARM copyright,
which was wrongly missing in the dsc.inc file.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/{Armada/Armada70x0.dsc => Armada70x0Db/Armada70x0Db.dsc}  
   |   6 +--
 Platform/Marvell/{Armada/Armada70x0.fdf => Armada70x0Db/Armada70x0Db.fdf}  
   |  24 +--
 {Platform => Silicon}/Marvell/Applications/EepromCmd/EepromCmd.c   
   |   0
 {Platform => Silicon}/Marvell/Applications/EepromCmd/EepromCmd.inf 
   |   2 +-
 {Platform => Silicon}/Marvell/Applications/EepromCmd/EepromCmd.uni 
   | Bin
 {Platform => Silicon}/Marvell/Applications/FirmwareUpdate/FUpdate.c
   |   0
 {Platform => Silicon}/Marvell/Applications/FirmwareUpdate/FUpdate.inf  
   |   2 +-
 {Platform => Silicon}/Marvell/Applications/FirmwareUpdate/FUpdate.uni  
   | Bin
 {Platform => Silicon}/Marvell/Applications/SpiTool/SpiFlashCmd.c   
   |   0
 {Platform => Silicon}/Marvell/Applications/SpiTool/SpiFlashCmd.inf 
   |   2 +-
 {Platform => Silicon}/Marvell/Applications/SpiTool/SpiFlashCmd.uni 
   | Bin
 Platform/Marvell/Armada/Armada.dsc.inc => 
Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc   
|  44 ++--
 {Platform/Marvell/Armada => 
Silicon/Marvell/Armada7k8k}/Drivers/Armada70x0RngDxe/Armada70x0RngDxe.c 
  |   0
 {Platform/Marvell/Armada => 
Silicon/Marvell/Armada7k8k}/Drivers/Armada70x0RngDxe/Armada70x0RngDxe.inf   
  |   2 +-
 {Platform/Marvell/Armada => 
Silicon/Marvell/Armada7k8k}/Drivers/PlatInitDxe/PlatInitDxe.c   
  |   0
 {Platform/Marvell/Armada => 
Silicon/Marvell/Armada7k8k}/Drivers/PlatInitDxe/PlatInitDxe.inf 
  |   2 +-
 {Platform/Marvell/Armada => 
Silicon/Marvell/Armada7k8k}/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S   
  |   0
 {Platform/Marvell/Armada => 
Silicon/Marvell/Armada7k8k}/Library/Armada70x0Lib/ARM/ArmPlatformHelper.S   
  |   0
 {Platform/Marvell/Armada => 
Silicon/Marvell/Armada7k8k}/Library/Armada70x0Lib/Armada70x0Lib.c   
  |   0
 {Platform/Marvell/Armada => 
Silicon/Marvell/Armada7k8k}/Library/Armada70x0Lib/Armada70x0Lib.inf 
  |   2 +-
 {Platform/Marvell/Armada => 
Silicon/Marvell/Armada7k8k}/Library/Armada70x0Lib/Armada70x0LibMem.c
  |   0
 {Platform/Marvell/Armada => 
Silicon/Marvell/Armada7k8k}/Library/Armada70x0Lib/Armada70x0LibMem.h
  |   0
 {Platform/Marvell/Armada => 
Silicon/Marvell/Armada7k8k}/Library/Armada70x0MemoryInitPeiLib/Armada70x0MemoryInitPeiLib.c
   |   0
 {Platform/Marvell/Armada => 
Silicon/Marvell/Armada7k8k}/Library/Armada70x0MemoryInitPeiLib/Armada70x0MemoryInitPeiLib.inf
 |   2 +-
 {Platform/Marvell/Armada => 
Silicon/Marvell/Armada7k8k}/Library/RealTimeClockLib/RealTimeClockLib.c 
  |   0
 {Platform/Marvell/Armada => 
Silicon/Marvell/Armada7k8k}/Library/RealTimeClockLib/RealTimeClockLib.h 
  |   0
 {Platform/Marvell/Armada => 
Silicon/Marvell/Armada7k8k}/Library/RealTimeClockLib/RealTimeClockLib.inf   
  |   2 +-
 {Platform => Silicon}/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.c  
   |   0
 {Platform => Silicon}/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.h  
   |   0
 {Platform => Silicon}/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf
   |   2 +-
 {Platform => Silicon}/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.c  
   |   0
 {Platform => Silicon}/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.h  
   |   0
 {Platform => 

Re: [edk2] [platforms: PATCH 0/5] Armada 7k/8k files reorganization

[Marcin Wojtas]

2017-12-07 20:07 GMT+01:00 Ard Biesheuvel :
> On 7 December 2017 at 19:06, Marcin Wojtas  wrote:
>> Hi Ard,
>>
>> 2017-12-07 17:48 GMT+01:00 Ard Biesheuvel :
>>> On 7 December 2017 at 16:31, Marcin Wojtas  wrote:
 Hi,

 I submit a long awaited file reorganization of Marvell Armada 7k/8k
 SoC family support. Armada 70x0 DB files remained in
 'Platform/Marvell', SoC files, drivers, libraries, etc. were
 shifted to 'Silicon/Marvell'.

 Although there are no functional changes, other most significant
 modifications are:
 - use 'Armada7k8k' name/prefix, reflecting the SoC family properly
 - use 'Armada70x0Db' for a board files
 - move and rename the SPI master driver
 - move and rename the PciEmulation driver
 - rename output fd file for Armada70x0Db

 More details can be found in the commit log. In order to get a
 better overview, please check 'tree' command outputs below.

 The code is available in the github:
 https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/reorg-upstream-r20171207

 I'm looking forward to your feedback.

>>>
>>> Hi Marcin,
>>>
>>> Could you regenerate these patches with rename detection please?
>>>
>>
>> For every single operation I used 'git mv'. 'git status' showed the
>> renaming properly and so does 'git show -M' on my branch. I'll search
>> for better 'git format-patch' generation, but if you know  the trick,
>> please share.
>>
>
> git format-patch -M does not work for you?

'git format-patch --find-renames' works fine. I'll issue v2 right away.

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

Re: [edk2] [platforms: PATCH 0/5] Armada 7k/8k files reorganization

[Ard Biesheuvel]

On 7 December 2017 at 19:06, Marcin Wojtas  wrote:
> Hi Ard,
>
> 2017-12-07 17:48 GMT+01:00 Ard Biesheuvel :
>> On 7 December 2017 at 16:31, Marcin Wojtas  wrote:
>>> Hi,
>>>
>>> I submit a long awaited file reorganization of Marvell Armada 7k/8k
>>> SoC family support. Armada 70x0 DB files remained in
>>> 'Platform/Marvell', SoC files, drivers, libraries, etc. were
>>> shifted to 'Silicon/Marvell'.
>>>
>>> Although there are no functional changes, other most significant
>>> modifications are:
>>> - use 'Armada7k8k' name/prefix, reflecting the SoC family properly
>>> - use 'Armada70x0Db' for a board files
>>> - move and rename the SPI master driver
>>> - move and rename the PciEmulation driver
>>> - rename output fd file for Armada70x0Db
>>>
>>> More details can be found in the commit log. In order to get a
>>> better overview, please check 'tree' command outputs below.
>>>
>>> The code is available in the github:
>>> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/reorg-upstream-r20171207
>>>
>>> I'm looking forward to your feedback.
>>>
>>
>> Hi Marcin,
>>
>> Could you regenerate these patches with rename detection please?
>>
>
> For every single operation I used 'git mv'. 'git status' showed the
> renaming properly and so does 'git show -M' on my branch. I'll search
> for better 'git format-patch' generation, but if you know  the trick,
> please share.
>

git format-patch -M does not work for you?
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 0/5] Armada 7k/8k files reorganization

[Marcin Wojtas]

Hi Ard,

2017-12-07 17:48 GMT+01:00 Ard Biesheuvel :
> On 7 December 2017 at 16:31, Marcin Wojtas  wrote:
>> Hi,
>>
>> I submit a long awaited file reorganization of Marvell Armada 7k/8k
>> SoC family support. Armada 70x0 DB files remained in
>> 'Platform/Marvell', SoC files, drivers, libraries, etc. were
>> shifted to 'Silicon/Marvell'.
>>
>> Although there are no functional changes, other most significant
>> modifications are:
>> - use 'Armada7k8k' name/prefix, reflecting the SoC family properly
>> - use 'Armada70x0Db' for a board files
>> - move and rename the SPI master driver
>> - move and rename the PciEmulation driver
>> - rename output fd file for Armada70x0Db
>>
>> More details can be found in the commit log. In order to get a
>> better overview, please check 'tree' command outputs below.
>>
>> The code is available in the github:
>> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/reorg-upstream-r20171207
>>
>> I'm looking forward to your feedback.
>>
>
> Hi Marcin,
>
> Could you regenerate these patches with rename detection please?
>

For every single operation I used 'git mv'. 'git status' showed the
renaming properly and so does 'git show -M' on my branch. I'll search
for better 'git format-patch' generation, but if you know  the trick,
please share.

Best regards,
Marcin


>
>
>
>>
>> NEW FILE STRUCTURE:
>> ==
>> tree Platform/Marvell/
>>
>> Platform/Marvell/
>> └── Armada70x0Db
>> ├── Armada70x0Db.dsc
>> └── Armada70x0Db.fdf
>>
>> ==
>> tree Silicon/Marvell/
>>
>> Silicon/Marvell/
>> ├── Applications
>> │   ├── EepromCmd
>> │   │   ├── EepromCmd.c
>> │   │   ├── EepromCmd.inf
>> │   │   └── EepromCmd.uni
>> │   ├── FirmwareUpdate
>> │   │   ├── FUpdate.c
>> │   │   ├── FUpdate.inf
>> │   │   └── FUpdate.uni
>> │   └── SpiTool
>> │   ├── SpiFlashCmd.c
>> │   ├── SpiFlashCmd.inf
>> │   └── SpiFlashCmd.uni
>> ├── Armada7k8k
>> │   ├── Armada7k8k.dsc.inc
>> │   ├── Drivers
>> │   │   ├── Armada7k8kRngDxe
>> │   │   │   ├── Armada7k8kRngDxe.c
>> │   │   │   └── Armada7k8kRngDxe.inf
>> │   │   └── PlatInitDxe
>> │   │   ├── PlatInitDxe.c
>> │   │   └── PlatInitDxe.inf
>> │   └── Library
>> │   ├── Armada7k8kLib
>> │   │   ├── AArch64
>> │   │   │   └── ArmPlatformHelper.S
>> │   │   ├── ARM
>> │   │   │   └── ArmPlatformHelper.S
>> │   │   ├── Armada7k8kLib.c
>> │   │   ├── Armada7k8kLib.inf
>> │   │   ├── Armada7k8kLibMem.c
>> │   │   └── Armada7k8kLibMem.h
>> │   ├── Armada7k8kMemoryInitPeiLib
>> │   │   ├── Armada7k8kMemoryInitPeiLib.c
>> │   │   └── Armada7k8kMemoryInitPeiLib.inf
>> │   └── RealTimeClockLib
>> │   ├── RealTimeClockLib.c
>> │   ├── RealTimeClockLib.h
>> │   └── RealTimeClockLib.inf
>> ├── Documentation
>> │   ├── Drivers
>> │   │   ├── EepromDriver.txt
>> │   │   ├── I2cDriver.txt
>> │   │   └── SpiDriver.txt
>> │   └── PortingGuide.txt
>> ├── Drivers
>> │   ├── I2c
>> │   │   ├── Devices
>> │   │   │   └── MvEeprom
>> │   │   │   ├── MvEeprom.c
>> │   │   │   ├── MvEeprom.h
>> │   │   │   └── MvEeprom.inf
>> │   │   └── MvI2cDxe
>> │   │   ├── MvI2cDxe.c
>> │   │   ├── MvI2cDxe.h
>> │   │   └── MvI2cDxe.inf
>> │   ├── Net
>> │   │   ├── MvMdioDxe
>> │   │   │   ├── MvMdioDxe.c
>> │   │   │   ├── MvMdioDxe.h
>> │   │   │   └── MvMdioDxe.inf
>> │   │   ├── Phy
>> │   │   │   └── MvPhyDxe
>> │   │   │   ├── MvPhyDxe.c
>> │   │   │   ├── MvPhyDxe.h
>> │   │   │   └── MvPhyDxe.inf
>> │   │   └── Pp2Dxe
>> │   │   ├── Mvpp2Lib.c
>> │   │   ├── Mvpp2Lib.h
>> │   │   ├── Mvpp2LibHw.h
>> │   │   ├── Pp2Dxe.c
>> │   │   ├── Pp2Dxe.h
>> │   │   └── Pp2Dxe.inf
>> │   ├── NonDiscoverableDevices
>> │   │   ├── MvNonDiscoverableDxe.c
>> │   │   ├── MvNonDiscoverableDxe.inf
>> │   │   └── NonDiscoverableDevicesDxe.inf
>> │   ├── SdMmc
>> │   │   └── XenonDxe
>> │   │   ├── ComponentName.c
>> │   │   ├── EmmcDevice.c
>> │   │   ├── SdDevice.c
>> │   │   ├── SdMmcPciHcDxe.c
>> │   │   ├── SdMmcPciHcDxeExtra.uni
>> │   │   ├── SdMmcPciHcDxe.h
>> │   │   ├── SdMmcPciHcDxe.inf
>> │   │   ├── SdMmcPciHcDxe.uni
>> │   │   ├── SdMmcPciHci.c
>> │   │   ├── SdMmcPciHci.h
>> │   │   ├── XenonSdhci.c
>> │   │   └── XenonSdhci.h
>> │   └── Spi
>> │   ├── Controllers
>> │   │   ├── MvSpiOrionDxe.c
>> │   │   ├── MvSpiOrionDxe.h
>> │   │   └── MvSpiOrionDxe.inf
>> │   ├── Devices
>> │   │   ├── MvSpiFlash.c
>> │   │   ├── MvSpiFlash.h
>> │   │   └── MvSpiFlash.inf
>> │   └── Variables
>> │   ├── MvFvbDxe.c
>> │   ├── MvFvbDxe.h
>> │   └── MvFvbDxe.inf
>> ├── Include
>> │   ├── Library
>> │   │   ├── MppLib.h
>> │   │   ├── MvComPhyLib.h
>> │   │   ├── MvHwDescLib.h
>> │   │   └── UtmiPhyLib.h
>> │   └── Protocol
>> │   

Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR

[Ard Biesheuvel]

On 7 December 2017 at 17:36, Kinney, Michael D
 wrote:
> Ard,
>
> With link time optimization, the current order produces
> smaller code.
>

I don't think it does. You are essentially saying that
DebugAssertEnabled() may resolve to a link time constant FALSE under
LTO.

In that case, why would the following two statement not be equivalent?

if (FALSE && EFI_ERROR (StatusParameter)) {}

if (EFI_ERROR (StatusParameter) && FALSE) {}

(which is essentially what a nested if () resolves to)

In other words, the compiler is smart enough to drop the status check
in the second case, because it can see there are no side effects, and
the condition can never be made true anyway.

> Without link time optimization, your patch will produce
> smaller code, but not as small as link time optimized code.
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2] BaseTools: align ERROR/WARNING/RETURN macros with MdePkg versions

[Leif Lindholm]

BaseTools' BaseTypes.h defined the ENCODE_ERROR macro as
 #define ENCODE_ERROR(a)  ((RETURN_STATUS)(MAX_BIT | (a)))
whereas MdePkg defines it as
 #define ENCODE_ERROR(StatusCode) ((RETURN_STATUS)(MAX_BIT | (StatusCode)))

When building with GCC 6.3 (at least) the former triggers
"error: overflow in implicit constant conversion [-Werror=overflow]"
Resolve this by aligning it with the latter one.

This also requires aligning the BaseTools typedef of RETURN_STATUS with
the MdePkg one: INTN -> UINTN.

While at it, update adjacent ENCODE_WARNING and RETURN_ERROR as well.

Add an explicit initialization of *Alignment to 0 in GenFfs.c
GetAlignmentFromFile to get rid of a warning occuring with GCC after
this change (-Werror=maybe-uninitialized).

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Leif Lindholm 
---

v2 updated for ENCODE_WARNING and RETURN_ERROR, as requested
by Liming.

 BaseTools/Source/C/GenFfs/GenFfs.c| 1 +
 BaseTools/Source/C/Include/Common/BaseTypes.h | 8 
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Source/C/GenFfs/GenFfs.c 
b/BaseTools/Source/C/GenFfs/GenFfs.c
index e2fb3e0d1e..3b4a9b7761 100644
--- a/BaseTools/Source/C/GenFfs/GenFfs.c
+++ b/BaseTools/Source/C/GenFfs/GenFfs.c
@@ -529,6 +529,7 @@ GetAlignmentFromFile(char *InFile, UINT32 *Alignment)
 
   InFileHandle= NULL;
   PeFileBuffer= NULL;
+  *Alignment  = 0;
 
   memset (, 0, sizeof (ImageContext));
 
diff --git a/BaseTools/Source/C/Include/Common/BaseTypes.h 
b/BaseTools/Source/C/Include/Common/BaseTypes.h
index 198647ab95..08b60bae11 100644
--- a/BaseTools/Source/C/Include/Common/BaseTypes.h
+++ b/BaseTools/Source/C/Include/Common/BaseTypes.h
@@ -170,15 +170,15 @@
 // EFI Error Codes common to all execution phases
 //
 
-typedef INTN RETURN_STATUS;
+typedef UINTN RETURN_STATUS;
 
 ///
 /// Set the upper bit to indicate EFI Error.
 ///
-#define ENCODE_ERROR(a)  (MAX_BIT | (a))
+#define ENCODE_ERROR(a)  ((RETURN_STATUS)(MAX_BIT | (a)))
 
-#define ENCODE_WARNING(a)(a)
-#define RETURN_ERROR(a)  ((a) < 0)
+#define ENCODE_WARNING(a)((RETURN_STATUS)(a))
+#define RETURN_ERROR(a)  (((INTN)(RETURN_STATUS)(a)) < 0)
 
 #define RETURN_SUCCESS   0
 #define RETURN_LOAD_ERRORENCODE_ERROR (1)
-- 
2.11.0

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

Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR

[Kinney, Michael D]

Ard,

With link time optimization, the current order produces
smaller code.  

Without link time optimization, your patch will produce
smaller code, but not as small as link time optimized code.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of Ard Biesheuvel
> Sent: Thursday, December 7, 2017 9:13 AM
> To: Kinney, Michael D 
> Cc: Alexei Fedorov ; edk2-
> de...@lists.01.org; Gao, Liming ;
> Leif Lindholm 
> Subject: Re: [edk2] [PATCH] MdePkg/DebugLib; swap if
> conditions in ASSERT_[EFI|RETURN]_ERROR
> 
> On 7 December 2017 at 17:09, Ard Biesheuvel
>  wrote:
> > On 7 December 2017 at 17:01, Kinney, Michael D
> >  wrote:
> >> Ard,
> >>
> >> The reason for the current ordering is for size
> optimization.
> >>
> >> The most common implementation of DebugAssertEnabled()
> uses
> >> a FixedAtBuild PCD to determine if these are enabled.
> The
> >> check of status can be optimized away if they are
> disabled.
> >> If you reverse them, then the status check is always
> performed.
> >>
> >
> > DebugAssertEnabled() is a function call that gets
> resolved at link
> > time, and is not annotated as being free of side
> effects. So I agree
> > that the implementation of that function could be
> optimized into a
> > 'return true' or 'return false' depending on the
> compile time values
> > of those PCDs, but the way the macro is defined
> currently, it still
> > requires the function call to be made, and the
> conditional compare
> > with a constant that follows will still be present in
> the code.
> >
> > What I am suggesting is to replace it with a comparison
> with a
> > constant, and a conditional function call instead. This
> will not
> > affect code size, but will only remove needless
> function calls at
> > runtime.
> 
> Please refer to these threads for details:
> https://lists.01.org/pipermail/edk2-devel/2017-
> December/018790.html
> https://lists.01.org/pipermail/edk2-devel/2017-
> December/018809.html
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR

[Ard Biesheuvel]

On 7 December 2017 at 17:01, Kinney, Michael D
 wrote:
> Ard,
>
> The reason for the current ordering is for size optimization.
>
> The most common implementation of DebugAssertEnabled() uses
> a FixedAtBuild PCD to determine if these are enabled.  The
> check of status can be optimized away if they are disabled.
> If you reverse them, then the status check is always performed.
>

DebugAssertEnabled() is a function call that gets resolved at link
time, and is not annotated as being free of side effects. So I agree
that the implementation of that function could be optimized into a
'return true' or 'return false' depending on the compile time values
of those PCDs, but the way the macro is defined currently, it still
requires the function call to be made, and the conditional compare
with a constant that follows will still be present in the code.

What I am suggesting is to replace it with a comparison with a
constant, and a conditional function call instead. This will not
affect code size, but will only remove needless function calls at
runtime.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR

[Kinney, Michael D]

Ard,

The reason for the current ordering is for size optimization.

The most common implementation of DebugAssertEnabled() uses
a FixedAtBuild PCD to determine if these are enabled.  The 
check of status can be optimized away if they are disabled.
If you reverse them, then the status check is always performed.

Mike

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, December 7, 2017 7:26 AM
> To: edk2-devel@lists.01.org
> Cc: Leif Lindholm ; Gao, Liming
> ; Evan Lloyd ;
> Kinney, Michael D ; Alexei
> Fedorov ; Ard Biesheuvel
> 
> Subject: Re: [PATCH] MdePkg/DebugLib; swap if conditions
> in ASSERT_[EFI|RETURN]_ERROR
> 
> On 7 December 2017 at 15:12, Ard Biesheuvel
>  wrote:
> > ASSERT_EFI_ERROR () is currently defined as
> >
> >   #if !defined(MDEPKG_NDEBUG)
> > #define ASSERT_EFI_ERROR(StatusParameter)
> \
> >   do {
> \
> > if (DebugAssertEnabled ()) {
> \
> >   if (EFI_ERROR (StatusParameter)) {
> \
> > DEBUG ((EFI_D_ERROR, "\nASSERT_EFI_ERROR
> (Status = %r)\n", StatusParameter));  \
> > _ASSERT (!EFI_ERROR (StatusParameter));
> \
> >   }
> \
> > }
> \
> >   } while (FALSE)
> >   #else
> > #define ASSERT_EFI_ERROR(StatusParameter)
> >   #endif
> >
> > This is suboptimal, given that the DebugAssertEnabled
> () call in the
> > outer if must be executed unconditionally, since the
> compiler does not
> > know that it does not have any side effects. Instead,
> let's swap the
> > two ifs, and only call DebugAssertEnabled () if
> StatusParameter contains
> > an error value to begin with. Do the same for
> ASSERT_RETURN_ERROR
> > as well.
> >
> 
> I just noticed we could do the same for ASSERT () as
> well.
> 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel
> 
> > Reported-by: Alexei Fedorov 
> > ---
> >  MdePkg/Include/Library/DebugLib.h | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/MdePkg/Include/Library/DebugLib.h
> b/MdePkg/Include/Library/DebugLib.h
> > index 3a910e6a208b..8369c378e79c 100644
> > --- a/MdePkg/Include/Library/DebugLib.h
> > +++ b/MdePkg/Include/Library/DebugLib.h
> > @@ -337,8 +337,8 @@ DebugPrintLevelEnabled (
> >  #if !defined(MDEPKG_NDEBUG)
> >#define ASSERT_EFI_ERROR(StatusParameter)
> \
> >  do {
> \
> > -  if (DebugAssertEnabled ()) {
> \
> > -if (EFI_ERROR (StatusParameter)) {
> \
> > +  if (EFI_ERROR (StatusParameter)) {
> \
> > +if (DebugAssertEnabled ()) {
> \
> >DEBUG ((EFI_D_ERROR, "\nASSERT_EFI_ERROR
> (Status = %r)\n", StatusParameter));  \
> >_ASSERT (!EFI_ERROR (StatusParameter));
> \
> >  }
> \
> > @@ -363,8 +363,8 @@ DebugPrintLevelEnabled (
> >  #if !defined(MDEPKG_NDEBUG)
> >#define ASSERT_RETURN_ERROR(StatusParameter)
> \
> >  do {
> \
> > -  if (DebugAssertEnabled ()) {
> \
> > -if (RETURN_ERROR (StatusParameter)) {
> \
> > +  if (RETURN_ERROR (StatusParameter)) {
> \
> > +if (DebugAssertEnabled ()) {
> \
> >DEBUG ((DEBUG_ERROR, "\nASSERT_RETURN_ERROR
> (Status = %r)\n", \
> >  StatusParameter));
> \
> >_ASSERT (!RETURN_ERROR (StatusParameter));
> \
> > --
> > 2.11.0
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add debug asserts

[Alexei Fedorov]

As expected with new ASSERT_EFI_ERROR () definition compiler generates 1 
conditional branch at the start:


// r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:   
ASSERT_EFI_ERROR (Status);
.loc 1 79 0
tbzx0, #63, .L4// Status,




From: Ard Biesheuvel 
Sent: 07 December 2017 15:10:05
To: Alexei Fedorov
Cc: Evan Lloyd; edk2-devel@lists.01.org; leif.lindh...@linaro.org@arm.com; 
n...@arm.com@arm.com; ard.biesheu...@linaro.org@arm.com; 
matteo.carl...@arm.com@arm.com
Subject: Re: [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add debug 
asserts

On 7 December 2017 at 14:55, Alexei Fedorov  wrote:
> Hi,
>
> I've compiled current HdLcd.c code with different optimisation levels for
> DEBUG build using GCC 7.2.1, and the assembler code below was generated for:
>
>   ASSERT_EFI_ERROR (Status);
>   if (EFI_ERROR( Status )) {
> return EFI_DEVICE_ERROR;
>   }
>
> -O0 (default DEBUG option for AARCH64 before Ard's patch):
>
>
> strx0, [x29, 72]//, Status
>
> // r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:
> ASSERT_EFI_ERROR (Status);
> .loc 1 79 0
> blDebugAssertEnabled//
> andw0, w0, 255// _1, tmp150
> cmpw0, 0// _1,
> beq.L4//,
> ldrx0, [x29, 72]// Status.9_2, Status
> cmpx0, 0// Status.9_2,
> bge.L4//,
>
> 2.  -Os:
>
>  movx19, x0// Status,
> // r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:
> ASSERT_EFI_ERROR (Status);
> .loc 1 79 0
> blDebugAssertEnabled//
> .LVL15:
> tstw0, 255//
> beq.L4//,
> tbzx19, #63, .L8// Status,
>
> 3.  -O3:
>
> movx19, x0// Status,
> .LVL14:
> // r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:
> ASSERT_EFI_ERROR (Status);
> blDebugAssertEnabled//
> .LVL15:
> tstw0, 255//
> beq.L5//,
> tbnzx19, #63, .L26// Status,
>
> with DebugAssertEnabled() compiled as:
>
> DebugAssertEnabled:
> .LFB4:
> .loc 1 203 0
> .cfi_startproc
> // r:\edk2\MdePkg\Library\BaseDebugLibSerialPort\DebugLib.c:204:   return
> (BOOLEAN) ((PcdGet8(PcdDebugPropertyMask) &
> DEBUG_PROPERTY_DEBUG_ASSERT_ENABLED) != 0);
> .loc 1 204 0
> adrpx0, _gPcd_FixedAtBuild_PcdDebugPropertyMask// tmp80,
> addx0, x0, :lo12:_gPcd_FixedAtBuild_PcdDebugPropertyMask//
> tmp79, tmp80,
> ldrbw0, [x0]// _gPcd_FixedAtBuild_PcdDebugPropertyMask.4_1,
> _gPcd_FixedAtBuild_PcdDebugPropertyMask
> andw0, w0, 1// _3, _2,
> cmpw0, 0// _3,
> csetw0, ne// tmp82,
> andw0, w0, 255// _4, tmp81
> // r:\edk2\MdePkg\Library\BaseDebugLibSerialPort\DebugLib.c:205: }
> .loc 1 205 0
> ret
>
> As you can see each "ASSERT_EFI_ERROR (Status)" macro requires
> DebugAssertEnabled() call taking 8 instructions by itself + minimum 3
> instructions (for -Os, -O3) for Status check, which will be performed by "if
> (EFI_ERROR( Status ))" anyway.
> Please correct me if I'm wrong assuming that placing
> ASSERT_EFI_ERROR (Status)
> inside
> if (EFI_ERROR( Status )) {
> statement is an optimisation improvement.
>

Thanks for digging this up. This appears to be an oversight in the
definition of the ASSERT_EFI_ERROR () macro, which is currently
defined as

#if !defined(MDEPKG_NDEBUG)
  #define ASSERT_EFI_ERROR(StatusParameter)  \
do { \
  if (DebugAssertEnabled ()) {   \
if (EFI_ERROR (StatusParameter)) {   \

which is obviously the wrong way around, given that the compiler can
never optimize away the function call, due to its potential side
effects (which it doesn't have)

So I will propose to fix this, by swapping the two if () statements.
Please let me know if the issue is still reproducible with that patch
applied.
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix duplicate symbol

[Kinney, Michael D]

Ard,

If the variable was not prepended with GLOBAL_REMOVE_IF_UNREFERENCED, I would 
agree.

GLOBAL_REMOVE_IF_UNREFERENCED for some compilers is not compatible with static.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> On Behalf Of Ard Biesheuvel
> Sent: Thursday, December 7, 2017 12:47 AM
> To: Gao, Liming 
> Cc: Wu, Hao A ; edk2-
> de...@lists.01.org; Andrew Fish ;
> Kinney, Michael D ; Laszlo
> Ersek ; Jeff Fan 
> Subject: Re: [edk2] [Patch]
> SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix duplicate
> symbol
> 
> On 7 December 2017 at 07:48, Liming Gao
>  wrote:
> > From: Michael Kinney 
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=573
> > https://bugzilla.tianocore.org/show_bug.cgi?id=796
> >
> > The same issue is reported again by GCC. Resend this
> patch again.
> > This patch renames the duplicated function name to fix
> it.
> >
> > The SecPeiDebugAgentLib uses the global variable
> > mMemoryDiscoveredNotifyList for a PPI notification on
> > the Memory Discovered PPI.  This same variable name is
> > used in the DxeIplPeim for the same PPI notification.
> >
> > The XCODE5 tool chain detects this duplicate symbol
> > when the OVMF platform is built with the flag
> > -D SOURCE_DEBUG_ENABLE.
> >
> > The fix is to rename this global variable in the
> > SecPeiDebugAgentLib library.
> >
> 
> No, the fix is to make it STATIC unless it *needs* to be
> a global.
> Is that the case here?
> 
> 
> > Cc: Andrew Fish 
> > Cc: Jeff Fan 
> > Cc: Hao Wu 
> > Cc: Laszlo Ersek 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Michael D Kinney
> 
> > Reviewed-by: Jeff Fan 
> > ---
> >
> .../Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentL
> ib.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git
> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent
> /SecPeiDebugAgentLib.c
> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent
> /SecPeiDebugAgentLib.c
> > index b717e33..9f5223a 100644
> > ---
> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent
> /SecPeiDebugAgentLib.c
> > +++
> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent
> /SecPeiDebugAgentLib.c
> > @@ -32,7 +32,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED
> EFI_PEI_PPI_DESCRIPTOR   mVectorHandoffInf
> >}
> >  };
> >
> > -GLOBAL_REMOVE_IF_UNREFERENCED
> EFI_PEI_NOTIFY_DESCRIPTOR mMemoryDiscoveredNotifyList[1]
> = {
> > +GLOBAL_REMOVE_IF_UNREFERENCED
> EFI_PEI_NOTIFY_DESCRIPTOR
> mDebugAgentMemoryDiscoveredNotifyList[1] = {
> >{
> >  (EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK |
> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
> >  ,
> > @@ -554,7 +554,7 @@ InitializeDebugAgent (
> >  // Register for a callback once memory has been
> initialized.
> >  // If memery has been ready, the callback funtion
> will be invoked immediately
> >  //
> > -Status = PeiServicesNotifyPpi
> ([0]);
> > +Status = PeiServicesNotifyPpi
> ([0]);
> >  if (EFI_ERROR (Status)) {
> >DEBUG ((EFI_D_ERROR, "DebugAgent: Failed to
> register memory discovered callback function!\n"));
> >CpuDeadLoop ();
> > --
> > 2.6.3.windows.1
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> > GitPatchExtractor 1.1
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch V2] BaseTools: Fix GenSec can't found the depex file

[Leif Lindholm]

Thanks - with this patch all of my platforms build again.

On Thu, Dec 07, 2017 at 11:59:44PM +0800, Yonghong Zhu wrote:
> From: Yunhua Feng 
> 
> Filter the FileList when multiple genfds thread options is not enabled.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Yunhua Feng 
> Signed-off-by: Yonghong Zhu 

Tested-by: Leif Lindholm 

> ---
>  BaseTools/Source/Python/GenFds/EfiSection.py | 5 +++--
>  BaseTools/Source/Python/GenFds/Section.py| 4 ++--
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/GenFds/EfiSection.py 
> b/BaseTools/Source/Python/GenFds/EfiSection.py
> index 7b3b717..5029ec7 100644
> --- a/BaseTools/Source/Python/GenFds/EfiSection.py
> +++ b/BaseTools/Source/Python/GenFds/EfiSection.py
> @@ -90,13 +90,14 @@ class EfiSection (EfiSectionClassObject):
>  if not self.Optional:
>  FileList.append(Filename)
>  elif os.path.exists(Filename):
>  FileList.append(Filename)
>  elif '.depex' in FfsInf.FinalTargetSuffixMap or FfsInf.Depex:
> -FileList.append(Filename)
> +if IsMakefile:
> +FileList.append(Filename)
>  else:
> -FileList, IsSect = Section.Section.GetFileList(FfsInf, 
> self.FileType, self.FileExtension, Dict)
> +FileList, IsSect = Section.Section.GetFileList(FfsInf, 
> self.FileType, self.FileExtension, Dict, IsMakefile=IsMakefile)
>  if IsSect :
>  return FileList, self.Alignment
>  
>  Index = 0
>  Align = self.Alignment
> diff --git a/BaseTools/Source/Python/GenFds/Section.py 
> b/BaseTools/Source/Python/GenFds/Section.py
> index 4c1aaac..463faa3 100644
> --- a/BaseTools/Source/Python/GenFds/Section.py
> +++ b/BaseTools/Source/Python/GenFds/Section.py
> @@ -108,11 +108,11 @@ class Section (SectionClassObject):
>  #   @param  FileTypeFile type to get
>  #   @param  FileExtension  File extension to get
>  #   @param  Dictdictionary contains macro and its value
>  #   @retval tuple   (File list, boolean)
>  #
> -def GetFileList(FfsInf, FileType, FileExtension, Dict = {}):
> +def GetFileList(FfsInf, FileType, FileExtension, Dict = {}, 
> IsMakefile=False):
>  if FileType in Section.SectFileType.keys() :
>  IsSect = True
>  else :
>  IsSect = False
>  
> @@ -139,11 +139,11 @@ class Section (SectionClassObject):
>  else:
>  GenFdsGlobalVariable.VerboseLogger ("\nFile Type 
> \'%s\' of File %s in %s is not same with file type \'%s\' from Rule in FDF" 
> %(File.Type, File.File, FfsInf.InfFileName, FileType))
>  else:
>  GenFdsGlobalVariable.InfLogger ("\nCurrent ARCH \'%s\' 
> of File %s is not in the Support Arch Scope of %s specified by INF %s in FDF" 
> %(FfsInf.CurrentArch, File.File, File.Arch, FfsInf.InfFileName))
>  
> -if Suffix != None:
> +if (not IsMakefile and Suffix != None and 
> os.path.exists(FfsInf.EfiOutputPath)) or (IsMakefile and Suffix != None):
>  #
>  # Get Makefile path and time stamp
>  #
>  MakefileDir = FfsInf.EfiOutputPath[:-len('OUTPUT')]
>  Makefile = os.path.join(MakefileDir, 'Makefile')
> -- 
> 2.6.1.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [platforms: PATCH 0/5] Armada 7k/8k files reorganization

[Ard Biesheuvel]

On 7 December 2017 at 16:31, Marcin Wojtas  wrote:
> Hi,
>
> I submit a long awaited file reorganization of Marvell Armada 7k/8k
> SoC family support. Armada 70x0 DB files remained in
> 'Platform/Marvell', SoC files, drivers, libraries, etc. were
> shifted to 'Silicon/Marvell'.
>
> Although there are no functional changes, other most significant
> modifications are:
> - use 'Armada7k8k' name/prefix, reflecting the SoC family properly
> - use 'Armada70x0Db' for a board files
> - move and rename the SPI master driver
> - move and rename the PciEmulation driver
> - rename output fd file for Armada70x0Db
>
> More details can be found in the commit log. In order to get a
> better overview, please check 'tree' command outputs below.
>
> The code is available in the github:
> https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/reorg-upstream-r20171207
>
> I'm looking forward to your feedback.
>

Hi Marcin,

Could you regenerate these patches with rename detection please?

Thanks,
Ard.



>
> NEW FILE STRUCTURE:
> ==
> tree Platform/Marvell/
>
> Platform/Marvell/
> └── Armada70x0Db
> ├── Armada70x0Db.dsc
> └── Armada70x0Db.fdf
>
> ==
> tree Silicon/Marvell/
>
> Silicon/Marvell/
> ├── Applications
> │   ├── EepromCmd
> │   │   ├── EepromCmd.c
> │   │   ├── EepromCmd.inf
> │   │   └── EepromCmd.uni
> │   ├── FirmwareUpdate
> │   │   ├── FUpdate.c
> │   │   ├── FUpdate.inf
> │   │   └── FUpdate.uni
> │   └── SpiTool
> │   ├── SpiFlashCmd.c
> │   ├── SpiFlashCmd.inf
> │   └── SpiFlashCmd.uni
> ├── Armada7k8k
> │   ├── Armada7k8k.dsc.inc
> │   ├── Drivers
> │   │   ├── Armada7k8kRngDxe
> │   │   │   ├── Armada7k8kRngDxe.c
> │   │   │   └── Armada7k8kRngDxe.inf
> │   │   └── PlatInitDxe
> │   │   ├── PlatInitDxe.c
> │   │   └── PlatInitDxe.inf
> │   └── Library
> │   ├── Armada7k8kLib
> │   │   ├── AArch64
> │   │   │   └── ArmPlatformHelper.S
> │   │   ├── ARM
> │   │   │   └── ArmPlatformHelper.S
> │   │   ├── Armada7k8kLib.c
> │   │   ├── Armada7k8kLib.inf
> │   │   ├── Armada7k8kLibMem.c
> │   │   └── Armada7k8kLibMem.h
> │   ├── Armada7k8kMemoryInitPeiLib
> │   │   ├── Armada7k8kMemoryInitPeiLib.c
> │   │   └── Armada7k8kMemoryInitPeiLib.inf
> │   └── RealTimeClockLib
> │   ├── RealTimeClockLib.c
> │   ├── RealTimeClockLib.h
> │   └── RealTimeClockLib.inf
> ├── Documentation
> │   ├── Drivers
> │   │   ├── EepromDriver.txt
> │   │   ├── I2cDriver.txt
> │   │   └── SpiDriver.txt
> │   └── PortingGuide.txt
> ├── Drivers
> │   ├── I2c
> │   │   ├── Devices
> │   │   │   └── MvEeprom
> │   │   │   ├── MvEeprom.c
> │   │   │   ├── MvEeprom.h
> │   │   │   └── MvEeprom.inf
> │   │   └── MvI2cDxe
> │   │   ├── MvI2cDxe.c
> │   │   ├── MvI2cDxe.h
> │   │   └── MvI2cDxe.inf
> │   ├── Net
> │   │   ├── MvMdioDxe
> │   │   │   ├── MvMdioDxe.c
> │   │   │   ├── MvMdioDxe.h
> │   │   │   └── MvMdioDxe.inf
> │   │   ├── Phy
> │   │   │   └── MvPhyDxe
> │   │   │   ├── MvPhyDxe.c
> │   │   │   ├── MvPhyDxe.h
> │   │   │   └── MvPhyDxe.inf
> │   │   └── Pp2Dxe
> │   │   ├── Mvpp2Lib.c
> │   │   ├── Mvpp2Lib.h
> │   │   ├── Mvpp2LibHw.h
> │   │   ├── Pp2Dxe.c
> │   │   ├── Pp2Dxe.h
> │   │   └── Pp2Dxe.inf
> │   ├── NonDiscoverableDevices
> │   │   ├── MvNonDiscoverableDxe.c
> │   │   ├── MvNonDiscoverableDxe.inf
> │   │   └── NonDiscoverableDevicesDxe.inf
> │   ├── SdMmc
> │   │   └── XenonDxe
> │   │   ├── ComponentName.c
> │   │   ├── EmmcDevice.c
> │   │   ├── SdDevice.c
> │   │   ├── SdMmcPciHcDxe.c
> │   │   ├── SdMmcPciHcDxeExtra.uni
> │   │   ├── SdMmcPciHcDxe.h
> │   │   ├── SdMmcPciHcDxe.inf
> │   │   ├── SdMmcPciHcDxe.uni
> │   │   ├── SdMmcPciHci.c
> │   │   ├── SdMmcPciHci.h
> │   │   ├── XenonSdhci.c
> │   │   └── XenonSdhci.h
> │   └── Spi
> │   ├── Controllers
> │   │   ├── MvSpiOrionDxe.c
> │   │   ├── MvSpiOrionDxe.h
> │   │   └── MvSpiOrionDxe.inf
> │   ├── Devices
> │   │   ├── MvSpiFlash.c
> │   │   ├── MvSpiFlash.h
> │   │   └── MvSpiFlash.inf
> │   └── Variables
> │   ├── MvFvbDxe.c
> │   ├── MvFvbDxe.h
> │   └── MvFvbDxe.inf
> ├── Include
> │   ├── Library
> │   │   ├── MppLib.h
> │   │   ├── MvComPhyLib.h
> │   │   ├── MvHwDescLib.h
> │   │   └── UtmiPhyLib.h
> │   └── Protocol
> │   ├── Eeprom.h
> │   ├── Mdio.h
> │   ├── MvPhy.h
> │   ├── SpiFlash.h
> │   └── Spi.h
> ├── Library
> │   ├── ComPhyLib
> │   │   ├── ComPhyCp110.c
> │   │   ├── ComPhyLib.c
> │   │   ├── ComPhyLib.h
> │   │   ├── ComPhyLib.inf
> │   │   └── ComPhyMux.c
> │   ├── MppLib
> │   │   ├── MppLib.c
> │   │   └── MppLib.inf
> │   └── UtmiPhyLib
> │   ├── UtmiPhyLib.c
> │   ├── UtmiPhyLib.h
> │   └── UtmiPhyLib.inf
> └── Marvell.dec
>
> 

[edk2] [platforms: PATCH 5/5] Marvell/Drivers: Drop 'PciEmulation' naming

[Marcin Wojtas]

'PciEmulation' is not a proper naming for a driver, which
uses NonDiscoverableDeviceRegistrationLib for handling
the devices attached via internal bus of the SoC.
Rename it to MvNonDiscoverableDxe and move under
Silicon/Marvell/Drivers directory.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf  |   4 
+-
 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc   |   4 
+-
 Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c   | 195 

 Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf |  61 
++
 Silicon/Marvell/PciEmulation/PciEmulation.c | 195 

 Silicon/Marvell/PciEmulation/PciEmulation.inf   |  61 
--
 6 files changed, 260 insertions(+), 260 deletions(-)

diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf 
b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
index 6d57b9a..2bf409e 100644
--- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
+++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
@@ -135,8 +135,8 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
   INF Silicon/Marvell/Drivers/Net/Phy/MvPhyDxe/MvPhyDxe.inf
   INF Silicon/Marvell/Drivers/Net/Pp2Dxe/Pp2Dxe.inf
 
-  # PciEmulation
-  INF Silicon/Marvell/PciEmulation/PciEmulation.inf
+  # NonDiscoverableDevices
+  INF Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf
   INF 
MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
 
   # SCSI
diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index 0eb3ef3..598810e 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -440,8 +440,8 @@
   EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf
   EmbeddedPkg/MetronomeDxe/MetronomeDxe.inf
 
-  # PciEmulation
-  Silicon/Marvell/PciEmulation/PciEmulation.inf
+  # NonDiscoverableDevices
+  Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.inf
   
MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceDxe.inf
 
   # SCSI
diff --git 
a/Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c 
b/Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
new file mode 100644
index 000..abb2940
--- /dev/null
+++ b/Silicon/Marvell/Drivers/NonDiscoverableDevices/MvNonDiscoverableDxe.c
@@ -0,0 +1,195 @@
+/
+Copyright (C) 2016 Marvell International Ltd.
+
+Marvell BSD License Option
+
+If you received this File from Marvell, you may opt to use, redistribute and/or
+modify this File under the following licensing terms.
+Redistribution and use in source and binary forms, with or without 
modification,
+are permitted provided that the following conditions are met:
+
+  * Redistributions of source code must retain the above copyright notice,
+this list of conditions and the following disclaimer.
+
+  * Redistributions in binary form must reproduce the above copyright
+notice, this list of conditions and the following disclaimer in the
+documentation and/or other materials provided with the distribution.
+
+  * Neither the name of Marvell nor the names of its contributors may be
+used to endorse or promote products derived from this software without
+specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
+ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+***/
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+DECLARE_A7K8K_NONDISCOVERABLE_TEMPLATE;
+
+//
+// Tables with used devices
+//
+STATIC UINT8 * CONST XhciDeviceTable = FixedPcdGetPtr (PcdPciEXhci);
+STATIC UINT8 * CONST AhciDeviceTable = FixedPcdGetPtr (PcdPciEAhci);
+STATIC UINT8 * CONST SdhciDeviceTable = FixedPcdGetPtr (PcdPciESdhci);
+
+//
+// NonDiscoverable devices registration
+//
+STATIC
+EFI_STATUS
+MvNonDiscoverableInitXhci (
+  )
+{
+  MVHW_NONDISCOVERABLE_DESC *Desc = 
+  EFI_STATUS 

[edk2] [platforms: PATCH 4/5] Marvell/Drivers: Rename SPI master driver

[Marcin Wojtas]

Hitherto driver name was very generic. In order to be ready
for adding new SPI master drivers, use the controller's
traditional name (it's called SPI Orion in linux and
U-Boot) for files and the entry point.

Additionally, move the files to new 'Controllers' directory,
which is paralel to existing 'Devices' and 'Variables', so
that to make the separation more clear.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf|   2 +-
 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc |   2 +-
 Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c   | 432 

 Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.h   | 148 +++
 Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf |  73 
 Silicon/Marvell/Drivers/Spi/MvSpiDxe.c| 432 

 Silicon/Marvell/Drivers/Spi/MvSpiDxe.h| 148 ---
 Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf  |  73 
 8 files changed, 655 insertions(+), 655 deletions(-)

diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf 
b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
index 3b0646e..6d57b9a 100644
--- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
+++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
@@ -110,7 +110,7 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
   INF Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
   INF MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
   INF Silicon/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf
-  INF Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
+  INF Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
   INF Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
   INF Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.inf
 
diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index 7d87766..0eb3ef3 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -411,7 +411,7 @@
   Silicon/Marvell/Drivers/I2c/MvI2cDxe/MvI2cDxe.inf
   MdeModulePkg/Bus/I2c/I2cDxe/I2cDxe.inf
   Silicon/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf
-  Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
+  Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.inf
   Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
   Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.inf
 
diff --git a/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c 
b/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c
new file mode 100755
index 000..c657daf
--- /dev/null
+++ b/Silicon/Marvell/Drivers/Spi/Controllers/MvSpiOrionDxe.c
@@ -0,0 +1,432 @@
+/***
+Copyright (C) 2016 Marvell International Ltd.
+
+Marvell BSD License Option
+
+If you received this File from Marvell, you may opt to use, redistribute and/or
+modify this File under the following licensing terms.
+Redistribution and use in source and binary forms, with or without 
modification,
+are permitted provided that the following conditions are met:
+
+* Redistributions of source code must retain the above copyright notice,
+  this list of conditions and the following disclaimer.
+
+* Redistributions in binary form must reproduce the above copyright
+  notice, this list of conditions and the following disclaimer in the
+  documentation and/or other materials provided with the distribution.
+
+* Neither the name of Marvell nor the names of its contributors may be
+  used to endorse or promote products derived from this software without
+  specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND
+ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR
+ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+
+***/
+#include "MvSpiOrionDxe.h"
+
+SPI_MASTER *mSpiMasterInstance;
+
+STATIC
+EFI_STATUS
+SpiSetBaudRate (
+  IN SPI_DEVICE *Slave,
+  IN UINT32 CpuClock,
+  IN UINT32 MaxFreq
+  )
+{
+  UINT32 Spr, BestSpr, Sppr, BestSppr, ClockDivider, Match, Reg, MinBaudDiff;
+  UINTN SpiRegBase = Slave->HostRegisterBaseAddress;
+
+  MinBaudDiff = 0x;
+  BestSppr = 0;
+
+  //Spr is 

[edk2] [platforms: PATCH 2/5] Marvell/Armada7k8k: Use '7k8k' prefix in the SoC drivers/libraries

[Marcin Wojtas]

As a part of files reorganization, switch to using '7k8k'
in all SoC-specific driver/library code instead of
'70x0'/'7040', so that to ensure consistent naming for
entire SoC family.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf 
  |   2 +-
 Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc  
  |   6 +-
 Silicon/Marvell/Armada7k8k/Drivers/Armada70x0RngDxe/Armada70x0RngDxe.c 
  | 255 
 Silicon/Marvell/Armada7k8k/Drivers/Armada70x0RngDxe/Armada70x0RngDxe.inf   
  |  47 
 Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.c 
  | 255 
 Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.inf   
  |  47 
 Silicon/Marvell/Armada7k8k/Library/Armada70x0Lib/AArch64/ArmPlatformHelper.S   
  |  51 
 Silicon/Marvell/Armada7k8k/Library/Armada70x0Lib/ARM/ArmPlatformHelper.S   
  |  77 --
 Silicon/Marvell/Armada7k8k/Library/Armada70x0Lib/Armada70x0Lib.c   
  | 132 --
 Silicon/Marvell/Armada7k8k/Library/Armada70x0Lib/Armada70x0Lib.inf 
  |  76 --
 Silicon/Marvell/Armada7k8k/Library/Armada70x0Lib/Armada70x0LibMem.c
  | 204 
 Silicon/Marvell/Armada7k8k/Library/Armada70x0Lib/Armada70x0LibMem.h
  |  73 --
 
Silicon/Marvell/Armada7k8k/Library/Armada70x0MemoryInitPeiLib/Armada70x0MemoryInitPeiLib.c
   | 158 
 
Silicon/Marvell/Armada7k8k/Library/Armada70x0MemoryInitPeiLib/Armada70x0MemoryInitPeiLib.inf
 |  46 
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/AArch64/ArmPlatformHelper.S   
  |  51 
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/ARM/ArmPlatformHelper.S   
  |  77 ++
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLib.c   
  | 132 ++
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLib.inf 
  |  76 ++
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c
  | 204 
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.h
  |  73 ++
 
Silicon/Marvell/Armada7k8k/Library/Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.c
   | 158 
 
Silicon/Marvell/Armada7k8k/Library/Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.inf
 |  46 
 22 files changed, 1123 insertions(+), 1123 deletions(-)

diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf 
b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
index f63f42d..bba449a 100644
--- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
+++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
@@ -112,7 +112,7 @@ FvNameGuid = 5eda4200-2c5f-43cb-9da3-0baf74b1b30c
   INF Silicon/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf
   INF Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
   INF Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
-  INF Silicon/Marvell/Armada7k8k/Drivers/Armada70x0RngDxe/Armada70x0RngDxe.inf
+  INF Silicon/Marvell/Armada7k8k/Drivers/Armada7k8kRngDxe/Armada7k8kRngDxe.inf
 
   # Variable services
   INF Silicon/Marvell/Drivers/Spi/Variables/MvFvbDxe.inf
diff --git a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc 
b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
index 75717e9..7d87766 100644
--- a/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
+++ b/Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
@@ -32,7 +32,7 @@
 #SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 #
 [LibraryClasses.common]
-  
ArmPlatformLib|Silicon/Marvell/Armada7k8k/Library/Armada70x0Lib/Armada70x0Lib.inf
+  
ArmPlatformLib|Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLib.inf
   ComPhyLib|Silicon/Marvell/Library/ComPhyLib/ComPhyLib.inf
   MppLib|Silicon/Marvell/Library/MppLib/MppLib.inf
   NorFlashInfoLib|EmbeddedPkg/Library/NorFlashInfoLib/NorFlashInfoLib.inf
@@ -149,7 +149,7 @@
   PcdLib|MdePkg/Library/BasePcdLibNull/BasePcdLibNull.inf
 
 [LibraryClasses.common.SEC, LibraryClasses.common.PEIM]
-  
MemoryInitPeiLib|Silicon/Marvell/Armada7k8k/Library/Armada70x0MemoryInitPeiLib/Armada70x0MemoryInitPeiLib.inf
+  
MemoryInitPeiLib|Silicon/Marvell/Armada7k8k/Library/Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.inf
   BaseMemoryLib|MdePkg/Library/BaseMemoryLib/BaseMemoryLib.inf
 
 [LibraryClasses.common.DXE_CORE]
@@ -413,7 +413,7 @@
   Silicon/Marvell/Drivers/I2c/Devices/MvEeprom/MvEeprom.inf
   Silicon/Marvell/Drivers/Spi/MvSpiDxe.inf
   Silicon/Marvell/Drivers/Spi/Devices/MvSpiFlash.inf
-  Silicon/Marvell/Armada7k8k/Drivers/Armada70x0RngDxe/Armada70x0RngDxe.inf
+  

[edk2] [platforms: PATCH 3/5] Marvell/Armada70x0Db: Rename fd file

[Marcin Wojtas]

Hitherto fd file name was pretty generic, so use one,
which reflects actual board model.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf 
b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
index bba449a..3b0646e 100644
--- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
+++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.fdf
@@ -24,7 +24,7 @@
 #
 

 
-[FD.Armada70x0_EFI]
+[FD.Armada70x0Db_EFI]
 BaseAddress   = 0x|gArmTokenSpaceGuid.PcdFdBaseAddress  # The base 
address of the Firmware in NOR Flash.
 Size  = 0x0040|gArmTokenSpaceGuid.PcdFdSize # The size in 
bytes of the FLASH Device
 ErasePolarity = 1
-- 
2.7.4

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

[edk2] [platforms: PATCH 0/5] Armada 7k/8k files reorganization

[Marcin Wojtas]

Hi,

I submit a long awaited file reorganization of Marvell Armada 7k/8k
SoC family support. Armada 70x0 DB files remained in
'Platform/Marvell', SoC files, drivers, libraries, etc. were
shifted to 'Silicon/Marvell'.

Although there are no functional changes, other most significant
modifications are:
- use 'Armada7k8k' name/prefix, reflecting the SoC family properly
- use 'Armada70x0Db' for a board files
- move and rename the SPI master driver
- move and rename the PciEmulation driver
- rename output fd file for Armada70x0Db

More details can be found in the commit log. In order to get a
better overview, please check 'tree' command outputs below.

The code is available in the github:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/reorg-upstream-r20171207

I'm looking forward to your feedback.

Best regards,
Marcin

NEW FILE STRUCTURE:
==
tree Platform/Marvell/

Platform/Marvell/
└── Armada70x0Db
├── Armada70x0Db.dsc
└── Armada70x0Db.fdf

==
tree Silicon/Marvell/

Silicon/Marvell/
├── Applications
│   ├── EepromCmd
│   │   ├── EepromCmd.c
│   │   ├── EepromCmd.inf
│   │   └── EepromCmd.uni
│   ├── FirmwareUpdate
│   │   ├── FUpdate.c
│   │   ├── FUpdate.inf
│   │   └── FUpdate.uni
│   └── SpiTool
│   ├── SpiFlashCmd.c
│   ├── SpiFlashCmd.inf
│   └── SpiFlashCmd.uni
├── Armada7k8k
│   ├── Armada7k8k.dsc.inc
│   ├── Drivers
│   │   ├── Armada7k8kRngDxe
│   │   │   ├── Armada7k8kRngDxe.c
│   │   │   └── Armada7k8kRngDxe.inf
│   │   └── PlatInitDxe
│   │   ├── PlatInitDxe.c
│   │   └── PlatInitDxe.inf
│   └── Library
│   ├── Armada7k8kLib
│   │   ├── AArch64
│   │   │   └── ArmPlatformHelper.S
│   │   ├── ARM
│   │   │   └── ArmPlatformHelper.S
│   │   ├── Armada7k8kLib.c
│   │   ├── Armada7k8kLib.inf
│   │   ├── Armada7k8kLibMem.c
│   │   └── Armada7k8kLibMem.h
│   ├── Armada7k8kMemoryInitPeiLib
│   │   ├── Armada7k8kMemoryInitPeiLib.c
│   │   └── Armada7k8kMemoryInitPeiLib.inf
│   └── RealTimeClockLib
│   ├── RealTimeClockLib.c
│   ├── RealTimeClockLib.h
│   └── RealTimeClockLib.inf
├── Documentation
│   ├── Drivers
│   │   ├── EepromDriver.txt
│   │   ├── I2cDriver.txt
│   │   └── SpiDriver.txt
│   └── PortingGuide.txt
├── Drivers
│   ├── I2c
│   │   ├── Devices
│   │   │   └── MvEeprom
│   │   │   ├── MvEeprom.c
│   │   │   ├── MvEeprom.h
│   │   │   └── MvEeprom.inf
│   │   └── MvI2cDxe
│   │   ├── MvI2cDxe.c
│   │   ├── MvI2cDxe.h
│   │   └── MvI2cDxe.inf
│   ├── Net
│   │   ├── MvMdioDxe
│   │   │   ├── MvMdioDxe.c
│   │   │   ├── MvMdioDxe.h
│   │   │   └── MvMdioDxe.inf
│   │   ├── Phy
│   │   │   └── MvPhyDxe
│   │   │   ├── MvPhyDxe.c
│   │   │   ├── MvPhyDxe.h
│   │   │   └── MvPhyDxe.inf
│   │   └── Pp2Dxe
│   │   ├── Mvpp2Lib.c
│   │   ├── Mvpp2Lib.h
│   │   ├── Mvpp2LibHw.h
│   │   ├── Pp2Dxe.c
│   │   ├── Pp2Dxe.h
│   │   └── Pp2Dxe.inf
│   ├── NonDiscoverableDevices
│   │   ├── MvNonDiscoverableDxe.c
│   │   ├── MvNonDiscoverableDxe.inf
│   │   └── NonDiscoverableDevicesDxe.inf
│   ├── SdMmc
│   │   └── XenonDxe
│   │   ├── ComponentName.c
│   │   ├── EmmcDevice.c
│   │   ├── SdDevice.c
│   │   ├── SdMmcPciHcDxe.c
│   │   ├── SdMmcPciHcDxeExtra.uni
│   │   ├── SdMmcPciHcDxe.h
│   │   ├── SdMmcPciHcDxe.inf
│   │   ├── SdMmcPciHcDxe.uni
│   │   ├── SdMmcPciHci.c
│   │   ├── SdMmcPciHci.h
│   │   ├── XenonSdhci.c
│   │   └── XenonSdhci.h
│   └── Spi
│   ├── Controllers
│   │   ├── MvSpiOrionDxe.c
│   │   ├── MvSpiOrionDxe.h
│   │   └── MvSpiOrionDxe.inf
│   ├── Devices
│   │   ├── MvSpiFlash.c
│   │   ├── MvSpiFlash.h
│   │   └── MvSpiFlash.inf
│   └── Variables
│   ├── MvFvbDxe.c
│   ├── MvFvbDxe.h
│   └── MvFvbDxe.inf
├── Include
│   ├── Library
│   │   ├── MppLib.h
│   │   ├── MvComPhyLib.h
│   │   ├── MvHwDescLib.h
│   │   └── UtmiPhyLib.h
│   └── Protocol
│   ├── Eeprom.h
│   ├── Mdio.h
│   ├── MvPhy.h
│   ├── SpiFlash.h
│   └── Spi.h
├── Library
│   ├── ComPhyLib
│   │   ├── ComPhyCp110.c
│   │   ├── ComPhyLib.c
│   │   ├── ComPhyLib.h
│   │   ├── ComPhyLib.inf
│   │   └── ComPhyMux.c
│   ├── MppLib
│   │   ├── MppLib.c
│   │   └── MppLib.inf
│   └── UtmiPhyLib
│   ├── UtmiPhyLib.c
│   ├── UtmiPhyLib.h
│   └── UtmiPhyLib.inf
└── Marvell.dec

==

Marcin Wojtas (5):
  Marvell: Reorganize file structure
  Marvell/Armada7k8k: Use '7k8k' prefix in the SoC drivers/libraries
  Marvell/Armada70x0Db: Rename fd file
  Marvell/Drivers: Rename SPI master driver
  Marvell/Drivers: Drop 'PciEmulation' naming

 Platform/Marvell/Applications/EepromCmd/EepromCmd.c
  |  397 --
 Platform/Marvell/Applications/EepromCmd/EepromCmd.inf  
  |   

Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file

[Zhu, Yonghong]

Hi Leif,

I just sent out V2 patch. thanks.

Best Regards,
Zhu Yonghong


-Original Message-
From: Zhu, Yonghong 
Sent: Thursday, December 07, 2017 10:42 PM
To: 'Leif Lindholm' 
Cc: edk2-devel@lists.01.org; Feng, YunhuaX ; Gao, 
Liming ; jason.zh...@linaro.org; Zhu, Yonghong 

Subject: RE: [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file

Hi Leif,

I reproduced this issue. Thanks. I will try to fix it ASAP.

Best Regards,
Zhu Yonghong


-Original Message-
From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
Sent: Thursday, December 07, 2017 10:36 PM
To: Zhu, Yonghong 
Cc: edk2-devel@lists.01.org; Feng, YunhuaX ; Gao, 
Liming ; jason.zh...@linaro.org
Subject: Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file

Hi Yonghong,

I do not have the DSC that was used to build it. The FDF is
https://github.com/tianocore/edk2-platforms/blob/master/Platform/Hisilicon/D05/D05.fdf#L250

Jason (cc) may be able to provide more information on the binary.

Best Regards,

Leif

On Thu, Dec 07, 2017 at 12:55:48PM +, Zhu, Yonghong wrote:
> Hi Leif,
> 
> May I know how this binary driver is described in DSC file and FDF 
> file, and the [Rule.Common.DXE_DRIVER.BINARY] section ?
> I tried to add this driver into OvmfPkg, but failed to reproduce this 
> failure. Thanks.
> 
> Best Regards,
> Zhu Yonghong
> 
> 
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Thursday, December 07, 2017 7:30 PM
> To: Zhu, Yonghong 
> Cc: edk2-devel@lists.01.org; Feng, YunhuaX ; 
> Gao, Liming 
> Subject: Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the 
> depex file
> 
> Hi Yonghong,
> 
> This patch resolves the issue for the hikey platform, but not for 
> (edk2-platforms/Platform/Hisilicon/)D03/D05. They fail with
> 
> ---
> Generating FVMAIN FV
> ##
> 
> #Return Value = 2
> GenSec: ERROR 0001: Error opening file
> 
>   
> /work/git/tianocore/Build/D03/DEBUG_GCC5/AARCH64/Platform/Hisilicon/D0
> 3/Drivers/Net/SnpPlatform/SnpPlatform/OUTPUT/SnpPlatform.depex
> GenSec: ERROR 2000: Status is not successful
> ---
> 
> and
> 
> ---
> Generating FVMAIN FV
> ##
> 
> 
> Return Value = 2
> GenSec: ERROR 0001: Error opening file
> 
> 
>   
> /work/git/tianocore/Build/D05/RELEASE_GCC5/AARCH64/Platform/Hisilicon/
> D05/Drivers/Net/SnpPlatform/SnpPlatform/OUTPUT/SnpPlatform.depex
> GenFds.py...
>  : error 7000: Failed to generate section
> GenSec: ERROR 2000: Status is not successful
> ---
> 
> respectively.
> 
> Again, reverting 37de70b7 makes the build successful again.
> 
> Note that the failing drivers are binary, held in edk2-non-osi.
> 
> Regards,
> 
> Leif
> 
> On Thu, Dec 07, 2017 at 02:51:17PM +0800, Yonghong Zhu wrote:
> > From: Yunhua Feng 
> > 
> > Filter the FileList when multiple genfds thread options is not enabled.
> > 
> > Cc: Liming Gao 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Yunhua Feng 
> > ---
> >  BaseTools/Source/Python/GenFds/EfiSection.py | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/BaseTools/Source/Python/GenFds/EfiSection.py
> > b/BaseTools/Source/Python/GenFds/EfiSection.py
> > index 7b3b717191..4276945a10 100644
> > --- a/BaseTools/Source/Python/GenFds/EfiSection.py
> > +++ b/BaseTools/Source/Python/GenFds/EfiSection.py
> > @@ -92,7 +92,8 @@ class EfiSection (EfiSectionClassObject):
> >  elif os.path.exists(Filename):
> >  FileList.append(Filename)
> >  elif '.depex' in FfsInf.FinalTargetSuffixMap or FfsInf.Depex:
> > -FileList.append(Filename)
> > +if IsMakefile:
> > +FileList.append(Filename)
> >  else:
> >  FileList, IsSect = Section.Section.GetFileList(FfsInf, 
> > self.FileType, self.FileExtension, Dict)
> >  if IsSect :
> > --
> > 2.12.2.windows.2
> > 
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch V2] BaseTools: Fix GenSec can't found the depex file

[Yonghong Zhu]

From: Yunhua Feng 

Filter the FileList when multiple genfds thread options is not enabled.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Yunhua Feng 
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/GenFds/EfiSection.py | 5 +++--
 BaseTools/Source/Python/GenFds/Section.py| 4 ++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/BaseTools/Source/Python/GenFds/EfiSection.py 
b/BaseTools/Source/Python/GenFds/EfiSection.py
index 7b3b717..5029ec7 100644
--- a/BaseTools/Source/Python/GenFds/EfiSection.py
+++ b/BaseTools/Source/Python/GenFds/EfiSection.py
@@ -90,13 +90,14 @@ class EfiSection (EfiSectionClassObject):
 if not self.Optional:
 FileList.append(Filename)
 elif os.path.exists(Filename):
 FileList.append(Filename)
 elif '.depex' in FfsInf.FinalTargetSuffixMap or FfsInf.Depex:
-FileList.append(Filename)
+if IsMakefile:
+FileList.append(Filename)
 else:
-FileList, IsSect = Section.Section.GetFileList(FfsInf, 
self.FileType, self.FileExtension, Dict)
+FileList, IsSect = Section.Section.GetFileList(FfsInf, 
self.FileType, self.FileExtension, Dict, IsMakefile=IsMakefile)
 if IsSect :
 return FileList, self.Alignment
 
 Index = 0
 Align = self.Alignment
diff --git a/BaseTools/Source/Python/GenFds/Section.py 
b/BaseTools/Source/Python/GenFds/Section.py
index 4c1aaac..463faa3 100644
--- a/BaseTools/Source/Python/GenFds/Section.py
+++ b/BaseTools/Source/Python/GenFds/Section.py
@@ -108,11 +108,11 @@ class Section (SectionClassObject):
 #   @param  FileTypeFile type to get
 #   @param  FileExtension  File extension to get
 #   @param  Dictdictionary contains macro and its value
 #   @retval tuple   (File list, boolean)
 #
-def GetFileList(FfsInf, FileType, FileExtension, Dict = {}):
+def GetFileList(FfsInf, FileType, FileExtension, Dict = {}, 
IsMakefile=False):
 if FileType in Section.SectFileType.keys() :
 IsSect = True
 else :
 IsSect = False
 
@@ -139,11 +139,11 @@ class Section (SectionClassObject):
 else:
 GenFdsGlobalVariable.VerboseLogger ("\nFile Type 
\'%s\' of File %s in %s is not same with file type \'%s\' from Rule in FDF" 
%(File.Type, File.File, FfsInf.InfFileName, FileType))
 else:
 GenFdsGlobalVariable.InfLogger ("\nCurrent ARCH \'%s\' of 
File %s is not in the Support Arch Scope of %s specified by INF %s in FDF" 
%(FfsInf.CurrentArch, File.File, File.Arch, FfsInf.InfFileName))
 
-if Suffix != None:
+if (not IsMakefile and Suffix != None and 
os.path.exists(FfsInf.EfiOutputPath)) or (IsMakefile and Suffix != None):
 #
 # Get Makefile path and time stamp
 #
 MakefileDir = FfsInf.EfiOutputPath[:-len('OUTPUT')]
 Makefile = os.path.join(MakefileDir, 'Makefile')
-- 
2.6.1.windows.1

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

Re: [edk2] [PATCH v2 0/6] Add ARM support for VS2017

[Pete Batard]

Hi Liming,

On 2017.12.07 03:02, Gao, Liming wrote:

   This is the base step to enable VS2017 ARM tool chain. Then, user could use 
it and build ARM application first.


Yes.


   Here, I have one question. VS2017 ARM requires 4096 alignment. So, why not 
add /FILEALIGN:4096 into tools_def.txt as the default linker option for ARM?


I don't think we want to do that on account that this option does not 
need to be specified when building regular applications, and is 
currently only needed when building the QEMU firmware.


So it's probably better to only specify it in the context where it is 
needed, rather than globally, especially as the documentation for 
/FILEALIGN [1] indicates that "By default, the linker does not use a 
fixed alignment size" which would tend to indicate that we might be 
better off letting the compiler decide what it should use on its own.


Especially, forcing /FILEALIGN to 4K everywhere does appear to increase 
the size of the generated binaries. For instance, I'm seeing a RELEASE 
Shell.efi  with a size of 762 KB without /FILEALIGN, vs. 792 KB with 
/FILEALIGN:4096.


Thus, I think we should be conservative with regards to the global 
compiler options we add: if an option only seems to be needed for a 
single module (and especially, if that module has not yet been patched 
and reviewed for compilation), it should probably be specified for that 
module alone.


As such, unless you or other people on this list have a strong opinion 
that /FILEALIGN:4096 should be global, I am currently not planning to 
resubmit a new patch that adds that option.


Please let me know if you still think the patch should be altered.

Regards,

/Pete

[1] https://docs.microsoft.com/en-gb/cpp/build/reference/filealign
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support for Watchdog driver

[Leif Lindholm]

Liming,

https://www.mail-archive.com/edk2-devel@lists.01.org/msg32761.html
Search for WdogRegisterHandler.

This topic is entirely unrelated to any _usage_ of watchdog timer
protocol.

The topic is only whether it is reasonable to _implement_
EFI_WATCHDOG_TIMER_ARCH_PROTOCOL for a hardware watchdog that *cannot*
cause a callback to a handler function.
Because when the hardware watchdog times out, it triggers a hard
system reset, without any software interaction.

/
Leif

On Thu, Dec 07, 2017 at 02:54:08PM +, Gao, Liming wrote:
> Leif:
>   I don't review the whole patch serial. Could you point your usage
>   case on watch dog timer protocol?
> 
> Thanks
> Liming
> > -Original Message-
> > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > Sent: Thursday, December 7, 2017 7:04 PM
> > To: Gao, Liming 
> > Cc: Udit Kumar ; Kinney, Michael D 
> > ; Meenakshi Aggarwal
> > ; ard.biesheu...@linaro.org; 
> > edk2-devel@lists.01.org; Varun Sethi 
> > Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add 
> > support for Watchdog driver
> > 
> > Hi Liming,
> > 
> > On Thu, Dec 07, 2017 at 07:11:38AM +, Gao, Liming wrote:
> > > Leif:
> > >   I don't see the core driver uses
> > >   WatchdogTimer->RegisterHandler(). When it returns unsupported, it
> > >   means the additional handler can't be registered. DxeCore uses
> > >   WatchdogTimer->SetTimerPeriod(). This service is implemented in
> > >   your driver.
> > >
> > >   Watchdog protocol is defined in PI spec. Spec describes that this
> > >   protocol provides the services required to implement the Boot
> > >   Service SetWatchdogTimer(). It provides a service to set the
> > >   amount of time to wait before firing the watchdog timer, and it
> > >   also provides a service to register a handler that is invoked when
> > >   the watchdog timer fires. This protocol can implement the watchdog
> > >   timer by using the event and timer Boot Services, or it can make
> > >   use of custom hardware. If no handler has been registered, or the
> > >   registered handler returns, then the system will be reset by
> > >   calling the Runtime Service ResetSystem(). So, this protocol is
> > >   required.
> > 
> > I am not disputing that the protocol is not required. I am suggesting
> > that this hardware watchdog _cannot_ be used to register a handler.
> > 
> > If this hardware watchdog does not get updated in time, that causes an
> > immediate hardware reset of the processor.
> > 
> > Because of this, I believe EFI_WATCHDOG_TIMER_ARCH_PROTOCOL is not the
> > appropriate way to make use of it.
> > 
> > Please let me know whether you agree.
> > 
> > Regards,
> > 
> > Leif
> > 
> > > Thanks
> > > Liming
> > > >-Original Message-
> > > >From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > > >Sent: Tuesday, December 05, 2017 7:06 PM
> > > >To: Udit Kumar 
> > > >Cc: Gao, Liming ; Kinney, Michael D
> > > >; Meenakshi Aggarwal
> > > >; ard.biesheu...@linaro.org; edk2-
> > > >de...@lists.01.org; Varun Sethi 
> > > >Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> > > >support for Watchdog driver
> > > >
> > > >On Tue, Dec 05, 2017 at 05:07:00AM +, Udit Kumar wrote:
> > > >> >   I suggest return EFI_UNSUPPORTED for this case. The protocol
> > > >implementation
> > > >> > could return its status besides spec defined status.
> > > >>
> > > >> Thanks to help me , how core will treat this error
> > > >> 1/  Wdt not available
> > > >> 2/ ignoring this error
> > > >> 3/ core is not registering handler
> > > >> I guess 3 is valid,
> > > >
> > > >Looking at Core/Dxe/Misc/SetWatchdogTimer.c:
> > > >  //
> > > >  // Attempt to set the timeout
> > > >  //
> > > >  Status = gWatchdogTimer->SetTimerPeriod (gWatchdogTimer,
> > > >  MultU64x32 (Timeout, WATCHDOG_TIMER_CALIBRATE_PER_SECOND));
> > > >
> > > >  //
> > > >  // Check for errors
> > > >  //
> > > >  if (EFI_ERROR (Status)) {
> > > >return EFI_DEVICE_ERROR;
> > > >  }
> > > >
> > > >The SetWatchdogTimer() call would always return EFI_DEVICE_ERROR.
> > > >
> > > >> On side track, looks wdt is not used by core services then do we
> > > >> really need this as part of arch protocol ?
> > > >
> > > >Yes, that was ultimately what I was implying with my question
> > > >regarding whether this protocol is relevant for a watchdog that can
> > > >only ever reset the system on timeout.
> > > >
> > > >The protocol looks to me to be designed to use a dedicated generic
> > > >timer as backing for a software watchdog.
> > > >
> > > >Liming, Mike?
> > > >
> > > >If that is the case, then I agree this driver should probably not
> > > >implement this protocol, but rather set up a timer event (or a
> > > >dedicated timer) to stroke the watchdog.
> > > 

[edk2] [RFC] Update EDKII Performance infrastructure based on ACPI FPDT table

[Liming Gao]

From: "Gao, Liming" 

Current EDKII performance implementation bases on performance protocol to log
and dump performance entry. There is no way to get the performance data in OS.
ACPI FPDT table allows to insert the firmware extension record. If so,
the detail boot performance data can be stored as FPDT record in ACPI FPDT 
table. It supports to dump performance data in UEFI Shell and OS both.

This proposal is to update EDKII performance infrastructure to log and dump 
the performance entry as FPDT record in ACPI FPDT table. This RFC defines 5 
edk2 FPDT records. Three of them are used for current Perf entry. Other two 
will be used with new Perf APIs. Now, this proposal focus on the performance
internal implementation, but doesn't impact PerformanceLib interfaces and
DP application output. So, there is no change required to any consumer code
and platform DSC/FDF. New Perf APIs will be introduced later.

The detail changes are list here.
0. Introduce PCD PcdEdkiiFpdtStringRecordEnableOnly to generate two style edk2
   extended FPDT records.
1. When PCD PcdEdkiiFpdtStringRecordEnableOnly is set to FALSE, the different
   records will be used to store the different performance entry. EDKII provides
   two pair PERF APIs. PERF_START()/PERF_END() and 
PERF_START_EX()/PERF_END_EX().
   Every PERF_START or PERF_END will be saved into one record. Every record has
   ProgressId to identify the perf entry. It has Guid to store the module GUID.
   Some records have String for Token/Module name. PERF_START_EX()/PERF_END_EX()
   has ProgressId parameter. They will be converted based on their ProgressId.
   PERF_START()/PERF_END() have no ProgressId parameter. Its token name will
   be converted to ProgressId.
   Below is the detail mapping between perf token name and records.
   "StartImage:" --> GUID_EVENT_RECORD   with ProgressId 0x01~0x02
   "PEIM"--> GUID_EVENT_RECORD   with ProgressId 0x01~0x02
   "LoadImage:"  --> GUID_QWORD_EVENT_RECORD with ProgressId 0x03~0x04,
 its Qword is the loaded image count.
   "DB:Start:" START --> GUID_QWORD_EVENT_RECORD with ProgressId 0x05,
 its Qword is the controller handle.
   "DB:Start:" END   --> GUID_QWORD_STRING_EVENT_RECORD with ProgressId 0x06,
 its Qword is the controller handle, its String is the
 device path of the controller handle.
   "DB:Support:" --> GUID_QWORD_EVENT_RECORD with ProgressId 0x07~0x08,
 its Qword is the controller handle.
   "DB:Stop:"--> GUID_QWORD_EVENT_RECORD with ProgressId 0x09~0x0A,
 its Qword is the controller handle.
   "SEC", "PEI"  --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x50~0x51
 (cross module), its String is the token name.
   "DXE", "BDS"  --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x50~0x51
 (cross module), its String is the token name.
   Non-null token--> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x40~0x41
 (in module), its String is the token name.
   Non-null module   --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x40~0x41
 (in module), its String is the module name.
   Non-null Handle   --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x40~0x41
 (in module), its String is the module name from Handle
   Others are ignored.
2. When PCD PcdEdkiiFpdtStringRecordEnableOnly is set to TRUE,
   DYNAMIC_STRING_EVENT_RECORD will be used to store all performance entry.
   Every record has ProgressId to identify the perf entry. Its Guid stores
   the module or caller GUID. Its String stores Token/Module name.
   PERF_START_EX()/PERF_END_EX() has ProgressId parameter. They will be
   converted based on their ProgressId. PERF_START()/PERF_END() have no
   ProgressId parameter. Its token name will be converted to ProgressId.
   Below is the detail mapping.
   "StartImage:"   --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x01~0x02
   "PEIM"  --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x01~0x02
   "LoadImage:"--> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x03~0x04
   "DB:Start:" --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x05~0x06
   "DB:Support:"   --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x07~0x08
   "DB:Stop:"  --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x09~0x0A
   "SEC", "PEI"--> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x50~0x51
   (cross module), its String is the token name.
   "DXE", "BDS"--> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x50~0x51
   (cross module), its String is the token name.
   Non-null token  --> DYNAMIC_STRING_EVENT_RECORD with ProgressId 0x40~0x41
   (in module), its String is the token name.
   Non-null module --> DYNAMIC_STRING_EVENT_RECORD with 

Re: [edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR

[Ard Biesheuvel]

On 7 December 2017 at 15:12, Ard Biesheuvel  wrote:
> ASSERT_EFI_ERROR () is currently defined as
>
>   #if !defined(MDEPKG_NDEBUG)
> #define ASSERT_EFI_ERROR(StatusParameter) 
>  \
>   do {
>  \
> if (DebugAssertEnabled ()) {  
>  \
>   if (EFI_ERROR (StatusParameter)) {  
>  \
> DEBUG ((EFI_D_ERROR, "\nASSERT_EFI_ERROR (Status = %r)\n", 
> StatusParameter));  \
> _ASSERT (!EFI_ERROR (StatusParameter));   
>  \
>   }   
>  \
> } 
>  \
>   } while (FALSE)
>   #else
> #define ASSERT_EFI_ERROR(StatusParameter)
>   #endif
>
> This is suboptimal, given that the DebugAssertEnabled () call in the
> outer if must be executed unconditionally, since the compiler does not
> know that it does not have any side effects. Instead, let's swap the
> two ifs, and only call DebugAssertEnabled () if StatusParameter contains
> an error value to begin with. Do the same for ASSERT_RETURN_ERROR
> as well.
>

I just noticed we could do the same for ASSERT () as well.

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> Reported-by: Alexei Fedorov 
> ---
>  MdePkg/Include/Library/DebugLib.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/MdePkg/Include/Library/DebugLib.h 
> b/MdePkg/Include/Library/DebugLib.h
> index 3a910e6a208b..8369c378e79c 100644
> --- a/MdePkg/Include/Library/DebugLib.h
> +++ b/MdePkg/Include/Library/DebugLib.h
> @@ -337,8 +337,8 @@ DebugPrintLevelEnabled (
>  #if !defined(MDEPKG_NDEBUG)
>#define ASSERT_EFI_ERROR(StatusParameter)  
> \
>  do { 
> \
> -  if (DebugAssertEnabled ()) {   
> \
> -if (EFI_ERROR (StatusParameter)) {   
> \
> +  if (EFI_ERROR (StatusParameter)) { 
> \
> +if (DebugAssertEnabled ()) { 
> \
>DEBUG ((EFI_D_ERROR, "\nASSERT_EFI_ERROR (Status = %r)\n", 
> StatusParameter));  \
>_ASSERT (!EFI_ERROR (StatusParameter));
> \
>  }
> \
> @@ -363,8 +363,8 @@ DebugPrintLevelEnabled (
>  #if !defined(MDEPKG_NDEBUG)
>#define ASSERT_RETURN_ERROR(StatusParameter)  \
>  do {\
> -  if (DebugAssertEnabled ()) {  \
> -if (RETURN_ERROR (StatusParameter)) {   \
> +  if (RETURN_ERROR (StatusParameter)) { \
> +if (DebugAssertEnabled ()) {\
>DEBUG ((DEBUG_ERROR, "\nASSERT_RETURN_ERROR (Status = %r)\n", \
>  StatusParameter));  \
>_ASSERT (!RETURN_ERROR (StatusParameter));\
> --
> 2.11.0
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] MdePkg/DebugLib; swap if conditions in ASSERT_[EFI|RETURN]_ERROR

[Ard Biesheuvel]

ASSERT_EFI_ERROR () is currently defined as

  #if !defined(MDEPKG_NDEBUG)
#define ASSERT_EFI_ERROR(StatusParameter)   
   \
  do {  
   \
if (DebugAssertEnabled ()) {
   \
  if (EFI_ERROR (StatusParameter)) {
   \
DEBUG ((EFI_D_ERROR, "\nASSERT_EFI_ERROR (Status = %r)\n", 
StatusParameter));  \
_ASSERT (!EFI_ERROR (StatusParameter)); 
   \
  } 
   \
}   
   \
  } while (FALSE)
  #else
#define ASSERT_EFI_ERROR(StatusParameter)
  #endif

This is suboptimal, given that the DebugAssertEnabled () call in the
outer if must be executed unconditionally, since the compiler does not
know that it does not have any side effects. Instead, let's swap the
two ifs, and only call DebugAssertEnabled () if StatusParameter contains
an error value to begin with. Do the same for ASSERT_RETURN_ERROR
as well.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel 
Reported-by: Alexei Fedorov 
---
 MdePkg/Include/Library/DebugLib.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Include/Library/DebugLib.h 
b/MdePkg/Include/Library/DebugLib.h
index 3a910e6a208b..8369c378e79c 100644
--- a/MdePkg/Include/Library/DebugLib.h
+++ b/MdePkg/Include/Library/DebugLib.h
@@ -337,8 +337,8 @@ DebugPrintLevelEnabled (
 #if !defined(MDEPKG_NDEBUG)
   #define ASSERT_EFI_ERROR(StatusParameter)
  \
 do {   
  \
-  if (DebugAssertEnabled ()) { 
  \
-if (EFI_ERROR (StatusParameter)) { 
  \
+  if (EFI_ERROR (StatusParameter)) {   
  \
+if (DebugAssertEnabled ()) {   
  \
   DEBUG ((EFI_D_ERROR, "\nASSERT_EFI_ERROR (Status = %r)\n", 
StatusParameter));  \
   _ASSERT (!EFI_ERROR (StatusParameter));  
  \
 }  
  \
@@ -363,8 +363,8 @@ DebugPrintLevelEnabled (
 #if !defined(MDEPKG_NDEBUG)
   #define ASSERT_RETURN_ERROR(StatusParameter)  \
 do {\
-  if (DebugAssertEnabled ()) {  \
-if (RETURN_ERROR (StatusParameter)) {   \
+  if (RETURN_ERROR (StatusParameter)) { \
+if (DebugAssertEnabled ()) {\
   DEBUG ((DEBUG_ERROR, "\nASSERT_RETURN_ERROR (Status = %r)\n", \
 StatusParameter));  \
   _ASSERT (!RETURN_ERROR (StatusParameter));\
-- 
2.11.0

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

Re: [edk2] [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add debug asserts

[Ard Biesheuvel]

On 7 December 2017 at 14:55, Alexei Fedorov  wrote:
> Hi,
>
> I've compiled current HdLcd.c code with different optimisation levels for
> DEBUG build using GCC 7.2.1, and the assembler code below was generated for:
>
>   ASSERT_EFI_ERROR (Status);
>   if (EFI_ERROR( Status )) {
> return EFI_DEVICE_ERROR;
>   }
>
> -O0 (default DEBUG option for AARCH64 before Ard's patch):
>
>
> strx0, [x29, 72]//, Status
>
> // r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:
> ASSERT_EFI_ERROR (Status);
> .loc 1 79 0
> blDebugAssertEnabled//
> andw0, w0, 255// _1, tmp150
> cmpw0, 0// _1,
> beq.L4//,
> ldrx0, [x29, 72]// Status.9_2, Status
> cmpx0, 0// Status.9_2,
> bge.L4//,
>
> 2.  -Os:
>
>  movx19, x0// Status,
> // r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:
> ASSERT_EFI_ERROR (Status);
> .loc 1 79 0
> blDebugAssertEnabled//
> .LVL15:
> tstw0, 255//
> beq.L4//,
> tbzx19, #63, .L8// Status,
>
> 3.  -O3:
>
> movx19, x0// Status,
> .LVL14:
> // r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:
> ASSERT_EFI_ERROR (Status);
> blDebugAssertEnabled//
> .LVL15:
> tstw0, 255//
> beq.L5//,
> tbnzx19, #63, .L26// Status,
>
> with DebugAssertEnabled() compiled as:
>
> DebugAssertEnabled:
> .LFB4:
> .loc 1 203 0
> .cfi_startproc
> // r:\edk2\MdePkg\Library\BaseDebugLibSerialPort\DebugLib.c:204:   return
> (BOOLEAN) ((PcdGet8(PcdDebugPropertyMask) &
> DEBUG_PROPERTY_DEBUG_ASSERT_ENABLED) != 0);
> .loc 1 204 0
> adrpx0, _gPcd_FixedAtBuild_PcdDebugPropertyMask// tmp80,
> addx0, x0, :lo12:_gPcd_FixedAtBuild_PcdDebugPropertyMask//
> tmp79, tmp80,
> ldrbw0, [x0]// _gPcd_FixedAtBuild_PcdDebugPropertyMask.4_1,
> _gPcd_FixedAtBuild_PcdDebugPropertyMask
> andw0, w0, 1// _3, _2,
> cmpw0, 0// _3,
> csetw0, ne// tmp82,
> andw0, w0, 255// _4, tmp81
> // r:\edk2\MdePkg\Library\BaseDebugLibSerialPort\DebugLib.c:205: }
> .loc 1 205 0
> ret
>
> As you can see each "ASSERT_EFI_ERROR (Status)" macro requires
> DebugAssertEnabled() call taking 8 instructions by itself + minimum 3
> instructions (for -Os, -O3) for Status check, which will be performed by "if
> (EFI_ERROR( Status ))" anyway.
> Please correct me if I'm wrong assuming that placing
> ASSERT_EFI_ERROR (Status)
> inside
> if (EFI_ERROR( Status )) {
> statement is an optimisation improvement.
>

Thanks for digging this up. This appears to be an oversight in the
definition of the ASSERT_EFI_ERROR () macro, which is currently
defined as

#if !defined(MDEPKG_NDEBUG)
  #define ASSERT_EFI_ERROR(StatusParameter)  \
do { \
  if (DebugAssertEnabled ()) {   \
if (EFI_ERROR (StatusParameter)) {   \

which is obviously the wrong way around, given that the compiler can
never optimize away the function call, due to its potential side
effects (which it doesn't have)

So I will propose to fix this, by swapping the two if () statements.
Please let me know if the issue is still reproducible with that patch
applied.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/2] MdePkg MmCommunication.h: Follow PI spec to update EFI_MM_COMMUNICATE

[Gao, Liming]

Reviewed-by: Liming Gao 

> -Original Message-
> From: Zeng, Star
> Sent: Wednesday, December 6, 2017 5:18 PM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Yao, Jiewen ; 
> Gao, Liming ; Kinney, Michael D
> 
> Subject: [PATCH 1/2] MdePkg MmCommunication.h: Follow PI spec to update 
> EFI_MM_COMMUNICATE
> 
> Follow PI spec (>= 1.5) to add new return status code description
> and make CommSize OPTIONAL.
> 
> Cc: Jiewen Yao 
> Cc: Liming Gao 
> Cc: Michael D Kinney 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng 
> ---
>  MdePkg/Include/Protocol/MmCommunication.h | 14 --
>  1 file changed, 12 insertions(+), 2 deletions(-)
> 
> diff --git a/MdePkg/Include/Protocol/MmCommunication.h 
> b/MdePkg/Include/Protocol/MmCommunication.h
> index 16450e3445b0..774686ba3e7f 100644
> --- a/MdePkg/Include/Protocol/MmCommunication.h
> +++ b/MdePkg/Include/Protocol/MmCommunication.h
> @@ -55,18 +55,28 @@ typedef struct _EFI_MM_COMMUNICATION_PROTOCOL  
> EFI_MM_COMMUNICATION_PROTOCOL;
> 
>@param[in] ThisThe EFI_MM_COMMUNICATION_PROTOCOL instance.
>@param[in] CommBuffer  A pointer to the buffer to convey into 
> MMRAM.
> -  @param[in] CommSizeThe size of the data buffer being passed 
> in.On exit, the size of data
> +  @param[in] CommSizeThe size of the data buffer being passed 
> in. On exit, the size of data
>   being returned. Zero if the handler does 
> not wish to reply with any data.
> + This parameter is optional and may be NULL.
> 
>@retval EFI_SUCCESSThe message was successfully posted.
>@retval EFI_INVALID_PARAMETER  The CommBuffer was NULL.
> +  @retval EFI_BAD_BUFFER_SIZEThe buffer is too large for the MM 
> implementation.
> + If this error is returned, the 
> MessageLength field
> + in the CommBuffer header or the integer 
> pointed by
> + CommSize, are updated to reflect the 
> maximum payload
> + size the implementation can accommodate.
> +  @retval EFI_ACCESS_DENIED  The CommunicateBuffer parameter or CommSize 
> parameter,
> + if not omitted, are in address range that 
> cannot be
> + accessed by the MM environment.
> +
>  **/
>  typedef
>  EFI_STATUS
>  (EFIAPI *EFI_MM_COMMUNICATE)(
>IN CONST EFI_MM_COMMUNICATION_PROTOCOL   *This,
>IN OUT VOID  *CommBuffer,
> -  IN OUT UINTN *CommSize
> +  IN OUT UINTN *CommSize OPTIONAL
>);
> 
>  ///
> --
> 2.7.0.windows.1

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

Re: [edk2] [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add debug asserts

[Alexei Fedorov]

Hi,

I've compiled current HdLcd.c code with different optimisation levels for DEBUG 
build using GCC 7.2.1, and the assembler code below was generated for:

  ASSERT_EFI_ERROR (Status);
  if (EFI_ERROR( Status )) {
return EFI_DEVICE_ERROR;
  }


  1.  -O0 (default DEBUG option for AARCH64 before Ard's patch):


strx0, [x29, 72]//, Status

// r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:   
ASSERT_EFI_ERROR (Status);
.loc 1 79 0
blDebugAssertEnabled//
andw0, w0, 255// _1, tmp150
cmpw0, 0// _1,
beq.L4//,
ldrx0, [x29, 72]// Status.9_2, Status
cmpx0, 0// Status.9_2,
bge.L4//,

2.  -Os:

 movx19, x0// Status,
// r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:   
ASSERT_EFI_ERROR (Status);
.loc 1 79 0
blDebugAssertEnabled//
.LVL15:
tstw0, 255//
beq.L4//,
tbzx19, #63, .L8// Status,

3.  -O3:

movx19, x0// Status,
.LVL14:
// r:\edk2\ArmPlatformPkg\Drivers\LcdGraphicsOutputDxe\HdLcd.c:79:   
ASSERT_EFI_ERROR (Status);
blDebugAssertEnabled//
.LVL15:
tstw0, 255//
beq.L5//,
tbnzx19, #63, .L26// Status,

with DebugAssertEnabled() compiled as:

DebugAssertEnabled:
.LFB4:
.loc 1 203 0
.cfi_startproc
// r:\edk2\MdePkg\Library\BaseDebugLibSerialPort\DebugLib.c:204:   return 
(BOOLEAN) ((PcdGet8(PcdDebugPropertyMask) & 
DEBUG_PROPERTY_DEBUG_ASSERT_ENABLED) != 0);
.loc 1 204 0
adrpx0, _gPcd_FixedAtBuild_PcdDebugPropertyMask// tmp80,
addx0, x0, :lo12:_gPcd_FixedAtBuild_PcdDebugPropertyMask// tmp79, 
tmp80,
ldrbw0, [x0]// _gPcd_FixedAtBuild_PcdDebugPropertyMask.4_1, 
_gPcd_FixedAtBuild_PcdDebugPropertyMask
andw0, w0, 1// _3, _2,
cmpw0, 0// _3,
csetw0, ne// tmp82,
andw0, w0, 255// _4, tmp81
// r:\edk2\MdePkg\Library\BaseDebugLibSerialPort\DebugLib.c:205: }
.loc 1 205 0
ret

As you can see each "ASSERT_EFI_ERROR (Status)" macro requires 
DebugAssertEnabled() call taking 8 instructions by itself + minimum 3 
instructions (for -Os, -O3) for Status check, which will be performed by "if 
(EFI_ERROR( Status ))" anyway.
Please correct me if I'm wrong assuming that placing
ASSERT_EFI_ERROR (Status)
inside
if (EFI_ERROR( Status )) {
statement is an optimisation improvement.

Thank you for your cooperation.

Alexei.



> >> > -  ASSERT_EFI_ERROR (Status);
> >> >if (EFI_ERROR (Status)) {
> >> > +ASSERT_EFI_ERROR (Status);
> >>
> >> What is the point of this change?
> > [[Evan Lloyd]] It is a minor efficiency improvement.  Since the ASSERT can
> only fire when the if condition is true, it removes a duplicated test from the
> main (non-error) code flow.  This is irrelevant on hardware, but actually
> significant when running debug builds on an emulator environment.
> >
>
> Fair enough. But I'd prefer to finally fix the DEBUG vs NOOPT build targets
> for ARM/AARCH64. DEBUG was never intended to be -O0 (and it is not on
> X86 either).
>
> Code is complex enough as it is, and how to move trivial tests like this
> around for 'performance' reasons is a dimension I would like to avoid.

  >[[Evan Lloyd]] I have no objection to the DEBUG build being updated from -O0.
>I strongly suspect that it was set to that because it reduced the incidence of 
>the r18 problem that has now been fixed.
>However, I can certainly envisage circumstances when we might need to do an 
>emulator run with -O0 used for the build - so the >

>reordering would still be beneficial.



From: edk2-devel  on behalf of Evan Lloyd 

Sent: 05 December 2017 20:46
To: Ard Biesheuvel
Cc: edk2-devel@lists.01.org; leif.lindh...@linaro.org@arm.com; 
n...@arm.com@arm.com; ard.biesheu...@linaro.org@arm.com; 
matteo.carl...@arm.com@arm.com
Subject: Re: [edk2] [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add 
debug asserts



> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: 01 December 2017 17:35
> To: Evan Lloyd 
> Cc: edk2-devel@lists.01.org; ard.biesheu...@linaro.org@arm.com
> <"ard.biesheu...@linaro.org"@arm.com>;
> leif.lindh...@linaro.org@arm.com <"leif.lindh...@linaro.org"@arm.com>;
> matteo.carl...@arm.com@arm.com
> <"matteo.carl...@arm.com"@arm.com>; n...@arm.com@arm.com
> <"n...@arm.com"@arm.com>
> Subject: Re: [PATCH 04/19] ArmPlatformPkg: LcdGraphicsOurputDxe: Add
> debug asserts
>
> On 1 December 2017 at 16:33, Evan Lloyd  wrote:
> > Responses inline:
> >
> >> -Original Message-
> >> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> >> Sent: 13 October 2017 08:33
> >> To: Evan Lloyd 
> >> Cc: edk2-devel@lists.01.org; "ard.biesheu...@linaro.org"@arm.com;
> >> "leif.lindh...@linaro.org"@arm.com;
> >> 

Re: [edk2] [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support for Watchdog driver

[Gao, Liming]

Leif:
  I don't review the whole patch serial. Could you point your usage case on 
watch dog timer protocol?

Thanks
Liming
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: Thursday, December 7, 2017 7:04 PM
> To: Gao, Liming 
> Cc: Udit Kumar ; Kinney, Michael D 
> ; Meenakshi Aggarwal
> ; ard.biesheu...@linaro.org; 
> edk2-devel@lists.01.org; Varun Sethi 
> Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support 
> for Watchdog driver
> 
> Hi Liming,
> 
> On Thu, Dec 07, 2017 at 07:11:38AM +, Gao, Liming wrote:
> > Leif:
> >   I don't see the core driver uses
> >   WatchdogTimer->RegisterHandler(). When it returns unsupported, it
> >   means the additional handler can't be registered. DxeCore uses
> >   WatchdogTimer->SetTimerPeriod(). This service is implemented in
> >   your driver.
> >
> >   Watchdog protocol is defined in PI spec. Spec describes that this
> >   protocol provides the services required to implement the Boot
> >   Service SetWatchdogTimer(). It provides a service to set the
> >   amount of time to wait before firing the watchdog timer, and it
> >   also provides a service to register a handler that is invoked when
> >   the watchdog timer fires. This protocol can implement the watchdog
> >   timer by using the event and timer Boot Services, or it can make
> >   use of custom hardware. If no handler has been registered, or the
> >   registered handler returns, then the system will be reset by
> >   calling the Runtime Service ResetSystem(). So, this protocol is
> >   required.
> 
> I am not disputing that the protocol is not required. I am suggesting
> that this hardware watchdog _cannot_ be used to register a handler.
> 
> If this hardware watchdog does not get updated in time, that causes an
> immediate hardware reset of the processor.
> 
> Because of this, I believe EFI_WATCHDOG_TIMER_ARCH_PROTOCOL is not the
> appropriate way to make use of it.
> 
> Please let me know whether you agree.
> 
> Regards,
> 
> Leif
> 
> > Thanks
> > Liming
> > >-Original Message-
> > >From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > >Sent: Tuesday, December 05, 2017 7:06 PM
> > >To: Udit Kumar 
> > >Cc: Gao, Liming ; Kinney, Michael D
> > >; Meenakshi Aggarwal
> > >; ard.biesheu...@linaro.org; edk2-
> > >de...@lists.01.org; Varun Sethi 
> > >Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> > >support for Watchdog driver
> > >
> > >On Tue, Dec 05, 2017 at 05:07:00AM +, Udit Kumar wrote:
> > >> >   I suggest return EFI_UNSUPPORTED for this case. The protocol
> > >implementation
> > >> > could return its status besides spec defined status.
> > >>
> > >> Thanks to help me , how core will treat this error
> > >> 1/  Wdt not available
> > >> 2/ ignoring this error
> > >> 3/ core is not registering handler
> > >> I guess 3 is valid,
> > >
> > >Looking at Core/Dxe/Misc/SetWatchdogTimer.c:
> > >  //
> > >  // Attempt to set the timeout
> > >  //
> > >  Status = gWatchdogTimer->SetTimerPeriod (gWatchdogTimer,
> > >  MultU64x32 (Timeout, WATCHDOG_TIMER_CALIBRATE_PER_SECOND));
> > >
> > >  //
> > >  // Check for errors
> > >  //
> > >  if (EFI_ERROR (Status)) {
> > >return EFI_DEVICE_ERROR;
> > >  }
> > >
> > >The SetWatchdogTimer() call would always return EFI_DEVICE_ERROR.
> > >
> > >> On side track, looks wdt is not used by core services then do we
> > >> really need this as part of arch protocol ?
> > >
> > >Yes, that was ultimately what I was implying with my question
> > >regarding whether this protocol is relevant for a watchdog that can
> > >only ever reset the system on timeout.
> > >
> > >The protocol looks to me to be designed to use a dedicated generic
> > >timer as backing for a software watchdog.
> > >
> > >Liming, Mike?
> > >
> > >If that is the case, then I agree this driver should probably not
> > >implement this protocol, but rather set up a timer event (or a
> > >dedicated timer) to stroke the watchdog.
> > >
> > >Regards,
> > >
> > >Leif
> > >
> > >> regards
> > >> Udit
> > >>
> > >> > -Original Message-
> > >> > From: Gao, Liming [mailto:liming@intel.com]
> > >> > Sent: Monday, December 04, 2017 8:53 PM
> > >> > To: Leif Lindholm ; Kinney, Michael D
> > >> > 
> > >> > Cc: Meenakshi Aggarwal ;
> > >> > ard.biesheu...@linaro.org; edk2-devel@lists.01.org; Udit Kumar
> > >> > ; Varun Sethi 
> > >> > Subject: RE: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> > >support
> > >> > for Watchdog driver
> > >> >
> > >> > Leif:
> > >> >   I suggest return EFI_UNSUPPORTED for this case. The protocol
> > >implementation
> > >> 

Re: [edk2] [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support for Watchdog driver

[Gao, Liming]

CoreSetWatchdogTimer() allows the error status for watchdog service.

> -Original Message-
> From: Udit Kumar [mailto:udit.ku...@nxp.com]
> Sent: Thursday, December 7, 2017 7:15 PM
> To: Gao, Liming ; Leif Lindholm 
> 
> Cc: Kinney, Michael D ; Meenakshi Aggarwal 
> ;
> ard.biesheu...@linaro.org; edk2-devel@lists.01.org; Varun Sethi 
> 
> Subject: RE: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support 
> for Watchdog driver
> 
> Hi Liming,
> 
> > DxeCore uses WatchdogTimer->SetTimerPeriod(). This service is implemented in
> > your driver.
> 
> Callers of SetTimerPeriod are ignoring error reported.
> Is they assume this call will be perfect or they are ok in case some error on 
> watchdog service.
> 
> 
> Regards
> Udit
> 
> > -Original Message-
> > From: Gao, Liming [mailto:liming@intel.com]
> > Sent: Thursday, December 07, 2017 12:42 PM
> > To: Leif Lindholm ; Udit Kumar
> > 
> > Cc: Kinney, Michael D ; Meenakshi Aggarwal
> > ; ard.biesheu...@linaro.org; edk2-
> > de...@lists.01.org; Varun Sethi 
> > Subject: RE: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add 
> > support
> > for Watchdog driver
> >
> > Leif:
> >   I don't see the core driver uses WatchdogTimer->RegisterHandler(). When it
> > returns unsupported, it means the additional handler can't be registered.
> > DxeCore uses WatchdogTimer->SetTimerPeriod(). This service is implemented in
> > your driver.
> >
> >   Watchdog protocol is defined in PI spec. Spec describes that this protocol
> > provides the services required to implement the Boot Service
> > SetWatchdogTimer(). It provides a service to set the amount of time to wait
> > before firing the watchdog timer, and it also provides a service to 
> > register a
> > handler that is invoked when the watchdog timer fires. This protocol can
> > implement the watchdog timer by using the event and timer Boot Services, or 
> > it
> > can make use of custom hardware. If no handler has been registered, or the
> > registered handler returns, then the system will be reset by calling the 
> > Runtime
> > Service ResetSystem(). So, this protocol is required.
> >
> > Thanks
> > Liming
> > >-Original Message-
> > >From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> > >Sent: Tuesday, December 05, 2017 7:06 PM
> > >To: Udit Kumar 
> > >Cc: Gao, Liming ; Kinney, Michael D
> > >; Meenakshi Aggarwal
> > >; ard.biesheu...@linaro.org; edk2-
> > >de...@lists.01.org; Varun Sethi 
> > >Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> > >support for Watchdog driver
> > >
> > >On Tue, Dec 05, 2017 at 05:07:00AM +, Udit Kumar wrote:
> > >> >   I suggest return EFI_UNSUPPORTED for this case. The protocol
> > >implementation
> > >> > could return its status besides spec defined status.
> > >>
> > >> Thanks to help me , how core will treat this error 1/  Wdt not
> > >> available 2/ ignoring this error 3/ core is not registering handler I
> > >> guess 3 is valid,
> > >
> > >Looking at Core/Dxe/Misc/SetWatchdogTimer.c:
> > >  //
> > >  // Attempt to set the timeout
> > >  //
> > >  Status = gWatchdogTimer->SetTimerPeriod (gWatchdogTimer,
> > >  MultU64x32 (Timeout, WATCHDOG_TIMER_CALIBRATE_PER_SECOND));
> > >
> > >  //
> > >  // Check for errors
> > >  //
> > >  if (EFI_ERROR (Status)) {
> > >return EFI_DEVICE_ERROR;
> > >  }
> > >
> > >The SetWatchdogTimer() call would always return EFI_DEVICE_ERROR.
> > >
> > >> On side track, looks wdt is not used by core services then do we
> > >> really need this as part of arch protocol ?
> > >
> > >Yes, that was ultimately what I was implying with my question regarding
> > >whether this protocol is relevant for a watchdog that can only ever
> > >reset the system on timeout.
> > >
> > >The protocol looks to me to be designed to use a dedicated generic
> > >timer as backing for a software watchdog.
> > >
> > >Liming, Mike?
> > >
> > >If that is the case, then I agree this driver should probably not
> > >implement this protocol, but rather set up a timer event (or a
> > >dedicated timer) to stroke the watchdog.
> > >
> > >Regards,
> > >
> > >Leif
> > >
> > >> regards
> > >> Udit
> > >>
> > >> > -Original Message-
> > >> > From: Gao, Liming [mailto:liming@intel.com]
> > >> > Sent: Monday, December 04, 2017 8:53 PM
> > >> > To: Leif Lindholm ; Kinney, Michael D
> > >> > 
> > >> > Cc: Meenakshi Aggarwal ;
> > >> > ard.biesheu...@linaro.org; edk2-devel@lists.01.org; Udit Kumar
> > >> > ; Varun Sethi 
> > >> > Subject: RE: [PATCH 

Re: [edk2] [RFC] MdePkg/Spi : Modify SPI Protocol strctures to make it more generic

[Leif Lindholm]

Adding MdePkg maintainers: Mike and Liming.

Please always cc package maintainers (listed in Maintainers.txt).

/
Leif

On Thu, Dec 07, 2017 at 02:05:19PM +0530, Pankaj Bansal wrote:
> Issue_1: Currenty SPI IO and SPI HC protocol strcture is not equipped
> to handle all type of SPI commands
> e.g. QuadIo Read Command (0xEBh) in spansion flash S25FS512S will not
> work.
> 
> Cause: Currenty SPI protocol describes a SPI transaction as combination
> of data and address and command, which would all be transmitted on
> same data bus (1 or 2 or 4).
> 
> BUT when we have a case in which command is send one single data bus and
> address and data is sent one 4 data bus (like 0xEB in spansion), then
> this will not work with current strcture.
> 
> Fix: Instead of making a single transaction, we can specify a group of
> transactions (called packet, terminology borrowed from I2c Protocol) in
> which each transaction specifies the data width, frequency, delay and
> read/write info.
> 
> Issue_2: Specify additional data about SPI transaction (i.e. transaction
> is of type cmd, address, data, dummy etc). some controllers need this
> info to communicate with SPI peripheral. others can ignore this info.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Pankaj Bansal 
> ---
>  MdePkg/Include/Protocol/SpiHc.h |  15 +-
>  MdePkg/Include/Protocol/SpiIo.h | 250 --
>  2 files changed, 104 insertions(+), 161 deletions(-)
> 
> diff --git a/MdePkg/Include/Protocol/SpiHc.h b/MdePkg/Include/Protocol/SpiHc.h
> index 12fe5d2..65964bc 100644
> --- a/MdePkg/Include/Protocol/SpiHc.h
> +++ b/MdePkg/Include/Protocol/SpiHc.h
> @@ -110,8 +110,11 @@ typedef EFI_STATUS
>status.
>  
>@param[in] ThisPointer to an EFI_SPI_HC_PROTOCOL structure.
> -  @param[in] BusTransaction  Pointer to a EFI_SPI_BUS_ TRANSACTION containing
> - the description of the SPI transaction to 
> perform.
> +  @param[in] SpiPeripheral   The address of an EFI_SPI_PERIPHERAL data 
> structure
> + describing the SPI peripheral from(to) which
> + read(write) transactions to be performed.
> +  @param[in] RequestPacket   Pointer to a EFI_SPI_REQUEST_PACKET containing
> + the description of the SPI transactions to 
> perform.
>  
>@retval EFI_SUCCESS  The transaction completed successfully
>@retval EFI_BAD_BUFFER_SIZE  The BusTransaction->WriteBytes value is 
> invalid,
> @@ -124,7 +127,8 @@ typedef EFI_STATUS
>  typedef EFI_STATUS
>  (EFIAPI *EFI_SPI_HC_PROTOCOL_TRANSACTION) (
>IN CONST EFI_SPI_HC_PROTOCOL  *This,
> -  IN EFI_SPI_BUS_TRANSACTION*BusTransaction
> +  IN CONST EFI_SPI_PERIPHERAL   *SpiPeripheral;
> +  IN EFI_SPI_REQUEST_PACKET *RequestPacket
>);
>  
>  ///
> @@ -135,7 +139,6 @@ struct _EFI_SPI_HC_PROTOCOL {
>/// Host control attributes, may have zero or more of the following set:
>/// * HC_SUPPORTS_WRITE_ONLY_OPERATIONS
>/// * HC_SUPPORTS_READ_ONLY_OPERATIONS
> -  /// * HC_SUPPORTS_WRITE_THEN_READ_OPERATIONS
>/// * HC_TX_FRAME_IN_MOST_SIGNIFICANT_BITS
>///   - The SPI host controller requires the transmit frame to be in most
>/// significant bits instead of least significant bits.The host driver
> @@ -149,10 +152,6 @@ struct _EFI_SPI_HC_PROTOCOL {
>///   - The SPI controller supports a 2 - bit data bus
>/// * HC_SUPPORTS_4_B1T_DATA_BUS_WIDTH
>///   - The SPI controller supports a 4 - bit data bus
> -  /// * HC_TRANSFER_SIZE_INCLUDES_OPCODE
> -  ///   - Transfer size includes the opcode byte
> -  /// * HC_TRANSFER_SIZE_INCLUDES_ADDRESS
> -  ///   - Transfer size includes the 3 address bytes
>/// The SPI host controller must support full - duplex (receive while
>/// sending) operation.The SPI host controller must support a 1 - bit bus
>/// width.
> diff --git a/MdePkg/Include/Protocol/SpiIo.h b/MdePkg/Include/Protocol/SpiIo.h
> index 43e8045..507abb5 100644
> --- a/MdePkg/Include/Protocol/SpiIo.h
> +++ b/MdePkg/Include/Protocol/SpiIo.h
> @@ -27,147 +27,33 @@ typedef struct _EFI_SPI_IO_PROTOCOL EFI_SPI_IO_PROTOCOL;
>  /// Note: The UEFI PI 1.6 specification does not specify values for the
>  ///   members below. The order matches the specification.
>  ///
> +///
> +/// SPI peripheral transfer type
> +///
> +/// The EFI_SPI_TRANSACTION_TYPE describes the type of SPI transaction to 
> either
> +/// send or recievce from SPI peripheral.
> +/// some SPI controllers need this information to complete a SPI operation
> +/// (which consists of one or many transactions)
> +///
> +/// for other controllers this field may be left 0 (SPI_TRANSACTION_NONE)
> +///
>  typedef enum {
> -  ///
> -  /// Data flowing in both direction between the host and
> -  /// SPI peripheral.ReadBytes must equal WriteBytes and both ReadBuffer and
> -  /// WriteBuffer must be provided.
> -  ///
> -  

Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file

[Leif Lindholm]

Hi Yonghong,

I do not have the DSC that was used to build it. The FDF is
https://github.com/tianocore/edk2-platforms/blob/master/Platform/Hisilicon/D05/D05.fdf#L250

Jason (cc) may be able to provide more information on the binary.

Best Regards,

Leif

On Thu, Dec 07, 2017 at 12:55:48PM +, Zhu, Yonghong wrote:
> Hi Leif,
> 
> May I know how this binary driver is described in DSC file and FDF
> file, and the [Rule.Common.DXE_DRIVER.BINARY] section ?
> I tried to add this driver into OvmfPkg, but failed to reproduce
> this failure. Thanks.
> 
> Best Regards,
> Zhu Yonghong
> 
> 
> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org] 
> Sent: Thursday, December 07, 2017 7:30 PM
> To: Zhu, Yonghong 
> Cc: edk2-devel@lists.01.org; Feng, YunhuaX ; Gao, 
> Liming 
> Subject: Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file
> 
> Hi Yonghong,
> 
> This patch resolves the issue for the hikey platform, but not for 
> (edk2-platforms/Platform/Hisilicon/)D03/D05. They fail with
> 
> ---
> Generating FVMAIN FV
> ##
> 
> #Return Value = 2
> GenSec: ERROR 0001: Error opening file
> 
>   
> /work/git/tianocore/Build/D03/DEBUG_GCC5/AARCH64/Platform/Hisilicon/D03/Drivers/Net/SnpPlatform/SnpPlatform/OUTPUT/SnpPlatform.depex
> GenSec: ERROR 2000: Status is not successful
> ---
> 
> and
> 
> ---
> Generating FVMAIN FV
> ##
> 
> 
> Return Value = 2
> GenSec: ERROR 0001: Error opening file
> 
> 
>   
> /work/git/tianocore/Build/D05/RELEASE_GCC5/AARCH64/Platform/Hisilicon/D05/Drivers/Net/SnpPlatform/SnpPlatform/OUTPUT/SnpPlatform.depex
> GenFds.py...
>  : error 7000: Failed to generate section
> GenSec: ERROR 2000: Status is not successful
> ---
> 
> respectively.
> 
> Again, reverting 37de70b7 makes the build successful again.
> 
> Note that the failing drivers are binary, held in edk2-non-osi.
> 
> Regards,
> 
> Leif
> 
> On Thu, Dec 07, 2017 at 02:51:17PM +0800, Yonghong Zhu wrote:
> > From: Yunhua Feng 
> > 
> > Filter the FileList when multiple genfds thread options is not enabled.
> > 
> > Cc: Liming Gao 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Yunhua Feng 
> > ---
> >  BaseTools/Source/Python/GenFds/EfiSection.py | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/BaseTools/Source/Python/GenFds/EfiSection.py 
> > b/BaseTools/Source/Python/GenFds/EfiSection.py
> > index 7b3b717191..4276945a10 100644
> > --- a/BaseTools/Source/Python/GenFds/EfiSection.py
> > +++ b/BaseTools/Source/Python/GenFds/EfiSection.py
> > @@ -92,7 +92,8 @@ class EfiSection (EfiSectionClassObject):
> >  elif os.path.exists(Filename):
> >  FileList.append(Filename)
> >  elif '.depex' in FfsInf.FinalTargetSuffixMap or FfsInf.Depex:
> > -FileList.append(Filename)
> > +if IsMakefile:
> > +FileList.append(Filename)
> >  else:
> >  FileList, IsSect = Section.Section.GetFileList(FfsInf, 
> > self.FileType, self.FileExtension, Dict)
> >  if IsSect :
> > --
> > 2.12.2.windows.2
> > 
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 0/3] Adding secure boot and HTTP image download features for Linux based platform

[Kalyan Nagabhirava]

yes Ard,
but this is not platform sepecfic only application code, leif has given
comments on this application , addressed his comments
and send the patch.

On 7 December 2017 at 19:36, Ard Biesheuvel 
wrote:

> On 7 December 2017 at 13:34, kalyan-nagabhirava
>  wrote:
> > Linaro and RDK are  working on standardizing the boot process for RDK
> STB boxes using Uefi.
> > Added applications are reference implementation of RDK STB boot process
> on Arm platforms
> >
>
> Please don't add this to EmbeddedPkg. I thought we agreed to put this
> in edk2-platforms/Platform/Comcast?
>
> > kalyan-nagabhirava (3):
> >   [edk2 EmbeddedPkg]:Implementation of secure boot and HTTP Image
> > download
> >   EmbeddedPkg: secureboot application using RdkBootManagerLib
> >   EmbeddedPkg: Httpimage downlaod application
> >
> >  EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.dec   |
> 52 ++
> >  EmbeddedPkg/Application/Dri/Dri.inf   |
> 56 ++
> >  EmbeddedPkg/Application/SecureBoot/SecureBoot.inf |
> 57 ++
> >  EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.inf   |
> 81 +++
> >  EmbeddedPkg/Library/RdkBootManagerLib/Include/DiskIo.h|
> 20 +
> >  EmbeddedPkg/Library/RdkBootManagerLib/Include/HttpBoot.h  |
>  7 +
> >  EmbeddedPkg/Library/RdkBootManagerLib/Include/List.h  |
> 52 ++
> >  EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkBootManagerLib.h |
> 31 ++
> >  EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkFile.h   |
> 20 +
> >  EmbeddedPkg/Library/RdkBootManagerLib/Include/SecureBoot.h|
> 40 ++
> >  EmbeddedPkg/Application/Dri/Dri.c |
> 26 +
> >  EmbeddedPkg/Application/SecureBoot/SecureBoot.c   |
> 30 +
> >  EmbeddedPkg/Library/RdkBootManagerLib/DiskIo.c|
> 536 ++
> >  EmbeddedPkg/Library/RdkBootManagerLib/HttpBoot.c  |
> 315 +++
> >  EmbeddedPkg/Library/RdkBootManagerLib/RdkFile.c   |
> 259 +
> >  EmbeddedPkg/Library/RdkBootManagerLib/SecureBoot.c|
> 577 
> >  16 files changed, 2159 insertions(+)
> >  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/
> RdkBootManagerLib.dec
> >  create mode 100644 EmbeddedPkg/Application/Dri/Dri.inf
> >  create mode 100644 EmbeddedPkg/Application/SecureBoot/SecureBoot.inf
> >  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/
> RdkBootManagerLib.inf
> >  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/
> DiskIo.h
> >  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/
> HttpBoot.h
> >  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/List.h
> >  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/
> RdkBootManagerLib.h
> >  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/
> RdkFile.h
> >  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/
> SecureBoot.h
> >  create mode 100644 EmbeddedPkg/Application/Dri/Dri.c
> >  create mode 100644 EmbeddedPkg/Application/SecureBoot/SecureBoot.c
> >  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/DiskIo.c
> >  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/HttpBoot.c
> >  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/RdkFile.c
> >  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/SecureBoot.c
> >
> > --
> > 2.15.0
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
>



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

Re: [edk2] [Patch] SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix duplicate symbol

[Ard Biesheuvel]

On 7 December 2017 at 14:19, Gao, Liming  wrote:
> Ard and Ersek:
>   On VS, static may make debug become hard. And, STATIC + 
> GLOBAL_REMOVE_IF_UNREFERENCED may failure on old VS before VS supports /Gw 
> option. So, I don't add static here.
>   I would like to separate static usage topic. We could discuss more and 
> summary the rule on how to use static in code. But for this build failure 
> issue, I prefer to fix it with this solution first. Is it OK to you?
>

Yes that is fine.

-- 
Ard.

>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Thursday, December 7, 2017 7:41 PM
>> To: Laszlo Ersek 
>> Cc: Gao, Liming ; edk2-devel@lists.01.org; Kinney, 
>> Michael D ; Wu, Hao A
>> ; Andrew Fish ; Jeff Fan 
>> 
>> Subject: Re: [edk2] [Patch] SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix 
>> duplicate symbol
>>
>> On 7 December 2017 at 11:18, Laszlo Ersek  wrote:
>> > On 12/07/17 09:46, Ard Biesheuvel wrote:
>> >> On 7 December 2017 at 07:48, Liming Gao  wrote:
>> >>> From: Michael Kinney 
>> >>>
>> >>> https://bugzilla.tianocore.org/show_bug.cgi?id=573
>> >>> https://bugzilla.tianocore.org/show_bug.cgi?id=796
>> >>>
>> >>> The same issue is reported again by GCC. Resend this patch again.
>> >>> This patch renames the duplicated function name to fix it.
>> >>>
>> >>> The SecPeiDebugAgentLib uses the global variable
>> >>> mMemoryDiscoveredNotifyList for a PPI notification on
>> >>> the Memory Discovered PPI.  This same variable name is
>> >>> used in the DxeIplPeim for the same PPI notification.
>> >>>
>> >>> The XCODE5 tool chain detects this duplicate symbol
>> >>> when the OVMF platform is built with the flag
>> >>> -D SOURCE_DEBUG_ENABLE.
>> >>>
>> >>> The fix is to rename this global variable in the
>> >>> SecPeiDebugAgentLib library.
>> >>>
>> >>
>> >> No, the fix is to make it STATIC unless it *needs* to be a global.
>> >> Is that the case here?
>> >
>> > I agree with you (of course), but Mike explained earlier (if I recall
>> > correctly -- and perhaps you remember too) that giving internal linkage
>> > to global variables (i.e., making them STATIC) messes either with
>> > debuggability under VS, or else defeats "GLOBAL_REMOVE_IF_UNREFERENCED".
>> > (I'm not sure which one of the two.)
>> >
>>
>> That doesn't quite ring a bell, but if that is the case, it deserves a 
>> mention.
>>
>> Note that STATIC variables are also removed when unreferenced (but may
>> require a warning override like we have for GCC if it is only used
>> from DEBUG () code). In any case, polluting the global namespace in a
>> heterogeneous project like EDK2 is something that should only be done
>> with good reason IMO.
>>
>> > So, I've settled on considering "extern by default" just another
>> > peculiarity of edk2. *shrug* I'm just glad -fno-common catches bugs like
>> > this!
>> >
>>
>> Well, the thing is, external linkage defeats optimizations in the
>> compiler, and also prevents it from emitting the variable into a
>> read-only section even if it would otherwise be able to infer from the
>> usage that the variable is never modified.
>>
>> > Reviewed-by: Laszlo Ersek 
>> >
>> > (Obviously I'm not trying to dismiss your objection at all! Just stating
>> > my view. If the patch is changed to STATIC, I'll R-b that version *more
>> > happily* than this one.)
>> >
>> > Thanks!
>> > Laszlo
>> >
>> >>
>> >>
>> >>> Cc: Andrew Fish 
>> >>> Cc: Jeff Fan 
>> >>> Cc: Hao Wu 
>> >>> Cc: Laszlo Ersek 
>> >>> Contributed-under: TianoCore Contribution Agreement 1.0
>> >>> Signed-off-by: Michael D Kinney 
>> >>> Reviewed-by: Jeff Fan 
>> >>> ---
>> >>>  .../Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c | 
>> >>> 4 ++--
>> >>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> >>>
>> >>> diff --git 
>> >>> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>> >>> index b717e33..9f5223a 100644
>> >>> --- 
>> >>> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>> >>> +++ 
>> >>> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>> >>> @@ -32,7 +32,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_PPI_DESCRIPTOR   
>> >>> mVectorHandoffInf
>> >>>}
>> >>>  };
>> >>>
>> >>> -GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR 
>> >>> mMemoryDiscoveredNotifyList[1] = {
>> >>> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR 
>> >>> mDebugAgentMemoryDiscoveredNotifyList[1] = {
>> >>>{
>> >>>  (EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK | 

Re: [edk2] [Patch] SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix duplicate symbol

[Gao, Liming]

Ard and Ersek:
  On VS, static may make debug become hard. And, STATIC + 
GLOBAL_REMOVE_IF_UNREFERENCED may failure on old VS before VS supports /Gw 
option. So, I don't add static here. 
  I would like to separate static usage topic. We could discuss more and 
summary the rule on how to use static in code. But for this build failure 
issue, I prefer to fix it with this solution first. Is it OK to you?

Thanks
Liming
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Thursday, December 7, 2017 7:41 PM
> To: Laszlo Ersek 
> Cc: Gao, Liming ; edk2-devel@lists.01.org; Kinney, 
> Michael D ; Wu, Hao A
> ; Andrew Fish ; Jeff Fan 
> 
> Subject: Re: [edk2] [Patch] SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix 
> duplicate symbol
> 
> On 7 December 2017 at 11:18, Laszlo Ersek  wrote:
> > On 12/07/17 09:46, Ard Biesheuvel wrote:
> >> On 7 December 2017 at 07:48, Liming Gao  wrote:
> >>> From: Michael Kinney 
> >>>
> >>> https://bugzilla.tianocore.org/show_bug.cgi?id=573
> >>> https://bugzilla.tianocore.org/show_bug.cgi?id=796
> >>>
> >>> The same issue is reported again by GCC. Resend this patch again.
> >>> This patch renames the duplicated function name to fix it.
> >>>
> >>> The SecPeiDebugAgentLib uses the global variable
> >>> mMemoryDiscoveredNotifyList for a PPI notification on
> >>> the Memory Discovered PPI.  This same variable name is
> >>> used in the DxeIplPeim for the same PPI notification.
> >>>
> >>> The XCODE5 tool chain detects this duplicate symbol
> >>> when the OVMF platform is built with the flag
> >>> -D SOURCE_DEBUG_ENABLE.
> >>>
> >>> The fix is to rename this global variable in the
> >>> SecPeiDebugAgentLib library.
> >>>
> >>
> >> No, the fix is to make it STATIC unless it *needs* to be a global.
> >> Is that the case here?
> >
> > I agree with you (of course), but Mike explained earlier (if I recall
> > correctly -- and perhaps you remember too) that giving internal linkage
> > to global variables (i.e., making them STATIC) messes either with
> > debuggability under VS, or else defeats "GLOBAL_REMOVE_IF_UNREFERENCED".
> > (I'm not sure which one of the two.)
> >
> 
> That doesn't quite ring a bell, but if that is the case, it deserves a 
> mention.
> 
> Note that STATIC variables are also removed when unreferenced (but may
> require a warning override like we have for GCC if it is only used
> from DEBUG () code). In any case, polluting the global namespace in a
> heterogeneous project like EDK2 is something that should only be done
> with good reason IMO.
> 
> > So, I've settled on considering "extern by default" just another
> > peculiarity of edk2. *shrug* I'm just glad -fno-common catches bugs like
> > this!
> >
> 
> Well, the thing is, external linkage defeats optimizations in the
> compiler, and also prevents it from emitting the variable into a
> read-only section even if it would otherwise be able to infer from the
> usage that the variable is never modified.
> 
> > Reviewed-by: Laszlo Ersek 
> >
> > (Obviously I'm not trying to dismiss your objection at all! Just stating
> > my view. If the patch is changed to STATIC, I'll R-b that version *more
> > happily* than this one.)
> >
> > Thanks!
> > Laszlo
> >
> >>
> >>
> >>> Cc: Andrew Fish 
> >>> Cc: Jeff Fan 
> >>> Cc: Hao Wu 
> >>> Cc: Laszlo Ersek 
> >>> Contributed-under: TianoCore Contribution Agreement 1.0
> >>> Signed-off-by: Michael D Kinney 
> >>> Reviewed-by: Jeff Fan 
> >>> ---
> >>>  .../Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c | 
> >>> 4 ++--
> >>>  1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git 
> >>> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
> >>> index b717e33..9f5223a 100644
> >>> --- 
> >>> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
> >>> +++ 
> >>> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
> >>> @@ -32,7 +32,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_PPI_DESCRIPTOR
> >>>mVectorHandoffInf
> >>>}
> >>>  };
> >>>
> >>> -GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR 
> >>> mMemoryDiscoveredNotifyList[1] = {
> >>> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR 
> >>> mDebugAgentMemoryDiscoveredNotifyList[1] = {
> >>>{
> >>>  (EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK | 
> >>> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
> >>>  ,
> >>> @@ -554,7 +554,7 @@ InitializeDebugAgent (
> >>>  // Register for a callback once memory has been initialized.
> >>>  // If 

Re: [edk2] [PATCH v2 0/3] Adding secure boot and HTTP image download features for Linux based platform

[Ard Biesheuvel]

On 7 December 2017 at 13:34, kalyan-nagabhirava
 wrote:
> Linaro and RDK are  working on standardizing the boot process for RDK  STB 
> boxes using Uefi.
> Added applications are reference implementation of RDK STB boot process on 
> Arm platforms
>

Please don't add this to EmbeddedPkg. I thought we agreed to put this
in edk2-platforms/Platform/Comcast?

> kalyan-nagabhirava (3):
>   [edk2 EmbeddedPkg]:Implementation of secure boot and HTTP Image
> download
>   EmbeddedPkg: secureboot application using RdkBootManagerLib
>   EmbeddedPkg: Httpimage downlaod application
>
>  EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.dec   |  52 ++
>  EmbeddedPkg/Application/Dri/Dri.inf   |  56 ++
>  EmbeddedPkg/Application/SecureBoot/SecureBoot.inf |  57 ++
>  EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.inf   |  81 +++
>  EmbeddedPkg/Library/RdkBootManagerLib/Include/DiskIo.h|  20 +
>  EmbeddedPkg/Library/RdkBootManagerLib/Include/HttpBoot.h  |   7 +
>  EmbeddedPkg/Library/RdkBootManagerLib/Include/List.h  |  52 ++
>  EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkBootManagerLib.h |  31 ++
>  EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkFile.h   |  20 +
>  EmbeddedPkg/Library/RdkBootManagerLib/Include/SecureBoot.h|  40 ++
>  EmbeddedPkg/Application/Dri/Dri.c |  26 +
>  EmbeddedPkg/Application/SecureBoot/SecureBoot.c   |  30 +
>  EmbeddedPkg/Library/RdkBootManagerLib/DiskIo.c| 536 
> ++
>  EmbeddedPkg/Library/RdkBootManagerLib/HttpBoot.c  | 315 
> +++
>  EmbeddedPkg/Library/RdkBootManagerLib/RdkFile.c   | 259 
> +
>  EmbeddedPkg/Library/RdkBootManagerLib/SecureBoot.c| 577 
> 
>  16 files changed, 2159 insertions(+)
>  create mode 100644 
> EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.dec
>  create mode 100644 EmbeddedPkg/Application/Dri/Dri.inf
>  create mode 100644 EmbeddedPkg/Application/SecureBoot/SecureBoot.inf
>  create mode 100644 
> EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.inf
>  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/DiskIo.h
>  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/HttpBoot.h
>  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/List.h
>  create mode 100644 
> EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkBootManagerLib.h
>  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkFile.h
>  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/SecureBoot.h
>  create mode 100644 EmbeddedPkg/Application/Dri/Dri.c
>  create mode 100644 EmbeddedPkg/Application/SecureBoot/SecureBoot.c
>  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/DiskIo.c
>  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/HttpBoot.c
>  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/RdkFile.c
>  create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/SecureBoot.c
>
> --
> 2.15.0
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH edk2-platforms v2] Silicon/SynQuacer: enable coherent DMA for NETSEC and eMMC

[Ard Biesheuvel]

On 1 December 2017 at 17:53, Ard Biesheuvel  wrote:
> On 1 December 2017 at 12:57, Leif Lindholm  wrote:
>> On Thu, Nov 30, 2017 at 06:53:55PM +, Ard Biesheuvel wrote:
>>> As it turns out, it is surprisingly easy to configure both the NETSEC
>>> and eMMC devices as cache coherent for DMA, given that they are both
>>> behind the same SMMU which is already configured in passthrough mode
>>> by the firmware running on the SCP.
>>>
>>> So update the static SMMU configuration to make memory accesses performed
>>> by these devices inner shareable inner/outer writeback cacheable, which
>>> makes them cache coherent with the CPUs.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.1
>>> Signed-off-by: Ard Biesheuvel 
>>
>> Looks fine to me:
>> Reviewed-by: Leif Lindholm 
>> (If you want to hold back for Tested-by:s, feel free to.)
>>
>
> Thanks. It actually depends on the patch that adds the EMMC driver
> stack, which depends on the SD/MMC override patches for EDK2, so it
> needs to wait anyway.

Pushed as ce95ec196da05885844afb79bd2570c5cd9f6b27. I have reordered
this with the EMMC driver patch, which will simply be DMA coherent
from the start (but I kept the DT bit so the EMMC reference in the
commit log is still relevant)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v2 2/3] EmbeddedPkg: secureboot application using RdkBootManagerLib

[kalyan-nagabhirava]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: kalyan-nagabhirava 
---
 EmbeddedPkg/Application/SecureBoot/SecureBoot.inf | 57 
 EmbeddedPkg/Application/SecureBoot/SecureBoot.c   | 30 +++
 2 files changed, 87 insertions(+)

diff --git a/EmbeddedPkg/Application/SecureBoot/SecureBoot.inf 
b/EmbeddedPkg/Application/SecureBoot/SecureBoot.inf
new file mode 100644
index ..90d1ee677f6a
--- /dev/null
+++ b/EmbeddedPkg/Application/SecureBoot/SecureBoot.inf
@@ -0,0 +1,57 @@
+#
+#  Copyright (c) 2016-2017, Linaro Limited. All rights reserved.
+#  Copyright (c) 2016-2017, comcast . All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution.  The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+
+[Defines]
+  INF_VERSION = 0x00010006
+  BASE_NAME   = RdkSecureLoader
+  FILE_GUID   = b2c7930f-07ef-4305-ac4e-1ce2085a7031
+  MODULE_TYPE = UEFI_APPLICATION
+  VERSION_STRING  = 1.0
+  ENTRY_POINT = SecureBootEntryPoint
+
+[Sources]
+  SecureBoot.c
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  ArmPlatformPkg/ArmPlatformPkg.dec
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  ShellPkg/ShellPkg.dec
+  SecurityPkg/SecurityPkg.dec
+  CryptoPkg/CryptoPkg.dec
+  NetworkPkg/NetworkPkg.dec
+  EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.dec
+
+[Guids]
+  gEfiCertX509Guid
+  gEfiCertPkcs7Guid
+  gEfiCustomModeEnableGuid
+  gEfiImageSecurityDatabaseGuid
+  gFdtTableGuid
+  gRdkGlobalVariableGuid
+
+[LibraryClasses]
+  RdkBootManagerLib
+  UefiApplicationEntryPoint
+
+[Protocols]
+  gEfiBlockIoProtocolGuid
+  gEfiDevicePathToTextProtocolGuid
diff --git a/EmbeddedPkg/Application/SecureBoot/SecureBoot.c 
b/EmbeddedPkg/Application/SecureBoot/SecureBoot.c
new file mode 100644
index ..51ac75835fd0
--- /dev/null
+++ b/EmbeddedPkg/Application/SecureBoot/SecureBoot.c
@@ -0,0 +1,30 @@
+/*
+#  Copyright (c) 2016-2017, Linaro Limited. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution.  The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+ */
+#include 
+
+EFI_STATUS
+EFIAPI
+SecureBootEntryPoint (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  EFI_STATUS Status;
+
+  Status = RdkSecureBoot (
+ImageHandle,
+SystemTable->BootServices
+  );
+
+  return Status;
+}
-- 
2.15.0

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

[edk2] [PATCH v2 3/3] EmbeddedPkg: Httpimage downlaod application

[kalyan-nagabhirava]

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: kalyan-nagabhirava 
---
 EmbeddedPkg/Application/Dri/Dri.inf | 56 
 EmbeddedPkg/Application/Dri/Dri.c   | 26 +
 2 files changed, 82 insertions(+)

diff --git a/EmbeddedPkg/Application/Dri/Dri.inf 
b/EmbeddedPkg/Application/Dri/Dri.inf
new file mode 100644
index ..d6f24b48a6b3
--- /dev/null
+++ b/EmbeddedPkg/Application/Dri/Dri.inf
@@ -0,0 +1,56 @@
+#
+#  Copyright (c) 2016-2017, Linaro Limited. All rights reserved.
+#  Copyright (c) 2016-2017, comcast . All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution.  The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+
+
+#
+# Defines Section - statements that will be processed to create a Makefile.
+#
+
+
+[Defines]
+  INF_VERSION = 0x00010006
+  BASE_NAME   = RdkDriLoader
+  FILE_GUID   = 081ba18a-d71e-40a7-99a9-cdb86463966d
+  MODULE_TYPE = UEFI_APPLICATION
+  VERSION_STRING  = 1.0
+  ENTRY_POINT = DriEntryPoint
+
+[Sources]
+  Dri.c
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  ArmPlatformPkg/ArmPlatformPkg.dec
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdePkg/MdePkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  ShellPkg/ShellPkg.dec
+  SecurityPkg/SecurityPkg.dec
+  CryptoPkg/CryptoPkg.dec
+  NetworkPkg/NetworkPkg.dec
+  EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.dec
+
+[Guids]
+  gEfiCertX509Guid
+  gEfiCertPkcs7Guid
+  gEfiCustomModeEnableGuid
+  gEfiImageSecurityDatabaseGuid
+  gFdtTableGuid
+
+[LibraryClasses]
+  RdkBootManagerLib
+  UefiApplicationEntryPoint
+
+[Protocols]
+  gEfiBlockIoProtocolGuid
+  gEfiDevicePathToTextProtocolGuid
diff --git a/EmbeddedPkg/Application/Dri/Dri.c 
b/EmbeddedPkg/Application/Dri/Dri.c
new file mode 100644
index ..affbac08b602
--- /dev/null
+++ b/EmbeddedPkg/Application/Dri/Dri.c
@@ -0,0 +1,26 @@
+/*
+#  Copyright (c) 2016-2017, Linaro Limited. All rights reserved.
+#
+#  This program and the accompanying materials
+#  are licensed and made available under the terms and conditions of the BSD 
License
+#  which accompanies this distribution.  The full text of the license may be 
found at
+#  http://opensource.org/licenses/bsd-license.php
+#
+#  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+#  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+#
+ */
+#include 
+
+EFI_STATUS
+EFIAPI
+DriEntryPoint (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  EFI_STATUS Status;
+
+  Status = RdkHttpBoot ();
+  return Status;
+}
-- 
2.15.0

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

[edk2] [PATCH v2 0/3] Adding secure boot and HTTP image download features for Linux based platform

[kalyan-nagabhirava]

Linaro and RDK are  working on standardizing the boot process for RDK  STB 
boxes using Uefi.
Added applications are reference implementation of RDK STB boot process on Arm 
platforms

kalyan-nagabhirava (3):
  [edk2 EmbeddedPkg]:Implementation of secure boot and HTTP Image
download
  EmbeddedPkg: secureboot application using RdkBootManagerLib
  EmbeddedPkg: Httpimage downlaod application

 EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.dec   |  52 ++
 EmbeddedPkg/Application/Dri/Dri.inf   |  56 ++
 EmbeddedPkg/Application/SecureBoot/SecureBoot.inf |  57 ++
 EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.inf   |  81 +++
 EmbeddedPkg/Library/RdkBootManagerLib/Include/DiskIo.h|  20 +
 EmbeddedPkg/Library/RdkBootManagerLib/Include/HttpBoot.h  |   7 +
 EmbeddedPkg/Library/RdkBootManagerLib/Include/List.h  |  52 ++
 EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkBootManagerLib.h |  31 ++
 EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkFile.h   |  20 +
 EmbeddedPkg/Library/RdkBootManagerLib/Include/SecureBoot.h|  40 ++
 EmbeddedPkg/Application/Dri/Dri.c |  26 +
 EmbeddedPkg/Application/SecureBoot/SecureBoot.c   |  30 +
 EmbeddedPkg/Library/RdkBootManagerLib/DiskIo.c| 536 
++
 EmbeddedPkg/Library/RdkBootManagerLib/HttpBoot.c  | 315 
+++
 EmbeddedPkg/Library/RdkBootManagerLib/RdkFile.c   | 259 
+
 EmbeddedPkg/Library/RdkBootManagerLib/SecureBoot.c| 577 

 16 files changed, 2159 insertions(+)
 create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.dec
 create mode 100644 EmbeddedPkg/Application/Dri/Dri.inf
 create mode 100644 EmbeddedPkg/Application/SecureBoot/SecureBoot.inf
 create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/RdkBootManagerLib.inf
 create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/DiskIo.h
 create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/HttpBoot.h
 create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/List.h
 create mode 100644 
EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkBootManagerLib.h
 create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/RdkFile.h
 create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/Include/SecureBoot.h
 create mode 100644 EmbeddedPkg/Application/Dri/Dri.c
 create mode 100644 EmbeddedPkg/Application/SecureBoot/SecureBoot.c
 create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/DiskIo.c
 create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/HttpBoot.c
 create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/RdkFile.c
 create mode 100644 EmbeddedPkg/Library/RdkBootManagerLib/SecureBoot.c

-- 
2.15.0

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

Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file

[Zhu, Yonghong]

Hi Leif,

May I know how this binary driver is described in DSC file and FDF file, and 
the [Rule.Common.DXE_DRIVER.BINARY] section ?
I tried to add this driver into OvmfPkg, but failed to reproduce this failure. 
Thanks.

Best Regards,
Zhu Yonghong


-Original Message-
From: Leif Lindholm [mailto:leif.lindh...@linaro.org] 
Sent: Thursday, December 07, 2017 7:30 PM
To: Zhu, Yonghong 
Cc: edk2-devel@lists.01.org; Feng, YunhuaX ; Gao, 
Liming 
Subject: Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file

Hi Yonghong,

This patch resolves the issue for the hikey platform, but not for 
(edk2-platforms/Platform/Hisilicon/)D03/D05. They fail with

---
Generating FVMAIN FV
##

#Return Value = 2
GenSec: ERROR 0001: Error opening file

  
/work/git/tianocore/Build/D03/DEBUG_GCC5/AARCH64/Platform/Hisilicon/D03/Drivers/Net/SnpPlatform/SnpPlatform/OUTPUT/SnpPlatform.depex
GenSec: ERROR 2000: Status is not successful
---

and

---
Generating FVMAIN FV
##


Return Value = 2
GenSec: ERROR 0001: Error opening file


  
/work/git/tianocore/Build/D05/RELEASE_GCC5/AARCH64/Platform/Hisilicon/D05/Drivers/Net/SnpPlatform/SnpPlatform/OUTPUT/SnpPlatform.depex
GenFds.py...
 : error 7000: Failed to generate section
GenSec: ERROR 2000: Status is not successful
---

respectively.

Again, reverting 37de70b7 makes the build successful again.

Note that the failing drivers are binary, held in edk2-non-osi.

Regards,

Leif

On Thu, Dec 07, 2017 at 02:51:17PM +0800, Yonghong Zhu wrote:
> From: Yunhua Feng 
> 
> Filter the FileList when multiple genfds thread options is not enabled.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Yunhua Feng 
> ---
>  BaseTools/Source/Python/GenFds/EfiSection.py | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/BaseTools/Source/Python/GenFds/EfiSection.py 
> b/BaseTools/Source/Python/GenFds/EfiSection.py
> index 7b3b717191..4276945a10 100644
> --- a/BaseTools/Source/Python/GenFds/EfiSection.py
> +++ b/BaseTools/Source/Python/GenFds/EfiSection.py
> @@ -92,7 +92,8 @@ class EfiSection (EfiSectionClassObject):
>  elif os.path.exists(Filename):
>  FileList.append(Filename)
>  elif '.depex' in FfsInf.FinalTargetSuffixMap or FfsInf.Depex:
> -FileList.append(Filename)
> +if IsMakefile:
> +FileList.append(Filename)
>  else:
>  FileList, IsSect = Section.Section.GetFileList(FfsInf, 
> self.FileType, self.FileExtension, Dict)
>  if IsSect :
> --
> 2.12.2.windows.2
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] MdeModulePkg/Ip4Dxe: fix ICMP echo reply memory leak

[Heyi Guo]

Hi Siyuan and Jiaxin,

Thanks for your review; shall I generate a formal patch and post it 
again, as well as making some commit message refinement?


Regards,


Gary (Heyi Guo)


在 12/7/2017 3:01 PM, Wu, Jiaxin 写道:

It's is good to me.

Reviewed-by: Jiaxin Wu 

Thanks,
Jiaxin



-Original Message-
From: Heyi Guo [mailto:heyi@linaro.org]
Sent: Thursday, December 7, 2017 10:22 AM
To: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org
Cc: Heyi Guo ; Junbiao Hong
; Zeng, Star ; Dong, Eric
; Ni, Ruiyu ; Fu, Siyuan
; Wu, Jiaxin 
Subject: [RFC] MdeModulePkg/Ip4Dxe: fix ICMP echo reply memory leak

When UEFI receives IPMP echo packets it will enter Ip4IcmpReplyEcho
function, and then call Ip4Output. However, if Ip4Output gets some
error and exits early, e.g. fails to find the route entry, memory
buffer of "Data" gets no chance to be freed and memory leak will be
caused. If there is such an attacker in the network, we will see UEFI
runs out of memory and system hangs.

Network stack code is so complicated that this is just a RFC to fix
this issue. Please provide your comments about this.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Junbiao Hong 
Signed-off-by: Heyi Guo 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Ruiyu Ni 
Cc: Siyuan Fu 
Cc: Jiaxin Wu 
---
  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
index b4b0864..ed6bdbe 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Icmp.c
@@ -267,6 +267,9 @@ Ip4IcmpReplyEcho (
   Ip4SysPacketSent,
   NULL
   );
+  if (EFI_ERROR (Status)) {
+NetbufFree (Data);
+  }

  ON_EXIT:
NetbufFree (Packet);
--
2.7.4


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

Re: [edk2] MdeModulePkg/UefiPxeBcDxe: Question about IcmpErrorListenHandler in PxeBcImpl.c

[Heyi Guo]

在 12/7/2017 6:40 PM, Wu, Jiaxin 写道:

You say "IcmpErrorRcvToken is only used to get ICMP error from IP
layer", does that mean only ICMP error packets will go to
IcmpErrorListenHandler?
If it is the case, how do we make it? I can only find a simple
Ip4->Receive is called to receive IP4 packets; how are other types of
IP4 packets filtered out?

No, all of the *ICMP* packets with the same station IP address will go to 
IcmpErrorListenHandler() callback function. Because PXE driver has already 
configured the current IP protocol only receive the ICMP packets:
ZeroMem (>Ip4ConfigData, sizeof (EFI_IP4_CONFIG_DATA));
Private->Ip4ConfigData.DefaultProtocol   = EFI_IP_PROTO_ICMP;
Private->Ip4ConfigData.AcceptIcmpErrors  = TRUE;
Ip4ConfigData.DefaultProtocol   = EFI_IP_PROTO_ICMP;
So, it is only used to capture background ICMP packets (Including the ICMP 
error message) with the same station IP address.

Many thanks; it explains my question clearly.




If it is not, why don't we need to filter the packets in
IcmpErrorListenHandler? If we recycle the packets in
IcmpErrorListenHandler, will it cause the upper layer of protocols fail
to fetch RxData?

IcmpErrorListenHandler() should filter the packets and only handle the ICMP 
error message. But currently, the code logic is incorrect. I generated one 
patch as attached one for your reference, can you help to verify whether it 
works or not? (Ignore my previous suggestion check).

Sure we can verify it.

In my opinion, the RxData should be recycled since it has been recorded in 
Mode->IcmpError.

Agree.

Thanks,

Gary (Heyi Guo)


Thanks,
Jiaxin











-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Heyi Guo
Sent: Thursday, December 7, 2017 4:18 PM
To: Wu, Jiaxin ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Fu, Siyuan ; Dong,
Eric ; Zeng, Star 
Subject: Re: [edk2] MdeModulePkg/UefiPxeBcDxe: Question about
IcmpErrorListenHandler in PxeBcImpl.c

Hi Jiaxin,

Thanks for your reply.

You say "IcmpErrorRcvToken is only used to get ICMP error from IP
layer", does that mean only ICMP error packets will go to
IcmpErrorListenHandler?

If it is the case, how do we make it? I can only find a simple
Ip4->Receive is called to receive IP4 packets; how are other types of
IP4 packets filtered out?

If it is not, why don't we need to filter the packets in
IcmpErrorListenHandler? If we recycle the packets in
IcmpErrorListenHandler, will it cause the upper layer of protocols fail
to fetch RxData?

Please forgive me if my questions are too stupid :)

Regards,

Gary (Heyi Guo)


在 12/7/2017 3:48 PM, Wu, Jiaxin 写道:

Hi Gary,

IcmpErrorRcvToken is only used to get ICMP error from IP layer, and the

data will be copied to Mode->IcmpError. So, I think the RxData should be
recycled.

Besides, EFI_IP_PROTO_ICMP should be also checked in the call function

but currently it's not:

if (!EFI_IP4_EQUAL (>Header->DestinationAddress, 
StationIp.v4)) {
  //
  // The dest address is not equal to Station Ip address, discard it.
  //
  goto CleanUp;
}

+if (>Header->Protocol != EFI_IP_PROTO_ICMP) {
+//
+// The protocol value in the header of the receveid packet should be

EFI_IP_PROTO_ICMP.

+//
+goto CleanUp;
+}

Thanks the report.

Thanks,
Jiaxin




-Original Message-
From: Guo Heyi [mailto:heyi@linaro.org]
Sent: Thursday, December 7, 2017 12:07 PM
To: edk2-devel@lists.01.org
Cc: Zeng, Star ; Dong, Eric ;

Ni,

Ruiyu ; Fu, Siyuan ; Wu, Jiaxin

Subject: MdeModulePkg/UefiPxeBcDxe: Question about
IcmpErrorListenHandler in PxeBcImpl.c

Hi folks,

In PxeBcImpl.c, we have IcmpErrorListenHandler which seems to process
ICMP errors. But in EfiPxeBcStart function, we can see Private-

IcmpErrorRcvToken.Event is only a common event and Ip4->Receive is

called to receive IP4 packets. So will IcmpErrorListenHandler receive all IP4
packets belonging to this network interface, or will it only receive ICMP

error

packets? If it is the latter situation, how do we make it?

The background of this question is that when we flush the network with
deprecated ICMP packets (type 15, 16, ...), RxData will not be recycled and
the list of UEFI events becomes longer and longer, which finally impacts
system performance a lot. If only error ICMP will be received by
IcmpErrorListenHandler, we'd like to patch it as below:

diff --git

a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c

b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
index 6d4f33f..f74b264 100644
--- a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
+++ b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
@@ -216,8 +216,6 @@ IcmpErrorListenHandlerDpc (
   CopiedPointer += CopiedLen;

Re: [edk2] [Patch] SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix duplicate symbol

[Ard Biesheuvel]

On 7 December 2017 at 11:18, Laszlo Ersek  wrote:
> On 12/07/17 09:46, Ard Biesheuvel wrote:
>> On 7 December 2017 at 07:48, Liming Gao  wrote:
>>> From: Michael Kinney 
>>>
>>> https://bugzilla.tianocore.org/show_bug.cgi?id=573
>>> https://bugzilla.tianocore.org/show_bug.cgi?id=796
>>>
>>> The same issue is reported again by GCC. Resend this patch again.
>>> This patch renames the duplicated function name to fix it.
>>>
>>> The SecPeiDebugAgentLib uses the global variable
>>> mMemoryDiscoveredNotifyList for a PPI notification on
>>> the Memory Discovered PPI.  This same variable name is
>>> used in the DxeIplPeim for the same PPI notification.
>>>
>>> The XCODE5 tool chain detects this duplicate symbol
>>> when the OVMF platform is built with the flag
>>> -D SOURCE_DEBUG_ENABLE.
>>>
>>> The fix is to rename this global variable in the
>>> SecPeiDebugAgentLib library.
>>>
>>
>> No, the fix is to make it STATIC unless it *needs* to be a global.
>> Is that the case here?
>
> I agree with you (of course), but Mike explained earlier (if I recall
> correctly -- and perhaps you remember too) that giving internal linkage
> to global variables (i.e., making them STATIC) messes either with
> debuggability under VS, or else defeats "GLOBAL_REMOVE_IF_UNREFERENCED".
> (I'm not sure which one of the two.)
>

That doesn't quite ring a bell, but if that is the case, it deserves a mention.

Note that STATIC variables are also removed when unreferenced (but may
require a warning override like we have for GCC if it is only used
from DEBUG () code). In any case, polluting the global namespace in a
heterogeneous project like EDK2 is something that should only be done
with good reason IMO.

> So, I've settled on considering "extern by default" just another
> peculiarity of edk2. *shrug* I'm just glad -fno-common catches bugs like
> this!
>

Well, the thing is, external linkage defeats optimizations in the
compiler, and also prevents it from emitting the variable into a
read-only section even if it would otherwise be able to infer from the
usage that the variable is never modified.

> Reviewed-by: Laszlo Ersek 
>
> (Obviously I'm not trying to dismiss your objection at all! Just stating
> my view. If the patch is changed to STATIC, I'll R-b that version *more
> happily* than this one.)
>
> Thanks!
> Laszlo
>
>>
>>
>>> Cc: Andrew Fish 
>>> Cc: Jeff Fan 
>>> Cc: Hao Wu 
>>> Cc: Laszlo Ersek 
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Michael D Kinney 
>>> Reviewed-by: Jeff Fan 
>>> ---
>>>  .../Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c | 4 
>>> ++--
>>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git 
>>> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>>>  
>>> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>>> index b717e33..9f5223a 100644
>>> --- 
>>> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>>> +++ 
>>> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>>> @@ -32,7 +32,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_PPI_DESCRIPTOR  
>>>  mVectorHandoffInf
>>>}
>>>  };
>>>
>>> -GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR 
>>> mMemoryDiscoveredNotifyList[1] = {
>>> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR 
>>> mDebugAgentMemoryDiscoveredNotifyList[1] = {
>>>{
>>>  (EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK | 
>>> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
>>>  ,
>>> @@ -554,7 +554,7 @@ InitializeDebugAgent (
>>>  // Register for a callback once memory has been initialized.
>>>  // If memery has been ready, the callback funtion will be invoked 
>>> immediately
>>>  //
>>> -Status = PeiServicesNotifyPpi ([0]);
>>> +Status = PeiServicesNotifyPpi 
>>> ([0]);
>>>  if (EFI_ERROR (Status)) {
>>>DEBUG ((EFI_D_ERROR, "DebugAgent: Failed to register memory 
>>> discovered callback function!\n"));
>>>CpuDeadLoop ();
>>> --
>>> 2.6.3.windows.1
>>>
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>> GitPatchExtractor 1.1
>>> ___
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 3/3] BaseTool/tools_def GCC5: enable optimization for ARM/AARCH64 DEBUG builds

[Laszlo Ersek]

On 12/07/17 10:28, Ard Biesheuvel wrote:
> Enable optimization for DEBUG builds, to make it more usable in terms of
> performance, and to give more coverage to the LTO builds. Also, some
> diagnostics are only enabled when optimization is enabled.
> NOOPT builds can now also be created, which will retain the behavior DEBUG
> builds had previously.
> 
> Note that this aligns ARM and AARCH64 with the x86 architectures, which
> already use optimization for DEBUG builds.
> 
> In order to preserve existing behavior for users of older toolchains,
> keep GCC49 and older as-is.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
> v2: new patch
> 
>  BaseTools/Conf/tools_def.template | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index 703884fc49a7..aec390f8eeb1 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -5517,8 +5517,8 @@ RELEASE_GCC5_X64_DLINK_FLAGS = 
> DEF(GCC5_X64_DLINK_FLAGS) -flto -Os
>  *_GCC5_ARM_VFRPP_FLAGS   = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
> DEF(GCC_VFRPP_FLAGS)
>  *_GCC5_ARM_CC_XIPFLAGS   = DEF(GCC5_ARM_CC_XIPFLAGS)
>  
> -  DEBUG_GCC5_ARM_CC_FLAGS= DEF(GCC5_ARM_CC_FLAGS) -O0
> -  DEBUG_GCC5_ARM_DLINK_FLAGS = DEF(GCC5_ARM_DLINK_FLAGS)
> +  DEBUG_GCC5_ARM_CC_FLAGS= DEF(GCC5_ARM_CC_FLAGS) -flto 
> -Wno-unused-but-set-variable -Wno-unused-const-variable
> +  DEBUG_GCC5_ARM_DLINK_FLAGS = DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os 
> -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-arm 
> -Wl,-plugin-opt=-pass-through=-llto-arm
>  
>  RELEASE_GCC5_ARM_CC_FLAGS= DEF(GCC5_ARM_CC_FLAGS) -flto 
> -Wno-unused-but-set-variable -Wno-unused-const-variable
>  RELEASE_GCC5_ARM_DLINK_FLAGS = DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os 
> -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-arm 
> -Wl,-plugin-opt=-pass-through=-llto-arm
> @@ -5551,8 +5551,8 @@ RELEASE_GCC5_ARM_DLINK_FLAGS = 
> DEF(GCC5_ARM_DLINK_FLAGS) -flto -Os -L$(WORKS
>  *_GCC5_AARCH64_VFRPP_FLAGS   = $(ARCHCC_FLAGS) $(PLATFORM_FLAGS) 
> DEF(GCC_VFRPP_FLAGS)
>  *_GCC5_AARCH64_CC_XIPFLAGS   = DEF(GCC5_AARCH64_CC_XIPFLAGS)
>  
> -  DEBUG_GCC5_AARCH64_CC_FLAGS= DEF(GCC5_AARCH64_CC_FLAGS) -O0 
> -mcmodel=small
> -  DEBUG_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -z 
> common-page-size=0x1000
> +  DEBUG_GCC5_AARCH64_CC_FLAGS= DEF(GCC5_AARCH64_CC_FLAGS) -flto 
> -Wno-unused-but-set-variable -Wno-unused-const-variable -mcmodel=small
> +  DEBUG_GCC5_AARCH64_DLINK_FLAGS = DEF(GCC5_AARCH64_DLINK_FLAGS) -z 
> common-page-size=0x1000 -flto -Os -L$(WORKSPACE)/ArmPkg/Library/GccLto 
> -llto-aarch64 -Wl,-plugin-opt=-pass-through=-llto-aarch64 
> -Wno-lto-type-mismatch -mcmodel=small
>DEBUG_GCC5_AARCH64_DLINK_XIPFLAGS = -z common-page-size=0x20
>  
>  RELEASE_GCC5_AARCH64_CC_FLAGS= DEF(GCC5_AARCH64_CC_FLAGS) -flto 
> -Wno-unused-but-set-variable -Wno-unused-const-variable -mcmodel=tiny
> 

If it compiles, ship it. :)

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

Re: [edk2] [PATCH] MdePkg: Arm/AArch64 - filter #pragma pack() when __ASSEMBLER__

[Leif Lindholm]

On Thu, Dec 07, 2017 at 03:09:17AM +, Gao, Liming wrote:
> Reviewed-by: Liming Gao 

Thanks!

Pushed as 5b8766bb92.

> >-Original Message-
> >From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> >Sent: Thursday, December 07, 2017 1:08 AM
> >To: edk2-devel@lists.01.org
> >Cc: Kinney, Michael D ; Gao, Liming
> >; ard.biesheu...@linaro.org
> >Subject: [PATCH] MdePkg: Arm/AArch64 - filter #pragma pack() when
> >__ASSEMBLER__
> >
> >clang, when used as a preprocessor for dtc, does not discard #pragma
> >statements although -x assembler-with-cpp is specified. This causes dtc
> >to barf at a #pragma pack() statement that is already filtered out for
> >__GNUC__. So add a check to also filter this out if __ASSEMBLER__.
> >
> >Contributed-under: TianoCore Contribution Agreement 1.1
> >Signed-off-by: Leif Lindholm 
> >---
> > MdePkg/Include/AArch64/ProcessorBind.h | 2 +-
> > MdePkg/Include/Arm/ProcessorBind.h | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> >diff --git a/MdePkg/Include/AArch64/ProcessorBind.h
> >b/MdePkg/Include/AArch64/ProcessorBind.h
> >index 775e7498c5..7b0f0ff32f 100644
> >--- a/MdePkg/Include/AArch64/ProcessorBind.h
> >+++ b/MdePkg/Include/AArch64/ProcessorBind.h
> >@@ -26,7 +26,7 @@
> > //
> > // Make sure we are using the correct packing rules per EFI specification
> > //
> >-#ifndef __GNUC__
> >+#if !defined(__GNUC__) && !defined(__ASSEMBLER__)
> > #pragma pack()
> > #endif
> >
> >diff --git a/MdePkg/Include/Arm/ProcessorBind.h
> >b/MdePkg/Include/Arm/ProcessorBind.h
> >index dde1fd1152..42ea2f3055 100644
> >--- a/MdePkg/Include/Arm/ProcessorBind.h
> >+++ b/MdePkg/Include/Arm/ProcessorBind.h
> >@@ -24,7 +24,7 @@
> > //
> > // Make sure we are using the correct packing rules per EFI specification
> > //
> >-#ifndef __GNUC__
> >+#if !defined(__GNUC__) && !defined(__ASSEMBLER__)
> > #pragma pack()
> > #endif
> >
> >--
> >2.11.0
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH v4 1/2] MdeModulePkg/DxeIpl: Mark page table as read-only

[Jian J Wang]

> v4:
> a. Fix a calculation error in pool page number during initialization
> b. Change comments to remove constants in description

> v3:
>Remove the public definition of PAGE_TABLE_POOL_HEADER but keep similar
>concept locally. CpuDxe has its own page table pool.

> v2:
>Introduce page table pool to ease the page table memory allocation and
>protection, which replaces the direct calling of AllocatePages().

This patch will set the memory pages used for page table as read-only
memory after the paging is setup. CR0.WP must set to let it take into
effect.

A simple page table memory management mechanism, page table pool concept,
is introduced to simplify the page table memory allocation and protection.
It will also help to reduce the potential recursive "split" action during
updating memory paging attributes.

The basic idea is to allocate a bunch of continuous pages of memory in
advance as one or more page table pools, and all future page tables
consumption will happen in those pool instead of system memory. If the page
pool is reserved at the boundary of 2MB page and with same size of 2MB page,
there's no page granularity "split" operation will be needed, because the
memory of new page tables (if needed) will be usually in the same page as
target page table you're working on.

And since we have centralized page tables (a few 2MB pages), it's easier
to protect them by changing their attributes to be read-only once and for
all. There's no need to apply the protection for new page tables any more
as long as the pool has free pages available.

Once current page table pool has been used up, one can allocate another 2MB
memory pool and just set this new 2MB memory block to be read-only instead of
setting the new page tables one page by one page.

Two new PCDs PcdPageTablePoolUnitSize and PcdPageTablePoolAlignment are used
to specify the size and alignment for page table pool. For IA32 processor
0x20 (2MB) is the only choice for both of them to meet the requirement of
page table pool.

Cc: Jiewen Yao 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang 
---
 MdeModulePkg/Core/DxeIplPeim/DxeIpl.h|  34 +++
 MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c  |   8 +-
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 299 ++-
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h |  26 ++
 4 files changed, 363 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h 
b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
index f3aabdb7e0..9dc80b1508 100644
--- a/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
+++ b/MdeModulePkg/Core/DxeIplPeim/DxeIpl.h
@@ -265,4 +265,38 @@ IsNullDetectionEnabled (
   VOID
   );
 
+/**
+  Prevent the memory pages used for page table from been overwritten.
+
+  @param[in] PageTableBaseBase address of page table (CR3).
+
+**/
+VOID
+EnablePageTableProtection (
+  IN  UINTN PageTableBase,
+  IN  BOOLEAN   Level4Paging
+  );
+
+/**
+  This API provides a way to allocate memory for page table.
+
+  This API can be called more than once to allocate memory for page tables.
+
+  Allocates the number of 4KB pages and returns a pointer to the allocated
+  buffer. The buffer returned is aligned on a 4KB boundary.
+
+  If Pages is 0, then NULL is returned.
+  If there is not enough memory remaining to satisfy the request, then NULL is
+  returned.
+
+  @param  Pages The number of 4 KB pages to allocate.
+
+  @return A pointer to the allocated buffer or NULL if allocation fails.
+
+**/
+VOID *
+AllocatePageTableMemory (
+  IN UINTN   Pages
+  );
+
 #endif
diff --git a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c 
b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
index 5649265367..13fff28e93 100644
--- a/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
+++ b/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c
@@ -99,7 +99,7 @@ Create4GPageTablesIa32Pae (
   NumberOfPdpEntriesNeeded = (UINT32) LShiftU64 (1, (PhysicalAddressBits - 
30));
 
   TotalPagesNum = NumberOfPdpEntriesNeeded + 1;
-  PageAddress = (UINTN) AllocatePages (TotalPagesNum);
+  PageAddress = (UINTN) AllocatePageTableMemory (TotalPagesNum);
   ASSERT (PageAddress != 0);
 
   PageMap = (VOID *) PageAddress;
@@ -149,6 +149,12 @@ Create4GPageTablesIa32Pae (
   );
   }
 
+  //
+  // Protect the page table by marking the memory used for page table to be
+  // read-only.
+  //
+  EnablePageTableProtection ((UINTN)PageMap, FALSE);
+
   return (UINTN) PageMap;
 }
 
diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c 
b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
index 29b6205e88..038aa0d127 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
@@ -31,6 +31,11 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF 

Re: [edk2] [PATCH] UefiCpuPkg PiSmmCpuDxeSmm: SMM profile and static paging mutual exclusion

[Laszlo Ersek]

Hi Star,

On 12/07/17 11:47, Star Zeng wrote:
> SMM profile and static paging could not enabled at the same time,
> this patch is add check and comments to make sure it.
> 
> Similar comments are also added for the case of static paging and
> heap guard for SMM.
> 
> Cc: Jiewen Yao 
> Cc: Eric Dong 
> Cc: Ruiyu Ni 
> Cc: Jian J Wang 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c |  9 +
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c  | 13 ++---
>  UefiCpuPkg/UefiCpuPkg.dec|  6 +-
>  UefiCpuPkg/UefiCpuPkg.uni| 10 --
>  4 files changed, 32 insertions(+), 6 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> index 6e1ffe7c6287..939ac25a506c 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> @@ -205,6 +205,15 @@ SetPageTableAttributes (
>//  BIT3: SMM pool guard enabled
>//
>if ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
> +DEBUG ((DEBUG_INFO, "Don't mark page table as read-only as heap guard is 
> enabled\n"));
> +return ;
> +  }
> +
> +  //
> +  // Don't mark page table as read-only if SMM profile is enabled.
> +  //
> +  if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
> +DEBUG ((DEBUG_INFO, "Don't mark page table as read-only as SMM profile 
> is enabled\n"));
>  return ;
>}
>  
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> index 6478c6c3e355..0fe944fc18cc 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> @@ -919,17 +919,24 @@ SetPageTableAttributes (
>//
>// Don't do this if
>//  - no static page table; or
> -  //  - SMM heap guard feature enabled
> +  //  - SMM heap guard feature enabled; or
>//  BIT2: SMM page guard enabled
>//  BIT3: SMM pool guard enabled
> +  //  - SMM profile feature enabled
>//
>if (!mCpuSmmStaticPageTable ||
> -  (PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
> +  ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) ||
> +  FeaturePcdGet (PcdCpuSmmProfileEnable)) {
>  //
> -// Static paging and heap guard should not be enabled at the same time.
> +// Static paging and heap guard could not be enabled at the same time.
>  //
>  ASSERT (!(mCpuSmmStaticPageTable &&
>(PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0));
> +
> +//
> +// Static paging and SMM profile could not be enabled at the same time.
> +//
> +ASSERT (!(mCpuSmmStaticPageTable && FeaturePcdGet 
> (PcdCpuSmmProfileEnable)));
>  return ;
>}
>  
> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
> index d2965ba14c2d..36205ab63796 100644
> --- a/UefiCpuPkg/UefiCpuPkg.dec
> +++ b/UefiCpuPkg/UefiCpuPkg.dec
> @@ -84,6 +84,7 @@ [Protocols]
>  [PcdsFeatureFlag]
>## Indicates if SMM Profile will be enabled.
>#  If enabled, instruction executions in and data accesses to memory 
> outside of SMRAM will be logged.
> +  #  It could not be enabled at the same time with SMM profile feature 
> (PcdCpuSmmStaticPageTable).
>#  This PCD is only for validation purpose. It should be set to false in 
> production.
>#   TRUE  - SMM Profile will be enabled.
>#   FALSE - SMM Profile will be disabled.
> @@ -225,8 +226,11 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, 
> PcdsDynamicEx]
>gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate|0|UINT8|0x0007
>  
>## Indicates if SMM uses static page table.
> -  #  If enabled, SMM will not use on-demand paging. SMM will build static 
> page table for all memory.
> +  #  If enabled, SMM will not use on-demand paging. SMM will build static 
> page table for all memory.
>#  This flag only impacts X64 build, because SMM alway builds static page 
> table for IA32.
> +  #  It could not be enabled at the same time with SMM profile feature 
> (PcdCpuSmmProfileEnable).
> +  #  It could not be enabled also at the same time with heap guard feature 
> for SMM
> +  #  (PcdHeapGuardPropertyMask in MdeModulePkg).
>#   TRUE  - SMM uses static page table for all memory.
>#   FALSE - SMM uses static page table for below 4G memory and use 
> on-demand paging for above 4G memory.
># @Prompt Use static page table for all memory in SMM.
> diff --git a/UefiCpuPkg/UefiCpuPkg.uni b/UefiCpuPkg/UefiCpuPkg.uni
> index 9472b185e46e..013d2870a682 100644
> --- a/UefiCpuPkg/UefiCpuPkg.uni
> +++ b/UefiCpuPkg/UefiCpuPkg.uni
> @@ -53,7 +53,10 @@
>  
>  #string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuSmmProfileEnable_PROMPT  
> #language en-US "Enable SMM Profile"
>  
> 

[edk2] [PATCH v4 0/2] Enable page table write protection

[Jian J Wang]

> v4 changes:
>MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 22 ++---
> MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h |  2 +-
> UefiCpuPkg/CpuDxe/CpuPageTable.c | 25 +++-
> UefiCpuPkg/CpuDxe/CpuPageTable.h |  2 +-
> 4 files changed, 23 insertions(+), 28 deletions(-)
>
>diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c 
>b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>index 4ef3521224..038aa0d127 100644
>--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
>@@ -126,12 +126,13 @@ EnableExecuteDisableBit (
>   Initialize a buffer pool for page table use only.
> 
>   To reduce the potential split operation on page table, the pages reserved 
> for
>-  page table should be allocated in the times of 512 (= SIZE_2MB) and at the
>-  boundary of SIZE_2MB. So the page pool is always initialized with number of
>-  pages greater than or equal to the given PoolPages.
>+  page table should be allocated in the times of PAGE_TABLE_POOL_UNIT_PAGES 
>and
>+  at the boundary of PAGE_TABLE_POOL_ALIGNMENT. So the page pool is always
>+  initialized with number of pages greater than or equal to the given 
>PoolPages.
> 
>   Once the pages in the pool are used up, this method should be called again 
> to
>-  reserve at least another 512 pages. But usually this won't happen in 
>practice.
>+  reserve at least another PAGE_TABLE_POOL_UNIT_PAGES. But usually this won't
>+  happen in practice.
> 
>   @param PoolPages  The least page number of the pool to be created.
> 
>@@ -146,15 +147,12 @@ InitializePageTablePool (
>   VOID  *Buffer;
> 
>   //
>-  // Always reserve at least PAGE_TABLE_POOL_UNIT_PAGES (512).
>+  // Always reserve at least PAGE_TABLE_POOL_UNIT_PAGES, including one page 
>for
>+  // header.
>   //
>-  if (PoolPages <= PAGE_TABLE_POOL_UNIT_PAGES) {
>-PoolPages = PAGE_TABLE_POOL_UNIT_PAGES;
>-  } else {
>-PoolPages = ((PoolPages + PAGE_TABLE_POOL_UNIT_PAGES) %
>- PAGE_TABLE_POOL_UNIT_PAGES) * PAGE_TABLE_POOL_UNIT_PAGES;
>-  }
>-
>+  PoolPages += 1;   // Add one page for header.
>+  PoolPages = ((PoolPages - 1) / PAGE_TABLE_POOL_UNIT_PAGES + 1) *
>+  PAGE_TABLE_POOL_UNIT_PAGES;
>   Buffer = AllocateAlignedPages (PoolPages, PAGE_TABLE_POOL_ALIGNMENT);
>   if (Buffer == NULL) {
> DEBUG ((DEBUG_ERROR, "ERROR: Out of aligned pages\r\n"));
>diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h 
>b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
>index 9f14ac6007..b8cf43104e 100644
>--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
>+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.h
>@@ -169,7 +169,7 @@ typedef union {
> 
> #define PAGE_TABLE_POOL_ALIGNMENT   BASE_2MB
> #define PAGE_TABLE_POOL_UNIT_SIZE   SIZE_2MB
>-#define PAGE_TABLE_POOL_UNIT_PAGES  EFI_SIZE_TO_PAGES (SIZE_2MB)
>+#define PAGE_TABLE_POOL_UNIT_PAGES  EFI_SIZE_TO_PAGES 
>(PAGE_TABLE_POOL_UNIT_SIZE)
> #define PAGE_TABLE_POOL_ALIGN_MASK  \
>   (~(EFI_PHYSICAL_ADDRESS)(PAGE_TABLE_POOL_ALIGNMENT - 1))
> 
>diff --git a/UefiCpuPkg/CpuDxe/CpuPageTable.c 
>b/UefiCpuPkg/CpuDxe/CpuPageTable.c
>index 57ec76378a..a9c9bc9d5e 100644
>--- a/UefiCpuPkg/CpuDxe/CpuPageTable.c
>+++ b/UefiCpuPkg/CpuDxe/CpuPageTable.c
>@@ -1000,13 +1000,13 @@ RefreshGcdMemoryAttributesFromPaging (
>   Initialize a buffer pool for page table use only.
> 
>   To reduce the potential split operation on page table, the pages reserved 
> for
>-  page table should be allocated in the times of 512 (= SIZE_2MB) and at the
>-  boundary of SIZE_2MB. So the page pool is always initialized with number of
>-  pages greater than or equal to the given PoolPages.
>+  page table should be allocated in the times of PAGE_TABLE_POOL_UNIT_PAGES 
>and
>+  at the boundary of PAGE_TABLE_POOL_ALIGNMENT. So the page pool is always
>+  initialized with number of pages greater than or equal to the given 
>PoolPages.
> 
>   Once the pages in the pool are used up, this method should be called again 
> to
>-  reserve at least another 512 pages. Usually this won't happen often in
>-  practice.
>+  reserve at least another PAGE_TABLE_POOL_UNIT_PAGES. Usually this won't 
>happen
>+  often in practice.
> 
>   @param[in] PoolPages  The least page number of the pool to be created.
> 
>@@ -1022,15 +1022,12 @@ InitializePageTablePool (
>   BOOLEAN   IsModified;
> 
>   //
>-  // Always reserve at least PAGE_TABLE_POOL_UNIT_PAGES (512).
>+  // Always reserve at least PAGE_TABLE_POOL_UNIT_PAGES, including one page 
>for
>+  // header.
>   //
>-  if (PoolPages <= PAGE_TABLE_POOL_UNIT_PAGES) {
>-PoolPages = PAGE_TABLE_POOL_UNIT_PAGES;
>-  } else {
>-PoolPages = ((PoolPages + PAGE_TABLE_POOL_UNIT_PAGES) %
>- PAGE_TABLE_POOL_UNIT_PAGES) * PAGE_TABLE_POOL_UNIT_PAGES;
>-  }
>-
>+  PoolPages += 1;   // Add one page for header.
>+  PoolPages = ((PoolPages - 1) / PAGE_TABLE_POOL_UNIT_PAGES + 

Re: [edk2] [PATCH] BaseTools: Fix GenSec can't found the depex file

[Leif Lindholm]

Hi Yonghong,

This patch resolves the issue for the hikey platform, but not for
(edk2-platforms/Platform/Hisilicon/)D03/D05. They fail with

---
Generating FVMAIN FV
##

#Return Value = 2
GenSec: ERROR 0001: Error opening file

  
/work/git/tianocore/Build/D03/DEBUG_GCC5/AARCH64/Platform/Hisilicon/D03/Drivers/Net/SnpPlatform/SnpPlatform/OUTPUT/SnpPlatform.depex
GenSec: ERROR 2000: Status is not successful
---

and

---
Generating FVMAIN FV
##


Return Value = 2
GenSec: ERROR 0001: Error opening file


  
/work/git/tianocore/Build/D05/RELEASE_GCC5/AARCH64/Platform/Hisilicon/D05/Drivers/Net/SnpPlatform/SnpPlatform/OUTPUT/SnpPlatform.depex
GenFds.py...
 : error 7000: Failed to generate section
GenSec: ERROR 2000: Status is not successful
---

respectively.

Again, reverting 37de70b7 makes the build successful again.

Note that the failing drivers are binary, held in edk2-non-osi.

Regards,

Leif

On Thu, Dec 07, 2017 at 02:51:17PM +0800, Yonghong Zhu wrote:
> From: Yunhua Feng 
> 
> Filter the FileList when multiple genfds thread options is not enabled.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Yunhua Feng 
> ---
>  BaseTools/Source/Python/GenFds/EfiSection.py | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/BaseTools/Source/Python/GenFds/EfiSection.py 
> b/BaseTools/Source/Python/GenFds/EfiSection.py
> index 7b3b717191..4276945a10 100644
> --- a/BaseTools/Source/Python/GenFds/EfiSection.py
> +++ b/BaseTools/Source/Python/GenFds/EfiSection.py
> @@ -92,7 +92,8 @@ class EfiSection (EfiSectionClassObject):
>  elif os.path.exists(Filename):
>  FileList.append(Filename)
>  elif '.depex' in FfsInf.FinalTargetSuffixMap or FfsInf.Depex:
> -FileList.append(Filename)
> +if IsMakefile:
> +FileList.append(Filename)
>  else:
>  FileList, IsSect = Section.Section.GetFileList(FfsInf, 
> self.FileType, self.FileExtension, Dict)
>  if IsSect :
> -- 
> 2.12.2.windows.2
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] BaseTools/tools_def: add CLANG38 LTO versions for AARCH64 and ARM

[Ard Biesheuvel]

On 7 December 2017 at 11:09, Laszlo Ersek  wrote:
> On 12/07/17 03:05, Shi, Steven wrote:
>> Hi Ard,
>> I'm OK for the patch.
>> BTW, would you mind to help add the "-Wno-unused-const-variable" in the 
>> CLANG38_WARNING_OVERRIDES? I happen to need add it in CLANG38 
>> (https://bugzilla.tianocore.org/show_bug.cgi?id=790) and I see it seems a 
>> shared flag for ARM/AARCH64 as well.
>
> I suggest we handle that flag / BZ separately from this patch. (If Ard
> feels very generous, he could append a separate patch to this series,
> for adding the flag, but I don't think we can *ask* for that. It's a
> totally separate topic.)
>

Yes, it is. But guess what, I was feeling very generous, so I did exactly that.
(I am guessing Steven is very busy, so I don't mind doing his work :-))

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

Re: [edk2] [Patch] SourceLevelDebugPkg/SecPeiDebugAgentLib: Fix duplicate symbol

[Laszlo Ersek]

On 12/07/17 09:46, Ard Biesheuvel wrote:
> On 7 December 2017 at 07:48, Liming Gao  wrote:
>> From: Michael Kinney 
>>
>> https://bugzilla.tianocore.org/show_bug.cgi?id=573
>> https://bugzilla.tianocore.org/show_bug.cgi?id=796
>>
>> The same issue is reported again by GCC. Resend this patch again.
>> This patch renames the duplicated function name to fix it.
>>
>> The SecPeiDebugAgentLib uses the global variable
>> mMemoryDiscoveredNotifyList for a PPI notification on
>> the Memory Discovered PPI.  This same variable name is
>> used in the DxeIplPeim for the same PPI notification.
>>
>> The XCODE5 tool chain detects this duplicate symbol
>> when the OVMF platform is built with the flag
>> -D SOURCE_DEBUG_ENABLE.
>>
>> The fix is to rename this global variable in the
>> SecPeiDebugAgentLib library.
>>
> 
> No, the fix is to make it STATIC unless it *needs* to be a global.
> Is that the case here?

I agree with you (of course), but Mike explained earlier (if I recall
correctly -- and perhaps you remember too) that giving internal linkage
to global variables (i.e., making them STATIC) messes either with
debuggability under VS, or else defeats "GLOBAL_REMOVE_IF_UNREFERENCED".
(I'm not sure which one of the two.)

So, I've settled on considering "extern by default" just another
peculiarity of edk2. *shrug* I'm just glad -fno-common catches bugs like
this!

Reviewed-by: Laszlo Ersek 

(Obviously I'm not trying to dismiss your objection at all! Just stating
my view. If the patch is changed to STATIC, I'll R-b that version *more
happily* than this one.)

Thanks!
Laszlo

> 
> 
>> Cc: Andrew Fish 
>> Cc: Jeff Fan 
>> Cc: Hao Wu 
>> Cc: Laszlo Ersek 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Michael D Kinney 
>> Reviewed-by: Jeff Fan 
>> ---
>>  .../Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c | 4 
>> ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git 
>> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>>  
>> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>> index b717e33..9f5223a 100644
>> --- 
>> a/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>> +++ 
>> b/SourceLevelDebugPkg/Library/DebugAgent/SecPeiDebugAgent/SecPeiDebugAgentLib.c
>> @@ -32,7 +32,7 @@ GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_PPI_DESCRIPTOR   
>> mVectorHandoffInf
>>}
>>  };
>>
>> -GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR 
>> mMemoryDiscoveredNotifyList[1] = {
>> +GLOBAL_REMOVE_IF_UNREFERENCED EFI_PEI_NOTIFY_DESCRIPTOR 
>> mDebugAgentMemoryDiscoveredNotifyList[1] = {
>>{
>>  (EFI_PEI_PPI_DESCRIPTOR_NOTIFY_CALLBACK | 
>> EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST),
>>  ,
>> @@ -554,7 +554,7 @@ InitializeDebugAgent (
>>  // Register for a callback once memory has been initialized.
>>  // If memery has been ready, the callback funtion will be invoked 
>> immediately
>>  //
>> -Status = PeiServicesNotifyPpi ([0]);
>> +Status = PeiServicesNotifyPpi 
>> ([0]);
>>  if (EFI_ERROR (Status)) {
>>DEBUG ((EFI_D_ERROR, "DebugAgent: Failed to register memory 
>> discovered callback function!\n"));
>>CpuDeadLoop ();
>> --
>> 2.6.3.windows.1
>>
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>> GitPatchExtractor 1.1
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel

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

Re: [edk2] [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support for Watchdog driver

[Udit Kumar]

Hi Liming, 

> DxeCore uses WatchdogTimer->SetTimerPeriod(). This service is implemented in
> your driver.

Callers of SetTimerPeriod are ignoring error reported. 
Is they assume this call will be perfect or they are ok in case some error on 
watchdog service. 

 
Regards
Udit 

> -Original Message-
> From: Gao, Liming [mailto:liming@intel.com]
> Sent: Thursday, December 07, 2017 12:42 PM
> To: Leif Lindholm ; Udit Kumar
> 
> Cc: Kinney, Michael D ; Meenakshi Aggarwal
> ; ard.biesheu...@linaro.org; edk2-
> de...@lists.01.org; Varun Sethi 
> Subject: RE: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support
> for Watchdog driver
> 
> Leif:
>   I don't see the core driver uses WatchdogTimer->RegisterHandler(). When it
> returns unsupported, it means the additional handler can't be registered.
> DxeCore uses WatchdogTimer->SetTimerPeriod(). This service is implemented in
> your driver.
> 
>   Watchdog protocol is defined in PI spec. Spec describes that this protocol
> provides the services required to implement the Boot Service
> SetWatchdogTimer(). It provides a service to set the amount of time to wait
> before firing the watchdog timer, and it also provides a service to register a
> handler that is invoked when the watchdog timer fires. This protocol can
> implement the watchdog timer by using the event and timer Boot Services, or it
> can make use of custom hardware. If no handler has been registered, or the
> registered handler returns, then the system will be reset by calling the 
> Runtime
> Service ResetSystem(). So, this protocol is required.
> 
> Thanks
> Liming
> >-Original Message-
> >From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> >Sent: Tuesday, December 05, 2017 7:06 PM
> >To: Udit Kumar 
> >Cc: Gao, Liming ; Kinney, Michael D
> >; Meenakshi Aggarwal
> >; ard.biesheu...@linaro.org; edk2-
> >de...@lists.01.org; Varun Sethi 
> >Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> >support for Watchdog driver
> >
> >On Tue, Dec 05, 2017 at 05:07:00AM +, Udit Kumar wrote:
> >> >   I suggest return EFI_UNSUPPORTED for this case. The protocol
> >implementation
> >> > could return its status besides spec defined status.
> >>
> >> Thanks to help me , how core will treat this error 1/  Wdt not
> >> available 2/ ignoring this error 3/ core is not registering handler I
> >> guess 3 is valid,
> >
> >Looking at Core/Dxe/Misc/SetWatchdogTimer.c:
> >  //
> >  // Attempt to set the timeout
> >  //
> >  Status = gWatchdogTimer->SetTimerPeriod (gWatchdogTimer,
> >  MultU64x32 (Timeout, WATCHDOG_TIMER_CALIBRATE_PER_SECOND));
> >
> >  //
> >  // Check for errors
> >  //
> >  if (EFI_ERROR (Status)) {
> >return EFI_DEVICE_ERROR;
> >  }
> >
> >The SetWatchdogTimer() call would always return EFI_DEVICE_ERROR.
> >
> >> On side track, looks wdt is not used by core services then do we
> >> really need this as part of arch protocol ?
> >
> >Yes, that was ultimately what I was implying with my question regarding
> >whether this protocol is relevant for a watchdog that can only ever
> >reset the system on timeout.
> >
> >The protocol looks to me to be designed to use a dedicated generic
> >timer as backing for a software watchdog.
> >
> >Liming, Mike?
> >
> >If that is the case, then I agree this driver should probably not
> >implement this protocol, but rather set up a timer event (or a
> >dedicated timer) to stroke the watchdog.
> >
> >Regards,
> >
> >Leif
> >
> >> regards
> >> Udit
> >>
> >> > -Original Message-
> >> > From: Gao, Liming [mailto:liming@intel.com]
> >> > Sent: Monday, December 04, 2017 8:53 PM
> >> > To: Leif Lindholm ; Kinney, Michael D
> >> > 
> >> > Cc: Meenakshi Aggarwal ;
> >> > ard.biesheu...@linaro.org; edk2-devel@lists.01.org; Udit Kumar
> >> > ; Varun Sethi 
> >> > Subject: RE: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP :
> >> > Add
> >support
> >> > for Watchdog driver
> >> >
> >> > Leif:
> >> >   I suggest return EFI_UNSUPPORTED for this case. The protocol
> >implementation
> >> > could return its status besides spec defined status.
> >> >
> >> > Thanks
> >> > Liming
> >> > > -Original Message-
> >> > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> >> > > Sent: Monday, December 4, 2017 10:36 PM
> >> > > To: Kinney, Michael D ; Gao, Liming
> >> > > 
> >> > > Cc: Meenakshi Aggarwal ;
> >> > > ard.biesheu...@linaro.org; edk2-devel@lists.01.org;
> >> > > udit.ku...@nxp.com; v.se...@nxp.com
> >> > > Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP :
> >> > > 

Re: [edk2] [PATCH] UefiCpuPkg PiSmmCpuDxeSmm: Only DumpCpuContext in error case

[Laszlo Ersek]

On 12/07/17 02:49, Star Zeng wrote:
> Only DumpCpuContext in error case, otherwise there will be too many
> debug messages from DumpCpuContext() when SmmProfile feature is enabled
> by setting PcdCpuSmmProfileEnable to TRUE. Those debug messages are not
> needed for SmmProfile feature as it will record those information to
> buffer for further dump.
> 
> Cc: Jiewen Yao 
> Cc: Eric Dong 
> Cc: Laszlo Ersek 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng 
> ---
>  UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c | 6 --
>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c  | 6 --
>  2 files changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> index 0396f2daaaed..6e1ffe7c6287 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
> @@ -134,12 +134,12 @@ SmiPFHandler (
>}
>  
>//
> -  // If a page fault occurs in SMM range
> +  // If a page fault occurs in non-SMRAM range.
>//
>if ((PFAddress < mCpuHotPlugData.SmrrBase) ||
>(PFAddress >= mCpuHotPlugData.SmrrBase + mCpuHotPlugData.SmrrSize)) {
> -DumpCpuContext (InterruptType, SystemContext);
>  if ((SystemContext.SystemContextIa32->ExceptionData & IA32_PF_EC_ID) != 
> 0) {
> +  DumpCpuContext (InterruptType, SystemContext);
>DEBUG ((DEBUG_ERROR, "Code executed on IP(0x%x) out of SMM range after 
> SMM is locked!\n", PFAddress));
>DEBUG_CODE (
>  DumpModuleInfoByIp (*(UINTN 
> *)(UINTN)SystemContext.SystemContextIa32->Esp);
> @@ -147,6 +147,7 @@ SmiPFHandler (
>CpuDeadLoop ();
>  }
>  if (IsSmmCommBufferForbiddenAddress (PFAddress)) {
> +  DumpCpuContext (InterruptType, SystemContext);
>DEBUG ((DEBUG_ERROR, "Access SMM communication forbidden address 
> (0x%x)!\n", PFAddress));
>DEBUG_CODE (
>  DumpModuleInfoByIp ((UINTN)SystemContext.SystemContextIa32->Eip);
> @@ -160,6 +161,7 @@ SmiPFHandler (
>//
>if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT1) != 0 &&
>(PFAddress < EFI_PAGE_SIZE)) {
> +DumpCpuContext (InterruptType, SystemContext);
>  DEBUG ((DEBUG_ERROR, "!!! NULL pointer access !!!\n"));
>  DEBUG_CODE (
>DumpModuleInfoByIp ((UINTN)SystemContext.SystemContextIa32->Eip);
> diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c 
> b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> index 79a26d7ec6a3..6478c6c3e355 100644
> --- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> +++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
> @@ -851,12 +851,12 @@ SmiPFHandler (
>}
>  
>//
> -  // If a page fault occurs in SMM range
> +  // If a page fault occurs in non-SMRAM range.
>//
>if ((PFAddress < mCpuHotPlugData.SmrrBase) ||
>(PFAddress >= mCpuHotPlugData.SmrrBase + mCpuHotPlugData.SmrrSize)) {
> -DumpCpuContext (InterruptType, SystemContext);
>  if ((SystemContext.SystemContextX64->ExceptionData & IA32_PF_EC_ID) != 
> 0) {
> +  DumpCpuContext (InterruptType, SystemContext);
>DEBUG ((DEBUG_ERROR, "Code executed on IP(0x%lx) out of SMM range 
> after SMM is locked!\n", PFAddress));
>DEBUG_CODE (
>  DumpModuleInfoByIp (*(UINTN 
> *)(UINTN)SystemContext.SystemContextX64->Rsp);
> @@ -864,6 +864,7 @@ SmiPFHandler (
>CpuDeadLoop ();
>  }
>  if (IsSmmCommBufferForbiddenAddress (PFAddress)) {
> +  DumpCpuContext (InterruptType, SystemContext);
>DEBUG ((DEBUG_ERROR, "Access SMM communication forbidden address 
> (0x%lx)!\n", PFAddress));
>DEBUG_CODE (
>  DumpModuleInfoByIp ((UINTN)SystemContext.SystemContextX64->Rip);
> @@ -877,6 +878,7 @@ SmiPFHandler (
>//
>if ((PcdGet8 (PcdNullPointerDetectionPropertyMask) & BIT1) != 0 &&
>(PFAddress < EFI_PAGE_SIZE)) {
> +DumpCpuContext (InterruptType, SystemContext);
>  DEBUG ((DEBUG_ERROR, "!!! NULL pointer access !!!\n"));
>  DEBUG_CODE (
>DumpModuleInfoByIp ((UINTN)SystemContext.SystemContextX64->Rip);
> 

Looks reasonable to me.

Acked-by: Laszlo Ersek 

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

Re: [edk2] [PATCH] BaseTools/tools_def: add CLANG38 LTO versions for AARCH64 and ARM

[Laszlo Ersek]

On 12/07/17 03:05, Shi, Steven wrote:
> Hi Ard,
> I'm OK for the patch.
> BTW, would you mind to help add the "-Wno-unused-const-variable" in the 
> CLANG38_WARNING_OVERRIDES? I happen to need add it in CLANG38 
> (https://bugzilla.tianocore.org/show_bug.cgi?id=790) and I see it seems a 
> shared flag for ARM/AARCH64 as well.

I suggest we handle that flag / BZ separately from this patch. (If Ard
feels very generous, he could append a separate patch to this series,
for adding the flag, but I don't think we can *ask* for that. It's a
totally separate topic.)

Thanks!
Laszlo

> 
> Steven Shi
> Intel\SSG\STO\UEFI Firmware
> 
> Tel: +86 021-61166522
> iNet: 821-6522
> 
> 
>> -Original Message-
>> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
>> Sent: Wednesday, December 6, 2017 7:39 PM
>> To: edk2-devel@lists.01.org
>> Cc: leif.lindh...@linaro.org; Gao, Liming ; Zhu,
>> Yonghong ; Shi, Steven ;
>> evan.ll...@arm.com; ler...@redhat.com; Ard Biesheuvel
>> 
>> Subject: [PATCH] BaseTools/tools_def: add CLANG38 LTO versions for
>> AARCH64 and ARM
>>
>> Extend the CLANG38 toolchain definition so it can be used for
>> ARM and AARCH64 as well. Note that this requires llvm-ar and
>> the LLVMgold.so linker plugin.
>>
>> In preparation of doing the same for GCC5, this toolchain version
>> also departs from the custom of using -O0 for DEBUG builds, which
>> makes them needlessly slow. Instead, let's add a NOOPT flavor as
>> well, and enable optimization for DEBUG like the other architectures
>> do. (Note that this will require some trivial changes to the platform
>> description files)
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel 
>> ---
>>  BaseTools/Conf/tools_def.template | 98 +++-
>>  1 file changed, 95 insertions(+), 3 deletions(-)
>>
>> diff --git a/BaseTools/Conf/tools_def.template
>> b/BaseTools/Conf/tools_def.template
>> index 91b135c2e569..6ee720d7586e 100755
>> --- a/BaseTools/Conf/tools_def.template
>> +++ b/BaseTools/Conf/tools_def.template
>> @@ -399,8 +399,8 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
>>  #   Intel(r) ACPI Compiler from
>>  #   https://acpica.org/downloads
>>  #   CLANG38  -Linux-  Requires:
>> -# Clang v3.8, LLVMgold plugin and GNU binutils 
>> 2.26
>> targeting x86_64-linux-gnu
>> -# Clang v3.9 or later, LLVMgold plugin and GNU 
>> binutils 2.28
>> targeting x86_64-linux-gnu
>> +# Clang v3.8, LLVMgold plugin and GNU binutils 
>> 2.26
>> targeting x86_64-linux-gnu, aarch64-linux-gnu or arm-linux-gnueabi
>> +# Clang v3.9 or later, LLVMgold plugin and GNU 
>> binutils 2.28
>> targeting x86_64-linux-gnu, aarch64-linux-gnu or arm-linux-gnueabi
>>  #Optional:
>>  # Required to build platforms or ACPI tables:
>>  #   Intel(r) ACPI Compiler from
>> @@ -5652,6 +5652,7 @@ RELEASE_CLANG35_AARCH64_CC_FLAGS =
>> DEF(CLANG35_AARCH64_CC_FLAGS) $(ARCHCC_FLAGS)
>>  *_CLANG38_*_MAKE_PATH   = make
>>  *_CLANG38_*_*_DLL   = ENV(CLANG38_DLL)
>>  *_CLANG38_*_ASL_PATH= DEF(UNIX_IASL_BIN)
>> +*_CLANG38_*_DTC_PATH= DEF(DTC_BIN)
>>
>>  *_CLANG38_*_APP_FLAGS   =
>>  *_CLANG38_*_ASL_FLAGS   = DEF(IASL_FLAGS)
>> @@ -5663,7 +5664,8 @@ DEFINE CLANG38_X64_PREFIX   =
>> ENV(CLANG38_BIN)
>>  DEFINE CLANG38_IA32_TARGET  = -target i686-pc-linux-gnu
>>  DEFINE CLANG38_X64_TARGET   = -target x86_64-pc-linux-gnu
>>
>> -DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS) -Wno-
>> empty-body -fno-stack-protector -mms-bitfields -Wno-address -Wno-shift-
>> negative-value -Wno-parentheses-equality -Wno-unknown-pragmas -Wno-
>> tautological-constant-out-of-range-compare -Wno-incompatible-library-
>> redeclaration -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -
>> msoft-float -mno-implicit-float  -ftrap-
>> function=undefined_behavior_has_been_optimized_away_by_clang -
>> funsigned-char -fno-ms-extensions -Wno-null-dereference -Wno-
>> tautological-compare -Wno-unknown-warning-option -Wno-varargs
>> +DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality -
>> Wno-tautological-compare -Wno-tautological-constant-out-of-range-
>> compare -Wno-empty-body  -Wno-varargs
>> +DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC44_ALL_CC_FLAGS)
>> DEF(CLANG38_WARNING_OVERRIDES) -fno-stack-protector -mms-bitfields -
>> Wno-address -Wno-shift-negative-value -Wno-unknown-pragmas -Wno-
>> incompatible-library-redeclaration -fno-asynchronous-unwind-tables -mno-
>> sse -mno-mmx -msoft-float -mno-implicit-float  -ftrap-
>> 

Re: [edk2] [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add support for Watchdog driver

[Leif Lindholm]

Hi Liming,

On Thu, Dec 07, 2017 at 07:11:38AM +, Gao, Liming wrote:
> Leif:
>   I don't see the core driver uses
>   WatchdogTimer->RegisterHandler(). When it returns unsupported, it
>   means the additional handler can't be registered. DxeCore uses
>   WatchdogTimer->SetTimerPeriod(). This service is implemented in
>   your driver.
> 
>   Watchdog protocol is defined in PI spec. Spec describes that this
>   protocol provides the services required to implement the Boot
>   Service SetWatchdogTimer(). It provides a service to set the
>   amount of time to wait before firing the watchdog timer, and it
>   also provides a service to register a handler that is invoked when
>   the watchdog timer fires. This protocol can implement the watchdog
>   timer by using the event and timer Boot Services, or it can make
>   use of custom hardware. If no handler has been registered, or the
>   registered handler returns, then the system will be reset by
>   calling the Runtime Service ResetSystem(). So, this protocol is
>   required.

I am not disputing that the protocol is not required. I am suggesting
that this hardware watchdog _cannot_ be used to register a handler.

If this hardware watchdog does not get updated in time, that causes an
immediate hardware reset of the processor.

Because of this, I believe EFI_WATCHDOG_TIMER_ARCH_PROTOCOL is not the
appropriate way to make use of it.

Please let me know whether you agree.

Regards,

Leif

> Thanks
> Liming
> >-Original Message-
> >From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> >Sent: Tuesday, December 05, 2017 7:06 PM
> >To: Udit Kumar 
> >Cc: Gao, Liming ; Kinney, Michael D
> >; Meenakshi Aggarwal
> >; ard.biesheu...@linaro.org; edk2-
> >de...@lists.01.org; Varun Sethi 
> >Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> >support for Watchdog driver
> >
> >On Tue, Dec 05, 2017 at 05:07:00AM +, Udit Kumar wrote:
> >> >   I suggest return EFI_UNSUPPORTED for this case. The protocol
> >implementation
> >> > could return its status besides spec defined status.
> >>
> >> Thanks to help me , how core will treat this error
> >> 1/  Wdt not available
> >> 2/ ignoring this error
> >> 3/ core is not registering handler
> >> I guess 3 is valid,
> >
> >Looking at Core/Dxe/Misc/SetWatchdogTimer.c:
> >  //
> >  // Attempt to set the timeout
> >  //
> >  Status = gWatchdogTimer->SetTimerPeriod (gWatchdogTimer,
> >  MultU64x32 (Timeout, WATCHDOG_TIMER_CALIBRATE_PER_SECOND));
> >
> >  //
> >  // Check for errors
> >  //
> >  if (EFI_ERROR (Status)) {
> >return EFI_DEVICE_ERROR;
> >  }
> >
> >The SetWatchdogTimer() call would always return EFI_DEVICE_ERROR.
> >
> >> On side track, looks wdt is not used by core services then do we
> >> really need this as part of arch protocol ?
> >
> >Yes, that was ultimately what I was implying with my question
> >regarding whether this protocol is relevant for a watchdog that can
> >only ever reset the system on timeout.
> >
> >The protocol looks to me to be designed to use a dedicated generic
> >timer as backing for a software watchdog.
> >
> >Liming, Mike?
> >
> >If that is the case, then I agree this driver should probably not
> >implement this protocol, but rather set up a timer event (or a
> >dedicated timer) to stroke the watchdog.
> >
> >Regards,
> >
> >Leif
> >
> >> regards
> >> Udit
> >>
> >> > -Original Message-
> >> > From: Gao, Liming [mailto:liming@intel.com]
> >> > Sent: Monday, December 04, 2017 8:53 PM
> >> > To: Leif Lindholm ; Kinney, Michael D
> >> > 
> >> > Cc: Meenakshi Aggarwal ;
> >> > ard.biesheu...@linaro.org; edk2-devel@lists.01.org; Udit Kumar
> >> > ; Varun Sethi 
> >> > Subject: RE: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> >support
> >> > for Watchdog driver
> >> >
> >> > Leif:
> >> >   I suggest return EFI_UNSUPPORTED for this case. The protocol
> >implementation
> >> > could return its status besides spec defined status.
> >> >
> >> > Thanks
> >> > Liming
> >> > > -Original Message-
> >> > > From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> >> > > Sent: Monday, December 4, 2017 10:36 PM
> >> > > To: Kinney, Michael D ; Gao, Liming
> >> > > 
> >> > > Cc: Meenakshi Aggarwal ;
> >> > > ard.biesheu...@linaro.org; edk2-devel@lists.01.org;
> >> > > udit.ku...@nxp.com; v.se...@nxp.com
> >> > > Subject: Re: [PATCH edk2-platforms] [PATCH v3 2/9] Platform/NXP : Add
> >> > > support for Watchdog driver
> >> > >
> >> > > Mike, Liming, as MdePkg mainteiners - one question below:
> >> > >
> >> > > On Mon, Nov 27, 2017 at 04:21:50PM +0530, Meenakshi Aggarwal wrote:
> >> > > > diff --git a/Platform/NXP/Drivers/WatchDog/WatchDog.c
> 

Re: [edk2] [PATCH] UefiCpuPkg PiSmmCpuDxeSmm: SMM profile and static paging mutual exclusion

[Dong, Eric]

Star,

Reviewed-by: Eric Dong 


Below typo you can change when you push the code.

+  #  It could not be enabled at the same time with SMM profile feature 
(PcdCpuSmmStaticPageTable).

" SMM profile feature " should be "Static page table feature"?

Thanks,
Eric
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng
Sent: Thursday, December 7, 2017 6:48 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu; Dong, Eric; Yao, Jiewen; Laszlo Ersek; Zeng, Star
Subject: [edk2] [PATCH] UefiCpuPkg PiSmmCpuDxeSmm: SMM profile and static 
paging mutual exclusion

SMM profile and static paging could not enabled at the same time, this patch is 
add check and comments to make sure it.

Similar comments are also added for the case of static paging and heap guard 
for SMM.

Cc: Jiewen Yao 
Cc: Eric Dong 
Cc: Ruiyu Ni 
Cc: Jian J Wang 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c |  9 +  
UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c  | 13 ++---
 UefiCpuPkg/UefiCpuPkg.dec|  6 +-
 UefiCpuPkg/UefiCpuPkg.uni| 10 --
 4 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
index 6e1ffe7c6287..939ac25a506c 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
@@ -205,6 +205,15 @@ SetPageTableAttributes (
   //  BIT3: SMM pool guard enabled
   //
   if ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
+DEBUG ((DEBUG_INFO, "Don't mark page table as read-only as heap guard is 
enabled\n"));
+return ;
+  }
+
+  //
+  // Don't mark page table as read-only if SMM profile is enabled.
+  //
+  if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
+DEBUG ((DEBUG_INFO, "Don't mark page table as read-only as SMM 
+ profile is enabled\n"));
 return ;
   }
 
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
index 6478c6c3e355..0fe944fc18cc 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
@@ -919,17 +919,24 @@ SetPageTableAttributes (
   //
   // Don't do this if
   //  - no static page table; or
-  //  - SMM heap guard feature enabled
+  //  - SMM heap guard feature enabled; or
   //  BIT2: SMM page guard enabled
   //  BIT3: SMM pool guard enabled
+  //  - SMM profile feature enabled
   //
   if (!mCpuSmmStaticPageTable ||
-  (PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
+  ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) ||
+  FeaturePcdGet (PcdCpuSmmProfileEnable)) {
 //
-// Static paging and heap guard should not be enabled at the same time.
+// Static paging and heap guard could not be enabled at the same time.
 //
 ASSERT (!(mCpuSmmStaticPageTable &&
   (PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0));
+
+//
+// Static paging and SMM profile could not be enabled at the same time.
+//
+ASSERT (!(mCpuSmmStaticPageTable && FeaturePcdGet 
+ (PcdCpuSmmProfileEnable)));
 return ;
   }
 
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec index 
d2965ba14c2d..36205ab63796 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -84,6 +84,7 @@ [Protocols]
 [PcdsFeatureFlag]
   ## Indicates if SMM Profile will be enabled.
   #  If enabled, instruction executions in and data accesses to memory outside 
of SMRAM will be logged.
+  #  It could not be enabled at the same time with SMM profile feature 
(PcdCpuSmmStaticPageTable).
   #  This PCD is only for validation purpose. It should be set to false in 
production.
   #   TRUE  - SMM Profile will be enabled.
   #   FALSE - SMM Profile will be disabled.
@@ -225,8 +226,11 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, 
PcdsDynamicEx]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate|0|UINT8|0x0007
 
   ## Indicates if SMM uses static page table.
-  #  If enabled, SMM will not use on-demand paging. SMM will build static page 
table for all memory.
+  #  If enabled, SMM will not use on-demand paging. SMM will build static page 
table for all memory.
   #  This flag only impacts X64 build, because SMM alway builds static page 
table for IA32.
+  #  It could not be enabled at the same time with SMM profile feature 
(PcdCpuSmmProfileEnable).
+  #  It could not be enabled also at the same time with heap guard 
+ feature for SMM  #  (PcdHeapGuardPropertyMask in 
+ MdeModulePkg).
   #   TRUE  - SMM uses static page table for all memory.
   #   FALSE - SMM uses static page table for below 4G memory and use on-demand 
paging for above 4G memory.
   # @Prompt 

[edk2] [PATCH] UefiCpuPkg PiSmmCpuDxeSmm: SMM profile and static paging mutual exclusion

[Star Zeng]

SMM profile and static paging could not enabled at the same time,
this patch is add check and comments to make sure it.

Similar comments are also added for the case of static paging and
heap guard for SMM.

Cc: Jiewen Yao 
Cc: Eric Dong 
Cc: Ruiyu Ni 
Cc: Jian J Wang 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c |  9 +
 UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c  | 13 ++---
 UefiCpuPkg/UefiCpuPkg.dec|  6 +-
 UefiCpuPkg/UefiCpuPkg.uni| 10 --
 4 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
index 6e1ffe7c6287..939ac25a506c 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/Ia32/PageTbl.c
@@ -205,6 +205,15 @@ SetPageTableAttributes (
   //  BIT3: SMM pool guard enabled
   //
   if ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
+DEBUG ((DEBUG_INFO, "Don't mark page table as read-only as heap guard is 
enabled\n"));
+return ;
+  }
+
+  //
+  // Don't mark page table as read-only if SMM profile is enabled.
+  //
+  if (FeaturePcdGet (PcdCpuSmmProfileEnable)) {
+DEBUG ((DEBUG_INFO, "Don't mark page table as read-only as SMM profile is 
enabled\n"));
 return ;
   }
 
diff --git a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c 
b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
index 6478c6c3e355..0fe944fc18cc 100644
--- a/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
+++ b/UefiCpuPkg/PiSmmCpuDxeSmm/X64/PageTbl.c
@@ -919,17 +919,24 @@ SetPageTableAttributes (
   //
   // Don't do this if
   //  - no static page table; or
-  //  - SMM heap guard feature enabled
+  //  - SMM heap guard feature enabled; or
   //  BIT2: SMM page guard enabled
   //  BIT3: SMM pool guard enabled
+  //  - SMM profile feature enabled
   //
   if (!mCpuSmmStaticPageTable ||
-  (PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) {
+  ((PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0) ||
+  FeaturePcdGet (PcdCpuSmmProfileEnable)) {
 //
-// Static paging and heap guard should not be enabled at the same time.
+// Static paging and heap guard could not be enabled at the same time.
 //
 ASSERT (!(mCpuSmmStaticPageTable &&
   (PcdGet8 (PcdHeapGuardPropertyMask) & (BIT3 | BIT2)) != 0));
+
+//
+// Static paging and SMM profile could not be enabled at the same time.
+//
+ASSERT (!(mCpuSmmStaticPageTable && FeaturePcdGet 
(PcdCpuSmmProfileEnable)));
 return ;
   }
 
diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
index d2965ba14c2d..36205ab63796 100644
--- a/UefiCpuPkg/UefiCpuPkg.dec
+++ b/UefiCpuPkg/UefiCpuPkg.dec
@@ -84,6 +84,7 @@ [Protocols]
 [PcdsFeatureFlag]
   ## Indicates if SMM Profile will be enabled.
   #  If enabled, instruction executions in and data accesses to memory outside 
of SMRAM will be logged.
+  #  It could not be enabled at the same time with SMM profile feature 
(PcdCpuSmmStaticPageTable).
   #  This PCD is only for validation purpose. It should be set to false in 
production.
   #   TRUE  - SMM Profile will be enabled.
   #   FALSE - SMM Profile will be disabled.
@@ -225,8 +226,11 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, 
PcdsDynamicEx]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuApTargetCstate|0|UINT8|0x0007
 
   ## Indicates if SMM uses static page table.
-  #  If enabled, SMM will not use on-demand paging. SMM will build static page 
table for all memory.
+  #  If enabled, SMM will not use on-demand paging. SMM will build static page 
table for all memory.
   #  This flag only impacts X64 build, because SMM alway builds static page 
table for IA32.
+  #  It could not be enabled at the same time with SMM profile feature 
(PcdCpuSmmProfileEnable).
+  #  It could not be enabled also at the same time with heap guard feature for 
SMM
+  #  (PcdHeapGuardPropertyMask in MdeModulePkg).
   #   TRUE  - SMM uses static page table for all memory.
   #   FALSE - SMM uses static page table for below 4G memory and use on-demand 
paging for above 4G memory.
   # @Prompt Use static page table for all memory in SMM.
diff --git a/UefiCpuPkg/UefiCpuPkg.uni b/UefiCpuPkg/UefiCpuPkg.uni
index 9472b185e46e..013d2870a682 100644
--- a/UefiCpuPkg/UefiCpuPkg.uni
+++ b/UefiCpuPkg/UefiCpuPkg.uni
@@ -53,7 +53,10 @@
 
 #string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuSmmProfileEnable_PROMPT  #language 
en-US "Enable SMM Profile"
 
-#string STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuSmmProfileEnable_HELP  #language 
en-US "Indicates if SMM Profile will be enabled. If enabled, instruction 
executions in and data accesses to memory outside of SMRAM will be logged. This 
PCD is only for validation purpose. It should be set to 

Re: [edk2] [Patch] MdeModulePkg/NetLib: Fix an error when AIP doesn't support network media state detection

[Wu, Jiaxin]

Reviewed-by: Jiaxin Wu 



> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> fanwang2
> Sent: Thursday, December 7, 2017 5:51 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Wang, Fan ; Fu,
> Siyuan ; Wu, Jiaxin 
> Subject: [edk2] [Patch] MdeModulePkg/NetLib: Fix an error when AIP
> doesn't support network media state detection
> 
> AIP may not support detecting network media state, in this case,
> should call NetLibDetectMedia to get media state. This patch is to
> fix this issue.
> 
> Cc: Fu Siyuan 
> Cc: Ye Ting 
> Cc: Jiaxin Wu 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Wang Fan 
> ---
>  MdeModulePkg/Library/DxeNetLib/DxeNetLib.c | 18
> ++
>  1 file changed, 18 insertions(+)
> 
> diff --git a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> index 1bfa33d..d75cca2 100644
> --- a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> +++ b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
> @@ -2603,10 +2603,28 @@ NetLibDetectMediaWaitTimeout (
>} else {
> 
>  if (MediaInfo != NULL) {
>FreePool (MediaInfo);
>  }
> +
> +if (Status == EFI_UNSUPPORTED) {
> +
> +  //
> +  // If gEfiAdapterInfoMediaStateGuid is not supported, call
> NetLibDetectMedia to get media state!
> +  //
> +  MediaPresent = TRUE;
> +  Status = NetLibDetectMedia (ServiceHandle, );
> +  if (!EFI_ERROR (Status)) {
> +if (MediaPresent == TRUE) {
> +  *MediaState = EFI_SUCCESS;
> +} else {
> +  *MediaState = EFI_NO_MEDIA;
> +}
> +  }
> +  return Status;
> +}
> +
>  return Status;
>}
> 
>//
>// Loop to check media state
> --
> 1.9.5.msysgit.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] MdeModulePkg/UefiPxeBcDxe: Question about IcmpErrorListenHandler in PxeBcImpl.c

[Wu, Jiaxin]

> You say "IcmpErrorRcvToken is only used to get ICMP error from IP
> layer", does that mean only ICMP error packets will go to
> IcmpErrorListenHandler?
> If it is the case, how do we make it? I can only find a simple
> Ip4->Receive is called to receive IP4 packets; how are other types of
> IP4 packets filtered out?

No, all of the *ICMP* packets with the same station IP address will go to 
IcmpErrorListenHandler() callback function. Because PXE driver has already 
configured the current IP protocol only receive the ICMP packets: 
ZeroMem (>Ip4ConfigData, sizeof (EFI_IP4_CONFIG_DATA));
Private->Ip4ConfigData.DefaultProtocol   = EFI_IP_PROTO_ICMP;
Private->Ip4ConfigData.AcceptIcmpErrors  = TRUE;
Ip4ConfigData.DefaultProtocol   = EFI_IP_PROTO_ICMP;
So, it is only used to capture background ICMP packets (Including the ICMP 
error message) with the same station IP address.

> If it is not, why don't we need to filter the packets in
> IcmpErrorListenHandler? If we recycle the packets in
> IcmpErrorListenHandler, will it cause the upper layer of protocols fail
> to fetch RxData?

IcmpErrorListenHandler() should filter the packets and only handle the ICMP 
error message. But currently, the code logic is incorrect. I generated one 
patch as attached one for your reference, can you help to verify whether it 
works or not? (Ignore my previous suggestion check).

In my opinion, the RxData should be recycled since it has been recorded in 
Mode->IcmpError.

Thanks,
Jiaxin










> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Heyi Guo
> Sent: Thursday, December 7, 2017 4:18 PM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Fu, Siyuan ; Dong,
> Eric ; Zeng, Star 
> Subject: Re: [edk2] MdeModulePkg/UefiPxeBcDxe: Question about
> IcmpErrorListenHandler in PxeBcImpl.c
> 
> Hi Jiaxin,
> 
> Thanks for your reply.
> 
> You say "IcmpErrorRcvToken is only used to get ICMP error from IP
> layer", does that mean only ICMP error packets will go to
> IcmpErrorListenHandler?
> 
> If it is the case, how do we make it? I can only find a simple
> Ip4->Receive is called to receive IP4 packets; how are other types of
> IP4 packets filtered out?
> 
> If it is not, why don't we need to filter the packets in
> IcmpErrorListenHandler? If we recycle the packets in
> IcmpErrorListenHandler, will it cause the upper layer of protocols fail
> to fetch RxData?
> 
> Please forgive me if my questions are too stupid :)
> 
> Regards,
> 
> Gary (Heyi Guo)
> 
> 
> 在 12/7/2017 3:48 PM, Wu, Jiaxin 写道:
> > Hi Gary,
> >
> > IcmpErrorRcvToken is only used to get ICMP error from IP layer, and the
> data will be copied to Mode->IcmpError. So, I think the RxData should be
> recycled.
> >
> > Besides, EFI_IP_PROTO_ICMP should be also checked in the call function
> but currently it's not:
> >
> >if (!EFI_IP4_EQUAL (>Header->DestinationAddress, 
> >StationIp.v4)) {
> >  //
> >  // The dest address is not equal to Station Ip address, discard it.
> >  //
> >  goto CleanUp;
> >}
> >
> >+if (>Header->Protocol != EFI_IP_PROTO_ICMP) {
> >+//
> >+// The protocol value in the header of the receveid packet should be
> EFI_IP_PROTO_ICMP.
> >+//
> >+goto CleanUp;
> >+}
> >
> > Thanks the report.
> >
> > Thanks,
> > Jiaxin
> >
> >
> >
> >> -Original Message-
> >> From: Guo Heyi [mailto:heyi@linaro.org]
> >> Sent: Thursday, December 7, 2017 12:07 PM
> >> To: edk2-devel@lists.01.org
> >> Cc: Zeng, Star ; Dong, Eric ;
> Ni,
> >> Ruiyu ; Fu, Siyuan ; Wu, Jiaxin
> >> 
> >> Subject: MdeModulePkg/UefiPxeBcDxe: Question about
> >> IcmpErrorListenHandler in PxeBcImpl.c
> >>
> >> Hi folks,
> >>
> >> In PxeBcImpl.c, we have IcmpErrorListenHandler which seems to process
> >> ICMP errors. But in EfiPxeBcStart function, we can see Private-
> >>> IcmpErrorRcvToken.Event is only a common event and Ip4->Receive is
> >> called to receive IP4 packets. So will IcmpErrorListenHandler receive all 
> >> IP4
> >> packets belonging to this network interface, or will it only receive ICMP
> error
> >> packets? If it is the latter situation, how do we make it?
> >>
> >> The background of this question is that when we flush the network with
> >> deprecated ICMP packets (type 15, 16, ...), RxData will not be recycled and
> >> the list of UEFI events becomes longer and longer, which finally impacts
> >> system performance a lot. If only error ICMP will be received by
> >> IcmpErrorListenHandler, we'd like to patch it as below:
> >>
> >> diff --git
> a/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
> >> b/MdeModulePkg/Universal/Network/UefiPxeBcDxe/PxeBcImpl.c
> >> index 6d4f33f..f74b264 100644
> >> --- 

Re: [edk2] [Patch 4/4 V3] BaseTools: Update Makefile to support FFS file generation

[Zhu, Yonghong]

Hi Leif,

Please help to check whether this patch " [edk2] [PATCH] BaseTools: Fix GenSec 
can't found the depex file" can fix it. thanks a lot.

Best Regards,
Zhu Yonghong

-Original Message-
From: Zhu, Yonghong 
Sent: Thursday, December 07, 2017 9:00 AM
To: Leif Lindholm 
Cc: edk2-devel@lists.01.org; Feng, YunhuaX ; Gao, 
Liming ; Zhu, Yonghong 
Subject: RE: [edk2] [Patch 4/4 V3] BaseTools: Update Makefile to support FFS 
file generation

Thanks Leif.  I will provide patch to fix it soon.

Best Regards,
Zhu Yonghong


-Original Message-
From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
Sent: Thursday, December 07, 2017 2:24 AM
To: Zhu, Yonghong 
Cc: edk2-devel@lists.01.org; Feng, YunhuaX ; Gao, 
Liming 
Subject: Re: [edk2] [Patch 4/4 V3] BaseTools: Update Makefile to support FFS 
file generation

Hi Yonghong,

I'm afraid I have come across an issue with this one as well:
When trying to build OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b
into a platform (edk2-platforms/Platform/Hisilicon/HiKey/), GenSec fails with:

Generating FVMAIN FV


Return Value = 2
GenSec: ERROR 0001: Error opening file
  
/work/git/tianocore/Build/HiKey/RELEASE_GCC5/AARCH64/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772b/OUTPUT/Ax88772b.depex
GenSec: ERROR 2000: Status is not successful

If I revert commit 37de70b7, the platform builds successfully again.
D03 and D05 platforms also appear to have issues with this, but in that case 
due to drivers in edk2-non-osi.

/
Leif

On Wed, Nov 29, 2017 at 10:02:06PM +0800, Yonghong Zhu wrote:
> Update Makefile to support FFS file generation with new build option 
> --genfds-multi-thread.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Yonghong Zhu 
> Signed-off-by: Yunhua Feng 
> ---
>  BaseTools/Source/Python/AutoGen/AutoGen.py |  23 ++-
>  BaseTools/Source/Python/AutoGen/GenMake.py |  90 -
>  BaseTools/Source/Python/Common/GlobalData.py   |   1 +
>  BaseTools/Source/Python/GenFds/AprioriSection.py   |  14 +-
>  BaseTools/Source/Python/GenFds/CompressSection.py  |  10 +-
>  BaseTools/Source/Python/GenFds/DataSection.py  |  37 ++--
>  BaseTools/Source/Python/GenFds/DepexSection.py |   6 +-
>  BaseTools/Source/Python/GenFds/EfiSection.py   |  78 +---
>  BaseTools/Source/Python/GenFds/Fd.py   |  24 ++-
>  BaseTools/Source/Python/GenFds/FfsFileStatement.py |   4 +-
>  BaseTools/Source/Python/GenFds/FfsInfStatement.py  | 202 
> -
>  BaseTools/Source/Python/GenFds/Fv.py   | 189 ++-
>  BaseTools/Source/Python/GenFds/FvImageSection.py   |   8 +-
>  BaseTools/Source/Python/GenFds/GenFds.py   |  20 ++
>  .../Source/Python/GenFds/GenFdsGlobalVariable.py   | 174 ++
>  BaseTools/Source/Python/GenFds/GuidSection.py  | 168 +
>  .../Source/Python/GenFds/OptRomFileStatement.py|   4 +-
>  .../Source/Python/GenFds/OptRomInfStatement.py |  12 +-
>  BaseTools/Source/Python/GenFds/OptionRom.py|  25 +--
>  BaseTools/Source/Python/GenFds/Region.py   |  49 +++--
>  BaseTools/Source/Python/GenFds/Section.py  |   4 +-
>  BaseTools/Source/Python/GenFds/UiSection.py|   5 +-
>  BaseTools/Source/Python/GenFds/VerSection.py   |   9 +-
>  BaseTools/Source/Python/build/build.py |  48 -
>  24 files changed, 793 insertions(+), 411 deletions(-)
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [PATCH] MdeModulePkg/ScsiDisk: Return EFI_NO_MEDIA when no media presents

[Ruiyu Ni]

Current code always return EFI_MEDIA_CHANGED no matter the media
is removed from CD/DVD drive or the media is changed.
It doesn't strictly follow the UEFI Spec.
Update code to return EFI_NO_MEDIA when media is removed.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Star Zeng 
Cc: Hao A Wu 
---
 MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c | 41 
 1 file changed, 30 insertions(+), 11 deletions(-)

diff --git a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c 
b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
index 2289f20152..6a0a193556 100644
--- a/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
+++ b/MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c
@@ -568,6 +568,7 @@ ScsiDiskReadBlocks (
   MediaChange= FALSE;
   OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
   ScsiDiskDevice = SCSI_DISK_DEV_FROM_BLKIO (This);
+  Media  = ScsiDiskDevice->BlkIo.Media;
 
   if (!IS_DEVICE_FIXED(ScsiDiskDevice)) {
 
@@ -598,14 +599,17 @@ ScsiDiskReadBlocks (
>EraseBlock
);
   }
-  Status = EFI_MEDIA_CHANGED;
+  if (Media->MediaPresent) {
+Status = EFI_MEDIA_CHANGED;
+  } else {
+Status = EFI_NO_MEDIA;
+  }
   goto Done;
 }
   }
   //
   // Get the intrinsic block size
   //
-  Media   = ScsiDiskDevice->BlkIo.Media;
   BlockSize   = Media->BlockSize;
 
   NumberOfBlocks  = BufferSize / BlockSize;
@@ -700,6 +704,7 @@ ScsiDiskWriteBlocks (
   MediaChange= FALSE;
   OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
   ScsiDiskDevice = SCSI_DISK_DEV_FROM_BLKIO (This);
+  Media  = ScsiDiskDevice->BlkIo.Media;
 
   if (!IS_DEVICE_FIXED(ScsiDiskDevice)) {
 
@@ -730,14 +735,17 @@ ScsiDiskWriteBlocks (
>EraseBlock
);
   }
-  Status = EFI_MEDIA_CHANGED;
+  if (Media->MediaPresent) {
+Status = EFI_MEDIA_CHANGED;
+  } else {
+Status = EFI_NO_MEDIA;
+  }
   goto Done;
 }
   }
   //
   // Get the intrinsic block size
   //
-  Media   = ScsiDiskDevice->BlkIo.Media;
   BlockSize   = Media->BlockSize;
 
   NumberOfBlocks  = BufferSize / BlockSize;
@@ -922,6 +930,7 @@ ScsiDiskReadBlocksEx (
   MediaChange= FALSE;
   OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
   ScsiDiskDevice = SCSI_DISK_DEV_FROM_BLKIO2 (This);
+  Media  = ScsiDiskDevice->BlkIo.Media;
 
   if (!IS_DEVICE_FIXED(ScsiDiskDevice)) {
 
@@ -952,14 +961,17 @@ ScsiDiskReadBlocksEx (
>EraseBlock
);
   }
-  Status = EFI_MEDIA_CHANGED;
+  if (Media->MediaPresent) {
+Status = EFI_MEDIA_CHANGED;
+  } else {
+Status = EFI_NO_MEDIA;
+  }
   goto Done;
 }
   }
   //
   // Get the intrinsic block size
   //
-  Media   = ScsiDiskDevice->BlkIo2.Media;
   BlockSize   = Media->BlockSize;
 
   NumberOfBlocks  = BufferSize / BlockSize;
@@ -1081,6 +1093,7 @@ ScsiDiskWriteBlocksEx (
   MediaChange= FALSE;
   OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
   ScsiDiskDevice = SCSI_DISK_DEV_FROM_BLKIO2 (This);
+  Media  = ScsiDiskDevice->BlkIo.Media;
 
   if (!IS_DEVICE_FIXED(ScsiDiskDevice)) {
 
@@ -,14 +1124,17 @@ ScsiDiskWriteBlocksEx (
>EraseBlock
);
   }
-  Status = EFI_MEDIA_CHANGED;
+  if (Media->MediaPresent) {
+Status = EFI_MEDIA_CHANGED;
+  } else {
+Status = EFI_NO_MEDIA;
+  }
   goto Done;
 }
   }
   //
   // Get the intrinsic block size
   //
-  Media   = ScsiDiskDevice->BlkIo2.Media;
   BlockSize   = Media->BlockSize;
 
   NumberOfBlocks  = BufferSize / BlockSize;
@@ -1230,6 +1246,7 @@ ScsiDiskFlushBlocksEx (
   MediaChange= FALSE;
   OldTpl = gBS->RaiseTPL (TPL_CALLBACK);
   ScsiDiskDevice = SCSI_DISK_DEV_FROM_BLKIO2 (This);
+  Media  = ScsiDiskDevice->BlkIo.Media;
 
   if (!IS_DEVICE_FIXED(ScsiDiskDevice)) {
 
@@ -1260,13 +1277,15 @@ ScsiDiskFlushBlocksEx (
>EraseBlock
);
   }
-  Status = EFI_MEDIA_CHANGED;
+  if (Media->MediaPresent) {
+Status = EFI_MEDIA_CHANGED;
+  } else {
+Status = EFI_NO_MEDIA;
+  }
   goto Done;
 }
   }
 
-  Media = ScsiDiskDevice->BlkIo2.Media;
-
   if (!(Media->MediaPresent)) {
 Status = EFI_NO_MEDIA;
 goto Done;
-- 
2.15.0.gvfs.1.preview.4

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

[edk2] [Patch] MdeModulePkg/NetLib: Fix an error when AIP doesn't support network media state detection

[fanwang2]

AIP may not support detecting network media state, in this case,
should call NetLibDetectMedia to get media state. This patch is to
fix this issue.

Cc: Fu Siyuan 
Cc: Ye Ting 
Cc: Jiaxin Wu 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wang Fan 
---
 MdeModulePkg/Library/DxeNetLib/DxeNetLib.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c 
b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
index 1bfa33d..d75cca2 100644
--- a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
+++ b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
@@ -2603,10 +2603,28 @@ NetLibDetectMediaWaitTimeout (
   } else {
 
 if (MediaInfo != NULL) {
   FreePool (MediaInfo);
 }
+
+if (Status == EFI_UNSUPPORTED) {
+
+  //
+  // If gEfiAdapterInfoMediaStateGuid is not supported, call 
NetLibDetectMedia to get media state!
+  //
+  MediaPresent = TRUE;
+  Status = NetLibDetectMedia (ServiceHandle, );
+  if (!EFI_ERROR (Status)) {
+if (MediaPresent == TRUE) {
+  *MediaState = EFI_SUCCESS;
+} else {
+  *MediaState = EFI_NO_MEDIA;
+}
+  }
+  return Status;
+}
+
 return Status;
   }
 
   //
   // Loop to check media state 
-- 
1.9.5.msysgit.1

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