Re: [edk2] [Patch 0/2] Stop-the-timer-before-clean-IP-service

[Subramanian, Sriram (EG Servers Platform SW)]

Serials Reviewed-by: Sriram Subramanian 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fu Siyuan
Sent: Thursday, May 26, 2016 6:34 AM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch 0/2] Stop-the-timer-before-clean-IP-service

Fu Siyuan (2):
  MdeModulePkg: Stop the timer before clean IP service.
  NetworkPkg: Stop the timer before clean IP service.

 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c | 18 ++---
 NetworkPkg/Ip6Dxe/Ip6Driver.c | 31 ---
 2 files changed, 25 insertions(+), 24 deletions(-)

-- 
2.7.4.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] Nt32Pkg/PlatformBootManagerLib: zero EFI_GRAPHICS_OUTPUT_BLT_PIXEL.Reserved

[Jordan Justen]

For this, and the related patch for OVMF:

Reviewed-by: Jordan Justen 

On 2016-05-25 16:03:36, Laszlo Ersek wrote:
> The PlatformBootManagerWaitCallback() function sets White.Reserved to
> 0xFF; it should be 0x00. Also, use a more compact form to assign the
> component fields.
> 
> Suggested-by: Jordan Justen 
> Cc: Andrew Fish 
> Cc: Jordan Justen 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c | 16 
> 
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c 
> b/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
> index 82f7647c7039..007e18a956c4 100644
> --- a/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
> +++ b/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
> @@ -262,20 +262,20 @@ PlatformBootManagerWaitCallback (
>UINT16  TimeoutRemain
>)
>  {
> -  EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black;
> -  EFI_GRAPHICS_OUTPUT_BLT_PIXEL White;
> -  UINT16Timeout;
> +  EFI_GRAPHICS_OUTPUT_BLT_PIXEL_UNION Black;
> +  EFI_GRAPHICS_OUTPUT_BLT_PIXEL_UNION White;
> +  UINT16  Timeout;
>  
>Timeout = PcdGet16 (PcdPlatformBootTimeOut);
>  
> -  Black.Blue = Black.Green = Black.Red = Black.Reserved = 0;
> -  White.Blue = White.Green = White.Red = White.Reserved = 0xFF;
> +  Black.Raw = 0x;
> +  White.Raw = 0x00FF;
>  
>BootLogoUpdateProgress (
> -White,
> -Black,
> +White.Pixel,
> +Black.Pixel,
>  L"Start boot option",
> -White,
> +White.Pixel,
>  (Timeout - TimeoutRemain) * 100 / Timeout,
>  0
>  );
> -- 
> 1.8.3.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/2] add '!include' support to tools_def.txt parser

[Gao, Liming]

Push at 8ac46e4ef76ee56778430bb3dbcc545cce49d208

From: Michael Zimmermann [mailto:sigmaepsilo...@gmail.com]
Sent: Tuesday, May 17, 2016 3:55 PM
To: Gao, Liming 
Cc: edk2-devel@lists.01.org 
Subject: Re: [edk2] [PATCH 0/2] add '!include' support to tools_def.txt parser

I sent v3 with relative path support.

Thanks
Michael

On Mon, May 16, 2016 at 8:19 AM, Gao, Liming 
> wrote:
Michael:
  In DSC/FDF, if the file path is relative, Build tool will find it from 
$(WORKSPACE) and $(PACKAGES_PATH). I expect the same way is in tools_def.txt 
file.

Thanks
Liming
> -Original Message-
> From: edk2-devel 
> [mailto:edk2-devel-boun...@lists.01.org]
>  On Behalf Of
> Michael Zimmermann
> Sent: Monday, May 16, 2016 2:00 PM
> To: Gao, Liming >
> Cc: edk2-devel@lists.01.org 
> >
> Subject: Re: [edk2] [PATCH 0/2] add '!include' support to tools_def.txt parser
>
> I guess you mean relative to the currently parsed file?
> It doesn't, I'll make a new patch with support for that.
>
> On Mon, May 16, 2016 at 4:30 AM, Gao, Liming 
> >
> wrote:
>
> > Does it support the relative path?
> >
> > > -Original Message-
> > > From: edk2-devel 
> > > [mailto:edk2-devel-boun...@lists.01.org]
> > >  On Behalf Of
> > > Michael Zimmermann
> > > Sent: Saturday, May 14, 2016 5:49 PM
> > > To: edk2-devel@lists.01.org 
> > > >
> > > Subject: [edk2] [PATCH 0/2] add '!include' support to tools_def.txt
> > parser
> > >
> > > this is a response to this github issue:
> > > https://github.com/tianocore/edk2/issues/77
> > >
> > > this patch just adds !include support to tools_def.txt like it's
> > supported
> > > for FDF and DSC files already.
> > >
> > > the split of the current tools_def.txt into multiple per-toolchain files
> > > can be done in another patch.
> > >
> > > Thanks
> > > Michael
> > >
> > > Michael Zimmermann (2):
> > >   BaseTools: fix incorrect documentation about return value of
> > > 'LoadToolDefFile'
> > >   BaseTools: add '!include' support to tools_def.txt parser
> > >
> > >  BaseTools/Source/Python/Common/ToolDefClassObject.py | 51
> > > +--
> > >  1 file changed, 33 insertions(+), 18 deletions(-)
> > > --
> > > 2.8.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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] Nt32Pkg/PlatformBootManagerLib: zero EFI_GRAPHICS_OUTPUT_BLT_PIXEL.Reserved

[Ni, Ruiyu]

Reviewed-by: Ruiyu Ni 
>-Original Message-
>From: Laszlo Ersek [mailto:ler...@redhat.com]
>Sent: Thursday, May 26, 2016 7:04 AM
>To: edk2-devel-01 
>Cc: Andrew Fish ; Justen, Jordan L 
>; Ni, Ruiyu 
>Subject: [PATCH] Nt32Pkg/PlatformBootManagerLib: zero 
>EFI_GRAPHICS_OUTPUT_BLT_PIXEL.Reserved
>
>The PlatformBootManagerWaitCallback() function sets White.Reserved to
>0xFF; it should be 0x00. Also, use a more compact form to assign the
>component fields.
>
>Suggested-by: Jordan Justen 
>Cc: Andrew Fish 
>Cc: Jordan Justen 
>Cc: Ruiyu Ni 
>Contributed-under: TianoCore Contribution Agreement 1.0
>Signed-off-by: Laszlo Ersek 
>---
> Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c | 16 
> 
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
>diff --git a/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
>b/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
>index 82f7647c7039..007e18a956c4 100644
>--- a/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
>+++ b/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
>@@ -262,20 +262,20 @@ PlatformBootManagerWaitCallback (
>   UINT16  TimeoutRemain
>   )
> {
>-  EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black;
>-  EFI_GRAPHICS_OUTPUT_BLT_PIXEL White;
>-  UINT16Timeout;
>+  EFI_GRAPHICS_OUTPUT_BLT_PIXEL_UNION Black;
>+  EFI_GRAPHICS_OUTPUT_BLT_PIXEL_UNION White;
>+  UINT16  Timeout;
>
>   Timeout = PcdGet16 (PcdPlatformBootTimeOut);
>
>-  Black.Blue = Black.Green = Black.Red = Black.Reserved = 0;
>-  White.Blue = White.Green = White.Red = White.Reserved = 0xFF;
>+  Black.Raw = 0x;
>+  White.Raw = 0x00FF;
>
>   BootLogoUpdateProgress (
>-White,
>-Black,
>+White.Pixel,
>+Black.Pixel,
> L"Start boot option",
>-White,
>+White.Pixel,
> (Timeout - TimeoutRemain) * 100 / Timeout,
> 0
> );
>--
>1.8.3.1

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

Re: [edk2] [Patch 0/2] Stop-the-timer-before-clean-IP-service

[El-Haj-Mahmoud, Samer]

Reviewed-by : Samer El-Haj-Mahmoud 



-Original Message-
From: Fu Siyuan [siyuan...@intel.com]
Received: Wednesday, 25 May 2016, 9:04PM
To: edk2-devel@lists.01.org [edk2-devel@lists.01.org]
Subject: [edk2] [Patch 0/2] Stop-the-timer-before-clean-IP-service

Fu Siyuan (2):
  MdeModulePkg: Stop the timer before clean IP service.
  NetworkPkg: Stop the timer before clean IP service.

 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c | 18 ++---
 NetworkPkg/Ip6Dxe/Ip6Driver.c | 31 ---
 2 files changed, 25 insertions(+), 24 deletions(-)

--
2.7.4.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 0/2] Stop-the-timer-before-clean-IP-service

[Wu, Jiaxin]

Serials Reviewed-by: Wu Jiaxin 


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Fu
> Siyuan
> Sent: Thursday, May 26, 2016 9:04 AM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch 0/2] Stop-the-timer-before-clean-IP-service
> 
> Fu Siyuan (2):
>   MdeModulePkg: Stop the timer before clean IP service.
>   NetworkPkg: Stop the timer before clean IP service.
> 
>  MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c | 18 ++---
>  NetworkPkg/Ip6Dxe/Ip6Driver.c | 31 
> ---
>  2 files changed, 25 insertions(+), 24 deletions(-)
> 
> --
> 2.7.4.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

[edk2] [RFC V2] Proposal to organize packages into directories

[Kinney, Michael D]

Hello,

I have gone through all the feedback I have received and have updated this
proposal.  Here is a summary of the changes in V2:

* IntelFrameworkModulePkg   -> Deprecated
* IntelFrameworkPkg -> Deprecated
* IntelFspPkg   -> Deprecated
* IntelFspWrapperPkg-> Deprecated
* PerformancePkg-> Deprecated
* CorebootPayloadPkg-> Platform
* EmbeddedPkg   -> Driver
* ArmPlatformPkg/ArmJunoPkg -> Silicon/Arm/ArmJunoPkg
* ArmPlatformPkg/ArmVExpressPkg -> Silicon/Arm/ ArmVExpressPkg
* Change Drivers to Driver so no top level directories are plural.
* Remove Vendor directory from Silicon and Platform to reduce directory depth
* Add Platform/Common directory for non-vendor specific platform packages
* Add Silicon/Common directory for non-vendor specific packages of
  CPU/Chipset/SoC drivers
* Keep Vendor directory in Driver.
  Non-vendor specific packages of drivers are flat just below Driver.
  Provides area to migrate non-vendor specific drivers from Core over time

Please let me know if I missed any feedback and if there is new
feedback on this revised proposal for the directory structure or the 
directory names.



# EDK II - Proposal to organize packages into directories

There have been some discussions about organizing packages into directories.
Below is a proposal for a top level directory structure and a first pass 
mapping of the packages from edk2/master.  Where applicable, vendor specific 
directories can be added.

The PACKAGES_PATH feature documented in the link below is used to support
this proposed directory structure with no source file changes.  An example
of setting PACKAGES_PATH in a windows environment is also shown below and
I have verified that platforms can be built using this proposal.

https://github.com/tianocore/tianocore.github.io/wiki/Multiple_Workspace

Please provide feedback on the proposal (for, against, alternate proposal), 
the number/type of top level directories, and the top level directory names.

I have setup a branch with this directory structure in this proposal to help
with the review.  I have verified that I can build some platforms in this 
branch using the PACKAGES_PATH settings shown below.

https://github.com/mdkinney/edk2/tree/NewDirStruct


# Top Level Directory Structure (Listed Alphabetically)
```
edk2
  Application   Applications and application support libraries
  BaseTools EDK II build tools/scripts
  Conf  EDK II build configuration files
  Core  Platform agnostic packages for core FW services
  DeprecatedPackages that will be removed from edk2/master soon
  DriverEDK II Drivers (no platform assumptions)
  Non-Vendor specific EDK II drivers
  Non-Vendor specific EDK II drivers
. . .
Vendor  Vendor specific EDK II drivers
  
  
  Platform  Platforms used to validate edk2/master features
Common  Non-vendor specific platform packages
EmulatedNon-vendor specific emulated platform packages
Arm ARM specific platform packages
Intel   Intel specific platform packages
specific platform packages
specific platform packages 
  Silicon   CPU/Chipset/SoC packages
Common  Non-vendor specific CPU/Chipset/SoC drivers
Arm Arm specific CPU/Chipset/SoC drivers
Intel   Intel specific CPU/Chipset/SoC drivers 
specific CPU/Chipset/SoC drivers
specific CPU/Chipset/SoC drivers
```

# Mapping packages from edk2/master into proposed directory structure
```
edk2
  Application
AppPkg
ShellPkg
StdLib
StdLibPrivateInternalFiles
  Core
CorebootModulePkg
CryptoPkg
IntelFsp2Pkg
IntelFsp2WrapperPkg
MdeModulePkg
MdePkg
SecurityPkg
SourceLevelDebugPkg
  Deprecated
EdkCompatibilityPkg
EdkShellBinPkg
EdkShellPkg
FatBinPkg
IntelFrameworkModulePkg
IntelFrameworkPkg
IntelFspPkg
IntelFspWrapperPkg
PerformancePkg
ShellBinPkg
  Driver
EmbeddedPkg
FatPkg
NetworkPkg
OptionRomPkg
Vendor
  Platform
Common
  DuetPkg
  OvmfPkg
  CorebootPayloadPkg
Emulated
  EmulatorPkg
  Nt32Pkg
  UnixPkg
Arm
  ArmPlatformPkg
  ArmVirtPkg
  BeagleBoardPkg
Intel
  QuarkPlatformPkg
  Vlv2TbltDevicePkg
  Silicon
Common
  PcAtChipsetPkg
  UefiCpuPkg
Arm
  ArmPkg
  ArmJunoPkg
  ArmVExpressPkg
  Omap35xxPkg
Intel
  QuarkSocPkg
  Vlv2DeviceRefCodePkg
```

# Setting PACKAGES_PATH to support builds using proposed directory structure
```
set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Core
set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Driver
set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Silicon\Arm
set PACKAGES_PATH=%PACKAGES_PATH%;%WORKSPACE%\edk2\Silicon\Common

Re: [edk2] TCP4: Failure to Acknowledge due to DPC Dispatch Nesting

[Fu, Siyuan]

Hi, Eugene

The FIN_SENT flag seems OK because an incoming TCP message won't override this 
flag, while the other control flag like the TIMER_REXMIT and RTT are more 
complex which need case by case analysis. There is no DPC mechanism when 
writing the first revision TCP code, so I think we need to review the TCP code 
for the similar cases to make it more robust.

For your question, why not update DPC "such that DPCs at the same TPL didn't 
preempt each other", the answer is that's the reason why DPC is introduced. The 
design intention of DPC is to interrupt current code when the preempted code is 
in the same TPL level with the code being interrupted.

For example, consider the case that the SCSI bus and the iSCSI driver is built 
on top of TCP, which is one of the reason why we design the DPC in history.

*The SCSI must be work as synchronous API in some situation according 
to UEFI spec, while the under layer TCP, IP and MNP are asynchronous API.

*A block reading request comes from the FAT on top of the SCSI device, 
may run oat TPL_CALLBACK, then iSCSI driver transmit a read request message to 
the network.

*The driver's above iSCSI is synchronous and locked on TPL_CALLBACK, 
while the network drivers can only run at TPL_CALLBACK, which comes out the 
problem: there is no more data could receive from network any more.
You can see that we must allow some event at same TPL level with the current 
running code to preempt, otherwise there is a deadlock.

Best Regards
Siyuan

From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, 
Eugene
Sent: Wednesday, May 25, 2016 1:16 AM
To: Fu, Siyuan ; Ye, Ting ; 
edk2-devel@lists.01.org; Wu, Jiaxin ; Zhang, Lubo 

Cc: Vaughn, Gregory (IPG LJ Printer Lab) 
Subject: Re: [edk2] TCP4: Failure to Acknowledge due to DPC Dispatch Nesting

Siyuan,

Thanks for clarifying the intended design.

Given your response I understand that it's considered acceptable for DPC 
functions to preempt each other, even at the same registered TPL level and even 
sometimes with the same exact function (and in the case of TCP operating on the 
exact same connection).  This would seem to present a substantial challenge for 
DPCs to be written correctly because you have to assume that any protocol or 
library you call may result in a DPC dispatch and cause other routines at your 
TPL level (or even another instance of the same function) to be called again.  
Are there restrictions to when DispatchDPC is allowed to be called or can 
anyone do it anytime?  What if, for some evil reason, someone decided to use 
DPCs as part of a specialized DebugLib causing the stack to be preempted 
constantly - do you expect all DPC handlers to behave correctly under these 
circumstances?  Wouldn't it be safer to remove this form of preemption (or at 
least the same-TPL preemption)?

To change the TCP code as you mention, what do you recommend?  Right now we 
have a routine:

  if (TcpTransmitSegment (Tcb, Nbuf) == 0) {
TCP_CLEAR_FLG (Tcb->CtrlFlag, TCP_CTRL_ACK_NOW);
Tcb->DelayedAck = 0;
  }

That attempts the transmit and clears the DelayedAck flag as a function of the 
return status.  Are you recommending that we clear CTRL_ACK_NOW and DelayedAck 
before attempting the transmit?  In the case of an error we would need a way to 
restore the ACK_NOW and DelayedAck these flags which presents the same problem 
again.

But generally I don't think this methodology can be applied to other areas with 
the same exposure.  Consider the TcpToSendData function.  It does this:

if (TcpTransmitSegment (Tcb, Nbuf) != 0) {
NetbufTrim (Nbuf, (Nbuf->Tcp->HeadLen << 2), NET_BUF_HEAD);
Nbuf->Tcp = NULL;

if ((Flag & TCP_FLG_FIN) != 0)  {
  TCP_SET_FLG (Tcb->CtrlFlag, TCP_CTRL_FIN_SENT);
}

goto OnError;
  }

which as you can see sets a flag (FIN_SENT) after a DPC preemption point 
(TcpTransmitSegment) and even later it sets other TCB data after the DPC 
preemption point:

  //
  // update status in TCB
  //
  Tcb->DelayedAck = 0;

  if ((Flag & TCP_FLG_FIN) != 0) {
TCP_SET_FLG (Tcb->CtrlFlag, TCP_CTRL_FIN_SENT);
  }

So it seems like the TCB contents may be at risk in a number of places because 
of DPC preemption.

If we the DPC rules were changed such that DPCs at the same TPL didn't preempt 
each other it would seem to prevent this (to the extent that DPC callbacks use 
a consistent TPL level to provide protection).

Thanks,

Eugene

From: Fu, Siyuan [mailto:siyuan...@intel.com]
Sent: Monday, May 23, 2016 8:45 PM
To: Ye, Ting >; Cohen, Eugene 
>; 
edk2-devel@lists.01.org; Wu, Jiaxin 
>; Zhang, Lubo 
>
Cc: Vaughn, Gregory (IPG LJ Printer 

Re: [edk2] [Patch 2/2] NetworkPkg: Correct HttpConfigure parameter check

[Zhang, Lubo]

Reviewed-by: Zhang Lubo 

-Original Message-
From: Wu, Jiaxin 
Sent: Wednesday, May 25, 2016 4:28 PM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Fu, Siyuan ; Zhang, Lubo 

Subject: [Patch 2/2] NetworkPkg: Correct HttpConfigure parameter check

When HttpConfigData is NULL, HttpConfigure should not return 
EFI_INVALID_PARAMETER.

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Zhang Lubo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 NetworkPkg/HttpDxe/HttpImpl.c | 9 +  NetworkPkg/HttpDxe/HttpImpl.h | 1 
-
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c 
index 7ee6613..12f22db 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -112,11 +112,10 @@ EfiHttpGetModeData (
   @param[in]  HttpConfigData  Pointer to the configure data to configure 
the instance.
 
   @retval EFI_SUCCESS Operation succeeded.
   @retval EFI_INVALID_PARAMETER   One or more of the following conditions is 
TRUE:
   This is NULL.
-  HttpConfigData is NULL.
   HttpConfigData->LocalAddressIsIPv6 is FALSE 
and
   HttpConfigData->IPv4Node is NULL.
   HttpConfigData->LocalAddressIsIPv6 is TRUE 
and
   HttpConfigData->IPv6Node is NULL.
   @retval EFI_ALREADY_STARTED Reinitialize this HTTP instance without 
calling
@@ -139,13 +138,13 @@ EfiHttpConfigure (
   
   //
   // Check input parameters.
   //
   if (This == NULL ||
-  HttpConfigData == NULL ||
- ((HttpConfigData->LocalAddressIsIPv6 && 
HttpConfigData->AccessPoint.IPv6Node == NULL) ||
- (!HttpConfigData->LocalAddressIsIPv6 && 
HttpConfigData->AccessPoint.IPv4Node == NULL))) {
+  (HttpConfigData != NULL && 
+   ((HttpConfigData->LocalAddressIsIPv6 && 
HttpConfigData->AccessPoint.IPv6Node == NULL) ||
+(!HttpConfigData->LocalAddressIsIPv6 && 
+ HttpConfigData->AccessPoint.IPv4Node == NULL {
 return EFI_INVALID_PARAMETER;
   }
 
   HttpInstance = HTTP_INSTANCE_FROM_PROTOCOL (This);
   ASSERT (HttpInstance != NULL && HttpInstance->Service != NULL); @@ -252,10 
+251,11 @@ EfiHttpRequest (
   //
   // Initializations
   //
   Url = NULL;
   UrlParser = NULL;
+  RemotePort = 0;
   HostName = NULL;
   RequestMsg = NULL;
   HostNameStr = NULL;
   Wrap = NULL;
   FileUrl = NULL;
@@ -906,10 +906,11 @@ HttpResponseWorker (
   HttpMsg->Headers  = NULL;
   HttpHeaders   = NULL;
   SizeofHeaders = 0;
   BufferSize= 0;
   EndofHeader   = NULL;
+  ValueInItem   = NULL;
  
   if (HttpMsg->Data.Response != NULL) {
 //
 // Need receive the HTTP headers, prepare buffer.
 //
diff --git a/NetworkPkg/HttpDxe/HttpImpl.h b/NetworkPkg/HttpDxe/HttpImpl.h 
index 415b5e5..40b2504 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.h
+++ b/NetworkPkg/HttpDxe/HttpImpl.h
@@ -70,11 +70,10 @@ EfiHttpGetModeData (
   @param[in]  HttpConfigData  Pointer to the configure data to configure 
the instance.
 
   @retval EFI_SUCCESS Operation succeeded.
   @retval EFI_INVALID_PARAMETER   One or more of the following conditions is 
TRUE:
   This is NULL.
-  HttpConfigData is NULL.
   HttpConfigData->LocalAddressIsIPv6 is FALSE 
and
   HttpConfigData->IPv4Node is NULL.
   HttpConfigData->LocalAddressIsIPv6 is TRUE 
and
   HttpConfigData->IPv6Node is NULL.
   @retval EFI_ALREADY_STARTED Reinitialize this HTTP instance without 
calling
--
1.9.5.msysgit.1

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

[edk2] [Patch] MdeModulePkg: Fix SNP.Initialize() spec conformance issue

[Jiaxin Wu]

Current SNP UNDI Initialize command does not follow the UEFI Spec
to update the SNP MediaPresent field. The result for the Initialize
command execution check should be:
StatFlags: (1) Monitor the upper two bits (14 & 15) in the field to know
whether the command has been executed by the UNDI (Not started, Queued,
Error, Complete). (2) Check the other field to see if there is an active
connection to this network device (used to update MediaPresent).
StatCode: After command execution completes, either successfully or not,
this field contains the result of the command execution (success or failure).
This patch is used to fix it.

NOTE: If any UNDI driver does not follow the UEFI Spec for the media status
update, it may meet failure with this more conditions check (StatFlags).

Cc: Ye Ting 
Cc: Fu Siyuan 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 MdeModulePkg/Universal/Network/SnpDxe/Initialize.c | 37 ++
 1 file changed, 31 insertions(+), 6 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/SnpDxe/Initialize.c 
b/MdeModulePkg/Universal/Network/SnpDxe/Initialize.c
index 2151375..0c292a5 100644
--- a/MdeModulePkg/Universal/Network/SnpDxe/Initialize.c
+++ b/MdeModulePkg/Universal/Network/SnpDxe/Initialize.c
@@ -1,9 +1,9 @@
 /** @file
Implementation of initializing a network adapter.
 
-Copyright (c) 2004 - 2008, Intel Corporation. All rights reserved.
+Copyright (c) 2004 - 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 
 
@@ -35,10 +35,12 @@ PxeInit (
 {
   PXE_CPB_INITIALIZE  *Cpb;
   VOID*Addr;
   EFI_STATUS  Status;
 
+  Status = EFI_SUCCESS;
+
   Cpb = Snp->Cpb;
   if (Snp->TxRxBufferSize != 0) {
 Status = Snp->PciIo->AllocateBuffer (
Snp->PciIo,
AllocateAnyPages,
@@ -97,14 +99,38 @@ PxeInit (
 
   DEBUG ((EFI_D_NET, "\nSnp->undi.initialize()  "));
 
   (*Snp->IssueUndi32Command) ((UINT64)(UINTN) >Cdb);
 
-  if (Snp->Cdb.StatCode == PXE_STATCODE_SUCCESS) {
-Snp->Mode.State = EfiSimpleNetworkInitialized;
-
-Status  = EFI_SUCCESS;
+  //
+  // There are two fields need to be checked here:
+  // First is the upper two bits (14 & 15) in the CDB.StatFlags field. Until 
these bits change to report 
+  // PXE_STATFLAGS_COMMAND_COMPLETE or PXE_STATFLAGS_COMMAND_FAILED, the 
command has not been executed by the UNDI.
+  // Second is the CDB.StatCode field. After command execution completes, 
either successfully or not, 
+  // the CDB.StatCode field contains the result of the command execution.
+  //
+  if Snp->Cdb.StatFlags) & PXE_STATFLAGS_STATUS_MASK) == 
PXE_STATFLAGS_COMMAND_COMPLETE) &&
+  (Snp->Cdb.StatCode == PXE_STATCODE_SUCCESS)) {
+//
+// If cable detect feature is enabled in CDB.OpFlags, check the 
CDB.StatFlags to see if there is an 
+// active connection to this network device. If the no media StatFlag is 
set, the UNDI and network 
+// device are still initialized.
+//
+if (CableDetectFlag == PXE_OPFLAGS_INITIALIZE_DETECT_CABLE) {
+  if(((Snp->Cdb.StatFlags) & PXE_STATFLAGS_INITIALIZED_NO_MEDIA) != 
PXE_STATFLAGS_INITIALIZED_NO_MEDIA) {
+Snp->Mode.MediaPresent = TRUE;
+Snp->Mode.State = EfiSimpleNetworkInitialized;
+Status = EFI_SUCCESS;
+  } else {
+Snp->Mode.MediaPresent = FALSE;
+Snp->Mode.State = EfiSimpleNetworkInitialized;
+Status  = EFI_SUCCESS;
+  }
+} else {
+  Snp->Mode.State   = EfiSimpleNetworkInitialized;
+  Status= EFI_SUCCESS;
+}
   } else {
 DEBUG (
   (EFI_D_WARN,
   "\nSnp->undi.initialize()  %xh:%xh\n",
   Snp->Cdb.StatFlags,
@@ -232,11 +258,10 @@ SnpUndi32Initialize (
   //
   // If UNDI support cable detect for INITIALIZE command, try it first.
   //
   if (Snp->CableDetectSupported) {
 if (PxeInit (Snp, PXE_OPFLAGS_INITIALIZE_DETECT_CABLE) == EFI_SUCCESS) {
-  Snp->Mode.MediaPresent = TRUE;
   goto ON_EXIT;
 }
   }
 
   Snp->Mode.MediaPresent  = FALSE;
-- 
1.9.5.msysgit.1

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

Re: [edk2] [Patch 1/2] MdePkg: Correct EFI_HTTP_CONFIGURE return status value

[Fu, Siyuan]

Serials Reviewed-by: Fu Siyuan 



> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jiaxin Wu
> Sent: Wednesday, May 25, 2016 4:28 PM
> To: edk2-devel@lists.01.org
> Cc: Ye, Ting ; Zhang, Lubo ; Fu,
> Siyuan 
> Subject: [edk2] [Patch 1/2] MdePkg: Correct EFI_HTTP_CONFIGURE return
> status value
> 
> Cc: Ye Ting 
> Cc: Fu Siyuan 
> Cc: Zhang Lubo 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiaxin Wu 
> ---
>  MdePkg/Include/Protocol/Http.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/MdePkg/Include/Protocol/Http.h
> b/MdePkg/Include/Protocol/Http.h
> index 22201b4..269416c 100644
> --- a/MdePkg/Include/Protocol/Http.h
> +++ b/MdePkg/Include/Protocol/Http.h
> @@ -339,11 +339,10 @@ EFI_STATUS
>@param[in]  HttpConfigData  Pointer to the configure data to configure
> the instance.
> 
>@retval EFI_SUCCESS Operation succeeded.
>@retval EFI_INVALID_PARAMETER   One or more of the following conditions
> is TRUE:
>This is NULL.
> -  HttpConfigData is NULL.
>HttpConfigData->LocalAddressIsIPv6 is 
> FALSE and
>HttpConfigData->IPv4Node is NULL.
>HttpConfigData->LocalAddressIsIPv6 is TRUE 
> and
>HttpConfigData->IPv6Node is NULL.
>@retval EFI_ALREADY_STARTED Reinitialize this HTTP instance without
> calling
> --
> 1.9.5.msysgit.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

[edk2] [Patch 2/2] NetworkPkg: Stop the timer before clean IP service.

[Fu Siyuan]

In Ip6CleanService()it first cleaned some resources, then stop the timer .
While before the timer stopped it may try to access some already freed
data, which may generate an exception.
This patch updates the driver to stop the timer event before starting to
clean up the service data.

Cc: Wu Jiaxin 
Cc: Ye Ting 
Cc: Subramanian Sriram 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 NetworkPkg/Ip6Dxe/Ip6Driver.c | 31 ---
 1 file changed, 16 insertions(+), 15 deletions(-)

diff --git a/NetworkPkg/Ip6Dxe/Ip6Driver.c b/NetworkPkg/Ip6Dxe/Ip6Driver.c
index 16617c1..f2df200 100644
--- a/NetworkPkg/Ip6Dxe/Ip6Driver.c
+++ b/NetworkPkg/Ip6Dxe/Ip6Driver.c
@@ -149,6 +149,22 @@ Ip6CleanService (
   EFI_IPv6_ADDRESS  AllNodes;
   IP6_NEIGHBOR_ENTRY*NeighborCache;
 
+  IpSb->State = IP6_SERVICE_DESTROY;
+
+  if (IpSb->Timer != NULL) {
+gBS->SetTimer (IpSb->Timer, TimerCancel, 0);
+gBS->CloseEvent (IpSb->Timer);
+
+IpSb->Timer = NULL;
+  }
+
+  if (IpSb->FasterTimer != NULL) {
+gBS->SetTimer (IpSb->FasterTimer, TimerCancel, 0);
+gBS->CloseEvent (IpSb->FasterTimer);
+
+IpSb->FasterTimer = NULL;
+  }
+
   Ip6ConfigCleanInstance (>Ip6ConfigInstance);
 
   if (!IpSb->LinkLocalDadFail) {
@@ -214,19 +230,6 @@ Ip6CleanService (
 gBS->CloseEvent (IpSb->RecvRequest.MnpToken.Event);
   }
 
-  if (IpSb->Timer != NULL) {
-gBS->SetTimer (IpSb->Timer, TimerCancel, 0);
-gBS->CloseEvent (IpSb->Timer);
-
-IpSb->Timer = NULL;
-  }
-
-  if (IpSb->FasterTimer != NULL) {
-gBS->SetTimer (IpSb->FasterTimer, TimerCancel, 0);
-gBS->CloseEvent (IpSb->FasterTimer);
-
-IpSb->FasterTimer = NULL;
-  }
   //
   // Free the Neighbor Discovery resources
   //
@@ -759,8 +762,6 @@ Ip6DriverBindingStop (
);
   } else if (IsListEmpty (>Children)) {
 State   = IpSb->State;
-IpSb->State = IP6_SERVICE_DESTROY;
-
 Status = Ip6CleanService (IpSb);
 if (EFI_ERROR (Status)) {
   IpSb->State = State;
-- 
2.7.4.windows.1

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

[edk2] [Patch 0/2] Stop-the-timer-before-clean-IP-service

[Fu Siyuan]

Fu Siyuan (2):
  MdeModulePkg: Stop the timer before clean IP service.
  NetworkPkg: Stop the timer before clean IP service.

 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c | 18 ++---
 NetworkPkg/Ip6Dxe/Ip6Driver.c | 31 ---
 2 files changed, 25 insertions(+), 24 deletions(-)

-- 
2.7.4.windows.1

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

[edk2] [Patch 1/2] MdeModulePkg: Stop the timer before clean IP service.

[Fu Siyuan]

In Ip4CleanService()it first cleaned some resources, then stop the timer .
While before the timer stopped it may try to access some already freed
data, which may generate an exception.
This patch updates the driver to stop the timer event before starting to
clean up the service data.

Cc: Wu Jiaxin 
Cc: Ye Ting 
Cc: Subramanian Sriram 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Fu Siyuan 
---
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
index fb83784..fcd3ccb 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Driver.c
@@ -393,6 +393,15 @@ Ip4CleanService (
 {
   EFI_STATUSStatus;
 
+  IpSb->State = IP4_SERVICE_DESTROY;
+
+  if (IpSb->Timer != NULL) {
+gBS->SetTimer (IpSb->Timer, TimerCancel, 0);
+gBS->CloseEvent (IpSb->Timer);
+
+IpSb->Timer = NULL;
+  }
+
   if (IpSb->DefaultInterface != NULL) {
 Status = Ip4FreeInterface (IpSb->DefaultInterface, NULL);
 
@@ -432,13 +441,6 @@ Ip4CleanService (
 IpSb->MnpChildHandle = NULL;
   }
 
-  if (IpSb->Timer != NULL) {
-gBS->SetTimer (IpSb->Timer, TimerCancel, 0);
-gBS->CloseEvent (IpSb->Timer);
-
-IpSb->Timer = NULL;
-  }
-
   if (IpSb->ReconfigEvent != NULL) {
 gBS->CloseEvent (IpSb->ReconfigEvent);
 
@@ -750,8 +752,6 @@ Ip4DriverBindingStop (
 
   } else if (IsListEmpty (>Children)) {
 State   = IpSb->State;
-IpSb->State = IP4_SERVICE_DESTROY;
-
 //
 // OK, clean other resources then uninstall the service binding protocol.
 //
-- 
2.7.4.windows.1

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

[edk2] [PATCH] Nt32Pkg/PlatformBootManagerLib: zero EFI_GRAPHICS_OUTPUT_BLT_PIXEL.Reserved

[Laszlo Ersek]

The PlatformBootManagerWaitCallback() function sets White.Reserved to
0xFF; it should be 0x00. Also, use a more compact form to assign the
component fields.

Suggested-by: Jordan Justen 
Cc: Andrew Fish 
Cc: Jordan Justen 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c | 16 

 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c 
b/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
index 82f7647c7039..007e18a956c4 100644
--- a/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
+++ b/Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
@@ -262,20 +262,20 @@ PlatformBootManagerWaitCallback (
   UINT16  TimeoutRemain
   )
 {
-  EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black;
-  EFI_GRAPHICS_OUTPUT_BLT_PIXEL White;
-  UINT16Timeout;
+  EFI_GRAPHICS_OUTPUT_BLT_PIXEL_UNION Black;
+  EFI_GRAPHICS_OUTPUT_BLT_PIXEL_UNION White;
+  UINT16  Timeout;
 
   Timeout = PcdGet16 (PcdPlatformBootTimeOut);
 
-  Black.Blue = Black.Green = Black.Red = Black.Reserved = 0;
-  White.Blue = White.Green = White.Red = White.Reserved = 0xFF;
+  Black.Raw = 0x;
+  White.Raw = 0x00FF;
 
   BootLogoUpdateProgress (
-White,
-Black,
+White.Pixel,
+Black.Pixel,
 L"Start boot option",
-White,
+White.Pixel,
 (Timeout - TimeoutRemain) * 100 / Timeout,
 0
 );
-- 
1.8.3.1

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

Re: [edk2] [PATCH 3/6] OvmfPkg/PlatformBootManagerLib: bring back the progress bar

[Andrew Fish]

> On May 25, 2016, at 3:03 PM, Jordan Justen  wrote:
> 
> On 2016-05-25 14:13:03, Laszlo Ersek wrote:
>> On 05/25/16 21:53, Jordan Justen wrote:
>>> On 2016-05-25 10:23:56, Laszlo Ersek wrote:
 On 05/25/16 19:00, Jordan Justen wrote:
> On 2016-05-25 05:36:43, Laszlo Ersek wrote:
>> OVMF's Platform BDS used to have a nice progress bar (with
>> IntelFrameworkModulePkg BDS). We can restore it by copying the
>> PlatformBootManagerWaitCallback() function verbatim from
>> 
>>  Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
>> 
>> It can be tested by passing the following option to QEMU (5 seconds):
>> 
>>  -boot menu=on,splash-time=5000
>> 
>> Cc: Jordan Justen 
>> Cc: Ruiyu Ni 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek 
>> ---
>> OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 17 
>> +
>> 1 file changed, 17 insertions(+)
>> 
>> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
>> b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>> index 9eb9e390373d..dd8757f58ec3 100644
>> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>> @@ -1425,5 +1425,22 @@ PlatformBootManagerWaitCallback (
>>   UINT16  TimeoutRemain
>>   )
>> {
>> +  EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black;
>> +  EFI_GRAPHICS_OUTPUT_BLT_PIXEL White;
>> +  UINT16Timeout;
>> +
>> +  Timeout = PcdGet16 (PcdPlatformBootTimeOut);
>> +
>> +  Black.Blue = Black.Green = Black.Red = Black.Reserved = 0;
>> +  White.Blue = White.Green = White.Red = White.Reserved = 0xFF;
> 
> I know this came from Nt32, but how about making these global vars?
> 
> static EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black = { 0, 0, 0, 0 };
> static EFI_GRAPHICS_OUTPUT_BLT_PIXEL White = { 0xff, 0xff, 0xff, 0 };
 
 I'm okay with giving them static storage duration.
 
 With that changed,
 - do you want me to keep them in function scope (with the same names),
 - or should I move them to file scope (and then, as Andrew suggests,
  rename them to, say, mPixelBlack and mPixelWhite)?
 
>>> 
>>> The part that bugged me was setting .Reserved to 0xff.
>>> 
>>> How about just making them initialized local variables?
>>> 
>>>  EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black = { 0, 0, 0, 0 };
>>>  EFI_GRAPHICS_OUTPUT_BLT_PIXEL White = { 0xff, 0xff, 0xff, 0 };
>> 
>> That would conflict with the edk2 coding style (6.8 C Function Layout,
>> "Initializing a variable as part of its declaration is illegal" --
>> although it clearly doesn't cover variables with static storage duration.)
>> 
> 
> I do see that in the older style guide, but not the newer ones (2.0+).
> 
>> I even suspect that the first initialization could cause some compilers
>> to emit memset() intrinsics.
>> 
> 
> Hmm, yeah that could be a problem.
> 

I've never seen the compiler emit a memcpy/memset for something <  64-bits (8 
bytes). There is an overhead for making the call to memcpy/memset and you have 
to pass a pointer so even with optimizations disabled I think the compilers 
have  a minimum threshold for the call. From what I've seen clang NOOPT is the 
best way to expose these kinds of issues. Most optimizers seem to decide to 
generate code vs. calling memcpy for a lot of smaller cases, like a GUID but 
clang at -O0 seems to default to memcpy/memset very quickly and defaults to the 
optimizer to remove it. 

Thanks,

Andrew Fish 

>> How about:
>> 
>>  Black.Blue = Black.Green = Black.Red = 0;
>>  White.Blue = White.Green = White.Red = 0xFF;
>>  Black.Reserved = White.Reserved = 0;
>> 
> 
> Sure, or a static local var.
> 
> I hope that in the case of the above code that most compilers would
> see that we are really just dealing with two uint32_t values.
> 
> I guess there is the union wrapper of the struct, and combined with
> the UEFI assumption of little-endian, you could force it.
> 
> -Jordan
> 
>> (I could submit a patch for Nt32Pkg too that fixed White.Reserved.)
>> 
>> Thanks
>> Laszlo
> ___
> 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 v3 1/2] MdePkg: Add a header for NVMe v1.1 spec. definitions.

[darbin . emm . reyes]

From: Darbin Reyes 

Adds a public header for NVMe v1.1 spec. definitions. The majority
of these definitions where copied from a private header in
MdeModulePkg/Bus/Pci/NvmExpress/NvmExpressHci.h. Additional
definitions were added e.g. the NVMe Smart Health Log and
Firmware Info. Log structures. These definitions should be
in a public header so that clients of the NVMe passthru protocol
can use them to execute NVMe commands.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Darbin Reyes 
Reviewed-by: Samer El-Haj-Mahmoud 
---
 MdePkg/Include/IndustryStandard/Nvme.h | 935 +
 1 file changed, 935 insertions(+)
 create mode 100644 MdePkg/Include/IndustryStandard/Nvme.h

diff --git a/MdePkg/Include/IndustryStandard/Nvme.h 
b/MdePkg/Include/IndustryStandard/Nvme.h
new file mode 100644
index 000..6fe92ac
--- /dev/null
+++ b/MdePkg/Include/IndustryStandard/Nvme.h
@@ -0,0 +1,935 @@
+/** @file
+  Definitions based on NVMe spec. version 1.1.
+
+  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
+  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.
+
+  @par Specification Reference:
+  NVMe Specification 1.1
+
+**/
+
+#ifndef __NVM_E_H__
+#define __NVM_E_H__
+
+#pragma pack(1)
+
+//
+// controller register offsets
+//
+#define NVME_CAP_OFFSET  0x  // Controller Capabilities
+#define NVME_VER_OFFSET  0x0008  // Version
+#define NVME_INTMS_OFFSET0x000c  // Interrupt Mask Set
+#define NVME_INTMC_OFFSET0x0010  // Interrupt Mask Clear
+#define NVME_CC_OFFSET   0x0014  // Controller Configuration
+#define NVME_CSTS_OFFSET 0x001c  // Controller Status
+#define NVME_NSSR_OFFSET 0x0020  // NVM Subsystem Reset
+#define NVME_AQA_OFFSET  0x0024  // Admin Queue Attributes
+#define NVME_ASQ_OFFSET  0x0028  // Admin Submission Queue Base Address
+#define NVME_ACQ_OFFSET  0x0030  // Admin Completion Queue Base Address
+#define NVME_SQ0_OFFSET  0x1000  // Submission Queue 0 (admin) Tail 
Doorbell
+#define NVME_CQ0_OFFSET  0x1004  // Completion Queue 0 (admin) Head 
Doorbell
+
+//
+// These register offsets are defined as 0x1000 + (N * (4 << CAP.DSTRD))
+// Get the doorbell stride bit shift value from the controller capabilities.
+//
+#define NVME_SQTDBL_OFFSET(QID, DSTRD)0x1000 + ((2 * (QID)) * (4 << 
(DSTRD)))   // Submission Queue y (NVM) Tail Doorbell
+#define NVME_CQHDBL_OFFSET(QID, DSTRD)0x1000 + (((2 * (QID)) + 1) * (4 << 
(DSTRD))) // Completion Queue y (NVM) Head Doorbell
+
+
+#pragma pack(1)
+
+//
+// 3.1.1 Offset 00h: CAP - Controller Capabilities
+//
+typedef struct {
+  UINT16 Mqes;  // Maximum Queue Entries Supported
+  UINT8  Cqr:1; // Contiguous Queues Required
+  UINT8  Ams:2; // Arbitration Mechanism Supported
+  UINT8  Rsvd1:5;
+  UINT8  To;// Timeout
+  UINT16 Dstrd:4;
+  UINT16 Nssrs:1;   // NVM Subsystem Reset Supported NSSRS
+  UINT16 Css:4; // Command Sets Supported - Bit 37
+  UINT16 Rsvd3:7;
+  UINT8  Mpsmin:4;
+  UINT8  Mpsmax:4;
+  UINT8  Rsvd4;
+} NVME_CAP;
+
+//
+// 3.1.2 Offset 08h: VS - Version
+//
+typedef struct {
+  UINT16 Mnr;   // Minor version number
+  UINT16 Mjr;   // Major version number
+} NVME_VER;
+
+//
+// 3.1.5 Offset 14h: CC - Controller Configuration
+//
+typedef struct {
+  UINT16 En:1;   // Enable
+  UINT16 Rsvd1:3;
+  UINT16 Css:3;  // I/O Command Set Selected
+  UINT16 Mps:4;  // Memory Page Size
+  UINT16 Ams:3;  // Arbitration Mechanism Selected
+  UINT16 Shn:2;  // Shutdown Notification
+  UINT8  Iosqes:4;   // I/O Submission Queue Entry Size
+  UINT8  Iocqes:4;   // I/O Completion Queue Entry Size
+  UINT8  Rsvd2;
+} NVME_CC;
+
+//
+// 3.1.6 Offset 1Ch: CSTS - Controller Status
+//
+typedef struct {
+  UINT32 Rdy:1;  // Ready
+  UINT32 Cfs:1;  // Controller Fatal Status
+  UINT32 Shst:2; // Shutdown Status
+  UINT32 Nssro:1;// NVM Subsystem Reset Occurred
+  UINT32 Rsvd1:27;
+} NVME_CSTS;
+
+//
+// 3.1.8 Offset 24h: AQA - Admin Queue Attributes
+//
+typedef struct {
+  UINT16 Asqs:12;// Submission Queue Size
+  UINT16 Rsvd1:4;
+  UINT16 Acqs:12;// Completion Queue Size
+  UINT16 Rsvd2:4;
+} NVME_AQA;
+
+//
+// 3.1.9 Offset 28h: ASQ - Admin Submission Queue Base Address
+//
+#define NVME_ASQ  UINT64
+//
+// 3.1.10 Offset 30h: ACQ - Admin Completion Queue Base Address
+//
+#define NVME_ACQ  UINT64
+
+//
+// 3.1.11 Offset (1000h + ((2y) * (4 << CAP.DSTRD))): SQyTDBL - 

[edk2] [PATCH v3 0/2] *** Move NvmExpress definitions to public Nvme.h ***

[darbin . emm . reyes]

From: Darbin Reyes 

*** Move NvmExpress definitions to public Nvme.h ***
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Darbin Reyes 
Reviewed-by: Samer El-Haj-Mahmoud 
Darbin Reyes (2):
  MdePkg: Add a header for NVMe v1.1 spec. definitions.
  MdeModulePkg: Move/Replace NvmExpressHci.h definitions to Nvme.h.

 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h|   2 +
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.h | 728 +---
 MdePkg/Include/IndustryStandard/Nvme.h | 935 +
 3 files changed, 938 insertions(+), 727 deletions(-)
 create mode 100644 MdePkg/Include/IndustryStandard/Nvme.h

-- 
2.8.2

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

[edk2] [PATCH v3 2/2] MdeModulePkg: Move/Replace NvmExpressHci.h definitions to Nvme.h.

[darbin . emm . reyes]

From: Darbin Reyes 

Move NvmExpressHci.h definitions to a public industry standard
header in MdePkg. The NvmExpressHci.h contains definitions based
on the NVMe v1.1 specification. These definitions should be in
a public header so that clients of the NVMe passthru protocol
can use them to execute NVMe commands.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Darbin Reyes 
Reviewed-by: Samer El-Haj-Mahmoud 
---
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h|   2 +
 MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.h | 728 +
 2 files changed, 3 insertions(+), 727 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
index 519772b..6a1c257 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpress.h
@@ -2,6 +2,7 @@
   NvmExpressDxe driver is used to manage non-volatile memory subsystem which 
follows
   NVM Express specification.
 
+  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
   Copyright (c) 2013 - 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
@@ -19,6 +20,7 @@
 #include 
 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.h 
b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.h
index f893251..ddfba14 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.h
+++ b/MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressHci.h
@@ -2,6 +2,7 @@
   NvmExpressDxe driver is used to manage non-volatile memory subsystem which 
follows
   NVM Express specification.
 
+  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
   Copyright (c) 2013 - 2015, 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
@@ -19,731 +20,6 @@
 #define NVME_BAR 0
 
 //
-// controller register offsets
-//
-#define NVME_CAP_OFFSET  0x  // Controller Capabilities
-#define NVME_VER_OFFSET  0x0008  // Version
-#define NVME_INTMS_OFFSET0x000c  // Interrupt Mask Set
-#define NVME_INTMC_OFFSET0x0010  // Interrupt Mask Clear
-#define NVME_CC_OFFSET   0x0014  // Controller Configuration
-#define NVME_CSTS_OFFSET 0x001c  // Controller Status
-#define NVME_NSSR_OFFSET 0x0020  // NVM Subsystem Reset
-#define NVME_AQA_OFFSET  0x0024  // Admin Queue Attributes
-#define NVME_ASQ_OFFSET  0x0028  // Admin Submission Queue Base Address
-#define NVME_ACQ_OFFSET  0x0030  // Admin Completion Queue Base Address
-#define NVME_SQ0_OFFSET  0x1000  // Submission Queue 0 (admin) Tail 
Doorbell
-#define NVME_CQ0_OFFSET  0x1004  // Completion Queue 0 (admin) Head 
Doorbell
-
-//
-// These register offsets are defined as 0x1000 + (N * (4 << CAP.DSTRD))
-// Get the doorbell stride bit shift value from the controller capabilities.
-//
-#define NVME_SQTDBL_OFFSET(QID, DSTRD)0x1000 + ((2 * (QID)) * (4 << 
(DSTRD)))   // Submission Queue y (NVM) Tail Doorbell
-#define NVME_CQHDBL_OFFSET(QID, DSTRD)0x1000 + (((2 * (QID)) + 1) * (4 << 
(DSTRD))) // Completion Queue y (NVM) Head Doorbell
-
-
-#pragma pack(1)
-
-//
-// 3.1.1 Offset 00h: CAP - Controller Capabilities
-//
-typedef struct {
-  UINT16 Mqes;  // Maximum Queue Entries Supported
-  UINT8  Cqr:1; // Contiguous Queues Required
-  UINT8  Ams:2; // Arbitration Mechanism Supported
-  UINT8  Rsvd1:5;
-  UINT8  To;// Timeout
-  UINT16 Dstrd:4;
-  UINT16 Nssrs:1;   // NVM Subsystem Reset Supported NSSRS
-  UINT16 Css:4; // Command Sets Supported - Bit 37
-  UINT16 Rsvd3:7;
-  UINT8  Mpsmin:4;
-  UINT8  Mpsmax:4;
-  UINT8  Rsvd4;
-} NVME_CAP;
-
-//
-// 3.1.2 Offset 08h: VS - Version
-//
-typedef struct {
-  UINT16 Mnr;   // Minor version number
-  UINT16 Mjr;   // Major version number
-} NVME_VER;
-
-//
-// 3.1.5 Offset 14h: CC - Controller Configuration
-//
-typedef struct {
-  UINT16 En:1;   // Enable
-  UINT16 Rsvd1:3;
-  UINT16 Css:3;  // I/O Command Set Selected
-  UINT16 Mps:4;  // Memory Page Size
-  UINT16 Ams:3;  // Arbitration Mechanism Selected
-  UINT16 Shn:2;  // Shutdown Notification
-  UINT8  Iosqes:4;   // I/O Submission Queue Entry Size
-  UINT8  Iocqes:4;   // I/O Completion Queue Entry Size
-  UINT8  Rsvd2;
-} NVME_CC;
-
-//
-// 3.1.6 Offset 1Ch: CSTS - Controller Status
-//
-typedef struct {
-  UINT32 Rdy:1;  // Ready
-  UINT32 Cfs:1;  // Controller Fatal Status
-  UINT32 Shst:2; // Shutdown Status
-  UINT32 Nssro:1;// NVM Subsystem Reset Occurred
-  UINT32 Rsvd1:27;
-} NVME_CSTS;
-
-//
-// 3.1.8 Offset 24h: AQA - Admin Queue Attributes

Re: [edk2] [PATCH 3/6] OvmfPkg/PlatformBootManagerLib: bring back the progress bar

[Jordan Justen]

On 2016-05-25 14:13:03, Laszlo Ersek wrote:
> On 05/25/16 21:53, Jordan Justen wrote:
> > On 2016-05-25 10:23:56, Laszlo Ersek wrote:
> >> On 05/25/16 19:00, Jordan Justen wrote:
> >>> On 2016-05-25 05:36:43, Laszlo Ersek wrote:
>  OVMF's Platform BDS used to have a nice progress bar (with
>  IntelFrameworkModulePkg BDS). We can restore it by copying the
>  PlatformBootManagerWaitCallback() function verbatim from
> 
>    Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
> 
>  It can be tested by passing the following option to QEMU (5 seconds):
> 
>    -boot menu=on,splash-time=5000
> 
>  Cc: Jordan Justen 
>  Cc: Ruiyu Ni 
>  Contributed-under: TianoCore Contribution Agreement 1.0
>  Signed-off-by: Laszlo Ersek 
>  ---
>   OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 17 
>  +
>   1 file changed, 17 insertions(+)
> 
>  diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
>  b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>  index 9eb9e390373d..dd8757f58ec3 100644
>  --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>  +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>  @@ -1425,5 +1425,22 @@ PlatformBootManagerWaitCallback (
> UINT16  TimeoutRemain
> )
>   {
>  +  EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black;
>  +  EFI_GRAPHICS_OUTPUT_BLT_PIXEL White;
>  +  UINT16Timeout;
>  +
>  +  Timeout = PcdGet16 (PcdPlatformBootTimeOut);
>  +
>  +  Black.Blue = Black.Green = Black.Red = Black.Reserved = 0;
>  +  White.Blue = White.Green = White.Red = White.Reserved = 0xFF;
> >>>
> >>> I know this came from Nt32, but how about making these global vars?
> >>>
> >>> static EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black = { 0, 0, 0, 0 };
> >>> static EFI_GRAPHICS_OUTPUT_BLT_PIXEL White = { 0xff, 0xff, 0xff, 0 };
> >>
> >> I'm okay with giving them static storage duration.
> >>
> >> With that changed,
> >> - do you want me to keep them in function scope (with the same names),
> >> - or should I move them to file scope (and then, as Andrew suggests,
> >>   rename them to, say, mPixelBlack and mPixelWhite)?
> >>
> > 
> > The part that bugged me was setting .Reserved to 0xff.
> > 
> > How about just making them initialized local variables?
> > 
> >   EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black = { 0, 0, 0, 0 };
> >   EFI_GRAPHICS_OUTPUT_BLT_PIXEL White = { 0xff, 0xff, 0xff, 0 };
> 
> That would conflict with the edk2 coding style (6.8 C Function Layout,
> "Initializing a variable as part of its declaration is illegal" --
> although it clearly doesn't cover variables with static storage duration.)
> 

I do see that in the older style guide, but not the newer ones (2.0+).

> I even suspect that the first initialization could cause some compilers
> to emit memset() intrinsics.
>

Hmm, yeah that could be a problem.

> How about:
> 
>   Black.Blue = Black.Green = Black.Red = 0;
>   White.Blue = White.Green = White.Red = 0xFF;
>   Black.Reserved = White.Reserved = 0;
> 

Sure, or a static local var.

I hope that in the case of the above code that most compilers would
see that we are really just dealing with two uint32_t values.

I guess there is the union wrapper of the struct, and combined with
the UEFI assumption of little-endian, you could force it.

-Jordan

> (I could submit a patch for Nt32Pkg too that fixed White.Reserved.)
> 
> Thanks
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 3/6] OvmfPkg/PlatformBootManagerLib: bring back the progress bar

[Laszlo Ersek]

On 05/25/16 21:53, Jordan Justen wrote:
> On 2016-05-25 10:23:56, Laszlo Ersek wrote:
>> On 05/25/16 19:00, Jordan Justen wrote:
>>> On 2016-05-25 05:36:43, Laszlo Ersek wrote:
 OVMF's Platform BDS used to have a nice progress bar (with
 IntelFrameworkModulePkg BDS). We can restore it by copying the
 PlatformBootManagerWaitCallback() function verbatim from

   Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c

 It can be tested by passing the following option to QEMU (5 seconds):

   -boot menu=on,splash-time=5000

 Cc: Jordan Justen 
 Cc: Ruiyu Ni 
 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Laszlo Ersek 
 ---
  OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 17 
 +
  1 file changed, 17 insertions(+)

 diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
 b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
 index 9eb9e390373d..dd8757f58ec3 100644
 --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
 +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
 @@ -1425,5 +1425,22 @@ PlatformBootManagerWaitCallback (
UINT16  TimeoutRemain
)
  {
 +  EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black;
 +  EFI_GRAPHICS_OUTPUT_BLT_PIXEL White;
 +  UINT16Timeout;
 +
 +  Timeout = PcdGet16 (PcdPlatformBootTimeOut);
 +
 +  Black.Blue = Black.Green = Black.Red = Black.Reserved = 0;
 +  White.Blue = White.Green = White.Red = White.Reserved = 0xFF;
>>>
>>> I know this came from Nt32, but how about making these global vars?
>>>
>>> static EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black = { 0, 0, 0, 0 };
>>> static EFI_GRAPHICS_OUTPUT_BLT_PIXEL White = { 0xff, 0xff, 0xff, 0 };
>>
>> I'm okay with giving them static storage duration.
>>
>> With that changed,
>> - do you want me to keep them in function scope (with the same names),
>> - or should I move them to file scope (and then, as Andrew suggests,
>>   rename them to, say, mPixelBlack and mPixelWhite)?
>>
> 
> The part that bugged me was setting .Reserved to 0xff.
> 
> How about just making them initialized local variables?
> 
>   EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black = { 0, 0, 0, 0 };
>   EFI_GRAPHICS_OUTPUT_BLT_PIXEL White = { 0xff, 0xff, 0xff, 0 };

That would conflict with the edk2 coding style (6.8 C Function Layout,
"Initializing a variable as part of its declaration is illegal" --
although it clearly doesn't cover variables with static storage duration.)

I even suspect that the first initialization could cause some compilers
to emit memset() intrinsics.

How about:

  Black.Blue = Black.Green = Black.Red = 0;
  White.Blue = White.Green = White.Red = 0xFF;
  Black.Reserved = White.Reserved = 0;

(I could submit a patch for Nt32Pkg too that fixed White.Reserved.)

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

Re: [edk2] [PATCH 3/6] OvmfPkg/PlatformBootManagerLib: bring back the progress bar

[Jordan Justen]

On 2016-05-25 10:23:56, Laszlo Ersek wrote:
> On 05/25/16 19:00, Jordan Justen wrote:
> > On 2016-05-25 05:36:43, Laszlo Ersek wrote:
> >> OVMF's Platform BDS used to have a nice progress bar (with
> >> IntelFrameworkModulePkg BDS). We can restore it by copying the
> >> PlatformBootManagerWaitCallback() function verbatim from
> >>
> >>   Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
> >>
> >> It can be tested by passing the following option to QEMU (5 seconds):
> >>
> >>   -boot menu=on,splash-time=5000
> >>
> >> Cc: Jordan Justen 
> >> Cc: Ruiyu Ni 
> >> Contributed-under: TianoCore Contribution Agreement 1.0
> >> Signed-off-by: Laszlo Ersek 
> >> ---
> >>  OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 17 
> >> +
> >>  1 file changed, 17 insertions(+)
> >>
> >> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
> >> b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> >> index 9eb9e390373d..dd8757f58ec3 100644
> >> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> >> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> >> @@ -1425,5 +1425,22 @@ PlatformBootManagerWaitCallback (
> >>UINT16  TimeoutRemain
> >>)
> >>  {
> >> +  EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black;
> >> +  EFI_GRAPHICS_OUTPUT_BLT_PIXEL White;
> >> +  UINT16Timeout;
> >> +
> >> +  Timeout = PcdGet16 (PcdPlatformBootTimeOut);
> >> +
> >> +  Black.Blue = Black.Green = Black.Red = Black.Reserved = 0;
> >> +  White.Blue = White.Green = White.Red = White.Reserved = 0xFF;
> > 
> > I know this came from Nt32, but how about making these global vars?
> > 
> > static EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black = { 0, 0, 0, 0 };
> > static EFI_GRAPHICS_OUTPUT_BLT_PIXEL White = { 0xff, 0xff, 0xff, 0 };
> 
> I'm okay with giving them static storage duration.
> 
> With that changed,
> - do you want me to keep them in function scope (with the same names),
> - or should I move them to file scope (and then, as Andrew suggests,
>   rename them to, say, mPixelBlack and mPixelWhite)?
> 

The part that bugged me was setting .Reserved to 0xff.

How about just making them initialized local variables?

  EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black = { 0, 0, 0, 0 };
  EFI_GRAPHICS_OUTPUT_BLT_PIXEL White = { 0xff, 0xff, 0xff, 0 };

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

[edk2] [PATCH] IntelFsp2Pkg/Tools: Add BSF bit field support in GenCfgOpt tool

[Maurice Ma]

The current GenCfgOpt tool does not generate bit fields in BSF.
This change will allow bit fields to be created in BSF for a specific
FSP UPD item. The argument for the tool is also updated to be in sync
with the old usage model in IntelFspPkg.

Cc: Jiewen Yao 
Cc: Giri P Mudusuru 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Maurice Ma 
---
 IntelFsp2Pkg/Tools/GenCfgOpt.py | 224 
 1 file changed, 113 insertions(+), 111 deletions(-)

diff --git a/IntelFsp2Pkg/Tools/GenCfgOpt.py b/IntelFsp2Pkg/Tools/GenCfgOpt.py
index 4fd0562e7534..e8cec95aa735 100644
--- a/IntelFsp2Pkg/Tools/GenCfgOpt.py
+++ b/IntelFsp2Pkg/Tools/GenCfgOpt.py
@@ -310,6 +310,7 @@ EndList
 self._BuidinOption  = {'$EN_DIS' : 'EN_DIS'}
 
 self._MacroDict   = {}
+self._PcdsDict= {}
 self._CfgBlkDict  = {}
 self._CfgPageDict = {}
 self._CfgItemList = []
@@ -374,8 +375,21 @@ EndList
   Line = Line.replace(Each, Each[2:-1])
 return Line
 
+def ExpandPcds (self, Input):
+Line = Input
+Match = re.findall("(\w+\.\w+)", Input)
+if Match:
+for PcdName in Match:
+  if PcdName in self._PcdsDict:
+  Line = Line.replace(PcdName, self._PcdsDict[PcdName])
+  else:
+  if self.Debug:
+  print "WARN : %s is not defined" % PcdName
+return Line
+
 def EvaluateExpress (self, Expr):
-ExpExpr = self.ExpandMacros(Expr)
+ExpExpr = self.ExpandPcds(Expr)
+ExpExpr = self.ExpandMacros(ExpExpr)
 LogExpr = CLogicalExpression()
 Result  = LogExpr.evaluateExpress (ExpExpr)
 if self.Debug:
@@ -411,7 +425,7 @@ EndList
 ConfigDict['value'] = newvalue
 return ""
 
-def ParseDscFile (self, DscFile, FvDir, ConfigDscFile, ExtConfigDscFile):
+def ParseDscFile (self, DscFile, FvDir):
 self._CfgItemList = []
 self._CfgPageDict = {}
 self._CfgBlkDict  = {}
@@ -419,9 +433,9 @@ EndList
 self._FvDir   = FvDir
 
 IsDefSect   = False
+IsPcdSect   = False
 IsUpdSect   = False
 IsVpdSect   = False
-Found   = False
 
 IfStack = []
 ElifStack   = []
@@ -437,10 +451,14 @@ EndList
 Handle   = False
 Match= re.match("^\[(.+)\]", DscLine)
 if Match is not None:
+IsDefSect = False
+IsPcdSect = False
+IsVpdSect = False
+IsUpdSect = False
 if  Match.group(1).lower() == "Defines".lower():
 IsDefSect = True
-IsVpdSect = False
-IsUpdSect = False
+if  Match.group(1).lower() == "PcdsFeatureFlag".lower():
+IsPcdSect = True
 elif Match.group(1).lower() == "PcdsDynamicVpd.Upd".lower():
 ConfigDict = {}
 ConfigDict['header']  = 'ON'
@@ -453,16 +471,9 @@ EndList
 ConfigDict['embed']   = ''
 ConfigDict['comment'] = ''
 ConfigDict['subreg']  = []
-IsDefSect = False
 IsUpdSect = True
-IsVpdSect = False
-Found = True
-else:
-IsDefSect = False
-IsUpdSect = False
-IsVpdSect = False
 else:
-if IsDefSect or IsUpdSect or IsVpdSect:
+if IsDefSect or IsPcdSect or IsUpdSect or IsVpdSect:
 if re.match("^!else($|\s+#.+)", DscLine):
 if IfStack:
 IfStack[-1] = not IfStack[-1]
@@ -490,41 +501,7 @@ EndList
 else:
 Match  = re.match("!(if|elseif)\s+(.+)", DscLine)
 if Match:
-IsFoundInFile = False
-MatchPcdFormat = 
re.match("^\s*(.+)\.(.+)\s*==\s*(.+)", Match.group(2))
-if MatchPcdFormat:
-   ExtConfigDsc = open(ExtConfigDscFile, 
"r")
-   ExtConfigDscLines = 
ExtConfigDsc.readlines()
-   ExtConfigDsc.close()
-   
-   while len(ExtConfigDscLines):
-   ExtConfigDscLine  = 
ExtConfigDscLines.pop(0).strip()
-   MatchExtConfigPcd = 
re.match("^\s*(.+)\s*\|\s*(.+)", ExtConfigDscLine)
-   if MatchExtConfigPcd and 
IsFoundInFile == False:
-   

Re: [edk2] [PATCH 3/6] OvmfPkg/PlatformBootManagerLib: bring back the progress bar

[Laszlo Ersek]

On 05/25/16 19:00, Jordan Justen wrote:
> On 2016-05-25 05:36:43, Laszlo Ersek wrote:
>> OVMF's Platform BDS used to have a nice progress bar (with
>> IntelFrameworkModulePkg BDS). We can restore it by copying the
>> PlatformBootManagerWaitCallback() function verbatim from
>>
>>   Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
>>
>> It can be tested by passing the following option to QEMU (5 seconds):
>>
>>   -boot menu=on,splash-time=5000
>>
>> Cc: Jordan Justen 
>> Cc: Ruiyu Ni 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek 
>> ---
>>  OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 17 +
>>  1 file changed, 17 insertions(+)
>>
>> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
>> b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>> index 9eb9e390373d..dd8757f58ec3 100644
>> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>> @@ -1425,5 +1425,22 @@ PlatformBootManagerWaitCallback (
>>UINT16  TimeoutRemain
>>)
>>  {
>> +  EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black;
>> +  EFI_GRAPHICS_OUTPUT_BLT_PIXEL White;
>> +  UINT16Timeout;
>> +
>> +  Timeout = PcdGet16 (PcdPlatformBootTimeOut);
>> +
>> +  Black.Blue = Black.Green = Black.Red = Black.Reserved = 0;
>> +  White.Blue = White.Green = White.Red = White.Reserved = 0xFF;
> 
> I know this came from Nt32, but how about making these global vars?
> 
> static EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black = { 0, 0, 0, 0 };
> static EFI_GRAPHICS_OUTPUT_BLT_PIXEL White = { 0xff, 0xff, 0xff, 0 };

I'm okay with giving them static storage duration.

With that changed,
- do you want me to keep them in function scope (with the same names),
- or should I move them to file scope (and then, as Andrew suggests,
  rename them to, say, mPixelBlack and mPixelWhite)?

Thanks
Laszlo

> Series Reviewed-by: Jordan Justen 
> 
>> +
>> +  BootLogoUpdateProgress (
>> +White,
>> +Black,
>> +L"Start boot option",
>> +White,
>> +(Timeout - TimeoutRemain) * 100 / Timeout,
>> +0
>> +);
>>  }
>>  
>> -- 
>> 1.8.3.1
>>
>>

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

Re: [edk2] [PATCH] MdePkg/BaseLib: Add more comments for safe string functions.

[Palmer, Thomas]

Reviewed-by: Thomas Palmer 

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gao, 
Liming
Sent: Sunday, May 22, 2016 9:33 PM
To: Yao, Jiewen ; edk2-devel@lists.01.org
Cc: Kinney, Michael D 
Subject: Re: [edk2] [PATCH] MdePkg/BaseLib: Add more comments for safe string 
functions.

Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Jiewen Yao
> Sent: Sunday, May 22, 2016 9:03 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Gao, Liming 
> 
> Subject: [edk2] [PATCH] MdePkg/BaseLib: Add more comments for safe 
> string functions.
> 
> Add more comments:
> 1) EDKII version safe string function is similar as the one C11.
> 2) If error is returned, the Destination is unmodified.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jiewen Yao 
> ---
>  MdePkg/Include/Library/BaseLib.h| 36
> 
>  MdePkg/Library/BaseLib/SafeString.c | 36
> 
>  2 files changed, 72 insertions(+)
> 
> diff --git a/MdePkg/Include/Library/BaseLib.h
> b/MdePkg/Include/Library/BaseLib.h
> index c41fa78..6f6bd85 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -187,6 +187,8 @@ typedef struct {
>  /**
>Returns the length of a Null-terminated Unicode string.
> 
> +  This function is similar as strlen_s defined in C11.
> +
>If String is not aligned on a 16-bit boundary, then ASSERT().
> 
>@param  String   A pointer to a Null-terminated Unicode string.
> @@ -209,10 +211,14 @@ StrnLenS (
>Copies the string pointed to by Source (including the terminating null 
> char)
>to the array pointed to by Destination.
> 
> +  This function is similar as strcpy_s defined in C11.
> +
>If Destination is not aligned on a 16-bit boundary, then ASSERT().
>If Source is not aligned on a 16-bit boundary, then ASSERT().
>If an error would be returned, then the function will also ASSERT().
> 
> +  If an error is returned, then the Destination is unmodified.
> +
>@param  Destination  A pointer to a Null-terminated Unicode 
> string.
>@param  DestMax  The maximum number of Destination Unicode
> char, including terminating null char.
> @@ -241,10 +247,14 @@ StrCpyS (
>Source to the array pointed to by Destination. If no null char is copied 
> from
>Source, then Destination[Length] is always set to null.
> 
> +  This function is similar as strncpy_s defined in C11.
> +
>If Length > 0 and Destination is not aligned on a 16-bit boundary, 
> then ASSERT().
>If Length > 0 and Source is not aligned on a 16-bit boundary, then 
> ASSERT().
>If an error would be returned, then the function will also ASSERT().
> 
> +  If an error is returned, then the Destination is unmodified.
> +
>@param  Destination  A pointer to a Null-terminated Unicode 
> string.
>@param  DestMax  The maximum number of Destination Unicode
> char, including terminating null char.
> @@ -275,10 +285,14 @@ StrnCpyS (
>Appends a copy of the string pointed to by Source (including the 
> terminating
>null char) to the end of the string pointed to by Destination.
> 
> +  This function is similar as strcat_s defined in C11.
> +
>If Destination is not aligned on a 16-bit boundary, then ASSERT().
>If Source is not aligned on a 16-bit boundary, then ASSERT().
>If an error would be returned, then the function will also ASSERT().
> 
> +  If an error is returned, then the Destination is unmodified.
> +
>@param  Destination  A pointer to a Null-terminated Unicode 
> string.
>@param  DestMax  The maximum number of Destination Unicode
> char, including terminating null char.
> @@ -311,10 +325,14 @@ StrCatS (
>copied from Source, then Destination[StrLen(Destination) + Length] 
> is always
>set to null.
> 
> +  This function is similar as strncat_s defined in C11.
> +
>If Destination is not aligned on a 16-bit boundary, then ASSERT().
>If Source is not aligned on a 16-bit boundary, then ASSERT().
>If an error would be returned, then the function will also ASSERT().
> 
> +  If an error is returned, then the Destination is unmodified.
> +
>@param  Destination  A pointer to a Null-terminated Unicode 
> string.
>@param  DestMax  The maximum number of Destination Unicode
> char, including terminating null char.
> @@ -346,6 

Re: [edk2] edk2-staging/HTTPS-TLS

[El-Haj-Mahmoud, Samer]

Thanks Jiaxin. I will pull the code and let you know if I run into issues


-Original Message-
From: Wu, Jiaxin [mailto:jiaxin...@intel.com] 
Sent: Tuesday, May 24, 2016 10:17 PM
To: El-Haj-Mahmoud, Samer ; 
edk2-devel@lists.01.org
Subject: RE: edk2-staging/HTTPS-TLS

Finished sync the branch from EDK2 master.

Thanks.
Jiaxin


> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> El- Haj-Mahmoud, Samer
> Sent: Thursday, May 19, 2016 6:10 AM
> To: Wu, Jiaxin ; edk2-devel@lists.01.org
> Subject: [edk2] edk2-staging/HTTPS-TLS
> 
> Jiaxin,
> 
> The HTTPs-TLS branch is behind EDK2 master, and they are quite a few 
> conflicts to try to keep up with both. Can you please sync the branch 
> from
> EDK2 master?
> 
> Thanks,
> --Samer
> 
> ___
> 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] MdeModulePkg RamDiskDxe: VALID_ARCH cleanup to list supported options

[El-Haj-Mahmoud, Samer]

Reviewed-by: Samer El-Haj-Mahmoud 


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Tian, 
Feng
Sent: Wednesday, May 25, 2016 12:23 AM
To: Wu, Hao A ; edk2-devel@lists.01.org
Cc: Tian, Feng 
Subject: Re: [edk2] [PATCH v2] MdeModulePkg RamDiskDxe: VALID_ARCH cleanup to 
list supported options

Reviewed-by: Feng Tian 

Thanks
Feng

-Original Message-
From: Wu, Hao A 
Sent: Tuesday, May 24, 2016 11:26 AM
To: edk2-devel@lists.01.org; Tian, Feng 
Cc: Wu, Hao A 
Subject: [PATCH v2] MdeModulePkg RamDiskDxe: VALID_ARCH cleanup to list 
supported options

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu 
---
 MdeModulePkg/MdeModulePkg.dsc | 2 +-
 MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc 
index 936f46d..abce62d 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -330,7 +330,6 @@
   MdeModulePkg/Universal/Disk/PartitionDxe/PartitionDxe.inf
   MdeModulePkg/Universal/Disk/UnicodeCollation/EnglishDxe/EnglishDxe.inf
   MdeModulePkg/Universal/Disk/CdExpressPei/CdExpressPei.inf
-  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
   MdeModulePkg/Universal/DriverSampleDxe/DriverSampleDxe.inf
   MdeModulePkg/Universal/HiiDatabaseDxe/HiiDatabaseDxe.inf
   
MdeModulePkg/Universal/MemoryTest/GenericMemoryTestDxe/GenericMemoryTestDxe.inf
@@ -449,6 +448,7 @@
   MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmDxe.inf
   MdeModulePkg/Universal/RegularExpressionDxe/RegularExpressionDxe.inf
   
MdeModulePkg/Universal/SmmCommunicationBufferDxe/SmmCommunicationBufferDxe.inf
+  MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
 
 [Components.X64]
   MdeModulePkg/Universal/CapsulePei/CapsuleX64.inf
diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf 
b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
index d1eb429..cdd2da6 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDxe.inf
@@ -26,7 +26,7 @@
 #
 # The following information is for reference only and not required by the 
build tools.
 #
-#  VALID_ARCHITECTURES  = IA32 X64 IPF EBC
+#  VALID_ARCHITECTURES  = IA32 X64 ARM AARCH64
 #
 
 [Sources]
--
1.9.5.msysgit.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 1/2] MdePkg: Correct EFI_HTTP_CONFIGURE return status value

[El-Haj-Mahmoud, Samer]

Reviewed-by: Samer El-Haj-Mahmoud 


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jiaxin Wu
Sent: Wednesday, May 25, 2016 3:28 AM
To: edk2-devel@lists.01.org
Cc: Ye Ting ; Zhang Lubo ; Fu Siyuan 

Subject: [edk2] [Patch 1/2] MdePkg: Correct EFI_HTTP_CONFIGURE return status 
value

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Zhang Lubo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 MdePkg/Include/Protocol/Http.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MdePkg/Include/Protocol/Http.h b/MdePkg/Include/Protocol/Http.h 
index 22201b4..269416c 100644
--- a/MdePkg/Include/Protocol/Http.h
+++ b/MdePkg/Include/Protocol/Http.h
@@ -339,11 +339,10 @@ EFI_STATUS
   @param[in]  HttpConfigData  Pointer to the configure data to configure 
the instance.
 
   @retval EFI_SUCCESS Operation succeeded.
   @retval EFI_INVALID_PARAMETER   One or more of the following conditions is 
TRUE:
   This is NULL.
-  HttpConfigData is NULL.
   HttpConfigData->LocalAddressIsIPv6 is FALSE 
and
   HttpConfigData->IPv4Node is NULL.
   HttpConfigData->LocalAddressIsIPv6 is TRUE 
and
   HttpConfigData->IPv6Node is NULL.
   @retval EFI_ALREADY_STARTED Reinitialize this HTTP instance without 
calling
--
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] [PATCH 3/6] OvmfPkg/PlatformBootManagerLib: bring back the progress bar

[Andrew Fish]

> On May 25, 2016, at 10:00 AM, Jordan Justen  wrote:
> 
> On 2016-05-25 05:36:43, Laszlo Ersek wrote:
>> OVMF's Platform BDS used to have a nice progress bar (with
>> IntelFrameworkModulePkg BDS). We can restore it by copying the
>> PlatformBootManagerWaitCallback() function verbatim from
>> 
>>  Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
>> 
>> It can be tested by passing the following option to QEMU (5 seconds):
>> 
>>  -boot menu=on,splash-time=5000
>> 
>> Cc: Jordan Justen 
>> Cc: Ruiyu Ni 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek 
>> ---
>> OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 17 +
>> 1 file changed, 17 insertions(+)
>> 
>> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
>> b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>> index 9eb9e390373d..dd8757f58ec3 100644
>> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
>> @@ -1425,5 +1425,22 @@ PlatformBootManagerWaitCallback (
>>   UINT16  TimeoutRemain
>>   )
>> {
>> +  EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black;
>> +  EFI_GRAPHICS_OUTPUT_BLT_PIXEL White;
>> +  UINT16Timeout;
>> +
>> +  Timeout = PcdGet16 (PcdPlatformBootTimeOut);
>> +
>> +  Black.Blue = Black.Green = Black.Red = Black.Reserved = 0;
>> +  White.Blue = White.Green = White.Red = White.Reserved = 0xFF;
> 
> I know this came from Nt32, but how about making these global vars?
> 

Do you need to change the name if they are global? 

Thanks,

Andrew Fish

> static EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black = { 0, 0, 0, 0 };
> static EFI_GRAPHICS_OUTPUT_BLT_PIXEL White = { 0xff, 0xff, 0xff, 0 };
> 
> Series Reviewed-by: Jordan Justen 
> 
>> +
>> +  BootLogoUpdateProgress (
>> +White,
>> +Black,
>> +L"Start boot option",
>> +White,
>> +(Timeout - TimeoutRemain) * 100 / Timeout,
>> +0
>> +);
>> }
>> 
>> -- 
>> 1.8.3.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 3/6] OvmfPkg/PlatformBootManagerLib: bring back the progress bar

[Jordan Justen]

On 2016-05-25 05:36:43, Laszlo Ersek wrote:
> OVMF's Platform BDS used to have a nice progress bar (with
> IntelFrameworkModulePkg BDS). We can restore it by copying the
> PlatformBootManagerWaitCallback() function verbatim from
> 
>   Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c
> 
> It can be tested by passing the following option to QEMU (5 seconds):
> 
>   -boot menu=on,splash-time=5000
> 
> Cc: Jordan Justen 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
> b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> index 9eb9e390373d..dd8757f58ec3 100644
> --- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> +++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
> @@ -1425,5 +1425,22 @@ PlatformBootManagerWaitCallback (
>UINT16  TimeoutRemain
>)
>  {
> +  EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black;
> +  EFI_GRAPHICS_OUTPUT_BLT_PIXEL White;
> +  UINT16Timeout;
> +
> +  Timeout = PcdGet16 (PcdPlatformBootTimeOut);
> +
> +  Black.Blue = Black.Green = Black.Red = Black.Reserved = 0;
> +  White.Blue = White.Green = White.Red = White.Reserved = 0xFF;

I know this came from Nt32, but how about making these global vars?

static EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black = { 0, 0, 0, 0 };
static EFI_GRAPHICS_OUTPUT_BLT_PIXEL White = { 0xff, 0xff, 0xff, 0 };

Series Reviewed-by: Jordan Justen 

> +
> +  BootLogoUpdateProgress (
> +White,
> +Black,
> +L"Start boot option",
> +White,
> +(Timeout - TimeoutRemain) * 100 / Timeout,
> +0
> +);
>  }
>  
> -- 
> 1.8.3.1
> 
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] edk2 llvm branch

[Andrew Fish]

> On May 25, 2016, at 9:43 AM, Shi, Steven  wrote:
> 
> Hi Andrew,
> For the Clang LTO generate wrong code on Qemu X64 issue, I found it is 
> related to the high address (>2G) wrong sign-extend displacements to 64 bits. 
> E.g. I hope “jmp qword ptr 0xfffcdd54[0]” in 64 bits mode is to jump to the 
> address in [0xfffcdd54+0], but in fact, clang lto generate 
> instruction to jump to address in [0xfffcdd54+0]. Qemu X64 is very 
> special that its SecMain run in 64 bits mode, and its execution address 
> happen to be 0xfffc. If there is any instruction need indirect 
> address access, the clang lto code will wrong access very high 
> 0xfffc rang, which cause page fault error in Qemu X64 sec. This 
> is why this issue does not happen in IA32 tip, but only in X64 tip.
>  
> BTW, could you help to build the XCode LTO Qemu X64 image as below and send 
> it (edk2\Build\OvmfX64\DEBUG_CLANGLTO38\FV\OVMF.fd) to me to test whether the 
> XCode LTO Qemu X64 image really work?
> build -a X64 -t CLANGLTO38(replace it with your XCodeLTO tool chain) -p 
> OvmfPkg/OvmfPkgX64.dsc -n 5 -b DEBUG -DDEBUG_ON_SERIAL_PORT
>  
> Below is this issue detail info:
> You know, Clang LTO aggressively inline (or collapse) code together, and then 
> like to use many Jump far, absolute indirect, instructions, which is quite 
> different from Clang normal build. In the attachment, there is a LTO assembly 
> code example of MdePkg\Library\BasePrintLib\PrintLibInternal.c. You can 
> create it with below command:
> build -a X64 -t CLANGLTO38(replace it with your XCodeLTO tool chain) -p 
> OvmfPkg/OvmfPkgX64.dsc -n 5 -b DEBUG -DDEBUG_ON_SERIAL_PORT -m 
> MdePkg/Library/BasePrintLib/BasePrintLib.inf
> llc 
> Build/OvmfX64/DEBUG_CLANGLTO38/X64/MdePkg/Library/BasePrintLib/BasePrintLib/OUTPUT/PrintLibInternal.obj
>  -o PrintLibInternal.s
>  
> And in this PrintLibInternal.s, you can see the Clang LTO use two indirect 
> Jump far as below. These two indirect Jump far cause the Qemu X64 SecMain 
> page fault.
> # /home/jshi19/edk2-fork/MdePkg/Library/BasePrintLib/PrintLibInternal.c:446:9
> ...
> jmpq *.LJTI3_0(,%rdx,8)
> ...
>  
> # /home/jshi19/edk2-fork/MdePkg/Library/BasePrintLib/PrintLibInternal.c:528:7
> 
> jmpq *.LJTI3_1(,%rax,8)
> ...
>  
> .LJTI3_0:
> .quad.LBB3_36
> .quad.LBB3_33
> .quad.LBB3_35
> ... ...
>  
> .LJTI3_1:
> .quad.LBB3_56
> .quad.LBB3_26
> .quad.LBB3_89
> ...
>  
> To more clearly show the page fault arch info, I leaverage Simics MinnowMax 
> to re-run the Qemu X64 SecMain LTO code to reproduce it. I add one more line 
> in line 528 to let simics stop just before the page fault point. You can see 
> the new PrintLibInternal.c and its LTO assembly code in attached 
> PrintLibInternal.c-Simics and PrintLibInternal.s-Simics. Below is the page 
> fault point:
>  
> .loc 2 528 7 is_stmt 0   # 
> /home/jshi19/edk2-fork/MdePkg/Library/BasePrintLib/PrintLibInternal.c:528:7
> callq   MAGIC_SHOW_VALUE
> .loc 2 529 15 is_stmt 1  # 
> /home/jshi19/edk2-fork/MdePkg/Library/BasePrintLib/PrintLibInternal.c:529:15
> movq-416(%rbp), %rax
> .loc 2 529 7 is_stmt 0   # 
> /home/jshi19/edk2-fork/MdePkg/Library/BasePrintLib/PrintLibInternal.c:529:7
> cmpq $87, %rax
> jle   .LBB3_66
> # BB#72:#   in Loop: Header=BB3_23 Depth=1
> leaq   -97(%rax), %rcx
> cmpq $23, %rcx
> ja.LBB3_73
> # BB#76:#   in Loop: Header=BB3_23 Depth=1
> jmpq *.LJTI3_0(,%rcx,8)
> … …
>  
> In below Simics, you can clearly see the “jmp qword ptr 0xfffcdd54[rcx*8]” 
> instruction cause the processor access logic address 0xfffcdd54 (not 
> we hoped 0xfffcdd54)

Steven,

Can you dump the bytes for the instruction and look it up in the Intel manual. 
I did not think that a jmp does a sign extend? I usually dump the code in lldb 
to get the byte, assembly, and source mixed together so I'm not sure how to do 
it in your setup.

Thanks,

Andrew Fish

> which cause page fault exception, then the page fault trigger General 
> Protection (Exception 13) because there is not exception handler in Sec parse.
> 
> The content in [0xfffcdd54] is 0xFFFCC8FA as below
> 
>  
> There is no page table to map logic address 0xfffcdd54, so there is 
> no content in [0xfffcdd54] :
> 
>  
>  
>  
>  
> Steven Shi
> Intel\SSG\STO\UEFI Firmware
>  
> Tel: +86 021-61166522
> iNet: 821-6522
>  
>  <> 
> 

[edk2] [PATCH 2/6] OvmfPkg/PlatformBootManagerLib: rebase boot logo display to BootLogoLib

[Laszlo Ersek]

In the course of porting OvmfPkg to the MdeModulePkg BDS, commit
817fb3ac2a78

  OvmfPkg/PlatformBootManagerLib: Add EnableQuietBoot & DisableQuietBoot

open-coded the EnableQuietBoot() function (and its dependencies / friends)
from IntelFrameworkModulePkg BDS.

This code duplication can be avoided; the functionality is available from
the following three libraries in MdeModulePkg:

- BootLogoLib: provides the BootLogoEnableLogo() function. It does not
  provide the internal ConvertBmpToGopBlt() function -- that one is
  delegated to ImageDecoderLib (function DecodeImage()).

- ImageDecoderLib: a general library that registers decoder plugins for
  specific image formats, and provides the generic DecodeImage() on top.

- BmpImageDecoderLib: one of said decoder plugins, for handling BMP images
  (which is the format of our logo).

In this patch, we revert 817fb3ac2a78, and atomically incorporate the
above libraries. This is inspired by Nt32Pkg commit 859e75c4fc42:

  Nt32Pkg: Use BootLogoLib for logo and progress bar drawing.

Cc: Jordan Justen 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc   |   3 +
 OvmfPkg/OvmfPkgIa32X64.dsc|   3 +
 OvmfPkg/OvmfPkgX64.dsc|   3 +
 OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |   7 +-
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h  |  33 +-
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c  |   8 +-
 OvmfPkg/Library/PlatformBootManagerLib/QuietBoot.c| 673 

 7 files changed, 18 insertions(+), 712 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 1eb5d0bc9bcb..338c9ba4f8e5 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -77,6 +77,8 @@ [LibraryClasses]
   HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
   SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
   
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
+  BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
+  ImageDecoderLib|MdeModulePkg/Library/ImageDecoderLib/ImageDecoderLib.inf
   FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
@@ -562,6 +564,7 @@ [Components]
   PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
+  NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
 !ifdef $(CSM_ENABLE)
   NULL|OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
   
NULL|IntelFrameworkModulePkg/Library/LegacyBootManagerLib/LegacyBootManagerLib.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index ea381a023f7e..8475280b2cda 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -82,6 +82,8 @@ [LibraryClasses]
   HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
   SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
   
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
+  BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
+  ImageDecoderLib|MdeModulePkg/Library/ImageDecoderLib/ImageDecoderLib.inf
   FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
@@ -571,6 +573,7 @@ [Components.X64]
   PcAtChipsetPkg/PcatRealTimeClockRuntimeDxe/PcatRealTimeClockRuntimeDxe.inf
   MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
 
+  NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
 !ifdef $(CSM_ENABLE)
   NULL|OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
   
NULL|IntelFrameworkModulePkg/Library/LegacyBootManagerLib/LegacyBootManagerLib.inf
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index d37a206d5263..200c06baaa16 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -82,6 +82,8 @@ [LibraryClasses]
   HiiLib|MdeModulePkg/Library/UefiHiiLib/UefiHiiLib.inf
   SortLib|MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
   
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
+  BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
+  ImageDecoderLib|MdeModulePkg/Library/ImageDecoderLib/ImageDecoderLib.inf
   FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   DxeServicesLib|MdePkg/Library/DxeServicesLib/DxeServicesLib.inf
@@ -569,6 +571,7 @@ [Components]
   

[edk2] [PATCH 1/6] MdeModulePkg/BootLogoLib: pull GraphicsOutput protocol into class header

[Laszlo Ersek]

The BootLogoUpdateProgress() function uses the
EFI_GRAPHICS_OUTPUT_BLT_PIXEL type in its parameter list, but the protocol
header that defines this type is not included. This breaks dependent C
source files that don't otherwise include the GraphicsOutput protocol
header. Supply the necessary include directive.

(Similarly, BootLogoEnableLogo() uses
EDKII_PLATFORM_LOGO_DISPLAY_ATTRIBUTE in its parameter list. For that
however, the PlatformLogo protocol header is included already.)

Cc: Feng Tian 
Cc: Jordan Justen 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 MdeModulePkg/Include/Library/BootLogoLib.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MdeModulePkg/Include/Library/BootLogoLib.h 
b/MdeModulePkg/Include/Library/BootLogoLib.h
index b39d61b7c3e5..55fe4b11cc4e 100644
--- a/MdeModulePkg/Include/Library/BootLogoLib.h
+++ b/MdeModulePkg/Include/Library/BootLogoLib.h
@@ -17,6 +17,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #define _BOOT_LOGO_LIB_H_
 
 #include 
+#include 
 
 /**
   Show LOGO on all consoles.
-- 
1.8.3.1


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

[edk2] [PATCH 0/6] OvmfPkg, ArmVirtPkg: (re)introduce the progress bar

[Laszlo Ersek]

OVMF used to have a progress bar, but it went lost with the port to
MdeModulePkg BDS. I never considered this a major issue, but the
progress bar does look nice, and given how simply it can be reinstated
(using MdeModulePkg libraries), we should do that.

ArmVirtPkg never had a progress bar; this series adds it.

You should look at the diffstat, and like it.

Public branch: .

Cc: Ard Biesheuvel 
Cc: Feng Tian 
Cc: Jordan Justen 
Cc: Ruiyu Ni 

Thanks
Laszlo

Laszlo Ersek (6):
  MdeModulePkg/BootLogoLib: pull GraphicsOutput protocol into class
header
  OvmfPkg/PlatformBootManagerLib: rebase boot logo display to
BootLogoLib
  OvmfPkg/PlatformBootManagerLib: bring back the progress bar
  OvmfPkg/PlatformBootManagerLib: keep the logo after connecting devices
  ArmVirtPkg/PlatformBootManagerLib: rebase boot logo display to
BootLogoLib
  ArmVirtPkg/PlatformBootManagerLib: introduce the progress bar

 ArmVirtPkg/ArmVirtQemu.dsc   |   7 +-
 ArmVirtPkg/ArmVirtQemuKernel.dsc |   7 +-
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c   |  26 +-
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.h   |  29 -
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |   8 +-
 ArmVirtPkg/Library/PlatformBootManagerLib/QuietBoot.c| 680 

 MdeModulePkg/Include/Library/BootLogoLib.h   |   1 +
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c |  30 +-
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.h |  33 +-
 OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf|   7 +-
 OvmfPkg/Library/PlatformBootManagerLib/QuietBoot.c   | 673 
---
 OvmfPkg/OvmfPkgIa32.dsc  |   3 +
 OvmfPkg/OvmfPkgIa32X64.dsc   |   3 +
 OvmfPkg/OvmfPkgX64.dsc   |   3 +
 14 files changed, 74 insertions(+), 1436 deletions(-)
 delete mode 100644 ArmVirtPkg/Library/PlatformBootManagerLib/QuietBoot.c
 delete mode 100644 OvmfPkg/Library/PlatformBootManagerLib/QuietBoot.c

-- 
1.8.3.1

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

[edk2] [PATCH 5/6] ArmVirtPkg/PlatformBootManagerLib: rebase boot logo display to BootLogoLib

[Laszlo Ersek]

In the course of porting ArmVirtPkg to the MdeModulePkg BDS, commit
1f73aef50c5e

  ArmVirtPkg/PlatformBootManagerLib: add EnableQuietBoot & DisableQuietBoot

open-coded the EnableQuietBoot() function (and its dependencies / friends)
from IntelFrameworkModulePkg BDS.

This code duplication can be avoided; the functionality is available from
the following three libraries in MdeModulePkg:

- BootLogoLib: provides the BootLogoEnableLogo() function. It does not
  provide the internal ConvertBmpToGopBlt() function -- that one is
  delegated to ImageDecoderLib (function DecodeImage()).

- ImageDecoderLib: a general library that registers decoder plugins for
  specific image formats, and provides the generic DecodeImage() on top.

- BmpImageDecoderLib: one of said decoder plugins, for handling BMP images
  (which is the format of our logo).

In this patch, we revert 1f73aef50c5e, and atomically incorporate the
above libraries. This is inspired by Nt32Pkg commit 859e75c4fc42:

  Nt32Pkg: Use BootLogoLib for logo and progress bar drawing.

Cc: Ard Biesheuvel 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 ArmVirtPkg/ArmVirtQemu.dsc   |   7 +-
 ArmVirtPkg/ArmVirtQemuKernel.dsc |   7 +-
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf |   8 +-
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.h   |  29 -
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c   |   9 +-
 ArmVirtPkg/Library/PlatformBootManagerLib/QuietBoot.c| 680 

 6 files changed, 21 insertions(+), 719 deletions(-)

diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index cd4a50d5eaa3..32a5aa977401 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -60,6 +60,8 @@ [LibraryClasses.common]
 
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
+  BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
+  ImageDecoderLib|MdeModulePkg/Library/ImageDecoderLib/ImageDecoderLib.inf
   
PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
@@ -346,7 +348,10 @@ [Components.common]
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
-  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
+  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
+
+  NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
+  }
   MdeModulePkg/Application/UiApp/UiApp.inf {
 
   NULL|MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index 9982dee9365d..264bd445ea4e 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -59,6 +59,8 @@ [LibraryClasses.common]
 
   CapsuleLib|MdeModulePkg/Library/DxeCapsuleLibNull/DxeCapsuleLibNull.inf
   
UefiBootManagerLib|MdeModulePkg/Library/UefiBootManagerLib/UefiBootManagerLib.inf
+  BootLogoLib|MdeModulePkg/Library/BootLogoLib/BootLogoLib.inf
+  ImageDecoderLib|MdeModulePkg/Library/ImageDecoderLib/ImageDecoderLib.inf
   
PlatformBootManagerLib|ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
   
CustomizedDisplayLib|MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
   QemuBootOrderLib|OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf
@@ -322,7 +324,10 @@ [Components.common]
   MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   MdeModulePkg/Universal/DisplayEngineDxe/DisplayEngineDxe.inf
   MdeModulePkg/Universal/SetupBrowserDxe/SetupBrowserDxe.inf
-  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
+  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
+
+  NULL|MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.inf
+  }
   MdeModulePkg/Application/UiApp/UiApp.inf {
 
   NULL|MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
diff --git 
a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index 2500ad9d6805..9c95b69cc974 100644
--- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -33,7 +33,6 @@ [Defines]
 [Sources]
   PlatformBm.c
   QemuKernel.c
-  QuietBoot.c
 
 [Packages]
   IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
@@ -45,9 +44,9 @@ [Packages]
 [LibraryClasses]
   BaseLib
   

[edk2] [PATCH 3/6] OvmfPkg/PlatformBootManagerLib: bring back the progress bar

[Laszlo Ersek]

OVMF's Platform BDS used to have a nice progress bar (with
IntelFrameworkModulePkg BDS). We can restore it by copying the
PlatformBootManagerWaitCallback() function verbatim from

  Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c

It can be tested by passing the following option to QEMU (5 seconds):

  -boot menu=on,splash-time=5000

Cc: Jordan Justen 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index 9eb9e390373d..dd8757f58ec3 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -1425,5 +1425,22 @@ PlatformBootManagerWaitCallback (
   UINT16  TimeoutRemain
   )
 {
+  EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black;
+  EFI_GRAPHICS_OUTPUT_BLT_PIXEL White;
+  UINT16Timeout;
+
+  Timeout = PcdGet16 (PcdPlatformBootTimeOut);
+
+  Black.Blue = Black.Green = Black.Red = Black.Reserved = 0;
+  White.Blue = White.Green = White.Red = White.Reserved = 0xFF;
+
+  BootLogoUpdateProgress (
+White,
+Black,
+L"Start boot option",
+White,
+(Timeout - TimeoutRemain) * 100 / Timeout,
+0
+);
 }
 
-- 
1.8.3.1


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

[edk2] [PATCH 6/6] ArmVirtPkg/PlatformBootManagerLib: introduce the progress bar

[Laszlo Ersek]

ArmVirtPkg's Platform BDS has never had a progress bar. We can easily add
one, by copying the PlatformBootManagerWaitCallback() function verbatim
from

  Nt32Pkg/Library/PlatformBootManagerLib/PlatformBootManager.c

It can be tested by passing the following option to QEMU (5 seconds):

  -boot menu=on,splash-time=5000

Cc: Ard Biesheuvel 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c 
b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
index b7e02f3d00f4..88441949492b 100644
--- a/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
+++ b/ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c
@@ -573,4 +573,21 @@ PlatformBootManagerWaitCallback (
   UINT16  TimeoutRemain
   )
 {
+  EFI_GRAPHICS_OUTPUT_BLT_PIXEL Black;
+  EFI_GRAPHICS_OUTPUT_BLT_PIXEL White;
+  UINT16Timeout;
+
+  Timeout = PcdGet16 (PcdPlatformBootTimeOut);
+
+  Black.Blue = Black.Green = Black.Red = Black.Reserved = 0;
+  White.Blue = White.Green = White.Red = White.Reserved = 0xFF;
+
+  BootLogoUpdateProgress (
+White,
+Black,
+L"Start boot option",
+White,
+(Timeout - TimeoutRemain) * 100 / Timeout,
+0
+);
 }
-- 
1.8.3.1

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

[edk2] [PATCH 4/6] OvmfPkg/PlatformBootManagerLib: keep the logo after connecting devices

[Laszlo Ersek]

OVMF (unlike ArmVirtPkg) has traditionally cleared the screen after
connecting devices. This is not really necessary, and keeping the logo up
while the progress bar is advancing at the bottom looks great. So don't
clear the screen.

Cc: Jordan Justen 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index dd8757f58ec3..30eaf3c7374a 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -1200,11 +1200,6 @@ Returns:
   EfiBootManagerConnectAll ();
 
   PciAcpiInitialization ();
-
-  //
-  // Clear the logo after all devices are connected.
-  //
-  gST->ConOut->ClearScreen (gST->ConOut);
 }
 
 /**
-- 
1.8.3.1


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

Re: [edk2] [PATCH] OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no CSM

[Laszlo Ersek]

On 05/24/16 22:53, Jordan Justen wrote:
> Reviewed-by: Jordan Justen 

Thank you guys for the reviews. Commit
855743f7177459bea95798e59b6b18dab867710c.

Cheers
Laszlo

> On 2016-05-18 15:12:53, Laszlo Ersek wrote:
>> According to edk2 commit
>>
>>   "MdeModulePkg/PciBus: do not improperly degrade resource"
>>
>> and to the EFI_INCOMPATIBLE_PCI_DEVICE_SUPPORT_PROTOCOL definition in the
>> Platform Init 1.4a specification, a platform can provide such a protocol
>> in order to influence the PCI resource allocation performed by the PCI Bus
>> driver.
>>
>> In particular it is possible instruct the PCI Bus driver, with a
>> "wildcard" hint, to allocate the 64-bit MMIO BARs of a device in 64-bit
>> address space, regardless of whether the device features an option ROM.
>>
>> (By default, the PCI Bus driver considers an option ROM reason enough for
>> allocating the 64-bit MMIO BARs in 32-bit address space. It cannot know if
>> BDS will launch a legacy boot option, and under legacy boot, a legacy BIOS
>> binary from a combined option ROM could be dispatched, and fail to access
>> MMIO BARs in 64-bit address space.)
>>
>> In platform code we can ascertain whether a CSM is present or not. If not,
>> then legacy BIOS binaries in option ROMs can't be dispatched, hence the
>> BAR degradation is detrimental, and we should prevent it. This is expected
>> to conserve the 32-bit address space for 32-bit MMIO BARs.
>>
>> The driver added in this patch could be simplified based on the following
>> facts:
>>
>> - In the Ia32 build, the 64-bit MMIO aperture is always zero-size, hence
>>   the driver will exit immediately. Therefore the driver could be omitted
>>   from the Ia32 build.
>>
>> - In the Ia32X64 and X64 builds, the driver could be omitted if CSM_ENABLE
>>   was defined (because in that case the degradation would be justified).
>>   On the other hand, if CSM_ENABLE was undefined, then the driver could be
>>   included, and it could provide the hint unconditionally (without looking
>>   for the Legacy BIOS protocol).
>>
>> These short-cuts are not taken because they would increase the differences
>> between the OVMF DSC/FDF files. If we can manage without extreme
>> complexity, we should use dynamic logic (vs. build time configuration),
>> plus keep conditional compilation to a minimum.
>>
>> Cc: Jordan Justen 
>> Cc: Ruiyu Ni 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek 
>> ---
>>
>> Notes:
>> This patch will make a difference only when Ray's patch at
>> 
>> is committed.
>>
>>  OvmfPkg/OvmfPkgIa32.dsc  |  
>>  1 +
>>  OvmfPkg/OvmfPkgIa32X64.dsc   |  
>>  1 +
>>  OvmfPkg/OvmfPkgX64.dsc   |  
>>  1 +
>>  OvmfPkg/OvmfPkgIa32.fdf  |  
>>  1 +
>>  OvmfPkg/OvmfPkgIa32X64.fdf   |  
>>  1 +
>>  OvmfPkg/OvmfPkgX64.fdf   |  
>>  1 +
>>  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf |  
>> 50 +++
>>  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.c   | 
>> 353 
>>  8 files changed, 409 insertions(+)
>>
>> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
>> index 45569f2875b5..1becb65cd878 100644
>> --- a/OvmfPkg/OvmfPkgIa32.dsc
>> +++ b/OvmfPkg/OvmfPkgIa32.dsc
>> @@ -552,6 +552,7 @@ [Components]
>>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>>UefiCpuPkg/CpuDxe/CpuDxe.inf
>>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
>> +  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>>MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
>>  
>>PciHostBridgeLib|OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf
>> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
>> index 05ff1c914455..3d838cdcb125 100644
>> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
>> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
>> @@ -561,6 +561,7 @@ [Components.X64]
>>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>>UefiCpuPkg/CpuDxe/CpuDxe.inf
>>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
>> +  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
>>MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf {
>>  
>>PciHostBridgeLib|OvmfPkg/Library/PciHostBridgeLib/PciHostBridgeLib.inf
>> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
>> index 54d4413f11f6..16d58bad7865 100644
>> --- a/OvmfPkg/OvmfPkgX64.dsc
>> +++ b/OvmfPkg/OvmfPkgX64.dsc
>> @@ -559,6 +559,7 @@ [Components]
>>UefiCpuPkg/CpuIo2Dxe/CpuIo2Dxe.inf
>>UefiCpuPkg/CpuDxe/CpuDxe.inf
>>PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
>> 

Re: [edk2] StdLib for EFI DRIVER type

[jabir]

Thanks Jaben, David, I am trying to link JSON parser to a UEFI driver which
uses mathlib, stringlib etc.. Let me try to create wrappers which uses
calls form MdePkg/MdeModulePkg.


Thanks,
Jabir

On Mon, May 23, 2016 at 10:51 PM, David Van Arnem 
wrote:

> On 05/23/2016 08:15 AM, jabir wrote:
> > Hi,
> >
> > I found that StdLib package can be only used for Apps in shell
> > environment.. Is there any way to port StdLib for EFI DRIVER type? Is
> there
> > any alternate package that can be used?
> > Please help. Thanks in advance.
>
> Hi Jabir,
>
> What functions do you need from StdLib?  There are a number of libraries
> in both MdeModulePkg and MdePkg that likely will provide what you need.
> For example, MdePkg/Library/UefiLib provides functionality for printing
> messages to the console/standard error device (among other things).
>
> David
>
> >
> > --
> > Jabir
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> >
>
>
> --
> Thanks,
> David Van Arnem
>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 0/6] OvmfPkg, ArmVirtPkg: remove compatibility with IntelFrameworkModulePkg BDS

[Laszlo Ersek]

On 05/24/16 23:15, Jordan Justen wrote:
> Series Reviewed-by: Jordan Justen 

Thanks all for the reviews. Commit range
8caa3caaed4b32d699b79c6d5aaa606b52d740e7..d85c5e31ed2b550dd801f82e4ddb5f7583332098.

Cheers
Laszlo

> On 2016-05-17 12:59:10, Laszlo Ersek wrote:
>> Mainly triggered by
>> 
>> from about a week ago. In patch #2 the reasons are listed in more
>> detail.
>>
>> Public branch: .
>>
>> Cc: Ard Biesheuvel 
>> Cc: Gary Ching-Pang Lin 
>> Cc: Jordan Justen 
>> Cc: Ruiyu Ni 
>>
>> Thanks
>> Laszlo
>>
>> Laszlo Ersek (6):
>>   OvmfPkg/README: refer to MdeModulePkg & PlatformBootManagerLib in
>> examples
>>   OvmfPkg: remove USE_OLD_BDS build fallback macro
>>   OvmfPkg: remove PlatformBdsLib instance
>>   OvmfPkg: remove QemuBootOrderLib instance
>>   OvmfPkg, ArmVirtPkg: clean up SetBootOrderFromQemu() parameter list
>>   OvmfPkg, ArmVirtPkg: rename QemuNewBootOrderLib to QemuBootOrderLib
>>
>>  ArmVirtPkg/ArmVirtQemu.dsc   |2 +-
>>  ArmVirtPkg/ArmVirtQemuKernel.dsc |2 +-
>>  OvmfPkg/OvmfPkgIa32.dsc  |   21 +-
>>  OvmfPkg/OvmfPkgIa32X64.dsc   |   21 +-
>>  OvmfPkg/OvmfPkgX64.dsc   |   21 +-
>>  OvmfPkg/OvmfPkgIa32.fdf  |4 -
>>  OvmfPkg/OvmfPkgIa32X64.fdf   |4 -
>>  OvmfPkg/OvmfPkgX64.fdf   |4 -
>>  OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf|   73 -
>>  OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.inf|8 +-
>>  OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.inf |   68 -
>>  OvmfPkg/Include/Library/QemuBootOrderLib.h   |   11 +-
>>  OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h |  292 ---
>>  OvmfPkg/Library/QemuNewBootOrderLib/ExtraRootBusMap.h|   40 -
>>  ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c   |2 +-
>>  OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c | 1592 
>> 
>>  OvmfPkg/Library/PlatformBdsLib/PlatformData.c|   51 -
>>  OvmfPkg/Library/PlatformBdsLib/QemuKernel.c  |  170 --
>>  OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c |2 +-
>>  OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c  |  163 +-
>>  OvmfPkg/Library/QemuNewBootOrderLib/ExtraRootBusMap.c|  313 
>>  OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.c   | 1954 
>> 
>>  OvmfPkg/README   |4 +-
>>  23 files changed, 126 insertions(+), 4696 deletions(-)
>>  delete mode 100644 OvmfPkg/Library/PlatformBdsLib/PlatformBdsLib.inf
>>  delete mode 100644 OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.inf
>>  delete mode 100644 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.h
>>  delete mode 100644 OvmfPkg/Library/QemuNewBootOrderLib/ExtraRootBusMap.h
>>  delete mode 100644 OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c
>>  delete mode 100644 OvmfPkg/Library/PlatformBdsLib/PlatformData.c
>>  delete mode 100644 OvmfPkg/Library/PlatformBdsLib/QemuKernel.c
>>  delete mode 100644 OvmfPkg/Library/QemuNewBootOrderLib/ExtraRootBusMap.c
>>  delete mode 100644 OvmfPkg/Library/QemuNewBootOrderLib/QemuBootOrderLib.c
>>
>> -- 
>> 1.8.3.1
>>
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 

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

[edk2] [Patch 0/2] Correct HttpConfigure parameter check

[Jiaxin Wu]

Jiaxin Wu (2):
  MdePkg: Correct EFI_HTTP_CONFIGURE return status value
  NetworkPkg: Correct HttpConfigure parameter check

 MdePkg/Include/Protocol/Http.h | 1 -
 NetworkPkg/HttpDxe/HttpImpl.c  | 9 +
 NetworkPkg/HttpDxe/HttpImpl.h  | 1 -
 3 files changed, 5 insertions(+), 6 deletions(-)

-- 
1.9.5.msysgit.1

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

[edk2] [Patch 1/2] MdePkg: Correct EFI_HTTP_CONFIGURE return status value

[Jiaxin Wu]

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Zhang Lubo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 MdePkg/Include/Protocol/Http.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MdePkg/Include/Protocol/Http.h b/MdePkg/Include/Protocol/Http.h
index 22201b4..269416c 100644
--- a/MdePkg/Include/Protocol/Http.h
+++ b/MdePkg/Include/Protocol/Http.h
@@ -339,11 +339,10 @@ EFI_STATUS
   @param[in]  HttpConfigData  Pointer to the configure data to configure 
the instance.
 
   @retval EFI_SUCCESS Operation succeeded.
   @retval EFI_INVALID_PARAMETER   One or more of the following conditions is 
TRUE:
   This is NULL.
-  HttpConfigData is NULL.
   HttpConfigData->LocalAddressIsIPv6 is FALSE 
and
   HttpConfigData->IPv4Node is NULL.
   HttpConfigData->LocalAddressIsIPv6 is TRUE 
and
   HttpConfigData->IPv6Node is NULL.
   @retval EFI_ALREADY_STARTED Reinitialize this HTTP instance without 
calling
-- 
1.9.5.msysgit.1

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

[edk2] [Patch 2/2] NetworkPkg: Correct HttpConfigure parameter check

[Jiaxin Wu]

When HttpConfigData is NULL, HttpConfigure should not return
EFI_INVALID_PARAMETER.

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Zhang Lubo 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu 
---
 NetworkPkg/HttpDxe/HttpImpl.c | 9 +
 NetworkPkg/HttpDxe/HttpImpl.h | 1 -
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
index 7ee6613..12f22db 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -112,11 +112,10 @@ EfiHttpGetModeData (
   @param[in]  HttpConfigData  Pointer to the configure data to configure 
the instance.
 
   @retval EFI_SUCCESS Operation succeeded.
   @retval EFI_INVALID_PARAMETER   One or more of the following conditions is 
TRUE:
   This is NULL.
-  HttpConfigData is NULL.
   HttpConfigData->LocalAddressIsIPv6 is FALSE 
and
   HttpConfigData->IPv4Node is NULL.
   HttpConfigData->LocalAddressIsIPv6 is TRUE 
and
   HttpConfigData->IPv6Node is NULL.
   @retval EFI_ALREADY_STARTED Reinitialize this HTTP instance without 
calling
@@ -139,13 +138,13 @@ EfiHttpConfigure (
   
   //
   // Check input parameters.
   //
   if (This == NULL ||
-  HttpConfigData == NULL ||
- ((HttpConfigData->LocalAddressIsIPv6 && 
HttpConfigData->AccessPoint.IPv6Node == NULL) ||
- (!HttpConfigData->LocalAddressIsIPv6 && 
HttpConfigData->AccessPoint.IPv4Node == NULL))) {
+  (HttpConfigData != NULL && 
+   ((HttpConfigData->LocalAddressIsIPv6 && 
HttpConfigData->AccessPoint.IPv6Node == NULL) ||
+(!HttpConfigData->LocalAddressIsIPv6 && 
HttpConfigData->AccessPoint.IPv4Node == NULL {
 return EFI_INVALID_PARAMETER;
   }
 
   HttpInstance = HTTP_INSTANCE_FROM_PROTOCOL (This);
   ASSERT (HttpInstance != NULL && HttpInstance->Service != NULL);
@@ -252,10 +251,11 @@ EfiHttpRequest (
   //
   // Initializations
   //
   Url = NULL;
   UrlParser = NULL;
+  RemotePort = 0;
   HostName = NULL;
   RequestMsg = NULL;
   HostNameStr = NULL;
   Wrap = NULL;
   FileUrl = NULL;
@@ -906,10 +906,11 @@ HttpResponseWorker (
   HttpMsg->Headers  = NULL;
   HttpHeaders   = NULL;
   SizeofHeaders = 0;
   BufferSize= 0;
   EndofHeader   = NULL;
+  ValueInItem   = NULL;
  
   if (HttpMsg->Data.Response != NULL) {
 //
 // Need receive the HTTP headers, prepare buffer.
 //
diff --git a/NetworkPkg/HttpDxe/HttpImpl.h b/NetworkPkg/HttpDxe/HttpImpl.h
index 415b5e5..40b2504 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.h
+++ b/NetworkPkg/HttpDxe/HttpImpl.h
@@ -70,11 +70,10 @@ EfiHttpGetModeData (
   @param[in]  HttpConfigData  Pointer to the configure data to configure 
the instance.
 
   @retval EFI_SUCCESS Operation succeeded.
   @retval EFI_INVALID_PARAMETER   One or more of the following conditions is 
TRUE:
   This is NULL.
-  HttpConfigData is NULL.
   HttpConfigData->LocalAddressIsIPv6 is FALSE 
and
   HttpConfigData->IPv4Node is NULL.
   HttpConfigData->LocalAddressIsIPv6 is TRUE 
and
   HttpConfigData->IPv6Node is NULL.
   @retval EFI_ALREADY_STARTED Reinitialize this HTTP instance without 
calling
-- 
1.9.5.msysgit.1

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

Re: [edk2] [PATCH v2] MdeModulePkg/DisplayEngine: Fix memory leak issues in DisplayEngine

[Dong, Eric]

Reviewed-by: Eric Dong 

> -Original Message-
> From: Bi, Dandan
> Sent: Friday, May 20, 2016 10:12 AM
> To: edk2-devel@lists.01.org
> Cc: Cecil Sheng; Qiu, Shumin; Dong, Eric
> Subject: [PATCH v2] MdeModulePkg/DisplayEngine: Fix memory leak issues in 
> DisplayEngine
> 
> The following codes are useless and cause memory leak issues.
> So now remove them.
> 
> Cc: Cecil Sheng 
> Cc: Qiu Shumin 
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi 
> ---
>  MdeModulePkg/Universal/DisplayEngineDxe/InputHandler.c   |  5 +
>  MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c | 12 +---
>  2 files changed, 2 insertions(+), 15 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/DisplayEngineDxe/InputHandler.c 
> b/MdeModulePkg/Universal/DisplayEngineDxe/InputHandler.c
> index 732dd2f..8e7b735 100644
> --- a/MdeModulePkg/Universal/DisplayEngineDxe/InputHandler.c
> +++ b/MdeModulePkg/Universal/DisplayEngineDxe/InputHandler.c
> @@ -1,9 +1,9 @@
>  /** @file
>  Implementation for handling user input from the User Interfaces.
> 
> -Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2004 - 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
> 
> @@ -1297,13 +1297,10 @@ GetSelectionInputPopUp (
>ValueType = 0;
>CurrentOption = NULL;
>ShowDownArrow = FALSE;
>ShowUpArrow   = FALSE;
> 
> -  StringPtr = AllocateZeroPool ((gOptionBlockWidth + 1) * 2);
> -  ASSERT (StringPtr);
> -
>ZeroMem (, sizeof (EFI_HII_VALUE));
> 
>Question = MenuOption->ThisTag;
>if (Question->OpCode->OpCode == EFI_IFR_ORDERED_LIST_OP) {
>  Link = GetFirstNode (>OptionListHead);
> diff --git a/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
> b/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
> index bb2faf3..c61a395 100644
> --- a/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
> +++ b/MdeModulePkg/Universal/DisplayEngineDxe/ProcessOptions.c
> @@ -1,10 +1,10 @@
>  /** @file
>  Implementation for handling the User Interface option processing.
> 
> 
> -Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.
> +Copyright (c) 2004 - 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
> 
> @@ -883,22 +883,12 @@ PasswordProcess (
>if (StrCmp (StringPtr, TempString) == 0) {
>  gUserInput->InputValue.Buffer = AllocateCopyPool 
> (Question->CurrentValue.BufferLen, StringPtr);
>  gUserInput->InputValue.BufferLen = Question->CurrentValue.BufferLen;
>  gUserInput->InputValue.Type = Question->CurrentValue.Type;
>  gUserInput->InputValue.Value.string = HiiSetString(gFormData->HiiHandle, 
> gUserInput->InputValue.Value.string, StringPtr, NULL);
> -FreePool (StringPtr);
> 
>  Status = EFI_SUCCESS;
> -
> -if (EFI_ERROR (Status)) {
> -  //
> -  // Reset state machine for password
> -  //
> -  Question->PasswordCheck (gFormData, Question, NULL);
> -}
> -
> -return Status;
>} else {
>  //
>  // Reset state machine for password
>  //
>  Question->PasswordCheck (gFormData, Question, NULL);
> --
> 1.9.5.msysgit.1

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