[edk2] [PATCH] SecurityPkg/OpalPassword: Update strings on Opal Setup page

2019-02-12 Thread Maggie Chu
https://bugzilla.tianocore.org/show_bug.cgi?id=1506
Updated some descriptions on SETUP page to avoid user confusion.
Currently it shows "1.0 UEFI Opal Driver", however it may be mislead user to 
think
it is only for Opal drive but not for Pyrite drive.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Maggie Chu 
Cc: Chao Zhang 
Cc: Jiewen Yao 
Cc: Eric Dong 
---
 SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c  | 10 --
 SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.h  | 11 ---
 SecurityPkg/Tcg/Opal/OpalPassword/OpalHiiCallbacks.c | 16 +---
 SecurityPkg/Tcg/Opal/OpalPassword/OpalHiiFormStrings.uni | 11 ++-
 SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordForm.vfr   |  4 ++--
 5 files changed, 9 insertions(+), 43 deletions(-)

diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c 
b/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c
index 4336604d0d..51aa93c2fd 100644
--- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c
+++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.c
@@ -393,7 +393,6 @@ OpalHiiAddPackages(
   )
 {
   EFI_HANDLE   DriverHandle;
-  CHAR16   *NewString;
 
   DriverHandle = HiiGetDriverImageHandleCB();
 
@@ -416,15 +415,6 @@ OpalHiiAddPackages(
 return EFI_OUT_OF_RESOURCES;
   }
 
-  //
-  // Update Version String in main window
-  //
-  NewString = HiiGetDriverNameCB ();
-  if (HiiSetString(gHiiPackageListHandle, STRING_TOKEN(STR_MAIN_OPAL_VERSION), 
NewString, NULL) == 0) {
-DEBUG ((DEBUG_INFO,  "OpalHiiAddPackages: HiiSetString( ) failed\n"));
-return EFI_OUT_OF_RESOURCES;
-  }
-
   return EFI_SUCCESS;
 }
 
diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.h 
b/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.h
index 8b368fe995..e137a55810 100644
--- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.h
+++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalHii.h
@@ -285,17 +285,6 @@ OpalHiiAddPackages(
   VOID
   );
 
-/**
-  Returns the driver name.
-
-  @retval Returns the driver name.
-
-**/
-CHAR16*
-HiiGetDriverNameCB(
-  VOID
-  );
-
 /**
   Returns the opaque pointer to a physical disk context.
 
diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalHiiCallbacks.c 
b/SecurityPkg/Tcg/Opal/OpalPassword/OpalHiiCallbacks.c
index 31e1aa2240..1b6f067076 100644
--- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalHiiCallbacks.c
+++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalHiiCallbacks.c
@@ -115,18 +115,4 @@ HiiDiskGetNameCB(
 return Ctx->NameZ;
   }
   return NULL;
-}
-
-/**
-  Returns the driver name.
-
-  @retval Returns the driver name.
-
-**/
-CHAR16*
-HiiGetDriverNameCB(
-  VOID
-  )
-{
-  return (CHAR16*)EFI_DRIVER_NAME_UNICODE;
-}
+}
\ No newline at end of file
diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalHiiFormStrings.uni 
b/SecurityPkg/Tcg/Opal/OpalPassword/OpalHiiFormStrings.uni
index 5f753dfa8c..44cfc80626 100644
--- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalHiiFormStrings.uni
+++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalHiiFormStrings.uni
@@ -20,14 +20,14 @@
 #string STR_NULL#language en-US " "
 
 /   FORM SET   
/
-#string STR_FORM_SET_HELP#language en-US "Manage Opal 
disks"
+#string STR_FORM_SET_HELP#language en-US "Select to 
manage"
 
 /   MULTIPLE FORMS   
/
-#string STR_OPAL #language en-US "Opal"
-#string STR_MAIN_OPAL_VERSION#language en-US "Version 
00.0.0."
+#string STR_OPAL #language en-US "TCG Drive 
Management"
 
 /   MAIN MENU FORM   
/
 #string STR_MAIN_PHY_DISKS_LBL   #language en-US "Physical 
Disks:"
+#string STR_MAIN_OPAL_TITLE_LBL  #language en-US "Allows user 
to choose drive to configure drive security. User can also set storage action 
policy for use of the TCG Block SID authentication feature."
 
 #string STR_MAIN_GOTO_DISK_INFO_0#language en-US " "
 #string STR_MAIN_GOTO_DISK_INFO_1#language en-US " "
@@ -36,13 +36,14 @@
 #string STR_MAIN_GOTO_DISK_INFO_4#language en-US " "
 #string STR_MAIN_GOTO_DISK_INFO_5#language en-US " "
 
-#string STR_MAIN_GOTO_DISK_INFO_HELP #language en-US "Select to 
see Opal disk actions"
+#string STR_MAIN_GOTO_DISK_INFO_HELP #language en-US "Select disk 
to see actions"
 
 #string STR_MAIN_NO_DISKS_PRESENT_LBL#language en-US "No disks 
connected to system"
 #string STR_MAIN_NO_DISKS_PRESENT_LBL_HELP   #language en-US "The storage 
needs to be connected before EndOfDxe"
 
 /   DISK INFO MENU FORM   
/
 #string STR_DISK_INFO_SELECTED_DISK_NAME #language en-US " "
+#string 

[edk2] [PATCH 3/3] MdeModulePkg/SmmS3SaveStateDxe: Change function parameter types

2019-02-12 Thread Shenglei Zhang
Change parameter Opcode from UINT16 to UINTN in
BootScriptWrite and BootScriptInsert.
https://bugzilla.tianocore.org/show_bug.cgi?id=1517

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 .../Universal/Acpi/SmmS3SaveState/InternalSmmSaveState.h  | 4 ++--
 MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Universal/Acpi/SmmS3SaveState/InternalSmmSaveState.h 
b/MdeModulePkg/Universal/Acpi/SmmS3SaveState/InternalSmmSaveState.h
index 51cf9db4aa..440f43defe 100644
--- a/MdeModulePkg/Universal/Acpi/SmmS3SaveState/InternalSmmSaveState.h
+++ b/MdeModulePkg/Universal/Acpi/SmmS3SaveState/InternalSmmSaveState.h
@@ -58,7 +58,7 @@ EFI_STATUS
 EFIAPI
 BootScriptWrite (
   IN CONST EFI_S3_SAVE_STATE_PROTOCOL  *This,
-  IN   UINT16   OpCode,
+  IN   UINTNOpCode,
   ...
   );
 /**
@@ -95,7 +95,7 @@ BootScriptInsert (
   IN CONST EFI_S3_SAVE_STATE_PROTOCOL  *This,
   IN   BOOLEAN  BeforeOrAfter,
   IN OUT   EFI_S3_BOOT_SCRIPT_POSITION *Position OPTIONAL,
-  IN   UINT16   OpCode,
+  IN   UINTNOpCode,
   ...
   );
 /**
diff --git a/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c 
b/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
index c1d29b5d3a..bd43011b79 100644
--- a/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
+++ b/MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c
@@ -540,7 +540,7 @@ EFI_STATUS
 EFIAPI
 BootScriptWrite (
   IN CONST EFI_S3_SAVE_STATE_PROTOCOL *This,
-  IN UINT16OpCode,
+  IN UINTN OpCode,
   ...
   )
 {
@@ -695,7 +695,7 @@ BootScriptInsert (
   IN CONST EFI_S3_SAVE_STATE_PROTOCOL*This,
   IN   BOOLEAN  BeforeOrAfter,
   IN OUT   EFI_S3_BOOT_SCRIPT_POSITION *Position OPTIONAL,
-  IN   UINT16   OpCode,
+  IN   UINTNOpCode,
   ...
   )
 {
-- 
2.18.0.windows.1

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


[edk2] [PATCH 2/3] MdeModulePkg/S3SaveStateDxe: Change function parameter types

2019-02-12 Thread Shenglei Zhang
Change parameter Opcode from UINT16 to UINTN in
BootScriptWrite and BootScriptInsert.
https://bugzilla.tianocore.org/show_bug.cgi?id=1517

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 .../Universal/Acpi/S3SaveStateDxe/InternalS3SaveState.h   | 4 ++--
 MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c  | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/InternalS3SaveState.h 
b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/InternalS3SaveState.h
index 19600085f1..b710919881 100644
--- a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/InternalS3SaveState.h
+++ b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/InternalS3SaveState.h
@@ -75,7 +75,7 @@ EFI_STATUS
 EFIAPI
 BootScriptWrite (
   IN CONST EFI_S3_SAVE_STATE_PROTOCOL  *This,
-  IN   UINT16   OpCode,
+  IN   UINTNOpCode,
   ...
   );
 /**
@@ -112,7 +112,7 @@ BootScriptInsert (
   IN CONST EFI_S3_SAVE_STATE_PROTOCOL*This,
   IN   BOOLEAN  BeforeOrAfter,
   IN OUT   EFI_S3_BOOT_SCRIPT_POSITION *Position OPTIONAL,
-  IN   UINT16   OpCode,
+  IN   UINTNOpCode,
   ...
   );
 /**
diff --git a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c 
b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
index 274f3be12c..5913078d69 100644
--- a/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
+++ b/MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c
@@ -542,7 +542,7 @@ EFI_STATUS
 EFIAPI
 BootScriptWrite (
   IN CONST EFI_S3_SAVE_STATE_PROTOCOL  *This,
-  IN   UINT16   OpCode,
+  IN   UINTNOpCode,
   ...
   )
 {
@@ -697,7 +697,7 @@ BootScriptInsert (
   IN CONST EFI_S3_SAVE_STATE_PROTOCOL *This,
   IN   BOOLEANBeforeOrAfter,
   IN OUT   EFI_S3_BOOT_SCRIPT_POSITION*Position OPTIONAL,
-  IN   UINT16 OpCode,
+  IN   UINTN  OpCode,
   ...
   )
 {
-- 
2.18.0.windows.1

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


[edk2] [PATCH 1/3] MdePkg: Change structure parameter types

2019-02-12 Thread Shenglei Zhang
Change parameter Opcode from UINT16 to UINTN
in EFI_S3_SAVE_STATE_WRITE and EFI_S3_SAVE_STATE_INSERT.
https://bugzilla.tianocore.org/show_bug.cgi?id=1517

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 MdePkg/Include/Protocol/S3SaveState.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Include/Protocol/S3SaveState.h 
b/MdePkg/Include/Protocol/S3SaveState.h
index 9e7b4050f6..1563527148 100644
--- a/MdePkg/Include/Protocol/S3SaveState.h
+++ b/MdePkg/Include/Protocol/S3SaveState.h
@@ -52,7 +52,7 @@ typedef
 EFI_STATUS
 (EFIAPI *EFI_S3_SAVE_STATE_WRITE)(
IN CONST EFI_S3_SAVE_STATE_PROTOCOL  *This,
-   IN   UINT16  OpCode,
+   IN   UINTN   OpCode,
...
 );
 
@@ -98,7 +98,7 @@ EFI_STATUS
IN CONST EFI_S3_SAVE_STATE_PROTOCOL  *This,
IN   BOOLEAN BeforeOrAfter,
IN OUT   EFI_S3_BOOT_SCRIPT_POSITION *Position   OPTIONAL,
-   IN   UINT16  OpCode,
+   IN   UINTN   OpCode,
...
 );
 
-- 
2.18.0.windows.1

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


[edk2] [PATCH 0/3] Change parameters' type in MdePkg and MdeModulePkg

2019-02-12 Thread Shenglei Zhang
Change parameters' type according to the new spec PI 1.7.
https://bugzilla.tianocore.org/show_bug.cgi?id=1517

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Shenglei Zhang (3):
  MdePkg: Change structure parameter types
  MdeModulePkg/S3SaveStateDxe: Change function parameter types
  MdeModulePkg/SmmS3SaveStateDxe: Change function parameter types

 .../Universal/Acpi/S3SaveStateDxe/InternalS3SaveState.h   | 4 ++--
 MdeModulePkg/Universal/Acpi/S3SaveStateDxe/S3SaveState.c  | 4 ++--
 .../Universal/Acpi/SmmS3SaveState/InternalSmmSaveState.h  | 4 ++--
 MdeModulePkg/Universal/Acpi/SmmS3SaveState/SmmS3SaveState.c   | 4 ++--
 MdePkg/Include/Protocol/S3SaveState.h | 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)

-- 
2.18.0.windows.1

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


Re: [edk2] [PATCH v2 0/3] MdeModulePkg/PciBus: Fix a bug PPB MEM32 BAR isn't restored sometimes

2019-02-12 Thread Wu, Hao A
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ray Ni
> Sent: Tuesday, February 12, 2019 5:48 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [PATCH v2 0/3] MdeModulePkg/PciBus: Fix a bug PPB MEM32
> BAR isn't restored sometimes
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1505
> 
> v2: fixed all typos in PciBus driver.
> changed RomSize to UINT32 and added type cast to PPB MEM32 BAR
> Base/Length to avoid using RShiftU64().

For the series:
Reviewed-by: Hao Wu 

Best Regards,
Hao Wu

> 
> 
> Ray Ni (3):
>   MdeModulePkg/PciBus: Change PCI_IO_DEVICE.RomSize to UINT32 type
>   MdeModulePkg/PciBus: Correct typos
>   MdeModulePkg/PciBus: Fix a bug PPB MEM32 BAR isn't restored
> sometimes
> 
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h   |   4 +-
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c   |  14 +--
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.h   |  16 +--
>  .../Bus/Pci/PciBusDxe/PciDeviceSupport.c  |  20 ++--
>  .../Bus/Pci/PciBusDxe/PciDeviceSupport.h  |  14 +--
>  .../Bus/Pci/PciBusDxe/PciDriverOverride.c |   4 +-
>  .../Bus/Pci/PciBusDxe/PciDriverOverride.h |   4 +-
>  .../Bus/Pci/PciBusDxe/PciEnumerator.c |   8 +-
>  .../Bus/Pci/PciBusDxe/PciEnumerator.h |   8 +-
>  .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.c  |  42 +++
>  .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.h  |  16 +--
>  .../Bus/Pci/PciBusDxe/PciHotPlugSupport.c |  16 +--
>  .../Bus/Pci/PciBusDxe/PciHotPlugSupport.h |  18 +--
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c|  16 +--
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.h|   4 +-
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c   |   4 +-
>  .../Bus/Pci/PciBusDxe/PciOptionRomSupport.c   |   6 +-
>  .../Bus/Pci/PciBusDxe/PciOptionRomSupport.h   |   4 +-
>  .../Bus/Pci/PciBusDxe/PciPowerManagement.c|   4 +-
>  .../Bus/Pci/PciBusDxe/PciPowerManagement.h|   4 +-
>  .../Bus/Pci/PciBusDxe/PciResourceSupport.c| 113 +-
>  .../Bus/Pci/PciBusDxe/PciResourceSupport.h|  41 ---
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciRomTable.h  |   7 +-
>  23 files changed, 190 insertions(+), 197 deletions(-)
> 
> --
> 2.20.1.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms v1 01/16] Hisilicon/D0x: Remove SerdesLib

2019-02-12 Thread Ming Huang



On 2/11/2019 11:05 PM, Leif Lindholm wrote:
> On Fri, Feb 01, 2019 at 09:34:21PM +0800, Ming Huang wrote:
>> SerdesLib is useless for SmbiosMiscDxe and D06, so remove it.
> 
> Should it not then also delete #include  from
> Platform/Hisilicon/D06/Library/OemMiscLibD06/BoardFeatureD06.c,
> Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c and
> Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/Type09/MiscSystemSlotDesignationFunction.c
> ?
> 
> Meanwhile,
> Platform/Hisilicon/D03/Library/OemMiscLib2P/BoardFeature2PHi1610.c
> and
> Platform/Hisilicon/D05/Library/OemMiscLibD05/BoardFeatureD05.c
> both include this header, but
> Platform/Hisilicon/D03/Library/OemMiscLib2P/OemMiscLib2PHi1610.inf
> and 
> Platform/Hisilicon/D05/Library/OemMiscLibD05/OemMiscLibD05.inf
> do not declare the dependency.

OemMiscLibD06.c can remove the SerdesLib.h. As using the definitions in
SerdesLib.h, other .c files can not remove the header file.

> 
> Can you investigate and submit an updated patch addressing all of the
> unnecessary references?

This may takes a lot of time, as Hi1620(D06) is our important project,
maybe we should focus on D06.

Thanks

> 
> Best Regards,
> 
> Leif
> 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> ---
>>  Platform/Hisilicon/D06/D06.dsc   | 2 --
>>  Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf | 1 -
>>  2 files changed, 3 deletions(-)
>>
>> diff --git a/Platform/Hisilicon/D06/D06.dsc b/Platform/Hisilicon/D06/D06.dsc
>> index 396bd03c9d24..cbbd99e4a659 100644
>> --- a/Platform/Hisilicon/D06/D06.dsc
>> +++ b/Platform/Hisilicon/D06/D06.dsc
>> @@ -64,8 +64,6 @@ [LibraryClasses.common]
>>  
>>CpldIoLib|Silicon/Hisilicon/Library/CpldIoLib/CpldIoLib.inf
>>  
>> -  
>> SerdesLib|Silicon/Hisilicon/Hi1620/Library/Hi1620Serdes/Hi1620SerdesLib.inf
>> -
>>TimeBaseLib|EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.inf
>>
>> RealTimeClockLib|Silicon/Hisilicon/Library/M41T83RealTimeClockLib/M41T83RealTimeClockLib.inf
>>OemMiscLib|Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.inf
>> diff --git 
>> a/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf 
>> b/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
>> index 61cead7779b9..8e5c56fa41fd 100644
>> --- a/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
>> +++ b/Silicon/Hisilicon/Drivers/Smbios/SmbiosMiscDxe/SmbiosMiscDxe.inf
>> @@ -77,7 +77,6 @@ [LibraryClasses]
>>  
>>IpmiCmdLib
>>  
>> -  SerdesLib
>>  
>>  [Protocols]
>>gEfiSmbiosProtocolGuid   # PROTOCOL ALWAYS_CONSUMED
>> -- 
>> 2.9.5
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH 00/14] ArmVirtPkg: clean up set-but-unused PCDs

2019-02-12 Thread Laszlo Ersek
On 02/06/19 13:10, Laszlo Ersek wrote:
> Repo:   https://github.com/lersek/edk2.git
> Branch: armvirt_pcd_clean
> 
> (1) The procedure described below depends on:
> 
> [edk2] [PATCH]
> BaseTools/BuildReport: fix report for platforms/arches without struct PCDs
> 
> 20190205112213.682-1-lersek@redhat.com">http://mid.mail-archive.com/20190205112213.682-1-lersek@redhat.com
> https://lists.01.org/pipermail/edk2-devel/2019-February/036320.html
> 
> (2) Background: while working on the fix in (1), I noticed that the PCD
> sections in the build reports of various ArmVirt platforms contained
> "PCDs not used by modules or in conditional directives". I thought
> that we should attempt to clean those up. Subsequently I built the
> following 36 ArmVirt platforms:
> 
>> extra_opts=("" "-D HTTP_BOOT_ENABLE -D NETWORK_IP6_ENABLE -D 
>> SECURE_BOOT_ENABLE -D TTY_TERMINAL")
>> for arch in ARM AARCH64; do
>>   for platform in Qemu QemuKernel Xen; do
>> for target in NOOPT DEBUG RELEASE; do
>>   for extra in 0 1; do
>> GCC5_ARM_PREFIX=arm-linux-gnu- \
>> GCC5_AARCH64_PREFIX=aarch64-linux-gnu- \
>> build \
>>   -a $arch \
>>   -p ArmVirtPkg/ArmVirt${platform}.dsc \
>>   -t GCC5 \
>>   -b $target \
>>   -n $(getconf _NPROCESSORS_ONLN) \
>>   --report-file=$HOME/tmp/report.$arch.$platform.$target.$extra.txt \
>>   --report-type=PCD \
>>   --cmd-len=65536 \
>>   ${extra_opts[$extra]}
>>   done
>> done
>>   done
>> done
> 
> Then I gradually eliminated the redundant PCD settings.
> 
> (3) At the bottom of this email (i.e., the series cover letter), I'm
> including a base64-encoded tarball of report files, saved (like
> described in (2)) before and after the series. Diffing the reports
> proves that the series cleans up the PCD settings without any
> changes observable to modules.
> 
> (4) The series advances in small steps. The reason is that some of the
> facts exposed could be surprising (I know I was surprised), and we
> could decide that we want to do something else (e.g. file a BZ, and
> fill the gap later). For such cases I wanted to be able to drop
> individual patches at will.
> 
> Cc: Ard Biesheuvel 
> Cc: Julien Grall 
> 
> Thanks,
> Laszlo
> 
> Laszlo Ersek (14):
>   ArmVirtPkg/ArmVirtQemuKernel: don't set PcdCPUCoresStackBase
>   ArmVirtPkg: don't set PcdRelocateVectorTable
>   ArmVirtPkg/{ArmVirtQemu,ArmVirtQemuKernel}: don't set
> PcdTrustzoneSupport
>   ArmVirtPkg: don't set PcdPostCodePropertyMask
>   ArmVirtPkg: clean up PcdSetNxForStack setting (applies to ArmVirtQemu
> only)
>   ArmVirtPkg/PrePi: drop wrong PcdCoreCount dependency
>   ArmVirtPkg: don't set PcdCoreCount
>   ArmVirtPkg: don't set PcdDebugClearMemoryValue
>   ArmVirtPkg: don't set PcdDebugPrintErrorLevel in RELEASE builds
>   ArmVirtPkg/ArmVirtXen: don't set PcdPL031RtcBase
>   ArmVirtPkg/ArmVirtXen: don't set PcdTerminalTypeGuidBuffer
>   ArmVirtPkg/ArmVirtXen: don't set PcdShellFile
>   ArmVirtPkg/ArmVirtXen: don't set PcdTurnOffUsbLegacySupport
>   ArmVirtPkg/ArmVirtXen: don't set Pcd*ImageVerificationPolicy
> 
>  ArmVirtPkg/ArmVirt.dsc.inc  | 27 ++--
>  ArmVirtPkg/ArmVirtQemu.dsc  | 21 ---
>  ArmVirtPkg/ArmVirtQemuKernel.dsc| 17 
>  ArmVirtPkg/ArmVirtXen.dsc   |  9 ---
>  ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf |  2 --
>  5 files changed, 31 insertions(+), 45 deletions(-)

series pushed as 63d8431a49cb..da06a2a2fa1e

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


Re: [edk2] [PATCH edk2-platforms v1 03/16] Hisilicon/D06: Optimize SAS driver for reducing boot time

2019-02-12 Thread Ming Huang



On 2/12/2019 11:12 PM, Leif Lindholm wrote:
> On Fri, Feb 01, 2019 at 09:34:23PM +0800, Ming Huang wrote:
>> SAS controller is always existed, so accessing SAS register don't
>> depend on PciBusDxe (pci enumeration).
>> Move the SAS module early in D06.fdf for dispatching SAS driver
>> early. This can avoid wait in BDS normally and reduce boot time.
>>
>> This patch is relative with SasDriverDxe in edk2-non-osi.
> 
> I think you are saying that this change is only valid after the
> update to SasDriverDxe in edk2-non-osi has been applied?
> Or does it mean that it only improves performance after that
> edk2-non-osi patch has been applied?

This change is only valid after the update to SasDriverDxe in
edk2-non-osi has been applied.

Thanks

> 
> Please be more explicit in the commit message.
> 
> Other than that. I'm OK with this patch.
> 
> /
> Leif
> 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> ---
>>  Platform/Hisilicon/D06/D06.fdf | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Platform/Hisilicon/D06/D06.fdf b/Platform/Hisilicon/D06/D06.fdf
>> index a937660a09e2..d495ad7f264c 100644
>> --- a/Platform/Hisilicon/D06/D06.fdf
>> +++ b/Platform/Hisilicon/D06/D06.fdf
>> @@ -165,6 +165,7 @@ [FV.FvMain]
>>INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
>>  
>>INF Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.inf
>> +  INF Platform/Hisilicon/D06/Drivers/Sas/SasDxeDriver.inf
>>#
>># PI DXE Drivers producing Architectural Protocols (EFI Services)
>>#
>> @@ -296,7 +297,6 @@ [FV.FvMain]
>>#
>>INF Platform/Hisilicon/D06/Drivers/Sm750Dxe/UefiSmi.inf
>>INF MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
>> -  INF Platform/Hisilicon/D06/Drivers/Sas/SasDxeDriver.inf
>>INF MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
>>INF MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
>>INF MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
>> -- 
>> 2.9.5
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] OVMF and TCP4, HTTP protocols

2019-02-12 Thread Laszlo Ersek
On 02/13/19 05:28, Rebecca Cran wrote:
> On February 6, 2019 at 4:08:03 PM, Rebecca Cran via edk2-devel
> (edk2-devel@lists.01.org ) wrote:
>>
>> Oh, that makes sense! Thanks, after disabling the existing code that was 
>> opening SNP exclusively, things started working much better. 
> 
> 
> I have a follow-up question. After opening the EFI_SIMPLE_NETWORK
> protocol exclusively, should code be able to later call
> gBS->CloseProtocol on the handle and subsequently start using TCP/HTTP? 
> 
> From what I’ve seen, closing the protocol (I’m also calling
> net->Shutdown(), and the CloseProtocol succeeds) has no effect and the
> TCP and HTTP protocols still can’t be found/used.

Sure, that's expected.

Just because an agent releases a reference to a protocol interface, no
other agent is expected to automatically bind the interface. In order to
get back from SNP to the HTTP SB, you have to re-connect the related
drivers (recursively).

"Recursive" has dual meaning here. First, it means that, given a
specific handle, and a protocol interface on that handle, another driver
-- a device driver -- can consume the protocol interace, and install
another protocol interface on the *same* handle.

The other meaning of "recursive" is that a *bus* driver may produce a
number of direct child handles (with appropriate device paths on them)
for the original handle, and install the suitable protocol interface(s)
on those child handles. In turn another driver will bind the protocol
interfaces on the child handles.

Thus "recursion" may occur on two axes -- one axis is the protocol stack
on a given, single, handle; the other axis is the hierarchy of child
handles (reflected by device paths). In the ConnectController() boot
service, the first axis is covered automatically (it is not optional).
The second axis is controlled by the "Recursive" parameter.

In your case, I think it should suffice to call ConnectController() with
Recursive=FALSE, on the controller that already has SNP. The
HttpServiceBinding, Tcp6ServiceBinding and TCPv4ServiceBinding protocols
seem to be installed on the same handle. (The device path on this handle
ends with the MAC() node.)

Once the HttpServiceBinding protocol instance exists, UEFI 2.7 "29.6.2.1
Usage Examples" provides a code example for a HTTP file download,
including IPv4 address configuration with DHCP.

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


Re: [edk2] [PATCH edk2-platforms v1 15/16] Hisilicon/D06: Use CalculateCrc16 in BaseLib

2019-02-12 Thread Ming Huang



On 2/12/2019 4:52 AM, Leif Lindholm wrote:
> On Fri, Feb 01, 2019 at 10:29:06PM +0800, Ming Huang wrote:
>> This patch is relative with "Add new API CalculateCrc16()" in edk2.
> 
> The commit message should describe what the patch does.
> I don't mind keeping the above line in, but we also need the
> description.
> 
> Obviously, this patch depends on the corresponding one going into
> edk2, which is has not yet.

As edk2 patch is has not yet, I will drop this patch.

Thanks

> 
> /
> Leif
> 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> ---
>>  Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c | 69 
>> ++--
>>  1 file changed, 5 insertions(+), 64 deletions(-)
>>
>> diff --git a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c 
>> b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
>> index 9bf274e1b991..3ba4f305fb8e 100644
>> --- a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
>> +++ b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
>> @@ -14,6 +14,7 @@
>>  **/
>>  
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -56,66 +57,6 @@ ETH_PRODUCT_DESC gEthPdtDesc[ETH_MAX_PORT] =
>>  {FALSE,  ETH_INVALID, ETH_INVALID, ETH_INVALID, ETH_INVALID}
>>  };
>>  
>> -UINT16 CrcTable16[256] = {
>> -  0x, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7,
>> -  0x8108, 0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF,
>> -  0x1231, 0x0210, 0x3273, 0x2252, 0x52B5, 0x4294, 0x72F7, 0x62D6,
>> -  0x9339, 0x8318, 0xB37B, 0xA35A, 0xD3BD, 0xC39C, 0xF3FF, 0xE3DE,
>> -  0x2462, 0x3443, 0x0420, 0x1401, 0x64E6, 0x74C7, 0x44A4, 0x5485,
>> -  0xA56A, 0xB54B, 0x8528, 0x9509, 0xE5EE, 0xF5CF, 0xC5AC, 0xD58D,
>> -  0x3653, 0x2672, 0x1611, 0x0630, 0x76D7, 0x66F6, 0x5695, 0x46B4,
>> -  0xB75B, 0xA77A, 0x9719, 0x8738, 0xF7DF, 0xE7FE, 0xD79D, 0xC7BC,
>> -  0x48C4, 0x58E5, 0x6886, 0x78A7, 0x0840, 0x1861, 0x2802, 0x3823,
>> -  0xC9CC, 0xD9ED, 0xE98E, 0xF9AF, 0x8948, 0x9969, 0xA90A, 0xB92B,
>> -  0x5AF5, 0x4AD4, 0x7AB7, 0x6A96, 0x1A71, 0x0A50, 0x3A33, 0x2A12,
>> -  0xDBFD, 0xCBDC, 0xFBBF, 0xEB9E, 0x9B79, 0x8B58, 0xBB3B, 0xAB1A,
>> -  0x6CA6, 0x7C87, 0x4CE4, 0x5CC5, 0x2C22, 0x3C03, 0x0C60, 0x1C41,
>> -  0xEDAE, 0xFD8F, 0xCDEC, 0xDDCD, 0xAD2A, 0xBD0B, 0x8D68, 0x9D49,
>> -  0x7E97, 0x6EB6, 0x5ED5, 0x4EF4, 0x3E13, 0x2E32, 0x1E51, 0x0E70,
>> -  0xFF9F, 0xEFBE, 0xDFDD, 0xCFFC, 0xBF1B, 0xAF3A, 0x9F59, 0x8F78,
>> -  0x9188, 0x81A9, 0xB1CA, 0xA1EB, 0xD10C, 0xC12D, 0xF14E, 0xE16F,
>> -  0x1080, 0x00A1, 0x30C2, 0x20E3, 0x5004, 0x4025, 0x7046, 0x6067,
>> -  0x83B9, 0x9398, 0xA3FB, 0xB3DA, 0xC33D, 0xD31C, 0xE37F, 0xF35E,
>> -  0x02B1, 0x1290, 0x22F3, 0x32D2, 0x4235, 0x5214, 0x6277, 0x7256,
>> -  0xB5EA, 0xA5CB, 0x95A8, 0x8589, 0xF56E, 0xE54F, 0xD52C, 0xC50D,
>> -  0x34E2, 0x24C3, 0x14A0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
>> -  0xA7DB, 0xB7FA, 0x8799, 0x97B8, 0xE75F, 0xF77E, 0xC71D, 0xD73C,
>> -  0x26D3, 0x36F2, 0x0691, 0x16B0, 0x6657, 0x7676, 0x4615, 0x5634,
>> -  0xD94C, 0xC96D, 0xF90E, 0xE92F, 0x99C8, 0x89E9, 0xB98A, 0xA9AB,
>> -  0x5844, 0x4865, 0x7806, 0x6827, 0x18C0, 0x08E1, 0x3882, 0x28A3,
>> -  0xCB7D, 0xDB5C, 0xEB3F, 0xFB1E, 0x8BF9, 0x9BD8, 0xABBB, 0xBB9A,
>> -  0x4A75, 0x5A54, 0x6A37, 0x7A16, 0x0AF1, 0x1AD0, 0x2AB3, 0x3A92,
>> -  0xFD2E, 0xED0F, 0xDD6C, 0xCD4D, 0xBDAA, 0xAD8B, 0x9DE8, 0x8DC9,
>> -  0x7C26, 0x6C07, 0x5C64, 0x4C45, 0x3CA2, 0x2C83, 0x1CE0, 0x0CC1,
>> -  0xEF1F, 0xFF3E, 0xCF5D, 0xDF7C, 0xAF9B, 0xBFBA, 0x8FD9, 0x9FF8,
>> -  0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0,
>> -};
>> -
>> -UINT16 MakeCrcCheckSum (
>> -  UINT8 *Buffer,
>> -  UINT32 Length
>> -  )
>> -{
>> -  UINT16 StartCRC = 0;
>> -
>> -  if (Length > SIZE_512KB) {
>> -return 0;
>> -  }
>> -
>> -  if (Buffer == NULL) {
>> -return 0;
>> -  }
>> -
>> -  while (Length) {
>> -StartCRC = CrcTable16 [((UINT8) ((StartCRC >> 8) & 0xff)) ^ 
>> *(Buffer++)] ^
>> -   ((UINT16) (StartCRC << 8));
>> -Length--;
>> -  }
>> -
>> -  return StartCRC;
>> -}
>> -
>> -
>>  EFI_STATUS
>>  OemGetMacE2prom(
>>IN  UINT32 Port,
>> @@ -170,8 +111,8 @@ OemGetMacE2prom(
>>  return Status;
>>}
>>  
>> -  Crc16 = MakeCrcCheckSum (
>> -(UINT8 *)&(MacDesc.MacLen),
>> +  Crc16 = CalculateCrc16 (
>> +&(MacDesc.MacLen),
>>  sizeof (MacDesc.MacLen) + sizeof (MacDesc.Mac)
>>  );
>>if ((Crc16 != MacDesc.Crc16) || (Crc16 == 0)) {
>> @@ -207,8 +148,8 @@ OemSetMacE2prom (
>>  MacDesc.Mac[I] = Addr[I];
>>}
>>  
>> -  MacDesc.Crc16 = MakeCrcCheckSum (
>> -(UINT8 *)&(MacDesc.MacLen),
>> +  MacDesc.Crc16 = CalculateCrc16 (
>> +&(MacDesc.MacLen),
>>  sizeof (MacDesc.MacLen) + MAC_ADDR_LEN
>>  );
>>  
>> -- 
>> 2.9.5
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms v1 12/16] Hisilicon/D06: Use new flash layout

2019-02-12 Thread Ming Huang



On 2/11/2019 10:54 PM, Leif Lindholm wrote:
> On Fri, Feb 01, 2019 at 09:34:32PM +0800, Ming Huang wrote:
>> In new flash layout, BIOS fd change from offset 1M to 8M in 16M
>> spi flash.
> 
> This bit
> 
>> Use the new CustomData.Fv which indicate the offset
>> of fd and which flash area can be updated for BMC.
> 
> is of critical importance. Should be its own paragraph.
> 
> How does this change affect variable storage? Will the server maintain
> state after a firmware upgrade, or will the operator need to rescue it
> manually via the BMC?

As the address of variable is change, need to update via the BMC for 19.02.

Thanks

> 
> /
> Leif
> 
>>
>> This patch is relative with patch "Use new flash layout" in
>> edk2-non-osi.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> ---
>>  Platform/Hisilicon/D06/D06.fdf | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/Platform/Hisilicon/D06/D06.fdf b/Platform/Hisilicon/D06/D06.fdf
>> index d495ad7f264c..f72b513352fb 100644
>> --- a/Platform/Hisilicon/D06/D06.fdf
>> +++ b/Platform/Hisilicon/D06/D06.fdf
>> @@ -29,7 +29,7 @@ [DEFINES]
>>  
>> 
>>  [FD.D06]
>>  
>> -BaseAddress   = 0x20410|gArmTokenSpaceGuid.PcdFdBaseAddress  # The base 
>> address of the Firmware in NOR Flash.
>> +BaseAddress   = 0x20480|gArmTokenSpaceGuid.PcdFdBaseAddress  # The base 
>> address of the Firmware in NOR Flash.
>>  
>>  Size  = 0x0040|gArmTokenSpaceGuid.PcdFdSize # The size 
>> in bytes of the FLASH Device
>>  ErasePolarity = 1
>> @@ -124,7 +124,7 @@ [FD.D06]
>>  0x003E|0x0001
>>  
>>  0x003F|0x0001
>> -FILE = Platform/Hisilicon/D0x-CustomData.Fv
>> +FILE = Platform/Hisilicon/D06/CustomData.Fv
>>  
>>  
>> 
>>  #
>> -- 
>> 2.9.5
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms v1 10/16] Hisilicon/D06: Modify for M7 self-Adapte support

2019-02-12 Thread Ming Huang



On 2/12/2019 11:46 PM, Leif Lindholm wrote:
> On Tue, Feb 12, 2019 at 11:14:43PM +0800, Ming Huang wrote:
>>
>>
>> On 2/12/2019 3:28 AM, Leif Lindholm wrote:
>>> On Fri, Feb 01, 2019 at 09:34:30PM +0800, Ming Huang wrote:
 As new M7(Cortex-M7) firmware support self-adapte, so do not
 need BIOS to implement some function, remove useless funtions
 and report CPU0/CPU1 Nic NCL offset to M7.
>>>
>>> I don't really care that some other device in the system is a
>>> Cortex-A7. What is its function? Is it an SCP, an MCP, ?
>>> Please describe its function rather than its implementation.
>>
>> M7 is used for HNS(Hisilicon network system), cpu access the network
>> component via M7.
> 
> Sure. But does customer documentation documentation refer to it as
> "M7"?

I check documentation just now, Integrated Management Processor(IMP) is used,
so, I will change commit titil and message M7 to IMP.

> 
>>>
>>> What are the external dependencies?
>>> Is this addressed by one of the patches for edk2-non-osi?
>>
>> This is depend on M7 firmware which will include in hpm file.
> 
> So we don't get it when using Capsule Update?

Yes.

> 
> What would be the implication of installing system firmware with the
> below change on a system that had not had the corresponding M7
> firmware update?

The HNS will not worked.

Thanks

> 
> /
> Leif
> 
>>>
>>> More style issues below.
>>>

 Contributed-under: TianoCore Contribution Agreement 1.1
 Signed-off-by: Ming Huang 
 ---
  Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c | 272 
 
  1 file changed, 45 insertions(+), 227 deletions(-)

 diff --git a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c 
 b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
 index aaf990216982..9bf274e1b991 100644
 --- a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
 +++ b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
 @@ -21,44 +21,21 @@
  #include 
  
  #define CPU2_SFP2_100G_CARD_OFFSET   0x25
 -#define CPU1_SFP1_LOCATE_OFFSET  0x16
 -#define CPU1_SFP0_LOCATE_OFFSET  0x12
 -#define CPU2_SFP1_LOCATE_OFFSET  0x21
 -#define CPU2_SFP0_LOCATE_OFFSET  0x19
 -#define CPU2_SFP2_10G_GE_CARD_OFFSET 0x25
  
 -#define SFP_10G_SPEED   10
 -#define SFP_25G_SPEED   25
 -#define SFP_100G_SPEED  100
 -#define SFP_GE_SPEED1
 -
 -#define SFP_GE_SPEED_VAL_VENDOR_FINISAR 0x0C
 -#define SFP_GE_SPEED_VAL0x0D
 -#define SFP_10G_SPEED_VAL   0x67
 -#define SFP_25G_SPEED_VAL   0xFF
 +#define SOCKET1_NET_PORT_100G 1
 +#define SOCKET0_NET_PORT_NUM  4
 +#define SOCKET1_NET_PORT_NUM  2
  
  #define CARD_PRESENT_100G   (BIT7)
 -#define CARD_PRESENT_10G(BIT0)
 -#define SELECT_SFP_BY_INDEX(index)  (1 << (index - 1))
 -#define SPF_SPEED_OFFSET12
 -
 -#define SFP_DEVICE_ADDRESS 0x50
 -#define CPU1_9545_I2C_ADDR 0x70
 -#define CPU2_9545_I2C_ADDR 0x71
 -
 -#define FIBER_PRESENT 0
 -#define CARD_PRESENT  1
 -#define I2C_PORT_SFP  4
 -#define CPU2_I2C_PORT_SFP 5
 -
 -#define SOCKET_0 0
 -#define SOCKET_1 1
  #define EEPROM_I2C_PORT  4
  #define EEPROM_PAGE_SIZE 0x40
  #define MAC_ADDR_LEN 6
  #define I2C_OFFSET_EEPROM_ETH0   (0xc00)
  #define I2C_SLAVEADDR_EEPROM (0x52)
  
 +#define SRAM_NIC_NCL1_OFFSET_FLAG   0xA0E87FE0
 +#define SRAM_NIC_NCL2_OFFSET_FLAG   0xA0E87FE4
>>>
>>> Is this just a hard-coded address in SRAM? Where is it specified?
>>> I don't think "_FLAG" is the correct name for this #define - this is
>>> the actual offset value. So _OFFSET_ADDRESS would be more descriptive.
>>
>> Yes, M7 firmware will read this two sram addresses.
>>
>>>
 +
  #pragma pack(1)
  typedef struct {
UINT16 Crc16;
 @@ -114,204 +91,6 @@ UINT16 CrcTable16[256] = {
0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0,
  };
  
 -EFI_STATUS
 -GetSfpSpeed (
 -  UINT16 Socket,
 -  UINT16 SfpNum,
 -  UINT8* FiberSpeed
 -  )
 -{
 -  EFI_STATUS  Status;
 -  I2C_DEVICE  SpdDev;
 -  UINT8   SfpSelect;
 -  UINT8   SfpSpeed;
 -  UINT32  RegAddr;
 -  UINT16  I2cAddr;
 -  UINT32  SfpPort;
 -
 -  SfpSpeed = 0x0;
 -  if (Socket == SOCKET_1) {
 -I2cAddr = CPU2_9545_I2C_ADDR;
 -SfpPort = CPU2_I2C_PORT_SFP;
 -  } else {
 -I2cAddr = CPU1_9545_I2C_ADDR;
 -SfpPort = I2C_PORT_SFP;
 -  }
 -
 -  Status = I2CInit (Socket, SfpPort, Normal);
 -  if (EFI_ERROR (Status)) {
 -DEBUG ((DEBUG_ERROR, "[%a]:[%dL] Socket%d Call I2CInit failed! 
 p1=0x%x.\n",
 -__FUNCTION__, 

Re: [edk2] OVMF and TCP4, HTTP protocols

2019-02-12 Thread Rebecca Cran via edk2-devel
On February 6, 2019 at 4:08:03 PM, Rebecca Cran via edk2-devel 
(edk2-devel@lists.01.org) wrote:

Oh, that makes sense! Thanks, after disabling the existing code that was 
opening SNP exclusively, things started working much better. 


I have a follow-up question. After opening the EFI_SIMPLE_NETWORK protocol 
exclusively, should code be able to later call gBS->CloseProtocol on the handle 
and subsequently start using TCP/HTTP? 

From what I’ve seen, closing the protocol (I’m also calling net->Shutdown(), 
and the CloseProtocol succeeds) has no effect and the TCP and HTTP protocols 
still can’t be found/used.



— 

Rebecca Cran

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


[edk2] [Patch edk2 Wiki] Add three features for edk2-stable201903

2019-02-12 Thread Liming Gao
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao 
---
 EDK-II-Release-Planning.md | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/EDK-II-Release-Planning.md b/EDK-II-Release-Planning.md
index f302be3..095da69 100644
--- a/EDK-II-Release-Planning.md
+++ b/EDK-II-Release-Planning.md
@@ -24,7 +24,9 @@
 * [Remove PcdPeiCoreMaxXXX 
PCDs](https://bugzilla.tianocore.org/show_bug.cgi?id=1405)
 * [Remove unused tool logic in BaseTools 
C\Python](https://bugzilla.tianocore.org/show_bug.cgi?id=1350)
 * [BaseTools: Enable component override 
functionality](https://bugzilla.tianocore.org/show_bug.cgi?id=1449)
-* [SMM CET support](https://bugzilla.tianocore.org/show_bug.cgi?id=1521)
+* [Support PI1.7 
EFI_PEI_CORE_FV_LOCATION_PPI](https://bugzilla.tianocore.org/show_bug.cgi?id=1524)
+* [Remove unused tool chain configuration in 
tools_def.template](https://bugzilla.tianocore.org/show_bug.cgi?id=1377)
+* [BaseTools supports to the driver 
combination](https://bugzilla.tianocore.org/show_bug.cgi?id=1520)
 * Standalone MM build of authenticated variable stack (bugzilla link TBD)
 * TBD Bugzilla List
 
-- 
2.13.0.windows.1

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


Re: [edk2] [PATCH 2/3] MdeModulePkg/PeiMain: Support EFI_PEI_CORE_FV_LOCATION_PPI

2019-02-12 Thread Chiu, Chasel


No issue, I will remove UINT32 casting. Thanks!

> -Original Message-
> From: Wang, Jian J
> Sent: Wednesday, February 13, 2019 9:14 AM
> To: Chiu, Chasel ; edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Ni, Ray ; Zeng, Star
> ; Gao, Liming 
> Subject: RE: [PATCH 2/3] MdeModulePkg/PeiMain: Support
> EFI_PEI_CORE_FV_LOCATION_PPI
> 
> Chasel,
> 
> 
> > -Original Message-
> > From: Chiu, Chasel
> > Sent: Tuesday, February 12, 2019 9:20 PM
> > To: edk2-devel@lists.01.org
> > Cc: Wang, Jian J ; Wu, Hao A
> > ; Ni, Ray ; Zeng, Star
> > ; Gao, Liming ; Chiu,
> > Chasel 
> > Subject: [PATCH 2/3] MdeModulePkg/PeiMain: Support
> > EFI_PEI_CORE_FV_LOCATION_PPI
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1524
> >
> > When shadowing PeiCore the EFI_PEI_CORE_FV_LOCATION_PPI should be
> > checked to see if PeiCore not in BFV, otherwise just shadowing PeiCore
> > from BFV.
> >
> > Test: Verified on internal platform and booting successfully.
> >
> > Cc: Jian J Wang 
> > Cc: Hao Wu 
> > Cc: Ray Ni 
> > Cc: Star Zeng 
> > Cc: Liming Gao 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Chasel Chiu 
> > ---
> >  MdeModulePkg/Core/Pei/PeiMain/PeiMain.c | 58
> > +-
> >  MdeModulePkg/Core/Pei/PeiMain.h |  3 ++-
> >  MdeModulePkg/Core/Pei/PeiMain.inf   |  3 ++-
> >  3 files changed, 49 insertions(+), 15 deletions(-)
> >
> > diff --git a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> > b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> > index 4da80a8222..408f24c216 100644
> > --- a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> > +++ b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> > @@ -1,7 +1,7 @@
> >  /** @file
> >Pei Core Main Entry Point
> >
> > -Copyright (c) 2006 - 2018, Intel Corporation. All rights
> > reserved.
> > +Copyright (c) 2006 - 2019, 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 @@ -80,23 +80,55 @@ ShadowPeiCore (
> >IN PEI_CORE_INSTANCE  *PrivateData
> >)
> >  {
> > -  EFI_PEI_FILE_HANDLE  PeiCoreFileHandle;
> > -  EFI_PHYSICAL_ADDRESS EntryPoint;
> > -  EFI_STATUS   Status;
> > -  UINT32   AuthenticationState;
> > +  EFI_PEI_FILE_HANDLE  PeiCoreFileHandle;
> > +  EFI_PHYSICAL_ADDRESS EntryPoint;
> > +  EFI_STATUS   Status;
> > +  UINT32   AuthenticationState;
> > +  UINTNIndex;
> > +  EFI_PEI_CORE_FV_LOCATION_PPI *PeiCoreFvLocationPpi;
> >
> >PeiCoreFileHandle = NULL;
> >
> >//
> > -  // Find the PEI Core in the BFV
> > +  // Find the PEI Core either from EFI_PEI_CORE_FV_LOCATION_PPI
> > + indicated
> > FV or BFV
> >//
> > -  Status = PrivateData->Fv[0].FvPpi->FindFileByType (
> > -   PrivateData->Fv[0].FvPpi,
> > -   EFI_FV_FILETYPE_PEI_CORE,
> > -   PrivateData->Fv[0].FvHandle,
> > -   
> > -   );
> > -  ASSERT_EFI_ERROR (Status);
> > +  Status = PeiServicesLocatePpi (
> > + ,
> > + 0,
> > + NULL,
> > + (VOID **) 
> > + );
> > +  if (!EFI_ERROR (Status) && (PeiCoreFvLocationPpi->PeiCoreFvLocation
> > + !=
> > NULL)) {
> > +//
> > +// If PeiCoreFvLocation present, the PEI Core should be found
> > + from indicated
> > FV.
> > +//
> > +for (Index = 0; Index < PrivateData->FvCount; Index ++) {
> > +  if ((UINT32) PrivateData->Fv[Index].FvHandle != (UINT32)
> > PeiCoreFvLocationPpi->PeiCoreFvLocation) {
> 
> I think the UINT32 type cast is not necessary. FvHandle and PeiCoreFvLocation
> are actually type of VOID*. Do you encounter any compiler error here?
> 
> Regards,
> Jian
> 
> > +continue;
> > +  }
> > +  Status = PrivateData->Fv[Index].FvPpi->FindFileByType (
> > +   
> > PrivateData->Fv[Index].FvPpi,
> > +   EFI_FV_FILETYPE_PEI_CORE,
> > +   
> > PrivateData->Fv[Index].FvHandle,
> > +   
> > +   );
> > +  if (!EFI_ERROR (Status)) {
> > +break;
> > +  }
> > +}
> > +ASSERT (Index < PrivateData->FvCount);  } else {
> > +//
> > +// Find PEI Core from BFV
> > +//
> > +Status = PrivateData->Fv[0].FvPpi->FindFileByType (
> > + PrivateData->Fv[0].FvPpi,
> > + EFI_FV_FILETYPE_PEI_CORE,
> > + PrivateData->Fv[0].FvHandle,
> > +  

Re: [edk2] [PATCH v3] MdeModulePkg/CapsuleApp: Fix memory leak issue.

2019-02-12 Thread Wu, Hao A
> -Original Message-
> From: Chen, Chen A
> Sent: Wednesday, February 13, 2019 8:53 AM
> To: edk2-devel@lists.01.org
> Cc: Chen, Chen A; Wang, Jian J; Wu, Hao A; Zhang, Chao B; Gao, Liming
> Subject: [PATCH v3] MdeModulePkg/CapsuleApp: Fix memory leak issue.
> 
> This issue is caused by FileInfoBuffer variable. This is a pointer array
> and each elements also pointer to a memory buffer that is allocated and
> returned by AllocateCopyPool function.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Zhang Chao B 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen 
> ---
>  MdeModulePkg/Application/CapsuleApp/CapsuleDump.c | 87
> ---
>  1 file changed, 60 insertions(+), 27 deletions(-)
> 
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> index ba2583accb..9fd4af4e55 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> @@ -806,48 +806,69 @@ DumpCapsuleFromDisk (
>Status = Fs->OpenVolume (Fs, );
>if (EFI_ERROR (Status)) {
>  Print (L"Cannot open volume. Status = %r\n", Status);
> -return EFI_NOT_FOUND;
> +goto Done;
>}
> 
>Status = Root->Open (Root, , EFI_CAPSULE_FILE_DIRECTORY,
> EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE , 0);
>if (EFI_ERROR (Status)) {
>  Print (L"Cannot open %s. Status = %r\n", EFI_CAPSULE_FILE_DIRECTORY,
> Status);
> -return EFI_NOT_FOUND;
> +goto Done;
>}
> 
>//
>// Get file count first
>//
> -  for ( Status = FileHandleFindFirstFile (DirHandle, )
> -  ; !EFI_ERROR(Status) && !NoFile
> -  ; Status = FileHandleFindNextFile (DirHandle, FileInfo, )
> - ){
> -if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
> -  continue;
> +  do {
> +Status = FileHandleFindFirstFile (DirHandle, );
> +if (EFI_ERROR (Status) || FileInfo == NULL) {
> +  Print (L"Get File Info Fail. Status = %r\n", Status);
> +  goto Done;
>  }
> -FileCount++;
> -  }
> +
> +if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
> +  FileCount++;
> +}
> +
> +Status = FileHandleFindNextFile (DirHandle, FileInfo, );
> +if (EFI_ERROR (Status)) {
> +  Print (L"Get Next File Fail. Status = %r\n", Status);
> +  goto Done;
> +}
> +  } while (!NoFile);
> 
>if (FileCount == 0) {
>  Print (L"Error: No capsule file found!\n");
> -return EFI_NOT_FOUND;
> +Status = EFI_NOT_FOUND;
> +goto Done;
>}
> 
> -  FileInfoBuffer = AllocatePool (sizeof(FileInfo) * FileCount);
> +  FileInfoBuffer = AllocateZeroPool (sizeof (FileInfo) * FileCount);

Reviewed-by: Hao Wu 

Best Regards,
Hao Wu

> +  if (FileInfoBuffer == NULL) {
> +Status = EFI_OUT_OF_RESOURCES;
> +goto Done;
> +  }
>NoFile = FALSE;
> 
>//
>// Get all file info
>//
> -  for ( Status = FileHandleFindFirstFile (DirHandle, )
> -  ; !EFI_ERROR (Status) && !NoFile
> -  ; Status = FileHandleFindNextFile (DirHandle, FileInfo, )
> - ){
> -if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
> -  continue;
> +  do {
> +Status = FileHandleFindFirstFile (DirHandle, );
> +if (EFI_ERROR (Status) || FileInfo == NULL) {
> +  Print (L"Get File Info Fail. Status = %r\n", Status);
> +  goto Done;
> +}
> +
> +if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
> +  FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
> FileInfo);
>  }
> -FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
> FileInfo);
> -  }
> +
> +Status = FileHandleFindNextFile (DirHandle, FileInfo, );
> +if (EFI_ERROR (Status)) {
> +  Print (L"Get Next File Fail. Status = %r\n", Status);
> +  goto Done;
> +}
> +  } while (!NoFile);
> 
>//
>// Sort FileInfoBuffer by alphabet order
> @@ -866,7 +887,8 @@ DumpCapsuleFromDisk (
>}
> 
>if (!DumpCapsuleInfo) {
> -return EFI_SUCCESS;
> +Status = EFI_SUCCESS;
> +goto Done;
>}
> 
>Print(L"The infomation of the capsules:\n");
> @@ -875,27 +897,28 @@ DumpCapsuleFromDisk (
>  FileHandle = NULL;
>  Status = DirHandle->Open (DirHandle, , FileInfoBuffer[Index]-
> >FileName, EFI_FILE_MODE_READ, 0);
>  if (EFI_ERROR (Status)) {
> -  break;
> +  goto Done;
>  }
> 
>  Status = FileHandleGetSize (FileHandle, (UINT64 *) );
>  if (EFI_ERROR (Status)) {
>Print (L"Cannot read file %s. Status = %r\n", FileInfoBuffer[Index]-
> >FileName, Status);
>FileHandleClose (FileHandle);
> -  return Status;
> +  goto Done;
>  }
> 
>  FileBuffer = AllocatePool (FileSize);
>  if (FileBuffer == NULL) {
> -  return RETURN_OUT_OF_RESOURCES;
> +  Status = EFI_OUT_OF_RESOURCES;
> +  goto Done;
>  }
> 
>  Status = FileHandleRead 

Re: [edk2] [PATCH v5 edk2-platforms 00/22] Platform/RaspberryPi: Add Raspberry Pi 3 support

2019-02-12 Thread Jeremy Linton

the
Hi,

On 2/5/19 10:25 AM, Pete Batard wrote:

Changes for v5:

* Raspberry/Pi3 -> RaspberryPi/RPi3
* Remove VirtualRealTimeClockLib as well as BUILD_EPOCH macro (use the upcoming
   EmbeddedPkg Virtual RTC from EDK2 instead)
* Use $(PLATFORM_NAME) where possible in .dsc and .fdf
* Update Readme to remove build instructions, describe ACPI limitations, fix
   ATF Readme link and split OS installation & test notes into a separate file.
* Add -Wl,--fix-cortex-a53-843419 to LINK_FLAGS

IMPORTANT: Due to the removal of VirtualRealTimeClockLib this series requires
https://lists.01.org/pipermail/edk2-devel/2019-February/036301.html to have
been applied to your edk2 repository.


I would just like to congratulate everyone working on this port. It is 
crazy awesome! I just applied these patches, followed the readme 
instructions for the SD card. Then grabbed a USB DVD drive, and a USB 
SSD, plugged in a keyboard/mouse/monitor/network and booted the fedora 
29 1.2 install ISO. The graphical installer ran as expected, system 
installed as expected, and other than the nextboot not being reset (had 
to update it via the BDS, as is documented) it "just worked".


There are a few rough edges here/there but the idea that we have another 
ARM machine that almost behaves like one expects a modern computing 
device to behave, is wonderful. The only real gocha continues to be the 
rpi's well known shortcomings, including the fact that it took nearly 6 
hours to install.



so,

Tested-by: Jeremy Linton 






Regards,

/Pete


Pete Batard (22):
   Silicon/Broadcom/Bcm283x: Add interrupt driver
   Silicon/Broadcom/Bcm283x: Add GpioLib
   Platform/RaspberryPi/RPi3: Add ACPI tables
   Platform/RaspberryPi/RPi3: Add reset and memory init libraries
   Platform/RaspberryPi/RPi3: Add platform library
   Platform/RaspberryPi/RPi3: Add firmware driver
   Platform/RaspberryPi/RPi3: Add platform config driver
   Platform/RaspberryPi/RPi3: Add SMBIOS driver
   Platform/RaspberryPi/RPi3: Add display driver
   Platform/RaspberryPi/RPi3: Add console driver
   Platform/RaspberryPi/RPi3: Add NV storage driver
   Platform/RaspberryPi/RPi3: Add Device Tree driver
   Platform/RaspberryPi/RPi3: Add base MMC driver
   Platform/RaspberryPi/RPi3: Add Arasan MMC driver
   Platform/RaspberryPi/RPi3: Add SD Host driver
   Platform/RaspberryPi/RPi3: Add platform boot manager and helper libs
   Platform/RaspberryPi/RPi3: Add USB host driver
   Platform/RaspberryPi/RPi3 *NON-OSI*: Add ATF binaries
   Platform/RaspberryPi/RPi3 *NON-OSI*: Add Device Tree binaries
   Platform/RaspberryPi/RPi3 *NON-OSI*: Add logo driver
   Platform/RaspberryPi/RPi3: Add platform
   Platform/RaspberryPi/RPi3: Add platform readme's

  .../RaspberryPi/RPi3/AcpiTables/AcpiTables.h  |   82 +
  .../RPi3/AcpiTables/AcpiTables.inf|   46 +
  .../RaspberryPi/RPi3/AcpiTables/Csrt.aslc |  332 +++
  .../RaspberryPi/RPi3/AcpiTables/Dbg2.aslc |   34 +
  Platform/RaspberryPi/RPi3/AcpiTables/Dsdt.asl |  511 +
  .../RaspberryPi/RPi3/AcpiTables/Fadt.aslc |   52 +
  .../RaspberryPi/RPi3/AcpiTables/Gtdt.aslc |   33 +
  .../RaspberryPi/RPi3/AcpiTables/Madt.aslc |   62 +
  Platform/RaspberryPi/RPi3/AcpiTables/Pep.asl  |   95 +
  Platform/RaspberryPi/RPi3/AcpiTables/Pep.c|   84 +
  Platform/RaspberryPi/RPi3/AcpiTables/Pep.h|  126 ++
  Platform/RaspberryPi/RPi3/AcpiTables/Rhpx.asl |  201 ++
  Platform/RaspberryPi/RPi3/AcpiTables/Sdhc.asl |  105 +
  Platform/RaspberryPi/RPi3/AcpiTables/Spcr.asl |   53 +
  Platform/RaspberryPi/RPi3/AcpiTables/Uart.asl |  158 ++
  .../RaspberryPi/RPi3/DeviceTree/License.txt   |  340 +++
  .../RPi3/DeviceTree/bcm2710-rpi-3-b-plus.dtb  |  Bin 0 -> 25617 bytes
  .../RPi3/DeviceTree/bcm2710-rpi-3-b-plus.dts  | 1263 
  .../RPi3/DeviceTree/bcm2710-rpi-3-b.dtb   |  Bin 0 -> 25354 bytes
  .../RPi3/DeviceTree/bcm2710-rpi-3-b.dts   | 1259 +++
  .../ArasanMmcHostDxe/ArasanMmcHostDxe.c   |  723 +++
  .../ArasanMmcHostDxe/ArasanMmcHostDxe.h   |   50 +
  .../ArasanMmcHostDxe/ArasanMmcHostDxe.inf |   52 +
  .../RPi3/Drivers/ConfigDxe/ConfigDxe.c|  351 
  .../RPi3/Drivers/ConfigDxe/ConfigDxe.inf  |   78 +
  .../Drivers/ConfigDxe/ConfigDxeFormSetGuid.h  |   23 +
  .../RPi3/Drivers/ConfigDxe/ConfigDxeHii.uni   |  100 +
  .../RPi3/Drivers/ConfigDxe/ConfigDxeHii.vfr   |  306 +++
  .../RPi3/Drivers/DisplayDxe/ComponentName.c   |  222 ++
  .../RPi3/Drivers/DisplayDxe/DisplayDxe.c  |  606 ++
  .../RPi3/Drivers/DisplayDxe/DisplayDxe.h  |   42 +
  .../RPi3/Drivers/DisplayDxe/DisplayDxe.inf|   71 +
  .../RPi3/Drivers/DisplayDxe/Screenshot.c  |  375 
  .../RPi3/Drivers/DwUsbHostDxe/ComponentName.c |  225 ++
  .../RPi3/Drivers/DwUsbHostDxe/DriverBinding.c |  274 +++
  .../RPi3/Drivers/DwUsbHostDxe/DwUsbHostDxe.c  | 1635 +++
  .../RPi3/Drivers/DwUsbHostDxe/DwUsbHostDxe.h  |  162 ++
  .../Drivers/DwUsbHostDxe/DwUsbHostDxe.inf |   59 +
  

[edk2] [Patch edk2 wiki] Add new feature: WiFi Connection Manager for edk2-stable201903 in EDK-II-Release-Planning

2019-02-12 Thread Wang Fan
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wang Fan 
---
 EDK-II-Release-Planning.md | 1 +
 1 file changed, 1 insertion(+)

diff --git a/EDK-II-Release-Planning.md b/EDK-II-Release-Planning.md
index f302be3..eba2afe 100644
--- a/EDK-II-Release-Planning.md
+++ b/EDK-II-Release-Planning.md
@@ -23,9 +23,10 @@
 * [Split the S3 phase device initialization codes from the OpalPassword PEI 
driver](https://bugzilla.tianocore.org/show_bug.cgi?id=1409)
 * [Remove PcdPeiCoreMaxXXX 
PCDs](https://bugzilla.tianocore.org/show_bug.cgi?id=1405)
 * [Remove unused tool logic in BaseTools 
C\Python](https://bugzilla.tianocore.org/show_bug.cgi?id=1350)
 * [BaseTools: Enable component override 
functionality](https://bugzilla.tianocore.org/show_bug.cgi?id=1449)
 * [SMM CET support](https://bugzilla.tianocore.org/show_bug.cgi?id=1521)
+* [Add Wi-Fi Connection Manager to 
NetworkPkg](https://bugzilla.tianocore.org/show_bug.cgi?id=1492)
 * Standalone MM build of authenticated variable stack (bugzilla link TBD)
 * TBD Bugzilla List
 
 ---
-- 
2.16.2.windows.1

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


Re: [edk2] [Patch 3/3] UefiCpuPkg/RegisterCpuFeaturesLib: Simplify PcdCpuFeaturesSupport.

2019-02-12 Thread Laszlo Ersek
On 02/13/19 03:04, Eric Dong wrote:
> PcdCpuFeaturesSupport used to specify the platform policy about
> what CPU features this platform supports. This value is decide by
> platform owner, not by hardware. After this change, this PCD will
> be used in IsCpuFeatureSupported function only.
> 
> Now RegisterCpuFeaturesLib use this PCD as an template to Get the
> pcd size. Update the code logic to replace it with
> PcdCpuFeaturesSetting.
> 
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1375
> 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  .../RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 66 
> +++---
>  .../RegisterCpuFeaturesLib/RegisterCpuFeatures.h   |  1 -
>  .../RegisterCpuFeaturesLib.c   | 10 ++--
>  3 files changed, 24 insertions(+), 53 deletions(-)
> 
> diff --git 
> a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c 
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> index 4ebd0025b4..762eaec277 100644
> --- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> +++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> @@ -74,27 +74,6 @@ GetSettingPcd (
>return SettingBitMask;
>  }
>  
> -/**
> -  Worker function to get PcdCpuFeaturesSupport.
> -
> -  @return  The pointer to CPU feature bits mask buffer.
> -**/
> -UINT8 *
> -GetSupportPcd (
> -  VOID
> -  )
> -{
> -  UINT8  *SupportBitMask;
> -
> -  SupportBitMask = AllocateCopyPool (
> -  PcdGetSize (PcdCpuFeaturesSupport),
> -  PcdGetPtr (PcdCpuFeaturesSupport)
> -  );
> -  ASSERT (SupportBitMask != NULL);
> -
> -  return SupportBitMask;
> -}
> -
>  /**
>Collects CPU type and feature information.
>  
> @@ -282,11 +261,6 @@ CpuInitDataInitialize (
>ASSERT (CpuFeaturesData->CpuFlags.CoreSemaphoreCount != NULL);
>CpuFeaturesData->CpuFlags.PackageSemaphoreCount = AllocateZeroPool (sizeof 
> (UINT32) * CpuStatus->PackageCount * CpuStatus->MaxCoreCount * 
> CpuStatus->MaxThreadCount);
>ASSERT (CpuFeaturesData->CpuFlags.PackageSemaphoreCount != NULL);
> -
> -  //
> -  // Get support and configuration PCDs
> -  //
> -  CpuFeaturesData->SupportPcd   = GetSupportPcd ();
>  }
>  
>  /**
> @@ -306,7 +280,7 @@ SupportedMaskOr (
>UINT8  *Data1;
>UINT8  *Data2;
>  
> -  BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
> +  BitMaskSize = PcdGetSize (PcdCpuFeaturesSetting);
>Data1 = SupportedFeatureMask;
>Data2 = OrFeatureBitMask;
>for (Index = 0; Index < BitMaskSize; Index++) {
> @@ -331,7 +305,7 @@ SupportedMaskAnd (
>UINT8  *Data1;
>UINT8  *Data2;
>  
> -  BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
> +  BitMaskSize = PcdGetSize (PcdCpuFeaturesSetting);
>Data1 = SupportedFeatureMask;
>Data2 = AndFeatureBitMask;
>for (Index = 0; Index < BitMaskSize; Index++) {
> @@ -356,7 +330,7 @@ SupportedMaskCleanBit (
>UINT8  *Data1;
>UINT8  *Data2;
>  
> -  BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
> +  BitMaskSize = PcdGetSize (PcdCpuFeaturesSetting);
>Data1 = SupportedFeatureMask;
>Data2 = AndFeatureBitMask;
>for (Index = 0; Index < BitMaskSize; Index++) {
> @@ -387,7 +361,7 @@ IsBitMaskMatch (
>UINT8  *Data1;
>UINT8  *Data2;
>  
> -  BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
> +  BitMaskSize = PcdGetSize (PcdCpuFeaturesSetting);
>  
>Data1 = SupportedFeatureMask;
>Data2 = ComparedFeatureBitMask;
> @@ -426,22 +400,22 @@ CollectProcessorData (
>Entry = GetFirstNode (>FeatureList);
>while (!IsNull (>FeatureList, Entry)) {
>  CpuFeature = CPU_FEATURE_ENTRY_FROM_LINK (Entry);
> -if (IsBitMaskMatch (CpuFeaturesData->SupportPcd, 
> CpuFeature->FeatureMask)) {
> -  if (CpuFeature->SupportFunc == NULL) {
> -//
> -// If SupportFunc is NULL, then the feature is supported.
> -//
> -SupportedMaskOr (
> -  CpuFeaturesData->InitOrder[ProcessorNumber].FeaturesSupportedMask,
> -  CpuFeature->FeatureMask
> -  );
> -  } else if (CpuFeature->SupportFunc (ProcessorNumber, CpuInfo, 
> CpuFeature->ConfigData)) {
> -SupportedMaskOr (
> -  CpuFeaturesData->InitOrder[ProcessorNumber].FeaturesSupportedMask,
> -  CpuFeature->FeatureMask
> -  );
> -  }
> +
> +if (CpuFeature->SupportFunc == NULL) {
> +  //
> +  // If SupportFunc is NULL, then the feature is supported.
> +  //
> +  SupportedMaskOr (
> +CpuFeaturesData->InitOrder[ProcessorNumber].FeaturesSupportedMask,
> +CpuFeature->FeatureMask
> +);
> +} else if (CpuFeature->SupportFunc (ProcessorNumber, CpuInfo, 
> CpuFeature->ConfigData)) {
> +  SupportedMaskOr (
> +

Re: [edk2] [PATCH edk2-platforms v1 09/16] Hisilicon/D06: Add PCI_OSC_SUPPORT

2019-02-12 Thread Ming Huang



On 2/12/2019 2:51 AM, Leif Lindholm wrote:
> On Fri, Feb 01, 2019 at 09:34:29PM +0800, Ming Huang wrote:
>> Add PCI_OSC_SUPPORT for remaining host bridges to remove fail
>> output in kernel:
>> [  103.478893] acpi PNP0A08:01: _OSC failed (AE_NOT_FOUND);
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> ---
>>  Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl | 64 
>> 
>>  1 file changed, 64 insertions(+)
>>
>> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl 
>> b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
>> index 4d9d9d95be68..86d8728b82f2 100644
>> --- a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
>> +++ b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
>> @@ -17,6 +17,50 @@
>>  **/
>>  
>>  //#include "ArmPlatform.h"
>> +
>> +/*
>> +  See ACPI 6.1 Spec, 6.2.11, PCI Firmware Spec 3.0, 4.5
>> +*/
>> +#define PCI_OSC_SUPPORT() \
> 
> PCI0 and PCI6 already have _OSC entries.
> This macro ends up being used for 1-5 and 7-B.
> So calling it PCI_OSC_SUPPORT seems somewhat misleading.
> 
> Then again, there is a lot of similarities between this macro and the
> existing entries. Could the same macro be used for 0 and 6? Or could
> the macro be split up into multiple parts and reused?

When I make this patch, I try to rewrite PCI0/6 with the same macro, but
the macro don't support parameter. For spliting up multiple parts, if modify
something in future, the parts need to split up to smaller parts. So, if
need to rewrite PCI0/6 with macro, is it applicable to add another macro
PCI_OSC_SUPPORT_HOTPLUG?

Thanks

> 
> /
> Leif
> 
>> +  Name(SUPP, Zero) /* PCI _OSC Support Field value */ \
>> +  Name(CTRL, Zero) /* PCI _OSC Control Field value */ \
>> +  Method(_OSC,4) { \
>> +If(LEqual(Arg0,ToUUID("33DB4D5B-1FF7-401C-9657-7441C03DD766"))) { \
>> +  /* Create DWord-adressable fields from the Capabilities Buffer */ \
>> +  CreateDWordField(Arg3,0,CDW1) \
>> +  CreateDWordField(Arg3,4,CDW2) \
>> +  CreateDWordField(Arg3,8,CDW3) \
>> +  /* Save Capabilities DWord2 & 3 */ \
>> +  Store(CDW2,SUPP) \
>> +  Store(CDW3,CTRL) \
>> +  /* Only allow native hot plug control if OS supports: */ \
>> +  /* ASPM */ \
>> +  /* Clock PM */ \
>> +  /* MSI/MSI-X */ \
>> +  If(LNotEqual(And(SUPP, 0x16), 0x16)) { \
>> +And(CTRL,0x1E,CTRL) \
>> +  }\
>> +  \
>> +  /* Do not allow native PME, AER */ \
>> +  /* Never allow SHPC (no SHPC controller in this system)*/ \
>> +  And(CTRL,0x10,CTRL) \
>> +  If(LNotEqual(Arg1,One)) { /* Unknown revision */ \
>> +Or(CDW1,0x08,CDW1) \
>> +  } \
>> +  \
>> +  If(LNotEqual(CDW3,CTRL)) { /* Capabilities bits were masked */ \
>> +Or(CDW1,0x10,CDW1) \
>> +  } \
>> +  \
>> +  /* Update DWORD3 in the buffer */ \
>> +  Store(CTRL,CDW3) \
>> +  Return(Arg3) \
>> +} Else { \
>> +  Or(CDW1,4,CDW1) /* Unrecognized UUID */ \
>> +  Return(Arg3) \
>> +} \
>> +  } // End _OSC
>> +
>>  Scope(_SB)
>>  {
>>Device (PCI0)
>> @@ -270,6 +314,8 @@ Device (PCI1)
>>  Return (RBUF)
>>} // Method(_CRS), this method 
>> return RBUF!
>>  
>> +  PCI_OSC_SUPPORT ()
>> +
>>Method (_STA, 0x0, NotSerialized)
>>{
>>  Return (0xf)
>> @@ -333,6 +379,8 @@ Device (PCI2)
>>  Return (RBUF)
>>} // Method(_CRS), this method 
>> return RBUF!
>>  
>> +  PCI_OSC_SUPPORT ()
>> +
>>Method (_STA, 0x0, NotSerialized)
>>{
>>  Return (0xf)
>> @@ -382,6 +430,8 @@ Device (PCI3)
>>  Return (RBUF)
>>} // Method(_CRS), this method 
>> return RBUF!
>>  
>> +  PCI_OSC_SUPPORT ()
>> +
>>Method (_STA, 0x0, NotSerialized)
>>{
>>  Return (0xf)
>> @@ -431,6 +481,8 @@ Device (PCI4)
>>  Return (RBUF)
>>} // Method(_CRS), this method 
>> return RBUF!
>>  
>> +  PCI_OSC_SUPPORT ()
>> +
>>Method (_STA, 0x0, NotSerialized)
>>{
>>  Return (0x0F)
>> @@ -505,6 +557,8 @@ Device (PCI5)
>>  Return (RBUF)
>>}// Method(_CRS), this method return 
>> RBUF!
>>  
>> +  PCI_OSC_SUPPORT ()
>> +
>>Method (_STA, 0x0, NotSerialized)
>>{
>>  Return (0xf)
>> @@ -1002,6 +1056,8 @@ Device (PCI7)
>>  Return (RBUF)
>>} // Method(_CRS), this method 
>> return RBUF!
>>  
>> +  PCI_OSC_SUPPORT ()
>> +
>>Method (_STA, 0x0, NotSerialized)
>>{
>>  Return (0xf)
>> @@ -1066,6 +1122,8 @@ Device (PCI8)
>>  Return (RBUF)
>>} // Method(_CRS), this method 
>> return RBUF!
>>  
>> +  PCI_OSC_SUPPORT ()
>> +
>>Method (_STA, 0x0, NotSerialized)
>>{
>>  Return (0xf)
>> @@ -1115,6 +1173,8 @@ Device 

Re: [edk2] [Patch 2/3] UefiCpuPkg/RegisterCpuFeaturesLib: Optimize PCD PcdCpuFeaturesUserConfiguration.

2019-02-12 Thread Laszlo Ersek
On 02/13/19 03:04, Eric Dong wrote:
> In current implementation, PCD PcdCpuFeaturesUserConfiguration used as
> user enabled CPU features list. It is initialzied in platform driver
> and as an input for CpuFeatures driver. PCD PcdCpuFeaturesSetting used
> as an output for the final enabled CPU features list. For now,
> PcdCpuFeaturesUserConfiguration is only used as an input and
> PcdCpuFeaturesSetting only used as an output.
> 
> This change merge PcdCpuFeaturesUserConfiguration into
> PcdCpuFeaturesSetting.
> Use PcdCpuFeaturesSetting as input for the user input feature setting
> Use PcdCpuFeaturesSetting as output for the final CPU feature setting
> 
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1375
> 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  .../RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 37 
> --
>  .../DxeRegisterCpuFeaturesLib.inf  |  1 -
>  .../PeiRegisterCpuFeaturesLib.inf  |  1 -
>  .../RegisterCpuFeaturesLib/RegisterCpuFeatures.h   |  1 -
>  UefiCpuPkg/UefiCpuPkg.dec  |  7 ++--
>  5 files changed, 22 insertions(+), 25 deletions(-)
> 
> diff --git 
> a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c 
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> index bae92b89a6..4ebd0025b4 100644
> --- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> +++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
> @@ -54,41 +54,41 @@ SetSettingPcd (
>  }
>  
>  /**
> -  Worker function to get PcdCpuFeaturesSupport.
> +  Worker function to get PcdCpuFeaturesSetting.
>  
>@return  The pointer to CPU feature bits mask buffer.
>  **/
>  UINT8 *
> -GetSupportPcd (
> +GetSettingPcd (
>VOID
>)
>  {
> -  UINT8  *SupportBitMask;
> +  UINT8  *SettingBitMask;
>  
> -  SupportBitMask = AllocateCopyPool (
> -  PcdGetSize (PcdCpuFeaturesSupport),
> -  PcdGetPtr (PcdCpuFeaturesSupport)
> +  SettingBitMask = AllocateCopyPool (
> +  PcdGetSize (PcdCpuFeaturesSetting),
> +  PcdGetPtr (PcdCpuFeaturesSetting)
>);

(1) The indentation of the AllocateCopyPool() arguments is not
idiomatic. I suggest fixing that, even if it means diverging from the
old code.

> -  ASSERT (SupportBitMask != NULL);
> +  ASSERT (SettingBitMask != NULL);
>  
> -  return SupportBitMask;
> +  return SettingBitMask;
>  }
>  
>  /**
> -  Worker function to get PcdCpuFeaturesUserConfiguration.
> +  Worker function to get PcdCpuFeaturesSupport.
>  
>@return  The pointer to CPU feature bits mask buffer.
>  **/
>  UINT8 *
> -GetConfigurationPcd (
> +GetSupportPcd (
>VOID
>)
>  {
>UINT8  *SupportBitMask;
>  
>SupportBitMask = AllocateCopyPool (
> -  PcdGetSize (PcdCpuFeaturesUserConfiguration),
> -  PcdGetPtr (PcdCpuFeaturesUserConfiguration)
> +  PcdGetSize (PcdCpuFeaturesSupport),
> +  PcdGetPtr (PcdCpuFeaturesSupport)
>);
>ASSERT (SupportBitMask != NULL);
>  
> @@ -287,7 +287,6 @@ CpuInitDataInitialize (
>// Get support and configuration PCDs
>//
>CpuFeaturesData->SupportPcd   = GetSupportPcd ();
> -  CpuFeaturesData->ConfigurationPcd = GetConfigurationPcd ();
>  }
>  
>  /**
> @@ -595,6 +594,9 @@ AnalysisProcessorFeatures (
>CPU_FEATURE_DEPENDENCE_TYPE  AfterDep;
>CPU_FEATURE_DEPENDENCE_TYPE  NoneNeibBeforeDep;
>CPU_FEATURE_DEPENDENCE_TYPE  NoneNeibAfterDep;
> +  UINT8*ConfigurationPcd;
> +
> +  ConfigurationPcd = NULL;
>  
>CpuFeaturesData = GetCpuFeaturesData ();
>CpuFeaturesData->CapabilityPcd = AllocatePool 
> (CpuFeaturesData->BitMaskSize);
> @@ -610,10 +612,13 @@ AnalysisProcessorFeatures (
>//
>// Calculate the last setting
>//
> -
>CpuFeaturesData->SettingPcd = AllocateCopyPool 
> (CpuFeaturesData->BitMaskSize, CpuFeaturesData->CapabilityPcd);
>ASSERT (CpuFeaturesData->SettingPcd != NULL);
> -  SupportedMaskAnd (CpuFeaturesData->SettingPcd, 
> CpuFeaturesData->ConfigurationPcd);
> +  ConfigurationPcd = GetSettingPcd ();
> +  SupportedMaskAnd (CpuFeaturesData->SettingPcd, ConfigurationPcd);
> +  if (ConfigurationPcd != NULL) {
> +FreePool (ConfigurationPcd);
> +  }

(2) Why is it necessary to set ConfigurationPcd to NULL at the beginning
of the function? And why is the NULL check necessary here?
GetSettingPcd() can never return NULL.

(I don't just mean the ASSERT, but also the fact that we pass
ConfigurationPcd to SupportedMaskAnd() without checking ConfigurationPcd
for NULL.)

>  
>//
>// Save PCDs and display CPU PCDs
> @@ -643,8 +648,6 @@ AnalysisProcessorFeatures (
>  }
>  DEBUG ((DEBUG_INFO, "PcdCpuFeaturesSupport:\n"));
>  DumpCpuFeatureMask (CpuFeaturesData->SupportPcd);
> -DEBUG ((DEBUG_INFO, 

Re: [edk2] [PATCH edk2-platforms v1 06/16] Hisilicon/D06: Add OemGetCpuFreq to encapsulate difference

2019-02-12 Thread Ming Huang



On 2/12/2019 1:15 AM, Leif Lindholm wrote:
> On Fri, Feb 01, 2019 at 09:34:26PM +0800, Ming Huang wrote:
>> From: xingjiang tang 
>>
>> Implementation OemGetCpuFreq() to get cpu frequency from cpld to
>> encapsulate project difference, for some projects don't support
>> get cpu frequency by this way.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> ---
>>  Platform/Hisilicon/D06/Include/Library/CpldD06.h |  4 
>>  Silicon/Hisilicon/Include/Library/OemMiscLib.h   |  2 ++
>>  Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c | 16 
>> 
>>  3 files changed, 22 insertions(+)
>>
>> diff --git a/Platform/Hisilicon/D06/Include/Library/CpldD06.h 
>> b/Platform/Hisilicon/D06/Include/Library/CpldD06.h
>> index ec9b49f4e70d..4d07a8ab3741 100644
>> --- a/Platform/Hisilicon/D06/Include/Library/CpldD06.h
>> +++ b/Platform/Hisilicon/D06/Include/Library/CpldD06.h
>> @@ -36,4 +36,8 @@
>>  #define CPLD_X8_X8_X8_BOARD_ID0x92
>>  #define CPLD_X16_X8_BOARD_ID  0x93
>>  
>> +#define CPLD_CLOCK_FLAG  0xFD
>> +#define CPLD_BOM_VER_FLAG0x0B
>> +#define BRD_VER_4TH  0x4
> 
> What is BRD_VER_4TH? Please write out full words.
> Also, this macro needs a CPLD_ prefix.

BRD_VER_4TH: BOARD_REVISION_4TH
Modify in v2.

> 
>> +
>>  #endif /* __CPLDD06_H__ */
>> diff --git a/Silicon/Hisilicon/Include/Library/OemMiscLib.h 
>> b/Silicon/Hisilicon/Include/Library/OemMiscLib.h
>> index 86ea6a1b3deb..dfac87d635d9 100644
>> --- a/Silicon/Hisilicon/Include/Library/OemMiscLib.h
>> +++ b/Silicon/Hisilicon/Include/Library/OemMiscLib.h
>> @@ -53,4 +53,6 @@ BOOLEAN OemIsNeedDisableExpanderBuffer(VOID);
>>  
>>  extern EFI_STRING_ID gDimmToDevLocator[MAX_SOCKET][MAX_CHANNEL][MAX_DIMM];
>>  EFI_HII_HANDLE EFIAPI OemGetPackages ();
>> +UINTN OemGetCpuFreq (UINT8 Socket);
>> +
>>  #endif
>> diff --git a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c 
>> b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
>> index 2a9db46d1ff9..8f2ac308c7b9 100644
>> --- a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
>> +++ b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
>> @@ -207,3 +207,19 @@ OemIsNeedDisableExpanderBuffer (
>>  {
>>return TRUE;
>>  }
>> +
>> +UINTN OemGetCpuFreq (UINT8 Socket)
>> +{
>> +  UINT8 BrdVerData;
> 
> Write out full words.
> 
>> +
>> +  BrdVerData = MmioRead8(CPLD_BASE_ADDRESS + CPLD_BOM_VER_FLAG);
> 
> Space before (.
> 
>> +
>> +  if (BrdVerData >= BRD_VER_4TH){  //2.5G
> 
> What is the comment saying? The number below?
> The number below is also saying the number below.
> A useful comment would be
> "// Board revision 4 and higher run at 2.5GHz
>  // Earlier revisions run at 2GHz"
> 
> At that point you don't even need the #define.
> And not really the temporary variable either.
> 
>> +return 25;
>> +  }
>> +  else
>> +  {
> 
> } else {

Modify in v2.

Thanks

> 
> /
> Leif
> 
>> + return 20;
>> +  }
>> +}
>> +
>> -- 
>> 2.9.5
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib: Remove useless functions.

2019-02-12 Thread Laszlo Ersek
On 02/13/19 03:04, Eric Dong wrote:
> Remove useless APIs, simply the code logic.

s/simply/simplify/

> 
> BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1375
> 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  .../Include/Library/RegisterCpuFeaturesLib.h   | 34 ---
>  .../RegisterCpuFeaturesLib.c   | 50 
> --
>  2 files changed, 84 deletions(-)

With the typo fixed:

Reviewed-by: Laszlo Ersek 

Thanks
Laszlo

> diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h 
> b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> index 2f7e71c833..073f020d0b 100644
> --- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> +++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
> @@ -166,40 +166,6 @@ IsCpuFeatureInSetting (
>IN UINT32  Feature
>);
>  
> -/**
> -  Determines if a CPU feature is set in PcdCpuFeaturesCapability bit mask.
> -
> -  @param[in]  Feature  The bit number of the CPU feature to check in the PCD
> -   PcdCpuFeaturesCapability.
> -
> -  @retval  TRUE   The CPU feature is set in PcdCpuFeaturesCapability.
> -  @retval  FALSE  The CPU feature is not set in PcdCpuFeaturesCapability.
> -
> -  @note This service could be called by BSP only.
> -**/
> -BOOLEAN
> -EFIAPI
> -IsCpuFeatureCapability (
> -  IN UINT32  Feature
> -  );
> -
> -/**
> -  Determines if a CPU feature is set in PcdCpuFeaturesUserConfiguration bit 
> mask.
> -
> -  @param[in]  Feature  The bit number of the CPU feature to check in the PCD
> -   PcdCpuFeaturesUserConfiguration.
> -
> -  @retval  TRUE   The CPU feature is set in PcdCpuFeaturesUserConfiguration.
> -  @retval  FALSE  The CPU feature is not set in 
> PcdCpuFeaturesUserConfiguration.
> -
> -  @note This service could be called by BSP only.
> -**/
> -BOOLEAN
> -EFIAPI
> -IsCpuFeatureUserConfiguration (
> -  IN UINT32  Feature
> -  );
> -
>  /**
>Prepares for the data used by CPU feature detection and initialization.
>  
> diff --git 
> a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c 
> b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> index ed8d526325..3540029079 100644
> --- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> +++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
> @@ -1242,56 +1242,6 @@ IsCpuFeatureInSetting (
> );
>  }
>  
> -/**
> -  Determines if a CPU feature is set in PcdCpuFeaturesCapability bit mask.
> -
> -  @param[in]  Feature  The bit number of the CPU feature to check in the PCD
> -   PcdCpuFeaturesCapability
> -
> -  @retval  TRUE   The CPU feature is set in PcdCpuFeaturesCapability.
> -  @retval  FALSE  The CPU feature is not set in PcdCpuFeaturesCapability.
> -
> -  @note This service could be called by BSP only.
> -**/
> -BOOLEAN
> -EFIAPI
> -IsCpuFeatureCapability (
> -  IN UINT32  Feature
> -  )
> -{
> -  return IsCpuFeatureSetInCpuPcd (
> -   (UINT8 *)PcdGetPtr (PcdCpuFeaturesCapability),
> -   PcdGetSize (PcdCpuFeaturesCapability),
> -   Feature
> -   );
> -
> -}
> -
> -/**
> -  Determines if a CPU feature is set in PcdCpuFeaturesUserConfiguration bit 
> mask.
> -
> -  @param[in]  Feature  The bit number of the CPU feature to check in the PCD
> -   PcdCpuFeaturesUserConfiguration
> -
> -  @retval  TRUE   The CPU feature is set in PcdCpuFeaturesUserConfiguration.
> -  @retval  FALSE  The CPU feature is not set in 
> PcdCpuFeaturesUserConfiguration.
> -
> -  @note This service could be called by BSP only.
> -**/
> -BOOLEAN
> -EFIAPI
> -IsCpuFeatureUserConfiguration (
> -  IN UINT32  Feature
> -  )
> -{
> -  return IsCpuFeatureSetInCpuPcd (
> -   (UINT8 *)PcdGetPtr (PcdCpuFeaturesUserConfiguration),
> -   PcdGetSize (PcdCpuFeaturesUserConfiguration),
> -   Feature
> -   );
> -
> -}
> -
>  /**
>Switches to assigned BSP after CPU features initialization.
>  
> 

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


Re: [edk2] [PATCH edk2-platforms v1 04/16] Hisilicon/D06: Fix access variable fail issue

2019-02-12 Thread Ming Huang



On 2/12/2019 11:17 PM, Leif Lindholm wrote:
> On Fri, Feb 01, 2019 at 09:34:24PM +0800, Ming Huang wrote:
>> From: Jason Zhang 
>>
>> BmcWdtEnable is a field of OemConfigData structure, need have
>> runtime service attribution if use it during exit boot service
> 
> This sounds like a very shady thing to do.
> Which module is seeing issues, and what issues are it seeing, during
> ExitBootServices?

Yes,WatchDog module read the OemConfigData.BmcWdtEnable during ExitBootServices
and will get fail log before boot kernel:

Get Variable failed. Status Not Found
[0.00] Booting Linux on physical CPU 0x01 [0x480fd010]

Thanks.

> 
> /
> Leif
> 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> ---
>>  Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr | 2 +-
>>  Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c  | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr 
>> b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
>> index 470e9ace3dcf..08236704fbfe 100644
>> --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
>> +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
>> @@ -23,7 +23,7 @@ formset
>>help  = STRING_TOKEN(STR_OEM_CONFIG),
>>classguid = gEfiIfrFrontPageGuid,  // for MdeModule Bds.
>>efivarstore OEM_CONFIG_DATA,
>> -attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_NON_VOLATILE,
>> +attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_NON_VOLATILE 
>> | EFI_VARIABLE_RUNTIME_ACCESS,
>>  name  = OemConfig,
>>  guid  = gOemConfigGuid;
>>  
>> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c 
>> b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
>> index 012d45bc0214..6668103af027 100644
>> --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
>> +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
>> @@ -316,7 +316,7 @@ OemConfigUiLibConstructor (
>>Status = gRT->SetVariable (
>>OEM_CONFIG_NAME,
>>,
>> -  EFI_VARIABLE_NON_VOLATILE | 
>> EFI_VARIABLE_BOOTSERVICE_ACCESS,
>> +  EFI_VARIABLE_NON_VOLATILE | 
>> EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS,
>>sizeof (OEM_CONFIG_DATA),
>>
>>);
>> -- 
>> 2.9.5
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [Patch 3/3] UefiCpuPkg/RegisterCpuFeaturesLib: Simplify PcdCpuFeaturesSupport.

2019-02-12 Thread Eric Dong
PcdCpuFeaturesSupport used to specify the platform policy about
what CPU features this platform supports. This value is decide by
platform owner, not by hardware. After this change, this PCD will
be used in IsCpuFeatureSupported function only.

Now RegisterCpuFeaturesLib use this PCD as an template to Get the
pcd size. Update the code logic to replace it with
PcdCpuFeaturesSetting.

BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1375

Cc: Ray Ni 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
---
 .../RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 66 +++---
 .../RegisterCpuFeaturesLib/RegisterCpuFeatures.h   |  1 -
 .../RegisterCpuFeaturesLib.c   | 10 ++--
 3 files changed, 24 insertions(+), 53 deletions(-)

diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
index 4ebd0025b4..762eaec277 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
@@ -74,27 +74,6 @@ GetSettingPcd (
   return SettingBitMask;
 }
 
-/**
-  Worker function to get PcdCpuFeaturesSupport.
-
-  @return  The pointer to CPU feature bits mask buffer.
-**/
-UINT8 *
-GetSupportPcd (
-  VOID
-  )
-{
-  UINT8  *SupportBitMask;
-
-  SupportBitMask = AllocateCopyPool (
-  PcdGetSize (PcdCpuFeaturesSupport),
-  PcdGetPtr (PcdCpuFeaturesSupport)
-  );
-  ASSERT (SupportBitMask != NULL);
-
-  return SupportBitMask;
-}
-
 /**
   Collects CPU type and feature information.
 
@@ -282,11 +261,6 @@ CpuInitDataInitialize (
   ASSERT (CpuFeaturesData->CpuFlags.CoreSemaphoreCount != NULL);
   CpuFeaturesData->CpuFlags.PackageSemaphoreCount = AllocateZeroPool (sizeof 
(UINT32) * CpuStatus->PackageCount * CpuStatus->MaxCoreCount * 
CpuStatus->MaxThreadCount);
   ASSERT (CpuFeaturesData->CpuFlags.PackageSemaphoreCount != NULL);
-
-  //
-  // Get support and configuration PCDs
-  //
-  CpuFeaturesData->SupportPcd   = GetSupportPcd ();
 }
 
 /**
@@ -306,7 +280,7 @@ SupportedMaskOr (
   UINT8  *Data1;
   UINT8  *Data2;
 
-  BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
+  BitMaskSize = PcdGetSize (PcdCpuFeaturesSetting);
   Data1 = SupportedFeatureMask;
   Data2 = OrFeatureBitMask;
   for (Index = 0; Index < BitMaskSize; Index++) {
@@ -331,7 +305,7 @@ SupportedMaskAnd (
   UINT8  *Data1;
   UINT8  *Data2;
 
-  BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
+  BitMaskSize = PcdGetSize (PcdCpuFeaturesSetting);
   Data1 = SupportedFeatureMask;
   Data2 = AndFeatureBitMask;
   for (Index = 0; Index < BitMaskSize; Index++) {
@@ -356,7 +330,7 @@ SupportedMaskCleanBit (
   UINT8  *Data1;
   UINT8  *Data2;
 
-  BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
+  BitMaskSize = PcdGetSize (PcdCpuFeaturesSetting);
   Data1 = SupportedFeatureMask;
   Data2 = AndFeatureBitMask;
   for (Index = 0; Index < BitMaskSize; Index++) {
@@ -387,7 +361,7 @@ IsBitMaskMatch (
   UINT8  *Data1;
   UINT8  *Data2;
 
-  BitMaskSize = PcdGetSize (PcdCpuFeaturesSupport);
+  BitMaskSize = PcdGetSize (PcdCpuFeaturesSetting);
 
   Data1 = SupportedFeatureMask;
   Data2 = ComparedFeatureBitMask;
@@ -426,22 +400,22 @@ CollectProcessorData (
   Entry = GetFirstNode (>FeatureList);
   while (!IsNull (>FeatureList, Entry)) {
 CpuFeature = CPU_FEATURE_ENTRY_FROM_LINK (Entry);
-if (IsBitMaskMatch (CpuFeaturesData->SupportPcd, CpuFeature->FeatureMask)) 
{
-  if (CpuFeature->SupportFunc == NULL) {
-//
-// If SupportFunc is NULL, then the feature is supported.
-//
-SupportedMaskOr (
-  CpuFeaturesData->InitOrder[ProcessorNumber].FeaturesSupportedMask,
-  CpuFeature->FeatureMask
-  );
-  } else if (CpuFeature->SupportFunc (ProcessorNumber, CpuInfo, 
CpuFeature->ConfigData)) {
-SupportedMaskOr (
-  CpuFeaturesData->InitOrder[ProcessorNumber].FeaturesSupportedMask,
-  CpuFeature->FeatureMask
-  );
-  }
+
+if (CpuFeature->SupportFunc == NULL) {
+  //
+  // If SupportFunc is NULL, then the feature is supported.
+  //
+  SupportedMaskOr (
+CpuFeaturesData->InitOrder[ProcessorNumber].FeaturesSupportedMask,
+CpuFeature->FeatureMask
+);
+} else if (CpuFeature->SupportFunc (ProcessorNumber, CpuInfo, 
CpuFeature->ConfigData)) {
+  SupportedMaskOr (
+CpuFeaturesData->InitOrder[ProcessorNumber].FeaturesSupportedMask,
+CpuFeature->FeatureMask
+);
 }
+
 Entry = Entry->ForwardLink;
   }
 }
@@ -646,8 +620,6 @@ AnalysisProcessorFeatures (
   DumpCpuFeature (CpuFeature);
   Entry = Entry->ForwardLink;
 }
-DEBUG ((DEBUG_INFO, "PcdCpuFeaturesSupport:\n"));
-

[edk2] [Patch 1/3] UefiCpuPkg/RegisterCpuFeaturesLib: Remove useless functions.

2019-02-12 Thread Eric Dong
Remove useless APIs, simply the code logic.

BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1375

Cc: Ray Ni 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
---
 .../Include/Library/RegisterCpuFeaturesLib.h   | 34 ---
 .../RegisterCpuFeaturesLib.c   | 50 --
 2 files changed, 84 deletions(-)

diff --git a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h 
b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
index 2f7e71c833..073f020d0b 100644
--- a/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
+++ b/UefiCpuPkg/Include/Library/RegisterCpuFeaturesLib.h
@@ -166,40 +166,6 @@ IsCpuFeatureInSetting (
   IN UINT32  Feature
   );
 
-/**
-  Determines if a CPU feature is set in PcdCpuFeaturesCapability bit mask.
-
-  @param[in]  Feature  The bit number of the CPU feature to check in the PCD
-   PcdCpuFeaturesCapability.
-
-  @retval  TRUE   The CPU feature is set in PcdCpuFeaturesCapability.
-  @retval  FALSE  The CPU feature is not set in PcdCpuFeaturesCapability.
-
-  @note This service could be called by BSP only.
-**/
-BOOLEAN
-EFIAPI
-IsCpuFeatureCapability (
-  IN UINT32  Feature
-  );
-
-/**
-  Determines if a CPU feature is set in PcdCpuFeaturesUserConfiguration bit 
mask.
-
-  @param[in]  Feature  The bit number of the CPU feature to check in the PCD
-   PcdCpuFeaturesUserConfiguration.
-
-  @retval  TRUE   The CPU feature is set in PcdCpuFeaturesUserConfiguration.
-  @retval  FALSE  The CPU feature is not set in 
PcdCpuFeaturesUserConfiguration.
-
-  @note This service could be called by BSP only.
-**/
-BOOLEAN
-EFIAPI
-IsCpuFeatureUserConfiguration (
-  IN UINT32  Feature
-  );
-
 /**
   Prepares for the data used by CPU feature detection and initialization.
 
diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
index ed8d526325..3540029079 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeaturesLib.c
@@ -1242,56 +1242,6 @@ IsCpuFeatureInSetting (
);
 }
 
-/**
-  Determines if a CPU feature is set in PcdCpuFeaturesCapability bit mask.
-
-  @param[in]  Feature  The bit number of the CPU feature to check in the PCD
-   PcdCpuFeaturesCapability
-
-  @retval  TRUE   The CPU feature is set in PcdCpuFeaturesCapability.
-  @retval  FALSE  The CPU feature is not set in PcdCpuFeaturesCapability.
-
-  @note This service could be called by BSP only.
-**/
-BOOLEAN
-EFIAPI
-IsCpuFeatureCapability (
-  IN UINT32  Feature
-  )
-{
-  return IsCpuFeatureSetInCpuPcd (
-   (UINT8 *)PcdGetPtr (PcdCpuFeaturesCapability),
-   PcdGetSize (PcdCpuFeaturesCapability),
-   Feature
-   );
-
-}
-
-/**
-  Determines if a CPU feature is set in PcdCpuFeaturesUserConfiguration bit 
mask.
-
-  @param[in]  Feature  The bit number of the CPU feature to check in the PCD
-   PcdCpuFeaturesUserConfiguration
-
-  @retval  TRUE   The CPU feature is set in PcdCpuFeaturesUserConfiguration.
-  @retval  FALSE  The CPU feature is not set in 
PcdCpuFeaturesUserConfiguration.
-
-  @note This service could be called by BSP only.
-**/
-BOOLEAN
-EFIAPI
-IsCpuFeatureUserConfiguration (
-  IN UINT32  Feature
-  )
-{
-  return IsCpuFeatureSetInCpuPcd (
-   (UINT8 *)PcdGetPtr (PcdCpuFeaturesUserConfiguration),
-   PcdGetSize (PcdCpuFeaturesUserConfiguration),
-   Feature
-   );
-
-}
-
 /**
   Switches to assigned BSP after CPU features initialization.
 
-- 
2.15.0.windows.1

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


[edk2] [Patch 2/3] UefiCpuPkg/RegisterCpuFeaturesLib: Optimize PCD PcdCpuFeaturesUserConfiguration.

2019-02-12 Thread Eric Dong
In current implementation, PCD PcdCpuFeaturesUserConfiguration used as
user enabled CPU features list. It is initialzied in platform driver
and as an input for CpuFeatures driver. PCD PcdCpuFeaturesSetting used
as an output for the final enabled CPU features list. For now,
PcdCpuFeaturesUserConfiguration is only used as an input and
PcdCpuFeaturesSetting only used as an output.

This change merge PcdCpuFeaturesUserConfiguration into
PcdCpuFeaturesSetting.
Use PcdCpuFeaturesSetting as input for the user input feature setting
Use PcdCpuFeaturesSetting as output for the final CPU feature setting

BZ:https://bugzilla.tianocore.org/show_bug.cgi?id=1375

Cc: Ray Ni 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong 
---
 .../RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 37 --
 .../DxeRegisterCpuFeaturesLib.inf  |  1 -
 .../PeiRegisterCpuFeaturesLib.inf  |  1 -
 .../RegisterCpuFeaturesLib/RegisterCpuFeatures.h   |  1 -
 UefiCpuPkg/UefiCpuPkg.dec  |  7 ++--
 5 files changed, 22 insertions(+), 25 deletions(-)

diff --git a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
index bae92b89a6..4ebd0025b4 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/CpuFeaturesInitialize.c
@@ -54,41 +54,41 @@ SetSettingPcd (
 }
 
 /**
-  Worker function to get PcdCpuFeaturesSupport.
+  Worker function to get PcdCpuFeaturesSetting.
 
   @return  The pointer to CPU feature bits mask buffer.
 **/
 UINT8 *
-GetSupportPcd (
+GetSettingPcd (
   VOID
   )
 {
-  UINT8  *SupportBitMask;
+  UINT8  *SettingBitMask;
 
-  SupportBitMask = AllocateCopyPool (
-  PcdGetSize (PcdCpuFeaturesSupport),
-  PcdGetPtr (PcdCpuFeaturesSupport)
+  SettingBitMask = AllocateCopyPool (
+  PcdGetSize (PcdCpuFeaturesSetting),
+  PcdGetPtr (PcdCpuFeaturesSetting)
   );
-  ASSERT (SupportBitMask != NULL);
+  ASSERT (SettingBitMask != NULL);
 
-  return SupportBitMask;
+  return SettingBitMask;
 }
 
 /**
-  Worker function to get PcdCpuFeaturesUserConfiguration.
+  Worker function to get PcdCpuFeaturesSupport.
 
   @return  The pointer to CPU feature bits mask buffer.
 **/
 UINT8 *
-GetConfigurationPcd (
+GetSupportPcd (
   VOID
   )
 {
   UINT8  *SupportBitMask;
 
   SupportBitMask = AllocateCopyPool (
-  PcdGetSize (PcdCpuFeaturesUserConfiguration),
-  PcdGetPtr (PcdCpuFeaturesUserConfiguration)
+  PcdGetSize (PcdCpuFeaturesSupport),
+  PcdGetPtr (PcdCpuFeaturesSupport)
   );
   ASSERT (SupportBitMask != NULL);
 
@@ -287,7 +287,6 @@ CpuInitDataInitialize (
   // Get support and configuration PCDs
   //
   CpuFeaturesData->SupportPcd   = GetSupportPcd ();
-  CpuFeaturesData->ConfigurationPcd = GetConfigurationPcd ();
 }
 
 /**
@@ -595,6 +594,9 @@ AnalysisProcessorFeatures (
   CPU_FEATURE_DEPENDENCE_TYPE  AfterDep;
   CPU_FEATURE_DEPENDENCE_TYPE  NoneNeibBeforeDep;
   CPU_FEATURE_DEPENDENCE_TYPE  NoneNeibAfterDep;
+  UINT8*ConfigurationPcd;
+
+  ConfigurationPcd = NULL;
 
   CpuFeaturesData = GetCpuFeaturesData ();
   CpuFeaturesData->CapabilityPcd = AllocatePool (CpuFeaturesData->BitMaskSize);
@@ -610,10 +612,13 @@ AnalysisProcessorFeatures (
   //
   // Calculate the last setting
   //
-
   CpuFeaturesData->SettingPcd = AllocateCopyPool 
(CpuFeaturesData->BitMaskSize, CpuFeaturesData->CapabilityPcd);
   ASSERT (CpuFeaturesData->SettingPcd != NULL);
-  SupportedMaskAnd (CpuFeaturesData->SettingPcd, 
CpuFeaturesData->ConfigurationPcd);
+  ConfigurationPcd = GetSettingPcd ();
+  SupportedMaskAnd (CpuFeaturesData->SettingPcd, ConfigurationPcd);
+  if (ConfigurationPcd != NULL) {
+FreePool (ConfigurationPcd);
+  }
 
   //
   // Save PCDs and display CPU PCDs
@@ -643,8 +648,6 @@ AnalysisProcessorFeatures (
 }
 DEBUG ((DEBUG_INFO, "PcdCpuFeaturesSupport:\n"));
 DumpCpuFeatureMask (CpuFeaturesData->SupportPcd);
-DEBUG ((DEBUG_INFO, "PcdCpuFeaturesUserConfiguration:\n"));
-DumpCpuFeatureMask (CpuFeaturesData->ConfigurationPcd);
 DEBUG ((DEBUG_INFO, "PcdCpuFeaturesCapability:\n"));
 DumpCpuFeatureMask (CpuFeaturesData->CapabilityPcd);
 DEBUG ((DEBUG_INFO, "PcdCpuFeaturesSetting:\n"));
diff --git 
a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.inf 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.inf
index 362e0c6cd1..b7dc70808f 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.inf
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/DxeRegisterCpuFeaturesLib.inf
@@ -56,7 +56,6 @@
 [Pcd]
   gUefiCpuPkgTokenSpaceGuid.PcdCpuS3DataAddress## 
CONSUMES
   

[edk2] [Patch 0/3] Simplify CPU Features solution.

2019-02-12 Thread Eric Dong
Changes includes:
1. Optimize PCD PcdCpuFeaturesUserConfiguration
2. Limit useage of PcdCpuFeaturesSupport
3. Remove some useless APIs.
Detail explanation please check each patch's introduction.

Cc: Ray Ni 
Cc: Laszlo Ersek 

Eric Dong (3):
  UefiCpuPkg/RegisterCpuFeaturesLib: Remove useless functions.
  UefiCpuPkg/RegisterCpuFeaturesLib: Optimize PCD 
PcdCpuFeaturesUserConfiguration.
  UefiCpuPkg/RegisterCpuFeaturesLib: Simplify PcdCpuFeaturesSupport.

 .../Include/Library/RegisterCpuFeaturesLib.h   | 34 
 .../RegisterCpuFeaturesLib/CpuFeaturesInitialize.c | 95 --
 .../DxeRegisterCpuFeaturesLib.inf  |  1 -
 .../PeiRegisterCpuFeaturesLib.inf  |  1 -
 .../RegisterCpuFeaturesLib/RegisterCpuFeatures.h   |  2 -
 .../RegisterCpuFeaturesLib.c   | 60 ++
 UefiCpuPkg/UefiCpuPkg.dec  |  7 +-
 7 files changed, 42 insertions(+), 158 deletions(-)

-- 
2.15.0.windows.1

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


Re: [edk2] [PATCH v3 07/10] OvmfPkg/README: Remove UNIXGCC

2019-02-12 Thread Laszlo Ersek
Hi,

On 02/13/19 02:42, Shenglei Zhang wrote:
> Remove UNIXGCC in OvmfPkgIa32.dsc, OvmfPkgIa32X64.dsc
> and OvmfPkgX64.dsc.
> Remove content related to UNIXGCC in README.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1377
> 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Cc: Anthony Perard 
> Cc: Julien Grall 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang 
> Reviewed-by: Laszlo Ersek 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc|  1 -
>  OvmfPkg/OvmfPkgIa32X64.dsc |  1 -
>  OvmfPkg/OvmfPkgX64.dsc |  1 -
>  OvmfPkg/README | 19 ---
>  4 files changed, 22 deletions(-)

You forgot to pick up Ard's Acked-by:

  [edk2] [PATCH v2 05/10] OvmfPkg/README: Remove UNIXGCC
  https://lists.01.org/pipermail/edk2-devel/2019-February/036486.html

Please amend the commit message before pushing the series.

Thanks
Laszlo

> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index 2b642ab5dc..f9216af479 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -62,7 +62,6 @@
>  !endif
>  
>  [BuildOptions]
> -  GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
>GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
>INTEL:RELEASE_*_*_CC_FLAGS   = /D MDEPKG_NDEBUG
>MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 14a5c1bb29..1e470de744 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -62,7 +62,6 @@
>  !endif
>  
>  [BuildOptions]
> -  GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
>GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
>INTEL:RELEASE_*_*_CC_FLAGS   = /D MDEPKG_NDEBUG
>MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index aa7197f533..e4929d8cf4 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -62,7 +62,6 @@
>  !endif
>  
>  [BuildOptions]
> -  GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
>GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
>INTEL:RELEASE_*_*_CC_FLAGS   = /D MDEPKG_NDEBUG
>MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
> diff --git a/OvmfPkg/README b/OvmfPkg/README
> index 68ce0750af..c014d07bfb 100644
> --- a/OvmfPkg/README
> +++ b/OvmfPkg/README
> @@ -402,25 +402,6 @@ main firmware (MAINFV) into RAM memory at address 
> 0x80. The
>  remaining OVMF firmware then uses this decompressed firmware
>  volume image.
>  
> -=== UNIXGCC Debug ===
> -
> -If you build with the UNIXGCC toolchain, then debugging will be disabled
> -due to larger image sizes being produced by the UNIXGCC toolchain. The
> -first choice recommendation is to use GCC48 or newer instead.
> -
> -If you must use UNIXGCC, then you can override the build options for
> -particular libraries and modules in the .dsc to re-enable debugging
> -selectively. For example:
> -  [Components]
> -  OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf {
> -
> -  GCC:*_*_*_CC_FLAGS = -UMDEPKG_NDEBUG
> -  }
> -  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
> -
> -  GCC:*_*_*_CC_FLAGS = -UMDEPKG_NDEBUG
> -  }
> -
>  === UEFI Windows 7 & Windows 2008 Server ===
>  
>  * One of the '-vga std' and '-vga qxl' QEMU options should be used.
> 

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


[edk2] [PATCH v3 10/10] BaseTools/build_rule.template: Remove GCCLD

2019-02-12 Thread Shenglei Zhang
GCCLD will be unused when UNIXGCC, CYGGCC and ELFGCC
are removed.
https://bugzilla.tianocore.org/show_bug.cgi?id=1377

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 BaseTools/Conf/build_rule.template | 33 --
 1 file changed, 13 insertions(+), 20 deletions(-)

diff --git a/BaseTools/Conf/build_rule.template 
b/BaseTools/Conf/build_rule.template
index 2a53d7ed63..3009310233 100755
--- a/BaseTools/Conf/build_rule.template
+++ b/BaseTools/Conf/build_rule.template
@@ -131,7 +131,7 @@
 
 "$(CC)" /Fo${dst} $(CC_FLAGS) $(INC) ${src}
 
-
+
 # For RVCTCYGWIN CC_FLAGS must be first to work around pathing issues
 "$(CC)" $(CC_FLAGS) -c -o ${dst} $(INC) ${src}
 
@@ -148,7 +148,7 @@
 
 $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
 
-
+
 "$(CC)" $(CC_FLAGS) $(CC_XIPFLAGS) -c -o ${dst} $(INC) ${src}
 
 [C-Header-File]
@@ -163,7 +163,7 @@
 
 ?.asm, ?.Asm, ?.ASM
 
-
+
 ?.S, ?.s
 
 
@@ -177,7 +177,7 @@
 Trim --source-code --convert-hex --trim-long -o 
${d_path}(+)${s_base}.iii ${d_path}(+)${s_base}.i
 "$(ASM)" /Fo${dst} $(ASM_FLAGS) /I${s_path} $(INC) 
${d_path}(+)${s_base}.iii
 
-
+
 "$(PP)" $(PP_FLAGS) $(INC) ${src} > ${d_path}(+)${s_base}.i
 Trim --trim-long --source-code -o ${d_path}(+)${s_base}.iii 
${d_path}(+)${s_base}.i
 # For RVCTCYGWIN ASM_FLAGS must be first to work around pathing issues
@@ -188,7 +188,7 @@
 
 ?.asm, ?.Asm, ?.ASM
 
-
+
 ?.S, ?.s
 
 
@@ -207,7 +207,7 @@
 Trim --source-code --trim-long -o ${d_path}(+)${s_base}.iii 
${d_path}(+)${s_base}.i
 "$(ASM)" /Fo${dst} $(ASM_FLAGS) /I${s_path} $(INC) 
${d_path}(+)${s_base}.iii
 
-
+
 "$(PP)" $(PP_FLAGS) $(INC) ${src} > ${d_path}(+)${s_base}.i
 Trim --trim-long --source-code -o ${d_path}(+)${s_base}.iii 
${d_path}(+)${s_base}.i
 # For RVCTCYGWIN ASM_FLAGS must be first to work around pathing issues
@@ -269,7 +269,7 @@
 
 "$(SLINK)" $(SLINK_FLAGS) /OUT:${dst} @$(OBJECT_FILES_LIST)
 
-
+
 $(RM) ${dst}
 "$(SLINK)" cr ${dst} $(SLINK_FLAGS) @$(OBJECT_FILES_LIST)
 
@@ -301,10 +301,6 @@
 "$(DLINK)" -o ${dst} $(DLINK_FLAGS) 
-Wl,--start-group,@$(STATIC_LIBRARY_FILES_LIST),--end-group $(CC_FLAGS) 
$(DLINK2_FLAGS)
 "$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
 
-
-"$(DLINK)" -o ${dst} $(DLINK_FLAGS) --start-group $(DLINK_SPATH) 
@$(STATIC_LIBRARY_FILES_LIST) --end-group $(DLINK2_FLAGS)
-"$(OBJCOPY)" $(OBJCOPY_FLAGS) ${dst}
-
 
 "$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) --via 
$(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
 
@@ -347,9 +343,6 @@
 
 "$(DLINK)" $(DLINK_FLAGS) 
-Wl,--start-group,@$(STATIC_LIBRARY_FILES_LIST),--end-group $(DLINK2_FLAGS)
 
-
-"$(DLINK)" $(DLINK_FLAGS) --start-group $(DLINK_SPATH) 
@$(STATIC_LIBRARY_FILES_LIST) --end-group $(DLINK2_FLAGS)
-
 
 "$(DLINK)" $(DLINK_FLAGS) -o ${dst} $(DLINK_SPATH) --via 
$(STATIC_LIBRARY_FILES_LIST) $(DLINK2_FLAGS)
 
@@ -374,7 +367,7 @@
 $(CP) ${dst} $(BIN_DIR)(+)$(MODULE_NAME_GUID).efi
 -$(CP) $(DEBUG_DIR)(+)*.map $(OUTPUT_DIR)
 -$(CP) $(DEBUG_DIR)(+)*.pdb $(OUTPUT_DIR) 
-
+
 $(CP) ${src} $(DEBUG_DIR)(+)$(MODULE_NAME).debug
 $(OBJCOPY) --strip-unneeded -R .eh_frame ${src}
 
@@ -430,7 +423,7 @@
 Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}. 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii 
 "$(ASL)" $(ASL_FLAGS) $(ASL_OUTFLAGS)${dst} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.
 
-
+
 Trim --asl-file -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i -i 
$(INC_LIST) ${src}
 "$(ASLPP)" $(ASLPP_FLAGS) $(INC) -I${s_path} 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.i > 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii
 Trim --source-code -l -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}. 
$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.iii 
@@ -451,7 +444,7 @@
 "$(ASLDLINK)" /OUT:$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
$(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
 "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
$(GENFW_FLAGS)
 
-
+
 "$(ASLCC)" -c -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj $(CC_FLAGS) 
$(ASLCC_FLAGS) $(INC) ${src}
 "$(ASLDLINK)" -o $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
$(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
 "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
$(GENFW_FLAGS)
@@ -471,7 +464,7 @@
 "$(ASLDLINK)" /OUT:$(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
$(ASLDLINK_FLAGS) $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.obj
 "$(GENFW)" -o ${dst} -c $(OUTPUT_DIR)(+)${s_dir}(+)${s_base}.dll 
$(GENFW_FLAGS)
 
-
+
 "$(ASLCC)" -c -o 

[edk2] [PATCH v3 06/10] BaseTools/tools_def.template: Remove UNIXGCC

2019-02-12 Thread Shenglei Zhang
UNIXGCC is too old.There is no verification for it.
https://bugzilla.tianocore.org/show_bug.cgi?id=1377

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
Reviewed-by: Laszlo Ersek 
---
 BaseTools/Conf/tools_def.template | 96 ---
 1 file changed, 96 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index ade6224139..f1ada594b4 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -147,29 +147,6 @@ DEFINE EBC_BINx86   = C:\Program Files 
(x86)\Intel\EBC\Bin
 
 DEFINE ELFGCC_BIN   = /usr/bin
 
-#
-# Option 1: Hard coded full path to compiler suite
-DEFINE UNIXGCC_IA32_PETOOLS_PREFIX = 
/opt/tiano/i386-tiano-pe/i386-tiano-pe/bin/
-DEFINE UNIXGCC_X64_PETOOLS_PREFIX  = 
/opt/tiano/x86_64-pc-mingw64/x86_64-pc-mingw64/bin/
-#
-# Option 2: Use an environment variable
-#DEFINE UNIXGCC_IA32_PETOOLS_PREFIX = ENV(IA32_PETOOLS_PREFIX)
-#DEFINE UNIXGCC_X64_PETOOLS_PREFIX  = ENV(X64_PETOOLS_PREFIX)
-#
-# Option 3: Install the compiler suite into your default paths
-#DEFINE UNIXGCC_IA32_PETOOLS_PREFIX = i386-pc-mingw32-
-#DEFINE UNIXGCC_X64_PETOOLS_PREFIX  = x86_64-pc-mingw32-
-#
-# Option 4: Create links under the BaseTools/Bin/gcc/ARCH directory
-# Links needed: gcc, ar & ld
-#DEFINE UNIXGCC_IA32_PETOOLS_PREFIX = ENV(WORKSPACE)/BaseTools/Bin/gcc/Ia32/
-#DEFINE UNIXGCC_X64_PETOOLS_PREFIX  = ENV(WORKSPACE)/BaseTools/Bin/gcc/X64/
-#
-# Option 5: Install programs under user's home directory
-#DEFINE UNIXGCC_IA32_PETOOLS_PREFIX = 
ENV(HOME)/programs/gcc/ia32/bin/i686-pc-mingw32-
-#DEFINE UNIXGCC_X64_PETOOLS_PREFIX  = 
ENV(HOME)/programs/gcc/x64/bin/x86_64-pc-mingw32-
-#
-
 DEFINE CYGWIN_BIN  = c:/cygwin/bin
 DEFINE CYGWIN_BINIA32  = 
c:/cygwin/opt/tiano/i386-tiano-pe/i386-tiano-pe/bin/
 DEFINE CYGWIN_BINX64   = 
c:/cygwin/opt/tiano/x86_64-pc-mingw64/x86_64-pc-mingw64/bin/
@@ -305,13 +282,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 # Required to build platforms or ACPI tables:
 #   Intel(r) ACPI Compiler (iasl.exe) from
 #   https://acpica.org/downloads
-#   UNIXGCC -UNIX-   Requires:
-# GCC 4.3.0
-# binutils 2.20.51.0.5
-#Optional:
-# Required to build platforms or ACPI tables:
-#   Intel(r) ACPI Compiler from
-#   https://acpica.org/downloads
 #   GCC48   -Linux,Windows-  Requires:
 # GCC 4.8 targeting x86_64-linux-gnu, 
aarch64-linux-gnu, or arm-linux-gnueabi
 #Optional:
@@ -3479,72 +3449,6 @@ DEFINE GCC5_ARM_ASLDLINK_FLAGS   = 
DEF(GCC49_ARM_ASLDLINK_FLAGS)
 DEFINE GCC5_AARCH64_ASLDLINK_FLAGS   = DEF(GCC49_AARCH64_ASLDLINK_FLAGS)
 DEFINE GCC5_ASLCC_FLAGS  = DEF(GCC49_ASLCC_FLAGS) -fno-lto
 
-
-#
-# Unix GCC And Intel Linux ACPI Compiler
-#
-
-#   UNIXGCC - UNIX GCC
-#   ASL - Intel Linux ACPI Source Language Compiler (iasl)
-*_UNIXGCC_*_*_FAMILY   = GCC
-*_UNIXGCC_*_*_BUILDRULEFAMILY  = GCCLD
-
-*_UNIXGCC_*_MAKE_PATH= make
-*_UNIXGCC_*_ASL_PATH = DEF(UNIX_IASL_BIN)
-
-*_UNIXGCC_IA32_DLINK_FLAGS   = DEF(GCC_IA32_X64_DLINK_FLAGS) 
--image-base=0
-*_UNIXGCC_X64_DLINK_FLAGS= DEF(GCC_IA32_X64_DLINK_FLAGS) 
--image-base=0
-*_UNIXGCC_IA32_ASLDLINK_FLAGS= DEF(GCC_IA32_X64_ASLDLINK_FLAGS)
-*_UNIXGCC_X64_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_ASLDLINK_FLAGS)
-*_UNIXGCC_*_ASM_FLAGS= DEF(GCC_ASM_FLAGS)
-*_UNIXGCC_*_PP_FLAGS = DEF(GCC_PP_FLAGS)
-*_UNIXGCC_*_ASLPP_FLAGS  = DEF(GCC_ASLPP_FLAGS)
-*_UNIXGCC_*_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS)
-*_UNIXGCC_*_VFRPP_FLAGS  = DEF(GCC_VFRPP_FLAGS)
-*_UNIXGCC_*_APP_FLAGS=
-*_UNIXGCC_*_ASL_FLAGS= DEF(IASL_FLAGS)
-*_UNIXGCC_*_ASL_OUTFLAGS = DEF(IASL_OUTFLAGS)
-
-##
-# IA32 definitions
-##
-*_UNIXGCC_IA32_OBJCOPY_PATH = DEF(UNIXGCC_IA32_PETOOLS_PREFIX)objcopy
-*_UNIXGCC_IA32_PP_PATH  = DEF(UNIXGCC_IA32_PETOOLS_PREFIX)gcc
-*_UNIXGCC_IA32_CC_PATH  = DEF(UNIXGCC_IA32_PETOOLS_PREFIX)gcc
-*_UNIXGCC_IA32_SLINK_PATH   = DEF(UNIXGCC_IA32_PETOOLS_PREFIX)ar
-*_UNIXGCC_IA32_DLINK_PATH   = DEF(UNIXGCC_IA32_PETOOLS_PREFIX)ld
-*_UNIXGCC_IA32_ASLPP_PATH   = DEF(UNIXGCC_IA32_PETOOLS_PREFIX)gcc
-*_UNIXGCC_IA32_ASLCC_PATH   = 

[edk2] [PATCH v3 09/10] BaseTools/tools_def.template: Remove DDK3790

2019-02-12 Thread Shenglei Zhang
DDK3790 is too old.There is no verification for it.
https://bugzilla.tianocore.org/show_bug.cgi?id=1377

v3:Reserve WINDDK_BIN32 and WINDDK_BIN64.

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 BaseTools/Conf/tools_def.template | 233 --
 1 file changed, 233 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 21efe4e593..c9ed2a33ef 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -101,9 +101,7 @@ DEFINE MS_VS_BIN   = DEF(VS2008_BIN)
 DEFINE MS_VS_DLL   = DEF(VS2008_DLL)
 
 DEFINE WINDDK_BIN16 = ENV(WINDDK3790_PREFIX)bin16
-DEFINE WINDDK_BIN32 = ENV(WINDDK3790_PREFIX)x86
 DEFINE WINDDK_BINX64= ENV(WINDDK3790_PREFIX)win64\x86\amd64
-DEFINE WINDDK_BIN64 = ENV(WINDDK3790_PREFIX)win64\x86
 
 # NOTE: The Intel C++ Compiler for Windows requires one of the Microsoft C 
compiler
 #tool chains for the linker and nmake commands.
@@ -273,14 +271,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 #Note:
 # Building of XIP firmware images for ARM/ARM64 is 
not currently supported (only applications).
 # /FILEALIGN:4096 and other changes are needed for 
ARM firmware builds.
-#   DDK3790 -win32-  Requires:
-# Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Intel(r) ACPI Compiler (iasl.exe) from
-#   https://acpica.org/downloads
 #   GCC48   -Linux,Windows-  Requires:
 # GCC 4.8 targeting x86_64-linux-gnu, 
aarch64-linux-gnu, or arm-linux-gnueabi
 #Optional:
@@ -381,14 +371,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 # Required to build platforms or ACPI tables:
 #   Microsoft ASL ACPI Compiler (asl.exe) v4.0.0 
from
 #   
http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi
-#   DDK3790xASL -win32-  Requires:
-# Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Microsoft ASL ACPI Compiler (asl.exe) v4.0.0 
from
-#   
http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi
 #   CYGGCCxASL  -win32-  Requires:
 # CygWin, GCC 4.3.0, binutils 2.20.51.0.5
 # Microsoft Visual Studio 2005 or 2008
@@ -3112,221 +3094,6 @@ NOOPT_VS2017_AARCH64_DLINK_FLAGS   = /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:REF
 *_VS2017_EBC_SLINK_FLAGS = /lib /NOLOGO /MACHINE:EBC
 *_VS2017_EBC_DLINK_FLAGS = "C:\Program Files 
(x86)\Intel\EBC\Lib\EbcLib.lib" /NOLOGO /NODEFAULTLIB /MACHINE:EBC /OPT:REF 
/ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /MAP /ALIGN:32 
/DRIVER
 
-
-#
-# Microsoft Device Driver Kit 3790.1830 (IA-32, X64, Itanium, with Link Time 
Code Generation)
-# And Intel ACPI Compiler
-#
-
-#   DDK3790  - Microsoft Windows DDK 3790.1830
-#   ASL  - Intel ACPI Source Language Compiler (iasl.exe)
-*_DDK3790_*_*_FAMILY= MSFT
-
-*_DDK3790_*_*_DLL   = DEF(WINDDK_BIN32)
-*_DDK3790_*_MAKE_PATH   = DEF(WINDDK_BIN32)\nmake.exe
-*_DDK3790_*_MAKE_FLAGS   = /nologo
-*_DDK3790_*_RC_PATH = DEF(WINDDK_BIN32)\rc.exe
-
-*_DDK3790_*_PP_FLAGS = /nologo /E /TC /FIAutoGen.h
-*_DDK3790_*_APP_FLAGS= /nologo /E /TC
-*_DDK3790_*_SLINK_FLAGS  = /nologo /LTCG
-*_DDK3790_*_VFRPP_FLAGS  = /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h
-
-*_DDK3790_*_ASM16_PATH  = DEF(WINDDK_BIN32)\ml.exe
-
-##
-# ASL definitions
-##
-*_DDK3790_*_ASL_PATH= DEF(DEFAULT_WIN_ASL_BIN)
-*_DDK3790_*_ASL_FLAGS   = DEF(DEFAULT_WIN_ASL_FLAGS)
-*_DDK3790_*_ASL_OUTFLAGS= DEF(DEFAULT_WIN_ASL_OUTFLAGS)
-*_DDK3790_*_ASLCC_FLAGS = 

[edk2] [PATCH v3 04/10] BaseTools/tools_def.template: Remove VS2003 and VS2005

2019-02-12 Thread Shenglei Zhang
VS2003 and VS2005 are too old.There is no verification
for them.
https://bugzilla.tianocore.org/show_bug.cgi?id=1377

v3:1.Instead of removing MS_VS_BIN, change MS_VS_BIN from
 VS2005_BIN to VS2008_BIN.
   2.Instead of removing MS_VS_DLL, change MS_VS_DLL from
 VS2005_DLL to VS2008_DLL.

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 BaseTools/Conf/tools_def.template | 689 --
 1 file changed, 689 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 8ed9abd2c9..ade6224139 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -17,19 +17,6 @@
 IDENTIFIER = Default TOOL_CHAIN_CONF
 
 # common path macros
-DEFINE VS2003_BIN   = ENV(VS2003_PREFIX)Vc7\bin
-DEFINE VS2003_DLL   = ENV(VS2003_PREFIX)Common7\IDE
-
-DEFINE VS2005_BIN   = ENV(VS2005_PREFIX)Vc\bin
-DEFINE VS2005_DLL   = ENV(VS2005_PREFIX)Common7\IDE;DEF(VS2005_BIN)
-DEFINE VS2005_BINX64= DEF(VS2005_BIN)\x86_amd64
-DEFINE VS2005_BIN64 = DEF(VS2005_BIN)\x86_ia64
-
-DEFINE VS2005x86_BIN= ENV(VS2005_PREFIX)Vc\bin
-DEFINE VS2005x86_DLL= ENV(VS2005_PREFIX)Common7\IDE;DEF(VS2005x86_BIN)
-DEFINE VS2005x86_BINX64 = DEF(VS2005x86_BIN)\x86_amd64
-DEFINE VS2005x86_BIN64  = DEF(VS2005x86_BIN)\x86_ia64
-
 DEFINE VS2008_BIN  = ENV(VS2008_PREFIX)Vc\bin
 DEFINE VS2008_DLL  = ENV(VS2008_PREFIX)Common7\IDE;DEF(VS2008_BIN)
 DEFINE VS2008_BINX64   = DEF(VS2008_BIN)\x86_amd64
@@ -254,24 +241,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 #
 # Supported Tool Chains
 # =
-#   VS2003  -win32-  Requires:
-# Microsoft Visual Studio .NET 2003
-# Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Intel(r) ACPI Compiler (iasl.exe) from
-#   https://acpica.org/downloads
-#   VS2005  -win32-  Requires:
-# Microsoft Visual Studio 2005 Team Suite Edition
-# Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Intel(r) ACPI Compiler (iasl.exe) from
-#   https://acpica.org/downloads
 #   VS2008  -win32-  Requires:
 # Microsoft Visual Studio 2008 Team Suite Edition
 # Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
@@ -404,24 +373,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 # Required to build platforms or ACPI tables:
 #   Intel(r) ACPI Compiler (iasl.exe) from
 #   https://acpica.org/downloads
-#   VS2003xASL  -win32-  Requires:
-# Microsoft Visual Studio .NET 2003
-# Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Microsoft ASL ACPI Compiler (asl.exe) v4.0.0 
from
-#   
http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi
-#   VS2005xASL  -win32-  Requires:
-# Microsoft Visual Studio 2005 Team Suite Edition
-# Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Microsoft ASL ACPI Compiler (asl.exe) v4.0.0 
from
-#   
http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi
 #   VS2008xASL  -win32-  Requires:
 #

[edk2] [PATCH v3 07/10] OvmfPkg/README: Remove UNIXGCC

2019-02-12 Thread Shenglei Zhang
Remove UNIXGCC in OvmfPkgIa32.dsc, OvmfPkgIa32X64.dsc
and OvmfPkgX64.dsc.
Remove content related to UNIXGCC in README.
https://bugzilla.tianocore.org/show_bug.cgi?id=1377

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Anthony Perard 
Cc: Julien Grall 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/OvmfPkgIa32.dsc|  1 -
 OvmfPkg/OvmfPkgIa32X64.dsc |  1 -
 OvmfPkg/OvmfPkgX64.dsc |  1 -
 OvmfPkg/README | 19 ---
 4 files changed, 22 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 2b642ab5dc..f9216af479 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -62,7 +62,6 @@
 !endif
 
 [BuildOptions]
-  GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
   GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
   INTEL:RELEASE_*_*_CC_FLAGS   = /D MDEPKG_NDEBUG
   MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 14a5c1bb29..1e470de744 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -62,7 +62,6 @@
 !endif
 
 [BuildOptions]
-  GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
   GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
   INTEL:RELEASE_*_*_CC_FLAGS   = /D MDEPKG_NDEBUG
   MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index aa7197f533..e4929d8cf4 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -62,7 +62,6 @@
 !endif
 
 [BuildOptions]
-  GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
   GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
   INTEL:RELEASE_*_*_CC_FLAGS   = /D MDEPKG_NDEBUG
   MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
diff --git a/OvmfPkg/README b/OvmfPkg/README
index 68ce0750af..c014d07bfb 100644
--- a/OvmfPkg/README
+++ b/OvmfPkg/README
@@ -402,25 +402,6 @@ main firmware (MAINFV) into RAM memory at address 
0x80. The
 remaining OVMF firmware then uses this decompressed firmware
 volume image.
 
-=== UNIXGCC Debug ===
-
-If you build with the UNIXGCC toolchain, then debugging will be disabled
-due to larger image sizes being produced by the UNIXGCC toolchain. The
-first choice recommendation is to use GCC48 or newer instead.
-
-If you must use UNIXGCC, then you can override the build options for
-particular libraries and modules in the .dsc to re-enable debugging
-selectively. For example:
-  [Components]
-  OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf {
-
-  GCC:*_*_*_CC_FLAGS = -UMDEPKG_NDEBUG
-  }
-  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {
-
-  GCC:*_*_*_CC_FLAGS = -UMDEPKG_NDEBUG
-  }
-
 === UEFI Windows 7 & Windows 2008 Server ===
 
 * One of the '-vga std' and '-vga qxl' QEMU options should be used.
-- 
2.18.0.windows.1

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


[edk2] [PATCH v3 08/10] BaseTools/tools_def.template: Remove ELFGCC

2019-02-12 Thread Shenglei Zhang
ELFGCC is too old.There is no verification for it.
https://bugzilla.tianocore.org/show_bug.cgi?id=1377

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 BaseTools/Conf/tools_def.template | 80 ---
 1 file changed, 80 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index f1ada594b4..21efe4e593 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -145,7 +145,6 @@ DEFINE ICC11_BIN64x86 = C:\Program Files 
(x86)\Intel\Compiler\DEF(ICC11_VERS
 DEFINE EBC_BIN  = C:\Program Files\Intel\EBC\Bin
 DEFINE EBC_BINx86   = C:\Program Files (x86)\Intel\EBC\Bin
 
-DEFINE ELFGCC_BIN   = /usr/bin
 
 DEFINE CYGWIN_BIN  = c:/cygwin/bin
 DEFINE CYGWIN_BINIA32  = 
c:/cygwin/opt/tiano/i386-tiano-pe/i386-tiano-pe/bin/
@@ -313,12 +312,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 # Required to build platforms or ACPI tables:
 #   Intel(r) ACPI Compiler from
 #   https://acpica.org/downloads
-#   ELFGCC  -Linux-  Requires:
-# GCC(this tool chain uses whatever version of gcc 
and binutils that is installed in /usr/bin)
-#Optional:
-# Required to build platforms or ACPI tables:
-#   Intel(r) ACPI Compiler from
-#   https://acpica.org/downloads
 #   ICC -win32-  Requires:
 # Intel C Compiler V9.1
 #Dependencies:
@@ -4160,79 +4153,6 @@ RELEASE_CLANG38_AARCH64_CC_FLAGS= 
DEF(CLANG38_AARCH64_CC_FLAGS) $(ARCHCC_FLA
 RELEASE_CLANG38_AARCH64_DLINK_FLAGS = DEF(CLANG38_AARCH64_DLINK_FLAGS) -flto 
-Wl,-O3 -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-aarch64 
-Wl,-plugin-opt=-pass-through=-llto-aarch64
 
 
-
-#
-# Elf GCC - This configuration is used to compile on Linux boxes to produce elf
-#   binaries.
-#
-
-#   ELFGCC   - Linux ELF GCC
-*_ELFGCC_*_*_FAMILY = GCC
-*_ELFGCC_*_*_BUILDRULEFAMILY= GCCLD
-*_ELFGCC_*_MAKE_PATH= make
-
-*_ELFGCC_*_PP_FLAGS = -E -x assembler-with-cpp -include 
AutoGen.h
-*_ELFGCC_*_VFRPP_FLAGS  = -x c -E -P -DVFRCOMPILE --include 
$(MODULE_NAME)StrDefs.h
-
-##
-# ASL definitions
-##
-*_ELFGCC_*_ASL_PATH = DEF(UNIX_IASL_BIN)
-*_ELFGCC_*_ASL_FLAGS= DEF(IASL_FLAGS)
-*_ELFGCC_*_ASL_OUTFLAGS = DEF(IASL_OUTFLAGS)
-*_ELFGCC_*_ASLPP_FLAGS  = -x c -E -include AutoGen.h
-*_ELFGCC_*_ASLCC_FLAGS  = -x c
-*_ELFGCC_*_ASLDLINK_FLAGS   = DEF(GCC_DLINK_FLAGS_COMMON) --entry 
_ReferenceAcpiTable
-
-##
-# IA32 definitions
-##
-*_ELFGCC_IA32_OBJCOPY_PATH  = DEF(ELFGCC_BIN)/objcopy
-*_ELFGCC_IA32_CC_PATH   = DEF(ELFGCC_BIN)/gcc
-*_ELFGCC_IA32_SLINK_PATH= DEF(ELFGCC_BIN)/ar
-*_ELFGCC_IA32_DLINK_PATH= DEF(ELFGCC_BIN)/ld
-*_ELFGCC_IA32_ASM_PATH  = DEF(ELFGCC_BIN)/gcc
-*_ELFGCC_IA32_PP_PATH   = DEF(ELFGCC_BIN)/gcc
-*_ELFGCC_IA32_VFRPP_PATH= DEF(ELFGCC_BIN)/gcc
-*_ELFGCC_IA32_ASLCC_PATH= DEF(ELFGCC_BIN)/gcc
-*_ELFGCC_IA32_ASLPP_PATH= DEF(ELFGCC_BIN)/gcc
-*_ELFGCC_IA32_ASLDLINK_PATH = DEF(ELFGCC_BIN)/ld
-*_ELFGCC_IA32_RC_PATH   = DEF(ELFGCC_BIN)/objcopy
-
-*_ELFGCC_IA32_CC_FLAGS  = -m32 -g -fshort-wchar 
-fno-strict-aliasing -Wall -malign-double -include $(DEST_DIR_DEBUG)/AutoGen.h 
-DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
-*_ELFGCC_IA32_SLINK_FLAGS   =
-*_ELFGCC_IA32_DLINK_FLAGS   = -melf_i386 -nostdlib --shared --entry 
$(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
-#*_ELFGCC_IA32_DLINK_FLAGS  = -melf_i386 -nostdlib -n -q -Ttext 0x220 
--entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT)
-*_ELFGCC_IA32_ASM_FLAGS = -m32 -c -x assembler -imacros 
$(DEST_DIR_DEBUG)/AutoGen.h
-*_ELFGCC_IA32_PP_FLAGS  = -m32 -E -x assembler-with-cpp -include 
$(DEST_DIR_DEBUG)/AutoGen.h
-*_ELFGCC_IA32_VFRPP_FLAGS   = -x c -E -P -DVFRCOMPILE --include 
$(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h
-*_ELFGCC_IA32_RC_FLAGS  = DEF(GCC_IA32_RC_FLAGS)
-*_ELFGCC_IA32_OBJCOPY_FLAGS =
-*_ELFGCC_IA32_NASM_FLAGS= -f elf32
-
-##
-# X64 definitions
-##
-*_ELFGCC_X64_CC_PATH   = DEF(ELFGCC_BIN)/gcc
-*_ELFGCC_X64_ASLCC_PATH

[edk2] [PATCH v3 02/10] OptionRomPkg/ReadMe.txt: Remove CYGGCC

2019-02-12 Thread Shenglei Zhang
Remove CYGGCC in Build Validation.
https://bugzilla.tianocore.org/show_bug.cgi?id=1377

Cc: Ray Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
Reviewed-by: Laszlo Ersek 
---
 OptionRomPkg/ReadMe.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/OptionRomPkg/ReadMe.txt b/OptionRomPkg/ReadMe.txt
index 5eb81cb0c2..4fce87056e 100644
--- a/OptionRomPkg/ReadMe.txt
+++ b/OptionRomPkg/ReadMe.txt
@@ -15,5 +15,4 @@ CirrusLogic5430:
 Build Validation:
 MYTOOLS(VS2005) IA32 X64 IPF EBC
 ICC IA32 X64 IPF
-CYGWINGCC   IA32 X64
 
-- 
2.18.0.windows.1

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


[edk2] [PATCH v3 01/10] BaseTools/tools_def.template: Remove CYGGCC

2019-02-12 Thread Shenglei Zhang
CYGGCC is too old.There is no verification for it.
https://bugzilla.tianocore.org/show_bug.cgi?id=1377

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 BaseTools/Conf/tools_def.template | 194 --
 1 file changed, 194 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 2bd0982872..d62fe55385 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -380,15 +380,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 # Required to build platforms or ACPI tables:
 #   Intel(r) ACPI Compiler from
 #   https://acpica.org/downloads
-#   CYGGCC  -win32-  Requires:
-# CygWin, GCC 4.3.0, binutils 2.20.51.0.5
-# Microsoft Visual Studio 2005 or 2008
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Intel(r) ACPI Compiler (iasl.exe) from
-#   https://acpica.org/downloads
 #   ICC -win32-  Requires:
 # Intel C Compiler V9.1
 #Dependencies:
@@ -661,24 +652,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 # Required to build platforms or ACPI tables:
 #   Microsoft ASL ACPI Compiler (asl.exe) v4.0.0 
from
 #   
http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi
-#   CYGGCCx86   -win64-  Requires:
-# CygWin, GCC 4.3.0, binutils 2.20.51.0.5
-# Microsoft Visual Studio 2005 or 2008
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Intel(r) ACPI Compiler (iasl.exe) from
-#   https://acpica.org/downloads
-#  CYGGCCx86xASL -win64- Requires:
-# CygWin, GCC 4.3.0, binutils 2.20.51.0.5
-# Microsoft Visual Studio 2005 or 2008
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Microsoft ASL ACPI Compiler (asl.exe) v4.0.0 
from
-#   
http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi
 #   RVCT-win-   Requires:
 # ARM C/C++ Compiler, 5.00
 #Optional:
@@ -4979,173 +4952,6 @@ DEFINE CLANG38_AARCH64_DLINK_FLAGS  = 
DEF(CLANG38_AARCH64_TARGET) DEF(GCC_AARCH6
 RELEASE_CLANG38_AARCH64_CC_FLAGS= DEF(CLANG38_AARCH64_CC_FLAGS) 
$(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -flto -O3
 RELEASE_CLANG38_AARCH64_DLINK_FLAGS = DEF(CLANG38_AARCH64_DLINK_FLAGS) -flto 
-Wl,-O3 -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-aarch64 
-Wl,-plugin-opt=-pass-through=-llto-aarch64
 
-
-#
-# Cygwin GCC And Intel ACPI Compiler
-#
-
-#   CYGGCC- CygWin GCC
-#   ASL   - Intel ACPI Source Language Compiler (iasl.exe)
-*_CYGGCC_*_*_FAMILY  = GCC
-*_CYGGCC_*_*_BUILDRULEFAMILY = GCCLD
-
-*_CYGGCC_*_*_DLL = DEF(CYGWIN_BIN)
-*_CYGGCC_*_MAKE_PATH = DEF(MS_VS_BIN)\nmake.exe
-*_CYGGCC_*_ASL_PATH  = DEF(DEFAULT_WIN_ASL_BIN)
-
-*_CYGGCC_IA32_DLINK_FLAGS   = DEF(GCC_IA32_X64_DLINK_FLAGS) 
--image-base=0
-*_CYGGCC_X64_DLINK_FLAGS= DEF(GCC_IA32_X64_DLINK_FLAGS) 
--image-base=0
-*_CYGGCC_IA32_ASLDLINK_FLAGS= DEF(GCC_IA32_X64_ASLDLINK_FLAGS)
-*_CYGGCC_X64_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_ASLDLINK_FLAGS)
-*_CYGGCC_*_MAKE_FLAGS   = /nologo
-*_CYGGCC_*_ASM_FLAGS= DEF(GCC_ASM_FLAGS)
-*_CYGGCC_*_PP_FLAGS = DEF(GCC_PP_FLAGS)
-*_CYGGCC_*_ASLPP_FLAGS  = DEF(GCC_ASLPP_FLAGS)
-*_CYGGCC_*_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS)
-*_CYGGCC_*_VFRPP_FLAGS  = DEF(GCC_VFRPP_FLAGS)
-*_CYGGCC_*_APP_FLAGS  

[edk2] [PATCH v3 03/10] BaseTools: Update MYTOOLS

2019-02-12 Thread Shenglei Zhang
Remove MYTOOLS in tools_def.template and change
MYTOOLS to VS2015x86 in target.template.
https://bugzilla.tianocore.org/show_bug.cgi?id=1377

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 BaseTools/Conf/target.template|   2 +-
 BaseTools/Conf/tools_def.template | 129 +-
 2 files changed, 5 insertions(+), 126 deletions(-)

diff --git a/BaseTools/Conf/target.template b/BaseTools/Conf/target.template
index e5c31fe5a0..dc8e0f943b 100644
--- a/BaseTools/Conf/target.template
+++ b/BaseTools/Conf/target.template
@@ -57,7 +57,7 @@ TOOL_CHAIN_CONF   = Conf/tools_def.txt
 #  TAGNAME   List  Optional   Specify the name(s) of the 
tools_def.txt TagName to use.
 # If not specified, all applicable 
TagName tools will be
 # used for the build.  The list 
uses space character separation.
-TOOL_CHAIN_TAG= MYTOOLS
+TOOL_CHAIN_TAG= VS2015x86
 
 # MAX_CONCURRENT_THREAD_NUMBER  NUMBER  Optional  The number of concurrent 
threads. If not specified or set
 # to zero, tool automatically 
detect number of processor
diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index d62fe55385..8ed9abd2c9 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -108,10 +108,10 @@ DEFINE WINSDK10_BIN   = 
ENV(WINSDK10_PREFIX)DEF(VS2017_HOST)
 # are used by other toolchains.  An example is that ICC on Windows normally
 # uses Microsoft's nmake.exe.
 
-# Some MS_VS_BIN options: DEF(VS2003_BIN), DEF(VS2005_BIN), 
DEF(VS2005x86_BIN), DEF(VS2008_BIN), DEF(VS2008x86_BIN)
-DEFINE MS_VS_BIN   = DEF(VS2005_BIN)
-# Some MS_VS_DLL options: DEF(VS2003_DLL), DEF(VS2005_DLL), 
DEF(VS2005x86_DLL), DEF(VS2008_DLL), DEF(VS2008x86_DLL)
-DEFINE MS_VS_DLL   = DEF(VS2005_DLL)
+# Some MS_VS_BIN options: DEF(VS2008_BIN), DEF(VS2008x86_BIN)
+DEFINE MS_VS_BIN   = DEF(VS2008_BIN)
+# Some MS_VS_DLL options: DEF(VS2008_DLL), DEF(VS2008x86_DLL)
+DEFINE MS_VS_DLL   = DEF(VS2008_DLL)
 
 DEFINE WINDDK_BIN16 = ENV(WINDDK3790_PREFIX)bin16
 DEFINE WINDDK_BIN32 = ENV(WINDDK3790_PREFIX)x86
@@ -404,14 +404,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 # Required to build platforms or ACPI tables:
 #   Intel(r) ACPI Compiler (iasl.exe) from
 #   https://acpica.org/downloads
-#   MYTOOLS -win32-  Requires:
-# Microsoft Visual Studio 2008 for IA32/X64
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Intel(r) ACPI Compiler (iasl.exe) from
-#   https://acpica.org/downloads
 #   VS2003xASL  -win32-  Requires:
 # Microsoft Visual Studio .NET 2003
 # Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
@@ -5983,119 +5975,6 @@ NOOPT_ICC11x86xASL_X64_DLINK_FLAGS= 
/NOLOGO /NODEFAULTLIB /IGNOR
 *_ICC11x86xASL_EBC_DLINK_FLAGS= "C:\Program Files 
(x86)\Intel\EBC\Lib\EbcLib.lib" /NOLOGO /NODEFAULTLIB /MACHINE:EBC /OPT:REF 
/ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /MAP /ALIGN:32 
/DRIVER
 
 
-
-#
-# MYTOOLS
-#   IA32 - Microsoft Visual Studio 2008 Team Suite
-#   X64  - Microsoft Visual Studio 2008 Team Suite
-#   EBC  - Intel EFI Byte Code Compiler
-#
-
-#   MYTOOLS  - Settings compatible with previous versions of 
tools_def.template
-*_MYTOOLS_*_*_FAMILY= MSFT
-
-##
-# ASL definitions
-##
-*_MYTOOLS_*_ASL_PATH= DEF(DEFAULT_WIN_ASL_BIN)
-*_MYTOOLS_*_ASL_FLAGS   = DEF(DEFAULT_WIN_ASL_FLAGS)
-*_MYTOOLS_*_ASL_OUTFLAGS= DEF(DEFAULT_WIN_ASL_OUTFLAGS)
-*_MYTOOLS_*_ASLCC_FLAGS = DEF(MSFT_ASLCC_FLAGS)
-*_MYTOOLS_*_ASLPP_FLAGS = DEF(MSFT_ASLPP_FLAGS)
-*_MYTOOLS_*_ASLDLINK_FLAGS  = DEF(MSFT_ASLDLINK_FLAGS)
-
-
-*_MYTOOLS_*_MAKE_FLAGS   = /nologo
-*_MYTOOLS_*_VFRPP_FLAGS  = /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h
-*_MYTOOLS_*_APP_FLAGS= /nologo /E /TC
-*_MYTOOLS_*_PP_FLAGS = /nologo /E /TC /FIAutoGen.h
-*_MYTOOLS_*_SLINK_FLAGS  = /nologo /LTCG
-
-*_MYTOOLS_*_ASM16_PATH  = DEF(VS2008_BIN)\ml.exe
-
-##
-# IA32 definitions

[edk2] [PATCH v3 05/10] OptionRomPkg/ReadMe.txt: Remove VS2005

2019-02-12 Thread Shenglei Zhang
Remove VS2005 in Build Validation.
https://bugzilla.tianocore.org/show_bug.cgi?id=1377

Cc: Ray Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 OptionRomPkg/ReadMe.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/OptionRomPkg/ReadMe.txt b/OptionRomPkg/ReadMe.txt
index 4fce87056e..99f97896da 100644
--- a/OptionRomPkg/ReadMe.txt
+++ b/OptionRomPkg/ReadMe.txt
@@ -13,6 +13,5 @@ CirrusLogic5430:
   Component Name (2), EFI driver supported Verison protocol.
 
 Build Validation:
-MYTOOLS(VS2005) IA32 X64 IPF EBC
 ICC IA32 X64 IPF
 
-- 
2.18.0.windows.1

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


[edk2] [PATCH v3 00/10] Remove unused tool chain configuration

2019-02-12 Thread Shenglei Zhang
VS2003, VS2005, DDK3790, UNIXGCC, ELFGCC, CYGCC and MYTOOLS are
too old. There is no verification for them. So remove them from
edk2/master.
https://bugzilla.tianocore.org/show_bug.cgi?id=1377

v2:1.Combine previous 05/10 and 06/10 to 05/10.
   2.Add 10/10(Remove GCCLD).

v3:1.Change order of patch series because of bisectability.
   2.Make changes in 04/10 and 09/10.

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yonghong Zhu 
Cc: Ray Ni 
Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Anthony Perard 
Cc: Julien Grall 
Shenglei Zhang (10):
  BaseTools/tools_def.template: Remove CYGGCC
  OptionRomPkg/ReadMe.txt: Remove CYGGCC
  BaseTools: Update MYTOOLS
  BaseTools/tools_def.template: Remove VS2003 and VS2005
  OptionRomPkg/ReadMe.txt: Remove VS2005
  BaseTools/tools_def.template: Remove UNIXGCC
  OvmfPkg/README: Remove UNIXGCC
  BaseTools/tools_def.template: Remove ELFGCC
  BaseTools/tools_def.template: Remove DDK3790
  BaseTools/build_rule.template: Remove GCCLD

 BaseTools/Conf/build_rule.template |   33 +-
 BaseTools/Conf/target.template |2 +-
 BaseTools/Conf/tools_def.template  | 1421 +---
 OptionRomPkg/ReadMe.txt|2 -
 OvmfPkg/OvmfPkgIa32.dsc|1 -
 OvmfPkg/OvmfPkgIa32X64.dsc |1 -
 OvmfPkg/OvmfPkgX64.dsc |1 -
 OvmfPkg/README |   19 -
 8 files changed, 18 insertions(+), 1462 deletions(-)

-- 
2.18.0.windows.1

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


Re: [edk2] [PATCH 2/3] MdeModulePkg/PeiMain: Support EFI_PEI_CORE_FV_LOCATION_PPI

2019-02-12 Thread Wang, Jian J
Chasel,


> -Original Message-
> From: Chiu, Chasel
> Sent: Tuesday, February 12, 2019 9:20 PM
> To: edk2-devel@lists.01.org
> Cc: Wang, Jian J ; Wu, Hao A ;
> Ni, Ray ; Zeng, Star ; Gao, Liming
> ; Chiu, Chasel 
> Subject: [PATCH 2/3] MdeModulePkg/PeiMain: Support
> EFI_PEI_CORE_FV_LOCATION_PPI
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1524
> 
> When shadowing PeiCore the EFI_PEI_CORE_FV_LOCATION_PPI
> should be checked to see if PeiCore not in BFV, otherwise
> just shadowing PeiCore from BFV.
> 
> Test: Verified on internal platform and booting successfully.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chasel Chiu 
> ---
>  MdeModulePkg/Core/Pei/PeiMain/PeiMain.c | 58
> +-
>  MdeModulePkg/Core/Pei/PeiMain.h |  3 ++-
>  MdeModulePkg/Core/Pei/PeiMain.inf   |  3 ++-
>  3 files changed, 49 insertions(+), 15 deletions(-)
> 
> diff --git a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> index 4da80a8222..408f24c216 100644
> --- a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> +++ b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
> @@ -1,7 +1,7 @@
>  /** @file
>Pei Core Main Entry Point
> 
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, 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
> @@ -80,23 +80,55 @@ ShadowPeiCore (
>IN PEI_CORE_INSTANCE  *PrivateData
>)
>  {
> -  EFI_PEI_FILE_HANDLE  PeiCoreFileHandle;
> -  EFI_PHYSICAL_ADDRESS EntryPoint;
> -  EFI_STATUS   Status;
> -  UINT32   AuthenticationState;
> +  EFI_PEI_FILE_HANDLE  PeiCoreFileHandle;
> +  EFI_PHYSICAL_ADDRESS EntryPoint;
> +  EFI_STATUS   Status;
> +  UINT32   AuthenticationState;
> +  UINTNIndex;
> +  EFI_PEI_CORE_FV_LOCATION_PPI *PeiCoreFvLocationPpi;
> 
>PeiCoreFileHandle = NULL;
> 
>//
> -  // Find the PEI Core in the BFV
> +  // Find the PEI Core either from EFI_PEI_CORE_FV_LOCATION_PPI indicated
> FV or BFV
>//
> -  Status = PrivateData->Fv[0].FvPpi->FindFileByType (
> -   PrivateData->Fv[0].FvPpi,
> -   EFI_FV_FILETYPE_PEI_CORE,
> -   PrivateData->Fv[0].FvHandle,
> -   
> -   );
> -  ASSERT_EFI_ERROR (Status);
> +  Status = PeiServicesLocatePpi (
> + ,
> + 0,
> + NULL,
> + (VOID **) 
> + );
> +  if (!EFI_ERROR (Status) && (PeiCoreFvLocationPpi->PeiCoreFvLocation !=
> NULL)) {
> +//
> +// If PeiCoreFvLocation present, the PEI Core should be found from 
> indicated
> FV.
> +//
> +for (Index = 0; Index < PrivateData->FvCount; Index ++) {
> +  if ((UINT32) PrivateData->Fv[Index].FvHandle != (UINT32)
> PeiCoreFvLocationPpi->PeiCoreFvLocation) {

I think the UINT32 type cast is not necessary. FvHandle and PeiCoreFvLocation 
are
actually type of VOID*. Do you encounter any compiler error here?

Regards,
Jian

> +continue;
> +  }
> +  Status = PrivateData->Fv[Index].FvPpi->FindFileByType (
> +   PrivateData->Fv[Index].FvPpi,
> +   EFI_FV_FILETYPE_PEI_CORE,
> +   
> PrivateData->Fv[Index].FvHandle,
> +   
> +   );
> +  if (!EFI_ERROR (Status)) {
> +break;
> +  }
> +}
> +ASSERT (Index < PrivateData->FvCount);
> +  } else {
> +//
> +// Find PEI Core from BFV
> +//
> +Status = PrivateData->Fv[0].FvPpi->FindFileByType (
> + PrivateData->Fv[0].FvPpi,
> + EFI_FV_FILETYPE_PEI_CORE,
> + PrivateData->Fv[0].FvHandle,
> + 
> + );
> +ASSERT_EFI_ERROR (Status);
> +  }
> 
>//
>// Shadow PEI Core into memory so it will run faster
> diff --git a/MdeModulePkg/Core/Pei/PeiMain.h
> b/MdeModulePkg/Core/Pei/PeiMain.h
> index 322e7cd845..38542ab072 100644
> --- a/MdeModulePkg/Core/Pei/PeiMain.h
> +++ b/MdeModulePkg/Core/Pei/PeiMain.h
> @@ -1,7 +1,7 @@
>  /** @file
>Definition of Pei Core Structures and Services
> 
> -Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2019, Intel 

Re: [edk2] [PATCH v4 12/13] OvmfPkg/LockBoxLib: Update the comments for API UpdateLockBox()

2019-02-12 Thread Ni, Ray

Reviewed-by: Ray Ni 

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


[edk2] [PATCH v3] MdeModulePkg/CapsuleApp: Fix memory leak issue.

2019-02-12 Thread Chen A Chen
This issue is caused by FileInfoBuffer variable. This is a pointer array
and each elements also pointer to a memory buffer that is allocated and
returned by AllocateCopyPool function.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Zhang Chao B 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chen A Chen 
---
 MdeModulePkg/Application/CapsuleApp/CapsuleDump.c | 87 ---
 1 file changed, 60 insertions(+), 27 deletions(-)

diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c 
b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
index ba2583accb..9fd4af4e55 100644
--- a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
+++ b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
@@ -806,48 +806,69 @@ DumpCapsuleFromDisk (
   Status = Fs->OpenVolume (Fs, );
   if (EFI_ERROR (Status)) {
 Print (L"Cannot open volume. Status = %r\n", Status);
-return EFI_NOT_FOUND;
+goto Done;
   }
 
   Status = Root->Open (Root, , EFI_CAPSULE_FILE_DIRECTORY, 
EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE , 0);
   if (EFI_ERROR (Status)) {
 Print (L"Cannot open %s. Status = %r\n", EFI_CAPSULE_FILE_DIRECTORY, 
Status);
-return EFI_NOT_FOUND;
+goto Done;
   }
 
   //
   // Get file count first
   //
-  for ( Status = FileHandleFindFirstFile (DirHandle, )
-  ; !EFI_ERROR(Status) && !NoFile
-  ; Status = FileHandleFindNextFile (DirHandle, FileInfo, )
- ){
-if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
-  continue;
+  do {
+Status = FileHandleFindFirstFile (DirHandle, );
+if (EFI_ERROR (Status) || FileInfo == NULL) {
+  Print (L"Get File Info Fail. Status = %r\n", Status);
+  goto Done;
 }
-FileCount++;
-  }
+
+if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
+  FileCount++;
+}
+
+Status = FileHandleFindNextFile (DirHandle, FileInfo, );
+if (EFI_ERROR (Status)) {
+  Print (L"Get Next File Fail. Status = %r\n", Status);
+  goto Done;
+}
+  } while (!NoFile);
 
   if (FileCount == 0) {
 Print (L"Error: No capsule file found!\n");
-return EFI_NOT_FOUND;
+Status = EFI_NOT_FOUND;
+goto Done;
   }
 
-  FileInfoBuffer = AllocatePool (sizeof(FileInfo) * FileCount);
+  FileInfoBuffer = AllocateZeroPool (sizeof (FileInfo) * FileCount);
+  if (FileInfoBuffer == NULL) {
+Status = EFI_OUT_OF_RESOURCES;
+goto Done;
+  }
   NoFile = FALSE;
 
   //
   // Get all file info
   //
-  for ( Status = FileHandleFindFirstFile (DirHandle, )
-  ; !EFI_ERROR (Status) && !NoFile
-  ; Status = FileHandleFindNextFile (DirHandle, FileInfo, )
- ){
-if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
-  continue;
+  do {
+Status = FileHandleFindFirstFile (DirHandle, );
+if (EFI_ERROR (Status) || FileInfo == NULL) {
+  Print (L"Get File Info Fail. Status = %r\n", Status);
+  goto Done;
+}
+
+if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
+  FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size, 
FileInfo);
 }
-FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size, 
FileInfo);
-  }
+
+Status = FileHandleFindNextFile (DirHandle, FileInfo, );
+if (EFI_ERROR (Status)) {
+  Print (L"Get Next File Fail. Status = %r\n", Status);
+  goto Done;
+}
+  } while (!NoFile);
 
   //
   // Sort FileInfoBuffer by alphabet order
@@ -866,7 +887,8 @@ DumpCapsuleFromDisk (
   }
 
   if (!DumpCapsuleInfo) {
-return EFI_SUCCESS;
+Status = EFI_SUCCESS;
+goto Done;
   }
 
   Print(L"The infomation of the capsules:\n");
@@ -875,27 +897,28 @@ DumpCapsuleFromDisk (
 FileHandle = NULL;
 Status = DirHandle->Open (DirHandle, , 
FileInfoBuffer[Index]->FileName, EFI_FILE_MODE_READ, 0);
 if (EFI_ERROR (Status)) {
-  break;
+  goto Done;
 }
 
 Status = FileHandleGetSize (FileHandle, (UINT64 *) );
 if (EFI_ERROR (Status)) {
   Print (L"Cannot read file %s. Status = %r\n", 
FileInfoBuffer[Index]->FileName, Status);
   FileHandleClose (FileHandle);
-  return Status;
+  goto Done;
 }
 
 FileBuffer = AllocatePool (FileSize);
 if (FileBuffer == NULL) {
-  return RETURN_OUT_OF_RESOURCES;
+  Status = EFI_OUT_OF_RESOURCES;
+  goto Done;
 }
 
 Status = FileHandleRead (FileHandle, , FileBuffer);
 if (EFI_ERROR (Status)) {
   Print (L"Cannot read file %s. Status = %r\n", 
FileInfoBuffer[Index]->FileName, Status);
-  FreePool (FileBuffer);
   FileHandleClose (FileHandle);
-  return Status;
+  FreePool (FileBuffer);
+  goto Done;
 }
 
 Print (L"**\n");
@@ -906,7 +929,17 @@ DumpCapsuleFromDisk (
 FreePool (FileBuffer);
   }
 
-  return EFI_SUCCESS;
+Done:
+  if (FileInfoBuffer != NULL) {
+for (Index = 0; Index < FileCount; Index++) {
+  if (FileInfoBuffer[Index] != NULL) {
+FreePool 

Re: [edk2] [PATCH v4 04/13] MdeModulePkg: Add GUID for LockBox to save storage dev to init in S3

2019-02-12 Thread Ni, Ray

Reviewed-by: Ray Ni 

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


Re: [edk2] [PATCH v4 02/13] MdeModulePkg: Add definitions for EDKII PEI ATA PassThru PPI

2019-02-12 Thread Ni, Ray

On 2/11/2019 3:57 PM, Hao Wu wrote:

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409

This commit will add the definitions for EDKII PEI ATA PassThru PPI. This
PPI will provide services that allow ATA commands to be sent to ATA
devices attached to an ATA controller in the PEI phase.

More specifically, the PPI will provide services to:

* Send ATA commands to an ATA device (by service 'PassThru');
* Get the list of the attached ATA device on a controller (by services
   'GetNextPort' and 'GetNextDevice');
* Get the identification information (DevicePath) of the underlying ATA
   host controller (by service 'GetDevicePath').

Cc: Jian J Wang
Cc: Ruiyu Ni
Cc: Eric Dong
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu

Reviewed-by: Ray Ni 

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


Re: [edk2] [PATCH v1 1/1] MdeModulePkg/NvmExpressDxe: Report StatusCode for device init failure

2019-02-12 Thread Ni, Ray

On 2/11/2019 3:57 PM, Hao Wu wrote:

From: Sean Brogan

REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1408

According to the information of the above BZ-1408 and other platform
owners, NVM Express devices are becoming more likely to be a critical
part during the boot process.

This commit will add the calls to 'REPORT_STATUS_CODE' when there is a
failure happens during the NVM Express controller/device initialization
process.

Cc: Sean Brogan
Cc: Bret Barkelew
Cc: Jian J Wang
Cc: Ray Ni
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu


Reviewed-by: Ray Ni 

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


Re: [edk2] [PATCH] MdePkg/BaseLib: implement SpeculationBarrier() for ARM and AArch64

2019-02-12 Thread Ard Biesheuvel
On Tue, 12 Feb 2019 at 01:26, Gao, Liming  wrote:
>
> Ard:
>   I agree your comments not to add PCD until there is the real problem.
>

Pushed as 1a35dd723bbf..c0959b4426b2

Thanks all


> Thanks
> Liming
> >-Original Message-
> >From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard
> >Biesheuvel
> >Sent: Tuesday, February 12, 2019 1:32 AM
> >To: Leif Lindholm 
> >Cc: Kinney, Michael D ; edk2-
> >de...@lists.01.org; Gao, Liming 
> >Subject: Re: [edk2] [PATCH] MdePkg/BaseLib: implement SpeculationBarrier()
> >for ARM and AArch64
> >
> >On Mon, 11 Feb 2019 at 15:41, Leif Lindholm  wrote:
> >>
> >> On Wed, Feb 06, 2019 at 12:08:22AM +, Ard Biesheuvel wrote:
> >> > Replace the dummy C implementation of SpeculationBarrier() with
> >> > implementations consisting of the recommended DSB SY + ISB sequence,
> >> > as recommended by ARM in the whitepaper "Cache Speculation Side-
> >channels"
> >> > version 2.4, dated October 2018.
> >> >
> >> > Contributed-under: TianoCore Contribution Agreement 1.1
> >> > Signed-off-by: Ard Biesheuvel 
> >>
> >> Patch looks fine.
> >> Reviewed-by: Leif Lindholm 
> >>
> >> Question: do we expect performance impact to be sufficient to
> >> motivate a Pcd to be able to disable the barrier on unaffected
> >> processors?
> >>
> >
> >Currently, these are only used on some codepaths in the MM component
> >of the variable store, which do not look like hot paths to me.
> >
> >In general, I think it should be fine to defer doing something like
> >this until someone highlights it as an actual problem (and has the
> >numbers to prove it)
> >
> >
> >> > ---
> >> >  MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S   | 39
> >
> >> >  MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm | 38
> >+++
> >> >  MdePkg/Library/BaseLib/Arm/SpeculationBarrier.S   | 39
> >
> >> >  MdePkg/Library/BaseLib/Arm/SpeculationBarrier.asm | 39
> >
> >> >  MdePkg/Library/BaseLib/Arm/SpeculationBarrier.c   | 30 
> >> > ---
> >> >  MdePkg/Library/BaseLib/BaseLib.inf|  7 +++-
> >> >  6 files changed, 160 insertions(+), 32 deletions(-)
> >> >
> >> > diff --git a/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S
> >b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S
> >> > new file mode 100644
> >> > index ..500bdadca5d2
> >> > --- /dev/null
> >> > +++ b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.S
> >> > @@ -0,0 +1,39 @@
> >> > +##--
> >> > +#
> >> > +# SpeculationBarrier() for AArch64
> >> > +#
> >> > +# Copyright (c) 2019, Linaro Ltd. All rights reserved.
> >> > +#
> >> > +# This program and the accompanying materials
> >> > +# are licensed and made available under the terms and conditions of the
> >BSD License
> >> > +# which accompanies this distribution.  The full text of the license 
> >> > may be
> >found at
> >> > +# http://opensource.org/licenses/bsd-license.php.
> >> > +#
> >> > +# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> >BASIS,
> >> > +# WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> >EXPRESS OR IMPLIED.
> >> > +#
> >> > +##--
> >> > +
> >> > +.text
> >> > +.p2align 2
> >> > +
> >> > +GCC_ASM_EXPORT(SpeculationBarrier)
> >> > +
> >> > +
> >> > +#/**
> >> > +#  Uses as a barrier to stop speculative execution.
> >> > +#
> >> > +#  Ensures that no later instruction will execute speculatively, until 
> >> > all
> >prior
> >> > +#  instructions have completed.
> >> > +#
> >> > +#**/
> >> > +#VOID
> >> > +#EFIAPI
> >> > +#SpeculationBarrier (
> >> > +#  VOID
> >> > +#  );
> >> > +#
> >> > +ASM_PFX(SpeculationBarrier):
> >> > +dsb  sy
> >> > +isb
> >> > +ret
> >> > diff --git a/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm
> >b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm
> >> > new file mode 100644
> >> > index ..0c4b915b7798
> >> > --- /dev/null
> >> > +++ b/MdePkg/Library/BaseLib/AArch64/SpeculationBarrier.asm
> >> > @@ -0,0 +1,38 @@
> >> > +;--
> >> > +;
> >> > +; SpeculationBarrier() for AArch64
> >> > +;
> >> > +; Copyright (c) 2019, Linaro Ltd. All rights reserved.
> >> > +;
> >> > +; This program and the accompanying materials
> >> > +; are licensed and made available under the terms and conditions of the
> >BSD License
> >> > +; which accompanies this distribution.  The full text of the license 
> >> > may be
> >found at
> >> > +; http://opensource.org/licenses/bsd-license.php.
> >> > +;
> >> > +; THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> >BASIS,
> >> > +; WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
> >EXPRESS OR IMPLIED.
> >> > +;
> >> > 

Re: [edk2] [PATCH 1/1] EmbeddedPkg/Library: Add VirtualRealTimeClockLib

2019-02-12 Thread Leif Lindholm
On Mon, Feb 04, 2019 at 12:47:36PM +, Pete Batard wrote:
> This is designed to be used on platforms where a a real RTC is not
> available and relies on an RtcEpochSeconds variable having been set or,
> if that is not the case, falls back to using the epoch embedded at
> compilation time.
> 
> Note that, in order to keep things simple for the setting of the
> compilation time variable, only GCC environments with UNIX-like shells
> and where a 'date' command is available are meant to be supported for
> now.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Pete Batard 

On the whole, this looks good to me.
One addition we'll need, so that we can build this library standalone
is an entry in EmbeddedPkg.dsc:

diff --git a/EmbeddedPkg/EmbeddedPkg.dsc b/EmbeddedPkg/EmbeddedPkg.dsc
index 4d9e6399d5..dc5040e611 100644
--- a/EmbeddedPkg/EmbeddedPkg.dsc
+++ b/EmbeddedPkg/EmbeddedPkg.dsc
@@ -218,6 +218,7 @@ [Components.common]
   EmbeddedPkg/Library/CoherentDmaLib/CoherentDmaLib.inf
   EmbeddedPkg/Library/NonCoherentDmaLib/NonCoherentDmaLib.inf
   
EmbeddedPkg/Library/DxeDtPlatformDtbLoaderLibDefault/DxeDtPlatformDtbLoaderLibDefault.inf
+  EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf
   EmbeddedPkg/EmbeddedMonotonicCounter/EmbeddedMonotonicCounter.inf
   EmbeddedPkg/RealTimeClockRuntimeDxe/RealTimeClockRuntimeDxe.inf

I don't have any strong opinions on either of Phil's suggestions, but
if you could give some feedback on those and fold the above in, this
could go in.

Regards,

Leif

> ---
>  EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c   | 
> 400 
>  EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf |  
> 43 +++
>  2 files changed, 443 insertions(+)
> 
> diff --git 
> a/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c 
> b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
> new file mode 100644
> index ..4c354730d02b
> --- /dev/null
> +++ b/EmbeddedPkg/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
> @@ -0,0 +1,400 @@
> +/** @file
> + *
> + *  Implement virtual EFI RealTimeClock runtime services.
> + *
> + *  Coypright (c) 2019, Pete Batard 
> + *  Copyright (c) 2018, Andrei Warkentin 
> + *  Copyright (c) 2011-2014, ARM Ltd. All rights reserved.
> + *  Copyright (c) 2008-2010, Apple Inc. All rights reserved.
> + *  Copyright (c) Microsoft Corporation. All rights reserved.
> + *
> + *  This program and the accompanying materials
> + *  are licensed and made available under the terms and conditions of the 
> BSD License
> + *  which accompanies this distribution.  The full text of the license may 
> be found at
> + *  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.
> + *
> + *  Based on 
> ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.inf
> + *
> + **/
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +STATIC CONST CHAR16  mEpochVariableName[] = L"RtcEpochSeconds";
> +STATIC CONST CHAR16  mTimeZoneVariableName[]  = L"RtcTimeZone";
> +STATIC CONST CHAR16  mDaylightVariableName[]  = L"RtcDaylight";
> +
> +/**
> +   Returns the current time and date information, and the time-keeping 
> capabilities
> +   of the virtual RTC.
> +
> +   @param  Time  A pointer to storage to receive a snapshot 
> of the current time.
> +   @param  Capabilities  An optional pointer to a buffer to receive 
> the real time clock
> + device's capabilities.
> +
> +   @retval EFI_SUCCESS   The operation completed successfully.
> +   @retval EFI_INVALID_PARAMETER Time is NULL.
> +   @retval EFI_DEVICE_ERROR  The time could not be retrieved due to 
> hardware error.
> +
> +**/
> +EFI_STATUS
> +EFIAPI
> +LibGetTime (
> +  OUT EFI_TIME   *Time,
> +  OUT EFI_TIME_CAPABILITIES  *Capabilities
> +  )
> +{
> +  EFI_STATUS  Status;
> +  UINT32  EpochSeconds;
> +  INT16   TimeZone;
> +  UINT8   Daylight;
> +  UINT64  Freq;
> +  UINT64  Counter;
> +  UINT64  Remainder;
> +  UINTN   ElapsedSeconds;
> +  UINTN   Size;
> +
> +  if (Time == NULL) {
> +return EFI_INVALID_PARAMETER;
> +  }
> +
> +  // Get the counter frequency
> +  Freq = GetPerformanceCounterProperties (NULL, NULL);
> +  if (Freq == 0) {
> +return EFI_DEVICE_ERROR;
> +  }
> +
> +  // Get the epoch time from non-volatile storage
> +  Size = sizeof (UINTN);
> +  ElapsedSeconds = 0;
> +  Status = EfiGetVariable (
> + (CHAR16 *)mEpochVariableName,
> + ,
> + NULL,
> + ,
> + (VOID *)
> + );
> +  // Fall back to compilation-time epoch if not set
> +  if (EFI_ERROR (Status)) 

Re: [edk2] [Patch 0/3] BaseTools: Implement splitquoted function

2019-02-12 Thread Laszlo Ersek
On 02/12/19 18:16, Philippe Mathieu-Daudé wrote:
> On 2/12/19 3:02 PM, Laszlo Ersek wrote:
>> On 02/12/19 14:33, Gao, Liming wrote:
>>> Laszlo:
>>>  To install python3-distutils should resolve this issue. I expect BaseTools 
>>> build functionality doesn't depend on the third party python lib.
>>
>> I completely agree with your expectation, regarding *3rd party* python
>> packages. We shouldn't expect developers to install packages from
>> repositories that fall outside of their normal distro repos.
>>
>> However, my understanding was that python3-distutils should be available
>> as a normal (not 3rd party) component on Ubuntu 18. I think we can
>> expect developers to install additional packages if those packages are
>> readily available in their normal (distro-provided) repos.
> 
> The documentation is not precise about the python package to install, it
> simply states "Install Python 2.7.10":
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Getting-Started-with-EDK-II
> 
> --
> 
> Except python, there is a precise list of packages to install for this
> distro: "sudo apt-get install build-essential uuid-dev iasl git gcc-5
> nasm", per:
> 
> https://github.com/tianocore/tianocore.github.io/wiki/Using-EDK-II-with-Native-GCC#Install_required_software_from_apt
> 
> Maybe we simply need to update the doc to ask python3 and add
> python3-distutils in the list?

I didn't realize we had Ubuntu-specific instructions for setting up the
environment :) So yes, if Liming & Hao confirm python3-distutils is
available as part of Ubuntu 18, then the docs should likely be updated
as you say.

Thanks
Laszlo

> 
>>
>>> So, I suggest to check whether python3-distutils is the native python 
>>> library. If it is native python library, why Ubuntu18 doesn't include it. I 
>>> will work with Dandan to collect more information. 
>>
>> Right, that's exactly what I'm asking for. Thank you very much!
>> Laszlo
>>
 -Original Message-
 From: Laszlo Ersek [mailto:ler...@redhat.com]
 Sent: Tuesday, February 12, 2019 8:24 PM
 To: Feng, Bob C ; Bi, Dandan 
 Cc: edk2-devel@lists.01.org; Gao, Liming 
 Subject: Re: [edk2] [Patch 0/3] BaseTools: Implement splitquoted function

 On 02/04/19 20:12, Laszlo Ersek wrote:
> On 02/03/19 06:55, Feng, Bob C wrote:
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1509
>> On some Linux environment, there may be no distutils.util
>> library for python3 that will cause build tool crash.
>> This patch implement distutils.util.split_quoted
>> in BaseTools so that the Basetools will be independent with
>> distutils.util library.
>>
>> Feng, Bob C (3):
>>   BaseTools: Implement splitquoted function in Build tool
>>   BaseTools: Implement splitquoted function in UPT
>>   BaseTools: unit test for splitquoted function
>>
>>  BaseTools/Source/Python/AutoGen/UniClassObject.py | 50 
>> ++
>>  BaseTools/Source/Python/UPT/Library/UniClassObject.py | 47 
>> ---
>>  BaseTools/Tests/TestStringSplit.py| 38 
>> ++
>>  3 files changed, 128 insertions(+), 7 deletions(-)
>>  create mode 100644 BaseTools/Tests/TestStringSplit.py
>>
>
> Is this really necessary? BZ#1509 references Ubuntu18; however it looks
> like the issue can be resolved by a simple package installation on
> Ubuntu 18:
>
> https://superuser.com/questions/1319047/cant-install-virtual-interpreter-in-pycharm-in-linux
>
> """
> sudo apt-get install python3-distutils
> """
>
> I'm not a Ubuntu user myself; so all I can do here (without installing a
> Ubuntu18 VM) is check the Ubuntu package directory:
>
> https://packages.ubuntu.com/search?keywords=python3-distutils=names=all=all
>
> python3-distutils appears available for both "bionic (18.04LTS)" and
> "cosmic (18.10)".
>
> Dandan, if you install python3-distutils, does that solve the issue for 
> you?

 I'd still like to get an answer to my question, before the series is 
 pushed.

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

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


Re: [edk2] [Patch 0/3] BaseTools: Implement splitquoted function

2019-02-12 Thread Philippe Mathieu-Daudé
On 2/12/19 3:02 PM, Laszlo Ersek wrote:
> On 02/12/19 14:33, Gao, Liming wrote:
>> Laszlo:
>>  To install python3-distutils should resolve this issue. I expect BaseTools 
>> build functionality doesn't depend on the third party python lib.
> 
> I completely agree with your expectation, regarding *3rd party* python
> packages. We shouldn't expect developers to install packages from
> repositories that fall outside of their normal distro repos.
> 
> However, my understanding was that python3-distutils should be available
> as a normal (not 3rd party) component on Ubuntu 18. I think we can
> expect developers to install additional packages if those packages are
> readily available in their normal (distro-provided) repos.

The documentation is not precise about the python package to install, it
simply states "Install Python 2.7.10":

https://github.com/tianocore/tianocore.github.io/wiki/Getting-Started-with-EDK-II

--

Except python, there is a precise list of packages to install for this
distro: "sudo apt-get install build-essential uuid-dev iasl git gcc-5
nasm", per:

https://github.com/tianocore/tianocore.github.io/wiki/Using-EDK-II-with-Native-GCC#Install_required_software_from_apt

Maybe we simply need to update the doc to ask python3 and add
python3-distutils in the list?

> 
>> So, I suggest to check whether python3-distutils is the native python 
>> library. If it is native python library, why Ubuntu18 doesn't include it. I 
>> will work with Dandan to collect more information. 
> 
> Right, that's exactly what I'm asking for. Thank you very much!
> Laszlo
> 
>>> -Original Message-
>>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>>> Sent: Tuesday, February 12, 2019 8:24 PM
>>> To: Feng, Bob C ; Bi, Dandan 
>>> Cc: edk2-devel@lists.01.org; Gao, Liming 
>>> Subject: Re: [edk2] [Patch 0/3] BaseTools: Implement splitquoted function
>>>
>>> On 02/04/19 20:12, Laszlo Ersek wrote:
 On 02/03/19 06:55, Feng, Bob C wrote:
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1509
> On some Linux environment, there may be no distutils.util
> library for python3 that will cause build tool crash.
> This patch implement distutils.util.split_quoted
> in BaseTools so that the Basetools will be independent with
> distutils.util library.
>
> Feng, Bob C (3):
>   BaseTools: Implement splitquoted function in Build tool
>   BaseTools: Implement splitquoted function in UPT
>   BaseTools: unit test for splitquoted function
>
>  BaseTools/Source/Python/AutoGen/UniClassObject.py | 50 
> ++
>  BaseTools/Source/Python/UPT/Library/UniClassObject.py | 47 
> ---
>  BaseTools/Tests/TestStringSplit.py| 38 
> ++
>  3 files changed, 128 insertions(+), 7 deletions(-)
>  create mode 100644 BaseTools/Tests/TestStringSplit.py
>

 Is this really necessary? BZ#1509 references Ubuntu18; however it looks
 like the issue can be resolved by a simple package installation on
 Ubuntu 18:

 https://superuser.com/questions/1319047/cant-install-virtual-interpreter-in-pycharm-in-linux

 """
 sudo apt-get install python3-distutils
 """

 I'm not a Ubuntu user myself; so all I can do here (without installing a
 Ubuntu18 VM) is check the Ubuntu package directory:

 https://packages.ubuntu.com/search?keywords=python3-distutils=names=all=all

 python3-distutils appears available for both "bionic (18.04LTS)" and
 "cosmic (18.10)".

 Dandan, if you install python3-distutils, does that solve the issue for 
 you?
>>>
>>> I'd still like to get an answer to my question, before the series is pushed.
>>>
>>> Thanks,
>>> Laszlo
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] 3rd Party Python Packages

2019-02-12 Thread Laszlo Ersek
On 02/12/19 16:22, Carsey, Jaben wrote:
> Note: deviating from "RE: [edk2] [Patch 0/3] BaseTools: Implement splitquoted 
> function"
> 
> Laszlo,
> 
> Since I am working on some research related to this, I have a few follow up 
> questions.
> 
> If there is significant performance improvement, how would you feel about 
> requiring a 3rd party package to be installed (via pip I think)?

I'd strongly disagree with the proposal, except if the add-on were optional.

If the python add-on in question is well-maintained, its upstream
maintainers should work with popular distro maintainers to get the
project packaged. Then distro users can enable the add-on (and the
dependent BaseTools goodies) without leaving their well known / trusted
repos.

> Would you feel more comfortable if BaseTools were able to run either with it 
> or without (with performance differences)?

I certainly would.

> Basically there are potential performance improvements, but use of 3rd party 
> python packages is instrumental for many of them.

I think that's normal; people write libs and add-ons to improve
functionality and/or performance. What matters is how distro users can
consume these add-ons.

Thanks,
Laszlo

> 
> -Jaben
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Tuesday, February 12, 2019 6:02 AM
>> To: Gao, Liming ; Feng, Bob C
>> ; Bi, Dandan 
>> Cc: edk2-devel@lists.01.org
>> Subject: Re: [edk2] [Patch 0/3] BaseTools: Implement splitquoted function
>>
>> On 02/12/19 14:33, Gao, Liming wrote:
>>> Laszlo:
>>>  To install python3-distutils should resolve this issue. I expect BaseTools
>> build functionality doesn't depend on the third party python lib.
>>
>> I completely agree with your expectation, regarding *3rd party* python
>> packages. We shouldn't expect developers to install packages from
>> repositories that fall outside of their normal distro repos.
>>
>> However, my understanding was that python3-distutils should be available
>> as a normal (not 3rd party) component on Ubuntu 18. I think we can
>> expect developers to install additional packages if those packages are
>> readily available in their normal (distro-provided) repos.
>>
>>> So, I suggest to check whether python3-distutils is the native python
>> library. If it is native python library, why Ubuntu18 doesn't include it. I 
>> will
>> work with Dandan to collect more information.
>>
>> Right, that's exactly what I'm asking for. Thank you very much!
>> Laszlo
>>
 -Original Message-
 From: Laszlo Ersek [mailto:ler...@redhat.com]
 Sent: Tuesday, February 12, 2019 8:24 PM
 To: Feng, Bob C ; Bi, Dandan
>> 
 Cc: edk2-devel@lists.01.org; Gao, Liming 
 Subject: Re: [edk2] [Patch 0/3] BaseTools: Implement splitquoted
>> function

 On 02/04/19 20:12, Laszlo Ersek wrote:
> On 02/03/19 06:55, Feng, Bob C wrote:
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1509
>> On some Linux environment, there may be no distutils.util
>> library for python3 that will cause build tool crash.
>> This patch implement distutils.util.split_quoted
>> in BaseTools so that the Basetools will be independent with
>> distutils.util library.
>>
>> Feng, Bob C (3):
>>   BaseTools: Implement splitquoted function in Build tool
>>   BaseTools: Implement splitquoted function in UPT
>>   BaseTools: unit test for splitquoted function
>>
>>  BaseTools/Source/Python/AutoGen/UniClassObject.py | 50
>> ++
>>  BaseTools/Source/Python/UPT/Library/UniClassObject.py | 47
>> ---
>>  BaseTools/Tests/TestStringSplit.py| 38
>> ++
>>  3 files changed, 128 insertions(+), 7 deletions(-)
>>  create mode 100644 BaseTools/Tests/TestStringSplit.py
>>
>
> Is this really necessary? BZ#1509 references Ubuntu18; however it looks
> like the issue can be resolved by a simple package installation on
> Ubuntu 18:
>
> https://superuser.com/questions/1319047/cant-install-virtual-
>> interpreter-in-pycharm-in-linux
>
> """
> sudo apt-get install python3-distutils
> """
>
> I'm not a Ubuntu user myself; so all I can do here (without installing a
> Ubuntu18 VM) is check the Ubuntu package directory:
>
> https://packages.ubuntu.com/search?keywords=python3-
>> distutils=names=all=all
>
> python3-distutils appears available for both "bionic (18.04LTS)" and
> "cosmic (18.10)".
>
> Dandan, if you install python3-distutils, does that solve the issue for
>> you?

 I'd still like to get an answer to my question, before the series is 
 pushed.

 Thanks,
 Laszlo
>>
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> 

Re: [edk2] [PATCH edk2-platforms v1 11/16] Hisilicon/D06: Add Setup Item "Support DPC"

2019-02-12 Thread Leif Lindholm
On Tue, Feb 12, 2019 at 11:22:24PM +0800, Ming Huang wrote:
> On 2/12/2019 3:46 AM, Leif Lindholm wrote:
> > On Fri, Feb 01, 2019 at 09:34:31PM +0800, Ming Huang wrote:
> >> Add setup item "Support DPC" to enable or disable PCIe DPC
> >> (Downstream Port Containment).
> > 
> > This patch also seems to disable the SRIOV configuration and delete a
> > lot of ports. Can you explain how this is related?
> 
> The pcie menu is suppressed for original code as these menus are not ready,
> this patch remove the suppression for pcie menu, so delete these menus for 
> now.

OK. Please update subject and commit message to reflect these
additional changes.

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


Re: [edk2] [PATCH edk2-platforms v1 10/16] Hisilicon/D06: Modify for M7 self-Adapte support

2019-02-12 Thread Leif Lindholm
On Tue, Feb 12, 2019 at 11:14:43PM +0800, Ming Huang wrote:
> 
> 
> On 2/12/2019 3:28 AM, Leif Lindholm wrote:
> > On Fri, Feb 01, 2019 at 09:34:30PM +0800, Ming Huang wrote:
> >> As new M7(Cortex-M7) firmware support self-adapte, so do not
> >> need BIOS to implement some function, remove useless funtions
> >> and report CPU0/CPU1 Nic NCL offset to M7.
> > 
> > I don't really care that some other device in the system is a
> > Cortex-A7. What is its function? Is it an SCP, an MCP, ?
> > Please describe its function rather than its implementation.
> 
> M7 is used for HNS(Hisilicon network system), cpu access the network
> component via M7.

Sure. But does customer documentation documentation refer to it as
"M7"?

> > 
> > What are the external dependencies?
> > Is this addressed by one of the patches for edk2-non-osi?
> 
> This is depend on M7 firmware which will include in hpm file.

So we don't get it when using Capsule Update?

What would be the implication of installing system firmware with the
below change on a system that had not had the corresponding M7
firmware update?

/
Leif

> > 
> > More style issues below.
> > 
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Ming Huang 
> >> ---
> >>  Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c | 272 
> >> 
> >>  1 file changed, 45 insertions(+), 227 deletions(-)
> >>
> >> diff --git a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c 
> >> b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> >> index aaf990216982..9bf274e1b991 100644
> >> --- a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> >> +++ b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
> >> @@ -21,44 +21,21 @@
> >>  #include 
> >>  
> >>  #define CPU2_SFP2_100G_CARD_OFFSET   0x25
> >> -#define CPU1_SFP1_LOCATE_OFFSET  0x16
> >> -#define CPU1_SFP0_LOCATE_OFFSET  0x12
> >> -#define CPU2_SFP1_LOCATE_OFFSET  0x21
> >> -#define CPU2_SFP0_LOCATE_OFFSET  0x19
> >> -#define CPU2_SFP2_10G_GE_CARD_OFFSET 0x25
> >>  
> >> -#define SFP_10G_SPEED   10
> >> -#define SFP_25G_SPEED   25
> >> -#define SFP_100G_SPEED  100
> >> -#define SFP_GE_SPEED1
> >> -
> >> -#define SFP_GE_SPEED_VAL_VENDOR_FINISAR 0x0C
> >> -#define SFP_GE_SPEED_VAL0x0D
> >> -#define SFP_10G_SPEED_VAL   0x67
> >> -#define SFP_25G_SPEED_VAL   0xFF
> >> +#define SOCKET1_NET_PORT_100G 1
> >> +#define SOCKET0_NET_PORT_NUM  4
> >> +#define SOCKET1_NET_PORT_NUM  2
> >>  
> >>  #define CARD_PRESENT_100G   (BIT7)
> >> -#define CARD_PRESENT_10G(BIT0)
> >> -#define SELECT_SFP_BY_INDEX(index)  (1 << (index - 1))
> >> -#define SPF_SPEED_OFFSET12
> >> -
> >> -#define SFP_DEVICE_ADDRESS 0x50
> >> -#define CPU1_9545_I2C_ADDR 0x70
> >> -#define CPU2_9545_I2C_ADDR 0x71
> >> -
> >> -#define FIBER_PRESENT 0
> >> -#define CARD_PRESENT  1
> >> -#define I2C_PORT_SFP  4
> >> -#define CPU2_I2C_PORT_SFP 5
> >> -
> >> -#define SOCKET_0 0
> >> -#define SOCKET_1 1
> >>  #define EEPROM_I2C_PORT  4
> >>  #define EEPROM_PAGE_SIZE 0x40
> >>  #define MAC_ADDR_LEN 6
> >>  #define I2C_OFFSET_EEPROM_ETH0   (0xc00)
> >>  #define I2C_SLAVEADDR_EEPROM (0x52)
> >>  
> >> +#define SRAM_NIC_NCL1_OFFSET_FLAG   0xA0E87FE0
> >> +#define SRAM_NIC_NCL2_OFFSET_FLAG   0xA0E87FE4
> > 
> > Is this just a hard-coded address in SRAM? Where is it specified?
> > I don't think "_FLAG" is the correct name for this #define - this is
> > the actual offset value. So _OFFSET_ADDRESS would be more descriptive.
> 
> Yes, M7 firmware will read this two sram addresses.
> 
> > 
> >> +
> >>  #pragma pack(1)
> >>  typedef struct {
> >>UINT16 Crc16;
> >> @@ -114,204 +91,6 @@ UINT16 CrcTable16[256] = {
> >>0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0,
> >>  };
> >>  
> >> -EFI_STATUS
> >> -GetSfpSpeed (
> >> -  UINT16 Socket,
> >> -  UINT16 SfpNum,
> >> -  UINT8* FiberSpeed
> >> -  )
> >> -{
> >> -  EFI_STATUS  Status;
> >> -  I2C_DEVICE  SpdDev;
> >> -  UINT8   SfpSelect;
> >> -  UINT8   SfpSpeed;
> >> -  UINT32  RegAddr;
> >> -  UINT16  I2cAddr;
> >> -  UINT32  SfpPort;
> >> -
> >> -  SfpSpeed = 0x0;
> >> -  if (Socket == SOCKET_1) {
> >> -I2cAddr = CPU2_9545_I2C_ADDR;
> >> -SfpPort = CPU2_I2C_PORT_SFP;
> >> -  } else {
> >> -I2cAddr = CPU1_9545_I2C_ADDR;
> >> -SfpPort = I2C_PORT_SFP;
> >> -  }
> >> -
> >> -  Status = I2CInit (Socket, SfpPort, Normal);
> >> -  if (EFI_ERROR (Status)) {
> >> -DEBUG ((DEBUG_ERROR, "[%a]:[%dL] Socket%d Call I2CInit failed! 
> >> p1=0x%x.\n",
> >> -__FUNCTION__, __LINE__, Socket, Status));
> >> -return Status;
> >> -  }
> >> -
> >> -  SpdDev.Socket = Socket;
> >> -  SpdDev.DeviceType = DEVICE_TYPE_SPD;
> >> -  SpdDev.Port = SfpPort;
> >> -  SpdDev.SlaveDeviceAddress = I2cAddr;
> >> -  RegAddr = 0x0;
> >> -  

Re: [edk2] [PATCH edk2-non-osi v1 1/7] Hisilicon/D06: Optimize SAS driver for reducing boot time

2019-02-12 Thread Ming Huang



On 2/12/2019 11:20 PM, Leif Lindholm wrote:
> Change the subject line to:
> Hisilicon/D06: remove PCI enumeration dependency from SAS driver
> 
> On Fri, Feb 01, 2019 at 10:25:01PM +0800, Ming Huang wrote:
>> SAS controller is always existed, so accessing SAS register don't
>> depend on PciBusDxe (pci enumeration). Modify SAS driver remove the
>> dependence on pci enumeration.
> 
> And mention here that this is done to improve boot times.
> 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> ---
>>  Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex | Bin 216 -> 36 bytes
> 
> What are the remaining depexes?
> Do we have the opportunity to get rid of this .depex?

SAS driver is depended on IoInitDxe, IoInitDxe use the variable server, so add
variable dependence to let SAS driver run after IoInitDxe.

> 
> /
> Leif
> 
>>  Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi   | Bin 221312 -> 
>> 220640 bytes
>>  2 files changed, 0 insertions(+), 0 deletions(-)
>>
>> diff --git a/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex 
>> b/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex
>> index 1a5bc1e..e076777 100644
>> Binary files a/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex and 
>> b/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex differ
>> diff --git a/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi 
>> b/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi
>> index ac6bae7..4a29e8c 100644
>> Binary files a/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi and 
>> b/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi differ
>> -- 
>> 2.9.5
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-non-osi v1 7/7] Hisilicon/D06: Add Setup Item "Support DPC"

2019-02-12 Thread Leif Lindholm
On Fri, Feb 01, 2019 at 10:25:07PM +0800, Ming Huang wrote:
> Add setup item "Support DPC" to enable or disable PCIe DPC
> (Downstream Port Containment).
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang 

Reviewed-by: Leif Lindholm 

> ---
>  Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi | Bin 232832 -> 
> 226784 bytes
>  1 file changed, 0 insertions(+), 0 deletions(-)
> 
> diff --git a/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi 
> b/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi
> index e32c056..4511f6b 100644
> Binary files a/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi and 
> b/Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.efi differ
> -- 
> 2.9.5
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-non-osi v1 5/7] Hisilicon/D06: Use new flash layout

2019-02-12 Thread Leif Lindholm
On Fri, Feb 01, 2019 at 10:25:05PM +0800, Ming Huang wrote:
> In new flash layout, BIOS fd change from offset 1M to 8M in 16M
> spi flash.

I think I covered all of the layout questions in the corresponding
edk2-platforms patch.

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang 
> ---
>  Platform/Hisilicon/D06/CustomData.Fv | Bin 0 
> -> 65536 bytes
>  Platform/Hisilicon/D06/Library/OemAddressMapD06/OemAddressMapD06.lib | Bin 
> 61892 -> 31696 bytes

But can you explain why the size of this lib is _halved_?

/
Leif

>  Platform/Hisilicon/D06/Sec/FVMAIN_SEC.Fv | Bin 
> 1048576 -> 1048576 bytes
>  3 files changed, 0 insertions(+), 0 deletions(-)
> 
> diff --git a/Platform/Hisilicon/D06/CustomData.Fv 
> b/Platform/Hisilicon/D06/CustomData.Fv
> new file mode 100644
> index 000..22ef62b
> Binary files /dev/null and b/Platform/Hisilicon/D06/CustomData.Fv differ
> diff --git 
> a/Platform/Hisilicon/D06/Library/OemAddressMapD06/OemAddressMapD06.lib 
> b/Platform/Hisilicon/D06/Library/OemAddressMapD06/OemAddressMapD06.lib
> index 7e1f6b2..851c2c3 100644
> Binary files 
> a/Platform/Hisilicon/D06/Library/OemAddressMapD06/OemAddressMapD06.lib and 
> b/Platform/Hisilicon/D06/Library/OemAddressMapD06/OemAddressMapD06.lib differ
> diff --git a/Platform/Hisilicon/D06/Sec/FVMAIN_SEC.Fv 
> b/Platform/Hisilicon/D06/Sec/FVMAIN_SEC.Fv
> index 247e44e..7f75bc6 100644
> Binary files a/Platform/Hisilicon/D06/Sec/FVMAIN_SEC.Fv and 
> b/Platform/Hisilicon/D06/Sec/FVMAIN_SEC.Fv differ
> -- 
> 2.9.5
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms v1 11/16] Hisilicon/D06: Add Setup Item "Support DPC"

2019-02-12 Thread Ming Huang



On 2/12/2019 3:46 AM, Leif Lindholm wrote:
> On Fri, Feb 01, 2019 at 09:34:31PM +0800, Ming Huang wrote:
>> Add setup item "Support DPC" to enable or disable PCIe DPC
>> (Downstream Port Containment).
> 
> This patch also seems to disable the SRIOV configuration and delete a
> lot of ports. Can you explain how this is related?

The pcie menu is suppressed for original code as these menus are not ready,
this patch remove the suppression for pcie menu, so delete these menus for now.

Thanks.

> 
> /
> Leif
> 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> ---
>>  Silicon/Hisilicon/Include/Library/OemConfigData.h   |   1 +
>>  Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr  |   2 -
>>  Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c   |   4 +
>>  Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr| 197 
>> +---
>>  Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfigStrings.uni |   3 +-
>>  5 files changed, 10 insertions(+), 197 deletions(-)
>>
>> diff --git a/Silicon/Hisilicon/Include/Library/OemConfigData.h 
>> b/Silicon/Hisilicon/Include/Library/OemConfigData.h
>> index f120e3123c83..c0097d0829f0 100644
>> --- a/Silicon/Hisilicon/Include/Library/OemConfigData.h
>> +++ b/Silicon/Hisilicon/Include/Library/OemConfigData.h
>> @@ -49,6 +49,7 @@ typedef struct {
>>UINT8 OSWdtAction;
>>/*PCIe Config*/
>>UINT8 PcieSRIOVSupport;
>> +  UINT8 PcieDPCSupport;
>>UINT8 PciePort[PCIE_MAX_TOTAL_PORTS];
>>UINT8 PcieLinkSpeedPort[PCIE_MAX_TOTAL_PORTS];
>>UINT8 PcieLinkDeEmphasisPort[PCIE_MAX_TOTAL_PORTS];
>> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr 
>> b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
>> index 08236704fbfe..93ccb99bdc67 100644
>> --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
>> +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
>> @@ -62,11 +62,9 @@ formset
>>prompt = STRING_TOKEN(STR_IBMC_CONFIG_FORM_TITLE),
>>help   = STRING_TOKEN(STR_IBMC_CONFIG_FORM_HELP);
>>  
>> -suppressif TRUE;
>>  goto PCIE_CONFIG_FORM_ID,
>>prompt  = STRING_TOKEN(STR_PCIE_CONFIG_FORM_TITLE),
>>help= STRING_TOKEN(STR_PCIE_CONFIG_FORM_HELP);
>> -endif;
>>  
>>  goto MISC_CONFIG_FORM_ID,
>>prompt  = STRING_TOKEN(STR_MISC_CONFIG_FORM_TITLE),
>> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c 
>> b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
>> index 6668103af027..be4ce8820f73 100644
>> --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
>> +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
>> @@ -290,6 +290,10 @@ OemConfigUiLibConstructor (
>>Configuration.OSWdtTimeout = 5;
>>Configuration.OSWdtAction = 1;
>>//
>> +  //Set the default value of the PCIe option
>> +  //
>> +  Configuration.PcieDPCSupport = 0;
>> +  //
>>//Set the default value of the Misc option
>>//
>>Configuration.EnableSmmu = 1;
>> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr 
>> b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
>> index 7cf7cdd29ba2..c65907fe846e 100644
>> --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
>> +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/PcieConfig.hfr
>> @@ -17,203 +17,12 @@
>>  form formid = PCIE_CONFIG_FORM_ID,
>>title   = STRING_TOKEN (STR_PCIE_CONFIG_FORM_TITLE);
>>  
>> -  goto VFR_FORMID_PCIE_SOCKET0,
>> -prompt  = STRING_TOKEN (STR_PCIE_CPU_0_PROMPT),
>> -help= STRING_TOKEN (STR_PCIE_CPU_PROMPT_HELP);
>> -
>> -  goto VFR_FORMID_PCIE_SOCKET1,
>> -prompt  = STRING_TOKEN (STR_PCIE_CPU_1_PROMPT),
>> -help= STRING_TOKEN (STR_PCIE_CPU_PROMPT_HELP);
>> -
>> -  oneof varid  = OEM_CONFIG_DATA.PcieSRIOVSupport,
>> -prompt   = STRING_TOKEN (STR_SRIOV_SUPPORT_PROMPT),
>> -help = STRING_TOKEN (STR_SRIOV_SUPPORT_HELP),
>> +  oneof varid  = OEM_CONFIG_DATA.PcieDPCSupport,
>> +prompt   = STRING_TOKEN (STR_DPC_SUPPORT_PROMPT),
>> +help = STRING_TOKEN (STR_DPC_SUPPORT_HELP),
>>  option text = STRING_TOKEN (STR_DISABLE), value = 0, flags = 
>> MANUFACTURING | DEFAULT | RESET_REQUIRED;
>>  option text = STRING_TOKEN (STR_ENABLE),  value = 1, flags = 
>> RESET_REQUIRED;
>>endoneof;
>>  
>>  endform;
>>  
>> -form formid = VFR_FORMID_PCIE_SOCKET0,
>> -  title = STRING_TOKEN(STR_PCIE_CPU_0_PROMPT);
>> -
>> -  goto VFR_FORMID_PCIE_PORT2,
>> -prompt  = STRING_TOKEN(STR_PCIE_PORT_2_PROMPT),
>> -help= STRING_TOKEN(STR_PCIE_PORT_PROMPT_HELP);
>> -
>> -  goto VFR_FORMID_PCIE_PORT4,
>> -prompt  = STRING_TOKEN(STR_PCIE_PORT_4_PROMPT),
>> -help= STRING_TOKEN(STR_PCIE_PORT_PROMPT_HELP);
>> -
>> -  

[edk2] 3rd Party Python Packages

2019-02-12 Thread Carsey, Jaben
Note: deviating from "RE: [edk2] [Patch 0/3] BaseTools: Implement splitquoted 
function"

Laszlo,

Since I am working on some research related to this, I have a few follow up 
questions.

If there is significant performance improvement, how would you feel about 
requiring a 3rd party package to be installed (via pip I think)?
Would you feel more comfortable if BaseTools were able to run either with it or 
without (with performance differences)?

Basically there are potential performance improvements, but use of 3rd party 
python packages is instrumental for many of them.  

-Jaben

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Tuesday, February 12, 2019 6:02 AM
> To: Gao, Liming ; Feng, Bob C
> ; Bi, Dandan 
> Cc: edk2-devel@lists.01.org
> Subject: Re: [edk2] [Patch 0/3] BaseTools: Implement splitquoted function
> 
> On 02/12/19 14:33, Gao, Liming wrote:
> > Laszlo:
> >  To install python3-distutils should resolve this issue. I expect BaseTools
> build functionality doesn't depend on the third party python lib.
> 
> I completely agree with your expectation, regarding *3rd party* python
> packages. We shouldn't expect developers to install packages from
> repositories that fall outside of their normal distro repos.
> 
> However, my understanding was that python3-distutils should be available
> as a normal (not 3rd party) component on Ubuntu 18. I think we can
> expect developers to install additional packages if those packages are
> readily available in their normal (distro-provided) repos.
> 
> > So, I suggest to check whether python3-distutils is the native python
> library. If it is native python library, why Ubuntu18 doesn't include it. I 
> will
> work with Dandan to collect more information.
> 
> Right, that's exactly what I'm asking for. Thank you very much!
> Laszlo
> 
> >> -Original Message-
> >> From: Laszlo Ersek [mailto:ler...@redhat.com]
> >> Sent: Tuesday, February 12, 2019 8:24 PM
> >> To: Feng, Bob C ; Bi, Dandan
> 
> >> Cc: edk2-devel@lists.01.org; Gao, Liming 
> >> Subject: Re: [edk2] [Patch 0/3] BaseTools: Implement splitquoted
> function
> >>
> >> On 02/04/19 20:12, Laszlo Ersek wrote:
> >>> On 02/03/19 06:55, Feng, Bob C wrote:
>  BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1509
>  On some Linux environment, there may be no distutils.util
>  library for python3 that will cause build tool crash.
>  This patch implement distutils.util.split_quoted
>  in BaseTools so that the Basetools will be independent with
>  distutils.util library.
> 
>  Feng, Bob C (3):
>    BaseTools: Implement splitquoted function in Build tool
>    BaseTools: Implement splitquoted function in UPT
>    BaseTools: unit test for splitquoted function
> 
>   BaseTools/Source/Python/AutoGen/UniClassObject.py | 50
> ++
>   BaseTools/Source/Python/UPT/Library/UniClassObject.py | 47
> ---
>   BaseTools/Tests/TestStringSplit.py| 38
> ++
>   3 files changed, 128 insertions(+), 7 deletions(-)
>   create mode 100644 BaseTools/Tests/TestStringSplit.py
> 
> >>>
> >>> Is this really necessary? BZ#1509 references Ubuntu18; however it looks
> >>> like the issue can be resolved by a simple package installation on
> >>> Ubuntu 18:
> >>>
> >>> https://superuser.com/questions/1319047/cant-install-virtual-
> interpreter-in-pycharm-in-linux
> >>>
> >>> """
> >>> sudo apt-get install python3-distutils
> >>> """
> >>>
> >>> I'm not a Ubuntu user myself; so all I can do here (without installing a
> >>> Ubuntu18 VM) is check the Ubuntu package directory:
> >>>
> >>> https://packages.ubuntu.com/search?keywords=python3-
> distutils=names=all=all
> >>>
> >>> python3-distutils appears available for both "bionic (18.04LTS)" and
> >>> "cosmic (18.10)".
> >>>
> >>> Dandan, if you install python3-distutils, does that solve the issue for
> you?
> >>
> >> I'd still like to get an answer to my question, before the series is 
> >> pushed.
> >>
> >> Thanks,
> >> Laszlo
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-non-osi v1 4/7] Hisilicon/D06: Support PCIe local RAS

2019-02-12 Thread Leif Lindholm
On Fri, Feb 01, 2019 at 10:25:04PM +0800, Ming Huang wrote:
> Add some registers configuration in PcieRasInitDxe and add PCIe
> local RAS interrupt handle in trusted firmware to support PCIe
> local RAS.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang 

Reviewed-by: Leif Lindholm 

> ---
>  Platform/Hisilicon/D06/Drivers/PcieRasInitDxe/PcieRasInitDxe.efi | Bin 21248 
> -> 22048 bytes
>  Platform/Hisilicon/D06/bl1.bin   | Bin 12432 
> -> 12432 bytes
>  Platform/Hisilicon/D06/fip.bin   | Bin 
> 113450 -> 121866 bytes
>  3 files changed, 0 insertions(+), 0 deletions(-)
> 
> diff --git a/Platform/Hisilicon/D06/Drivers/PcieRasInitDxe/PcieRasInitDxe.efi 
> b/Platform/Hisilicon/D06/Drivers/PcieRasInitDxe/PcieRasInitDxe.efi
> index 0e22237..f9ceff2 100644
> Binary files 
> a/Platform/Hisilicon/D06/Drivers/PcieRasInitDxe/PcieRasInitDxe.efi and 
> b/Platform/Hisilicon/D06/Drivers/PcieRasInitDxe/PcieRasInitDxe.efi differ
> diff --git a/Platform/Hisilicon/D06/bl1.bin b/Platform/Hisilicon/D06/bl1.bin
> index 416535f..d0970e5 100644
> Binary files a/Platform/Hisilicon/D06/bl1.bin and 
> b/Platform/Hisilicon/D06/bl1.bin differ
> diff --git a/Platform/Hisilicon/D06/fip.bin b/Platform/Hisilicon/D06/fip.bin
> index c9b7ca0..795cfb5 100644
> Binary files a/Platform/Hisilicon/D06/fip.bin and 
> b/Platform/Hisilicon/D06/fip.bin differ
> -- 
> 2.9.5
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-non-osi v1 1/7] Hisilicon/D06: Optimize SAS driver for reducing boot time

2019-02-12 Thread Leif Lindholm
Change the subject line to:
Hisilicon/D06: remove PCI enumeration dependency from SAS driver

On Fri, Feb 01, 2019 at 10:25:01PM +0800, Ming Huang wrote:
> SAS controller is always existed, so accessing SAS register don't
> depend on PciBusDxe (pci enumeration). Modify SAS driver remove the
> dependence on pci enumeration.

And mention here that this is done to improve boot times.

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang 
> ---
>  Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex | Bin 216 -> 36 bytes

What are the remaining depexes?
Do we have the opportunity to get rid of this .depex?

/
Leif

>  Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi   | Bin 221312 -> 220640 
> bytes
>  2 files changed, 0 insertions(+), 0 deletions(-)
> 
> diff --git a/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex 
> b/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex
> index 1a5bc1e..e076777 100644
> Binary files a/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex and 
> b/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.depex differ
> diff --git a/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi 
> b/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi
> index ac6bae7..4a29e8c 100644
> Binary files a/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi and 
> b/Platform/Hisilicon/D06/Drivers/Sas/SasDriverDxe.efi differ
> -- 
> 2.9.5
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms v1 04/16] Hisilicon/D06: Fix access variable fail issue

2019-02-12 Thread Leif Lindholm
On Fri, Feb 01, 2019 at 09:34:24PM +0800, Ming Huang wrote:
> From: Jason Zhang 
> 
> BmcWdtEnable is a field of OemConfigData structure, need have
> runtime service attribution if use it during exit boot service

This sounds like a very shady thing to do.
Which module is seeing issues, and what issues are it seeing, during
ExitBootServices?

/
Leif

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang 
> ---
>  Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr | 2 +-
>  Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr 
> b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
> index 470e9ace3dcf..08236704fbfe 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfigVfr.vfr
> @@ -23,7 +23,7 @@ formset
>help  = STRING_TOKEN(STR_OEM_CONFIG),
>classguid = gEfiIfrFrontPageGuid,  // for MdeModule Bds.
>efivarstore OEM_CONFIG_DATA,
> -attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_NON_VOLATILE,
> +attribute = EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_NON_VOLATILE 
> | EFI_VARIABLE_RUNTIME_ACCESS,
>  name  = OemConfig,
>  guid  = gOemConfigGuid;
>  
> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c 
> b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
> index 012d45bc0214..6668103af027 100644
> --- a/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
> +++ b/Silicon/Hisilicon/Hi1620/Hi1620OemConfigUiLib/OemConfig.c
> @@ -316,7 +316,7 @@ OemConfigUiLibConstructor (
>Status = gRT->SetVariable (
>OEM_CONFIG_NAME,
>,
> -  EFI_VARIABLE_NON_VOLATILE | 
> EFI_VARIABLE_BOOTSERVICE_ACCESS,
> +  EFI_VARIABLE_NON_VOLATILE | 
> EFI_VARIABLE_BOOTSERVICE_ACCESS | EFI_VARIABLE_RUNTIME_ACCESS,
>sizeof (OEM_CONFIG_DATA),
>
>);
> -- 
> 2.9.5
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms v1 10/16] Hisilicon/D06: Modify for M7 self-Adapte support

2019-02-12 Thread Ming Huang



On 2/12/2019 3:28 AM, Leif Lindholm wrote:
> On Fri, Feb 01, 2019 at 09:34:30PM +0800, Ming Huang wrote:
>> As new M7(Cortex-M7) firmware support self-adapte, so do not
>> need BIOS to implement some function, remove useless funtions
>> and report CPU0/CPU1 Nic NCL offset to M7.
> 
> I don't really care that some other device in the system is a
> Cortex-A7. What is its function? Is it an SCP, an MCP, ?
> Please describe its function rather than its implementation.

M7 is used for HNS(Hisilicon network system), cpu access the network
component via M7.

> 
> What are the external dependencies?
> Is this addressed by one of the patches for edk2-non-osi?

This is depend on M7 firmware which will include in hpm file.

> 
> More style issues below.
> 
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> ---
>>  Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c | 272 
>> 
>>  1 file changed, 45 insertions(+), 227 deletions(-)
>>
>> diff --git a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c 
>> b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
>> index aaf990216982..9bf274e1b991 100644
>> --- a/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
>> +++ b/Platform/Hisilicon/D06/Library/OemNicLib/OemNicLib.c
>> @@ -21,44 +21,21 @@
>>  #include 
>>  
>>  #define CPU2_SFP2_100G_CARD_OFFSET   0x25
>> -#define CPU1_SFP1_LOCATE_OFFSET  0x16
>> -#define CPU1_SFP0_LOCATE_OFFSET  0x12
>> -#define CPU2_SFP1_LOCATE_OFFSET  0x21
>> -#define CPU2_SFP0_LOCATE_OFFSET  0x19
>> -#define CPU2_SFP2_10G_GE_CARD_OFFSET 0x25
>>  
>> -#define SFP_10G_SPEED   10
>> -#define SFP_25G_SPEED   25
>> -#define SFP_100G_SPEED  100
>> -#define SFP_GE_SPEED1
>> -
>> -#define SFP_GE_SPEED_VAL_VENDOR_FINISAR 0x0C
>> -#define SFP_GE_SPEED_VAL0x0D
>> -#define SFP_10G_SPEED_VAL   0x67
>> -#define SFP_25G_SPEED_VAL   0xFF
>> +#define SOCKET1_NET_PORT_100G 1
>> +#define SOCKET0_NET_PORT_NUM  4
>> +#define SOCKET1_NET_PORT_NUM  2
>>  
>>  #define CARD_PRESENT_100G   (BIT7)
>> -#define CARD_PRESENT_10G(BIT0)
>> -#define SELECT_SFP_BY_INDEX(index)  (1 << (index - 1))
>> -#define SPF_SPEED_OFFSET12
>> -
>> -#define SFP_DEVICE_ADDRESS 0x50
>> -#define CPU1_9545_I2C_ADDR 0x70
>> -#define CPU2_9545_I2C_ADDR 0x71
>> -
>> -#define FIBER_PRESENT 0
>> -#define CARD_PRESENT  1
>> -#define I2C_PORT_SFP  4
>> -#define CPU2_I2C_PORT_SFP 5
>> -
>> -#define SOCKET_0 0
>> -#define SOCKET_1 1
>>  #define EEPROM_I2C_PORT  4
>>  #define EEPROM_PAGE_SIZE 0x40
>>  #define MAC_ADDR_LEN 6
>>  #define I2C_OFFSET_EEPROM_ETH0   (0xc00)
>>  #define I2C_SLAVEADDR_EEPROM (0x52)
>>  
>> +#define SRAM_NIC_NCL1_OFFSET_FLAG   0xA0E87FE0
>> +#define SRAM_NIC_NCL2_OFFSET_FLAG   0xA0E87FE4
> 
> Is this just a hard-coded address in SRAM? Where is it specified?
> I don't think "_FLAG" is the correct name for this #define - this is
> the actual offset value. So _OFFSET_ADDRESS would be more descriptive.

Yes, M7 firmware will read this two sram addresses.

> 
>> +
>>  #pragma pack(1)
>>  typedef struct {
>>UINT16 Crc16;
>> @@ -114,204 +91,6 @@ UINT16 CrcTable16[256] = {
>>0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0,
>>  };
>>  
>> -EFI_STATUS
>> -GetSfpSpeed (
>> -  UINT16 Socket,
>> -  UINT16 SfpNum,
>> -  UINT8* FiberSpeed
>> -  )
>> -{
>> -  EFI_STATUS  Status;
>> -  I2C_DEVICE  SpdDev;
>> -  UINT8   SfpSelect;
>> -  UINT8   SfpSpeed;
>> -  UINT32  RegAddr;
>> -  UINT16  I2cAddr;
>> -  UINT32  SfpPort;
>> -
>> -  SfpSpeed = 0x0;
>> -  if (Socket == SOCKET_1) {
>> -I2cAddr = CPU2_9545_I2C_ADDR;
>> -SfpPort = CPU2_I2C_PORT_SFP;
>> -  } else {
>> -I2cAddr = CPU1_9545_I2C_ADDR;
>> -SfpPort = I2C_PORT_SFP;
>> -  }
>> -
>> -  Status = I2CInit (Socket, SfpPort, Normal);
>> -  if (EFI_ERROR (Status)) {
>> -DEBUG ((DEBUG_ERROR, "[%a]:[%dL] Socket%d Call I2CInit failed! 
>> p1=0x%x.\n",
>> -__FUNCTION__, __LINE__, Socket, Status));
>> -return Status;
>> -  }
>> -
>> -  SpdDev.Socket = Socket;
>> -  SpdDev.DeviceType = DEVICE_TYPE_SPD;
>> -  SpdDev.Port = SfpPort;
>> -  SpdDev.SlaveDeviceAddress = I2cAddr;
>> -  RegAddr = 0x0;
>> -  SfpSelect = SELECT_SFP_BY_INDEX (SfpNum);
>> -
>> -  Status = I2CWrite (, RegAddr, 1, );
>> -  if (EFI_ERROR (Status)) {
>> -DEBUG ((DEBUG_ERROR, "I2CWrite Error =%r.\n", Status));
>> -return Status;
>> -  }
>> -
>> -  SpdDev.Socket = Socket;
>> -  SpdDev.DeviceType = DEVICE_TYPE_SPD;
>> -  SpdDev.Port = SfpPort;
>> -  SpdDev.SlaveDeviceAddress = SFP_DEVICE_ADDRESS;
>> -
>> -  RegAddr = SPF_SPEED_OFFSET;
>> -  Status = I2CRead (, RegAddr, 1, );
>> -  if (EFI_ERROR (Status)) {
>> -DEBUG ((DEBUG_ERROR, "I2CRead Error =%r.\n", Status));
>> -return Status;
>> -  }
>> -
>> -  DEBUG ((DEBUG_INFO, 

Re: [edk2] [PATCH edk2-platforms v1 03/16] Hisilicon/D06: Optimize SAS driver for reducing boot time

2019-02-12 Thread Leif Lindholm
On Fri, Feb 01, 2019 at 09:34:23PM +0800, Ming Huang wrote:
> SAS controller is always existed, so accessing SAS register don't
> depend on PciBusDxe (pci enumeration).
> Move the SAS module early in D06.fdf for dispatching SAS driver
> early. This can avoid wait in BDS normally and reduce boot time.
> 
> This patch is relative with SasDriverDxe in edk2-non-osi.

I think you are saying that this change is only valid after the
update to SasDriverDxe in edk2-non-osi has been applied?
Or does it mean that it only improves performance after that
edk2-non-osi patch has been applied?

Please be more explicit in the commit message.

Other than that. I'm OK with this patch.

/
Leif

> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang 
> ---
>  Platform/Hisilicon/D06/D06.fdf | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Platform/Hisilicon/D06/D06.fdf b/Platform/Hisilicon/D06/D06.fdf
> index a937660a09e2..d495ad7f264c 100644
> --- a/Platform/Hisilicon/D06/D06.fdf
> +++ b/Platform/Hisilicon/D06/D06.fdf
> @@ -165,6 +165,7 @@ [FV.FvMain]
>INF MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
>  
>INF Platform/Hisilicon/D06/Drivers/IoInitDxe/IoInitDxe.inf
> +  INF Platform/Hisilicon/D06/Drivers/Sas/SasDxeDriver.inf
>#
># PI DXE Drivers producing Architectural Protocols (EFI Services)
>#
> @@ -296,7 +297,6 @@ [FV.FvMain]
>#
>INF Platform/Hisilicon/D06/Drivers/Sm750Dxe/UefiSmi.inf
>INF MdeModulePkg/Bus/Pci/NvmExpressDxe/NvmExpressDxe.inf
> -  INF Platform/Hisilicon/D06/Drivers/Sas/SasDxeDriver.inf
>INF MdeModulePkg/Bus/Pci/SataControllerDxe/SataControllerDxe.inf
>INF MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AtaAtapiPassThru.inf
>INF MdeModulePkg/Bus/Ata/AtaBusDxe/AtaBusDxe.inf
> -- 
> 2.9.5
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-platforms v1 08/16] Hisilicon/D06: Change HCCS speed from 30G to 26G

2019-02-12 Thread Leif Lindholm
On Tue, Feb 12, 2019 at 10:45:05PM +0800, Ming Huang wrote:
> 
> 
> On 2/12/2019 2:36 AM, Leif Lindholm wrote:
> > On Fri, Feb 01, 2019 at 09:34:28PM +0800, Ming Huang wrote:
> >> Follow chip team suggestion to change HCCS(Huawei Cache-Coherent
> >> System) speed from 30G to 26G, this modification can avoid some
> >> unstable stress issue.
> >>
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Ming Huang 
> >> ---
> >>  Silicon/Hisilicon/Include/Library/OemMiscLib.h   | 10 
> >> ++
> >>  Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c |  8 
> >>  2 files changed, 18 insertions(+)
> >>
> >> diff --git a/Silicon/Hisilicon/Include/Library/OemMiscLib.h 
> >> b/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> >> index dfac87d635d9..3c0cd0319122 100644
> >> --- a/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> >> +++ b/Silicon/Hisilicon/Include/Library/OemMiscLib.h
> >> @@ -22,6 +22,11 @@
> >>  #include 
> >>  #include 
> >>  
> >> +#define HCCS_PLL_VALUE_3000  0x52240781
> >> +#define HCCS_PLL_VALUE_2600  0x52240681
> >> +#define HCCS_PLL_VALUE_2800  0x52240701
> > 
> > Could these be described by a proper macro instead of just values?
> > A cursory glance suggests that an increase of 0x80 in the lower half
> > means 200MHz.
> > 
> > If not, please sort them by frequency, ascending.
> 
> As the macros have use in other files, I prefer sort them by frequency.
> 
> > 
> >> +
> >> +
> >>  #define PCIEDEVICE_REPORT_MAX  8
> >>  #define MAX_PROCESSOR_SOCKETS  MAX_SOCKET
> >>  #define MAX_MEMORY_CHANNELSMAX_CHANNEL
> >> @@ -55,4 +60,9 @@ extern EFI_STRING_ID 
> >> gDimmToDevLocator[MAX_SOCKET][MAX_CHANNEL][MAX_DIMM];
> >>  EFI_HII_HANDLE EFIAPI OemGetPackages ();
> >>  UINTN OemGetCpuFreq (UINT8 Socket);
> >>  
> >> +UINTN
> >> +OemGetHccsFreq (
> >> +  VOID
> >> +  );
> >> +
> >>  #endif
> >> diff --git a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c 
> >> b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> >> index 8f2ac308c7b9..83e53cfeb5dd 100644
> >> --- a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> >> +++ b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
> >> @@ -223,3 +223,11 @@ UINTN OemGetCpuFreq (UINT8 Socket)
> >>}
> >>  }
> >>  
> >> +UINTN
> >> +OemGetHccsFreq (
> > 
> > The commit message describes this patch as changing the frequency.
> > The actual code simply returns a value.
> > The name of the function returning this value suggests the value is a
> > frequency>
> >> +  VOID
> >> +  )
> >> +{
> >> +  return HCCS_PLL_VALUE_2600;
> > 
> > But the constant returned is named suggesting a PLL configuration
> > value. And the frequency suggested by the name is many orders of
> > magnitude below that described by the commit message.
> 
> Yes, the macros and function name are not very matched.
> I plan to modify the commit title and message:
> Hisilicon/D06: Use HCCS speed with 2.6G
> 
> Follow chip team suggestion, HCCS(Huawei Cache-Coherent System)
> may be unstable while speed is 3.0G, so use 2.6G to avoid some
> unstable stress issue.

This all sounds good, thanks.

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


Re: [edk2] [PATCH edk2-platforms v1 08/16] Hisilicon/D06: Change HCCS speed from 30G to 26G

2019-02-12 Thread Ming Huang



On 2/12/2019 2:36 AM, Leif Lindholm wrote:
> On Fri, Feb 01, 2019 at 09:34:28PM +0800, Ming Huang wrote:
>> Follow chip team suggestion to change HCCS(Huawei Cache-Coherent
>> System) speed from 30G to 26G, this modification can avoid some
>> unstable stress issue.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> ---
>>  Silicon/Hisilicon/Include/Library/OemMiscLib.h   | 10 ++
>>  Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c |  8 
>>  2 files changed, 18 insertions(+)
>>
>> diff --git a/Silicon/Hisilicon/Include/Library/OemMiscLib.h 
>> b/Silicon/Hisilicon/Include/Library/OemMiscLib.h
>> index dfac87d635d9..3c0cd0319122 100644
>> --- a/Silicon/Hisilicon/Include/Library/OemMiscLib.h
>> +++ b/Silicon/Hisilicon/Include/Library/OemMiscLib.h
>> @@ -22,6 +22,11 @@
>>  #include 
>>  #include 
>>  
>> +#define HCCS_PLL_VALUE_3000  0x52240781
>> +#define HCCS_PLL_VALUE_2600  0x52240681
>> +#define HCCS_PLL_VALUE_2800  0x52240701
> 
> Could these be described by a proper macro instead of just values?
> A cursory glance suggests that an increase of 0x80 in the lower half
> means 200MHz.
> 
> If not, please sort them by frequency, ascending.

As the macros have use in other files, I prefer sort them by frequency.

> 
>> +
>> +
>>  #define PCIEDEVICE_REPORT_MAX  8
>>  #define MAX_PROCESSOR_SOCKETS  MAX_SOCKET
>>  #define MAX_MEMORY_CHANNELSMAX_CHANNEL
>> @@ -55,4 +60,9 @@ extern EFI_STRING_ID 
>> gDimmToDevLocator[MAX_SOCKET][MAX_CHANNEL][MAX_DIMM];
>>  EFI_HII_HANDLE EFIAPI OemGetPackages ();
>>  UINTN OemGetCpuFreq (UINT8 Socket);
>>  
>> +UINTN
>> +OemGetHccsFreq (
>> +  VOID
>> +  );
>> +
>>  #endif
>> diff --git a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c 
>> b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
>> index 8f2ac308c7b9..83e53cfeb5dd 100644
>> --- a/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
>> +++ b/Platform/Hisilicon/D06/Library/OemMiscLibD06/OemMiscLibD06.c
>> @@ -223,3 +223,11 @@ UINTN OemGetCpuFreq (UINT8 Socket)
>>}
>>  }
>>  
>> +UINTN
>> +OemGetHccsFreq (
> 
> The commit message describes this patch as changing the frequency.
> The actual code simply returns a value.
> The name of the function returning this value suggests the value is a
> frequency>
>> +  VOID
>> +  )
>> +{
>> +  return HCCS_PLL_VALUE_2600;
> 
> But the constant returned is named suggesting a PLL configuration
> value. And the frequency suggested by the name is many orders of
> magnitude below that described by the commit message.

Yes, the macros and function name are not very matched.
I plan to modify the commit title and message:
Hisilicon/D06: Use HCCS speed with 2.6G

Follow chip team suggestion, HCCS(Huawei Cache-Coherent System)
may be unstable while speed is 3.0G, so use 2.6G to avoid some
unstable stress issue.

Thanks.

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


Re: [edk2] [Patch 0/3] BaseTools: Implement splitquoted function

2019-02-12 Thread Laszlo Ersek
On 02/12/19 14:33, Gao, Liming wrote:
> Laszlo:
>  To install python3-distutils should resolve this issue. I expect BaseTools 
> build functionality doesn't depend on the third party python lib.

I completely agree with your expectation, regarding *3rd party* python
packages. We shouldn't expect developers to install packages from
repositories that fall outside of their normal distro repos.

However, my understanding was that python3-distutils should be available
as a normal (not 3rd party) component on Ubuntu 18. I think we can
expect developers to install additional packages if those packages are
readily available in their normal (distro-provided) repos.

> So, I suggest to check whether python3-distutils is the native python 
> library. If it is native python library, why Ubuntu18 doesn't include it. I 
> will work with Dandan to collect more information. 

Right, that's exactly what I'm asking for. Thank you very much!
Laszlo

>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Tuesday, February 12, 2019 8:24 PM
>> To: Feng, Bob C ; Bi, Dandan 
>> Cc: edk2-devel@lists.01.org; Gao, Liming 
>> Subject: Re: [edk2] [Patch 0/3] BaseTools: Implement splitquoted function
>>
>> On 02/04/19 20:12, Laszlo Ersek wrote:
>>> On 02/03/19 06:55, Feng, Bob C wrote:
 BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1509
 On some Linux environment, there may be no distutils.util
 library for python3 that will cause build tool crash.
 This patch implement distutils.util.split_quoted
 in BaseTools so that the Basetools will be independent with
 distutils.util library.

 Feng, Bob C (3):
   BaseTools: Implement splitquoted function in Build tool
   BaseTools: Implement splitquoted function in UPT
   BaseTools: unit test for splitquoted function

  BaseTools/Source/Python/AutoGen/UniClassObject.py | 50 
 ++
  BaseTools/Source/Python/UPT/Library/UniClassObject.py | 47 
 ---
  BaseTools/Tests/TestStringSplit.py| 38 
 ++
  3 files changed, 128 insertions(+), 7 deletions(-)
  create mode 100644 BaseTools/Tests/TestStringSplit.py

>>>
>>> Is this really necessary? BZ#1509 references Ubuntu18; however it looks
>>> like the issue can be resolved by a simple package installation on
>>> Ubuntu 18:
>>>
>>> https://superuser.com/questions/1319047/cant-install-virtual-interpreter-in-pycharm-in-linux
>>>
>>> """
>>> sudo apt-get install python3-distutils
>>> """
>>>
>>> I'm not a Ubuntu user myself; so all I can do here (without installing a
>>> Ubuntu18 VM) is check the Ubuntu package directory:
>>>
>>> https://packages.ubuntu.com/search?keywords=python3-distutils=names=all=all
>>>
>>> python3-distutils appears available for both "bionic (18.04LTS)" and
>>> "cosmic (18.10)".
>>>
>>> Dandan, if you install python3-distutils, does that solve the issue for you?
>>
>> I'd still like to get an answer to my question, before the series is pushed.
>>
>> Thanks,
>> Laszlo

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


Re: [edk2] [PATCH 3/3] UefiCpuPkg/SecCore: Support EFI_PEI_CORE_FV_LOCATION_PPI

2019-02-12 Thread Laszlo Ersek
On 02/12/19 14:19, Chasel, Chiu wrote:
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1524
> 
> EFI_PEI_CORE_FV_LOCATION_PPI may be passed by platform
> when PeiCore not in BFV so SecCore has to search PeiCore
> either from the FV location provided by
> EFI_PEI_CORE_FV_LOCATION_PPI or from BFV.
> 
> Test: Verified on internal platform and booting successfully.
> 
> Cc: Eric Dong 
> Cc: Ray Ni 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chasel Chiu 
> ---
>  UefiCpuPkg/SecCore/SecMain.c   | 35 +--
>  UefiCpuPkg/SecCore/SecCore.inf |  3 ++-
>  UefiCpuPkg/SecCore/SecMain.h   |  3 ++-
>  3 files changed, 33 insertions(+), 8 deletions(-)

Thank you for the CC. OVMF doesn't consume this module, so I'll pass on
this review.

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


Re: [edk2] [Patch 0/3] BaseTools: Implement splitquoted function

2019-02-12 Thread Gao, Liming
Laszlo:
 To install python3-distutils should resolve this issue. I expect BaseTools 
build functionality doesn't depend on the third party python lib. So, I suggest 
to check whether python3-distutils is the native python library. If it is 
native python library, why Ubuntu18 doesn't include it. I will work with Dandan 
to collect more information. 

Thanks
Liming
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Tuesday, February 12, 2019 8:24 PM
> To: Feng, Bob C ; Bi, Dandan 
> Cc: edk2-devel@lists.01.org; Gao, Liming 
> Subject: Re: [edk2] [Patch 0/3] BaseTools: Implement splitquoted function
> 
> On 02/04/19 20:12, Laszlo Ersek wrote:
> > On 02/03/19 06:55, Feng, Bob C wrote:
> >> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1509
> >> On some Linux environment, there may be no distutils.util
> >> library for python3 that will cause build tool crash.
> >> This patch implement distutils.util.split_quoted
> >> in BaseTools so that the Basetools will be independent with
> >> distutils.util library.
> >>
> >> Feng, Bob C (3):
> >>   BaseTools: Implement splitquoted function in Build tool
> >>   BaseTools: Implement splitquoted function in UPT
> >>   BaseTools: unit test for splitquoted function
> >>
> >>  BaseTools/Source/Python/AutoGen/UniClassObject.py | 50 
> >> ++
> >>  BaseTools/Source/Python/UPT/Library/UniClassObject.py | 47 
> >> ---
> >>  BaseTools/Tests/TestStringSplit.py| 38 
> >> ++
> >>  3 files changed, 128 insertions(+), 7 deletions(-)
> >>  create mode 100644 BaseTools/Tests/TestStringSplit.py
> >>
> >
> > Is this really necessary? BZ#1509 references Ubuntu18; however it looks
> > like the issue can be resolved by a simple package installation on
> > Ubuntu 18:
> >
> > https://superuser.com/questions/1319047/cant-install-virtual-interpreter-in-pycharm-in-linux
> >
> > """
> > sudo apt-get install python3-distutils
> > """
> >
> > I'm not a Ubuntu user myself; so all I can do here (without installing a
> > Ubuntu18 VM) is check the Ubuntu package directory:
> >
> > https://packages.ubuntu.com/search?keywords=python3-distutils=names=all=all
> >
> > python3-distutils appears available for both "bionic (18.04LTS)" and
> > "cosmic (18.10)".
> >
> > Dandan, if you install python3-distutils, does that solve the issue for you?
> 
> I'd still like to get an answer to my question, before the series is pushed.
> 
> Thanks,
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH 1/3] MdePkg: Support EFI_PEI_CORE_FV_LOCATION_PPI

2019-02-12 Thread Chasel, Chiu
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1524

Add EFI_PEI_CORE_FV_LOCATION_PPI definition basing on
PI spec 1.7, Section 6.3.9.
This PPI can support the secnario that PEI Foundation
not in BFV.

Cc: Michael D Kinney 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chasel Chiu 
---
 MdePkg/Include/Ppi/PeiCoreFvLocation.h | 53 
+
 MdePkg/MdePkg.dec  | 11 +--
 2 files changed, 62 insertions(+), 2 deletions(-)

diff --git a/MdePkg/Include/Ppi/PeiCoreFvLocation.h 
b/MdePkg/Include/Ppi/PeiCoreFvLocation.h
new file mode 100644
index 00..c7bbbfb265
--- /dev/null
+++ b/MdePkg/Include/Ppi/PeiCoreFvLocation.h
@@ -0,0 +1,53 @@
+/** @file
+  Header file for Pei Core FV Location PPI.
+
+  This PPI contains a pointer to the firmware volume which contains the PEI 
Foundation.
+  If the PEI Foundation does not reside in the BFV, then SEC must pass this 
PPI as a part
+  of the PPI list provided to the PEI Foundation Entry Point, otherwise the 
PEI Foundation
+  shall assume that it resides within the BFV.
+
+  Copyright (c) 2019, 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.
+
+  @par Revision Reference:
+  This PPI is defined in UEFI Platform Initialization Specification 1.7 Volume 
1:
+  Standards
+
+**/
+
+
+#ifndef _EFI_PEI_CORE_FV_LOCATION_H_
+#define _EFI_PEI_CORE_FV_LOCATION_H_
+
+///
+/// Global ID for EFI_PEI_CORE_FV_LOCATION_PPI
+///
+#define EFI_PEI_CORE_FV_LOCATION_GUID \
+  { \
+0x52888eae, 0x5b10, 0x47d0, {0xa8, 0x7f, 0xb8, 0x22, 0xab, 0xa0, 0xca, 
0xf4 } \
+  }
+
+///
+/// Forward declaration for EFI_PEI_CORE_FV_LOCATION_PPI
+///
+typedef struct _EFI_PEI_CORE_FV_LOCATION_PPI EFI_PEI_CORE_FV_LOCATION_PPI;
+
+///
+/// This PPI provides location of EFI PeiCoreFv.
+///
+struct _EFI_PEI_CORE_FV_LOCATION_PPI {
+  ///
+  /// Pointer to the first byte of the firmware volume which contains the PEI 
Foundation.
+  ///
+  VOID*PeiCoreFvLocation;
+};
+
+extern EFI_GUID gEfiPeiCoreFvLocationPpiGuid;
+
+#endif // _EFI_PEI_CORE_FV_LOCATION_H_
diff --git a/MdePkg/MdePkg.dec b/MdePkg/MdePkg.dec
index a485408310..c859b4a511 100644
--- a/MdePkg/MdePkg.dec
+++ b/MdePkg/MdePkg.dec
@@ -2,9 +2,9 @@
 # This Package provides all definitions, library classes and libraries 
instances.
 #
 # It also provides the definitions(including PPIs/PROTOCOLs/GUIDs) of
-# EFI1.10/UEFI2.7/PI1.6 and some Industry Standards.
+# EFI1.10/UEFI2.7/PI1.7 and some Industry Standards.
 #
-# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
+# Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
 # Portions copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
 # (C) Copyright 2016 Hewlett Packard Enterprise Development LP
 #
@@ -929,6 +929,13 @@
   ## Include/Ppi/SecHobData.h
   gEfiSecHobDataPpiGuid = { 0x3ebdaf20, 0x6667, 0x40d8, {0xb4, 0xee, 0xf5, 
0x99, 0x9a, 0xc1, 0xb7, 0x1f } }
 
+  #
+  # PPIs defined in PI 1.7.
+  #
+
+  ## Include/Ppi/PeiCoreFvLocation.h
+  gEfiPeiCoreFvLocationPpiGuid   = { 0x52888eae, 0x5b10, 0x47d0, { 0xa8, 0x7f, 
0xb8, 0x22, 0xab, 0xa0, 0xca, 0xf4 }}
+
 [Protocols]
   ## Include/Protocol/Pcd.h
   gPcdProtocolGuid   = { 0x11B34006, 0xD85B, 0x4D0A, { 0xA2, 0x90, 
0xD5, 0xA5, 0x71, 0x31, 0x0E, 0xF7 }}
-- 
2.13.3.windows.1

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


[edk2] [PATCH 3/3] UefiCpuPkg/SecCore: Support EFI_PEI_CORE_FV_LOCATION_PPI

2019-02-12 Thread Chasel, Chiu
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1524

EFI_PEI_CORE_FV_LOCATION_PPI may be passed by platform
when PeiCore not in BFV so SecCore has to search PeiCore
either from the FV location provided by
EFI_PEI_CORE_FV_LOCATION_PPI or from BFV.

Test: Verified on internal platform and booting successfully.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chasel Chiu 
---
 UefiCpuPkg/SecCore/SecMain.c   | 35 +--
 UefiCpuPkg/SecCore/SecCore.inf |  3 ++-
 UefiCpuPkg/SecCore/SecMain.h   |  3 ++-
 3 files changed, 33 insertions(+), 8 deletions(-)

diff --git a/UefiCpuPkg/SecCore/SecMain.c b/UefiCpuPkg/SecCore/SecMain.c
index b24e190617..b99072599d 100644
--- a/UefiCpuPkg/SecCore/SecMain.c
+++ b/UefiCpuPkg/SecCore/SecMain.c
@@ -1,7 +1,7 @@
 /** @file
   C functions in SEC
 
-  Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2008 - 2019, 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
@@ -228,26 +228,49 @@ SecStartupPhase2(
 {
   EFI_SEC_PEI_HAND_OFF*SecCoreData;
   EFI_PEI_PPI_DESCRIPTOR  *PpiList;
+  EFI_PEI_PPI_DESCRIPTOR  *PpiListTmp;
   UINT32  Index;
   EFI_PEI_PPI_DESCRIPTOR  *AllSecPpiList;
   EFI_PEI_CORE_ENTRY_POINTPeiCoreEntryPoint;
 
+  PeiCoreEntryPoint = NULL;
   SecCoreData   = (EFI_SEC_PEI_HAND_OFF *) Context;
   AllSecPpiList = (EFI_PEI_PPI_DESCRIPTOR *) SecCoreData->PeiTemporaryRamBase;
+
   //
   // Find Pei Core entry point. It will report SEC and Pei Core debug 
information if remote debug
   // is enabled.
   //
-  FindAndReportEntryPoints ((EFI_FIRMWARE_VOLUME_HEADER *) 
SecCoreData->BootFirmwareVolumeBase, );
-  if (PeiCoreEntryPoint == NULL)
-  {
-CpuDeadLoop ();
+  PpiList = SecPlatformMain (SecCoreData);
+  PpiListTmp = PpiList;
+  for (;;) {
+if (CompareGuid (PpiListTmp->Guid, ) && 
(((EFI_PEI_CORE_FV_LOCATION_PPI *) PpiListTmp->Ppi)->PeiCoreFvLocation != 0)) {
+  FindAndReportEntryPoints ((EFI_FIRMWARE_VOLUME_HEADER *) 
((EFI_PEI_CORE_FV_LOCATION_PPI *) PpiListTmp->Ppi)->PeiCoreFvLocation, 
);
+  if (PeiCoreEntryPoint != NULL) {
+break;
+  }
+}
+if ((PpiListTmp->Flags & EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST) == 
EFI_PEI_PPI_DESCRIPTOR_TERMINATE_LIST) {
+  //
+  // Continue until the end of the PPI List.
+  //
+  break;
+}
+PpiListTmp++;
+  }
+  //
+  // If EFI_PEI_CORE_FV_LOCATION_PPI not found or no PeiCore found by the 
pointer in provided PPI, try to locate PeiCore from BFV.
+  //
+  if (PeiCoreEntryPoint == NULL) {
+FindAndReportEntryPoints ((EFI_FIRMWARE_VOLUME_HEADER *) 
SecCoreData->BootFirmwareVolumeBase, );
+if (PeiCoreEntryPoint == NULL) {
+  CpuDeadLoop ();
+}
   }
 
   //
   // Perform platform specific initialization before entering PeiCore.
   //
-  PpiList = SecPlatformMain (SecCoreData);
   if (PpiList != NULL) {
 //
 // Remove the terminal flag from the terminal PPI
diff --git a/UefiCpuPkg/SecCore/SecCore.inf b/UefiCpuPkg/SecCore/SecCore.inf
index 442f663911..fc1485b5cb 100644
--- a/UefiCpuPkg/SecCore/SecCore.inf
+++ b/UefiCpuPkg/SecCore/SecCore.inf
@@ -7,7 +7,7 @@
 #  protected mode, setup flat memory model, enable temporary memory and
 #  call into SecStartup().
 #
-#  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2006 - 2019, 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
@@ -73,6 +73,7 @@
   ## NOTIFY
   ## SOMETIMES_CONSUMES
   gPeiSecPerformancePpiGuid
+  gEfiPeiCoreFvLocationPpiGuid
 
 [Guids]
   ## SOMETIMES_PRODUCES   ## HOB
diff --git a/UefiCpuPkg/SecCore/SecMain.h b/UefiCpuPkg/SecCore/SecMain.h
index 83244af119..80045d34f4 100644
--- a/UefiCpuPkg/SecCore/SecMain.h
+++ b/UefiCpuPkg/SecCore/SecMain.h
@@ -1,7 +1,7 @@
 /** @file
   Master header file for SecCore.
 
-  Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2008 - 2019, 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
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
-- 
2.13.3.windows.1

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


[edk2] [PATCH 2/3] MdeModulePkg/PeiMain: Support EFI_PEI_CORE_FV_LOCATION_PPI

2019-02-12 Thread Chasel, Chiu
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1524

When shadowing PeiCore the EFI_PEI_CORE_FV_LOCATION_PPI
should be checked to see if PeiCore not in BFV, otherwise
just shadowing PeiCore from BFV.

Test: Verified on internal platform and booting successfully.

Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chasel Chiu 
---
 MdeModulePkg/Core/Pei/PeiMain/PeiMain.c | 58 
+-
 MdeModulePkg/Core/Pei/PeiMain.h |  3 ++-
 MdeModulePkg/Core/Pei/PeiMain.inf   |  3 ++-
 3 files changed, 49 insertions(+), 15 deletions(-)

diff --git a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c 
b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
index 4da80a8222..408f24c216 100644
--- a/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
+++ b/MdeModulePkg/Core/Pei/PeiMain/PeiMain.c
@@ -1,7 +1,7 @@
 /** @file
   Pei Core Main Entry Point
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, 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
@@ -80,23 +80,55 @@ ShadowPeiCore (
   IN PEI_CORE_INSTANCE  *PrivateData
   )
 {
-  EFI_PEI_FILE_HANDLE  PeiCoreFileHandle;
-  EFI_PHYSICAL_ADDRESS EntryPoint;
-  EFI_STATUS   Status;
-  UINT32   AuthenticationState;
+  EFI_PEI_FILE_HANDLE  PeiCoreFileHandle;
+  EFI_PHYSICAL_ADDRESS EntryPoint;
+  EFI_STATUS   Status;
+  UINT32   AuthenticationState;
+  UINTNIndex;
+  EFI_PEI_CORE_FV_LOCATION_PPI *PeiCoreFvLocationPpi;
 
   PeiCoreFileHandle = NULL;
 
   //
-  // Find the PEI Core in the BFV
+  // Find the PEI Core either from EFI_PEI_CORE_FV_LOCATION_PPI indicated FV 
or BFV
   //
-  Status = PrivateData->Fv[0].FvPpi->FindFileByType (
-   PrivateData->Fv[0].FvPpi,
-   EFI_FV_FILETYPE_PEI_CORE,
-   PrivateData->Fv[0].FvHandle,
-   
-   );
-  ASSERT_EFI_ERROR (Status);
+  Status = PeiServicesLocatePpi (
+ ,
+ 0,
+ NULL,
+ (VOID **) 
+ );
+  if (!EFI_ERROR (Status) && (PeiCoreFvLocationPpi->PeiCoreFvLocation != 
NULL)) {
+//
+// If PeiCoreFvLocation present, the PEI Core should be found from 
indicated FV.
+//
+for (Index = 0; Index < PrivateData->FvCount; Index ++) {
+  if ((UINT32) PrivateData->Fv[Index].FvHandle != (UINT32) 
PeiCoreFvLocationPpi->PeiCoreFvLocation) {
+continue;
+  }
+  Status = PrivateData->Fv[Index].FvPpi->FindFileByType (
+   PrivateData->Fv[Index].FvPpi,
+   EFI_FV_FILETYPE_PEI_CORE,
+   PrivateData->Fv[Index].FvHandle,
+   
+   );
+  if (!EFI_ERROR (Status)) {
+break;
+  }
+}
+ASSERT (Index < PrivateData->FvCount);
+  } else {
+//
+// Find PEI Core from BFV
+//
+Status = PrivateData->Fv[0].FvPpi->FindFileByType (
+ PrivateData->Fv[0].FvPpi,
+ EFI_FV_FILETYPE_PEI_CORE,
+ PrivateData->Fv[0].FvHandle,
+ 
+ );
+ASSERT_EFI_ERROR (Status);
+  }
 
   //
   // Shadow PEI Core into memory so it will run faster
diff --git a/MdeModulePkg/Core/Pei/PeiMain.h b/MdeModulePkg/Core/Pei/PeiMain.h
index 322e7cd845..38542ab072 100644
--- a/MdeModulePkg/Core/Pei/PeiMain.h
+++ b/MdeModulePkg/Core/Pei/PeiMain.h
@@ -1,7 +1,7 @@
 /** @file
   Definition of Pei Core Structures and Services
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, 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
@@ -49,6 +49,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #include 
 #include 
 #include 
+#include 
 
 ///
 /// It is an FFS type extension used for PeiFindFileEx. It indicates current
diff --git a/MdeModulePkg/Core/Pei/PeiMain.inf 
b/MdeModulePkg/Core/Pei/PeiMain.inf
index 140cb1..5bab2aab8c 100644
--- a/MdeModulePkg/Core/Pei/PeiMain.inf
+++ b/MdeModulePkg/Core/Pei/PeiMain.inf
@@ -6,7 +6,7 @@
 # 2) Dispatch PEIM from 

[edk2] [PATCH 0/3] Support EFI_PEI_CORE_FV_LOCATION_PPI

2019-02-12 Thread Chasel, Chiu
PI spec 1.7 section 6.3.9 has defined a PPI to support the scenario
that PEI Foundation not in BFV. EFI_PEI_CORE_FV_LOCATION_PPI reports
the FV which contains PEI Foundation and should be passed by SEC as
part of PPI list. Otherwise PEI Foundation shall assume that it
resides in BFV.

Patch1: Add EFI_PEI_CORE_FV_LOCATION_PPI definition.
Patch2: Support PeiCore not in BFV scenario when shadowing.
Patch3: SecCore to find PeiCore from either non-BFV or BFV.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao Wu 
Cc: Ray Ni 
Cc: Star Zeng 
Cc: Eric Dong 
Cc: Laszlo Ersek 

Chasel, Chiu (3):
  MdePkg: Support EFI_PEI_CORE_FV_LOCATION_PPI
  MdeModulePkg/PeiMain: Support EFI_PEI_CORE_FV_LOCATION_PPI
  UefiCpuPkg/SecCore: Support EFI_PEI_CORE_FV_LOCATION_PPI

 MdeModulePkg/Core/Pei/PeiMain/PeiMain.c | 58 
+-
 UefiCpuPkg/SecCore/SecMain.c| 35 
+--
 MdeModulePkg/Core/Pei/PeiMain.h |  3 ++-
 MdeModulePkg/Core/Pei/PeiMain.inf   |  3 ++-
 MdePkg/Include/Ppi/PeiCoreFvLocation.h  | 53 
+
 MdePkg/MdePkg.dec   | 11 +--
 UefiCpuPkg/SecCore/SecCore.inf  |  3 ++-
 UefiCpuPkg/SecCore/SecMain.h|  3 ++-
 8 files changed, 144 insertions(+), 25 deletions(-)
 create mode 100644 MdePkg/Include/Ppi/PeiCoreFvLocation.h

-- 
2.13.3.windows.1

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


[edk2] [PATCH edk2-non-osi v2 1/1] Platform/Socionext: uprev TF-A binary

2019-02-12 Thread Sumit Garg
Update TF-A to upstream v2.0 release + synquacer-spm changes
(Commit: e86e202c2e4e).
Also update OP-TEE to upstream v3.4.0 release (Commit: 406c609bbf08).

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Sumit Garg 
---

Changes in v2:

Include synquacer-spm patches and some internal workarounds for TF-A.

Following is reference repo to pull this patch:
ssh://g...@git.linaro.org/people/sumit.garg/edk2-non-osi.git

 Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin | Bin 415251 -> 402960 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)

diff --git a/Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin 
b/Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin
index bc6f4563a5d6..f6f4f5063edf 100644
Binary files a/Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin and 
b/Platform/Socionext/DeveloperBox/fip_all_arm_tf.bin differ
-- 
2.7.4

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


Re: [edk2] [PATCH edk2-platforms v1 05/16] Hisilicon/D06: Add more PCIe port INT-x support

2019-02-12 Thread Ming Huang



On 2/12/2019 1:05 AM, Leif Lindholm wrote:
> On Fri, Feb 01, 2019 at 09:34:25PM +0800, Ming Huang wrote:
>> From: Jason Zhang 
>>
>> Since NVMe riser width is 6*X4, need add the related
>> port's INT-x support to match OS driver.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> ---
>>  Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl | 65 
>> +++-
>>  1 file changed, 50 insertions(+), 15 deletions(-)
>>
>> diff --git a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl 
>> b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
>> index 27fde2e09bfe..4d9d9d95be68 100644
>> --- a/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
>> +++ b/Silicon/Hisilicon/Hi1620/Hi1620AcpiTables/Dsdt/Hi1620Pci.asl
>> @@ -41,11 +41,21 @@ Scope(_SB)
>>// adding RPx INTx configure deponds on hardware board topology,
>>// if UEFI enables RPx, RPy, RPz... related INTx configure
>>// should be added
>> +  Package () {0x2,0,0,640}, // INT_A
>> +  Package () {0x2,1,0,641}, // INT_B
>> +  Package () {0x2,2,0,642}, // INT_C
>> +  Package () {0x2,3,0,643}, // INT_D
>> +
>>Package () {0x4,0,0,640}, // INT_A
>>Package () {0x4,1,0,641}, // INT_B
>>Package () {0x4,2,0,642}, // INT_C
>>Package () {0x4,3,0,643}, // INT_D
>>  
>> +  Package () {0x6,0,0,640}, // INT_A
>> +  Package () {0x6,1,0,641}, // INT_B
>> +  Package () {0x6,2,0,642}, // INT_C
>> +  Package () {0x6,3,0,643}, // INT_D
>> +
>>Package () {0x8,0,0,640}, // INT_A
>>Package () {0x8,1,0,641}, // INT_B
>>Package () {0x8,2,0,642}, // INT_C
>> @@ -56,6 +66,11 @@ Scope(_SB)
>>Package () {0xC,2,0,642}, // INT_C
>>Package () {0xC,3,0,643}, // INT_D
>>  
>> +  Package () {0xE,0,0,640}, // INT_A
>> +  Package () {0xE,1,0,641}, // INT_B
>> +  Package () {0xE,2,0,642}, // INT_C
>> +  Package () {0xE,3,0,643}, // INT_D
>> +
>>Package () {0x10,0,0,640}, // INT_A
>>Package () {0x10,1,0,641}, // INT_B
>>Package () {0x10,2,0,642}, // INT_C
>> @@ -759,26 +774,46 @@ Device (PCI6)
>>  // adding RPx INTx configure deponds on hardware board topology,
>>  // if UEFI enables RPx, RPy, RPz... related INTx configure
>>  // should be added
>> -Package () {0x04,0,0,640}, // INT_A
>> -Package () {0x04,1,0,641}, // INT_B
>> -Package () {0x04,2,0,642}, // INT_C
>> -Package () {0x04,3,0,643}, // INT_D
>> -
>> -Package () {0x08,0,0,640}, // INT_A
>> -Package () {0x08,1,0,641}, // INT_B
>> -Package () {0x08,2,0,642}, // INT_C
>> -Package () {0x08,3,0,643}, // INT_D
>> -
>> -Package () {0x0C,0,0,640}, // INT_A
>> -Package () {0x0C,1,0,641}, // INT_B
>> -Package () {0x0C,2,0,642}, // INT_C
>> -Package () {0x0C,3,0,643}, // INT_D
> 
> Please don't include the non-functional change of dropping the leading
> 0 (0x0 -> 0x) here together with the functional change of adding new
> entries. Please submit as a separate patch.

Ok, do it in v2.

> 
> /
> Leif
> 
>> +Package () {0x2,0,0,640}, // INT_A
>> +Package () {0x2,1,0,641}, // INT_B
>> +Package () {0x2,2,0,642}, // INT_C
>> +Package () {0x2,3,0,643}, // INT_D
>> +
>> +Package () {0x4,0,0,640}, // INT_A
>> +Package () {0x4,1,0,641}, // INT_B
>> +Package () {0x4,2,0,642}, // INT_C
>> +Package () {0x4,3,0,643}, // INT_D
>> +
>> +Package () {0x6,0,0,640}, // INT_A
>> +Package () {0x6,1,0,641}, // INT_B
>> +Package () {0x6,2,0,642}, // INT_C
>> +Package () {0x6,3,0,643}, // INT_D
>> +
>> +Package () {0x8,0,0,640}, // INT_A
>> +Package () {0x8,1,0,641}, // INT_B
>> +Package () {0x8,2,0,642}, // INT_C
>> +Package () {0x8,3,0,643}, // INT_D
>> +
>> +Package () {0xC,0,0,640}, // INT_A
>> +Package () {0xC,1,0,641}, // INT_B
>> +Package () {0xC,2,0,642}, // INT_C
>> +Package () {0xC,3,0,643}, // INT_D
>> +
>> +Package () {0xE,0,0,640}, // INT_A
>> +Package () {0xE,1,0,641}, // INT_B
>> +Package () {0xE,2,0,642}, // INT_C
>> +Package () {0xE,3,0,643}, // INT_D
>>  
>>  Package () {0x10,0,0,640}, // INT_A
>>  Package () 

Re: [edk2] [Patch 0/3] BaseTools: Implement splitquoted function

2019-02-12 Thread Laszlo Ersek
On 02/04/19 20:12, Laszlo Ersek wrote:
> On 02/03/19 06:55, Feng, Bob C wrote:
>> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1509
>> On some Linux environment, there may be no distutils.util
>> library for python3 that will cause build tool crash.
>> This patch implement distutils.util.split_quoted
>> in BaseTools so that the Basetools will be independent with
>> distutils.util library.
>>
>> Feng, Bob C (3):
>>   BaseTools: Implement splitquoted function in Build tool
>>   BaseTools: Implement splitquoted function in UPT
>>   BaseTools: unit test for splitquoted function
>>
>>  BaseTools/Source/Python/AutoGen/UniClassObject.py | 50 
>> ++
>>  BaseTools/Source/Python/UPT/Library/UniClassObject.py | 47 
>> ---
>>  BaseTools/Tests/TestStringSplit.py| 38 
>> ++
>>  3 files changed, 128 insertions(+), 7 deletions(-)
>>  create mode 100644 BaseTools/Tests/TestStringSplit.py
>>
> 
> Is this really necessary? BZ#1509 references Ubuntu18; however it looks
> like the issue can be resolved by a simple package installation on
> Ubuntu 18:
> 
> https://superuser.com/questions/1319047/cant-install-virtual-interpreter-in-pycharm-in-linux
> 
> """
> sudo apt-get install python3-distutils
> """
> 
> I'm not a Ubuntu user myself; so all I can do here (without installing a
> Ubuntu18 VM) is check the Ubuntu package directory:
> 
> https://packages.ubuntu.com/search?keywords=python3-distutils=names=all=all
> 
> python3-distutils appears available for both "bionic (18.04LTS)" and
> "cosmic (18.10)".
> 
> Dandan, if you install python3-distutils, does that solve the issue for you?

I'd still like to get an answer to my question, before the series is pushed.

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


Re: [edk2] [PATCH edk2-non-osi v1 2/7] Hisilicon/D0x: Rename StartupAp() function

2019-02-12 Thread Ming Huang



On 2/12/2019 8:17 PM, Leif Lindholm wrote:
> On Tue, Feb 12, 2019 at 08:07:52PM +0800, Ming Huang wrote:
 For D06 library, we use the same source code to support all Hi1620 
 projects,
 include product projects,so there are some modify for this, like support
 3 sockets, 4 sockets and remove some useless functions.
>>>
>>> So please reword the subject line of this commit to explain it is an
>>> overall update of PlatformSysCtrlLib - including which bits are dropped.
>>>
>>> And I think this makes a good argument for moving the header files for
>>> binary-only libraries from edk2-platforms to edk2-non-osi.
>>> If you do that in a separate patch before this one, you won't need to
>>> include as much detail in the commit message as you will otherwise.
>>
>> Do youe mean move PlatformSysCtrlLib.h, OemAddressMapLib.h and LpcLib.h to 
>> edk2-non-osi?
> 
> Yes.
> 
> Any interfaces exposed _only_ by implementations in edk2-non-osi.
> If there are any interfaces _also_ exposed by implementations in
> edk2-platforms, then I would prefer for them to remain in
> edk2-platforms.
> 
> Ideally, this would also include (the multiple) SerdesLib.h,
> IpmiCmdLib.h, and possibly others.

Ok, I will do that in v2.

Thanks

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


Re: [edk2] [PATCH edk2-non-osi v1 2/7] Hisilicon/D0x: Rename StartupAp() function

2019-02-12 Thread Leif Lindholm
On Tue, Feb 12, 2019 at 08:07:52PM +0800, Ming Huang wrote:
> >> For D06 library, we use the same source code to support all Hi1620 
> >> projects,
> >> include product projects,so there are some modify for this, like support
> >> 3 sockets, 4 sockets and remove some useless functions.
> > 
> > So please reword the subject line of this commit to explain it is an
> > overall update of PlatformSysCtrlLib - including which bits are dropped.
> > 
> > And I think this makes a good argument for moving the header files for
> > binary-only libraries from edk2-platforms to edk2-non-osi.
> > If you do that in a separate patch before this one, you won't need to
> > include as much detail in the commit message as you will otherwise.
> 
> Do youe mean move PlatformSysCtrlLib.h, OemAddressMapLib.h and LpcLib.h to 
> edk2-non-osi?

Yes.

Any interfaces exposed _only_ by implementations in edk2-non-osi.
If there are any interfaces _also_ exposed by implementations in
edk2-platforms, then I would prefer for them to remain in
edk2-platforms.

Ideally, this would also include (the multiple) SerdesLib.h,
IpmiCmdLib.h, and possibly others.

Regards,

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


Re: [edk2] [PATCH edk2-non-osi v1 6/7] Hisilicon/D06: Fix numa node wrong issue

2019-02-12 Thread Ming Huang



On 2/11/2019 10:48 PM, Leif Lindholm wrote:
> *bangs head on desk*
> 
> That question I just asked as a reply to
> ("Silicon/Hisilicon/D06: Set TA as Node 0 for TA boot")
> was meant to be a comment on this patch.
> 
> So - was this change one that was meant to happen together with
> edk2-platforms "Silicon/Hisilicon/D06: Set TA as Node 0 for TA boot"?

Yes, it is better to happen together with that patch.

> 
> What is the user visible behaviour that this change addresses?

Numa info of kernel boot is different:
Use old MemoryInit.efi:
[0.00] ACPI: SRAT: Node 1 PXM 0 [mem 0x208000-0x23]
[0.00] ACPI: SRAT: Node 1 PXM 0 [mem 0x-0x7fff]
[0.00] ACPI: SRAT: Node 3 PXM 2 [mem 0xa20-0xa23]
Use new MemoryInit.efi:
[0.00] ACPI: SRAT: Node 1 PXM 1 [mem 0x208000-0x23]
[0.00] ACPI: SRAT: Node 1 PXM 1 [mem 0x-0x7fff]
[0.00] ACPI: SRAT: Node 3 PXM 3 [mem 0xa20-0xa23]o

Thanks.

> 
> /
> Leif
> 
> On Fri, Feb 01, 2019 at 10:25:06PM +0800, Ming Huang wrote:
>> Numa informations are acquired from HOB that build from memory
>> initialization module. Correct numa informations to match booting
>> from TA(Totem A or super cpu cluster A).
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> ---
>>  Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi | Bin 297696 -> 358656 
>> bytes
>>  1 file changed, 0 insertions(+), 0 deletions(-)
>>
>> diff --git a/Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi 
>> b/Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi
>> index 5fba353..fea1475 100644
>> Binary files a/Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi and 
>> b/Platform/Hisilicon/D06/MemoryInitPei/MemoryInit.efi differ
>> -- 
>> 2.9.5
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-non-osi v1 2/7] Hisilicon/D0x: Rename StartupAp() function

2019-02-12 Thread Ming Huang



On 2/12/2019 6:44 PM, Leif Lindholm wrote:
> On Tue, Feb 12, 2019 at 04:05:50PM +0800, Ming Huang wrote:
>> On 2/12/2019 5:36 AM, Leif Lindholm wrote:
>>> On Fri, Feb 01, 2019 at 10:25:02PM +0800, Ming Huang wrote:
 As suggestion of community, 'AP' is a bit unfortunate to use in EDK2
 context. PI specifies 'BSP' for Boot-strap Processor, as the one
 executing all of the EDK2 code. It then uses 'AP' to refer to
 Additional Processors, which can be assigned tasks using the
 EFI_MP_SERVICES_PROTOCOL. In a TianoCore context, this should be
 'BSP'. So, Rename StartupAp() to StartUpBSP.
>>>
>>> Please add a comment somewhere that this applies to D0x
>>> PlatformSysCtrlLib.
>>
>> ok
>>
 Contributed-under: TianoCore Contribution Agreement 1.1
 Signed-off-by: Ming Huang 
 ---
  
 Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib
  | Bin 297590 -> 229128 bytes
  
 Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib
  | Bin 344310 -> 275312 bytes
  
 Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib
  | Bin 356032 -> 375916 bytes
  3 files changed, 0 insertions(+), 0 deletions(-)
>>>
>>> These are substantial changes in image size from only changing the
>>> name of a function. So I'll have a little look around.
>>>
>>> 1610 version appears to have switched from building with GCC49_RELEASE
>>> to GCC48_RELEASE.
>>> 1616 and 1620 versions seem to have used GCC48_RELEASE all along.
>>>
>>> I definitely see additional renamed functions in these libraries too.
>>>
>>> Please have an inventory and determine what may be affecting image sizes.
>>>
>>> Also, I *beg* you - please upgrade from "GNU C 4.8.3 20131202 (prerelease)".
>>
>> We have plan to upgrage gcc to 7.3, but our build server is share for all ARM
>> project, so need discuss with other project groups, it may be not enough time
>> for 19.02.
> 
> Oh, we're too late in the game to change for this release.
> But you are using ancient toolchains with poor code generation and
> quite likely known bugs.
> And this has been the state for quite some time.
> If that can change for 19.06, that's good enough.

Ok, I will upgrade gcc from 4.8 for 19.06.

> 
>> For D05/D03 libraries, just remove 2 functions from OemMiscLib which used
>> by PlatformSysCtrlLib. Does edk2 version effect the libraries size?
>> old edk2 base on: 2017-0904
>> now edk2 base on: 2018-0801
> 
> Well, changing edk2 version will mean that command line options to
> compiler and linker may change. So certainly some change can be seen.
> But when the changes are this big, I suspect something else has been
> going on.

I also think it is strange for big size change.

> 
>> For D06 library, we use the same source code to support all Hi1620 projects,
>> include product projects,so there are some modify for this, like support
>> 3 sockets, 4 sockets and remove some useless functions.
> 
> So please reword the subject line of this commit to explain it is an
> overall update of PlatformSysCtrlLib - including which bits are dropped.
> 
> And I think this makes a good argument for moving the header files for
> binary-only libraries from edk2-platforms to edk2-non-osi.
> If you do that in a separate patch before this one, you won't need to
> include as much detail in the commit message as you will otherwise.

Do youe mean move PlatformSysCtrlLib.h, OemAddressMapLib.h and LpcLib.h to 
edk2-non-osi?

> 
> Regards,
> 
> Leif
> 
>> Thanks.
>>
>>>
>>> /
>>> Leif
>>>

 diff --git 
 a/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib
  
 b/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib
 index 68be770..4c63a26 100644
 Binary files 
 a/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib
  and 
 b/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib
  differ
 diff --git 
 a/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib
  
 b/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib
 index b3cc88e..cb2c652 100644
 Binary files 
 a/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib
  and 
 b/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib
  differ
 diff --git 
 a/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib
  
 b/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib
 index 50d453a..d643f7b 100644
 Binary files 
 a/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib
  and 
 

Re: [edk2] [PATCH edk2-non-osi v1 3/7] Hisilicon/D06: Update Mbigen and gic RAS register

2019-02-12 Thread Leif Lindholm
On Tue, Feb 12, 2019 at 07:42:55PM +0800, Ming Huang wrote:
> 
> 
> On 2/12/2019 5:38 AM, Leif Lindholm wrote:
> > On Fri, Feb 01, 2019 at 10:25:03PM +0800, Ming Huang wrote:
> >> As chip group suggestions, update Mbigen and gic RAS configuration
> >> flow.
> > 
> > Update how?
> 
> Add below flow:
> 1 Reset Mbigen;
> 2 Disable Mbigen clock;
> 3 Deassert reset Mbigen;
> 4 Enable Mbigen clock;

If you add that to commit message, that's good enough for me.

Regards,

Leif

> Thanks.
> 
> > 
> > /
> > Leif
> > 
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Ming Huang 
> >> ---
> >>  Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi | Bin 17984 -> 
> >> 18720 bytes
> >>  1 file changed, 0 insertions(+), 0 deletions(-)
> >>
> >> diff --git a/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi 
> >> b/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi
> >> index 19adbc9..9ea21e9 100644
> >> Binary files a/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi 
> >> and b/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi differ
> >> -- 
> >> 2.9.5
> >>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH edk2-non-osi v1 3/7] Hisilicon/D06: Update Mbigen and gic RAS register

2019-02-12 Thread Ming Huang



On 2/12/2019 5:38 AM, Leif Lindholm wrote:
> On Fri, Feb 01, 2019 at 10:25:03PM +0800, Ming Huang wrote:
>> As chip group suggestions, update Mbigen and gic RAS configuration
>> flow.
> 
> Update how?

Add below flow:
1 Reset Mbigen;
2 Disable Mbigen clock;
3 Deassert reset Mbigen;
4 Enable Mbigen clock;

Thanks.

> 
> /
> Leif
> 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> ---
>>  Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi | Bin 17984 -> 
>> 18720 bytes
>>  1 file changed, 0 insertions(+), 0 deletions(-)
>>
>> diff --git a/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi 
>> b/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi
>> index 19adbc9..9ea21e9 100644
>> Binary files a/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi and 
>> b/Platform/Hisilicon/D06/Drivers/RasInitDxe/RasInitDxe.efi differ
>> -- 
>> 2.9.5
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v2] MdeModulePkg/CapsuleApp: Fix memory leak issue.

2019-02-12 Thread Wu, Hao A
> -Original Message-
> From: Chen, Chen A
> Sent: Tuesday, February 12, 2019 3:56 PM
> To: edk2-devel@lists.01.org
> Cc: Chen, Chen A; Wang, Jian J; Wu, Hao A; Zhang, Chao B; Gao, Liming
> Subject: [PATCH v2] MdeModulePkg/CapsuleApp: Fix memory leak issue.
> 
> This issue is caused by FileInfoBuffer variable. This is a pointer array
> and each elements also pointer to a memory buffer that is allocated and
> returned by AllocateCopyPool function.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Zhang Chao B 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Chen A Chen 
> ---
>  MdeModulePkg/Application/CapsuleApp/CapsuleDump.c | 83
> ---
>  1 file changed, 58 insertions(+), 25 deletions(-)
> 
> diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> index ba2583accb..732472bb9c 100644
> --- a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> +++ b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
> @@ -806,48 +806,69 @@ DumpCapsuleFromDisk (
>Status = Fs->OpenVolume (Fs, );
>if (EFI_ERROR (Status)) {
>  Print (L"Cannot open volume. Status = %r\n", Status);
> -return EFI_NOT_FOUND;
> +goto Done;
>}
> 
>Status = Root->Open (Root, , EFI_CAPSULE_FILE_DIRECTORY,
> EFI_FILE_MODE_READ | EFI_FILE_MODE_WRITE , 0);
>if (EFI_ERROR (Status)) {
>  Print (L"Cannot open %s. Status = %r\n", EFI_CAPSULE_FILE_DIRECTORY,
> Status);
> -return EFI_NOT_FOUND;
> +goto Done;
>}
> 
>//
>// Get file count first
>//
> -  for ( Status = FileHandleFindFirstFile (DirHandle, )
> -  ; !EFI_ERROR(Status) && !NoFile
> -  ; Status = FileHandleFindNextFile (DirHandle, FileInfo, )
> - ){
> -if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
> -  continue;
> +  do {
> +Status = FileHandleFindFirstFile (DirHandle, );
> +if (EFI_ERROR (Status) || FileInfo == NULL) {
> +  Print (L"Get File Info Fail. Status = %r\n", Status);
> +  goto Done;
>  }
> -FileCount++;
> -  }
> +
> +if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
> +  FileCount++;
> +}
> +
> +Status = FileHandleFindNextFile (DirHandle, FileInfo, );
> +if (EFI_ERROR (Status)) {
> +  Print (L"Get Next File Fail. Status = %r\n", Status);
> +  goto Done;
> +}
> +  } while (!NoFile);
> 
>if (FileCount == 0) {
>  Print (L"Error: No capsule file found!\n");
> -return EFI_NOT_FOUND;
> +Status = EFI_NOT_FOUND;
> +goto Done;
>}
> 
>FileInfoBuffer = AllocatePool (sizeof(FileInfo) * FileCount);

For me, AllocateZeroPool() should be used here.

Please refer to the reason below.

> +  if (FileInfoBuffer == NULL) {
> +Status = EFI_OUT_OF_RESOURCES;
> +goto Done;
> +  }
>NoFile = FALSE;
> 
>//
>// Get all file info
>//
> -  for ( Status = FileHandleFindFirstFile (DirHandle, )
> -  ; !EFI_ERROR (Status) && !NoFile
> -  ; Status = FileHandleFindNextFile (DirHandle, FileInfo, )
> - ){
> -if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) == 0) {
> -  continue;
> +  do {
> +Status = FileHandleFindFirstFile (DirHandle, );
> +if (EFI_ERROR (Status) || FileInfo == NULL) {
> +  Print (L"Get File Info Fail. Status = %r\n", Status);
> +  goto Done;
> +}
> +
> +if ((FileInfo->Attribute & (EFI_FILE_SYSTEM | EFI_FILE_ARCHIVE)) != 0) {
> +  FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
> FileInfo);

If the memory allocation somehow fails during the 'do-while' loop, the
elements within array 'FileInfoBuffer' will not all have valid pointer
values.

So I believe, an 'AllocateZeroPool' should be used above.

With this addressed,
Reviewed-by: Hao Wu 

Best Regards,
Hao Wu

>  }
> -FileInfoBuffer[Index++] = AllocateCopyPool ((UINTN)FileInfo->Size,
> FileInfo);
> -  }
> +
> +Status = FileHandleFindNextFile (DirHandle, FileInfo, );
> +if (EFI_ERROR (Status)) {
> +  Print (L"Get Next File Fail. Status = %r\n", Status);
> +  goto Done;
> +}
> +  } while (!NoFile);
> 
>//
>// Sort FileInfoBuffer by alphabet order
> @@ -866,7 +887,8 @@ DumpCapsuleFromDisk (
>}
> 
>if (!DumpCapsuleInfo) {
> -return EFI_SUCCESS;
> +Status = EFI_SUCCESS;
> +goto Done;
>}
> 
>Print(L"The infomation of the capsules:\n");
> @@ -875,19 +897,20 @@ DumpCapsuleFromDisk (
>  FileHandle = NULL;
>  Status = DirHandle->Open (DirHandle, ,
> FileInfoBuffer[Index]->FileName, EFI_FILE_MODE_READ, 0);
>  if (EFI_ERROR (Status)) {
> -  break;
> +  goto Done;
>  }
> 
>  Status = FileHandleGetSize (FileHandle, (UINT64 *) );
>  if (EFI_ERROR (Status)) {
>Print (L"Cannot read file %s. Status = %r\n", FileInfoBuffer[Index]-
> >FileName, Status);
>FileHandleClose (FileHandle);
> -  return Status;
> +  goto Done;
> 

Re: [edk2] [patch] MdeModulePkg/ReportStatusCodeLib: Avoid using AllocatePool if possible

2019-02-12 Thread Gao, Liming
Dandan:
 The last change in RuntimeDxeReportStatusCodeLib can be simplified. Other 
change is good. 

  if (!mHaveExitedBootServices && (StatusCodeData != (EFI_STATUS_CODE_DATA *) 
StatusCodeBuffer)) {
gBS->FreePool (StatusCodeData);
  }
==>
  if (StatusCodeData != (EFI_STATUS_CODE_DATA *) StatusCodeBuffer) {
gBS->FreePool (StatusCodeData);
  }

Thanks
Liming
> -Original Message-
> From: Bi, Dandan
> Sent: Saturday, February 2, 2019 4:47 PM
> To: edk2-devel@lists.01.org
> Cc: Max Knutsen ; Wang, Jian J 
> ; Wu, Hao A ; Michael Turner
> ; Gao, Liming 
> Subject: [patch] MdeModulePkg/ReportStatusCodeLib: Avoid using AllocatePool 
> if possible
> 
> From: Max Knutsen 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1114
> 
> When report status code with ExtendedData data,
> and the extended data can fit in the local static buffer,
> there is no need to use AllocatePool to hold the ExtendedData data.
> 
> This patch is just to do the enhancement to avoid using AllocatePool.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Michael Turner 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi 
> ---
>  .../Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c | 9 +++--
>  .../RuntimeDxeReportStatusCodeLib/ReportStatusCodeLib.c  | 9 +++--
>  2 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git a/MdeModulePkg/Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c
> b/MdeModulePkg/Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c
> index b28dc5c3bb..c88be5a1a3 100644
> --- a/MdeModulePkg/Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c
> +++ b/MdeModulePkg/Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c
> @@ -505,13 +505,18 @@ ReportStatusCodeEx (
>//
>Tpl = gBS->RaiseTPL (TPL_HIGH_LEVEL);
>gBS->RestoreTPL (Tpl);
> 
>StatusCodeData = NULL;
> -  if (Tpl <= TPL_NOTIFY) {
> +  if (ExtendedDataSize <= (MAX_EXTENDED_DATA_SIZE - sizeof 
> (EFI_STATUS_CODE_DATA))) {
>  //
> -// Allocate space for the Status Code Header and its buffer
> +// Use Buffer instead of allocating if possible.
> +//
> +StatusCodeData = (EFI_STATUS_CODE_DATA *)Buffer;
> +  } else if (Tpl <= TPL_NOTIFY){
> +//
> +// If Buffer is not big enough, allocate space for the Status Code 
> Header and its buffer
>  //
>  gBS->AllocatePool (EfiBootServicesData, sizeof (EFI_STATUS_CODE_DATA) + 
> ExtendedDataSize, (VOID **));
>}
> 
>if (StatusCodeData == NULL) {
> diff --git 
> a/MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/ReportStatusCodeLib.c
> b/MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/ReportStatusCodeLib.c
> index b73103517a..3380469759 100644
> --- a/MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/ReportStatusCodeLib.c
> +++ b/MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/ReportStatusCodeLib.c
> @@ -635,11 +635,14 @@ ReportStatusCodeEx (
>if (mHaveExitedBootServices) {
>  if (sizeof (EFI_STATUS_CODE_DATA) + ExtendedDataSize > 
> MAX_EXTENDED_DATA_SIZE) {
>return EFI_OUT_OF_RESOURCES;
>  }
>  StatusCodeData = (EFI_STATUS_CODE_DATA *) StatusCodeBuffer;
> -  } else  {
> +  } else if (sizeof (EFI_STATUS_CODE_DATA) + ExtendedDataSize > 
> MAX_EXTENDED_DATA_SIZE) {
> +//
> +// Only use AllocatePool for larger ExtendedData.
> +//
>  if (gBS == NULL || gBS->AllocatePool == NULL || gBS->FreePool == NULL) {
>return EFI_UNSUPPORTED;
>  }
> 
>  //
> @@ -648,10 +651,12 @@ ReportStatusCodeEx (
>  StatusCodeData = NULL;
>  gBS->AllocatePool (EfiBootServicesData, sizeof (EFI_STATUS_CODE_DATA) + 
> ExtendedDataSize, (VOID **));
>  if (StatusCodeData == NULL) {
>return EFI_OUT_OF_RESOURCES;
>  }
> +  } else {
> +StatusCodeData = (EFI_STATUS_CODE_DATA *) StatusCodeBuffer;
>}
> 
>//
>// Fill in the extended data header
>//
> @@ -678,11 +683,11 @@ ReportStatusCodeEx (
>Status = InternalReportStatusCode (Type, Value, Instance, CallerId, 
> StatusCodeData);
> 
>//
>// Free the allocated buffer
>//
> -  if (!mHaveExitedBootServices) {
> +  if (!mHaveExitedBootServices && (StatusCodeData != (EFI_STATUS_CODE_DATA 
> *) StatusCodeBuffer)) {
>  gBS->FreePool (StatusCodeData);
>}
> 
>return Status;
>  }
> --
> 2.18.0.windows.1

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


Re: [edk2] [PATCH edk2-non-osi v1 2/7] Hisilicon/D0x: Rename StartupAp() function

2019-02-12 Thread Leif Lindholm
On Tue, Feb 12, 2019 at 04:05:50PM +0800, Ming Huang wrote:
> On 2/12/2019 5:36 AM, Leif Lindholm wrote:
> > On Fri, Feb 01, 2019 at 10:25:02PM +0800, Ming Huang wrote:
> >> As suggestion of community, 'AP' is a bit unfortunate to use in EDK2
> >> context. PI specifies 'BSP' for Boot-strap Processor, as the one
> >> executing all of the EDK2 code. It then uses 'AP' to refer to
> >> Additional Processors, which can be assigned tasks using the
> >> EFI_MP_SERVICES_PROTOCOL. In a TianoCore context, this should be
> >> 'BSP'. So, Rename StartupAp() to StartUpBSP.
> > 
> > Please add a comment somewhere that this applies to D0x
> > PlatformSysCtrlLib.
> 
> ok
> 
> >> Contributed-under: TianoCore Contribution Agreement 1.1
> >> Signed-off-by: Ming Huang 
> >> ---
> >>  
> >> Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib
> >>  | Bin 297590 -> 229128 bytes
> >>  
> >> Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib
> >>  | Bin 344310 -> 275312 bytes
> >>  
> >> Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib
> >>  | Bin 356032 -> 375916 bytes
> >>  3 files changed, 0 insertions(+), 0 deletions(-)
> > 
> > These are substantial changes in image size from only changing the
> > name of a function. So I'll have a little look around.
> > 
> > 1610 version appears to have switched from building with GCC49_RELEASE
> > to GCC48_RELEASE.
> > 1616 and 1620 versions seem to have used GCC48_RELEASE all along.
> > 
> > I definitely see additional renamed functions in these libraries too.
> > 
> > Please have an inventory and determine what may be affecting image sizes.
> > 
> > Also, I *beg* you - please upgrade from "GNU C 4.8.3 20131202 (prerelease)".
> 
> We have plan to upgrage gcc to 7.3, but our build server is share for all ARM
> project, so need discuss with other project groups, it may be not enough time
> for 19.02.

Oh, we're too late in the game to change for this release.
But you are using ancient toolchains with poor code generation and
quite likely known bugs.
And this has been the state for quite some time.
If that can change for 19.06, that's good enough.

> For D05/D03 libraries, just remove 2 functions from OemMiscLib which used
> by PlatformSysCtrlLib. Does edk2 version effect the libraries size?
> old edk2 base on: 2017-0904
> now edk2 base on: 2018-0801

Well, changing edk2 version will mean that command line options to
compiler and linker may change. So certainly some change can be seen.
But when the changes are this big, I suspect something else has been
going on.

> For D06 library, we use the same source code to support all Hi1620 projects,
> include product projects,so there are some modify for this, like support
> 3 sockets, 4 sockets and remove some useless functions.

So please reword the subject line of this commit to explain it is an
overall update of PlatformSysCtrlLib - including which bits are dropped.

And I think this makes a good argument for moving the header files for
binary-only libraries from edk2-platforms to edk2-non-osi.
If you do that in a separate patch before this one, you won't need to
include as much detail in the commit message as you will otherwise.

Regards,

Leif

> Thanks.
> 
> > 
> > /
> > Leif
> > 
> >>
> >> diff --git 
> >> a/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib
> >>  
> >> b/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib
> >> index 68be770..4c63a26 100644
> >> Binary files 
> >> a/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib
> >>  and 
> >> b/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib
> >>  differ
> >> diff --git 
> >> a/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib
> >>  
> >> b/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib
> >> index b3cc88e..cb2c652 100644
> >> Binary files 
> >> a/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib
> >>  and 
> >> b/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib
> >>  differ
> >> diff --git 
> >> a/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib
> >>  
> >> b/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib
> >> index 50d453a..d643f7b 100644
> >> Binary files 
> >> a/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib
> >>  and 
> >> b/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib
> >>  differ
> >> -- 
> >> 2.9.5
> >>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [Patch 0/3] BaseTools: Implement splitquoted function

2019-02-12 Thread Gao, Liming
Reviewed-by: Liming Gao 

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Feng, 
> Bob C
> Sent: Sunday, February 3, 2019 1:55 PM
> To: edk2-devel@lists.01.org
> Subject: [edk2] [Patch 0/3] BaseTools: Implement splitquoted function
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1509
> On some Linux environment, there may be no distutils.util
> library for python3 that will cause build tool crash.
> This patch implement distutils.util.split_quoted
> in BaseTools so that the Basetools will be independent with
> distutils.util library.
> 
> Feng, Bob C (3):
>   BaseTools: Implement splitquoted function in Build tool
>   BaseTools: Implement splitquoted function in UPT
>   BaseTools: unit test for splitquoted function
> 
>  BaseTools/Source/Python/AutoGen/UniClassObject.py | 50 
> ++
>  BaseTools/Source/Python/UPT/Library/UniClassObject.py | 47 
> ---
>  BaseTools/Tests/TestStringSplit.py| 38 
> ++
>  3 files changed, 128 insertions(+), 7 deletions(-)
>  create mode 100644 BaseTools/Tests/TestStringSplit.py
> 
> --
> 2.20.1.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH v2 1/3] MdeModulePkg/PciBus: Change PCI_IO_DEVICE.RomSize to UINT32 type

2019-02-12 Thread Ray Ni
Per PCI Spec, the option ROM BAR is 32bit so the maximum option ROM
size can be hold by UINT32 type.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ray Ni 
Cc: Hao Wu 
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h   | 4 ++--
 MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c | 6 +++---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c| 8 
 MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.h| 4 ++--
 MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c   | 4 ++--
 5 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
index 6938802857..18d76ea965 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h
@@ -1,7 +1,7 @@
 /** @file
   Header files and data structures needed by PCI Bus module.
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, 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
@@ -237,7 +237,7 @@ struct _PCI_IO_DEVICE {
   //
   // The OptionRom Size
   //
-  UINT64RomSize;
+  UINT32RomSize;
 
   //
   // TRUE if all OpROM (in device or in platform specific position) have been 
processed
diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
index ab791541c3..7fb8e596f5 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciDeviceSupport.c
@@ -1,7 +1,7 @@
 /** @file
   Supporting functions implementaion for PCI devices management.
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 (C) Copyright 2018 Hewlett Packard Enterprise Development LP
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
@@ -259,7 +259,7 @@ RegisterPciDevice (
);
   if (!EFI_ERROR (Status)) {
 PciIoDevice->EmbeddedRom= FALSE;
-PciIoDevice->RomSize= PlatformOpRomSize;
+PciIoDevice->RomSize= (UINT32) PlatformOpRomSize;
 PciIoDevice->PciIo.RomSize  = PlatformOpRomSize;
 PciIoDevice->PciIo.RomImage = PlatformOpRomBuffer;
 //
@@ -285,7 +285,7 @@ RegisterPciDevice (
);
   if (!EFI_ERROR (Status)) {
 PciIoDevice->EmbeddedRom= FALSE;
-PciIoDevice->RomSize= PlatformOpRomSize;
+PciIoDevice->RomSize= (UINT32) PlatformOpRomSize;
 PciIoDevice->PciIo.RomSize  = PlatformOpRomSize;
 PciIoDevice->PciIo.RomImage = PlatformOpRomBuffer;
 //
diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c
index f44db01a9d..f8ba342681 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c
@@ -1,7 +1,7 @@
 /** @file
   PCI eunmeration implementation on entire PCI bus system for PCI Bus module.
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 (C) Copyright 2015 Hewlett Packard Enterprise Development LP
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
@@ -528,15 +528,15 @@ DetermineRootBridgeAttributes (
   @return Max size of option rom needed.
 
 **/
-UINT64
+UINT32
 GetMaxOptionRomSize (
   IN PCI_IO_DEVICE   *Bridge
   )
 {
   LIST_ENTRY  *CurrentLink;
   PCI_IO_DEVICE   *Temp;
-  UINT64  MaxOptionRomSize;
-  UINT64  TempOptionRomSize;
+  UINT32  MaxOptionRomSize;
+  UINT32  TempOptionRomSize;
 
   MaxOptionRomSize = 0;
 
diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.h 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.h
index 2df1fb0b94..ed4c875d36 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.h
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.h
@@ -1,7 +1,7 @@
 /** @file
   PCI bus enumeration logic function declaration for PCI bus module.
 
-Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, 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
@@ -109,7 +109,7 @@ DetermineRootBridgeAttributes (
   @return Max size of option rom needed.
 
 **/
-UINT64
+UINT32
 GetMaxOptionRomSize (
   IN PCI_IO_DEVICE   

[edk2] [PATCH v2 0/3] MdeModulePkg/PciBus: Fix a bug PPB MEM32 BAR isn't restored sometimes

2019-02-12 Thread Ray Ni
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1505

v2: fixed all typos in PciBus driver.
changed RomSize to UINT32 and added type cast to PPB MEM32 BAR
Base/Length to avoid using RShiftU64().


Ray Ni (3):
  MdeModulePkg/PciBus: Change PCI_IO_DEVICE.RomSize to UINT32 type
  MdeModulePkg/PciBus: Correct typos
  MdeModulePkg/PciBus: Fix a bug PPB MEM32 BAR isn't restored sometimes

 MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.h   |   4 +-
 MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c   |  14 +--
 MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.h   |  16 +--
 .../Bus/Pci/PciBusDxe/PciDeviceSupport.c  |  20 ++--
 .../Bus/Pci/PciBusDxe/PciDeviceSupport.h  |  14 +--
 .../Bus/Pci/PciBusDxe/PciDriverOverride.c |   4 +-
 .../Bus/Pci/PciBusDxe/PciDriverOverride.h |   4 +-
 .../Bus/Pci/PciBusDxe/PciEnumerator.c |   8 +-
 .../Bus/Pci/PciBusDxe/PciEnumerator.h |   8 +-
 .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.c  |  42 +++
 .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.h  |  16 +--
 .../Bus/Pci/PciBusDxe/PciHotPlugSupport.c |  16 +--
 .../Bus/Pci/PciBusDxe/PciHotPlugSupport.h |  18 +--
 MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c|  16 +--
 MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.h|   4 +-
 MdeModulePkg/Bus/Pci/PciBusDxe/PciLib.c   |   4 +-
 .../Bus/Pci/PciBusDxe/PciOptionRomSupport.c   |   6 +-
 .../Bus/Pci/PciBusDxe/PciOptionRomSupport.h   |   4 +-
 .../Bus/Pci/PciBusDxe/PciPowerManagement.c|   4 +-
 .../Bus/Pci/PciBusDxe/PciPowerManagement.h|   4 +-
 .../Bus/Pci/PciBusDxe/PciResourceSupport.c| 113 +-
 .../Bus/Pci/PciBusDxe/PciResourceSupport.h|  41 ---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciRomTable.h  |   7 +-
 23 files changed, 190 insertions(+), 197 deletions(-)

-- 
2.20.1.windows.1

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


[edk2] [PATCH v2 2/3] MdeModulePkg/PciBus: Correct typos

2019-02-12 Thread Ray Ni
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ray Ni 
Cc: Hao Wu 
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c   | 14 ++---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.h   | 16 ++---
 .../Bus/Pci/PciBusDxe/PciDeviceSupport.c  | 14 ++---
 .../Bus/Pci/PciBusDxe/PciDeviceSupport.h  | 14 ++---
 .../Bus/Pci/PciBusDxe/PciDriverOverride.c |  4 +-
 .../Bus/Pci/PciBusDxe/PciDriverOverride.h |  4 +-
 .../Bus/Pci/PciBusDxe/PciEnumerator.h |  4 +-
 .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.c  | 42 ++---
 .../Bus/Pci/PciBusDxe/PciEnumeratorSupport.h  | 16 ++---
 .../Bus/Pci/PciBusDxe/PciHotPlugSupport.c | 16 ++---
 .../Bus/Pci/PciBusDxe/PciHotPlugSupport.h | 18 +++---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.c| 16 ++---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciIo.h|  4 +-
 .../Bus/Pci/PciBusDxe/PciOptionRomSupport.c   |  6 +-
 .../Bus/Pci/PciBusDxe/PciOptionRomSupport.h   |  4 +-
 .../Bus/Pci/PciBusDxe/PciPowerManagement.c|  4 +-
 .../Bus/Pci/PciBusDxe/PciPowerManagement.h|  4 +-
 .../Bus/Pci/PciBusDxe/PciResourceSupport.c| 62 +--
 .../Bus/Pci/PciBusDxe/PciResourceSupport.h| 41 ++--
 MdeModulePkg/Bus/Pci/PciBusDxe/PciRomTable.h  |  7 +--
 20 files changed, 154 insertions(+), 156 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
index 0bc1fbfeff..a71868cbf8 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.c
@@ -1,7 +1,7 @@
 /** @file
   PCI command register operations supporting functions implementation for PCI 
Bus module.
 
-Copyright (c) 2006 - 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, 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
@@ -75,12 +75,12 @@ PciOperateRegister (
 }
 
 /**
-  Check the cpability supporting by given device.
+  Check the capability supporting by given device.
 
   @param PciIoDevice   Pointer to instance of PCI_IO_DEVICE.
 
-  @retval TRUE Cpability supportted.
-  @retval FALSECpability not supportted.
+  @retval TRUE Capability supported.
+  @retval FALSECapability not supported.
 
 **/
 BOOLEAN
@@ -103,7 +103,7 @@ PciCapabilitySupport (
   @param OffsetA pointer to the offset returned.
   @param NextRegBlock  A pointer to the next block returned.
 
-  @retval EFI_SUCCESS  Successfuly located capability register block.
+  @retval EFI_SUCCESS  Successfully located capability register block.
   @retval EFI_UNSUPPORTED  Pci device does not support capability.
   @retval EFI_NOT_FOUNDPci device support but can not find register block.
 
@@ -121,7 +121,7 @@ LocateCapabilityRegBlock (
   UINT8   CapabilityID;
 
   //
-  // To check the cpability of this device supports
+  // To check the capability of this device supports
   //
   if (!PciCapabilitySupport (PciIoDevice)) {
 return EFI_UNSUPPORTED;
@@ -195,7 +195,7 @@ LocateCapabilityRegBlock (
   @param OffsetA pointer to the offset returned.
   @param NextRegBlock  A pointer to the next block returned.
 
-  @retval EFI_SUCCESS  Successfuly located capability register block.
+  @retval EFI_SUCCESS  Successfully located capability register block.
   @retval EFI_UNSUPPORTED  Pci device does not support capability.
   @retval EFI_NOT_FOUNDPci device support but can not find register block.
 
diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.h 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.h
index cc942d0d42..3e1746b969 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.h
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciCommand.h
@@ -1,7 +1,7 @@
 /** @file
   PCI command register operations supporting functions declaration for PCI Bus 
module.
 
-Copyright (c) 2006 - 2009, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2019, 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
@@ -84,12 +84,12 @@ PciOperateRegister (
   );
 
 /**
-  Check the cpability supporting by given device.
+  Check the capability supporting by given device.
 
   @param PciIoDevice   Pointer to instance of PCI_IO_DEVICE.
 
-  @retval TRUE Cpability supportted.
-  @retval FALSECpability not supportted.
+  @retval TRUE Capability supported.
+  @retval FALSECapability not supported.
 
 **/
 BOOLEAN
@@ -105,7 +105,7 @@ PciCapabilitySupport (
   @param OffsetA pointer to the offset returned.
   @param NextRegBlock  A pointer to the next block returned.
 
-  @retval 

[edk2] [PATCH v2 3/3] MdeModulePkg/PciBus: Fix a bug PPB MEM32 BAR isn't restored sometimes

2019-02-12 Thread Ray Ni
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1505

When a device under PPB contains option ROM but doesn't require 32bit
MMIO, ProgrameUpstreamBridgeForRom() cannot correctly restore the
PPB MEM32 RANGE BAR. It causes the 32bit MMIO conflict which may
cause system hangs in boot.

The root cause is when ProgrameUpstreamBridgeForRom() calls
ProgramPpbApperture() to restore the PPB MEM32 RANGE BAR, the
ProgramPpbApperture() skips to program the BAR when the resource
length is 0.

This patch fixes this issue by not calling ProgramPpbApperture().
Instead, it directly programs the PPB MEM32 RANGE BAR.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ray Ni 
Cc: Hao Wu 
Cc: Dandan Bi 
---
 .../Bus/Pci/PciBusDxe/PciResourceSupport.c| 51 +--
 1 file changed, 23 insertions(+), 28 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
index f5ae3d857b..70e45040e2 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciResourceSupport.c
@@ -1661,57 +1661,52 @@ ProgramUpstreamBridgeForRom (
   IN BOOLEAN Enable
   )
 {
-  PCI_IO_DEVICE *Parent;
-  PCI_RESOURCE_NODE Node;
-  UINT64Base;
-  UINT64Length;
+  PCI_IO_DEVICE   *Parent;
+  EFI_PCI_IO_PROTOCOL *PciIo;
+  UINT16  Base;
+  UINT16  Limit;
   //
   // For root bridge, just return.
   //
   Parent = PciDevice->Parent;
-  ZeroMem (, sizeof (Node));
   while (Parent != NULL) {
 if (!IS_PCI_BRIDGE (>Pci)) {
   break;
 }
 
-Node.PciDev = Parent;
-Node.Alignment  = 0;
-Node.Bar= PPB_MEM32_RANGE;
-Node.ResType= PciBarTypeMem32;
-Node.Offset = 0;
+PciIo = >PciIo;
 
 //
 // Program PPB to only open a single <= 16MB aperture
 //
 if (Enable) {
-  //
-  // Save the original PPB_MEM32_RANGE BAR.
-  // The values will be changed by ProgramPpbApperture().
-  //
-  Base   = Parent->PciBar[Node.Bar].BaseAddress;
-  Length = Parent->PciBar[Node.Bar].Length;
-
   //
   // Only cover MMIO for Option ROM.
   //
-  Node.Length = PciDevice->RomSize;
-  ProgramPpbApperture (OptionRomBase, );
-
-  //
-  // Restore the original PPB_MEM32_RANGE BAR.
-  // So the MEM32 RANGE BAR register can be restored when disable the 
decoding.
-  //
-  Parent->PciBar[Node.Bar].BaseAddress = Base;
-  Parent->PciBar[Node.Bar].Length  = Length;
+  Base  = (UINT16) (OptionRomBase >> 16);
+  Limit = (UINT16) ((OptionRomBase + PciDevice->RomSize - 1) >> 16);
+  PciIo->Pci.Write (PciIo, EfiPciIoWidthUint16, OFFSET_OF (PCI_TYPE01, 
Bridge.MemoryBase),  1, );
+  PciIo->Pci.Write (PciIo, EfiPciIoWidthUint16, OFFSET_OF (PCI_TYPE01, 
Bridge.MemoryLimit), 1, );
 
   PCI_ENABLE_COMMAND_REGISTER (Parent, EFI_PCI_COMMAND_MEMORY_SPACE);
 } else {
   //
   // Cover 32bit MMIO for devices below the bridge.
   //
-  Node.Length = Parent->PciBar[Node.Bar].Length;
-  ProgramPpbApperture (Parent->PciBar[Node.Bar].BaseAddress, );
+  if (Parent->PciBar[PPB_MEM32_RANGE].Length == 0) {
+//
+// When devices under the bridge contains Option ROM and doesn't 
require 32bit MMIO.
+//
+Base  = (UINT16) gAllOne;
+Limit = (UINT16) gAllZero;
+  } else {
+Base  = (UINT16) ((UINT32) Parent->PciBar[PPB_MEM32_RANGE].BaseAddress 
>> 16);
+Limit = (UINT16) ((UINT32) (Parent->PciBar[PPB_MEM32_RANGE].BaseAddress
++ Parent->PciBar[PPB_MEM32_RANGE].Length - 
1) >> 16);
+  }
+  PciIo->Pci.Write (PciIo, EfiPciIoWidthUint16, OFFSET_OF (PCI_TYPE01, 
Bridge.MemoryBase),  1, );
+  PciIo->Pci.Write (PciIo, EfiPciIoWidthUint16, OFFSET_OF (PCI_TYPE01, 
Bridge.MemoryLimit), 1, );
+
   PCI_DISABLE_COMMAND_REGISTER (Parent, EFI_PCI_COMMAND_MEMORY_SPACE);
 }
 
-- 
2.20.1.windows.1

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


Re: [edk2] [PATCH edk2-non-osi v1 2/7] Hisilicon/D0x: Rename StartupAp() function

2019-02-12 Thread Ming Huang



On 2/12/2019 5:36 AM, Leif Lindholm wrote:
> On Fri, Feb 01, 2019 at 10:25:02PM +0800, Ming Huang wrote:
>> As suggestion of community, 'AP' is a bit unfortunate to use in EDK2
>> context. PI specifies 'BSP' for Boot-strap Processor, as the one
>> executing all of the EDK2 code. It then uses 'AP' to refer to
>> Additional Processors, which can be assigned tasks using the
>> EFI_MP_SERVICES_PROTOCOL. In a TianoCore context, this should be
>> 'BSP'. So, Rename StartupAp() to StartUpBSP.
> 
> Please add a comment somewhere that this applies to D0x
> PlatformSysCtrlLib.

ok

> 
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> ---
>>  
>> Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib
>>  | Bin 297590 -> 229128 bytes
>>  
>> Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib
>>  | Bin 344310 -> 275312 bytes
>>  
>> Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib
>>  | Bin 356032 -> 375916 bytes
>>  3 files changed, 0 insertions(+), 0 deletions(-)
> 
> These are substantial changes in image size from only changing the
> name of a function. So I'll have a little look around.
> 
> 1610 version appears to have switched from building with GCC49_RELEASE
> to GCC48_RELEASE.
> 1616 and 1620 versions seem to have used GCC48_RELEASE all along.
> 
> I definitely see additional renamed functions in these libraries too.
> 
> Please have an inventory and determine what may be affecting image sizes.
> 
> Also, I *beg* you - please upgrade from "GNU C 4.8.3 20131202 (prerelease)".

We have plan to upgrage gcc to 7.3, but our build server is share for all ARM
project, so need discuss with other project groups, it may be not enough time
for 19.02.

For D05/D03 libraries, just remove 2 functions from OemMiscLib which used
by PlatformSysCtrlLib. Does edk2 version effect the libraries size?
old edk2 base on: 2017-0904
now edk2 base on: 2018-0801

For D06 library, we use the same source code to support all Hi1620 projects,
include product projects,so there are some modify for this, like support
3 sockets, 4 sockets and remove some useless functions.

Thanks.

> 
> /
> Leif
> 
>>
>> diff --git 
>> a/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib
>>  
>> b/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib
>> index 68be770..4c63a26 100644
>> Binary files 
>> a/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib
>>  and 
>> b/Silicon/Hisilicon/Hi1610/Library/PlatformSysCtrlLibHi1610/PlatformSysCtrlLibHi1610.lib
>>  differ
>> diff --git 
>> a/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib
>>  
>> b/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib
>> index b3cc88e..cb2c652 100644
>> Binary files 
>> a/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib
>>  and 
>> b/Silicon/Hisilicon/Hi1616/Library/PlatformSysCtrlLibHi1616/PlatformSysCtrlLibHi1616.lib
>>  differ
>> diff --git 
>> a/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib
>>  
>> b/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib
>> index 50d453a..d643f7b 100644
>> Binary files 
>> a/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib
>>  and 
>> b/Silicon/Hisilicon/Hi1620/Library/PlatformSysCtrlLibHi1620/PlatformSysCtrlLibHi1620.lib
>>  differ
>> -- 
>> 2.9.5
>>
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel