Re: [edk2-devel] ExtScsiPassThru support for Logical SCSI devices

[Wu, Hao A]

Hello Ravi Kumar,
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Ravi 
Kumar Siadri
Sent: Thursday, June 13, 2019 4:18 PM
To: Wu, Hao A
Cc: devel@edk2.groups.io
Subject: Re: [edk2-devel] ExtScsiPassThru support for Logical SCSI devices

Hi Wu Hao A,

Thanks for the response.
I have added my comments in line.

Thanks,
Ravi Kumar




On Wed, Jun 12, 2019 at 1:26 PM Wu, Hao A 
mailto:hao.a...@intel.com>> wrote:
Hello Ravi Kumar,

Inline comments below:

From: devel@edk2.groups.io 
[mailto:devel@edk2.groups.io] On Behalf Of Ravi 
Kumar Siadri
Sent: Wednesday, June 12, 2019 12:01 PM
To: devel@edk2.groups.io
Subject: Re: [edk2-devel] ExtScsiPassThru support for Logical SCSI devices

Hi,

Can someone help me in clarifying my queries ??

Thanks,
Ravi Kumar

On Mon, Jun 10, 2019 at 3:55 PM Ravi Kumar Siadri 
mailto:siadriravikumaru...@gmail.com>> wrote:
Hi all,

I have couple of queries regarding the 
EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL attribute support in 
EFI_EXT_SCSI_PASS_THRU_PROTOCOL.

1.
The Attributes field of the EFI_EXT_SCSI_PASS_THRU_PROTOCOL interface tells if 
the interface is for physical SCSI devices or logical SCSI devices. Drivers for 
non-RAID SCSI controllers will set both the 
EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL, and the 
EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL bits.

If the Drivers is for non-RAID SCSI controllers why to set the 
EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL bit. Will there be any case that 
non-RAID SCSI controllers have Logical devices connected to it ??

Per my understanding, every partition on a physical HW device will be treated
as a logical device by the firmware.

So for non-RAID case, both bits will be set for the PassThru protocol produced
for the physical device.

Ravi:
As far as i know RAID controller will treat a partition/drive as logical device 
only if has RIS (raid information sector) information in it.  So i don't think 
partition is treated as logical device.

Agree.
Then for the non-RAID case, the hardware is considered as a physical device and 
a logical one at the same time.
Since media access protocols like the BlockIO protocol will be produced upon 
the logical instance of the PassThru protocol, it is the reason that both bits 
are set for this case.
(Refer to function DetermineInstallBlockIo() at 
MdeModulePkg\Bus\Scsi\ScsiDiskDxe\ScsiDisk.c)

2.
Drivers for RAID controllers that allow access to the physical devices and 
logical devices will produce two EFI_EXT_SCSI_PASS_THRU_PROTOCOL interfaces:
One with the just the EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL bit set and 
another with just the EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL bit set. One 
interface can be used to access the physical devices attached to the RAID 
controller, and the other can be used to access the logical devices attached to 
the RAID controller for its current configuration.

Any background why EFI_EXT_SCSI_PASS_THRU_PROTOCOL needed 2 instances ? why 
can't we install attributes EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL and 
EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL on same Instance ??
How User locates the Instance with EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL 
bit set and Instance with EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL bit set. ??

UEFI spec allows RAID drivers to only produce one PassThru protocol interface
with just the XXX_PASS_THRU_LOGICAL bit set when the RAID controller select to
not allow direct access to the underlying physical devices.

  Ravi:
If the RAID Driver supports only Logical or Physical Devices then it is fine 
creating only 1 instance and not allowing other devices which Bit is not set. 
(either  EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL or 
EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL).
But if the RAID driver supports both the Logical and Physical Devices, then we 
have to need 2 instances as per spec. This is going to be an over head, while 
locating instances by the user who want to send commands to Target devices 
connected to RAID controller.
Since each EFI_EXT_SCSI_PASS_THRU_PROTOCOL instance must have an associated 
device path. Only 1 instance can be installed on that particular RAID 
controller handle since the GUID is same for both the instances.
If our intention is to filter the Logical and Physical devices then, we can add 
a parameter in GetNextTartget() function to inform RAID Driver which type of 
targets the user is looking for. (Physical or Logical).
 Right ??

My take is that the producer of the physical and logical PassThru protocol may 
not be the same vender (or driver).
The logical instance (which determines the configuration of the RAID) might 
have a common logic that applies to common using cases.
The logical one will be used to produce media access protocols, some actual HW 
may not be accessible (e.g. used for data backup) by this PassThru protocol 
instance.
While the physical one can be used 

Re: [edk2-devel] [PATCH v1 2/6] OvmfPkg/OvmfPkg.dec: Add PcdShellFile in OVMF DEC file

[Wu, Hao A]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Thursday, June 13, 2019 10:42 PM
> To: devel@edk2.groups.io; Wu, Hao A
> Cc: Ni, Ray; Justen, Jordan L; Ard Biesheuvel
> Subject: Re: [edk2-devel] [PATCH v1 2/6] OvmfPkg/OvmfPkg.dec: Add
> PcdShellFile in OVMF DEC file
> 
> Hi Hao,
> 
> On 05/27/19 07:19, Wu, Hao A wrote:
> > REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843
> >
> > OVMF is currently using the PCD 'PcdShellFile' defined in
> > IntelFrameworkModulePkg.
> >
> > This commit will add this PCD into the OVMF DEC file in order to drop
> > OVMF's dependency on IntelFrameworkModulePkg. The PCD token value
> 0x17 is
> > selected to fill the hole (seems the only one left) in OvmfPkg.
> >
> > Please note that, instead of adding the PCD under section:
> > [PcdsFixedAtBuild, PcdsPatchableInModule]
> >
> > as in IntelFrameworkModulePkg.dec file, it is added in section:
> > [PcdsFixedAtBuild]
> >
> > in OvmfPkg.dec instead.
> 
> Please replace patches #2 through #4 with the following approach:
> 
> - eliminate PcdShellFile completely, from OvmfPkg
> 
> - in PlatformBootManagerLib, please consume gUefiShellFileGuid, from
> ShellPkg.dec.
> 
> (This is what ArmPkg and ArmVirtPkg do.)


Got it.

A new series has been sent out to address this.
Replaced patch #2~#4 with the last patch of the new series:
https://edk2.groups.io/g/devel/message/42415

Best Regards,
Hao Wu


> 
> Thanks!
> Laszlo
> 
> > Cc: Ray Ni 
> > Cc: Jordan Justen 
> > Cc: Laszlo Ersek 
> > Cc: Ard Biesheuvel 
> > Signed-off-by: Hao A Wu 
> > ---
> >  OvmfPkg/OvmfPkg.dec | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> > index 9640360f62..38a2d4763d 100644
> > --- a/OvmfPkg/OvmfPkg.dec
> > +++ b/OvmfPkg/OvmfPkg.dec
> > @@ -160,6 +160,9 @@ [PcdsFixedAtBuild]
> >#  For the corresponding bits, 0 = Edge triggered and 1 = Level 
> > triggered.
> >
> gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x|UIN
> T16|0x5
> >
> > +  ## FFS filename to find the shell application.
> > +  gUefiOvmfPkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C,
> 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4,
> 0xD1 }|VOID*|0x17
> > +
> >## Indicates if BiosVideo driver will switch to 80x25 Text VGA Mode when
> >#  exiting boot service.
> >#   TRUE  - Switch to Text VGA Mode.
> >
> 
> 
> 


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

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

[edk2-devel] [PATCH v3 2/4] OvmfPkg/IncompatiblePciDeviceSupportDxe: Drop framework pkg dependency

[Wu, Hao A]

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

This commit will drop the driver's dependency on the IntelFrameworkPkg:
gEfiLegacyBiosProtocolGuid

Such dependency has already been addressed by the duplication of the above
definition from IntelFrameworkPkg into the OvmfPkg.

Cc: Ray Ni 
Cc: David Woodhouse 
Cc: Jordan Justen 
Cc: Ard Biesheuvel 
Signed-off-by: Hao A Wu 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf | 1 -
 1 file changed, 1 deletion(-)

diff --git 
a/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf 
b/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
index e13577530d..f08b6f4bd4 100644
--- a/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
+++ b/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
@@ -20,7 +20,6 @@ [Sources]
   IncompatiblePciDeviceSupport.c
 
 [Packages]
-  IntelFrameworkPkg/IntelFrameworkPkg.dec
   MdeModulePkg/MdeModulePkg.dec
   MdePkg/MdePkg.dec
   OvmfPkg/OvmfPkg.dec
-- 
2.12.0.windows.1


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

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

[edk2-devel] [PATCH v3 4/4] OvmfPkg: Refer to Shell app via its declared GUID

[Wu, Hao A]

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

Currently, the file GUID reference of the UEFI Shell app is indirected
via the PCD gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile,
which is set to a fixed value for OvmfPkg.

So instead, use the symbolic GUID in ShellPkg for this purpose, and drop
the reference to this PCD, and to the IntelFrameworkModulePkg package
entirely.

Cc: Ray Ni 
Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Signed-off-by: Hao A Wu 
---
 OvmfPkg/OvmfPkgIa32.dsc   | 2 --
 OvmfPkg/OvmfPkgIa32X64.dsc| 2 --
 OvmfPkg/OvmfPkgX64.dsc| 2 --
 OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf | 6 +++---
 OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c  | 4 ++--
 5 files changed, 5 insertions(+), 11 deletions(-)

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 6830e361bf..473eaba246 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -503,8 +503,6 @@ [PcdsFixedAtBuild]
   #
 !include NetworkPkg/NetworkPcds.dsc.inc
 
-  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 
0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
-
 !if $(SMM_REQUIRE) == TRUE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize|0x4000
 !endif
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 372161365c..73f33b7218 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -509,8 +509,6 @@ [PcdsFixedAtBuild.X64]
   #
 !include NetworkPkg/NetworkPcds.dsc.inc
 
-  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 
0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
-
 !if $(SMM_REQUIRE) == TRUE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize|0x4000
 !endif
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index e0c60bc5dc..39ac791565 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -508,8 +508,6 @@ [PcdsFixedAtBuild]
   #
 !include NetworkPkg/NetworkPcds.dsc.inc
 
-  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 
0x7C, 0x3E, 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }
-
 !if $(SMM_REQUIRE) == TRUE
   gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmStackSize|0x4000
 !endif
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf 
b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
index d25e0a417f..060a3ab4c5 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
+++ b/OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf
@@ -1,7 +1,7 @@
 ## @file
 #  Platform BDS customizations library.
 #
-#  Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 ##
@@ -29,10 +29,10 @@ [Sources]
 [Packages]
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
-  IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
   SourceLevelDebugPkg/SourceLevelDebugPkg.dec
   OvmfPkg/OvmfPkg.dec
   SecurityPkg/SecurityPkg.dec
+  ShellPkg/ShellPkg.dec
 
 [LibraryClasses]
   BaseLib
@@ -60,7 +60,6 @@ [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
   gEfiMdePkgTokenSpaceGuid.PcdPlatformBootTimeOut
-  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile
 
 [Pcd.IA32, Pcd.X64]
   gEfiMdePkgTokenSpaceGuid.PcdFSBClock
@@ -77,3 +76,4 @@ [Guids]
   gEfiXenInfoGuid
   gEfiEndOfDxeEventGroupGuid
   gRootBridgesConnectedEventGroupGuid
+  gUefiShellFileGuid
diff --git a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c 
b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
index 5b15d3bb12..797731a41c 100644
--- a/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
+++ b/OvmfPkg/Library/PlatformBootManagerLib/BdsPlatform.c
@@ -1,7 +1,7 @@
 /** @file
   Platform BDS customizations.
 
-  Copyright (c) 2004 - 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2004 - 2019, Intel Corporation. All rights reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
 **/
@@ -1532,7 +1532,7 @@ PlatformBootManagerAfterConsole (
   // Register UEFI Shell
   //
   PlatformRegisterFvBootOption (
-PcdGetPtr (PcdShellFile), L"EFI Internal Shell", LOAD_OPTION_ACTIVE
+, L"EFI Internal Shell", LOAD_OPTION_ACTIVE
 );
 
   RemoveStaleFvFileOptions ();
-- 
2.12.0.windows.1


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

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

[edk2-devel] [PATCH v3 1/4] OvmfPkg/PlatformPei: Remove redundant reference of framework pkg DEC

[Wu, Hao A]

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

For the driver's INF file, this commit will remove the redundant reference
to 'IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec'.

Cc: Ray Ni 
Cc: Jordan Justen 
Cc: Ard Biesheuvel 
Signed-off-by: Hao A Wu 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/PlatformPei/PlatformPei.inf | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
b/OvmfPkg/PlatformPei/PlatformPei.inf
index f660c2d9e4..d9fd9c8f05 100644
--- a/OvmfPkg/PlatformPei/PlatformPei.inf
+++ b/OvmfPkg/PlatformPei/PlatformPei.inf
@@ -2,7 +2,7 @@
 #  Platform PEI driver
 #
 #  This module provides platform specific function to detect boot mode.
-#  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
 #
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
@@ -36,7 +36,6 @@ [Sources]
   Xen.h
 
 [Packages]
-  IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
   MdePkg/MdePkg.dec
   MdeModulePkg/MdeModulePkg.dec
   SecurityPkg/SecurityPkg.dec
-- 
2.12.0.windows.1


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

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

[edk2-devel] [PATCH v3 3/4] OvmfPkg/Csm/CsmSupportLib: Drop IntelFrameworkPkg dependency

[Wu, Hao A]

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

This commit will update the INF file of the CsmSupportLib to drop its
dependency on IntelFrameworkPkg:

gEfiLegacyBiosPlatformProtocolGuid
gEfiLegacyBiosProtocolGuid
gEfiLegacyInterruptProtocolGuid

The above dependencies have already been addressed by the duplication of
these definitions from IntelFrameworkPkg to OvmfPkg.

Cc: Ray Ni 
Cc: David Woodhouse 
Cc: Jordan Justen 
Cc: Ard Biesheuvel 
Signed-off-by: Hao A Wu 
Reviewed-by: Laszlo Ersek 
---
 OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf 
b/OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
index 229f2e0b4b..45f201f07b 100644
--- a/OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
+++ b/OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
@@ -1,7 +1,7 @@
 ## @file
 #  Platform CSM Support Library
 #
-#  Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2008 - 2019, Intel Corporation. All rights reserved.
 #  SPDX-License-Identifier: BSD-2-Clause-Patent
 #
 ##
@@ -34,7 +34,6 @@ [Sources]
 
 [Packages]
   MdePkg/MdePkg.dec
-  IntelFrameworkPkg/IntelFrameworkPkg.dec
   OvmfPkg/OvmfPkg.dec
 
 [Pcd]
-- 
2.12.0.windows.1


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

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

Re: [edk2-devel] [PATCH v2 0/3] Common OBB verification feature

[Wang, Jian J]

Forgot to mention test:
1. Unit test and security test based on HBFA test framework
2. System test on three real platforms

Regards,
Jian


> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Wang,
> Jian J
> Sent: Friday, June 14, 2019 8:30 AM
> To: Yao, Jiewen ; devel@edk2.groups.io
> Cc: Zhang, Chao B ; Hernandez Beltran, Jorge
> ; Han, Harry 
> Subject: Re: [edk2-devel] [PATCH v2 0/3] Common OBB verification feature
> 
> Jiewen,
> 
> > -Original Message-
> > From: Yao, Jiewen
> > Sent: Wednesday, June 12, 2019 12:49 PM
> > To: Wang, Jian J ; devel@edk2.groups.io
> > Cc: Zhang, Chao B ; Hernandez Beltran, Jorge
> > ; Han, Harry 
> > Subject: RE: [PATCH v2 0/3] Common OBB verification feature
> >
> > Thanks Jian. Some comment below:
> >
> > 0) Please add what unit test has been done.
> >
> > 1) Can we use UINT64 for Base and Length?
> > typedef struct _HASHED_FV_INFO {
> >   UINT32  Base;
> >   UINT32  Length;
> >   UINT64  Flag;
> > } HASHED_FV_INFO;
> >
> 
> Yes, we can. But is it necessary? Isn't the flash address always below 4G?
> 
> > 2) Can we remove the hard code HASHED_FV_MAX_NUMBER and use more
> > flexible way?
> > #define HASHED_FV_MAX_NUMBER  10
> > struct _EDKII_PEI_FIRMWARE_VOLUME_INFO_STORED_HASH_FV_PPI {
> >   UINTN   FvNumber;
> >   HASHED_FV_INFO  FvInfo[HASHED_FV_MAX_NUMBER];
> >   UINTN   HashNumber;
> >   FV_HASH_INFOHashInfo[1];
> > };
> >
> 
> Yes. I thought we need more than one hash value here. I went through the
> whole
> logic here. Maybe one hash value is enough (no need to pass the hash value not
> meant for current boot mode). So we can put the FvInfo at the end of structure
> and remove the hard-coded fv number.
> 
> > 3) can we use better way to organize the table? It is weird to have so many
> zero.
> > Why not just use TPM_ALG_xxx as the first field and search?
> > STATIC CONST HASH_ALG_INFO mHashAlgInfo[] = {
> >   {0, NULL, NULL, NULL, NULL},//  TPM_ALG_ERROR
> >   {0, NULL, NULL, NULL, NULL},// 0001 TPM_ALG_FIRST
> >   {0, NULL, NULL, NULL, NULL},// 0002
> >   {0, NULL, NULL, NULL, NULL},// 0003
> >   {0, NULL, NULL, NULL, NULL},// 0004 TPM_ALG_SHA1
> >   {0, NULL, NULL, NULL, NULL},// 0005
> >   {0, NULL, NULL, NULL, NULL},// 0006 TPM_ALG_AES
> >   {0, NULL, NULL, NULL, NULL},// 0007
> >   {0, NULL, NULL, NULL, NULL},// 0008 TPM_ALG_KEYEDHASH
> >   {0, NULL, NULL, NULL, NULL},// 0009
> >   {0, NULL, NULL, NULL, NULL},// 000A
> >   {SHA256_DIGEST_SIZE, Sha256Init, Sha256Update, Sha256Final,
> > Sha256HashAll}, // 000B TPM_ALG_SHA256
> >   {SHA384_DIGEST_SIZE, Sha384Init, Sha384Update, Sha384Final,
> > Sha384HashAll}, // 000C TPM_ALG_SHA384
> >   {SHA512_DIGEST_SIZE, Sha512Init, Sha512Update, Sha512Final,
> > Sha512HashAll}, // 000D TPM_ALG_SHA512
> >   {0, NULL, NULL, NULL, NULL},// 000E
> >   {0, NULL, NULL, NULL, NULL},// 000F
> >   {0, NULL, NULL, NULL, NULL},// 0010 TPM_ALG_NULL
> > //{0, NULL, NULL, NULL, NULL},// 0011
> > //{0, NULL, NULL, NULL, NULL},// 0012 TPM_ALG_SM3_256
> > };
> >
> 
> I prefer the code directly index the algorithm info/methods as array. It
> makes code quite simpler.
> 
> > 4) Why not just add one bit say: skip in S3 ? Why need such complexity?
> > #define HASHED_FV_FLAG_SKIP_BOOT_MODE(Mode)   LShiftU64 (0x100,
> > (Mode))
> > #define FV_HASH_FLAG_BOOT_MODE(Mode)  LShiftU64 (1, (Mode))
> >
> > I am not sure how that works. Is boot mode bit start from BIT0 or BIT8 ? I 
> > am
> > confused.
> >
> > if ((StoredHashFvPpi->HashInfo[HashIndex].HashFlag
> >  & FV_HASH_FLAG_BOOT_MODE (BootMode)) != 0) {
> >   HashInfo = >HashInfo[HashIndex];
> >   break;
> > }
> >
> 
> Boot mode is just a const number less than 64. So 64 bits can hold all 
> different
> boot mode. Using this way is just to keep the flexibility to avoid code 
> change if
> we want to support more boot modes besides S3. But if there's never such
> possibility at all, you're right that one bit is enough.
> 
> > 5) Why the producer want skip both verified boot and measured boot? Is that
> > legal or illegal? If it is illegal, I prefer use ASSER() to tell people.
> > if ((FvInfo[FvIndex].Flag & HASHED_FV_FLAG_VERIFIED_BOOT) == 0 &&
> > (FvInfo[FvIndex].Flag & HASHED_FV_FLAG_MEASURED_BOOT) == 0) {
> >   continue;
> > }
> 
> Suppose there's a use case, most likely for developers, which need to disable
> security feature temporarily. The BIOS still need to boot. The developers 
> don't
> need to remove this driver in order to do it. I think it's 

Re: [edk2-devel] [PATCH v2 00/10] Duplicate required CSM components for OVMF

[Wu, Hao A]

Thanks all.
Series pushed via commits 0a35997643..b0663641c9.

Best Regards,
Hao Wu

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> David Woodhouse
> Sent: Thursday, June 13, 2019 5:40 AM
> To: Wu, Hao A; devel@edk2.groups.io
> Cc: Ni, Ray; Justen, Jordan L; Laszlo Ersek; Ard Biesheuvel
> Subject: Re: [edk2-devel] [PATCH v2 00/10] Duplicate required CSM
> components for OVMF
> 
> On Mon, 2019-05-27 at 11:03 +0800, Hao A Wu wrote:
> > '''
> > Please note that this series will be hold until the edk2-stable201905 is
> > created.
> > '''
> >
> > The series is also available at:
> > https://github.com/hwu25/edk2/tree/ovmf_csm_v2
> >
> > V2 changes:
> >
> > Discussion with David Woodhouse for him to take the reviewer role for the
> > duplicated CSM components under OvmfPkg:
> > https://edk2.groups.io/g/devel/topic/31682287#40996
> >
> > The (new) first patch will update the Maintainers.txt to reflect such
> > role.
> >
> >
> > V1 history:
> >
> > The series will duplicate the CSM components used by the OVMF package
> from
> > IntelFrameworkModulePkg & IntelFrameworkPkg.
> >
> > Verification done for the series:
> > * Build pass with/without build command option '-D CSM_ENABLE';
> > * Boot shell pass with the built images.
> >
> > Cc: David Woodhouse 
> > Cc: Ray Ni 
> > Cc: Jordan Justen 
> > Cc: Laszlo Ersek 
> > Cc: Ard Biesheuvel 
> >
> > Hao A Wu (10):
> >   Maintainers.txt: Add maintainer for CSM components in OvmfPkg
> >   OvmfPkg: Copy the required CSM components from framework packages
> >   OvmfPkg/OvmfPkg.dec: Add definitions for CSM-related Guid & Protocol
> >   OvmfPkg/OvmfPkg.dec: Add the new include folder for CSM header files
> >   OvmfPkg/OvmfPkg.dec: Add PCD definitions used by copied CSM
> modules
> >   OvmfPkg/Csm/VideoDxe: Update to make it build for OVMF
> >   OvmfPkg/Csm/LegacyBiosDxe: Update to make it build for OVMF
> >   OvmfPkg/Csm/LegacyBootMaintUiLib: Update to make it build for OVMF
> >   OvmfPkg/Csm/LegacyBootManagerLib: Update to make it build for OVMF
> >   OvmfPkg: Update DSC/FDF files to consume CSM components in OvmfPkg
> 
> I'll submit a [PATCH 11/10] in a moment which makes it actually work
> again. With that included, the first ten in the series are
> 
> Reviewed-by: David Woodhouse 
> 
> Thanks.
> 
> 
> 
> 


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

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

Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/SdMmcHcDxe: Implement revision 3 of SdMmcOverrideProtocol

[Wu, Hao A]

> -Original Message-
> From: Albecki, Mateusz
> Sent: Thursday, June 13, 2019 10:39 PM
> To: devel@edk2.groups.io
> Cc: Wu, Hao A
> Subject: RE: [PATCH 2/2] MdeModulePkg/SdMmcHcDxe: Implement revision
> 3 of SdMmcOverrideProtocol
> 
> Resending to group. Inline reply to some of the comments.
> 
> As for the mapping between eMMC driver strength and SD controller driver
> strength should we use this one:
> 
> SD controller -> eMMC card
> B-> Type 0
> A   -> Type 1
> C   -> Type 2
> D   -> Type 3
> (none)-> Type4


Yes, I think this matching is fine. Inspecting the SD & eMMC specs:

For SD Physical Layer Specification:
Driver Type Nominal Driving
Impedance   Capability
A   33Ω x1.5
B   50Ω x1
C   66Ω x0.75
D   100Ωx0.5

For Embedded Multi-Media Card (e.MMC) Electrical Standard:
Driver Type Nominal Approximated driver capability
Values  Impedance   compared to Type-0
0x0 50Ω x1
0x1 33Ω x1.5
0x2 66Ω x0.75
0x3 100Ωx0.5
0x4 40Ω x1.2

The above mapping is consistent with regard to the Nominal Impedance &
Driving Capability parameters.


> 
> And Type 4 would be identified by bit 39 in capability register which is
> currently marked as reserved in SD controller specification. This is current
> capability register definition in the driver.


I am not sure if the bit39 in the capability register works for all SD
host controller (because it is not documented in specs, as far as I know).
I suggest we just ignore the HC capability when setting driver strength
type 4 for eMMC devices.

Response to other inline comments below:


> 
> Thanks,
> Mateusz
> 
> > -Original Message-
> > From: Wu, Hao A
> > Sent: Monday, June 10, 2019 5:19 AM
> > To: Albecki, Mateusz 
> > Subject: RE: [PATCH 2/2] MdeModulePkg/SdMmcHcDxe: Implement
> revision
> > 3 of SdMmcOverrideProtocol
> >
> > Hello Mateusz,
> >
> > Some inline comments below:
> >
> > > -Original Message-
> > > From: Albecki, Mateusz
> > > Sent: Monday, June 03, 2019 7:34 PM
> > > Cc: Albecki, Mateusz; Wu, Hao A; Albecki
> > > Subject: [PATCH 2/2] MdeModulePkg/SdMmcHcDxe: Implement revision
> 3
> > > of SdMmcOverrideProtocol
> > >
> > > Implement support for GetOperatingParamters notify phase
> > > in SdMmcHcDxe driver. GetOperatingParameters notify phase
> > > is signaled before we start card detection and initialization.
> > > Code has been updated for both eMMC and SD card controllers to
> > > take into consideration those new parameters. Initialization process
> > > has been divided into 2 steps. In the first step we bring the link
> > > up to the point where we can get card identification data(Extended
> > > CSD in eMMC case and SWITCH command response in SD card case). This
> > > data is later used along with controller capabilities and operating
> > > parameters passed in GetOperatingParameters phase to choose
> preferred
> > > bus settings in GetTargetBusSettings function. Those settings are later
> > > on to start bus training to high speeds. If user passes incompatible
> > > setting with selected bus timing driver will assume it's standard behavior
> > with
> > > respect to that setting. For instance if HS400 has been selected as a
> > > target bus timing due to card and controller support bus width setting of
> > > 4 and 1 bit won't be respected and 8 bit setting will be chosen instead.
> > >
> > >
> > > Cc: hao.a...@intel.com
> > > Signed-off-by: Albecki, Mateusz 
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > ---
> > >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c| 522
> > > +++--
> > >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdDevice.c  | 381
> > > ---
> > >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c |  52 +-
> > >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h |  18 +-
> > >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c   |   8 +-
> > >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h   |   8 +-
> > >  6 files changed, 750 insertions(+), 239 deletions(-)
> > >
> > > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> > > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> > > index deaf4468c9..1a81f6d250 100644
> > > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> > > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> > > @@ -449,7 +449,7 @@ EFI_STATUS
> > >  EmmcSendTuningBlk (
> > >IN EFI_SD_MMC_PASS_THRU_PROTOCOL  *PassThru,
> > >IN UINT8  Slot,
> > > -  IN UINT8  BusWidth
> > > +  IN UINT16 BusWidth
> > >)
> > >  {
> > >EFI_SD_MMC_COMMAND_BLOCK  SdMmcCmdBlk;
> > > @@ -506,7 +506,7 @@ EmmcTuningClkForHs200 (
> > 

[edk2-devel] [PATCH V2] BaseTools:Add DetectNotUsedItem.py to Edk2\BaseTools\Scripts

[Fan, ZhijuX]

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

This script is used to Detect unreferenced PCD and GUID/Protocols/PPIs.
The input parameters are Dec file and package directory.

This script can be run in both Py2 and Py3.

Cc: Bob Feng 
Cc: Liming Gao 
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Scripts/DetectNotUsedItem.py | 199 +
 1 file changed, 199 insertions(+)
 create mode 100644 BaseTools/Scripts/DetectNotUsedItem.py

diff --git a/BaseTools/Scripts/DetectNotUsedItem.py 
b/BaseTools/Scripts/DetectNotUsedItem.py
new file mode 100644
index 00..7e3568fcf9
--- /dev/null
+++ b/BaseTools/Scripts/DetectNotUsedItem.py
@@ -0,0 +1,199 @@
+## @file
+# Detect unreferenced PCD and GUID/Protocols/PPIs.
+#
+# Copyright (c) 2019, Intel Corporation. All rights reserved.
+#
+# SPDX-License-Identifier: BSD-2-Clause-Patent
+#
+
+'''
+DetectNotUsedItem
+'''
+import re
+import os
+import sys
+import argparse
+
+#
+# Globals for help information
+#
+__prog__ = 'DetectNotUsedItem'
+__version__ = '%s Version %s' % (__prog__, '0.1')
+__copyright__ = 'Copyright (c) 2019, Intel Corporation. All rights reserved.'
+__description__ = "Detect unreferenced PCD and GUID/Protocols/PPIs.\n"
+
+SectionList = ["LibraryClasses", "Guids", "Ppis", "Protocols", "Pcd"]
+
+
+class PROCESS(object):
+
+def __init__(self, DecPath, InfDirs):
+self.Dec = DecPath
+self.InfPath = InfDirs
+self.Log = []
+
+def ParserDscFdfInfFile(self):
+AllContentList = []
+for File in self.SearchbyExt([".dsc", ".fdf", ".inf"]):
+AllContentList += self.ParseDscFdfInfContent(File)
+return AllContentList
+
+# Search File by extension name
+def SearchbyExt(self, ExtList):
+FileList = []
+for path in self.InfPath:
+if type(ExtList) == type(''):
+for root, _, files in os.walk(path, topdown=True, 
followlinks=False):
+for filename in files:
+if filename.endswith(ExtList):
+FileList.append(os.path.join(root, filename))
+elif type(ExtList) == type([]):
+for root, _, files in os.walk(path, topdown=True, 
followlinks=False):
+for filename in files:
+for Ext in ExtList:
+if filename.endswith(Ext):
+FileList.append(os.path.join(root, filename))
+return FileList
+
+# Parse DEC file to get Line number and Name
+# return section name, the Item Name and comments line number
+def ParseDecContent(self):
+SectionRE = re.compile(r'\[(.*)\]')
+Flag = False
+Comments = {}
+Comment_Line = []
+ItemName = {}
+with open(self.Dec, 'r') as F:
+for Index, content in enumerate(F):
+NotComment = not content.strip().startswith("#")
+Section = SectionRE.findall(content)
+if Section and NotComment:
+Flag = self.IsNeedParseSection(Section[0])
+if Flag:
+Comment_Line.append(Index)
+if NotComment:
+if content != "\n" and content != "\r\n":
+ItemName[Index] = 
content.split('=')[0].split('|')[0].split('#')[0].strip()
+Comments[Index] = Comment_Line
+Comment_Line = []
+return ItemName, Comments
+
+def IsNeedParseSection(self, SectionName):
+for item in SectionList:
+if item in SectionName:
+return True
+return False
+
+# Parse DSC, FDF, INF File, remove comments, return Lines list
+def ParseDscFdfInfContent(self, File):
+with open(File, 'r') as F:
+lines = F.readlines()
+for Index in range(len(lines) - 1, -1, -1):
+if lines[Index].strip().startswith("#") or lines[Index] == "\n" or 
lines[Index] == "\r\n":
+lines.remove(lines[Index])
+elif "#" in lines[Index]:
+lines[Index] = lines[Index].split("#")[0].strip()
+else:
+lines[Index] = lines[Index].strip()
+return lines
+
+def DetectNotUsedItem(self):
+NotUsedItem = {}
+DecItem, DecComments = self.ParseDecContent()
+InfDscFdfContent = self.ParserDscFdfInfFile()
+for LineNum in list(DecItem.keys()):
+DecItemName = DecItem[LineNum]
+Match_reg = re.compile("(?

Re: [edk2-devel] [PATCH 0/2] Add GetOperatingParam notify phase to SdMmcOverride protocol

[Wu, Hao A]

Loop in Ard and Marcin.


Hello Ard and Marcin,

We are proposing to make an extension to the SDMMC Override protocol to
more customization for platforms during the SD/eMMC device/controller
initialization process.

For convenience, the series is available at:
https://github.com/hwu25/edk2/tree/sdmmc_override_extension_v1

I only verified the change will not break the build for platforms
(in edk2-platform repo). Could you help provide feedbacks for this series?
Thanks in advance.

Best Regards,
Hao Wu

From: Albecki, Mateusz
Sent: Thursday, June 13, 2019 9:44 PM
To: devel@edk2.groups.io
Cc: Wu, Hao A
Subject: RE: [PATCH 0/2] Add GetOperatingParam notify phase to SdMmcOverride 
protocol

Resending to group.

From: Wu, Hao A
Sent: Monday, June 10, 2019 5:18 AM
To: Albecki, Mateusz 
Subject: RE: [PATCH 0/2] Add GetOperatingParam notify phase to SdMmcOverride 
protocol


Hello Mateusz,



Thanks for the patch series and sorry for the delayed response.



One question first, I did not see the patches being sent to the mailing list

'devel@edk2.groups.io'. We have recently switched to this new mailing list back

to early April, the old one 'edk2-de...@lists.01.org' is no longer being used.



In case that you have not registered the new list, you can sign up at:

https://edk2.groups.io/g/devel

or email:

devel+subscr...@edk2.groups.io

to get registered in the new mailing list.



Or you can send me the patch files and I will help to send them to the mailing 
list.





Below are some general level feedbacks (Other patch-specific feedbacks will be 
replied in other mails):

* Could you help to add the below Bugzilla tracker reference in the 
commit log message?

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



* Could you help to run the script 'BaseTools/Scripts/PatchCheck.py' 
and resolve its report on the commit log format issues?

Checking git commit: 6e3f64aeb4

The commit message format is not valid:

* Contributed-under! (Note: this must be removed by the code contributor!)

* Add quotes (") around name with a comma: Albecki, Mateusz

* Email format is invalid: hao.a...@intel.com

* Line 15 of commit message is too long.

https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format

The code passed all checks.



Checking git commit: 91595ae911

The commit message format is not valid:

* Contributed-under! (Note: this must be removed by the code contributor!)

* Add quotes (") around name with a comma: Albecki, Mateusz

* Email format is invalid: hao.a...@intel.com

https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format

The code passed all checks.



* Could you help to resolve the typo 'Prefered' to 'Preferred' in the 
naming of some variables?



* Could you help to use lowercase 'static' (instead of using the 
uppercase one) for the new functions?





Also, I only verified the build of the patch series. Please grant me some time

to verify on the HW on my side. Maybe your updated patches arrive first and I

will then verify the update ones.





Best Regards,

Hao Wu



> -Original Message-

> From: Albecki, Mateusz

> Sent: Monday, June 03, 2019 7:34 PM

> Cc: Albecki, Mateusz; Wu, Hao A

> Subject: [PATCH 0/2] Add GetOperatingParam notify phase to

> SdMmcOverride protocol

>

> To allow platform greater control over the bus settings for SD card and

> eMMC card

> we have added a new notify phase to SdMmcOverrideProtocol called

> GetOperatingParam.

> This phase is signaled before SD card/eMMC initialization and allows platform

> to tweak

> the values in new structure called

> EDKII_SD_MMC_OPERATING_PARAMETERS which allows to configure

> bus width, clock frequency and driver strength. Other bus parameters can be

> configured by

> overriding host controller capabilities.

>

> Tests:

> - OS boot from eMMC without SdMmcOverride protocol installed

> - OS boot from eMMC with SdMmcOverride installed and clock frequency

> lowered to 100MHz in HS200

> - OS boot from eMMC with driver strength changed to Type1

> - SD card enumeration in UEFI shell on default speed and high speed(non

> UHS-I) with SdMmcOverride installed and UHS-I disabled in capability

>

>

> Cc: hao.a...@intel.com

>

> Albecki, Mateusz (2):

>   MdeModulePkg/SdMmcOverride: Add GetOperatingParam notify phase

>   MdeModulePkg/SdMmcHcDxe: Implement revision 3 of

> SdMmcOverrideProtocol

>

>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c| 522

> +++--

>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdDevice.c  | 381

> ---

>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c |  52 +-

>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h |  18 +-

>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c   |   8 +-

>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h   |   8 +-

>  

[edk2-devel] Upcoming Event: TianoCore Design Meeting - APAC/NAMO - Thu, 06/13/2019 6:30pm-7:30pm #cal-reminder

[devel@edk2.groups.io Calendar]

*Reminder:* TianoCore Design Meeting - APAC/NAMO

*When:* Thursday, 13 June 2019, 6:30pm to 7:30pm, (GMT-07:00) America/Los 
Angeles

*Where:* https://zoom.us/j/969264410

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=458028 )

*Organizer:* Stephano Cetola stephano.cet...@intel.com ( 
stephano.cet...@intel.com?subject=Re:%20Event:%20TianoCore%20Design%20Meeting%20-%20APAC%2FNAMO
 )

*Description:*

Join Zoom Meeting

https://zoom.us/j/969264410 ( https://zoom.us/j/969264410 )

*TOPICS*
CPU V2 Extended Topology Support - Ray (Intel)

https://edk2.groups.io/g/devel/files/Designs/2019/0613

One tap mobile

+16465588656,,969264410# US (New York)

+17207072699,,969264410# US

Dial by your location

+1 646 558 8656 US (New York)

+1 720 707 2699 US

Meeting ID: 969 264 410

Find your local number: https://zoom.us/u/abOtdJckxL

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

View/Reply Online (#42404): https://edk2.groups.io/g/devel/message/42404
Mute This Topic: https://groups.io/mt/32059233/21656
Mute #cal-reminder: https://groups.io/mk?hashtag=cal-reminder=3846945
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [RFC][edk2-platform][Add new packages in Platform\Intel directory]

[Yao, Jiewen]

Yes, ok for me.
Good idea to add the overview of the package content.

Thank you
Yao Jiewen

From: Oram, Isaac W
Sent: Friday, June 14, 2019 8:55 AM
To: Gao, Liming ; Yao, Jiewen ; 
Dong, Eric ; devel@edk2.groups.io; Kinney, Michael D 

Subject: RE: [RFC][edk2-platform][Add new packages in Platform\Intel directory]

This looks good to me.  I would suggest that we also capture an overview of the 
organization and the targeted contents of the different packages in the 
Platform/Intel/Readme.md or maybe a wiki page.

Thanks,
Isaac

From: Gao, Liming
Sent: Wednesday, June 12, 2019 6:27 AM
To: Oram, Isaac W mailto:isaac.w.o...@intel.com>>; Yao, 
Jiewen mailto:jiewen@intel.com>>; Dong, Eric 
mailto:eric.d...@intel.com>>; 
devel@edk2.groups.io; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Cc: Gao, Liming mailto:liming@intel.com>>
Subject: RE: [RFC][edk2-platform][Add new packages in Platform\Intel directory]

Isaac and Eric:
  Here is the proposal for new packages in Platform\Intel directory.

BoardModulePkg: This package includes the libraries shared between the 
different board packages. Those libraries are linked by the drivers in the 
board packages.
DebugFeaturePkg: This package provides the debug features, such as debug 
library, debug method.
ManageabilityFeaturePkg: This package provides the system management driver, 
such as Ipmi, Smbios.
DeviceFeaturePkg: This package provides the different device support, such as 
SIO controller, Network.
UserInterfaceFeaturePkg: This package provides UI related modules, such as 
Logo, Setup page.

Thanks
Liming
From: Oram, Isaac W
Sent: Tuesday, June 4, 2019 4:25 PM
To: Yao, Jiewen mailto:jiewen@intel.com>>; Dong, Eric 
mailto:eric.d...@intel.com>>; 
devel@edk2.groups.io; Gao, Liming 
mailto:liming@intel.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: RE: [RFC][edk2-platform][Add new packages in Platform\Intel directory]

Eric,

I have envisioned less granular packages for advanced features.  One of the 
goals for MinPlatform is to improve usability during porting.  The idea is that 
you would do basic board porting with minimal effort to get your system 
functional.  Then you would enable additional features by adding collections of 
features to your baseline.  Then as a last step optimize out unnecessary 
things.  This is something like a functionality oriented porting approach.  Get 
all the functionality you need by building up, then optimize out.  I would 
characterize Intel's traditional reference platforms as having everything and 
then adding and removing from a starting point that was very feature rich.  The 
challenge we seemed to face was that it was hard to remove things with the 
feature rich starting point.

As an example of functionality oriented porting, say that I set up my basic 
server port by starting with the Purley open board package.  I port it to my 
motherboard, then I check out my baseline functionality.  Then I add 
manageability features by including DSC/FDF from the ManageabilityFeaturePkg 
that add FV to my MinPlatform port.  And I repeat for other sets of features 
until I get all of the features that I need.  Then I optimize: for size, speed, 
to reduce complexity, and so on.  It would be best if this optimization were 
tool assisted to a great degree, e.g a more sophisticated FMMT that lets one 
cut out extra components.

My concern is that if we allow very specific feature packages, like the 
UserAuthenticationPkg, we are very much like today.  Yes, you can select any 
drivers you need and add to your DSC/FDF.  But that is very quickly 
overwhelming.  There are hundreds of drivers and what they require is often 
complex to determine.  Thus we tend to copy something else and customize it.  
This tends to lead to lots of technical debt and complexity.

I am thinking that we should target something like 10-20 advanced feature 
packages that produce one or two (if features have pre-memory components) FV 
with a set of features and simpler dependencies.  We are just in the early 
stages of defining what this would look like, and our thinking is evolving.  We 
have identified Manageability and Debug as feature collections.  I think that 
there is one for adding USB, network, Bluetooth and such peripheral support.  I 
think setup browser and UI stuff will go somewhere.  We can mine a few 
reference platforms for data.

Let's discuss this in person and make a proposal for organization for feature 
packages and the rules for what goes where.  We can add this proposal to your 
RFC and I think that will help guide the future development of the 
Platform\Intel contents.

Regards,
Isaac


From: Yao, Jiewen
Sent: Monday, June 3, 2019 9:03 AM
To: Dong, Eric mailto:eric.d...@intel.com>>; 
devel@edk2.groups.io; Gao, Liming 
mailto:liming@intel.com>>; Kubacki, Michael A 
mailto:michael.a.kuba...@intel.com>>; Oram, 

Re: [edk2-devel] [RFC][edk2-platform][Add new packages in Platform\Intel directory]

[Oram, Isaac W]

This looks good to me.  I would suggest that we also capture an overview of the 
organization and the targeted contents of the different packages in the 
Platform/Intel/Readme.md or maybe a wiki page.

Thanks,
Isaac

From: Gao, Liming
Sent: Wednesday, June 12, 2019 6:27 AM
To: Oram, Isaac W ; Yao, Jiewen ; 
Dong, Eric ; devel@edk2.groups.io; Kinney, Michael D 

Cc: Gao, Liming 
Subject: RE: [RFC][edk2-platform][Add new packages in Platform\Intel directory]

Isaac and Eric:
  Here is the proposal for new packages in Platform\Intel directory.

BoardModulePkg: This package includes the libraries shared between the 
different board packages. Those libraries are linked by the drivers in the 
board packages.
DebugFeaturePkg: This package provides the debug features, such as debug 
library, debug method.
ManageabilityFeaturePkg: This package provides the system management driver, 
such as Ipmi, Smbios.
DeviceFeaturePkg: This package provides the different device support, such as 
SIO controller, Network.
UserInterfaceFeaturePkg: This package provides UI related modules, such as 
Logo, Setup page.

Thanks
Liming
From: Oram, Isaac W
Sent: Tuesday, June 4, 2019 4:25 PM
To: Yao, Jiewen mailto:jiewen@intel.com>>; Dong, Eric 
mailto:eric.d...@intel.com>>; 
devel@edk2.groups.io; Gao, Liming 
mailto:liming@intel.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: RE: [RFC][edk2-platform][Add new packages in Platform\Intel directory]

Eric,

I have envisioned less granular packages for advanced features.  One of the 
goals for MinPlatform is to improve usability during porting.  The idea is that 
you would do basic board porting with minimal effort to get your system 
functional.  Then you would enable additional features by adding collections of 
features to your baseline.  Then as a last step optimize out unnecessary 
things.  This is something like a functionality oriented porting approach.  Get 
all the functionality you need by building up, then optimize out.  I would 
characterize Intel's traditional reference platforms as having everything and 
then adding and removing from a starting point that was very feature rich.  The 
challenge we seemed to face was that it was hard to remove things with the 
feature rich starting point.

As an example of functionality oriented porting, say that I set up my basic 
server port by starting with the Purley open board package.  I port it to my 
motherboard, then I check out my baseline functionality.  Then I add 
manageability features by including DSC/FDF from the ManageabilityFeaturePkg 
that add FV to my MinPlatform port.  And I repeat for other sets of features 
until I get all of the features that I need.  Then I optimize: for size, speed, 
to reduce complexity, and so on.  It would be best if this optimization were 
tool assisted to a great degree, e.g a more sophisticated FMMT that lets one 
cut out extra components.

My concern is that if we allow very specific feature packages, like the 
UserAuthenticationPkg, we are very much like today.  Yes, you can select any 
drivers you need and add to your DSC/FDF.  But that is very quickly 
overwhelming.  There are hundreds of drivers and what they require is often 
complex to determine.  Thus we tend to copy something else and customize it.  
This tends to lead to lots of technical debt and complexity.

I am thinking that we should target something like 10-20 advanced feature 
packages that produce one or two (if features have pre-memory components) FV 
with a set of features and simpler dependencies.  We are just in the early 
stages of defining what this would look like, and our thinking is evolving.  We 
have identified Manageability and Debug as feature collections.  I think that 
there is one for adding USB, network, Bluetooth and such peripheral support.  I 
think setup browser and UI stuff will go somewhere.  We can mine a few 
reference platforms for data.

Let's discuss this in person and make a proposal for organization for feature 
packages and the rules for what goes where.  We can add this proposal to your 
RFC and I think that will help guide the future development of the 
Platform\Intel contents.

Regards,
Isaac


From: Yao, Jiewen
Sent: Monday, June 3, 2019 9:03 AM
To: Dong, Eric mailto:eric.d...@intel.com>>; 
devel@edk2.groups.io; Gao, Liming 
mailto:liming@intel.com>>; Kubacki, Michael A 
mailto:michael.a.kuba...@intel.com>>; Oram, Isaac 
W mailto:isaac.w.o...@intel.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Subject: RE: [RFC][edk2-platform][Add new packages in Platform\Intel directory]

Since there is no other module, I think we can use this specific package name 
to tell people what it is.
It is also good for feature isolation.

Thank you
Yao Jiewen

From: Dong, Eric
Sent: Monday, June 3, 2019 8:53 AM
To: Yao, Jiewen mailto:jiewen@intel.com>>; 
devel@edk2.groups.io; 

Re: [edk2-devel] [PATCH v4 0/2] Add SCSI Support for Storage Security Command Protocol

[Wu, Hao A]

> -Original Message-
> From: Yao, Jiewen
> Sent: Friday, June 14, 2019 6:32 AM
> To: Zurcher, Christopher J; Gao, Liming; devel@edk2.groups.io
> Cc: Kinney, Michael D; Wang, Jian J; Ni, Ray; Wu, Hao A
> Subject: RE: [PATCH v4 0/2] Add SCSI Support for Storage Security Command
> Protocol
> 
> Thank you Christopher.
> Your code looks good to me.
> 
> I also recommend MdeModulePkg/SCSI owner take a look and give r-b.
> 
> Ray or Hao
> Can you help on that?


Yes, I will take a look.
Please grant me some time, will give my feedbacks early next week.

Best Regards,
Hao Wu


> 
> Thank you
> Yao Jiewen
> 
> > -Original Message-
> > From: Zurcher, Christopher J
> > Sent: Friday, June 14, 2019 6:26 AM
> > To: Gao, Liming ; devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Yao, Jiewen
> > ; Wang, Jian J 
> > Subject: RE: [PATCH v4 0/2] Add SCSI Support for Storage Security
> Command
> > Protocol
> >
> > A unit test has been run which provisions RPMB key, writes data, and
> verifies
> > it after reading on the following boot.
> > Further, this code is being exercised for secure storage on multiple
> platforms
> > as part of standard boot flow.
> >
> > Unit test files emailed separately.
> >
> > Thanks,
> > Christopher Zurcher
> >
> >
> > -Original Message-
> > From: Gao, Liming
> > Sent: Thursday, June 13, 2019 05:59
> > To: Zurcher, Christopher J ;
> > devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Yao, Jiewen
> > ; Wang, Jian J 
> > Subject: RE: [PATCH v4 0/2] Add SCSI Support for Storage Security
> Command
> > Protocol
> >
> > Zurcher:
> >   Can you share what test has been done for this feature?
> >
> > Thanks
> > Liming
> > > -Original Message-
> > > From: Zurcher, Christopher J
> > > Sent: Thursday, June 13, 2019 10:05 AM
> > > To: devel@edk2.groups.io
> > > Cc: Kinney, Michael D ; Yao, Jiewen
> > ; Wang, Jian J ; Gao,
> > > Liming 
> > > Subject: [PATCH v4 0/2] Add SCSI Support for Storage Security Command
> > Protocol
> > >
> > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1546
> > >
> > > V4 changes:
> > > Add SSC Protocol in addition to BlockIo instead of in place of BlockIo.
> > > Add error handling for (BlockSize == 0) in Read and WriteBlocks
> commands
> > > to handle partitions that do not support ReadCapacity().
> > >
> > > V3 changes:
> > > Initialize AlignedBuffer variable in ScsiDiskReceiveData and
> > > ScsiDiskSendData functions. Remove redundant input validation and
> debug
> > > message in ScsiDiskSendData.
> > >
> > > V2 changes:
> > > Split the patch into separate commits for separate packages.
> > >
> > > To support RPMB access on UFS devices, support must be added to
> > > the ScsiDiskDxe driver for the Storage Security Command Protocol.
> > >
> > > Cc: Michael D Kinney 
> > > Cc: Jiewen Yao 
> > > Cc: Jian J Wang 
> > > Cc: Liming Gao 
> > >
> > > Christopher J Zurcher (2):
> > >   MdePkg: Implement SCSI commands for Security Protocol In/Out
> > >   MdeModulePkg/ScsiDiskDxe: Support Storage Security Command
> > Protocol
> > >
> > >  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf |   3 +-
> > >  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h  | 171 ++-
> > >  MdePkg/Include/IndustryStandard/Scsi.h|  48 +-
> > >  MdePkg/Include/Library/UefiScsiLib.h  | 126 -
> > >  MdePkg/Include/Protocol/ScsiIo.h  |   9 +-
> > >  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c|   5 +-
> > >  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c  | 522
> > +++-
> > >  MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c |  19 +-
> > >  MdePkg/Library/UefiScsiLib/UefiScsiLib.c  | 205 +++-
> > >  9 files changed, 1064 insertions(+), 44 deletions(-)
> > >
> > > --
> > > 2.16.2.windows.1


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

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

[edk2-devel] Upcoming Event: TianoCore Bug Triage - APAC / NAMO - Thu, 06/13/2019 5:00pm-5:30pm #cal-reminder

[devel@edk2.groups.io Calendar]

*Reminder:* TianoCore Bug Triage - APAC / NAMO

*When:* Thursday, 13 June 2019, 5:00pm to 5:30pm, (GMT-07:00) America/Los 
Angeles

*Where:* https://zoom.us/j/769108409

View Event ( https://edk2.groups.io/g/devel/viewevent?eventid=458031 )

*Organizer:* Stephano Cetola stephano.cet...@intel.com ( 
stephano.cet...@intel.com?subject=Re:%20Event:%20TianoCore%20Bug%20Triage%20-%20APAC%20%2F%20NAMO
 )

*Description:*

Join Zoom Meeting

https://zoom.us/j/769108409 ( https://zoom.us/j/769108409 )

One tap mobile

+17207072699,,769108409# US

+16465588656,,769108409# US (New York)

Dial by your location

+1 720 707 2699 US

+1 646 558 8656 US (New York)

Meeting ID: 769 108 409

Find your local number: https://zoom.us/u/abOtdJckxL

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

View/Reply Online (#42398): https://edk2.groups.io/g/devel/message/42398
Mute This Topic: https://groups.io/mt/32058514/21656
Mute #cal-reminder: https://groups.io/mk?hashtag=cal-reminder=3846945
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] CryptoPkg: define DSO_NONE in the OpenSSL build

[rebecca]

On 2019-06-13 17:32, Rebecca Cran wrote:
> This fixes the build on FreeBSD, where DSO_METHOD_openssl is undefined
> since dso_openssl.c only compiles the function if DSO_NONE is defined.

Sorry, I just realized this isn't applicable to the OpenSSL we currently
pull in: I was testing against OpenSSL_1_1_1-stable where they changed
the configuration in
https://github.com/openssl/openssl/commit/5fba3afad01707f4a8856a35500de007a8a256ec#diff-e1ea891baa345b284ad0a5a663bb9b20
:


"Rework DSO API conditions and configuration option

'no-dso' is meaningless, as it doesn't get any macro defined.
Therefore, we remove all checks of OPENSSL_NO_DSO.  However, there may
be some odd platforms with no DSO scheme.  For those, we generate the
internal macro DSO_NONE aand use it."



So please ignore this.


-- 
Rebecca Cran


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

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

[edk2-devel] [PATCH] CryptoPkg: define DSO_NONE in the OpenSSL build

[rebecca]

This fixes the build on FreeBSD, where DSO_METHOD_openssl is undefined
since dso_openssl.c only compiles the function if DSO_NONE is defined.

Signed-off-by: Rebecca Cran 
---
 CryptoPkg/Library/OpensslLib/OpensslLib.inf   | 2 +-
 CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/CryptoPkg/Library/OpensslLib/OpensslLib.inf 
b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
index 5f36edeeef..fa8cc660be 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLib.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLib.inf
@@ -15,7 +15,7 @@
   VERSION_STRING = 1.0
   LIBRARY_CLASS  = OpensslLib
   DEFINE OPENSSL_PATH= openssl
-  DEFINE OPENSSL_FLAGS   = -DL_ENDIAN -DOPENSSL_SMALL_FOOTPRINT 
-D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE
+  DEFINE OPENSSL_FLAGS   = -DL_ENDIAN -DOPENSSL_SMALL_FOOTPRINT 
-D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DDSO_NONE
 
 #
 #  VALID_ARCHITECTURES   = IA32 X64 ARM AARCH64
diff --git a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf 
b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
index de05cac931..680df19a4a 100644
--- a/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
+++ b/CryptoPkg/Library/OpensslLib/OpensslLibCrypto.inf
@@ -15,7 +15,7 @@
   VERSION_STRING = 1.0
   LIBRARY_CLASS  = OpensslLib
   DEFINE OPENSSL_PATH= openssl
-  DEFINE OPENSSL_FLAGS   = -DL_ENDIAN -DOPENSSL_SMALL_FOOTPRINT 
-D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE
+  DEFINE OPENSSL_FLAGS   = -DL_ENDIAN -DOPENSSL_SMALL_FOOTPRINT 
-D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DDSO_NONE
 
 #
 #  VALID_ARCHITECTURES   = IA32 X64 ARM AARCH64
-- 
2.21.0


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

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

Re: [edk2-devel] [PATCH v4 0/2] Add SCSI Support for Storage Security Command Protocol

[Yao, Jiewen]

Thank you Christopher.
Your code looks good to me.

I also recommend MdeModulePkg/SCSI owner take a look and give r-b.

Ray or Hao
Can you help on that?

Thank you
Yao Jiewen

> -Original Message-
> From: Zurcher, Christopher J
> Sent: Friday, June 14, 2019 6:26 AM
> To: Gao, Liming ; devel@edk2.groups.io
> Cc: Kinney, Michael D ; Yao, Jiewen
> ; Wang, Jian J 
> Subject: RE: [PATCH v4 0/2] Add SCSI Support for Storage Security Command
> Protocol
> 
> A unit test has been run which provisions RPMB key, writes data, and verifies
> it after reading on the following boot.
> Further, this code is being exercised for secure storage on multiple platforms
> as part of standard boot flow.
> 
> Unit test files emailed separately.
> 
> Thanks,
> Christopher Zurcher
> 
> 
> -Original Message-
> From: Gao, Liming
> Sent: Thursday, June 13, 2019 05:59
> To: Zurcher, Christopher J ;
> devel@edk2.groups.io
> Cc: Kinney, Michael D ; Yao, Jiewen
> ; Wang, Jian J 
> Subject: RE: [PATCH v4 0/2] Add SCSI Support for Storage Security Command
> Protocol
> 
> Zurcher:
>   Can you share what test has been done for this feature?
> 
> Thanks
> Liming
> > -Original Message-
> > From: Zurcher, Christopher J
> > Sent: Thursday, June 13, 2019 10:05 AM
> > To: devel@edk2.groups.io
> > Cc: Kinney, Michael D ; Yao, Jiewen
> ; Wang, Jian J ; Gao,
> > Liming 
> > Subject: [PATCH v4 0/2] Add SCSI Support for Storage Security Command
> Protocol
> >
> > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1546
> >
> > V4 changes:
> > Add SSC Protocol in addition to BlockIo instead of in place of BlockIo.
> > Add error handling for (BlockSize == 0) in Read and WriteBlocks commands
> > to handle partitions that do not support ReadCapacity().
> >
> > V3 changes:
> > Initialize AlignedBuffer variable in ScsiDiskReceiveData and
> > ScsiDiskSendData functions. Remove redundant input validation and debug
> > message in ScsiDiskSendData.
> >
> > V2 changes:
> > Split the patch into separate commits for separate packages.
> >
> > To support RPMB access on UFS devices, support must be added to
> > the ScsiDiskDxe driver for the Storage Security Command Protocol.
> >
> > Cc: Michael D Kinney 
> > Cc: Jiewen Yao 
> > Cc: Jian J Wang 
> > Cc: Liming Gao 
> >
> > Christopher J Zurcher (2):
> >   MdePkg: Implement SCSI commands for Security Protocol In/Out
> >   MdeModulePkg/ScsiDiskDxe: Support Storage Security Command
> Protocol
> >
> >  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf |   3 +-
> >  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h  | 171 ++-
> >  MdePkg/Include/IndustryStandard/Scsi.h|  48 +-
> >  MdePkg/Include/Library/UefiScsiLib.h  | 126 -
> >  MdePkg/Include/Protocol/ScsiIo.h  |   9 +-
> >  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c|   5 +-
> >  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c  | 522
> +++-
> >  MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c |  19 +-
> >  MdePkg/Library/UefiScsiLib/UefiScsiLib.c  | 205 +++-
> >  9 files changed, 1064 insertions(+), 44 deletions(-)
> >
> > --
> > 2.16.2.windows.1


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

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

Re: [edk2-devel] [PATCH v4 0/2] Add SCSI Support for Storage Security Command Protocol

[Zurcher, Christopher J]

A unit test has been run which provisions RPMB key, writes data, and verifies 
it after reading on the following boot.
Further, this code is being exercised for secure storage on multiple platforms 
as part of standard boot flow.

Unit test files emailed separately.

Thanks,
Christopher Zurcher


-Original Message-
From: Gao, Liming 
Sent: Thursday, June 13, 2019 05:59
To: Zurcher, Christopher J ; 
devel@edk2.groups.io
Cc: Kinney, Michael D ; Yao, Jiewen 
; Wang, Jian J 
Subject: RE: [PATCH v4 0/2] Add SCSI Support for Storage Security Command 
Protocol

Zurcher:
  Can you share what test has been done for this feature?

Thanks
Liming
> -Original Message-
> From: Zurcher, Christopher J
> Sent: Thursday, June 13, 2019 10:05 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Yao, Jiewen 
> ; Wang, Jian J ; Gao,
> Liming 
> Subject: [PATCH v4 0/2] Add SCSI Support for Storage Security Command Protocol
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1546
> 
> V4 changes:
> Add SSC Protocol in addition to BlockIo instead of in place of BlockIo.
> Add error handling for (BlockSize == 0) in Read and WriteBlocks commands
> to handle partitions that do not support ReadCapacity().
> 
> V3 changes:
> Initialize AlignedBuffer variable in ScsiDiskReceiveData and
> ScsiDiskSendData functions. Remove redundant input validation and debug
> message in ScsiDiskSendData.
> 
> V2 changes:
> Split the patch into separate commits for separate packages.
> 
> To support RPMB access on UFS devices, support must be added to
> the ScsiDiskDxe driver for the Storage Security Command Protocol.
> 
> Cc: Michael D Kinney 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Liming Gao 
> 
> Christopher J Zurcher (2):
>   MdePkg: Implement SCSI commands for Security Protocol In/Out
>   MdeModulePkg/ScsiDiskDxe: Support Storage Security Command Protocol
> 
>  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf |   3 +-
>  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h  | 171 ++-
>  MdePkg/Include/IndustryStandard/Scsi.h|  48 +-
>  MdePkg/Include/Library/UefiScsiLib.h  | 126 -
>  MdePkg/Include/Protocol/ScsiIo.h  |   9 +-
>  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c|   5 +-
>  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c  | 522 +++-
>  MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c |  19 +-
>  MdePkg/Library/UefiScsiLib/UefiScsiLib.c  | 205 +++-
>  9 files changed, 1064 insertions(+), 44 deletions(-)
> 
> --
> 2.16.2.windows.1


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

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

Re: [edk2-devel] [PATCH v4 1/2] MdePkg: Implement SCSI commands for Security Protocol In/Out

[Zurcher, Christopher J]

> Why remove ASCIT8_1 & ASCIT8_2? Can we keep them for compatibility?

If that's preferred, I can add them back in. They were only removed as they are 
marked obsolete in SPC-5.

--
Christopher Zurcher

-Original Message-
From: Gao, Liming 
Sent: Thursday, June 13, 2019 05:54
To: Zurcher, Christopher J ; 
devel@edk2.groups.io
Cc: Yao, Jiewen ; Wang, Jian J 
Subject: RE: [PATCH v4 1/2] MdePkg: Implement SCSI commands for Security 
Protocol In/Out


> -Original Message-
> From: Zurcher, Christopher J
> Sent: Thursday, June 13, 2019 10:05 AM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen ; Wang, Jian J ; 
> Gao, Liming 
> Subject: [PATCH v4 1/2] MdePkg: Implement SCSI commands for Security Protocol 
> In/Out
> 
> This patch implements the Security Protocol In and Security Protocol Out
> commands in UefiScsiLib to prepare support for the Storage Security
> Command Protocol.
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Liming Gao 
> Signed-off-by: Christopher J Zurcher 
> ---
>  MdePkg/Include/IndustryStandard/Scsi.h   |  48 +++--
>  MdePkg/Include/Library/UefiScsiLib.h | 126 +++-
>  MdePkg/Include/Protocol/ScsiIo.h |   9 +-
>  MdePkg/Library/UefiScsiLib/UefiScsiLib.c | 205 +++-
>  4 files changed, 366 insertions(+), 22 deletions(-)
> 
> diff --git a/MdePkg/Include/IndustryStandard/Scsi.h 
> b/MdePkg/Include/IndustryStandard/Scsi.h
> index cbe5709fe5..10d7b49ba7 100644
> --- a/MdePkg/Include/IndustryStandard/Scsi.h
> +++ b/MdePkg/Include/IndustryStandard/Scsi.h
> @@ -1,7 +1,7 @@
>  /** @file
>Support for SCSI-2 standard
> 
> -  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -163,6 +163,12 @@
>  #define EFI_SCSI_OP_SEND_MESSAGE10  0x2a
>  #define EFI_SCSI_OP_SEND_MESSAGE12  0xaa
> 
> +//
> +// Additional commands for Secure Transactions
> +//
> +#define EFI_SCSI_OP_SECURITY_PROTOCOL_IN  0xa2
> +#define EFI_SCSI_OP_SECURITY_PROTOCOL_OUT 0xb5
> +
>  //
>  // SCSI Data Transfer Direction
>  //
> @@ -172,22 +178,30 @@
>  //
>  // Peripheral Device Type Definitions
>  //
> -#define EFI_SCSI_TYPE_DISK  0x00  ///< Direct-access device (e.g. 
> magnetic disk)
> -#define EFI_SCSI_TYPE_TAPE  0x01  ///< Sequential-access device 
> (e.g. magnetic tape)
> -#define EFI_SCSI_TYPE_PRINTER   0x02  ///< Printer device
> -#define EFI_SCSI_TYPE_PROCESSOR 0x03  ///< Processor device
> -#define EFI_SCSI_TYPE_WORM  0x04  ///< Write-once device (e.g. some 
> optical disks)
> -#define EFI_SCSI_TYPE_CDROM 0x05  ///< CD-ROM device
> -#define EFI_SCSI_TYPE_SCANNER   0x06  ///< Scanner device
> -#define EFI_SCSI_TYPE_OPTICAL   0x07  ///< Optical memory device (e.g. 
> some optical disks)
> -#define EFI_SCSI_TYPE_MEDIUMCHANGER 0x08  ///< Medium changer device (e.g. 
> jukeboxes)
> -#define EFI_SCSI_TYPE_COMMUNICATION 0x09  ///< Communications device
> -#define EFI_SCSI_TYPE_ASCIT8_1  0x0A  ///< Defined by ASC IT8 (Graphic 
> arts pre-press devices)
> -#define EFI_SCSI_TYPE_ASCIT8_2  0x0B  ///< Defined by ASC IT8 (Graphic 
> arts pre-press devices)

Why remove ASCIT8_1 & ASCIT8_2? Can we keep them for compatibility?

> -//
> -// 0Ch - 1Eh are reserved
> -//
> -#define EFI_SCSI_TYPE_UNKNOWN   0x1F  ///< Unknown or no device type
> +#define EFI_SCSI_TYPE_DISK0x00  ///< Direct-access device (e.g. 
> magnetic disk)
> +#define EFI_SCSI_TYPE_TAPE0x01  ///< Sequential-access device 
> (e.g. magnetic tape)
> +#define EFI_SCSI_TYPE_PRINTER 0x02  ///< Printer device
> +#define EFI_SCSI_TYPE_PROCESSOR   0x03  ///< Processor device
> +#define EFI_SCSI_TYPE_WORM0x04  ///< Write-once device (e.g. 
> some optical disks)
> +#define EFI_SCSI_TYPE_CDROM   0x05  ///< CD/DVD device
> +#define EFI_SCSI_TYPE_SCANNER 0x06  ///< Scanner device (obsolete)
> +#define EFI_SCSI_TYPE_OPTICAL 0x07  ///< Optical memory device (e.g. 
> some optical disks)
> +#define EFI_SCSI_TYPE_MEDIUMCHANGER   0x08  ///< Medium changer device (e.g. 
> jukeboxes)
> +#define EFI_SCSI_TYPE_COMMUNICATION   0x09  ///< Communications device 
> (obsolete)
> +#define EFI_SCSI_TYPE_A   0x0A  ///< Obsolete
> +#define EFI_SCSI_TYPE_B   0x0B  ///< Obsolete
> +#define EFI_SCSI_TYPE_RAID0x0C  ///< Storage array controller 
> device (e.g., RAID)
> +#define EFI_SCSI_TYPE_SES 0x0D  ///< Enclosure services device
> +#define EFI_SCSI_TYPE_RBC 0x0E  ///< Simplified direct-access 
> device (e.g., magnetic disk)
> +#define EFI_SCSI_TYPE_OCRW0x0F  ///< Optical card reader/writer 
> device
> +#define EFI_SCSI_TYPE_BRIDGE  0x10  ///< Bridge Controller Commands
> +#define EFI_SCSI_TYPE_OSD 0x11  ///< Object-based Storage Device
> +#define EFI_SCSI_TYPE_AUTOMATION  0x12  ///< 

Re: [edk2-devel] [PATCH 0/6] Fix race condition and add event protocol

[Liming Gao]

Felix:
  Sorry for the late response. 

> -Original Message-
> From: Felix Polyudov [mailto:fel...@ami.com]
> Sent: Friday, May 24, 2019 8:53 PM
> To: devel@edk2.groups.io; Gao, Zhichao 
> Cc: Wang, Jian J ; Wu, Hao A ; Ni, 
> Ray ; Zeng, Star
> ; Gao, Liming ; Sean Brogan 
> ; Michael Turner
> ; Bret Barkelew ; 
> Kinney, Michael D ;
> Dong, Eric ; Laszlo Ersek ; Andrew 
> Fish (af...@apple.com) 
> Subject: RE: [edk2-devel] [PATCH 0/6] Fix race condition and add event 
> protocol
> 
> I think there is a bigger problem with the idle event signaling by 
> CoreWaitForEvent.
> On every iteration CoreWaitForEvent checks user events, and, if none is 
> signaled, the function signals special idle event.
> This itself is not a problem. However, on many (most?) platforms CPU driver 
> installs idle event handler that calls CpuSleep
> (f.i. refer to IdleLoopEventCallback in UefiCpuPkg/CpuDxe/CpuDxe.c and 
> ArmPkg/Drivers/CpuDxe/CpuDxe.c).
> CpuSleep "places the CPU in a sleep state until an interrupt is received", 
> which changes the nature of the WaitForEvent function arguably
> violating the UEFI specification.
> 
> According to the UEFI specification:
> "The list of events in the Event array are evaluated in order from first to 
> last, and this evaluation is repeated until an event is signaled or an
> error is detected."
> 
> The sentence above implies continues evaluation (polling model).

Here is repeat. It is not identical to polling model. A check per timer period 
is also a repeat implementation. So, it follows UEFI spec.

> An idle event callback that sends CPU to a sleep state, converts WaitForEvent 
> from
> a continues polling function into a poll-once-per-timer-period function 
> (timer is typically the only enabled HW interrupt),
> which reduces quality of service provided by WaitForEvent and can lead to 
> missed events.
> 
> For example, UEFI application that reads key strokes using 
> gBS->WaitForEvent(..)/ConIn->ReadKey(...) sequence
> will be losing key strokes if they are coming faster than 18.2 keys per 
> second on a system based on legacy timer.

This case may not be real case. Idle event is added since 2011 year 
@54cd17e9842d82dae3cd78686e05c4dc37a3540d. 
I don't get the real issue report. Have you meet with some real issue in the 
production?

> 
> So, should idle event support be removed from CoreWaitForEvent?
> 
I think we can still keep it. It is edk2 implementation.

Thanks
Liming
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Gao, 
> Zhichao
> Sent: Friday, May 24, 2019 1:05 AM
> To: devel@edk2.groups.io
> Cc: Jian J Wang; Hao A Wu; Ray Ni; Star Zeng; Liming gao; Sean Brogan; 
> Michael Turner; Bret Barkelew; Michael D Kinney; Eric Dong;
> Laszlo Ersek
> Subject: [edk2-devel] [PATCH 0/6] Fix race condition and add event protocol
> 
> There is a race condition in CoreWaitForEvent function:
> If an interrupt happens between CheckEvent and gIdleLoopEvent,
> there would be a event pending during cpu sleep.
> So it is required to check the gEventPending with the interrupt
> disabled.
> Implement a gEfiCpu2ProtocolGuid to fix that. The protocol include
> one interface to enable interrupt and put the cpu to sleep.
> 
> Add a event protocol gEdkiiCommonEventProtocolGuid to support
> all TPL event. It is require for PI drivers that use HW interrput.
> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> cc: Ray Ni 
> Cc: Star Zeng 
> Cc: Liming gao 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Bret Barkelew 
> Cc: Michael D Kinney 
> Cc: Eric Dong 
> Cc: Laszlo Ersek 
> 
> Sean Brogan (5):
>   MdeModulePkg: Add gEdkiiCommonEventProtocolGuid for event
>   MdePkg/BaseLib.h: Add EnableInterruptsAndSleep function declare
>   MdePkg/BaseLib: Implement EnableInterruptsAndSleep
>   MdePkg: Add gEfiCpu2ProtocolGuid and header file
>   MdeModulePkg/DxeMain: Implement common event protocol
> 
> Zhichao Gao (1):
>   UefiCpuPkg/CpuDxe: Implement Cpu2 protocol
> 
>  MdeModulePkg/Core/Dxe/DxeMain.h   |  64 ++-
>  MdeModulePkg/Core/Dxe/DxeMain.inf |   1 +
>  MdeModulePkg/Core/Dxe/DxeMain/DxeMain.c   |  22 
>  .../Core/Dxe/DxeMain/DxeProtocolNotify.c  |   1 +
>  MdeModulePkg/Core/Dxe/Event/Event.c   | 102 --
>  MdeModulePkg/Core/Dxe/Event/Event.h   |   2 +-
>  MdeModulePkg/Include/Protocol/CommonEvent.h   |  18 
>  MdeModulePkg/MdeModulePkg.dec |   3 +
>  MdePkg/Include/Library/BaseLib.h  |  11 ++
>  MdePkg/Include/Protocol/Cpu2.h|  43 
>  .../Library/BaseLib/Ia32/EnableInterrupts.c   |  18 +++-
>  .../BaseLib/Ia32/EnableInterrupts.nasm|  15 ++-
>  .../Library/BaseLib/X64/EnableInterrupts.nasm |  15 ++-
>  MdePkg/MdePkg.dec |   3 +
>  UefiCpuPkg/CpuDxe/CpuDxe.c|  40 ++-
>  UefiCpuPkg/CpuDxe/CpuDxe.h|  15 +++
>  UefiCpuPkg/CpuDxe/CpuDxe.inf   

Re: [edk2-devel] [PATCH 0/2] EmbeddedPkg,ArmPlatformPkg: fix VS2017 TimeBaseLib build errors

[Philippe Mathieu-Daudé]

On 6/13/19 6:18 PM, Leif Lindholm wrote:
> TimeBaseLib EfiTimeToEpoch returns a UINTN, meaning its behaviour differs
> between architectures. This upsets VS2017 when building for 32-bit ARM
> (and likely would if building for IA32 too). Similarly, some internal
> calculations used UINTN for operating on fixed-size fields, giving
> further issues.
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=997
> 
> PL031RealTimeClockLib needed an adjustment to support the resulting API
> change, but frankly that change just makes the code agree with the
> comments surrounding it.
> 
> This series cleans up the type handling Visual Studio complains about.
> This is not a proper overhaul of the library, just a fix of encountered
> build errors.
> 
> Leif Lindholm (2):
>   ArmPlatformPkg: use UINT32 epoch second counter
>   EmbeddedPkg: improve TimeBaseLib type safety
> 
>  ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c |  3 ++-
>  EmbeddedPkg/Include/Library/TimeBaseLib.h|  4 
> ++--
>  EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.c| 18 
> +-
>  3 files changed, 13 insertions(+), 12 deletions(-)
> 
> Cc: Alexei Fedorov 
> 

Series:
Reviewed-by: Philippe Mathieu-Daude 

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

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

Re: [edk2-devel] [PATCH 0/2] EmbeddedPkg,ArmPlatformPkg: fix VS2017 TimeBaseLib build errors

[Ard Biesheuvel]

On Thu, 13 Jun 2019 at 18:18, Leif Lindholm  wrote:
>
> TimeBaseLib EfiTimeToEpoch returns a UINTN, meaning its behaviour differs
> between architectures. This upsets VS2017 when building for 32-bit ARM
> (and likely would if building for IA32 too). Similarly, some internal
> calculations used UINTN for operating on fixed-size fields, giving
> further issues.
>
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=997
>
> PL031RealTimeClockLib needed an adjustment to support the resulting API
> change, but frankly that change just makes the code agree with the
> comments surrounding it.
>
> This series cleans up the type handling Visual Studio complains about.
> This is not a proper overhaul of the library, just a fix of encountered
> build errors.
>
> Leif Lindholm (2):
>   ArmPlatformPkg: use UINT32 epoch second counter
>   EmbeddedPkg: improve TimeBaseLib type safety
>

Acked-by: Ard Biesheuvel 

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

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

[edk2-devel] [PATCH 2/2] EmbeddedPkg: improve TimeBaseLib type safety

[Leif Lindholm]

EfiTimeToEpoch currently returns a UINTN.
Also, some internal calculations was using UINTN for fixed-width.
Both of these lead to warnings/errors with VS2017.

Replace with appropriate fixed-size types.

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

Cc: Alexei Fedorov 
Signed-off-by: Leif Lindholm 
---
 EmbeddedPkg/Include/Library/TimeBaseLib.h |  4 ++--
 EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.c | 18 +-
 2 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/EmbeddedPkg/Include/Library/TimeBaseLib.h 
b/EmbeddedPkg/Include/Library/TimeBaseLib.h
index d51059cb1f7d..4103c89b3891 100644
--- a/EmbeddedPkg/Include/Library/TimeBaseLib.h
+++ b/EmbeddedPkg/Include/Library/TimeBaseLib.h
@@ -1,7 +1,7 @@
 /** @file
 *
 *  Copyright (c) 2016, Hisilicon Limited. All rights reserved.
-*  Copyright (c) 2016, Linaro Limited. All rights reserved.
+*  Copyright (c) 2016-2019, Linaro Limited. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -53,7 +53,7 @@ EpochToEfiTime (
 /**
   Converts EFI_TIME to Epoch seconds (elapsed since 1970 JANUARY 01, 00:00:00 
UTC)
  **/
-UINTN
+UINT32
 EFIAPI
 EfiTimeToEpoch (
   IN  EFI_TIME  *Time
diff --git a/EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.c 
b/EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.c
index 662cbdd5da99..136ce8a51e86 100644
--- a/EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.c
+++ b/EmbeddedPkg/Library/TimeBaseLib/TimeBaseLib.c
@@ -1,7 +1,7 @@
 /** @file
 *
 *  Copyright (c) 2016, Hisilicon Limited. All rights reserved.
-*  Copyright (c) 2016, Linaro Limited. All rights reserved.
+*  Copyright (c) 2016-2019, Linaro Limited. All rights reserved.
 *
 *  SPDX-License-Identifier: BSD-2-Clause-Patent
 *
@@ -53,9 +53,9 @@ EpochToEfiTime (
   m  = (((da * 5) + 308) / 153) - 2;
   d  = da - (((m + 4) * 153) / 5) + 122;
 
-  Time->Year  = y - 4800 + ((m + 2) / 12);
+  Time->Year  = (UINT16)(y - 4800 + ((m + 2) / 12));
   Time->Month = ((m + 2) % 12) + 1;
-  Time->Day   = d + 1;
+  Time->Day   = (UINT8)(d + 1);
 
   ss = EpochSeconds % 60;
   a  = (EpochSeconds - ss) / 60;
@@ -63,9 +63,9 @@ EpochToEfiTime (
   b = (a - mm) / 60;
   hh = b % 24;
 
-  Time->Hour= hh;
-  Time->Minute  = mm;
-  Time->Second  = ss;
+  Time->Hour= (UINT8)hh;
+  Time->Minute  = (UINT8)mm;
+  Time->Second  = (UINT8)ss;
   Time->Nanosecond  = 0;
 
 }
@@ -99,14 +99,14 @@ EfiGetEpochDays (
 /**
   Converts EFI_TIME to Epoch seconds (elapsed since 1970 JANUARY 01, 00:00:00 
UTC)
  **/
-UINTN
+UINT32
 EFIAPI
 EfiTimeToEpoch (
   IN  EFI_TIME  *Time
   )
 {
-  UINTN EpochDays;   // Number of days elapsed since EPOCH_JULIAN_DAY
-  UINTN EpochSeconds;
+  UINT32 EpochDays;   // Number of days elapsed since EPOCH_JULIAN_DAY
+  UINT32 EpochSeconds;
 
   EpochDays = EfiGetEpochDays (Time);
 
-- 
2.11.0


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

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

[edk2-devel] [PATCH 1/2] ArmPlatformPkg: use UINT32 epoch second counter

[Leif Lindholm]

The comments describes the device as being 32-bit:
"the maximum time span is just over 136 years"
then uses a UINTN to hold the value.

Change to UINT32 so we don't get different behaviour for different 
architectures.

Signed-off-by: Leif Lindholm 
---
 ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c 
b/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
index 5d5495503d18..b630a5cfbfcd 100644
--- a/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
+++ b/ArmPlatformPkg/Library/PL031RealTimeClockLib/PL031RealTimeClockLib.c
@@ -3,6 +3,7 @@
 
   Copyright (c) 2008 - 2010, Apple Inc. All rights reserved.
   Copyright (c) 2011 - 2014, ARM Ltd. All rights reserved.
+  Copyright (c) 2019, Linaro Ltd. All rights reserved.
 
   SPDX-License-Identifier: BSD-2-Clause-Patent
 
@@ -181,7 +182,7 @@ LibSetTime (
   )
 {
   EFI_STATUS  Status;
-  UINTN   EpochSeconds;
+  UINT32  EpochSeconds;
 
   // Because the PL031 is a 32-bit counter counting seconds,
   // the maximum time span is just over 136 years.
-- 
2.11.0


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

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

Re: [edk2-devel] [PATCH v2 0/4] Define EDKII_SERIAL_PORT_LIB_VENDOR_GUID

[Ma, Maurice]

Hi, Laszlo

Thank you for the reminder.   Reviewed patch #4 just now.

Regards,
Maurice
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, June 13, 2019 8:32
> To: Ard Biesheuvel ; Leif Lindholm
> ; Ma, Maurice ; Dong,
> Guo ; You, Benjamin 
> Cc: Wang, Jian J ; Wu, Hao A ;
> Zeng, Star ; devel@edk2.groups.io; Anthony Perard
> ; Julien Grall ; Ni, Ray
> 
> Subject: Re: [edk2-devel] [PATCH v2 0/4] Define
> EDKII_SERIAL_PORT_LIB_VENDOR_GUID
> 
> On 06/06/19 15:14, Anthony PERARD wrote:
> > The macro SERIAL_DXE_FILE_GUID is been defined twice and the GUID is
> > been used once without defining the macro. This patch series define a
> > macro in MdeModulePkg where the SerialDxe is, and replace all other
> > use by this new one, EDKII_SERIAL_PORT_LIB_VENDOR_GUID.
> >
> > Note that I haven't build/test those changes, but I have test the
> > first patch by applying a similar change to a patch series I'm working on.
> >
> > Patch series available in this git branch:
> > https://xenbits.xen.org/git-http/people/aperard/ovmf.git
> > br.serial-dxe-guid-v2
> >
> > Thanks.
> >
> > Anthony PERARD (4):
> >   MdeModulePkg: Introduce EDKII_SERIAL_PORT_LIB_VENDOR_GUID
> >   ArmVirtPkg/PlatformBootManagerLib: Use
> > EDKII_SERIAL_PORT_LIB_VENDOR_GUID from MdeModulePkg
> >   ArmPkg/PlatformBootManagerLib: Use
> EDKII_SERIAL_PORT_LIB_VENDOR_GUID
> > from MdeModulePkg
> 
> Leif, Ard, can you please review patch #3?
> 
> >   UefiPayloadPkg/PlatformBootManagerLib: Use
> > EDKII_SERIAL_PORT_LIB_VENDOR_GUID from MdeModulePkg
> 
> Maurice, Guo, Benjamin, can you please review patch #4?
> 
> Thanks,
> Laszlo

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

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

Re: [edk2-devel] [PATCH v2 4/4] UefiPayloadPkg/PlatformBootManagerLib: Use EDKII_SERIAL_PORT_LIB_VENDOR_GUID from MdeModulePkg

[Ma, Maurice]

Reviewed-by: Maurice Ma 

Regards,
Maurice

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Anthony PERARD
> Sent: Thursday, June 6, 2019 6:15
> To: devel@edk2.groups.io
> Cc: Ni, Ray ; Julien Grall ; Ard
> Biesheuvel ; Leif Lindholm
> ; Laszlo Ersek ; Wang, Jian J
> ; Wu, Hao A ; Zeng, Star
> ; Anthony PERARD 
> Subject: [edk2-devel] [PATCH v2 4/4]
> UefiPayloadPkg/PlatformBootManagerLib: Use
> EDKII_SERIAL_PORT_LIB_VENDOR_GUID from MdeModulePkg
> 
> EDKII_SERIAL_PORT_LIB_VENDOR_GUID is now defined in MdeModulePkg,
> simply use it.
> 
> Signed-off-by: Anthony PERARD 
> ---
>  .../Library/PlatformBootManagerLib/PlatformConsole.c   | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git
> a/UefiPayloadPkg/Library/PlatformBootManagerLib/PlatformConsole.c
> b/UefiPayloadPkg/Library/PlatformBootManagerLib/PlatformConsole.c
> index 80a11d7451..ee2d8c8d1e 100644
> --- a/UefiPayloadPkg/Library/PlatformBootManagerLib/PlatformConsole.c
> +++ b/UefiPayloadPkg/Library/PlatformBootManagerLib/PlatformConsole.c
> @@ -8,6 +8,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  #include "PlatformBootManager.h"
>  #include "PlatformConsole.h"
> +#include 
> 
>  #define PCI_DEVICE_PATH_NODE(Func, Dev) \
>{ \
> @@ -53,7 +54,7 @@ SPDX-License-Identifier: BSD-2-Clause-Patent
>  (UINT8) ((sizeof (VENDOR_DEVICE_PATH)) >> 8) \
>} \
>  }, \
> -{0xD3987D4B, 0x971A, 0x435F, {0x8C, 0xAF, 0x49, 0x67, 0xEB, 0x62, 0x72,
> 0x41}} \
> +EDKII_SERIAL_PORT_LIB_VENDOR_GUID \
>}
> 
>  #define gUart \
> --
> Anthony PERARD
> 
> 
> 


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

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

Re: [edk2-devel] [PATCH v2 0/4] Define EDKII_SERIAL_PORT_LIB_VENDOR_GUID

[Laszlo Ersek]

On 06/13/19 17:32, Laszlo Ersek wrote:
> On 06/06/19 15:14, Anthony PERARD wrote:
>> The macro SERIAL_DXE_FILE_GUID is been defined twice and the GUID is been 
>> used
>> once without defining the macro. This patch series define a macro in
>> MdeModulePkg where the SerialDxe is, and replace all other use by this new 
>> one,
>> EDKII_SERIAL_PORT_LIB_VENDOR_GUID.
>>
>> Note that I haven't build/test those changes, but I have test the first patch
>> by applying a similar change to a patch series I'm working on.
>>
>> Patch series available in this git branch:
>> https://xenbits.xen.org/git-http/people/aperard/ovmf.git 
>> br.serial-dxe-guid-v2
>>
>> Thanks.
>>
>> Anthony PERARD (4):
>>   MdeModulePkg: Introduce EDKII_SERIAL_PORT_LIB_VENDOR_GUID
>>   ArmVirtPkg/PlatformBootManagerLib: Use
>> EDKII_SERIAL_PORT_LIB_VENDOR_GUID from MdeModulePkg
>>   ArmPkg/PlatformBootManagerLib: Use EDKII_SERIAL_PORT_LIB_VENDOR_GUID
>> from MdeModulePkg
> 
> Leif, Ard, can you please review patch #3?

Ooops, nevermind, I missed for a moment Ard's ACK for the whole series:

http://mid.mail-archive.com/CAKv+Gu9jx+xgQBfD0DOc+ZLJ1XqKb6=tjdbh09_luawdsxs...@mail.gmail.com

However,

> 
>>   UefiPayloadPkg/PlatformBootManagerLib: Use
>> EDKII_SERIAL_PORT_LIB_VENDOR_GUID from MdeModulePkg
> 
> Maurice, Guo, Benjamin, can you please review patch #4?

the UefiPayloadPkg patch still needs a maintainer A-b or R-b.

Thanks
Laszlo

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

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

Re: [edk2-devel] [PATCH v2 0/4] Define EDKII_SERIAL_PORT_LIB_VENDOR_GUID

[Laszlo Ersek]

On 06/06/19 15:14, Anthony PERARD wrote:
> The macro SERIAL_DXE_FILE_GUID is been defined twice and the GUID is been used
> once without defining the macro. This patch series define a macro in
> MdeModulePkg where the SerialDxe is, and replace all other use by this new 
> one,
> EDKII_SERIAL_PORT_LIB_VENDOR_GUID.
> 
> Note that I haven't build/test those changes, but I have test the first patch
> by applying a similar change to a patch series I'm working on.
> 
> Patch series available in this git branch:
> https://xenbits.xen.org/git-http/people/aperard/ovmf.git br.serial-dxe-guid-v2
> 
> Thanks.
> 
> Anthony PERARD (4):
>   MdeModulePkg: Introduce EDKII_SERIAL_PORT_LIB_VENDOR_GUID
>   ArmVirtPkg/PlatformBootManagerLib: Use
> EDKII_SERIAL_PORT_LIB_VENDOR_GUID from MdeModulePkg
>   ArmPkg/PlatformBootManagerLib: Use EDKII_SERIAL_PORT_LIB_VENDOR_GUID
> from MdeModulePkg

Leif, Ard, can you please review patch #3?

>   UefiPayloadPkg/PlatformBootManagerLib: Use
> EDKII_SERIAL_PORT_LIB_VENDOR_GUID from MdeModulePkg

Maurice, Guo, Benjamin, can you please review patch #4?

Thanks,
Laszlo

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

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

Re: [edk2-devel] [RFC][PATCH v1 0/3] Remove IntelFramework[Module]Pkg

[Laszlo Ersek]

On 05/27/19 08:48, Wu, Hao A wrote:
> '''
> Please note that this series will be hold until all the below requirements
> are met:
> 
> A. edk2-stable201905 is created;
> B. OvmfPkg has been updated to drop its dependency on
>IntelFramework[Module]Pkg; (Patches already been sent)
> C. Platforms in the edk2-platforms have been updated to drop their
>dependencies on IntelFramework[Module]Pkg. (Patches already been sent
>for all platforms except Intel Quark and Minnowboard)
> '''
> 
> The patches themselves will not be sent to the mailing list and are only
> available at:
> https://github.com/hwu25/edk2/commits/delete_framework
> 
> Cc: Liming Gao 
> Cc: Ray Ni 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> 
> 
> Hao A Wu (3):
>   Remove IntelFrameworkModulePkg
>   Remove IntelFrameworkPkg
>   Maintainers.txt: Remove information for IntelFramework[Module]Pkg
> 

series
Acked-by: Laszlo Ersek 


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

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

Re: [edk2-devel] [RFC][PATCH v1 0/1] PcAtChipsetPkg: Remove framework modules

[Laszlo Ersek]

Hello Hao,

On 05/27/19 08:36, Wu, Hao A wrote:
> '''
> Please note that this patch will be hold until all the below requirements
> are met:
> 
> A. edk2-stable201905 is created;
> B. OvmfPkg has drop its usage of the legacy ISA stack (which includes
>the IsaAcpiDxe driver);
> C. UefiPayloadPkg has been updated to drop its consume to the
>8259InterruptControllerDxe driver.
> '''
> 
> This patch itself will not be sent to the mailing list and is only
> available at:
> https://github.com/hwu25/edk2/tree/delete_framework
> (https://github.com/hwu25/edk2/commit/84e58f89f6d03f9cc3399cced9d5d5529e06a416)
> 
> 
> Below modules will be removed from PcAtChipsetPkg:
> * PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
> * PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
> * PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf

OvmfPkg's dependency on IsaAcpiDxe has been removed in commit
562688707145 ("OvmfPkg: Drop build flag USE_LEGACY_ISA_STACK and legacy
ISA stack", 2019-06-11), so that's fine.

The other two drivers (8259InterruptControllerDxe and 8254TimerDxe) have
been copied under OvmfPkg for bug 1496.

I haven't reviewed this series in detail, but based on the above, I'm
fine with the removals, in general.

Acked-by: Laszlo Ersek 

Thanks
Laszlo


> 
> They are considered legacy framework components and will no longer be used
> after the removal of IntelFramework[Module]Pkg.
> 
> Also, the unused (after the modules being removed) PCDs will be deleted in
> package level DEC/UNI files.
> 
> Cc: Ray Ni 
> Cc: Andrew Fish 
> Cc: Laszlo Ersek 
> Cc: Leif Lindholm 
> Cc: Michael D Kinney 
> 
> 
> Hao A Wu (1):
>   PcAtChipsetPkg: Remove framework modules
> 
>  PcAtChipsetPkg/PcAtChipsetPkg.dec |  58 --
>  PcAtChipsetPkg/PcAtChipsetPkg.dsc |   5 +-
>  PcAtChipsetPkg/8254TimerDxe/8254Timer.inf |  42 --
>  PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf|  46 --
>  PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf |  50 --
>  PcAtChipsetPkg/8254TimerDxe/Timer.h   | 185 --
>  PcAtChipsetPkg/8259InterruptControllerDxe/8259.h  | 220 ---
>  PcAtChipsetPkg/IsaAcpiDxe/PcatIsaAcpi.h   | 269 -
>  PcAtChipsetPkg/8254TimerDxe/Timer.c   | 401 
> -
>  PcAtChipsetPkg/8259InterruptControllerDxe/8259.c  | 622 
> 
>  PcAtChipsetPkg/IsaAcpiDxe/ComponentName.c | 301 
> --
>  PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.c   | 353 
> ---
>  PcAtChipsetPkg/IsaAcpiDxe/PcatIsaAcpi.c   | 386 
> 
>  PcAtChipsetPkg/8254TimerDxe/Timer.uni |  16 -
>  PcAtChipsetPkg/8254TimerDxe/TimerExtra.uni|  14 -
>  PcAtChipsetPkg/8259InterruptControllerDxe/Legacy8259.uni  |  16 -
>  PcAtChipsetPkg/8259InterruptControllerDxe/Legacy8259Extra.uni |  14 -
>  PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.uni |  16 -
>  PcAtChipsetPkg/IsaAcpiDxe/IsaAcpiExtra.uni|  14 -
>  PcAtChipsetPkg/PcAtChipsetPkg.uni |  52 +-
>  20 files changed, 2 insertions(+), 3078 deletions(-)
>  delete mode 100644 PcAtChipsetPkg/8254TimerDxe/8254Timer.inf
>  delete mode 100644 PcAtChipsetPkg/8259InterruptControllerDxe/8259.inf
>  delete mode 100644 PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf
>  delete mode 100644 PcAtChipsetPkg/8254TimerDxe/Timer.h
>  delete mode 100644 PcAtChipsetPkg/8259InterruptControllerDxe/8259.h
>  delete mode 100644 PcAtChipsetPkg/IsaAcpiDxe/PcatIsaAcpi.h
>  delete mode 100644 PcAtChipsetPkg/8254TimerDxe/Timer.c
>  delete mode 100644 PcAtChipsetPkg/8259InterruptControllerDxe/8259.c
>  delete mode 100644 PcAtChipsetPkg/IsaAcpiDxe/ComponentName.c
>  delete mode 100644 PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.c
>  delete mode 100644 PcAtChipsetPkg/IsaAcpiDxe/PcatIsaAcpi.c
>  delete mode 100644 PcAtChipsetPkg/8254TimerDxe/Timer.uni
>  delete mode 100644 PcAtChipsetPkg/8254TimerDxe/TimerExtra.uni
>  delete mode 100644 PcAtChipsetPkg/8259InterruptControllerDxe/Legacy8259.uni
>  delete mode 100644 
> PcAtChipsetPkg/8259InterruptControllerDxe/Legacy8259Extra.uni
>  delete mode 100644 PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.uni
>  delete mode 100644 PcAtChipsetPkg/IsaAcpiDxe/IsaAcpiExtra.uni
> 


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

View/Reply Online (#42381): https://edk2.groups.io/g/devel/message/42381
Mute This Topic: https://groups.io/mt/31806937/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 6/6] OvmfPkg/Csm/CsmSupportLib: Drop IntelFrameworkPkg dependency

[Laszlo Ersek]

On 05/27/19 07:19, Wu, Hao A wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843
> 
> This commit will update the INF file of the CsmSupportLib to drop its
> dependency on IntelFrameworkPkg:
> 
> gEfiLegacyBiosPlatformProtocolGuid
> gEfiLegacyBiosProtocolGuid
> gEfiLegacyInterruptProtocolGuid
> 
> The above dependencies have already been addressed by the duplication of
> these definitions from IntelFrameworkPkg to OvmfPkg.
> 
> Cc: Ray Ni 
> Cc: David Woodhouse 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Hao A Wu 
> ---
>  OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf 
> b/OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
> index 229f2e0b4b..45f201f07b 100644
> --- a/OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
> +++ b/OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  #  Platform CSM Support Library
>  #
> -#  Copyright (c) 2008 - 2018, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2008 - 2019, Intel Corporation. All rights reserved.
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
>  ##
> @@ -34,7 +34,6 @@ [Sources]
>  
>  [Packages]
>MdePkg/MdePkg.dec
> -  IntelFrameworkPkg/IntelFrameworkPkg.dec
>OvmfPkg/OvmfPkg.dec
>  
>  [Pcd]
> 

Reviewed-by: Laszlo Ersek 

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

View/Reply Online (#42380): https://edk2.groups.io/g/devel/message/42380
Mute This Topic: https://groups.io/mt/31806549/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 5/6] OvmfPkg/IncompatiblePciDeviceSupportDxe: Drop framework pkg dependency

[Laszlo Ersek]

On 05/27/19 07:19, Wu, Hao A wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843
> 
> This commit will drop the driver's dependency on the IntelFrameworkPkg:
> gEfiLegacyBiosProtocolGuid
> 
> Such dependency has already been addressed by the duplication of the above
> definition from IntelFrameworkPkg into the OvmfPkg.
> 
> Cc: Ray Ni 
> Cc: David Woodhouse 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Hao A Wu 
> ---
>  OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf | 1 
> -
>  1 file changed, 1 deletion(-)
> 
> diff --git 
> a/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf 
> b/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
> index e13577530d..f08b6f4bd4 100644
> --- a/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
> +++ b/OvmfPkg/IncompatiblePciDeviceSupportDxe/IncompatiblePciDeviceSupport.inf
> @@ -20,7 +20,6 @@ [Sources]
>IncompatiblePciDeviceSupport.c
>  
>  [Packages]
> -  IntelFrameworkPkg/IntelFrameworkPkg.dec
>MdeModulePkg/MdeModulePkg.dec
>MdePkg/MdePkg.dec
>OvmfPkg/OvmfPkg.dec
> 

Reviewed-by: Laszlo Ersek 

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

View/Reply Online (#42379): https://edk2.groups.io/g/devel/message/42379
Mute This Topic: https://groups.io/mt/31806548/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 2/6] OvmfPkg/OvmfPkg.dec: Add PcdShellFile in OVMF DEC file

[Laszlo Ersek]

Hi Hao,

On 05/27/19 07:19, Wu, Hao A wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843
> 
> OVMF is currently using the PCD 'PcdShellFile' defined in
> IntelFrameworkModulePkg.
> 
> This commit will add this PCD into the OVMF DEC file in order to drop
> OVMF's dependency on IntelFrameworkModulePkg. The PCD token value 0x17 is
> selected to fill the hole (seems the only one left) in OvmfPkg.
> 
> Please note that, instead of adding the PCD under section:
> [PcdsFixedAtBuild, PcdsPatchableInModule]
> 
> as in IntelFrameworkModulePkg.dec file, it is added in section:
> [PcdsFixedAtBuild]
> 
> in OvmfPkg.dec instead.

Please replace patches #2 through #4 with the following approach:

- eliminate PcdShellFile completely, from OvmfPkg

- in PlatformBootManagerLib, please consume gUefiShellFileGuid, from
ShellPkg.dec.

(This is what ArmPkg and ArmVirtPkg do.)

Thanks!
Laszlo

> Cc: Ray Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Hao A Wu 
> ---
>  OvmfPkg/OvmfPkg.dec | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index 9640360f62..38a2d4763d 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -160,6 +160,9 @@ [PcdsFixedAtBuild]
>#  For the corresponding bits, 0 = Edge triggered and 1 = Level triggered.
>gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x|UINT16|0x5
>  
> +  ## FFS filename to find the shell application.
> +  gUefiOvmfPkgTokenSpaceGuid.PcdShellFile|{ 0x83, 0xA5, 0x04, 0x7C, 0x3E, 
> 0x9E, 0x1C, 0x4F, 0xAD, 0x65, 0xE0, 0x52, 0x68, 0xD0, 0xB4, 0xD1 }|VOID*|0x17
> +
>## Indicates if BiosVideo driver will switch to 80x25 Text VGA Mode when
>#  exiting boot service.
>#   TRUE  - Switch to Text VGA Mode.
> 


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

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

Re: [edk2-devel] [PATCH 2/2] MdeModulePkg/SdMmcHcDxe: Implement revision 3 of SdMmcOverrideProtocol

[Albecki, Mateusz]

Resending to group. Inline reply to some of the comments.

As for the mapping between eMMC driver strength and SD controller driver 
strength should we use this one:

SD controller -> eMMC card
B-> Type 0
A   -> Type 1
C   -> Type 2
D   -> Type 3
(none)-> Type4

And Type 4 would be identified by bit 39 in capability register which is 
currently marked as reserved in SD controller specification. This is current 
capability register definition in the driver.

Thanks,
Mateusz

> -Original Message-
> From: Wu, Hao A
> Sent: Monday, June 10, 2019 5:19 AM
> To: Albecki, Mateusz 
> Subject: RE: [PATCH 2/2] MdeModulePkg/SdMmcHcDxe: Implement revision
> 3 of SdMmcOverrideProtocol
> 
> Hello Mateusz,
> 
> Some inline comments below:
> 
> > -Original Message-
> > From: Albecki, Mateusz
> > Sent: Monday, June 03, 2019 7:34 PM
> > Cc: Albecki, Mateusz; Wu, Hao A; Albecki
> > Subject: [PATCH 2/2] MdeModulePkg/SdMmcHcDxe: Implement revision 3
> > of SdMmcOverrideProtocol
> >
> > Implement support for GetOperatingParamters notify phase
> > in SdMmcHcDxe driver. GetOperatingParameters notify phase
> > is signaled before we start card detection and initialization.
> > Code has been updated for both eMMC and SD card controllers to
> > take into consideration those new parameters. Initialization process
> > has been divided into 2 steps. In the first step we bring the link
> > up to the point where we can get card identification data(Extended
> > CSD in eMMC case and SWITCH command response in SD card case). This
> > data is later used along with controller capabilities and operating
> > parameters passed in GetOperatingParameters phase to choose preferred
> > bus settings in GetTargetBusSettings function. Those settings are later
> > on to start bus training to high speeds. If user passes incompatible
> > setting with selected bus timing driver will assume it's standard behavior
> with
> > respect to that setting. For instance if HS400 has been selected as a
> > target bus timing due to card and controller support bus width setting of
> > 4 and 1 bit won't be respected and 8 bit setting will be chosen instead.
> >
> >
> > Cc: hao.a...@intel.com
> > Signed-off-by: Albecki, Mateusz 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > ---
> >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c| 522
> > +++--
> >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdDevice.c  | 381
> > ---
> >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c |  52 +-
> >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h |  18 +-
> >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c   |   8 +-
> >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h   |   8 +-
> >  6 files changed, 750 insertions(+), 239 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> > index deaf4468c9..1a81f6d250 100644
> > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c
> > @@ -449,7 +449,7 @@ EFI_STATUS
> >  EmmcSendTuningBlk (
> >IN EFI_SD_MMC_PASS_THRU_PROTOCOL  *PassThru,
> >IN UINT8  Slot,
> > -  IN UINT8  BusWidth
> > +  IN UINT16 BusWidth
> >)
> >  {
> >EFI_SD_MMC_COMMAND_BLOCK  SdMmcCmdBlk;
> > @@ -506,7 +506,7 @@ EmmcTuningClkForHs200 (
> >IN EFI_PCI_IO_PROTOCOL*PciIo,
> >IN EFI_SD_MMC_PASS_THRU_PROTOCOL  *PassThru,
> >IN UINT8  Slot,
> > -  IN UINT8  BusWidth
> > +  IN UINT16 BusWidth
> >)
> >  {
> >EFI_STATUS  Status;
> > @@ -583,7 +583,7 @@ EmmcSwitchBusWidth (
> >IN UINT8  Slot,
> >IN UINT16 Rca,
> >IN BOOLEANIsDdr,
> > -  IN UINT8  BusWidth
> > +  IN UINT16 BusWidth
> >)
> >  {
> >EFI_STATUS  Status;
> > @@ -641,13 +641,13 @@ EmmcSwitchBusWidth (
> >Refer to EMMC Electrical Standard Spec 5.1 Section 6.6 and SD Host
> > Controller
> >Simplified Spec 3.0 Figure 3-3 for details.
> >
> > -  @param[in] PciIo  A pointer to the EFI_PCI_IO_PROTOCOL instance.
> > -  @param[in] PassThru   A pointer to the
> > EFI_SD_MMC_PASS_THRU_PROTOCOL instance.
> > -  @param[in] Slot   The slot number of the SD card to send the
> command
> > to.
> > -  @param[in] RcaThe relative device address to be assigned.
> > -  @param[in] HsTiming   The value to be written to HS_TIMING field of
> > EXT_CSD register.
> > -  @param[in] Timing The bus mode timing indicator.
> > -  @param[in] ClockFreq  The max clock frequency to be set, the unit 

Re: [edk2-devel] [PATCH v1 1/6] OvmfPkg/PlatformPei: Remove redundant reference of framework pkg DEC

[Laszlo Ersek]

On 05/27/19 07:19, Wu, Hao A wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843
> 
> For the driver's INF file, this commit will remove the redundant reference
> to 'IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec'.
> 
> Cc: Ray Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Hao A Wu 
> ---
>  OvmfPkg/PlatformPei/PlatformPei.inf | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
> b/OvmfPkg/PlatformPei/PlatformPei.inf
> index f660c2d9e4..d9fd9c8f05 100644
> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
> @@ -2,7 +2,7 @@
>  #  Platform PEI driver
>  #
>  #  This module provides platform specific function to detect boot mode.
> -#  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  #
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -36,7 +36,6 @@ [Sources]
>Xen.h
>  
>  [Packages]
> -  IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
>SecurityPkg/SecurityPkg.dec
> 

Reviewed-by: Laszlo Ersek 

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

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

Re: [edk2-devel] [PATCH v2 11/10] OvmfPkg/Csm/LegacyBiosDxe: Fix Legacy16GetTableAddress call for E820 data

[Laszlo Ersek]

On 06/13/19 10:40, David Woodhouse wrote:
> The DX register is supposed to contain the required alignment for the
> allocation. It was zero, and SeaBIOS doesn't (well, didn't) cope well
> with that. Set it appropriately.
> 
> Also set BX to indicate the regions it's OK to allocate in too. That
> wasn't being initialised and was just using whatever the previous user
> of the structure had left there.
> 
> Finally, actually return an error if the allocation fails. Instead of
> going all the way through into the CSM and just letting it have a bogus
> pointer to the E820 data.
> 
> Signed-off-by: David Woodhouse 
> Reviewed-by: Hao A Wu 
> ---
>  OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c 
> b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> index 211750c012..cd4cd24f42 100644
> --- a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> +++ b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> @@ -928,7 +928,9 @@ GenericLegacyBoot (
>if (CopySize > Private->Legacy16Table->E820Length) {
>  ZeroMem (, sizeof (EFI_IA32_REGISTER_SET));
>  Regs.X.AX = Legacy16GetTableAddress;
> +Regs.X.BX = (UINT16) 0x0; // Any region
>  Regs.X.CX = (UINT16) CopySize;
> +Regs.X.DX = (UINT16) 0x4; // Alignment
>  Private->LegacyBios.FarCall86 (
>>LegacyBios,
>Private->Legacy16Table->Compatibility16CallSegment,
> @@ -942,6 +944,7 @@ GenericLegacyBoot (
>  Private->Legacy16Table->E820Length  = (UINT32) CopySize;
>  if (Regs.X.AX != 0) {
>DEBUG ((EFI_D_ERROR, "Legacy16 E820 length insufficient\n"));
> +  return EFI_OUT_OF_RESOURCES;
>  } else {
>CopyMem (
>  (VOID *)(UINTN) Private->Legacy16Table->E820Pointer,
> 

Acked-by: Laszlo Ersek 

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

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

Re: [edk2-devel] [PATCH v2 10/10] OvmfPkg: Update DSC/FDF files to consume CSM components in OvmfPkg

[Laszlo Ersek]

On 05/27/19 05:03, Wu, Hao A wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
> 
> This commit updates the OVMF DSC/FDF files to consume the copied CSM
> components within OvmfPkg.
> 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Hao A Wu 
> ---
>  OvmfPkg/OvmfPkgIa32.dsc| 10 +-
>  OvmfPkg/OvmfPkgIa32X64.dsc | 10 +-
>  OvmfPkg/OvmfPkgX64.dsc | 10 +-
>  OvmfPkg/OvmfPkgIa32.fdf|  4 ++--
>  OvmfPkg/OvmfPkgIa32X64.fdf |  4 ++--
>  OvmfPkg/OvmfPkgX64.fdf |  4 ++--
>  6 files changed, 21 insertions(+), 21 deletions(-)
> 
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
> index b3446ece31..94d8af6b8a 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -683,7 +683,7 @@ [Components]
>  
>  !ifdef $(CSM_ENABLE)
>NULL|OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
> -  
> NULL|IntelFrameworkModulePkg/Library/LegacyBootManagerLib/LegacyBootManagerLib.inf
> +  NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
>  !endif
>}
>MdeModulePkg/Logo/LogoDxe.inf
> @@ -693,8 +693,8 @@ [Components]
>NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
>
> NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
>  !ifdef $(CSM_ENABLE)
> -  
> NULL|IntelFrameworkModulePkg/Library/LegacyBootManagerLib/LegacyBootManagerLib.inf
> -  
> NULL|IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
> +  NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
> +  NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
>  !endif
>}
>OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
> @@ -799,11 +799,11 @@ [Components]
>MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
>  
>  !ifdef $(CSM_ENABLE)
> -  IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf {
> +  OvmfPkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf {
>  
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>}
> -  IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
> +  OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
>OvmfPkg/Csm/Csm16/Csm16.inf
>  !endif
>  
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 679d4eb8dd..5d9c688e8b 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ b/OvmfPkg/OvmfPkgIa32X64.dsc
> @@ -692,7 +692,7 @@ [Components.X64]
>  
>  !ifdef $(CSM_ENABLE)
>NULL|OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
> -  
> NULL|IntelFrameworkModulePkg/Library/LegacyBootManagerLib/LegacyBootManagerLib.inf
> +  NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
>  !endif
>}
>MdeModulePkg/Logo/LogoDxe.inf
> @@ -702,8 +702,8 @@ [Components.X64]
>NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
>
> NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
>  !ifdef $(CSM_ENABLE)
> -  
> NULL|IntelFrameworkModulePkg/Library/LegacyBootManagerLib/LegacyBootManagerLib.inf
> -  
> NULL|IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
> +  NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
> +  NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
>  !endif
>}
>OvmfPkg/VirtioPciDeviceDxe/VirtioPciDeviceDxe.inf
> @@ -808,11 +808,11 @@ [Components.X64]
>MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassStorageDxe.inf
>  
>  !ifdef $(CSM_ENABLE)
> -  IntelFrameworkModulePkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf {
> +  OvmfPkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf {
>  
>PcdLib|MdePkg/Library/DxePcdLib/DxePcdLib.inf
>}
> -  IntelFrameworkModulePkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
> +  OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
>OvmfPkg/Csm/Csm16/Csm16.inf
>  !endif
>  
> diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
> index 56a9560262..3a9d25ba4a 100644
> --- a/OvmfPkg/OvmfPkgX64.dsc
> +++ b/OvmfPkg/OvmfPkgX64.dsc
> @@ -690,7 +690,7 @@ [Components]
>  
>  !ifdef $(CSM_ENABLE)
>NULL|OvmfPkg/Csm/CsmSupportLib/CsmSupportLib.inf
> -  
> NULL|IntelFrameworkModulePkg/Library/LegacyBootManagerLib/LegacyBootManagerLib.inf
> +  NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
>  !endif
>}
>MdeModulePkg/Logo/LogoDxe.inf
> @@ -700,8 +700,8 @@ [Components]
>NULL|MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
>
> NULL|MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib.inf
>  !ifdef $(CSM_ENABLE)
> -  
> NULL|IntelFrameworkModulePkg/Library/LegacyBootManagerLib/LegacyBootManagerLib.inf
> -  
> NULL|IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
> +  NULL|OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
> +  NULL|OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
> 

Re: [edk2-devel] [PATCH v2 09/10] OvmfPkg/Csm/LegacyBootManagerLib: Update to make it build for OVMF

[Laszlo Ersek]

On 05/27/19 05:03, Wu, Hao A wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
> 
> This commit will update the library's INF file to:
> 
> A) Assign a new file GUID;
> B) Remove the IntelFramework[Module]Pkg DEC file dependency.
> 
> Please note that a subsequent commit (final patch of the series) will:
> 
> Replace the use of LegacyBootManagerLib in IntelFrameworkModulePkg with
> the one copied in OvmfPkg within DSC files.
> 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Hao A Wu 
> ---
>  OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf 
> b/OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
> index eaf7b7235d..e43351cf95 100644
> --- a/OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
> +++ b/OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  #  Legacy Boot Manager module is library for BDS phase.
>  #
> -#  Copyright (c) 2011 - 2018, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2011 - 2019, Intel Corporation. All rights reserved.
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
>  ##
> @@ -10,7 +10,7 @@ [Defines]
>INF_VERSION= 0x00010005
>BASE_NAME  = LegacyBootManagerLib
>MODULE_UNI_FILE= LegacyBootManagerLib.uni
> -  FILE_GUID  = F1B87BE4-0ACC-409A-A52B-7BFFABCC96A0
> +  FILE_GUID  = D1BBB810-6A9E-40E0-87CB-65EAD2AA2A09
>MODULE_TYPE= DXE_DRIVER
>VERSION_STRING = 1.0
>LIBRARY_CLASS  = NULL|DXE_DRIVER UEFI_APPLICATION
> @@ -29,8 +29,7 @@ [Sources]
>  [Packages]
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
> -  IntelFrameworkPkg/IntelFrameworkPkg.dec
> -  IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
> +  OvmfPkg/OvmfPkg.dec
>  
>  [LibraryClasses]
>BaseLib
> 

Reviewed-by: Laszlo Ersek 

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

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

Re: [edk2-devel] [PATCH v2 08/10] OvmfPkg/Csm/LegacyBootMaintUiLib: Update to make it build for OVMF

[Laszlo Ersek]

On 05/27/19 05:03, Wu, Hao A wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
> 
> This commit will update the library's INF file to:
> 
> A) Assign a new file GUID;
> B) Remove the IntelFramework[Module]Pkg DEC file dependency.
> 
> Please note that a subsequent commit (final patch of the series) will:
> 
> Replace the use of LegacyBootMaintUiLib in IntelFrameworkModulePkg with
> the one copied in OvmfPkg within DSC files.
> 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Hao A Wu 
> ---
>  OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf 
> b/OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
> index 557b8d8169..5cc64a1b2d 100644
> --- a/OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
> +++ b/OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf
> @@ -1,7 +1,7 @@
>  ## @file
>  #  Legacy Boot Maintainence UI module is library for BDS phase.
>  #
> -#  Copyright (c) 2015 - 2018, Intel Corporation. All rights reserved.
> +#  Copyright (c) 2015 - 2019, Intel Corporation. All rights reserved.
>  #  SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
>  ##
> @@ -10,7 +10,7 @@ [Defines]
>INF_VERSION= 0x00010005
>BASE_NAME  = LegacyBootMaintUiLib
>MODULE_UNI_FILE= LegacyBootMaintUiLib.uni
> -  FILE_GUID  = e6f7f038-3ed9-401a-af1f-5ea7bf644d34
> +  FILE_GUID  = 259A90B1-C151-43E5-8A71-82B4E3201F4E
>MODULE_TYPE= DXE_DRIVER
>VERSION_STRING = 1.0
>LIBRARY_CLASS  = NULL|DXE_DRIVER UEFI_APPLICATION
> @@ -32,8 +32,7 @@ [Sources]
>  [Packages]
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
> -  IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
> -  IntelFrameworkPkg/IntelFrameworkPkg.dec
> +  OvmfPkg/OvmfPkg.dec
>  
>  [LibraryClasses]
>DevicePathLib
> 

Reviewed-by: Laszlo Ersek 

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

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

Re: [edk2-devel] [PATCH v2 07/10] OvmfPkg/Csm/LegacyBiosDxe: Update to make it build for OVMF

[Laszlo Ersek]

On 05/27/19 05:03, Wu, Hao A wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
> 
> This commit will update the driver's INF file to:
> 
> A) Assign a new file GUID;
> B) Consume the PCDs duplicated in OvmfPkg DEC file;
> C) Remove the IntelFramework[Module]Pkg DEC file dependency.
> 
> Please note that a subsequent commit (final patch of the series) will:
> 
> Replace the use of LegacyBiosDxe in IntelFrameworkModulePkg with the one
> copied in OvmfPkg within DSC/FDF files.
> 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Hao A Wu 
> ---
>  OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf | 22 +---
>  1 file changed, 10 insertions(+), 12 deletions(-)
> 
> diff --git a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf 
> b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
> index 471d37365c..f6379dcc46 100644
> --- a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
> +++ b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf
> @@ -3,7 +3,7 @@
>  #
>  # This driver installs Legacy Bios Protocol to support CSM module work in 
> EFI system.
>  #
> -# Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>  #
>  # SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -13,7 +13,7 @@ [Defines]
>INF_VERSION= 0x00010005
>BASE_NAME  = LegacyBiosDxe
>MODULE_UNI_FILE= LegacyBiosDxe.uni
> -  FILE_GUID  = F122A15C-C10B-4d54-8F48-60F4F06DD1AD
> +  FILE_GUID  = 46482D14-7CA1-4977-9DDB-64D747E13DE6
>MODULE_TYPE= DXE_DRIVER
>VERSION_STRING = 1.0
>  
> @@ -50,9 +50,7 @@ [Sources.X64]
>  [Packages]
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
> -  IntelFrameworkPkg/IntelFrameworkPkg.dec
> -  IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
> -
> +  OvmfPkg/OvmfPkg.dec
>  
>  [LibraryClasses]
>DevicePathLib
> @@ -116,13 +114,13 @@ [Protocols]
>gEdkiiIoMmuProtocolGuid   ## CONSUMES
>  
>  [Pcd]
> -  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdLegacyBiosCacheLegacyRegion  
> ## CONSUMES
> -  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdEbdaReservedMemorySize   
> ## CONSUMES
> -  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdEndOpromShadowAddress
> ## SOMETIMES_CONSUMES
> -  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdLowPmmMemorySize 
> ## CONSUMES
> -  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdHighPmmMemorySize
> ## CONSUMES
> -  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdOpromReservedMemoryBase  
> ## CONSUMES
> -  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdOpromReservedMemorySize  
> ## CONSUMES
> +  gUefiOvmfPkgTokenSpaceGuid.PcdLegacyBiosCacheLegacyRegion  ## CONSUMES
> +  gUefiOvmfPkgTokenSpaceGuid.PcdEbdaReservedMemorySize   ## CONSUMES
> +  gUefiOvmfPkgTokenSpaceGuid.PcdEndOpromShadowAddress## 
> SOMETIMES_CONSUMES
> +  gUefiOvmfPkgTokenSpaceGuid.PcdLowPmmMemorySize ## CONSUMES
> +  gUefiOvmfPkgTokenSpaceGuid.PcdHighPmmMemorySize## CONSUMES
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOpromReservedMemoryBase  ## CONSUMES
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOpromReservedMemorySize  ## CONSUMES
>  
>  [Depex]
>gEfiLegacyRegion2ProtocolGuid AND gEfiLegacyInterruptProtocolGuid AND 
> gEfiLegacyBiosPlatformProtocolGuid AND gEfiLegacy8259ProtocolGuid AND 
> gEfiGenericMemTestProtocolGuid AND gEfiCpuArchProtocolGuid AND 
> gEfiTimerArchProtocolGuid AND gEfiVariableWriteArchProtocolGuid
> 

Reviewed-by: Laszlo Ersek 

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

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

Re: [edk2-devel] [PATCH v2 06/10] OvmfPkg/Csm/VideoDxe: Update to make it build for OVMF

[Laszlo Ersek]

On 05/27/19 05:03, Wu, Hao A wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
> 
> This commit will update the driver's INF file to:
> 
> A) Assign a new file GUID;
> B) Consume the PCDs duplicated in OvmfPkg DEC file;
> C) Remove the IntelFramework[Module]Pkg DEC file dependency.
> 
> Please note that a subsequent commit (final patch of the series) will:
> 
> Replace the use of VideoDxe in IntelFrameworkModulePkg with the one copied
> in OvmfPkg within DSC/FDF files.
> 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Hao A Wu 
> ---
>  OvmfPkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf | 14 ++
>  1 file changed, 6 insertions(+), 8 deletions(-)
> 
> diff --git a/OvmfPkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf 
> b/OvmfPkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf
> index 1526bc4cc2..1ed4020661 100644
> --- a/OvmfPkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf
> +++ b/OvmfPkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf
> @@ -4,7 +4,7 @@
>  # This driver by using Legacy Bios protocol service to support csm Video
>  # and produce Graphics Output Protocol.
>  #
> -# Copyright (c) 2007 - 2018, Intel Corporation. All rights reserved.
> +# Copyright (c) 2007 - 2019, Intel Corporation. All rights reserved.
>  #
>  # SPDX-License-Identifier: BSD-2-Clause-Patent
>  #
> @@ -14,7 +14,7 @@ [Defines]
>INF_VERSION= 0x00010005
>BASE_NAME  = BiosVideoDxe
>MODULE_UNI_FILE= BiosVideoDxe.uni
> -  FILE_GUID  = 0B04B2ED-861C-42cd-A22F-C3AAFACCB896
> +  FILE_GUID  = 8669E6C9-842B-4B49-BCC3-32C96D244750
>MODULE_TYPE= UEFI_DRIVER
>VERSION_STRING = 1.0
>  
> @@ -38,9 +38,7 @@ [Sources]
>  [Packages]
>MdePkg/MdePkg.dec
>MdeModulePkg/MdeModulePkg.dec
> -  IntelFrameworkPkg/IntelFrameworkPkg.dec
> -  IntelFrameworkModulePkg/IntelFrameworkModulePkg.dec
> -
> +  OvmfPkg/OvmfPkg.dec
>  
>  [LibraryClasses]
>MemoryAllocationLib
> @@ -70,9 +68,9 @@ [Protocols]
>gEfiEdidOverrideProtocolGuid  ## SOMETIMES_CONSUMES
>  
>  [Pcd]
> -  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdBiosVideoSetTextVgaModeEnable 
>  ## CONSUMES
> -  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdBiosVideoCheckVbeEnable   
>  ## CONSUMES
> -  gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdBiosVideoCheckVgaEnable   
>  ## SOMETIMES_CONSUMES
> +  gUefiOvmfPkgTokenSpaceGuid.PcdBiosVideoSetTextVgaModeEnable
>  ## CONSUMES
> +  gUefiOvmfPkgTokenSpaceGuid.PcdBiosVideoCheckVbeEnable  
>  ## CONSUMES
> +  gUefiOvmfPkgTokenSpaceGuid.PcdBiosVideoCheckVgaEnable  
>  ## SOMETIMES_CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution
>  ## SOMETIMES_CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution  
>  ## SOMETIMES_CONSUMES
>  
> 

Reviewed-by: Laszlo Ersek 

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

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

Re: [edk2-devel] [PATCH v2 05/10] OvmfPkg/OvmfPkg.dec: Add PCD definitions used by copied CSM modules

[Laszlo Ersek]

On 05/27/19 05:03, Wu, Hao A wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
> 
> This commit will add the PCD definitions consumed by the duplicated
> drivers:
> 
> * VideoDxe
> * LegacyBiosDxe
> 
> into the OvmfPkg DEC file.
> 
> Please note that, instead of adding these PCDs under section:
> [PcdsFixedAtBuild, PcdsDynamic, PcdsDynamicEx, PcdsPatchableInModule]
> 
> as in IntelFrameworkModulePkg.dec file, they are added in section:
> [PcdsFixedAtBuild]
> 
> in OvmfPkg.dec instead.
> 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Hao A Wu 
> ---
>  OvmfPkg/OvmfPkg.dec | 58 
>  1 file changed, 58 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index 2251f4ca99..9640360f62 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -160,6 +160,64 @@ [PcdsFixedAtBuild]
>#  For the corresponding bits, 0 = Edge triggered and 1 = Level triggered.
>gUefiOvmfPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x|UINT16|0x5
>  
> +  ## Indicates if BiosVideo driver will switch to 80x25 Text VGA Mode when
> +  #  exiting boot service.
> +  #   TRUE  - Switch to Text VGA Mode.
> +  #   FALSE - Does not switch to Text VGA Mode.
> +  
> gUefiOvmfPkgTokenSpaceGuid.PcdBiosVideoSetTextVgaModeEnable|FALSE|BOOLEAN|0x28
> +
> +  ## Indicates if BiosVideo driver will check for VESA BIOS Extension service
> +  #  support.
> +  #   TRUE  - Check for VESA BIOS Extension service.
> +  #   FALSE - Does not check for VESA BIOS Extension service.
> +  gUefiOvmfPkgTokenSpaceGuid.PcdBiosVideoCheckVbeEnable|TRUE|BOOLEAN|0x29
> +
> +  ## Indicates if BiosVideo driver will check for VGA service support.
> +  #  NOTE: If both PcdBiosVideoCheckVbeEnable and PcdBiosVideoCheckVgaEnable
> +  #  are set to FALSE, that means Graphics Output protocol will not be
> +  #  installed, the VGA miniport protocol will be installed instead.
> +  #   TRUE  - Check for VGA service.
> +  #   FALSE - Does not check for VGA service.
> +  gUefiOvmfPkgTokenSpaceGuid.PcdBiosVideoCheckVgaEnable|TRUE|BOOLEAN|0x2a
> +
> +  ## Indicates if memory space for legacy region will be set as cacheable.
> +  #   TRUE  - Set cachebility for legacy region.
> +  #   FALSE - Does not set cachebility for legacy region.
> +  gUefiOvmfPkgTokenSpaceGuid.PcdLegacyBiosCacheLegacyRegion|TRUE|BOOLEAN|0x2b
> +
> +  ## Specify memory size with bytes to reserve EBDA below 640K for OPROM.
> +  #  The value should be a multiple of 4KB.
> +  gUefiOvmfPkgTokenSpaceGuid.PcdEbdaReservedMemorySize|0x8000|UINT32|0x2c
> +
> +  ## Specify memory base address for OPROM to find free memory.
> +  #  Some OPROMs do not use EBDA or PMM to allocate memory for its usage,
> +  #  instead they find the memory filled with zero from 0x2.
> +  #  The value should be a multiple of 4KB.
> +  #  The range should be below the EBDA reserved range from
> +  #  (CONVENTIONAL_MEMORY_TOP - Reserved EBDA Memory Size) to
> +  #  CONVENTIONAL_MEMORY_TOP.
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOpromReservedMemoryBase|0x6|UINT32|0x2d
> +
> +  ## Specify memory size with bytes for OPROM to find free memory.
> +  #  The value should be a multiple of 4KB. And the range should be below the
> +  #  EBDA reserved range from
> +  #  (CONVENTIONAL_MEMORY_TOP - Reserved EBDA Memory Size) to
> +  #  CONVENTIONAL_MEMORY_TOP.
> +  gUefiOvmfPkgTokenSpaceGuid.PcdOpromReservedMemorySize|0x28000|UINT32|0x2e
> +
> +  ## Specify the end of address below 1MB for the OPROM.
> +  #  The last shadowed OpROM should not exceed this address.
> +  gUefiOvmfPkgTokenSpaceGuid.PcdEndOpromShadowAddress|0xd|UINT32|0x2f
> +
> +  ## Specify the low PMM (Post Memory Manager) size with bytes below 1MB.
> +  #  The value should be a multiple of 4KB.
> +  # @Prompt Low PMM (Post Memory Manager) Size
> +  gUefiOvmfPkgTokenSpaceGuid.PcdLowPmmMemorySize|0x1|UINT32|0x30
> +
> +  ## Specify the high PMM (Post Memory Manager) size with bytes above 1MB.
> +  #  The value should be a multiple of 4KB.
> +  gUefiOvmfPkgTokenSpaceGuid.PcdHighPmmMemorySize|0x40|UINT32|0x31
> +
>  [PcdsDynamic, PcdsDynamicEx]
>gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfFlashVariablesEnable|FALSE|BOOLEAN|0x10
> 

Reviewed-by: Laszlo Ersek 

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

View/Reply Online (#42369): https://edk2.groups.io/g/devel/message/42369
Mute This Topic: https://groups.io/mt/31805484/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/2] MdeModulePkg/SdMmcOverride: Add GetOperatingParam notify phase

[Albecki, Mateusz]

Resending to group.

> -Original Message-
> From: Wu, Hao A
> Sent: Monday, June 10, 2019 5:19 AM
> To: Albecki, Mateusz 
> Subject: RE: [PATCH 1/2] MdeModulePkg/SdMmcOverride: Add
> GetOperatingParam notify phase
> 
> Thanks Mateusz,
> 
> Please refer to the comments in patch 2/2 for the reorder in definition
> 'SD_MMC_BUS_MODE'.
> 
> Also, some inline comments below:
> 
> Best Regards,
> Hao Wu
> 
> 
> > -Original Message-
> > From: Albecki, Mateusz
> > Sent: Monday, June 03, 2019 7:34 PM
> > Cc: Albecki, Mateusz; Wu, Hao A; Albecki
> > Subject: [PATCH 1/2] MdeModulePkg/SdMmcOverride: Add
> GetOperatingParam
> > notify phase
> >
> > The new notify phase allows platform to configure additional bus
> > parameters in addition to parameters that can already be configured
> > with capability override. Specifically we allow to configure bus
> > width, clock frequency and driver strength. If platform doesn't wish
> > to configure some of the parameters it can left it on default values
> > and driver will assume it's standard behavior with respect to those
> parameters.
> > The definition of the SD_MMC_BUS_MODE has been extended to
> incorporate
> > SD card default speed and high speed.
> >
> > Cc: hao.a...@intel.com
> > Signed-off-by: Albecki, Mateusz 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > ---
> >  MdeModulePkg/Include/Protocol/SdMmcOverride.h | 58
> > ---
> >  1 file changed, 52 insertions(+), 6 deletions(-)
> >
> > diff --git a/MdeModulePkg/Include/Protocol/SdMmcOverride.h
> > b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
> > index 9c8bf37efd..bb9545c80c 100644
> > --- a/MdeModulePkg/Include/Protocol/SdMmcOverride.h
> > +++ b/MdeModulePkg/Include/Protocol/SdMmcOverride.h
> > @@ -16,14 +16,61 @@
> >  #define EDKII_SD_MMC_OVERRIDE_PROTOCOL_GUID \
> >{ 0xeaf9e3c1, 0xc9cd, 0x46db, { 0xa5, 0xe5, 0x5a, 0x12, 0x4c, 0x83,
> > 0x23,
> > 0x23 } }
> >
> > -#define EDKII_SD_MMC_OVERRIDE_PROTOCOL_VERSION0x2
> > +#define EDKII_SD_MMC_OVERRIDE_PROTOCOL_VERSION0x3
> >
> >  typedef struct _EDKII_SD_MMC_OVERRIDE EDKII_SD_MMC_OVERRIDE;
> >
> > -//
> > -// Bus timing modes
> > -//
> > +#define EDKII_SD_MMC_BUS_WIDTH_IGNORE MAX_UINT16 #define
> > +EDKII_SD_MMC_CLOCK_FREQ_IGNORE MAX_UINT32 #define
> > +EDKII_SD_MMC_DRIVER_STRENGTH_IGNORE  MAX_UINT8
> > +
> > +typedef enum {
> > +  SdDriverStrengthTypeB= 0,
> > +  SdDriverStrengthTypeA,
> > +  SdDriverStrengthTypeC,
> > +  SdDriverStrengthTypeD,
> > +  SdDriverStrengthIgnore = EDKII_SD_MMC_DRIVER_STRENGTH_IGNORE
> > +} SD_DRIVER_STRENGTH_TYPE;
> > +
> >  typedef enum {
> > +  EmmcDriverStrengthType0  = 0,
> > +  EmmcDriverStrengthType1,
> > +  EmmcDriverStrengthType2,
> > +  EmmcDriverStrengthType3,
> > +  EmmcDriverStrengthType4,
> > +  EmmcDriverStrengthIgnore =
> > EDKII_SD_MMC_DRIVER_STRENGTH_IGNORE
> > +} EMMC_DRIVER_STRENGTH_TYPE;
> > +
> > +typedef union {
> > +  SD_DRIVER_STRENGTH_TYPE  Sd;
> > +  EMMC_DRIVER_STRENGTH_TYPEEmmc;
> > +} EDKII_SD_MMC_DRIVER_STRENGTH;
> > +
> > +typedef struct {
> > +  //
> > +  // The target width of the bus. If user tells driver to ignore it
> > +  // or specifies unsuportted width driver will choose highest
> > +supported
> 
> 
> unsuportted -> unsupported
> 
> 
> > +  // bus width for a given mode.
> > +  //
> > +  UINT16BusWidth;
> 
> 
> After seeing some type changes (from UINT8 to UINT16) for some variables
> in the 2nd patch, I realize that the 'BusWidth' type should be UINT8 here and
> the 'EDKII_SD_MMC_BUS_WIDTH_IGNORE' definition should be
> MAX_UINT8.
> 
> I am really sorry for the typo I made in the foil sent to you.
> 
> 
> > +  //
> > +  // The target clock frequency of the bus in MHz. If user tells
> > + driver to
> > ignore
> > +  // it or specifies unsupported frequency driver will choose highest
> > supported
> > +  // clock frequency for a given mode.
> > +  //
> > +  UINT32ClockFreq;
> > +  //
> > +  // The target driver strength of the bus. If user tells driver to
> > + // ignore it or specifies unsupported driver strength, driver will
> > + // default to Type0 for eMMC cards and TypeB for SD cards. Driver
> > strength
> > +  // setting is only considered if choosen bus timing supports them.
> 
> 
> choosen -> chosen
> 
> Best Regards,
> Hao Wu
> 
> 
> > +  //
> > +  EDKII_SD_MMC_DRIVER_STRENGTH  DriverStrength; }
> > +EDKII_SD_MMC_OPERATING_PARAMETERS;
> > +
> > +typedef enum {
> > +  SdMmcSdDs,
> > +  SdMmcSdHs,
> >SdMmcUhsSdr12,
> >SdMmcUhsSdr25,
> >SdMmcUhsSdr50,
> > @@ -43,10 +90,10 @@ typedef enum {
> >EdkiiSdMmcInitHostPost,
> >EdkiiSdMmcUhsSignaling,
> >EdkiiSdMmcSwitchClockFreqPost,
> > +  EdkiiSdMmcGetOperatingParam
> >  } EDKII_SD_MMC_PHASE_TYPE;
> >
> >  /**
> > -
> >Override function for SDHCI capability bits
> >
> >@param[in]  ControllerHandle  The EFI_HANDLE of the controller.
> > @@ -70,7 +117,6 @@ EFI_STATUS
> >);
> 

Re: [edk2-devel] [PATCH v2 04/10] OvmfPkg/OvmfPkg.dec: Add the new include folder for CSM header files

[Laszlo Ersek]

On 05/27/19 05:03, Wu, Hao A wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
> 
> The previous file-duplication commit has put all the CSM related header
> files within folder: OvmfPkg/Csm/Inclue.
> 
> This commit will update the DEC file to add that folder under the
> '[Include]' section.
> 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Hao A Wu 
> ---
>  OvmfPkg/OvmfPkg.dec | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index 59eda563a2..2251f4ca99 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -15,6 +15,7 @@ [Defines]
>  
>  [Includes]
>Include
> +  Csm/Include
>  
>  [LibraryClasses]
>##  @libraryclass  Loads and boots a Linux kernel image
> 

Reviewed-by: Laszlo Ersek 

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

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

Re: [edk2-devel] [PATCH v2 03/10] OvmfPkg/OvmfPkg.dec: Add definitions for CSM-related Guid & Protocol

[Laszlo Ersek]

On 05/27/19 05:03, Wu, Hao A wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
> 
> This commit will add the Guid definitions of the duplicated CSM-related
> Guids and Protocols from IntelFramework[Module]Pkg.
> 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Hao A Wu 
> ---
>  OvmfPkg/OvmfPkg.dec | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
> index 0e555c5c78..59eda563a2 100644
> --- a/OvmfPkg/OvmfPkg.dec
> +++ b/OvmfPkg/OvmfPkg.dec
> @@ -79,6 +79,8 @@ [Guids]
>gXenBusRootDeviceGuid   = {0xa732241f, 0x383d, 0x4d9c, {0x8a, 
> 0xe1, 0x8e, 0x09, 0x83, 0x75, 0x89, 0xd7}}
>gRootBridgesConnectedEventGroupGuid = {0x24a2d66f, 0xeedd, 0x4086, {0x90, 
> 0x42, 0xf2, 0x6e, 0x47, 0x97, 0xee, 0x69}}
>gMicrosoftVendorGuid= {0x77fa9abd, 0x0359, 0x4d32, {0xbd, 
> 0x60, 0x28, 0xf4, 0xe7, 0x8f, 0x78, 0x4b}}
> +  gEfiLegacyBiosGuid  = {0x2E3044AC, 0x879F, 0x490F, {0x97, 
> 0x60, 0xBB, 0xDF, 0xAF, 0x69, 0x5F, 0x50}}
> +  gEfiLegacyDevOrderVariableGuid  = {0xa56074db, 0x65fe, 0x45f7, {0xbd, 
> 0x21, 0x2d, 0x2b, 0xdd, 0x8e, 0x96, 0x52}}
>  
>  [Protocols]
>gVirtioDeviceProtocolGuid   = {0xfa920010, 0x6785, 0x4941, {0xb6, 
> 0xec, 0x49, 0x8c, 0x57, 0x9f, 0x16, 0x0a}}
> @@ -86,6 +88,13 @@ [Protocols]
>gXenIoProtocolGuid  = {0x6efac84f, 0x0ab0, 0x4747, {0x81, 
> 0xbe, 0x85, 0x55, 0x62, 0x59, 0x04, 0x49}}
>gIoMmuAbsentProtocolGuid= {0xf8775d50, 0x8abd, 0x4adf, {0x92, 
> 0xac, 0x85, 0x3e, 0x51, 0xf6, 0xc8, 0xdc}}
>gEfiLegacy8259ProtocolGuid  = {0x38321dba, 0x4fe0, 0x4e17, {0x8a, 
> 0xec, 0x41, 0x30, 0x55, 0xea, 0xed, 0xc1}}
> +  gEfiFirmwareVolumeProtocolGuid  = {0x389F751F, 0x1838, 0x4388, {0x83, 
> 0x90, 0xcd, 0x81, 0x54, 0xbd, 0x27, 0xf8}}
> +  gEfiIsaAcpiProtocolGuid = {0x64a892dc, 0x5561, 0x4536, {0x92, 
> 0xc7, 0x79, 0x9b, 0xfc, 0x18, 0x33, 0x55}}
> +  gEfiIsaIoProtocolGuid   = {0x7ee2bd44, 0x3da0, 0x11d4, {0x9a, 
> 0x38, 0x0, 0x90, 0x27, 0x3f, 0xc1, 0x4d}}
> +  gEfiLegacyBiosProtocolGuid  = {0xdb9a1e3d, 0x45cb, 0x4abb, {0x85, 
> 0x3b, 0xe5, 0x38, 0x7f, 0xdb, 0x2e, 0x2d}}
> +  gEfiLegacyBiosPlatformProtocolGuid  = {0x783658a3, 0x4172, 0x4421, {0xa2, 
> 0x99, 0xe0, 0x09, 0x07, 0x9c, 0x0c, 0xb4}}
> +  gEfiLegacyInterruptProtocolGuid = {0x31ce593d, 0x108a, 0x485d, {0xad, 
> 0xb2, 0x78, 0xf2, 0x1f, 0x29, 0x66, 0xbe}}
> +  gEfiVgaMiniPortProtocolGuid = {0xc7735a2f, 0x88f5, 0x4882, {0xae, 
> 0x63, 0xfa, 0xac, 0x8c, 0x8b, 0x86, 0xb3}}
>  
>  [PcdsFixedAtBuild]
>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfPeiMemFvBase|0x0|UINT32|0
> 

Reviewed-by: Laszlo Ersek 

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

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

Re: [edk2-devel] [PATCH 0/2] Add GetOperatingParam notify phase to SdMmcOverride protocol

[Albecki, Mateusz]

Resending to group.

From: Wu, Hao A
Sent: Monday, June 10, 2019 5:18 AM
To: Albecki, Mateusz 
Subject: RE: [PATCH 0/2] Add GetOperatingParam notify phase to SdMmcOverride 
protocol


Hello Mateusz,



Thanks for the patch series and sorry for the delayed response.



One question first, I did not see the patches being sent to the mailing list

'devel@edk2.groups.io'. We have recently switched to this new mailing list back

to early April, the old one 'edk2-de...@lists.01.org' is no longer being used.



In case that you have not registered the new list, you can sign up at:

https://edk2.groups.io/g/devel

or email:

devel+subscr...@edk2.groups.io

to get registered in the new mailing list.



Or you can send me the patch files and I will help to send them to the mailing 
list.





Below are some general level feedbacks (Other patch-specific feedbacks will be 
replied in other mails):

* Could you help to add the below Bugzilla tracker reference in the 
commit log message?

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



* Could you help to run the script 'BaseTools/Scripts/PatchCheck.py' 
and resolve its report on the commit log format issues?

Checking git commit: 6e3f64aeb4

The commit message format is not valid:

* Contributed-under! (Note: this must be removed by the code contributor!)

* Add quotes (") around name with a comma: Albecki, Mateusz

* Email format is invalid: hao.a...@intel.com

* Line 15 of commit message is too long.

https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format

The code passed all checks.



Checking git commit: 91595ae911

The commit message format is not valid:

* Contributed-under! (Note: this must be removed by the code contributor!)

* Add quotes (") around name with a comma: Albecki, Mateusz

* Email format is invalid: hao.a...@intel.com

https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format

The code passed all checks.



* Could you help to resolve the typo 'Prefered' to 'Preferred' in the 
naming of some variables?



* Could you help to use lowercase 'static' (instead of using the 
uppercase one) for the new functions?





Also, I only verified the build of the patch series. Please grant me some time

to verify on the HW on my side. Maybe your updated patches arrive first and I

will then verify the update ones.





Best Regards,

Hao Wu



> -Original Message-

> From: Albecki, Mateusz

> Sent: Monday, June 03, 2019 7:34 PM

> Cc: Albecki, Mateusz; Wu, Hao A

> Subject: [PATCH 0/2] Add GetOperatingParam notify phase to

> SdMmcOverride protocol

>

> To allow platform greater control over the bus settings for SD card and

> eMMC card

> we have added a new notify phase to SdMmcOverrideProtocol called

> GetOperatingParam.

> This phase is signaled before SD card/eMMC initialization and allows platform

> to tweak

> the values in new structure called

> EDKII_SD_MMC_OPERATING_PARAMETERS which allows to configure

> bus width, clock frequency and driver strength. Other bus parameters can be

> configured by

> overriding host controller capabilities.

>

> Tests:

> - OS boot from eMMC without SdMmcOverride protocol installed

> - OS boot from eMMC with SdMmcOverride installed and clock frequency

> lowered to 100MHz in HS200

> - OS boot from eMMC with driver strength changed to Type1

> - SD card enumeration in UEFI shell on default speed and high speed(non

> UHS-I) with SdMmcOverride installed and UHS-I disabled in capability

>

>

> Cc: hao.a...@intel.com

>

> Albecki, Mateusz (2):

>   MdeModulePkg/SdMmcOverride: Add GetOperatingParam notify phase

>   MdeModulePkg/SdMmcHcDxe: Implement revision 3 of

> SdMmcOverrideProtocol

>

>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/EmmcDevice.c| 522

> +++--

>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdDevice.c  | 381

> ---

>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.c |  52 +-

>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHcDxe.h |  18 +-

>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c   |   8 +-

>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.h   |   8 +-

>  MdeModulePkg/Include/Protocol/SdMmcOverride.h  |  58 ++-

>  7 files changed, 802 insertions(+), 245 deletions(-)

>

> --

> 2.14.1.windows.1




Intel Technology Poland sp. z o.o.
ul. Slowackiego 173 | 80-298 Gdansk | Sad Rejonowy Gdansk Polnoc | VII Wydzial 
Gospodarczy Krajowego Rejestru Sadowego - KRS 101882 | NIP 957-07-52-316 | 
Kapital zakladowy 200.000 PLN.

Ta wiadomosc wraz z zalacznikami jest przeznaczona dla okreslonego adresata i 
moze zawierac informacje poufne. W razie przypadkowego otrzymania tej 
wiadomosci, prosimy o powiadomienie nadawcy oraz trwale jej usuniecie; 
jakiekolwiek
przegladanie lub rozpowszechnianie 

Re: [edk2-devel] [PATCH v2 02/10] OvmfPkg: Copy the required CSM components from framework packages

[Laszlo Ersek]

On 05/27/19 05:03, Wu, Hao A wrote:
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811
> 
> This commit copies the exact:
> 
> Drivers:
> * VideoDxe
> * LegacyBiosDxe
> 
> Libraries:
> * LegacyBootMaintUiLib
> * LegacyBootManagerLib
> 
> Guid header files:
> * Legacy Bios Guid
> * LegacyDevOrder Guid
> 
> Protocol header files:
> * Firmware Volume Protocol
> * ISA ACPI Protocol
> * ISA I/O Protocol
> * Legacy BIOS Protocol
> * Legacy BIOS Platform Protocol
> * Legacy Interrupt Protocol
> * VGA Mini Port Protocol
> 
> Framework header files (within IntelFrameworkPkg):
> * FrameworkDxe.h
> * Framework/BootScript.h
> * Framework/DxeCis.h
> * Framework/FirmwareVolumeHeader.h
> * Framework/FirmwareVolumeImageFormat.h
> * Framework/FrameworkInternalFormRepresentation.h
> * Framework/Hob.h
> * Framework/StatusCode.h
> 
> from IntelFramework[Module]Pkg to OvmfPkg/Csm/ folder.
> 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Hao A Wu 
> ---
>  OvmfPkg/Csm/BiosThunk/VideoDxe/VideoDxe.inf |   80 +
>  OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.inf |  131 +
>  OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.inf   |   63 +
>  OvmfPkg/Csm/LegacyBootManagerLib/LegacyBootManagerLib.inf   |   58 +
>  OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.h  |  532 
> 
>  OvmfPkg/Csm/BiosThunk/VideoDxe/VesaBiosExtensions.h |  459 
> +++
>  OvmfPkg/Csm/Include/Framework/BootScript.h  |   41 +
>  OvmfPkg/Csm/Include/Framework/DxeCis.h  |  170 +
>  OvmfPkg/Csm/Include/Framework/FirmwareVolumeHeader.h|   79 +
>  OvmfPkg/Csm/Include/Framework/FirmwareVolumeImageFormat.h   |   32 +
>  OvmfPkg/Csm/Include/Framework/FrameworkInternalFormRepresentation.h |  397 
> +++
>  OvmfPkg/Csm/Include/Framework/Hob.h |   28 +
>  OvmfPkg/Csm/Include/Framework/StatusCode.h  |  155 +
>  OvmfPkg/Csm/Include/FrameworkDxe.h  |   26 +
>  OvmfPkg/Csm/Include/Guid/LegacyBios.h   |   29 +
>  OvmfPkg/Csm/Include/Guid/LegacyDevOrder.h   |   39 +
>  OvmfPkg/Csm/Include/Protocol/FirmwareVolume.h   |  340 ++
>  OvmfPkg/Csm/Include/Protocol/IsaAcpi.h  |  298 ++
>  OvmfPkg/Csm/Include/Protocol/IsaIo.h|  356 
> +++
>  OvmfPkg/Csm/Include/Protocol/LegacyBios.h   | 1553 
> +
>  OvmfPkg/Csm/Include/Protocol/LegacyBiosPlatform.h   |  755 
> +
>  OvmfPkg/Csm/Include/Protocol/LegacyInterrupt.h  |  122 +
>  OvmfPkg/Csm/Include/Protocol/VgaMiniPort.h  |   88 +
>  OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosInterface.h | 1460 
> +
>  OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUi.h|  249 ++
>  OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiVfr.h |   79 +
>  OvmfPkg/Csm/LegacyBootManagerLib/InternalLegacyBm.h |   60 +
>  OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideo.c  | 3289 
> 
>  OvmfPkg/Csm/BiosThunk/VideoDxe/ComponentName.c  |  306 ++
>  OvmfPkg/Csm/LegacyBiosDxe/LegacyBbs.c   |  377 
> +++
>  OvmfPkg/Csm/LegacyBiosDxe/LegacyBda.c   |   62 +
>  OvmfPkg/Csm/LegacyBiosDxe/LegacyBios.c  | 1214 
> 
>  OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c   | 2173 
> +
>  OvmfPkg/Csm/LegacyBiosDxe/LegacyCmos.c  |  117 +
>  OvmfPkg/Csm/LegacyBiosDxe/LegacyIde.c   |  310 ++
>  OvmfPkg/Csm/LegacyBiosDxe/LegacyPci.c   | 3083 
> ++
>  OvmfPkg/Csm/LegacyBiosDxe/LegacySio.c   |  477 
> +++
>  OvmfPkg/Csm/LegacyBiosDxe/Thunk.c   |  419 
> +++
>  OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUi.c| 1505 
> +
>  OvmfPkg/Csm/LegacyBootManagerLib/LegacyBm.c | 1530 
> +
>  OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideoDxe.uni |   17 +
>  OvmfPkg/Csm/BiosThunk/VideoDxe/BiosVideoDxeExtra.uni|   14 +
>  OvmfPkg/Csm/LegacyBiosDxe/IA32/InterruptTable.nasm  |   63 +
>  OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxe.uni |   16 +
>  OvmfPkg/Csm/LegacyBiosDxe/LegacyBiosDxeExtra.uni|   14 +
>  OvmfPkg/Csm/LegacyBiosDxe/X64/InterruptTable.nasm   |   64 +
>  OvmfPkg/Csm/LegacyBootMaintUiLib/LegacyBootMaintUiLib.uni   |   20 +
>  

Re: [edk2-devel] [PATCH v2 01/10] Maintainers.txt: Add maintainer for CSM components in OvmfPkg

[Laszlo Ersek]

On 05/27/19 05:03, Wu, Hao A wrote:
> According to the discussion at:
> 
> https://edk2.groups.io/g/devel/topic/31627718#40659
> (Request by Laszlo to find proper maintainer for to-be-duplicated CSM
> components in OvmfPkg.)
> 
> and:
> 
> https://edk2.groups.io/g/devel/topic/31682287#40996
> (Confirmation with David Woodhouse as the maintainer for the
> to-be-duplicated CSM components in OvmfPkg.)
> 
> This commit will add David Woodhouse as the maintainer for the CSM
> modules under OvmfPkg.
> 
> Please note that the duplication of the required CSM modules from
> framework packages to OvmfPkg will be done in subsequent commits.
> 
> Cc: David Woodhouse 
> Cc: Ray Ni 
> Cc: Jordan Justen 
> Cc: Laszlo Ersek 
> Cc: Ard Biesheuvel 
> Signed-off-by: Hao A Wu 
> ---
>  Maintainers.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Maintainers.txt b/Maintainers.txt
> index aaabe2b52d..3b8449dd66 100644
> --- a/Maintainers.txt
> +++ b/Maintainers.txt
> @@ -198,6 +198,8 @@ R: Marc-André Lureau 
> (TPM2 modules)
>  R: Stefan Berger 
> (TPM2 modules)
> +R: David Woodhouse 
> +   (CSM modules)
>  S: Maintained
>
>  PcAtChipsetPkg
> 

Reviewed-by: Laszlo Ersek 

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

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

Re: [edk2-devel] [PATCH v4 0/2] Add SCSI Support for Storage Security Command Protocol

[Liming Gao]

Zurcher:
  Can you share what test has been done for this feature?

Thanks
Liming
> -Original Message-
> From: Zurcher, Christopher J
> Sent: Thursday, June 13, 2019 10:05 AM
> To: devel@edk2.groups.io
> Cc: Kinney, Michael D ; Yao, Jiewen 
> ; Wang, Jian J ; Gao,
> Liming 
> Subject: [PATCH v4 0/2] Add SCSI Support for Storage Security Command Protocol
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1546
> 
> V4 changes:
> Add SSC Protocol in addition to BlockIo instead of in place of BlockIo.
> Add error handling for (BlockSize == 0) in Read and WriteBlocks commands
> to handle partitions that do not support ReadCapacity().
> 
> V3 changes:
> Initialize AlignedBuffer variable in ScsiDiskReceiveData and
> ScsiDiskSendData functions. Remove redundant input validation and debug
> message in ScsiDiskSendData.
> 
> V2 changes:
> Split the patch into separate commits for separate packages.
> 
> To support RPMB access on UFS devices, support must be added to
> the ScsiDiskDxe driver for the Storage Security Command Protocol.
> 
> Cc: Michael D Kinney 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Liming Gao 
> 
> Christopher J Zurcher (2):
>   MdePkg: Implement SCSI commands for Security Protocol In/Out
>   MdeModulePkg/ScsiDiskDxe: Support Storage Security Command Protocol
> 
>  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDiskDxe.inf |   3 +-
>  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.h  | 171 ++-
>  MdePkg/Include/IndustryStandard/Scsi.h|  48 +-
>  MdePkg/Include/Library/UefiScsiLib.h  | 126 -
>  MdePkg/Include/Protocol/ScsiIo.h  |   9 +-
>  MdeModulePkg/Bus/Scsi/ScsiBusDxe/ScsiBus.c|   5 +-
>  MdeModulePkg/Bus/Scsi/ScsiDiskDxe/ScsiDisk.c  | 522 +++-
>  MdeModulePkg/Bus/Ufs/UfsPassThruDxe/UfsPassThru.c |  19 +-
>  MdePkg/Library/UefiScsiLib/UefiScsiLib.c  | 205 +++-
>  9 files changed, 1064 insertions(+), 44 deletions(-)
> 
> --
> 2.16.2.windows.1


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

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

Re: [edk2-devel] [PATCH v4 1/2] MdePkg: Implement SCSI commands for Security Protocol In/Out

[Liming Gao]

> -Original Message-
> From: Zurcher, Christopher J
> Sent: Thursday, June 13, 2019 10:05 AM
> To: devel@edk2.groups.io
> Cc: Yao, Jiewen ; Wang, Jian J ; 
> Gao, Liming 
> Subject: [PATCH v4 1/2] MdePkg: Implement SCSI commands for Security Protocol 
> In/Out
> 
> This patch implements the Security Protocol In and Security Protocol Out
> commands in UefiScsiLib to prepare support for the Storage Security
> Command Protocol.
> 
> Cc: Jiewen Yao 
> Cc: Jian J Wang 
> Cc: Liming Gao 
> Signed-off-by: Christopher J Zurcher 
> ---
>  MdePkg/Include/IndustryStandard/Scsi.h   |  48 +++--
>  MdePkg/Include/Library/UefiScsiLib.h | 126 +++-
>  MdePkg/Include/Protocol/ScsiIo.h |   9 +-
>  MdePkg/Library/UefiScsiLib/UefiScsiLib.c | 205 +++-
>  4 files changed, 366 insertions(+), 22 deletions(-)
> 
> diff --git a/MdePkg/Include/IndustryStandard/Scsi.h 
> b/MdePkg/Include/IndustryStandard/Scsi.h
> index cbe5709fe5..10d7b49ba7 100644
> --- a/MdePkg/Include/IndustryStandard/Scsi.h
> +++ b/MdePkg/Include/IndustryStandard/Scsi.h
> @@ -1,7 +1,7 @@
>  /** @file
>Support for SCSI-2 standard
> 
> -  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
> +  Copyright (c) 2006 - 2019, Intel Corporation. All rights reserved.
>SPDX-License-Identifier: BSD-2-Clause-Patent
> 
>  **/
> @@ -163,6 +163,12 @@
>  #define EFI_SCSI_OP_SEND_MESSAGE10  0x2a
>  #define EFI_SCSI_OP_SEND_MESSAGE12  0xaa
> 
> +//
> +// Additional commands for Secure Transactions
> +//
> +#define EFI_SCSI_OP_SECURITY_PROTOCOL_IN  0xa2
> +#define EFI_SCSI_OP_SECURITY_PROTOCOL_OUT 0xb5
> +
>  //
>  // SCSI Data Transfer Direction
>  //
> @@ -172,22 +178,30 @@
>  //
>  // Peripheral Device Type Definitions
>  //
> -#define EFI_SCSI_TYPE_DISK  0x00  ///< Direct-access device (e.g. 
> magnetic disk)
> -#define EFI_SCSI_TYPE_TAPE  0x01  ///< Sequential-access device 
> (e.g. magnetic tape)
> -#define EFI_SCSI_TYPE_PRINTER   0x02  ///< Printer device
> -#define EFI_SCSI_TYPE_PROCESSOR 0x03  ///< Processor device
> -#define EFI_SCSI_TYPE_WORM  0x04  ///< Write-once device (e.g. some 
> optical disks)
> -#define EFI_SCSI_TYPE_CDROM 0x05  ///< CD-ROM device
> -#define EFI_SCSI_TYPE_SCANNER   0x06  ///< Scanner device
> -#define EFI_SCSI_TYPE_OPTICAL   0x07  ///< Optical memory device (e.g. 
> some optical disks)
> -#define EFI_SCSI_TYPE_MEDIUMCHANGER 0x08  ///< Medium changer device (e.g. 
> jukeboxes)
> -#define EFI_SCSI_TYPE_COMMUNICATION 0x09  ///< Communications device
> -#define EFI_SCSI_TYPE_ASCIT8_1  0x0A  ///< Defined by ASC IT8 (Graphic 
> arts pre-press devices)
> -#define EFI_SCSI_TYPE_ASCIT8_2  0x0B  ///< Defined by ASC IT8 (Graphic 
> arts pre-press devices)

Why remove ASCIT8_1 & ASCIT8_2? Can we keep them for compatibility?

> -//
> -// 0Ch - 1Eh are reserved
> -//
> -#define EFI_SCSI_TYPE_UNKNOWN   0x1F  ///< Unknown or no device type
> +#define EFI_SCSI_TYPE_DISK0x00  ///< Direct-access device (e.g. 
> magnetic disk)
> +#define EFI_SCSI_TYPE_TAPE0x01  ///< Sequential-access device 
> (e.g. magnetic tape)
> +#define EFI_SCSI_TYPE_PRINTER 0x02  ///< Printer device
> +#define EFI_SCSI_TYPE_PROCESSOR   0x03  ///< Processor device
> +#define EFI_SCSI_TYPE_WORM0x04  ///< Write-once device (e.g. 
> some optical disks)
> +#define EFI_SCSI_TYPE_CDROM   0x05  ///< CD/DVD device
> +#define EFI_SCSI_TYPE_SCANNER 0x06  ///< Scanner device (obsolete)
> +#define EFI_SCSI_TYPE_OPTICAL 0x07  ///< Optical memory device (e.g. 
> some optical disks)
> +#define EFI_SCSI_TYPE_MEDIUMCHANGER   0x08  ///< Medium changer device (e.g. 
> jukeboxes)
> +#define EFI_SCSI_TYPE_COMMUNICATION   0x09  ///< Communications device 
> (obsolete)
> +#define EFI_SCSI_TYPE_A   0x0A  ///< Obsolete
> +#define EFI_SCSI_TYPE_B   0x0B  ///< Obsolete
> +#define EFI_SCSI_TYPE_RAID0x0C  ///< Storage array controller 
> device (e.g., RAID)
> +#define EFI_SCSI_TYPE_SES 0x0D  ///< Enclosure services device
> +#define EFI_SCSI_TYPE_RBC 0x0E  ///< Simplified direct-access 
> device (e.g., magnetic disk)
> +#define EFI_SCSI_TYPE_OCRW0x0F  ///< Optical card reader/writer 
> device
> +#define EFI_SCSI_TYPE_BRIDGE  0x10  ///< Bridge Controller Commands
> +#define EFI_SCSI_TYPE_OSD 0x11  ///< Object-based Storage Device
> +#define EFI_SCSI_TYPE_AUTOMATION  0x12  ///< Automation/Drive Interface
> +#define EFI_SCSI_TYPE_SECURITYMANAGER 0x13  ///< Security manager device
> +#define EFI_SCSI_TYPE_RESERVED_LOW0x14  ///< Reserved (low)
> +#define EFI_SCSI_TYPE_RESERVED_HIGH   0x1D  ///< Reserved (high)
> +#define EFI_SCSI_TYPE_WLUN0x1E  ///< Well known logical unit
> +#define EFI_SCSI_TYPE_UNKNOWN 0x1F  ///< Unknown or no device type
> 
>  //
>  // Page Codes for INQUIRY command
> diff --git 

Re: [edk2-devel] [PATCH 11/10] OvmfPkg/Csm/LegacyBiosDxe: Correct Legacy16GetTableAddress call for E820 data

[Laszlo Ersek]

On 06/13/19 10:34, David Woodhouse wrote:
> On Thu, 2019-06-13 at 06:28 +, Wu, Hao A wrote:
>> Hello Ray,
>>
>> Do you have comment on this?
>>
>> Some inline comments below:
>>
>>> -Original Message-
>>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>>> David Woodhouse
>>> Sent: Thursday, June 13, 2019 5:43 AM
>>> To: Wu, Hao A
>>> Cc: devel@edk2.groups.io; Ni, Ray; Justen, Jordan L; Laszlo Ersek; Ard
>>> Biesheuvel
>>> Subject: [edk2-devel] [PATCH 11/10] OvmfPkg/Csm/LegacyBiosDxe: Correct
>>> Legacy16GetTableAddress call for E820 data
>>>
>>> The DX register is supposed to contain the required alignment for the
>>> allocation. It was zero, and SeaBIOS doesn't (well, didn't) cope well
>>> with that. Set it appropriately, and set BX to indicate the regions
>>> it's OK to allocate in too. That was already OK but let's make sure
>>> it's initialised properly and not just working by chance.
>>>
>>> Also actually return an error if the allocation fails. Instead of going
>>> all the way through into the CSM and just letting it have a bogus
>>> pointer to the E82o data.
>>>
>>> Signed-off-by: David Woodhouse 
>>> ---
>>> I made SeaBIOS cope with the zero too:
>>> https://mail.coreboot.org/hyperkitty/list/seab...@seabios.org/thread/4PH
>>> W3O3Y3HJFENODFV5INBGDLZMXA5KE/
>>>
>>>  OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c | 3 +++
>>
>>
>> Not sure if it is the issue of my mail client, the new lines added are
>> with LF line ending on my local machine after applying the patch.
> 
> Hm, that's normal, isn't it?
> 
> We still haven't fixed the repository to store LF line endings
> internally and then let all the tools automatically do the right thing
> by checking out to LF or CRLF as appropriate for the system you're
> checking out on.
> 
> I vaguely recall that Laszlo has some scripts which mangle an email and
> make it apply with CRLF? But only vaguely... which is why I asked for a
> git tree instead of trying to run the gauntlet of trying to apply
> patches 1-10 of your series myself.
> 
> I've pushed v2 with the E82o typo fixed, and using BX==0, to 
> http://git.infradead.org/users/dwmw2/edk2.git/shortlog/refs/heads/csm
> git://http://git.infradead.org/users/dwmw2/edk2.git csm
> 
> I'll try sending that with git-send-email directly rather than with via
> my mailer, but IIRC that doesn't make any difference. CRLF conversions
> are baked into every level — even SMTP converts to send CRLF on the
> wire and often back again at the receive side. 

You may be remembering this article:

https://github.com/tianocore/tianocore.github.io/wiki/Laszlo's-unkempt-git-guide-for-edk2-contributors-and-maintainers

I think Hao may have missed "--keep-cr" with git-am (or "git config
am.keepcr true" for a permanent setting).

Leif recently implemented a python script that configures one's git
clone the way we suggest:

1 5b3e695d8ac5 BaseTools: add centralized location for git config files
2 4eb0acb1e2be BaseTools: add script to configure local git options


The conversion of the repo's internal representation to LF has not been
forgotten (nor abandoned); it's just that I've personally learned to
cope with CRLF, and everyone's got to pick their fights. I support the
conversion but I have no capacity for working on it.

Thanks,
Laszlo

>>
>>>  1 file changed, 3 insertions(+)
>>>
>>> diff --git a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
>>> b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
>>> index 211750c012..e7766eb2b1 100644
>>> --- a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
>>> +++ b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
>>> @@ -928,7 +928,9 @@ GenericLegacyBoot (
>>>if (CopySize > Private->Legacy16Table->E820Length) {
>>>  ZeroMem (, sizeof (EFI_IA32_REGISTER_SET));
>>>  Regs.X.AX = Legacy16GetTableAddress;
>>> +Regs.X.BX = (UINT16) 0x3; // Region
>>
>>
>> According to the spec:
>>
>> '''
>> BX = Allocation region
>> 00 = Allocate from either 0xE or 0xF 64 KB blocks.
>> Bit 0 = 1 Allocate from 0xF 64 KB block
>> Bit 1 = 1 Allocate from 0xE 64 KB block
>> '''
>>
>> I think the value 0 for BX is fine which indicates the allocation can
>> happen in either ranges. Not sure if setting BX to 0x11 is a valid
>> operation.
> 
> Note, I may have lied in my reply to Jordan when I said that 0x11 is
> what was already happening. The way SeaBIOS copes with zero is by
> setting it to 3... *before* the debug print showing what it was set to.
> 
>> With the above comments handled:
>> Reviewed-by: Hao A Wu 
> 
> Thanks.
> 


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

View/Reply Online (#42360): https://edk2.groups.io/g/devel/message/42360
Mute This Topic: https://groups.io/mt/32045939/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/2] MdePkg: Add Generic Initiator Affinity Structure definitions to SRAT

[Liming Gao]

Reviewed-by: Liming Gao 

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of 
> Krzysztof Koch
> Sent: Wednesday, June 12, 2019 10:11 PM
> To: devel@edk2.groups.io
> Cc: Carsey, Jaben ; Ni, Ray ; Gao, 
> Zhichao ; Kinney, Michael D
> ; Gao, Liming ; 
> sami.muja...@arm.com; matteo.carl...@arm.com;
> stephanie.hughes-f...@arm.com; n...@arm.com
> Subject: [edk2-devel] [PATCH v1 1/2] MdePkg: Add Generic Initiator Affinity 
> Structure definitions to SRAT
> 
> Add Generic Initiator Affinity Structure to the list of recognised
> System Resource Affinity Table (SRAT) structure types.
> 
> Add definitions for Device Handle Types inside the Generic Initiator
> Affinity Structure.
> 
> References:
> - ACPI 6.3 January 2019, Table 5-78
> 
> Signed-off-by: Krzysztof Koch 
> ---
> 
> Changes can be seen at: 
> https://github.com/KrzysztofKoch1/edk2/tree/582_acpiview_6_3_srat_v1
> 
> Notes:
> v1:
> - define the SRAT Generic Initiator Affinity Struct type [Krzysztof]
> - define the SRAT Device Handle Types [Krzysztof]
> 
>  MdePkg/Include/IndustryStandard/Acpi63.h | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/MdePkg/Include/IndustryStandard/Acpi63.h 
> b/MdePkg/Include/IndustryStandard/Acpi63.h
> index 
> a8e011579ffcf070ecdfd2c6726a16d1afd65891..eca1f9357b70f10887e680ff13c97c0beab3600b
>  100644
> --- a/MdePkg/Include/IndustryStandard/Acpi63.h
> +++ b/MdePkg/Include/IndustryStandard/Acpi63.h
> @@ -639,7 +639,7 @@ typedef struct {
> 
>  //
>  // SRAT structure types.
> -// All other values between 0x05 an 0xFF are reserved and
> +// All other values between 0x06 an 0xFF are reserved and
>  // will be ignored by OSPM.
>  //
>  #define EFI_ACPI_6_3_PROCESSOR_LOCAL_APIC_SAPIC_AFFINITY  0x00
> @@ -647,6 +647,7 @@ typedef struct {
>  #define EFI_ACPI_6_3_PROCESSOR_LOCAL_X2APIC_AFFINITY  0x02
>  #define EFI_ACPI_6_3_GICC_AFFINITY0x03
>  #define EFI_ACPI_6_3_GIC_ITS_AFFINITY 0x04
> +#define EFI_ACPI_6_3_GENERIC_INITIATOR_AFFINITY   0x05
> 
>  ///
>  /// Processor Local APIC/SAPIC Affinity Structure Definition
> @@ -733,6 +734,14 @@ typedef struct {
>UINT32  ItsId;
>  } EFI_ACPI_6_3_GIC_ITS_AFFINITY_STRUCTURE;
> 
> +//
> +// Generic Initiator Affinity Structure Device Handle Types
> +// All other values between 0x02 an 0xFF are reserved and
> +// will be ignored by OSPM.
> +//
> +#define EFI_ACPI_6_3_ACPI_DEVICE_HANDLE 0x00
> +#define EFI_ACPI_6_3_PCI_DEVICE_HANDLE  0x01
> +
>  ///
>  /// Device Handle - ACPI
>  ///
> --
> 'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'
> 
> 
> 
> 


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

View/Reply Online (#42359): https://edk2.groups.io/g/devel/message/42359
Mute This Topic: https://groups.io/mt/32043797/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 2/2] ShellPkg: acpiview: Update SRAT parser to ACPI 6.3

[Alexei Fedorov]

Reviewed-by: Alexei Fedorov 

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

View/Reply Online (#42358): https://edk2.groups.io/g/devel/message/42358
Mute This Topic: https://groups.io/mt/32042587/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/2] Update the SRAT Acpiview parser to ACPI 6.3

[Alexei Fedorov]

Reviewed-by: Alexei Fedorov 

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

View/Reply Online (#42357): https://edk2.groups.io/g/devel/message/42357
Mute This Topic: https://groups.io/mt/32042460/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] Platforms/Hisilicon: update OptionRomPkg path for HiKey

[Leif Lindholm]

On Thu, Jun 13, 2019 at 01:42:29PM +0200, Ard Biesheuvel wrote:
> On Thu, 13 Jun 2019 at 13:41, Leif Lindholm  wrote:
> >
> > The migration of OptionRomPkg to edk2-platforms broke the HiKey build.
> > Update the paths in .dsc/.fdf to restore.
> >
> > Signed-off-by: Leif Lindholm 
> 
> Acked-by: Ard Biesheuvel 

Thanks!
Pushed as 06910756b8.

> > ---
> >  Platform/Hisilicon/HiKey/HiKey.dsc | 2 +-
> >  Platform/Hisilicon/HiKey/HiKey.fdf | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Platform/Hisilicon/HiKey/HiKey.dsc 
> > b/Platform/Hisilicon/HiKey/HiKey.dsc
> > index c785af6e69..bcbe4fafce 100644
> > --- a/Platform/Hisilicon/HiKey/HiKey.dsc
> > +++ b/Platform/Hisilicon/HiKey/HiKey.dsc
> > @@ -246,7 +246,7 @@ [Components.common]
> >#
> ># AX88772 Ethernet Driver
> >#
> > -  OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772b.inf
> > +  Drivers/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772b.inf
> >
> >#
> ># FAT filesystem + GPT/MBR partitioning
> > diff --git a/Platform/Hisilicon/HiKey/HiKey.fdf 
> > b/Platform/Hisilicon/HiKey/HiKey.fdf
> > index 2b2e3ad053..33fa0da208 100644
> > --- a/Platform/Hisilicon/HiKey/HiKey.fdf
> > +++ b/Platform/Hisilicon/HiKey/HiKey.fdf
> > @@ -158,7 +158,7 @@ [FV.FvMain]
> >#
> ># AX88772 Ethernet Driver for Apple Ethernet Adapter
> >#
> > -  INF OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772b.inf
> > +  INF Drivers/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772b.inf
> >
> >#
> ># FAT filesystem + GPT/MBR partitioning
> > --
> > 2.11.0
> >
> 
> 
> 

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

View/Reply Online (#42356): https://edk2.groups.io/g/devel/message/42356
Mute This Topic: https://groups.io/mt/32051247/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/2] MdePkg: Add Generic Initiator Affinity Structure definitions to SRAT

[Alexei Fedorov]

Reviewed-by: Alexei Fedorov 

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

View/Reply Online (#42355): https://edk2.groups.io/g/devel/message/42355
Mute This Topic: https://groups.io/mt/32043797/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] Platforms/Hisilicon: update OptionRomPkg path for HiKey

[Ard Biesheuvel]

On Thu, 13 Jun 2019 at 13:41, Leif Lindholm  wrote:
>
> The migration of OptionRomPkg to edk2-platforms broke the HiKey build.
> Update the paths in .dsc/.fdf to restore.
>
> Signed-off-by: Leif Lindholm 

Acked-by: Ard Biesheuvel 

> ---
>  Platform/Hisilicon/HiKey/HiKey.dsc | 2 +-
>  Platform/Hisilicon/HiKey/HiKey.fdf | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Platform/Hisilicon/HiKey/HiKey.dsc 
> b/Platform/Hisilicon/HiKey/HiKey.dsc
> index c785af6e69..bcbe4fafce 100644
> --- a/Platform/Hisilicon/HiKey/HiKey.dsc
> +++ b/Platform/Hisilicon/HiKey/HiKey.dsc
> @@ -246,7 +246,7 @@ [Components.common]
>#
># AX88772 Ethernet Driver
>#
> -  OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772b.inf
> +  Drivers/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772b.inf
>
>#
># FAT filesystem + GPT/MBR partitioning
> diff --git a/Platform/Hisilicon/HiKey/HiKey.fdf 
> b/Platform/Hisilicon/HiKey/HiKey.fdf
> index 2b2e3ad053..33fa0da208 100644
> --- a/Platform/Hisilicon/HiKey/HiKey.fdf
> +++ b/Platform/Hisilicon/HiKey/HiKey.fdf
> @@ -158,7 +158,7 @@ [FV.FvMain]
>#
># AX88772 Ethernet Driver for Apple Ethernet Adapter
>#
> -  INF OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772b.inf
> +  INF Drivers/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772b.inf
>
>#
># FAT filesystem + GPT/MBR partitioning
> --
> 2.11.0
>

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

View/Reply Online (#42354): https://edk2.groups.io/g/devel/message/42354
Mute This Topic: https://groups.io/mt/32051247/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] Platforms/Hisilicon: update OptionRomPkg path for HiKey

[Leif Lindholm]

The migration of OptionRomPkg to edk2-platforms broke the HiKey build.
Update the paths in .dsc/.fdf to restore.

Signed-off-by: Leif Lindholm 
---
 Platform/Hisilicon/HiKey/HiKey.dsc | 2 +-
 Platform/Hisilicon/HiKey/HiKey.fdf | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Platform/Hisilicon/HiKey/HiKey.dsc 
b/Platform/Hisilicon/HiKey/HiKey.dsc
index c785af6e69..bcbe4fafce 100644
--- a/Platform/Hisilicon/HiKey/HiKey.dsc
+++ b/Platform/Hisilicon/HiKey/HiKey.dsc
@@ -246,7 +246,7 @@ [Components.common]
   #
   # AX88772 Ethernet Driver
   #
-  OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772b.inf
+  Drivers/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772b.inf
 
   #
   # FAT filesystem + GPT/MBR partitioning
diff --git a/Platform/Hisilicon/HiKey/HiKey.fdf 
b/Platform/Hisilicon/HiKey/HiKey.fdf
index 2b2e3ad053..33fa0da208 100644
--- a/Platform/Hisilicon/HiKey/HiKey.fdf
+++ b/Platform/Hisilicon/HiKey/HiKey.fdf
@@ -158,7 +158,7 @@ [FV.FvMain]
   #
   # AX88772 Ethernet Driver for Apple Ethernet Adapter
   #
-  INF OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772b.inf
+  INF Drivers/OptionRomPkg/Bus/Usb/UsbNetworking/Ax88772b/Ax88772b.inf
 
   #
   # FAT filesystem + GPT/MBR partitioning
-- 
2.11.0


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

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

Re: [edk2-devel] [PATCH V4 0/2] MdeModulePkg: Make the screen seamless

[Laszlo Ersek]

On 06/13/19 08:58, Wu, Hao A wrote:
>> -Original Message-
>> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
>> Wu, Hao A
>> Sent: Monday, May 27, 2019 10:15 AM
>> To: Gao, Zhichao; devel@edk2.groups.io
>> Cc: Wang, Jian J; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan; Michael
>> Turner; Bret Barkelew; Laszlo Ersek
>> Subject: Re: [edk2-devel] [PATCH V4 0/2] MdeModulePkg: Make the screen
>> seamless
>>
>> For my understanding, the series looks like a feature rather than bug to me.
>> I suggest to hold this one until the stable tag is created.
> 
> 
> Pushed via commits e85cfa2fa4..0a35997643.

Thanks for handling this!
Laszlo

> 
> Best Regards,
> Hao Wu
> 
> 
>>
>> Best Regards,
>> Hao Wu
>>
>>
>>> -Original Message-
>>> From: Gao, Zhichao
>>> Sent: Friday, May 24, 2019 10:40 AM
>>> To: devel@edk2.groups.io
>>> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan;
>>> Michael Turner; Bret Barkelew; Laszlo Ersek
>>> Subject: [PATCH V4 0/2] MdeModulePkg: Make the screen seamless
>>>
>>> For now most platforms support display function at PEI phase.
>>> But the conspliter and graphics console driver would clear the
>>> screen at BDS connect console phase. Maybe some platforms would
>>> show logo in the next or maybe not. For consumers, it looks like
>>> the screen flashed.
>>> So change the behavior of graphics console devices while connect
>>> console devices to maintain seamless screen from PEI.
>>>
>>> Test has done on MinPlatform Kabylake-RVP3 which support PEI
>>> display.
>>>
>>> V2:
>>> Make the SetMode not clear the screen only at the first boot during
>>> the first conncettion of graphics device.
>>>
>>> V3:
>>> Abandon V2. Directly set the output mode without clear the screen
>>> while initialize the graphics console device. Add clear screen operation
>>> in stop function of graphics console device.
>>>
>>> V4:
>>> Fix incorrect mode check in V3.
>>> Initialize the mode to an invalid mode. If no perfer mode is found, it
>>> is better to initialize its text mode to an invalid one.
>>> Remove the ClearScreen fuction in the BindingStop function in V3.
>>> The graphics output driver may disconnect before graphics console, that
>>> may cause a system exception because of using released resource.
>>> Impact: the screen would not be cleared after reconnect the graphics
>> device
>>> thru software, such as 'reconnect -r' in shell.
>>>
>>> Cc: Jian J Wang 
>>> Cc: Hao Wu 
>>> Cc: Ray Ni 
>>> Cc: Star Zeng 
>>> Cc: Liming Gao 
>>> Cc: Sean Brogan 
>>> Cc: Michael Turner 
>>> Cc: Bret Barkelew 
>>> Cc: Laszlo Ersek 
>>>
>>> Aaron Antone (1):
>>>   MdeModulePkg/ConSplitterDxe: Optimize the
>>> ConSplitterTextOutSetMode
>>>
>>> Zhichao Gao (1):
>>>   MdeModulePkg/GraphicsConsoleDxe: Initialize the output mode
>>>
>>>  .../Console/ConSplitterDxe/ConSplitter.c  | 33 ++-
>>>  .../Console/ConSplitterDxe/ConSplitter.h  |  4 +-
>>>  .../GraphicsConsoleDxe/GraphicsConsole.c  | 42 ++-
>>>  .../GraphicsConsoleDxe/GraphicsConsoleDxe.inf |  2 +
>>>  4 files changed, 59 insertions(+), 22 deletions(-)
>>>
>>> --
>>> 2.21.0.windows.1
>>
>>
>> 
> 


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

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

Re: [edk2-devel] [PATCH v2] Platform/Intel: Dynamic NUMBER_OF_PROCESSORS in build.

[Bob Feng]

Reviewed-by: Bob Feng 


-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Chiu, 
Chasel
Sent: Thursday, June 13, 2019 4:32 PM
To: devel@edk2.groups.io
Cc: Kubacki, Michael A ; Desimone, Nathaniel L 
; Gao, Liming ; Feng, Bob 
C 
Subject: [edk2-devel] [PATCH v2] Platform/Intel: Dynamic NUMBER_OF_PROCESSORS 
in build.

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

To improve build performance by default the maximum processors should be used 
for building.
NUMBER_OF_PROCESSORS in build.cfg is set to 0 so BaseTools can utilize maximum 
processors for build.

Test: tried NUMBER_OF_PROCESSORS 0 and 1 cases and
  confirmed the build time is half with 0 case.

Cc: Michael Kubacki 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Chasel Chiu 
---
 Platform/Intel/build.cfg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/Intel/build.cfg b/Platform/Intel/build.cfg index 
6c23e5eabc..fc6e4fe824 100644
--- a/Platform/Intel/build.cfg
+++ b/Platform/Intel/build.cfg
@@ -46,7 +46,7 @@ FSP_TEST_RELEASE = FALSE  SECURE_BOOT_ENABLE = FALSE  
REBUILD_MODE =  BUILD_ROM_ONLY = -NUMBER_OF_PROCESSORS = 1
+NUMBER_OF_PROCESSORS = 0
 
 
 [PLATFORMS]
--
2.13.3.windows.1





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

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

[edk2-devel] [PATCH v2 11/10] OvmfPkg/Csm/LegacyBiosDxe: Fix Legacy16GetTableAddress call for E820 data

[David Woodhouse]

The DX register is supposed to contain the required alignment for the
allocation. It was zero, and SeaBIOS doesn't (well, didn't) cope well
with that. Set it appropriately.

Also set BX to indicate the regions it's OK to allocate in too. That
wasn't being initialised and was just using whatever the previous user
of the structure had left there.

Finally, actually return an error if the allocation fails. Instead of
going all the way through into the CSM and just letting it have a bogus
pointer to the E820 data.

Signed-off-by: David Woodhouse 
Reviewed-by: Hao A Wu 
---
 OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c 
b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
index 211750c012..cd4cd24f42 100644
--- a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
+++ b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
@@ -928,7 +928,9 @@ GenericLegacyBoot (
   if (CopySize > Private->Legacy16Table->E820Length) {
 ZeroMem (, sizeof (EFI_IA32_REGISTER_SET));
 Regs.X.AX = Legacy16GetTableAddress;
+Regs.X.BX = (UINT16) 0x0; // Any region
 Regs.X.CX = (UINT16) CopySize;
+Regs.X.DX = (UINT16) 0x4; // Alignment
 Private->LegacyBios.FarCall86 (
   >LegacyBios,
   Private->Legacy16Table->Compatibility16CallSegment,
@@ -942,6 +944,7 @@ GenericLegacyBoot (
 Private->Legacy16Table->E820Length  = (UINT32) CopySize;
 if (Regs.X.AX != 0) {
   DEBUG ((EFI_D_ERROR, "Legacy16 E820 length insufficient\n"));
+  return EFI_OUT_OF_RESOURCES;
 } else {
   CopyMem (
 (VOID *)(UINTN) Private->Legacy16Table->E820Pointer,
-- 
2.21.0


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

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

Re: [edk2-devel] [PATCH 11/10] OvmfPkg/Csm/LegacyBiosDxe: Correct Legacy16GetTableAddress call for E820 data

[David Woodhouse]

On Thu, 2019-06-13 at 06:28 +, Wu, Hao A wrote:
> Hello Ray,
> 
> Do you have comment on this?
> 
> Some inline comments below:
> 
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > David Woodhouse
> > Sent: Thursday, June 13, 2019 5:43 AM
> > To: Wu, Hao A
> > Cc: devel@edk2.groups.io; Ni, Ray; Justen, Jordan L; Laszlo Ersek; Ard
> > Biesheuvel
> > Subject: [edk2-devel] [PATCH 11/10] OvmfPkg/Csm/LegacyBiosDxe: Correct
> > Legacy16GetTableAddress call for E820 data
> > 
> > The DX register is supposed to contain the required alignment for the
> > allocation. It was zero, and SeaBIOS doesn't (well, didn't) cope well
> > with that. Set it appropriately, and set BX to indicate the regions
> > it's OK to allocate in too. That was already OK but let's make sure
> > it's initialised properly and not just working by chance.
> > 
> > Also actually return an error if the allocation fails. Instead of going
> > all the way through into the CSM and just letting it have a bogus
> > pointer to the E82o data.
> > 
> > Signed-off-by: David Woodhouse 
> > ---
> > I made SeaBIOS cope with the zero too:
> > https://mail.coreboot.org/hyperkitty/list/seab...@seabios.org/thread/4PH
> > W3O3Y3HJFENODFV5INBGDLZMXA5KE/
> > 
> >  OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c | 3 +++
> 
> 
> Not sure if it is the issue of my mail client, the new lines added are
> with LF line ending on my local machine after applying the patch.

Hm, that's normal, isn't it?

We still haven't fixed the repository to store LF line endings
internally and then let all the tools automatically do the right thing
by checking out to LF or CRLF as appropriate for the system you're
checking out on.

I vaguely recall that Laszlo has some scripts which mangle an email and
make it apply with CRLF? But only vaguely... which is why I asked for a
git tree instead of trying to run the gauntlet of trying to apply
patches 1-10 of your series myself.

I've pushed v2 with the E82o typo fixed, and using BX==0, to 
http://git.infradead.org/users/dwmw2/edk2.git/shortlog/refs/heads/csm
git://http://git.infradead.org/users/dwmw2/edk2.git csm

I'll try sending that with git-send-email directly rather than with via
my mailer, but IIRC that doesn't make any difference. CRLF conversions
are baked into every level — even SMTP converts to send CRLF on the
wire and often back again at the receive side. 


> 
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> > b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> > index 211750c012..e7766eb2b1 100644
> > --- a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> > +++ b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> > @@ -928,7 +928,9 @@ GenericLegacyBoot (
> >if (CopySize > Private->Legacy16Table->E820Length) {
> >  ZeroMem (, sizeof (EFI_IA32_REGISTER_SET));
> >  Regs.X.AX = Legacy16GetTableAddress;
> > +Regs.X.BX = (UINT16) 0x3; // Region
> 
> 
> According to the spec:
> 
> '''
> BX = Allocation region
> 00 = Allocate from either 0xE or 0xF 64 KB blocks.
> Bit 0 = 1 Allocate from 0xF 64 KB block
> Bit 1 = 1 Allocate from 0xE 64 KB block
> '''
> 
> I think the value 0 for BX is fine which indicates the allocation can
> happen in either ranges. Not sure if setting BX to 0x11 is a valid
> operation.

Note, I may have lied in my reply to Jordan when I said that 0x11 is
what was already happening. The way SeaBIOS copes with zero is by
setting it to 3... *before* the debug print showing what it was set to.

> With the above comments handled:
> Reviewed-by: Hao A Wu 

Thanks.


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

View/Reply Online (#42349): https://edk2.groups.io/g/devel/message/42349
Mute This Topic: https://groups.io/mt/32045939/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] Platform/Intel: Dynamic NUMBER_OF_PROCESSORS in build.

[Chiu, Chasel]

Thanks Bob! I was not aware that BaseTools already handled this.
I just verified and it works so I will update code review which will only touch 
build.cfg.

Thanks!
Chasel


> -Original Message-
> From: Feng, Bob C
> Sent: Thursday, June 13, 2019 3:39 PM
> To: devel@edk2.groups.io; Chiu, Chasel 
> Cc: Kubacki, Michael A ; Desimone, Nathaniel L
> ; Gao, Liming 
> Subject: RE: [edk2-devel] [PATCH] Platform/Intel: Dynamic
> NUMBER_OF_PROCESSORS in build.
> 
> Hi Chasel,
> 
> Patch looks good.
> 
> For the process number, build.py does the same thing as this patch. If pass 
> -n 0 to
> build.py, build.py will set the processor number to 
> multiprocessing.cpu_count()
> 
> Thanks,
> Bob
> 
> 
> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Chiu,
> Chasel
> Sent: Thursday, June 13, 2019 2:15 PM
> To: devel@edk2.groups.io
> Cc: Kubacki, Michael A ; Desimone, Nathaniel L
> ; Gao, Liming 
> Subject: [edk2-devel] [PATCH] Platform/Intel: Dynamic
> NUMBER_OF_PROCESSORS in build.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1913
> 
> To improve build performance by default the maximum processors should be
> used for building.
> To support this, NUMBER_OF_PROCESSORS in build.cfg has new definition:
>   0 = AUTO. Maximum of processors will be used.
>   non-zero = limit or force the number of processors.
> 
> Test: tried several NUMBER_OF_PROCESSORS settings and
>   the build parameter can be updated accordingly
>   also builds successfully.
> 
> Cc: Michael Kubacki 
> Cc: Nate DeSimone 
> Cc: Liming Gao 
> Signed-off-by: Chasel Chiu 
> ---
>  Platform/Intel/build.cfg | 2 +-
>  Platform/Intel/build_bios.py | 8 +++-
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/Platform/Intel/build.cfg b/Platform/Intel/build.cfg index
> 6c23e5eabc..fc6e4fe824 100644
> --- a/Platform/Intel/build.cfg
> +++ b/Platform/Intel/build.cfg
> @@ -46,7 +46,7 @@ FSP_TEST_RELEASE = FALSE  SECURE_BOOT_ENABLE =
> FALSE  REBUILD_MODE =  BUILD_ROM_ONLY = -NUMBER_OF_PROCESSORS =
> 1
> +NUMBER_OF_PROCESSORS = 0
> 
> 
>  [PLATFORMS]
> diff --git a/Platform/Intel/build_bios.py b/Platform/Intel/build_bios.py index
> 09eceddeff..864511ac4d 100644
> --- a/Platform/Intel/build_bios.py
> +++ b/Platform/Intel/build_bios.py
> @@ -21,6 +21,7 @@ import shutil
>  import argparse
>  import traceback
>  import subprocess
> +import multiprocessing
>  from importlib import import_module
> 
>  try:
> @@ -345,7 +346,12 @@ def build(config):
>  print(" BUILD_ROM_ONLY = ", config.get("BUILD_ROM_ONLY"))
>  print("==")
> 
> -command = ["build", "-n", config["NUMBER_OF_PROCESSORS"]]
> +NumberOfProcessors = config["NUMBER_OF_PROCESSORS"]
> +if config["NUMBER_OF_PROCESSORS"] == "0":
> +# 0 means AUTO, maximum number of processors will be set
> +NumberOfProcessors = str(multiprocessing.cpu_count())
> +print ("Number of processors set to " + NumberOfProcessors)
> +command = ["build", "-n", NumberOfProcessors]
> 
>  if config["REBUILD_MODE"] and config["REBUILD_MODE"] != "":
>  command.append(config["REBUILD_MODE"])
> --
> 2.13.3.windows.1
> 
> 
> 


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

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

[edk2-devel] [PATCH v2] Platform/Intel: Dynamic NUMBER_OF_PROCESSORS in build.

[Chiu, Chasel]

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

To improve build performance by default the maximum
processors should be used for building.
NUMBER_OF_PROCESSORS in build.cfg is set to 0 so
BaseTools can utilize maximum processors for build.

Test: tried NUMBER_OF_PROCESSORS 0 and 1 cases and
  confirmed the build time is half with 0 case.

Cc: Michael Kubacki 
Cc: Nate DeSimone 
Cc: Liming Gao 
Cc: Bob Feng 
Signed-off-by: Chasel Chiu 
---
 Platform/Intel/build.cfg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/Intel/build.cfg b/Platform/Intel/build.cfg
index 6c23e5eabc..fc6e4fe824 100644
--- a/Platform/Intel/build.cfg
+++ b/Platform/Intel/build.cfg
@@ -46,7 +46,7 @@ FSP_TEST_RELEASE = FALSE
 SECURE_BOOT_ENABLE = FALSE
 REBUILD_MODE =
 BUILD_ROM_ONLY =
-NUMBER_OF_PROCESSORS = 1
+NUMBER_OF_PROCESSORS = 0
 
 
 [PLATFORMS]
-- 
2.13.3.windows.1


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

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

[edk2-devel] [PATCH] Platform/Intel: Dynamic NUMBER_OF_PROCESSORS in build.

[Chiu, Chasel]

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

To improve build performance by default the maximum
processors should be used for building.
NUMBER_OF_PROCESSORS in build.cfg is set to 0 so
BaseTools can utilize maximum processors for build.

Test: tried NUMBER_OF_PROCESSORS 0 and 1 cases and
  confirmed the build time is half with 0 case.

Cc: Michael Kubacki 
Cc: Nate DeSimone 
Cc: Liming Gao 
Signed-off-by: Chasel Chiu 
---
 Platform/Intel/build.cfg | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/Intel/build.cfg b/Platform/Intel/build.cfg
index 6c23e5eabc..fc6e4fe824 100644
--- a/Platform/Intel/build.cfg
+++ b/Platform/Intel/build.cfg
@@ -46,7 +46,7 @@ FSP_TEST_RELEASE = FALSE
 SECURE_BOOT_ENABLE = FALSE
 REBUILD_MODE =
 BUILD_ROM_ONLY =
-NUMBER_OF_PROCESSORS = 1
+NUMBER_OF_PROCESSORS = 0
 
 
 [PLATFORMS]
-- 
2.13.3.windows.1


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

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

Re: [edk2-devel] [PATCH] MdeModulePkg: Add lacking instances for build only

[Wu, Hao A]

> -Original Message-
> From: Gao, Zhichao
> Sent: Wednesday, June 12, 2019 10:40 AM
> To: devel@edk2.groups.io
> Cc: Bret Barkelew; Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming;
> Sean Brogan; Michael Turner
> Subject: [PATCH] MdeModulePkg: Add lacking instances for build only

There are 224 INF files in MdeModulePkg, and now there are 224 occurrences
when searching '^  MdeModulePkg.+\.inf' in MdeModulePkg.dsc. The number
matches.

Also, seems to me ARM & AARCH64 also build fine.

Then, with a similar suggestion at:
https://edk2.groups.io/g/devel/topic/32037312#42319

handled:
Reviewed-by: Hao A Wu 

Best Regards,
Hao Wu


> 
> From: Bret Barkelew 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1857
> 
> Add the lacking instances to the [Components] of dsc file
> for build only.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Bret Barkelew 
> Signed-off-by: Zhichao Gao 
> ---
>  MdeModulePkg/MdeModulePkg.dsc | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/MdeModulePkg/MdeModulePkg.dsc
> b/MdeModulePkg/MdeModulePkg.dsc
> index 995fd805e1..f32adc3839 100644
> --- a/MdeModulePkg/MdeModulePkg.dsc
> +++ b/MdeModulePkg/MdeModulePkg.dsc
> @@ -204,6 +204,22 @@
>MdeModulePkg/Application/DumpDynPcd/DumpDynPcd.inf
>MdeModulePkg/Application/MemoryProfileInfo/MemoryProfileInfo.inf
> 
> +  MdeModulePkg/Library/UefiSortLib/UefiSortLib.inf
> +  MdeModulePkg/Logo/Logo.inf
> +  MdeModulePkg/Logo/LogoDxe.inf
> +  MdeModulePkg/Library/BaseSortLib/BaseSortLib.inf
> +
> MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenance
> ManagerUiLib.inf
> +  MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.inf
> +  MdeModulePkg/Library/CustomizedDisplayLib/CustomizedDisplayLib.inf
> +  MdeModulePkg/Library/DebugAgentLibNull/DebugAgentLibNull.inf
> +  MdeModulePkg/Library/DeviceManagerUiLib/DeviceManagerUiLib.inf
> +  MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.inf
> +  MdeModulePkg/Library/PciHostBridgeLibNull/PciHostBridgeLibNull.inf
> +
> MdeModulePkg/Library/PiSmmCoreSmmServicesTableLib/PiSmmCoreSmmS
> ervicesTableLib.inf
> +  MdeModulePkg/Library/UefiHiiServicesLib/UefiHiiServicesLib.inf
> +  MdeModulePkg/Library/BaseHobLibNull/BaseHobLibNull.inf
> +
> MdeModulePkg/Library/BaseMemoryAllocationLibNull/BaseMemoryAllocati
> onLibNull.inf
> +
>MdeModulePkg/Bus/Pci/PciHostBridgeDxe/PciHostBridgeDxe.inf
>MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
>MdeModulePkg/Bus/Pci/PciBusDxe/PciBusDxe.inf
> --
> 2.21.0.windows.1


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

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

Re: [edk2-devel] [PATCH] Platform/Intel: Dynamic NUMBER_OF_PROCESSORS in build.

[Nate DeSimone]

Reviewed-by: Nate DeSimone 

On 6/12/19, 11:17 PM, "Chiu, Chasel"  wrote:

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

To improve build performance by default the maximum
processors should be used for building.
To support this, NUMBER_OF_PROCESSORS in build.cfg has
new definition:
  0 = AUTO. Maximum of processors will be used.
  non-zero = limit or force the number of processors.

Test: tried several NUMBER_OF_PROCESSORS settings and
  the build parameter can be updated accordingly
  also builds successfully.

Cc: Michael Kubacki 
Cc: Nate DeSimone 
Cc: Liming Gao 
Signed-off-by: Chasel Chiu 
---
 Platform/Intel/build.cfg | 2 +-
 Platform/Intel/build_bios.py | 8 +++-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/Platform/Intel/build.cfg b/Platform/Intel/build.cfg
index 6c23e5eabc..fc6e4fe824 100644
--- a/Platform/Intel/build.cfg
+++ b/Platform/Intel/build.cfg
@@ -46,7 +46,7 @@ FSP_TEST_RELEASE = FALSE
 SECURE_BOOT_ENABLE = FALSE
 REBUILD_MODE =
 BUILD_ROM_ONLY =
-NUMBER_OF_PROCESSORS = 1
+NUMBER_OF_PROCESSORS = 0
 
 
 [PLATFORMS]
diff --git a/Platform/Intel/build_bios.py b/Platform/Intel/build_bios.py
index 09eceddeff..864511ac4d 100644
--- a/Platform/Intel/build_bios.py
+++ b/Platform/Intel/build_bios.py
@@ -21,6 +21,7 @@ import shutil
 import argparse
 import traceback
 import subprocess
+import multiprocessing
 from importlib import import_module
 
 try:
@@ -345,7 +346,12 @@ def build(config):
 print(" BUILD_ROM_ONLY = ", config.get("BUILD_ROM_ONLY"))
 print("==")
 
-command = ["build", "-n", config["NUMBER_OF_PROCESSORS"]]
+NumberOfProcessors = config["NUMBER_OF_PROCESSORS"]
+if config["NUMBER_OF_PROCESSORS"] == "0":
+# 0 means AUTO, maximum number of processors will be set
+NumberOfProcessors = str(multiprocessing.cpu_count())
+print ("Number of processors set to " + NumberOfProcessors)
+command = ["build", "-n", NumberOfProcessors]
 
 if config["REBUILD_MODE"] and config["REBUILD_MODE"] != "":
 command.append(config["REBUILD_MODE"])
-- 
2.13.3.windows.1




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

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

Re: [edk2-devel] ExtScsiPassThru support for Logical SCSI devices

[Ravi Kumar Siadri]

Hi Wu Hao A,

Thanks for the response.
I have added my comments in line.

Thanks,
Ravi Kumar




On Wed, Jun 12, 2019 at 1:26 PM Wu, Hao A  wrote:

> Hello Ravi Kumar,
>
>
>
> Inline comments below:
>
>
>
> *From:* devel@edk2.groups.io [mailto:devel@edk2.groups.io] *On Behalf Of *Ravi
> Kumar Siadri
> *Sent:* Wednesday, June 12, 2019 12:01 PM
> *To:* devel@edk2.groups.io
> *Subject:* Re: [edk2-devel] ExtScsiPassThru support for Logical SCSI
> devices
>
>
>
> Hi,
>
>
>
> Can someone help me in clarifying my queries ??
>
>
>
> Thanks,
>
> Ravi Kumar
>
>
>
> On Mon, Jun 10, 2019 at 3:55 PM Ravi Kumar Siadri <
> siadriravikumaru...@gmail.com> wrote:
>
> Hi all,
>
>
>
> I have couple of queries regarding the
> *EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL* attribute support in
> *EFI_EXT_SCSI_PASS_THRU_PROTOCOL*.
>
>
>
> *1. *
>
> *The Attributes field of the EFI_EXT_SCSI_PASS_THRU_PROTOCOL interface
> tells if the interface is for physical SCSI devices or logical SCSI
> devices. Drivers for non-RAID SCSI controllers will set both the
> EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL, and the
> EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL bits.*
>
>
>
> If the Drivers is for non-RAID SCSI controllers why to set the
> EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL bit. Will there be any case that
> non-RAID SCSI controllers have Logical devices connected to it ??
>
>
>
> Per my understanding, every partition on a physical HW device will be
> treated
>
> as a logical device by the firmware.
>
>
>
> So for non-RAID case, both bits will be set for the PassThru protocol
> produced
>
> for the physical device.
>
>

> Ravi:
>
> As far as i know RAID controller will treat a partition/drive as logical
> device only if has RIS (raid information sector) information in it.  So i
> don't think partition is treated as logical device.
>
>
>
>
>
> *2. *
>
> *Drivers for RAID controllers that allow access to the physical devices
> and logical devices will produce two EFI_EXT_SCSI_PASS_THRU_PROTOCOL
> interfaces:  *
>
> *One with the just the EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL bit set
> and another with just the EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL bit
> set. One interface can be used to access the physical devices attached to
> the RAID controller, and the other can be used to access the logical
> devices attached to the RAID controller for its current configuration.*
>
>
>
> Any background why EFI_EXT_SCSI_PASS_THRU_PROTOCOL needed 2 instances ?
> why can't we install attributes EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL
> and EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL on same Instance ??
>
> How User locates the Instance with
> EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL bit set and Instance with
> EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL bit set. ??
>
>
>
> UEFI spec allows RAID drivers to only produce one PassThru protocol
> interface
>
> with just the XXX_PASS_THRU_LOGICAL bit set when the RAID controller
> select to
>
> not allow direct access to the underlying physical devices.
>
>
  Ravi:

> If the RAID Driver supports only Logical or Physical Devices then it is
> fine creating only 1 instance and not allowing other devices which Bit is
> not set. (either  EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_LOGICAL or
> EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL).
>
> But if the RAID driver supports both the Logical and Physical Devices,
> then we have to need 2 instances as per spec. This is going to be an over
> head, while locating instances by the user who want to send commands to
> Target devices connected to RAID controller.
>
> Since each EFI_EXT_SCSI_PASS_THRU_PROTOCOL instance must have an
> associated device path. Only 1 instance can be installed on that particular
> RAID controller handle since the GUID is same for both the instances.
>
> If our intention is to filter the Logical and Physical devices then, we
> can add a parameter in GetNextTartget() function to inform RAID Driver
> which type of targets the user is looking for. (Physical or Logical).
>
>  Right ??
>
>
>
> Thanks,
>
> Ravi Kumar
>
>
>
> 
>

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

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

Re: [edk2-devel] UEFI SCT Build Broken

[Eric Jin]

Ashish,

Supreeth already sent out the patch yesterday, we will let you know if the 
patches are committed to repo. Thanks.

Best Regards
Eric

From: Jin, Eric 
Sent: Wednesday, June 12, 2019 5:19 PM
To: Ashish Singhal ; Supreeth Venkatesh 
; devel@edk2.groups.io
Cc: Jin, Eric 
Subject: RE: UEFI SCT Build Broken

Hi Ashish,

Thank for raising this issue.
UEFI SCT build pass with edk2-stable201903, and fail on edk2-stable201905, 
because edk2 drop the IPF support (4e1daa60f5372c22a11503961061ffa569eaf873).
UEFI SCT can remove IPF support too. I can follow it tomorrow. Thanks.


Best Regards
Eric

From: Ashish Singhal mailto:ashishsin...@nvidia.com>>
Sent: Wednesday, June 12, 2019 4:26 AM
To: Supreeth Venkatesh 
mailto:supreeth.venkat...@arm.com>>; Jin, Eric 
mailto:eric@intel.com>>; 
devel@edk2.groups.io
Subject: Re: UEFI SCT Build Broken

Supreeth,

It is broken against both edk2 tip as well as latest edk2 tag edk2-stable201903.

I have filed a bugzilla 
bug for the same.

Thanks
Ashish

From: Supreeth Venkatesh 
mailto:supreeth.venkat...@arm.com>>
Sent: Tuesday, June 11, 2019 1:36 PM
To: Ashish Singhal; Eric Jin; devel@edk2.groups.io
Subject: RE: UEFI SCT Build Broken


Ashish,



We are working towards fixing the issue for the next SCT tag corresponding to 
edk2 tag.

Can you please let us know whether you are referring to edk2 tip or which edk2 
tag (edk2-stable201903)?



If possible, could you log a bug entry in bugzillafor edk2-test/SCT component?



Thanks,

Supreeth



From: Ashish Singhal mailto:ashishsin...@nvidia.com>>
Sent: Tuesday, June 11, 2019 12:18 PM
To: Supreeth Venkatesh 
mailto:supreeth.venkat...@arm.com>>; Eric Jin 
mailto:eric@intel.com>>; 
devel@edk2.groups.io
Subject: UEFI SCT Build Broken



Hello Eric/Supreeth,



With the latest edk2 tag, UEFI SCT tip build is broken. Seems like it needs 
Guid/SalSystemTable.h header file which is not in edk2 tree any more. Is a fix 
for this already being looked at?



Thanks

Ashish



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.


IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

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

View/Reply Online (#42342): https://edk2.groups.io/g/devel/message/42342
Mute This Topic: https://groups.io/mt/32030281/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 v1 5/5] EasLib: Remove files required for building Ipf

[Eric Jin]

Hello Supreeth,

The serial patch 1- 5 is good to me.
Could you add one patch to remove source and header files required for building 
library from SctPkg/Library/SctLib/SctLib.inf ?

[sources.ipf]
  Ipf/SctLibPlat.h
  Ipf/initplat.c
  Ipf/salpal.c
  Ipf/libsalpal.h
  Math.c

Best Regards
Eric

-Original Message-
From: Supreeth Venkatesh  
Sent: Thursday, June 13, 2019 4:36 AM
To: devel@edk2.groups.io
Cc: Supreeth Venkatesh ; Jin, Eric 

Subject: [edk2-test][PATCH v1 5/5] EasLib: Remove files required for building 
Ipf

Remove all files required for building Ipf Eas library as edk2
(edk2-stable201905) has removed IPF support.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Supreeth Venkatesh 
---
 .../Framework/ENTS/EasLib/Ipf/EntsLibPlat.h   |  55 --
 .../SCT/Framework/ENTS/EasLib/Ipf/InitPlat.c  |  54 --  
.../SCT/Framework/ENTS/EasLib/Ipf/LibSalPal.h | 182 -
 .../SCT/Framework/ENTS/EasLib/Ipf/PalApi.h| 137 
 .../SCT/Framework/ENTS/EasLib/Ipf/SalApi.h| 728 --
 .../SCT/Framework/ENTS/EasLib/Ipf/SalPal.c| 369 -
 6 files changed, 1525 deletions(-)
 delete mode 100644 
uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/EntsLibPlat.h
 delete mode 100644 
uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/InitPlat.c
 delete mode 100644 
uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/LibSalPal.h
 delete mode 100644 
uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/PalApi.h
 delete mode 100644 
uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/SalApi.h
 delete mode 100644 
uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/SalPal.c

diff --git 
a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/EntsLibPlat.h
 
b/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/EntsLibPlat.h
deleted file mode 100644
index f0060614..
--- 
a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/EntsLibPlat.h
+++ /dev/null
@@ -1,55 +0,0 @@
-/** @file
-
-  Copyright 2006 - 2010 Unified EFI, Inc.
-  Copyright (c) 2010, Intel Corporation. All rights reserved.
-
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  which accompanies this distribution.  The full text of the license may be 
found at
-  http://opensource.org/licenses/bsd-license.php
-
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-/*++
-
-Module Name:
-
-  EntsLibPlat.h
-
-Abstract:
-
-  IPF specific defines
-
---*/
-
-#ifndef _EFI_LIB_PLAT_H
-#define _EFI_LIB_PLAT_H
-
-#define MIN_ALIGNMENT_SIZE  8
-
-VOID
-EntsInitializeLibPlatform (
-  IN EFI_HANDLE   ImageHandle,
-  IN EFI_SYSTEM_TABLE *SystemTable
-  )
-/*++
-
-Routine Description:
-
-  Initialize platform.
-
-Arguments:
-
-  ImageHandle   - The image handle.
-  SystemTable   - The system table.
-
-Returns:
-
-  None.
-
---*/
-;
-
-#endif
diff --git 
a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/InitPlat.c 
b/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/InitPlat.c
deleted file mode 100644
index fd62..
--- 
a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/InitPlat.c
+++ /dev/null
@@ -1,54 +0,0 @@
-/** @file
-
-  Copyright 2006 - 2010 Unified EFI, Inc.
-  Copyright (c) 2010, Intel Corporation. All rights reserved.
-
-  This program and the accompanying materials
-  are licensed and made available under the terms and conditions of the BSD 
License
-  which accompanies this distribution.  The full text of the license may be 
found at
-  http://opensource.org/licenses/bsd-license.php
-
-  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
-  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
-
-**/
-/*++
-
-Module Name:
-
-  InitPlat.c
-
-Abstract:
-
-  Functions to make SAL and PAL proc calls
-
---*/
-
-#include "Efi.h"
-#include "EntsLibPlat.h"
-#include "LibSalPal.h"
-
-VOID
-EntsInitializeLibPlatform (
-  IN EFI_HANDLE   ImageHandle,
-  IN EFI_SYSTEM_TABLE *SystemTable
-  )
-/*++
-
-Routine Description:
-
-  Initialize platform.
-
-Arguments:
-
-  ImageHandle   - The image handle.
-  SystemTable   - The system table.
-
-Returns:
-
-  None.
-
---*/
-{
-  LibInitSalAndPalProc ();
-}
diff --git 
a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/LibSalPal.h 
b/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/LibSalPal.h
deleted file mode 100644
index 78d96d59..
--- 
a/uefi-sct/SctPkg/TestInfrastructure/SCT/Framework/ENTS/EasLib/Ipf/LibSalPal.h
+++ /dev/null
@@ -1,182 +0,0 @@
-/** @file
-
-  Copyright 2006 - 2010 Unified EFI, Inc.
-  Copyright (c) 2010, Intel Corporation. All rights reserved.
-
-  This 

Re: [edk2-devel] [PATCH] SourceLevelDebugPkg: Add lacking instances for build only

[Wu, Hao A]

> -Original Message-
> From: Gao, Zhichao
> Sent: Wednesday, June 12, 2019 10:40 AM
> To: devel@edk2.groups.io
> Cc: Bret Barkelew; Wu, Hao A; Gao, Liming; Sean Brogan; Michael Turner; Leif
> Lindholm; Gao, Zhichao
> Subject: [PATCH] SourceLevelDebugPkg: Add lacking instances for build only


With a similar suggestion at:
https://edk2.groups.io/g/devel/topic/32037312#42319

handled:
Reviewed-by: Hao A Wu 

Best Regards,
Hao Wu


> 
> From: Bret Barkelew 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1902
> 
> Add the lacking instance to the [Components] of dsc file
> for build only.
> 
> Cc: Hao A Wu 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Bret Barkelew 
> Cc: Leif Lindholm 
> Signed-off-by: Zhichao gao 
> ---
>  SourceLevelDebugPkg/SourceLevelDebugPkg.dsc | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/SourceLevelDebugPkg/SourceLevelDebugPkg.dsc
> b/SourceLevelDebugPkg/SourceLevelDebugPkg.dsc
> index 8be6781296..a1a1b81d03 100644
> --- a/SourceLevelDebugPkg/SourceLevelDebugPkg.dsc
> +++ b/SourceLevelDebugPkg/SourceLevelDebugPkg.dsc
> @@ -93,6 +93,8 @@
> 
> ##
> #
> 
>  [Components.common]
> +
> SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugCommu
> nicationLibUsb3Dxe.inf
> +
> SourceLevelDebugPkg/Library/DebugCommunicationLibUsb3/DebugCommu
> nicationLibUsb3Pei.inf
> 
> SourceLevelDebugPkg/Library/DebugCommunicationLibSerialPort/DebugCo
> mmunicationLibSerialPort.inf
> 
> SourceLevelDebugPkg/Library/DebugCommunicationLibUsb/DebugCommun
> icationLibUsb.inf
> 
> SourceLevelDebugPkg/Library/PeCoffExtraActionLibDebug/PeCoffExtraActio
> nLibDebug.inf
> --
> 2.21.0.windows.1


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

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

Re: [edk2-devel] [PATCH 11/10] OvmfPkg/Csm/LegacyBiosDxe: Correct Legacy16GetTableAddress call for E820 data

[David Woodhouse]

On Thu, 2019-06-13 at 00:40 -0700, Jordan Justen wrote:
> On 2019-06-12 23:28:12, Wu, Hao A wrote:
> > 
> > > -Original Message-
> > > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > > David Woodhouse
> > > Sent: Thursday, June 13, 2019 5:43 AM
> > > 
> > > The DX register is supposed to contain the required alignment for the
> > > allocation. It was zero, and SeaBIOS doesn't (well, didn't) cope well
> > > with that. Set it appropriately, and set BX to indicate the regions
> > > it's OK to allocate in too. That was already OK but let's make sure
> > > it's initialised properly and not just working by chance.
> > > 
> > > Also actually return an error if the allocation fails. Instead of going
> > > all the way through into the CSM and just letting it have a bogus
> > > pointer to the E82o data.
> 
> 'E82o' => 'E820'

Yeah, spotted that just after sending and it's in my tree for v2 if
there is one. Thanks.

> > > 
> > > diff --git a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> > > b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> > > index 211750c012..e7766eb2b1 100644
> > > --- a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> > > +++ b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> > > @@ -928,7 +928,9 @@ GenericLegacyBoot (
> > >if (CopySize > Private->Legacy16Table->E820Length) {
> > >  ZeroMem (, sizeof (EFI_IA32_REGISTER_SET));
> > >  Regs.X.AX = Legacy16GetTableAddress;
> > > +Regs.X.BX = (UINT16) 0x3; // Region
> > 
> > 
> > According to the spec:
> > 
> > '''
> > BX = Allocation region
> > 00 = Allocate from either 0xE or 0xF 64 KB blocks.
> > Bit 0 = 1 Allocate from 0xF 64 KB block
> > Bit 1 = 1 Allocate from 0xE 64 KB block
> > '''
> > 
> > I think the value 0 for BX is fine which indicates the allocation can
> > happen in either ranges. Not sure if setting BX to 0x11 is a valid
> > operation.
> 
> Based on the spec you quote, it does seem reasonable to expect that a
> CSM should treat 0 the same as 3, but it is possible that some CSM out
> there made a silly choice and would blow up on 3.

I think it's more likely that a CSM would blow up on zero (no bits set
→ no regions to allocate from) than 3. In fact, I just had to double-
check that SeaBIOS does the right thing for BX==0. (It does.)

In practice, Legacy16GetTableAddress only seems to be called with BX==1
or 3, and I haven't seen any calls with 0.

The setting of Regs.X.BX in this patch has no observable effect — it
was *already* 3 before this call, because whoever used it last happened
to leave it like that. Setting it explicitly was just a cleanup to make
sure we didn't depend on that any more.

> Since David mentioned that bx==0 works ok with SeaBIOS CSM, then maybe
> we should just drop this change? Or, we can add a comment that bx==0
> means either the e000 or f000 block?

SeaBIOS as CSM will with with *DX* == 0, after this goes in:
https://mail.coreboot.org/hyperkitty/list/seab...@seabios.org/thread/4PHW3O3Y3HJFENODFV5INBGDLZMXA5KE/

It does look like it already works with BX==0. So I'm not entirely
averse to setting it explicitly to 0 instead, if you prefer. I just
wanted it to be set explicitly to *something*.

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

View/Reply Online (#42339): https://edk2.groups.io/g/devel/message/42339
Mute This Topic: https://groups.io/mt/32045939/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 V3 2/2] MdeModulePkg/BdsDxe: Use a pcd to control PlatformRecovery

[Gao, Zhichao]

> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, June 13, 2019 3:39 PM
> To: devel@edk2.groups.io; Gao, Zhichao 
> Cc: Wang, Jian J ; Ni, Ray ; Zeng,
> Star ; Gao, Liming ; Sean
> Brogan ; Michael Turner
> ; Bret Barkelew
> 
> Subject: RE: [edk2-devel] [PATCH V3 2/2] MdeModulePkg/BdsDxe: Use a pcd
> to control PlatformRecovery
> 
> One comment below:
> 
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > Gao, Zhichao
> > Sent: Tuesday, June 04, 2019 9:05 AM
> > To: devel@edk2.groups.io
> > Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean
> > Brogan; Michael Turner; Bret Barkelew
> > Subject: [edk2-devel] [PATCH V3 2/2] MdeModulePkg/BdsDxe: Use a pcd
> to
> > control PlatformRecovery
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1678
> >
> > Use the PcdPlatformRecoverySupport to control the function of platform
> > recovery in BDS.
> > First, set the variable's ("OsIndicationsSupported")
> > EFI_OS_INDICATIONS_START_PLATFORM_RECOVERY bit base on the pcd.
> > It would affect the variable "OsIndications".
> > While the platform does not support the platform recovery, it is
> > inappropriate to set a PlatformRecovery variable. So skip setting
> > the variable. But it should remain the behavior of booting from a
> > default file path (such as \EFI\BOOT\BOOTX64.EFI) to be compatible
> > with the previous version UEFI spec.
> >
> > Add memory check before build platform default boot option. If fail to
> > allocate memory for the defualt boot file path, put the system into
> > dead loop to indicate it is unable to boot.
> >
> > Cc: Jian J Wang 
> > Cc: Hao Wu 
> > Cc: Ray Ni 
> > Cc: Star Zeng 
> > Cc: Liming Gao 
> > Cc: Sean Brogan 
> > Cc: Michael Turner 
> > Cc: Bret Barkelew 
> > Signed-off-by: Zhichao Gao 
> > ---
> >  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf |  3 +-
> > MdeModulePkg/Universal/BdsDxe/BdsEntry.c | 71 +++-
> -
> > ---
> >  2 files changed, 47 insertions(+), 27 deletions(-)
> >
> > diff --git a/MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
> > b/MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
> > index 6913389d34..7f94ca17df 100644
> > --- a/MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
> > +++ b/MdeModulePkg/Universal/BdsDxe/BdsDxe.inf
> > @@ -5,7 +5,7 @@
> >  #  gEfiBdsArchProtocolGuid. After DxeCore finish dispatching, DxeCore
> > will invoke Entry  #  interface of protocol gEfiBdsArchProtocolGuid,
> > then BDS phase is entered.
> >  #
> > -#  Copyright (c) 2008 - 2018, Intel Corporation. All rights
> > reserved.
> > +#  Copyright (c) 2008 - 2019, Intel Corporation. All rights
> > +reserved.
> >  #  SPDX-License-Identifier: BSD-2-Clause-Patent  #  ## @@ -95,6 +95,7
> > @@
> >gEfiMdeModulePkgTokenSpaceGuid.PcdConInConnectOnDemand
> > ## CONSUMES
> >gEfiMdeModulePkgTokenSpaceGuid.PcdErrorCodeSetVariable  ##
> > SOMETIMES_CONSUMES
> >gEfiMdeModulePkgTokenSpaceGuid.PcdTestKeyUsed   ##
> > CONSUMES
> > +  gEfiMdeModulePkgTokenSpaceGuid.PcdPlatformRecoverySupport
> > ## CONSUMES
> >
> >  [Depex]
> >TRUE
> > diff --git a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> > b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> > index 9d312bd982..8c8a0b5236 100644
> > --- a/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> > +++ b/MdeModulePkg/Universal/BdsDxe/BdsEntry.c
> > @@ -5,7 +5,7 @@
> >After DxeCore finish DXE phase, gEfiBdsArchProtocolGuid->BdsEntry
> > will be invoked
> >to enter BDS phase.
> >
> > -Copyright (c) 2004 - 2018, Intel Corporation. All rights
> > reserved.
> > +Copyright (c) 2004 - 2019, Intel Corporation. All rights
> > +reserved.
> >  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
> >  (C) Copyright 2015 Hewlett-Packard Development Company, L.P.
> >  SPDX-License-Identifier: BSD-2-Clause-Patent @@ -546,10 +546,14 @@
> > BdsFormalizeOSIndicationVariable (
> >//
> >Status = EfiBootManagerGetBootManagerMenu ();
> >if (Status != EFI_NOT_FOUND) {
> > -OsIndicationSupport = EFI_OS_INDICATIONS_BOOT_TO_FW_UI |
> > EFI_OS_INDICATIONS_START_PLATFORM_RECOVERY;
> > +OsIndicationSupport = EFI_OS_INDICATIONS_BOOT_TO_FW_UI;
> >  EfiBootManagerFreeLoadOption ();
> >} else {
> > -OsIndicationSupport =
> > EFI_OS_INDICATIONS_START_PLATFORM_RECOVERY;
> > +OsIndicationSupport = 0;
> > +  }
> > +
> > +  if (PcdGetBool (PcdPlatformRecoverySupport)) {
> > +OsIndicationSupport |=
> > EFI_OS_INDICATIONS_START_PLATFORM_RECOVERY;
> >}
> >
> >Status = gRT->SetVariable (
> > @@ -662,6 +666,7 @@ BdsEntry (
> >BOOLEAN BootSuccess;
> >EFI_DEVICE_PATH_PROTOCOL*FilePath;
> >EFI_STATUS  BootManagerMenuStatus;
> > +  EFI_BOOT_MANAGER_LOAD_OPTIONPlatformDefaultBootOption;
> >
> >HotkeyTriggered = NULL;
> >Status  = EFI_SUCCESS;
> > @@ -763,14 +768,13 @@ BdsEntry (
> >//
> >InitializeLanguage (TRUE);
> >
> > -  //
> > 

Re: [edk2-devel] [PATCH v5 0/5] MdeModulePkg/CapsulePei: Optimize the CapsulePei

[Wu, Hao A]

> -Original Message-
> From: Gao, Zhichao
> Sent: Monday, June 10, 2019 1:21 PM
> To: devel@edk2.groups.io
> Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan;
> Michael Turner; Bret Barkelew; Leif Lindholm
> Subject: [PATCH v5 0/5] MdeModulePkg/CapsulePei: Optimize the
> CapsulePei
> 
> v1:
> Sperate the capsule check function from GetCapsuleDescriptors
> and name it to AreCapsulesStaged.
> Rename GetCapsuleDescriptors to GetScatterGatherHeadEntries.
> And optimize its to remove the duplicated code.
> 
> V2:
> Clarify the changes of the patch and descript in the commit
> message.
> 
> V3:
> Add the code change repo location in Mu and add description of
> the changes on it.
> Do not need to remain 2 byte for the null-terminate while using
> UnicodeValueToStringS.
> 
> V4:
> Separate the patch into 2 part. first part is changes from MU.
> Second part is the substantial change on it.
> 
> V5:
> Separate the substantial change in 2/2 base on the purpose.


With the comment from Leif handled, for the series:
Reviewed-by: Hao A Wu 

Best Regards,
Hao Wu


> 
> Cc: Jian J Wang 
> Cc: Hao A Wu 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Bret Barkelew 
> Cc: Leif Lindholm 
> 
> Bret Barkelew (1):
>   MdeModulePkg/CapsulePei: Optimize the CapsulePei
> 
> Zhichao Gao (4):
>   MdeMoudlePkg/CapsulePei: Fix coding style issue
>   MdeMoudlePkg/CapsulePei: Optimize AreCapsulesStaged
>   MdeMoudlePkg/CapsulePei: Optimize GetScatterGatherHeadEntries
>   MdeMoudlePkg/CapsulePei: No need to remain space for null-terminate
> 
>  MdeModulePkg/Universal/CapsulePei/Capsule.h   |   1 +
>  .../Universal/CapsulePei/CapsulePei.inf   |   1 +
>  .../Universal/CapsulePei/UefiCapsule.c| 356 +-
>  3 files changed, 190 insertions(+), 168 deletions(-)
> 
> --
> 2.21.0.windows.1


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

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

Re: [edk2-devel] [Patch V3] EmulatorPkg: don't display the cpu current speed

[Jordan Justen]

On 2019-06-11 22:42:13, Liu, Zhiguang wrote:
> Thanks for the comments.
> I will change the commit message in the next version.
> But I don't think this is a issue worth making a major change.
> Given that the change is consistent with NT32, will you agree with this 
> change?

Hmm. You are right that NT32 also does this. I don't agree enough to
give you a Reviewed-by, but if Andrew or Ray give a Reviewed-by, then
I'm ok for us to take the patch.

-Jordan

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

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

Re: [edk2-devel] [PATCH 11/10] OvmfPkg/Csm/LegacyBiosDxe: Correct Legacy16GetTableAddress call for E820 data

[Jordan Justen]

On 2019-06-12 23:28:12, Wu, Hao A wrote:
> 
> > -Original Message-
> > From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> > David Woodhouse
> > Sent: Thursday, June 13, 2019 5:43 AM
> > 
> > The DX register is supposed to contain the required alignment for the
> > allocation. It was zero, and SeaBIOS doesn't (well, didn't) cope well
> > with that. Set it appropriately, and set BX to indicate the regions
> > it's OK to allocate in too. That was already OK but let's make sure
> > it's initialised properly and not just working by chance.
> > 
> > Also actually return an error if the allocation fails. Instead of going
> > all the way through into the CSM and just letting it have a bogus
> > pointer to the E82o data.

'E82o' => 'E820'

> > 
> > diff --git a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> > b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> > index 211750c012..e7766eb2b1 100644
> > --- a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> > +++ b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> > @@ -928,7 +928,9 @@ GenericLegacyBoot (
> >if (CopySize > Private->Legacy16Table->E820Length) {
> >  ZeroMem (, sizeof (EFI_IA32_REGISTER_SET));
> >  Regs.X.AX = Legacy16GetTableAddress;
> > +Regs.X.BX = (UINT16) 0x3; // Region
> 
> 
> According to the spec:
> 
> '''
> BX = Allocation region
> 00 = Allocate from either 0xE or 0xF 64 KB blocks.
> Bit 0 = 1 Allocate from 0xF 64 KB block
> Bit 1 = 1 Allocate from 0xE 64 KB block
> '''
> 
> I think the value 0 for BX is fine which indicates the allocation can
> happen in either ranges. Not sure if setting BX to 0x11 is a valid
> operation.

Based on the spec you quote, it does seem reasonable to expect that a
CSM should treat 0 the same as 3, but it is possible that some CSM out
there made a silly choice and would blow up on 3.

Since David mentioned that bx==0 works ok with SeaBIOS CSM, then maybe
we should just drop this change? Or, we can add a comment that bx==0
means either the e000 or f000 block?

-Jordan

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

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

Re: [edk2-devel] [PATCH V3 1/2] MdeModulePkg: Add a pcd to set the OS indications bit

[Wu, Hao A]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Gao, Zhichao
> Sent: Tuesday, June 04, 2019 9:05 AM
> To: devel@edk2.groups.io
> Cc: Bret Barkelew; Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming;
> Sean Brogan; Michael Turner
> Subject: [edk2-devel] [PATCH V3 1/2] MdeModulePkg: Add a pcd to set the
> OS indications bit
> 
> From: Bret Barkelew 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1678
> 
> Add a pcd PcdPlatformRecoverySupport to conditionally
> set an OS indications bit and set the 'PlatformRecovery'
> variable. This pcd would also control whether the BDS
> support platform recovery or not.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Ray Ni 
> Cc: Star Zeng 
> Cc: Liming Gao 
> Cc: Sean Brogan 
> Cc: Michael Turner 
> Cc: Bret Barkelew 
> Signed-off-by: Zhichao Gao 
> Reviewed-by: Ray Ni 
> ---
>  MdeModulePkg/MdeModulePkg.dec | 6 ++


Really sorry for the delayed response.
Please help to update the MdeModulePkg.uni file for adding a new PCD.

With this handled:
Reviewed-by: Hao A Wu 

Best Regards,
Hao Wu


>  1 file changed, 6 insertions(+)
> 
> diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec
> index 0a9fcddecc..da2b85770c 100644
> --- a/MdeModulePkg/MdeModulePkg.dec
> +++ b/MdeModulePkg/MdeModulePkg.dec
> @@ -1660,6 +1660,12 @@
># @Prompt Reset on memory type information change.
> 
> gEfiMdeModulePkgTokenSpaceGuid.PcdResetOnMemoryTypeInformationC
> hange|TRUE|BOOLEAN|0x00010056
> 
> +  ## Indicates if the BDS supports Platform Recovery.
> +  #   TRUE  - BDS supports Platform Recovery.
> +  #   FALSE - BDS does not support Platform Recovery.
> +  # @Prompt Support Platform Recovery.
> +
> gEfiMdeModulePkgTokenSpaceGuid.PcdPlatformRecoverySupport|TRUE|B
> OOLEAN|0x00010078
> +
>## Specify the foreground color for Subtile text in HII Form Browser. The
> default value is EFI_BLUE.
>#  Only following values defined in UEFI specification are valid:
>#  0x00 (EFI_BLACK)
> --
> 2.21.0.windows.1
> 
> 
> 


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

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

Re: [edk2-devel] [PATCH] Platform/Intel: Dynamic NUMBER_OF_PROCESSORS in build.

[Bob Feng]

Hi Chasel,

Patch looks good.

For the process number, build.py does the same thing as this patch. If pass -n 
0 to build.py, build.py will set the processor number to 
multiprocessing.cpu_count()

Thanks,
Bob


-Original Message-
From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of Chiu, 
Chasel
Sent: Thursday, June 13, 2019 2:15 PM
To: devel@edk2.groups.io
Cc: Kubacki, Michael A ; Desimone, Nathaniel L 
; Gao, Liming 
Subject: [edk2-devel] [PATCH] Platform/Intel: Dynamic NUMBER_OF_PROCESSORS in 
build.

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

To improve build performance by default the maximum processors should be used 
for building.
To support this, NUMBER_OF_PROCESSORS in build.cfg has new definition:
  0 = AUTO. Maximum of processors will be used.
  non-zero = limit or force the number of processors.

Test: tried several NUMBER_OF_PROCESSORS settings and
  the build parameter can be updated accordingly
  also builds successfully.

Cc: Michael Kubacki 
Cc: Nate DeSimone 
Cc: Liming Gao 
Signed-off-by: Chasel Chiu 
---
 Platform/Intel/build.cfg | 2 +-
 Platform/Intel/build_bios.py | 8 +++-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/Platform/Intel/build.cfg b/Platform/Intel/build.cfg index 
6c23e5eabc..fc6e4fe824 100644
--- a/Platform/Intel/build.cfg
+++ b/Platform/Intel/build.cfg
@@ -46,7 +46,7 @@ FSP_TEST_RELEASE = FALSE  SECURE_BOOT_ENABLE = FALSE  
REBUILD_MODE =  BUILD_ROM_ONLY = -NUMBER_OF_PROCESSORS = 1
+NUMBER_OF_PROCESSORS = 0
 
 
 [PLATFORMS]
diff --git a/Platform/Intel/build_bios.py b/Platform/Intel/build_bios.py index 
09eceddeff..864511ac4d 100644
--- a/Platform/Intel/build_bios.py
+++ b/Platform/Intel/build_bios.py
@@ -21,6 +21,7 @@ import shutil
 import argparse
 import traceback
 import subprocess
+import multiprocessing
 from importlib import import_module
 
 try:
@@ -345,7 +346,12 @@ def build(config):
 print(" BUILD_ROM_ONLY = ", config.get("BUILD_ROM_ONLY"))
 print("==")
 
-command = ["build", "-n", config["NUMBER_OF_PROCESSORS"]]
+NumberOfProcessors = config["NUMBER_OF_PROCESSORS"]
+if config["NUMBER_OF_PROCESSORS"] == "0":
+# 0 means AUTO, maximum number of processors will be set
+NumberOfProcessors = str(multiprocessing.cpu_count())
+print ("Number of processors set to " + NumberOfProcessors)
+command = ["build", "-n", NumberOfProcessors]
 
 if config["REBUILD_MODE"] and config["REBUILD_MODE"] != "":
 command.append(config["REBUILD_MODE"])
--
2.13.3.windows.1





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

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

Re: [edk2-devel] [PATCH 11/10] OvmfPkg/Csm/LegacyBiosDxe: Correct Legacy16GetTableAddress call for E820 data

[Ni, Ray]

> -Original Message-
> From: Wu, Hao A
> Sent: Thursday, June 13, 2019 2:28 PM
> To: devel@edk2.groups.io; dw...@infradead.org; Ni, Ray
> 
> Cc: Justen, Jordan L ; Laszlo Ersek
> ; Ard Biesheuvel 
> Subject: RE: [edk2-devel] [PATCH 11/10] OvmfPkg/Csm/LegacyBiosDxe:
> Correct Legacy16GetTableAddress call for E820 data
> 
> Hello Ray,
> 
> Do you have comment on this?

No.

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

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

Re: [edk2-devel] [PATCH V4 0/2] MdeModulePkg: Make the screen seamless

[Wu, Hao A]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Wu, Hao A
> Sent: Monday, May 27, 2019 10:15 AM
> To: Gao, Zhichao; devel@edk2.groups.io
> Cc: Wang, Jian J; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan; Michael
> Turner; Bret Barkelew; Laszlo Ersek
> Subject: Re: [edk2-devel] [PATCH V4 0/2] MdeModulePkg: Make the screen
> seamless
> 
> For my understanding, the series looks like a feature rather than bug to me.
> I suggest to hold this one until the stable tag is created.


Pushed via commits e85cfa2fa4..0a35997643.

Best Regards,
Hao Wu


> 
> Best Regards,
> Hao Wu
> 
> 
> > -Original Message-
> > From: Gao, Zhichao
> > Sent: Friday, May 24, 2019 10:40 AM
> > To: devel@edk2.groups.io
> > Cc: Wang, Jian J; Wu, Hao A; Ni, Ray; Zeng, Star; Gao, Liming; Sean Brogan;
> > Michael Turner; Bret Barkelew; Laszlo Ersek
> > Subject: [PATCH V4 0/2] MdeModulePkg: Make the screen seamless
> >
> > For now most platforms support display function at PEI phase.
> > But the conspliter and graphics console driver would clear the
> > screen at BDS connect console phase. Maybe some platforms would
> > show logo in the next or maybe not. For consumers, it looks like
> > the screen flashed.
> > So change the behavior of graphics console devices while connect
> > console devices to maintain seamless screen from PEI.
> >
> > Test has done on MinPlatform Kabylake-RVP3 which support PEI
> > display.
> >
> > V2:
> > Make the SetMode not clear the screen only at the first boot during
> > the first conncettion of graphics device.
> >
> > V3:
> > Abandon V2. Directly set the output mode without clear the screen
> > while initialize the graphics console device. Add clear screen operation
> > in stop function of graphics console device.
> >
> > V4:
> > Fix incorrect mode check in V3.
> > Initialize the mode to an invalid mode. If no perfer mode is found, it
> > is better to initialize its text mode to an invalid one.
> > Remove the ClearScreen fuction in the BindingStop function in V3.
> > The graphics output driver may disconnect before graphics console, that
> > may cause a system exception because of using released resource.
> > Impact: the screen would not be cleared after reconnect the graphics
> device
> > thru software, such as 'reconnect -r' in shell.
> >
> > Cc: Jian J Wang 
> > Cc: Hao Wu 
> > Cc: Ray Ni 
> > Cc: Star Zeng 
> > Cc: Liming Gao 
> > Cc: Sean Brogan 
> > Cc: Michael Turner 
> > Cc: Bret Barkelew 
> > Cc: Laszlo Ersek 
> >
> > Aaron Antone (1):
> >   MdeModulePkg/ConSplitterDxe: Optimize the
> > ConSplitterTextOutSetMode
> >
> > Zhichao Gao (1):
> >   MdeModulePkg/GraphicsConsoleDxe: Initialize the output mode
> >
> >  .../Console/ConSplitterDxe/ConSplitter.c  | 33 ++-
> >  .../Console/ConSplitterDxe/ConSplitter.h  |  4 +-
> >  .../GraphicsConsoleDxe/GraphicsConsole.c  | 42 ++-
> >  .../GraphicsConsoleDxe/GraphicsConsoleDxe.inf |  2 +
> >  4 files changed, 59 insertions(+), 22 deletions(-)
> >
> > --
> > 2.21.0.windows.1
> 
> 
> 


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

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

Re: [edk2-devel] [PATCH v2 1/4] MdeModulePkg: Introduce EDKII_SERIAL_PORT_LIB_VENDOR_GUID

[Wu, Hao A]

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> Laszlo Ersek
> Sent: Friday, June 07, 2019 1:13 AM
> To: Anthony PERARD; devel@edk2.groups.io
> Cc: Ni, Ray; Julien Grall; Ard Biesheuvel; Leif Lindholm; Wang, Jian J; Wu, 
> Hao
> A; Zeng, Star
> Subject: Re: [edk2-devel] [PATCH v2 1/4] MdeModulePkg: Introduce
> EDKII_SERIAL_PORT_LIB_VENDOR_GUID
> 
> On 06/06/19 15:14, Anthony PERARD wrote:
> > SERIAL_DXE_FILE_GUID is used in different places, create a single
> > define that other can use. Also fix SerialDxe to actually use
> > EDKII_SERIAL_PORT_LIB_VENDOR_GUID in the device path instead of the
> > FILE_GUID.
> >
> > Suggested-by: Laszlo Ersek 
> > Signed-off-by: Anthony PERARD 
> > ---
> >
> > Notes:
> > Suggested in: Message-ID: <7d6adf5d-baca-7e9c-68ef-
> 2f8479bbd...@redhat.com>
> >
> >  MdeModulePkg/MdeModulePkg.dec |  3 +++
> >  .../Universal/SerialDxe/SerialDxe.inf |  1 +
> >  .../Include/Guid/SerialPortLibVendor.h| 19 +++
> >  MdeModulePkg/Universal/SerialDxe/SerialIo.c   |  3 ++-
> >  4 files changed, 25 insertions(+), 1 deletion(-)
> >  create mode 100644 MdeModulePkg/Include/Guid/SerialPortLibVendor.h
> >
> > diff --git a/MdeModulePkg/MdeModulePkg.dec
> b/MdeModulePkg/MdeModulePkg.dec
> > index 6cba729982..2dee139ba3 100644
> > --- a/MdeModulePkg/MdeModulePkg.dec
> > +++ b/MdeModulePkg/MdeModulePkg.dec
> > @@ -396,6 +396,9 @@ [Guids]
> >## Include/Guid/S3StorageDeviceInitList.h
> >gS3StorageDeviceInitListGuid = { 0x310e9b8c, 0xcf90, 0x421e, { 0x8e, 
> > 0x9b,
> 0x9e, 0xef, 0xb6, 0x17, 0xc8, 0xef } }
> >
> > +  ## Include/Guid/SerialPortLibVendor.h
> > +  gEdkiiSerialPortLibVendorGuid = { 0xD3987D4B, 0x971A, 0x435F, { 0x8C,
> 0xAF, 0x49, 0x67, 0xEB, 0x62, 0x72, 0x41 } }
> > +
> >  [Ppis]
> >## Include/Ppi/AtaController.h
> >gPeiAtaControllerPpiGuid   = { 0xa45e60d1, 0xc719, 0x44aa, { 0xb0, 
> > 0x7a,
> 0xaa, 0x77, 0x7f, 0x85, 0x90, 0x6d }}
> > diff --git a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
> b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
> > index 81066a26a2..b6c85b3f84 100644
> > --- a/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
> > +++ b/MdeModulePkg/Universal/SerialDxe/SerialDxe.inf
> > @@ -22,6 +22,7 @@ [Sources.common]
> >
> >  [Packages]
> >MdePkg/MdePkg.dec
> > +  MdeModulePkg/MdeModulePkg.dec
> >
> >  [LibraryClasses]
> >UefiDriverEntryPoint
> > diff --git a/MdeModulePkg/Include/Guid/SerialPortLibVendor.h
> b/MdeModulePkg/Include/Guid/SerialPortLibVendor.h
> > new file mode 100644
> > index 00..887f96c30a
> > --- /dev/null
> > +++ b/MdeModulePkg/Include/Guid/SerialPortLibVendor.h
> > @@ -0,0 +1,19 @@
> > +/** @file
> > +  Define the SerialDxe GUID.
> 
> I think we could elaborate a bit more here, if we really wanted to, but
> in the end I'm fine with this. (I'm not an MdeModulePkg maintainer though.)


Sorry for the delayed response.
I am okay with this file description comment.

Reviewed-by: Hao A Wu 

Best Regards,
Hao Wu


> 
> Reviewed-by: Laszlo Ersek 
> 
> Thanks
> Laszlo
> 
> 
> > +
> > +  Copyright (c) 2019, Citrix Systems, Inc.
> > +
> > +  SPDX-License-Identifier: BSD-2-Clause-Patent
> > +**/
> > +
> > +#ifndef __SERIAL_PORT_LIB_VENDOR_H__
> > +#define __SERIAL_PORT_LIB_VENDOR_H__
> > +
> > +#define EDKII_SERIAL_PORT_LIB_VENDOR_GUID { \
> > +  0xD3987D4B, 0x971A, 0x435F, \
> > +  { 0x8C, 0xAF, 0x49, 0x67, 0xEB, 0x62, 0x72, 0x41 } \
> > +  }
> > +
> > +extern EFI_GUID gEdkiiSerialPortLibVendorGuid;
> > +
> > +#endif // __SERIAL_PORT_LIB_VENDOR_H__
> > diff --git a/MdeModulePkg/Universal/SerialDxe/SerialIo.c
> b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
> > index 720a3f264a..fb816a1611 100644
> > --- a/MdeModulePkg/Universal/SerialDxe/SerialIo.c
> > +++ b/MdeModulePkg/Universal/SerialDxe/SerialIo.c
> > @@ -16,6 +16,7 @@
> >
> >  #include 
> >  #include 
> > +#include 
> >
> >  typedef struct {
> >VENDOR_DEVICE_PATHGuid;
> > @@ -159,7 +160,7 @@ EFI_HANDLE mSerialHandle = NULL;
> >  SERIAL_DEVICE_PATH mSerialDevicePath = {
> >{
> >  { HARDWARE_DEVICE_PATH, HW_VENDOR_DP, { sizeof
> (VENDOR_DEVICE_PATH), 0} },
> > -EFI_CALLER_ID_GUID  // Use the driver's GUID
> > +EDKII_SERIAL_PORT_LIB_VENDOR_GUID
> >},
> >{
> >  { MESSAGING_DEVICE_PATH, MSG_UART_DP, { sizeof
> (UART_DEVICE_PATH), 0} },
> >
> 
> 
> 


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

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

Re: [EXT] Re: [edk2-devel] Printing git commit in build

[Udit Kumar]

Thanks Laszlo

> -Original Message-
> From: Laszlo Ersek 
> Sent: Thursday, June 6, 2019 1:55 PM
> To: devel@edk2.groups.io; Udit Kumar 
> Subject: [EXT] Re: [edk2-devel] Printing git commit in build
> 
> Caution: EXT Email
> 
> On 06/06/19 07:38, Udit Kumar wrote:
> > Dear Community,
> >
> > I like to print git commit id, which printing UEFI firmware build 
> > information.
> > Could you help, how I can collect ' git describe' information in C file.
> 
> I think you should be able to do this in the PREBUILD hook in the DSC file.
> (Run "git describe" in a script for generating a simple C source file.)
> 
> 
> Another option would be to introduce a PCD in your platform package DEC
> file, with datum type (VOID*) and access method FixedAtBuild. For example:
> 
> [PcdsFixedAtBuild]
>   gMyPlatformPkgTokenSpaceGuid.PcdBuildIdentifier|""|VOID*|
> 
> and when you build your platform DSC, you could pass the following option
> to the "build" utility:
> 
>   --pcd=gMyPlatformPkgTokenSpaceGuid.PcdBuildIdentifier="$(git
> describe)"
> 
> Thanks
> Laszlo

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

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

Re: [edk2-devel] [PATCH 11/10] OvmfPkg/Csm/LegacyBiosDxe: Correct Legacy16GetTableAddress call for E820 data

[Wu, Hao A]

Hello Ray,

Do you have comment on this?

Some inline comments below:

> -Original Message-
> From: devel@edk2.groups.io [mailto:devel@edk2.groups.io] On Behalf Of
> David Woodhouse
> Sent: Thursday, June 13, 2019 5:43 AM
> To: Wu, Hao A
> Cc: devel@edk2.groups.io; Ni, Ray; Justen, Jordan L; Laszlo Ersek; Ard
> Biesheuvel
> Subject: [edk2-devel] [PATCH 11/10] OvmfPkg/Csm/LegacyBiosDxe: Correct
> Legacy16GetTableAddress call for E820 data
> 
> The DX register is supposed to contain the required alignment for the
> allocation. It was zero, and SeaBIOS doesn't (well, didn't) cope well
> with that. Set it appropriately, and set BX to indicate the regions
> it's OK to allocate in too. That was already OK but let's make sure
> it's initialised properly and not just working by chance.
> 
> Also actually return an error if the allocation fails. Instead of going
> all the way through into the CSM and just letting it have a bogus
> pointer to the E82o data.
> 
> Signed-off-by: David Woodhouse 
> ---
> I made SeaBIOS cope with the zero too:
> https://mail.coreboot.org/hyperkitty/list/seab...@seabios.org/thread/4PH
> W3O3Y3HJFENODFV5INBGDLZMXA5KE/
> 
>  OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c | 3 +++


Not sure if it is the issue of my mail client, the new lines added are
with LF line ending on my local machine after applying the patch.


>  1 file changed, 3 insertions(+)
> 
> diff --git a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> index 211750c012..e7766eb2b1 100644
> --- a/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> +++ b/OvmfPkg/Csm/LegacyBiosDxe/LegacyBootSupport.c
> @@ -928,7 +928,9 @@ GenericLegacyBoot (
>if (CopySize > Private->Legacy16Table->E820Length) {
>  ZeroMem (, sizeof (EFI_IA32_REGISTER_SET));
>  Regs.X.AX = Legacy16GetTableAddress;
> +Regs.X.BX = (UINT16) 0x3; // Region


According to the spec:

'''
BX = Allocation region
00 = Allocate from either 0xE or 0xF 64 KB blocks.
Bit 0 = 1 Allocate from 0xF 64 KB block
Bit 1 = 1 Allocate from 0xE 64 KB block
'''

I think the value 0 for BX is fine which indicates the allocation can
happen in either ranges. Not sure if setting BX to 0x11 is a valid
operation.

With the above comments handled:
Reviewed-by: Hao A Wu 

Best Regards,
Hao Wu


>  Regs.X.CX = (UINT16) CopySize;
> +Regs.X.DX = (UINT16) 0x4; // Alignment
>  Private->LegacyBios.FarCall86 (
>>LegacyBios,
>Private->Legacy16Table->Compatibility16CallSegment,
> @@ -942,6 +944,7 @@ GenericLegacyBoot (
>  Private->Legacy16Table->E820Length  = (UINT32) CopySize;
>  if (Regs.X.AX != 0) {
>DEBUG ((EFI_D_ERROR, "Legacy16 E820 length insufficient\n"));
> +  return EFI_OUT_OF_RESOURCES;
>  } else {
>CopyMem (
>  (VOID *)(UINTN) Private->Legacy16Table->E820Pointer,
> 
> 
> 


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

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

[edk2-devel] [PATCH] Platform/Intel: Dynamic NUMBER_OF_PROCESSORS in build.

[Chiu, Chasel]

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

To improve build performance by default the maximum
processors should be used for building.
To support this, NUMBER_OF_PROCESSORS in build.cfg has
new definition:
  0 = AUTO. Maximum of processors will be used.
  non-zero = limit or force the number of processors.

Test: tried several NUMBER_OF_PROCESSORS settings and
  the build parameter can be updated accordingly
  also builds successfully.

Cc: Michael Kubacki 
Cc: Nate DeSimone 
Cc: Liming Gao 
Signed-off-by: Chasel Chiu 
---
 Platform/Intel/build.cfg | 2 +-
 Platform/Intel/build_bios.py | 8 +++-
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/Platform/Intel/build.cfg b/Platform/Intel/build.cfg
index 6c23e5eabc..fc6e4fe824 100644
--- a/Platform/Intel/build.cfg
+++ b/Platform/Intel/build.cfg
@@ -46,7 +46,7 @@ FSP_TEST_RELEASE = FALSE
 SECURE_BOOT_ENABLE = FALSE
 REBUILD_MODE =
 BUILD_ROM_ONLY =
-NUMBER_OF_PROCESSORS = 1
+NUMBER_OF_PROCESSORS = 0
 
 
 [PLATFORMS]
diff --git a/Platform/Intel/build_bios.py b/Platform/Intel/build_bios.py
index 09eceddeff..864511ac4d 100644
--- a/Platform/Intel/build_bios.py
+++ b/Platform/Intel/build_bios.py
@@ -21,6 +21,7 @@ import shutil
 import argparse
 import traceback
 import subprocess
+import multiprocessing
 from importlib import import_module
 
 try:
@@ -345,7 +346,12 @@ def build(config):
 print(" BUILD_ROM_ONLY = ", config.get("BUILD_ROM_ONLY"))
 print("==")
 
-command = ["build", "-n", config["NUMBER_OF_PROCESSORS"]]
+NumberOfProcessors = config["NUMBER_OF_PROCESSORS"]
+if config["NUMBER_OF_PROCESSORS"] == "0":
+# 0 means AUTO, maximum number of processors will be set
+NumberOfProcessors = str(multiprocessing.cpu_count())
+print ("Number of processors set to " + NumberOfProcessors)
+command = ["build", "-n", NumberOfProcessors]
 
 if config["REBUILD_MODE"] and config["REBUILD_MODE"] != "":
 command.append(config["REBUILD_MODE"])
-- 
2.13.3.windows.1


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

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