date:20191009

Re: [edk2-devel] [edk2-platforms][PATCH V2 1/3] IntelSiliconPkg/FirmwareBootMediaLib: Add library

2019-10-09 Thread Ni, Ray




> -Original Message-
> From: Kubacki, Michael A 
> Sent: Thursday, October 10, 2019 12:43 PM
> To: Ni, Ray ; devel@edk2.groups.io
> Cc: Chaganty, Rangasai V 
> Subject: RE: [edk2-platforms][PATCH V2 1/3]
> IntelSiliconPkg/FirmwareBootMediaLib: Add library
> 
> Replies below.
> 
> > -Original Message-
> > From: Ni, Ray 
> > Sent: Wednesday, October 9, 2019 7:21 PM
> > To: Kubacki, Michael A ;
> > devel@edk2.groups.io
> > Cc: Chaganty, Rangasai V 
> > Subject: RE: [edk2-platforms][PATCH V2 1/3]
> > IntelSiliconPkg/FirmwareBootMediaLib: Add library
> >
> > Comments below.
> >
> > > -Original Message-
> > > From: Kubacki, Michael A 
> > > Sent: Thursday, October 10, 2019 12:34 AM
> > > To: Ni, Ray ; devel@edk2.groups.io
> > > Cc: Chaganty, Rangasai V 
> > > Subject: RE: [edk2-platforms][PATCH V2 1/3]
> > > IntelSiliconPkg/FirmwareBootMediaLib: Add library
> > >
> > > 1. DxeSmmFirmwareBootMediaLib could get the HOB like PEI for every
> > > access. I considered this but it seems unnecessary since we have the
> > > flexibility for  phase-specific drivers that can have trivial
> > > optimizations like
> > this.
> > > Checking the HOB on every access would also constrain usage in
> > > DXE_SMM_DRIVER and DXE_RUNTIME_DRIVER modules.
> >
> > Having single library instance can make platform DSC simpler.
> > Because SMM and Runtime drivers are dispatched in BS phase, they can
> > cache the boot media type if the usage lasts to post-EndOfDxe or OS
> > runtime.
> >
> 
> I don't see an issue with phase-specific instances that cleanly comply with
> phase restrictions.
> 
> In general, PEI drivers cannot write to global variables. This change does
> cache the value in BS phase so it is available in OS runtime.
> 
>  * PEI: Do not write to a global variable. Use the heap to store the value via
> the HOB list. Always get the value from the HOB.
>  * DXE: Get the value from the HOB and store the value in a global variable
> during the library constructor in the BS phase so the value is available 
> during
> later phase transition.
> 
> What exactly are you proposing to change?
> 

I would like to see one library instance that can be used in both PEI and DXE.
The library implementation doesn't need to care when it's called. Caller is 
responsible to call the API
properly in boot time phase.

> > >
> > > 2. They are certainly not required, but in practice we've found code
> > > usage tends to read better and be more concise with these APIs for
> > > simple firmware boot media checks. The enum is provided for
> > > relatively rarer scenarios where many possibilities need to be
> > > considered such as usage in a switch statement. I can see a case
> > > made in either direction. Let me know if you and Sai feel strongly about
> this.
> >
> > I prefer to use enum and GetType() API. Because if there is more boot
> > media type, there is no need to add a new library API like IsXXX().
> > Not sure if it's over design, I prefer to use GUID against enum. No
> > strong preference of using GUID in this case.
> >
> 
> My preference is that the API is well-defined and stable. In this case, my
> primary thought  on the matter is not having two ways to do the same thing.
> And again, I have no strong preference for either case but we do have Intel
> code that favors the IsXXX () usage. I don't think adding new devices
> (extending the API) is so much an issue as ensuring the existing ones are not
> modified. Which would be the case for the enum members and the functions.
> In conclusion, I will send a patch to remove the IsXXX () functions.

Thanks.

> 
> Before adding GUIDs, the problem statement needs to be clearly articulated
> that justifies introducing GUID management.

I am ok with enum.

> 
> > Thanks,
> > Ray
> >
> > >
> > > Thanks,
> > > Michael
> > >
> > > > -Original Message-
> > > > From: Ni, Ray 
> > > > Sent: Wednesday, October 9, 2019 2:36 AM
> > > > To: Kubacki, Michael A ;
> > > > devel@edk2.groups.io
> > > > Cc: Chaganty, Rangasai V 
> > > > Subject: RE: [edk2-platforms][PATCH V2 1/3]
> > > > IntelSiliconPkg/FirmwareBootMediaLib: Add library
> > > >
> > > > Michael,
> > > > Two comments:
> > > > 1. The difference between PEI and DXE instances is DXE instance
> > > > has a global variable caching the boot media type. Both get the
> > > > type from HOB. So I am thinking how about simplifying the library
> > > > to have only one instance which equals to PEI instance. That can
> > > > also be used in DXE
> > > phase.
> > > > 2. With the definition of enum type FW_BOOT_MEDIA_TYPE and
> > GetType()
> > > > API, I feel the other several FirmwareBootMediaIsXXX() APIs are
> > > > not very necessary.
> > > >
> > > > Thanks,
> > > > Ray
> > > >
> > > > > -Original Message-
> > > > > From: Kubacki, Michael A 
> > > > > Sent: Saturday, October 5, 2019 1:29 AM
> > > > > To: devel@edk2.groups.io
> > > > > Cc: Chaganty, Rangasai V ; Ni,
> > > > > Ray 
> > > > > Subject: [edk2-platforms][PATCH V2

[edk2-devel] [edk2-platforms: PATCH v3 1/9] Marvell/Armada7k8k: Fix 32-bit compilation

2019-10-09 Thread Marcin Wojtas

It turned out, that the recently added features broke
ARM compilation. Fix all issues:
* Update signatures types in structures (UINTN -> UINT64)
* Use fixed type for address in ICU
* Limit memory for ARM build to 1GB and stop using non-existent PCD

Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.h   |  2 
+-
 Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h   |  2 
+-
 Silicon/Marvell/Include/Library/ArmadaSoCDescLib.h   |  4 
++--
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c  |  8 

 Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/ARM/ArmPlatformHelper.S | 11 
---
 5 files changed, 12 insertions(+), 15 deletions(-)

diff --git a/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.h 
b/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.h
index a6f551b..3b5a28c 100644
--- a/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.h
+++ b/Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.h
@@ -22,7 +22,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
 
 typedef struct {
   MARVELL_BOARD_DESC_PROTOCOL   BoardDescProtocol;
-  UINTN   Signature;
+  UINT64  Signature;
   EFI_HANDLE  Handle;
   EFI_LOCKLock;
 } MV_BOARD_DESC;
diff --git a/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h 
b/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h
index 1cb006a..ce683e7 100644
--- a/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h
+++ b/Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h
@@ -36,7 +36,7 @@ typedef struct {
   EMBEDDED_GPIO GpioProtocol;
   GPIO_CONTROLLER  *SoCGpio;
   UINTN GpioDeviceCount;
-  UINTN Signature;
+  UINT64Signature;
   EFI_HANDLEHandle;
 } MV_GPIO;
 
diff --git a/Silicon/Marvell/Include/Library/ArmadaSoCDescLib.h 
b/Silicon/Marvell/Include/Library/ArmadaSoCDescLib.h
index 6432916..da7a41e 100644
--- a/Silicon/Marvell/Include/Library/ArmadaSoCDescLib.h
+++ b/Silicon/Marvell/Include/Library/ArmadaSoCDescLib.h
@@ -109,8 +109,8 @@ typedef enum {
 
 typedef struct {
   ICU_GROUP Group;
-  UINTN SetSpiAddr;
-  UINTN ClrSpiAddr;
+  EFI_PHYSICAL_ADDRESS SetSpiAddr;
+  EFI_PHYSICAL_ADDRESS ClrSpiAddr;
 } ICU_MSI;
 
 typedef struct {
diff --git 
a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c 
b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c
index a735fe5..cc19694 100644
--- a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c
+++ b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c
@@ -36,6 +36,7 @@ GetDramSize (
   IN OUT UINT64 *MemSize
   )
 {
+#if defined(MDE_CPU_AARCH64)
   ARM_SMC_ARGS SmcRegs = {0};
   EFI_STATUS Status;
 
@@ -48,6 +49,13 @@ GetDramSize (
   ArmCallSmc ();
 
   *MemSize = SmcRegs.Arg0;
+#else
+  //
+  // Use fixed value, as currently there is no support
+  // in Armada early firmware for 32-bit SMC
+  //
+  *MemSize = FixedPcdGet64 (PcdSystemMemorySize);
+#endif
 
   return EFI_SUCCESS;
 }
diff --git 
a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/ARM/ArmPlatformHelper.S 
b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/ARM/ArmPlatformHelper.S
index 4416163..db43b0f 100644
--- a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/ARM/ArmPlatformHelper.S
+++ b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/ARM/ArmPlatformHelper.S
@@ -28,17 +28,6 @@ ASM_FUNC(ArmPlatformPeiBootAction)
   .err  PcdSystemMemoryBase should be 0x0 on this platform!
   .endif
 
-  .if   FixedPcdGet64 (PcdSystemMemorySize) > FixedPcdGet32 
(PcdDramRemapTarget)
-//
-// Use the low range for UEFI itself. The remaining memory will be mapped
-// and added to the GCD map later.
-//
-ADRL  (r0, mSystemMemoryEnd)
-MOV32 (r2, FixedPcdGet32 (PcdDramRemapTarget) - 1)
-mov   r3, #0
-strd  r2, r3, [r0]
-  .endif
-
   bxlr
 
 //UINTN
-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48695): https://edk2.groups.io/g/devel/message/48695
Mute This Topic: https://groups.io/mt/34471897/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms: PATCH v3 9/9] Marvell: Customize per-board SBMIOS strings

2019-10-09 Thread Marcin Wojtas

Now that the customization of Type1/2/3 SBMIOS
tables strings is possible, adjust them for all
supported boards.

Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc|  4 
 Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc|  4 
 Platform/Marvell/Cn913xDb/Cn913xDbA.dsc   | 11 +++
 Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.dsc |  5 +
 4 files changed, 24 insertions(+)

diff --git a/Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc 
b/Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc
index 523e60e..3626967 100644
--- a/Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc
+++ b/Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc
@@ -45,6 +45,10 @@
 #
 

 [PcdsFixedAtBuild.common]
+  #Platform description
+  gMarvellTokenSpaceGuid.PcdProductPlatformName|"Armada 7040 DB\0"
+  gMarvellTokenSpaceGuid.PcdProductVersion|"Rev. 1.5\0"
+
   #CP110 count
   gMarvellTokenSpaceGuid.PcdMaxCpCount|1
 
diff --git a/Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc 
b/Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc
index 4e6e62b..ce0c541 100644
--- a/Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc
+++ b/Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc
@@ -45,6 +45,10 @@
 #
 

 [PcdsFixedAtBuild.common]
+  #Platform description
+  gMarvellTokenSpaceGuid.PcdProductPlatformName|"Armada 8040 DB\0"
+  gMarvellTokenSpaceGuid.PcdProductVersion|"Rev. 1.4\0"
+
   #MPP
   gMarvellTokenSpaceGuid.PcdMppChipCount|3
 
diff --git a/Platform/Marvell/Cn913xDb/Cn913xDbA.dsc 
b/Platform/Marvell/Cn913xDb/Cn913xDbA.dsc
index 268c39c..bcc5158 100644
--- a/Platform/Marvell/Cn913xDb/Cn913xDbA.dsc
+++ b/Platform/Marvell/Cn913xDb/Cn913xDbA.dsc
@@ -62,3 +62,14 @@
   
ArmadaBoardDescLib|Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.inf
 !endif
   
NonDiscoverableInitLib|Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.inf
+
+[PcdsFixedAtBuild.common]
+  #Platform description
+  !if $(CN9130)
+  gMarvellTokenSpaceGuid.PcdProductPlatformName|"CN9130 DB-A\0"
+  !elseif $(CN9131)
+  gMarvellTokenSpaceGuid.PcdProductPlatformName|"CN9131 DB-A\0"
+  !elseif $(CN9132)
+  gMarvellTokenSpaceGuid.PcdProductPlatformName|"CN9132 DB-A\0"
+  !endif
+  gMarvellTokenSpaceGuid.PcdProductVersion|"Rev. 1.1\0"
diff --git a/Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.dsc 
b/Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.dsc
index 2b42d75..f7d5a57 100644
--- a/Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.dsc
+++ b/Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.dsc
@@ -46,6 +46,11 @@
 #
 

 [PcdsFixedAtBuild.common]
+  #Platform description
+  gMarvellTokenSpaceGuid.PcdProductManufacturer|"SolidRun\0"
+  gMarvellTokenSpaceGuid.PcdProductPlatformName|"Armada 8040 MacchiatoBin\0"
+  gMarvellTokenSpaceGuid.PcdProductVersion|"Rev. 1.3\0"
+
   #MPP
   gMarvellTokenSpaceGuid.PcdMppChipCount|3
 
-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48703): https://edk2.groups.io/g/devel/message/48703
Mute This Topic: https://groups.io/mt/34471906/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms: PATCH v3 3/9] Marvell/Cn9130Db: Introduce board support

2019-10-09 Thread Marcin Wojtas

This patch introduces all necessary components required
for building EDK2 firmware for CN9130-DB setup A.
Because the board is modular and can be extended to support
also CN9131 and CN9132 SoC variants, extract common part into
.dsc.inc file, which will be included by them.

In order to build this variant, '-D CN9130' flag should be added.

Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Cn913xDb/Cn9130DbA.dsc.inc | 
107 +++
 Platform/Marvell/Cn913xDb/Cn913xDbA.dsc |  
48 +++
 Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.inf |  
29 
 Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.inf |  
37 +
 Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.h   |  
19 +++
 Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.c   | 
126 +
 Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.c   | 
144 
 Platform/Marvell/Cn913xDb/Cn913xDbA.fdf.inc |  
18 +++
 8 files changed, 528 insertions(+)
 create mode 100644 Platform/Marvell/Cn913xDb/Cn9130DbA.dsc.inc
 create mode 100644 Platform/Marvell/Cn913xDb/Cn913xDbA.dsc
 create mode 100644 
Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.inf
 create mode 100644 
Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.inf
 create mode 100644 
Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.h
 create mode 100644 
Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.c
 create mode 100644 
Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.c
 create mode 100644 Platform/Marvell/Cn913xDb/Cn913xDbA.fdf.inc

diff --git a/Platform/Marvell/Cn913xDb/Cn9130DbA.dsc.inc 
b/Platform/Marvell/Cn913xDb/Cn9130DbA.dsc.inc
new file mode 100644
index 000..33fb7cc
--- /dev/null
+++ b/Platform/Marvell/Cn913xDb/Cn9130DbA.dsc.inc
@@ -0,0 +1,107 @@
+## @file
+#  Component description file for the CN9130 Development Board (variant A)
+#
+#  Copyright (c) 2019 Marvell International Ltd.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+
+#
+# Pcd Section - list of all EDK II PCD Entries defined by this Platform
+#
+
+[PcdsFixedAtBuild.common]
+  # CP115 count
+  gMarvellTokenSpaceGuid.PcdMaxCpCount|1
+
+  # MPP
+  gMarvellTokenSpaceGuid.PcdMppChipCount|2
+
+  # APN807 MPP
+  gMarvellTokenSpaceGuid.PcdChip0MppReverseFlag|FALSE
+  gMarvellTokenSpaceGuid.PcdChip0MppBaseAddress|0xF06F4000
+  gMarvellTokenSpaceGuid.PcdChip0MppPinCount|20
+  gMarvellTokenSpaceGuid.PcdChip0MppSel0|{ 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 
0x1, 0x1, 0x1 }
+  gMarvellTokenSpaceGuid.PcdChip0MppSel1|{ 0x1, 0x3, 0x1, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x3 }
+
+  # CP115 #0 MPP
+  gMarvellTokenSpaceGuid.PcdChip1MppReverseFlag|FALSE
+  gMarvellTokenSpaceGuid.PcdChip1MppBaseAddress|0xF244
+  gMarvellTokenSpaceGuid.PcdChip1MppPinCount|64
+  gMarvellTokenSpaceGuid.PcdChip1MppSel0|{ 0x3, 0x3, 0x3, 0x3, 0x3, 0x3, 0x3, 
0x3, 0x3, 0x3 }
+  gMarvellTokenSpaceGuid.PcdChip1MppSel1|{ 0x3, 0x3, 0x0, 0x3, 0x3, 0x3, 0x3, 
0x1, 0x1, 0x1 }
+  gMarvellTokenSpaceGuid.PcdChip1MppSel2|{ 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 
0x1, 0x3, 0x9 }
+  gMarvellTokenSpaceGuid.PcdChip1MppSel3|{ 0x9, 0x3, 0x7, 0x6, 0x7, 0x2, 0x2, 
0x2, 0x2, 0x1 }
+  gMarvellTokenSpaceGuid.PcdChip1MppSel4|{ 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 
0x1, 0x1, 0x1 }
+  gMarvellTokenSpaceGuid.PcdChip1MppSel5|{ 0x1, 0x1, 0x1, 0x1, 0x1, 0x1, 0xE, 
0xE, 0xE, 0xE }
+  gMarvellTokenSpaceGuid.PcdChip1MppSel6|{ 0xE, 0xE, 0xE, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
+
+  # I2C
+  gMarvellTokenSpaceGuid.PcdI2cSlaveAddresses|{ 0x21 }
+  gMarvellTokenSpaceGuid.PcdI2cSlaveBuses|{ 0x0 }
+  gMarvellTokenSpaceGuid.PcdI2cControllersEnabled|{ 0x0, 0x1 }
+  gMarvellTokenSpaceGuid.PcdI2cClockFrequency|25000
+  gMarvellTokenSpaceGuid.PcdI2cBaudRate|10
+
+  # SPI
+  gMarvellTokenSpaceGuid.PcdSpiRegBase|0xF2700680
+  gMarvellTokenSpaceGuid.PcdSpiMaxFrequency|1000
+  gMarvellTokenSpaceGuid.PcdSpiClockFrequency|2
+
+  gMarvellTokenSpaceGuid.PcdSpiFlashMode|3
+  gMarvellTokenSpaceGuid.PcdSpiFlashCs|0
+
+  # ComPhy
+  gMarvellTokenSpaceGuid.PcdComPhyDevices|{ 0x1 }
+  # ComPhy0
+  # 0: PCIE0 5 Gbps
+  # 1: PCIE0 5 Gbps
+  # 2: PCIE0 5 Gbps
+  # 3: PCIE0 5 Gbps
+  # 4: SFI   10.31 Gbps
+  # 5: SATA1 5 Gbps
+  gMarvellTokenSpaceGuid.PcdChip0ComPhyTypes|{ $(CP_PCIE0), $(CP_PCIE0), 
$(CP_PCIE0), $(CP_PCIE0), $(CP_SFI), $(CP_SATA1)}
+  gMarvellTokenSpaceGuid.PcdChip0ComPhySpeeds|{ $(CP_5G), $(CP_5G), $(CP_5G), 
$(CP_5G), $(CP_10_3125G), $(CP_5G) }
+
+  # UtmiPhy
+  gMarvellTokenSpaceGuid.PcdUtmiControllersEnabled|{ 0x1, 0x1 }
+

[edk2-devel] [edk2-platforms: PATCH v3 7/9] Marvell/Cn9132Db: Introduce board support

2019-10-09 Thread Marcin Wojtas

This patch introduces all necessary components required
for building EDK2 firmware for CN9132-DB setup A. Note
the ACPI is not yet available for this variant, due to
the current ICU (CP1xx interrupt controller) support
implementation.

In order to build this variant, '-D CN9132' flag should be added.

Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Cn913xDb/Cn9132DbA.dsc.inc   |  
72 +++
 Platform/Marvell/Cn913xDb/Cn913xDbA.dsc   |  
13 +-
 Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9132DbABoardDescLib.inf   |  
29 +
 Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.h |   
4 +
 Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9132DbABoardDescLib.c | 
135 
 Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.c |  
42 ++
 Platform/Marvell/Cn913xDb/Cn913xDbA.fdf.inc   |   
2 +
 7 files changed, 296 insertions(+), 1 deletion(-)
 create mode 100644 Platform/Marvell/Cn913xDb/Cn9132DbA.dsc.inc
 create mode 100644 
Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9132DbABoardDescLib.inf
 create mode 100644 
Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9132DbABoardDescLib.c

diff --git a/Platform/Marvell/Cn913xDb/Cn9132DbA.dsc.inc 
b/Platform/Marvell/Cn913xDb/Cn9132DbA.dsc.inc
new file mode 100644
index 000..a0b90fa
--- /dev/null
+++ b/Platform/Marvell/Cn913xDb/Cn9132DbA.dsc.inc
@@ -0,0 +1,72 @@
+## @file
+#  Component description file for the CN9132 Development Board (variant A)
+#
+#  Copyright (c) 2019 Marvell International Ltd.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+
+#
+# Pcd Section - list of all EDK II PCD Entries defined by this Platform
+#
+
+[PcdsFixedAtBuild.common]
+  # CP115 count
+  gMarvellTokenSpaceGuid.PcdMaxCpCount|3
+
+  # MPP
+  gMarvellTokenSpaceGuid.PcdMppChipCount|4
+
+  # CP115 #2 MPP
+  gMarvellTokenSpaceGuid.PcdChip3MppReverseFlag|FALSE
+  gMarvellTokenSpaceGuid.PcdChip3MppBaseAddress|0xF644
+  gMarvellTokenSpaceGuid.PcdChip3MppPinCount|64
+  gMarvellTokenSpaceGuid.PcdChip3MppSel0|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip3MppSel1|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip3MppSel2|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x9, 0x9, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip3MppSel3|{ 0x0, 0x0, 0x8, 0x0, 0x8, 0x0, 0x0, 
0x2, 0x2, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip3MppSel4|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip3MppSel5|{ 0x0, 0x0, 0x0, 0x0, 0xA, 0xB, 0xE, 
0xE, 0xE, 0xE }
+  gMarvellTokenSpaceGuid.PcdChip3MppSel6|{ 0xE, 0xE, 0xE, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
+
+  # ComPhy
+  gMarvellTokenSpaceGuid.PcdComPhyDevices|{ 0x1, 0x1, 0x1 }
+  # ComPhy1
+  # 0: PCIE0 5 Gbps
+  # 1: PCIE0 5 Gbps
+  # 2: SATA0 5 Gbps
+  # 3: USB3_HOST15 Gbps
+  # 4: SFI   10.31 Gbps
+  # 5: PCIE2 5 Gbps
+  gMarvellTokenSpaceGuid.PcdChip2ComPhyTypes|{ $(CP_PCIE0), $(CP_PCIE0), 
$(CP_SATA0), $(CP_USB3_HOST1), $(CP_SFI), $(CP_PCIE2)}
+  gMarvellTokenSpaceGuid.PcdChip2ComPhySpeeds|{ $(CP_5G), $(CP_5G), $(CP_5G), 
$(CP_5G), $(CP_10_3125G), $(CP_5G) }
+
+  # UtmiPhy
+  gMarvellTokenSpaceGuid.PcdUtmiControllersEnabled|{ 0x1, 0x1, 0x0, 0x1, 0x1, 
0x1 }
+  gMarvellTokenSpaceGuid.PcdUtmiPortType|{ $(UTMI_USB_HOST0), 
$(UTMI_USB_HOST1), $(UTMI_USB_HOST0), $(UTMI_USB_HOST1), $(UTMI_USB_HOST0), 
$(UTMI_USB_HOST1) }
+
+  # MDIO
+  gMarvellTokenSpaceGuid.PcdMdioControllersEnabled|{ 0x1, 0x0 }
+
+  # PHY
+  gMarvellTokenSpaceGuid.PcdPhy2MdioController|{ 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPhyDeviceIds|{ 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPhySmiAddresses|{ 0x0, 0x1 }
+  gMarvellTokenSpaceGuid.PcdPhyStartupAutoneg|FALSE
+
+  # NET
+  gMarvellTokenSpaceGuid.PcdPp2GopIndexes|{ 0x0, 0x2, 0x3, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPp2InterfaceAlwaysUp|{ 0x0, 0x0, 0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPp2InterfaceSpeed|{ $(PHY_SPEED_1), 
$(PHY_SPEED_1000), $(PHY_SPEED_1000), $(PHY_SPEED_1), $(PHY_SPEED_1) }
+  gMarvellTokenSpaceGuid.PcdPp2PhyConnectionTypes|{ $(PHY_SFI), $(PHY_RGMII), 
$(PHY_RGMII), $(PHY_SFI), $(PHY_SFI) }
+  gMarvellTokenSpaceGuid.PcdPp2PhyIndexes|{ 0xFF, 0x0, 0x1, 0xFF, 0xFF }
+  gMarvellTokenSpaceGuid.PcdPp2Port2Controller|{ 0x0, 0x0, 0x0, 0x1, 0x2 }
+  gMarvellTokenSpaceGuid.PcdPp2PortIds|{ 0x0, 0x1, 0x2, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPp2Controllers|{ 0x1, 0x1, 0x1 }
+
+  # NonDiscoverableDevices
+  gMarvellTokenSpaceGuid.PcdPciEXhci|{ 0x1, 0x1, 0x0, 0x1, 0x1, 0x1 }
+  gMarvellTokenSpaceGuid.PcdPciEAhci|{ 0x1, 0x1, 0x1 }
+  gMarvellTokenSpaceGuid.PcdPciESdhci|{ 0x1, 0x1, 0x0, 0x1 }
diff --git

[edk2-devel] [edk2-platforms: PATCH v3 5/9] Marvell/Library: IcuLib: Fix debug information

2019-10-09 Thread Marcin Wojtas

In case the number of CP11x components exceeded the maximum
of currently supported, the user is informed with the information.
It turned out that the print arguments were incorrect - fix it.

Signed-off-by: Marcin Wojtas 
Reviewed-by: Leif Lindholm 
---
 Silicon/Marvell/Library/IcuLib/IcuLib.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Silicon/Marvell/Library/IcuLib/IcuLib.c 
b/Silicon/Marvell/Library/IcuLib/IcuLib.c
index 343c21b..4d9f174 100644
--- a/Silicon/Marvell/Library/IcuLib/IcuLib.c
+++ b/Silicon/Marvell/Library/IcuLib/IcuLib.c
@@ -280,8 +280,8 @@ ArmadaIcuInitialize (
   if (CpCount > ICU_MAX_SUPPORTED_UNITS) {
 DEBUG ((DEBUG_ERROR,
   "%a: Default ICU to GIC mapping is available for maximum %d CP110 units",
-  ICU_MAX_SUPPORTED_UNITS,
-  __FUNCTION__));
+  __FUNCTION__,
+  ICU_MAX_SUPPORTED_UNITS));
 CpCount = ICU_MAX_SUPPORTED_UNITS;
   }
 
-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48699): https://edk2.groups.io/g/devel/message/48699
Mute This Topic: https://groups.io/mt/34471901/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-non-osi: PATCH 1/3] Marvell/Cn9130Db: Add DeviceTree

2019-10-09 Thread Marcin Wojtas

This patch adds device tree sources which are common for Cn913x SoCs
and the CN9130 development board (variant A).

Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9130DbA.inf  |  22 +
 Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806-quad.dtsi |  43 ++
 Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806.dtsi  | 264 ++
 Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-common.dtsi |  10 +
 Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-cp110.dtsi  | 552 

 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130-db-A.dts| 185 +++
 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130-db.dtsi | 168 ++
 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130.dtsi| 126 +
 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db-A.dts|  29 +
 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db.dtsi | 173 ++
 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db-A.dts|  76 +++
 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db.dtsi | 151 ++
 12 files changed, 1799 insertions(+)
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9130DbA.inf
 create mode 100644 
Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806-quad.dtsi
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806.dtsi
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-common.dtsi
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-cp110.dtsi
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130-db-A.dts
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130-db.dtsi
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9130.dtsi
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db-A.dts
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db.dtsi
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db-A.dts
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db.dtsi

diff --git a/Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9130DbA.inf 
b/Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9130DbA.inf
new file mode 100644
index 000..091a5b4
--- /dev/null
+++ b/Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9130DbA.inf
@@ -0,0 +1,22 @@
+## @file
+#
+#  Device tree description of the Marvell CN9130-DB-A platform
+#
+#  Copyright (c) 2019, Marvell International Ltd. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x0001001B
+  BASE_NAME  = Cn9130DbADeviceTree
+  FILE_GUID  = 25462CDA-221F-47DF-AC1D-259CFAA4E326 # 
gDtPlatformDefaultDtbFileGuid
+  MODULE_TYPE= USER_DEFINED
+  VERSION_STRING = 1.0
+
+[Sources]
+  cn9130-db-A.dts
+
+[Packages]
+  MdePkg/MdePkg.dec
diff --git a/Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806-quad.dtsi 
b/Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806-quad.dtsi
new file mode 100644
index 000..bae0ed9
--- /dev/null
+++ b/Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806-quad.dtsi
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * Device Tree file for Marvell Armada AP806.
+ */
+
+#include "armada-ap806.dtsi"
+
+/ {
+model = "Marvell Armada AP806 Quad";
+compatible = "marvell,armada-ap806-quad", "marvell,armada-ap806";
+
+cpus {
+#address-cells = <1>;
+#size-cells = <0>;
+
+cpu@0 {
+device_type = "cpu";
+compatible = "arm,cortex-a72", "arm,armv8";
+reg = <0x000>;
+enable-method = "psci";
+};
+cpu@1 {
+device_type = "cpu";
+compatible = "arm,cortex-a72", "arm,armv8";
+reg = <0x001>;
+enable-method = "psci";
+};
+cpu@100 {
+device_type = "cpu";
+compatible = "arm,cortex-a72", "arm,armv8";
+reg = <0x100>;
+enable-method = "psci";
+};
+cpu@101 {
+device_type = "cpu";
+compatible = "arm,cortex-a72", "arm,armv8";
+reg = <0x101>;
+enable-method = "psci";
+};
+};
+};
diff --git a/Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806.dtsi 
b/Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806.dtsi
new file mode 100644
index 000..66124bf
--- /dev/null
+++ b/Silicon/Marvell/OcteonTx/DeviceTree/T91/armada-ap806.dtsi
@@ -0,0 +1,264 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2016 Marvell Technology Group Ltd.
+ *
+ * Device Tree file for Marvell Armada AP806.
+ */
+
+#define IRQ_TYPE_LEVEL_HIGH  (1 << 2)
+#define

[edk2-devel] [edk2-platforms: PATCH v3 8/9] Marvell/Drivers: SmbiosPlatformDxe: Load SMBIOS strings from PCD

2019-10-09 Thread Marcin Wojtas

From: Patryk Duda 

This patch implements convenient way of changing strings included
in SMBIOS Table1, Table2, Table3.

Strings can be altered by defining following PCDs:
  gMarvellTokenSpaceGuid.PcdProductManufacturer
  gMarvellTokenSpaceGuid.PcdProductPlatformName
  gMarvellTokenSpaceGuid.PcdProductVersion
  gMarvellTokenSpaceGuid.PcdProductSerial

This patch adds also limit for length of string which can be increased
if necessary in future.

Signed-off-by: Patryk Duda 
---
 Silicon/Marvell/Marvell.dec |  6 ++
 Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf |  4 +
 Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c   | 79 
+---
 3 files changed, 78 insertions(+), 11 deletions(-)

diff --git a/Silicon/Marvell/Marvell.dec b/Silicon/Marvell/Marvell.dec
index d337d3e..a84b056 100644
--- a/Silicon/Marvell/Marvell.dec
+++ b/Silicon/Marvell/Marvell.dec
@@ -169,6 +169,12 @@
   gMarvellTokenSpaceGuid.PcdPciEAhci|{ 0x0 }|VOID*|0x334
   gMarvellTokenSpaceGuid.PcdPciESdhci|{ 0x0 }|VOID*|0x335
 
+#Platform description
+  gMarvellTokenSpaceGuid.PcdProductManufacturer|"Marvell   
 \0"|VOID*|0x5100
+  gMarvellTokenSpaceGuid.PcdProductPlatformName|"Marvell Development Board 
 \0"|VOID*|0x5101
+  gMarvellTokenSpaceGuid.PcdProductSerial|"Serial Not Set 
\0"|VOID*|0x5103
+  gMarvellTokenSpaceGuid.PcdProductVersion|"Revision unknown   
\0"|VOID*|0x5102
+
 #RTC
   gMarvellTokenSpaceGuid.PcdRtcBaseAddress|0x0|UINT64|0x4052
 
diff --git a/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf 
b/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
index 8b4586c..7722146 100644
--- a/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
+++ b/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
@@ -36,6 +36,10 @@
 
 [FixedPcd]
   gEfiMdeModulePkgTokenSpaceGuid.PcdFirmwareRevision
+  gMarvellTokenSpaceGuid.PcdProductManufacturer
+  gMarvellTokenSpaceGuid.PcdProductPlatformName
+  gMarvellTokenSpaceGuid.PcdProductSerial
+  gMarvellTokenSpaceGuid.PcdProductVersion
 
 [Protocols]
   gEfiSmbiosProtocolGuid  # PROTOCOL ALWAYS_CONSUMED
diff --git a/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c 
b/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
index 08f4fa7..c5b1d77 100644
--- a/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
+++ b/Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c
@@ -21,6 +21,22 @@
 #include 
 
 //
+// SMBIOS specification indicates that there is no limit for string size.
+// However, some strings are printed in UEFI and OS. Printing very big string
+// can lead to unexpected behaviour. Second reason of string size definition
+// is that static buffers can be used instead of dynamic ones.
+//
+// Nevertheless, this value can be increased if necessary
+//
+
+#define MV_SMBIOS_STRING_MAX_SIZE 32
+
+STATIC CHAR8 mSysInfoManufacturer[MV_SMBIOS_STRING_MAX_SIZE];
+STATIC CHAR8 mSysInfoProductName[MV_SMBIOS_STRING_MAX_SIZE];
+STATIC CHAR8 mSysInfoVersion[MV_SMBIOS_STRING_MAX_SIZE];
+STATIC CHAR8 mSysInfoSerial[MV_SMBIOS_STRING_MAX_SIZE];
+
+//
 // SMBIOS tables often reference each other using
 // fixed constants, define a list of these constants
 // for our hardcoded tables
@@ -101,10 +117,10 @@ STATIC SMBIOS_TABLE_TYPE1 mArmadaDefaultType1 = {
 };
 
 STATIC CHAR8 CONST *mArmadaDefaultType1Strings[] = {
-  "Marvell\0",/* Manufacturer */
-  "Armada 7k/8k Family Board  \0",/* Product Name placeholder*/
-  "Revision unknown   \0",/* Version placeholder */
-  "   \0",/* 32 character buffer */
+  mSysInfoManufacturer,
+  mSysInfoProductName,
+  mSysInfoVersion,
+  mSysInfoSerial,
   NULL
 };
 
@@ -129,10 +145,10 @@ STATIC SMBIOS_TABLE_TYPE2 mArmadaDefaultType2 = {
 };
 
 STATIC CHAR8 CONST *mArmadaDefaultType2Strings[] = {
-  "Marvell\0",/* Manufacturer */
-  "Armada 7k/8k Family Board  \0",/* Product Name placeholder*/
-  "Revision unknown   \0",/* Version placeholder */
-  "Serial Not Set \0",/* Serial */
+  mSysInfoManufacturer,
+  mSysInfoProductName,
+  mSysInfoVersion,
+  mSysInfoSerial,
   "Base of Chassis\0",/* Board location */
   NULL
 };
@@ -160,9 +176,9 @@ STATIC SMBIOS_TABLE_TYPE3 mArmadaDefaultType3 = {
 };
 
 STATIC CHAR8 CONST *mArmadaDefaultType3Strings[] = {
-  "Marvell\0",/* Manufacturer placeholder */
-  "Revision unknown   \0",/* Version placeholder */
-  "Serial Not Set \0",/* Serial placeholder */
+  mSysInfoManufacturer,
+  mSysInfoVersion,
+  mSysInfoSerial,
   NULL
 };
 
@@ -743,6 +759,45 @@ SmbiosMemoryInstall (
 }
 
 /**
+   Copy Type1, Type2, Type3 strings form PCD
+**/
+
+STATIC
+VOID
+MvSmbiosCopyStrings (
+   VOID
+   )
+{
+

[edk2-devel] [edk2-platforms: PATCH v3 0/9] Marvell Octeon CN913X SoC family support

2019-10-09 Thread Marcin Wojtas

Hi,

After a couple of weeks I finaly was able to submit
the third version of CN913X SoC family support
introduction.

Following the v2 comments the device tree part was
moved to the edk2-platforms. Also there is no default
platform built, so in any case the build flag must
be declared explicitly.

Also 2 Xenon-related patches were squashed, ARM
compilation fix was reworked and the way of updating
the SMBIOS tables was reimplemented to use PCDs.

For more details please see the changelog below
and commit logs.

The patches are available in the github:
https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/cn913x-upstream-r20191009

I'm looking forward to your comments or remarks.

Best regards,
Marcin

Changelog:
v2->v3
* 1/9
  - update signatures types in structures (UINTN -> UINT64)
  - add comment in setting memory size
  - rework fix for ICU compilation - use fixed type

* 2/9
  - add Leif's Acked-by

* 3/9, 6/9, 7/9
  - remove leading __ from include guards in header
  - require specifying flag for the platform - no default will be built
  - move dts part to edk2-platforms and update the commit message

* 4/9
  - squash Xenon-related patches from v2

* 5/9
  - Add Leif's RB

* 8/9
  - Rework patch and allow updating SMBIOS strings from PCDs

* 9/9
  - New patch, customizing SMBIOS strings for supported boards

v1->v2:

* 1/10 (new patch)
  - fix 32-bit compilation

* 4/10
  - fix OEM Table ID length in DSDT
  - rename .dsc / .fdf.inc - they are used by all variants

* 8,9/10
  - remove redundant .dsc / .fdf files
  - enable building with '-D CN9131' / '-D CN9132' flags
  - fix OEM Table ID length in SSDT (CN9131)

Marcin Wojtas (8):
  Marvell/Armada7k8k: Fix 32-bit compilation
  Marvell/Cn9130Db: Add ACPI tables
  Marvell/Cn9130Db: Introduce board support
  Marvell/Library: ArmadaSoCDescLib/MppLib: Extend Xenon information
  Marvell/Library: IcuLib: Fix debug information
  Marvell/Cn9131Db: Introduce board support
  Marvell/Cn9132Db: Introduce board support
  Marvell: Customize per-board SBMIOS strings

Patryk Duda (1):
  Marvell/Drivers: SmbiosPlatformDxe: Load SMBIOS strings from PCD

 Silicon/Marvell/Marvell.dec
|   6 +
 Platform/Marvell/Cn913xDb/Cn9130DbA.dsc.inc
| 107 +++
 Platform/Marvell/Cn913xDb/Cn9131DbA.dsc.inc
|  72 +
 Platform/Marvell/Cn913xDb/Cn9132DbA.dsc.inc
|  72 +
 Platform/Marvell/Armada70x0Db/Armada70x0Db.dsc 
|   4 +
 Platform/Marvell/Armada80x0Db/Armada80x0Db.dsc 
|   4 +
 Platform/Marvell/Cn913xDb/Cn913xDbA.dsc
|  75 +
 Platform/SolidRun/Armada80x0McBin/Armada80x0McBin.dsc  
|   5 +
 Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.inf
|  29 ++
 Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9132DbABoardDescLib.inf
|  29 ++
 Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.inf
|  37 +++
 Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
|   4 +
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9130DbA.inf  
|  56 
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA.inf  
|  57 
 Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.h  
|  25 ++
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h 
|   5 +-
 Silicon/Marvell/Drivers/BoardDesc/MvBoardDescDxe.h 
|   2 +-
 Silicon/Marvell/Drivers/Gpio/MvGpioDxe/MvGpioDxe.h 
|   2 +-
 Silicon/Marvell/Include/Library/ArmadaSoCDescLib.h 
|   4 +-
 Silicon/Marvell/OcteonTx/AcpiTables/T91/AcpiHeader.h   
|  39 +++
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Pcie.h   
|  20 ++
 Silicon/Marvell/OcteonTx/AcpiTables/T91/IcuInterrupts.h
|  36 +++
 Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9130DbABoardDescLib.c  
| 126 
 Platform/Marvell/Cn913xDb/BoardDescriptionLib/Cn9132DbABoardDescLib.c  
| 135 
 Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.c  
| 215 +
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c
|   8 +
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c 
|  34 +-
 Silicon/Marvell/Drivers/SmbiosPlatformDxe/SmbiosPlatformDxe.c  
|  79 -
 Silicon/Marvell/Library/IcuLib/IcuLib.c
|   4 +-
 Silicon/Marvell/Library/MppLib/MppLib.c
|   4 +-
 Platform/Marvell/Cn913xDb/Cn913xDbA.fdf.inc
|  20 ++

[edk2-devel] [edk2-platforms: PATCH v3 6/9] Marvell/Cn9131Db: Introduce board support

2019-10-09 Thread Marcin Wojtas

This patch introduces all necessary components required
for building EDK2 firmware for CN9131-DB setup A.

In order to build this variant, '-D CN9131' flag should be added.

Signed-off-by: Marcin Wojtas 
---
 Platform/Marvell/Cn913xDb/Cn9131DbA.dsc.inc   | 72 
++
 Platform/Marvell/Cn913xDb/Cn913xDbA.dsc   |  5 
+
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA.inf | 57 

 Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.h |  2 
+
 Silicon/Marvell/OcteonTx/AcpiTables/T91/AcpiHeader.h  |  2 
+
 Platform/Marvell/Cn913xDb/NonDiscoverableInitLib/NonDiscoverableInitLib.c | 29 
++
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA/Ssdt.asl| 98 

 7 files changed, 265 insertions(+)
 create mode 100644 Platform/Marvell/Cn913xDb/Cn9131DbA.dsc.inc
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA.inf
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9131DbA/Ssdt.asl

diff --git a/Platform/Marvell/Cn913xDb/Cn9131DbA.dsc.inc 
b/Platform/Marvell/Cn913xDb/Cn9131DbA.dsc.inc
new file mode 100644
index 000..7235b9f
--- /dev/null
+++ b/Platform/Marvell/Cn913xDb/Cn9131DbA.dsc.inc
@@ -0,0 +1,72 @@
+## @file
+#  Component description file for the CN9131 Development Board (variant A)
+#
+#  Copyright (c) 2019 Marvell International Ltd.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+
+#
+# Pcd Section - list of all EDK II PCD Entries defined by this Platform
+#
+
+[PcdsFixedAtBuild.common]
+  # CP115 count
+  gMarvellTokenSpaceGuid.PcdMaxCpCount|2
+
+  # MPP
+  gMarvellTokenSpaceGuid.PcdMppChipCount|3
+
+  # CP115 #1 MPP
+  gMarvellTokenSpaceGuid.PcdChip2MppReverseFlag|FALSE
+  gMarvellTokenSpaceGuid.PcdChip2MppBaseAddress|0xF444
+  gMarvellTokenSpaceGuid.PcdChip2MppPinCount|64
+  gMarvellTokenSpaceGuid.PcdChip2MppSel0|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip2MppSel1|{ 0x0, 0x0, 0x0, 0x3, 0x3, 0x3, 0x3, 
0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip2MppSel2|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x9, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip2MppSel3|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x7, 0x7, 
0x2, 0x2, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip2MppSel4|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip2MppSel5|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdChip2MppSel6|{ 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 
0x0, 0x0, 0x0 }
+
+  # ComPhy
+  gMarvellTokenSpaceGuid.PcdComPhyDevices|{ 0x1, 0x1 }
+  # ComPhy1
+  # 0: PCIE0 5 Gbps
+  # 1: PCIE0 5 Gbps
+  # 2: UNCONNECTED
+  # 3: USB3_HOST15 Gbps
+  # 4: SFI   10.31 Gbps
+  # 5: SATA1 5 Gbps
+  gMarvellTokenSpaceGuid.PcdChip1ComPhyTypes|{ $(CP_PCIE0), $(CP_PCIE0), 
$(CP_UNCONNECTED), $(CP_USB3_HOST1), $(CP_SFI), $(CP_SATA1)}
+  gMarvellTokenSpaceGuid.PcdChip1ComPhySpeeds|{ $(CP_5G), $(CP_5G), 
$(CP_DEFAULT), $(CP_5G), $(CP_10_3125G), $(CP_5G) }
+
+  # UtmiPhy
+  gMarvellTokenSpaceGuid.PcdUtmiControllersEnabled|{ 0x1, 0x1, 0x0, 0x1 }
+  gMarvellTokenSpaceGuid.PcdUtmiPortType|{ $(UTMI_USB_HOST0), 
$(UTMI_USB_HOST1), $(UTMI_USB_HOST0), $(UTMI_USB_HOST1) }
+
+  # MDIO
+  gMarvellTokenSpaceGuid.PcdMdioControllersEnabled|{ 0x1, 0x0 }
+
+  # PHY
+  gMarvellTokenSpaceGuid.PcdPhy2MdioController|{ 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPhyDeviceIds|{ 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPhySmiAddresses|{ 0x0, 0x1 }
+  gMarvellTokenSpaceGuid.PcdPhyStartupAutoneg|FALSE
+
+  # NET
+  gMarvellTokenSpaceGuid.PcdPp2GopIndexes|{ 0x0, 0x2, 0x3, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPp2InterfaceAlwaysUp|{ 0x0, 0x0, 0x0, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPp2InterfaceSpeed|{ $(PHY_SPEED_1), 
$(PHY_SPEED_1000), $(PHY_SPEED_1000), $(PHY_SPEED_1) }
+  gMarvellTokenSpaceGuid.PcdPp2PhyConnectionTypes|{ $(PHY_SFI), $(PHY_RGMII), 
$(PHY_RGMII), $(PHY_SFI) }
+  gMarvellTokenSpaceGuid.PcdPp2PhyIndexes|{ 0xFF, 0x0, 0x1, 0xFF }
+  gMarvellTokenSpaceGuid.PcdPp2Port2Controller|{ 0x0, 0x0, 0x0, 0x1 }
+  gMarvellTokenSpaceGuid.PcdPp2PortIds|{ 0x0, 0x1, 0x2, 0x0 }
+  gMarvellTokenSpaceGuid.PcdPp2Controllers|{ 0x1, 0x1 }
+
+  # NonDiscoverableDevices
+  gMarvellTokenSpaceGuid.PcdPciEXhci|{ 0x1, 0x1, 0x0, 0x1 }
+  gMarvellTokenSpaceGuid.PcdPciEAhci|{ 0x1, 0x1 }
+  gMarvellTokenSpaceGuid.PcdPciESdhci|{ 0x1, 0x1 }
diff --git a/Platform/Marvell/Cn913xDb/Cn913xDbA.dsc 
b/Platform/Marvell/Cn913xDb/Cn913xDbA.dsc
index fc1190d..70f99cf 100644
--- a/Platform/Marvell/Cn913xDb/Cn913xDbA.dsc
+++ b/Platform/Marvell/Cn913xDb/Cn913xDbA.dsc
@@ -15,6 +15,8 @@
 [Defines]
 !if $(CN9130)
   PLATFORM_NAME  = Cn9130DbA
+!elseif $(CN9131)
+  PLATFORM_NAME  =

[edk2-devel] [edk2-platforms: PATCH v3 4/9] Marvell/Library: ArmadaSoCDescLib/MppLib: Extend Xenon information

2019-10-09 Thread Marcin Wojtas

Hitherto SoC description and MppLib libraries code assumed
that there could be only two Xenon SdMmc controller
instances in the SoC. Remove those limitations, so that
to support CN913x SoCs, which may have up to 4 of such interfaces.

Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h 
|  5 +--
 Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c 
| 34 +---
 Silicon/Marvell/Library/MppLib/MppLib.c
|  4 +--
 3 files changed, 26 insertions(+), 17 deletions(-)

diff --git 
a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
 
b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
index 0296d43..265b4f4 100644
--- 
a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
+++ 
b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
@@ -90,8 +90,9 @@
 //
 // Platform description of SDMMC controllers
 //
-#define MV_SOC_MAX_SDMMC_COUNT   2
-#define MV_SOC_SDMMC_BASE(Index) ((Index) == 0 ? 0xF06E : 
0xF278)
+#define MV_SOC_SDMMC_PER_CP_COUNT1
+#define MV_SOC_AP80X_SDMMC_BASE  0xF06E
+#define MV_SOC_CP_SDMMC_BASE(Cp) (MV_SOC_CP_BASE (Cp) + 0x78)
 
 //
 // Platform description of UTMI PHY's
diff --git 
a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
 
b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
index 5947601..3ffd57e 100644
--- 
a/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
+++ 
b/Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
@@ -349,26 +349,36 @@ EFI_STATUS
 EFIAPI
 ArmadaSoCDescSdMmcGet (
   IN OUT MV_SOC_SDMMC_DESC  **SdMmcDesc,
-  IN OUT UINTN   *DescCount
+  IN OUT UINTN   *Count
   )
 {
-  MV_SOC_SDMMC_DESC *Desc;
-  UINTN Index;
+  MV_SOC_SDMMC_DESC *SdMmc;
+  UINTN CpCount, CpIndex;
 
-  Desc = AllocateZeroPool (MV_SOC_MAX_SDMMC_COUNT * sizeof 
(MV_SOC_SDMMC_DESC));
-  if (Desc == NULL) {
+  CpCount = FixedPcdGet8 (PcdMaxCpCount);
+
+  *Count = CpCount * MV_SOC_SDMMC_PER_CP_COUNT + MV_SOC_AP806_COUNT;
+  SdMmc = AllocateZeroPool (*Count * sizeof (MV_SOC_SDMMC_DESC));
+  if (SdMmc == NULL) {
 DEBUG ((DEBUG_ERROR, "%a: Cannot allocate memory\n", __FUNCTION__));
 return EFI_OUT_OF_RESOURCES;
   }
 
-  for (Index = 0; Index < MV_SOC_MAX_SDMMC_COUNT; Index++) {
-Desc[Index].SdMmcBaseAddress = MV_SOC_SDMMC_BASE (Index);
-Desc[Index].SdMmcMemSize = SIZE_1KB;
-Desc[Index].SdMmcDmaType = NonDiscoverableDeviceDmaTypeCoherent;
-  }
+  *SdMmcDesc = SdMmc;
+
+  /* AP80x controller */
+  SdMmc->SdMmcBaseAddress = MV_SOC_AP80X_SDMMC_BASE;
+  SdMmc->SdMmcMemSize = SIZE_1KB;
+  SdMmc->SdMmcDmaType = NonDiscoverableDeviceDmaTypeCoherent;
+  SdMmc++;
 
-  *SdMmcDesc = Desc;
-  *DescCount = MV_SOC_MAX_SDMMC_COUNT;
+  /* CP11x controllers */
+  for (CpIndex = 0; CpIndex < CpCount; CpIndex++) {
+SdMmc->SdMmcBaseAddress = MV_SOC_CP_SDMMC_BASE (CpIndex);
+SdMmc->SdMmcMemSize = SIZE_1KB;
+SdMmc->SdMmcDmaType = NonDiscoverableDeviceDmaTypeCoherent;
+SdMmc++;
+  }
 
   return EFI_SUCCESS;
 }
diff --git a/Silicon/Marvell/Library/MppLib/MppLib.c 
b/Silicon/Marvell/Library/MppLib/MppLib.c
index 40d9077..f20668d 100644
--- a/Silicon/Marvell/Library/MppLib/MppLib.c
+++ b/Silicon/Marvell/Library/MppLib/MppLib.c
@@ -139,11 +139,9 @@ SetSdMmcPhyMpp (
   case 0:
 Offset = SD_MMC_PHY_AP_MPP_OFFSET;
 break;
-  case 1:
+  default:
 Offset = SD_MMC_PHY_CP0_MPP_OFFSET;
 break;
-  default:
-return;
   }
 
   /*
-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48698): https://edk2.groups.io/g/devel/message/48698
Mute This Topic: https://groups.io/mt/34471900/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-platforms: PATCH v3 2/9] Marvell/Cn9130Db: Add ACPI tables

2019-10-09 Thread Marcin Wojtas

This patch adds ACPI tables and necessary headers,
which are common for Cn913x SoCs and the CN9130 development board
(variant A). Wiring up of support will be done in the follow-up
commits.

Signed-off-by: Marcin Wojtas 
Acked-by: Leif Lindholm 
---
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9130DbA.inf   |  56 
 Silicon/Marvell/OcteonTx/AcpiTables/T91/AcpiHeader.h|  37 +++
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Pcie.h|  20 ++
 Silicon/Marvell/OcteonTx/AcpiTables/T91/IcuInterrupts.h |  36 +++
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Dsdt.asl  | 324 

 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Mcfg.aslc |  41 +++
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Fadt.aslc   |  80 +
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Gtdt.aslc   |  58 
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Madt.aslc   | 135 
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Pptt.aslc   | 210 +
 Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc   |  49 +++
 11 files changed, 1046 insertions(+)
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9130DbA.inf
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/AcpiHeader.h
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Pcie.h
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/IcuInterrupts.h
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Dsdt.asl
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn913xDbA/Mcfg.aslc
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Fadt.aslc
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Gtdt.aslc
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Madt.aslc
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Pptt.aslc
 create mode 100644 Silicon/Marvell/OcteonTx/AcpiTables/T91/Spcr.aslc

diff --git a/Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9130DbA.inf 
b/Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9130DbA.inf
new file mode 100644
index 000..191a747
--- /dev/null
+++ b/Silicon/Marvell/OcteonTx/AcpiTables/T91/Cn9130DbA.inf
@@ -0,0 +1,56 @@
+## @file
+#  Component description file for PlatformAcpiTables module.
+#
+#  ACPI table data and ASL sources required to boot the platform.
+#
+#  Copyright (c) 2018, Linaro, Ltd. All rights reserved.
+#  Copyright (C) 2019, Marvell International Ltd. and its affiliates.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x0001001B
+  BASE_NAME  = PlatformAcpiTables
+  FILE_GUID  = 7E374E25-8E01-4FEE-87F2-390C23C606CD
+  MODULE_TYPE= USER_DEFINED
+  VERSION_STRING = 1.0
+
+[Sources]
+  Cn913xDbA/Dsdt.asl
+  Cn913xDbA/Mcfg.aslc
+  Fadt.aslc
+  Gtdt.aslc
+  Madt.aslc
+  Pptt.aslc
+  Spcr.aslc
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  ArmPlatformPkg/ArmPlatformPkg.dec
+  EmbeddedPkg/EmbeddedPkg.dec
+  MdeModulePkg/MdeModulePkg.dec
+  MdePkg/MdePkg.dec
+  Silicon/Marvell/Marvell.dec
+
+[FixedPcd]
+  gArmPlatformTokenSpaceGuid.PcdCoreCount
+
+  gArmTokenSpaceGuid.PcdArmArchTimerHypIntrNum
+  gArmTokenSpaceGuid.PcdArmArchTimerIntrNum
+  gArmTokenSpaceGuid.PcdArmArchTimerSecIntrNum
+  gArmTokenSpaceGuid.PcdArmArchTimerVirtIntrNum
+
+  gArmTokenSpaceGuid.PcdGenericWatchdogControlBase
+  gArmTokenSpaceGuid.PcdGenericWatchdogEl2IntrNum
+  gArmTokenSpaceGuid.PcdGenericWatchdogRefreshBase
+
+  gArmTokenSpaceGuid.PcdGicDistributorBase
+  gArmTokenSpaceGuid.PcdGicInterruptInterfaceBase
+
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialClockRate
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSerialRegisterBase
+
+[BuildOptions]
+  *_*_*_ASLCC_FLAGS = -DCN9130
diff --git a/Silicon/Marvell/OcteonTx/AcpiTables/T91/AcpiHeader.h 
b/Silicon/Marvell/OcteonTx/AcpiTables/T91/AcpiHeader.h
new file mode 100644
index 000..b5fd397
--- /dev/null
+++ b/Silicon/Marvell/OcteonTx/AcpiTables/T91/AcpiHeader.h
@@ -0,0 +1,37 @@
+/** @file
+
+  Multiple APIC Description Table (MADT)
+
+  Copyright (c) 2017, Linaro Ltd. All rights reserved.
+  Copyright (C) 2019, Marvell International Ltd. and its affiliates.
+
+  SPDX-License-Identifier: BSD-2-Clause-Patent
+
+**/
+
+#include 
+
+#define ACPI_OEM_ID_ARRAY{'M','V','E','B','U',' '}
+#define ACPI_OEM_REVISION0
+#define ACPI_CREATOR_ID  SIGNATURE_32('L','N','R','O')
+#define ACPI_CREATOR_REVISION0
+
+#if defined(CN9130)
+#define ACPI_OEM_TABLE_IDSIGNATURE_64('C','N','9','1','3','0',' ',' ')
+#endif
+
+/**
+ * A macro to initialize the common header part of EFI ACPI tables
+ * as defined by EFI_ACPI_DESCRIPTION_HEADER structure.
+ **/
+#define __ACPI_HEADER(sign, type, rev) {\
+  sign,   /* UINT32  Signature */   \
+  sizeof (type),  /* UINT32  Length */  \
+  rev,/* UINT8   Revision */\
+  0,  /* UINT8   Checksum

[edk2-devel] [edk2-non-osi: PATCH 2/3] Marvell/Cn9131Db: Add DeviceTree

2019-10-09 Thread Marcin Wojtas

This patch adjusts the top device tree for the CN9131 development board
(variant A), based on the sources which are common for the Cn913x SoCs.
Also an .inf file is added to allow its compilation.

Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9131DbA.inf  | 22 +
 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db.dtsi | 26 
+++-
 2 files changed, 36 insertions(+), 12 deletions(-)
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9131DbA.inf

diff --git a/Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9131DbA.inf 
b/Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9131DbA.inf
new file mode 100644
index 000..8108197
--- /dev/null
+++ b/Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9131DbA.inf
@@ -0,0 +1,22 @@
+## @file
+#
+#  Device tree description of the Marvell CN9130-DB-A platform
+#
+#  Copyright (c) 2019, Marvell International Ltd. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x0001001B
+  BASE_NAME  = Cn9131DbADeviceTree
+  FILE_GUID  = 25462CDA-221F-47DF-AC1D-259CFAA4E326 # 
gDtPlatformDefaultDtbFileGuid
+  MODULE_TYPE= USER_DEFINED
+  VERSION_STRING = 1.0
+
+[Sources]
+  cn9131-db-A.dts
+
+[Packages]
+  MdePkg/MdePkg.dec
diff --git a/Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db.dtsi 
b/Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db.dtsi
index c8e425a..9c9dfb6 100644
--- a/Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db.dtsi
+++ b/Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9131-db.dtsi
@@ -6,15 +6,23 @@
  */
 
 #undef CP110_NUM
-#undef CP110_PCIE_MEM_SIZE
+#undef CP110_NAME
+#undef CP110_BASE
+#undef CP110_PCIE0_BASE
+#undef CP110_PCIE1_BASE
+#undef CP110_PCIE2_BASE
 #undef CP110_PCIEx_CPU_MEM_BASE
-#undef CP110_PCIEx_BUS_MEM_BASE
+#undef CP110_PCIEx_MEM_BASE
 
 /* CP110-1 Settings */
+#define CP110_NAME   cp1
 #define CP110_NUM1
-#define CP110_PCIE_MEM_SIZE(iface)(0xf0)
-#define CP110_PCIEx_CPU_MEM_BASE(iface)(0xe200 + (iface) * 
0x100)
-#define CP110_PCIEx_BUS_MEM_BASE(iface)
(CP110_PCIEx_CPU_MEM_BASE(iface))
+#define CP110_BASE   f400
+#define CP110_PCIE0_BASE f460
+#define CP110_PCIE1_BASE f462
+#define CP110_PCIE2_BASE f464
+#define CP110_PCIEx_CPU_MEM_BASE(iface)  (0xe200 + (iface) * 0x100)
+#define CP110_PCIEx_MEM_BASE(iface)  (CP110_PCIEx_CPU_MEM_BASE(iface))
 
 #include "armada-cp110.dtsi"
 
@@ -93,12 +101,6 @@
 
 _sata0 {
 status = "okay";
-/* CON32 */
-sata-port@1 {
-status = "okay";
-/* Generic PHY, providing serdes lanes */
-phys = <_comphy5 1>;
-};
 };
 
 /* U24 */
@@ -138,7 +140,7 @@
 
 _syscon0 {
 cp1_pinctrl: pinctrl {
-compatible = "marvell,cp115-standalone-pinctrl";
+compatible = "marvell,armada-7k-pinctrl";
 
 cp1_i2c0_pins: cp1-i2c-pins-0 {
 marvell,pins = "mpp37", "mpp38";
-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48691): https://edk2.groups.io/g/devel/message/48691
Mute This Topic: https://groups.io/mt/34471893/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-non-osi: PATCH 3/3] Marvell/Cn9132Db: Add DeviceTree

2019-10-09 Thread Marcin Wojtas

This patch adjusts the top device tree for the CN9132 development board
(variant A), based on the sources which are common for the Cn913x SoCs.
Also an .inf file is added to allow its compilation.

Signed-off-by: Marcin Wojtas 
---
 Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9132DbA.inf   | 22 

 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db-A.dts |  6 --
 Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db.dtsi  | 20 --
 3 files changed, 36 insertions(+), 12 deletions(-)
 create mode 100644 Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9132DbA.inf

diff --git a/Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9132DbA.inf 
b/Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9132DbA.inf
new file mode 100644
index 000..c9e3b04
--- /dev/null
+++ b/Silicon/Marvell/OcteonTx/DeviceTree/T91/Cn9132DbA.inf
@@ -0,0 +1,22 @@
+## @file
+#
+#  Device tree description of the Marvell CN9130-DB-A platform
+#
+#  Copyright (c) 2019, Marvell International Ltd. All rights reserved.
+#
+#  SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+##
+
+[Defines]
+  INF_VERSION= 0x0001001B
+  BASE_NAME  = Cn9132DbADeviceTree
+  FILE_GUID  = 25462CDA-221F-47DF-AC1D-259CFAA4E326 # 
gDtPlatformDefaultDtbFileGuid
+  MODULE_TYPE= USER_DEFINED
+  VERSION_STRING = 1.0
+
+[Sources]
+  cn9132-db-A.dts
+
+[Packages]
+  MdePkg/MdePkg.dec
diff --git a/Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db-A.dts 
b/Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db-A.dts
index e9464f8..724d7dc 100644
--- a/Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db-A.dts
+++ b/Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db-A.dts
@@ -55,12 +55,6 @@
 
 _sata0 {
 status = "okay";
-/* SLM-1521-V2, CON4 */
-sata-port@0 {
-status = "okay";
-/* Generic PHY, providing serdes lanes */
-phys = <_comphy2 0>;
-};
 };
 
 /* CON 2 on SLM-1683 - microSD */
diff --git a/Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db.dtsi 
b/Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db.dtsi
index 8613607..7dc6c6e 100644
--- a/Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db.dtsi
+++ b/Silicon/Marvell/OcteonTx/DeviceTree/T91/cn9132-db.dtsi
@@ -6,15 +6,23 @@
  */
 
 #undef CP110_NUM
-#undef CP110_PCIE_MEM_SIZE
+#undef CP110_NAME
+#undef CP110_BASE
+#undef CP110_PCIE0_BASE
+#undef CP110_PCIE1_BASE
+#undef CP110_PCIE2_BASE
 #undef CP110_PCIEx_CPU_MEM_BASE
-#undef CP110_PCIEx_BUS_MEM_BASE
+#undef CP110_PCIEx_MEM_BASE
 
 /* CP110-1 Settings */
+#define CP110_NAME   cp2
 #define CP110_NUM2
-#define CP110_PCIE_MEM_SIZE(iface)(0xf0)
-#define CP110_PCIEx_CPU_MEM_BASE(iface)(0xe500 + (iface) * 
0x100)
-#define CP110_PCIEx_BUS_MEM_BASE(iface)
(CP110_PCIEx_CPU_MEM_BASE(iface))
+#define CP110_BASE   f600
+#define CP110_PCIE0_BASE f660
+#define CP110_PCIE1_BASE f662
+#define CP110_PCIE2_BASE f664
+#define CP110_PCIEx_CPU_MEM_BASE(iface)  (0xe500 + (iface) * 0x100)
+#define CP110_PCIEx_MEM_BASE(iface)  (CP110_PCIEx_CPU_MEM_BASE(iface))
 
 #include "armada-cp110.dtsi"
 
@@ -124,7 +132,7 @@
 
 _syscon0 {
 cp2_pinctrl: pinctrl {
-compatible = "marvell,cp115-standalone-pinctrl";
+compatible = "marvell,armada-7k-pinctrl";
 
 cp2_i2c0_pins: cp2-i2c-pins-0 {
 marvell,pins = "mpp37", "mpp38";
-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48693): https://edk2.groups.io/g/devel/message/48693
Mute This Topic: https://groups.io/mt/34471895/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH V2 1/3] IntelSiliconPkg/FirmwareBootMediaLib: Add library

2019-10-09 Thread Kubacki, Michael A

Replies below.

> -Original Message-
> From: Ni, Ray 
> Sent: Wednesday, October 9, 2019 7:21 PM
> To: Kubacki, Michael A ;
> devel@edk2.groups.io
> Cc: Chaganty, Rangasai V 
> Subject: RE: [edk2-platforms][PATCH V2 1/3]
> IntelSiliconPkg/FirmwareBootMediaLib: Add library
> 
> Comments below.
> 
> > -Original Message-
> > From: Kubacki, Michael A 
> > Sent: Thursday, October 10, 2019 12:34 AM
> > To: Ni, Ray ; devel@edk2.groups.io
> > Cc: Chaganty, Rangasai V 
> > Subject: RE: [edk2-platforms][PATCH V2 1/3]
> > IntelSiliconPkg/FirmwareBootMediaLib: Add library
> >
> > 1. DxeSmmFirmwareBootMediaLib could get the HOB like PEI for every
> > access. I considered this but it seems unnecessary since we have the
> > flexibility for  phase-specific drivers that can have trivial optimizations 
> > like
> this.
> > Checking the HOB on every access would also constrain usage in
> > DXE_SMM_DRIVER and DXE_RUNTIME_DRIVER modules.
> 
> Having single library instance can make platform DSC simpler.
> Because SMM and Runtime drivers are dispatched in BS phase, they can
> cache the boot media type if the usage lasts to post-EndOfDxe or OS
> runtime.
> 

I don't see an issue with phase-specific instances that cleanly comply with
phase restrictions.

In general, PEI drivers cannot write to global variables. This change does
cache the value in BS phase so it is available in OS runtime.

 * PEI: Do not write to a global variable. Use the heap to store the value via
the HOB list. Always get the value from the HOB.
 * DXE: Get the value from the HOB and store the value in a global variable
during the library constructor in the BS phase so the value is available during
later phase transition.

What exactly are you proposing to change?

> >
> > 2. They are certainly not required, but in practice we've found code
> > usage tends to read better and be more concise with these APIs for
> > simple firmware boot media checks. The enum is provided for relatively
> > rarer scenarios where many possibilities need to be considered such as
> > usage in a switch statement. I can see a case made in either
> > direction. Let me know if you and Sai feel strongly about this.
> 
> I prefer to use enum and GetType() API. Because if there is more boot media
> type, there is no need to add a new library API like IsXXX().
> Not sure if it's over design, I prefer to use GUID against enum. No strong
> preference of using GUID in this case.
> 

My preference is that the API is well-defined and stable. In this case, my 
primary
thought  on the matter is not having two ways to do the same thing. And again,
I have no strong preference for either case but we do have Intel code that 
favors
the IsXXX () usage. I don't think adding new devices (extending the API) is so 
much an
issue as ensuring the existing ones are not modified. Which would be the case 
for
the enum members and the functions. In conclusion, I will send a patch to remove
the IsXXX () functions.

Before adding GUIDs, the problem statement needs to be clearly articulated
that justifies introducing GUID management.

> Thanks,
> Ray
> 
> >
> > Thanks,
> > Michael
> >
> > > -Original Message-
> > > From: Ni, Ray 
> > > Sent: Wednesday, October 9, 2019 2:36 AM
> > > To: Kubacki, Michael A ;
> > > devel@edk2.groups.io
> > > Cc: Chaganty, Rangasai V 
> > > Subject: RE: [edk2-platforms][PATCH V2 1/3]
> > > IntelSiliconPkg/FirmwareBootMediaLib: Add library
> > >
> > > Michael,
> > > Two comments:
> > > 1. The difference between PEI and DXE instances is DXE instance has
> > > a global variable caching the boot media type. Both get the type
> > > from HOB. So I am thinking how about simplifying the library to have
> > > only one instance which equals to PEI instance. That can also be
> > > used in DXE
> > phase.
> > > 2. With the definition of enum type FW_BOOT_MEDIA_TYPE and
> GetType()
> > > API, I feel the other several FirmwareBootMediaIsXXX() APIs are not
> > > very necessary.
> > >
> > > Thanks,
> > > Ray
> > >
> > > > -Original Message-
> > > > From: Kubacki, Michael A 
> > > > Sent: Saturday, October 5, 2019 1:29 AM
> > > > To: devel@edk2.groups.io
> > > > Cc: Chaganty, Rangasai V ; Ni, Ray
> > > > 
> > > > Subject: [edk2-platforms][PATCH V2 1/3]
> > > > IntelSiliconPkg/FirmwareBootMediaLib: Add library
> > > >
> > > > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2229
> > > >
> > > > Adds a new library that is used to make system initialization
> > > > decisions in the boot flow dependent upon firmware boot media.
> > > > Note that the firmware boot media is the storage media that the
> > > > boot firmware is stored on. It is not the OS storage media which
> > > > may be stored upon a different non-volatile storage device.
> > > >
> > > > Any Intel board, platform, or silicon code that must take action
> > > > conditionally based on the firmware boot media must use this
> > > > library API.
> > > >
> > > > Cc: Sai Chaganty 
> > > > Cc: Ray Ni 
> > > >

Re: [edk2-devel] [PATCH v1 1/1] NetworkPkg/SnpDxe: Remove ExitBootServices event

2019-10-09 Thread Siyuan, Fu

Hi, Maciej

Considering that this patch has to co-work with corresponding UNDI device driver
bug fix, in order to avoid potential compatibility problem, please add a PCD to 
NetworkPkg for this fix, and set the default value to disable state (no behavior
 change). The platform which need this fix could set the PCD to enable in its 
platform DSC.

Please add clear description for the problem, new PCD, the SNP fix, and also the
 expected UNDI driver fix in Bugzilla 1974. So 3rd party UNDI device vendor 
could
 know how to fix the problem if they meet same issue.

And please correct the Bugzilla number in patch description as Laszlo pointed 
out.

Thanks.

Best Regards
Siyuan 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Laszlo
> Ersek
> Sent: 2019年10月10日 6:10
> To: devel@edk2.groups.io; Rabeda, Maciej 
> Cc: Fu, Siyuan ; Wu, Jiaxin 
> Subject: Re: [edk2-devel] [PATCH v1 1/1] NetworkPkg/SnpDxe: Remove
> ExitBootServices event
> 
> On 10/08/19 18:16, Rabeda, Maciej wrote:
> > Patch addresses Bugzilla #1972.
> 
> I think the BZ reference should be
> . (The cover letter
> has it right.)
> 
> Thanks
> Laszlo
> 
> > During ExitBootServices stage, drivers should not call any
> > functions known to use Memory Allocation Services. One of such
> > functions (as per UEFI spec) is UNDI->Shutdown().
> >
> > Since UNDI drivers during ExitBootServices phase are expected
> > to put the adapter to such a state that it will not perform any DMA
> > operations, there is no need to interface UNDI by SNP driver during
> > that phase.
> >
> > Finally, since ExitBootServices event notification function in SNP
> > only calls UNDI->Shutdown() and Stop() functions, there is no need
> > to create this event at all.
> >
> > Signed-off-by: Maciej Rabeda 
> > Cc: Siyuan Fu 
> > Cc: Jiaxin Wu 
> > ---
> >  NetworkPkg/SnpDxe/Snp.c  | 45 
> >  NetworkPkg/SnpDxe/Snp.h  |  2 -
> >  NetworkPkg/SnpDxe/SnpDxe.inf |  3 --
> >  3 files changed, 50 deletions(-)
> >
> > diff --git a/NetworkPkg/SnpDxe/Snp.c b/NetworkPkg/SnpDxe/Snp.c
> > index a23af05078bc..7646a3ce0293 100644
> > --- a/NetworkPkg/SnpDxe/Snp.c
> > +++ b/NetworkPkg/SnpDxe/Snp.c
> > @@ -8,31 +8,6 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >  #include "Snp.h"
> >
> > -/**
> > -  One notified function to stop UNDI device when gBS->ExitBootServices()
> called.
> > -
> > -  @param  Event   Pointer to this event
> > -  @param  Context Event handler private data
> > -
> > -**/
> > -VOID
> > -EFIAPI
> > -SnpNotifyExitBootServices (
> > -  EFI_EVENT Event,
> > -  VOID  *Context
> > -  )
> > -{
> > -  SNP_DRIVER *Snp;
> > -
> > -  Snp  = (SNP_DRIVER *)Context;
> > -
> > -  //
> > -  // Shutdown and stop UNDI driver
> > -  //
> > -  PxeShutdown (Snp);
> > -  PxeStop (Snp);
> > -}
> > -
> >  /**
> >Send command to UNDI. It does nothing currently.
> >
> > @@ -647,21 +622,6 @@ SimpleNetworkDriverStart (
> >PxeShutdown (Snp);
> >PxeStop (Snp);
> >
> > -  //
> > -  // Create EXIT_BOOT_SERIVES Event
> > -  //
> > -  Status = gBS->CreateEventEx (
> > -  EVT_NOTIFY_SIGNAL,
> > -  TPL_NOTIFY,
> > -  SnpNotifyExitBootServices,
> > -  Snp,
> > -  ,
> > -  >ExitBootServicesEvent
> > -  );
> > -  if (EFI_ERROR (Status)) {
> > -goto Error_DeleteSNP;
> > -  }
> > -
> >//
> >//  add SNP to the undi handle
> >//
> > @@ -778,11 +738,6 @@ SimpleNetworkDriverStop (
> >  return Status;
> >}
> >
> > -  //
> > -  // Close EXIT_BOOT_SERIVES Event
> > -  //
> > -  gBS->CloseEvent (Snp->ExitBootServicesEvent);
> > -
> >Status = gBS->CloseProtocol (
> >Controller,
> >_31,
> > diff --git a/NetworkPkg/SnpDxe/Snp.h b/NetworkPkg/SnpDxe/Snp.h
> > index e6b62930397d..f83a4f075adc 100644
> > --- a/NetworkPkg/SnpDxe/Snp.h
> > +++ b/NetworkPkg/SnpDxe/Snp.h
> > @@ -120,8 +120,6 @@ typedef struct {
> >  VOID  *MapCookie;
> >} MapList[MAX_MAP_LENGTH];
> >
> > -  EFI_EVENT  ExitBootServicesEvent;
> > -
> >//
> >// Whether UNDI support reporting media status from GET_STATUS
> command,
> >// i.e. PXE_STATFLAGS_GET_STATUS_NO_MEDIA_SUPPORTED or
> > diff --git a/NetworkPkg/SnpDxe/SnpDxe.inf
> b/NetworkPkg/SnpDxe/SnpDxe.inf
> > index afeb1526cc10..8d045cfcf4ca 100644
> > --- a/NetworkPkg/SnpDxe/SnpDxe.inf
> > +++ b/NetworkPkg/SnpDxe/SnpDxe.inf
> > @@ -64,9 +64,6 @@
> >DebugLib
> >NetLib
> >
> > -[Guids]
> > -  gEfiEventExitBootServicesGuid ## SOMETIMES_CONSUMES ##
> Event
> > -
> >  [Protocols]
> >gEfiSimpleNetworkProtocolGuid ## BY_START
> >gEfiDevicePathProtocolGuid## TO_START
> >
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this

[edk2-devel] [RFC]Drop EDK Shell (EdkShellPkg) support

2019-10-09 Thread Ni, Ray

All,
Given the fact EdkShellPkg was deleted from edk2 repo one year ago 
(6caf954c1bf9), I propose to drop the support of EDK Shell in ShellPkg.
The EDK Shell support is mainly in ShellPkg/Library/UefiShellLib. The library 
supports to build individual shell apps that can run in both UEFI Shell and EDK 
Shell environment. EDK Shell environment support is what this RFC wants to 
remove.
Besides that, below components can also be removed:
ShellPkg/Include/Guid/ShellEnvironment2Ext.h
ShellPkg/Include/Protocol/

Jaben raised this idea and Laszlo had no concern.

Thanks,
Ray

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48687): https://edk2.groups.io/g/devel/message/48687
Mute This Topic: https://groups.io/mt/34471251/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/4] UefiCpuPkg/MpInitLib: honor the platform's boot CPU count in AP detection

2019-10-09 Thread Ni, Ray

Laszlo,
Can you add comments in the code you changed to describe the two different 
behaviors?

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48685): https://edk2.groups.io/g/devel/message/48685
Mute This Topic: https://groups.io/mt/34441228/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 0/4] Support HTTPS HostName validation feature(CVE-2019-14553)

2019-10-09 Thread Wu, Jiaxin

Hi  Laszlo,

Thanks the comments.

Best Regards!
Jiaxin  

> -Original Message-
> From: Laszlo Ersek 
> Sent: Wednesday, October 9, 2019 11:55 PM
> To: devel@edk2.groups.io; Wang, Jian J ; Wu, Jiaxin
> ; David Woodhouse ; Bret
> Barkelew 
> Subject: Re: [edk2-devel] [PATCH v1 0/4] Support HTTPS HostName
> validation feature(CVE-2019-14553)
> 
> On 10/01/19 01:21, Laszlo Ersek wrote:
> > On 09/29/19 08:09, Wang, Jian J wrote:
> >> For this patch series,
> >> 1. " Contributed-under: TianoCore Contribution Agreement 1.1" is not
> needed any more.
> >>   Remove it at push time and no need to send a v2.
> >> 2. Since it's security patch which had been reviewed separately, I see no
> reason for new r-b
> >>   required. Please raise it asap if any objections.
> >> 3. Acked-by: Jian J Wang 
> >
> >
> > * Can you please confirm that these patches match those that we
> > discussed here:
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=960#c18
> > https://bugzilla.tianocore.org/show_bug.cgi?id=960#c19
> 
> To answer my own question, I've now compared the patches from those BZ
> comments linked above, with the present series. Here's a list of
> differences.
> 
> (1) The subject lines now include the reference "(CVE-2019-14553)".
> 
> This is great, *but* please be sure to insert a space character before
> the opening parenthesis! (In every patch.)
> 
> (2) The commit messages reference both the BZ and the CVE number.
> 
> Good.
> 
> (3) In the commit messages, the line
> 
>   Contributed-under: TianoCore Contribution Agreement 1.0
> 
> has been upgraded to
> 
>   Contributed-under: TianoCore Contribution Agreement 1.1
> 
> I think this is wrong. The lines should have been removed, due to the
> SPDX adoption. Please update all the commit messages.
> 
> (4) Copyright notice updates are gone from the patches.
> 
> That's fine: the reason is that the underlying files have seen their
> copyright notices updated, meanwhile.
> 
> 
> Otherwise, the patches (code, commit messages, and feedback tags) are
> identical.
> 
> Before you push the patches (or post a v2), please fix issues (1) and (3).
> 
> Now, regarding the other set of questions:
> 
> > * In the BZ, David and Bret raised some questions:
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=960#c31
> > https://bugzilla.tianocore.org/show_bug.cgi?id=960#c32
> > https://bugzilla.tianocore.org/show_bug.cgi?id=960#c35
> > https://bugzilla.tianocore.org/show_bug.cgi?id=960#c36
> >
> > and
> >
> > https://bugzilla.tianocore.org/show_bug.cgi?id=960#c40
> >
> > The latest comment in the bug is c#41. I'm not under the impression that
> > all concerns raised by David and Bret have been addressed (or
> > abandoned). I'd like David and Bret to ACK the patches.
> 
> I'll first have to process the new comments down-thread.
> 
> Thanks
> Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48684): https://edk2.groups.io/g/devel/message/48684
Mute This Topic: https://groups.io/mt/34307578/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 0/4] Support HTTPS HostName validation feature(CVE-2019-14553)

2019-10-09 Thread Wu, Jiaxin

> 
> I have not tested this, but I started looking when there was a message
> on the edk2 list from someone who was reporting that it didn't work for
> IPv6 URIs, IIRC.
> 
> You are using SSL_set1_host(), and I believe you're just passing in the
> bare hostname part of the URI, be it "1.2.3.4" or "[2001:8b0:10b::5]".

Here, I want to highlight is that UEFI TLS only provides the *HostName* 
verification interface to upper driver (HttpDxe), not the IP/email verification 
capability. Please refer to UEFI Spec2.8 section 28.10.2: 
"...TLS session hostname for validation which is used to verify whether the 
name within the peer certificate matches a given host name..." 
In upper UEFI HTTP driver, we get the hostname from URI directly no matter it's 
the real FQDN (www.xxx.com) or IP address format string (1.2.3.4 or 
2001:8b0:10b::5 (not "[2001:8b0:10b::5])), and set it to the TLS hostname filed 
via the interface -- EFI_TLS_VERIFY_HOST. That's implementation choice for 
HttpDxe to achieve the HTTPS HostName validation feature by following the 
standard TLS HostName verification capability.
  
> 
> That just adds it to the 'hosts' list in the X509_VERIFY_PARAM for the
> SSL connection.

Yes.

> 
> In the check_hosts() function in openssl/crypto/x509/v509_vfy.c, the
> code simply iterates over the members of that list, calling
> X509_check_host() for each one. It never calls X509_check_ip().

Yes.

> 
> If you look in openssl/crypto/x509/v3_utl.c you can see the
> X509_check_host() really does only check hostnames. 

Yes.

> You'd need to call X509_check_ip_asc() to check hostnames. And something 
> would need to
> have stripped the [] which surround an IPv6 literal.
> 

Disagree, why need check the IP here since we only focus on the hostname 
verification? For HttpDxe driver, it's the implementation choice to treat the 
IP in URI as hostname string format. As I said before in the email, if the CN 
or SAN (Seems only in X509 V3) in the certificate are set correctly, it should 
be OK to pass the verification. Laszlo and I already have verified that.

> I can't see how this can work. Have you tested it since the report on
> the list that it wasn't working?
> 

Sorry, I can't remember there is any failure of Ipv6 URI reported from edk2. If 
you can find it, that will be better.

> cf. https://github.com/openssl/openssl/pull/9201 which is being ignored
> by the OpenSSL developers — OpenSSL really doesn't make life easy for
> you here, which is a shame.
> 
> 
> > For the series patches here, we are intending to support the host
> > name validation, I think we can commit the series patches since we
> > pass the verification of IPV6 URL, what do you think?
> 
> If it passes the verification of IPv6 literals, then all my analysis is
> broken and so was the report on the list that prompted me to start
> looking (or I'm misremembering that report). In that case, sure, go
> ahead and commit.
> 
> > Thanks,
> > Jiaxin


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48683): https://edk2.groups.io/g/devel/message/48683
Mute This Topic: https://groups.io/mt/34307578/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-test][Patch v2] uefi-sct/SctPkg: Sync SNP Statistics change to IHV

2019-10-09 Thread Eric Jin

Reviewed-by: Eric Jin 

> -Original Message-
> From: Liu, XianhuiX 
> Sent: Thursday, October 10, 2019 10:24 AM
> To: devel@edk2.groups.io
> Cc: Heinrich Schuchardt ; Supreeth Venkatesh
> ; Jin, Eric ; Liu,
> XianhuiX 
> Subject: [edk2-test][Patch v2] uefi-sct/SctPkg: Sync SNP Statistics change to
> IHV
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2160
> sync commit 269f8a35e44f2093625b3671f372f68e2983c49d
> on file EFI/Protocol/SimpleNetwork/BlackBoxTest
> /SimpleNetworkBBTestConformance.c to IHV
> 
> Cc: Heinrich Schuchardt 
> Cc: Supreeth Venkatesh 
> Cc: Eric Jin 
> 
> Signed-off-by: xianhui liu 
> ---
>  .../BlackBoxTest/SimpleNetworkBBTestConformance.c  | 125
> -
>  1 file changed, 73 insertions(+), 52 deletions(-)
> 
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/Simpl
> eNetworkBBTestConformance.c b/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/Simpl
> eNetworkBBTestConformance.c
> index 9d5bec18..c758f560 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/Simpl
> eNetworkBBTestConformance.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxT
> +++ est/SimpleNetworkBBTestConformance.c
> @@ -1,7 +1,7 @@
>  /** @file
> 
>Copyright 2006 - 2016 Unified EFI, Inc.
> -  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2010 - 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 @@ -964,8 +964,7 @@ BBTestStatisticsConformanceTest (  {
>EFI_STANDARD_TEST_LIBRARY_PROTOCOL*StandardLib;
>EFI_STATUSStatus;
> -  EFI_STATUSStatusBuf[3];
> -  EFI_TEST_ASSERTIONAssertionType[3];
> +  EFI_TEST_ASSERTIONAssertionType;
>EFI_SIMPLE_NETWORK_PROTOCOL   *SnpInterface;
>EFI_SIMPLE_NETWORK_STATE  State1, State2;
>EFI_NETWORK_STATISTICSStatisticsTable;
> @@ -1012,31 +1011,68 @@ BBTestStatisticsConformanceTest (
>StatisticsSize = sizeof (EFI_NETWORK_STATISTICS);
>//
>// Assertion Point 5.8.2.1
> -  // Call Statistics() function if network interface not start.
> +  // Call Statistics() function while network interface is not started.
>//
> -  StatusBuf[0] = SnpInterface->Statistics (SnpInterface, FALSE, 
> ,
> );
> -  if ((StatusBuf[0] == EFI_NOT_STARTED) && (SnpInterface->Mode->State
> == EfiSimpleNetworkStopped)) {
> -AssertionType[0] = EFI_TEST_ASSERTION_PASSED;
> +  Status = SnpInterface->Statistics (SnpInterface, FALSE,
> + , );  if (Status == EFI_UNSUPPORTED) {
> +StandardLib->RecordMessage(
> +   StandardLib,
> +   EFI_VERBOSE_LEVEL_QUIET,
> +   L"Statistics isn't supported, Status - %r\n",
> +   Status
> +   );
>} else {
> -AssertionType[0] = EFI_TEST_ASSERTION_FAILED;
> +if ((Status == EFI_NOT_STARTED) && (SnpInterface->Mode->State ==
> EfiSimpleNetworkStopped)) {
> +  AssertionType = EFI_TEST_ASSERTION_PASSED;
> +} else {
> +  AssertionType = EFI_TEST_ASSERTION_FAILED;
> +}
> +StandardLib->RecordAssertion (
> +   StandardLib,
> +   AssertionType,
> +   gSimpleNetworkBBTestConformanceAssertionGuid014,
> +   L"EFI_SIMPLE_NETWORK_PROTOCOL.Statistics - Invoke 
> Statistics()
> while network interface not started.",
> +   L"%a:%d:Status - %r",
> +   __FILE__,
> +   (UINTN)__LINE__,
> +   Status
> +   );
>}
> 
>//
>// Assertion Point 5.8.2.2
> -  // Call Statistics() function if network interface not initialized.
> +  // Call Statistics() function while network interface is not initialized.
>//
>Status = SnpInterface->Start (SnpInterface);
>if (EFI_ERROR(Status)) {
>  return Status;
>}
> 
> -  StatusBuf[1] = SnpInterface->Statistics (SnpInterface, FALSE, 
> ,
> );
> -  if (StatusBuf[1] == EFI_DEVICE_ERROR) {
> -AssertionType[1] = EFI_TEST_ASSERTION_PASSED;
> +  Status = SnpInterface->Statistics (SnpInterface, FALSE,
> + , );  if (Status == EFI_UNSUPPORTED) {
> +StandardLib->RecordMessage(
> +   StandardLib,
> +   EFI_VERBOSE_LEVEL_QUIET,
> +   L"Statistics isn't supported, Status - %r\n",
> +   Status
> +   );
>} else {
> -AssertionType[1] = EFI_TEST_ASSERTION_FAILED;
> +if (Status == EFI_DEVICE_ERROR) {
> +  AssertionType = EFI_TEST_ASSERTION_PASSED;
> +} else {
> +  AssertionType = EFI_TEST_ASSERTION_FAILED;
> +}
> +StandardLib->RecordAssertion (
> +   StandardLib,
> +

Re: [edk2-devel] [edk2-test][Patch v2] uefi-sct/SctPkg: Sync SimpleTextInputEx change to IHV

2019-10-09 Thread Eric Jin

Reviewed-by: Eric Jin 

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of xianhui
> liu
> Sent: Thursday, October 10, 2019 10:13 AM
> To: devel@edk2.groups.io
> Cc: Heinrich Schuchardt ; Supreeth Venkatesh
> ; Jin, Eric ; Liu,
> XianhuiX 
> Subject: [edk2-devel] [edk2-test][Patch v2] uefi-sct/SctPkg: Sync
> SimpleTextInputEx change to IHV
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2169
> sync commit fc1a95f7b1a4c157d0536bc159bc5114cdfcb9b4
> on file EFI/Protocol/SimpleTextInputEx/BlackBoxTest
> /SimpleTextInputExBBTestConformance.c to IHV
> 
> Cc: Heinrich Schuchardt 
> Cc: Supreeth Venkatesh 
> Cc: Eric Jin 
> 
> Signed-off-by: xianhui liu 
> ---
>  .../BlackBoxTest/SimpleTextInputExBBTestConformance.c  | 10 ++-
> ---
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/Si
> mpleTextInputExBBTestConformance.c b/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/Si
> mpleTextInputExBBTestConformance.c
> index 3e230f9e..e1797219 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/Si
> mpleTextInputExBBTestConformance.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/Black
> +++ BoxTest/SimpleTextInputExBBTestConformance.c
> @@ -1,7 +1,7 @@
>  /** @file
> 
>Copyright 2006 - 2016 Unified EFI, Inc.
> -  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2010 - 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 @@ -153,7 +153,7 @@ BBTestSetStateConformanceTest (
>  return Status;
>}
>BBTestSetStateConformanceTestCheckpoint2 ( StandardLib,
> SimpleTextInputEx );
> -
> +
>Status = gtBS->FreePool (DevicePathStr);
>if (EFI_ERROR(Status))
>  return Status;
> @@ -483,8 +483,10 @@ BBTestSetStateConformanceTestCheckpoint1 (
>  );
>  }
>}
> -
> -  if ( EFI_INVALID_PARAMETER != Status) {
> +
> +  if (Status == EFI_UNSUPPORTED) {
> +AssertionType = EFI_TEST_ASSERTION_WARNING;  } else if (Status !=
> + EFI_INVALID_PARAMETER) {
>  AssertionType = EFI_TEST_ASSERTION_FAILED;
>} else {
>  AssertionType = EFI_TEST_ASSERTION_PASSED;
> --
> 2.14.1.windows.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48681): https://edk2.groups.io/g/devel/message/48681
Mute This Topic: https://groups.io/mt/34470713/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-test][Patch v2] uefi-sct/SctPkg: Sync SNP Statistics change to IHV

2019-10-09 Thread xianhui liu

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2160
sync commit 269f8a35e44f2093625b3671f372f68e2983c49d
on file EFI/Protocol/SimpleNetwork/BlackBoxTest
/SimpleNetworkBBTestConformance.c to IHV

Cc: Heinrich Schuchardt 
Cc: Supreeth Venkatesh 
Cc: Eric Jin 

Signed-off-by: xianhui liu 
---
 .../BlackBoxTest/SimpleNetworkBBTestConformance.c  | 125 -
 1 file changed, 73 insertions(+), 52 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestConformance.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestConformance.c
index 9d5bec18..c758f560 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestConformance.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestConformance.c
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright 2006 - 2016 Unified EFI, Inc.
-  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 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
@@ -964,8 +964,7 @@ BBTestStatisticsConformanceTest (
 {
   EFI_STANDARD_TEST_LIBRARY_PROTOCOL*StandardLib;
   EFI_STATUSStatus;
-  EFI_STATUSStatusBuf[3];  
-  EFI_TEST_ASSERTIONAssertionType[3];
+  EFI_TEST_ASSERTIONAssertionType;
   EFI_SIMPLE_NETWORK_PROTOCOL   *SnpInterface;
   EFI_SIMPLE_NETWORK_STATE  State1, State2;
   EFI_NETWORK_STATISTICSStatisticsTable;
@@ -1012,31 +1011,68 @@ BBTestStatisticsConformanceTest (
   StatisticsSize = sizeof (EFI_NETWORK_STATISTICS);
   //
   // Assertion Point 5.8.2.1
-  // Call Statistics() function if network interface not start.
+  // Call Statistics() function while network interface is not started.
   //
-  StatusBuf[0] = SnpInterface->Statistics (SnpInterface, FALSE, 
, );
-  if ((StatusBuf[0] == EFI_NOT_STARTED) && (SnpInterface->Mode->State == 
EfiSimpleNetworkStopped)) {
-AssertionType[0] = EFI_TEST_ASSERTION_PASSED;
+  Status = SnpInterface->Statistics (SnpInterface, FALSE, , 
);
+  if (Status == EFI_UNSUPPORTED) {
+StandardLib->RecordMessage(
+   StandardLib,
+   EFI_VERBOSE_LEVEL_QUIET,
+   L"Statistics isn't supported, Status - %r\n",
+   Status
+   );
   } else {
-AssertionType[0] = EFI_TEST_ASSERTION_FAILED;
+if ((Status == EFI_NOT_STARTED) && (SnpInterface->Mode->State == 
EfiSimpleNetworkStopped)) {
+  AssertionType = EFI_TEST_ASSERTION_PASSED;
+} else {
+  AssertionType = EFI_TEST_ASSERTION_FAILED;
+}
+StandardLib->RecordAssertion (
+   StandardLib,
+   AssertionType,
+   gSimpleNetworkBBTestConformanceAssertionGuid014,
+   L"EFI_SIMPLE_NETWORK_PROTOCOL.Statistics - Invoke 
Statistics() while network interface not started.",
+   L"%a:%d:Status - %r",
+   __FILE__,
+   (UINTN)__LINE__,
+   Status
+   );
   }
 
   //
   // Assertion Point 5.8.2.2
-  // Call Statistics() function if network interface not initialized.
+  // Call Statistics() function while network interface is not initialized.
   //
   Status = SnpInterface->Start (SnpInterface);
   if (EFI_ERROR(Status)) {
 return Status;
   }
 
-  StatusBuf[1] = SnpInterface->Statistics (SnpInterface, FALSE, 
, );
-  if (StatusBuf[1] == EFI_DEVICE_ERROR) {
-AssertionType[1] = EFI_TEST_ASSERTION_PASSED;
+  Status = SnpInterface->Statistics (SnpInterface, FALSE, , 
);
+  if (Status == EFI_UNSUPPORTED) {
+StandardLib->RecordMessage(
+   StandardLib,
+   EFI_VERBOSE_LEVEL_QUIET,
+   L"Statistics isn't supported, Status - %r\n",
+   Status
+   );
   } else {
-AssertionType[1] = EFI_TEST_ASSERTION_FAILED;
+if (Status == EFI_DEVICE_ERROR) {
+  AssertionType = EFI_TEST_ASSERTION_PASSED;
+} else {
+  AssertionType = EFI_TEST_ASSERTION_FAILED;
+}
+StandardLib->RecordAssertion (
+   StandardLib,
+   AssertionType,
+   gSimpleNetworkBBTestConformanceAssertionGuid015,
+   L"EFI_SIMPLE_NETWORK_PROTOCOL.Statistics - Invoke 
Statistics() while network interface is not initialized.",
+   L"%a:%d:Status - %r",
+   __FILE__,
+   (UINTN)__LINE__,
+   Status
+   );
   }
- 
 
   //
   // Assertion Point 5.8.2.3
@@ -1053,47 +1089,32 @@ BBTestStatisticsConformanceTest (
   //
   StatisticsSize = 0;
 
-  StatusBuf[2] = SnpInterface->Statistics

Re: [edk2-devel] [edk2-platforms][PATCH V2 1/3] IntelSiliconPkg/FirmwareBootMediaLib: Add library

2019-10-09 Thread Ni, Ray

Comments below.

> -Original Message-
> From: Kubacki, Michael A 
> Sent: Thursday, October 10, 2019 12:34 AM
> To: Ni, Ray ; devel@edk2.groups.io
> Cc: Chaganty, Rangasai V 
> Subject: RE: [edk2-platforms][PATCH V2 1/3]
> IntelSiliconPkg/FirmwareBootMediaLib: Add library
> 
> 1. DxeSmmFirmwareBootMediaLib could get the HOB like PEI for every
> access. I considered this but it seems unnecessary since we have the
> flexibility for  phase-specific drivers that can have trivial optimizations 
> like this.
> Checking the HOB on every access would also constrain usage in
> DXE_SMM_DRIVER and DXE_RUNTIME_DRIVER modules.

Having single library instance can make platform DSC simpler.
Because SMM and Runtime drivers are dispatched in BS phase, they can cache the
boot media type if the usage lasts to post-EndOfDxe or OS runtime.

> 
> 2. They are certainly not required, but in practice we've found code usage
> tends to read better and be more concise with these APIs for simple
> firmware boot media checks. The enum is provided for relatively rarer
> scenarios where many possibilities need to be considered such as usage in a
> switch statement. I can see a case made in either direction. Let me know if
> you and Sai feel strongly about this.

I prefer to use enum and GetType() API. Because if there is more boot media 
type,
there is no need to add a new library API like IsXXX().
Not sure if it's over design, I prefer to use GUID against enum. No strong 
preference
of using GUID in this case.

Thanks,
Ray

> 
> Thanks,
> Michael
> 
> > -Original Message-
> > From: Ni, Ray 
> > Sent: Wednesday, October 9, 2019 2:36 AM
> > To: Kubacki, Michael A ;
> > devel@edk2.groups.io
> > Cc: Chaganty, Rangasai V 
> > Subject: RE: [edk2-platforms][PATCH V2 1/3]
> > IntelSiliconPkg/FirmwareBootMediaLib: Add library
> >
> > Michael,
> > Two comments:
> > 1. The difference between PEI and DXE instances is DXE instance has a
> > global variable caching the boot media type. Both get the type from
> > HOB. So I am thinking how about simplifying the library to have only
> > one instance which equals to PEI instance. That can also be used in DXE
> phase.
> > 2. With the definition of enum type FW_BOOT_MEDIA_TYPE and GetType()
> > API, I feel the other several FirmwareBootMediaIsXXX() APIs are not
> > very necessary.
> >
> > Thanks,
> > Ray
> >
> > > -Original Message-
> > > From: Kubacki, Michael A 
> > > Sent: Saturday, October 5, 2019 1:29 AM
> > > To: devel@edk2.groups.io
> > > Cc: Chaganty, Rangasai V ; Ni, Ray
> > > 
> > > Subject: [edk2-platforms][PATCH V2 1/3]
> > > IntelSiliconPkg/FirmwareBootMediaLib: Add library
> > >
> > > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2229
> > >
> > > Adds a new library that is used to make system initialization
> > > decisions in the boot flow dependent upon firmware boot media.
> > > Note that the firmware boot media is the storage media that the boot
> > > firmware is stored on. It is not the OS storage media which may be
> > > stored upon a different non-volatile storage device.
> > >
> > > Any Intel board, platform, or silicon code that must take action
> > > conditionally based on the firmware boot media must use this library
> > > API.
> > >
> > > Cc: Sai Chaganty 
> > > Cc: Ray Ni 
> > > Signed-off-by: Michael Kubacki 
> > > ---
> > >  Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> > >   |   8
> +-
> > >  Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
> > >   |   4
> +-
> > >
> > >
> >
> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/DxeSmmFirm
> > > wareBootMediaLib.inf |  43 
> > >
> > >
> > Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/PeiFirmwar
> > eB
> > > ootMediaLib.inf|  38 +++
> > >
> > > Silicon/Intel/IntelSiliconPkg/Include/Library/FirmwareBootMediaLib.h
> > > | 106 +++
> > >
> > >
> >
> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/DxeSmmFirm
> > > wareBootMediaLib.c   | 107 +++
> > >
> > >
> > Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/FirmwareBo
> > o
> > > tMediaLib.c | 109 
> > >
> > >
> > Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/PeiFirmwar
> > eB
> > > ootMediaLib.c  |  82 +++
> > >  8 files changed, 495 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> > > b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> > > index fe5bfa0dc6..f70e3b977d 100644
> > > --- a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> > > +++ b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> > > @@ -3,7 +3,7 @@
> > >  #
> > >  # This package provides common open source Intel silicon modules.
> > >  #
> > > -# Copyright (c) 2016 - 2018, Intel Corporation. All rights
> > > reserved.
> > > +# Copyright (c) 2016 - 2019, Intel Corporation. All rights
> > >

[edk2-devel] [edk2-test][Patch v2] uefi-sct/SctPkg: Sync SimpleTextInputEx change to IHV

2019-10-09 Thread xianhui liu

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2169
sync commit fc1a95f7b1a4c157d0536bc159bc5114cdfcb9b4
on file EFI/Protocol/SimpleTextInputEx/BlackBoxTest
/SimpleTextInputExBBTestConformance.c to IHV

Cc: Heinrich Schuchardt 
Cc: Supreeth Venkatesh 
Cc: Eric Jin 

Signed-off-by: xianhui liu 
---
 .../BlackBoxTest/SimpleTextInputExBBTestConformance.c  | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestConformance.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestConformance.c
index 3e230f9e..e1797219 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestConformance.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestConformance.c
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright 2006 - 2016 Unified EFI, Inc.
-  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 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
@@ -153,7 +153,7 @@ BBTestSetStateConformanceTest (
 return Status;
   }
   BBTestSetStateConformanceTestCheckpoint2 ( StandardLib, 
SimpleTextInputEx );
-  
+
   Status = gtBS->FreePool (DevicePathStr);
   if (EFI_ERROR(Status))
 return Status;
@@ -483,8 +483,10 @@ BBTestSetStateConformanceTestCheckpoint1 (
 );
 }
   }
-  
-  if ( EFI_INVALID_PARAMETER != Status) {
+
+  if (Status == EFI_UNSUPPORTED) {
+AssertionType = EFI_TEST_ASSERTION_WARNING;
+  } else if (Status != EFI_INVALID_PARAMETER) {
 AssertionType = EFI_TEST_ASSERTION_FAILED;
   } else {
 AssertionType = EFI_TEST_ASSERTION_PASSED;
-- 
2.14.1.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48678): https://edk2.groups.io/g/devel/message/48678
Mute This Topic: https://groups.io/mt/34470713/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-test][Patch] uefi-sct/SctPkg: Sync SNP Statistics change to IHV

2019-10-09 Thread Eric Jin

Content is good to me.
Please update the copyright with correct year info.

Best Regards
Eric

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of xianhui
> liu
> Sent: Wednesday, October 9, 2019 5:42 PM
> To: devel@edk2.groups.io
> Cc: Heinrich Schuchardt ; Supreeth Venkatesh
> ; Jin, Eric ; Liu,
> XianhuiX 
> Subject: [edk2-devel] [edk2-test][Patch] uefi-sct/SctPkg: Sync SNP Statistics
> change to IHV
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2160
> sync commit 269f8a35e44f2093625b3671f372f68e2983c49d
> on file EFI/Protocol/SimpleNetwork/BlackBoxTest
> /SimpleNetworkBBTestConformance.c to IHV
> 
> Cc: Heinrich Schuchardt 
> Cc: Supreeth Venkatesh 
> Cc: Eric Jin 
> 
> Signed-off-by: xianhui liu 
> ---
>  .../BlackBoxTest/SimpleNetworkBBTestConformance.c  | 123
> -
>  1 file changed, 72 insertions(+), 51 deletions(-)
> 
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/Simpl
> eNetworkBBTestConformance.c b/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/Simpl
> eNetworkBBTestConformance.c
> index 9d5bec18..9bd21a76 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/Simpl
> eNetworkBBTestConformance.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxT
> +++ est/SimpleNetworkBBTestConformance.c
> @@ -964,8 +964,7 @@ BBTestStatisticsConformanceTest (  {
>EFI_STANDARD_TEST_LIBRARY_PROTOCOL*StandardLib;
>EFI_STATUSStatus;
> -  EFI_STATUSStatusBuf[3];
> -  EFI_TEST_ASSERTIONAssertionType[3];
> +  EFI_TEST_ASSERTIONAssertionType;
>EFI_SIMPLE_NETWORK_PROTOCOL   *SnpInterface;
>EFI_SIMPLE_NETWORK_STATE  State1, State2;
>EFI_NETWORK_STATISTICSStatisticsTable;
> @@ -1012,31 +1011,68 @@ BBTestStatisticsConformanceTest (
>StatisticsSize = sizeof (EFI_NETWORK_STATISTICS);
>//
>// Assertion Point 5.8.2.1
> -  // Call Statistics() function if network interface not start.
> +  // Call Statistics() function while network interface is not started.
>//
> -  StatusBuf[0] = SnpInterface->Statistics (SnpInterface, FALSE, 
> ,
> );
> -  if ((StatusBuf[0] == EFI_NOT_STARTED) && (SnpInterface->Mode->State
> == EfiSimpleNetworkStopped)) {
> -AssertionType[0] = EFI_TEST_ASSERTION_PASSED;
> +  Status = SnpInterface->Statistics (SnpInterface, FALSE,
> + , );  if (Status == EFI_UNSUPPORTED) {
> +StandardLib->RecordMessage(
> +   StandardLib,
> +   EFI_VERBOSE_LEVEL_QUIET,
> +   L"Statistics isn't supported, Status - %r\n",
> +   Status
> +   );
>} else {
> -AssertionType[0] = EFI_TEST_ASSERTION_FAILED;
> +if ((Status == EFI_NOT_STARTED) && (SnpInterface->Mode->State ==
> EfiSimpleNetworkStopped)) {
> +  AssertionType = EFI_TEST_ASSERTION_PASSED;
> +} else {
> +  AssertionType = EFI_TEST_ASSERTION_FAILED;
> +}
> +StandardLib->RecordAssertion (
> +   StandardLib,
> +   AssertionType,
> +   gSimpleNetworkBBTestConformanceAssertionGuid014,
> +   L"EFI_SIMPLE_NETWORK_PROTOCOL.Statistics - Invoke 
> Statistics()
> while network interface not started.",
> +   L"%a:%d:Status - %r",
> +   __FILE__,
> +   (UINTN)__LINE__,
> +   Status
> +   );
>}
> 
>//
>// Assertion Point 5.8.2.2
> -  // Call Statistics() function if network interface not initialized.
> +  // Call Statistics() function while network interface is not initialized.
>//
>Status = SnpInterface->Start (SnpInterface);
>if (EFI_ERROR(Status)) {
>  return Status;
>}
> 
> -  StatusBuf[1] = SnpInterface->Statistics (SnpInterface, FALSE, 
> ,
> );
> -  if (StatusBuf[1] == EFI_DEVICE_ERROR) {
> -AssertionType[1] = EFI_TEST_ASSERTION_PASSED;
> +  Status = SnpInterface->Statistics (SnpInterface, FALSE,
> + , );  if (Status == EFI_UNSUPPORTED) {
> +StandardLib->RecordMessage(
> +   StandardLib,
> +   EFI_VERBOSE_LEVEL_QUIET,
> +   L"Statistics isn't supported, Status - %r\n",
> +   Status
> +   );
>} else {
> -AssertionType[1] = EFI_TEST_ASSERTION_FAILED;
> +if (Status == EFI_DEVICE_ERROR) {
> +  AssertionType = EFI_TEST_ASSERTION_PASSED;
> +} else {
> +  AssertionType = EFI_TEST_ASSERTION_FAILED;
> +}
> +StandardLib->RecordAssertion (
> +   StandardLib,
> +   AssertionType,
> +   gSimpleNetworkBBTestConformanceAssertionGuid015,
> +   L"EFI_SIMPLE_NETWORK_PROTOCOL.Statistics - Invoke 
> Statistics()
> while network interface is not initialized.",
> +

Re: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Fix Aligned Page Allocation

2019-10-09 Thread Wu, Hao A

> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Thursday, October 10, 2019 9:58 AM
> To: Wu, Hao A; devel@edk2.groups.io; Ni, Ray
> Subject: RE: [PATCH] MdeModulePkg/XhciDxe: Fix Aligned Page Allocation
> 
> Hello Hao,
> 
> I can see that the PEI also has the same issue and take a look at that as well
> but I have no way to verify that as we are not using it. For the change I have
> made in DXE, I have verified it with an alignment of 4K and 64K.


Is it possible for you to verify the PEI case with a test PEI module that
performs read operation to a USB storage device? I think this will trigger
the affecting codes.

In my opinion, it would be better for the fix to be complete.

Best Regards,
Hao Wu


> 
> Thanks
> Ashish
> 
> -Original Message-
> From: Wu, Hao A 
> Sent: Wednesday, October 9, 2019 7:33 PM
> To: Ashish Singhal ; devel@edk2.groups.io; Ni,
> Ray 
> Subject: RE: [PATCH] MdeModulePkg/XhciDxe: Fix Aligned Page Allocation
> 
> > -Original Message-
> > From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> > Sent: Thursday, October 10, 2019 1:02 AM
> > To: devel@edk2.groups.io; Wu, Hao A; Ni, Ray
> > Cc: Ashish Singhal
> > Subject: [PATCH] MdeModulePkg/XhciDxe: Fix Aligned Page Allocation
> >
> > While allocating pages aligned at an alignment higher than 4K,
> > allocate memory taking into consideration the padding required for
> > that alignment. The calls to free pages takes care of this already.
> >
> > Signed-off-by: Ashish Singhal 
> > ---
> >  MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
> > b/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
> > index fd79988..aa69c47 100644
> > --- a/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
> > +++ b/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
> > @@ -656,7 +656,7 @@ UsbHcAllocateAlignedPages (
> >PciIo,
> >AllocateAnyPages,
> >EfiBootServicesData,
> > -  Pages,
> > +  RealPages,
> >,
> >0
> >);
> 
> 
> Hello,
> 
> The change looks good to me.
> 
> Just a couple of things to confirm:
> 
> 1. I think there is a similar case within the XhciPei driver Could you help to
> resolve it as well?
> 
> I think for the PEI counterpart you may need to update both
> UsbHcAllocateAlignedPages() and UsbHcFreeAlignedPages(), since the
> IOMMU helper functions like IoMmuAllocateBuffer() and IoMmuFreeBuffer()
> might not be suitable now. Instead, I think services in the IoMmu PPI can be
> used.
> 
> 2. Could you help to provide the information on what test has been done for
> the proposed patch?
> 
> Thanks in advance.
> 
> Best Regards,
> Hao Wu
> 
> 
> > --
> > 2.7.4
> 
> ---
> This email message is for the sole use of the intended recipient(s) and may
> contain
> confidential information.  Any unauthorized review, use, disclosure or
> distribution
> is prohibited.  If you are not the intended recipient, please contact the
> sender by
> reply email and destroy all copies of the original message.
> ---

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48676): https://edk2.groups.io/g/devel/message/48676
Mute This Topic: https://groups.io/mt/34465466/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-test][Patch] uefi-sct/SctPkg: Sync SimpleTesxtInputEx change to IHV

2019-10-09 Thread Eric Jin

Hi Xianhui,

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of xianhui
> liu
> Sent: Wednesday, October 9, 2019 4:09 PM
> To: devel@edk2.groups.io
> Cc: Heinrich Schuchardt ; Supreeth Venkatesh
> ; Jin, Eric ; Liu,
> XianhuiX 
> Subject: [edk2-devel] [edk2-test][Patch] uefi-sct/SctPkg: Sync
> SimpleTesxtInputEx change to IHV

Typo here: SimpleTesxtInputEx should be SimpleTextInputEx

Best Regards
Eric

> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2169
> sync commit fc1a95f7b1a4c157d0536bc159bc5114cdfcb9b4
> on file EFI/Protocol/SimpleTextInputEx/BlackBoxTest
> /SimpleTextInputExBBTestConformance.c to IHV
> 
> Cc: Heinrich Schuchardt 
> Cc: Supreeth Venkatesh 
> Cc: Eric Jin 
> 
> Signed-off-by: xianhui liu 
> ---
>  .../BlackBoxTest/SimpleTextInputExBBTestConformance.c  | 10 ++-
> ---
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/Si
> mpleTextInputExBBTestConformance.c b/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/Si
> mpleTextInputExBBTestConformance.c
> index 3e230f9e..e1797219 100644
> --- a/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/Si
> mpleTextInputExBBTestConformance.c
> +++ b/uefi-
> sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/Black
> +++ BoxTest/SimpleTextInputExBBTestConformance.c
> @@ -1,7 +1,7 @@
>  /** @file
> 
>Copyright 2006 - 2016 Unified EFI, Inc.
> -  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2010 - 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 @@ -153,7 +153,7 @@ BBTestSetStateConformanceTest (
>  return Status;
>}
>BBTestSetStateConformanceTestCheckpoint2 ( StandardLib,
> SimpleTextInputEx );
> -
> +
>Status = gtBS->FreePool (DevicePathStr);
>if (EFI_ERROR(Status))
>  return Status;
> @@ -483,8 +483,10 @@ BBTestSetStateConformanceTestCheckpoint1 (
>  );
>  }
>}
> -
> -  if ( EFI_INVALID_PARAMETER != Status) {
> +
> +  if (Status == EFI_UNSUPPORTED) {
> +AssertionType = EFI_TEST_ASSERTION_WARNING;  } else if (Status !=
> + EFI_INVALID_PARAMETER) {
>  AssertionType = EFI_TEST_ASSERTION_FAILED;
>} else {
>  AssertionType = EFI_TEST_ASSERTION_PASSED;
> --
> 2.14.1.windows.1
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48675): https://edk2.groups.io/g/devel/message/48675
Mute This Topic: https://groups.io/mt/34460889/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-test][Patch] uefi-sct/SctPkg: Sync StrUpr() test change to IHV

2019-10-09 Thread Eric Jin

Reviewed-by: Eric Jin 

-Original Message-
From: Liu, XianhuiX  
Sent: Wednesday, October 9, 2019 4:11 PM
To: devel@edk2.groups.io
Cc: Heinrich Schuchardt ; Supreeth Venkatesh 
; Jin, Eric ; Liu, XianhuiX 

Subject: [edk2-test][Patch] uefi-sct/SctPkg: Sync StrUpr() test change to IHV

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1911
sync commit cce43fc3ae30d343964fe02f09242ec8604eb44b
on file EFI/Protocol/UnicodeCollation2/BlackBoxTest
/UnicodeCollation2BBTestFunction.c to IHV

Cc: Heinrich Schuchardt 
Cc: Supreeth Venkatesh 
Cc: Eric Jin 

Signed-off-by: xianhui liu 
---
 .../BlackBoxTest/UnicodeCollation2BBTestFunction.c | 218 ++---
 1 file changed, 107 insertions(+), 111 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/UnicodeCollation2/BlackBoxTest/UnicodeCollation2BBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/UnicodeCollation2/BlackBoxTest/UnicodeCollation2BBTestFunction.c
index 7282034d..239be45b 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/UnicodeCollation2/BlackBoxTest/UnicodeCollation2BBTestFunction.c
+++ b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/UnicodeCollation2/Black
+++ BoxTest/UnicodeCollation2BBTestFunction.c
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright 2006 - 2016 Unified EFI, Inc.
-  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 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 @@ -28,6 +28,43 @@ Abstract:
 #include "SctLib.h"
 #include "UnicodeCollation2BBTestMain.h"
 
+STATIC CONST STRICOLL_TEST_DATA_FIELD mStriCollTestData[] ={
+ {
+   L"",
+   L"",
+   STRING_COMPARE_EQUAL
+ },
+ {
+   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5Ax61\x62\x7D\x7E",
+   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6A\x6B\x6C\x6D\x6E\x6F\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7Ax61\x62\x7D\x7E",
+   STRING_COMPARE_EQUAL
+ },
+ {
+   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6A\x6B\x6C\x6D\x6E\x6F\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7Ax61\x62\x7D\x7E",
+   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5Ax61\x62\x7D\x7E",
+   STRING_COMPARE_EQUAL
+ },
+ {
+   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5A\x61\x62\x7D\x7E",
+   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5A\x61\x62\x7D\x7D",
+   STRING_COMPARE_MORE
+ },
+ {
+   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5A\x61\x62\x7D\x7E",
+   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5A\x61\x62\x7D\x7F",
+   STRING_COMPARE_LESS
+ },
+ {
+   L"\x01",
+   L"",
+   STRING_COMPARE_MORE
+ },
+ {
+   L"",
+   L"\x01\x02",
+   STRING_COMPARE_LESS
+ },
+};
 
 /**
  *  Entrypoint for EFI_UNICODE_COLLATOIN2_PROTOCOL.StriColl() Function Test.
@@ -59,45 +96,6 @@ BBTestStriCollFunctionAutoTest (
   //
   // Test Data
   //
-  STRICOLL_TEST_DATA_FIELD TestData[] ={
- {
-   L"",
-   L"",
-   STRING_COMPARE_EQUAL
- },
- {
-   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5Ax61\x62\x7D\x7E",
-   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6A\x6B\x6C\x6D\x6E\x6F\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7Ax61\x62\x7D\x7E",
-   STRING_COMPARE_EQUAL
- },
- {
-   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6A\x6B\x6C\x6D\x6E\x6F\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7Ax61\x62\x7D\x7E",
-   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5Ax61\x62\x7D\x7E",
-   STRING_COMPARE_EQUAL
- },
- {
-   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5A\x61\x62\x7D\x7E",
-   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5A\x61\x62\x7D\x7D",
-   STRING_COMPARE_MORE
- },
- {
-   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5A\x61\x62\x7D\x7E",
-

Re: [edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Fix Aligned Page Allocation

2019-10-09 Thread Wu, Hao A

> -Original Message-
> From: Ashish Singhal [mailto:ashishsin...@nvidia.com]
> Sent: Thursday, October 10, 2019 1:02 AM
> To: devel@edk2.groups.io; Wu, Hao A; Ni, Ray
> Cc: Ashish Singhal
> Subject: [PATCH] MdeModulePkg/XhciDxe: Fix Aligned Page Allocation
> 
> While allocating pages aligned at an alignment higher than
> 4K, allocate memory taking into consideration the padding
> required for that alignment. The calls to free pages takes
> care of this already.
> 
> Signed-off-by: Ashish Singhal 
> ---
>  MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
> b/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
> index fd79988..aa69c47 100644
> --- a/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
> +++ b/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
> @@ -656,7 +656,7 @@ UsbHcAllocateAlignedPages (
>PciIo,
>AllocateAnyPages,
>EfiBootServicesData,
> -  Pages,
> +  RealPages,
>,
>0
>);


Hello,

The change looks good to me.

Just a couple of things to confirm:

1. I think there is a similar case within the XhciPei driver
Could you help to resolve it as well?

I think for the PEI counterpart you may need to update both
UsbHcAllocateAlignedPages() and UsbHcFreeAlignedPages(), since the IOMMU helper
functions like IoMmuAllocateBuffer() and IoMmuFreeBuffer() might not be
suitable now. Instead, I think services in the IoMmu PPI can be used.

2. Could you help to provide the information on what test has been done for the
proposed patch?

Thanks in advance.

Best Regards,
Hao Wu


> --
> 2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48672): https://edk2.groups.io/g/devel/message/48672
Mute This Topic: https://groups.io/mt/34465466/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 1/1] NetworkPkg/SnpDxe: Remove ExitBootServices event

2019-10-09 Thread Laszlo Ersek

On 10/08/19 18:16, Rabeda, Maciej wrote:
> Patch addresses Bugzilla #1972.

I think the BZ reference should be
. (The cover letter
has it right.)

Thanks
Laszlo

> During ExitBootServices stage, drivers should not call any
> functions known to use Memory Allocation Services. One of such
> functions (as per UEFI spec) is UNDI->Shutdown().
> 
> Since UNDI drivers during ExitBootServices phase are expected
> to put the adapter to such a state that it will not perform any DMA
> operations, there is no need to interface UNDI by SNP driver during
> that phase.
> 
> Finally, since ExitBootServices event notification function in SNP
> only calls UNDI->Shutdown() and Stop() functions, there is no need
> to create this event at all.
> 
> Signed-off-by: Maciej Rabeda 
> Cc: Siyuan Fu 
> Cc: Jiaxin Wu 
> ---
>  NetworkPkg/SnpDxe/Snp.c  | 45 
>  NetworkPkg/SnpDxe/Snp.h  |  2 -
>  NetworkPkg/SnpDxe/SnpDxe.inf |  3 --
>  3 files changed, 50 deletions(-)
> 
> diff --git a/NetworkPkg/SnpDxe/Snp.c b/NetworkPkg/SnpDxe/Snp.c
> index a23af05078bc..7646a3ce0293 100644
> --- a/NetworkPkg/SnpDxe/Snp.c
> +++ b/NetworkPkg/SnpDxe/Snp.c
> @@ -8,31 +8,6 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  
>  #include "Snp.h"
>  
> -/**
> -  One notified function to stop UNDI device when gBS->ExitBootServices() 
> called.
> -
> -  @param  Event   Pointer to this event
> -  @param  Context Event handler private data
> -
> -**/
> -VOID
> -EFIAPI
> -SnpNotifyExitBootServices (
> -  EFI_EVENT Event,
> -  VOID  *Context
> -  )
> -{
> -  SNP_DRIVER *Snp;
> -
> -  Snp  = (SNP_DRIVER *)Context;
> -
> -  //
> -  // Shutdown and stop UNDI driver
> -  //
> -  PxeShutdown (Snp);
> -  PxeStop (Snp);
> -}
> -
>  /**
>Send command to UNDI. It does nothing currently.
>  
> @@ -647,21 +622,6 @@ SimpleNetworkDriverStart (
>PxeShutdown (Snp);
>PxeStop (Snp);
>  
> -  //
> -  // Create EXIT_BOOT_SERIVES Event
> -  //
> -  Status = gBS->CreateEventEx (
> -  EVT_NOTIFY_SIGNAL,
> -  TPL_NOTIFY,
> -  SnpNotifyExitBootServices,
> -  Snp,
> -  ,
> -  >ExitBootServicesEvent
> -  );
> -  if (EFI_ERROR (Status)) {
> -goto Error_DeleteSNP;
> -  }
> -
>//
>//  add SNP to the undi handle
>//
> @@ -778,11 +738,6 @@ SimpleNetworkDriverStop (
>  return Status;
>}
>  
> -  //
> -  // Close EXIT_BOOT_SERIVES Event
> -  //
> -  gBS->CloseEvent (Snp->ExitBootServicesEvent);
> -
>Status = gBS->CloseProtocol (
>Controller,
>_31,
> diff --git a/NetworkPkg/SnpDxe/Snp.h b/NetworkPkg/SnpDxe/Snp.h
> index e6b62930397d..f83a4f075adc 100644
> --- a/NetworkPkg/SnpDxe/Snp.h
> +++ b/NetworkPkg/SnpDxe/Snp.h
> @@ -120,8 +120,6 @@ typedef struct {
>  VOID  *MapCookie;
>} MapList[MAX_MAP_LENGTH];
>  
> -  EFI_EVENT  ExitBootServicesEvent;
> -
>//
>// Whether UNDI support reporting media status from GET_STATUS command,
>// i.e. PXE_STATFLAGS_GET_STATUS_NO_MEDIA_SUPPORTED or
> diff --git a/NetworkPkg/SnpDxe/SnpDxe.inf b/NetworkPkg/SnpDxe/SnpDxe.inf
> index afeb1526cc10..8d045cfcf4ca 100644
> --- a/NetworkPkg/SnpDxe/SnpDxe.inf
> +++ b/NetworkPkg/SnpDxe/SnpDxe.inf
> @@ -64,9 +64,6 @@
>DebugLib
>NetLib
>  
> -[Guids]
> -  gEfiEventExitBootServicesGuid ## SOMETIMES_CONSUMES ## 
> Event
> -
>  [Protocols]
>gEfiSimpleNetworkProtocolGuid ## BY_START
>gEfiDevicePathProtocolGuid## TO_START
> 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48671): https://edk2.groups.io/g/devel/message/48671
Mute This Topic: https://groups.io/mt/3145/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 0/4] Support HTTPS HostName validation feature(CVE-2019-14553)

2019-10-09 Thread David Woodhouse

Can you show result of 'openssl x509 -noout -text -in xx.pem' on your certs 
please.

Would like to check if you really have a cert for the hostname string 
"192.168.124.2" or to the IP address. They are different things.


On 9 October 2019 21:24:34 BST, Laszlo Ersek  wrote:
>Hi All,
>
>(multi-hour composition ahead...)
>
>On 10/09/19 09:53, David Woodhouse wrote:
>> On Tue, 2019-10-08 at 06:19 +, Wu, Jiaxin wrote:
>>> Hi David,
>>>
>>> I just realized you have the comments on Bugzilla 960:
>>>
 "...given that testing is failing and code inspection shows it
 would never have been expected to work."
>>>
>>> Do you mean you didn't pass the verification if URLs with IPv6
>>> literals (https://[2001:8b0:10b:1236::1]/)?  Can you also show me
>>> where the code inspection indicated it would never have been
>expected
>>> to work? We do pass the testing for the URLs with IPv6 if the CN or
>>> SAN in certificate has the corresponding IPv6 address (at least
>>> working with openssl 1.1.0).
>>
>> I have not tested this, but I started looking when there was a
>message
>> on the edk2 list from someone who was reporting that it didn't work
>> for IPv6 URIs, IIRC.
>>
>> You are using SSL_set1_host(), and I believe you're just passing in
>> the bare hostname part of the URI, be it "1.2.3.4" or
>> "[2001:8b0:10b::5]".
>>
>> That just adds it to the 'hosts' list in the X509_VERIFY_PARAM for
>the
>> SSL connection.
>>
>> In the check_hosts() function in openssl/crypto/x509/v509_vfy.c, the
>> code simply iterates over the members of that list, calling
>> X509_check_host() for each one. It never calls X509_check_ip().
>>
>> If you look in openssl/crypto/x509/v3_utl.c you can see the
>> X509_check_host() really does only check hostnames. You'd need to
>call
>> X509_check_ip_asc() to check hostnames. And something would need to
>> have stripped the [] which surround an IPv6 literal.
>>
>> I can't see how this can work. Have you tested it since the report on
>> the list that it wasn't working?
>>
>> cf. https://github.com/openssl/openssl/pull/9201 which is being
>> ignored by the OpenSSL developers  OpenSSL really doesn't make
>> life easy for you here, which is a shame.
>>
>>
>>> For the series patches here, we are intending to support the host
>>> name validation, I think we can commit the series patches since we
>>> pass the verification of IPV6 URL, what do you think?
>>
>> If it passes the verification of IPv6 literals, then all my analysis
>> is broken and so was the report on the list that prompted me to start
>> looking (or I'm misremembering that report). In that case, sure, go
>> ahead and commit.
>
>Here's a summary of my setup.
>
>* I've generated a brand new CA certificate, and two HTTP server
>  certificates, signed by the CA.
>
>* One HTTP server certificate is for Common Name = 192.168.124.2
>
>* The other HTTP server certificate is for Common Name =
>  fd33:eb1b:9b36::2
>
>* I have a "net-server" virtual machine that runs Apache on the above
>IP
>  addresses (TCP port 443).
>
>  - This virtual machine also runs DHCP (v4) and DHCP (v6) daemons.
>
>  - The DHCP servers send the following boot file names:
>
>- "https://192.168.124.2/RHEL-7.4-20170711.0-Server-x86_64-boot.iso;   
>   [IPv4]
>-
>"https://[fd33:eb1b:9b36::2]/RHEL-7.4-20170711.0-Server-x86_64-boot.iso;
>[IPv6]
>
>* For sanity-checking the environment, I run the following two commands
>  on the *host* (connecting to the "net-server" virtual machine):
>
>- curl   -I
>'https://192.168.124.2/RHEL-7.4-20170711.0-Server-x86_64-boot.iso'
>- curl --globoff -I
>'https://[fd33:eb1b:9b36::2]/RHEL-7.4-20170711.0-Server-x86_64-boot.iso'
>
>  - The host is configured to trust the brand new test CA certificate
>(see near the top).
>
>  - When the certificates are assigned *correctly* to the IP addresses
>   in the Apache configuration, the above "curl" commands complete just
>fine. If I add the "-v" option to "curl", it confirms the right
>certificates are used, and it confirms the test CA as issuer too.
>
> - When the certificates are (intentionally) *cross-assigned* to the IP
>addresses in the Apache configuration, then both "curl" commands
>break with the following error message:
>
>> curl: (51) Unable to communicate securely with peer: requested domain
>> name does not match the server's certificate.
>
>  - If I add the "-v" option, I also see
>
>> NSS error -12276 (SSL_ERROR_BAD_CERT_DOMAIN)
>
>  - As a side comment: Apache itself warns about the misconfig, in
>"/var/log/httpd/ssl_error_log":
>
>> ... [ssl:warn] ... AH01909: RSA certificate configured for ...:443
>> does NOT include an ID which matches the server name
>
>* I have a "net-client" virtual machine, running OVMF.
>
>  - The edk2 HTTPS/TLS client booting in this virtual machine is
>configured to trust the exact same set of CA certificates that the
>host trusts too.
>
>  - In other words, HTTPS boot in the "net-client" VM accepts server
>

Re: [edk2-devel] [PATCH v1 0/4] Support HTTPS HostName validation feature(CVE-2019-14553)

2019-10-09 Thread Laszlo Ersek

Hi All,

(multi-hour composition ahead...)

On 10/09/19 09:53, David Woodhouse wrote:
> On Tue, 2019-10-08 at 06:19 +, Wu, Jiaxin wrote:
>> Hi David,
>>
>> I just realized you have the comments on Bugzilla 960:
>>
>>> "...given that testing is failing and code inspection shows it
>>> would never have been expected to work."
>>
>> Do you mean you didn't pass the verification if URLs with IPv6
>> literals (https://[2001:8b0:10b:1236::1]/)?  Can you also show me
>> where the code inspection indicated it would never have been expected
>> to work? We do pass the testing for the URLs with IPv6 if the CN or
>> SAN in certificate has the corresponding IPv6 address (at least
>> working with openssl 1.1.0).
>
> I have not tested this, but I started looking when there was a message
> on the edk2 list from someone who was reporting that it didn't work
> for IPv6 URIs, IIRC.
>
> You are using SSL_set1_host(), and I believe you're just passing in
> the bare hostname part of the URI, be it "1.2.3.4" or
> "[2001:8b0:10b::5]".
>
> That just adds it to the 'hosts' list in the X509_VERIFY_PARAM for the
> SSL connection.
>
> In the check_hosts() function in openssl/crypto/x509/v509_vfy.c, the
> code simply iterates over the members of that list, calling
> X509_check_host() for each one. It never calls X509_check_ip().
>
> If you look in openssl/crypto/x509/v3_utl.c you can see the
> X509_check_host() really does only check hostnames. You'd need to call
> X509_check_ip_asc() to check hostnames. And something would need to
> have stripped the [] which surround an IPv6 literal.
>
> I can't see how this can work. Have you tested it since the report on
> the list that it wasn't working?
>
> cf. https://github.com/openssl/openssl/pull/9201 which is being
> ignored by the OpenSSL developers  OpenSSL really doesn't make
> life easy for you here, which is a shame.
>
>
>> For the series patches here, we are intending to support the host
>> name validation, I think we can commit the series patches since we
>> pass the verification of IPV6 URL, what do you think?
>
> If it passes the verification of IPv6 literals, then all my analysis
> is broken and so was the report on the list that prompted me to start
> looking (or I'm misremembering that report). In that case, sure, go
> ahead and commit.

Here's a summary of my setup.

* I've generated a brand new CA certificate, and two HTTP server
  certificates, signed by the CA.

* One HTTP server certificate is for Common Name = 192.168.124.2

* The other HTTP server certificate is for Common Name =
  fd33:eb1b:9b36::2

* I have a "net-server" virtual machine that runs Apache on the above IP
  addresses (TCP port 443).

  - This virtual machine also runs DHCP (v4) and DHCP (v6) daemons.

  - The DHCP servers send the following boot file names:

- "https://192.168.124.2/RHEL-7.4-20170711.0-Server-x86_64-boot.iso;   
[IPv4]
- "https://[fd33:eb1b:9b36::2]/RHEL-7.4-20170711.0-Server-x86_64-boot.iso; 
[IPv6]

* For sanity-checking the environment, I run the following two commands
  on the *host* (connecting to the "net-server" virtual machine):

  - curl   -I 
'https://192.168.124.2/RHEL-7.4-20170711.0-Server-x86_64-boot.iso'
  - curl --globoff -I 
'https://[fd33:eb1b:9b36::2]/RHEL-7.4-20170711.0-Server-x86_64-boot.iso'

  - The host is configured to trust the brand new test CA certificate
(see near the top).

  - When the certificates are assigned *correctly* to the IP addresses
in the Apache configuration, the above "curl" commands complete just
fine. If I add the "-v" option to "curl", it confirms the right
certificates are used, and it confirms the test CA as issuer too.

  - When the certificates are (intentionally) *cross-assigned* to the IP
addresses in the Apache configuration, then both "curl" commands
break with the following error message:

> curl: (51) Unable to communicate securely with peer: requested domain
> name does not match the server's certificate.

  - If I add the "-v" option, I also see

> NSS error -12276 (SSL_ERROR_BAD_CERT_DOMAIN)

  - As a side comment: Apache itself warns about the misconfig, in
"/var/log/httpd/ssl_error_log":

> ... [ssl:warn] ... AH01909: RSA certificate configured for ...:443
> does NOT include an ID which matches the server name

* I have a "net-client" virtual machine, running OVMF.

  - The edk2 HTTPS/TLS client booting in this virtual machine is
configured to trust the exact same set of CA certificates that the
host trusts too.

  - In other words, HTTPS boot in the "net-client" VM accepts server
certificates signed by the new test CA.

* The following is the test plan.

1. The patch set is *not* applied (that is, OVMF is built at current
   master, commit 976d0353a6ce).

  1. Properly assigned certificates:

1. HTTPSv4 boot --> expect success (correct behavior, establishes
baseline)

2. HTTPSv6 boot --> expect success (correct

[edk2-devel] [PATCH] MdeModulePkg/XhciDxe: Fix Aligned Page Allocation

2019-10-09 Thread Ashish Singhal

While allocating pages aligned at an alignment higher than
4K, allocate memory taking into consideration the padding
required for that alignment. The calls to free pages takes
care of this already.

Signed-off-by: Ashish Singhal 
---
 MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c 
b/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
index fd79988..aa69c47 100644
--- a/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
+++ b/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
@@ -656,7 +656,7 @@ UsbHcAllocateAlignedPages (
   PciIo,
   AllocateAnyPages,
   EfiBootServicesData,
-  Pages,
+  RealPages,
   ,
   0
   );
-- 
2.7.4


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48668): https://edk2.groups.io/g/devel/message/48668
Mute This Topic: https://groups.io/mt/34465466/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Patch for Bug 2236 on Bugzilla

2019-10-09 Thread Chen, Kenji

Will do. Track number as title, 
https://bugzilla.tianocore.org/show_bug.cgi?id=2236.

From: Gao, Liming 
Sent: Wednesday, October 9, 2019 9:38 PM
To: devel@edk2.groups.io; Chen, Kenji 
Subject: RE: Patch for Bug 2236 on Bugzilla

Kenji:
 Please use git format-patch -1 to generate the patch, then use git send-email 
xxx.patch to send this patch to 
devel@edk2.groups.io

  Besides, is there the track in edk2 https://bugzilla.tianocore.org/? If no, 
can you submit one?

Thanks
Liming
From: devel@edk2.groups.io 
mailto:devel@edk2.groups.io>> On Behalf Of Chen, Kenji
Sent: Wednesday, October 9, 2019 4:00 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] Patch for Bug 2236 on Bugzilla

Commit Message:

FmpDevicePkg: Deferred LSV Commit after Platform Health Check

- LSV variable in each FmpDevice is updated after each successful FmpSetImage 
invocation. This blocks the deferred SVN mechanism performed by platfor side. 
Add a PCD to remove it to make platform code feasible to handle the mechanism 
of deferred LSV commit.
- Add FmpDevieSetImageEx function to delivr LsvUpdate parameter for 
FmpDeviceSetImage function. The value is from Fmp capsule image header to 
indicate platform side this is a LSV update.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48667): https://edk2.groups.io/g/devel/message/48667
Mute This Topic: https://groups.io/mt/34461090/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH V2 1/3] IntelSiliconPkg/FirmwareBootMediaLib: Add library

2019-10-09 Thread Kubacki, Michael A

1. DxeSmmFirmwareBootMediaLib could get the HOB like PEI for every access. I 
considered this but it seems
unnecessary since we have the flexibility for  phase-specific drivers that can 
have trivial optimizations
like this. Checking the HOB on every access would also constrain usage in 
DXE_SMM_DRIVER and 
DXE_RUNTIME_DRIVER modules.

2. They are certainly not required, but in practice we've found code usage 
tends to read better and be more
concise with these APIs for simple firmware boot media checks. The enum is 
provided for relatively rarer
scenarios where many possibilities need to be considered such as usage in a 
switch statement. I can see a
case made in either direction. Let me know if you and Sai feel strongly about 
this.

Thanks,
Michael

> -Original Message-
> From: Ni, Ray 
> Sent: Wednesday, October 9, 2019 2:36 AM
> To: Kubacki, Michael A ;
> devel@edk2.groups.io
> Cc: Chaganty, Rangasai V 
> Subject: RE: [edk2-platforms][PATCH V2 1/3]
> IntelSiliconPkg/FirmwareBootMediaLib: Add library
> 
> Michael,
> Two comments:
> 1. The difference between PEI and DXE instances is DXE instance has a global
> variable caching the boot media type. Both get the type from HOB. So I am
> thinking how about simplifying the library to have only one instance which
> equals to PEI instance. That can also be used in DXE phase.
> 2. With the definition of enum type FW_BOOT_MEDIA_TYPE and GetType()
> API, I feel the other several FirmwareBootMediaIsXXX() APIs are not very
> necessary.
> 
> Thanks,
> Ray
> 
> > -Original Message-
> > From: Kubacki, Michael A 
> > Sent: Saturday, October 5, 2019 1:29 AM
> > To: devel@edk2.groups.io
> > Cc: Chaganty, Rangasai V ; Ni, Ray
> > 
> > Subject: [edk2-platforms][PATCH V2 1/3]
> > IntelSiliconPkg/FirmwareBootMediaLib: Add library
> >
> > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2229
> >
> > Adds a new library that is used to make system initialization
> > decisions in the boot flow dependent upon firmware boot media.
> > Note that the firmware boot media is the storage media that the boot
> > firmware is stored on. It is not the OS storage media which may be
> > stored upon a different non-volatile storage device.
> >
> > Any Intel board, platform, or silicon code that must take action
> > conditionally based on the firmware boot media must use this library
> > API.
> >
> > Cc: Sai Chaganty 
> > Cc: Ray Ni 
> > Signed-off-by: Michael Kubacki 
> > ---
> >  Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec  
> > |   8 +-
> >  Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc  
> > |   4 +-
> >
> >
> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/DxeSmmFirm
> > wareBootMediaLib.inf |  43 
> >
> >
> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/PeiFirmwareB
> > ootMediaLib.inf|  38 +++
> >  Silicon/Intel/IntelSiliconPkg/Include/Library/FirmwareBootMediaLib.h
> > | 106 +++
> >
> >
> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/DxeSmmFirm
> > wareBootMediaLib.c   | 107 +++
> >
> >
> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/FirmwareBoo
> > tMediaLib.c | 109 
> >
> >
> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/PeiFirmwareB
> > ootMediaLib.c  |  82 +++
> >  8 files changed, 495 insertions(+), 2 deletions(-)
> >
> > diff --git a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> > b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> > index fe5bfa0dc6..f70e3b977d 100644
> > --- a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> > +++ b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> > @@ -3,7 +3,7 @@
> >  #
> >  # This package provides common open source Intel silicon modules.
> >  #
> > -# Copyright (c) 2016 - 2018, Intel Corporation. All rights
> > reserved.
> > +# Copyright (c) 2016 - 2019, Intel Corporation. All rights
> > +reserved.
> >  # SPDX-License-Identifier: BSD-2-Clause-Patent  #  ## @@ -22,6 +22,10
> > @@
> >#
> >MicrocodeFlashAccessLib|Include/Library/MicrocodeFlashAccessLib.h
> >
> > +  ## @libraryclass  Provides services to identify the firmware boot
> > + media
> > device.
> > +  #
> > +  FirmwareBootMediaLib|Include/Library/FirmwareBootMediaLib.h
> > +
> >  [Guids]
> >## GUID for Package token space
> ># {A9F8D54E-1107-4F0A-ADD0-4587E7A4A735}
> > @@ -35,6 +39,8 @@
> >## Include/Guid/MicrocodeFmp.h
> >gMicrocodeFmpImageTypeIdGuid  = { 0x96d4fdcd, 0x1502, 0x424d, {
> 0x9d,
> > 0x4c, 0x9b, 0x12, 0xd2, 0xdc, 0xae, 0x5c } }
> >
> > +  gFirmwareBootMediaHobGuid = { 0x8c7340ea, 0xde8b, 0x4e06, {0xa4,
> > + 0x78,
> > 0xec, 0x8b, 0x62, 0xd7, 0xa, 0x8b } }
> > +
> >  [Ppis]
> >gEdkiiVTdInfoPpiGuid = { 0x8a59fcb3, 0xf191, 0x400c, { 0x97, 0x67,
> > 0x67, 0xaf, 0x2b, 0x25, 0x68, 0x4a } }
> >
> > diff --git a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
> >

Re: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain -

2019-10-09 Thread Andrew Fish via Groups.Io



> On Oct 9, 2019, at 7:44 AM, Gao, Liming  wrote:
> 
> Laszlo:
> 
>> -Original Message-
>> From: Laszlo Ersek 
>> Sent: Wednesday, October 9, 2019 9:44 PM
>> To: Andrew Fish ; devel@edk2.groups.io
>> Cc: Gao, Liming 
>> Subject: Re: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain
>> 
>> On 10/09/19 01:08, Andrew Fish wrote:
>> 
>>> So I guess the way to describe it is XCODE inherits GCC and only needs to 
>>> override when it is different.
>> 
>> Thank you for the explanation!
>> 
>> I've been trying to figure out why this inheritance bothers me so much.
>> I guess the reason is the following:
>> 
>> I'm a user of the actual GCCxx toolchains (such as GCC48, GCC49, GCC5).
>> Assume that I realize that a gcc-specific change is needed to some part
>> of the code. (It could be build options, or gcc specific source code,
>> etc.) Then, I go to the gcc documentation, and verify whether the change
>> is indeed supported by all the relevant gcc versions.
>> 
>> If the change is possible with only some gcc versions, then I likely
>> write the change for a specific toolchain only, such as GCC5. Fine.
>> 
>> Now assume that my documentation review proves that *all* GCCxx
>> toolchains, supported by edk2, should receive the update. This could be
>> a #pragma, a command line flag, some __attribute__, etc. I'd very likely
>> express the change for the whole GCC toolchain *family*, and not
>> enumerate it for GCC48, GCC49, GCC5 individually.
>> 
>> And now I learn that said approach would be wrong, because such a change
>> would be inherited by XCODExx and CLANGxx too (via FAMILY), fully
>> against my intent, unless XCODExx and CLANGxx overrode the particular
>> aspect (via BUILDRULEFAMILY).
> 
> The difference between XCODE/CLANG and GCCXX is the linker. Current patches 
> are
> introduced for the different linker. Clang supports most usage of GCC 
> compiler.
> So, CLANG and XCODE uses GCC family. When I enable XCODE or CLANG tool chain
> in the platform, I don't find other incompatible behavior with GCC compiler.
> So, I think it is safe to let CLANG inherit GCC option except for these two 
> cases.
> When you make new changes, and verify them with GCC compiler, that's enough.
> You don't need to specially verify them with XCODE or CLANG. In most case, 
> GCC 
> compiler pass, XCODE or CLANG can also pass.
> 

Liming,

I agree that clang attempts to be drop in compatible with GCC and the big 
difference is the linker. For the most part XCODE means macOS linker + clang. 

I thought the thing we were discussing was compiler flags. Specifically 
-mno-mmx -mno-sse. It seems to me if OVMF requires -mno-mmx -mno-sse then it is 
a bug in the tools_def.txt definition for those compilers?  As far as I can 
tell -mno-implicit-float should prevent the optimizer from using floating 
point. The -mno-mmx -mno-sse flags most change how floating point code gets 
compiled [1]. it looks like -mno-mmx -mno-sse just down grade floating point 
instructions that get used. Thus it seems like either we have some code doing 
float and that code should set -mno-mmx -mno-sse, or the -mno-mmx -mno-sse 
should be set generically. 

[1]
~/work/Compiler/float>cat c.c
int main()
{
float a = 10;
float b = 20;

float c = a * b;

return 0;
}
~/work/Compiler/float>clang -S c.c -mno-implicit-float
~/work/Compiler/float>cat c.S
.section__TEXT,__text,regular,pure_instructions
.build_version macos, 10, 15sdk_version 10, 15
.section__TEXT,__literal4,4byte_literals
.p2align2   ## -- Begin function main
LCPI0_0:
.long   1101004800  ## float 20
LCPI0_1:
.long   1092616192  ## float 10
.section__TEXT,__text,regular,pure_instructions
.globl  _main
.p2align4, 0x90
_main:  ## @main
.cfi_startproc
## %bb.0:
pushq   %rbp
.cfi_def_cfa_offset 16
.cfi_offset %rbp, -16
movq%rsp, %rbp
.cfi_def_cfa_register %rbp
xorl%eax, %eax
movss   LCPI0_0(%rip), %xmm0## xmm0 = mem[0],zero,zero,zero
movss   LCPI0_1(%rip), %xmm1## xmm1 = mem[0],zero,zero,zero
movl$0, -4(%rbp)
movss   %xmm1, -8(%rbp)
movss   %xmm0, -12(%rbp)
movss   -8(%rbp), %xmm0 ## xmm0 = mem[0],zero,zero,zero
mulss   -12(%rbp), %xmm0
movss   %xmm0, -16(%rbp)
popq%rbp
retq
.cfi_endproc
## -- End function

.subsections_via_symbols
~/work/Compiler/float>clang -S c.c -mno-implicit-float -mno-mmx -mno-sse
~/work/Compiler/float>cat c.S
.section__TEXT,__text,regular,pure_instructions
.build_version macos, 10, 15sdk_version 10, 15
.globl  _main   ## -- Begin function main
.p2align4, 0x90
_main:

Re: [edk2-devel] [PATCH v1 0/4] Support HTTPS HostName validation feature(CVE-2019-14553)

2019-10-09 Thread Laszlo Ersek

On 10/01/19 01:21, Laszlo Ersek wrote:
> On 09/29/19 08:09, Wang, Jian J wrote:
>> For this patch series,
>> 1. " Contributed-under: TianoCore Contribution Agreement 1.1" is not needed 
>> any more.
>>   Remove it at push time and no need to send a v2.
>> 2. Since it's security patch which had been reviewed separately, I see no 
>> reason for new r-b
>>   required. Please raise it asap if any objections.
>> 3. Acked-by: Jian J Wang 
> 
> 
> * Can you please confirm that these patches match those that we
> discussed here:
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=960#c18
> https://bugzilla.tianocore.org/show_bug.cgi?id=960#c19

To answer my own question, I've now compared the patches from those BZ
comments linked above, with the present series. Here's a list of
differences.

(1) The subject lines now include the reference "(CVE-2019-14553)".

This is great, *but* please be sure to insert a space character before
the opening parenthesis! (In every patch.)

(2) The commit messages reference both the BZ and the CVE number.

Good.

(3) In the commit messages, the line

  Contributed-under: TianoCore Contribution Agreement 1.0

has been upgraded to

  Contributed-under: TianoCore Contribution Agreement 1.1

I think this is wrong. The lines should have been removed, due to the
SPDX adoption. Please update all the commit messages.

(4) Copyright notice updates are gone from the patches.

That's fine: the reason is that the underlying files have seen their
copyright notices updated, meanwhile.

Otherwise, the patches (code, commit messages, and feedback tags) are
identical.

Before you push the patches (or post a v2), please fix issues (1) and (3).

Now, regarding the other set of questions:

> * In the BZ, David and Bret raised some questions:
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=960#c31
> https://bugzilla.tianocore.org/show_bug.cgi?id=960#c32
> https://bugzilla.tianocore.org/show_bug.cgi?id=960#c35
> https://bugzilla.tianocore.org/show_bug.cgi?id=960#c36
> 
> and
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=960#c40
> 
> The latest comment in the bug is c#41. I'm not under the impression that
> all concerns raised by David and Bret have been addressed (or
> abandoned). I'd like David and Bret to ACK the patches.

I'll first have to process the new comments down-thread.

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48664): https://edk2.groups.io/g/devel/message/48664
Mute This Topic: https://groups.io/mt/34307578/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/4] UefiCpuPkg/MpInitLib: honor the platform's boot CPU count in AP detection

2019-10-09 Thread Laszlo Ersek

On 10/09/19 02:57, Dong, Eric wrote:
> Hi Laszlo,
> 
>> -Original Message-
>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>> Laszlo Ersek
>> Sent: Tuesday, October 8, 2019 7:27 PM
>> To: edk2-devel-groups-io 
>> Cc: Dong, Eric ; Igor Mammedov
>> ; Ni, Ray 
>> Subject: [edk2-devel] [PATCH 1/4] UefiCpuPkg/MpInitLib: honor the platform's
>> boot CPU count in AP detection
>>
>> If a platform boots with a CPU topology that is not fully populated (that
>> is, the boot CPU count is smaller than PcdCpuMaxLogicalProcessorNumber),
>> then the platform cannot use the "fast AP detection" logic added in commit
>> 6e1987f19af7. Said logic depends on the boot CPU count being equal to
>> PcdCpuMaxLogicalProcessorNumber.
>>
>> The platform may not be able to use the variant added in commit
>> 0594ec417c89 either, for different reasons; see for example commit
>> 861218740d6d.
>>
>> Allow platforms to specify the exact boot CPU count, independently of
>> PcdCpuMaxLogicalProcessorNumber.
>>
>> Cc: Eric Dong 
>> Cc: Igor Mammedov 
>> Cc: Ray Ni 
>> Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515
>> Signed-off-by: Laszlo Ersek 
>> ---
>>  UefiCpuPkg/UefiCpuPkg.dec | 11 +
>>  UefiCpuPkg/UefiCpuPkg.uni |  4 ++
>>  UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf |  1 +
>>  UefiCpuPkg/Library/MpInitLib/PeiMpInitLib.inf |  3 +-
>>  UefiCpuPkg/Library/MpInitLib/MpLib.c  | 42 
>>  5 files changed, 43 insertions(+), 18 deletions(-)
>>
>> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
>> index 031a2ccd680a..d6b33fd9b465 100644
>> --- a/UefiCpuPkg/UefiCpuPkg.dec
>> +++ b/UefiCpuPkg/UefiCpuPkg.dec
>> @@ -227,6 +227,17 @@ [PcdsFixedAtBuild, PcdsPatchableInModule,
>> PcdsDynamic, PcdsDynamicEx]
>>## Specifies timeout value in microseconds for the BSP to detect all APs 
>> for
>> the first time.
>># @Prompt Timeout for the BSP to detect all APs for the first time.
>>
>> gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds|5|UI
>> NT32|0x0004
>> +  ## Specifies the number of Logical Processors that are available in the
>> +  #  preboot environment after platform reset, including BSP and APs. 
>> Possible
>> +  #  values:
>> +  #  zero (default) - This PCD is ignored, and
>> +  #   PcdCpuApInitTimeOutInMicroSeconds limits the initial 
>> AP
>> +  #   detection by the BSP.
>> +  #  nonzero- PcdCpuApInitTimeOutInMicroSeconds is ignored. The 
>> initial
>> +  #   AP detection finishes when the detected CPU count (BSP
>> +  #   plus APs) reaches the value of this PCD.
>> +  # @Prompt Number of Logical Processors available after platform reset.
>> +
>> gUefiCpuPkgTokenSpaceGuid.PcdCpuBootLogicalProcessorNumber|0|UINT32
>> |0x0008
>>## Specifies the base address of the first microcode Patch in the 
>> microcode
>> Region.
>># @Prompt Microcode Region base address.
>>
>> gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchAddress|0x0|UINT64|0x
>> 0005
>> diff --git a/UefiCpuPkg/UefiCpuPkg.uni b/UefiCpuPkg/UefiCpuPkg.uni
>> index fbf768072668..a7e279c5cb14 100644
>> --- a/UefiCpuPkg/UefiCpuPkg.uni
>> +++ b/UefiCpuPkg/UefiCpuPkg.uni
>> @@ -37,6 +37,10 @@
>>
>>  #string
>> STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuApInitTimeOutInMicroSeconds_HEL
>> P  #language en-US "Specifies timeout value in microseconds for the BSP to
>> detect all APs for the first time."
>>
>> +#string
>> STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuBootLogicalProcessorNumber_PRO
>> MPT  #language en-US "Number of Logical Processors available after platform
>> reset."
>> +
>> +#string
>> STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuBootLogicalProcessorNumber_HELP
>> #language en-US "Specifies the number of Logical Processors that are 
>> available
>> in the preboot environment after platform reset, including BSP and APs."
>> +
>>  #string
>> STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuMicrocodePatchAddress_PROMPT
>> #language en-US "Microcode Region base address."
>>
>>  #string
>> STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuMicrocodePatchAddress_HELP
>> #language en-US "Specifies the base address of the first microcode Patch in
>> the microcode Region."
>> diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
>> b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
>> index 37b3f64e578a..cd912ab0c5ee 100644
>> --- a/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
>> +++ b/UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
>> @@ -61,6 +61,7 @@ [Guids]
>>
>>  [Pcd]
>>gUefiCpuPkgTokenSpaceGuid.PcdCpuMaxLogicalProcessorNumber##
>> CONSUMES
>> +  gUefiCpuPkgTokenSpaceGuid.PcdCpuBootLogicalProcessorNumber   ##
>> CONSUMES
>>gUefiCpuPkgTokenSpaceGuid.PcdCpuApInitTimeOutInMicroSeconds  ##
>> SOMETIMES_CONSUMES
>>gUefiCpuPkgTokenSpaceGuid.PcdCpuApStackSize  ## 
>> CONSUMES
>>gUefiCpuPkgTokenSpaceGuid.PcdCpuMicrocodePatchAddress##
>>

Re: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain

2019-10-09 Thread Liming Gao

Laszlo:

> -Original Message-
> From: Laszlo Ersek 
> Sent: Wednesday, October 9, 2019 9:44 PM
> To: Andrew Fish ; devel@edk2.groups.io
> Cc: Gao, Liming 
> Subject: Re: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain
> 
> On 10/09/19 01:08, Andrew Fish wrote:
> 
> > So I guess the way to describe it is XCODE inherits GCC and only needs to 
> > override when it is different.
> 
> Thank you for the explanation!
> 
> I've been trying to figure out why this inheritance bothers me so much.
> I guess the reason is the following:
> 
> I'm a user of the actual GCCxx toolchains (such as GCC48, GCC49, GCC5).
> Assume that I realize that a gcc-specific change is needed to some part
> of the code. (It could be build options, or gcc specific source code,
> etc.) Then, I go to the gcc documentation, and verify whether the change
> is indeed supported by all the relevant gcc versions.
> 
> If the change is possible with only some gcc versions, then I likely
> write the change for a specific toolchain only, such as GCC5. Fine.
> 
> Now assume that my documentation review proves that *all* GCCxx
> toolchains, supported by edk2, should receive the update. This could be
> a #pragma, a command line flag, some __attribute__, etc. I'd very likely
> express the change for the whole GCC toolchain *family*, and not
> enumerate it for GCC48, GCC49, GCC5 individually.
> 
> And now I learn that said approach would be wrong, because such a change
> would be inherited by XCODExx and CLANGxx too (via FAMILY), fully
> against my intent, unless XCODExx and CLANGxx overrode the particular
> aspect (via BUILDRULEFAMILY).

The difference between XCODE/CLANG and GCCXX is the linker. Current patches are
introduced for the different linker. Clang supports most usage of GCC compiler.
So, CLANG and XCODE uses GCC family. When I enable XCODE or CLANG tool chain
in the platform, I don't find other incompatible behavior with GCC compiler.
So, I think it is safe to let CLANG inherit GCC option except for these two 
cases.
When you make new changes, and verify them with GCC compiler, that's enough.
You don't need to specially verify them with XCODE or CLANG. In most case, GCC 
compiler pass, XCODE or CLANG can also pass.

Thanks
Liming
> 
> This means that, after checking the gcc documentation meticulously
> (multiple releases), and possibly even testing multiple gcc
> installations, I could still regress edk2 (CLANGxx and/or XCODExx
> specific parts), because they could inherit my GCC-oriented changes that
> I never meant for CLANGxx and/or XCODExx.
> 
> I don't use XCODE or CLANG, I don't test on them, and now it seems I can
> restrict changes to the *actual* gcc compilers only if I keep spelling
> out the individual toolchain names, such as GCC48, GCC49, GCC5.
> 
> This makes the toolchain family concept totally useless to me (and to
> other users that only care about actual gcc compilers). There is no
> *family* facility available that allows people to restrict settings to
> actual gcc compilers. In other words, we can't express "all GCCxx
> toolchains, regardless of toolchain version, but not XCODE, and also not
> CLANG".
> 
> Thanks
> Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48662): https://edk2.groups.io/g/devel/message/48662
Mute This Topic: https://groups.io/mt/34309064/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 4/4] OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU hotplug

2019-10-09 Thread Laszlo Ersek

On 10/09/19 12:23, Igor Mammedov wrote:
> On Tue, 8 Oct 2019 23:12:10 +0200
> Laszlo Ersek  wrote:
> 
>> On 10/08/19 17:06, Igor Mammedov wrote:
>>> On Tue,  8 Oct 2019 13:27:14 +0200
>>> Laszlo Ersek  wrote:
>>>  
 MaxCpuCountInitialization() currently handles the following options:

 (1) QEMU does not report the boot CPU count.

 In this case, PlatformPei makes MpInitLib enumerate APs up to the
 default PcdCpuMaxLogicalProcessorNumber value (64) minus 1, or until
 the default PcdCpuApInitTimeOutInMicroSeconds (50,000) elapses.
 (Whichever is reached first.)

 Time-limited AP enumeration had never been reliable on QEMU/KVM, which
 is why commit 45a70db3c3a5 strated handling case (2) below, in OVMF.

 (2) QEMU reports the boot CPU count.

 In this case, PlatformPei sets PcdCpuMaxLogicalProcessorNumber to the
 reported boot CPU count, and PcdCpuApInitTimeOutInMicroSeconds to
 practically "infinity" (MAX_UINT32, ~71 minutes). That causes
 MpInitLib to enumerate exactly the available (boot) APs.

 With CPU hotplug in mind, this method is not good enough. While
 UefiCpuPkg expects PcdCpuMaxLogicalProcessorNumber to include both
 boot (i.e., cold-plugged), and all *potentially* hot-plugged, logical
 processors, the boot CPU count reported by QEMU does not cover the
 second category.  
>>>
>>> Can you elaborate why it doesn't cover the second category?  
>>
>> (Elaborate just in this thread, or elaborate in the commit message?)
>>
>> The boot CPU count reported by QEMU does not cover all potentially
>> hot-plugged logical processors ... because it is not supposed to.
>>
>> Namely, FW_CFG_NB_CPUS exposes "pcms->boot_cpus", and that is not
>> supposed to cover all potentially hot-plugged CPUs, only the boot-time
>> CPUs.
> 'potentially hotplugged' confuses me greatly in this context
> (I'm not sure if you talk about hotplugged or not existing yet CPUs).
> 
> If it's about possible CPUs limit, I'd use "possible CPUs"
> instead (wich includes present and not present CPUs).

Good idea. I was struggling to find the correct term. I realize the
"possible CPUs" term has been used in QEMU forever. I'll update the
commit message.

> 
> 
>> Whereas PcdCpuMaxLogicalProcessorNumber needs to include all potentially
>> hot-plugged CPUs too. For that, we need to expose "ms->smp.max_cpus"
>> from QEMU.
>>
>> Does this answer your question?
> You answered question better below
> 
> [...]
> 
>> When a CPU is hotplugged at OS runtime, "pcms->boot_cpus" increases in
>> QEMU. 
>> Before the patch, the "pcms->boot_cpus" increase causes
>> PcdCpuMaxLogicalProcessorNumber to increase as well. That breaks S3
>> resume. PcdCpuMaxLogicalProcessorNumber must not change from initial
>> boot to S3 resume.
> Probably something along this lines should be put in commit message,
> which clearly states a requirement for max_cpus

OK, I'll work that into the commit message too.

Thanks!
Laszlo

> 
>>
>> After the patch, the "pcms->boot_cpus" increase does not increase
>> PcdCpuMaxLogicalProcessorNumber. PcdCpuMaxLogicalProcessorNumber remains
>> the same (namely, "ms->smp.max_cpus"). Therefore, the CPU structures
>> allocated during normal boot, for "ms->smp.max_cpus", will accommodate
>> the CPUs that have been hotplugged prior to S3 resume.
>>
>> I tested the S3 behavior, plus the values mentioned above are also
>> logged to the OVMF debug log, by this patch:
>>
>>> +  DEBUG ((DEBUG_INFO, "%a: BootCpuCount=%d mMaxCpuCount=%u\n", 
>>> __FUNCTION__,
>>> +BootCpuCount, mMaxCpuCount));  
>>
>> This is one libvirt domain XML snippet I've used for testing:
>>
>>   4
>>   
>> 
>> 
>> 
>> 
>>   
>>   
>> hvm
>> ...
>>   
>> Haswell-noTSX
>> 
>> 
>> 
>> 
>> 
>>   
>>
>> And the command used for testing was:
>>
>> $ virsh setvcpu GUEST 3 --enable --live
>>
>> When this is done, the guest kernel dmesg confirms the CPU hotplug, but
>> it is not onlined automatically. I onlined it via /sys manually in the
>> guest.
>>
>> After that point, I exercised S3 suspend / resume. During S3 resume, the
>> "BootCpuCount" log (from above) increases from 3 to 4 (and the related
>> edk2 infrastructure messages are in sync). All the while "mMaxCpuCount"
>> preserves its initial value, 4.
>>
>> Finally, after S3 resume, I ran "rdmsr -a 0x3a" in the guest, which
>> printed "5" for all *four* CPUs. This confirms that OVMF has set the
>> Feature Control MSR on the new VCPU too, during S3 resume.
>>
>> (The MSR is zeroed on platform reset, and has to be re-configured by
>> firmware, on every CPU, during S3. It is set to 5 due to the "vmx" CPU
>> feature in the above domain XML snippet. References:
>>
>> - https://bugzilla.tianocore.org/show_bug.cgi?id=86
>> - 
>>

Re: [edk2-devel] [PATCH edk2-platforms 3/6] Maintainers.txt: revamp file to machine-readable format

2019-10-09 Thread Leif Lindholm

On Wed, Oct 09, 2019 at 01:48:57PM +, Gao, Liming wrote:
> Leif:
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On Behalf Of Leif Lindholm
> > Sent: Wednesday, October 9, 2019 8:00 PM
> > To: devel@edk2.groups.io
> > Cc: Ard Biesheuvel ; Kinney, Michael D 
> > 
> > Subject: [edk2-devel] [PATCH edk2-platforms 3/6] Maintainers.txt: revamp 
> > file to machine-readable format
> > 
> > Convert existing package maintainer/reviewer descriptions
> > with adding the new path definitions.
> > 
> > Delete the "Platform" and "Silicon" section maintainership
> > descriptions. The EDK II Platforms maintainers section will
> > now match that.
> > 
> > Cc: Ard Biesheuvel 
> > Cc: Michael D Kinney 
> > Signed-off-by: Leif Lindholm 
> > ---
> >  Maintainers.txt | 56 ++---
> >  1 file changed, 44 insertions(+), 12 deletions(-)
> > 
> > diff --git a/Maintainers.txt b/Maintainers.txt
> > index 1d27dde741f0..43803592d369 100644
> > --- a/Maintainers.txt
> > +++ b/Maintainers.txt
> > @@ -60,6 +60,18 @@ W: 
> > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II
> >  L: https://edk2.groups.io/g/devel/
> >  T: git - https://github.com/tianocore/edk2-platforms.git
> > 
> > +All patches CC:d here
> > +L: devel@edk2.groups.io
> > +F: *
> > +F: */
> > +
> > +EDK II Platforms maintainers
> > +
> > +F: *
> > +M: Ard Bieshuevel 
> > +M: Leif Lindholm 
> > +M: Michael D Kinney 
> > +
> >  Responsible Disclosure, Reporting Security Issues
> >  -
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/Security
> > @@ -67,136 +79,156 @@ W: 
> > https://github.com/tianocore/tianocore.github.io/wiki/Security
> >  EDK II Platforms Packages:
> >  --
> > 
> > -Drivers/OptionRomPkg
> > +OptionRomPkg
> > +F: Drivers/OptionRomPkg/
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg
> >  M: Ray Ni 
> > 
> > -Drivers/DisplayLink
> > +DisplayLink
> > +F: Drivers/DisplayLink/
> >  M: Leif Lindholm 
> >  M: Ard Bieshuevel 
> >  R: Andy Hayes 
> > 
> > -Platform
> > -M: Ard Biesheuvel 
> > -M: Leif Lindholm 
> > -M: Michael D Kinney 
> > -
> >  Platform/Intel/QuarkPlatformPkg
> > +F: Platform/Intel/QuarkPlatformPkg/
> >  M: Michael D Kinney 
> >  M: Kelly Steele 
> > 
> >  Platform/Intel/Vlv2TbltDevicePkg
> > +F: Platform/Intel/Vlv2TbltDevicePkg/
> >  M: Zailiang Sun 
> >  M: Yi Qian 
> > 
> >  Platform/Intel/AdvancedFeaturePkg
> > +F: Platform/Intel/AdvancedFeaturePkg/
> >  M: Michael Kubacki 
> >  M: Sai Chaganty 
> >  R: Liming Gao 
> > 
> >  Platform/Intel/BoardModulePkg
> > +F: Platform/Intel/BoardModulePkg/
> >  M: Eric Dong 
> >  R: Liming Gao 
> > 
> >  Platform/Intel/DebugFeaturePkg
> > +F: Platform/Intel/DebugFeaturePkg/
> >  M: Eric Dong 
> >  R: Liming Gao 
> > 
> >  Platform/Intel/UserInterfaceFeaturePkg
> > +F: Platform/Intel/UserInterfaceFeaturePkg/
> >  M: Dandan Bi 
> >  R: Liming Gao 
> > 
> >  Platform/Intel/KabylakeOpenBoardPkg
> > +F: Platform/Intel/KabylakeOpenBoardPkg/
> >  M: Chasel Chiu 
> >  M: Michael Kubacki 
> >  M: Nate DeSimone 
> > 
> >  Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3
> > +F: Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/
> >  R: Jeremy Soller 
> > 
> >  Platform/Intel/MinPlatformPkg
> > +F: Platform/Intel/MinPlatformPkg/
> >  M: Michael Kubacki 
> >  M: Chasel Chiu 
> >  M: Nate DeSimone 
> >  R: Liming Gao 
> > 
> >  Platform/Intel/PurleyOpenBoardPkg
> > +F: Platform/Intel/PurleyOpenBoardPkg/
> >  M: Shifei A Lu 
> >  M: Xiaohu Zhou 
> >  M: Isaac W Oram 
> > 
> >  Platform/Intel/WhiskeylakeOpenBoardPkg
> > +F: Platform/Intel/WhiskeylakeOpenBoardPkg/
> >  M: Chasel Chiu 
> >  M: Michael Kubacki 
> >  M: Nate DeSimone 
> > 
> >  Platform/Intel/SimicsOpenBoardPkg
> > +F: Platform/Intel/SimicsOpenBoardPkg/
> >  M: Wei David Y 
> >  M: Agyeman Prince 
> > 
> >  Platform/Intel/Tools
> > +F: Platform/Intel/Tools/
> >  M: Bob Feng 
> >  M: Liming Gao 
> > 
> >  Platform/Marvell
> > +F; Platform/Marvell/
> This is a typo. It should be F: Platform/Marvell/. Right?

Yes. Thanks!

/
Leif

> Thanks
> Liming
> >  R: Marcin Wojtas 
> > +M: Leif Lindholm 
> > 
> >  Platform/SolidRun/Armada80x0McBin
> > +F: Platform/SolidRun/Armada80x0McBin/
> >  R: Marcin Wojtas 
> > 
> > -Silicon
> > -M: Ard Biesheuvel 
> > -M: Leif Lindholm 
> > -M: Michael D Kinney 
> > -
> >  Silicon/Intel/IntelSiliconPkg
> > +F: Silicon/Intel/IntelSiliconPkg/
> >  M: Ray Ni 
> >  M: Rangasai V Chaganty 
> > 
> >  Silicon/Intel/QuarkSocPkg
> > +F: Silicon/Intel/QuarkSocPkg/
> >  M: Michael D Kinney 
> >  M: Kelly Steele 
> > 
> >  Silicon/Intel/Vlv2DeviceRefCodePkg
> > +F: Silicon/Intel/Vlv2DeviceRefCodePkg/
> >  M: Zailiang Sun 
> >  M: Yi Qian 
> > 
> >  Silicon/Intel/CoffeelakeSiliconPkg
> > +F: Silicon/Intel/CoffeelakeSiliconPkg/
> >  M: Chasel Chiu 
> >  M: Michael Kubacki 
> >  M: Sai Chaganty 
> > 
> >  Silicon/Intel/KabylakeSiliconPkg

Re: [edk2-devel] [PATCH edk2-platforms 3/6] Maintainers.txt: revamp file to machine-readable format

2019-10-09 Thread Liming Gao

Leif:

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Leif Lindholm
> Sent: Wednesday, October 9, 2019 8:00 PM
> To: devel@edk2.groups.io
> Cc: Ard Biesheuvel ; Kinney, Michael D 
> 
> Subject: [edk2-devel] [PATCH edk2-platforms 3/6] Maintainers.txt: revamp file 
> to machine-readable format
> 
> Convert existing package maintainer/reviewer descriptions
> with adding the new path definitions.
> 
> Delete the "Platform" and "Silicon" section maintainership
> descriptions. The EDK II Platforms maintainers section will
> now match that.
> 
> Cc: Ard Biesheuvel 
> Cc: Michael D Kinney 
> Signed-off-by: Leif Lindholm 
> ---
>  Maintainers.txt | 56 ++---
>  1 file changed, 44 insertions(+), 12 deletions(-)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 1d27dde741f0..43803592d369 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -60,6 +60,18 @@ W: 
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II
>  L: https://edk2.groups.io/g/devel/
>  T: git - https://github.com/tianocore/edk2-platforms.git
> 
> +All patches CC:d here
> +L: devel@edk2.groups.io
> +F: *
> +F: */
> +
> +EDK II Platforms maintainers
> +
> +F: *
> +M: Ard Bieshuevel 
> +M: Leif Lindholm 
> +M: Michael D Kinney 
> +
>  Responsible Disclosure, Reporting Security Issues
>  -
>  W: https://github.com/tianocore/tianocore.github.io/wiki/Security
> @@ -67,136 +79,156 @@ W: 
> https://github.com/tianocore/tianocore.github.io/wiki/Security
>  EDK II Platforms Packages:
>  --
> 
> -Drivers/OptionRomPkg
> +OptionRomPkg
> +F: Drivers/OptionRomPkg/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg
>  M: Ray Ni 
> 
> -Drivers/DisplayLink
> +DisplayLink
> +F: Drivers/DisplayLink/
>  M: Leif Lindholm 
>  M: Ard Bieshuevel 
>  R: Andy Hayes 
> 
> -Platform
> -M: Ard Biesheuvel 
> -M: Leif Lindholm 
> -M: Michael D Kinney 
> -
>  Platform/Intel/QuarkPlatformPkg
> +F: Platform/Intel/QuarkPlatformPkg/
>  M: Michael D Kinney 
>  M: Kelly Steele 
> 
>  Platform/Intel/Vlv2TbltDevicePkg
> +F: Platform/Intel/Vlv2TbltDevicePkg/
>  M: Zailiang Sun 
>  M: Yi Qian 
> 
>  Platform/Intel/AdvancedFeaturePkg
> +F: Platform/Intel/AdvancedFeaturePkg/
>  M: Michael Kubacki 
>  M: Sai Chaganty 
>  R: Liming Gao 
> 
>  Platform/Intel/BoardModulePkg
> +F: Platform/Intel/BoardModulePkg/
>  M: Eric Dong 
>  R: Liming Gao 
> 
>  Platform/Intel/DebugFeaturePkg
> +F: Platform/Intel/DebugFeaturePkg/
>  M: Eric Dong 
>  R: Liming Gao 
> 
>  Platform/Intel/UserInterfaceFeaturePkg
> +F: Platform/Intel/UserInterfaceFeaturePkg/
>  M: Dandan Bi 
>  R: Liming Gao 
> 
>  Platform/Intel/KabylakeOpenBoardPkg
> +F: Platform/Intel/KabylakeOpenBoardPkg/
>  M: Chasel Chiu 
>  M: Michael Kubacki 
>  M: Nate DeSimone 
> 
>  Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3
> +F: Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/
>  R: Jeremy Soller 
> 
>  Platform/Intel/MinPlatformPkg
> +F: Platform/Intel/MinPlatformPkg/
>  M: Michael Kubacki 
>  M: Chasel Chiu 
>  M: Nate DeSimone 
>  R: Liming Gao 
> 
>  Platform/Intel/PurleyOpenBoardPkg
> +F: Platform/Intel/PurleyOpenBoardPkg/
>  M: Shifei A Lu 
>  M: Xiaohu Zhou 
>  M: Isaac W Oram 
> 
>  Platform/Intel/WhiskeylakeOpenBoardPkg
> +F: Platform/Intel/WhiskeylakeOpenBoardPkg/
>  M: Chasel Chiu 
>  M: Michael Kubacki 
>  M: Nate DeSimone 
> 
>  Platform/Intel/SimicsOpenBoardPkg
> +F: Platform/Intel/SimicsOpenBoardPkg/
>  M: Wei David Y 
>  M: Agyeman Prince 
> 
>  Platform/Intel/Tools
> +F: Platform/Intel/Tools/
>  M: Bob Feng 
>  M: Liming Gao 
> 
>  Platform/Marvell
> +F; Platform/Marvell/
This is a typo. It should be F: Platform/Marvell/. Right?

Thanks
Liming
>  R: Marcin Wojtas 
> +M: Leif Lindholm 
> 
>  Platform/SolidRun/Armada80x0McBin
> +F: Platform/SolidRun/Armada80x0McBin/
>  R: Marcin Wojtas 
> 
> -Silicon
> -M: Ard Biesheuvel 
> -M: Leif Lindholm 
> -M: Michael D Kinney 
> -
>  Silicon/Intel/IntelSiliconPkg
> +F: Silicon/Intel/IntelSiliconPkg/
>  M: Ray Ni 
>  M: Rangasai V Chaganty 
> 
>  Silicon/Intel/QuarkSocPkg
> +F: Silicon/Intel/QuarkSocPkg/
>  M: Michael D Kinney 
>  M: Kelly Steele 
> 
>  Silicon/Intel/Vlv2DeviceRefCodePkg
> +F: Silicon/Intel/Vlv2DeviceRefCodePkg/
>  M: Zailiang Sun 
>  M: Yi Qian 
> 
>  Silicon/Intel/CoffeelakeSiliconPkg
> +F: Silicon/Intel/CoffeelakeSiliconPkg/
>  M: Chasel Chiu 
>  M: Michael Kubacki 
>  M: Sai Chaganty 
> 
>  Silicon/Intel/KabylakeSiliconPkg
> +F: Silicon/Intel/KabylakeSiliconPkg/
>  M: Chasel Chiu 
>  M: Michael Kubacki 
>  M: Sai Chaganty 
> 
>  Silicon/Intel/LewisburgPkg
> +F: Silicon/Intel/LewisburgPkg/
>  M: Maciej Piwko
>  M: Daocheng Bu 
>  M: Isaac W Oram 
> 
>  Silicon/Intel/PurleyRcPkg
> +F: Silicon/Intel/PurleyRcPkg/
>  M: Thad Gillispie 
>  M: Daocheng Bu 
>  M: Isaac W Oram 
> 
>  Silicon/Intel/PurleySktPkg
> +F: Silicon/Intel/PurleySktPkg/
>  M: Thad Gillispie 
>  M:

Re: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain

2019-10-09 Thread Laszlo Ersek

On 10/09/19 01:08, Andrew Fish wrote:

> So I guess the way to describe it is XCODE inherits GCC and only needs to 
> override when it is different.

Thank you for the explanation!

I've been trying to figure out why this inheritance bothers me so much.
I guess the reason is the following:

I'm a user of the actual GCCxx toolchains (such as GCC48, GCC49, GCC5).
Assume that I realize that a gcc-specific change is needed to some part
of the code. (It could be build options, or gcc specific source code,
etc.) Then, I go to the gcc documentation, and verify whether the change
is indeed supported by all the relevant gcc versions.

If the change is possible with only some gcc versions, then I likely
write the change for a specific toolchain only, such as GCC5. Fine.

Now assume that my documentation review proves that *all* GCCxx
toolchains, supported by edk2, should receive the update. This could be
a #pragma, a command line flag, some __attribute__, etc. I'd very likely
express the change for the whole GCC toolchain *family*, and not
enumerate it for GCC48, GCC49, GCC5 individually.

And now I learn that said approach would be wrong, because such a change
would be inherited by XCODExx and CLANGxx too (via FAMILY), fully
against my intent, unless XCODExx and CLANGxx overrode the particular
aspect (via BUILDRULEFAMILY).

This means that, after checking the gcc documentation meticulously
(multiple releases), and possibly even testing multiple gcc
installations, I could still regress edk2 (CLANGxx and/or XCODExx
specific parts), because they could inherit my GCC-oriented changes that
I never meant for CLANGxx and/or XCODExx.

I don't use XCODE or CLANG, I don't test on them, and now it seems I can
restrict changes to the *actual* gcc compilers only if I keep spelling
out the individual toolchain names, such as GCC48, GCC49, GCC5.

This makes the toolchain family concept totally useless to me (and to
other users that only care about actual gcc compilers). There is no
*family* facility available that allows people to restrict settings to
actual gcc compilers. In other words, we can't express "all GCCxx
toolchains, regardless of toolchain version, but not XCODE, and also not
CLANG".

Thanks
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48658): https://edk2.groups.io/g/devel/message/48658
Mute This Topic: https://groups.io/mt/34309064/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] Patch for Bug 2236 on Bugzilla

2019-10-09 Thread Liming Gao

Kenji:
 Please use git format-patch -1 to generate the patch, then use git send-email 
xxx.patch to send this patch to 
devel@edk2.groups.io

  Besides, is there the track in edk2 https://bugzilla.tianocore.org/? If no, 
can you submit one?

Thanks
Liming
From: devel@edk2.groups.io  On Behalf Of Chen, Kenji
Sent: Wednesday, October 9, 2019 4:00 PM
To: devel@edk2.groups.io
Subject: [edk2-devel] Patch for Bug 2236 on Bugzilla

Commit Message:

FmpDevicePkg: Deferred LSV Commit after Platform Health Check

- LSV variable in each FmpDevice is updated after each successful FmpSetImage 
invocation. This blocks the deferred SVN mechanism performed by platfor side. 
Add a PCD to remove it to make platform code feasible to handle the mechanism 
of deferred LSV commit.
- Add FmpDevieSetImageEx function to delivr LsvUpdate parameter for 
FmpDeviceSetImage function. The value is from Fmp capsule image header to 
indicate platform side this is a LSV update.


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48657): https://edk2.groups.io/g/devel/message/48657
Mute This Topic: https://groups.io/mt/34461090/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 2/6] Maintainers.txt: drop ',' from maintainer names

2019-10-09 Thread Philippe Mathieu-Daudé


On 10/9/19 3:16 PM, Leif Lindholm wrote:

On Wed, Oct 09, 2019 at 02:53:34PM +0200, Philippe Mathieu-Daudé wrote:

On 10/9/19 2:00 PM, Leif Lindholm wrote:

The ',' character, when used in the name part of email addresses,
must be escaped. Not doing so leads to all kinds of fun with SMTP.
So rework all M: entries containing a , to not do so.


Oh, good tip!


Cc: Ard Bieshuevel 
Cc: Michael D Kinney 
Signed-off-by: Leif Lindholm 
---
   Maintainers.txt | 18 +-
   1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index f824e2b05de1..1d27dde741f0 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -172,19 +172,19 @@ M: Michael Kubacki 
   M: Sai Chaganty 
   Silicon/Intel/LewisburgPkg
-M: Piwko, Maciej 
-M: Bu, Daocheng 
-M: Oram, Isaac W 
+M: Maciej Piwko


Name [space]  ?


Huh, yeah, as previously mentioned...
OK to fold in?


Sure:
Reviewed-by: Philippe Mathieu-Daude 


+M: Daocheng Bu 
+M: Isaac W Oram 
   Silicon/Intel/PurleyRcPkg
-M: Gillispie, Thad 
-M: Bu, Daocheng 
-M: Oram, Isaac W 
+M: Thad Gillispie 
+M: Daocheng Bu 
+M: Isaac W Oram 
   Silicon/Intel/PurleySktPkg
-M: Gillispie, Thad 
-M: Bu, Daocheng 
-M: Oram, Isaac W 
+M: Thad Gillispie 
+M: Daocheng Bu 
+M: Isaac W Oram 
   Silicon/Intel/SimicsX58SktPkg
   M: Wei David Y 






-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48656): https://edk2.groups.io/g/devel/message/48656
Mute This Topic: https://groups.io/mt/34462373/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 4/6] Maintainers.txt: merge Marvell platforms and silicon sections

2019-10-09 Thread Marcin Wojtas

Hi Leif,

śr., 9 paź 2019 o 14:00 Leif Lindholm  napisał(a):
>
> Cc: Marcin Wojtas 
> Signed-off-by: Leif Lindholm 
> ---
>  Maintainers.txt | 14 --
>  1 file changed, 4 insertions(+), 10 deletions(-)
>
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 43803592d369..56b12dd79c3f 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -160,15 +160,6 @@ F: Platform/Intel/Tools/
>  M: Bob Feng 
>  M: Liming Gao 
>
> -Platform/Marvell
> -F; Platform/Marvell/
> -R: Marcin Wojtas 
> -M: Leif Lindholm 
> -
> -Platform/SolidRun/Armada80x0McBin
> -F: Platform/SolidRun/Armada80x0McBin/
> -R: Marcin Wojtas 
> -
>  Silicon/Intel/IntelSiliconPkg
>  F: Silicon/Intel/IntelSiliconPkg/
>  M: Ray Ni 
> @@ -229,6 +220,9 @@ F: Silicon/Intel/Tools/
>  M: Bob Feng 
>  M: Liming Gao 
>
> -Silicon/Marvell
> +Marvell platforms and silicon
> +F; Platform/Marvell/
> +F: Platform/SolidRun/Armada80x0McBin/
>  F: Silicon/Marvell/
>  R: Marcin Wojtas 
> +M: Leif Lindholm 
> --
> 2.20.1
>

Ok for me, so:
Reviewed-by: Marcin Wojtas 

Thanks,
Marcin

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48655): https://edk2.groups.io/g/devel/message/48655
Mute This Topic: https://groups.io/mt/34462376/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 2/6] Maintainers.txt: drop ',' from maintainer names

2019-10-09 Thread Leif Lindholm

On Wed, Oct 09, 2019 at 02:53:34PM +0200, Philippe Mathieu-Daudé wrote:
> On 10/9/19 2:00 PM, Leif Lindholm wrote:
> > The ',' character, when used in the name part of email addresses,
> > must be escaped. Not doing so leads to all kinds of fun with SMTP.
> > So rework all M: entries containing a , to not do so.
> 
> Oh, good tip!
> 
> > Cc: Ard Bieshuevel 
> > Cc: Michael D Kinney 
> > Signed-off-by: Leif Lindholm 
> > ---
> >   Maintainers.txt | 18 +-
> >   1 file changed, 9 insertions(+), 9 deletions(-)
> > 
> > diff --git a/Maintainers.txt b/Maintainers.txt
> > index f824e2b05de1..1d27dde741f0 100644
> > --- a/Maintainers.txt
> > +++ b/Maintainers.txt
> > @@ -172,19 +172,19 @@ M: Michael Kubacki 
> >   M: Sai Chaganty 
> >   Silicon/Intel/LewisburgPkg
> > -M: Piwko, Maciej 
> > -M: Bu, Daocheng 
> > -M: Oram, Isaac W 
> > +M: Maciej Piwko
> 
> Name [space]  ?

Huh, yeah, as previously mentioned...
OK to fold in?

> > +M: Daocheng Bu 
> > +M: Isaac W Oram 
> >   Silicon/Intel/PurleyRcPkg
> > -M: Gillispie, Thad 
> > -M: Bu, Daocheng 
> > -M: Oram, Isaac W 
> > +M: Thad Gillispie 
> > +M: Daocheng Bu 
> > +M: Isaac W Oram 
> >   Silicon/Intel/PurleySktPkg
> > -M: Gillispie, Thad 
> > -M: Bu, Daocheng 
> > -M: Oram, Isaac W 
> > +M: Thad Gillispie 
> > +M: Daocheng Bu 
> > +M: Isaac W Oram 
> >   Silicon/Intel/SimicsX58SktPkg
> >   M: Wei David Y 
> > 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48654): https://edk2.groups.io/g/devel/message/48654
Mute This Topic: https://groups.io/mt/34462373/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 1/6] Maintainers.txt: Update documentation for new format

2019-10-09 Thread Philippe Mathieu-Daudé


On 10/9/19 2:54 PM, Leif Lindholm wrote:

On Wed, Oct 09, 2019 at 02:51:38PM +0200, Philippe Mathieu-Daudé wrote:

On 10/9/19 2:00 PM, Leif Lindholm wrote:

Synchronize header with edk2/Maintainers.txt and change references
from "EDK II to EDK II Platforms".

Cc: Ard Biesheuvel 
Cc: Michael D Kinney 
Signed-off-by: Leif Lindholm 
---
   Maintainers.txt | 42 +-
   1 file changed, 33 insertions(+), 9 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 1260c8d2465b..f824e2b05de1 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -1,17 +1,24 @@
-EDK II Maintainers
-==
+EDK II Platforms Maintainers
+
   This file provides information about the primary maintainers for
-EDK II Platforms.
+EDK Platforms II.


This one looks odd :)


I might have been getting a bit cross-eyed at this point.


8)

No need to respin the series IMO, so once fixed:
Reviewed-by: Philippe Mathieu-Daude 



Thanks!

/
 Leif


   In general, you should not privately email the maintainer. You should
-email the edk2-devel list, but you can also Cc the maintainer.
+email the edk2-devel list, and Cc the package maintainers and
+reviewers.
+
+If the package maintainer wants to hand over the role to other people,
+the package maintainer should send the patch to update Maintainers.txt
+with new maintainer, and the new maintainer should follow up with
+an Acked-by or a Reviewed-by.
   Descriptions of section entries:
 L: Mailing list that is relevant to this area (default is edk2-devel)
Patches and questions should be sent to the email list.
-  M: Cc address for patches and questions (ie, the package maintainer)
+  M: Package Maintainer: Cc address for patches and questions. Responsible
+ for reviewing and pushing package changes to source control.
 R: Package Reviewer: Cc address for patches and questions. Reviewers help
maintainers review code, but don't have push access. A designated 
Package
Reviewer is reasonably familiar with the Package (or some modules
@@ -29,9 +36,26 @@ Descriptions of section entries:
Obsolete:   Old code. Something tagged obsolete generally means
it has been replaced by a better system and you
should be using that.
+  F: Files and directories with wildcard patterns.
+ A trailing slash includes all files and subdirectory files.
+ F:   MdeModulePkg/   all files in and below MdeModulePkg
+ F:   MdeModulePkg/*  all files in MdeModulePkg, but not below
+ F:   */Pci/* all files in a directory called Pci, at any depth in
+  the hierarchy, but not below
+ One pattern per line.  Multiple F: lines per section acceptable.
+  X: Files and directories that are NOT maintained, same rules as F:
+ Files exclusions are tested after file matches.
+ Can be useful for excluding a specific subdirectory, for instance:
+ F:   NetworkPkg/
+ X:   NetworkPkg/Ip6Dxe/
+ matches all files in and below NetworkPkg excluding NetworkPkg/Ip6Dxe/
+  Filenames not caught by any F: rule get matched as being located in the top-
+  level directory. (Internally, the script looks for a match called 
'',
+  so please don't add a file called that in the top-level directory.)
-EDK II
---
+
+EDK II Platforms
+
   W: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II
   L: https://edk2.groups.io/g/devel/
   T: git - https://github.com/tianocore/edk2-platforms.git
@@ -40,8 +64,8 @@ Responsible Disclosure, Reporting Security Issues
   -
   W: https://github.com/tianocore/tianocore.github.io/wiki/Security
-EDK II Packages:
-
+EDK II Platforms Packages:
+--
   Drivers/OptionRomPkg
   W: https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg













-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48653): https://edk2.groups.io/g/devel/message/48653
Mute This Topic: https://groups.io/mt/34462372/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 5/6] Maintainers.txt: create explicit sections for remaining modules

2019-10-09 Thread Philippe Mathieu-Daudé


On 10/9/19 2:00 PM, Leif Lindholm wrote:

Many of the original (ARM) platforms, and drivers brought in for them,
had no explicit maintainership defined. Add entries for these, roughly
corresponding to how they have already been handled in the past.

Cc: Ard Bieshuevel 
Cc: Michael D Kinney 
Signed-off-by: Leif Lindholm 
---
  Maintainers.txt | 56 +
  1 file changed, 56 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index 56b12dd79c3f..ebb878e22ac4 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -79,6 +79,35 @@ W: 
https://github.com/tianocore/tianocore.github.io/wiki/Security
  EDK II Platforms Packages:
  --
  
+96Boards

+F: Platform/96Boards/
+M: Ard Bieshuevel 
+M: Leif Lindholm 
+
+AMD Seattle
+F: Platform/AMD/OverdriveBoard/
+F: Platform/LeMaker/CelloBoard/
+F: Platform/SoftIron/
+F: Silicon/AMD/Styx/
+M: Ard Bieshuevel 
+M: Leif Lindholm 
+
+ARM
+F: Platform/ARM/
+R: Ard Bieshuevel 
+M: Leif Lindholm 
+
+BeagleBoard:
+F: Platform/BeagleBoard/
+F: Silicon/TexasInstruments/
+R: Ard Bieshuevel 
+M: Leif Lindholm 
+
+Comcast
+F: Platform/Comcast/
+M: Ard Bieshuevel 
+M: Leif Lindholm 
+
  OptionRomPkg
  F: Drivers/OptionRomPkg/
  W: https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg
@@ -90,6 +119,12 @@ M: Leif Lindholm 
  M: Ard Bieshuevel 
  R: Andy Hayes 
  
+HiSilicon

+F: Platform/Hisilicon/
+F: Silicon/Hisilicon/
+M: Leif Lindholm 
+R: Ard Bieshuevel 
+
  Platform/Intel/QuarkPlatformPkg
  F: Platform/Intel/QuarkPlatformPkg/
  M: Michael D Kinney 
@@ -226,3 +261,24 @@ F: Platform/SolidRun/Armada80x0McBin/
  F: Silicon/Marvell/
  R: Marcin Wojtas 
  M: Leif Lindholm 
+
+Miscellaneous drivers
+F: Silicon/Atmel/
+F: Silicon/NXP/
+F: Silicon/Openmoko/
+F: Silicon/Synopsys/DesignWare/
+R: Ard Bieshuevel 
+M: Leif Lindholm 
+
+Raspberry Pi platforms and silicon
+F: Platform/RaspberryPi/
+F: Silicon/Broadcom/
+M: Ard Bieshuevel 
+M: Leif Lindholm 
+R: Pete Batard 
+
+Socionext platforms and silicon
+F: Platform/Socionext/
+F: Silicon/Socionext/
+M: Ard Bieshuevel 
+M: Leif Lindholm 



FWIW:
Reviewed-by: Philippe Mathieu-Daude 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48652): https://edk2.groups.io/g/devel/message/48652
Mute This Topic: https://groups.io/mt/34462377/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 4/6] Maintainers.txt: merge Marvell platforms and silicon sections

2019-10-09 Thread Philippe Mathieu-Daudé


On 10/9/19 2:00 PM, Leif Lindholm wrote:

Cc: Marcin Wojtas 
Signed-off-by: Leif Lindholm 
---
  Maintainers.txt | 14 --
  1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 43803592d369..56b12dd79c3f 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -160,15 +160,6 @@ F: Platform/Intel/Tools/
  M: Bob Feng 
  M: Liming Gao 
  
-Platform/Marvell

-F; Platform/Marvell/
-R: Marcin Wojtas 
-M: Leif Lindholm 
-
-Platform/SolidRun/Armada80x0McBin
-F: Platform/SolidRun/Armada80x0McBin/
-R: Marcin Wojtas 
-
  Silicon/Intel/IntelSiliconPkg
  F: Silicon/Intel/IntelSiliconPkg/
  M: Ray Ni 
@@ -229,6 +220,9 @@ F: Silicon/Intel/Tools/
  M: Bob Feng 
  M: Liming Gao 
  
-Silicon/Marvell

+Marvell platforms and silicon
+F; Platform/Marvell/
+F: Platform/SolidRun/Armada80x0McBin/
  F: Silicon/Marvell/
  R: Marcin Wojtas 
+M: Leif Lindholm 



Reviewed-by: Philippe Mathieu-Daude 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48651): https://edk2.groups.io/g/devel/message/48651
Mute This Topic: https://groups.io/mt/34462376/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 1/6] Maintainers.txt: Update documentation for new format

2019-10-09 Thread Leif Lindholm

On Wed, Oct 09, 2019 at 02:51:38PM +0200, Philippe Mathieu-Daudé wrote:
> On 10/9/19 2:00 PM, Leif Lindholm wrote:
> > Synchronize header with edk2/Maintainers.txt and change references
> > from "EDK II to EDK II Platforms".
> > 
> > Cc: Ard Biesheuvel 
> > Cc: Michael D Kinney 
> > Signed-off-by: Leif Lindholm 
> > ---
> >   Maintainers.txt | 42 +-
> >   1 file changed, 33 insertions(+), 9 deletions(-)
> > 
> > diff --git a/Maintainers.txt b/Maintainers.txt
> > index 1260c8d2465b..f824e2b05de1 100644
> > --- a/Maintainers.txt
> > +++ b/Maintainers.txt
> > @@ -1,17 +1,24 @@
> > -EDK II Maintainers
> > -==
> > +EDK II Platforms Maintainers
> > +
> >   This file provides information about the primary maintainers for
> > -EDK II Platforms.
> > +EDK Platforms II.
> 
> This one looks odd :)

I might have been getting a bit cross-eyed at this point.

Thanks!

/
Leif

> >   In general, you should not privately email the maintainer. You should
> > -email the edk2-devel list, but you can also Cc the maintainer.
> > +email the edk2-devel list, and Cc the package maintainers and
> > +reviewers.
> > +
> > +If the package maintainer wants to hand over the role to other people,
> > +the package maintainer should send the patch to update Maintainers.txt
> > +with new maintainer, and the new maintainer should follow up with
> > +an Acked-by or a Reviewed-by.
> >   Descriptions of section entries:
> > L: Mailing list that is relevant to this area (default is edk2-devel)
> >Patches and questions should be sent to the email list.
> > -  M: Cc address for patches and questions (ie, the package maintainer)
> > +  M: Package Maintainer: Cc address for patches and questions. Responsible
> > + for reviewing and pushing package changes to source control.
> > R: Package Reviewer: Cc address for patches and questions. Reviewers 
> > help
> >maintainers review code, but don't have push access. A designated 
> > Package
> >Reviewer is reasonably familiar with the Package (or some modules
> > @@ -29,9 +36,26 @@ Descriptions of section entries:
> >Obsolete:   Old code. Something tagged obsolete generally means
> >it has been replaced by a better system and you
> >should be using that.
> > +  F: Files and directories with wildcard patterns.
> > + A trailing slash includes all files and subdirectory files.
> > + F:   MdeModulePkg/   all files in and below MdeModulePkg
> > + F:   MdeModulePkg/*  all files in MdeModulePkg, but not below
> > + F:   */Pci/* all files in a directory called Pci, at any 
> > depth in
> > +  the hierarchy, but not below
> > + One pattern per line.  Multiple F: lines per section acceptable.
> > +  X: Files and directories that are NOT maintained, same rules as F:
> > + Files exclusions are tested after file matches.
> > + Can be useful for excluding a specific subdirectory, for instance:
> > + F:   NetworkPkg/
> > + X:   NetworkPkg/Ip6Dxe/
> > + matches all files in and below NetworkPkg excluding NetworkPkg/Ip6Dxe/
> > +  Filenames not caught by any F: rule get matched as being located in the 
> > top-
> > +  level directory. (Internally, the script looks for a match called 
> > '',
> > +  so please don't add a file called that in the top-level directory.)
> > -EDK II
> > ---
> > +
> > +EDK II Platforms
> > +
> >   W: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II
> >   L: https://edk2.groups.io/g/devel/
> >   T: git - https://github.com/tianocore/edk2-platforms.git
> > @@ -40,8 +64,8 @@ Responsible Disclosure, Reporting Security Issues
> >   -
> >   W: https://github.com/tianocore/tianocore.github.io/wiki/Security
> > -EDK II Packages:
> > -
> > +EDK II Platforms Packages:
> > +--
> >   Drivers/OptionRomPkg
> >   W: https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg
> > 
> 
> 
> 
> 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48650): https://edk2.groups.io/g/devel/message/48650
Mute This Topic: https://groups.io/mt/34462372/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 2/6] Maintainers.txt: drop ',' from maintainer names

2019-10-09 Thread Philippe Mathieu-Daudé


On 10/9/19 2:00 PM, Leif Lindholm wrote:

The ',' character, when used in the name part of email addresses,
must be escaped. Not doing so leads to all kinds of fun with SMTP.
So rework all M: entries containing a , to not do so.


Oh, good tip!


Cc: Ard Bieshuevel 
Cc: Michael D Kinney 
Signed-off-by: Leif Lindholm 
---
  Maintainers.txt | 18 +-
  1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index f824e2b05de1..1d27dde741f0 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -172,19 +172,19 @@ M: Michael Kubacki 
  M: Sai Chaganty 
  
  Silicon/Intel/LewisburgPkg

-M: Piwko, Maciej 
-M: Bu, Daocheng 
-M: Oram, Isaac W 
+M: Maciej Piwko


Name [space]  ?


+M: Daocheng Bu 
+M: Isaac W Oram 
  
  Silicon/Intel/PurleyRcPkg

-M: Gillispie, Thad 
-M: Bu, Daocheng 
-M: Oram, Isaac W 
+M: Thad Gillispie 
+M: Daocheng Bu 
+M: Isaac W Oram 
  
  Silicon/Intel/PurleySktPkg

-M: Gillispie, Thad 
-M: Bu, Daocheng 
-M: Oram, Isaac W 
+M: Thad Gillispie 
+M: Daocheng Bu 
+M: Isaac W Oram 
  
  Silicon/Intel/SimicsX58SktPkg

  M: Wei David Y 




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48649): https://edk2.groups.io/g/devel/message/48649
Mute This Topic: https://groups.io/mt/34462373/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 1/6] Maintainers.txt: Update documentation for new format

2019-10-09 Thread Philippe Mathieu-Daudé


On 10/9/19 2:00 PM, Leif Lindholm wrote:

Synchronize header with edk2/Maintainers.txt and change references
from "EDK II to EDK II Platforms".

Cc: Ard Biesheuvel 
Cc: Michael D Kinney 
Signed-off-by: Leif Lindholm 
---
  Maintainers.txt | 42 +-
  1 file changed, 33 insertions(+), 9 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 1260c8d2465b..f824e2b05de1 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -1,17 +1,24 @@
-EDK II Maintainers
-==
+EDK II Platforms Maintainers
+
  
  This file provides information about the primary maintainers for

-EDK II Platforms.
+EDK Platforms II.


This one looks odd :)


  In general, you should not privately email the maintainer. You should
-email the edk2-devel list, but you can also Cc the maintainer.
+email the edk2-devel list, and Cc the package maintainers and
+reviewers.
+
+If the package maintainer wants to hand over the role to other people,
+the package maintainer should send the patch to update Maintainers.txt
+with new maintainer, and the new maintainer should follow up with
+an Acked-by or a Reviewed-by.
  
  Descriptions of section entries:
  
L: Mailing list that is relevant to this area (default is edk2-devel)

   Patches and questions should be sent to the email list.
-  M: Cc address for patches and questions (ie, the package maintainer)
+  M: Package Maintainer: Cc address for patches and questions. Responsible
+ for reviewing and pushing package changes to source control.
R: Package Reviewer: Cc address for patches and questions. Reviewers help
   maintainers review code, but don't have push access. A designated Package
   Reviewer is reasonably familiar with the Package (or some modules
@@ -29,9 +36,26 @@ Descriptions of section entries:
   Obsolete:   Old code. Something tagged obsolete generally means
   it has been replaced by a better system and you
   should be using that.
+  F: Files and directories with wildcard patterns.
+ A trailing slash includes all files and subdirectory files.
+ F:   MdeModulePkg/   all files in and below MdeModulePkg
+ F:   MdeModulePkg/*  all files in MdeModulePkg, but not below
+ F:   */Pci/* all files in a directory called Pci, at any depth in
+  the hierarchy, but not below
+ One pattern per line.  Multiple F: lines per section acceptable.
+  X: Files and directories that are NOT maintained, same rules as F:
+ Files exclusions are tested after file matches.
+ Can be useful for excluding a specific subdirectory, for instance:
+ F:   NetworkPkg/
+ X:   NetworkPkg/Ip6Dxe/
+ matches all files in and below NetworkPkg excluding NetworkPkg/Ip6Dxe/
+  Filenames not caught by any F: rule get matched as being located in the top-
+  level directory. (Internally, the script looks for a match called 
'',
+  so please don't add a file called that in the top-level directory.)
  
-EDK II

---
+
+EDK II Platforms
+
  W: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II
  L: https://edk2.groups.io/g/devel/
  T: git - https://github.com/tianocore/edk2-platforms.git
@@ -40,8 +64,8 @@ Responsible Disclosure, Reporting Security Issues
  -
  W: https://github.com/tianocore/tianocore.github.io/wiki/Security
  
-EDK II Packages:

-
+EDK II Platforms Packages:
+--
  
  Drivers/OptionRomPkg

  W: https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48648): https://edk2.groups.io/g/devel/message/48648
Mute This Topic: https://groups.io/mt/34462372/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 3/6] Maintainers.txt: revamp file to machine-readable format

2019-10-09 Thread Leif Lindholm

On Wed, Oct 09, 2019 at 02:31:21PM +0200, Ard Biesheuvel wrote:
> On Wed, 9 Oct 2019 at 14:00, Leif Lindholm  wrote:
> >
> > Convert existing package maintainer/reviewer descriptions
> > with adding the new path definitions.
> >
> > Delete the "Platform" and "Silicon" section maintainership
> > descriptions. The EDK II Platforms maintainers section will
> > now match that.
> >
> > Cc: Ard Biesheuvel 
> > Cc: Michael D Kinney 
> > Signed-off-by: Leif Lindholm 
> > ---
> >  Maintainers.txt | 56 ++---
> >  1 file changed, 44 insertions(+), 12 deletions(-)
> >
> > diff --git a/Maintainers.txt b/Maintainers.txt
> > index 1d27dde741f0..43803592d369 100644
> > --- a/Maintainers.txt
> > +++ b/Maintainers.txt
> > @@ -60,6 +60,18 @@ W: 
> > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II
> >  L: https://edk2.groups.io/g/devel/
> >  T: git - https://github.com/tianocore/edk2-platforms.git
> >
> > +All patches CC:d here
> > +L: devel@edk2.groups.io
> > +F: *
> > +F: */
> > +
> > +EDK II Platforms maintainers
> > +
> > +F: *
> > +M: Ard Bieshuevel 
> 
> Typo here ^^
> 
> Not a big deal since you are removing this line again in the last
> patch, but I thought I'd mention it nonetheless

Yeah, I'll fix that before pushing, or a v2.

Thanks!

/
Leif

> > +M: Leif Lindholm 
> > +M: Michael D Kinney 
> > +
> >  Responsible Disclosure, Reporting Security Issues
> >  -
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/Security
> > @@ -67,136 +79,156 @@ W: 
> > https://github.com/tianocore/tianocore.github.io/wiki/Security
> >  EDK II Platforms Packages:
> >  --
> >
> > -Drivers/OptionRomPkg
> > +OptionRomPkg
> > +F: Drivers/OptionRomPkg/
> >  W: https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg
> >  M: Ray Ni 
> >
> > -Drivers/DisplayLink
> > +DisplayLink
> > +F: Drivers/DisplayLink/
> >  M: Leif Lindholm 
> >  M: Ard Bieshuevel 
> >  R: Andy Hayes 
> >
> > -Platform
> > -M: Ard Biesheuvel 
> > -M: Leif Lindholm 
> > -M: Michael D Kinney 
> > -
> >  Platform/Intel/QuarkPlatformPkg
> > +F: Platform/Intel/QuarkPlatformPkg/
> >  M: Michael D Kinney 
> >  M: Kelly Steele 
> >
> >  Platform/Intel/Vlv2TbltDevicePkg
> > +F: Platform/Intel/Vlv2TbltDevicePkg/
> >  M: Zailiang Sun 
> >  M: Yi Qian 
> >
> >  Platform/Intel/AdvancedFeaturePkg
> > +F: Platform/Intel/AdvancedFeaturePkg/
> >  M: Michael Kubacki 
> >  M: Sai Chaganty 
> >  R: Liming Gao 
> >
> >  Platform/Intel/BoardModulePkg
> > +F: Platform/Intel/BoardModulePkg/
> >  M: Eric Dong 
> >  R: Liming Gao 
> >
> >  Platform/Intel/DebugFeaturePkg
> > +F: Platform/Intel/DebugFeaturePkg/
> >  M: Eric Dong 
> >  R: Liming Gao 
> >
> >  Platform/Intel/UserInterfaceFeaturePkg
> > +F: Platform/Intel/UserInterfaceFeaturePkg/
> >  M: Dandan Bi 
> >  R: Liming Gao 
> >
> >  Platform/Intel/KabylakeOpenBoardPkg
> > +F: Platform/Intel/KabylakeOpenBoardPkg/
> >  M: Chasel Chiu 
> >  M: Michael Kubacki 
> >  M: Nate DeSimone 
> >
> >  Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3
> > +F: Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/
> >  R: Jeremy Soller 
> >
> >  Platform/Intel/MinPlatformPkg
> > +F: Platform/Intel/MinPlatformPkg/
> >  M: Michael Kubacki 
> >  M: Chasel Chiu 
> >  M: Nate DeSimone 
> >  R: Liming Gao 
> >
> >  Platform/Intel/PurleyOpenBoardPkg
> > +F: Platform/Intel/PurleyOpenBoardPkg/
> >  M: Shifei A Lu 
> >  M: Xiaohu Zhou 
> >  M: Isaac W Oram 
> >
> >  Platform/Intel/WhiskeylakeOpenBoardPkg
> > +F: Platform/Intel/WhiskeylakeOpenBoardPkg/
> >  M: Chasel Chiu 
> >  M: Michael Kubacki 
> >  M: Nate DeSimone 
> >
> >  Platform/Intel/SimicsOpenBoardPkg
> > +F: Platform/Intel/SimicsOpenBoardPkg/
> >  M: Wei David Y 
> >  M: Agyeman Prince 
> >
> >  Platform/Intel/Tools
> > +F: Platform/Intel/Tools/
> >  M: Bob Feng 
> >  M: Liming Gao 
> >
> >  Platform/Marvell
> > +F; Platform/Marvell/
> >  R: Marcin Wojtas 
> > +M: Leif Lindholm 
> >
> >  Platform/SolidRun/Armada80x0McBin
> > +F: Platform/SolidRun/Armada80x0McBin/
> >  R: Marcin Wojtas 
> >
> > -Silicon
> > -M: Ard Biesheuvel 
> > -M: Leif Lindholm 
> > -M: Michael D Kinney 
> > -
> >  Silicon/Intel/IntelSiliconPkg
> > +F: Silicon/Intel/IntelSiliconPkg/
> >  M: Ray Ni 
> >  M: Rangasai V Chaganty 
> >
> >  Silicon/Intel/QuarkSocPkg
> > +F: Silicon/Intel/QuarkSocPkg/
> >  M: Michael D Kinney 
> >  M: Kelly Steele 
> >
> >  Silicon/Intel/Vlv2DeviceRefCodePkg
> > +F: Silicon/Intel/Vlv2DeviceRefCodePkg/
> >  M: Zailiang Sun 
> >  M: Yi Qian 
> >
> >  Silicon/Intel/CoffeelakeSiliconPkg
> > +F: Silicon/Intel/CoffeelakeSiliconPkg/
> >  M: Chasel Chiu 
> >  M: Michael Kubacki 
> >  M: Sai Chaganty 
> >
> >  Silicon/Intel/KabylakeSiliconPkg
> > +F: Silicon/Intel/KabylakeSiliconPkg/
> >  M: Chasel Chiu 
> >  M: Michael Kubacki 
> >  M: Sai Chaganty 
> >
> >  Silicon/Intel/LewisburgPkg
> > +F: Silicon/Intel/LewisburgPkg/
> >  M: Maciej Piwko
> >

Re: [edk2-devel] [PATCH edk2-platforms 0/6] Update Maintainers.txt

2019-10-09 Thread Leif Lindholm

On Wed, Oct 09, 2019 at 02:32:37PM +0200, Ard Biesheuvel wrote:
> On Wed, 9 Oct 2019 at 14:00, Leif Lindholm  wrote:
> >
> > This set does a few things:
> > - Imports the documentation header from edk2/Maintainers.txt
> > - Reformats some maintainer entries to get rid of ',' characters
> >   in the names.
> > - Adds F: entries for all sections, and a default fallback section
> >   for those where there is no match.
> > - Merges the Marvell sections (designed to work with this format)
> >   into a single area of responsibility.
> > - Adds sections for those that now ended up having none other than
> >   the fallback one (mostly ARM platforms).
> > - Remove Ard from the default section.
> >
> > I am intentionally not Cc:ing all affected maintainers, since this
> > is a reformatting exercise. All roles actually affected are Cc:d.
> >
> > Cc: Ard Bieshuevel 
> 
> Typo here ^^^
> 
> ... but I'm sure the Google mail robot has informed you by now? :-)

Many times...
Funny thing is, I didn't type out a single address - I copy-pasted it
from the GetMaintainers.py output (from another window where I was
going through the whitespace fixups, using the script to get at it).

Turns out your name/address was always wrong in
https://github.com/tianocore/edk2-platforms/blob/master/Maintainers.txt#L52
:)

Gosh hecking darnit!

> In any case, for the series (modulo the typoes)
> 
> Acked-by: Ard Bieshulevl 

Don't tempt me.

(Thanks!)

> 
> > Cc: Marcin Wojtas 
> > Cc: Michael D Kinney 
> >
> > Leif Lindholm (6):
> >   Maintainers.txt: Update documentation for new format
> >   Maintainers.txt: drop ',' from maintainer names
> >   Maintainers.txt: revamp file to machine-readable format
> >   Maintainers.txt: merge Marvell platforms and silicon sections
> >   Maintainers.txt: create explicit sections for remaining modules
> >   Maintainers.txt: drop Ard from default section
> >
> >  Maintainers.txt | 175 ++--
> >  1 file changed, 140 insertions(+), 35 deletions(-)
> >
> > --
> > 2.20.1
> >

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48646): https://edk2.groups.io/g/devel/message/48646
Mute This Topic: https://groups.io/mt/34462371/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 0/6] Update Maintainers.txt

2019-10-09 Thread Ard Biesheuvel

On Wed, 9 Oct 2019 at 14:00, Leif Lindholm  wrote:
>
> This set does a few things:
> - Imports the documentation header from edk2/Maintainers.txt
> - Reformats some maintainer entries to get rid of ',' characters
>   in the names.
> - Adds F: entries for all sections, and a default fallback section
>   for those where there is no match.
> - Merges the Marvell sections (designed to work with this format)
>   into a single area of responsibility.
> - Adds sections for those that now ended up having none other than
>   the fallback one (mostly ARM platforms).
> - Remove Ard from the default section.
>
> I am intentionally not Cc:ing all affected maintainers, since this
> is a reformatting exercise. All roles actually affected are Cc:d.
>
> Cc: Ard Bieshuevel 

Typo here ^^^

... but I'm sure the Google mail robot has informed you by now? :-)

In any case, for the series (modulo the typoes)

Acked-by: Ard Bieshulevl 


> Cc: Marcin Wojtas 
> Cc: Michael D Kinney 
>
> Leif Lindholm (6):
>   Maintainers.txt: Update documentation for new format
>   Maintainers.txt: drop ',' from maintainer names
>   Maintainers.txt: revamp file to machine-readable format
>   Maintainers.txt: merge Marvell platforms and silicon sections
>   Maintainers.txt: create explicit sections for remaining modules
>   Maintainers.txt: drop Ard from default section
>
>  Maintainers.txt | 175 ++--
>  1 file changed, 140 insertions(+), 35 deletions(-)
>
> --
> 2.20.1
>

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48645): https://edk2.groups.io/g/devel/message/48645
Mute This Topic: https://groups.io/mt/34462371/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH edk2-platforms 3/6] Maintainers.txt: revamp file to machine-readable format

2019-10-09 Thread Ard Biesheuvel

On Wed, 9 Oct 2019 at 14:00, Leif Lindholm  wrote:
>
> Convert existing package maintainer/reviewer descriptions
> with adding the new path definitions.
>
> Delete the "Platform" and "Silicon" section maintainership
> descriptions. The EDK II Platforms maintainers section will
> now match that.
>
> Cc: Ard Biesheuvel 
> Cc: Michael D Kinney 
> Signed-off-by: Leif Lindholm 
> ---
>  Maintainers.txt | 56 ++---
>  1 file changed, 44 insertions(+), 12 deletions(-)
>
> diff --git a/Maintainers.txt b/Maintainers.txt
> index 1d27dde741f0..43803592d369 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -60,6 +60,18 @@ W: 
> https://github.com/tianocore/tianocore.github.io/wiki/EDK-II
>  L: https://edk2.groups.io/g/devel/
>  T: git - https://github.com/tianocore/edk2-platforms.git
>
> +All patches CC:d here
> +L: devel@edk2.groups.io
> +F: *
> +F: */
> +
> +EDK II Platforms maintainers
> +
> +F: *
> +M: Ard Bieshuevel 

Typo here ^^

Not a big deal since you are removing this line again in the last
patch, but I thought I'd mention it nonetheless


> +M: Leif Lindholm 
> +M: Michael D Kinney 
> +
>  Responsible Disclosure, Reporting Security Issues
>  -
>  W: https://github.com/tianocore/tianocore.github.io/wiki/Security
> @@ -67,136 +79,156 @@ W: 
> https://github.com/tianocore/tianocore.github.io/wiki/Security
>  EDK II Platforms Packages:
>  --
>
> -Drivers/OptionRomPkg
> +OptionRomPkg
> +F: Drivers/OptionRomPkg/
>  W: https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg
>  M: Ray Ni 
>
> -Drivers/DisplayLink
> +DisplayLink
> +F: Drivers/DisplayLink/
>  M: Leif Lindholm 
>  M: Ard Bieshuevel 
>  R: Andy Hayes 
>
> -Platform
> -M: Ard Biesheuvel 
> -M: Leif Lindholm 
> -M: Michael D Kinney 
> -
>  Platform/Intel/QuarkPlatformPkg
> +F: Platform/Intel/QuarkPlatformPkg/
>  M: Michael D Kinney 
>  M: Kelly Steele 
>
>  Platform/Intel/Vlv2TbltDevicePkg
> +F: Platform/Intel/Vlv2TbltDevicePkg/
>  M: Zailiang Sun 
>  M: Yi Qian 
>
>  Platform/Intel/AdvancedFeaturePkg
> +F: Platform/Intel/AdvancedFeaturePkg/
>  M: Michael Kubacki 
>  M: Sai Chaganty 
>  R: Liming Gao 
>
>  Platform/Intel/BoardModulePkg
> +F: Platform/Intel/BoardModulePkg/
>  M: Eric Dong 
>  R: Liming Gao 
>
>  Platform/Intel/DebugFeaturePkg
> +F: Platform/Intel/DebugFeaturePkg/
>  M: Eric Dong 
>  R: Liming Gao 
>
>  Platform/Intel/UserInterfaceFeaturePkg
> +F: Platform/Intel/UserInterfaceFeaturePkg/
>  M: Dandan Bi 
>  R: Liming Gao 
>
>  Platform/Intel/KabylakeOpenBoardPkg
> +F: Platform/Intel/KabylakeOpenBoardPkg/
>  M: Chasel Chiu 
>  M: Michael Kubacki 
>  M: Nate DeSimone 
>
>  Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3
> +F: Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/
>  R: Jeremy Soller 
>
>  Platform/Intel/MinPlatformPkg
> +F: Platform/Intel/MinPlatformPkg/
>  M: Michael Kubacki 
>  M: Chasel Chiu 
>  M: Nate DeSimone 
>  R: Liming Gao 
>
>  Platform/Intel/PurleyOpenBoardPkg
> +F: Platform/Intel/PurleyOpenBoardPkg/
>  M: Shifei A Lu 
>  M: Xiaohu Zhou 
>  M: Isaac W Oram 
>
>  Platform/Intel/WhiskeylakeOpenBoardPkg
> +F: Platform/Intel/WhiskeylakeOpenBoardPkg/
>  M: Chasel Chiu 
>  M: Michael Kubacki 
>  M: Nate DeSimone 
>
>  Platform/Intel/SimicsOpenBoardPkg
> +F: Platform/Intel/SimicsOpenBoardPkg/
>  M: Wei David Y 
>  M: Agyeman Prince 
>
>  Platform/Intel/Tools
> +F: Platform/Intel/Tools/
>  M: Bob Feng 
>  M: Liming Gao 
>
>  Platform/Marvell
> +F; Platform/Marvell/
>  R: Marcin Wojtas 
> +M: Leif Lindholm 
>
>  Platform/SolidRun/Armada80x0McBin
> +F: Platform/SolidRun/Armada80x0McBin/
>  R: Marcin Wojtas 
>
> -Silicon
> -M: Ard Biesheuvel 
> -M: Leif Lindholm 
> -M: Michael D Kinney 
> -
>  Silicon/Intel/IntelSiliconPkg
> +F: Silicon/Intel/IntelSiliconPkg/
>  M: Ray Ni 
>  M: Rangasai V Chaganty 
>
>  Silicon/Intel/QuarkSocPkg
> +F: Silicon/Intel/QuarkSocPkg/
>  M: Michael D Kinney 
>  M: Kelly Steele 
>
>  Silicon/Intel/Vlv2DeviceRefCodePkg
> +F: Silicon/Intel/Vlv2DeviceRefCodePkg/
>  M: Zailiang Sun 
>  M: Yi Qian 
>
>  Silicon/Intel/CoffeelakeSiliconPkg
> +F: Silicon/Intel/CoffeelakeSiliconPkg/
>  M: Chasel Chiu 
>  M: Michael Kubacki 
>  M: Sai Chaganty 
>
>  Silicon/Intel/KabylakeSiliconPkg
> +F: Silicon/Intel/KabylakeSiliconPkg/
>  M: Chasel Chiu 
>  M: Michael Kubacki 
>  M: Sai Chaganty 
>
>  Silicon/Intel/LewisburgPkg
> +F: Silicon/Intel/LewisburgPkg/
>  M: Maciej Piwko
>  M: Daocheng Bu 
>  M: Isaac W Oram 
>
>  Silicon/Intel/PurleyRcPkg
> +F: Silicon/Intel/PurleyRcPkg/
>  M: Thad Gillispie 
>  M: Daocheng Bu 
>  M: Isaac W Oram 
>
>  Silicon/Intel/PurleySktPkg
> +F: Silicon/Intel/PurleySktPkg/
>  M: Thad Gillispie 
>  M: Daocheng Bu 
>  M: Isaac W Oram 
>
>  Silicon/Intel/SimicsX58SktPkg
> +F: Silicon/Intel/SimicsX58SktPkg/
>  M: Wei David Y 
>  M: Agyeman Prince 
>
>  Silicon/Intel/SimicsIch10Pkg
> +F: Silicon/Intel/SimicsIch10Pkg/
>  M: Wei David Y 
>

Re: [edk2-devel] [PATCH v2 3/7] BaseTools: strip trailing whitespace

2019-10-09 Thread Leif Lindholm

Hi Mike,

This one turned out to be a bit trickier, and also it was helpful
converting Maintainers.txt in preparation, but now sent out.

Regards,

Leif

On Fri, Oct 04, 2019 at 04:01:09PM +, Kinney, Michael D wrote:
> Hi Leif,
> 
> Do you want to run the same script on the edk2-platforms
> repo?
> 
> Thanks,
> 
> Mike
> 
> > -Original Message-
> > From: devel@edk2.groups.io  On
> > Behalf Of Leif Lindholm
> > Sent: Friday, October 4, 2019 3:20 AM
> > To: Kinney, Michael D 
> > Cc: devel@edk2.groups.io; Feng, Bob C
> > ; Gao, Liming
> > 
> > Subject: Re: [edk2-devel] [PATCH v2 3/7] BaseTools:
> > strip trailing whitespace
> > 
> > Mike, others,
> > 
> > Many thanks - series pushed as
> > 61af5f249495..d19040804afb
> > 
> > /
> > Leif
> > 
> > On Thu, Oct 03, 2019 at 09:05:05PM +, Kinney,
> > Michael D wrote:
> > > Leif,
> > >
> > > Reviewed-by: Michael D Kinney
> > 
> > >
> > > I am covering for Liming and Bob this week, so you do
> > not have to wait
> > > for a review from them to push these changes.
> > >
> > > Mike
> > >
> > > > -Original Message-
> > > > From: devel@edk2.groups.io  On
> > Behalf Of Leif
> > > > Lindholm
> > > > Sent: Tuesday, October 1, 2019 5:49 AM
> > > > To: devel@edk2.groups.io
> > > > Cc: Feng, Bob C ; Gao, Liming
> > > > 
> > > > Subject: [edk2-devel] [PATCH v2 3/7] BaseTools:
> > strip trailing
> > > > whitespace
> > > >
> > > > Cc: Bob Feng 
> > > > Cc: Liming Gao 
> > > > Signed-off-by: Leif Lindholm
> > 
> > > > ---
> > > >
> > > > Resubmitting a v2 with changes to external projects:
> > > > - BrotliCompress
> > > > - LzmaCompress
> > > > - Pccts
> > > > backed out for now.
> > > >
> > > > BaseTools/Source/C/GNUmakefile
> > |
> > > > 2 +-
> > > >  BaseTools/Source/C/Makefiles/app.makefile
> > > > | 4 ++--
> > > >  BaseTools/Source/C/Makefiles/footer.makefile
> > > > | 4 ++--
> > > >  BaseTools/Source/C/Makefiles/header.makefile
> > > > | 8 
> > > >  BaseTools/Source/C/Makefiles/lib.makefile
> > > > | 2 +-
> > > >  BaseTools/Source/C/Makefiles/ms.common
> > > > | 4 ++--
> > > >  BaseTools/Source/C/VfrCompile/GNUmakefile
> > > > | 6 +++---
> > > >  BaseTools/Source/Python/Ecc/Check.py
> > > > | 2 +-
> > > >
> > BaseTools/Source/Python/GenFds/GenFdsGlobalVariable.py
> > > > | 2 +-
> > > >  BaseTools/Source/Python/Makefile
> > > > | 2 +-
> > > >  10 files changed, 18 insertions(+), 18 deletions(-)
> > > >
> > > > diff --git a/BaseTools/Source/C/GNUmakefile
> > > > b/BaseTools/Source/C/GNUmakefile index
> > 37bcce519c7e..df4eb64ea95e
> > > > 100644
> > > > --- a/BaseTools/Source/C/GNUmakefile
> > > > +++ b/BaseTools/Source/C/GNUmakefile
> > > > @@ -77,7 +77,7 @@ $(SUBDIRS):
> > > >  $(patsubst %,%-clean,$(sort $(SUBDIRS))):
> > > > -$(MAKE) -C $(@:-clean=) clean
> > > >
> > > > -$(VFRAUTOGEN): VfrCompile/VfrSyntax.g
> > > > +$(VFRAUTOGEN): VfrCompile/VfrSyntax.g
> > > > $(MAKE) -C VfrCompile VfrLexer.h
> > > >
> > > >  clean:  $(patsubst %,%-clean,$(sort $(SUBDIRS)))
> > diff - -git
> > > > a/BaseTools/Source/C/Makefiles/app.makefile
> > > > b/BaseTools/Source/C/Makefiles/app.makefile
> > > > index fcadb4ed2194..6a2a8f5e8a0e 100644
> > > > --- a/BaseTools/Source/C/Makefiles/app.makefile
> > > > +++ b/BaseTools/Source/C/Makefiles/app.makefile
> > > > @@ -12,9 +12,9 @@ include
> > > > $(MAKEROOT)/Makefiles/header.makefile
> > > >  APPLICATION = $(MAKEROOT)/bin/$(APPNAME)
> > > >
> > > >  .PHONY:all
> > > > -all: $(MAKEROOT)/bin $(APPLICATION)
> > > > +all: $(MAKEROOT)/bin $(APPLICATION)
> > > >
> > > > -$(APPLICATION): $(OBJECTS)
> > > > +$(APPLICATION): $(OBJECTS)
> > > > $(LINKER) -o $(APPLICATION) $(BUILD_LFLAGS)
> > > > $(OBJECTS) -L$(MAKEROOT)/libs $(LIBS)
> > > >
> > > >  $(OBJECTS):
> > $(MAKEROOT)/Include/Common/BuildVersion.h
> > > > diff --git
> > > > a/BaseTools/Source/C/Makefiles/footer.makefile
> > > > b/BaseTools/Source/C/Makefiles/footer.makefile
> > > > index e823246cfbb4..85c3374224f2 100644
> > > > --- a/BaseTools/Source/C/Makefiles/footer.makefile
> > > > +++ b/BaseTools/Source/C/Makefiles/footer.makefile
> > > > @@ -14,10 +14,10 @@ $(MAKEROOT)/libs-$(HOST_ARCH):
> > > >  install: $(MAKEROOT)/libs-$(HOST_ARCH) $(LIBRARY)
> > > > cp $(LIBRARY) $(MAKEROOT)/libs-$(HOST_ARCH)
> > > >
> > > > -$(LIBRARY): $(OBJECTS)
> > > > +$(LIBRARY): $(OBJECTS)
> > > > $(BUILD_AR) crs $@ $^
> > > >
> > > > -%.o : %.c
> > > > +%.o : %.c
> > > > $(BUILD_CC)  -c $(BUILD_CPPFLAGS) $(BUILD_CFLAGS)
> > $< -o $@
> > > >
> > > >  %.o : %.cpp
> > > > diff --git
> > > > a/BaseTools/Source/C/Makefiles/header.makefile
> > > > b/BaseTools/Source/C/Makefiles/header.makefile
> > > > index 52cbffcb4423..4e9b36d98bdb 100644
> > > > --- a/BaseTools/Source/C/Makefiles/header.makefile
> > > > +++ b/BaseTools/Source/C/Makefiles/header.makefile
> > > > @@ -61,7 +61,7 @@ else
> > > >  $(error Bad HOST_ARCH)
> > > >  endif
> > > >
> > > > -INCLUDE = $(TOOL_INCLUDE) -I $(MAKEROOT) -I
> > > > $(MAKEROOT)/Include/Common -I

[edk2-devel] [PATCH edk2-platforms 5/6] Maintainers.txt: create explicit sections for remaining modules

2019-10-09 Thread Leif Lindholm

Many of the original (ARM) platforms, and drivers brought in for them,
had no explicit maintainership defined. Add entries for these, roughly
corresponding to how they have already been handled in the past.

Cc: Ard Bieshuevel 
Cc: Michael D Kinney 
Signed-off-by: Leif Lindholm 
---
 Maintainers.txt | 56 +
 1 file changed, 56 insertions(+)

diff --git a/Maintainers.txt b/Maintainers.txt
index 56b12dd79c3f..ebb878e22ac4 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -79,6 +79,35 @@ W: 
https://github.com/tianocore/tianocore.github.io/wiki/Security
 EDK II Platforms Packages:
 --
 
+96Boards
+F: Platform/96Boards/
+M: Ard Bieshuevel 
+M: Leif Lindholm 
+
+AMD Seattle
+F: Platform/AMD/OverdriveBoard/
+F: Platform/LeMaker/CelloBoard/
+F: Platform/SoftIron/
+F: Silicon/AMD/Styx/
+M: Ard Bieshuevel 
+M: Leif Lindholm 
+
+ARM
+F: Platform/ARM/
+R: Ard Bieshuevel 
+M: Leif Lindholm 
+
+BeagleBoard:
+F: Platform/BeagleBoard/
+F: Silicon/TexasInstruments/
+R: Ard Bieshuevel 
+M: Leif Lindholm 
+
+Comcast
+F: Platform/Comcast/
+M: Ard Bieshuevel 
+M: Leif Lindholm 
+
 OptionRomPkg
 F: Drivers/OptionRomPkg/
 W: https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg
@@ -90,6 +119,12 @@ M: Leif Lindholm 
 M: Ard Bieshuevel 
 R: Andy Hayes 
 
+HiSilicon
+F: Platform/Hisilicon/
+F: Silicon/Hisilicon/
+M: Leif Lindholm 
+R: Ard Bieshuevel 
+
 Platform/Intel/QuarkPlatformPkg
 F: Platform/Intel/QuarkPlatformPkg/
 M: Michael D Kinney 
@@ -226,3 +261,24 @@ F: Platform/SolidRun/Armada80x0McBin/
 F: Silicon/Marvell/
 R: Marcin Wojtas 
 M: Leif Lindholm 
+
+Miscellaneous drivers
+F: Silicon/Atmel/
+F: Silicon/NXP/
+F: Silicon/Openmoko/
+F: Silicon/Synopsys/DesignWare/
+R: Ard Bieshuevel 
+M: Leif Lindholm 
+
+Raspberry Pi platforms and silicon
+F: Platform/RaspberryPi/
+F: Silicon/Broadcom/
+M: Ard Bieshuevel 
+M: Leif Lindholm 
+R: Pete Batard 
+
+Socionext platforms and silicon
+F: Platform/Socionext/
+F: Silicon/Socionext/
+M: Ard Bieshuevel 
+M: Leif Lindholm 
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48641): https://edk2.groups.io/g/devel/message/48641
Mute This Topic: https://groups.io/mt/34462377/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms 3/6] Maintainers.txt: revamp file to machine-readable format

2019-10-09 Thread Leif Lindholm

Convert existing package maintainer/reviewer descriptions
with adding the new path definitions.

Delete the "Platform" and "Silicon" section maintainership
descriptions. The EDK II Platforms maintainers section will
now match that.

Cc: Ard Biesheuvel 
Cc: Michael D Kinney 
Signed-off-by: Leif Lindholm 
---
 Maintainers.txt | 56 ++---
 1 file changed, 44 insertions(+), 12 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 1d27dde741f0..43803592d369 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -60,6 +60,18 @@ W: 
https://github.com/tianocore/tianocore.github.io/wiki/EDK-II
 L: https://edk2.groups.io/g/devel/
 T: git - https://github.com/tianocore/edk2-platforms.git
 
+All patches CC:d here
+L: devel@edk2.groups.io
+F: *
+F: */
+
+EDK II Platforms maintainers
+
+F: *
+M: Ard Bieshuevel 
+M: Leif Lindholm 
+M: Michael D Kinney 
+
 Responsible Disclosure, Reporting Security Issues
 -
 W: https://github.com/tianocore/tianocore.github.io/wiki/Security
@@ -67,136 +79,156 @@ W: 
https://github.com/tianocore/tianocore.github.io/wiki/Security
 EDK II Platforms Packages:
 --
 
-Drivers/OptionRomPkg
+OptionRomPkg
+F: Drivers/OptionRomPkg/
 W: https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg
 M: Ray Ni 
 
-Drivers/DisplayLink
+DisplayLink
+F: Drivers/DisplayLink/
 M: Leif Lindholm 
 M: Ard Bieshuevel 
 R: Andy Hayes 
 
-Platform
-M: Ard Biesheuvel 
-M: Leif Lindholm 
-M: Michael D Kinney 
-
 Platform/Intel/QuarkPlatformPkg
+F: Platform/Intel/QuarkPlatformPkg/
 M: Michael D Kinney 
 M: Kelly Steele 
 
 Platform/Intel/Vlv2TbltDevicePkg
+F: Platform/Intel/Vlv2TbltDevicePkg/
 M: Zailiang Sun 
 M: Yi Qian 
 
 Platform/Intel/AdvancedFeaturePkg
+F: Platform/Intel/AdvancedFeaturePkg/
 M: Michael Kubacki 
 M: Sai Chaganty 
 R: Liming Gao 
 
 Platform/Intel/BoardModulePkg
+F: Platform/Intel/BoardModulePkg/
 M: Eric Dong 
 R: Liming Gao 
 
 Platform/Intel/DebugFeaturePkg
+F: Platform/Intel/DebugFeaturePkg/
 M: Eric Dong 
 R: Liming Gao 
 
 Platform/Intel/UserInterfaceFeaturePkg
+F: Platform/Intel/UserInterfaceFeaturePkg/
 M: Dandan Bi 
 R: Liming Gao 
 
 Platform/Intel/KabylakeOpenBoardPkg
+F: Platform/Intel/KabylakeOpenBoardPkg/
 M: Chasel Chiu 
 M: Michael Kubacki 
 M: Nate DeSimone 
 
 Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3
+F: Platform/Intel/KabylakeOpenBoardPkg/GalagoPro3/
 R: Jeremy Soller 
 
 Platform/Intel/MinPlatformPkg
+F: Platform/Intel/MinPlatformPkg/
 M: Michael Kubacki 
 M: Chasel Chiu 
 M: Nate DeSimone 
 R: Liming Gao 
 
 Platform/Intel/PurleyOpenBoardPkg
+F: Platform/Intel/PurleyOpenBoardPkg/
 M: Shifei A Lu 
 M: Xiaohu Zhou 
 M: Isaac W Oram 
 
 Platform/Intel/WhiskeylakeOpenBoardPkg
+F: Platform/Intel/WhiskeylakeOpenBoardPkg/
 M: Chasel Chiu 
 M: Michael Kubacki 
 M: Nate DeSimone 
 
 Platform/Intel/SimicsOpenBoardPkg
+F: Platform/Intel/SimicsOpenBoardPkg/
 M: Wei David Y 
 M: Agyeman Prince 
 
 Platform/Intel/Tools
+F: Platform/Intel/Tools/
 M: Bob Feng 
 M: Liming Gao 
 
 Platform/Marvell
+F; Platform/Marvell/
 R: Marcin Wojtas 
+M: Leif Lindholm 
 
 Platform/SolidRun/Armada80x0McBin
+F: Platform/SolidRun/Armada80x0McBin/
 R: Marcin Wojtas 
 
-Silicon
-M: Ard Biesheuvel 
-M: Leif Lindholm 
-M: Michael D Kinney 
-
 Silicon/Intel/IntelSiliconPkg
+F: Silicon/Intel/IntelSiliconPkg/
 M: Ray Ni 
 M: Rangasai V Chaganty 
 
 Silicon/Intel/QuarkSocPkg
+F: Silicon/Intel/QuarkSocPkg/
 M: Michael D Kinney 
 M: Kelly Steele 
 
 Silicon/Intel/Vlv2DeviceRefCodePkg
+F: Silicon/Intel/Vlv2DeviceRefCodePkg/
 M: Zailiang Sun 
 M: Yi Qian 
 
 Silicon/Intel/CoffeelakeSiliconPkg
+F: Silicon/Intel/CoffeelakeSiliconPkg/
 M: Chasel Chiu 
 M: Michael Kubacki 
 M: Sai Chaganty 
 
 Silicon/Intel/KabylakeSiliconPkg
+F: Silicon/Intel/KabylakeSiliconPkg/
 M: Chasel Chiu 
 M: Michael Kubacki 
 M: Sai Chaganty 
 
 Silicon/Intel/LewisburgPkg
+F: Silicon/Intel/LewisburgPkg/
 M: Maciej Piwko
 M: Daocheng Bu 
 M: Isaac W Oram 
 
 Silicon/Intel/PurleyRcPkg
+F: Silicon/Intel/PurleyRcPkg/
 M: Thad Gillispie 
 M: Daocheng Bu 
 M: Isaac W Oram 
 
 Silicon/Intel/PurleySktPkg
+F: Silicon/Intel/PurleySktPkg/
 M: Thad Gillispie 
 M: Daocheng Bu 
 M: Isaac W Oram 
 
 Silicon/Intel/SimicsX58SktPkg
+F: Silicon/Intel/SimicsX58SktPkg/
 M: Wei David Y 
 M: Agyeman Prince 
 
 Silicon/Intel/SimicsIch10Pkg
+F: Silicon/Intel/SimicsIch10Pkg/
 M: Wei David Y 
 M: Agyeman Prince 
 
 Silicon/Intel/Tools
+F: Silicon/Intel/Tools/
 M: Bob Feng 
 M: Liming Gao 
 
 Silicon/Marvell
+F: Silicon/Marvell/
 R: Marcin Wojtas 
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48639): https://edk2.groups.io/g/devel/message/48639
Mute This Topic: https://groups.io/mt/34462374/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms 1/6] Maintainers.txt: Update documentation for new format

2019-10-09 Thread Leif Lindholm

Synchronize header with edk2/Maintainers.txt and change references
from "EDK II to EDK II Platforms".

Cc: Ard Biesheuvel 
Cc: Michael D Kinney 
Signed-off-by: Leif Lindholm 
---
 Maintainers.txt | 42 +-
 1 file changed, 33 insertions(+), 9 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 1260c8d2465b..f824e2b05de1 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -1,17 +1,24 @@
-EDK II Maintainers
-==
+EDK II Platforms Maintainers
+
 
 This file provides information about the primary maintainers for
-EDK II Platforms.
+EDK Platforms II.
 
 In general, you should not privately email the maintainer. You should
-email the edk2-devel list, but you can also Cc the maintainer.
+email the edk2-devel list, and Cc the package maintainers and
+reviewers.
+
+If the package maintainer wants to hand over the role to other people,
+the package maintainer should send the patch to update Maintainers.txt
+with new maintainer, and the new maintainer should follow up with
+an Acked-by or a Reviewed-by.
 
 Descriptions of section entries:
 
   L: Mailing list that is relevant to this area (default is edk2-devel)
  Patches and questions should be sent to the email list.
-  M: Cc address for patches and questions (ie, the package maintainer)
+  M: Package Maintainer: Cc address for patches and questions. Responsible
+ for reviewing and pushing package changes to source control.
   R: Package Reviewer: Cc address for patches and questions. Reviewers help
  maintainers review code, but don't have push access. A designated Package
  Reviewer is reasonably familiar with the Package (or some modules
@@ -29,9 +36,26 @@ Descriptions of section entries:
  Obsolete:   Old code. Something tagged obsolete generally means
  it has been replaced by a better system and you
  should be using that.
+  F: Files and directories with wildcard patterns.
+ A trailing slash includes all files and subdirectory files.
+ F:   MdeModulePkg/   all files in and below MdeModulePkg
+ F:   MdeModulePkg/*  all files in MdeModulePkg, but not below
+ F:   */Pci/* all files in a directory called Pci, at any depth in
+  the hierarchy, but not below
+ One pattern per line.  Multiple F: lines per section acceptable.
+  X: Files and directories that are NOT maintained, same rules as F:
+ Files exclusions are tested after file matches.
+ Can be useful for excluding a specific subdirectory, for instance:
+ F:   NetworkPkg/
+ X:   NetworkPkg/Ip6Dxe/
+ matches all files in and below NetworkPkg excluding NetworkPkg/Ip6Dxe/
+  Filenames not caught by any F: rule get matched as being located in the top-
+  level directory. (Internally, the script looks for a match called 
'',
+  so please don't add a file called that in the top-level directory.)
 
-EDK II
---
+
+EDK II Platforms
+
 W: https://github.com/tianocore/tianocore.github.io/wiki/EDK-II
 L: https://edk2.groups.io/g/devel/
 T: git - https://github.com/tianocore/edk2-platforms.git
@@ -40,8 +64,8 @@ Responsible Disclosure, Reporting Security Issues
 -
 W: https://github.com/tianocore/tianocore.github.io/wiki/Security
 
-EDK II Packages:
-
+EDK II Platforms Packages:
+--
 
 Drivers/OptionRomPkg
 W: https://github.com/tianocore/tianocore.github.io/wiki/OptionRomPkg
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48637): https://edk2.groups.io/g/devel/message/48637
Mute This Topic: https://groups.io/mt/34462372/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms 0/6] Update Maintainers.txt

2019-10-09 Thread Leif Lindholm

This set does a few things:
- Imports the documentation header from edk2/Maintainers.txt
- Reformats some maintainer entries to get rid of ',' characters
  in the names.
- Adds F: entries for all sections, and a default fallback section
  for those where there is no match.
- Merges the Marvell sections (designed to work with this format)
  into a single area of responsibility.
- Adds sections for those that now ended up having none other than
  the fallback one (mostly ARM platforms).
- Remove Ard from the default section.

I am intentionally not Cc:ing all affected maintainers, since this
is a reformatting exercise. All roles actually affected are Cc:d.

Cc: Ard Bieshuevel 
Cc: Marcin Wojtas 
Cc: Michael D Kinney 

Leif Lindholm (6):
  Maintainers.txt: Update documentation for new format
  Maintainers.txt: drop ',' from maintainer names
  Maintainers.txt: revamp file to machine-readable format
  Maintainers.txt: merge Marvell platforms and silicon sections
  Maintainers.txt: create explicit sections for remaining modules
  Maintainers.txt: drop Ard from default section

 Maintainers.txt | 175 ++--
 1 file changed, 140 insertions(+), 35 deletions(-)

--
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48636): https://edk2.groups.io/g/devel/message/48636
Mute This Topic: https://groups.io/mt/34462371/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms 6/6] Maintainers.txt: drop Ard from default section

2019-10-09 Thread Leif Lindholm

Ard will still be looking after specific platforms and drivers, but he
was mainly added to the "default" maintainers group to offload me until
edk2-platforms got off the ground, so drop him from that target now we
add the GetMaintainers.py.

Cc: Ard Biesheuvel 
Cc: Michael D Kinney 
Signed-off-by: Leif Lindholm 
---
 Maintainers.txt | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index ebb878e22ac4..e155d20ae724 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -68,7 +68,6 @@ F: */
 EDK II Platforms maintainers
 
 F: *
-M: Ard Bieshuevel 
 M: Leif Lindholm 
 M: Michael D Kinney 
 
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48642): https://edk2.groups.io/g/devel/message/48642
Mute This Topic: https://groups.io/mt/34462379/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms 4/6] Maintainers.txt: merge Marvell platforms and silicon sections

2019-10-09 Thread Leif Lindholm

Cc: Marcin Wojtas 
Signed-off-by: Leif Lindholm 
---
 Maintainers.txt | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index 43803592d369..56b12dd79c3f 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -160,15 +160,6 @@ F: Platform/Intel/Tools/
 M: Bob Feng 
 M: Liming Gao 
 
-Platform/Marvell
-F; Platform/Marvell/
-R: Marcin Wojtas 
-M: Leif Lindholm 
-
-Platform/SolidRun/Armada80x0McBin
-F: Platform/SolidRun/Armada80x0McBin/
-R: Marcin Wojtas 
-
 Silicon/Intel/IntelSiliconPkg
 F: Silicon/Intel/IntelSiliconPkg/
 M: Ray Ni 
@@ -229,6 +220,9 @@ F: Silicon/Intel/Tools/
 M: Bob Feng 
 M: Liming Gao 
 
-Silicon/Marvell
+Marvell platforms and silicon
+F; Platform/Marvell/
+F: Platform/SolidRun/Armada80x0McBin/
 F: Silicon/Marvell/
 R: Marcin Wojtas 
+M: Leif Lindholm 
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48640): https://edk2.groups.io/g/devel/message/48640
Mute This Topic: https://groups.io/mt/34462376/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH edk2-platforms 2/6] Maintainers.txt: drop ',' from maintainer names

2019-10-09 Thread Leif Lindholm

The ',' character, when used in the name part of email addresses,
must be escaped. Not doing so leads to all kinds of fun with SMTP.
So rework all M: entries containing a , to not do so.

Cc: Ard Bieshuevel 
Cc: Michael D Kinney 
Signed-off-by: Leif Lindholm 
---
 Maintainers.txt | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/Maintainers.txt b/Maintainers.txt
index f824e2b05de1..1d27dde741f0 100644
--- a/Maintainers.txt
+++ b/Maintainers.txt
@@ -172,19 +172,19 @@ M: Michael Kubacki 
 M: Sai Chaganty 
 
 Silicon/Intel/LewisburgPkg
-M: Piwko, Maciej 
-M: Bu, Daocheng 
-M: Oram, Isaac W 
+M: Maciej Piwko
+M: Daocheng Bu 
+M: Isaac W Oram 
 
 Silicon/Intel/PurleyRcPkg
-M: Gillispie, Thad 
-M: Bu, Daocheng 
-M: Oram, Isaac W 
+M: Thad Gillispie 
+M: Daocheng Bu 
+M: Isaac W Oram 
 
 Silicon/Intel/PurleySktPkg
-M: Gillispie, Thad 
-M: Bu, Daocheng 
-M: Oram, Isaac W 
+M: Thad Gillispie 
+M: Daocheng Bu 
+M: Isaac W Oram 
 
 Silicon/Intel/SimicsX58SktPkg
 M: Wei David Y 
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48638): https://edk2.groups.io/g/devel/message/48638
Mute This Topic: https://groups.io/mt/34462373/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 4/4] OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU hotplug

2019-10-09 Thread Igor Mammedov

On Tue, 8 Oct 2019 23:12:10 +0200
Laszlo Ersek  wrote:

> On 10/08/19 17:06, Igor Mammedov wrote:
> > On Tue,  8 Oct 2019 13:27:14 +0200
> > Laszlo Ersek  wrote:
> >  
> >> MaxCpuCountInitialization() currently handles the following options:
> >>
> >> (1) QEMU does not report the boot CPU count.
> >>
> >> In this case, PlatformPei makes MpInitLib enumerate APs up to the
> >> default PcdCpuMaxLogicalProcessorNumber value (64) minus 1, or until
> >> the default PcdCpuApInitTimeOutInMicroSeconds (50,000) elapses.
> >> (Whichever is reached first.)
> >>
> >> Time-limited AP enumeration had never been reliable on QEMU/KVM, which
> >> is why commit 45a70db3c3a5 strated handling case (2) below, in OVMF.
> >>
> >> (2) QEMU reports the boot CPU count.
> >>
> >> In this case, PlatformPei sets PcdCpuMaxLogicalProcessorNumber to the
> >> reported boot CPU count, and PcdCpuApInitTimeOutInMicroSeconds to
> >> practically "infinity" (MAX_UINT32, ~71 minutes). That causes
> >> MpInitLib to enumerate exactly the available (boot) APs.
> >>
> >> With CPU hotplug in mind, this method is not good enough. While
> >> UefiCpuPkg expects PcdCpuMaxLogicalProcessorNumber to include both
> >> boot (i.e., cold-plugged), and all *potentially* hot-plugged, logical
> >> processors, the boot CPU count reported by QEMU does not cover the
> >> second category.  
> >
> > Can you elaborate why it doesn't cover the second category?  
> 
> (Elaborate just in this thread, or elaborate in the commit message?)
> 
> The boot CPU count reported by QEMU does not cover all potentially
> hot-plugged logical processors ... because it is not supposed to.
> 
> Namely, FW_CFG_NB_CPUS exposes "pcms->boot_cpus", and that is not
> supposed to cover all potentially hot-plugged CPUs, only the boot-time
> CPUs.
'potentially hotplugged' confuses me greatly in this context
(I'm not sure if you talk about hotplugged or not existing yet CPUs).

If it's about possible CPUs limit, I'd use "possible CPUs"
instead (wich includes present and not present CPUs).


> Whereas PcdCpuMaxLogicalProcessorNumber needs to include all potentially
> hot-plugged CPUs too. For that, we need to expose "ms->smp.max_cpus"
> from QEMU.
> 
> Does this answer your question?
You answered question better below

[...]

> When a CPU is hotplugged at OS runtime, "pcms->boot_cpus" increases in
> QEMU. 
> Before the patch, the "pcms->boot_cpus" increase causes
> PcdCpuMaxLogicalProcessorNumber to increase as well. That breaks S3
> resume. PcdCpuMaxLogicalProcessorNumber must not change from initial
> boot to S3 resume.
Probably something along this lines should be put in commit message,
which clearly states a requirement for max_cpus

> 
> After the patch, the "pcms->boot_cpus" increase does not increase
> PcdCpuMaxLogicalProcessorNumber. PcdCpuMaxLogicalProcessorNumber remains
> the same (namely, "ms->smp.max_cpus"). Therefore, the CPU structures
> allocated during normal boot, for "ms->smp.max_cpus", will accommodate
> the CPUs that have been hotplugged prior to S3 resume.
> 
> I tested the S3 behavior, plus the values mentioned above are also
> logged to the OVMF debug log, by this patch:
> 
> > +  DEBUG ((DEBUG_INFO, "%a: BootCpuCount=%d mMaxCpuCount=%u\n", 
> > __FUNCTION__,
> > +BootCpuCount, mMaxCpuCount));  
> 
> This is one libvirt domain XML snippet I've used for testing:
> 
>   4
>   
> 
> 
> 
> 
>   
>   
> hvm
> ...
>   
> Haswell-noTSX
> 
> 
> 
> 
> 
>   
> 
> And the command used for testing was:
> 
> $ virsh setvcpu GUEST 3 --enable --live
> 
> When this is done, the guest kernel dmesg confirms the CPU hotplug, but
> it is not onlined automatically. I onlined it via /sys manually in the
> guest.
> 
> After that point, I exercised S3 suspend / resume. During S3 resume, the
> "BootCpuCount" log (from above) increases from 3 to 4 (and the related
> edk2 infrastructure messages are in sync). All the while "mMaxCpuCount"
> preserves its initial value, 4.
> 
> Finally, after S3 resume, I ran "rdmsr -a 0x3a" in the guest, which
> printed "5" for all *four* CPUs. This confirms that OVMF has set the
> Feature Control MSR on the new VCPU too, during S3 resume.
> 
> (The MSR is zeroed on platform reset, and has to be re-configured by
> firmware, on every CPU, during S3. It is set to 5 due to the "vmx" CPU
> feature in the above domain XML snippet. References:
> 
> - https://bugzilla.tianocore.org/show_bug.cgi?id=86
> - 
> https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt#confirm-simple-multiprocessing-during-boot
> 
> The specific meaning of the MSR is totally irrelevant now, it's just a
> good use case for testing multi-processing during S3 resume. For MSR
> 0x3A (Feature Control), the firmware must execute the wrmsr
> instructionon on each CPU, and the "rdmsr -a" Linux userspace command
> reads back the MSR on each CPU separately.)
> 
>

Re: [edk2-devel] [PATCH 00/35] edk2: clean up the usage of standardized (VOID*) typedefs

2019-10-09 Thread Laszlo Ersek

On 10/09/19 01:49, Laszlo Ersek wrote:
> On 09/17/19 21:49, Laszlo Ersek wrote:
>> Repository: https://github.com/lersek/edk2.git
>> Branch: voidptr
>>
>> The UEFI / PI / Shell specifications define a number of standard types
>> as pointers to VOID. This is arguably a design mistake; those types
>> should have been pointers to distinct incomplete union or structure
>> types. Here's why:
>>
>> Roughly paraphrasing the constraints from ISO C99 "6.5.16.1 Simple
>> assignment" and "6.5.4 Cast operators", any pointer-to-object type
>> converts implicitly to, and from, pointer-to-void, provided const /
>> volatile qualifications are not relaxed. Such implicit conversions
>> prevent compilers from catching at least the following two kinds of
>> coding mistakes:
>>
>> - mixing up one type with another (for example, EFI_HANDLE with
>>   EFI_EVENT),
>>
>> - getting the depth of indirection wrong (for example, mixing up
>>   (EFI_HANDLE*) with EFI_HANDLE).
>>
>> This series first separates these standard types from each other, in the
>> first patch, which is *not* being proposed for merging. This unmasks a
>> number of warts (semantic issues, or actual bugs) in the source code, in
>> the form of build breakages. The rest of the series works through those
>> breakages, cleaning and fixing the code.
>>
>> Every DSC file in the edk2 tree was built for at least one of the NOOPT,
>> DEBUG, RELEASE targets (NOOPT being preferred), with the GCC48 toolchain
>> (for IA32 / X64) and the GCC5 toolchain (for ARM / AARCH64). Of course,
>> the build arches were restricted to the SUPPORTED_ARCHITECTURES stated
>> in the individual DSC files.
>>
>> There were two exceptions to the above rule: DynamicTablesPkg was only
>> build-tested with AARCH64 (despite its SUPPORTED_ARCHITECTURES), given
>> that 32-bit ARM has no ACPI bindings. StandaloneMmPkg too was only
>> build-tested with AARCH64; it doesn't actually support IA32/X64 yet.
>>
>> Regarding boot & runtime tests, ArmVirtQemu on AARCH64 was tested with
>> booting to the OS (RHEL7). Furthermore, I exercised OVMF with my usual
>> boot and S3 tests, covering IA32, IA32X64, and X64. Finally, some other
>> individual tests (noted per patch) were done with OVMF.
> 
> This patch series is now ready to be pushed (it's fully reviewed),
> except for the following two patches:
> 
> * [edk2-devel] [PATCH 01/35]
>   DO NOT APPLY: edk2: turn standard handle types into pointers to
>   non-VOID
> 
> * [edk2-devel] [PATCH 25/35]
>   OvmfPkg/VideoDxe: document EFI_EDID_OVERRIDE_PROTOCOL.GetEdid() call
> 
> Regarding 01/35, it was never meant to be pushed (certainly not in this
> form); plus it would likely be too early for a number of out-of-tree
> platforms.
> 
> We have discussed enabling "strict UEFI types" (even by default,
> possibly). That's a great goal. And I don't have any time for pursuing
> it. :( So yes, I'm aware the problems will likely reproduce over time;
> I'm sorry about that.
> 
> Regarding 25/35, the original (unpatched) code might actually prove
> correct there (needing a fix in the EFI_EDID_OVERRIDE_PROTOCOL_GET_EDID
> definition instead). That depends on
> , however.
> 
> I've reached out to Andy Hayes here:
> 
> 985de369-7880-b6cc-46e7-5a2edca6582b@redhat.com">http://mid.mail-archive.com/985de369-7880-b6cc-46e7-5a2edca6582b@redhat.com
> https://edk2.groups.io/g/devel/message/48487
> 
> but I've not received any feedback yet.
> 
> So tomorrow I plan to re-run some sanity builds, with all patches except
> #01 and #25 applied. If the builds still complete, I'm going to push the
> other 33 patches.

Commit range 2de1f611be06..976d0353a6ce.

Thanks,
Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48634): https://edk2.groups.io/g/devel/message/48634
Mute This Topic: https://groups.io/mt/34180197/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [edk2-test][Patch] uefi-sct/SctPkg: Sync SNP Statistics change to IHV

2019-10-09 Thread xianhui liu

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2160
sync commit 269f8a35e44f2093625b3671f372f68e2983c49d
on file EFI/Protocol/SimpleNetwork/BlackBoxTest
/SimpleNetworkBBTestConformance.c to IHV

Cc: Heinrich Schuchardt 
Cc: Supreeth Venkatesh 
Cc: Eric Jin 

Signed-off-by: xianhui liu 
---
 .../BlackBoxTest/SimpleNetworkBBTestConformance.c  | 123 -
 1 file changed, 72 insertions(+), 51 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestConformance.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestConformance.c
index 9d5bec18..9bd21a76 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestConformance.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleNetwork/BlackBoxTest/SimpleNetworkBBTestConformance.c
@@ -964,8 +964,7 @@ BBTestStatisticsConformanceTest (
 {
   EFI_STANDARD_TEST_LIBRARY_PROTOCOL*StandardLib;
   EFI_STATUSStatus;
-  EFI_STATUSStatusBuf[3];  
-  EFI_TEST_ASSERTIONAssertionType[3];
+  EFI_TEST_ASSERTIONAssertionType;
   EFI_SIMPLE_NETWORK_PROTOCOL   *SnpInterface;
   EFI_SIMPLE_NETWORK_STATE  State1, State2;
   EFI_NETWORK_STATISTICSStatisticsTable;
@@ -1012,31 +1011,68 @@ BBTestStatisticsConformanceTest (
   StatisticsSize = sizeof (EFI_NETWORK_STATISTICS);
   //
   // Assertion Point 5.8.2.1
-  // Call Statistics() function if network interface not start.
+  // Call Statistics() function while network interface is not started.
   //
-  StatusBuf[0] = SnpInterface->Statistics (SnpInterface, FALSE, 
, );
-  if ((StatusBuf[0] == EFI_NOT_STARTED) && (SnpInterface->Mode->State == 
EfiSimpleNetworkStopped)) {
-AssertionType[0] = EFI_TEST_ASSERTION_PASSED;
+  Status = SnpInterface->Statistics (SnpInterface, FALSE, , 
);
+  if (Status == EFI_UNSUPPORTED) {
+StandardLib->RecordMessage(
+   StandardLib,
+   EFI_VERBOSE_LEVEL_QUIET,
+   L"Statistics isn't supported, Status - %r\n",
+   Status
+   );
   } else {
-AssertionType[0] = EFI_TEST_ASSERTION_FAILED;
+if ((Status == EFI_NOT_STARTED) && (SnpInterface->Mode->State == 
EfiSimpleNetworkStopped)) {
+  AssertionType = EFI_TEST_ASSERTION_PASSED;
+} else {
+  AssertionType = EFI_TEST_ASSERTION_FAILED;
+}
+StandardLib->RecordAssertion (
+   StandardLib,
+   AssertionType,
+   gSimpleNetworkBBTestConformanceAssertionGuid014,
+   L"EFI_SIMPLE_NETWORK_PROTOCOL.Statistics - Invoke 
Statistics() while network interface not started.",
+   L"%a:%d:Status - %r",
+   __FILE__,
+   (UINTN)__LINE__,
+   Status
+   );
   }
 
   //
   // Assertion Point 5.8.2.2
-  // Call Statistics() function if network interface not initialized.
+  // Call Statistics() function while network interface is not initialized.
   //
   Status = SnpInterface->Start (SnpInterface);
   if (EFI_ERROR(Status)) {
 return Status;
   }
 
-  StatusBuf[1] = SnpInterface->Statistics (SnpInterface, FALSE, 
, );
-  if (StatusBuf[1] == EFI_DEVICE_ERROR) {
-AssertionType[1] = EFI_TEST_ASSERTION_PASSED;
+  Status = SnpInterface->Statistics (SnpInterface, FALSE, , 
);
+  if (Status == EFI_UNSUPPORTED) {
+StandardLib->RecordMessage(
+   StandardLib,
+   EFI_VERBOSE_LEVEL_QUIET,
+   L"Statistics isn't supported, Status - %r\n",
+   Status
+   );
   } else {
-AssertionType[1] = EFI_TEST_ASSERTION_FAILED;
+if (Status == EFI_DEVICE_ERROR) {
+  AssertionType = EFI_TEST_ASSERTION_PASSED;
+} else {
+  AssertionType = EFI_TEST_ASSERTION_FAILED;
+}
+StandardLib->RecordAssertion (
+   StandardLib,
+   AssertionType,
+   gSimpleNetworkBBTestConformanceAssertionGuid015,
+   L"EFI_SIMPLE_NETWORK_PROTOCOL.Statistics - Invoke 
Statistics() while network interface is not initialized.",
+   L"%a:%d:Status - %r",
+   __FILE__,
+   (UINTN)__LINE__,
+   Status
+   );
   }
- 
 
   //
   // Assertion Point 5.8.2.3
@@ -1053,47 +1089,32 @@ BBTestStatisticsConformanceTest (
   //
   StatisticsSize = 0;
 
-  StatusBuf[2] = SnpInterface->Statistics (SnpInterface, FALSE, 
, );
-  if (StatusBuf[2] == EFI_BUFFER_TOO_SMALL || Status == EFI_UNSUPPORTED) {
-AssertionType[2] = EFI_TEST_ASSERTION_PASSED;
+  Status = SnpInterface->Statistics (SnpInterface, FALSE, , 
);
+  if (Status == EFI_UNSUPPORTED) {
+StandardLib->RecordMessage(
+   StandardLib,
+

Re: [edk2-devel] [PATCH v1 1/1] NetworkPkg/SnpDxe: Remove ExitBootServices event

2019-10-09 Thread Tomas Pilar (tpilar)

I've commented on the bug, SFC adapters will be fine, but I am sure there is a 
vendor out there that will be affected. Bugs due to memory corruption during OS 
load that depend on the network externalities are notoriously difficult to 
diagnose.

We need to make sure this is properly communicated and signposted so others can 
audit their drivers.

Cheers,
Tom

From: devel@edk2.groups.io  on behalf of Rabeda, Maciej 

Sent: 09 October 2019 09:50
To: Fu, Siyuan; Devel EDK2
Cc: Wu, Jiaxin
Subject: Re: [edk2-devel] [PATCH v1 1/1] NetworkPkg/SnpDxe: Remove 
ExitBootServices event

Hi Siyuan,

This change has no effect to Intel Ethernet Server UNDI drivers.
They already handle ExitBootServices event and configure the Ethernet adapters 
not to perform any DMA at this point.

As per whitepaper 
(https://firmware.intel.com/sites/default/files/Intel_WhitePaper_Using_IOMMU_for_DMA_Protection_in_UEFI.pdf),
 section Call to Action, UEFI device drivers (including UNDI) should put the 
controller to halt state and disable bus mastering in ExitBootServices stage - 
which obliges UNDI drivers to have ExitBootServices event handlers. To me, this 
means shutting down DMA on the controllers to which UNDI driver is bound.

As for second question, not disabling DMA will make our adapters continue 
writing Rx packet data to RAM in DXE Runtime stage.
I believe that this behavior is as far from desired as it can.

Thanks!
Maciej Rabeda

-Original Message-
From: Fu, Siyuan
Sent: Wednesday, October 9, 2019 04:08
To: Rabeda, Maciej ; devel@edk2.groups.io
Cc: Wu, Jiaxin 
Subject: RE: [PATCH v1 1/1] NetworkPkg/SnpDxe: Remove ExitBootServices event

Hi, Maciej

Have you tested what will happen if this SNP co-work with those UNDI drivers 
which don't have an ExitBootService event callback to shut down its DMA 
activity? And what's the impact to OS if UNDI's DMA is not shut down?

Best Regards
Siyuan

> -Original Message-
> From: Rabeda, Maciej 
> Sent: 2019年10月9日 0:16
> To: devel@edk2.groups.io
> Cc: Fu, Siyuan ; Wu, Jiaxin 
> Subject: [PATCH v1 1/1] NetworkPkg/SnpDxe: Remove ExitBootServices
> event
>
> Patch addresses Bugzilla #1972.
> During ExitBootServices stage, drivers should not call any functions
> known to use Memory Allocation Services. One of such functions (as per
> UEFI spec) is UNDI->Shutdown().
>
> Since UNDI drivers during ExitBootServices phase are expected to put
> the adapter to such a state that it will not perform any DMA
> operations, there is no need to interface UNDI by SNP driver during
> that phase.
>
> Finally, since ExitBootServices event notification function in SNP
> only calls UNDI->Shutdown() and Stop() functions, there is no need to
> create this event at all.
>
> Signed-off-by: Maciej Rabeda 
> Cc: Siyuan Fu 
> Cc: Jiaxin Wu 
> ---
>  NetworkPkg/SnpDxe/Snp.c  | 45 
>  NetworkPkg/SnpDxe/Snp.h  |  2 -
>  NetworkPkg/SnpDxe/SnpDxe.inf |  3 --
>  3 files changed, 50 deletions(-)
>
> diff --git a/NetworkPkg/SnpDxe/Snp.c b/NetworkPkg/SnpDxe/Snp.c index
> a23af05078bc..7646a3ce0293 100644
> --- a/NetworkPkg/SnpDxe/Snp.c
> +++ b/NetworkPkg/SnpDxe/Snp.c
> @@ -8,31 +8,6 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>
>  #include "Snp.h"
>
> -/**
> -  One notified function to stop UNDI device when
> gBS->ExitBootServices() called.
> -
> -  @param  Event   Pointer to this event
> -  @param  Context Event handler private data
> -
> -**/
> -VOID
> -EFIAPI
> -SnpNotifyExitBootServices (
> -  EFI_EVENT Event,
> -  VOID  *Context
> -  )
> -{
> -  SNP_DRIVER *Snp;
> -
> -  Snp  = (SNP_DRIVER *)Context;
> -
> -  //
> -  // Shutdown and stop UNDI driver
> -  //
> -  PxeShutdown (Snp);
> -  PxeStop (Snp);
> -}
> -
>  /**
>Send command to UNDI. It does nothing currently.
>
> @@ -647,21 +622,6 @@ SimpleNetworkDriverStart (
>PxeShutdown (Snp);
>PxeStop (Snp);
>
> -  //
> -  // Create EXIT_BOOT_SERIVES Event
> -  //
> -  Status = gBS->CreateEventEx (
> -  EVT_NOTIFY_SIGNAL,
> -  TPL_NOTIFY,
> -  SnpNotifyExitBootServices,
> -  Snp,
> -  ,
> -  >ExitBootServicesEvent
> -  );
> -  if (EFI_ERROR (Status)) {
> -goto Error_DeleteSNP;
> -  }
> -
>//
>//  add SNP to the undi handle
>//
> @@ -778,11 +738,6 @@ SimpleNetworkDriverStop (
>  return Status;
>}
>
> -  //
> -  // Close EXIT_BOOT_SERIVES Event
> -  //
> -  gBS->CloseEvent (Snp->ExitBootServicesEvent);
> -
>Status = gBS->CloseProtocol (
>Controller,
>_31,
> diff --git a/NetworkPkg/SnpDxe/Snp.h b/NetworkPkg/SnpDxe/Snp.h index
> e6b62930397d..f83a4f075adc 100644
> --- a/NetworkPkg/SnpDxe/Snp.h
> +++ b/NetworkPkg/SnpDxe/Snp.h
> @@ -120,8 +120,6 @@ typedef struct {
>  VOID  *MapCookie;
>} MapList[MAX_MAP_LENGTH];
>
> -  EFI_EVENT

Re: [edk2-devel] [edk2-platforms][PATCH V2 1/3] IntelSiliconPkg/FirmwareBootMediaLib: Add library

2019-10-09 Thread Ni, Ray

Michael,
Two comments:
1. The difference between PEI and DXE instances is DXE instance has a global 
variable caching the boot media type. Both get the type from HOB. So I am 
thinking how about simplifying the library to have only one instance which 
equals to PEI instance. That can also be used in DXE phase.
2. With the definition of enum type FW_BOOT_MEDIA_TYPE and GetType() API, I 
feel the other several FirmwareBootMediaIsXXX() APIs are not very necessary.

Thanks,
Ray

> -Original Message-
> From: Kubacki, Michael A 
> Sent: Saturday, October 5, 2019 1:29 AM
> To: devel@edk2.groups.io
> Cc: Chaganty, Rangasai V ; Ni, Ray
> 
> Subject: [edk2-platforms][PATCH V2 1/3]
> IntelSiliconPkg/FirmwareBootMediaLib: Add library
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2229
> 
> Adds a new library that is used to make system initialization
> decisions in the boot flow dependent upon firmware boot media.
> Note that the firmware boot media is the storage media that
> the boot firmware is stored on. It is not the OS storage media
> which may be stored upon a different non-volatile storage device.
> 
> Any Intel board, platform, or silicon code that must take action
> conditionally based on the firmware boot media must use this
> library API.
> 
> Cc: Sai Chaganty 
> Cc: Ray Ni 
> Signed-off-by: Michael Kubacki 
> ---
>  Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
>   |   8 +-
>  Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
>   |   4 +-
> 
> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/DxeSmmFirm
> wareBootMediaLib.inf |  43 
> 
> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/PeiFirmwareB
> ootMediaLib.inf|  38 +++
>  Silicon/Intel/IntelSiliconPkg/Include/Library/FirmwareBootMediaLib.h
> | 106 +++
> 
> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/DxeSmmFirm
> wareBootMediaLib.c   | 107 +++
> 
> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/FirmwareBoo
> tMediaLib.c | 109 
> 
> Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/PeiFirmwareB
> ootMediaLib.c  |  82 +++
>  8 files changed, 495 insertions(+), 2 deletions(-)
> 
> diff --git a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> index fe5bfa0dc6..f70e3b977d 100644
> --- a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> +++ b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dec
> @@ -3,7 +3,7 @@
>  #
>  # This package provides common open source Intel silicon modules.
>  #
> -# Copyright (c) 2016 - 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2016 - 2019, Intel Corporation. All rights reserved.
>  # SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
>  ##
> @@ -22,6 +22,10 @@
>#
>MicrocodeFlashAccessLib|Include/Library/MicrocodeFlashAccessLib.h
> 
> +  ## @libraryclass  Provides services to identify the firmware boot media
> device.
> +  #
> +  FirmwareBootMediaLib|Include/Library/FirmwareBootMediaLib.h
> +
>  [Guids]
>## GUID for Package token space
># {A9F8D54E-1107-4F0A-ADD0-4587E7A4A735}
> @@ -35,6 +39,8 @@
>## Include/Guid/MicrocodeFmp.h
>gMicrocodeFmpImageTypeIdGuid  = { 0x96d4fdcd, 0x1502, 0x424d, { 0x9d,
> 0x4c, 0x9b, 0x12, 0xd2, 0xdc, 0xae, 0x5c } }
> 
> +  gFirmwareBootMediaHobGuid = { 0x8c7340ea, 0xde8b, 0x4e06, {0xa4, 0x78,
> 0xec, 0x8b, 0x62, 0xd7, 0xa, 0x8b } }
> +
>  [Ppis]
>gEdkiiVTdInfoPpiGuid = { 0x8a59fcb3, 0xf191, 0x400c, { 0x97, 0x67, 0x67,
> 0xaf, 0x2b, 0x25, 0x68, 0x4a } }
> 
> diff --git a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
> b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
> index 58b5b656ef..3fb8a08b50 100644
> --- a/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
> +++ b/Silicon/Intel/IntelSiliconPkg/IntelSiliconPkg.dsc
> @@ -1,7 +1,7 @@
>  ## @file
>  # This package provides common open source Intel silicon modules.
>  #
> -# Copyright (c) 2017, Intel Corporation. All rights reserved.
> +# Copyright (c) 2017 - 2019, Intel Corporation. All rights reserved.
>  #
>  #SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -80,6 +80,8 @@
> 
> IntelSiliconPkg/Feature/VTd/PlatformVTdInfoSamplePei/PlatformVTdInfoSa
> mplePei.inf
> 
> IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdateDx
> e.inf
> 
> IntelSiliconPkg/Feature/Capsule/Library/MicrocodeFlashAccessLibNull/Micro
> codeFlashAccessLibNull.inf
> +
> IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/PeiFirmwareBootMediaLib
> .inf
> +
> IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/DxeSmmFirmwareBootMe
> diaLib.inf
> 
>  [BuildOptions]
>*_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
> diff --git
> a/Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/DxeSmmFir
> mwareBootMediaLib.inf
> b/Silicon/Intel/IntelSiliconPkg/Library/PeiDxeSmmBootMediaLib/DxeSmmFir
>

Re: [edk2-devel] [PATCH v1 1/1] NetworkPkg/SnpDxe: Remove ExitBootServices event

2019-10-09 Thread Rabeda, Maciej

Hi Siyuan,

This change has no effect to Intel Ethernet Server UNDI drivers.
They already handle ExitBootServices event and configure the Ethernet adapters 
not to perform any DMA at this point.

As per whitepaper 
(https://firmware.intel.com/sites/default/files/Intel_WhitePaper_Using_IOMMU_for_DMA_Protection_in_UEFI.pdf),
 section Call to Action, UEFI device drivers (including UNDI) should put the 
controller to halt state and disable bus mastering in ExitBootServices stage - 
which obliges UNDI drivers to have ExitBootServices event handlers. To me, this 
means shutting down DMA on the controllers to which UNDI driver is bound.

As for second question, not disabling DMA will make our adapters continue 
writing Rx packet data to RAM in DXE Runtime stage.
I believe that this behavior is as far from desired as it can.

Thanks!
Maciej Rabeda

-Original Message-
From: Fu, Siyuan 
Sent: Wednesday, October 9, 2019 04:08
To: Rabeda, Maciej ; devel@edk2.groups.io
Cc: Wu, Jiaxin 
Subject: RE: [PATCH v1 1/1] NetworkPkg/SnpDxe: Remove ExitBootServices event

Hi, Maciej

Have you tested what will happen if this SNP co-work with those UNDI drivers 
which don't have an ExitBootService event callback to shut down its DMA 
activity? And what's the impact to OS if UNDI's DMA is not shut down?

Best Regards
Siyuan 

> -Original Message-
> From: Rabeda, Maciej 
> Sent: 2019年10月9日 0:16
> To: devel@edk2.groups.io
> Cc: Fu, Siyuan ; Wu, Jiaxin 
> Subject: [PATCH v1 1/1] NetworkPkg/SnpDxe: Remove ExitBootServices 
> event
> 
> Patch addresses Bugzilla #1972.
> During ExitBootServices stage, drivers should not call any functions 
> known to use Memory Allocation Services. One of such functions (as per 
> UEFI spec) is UNDI->Shutdown().
> 
> Since UNDI drivers during ExitBootServices phase are expected to put 
> the adapter to such a state that it will not perform any DMA 
> operations, there is no need to interface UNDI by SNP driver during 
> that phase.
> 
> Finally, since ExitBootServices event notification function in SNP 
> only calls UNDI->Shutdown() and Stop() functions, there is no need to 
> create this event at all.
> 
> Signed-off-by: Maciej Rabeda 
> Cc: Siyuan Fu 
> Cc: Jiaxin Wu 
> ---
>  NetworkPkg/SnpDxe/Snp.c  | 45 
>  NetworkPkg/SnpDxe/Snp.h  |  2 -
>  NetworkPkg/SnpDxe/SnpDxe.inf |  3 --
>  3 files changed, 50 deletions(-)
> 
> diff --git a/NetworkPkg/SnpDxe/Snp.c b/NetworkPkg/SnpDxe/Snp.c index 
> a23af05078bc..7646a3ce0293 100644
> --- a/NetworkPkg/SnpDxe/Snp.c
> +++ b/NetworkPkg/SnpDxe/Snp.c
> @@ -8,31 +8,6 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  #include "Snp.h"
> 
> -/**
> -  One notified function to stop UNDI device when 
> gBS->ExitBootServices() called.
> -
> -  @param  Event   Pointer to this event
> -  @param  Context Event handler private data
> -
> -**/
> -VOID
> -EFIAPI
> -SnpNotifyExitBootServices (
> -  EFI_EVENT Event,
> -  VOID  *Context
> -  )
> -{
> -  SNP_DRIVER *Snp;
> -
> -  Snp  = (SNP_DRIVER *)Context;
> -
> -  //
> -  // Shutdown and stop UNDI driver
> -  //
> -  PxeShutdown (Snp);
> -  PxeStop (Snp);
> -}
> -
>  /**
>Send command to UNDI. It does nothing currently.
> 
> @@ -647,21 +622,6 @@ SimpleNetworkDriverStart (
>PxeShutdown (Snp);
>PxeStop (Snp);
> 
> -  //
> -  // Create EXIT_BOOT_SERIVES Event
> -  //
> -  Status = gBS->CreateEventEx (
> -  EVT_NOTIFY_SIGNAL,
> -  TPL_NOTIFY,
> -  SnpNotifyExitBootServices,
> -  Snp,
> -  ,
> -  >ExitBootServicesEvent
> -  );
> -  if (EFI_ERROR (Status)) {
> -goto Error_DeleteSNP;
> -  }
> -
>//
>//  add SNP to the undi handle
>//
> @@ -778,11 +738,6 @@ SimpleNetworkDriverStop (
>  return Status;
>}
> 
> -  //
> -  // Close EXIT_BOOT_SERIVES Event
> -  //
> -  gBS->CloseEvent (Snp->ExitBootServicesEvent);
> -
>Status = gBS->CloseProtocol (
>Controller,
>_31,
> diff --git a/NetworkPkg/SnpDxe/Snp.h b/NetworkPkg/SnpDxe/Snp.h index 
> e6b62930397d..f83a4f075adc 100644
> --- a/NetworkPkg/SnpDxe/Snp.h
> +++ b/NetworkPkg/SnpDxe/Snp.h
> @@ -120,8 +120,6 @@ typedef struct {
>  VOID  *MapCookie;
>} MapList[MAX_MAP_LENGTH];
> 
> -  EFI_EVENT  ExitBootServicesEvent;
> -
>//
>// Whether UNDI support reporting media status from GET_STATUS 
> command,
>// i.e. PXE_STATFLAGS_GET_STATUS_NO_MEDIA_SUPPORTED or diff --git 
> a/NetworkPkg/SnpDxe/SnpDxe.inf b/NetworkPkg/SnpDxe/SnpDxe.inf index 
> afeb1526cc10..8d045cfcf4ca 100644
> --- a/NetworkPkg/SnpDxe/SnpDxe.inf
> +++ b/NetworkPkg/SnpDxe/SnpDxe.inf
> @@ -64,9 +64,6 @@
>DebugLib
>NetLib
> 
> -[Guids]
> -  gEfiEventExitBootServicesGuid ## SOMETIMES_CONSUMES ##
> Event
> -
>  [Protocols]
>gEfiSimpleNetworkProtocolGuid ## BY_START

[edk2-devel] Patch for Bug 2236 on Bugzilla

2019-10-09 Thread Chen, Kenji

Commit Message:

FmpDevicePkg: Deferred LSV Commit after Platform Health Check

- LSV variable in each FmpDevice is updated after each successful FmpSetImage 
invocation. This blocks the deferred SVN mechanism performed by platfor side. 
Add a PCD to remove it to make platform code feasible to handle the mechanism 
of deferred LSV commit.
- Add FmpDevieSetImageEx function to delivr LsvUpdate parameter for 
FmpDeviceSetImage function. The value is from Fmp capsule image header to 
indicate platform side this is a LSV update.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48629): https://edk2.groups.io/g/devel/message/48629
Mute This Topic: https://groups.io/mt/34461090/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

diff --git a/FmpDevicePkg/FmpDevicePkg.dec b/FmpDevicePkg/FmpDevicePkg.dec
index 8312b7cb22..2a26de2d3d 100644
--- a/FmpDevicePkg/FmpDevicePkg.dec
+++ b/FmpDevicePkg/FmpDevicePkg.dec
@@ -70,6 +70,11 @@
   #  setting the value to {0}.
   # @Prompt SHA-256 hash of PKCS7 test key.
   gFmpDevicePkgTokenSpaceGuid.PcdFmpDeviceTestKeySha256Digest|{0x2E, 0x97, 
0x89, 0x1B, 0xDB, 0xE7, 0x08, 0xAA,  0x8C, 0xB2, 0x8F, 0xAD, 0x20, 0xA9, 0x83, 
0xC7,  0x84, 0x7D, 0x4F, 0xEE, 0x48, 0x25, 0xE9, 0x4D,  0x39, 0xFA, 0x34, 0x9A, 
0xB8, 0xB1, 0xC4, 0x26}|VOID*|0x4009
+  #
+  # Deferred LSV commit to support Resiliency FW update
+  #   TRUE  - Lsv is handled by platform code
+  #   FALSE - Lsv is handled by FmpDevicePkg
+  gFmpDevicePkgTokenSpaceGuid.PcdLsvPolicy|FALSE|BOOLEAN|0x400A
 
 [PcdsFixedAtBuild, PcdsPatchableInModule]
   ## The color of the progress bar during a firmware update.  Each firmware
diff --git a/FmpDevicePkg/FmpDevicePkg.dsc b/FmpDevicePkg/FmpDevicePkg.dsc
index bf283b93ea..c639c1f319 100644
--- a/FmpDevicePkg/FmpDevicePkg.dsc
+++ b/FmpDevicePkg/FmpDevicePkg.dsc
@@ -104,6 +104,10 @@
   #
   gFmpDevicePkgTokenSpaceGuid.PcdFmpDeviceImageIdName|L"Sample Firmware 
Device"
   #
+  # Deferred SVN commit to support Resiliency FW update
+  #
+  gFmpDevicePkgTokenSpaceGuid.PcdLsvPolicy|FALSE
+  #
   # Certificates used to authenticate capsule update image
   #
   !include 
BaseTools/Source/Python/Pkcs7Sign/TestRoot.cer.gFmpDevicePkgTokenSpaceGuid.PcdFmpDevicePkcs7CertBufferXdr.inc
diff --git a/FmpDevicePkg/FmpDxe/FmpDxe.c b/FmpDevicePkg/FmpDxe/FmpDxe.c
index 3ca9d3526a..9fd46aa3ab 100644
--- a/FmpDevicePkg/FmpDxe/FmpDxe.c
+++ b/FmpDevicePkg/FmpDxe/FmpDxe.c
@@ -250,9 +250,11 @@ GetLowestSupportedVersion (
   //
   // Check the lowest supported version UEFI variable for this device
   //
-  VariableLowestSupportedVersion = GetLowestSupportedVersionFromVariable 
(Private);
-  if (VariableLowestSupportedVersion > ReturnLsv) {
-ReturnLsv = VariableLowestSupportedVersion;
+  if (!FeaturePcdGet (PcdLsvPolicy)) {
+VariableLowestSupportedVersion = GetLowestSupportedVersionFromVariable 
(Private);
+if (VariableLowestSupportedVersion > ReturnLsv) {
+  ReturnLsv = VariableLowestSupportedVersion;
+}
   }
 
   //
@@ -963,7 +965,7 @@ SetTheImage (
   VOID  *FmpHeader;
   UINTN FmpPayloadSize;
   UINT32AllHeaderSize;
-  UINT32IncommingFwVersion;
+  UINT32IncomingFwVersion;
   UINT32LastAttemptStatus;
   UINT32Version;
   UINT32LowestSupportedVersion;
@@ -975,7 +977,7 @@ SetTheImage (
   FmpHeader  = NULL;
   FmpPayloadSize = 0;
   AllHeaderSize  = 0;
-  IncommingFwVersion = 0;
+  IncomingFwVersion  = 0;
   LastAttemptStatus  = LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL;
 
   if (!FeaturePcdGet (PcdFmpDeviceStorageAccessEnable)) {
@@ -996,7 +998,7 @@ SetTheImage (
   //
   // Set to 0 to clear any previous results.
   //
-  SetLastAttemptVersionInVariable (Private, IncommingFwVersion);
+  SetLastAttemptVersionInVariable (Private, IncomingFwVersion);
 
   //
   // if we have locked the device, then skip the set operation.
@@ -1030,12 +1032,12 @@ SetTheImage (
 Status = EFI_ABORTED;
 goto cleanup;
   }
-  Status = GetFmpPayloadHeaderVersion (FmpHeader, FmpPayloadSize, 
);
+  Status = GetFmpPayloadHeaderVersion (FmpHeader, FmpPayloadSize, 
);
   if (!EFI_ERROR (Status)) {
 //
 // Set to actual value
 //
-SetLastAttemptVersionInVariable (Private, IncommingFwVersion);
+SetLastAttemptVersionInVariable (Private, IncomingFwVersion);
   }
 
 
@@ -1153,14 +1155,31 @@ SetTheImage (
   //
   //Copy the requested image to the firmware using the FmpDeviceLib
   //
-  Status = FmpDeviceSetImage (
- (((UINT8 *)Image) + AllHeaderSize),
- ImageSize - AllHeaderSize,
- VendorCode,
- FmpDxeProgress,
-

[edk2-devel] [edk2-test][Patch] uefi-sct/SctPkg: Sync StrUpr() test change to IHV

2019-10-09 Thread xianhui liu

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1911
sync commit cce43fc3ae30d343964fe02f09242ec8604eb44b
on file EFI/Protocol/UnicodeCollation2/BlackBoxTest
/UnicodeCollation2BBTestFunction.c to IHV

Cc: Heinrich Schuchardt 
Cc: Supreeth Venkatesh 
Cc: Eric Jin 

Signed-off-by: xianhui liu 
---
 .../BlackBoxTest/UnicodeCollation2BBTestFunction.c | 218 ++---
 1 file changed, 107 insertions(+), 111 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/UnicodeCollation2/BlackBoxTest/UnicodeCollation2BBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/UnicodeCollation2/BlackBoxTest/UnicodeCollation2BBTestFunction.c
index 7282034d..239be45b 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/UnicodeCollation2/BlackBoxTest/UnicodeCollation2BBTestFunction.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/UnicodeCollation2/BlackBoxTest/UnicodeCollation2BBTestFunction.c
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright 2006 - 2016 Unified EFI, Inc.
-  Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 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
@@ -28,6 +28,43 @@ Abstract:
 #include "SctLib.h"
 #include "UnicodeCollation2BBTestMain.h"
 
+STATIC CONST STRICOLL_TEST_DATA_FIELD mStriCollTestData[] ={
+ {
+   L"",
+   L"",
+   STRING_COMPARE_EQUAL
+ },
+ {
+   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5Ax61\x62\x7D\x7E",
+   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6A\x6B\x6C\x6D\x6E\x6F\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7Ax61\x62\x7D\x7E",
+   STRING_COMPARE_EQUAL
+ },
+ {
+   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6A\x6B\x6C\x6D\x6E\x6F\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7Ax61\x62\x7D\x7E",
+   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5Ax61\x62\x7D\x7E",
+   STRING_COMPARE_EQUAL
+ },
+ {
+   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5A\x61\x62\x7D\x7E",
+   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5A\x61\x62\x7D\x7D",
+   STRING_COMPARE_MORE
+ },
+ {
+   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5A\x61\x62\x7D\x7E",
+   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5A\x61\x62\x7D\x7F",
+   STRING_COMPARE_LESS
+ },
+ {
+   L"\x01",
+   L"",
+   STRING_COMPARE_MORE
+ },
+ {
+   L"",
+   L"\x01\x02",
+   STRING_COMPARE_LESS
+ },
+};
 
 /**
  *  Entrypoint for EFI_UNICODE_COLLATOIN2_PROTOCOL.StriColl() Function Test.
@@ -59,45 +96,6 @@ BBTestStriCollFunctionAutoTest (
   //
   // Test Data
   //
-  STRICOLL_TEST_DATA_FIELD TestData[] ={
- {
-   L"",
-   L"",
-   STRING_COMPARE_EQUAL
- },
- {
-   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5Ax61\x62\x7D\x7E",
-   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6A\x6B\x6C\x6D\x6E\x6F\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7Ax61\x62\x7D\x7E",
-   STRING_COMPARE_EQUAL
- },
- {
-   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x61\x62\x63\x64\x65\x66\x67\x68\x69\x6A\x6B\x6C\x6D\x6E\x6F\x70\x71\x72\x73\x74\x75\x76\x77\x78\x79\x7Ax61\x62\x7D\x7E",
-   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5Ax61\x62\x7D\x7E",
-   STRING_COMPARE_EQUAL
- },
- {
-   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5A\x61\x62\x7D\x7E",
-   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5A\x61\x62\x7D\x7D",
-   STRING_COMPARE_MORE
- },
- {
-   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5A\x61\x62\x7D\x7E",
-   
L"\x01\x02\x11\x12\x21\x22\x31\x32\x41\x42\x43\x44\x45\x46\x47\x48\x49\x4A\x4B\x4C\x4D\x4E\x4F\x50\x51\x52\x53\x54\x55\x56\x57\x58\x59\x5A\x61\x62\x7D\x7F",
-   STRING_COMPARE_LESS
- },
- {
-   L"\x01",
-   L"",
-   STRING_COMPARE_MORE
- },
- {
-   L"",
-   L"\x01\x02",
-   STRING_COMPARE_LESS
- },
-  };

[edk2-devel] [edk2-test][Patch] uefi-sct/SctPkg: Sync SimpleTesxtInputEx change to IHV

2019-10-09 Thread xianhui liu

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2169
sync commit fc1a95f7b1a4c157d0536bc159bc5114cdfcb9b4
on file EFI/Protocol/SimpleTextInputEx/BlackBoxTest
/SimpleTextInputExBBTestConformance.c to IHV

Cc: Heinrich Schuchardt 
Cc: Supreeth Venkatesh 
Cc: Eric Jin 

Signed-off-by: xianhui liu 
---
 .../BlackBoxTest/SimpleTextInputExBBTestConformance.c  | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestConformance.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestConformance.c
index 3e230f9e..e1797219 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestConformance.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/IHV/Protocol/SimpleTextInputEx/BlackBoxTest/SimpleTextInputExBBTestConformance.c
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright 2006 - 2016 Unified EFI, Inc.
-  Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2010 - 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
@@ -153,7 +153,7 @@ BBTestSetStateConformanceTest (
 return Status;
   }
   BBTestSetStateConformanceTestCheckpoint2 ( StandardLib, 
SimpleTextInputEx );
-  
+
   Status = gtBS->FreePool (DevicePathStr);
   if (EFI_ERROR(Status))
 return Status;
@@ -483,8 +483,10 @@ BBTestSetStateConformanceTestCheckpoint1 (
 );
 }
   }
-  
-  if ( EFI_INVALID_PARAMETER != Status) {
+
+  if (Status == EFI_UNSUPPORTED) {
+AssertionType = EFI_TEST_ASSERTION_WARNING;
+  } else if (Status != EFI_INVALID_PARAMETER) {
 AssertionType = EFI_TEST_ASSERTION_FAILED;
   } else {
 AssertionType = EFI_TEST_ASSERTION_PASSED;
-- 
2.14.1.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48627): https://edk2.groups.io/g/devel/message/48627
Mute This Topic: https://groups.io/mt/34460889/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v1 0/4] Support HTTPS HostName validation feature(CVE-2019-14553)

2019-10-09 Thread David Woodhouse

On Tue, 2019-10-08 at 06:19 +, Wu, Jiaxin wrote:
> Hi David,
> 
> I just realized you have the comments on Bugzilla 960: 
> 
> > "...given that testing is failing and code inspection shows it
> > would never have been expected to work."
> 
> Do you mean you didn't pass the verification if URLs with IPv6
> literals (https://[2001:8b0:10b:1236::1]/)?  Can you also show me
> where the code inspection indicated it would never have been expected
> to work? We do pass the testing for the URLs with IPv6 if the CN or
> SAN in certificate has the corresponding IPv6 address (at least
> working with openssl 1.1.0). 

I have not tested this, but I started looking when there was a message
on the edk2 list from someone who was reporting that it didn't work for
IPv6 URIs, IIRC.

You are using SSL_set1_host(), and I believe you're just passing in the
bare hostname part of the URI, be it "1.2.3.4" or "[2001:8b0:10b::5]".

That just adds it to the 'hosts' list in the X509_VERIFY_PARAM for the
SSL connection.

In the check_hosts() function in openssl/crypto/x509/v509_vfy.c, the
code simply iterates over the members of that list, calling
X509_check_host() for each one. It never calls X509_check_ip().

If you look in openssl/crypto/x509/v3_utl.c you can see the
X509_check_host() really does only check hostnames. You'd need to call
X509_check_ip_asc() to check hostnames. And something would need to
have stripped the [] which surround an IPv6 literal.

I can't see how this can work. Have you tested it since the report on
the list that it wasn't working? 

cf. https://github.com/openssl/openssl/pull/9201 which is being ignored
by the OpenSSL developers — OpenSSL really doesn't make life easy for
you here, which is a shame.

> For the series patches here, we are intending to support the host
> name validation, I think we can commit the series patches since we
> pass the verification of IPV6 URL, what do you think?

If it passes the verification of IPv6 literals, then all my analysis is
broken and so was the report on the list that prompted me to start
looking (or I'm misremembering that report). In that case, sure, go
ahead and commit.

> Thanks,
> Jiaxin
> 
> > -Original Message-
> > From: David Woodhouse 
> > Sent: Tuesday, October 1, 2019 5:02 PM
> > To: Laszlo Ersek ; devel@edk2.groups.io; Wang,
> > Jian J
> > ; Wu, Jiaxin ; Bret
> > Barkelew
> > 
> > Subject: Re: [edk2-devel] [PATCH v1 0/4] Support HTTPS HostName
> > validation feature(CVE-2019-14553)
> > 
> > On Tue, 2019-10-01 at 01:21 +0200, Laszlo Ersek wrote:
> > > On 09/29/19 08:09, Wang, Jian J wrote:
> > > > For this patch series,
> > > > 1. " Contributed-under: TianoCore Contribution Agreement 1.1"
> > > > is not
> > 
> > needed any more.
> > > >   Remove it at push time and no need to send a v2.
> > > > 2. Since it's security patch which had been reviewed
> > > > separately, I see no
> > 
> > reason for new r-b
> > > >   required. Please raise it asap if any objections.
> > > > 3. Acked-by: Jian J Wang 
> > > 
> > > 
> > > * Can you please confirm that these patches match those that we
> > > discussed here:
> > > 
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=960#c18
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=960#c19
> > > 
> > > 
> > > * In the BZ, David and Bret raised some questions:
> > > 
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=960#c31
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=960#c32
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=960#c35
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=960#c36
> > > 
> > > and
> > > 
> > > https://bugzilla.tianocore.org/show_bug.cgi?id=960#c40
> > > 
> > > The latest comment in the bug is c#41. I'm not under the
> > > impression that
> > > all concerns raised by David and Bret have been addressed (or
> > > abandoned). I'd like David and Bret to ACK the patches.
> > 
> > I do not believe my comment #35 has been addressed, nor the
> > requested
> > testing performed.

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#48626): https://edk2.groups.io/g/devel/message/48626
Mute This Topic: https://groups.io/mt/34307578/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

smime.p7s
Description: S/MIME cryptographic signature

Re: [edk2-devel] [PATCH v6 3/3] ShellPkg/UefiShellDebug1CommandsLib: Update to support SmBios 3.3.0

2019-10-09 Thread Gao, Zhichao

Thanks for take my suggestion. But you may forget the other one.
What I said is that moving the display functions into one function, not just 
removing one of them.
Here is the example:
VOID
DisplayProcessorArchitectureType (
  IN UINT8 Key,
  IN UINT8 Option
  )
{
  ShellPrintHiiEx (-1,-1,NULL,STRING_TOKEN 
(STR_SMBIOSVIEW_QUERYTABLE_PROCESSOR_ARCH_TYPE), gShellDebug1HiiHandle);
  PRINT_INFO_OPTION (Key, Option);
  PRINT_TABLE_ITEM (ProcessorArchitectureTypesTable, Key);
}

And you should add the STR_SMBIOSVIEW_QUERYTABLE_PROCESSOR_ARCH_TYPE to the 
SmbiosViewStrings.uni file with an appropriate string like "Process 
Architecture Type:".

In my opinion, PRINT_STRUCT_VALUE_H is used to print the field's name and hex 
value without any explain of the value. And DisplayXXX function is used to 
display the field's name, field's value and the meaning of the value.

Thanks,
Zhichao

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Abner Chang
> Sent: Wednesday, October 9, 2019 2:48 PM
> To: devel@edk2.groups.io
> Cc: abner.ch...@hpe.com; Carsey, Jaben ; Ni,
> Ray ; Gao, Zhichao ; Leif
> Lindholm ; Gilbert Chen 
> Subject: [edk2-devel] [PATCH v6 3/3]
> ShellPkg/UefiShellDebug1CommandsLib: Update to support SmBios 3.3.0
> 
> Shell command smbiosview updates for SMBIOS 3.3.0 spec.
> 
> Bugzilla link,
> https://bugzilla.tianocore.org/show_bug.cgi?id=2202
> 
> Signed-off-by: Abner Chang 
> 
> Cc: Jaben Carsey 
> Cc: Ray Ni 
> Cc: Zhichao Gao 
> Cc: Leif Lindholm 
> Cc: Gilbert Chen 
> ---
>  .../SmbiosView/PrintInfo.c | 22 +++-
>  .../SmbiosView/PrintInfo.h | 13 -
>  .../SmbiosView/QueryTable.c| 63 
> +-
>  .../UefiShellDebug1CommandsLib.uni |  3 +-
>  4 files changed, 97 insertions(+), 4 deletions(-)
> 
> diff --git
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> index cfd7a2b..4989102 100644
> ---
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> +++
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> @@ -3,7 +3,7 @@
> 
>Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
>(C) Copyright 2014 Hewlett-Packard Development Company, L.P.
> -  (C) Copyright 2015-2017 Hewlett Packard Enterprise Development LP
> +  (C) Copyright 2015-2019 Hewlett Packard Enterprise Development LP
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -1169,6 +1169,14 @@ SmbiosPrintStructure (
>  break;
> 
>//
> +  // Processor Additional Information (Type 44)  //  case 44:
> +PRINT_STRUCT_VALUE_H (Struct, Type44, RefHandle);
> +DisplayProcessorArchitectureType (Struct->Type44-
> >ProcessorSpecificBlock.ProcessorArchType, Option);
> +break;
> +
> +  //
>// Inactive (Type 126)
>//
>case 126:
> @@ -2350,6 +2358,18 @@ DisplayProcessorFamily2 (
>Print (L"Video Processor\n");
>break;
> 
> +case 0x200:
> +  Print (L"RISC-V RV32\n");
> +  break;
> +
> +case 0x201:
> +  Print (L"RISC-V RV64\n");
> +  break;
> +
> +case 0x202:
> +  Print (L"RISC-V RV128\n");
> +  break;
> +
>  default:
>   ShellPrintHiiEx(-1,-1,NULL,STRING_TOKEN
> (STR_SMBIOSVIEW_PRINTINFO_UNDEFINED_PROC_FAMILY),
> gShellDebug1HiiHandle);
>}
> diff --git
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.h
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.h
> index a8c32ab..77a86fc 100644
> ---
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.h
> +++
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.h
> @@ -2,7 +2,7 @@
>Module to clarify the element info of the smbios structure.
> 
>Copyright (c) 2005 - 2015, Intel Corporation. All rights reserved.
> -  (C) Copyright 2017 Hewlett Packard Enterprise Development LP
> +  (C) Copyright 2017 - 2019 Hewlett Packard Enterprise Development
> + LP
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -427,4 +427,15 @@ DisplayTpmDeviceCharacteristics (
>IN UINT8   Option
>);
> 
> +/**
> +  Display Processor Architecture Type (Type 44).
> +
> +  @param[in] Key   The key of the structure.
> +  @param[in] Option The optional information.
> +**/
> +VOID
> +DisplayProcessorArchitectureType (
> +  IN UINT8 Key,
> +  IN UINT8 Option
> +  );
>  #endif
> diff --git
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
> c
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
> c
> index bfb7c3b..ef098ad 100644
> ---
> a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
> c
> +++
> b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.
> +++ c
> @@ -3,7 +3,7 @@
>And give a interface of query a string out of a table.
> 
>Copyright

Re: [edk2-devel] [PATCH v5 3/3] ShellPkg/UefiShellDebug1CommandsLib: Update to support SmBios 3.3.0

2019-10-09 Thread Abner Chang

HI Zhichao,
I revise it as your suggestion. [PATCH v6] for the third patch (rebased) was 
just sent.

Thanks
Abner

> -Original Message-
> From: Gao, Zhichao [mailto:zhichao@intel.com]
> Sent: Wednesday, October 9, 2019 10:58 AM
> To: devel@edk2.groups.io; Chang, Abner (HPS SW/FW Technologist)
> 
> Cc: Carsey, Jaben ; Ni, Ray ;
> Leif Lindholm ; Chen, Gilbert
> 
> Subject: RE: [edk2-devel] [PATCH v5 3/3]
> ShellPkg/UefiShellDebug1CommandsLib: Update to support SmBios 3.3.0
> 
> How about change the function name from ProcessorArchitectureType to
> DisplayProcessorArchitectureType?
> 
> And why separate the processor arch type display into two section:
> i.e. first display " ProcessorSpecificBlock.ProcessorArchType: 0xXX" thru
> PRINT_STRUCT_VALUE_H, second display the value's meaning thru
> ProcessorArchitectureType, such as " 128-bit RISC-V (RV128)".
> I suggest to put them into one function DisplayProcessorArchitectureType
> like other functions did. Such as the blowing format:
> VOID
> DisplayMCHostInterfaceType (
>   IN UINT8 Key,
>   IN UINT8 Option
>   )
> {
>   ShellPrintHiiEx(-1,-1,NULL,STRING_TOKEN
> (STR_SMBIOSVIEW_QUERYTABLE_MC_HOST_INTERFACE_TYPE),
> gShellDebug1HiiHandle);
>   PRINT_INFO_OPTION (Key, Option);
>   PRINT_TABLE_ITEM (MCHostInterfaceTypeTable, Key); }
> 
> Thanks,
> Zhichao
> 
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > Abner Chang
> > Sent: Tuesday, October 8, 2019 4:04 PM
> > To: devel@edk2.groups.io
> > Cc: abner.ch...@hpe.com; Carsey, Jaben ; Ni,
> > Ray ; Gao, Zhichao ; Leif
> > Lindholm ; Gilbert Chen
> > 
> > Subject: [edk2-devel] [PATCH v5 3/3]
> > ShellPkg/UefiShellDebug1CommandsLib: Update to support SmBios 3.3.0
> >
> > Shell command smbiosview updates for SMBIOS 3.3.0 spec.
> >
> > Bugzilla link,
> > INVALID URI REMOVED
> > e.org_show-5Fbug.cgi-3Fid-
> 3D2202=DwIFAg=C5b8zRQO1miGmBeVZ2LFWg=_
> >
> SN6FZBN4Vgi4Ulkskz6qU3NYRO03nHp9P7Z5q59A3E=iZPRGBE2YqYcm2VO
> KgWvwrtGD
> > P3Gn-
> 0WwIs5VAkpqao=SidItX73peVBmSm4Ws1A5kr8hOtp2MBpWKg4zdb4Jeg&
> e=
> >
> > Signed-off-by: Abner Chang 
> >
> > Cc: Jaben Carsey 
> > Cc: Ray Ni 
> > Cc: Zhichao Gao 
> > Cc: Leif Lindholm 
> > Cc: Gilbert Chen 
> > ---
> >  .../SmbiosView/PrintInfo.c | 23 +++-
> >  .../SmbiosView/PrintInfo.h | 13 -
> >  .../SmbiosView/QueryTable.c| 63 
> > +-
> >  .../UefiShellDebug1CommandsLib.uni |  3 +-
> >  4 files changed, 98 insertions(+), 4 deletions(-)
> >
> > diff --git
> > a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> > b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> > index cfd7a2b..ff0c1db 100644
> > ---
> > a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> > +++
> > b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
> > @@ -3,7 +3,7 @@
> >
> >Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
> >(C) Copyright 2014 Hewlett-Packard Development Company, L.P.
> > -  (C) Copyright 2015-2017 Hewlett Packard Enterprise Development
> > LP
> > +  (C) Copyright 2015-2019 Hewlett Packard Enterprise Development
> > + LP
> >SPDX-License-Identifier: BSD-2-Clause-Patent
> >
> >  **/
> > @@ -1169,6 +1169,15 @@ SmbiosPrintStructure (
> >  break;
> >
> >//
> > +  // Processor Additional Information (Type 44)  //  case 44:
> > +PRINT_STRUCT_VALUE_H (Struct, Type44, RefHandle);
> > +PRINT_STRUCT_VALUE_H (Struct, Type44,
> > ProcessorSpecificBlock.ProcessorArchType);
> > +ProcessorArchitectureType (Struct->Type44-
> > >ProcessorSpecificBlock.ProcessorArchType, Option);
> > +break;
> > +
> > +  //
> >// Inactive (Type 126)
> >//
> >case 126:
> > @@ -2350,6 +2359,18 @@ DisplayProcessorFamily2 (
> >Print (L"Video Processor\n");
> >break;
> >
> > +case 0x200:
> > +  Print (L"RISC-V RV32\n");
> > +  break;
> > +
> > +case 0x201:
> > +  Print (L"RISC-V RV64\n");
> > +  break;
> > +
> > +case 0x202:
> > +  Print (L"RISC-V RV128\n");
> > +  break;
> > +
> >  default:
> >   ShellPrintHiiEx(-1,-1,NULL,STRING_TOKEN
> > (STR_SMBIOSVIEW_PRINTINFO_UNDEFINED_PROC_FAMILY),
> > gShellDebug1HiiHandle);
> >}
> > diff --git
> > a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.h
> > b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.h
> > index a8c32ab..22f59d6 100644
> > ---
> > a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.h
> > +++
> > b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.h
> > @@ -2,7 +2,7 @@
> >Module to clarify the element info of the smbios structure.
> >
> >Copyright (c) 2005 - 2015, Intel Corporation. All rights
> > reserved.
> > -  (C) Copyright 2017 Hewlett Packard Enterprise Development LP
> > +  (C) Copyright 2017 - 2019 Hewlett Packard

[edk2-devel] [PATCH v6 3/3] ShellPkg/UefiShellDebug1CommandsLib: Update to support SmBios 3.3.0

2019-10-09 Thread Abner Chang

Shell command smbiosview updates for SMBIOS 3.3.0 spec.

Bugzilla link,
https://bugzilla.tianocore.org/show_bug.cgi?id=2202

Signed-off-by: Abner Chang 

Cc: Jaben Carsey 
Cc: Ray Ni 
Cc: Zhichao Gao 
Cc: Leif Lindholm 
Cc: Gilbert Chen 
---
 .../SmbiosView/PrintInfo.c | 22 +++-
 .../SmbiosView/PrintInfo.h | 13 -
 .../SmbiosView/QueryTable.c| 63 +-
 .../UefiShellDebug1CommandsLib.uni |  3 +-
 4 files changed, 97 insertions(+), 4 deletions(-)

diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
index cfd7a2b..4989102 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.c
@@ -3,7 +3,7 @@
 
   Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
   (C) Copyright 2014 Hewlett-Packard Development Company, L.P.
-  (C) Copyright 2015-2017 Hewlett Packard Enterprise Development LP
+  (C) Copyright 2015-2019 Hewlett Packard Enterprise Development LP
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -1169,6 +1169,14 @@ SmbiosPrintStructure (
 break;
 
   //
+  // Processor Additional Information (Type 44)
+  //
+  case 44:
+PRINT_STRUCT_VALUE_H (Struct, Type44, RefHandle);
+DisplayProcessorArchitectureType 
(Struct->Type44->ProcessorSpecificBlock.ProcessorArchType, Option);
+break;
+
+  //
   // Inactive (Type 126)
   //
   case 126:
@@ -2350,6 +2358,18 @@ DisplayProcessorFamily2 (
   Print (L"Video Processor\n");
   break;
 
+case 0x200:
+  Print (L"RISC-V RV32\n");
+  break;
+
+case 0x201:
+  Print (L"RISC-V RV64\n");
+  break;
+
+case 0x202:
+  Print (L"RISC-V RV128\n");
+  break;
+
 default:
  ShellPrintHiiEx(-1,-1,NULL,STRING_TOKEN 
(STR_SMBIOSVIEW_PRINTINFO_UNDEFINED_PROC_FAMILY), gShellDebug1HiiHandle);
   }
diff --git a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.h 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.h
index a8c32ab..77a86fc 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.h
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/PrintInfo.h
@@ -2,7 +2,7 @@
   Module to clarify the element info of the smbios structure.
 
   Copyright (c) 2005 - 2015, Intel Corporation. All rights reserved.
-  (C) Copyright 2017 Hewlett Packard Enterprise Development LP
+  (C) Copyright 2017 - 2019 Hewlett Packard Enterprise Development LP
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -427,4 +427,15 @@ DisplayTpmDeviceCharacteristics (
   IN UINT8   Option
   );
 
+/**
+  Display Processor Architecture Type (Type 44).
+
+  @param[in] Key   The key of the structure.
+  @param[in] Option The optional information.
+**/
+VOID
+DisplayProcessorArchitectureType (
+  IN UINT8 Key,
+  IN UINT8 Option
+  );
 #endif
diff --git 
a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c 
b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
index bfb7c3b..ef098ad 100644
--- a/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
+++ b/ShellPkg/Library/UefiShellDebug1CommandsLib/SmbiosView/QueryTable.c
@@ -3,7 +3,7 @@
   And give a interface of query a string out of a table.
 
   Copyright (c) 2005 - 2018, Intel Corporation. All rights reserved.
-  (C) Copyright 2016-2017 Hewlett Packard Enterprise Development LP
+  (C) Copyright 2016-2019 Hewlett Packard Enterprise Development LP
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -620,6 +620,10 @@ TABLE_ITEM  ProcessorCharacteristicsTable[] = {
   {
 7,
 L" Power/Performance Control"
+  },
+  {
+8,
+L" 128-bit Capable"
   }
 };
 
@@ -3268,6 +3272,44 @@ TABLE_ITEM  MCHostInterfaceTypeTable[] = {
   },
 };
 
+TABLE_ITEM  ProcessorArchitectureTypesTable[] = {
+  {
+0,
+L" Reserved "
+  },
+  {
+1,
+L" IA32 (x86) "
+  },
+  {
+2,
+L" x64 (x86-64, intel64, AMD64, EM64T) "
+  },
+  {
+3,
+L" Intel Itanium architecture "
+  },
+  {
+4,
+L" 32-bit ARM (Aarch32) "
+  },
+  {
+5,
+L" 64-bit ARM (Aarch64) "
+  },
+  {
+6,
+L" 32-bit RISC-V (RV32) "
+  },
+  {
+7,
+L" 64-bit RISC-V (RV64) "
+  },
+  {
+8,
+L" 128-bit RISC-V (RV128) "
+  }
+};
 
 TABLE_ITEM  StructureTypeInfoTable[] = {
   {
@@ -3447,6 +3489,10 @@ TABLE_ITEM  StructureTypeInfoTable[] = {
 L" TPM Device"
   },
   {
+44,
+L" Processor Additional Information"
+  },
+  {
 0x7E,
 L" Inactive"
   },
@@ -4697,6 +4743,21 @@ DisplayMCHostInterfaceType (
 }
 
 /**
+  Display Processor Architecture Type (Type 44).
+
+  @param[in] Key   The key of the structure.
+  @param[in] Option The optional information.
+**/
+VOID
+DisplayProcessorArchitectureType (
+  IN UINT8

79 matches

Mail list logo