Re: [edk2] [Patch 07/11] MdeModulePkg: Add Platform recovery support

[Wang, Sunny (HPS SW)]

Hi Ray,
Yes, you are right! Thanks for pointing it out. :)
I took an inappropriate reference (in ArmPlatformPkg\Bds\Bds.c) which caused my 
misunderstanding. 

Regards,
Sunny Wang


-Original Message-
From: Ni, Ruiyu [mailto:ruiyu...@intel.com] 
Sent: Monday, November 09, 2015 7:25 PM
To: Wang, Sunny (HPS SW); edk2-devel@lists.01.org
Cc: Dong, Eric
Subject: RE: [edk2] [Patch 07/11] MdeModulePkg: Add Platform recovery support
Importance: High

Sunny,
I guess you may have misunderstanding about the EndOfDxe signal time. This 
event is not signaled immediately before calling Bds->Entry(). This event is 
signaled by platform (in PlatformBootManagerBeforeConsole).
So it means all the PlatformRecovery variables need to be created in core 
(before PlatformBootManagerBeforeConsole()) or in 
PlatformBootManagerBeforeConsole().

I agree with your other comments.

Regards,
Ray

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wang, 
Sunny (HPS SW)
Sent: Thursday, November 5, 2015 9:17 PM
To: Ni, Ruiyu ; edk2-devel@lists.01.org
Cc: Dong, Eric 
Subject: Re: [edk2] [Patch 07/11] MdeModulePkg: Add Platform recovery support

Hi Ray,
I made four comments in this patch. You can search "[Sunny]" to find 
them out. 

Regards,
Sunny Wang

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ruiyu Ni
Sent: Monday, November 02, 2015 7:34 PM
To: edk2-devel@lists.01.org
Cc: Ruiyu Ni; Eric Dong
Subject: [edk2] [Patch 07/11] MdeModulePkg: Add Platform recovery support

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Eric Dong 
---
 MdeModulePkg/Include/Library/UefiBootManagerLib.h  |   1 +
 .../Library/UefiBootManagerLib/BmLoadOption.c  | 130 ++---
 .../Library/UefiBootManagerLib/InternalBm.h|   3 +-
 .../UefiBootManagerLib/UefiBootManagerLib.inf  |   1 +
 4 files changed, 118 insertions(+), 17 deletions(-)

diff --git a/MdeModulePkg/Include/Library/UefiBootManagerLib.h 
b/MdeModulePkg/Include/Library/UefiBootManagerLib.h
index 5538d90..1b04a8c 100644
--- a/MdeModulePkg/Include/Library/UefiBootManagerLib.h
+++ b/MdeModulePkg/Include/Library/UefiBootManagerLib.h
@@ -30,6 +30,7 @@ typedef enum {
   LoadOptionTypeDriver,
   LoadOptionTypeSysPrep,
   LoadOptionTypeBoot,
+  LoadOptionTypePlatformRecovery,
   LoadOptionTypeMax
 } EFI_BOOT_MANAGER_LOAD_OPTION_TYPE;
 
diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c 
b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
index fbd7830..454fe20 100644
--- a/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
+++ b/MdeModulePkg/Library/UefiBootManagerLib/BmLoadOption.c
@@ -18,14 +18,16 @@ GLOBAL_REMOVE_IF_UNREFERENCED
   CHAR16 *mBmLoadOptionName[] = {
 L"Driver",
 L"SysPrep",
-L"Boot"
+L"Boot",
+L"PlatformRecovery"
   };
 
 GLOBAL_REMOVE_IF_UNREFERENCED
   CHAR16 *mBmLoadOptionOrderName[] = {
 EFI_DRIVER_ORDER_VARIABLE_NAME,
 EFI_SYS_PREP_ORDER_VARIABLE_NAME,
-EFI_BOOT_ORDER_VARIABLE_NAME
+EFI_BOOT_ORDER_VARIABLE_NAME,
+NULL  // PlatformRecovery doesn't have associated *Order 
+ variable
   };
 
 /**
@@ -153,8 +155,9 @@ BmGetFreeOptionNumber (  }
 
 /**
-  Create the Boot, Driver, SysPrep, variable from the load option.
-  
+  Create the Boot, Driver, SysPrep, PlatformRecovery 
+ variable  from the load option.
+
   @param  LoadOption  Pointer to the load option.
 
   @retval EFI_SUCCESS The variable was created.
@@ -166,12 +169,14 @@ EfiBootManagerLoadOptionToVariable (
   IN CONST EFI_BOOT_MANAGER_LOAD_OPTION *Option
   )
 {
+  EFI_STATUS   Status;
   UINTNVariableSize;
   UINT8*Variable;
   UINT8*Ptr;
   CHAR16   OptionName[BM_OPTION_NAME_LEN];
   CHAR16   *Description;
   CHAR16   NullChar;
+  EDKII_VARIABLE_LOCK_PROTOCOL *VariableLock;
   UINT32   VariableAttributes;
 
   if ((Option->OptionNumber == LoadOptionNumberUnassigned) || @@ -232,6 
+237,17 @@ structure.
   UnicodeSPrint (OptionName, sizeof (OptionName), L"%s%04x", 
mBmLoadOptionName[Option->OptionType], Option->OptionNumber);
 
   VariableAttributes = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
EFI_VARIABLE_RUNTIME_ACCESS | EFI_VARIABLE_NON_VOLATILE;
+  if (Option->OptionType == LoadOptionTypePlatformRecovery) {
+//
+// Lock the PlatformRecovery
+//
+Status = gBS->LocateProtocol (, NULL, (VOID 
**) );
+if (!EFI_ERROR (Status)) {
+  Status = VariableLock->RequestToLock (VariableLock, OptionName, 
);
+  ASSERT_EFI_ERROR (Status);
+}
+VariableAttributes = EFI_VARIABLE_BOOTSERVICE_ACCESS | 
+ EFI_VARIABLE_RUNTIME_ACCESS;  }
[Sunny] 

[edk2] [PATCH] MdeModulePkg PeiCore: PEI dispatcher need retry to process NOT_DISPATCHED FV

[Star Zeng]

A corner case like below will cause a NOT_DISPATCHED FV has no opportunity to
be dispatched.
  1. FV_RECOVERY has SecCore, PeiCore and some other PEI modules, a module will
report FVMAIN_COMPACT and FV_RECOVERY2 in sequence.
  2. FVMAIN_COMPACT has a FV image file with GUIDED FV image section in it.
  3. FV_RECOVERY2 has DxeIpl and other PEI modules, the DxeIpl will install
 SectionExtractionPpi
  If ALL the PEIMs in FV_RECOVERY and FV_RECOVERY2 have DEPEX satisfied and
  executed in one loop, PeimNeedingDispatch will be always FALSE, FVMAIN_COMPACT
  will have no opportunity to be decompressed and dispatched as DxeIpl executes
  after the first processing to FVMAIN_COMPACT.

The patch is to set PeimNeedingDispatch to TRUE when ProcessFvFile() not 
successfully,
then the NOT_DISPATCHED FV could have another opportunity to be processed.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c 
b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
index 7480b66..e7e795d 100644
--- a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
+++ b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
@@ -1056,7 +1056,7 @@ PeiDispatcher (
 ASSERT_EFI_ERROR (Status);
 if (FvFileInfo.FileType == EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE) {
   //
-  // For Fv type file, Produce new FV PPI and FV hob
+  // For Fv type file, Produce new FvInfo PPI and FV hob
   //
   Status = ProcessFvFile (Private, >Fv[FvCount], 
PeimFileHandle);
   if (Status == EFI_SUCCESS) {
@@ -1065,6 +1065,13 @@ PeiDispatcher (
 //
 Private->Fv[FvCount].PeimState[PeimCount]++;
 Private->PeimDispatchOnThisPass = TRUE;
+  } else {
+//
+// The related GuidedSectionExtraction/Decompress PPI for the
+// encapsulated FV image section may be installed in the rest
+// of this do-while loop, so need to make another pass.
+//
+Private->PeimNeedingDispatch = TRUE;
   }
 } else {
   //
@@ -1192,11 +1199,11 @@ PeiDispatcher (
 Private->CurrentPeimFvCount = 0;
 
 //
-// PeimNeedingDispatch being TRUE means we found a PEIM that did not get
+// PeimNeedingDispatch being TRUE means we found a PEIM/FV that did not get
 //  dispatched. So we need to make another pass
 //
-// PeimDispatchOnThisPass being TRUE means we dispatched a PEIM on this
-//  pass. If we did not dispatch a PEIM there is no point in trying again
+// PeimDispatchOnThisPass being TRUE means we dispatched a PEIM/FV on this
+//  pass. If we did not dispatch a PEIM/FV there is no point in trying 
again
 //  as it will fail the next time too (nothing has changed).
 //
   } while (Private->PeimNeedingDispatch && Private->PeimDispatchOnThisPass);
-- 
1.9.5.msysgit.0

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

Re: [edk2] Armv8 64bit: System error booting linux from the UEFI

[Ard Biesheuvel]

On 11 November 2015 at 01:20, Vladimir Olovyannikov
 wrote:
> Hello,
>
> I am not sure this is the right forum to ask this question, so I am sorry in
> advance if this is an offtopic here (please point me to the proper one).
>
> I brought up UEFI on the device and am trying to load linux from the SD card
> (loading from the network using GRUB is a topic for another message).
>
> Linux kernel starts and shortly after that (as soon as local_async is
> enabled which is simple “MSR DAIfclr,4”) there is a kernel crash with
>
> “Bad mode in Error handler detected, code 0xbf00 -- SError”
> Here is the log:
>
>
>
> The default boot selection will start in  10 seconds
>

Unrelated note: *please* get rid of the ARM BDS and use the Intel BDS
instead. The ARM BDS violates the UEFI spec, (i.e., you cannot boot
installer images from it without a lot of hassle) and does not allow
you to enable UEFI secure boot.

Look at the development history of ArmVExpress-FVP-AArch64.dsc for
hints how to do this.

> [1] Linux Kernel from SD Card
>
> - SD(0x0)/HD(1,MBR,0x,0x89,0x3A9F77)/Image
>
> - Arguments: dtb=ns2-svk.dtb initrd=initrd console=ttyS0,115200n8
> earlycon=uart8250,mmio32,0x6613,maxcpus=1
>
> [2] GRUB
>
> - MAC(001019D0B2A4,0x1)/IPv4(10.136.12.136)/grub.efi
>
> - Arguments:
>
> [3] Shell
>
> [4] Boot Manager
>
> Start: 1
>
> InstallProtocolInterface: CE345171-BA0B-11D2-8E4F-00A0C969723B BEDB9DA0
>
> BlockSize : 512
>
> LastBlock : 3A9FFF
>
> InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B BEDB9798
>
> InstallProtocolInterface: 964E5B21-6459-11D2-8E39-00A0C969723B BEDB9670
>
> InstallProtocolInterface: CE345171-BA0B-11D2-8E4F-00A0C969723B BEDB95A0
>
> InstallProtocolInterface: 964E5B22-6459-11D2-8E39-00A0C969723B BEDAF030
>
> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B BE2E6040
>
> Loading driver at 0x000B8C0C000 EntryPoint=0x000B9297440
>
> Loading driver at 0x000B8C0C000 EntryPoint=0x000B9297440
>
> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF BEDB0718
>
> EFI stub: Booting Linux Kernel...
>
> ConvertPages: Incompatible memory types
>
> EFI stub: Using DTB from command line
>
> EFI stub: Exiting boot services and installing virtual address map...
>
> MmcHost: ExitBootServicesEvent+
>
> Marked card brcm-SDIO1 as removed
>
> Resetting Card brcm-SDIO1
>
> brcm-SDIO1 Card reset done.
>
> MmcHost: ExitBootServicesEvent-
>
> MmcHost: ExitBootServicesEvent+
>
> Marked card brcm-SDIO0 as removed
>
> Resetting Card brcm-SDIO0
>
> brcm-SDIO0 Card reset done.
>
> MmcHost: ExitBootServicesEvent-
>
> [0.00] Booting Linux on physical CPU 0x0
>
> [0.00] Initializing cgroup subsys cpu
>
> [0.00] Linux version 4.2.0+ (volovyan@LBRMN-LNXUB114) (gcc version
> 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro
> GCC 4.9-2014.09) ) #1 SMP PREEMPT Tue Oct 13 11:33:09 PDT 2015
>
> [0.00] CPU: AArch64 Processor [411fd073] revision 3
>
> [0.00] Detected PIPT I-cache on CPU0
>
> [0.00] earlycon: Early serial console at MMIO32 0x6613 (options
> 'maxcpus=1')
>
> [0.00] bootconsole [uart0] enabled
>
> [0.00] Bad mode in Error handler detected, code 0xbf00 -- SError
>
> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0+ #1
>
> [0.00] Hardware name: SVK proto (DT)
>
> [0.00] task: ffc0007584b0 ti: ffc00074c000 task.ti:
> ffc00074c000
>
> [0.00] PC is at setup_arch+0x260/0x5b4
>
> [0.00] LR is at setup_arch+0x25c/0x5b4
>
> [0.00] pc : [] lr : [] pstate:
> 02c5
>
> [0.00] sp : ffc00074ff20
>
> [0.00] x29: ffc00074ff20 x28: 
>
> [0.00] x27: ffc81198 x26: 807cd000
>
> [0.00] x25: 807ca000 x24: 8000
>
> [0.00] x23:  x22: ffc000752000
>
> [0.00] x21: ffc000752610 x20: ffbffa80
>
> [0.00] x19: ffc8 x18: 
>
> [0.00] x17: 05e3 x16: 1000
>
> [0.00] x15: 1c00 x14: 0ffe
>
> [0.00] x13: 0020 x12: 0028
>
> [0.00] x11: 0007 x10: 0101010101010101
>
> [0.00] x9 : fffb x8 : 0008
>
> [0.00] x7 : 0003 x6 : 0080
>
> [0.00] x5 : 005f x4 : 
>
> [0.00] x3 :  x2 : 0065
>
> [0.00] x1 :  x0 : 0001
>
> [0.00]
>
> [0.00] Internal error: Oops - bad mode: 0 [#1] PREEMPT SMP
>
> [0.00] Modules linked in:
>
> [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0+ #1
>
> [0.00] Hardware name: SVK proto (DT)
>
> [0.00] task: ffc0007584b0 ti: 

Re: [edk2] Authentication status for signed FVs extracted in PEI

[Cohen, Eugene]

Mike,

> If content is only required in DXE, then consider deferring the FV 
> publication and authentication to DXE.  That may involve adjusting your FV 
> layout.  

Originally we had an uncompressed DxeCore.efi decompress the FV with the rest 
of the components.  But the signing already happened in PEI so we had the same 
issue (AuthenticationStatus = 0).  I suppose if we deferred the signature 
verification and decompression to DxeCore we would propagate 
AuthenticationStatus but we would be out of PEI and unable to run our recovery 
handler.

> If signed FV is required in PEI and DXE, then it would be authenticated in 
> PEI, and once authenticated in PEI, it is available to DXE without additional 
> authentication.

This is our scenario.  While further authentication in DXE is not needed our 
policy code needs to know the results of PEI authentication so that in the 
security callbacks we can to answer the question "Does this image originate 
from an FV that was already verified in PEI?".  Right now AuthenticationStatus 
is zero (unsigned) in the DXE phase security callbacks and this is incorrect.

> I am mainly trying to understand if there is a solution using current PI 
> architecture.

Based on our discussion I'm feeling more confident that we need to define an 
updated the FV HOB definition (or extend the original if this can be done 
compatibly) to include AuthenticationStatus from PEI.

Thanks,

Eugene

-Original Message-
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] 
Sent: Tuesday, November 10, 2015 7:06 PM
To: Cohen, Eugene ; Gao, Liming ; Zeng, 
Star ; edk2-devel@lists.01.org; Kinney, Michael D 

Subject: RE: [edk2] Authentication status for signed FVs extracted in PEI

Eugene,

No.  I am not aware of a channel in current PI architecture other than any FV 
published by PEI is assumed by DXE to be immediately useable (no additional 
authentication action required).

If content is only required in DXE, then consider deferring the FV publication 
and authentication to DXE.  That may involve adjusting your FV layout.  

If signed FV is required in PEI and DXE, then it would be authenticated in PEI, 
and once authenticated in PEI, it is available to DXE without additional 
authentication.

I am mainly trying to understand if there is a solution using current PI 
architecture.

Thanks,

Mike

>-Original Message-
>From: Cohen, Eugene [mailto:eug...@hp.com]
>Sent: Tuesday, November 10, 2015 2:46 PM
>To: Kinney, Michael D; Gao, Liming; Zeng, Star; edk2-devel@lists.01.org
>Subject: RE: [edk2] Authentication status for signed FVs extracted in 
>PEI
>
>Mike,
>
>> I believe the current behavior is that only FVs that are either 
>> unsigned or FVs that are signed and pass authentication can be passed
>from PEI to DXE.
>> I believe your use case is to pass an FV from PEI to DXE that is signed, but 
>> has not been authenticated yet.
>
>Our use case is PEI signing and verifying FVs (the first case) using 
>the GUIDed encapsulation scheme you contributed a while back (thank 
>you!).  From what I can see both in edk2 and in the PI spec there is 
>not an architected mechanism to pass this information.  As I mentioned in my 
>first message, the DXE core seems to jam AuthenticationStatus to zero (in 
>calling ProduceFVBProtocolOnBuffer) as it processes FV HOBs.  Are you aware of 
>a channel where this information is already being passed from PEI to DXE?
>
>The other lingering question I had was why others hadn't seen this 
>before me.  I'm guessing that people are choosing different approaches for 
>packaging up PEI and DXE phase components than we are.
>
>Thanks,
>
>Eugene
>
>-Original Message-
>From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
>Sent: Tuesday, November 10, 2015 12:54 PM
>To: Cohen, Eugene ; Gao, Liming ; 
>Zeng, Star ; edk2- de...@lists.01.org; Kinney, 
>Michael D 
>Subject: RE: [edk2] Authentication status for signed FVs extracted in 
>PEI
>
>Eugene,
>
>I believe the current behavior is that only FVs that are either 
>unsigned or FVs that are signed and pass authentication can be passed from PEI 
>to DXE.
>
>I believe your use case is to pass an FV from PEI to DXE that is signed, but 
>has not been authenticated yet.
>
>Given the current PI architecture constraints, would it be a reasonable 
>solution to have an early DXE driver publish the FV that is signed but not 
>authenticated yet, so the DXE phase can do the authentication?
>
>Thanks,
>
>Mike
>
>>-Original Message-
>>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>>Cohen, Eugene
>>Sent: Tuesday, November 10, 2015 7:12 AM
>>To: Gao, Liming; Zeng, Star; edk2-devel@lists.01.org
>>Subject: Re: [edk2] Authentication status for signed FVs extracted in 
>>PEI
>>
>>Liming and Star,
>>
>>Thanks 

Re: [edk2] [PATCH] MdeModulePkg PeiCore: PEI dispatcher need retry to process NOT_DISPATCHED FV

[Cohen, Eugene]

Good catch.

Reviewed-by: Eugene Cohen 


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng
Sent: Wednesday, November 11, 2015 3:07 AM
To: edk2-devel@lists.01.org
Cc: Liming Gao 
Subject: [edk2] [PATCH] MdeModulePkg PeiCore: PEI dispatcher need retry to 
process NOT_DISPATCHED FV

A corner case like below will cause a NOT_DISPATCHED FV has no opportunity to 
be dispatched.
  1. FV_RECOVERY has SecCore, PeiCore and some other PEI modules, a module will
report FVMAIN_COMPACT and FV_RECOVERY2 in sequence.
  2. FVMAIN_COMPACT has a FV image file with GUIDED FV image section in it.
  3. FV_RECOVERY2 has DxeIpl and other PEI modules, the DxeIpl will install
 SectionExtractionPpi
  If ALL the PEIMs in FV_RECOVERY and FV_RECOVERY2 have DEPEX satisfied and
  executed in one loop, PeimNeedingDispatch will be always FALSE, FVMAIN_COMPACT
  will have no opportunity to be decompressed and dispatched as DxeIpl executes
  after the first processing to FVMAIN_COMPACT.

The patch is to set PeimNeedingDispatch to TRUE when ProcessFvFile() not 
successfully, then the NOT_DISPATCHED FV could have another opportunity to be 
processed.

Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c 
b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
index 7480b66..e7e795d 100644
--- a/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
+++ b/MdeModulePkg/Core/Pei/Dispatcher/Dispatcher.c
@@ -1056,7 +1056,7 @@ PeiDispatcher (
 ASSERT_EFI_ERROR (Status);
 if (FvFileInfo.FileType == EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE) {
   //
-  // For Fv type file, Produce new FV PPI and FV hob
+  // For Fv type file, Produce new FvInfo PPI and FV hob
   //
   Status = ProcessFvFile (Private, >Fv[FvCount], 
PeimFileHandle);
   if (Status == EFI_SUCCESS) { @@ -1065,6 +1065,13 @@ 
PeiDispatcher (
 //
 Private->Fv[FvCount].PeimState[PeimCount]++;
 Private->PeimDispatchOnThisPass = TRUE;
+  } else {
+//
+// The related GuidedSectionExtraction/Decompress PPI for the
+// encapsulated FV image section may be installed in the rest
+// of this do-while loop, so need to make another pass.
+//
+Private->PeimNeedingDispatch = TRUE;
   }
 } else {
   //
@@ -1192,11 +1199,11 @@ PeiDispatcher (
 Private->CurrentPeimFvCount = 0;
 
 //
-// PeimNeedingDispatch being TRUE means we found a PEIM that did not get
+// PeimNeedingDispatch being TRUE means we found a PEIM/FV that did 
+ not get
 //  dispatched. So we need to make another pass
 //
-// PeimDispatchOnThisPass being TRUE means we dispatched a PEIM on this
-//  pass. If we did not dispatch a PEIM there is no point in trying again
+// PeimDispatchOnThisPass being TRUE means we dispatched a PEIM/FV on this
+//  pass. If we did not dispatch a PEIM/FV there is no point in 
+ trying again
 //  as it will fail the next time too (nothing has changed).
 //
   } while (Private->PeimNeedingDispatch && Private->PeimDispatchOnThisPass);
--
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 V2 5/5] Nt32Pkg: Use LogoLib for LOGO and progress bar drawing.

[Dong, Eric]

Reviewed-by: Eric Dong 

-Original Message-
From: Ni, Ruiyu 
Sent: Monday, November 09, 2015 1:24 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu; Dong, Eric
Subject: [Patch V2 5/5] Nt32Pkg: Use LogoLib for LOGO and progress bar drawing.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Eric Dong 
---
 .../Library/PlatformBootManagerLib/MemoryTest.c| 833 +
 .../PlatformBootManagerLib/PlatformBootManager.c   |   6 +-
 .../PlatformBootManagerLib/PlatformBootManager.h   |   6 +-
 .../PlatformBootManagerLib.inf |   2 +-
 Nt32Pkg/Nt32Pkg.dsc|   7 +-
 5 files changed, 14 insertions(+), 840 deletions(-)

diff --git a/Nt32Pkg/Library/PlatformBootManagerLib/MemoryTest.c 
b/Nt32Pkg/Library/PlatformBootManagerLib/MemoryTest.c
index 9f57466..93ecc7d 100644
--- a/Nt32Pkg/Library/PlatformBootManagerLib/MemoryTest.c
+++ b/Nt32Pkg/Library/PlatformBootManagerLib/MemoryTest.c
@@ -23,179 +23,6 @@ EFI_GUID   mPlatformBootManagerStringPackGuid = {
 //
 // BDS Platform Functions
 //
-/**
-
-  Show progress bar with title above it. It only works in Graphics mode.
-
-
-  @param TitleForeground Foreground color for Title.
-  @param TitleBackground Background color for Title.
-  @param Title   Title above progress bar.
-  @param ProgressColor   Progress bar color.
-  @param ProgressProgress (0-100)
-  @param PreviousValue   The previous value of the progress.
-
-  @retval  EFI_STATUS   Success update the progress bar
-
-**/
-EFI_STATUS
-PlatformBootManagerShowProgress (
-  IN EFI_GRAPHICS_OUTPUT_BLT_PIXEL TitleForeground,
-  IN EFI_GRAPHICS_OUTPUT_BLT_PIXEL TitleBackground,
-  IN CHAR16*Title,
-  IN EFI_GRAPHICS_OUTPUT_BLT_PIXEL ProgressColor,
-  IN UINTN Progress,
-  IN UINTN PreviousValue
-  )
-{
-  EFI_STATUS Status;
-  EFI_GRAPHICS_OUTPUT_PROTOCOL   *GraphicsOutput;
-  EFI_UGA_DRAW_PROTOCOL  *UgaDraw;
-  UINT32 SizeOfX;
-  UINT32 SizeOfY;
-  UINT32 ColorDepth;
-  UINT32 RefreshRate;
-  EFI_GRAPHICS_OUTPUT_BLT_PIXEL  Color;
-  UINTN  BlockHeight;
-  UINTN  BlockWidth;
-  UINTN  BlockNum;
-  UINTN  PosX;
-  UINTN  PosY;
-  UINTN  Index;
-
-  if (Progress > 100) {
-return EFI_INVALID_PARAMETER;
-  }
-
-  UgaDraw = NULL;
-  Status = gBS->HandleProtocol (
-  gST->ConsoleOutHandle,
-  ,
-  (VOID **) 
-  );
-  if (EFI_ERROR (Status) && FeaturePcdGet (PcdUgaConsumeSupport)) {
-GraphicsOutput = NULL;
-
-Status = gBS->HandleProtocol (
-gST->ConsoleOutHandle,
-,
-(VOID **) 
-);
-  }
-  if (EFI_ERROR (Status)) {
-return EFI_UNSUPPORTED;
-  }
-
-  SizeOfX = 0;
-  SizeOfY = 0;
-  if (GraphicsOutput != NULL) {
-SizeOfX = GraphicsOutput->Mode->Info->HorizontalResolution;
-SizeOfY = GraphicsOutput->Mode->Info->VerticalResolution;
-  } else if (UgaDraw != NULL) {
-Status = UgaDraw->GetMode (
-UgaDraw,
-,
-,
-,
-
-);
-if (EFI_ERROR (Status)) {
-  return EFI_UNSUPPORTED;
-}
-  } else {
-return EFI_UNSUPPORTED;
-  }
-
-  BlockWidth  = SizeOfX / 100;
-  BlockHeight = SizeOfY / 50;
-
-  BlockNum= Progress;
-
-  PosX= 0;
-  PosY= SizeOfY * 48 / 50;
-
-  if (BlockNum == 0) {
-//
-// Clear progress area
-//
-SetMem (, sizeof (EFI_GRAPHICS_OUTPUT_BLT_PIXEL), 0x0);
-
-if (GraphicsOutput != NULL) {
-  Status = GraphicsOutput->Blt (
-  GraphicsOutput,
-  ,
-  EfiBltVideoFill,
-  0,
-  0,
-  0,
-  PosY - EFI_GLYPH_HEIGHT - 1,
-  SizeOfX,
-  SizeOfY - (PosY - EFI_GLYPH_HEIGHT - 1),
-  SizeOfX * sizeof (EFI_GRAPHICS_OUTPUT_BLT_PIXEL)
-  );
-} else if (FeaturePcdGet (PcdUgaConsumeSupport)) {
-  Status = UgaDraw->Blt (
-  UgaDraw,
-  (EFI_UGA_PIXEL *) ,
-  EfiUgaVideoFill,
-  0,
-  0,
-  0,
-  PosY - EFI_GLYPH_HEIGHT - 1,
-  SizeOfX,
-  SizeOfY - (PosY - EFI_GLYPH_HEIGHT - 1),
-

[edk2] [Patch] MdeModulePkg/BmpImageDecoderLib: Support ImageFormatUnknown type

[Ruiyu Ni]

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Feng Tian 
---
 MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.c 
b/MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.c
index 86dcc91..28afd4f 100644
--- a/MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.c
+++ b/MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.c
@@ -65,7 +65,7 @@ BmpImageDecoderLibConvertBmpToGopBlt (
 
   ASSERT ((GopBlt != NULL) && (GopBltSize != NULL));
 
-  if (ImageFormat != ImageFormatBmp) {
+  if ((ImageFormat != ImageFormatBmp) && (ImageFormat != ImageFormatUnknown)) {
 return EFI_UNSUPPORTED;
   }
 
-- 
1.9.5.msysgit.1

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

Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken

[Andrew Fish]

> On Nov 11, 2015, at 8:03 PM, El-Haj-Mahmoud, Samer 
>  wrote:
> 
> I remember we specifically discussed this in the UEFI Forum and decided to 
> drop the If4ConfigProtocol compatability from the spec.
> 
> If edk2 would like to keep it, it can be done, but will complicate things. I 
> would recommend a build option to disable /remove the legacy support as new 
> platforms don't care about this in their shell (if the shell is embedded or 
> targets specific platforms).
> 

Samer,

I don't think this is a spec conformance issue. It is easy for a ROM to pick a 
given version of UEFI to conform to. The problem is an application as Johannes 
has pointed out can run on different ROMs that implement different versions of 
UEFI. 

>From an implementation standpoint it should be possible for the Application to 
>check the UEFI revision and "do the correct thing". So I think the objection 
>is the shell was written to strictly conform to the latest UEFI specification, 
>when it could have been made backward compatible with a range of UEFI 
>specification versions. 

Thanks,

Andrew Fish

> 
> Thanks
> Samer
> 
> 
> 
> Sent from my Android phone using Symantec TouchDown (www.symantec.com)
> 
> -Original Message-
> From: Ye, Ting [ting...@intel.com]
> Received: Wednesday, 11 Nov 2015, 7:41PM
> To: Conen, Johannes [johannes.co...@siemens.com]; Laszlo Ersek 
> [ler...@redhat.com]; Wu, Jiaxin [jiaxin...@intel.com]; 
> edk2-devel@lists.01.org [edk2-de...@ml01.01.org]; Carsey, Jaben 
> [jaben.car...@intel.com]
> CC: Leif Lindholm (Linaro address) [leif.lindh...@linaro.org]
> Subject: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken
> 
> One solution to support UEFI 2.4 network modules with UEFI 2.5 ifconfig is to 
> add the code back to use HII services to perform setting. The definition of 
> NIC_IP4_CONFIG_INFO and a private GUID gEfiNicIp4ConfigVariableGuid should be 
> added into ShellPkg as UEFI 2.5 no longer keep the definition in 
> MdeModulePkg. This will bring complexity to ShellPkg.
> 
> Also, more older network modules even uses a private protocol NicIp4Config 
> protocol (defined in EdkCompatibilityPkg) to fix the issue in 
> EFI_IP4_CONFIG_PROTOCOL. When Shell commands upgrade to Shell 2.0, the 
> ifconfig removes the support of this protocol. Does the UEFI 2.5 ifconfig 
> need support this protocol also to co-work with older platform?
> 
> Jaben, what's your opinion about this?
> 
> Best Regards,
> Ye Ting
> 
> 
> -Original Message-
> From: Conen, Johannes [mailto:johannes.co...@siemens.com]
> Sent: Wednesday, November 11, 2015 8:22 PM
> To: Ye, Ting; Laszlo Ersek; Wu, Jiaxin; edk2-devel@lists.01.org
> Cc: Leif Lindholm (Linaro address)
> Subject: AW: [edk2] ShellPkg: Network commands (ifconfig/ping) broken
> 
> Hi everyone,
> 
> I started with UEFI development only recently, in September, with UDK2014. 
> When UDK2015 was released and there was no explicit notice of it being 
> incompatible with UDK2014 platforms, I expected to be able to switch to it 
> without any problems - I didn't expect forward compatibility, but backward 
> compatibility like in most other development environments (e.g. if I write an 
> application with the C95 standard, my application will still work with C99, 
> but not the other way round). If I understood you correctly, neither the one 
> nor the another is given atm - the UDK2014 shell won't work with UEFI 2.50 
> platforms as the EFI_IP4_CONFIG_PROTOCOL is not present and the UDK2015 shell 
> won't work with UEFI 2.40 platforms as the EFI_IP4_CONFIG2_PROTOCOL is not 
> present.
> 
> I don't think you can expect every UEFI developer to be on the EDK2 mailing 
> list - I wasn't until a few days ago, the discussions about deprecating the 
> protocol were in April and July according to the mail attachments from Jiaxin 
> and with the amount of e-mails being sent over this mailing list on a daily 
> basis, I doubt everyone will take notice of everything. For me as someone who 
> is not involved into the development of EDKII itself, 90% of those e-mails 
> are completely irrelevant to me and get deleted immediately.
> 
> Now, I don't write UEFI firmwares, but UEFI applications - for testing our 
> computers before they leave the production factory. Something being 
> incompatible with previous versions (getting deprecated doesn't necessarily 
> mean it doesn't work anymore, only it shouldn't be used anymore) is a pretty 
> important notice to me as I need to rewrite all applications that are 
> affected by this as soon as our firmware developers switch to 
> UDK2015/UEFI2.50 - or maintain two versions of my applications while some 
> computers are still being shipped with UEFI 2.40 and others with UEFI 2.50. 
> AFAIK (please correct me if I'm wrong there), until now, every application 
> developed with an earlier version of EDK/EDKII could be used on platforms 
> developed with later versions, too - e.g. I was able to use 

Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken

[El-Haj-Mahmoud, Samer]

I remember we specifically discussed this in the UEFI Forum and decided to drop 
the If4ConfigProtocol compatability from the spec.

If edk2 would like to keep it, it can be done, but will complicate things. I 
would recommend a build option to disable /remove the legacy support as new 
platforms don't care about this in their shell (if the shell is embedded or 
targets specific platforms).


Thanks
Samer



Sent from my Android phone using Symantec TouchDown (www.symantec.com)

-Original Message-
From: Ye, Ting [ting...@intel.com]
Received: Wednesday, 11 Nov 2015, 7:41PM
To: Conen, Johannes [johannes.co...@siemens.com]; Laszlo Ersek 
[ler...@redhat.com]; Wu, Jiaxin [jiaxin...@intel.com]; edk2-devel@lists.01.org 
[edk2-de...@ml01.01.org]; Carsey, Jaben [jaben.car...@intel.com]
CC: Leif Lindholm (Linaro address) [leif.lindh...@linaro.org]
Subject: Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken

One solution to support UEFI 2.4 network modules with UEFI 2.5 ifconfig is to 
add the code back to use HII services to perform setting. The definition of 
NIC_IP4_CONFIG_INFO and a private GUID gEfiNicIp4ConfigVariableGuid should be 
added into ShellPkg as UEFI 2.5 no longer keep the definition in MdeModulePkg. 
This will bring complexity to ShellPkg.

Also, more older network modules even uses a private protocol NicIp4Config 
protocol (defined in EdkCompatibilityPkg) to fix the issue in 
EFI_IP4_CONFIG_PROTOCOL. When Shell commands upgrade to Shell 2.0, the ifconfig 
removes the support of this protocol. Does the UEFI 2.5 ifconfig need support 
this protocol also to co-work with older platform?

Jaben, what's your opinion about this?

Best Regards,
Ye Ting


-Original Message-
From: Conen, Johannes [mailto:johannes.co...@siemens.com]
Sent: Wednesday, November 11, 2015 8:22 PM
To: Ye, Ting; Laszlo Ersek; Wu, Jiaxin; edk2-devel@lists.01.org
Cc: Leif Lindholm (Linaro address)
Subject: AW: [edk2] ShellPkg: Network commands (ifconfig/ping) broken

Hi everyone,

I started with UEFI development only recently, in September, with UDK2014. When 
UDK2015 was released and there was no explicit notice of it being incompatible 
with UDK2014 platforms, I expected to be able to switch to it without any 
problems - I didn't expect forward compatibility, but backward compatibility 
like in most other development environments (e.g. if I write an application 
with the C95 standard, my application will still work with C99, but not the 
other way round). If I understood you correctly, neither the one nor the 
another is given atm - the UDK2014 shell won't work with UEFI 2.50 platforms as 
the EFI_IP4_CONFIG_PROTOCOL is not present and the UDK2015 shell won't work 
with UEFI 2.40 platforms as the EFI_IP4_CONFIG2_PROTOCOL is not present.

I don't think you can expect every UEFI developer to be on the EDK2 mailing 
list - I wasn't until a few days ago, the discussions about deprecating the 
protocol were in April and July according to the mail attachments from Jiaxin 
and with the amount of e-mails being sent over this mailing list on a daily 
basis, I doubt everyone will take notice of everything. For me as someone who 
is not involved into the development of EDKII itself, 90% of those e-mails are 
completely irrelevant to me and get deleted immediately.

Now, I don't write UEFI firmwares, but UEFI applications - for testing our 
computers before they leave the production factory. Something being 
incompatible with previous versions (getting deprecated doesn't necessarily 
mean it doesn't work anymore, only it shouldn't be used anymore) is a pretty 
important notice to me as I need to rewrite all applications that are affected 
by this as soon as our firmware developers switch to UDK2015/UEFI2.50 - or 
maintain two versions of my applications while some computers are still being 
shipped with UEFI 2.40 and others with UEFI 2.50. AFAIK (please correct me if 
I'm wrong there), until now, every application developed with an earlier 
version of EDK/EDKII could be used on platforms developed with later versions, 
too - e.g. I was able to use the applications shipped with the original EDK 
(like the ramdisk driver or the ftp client) on my UEFI 2.40 platform. That 
changing is a pretty big deal and should clearly be communicated within the 
release notes.

In this specific case, I wanted to customize the shell to include our 
diagnostic programs so we can boot the shell over PXE, run our diagnostics and 
send the results back to a server (therefore the need for ifconfig), thus 
eliminating the need for an EFI USB stick. Now, depending on which UEFI 
platform the PC has, we need to boot either the UEFI 2.40 compatible shell or 
the UEFI 2.50 compatible shell - which makes things a bit more complicated.

Greetings
Johannes


-Ursprüngliche Nachricht-
Von: Ye, Ting [mailto:ting...@intel.com]
Gesendet: Mittwoch, 11. November 2015 04:36
An: Conen, Johannes; Laszlo Ersek; Wu, Jiaxin; edk2-devel@lists.01.org
Cc: 

Re: [edk2] Armv8 64bit: System error booting linux from the UEFI

[Vladimir Olovyannikov]

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, November 11, 2015 1:08 AM
> To: Vladimir Olovyannikov
> Cc: edk2-devel@lists.01.org
> Subject: Re: Armv8 64bit: System error booting linux from the UEFI
> 
> On 11 November 2015 at 01:20, Vladimir Olovyannikov
>  wrote:
> > Hello,
> >
> > I am not sure this is the right forum to ask this question, so I am sorry in
> > advance if this is an offtopic here (please point me to the proper one).
> >
> > I brought up UEFI on the device and am trying to load linux from the SD
> card
> > (loading from the network using GRUB is a topic for another message).
> >
> > Linux kernel starts and shortly after that (as soon as local_async is
> > enabled which is simple “MSR DAIfclr,4”) there is a kernel crash with
> >
> > “Bad mode in Error handler detected, code 0xbf00 -- SError”
> > Here is the log:
> >
> >
> >
> > The default boot selection will start in  10 seconds
> >
> 
> Unrelated note: *please* get rid of the ARM BDS and use the Intel BDS
> instead. The ARM BDS violates the UEFI spec, (i.e., you cannot boot
> installer images from it without a lot of hassle) and does not allow
> you to enable UEFI secure boot.
> 
> Look at the development history of ArmVExpress-FVP-AArch64.dsc for
> hints how to do this.
Thank you for the hint. I will follow your advice to get rid of the ARM BDS.
> 
> > [1] Linux Kernel from SD Card
> >
> > - SD(0x0)/HD(1,MBR,0x,0x89,0x3A9F77)/Image
> >
> > - Arguments: dtb=ns2-svk.dtb initrd=initrd console=ttyS0,115200n8
> > earlycon=uart8250,mmio32,0x6613,maxcpus=1
> >
> > [2] GRUB
> >
> > - MAC(001019D0B2A4,0x1)/IPv4(10.136.12.136)/grub.efi
> >
> > - Arguments:
> >
> > [3] Shell
> >
> > [4] Boot Manager
> >
> > Start: 1
> >
> > InstallProtocolInterface: CE345171-BA0B-11D2-8E4F-00A0C969723B
> BEDB9DA0
> >
> > BlockSize : 512
> >
> > LastBlock : 3A9FFF
> >
> > InstallProtocolInterface: 09576E91-6D3F-11D2-8E39-00A0C969723B
> BEDB9798
> >
> > InstallProtocolInterface: 964E5B21-6459-11D2-8E39-00A0C969723B
> BEDB9670
> >
> > InstallProtocolInterface: CE345171-BA0B-11D2-8E4F-00A0C969723B
> BEDB95A0
> >
> > InstallProtocolInterface: 964E5B22-6459-11D2-8E39-00A0C969723B
> BEDAF030
> >
> > InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B
> BE2E6040
> >
> > Loading driver at 0x000B8C0C000 EntryPoint=0x000B9297440
> >
> > Loading driver at 0x000B8C0C000 EntryPoint=0x000B9297440
> >
> > InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF
> BEDB0718
> >
> > EFI stub: Booting Linux Kernel...
> >
> > ConvertPages: Incompatible memory types
> >
> > EFI stub: Using DTB from command line
> >
> > EFI stub: Exiting boot services and installing virtual address map...
> >
> > MmcHost: ExitBootServicesEvent+
> >
> > Marked card brcm-SDIO1 as removed
> >
> > Resetting Card brcm-SDIO1
> >
> > brcm-SDIO1 Card reset done.
> >
> > MmcHost: ExitBootServicesEvent-
> >
> > MmcHost: ExitBootServicesEvent+
> >
> > Marked card brcm-SDIO0 as removed
> >
> > Resetting Card brcm-SDIO0
> >
> > brcm-SDIO0 Card reset done.
> >
> > MmcHost: ExitBootServicesEvent-
> >
> > [0.00] Booting Linux on physical CPU 0x0
> >
> > [0.00] Initializing cgroup subsys cpu
> >
> > [0.00] Linux version 4.2.0+ (volovyan@LBRMN-LNXUB114) (gcc
> version
> > 4.9.2 20140904 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro
> > GCC 4.9-2014.09) ) #1 SMP PREEMPT Tue Oct 13 11:33:09 PDT 2015
> >
> > [0.00] CPU: AArch64 Processor [411fd073] revision 3
> >
> > [0.00] Detected PIPT I-cache on CPU0
> >
> > [0.00] earlycon: Early serial console at MMIO32 0x6613 (options
> > 'maxcpus=1')
> >
> > [0.00] bootconsole [uart0] enabled
> >
> > [0.00] Bad mode in Error handler detected, code 0xbf00 -- SError
> >
> > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted 4.2.0+ #1
> >
> > [0.00] Hardware name: SVK proto (DT)
> >
> > [0.00] task: ffc0007584b0 ti: ffc00074c000 task.ti:
> > ffc00074c000
> >
> > [0.00] PC is at setup_arch+0x260/0x5b4
> >
> > [0.00] LR is at setup_arch+0x25c/0x5b4
> >
> > [0.00] pc : [] lr : [] pstate:
> > 02c5
> >
> > [0.00] sp : ffc00074ff20
> >
> > [0.00] x29: ffc00074ff20 x28: 
> >
> > [0.00] x27: ffc81198 x26: 807cd000
> >
> > [0.00] x25: 807ca000 x24: 8000
> >
> > [0.00] x23:  x22: ffc000752000
> >
> > [0.00] x21: ffc000752610 x20: ffbffa80
> >
> > [0.00] x19: ffc8 x18: 
> >
> > [0.00] x17: 05e3 x16: 1000
> >
> > [0.00] x15: 1c00 x14: 0ffe
> >
> > [0.00] x13: 0020 x12: 0028
> >
> > [

Re: [edk2] ShellPkg: Network commands (ifconfig/ping) broken

[Ye, Ting]

One solution to support UEFI 2.4 network modules with UEFI 2.5 ifconfig is to 
add the code back to use HII services to perform setting. The definition of 
NIC_IP4_CONFIG_INFO and a private GUID gEfiNicIp4ConfigVariableGuid should be 
added into ShellPkg as UEFI 2.5 no longer keep the definition in MdeModulePkg. 
This will bring complexity to ShellPkg.

Also, more older network modules even uses a private protocol NicIp4Config 
protocol (defined in EdkCompatibilityPkg) to fix the issue in 
EFI_IP4_CONFIG_PROTOCOL. When Shell commands upgrade to Shell 2.0, the ifconfig 
removes the support of this protocol. Does the UEFI 2.5 ifconfig need support 
this protocol also to co-work with older platform?

Jaben, what's your opinion about this?

Best Regards,
Ye Ting


-Original Message-
From: Conen, Johannes [mailto:johannes.co...@siemens.com] 
Sent: Wednesday, November 11, 2015 8:22 PM
To: Ye, Ting; Laszlo Ersek; Wu, Jiaxin; edk2-devel@lists.01.org
Cc: Leif Lindholm (Linaro address)
Subject: AW: [edk2] ShellPkg: Network commands (ifconfig/ping) broken

Hi everyone,

I started with UEFI development only recently, in September, with UDK2014. When 
UDK2015 was released and there was no explicit notice of it being incompatible 
with UDK2014 platforms, I expected to be able to switch to it without any 
problems - I didn't expect forward compatibility, but backward compatibility 
like in most other development environments (e.g. if I write an application 
with the C95 standard, my application will still work with C99, but not the 
other way round). If I understood you correctly, neither the one nor the 
another is given atm - the UDK2014 shell won't work with UEFI 2.50 platforms as 
the EFI_IP4_CONFIG_PROTOCOL is not present and the UDK2015 shell won't work 
with UEFI 2.40 platforms as the EFI_IP4_CONFIG2_PROTOCOL is not present.

I don't think you can expect every UEFI developer to be on the EDK2 mailing 
list - I wasn't until a few days ago, the discussions about deprecating the 
protocol were in April and July according to the mail attachments from Jiaxin 
and with the amount of e-mails being sent over this mailing list on a daily 
basis, I doubt everyone will take notice of everything. For me as someone who 
is not involved into the development of EDKII itself, 90% of those e-mails are 
completely irrelevant to me and get deleted immediately.

Now, I don't write UEFI firmwares, but UEFI applications - for testing our 
computers before they leave the production factory. Something being 
incompatible with previous versions (getting deprecated doesn't necessarily 
mean it doesn't work anymore, only it shouldn't be used anymore) is a pretty 
important notice to me as I need to rewrite all applications that are affected 
by this as soon as our firmware developers switch to UDK2015/UEFI2.50 - or 
maintain two versions of my applications while some computers are still being 
shipped with UEFI 2.40 and others with UEFI 2.50. AFAIK (please correct me if 
I'm wrong there), until now, every application developed with an earlier 
version of EDK/EDKII could be used on platforms developed with later versions, 
too - e.g. I was able to use the applications shipped with the original EDK 
(like the ramdisk driver or the ftp client) on my UEFI 2.40 platform. That 
changing is a pretty big deal and should clearly be communicated within the 
release notes.

In this specific case, I wanted to customize the shell to include our 
diagnostic programs so we can boot the shell over PXE, run our diagnostics and 
send the results back to a server (therefore the need for ifconfig), thus 
eliminating the need for an EFI USB stick. Now, depending on which UEFI 
platform the PC has, we need to boot either the UEFI 2.40 compatible shell or 
the UEFI 2.50 compatible shell - which makes things a bit more complicated.

Greetings
Johannes


-Ursprüngliche Nachricht-
Von: Ye, Ting [mailto:ting...@intel.com] 
Gesendet: Mittwoch, 11. November 2015 04:36
An: Conen, Johannes; Laszlo Ersek; Wu, Jiaxin; edk2-devel@lists.01.org
Cc: Leif Lindholm (Linaro address)
Betreff: RE: [edk2] ShellPkg: Network commands (ifconfig/ping) broken

Hi Johannes,

I would like to add some background info here:

The original EFI_IP4_CONIFG_PROTOCOL has design issue that it cannot function 
well for a driver or an application (e.g. ifconfig) to configure static 
address. To solve this issue, ifconfig in UDK2014 defines a structure 
NIC_IP4_CONFIG_INFO and a private GUID gEfiNicIp4ConfigVariableGuid in 
NicIp4ConfigNvData.h under MdeModulePkg in order to deploy configuration 
through HII service. This is absolutely not a clean design.

In order to solve this issue, and also introduce new capabilities like 
configure DNS server address to IP4Config; a new protocol 
EFI_IP4_CONFIG2_PROTOCOL is introduced to UEFI 2.5 specification. The UEFI 
forum also discussed whether need keep EFI_IP4_CONFIG_PROTOCOL for backwards 
compatibility in a long period. Since the forum 

Re: [edk2] [PATCH v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI

[Yao, Jiewen]

Thanks Jorden, for your reminder.

Hi Laszlo
Per my understand, you add NULL implementation for PiSmmCommunicationPpi, just 
because SmmLockBoxPeiLib depends on it. Right?
How  about we update SmmLockBoxPeiLib to call 
InternalRestoreLockBoxFromSmram(), if PiSmmCommunicationPpi is not located?
==
  Status = PeiServicesLocatePpi (
 ,
 0,
 NULL,
 (VOID **)
 );
  if (EFI_ERROR (Status)) {
-return EFI_NOT_STARTED;
+return = InternalRestoreLockBoxFromSmram (Guid, Buffer, Length);
  }
==

SmmAccess is design to be silicon specific driver. I really do not want to let 
it touch generic infrastructure code like SmmCommunication.

Would you please do me a favor to try if it works?
If yes, we can update SmmLockBoxPeiLib.
If no, please let us know where is wrong, and we can try to figure out other 
better way.

Thank you
Yao Jiewen

-Original Message-
From: Justen, Jordan L 
Sent: Thursday, November 12, 2015 6:41 AM
To: Kinney, Michael D; Yao, Jiewen; Laszlo Ersek
Cc: edk2-devel@lists.01.org
Subject: RE: [edk2] [PATCH v4 07/41] OvmfPkg: add PEIM for providing 
TSEG-as-SMRAM during PEI

On 2015-11-05 07:45:21, Kinney, Michael D wrote:
> Laszlo,
> 
> Thanks for the details.  Your implementation looks good.
> 
> I will discuss this further with Jiewen to see if it makes sense to 
> provide additional implementations of this PPI that could be shared by 
> multiple platforms.

Mike, Jiewen,

Can you guys review Laszlo's patches 7-9?

Obviously I'd like to avoid adding forked versions of any modules under OVMF if 
the goal had been to have common modules that should work for all platforms.

You guys probably know better if we ought to be able to use common modules 
instead. If the common modules don't work, then hopefully it is something we 
can fix.

Laszlo,

Maybe it would be good to note in the commit message the common module location 
that were forced to fork, and why you needed to fork it.

-Jordan

> 
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> >Of Laszlo Ersek
> >Sent: Thursday, November 05, 2015 3:15 AM
> >To: Kinney, Michael D; edk2-de...@ml01.01.org
> >Cc: Justen, Jordan L
> >Subject: Re: [edk2] [PATCH v4 07/41] OvmfPkg: add PEIM for providing 
> >TSEG- as-SMRAM during PEI
> >
> >On 11/05/15 02:32, Kinney, Michael D wrote:
> >> Laszlo,
> >>
> >> For the EFI_PEI_COMMUNICATION_PPI, is there a reason you are not 
> >> using UefiCpuPkg\PiSmmCommunication\PiSmmCommunicationPei.inf to 
> >> produce
> >that PPI?
> >
> >Yes.
> >
> >When I wrote this patch originally on April 27th and the days after, 
> >there was no EFI_PEI_COMMUNICATION_PPI implementation in edk2; 
> >neither were plans known to add one.
> >
> >In addition, we had discussed the behavior of SmmLockBoxPeiLib at 
> >length, in an off-list thread that you had been CC'd on. Please 
> >search your archives for the message with the following metadata, and 
> >the sub-thread rooted in it:
> >
> >Message-ID: <553f96cc.9050...@redhat.com>
> >Date:   Tue, 28 Apr 2015 16:18:52 +0200
> >From:   Laszlo Ersek 
> >To: Yao, Jiewen 
> >CC: Justen, Jordan L ,
> >Zimmer, Vincent ,
> >Kinney, Michael D ,
> >Paolo Bonzini ,
> >Gerd Hoffmann ,
> >Michael S. Tsirkin 
> >Subject:Re: open-sourcing Intel's "IA32FamilyCpuPkg/PiSmmCpuDxeSmm"
> >
> >In that message, I asked:
> >
> >> In the whitepaper entitled "A Tour Beyond BIOS: Implementing S3 
> >> Resume with EDKII", page 25 says, under the heading "PEI Instance":
> >>
> >> The PEI instance of SmmLockboxLib has two ways to communicate with 
> >> the LockBox in SMRAM.
> >>
> >> 1) It uses the SMM_COMMUNICATION PPI to communicate the SmmLockbox 
> >> service provider, similar as DXE instance.
> >> 2) When the PEI instance is used before SMM ready, the 
> >> SMM_COMMUNICATION PPI will return EFI_NOT_STARTED. In this case, 
> >> PEI SmmLockBoxLib needs to search the SMRAM region directly to find 
> >> LockBox content.
> >>
> >> The question is why a platform would choose option (1), ever.
> >>
> >> Namely, option (1) depends on additional drivers:
> >> - SMM_COMMUNICATION_PPI that actually works
> >> - (which might further depend on PEI_SMM_CONTROL_PPI)
> >> - a PEIM driver that implements the privileged (SMM) half of 
> >> lockbox
> >>
> >> Whereas, option (2) is much simpler for the platform. It just needs 
> >> to provide a minimal SMM_COMMUNICATION_PPI where it always returns 
> >> EFI_NOT_STARTED. Then the lockbox library will do everything (and 
> >> depend only on PEI_SMM_ACCESS_PPI).
> >>
> >> So, the question is: why would a platform ever pick (1), given that 
> >> it is much 

Re: [edk2] [PATCH] ArmPlatformPkg: bring DS-5 scripts in line with linker script changes

[Ard Biesheuvel]

On 10 November 2015 at 20:06, Leif Lindholm  wrote:
> On 10 November 2015 at 18:10, Ard Biesheuvel  
> wrote:
>> On 6 November 2015 at 08:25, Ard Biesheuvel  
>> wrote:
>>> The ARM and AARCH64 linker scripts have recently been updated so that
>>> the memory layouts of the ELF and PE/COFF versions of each module are
>>> identical. In particular, this means that the ELF images now have a
>>> hole before the first section rather than starting at offset 0x0, which
>>> means we no longer have to correct for this difference when loading the
>>> ELF image into the debugger.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel 
>>
>> Leif,
>>
>> Vladimir has confirmed that this patch fixes the DS-5 problems he was 
>> observing.
>> Are you happy with me merging this patch?
>
> Sure, go ahead.
> (I lost track of the state of this thread somewhere.)
>

Thanks. Committed as SVN r18775 (with your ack)

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

Re: [edk2] [Patch] MdeModulePkg/BmpImageDecoderLib: Support ImageFormatUnknown type

[Tian, Feng]

Shall you change the commit title to  something like "error handling 
enhancement"?

Other looks good to me

Reviewed-by: Feng Tian 

Thanks
Feng

-Original Message-
From: Ni, Ruiyu 
Sent: Thursday, November 12, 2015 14:11
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu; Tian, Feng
Subject: [Patch] MdeModulePkg/BmpImageDecoderLib: Support ImageFormatUnknown 
type

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni 
Cc: Feng Tian 
---
 MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.c 
b/MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.c
index 86dcc91..28afd4f 100644
--- a/MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.c
+++ b/MdeModulePkg/Library/BmpImageDecoderLib/BmpImageDecoderLib.c
@@ -65,7 +65,7 @@ BmpImageDecoderLibConvertBmpToGopBlt (
 
   ASSERT ((GopBlt != NULL) && (GopBltSize != NULL));
 
-  if (ImageFormat != ImageFormatBmp) {
+  if ((ImageFormat != ImageFormatBmp) && (ImageFormat != ImageFormatUnknown)) {
 return EFI_UNSUPPORTED;
   }
 
-- 
1.9.5.msysgit.1

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

[edk2] [patch] NetworkPkg: Httpboot will fail the 2nd time result by wrong TCP state.

[Zhang Lubo]

If the 2nd boot quickly after the first succeed boot, it will function well, 
but if you
wait for some time and boot again, until the TCP state changed from established 
to
closed wait as the http server send fin flag, then boot fail occurred.

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

diff --git a/NetworkPkg/HttpDxe/HttpImpl.c b/NetworkPkg/HttpDxe/HttpImpl.c
index 2f4ce89..aec5cf7 100644
--- a/NetworkPkg/HttpDxe/HttpImpl.c
+++ b/NetworkPkg/HttpDxe/HttpImpl.c
@@ -460,10 +460,29 @@ EfiHttpRequest (
   goto Error1;
 }
   }
 
   //
+  // Check existing TCP connection, if in error state, recover TCP connection.
+  //
+  if (!Configure) {
+   if (HttpInstance->LocalAddressIsIPv6) {
+ Status = HttpConnectTcp6 (HttpInstance);
+ if (EFI_ERROR (Status)) {
+   return Status;
+ }
+
+   } else {
+ Status = HttpConnectTcp4 (HttpInstance);
+ if (EFI_ERROR (Status)) {
+  return Status;
+ }
+   }
+   
+  }
+
+  //
   // Create request message.
   //
   FileUrl = Url;
   if (*FileUrl != '/') {
 //
diff --git a/NetworkPkg/HttpDxe/HttpProto.c b/NetworkPkg/HttpDxe/HttpProto.c
index 39837a3..d22e33e 100644
--- a/NetworkPkg/HttpDxe/HttpProto.c
+++ b/NetworkPkg/HttpDxe/HttpProto.c
@@ -1175,13 +1175,12 @@ HttpConnectTcp4 (
   IN  HTTP_PROTOCOL*HttpInstance
   )
 {
   EFI_STATUSStatus;
   EFI_TCP4_CONNECTION_STATE Tcp4State;
-
-
-  if (HttpInstance->State != HTTP_STATE_TCP_CONFIGED || HttpInstance->Tcp4 == 
NULL) {
+ 
+  if (HttpInstance->State < HTTP_STATE_TCP_CONFIGED || HttpInstance->Tcp4 == 
NULL) {
 return EFI_NOT_READY;
   }
 
   Status = HttpInstance->Tcp4->GetModeData(
  HttpInstance->Tcp4, 
@@ -1196,11 +1195,15 @@ HttpConnectTcp4 (
 return Status;
   }
 
   if (Tcp4State > Tcp4StateEstablished) {
 HttpCloseConnection(HttpInstance);
-  }  
+  } else {
+if (HttpInstance->State == HTTP_STATE_TCP_CONNECTED) {
+  return EFI_SUCCESS;
+} 
+  }
 
   return HttpCreateConnection (HttpInstance);
 }
 
 /**
@@ -1219,11 +1222,11 @@ HttpConnectTcp6 (
   )
 {
   EFI_STATUSStatus;
   EFI_TCP6_CONNECTION_STATE Tcp6State;
 
-  if (HttpInstance->State != HTTP_STATE_TCP_CONFIGED || HttpInstance->Tcp6 == 
NULL) {
+  if (HttpInstance->State < HTTP_STATE_TCP_CONFIGED || HttpInstance->Tcp6 == 
NULL) {
 return EFI_NOT_READY;
   }
 
   Status = HttpInstance->Tcp6->GetModeData (
  HttpInstance->Tcp6,
@@ -1239,10 +1242,14 @@ HttpConnectTcp6 (
  return Status;
   }
 
   if (Tcp6State > Tcp6StateEstablished) {
 HttpCloseConnection (HttpInstance);
+  } else {
+if (HttpInstance->State == HTTP_STATE_TCP_CONNECTED) {
+  return EFI_SUCCESS;
+}
   }
 
   return HttpCreateConnection (HttpInstance);
 }
 
-- 
1.9.5.msysgit.1

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

Re: [edk2] EFI GOP with manual vsync trigger

[Michael Zimmermann]

I've started investigating in the timer event problem and I think I have
some weird problem with my platform drivers(I hope, so it's not a EDK2 bug).

If I create a timer that runs every 100ms which does nothing but a
stall(1), the thread mode code stops after some random time(usually in edk2
shell so I guess it's a race condition which needs some cpu load).

When threadmode code is stopped the timer continues getting called and even
if I stop the timer afterwards(with CloseEvent) it keeps being stopped.

Is there a way to get the threadmode context from inside a timer callback?
This way I could read the PC to check what's going on.

Michael

On Wed, Nov 11, 2015 at 8:10 PM, Kinney, Michael D <
michael.d.kin...@intel.com> wrote:

> Michael,
>
> A periodic event timer at 30 times a second should not cause pauses
> forever, unless the action you are performing in the event notification
> function takes more than 1/30 of a second to complete.  You should be able
> to just add a periodic event handler that does nothing, so you can measure
> what the overhead is.
>
> Another option is to use the performance counter in the TimerLib each time
> a Blt() is called (GetPerformanceCounterProperties() and
> GetPerformanceCounter()).  When Blt() is called frequently, the amount of
> time since last vsync will have elapsed, and you can go the vsync action
> within the Blt() call.  If you also set a one shot timer event, so if the
> last call to Blt() did not do a vsync and there are no more Blt() calls,
> 1/30th of a second later, the vsync action can be done.  Every time Blt()
> is called, the one shot timer can be re-armed.  This way, the one shot
> timer event is not actually executed very often.
>
> Mike
>
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Michael Zimmermann
> >Sent: Wednesday, November 11, 2015 12:32 AM
> >To: edk2-devel@lists.01.org
> >Subject: [edk2] EFI GOP with manual vsync trigger
> >
> >Hi,
> >
> >my Graphics HW uses a manual vsync trigger. That means that after drawing
> >to the framebuffer I need to manually trigger vsync(you can compare it to
> >switching between double buffers).
> >
> >The problem is that UEFI's GraphicsOutputProtocol(GOP) doesn't take care
> of
> >HW that needs a flush.
> >While issuing the trigger after every Blt Operation works, this obviously
> >causes extremely slow rendering for applications like the Shell which call
> >Blt very often(like for every character).
> >
> >Also I can't use a timer to set the trigger(like 30times a second) because
> >it takes too much time and the Timer Interrupt ends up consuming too much
> >time and the "normal" code gets paused forever.
> >
> >Do you have any other ideas how to handle this?
> >
> >Thx
> >Michael
> >___
> >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 v4 02/41] OvmfPkg: Sec: force reinit of BaseExtractGuidedSectionLib handler table

[Jordan Justen]

On 2015-11-03 13:00:38, Laszlo Ersek wrote:
> BaseExtractGuidedSectionLib uses a table at the static physical address
> PcdGuidedExtractHandlerTableAddress, and modules that are linked against
> BaseExtractGuidedSectionLib are expected to work together on that table.
> Namely, some modules can register handlers for GUIDed sections, some other
> modules can decode such sections with the pre-registered handlers. The
> table carries persistent information between these modules.
> 
> BaseExtractGuidedSectionLib checks a table signature whenever it is used
> (by whichever module that is linked against it), and at the first use
> (identified by a signature mismatch) it initializes the table.
> 
> One of the module types that BaseExtractGuidedSectionLib can be used with
> is SEC, if the SEC module in question runs with the platform's RAM already
> available.
> 
> In such cases the question emerges whether the initial contents of the RAM
> (ie. contents that predate the very first signature check) can be trusted.
> Normally RAM starts out with all zeroes (leading to a signature mismatch
> on the first check); however a malicious runtime OS can populate the area
> with some payload, then force a warm platform reset or an S3
> suspend-and-resume. In such cases the signature check in the SEC module
> might not fire, and ExtractGuidedSectionDecode() might run code injected
> by the runtime OS, as part of SEC (ie. with high privileges).
> 
> -D SMM_REQUIRE signals that the firmware should be secure against
> tampering from a malicious OS, therefore we clear the handler table in
> SEC, in such builds.
> 
> See also git commit ad43bc6b2e (SVN rev 15433) -- this patch secures the
> (d) and (e) code paths examined in that commit. Furthermore, a
> non-malicious runtime OS will observe no change in behavior; see case (c)
> in said commit.
> 
> Cc: Michael Kinney 
> Cc: Jordan Justen 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> [michael.d.kin...@intel.com: prevent VS20xx loop intrinsic with volatile]
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Michael Kinney 
> ---
> 
> Notes:
> v3:
> - volatile-qualify the Table pointer to prevent VS20xx from turning the
>   zeroing loop into a compiler intrinsic [Mike]
> 
> v2:
> - This implements option #2 from Jordan's feedback at
>   .
>   Liming was okay with that option:
>   .
> 
> - This patch replaces the following patches from the v1 series:
> 
>   [PATCH 03/58] MdePkg: BaseExtractGuidedSectionLib: allow forced reinit
> of handler table
>   
> 
>   [PATCH 04/58] OvmfPkg: set PcdBaseExtractGuidedSectionLibForceInit for
> SEC on SMM_REQUIRE
>   
> 
>  OvmfPkg/Sec/SecMain.inf |  5 
>  OvmfPkg/Sec/SecMain.c   | 28 
>  2 files changed, 33 insertions(+)
> 
> diff --git a/OvmfPkg/Sec/SecMain.inf b/OvmfPkg/Sec/SecMain.inf
> index 2f78f3c..8f4d86c 100644
> --- a/OvmfPkg/Sec/SecMain.inf
> +++ b/OvmfPkg/Sec/SecMain.inf
> @@ -68,3 +68,8 @@ [Pcd]
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPageTablesBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamBase
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfSecPeiTempRamSize
> +  gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
> +  gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
> +
> +[FeaturePcd]
> +  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
> diff --git a/OvmfPkg/Sec/SecMain.c b/OvmfPkg/Sec/SecMain.c
> index 4f87059..1556032 100644
> --- a/OvmfPkg/Sec/SecMain.c
> +++ b/OvmfPkg/Sec/SecMain.c
> @@ -699,8 +699,36 @@ SecCoreStartupWithStack (
>IA32_DESCRIPTOR IdtDescriptor;
>UINT32  Index;
>  
> +  //
> +  // This code may be running on the S3 resume boot path, where RAM has been
> +  // populated by the runtime guest OS. Guarantee the reinitialization of the
> +  // BaseExtractGuidedSectionLib handler table, before the constructor of
> +  // LzmaCustomDecompressLib calls into BaseExtractGuidedSectionLib, due to 
> our
> +  // explicit ProcessLibraryConstructorList() call below.
> +  //
> +  // We must not rely on any libraries before calling
> +  // ProcessLibraryConstructorList(), thus we clear the table with an
> +  // open-coded loop. (The FeaturePcdGet() and FixedPcdGetXX() macro
> +  // invocations are preprocessed to constants.)
> +  //

I think this comment could be more terse. What about:

  //
  // To ensure SMM can't be compromised on S3 resume, we must force re-init
  // of the BaseExtractGuidedSectionLib. 

Re: [edk2] [PATCH v4 15/41] OvmfPkg: resolve ReportStatusCodeLib for DXE_SMM_DRIVER modules

[Jordan Justen]

Reviewed-by: Jordan Justen 

On 2015-11-03 13:00:51, Laszlo Ersek wrote:
> PiSmmCpuDxeSmm depends on this library class, and it's okay to resolve it
> generally for all DXE_SMM_DRIVER modules.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
>  OvmfPkg/OvmfPkgX64.dsc | 1 +
>  3 files changed, 3 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index a19d4e2..6a93fd2 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -299,6 +299,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
>
> MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
> +  
> ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
>
> SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index d177154..dbaf8fb 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -304,6 +304,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
>
> MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
> +  
> ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
>
> SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 7908a31..a7efe52 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -304,6 +304,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
>
> MemoryAllocationLib|MdePkg/Library/SmmMemoryAllocationLib/SmmMemoryAllocationLib.inf
> +  
> ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
>HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
>SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
>
> SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
> -- 
> 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 v4 11/41] OvmfPkg: pull in CpuIo2Smm driver

[Jordan Justen]

Reviewed-by: Jordan Justen 

On 2015-11-03 13:00:47, Laszlo Ersek wrote:
> This driver provides EFI_SMM_CPU_IO2_PROTOCOL, which the SMM core depends
> on in its gEfiDxeSmmReadyToLockProtocolGuid callback
> (SmmReadyToLockHandler(), "MdeModulePkg/Core/PiSmmCore/PiSmmCore.c").
> 
> Approached on a higher level, this driver provides the SmmIo member of the
> EFI_SMM_SYSTEM_TABLE2 (SMST).
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 11 +++
>  OvmfPkg/OvmfPkgIa32X64.dsc | 11 +++
>  OvmfPkg/OvmfPkgX64.dsc | 11 +++
>  OvmfPkg/OvmfPkgIa32.fdf|  9 +
>  OvmfPkg/OvmfPkgIa32X64.fdf |  9 +
>  OvmfPkg/OvmfPkgX64.fdf |  9 +
>  6 files changed, 60 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index ca3be30..6cfd58e 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -292,6 +292,12 @@ [LibraryClasses.common.UEFI_APPLICATION]
>  [LibraryClasses.common.DXE_SMM_DRIVER]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> +  
> SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
> +!ifdef $(DEBUG_ON_SERIAL_PORT)
> +  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> +!else
> +  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
> +!endif
>  
>  [LibraryClasses.common.SMM_CORE]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> @@ -697,4 +703,9 @@ [Components]
># SMM_CORE
>#
>MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
> +
> +  #
> +  # Privileged drivers (DXE_SMM_DRIVER modules)
> +  #
> +  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
>  !endif
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 60f085a..6679e8a 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -297,6 +297,12 @@ [LibraryClasses.common.UEFI_APPLICATION]
>  [LibraryClasses.common.DXE_SMM_DRIVER]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> +  
> SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
> +!ifdef $(DEBUG_ON_SERIAL_PORT)
> +  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> +!else
> +  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
> +!endif
>  
>  [LibraryClasses.common.SMM_CORE]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> @@ -704,4 +710,9 @@ [Components.X64]
># SMM_CORE
>#
>MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
> +
> +  #
> +  # Privileged drivers (DXE_SMM_DRIVER modules)
> +  #
> +  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
>  !endif
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 0621292..2651042 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -297,6 +297,12 @@ [LibraryClasses.common.UEFI_APPLICATION]
>  [LibraryClasses.common.DXE_SMM_DRIVER]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> +  
> SmmServicesTableLib|MdePkg/Library/SmmServicesTableLib/SmmServicesTableLib.inf
> +!ifdef $(DEBUG_ON_SERIAL_PORT)
> +  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> +!else
> +  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
> +!endif
>  
>  [LibraryClasses.common.SMM_CORE]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> @@ -702,4 +708,9 @@ [Components]
># SMM_CORE
>#
>MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
> +
> +  #
> +  # Privileged drivers (DXE_SMM_DRIVER modules)
> +  #
> +  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
>  !endif
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
> index f705918..e908198 100644
> --- a/OvmfPkg/OvmfPkgIa32.fdf
> +++ b/OvmfPkg/OvmfPkgIa32.fdf
> @@ -360,6 +360,7 @@ [FV.DXEFV]
>  INF  OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
>  INF  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
>  INF  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
> +INF  UefiCpuPkg/CpuIo2Smm/CpuIo2Smm.inf
>  !endif
>  
>  
> 
> @@ -495,3 +496,11 @@ [Rule.Common.SMM_CORE]
>  UI   STRING="$(MODULE_NAME)" Optional
>  VERSION  STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
>}
> +
> +[Rule.Common.DXE_SMM_DRIVER]
> +  FILE SMM = $(NAMED_GUID) {
> +SMM_DEPEXSMM_DEPEX Optional  $(INF_OUTPUT)/$(MODULE_NAME).depex
> +PE32 PE32$(INF_OUTPUT)/$(MODULE_NAME).efi
> +UI   STRING="$(MODULE_NAME)" Optional
> +VERSION  STRING="$(INF_VERSION)" Optional BUILD_NUM=$(BUILD_NUMBER)
> +  }
> diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
> index 93a8d44..5300a71 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.fdf

Re: [edk2] [PATCH v4 16/41] OvmfPkg: resolve CpuExceptionHandlerLib for DXE_SMM_DRIVER modules

[Jordan Justen]

Reviewed-by: Jordan Justen 

On 2015-11-03 13:00:52, Laszlo Ersek wrote:
> UefiCpuPkg/PiSmmCpuDxeSmm depends on this library (the
> RegisterCpuInterruptHandler() function specifically) to set up its
> specialized page fault handler (SmiPFHandler() -> DumpModuleInfoByIp()).
> It doesn't hurt to resolve this library class for all DXE_SMM_DRIVER
> modules.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> v2:
> - new in v2 (the CpuExceptionHandlerLib dependency  of PiSmmCpuDxeSmm is
>   new in Mike's code, relative to Quark)
> 
>  OvmfPkg/OvmfPkgIa32.dsc| 1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc | 1 +
>  OvmfPkg/OvmfPkgX64.dsc | 1 +
>  3 files changed, 3 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 6a93fd2..f3de592 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -308,6 +308,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
>  !else
>DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
>  !endif
> +  
> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
>  
>  [LibraryClasses.common.SMM_CORE]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index dbaf8fb..ee97c84 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -313,6 +313,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
>  !else
>DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
>  !endif
> +  
> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
>  
>  [LibraryClasses.common.SMM_CORE]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index a7efe52..6ab7ffe 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -313,6 +313,7 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
>  !else
>DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
>  !endif
> +  
> CpuExceptionHandlerLib|UefiCpuPkg/Library/CpuExceptionHandlerLib/SmmCpuExceptionHandlerLib.inf
>  
>  [LibraryClasses.common.SMM_CORE]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
> -- 
> 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 v4 10/41] OvmfPkg: pull in the SMM IPL and SMM core

[Jordan Justen]

Reviewed-by: Jordan Justen 

On 2015-11-03 13:00:46, Laszlo Ersek wrote:
> "MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf" (a DXE_RUNTIME_DRIVER)
> implements the SMM Initial Program Loader. It produces
> EFI_SMM_BASE2_PROTOCOL and EFI_SMM_COMMUNICATION_PROTOCOL, relying on:
> - EFI_SMM_ACCESS2_PROTOCOL
>   (provided by OvmfPkg/SmmAccess/SmmAccess2Dxe.inf),
> - EFI_SMM_CONTROL2_PROTOCOL
>   (provided by OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf).
> 
> (The SMM IPL also depends on EFI_SMM_CONFIGURATION_PROTOCOL_GUID, but this
> dependency is not enforced in the entry point. A protocol notify callback
> is registered instead, hence we can delay providing that protocol via the
> PiSmmCpuDxeSmm driver that is (to be) imported from
> Quark_EDKII_v1.1.0/IA32FamilyCpuBasePkg/.)
> 
> The SMM IPL loads the SMM core into SMRAM and executes it from there.
> Therefore we add the SMM core to the build as well.
> 
> For the SMM core, a number of library classes need to be resolved.
> Furthermore, each FDF file must provide the GenFds.py BaseTools utility
> with a build rule for SMM_CORE; we copy the DXE_CORE's rule.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 21 
>  OvmfPkg/OvmfPkgIa32X64.dsc | 21 
>  OvmfPkg/OvmfPkgX64.dsc | 21 
>  OvmfPkg/OvmfPkgIa32.fdf|  9 +
>  OvmfPkg/OvmfPkgIa32X64.fdf |  9 +
>  OvmfPkg/OvmfPkgX64.fdf |  9 +
>  6 files changed, 90 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index c71a2f4..ca3be30 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -296,6 +296,17 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
>  [LibraryClasses.common.SMM_CORE]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> +  
> SmmCorePlatformHookLib|MdeModulePkg/Library/SmmCorePlatformHookLibNull/SmmCorePlatformHookLibNull.inf
> +  
> MemoryAllocationLib|MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryAllocationLib.inf
> +  
> ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
> +  HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> +  SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
> +  
> SmmServicesTableLib|MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.inf
> +!ifdef $(DEBUG_ON_SERIAL_PORT)
> +  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> +!else
> +  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
> +!endif
>  
>  
> 
>  #
> @@ -676,4 +687,14 @@ [Components]
>  !if $(SMM_REQUIRE) == TRUE
>OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
>OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
> +
> +  #
> +  # SMM Initial Program Load (a DXE_RUNTIME_DRIVER)
> +  #
> +  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
> +
> +  #
> +  # SMM_CORE
> +  #
> +  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
>  !endif
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index a1e8f0d..60f085a 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -301,6 +301,17 @@ [LibraryClasses.common.DXE_SMM_DRIVER]
>  [LibraryClasses.common.SMM_CORE]
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>TimerLib|OvmfPkg/Library/AcpiTimerLib/DxeAcpiTimerLib.inf
> +  
> SmmCorePlatformHookLib|MdeModulePkg/Library/SmmCorePlatformHookLibNull/SmmCorePlatformHookLibNull.inf
> +  
> MemoryAllocationLib|MdeModulePkg/Library/PiSmmCoreMemoryAllocationLib/PiSmmCoreMemoryAllocationLib.inf
> +  
> ReportStatusCodeLib|MdeModulePkg/Library/DxeReportStatusCodeLib/DxeReportStatusCodeLib.inf
> +  HobLib|MdePkg/Library/DxeHobLib/DxeHobLib.inf
> +  SmmMemLib|MdePkg/Library/SmmMemLib/SmmMemLib.inf
> +  
> SmmServicesTableLib|MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmServicesTableLib.inf
> +!ifdef $(DEBUG_ON_SERIAL_PORT)
> +  DebugLib|MdePkg/Library/BaseDebugLibSerialPort/BaseDebugLibSerialPort.inf
> +!else
> +  DebugLib|OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
> +!endif
>  
>  
> 
>  #
> @@ -683,4 +694,14 @@ [Components.X64]
>  !if $(SMM_REQUIRE) == TRUE
>OvmfPkg/SmmAccess/SmmAccess2Dxe.inf
>OvmfPkg/SmmControl2Dxe/SmmControl2Dxe.inf
> +
> +  #
> +  # SMM Initial Program Load (a DXE_RUNTIME_DRIVER)
> +  #
> +  MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf
> +
> +  #
> +  # SMM_CORE
> +  #
> +  MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
>  !endif
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 1176629..0621292 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -301,6 +301,17 @@ [LibraryClasses.common.DXE_SMM_DRIVER]

Re: [edk2] [PATCH v4 12/41] OvmfPkg: AcpiS3SaveDxe: don't fake LockBox protocol if SMM_REQUIRE

[Jordan Justen]

Reviewed-by: Jordan Justen 

On 2015-11-03 13:00:48, Laszlo Ersek wrote:
> In SVN r15306 (git commit d4ba06df), "OvmfPkg: S3 Resume: fake LockBox
> protocol for BootScriptExecutorDxe", we installed a fake LockBox protocol
> in OVMF's AcpiS3SaveDxe clone. While our other AcpiS3SaveDxe
> customizations remain valid (or harmless), said change is invalid when
> OVMF is built with -D SMM_REQUIRE and includes the real protocol provider,
> "MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf".
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek 
> ---
>  OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf |  3 ++-
>  OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c  | 14 --
>  2 files changed, 10 insertions(+), 7 deletions(-)
> 
> diff --git a/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf 
> b/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
> index 4cc0713..a288b95 100644
> --- a/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
> +++ b/OvmfPkg/AcpiS3SaveDxe/AcpiS3SaveDxe.inf
> @@ -59,7 +59,7 @@ [Guids]
>gEfiEndOfDxeEventGroupGuid## CONSUMES  ## Event
>  
>  [Protocols]
> -  gEfiLockBoxProtocolGuid   # PROTOCOL ALWAYS_PRODUCED
> +  gEfiLockBoxProtocolGuid   # PROTOCOL SOMETIMES_PRODUCED
>gEfiLegacyBiosProtocolGuid# PROTOCOL ALWAYS_CONSUMED
>gEfiLegacyRegion2ProtocolGuid # PROTOCOL SOMETIMES_CONSUMED
>gFrameworkEfiMpServiceProtocolGuid# PROTOCOL SOMETIMES_CONSUMED
> @@ -71,6 +71,7 @@ [Pcd]
>gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySize
> ## CONSUMES
>gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3BootScriptStackSize   
> ## CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdUse1GPageTable
> +  gUefiOvmfPkgTokenSpaceGuid.PcdSmmSmramRequire
> ## CONSUMES
>  
>  [Depex]
>gEfiVariableArchProtocolGuid AND gEfiVariableWriteArchProtocolGuid
> diff --git a/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c 
> b/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
> index f20560f..e3ff234 100644
> --- a/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
> +++ b/OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c
> @@ -538,12 +538,14 @@ InstallEndOfDxeCallback (
>  return EFI_LOAD_ERROR;
>}
>  
> -  Status = gBS->InstallMultipleProtocolInterfaces (
> -  ,
> -  , NULL,
> -  NULL
> -  );
> -  ASSERT_EFI_ERROR (Status);
> +  if (!FeaturePcdGet (PcdSmmSmramRequire)) {
> +Status = gBS->InstallMultipleProtocolInterfaces (
> +,
> +, NULL,
> +NULL
> +);
> +ASSERT_EFI_ERROR (Status);
> +  }
>  
>Status = gBS->CreateEventEx (
>EVT_NOTIFY_SIGNAL,
> -- 
> 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 v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI

[Jordan Justen]

On 2015-11-05 07:45:21, Kinney, Michael D wrote:
> Laszlo,
> 
> Thanks for the details.  Your implementation looks good.
> 
> I will discuss this further with Jiewen to see if it makes sense to
> provide additional implementations of this PPI that could be shared
> by multiple platforms.

Mike, Jiewen,

Can you guys review Laszlo's patches 7-9?

Obviously I'd like to avoid adding forked versions of any modules
under OVMF if the goal had been to have common modules that should
work for all platforms.

You guys probably know better if we ought to be able to use common
modules instead. If the common modules don't work, then hopefully it
is something we can fix.

Laszlo,

Maybe it would be good to note in the commit message the common module
location that were forced to fork, and why you needed to fork it.

-Jordan

> 
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> >Laszlo Ersek
> >Sent: Thursday, November 05, 2015 3:15 AM
> >To: Kinney, Michael D; edk2-de...@ml01.01.org
> >Cc: Justen, Jordan L
> >Subject: Re: [edk2] [PATCH v4 07/41] OvmfPkg: add PEIM for providing TSEG-
> >as-SMRAM during PEI
> >
> >On 11/05/15 02:32, Kinney, Michael D wrote:
> >> Laszlo,
> >>
> >> For the EFI_PEI_COMMUNICATION_PPI, is there a reason you are not using
> >> UefiCpuPkg\PiSmmCommunication\PiSmmCommunicationPei.inf to produce
> >that PPI?
> >
> >Yes.
> >
> >When I wrote this patch originally on April 27th and the days after,
> >there was no EFI_PEI_COMMUNICATION_PPI implementation in edk2; neither
> >were plans known to add one.
> >
> >In addition, we had discussed the behavior of SmmLockBoxPeiLib at
> >length, in an off-list thread that you had been CC'd on. Please search
> >your archives for the message with the following metadata, and the
> >sub-thread rooted in it:
> >
> >Message-ID: <553f96cc.9050...@redhat.com>
> >Date:   Tue, 28 Apr 2015 16:18:52 +0200
> >From:   Laszlo Ersek 
> >To: Yao, Jiewen 
> >CC: Justen, Jordan L ,
> >Zimmer, Vincent ,
> >Kinney, Michael D ,
> >Paolo Bonzini ,
> >Gerd Hoffmann ,
> >Michael S. Tsirkin 
> >Subject:Re: open-sourcing Intel's "IA32FamilyCpuPkg/PiSmmCpuDxeSmm"
> >
> >In that message, I asked:
> >
> >> In the whitepaper entitled "A Tour Beyond BIOS: Implementing S3 Resume
> >> with EDKII", page 25 says, under the heading "PEI Instance":
> >>
> >> The PEI instance of SmmLockboxLib has two ways to communicate with
> >> the LockBox in SMRAM.
> >>
> >> 1) It uses the SMM_COMMUNICATION PPI to communicate the SmmLockbox
> >> service provider, similar as DXE instance.
> >> 2) When the PEI instance is used before SMM ready, the
> >> SMM_COMMUNICATION PPI will return EFI_NOT_STARTED. In this case,
> >> PEI SmmLockBoxLib needs to search the SMRAM region directly to
> >> find LockBox content.
> >>
> >> The question is why a platform would choose option (1), ever.
> >>
> >> Namely, option (1) depends on additional drivers:
> >> - SMM_COMMUNICATION_PPI that actually works
> >> - (which might further depend on PEI_SMM_CONTROL_PPI)
> >> - a PEIM driver that implements the privileged (SMM) half of lockbox
> >>
> >> Whereas, option (2) is much simpler for the platform. It just needs to
> >> provide a minimal SMM_COMMUNICATION_PPI where it always returns
> >> EFI_NOT_STARTED. Then the lockbox library will do everything (and
> >> depend only on PEI_SMM_ACCESS_PPI).
> >>
> >> So, the question is: why would a platform ever pick (1), given that it
> >> is much more work to implement, for (as far as I can see) no benefit?
> >
> >And Jiewen replied (the same day),
> >
> >> Ah, I see. The only reason is that: A PEIM might need to restore
> >> lockbox data *before* SMM rebase happen. Then it has to use #2.
> >>
> >> A PEIM might need to restore lockbox data *after* SMM rebase happen.
> >> Then it has to use #1. (Scanning SMRAM does not work at that moment,
> >> which is enforced by SMRR)
> >
> >I couldn't see any grounds from Jiewen's answer to abandon option (2).
> >Option (2) actually worked, plus it was actually the *only* possibility
> >to make SmmLockboxLib work in OVMF (see above).
> >
> >I would like to stick with this approach.
> >
> >Thanks
> >Laszlo
> >
> >>
> >> Thanks,
> >>
> >> Mike
> >>
> >>> -Original Message-
> >>> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >>> Sent: Tuesday, November 03, 2015 1:01 PM
> >>> To: edk2-de...@ml01.01.org
> >>> Cc: Kinney, Michael D; Justen, Jordan L
> >>> Subject: [PATCH v4 07/41] OvmfPkg: add PEIM for providing TSEG-as-
> >SMRAM
> >>> during PEI
> >>>
> >>> "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.inf" is the
> >library
> >>> instance that implements the LockBoxLib library class with SMRAM access
> >>> for the PEI phase.
> 

[edk2] [patch 5/7] MdeModulePkg/Include/Guid:Add Guid file

[Dandan Bi]

Add the FrontPage Guid and SetupEnter Guid used by new added libraries.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 MdeModulePkg/Include/Guid/HiiFrontPageFormset.h | 26 +
 MdeModulePkg/Include/Guid/HiiSetupEnter.h   | 26 +
 2 files changed, 52 insertions(+)
 create mode 100644 MdeModulePkg/Include/Guid/HiiFrontPageFormset.h
 create mode 100644 MdeModulePkg/Include/Guid/HiiSetupEnter.h

diff --git a/MdeModulePkg/Include/Guid/HiiFrontPageFormset.h 
b/MdeModulePkg/Include/Guid/HiiFrontPageFormset.h
new file mode 100644
index 000..27b9be3
--- /dev/null
+++ b/MdeModulePkg/Include/Guid/HiiFrontPageFormset.h
@@ -0,0 +1,26 @@
+/**@file
+The front page GUID.
+  
+Copyright (c) 2010-2015, Intel Corporation. All rights reserved.
+This software and associated documentation (if any) is furnished
+under a license and may only be used or copied in accordance
+with the terms of the license. Except as permitted by such
+license, no part of this software or documentation may be
+reproduced, stored in a retrieval system, or transmitted in any
+form or by any means without the express written consent of
+Intel Corporation.
+
+**/
+
+#ifndef __HII_FRONT_PAGE_FORMSET_H__
+#define __HII_FRONT_PAGE_FORMSET_H__
+
+///
+/// Guid define to group the item show on the front page.
+///
+#define EFI_IFR_FRONT_PAGE_GUID \
+  { 0xe58809f8, 0xfbc1, 0x48e2, { 0x88, 0x3a, 0xa3, 0xf, 0xdc, 0x4b, 0x44, 
0x1e } }
+
+extern EFI_GUID gEfiIfrFrontPageGuid;
+
+#endif
diff --git a/MdeModulePkg/Include/Guid/HiiSetupEnter.h 
b/MdeModulePkg/Include/Guid/HiiSetupEnter.h
new file mode 100644
index 000..5296b35
--- /dev/null
+++ b/MdeModulePkg/Include/Guid/HiiSetupEnter.h
@@ -0,0 +1,26 @@
+/**@file
+GUID used to indiacte enter setup page.
+  
+Copyright (c) 2015, Intel Corporation. All rights reserved.
+This software and associated documentation (if any) is furnished
+under a license and may only be used or copied in accordance
+with the terms of the license. Except as permitted by such
+license, no part of this software or documentation may be
+reproduced, stored in a retrieval system, or transmitted in any
+form or by any means without the express written consent of
+Intel Corporation.
+
+**/
+
+#ifndef __HII_SETUP_ENTER_H__
+#define __HII_SETUP_ENTER_H__
+
+///
+/// This Guid is installed as protocol guid to notify system enter into Front 
Page for Setup configuration.
+///
+#define EFI_SETUP_ENTER_GUID \
+  { 0x71202EEE, 0x5F53, 0x40d9, {0xAB, 0x3D, 0x9E, 0x0C, 0x26, 0xD9, 0x66, 
0x57 }}
+
+extern EFI_GUID gEfiSetupEnterGuid;
+
+#endif
-- 
1.9.5.msysgit.1

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

[edk2] [patch 6/7] MdeModulePkg: To support new UiApp.

[Dandan Bi]

Add the new added Guid and libraries to the dec and dsc file in
MdeModulePkg.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 MdeModulePkg/MdeModulePkg.dec | 6 ++
 MdeModulePkg/MdeModulePkg.dsc | 4 
 2 files changed, 10 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index d45e49a..e63a48f 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -321,10 +321,16 @@
   ## Include/Guid/TtyTerm.h
   gEfiTtyTermGuid= { 0x7d916d80, 0x5bb1, 0x458c, {0xa4, 0x8f, 
0xe2, 0x5f, 0xdd, 0x51, 0xef, 0x94 }}
 
   ## Include/Guid/HiiBootMaintenanceFormset.h
   gEfiIfrBootMaintenanceGuid  = { 0xb2dedc91, 0xd59f, 0x48d2, { 0x89, 
0x8a, 0x12, 0x49, 0xc, 0x74, 0xa4, 0xe0 }}
+
+  ## Include/Guid/HiiFrontPageFormset.h
+  gEfiIfrFrontPageGuid= { 0xe58809f8, 0xfbc1, 0x48e2, { 0x88, 0x3a, 
0xa3, 0x0f, 0xdc, 0x4b, 0x44, 0x1e } }
+
+  ## Include/Guid/HiiSetupEnter.h
+  gEfiSetupEnterGuid  = { 0x71202EEE, 0x5F53, 0x40d9, {0xAB, 0x3D, 
0x9E, 0x0C, 0x26, 0xD9, 0x66, 0x57 }}
   
 [Ppis]
   ## Include/Ppi/AtaController.h
   gPeiAtaControllerPpiGuid   = { 0xa45e60d1, 0xc719, 0x44aa, { 0xb0, 0x7a, 
0xaa, 0x77, 0x7f, 0x85, 0x90, 0x6d }}
 
diff --git a/MdeModulePkg/MdeModulePkg.dsc b/MdeModulePkg/MdeModulePkg.dsc
index 62f596d..0c9f3ee 100644
--- a/MdeModulePkg/MdeModulePkg.dsc
+++ b/MdeModulePkg/MdeModulePkg.dsc
@@ -96,10 +96,14 @@
   
CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.inf
   
PlatformBootManagerLib|MdeModulePkg/Library/PlatformBootManagerLibNull/PlatformBootManagerLibNull.inf
   
TpmMeasurementLib|MdeModulePkg/Library/TpmMeasurementLibNull/TpmMeasurementLibNull.inf
   
AuthVariableLib|MdeModulePkg/Library/AuthVariableLibNull/AuthVariableLibNull.inf
   VarCheckLib|MdeModulePkg/Library/VarCheckLib/VarCheckLib.inf
+  DeviceManagerLib|MdeModulePkg/Library/DeviceManagerLib/DeviceManagerLib.inf
+  BootManagerLib|MdeModulePkg/Library/BootManagerLib/BootManagerLib.inf
+  
BootMaintenanceManagerLib|MdeModulePkg/Library/BootMaintenanceManagerLib/BootMaintenanceManagerLib.inf
+  FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
 
 [LibraryClasses.EBC.PEIM]
   IoLib|MdePkg/Library/PeiIoLibCpuIo/PeiIoLibCpuIo.inf
 
 [LibraryClasses.common.PEI_CORE]
-- 
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/7] MdeModulePkg:Create Device Manager Library.

[Dandan Bi]

Split the device manager library from UiApp in MdeModulePkg/Application
and put the library in MdeModulePkg/Library.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 .../Library/DeviceManagerLib/DeviceManager.c   | 953 +
 .../Library/DeviceManagerLib/DeviceManager.h   | 195 +
 .../Library/DeviceManagerLib/DeviceManagerLib.inf  |  58 ++
 .../DeviceManagerLib/DeviceManagerStrings.uni  | Bin 0 -> 7804 bytes
 .../Library/DeviceManagerLib/DeviceManagerVfr.Vfr  |  67 ++
 5 files changed, 1273 insertions(+)
 create mode 100644 MdeModulePkg/Library/DeviceManagerLib/DeviceManager.c
 create mode 100644 MdeModulePkg/Library/DeviceManagerLib/DeviceManager.h
 create mode 100644 MdeModulePkg/Library/DeviceManagerLib/DeviceManagerLib.inf
 create mode 100644 
MdeModulePkg/Library/DeviceManagerLib/DeviceManagerStrings.uni
 create mode 100644 MdeModulePkg/Library/DeviceManagerLib/DeviceManagerVfr.Vfr

diff --git a/MdeModulePkg/Library/DeviceManagerLib/DeviceManager.c 
b/MdeModulePkg/Library/DeviceManagerLib/DeviceManager.c
new file mode 100644
index 000..6edf529
--- /dev/null
+++ b/MdeModulePkg/Library/DeviceManagerLib/DeviceManager.c
@@ -0,0 +1,953 @@
+/** @file
+The device manager reference implementation
+
+Copyright (c) 2004 - 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
+which accompanies this distribution.  The full text of the license may be 
found at
+http://opensource.org/licenses/bsd-license.php
+
+THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#include "DeviceManager.h"
+
+EFI_EVENT  mDmEvent;
+DEVICE_MANAGER_CALLBACK_DATA  gDeviceManagerPrivate = {
+  DEVICE_MANAGER_CALLBACK_DATA_SIGNATURE,
+  NULL,
+  NULL,
+  {
+DeviceManagerExtractConfig,
+DeviceManagerRouteConfig,
+DeviceManagerCallback
+  }
+};
+
+#define  MAX_MAC_ADDRESS_NODE_LIST_LEN10
+
+EFI_GUID mDeviceManagerGuid = DEVICE_MANAGER_FORMSET_GUID;
+
+//
+// Which Mac Address string is select
+// it will decide what menu need to show in the NETWORK_DEVICE_FORM_ID form.
+//
+EFI_STRING  mSelectedMacAddrString;
+
+//
+// The Mac Address show in the NETWORK_DEVICE_LIST_FORM_ID
+//
+MAC_ADDRESS_NODE_LIST  mMacDeviceList;
+
+HII_VENDOR_DEVICE_PATH  mDeviceManagerHiiVendorDevicePath = {
+  {
+{
+  HARDWARE_DEVICE_PATH,
+  HW_VENDOR_DP,
+  {
+(UINT8) (sizeof (VENDOR_DEVICE_PATH)),
+(UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8)
+  }
+},
+//
+// {102579A0-3686-466e-ACD8-80C087044F4A}
+//
+{ 0x102579a0, 0x3686, 0x466e, { 0xac, 0xd8, 0x80, 0xc0, 0x87, 0x4, 0x4f, 
0x4a } }
+  },
+  {
+END_DEVICE_PATH_TYPE,
+END_ENTIRE_DEVICE_PATH_SUBTYPE,
+{ 
+  (UINT8) (END_DEVICE_PATH_LENGTH),
+  (UINT8) ((END_DEVICE_PATH_LENGTH) >> 8)
+}
+  }
+};
+
+/**
+  Extract device path for given HII handle and class guid.
+
+  @param Handle  The HII handle.
+
+  @retval  NULL  Fail to get the device path string.
+  @return  PathStringGet the device path string.
+
+**/
+CHAR16 *
+DmExtractDevicePathFromHiiHandle (
+  IN  EFI_HII_HANDLE  Handle
+  )
+{
+  EFI_STATUS   Status;
+  EFI_HANDLE   DriverHandle;
+
+  ASSERT (Handle != NULL);
+
+  if (Handle == NULL) {
+return NULL;
+  }
+
+  Status = gHiiDatabase->GetPackageListHandle (gHiiDatabase, Handle, 
);
+  if (EFI_ERROR (Status)) {
+return NULL;
+  }
+  //
+  // Get device path string.
+  //
+  return ConvertDevicePathToText(DevicePathFromHandle (DriverHandle), FALSE, 
FALSE);
+}
+
+/**
+  Get the mac address string from the device path.
+  if the device path has the vlan, get the vanid also.
+  
+  @param MacAddressNode  Device path begin with mac address 
+  @param PBuffer Output string buffer contain mac address.
+
+**/
+BOOLEAN 
+GetMacAddressString(
+  IN  MAC_ADDR_DEVICE_PATH   *MacAddressNode,
+  OUT CHAR16 **PBuffer
+  )
+{
+  UINTN HwAddressSize;
+  UINTN Index;
+  UINT8 *HwAddress;
+  EFI_DEVICE_PATH_PROTOCOL  *Node;
+  UINT16VlanId;
+  CHAR16*String;
+  UINTN BufferLen;
+
+  VlanId = 0;
+  String = NULL;
+  ASSERT(MacAddressNode != NULL);
+
+  HwAddressSize = sizeof (EFI_MAC_ADDRESS);
+  if (MacAddressNode->IfType == 0x01 || MacAddressNode->IfType == 0x00) {
+HwAddressSize = 6;
+  }
+
+  //
+  // The output format is MAC:XX:XX:XX:...\
+  // The size is the Number size + ":" size + Vlan size(\) + End
+  //
+  BufferLen = (4 + 2 * HwAddressSize + (HwAddressSize - 1) + 5 + 1) * sizeof 
(CHAR16);
+  String = AllocateZeroPool (BufferLen);
+  if (String == NULL) {
+

[edk2] [patch 1/7] MdeModulePkg:Create Boot Manager Library

[Dandan Bi]

Split the boot manager library from UiApp in MdeModulePkg/Application
and put the library in MdeModulePkg/Library.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 MdeModulePkg/Library/BootManagerLib/BootManager.c  | 820 +
 MdeModulePkg/Library/BootManagerLib/BootManager.h  | 171 +
 .../Library/BootManagerLib/BootManagerLib.inf  |  68 ++
 .../Library/BootManagerLib/BootManagerStrings.uni  | Bin 0 -> 3880 bytes
 .../Library/BootManagerLib/BootManagerVfr.Vfr  |  48 ++
 5 files changed, 1107 insertions(+)
 create mode 100644 MdeModulePkg/Library/BootManagerLib/BootManager.c
 create mode 100644 MdeModulePkg/Library/BootManagerLib/BootManager.h
 create mode 100644 MdeModulePkg/Library/BootManagerLib/BootManagerLib.inf
 create mode 100644 MdeModulePkg/Library/BootManagerLib/BootManagerStrings.uni
 create mode 100644 MdeModulePkg/Library/BootManagerLib/BootManagerVfr.Vfr

diff --git a/MdeModulePkg/Library/BootManagerLib/BootManager.c 
b/MdeModulePkg/Library/BootManagerLib/BootManager.c
new file mode 100644
index 000..875f6c3
--- /dev/null
+++ b/MdeModulePkg/Library/BootManagerLib/BootManager.c
@@ -0,0 +1,820 @@
+/** @file
+  The boot manager reference implementation
+
+  Copyright (c) 2004 - 2015, Intel Corporation. All rights reserved.
+  This software and associated documentation (if any) is furnished
+  under a license and may only be used or copied in accordance
+  with the terms of the license. Except as permitted by such
+  license, no part of this software or documentation may be
+  reproduced, stored in a retrieval system, or transmitted in any
+  form or by any means without the express written consent of
+  Intel Corporation.
+
+**/
+
+#include "BootManager.h"
+
+EFI_EVENT  mBmEvent;
+UINT16 mKeyInput;
+EFI_GUID   mBootManagerGuid = BOOT_MANAGER_FORMSET_GUID;
+//
+// Boot video resolution and text mode.
+//
+UINT32mBmBootHorizontalResolution= 0;
+UINT32mBmBootVerticalResolution  = 0;
+UINT32mBmBootTextModeColumn  = 0;
+UINT32mBmBootTextModeRow = 0;
+//
+// BIOS setup video resolution and text mode.
+//
+UINT32mBmSetupTextModeColumn = 0;
+UINT32mBmSetupTextModeRow= 0;
+UINT32mBmSetupHorizontalResolution   = 0;
+UINT32mBmSetupVerticalResolution = 0;
+
+CHAR16 *mDeviceTypeStr[] = {
+  L"Legacy BEV",
+  L"Legacy Floppy",
+  L"Legacy Hard Drive",
+  L"Legacy CD ROM",
+  L"Legacy PCMCIA",
+  L"Legacy USB",
+  L"Legacy Embedded Network",
+  L"Legacy Unknown Device"
+};
+
+HII_VENDOR_DEVICE_PATH  mBootManagerHiiVendorDevicePath = {
+  {
+{
+  HARDWARE_DEVICE_PATH,
+  HW_VENDOR_DP,
+  {
+(UINT8) (sizeof (VENDOR_DEVICE_PATH)),
+(UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8)
+  }
+},
+//
+// {1DDDBE15-481D-4d2b-8277-B191EAF66525}
+//
+{ 0x1dddbe15, 0x481d, 0x4d2b, { 0x82, 0x77, 0xb1, 0x91, 0xea, 0xf6, 0x65, 
0x25 } }
+  },
+  {
+END_DEVICE_PATH_TYPE,
+END_ENTIRE_DEVICE_PATH_SUBTYPE,
+{ 
+  (UINT8) (END_DEVICE_PATH_LENGTH),
+  (UINT8) ((END_DEVICE_PATH_LENGTH) >> 8)
+}
+  }
+};
+
+BOOT_MANAGER_CALLBACK_DATA  gBootManagerPrivate = {
+  BOOT_MANAGER_CALLBACK_DATA_SIGNATURE,
+  NULL,
+  NULL,
+  {
+BootManagerExtractConfig,
+BootManagerRouteConfig,
+BootManagerCallback
+  }
+};
+
+/**
+  This function will change video resolution and text mode
+  according to defined setup mode or defined boot mode  
+
+  @param  IsSetupMode   Indicate mode is changed to setup mode or boot mode. 
+
+  @retval  EFI_SUCCESS  Mode is changed successfully.
+  @retval  Others Mode failed to be changed.
+
+**/
+EFI_STATUS
+EFIAPI
+BmBdsSetConsoleMode (
+  BOOLEAN  IsSetupMode
+  )
+{
+  EFI_GRAPHICS_OUTPUT_PROTOCOL  *GraphicsOutput;
+  EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL   *SimpleTextOut;
+  UINTN SizeOfInfo;
+  EFI_GRAPHICS_OUTPUT_MODE_INFORMATION  *Info;
+  UINT32MaxGopMode;
+  UINT32MaxTextMode;
+  UINT32ModeNumber;
+  UINT32NewHorizontalResolution;
+  UINT32NewVerticalResolution;
+  UINT32NewColumns;
+  UINT32NewRows;
+  UINTN HandleCount;
+  EFI_HANDLE*HandleBuffer;
+  EFI_STATUSStatus;
+  UINTN Index;
+  UINTN CurrentColumn;
+  UINTN CurrentRow;  
+
+  MaxGopMode  = 0;
+  MaxTextMode = 0;
+
+  //
+  // Get current video resolution and text mode 
+  //
+  Status = gBS->HandleProtocol (
+  gST->ConsoleOutHandle,
+  ,
+  (VOID**)
+

[edk2] [patch 7/7] Nt32Pk: To support new UiApp.

[Dandan Bi]

Add the new added libraries to the Nt32 platform.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi 
---
 Nt32Pkg/Nt32Pkg.dsc | 4 
 1 file changed, 4 insertions(+)

diff --git a/Nt32Pkg/Nt32Pkg.dsc b/Nt32Pkg/Nt32Pkg.dsc
index 21e1f69..931cb0c 100644
--- a/Nt32Pkg/Nt32Pkg.dsc
+++ b/Nt32Pkg/Nt32Pkg.dsc
@@ -128,10 +128,14 @@
   
DebugPrintErrorLevelLib|MdeModulePkg/Library/DxeDebugPrintErrorLevelLib/DxeDebugPrintErrorLevelLib.inf
   
PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf
   DebugAgentLib|MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
   
CpuExceptionHandlerLib|MdeModulePkg/Library/CpuExceptionHandlerLibNull/CpuExceptionHandlerLibNull.inf
   LockBoxLib|MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
+  BootManagerLib|MdeModulePkg/Library/BootManagerLib/BootManagerLib.inf
+  DeviceManagerLib|MdeModulePkg/Library/DeviceManagerLib/DeviceManagerLib.inf
+  
BootMaintenanceManagerLib|MdeModulePkg/Library/BootMaintenanceManagerLib/BootMaintenanceManagerLib.inf
+  FileExplorerLib|MdeModulePkg/Library/FileExplorerLib/FileExplorerLib.inf
   
 !if $(SECURE_BOOT_ENABLE) == TRUE
   PlatformSecureLib|Nt32Pkg/Library/PlatformSecureLib/PlatformSecureLib.inf
   IntrinsicLib|CryptoPkg/Library/IntrinsicLib/IntrinsicLib.inf
   OpensslLib|CryptoPkg/Library/OpensslLib/OpensslLib.inf
-- 
1.9.5.msysgit.1

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

[edk2] [patch 0/7]MdeModulePkg:UiApp remodeling task

[Dandan Bi]

Our current UiApp code is huge and hard to understand and maintain.
So we split it to several independent libraries:device manager,boot manager,
boot maintenance manager.Make the code clear and easy to maintain.

Dandan Bi (7):
  MdeModulePkg:Create Boot Manager Library
  MdeModulePkg:Create Device Manager Library.
  MdeModulePkg:Create Boot Maintenance Manager Library.
  MdeModulePkg:Refine the UiApp
  MdeModulePkg/Include/Guid:Add Guid file
  MdeModulePkg: Modify to support new UiApp.
  Nt32Pk: To support new UiApp.

 MdeModulePkg/Application/UiApp/BootMaint/Bm.vfr|  360 -
 MdeModulePkg/Application/UiApp/BootMaint/BmLib.c   |  369 -
 .../Application/UiApp/BootMaint/Bmstring.uni   |  Bin 42642 -> 0 bytes
 .../Application/UiApp/BootMaint/BootMaint.c| 1383 -
 .../Application/UiApp/BootMaint/BootMaint.h| 1567 
 .../Application/UiApp/BootMaint/BootOption.c   | 1467 --
 .../Application/UiApp/BootMaint/ConsoleOption.c| 1147 --
 MdeModulePkg/Application/UiApp/BootMaint/Data.c|  289 
 MdeModulePkg/Application/UiApp/BootMaint/FE.vfr|  131 --
 .../Application/UiApp/BootMaint/FileExplorer.c |  449 --
 .../Application/UiApp/BootMaint/FormGuid.h |  223 ---
 .../Application/UiApp/BootMaint/UpdatePage.c   | 1245 
 .../Application/UiApp/BootMaint/Variable.c | 1074 --
 .../Application/UiApp/BootMngr/BootManager.c   |  399 -
 .../Application/UiApp/BootMngr/BootManager.h   |  112 --
 .../UiApp/BootMngr/BootManagerStrings.uni  |  Bin 3532 -> 0 bytes
 .../Application/UiApp/BootMngr/BootManagerVfr.Vfr  |   50 -
 .../Application/UiApp/DeviceMngr/DeviceManager.c   |  796 --
 .../Application/UiApp/DeviceMngr/DeviceManager.h   |  155 --
 .../UiApp/DeviceMngr/DeviceManagerStrings.uni  |  Bin 7100 -> 0 bytes
 .../UiApp/DeviceMngr/DeviceManagerVfr.Vfr  |  102 --
 .../UiApp/DeviceMngr/DriverHealthVfr.Vfr   |   45 -
 MdeModulePkg/Application/UiApp/FormsetGuid.h   |   51 -
 MdeModulePkg/Application/UiApp/FrontPage.c |  439 +++---
 MdeModulePkg/Application/UiApp/FrontPage.h |   58 +-
 .../Application/UiApp/FrontPageStrings.uni |  Bin 11202 -> 8930 bytes
 MdeModulePkg/Application/UiApp/FrontPageVfr.Vfr|   55 +-
 MdeModulePkg/Application/UiApp/String.h|   12 -
 MdeModulePkg/Application/UiApp/Strings.uni |  Bin 4716 -> 0 bytes
 MdeModulePkg/Application/UiApp/Ui.h|   47 +-
 MdeModulePkg/Application/UiApp/UiApp.inf   |   82 +-
 MdeModulePkg/Application/UiApp/UiApp.uni   |  Bin 1616 -> 1520 bytes
 MdeModulePkg/Include/Guid/HiiFrontPageFormset.h|   26 +
 MdeModulePkg/Include/Guid/HiiSetupEnter.h  |   26 +
 .../Library/BootMaintenanceManagerLib/BmLib.c  |   89 ++
 .../BootMaintenanceManagerLib/BootMaintenance.c| 1541 +++
 .../BootMaintenanceManager.h   | 1388 +
 .../BootMaintenanceManager.vfr |  441 ++
 .../BootMaintenanceManagerLib.inf  |  100 ++
 .../BootMaintenanceManagerStrings.uni  |  Bin 0 -> 43398 bytes
 .../Library/BootMaintenanceManagerLib/BootOption.c |  984 
 .../BootMaintenanceManagerLib/ConsoleOption.c  | 1162 +++
 .../Library/BootMaintenanceManagerLib/Data.c   |  263 
 .../Library/BootMaintenanceManagerLib/FormGuid.h   |  209 +++
 .../Library/BootMaintenanceManagerLib/UpdatePage.c | 1272 
 .../Library/BootMaintenanceManagerLib/Variable.c   | 1051 +
 MdeModulePkg/Library/BootManagerLib/BootManager.c  |  820 ++
 MdeModulePkg/Library/BootManagerLib/BootManager.h  |  171 +++
 .../Library/BootManagerLib/BootManagerLib.inf  |   68 +
 .../Library/BootManagerLib/BootManagerStrings.uni  |  Bin 0 -> 3880 bytes
 .../Library/BootManagerLib/BootManagerVfr.Vfr  |   48 +
 .../Library/DeviceManagerLib/DeviceManager.c   |  953 
 .../Library/DeviceManagerLib/DeviceManager.h   |  195 +++
 .../Library/DeviceManagerLib/DeviceManagerLib.inf  |   58 +
 .../DeviceManagerLib/DeviceManagerStrings.uni  |  Bin 0 -> 7804 bytes
 .../Library/DeviceManagerLib/DeviceManagerVfr.Vfr  |   67 +
 MdeModulePkg/MdeModulePkg.dec  |6 +
 MdeModulePkg/MdeModulePkg.dsc  |4 +
 Nt32Pkg/Nt32Pkg.dsc|4 +
 59 files changed, 11149 insertions(+), 11904 deletions(-)
 delete mode 100644 MdeModulePkg/Application/UiApp/BootMaint/Bm.vfr
 delete mode 100644 MdeModulePkg/Application/UiApp/BootMaint/BmLib.c
 delete mode 100644 MdeModulePkg/Application/UiApp/BootMaint/Bmstring.uni
 delete mode 100644 MdeModulePkg/Application/UiApp/BootMaint/BootMaint.c
 delete mode 100644 MdeModulePkg/Application/UiApp/BootMaint/BootMaint.h
 delete mode 100644