date:20160914

Re: [edk2] SMM PciExpressLib Instance

2016-09-14 Thread Kinney, Michael D

Felix,

Since you are doing math with the base address, shouldn't the type be UINTN
Instead of VOID *?

Please see MdePkg/Library/DxeRuntimePciExpressLib for an instance of this 
library class that caches the PCD into a global in a CONSTRUCTOR and uses
type UINTN.  Maybe this SMM lib instance should be based on 
DxeRuntimePciExpressLib
with the only difference being the removal of the register for runtime feature.

Thanks,

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Felix 
> Poludov
> Sent: Wednesday, September 14, 2016 12:29 PM
> To: edk2-devel@lists.01.org
> Subject: Re: [edk2] SMM PciExpressLib Instance
> 
> Resending with the patch (the patch was missing in the original e-mail).
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Felix 
> Poludov
> Sent: Wednesday, September 14, 2016 3:22 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] SMM PciExpressLib Instance
> 
> Dear MdePkg maintainer,
> 
> MdePkg does not provide a specialized instance of PciExpressLib for SMM 
> Drivers.
> It provides Base instance that is typically used by SMM Drivers.
> However, BasePciExpressLib calls PcdGet64 (PcdPciExpressBaseAddress) on every 
> PCI-E
> access
> and PcdPciExpressBaseAddress is declared in MdePkg.dec as a potentially 
> dynamic
> token.
> SMM Drivers cannot use BasePciExpressLib when PcdPciExpressBaseAddress is 
> dynamic.
> This patch adds SMM instance of PciExpressLib based on BasePciExpressLib.
> The only difference from BasePciExpressLib is a constructor that caches PCD 
> value
> into a local variable.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Felix Polyudov >
> 
> Thanks
> Felix
> 
> ==
> diff --git a/MdePkg/Library/SmmPciExpressLib/PciExpressLib.c
> b/MdePkg/Library/SmmPciExpressLib/PciExpressLib.c
> new file mode 100644
> index 000..5857b85
> --- /dev/null
> +++ b/MdePkg/Library/SmmPciExpressLib/PciExpressLib.c
> @@ -0,0 +1,1447 @@
> +/** @file
> +  Functions in this library instance make use of MMIO functions in IoLib to
> +  access memory mapped PCI configuration space.
> +
> +  All assertions for I/O operations are handled in MMIO functions in the 
> IoLib
> +  Library.
> +
> +  Copyright (c) 2006 - 2012, Intel Corporation. All rights reserved.
> +  Portions copyright (c) 2016, American Megatrends, Inc. 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 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +///
> +/// Module global that contains the base physical address of the PCI Express 
> MMIO
> range.
> +///
> +VOID *mSmmPciExpressLibPciExpressBaseAddress = 0;
> +
> +/**
> +  The constructor function caches the PCI Express Base Address
> +
> +  @param  ImageHandle   The firmware allocated handle for the EFI image.
> +  @param  SystemTable   A pointer to the EFI System Table.
> +
> +  @retval EFI_SUCCESS   The constructor completed successfully.
> +**/
> +EFI_STATUS
> +EFIAPI
> +SmmPciExpressLibConstructor (
> +  IN EFI_HANDLEImageHandle,
> +  IN EFI_SYSTEM_TABLE  *SystemTable
> +  )
> +{
> +  //
> +  // Cache the physical address of the PCI Express MMIO range into a module 
> global
> variable
> +  //
> +  mSmmPciExpressLibPciExpressBaseAddress = (VOID*)(UINTN) PcdGet64
> (PcdPciExpressBaseAddress);
> +
> +  return EFI_SUCCESS;
> +}
> +
> +/**
> +  Assert the validity of a PCI address. A valid PCI address should contain 
> 1's
> +  only in the low 28 bits.
> +
> +  @param  A The address to validate.
> +
> +**/
> +#define ASSERT_INVALID_PCI_ADDRESS(A) \
> +  ASSERT (((A) & ~0xfff) == 0)
> +
> +/**
> +  Registers a PCI device so PCI configuration registers may be accessed after
> +  SetVirtualAddressMap().
> +
> +  Registers the PCI device specified by Address so all the PCI configuration
> +  registers associated with that PCI device may be accessed after
> SetVirtualAddressMap()
> +  is called.
> +
> +  If Address > 0x0FFF, then ASSERT().
> +
> +  @param  Address The address that encodes the PCI Bus, Device, Function and
> +  Register.
> +
> +  @retval RETURN_SUCCESS   The PCI device was registered for runtime 
> access.
> +  @retval RETURN_UNSUPPORTED   An attempt was made to call this function
> +   after ExitBootServices().
> +  @retval RETURN_UNSUPPORTED   The resources required to access the PCI 
> device
> +   at

Re: [edk2] SMM PciExpressLib Instance

2016-09-14 Thread Felix Poludov

Resending with the patch (the patch was missing in the original e-mail).

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Felix 
Poludov
Sent: Wednesday, September 14, 2016 3:22 PM
To: edk2-devel@lists.01.org
Subject: [edk2] SMM PciExpressLib Instance

Dear MdePkg maintainer,

MdePkg does not provide a specialized instance of PciExpressLib for SMM Drivers.
It provides Base instance that is typically used by SMM Drivers.
However, BasePciExpressLib calls PcdGet64 (PcdPciExpressBaseAddress) on every 
PCI-E access
and PcdPciExpressBaseAddress is declared in MdePkg.dec as a potentially dynamic 
token.
SMM Drivers cannot use BasePciExpressLib when PcdPciExpressBaseAddress is 
dynamic.
This patch adds SMM instance of PciExpressLib based on BasePciExpressLib.
The only difference from BasePciExpressLib is a constructor that caches PCD 
value into a local variable.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Felix Polyudov >

Thanks
Felix

==
diff --git a/MdePkg/Library/SmmPciExpressLib/PciExpressLib.c 
b/MdePkg/Library/SmmPciExpressLib/PciExpressLib.c
new file mode 100644
index 000..5857b85
--- /dev/null
+++ b/MdePkg/Library/SmmPciExpressLib/PciExpressLib.c
@@ -0,0 +1,1447 @@
+/** @file
+  Functions in this library instance make use of MMIO functions in IoLib to
+  access memory mapped PCI configuration space.
+
+  All assertions for I/O operations are handled in MMIO functions in the IoLib
+  Library.
+
+  Copyright (c) 2006 - 2012, Intel Corporation. All rights reserved.
+  Portions copyright (c) 2016, American Megatrends, Inc. 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 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+///
+/// Module global that contains the base physical address of the PCI Express 
MMIO range.
+///
+VOID *mSmmPciExpressLibPciExpressBaseAddress = 0;
+
+/**
+  The constructor function caches the PCI Express Base Address 
+  
+  @param  ImageHandle   The firmware allocated handle for the EFI image.
+  @param  SystemTable   A pointer to the EFI System Table.
+  
+  @retval EFI_SUCCESS   The constructor completed successfully.
+**/
+EFI_STATUS
+EFIAPI
+SmmPciExpressLibConstructor (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  //
+  // Cache the physical address of the PCI Express MMIO range into a module 
global variable
+  //
+  mSmmPciExpressLibPciExpressBaseAddress = (VOID*)(UINTN) PcdGet64 
(PcdPciExpressBaseAddress);
+  
+  return EFI_SUCCESS;
+}
+
+/**
+  Assert the validity of a PCI address. A valid PCI address should contain 1's
+  only in the low 28 bits.
+
+  @param  A The address to validate.
+
+**/
+#define ASSERT_INVALID_PCI_ADDRESS(A) \
+  ASSERT (((A) & ~0xfff) == 0)
+
+/**
+  Registers a PCI device so PCI configuration registers may be accessed after 
+  SetVirtualAddressMap().
+  
+  Registers the PCI device specified by Address so all the PCI configuration 
+  registers associated with that PCI device may be accessed after 
SetVirtualAddressMap() 
+  is called.
+  
+  If Address > 0x0FFF, then ASSERT().
+
+  @param  Address The address that encodes the PCI Bus, Device, Function and
+  Register.
+  
+  @retval RETURN_SUCCESS   The PCI device was registered for runtime 
access.
+  @retval RETURN_UNSUPPORTED   An attempt was made to call this function 
+   after ExitBootServices().
+  @retval RETURN_UNSUPPORTED   The resources required to access the PCI 
device
+   at runtime could not be mapped.
+  @retval RETURN_OUT_OF_RESOURCES  There are not enough resources available to
+   complete the registration.
+
+**/
+RETURN_STATUS
+EFIAPI
+PciExpressRegisterForRuntimeAccess (
+  IN UINTN  Address
+  )
+{
+  ASSERT_INVALID_PCI_ADDRESS (Address);
+  return RETURN_UNSUPPORTED;
+}
+
+/**
+  Gets the base address of PCI Express.
+  
+  This internal functions retrieves PCI Express Base Address via a PCD entry
+  PcdPciExpressBaseAddress.
+  
+  @return The base address of PCI Express.
+
+**/
+VOID*
+GetPciExpressBaseAddress (
+  VOID
+  )
+{
+  return mSmmPciExpressLibPciExpressBaseAddress;
+}
+
+/**
+  Reads an 8-bit PCI configuration register.
+
+  Reads and returns the 8-bit PCI configuration register specified by Address.
+  This function must guarantee that all PCI read and write operations are
+  serialized.
+
+  If Address > 0x0FFF, then ASSERT().
+
+  @param

Re: [edk2] [PATCH] [MdePkg ] New Debug Message Levels

2016-09-14 Thread Felix Poludov

Resending with the patch (the patch was missing in the original e-mail).

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Felix 
Poludov
Sent: Wednesday, September 14, 2016 12:05 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [PATCH] [MdePkg ] New Debug Message Levels

Dear MdePkg maintainer,

DebugLib.h defines debug message levels. Some values such as DEBUG_ERROR and 
DEBUG_INFO define messages category, whereas other values such as DEBUG_BLKIO 
and DEBUG_VARIABLE define message domain.
This patch adds definitions for several additional message domains.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Felix Polyudov >

Thanks
Felix

==
diff --git a/MdePkg/Include/Library/DebugLib.h 
b/MdePkg/Include/Library/DebugLib.h
index 803872c..47549b7 100644
--- a/MdePkg/Include/Library/DebugLib.h
+++ b/MdePkg/Include/Library/DebugLib.h
@@ -54,6 +54,12 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #define DEBUG_CACHE 0x0020  // Memory range cachability changes
 #define DEBUG_VERBOSE   0x0040  // Detailed debug messages that may
 // significantly impact boot performance
+#define DEBUG_USB   0x0200  // USB Driver
+#define DEBUG_PCI   0x0800  // PCI Bus Driver
+#define DEBUG_CSM   0x2000  // Compatibility Support Module
+#define DEBUG_CPU   0x8000  // Processor Driver
+#define DEBUG_CHIPSET   0x0004  // Chipset/SoC Drivers
+#define DEBUG_PLATFORM  0x0080  // Platform/Board Drivers
 #define DEBUG_ERROR 0x8000  // Error
 
 //
@@ -75,6 +81,12 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #define EFI_D_LOADFILE  DEBUG_LOADFILE
 #define EFI_D_EVENT DEBUG_EVENT
 #define EFI_D_VERBOSE   DEBUG_VERBOSE
+#define EFI_D_USB   DEBUG_USB
+#define EFI_D_PCI   DEBUG_PCI
+#define EFI_D_CSM   DEBUG_CSM
+#define EFI_D_CPU   DEBUG_CPU
+#define EFI_D_CHIPSET   DEBUG_CHIPSET
+#define EFI_D_PLATFORM  DEBUG_PLATFORM
 #define EFI_D_ERROR DEBUG_ERROR
 
 /**
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index 606e2f1..eaae076 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -1883,15 +1883,21 @@
   #  BIT6  - Information message.
   #  BIT7  - Dispatcher message.
   #  BIT8  - Variable message.
+  #  BIT9  - USB Driver message.
   #  BIT10 - Boot Manager message.
+  #  BIT11 - PCI Bus Driver message.
   #  BIT12 - BlockIo Driver message.
+  #  BIT13 - Compatibility Support Module message.
   #  BIT14 - Network Driver message.
+  #  BIT15 - Processor Driver message.
   #  BIT16 - UNDI Driver message.
   #  BIT17 - LoadFile message.
+  #  BIT18 - Chipset/SoC Driver message.
   #  BIT19 - Event message.
   #  BIT20 - Global Coherency Database changes message.
   #  BIT21 - Memory range cachability changes message.
   #  BIT22 - Detailed debug message.
+  #  BIT23 - Platform/Board Driver message.
   #  BIT31 - Error message.
   # @Prompt Fixed Debug Message Print Level.
   
gEfiMdePkgTokenSpaceGuid.PcdFixedDebugPrintErrorLevel|0x|UINT32|0x30001016
@@ -1951,15 +1957,21 @@
   #  BIT6  - Information message.
   #  BIT7  - Dispatcher message.
   #  BIT8  - Variable message.
+  #  BIT9  - USB Driver message.
   #  BIT10 - Boot Manager message.
+  #  BIT11 - PCI Bus Driver message.
   #  BIT12 - BlockIo Driver message.
+  #  BIT13 - Compatibility Support Module message.
   #  BIT14 - Network Driver message.
+  #  BIT15 - Processor Driver message.
   #  BIT16 - UNDI Driver message.
   #  BIT17 - LoadFile message.
+  #  BIT18 - Chipset/SoC Driver message.
   #  BIT19 - Event message.
   #  BIT20 - Global Coherency Database changes message.
   #  BIT21 - Memory range cachability changes message.
   #  BIT22 - Detailed debug message.
+  #  BIT23 - Platform/Board Driver message.
   #  BIT31 - Error message.
   # @Prompt Debug Message Print Level.
   # @Expression  0x8002 | 
(gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel & 0x7F84AA00) == 0

Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary 
to American Megatrends, Inc.  This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited.  Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] MdeModulePkg/Xhci: add 1ms delay before access MMIO reg during reset

2016-09-14 Thread Kinney, Michael D

Andrew,

The 100 ns vs. 1 us differences are what I tried to highlight here and propose 
some helpers to hide that difference.

Do you have some alternatives in mind?

Mike

> -Original Message-
> From: af...@apple.com [mailto:af...@apple.com]
> Sent: Wednesday, September 14, 2016 10:37 AM
> To: Kinney, Michael D 
> Cc: Leif Lindholm ; Tian, Feng 
> ; edk2-
> de...@lists.01.org; Zeng, Star 
> Subject: Re: [edk2] [patch] MdeModulePkg/Xhci: add 1ms delay before access 
> MMIO reg
> during reset
> 
> 
> > On Sep 14, 2016, at 10:14 AM, Kinney, Michael D 
> >  wrote:
> >
> > Leif,
> >
> > MdePkg/Include/Library/UefiLib.h does have some helper macros for setting 
> > timer
> events periods
> > that are in 100 nS units:
> >
> >  #define EFI_TIMER_PERIOD_MICROSECONDS(Microseconds)
> MultU64x32((UINT64)(Microseconds), 10)
> >  #define EFI_TIMER_PERIOD_MILLISECONDS(Milliseconds)
> MultU64x32((UINT64)(Milliseconds), 1)
> >  #define EFI_TIMER_PERIOD_SECONDS(Seconds)   
> > MultU64x32((UINT64)(Seconds),
> 1000)
> >
> > I believe the examples you show are for use with the gBS->Stall() service 
> > which is
> in 1 uS units.
> >
> > Maybe we should consider some additional macros in UefiLib.h
> >
> >  #define EFI_STALL_PERIOD_MICROSECONDS(Microseconds) (Microseconds)
> >  #define EFI_STALL_PERIOD_MILLISECONDS(Milliseconds) ((Milliseconds) * 1000)
> >  #define EFI_STALL_PERIOD_SECONDS(Seconds)   ((Seconds) * 100)
> >
> > Or maybe some macros that actually do the call to gBS->Stall() too.
> >
> >  #define EFI_STALL_MICROSECONDS(Microseconds) gBS->Stall (Microseconds)
> >  #define EFI_STALL_MILLISECONDS(Milliseconds) gBS->Stall ((Milliseconds) * 
> > 1000)
> >  #define EFI_STALL_SECONDS(Seconds)   gBS->Stall ((Seconds) * 
> > 100)
> >
> > The other method of generating timed delays for PEI/DXE/SMM modules is 
> > using the
> > Services in MdePkg/Include/Library/TimerLib.h:
> >
> >  UINTN
> >  EFIAPI
> >  NanoSecondDelay (
> >IN  UINTN NanoSeconds
> >);
> >
> >  UINTN
> >  EFIAPI
> >  MicroSecondDelay (
> >IN  UINTN MicroSeconds
> >);
> >
> > If we wanted macros helper to use these services to match UEFI ones, maybe
> > add the following to TimerLib.h:
> >
> >  #define DELAY_NANOSECONDS(Nanoseconds)   NanoSecondDelay (Nanoseconds)
> >  #define DELAY_MICROSECONDS(Microseconds) MicroSecondDelay (Microseconds)
> >  #define DELAY_MILLISECONDS(Milliseconds) MicroSecondDelay ((Microseconds) 
> > * 1000)
> >  #define DELAY_SECONDS(Seconds)   MicroSecondDelay ((Microseconds) *
> 100)
> >
> > Do you think it would improve the maintenance of the code if macros like 
> > these
> > were used consistently?
> >
> 
> MIke,
> 
> We have some APIs that are 100ns vs. MIcroSeconds and that causes confusion 
> for
> folks. Maybe we should have some helpers for both APIs and comments about 
> which are
> which to help with the confusion. For example list the APIs that take the 
> 100ns
> argument, and list the APIs that take Microseconds.
> 
> Thanks,
> 
> Andrew Fish
> 
> 
> > Thanks,
> >
> > Mike
> >
> >
> >> -Original Message-
> >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif
> Lindholm
> >> Sent: Wednesday, September 14, 2016 6:09 AM
> >> To: Tian, Feng 
> >> Cc: edk2-devel@lists.01.org; Zeng, Star 
> >> Subject: Re: [edk2] [patch] MdeModulePkg/Xhci: add 1ms delay before access 
> >> MMIO
> reg
> >> during reset
> >>
> >> On Wed, Sep 14, 2016 at 09:37:13AM +0800, Feng Tian wrote:
> >>> Some XHCI host controllers require to have extra 1ms delay before
> >>> accessing any MMIO register during HC reset.
> >>
> >> Is this compliant with the XHCI specification or a bug workaround?
> >> I am not going to argue about the delay, but I would like to see it
> >> spelled out in the commit message.
> >>
> >>> Cc: Star Zeng 
> >>> Contributed-under: TianoCore Contribution Agreement 1.0
> >>> Signed-off-by: Feng Tian 
> >>> ---
> >>> MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c | 6 +-
> >>> 1 file changed, 5 insertions(+), 1 deletion(-)
> >>>
> >>> diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> >> b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> >>> index d0f2205..cb822a6 100644
> >>> --- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> >>> +++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> >>> @@ -2,7 +2,7 @@
> >>>
> >>>   The XHCI register operation routines.
> >>>
> >>> -Copyright (c) 2011 - 2015, Intel Corporation. All rights reserved.
> >>> +Copyright (c) 2011 - 2016, 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

Re: [edk2] [patch] MdeModulePkg/Xhci: add 1ms delay before access MMIO reg during reset

2016-09-14 Thread Andrew Fish


> On Sep 14, 2016, at 10:14 AM, Kinney, Michael D  
> wrote:
> 
> Leif,
> 
> MdePkg/Include/Library/UefiLib.h does have some helper macros for setting 
> timer events periods 
> that are in 100 nS units:
> 
>  #define EFI_TIMER_PERIOD_MICROSECONDS(Microseconds) 
> MultU64x32((UINT64)(Microseconds), 10)
>  #define EFI_TIMER_PERIOD_MILLISECONDS(Milliseconds) 
> MultU64x32((UINT64)(Milliseconds), 1)
>  #define EFI_TIMER_PERIOD_SECONDS(Seconds)   
> MultU64x32((UINT64)(Seconds), 1000)
> 
> I believe the examples you show are for use with the gBS->Stall() service 
> which is in 1 uS units.
> 
> Maybe we should consider some additional macros in UefiLib.h
> 
>  #define EFI_STALL_PERIOD_MICROSECONDS(Microseconds) (Microseconds)
>  #define EFI_STALL_PERIOD_MILLISECONDS(Milliseconds) ((Milliseconds) * 1000)
>  #define EFI_STALL_PERIOD_SECONDS(Seconds)   ((Seconds) * 100)
> 
> Or maybe some macros that actually do the call to gBS->Stall() too.
> 
>  #define EFI_STALL_MICROSECONDS(Microseconds) gBS->Stall (Microseconds)
>  #define EFI_STALL_MILLISECONDS(Milliseconds) gBS->Stall ((Milliseconds) * 
> 1000)
>  #define EFI_STALL_SECONDS(Seconds)   gBS->Stall ((Seconds) * 100)
> 
> The other method of generating timed delays for PEI/DXE/SMM modules is using 
> the 
> Services in MdePkg/Include/Library/TimerLib.h:
> 
>  UINTN
>  EFIAPI
>  NanoSecondDelay (
>IN  UINTN NanoSeconds
>);
> 
>  UINTN
>  EFIAPI
>  MicroSecondDelay (
>IN  UINTN MicroSeconds
>);
> 
> If we wanted macros helper to use these services to match UEFI ones, maybe 
> add the following to TimerLib.h:
> 
>  #define DELAY_NANOSECONDS(Nanoseconds)   NanoSecondDelay (Nanoseconds)
>  #define DELAY_MICROSECONDS(Microseconds) MicroSecondDelay (Microseconds)
>  #define DELAY_MILLISECONDS(Milliseconds) MicroSecondDelay ((Microseconds) * 
> 1000)
>  #define DELAY_SECONDS(Seconds)   MicroSecondDelay ((Microseconds) * 
> 100) 
> 
> Do you think it would improve the maintenance of the code if macros like these
> were used consistently?
> 

MIke,

We have some APIs that are 100ns vs. MIcroSeconds and that causes confusion for 
folks. Maybe we should have some helpers for both APIs and comments about which 
are which to help with the confusion. For example list the APIs that take the 
100ns argument, and list the APIs that take Microseconds.

Thanks,

Andrew Fish


> Thanks,
> 
> Mike
> 
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif 
>> Lindholm
>> Sent: Wednesday, September 14, 2016 6:09 AM
>> To: Tian, Feng 
>> Cc: edk2-devel@lists.01.org; Zeng, Star 
>> Subject: Re: [edk2] [patch] MdeModulePkg/Xhci: add 1ms delay before access 
>> MMIO reg
>> during reset
>> 
>> On Wed, Sep 14, 2016 at 09:37:13AM +0800, Feng Tian wrote:
>>> Some XHCI host controllers require to have extra 1ms delay before
>>> accessing any MMIO register during HC reset.
>> 
>> Is this compliant with the XHCI specification or a bug workaround?
>> I am not going to argue about the delay, but I would like to see it
>> spelled out in the commit message.
>> 
>>> Cc: Star Zeng 
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Feng Tian 
>>> ---
>>> MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c | 6 +-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>> 
>>> diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
>> b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
>>> index d0f2205..cb822a6 100644
>>> --- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
>>> +++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
>>> @@ -2,7 +2,7 @@
>>> 
>>>   The XHCI register operation routines.
>>> 
>>> -Copyright (c) 2011 - 2015, Intel Corporation. All rights reserved.
>>> +Copyright (c) 2011 - 2016, 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
>>> @@ -687,6 +687,10 @@ XhcResetHC (
>>>   if ((Xhc->DebugCapSupOffset == 0x) || ((XhcReadExtCapReg (Xhc, 
>>> Xhc-
>>> DebugCapSupOffset) & 0xFF) != XHC_CAP_USB_DEBUG) ||
>>>   ((XhcReadExtCapReg (Xhc, Xhc->DebugCapSupOffset + XHC_DC_DCCTRL) & 
>>> BIT0) ==
>> 0)) {
>>> XhcSetOpRegBit (Xhc, XHC_USBCMD_OFFSET, XHC_USBCMD_RESET);
>>> +//
>>> +// some XHCI host controllers require to have extra 1ms delay before 
>>> accessing
>> any MMIO register during reset.
>>> +//
>>> +gBS->Stall (XHC_1_MILLISECOND);
>> 
>> OK, so this is not actually a comment on this patch, but why do we
>> have so many separate definitions of how many microseconds go in a
>> milisecond or second?
>> 
>> USB_BUS_1_MILLISECOND (Pei and Dxe)
>> XHC_1_MILLISECOND (Pei

Re: [edk2] [patch] MdeModulePkg/Xhci: add 1ms delay before access MMIO reg during reset

2016-09-14 Thread Kinney, Michael D

Leif,

MdePkg/Include/Library/UefiLib.h does have some helper macros for setting timer 
events periods 
that are in 100 nS units:

  #define EFI_TIMER_PERIOD_MICROSECONDS(Microseconds) 
MultU64x32((UINT64)(Microseconds), 10)
  #define EFI_TIMER_PERIOD_MILLISECONDS(Milliseconds) 
MultU64x32((UINT64)(Milliseconds), 1)
  #define EFI_TIMER_PERIOD_SECONDS(Seconds)   
MultU64x32((UINT64)(Seconds), 1000)

I believe the examples you show are for use with the gBS->Stall() service which 
is in 1 uS units.

Maybe we should consider some additional macros in UefiLib.h

  #define EFI_STALL_PERIOD_MICROSECONDS(Microseconds) (Microseconds)
  #define EFI_STALL_PERIOD_MILLISECONDS(Milliseconds) ((Milliseconds) * 1000)
  #define EFI_STALL_PERIOD_SECONDS(Seconds)   ((Seconds) * 100)

Or maybe some macros that actually do the call to gBS->Stall() too.

  #define EFI_STALL_MICROSECONDS(Microseconds) gBS->Stall (Microseconds)
  #define EFI_STALL_MILLISECONDS(Milliseconds) gBS->Stall ((Milliseconds) * 
1000)
  #define EFI_STALL_SECONDS(Seconds)   gBS->Stall ((Seconds) * 100)

The other method of generating timed delays for PEI/DXE/SMM modules is using 
the 
Services in MdePkg/Include/Library/TimerLib.h:

  UINTN
  EFIAPI
  NanoSecondDelay (
IN  UINTN NanoSeconds
);

  UINTN
  EFIAPI
  MicroSecondDelay (
IN  UINTN MicroSeconds
);

If we wanted macros helper to use these services to match UEFI ones, maybe 
add the following to TimerLib.h:

  #define DELAY_NANOSECONDS(Nanoseconds)   NanoSecondDelay (Nanoseconds)
  #define DELAY_MICROSECONDS(Microseconds) MicroSecondDelay (Microseconds)
  #define DELAY_MILLISECONDS(Milliseconds) MicroSecondDelay ((Microseconds) * 
1000)
  #define DELAY_SECONDS(Seconds)   MicroSecondDelay ((Microseconds) * 
100) 

Do you think it would improve the maintenance of the code if macros like these
were used consistently?

Thanks,

Mike


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif 
> Lindholm
> Sent: Wednesday, September 14, 2016 6:09 AM
> To: Tian, Feng 
> Cc: edk2-devel@lists.01.org; Zeng, Star 
> Subject: Re: [edk2] [patch] MdeModulePkg/Xhci: add 1ms delay before access 
> MMIO reg
> during reset
> 
> On Wed, Sep 14, 2016 at 09:37:13AM +0800, Feng Tian wrote:
> > Some XHCI host controllers require to have extra 1ms delay before
> > accessing any MMIO register during HC reset.
> 
> Is this compliant with the XHCI specification or a bug workaround?
> I am not going to argue about the delay, but I would like to see it
> spelled out in the commit message.
> 
> > Cc: Star Zeng 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Feng Tian 
> > ---
> >  MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c | 6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> > index d0f2205..cb822a6 100644
> > --- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> > +++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> > @@ -2,7 +2,7 @@
> >
> >The XHCI register operation routines.
> >
> > -Copyright (c) 2011 - 2015, Intel Corporation. All rights reserved.
> > +Copyright (c) 2011 - 2016, 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
> > @@ -687,6 +687,10 @@ XhcResetHC (
> >if ((Xhc->DebugCapSupOffset == 0x) || ((XhcReadExtCapReg (Xhc, 
> > Xhc-
> >DebugCapSupOffset) & 0xFF) != XHC_CAP_USB_DEBUG) ||
> >((XhcReadExtCapReg (Xhc, Xhc->DebugCapSupOffset + XHC_DC_DCCTRL) & 
> > BIT0) ==
> 0)) {
> >  XhcSetOpRegBit (Xhc, XHC_USBCMD_OFFSET, XHC_USBCMD_RESET);
> > +//
> > +// some XHCI host controllers require to have extra 1ms delay before 
> > accessing
> any MMIO register during reset.
> > +//
> > +gBS->Stall (XHC_1_MILLISECOND);
> 
> OK, so this is not actually a comment on this patch, but why do we
> have so many separate definitions of how many microseconds go in a
> milisecond or second?
> 
> USB_BUS_1_MILLISECOND (Pei and Dxe)
> XHC_1_MILLISECOND (Pei and Dxe)
> EHC_1_MILLISECOND (Pei and Dxe)
> UHC_1_MILLISECOND (Dxe, Pei defines STALL_1_MILLI_SECOND instead)
> 
> And IdeBusPei/PciBusDxe do similar things.
> 
> Could we add something common to Base.h instead, like the SIZE_ ones,
> droppping a lot of duplication, gaining uniformity, and correcting
> spelling?
> 
> /
> Leif
> 
> >  Status = XhcWaitOpRegBit (Xhc, XHC_USBCMD_OFFSET, XHC_USBCMD_RESET, 
> > FALSE,
> Timeout);
> >}
> >
> > --
> > 2.7.1.windows.2
> >
> > ___
> >

[edk2] [PATCH] [MdePkg ] New Debug Message Levels

2016-09-14 Thread Felix Poludov

Dear MdePkg maintainer,

DebugLib.h defines debug message levels. Some values such as DEBUG_ERROR and 
DEBUG_INFO define messages category, whereas other values such as DEBUG_BLKIO 
and DEBUG_VARIABLE define message domain.
This patch adds definitions for several additional message domains.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Felix Polyudov >

Thanks
Felix

Please consider the environment before printing this email.

The information contained in this message may be confidential and proprietary 
to American Megatrends, Inc.  This communication is intended to be read only by 
the individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any distribution of this message, in any form, is strictly prohibited.  Please 
promptly notify the sender by reply e-mail or by telephone at 770-246-8600, and 
then delete or destroy all copies of the transmission.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] GenFds.py error CODE: Tools code failure

2016-09-14 Thread Vladimir Olovyannikov

Hi Liming,



Exactly.

I added the .inf file for the shell application I worked on, thinking that
it would be an .efi file, and only later
I recognized it should actually be a Shell library (I derived from tftp
command source as an example)…



Thank you,

Vladimir



*From:* Gao, Liming [mailto:liming@intel.com]
*Sent:* Tuesday, September 13, 2016 8:23 PM
*To:* Vladimir Olovyannikov
*Cc:* edk2-devel@lists.01.org
*Subject:* RE: [edk2] GenFds.py error CODE: Tools code failure



Vladimir:

  You add one library INF into FDF file, then cause this issue?



Thanks

Liming

*From:* Vladimir Olovyannikov [mailto:vladimir.olovyanni...@broadcom.com]
*Sent:* Wednesday, September 14, 2016 11:20 AM
*To:* Gao, Liming 
*Cc:* edk2-devel@lists.01.org 
*Subject:* RE: [edk2] GenFds.py error CODE: Tools code failure



Hi,
Thanks for reply. I found the reason: I should have add the Shell
application (which is actually a library) to the ShellPkg instead of trying
to add it in the .fdf.

Thank you,
Vladimir



On Sep 13, 2016 8:17 PM, "Gao, Liming"  wrote:

Hi,
  The below message is caused by the missing map file of the driver. In
build output directory /uefi/Build/NS2Pkg/DEBUG_GCC5,  please check whether
the map file is generated for each driver.

Thanks
Liming
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Vladimir Olovyannikov
> Sent: Wednesday, September 14, 2016 3:51 AM
> To: edk2-de...@ml01.01.org
> Subject: [edk2] GenFds.py error CODE: Tools code failure
>
> Hello,
>
> I have just got this error building UEFI for AARCH64.
>
> Here is an excerpt from the output:
>
> Fd File Name:BL33_AP_UEFI
>
> Generate Region at Offset 0x0
>Region Size = 0xF
>Region Name = FV
>
> Generating FVMAIN_COMPACT FV
> 
> Generating FVMAIN FV
> 
> 
> 
>
>
> GenFds.py...
>  : error C0DE: Tools code failure
> Please send email to edk2-devel@lists.01.org for help, attaching
> following call stack trace!
>
> Traceback (most recent call last):
>   File
> "/uefi/BaseTools/BinWrappers/PosixLike/../../Source/Python/GenFds/GenF
> ds.p
> y", line 307, in main
> GenFds.GenFd('', FdfParserObj, BuildWorkSpace, ArchList)
>   File
> "/uefi/BaseTools/BinWrappers/PosixLike/../../Source/Python/GenFds/GenF
> ds.p
> y", line 553, in GenFd
> FdObj.GenFd()
>   File "/uefi/BaseTools/Source/Python/GenFds/Fd.py", line 93, in GenFd
> RegionObj.AddToBuffer (TempFdBuffer, self.BaseAddress,
> self.BlockSizeList, self.ErasePolarity, GenFds.ImageBinDict,
> self.vtfRawDict, self.DefineVarDict)
>   File "/uefi/BaseTools/Source/Python/GenFds/Region.py", line 127, in
> AddToBuffer
> FvObj.AddToBuffer(FvBuffer, FvBaseAddress, BlockSize, BlockNum,
> ErasePolarity, vtfDict)
>   File "/uefi/BaseTools/Source/Python/GenFds/Fv.py", line 115, in
> AddToBuffer
> FileName = FfsFile.GenFfs(MacroDict, FvParentAddr=BaseAddress)
>   File "/uefi/BaseTools/Source/Python/GenFds/FfsFileStatement.py", line
> 156, in GenFfs
> sectList, align = section.GenSection(OutputDir, self.NameGuid,
> SecIndex, self.KeyStringList, None, Dict)
>   File "/uefi/BaseTools/Source/Python/GenFds/GuidSection.py", line 97, in
> GenSection
> ReturnSectList, align = Sect.GenSection(OutputPath, ModuleName,
> SecIndex, KeyStringList, FfsInf, Dict)
>   File "/uefi/BaseTools/Source/Python/GenFds/FvImageSection.py", line 101,
> in GenSection
> FvFileName = Fv.AddToBuffer(Buffer, self.FvAddr, MacroDict = Dict)
>   File "/uefi/BaseTools/Source/Python/GenFds/Fv.py", line 115, in
> AddToBuffer
> FileName = FfsFile.GenFfs(MacroDict, FvParentAddr=BaseAddress)
>   File "/uefi/BaseTools/Source/Python/GenFds/FfsInfStatement.py", line
> 480, in GenFfs
> InputSectList, InputSectAlignments =
> self.__GenComplexFileSection__(Rule, FvChildAddr, FvParentAddr)
>   File "/uefi/BaseTools/Source/Python/GenFds/FfsInfStatement.py", line
> 948, in __GenComplexFileSection__
> self.__GenUniVfrOffsetFile (VfrUniOffsetList, UniVfrOffsetFileName)
>   File "/uefi/BaseTools/Source/Python/GenFds/FfsInfStatement.py", line
> 1052, in __GenUniVfrOffsetFile
> for Item in VfrUniOffsetList:
> TypeError: 'NoneType' object is not iterable
>
> #
>
>
> build.py...
>  : error 7000: Failed to execute command
> GenFds -f /uefi/BroadcomPlatformPkg/NS2Pkg/NS2Pkg.fdf
> --conf=/uefi/Conf -o /uefi/Build/NS2Pkg/DEBUG_GCC5 -t GCC5 -b DEBUG -p
> /uefi/BroadcomPlatformPkg/NS2Pkg/NS2Pkg.dsc -a AARCH64 -D
> "EFI_SOURCE=/uefi/EdkCompatibilityPkg" -D
> "EDK_SOURCE=/uefi/EdkCompatibilityPkg" -D "TOOL_CHAIN_TAG=GCC5" -D
> "TOOLCHAIN=GCC5" -D "TARGET=DEBUG" -D "FAMILY=GCC" -D
> "WORKSPACE=/uefi" -D
> "EDK_TOOLS_PATH=/uefi/BaseTools" -D "ARCH=AARCH64" -D
> "ECP_SOURCE=/uefi/EdkCompatibilityPkg" [/uefi]
>
> - Failed -
>
> Please let me know if

Re: [edk2] [Patch] NetworkPkg: Correct the DNS token return status by RCODE

2016-09-14 Thread Subramanian, Sriram (EG Servers Platform SW)

Jiaxin,

-  Status = EFI_ABORTED;
-  goto ON_EXIT;
+//
+// The domain name referenced in the query does not exist.
+//
+if (DnsHeader->Flags.Bits.RCode == DNS_FLAGS_RCODE_NAME_ERROR) {
+  Status = EFI_NOT_FOUND; 
+} else {
+  Status = EFI_DEVICE_ERROR;
+}
+
+goto ON_COMPLETE;

This change looks good to me. Thanks for addressing this. Nagaraj is on 
vacation and will test it early next week and provide feedback.

Reviewed-by: Sriram Subramanian 

Thanks,
Sriram.

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiaxin Wu
Sent: Wednesday, September 14, 2016 12:16 PM
To: edk2-devel@lists.01.org
Cc: Ye Ting ; Fu Siyuan 
Subject: [edk2] [Patch] NetworkPkg: Correct the DNS token return status by RCODE

When HostNameToIp() and GeneralLookUp() are called with a invalid
host name, RCODE (4 bit field is set as part of responses) error
will returned in packet to identify the domain name referenced in
the query does not exist. So, EFI_NOT_FOUND should be returned
directly.

Current implementation only check the RCODE in successful condition.
Need update the code for more error check according to RFC 1035 4.1.1
section.

Cc: Hegde Nagaraj P 
Cc: Fu Siyuan 
Cc: Ye Ting 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 NetworkPkg/DnsDxe/DnsImpl.c | 104 +---
 1 file changed, 40 insertions(+), 64 deletions(-)

diff --git a/NetworkPkg/DnsDxe/DnsImpl.c b/NetworkPkg/DnsDxe/DnsImpl.c
index cfaa4c7..3f3b756 100644
--- a/NetworkPkg/DnsDxe/DnsImpl.c
+++ b/NetworkPkg/DnsDxe/DnsImpl.c
@@ -1230,12 +1230,20 @@ ParseDnsResponse (
   //
   // Continue Check Some Errors.
   //
   if (DnsHeader->Flags.Bits.RCode != DNS_FLAGS_RCODE_NO_ERROR || 
DnsHeader->AnswersNum < 1 || \
   DnsHeader->Flags.Bits.QR != DNS_FLAGS_QR_RESPONSE) {
-  Status = EFI_ABORTED;
-  goto ON_EXIT;
+//
+// The domain name referenced in the query does not exist.
+//
+if (DnsHeader->Flags.Bits.RCode == DNS_FLAGS_RCODE_NAME_ERROR) {
+  Status = EFI_NOT_FOUND; 
+} else {
+  Status = EFI_DEVICE_ERROR;
+}
+
+goto ON_COMPLETE;
   }
   
   //
   // Do some buffer allocations.
   //
@@ -1404,27 +1412,12 @@ ParseDnsResponse (
 
 HostAddr4 = Dns4TokenEntry->Token->RspData.H2AData->IpList;
 AnswerData = (UINT8 *) AnswerSection + sizeof (*AnswerSection);
 CopyMem ([IpCount], AnswerData, sizeof (EFI_IPv4_ADDRESS));
 
-//
-// Update DNS cache dynamically.
-//
-if (Dns4CacheEntry != NULL) {
-  if (Dns4CacheEntry->HostName != NULL) {
-FreePool (Dns4CacheEntry->HostName);
-  }
-
-  if (Dns4CacheEntry->IpAddress != NULL) {
-FreePool (Dns4CacheEntry->IpAddress);
-  }
-  
-  FreePool (Dns4CacheEntry);
-}
-
 // 
-// Allocate new CacheEntry pool.
+// Allocate new CacheEntry pool to update DNS cache dynamically.
 //
 Dns4CacheEntry = AllocateZeroPool (sizeof (EFI_DNS4_CACHE_ENTRY));
 if (Dns4CacheEntry == NULL) {
   Status = EFI_OUT_OF_RESOURCES;
   goto ON_EXIT;
@@ -1446,11 +1439,23 @@ ParseDnsResponse (
   Dns4CacheEntry->Timeout = MIN (CNameTtl, AnswerSection->Ttl);
 } else {
   Dns4CacheEntry->Timeout = MAX (CNameTtl, AnswerSection->Ttl);
 }
 
-UpdateDns4Cache (>Dns4CacheList, FALSE, TRUE, 
*Dns4CacheEntry);  
+UpdateDns4Cache (>Dns4CacheList, FALSE, TRUE, 
*Dns4CacheEntry);
+
+// 
+// Free allocated CacheEntry pool.
+//
+FreePool (Dns4CacheEntry->HostName);
+Dns4CacheEntry->HostName = NULL;
+
+FreePool (Dns4CacheEntry->IpAddress);
+Dns4CacheEntry->IpAddress = NULL;
+
+FreePool (Dns4CacheEntry);
+Dns4CacheEntry = NULL;
 
 IpCount ++;
 Status = EFI_SUCCESS;
 break;
   case DNS_TYPE_:
@@ -1461,27 +1466,12 @@ ParseDnsResponse (
 
 HostAddr6 = Dns6TokenEntry->Token->RspData.H2AData->IpList;
 AnswerData = (UINT8 *) AnswerSection + sizeof (*AnswerSection);
 CopyMem ([IpCount], AnswerData, sizeof (EFI_IPv6_ADDRESS));
 
-//
-// Update DNS cache dynamically.
-//
-if (Dns6CacheEntry != NULL) {
-  if (Dns6CacheEntry->HostName != NULL) {
-FreePool (Dns6CacheEntry->HostName);
-  }
-
-  if (Dns6CacheEntry->IpAddress != NULL) {
-FreePool (Dns6CacheEntry->IpAddress);
-  }
-  
-  FreePool (Dns6CacheEntry);
-}
-
 // 
-// Allocate new CacheEntry pool.
+// Allocate new CacheEntry pool to update DNS cache

Re: [edk2] [PATCH] ArmPkg/DefaultExceptionHandlerLib: improve formatting of backtrace

2016-09-14 Thread Leif Lindholm

On Wed, Sep 14, 2016 at 02:28:37PM +0100, Ard Biesheuvel wrote:
> On 12 September 2016 at 09:32, Ard Biesheuvel  
> wrote:
> > On 10 September 2016 at 01:23, Andrew Fish  wrote:
> >>
> >>
> >>> On Sep 9, 2016, at 11:00 AM, Ard Biesheuvel  
> >>> wrote:
> >>>
> >>> Implement the backtrace formattting suggested by Andrew, i.e.,
> >>>
> >>>  IRQ Exception at 0x5BE182B0
> >>>  PC 0x5BE182B0 (0x5BE14000+0x42B0) [ 0] ArmCpuDxe.dll
> >>>  PC 0x5BE15770 (0x5BE14000+0x1770) [ 0] ArmCpuDxe.dll
> >>>  PC 0x5EF08CC8 (0x5EEEB000+0x0001DCC8) [ 1] DxeCore.dll
> >>>  PC 0x5EF09008 (0x5EEEB000+0x0001E008) [ 1] DxeCore.dll
> >>>  PC 0x5EEF6ACC (0x5EEEB000+0xBACC) [ 1] DxeCore.dll
> >>>  PC 0x5EF0963C (0x5EEEB000+0x0001E63C) [ 1] DxeCore.dll
> >>>  PC 0x5EF09A38 (0x5EEEB000+0x0001EA38) [ 1] DxeCore.dll
> >>>  PC 0x5EF01560 (0x5EEEB000+0x00016560) [ 1] DxeCore.dll
> >>>  PC 0x5EF02FB4 (0x5EEEB000+0x00017FB4) [ 1] DxeCore.dll
> >>>  PC 0x5EF03098 (0x5EEEB000+0x00018098) [ 1] DxeCore.dll
> >>>  PC 0x5EF0460C (0x5EEEB000+0x0001960C) [ 1] DxeCore.dll
> >>>  PC 0x5EF005C4 (0x5EEEB000+0x000155C4) [ 1] DxeCore.dll
> >>>  PC 0x5EF00360 (0x5EEEB000+0x00015360) [ 1] DxeCore.dll
> >>>  PC 0x5EF003C8 (0x5EEEB000+0x000153C8) [ 1] DxeCore.dll
> >>>  PC 0x5EF128D0 (0x5EEEB000+0x000278D0) [ 1] DxeCore.dll
> >>>  PC 0x5EF12930 (0x5EEEB000+0x00027930) [ 1] DxeCore.dll
> >>>  PC 0x5EEEF594 (0x5EEEB000+0x4594) [ 1] DxeCore.dll
> >>>  PC 0x5EF0CF18 (0x5EEEB000+0x00021F18) [ 1] DxeCore.dll
> >>>  PC 0x5EF1A310 (0x5EEEB000+0x0002F310) [ 1] DxeCore.dll
> >>>  PC 0x5EEF1808 (0x5EEEB000+0x6808) [ 1] DxeCore.dll
> >>>  PC 0x5EEF1E48 (0x5EEEB000+0x6E48) [ 1] DxeCore.dll
> >>>  PC 0x5EF0A838 (0x5EEEB000+0x0001F838) [ 1] DxeCore.dll
> >>>  PC 0x5EEED70C (0x5EEEB000+0x270C) [ 1] DxeCore.dll
> >>>  PC 0x5EEEC93C (0x5EEEB000+0x193C) [ 1] DxeCore.dll
> >>>  PC 0x5EEEC024 (0x5EEEB000+0x1024) [ 1] DxeCore.dll
> >>>
> >>>  [ 0] 
> >>> /home/ard/build/edk2/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/ArmPkg/Drivers/CpuDxe/CpuDxe/DEBUG/ArmCpuDxe.dll
> >>>  [ 1] 
> >>> /home/ard/build/edk2/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
> >>>
> >>
> 
> Leif: any comments?

Was just hanging back to see if there was more discussion forthcoming.
Looks good to me:
Reviewed-by: Leif Lindholm 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ArmPkg/DefaultExceptionHandlerLib: improve formatting of backtrace

2016-09-14 Thread Ard Biesheuvel

On 12 September 2016 at 09:32, Ard Biesheuvel  wrote:
> On 10 September 2016 at 01:23, Andrew Fish  wrote:
>>
>>
>>> On Sep 9, 2016, at 11:00 AM, Ard Biesheuvel  
>>> wrote:
>>>
>>> Implement the backtrace formattting suggested by Andrew, i.e.,
>>>
>>>  IRQ Exception at 0x5BE182B0
>>>  PC 0x5BE182B0 (0x5BE14000+0x42B0) [ 0] ArmCpuDxe.dll
>>>  PC 0x5BE15770 (0x5BE14000+0x1770) [ 0] ArmCpuDxe.dll
>>>  PC 0x5EF08CC8 (0x5EEEB000+0x0001DCC8) [ 1] DxeCore.dll
>>>  PC 0x5EF09008 (0x5EEEB000+0x0001E008) [ 1] DxeCore.dll
>>>  PC 0x5EEF6ACC (0x5EEEB000+0xBACC) [ 1] DxeCore.dll
>>>  PC 0x5EF0963C (0x5EEEB000+0x0001E63C) [ 1] DxeCore.dll
>>>  PC 0x5EF09A38 (0x5EEEB000+0x0001EA38) [ 1] DxeCore.dll
>>>  PC 0x5EF01560 (0x5EEEB000+0x00016560) [ 1] DxeCore.dll
>>>  PC 0x5EF02FB4 (0x5EEEB000+0x00017FB4) [ 1] DxeCore.dll
>>>  PC 0x5EF03098 (0x5EEEB000+0x00018098) [ 1] DxeCore.dll
>>>  PC 0x5EF0460C (0x5EEEB000+0x0001960C) [ 1] DxeCore.dll
>>>  PC 0x5EF005C4 (0x5EEEB000+0x000155C4) [ 1] DxeCore.dll
>>>  PC 0x5EF00360 (0x5EEEB000+0x00015360) [ 1] DxeCore.dll
>>>  PC 0x5EF003C8 (0x5EEEB000+0x000153C8) [ 1] DxeCore.dll
>>>  PC 0x5EF128D0 (0x5EEEB000+0x000278D0) [ 1] DxeCore.dll
>>>  PC 0x5EF12930 (0x5EEEB000+0x00027930) [ 1] DxeCore.dll
>>>  PC 0x5EEEF594 (0x5EEEB000+0x4594) [ 1] DxeCore.dll
>>>  PC 0x5EF0CF18 (0x5EEEB000+0x00021F18) [ 1] DxeCore.dll
>>>  PC 0x5EF1A310 (0x5EEEB000+0x0002F310) [ 1] DxeCore.dll
>>>  PC 0x5EEF1808 (0x5EEEB000+0x6808) [ 1] DxeCore.dll
>>>  PC 0x5EEF1E48 (0x5EEEB000+0x6E48) [ 1] DxeCore.dll
>>>  PC 0x5EF0A838 (0x5EEEB000+0x0001F838) [ 1] DxeCore.dll
>>>  PC 0x5EEED70C (0x5EEEB000+0x270C) [ 1] DxeCore.dll
>>>  PC 0x5EEEC93C (0x5EEEB000+0x193C) [ 1] DxeCore.dll
>>>  PC 0x5EEEC024 (0x5EEEB000+0x1024) [ 1] DxeCore.dll
>>>
>>>  [ 0] 
>>> /home/ard/build/edk2/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/ArmPkg/Drivers/CpuDxe/CpuDxe/DEBUG/ArmCpuDxe.dll
>>>  [ 1] 
>>> /home/ard/build/edk2/Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
>>>
>>

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

Re: [edk2] [patch] MdeModulePkg/Xhci: add 1ms delay before access MMIO reg during reset

2016-09-14 Thread Leif Lindholm

On Wed, Sep 14, 2016 at 09:37:13AM +0800, Feng Tian wrote:
> Some XHCI host controllers require to have extra 1ms delay before
> accessing any MMIO register during HC reset.

Is this compliant with the XHCI specification or a bug workaround?
I am not going to argue about the delay, but I would like to see it
spelled out in the commit message.

> Cc: Star Zeng 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Feng Tian 
> ---
>  MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c 
> b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> index d0f2205..cb822a6 100644
> --- a/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> +++ b/MdeModulePkg/Bus/Pci/XhciDxe/XhciReg.c
> @@ -2,7 +2,7 @@
>  
>The XHCI register operation routines.
>  
> -Copyright (c) 2011 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2011 - 2016, 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
> @@ -687,6 +687,10 @@ XhcResetHC (
>if ((Xhc->DebugCapSupOffset == 0x) || ((XhcReadExtCapReg (Xhc, 
> Xhc->DebugCapSupOffset) & 0xFF) != XHC_CAP_USB_DEBUG) ||
>((XhcReadExtCapReg (Xhc, Xhc->DebugCapSupOffset + XHC_DC_DCCTRL) & 
> BIT0) == 0)) {
>  XhcSetOpRegBit (Xhc, XHC_USBCMD_OFFSET, XHC_USBCMD_RESET);
> +//
> +// some XHCI host controllers require to have extra 1ms delay before 
> accessing any MMIO register during reset.
> +//
> +gBS->Stall (XHC_1_MILLISECOND);

OK, so this is not actually a comment on this patch, but why do we
have so many separate definitions of how many microseconds go in a
milisecond or second?

USB_BUS_1_MILLISECOND (Pei and Dxe)
XHC_1_MILLISECOND (Pei and Dxe)
EHC_1_MILLISECOND (Pei and Dxe)
UHC_1_MILLISECOND (Dxe, Pei defines STALL_1_MILLI_SECOND instead)

And IdeBusPei/PciBusDxe do similar things.

Could we add something common to Base.h instead, like the SIZE_ ones,
droppping a lot of duplication, gaining uniformity, and correcting
spelling?

/
Leif

>  Status = XhcWaitOpRegBit (Xhc, XHC_USBCMD_OFFSET, XHC_USBCMD_RESET, 
> FALSE, Timeout);
>}
>  
> -- 
> 2.7.1.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] Recall: OVMF compile error

2016-09-14 Thread Chen, Farrah

Chen, Farrah would like to recall the message, "OVMF compile error".
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] Recall: OVMF compile error

2016-09-14 Thread Chen, Farrah

Chen, Farrah would like to recall the message, "OVMF compile error".
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch V2] BaseTools: Fix the bug to handle the read-only file

2016-09-14 Thread Gao, Liming

Reviewed-by: Liming Gao 

> -Original Message-
> From: Zhu, Yonghong
> Sent: Wednesday, September 14, 2016 2:24 PM
> To: edk2-devel@lists.01.org
> Cc: Gao, Liming 
> Subject: [Patch V2] BaseTools: Fix the bug to handle the read-only file
> 
> change the 'r+b' to 'rb' for some file's open, since these files we only
> read it and no need to write. It can fix the bug that the file's attribute
> had been set to read-only.
> 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Yonghong Zhu 
> ---
>  BaseTools/Source/Python/GenFds/FfsFileStatement.py | 2 +-
>  BaseTools/Source/Python/GenFds/Fv.py   | 2 +-
>  BaseTools/Source/Python/GenFds/FvImageSection.py   | 4 ++--
>  BaseTools/Source/Python/GenFds/Region.py   | 4 ++--
>  4 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/BaseTools/Source/Python/GenFds/FfsFileStatement.py
> b/BaseTools/Source/Python/GenFds/FfsFileStatement.py
> index 690826b..f76ddf4 100644
> --- a/BaseTools/Source/Python/GenFds/FfsFileStatement.py
> +++ b/BaseTools/Source/Python/GenFds/FfsFileStatement.py
> @@ -99,11 +99,11 @@ class FileStatement (FileStatementClassObject) :
>  FileContent = ''
>  MaxAlignIndex = 0
>  MaxAlignValue = 1
>  for Index, File in enumerate(self.FileName):
>  try:
> -f = open(File, 'r+b')
> +f = open(File, 'rb')
>  except:
>  GenFdsGlobalVariable.ErrorLogger("Error opening 
> RAW
> file %s." % (File))
>  Content = f.read()
>  f.close()
>  AlignValue = 1
> diff --git a/BaseTools/Source/Python/GenFds/Fv.py
> b/BaseTools/Source/Python/GenFds/Fv.py
> index 64d1709..ab3f8b2 100644
> --- a/BaseTools/Source/Python/GenFds/Fv.py
> +++ b/BaseTools/Source/Python/GenFds/Fv.py
> @@ -180,11 +180,11 @@ class FV (FvClassObject):
> 
>  #
>  # Write the Fv contents to Buffer
>  #
>  if os.path.isfile(FvOutputFile):
> -FvFileObj = open ( FvOutputFile,'r+b')
> +FvFileObj = open ( FvOutputFile,'rb')
> 
>  GenFdsGlobalVariable.VerboseLogger( "\nGenerate %s FV
> Successfully" %self.UiFvName)
>  GenFdsGlobalVariable.SharpCounter = 0
> 
>  Buffer.write(FvFileObj.read())
> diff --git a/BaseTools/Source/Python/GenFds/FvImageSection.py
> b/BaseTools/Source/Python/GenFds/FvImageSection.py
> index 748d02f..5989978 100644
> --- a/BaseTools/Source/Python/GenFds/FvImageSection.py
> +++ b/BaseTools/Source/Python/GenFds/FvImageSection.py
> @@ -62,11 +62,11 @@ class FvImageSection(FvImageSectionClassObject):
> 
>  MaxFvAlignment = 0
>  for FvFileName in FileList:
>  FvAlignmentValue = 0
>  if os.path.isfile(FvFileName):
> -FvFileObj = open (FvFileName,'r+b')
> +FvFileObj = open (FvFileName,'rb')
>  FvFileObj.seek(0)
>  # PI FvHeader is 0x48 byte
>  FvHeaderBuffer = FvFileObj.read(0x48)
>  # FV alignment position.
>  FvAlignmentValue = 1 << (ord (FvHeaderBuffer[0x2E]) & 
> 0x1F)
> @@ -107,11 +107,11 @@ class FvImageSection(FvImageSectionClassObject):
>  self.Alignment = Fv.FvAlignment
>  else:
>  if self.FvFileName != None:
>  FvFileName =
> GenFdsGlobalVariable.ReplaceWorkspaceMacro(self.FvFileName)
>  if os.path.isfile(FvFileName):
> -FvFileObj = open (FvFileName,'r+b')
> +FvFileObj = open (FvFileName,'rb')
>  FvFileObj.seek(0)
>  # PI FvHeader is 0x48 byte
>  FvHeaderBuffer = FvFileObj.read(0x48)
>  # FV alignment position.
>  FvAlignmentValue = 1 << (ord (FvHeaderBuffer[0x2E]) 
> & 0x1F)
> diff --git a/BaseTools/Source/Python/GenFds/Region.py
> b/BaseTools/Source/Python/GenFds/Region.py
> index e393286..945c548 100644
> --- a/BaseTools/Source/Python/GenFds/Region.py
> +++ b/BaseTools/Source/Python/GenFds/Region.py
> @@ -146,11 +146,11 @@ class Region(RegionClassObject):
>  FileLength = os.stat(FileName)[ST_SIZE]
>  if FileLength > Size:
>  EdkLogger.error("GenFds", GENFDS_ERROR,
>  "Size of FV File (%s) is larger than 
> Region Size 0x%X
> specified." \
>  % (RegionData, Size))
> -BinFile = open(FileName, 'r+b')
> +BinFile =

Re: [edk2] [Patch 0/2] Update the edk2.tianocore.org URL link

2016-09-14 Thread Gao, Liming

Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Yonghong Zhu
> Sent: Wednesday, September 14, 2016 2:24 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch 0/2] Update the edk2.tianocore.org URL link
> 
> The link http://edk2.tianocore.org is not valid, so update related link.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Yonghong Zhu 
> 
> Yonghong Zhu (2):
>   edksetup.sh: update the URL in edksetup.sh
>   IntelFrameworkPkg/FrameworkSpecConformance.txt: Update the URL
> 
>  IntelFrameworkPkg/FrameworkSpecConformance.txt | 2 +-
>  edksetup.sh| 9 +++--
>  2 files changed, 4 insertions(+), 7 deletions(-)
> 
> --
> 2.6.1.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 2/2] IntelFrameworkPkg/FrameworkSpecConformance.txt: Update the URL

2016-09-14 Thread Fan, Jeff

Reviewed-by: Jeff Fan 

-Original Message-
From: Zhu, Yonghong 
Sent: Wednesday, September 14, 2016 2:24 PM
To: edk2-devel@lists.01.org
Cc: Gao, Liming; Fan, Jeff
Subject: [Patch 2/2] IntelFrameworkPkg/FrameworkSpecConformance.txt: Update the 
URL

Update the URL since http://edk2.tianocore.org is not valid

Cc: Liming Gao 
Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 IntelFrameworkPkg/FrameworkSpecConformance.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/IntelFrameworkPkg/FrameworkSpecConformance.txt 
b/IntelFrameworkPkg/FrameworkSpecConformance.txt
index 36644c8..2aba2cb 100644
--- a/IntelFrameworkPkg/FrameworkSpecConformance.txt
+++ b/IntelFrameworkPkg/FrameworkSpecConformance.txt
@@ -1,9 +1,9 @@
 ##
 # This file is used to document mismatches between Intel Platform Innovation 
Framework specification  # (http://www.intel.com/technology/framework/spec.htm) 
and data structures defind at IntelFrameworkPkg -# package in EdkII Open Source 
Project 
(https://edk2.tianocore.org/source/browse/edk2/trunk/edk2/IntelFrameworkPkg)
+# package in EdkII Open Source Project 
+(https://github.com/tianocore/edk2/tree/master/IntelFrameworkPkg)
 ##
 
 ##
 # The general consideration about keeping the mismatches in EdkII:
 # 1. Some definitions defined in Framework specification may bring a little 
complexity on implementation. EdkII
--
2.6.1.windows.1

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

[edk2] [Patch] NetworkPkg: Correct the DNS token return status by RCODE

2016-09-14 Thread Jiaxin Wu

When HostNameToIp() and GeneralLookUp() are called with a invalid
host name, RCODE (4 bit field is set as part of responses) error
will returned in packet to identify the domain name referenced in
the query does not exist. So, EFI_NOT_FOUND should be returned
directly.

Current implementation only check the RCODE in successful condition.
Need update the code for more error check according to RFC 1035 4.1.1
section.

Cc: Hegde Nagaraj P 
Cc: Fu Siyuan 
Cc: Ye Ting 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 NetworkPkg/DnsDxe/DnsImpl.c | 104 +---
 1 file changed, 40 insertions(+), 64 deletions(-)

diff --git a/NetworkPkg/DnsDxe/DnsImpl.c b/NetworkPkg/DnsDxe/DnsImpl.c
index cfaa4c7..3f3b756 100644
--- a/NetworkPkg/DnsDxe/DnsImpl.c
+++ b/NetworkPkg/DnsDxe/DnsImpl.c
@@ -1230,12 +1230,20 @@ ParseDnsResponse (
   //
   // Continue Check Some Errors.
   //
   if (DnsHeader->Flags.Bits.RCode != DNS_FLAGS_RCODE_NO_ERROR || 
DnsHeader->AnswersNum < 1 || \
   DnsHeader->Flags.Bits.QR != DNS_FLAGS_QR_RESPONSE) {
-  Status = EFI_ABORTED;
-  goto ON_EXIT;
+//
+// The domain name referenced in the query does not exist.
+//
+if (DnsHeader->Flags.Bits.RCode == DNS_FLAGS_RCODE_NAME_ERROR) {
+  Status = EFI_NOT_FOUND; 
+} else {
+  Status = EFI_DEVICE_ERROR;
+}
+
+goto ON_COMPLETE;
   }
   
   //
   // Do some buffer allocations.
   //
@@ -1404,27 +1412,12 @@ ParseDnsResponse (
 
 HostAddr4 = Dns4TokenEntry->Token->RspData.H2AData->IpList;
 AnswerData = (UINT8 *) AnswerSection + sizeof (*AnswerSection);
 CopyMem ([IpCount], AnswerData, sizeof (EFI_IPv4_ADDRESS));
 
-//
-// Update DNS cache dynamically.
-//
-if (Dns4CacheEntry != NULL) {
-  if (Dns4CacheEntry->HostName != NULL) {
-FreePool (Dns4CacheEntry->HostName);
-  }
-
-  if (Dns4CacheEntry->IpAddress != NULL) {
-FreePool (Dns4CacheEntry->IpAddress);
-  }
-  
-  FreePool (Dns4CacheEntry);
-}
-
 // 
-// Allocate new CacheEntry pool.
+// Allocate new CacheEntry pool to update DNS cache dynamically.
 //
 Dns4CacheEntry = AllocateZeroPool (sizeof (EFI_DNS4_CACHE_ENTRY));
 if (Dns4CacheEntry == NULL) {
   Status = EFI_OUT_OF_RESOURCES;
   goto ON_EXIT;
@@ -1446,11 +1439,23 @@ ParseDnsResponse (
   Dns4CacheEntry->Timeout = MIN (CNameTtl, AnswerSection->Ttl);
 } else {
   Dns4CacheEntry->Timeout = MAX (CNameTtl, AnswerSection->Ttl);
 }
 
-UpdateDns4Cache (>Dns4CacheList, FALSE, TRUE, 
*Dns4CacheEntry);  
+UpdateDns4Cache (>Dns4CacheList, FALSE, TRUE, 
*Dns4CacheEntry);
+
+// 
+// Free allocated CacheEntry pool.
+//
+FreePool (Dns4CacheEntry->HostName);
+Dns4CacheEntry->HostName = NULL;
+
+FreePool (Dns4CacheEntry->IpAddress);
+Dns4CacheEntry->IpAddress = NULL;
+
+FreePool (Dns4CacheEntry);
+Dns4CacheEntry = NULL;
 
 IpCount ++;
 Status = EFI_SUCCESS;
 break;
   case DNS_TYPE_:
@@ -1461,27 +1466,12 @@ ParseDnsResponse (
 
 HostAddr6 = Dns6TokenEntry->Token->RspData.H2AData->IpList;
 AnswerData = (UINT8 *) AnswerSection + sizeof (*AnswerSection);
 CopyMem ([IpCount], AnswerData, sizeof (EFI_IPv6_ADDRESS));
 
-//
-// Update DNS cache dynamically.
-//
-if (Dns6CacheEntry != NULL) {
-  if (Dns6CacheEntry->HostName != NULL) {
-FreePool (Dns6CacheEntry->HostName);
-  }
-
-  if (Dns6CacheEntry->IpAddress != NULL) {
-FreePool (Dns6CacheEntry->IpAddress);
-  }
-  
-  FreePool (Dns6CacheEntry);
-}
-
 // 
-// Allocate new CacheEntry pool.
+// Allocate new CacheEntry pool to update DNS cache dynamically.
 //
 Dns6CacheEntry = AllocateZeroPool (sizeof (EFI_DNS6_CACHE_ENTRY));
 if (Dns6CacheEntry == NULL) {
   Status = EFI_OUT_OF_RESOURCES;
   goto ON_EXIT;
@@ -1503,11 +1493,23 @@ ParseDnsResponse (
   Dns6CacheEntry->Timeout = MIN (CNameTtl, AnswerSection->Ttl);
 } else {
   Dns6CacheEntry->Timeout = MAX (CNameTtl, AnswerSection->Ttl);
 }
 
-UpdateDns6Cache (>Dns6CacheList, FALSE, TRUE, 
*Dns6CacheEntry);  
+UpdateDns6Cache (>Dns6CacheList, FALSE, TRUE, 
*Dns6CacheEntry);
+
+// 
+// Free allocated CacheEntry pool.
+//
+FreePool (Dns6CacheEntry->HostName);
+Dns6CacheEntry->HostName = NULL;
+
+FreePool (Dns6CacheEntry->IpAddress);
+Dns6CacheEntry->IpAddress = NULL;
+
+FreePool

[edk2] [Patch 1/2] edksetup.sh: update the URL in edksetup.sh

2016-09-14 Thread Yonghong Zhu

Update the URL since http://edk2.tianocore.org is not valid

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 edksetup.sh | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/edksetup.sh b/edksetup.sh
index 57368b5..27c0994 100755
--- a/edksetup.sh
+++ b/edksetup.sh
@@ -1,30 +1,27 @@
 #
-# Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+# Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved.
 # This program and the accompanying materials
 # are licensed and made available under the terms and conditions of the BSD 
License
 # which accompanies this distribution.  The full text of the license may be 
found at
 # http://opensource.org/licenses/bsd-license.php
 # 
 # THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
 # WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 #
 # In *inux environment, the build tools's source is required and need to be 
compiled
-# firstly, please reference 
https://edk2.tianocore.org/unix-getting-started.html to 
+# firstly, please reference 
https://github.com/tianocore/tianocore.github.io/wiki/SourceForge-to-Github-Quick-Start
 # to get how to setup build tool.
 #
-# After build tool is downloaded and compiled, a soft symbol linker need to be 
created
-# at /Conf. For example: ln -s /work/BaseTools 
/work/edk2/Conf/BaseToolsSource.
-#
 # Setup the environment for unix-like systems running a bash-like shell.
 # This file must be "sourced" not merely executed. For example: ". edksetup.sh"
 #
 # CYGWIN users: Your path and filename related environment variables should be
 # set up in the unix style.  This script will make the necessary conversions to
 # windows style.
 #
-# Please reference edk2 user manual for more detail descriptions at 
https://edk2.tianocore.org/files/documents/64/494/EDKII_UserManual.pdf
+# Please reference edk2 user manual for more detail descriptions at 
https://github.com/tianocore-docs/Docs/raw/master/User_Docs/EDK_II_UserManual_0_7.pdf
 #
 
 function HelpMsg()
 {
   echo Please note: This script must be \'sourced\' so the environment can be 
changed.
-- 
2.6.1.windows.1

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

[edk2] [Patch V2] BaseTools: Fix the bug to handle the read-only file

2016-09-14 Thread Yonghong Zhu

change the 'r+b' to 'rb' for some file's open, since these files we only
read it and no need to write. It can fix the bug that the file's attribute
had been set to read-only.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 BaseTools/Source/Python/GenFds/FfsFileStatement.py | 2 +-
 BaseTools/Source/Python/GenFds/Fv.py   | 2 +-
 BaseTools/Source/Python/GenFds/FvImageSection.py   | 4 ++--
 BaseTools/Source/Python/GenFds/Region.py   | 4 ++--
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/BaseTools/Source/Python/GenFds/FfsFileStatement.py 
b/BaseTools/Source/Python/GenFds/FfsFileStatement.py
index 690826b..f76ddf4 100644
--- a/BaseTools/Source/Python/GenFds/FfsFileStatement.py
+++ b/BaseTools/Source/Python/GenFds/FfsFileStatement.py
@@ -99,11 +99,11 @@ class FileStatement (FileStatementClassObject) :
 FileContent = ''
 MaxAlignIndex = 0
 MaxAlignValue = 1
 for Index, File in enumerate(self.FileName):
 try:
-f = open(File, 'r+b')
+f = open(File, 'rb')
 except:
 GenFdsGlobalVariable.ErrorLogger("Error opening 
RAW file %s." % (File))
 Content = f.read()
 f.close()
 AlignValue = 1
diff --git a/BaseTools/Source/Python/GenFds/Fv.py 
b/BaseTools/Source/Python/GenFds/Fv.py
index 64d1709..ab3f8b2 100644
--- a/BaseTools/Source/Python/GenFds/Fv.py
+++ b/BaseTools/Source/Python/GenFds/Fv.py
@@ -180,11 +180,11 @@ class FV (FvClassObject):
 
 #
 # Write the Fv contents to Buffer
 #
 if os.path.isfile(FvOutputFile):
-FvFileObj = open ( FvOutputFile,'r+b')
+FvFileObj = open ( FvOutputFile,'rb')
 
 GenFdsGlobalVariable.VerboseLogger( "\nGenerate %s FV 
Successfully" %self.UiFvName)
 GenFdsGlobalVariable.SharpCounter = 0
 
 Buffer.write(FvFileObj.read())
diff --git a/BaseTools/Source/Python/GenFds/FvImageSection.py 
b/BaseTools/Source/Python/GenFds/FvImageSection.py
index 748d02f..5989978 100644
--- a/BaseTools/Source/Python/GenFds/FvImageSection.py
+++ b/BaseTools/Source/Python/GenFds/FvImageSection.py
@@ -62,11 +62,11 @@ class FvImageSection(FvImageSectionClassObject):
 
 MaxFvAlignment = 0
 for FvFileName in FileList:
 FvAlignmentValue = 0
 if os.path.isfile(FvFileName):
-FvFileObj = open (FvFileName,'r+b')
+FvFileObj = open (FvFileName,'rb')
 FvFileObj.seek(0)
 # PI FvHeader is 0x48 byte
 FvHeaderBuffer = FvFileObj.read(0x48)
 # FV alignment position.
 FvAlignmentValue = 1 << (ord (FvHeaderBuffer[0x2E]) & 0x1F)
@@ -107,11 +107,11 @@ class FvImageSection(FvImageSectionClassObject):
 self.Alignment = Fv.FvAlignment
 else:
 if self.FvFileName != None:
 FvFileName = 
GenFdsGlobalVariable.ReplaceWorkspaceMacro(self.FvFileName)
 if os.path.isfile(FvFileName):
-FvFileObj = open (FvFileName,'r+b')
+FvFileObj = open (FvFileName,'rb')
 FvFileObj.seek(0)
 # PI FvHeader is 0x48 byte
 FvHeaderBuffer = FvFileObj.read(0x48)
 # FV alignment position.
 FvAlignmentValue = 1 << (ord (FvHeaderBuffer[0x2E]) & 
0x1F)
diff --git a/BaseTools/Source/Python/GenFds/Region.py 
b/BaseTools/Source/Python/GenFds/Region.py
index e393286..945c548 100644
--- a/BaseTools/Source/Python/GenFds/Region.py
+++ b/BaseTools/Source/Python/GenFds/Region.py
@@ -146,11 +146,11 @@ class Region(RegionClassObject):
 FileLength = os.stat(FileName)[ST_SIZE]
 if FileLength > Size:
 EdkLogger.error("GenFds", GENFDS_ERROR,
 "Size of FV File (%s) is larger than 
Region Size 0x%X specified." \
 % (RegionData, Size))
-BinFile = open(FileName, 'r+b')
+BinFile = open(FileName, 'rb')
 Buffer.write(BinFile.read())
 BinFile.close()
 Size = Size - FileLength
 #
 # Pad the left buffer
@@ -199,11 +199,11 @@ class Region(RegionClassObject):
 FileLength = os.stat(FileName)[ST_SIZE]
 if FileLength > Size:
 EdkLogger.error("GenFds", GENFDS_ERROR,
 "Size 0x%X of Capsule File (%s) is

[edk2] [Patch 0/2] Update the edk2.tianocore.org URL link

2016-09-14 Thread Yonghong Zhu

The link http://edk2.tianocore.org is not valid, so update related link.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 

Yonghong Zhu (2):
  edksetup.sh: update the URL in edksetup.sh
  IntelFrameworkPkg/FrameworkSpecConformance.txt: Update the URL

 IntelFrameworkPkg/FrameworkSpecConformance.txt | 2 +-
 edksetup.sh| 9 +++--
 2 files changed, 4 insertions(+), 7 deletions(-)

-- 
2.6.1.windows.1

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

[edk2] [Patch 2/2] IntelFrameworkPkg/FrameworkSpecConformance.txt: Update the URL

2016-09-14 Thread Yonghong Zhu

Update the URL since http://edk2.tianocore.org is not valid

Cc: Liming Gao 
Cc: Jeff Fan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Yonghong Zhu 
---
 IntelFrameworkPkg/FrameworkSpecConformance.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/IntelFrameworkPkg/FrameworkSpecConformance.txt 
b/IntelFrameworkPkg/FrameworkSpecConformance.txt
index 36644c8..2aba2cb 100644
--- a/IntelFrameworkPkg/FrameworkSpecConformance.txt
+++ b/IntelFrameworkPkg/FrameworkSpecConformance.txt
@@ -1,9 +1,9 @@
 ##
 # This file is used to document mismatches between Intel Platform Innovation 
Framework specification
 # (http://www.intel.com/technology/framework/spec.htm) and data structures 
defind at IntelFrameworkPkg
-# package in EdkII Open Source Project 
(https://edk2.tianocore.org/source/browse/edk2/trunk/edk2/IntelFrameworkPkg)
+# package in EdkII Open Source Project 
(https://github.com/tianocore/edk2/tree/master/IntelFrameworkPkg)
 ##
 
 ##
 # The general consideration about keeping the mismatches in EdkII:
 # 1. Some definitions defined in Framework specification may bring a little 
complexity on implementation. EdkII
-- 
2.6.1.windows.1

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

Re: [edk2] SMM PciExpressLib Instance

Re: [edk2] SMM PciExpressLib Instance

Re: [edk2] [PATCH] [MdePkg ] New Debug Message Levels

Re: [edk2] [patch] MdeModulePkg/Xhci: add 1ms delay before access MMIO reg during reset

Re: [edk2] [patch] MdeModulePkg/Xhci: add 1ms delay before access MMIO reg during reset

Re: [edk2] [patch] MdeModulePkg/Xhci: add 1ms delay before access MMIO reg during reset

[edk2] [PATCH] [MdePkg ] New Debug Message Levels

Re: [edk2] GenFds.py error CODE: Tools code failure

Re: [edk2] [Patch] NetworkPkg: Correct the DNS token return status by RCODE

Re: [edk2] [PATCH] ArmPkg/DefaultExceptionHandlerLib: improve formatting of backtrace

Re: [edk2] [PATCH] ArmPkg/DefaultExceptionHandlerLib: improve formatting of backtrace

Re: [edk2] [patch] MdeModulePkg/Xhci: add 1ms delay before access MMIO reg during reset

[edk2] Recall: OVMF compile error

[edk2] Recall: OVMF compile error

Re: [edk2] [Patch V2] BaseTools: Fix the bug to handle the read-only file

Re: [edk2] [Patch 0/2] Update the edk2.tianocore.org URL link

Re: [edk2] [Patch 2/2] IntelFrameworkPkg/FrameworkSpecConformance.txt: Update the URL

[edk2] [Patch] NetworkPkg: Correct the DNS token return status by RCODE

[edk2] [Patch 1/2] edksetup.sh: update the URL in edksetup.sh

[edk2] [Patch V2] BaseTools: Fix the bug to handle the read-only file

[edk2] [Patch 0/2] Update the edk2.tianocore.org URL link

[edk2] [Patch 2/2] IntelFrameworkPkg/FrameworkSpecConformance.txt: Update the URL

22 matches

Site Navigation

Mail list logo

Footer information