Re: [edk2] [PATCH v4 edk2-platforms 01/23] Silicon/Broadcom/Bcm282x: Add interrupt driver

2019-01-31 Thread Leif Lindholm
+Andrew, Laszlo, Mike.

On Thu, Jan 31, 2019 at 06:19:48PM +0100, Ard Biesheuvel wrote:
> On Thu, 31 Jan 2019 at 16:24, Leif Lindholm  wrote:
> >
> > On Tue, Jan 29, 2019 at 04:26:33PM +, Pete Batard wrote:
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Pete Batard 
> > >
> > > Reviewed-by: Ard Biesheuvel 
> > > ---
> > >  Silicon/Broadcom/Bcm283x/Bcm283x.dec   |  23 ++
> > >  Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c   | 367 
> > > 
> > >  Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.inf |  48 +++
> > >  Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h|  72 
> >
> > Another generic comment: "IndustryStandard" is something like ACPI,
> > SMBIOS, PCI, USB, MMC, ... (also including SoC/platform-specific
> > additions to the same).
> 
> Is that your interpretation? Or is this documented somewhere?

Only in asmuch as it is a clearly descriptive name.

> I could live with Chipset/, and I'm open to other suggestions, but the
> Library vs Protocol vs IndustryStandard distinction is very useful
> imo.

It is useful because it is descriptive.
Pretending that an SoC hardware description or a platform description
header is an "Industry Standard" is disingenuous.

> > I would be more comfortable with SoC-specific and Platform-specific
> > include files living directly in Include/.
> 
> No, don't drop headers in Include/ please. The namespacing is one of
> the things EDK2 actually gets right (assuming you define the paths
> correctly in the package .dec file), and I'd hate to start dumping
> headers at the root level because we cannot make up our minds what to
> call the enclosing folder.

Mike, Andrew - what is your take on this?
Is there a formal definition of not only what goes in
IndustryStandard, but where chipset and platform headers should live
in the namespace?

Regards,

Leif

> > >  4 files changed, 510 insertions(+)
> > >
> > > diff --git a/Silicon/Broadcom/Bcm283x/Bcm283x.dec 
> > > b/Silicon/Broadcom/Bcm283x/Bcm283x.dec
> > > new file mode 100644
> > > index ..d193da4c0e1e
> > > --- /dev/null
> > > +++ b/Silicon/Broadcom/Bcm283x/Bcm283x.dec
> > > @@ -0,0 +1,23 @@
> > > +## @file
> > > +#
> > > +#  Copyright (c) 2019, Pete Batard 
> > > +#
> > > +#  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.
> > > +#
> > > +##
> > > +
> > > +[Defines]
> > > +  DEC_SPECIFICATION  = 0x0001001A
> > > +  PACKAGE_NAME   = Bcm283xPkg
> > > +  PACKAGE_GUID   = 900C0F44-1152-4FF9-B9C5-933E2918C831
> > > +  PACKAGE_VERSION= 1.0
> > > +
> > > +[Includes]
> > > +  Include
> > > diff --git a/Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c 
> > > b/Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c
> > > new file mode 100644
> > > index ..9058aa94ffb9
> > > --- /dev/null
> > > +++ b/Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c
> > > @@ -0,0 +1,367 @@
> > > +/** @file
> > > + *
> > > + *  Copyright (c) 2016, Linaro, Ltd. All rights reserved.
> > > + *
> > > + *  This program and the accompanying materials
> > > + *  are licensed and made available under the terms and conditions of 
> > > the BSD License
> > > + *  which accompanies this distribution.  The full text of the license 
> > > may be found at
> > > + *  http://opensource.org/licenses/bsd-license.php
> > > + *
> > > + *  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> > > + *  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> > > IMPLIED.
> > > + *
> > > + **/
> > > +
> > > +#include 
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#include 
> > > +
> > > +#include 
> > > +#include 
> > > +
> > > +//
> > > +// This currently only implements support for the architected timer 
> > > interrupts
> > > +// on the per-CPU interrupt controllers.
> > > +//
> > > +#define NUM_IRQS(4)
> > > +
> > > +#ifdef MDE_CPU_AARCH64
> > > +#define ARM_ARCH_EXCEPTION_IRQ  EXCEPT_AARCH64_IRQ
> > > +#else
> > > +#define ARM_ARCH_EXCEPTION_IRQ  EXCEPT_ARM_IRQ
> > > +#endif
> > > +
> > > +STATIC CONST
> > > +EFI_PHYSICAL_ADDRESS RegBase = FixedPcdGet32 (PcdInterruptBaseAddress);
> > > +
> > > +//
> > > +// Notifications
> > > +//
> > > +STATIC EFI_EVENTmExitBootServicesEvent;
> > > +STATIC HARDWARE_INTERRUPT_HANDLER   
> > > mRegisteredInterruptHandlers[NUM_IRQS];

Re: [edk2] [PATCH v4 edk2-platforms 01/23] Silicon/Broadcom/Bcm282x: Add interrupt driver

2019-01-31 Thread Andrew Fish via edk2-devel



> On Jan 31, 2019, at 11:57 AM, Leif Lindholm  wrote:
> 
> +Andrew, Laszlo, Mike.
> 
> On Thu, Jan 31, 2019 at 06:19:48PM +0100, Ard Biesheuvel wrote:
>> On Thu, 31 Jan 2019 at 16:24, Leif Lindholm  wrote:
>>> 
>>> On Tue, Jan 29, 2019 at 04:26:33PM +, Pete Batard wrote:
 Contributed-under: TianoCore Contribution Agreement 1.1
 Signed-off-by: Pete Batard 
 
 Reviewed-by: Ard Biesheuvel 
 ---
 Silicon/Broadcom/Bcm283x/Bcm283x.dec   |  23 ++
 Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c   | 367 
 
 Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.inf |  48 +++
 Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h|  72 
>>> 
>>> Another generic comment: "IndustryStandard" is something like ACPI,
>>> SMBIOS, PCI, USB, MMC, ... (also including SoC/platform-specific
>>> additions to the same).
>> 
>> Is that your interpretation? Or is this documented somewhere?
> 
> Only in asmuch as it is a clearly descriptive name.
> 
>> I could live with Chipset/, and I'm open to other suggestions, but the
>> Library vs Protocol vs IndustryStandard distinction is very useful
>> imo.
> 
> It is useful because it is descriptive.
> Pretending that an SoC hardware description or a platform description
> header is an "Industry Standard" is disingenuous.
> 
>>> I would be more comfortable with SoC-specific and Platform-specific
>>> include files living directly in Include/.
>> 
>> No, don't drop headers in Include/ please. The namespacing is one of
>> the things EDK2 actually gets right (assuming you define the paths
>> correctly in the package .dec file), and I'd hate to start dumping
>> headers at the root level because we cannot make up our minds what to
>> call the enclosing folder.
> 
> Mike, Andrew - what is your take on this?
> Is there a formal definition of not only what goes in
> IndustryStandard, but where chipset and platform headers should live
> in the namespace?
> 

Leif,

I kind of think IndustryStandard as things that have a public spec I don't know 
if we have a pedantic definition of what that means. 

I'm with Ard on that I like the current Include structure for the generic 
packages and global definitions. 

What seems to work poorly in our packaging scheme is the intersection of 
platforms and chipsets. Everything works OK is you just use PCDs, but if you 
try to use includes it get complicated. I guess that Library instances can help 
here too. An IP block for an SoC could be another example, do we  need a 
package for each IP block? Thus any SoC that uses that IP block can depend on 
that package? If you don't do that you end up copies of that IP block 
definition in every SoC package. In a more traditional C world grabbing 
includes is just a matter of adding an include search path to the build, but in 
the edk2 it is about having the proper package definitions, and the set of 
packages are somewhat fixed in the INF files. But I guess after all this 
rambling I'm really saying it is hard to figure out what package to put a given 
include in. I'm not sure that impacts pathing in a single package?

I think the scope of the package matters too as if you have a package to 
support a chipset (SoC) do you really need Include/Chipset or Include/Soc? As 
long as you have the Guid, Library, Ppi, Protocol, and IndustryStandard the 
package can dump everything in /Include or build some directory hierarchy that 
makes sense. But then again punting on what this hierarchy seems to not answer 
your question. I guess if the package has lots of functionality adding Include 
directory structure makes sense, if it is a smaller focused package it seems 
like having an extra directory for the main focus of the package could be 
redundant. 

Thanks,

Andrew Fish


> Regards,
> 
> Leif
> 
 4 files changed, 510 insertions(+)
 
 diff --git a/Silicon/Broadcom/Bcm283x/Bcm283x.dec 
 b/Silicon/Broadcom/Bcm283x/Bcm283x.dec
 new file mode 100644
 index ..d193da4c0e1e
 --- /dev/null
 +++ b/Silicon/Broadcom/Bcm283x/Bcm283x.dec
 @@ -0,0 +1,23 @@
 +## @file
 +#
 +#  Copyright (c) 2019, Pete Batard 
 +#
 +#  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.
 +#
 +##
 +
 +[Defines]
 +  DEC_SPECIFICATION  = 0x0001001A
 +  PACKAGE_NAME   = Bcm283xPkg
 +  PACKAGE_GUID   = 900C0F44-1152-4FF9-B9C5-933E2918C831
 +  PACKAGE_VERSION= 1.0
 +

Re: [edk2] [PATCH] EmbeddedPkg/DwEmacSnpDxe: Add designware emac support This add support for designware emac controller

2019-01-31 Thread Leif Lindholm
Hi Tzy Way,

Thank you for this contribution.

I do have some high-level comments.

First of all, my best guess is that you have used Lan9118Dxe for
reference when developing this driver. This is somewhat unfortunate.
I am reminded that
a) we badly need to migrate that driver (and Lan91xDxe) to
   edk2-platforms.
b) we badly need to convert those drivers to UEFI driver model and
   NonDiscoverableDeviceRegistrationLib.
Those two predate the NonDiscoverable implementation, so have been
left as is, but any new drivers really need to implement proper driver
model.
Additionally, this driver should be submitted to edk2-platforms rather
than edk2.

Secondly, searching online for "designware emac" does not find
unambigously the product this refers to. This is where it would be
usful with a proper commit message and explain in a bit more detail
what the driver is.

On Thu, Jan 31, 2019 at 04:32:00PM +0800, tzy.way@intel.com wrote:
> From: "Ooi, Tzy Way" 
> 
> Contributed-under: TianCore Contribution Agreement 1.1
> Signed-off-by: Ooi, Tzy Way 
> ---
>  .../Drivers/DwEmacSnpDxe/DwEmacSnpDxe.c   | 1368 +
>  .../Drivers/DwEmacSnpDxe/DwEmacSnpDxe.h   |  236 +++
>  .../Drivers/DwEmacSnpDxe/DwEmacSnpDxe.inf |   69 +
>  .../Drivers/DwEmacSnpDxe/EmacDxeUtil.c|  676 
>  .../Drivers/DwEmacSnpDxe/EmacDxeUtil.h|  378 +
>  EmbeddedPkg/Drivers/DwEmacSnpDxe/PhyDxeUtil.c |  604 
>  EmbeddedPkg/Drivers/DwEmacSnpDxe/PhyDxeUtil.h |  324 
>  EmbeddedPkg/EmbeddedPkg.dec   |4 +
>  EmbeddedPkg/EmbeddedPkg.dsc   |1 +
>  9 files changed, 3660 insertions(+)

Thirdly, please generate patches as described in
https://github.com/tianocore/tianocore.github.io/wiki/Laszlo%27s-unkempt-git-guide-for-edk2-contributors-and-maintainers#contrib-23
This greatly simplifies review.

Best Regards,

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


Re: [edk2] [PATCH edk2-platforms] Silicon/Bcm2836: add random number generator driver

2019-01-31 Thread Leif Lindholm
On Thu, Jan 31, 2019 at 06:14:45PM +0100, Ard Biesheuvel wrote:
> On Thu, 31 Jan 2019 at 16:05, Leif Lindholm  wrote:
> >
> > On Wed, Jan 30, 2019 at 08:39:43PM +0100, Ard Biesheuvel wrote:
> > > Expose the SoC's RNG peripheral via the EFI_RNG_PROTOCOL.
> > > This is used by Linux to seed the KASLR routines.
> > >
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Ard Biesheuvel 
> >
> > Not tested, but looks fine. Only question: could we add those few
> > #defines to IndustryStandard/Bcm2836.h (should that really be
> > #IndustryStandard, btw?) rather than creating a tiny standalone one?
> > (more below)
> >
> 
> Sure.
> 
> Re IndustryStandard/, I deliberately chose something idiomatic for
> EDK2, and this is the least inappropriate one. I could live with
> Chipset/ as well, but dumping headers under Include/ directly is not
> the solution IMO.

I disagree. Dumping the main SoC header under the top-level SoC
directory (and same pattern for platform) is idiomatic.
Dumping all kinds of random files there isn't, I agree (although that
happens too).

BeagleBoardPkg/Include/BeagleBoard.h
OvmfPkg/Include/OvmfPlatforms.h
Vlv2TbltDevicePkg/Include/Platform.h

Silicon/Hisilicon/Hi6220/Include/Hi6220.h

An alternative pattern is an include directory named after the
SoC/Platform.

Omap35xxPkg/Include/Omap3530/

You used 

Silicon/Socionext/SynQuacer/Include/Platform/

which I also don't mind.

If you'd prefer it, I'd be happy with Platform/ and Silicon/.

But we'd better settle on something before Pete changes too much based
on my feedback.

/
Leif

> > > ---
> > >  Silicon/Broadcom/Bcm283x/Drivers/RngDxe/RngDxe.c   | 204 
> > > 
> > >  Silicon/Broadcom/Bcm283x/Drivers/RngDxe/RngDxe.inf |  45 
> > > +
> > >  Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h |  26 +++
> > >  3 files changed, 275 insertions(+)
> > >
> >
> > > diff --git 
> > > a/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h 
> > > b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h
> > > new file mode 100644
> > > index ..8274e2fe8f77
> > > --- /dev/null
> > > +++ b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h
> > > @@ -0,0 +1,26 @@
> > > + /** @file
> > > + *
> > > + *  Copyright (c) 2019 Linaro, Ltd. All rights reserved.
> > > + *
> > > + *  This program and the accompanying materials
> > > + *  are licensed and made available under the terms and conditions of 
> > > the BSD License
> > > + *  which accompanies this distribution.  The full text of the license 
> > > may be found at
> > > + *  http://opensource.org/licenses/bsd-license.php
> > > + *
> > > + *  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> > > + *  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> > > IMPLIED.
> > > + *
> > > + **/
> > > +
> > > +#ifndef __BCM2836_RNG_H__
> > > +#define __BCM2836_RNG_H__
> > > +
> > > +#define RNG_BASE_ADDRESS   (BCM2836_SOC_REGISTERS + 0x00104000)
> >
> > If we can't, this file needs to pull in Bcm2836.h anyway.
> >
> 
> Yep.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH] BaseTools: PCD value incorrect in structure pcd sku case.

2019-01-31 Thread Fan, ZhijuX
Defined 2 PCDs(Test4 & Test401) and 2 SKUs(DEFAULT & _),
then set "SKUID_Defines" to ALL, for FixedAtBuild 
gEfiStructuredPcdPkgTokenSpaceGuid. Test401 in this case, 
its value should get from "Default" SKU, not from "_" SKU, 
but we does not set value in SKU "_" in dsc, so Test401 
should only display the value get from dec.

Cc: Bob Feng 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Source/Python/Common/GlobalData.py  | 2 +-
 BaseTools/Source/Python/Workspace/DscBuildData.py | 1 +
 BaseTools/Source/Python/build/BuildReport.py  | 5 -
 3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/Common/GlobalData.py 
b/BaseTools/Source/Python/Common/GlobalData.py
index 5eaee06694..f117998b0b 100644
--- a/BaseTools/Source/Python/Common/GlobalData.py
+++ b/BaseTools/Source/Python/Common/GlobalData.py
@@ -103,7 +103,7 @@ MixedPcd = {}
 
 # Structure Pcd dict
 gStructurePcd = {}
-
+gPcdSkuOverrides={}
 # Pcd name for the Pcd which used in the Conditional directives
 gConditionalPcds = []
 
diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py 
b/BaseTools/Source/Python/Workspace/DscBuildData.py
index 233e530d5c..0ea1b1bb39 100644
--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
@@ -1525,6 +1525,7 @@ class DscBuildData(PlatformBuildClassObject):
 for stru_pcd in S_pcd_set.values():
 for skuid in SkuIds:
 if skuid in stru_pcd.SkuOverrideValues:
+GlobalData.gPcdSkuOverrides.update({(stru_pcd.TokenCName, 
stru_pcd.TokenSpaceGuidCName): stru_pcd.SkuOverrideValues})
 continue
 nextskuid = self.SkuIdMgr.GetNextSkuId(skuid)
 NoDefault = False
diff --git a/BaseTools/Source/Python/build/BuildReport.py 
b/BaseTools/Source/Python/build/BuildReport.py
index e979611c26..9752a9c0d2 100644
--- a/BaseTools/Source/Python/build/BuildReport.py
+++ b/BaseTools/Source/Python/build/BuildReport.py
@@ -1295,7 +1295,10 @@ class PcdReport(object):
 FileWrite(File, ' %-*s   : %6s %10s = %s' % (self.MaxLen, Flag 
+ ' ' + PcdTokenCName, TypeName, '(' + Pcd.DatumType + ')', Value))
 if IsStructure:
 FiledOverrideFlag = False
-OverrideValues = Pcd.SkuOverrideValues
+if (Pcd.TokenCName,Pcd.TokenSpaceGuidCName) in 
GlobalData.gPcdSkuOverrides:
+OverrideValues = 
GlobalData.gPcdSkuOverrides[(Pcd.TokenCName,Pcd.TokenSpaceGuidCName)]
+else:
+OverrideValues = Pcd.SkuOverrideValues
 if OverrideValues:
 for Data in OverrideValues.values():
 Struct = list(Data.values())
-- 
2.14.1.windows.1

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


[edk2] [PATCH] MdeModulePkg/CapsuleApp: Fix potential NULL pointer dereference issue

2019-01-31 Thread Chen A Chen
To avoid potential NULL pointer dereference issue. Initialize them at
the beginning of the function.

Cc: Jian J Wang 
Cc: Hao Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chen A Chen 
---
 MdeModulePkg/Application/CapsuleApp/CapsuleApp.c|  5 +++--
 MdeModulePkg/Application/CapsuleApp/CapsuleDump.c   | 17 +++--
 MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c | 17 +++--
 3 files changed, 29 insertions(+), 10 deletions(-)

diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c 
b/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
index 896acd3304..198a63555d 100644
--- a/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
+++ b/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
@@ -916,8 +916,9 @@ UefiMain (
   EFI_GUID  ImageTypeId;
   UINTN ImageIndex;
 
-  MapFsStr = NULL;
-  CapsuleNum = 0;
+  BlockDescriptors  = NULL;
+  MapFsStr  = NULL;
+  CapsuleNum= 0;
 
   Status = GetArg();
   if (EFI_ERROR(Status)) {
diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c 
b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
index 5bf617c5f6..7bef5a1378 100644
--- a/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
+++ b/MdeModulePkg/Application/CapsuleApp/CapsuleDump.c
@@ -795,11 +795,13 @@ DumpCapsuleFromDisk (
   UINTN FileCount;
   BOOLEAN   NoFile;
 
-  DirHandle  = NULL;
-  FileHandle = NULL;
-  Index  = 0;
-  FileCount  = 0;
-  NoFile = FALSE;
+  DirHandle   = NULL;
+  FileHandle  = NULL;
+  Index   = 0;
+  FileInfoBuffer  = NULL;
+  FileInfo= NULL;
+  FileCount   = 0;
+  NoFile  = FALSE;
 
   Status = Fs->OpenVolume (Fs, );
   if (EFI_ERROR (Status)) {
@@ -970,7 +972,10 @@ DumpProvisionedCapsule (
 
   ShellProtocol = GetShellProtocol ();
 
-  Index = 0;
+  Index = 0;
+  CapsuleDataPtr64  = NULL;
+  BootNext  = NULL;
+  ShellProtocol = NULL;
 
   //
   // Dump capsule provisioned on Memory
diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c 
b/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
index 393b7ae7db..4faa863bca 100644
--- a/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
+++ b/MdeModulePkg/Application/CapsuleApp/CapsuleOnDisk.c
@@ -151,9 +151,14 @@ DumpAllEfiSysPartition (
   UINTN  NumberEfiSystemPartitions;
   EFI_SHELL_PROTOCOL *ShellProtocol;
 
-  ShellProtocol = GetShellProtocol ();
   NumberEfiSystemPartitions = 0;
 
+  ShellProtocol = GetShellProtocol ();
+  if (ShellProtocol == NULL) {
+Print (L"Get Shell Protocol Fail\n");;
+return ;
+  }
+
   Print (L"EFI System Partition list:\n");
 
   gBS->LocateHandleBuffer (
@@ -421,7 +426,13 @@ GetUpdateFileSystem (
   EFI_BOOT_MANAGER_LOAD_OPTIONNewOption;
 
   MappedDevicePath = NULL;
+  BootOptionBuffer = NULL;
+
   ShellProtocol = GetShellProtocol ();
+  if (ShellProtocol == NULL) {
+Print (L"Get Shell Protocol Fail\n");;
+return EFI_NOT_FOUND;
+  }
 
   //
   // 1. If Fs is not assigned and there are capsule provisioned before,
@@ -468,7 +479,9 @@ GetUpdateFileSystem (
   // 2. Get EFI system partition form boot options.
   //
   BootOptionBuffer = EfiBootManagerGetLoadOptions (, 
LoadOptionTypeBoot);
-  if (BootOptionCount == 0 && Map == NULL) {
+  if ( (BootOptionBuffer == NULL) ||
+   (BootOptionCount == 0 && Map == NULL)
+ ) {
 return EFI_NOT_FOUND;
   }
 
-- 
2.16.2.windows.1

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


[edk2] [PATCH] FatPkg/FatPei/Gpt.c: Fix uninitialized variable issue

2019-01-31 Thread Chen A Chen
Uninitialized pointer variable may randomly point to a block of memory.
In This case, FreePool function will free a block of memory that is not
belongs to this function.

Cc: Ruiyu Ni 
Cc: Hao Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chen A Chen 
---
 FatPkg/FatPei/Gpt.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/FatPkg/FatPei/Gpt.c b/FatPkg/FatPei/Gpt.c
index c3afb668d7..bba33c5bfd 100644
--- a/FatPkg/FatPei/Gpt.c
+++ b/FatPkg/FatPei/Gpt.c
@@ -244,6 +244,9 @@ PartitionCheckGptEntryArray (
   UINTN   Index2;
   EFI_PARTITION_ENTRY *Entry;
 
+  PartitionEntryBuffer = NULL;
+  PartitionEntryStatus = NULL;
+
   ParentBlockDev  = &(PrivateData->BlockDevice[ParentBlockDevNo]);
   Found   = FALSE;
 
-- 
2.16.2.windows.1

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


[edk2] [PATCH] BaseTools:StructurePCD value display incorrect in "Not used" section.

2019-01-31 Thread Fan, ZhijuX
StructurePCD value display incorrect in "Not used" section,
that the value defined in structure does not show.

StructurePCD will not display in "Not Used" section if
main structure not define in dsc and pcd not in inf

Cc: Bob Feng 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Source/Python/Workspace/DscBuildData.py | 4 ++--
 BaseTools/Source/Python/build/BuildReport.py  | 7 +++
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py 
b/BaseTools/Source/Python/Workspace/DscBuildData.py
index 0dad04212e..661852b1d5 100644
--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
@@ -1511,9 +1511,9 @@ class DscBuildData(PlatformBuildClassObject):
 else:
 str_pcd_obj_str.DefaultFromDSC = 
{skuname:{defaultstore: 
str_pcd_obj.SkuInfoList[skuname].DefaultStoreDict.get(defaultstore, 
str_pcd_obj.SkuInfoList[skuname].DefaultValue) for defaultstore in 
DefaultStores} for skuname in str_pcd_obj.SkuInfoList}
 S_pcd_set[Pcd] = str_pcd_obj_str
-self.FilterStrcturePcd(S_pcd_set)
 if S_pcd_set:
-GlobalData.gStructurePcd[self.Arch] = S_pcd_set
+GlobalData.gStructurePcd[self.Arch] = S_pcd_set.copy()
+self.FilterStrcturePcd(S_pcd_set)
 for stru_pcd in S_pcd_set.values():
 for skuid in SkuIds:
 if skuid in stru_pcd.SkuOverrideValues:
diff --git a/BaseTools/Source/Python/build/BuildReport.py 
b/BaseTools/Source/Python/build/BuildReport.py
index ae37a6ce0e..4094c9c488 100644
--- a/BaseTools/Source/Python/build/BuildReport.py
+++ b/BaseTools/Source/Python/build/BuildReport.py
@@ -780,6 +780,13 @@ class PcdReport(object):
 # Collect the PCD defined in DSC/FDF file, but not used in module
 #
 UnusedPcdFullList = []
+StructPcdDict = GlobalData.gStructurePcd[self.Arch]
+for Name, Guid in StructPcdDict:
+if (Name, Guid) not in Pa.Platform.Pcds:
+Pcd = StructPcdDict[(Name, Guid)]
+PcdList = self.AllPcds.setdefault(Guid, 
{}).setdefault(Pcd.Type, [])
+if Pcd not in PcdList and Pcd not in UnusedPcdFullList:
+UnusedPcdFullList.append(Pcd)
 for item in Pa.Platform.Pcds:
 Pcd = Pa.Platform.Pcds[item]
 if not Pcd.Type:
-- 
2.14.1.windows.1

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


Re: [edk2] [PATCH 01/14] OvmfPkg/MptScsiDxe: Create empty driver

2019-01-31 Thread Bi, Dandan
Hi Nikita,

I have one comment here, could you help to verify this patch series with VS 
tool chain build before commit the patches?


Thanks,
Dandan

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Nikita Leshenko
> Sent: Thursday, January 31, 2019 6:07 PM
> To: edk2-devel@lists.01.org
> Cc: liran.a...@oracle.com
> Subject: [edk2] [PATCH 01/14] OvmfPkg/MptScsiDxe: Create empty driver
> 
> In preparation for implementing LSI Fusion MPT SCSI devices, create a basic
> scaffolding for a driver.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Nikita Leshenko 
> Reviewed-by: Konrad Rzeszutek Wilk 
> Reviewed-by: Aaron Young 
> Reviewed-by: Liran Alon 
> ---
>  OvmfPkg/MptScsiDxe/MptScsi.c  | 30 
>  OvmfPkg/MptScsiDxe/MptScsiDxe.inf | 33
> +++
>  OvmfPkg/OvmfPkgIa32.dsc   |  1 +
>  OvmfPkg/OvmfPkgIa32.fdf   |  1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc|  1 +
>  OvmfPkg/OvmfPkgIa32X64.fdf|  1 +
>  OvmfPkg/OvmfPkgX64.dsc|  1 +
>  OvmfPkg/OvmfPkgX64.fdf|  1 +
>  8 files changed, 69 insertions(+)
>  create mode 100644 OvmfPkg/MptScsiDxe/MptScsi.c  create mode 100644
> OvmfPkg/MptScsiDxe/MptScsiDxe.inf
> 
> diff --git a/OvmfPkg/MptScsiDxe/MptScsi.c
> b/OvmfPkg/MptScsiDxe/MptScsi.c new file mode 100644 index
> 00..73a693741d
> --- /dev/null
> +++ b/OvmfPkg/MptScsiDxe/MptScsi.c
> @@ -0,0 +1,30 @@
> +/** @file
> +
> +  This driver produces Extended SCSI Pass Thru Protocol instances for
> + LSI Fusion MPT SCSI devices.
> +
> +  Copyright (C) 2018, Oracle and/or its affiliates. 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.
> +
> +**/
> +
> +//
> +// Entry Point
> +//
> +
> +EFI_STATUS
> +EFIAPI
> +MptScsiEntryPoint (
> +  IN EFI_HANDLE   ImageHandle,
> +  IN EFI_SYSTEM_TABLE *SystemTable
> +  )
> +{
> +  return EFI_UNSUPPORTED;
> +}
> diff --git a/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
> b/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
> new file mode 100644
> index 00..c558d78034
> --- /dev/null
> +++ b/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
> @@ -0,0 +1,33 @@
> +## @file
> +# This driver produces Extended SCSI Pass Thru Protocol instances for #
> +LSI Fusion MPT SCSI devices.
> +#
> +# Copyright (C) 2018, Oracle and/or its affiliates. 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.
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x00010005
> +  BASE_NAME  = MptScsiDxe
> +  FILE_GUID  = 2B3DB5DD-B315-4961-8454-0AFF3C811B19
> +  MODULE_TYPE= UEFI_DRIVER
> +  VERSION_STRING = 1.0
> +  ENTRY_POINT= MptScsiEntryPoint
> +
> +[Sources]
> +  MptScsi.c
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  OvmfPkg/OvmfPkg.dec
> +
> +[LibraryClasses]
> +  UefiDriverEntryPoint
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index
> aee19b75d7..52458859b6 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -708,6 +708,7 @@
>OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
>OvmfPkg/XenBusDxe/XenBusDxe.inf
>OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> +  OvmfPkg/MptScsiDxe/MptScsiDxe.inf
>MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
> 
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCoun
> terRuntimeDxe.inf
>MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf index
> e013099136..73e36636e0 100644
> --- a/OvmfPkg/OvmfPkgIa32.fdf
> +++ b/OvmfPkg/OvmfPkgIa32.fdf
> @@ -233,6 +233,7 @@ INF  OvmfPkg/VirtioRngDxe/VirtioRng.inf
>  INF  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
>  INF  OvmfPkg/XenBusDxe/XenBusDxe.inf
>  INF  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> +INF  OvmfPkg/MptScsiDxe/MptScsiDxe.inf
> 
>  !if $(SECURE_BOOT_ENABLE) == TRUE
>INF
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfi
> gDxe.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 90cbd8e341..d8ea2addb2 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ 

[edk2] [PATCH v3 07/12] MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList LockBox

2019-01-31 Thread Hao Wu
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409

For the NvmExpressPei driver, this commit will update the driver to
consume the S3StorageDeviceInitList LockBox in S3 phase. The purpose is to
perform an on-demand (partial) NVM Express device
enumeration/initialization to benefit the S3 resume performance.

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf |   8 +-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h   |  36 +++
 MdeModulePkg/Bus/Pci/NvmExpressPei/DevicePath.c  |  53 +
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c   |  20 
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiS3.c | 114 
 5 files changed, 230 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
index 0666e5892b..22b703e971 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
@@ -40,6 +40,7 @@
   NvmExpressPeiHci.h
   NvmExpressPeiPassThru.c
   NvmExpressPeiPassThru.h
+  NvmExpressPeiS3.c
   NvmExpressPeiStorageSecurity.c
   NvmExpressPeiStorageSecurity.h
 
@@ -54,6 +55,7 @@
   BaseMemoryLib
   IoLib
   TimerLib
+  LockBoxLib
   PeimEntryPoint
 
 [Ppis]
@@ -64,9 +66,13 @@
   gEfiPeiVirtualBlockIo2PpiGuid  ## SOMETIMES_PRODUCES
   gEdkiiPeiStorageSecurityCommandPpiGuid ## SOMETIMES_PRODUCES
 
+[Guids]
+  gS3StorageDeviceInitListGuid   ## SOMETIMES_CONSUMES ## 
UNDEFINED
+
 [Depex]
   gEfiPeiMemoryDiscoveredPpiGuid AND
-  gEdkiiPeiNvmExpressHostControllerPpiGuid
+  gEdkiiPeiNvmExpressHostControllerPpiGuid AND
+  gEfiPeiMasterBootModePpiGuid
 
 [UserExtensions.TianoCore."ExtraFiles"]
   NvmExpressPeiExtra.uni
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
index 92c3854c6e..e2a693abe8 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
@@ -267,6 +267,26 @@ NvmePeimEndOfPei (
   );
 
 /**
+  Get the size of the current device path instance.
+
+  @param[in]  DevicePath A pointer to the EFI_DEVICE_PATH_PROTOCOL
+ structure.
+  @param[out] InstanceSize   The size of the current device path 
instance.
+  @param[out] EntireDevicePathEndIndicate whether the instance is the last
+ one in the device path strucure.
+
+  @retval EFI_SUCCESSThe size of the current device path instance is 
fetched.
+  @retval Others Fails to get the size of the current device path 
instance.
+
+**/
+EFI_STATUS
+GetDevicePathInstanceSize (
+  IN  EFI_DEVICE_PATH_PROTOCOL*DevicePath,
+  OUT UINTN   *InstanceSize,
+  OUT BOOLEAN *EntireDevicePathEnd
+  );
+
+/**
   Check the validity of the device path of a NVM Express host controller.
 
   @param[in] DevicePath  A pointer to the EFI_DEVICE_PATH_PROTOCOL
@@ -309,4 +329,20 @@ NvmeBuildDevicePath (
   OUT EFI_DEVICE_PATH_PROTOCOL**DevicePath
   );
 
+/**
+  Determine if a specific NVM Express controller can be skipped for S3 phase.
+
+  @param[in]  HcDevicePath  Device path of the controller.
+  @param[in]  HcDevicePathLengthLength of the device path specified by
+HcDevicePath.
+
+  @retvalThe number of ports that need to be enumerated.
+
+**/
+BOOLEAN
+NvmeS3SkipThisController (
+  IN  EFI_DEVICE_PATH_PROTOCOL*HcDevicePath,
+  IN  UINTN   HcDevicePathLength
+  );
+
 #endif
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/DevicePath.c 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/DevicePath.c
index 5dab447f09..ed05d7a2be 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/DevicePath.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/DevicePath.c
@@ -89,6 +89,59 @@ NextDevicePathNode (
 }
 
 /**
+  Get the size of the current device path instance.
+
+  @param[in]  DevicePath A pointer to the EFI_DEVICE_PATH_PROTOCOL
+ structure.
+  @param[out] InstanceSize   The size of the current device path 
instance.
+  @param[out] EntireDevicePathEndIndicate whether the instance is the last
+ one in the device path strucure.
+
+  @retval EFI_SUCCESSThe size of the current device path instance is 
fetched.
+  @retval Others Fails to get the size of the current device path 
instance.
+
+**/
+EFI_STATUS
+GetDevicePathInstanceSize (
+  IN  EFI_DEVICE_PATH_PROTOCOL*DevicePath,
+  OUT UINTN   *InstanceSize,
+  OUT BOOLEAN *EntireDevicePathEnd
+  )
+{
+  EFI_DEVICE_PATH_PROTOCOL*Walker;
+
+  if (DevicePath == NULL || InstanceSize == 

[edk2] [PATCH v3 06/12] MdeModulePkg/NvmExpressPei: Add logic to produce SSC PPI

2019-01-31 Thread Hao Wu
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409

For the NvmExpressPei driver, this commit will add codes to produce the
Storage Security Command PPI if the underlying NVM Express controller
supports the Security Send and Security Receive commands.

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf  |  10 +-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h|  58 ++-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiHci.h |  20 +-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiStorageSecurity.h | 247 

 MdeModulePkg/Bus/Pci/NvmExpressPei/DevicePath.c   | 231 
+++
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c| 143 +--
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiHci.c |  32 +-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPeiStorageSecurity.c | 423 

 8 files changed, 1075 insertions(+), 89 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
index 9591572fec..0666e5892b 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf
@@ -2,7 +2,7 @@
 #  The NvmExpressPei driver is used to manage non-volatile memory subsystem
 #  which follows NVM Express specification at PEI phase.
 #
-#  Copyright (c) 2018, Intel Corporation. All rights reserved.
+#  Copyright (c) 2018 - 2019, Intel Corporation. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -30,6 +30,7 @@
 #
 
 [Sources]
+  DevicePath.c
   DmaMem.c
   NvmExpressPei.c
   NvmExpressPei.h
@@ -39,6 +40,8 @@
   NvmExpressPeiHci.h
   NvmExpressPeiPassThru.c
   NvmExpressPeiPassThru.h
+  NvmExpressPeiStorageSecurity.c
+  NvmExpressPeiStorageSecurity.h
 
 [Packages]
   MdePkg/MdePkg.dec
@@ -54,11 +57,12 @@
   PeimEntryPoint
 
 [Ppis]
-  gEfiPeiVirtualBlockIoPpiGuid   ## PRODUCES
-  gEfiPeiVirtualBlockIo2PpiGuid  ## PRODUCES
   gEdkiiPeiNvmExpressHostControllerPpiGuid   ## CONSUMES
   gEdkiiIoMmuPpiGuid ## CONSUMES
   gEfiEndOfPeiSignalPpiGuid  ## CONSUMES
+  gEfiPeiVirtualBlockIoPpiGuid   ## SOMETIMES_PRODUCES
+  gEfiPeiVirtualBlockIo2PpiGuid  ## SOMETIMES_PRODUCES
+  gEdkiiPeiStorageSecurityCommandPpiGuid ## SOMETIMES_PRODUCES
 
 [Depex]
   gEfiPeiMemoryDiscoveredPpiGuid AND
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
index 0135eca6f0..92c3854c6e 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -44,6 +45,7 @@ typedef struct _PEI_NVME_CONTROLLER_PRIVATE_DATA  
PEI_NVME_CONTROLLER_PRIVATE_DA
 #include "NvmExpressPeiHci.h"
 #include "NvmExpressPeiPassThru.h"
 #include "NvmExpressPeiBlockIo.h"
+#include "NvmExpressPeiStorageSecurity.h"
 
 //
 // NVME PEI driver implementation related definitions
@@ -90,10 +92,15 @@ struct _PEI_NVME_NAMESPACE_INFO {
 struct _PEI_NVME_CONTROLLER_PRIVATE_DATA {
   UINT32Signature;
   UINTN MmioBase;
+  UINTN DevicePathLength;
+  EFI_DEVICE_PATH_PROTOCOL  *DevicePath;
+
   EFI_PEI_RECOVERY_BLOCK_IO_PPI BlkIoPpi;
   EFI_PEI_RECOVERY_BLOCK_IO2_PPIBlkIo2Ppi;
+  EDKII_PEI_STORAGE_SECURITY_CMD_PPIStorageSecurityPpi;
   EFI_PEI_PPI_DESCRIPTORBlkIoPpiList;
   EFI_PEI_PPI_DESCRIPTORBlkIo2PpiList;
+  EFI_PEI_PPI_DESCRIPTORStorageSecurityPpiList;
   EFI_PEI_NOTIFY_DESCRIPTOR EndOfPeiNotifyList;
 
   //
@@ -139,11 +146,13 @@ struct _PEI_NVME_CONTROLLER_PRIVATE_DATA {
   PEI_NVME_NAMESPACE_INFO   *NamespaceInfo;
 };
 
-#define GET_NVME_PEIM_HC_PRIVATE_DATA_FROM_THIS_BLKIO(a) \
+#define GET_NVME_PEIM_HC_PRIVATE_DATA_FROM_THIS_BLKIO(a)   \
   CR (a, PEI_NVME_CONTROLLER_PRIVATE_DATA, BlkIoPpi, 
NVME_PEI_CONTROLLER_PRIVATE_DATA_SIGNATURE)
-#define GET_NVME_PEIM_HC_PRIVATE_DATA_FROM_THIS_BLKIO2(a)\
+#define GET_NVME_PEIM_HC_PRIVATE_DATA_FROM_THIS_BLKIO2(a)  \
   CR (a, PEI_NVME_CONTROLLER_PRIVATE_DATA, BlkIo2Ppi, 
NVME_PEI_CONTROLLER_PRIVATE_DATA_SIGNATURE)
-#define GET_NVME_PEIM_HC_PRIVATE_DATA_FROM_THIS_NOTIFY(a)\
+#define GET_NVME_PEIM_HC_PRIVATE_DATA_FROM_THIS_STROAGE_SECURITY(a)\
+  CR (a, PEI_NVME_CONTROLLER_PRIVATE_DATA, StorageSecurityPpi, 

[edk2] [PATCH v3 03/12] MdeModulePkg: Add definitions for Storage Security Command PPI

2019-01-31 Thread Hao Wu
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409

This commit will add the definitions for Storage Security Command (SSC)
PPI. This PPI will be be used to abstract mass storage devices to allow
code running in the PEI phase to send security protocol commands to mass
storage devices without specific knowledge of the type of device or
controller that manages the device.

More specifically, the PPI will provide services to:

* Get the number of mass storage devices managed by a instance of the SSC
  PPI (by service 'GetNumberofDevices');
* Get the identification information (DevicePath) of a managing mass
  storage devices (by service 'GetDevicePath');
* Send security protocol commands to mass storage devices (by services
  'ReceiveData' and 'SendData').

Cc: Jian J Wang 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Ray Ni 
---
 MdeModulePkg/MdeModulePkg.dec |   3 +
 MdeModulePkg/Include/Ppi/StorageSecurityCommand.h | 283 
 2 files changed, 286 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 8efb19e626..7f646d7702 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -483,6 +483,9 @@
   ## Include/Ppi/AtaAhciController.h
   gEdkiiPeiAtaAhciHostControllerPpiGuid = { 0x61dd33ea, 0x421f, 0x4cc0, { 
0x89, 0x29, 0xff, 0xee, 0xa9, 0xa1, 0xa2, 0x61 } }
 
+  ## Include/Ppi/StorageSecurityCommand.h
+  gEdkiiPeiStorageSecurityCommandPpiGuid= { 0x35de0b4e, 0x30fb, 0x46c3, { 
0xbd, 0x84, 0x1f, 0xdb, 0xa1, 0x58, 0xbb, 0x56 } }
+
   ## Include/Ppi/AtaPassThru.h
   gEdkiiPeiAtaPassThruPpiGuid   = { 0xa16473fd, 0xd474, 0x4c89, { 
0xae, 0xc7, 0x90, 0xb8, 0x3c, 0x73, 0x86, 0x9  } }
 
diff --git a/MdeModulePkg/Include/Ppi/StorageSecurityCommand.h 
b/MdeModulePkg/Include/Ppi/StorageSecurityCommand.h
new file mode 100644
index 00..cc1688dabb
--- /dev/null
+++ b/MdeModulePkg/Include/Ppi/StorageSecurityCommand.h
@@ -0,0 +1,283 @@
+/** @file
+
+  Copyright (c) 2019, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef _EDKII_STORAGE_SECURITY_COMMAND_PPI_H_
+#define _EDKII_STORAGE_SECURITY_COMMAND_PPI_H_
+
+#include 
+
+///
+/// Global ID for the EDKII_PEI_STORAGE_SECURITY_CMD_PPI.
+///
+#define EDKII_PEI_STORAGE_SECURITY_CMD_PPI_GUID \
+  { \
+0x35de0b4e, 0x30fb, 0x46c3, { 0xbd, 0x84, 0x1f, 0xdb, 0xa1, 0x58, 0xbb, 
0x56 } \
+  }
+
+//
+// Forward declaration for the EDKII_PEI_STORAGE_SECURITY_CMD_PPI.
+//
+typedef struct _EDKII_PEI_STORAGE_SECURITY_CMD_PPI  
EDKII_PEI_STORAGE_SECURITY_CMD_PPI;
+
+//
+// Revision The revision to which the Storage Security Command interface 
adheres.
+//  All future revisions must be backwards compatible.
+//  If a future version is not back wards compatible it is not the 
same GUID.
+//
+#define EDKII_STORAGE_SECURITY_PPI_REVISION  0x0001
+
+
+/**
+  Gets the count of storage security devices that one specific driver detects.
+
+  @param[in]  This   The PPI instance pointer.
+  @param[out] NumberofDevicesThe number of storage security devices 
discovered.
+
+  @retval EFI_SUCCESS  The operation performed successfully.
+  @retval EFI_INVALID_PARAMETERThe parameters are invalid.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EDKII_PEI_STORAGE_SECURITY_GET_NUMBER_DEVICES) (
+  IN  EDKII_PEI_STORAGE_SECURITY_CMD_PPI*This,
+  OUT UINTN *NumberofDevices
+  );
+
+/**
+  Gets the device path of a specific storage security device.
+
+  @param[in]  This The PPI instance pointer.
+  @param[in]  DeviceIndex  Specifies the storage security device to 
which
+   the function wants to talk. Because the 
driver
+   that implements Storage Security Command 
PPIs
+   will manage multiple storage devices, the 
PPIs
+   that want to talk to a single device must 
specify
+   the device index that was assigned during 
the
+   enumeration process. This index is a number 
from
+   one to NumberofDevices.
+  @param[out] DevicePathLength The length of the device path in bytes 
specified
+   by DevicePath.
+  @param[out] DevicePath   The device path of storage security device.
+   This field 

[edk2] [PATCH v3 04/12] MdeModulePkg: Add GUID for LockBox to save storage dev to init in S3

2019-01-31 Thread Hao Wu
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409

This commit will add the GUID definitions for LockBox which is used to
save a list of storage devices that need to get initialized during the S3
resume.

The content of the LockBox will be a DevicePath structure that contains
zero or more DevicePath instances. Each instance denotes a storage device
that needs to get initialized during the S3 resume.

The producers of the content of this LockBox will be drivers like
OpalPassword DXE driver. This kind of drivers requires some specific
storage devices to be initialized during the PEI phase of in S3 resume.
(For the OpalPasword case, it requires the managing devices to be
automatically unlocked during the S3 resume).

The attribute of the LockBox should be set to
LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY.

The consumers of the content of this LockBox will be PEI storage device
controller/bus drivers (e.g. NvmExpressPei) during S3 resume. This kind of
drivers can use the DevicePath instances stored in the LockBox to get a
list of devices that need to get initialized. In such way, an on-demand
(partial) device enumeration/initialization can be performed to benefit
the S3 resume performance.

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/MdeModulePkg.dec   |  3 +
 MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h | 64 
 2 files changed, 67 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 7f646d7702..a2130bc439 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -422,6 +422,9 @@
   ## Include/Guid/S3SmmInitDone.h
   gEdkiiS3SmmInitDoneGuid = { 0x8f9d4825, 0x797d, 0x48fc, { 0x84, 0x71, 0x84, 
0x50, 0x25, 0x79, 0x2e, 0xf6 } }
 
+  ## Include/Guid/S3StorageDeviceInitList.h
+  gS3StorageDeviceInitListGuid = { 0x310e9b8c, 0xcf90, 0x421e, { 0x8e, 0x9b, 
0x9e, 0xef, 0xb6, 0x17, 0xc8, 0xef } }
+
 [Ppis]
   ## Include/Ppi/AtaController.h
   gPeiAtaControllerPpiGuid   = { 0xa45e60d1, 0xc719, 0x44aa, { 0xb0, 0x7a, 
0xaa, 0x77, 0x7f, 0x85, 0x90, 0x6d }}
diff --git a/MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h 
b/MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h
new file mode 100644
index 00..bd300b2696
--- /dev/null
+++ b/MdeModulePkg/Include/Guid/S3StorageDeviceInitList.h
@@ -0,0 +1,64 @@
+/** @file
+  Define the LockBox GUID for list of storage devices need to be initialized in
+  S3.
+
+  Copyright (c) 2019, Intel Corporation. All rights reserved.
+
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions
+  of the BSD License which accompanies this distribution.  The
+  full text of the license may be found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef __S3_STORAGE_DEVICE_INIT_LIST_H__
+#define __S3_STORAGE_DEVICE_INIT_LIST_H__
+
+#define S3_STORAGE_DEVICE_INIT_LIST \
+  { \
+0x310e9b8c, 0xcf90, 0x421e, { 0x8e, 0x9b, 0x9e, 0xef, 0xb6, 0x17, 0xc8, 
0xef } \
+  }
+
+//
+// The LockBox will store a DevicePath structure that contains one or more
+// DevicePath instances. Each instance denotes a storage device that needs to
+// get initialized during the S3 resume.
+//
+// For example, if there is only one storage device stored in the list, the
+// content of this LockBox will be:
+//
+// +---+
+// | DevPath Instance #1   |
+// | (Terminated by an End of Hardware Device Path node|
+// |  with an End Entire Device Path sub-type) |
+// +---+
+//
+// If there are n (n > 1) storage devices in the list, the content of this
+// LockBox will be:
+//
+// +---+
+// | DevPath Instance #1   |
+// | (Terminated by an End of Hardware Device Path node|
+// |  with an End This Instance of a Device Path sub-type) |
+// +---+
+// | DevPath Instance #2   |
+// | (Terminated by an End of Hardware Device Path node|
+// |  with an End This Instance of a Device Path sub-type) |
+// +---+
+// |...|
+// +---+
+// | DevPath Instance #n   |
+// | (Terminated by an End of Hardware Device Path node|
+// |  with an End Entire Device Path sub-type) |
+// +---+
+//
+// The attribute of the LockBox should be set to

[edk2] [PATCH v3 05/12] MdeModulePkg/NvmExpressPei: Avoid updating the module-level variable

2019-01-31 Thread Hao Wu
This commit is out of the scope for BZ-1409. The commit will remove the
call of RegisterForShadow() at the entry point of the driver. By doing so,
the driver is now possible to be executed without being re-loaded into
permanent memory.

Thus, this commit will update the NvmExpressPei driver to avoid updating
the content of a global variable.

Cc: Jian J Wang 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Ray Ni 
---
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h |  12 +-
 MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c| 153 +++-
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.c |  11 +-
 3 files changed, 92 insertions(+), 84 deletions(-)

diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
index 0bd62c2459..0135eca6f0 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.h
@@ -2,7 +2,7 @@
   The NvmExpressPei driver is used to manage non-volatile memory subsystem
   which follows NVM Express specification at PEI phase.
 
-  Copyright (c) 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2018 - 2019, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions
@@ -147,13 +147,9 @@ struct _PEI_NVME_CONTROLLER_PRIVATE_DATA {
   CR (a, PEI_NVME_CONTROLLER_PRIVATE_DATA, EndOfPeiNotifyList, 
NVME_PEI_CONTROLLER_PRIVATE_DATA_SIGNATURE)
 
 
-/**
-  Initialize IOMMU.
-**/
-VOID
-IoMmuInit (
-  VOID
-  );
+//
+// Internal functions
+//
 
 /**
   Allocates pages that are suitable for an OperationBusMasterCommonBuffer or
diff --git a/MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c 
b/MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c
index 51b48d38dd..cb629c16b0 100644
--- a/MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c
+++ b/MdeModulePkg/Bus/Pci/NvmExpressPei/DmaMem.c
@@ -1,7 +1,7 @@
 /** @file
   The DMA memory help function.
 
-  Copyright (c) 2018, Intel Corporation. All rights reserved.
+  Copyright (c) 2018 - 2019, Intel Corporation. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions
@@ -16,7 +16,33 @@
 
 #include "NvmExpressPei.h"
 
-EDKII_IOMMU_PPI  *mIoMmu;
+/**
+  Get IOMMU PPI.
+
+  @return Pointer to IOMMU PPI.
+
+**/
+EDKII_IOMMU_PPI *
+GetIoMmu (
+  VOID
+  )
+{
+  EFI_STATUS Status;
+  EDKII_IOMMU_PPI*IoMmu;
+
+  IoMmu  = NULL;
+  Status = PeiServicesLocatePpi (
+ ,
+ 0,
+ NULL,
+ (VOID **) 
+ );
+  if (!EFI_ERROR (Status) && (IoMmu != NULL)) {
+return IoMmu;
+  }
+
+  return NULL;
+}
 
 /**
   Provides the controller-specific addresses required to access system memory 
from a
@@ -46,18 +72,21 @@ IoMmuMap (
   OUT VOID  **Mapping
   )
 {
-  EFI_STATUS  Status;
-  UINT64  Attribute;
-
-  if (mIoMmu != NULL) {
-Status = mIoMmu->Map (
-   mIoMmu,
-   Operation,
-   HostAddress,
-   NumberOfBytes,
-   DeviceAddress,
-   Mapping
-   );
+  EFI_STATUS Status;
+  UINT64 Attribute;
+  EDKII_IOMMU_PPI*IoMmu;
+
+  IoMmu = GetIoMmu ();
+
+  if (IoMmu != NULL) {
+Status = IoMmu->Map (
+ IoMmu,
+ Operation,
+ HostAddress,
+ NumberOfBytes,
+ DeviceAddress,
+ Mapping
+ );
 if (EFI_ERROR (Status)) {
   return EFI_OUT_OF_RESOURCES;
 }
@@ -78,11 +107,11 @@ IoMmuMap (
   ASSERT(FALSE);
   return EFI_INVALID_PARAMETER;
 }
-Status = mIoMmu->SetAttribute (
-   mIoMmu,
-   *Mapping,
-   Attribute
-   );
+Status = IoMmu->SetAttribute (
+  IoMmu,
+  *Mapping,
+  Attribute
+  );
 if (EFI_ERROR (Status)) {
   return Status;
 }
@@ -108,11 +137,14 @@ IoMmuUnmap (
   IN VOID  *Mapping
   )
 {
-  EFI_STATUS  Status;
+  EFI_STATUS Status;
+  EDKII_IOMMU_PPI*IoMmu;
+
+  IoMmu = GetIoMmu ();
 
-  if (mIoMmu != NULL) {
-Status = mIoMmu->SetAttribute (mIoMmu, Mapping, 0);
-Status = mIoMmu->Unmap (mIoMmu, Mapping);
+  if (IoMmu != NULL) {
+Status = IoMmu->SetAttribute (IoMmu, Mapping, 0);
+Status = IoMmu->Unmap (IoMmu, Mapping);
   } else {
 Status = EFI_SUCCESS;
   }
@@ -148,39 +180,42 @@ IoMmuAllocateBuffer (
   EFI_STATUSStatus;
   UINTN NumberOfBytes;
   EFI_PHYSICAL_ADDRESS  HostPhyAddress;
+  EDKII_IOMMU_PPI   *IoMmu;
 
   *HostAddress = NULL;
   *DeviceAddress = 0;
 
-  if 

[edk2] [PATCH v3 02/12] MdeModulePkg: Add definitions for EDKII PEI ATA PassThru PPI

2019-01-31 Thread Hao Wu
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409

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

More specifically, the PPI will provide services to:

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

Cc: Jian J Wang 
Cc: Ruiyu Ni 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/MdeModulePkg.dec  |   3 +
 MdeModulePkg/Include/Ppi/AtaPassThru.h | 219 
 2 files changed, 222 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index 4411185073..8efb19e626 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -483,6 +483,9 @@
   ## Include/Ppi/AtaAhciController.h
   gEdkiiPeiAtaAhciHostControllerPpiGuid = { 0x61dd33ea, 0x421f, 0x4cc0, { 
0x89, 0x29, 0xff, 0xee, 0xa9, 0xa1, 0xa2, 0x61 } }
 
+  ## Include/Ppi/AtaPassThru.h
+  gEdkiiPeiAtaPassThruPpiGuid   = { 0xa16473fd, 0xd474, 0x4c89, { 
0xae, 0xc7, 0x90, 0xb8, 0x3c, 0x73, 0x86, 0x9  } }
+
 [Protocols]
   ## Load File protocol provides capability to load and unload EFI image into 
memory and execute it.
   #  Include/Protocol/LoadPe32Image.h
diff --git a/MdeModulePkg/Include/Ppi/AtaPassThru.h 
b/MdeModulePkg/Include/Ppi/AtaPassThru.h
new file mode 100644
index 00..78bdaef9e2
--- /dev/null
+++ b/MdeModulePkg/Include/Ppi/AtaPassThru.h
@@ -0,0 +1,219 @@
+/** @file
+
+  Copyright (c) 2019, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef _EDKII_ATA_PASS_THRU_PPI_H_
+#define _EDKII_ATA_PASS_THRU_PPI_H_
+
+#include 
+#include 
+
+///
+/// Global ID for the EDKII_PEI_ATA_PASS_THRU_PPI.
+///
+#define EDKII_PEI_ATA_PASS_THRU_PPI_GUID \
+  { \
+0xa16473fd, 0xd474, 0x4c89, { 0xae, 0xc7, 0x90, 0xb8, 0x3c, 0x73, 0x86, 
0x9 } \
+  }
+
+//
+// Forward declaration for the EDKII_PEI_ATA_PASS_THRU_PPI.
+//
+typedef struct _EDKII_PEI_ATA_PASS_THRU_PPI  EDKII_PEI_ATA_PASS_THRU_PPI;
+
+//
+// Revision The revision to which the ATA Pass Thru PPI interface adheres.
+//  All future revisions must be backwards compatible.
+//  If a future version is not back wards compatible it is not the 
same GUID.
+//
+#define EDKII_PEI_ATA_PASS_THRU_PPI_REVISION0x0001
+
+
+/**
+  Sends an ATA command to an ATA device that is attached to the ATA controller.
+
+  @param[in] This  The PPI instance pointer.
+  @param[in] Port  The port number of the ATA device to 
send
+   the command.
+  @param[in] PortMultiplierPortThe port multiplier port number of the 
ATA
+   device to send the command.
+   If there is no port multiplier, then 
specify
+   0x.
+  @param[in,out] PacketA pointer to the ATA command to send to
+   the ATA device specified by Port and
+   PortMultiplierPort.
+
+  @retval EFI_SUCCESS  The ATA command was sent by the host. For
+   bi-directional commands, InTransferLength 
bytes
+   were transferred from InDataBuffer. For 
write
+   and bi-directional commands, 
OutTransferLength
+   bytes were transferred by OutDataBuffer.
+  @retval EFI_NOT_FOUNDThe specified ATA device is not found.
+  @retval EFI_INVALID_PARAMETERThe contents of Acb are invalid. The ATA 
command
+   was not sent, so no additional status 
information
+   is available.
+  @retval EFI_BAD_BUFFER_SIZE  The ATA command was not executed. The number
+   of bytes that could be transferred is 
returned
+   in InTransferLength. For write and 
bi-directional
+   commands, OutTransferLength bytes were 
transferred
+   by OutDataBuffer.
+  @retval EFI_NOT_READYThe ATA 

[edk2] [PATCH v3 01/12] MdeModulePkg: Add definitions for ATA AHCI host controller PPI

2019-01-31 Thread Hao Wu
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409

This commit will add the definitions for ATA AHCI host controller PPI. The
purpose of the PPI in to provide:

* MMIO base address
* Controller identification information (DevicePath)

for ATA host controllers working under AHCI mode.

Cc: Jian J Wang 
Cc: Eric Dong 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Ray Ni 
---
 MdeModulePkg/MdeModulePkg.dec|  3 +
 MdeModulePkg/Include/Ppi/AtaAhciController.h | 89 
 2 files changed, 92 insertions(+)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec
index e5c32d15ed..4411185073 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -480,6 +480,9 @@
   ## Include/Ppi/NvmExpressHostController.h
   gEdkiiPeiNvmExpressHostControllerPpiGuid  = { 0xcae3aa63, 0x676f, 0x4da3, { 
0xbd, 0x50, 0x6c, 0xc5, 0xed, 0xde, 0x9a, 0xad } }
 
+  ## Include/Ppi/AtaAhciController.h
+  gEdkiiPeiAtaAhciHostControllerPpiGuid = { 0x61dd33ea, 0x421f, 0x4cc0, { 
0x89, 0x29, 0xff, 0xee, 0xa9, 0xa1, 0xa2, 0x61 } }
+
 [Protocols]
   ## Load File protocol provides capability to load and unload EFI image into 
memory and execute it.
   #  Include/Protocol/LoadPe32Image.h
diff --git a/MdeModulePkg/Include/Ppi/AtaAhciController.h 
b/MdeModulePkg/Include/Ppi/AtaAhciController.h
new file mode 100644
index 00..2bdd53ff36
--- /dev/null
+++ b/MdeModulePkg/Include/Ppi/AtaAhciController.h
@@ -0,0 +1,89 @@
+/** @file
+
+  Copyright (c) 2019, Intel Corporation. All rights reserved.
+  This program and the accompanying materials
+  are licensed and made available under the terms and conditions of the BSD 
License
+  which accompanies this distribution.  The full text of the license may be 
found at
+  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+
+**/
+
+#ifndef _EDKII_ATA_AHCI_HOST_CONTROLLER_PPI_H_
+#define _EDKII_ATA_AHCI_HOST_CONTROLLER_PPI_H_
+
+#include 
+
+///
+/// Global ID for the EDKII_ATA_AHCI_HOST_CONTROLLER_PPI.
+///
+#define EDKII_ATA_AHCI_HOST_CONTROLLER_PPI_GUID \
+  { \
+0x61dd33ea, 0x421f, 0x4cc0, { 0x89, 0x29, 0xff, 0xee, 0xa9, 0xa1, 0xa2, 
0x61 } \
+  }
+
+//
+// Forward declaration for the EDKII_ATA_AHCI_HOST_CONTROLLER_PPI.
+//
+typedef struct _EDKII_ATA_AHCI_HOST_CONTROLLER_PPI  
EDKII_ATA_AHCI_HOST_CONTROLLER_PPI;
+
+/**
+  Get the MMIO base address of ATA AHCI host controller.
+
+  @param[in]  This The PPI instance pointer.
+  @param[in]  ControllerId The ID of the ATA AHCI host controller.
+  @param[out] MmioBar  The MMIO base address of the controller.
+
+  @retval EFI_SUCCESS  The operation succeeds.
+  @retval EFI_INVALID_PARAMETERThe parameters are invalid.
+  @retval EFI_NOT_FOUNDThe specified ATA AHCI host controller not 
found.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EDKII_ATA_AHCI_HC_GET_MMIO_BAR) (
+  IN  EDKII_ATA_AHCI_HOST_CONTROLLER_PPI*This,
+  IN  UINT8 ControllerId,
+  OUT UINTN *MmioBar
+  );
+
+/**
+  Get the device path of ATA AHCI host controller.
+
+  @param[in]  This The PPI instance pointer.
+  @param[in]  ControllerId The ID of the ATA AHCI host controller.
+  @param[out] DevicePathLength The length of the device path in bytes 
specified
+   by DevicePath.
+  @param[out] DevicePath   The device path of ATA AHCI host controller.
+   This field re-uses EFI Device Path Protocol 
as
+   defined by Section 10.2 EFI Device Path 
Protocol
+   of UEFI 2.7 Specification.
+
+  @retval EFI_SUCCESS  The operation succeeds.
+  @retval EFI_INVALID_PARAMETERThe parameters are invalid.
+  @retval EFI_NOT_FOUNDThe specified ATA AHCI host controller not 
found.
+  @retval EFI_OUT_OF_RESOURCES The operation fails due to lack of 
resources.
+
+**/
+typedef
+EFI_STATUS
+(EFIAPI *EDKII_ATA_AHCI_HC_GET_DEVICE_PATH) (
+  IN  EDKII_ATA_AHCI_HOST_CONTROLLER_PPI*This,
+  IN  UINT8 ControllerId,
+  OUT UINTN *DevicePathLength,
+  OUT EFI_DEVICE_PATH_PROTOCOL  **DevicePath
+  );
+
+//
+// This PPI contains a set of services to interact with the ATA AHCI host 
controller.
+//
+struct _EDKII_ATA_AHCI_HOST_CONTROLLER_PPI {
+  EDKII_ATA_AHCI_HC_GET_MMIO_BAR   GetAhciHcMmioBar;
+  EDKII_ATA_AHCI_HC_GET_DEVICE_PATHGetAhciHcDevicePath;
+};
+
+extern EFI_GUID gEdkiiPeiAtaAhciHostControllerPpiGuid;
+
+#endif
-- 
2.12.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org

[edk2] [PATCH v3 00/12] Split the S3 PEI phase HW init codes from Opal driver

2019-01-31 Thread Hao Wu
The series is also available at:
https://github.com/hwu25/edk2/tree/opal_remodel_v3

V3 changes:

For patch 2, reuse the definitions within AtaPassThru protocol header file
to reduce code duplication.

For patch 4, add detailed comments to illustrate the content that will be
stored in the newly introduced LockBox.

For patch 6, device path validity check refinement within function
NvmeCheckHcDevicePath().

For patch 7:
* Remove a redundant check within function NvmeS3SkipThisController();
* Replace internal implementation of GetNextDevicePathInstance() with
  GetDevicePathInstanceSize(), which avoids unnecessary memory allocation.

For patch 8:
* Device path validity check refinement within function
  AhciCheckHcDevicePath();
* Remove a redundant check within function AhciS3GetEumeratePorts();
* Replace internal implementation of GetNextDevicePathInstance() with
  GetDevicePathInstanceSize(), which avoids unnecessary memory allocation.

For patch 11:
* Remove the ASSERT() for memory allocation failure. Since error handling
  codes already exist, no new code is added for this;
* Refine the codes to only allocate new SMM buffer when the required
  LockBox size is greater than the size of origin pages allocated;
* Add additional parameter check for 'Offset' & 'Length' to prevent
  potential numeric overflow.


V2 history:

For patch 8, the new series removes the codes to produce the Block IO PPIs
from the AhciPei driver.

The task to produce the Block IO services is out of the scope of BZ-1409
(actually covered by BZ-1483). And we will later propose seperate patch(s)
to address this.

V1 history:

For the below 2 types of storage device:

1. NVM Express devices;
2. ATA hard disk devices working under AHCI mode.

the OpalPassword driver supports auto-unlocking those devices during S3
resume.

Current implementation of the OpalPassword driver is handling the device
initialization (using boot script to restore the host controller PCI
configuration space also counts) in the PEI phase during S3 resume by
itself.

Meanwhile, the NvmExpressPei driver in MdeModulePkg also handles the NVME
device initialization during the PEI phase in order to produce the Block
IO PPI.

Moreover, there is a Bugzilla request (BZ-1483) for adding the Block IO
PPI support for ATA device as well. So there is likely to be an PEI driver
for ATA device that will handle the ATA device initialization.

In order to remove code duplication, the series will split the S3 phase
device initialization related codes out from the OpalPassword driver. And
let the existing NvmExpressPei driver and the new AhciPei driver to handle
the task.

After this remodel, NvmExpressPei and AhciPei drivers will produce a PPI
called Storage Security Command PPI. And the OpalPassword driver will
consume this PPI to perform the device auto-unlock in S3 resume.


Patch   1~4: Add the definitions of PPIs and GUIDs;
Patch 5: Refinement for the NvmExpressPei driver;
Patch   6~7: Update the NvmExpressPei driver to produce the PPI needed by
 OpalPassword;
Patch 8: Add the Ahci mode ATA device support in the PEI phase, it
 will produce the PPI needed by OpalPassword;
Patch  9~10: Refinements for the SmmLockBoxLib;
Patch11: Support LockBox enlarge for LockBoxLib API UpdateLockBox();
Patch12: Remove the hardware initialization codes from the
 OpalPassword driver. And consume the SSC PPI to unlock device
 in S3 resume.

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Eric Dong 
Cc: Star Zeng 
Cc: Chao Zhang 
Cc: Jiewen Yao 

Hao Wu (12):
  MdeModulePkg: Add definitions for ATA AHCI host controller PPI
  MdeModulePkg: Add definitions for EDKII PEI ATA PassThru PPI
  MdeModulePkg: Add definitions for Storage Security Command PPI
  MdeModulePkg: Add GUID for LockBox to save storage dev to init in S3
  MdeModulePkg/NvmExpressPei: Avoid updating the module-level variable
  MdeModulePkg/NvmExpressPei: Add logic to produce SSC PPI
  MdeModulePkg/NvmExpressPei: Consume S3StorageDeviceInitList LockBox
  MdeModulePkg/AhciPei: Add AHCI mode ATA device support in PEI
  MdeModulePkg/SmmLockBoxLib: Use 'DEBUG_' prefix instead of 'EFI_D_'
  MdeModulePkg/SmmLockBox(PEI): Remove an ASSERT in RestoreLockBox()
  MdeModulePkg/SmmLockBoxLib: Support LockBox enlarge in UpdateLockBox()
  SecurityPkg/OpalPassword: Remove HW init codes and consume SSC PPI

 MdeModulePkg/MdeModulePkg.dec |   12 +
 MdeModulePkg/MdeModulePkg.dsc |1 +
 MdeModulePkg/Bus/Ata/AhciPei/AhciPei.inf  |   74 +
 MdeModulePkg/Bus/Pci/NvmExpressPei/NvmExpressPei.inf  |   18 +-
 SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordDxe.inf |6 +-
 SecurityPkg/Tcg/Opal/OpalPassword/OpalPasswordPei.inf |   12 +-
 MdeModulePkg/Bus/Ata/AhciPei/AhciPei.h|  708 
+++
 MdeModulePkg/Bus/Ata/AhciPei/AhciPeiPassThru.h| 

[edk2] [PATCH] EmbeddedPkg/PrePiLib: Correct function name

2019-01-31 Thread Jeff Brasen
Update header file function name for FfsFindFileByName to match
implementation function name.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jeff Brasen 
Cc: Leif Lindholm 
Cc: Ard Biesheuvel 
---
 EmbeddedPkg/Include/Library/PrePiLib.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/EmbeddedPkg/Include/Library/PrePiLib.h 
b/EmbeddedPkg/Include/Library/PrePiLib.h
index a857308..92fbc24 100644
--- a/EmbeddedPkg/Include/Library/PrePiLib.h
+++ b/EmbeddedPkg/Include/Library/PrePiLib.h
@@ -101,7 +101,7 @@ FfsFindSectionData (
 **/
 EFI_STATUS
 EFIAPI
-FfsFindByName (
+FfsFindFileByName (
   IN CONST  EFI_GUID*FileName,
   IN CONST  EFI_PEI_FV_HANDLE   VolumeHandle,
   OUT   EFI_PEI_FILE_HANDLE *FileHandle
-- 
2.7.4

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


Re: [edk2] [PATCH edk2-platforms 10/41] Readme : Add Readme.md file.

2019-01-31 Thread Meenakshi Aggarwal



> -Original Message-
> From: Leif Lindholm 
> Sent: Wednesday, December 19, 2018 12:11 AM
> To: Meenakshi Aggarwal 
> Cc: ard.biesheu...@linaro.org; michael.d.kin...@intel.com; edk2-
> de...@lists.01.org; Udit Kumar ; Varun Sethi
> 
> Subject: Re: [PATCH edk2-platforms 10/41] Readme : Add Readme.md file.
> 
> On Wed, Nov 28, 2018 at 08:31:24PM +0530, Meenakshi Aggarwal wrote:
> > Readme.md to explain how to build NXP board packages.
> >
> 
> Could you add a link to this file from top-level Readme.md (towards the very
> end)?
> 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Meenakshi Aggarwal 
> > ---
> >  Platform/NXP/Readme.md | 24 
> >  1 file changed, 24 insertions(+)
> >  create mode 100644 Platform/NXP/Readme.md
> >
> > diff --git a/Platform/NXP/Readme.md b/Platform/NXP/Readme.md new file
> > mode 100644 index 000..902bafe
> > --- /dev/null
> > +++ b/Platform/NXP/Readme.md
> > @@ -0,0 +1,24 @@
> > +Support for all NXP boards is available in this directory.
> > +
> > +# How to build
> > +
> > +1. Set toolchain path.
> > +
> > +   export
> > + PATH=/gcc-linaro-4.9-2016.02-x86_64_aarch64-linux-
> gn
> > + u/bin/:$PATH
> > +
> > +2. Export following variables needed for compilation.
> > +
> > +   export CROSS_COMPILE=aarch64-linux-gnu-
> > +   export GCC_ARCH_PREFIX=GCC49_AARCH64_PREFIX
> > +   export GCC49_AARCH64_PREFIX=aarch64-linux-gnu-
> > +   export PACKAGES_PATH=/edk2/edk2-platforms
> > +
> 
> Can you check whether you are happy with the generic build instructions in the
> top-level Readme.md and improve those if not?
> Then you could reference those rather than repeating.
> 
Ok, will check the common Readme.md

> /
> Leif
> 
> > +3. Build desired board package
> > +
> > +   source edksetup.sh
> > +   build -p "path to package's description (.dsc) file" -a AARCH64 -t
> > + GCC49 -b DEBUG/RELEASE clean
> > +
> > +   e.g.
> > +   build -p
> "$PACKAGES_PATH/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc" -a
> AARCH64 -t GCC49 -b DEBUG clean
> > +   build -p
> > + "$PACKAGES_PATH/Platform/NXP/LS1043aRdbPkg/LS1043aRdbPkg.dsc" -a
> > + AARCH64 -t GCC49 -b DEBUG
> > +
> > --
> > 1.9.1
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH v3 11/12] MdeModulePkg/SmmLockBoxLib: Support LockBox enlarge in UpdateLockBox()

2019-01-31 Thread Hao Wu
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1409

This commit will add the support to enlarge a LockBox when using the
LockBoxLib API UpdateLockBox().

Please note that the new support will ONLY work for LockBox with attribute
LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY set.

The functional uni-test for the commit is available at:
https://github.com/hwu25/edk2/tree/lockbox_unitest

Cc: Jian J Wang 
Cc: Ray Ni 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
---
 MdeModulePkg/Include/Library/LockBoxLib.h |  7 +-
 MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c  |  7 +-
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c |  5 +-
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c |  5 +-
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.c | 72 ++--
 5 files changed, 86 insertions(+), 10 deletions(-)

diff --git a/MdeModulePkg/Include/Library/LockBoxLib.h 
b/MdeModulePkg/Include/Library/LockBoxLib.h
index 5921731419..addce3bd4a 100644
--- a/MdeModulePkg/Include/Library/LockBoxLib.h
+++ b/MdeModulePkg/Include/Library/LockBoxLib.h
@@ -2,7 +2,7 @@
   This library is only intended to be used by DXE modules that need save
   confidential information to LockBox and get it by PEI modules in S3 phase.
 
-Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions
@@ -85,7 +85,10 @@ SetLockBoxAttributes (
   @retval RETURN_SUCCESSthe information is saved successfully.
   @retval RETURN_INVALID_PARAMETER  the Guid is NULL, or Buffer is NULL, or 
Length is 0.
   @retval RETURN_NOT_FOUND  the requested GUID not found.
-  @retval RETURN_BUFFER_TOO_SMALL   the original buffer to too small to hold 
new information.
+  @retval RETURN_BUFFER_TOO_SMALL   for lockbox with attribute 
LOCK_BOX_ATTRIBUTE_RESTORE_IN_PLACE,
+the original buffer to too small to hold 
new information.
+  @retval RETURN_OUT_OF_RESOURCES   for lockbox with attribute 
LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY,
+no enough resource to save the information.
   @retval RETURN_ACCESS_DENIED  it is too late to invoke this interface
   @retval RETURN_NOT_STARTEDit is too early to invoke this interface
   @retval RETURN_UNSUPPORTEDthe service is not supported by 
implementaion.
diff --git a/MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c 
b/MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c
index c40dfea398..0adda1e2a9 100644
--- a/MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c
+++ b/MdeModulePkg/Library/LockBoxNullLib/LockBoxNullLib.c
@@ -1,6 +1,6 @@
 /** @file
 
-Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions
@@ -76,7 +76,10 @@ SetLockBoxAttributes (
   @retval RETURN_SUCCESSthe information is saved successfully.
   @retval RETURN_INVALID_PARAMETER  the Guid is NULL, or Buffer is NULL, or 
Length is 0.
   @retval RETURN_NOT_FOUND  the requested GUID not found.
-  @retval RETURN_BUFFER_TOO_SMALL   the original buffer to too small to hold 
new information.
+  @retval RETURN_BUFFER_TOO_SMALL   for lockbox with attribute 
LOCK_BOX_ATTRIBUTE_RESTORE_IN_PLACE,
+the original buffer to too small to hold 
new information.
+  @retval RETURN_OUT_OF_RESOURCES   for lockbox with attribute 
LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY,
+no enough resource to save the information.
   @retval RETURN_ACCESS_DENIED  it is too late to invoke this interface
   @retval RETURN_NOT_STARTEDit is too early to invoke this interface
   @retval RETURN_UNSUPPORTEDthe service is not supported by 
implementaion.
diff --git a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c 
b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c
index 0428decbac..5ee563b71f 100644
--- a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c
+++ b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c
@@ -300,7 +300,10 @@ SetLockBoxAttributes (
   @retval RETURN_SUCCESSthe information is saved successfully.
   @retval RETURN_INVALID_PARAMETER  the Guid is NULL, or Buffer is NULL, or 
Length is 0.
   @retval RETURN_NOT_FOUND  the requested GUID not found.
-  @retval RETURN_BUFFER_TOO_SMALL   the original buffer to too small to hold 
new information.
+  @retval RETURN_BUFFER_TOO_SMALL   for lockbox with attribute 
LOCK_BOX_ATTRIBUTE_RESTORE_IN_PLACE,
+the original buffer to too small to hold 
new information.
+  @retval RETURN_OUT_OF_RESOURCES   for lockbox with 

[edk2] [PATCH v3 09/12] MdeModulePkg/SmmLockBoxLib: Use 'DEBUG_' prefix instead of 'EFI_D_'

2019-01-31 Thread Hao Wu
This commit is out of the scope for BZ-1409. It is a coding style
refinement for the SmmLockBoxLib.

More specifically, the commit will remove all the debug message display
level macros starting with 'EFI_D_' and replace them with macros starting
with 'DEBUG_'.

Cc: Jian J Wang 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Ray Ni 
---
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c | 22 +++---
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c | 26 +++
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.c | 78 ++--
 3 files changed, 63 insertions(+), 63 deletions(-)

diff --git a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c 
b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c
index ac8bcd2ff7..0428decbac 100644
--- a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c
+++ b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.c
@@ -1,6 +1,6 @@
 /** @file
 
-Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions
@@ -153,7 +153,7 @@ SaveLockBox (
   UINT8   *CommBuffer;
   UINTN   CommSize;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib SaveLockBox - Enter\n"));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib SaveLockBox - Enter\n"));
 
   //
   // Basic check
@@ -199,7 +199,7 @@ SaveLockBox (
 
   Status = (EFI_STATUS)LockBoxParameterSave->Header.ReturnStatus;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib SaveLockBox - Exit (%r)\n", Status));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib SaveLockBox - Exit (%r)\n", Status));
 
   //
   // Done
@@ -235,7 +235,7 @@ SetLockBoxAttributes (
   UINT8 *CommBuffer;
   UINTN CommSize;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib SetLockBoxAttributes - Enter\n"));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib SetLockBoxAttributes - Enter\n"));
 
   //
   // Basic check
@@ -281,7 +281,7 @@ SetLockBoxAttributes (
 
   Status = (EFI_STATUS)LockBoxParameterSetAttributes->Header.ReturnStatus;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib SetLockBoxAttributes - Exit (%r)\n", 
Status));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib SetLockBoxAttributes - Exit (%r)\n", 
Status));
 
   //
   // Done
@@ -322,7 +322,7 @@ UpdateLockBox (
   UINT8 *CommBuffer;
   UINTN CommSize;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib UpdateLockBox - Enter\n"));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib UpdateLockBox - Enter\n"));
 
   //
   // Basic check
@@ -369,7 +369,7 @@ UpdateLockBox (
 
   Status = (EFI_STATUS)LockBoxParameterUpdate->Header.ReturnStatus;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib UpdateLockBox - Exit (%r)\n", Status));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib UpdateLockBox - Exit (%r)\n", Status));
 
   //
   // Done
@@ -411,7 +411,7 @@ RestoreLockBox (
   UINT8  *CommBuffer;
   UINTN  CommSize;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib RestoreLockBox - Enter\n"));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib RestoreLockBox - Enter\n"));
 
   //
   // Basic check
@@ -467,7 +467,7 @@ RestoreLockBox (
 
   Status = (EFI_STATUS)LockBoxParameterRestore->Header.ReturnStatus;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib RestoreLockBox - Exit (%r)\n", 
Status));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib RestoreLockBox - Exit (%r)\n", 
Status));
 
   //
   // Done
@@ -496,7 +496,7 @@ RestoreAllLockBoxInPlace (
   UINT8   *CommBuffer;
   UINTN   CommSize;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib RestoreAllLockBoxInPlace - Enter\n"));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib RestoreAllLockBoxInPlace - Enter\n"));
 
   SmmCommunication = LockBoxGetSmmCommProtocol ();
   if (SmmCommunication == NULL) {
@@ -532,7 +532,7 @@ RestoreAllLockBoxInPlace (
 
   Status = (EFI_STATUS)LockBoxParameterRestoreAllInPlace->Header.ReturnStatus;
 
-  DEBUG ((EFI_D_INFO, "SmmLockBoxDxeLib RestoreAllLockBoxInPlace - Exit 
(%r)\n", Status));
+  DEBUG ((DEBUG_INFO, "SmmLockBoxDxeLib RestoreAllLockBoxInPlace - Exit 
(%r)\n", Status));
 
   //
   // Done
diff --git a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c 
b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
index 8a168663c4..9f73480070 100644
--- a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
+++ b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
@@ -1,6 +1,6 @@
 /** @file
 
-Copyright (c) 2010 - 2018, Intel Corporation. All rights reserved.
+Copyright (c) 2010 - 2019, Intel Corporation. All rights reserved.
 
 This program and the accompanying materials
 are licensed and made available under the terms and conditions
@@ -542,7 +542,7 @@ RestoreLockBox (
   // 

[edk2] [PATCH v3 10/12] MdeModulePkg/SmmLockBox(PEI): Remove an ASSERT in RestoreLockBox()

2019-01-31 Thread Hao Wu
This commit is out of the scope for BZ-1409. It is a refinement for the
PEI library instance within SmmLockBoxLib.

For the below ASSERT statement within function RestoreLockBox():
  Status = SmmCommunicationPpi->Communicate (
  SmmCommunicationPpi,
  [0],
  
  );
  if (Status == EFI_NOT_STARTED) {
//
// Pei SMM communication not ready yet, so we access SMRAM directly
//
DEBUG ((DEBUG_INFO, "SmmLockBoxPeiLib Communicate - (%r)\n", Status));
Status = InternalRestoreLockBoxFromSmram (Guid, Buffer, Length);
LockBoxParameterRestore->Header.ReturnStatus = (UINT64)Status;
if (Length != NULL) {
  LockBoxParameterRestore->Length = (UINT64)*Length;
}
  }
  ASSERT_EFI_ERROR (Status);

It is possible for previous codes to return an error status that is
possible for happen. One example is that, when the 'if' statement
'if (Status == EFI_NOT_STARTED) {' is entered, function
InternalRestoreLockBoxFromSmram() is possible to return 'BUFFER_TOO_SMALL'
if the caller of RestoreLockBox() provides a buffer that is too small to
hold the content of LockBox.

Thus, this commit will remove the ASSERT here.

Please note that the current implementation of RestoreLockBox() is
handling the above-mentioned error case properly, so no additional error
handling codes are needed here.

Cc: Jian J Wang 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu 
Reviewed-by: Ray Ni 
---
 MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c 
b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
index 9f73480070..8c3e65bc96 100644
--- a/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
+++ b/MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxPeiLib.c
@@ -623,7 +623,6 @@ RestoreLockBox (
   LockBoxParameterRestore->Length = (UINT64)*Length;
 }
   }
-  ASSERT_EFI_ERROR (Status);
 
   if (Length != NULL) {
 *Length = (UINTN)LockBoxParameterRestore->Length;
-- 
2.12.0.windows.1

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


Re: [edk2] [PATCH v3 11/12] MdeModulePkg/SmmLockBoxLib: Support LockBox enlarge in UpdateLockBox()

2019-01-31 Thread Ni, Ray

Reviewed-by: Ray Ni 

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


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

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

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

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 0e671d55bc..e2718a1354 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -295,15 +295,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 # Required to build platforms or ACPI tables:
 #   Intel(r) ACPI Compiler from
 #   https://acpica.org/downloads
-#   CYGGCC  -win32-  Requires:
-# CygWin, GCC 4.3.0, binutils 2.20.51.0.5
-# Microsoft Visual Studio 2005 or 2008
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Intel(r) ACPI Compiler (iasl.exe) from
-#   https://acpica.org/downloads
 #   ICC -win32-  Requires:
 # Intel C Compiler V9.1
 #Dependencies:
@@ -373,15 +364,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 # Required to build platforms or ACPI tables:
 #   Microsoft ASL ACPI Compiler (asl.exe) v4.0.0 
from
 #   
http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi
-#   CYGGCCxASL  -win32-  Requires:
-# CygWin, GCC 4.3.0, binutils 2.20.51.0.5
-# Microsoft Visual Studio 2005 or 2008
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Microsoft ASL ACPI Compiler (asl.exe) v4.0.0 
from
-#   
http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi
 #   ICCxASL -win32-  Requires:
 # Intel C Compiler V9.1
 #Dependencies:
@@ -524,24 +506,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 # Required to build platforms or ACPI tables:
 #   Microsoft ASL ACPI Compiler (asl.exe) v4.0.0 
from
 #   
http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi
-#   CYGGCCx86   -win64-  Requires:
-# CygWin, GCC 4.3.0, binutils 2.20.51.0.5
-# Microsoft Visual Studio 2005 or 2008
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Intel(r) ACPI Compiler (iasl.exe) from
-#   https://acpica.org/downloads
-#  CYGGCCx86xASL -win64- Requires:
-# CygWin, GCC 4.3.0, binutils 2.20.51.0.5
-# Microsoft Visual Studio 2005 or 2008
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Microsoft ASL ACPI Compiler (asl.exe) v4.0.0 
from
-#   
http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi
 #   RVCT-win-   Requires:
 # ARM C/C++ Compiler, 5.00
 #Optional:
@@ -3824,173 +3788,6 @@ DEFINE CLANG38_AARCH64_DLINK_FLAGS  = 
DEF(CLANG38_AARCH64_TARGET) DEF(GCC_AARCH6
 RELEASE_CLANG38_AARCH64_CC_FLAGS= DEF(CLANG38_AARCH64_CC_FLAGS) 
$(ARCHCC_FLAGS) $(PLATFORM_FLAGS) -flto -O3
 RELEASE_CLANG38_AARCH64_DLINK_FLAGS = DEF(CLANG38_AARCH64_DLINK_FLAGS) -flto 
-Wl,-O3 -L$(WORKSPACE)/ArmPkg/Library/GccLto -llto-aarch64 
-Wl,-plugin-opt=-pass-through=-llto-aarch64
 
-
-#
-# Cygwin GCC And Intel ACPI 

Re: [edk2] [PATCH edk2-platforms 11/41] IFC : Add Header file for IFC controller

2019-01-31 Thread Meenakshi Aggarwal



> -Original Message-
> From: Leif Lindholm 
> Sent: Wednesday, December 19, 2018 12:16 AM
> To: Meenakshi Aggarwal 
> Cc: ard.biesheu...@linaro.org; michael.d.kin...@intel.com; edk2-
> de...@lists.01.org; Udit Kumar ; Varun Sethi
> 
> Subject: Re: [PATCH edk2-platforms 11/41] IFC : Add Header file for IFC
> controller
> 
> On Wed, Nov 28, 2018 at 08:31:25PM +0530, Meenakshi Aggarwal wrote:
> > This header file contain IFC controller timing structure, chip select
> > enum and other IFC macros.
> 
> Please expand the IFC acronym here (like is done in file header below).
> 
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Meenakshi Aggarwal 
> > ---
> >  Silicon/NXP/Include/Ifc.h | 423
> > ++
> 
> Please Update at least filename Ifc.h->NxpIfc.h
> 
> >  1 file changed, 423 insertions(+)
> >  create mode 100644 Silicon/NXP/Include/Ifc.h
> >
> > diff --git a/Silicon/NXP/Include/Ifc.h b/Silicon/NXP/Include/Ifc.h new
> > file mode 100644 index 000..6babb22
> > --- /dev/null
> > +++ b/Silicon/NXP/Include/Ifc.h
> > @@ -0,0 +1,423 @@
> > +/** @Ifc.h
> > +
> > +  The integrated flash controller (IFC) is used to interface with
> > + external asynchronous  NAND flash, asynchronous NOR flash, SRAM, generic
> ASIC memories and EPROM.
> > +
> > +  Copyright 2017 NXP
> > +
> > +  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
> > +
> > + https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fop
> > + ensource.org%2Flicenses%2Fbsd-
> license.phpdata=02%7C01%7Cmeenaks
> > +
> hi.aggarwal%40nxp.com%7Cf5720bda0a8c4ab0dd6708d6651904fb%7C686ea1d
> 3b
> > +
> c2b4c6fa92cd99c5c301635%7C0%7C0%7C636807555468004917sdata=df
> OWZ
> > + Z2yXCKi55Cl94sAEGYx739%2FXCiK1yX3Wm6lTow%3Dreserved=0
> > +
> > +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > + BASIS,  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
> EITHER EXPRESS OR IMPLIED.
> > +
> > +**/
> > +
> > +#ifndef __IFC_H__
> > +#define __IFC_H__
> 
> Please add NXP_ prefix.
> 
> (I am less concerned about the actual defines below.)
> 
> > +
> > +#include 
> 
> Is BaseLib.h really used by this file?

Yes, it is needed for HighBitSet32() used in this file.

> If not, please drop it.
> 
> > +#include 
> > +
> > +#define IFC_BANK_COUNT4
> > +
> > +#define IFC_CSPR_REG_LEN  148
> > +#define IFC_AMASK_REG_LEN 144
> > +#define IFC_CSOR_REG_LEN  144
> > +#define IFC_FTIM_REG_LEN  576
> > +
> > +#define IFC_CSPR_USED_LEN sizeof (IFC_CSPR) * \
> > +  IFC_BANK_COUNT
> > +
> > +#define IFC_AMASK_USED_LENsizeof (IFC_AMASK) * \
> > +  IFC_BANK_COUNT
> > +
> > +#define IFC_CSOR_USED_LEN sizeof (IFC_CSOR) * \
> > +  IFC_BANK_COUNT
> > +
> > +#define IFC_FTIM_USED_LEN sizeof (IFC_FTIM) * \
> > +  IFC_BANK_COUNT
> > +
> > +/* List of commands */
> > +#define IFC_NAND_CMD_RESET0xFF
> > +#define IFC_NAND_CMD_READID   0x90
> > +#define IFC_NAND_CMD_STATUS   0x70
> > +#define IFC_NAND_CMD_READ00x00
> > +#define IFC_NAND_CMD_READSTART0x30
> > +#define IFC_NAND_CMD_ERASE1   0x60
> > +#define IFC_NAND_CMD_ERASE2   0xD0
> > +#define IFC_NAND_CMD_SEQIN0x80
> > +#define IFC_NAND_CMD_PAGEPROG 0x10
> > +#define MAX_RETRY_COUNT   15
> > +
> > +
> > +#define IFC_NAND_SEQ_STRT_FIR_STRT  0x8000
> > +
> > +/*
> > + * NAND Event and Error Status Register (NAND_EVTER_STAT)  */
> > +
> > +/* Operation Complete */
> > +#define IFC_NAND_EVTER_STAT_OPC 0x8000
> > +
> > +/* Flash Timeout Error */
> > +#define IFC_NAND_EVTER_STAT_FTOER   0x0800
> > +
> > +/* Write Protect Error */
> > +#define IFC_NAND_EVTER_STAT_WPER0x0400
> > +
> > +/* ECC Error */
> > +#define IFC_NAND_EVTER_STAT_ECCER   0x0200
> > +
> > +/*
> > + * NAND Flash Instruction Registers (NAND_FIR0/NAND_FIR1/NAND_FIR2)
> > +*/
> > +
> > +/* NAND Machine specific opcodes OP0-OP14*/
> > +#define IFC_NAND_FIR0_OP0   0xFC00
> > +#define IFC_NAND_FIR0_OP0_SHIFT 26
> > +#define IFC_NAND_FIR0_OP1   0x03F0
> > +#define IFC_NAND_FIR0_OP1_SHIFT 20
> > +#define IFC_NAND_FIR0_OP2   0x000FC000
> > +#define IFC_NAND_FIR0_OP2_SHIFT 14
> > +#define IFC_NAND_FIR0_OP3   0x3F00
> > +#define IFC_NAND_FIR0_OP3_SHIFT 8
> > +#define IFC_NAND_FIR0_OP4   0x00FC
> > +#define IFC_NAND_FIR0_OP4_SHIFT 2
> > +#define IFC_NAND_FIR1_OP5   0xFC00
> > +#define IFC_NAND_FIR1_OP5_SHIFT 26
> > +#define IFC_NAND_FIR1_OP6   0x03F0
> > +#define IFC_NAND_FIR1_OP6_SHIFT 20
> > +#define IFC_NAND_FIR1_OP7   0x000FC000
> > +#define 

Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widths

2019-01-31 Thread Wu, Hao A
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jeff
> Brasen
> Sent: Thursday, January 31, 2019 7:59 AM
> To: edk2-devel@lists.01.org
> Cc: Edgar Handal; Jeff Brasen
> Subject: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO
> widths
> 
> From: Edgar Handal 
> 
> Use 16-bit and 32-bit IO widths for SDMMC MMIO to prevent all register
> accesses from being split up into 8-bit accesses.
> 
> The SDHCI specification states that the registers shall be accessable in
> byte, word, and double word accesses.

Hi,

Thanks for the contribution. The change seems good to me.

Just curious, if the accesses are always slit into byte(8-bit), is there any
issue or performance impact is encountered during your usage?

It will be helpful to get more information on the purpose of the patch.
Thanks.

Best Regards,
Hao Wu

> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jeff Brasen 
> ---
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 25
> 
>  1 file changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index 5aec8c6..82f4493 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -152,19 +152,36 @@ SdMmcHcRwMmio (
>)
>  {
>EFI_STATUS   Status;
> +  EFI_PCI_IO_PROTOCOL_WIDTHWidth;
> 
>if ((PciIo == NULL) || (Data == NULL))  {
>  return EFI_INVALID_PARAMETER;
>}
> 
> -  if ((Count != 1) && (Count != 2) && (Count != 4) && (Count != 8)) {
> -return EFI_INVALID_PARAMETER;
> +  switch (Count) {
> +case 1:
> +  Width = EfiPciIoWidthUint8;
> +  break;
> +case 2:
> +  Width = EfiPciIoWidthUint16;
> +  Count = 1;
> +  break;
> +case 4:
> +  Width = EfiPciIoWidthUint32;
> +  Count = 1;
> +  break;
> +case 8:
> +  Width = EfiPciIoWidthUint32;
> +  Count = 2;
> +  break;
> +default:
> +  return EFI_INVALID_PARAMETER;
>}
> 
>if (Read) {
>  Status = PciIo->Mem.Read (
>PciIo,
> -  EfiPciIoWidthUint8,
> +  Width,
>BarIndex,
>(UINT64) Offset,
>Count,
> @@ -173,7 +190,7 @@ SdMmcHcRwMmio (
>} else {
>  Status = PciIo->Mem.Write (
>PciIo,
> -  EfiPciIoWidthUint8,
> +  Width,
>BarIndex,
>(UINT64) Offset,
>Count,
> --
> 2.7.4
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [MdePkg/BaseLib v1 1/1] MdePkg BaseLib: Add new API CalculateCrc16()

2019-01-31 Thread Ni, Ray
There is an CRC16 calculation implementation in
SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.c

Does your implementation generate the same CRC16 as above one?

> -Original Message-
> From: edk2-devel  On Behalf Of Ming
> Huang
> Sent: Friday, February 1, 2019 2:02 PM
> To: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org; Kinney, Michael D
> ; Gao, Liming 
> Cc: huangmin...@huawei.com; Dong, Eric ;
> zhangjinso...@huawei.com; Zeng, Star ;
> wai...@126.com; wanghuiqi...@huawei.com; huangda...@hisilicon.com
> Subject: [edk2] [MdePkg/BaseLib v1 1/1] MdePkg BaseLib: Add new API
> CalculateCrc16()
> 
> CalculateCrc16() bases on the initialized mCrcTable. When CalculateCrc16() is
> used, mCrcTable16 will take 512Bytes size in the image. When
> CalculateCrc16() is not used, mCrcTable16 will not be built in the image, and
> no size impact.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ming Huang 
> ---
>  MdePkg/Include/Library/BaseLib.h  | 20 ++
> MdePkg/Library/BaseLib/CheckSum.c | 73 
>  2 files changed, 93 insertions(+)
> 
> diff --git a/MdePkg/Include/Library/BaseLib.h
> b/MdePkg/Include/Library/BaseLib.h
> index 1eb842384ee2..956b971e5c69 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -4855,6 +4855,26 @@ CalculateCrc32(
>IN  UINTNLength
>);
> 
> +/**
> +  Computes and returns a 16-bit CRC for a data buffer.
> +  CRC16 value bases on CCITT.
> +
> +  If Buffer is NULL, then ASSERT().
> +  If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
> +
> +  @param[in]  Buffer   A pointer to the buffer on which the 16-bit CRC 
> is to
> be computed.
> +  @param[in]  Length  The number of bytes in the buffer Data.
> +
> +  @retval Crc16The 16-bit CRC was computed for the data buffer.
> +
> +**/
> +UINT16
> +EFIAPI
> +CalculateCrc16(
> +  IN  VOID *Buffer,
> +  IN  UINTNLength
> +  );
> +
>  //
>  // Base Library CPU Functions
>  //
> diff --git a/MdePkg/Library/BaseLib/CheckSum.c
> b/MdePkg/Library/BaseLib/CheckSum.c
> index 03d49afc5e6c..4e27aebe44bc 100644
> --- a/MdePkg/Library/BaseLib/CheckSum.c
> +++ b/MdePkg/Library/BaseLib/CheckSum.c
> @@ -630,3 +630,76 @@ CalculateCrc32(
> 
>return Crc ^ 0x;
>  }
> +
> +GLOBAL_REMOVE_IF_UNREFERENCED CONST UINT16  mCrcTable16[256] =
> {
> +  0x, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7,
> +  0x8108, 0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF,
> +  0x1231, 0x0210, 0x3273, 0x2252, 0x52B5, 0x4294, 0x72F7, 0x62D6,
> +  0x9339, 0x8318, 0xB37B, 0xA35A, 0xD3BD, 0xC39C, 0xF3FF, 0xE3DE,
> +  0x2462, 0x3443, 0x0420, 0x1401, 0x64E6, 0x74C7, 0x44A4, 0x5485,
> +  0xA56A, 0xB54B, 0x8528, 0x9509, 0xE5EE, 0xF5CF, 0xC5AC, 0xD58D,
> +  0x3653, 0x2672, 0x1611, 0x0630, 0x76D7, 0x66F6, 0x5695, 0x46B4,
> +  0xB75B, 0xA77A, 0x9719, 0x8738, 0xF7DF, 0xE7FE, 0xD79D, 0xC7BC,
> +  0x48C4, 0x58E5, 0x6886, 0x78A7, 0x0840, 0x1861, 0x2802, 0x3823,
> +  0xC9CC, 0xD9ED, 0xE98E, 0xF9AF, 0x8948, 0x9969, 0xA90A, 0xB92B,
> +  0x5AF5, 0x4AD4, 0x7AB7, 0x6A96, 0x1A71, 0x0A50, 0x3A33, 0x2A12,
> +  0xDBFD, 0xCBDC, 0xFBBF, 0xEB9E, 0x9B79, 0x8B58, 0xBB3B, 0xAB1A,
> +  0x6CA6, 0x7C87, 0x4CE4, 0x5CC5, 0x2C22, 0x3C03, 0x0C60, 0x1C41,
> +  0xEDAE, 0xFD8F, 0xCDEC, 0xDDCD, 0xAD2A, 0xBD0B, 0x8D68, 0x9D49,
> +  0x7E97, 0x6EB6, 0x5ED5, 0x4EF4, 0x3E13, 0x2E32, 0x1E51, 0x0E70,
> +  0xFF9F, 0xEFBE, 0xDFDD, 0xCFFC, 0xBF1B, 0xAF3A, 0x9F59, 0x8F78,
> +  0x9188, 0x81A9, 0xB1CA, 0xA1EB, 0xD10C, 0xC12D, 0xF14E, 0xE16F,
> +  0x1080, 0x00A1, 0x30C2, 0x20E3, 0x5004, 0x4025, 0x7046, 0x6067,
> +  0x83B9, 0x9398, 0xA3FB, 0xB3DA, 0xC33D, 0xD31C, 0xE37F, 0xF35E,
> +  0x02B1, 0x1290, 0x22F3, 0x32D2, 0x4235, 0x5214, 0x6277, 0x7256,
> +  0xB5EA, 0xA5CB, 0x95A8, 0x8589, 0xF56E, 0xE54F, 0xD52C, 0xC50D,
> +  0x34E2, 0x24C3, 0x14A0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
> +  0xA7DB, 0xB7FA, 0x8799, 0x97B8, 0xE75F, 0xF77E, 0xC71D, 0xD73C,
> +  0x26D3, 0x36F2, 0x0691, 0x16B0, 0x6657, 0x7676, 0x4615, 0x5634,
> +  0xD94C, 0xC96D, 0xF90E, 0xE92F, 0x99C8, 0x89E9, 0xB98A, 0xA9AB,
> +  0x5844, 0x4865, 0x7806, 0x6827, 0x18C0, 0x08E1, 0x3882, 0x28A3,
> +  0xCB7D, 0xDB5C, 0xEB3F, 0xFB1E, 0x8BF9, 0x9BD8, 0xABBB, 0xBB9A,
> +  0x4A75, 0x5A54, 0x6A37, 0x7A16, 0x0AF1, 0x1AD0, 0x2AB3, 0x3A92,
> +  0xFD2E, 0xED0F, 0xDD6C, 0xCD4D, 0xBDAA, 0xAD8B, 0x9DE8, 0x8DC9,
> +  0x7C26, 0x6C07, 0x5C64, 0x4C45, 0x3CA2, 0x2C83, 0x1CE0, 0x0CC1,
> +  0xEF1F, 0xFF3E, 0xCF5D, 0xDF7C, 0xAF9B, 0xBFBA, 0x8FD9, 0x9FF8,
> +  0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0 };
> +
> +/**
> +  Computes and returns a 16-bit CRC for a data buffer.
> +  CRC16 value bases on CCITT.
> +
> +  If Buffer is NULL, then ASSERT().
> +  If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
> +
> +  @param[in]  Buffer   A pointer to the buffer on which the 16-bit CRC 
> is to
> be 

Re: [edk2] [PATCH edk2-platforms 13/41] Silicon/NXP : Add support of IfcLib

2019-01-31 Thread Meenakshi Aggarwal



> -Original Message-
> From: Leif Lindholm 
> Sent: Wednesday, December 19, 2018 6:56 PM
> To: Meenakshi Aggarwal 
> Cc: ard.biesheu...@linaro.org; michael.d.kin...@intel.com; edk2-
> de...@lists.01.org; Udit Kumar ; Varun Sethi
> 
> Subject: Re: [PATCH edk2-platforms 13/41] Silicon/NXP : Add support of IfcLib
> 
> On Wed, Nov 28, 2018 at 08:31:27PM +0530, Meenakshi Aggarwal wrote:
> > Add support of IfcLib, it will be used to perform any operation on IFC
> > controller.
> 
> Expand acronym.
> 
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Meenakshi Aggarwal 
> > ---
> >  Silicon/NXP/Include/Library/IfcLib.h  |  26 +
> >  Silicon/NXP/Library/IfcLib/IfcLib.c   | 150 +++
> >  Silicon/NXP/Library/IfcLib/IfcLib.h   | 190
> ++
> >  Silicon/NXP/Library/IfcLib/IfcLib.inf |  38 +++
> 
> Names Ifc -> NxpIfc please.
> 
Is this renaming really needed for IfcLib, I can change the guard and header 
file name.

Please suggest?

> >  Silicon/NXP/NxpQoriqLs.dec|   1 +
> >  5 files changed, 405 insertions(+)
> >  create mode 100644 Silicon/NXP/Include/Library/IfcLib.h
> >  create mode 100644 Silicon/NXP/Library/IfcLib/IfcLib.c
> >  create mode 100644 Silicon/NXP/Library/IfcLib/IfcLib.h
> >  create mode 100644 Silicon/NXP/Library/IfcLib/IfcLib.inf
> >
> > diff --git a/Silicon/NXP/Include/Library/IfcLib.h
> > b/Silicon/NXP/Include/Library/IfcLib.h
> > new file mode 100644
> > index 000..8d2c151
> > --- /dev/null
> > +++ b/Silicon/NXP/Include/Library/IfcLib.h
> > @@ -0,0 +1,26 @@
> > +/** @IfcLib.h
> > +
> > +  The integrated flash controller (IFC) is used to interface with
> > + external asynchronous  NAND flash, asynchronous NOR flash, SRAM, generic
> ASIC memories and EPROM.
> > +
> > +  Copyright 2018 NXP
> > +
> > +  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
> > +
> > + https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fop
> > + ensource.org%2Flicenses%2Fbsd-
> license.phpdata=02%7C01%7Cmeenaks
> > +
> hi.aggarwal%40nxp.com%7C62c0401c65ac481e650508d665b57ea9%7C686ea1
> d3b
> > +
> c2b4c6fa92cd99c5c301635%7C0%7C0%7C636808227519182943sdata=4
> UMgN
> > + 7laz86jDwTlvJrHWkqdum8qmZPGWrhESvjHBMQ%3Dreserved=0
> > +
> > +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > + BASIS,  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
> EITHER EXPRESS OR IMPLIED.
> > +
> > +**/
> > +
> > +#ifndef __IFC_LIB_H__
> > +#define __IFC_LIB_H__
> 
> Header guard NXP_ (and/or QORIQ_) prefix.
> 
> > +
> > +VOID
> > +IfcInit (
> > +  VOID
> > +  );
> > +
> > +#endif //__IFC_LIB_H__
> > diff --git a/Silicon/NXP/Library/IfcLib/IfcLib.c
> > b/Silicon/NXP/Library/IfcLib/IfcLib.c
> > new file mode 100644
> > index 000..8cf02ae
> > --- /dev/null
> > +++ b/Silicon/NXP/Library/IfcLib/IfcLib.c
> > @@ -0,0 +1,150 @@
> > +/** @IfcLib.c
> > +
> > +  The integrated flash controller (IFC) is used to interface with
> > + external asynchronous/  synchronous NAND flash, asynchronous NOR
> > + flash, SRAM, generic ASIC memory and  EPROM.
> > +  It has eight chip-selects, to which a maximum of eight flash
> > + devices can be attached,  although only one of these can be accessed at 
> > any
> given time.
> > +
> > +  Copyright 2018 NXP
> > +
> > +  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
> > +
> > + https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fop
> > + ensource.org%2Flicenses%2Fbsd-
> license.phpdata=02%7C01%7Cmeenaks
> > +
> hi.aggarwal%40nxp.com%7C62c0401c65ac481e650508d665b57ea9%7C686ea1
> d3b
> > +
> c2b4c6fa92cd99c5c301635%7C0%7C0%7C636808227519182943sdata=4
> UMgN
> > + 7laz86jDwTlvJrHWkqdum8qmZPGWrhESvjHBMQ%3Dreserved=0
> > +
> > +  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS"
> > + BASIS,  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND,
> EITHER EXPRESS OR IMPLIED.
> > +
> > +**/
> > +
> > +#include 
> > +#include "IfcLib.h"
> > +
> > +STATIC MMIO_OPERATIONS_32 *mMmioOps;
> > +
> > +STATIC UINT8 mNandCS;
> > +STATIC UINT8 mNorCS;
> > +STATIC UINT8 mFpgaCS;
> > +
> > +VOID
> 
> Local only?
> If so, STATIC please.
> 
> > +SetTimings (
> > +  IN  UINT8CS,
> > +  IN  IFC_TIMINGS  IfcTimings
> > +  )
> > +{
> > +  IFC_REGS*IfcRegs;
> > +
> > +  IfcRegs = (IFC_REGS*)PcdGet64 (PcdIfcBaseAddr);
> > +
> > +  // Configure Extended chip select property registers
> > + mMmioOps->Write ((UINTN)>CsprCs[CS].CsprExt,
> > + IfcTimings.CsprExt);
> > +
> > +  // Configure Fpga timing registers
> > +  mMmioOps->Write ((UINTN)>FtimCs[CS].Ftim[IFC_FTIM0],
> > + IfcTimings.Ftim[0]);  

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

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

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

 BaseTools/Conf/target.template|2 +-
 BaseTools/Conf/tools_def.template | 1544 -
 OptionRomPkg/ReadMe.txt   |2 -
 OvmfPkg/OvmfPkgIa32.dsc   |1 -
 OvmfPkg/OvmfPkgIa32X64.dsc|1 -
 OvmfPkg/OvmfPkgX64.dsc|1 -
 OvmfPkg/README|   19 -
 7 files changed, 1 insertion(+), 1569 deletions(-)

-- 
2.18.0.windows.1

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


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

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

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

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

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


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

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

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

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 2bd0982872..7df9d735c1 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -17,19 +17,6 @@
 IDENTIFIER = Default TOOL_CHAIN_CONF
 
 # common path macros
-DEFINE VS2003_BIN   = ENV(VS2003_PREFIX)Vc7\bin
-DEFINE VS2003_DLL   = ENV(VS2003_PREFIX)Common7\IDE
-
-DEFINE VS2005_BIN   = ENV(VS2005_PREFIX)Vc\bin
-DEFINE VS2005_DLL   = ENV(VS2005_PREFIX)Common7\IDE;DEF(VS2005_BIN)
-DEFINE VS2005_BINX64= DEF(VS2005_BIN)\x86_amd64
-DEFINE VS2005_BIN64 = DEF(VS2005_BIN)\x86_ia64
-
-DEFINE VS2005x86_BIN= ENV(VS2005_PREFIX)Vc\bin
-DEFINE VS2005x86_DLL= ENV(VS2005_PREFIX)Common7\IDE;DEF(VS2005x86_BIN)
-DEFINE VS2005x86_BINX64 = DEF(VS2005x86_BIN)\x86_amd64
-DEFINE VS2005x86_BIN64  = DEF(VS2005x86_BIN)\x86_ia64
-
 DEFINE VS2008_BIN  = ENV(VS2008_PREFIX)Vc\bin
 DEFINE VS2008_DLL  = ENV(VS2008_PREFIX)Common7\IDE;DEF(VS2008_BIN)
 DEFINE VS2008_BINX64   = DEF(VS2008_BIN)\x86_amd64
@@ -108,11 +95,6 @@ DEFINE WINSDK10_BIN   = 
ENV(WINSDK10_PREFIX)DEF(VS2017_HOST)
 # are used by other toolchains.  An example is that ICC on Windows normally
 # uses Microsoft's nmake.exe.
 
-# Some MS_VS_BIN options: DEF(VS2003_BIN), DEF(VS2005_BIN), 
DEF(VS2005x86_BIN), DEF(VS2008_BIN), DEF(VS2008x86_BIN)
-DEFINE MS_VS_BIN   = DEF(VS2005_BIN)
-# Some MS_VS_DLL options: DEF(VS2003_DLL), DEF(VS2005_DLL), 
DEF(VS2005x86_DLL), DEF(VS2008_DLL), DEF(VS2008x86_DLL)
-DEFINE MS_VS_DLL   = DEF(VS2005_DLL)
-
 DEFINE WINDDK_BIN16 = ENV(WINDDK3790_PREFIX)bin16
 DEFINE WINDDK_BIN32 = ENV(WINDDK3790_PREFIX)x86
 DEFINE WINDDK_BINX64= ENV(WINDDK3790_PREFIX)win64\x86\amd64
@@ -254,24 +236,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 #
 # Supported Tool Chains
 # =
-#   VS2003  -win32-  Requires:
-# Microsoft Visual Studio .NET 2003
-# Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Intel(r) ACPI Compiler (iasl.exe) from
-#   https://acpica.org/downloads
-#   VS2005  -win32-  Requires:
-# Microsoft Visual Studio 2005 Team Suite Edition
-# Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Intel(r) ACPI Compiler (iasl.exe) from
-#   https://acpica.org/downloads
 #   VS2008  -win32-  Requires:
 # Microsoft Visual Studio 2008 Team Suite Edition
 # Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
@@ -421,24 +385,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 # Required to build platforms or ACPI tables:
 #   Intel(r) ACPI Compiler (iasl.exe) from
 #   https://acpica.org/downloads
-#   VS2003xASL  -win32-  Requires:
-# Microsoft Visual Studio .NET 2003
-# Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Microsoft ASL ACPI Compiler (asl.exe) v4.0.0 
from
-#   
http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi
-#   VS2005xASL  -win32-  Requires:
-# Microsoft Visual Studio 2005 Team Suite Edition
-# Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
-#Optional:
-# 

[edk2] [PATCH 05/10] OvmfPkg: Remove UNIXGCC in DSC files

2019-01-31 Thread Shenglei Zhang
Remove UNIXGCC in OvmfPkgIa32.dsc, OvmfPkgIa32X64.dsc
and OvmfPkgX64.dsc.
https://bugzilla.tianocore.org/show_bug.cgi?id=1377

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

diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index aee19b75d7..7872ead8de 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -61,7 +61,6 @@
 !endif
 
 [BuildOptions]
-  GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
   GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
   INTEL:RELEASE_*_*_CC_FLAGS   = /D MDEPKG_NDEBUG
   MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 90cbd8e341..eef8ae25f3 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -61,7 +61,6 @@
 !endif
 
 [BuildOptions]
-  GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
   GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
   INTEL:RELEASE_*_*_CC_FLAGS   = /D MDEPKG_NDEBUG
   MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
index 83d16eb00b..6d5623857c 100644
--- a/OvmfPkg/OvmfPkgX64.dsc
+++ b/OvmfPkg/OvmfPkgX64.dsc
@@ -61,7 +61,6 @@
 !endif
 
 [BuildOptions]
-  GCC:*_UNIXGCC_*_CC_FLAGS = -DMDEPKG_NDEBUG
   GCC:RELEASE_*_*_CC_FLAGS = -DMDEPKG_NDEBUG
   INTEL:RELEASE_*_*_CC_FLAGS   = /D MDEPKG_NDEBUG
   MSFT:RELEASE_*_*_CC_FLAGS= /D MDEPKG_NDEBUG
-- 
2.18.0.windows.1

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


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

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

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

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 7df9d735c1..162227ace1 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -95,10 +95,6 @@ DEFINE WINSDK10_BIN   = 
ENV(WINSDK10_PREFIX)DEF(VS2017_HOST)
 # are used by other toolchains.  An example is that ICC on Windows normally
 # uses Microsoft's nmake.exe.
 
-DEFINE WINDDK_BIN16 = ENV(WINDDK3790_PREFIX)bin16
-DEFINE WINDDK_BIN32 = ENV(WINDDK3790_PREFIX)x86
-DEFINE WINDDK_BINX64= ENV(WINDDK3790_PREFIX)win64\x86\amd64
-DEFINE WINDDK_BIN64 = ENV(WINDDK3790_PREFIX)win64\x86
 
 # NOTE: The Intel C++ Compiler for Windows requires one of the Microsoft C 
compiler
 #tool chains for the linker and nmake commands.
@@ -292,14 +288,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 #Note:
 # Building of XIP firmware images for ARM/ARM64 is 
not currently supported (only applications).
 # /FILEALIGN:4096 and other changes are needed for 
ARM firmware builds.
-#   DDK3790 -win32-  Requires:
-# Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Intel(r) ACPI Compiler (iasl.exe) from
-#   https://acpica.org/downloads
 #   UNIXGCC -UNIX-   Requires:
 # GCC 4.3.0
 # binutils 2.20.51.0.5
@@ -430,14 +418,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 # Required to build platforms or ACPI tables:
 #   Microsoft ASL ACPI Compiler (asl.exe) v4.0.0 
from
 #   
http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi
-#   DDK3790xASL -win32-  Requires:
-# Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Microsoft ASL ACPI Compiler (asl.exe) v4.0.0 
from
-#   
http://download.microsoft.com/download/2/c/1/2c16c7e0-96c1-40f5-81fc-3e4bf7b65496/microsoft_asl_compiler-v4-0-0.msi
 #   CYGGCCxASL  -win32-  Requires:
 # CygWin, GCC 4.3.0, binutils 2.20.51.0.5
 # Microsoft Visual Studio 2005 or 2008
@@ -3179,336 +3159,6 @@ NOOPT_VS2017_AARCH64_DLINK_FLAGS   = /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:REF
 *_VS2017_EBC_SLINK_FLAGS = /lib /NOLOGO /MACHINE:EBC
 *_VS2017_EBC_DLINK_FLAGS = "C:\Program Files 
(x86)\Intel\EBC\Lib\EbcLib.lib" /NOLOGO /NODEFAULTLIB /MACHINE:EBC /OPT:REF 
/ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /MAP /ALIGN:32 
/DRIVER
 
-
-#
-# Microsoft Device Driver Kit 3790.1830 (IA-32, X64, Itanium, with Link Time 
Code Generation)
-# And Intel ACPI Compiler
-#
-
-#   DDK3790  - Microsoft Windows DDK 3790.1830
-#   ASL  - Intel ACPI Source Language Compiler (iasl.exe)
-*_DDK3790_*_*_FAMILY= MSFT
-
-*_DDK3790_*_*_DLL   = DEF(WINDDK_BIN32)
-*_DDK3790_*_MAKE_PATH   = DEF(WINDDK_BIN32)\nmake.exe
-*_DDK3790_*_MAKE_FLAGS   = /nologo
-*_DDK3790_*_RC_PATH = DEF(WINDDK_BIN32)\rc.exe
-
-*_DDK3790_*_PP_FLAGS = /nologo /E /TC /FIAutoGen.h
-*_DDK3790_*_APP_FLAGS= /nologo /E /TC
-*_DDK3790_*_SLINK_FLAGS  = /nologo /LTCG
-*_DDK3790_*_VFRPP_FLAGS  = /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h
-
-*_DDK3790_*_ASM16_PATH  = DEF(WINDDK_BIN32)\ml.exe
-
-##
-# ASL definitions
-##
-*_DDK3790_*_ASL_PATH= DEF(DEFAULT_WIN_ASL_BIN)
-*_DDK3790_*_ASL_FLAGS   = DEF(DEFAULT_WIN_ASL_FLAGS)
-*_DDK3790_*_ASL_OUTFLAGS= DEF(DEFAULT_WIN_ASL_OUTFLAGS)
-*_DDK3790_*_ASLCC_FLAGS = 

[edk2] [PATCH 06/10] OvmfPkg/README: Remove UNIXGCC

2019-01-31 Thread Shenglei Zhang
Remove content related to UNIXGCC in README.
https://bugzilla.tianocore.org/show_bug.cgi?id=1377

Cc: Jordan Justen 
Cc: Laszlo Ersek 
Cc: Ard Biesheuvel 
Cc: Anthony Perard 
Cc: Julien Grall 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang 
---
 OvmfPkg/README | 19 ---
 1 file changed, 19 deletions(-)

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

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


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

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

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

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 162227ace1..ab5dc78b19 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -138,29 +138,6 @@ DEFINE EBC_BINx86   = C:\Program Files 
(x86)\Intel\EBC\Bin
 
 DEFINE ELFGCC_BIN   = /usr/bin
 
-#
-# Option 1: Hard coded full path to compiler suite
-DEFINE UNIXGCC_IA32_PETOOLS_PREFIX = 
/opt/tiano/i386-tiano-pe/i386-tiano-pe/bin/
-DEFINE UNIXGCC_X64_PETOOLS_PREFIX  = 
/opt/tiano/x86_64-pc-mingw64/x86_64-pc-mingw64/bin/
-#
-# Option 2: Use an environment variable
-#DEFINE UNIXGCC_IA32_PETOOLS_PREFIX = ENV(IA32_PETOOLS_PREFIX)
-#DEFINE UNIXGCC_X64_PETOOLS_PREFIX  = ENV(X64_PETOOLS_PREFIX)
-#
-# Option 3: Install the compiler suite into your default paths
-#DEFINE UNIXGCC_IA32_PETOOLS_PREFIX = i386-pc-mingw32-
-#DEFINE UNIXGCC_X64_PETOOLS_PREFIX  = x86_64-pc-mingw32-
-#
-# Option 4: Create links under the BaseTools/Bin/gcc/ARCH directory
-# Links needed: gcc, ar & ld
-#DEFINE UNIXGCC_IA32_PETOOLS_PREFIX = ENV(WORKSPACE)/BaseTools/Bin/gcc/Ia32/
-#DEFINE UNIXGCC_X64_PETOOLS_PREFIX  = ENV(WORKSPACE)/BaseTools/Bin/gcc/X64/
-#
-# Option 5: Install programs under user's home directory
-#DEFINE UNIXGCC_IA32_PETOOLS_PREFIX = 
ENV(HOME)/programs/gcc/ia32/bin/i686-pc-mingw32-
-#DEFINE UNIXGCC_X64_PETOOLS_PREFIX  = 
ENV(HOME)/programs/gcc/x64/bin/x86_64-pc-mingw32-
-#
-
 DEFINE CYGWIN_BIN  = c:/cygwin/bin
 DEFINE CYGWIN_BINIA32  = 
c:/cygwin/opt/tiano/i386-tiano-pe/i386-tiano-pe/bin/
 DEFINE CYGWIN_BINX64   = 
c:/cygwin/opt/tiano/x86_64-pc-mingw64/x86_64-pc-mingw64/bin/
@@ -288,13 +265,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 #Note:
 # Building of XIP firmware images for ARM/ARM64 is 
not currently supported (only applications).
 # /FILEALIGN:4096 and other changes are needed for 
ARM firmware builds.
-#   UNIXGCC -UNIX-   Requires:
-# GCC 4.3.0
-# binutils 2.20.51.0.5
-#Optional:
-# Required to build platforms or ACPI tables:
-#   Intel(r) ACPI Compiler from
-#   https://acpica.org/downloads
 #   GCC48   -Linux,Windows-  Requires:
 # GCC 4.8 targeting x86_64-linux-gnu, 
aarch64-linux-gnu, or arm-linux-gnueabi
 #Optional:
@@ -3159,72 +3129,6 @@ NOOPT_VS2017_AARCH64_DLINK_FLAGS   = /NOLOGO 
/NODEFAULTLIB /IGNORE:4001 /OPT:REF
 *_VS2017_EBC_SLINK_FLAGS = /lib /NOLOGO /MACHINE:EBC
 *_VS2017_EBC_DLINK_FLAGS = "C:\Program Files 
(x86)\Intel\EBC\Lib\EbcLib.lib" /NOLOGO /NODEFAULTLIB /MACHINE:EBC /OPT:REF 
/ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /MAP /ALIGN:32 
/DRIVER
 
-
-#
-# Unix GCC And Intel Linux ACPI Compiler
-#
-
-#   UNIXGCC - UNIX GCC
-#   ASL - Intel Linux ACPI Source Language Compiler (iasl)
-*_UNIXGCC_*_*_FAMILY   = GCC
-*_UNIXGCC_*_*_BUILDRULEFAMILY  = GCCLD
-
-*_UNIXGCC_*_MAKE_PATH= make
-*_UNIXGCC_*_ASL_PATH = DEF(UNIX_IASL_BIN)
-
-*_UNIXGCC_IA32_DLINK_FLAGS   = DEF(GCC_IA32_X64_DLINK_FLAGS) 
--image-base=0
-*_UNIXGCC_X64_DLINK_FLAGS= DEF(GCC_IA32_X64_DLINK_FLAGS) 
--image-base=0
-*_UNIXGCC_IA32_ASLDLINK_FLAGS= DEF(GCC_IA32_X64_ASLDLINK_FLAGS)
-*_UNIXGCC_X64_ASLDLINK_FLAGS = DEF(GCC_IA32_X64_ASLDLINK_FLAGS)
-*_UNIXGCC_*_ASM_FLAGS= DEF(GCC_ASM_FLAGS)
-*_UNIXGCC_*_PP_FLAGS = DEF(GCC_PP_FLAGS)
-*_UNIXGCC_*_ASLPP_FLAGS  = DEF(GCC_ASLPP_FLAGS)
-*_UNIXGCC_*_ASLCC_FLAGS  = DEF(GCC_ASLCC_FLAGS)
-*_UNIXGCC_*_VFRPP_FLAGS  = DEF(GCC_VFRPP_FLAGS)
-*_UNIXGCC_*_APP_FLAGS=
-*_UNIXGCC_*_ASL_FLAGS= DEF(IASL_FLAGS)
-*_UNIXGCC_*_ASL_OUTFLAGS = DEF(IASL_OUTFLAGS)
-
-##
-# IA32 definitions
-##
-*_UNIXGCC_IA32_OBJCOPY_PATH = DEF(UNIXGCC_IA32_PETOOLS_PREFIX)objcopy
-*_UNIXGCC_IA32_PP_PATH  = DEF(UNIXGCC_IA32_PETOOLS_PREFIX)gcc
-*_UNIXGCC_IA32_CC_PATH  = DEF(UNIXGCC_IA32_PETOOLS_PREFIX)gcc
-*_UNIXGCC_IA32_SLINK_PATH   = DEF(UNIXGCC_IA32_PETOOLS_PREFIX)ar

[edk2] [PATCH 07/10] BaseTools: Update MYTOOLS

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

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

diff --git a/BaseTools/Conf/target.template b/BaseTools/Conf/target.template
index e5c31fe5a0..dc8e0f943b 100644
--- a/BaseTools/Conf/target.template
+++ b/BaseTools/Conf/target.template
@@ -57,7 +57,7 @@ TOOL_CHAIN_CONF   = Conf/tools_def.txt
 #  TAGNAME   List  Optional   Specify the name(s) of the 
tools_def.txt TagName to use.
 # If not specified, all applicable 
TagName tools will be
 # used for the build.  The list 
uses space character separation.
-TOOL_CHAIN_TAG= MYTOOLS
+TOOL_CHAIN_TAG= VS2015x86
 
 # MAX_CONCURRENT_THREAD_NUMBER  NUMBER  Optional  The number of concurrent 
threads. If not specified or set
 # to zero, tool automatically 
detect number of processor
diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index ab5dc78b19..e73fec42bf 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -335,14 +335,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 # Required to build platforms or ACPI tables:
 #   Intel(r) ACPI Compiler (iasl.exe) from
 #   https://acpica.org/downloads
-#   MYTOOLS -win32-  Requires:
-# Microsoft Visual Studio 2008 for IA32/X64
-#Optional:
-# Required to build EBC drivers:
-#   Intel(r) Compiler for Efi Byte Code (Intel(r) 
EBC Compiler)
-# Required to build platforms or ACPI tables:
-#   Intel(r) ACPI Compiler (iasl.exe) from
-#   https://acpica.org/downloads
 #   VS2008xASL  -win32-  Requires:
 # Microsoft Visual Studio 2008 Team Suite
 # Microsoft Windows Server 2003 Driver Development 
Kit (Microsoft WINDDK) version 3790.1830
@@ -5037,119 +5029,6 @@ NOOPT_ICC11x86xASL_X64_DLINK_FLAGS= 
/NOLOGO /NODEFAULTLIB /IGNOR
 *_ICC11x86xASL_EBC_DLINK_FLAGS= "C:\Program Files 
(x86)\Intel\EBC\Lib\EbcLib.lib" /NOLOGO /NODEFAULTLIB /MACHINE:EBC /OPT:REF 
/ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /MAP /ALIGN:32 
/DRIVER
 
 
-
-#
-# MYTOOLS
-#   IA32 - Microsoft Visual Studio 2008 Team Suite
-#   X64  - Microsoft Visual Studio 2008 Team Suite
-#   EBC  - Intel EFI Byte Code Compiler
-#
-
-#   MYTOOLS  - Settings compatible with previous versions of 
tools_def.template
-*_MYTOOLS_*_*_FAMILY= MSFT
-
-##
-# ASL definitions
-##
-*_MYTOOLS_*_ASL_PATH= DEF(DEFAULT_WIN_ASL_BIN)
-*_MYTOOLS_*_ASL_FLAGS   = DEF(DEFAULT_WIN_ASL_FLAGS)
-*_MYTOOLS_*_ASL_OUTFLAGS= DEF(DEFAULT_WIN_ASL_OUTFLAGS)
-*_MYTOOLS_*_ASLCC_FLAGS = DEF(MSFT_ASLCC_FLAGS)
-*_MYTOOLS_*_ASLPP_FLAGS = DEF(MSFT_ASLPP_FLAGS)
-*_MYTOOLS_*_ASLDLINK_FLAGS  = DEF(MSFT_ASLDLINK_FLAGS)
-
-
-*_MYTOOLS_*_MAKE_FLAGS   = /nologo
-*_MYTOOLS_*_VFRPP_FLAGS  = /nologo /E /TC /DVFRCOMPILE 
/FI$(MODULE_NAME)StrDefs.h
-*_MYTOOLS_*_APP_FLAGS= /nologo /E /TC
-*_MYTOOLS_*_PP_FLAGS = /nologo /E /TC /FIAutoGen.h
-*_MYTOOLS_*_SLINK_FLAGS  = /nologo /LTCG
-
-*_MYTOOLS_*_ASM16_PATH  = DEF(VS2008_BIN)\ml.exe
-
-##
-# IA32 definitions
-##
-*_MYTOOLS_IA32_*_DLL= DEF(VS2008_DLL)
-
-*_MYTOOLS_IA32_MAKE_PATH= DEF(VS2008_BIN)\nmake.exe
-*_MYTOOLS_IA32_CC_PATH  = DEF(VS2008_BIN)\cl.exe
-*_MYTOOLS_IA32_SLINK_PATH   = DEF(VS2008_BIN)\lib.exe
-*_MYTOOLS_IA32_DLINK_PATH   = DEF(VS2008_BIN)\link.exe
-*_MYTOOLS_IA32_PP_PATH  = DEF(VS2008_BIN)\cl.exe
-*_MYTOOLS_IA32_VFRPP_PATH   = DEF(VS2008_BIN)\cl.exe
-*_MYTOOLS_IA32_APP_PATH = DEF(VS2008_BIN)\cl.exe
-*_MYTOOLS_IA32_ASM_PATH = DEF(VS2008_BIN)\ml.exe
-*_MYTOOLS_IA32_ASLCC_PATH   = DEF(VS2008_BIN)\cl.exe
-*_MYTOOLS_IA32_ASLPP_PATH   = DEF(VS2008_BIN)\cl.exe
-*_MYTOOLS_IA32_ASLDLINK_PATH= DEF(VS2008_BIN)\link.exe
-*_MYTOOLS_IA32_RC_PATH  = 

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

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

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

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index e73fec42bf..0e671d55bc 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -136,7 +136,6 @@ DEFINE ICC11_BIN64x86 = C:\Program Files 
(x86)\Intel\Compiler\DEF(ICC11_VERS
 DEFINE EBC_BIN  = C:\Program Files\Intel\EBC\Bin
 DEFINE EBC_BINx86   = C:\Program Files (x86)\Intel\EBC\Bin
 
-DEFINE ELFGCC_BIN   = /usr/bin
 
 DEFINE CYGWIN_BIN  = c:/cygwin/bin
 DEFINE CYGWIN_BINIA32  = 
c:/cygwin/opt/tiano/i386-tiano-pe/i386-tiano-pe/bin/
@@ -296,12 +295,6 @@ DEFINE DTC_BIN = ENV(DTC_PREFIX)dtc
 # Required to build platforms or ACPI tables:
 #   Intel(r) ACPI Compiler from
 #   https://acpica.org/downloads
-#   ELFGCC  -Linux-  Requires:
-# GCC(this tool chain uses whatever version of gcc 
and binutils that is installed in /usr/bin)
-#Optional:
-# Required to build platforms or ACPI tables:
-#   Intel(r) ACPI Compiler from
-#   https://acpica.org/downloads
 #   CYGGCC  -win32-  Requires:
 # CygWin, GCC 4.3.0, binutils 2.20.51.0.5
 # Microsoft Visual Studio 2005 or 2008
@@ -3999,79 +3992,6 @@ RELEASE_CLANG38_AARCH64_DLINK_FLAGS = 
DEF(CLANG38_AARCH64_DLINK_FLAGS) -flto -Wl
 *_CYGGCCxASL_EBC_SLINK_FLAGS= /lib /NOLOGO /MACHINE:EBC
 *_CYGGCCxASL_EBC_DLINK_FLAGS= "C:\Program 
Files\Intel\EBC\Lib\EbcLib.lib" /NOLOGO /NODEFAULTLIB /MACHINE:EBC /OPT:REF 
/ENTRY:$(IMAGE_ENTRY_POINT) /SUBSYSTEM:EFI_BOOT_SERVICE_DRIVER /ALIGN:32 /DRIVER
 
-
-#
-# Elf GCC - This configuration is used to compile on Linux boxes to produce elf
-#   binaries.
-#
-
-#   ELFGCC   - Linux ELF GCC
-*_ELFGCC_*_*_FAMILY = GCC
-*_ELFGCC_*_*_BUILDRULEFAMILY= GCCLD
-*_ELFGCC_*_MAKE_PATH= make
-
-*_ELFGCC_*_PP_FLAGS = -E -x assembler-with-cpp -include 
AutoGen.h
-*_ELFGCC_*_VFRPP_FLAGS  = -x c -E -P -DVFRCOMPILE --include 
$(MODULE_NAME)StrDefs.h
-
-##
-# ASL definitions
-##
-*_ELFGCC_*_ASL_PATH = DEF(UNIX_IASL_BIN)
-*_ELFGCC_*_ASL_FLAGS= DEF(IASL_FLAGS)
-*_ELFGCC_*_ASL_OUTFLAGS = DEF(IASL_OUTFLAGS)
-*_ELFGCC_*_ASLPP_FLAGS  = -x c -E -include AutoGen.h
-*_ELFGCC_*_ASLCC_FLAGS  = -x c
-*_ELFGCC_*_ASLDLINK_FLAGS   = DEF(GCC_DLINK_FLAGS_COMMON) --entry 
_ReferenceAcpiTable
-
-##
-# IA32 definitions
-##
-*_ELFGCC_IA32_OBJCOPY_PATH  = DEF(ELFGCC_BIN)/objcopy
-*_ELFGCC_IA32_CC_PATH   = DEF(ELFGCC_BIN)/gcc
-*_ELFGCC_IA32_SLINK_PATH= DEF(ELFGCC_BIN)/ar
-*_ELFGCC_IA32_DLINK_PATH= DEF(ELFGCC_BIN)/ld
-*_ELFGCC_IA32_ASM_PATH  = DEF(ELFGCC_BIN)/gcc
-*_ELFGCC_IA32_PP_PATH   = DEF(ELFGCC_BIN)/gcc
-*_ELFGCC_IA32_VFRPP_PATH= DEF(ELFGCC_BIN)/gcc
-*_ELFGCC_IA32_ASLCC_PATH= DEF(ELFGCC_BIN)/gcc
-*_ELFGCC_IA32_ASLPP_PATH= DEF(ELFGCC_BIN)/gcc
-*_ELFGCC_IA32_ASLDLINK_PATH = DEF(ELFGCC_BIN)/ld
-*_ELFGCC_IA32_RC_PATH   = DEF(ELFGCC_BIN)/objcopy
-
-*_ELFGCC_IA32_CC_FLAGS  = -m32 -g -fshort-wchar 
-fno-strict-aliasing -Wall -malign-double -include $(DEST_DIR_DEBUG)/AutoGen.h 
-DSTRING_ARRAY_NAME=$(BASE_NAME)Strings
-*_ELFGCC_IA32_SLINK_FLAGS   =
-*_ELFGCC_IA32_DLINK_FLAGS   = -melf_i386 -nostdlib --shared --entry 
$(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT) -Map 
$(DEST_DIR_DEBUG)/$(BASE_NAME).map
-#*_ELFGCC_IA32_DLINK_FLAGS  = -melf_i386 -nostdlib -n -q -Ttext 0x220 
--entry $(IMAGE_ENTRY_POINT) -u $(IMAGE_ENTRY_POINT)
-*_ELFGCC_IA32_ASM_FLAGS = -m32 -c -x assembler -imacros 
$(DEST_DIR_DEBUG)/AutoGen.h
-*_ELFGCC_IA32_PP_FLAGS  = -m32 -E -x assembler-with-cpp -include 
$(DEST_DIR_DEBUG)/AutoGen.h
-*_ELFGCC_IA32_VFRPP_FLAGS   = -x c -E -P -DVFRCOMPILE --include 
$(DEST_DIR_DEBUG)/$(MODULE_NAME)StrDefs.h
-*_ELFGCC_IA32_RC_FLAGS  = DEF(GCC_IA32_RC_FLAGS)
-*_ELFGCC_IA32_OBJCOPY_FLAGS =
-*_ELFGCC_IA32_NASM_FLAGS= -f elf32
-

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

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

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

diff --git a/OptionRomPkg/ReadMe.txt b/OptionRomPkg/ReadMe.txt
index 3f6538400f..99f97896da 100644
--- a/OptionRomPkg/ReadMe.txt
+++ b/OptionRomPkg/ReadMe.txt
@@ -14,5 +14,4 @@ CirrusLogic5430:
 
 Build Validation:
 ICC IA32 X64 IPF
-CYGWINGCC   IA32 X64
 
-- 
2.18.0.windows.1

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


[edk2] [MdePkg/BaseLib v1 0/1] Add new API CalculateCrc16()

2019-01-31 Thread Ming Huang
Crc16 is used in some cases, so add it to BaseLib.

Ming Huang (1):
  MdePkg BaseLib: Add new API CalculateCrc16()

 MdePkg/Include/Library/BaseLib.h  | 20 ++
 MdePkg/Library/BaseLib/CheckSum.c | 73 
 2 files changed, 93 insertions(+)

-- 
2.9.5

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


[edk2] [patch 2/2] MdePkg: Fix coding style issues

2019-01-31 Thread Dandan Bi
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1478

Fix issues that reported by Edk2 coding style check tool(ECC) that:
in Comment, <@param SystemTable> does NOT consistent with parameter
name MmSystemTable.

Cc: Ard Biesheuvel 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
---
 .../Library/StandaloneMmDriverEntryPoint.h   | 16 
 .../StandaloneMmDriverEntryPoint.c   |  4 ++--
 .../StandaloneMmServicesTableLib.c   |  4 ++--
 3 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/MdePkg/Include/Library/StandaloneMmDriverEntryPoint.h 
b/MdePkg/Include/Library/StandaloneMmDriverEntryPoint.h
index d618998622..fbc75add73 100644
--- a/MdePkg/Include/Library/StandaloneMmDriverEntryPoint.h
+++ b/MdePkg/Include/Library/StandaloneMmDriverEntryPoint.h
@@ -34,12 +34,12 @@ extern CONST UINT32   _gMmRevision;
   is an error status, then ProcessLibraryDestructorList() must be called.
   The return value from ProcessModuleEntryPointList() is returned.
   If _gMmRevision is not zero and MmSystemTable->Hdr.Revision is
   less than _gMmRevision, then return EFI_INCOMPATIBLE_VERSION.
 
-  @param  ImageHandle  The image handle of the Standalone MM Driver.
-  @param  SystemTable  A pointer to the EFI System Table.
+  @param  ImageHandleThe image handle of the Standalone MM Driver.
+  @param  MmSystemTable  A pointer to the MM System Table.
 
   @retval  EFI_SUCCESS   The Standalone MM Driver exited normally.
   @retval  EFI_INCOMPATIBLE_VERSION  _gMmRevision is greater than
  MmSystemTable->Hdr.Revision.
   @retval  Other Return value from
@@ -66,12 +66,12 @@ _ModuleEntryPoint (
   tools and those build tools are responsible for collecting the set of library
   instances, determine which ones have constructors, and calling the library
   constructors in the proper order based upon each of the library instances own
   dependencies.
 
-  @param  ImageHandle  The image handle of the Standalone MM Driver.
-  @param  SystemTable  A pointer to the MM System Table.
+  @param  ImageHandleThe image handle of the Standalone MM Driver.
+  @param  MmSystemTable  A pointer to the MM System Table.
 
 **/
 VOID
 EFIAPI
 ProcessLibraryConstructorList (
@@ -92,12 +92,12 @@ ProcessLibraryConstructorList (
   This function is auto generated by build tools and those build tools are
   responsible for collecting the set of library instances, determine which ones
   have destructors, and calling the library destructors in the proper order
   based upon each of the library instances own dependencies.
 
-  @param  ImageHandle  The image handle of the Standalone MM Driver.
-  @param  SystemTable  A pointer to the MM System Table.
+  @param  ImageHandleThe image handle of the Standalone MM Driver.
+  @param  MmSystemTable  A pointer to the MM System Table.
 
 **/
 VOID
 EFIAPI
 ProcessLibraryDestructorList (
@@ -113,12 +113,12 @@ ProcessLibraryDestructorList (
   This function calls the set of module entry points.
   This function is auto generated by build tools and those build tools are
   responsible for collecting the module entry points and calling them in a
   specified order.
 
-  @param  ImageHandle  The image handle of the Standalone MM Driver.
-  @param  SystemTable  A pointer to the EFI System Table.
+  @param  ImageHandleThe image handle of the Standalone MM Driver.
+  @param  MmSystemTable  A pointer to the MM System Table.
 
   @retval  EFI_SUCCESS   The Standalone MM Driver executed normally.
   @retval  !EFI_SUCCESS  The Standalone MM Driver failed to execute normally.
 **/
 EFI_STATUS
diff --git 
a/MdePkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.c 
b/MdePkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.c
index 4fb494d8cb..b665233142 100644
--- a/MdePkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.c
+++ b/MdePkg/Library/StandaloneMmDriverEntryPoint/StandaloneMmDriverEntryPoint.c
@@ -32,12 +32,12 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
   is an error status, then ProcessLibraryDestructorList() must be called.
   The return value from ProcessModuleEntryPointList() is returned.
   If _gMmRevision is not zero and SystemTable->Hdr.Revision is
   less than _gMmRevision, then return EFI_INCOMPATIBLE_VERSION.
 
-  @param  ImageHandle  The image handle of the Standalone MM Driver.
-  @param  SystemTable  A pointer to the EFI System Table.
+  @param  ImageHandleThe image handle of the Standalone MM Driver.
+  @param  MmSystemTable  A pointer to the MM System Table.
 
   @retval  EFI_SUCCESS   The Standalone MM Driver exited normally.
   @retval  EFI_INCOMPATIBLE_VERSION  _gMmRevision is greater than
  MmSystemTable->Hdr.Revision.
   @retval  Other Return value 

[edk2] [MdePkg/BaseLib v1 1/1] MdePkg BaseLib: Add new API CalculateCrc16()

2019-01-31 Thread Ming Huang
CalculateCrc16() bases on the initialized mCrcTable. When CalculateCrc16()
is used, mCrcTable16 will take 512Bytes size in the image. When
CalculateCrc16() is not used, mCrcTable16 will not be built in the image,
and no size impact.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ming Huang 
---
 MdePkg/Include/Library/BaseLib.h  | 20 ++
 MdePkg/Library/BaseLib/CheckSum.c | 73 
 2 files changed, 93 insertions(+)

diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index 1eb842384ee2..956b971e5c69 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -4855,6 +4855,26 @@ CalculateCrc32(
   IN  UINTNLength
   );
 
+/**
+  Computes and returns a 16-bit CRC for a data buffer.
+  CRC16 value bases on CCITT.
+
+  If Buffer is NULL, then ASSERT().
+  If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
+
+  @param[in]  Buffer   A pointer to the buffer on which the 16-bit CRC is 
to be computed.
+  @param[in]  Length  The number of bytes in the buffer Data.
+
+  @retval Crc16The 16-bit CRC was computed for the data buffer.
+
+**/
+UINT16
+EFIAPI
+CalculateCrc16(
+  IN  VOID *Buffer,
+  IN  UINTNLength
+  );
+
 //
 // Base Library CPU Functions
 //
diff --git a/MdePkg/Library/BaseLib/CheckSum.c 
b/MdePkg/Library/BaseLib/CheckSum.c
index 03d49afc5e6c..4e27aebe44bc 100644
--- a/MdePkg/Library/BaseLib/CheckSum.c
+++ b/MdePkg/Library/BaseLib/CheckSum.c
@@ -630,3 +630,76 @@ CalculateCrc32(
 
   return Crc ^ 0x;
 }
+
+GLOBAL_REMOVE_IF_UNREFERENCED CONST UINT16  mCrcTable16[256] = {
+  0x, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7,
+  0x8108, 0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF,
+  0x1231, 0x0210, 0x3273, 0x2252, 0x52B5, 0x4294, 0x72F7, 0x62D6,
+  0x9339, 0x8318, 0xB37B, 0xA35A, 0xD3BD, 0xC39C, 0xF3FF, 0xE3DE,
+  0x2462, 0x3443, 0x0420, 0x1401, 0x64E6, 0x74C7, 0x44A4, 0x5485,
+  0xA56A, 0xB54B, 0x8528, 0x9509, 0xE5EE, 0xF5CF, 0xC5AC, 0xD58D,
+  0x3653, 0x2672, 0x1611, 0x0630, 0x76D7, 0x66F6, 0x5695, 0x46B4,
+  0xB75B, 0xA77A, 0x9719, 0x8738, 0xF7DF, 0xE7FE, 0xD79D, 0xC7BC,
+  0x48C4, 0x58E5, 0x6886, 0x78A7, 0x0840, 0x1861, 0x2802, 0x3823,
+  0xC9CC, 0xD9ED, 0xE98E, 0xF9AF, 0x8948, 0x9969, 0xA90A, 0xB92B,
+  0x5AF5, 0x4AD4, 0x7AB7, 0x6A96, 0x1A71, 0x0A50, 0x3A33, 0x2A12,
+  0xDBFD, 0xCBDC, 0xFBBF, 0xEB9E, 0x9B79, 0x8B58, 0xBB3B, 0xAB1A,
+  0x6CA6, 0x7C87, 0x4CE4, 0x5CC5, 0x2C22, 0x3C03, 0x0C60, 0x1C41,
+  0xEDAE, 0xFD8F, 0xCDEC, 0xDDCD, 0xAD2A, 0xBD0B, 0x8D68, 0x9D49,
+  0x7E97, 0x6EB6, 0x5ED5, 0x4EF4, 0x3E13, 0x2E32, 0x1E51, 0x0E70,
+  0xFF9F, 0xEFBE, 0xDFDD, 0xCFFC, 0xBF1B, 0xAF3A, 0x9F59, 0x8F78,
+  0x9188, 0x81A9, 0xB1CA, 0xA1EB, 0xD10C, 0xC12D, 0xF14E, 0xE16F,
+  0x1080, 0x00A1, 0x30C2, 0x20E3, 0x5004, 0x4025, 0x7046, 0x6067,
+  0x83B9, 0x9398, 0xA3FB, 0xB3DA, 0xC33D, 0xD31C, 0xE37F, 0xF35E,
+  0x02B1, 0x1290, 0x22F3, 0x32D2, 0x4235, 0x5214, 0x6277, 0x7256,
+  0xB5EA, 0xA5CB, 0x95A8, 0x8589, 0xF56E, 0xE54F, 0xD52C, 0xC50D,
+  0x34E2, 0x24C3, 0x14A0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
+  0xA7DB, 0xB7FA, 0x8799, 0x97B8, 0xE75F, 0xF77E, 0xC71D, 0xD73C,
+  0x26D3, 0x36F2, 0x0691, 0x16B0, 0x6657, 0x7676, 0x4615, 0x5634,
+  0xD94C, 0xC96D, 0xF90E, 0xE92F, 0x99C8, 0x89E9, 0xB98A, 0xA9AB,
+  0x5844, 0x4865, 0x7806, 0x6827, 0x18C0, 0x08E1, 0x3882, 0x28A3,
+  0xCB7D, 0xDB5C, 0xEB3F, 0xFB1E, 0x8BF9, 0x9BD8, 0xABBB, 0xBB9A,
+  0x4A75, 0x5A54, 0x6A37, 0x7A16, 0x0AF1, 0x1AD0, 0x2AB3, 0x3A92,
+  0xFD2E, 0xED0F, 0xDD6C, 0xCD4D, 0xBDAA, 0xAD8B, 0x9DE8, 0x8DC9,
+  0x7C26, 0x6C07, 0x5C64, 0x4C45, 0x3CA2, 0x2C83, 0x1CE0, 0x0CC1,
+  0xEF1F, 0xFF3E, 0xCF5D, 0xDF7C, 0xAF9B, 0xBFBA, 0x8FD9, 0x9FF8,
+  0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0
+};
+
+/**
+  Computes and returns a 16-bit CRC for a data buffer.
+  CRC16 value bases on CCITT.
+
+  If Buffer is NULL, then ASSERT().
+  If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
+
+  @param[in]  Buffer   A pointer to the buffer on which the 16-bit CRC is 
to be computed.
+  @param[in]  Length  The number of bytes in the buffer Data.
+
+  @retval Crc16The 16-bit CRC was computed for the data buffer.
+
+**/
+UINT16
+EFIAPI
+CalculateCrc16(
+  IN  VOID *Buffer,
+  IN  UINTNLength
+  )
+{
+  UINT16  Crc;
+  UINT8   *Ptr;
+
+  ASSERT (Buffer != NULL);
+  ASSERT (Length <= (MAX_ADDRESS - ((UINTN) Buffer) + 1));
+
+  Crc = 0;
+  Ptr = (UINT8 *)Buffer;
+  while (Length) {
+Crc = mCrcTable16[((UINT8)((Crc >> 8) & 0xff)) ^ *(Ptr++)] ^
+((UINT16)(Crc << 8));
+Length--;
+  }
+
+  return Crc;
+}
+
-- 
2.9.5

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


[edk2] [patch 0/2] Fix coding style issues in MdeModulePkg and MdePkg

2019-01-31 Thread Dandan Bi
Cc: Ard Biesheuvel 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Hao Wu 
Dandan Bi (2):
  MdeModulePkg: Fix coding style issues
  MdePkg: Fix coding style issues

 .../FaultTolerantWriteSmmCommon.h|  4 ++--
 .../FaultTolerantWriteStandaloneMm.c |  2 +-
 .../FaultTolerantWriteTraditionalMm.c|  2 +-
 .../Variable/RuntimeDxe/PrivilegePolymorphic.h   |  4 ++--
 .../Variable/RuntimeDxe/VariableStandaloneMm.c   |  6 +++---
 .../Variable/RuntimeDxe/VariableTraditionalMm.c  |  4 ++--
 .../Library/StandaloneMmDriverEntryPoint.h   | 16 
 .../StandaloneMmDriverEntryPoint.c   |  4 ++--
 .../StandaloneMmServicesTableLib.c   |  4 ++--
 9 files changed, 23 insertions(+), 23 deletions(-)

-- 
2.18.0.windows.1

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


[edk2] [patch 1/2] MdeModulePkg: Fix coding style issues

2019-01-31 Thread Dandan Bi
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1479

Fix issues that reported by Edk2 coding style check tool(ECC) that:
Comment description should end with period '.'

Cc: Ard Biesheuvel 
Cc: Jian J Wang 
Cc: Hao Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
---
 .../FaultTolerantWriteDxe/FaultTolerantWriteSmmCommon.h | 4 ++--
 .../FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c  | 2 +-
 .../FaultTolerantWriteDxe/FaultTolerantWriteTraditionalMm.c | 2 +-
 .../Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h| 4 ++--
 .../Universal/Variable/RuntimeDxe/VariableStandaloneMm.c| 6 +++---
 .../Universal/Variable/RuntimeDxe/VariableTraditionalMm.c   | 4 ++--
 6 files changed, 11 insertions(+), 11 deletions(-)

diff --git 
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmCommon.h 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmCommon.h
index 61293ca864..cf1aef7ca4 100644
--- a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmCommon.h
+++ b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmCommon.h
@@ -76,11 +76,11 @@ typedef struct {
   BOOLEAN   Complete;
   UINT8 Data[1];
 } SMM_FTW_GET_LAST_WRITE_HEADER;
 
 /**
-  Shared entry point of the module
+  Shared entry point of the module.
 
   @retval EFI_SUCCESS   The initialization finished successfully.
   @retval EFI_OUT_OF_RESOURCES  Allocate memory error
   @retval EFI_INVALID_PARAMETER Workspace or Spare block does not exist
 
@@ -107,11 +107,11 @@ FtwSmmIsBufferOutsideSmmValid (
   IN EFI_PHYSICAL_ADDRESS  Buffer,
   IN UINT64Length
   );
 
 /**
-  Notify the system that the SMM FTW driver is ready
+  Notify the system that the SMM FTW driver is ready.
 **/
 VOID
 FtwNotifySmmReady (
   VOID
   );
diff --git 
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c
index 8a4ea5b476..c2aa501465 100644
--- 
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c
+++ 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c
@@ -63,11 +63,11 @@ FtwCalculateCrc32 (
 {
   return CalculateCrc32 (Buffer, Length);
 }
 
 /**
-  Notify the system that the SMM FTW driver is ready
+  Notify the system that the SMM FTW driver is ready.
 **/
 VOID
 FtwNotifySmmReady (
   VOID
   )
diff --git 
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteTraditionalMm.c
 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteTraditionalMm.c
index 0981c3c2a9..7c76e1f756 100644
--- 
a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteTraditionalMm.c
+++ 
b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteTraditionalMm.c
@@ -70,11 +70,11 @@ FtwCalculateCrc32 (
 
   return ReturnValue;
 }
 
 /**
-  Notify the system that the SMM FTW driver is ready
+  Notify the system that the SMM FTW driver is ready.
 **/
 VOID
 FtwNotifySmmReady (
   VOID
   )
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
index 0a886558f4..9b294e6b36 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
@@ -96,19 +96,19 @@ VOID
 VariableSpeculationBarrier (
   VOID
   );
 
 /**
-  Notify the system that the SMM variable driver is ready
+  Notify the system that the SMM variable driver is ready.
 **/
 VOID
 VariableNotifySmmReady (
   VOID
   );
 
 /**
-  Notify the system that the SMM variable write driver is ready
+  Notify the system that the SMM variable write driver is ready.
 **/
 VOID
 VariableNotifySmmWriteReady (
   VOID
   );
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
index 1e87ccfb5d..2eed038054 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
@@ -36,31 +36,31 @@ VariableSmmIsBufferOutsideSmmValid (
 {
   return TRUE;
 }
 
 /**
-  Notify the system that the SMM variable driver is ready
+  Notify the system that the SMM variable driver is ready.
 **/
 VOID
 VariableNotifySmmReady (
   VOID
   )
 {
 }
 
 /**
-  Notify the system that the SMM variable write driver is ready
+  Notify the system that the SMM variable write driver is ready.
 **/
 VOID
 VariableNotifySmmWriteReady (
   VOID
   )
 {
 }
 
 /**
-  Variable service MM driver entry point
+  Variable service MM driver entry point.
 
   @param[in] ImageHandleA handle for the image that is initializing this
 driver
   @param[in] MmSystemTable  A pointer to the MM system table
 
diff --git 

Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widths

2019-01-31 Thread Jeff Brasen



-Original Message-
From: Wu, Hao A  
Sent: Thursday, January 31, 2019 10:56 PM
To: Jeff Brasen ; edk2-devel@lists.01.org
Cc: Edgar Handal 
Subject: RE: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widths

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Jeff Brasen
> Sent: Thursday, January 31, 2019 7:59 AM
> To: edk2-devel@lists.01.org
> Cc: Edgar Handal; Jeff Brasen
> Subject: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO 
> widths
> 
> From: Edgar Handal 
> 
> Use 16-bit and 32-bit IO widths for SDMMC MMIO to prevent all register 
> accesses from being split up into 8-bit accesses.
> 
> The SDHCI specification states that the registers shall be accessable 
> in byte, word, and double word accesses.

Hi,

Thanks for the contribution. The change seems good to me.

Just curious, if the accesses are always slit into byte(8-bit), is there any 
issue or performance impact is encountered during your usage?

It will be helpful to get more information on the purpose of the patch.
Thanks.

Best Regards,
Hao Wu

[JMB] We were working with a simulation module that has some issues when 
accessing 16 or 32 bit registers by byte (This should be supported per the 
SDHCI specification.), and this patch resolves this while we work on getting 
the model fixed. This should also optimize performance as there will less 
read/write instructions (My guess is this is a marginal improvement as most of 
the SD access time would be DMA operations.)

Thanks,
Jeff
 


> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jeff Brasen 
> ---
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 25
> 
>  1 file changed, 21 insertions(+), 4 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index 5aec8c6..82f4493 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -152,19 +152,36 @@ SdMmcHcRwMmio (
>)
>  {
>EFI_STATUS   Status;
> +  EFI_PCI_IO_PROTOCOL_WIDTHWidth;
> 
>if ((PciIo == NULL) || (Data == NULL))  {
>  return EFI_INVALID_PARAMETER;
>}
> 
> -  if ((Count != 1) && (Count != 2) && (Count != 4) && (Count != 8)) {
> -return EFI_INVALID_PARAMETER;
> +  switch (Count) {
> +case 1:
> +  Width = EfiPciIoWidthUint8;
> +  break;
> +case 2:
> +  Width = EfiPciIoWidthUint16;
> +  Count = 1;
> +  break;
> +case 4:
> +  Width = EfiPciIoWidthUint32;
> +  Count = 1;
> +  break;
> +case 8:
> +  Width = EfiPciIoWidthUint32;
> +  Count = 2;
> +  break;
> +default:
> +  return EFI_INVALID_PARAMETER;
>}
> 
>if (Read) {
>  Status = PciIo->Mem.Read (
>PciIo,
> -  EfiPciIoWidthUint8,
> +  Width,
>BarIndex,
>(UINT64) Offset,
>Count,
> @@ -173,7 +190,7 @@ SdMmcHcRwMmio (
>} else {
>  Status = PciIo->Mem.Write (
>PciIo,
> -  EfiPciIoWidthUint8,
> +  Width,
>BarIndex,
>(UINT64) Offset,
>Count,
> --
> 2.7.4
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
---
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.
---
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [MdePkg/BaseLib v1 1/1] MdePkg BaseLib: Add new API CalculateCrc16()

2019-01-31 Thread Ming Huang



On 2/1/2019 2:37 PM, Ni, Ray wrote:
> There is an CRC16 calculation implementation in
> SourceLevelDebugPkg/Library/DebugAgent/DebugAgentCommon/DebugAgent.c
> 
> Does your implementation generate the same CRC16 as above one?

It is not the same with above one.

> 
>> -Original Message-
>> From: edk2-devel  On Behalf Of Ming
>> Huang
>> Sent: Friday, February 1, 2019 2:02 PM
>> To: linaro-u...@lists.linaro.org; edk2-devel@lists.01.org; Kinney, Michael D
>> ; Gao, Liming 
>> Cc: huangmin...@huawei.com; Dong, Eric ;
>> zhangjinso...@huawei.com; Zeng, Star ;
>> wai...@126.com; wanghuiqi...@huawei.com; huangda...@hisilicon.com
>> Subject: [edk2] [MdePkg/BaseLib v1 1/1] MdePkg BaseLib: Add new API
>> CalculateCrc16()
>>
>> CalculateCrc16() bases on the initialized mCrcTable. When CalculateCrc16() is
>> used, mCrcTable16 will take 512Bytes size in the image. When
>> CalculateCrc16() is not used, mCrcTable16 will not be built in the image, and
>> no size impact.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ming Huang 
>> ---
>>  MdePkg/Include/Library/BaseLib.h  | 20 ++
>> MdePkg/Library/BaseLib/CheckSum.c | 73 
>>  2 files changed, 93 insertions(+)
>>
>> diff --git a/MdePkg/Include/Library/BaseLib.h
>> b/MdePkg/Include/Library/BaseLib.h
>> index 1eb842384ee2..956b971e5c69 100644
>> --- a/MdePkg/Include/Library/BaseLib.h
>> +++ b/MdePkg/Include/Library/BaseLib.h
>> @@ -4855,6 +4855,26 @@ CalculateCrc32(
>>IN  UINTNLength
>>);
>>
>> +/**
>> +  Computes and returns a 16-bit CRC for a data buffer.
>> +  CRC16 value bases on CCITT.
>> +
>> +  If Buffer is NULL, then ASSERT().
>> +  If Length is greater than (MAX_ADDRESS - Buffer + 1), then ASSERT().
>> +
>> +  @param[in]  Buffer   A pointer to the buffer on which the 16-bit CRC 
>> is to
>> be computed.
>> +  @param[in]  Length  The number of bytes in the buffer Data.
>> +
>> +  @retval Crc16The 16-bit CRC was computed for the data buffer.
>> +
>> +**/
>> +UINT16
>> +EFIAPI
>> +CalculateCrc16(
>> +  IN  VOID *Buffer,
>> +  IN  UINTNLength
>> +  );
>> +
>>  //
>>  // Base Library CPU Functions
>>  //
>> diff --git a/MdePkg/Library/BaseLib/CheckSum.c
>> b/MdePkg/Library/BaseLib/CheckSum.c
>> index 03d49afc5e6c..4e27aebe44bc 100644
>> --- a/MdePkg/Library/BaseLib/CheckSum.c
>> +++ b/MdePkg/Library/BaseLib/CheckSum.c
>> @@ -630,3 +630,76 @@ CalculateCrc32(
>>
>>return Crc ^ 0x;
>>  }
>> +
>> +GLOBAL_REMOVE_IF_UNREFERENCED CONST UINT16  mCrcTable16[256] =
>> {
>> +  0x, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7,
>> +  0x8108, 0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF,
>> +  0x1231, 0x0210, 0x3273, 0x2252, 0x52B5, 0x4294, 0x72F7, 0x62D6,
>> +  0x9339, 0x8318, 0xB37B, 0xA35A, 0xD3BD, 0xC39C, 0xF3FF, 0xE3DE,
>> +  0x2462, 0x3443, 0x0420, 0x1401, 0x64E6, 0x74C7, 0x44A4, 0x5485,
>> +  0xA56A, 0xB54B, 0x8528, 0x9509, 0xE5EE, 0xF5CF, 0xC5AC, 0xD58D,
>> +  0x3653, 0x2672, 0x1611, 0x0630, 0x76D7, 0x66F6, 0x5695, 0x46B4,
>> +  0xB75B, 0xA77A, 0x9719, 0x8738, 0xF7DF, 0xE7FE, 0xD79D, 0xC7BC,
>> +  0x48C4, 0x58E5, 0x6886, 0x78A7, 0x0840, 0x1861, 0x2802, 0x3823,
>> +  0xC9CC, 0xD9ED, 0xE98E, 0xF9AF, 0x8948, 0x9969, 0xA90A, 0xB92B,
>> +  0x5AF5, 0x4AD4, 0x7AB7, 0x6A96, 0x1A71, 0x0A50, 0x3A33, 0x2A12,
>> +  0xDBFD, 0xCBDC, 0xFBBF, 0xEB9E, 0x9B79, 0x8B58, 0xBB3B, 0xAB1A,
>> +  0x6CA6, 0x7C87, 0x4CE4, 0x5CC5, 0x2C22, 0x3C03, 0x0C60, 0x1C41,
>> +  0xEDAE, 0xFD8F, 0xCDEC, 0xDDCD, 0xAD2A, 0xBD0B, 0x8D68, 0x9D49,
>> +  0x7E97, 0x6EB6, 0x5ED5, 0x4EF4, 0x3E13, 0x2E32, 0x1E51, 0x0E70,
>> +  0xFF9F, 0xEFBE, 0xDFDD, 0xCFFC, 0xBF1B, 0xAF3A, 0x9F59, 0x8F78,
>> +  0x9188, 0x81A9, 0xB1CA, 0xA1EB, 0xD10C, 0xC12D, 0xF14E, 0xE16F,
>> +  0x1080, 0x00A1, 0x30C2, 0x20E3, 0x5004, 0x4025, 0x7046, 0x6067,
>> +  0x83B9, 0x9398, 0xA3FB, 0xB3DA, 0xC33D, 0xD31C, 0xE37F, 0xF35E,
>> +  0x02B1, 0x1290, 0x22F3, 0x32D2, 0x4235, 0x5214, 0x6277, 0x7256,
>> +  0xB5EA, 0xA5CB, 0x95A8, 0x8589, 0xF56E, 0xE54F, 0xD52C, 0xC50D,
>> +  0x34E2, 0x24C3, 0x14A0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
>> +  0xA7DB, 0xB7FA, 0x8799, 0x97B8, 0xE75F, 0xF77E, 0xC71D, 0xD73C,
>> +  0x26D3, 0x36F2, 0x0691, 0x16B0, 0x6657, 0x7676, 0x4615, 0x5634,
>> +  0xD94C, 0xC96D, 0xF90E, 0xE92F, 0x99C8, 0x89E9, 0xB98A, 0xA9AB,
>> +  0x5844, 0x4865, 0x7806, 0x6827, 0x18C0, 0x08E1, 0x3882, 0x28A3,
>> +  0xCB7D, 0xDB5C, 0xEB3F, 0xFB1E, 0x8BF9, 0x9BD8, 0xABBB, 0xBB9A,
>> +  0x4A75, 0x5A54, 0x6A37, 0x7A16, 0x0AF1, 0x1AD0, 0x2AB3, 0x3A92,
>> +  0xFD2E, 0xED0F, 0xDD6C, 0xCD4D, 0xBDAA, 0xAD8B, 0x9DE8, 0x8DC9,
>> +  0x7C26, 0x6C07, 0x5C64, 0x4C45, 0x3CA2, 0x2C83, 0x1CE0, 0x0CC1,
>> +  0xEF1F, 0xFF3E, 0xCF5D, 0xDF7C, 0xAF9B, 0xBFBA, 0x8FD9, 0x9FF8,
>> +  0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0 };
>> +
>> +/**
>> +  Computes and returns a 16-bit CRC for a data buffer.
>> +  CRC16 value bases on CCITT.
>> +
>> +  If Buffer is NULL, 

[edk2] [PATCH V2] BaseTools: PCD value incorrect in structure pcd sku case.

2019-01-31 Thread Fan, ZhijuX
Defined 2 PCDs(Test4 & Test401) and 2 SKUs(DEFAULT & _),
then set "SKUID_Defines" to ALL, for FixedAtBuild
gEfiStructuredPcdPkgTokenSpaceGuid. Test401 in this case,
its value should get from "Default" SKU, not from "_" SKU,
but we does not set value in SKU "_" in dsc, so Test401
should only display the value get from dec.

Missing the map() function causes SKU specific items to
not be deleted

Cc: Bob Feng 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhiju.Fan 
---
 BaseTools/Source/Python/Workspace/DscBuildData.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/BaseTools/Source/Python/Workspace/DscBuildData.py 
b/BaseTools/Source/Python/Workspace/DscBuildData.py
index a96502b4bf..afcf99e66b 100644
--- a/BaseTools/Source/Python/Workspace/DscBuildData.py
+++ b/BaseTools/Source/Python/Workspace/DscBuildData.py
@@ -1613,7 +1613,7 @@ class DscBuildData(PlatformBuildClassObject):
 elif TAB_DEFAULT in pcd.SkuInfoList and TAB_COMMON in 
pcd.SkuInfoList:
 del pcd.SkuInfoList[TAB_COMMON]
 
-list((self.FilterSkuSettings, [Pcds[pcdkey] for pcdkey in Pcds if 
Pcds[pcdkey].Type in DynamicPcdType]))
+list(map(self.FilterSkuSettings, [Pcds[pcdkey] for pcdkey in Pcds if 
Pcds[pcdkey].Type in DynamicPcdType]))
 return Pcds
 @cached_property
 def PlatformUsedPcds(self):
-- 
2.14.1.windows.1

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


Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO widths

2019-01-31 Thread Wu, Hao A
> -Original Message-
> From: Jeff Brasen [mailto:jbra...@nvidia.com]
> Sent: Friday, February 01, 2019 3:12 PM
> To: Wu, Hao A; edk2-devel@lists.01.org
> Cc: Edgar Handal
> Subject: RE: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO
> widths
> 
> 
> 
> -Original Message-
> From: Wu, Hao A 
> Sent: Thursday, January 31, 2019 10:56 PM
> To: Jeff Brasen ; edk2-devel@lists.01.org
> Cc: Edgar Handal 
> Subject: RE: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO
> widths
> 
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Jeff Brasen
> > Sent: Thursday, January 31, 2019 7:59 AM
> > To: edk2-devel@lists.01.org
> > Cc: Edgar Handal; Jeff Brasen
> > Subject: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Use 16/32-bit IO
> > widths
> >
> > From: Edgar Handal 
> >
> > Use 16-bit and 32-bit IO widths for SDMMC MMIO to prevent all register
> > accesses from being split up into 8-bit accesses.
> >
> > The SDHCI specification states that the registers shall be accessable
> > in byte, word, and double word accesses.
> 
> Hi,
> 
> Thanks for the contribution. The change seems good to me.
> 
> Just curious, if the accesses are always slit into byte(8-bit), is there any 
> issue or
> performance impact is encountered during your usage?
> 
> It will be helpful to get more information on the purpose of the patch.
> Thanks.
> 
> Best Regards,
> Hao Wu
> 
> [JMB] We were working with a simulation module that has some issues when
> accessing 16 or 32 bit registers by byte (This should be supported per the 
> SDHCI
> specification.), and this patch resolves this while we work on getting the 
> model
> fixed. This should also optimize performance as there will less read/write
> instructions (My guess is this is a marginal improvement as most of the SD
> access time would be DMA operations.)

Thanks Jeff,

Got it. May I know is it possible for you to collect some performance data
for the change?

Meanwhile, I will test this patch with the boards I own and try to collect
some data. Please grant me some time for this. Since the current
implementation does not violate the spec, let us evaluate whether better
performance will be brought.

Best Regards,
Hao Wu

> 
> Thanks,
> Jeff
> 
> 
> 
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Jeff Brasen 
> > ---
> >  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 25
> > 
> >  1 file changed, 21 insertions(+), 4 deletions(-)
> >
> > diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > index 5aec8c6..82f4493 100644
> > --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> > @@ -152,19 +152,36 @@ SdMmcHcRwMmio (
> >)
> >  {
> >EFI_STATUS   Status;
> > +  EFI_PCI_IO_PROTOCOL_WIDTHWidth;
> >
> >if ((PciIo == NULL) || (Data == NULL))  {
> >  return EFI_INVALID_PARAMETER;
> >}
> >
> > -  if ((Count != 1) && (Count != 2) && (Count != 4) && (Count != 8)) {
> > -return EFI_INVALID_PARAMETER;
> > +  switch (Count) {
> > +case 1:
> > +  Width = EfiPciIoWidthUint8;
> > +  break;
> > +case 2:
> > +  Width = EfiPciIoWidthUint16;
> > +  Count = 1;
> > +  break;
> > +case 4:
> > +  Width = EfiPciIoWidthUint32;
> > +  Count = 1;
> > +  break;
> > +case 8:
> > +  Width = EfiPciIoWidthUint32;
> > +  Count = 2;
> > +  break;
> > +default:
> > +  return EFI_INVALID_PARAMETER;
> >}
> >
> >if (Read) {
> >  Status = PciIo->Mem.Read (
> >PciIo,
> > -  EfiPciIoWidthUint8,
> > +  Width,
> >BarIndex,
> >(UINT64) Offset,
> >Count,
> > @@ -173,7 +190,7 @@ SdMmcHcRwMmio (
> >} else {
> >  Status = PciIo->Mem.Write (
> >PciIo,
> > -  EfiPciIoWidthUint8,
> > +  Width,
> >BarIndex,
> >(UINT64) Offset,
> >Count,
> > --
> > 2.7.4
> >
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> ---
> 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.
> ---

Re: [edk2] [Patch v2 00/33] BaseTools python3 migration patch set

2019-01-31 Thread Feng, Bob C
I have pushed py3 patch set to edk2 master.

Thanks,
Bob

-Original Message-
From: Gao, Liming 
Sent: Thursday, January 31, 2019 4:24 PM
To: Feng, Bob C ; Laszlo Ersek 
Cc: edk2-devel@lists.01.org
Subject: RE: [edk2] [Patch v2 00/33] BaseTools python3 migration patch set

Bob:
  I have no other comments on this patch set. Reviewed-by: Liming Gao 


Thanks
Liming
> -Original Message-
> From: Feng, Bob C
> Sent: Wednesday, January 30, 2019 1:25 PM
> To: Gao, Liming ; Laszlo Ersek 
> 
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] [Patch v2 00/33] BaseTools python3 migration patch 
> set
> 
> I agree this proposal.
> I plan to push python3 patch set to edk2 master in this Friday 
> morning, Feb.1 PRC time if there is no more comments or no critical issues 
> found.
> 
> Thanks,
> Bob
> 
> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, January 30, 2019 9:53 AM
> To: Laszlo Ersek ; Feng, Bob C 
> 
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] [Patch v2 00/33] BaseTools python3 migration patch 
> set
> 
> Laszlo:
>  I agree your proposal. Push this patch set first if no other comments, then 
> continue to do minor bug fix.
> 
> Thanks
> Liming
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf 
> > Of Laszlo Ersek
> > Sent: Tuesday, January 29, 2019 9:07 PM
> > To: Feng, Bob C 
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] [Patch v2 00/33] BaseTools python3 migration 
> > patch set
> >
> > Hi Bob,
> >
> > On 01/29/19 03:05, Feng, Bob C wrote:
> > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=55
> > >
> > > V2:
> > > The python files under CParser4 folder of ECC/Eot tool are 
> > > generated by antlr4 and forpython3 usage.
> > > They have python3 specific syntax, for example the data type 
> > > declaration for the arguments of a function. That is not 
> > > compitable with python2. this patch is to remove these syntax.
> > >
> > > The version2 patch set is commit to 
> > > https://github.com/BobCF/edk2.git branch py3basetools_v2
> >
> > (reusing the "test plan" from my email at 
> >  > dh
> > at.com>:)
> >
> > I ran the following tests, at commit 6edb6bd9f182 ("BaseTools: Eot 
> > tool
> > Python3 adaption", 2019-01-29). Each test was performed in a clean 
> > tree (after running "git clean -ffdx") and clean environment (I 
> > re-sourced "edksetup.sh" for each test in separation). In addition, 
> > the base tools were rebuilt (again from a clean tree) for each test, 
> > with the following command [1]:
> >
> >   nice make -C "$EDK_TOOLS_PATH" -j $(getconf _NPROCESSORS_ONLN)
> >
> > (a) On my RHEL7.5 Workstation laptop, I have both the system-level 
> > python packages installed (python-2.7.5-69.el7_5.x86_64), and the 
> > extra
> > python-3.4 stuff from EPEL-7 (python34-3.4.9-1.el7.x86_64).
> >
> > (a1) Didn't set either PYTHON3_ENABLE or PYTHON_COMMAND. The build 
> > utility picked
> >
> >   PYTHON_COMMAND   = /usr/bin/python3.4
> >
> > and I successfully built OvmfPkg for IA32, IA32X64, and X64; also 
> > ArmVirtQemu for AARCH64. The built firmware images passed a smoke 
> > test too.
> >
> > (a2) I removed all the python34 packages (and the dependent 
> > packages) from my laptop. Didn't set either of PYTHON3_ENABLE and 
> > PYTHON_COMMAND.
> > (This is the configuration what a "normal" RHEL7 environment would
> > provide.) The "build" utility didn't print any PYTHON_COMMAND 
> > setting, but the same fw platform builds as in (a1) completed fine. 
> > The smoke tests passed again as well.
> >
> > (b) RHEL-8 virtual machine, with "/usr/bin/python3.6" from 
> > python36-3.6.6-18.el8.x86_64, and "/usr/libexec/platform-python" 
> > from platform-python-3.6.8-1.el8.x86_64.
> >
> > (b1) Didn't set either PYTHON3_ENABLE or PYTHON_COMMAND. The build 
> > utility picked
> >
> >   PYTHON_COMMAND   = /usr/bin/python3.6
> >
> > and I successfully built OvmfPkg for IA32, IA32X64, and X64. (I 
> > don't have a cross-compiler installed in this environment yet, nor a 
> > RHEL8
> > aarch64 KVM guest, so I couldn't test ArmVirtQemu for now).
> >
> > (b2) I set PYTHON_COMMAND to "/usr/libexec/platform-python". Didn't 
> > set PYTHON3_ENABLE. The same builds as in (b1) succeeded.
> >
> >
> > For the series:
> >
> > Tested-by: Laszlo Ersek 
> >
> > Given that the testing is quite time consuming, I suggest that we 
> > push
> > v2 (assuming reviewers don't find critical issues), and address 
> > small issues incrementally.
> >
> > Thanks!
> > Laszlo
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [patch 1/2] MdeModulePkg: Fix coding style issues

2019-01-31 Thread Wu, Hao A
> -Original Message-
> From: Bi, Dandan
> Sent: Friday, February 01, 2019 2:02 PM
> To: edk2-devel@lists.01.org
> Cc: Ard Biesheuvel; Wang, Jian J; Wu, Hao A
> Subject: [patch 1/2] MdeModulePkg: Fix coding style issues
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1479
> 
> Fix issues that reported by Edk2 coding style check tool(ECC) that:
> Comment description should end with period '.'
> 
> Cc: Ard Biesheuvel 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi 
> ---
>  .../FaultTolerantWriteDxe/FaultTolerantWriteSmmCommon.h | 4 ++--
>  .../FaultTolerantWriteDxe/FaultTolerantWriteStandaloneMm.c  | 2 +-
>  .../FaultTolerantWriteDxe/FaultTolerantWriteTraditionalMm.c | 2 +-
>  .../Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h| 4 ++--
>  .../Universal/Variable/RuntimeDxe/VariableStandaloneMm.c| 6 +++---
>  .../Universal/Variable/RuntimeDxe/VariableTraditionalMm.c   | 4 ++--
>  6 files changed, 11 insertions(+), 11 deletions(-)
> 
> diff --git
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmCo
> mmon.h
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmCo
> mmon.h
> index 61293ca864..cf1aef7ca4 100644
> ---
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmCo
> mmon.h
> +++
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteSmmCo
> mmon.h
> @@ -76,11 +76,11 @@ typedef struct {
>BOOLEAN   Complete;
>UINT8 Data[1];
>  } SMM_FTW_GET_LAST_WRITE_HEADER;
> 
>  /**
> -  Shared entry point of the module
> +  Shared entry point of the module.
> 
>@retval EFI_SUCCESS   The initialization finished successfully.
>@retval EFI_OUT_OF_RESOURCES  Allocate memory error
>@retval EFI_INVALID_PARAMETER Workspace or Spare block does not exist
> 
> @@ -107,11 +107,11 @@ FtwSmmIsBufferOutsideSmmValid (
>IN EFI_PHYSICAL_ADDRESS  Buffer,
>IN UINT64Length
>);
> 
>  /**
> -  Notify the system that the SMM FTW driver is ready
> +  Notify the system that the SMM FTW driver is ready.
>  **/
>  VOID
>  FtwNotifySmmReady (
>VOID
>);
> diff --git
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.c
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.c
> index 8a4ea5b476..c2aa501465 100644
> ---
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.c
> +++
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStandal
> oneMm.c
> @@ -63,11 +63,11 @@ FtwCalculateCrc32 (
>  {
>return CalculateCrc32 (Buffer, Length);
>  }
> 
>  /**
> -  Notify the system that the SMM FTW driver is ready
> +  Notify the system that the SMM FTW driver is ready.
>  **/
>  VOID
>  FtwNotifySmmReady (
>VOID
>)
> diff --git
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteTraditi
> onalMm.c
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteTraditi
> onalMm.c
> index 0981c3c2a9..7c76e1f756 100644
> ---
> a/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteTraditi
> onalMm.c
> +++
> b/MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteTraditi
> onalMm.c
> @@ -70,11 +70,11 @@ FtwCalculateCrc32 (
> 
>return ReturnValue;
>  }
> 
>  /**
> -  Notify the system that the SMM FTW driver is ready
> +  Notify the system that the SMM FTW driver is ready.
>  **/
>  VOID
>  FtwNotifySmmReady (
>VOID
>)
> diff --git
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> index 0a886558f4..9b294e6b36 100644
> --- a/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> +++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/PrivilegePolymorphic.h
> @@ -96,19 +96,19 @@ VOID
>  VariableSpeculationBarrier (
>VOID
>);
> 
>  /**
> -  Notify the system that the SMM variable driver is ready
> +  Notify the system that the SMM variable driver is ready.
>  **/
>  VOID
>  VariableNotifySmmReady (
>VOID
>);
> 
>  /**
> -  Notify the system that the SMM variable write driver is ready
> +  Notify the system that the SMM variable write driver is ready.
>  **/
>  VOID
>  VariableNotifySmmWriteReady (
>VOID
>);
> diff --git
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
> index 1e87ccfb5d..2eed038054 100644
> ---
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
> +++
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.c
> @@ -36,31 +36,31 @@ VariableSmmIsBufferOutsideSmmValid (
>  {
>return TRUE;
>  }
> 
>  /**
> -  Notify the system that the SMM variable driver is ready
> +  Notify the system that the SMM variable driver is ready.
>  **/
>  VOID
>  

[edk2] [PATCH 13/14] OvmfPkg/MptScsiDxe: Report multiple targets

2019-01-31 Thread Nikita Leshenko
The controller supports up to 8 targets (Not reported by the
controller, but based on the implementation of the virtual device),
report them in GetNextTarget and GetNextTargetLun. The firmware will
then try to communicate with them and create a block device for each
one that responds.

Support for multiple LUNs will be implemented in another series.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Nikita Leshenko 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Aaron Young 
Reviewed-by: Liran Alon 
---
 OvmfPkg/MptScsiDxe/MptScsi.c  | 27 ---
 OvmfPkg/MptScsiDxe/MptScsiDxe.inf |  1 +
 OvmfPkg/OvmfPkg.dec   |  3 +++
 3 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/OvmfPkg/MptScsiDxe/MptScsi.c b/OvmfPkg/MptScsiDxe/MptScsi.c
index a7dab0f71a..0b888a1c56 100644
--- a/OvmfPkg/MptScsiDxe/MptScsi.c
+++ b/OvmfPkg/MptScsiDxe/MptScsi.c
@@ -157,6 +157,7 @@ typedef struct {
   EFI_PCI_IO_PROTOCOL *PciIo;
   UINT64  OriginalPciAttributes;
   UINT32  StallPerPollUsec;
+  UINT8   MaxTarget;
   MPT_SCSI_IO_ERROR_REPLY IoErrorReply;
   MPT_SCSI_REQUEST_WITH_SGIoRequest;
 } MPT_SCSI_DEV;
@@ -245,6 +246,7 @@ MptScsiInit (
   EFI_STATUS Status;
 
   Dev->StallPerPollUsec = PcdGet32 (PcdMptScsiStallPerPollUsec);
+  Dev->MaxTarget = PcdGet8 (PcdMptScsiMaxTargetLimit);
 
   Status = MptScsiReset (Dev);
   if (EFI_ERROR (Status)) {
@@ -254,7 +256,7 @@ MptScsiInit (
   MPT_IO_CONTROLLER_INIT_REQUEST Req = {
 .WhoInit = MPT_IOC_WHOINIT_ROM_BIOS,
 .Function = MPT_MESSAGE_HDR_FUNCTION_IOC_INIT,
-.MaxDevices = 1,
+.MaxDevices = Dev->MaxTarget + 1,
 .MaxBuses = 1,
 .ReplyFrameSize = sizeof (MPT_SCSI_IO_ERROR_REPLY),
   };
@@ -305,6 +307,7 @@ MptScsiInit (
 STATIC
 EFI_STATUS
 MptScsiPopulateRequest (
+  IN MPT_SCSI_DEV   *Dev,
   IN UINT8  Target,
   IN UINT64 Lun,
   IN OUT EFI_EXT_SCSI_PASS_THRU_SCSI_REQUEST_PACKET *Packet,
@@ -316,7 +319,7 @@ MptScsiPopulateRequest (
 return EFI_UNSUPPORTED;
   }
 
-  if (Target > 0 || Lun > 0) {
+  if (Target > Dev->MaxTarget || Lun > 0) {
 return EFI_INVALID_PARAMETER;
   }
 
@@ -504,7 +507,7 @@ MptScsiPassThru (
   // Packet->DataDirection,
   // Packet->InTransferLength, Packet->OutTransferLength));
 
-  Status = MptScsiPopulateRequest (*Target, Lun, Packet, >IoRequest);
+  Status = MptScsiPopulateRequest (Dev, *Target, Lun, Packet, >IoRequest);
   if (EFI_ERROR (Status)) {
 return Status;
   }
@@ -568,16 +571,22 @@ MptScsiGetNextTargetLun (
   IN OUT UINT64 *Lun
   )
 {
+  MPT_SCSI_DEV *Dev = MPT_SCSI_FROM_PASS_THRU (This);
+
   DEBUG ((EFI_D_INFO, "MptScsiGetNextTargetLun %d %d\n", **Target, *Lun));
 
-  // Currently support only target 0 LUN 0, so hardcode it
+  // Currently support only LUN 0, so hardcode it
   if (!IsTargetInitialized (*Target)) {
 **Target = 0;
 *Lun = 0;
-return EFI_SUCCESS;
+  } else if (**Target < Dev->MaxTarget) {
+**Target += 1;
+*Lun = 0;
   } else {
 return EFI_NOT_FOUND;
   }
+
+  return EFI_SUCCESS;
 }
 
 STATIC
@@ -588,15 +597,19 @@ MptScsiGetNextTarget (
   IN OUT UINT8 **Target
   )
 {
+  MPT_SCSI_DEV *Dev = MPT_SCSI_FROM_PASS_THRU (This);
+
   DEBUG ((EFI_D_INFO, "MptScsiGetNextTarget\n"));
 
-  // Currently support only target 0 LUN 0, so hardcode it
   if (!IsTargetInitialized (*Target)) {
 **Target = 0;
-return EFI_SUCCESS;
+  } else if (**Target < Dev->MaxTarget) {
+**Target += 1;
   } else {
 return EFI_NOT_FOUND;
   }
+
+  return EFI_SUCCESS;
 }
 
 STATIC
diff --git a/OvmfPkg/MptScsiDxe/MptScsiDxe.inf 
b/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
index 5875d6c94b..3b6717c204 100644
--- a/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
+++ b/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
@@ -43,3 +43,4 @@
 
 [Pcd]
   gUefiOvmfPkgTokenSpaceGuid.PcdMptScsiStallPerPollUsec ## CONSUMES
+  gUefiOvmfPkgTokenSpaceGuid.PcdMptScsiMaxTargetLimit ## CONSUMES
diff --git a/OvmfPkg/OvmfPkg.dec b/OvmfPkg/OvmfPkg.dec
index 4ca98ff09f..3f088eca96 100644
--- a/OvmfPkg/OvmfPkg.dec
+++ b/OvmfPkg/OvmfPkg.dec
@@ -123,6 +123,9 @@
   gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecompressionScratchEnd|0x0|UINT32|0x1f
 
   gUefiOvmfPkgTokenSpaceGuid.PcdMptScsiStallPerPollUsec|5|UINT32|0x28
+  ## Set the *inclusive* number of targets that MptScsi exposes for scan
+  #  by ScsiBusDxe.
+  gUefiOvmfPkgTokenSpaceGuid.PcdMptScsiMaxTargetLimit|7|UINT8|0x29
 
 [PcdsDynamic, PcdsDynamicEx]
   gUefiOvmfPkgTokenSpaceGuid.PcdEmuVariableEvent|0|UINT64|2
-- 
2.20.1

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


[edk2] [PATCH 11/14] OvmfPkg/MptScsiDxe: Initialize hardware

2019-01-31 Thread Nikita Leshenko
Reset and send the IO controller initialization request. The reply is
read back to complete the doorbell function but it isn't useful to us
because it doesn't contain relevant data or status codes.

See "LSI53C1030 PCI-X to Dual Channel Ultra320 SCSI Multifunction
Controller" technical manual for more information.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Nikita Leshenko 
Reviewed-by: Aaron Young 
Reviewed-by: Liran Alon 
---
 OvmfPkg/MptScsiDxe/MptScsi.c | 234 +++
 1 file changed, 234 insertions(+)

diff --git a/OvmfPkg/MptScsiDxe/MptScsi.c b/OvmfPkg/MptScsiDxe/MptScsi.c
index 92c190499e..fbabeb22ca 100644
--- a/OvmfPkg/MptScsiDxe/MptScsi.c
+++ b/OvmfPkg/MptScsiDxe/MptScsi.c
@@ -33,10 +33,109 @@
 #define LSI_SAS1068_PCI_DEVICE_ID 0x0054
 #define LSI_SAS1068E_PCI_DEVICE_ID 0x0058
 
+#define MPT_REG_DOORBELL  0x00
+#define MPT_REG_WRITE_SEQ 0x04
+#define MPT_REG_HOST_DIAG 0x08
+#define MPT_REG_TEST  0x0c
+#define MPT_REG_DIAG_DATA 0x10
+#define MPT_REG_DIAG_ADDR 0x14
+#define MPT_REG_ISTATUS   0x30
+#define MPT_REG_IMASK 0x34
+#define MPT_REG_REQ_Q 0x40
+#define MPT_REG_REP_Q 0x44
+
+#define MPT_DOORBELL_RESET 0x40
+#define MPT_DOORBELL_HANDSHAKE 0x42
+
+#define MPT_IMASK_DOORBELL 0x01
+#define MPT_IMASK_REPLY0x08
+
+#define MPT_MESSAGE_HDR_FUNCTION_SCSI_IO_REQUEST 0x00
+#define MPT_MESSAGE_HDR_FUNCTION_IOC_INIT0x02
+
+#define MPT_SG_ENTRY_TYPE_SIMPLE 0x01
+
+#define MPT_IOC_WHOINIT_ROM_BIOS 0x02
+
 //
 // Runtime Structures
 //
 
+typedef struct {
+  UINT8 WhoInit;
+  UINT8 Reserved1;
+  UINT8 ChainOffset;
+  UINT8 Function;
+  UINT8 Flags;
+  UINT8 MaxDevices;
+  UINT8 MaxBuses;
+  UINT8 MessageFlags;
+  UINT32MessageContext;
+  UINT16ReplyFrameSize;
+  UINT16Reserved2;
+  UINT32HostMfaHighAddr;
+  UINT32SenseBufferHighAddr;
+} __attribute__((aligned(8), packed)) MPT_IO_CONTROLLER_INIT_REQUEST; // Align 
required by HW
+typedef struct {
+  UINT8 WhoInit;
+  UINT8 Reserved1;
+  UINT8 MessageLength;
+  UINT8 Function;
+  UINT8 Flags;
+  UINT8 MaxDevices;
+  UINT8 MaxBuses;
+  UINT8 MessageFlags;
+  UINT32MessageContext;
+  UINT16Reserved2;
+  UINT16IOCStatus;
+  UINT32IOCLogInfo;
+} __attribute__((packed)) MPT_IO_CONTROLLER_INIT_REPLY;
+typedef struct {
+  UINT8 TargetID;
+  UINT8 Bus;
+  UINT8 ChainOffset;
+  UINT8 Function;
+  UINT8 CDBLength;
+  UINT8 SenseBufferLength;
+  UINT8 Reserved;
+  UINT8 MessageFlags;
+  UINT32MessageContext;
+  UINT8 LUN[8];
+  UINT32Control;
+  UINT8 CDB[16];
+  UINT32DataLength;
+  UINT32SenseBufferLowAddress;
+} __attribute__((packed)) MPT_SCSI_IO_REQUEST;
+typedef struct {
+  UINT32Length: 24;
+  UINT32EndOfList:  1;
+  UINT32Is64BitAddress: 1;
+  UINT32BufferContainsData: 1;
+  UINT32LocalAddress:   1;
+  UINT32ElementType:2;
+  UINT32EndOfBuffer:1;
+  UINT32LastElement:1;
+  UINT64DataBufferAddress;
+} __attribute__((packed)) MPT_SG_ENTRY_SIMPLE;
+typedef struct {
+  UINT8 TargetID;
+  UINT8 Bus;
+  UINT8 MessageLength;
+  UINT8 Function;
+  UINT8 CDBLength;
+  UINT8 SenseBufferLength;
+  UINT8 Reserved;
+  UINT8 MessageFlags;
+  UINT32MessageContext;
+  UINT8 SCSIStatus;
+  UINT8 SCSIState;
+  UINT16IOCStatus;
+  UINT32IOCLogInfo;
+  UINT32TransferCount;
+  UINT32SenseCount;
+  UINT32ResponseInfo;
+} __attribute__((aligned(8), packed)) MPT_SCSI_IO_ERROR_REPLY; // Align 
required by HW
+
 #define MPT_SCSI_DEV_SIGNATURE SIGNATURE_32 ('M','P','T','S')
 typedef struct {
   UINT32  Signature;
@@ -49,6 +148,134 @@ typedef struct {
 #define MPT_SCSI_FROM_PASS_THRU(PassThruPtr) \
   CR (PassThruPtr, MPT_SCSI_DEV, PassThru, MPT_SCSI_DEV_SIGNATURE)
 
+//
+// Hardware functions
+//
+
+STATIC
+EFI_STATUS
+Out32 (
+  IN MPT_SCSI_DEV   *Dev,
+  IN UINT32 Addr,
+  IN UINT32 Data
+  )
+{
+  return Dev->PciIo->Io.Write (
+  Dev->PciIo,
+  EfiPciIoWidthUint32,
+  0, // BAR0
+  Addr, 1, );
+}
+
+STATIC
+EFI_STATUS
+In32 (
+  IN  MPT_SCSI_DEV   *Dev,
+  IN  UINT32 Addr,
+  OUT UINT32 *Data
+  )
+{
+  return Dev->PciIo->Io.Read (
+  Dev->PciIo,
+  EfiPciIoWidthUint32,
+  0, // BAR0
+  Addr, 1, Data);
+}
+
+STATIC
+EFI_STATUS
+MptDoorbell (
+  IN MPT_SCSI_DEV   *Dev,
+  IN UINT8  DoorbellFunc,
+  IN UINT8  DoorbellArg
+  )
+{
+  return Out32 (Dev, MPT_REG_DOORBELL, (DoorbellFunc << 24) | (DoorbellArg << 
16));
+}
+
+STATIC
+EFI_STATUS
+MptScsiReset (
+  IN MPT_SCSI_DEV   *Dev
+  )
+{
+  EFI_STATUS Status;
+
+  // Reset hardware
+  Status = MptDoorbell (Dev, 

[edk2] [PATCH 12/14] OvmfPkg/MptScsiDxe: Implement the PassThru method

2019-01-31 Thread Nikita Leshenko
Machines should be able to boot after this commit. Tested with different Linux
distributions (Ubuntu, CentOS) and different Windows versions (Windows 7,
Windows 10, Server 2016).

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Nikita Leshenko 
Reviewed-by: Aaron Young 
Reviewed-by: Liran Alon 
---
 OvmfPkg/MptScsiDxe/MptScsi.c  | 255 +-
 OvmfPkg/MptScsiDxe/MptScsiDxe.inf |   3 +
 OvmfPkg/OvmfPkg.dec   |   2 +
 3 files changed, 256 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/MptScsiDxe/MptScsi.c b/OvmfPkg/MptScsiDxe/MptScsi.c
index fbabeb22ca..a7dab0f71a 100644
--- a/OvmfPkg/MptScsiDxe/MptScsi.c
+++ b/OvmfPkg/MptScsiDxe/MptScsi.c
@@ -54,9 +54,15 @@
 #define MPT_MESSAGE_HDR_FUNCTION_IOC_INIT0x02
 
 #define MPT_SG_ENTRY_TYPE_SIMPLE 0x01
+#define MPT_SG_ENTRY_SIMPLE_MAX_LENGTH ((1 << 24) - 1)
 
 #define MPT_IOC_WHOINIT_ROM_BIOS 0x02
 
+#define MPT_SCSIIO_REQUEST_CONTROL_TXDIR_WRITE (0x01 << 24)
+#define MPT_SCSIIO_REQUEST_CONTROL_TXDIR_READ  (0x02 << 24)
+
+#define MPT_SCSI_IO_ERROR_IOCSTATUS_DEVICE_NOT_THERE 0x0043
+
 //
 // Runtime Structures
 //
@@ -110,6 +116,8 @@ typedef struct {
   UINT32Length: 24;
   UINT32EndOfList:  1;
   UINT32Is64BitAddress: 1;
+  // True when the buffer contains data to be transfered. Otherwise it's the
+  // destination buffer
   UINT32BufferContainsData: 1;
   UINT32LocalAddress:   1;
   UINT32ElementType:2;
@@ -136,6 +144,11 @@ typedef struct {
   UINT32ResponseInfo;
 } __attribute__((aligned(8), packed)) MPT_SCSI_IO_ERROR_REPLY; // Align 
required by HW
 
+typedef struct {
+  MPT_SCSI_IO_REQUEST Header;
+  MPT_SG_ENTRY_SIMPLE Sg;
+} __attribute__((aligned(8), packed)) MPT_SCSI_REQUEST_WITH_SG; // Align 
required by HW
+
 #define MPT_SCSI_DEV_SIGNATURE SIGNATURE_32 ('M','P','T','S')
 typedef struct {
   UINT32  Signature;
@@ -143,6 +156,9 @@ typedef struct {
   EFI_EXT_SCSI_PASS_THRU_MODE PassThruMode;
   EFI_PCI_IO_PROTOCOL *PciIo;
   UINT64  OriginalPciAttributes;
+  UINT32  StallPerPollUsec;
+  MPT_SCSI_IO_ERROR_REPLY IoErrorReply;
+  MPT_SCSI_REQUEST_WITH_SGIoRequest;
 } MPT_SCSI_DEV;
 
 #define MPT_SCSI_FROM_PASS_THRU(PassThruPtr) \
@@ -228,6 +244,8 @@ MptScsiInit (
 {
   EFI_STATUS Status;
 
+  Dev->StallPerPollUsec = PcdGet32 (PcdMptScsiStallPerPollUsec);
+
   Status = MptScsiReset (Dev);
   if (EFI_ERROR (Status)) {
 return Status;
@@ -273,6 +291,193 @@ MptScsiInit (
 return Status;
   }
 
+  // Put one free reply frame on the reply queue, the hardware may use it to
+  // report an error to us.
+  ASSERT ((UINTN) >IoErrorReply <= MAX_UINT32);
+  Status = Out32 (Dev, MPT_REG_REP_Q, (UINT32)(UINTN) >IoErrorReply);
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  return EFI_SUCCESS;
+}
+
+STATIC
+EFI_STATUS
+MptScsiPopulateRequest (
+  IN UINT8  Target,
+  IN UINT64 Lun,
+  IN OUT EFI_EXT_SCSI_PASS_THRU_SCSI_REQUEST_PACKET *Packet,
+  OUT MPT_SCSI_REQUEST_WITH_SG  *Request
+  )
+{
+  if (Packet->DataDirection == EFI_EXT_SCSI_DATA_DIRECTION_BIDIRECTIONAL ||
+  Packet->CdbLength > sizeof (Request->Header.CDB)) {
+return EFI_UNSUPPORTED;
+  }
+
+  if (Target > 0 || Lun > 0) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  if (Packet->InTransferLength > MPT_SG_ENTRY_SIMPLE_MAX_LENGTH) {
+Packet->InTransferLength = MPT_SG_ENTRY_SIMPLE_MAX_LENGTH;
+return EFI_BAD_BUFFER_SIZE;
+  }
+  if (Packet->OutTransferLength > MPT_SG_ENTRY_SIMPLE_MAX_LENGTH) {
+Packet->OutTransferLength = MPT_SG_ENTRY_SIMPLE_MAX_LENGTH;
+return EFI_BAD_BUFFER_SIZE;
+  }
+
+  ZeroMem (Request, sizeof (*Request));
+  Request->Header.TargetID = Target;
+  // It's 1 and not 0, for some reason...
+  Request->Header.LUN[1] = Lun;
+  Request->Header.Function = MPT_MESSAGE_HDR_FUNCTION_SCSI_IO_REQUEST;
+  Request->Header.MessageContext = 1; // Hardcoded, we handle one request at a 
time
+
+  Request->Header.CDBLength = Packet->CdbLength;
+  CopyMem (Request->Header.CDB, Packet->Cdb, Packet->CdbLength);
+
+  Request->Header.SenseBufferLength = Packet->SenseDataLength;
+  ASSERT ((UINTN) Packet->SenseData <= MAX_UINT32);
+  Request->Header.SenseBufferLowAddress = (UINT32)(UINTN) Packet->SenseData;
+
+  Request->Sg.EndOfList = 1;
+  Request->Sg.EndOfBuffer = 1;
+  Request->Sg.LastElement = 1;
+  Request->Sg.ElementType = MPT_SG_ENTRY_TYPE_SIMPLE;
+
+  switch (Packet->DataDirection)
+  {
+  case EFI_EXT_SCSI_DATA_DIRECTION_READ:
+Request->Header.DataLength = Packet->InTransferLength;
+Request->Sg.Length = Packet->InTransferLength;
+ASSERT ((UINTN) Packet->InDataBuffer <= MAX_UINT32);
+Request->Sg.DataBufferAddress = (UINT32)(UINTN) Packet->InDataBuffer;
+Request->Header.Control = 

[edk2] [PATCH 04/14] OvmfPkg/MptScsiDxe: Probe PCI devices and look for MptScsi

2019-01-31 Thread Nikita Leshenko
The MptScsiControllerSupported function is called for every handle
that appears on the system and if the handle is the lsi53c1030
controller the function would return success. A successful return
value will attach our driver to the device.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Nikita Leshenko 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Aaron Young 
Reviewed-by: Liran Alon 
---
 OvmfPkg/MptScsiDxe/MptScsi.c  | 55 ++-
 OvmfPkg/MptScsiDxe/MptScsiDxe.inf |  5 +++
 2 files changed, 59 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/MptScsiDxe/MptScsi.c b/OvmfPkg/MptScsiDxe/MptScsi.c
index 38cdda1abe..57a17ca0cb 100644
--- a/OvmfPkg/MptScsiDxe/MptScsi.c
+++ b/OvmfPkg/MptScsiDxe/MptScsi.c
@@ -15,7 +15,20 @@
 
 **/
 
+#include 
+#include 
 #include 
+#include 
+#include 
+
+//
+// Device offsets and constants
+//
+
+#define LSI_LOGIC_PCI_VENDOR_ID 0x1000
+#define LSI_53C1030_PCI_DEVICE_ID 0x0030
+#define LSI_SAS1068_PCI_DEVICE_ID 0x0054
+#define LSI_SAS1068E_PCI_DEVICE_ID 0x0058
 
 //
 // Driver Binding
@@ -30,7 +43,46 @@ MptScsiControllerSupported (
   IN EFI_DEVICE_PATH_PROTOCOL   *RemainingDevicePath OPTIONAL
   )
 {
-  return EFI_UNSUPPORTED;
+  EFI_STATUS  Status;
+  EFI_PCI_IO_PROTOCOL *PciIo = NULL;
+  PCI_TYPE00  Pci;
+
+  Status = gBS->OpenProtocol (
+  ControllerHandle,
+  ,
+  (VOID **) ,
+  This->DriverBindingHandle,
+  ControllerHandle,
+  EFI_OPEN_PROTOCOL_BY_DRIVER);
+  if (EFI_ERROR (Status)) {
+return Status;
+  }
+
+  Status = PciIo->Pci.Read (
+  PciIo,
+  EfiPciIoWidthUint32,
+  0, sizeof (Pci) / sizeof (UINT32),
+  );
+  if (EFI_ERROR (Status)) {
+goto Done;
+  }
+
+  if (Pci.Hdr.VendorId == LSI_LOGIC_PCI_VENDOR_ID
+  && (Pci.Hdr.DeviceId == LSI_53C1030_PCI_DEVICE_ID
+  || Pci.Hdr.DeviceId == LSI_SAS1068_PCI_DEVICE_ID
+  || Pci.Hdr.DeviceId == LSI_SAS1068E_PCI_DEVICE_ID)) {
+Status = EFI_SUCCESS;
+  } else {
+Status = EFI_UNSUPPORTED;
+  }
+
+Done:
+  gBS->CloseProtocol (
+  ControllerHandle,
+  ,
+  This->DriverBindingHandle,
+  ControllerHandle);
+  return Status;
 }
 
 STATIC
@@ -42,6 +94,7 @@ MptScsiControllerStart (
   IN EFI_DEVICE_PATH_PROTOCOL   *RemainingDevicePath OPTIONAL
   )
 {
+  DEBUG ((EFI_D_INFO, "Attempted to start MptScsi\n"));
   return EFI_UNSUPPORTED;
 }
 
diff --git a/OvmfPkg/MptScsiDxe/MptScsiDxe.inf 
b/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
index 8a780a661e..3608cecaab 100644
--- a/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
+++ b/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
@@ -30,5 +30,10 @@
   OvmfPkg/OvmfPkg.dec
 
 [LibraryClasses]
+  DebugLib
+  UefiBootServicesTableLib
   UefiDriverEntryPoint
   UefiLib
+
+[Protocols]
+  gEfiPciIoProtocolGuid## TO_START
\ No newline at end of file
-- 
2.20.1

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


[edk2] [PATCH 03/14] OvmfPkg/MptScsiDxe: Report name of driver

2019-01-31 Thread Nikita Leshenko
Install Component Name protocols to have a nice display name for the
driver in places such as UEFI shell.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Nikita Leshenko 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Aaron Young 
Reviewed-by: Liran Alon 
---
 OvmfPkg/MptScsiDxe/MptScsi.c | 61 ++--
 1 file changed, 59 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/MptScsiDxe/MptScsi.c b/OvmfPkg/MptScsiDxe/MptScsi.c
index 4dcb1b1ae5..38cdda1abe 100644
--- a/OvmfPkg/MptScsiDxe/MptScsi.c
+++ b/OvmfPkg/MptScsiDxe/MptScsi.c
@@ -71,6 +71,63 @@ EFI_DRIVER_BINDING_PROTOCOL gMptScsiDriverBinding = {
   NULL, // DriverBindingHandle filled by 
EfiLibInstallDriverBindingComponentName2
 };
 
+//
+// Component Name
+//
+
+STATIC
+EFI_UNICODE_STRING_TABLE mDriverNameTable[] = {
+  { "eng;en", L"LSI Fusion MPT SCSI Driver" },
+  { NULL, NULL   }
+};
+
+STATIC
+EFI_COMPONENT_NAME_PROTOCOL gComponentName;
+
+EFI_STATUS
+EFIAPI
+MptScsiGetDriverName (
+  IN  EFI_COMPONENT_NAME_PROTOCOL *This,
+  IN  CHAR8   *Language,
+  OUT CHAR16  **DriverName
+  )
+{
+  return LookupUnicodeString2 (
+   Language,
+   This->SupportedLanguages,
+   mDriverNameTable,
+   DriverName,
+   (BOOLEAN) (This == ) // Iso639Language
+   );
+}
+
+EFI_STATUS
+EFIAPI
+MptScsiGetDeviceName (
+  IN  EFI_COMPONENT_NAME_PROTOCOL *This,
+  IN  EFI_HANDLE  DeviceHandle,
+  IN  EFI_HANDLE  ChildHandle,
+  IN  CHAR8   *Language,
+  OUT CHAR16  **ControllerName
+  )
+{
+  return EFI_UNSUPPORTED;
+}
+
+STATIC
+EFI_COMPONENT_NAME_PROTOCOL gComponentName = {
+  ,
+  ,
+  "eng" // SupportedLanguages, ISO 639-2 language codes
+};
+
+STATIC
+EFI_COMPONENT_NAME2_PROTOCOL gComponentName2 = {
+  (EFI_COMPONENT_NAME2_GET_DRIVER_NAME) ,
+  (EFI_COMPONENT_NAME2_GET_CONTROLLER_NAME) ,
+  "en" // SupportedLanguages, RFC 4646 language codes
+};
+
 //
 // Entry Point
 //
@@ -87,7 +144,7 @@ MptScsiEntryPoint (
 SystemTable,
 ,
 ImageHandle, // The handle to install onto
-NULL, // TODO Component name
-NULL // TODO Component name
+,
+
 );
 }
-- 
2.20.1

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


[edk2] [PATCH 05/14] OvmfPkg/MptScsiDxe: Install stubbed EXT_SCSI_PASS_THRU

2019-01-31 Thread Nikita Leshenko
Support dynamic insertion and removal of the protocol

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Nikita Leshenko 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Aaron Young 
Reviewed-by: Liran Alon 
---
 OvmfPkg/MptScsiDxe/MptScsi.c  | 204 +-
 OvmfPkg/MptScsiDxe/MptScsiDxe.inf |   5 +-
 2 files changed, 205 insertions(+), 4 deletions(-)

diff --git a/OvmfPkg/MptScsiDxe/MptScsi.c b/OvmfPkg/MptScsiDxe/MptScsi.c
index 57a17ca0cb..6b655d9fe8 100644
--- a/OvmfPkg/MptScsiDxe/MptScsi.c
+++ b/OvmfPkg/MptScsiDxe/MptScsi.c
@@ -16,10 +16,13 @@
 **/
 
 #include 
+#include 
 #include 
+#include 
 #include 
 #include 
 #include 
+#include 
 
 //
 // Device offsets and constants
@@ -30,6 +33,118 @@
 #define LSI_SAS1068_PCI_DEVICE_ID 0x0054
 #define LSI_SAS1068E_PCI_DEVICE_ID 0x0058
 
+//
+// Runtime Structures
+//
+
+#define MPT_SCSI_DEV_SIGNATURE SIGNATURE_32 ('M','P','T','S')
+typedef struct {
+  UINT32  Signature;
+  EFI_EXT_SCSI_PASS_THRU_PROTOCOL PassThru;
+  EFI_EXT_SCSI_PASS_THRU_MODE PassThruMode;
+} MPT_SCSI_DEV;
+
+#define MPT_SCSI_FROM_PASS_THRU(PassThruPtr) \
+  CR (PassThruPtr, MPT_SCSI_DEV, PassThru, MPT_SCSI_DEV_SIGNATURE)
+
+//
+// Ext SCSI Pass Thru
+//
+
+STATIC
+EFI_STATUS
+EFIAPI
+MptScsiPassThru (
+  IN EFI_EXT_SCSI_PASS_THRU_PROTOCOL*This,
+  IN UINT8  *Target,
+  IN UINT64 Lun,
+  IN OUT EFI_EXT_SCSI_PASS_THRU_SCSI_REQUEST_PACKET *Packet,
+  IN EFI_EVENT  Event OPTIONAL
+  )
+{
+  DEBUG ((EFI_D_INFO, "MptScsiPassThru Direction %d In %d Out %d\n",
+  Packet->DataDirection,
+  Packet->InTransferLength, Packet->OutTransferLength));
+  return EFI_UNSUPPORTED;
+}
+
+STATIC
+EFI_STATUS
+EFIAPI
+MptScsiGetNextTargetLun (
+  IN EFI_EXT_SCSI_PASS_THRU_PROTOCOL*This,
+  IN OUT UINT8  **Target,
+  IN OUT UINT64 *Lun
+  )
+{
+  DEBUG ((EFI_D_INFO, "MptScsiGetNextTargetLun %d %d\n", **Target, *Lun));
+  return EFI_UNSUPPORTED;
+}
+
+STATIC
+EFI_STATUS
+EFIAPI
+MptScsiGetNextTarget (
+  IN EFI_EXT_SCSI_PASS_THRU_PROTOCOL   *This,
+  IN OUT UINT8 **Target
+  )
+{
+  DEBUG ((EFI_D_INFO, "MptScsiGetNextTarget\n"));
+  return EFI_UNSUPPORTED;
+}
+
+STATIC
+EFI_STATUS
+EFIAPI
+MptScsiBuildDevicePath (
+  IN EFI_EXT_SCSI_PASS_THRU_PROTOCOL   *This,
+  IN UINT8 *Target,
+  IN UINT64Lun,
+  IN OUT EFI_DEVICE_PATH_PROTOCOL  **DevicePath
+  )
+{
+  DEBUG ((EFI_D_INFO, "MptScsiBuildDevicePath %d %d\n", *Target, Lun));
+  return EFI_UNSUPPORTED;
+}
+
+STATIC
+EFI_STATUS
+EFIAPI
+MptScsiGetTargetLun (
+  IN EFI_EXT_SCSI_PASS_THRU_PROTOCOL   *This,
+  IN EFI_DEVICE_PATH_PROTOCOL  *DevicePath,
+  OUT UINT8**Target,
+  OUT UINT64   *Lun
+  )
+{
+  DEBUG ((EFI_D_INFO, "MptScsiGetTargetLun\n"));
+  return EFI_UNSUPPORTED;
+}
+
+STATIC
+EFI_STATUS
+EFIAPI
+MptScsiResetChannel (
+  IN EFI_EXT_SCSI_PASS_THRU_PROTOCOL   *This
+  )
+{
+  DEBUG ((EFI_D_INFO, "MptScsiResetChannel\n"));
+  return EFI_UNSUPPORTED;
+}
+
+STATIC
+EFI_STATUS
+EFIAPI
+MptScsiResetTargetLun (
+  IN EFI_EXT_SCSI_PASS_THRU_PROTOCOL   *This,
+  IN UINT8 *Target,
+  IN UINT64Lun
+  )
+{
+  DEBUG ((EFI_D_INFO, "MptScsiResetTargetLun\n"));
+  return EFI_UNSUPPORTED;
+}
+
 //
 // Driver Binding
 //
@@ -94,8 +209,65 @@ MptScsiControllerStart (
   IN EFI_DEVICE_PATH_PROTOCOL   *RemainingDevicePath OPTIONAL
   )
 {
-  DEBUG ((EFI_D_INFO, "Attempted to start MptScsi\n"));
-  return EFI_UNSUPPORTED;
+  EFI_STATUS   Status;
+  EFI_PHYSICAL_ADDRESS PhysicalAddress;
+  MPT_SCSI_DEV *Dev;
+
+  DEBUG ((EFI_D_INFO, "Starting MptScsi\n"));
+
+  //
+  // MPT_SCSI_DEV contains descriptors that are passed to the controller. The
+  // controller doesn't easily support addresses larger than 4GB, so we 
allocate
+  // the struct below 4GB. (Technically we can use HostMfaHighAddr and make 
sure
+  // all descriptors have the same high address but it's more complicated than
+  // just allocating below 4GB. Also, we allocate it only once per device so 
the
+  // overhead of allocating a whole page is minimal.)
+  //
+  PhysicalAddress = MAX_UINT32;
+  Status = gBS->AllocatePages (
+  AllocateMaxAddress,
+  EfiRuntimeServicesData,
+  EFI_SIZE_TO_PAGES (sizeof (*Dev)),
+  
+  );
+  if (EFI_ERROR (Status)) {
+return EFI_OUT_OF_RESOURCES;
+  }
+
+  // PhysicalAddress is page aligned, so 

[edk2] [PATCH 14/14] OvmfPkg/MptScsiDxe: Support packets with pointers above 4G

2019-01-31 Thread Nikita Leshenko
Users of this device might pass data pointers which are above 4G, in which case
we can't pass the pointers directly to the controller because the descriptors
contain 32-bit pointers.

Instead of failing the request, use below-4G memory to support the request.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Nikita Leshenko 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Aaron Young 
Reviewed-by: Liran Alon 
---
 OvmfPkg/MptScsiDxe/MptScsi.c | 50 +++-
 1 file changed, 44 insertions(+), 6 deletions(-)

diff --git a/OvmfPkg/MptScsiDxe/MptScsi.c b/OvmfPkg/MptScsiDxe/MptScsi.c
index 0b888a1c56..9e803735d2 100644
--- a/OvmfPkg/MptScsiDxe/MptScsi.c
+++ b/OvmfPkg/MptScsiDxe/MptScsi.c
@@ -160,6 +160,9 @@ typedef struct {
   UINT8   MaxTarget;
   MPT_SCSI_IO_ERROR_REPLY IoErrorReply;
   MPT_SCSI_REQUEST_WITH_SGIoRequest;
+
+  UINT8   SenseBuffer[MAX_UINT8];
+  UINT8   DataBuffer[0x2000];
 } MPT_SCSI_DEV;
 
 #define MPT_SCSI_FROM_PASS_THRU(PassThruPtr) \
@@ -323,6 +326,18 @@ MptScsiPopulateRequest (
 return EFI_INVALID_PARAMETER;
   }
 
+  // If the buffers are above 4G, make sure that we can buffer that data
+  if ((UINTN) Packet->InDataBuffer > MAX_UINT32 &&
+  Packet->InTransferLength > sizeof (Dev->DataBuffer)) {
+Packet->InTransferLength = sizeof (Dev->DataBuffer);
+return EFI_BAD_BUFFER_SIZE;
+  }
+  if ((UINTN) Packet->OutDataBuffer > MAX_UINT32 &&
+  Packet->OutTransferLength > sizeof (Dev->DataBuffer)) {
+Packet->OutTransferLength = sizeof (Dev->DataBuffer);
+return EFI_BAD_BUFFER_SIZE;
+  }
+
   if (Packet->InTransferLength > MPT_SG_ENTRY_SIMPLE_MAX_LENGTH) {
 Packet->InTransferLength = MPT_SG_ENTRY_SIMPLE_MAX_LENGTH;
 return EFI_BAD_BUFFER_SIZE;
@@ -343,8 +358,14 @@ MptScsiPopulateRequest (
   CopyMem (Request->Header.CDB, Packet->Cdb, Packet->CdbLength);
 
   Request->Header.SenseBufferLength = Packet->SenseDataLength;
-  ASSERT ((UINTN) Packet->SenseData <= MAX_UINT32);
-  Request->Header.SenseBufferLowAddress = (UINT32)(UINTN) Packet->SenseData;
+  // If sense is above 4G, we can't pass it directly to controller
+  if ((UINTN) Packet->SenseData > MAX_UINT32) {
+// Zero because the controller doesn't report the resulting sense data size
+ZeroMem (>SenseBuffer, Packet->SenseDataLength);
+Request->Header.SenseBufferLowAddress = (UINT32)(UINTN) >SenseBuffer;
+  } else {
+Request->Header.SenseBufferLowAddress = (UINT32)(UINTN) Packet->SenseData;
+  }
 
   Request->Sg.EndOfList = 1;
   Request->Sg.EndOfBuffer = 1;
@@ -356,15 +377,24 @@ MptScsiPopulateRequest (
   case EFI_EXT_SCSI_DATA_DIRECTION_READ:
 Request->Header.DataLength = Packet->InTransferLength;
 Request->Sg.Length = Packet->InTransferLength;
-ASSERT ((UINTN) Packet->InDataBuffer <= MAX_UINT32);
-Request->Sg.DataBufferAddress = (UINT32)(UINTN) Packet->InDataBuffer;
+// If buffer is above 4G, we can't pass it directly to controller
+if ((UINTN) Packet->InDataBuffer > MAX_UINT32) {
+  Request->Sg.DataBufferAddress = (UINT32)(UINTN) >DataBuffer;
+} else {
+  Request->Sg.DataBufferAddress = (UINT32)(UINTN) Packet->InDataBuffer;
+}
 Request->Header.Control = MPT_SCSIIO_REQUEST_CONTROL_TXDIR_READ;
 break;
   case EFI_EXT_SCSI_DATA_DIRECTION_WRITE:
 Request->Header.DataLength = Packet->OutTransferLength;
 Request->Sg.Length = Packet->OutTransferLength;
-ASSERT ((UINTN) Packet->OutDataBuffer <= MAX_UINT32);
-Request->Sg.DataBufferAddress = (UINT32)(UINTN) Packet->OutDataBuffer;
+// If buffer is above 4G, we can't pass it directly to controller
+if ((UINTN) Packet->OutDataBuffer > MAX_UINT32) {
+  CopyMem (>DataBuffer, Packet->OutDataBuffer, 
Packet->OutTransferLength);
+  Request->Sg.DataBufferAddress = (UINT32)(UINTN) >DataBuffer;
+} else {
+  Request->Sg.DataBufferAddress = (UINT32)(UINTN) Packet->OutDataBuffer;
+}
 Request->Header.Control = MPT_SCSIIO_REQUEST_CONTROL_TXDIR_WRITE;
 Request->Sg.BufferContainsData = 1;
 break;
@@ -451,6 +481,14 @@ MptScsiHandleReply (
   OUT EFI_EXT_SCSI_PASS_THRU_SCSI_REQUEST_PACKET*Packet
   )
 {
+  if ((UINTN) Packet->SenseData > MAX_UINT32) {
+CopyMem (Packet->SenseData, >SenseBuffer, Packet->SenseDataLength);
+  }
+  if ((UINTN) Packet->InDataBuffer > MAX_UINT32 &&
+  Packet->DataDirection == EFI_EXT_SCSI_DATA_DIRECTION_READ) {
+CopyMem (Packet->InDataBuffer, >DataBuffer, Packet->InTransferLength);
+  }
+
   if (Reply == Request->Header.MessageContext) {
 // Everything is good
 Packet->HostAdapterStatus = EFI_EXT_SCSI_STATUS_HOST_ADAPTER_OK;
-- 
2.20.1

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


[edk2] [PATCH 02/14] OvmfPkg/MptScsiDxe: Install DriverBinding Protocol

2019-01-31 Thread Nikita Leshenko
In order to probe and connect to the MptScsi device we need this
protocol. Currently it does nothing.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Nikita Leshenko 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Aaron Young 
Reviewed-by: Liran Alon 
---
 OvmfPkg/MptScsiDxe/MptScsi.c  | 65 ++-
 OvmfPkg/MptScsiDxe/MptScsiDxe.inf |  1 +
 2 files changed, 65 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/MptScsiDxe/MptScsi.c b/OvmfPkg/MptScsiDxe/MptScsi.c
index 73a693741d..4dcb1b1ae5 100644
--- a/OvmfPkg/MptScsiDxe/MptScsi.c
+++ b/OvmfPkg/MptScsiDxe/MptScsi.c
@@ -15,6 +15,62 @@
 
 **/
 
+#include 
+
+//
+// Driver Binding
+//
+
+STATIC
+EFI_STATUS
+EFIAPI
+MptScsiControllerSupported (
+  IN EFI_DRIVER_BINDING_PROTOCOL*This,
+  IN EFI_HANDLE ControllerHandle,
+  IN EFI_DEVICE_PATH_PROTOCOL   *RemainingDevicePath OPTIONAL
+  )
+{
+  return EFI_UNSUPPORTED;
+}
+
+STATIC
+EFI_STATUS
+EFIAPI
+MptScsiControllerStart (
+  IN EFI_DRIVER_BINDING_PROTOCOL*This,
+  IN EFI_HANDLE ControllerHandle,
+  IN EFI_DEVICE_PATH_PROTOCOL   *RemainingDevicePath OPTIONAL
+  )
+{
+  return EFI_UNSUPPORTED;
+}
+
+STATIC
+EFI_STATUS
+EFIAPI
+MptScsiControllerStop (
+  IN EFI_DRIVER_BINDING_PROTOCOL*This,
+  IN  EFI_HANDLEControllerHandle,
+  IN  UINTN NumberOfChildren,
+  IN  EFI_HANDLE*ChildHandleBuffer
+  )
+{
+  return EFI_UNSUPPORTED;
+}
+
+// Higher versions will be used before lower, 0x10-0xffef is the version
+// range for IVH (Indie Hardware Vendors)
+#define MPT_SCSI_BINDING_VERSION 0x10
+STATIC
+EFI_DRIVER_BINDING_PROTOCOL gMptScsiDriverBinding = {
+  ,
+  ,
+  ,
+  MPT_SCSI_BINDING_VERSION,
+  NULL, // ImageHandle filled by EfiLibInstallDriverBindingComponentName2
+  NULL, // DriverBindingHandle filled by 
EfiLibInstallDriverBindingComponentName2
+};
+
 //
 // Entry Point
 //
@@ -26,5 +82,12 @@ MptScsiEntryPoint (
   IN EFI_SYSTEM_TABLE *SystemTable
   )
 {
-  return EFI_UNSUPPORTED;
+  return EfiLibInstallDriverBindingComponentName2 (
+ImageHandle,
+SystemTable,
+,
+ImageHandle, // The handle to install onto
+NULL, // TODO Component name
+NULL // TODO Component name
+);
 }
diff --git a/OvmfPkg/MptScsiDxe/MptScsiDxe.inf 
b/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
index c558d78034..8a780a661e 100644
--- a/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
+++ b/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
@@ -31,3 +31,4 @@
 
 [LibraryClasses]
   UefiDriverEntryPoint
+  UefiLib
-- 
2.20.1

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


[edk2] [PATCH 10/14] OvmfPkg/MptScsiDxe: Set and restore PCI attributes

2019-01-31 Thread Nikita Leshenko
Enable the IO Space and Bus Mastering and restore the original values
when the device is stopped. This is a standard procedure in PCI
drivers.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Nikita Leshenko 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Aaron Young 
Reviewed-by: Liran Alon 
---
 OvmfPkg/MptScsiDxe/MptScsi.c | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/OvmfPkg/MptScsiDxe/MptScsi.c b/OvmfPkg/MptScsiDxe/MptScsi.c
index 29816fb98c..92c190499e 100644
--- a/OvmfPkg/MptScsiDxe/MptScsi.c
+++ b/OvmfPkg/MptScsiDxe/MptScsi.c
@@ -43,6 +43,7 @@ typedef struct {
   EFI_EXT_SCSI_PASS_THRU_PROTOCOL PassThru;
   EFI_EXT_SCSI_PASS_THRU_MODE PassThruMode;
   EFI_PCI_IO_PROTOCOL *PciIo;
+  UINT64  OriginalPciAttributes;
 } MPT_SCSI_DEV;
 
 #define MPT_SCSI_FROM_PASS_THRU(PassThruPtr) \
@@ -269,6 +270,7 @@ MptScsiControllerStart (
   EFI_STATUS   Status;
   EFI_PHYSICAL_ADDRESS PhysicalAddress;
   MPT_SCSI_DEV *Dev;
+  BOOLEAN  PciAttributesChanged = FALSE;
 
   DEBUG ((EFI_D_INFO, "Starting MptScsi\n"));
 
@@ -307,6 +309,25 @@ MptScsiControllerStart (
 goto Done;
   }
 
+  Status = Dev->PciIo->Attributes (
+  Dev->PciIo,
+  EfiPciIoAttributeOperationGet, 0,
+  >OriginalPciAttributes);
+  if (EFI_ERROR (Status)) {
+goto Done;
+  }
+
+  // Enable I/O Space & Bus-Mastering
+  Status = Dev->PciIo->Attributes (
+  Dev->PciIo,
+  EfiPciIoAttributeOperationEnable,
+  EFI_PCI_IO_ATTRIBUTE_IO | EFI_PCI_IO_ATTRIBUTE_BUS_MASTER,
+  NULL);
+  if (EFI_ERROR (Status)) {
+goto Done;
+  }
+  PciAttributesChanged = TRUE;
+
   Dev->PassThruMode.AdapterId = MAX_UINT32; // Host adapter channel, doesn't 
exist
   Dev->PassThruMode.Attributes =
 EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL
@@ -332,6 +353,13 @@ MptScsiControllerStart (
   DEBUG ((EFI_D_INFO, "MptScsi Installed\n"));
 Done:
   if (EFI_ERROR (Status)) {
+if (PciAttributesChanged) {
+  Dev->PciIo->Attributes (
+  Dev->PciIo,
+  EfiPciIoAttributeOperationEnable,
+  Dev->OriginalPciAttributes,
+  NULL);
+}
 if (Dev->PciIo) {
   gBS->CloseProtocol (
   ControllerHandle,
@@ -378,6 +406,13 @@ MptScsiControllerStop (
   ControllerHandle,
   ,
   >PassThru);
+
+  Dev->PciIo->Attributes (
+  Dev->PciIo,
+  EfiPciIoAttributeOperationEnable,
+  Dev->OriginalPciAttributes,
+  NULL);
+
   gBS->CloseProtocol (
   ControllerHandle,
   ,
-- 
2.20.1

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


[edk2] [PATCH 07/14] OvmfPkg/MptScsiDxe: Build DevicePath for discovered devices

2019-01-31 Thread Nikita Leshenko
Used to identify the individual disks in the hardware tree

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Nikita Leshenko 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Aaron Young 
Reviewed-by: Liran Alon 
---
 OvmfPkg/MptScsiDxe/MptScsi.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/MptScsiDxe/MptScsi.c b/OvmfPkg/MptScsiDxe/MptScsi.c
index 8ce7986b1d..7f360158e7 100644
--- a/OvmfPkg/MptScsiDxe/MptScsi.c
+++ b/OvmfPkg/MptScsiDxe/MptScsi.c
@@ -133,8 +133,24 @@ MptScsiBuildDevicePath (
   IN OUT EFI_DEVICE_PATH_PROTOCOL  **DevicePath
   )
 {
+  SCSI_DEVICE_PATH *ScsiDevicePath;
+
   DEBUG ((EFI_D_INFO, "MptScsiBuildDevicePath %d %d\n", *Target, Lun));
-  return EFI_UNSUPPORTED;
+
+  ScsiDevicePath = AllocateZeroPool (sizeof (*ScsiDevicePath));
+  if (ScsiDevicePath == NULL) {
+return EFI_OUT_OF_RESOURCES;
+  }
+
+  ScsiDevicePath->Header.Type  = MESSAGING_DEVICE_PATH;
+  ScsiDevicePath->Header.SubType   = MSG_SCSI_DP;
+  ScsiDevicePath->Header.Length[0] = (UINT8) sizeof (*ScsiDevicePath);
+  ScsiDevicePath->Header.Length[1] = (UINT8) sizeof (*ScsiDevicePath) >> 8;
+  ScsiDevicePath->Pun  = *Target;
+  ScsiDevicePath->Lun  = (UINT16) Lun;
+
+  *DevicePath = >Header;
+  return EFI_SUCCESS;
 }
 
 STATIC
-- 
2.20.1

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


Re: [edk2] [PATCH 5/5] IntelSiliconPkg\Include\IndustryStandard: Update IGD_OPREGION_MBOX3 Structure

2019-01-31 Thread Chaganty, Rangasai V
Reviewed-by: Chaganty, Rangasai V  

-Original Message-
From: Solanki, Digant H 
Sent: Thursday, January 31, 2019 12:01 AM
To: edk2-devel@lists.01.org
Cc: Ni, Ray ; Gao, Liming ; Chaganty, 
Rangasai V 
Subject: [PATCH 5/5] IntelSiliconPkg\Include\IndustryStandard: Update 
IGD_OPREGION_MBOX3 Structure

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1454
Based on latest IGD OpRegion Spec, IGD_OPREGION_MBOX3 needs to be updated with 
two new members : Physical Address of Raw VBT Data (RVDA) and Size of Raw VBT 
Data (RVDS)

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Digant H Solanki 
Cc: Ray Ni 
Cc: Liming Gao 
Cc: Rangasai V Chaganty 
---
 IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h 
b/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
index 5ce80a5be8..300a85a717 100644
--- a/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
+++ b/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
@@ -4,9 +4,7 @@
 
   https://01.org/sites/default/files/documentation/skl_opregion_rev0p5.pdf
 
-  @note Fixed bug in the spec Mailbox3 - RM31 size from 0x45(69) to 0x46(70)
-
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2019, Intel Corporation. All rights 
+ reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at @@ -118,7 +116,9 @@ typedef struct {
   UINT64 FDSS;  ///< Offset 0x3AA DSS Buffer address allocated for 
IFFS feature
   UINT32 FDSP;  ///< Offset 0x3B2 Size of DSS buffer
   UINT32 STAT;  ///< Offset 0x3B6 State Indicator
-  UINT8  RM31[0x46];///< Offset 0x3BA - 0x3FF  Reserved Must be zero. Bug 
in spec 0x45(69)
+  UINT64 RVDA;  ///< Offset 0x3BA Physical address of Raw VBT data. 
Added from Spec Version 0.90 to support VBT greater than 6KB.
+  UINT32 RVDS;  ///< Offset 0x3C2 Size of Raw VBT data. Added from 
Spec Version 0.90 to support VBT greater than 6KB.
+  UINT8  RM32[0x3A];///< Offset 0x3C6 - 0x3FF  Reserved Must be zero.
 } IGD_OPREGION_MBOX3;
 
 ///
--
2.18.0.windows.1

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


[edk2] [PATCH] EmbeddedPkg/DwEmacSnpDxe: Add designware emac support This add support for designware emac controller

2019-01-31 Thread tzy . way . ooi
From: "Ooi, Tzy Way" 

Contributed-under: TianCore Contribution Agreement 1.1
Signed-off-by: Ooi, Tzy Way 
---
 .../Drivers/DwEmacSnpDxe/DwEmacSnpDxe.c   | 1368 +
 .../Drivers/DwEmacSnpDxe/DwEmacSnpDxe.h   |  236 +++
 .../Drivers/DwEmacSnpDxe/DwEmacSnpDxe.inf |   69 +
 .../Drivers/DwEmacSnpDxe/EmacDxeUtil.c|  676 
 .../Drivers/DwEmacSnpDxe/EmacDxeUtil.h|  378 +
 EmbeddedPkg/Drivers/DwEmacSnpDxe/PhyDxeUtil.c |  604 
 EmbeddedPkg/Drivers/DwEmacSnpDxe/PhyDxeUtil.h |  324 
 EmbeddedPkg/EmbeddedPkg.dec   |4 +
 EmbeddedPkg/EmbeddedPkg.dsc   |1 +
 9 files changed, 3660 insertions(+)
 create mode 100755 EmbeddedPkg/Drivers/DwEmacSnpDxe/DwEmacSnpDxe.c
 create mode 100755 EmbeddedPkg/Drivers/DwEmacSnpDxe/DwEmacSnpDxe.h
 create mode 100755 EmbeddedPkg/Drivers/DwEmacSnpDxe/DwEmacSnpDxe.inf
 create mode 100755 EmbeddedPkg/Drivers/DwEmacSnpDxe/EmacDxeUtil.c
 create mode 100755 EmbeddedPkg/Drivers/DwEmacSnpDxe/EmacDxeUtil.h
 create mode 100755 EmbeddedPkg/Drivers/DwEmacSnpDxe/PhyDxeUtil.c
 create mode 100755 EmbeddedPkg/Drivers/DwEmacSnpDxe/PhyDxeUtil.h

diff --git a/EmbeddedPkg/Drivers/DwEmacSnpDxe/DwEmacSnpDxe.c 
b/EmbeddedPkg/Drivers/DwEmacSnpDxe/DwEmacSnpDxe.c
new file mode 100755
index 00..a1de8f63ac
--- /dev/null
+++ b/EmbeddedPkg/Drivers/DwEmacSnpDxe/DwEmacSnpDxe.c
@@ -0,0 +1,1368 @@
+/** @file
+  DW EMAC SNP DXE driver
+
+  Copyright (c) 2011 - 2019, Intel Corporaton. 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.
+  
+  The original software modules are licensed as follows:
+
+  Copyright (c) 2012 - 2014, ARM Limited. All rights reserved.
+  Copyright (c) 2004 - 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 3 Clause LICENSE ON AN "AS IS" 
BASIS,
+  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
+
+#include "DwEmacSnpDxe.h"
+#include "EmacDxeUtil.h"
+#include "PhyDxeUtil.h"
+
+typedef struct {
+  MAC_ADDR_DEVICE_PATH  MacAddrDP;
+  EFI_DEVICE_PATH_PROTOCOL  End;
+} EFI_SIMPLE_NETWORK_DEVICE_PATH;
+
+EFI_SIMPLE_NETWORK_DEVICE_PATH PathTemplate =  {
+  {
+{
+  MESSAGING_DEVICE_PATH, MSG_MAC_ADDR_DP,
+  { (UINT8) (sizeof(MAC_ADDR_DEVICE_PATH)), (UINT8) 
((sizeof(MAC_ADDR_DEVICE_PATH)) >> 8) }
+},
+{ { 0 } },
+0
+  },
+  {
+END_DEVICE_PATH_TYPE,
+END_ENTIRE_DEVICE_PATH_SUBTYPE,
+{ sizeof(EFI_DEVICE_PATH_PROTOCOL), 0 }
+  }
+};
+
+
+/**
+  The SNP driver entry point.
+
+  This is the declaration of an EFI image entry point. This entry point is
+  the same for UEFI Applications, UEFI OS Loaders, and UEFI Drivers including
+  both device drivers and bus drivers.
+
+  @param  ImageHandle   The firmware allocated handle for the UEFI 
image.
+  @param  SystemTable   A pointer to the EFI System Table.
+
+  @retval EFI_SUCCESS   The operation completed successfully.
+  @retval EFI_OUT_OF_RESOURCES  The request could not be completed due to a 
lack of resources.
+
+**/
+EFI_STATUS
+DwEmacSnpDxeEntry (
+  IN EFI_HANDLEImageHandle,
+  IN EFI_SYSTEM_TABLE  *SystemTable
+  )
+{
+  EFI_STATUS   Status;
+  EFI_SIMPLE_NETWORK_DRIVER   *Snp;
+  EFI_SIMPLE_NETWORK_MODE *SnpMode;
+  EFI_SIMPLE_NETWORK_DEVICE_PATH  *DevicePath;
+  EFI_HANDLE   ControllerHandle;
+  UINT64   DefaultMacAddress;
+  EFI_MAC_ADDRESS *SwapMacAddressPtr;
+  //UINT32   MacIf;
+ 
+
+  DEBUG ((EFI_D_INFO, "SNP:DXE: %a ()\r\n", __FUNCTION__));
+
+  Status = EFI_SUCCESS;
+  // Allocate Resources
+  Snp = AllocatePages (EFI_SIZE_TO_PAGES (sizeof (EFI_SIMPLE_NETWORK_DRIVER)));
+  if (Snp == NULL) {
+return EFI_OUT_OF_RESOURCES;
+  }
+
+  // Initialized signature (used by INSTANCE_FROM_SNP_THIS macro)
+  Snp->Signature = SNP_DRIVER_SIGNATURE;
+
+  DevicePath = (EFI_SIMPLE_NETWORK_DEVICE_PATH*)AllocateCopyPool (sizeof 
(EFI_SIMPLE_NETWORK_DEVICE_PATH), );
+  if (DevicePath == NULL) {
+return EFI_OUT_OF_RESOURCES;
+  }
+
+  // Initialize pointers
+  SnpMode = &(Snp->SnpMode);
+  Snp->Snp.Mode = SnpMode;
+
+  // Assign fields and func pointers
+  Snp->Snp.Revision = EFI_SIMPLE_NETWORK_PROTOCOL_REVISION;
+  

Re: [edk2] [platforms: PATCH v3 0/5] Armada7k8k memory handling update

2019-01-31 Thread Leif Lindholm
On Thu, Jan 31, 2019 at 08:01:08AM +0100, Marcin Wojtas wrote:
> Hi Leif,
> 
> Thanks a lot. While at it - do you think ArmPkg/Include/Library/ArmLib.h
> / ArmPkg/Library/ArmLib/ArmLib.c would be a proper place for it?

As good a place as any. While not ARM-architecture specific, I feel
it's probably ARM-platform specific.

I mean, hopefully we'll some day we'll get a sane reporting mechanism
of Secure-reserved regions by ARM-TF and we can drop this juggling in
Non-secure firmware.

Best Regards,

Leif

> Best regards,
> Marcin
> 
> śr., 30 sty 2019 o 17:47 Leif Lindholm 
> napisał(a):
> 
> > Thanks for the rework.
> >
> > (We should probably move that broken-out function to ArmPkg at some point.)
> >
> > For the series:
> > Reviewed-by: Leif Lindholm 
> >
> > Pushed as b0bb325f20..0a7d8e7d93.
> >
> > On Mon, Jan 28, 2019 at 10:45:10AM +0100, Marcin Wojtas wrote:
> > > Hi,
> > >
> > > The third version of the patchset moves the new common
> > > header for Marvell SMC ID's to the IndustryStandard directory.
> > > What is more important, now 3 regions (described by new PCDs)
> > > are reserved separately. For that purpose a preparation
> > > patch was added, which extract existing reservation code
> > > into a new subroutine. More details can be found in
> > > the changelog below and the commit messages.
> > >
> > > Patches are available in the github:
> > >
> > https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/dram-upstream-r20190128
> > >
> > > I'm looking forward to the comments and remarks.
> > >
> > > Best regards,
> > > Marcin
> > >
> > > Changelog:
> > > v2 -> v3
> > > * 1/5
> > >   - New patch - extract memory reservation to a separate routine
> > >
> > > * 2/2
> > >   - Add new PCDs and reserve 3 regions (ARM-TF, PEI stack, OP-TEE)
> > > separately
> > >   - Update commit message accordingly
> > >
> > > * 3/5
> > >   - Move MvSmc.h to Include/IndustryStandard
> > >
> > > * 4,5/5
> > >   - Add Leif's RB
> > >
> > > v1 -> v2:
> > > * 1/4
> > >   - Improve commit log - mention single area size and new PEI stack base
> > >
> > > * 2/4 (new patch)
> > >   - Add common header for Marvell SMC ID's
> > >
> > > * 3/4
> > >   - Add function description comment
> > >   - Define and use ARMADA7K8K_AP806_INDEX
> > >   - Change function argument to EFI_PHYSICAL_ADDRESS
> > >
> > > * 4/4
> > >   - Move new SMC ID to MvSmc.h
> > >   - Include ArmadaSoCDescLib.h directly (instead indirectly via
> > BoardDesc.h)
> > >   - Remove ARMADA7K8K_AP806_INDEX macro
> > >
> > > Grzegorz Jaszczyk (2):
> > >   Marvell/Library: ArmadaSoCDescLib: Add North Bridge description
> > >   Marvell/Armada7k8k: Read DRAM settings from ARM-TF
> > >
> > > Marcin Wojtas (3):
> > >   Marvell/Armada7k8k: Refactor reserving memory regions
> > >   Marvell/Armada7k8k: Shift PEI stack base and extend memory reservation
> > >   Marvell/Library: Introduce common header for the SMC ID's
> > >
> > >  Silicon/Marvell/Marvell.dec
> >   |   8 +-
> > >  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> >   |  16 ++-
> > >  Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLib.inf
> >  |   3 +
> > >
> > Silicon/Marvell/Armada7k8k/Library/Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.inf
> > |   8 +-
> > >  Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.h
> >   |  25 -
> > >
> > Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
> >  |   6 ++
> > >  Silicon/Marvell/Include/IndustryStandard/MvSmc.h
> >  |  24 +
> > >  Silicon/Marvell/Include/Library/ArmadaSoCDescLib.h
> >  |  28 +
> > >  Silicon/Marvell/Library/ComPhyLib/ComPhySipSvc.h
> >  |   8 +-
> > >  Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c
> >   |  60 ---
> > >
> > Silicon/Marvell/Armada7k8k/Library/Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.c
> >  | 107 +---
> > >
> > Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
> >  |  34 +++
> > >  Silicon/Marvell/Library/ComPhyLib/ComPhyCp110.c
> >   |  14 +--
> > >  13 files changed, 220 insertions(+), 121 deletions(-)
> > >  create mode 100644 Silicon/Marvell/Include/IndustryStandard/MvSmc.h
> > >
> > > --
> > > 2.7.4
> > >
> >
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] OvmfPkg: Support booting from Fusion-MPT SCSI controllers

2019-01-31 Thread Nikita Leshenko
This series adds driver support for:
- LSI53C1030
- SAS1068
- SAS1068E

These controllers are widely supported by QEMU, VirtualBox and VMWare. This work
is part of the more general agenda of enhancing OVMF boot device support to have
feature parity with SeaBIOS.

We have also developed support for PVSCSI which we will submit in a separate
patch series.

Thanks,
Nikita


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


[edk2] [PATCH 01/14] OvmfPkg/MptScsiDxe: Create empty driver

2019-01-31 Thread Nikita Leshenko
In preparation for implementing LSI Fusion MPT SCSI devices, create a
basic scaffolding for a driver.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Nikita Leshenko 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Aaron Young 
Reviewed-by: Liran Alon 
---
 OvmfPkg/MptScsiDxe/MptScsi.c  | 30 
 OvmfPkg/MptScsiDxe/MptScsiDxe.inf | 33 +++
 OvmfPkg/OvmfPkgIa32.dsc   |  1 +
 OvmfPkg/OvmfPkgIa32.fdf   |  1 +
 OvmfPkg/OvmfPkgIa32X64.dsc|  1 +
 OvmfPkg/OvmfPkgIa32X64.fdf|  1 +
 OvmfPkg/OvmfPkgX64.dsc|  1 +
 OvmfPkg/OvmfPkgX64.fdf|  1 +
 8 files changed, 69 insertions(+)
 create mode 100644 OvmfPkg/MptScsiDxe/MptScsi.c
 create mode 100644 OvmfPkg/MptScsiDxe/MptScsiDxe.inf

diff --git a/OvmfPkg/MptScsiDxe/MptScsi.c b/OvmfPkg/MptScsiDxe/MptScsi.c
new file mode 100644
index 00..73a693741d
--- /dev/null
+++ b/OvmfPkg/MptScsiDxe/MptScsi.c
@@ -0,0 +1,30 @@
+/** @file
+
+  This driver produces Extended SCSI Pass Thru Protocol instances for
+  LSI Fusion MPT SCSI devices.
+
+  Copyright (C) 2018, Oracle and/or its affiliates. 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.
+
+**/
+
+//
+// Entry Point
+//
+
+EFI_STATUS
+EFIAPI
+MptScsiEntryPoint (
+  IN EFI_HANDLE   ImageHandle,
+  IN EFI_SYSTEM_TABLE *SystemTable
+  )
+{
+  return EFI_UNSUPPORTED;
+}
diff --git a/OvmfPkg/MptScsiDxe/MptScsiDxe.inf 
b/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
new file mode 100644
index 00..c558d78034
--- /dev/null
+++ b/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
@@ -0,0 +1,33 @@
+## @file
+# This driver produces Extended SCSI Pass Thru Protocol instances for
+# LSI Fusion MPT SCSI devices.
+#
+# Copyright (C) 2018, Oracle and/or its affiliates. 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.
+#
+##
+
+[Defines]
+  INF_VERSION= 0x00010005
+  BASE_NAME  = MptScsiDxe
+  FILE_GUID  = 2B3DB5DD-B315-4961-8454-0AFF3C811B19
+  MODULE_TYPE= UEFI_DRIVER
+  VERSION_STRING = 1.0
+  ENTRY_POINT= MptScsiEntryPoint
+
+[Sources]
+  MptScsi.c
+
+[Packages]
+  MdePkg/MdePkg.dec
+  OvmfPkg/OvmfPkg.dec
+
+[LibraryClasses]
+  UefiDriverEntryPoint
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index aee19b75d7..52458859b6 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -708,6 +708,7 @@
   OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
   OvmfPkg/XenBusDxe/XenBusDxe.inf
   OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+  OvmfPkg/MptScsiDxe/MptScsiDxe.inf
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf
index e013099136..73e36636e0 100644
--- a/OvmfPkg/OvmfPkgIa32.fdf
+++ b/OvmfPkg/OvmfPkgIa32.fdf
@@ -233,6 +233,7 @@ INF  OvmfPkg/VirtioRngDxe/VirtioRng.inf
 INF  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
 INF  OvmfPkg/XenBusDxe/XenBusDxe.inf
 INF  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+INF  OvmfPkg/MptScsiDxe/MptScsiDxe.inf
 
 !if $(SECURE_BOOT_ENABLE) == TRUE
   INF  
SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
index 90cbd8e341..d8ea2addb2 100644
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
@@ -717,6 +717,7 @@
   OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
   OvmfPkg/XenBusDxe/XenBusDxe.inf
   OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
+  OvmfPkg/MptScsiDxe/MptScsiDxe.inf
   MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
   
MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCounterRuntimeDxe.inf
   MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
diff --git a/OvmfPkg/OvmfPkgIa32X64.fdf b/OvmfPkg/OvmfPkgIa32X64.fdf
index afaa334384..e22a223e7e 100644
--- a/OvmfPkg/OvmfPkgIa32X64.fdf
+++ b/OvmfPkg/OvmfPkgIa32X64.fdf
@@ -234,6 +234,7 @@ INF  OvmfPkg/VirtioRngDxe/VirtioRng.inf
 INF  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
 INF  OvmfPkg/XenBusDxe/XenBusDxe.inf
 

[edk2] [PATCH 06/14] OvmfPkg/MptScsiDxe: Report one Target and one LUN

2019-01-31 Thread Nikita Leshenko
Support for multiple targets will be implemented in a later commit in
this series.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Nikita Leshenko 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Aaron Young 
Reviewed-by: Liran Alon 
---
 OvmfPkg/MptScsiDxe/MptScsi.c | 34 --
 1 file changed, 32 insertions(+), 2 deletions(-)

diff --git a/OvmfPkg/MptScsiDxe/MptScsi.c b/OvmfPkg/MptScsiDxe/MptScsi.c
index 6b655d9fe8..8ce7986b1d 100644
--- a/OvmfPkg/MptScsiDxe/MptScsi.c
+++ b/OvmfPkg/MptScsiDxe/MptScsi.c
@@ -68,6 +68,21 @@ MptScsiPassThru (
   return EFI_UNSUPPORTED;
 }
 
+STATIC
+BOOLEAN
+IsTargetInitialized (
+  IN UINT8  *Target
+  )
+{
+  int i;
+  for (i = 0; i < TARGET_MAX_BYTES; ++i) {
+if (Target[i] != 0xFF) {
+  return TRUE;
+}
+  }
+  return FALSE;
+}
+
 STATIC
 EFI_STATUS
 EFIAPI
@@ -78,7 +93,15 @@ MptScsiGetNextTargetLun (
   )
 {
   DEBUG ((EFI_D_INFO, "MptScsiGetNextTargetLun %d %d\n", **Target, *Lun));
-  return EFI_UNSUPPORTED;
+
+  // Currently support only target 0 LUN 0, so hardcode it
+  if (!IsTargetInitialized (*Target)) {
+**Target = 0;
+*Lun = 0;
+return EFI_SUCCESS;
+  } else {
+return EFI_NOT_FOUND;
+  }
 }
 
 STATIC
@@ -90,7 +113,14 @@ MptScsiGetNextTarget (
   )
 {
   DEBUG ((EFI_D_INFO, "MptScsiGetNextTarget\n"));
-  return EFI_UNSUPPORTED;
+
+  // Currently support only target 0 LUN 0, so hardcode it
+  if (!IsTargetInitialized (*Target)) {
+**Target = 0;
+return EFI_SUCCESS;
+  } else {
+return EFI_NOT_FOUND;
+  }
 }
 
 STATIC
-- 
2.20.1

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


[edk2] [PATCH 08/14] OvmfPkg/MptScsiDxe: Implement GetTargetLun

2019-01-31 Thread Nikita Leshenko
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Nikita Leshenko 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Aaron Young 
Reviewed-by: Liran Alon 
---
 OvmfPkg/MptScsiDxe/MptScsi.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/OvmfPkg/MptScsiDxe/MptScsi.c b/OvmfPkg/MptScsiDxe/MptScsi.c
index 7f360158e7..719948a73d 100644
--- a/OvmfPkg/MptScsiDxe/MptScsi.c
+++ b/OvmfPkg/MptScsiDxe/MptScsi.c
@@ -164,7 +164,17 @@ MptScsiGetTargetLun (
   )
 {
   DEBUG ((EFI_D_INFO, "MptScsiGetTargetLun\n"));
-  return EFI_UNSUPPORTED;
+
+  if (DevicePath->Type!= MESSAGING_DEVICE_PATH ||
+  DevicePath->SubType != MSG_SCSI_DP) {
+return EFI_UNSUPPORTED;
+  }
+
+  SCSI_DEVICE_PATH *ScsiDevicePath = (SCSI_DEVICE_PATH *) DevicePath;
+  **Target = ScsiDevicePath->Pun;
+  *Lun = ScsiDevicePath->Lun;
+
+  return EFI_SUCCESS;
 }
 
 STATIC
-- 
2.20.1

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


[edk2] [PATCH 09/14] OvmfPkg/MptScsiDxe: Open PciIo protocol for later use

2019-01-31 Thread Nikita Leshenko
This will give us an exclusive access to the PciIo of this device
after it was started and until is will be stopped.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Nikita Leshenko 
Reviewed-by: Konrad Rzeszutek Wilk 
Reviewed-by: Aaron Young 
Reviewed-by: Liran Alon 
---
 OvmfPkg/MptScsiDxe/MptScsi.c | 24 
 1 file changed, 24 insertions(+)

diff --git a/OvmfPkg/MptScsiDxe/MptScsi.c b/OvmfPkg/MptScsiDxe/MptScsi.c
index 719948a73d..29816fb98c 100644
--- a/OvmfPkg/MptScsiDxe/MptScsi.c
+++ b/OvmfPkg/MptScsiDxe/MptScsi.c
@@ -42,6 +42,7 @@ typedef struct {
   UINT32  Signature;
   EFI_EXT_SCSI_PASS_THRU_PROTOCOL PassThru;
   EFI_EXT_SCSI_PASS_THRU_MODE PassThruMode;
+  EFI_PCI_IO_PROTOCOL *PciIo;
 } MPT_SCSI_DEV;
 
 #define MPT_SCSI_FROM_PASS_THRU(PassThruPtr) \
@@ -295,6 +296,17 @@ MptScsiControllerStart (
   ZeroMem (Dev, sizeof (*Dev));
   Dev->Signature = MPT_SCSI_DEV_SIGNATURE;
 
+  Status = gBS->OpenProtocol (
+  ControllerHandle,
+  ,
+  (VOID **) >PciIo,
+  This->DriverBindingHandle,
+  ControllerHandle,
+  EFI_OPEN_PROTOCOL_BY_DRIVER); // exclusive for us until 
stopped
+  if (EFI_ERROR (Status)) {
+goto Done;
+  }
+
   Dev->PassThruMode.AdapterId = MAX_UINT32; // Host adapter channel, doesn't 
exist
   Dev->PassThruMode.Attributes =
 EFI_EXT_SCSI_PASS_THRU_ATTRIBUTES_PHYSICAL
@@ -320,6 +332,13 @@ MptScsiControllerStart (
   DEBUG ((EFI_D_INFO, "MptScsi Installed\n"));
 Done:
   if (EFI_ERROR (Status)) {
+if (Dev->PciIo) {
+  gBS->CloseProtocol (
+  ControllerHandle,
+  ,
+  This->DriverBindingHandle,
+  ControllerHandle);
+}
 gBS->FreePages ((EFI_PHYSICAL_ADDRESS) (UINTN) Dev, EFI_SIZE_TO_PAGES 
(sizeof (*Dev)));
   }
 
@@ -359,6 +378,11 @@ MptScsiControllerStop (
   ControllerHandle,
   ,
   >PassThru);
+  gBS->CloseProtocol (
+  ControllerHandle,
+  ,
+  This->DriverBindingHandle,
+  ControllerHandle);
 
   gBS->FreePages ((EFI_PHYSICAL_ADDRESS) (UINTN) Dev, EFI_SIZE_TO_PAGES 
(sizeof (*Dev)));
 
-- 
2.20.1

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


Re: [edk2] [Patch v2 00/33] BaseTools python3 migration patch set

2019-01-31 Thread Gao, Liming
Bob:
  I have no other comments on this patch set. Reviewed-by: Liming Gao 


Thanks
Liming
> -Original Message-
> From: Feng, Bob C
> Sent: Wednesday, January 30, 2019 1:25 PM
> To: Gao, Liming ; Laszlo Ersek 
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] [Patch v2 00/33] BaseTools python3 migration patch set
> 
> I agree this proposal.
> I plan to push python3 patch set to edk2 master in this Friday morning, Feb.1 
> PRC time if there is no more comments or no critical issues
> found.
> 
> Thanks,
> Bob
> 
> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, January 30, 2019 9:53 AM
> To: Laszlo Ersek ; Feng, Bob C 
> Cc: edk2-devel@lists.01.org
> Subject: RE: [edk2] [Patch v2 00/33] BaseTools python3 migration patch set
> 
> Laszlo:
>  I agree your proposal. Push this patch set first if no other comments, then 
> continue to do minor bug fix.
> 
> Thanks
> Liming
> > -Original Message-
> > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> > Laszlo Ersek
> > Sent: Tuesday, January 29, 2019 9:07 PM
> > To: Feng, Bob C 
> > Cc: edk2-devel@lists.01.org
> > Subject: Re: [edk2] [Patch v2 00/33] BaseTools python3 migration patch
> > set
> >
> > Hi Bob,
> >
> > On 01/29/19 03:05, Feng, Bob C wrote:
> > > BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=55
> > >
> > > V2:
> > > The python files under CParser4 folder of ECC/Eot tool are generated
> > > by antlr4 and forpython3 usage.
> > > They have python3 specific syntax, for example the data type
> > > declaration for the arguments of a function. That is not compitable
> > > with python2. this patch is to remove these syntax.
> > >
> > > The version2 patch set is commit to
> > > https://github.com/BobCF/edk2.git branch py3basetools_v2
> >
> > (reusing the "test plan" from my email at
> >  > at.com>:)
> >
> > I ran the following tests, at commit 6edb6bd9f182 ("BaseTools: Eot
> > tool
> > Python3 adaption", 2019-01-29). Each test was performed in a clean
> > tree (after running "git clean -ffdx") and clean environment (I
> > re-sourced "edksetup.sh" for each test in separation). In addition,
> > the base tools were rebuilt (again from a clean tree) for each test,
> > with the following command [1]:
> >
> >   nice make -C "$EDK_TOOLS_PATH" -j $(getconf _NPROCESSORS_ONLN)
> >
> > (a) On my RHEL7.5 Workstation laptop, I have both the system-level
> > python packages installed (python-2.7.5-69.el7_5.x86_64), and the
> > extra
> > python-3.4 stuff from EPEL-7 (python34-3.4.9-1.el7.x86_64).
> >
> > (a1) Didn't set either PYTHON3_ENABLE or PYTHON_COMMAND. The build
> > utility picked
> >
> >   PYTHON_COMMAND   = /usr/bin/python3.4
> >
> > and I successfully built OvmfPkg for IA32, IA32X64, and X64; also
> > ArmVirtQemu for AARCH64. The built firmware images passed a smoke test
> > too.
> >
> > (a2) I removed all the python34 packages (and the dependent packages)
> > from my laptop. Didn't set either of PYTHON3_ENABLE and PYTHON_COMMAND.
> > (This is the configuration what a "normal" RHEL7 environment would
> > provide.) The "build" utility didn't print any PYTHON_COMMAND setting,
> > but the same fw platform builds as in (a1) completed fine. The smoke
> > tests passed again as well.
> >
> > (b) RHEL-8 virtual machine, with "/usr/bin/python3.6" from
> > python36-3.6.6-18.el8.x86_64, and "/usr/libexec/platform-python" from
> > platform-python-3.6.8-1.el8.x86_64.
> >
> > (b1) Didn't set either PYTHON3_ENABLE or PYTHON_COMMAND. The build
> > utility picked
> >
> >   PYTHON_COMMAND   = /usr/bin/python3.6
> >
> > and I successfully built OvmfPkg for IA32, IA32X64, and X64. (I don't
> > have a cross-compiler installed in this environment yet, nor a RHEL8
> > aarch64 KVM guest, so I couldn't test ArmVirtQemu for now).
> >
> > (b2) I set PYTHON_COMMAND to "/usr/libexec/platform-python". Didn't
> > set PYTHON3_ENABLE. The same builds as in (b1) succeeded.
> >
> >
> > For the series:
> >
> > Tested-by: Laszlo Ersek 
> >
> > Given that the testing is quite time consuming, I suggest that we push
> > v2 (assuming reviewers don't find critical issues), and address small
> > issues incrementally.
> >
> > Thanks!
> > Laszlo
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


[edk2] [PATCH 5/5] IntelSiliconPkg\Include\IndustryStandard: Update IGD_OPREGION_MBOX3 Structure

2019-01-31 Thread Digant H Solanki
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1454
Based on latest IGD OpRegion Spec, IGD_OPREGION_MBOX3 needs to be updated with 
two new members : Physical Address of Raw VBT Data (RVDA) and Size of Raw VBT 
Data (RVDS)

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Digant H Solanki 
Cc: Ray Ni 
Cc: Liming Gao 
Cc: Rangasai V Chaganty 
---
 IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h 
b/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
index 5ce80a5be8..300a85a717 100644
--- a/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
+++ b/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
@@ -4,9 +4,7 @@
 
   https://01.org/sites/default/files/documentation/skl_opregion_rev0p5.pdf
 
-  @note Fixed bug in the spec Mailbox3 - RM31 size from 0x45(69) to 0x46(70)
-
-  Copyright (c) 2016, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2019, Intel Corporation. All rights reserved.
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
   which accompanies this distribution.  The full text of the license may be 
found at
@@ -118,7 +116,9 @@ typedef struct {
   UINT64 FDSS;  ///< Offset 0x3AA DSS Buffer address allocated for 
IFFS feature
   UINT32 FDSP;  ///< Offset 0x3B2 Size of DSS buffer
   UINT32 STAT;  ///< Offset 0x3B6 State Indicator
-  UINT8  RM31[0x46];///< Offset 0x3BA - 0x3FF  Reserved Must be zero. Bug 
in spec 0x45(69)
+  UINT64 RVDA;  ///< Offset 0x3BA Physical address of Raw VBT data. 
Added from Spec Version 0.90 to support VBT greater than 6KB.
+  UINT32 RVDS;  ///< Offset 0x3C2 Size of Raw VBT data. Added from 
Spec Version 0.90 to support VBT greater than 6KB.
+  UINT8  RM32[0x3A];///< Offset 0x3C6 - 0x3FF  Reserved Must be zero.
 } IGD_OPREGION_MBOX3;
 
 ///
-- 
2.18.0.windows.1

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


Re: [edk2] [PATCH v5] MdePkg/BaseLib: Add Base64Encode() and Base64Decode()

2019-01-31 Thread Gao, Liming
Reviewed-by: Liming Gao 

> -Original Message-
> From: Zhang, Shenglei
> Sent: Thursday, January 31, 2019 3:37 PM
> To: edk2-devel@lists.01.org
> Cc: Mike Turner ; Kinney, Michael D 
> ; Gao, Liming 
> Subject: [PATCH v5] MdePkg/BaseLib: Add Base64Encode() and Base64Decode()
> 
> From: Mike Turner 
> 
> Introduce public functions Base64Encode and Base64Decode.
> https://bugzilla.tianocore.org/show_bug.cgi?id=1370
> 
> v2:1.Remove some white space.
>2.Add unit test with test vectors in RFC 4648.
>  https://github.com/shenglei10/edk2/tree/encode_test
>  https://github.com/shenglei10/edk2/tree/decode_test
> 
> v3:1.Align white space.
>2.Update comments of Base64Encode and Base64Decode.
>3.Change the use of macro RETURN_DEVICE_ERROR to
>  RETURN_INVALID_PARAMETER in string.c.
> 
> v4:Change parameters' names.
> 
> v5:1.Update usage of variables.
>2.Remove debug message in Base64Decode().
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Shenglei Zhang 
> ---
>  MdePkg/Include/Library/BaseLib.h |  56 ++
>  MdePkg/Library/BaseLib/String.c  | 331 +++
>  2 files changed, 387 insertions(+)
> 
> diff --git a/MdePkg/Include/Library/BaseLib.h 
> b/MdePkg/Include/Library/BaseLib.h
> index 1eb842384e..03173def58 100644
> --- a/MdePkg/Include/Library/BaseLib.h
> +++ b/MdePkg/Include/Library/BaseLib.h
> @@ -2720,6 +2720,62 @@ AsciiStrnToUnicodeStrS (
>OUT UINTN *DestinationLength
>);
> 
> +/**
> +  Convert binary data to a Base64 encoded ascii string based on RFC4648.
> +
> +  Produce a Null-terminated Ascii string in the output buffer specified by 
> Destination and DestinationSize.
> +  The Ascii string is produced by converting the data string specified by 
> Source and SourceLength.
> +
> +  @param Source   Input UINT8 data
> +  @param SourceLength Number of UINT8 bytes of data
> +  @param Destination  Pointer to output string buffer
> +  @param DestinationSize  Size of ascii buffer. Set to 0 to get the size 
> needed.
> +  Caller is responsible for passing in buffer of 
> DestinationSize
> +
> +  @retval RETURN_SUCCESS When ascii buffer is filled in.
> +  @retval RETURN_INVALID_PARAMETER   If Source is NULL or DestinationSize is 
> NULL.
> +  @retval RETURN_INVALID_PARAMETER   If SourceLength or DestinationSize is 
> bigger than (MAX_ADDRESS - (UINTN)Destination).
> +  @retval RETURN_BUFFER_TOO_SMALLIf SourceLength is 0 and 
> DestinationSize is <1.
> +  @retval RETURN_BUFFER_TOO_SMALLIf Destination is NULL or 
> DestinationSize is smaller than required buffersize.
> +
> +**/
> +RETURN_STATUS
> +EFIAPI
> +Base64Encode (
> +  IN  CONST UINT8  *Source,
> +  INUINTN   SourceLength,
> +  OUT   CHAR8  *Destination  OPTIONAL,
> +  IN OUTUINTN  *DestinationSize
> +  );
> +
> +/**
> +  Convert Base64 ascii string to binary data based on RFC4648.
> +
> +  Produce Null-terminated binary data in the output buffer specified by 
> Destination and DestinationSize.
> +  The binary data is produced by converting the Base64 ascii string 
> specified by Source and SourceLength.
> +
> +  @param Source  Input ASCII characters
> +  @param SourceLengthNumber of ASCII characters
> +  @param Destination Pointer to output buffer
> +  @param DestinationSize Caller is responsible for passing in buffer of at 
> least DestinationSize.
> + Set 0 to get the size needed. Set to bytes stored 
> on return.
> +
> +  @retval RETURN_SUCCESS When binary buffer is filled in.
> +  @retval RETURN_INVALID_PARAMETER   If Source is NULL or DestinationSize is 
> NULL.
> +  @retval RETURN_INVALID_PARAMETER   If SourceLength or DestinationSize is 
> bigger than (MAX_ADDRESS -(UINTN)Destination ).
> +  @retval RETURN_INVALID_PARAMETER   If there is any invalid character in 
> input stream.
> +  @retval RETURN_BUFFER_TOO_SMALLIf buffer length is smaller than 
> required buffer size.
> +
> + **/
> +RETURN_STATUS
> +EFIAPI
> +Base64Decode (
> +  IN  CONST CHAR8  *Source,
> +  INUINTN   SourceLength,
> +  OUT   UINT8  *Destination  OPTIONAL,
> +  IN OUTUINTN  *DestinationSize
> +  );
> +
>  /**
>Converts an 8-bit value to an 8-bit BCD value.
> 
> diff --git a/MdePkg/Library/BaseLib/String.c b/MdePkg/Library/BaseLib/String.c
> index e6df12797d..87d0a9d1dc 100644
> --- a/MdePkg/Library/BaseLib/String.c
> +++ b/MdePkg/Library/BaseLib/String.c
> @@ -1763,6 +1763,337 @@ AsciiStrToUnicodeStr (
> 
>  #endif
> 
> +//
> +// The basis for Base64 encoding is RFC 4686 
> https://tools.ietf.org/html/rfc4648
> +//
> +// RFC 4686 has a number of MAY and SHOULD cases.  This implementation 
> chooses
> +// the more restrictive versions for security concerns (see RFC 4686 section 
> 3.3).
> +//
> +// A invalid character, if encountered during the decode operation, 

Re: [edk2] [PATCH 5/5] IntelSiliconPkg\Include\IndustryStandard: Update IGD_OPREGION_MBOX3 Structure

2019-01-31 Thread Gao, Liming
One comment on the title. This is Patch V5, not Patch 5/5. You don't need to 
send new patch. 

Thanks
Liming
> -Original Message-
> From: Solanki, Digant H
> Sent: Thursday, January 31, 2019 4:01 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ray ; Gao, Liming ; Chaganty, 
> Rangasai V 
> Subject: [PATCH 5/5] IntelSiliconPkg\Include\IndustryStandard: Update 
> IGD_OPREGION_MBOX3 Structure
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1454
> Based on latest IGD OpRegion Spec, IGD_OPREGION_MBOX3 needs to be updated 
> with two new members : Physical Address of Raw VBT
> Data (RVDA) and Size of Raw VBT Data (RVDS)
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Digant H Solanki 
> Cc: Ray Ni 
> Cc: Liming Gao 
> Cc: Rangasai V Chaganty 
> ---
>  IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h 
> b/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
> index 5ce80a5be8..300a85a717 100644
> --- a/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
> +++ b/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
> @@ -4,9 +4,7 @@
> 
>https://01.org/sites/default/files/documentation/skl_opregion_rev0p5.pdf
> 
> -  @note Fixed bug in the spec Mailbox3 - RM31 size from 0x45(69) to 0x46(70)
> -
> -  Copyright (c) 2016, Intel Corporation. All rights reserved.
> +  Copyright (c) 2016 - 2019, Intel Corporation. All rights reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD 
> License
>which accompanies this distribution.  The full text of the license may be 
> found at
> @@ -118,7 +116,9 @@ typedef struct {
>UINT64 FDSS;  ///< Offset 0x3AA DSS Buffer address allocated for 
> IFFS feature
>UINT32 FDSP;  ///< Offset 0x3B2 Size of DSS buffer
>UINT32 STAT;  ///< Offset 0x3B6 State Indicator
> -  UINT8  RM31[0x46];///< Offset 0x3BA - 0x3FF  Reserved Must be zero. 
> Bug in spec 0x45(69)
> +  UINT64 RVDA;  ///< Offset 0x3BA Physical address of Raw VBT data. 
> Added from Spec Version 0.90 to support VBT greater
> than 6KB.
> +  UINT32 RVDS;  ///< Offset 0x3C2 Size of Raw VBT data. Added from 
> Spec Version 0.90 to support VBT greater than 6KB.
> +  UINT8  RM32[0x3A];///< Offset 0x3C6 - 0x3FF  Reserved Must be zero.
>  } IGD_OPREGION_MBOX3;
> 
>  ///
> --
> 2.18.0.windows.1

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


Re: [edk2] [RFC] Proposal to split Pkgs

2019-01-31 Thread Ni, Ray

On 1/31/2019 3:51 PM, Ard Biesheuvel wrote:

The POC code is inhttps://github.com/jyao1/edk2/tree/ReOrg.
It basically split the EDKII common code to three directories:
Core/, Device/, and Feature/.

I'm not sure I like the 'Device' name, but that's not that important
at this stage - I like that this is split up the way it is.

I also think a lot of things currently under Feture/misc could be
broken out into additional subdirectories under Feature/.


The code is in very early POC phase and only code in Core/ directory
can pass the build.
I would like to gather feedbacks through this RFC to see whether
this splitting direction makes sense.
Is there any other better ways of splitting?
Or perhaps do not split in such a small granularity?

I think this would be my only negative(ish) feedback on the POC.

While it has the benefit of modules requiring to specify more
precisely which functionality they are pulling in...
...it means that they now need to list*everything*.

And with the mechanism by which I have seen Intel engineers make use
of PACKAGES_PATH in the past*, we end up with a bazillion packages
that need to be added individually to this variable for each build.

No. "PACKAGES_PATH" only contains paths pointing to the*parent*
directory of *Pkg. In this case, it equals to:
/work/edk2/Core:/work/edk2/Device:/work/edk2/Feature/security:/work/edk2/Feature/network:/work/edk2/Feature/misc


Could we*please*  not do this? PACKAGES_PATH is very useful for
combining packages from different repositories, but that does not mean
we should split up the core repository in this way.

What we will end up with is platforms that use

   Core/Package/Foo.inf

and platforms that use

   Package/Foo.inf

which creates an aliasing mess where the same file is reachable in
different ways. Also, it encourages the behavior where you need to
fetch version X of repo A and version Y of repo B, and the whole point
of open sourcing is to have all code co-exist in the same source tree.



Ard,
Some platforms which define PACKAGES_PATH to "/work/edk2" will have 
"Core/Package/Foo.inf" in the DSC/FDF.
Some platforms which define PACKAGES_PATH to "/work/edk2/Core" will have 
"Package/Foo.inf" in the DSC/FDF.

It's bad and I 100% agree!
The basic rule behind that is PACKAGES_PATH should only contains path 
pointing to the root of repo.


Thanks for raising a very good concern on putting packages inside 
sub-directory.



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


Re: [edk2] [PATCH 5/5] IntelSiliconPkg\Include\IndustryStandard: Update IGD_OPREGION_MBOX3 Structure

2019-01-31 Thread Ni, Ray
Reviewed-by: Ray Ni 

> -Original Message-
> From: Solanki, Digant H 
> Sent: Thursday, January 31, 2019 4:01 PM
> To: edk2-devel@lists.01.org
> Cc: Ni, Ray ; Gao, Liming ;
> Chaganty, Rangasai V 
> Subject: [PATCH 5/5] IntelSiliconPkg\Include\IndustryStandard: Update
> IGD_OPREGION_MBOX3 Structure
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1454
> Based on latest IGD OpRegion Spec, IGD_OPREGION_MBOX3 needs to be
> updated with two new members : Physical Address of Raw VBT Data (RVDA)
> and Size of Raw VBT Data (RVDS)
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Digant H Solanki 
> Cc: Ray Ni 
> Cc: Liming Gao 
> Cc: Rangasai V Chaganty 
> ---
>  IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
> b/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
> index 5ce80a5be8..300a85a717 100644
> --- a/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
> +++ b/IntelSiliconPkg/Include/IndustryStandard/IgdOpRegion.h
> @@ -4,9 +4,7 @@
> 
>https://01.org/sites/default/files/documentation/skl_opregion_rev0p5.pdf
> 
> -  @note Fixed bug in the spec Mailbox3 - RM31 size from 0x45(69) to 0x46(70)
> -
> -  Copyright (c) 2016, Intel Corporation. All rights reserved.
> +  Copyright (c) 2016 - 2019, Intel Corporation. All rights
> + reserved.
>This program and the accompanying materials
>are licensed and made available under the terms and conditions of the BSD
> License
>which accompanies this distribution.  The full text of the license may be
> found at @@ -118,7 +116,9 @@ typedef struct {
>UINT64 FDSS;  ///< Offset 0x3AA DSS Buffer address allocated for 
> IFFS
> feature
>UINT32 FDSP;  ///< Offset 0x3B2 Size of DSS buffer
>UINT32 STAT;  ///< Offset 0x3B6 State Indicator
> -  UINT8  RM31[0x46];///< Offset 0x3BA - 0x3FF  Reserved Must be zero.
> Bug in spec 0x45(69)
> +  UINT64 RVDA;  ///< Offset 0x3BA Physical address of Raw VBT data.
> Added from Spec Version 0.90 to support VBT greater than 6KB.
> +  UINT32 RVDS;  ///< Offset 0x3C2 Size of Raw VBT data. Added from
> Spec Version 0.90 to support VBT greater than 6KB.
> +  UINT8  RM32[0x3A];///< Offset 0x3C6 - 0x3FF  Reserved Must be zero.
>  } IGD_OPREGION_MBOX3;
> 
>  ///
> --
> 2.18.0.windows.1

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


[edk2] [PATCH] SecurityPkg: Add NULL check of pointer variable before using it

2019-01-31 Thread Maggie Chu
https://bugzilla.tianocore.org/show_bug.cgi?id=1503
A pointer variable should be checked if it is NULL or Valid before using it.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Maggie Chu 
Cc: Chao Zhang 
Cc: Jiewen Yao 
Cc: Eric Dong 
---
 SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c 
b/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c
index 734c5f06ff..f79f9f7282 100644
--- a/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c
+++ b/SecurityPkg/Tcg/Opal/OpalPassword/OpalDriver.c
@@ -436,6 +436,9 @@ BuildOpalDeviceInfoAta (
 
   DevInfoAta = AllocateZeroPool (DevInfoLengthAta);
   ASSERT (DevInfoAta != NULL);
+  if (DevInfoAta == NULL) {
+return;
+  }
 
   TempDevInfoAta = DevInfoAta;
   TmpDev = mOpalDriver.DeviceList;
@@ -527,6 +530,9 @@ BuildOpalDeviceInfoNvme (
 
   DevInfoNvme = AllocateZeroPool (DevInfoLengthNvme);
   ASSERT (DevInfoNvme != NULL);
+  if (DevInfoNvme == NULL) {
+return;
+  }
 
   TempDevInfoNvme = DevInfoNvme;
   TmpDev = mOpalDriver.DeviceList;
-- 
2.16.2.windows.1

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


Re: [edk2] [platforms: PATCH v3 0/5] Armada7k8k memory handling update

2019-01-31 Thread Marcin Wojtas
czw., 31 sty 2019 o 11:28 Leif Lindholm  napisał(a):
>
> On Thu, Jan 31, 2019 at 08:01:08AM +0100, Marcin Wojtas wrote:
> > Hi Leif,
> >
> > Thanks a lot. While at it - do you think ArmPkg/Include/Library/ArmLib.h
> > / ArmPkg/Library/ArmLib/ArmLib.c would be a proper place for it?
>
> As good a place as any. While not ARM-architecture specific, I feel
> it's probably ARM-platform specific.
>
> I mean, hopefully we'll some day we'll get a sane reporting mechanism
> of Secure-reserved regions by ARM-TF and we can drop this juggling in
> Non-secure firmware.
>

Agree on ARM-TF dependency, but the code is IMO pretty generic itself.
In the merged version I also used this routine to cut out a hole in
the HoB for the reason not related to NS region - therefore I think
even MdePkg/Library would be good to go :)

Marcin

> > Best regards,
> > Marcin
> >
> > śr., 30 sty 2019 o 17:47 Leif Lindholm 
> > napisał(a):
> >
> > > Thanks for the rework.
> > >
> > > (We should probably move that broken-out function to ArmPkg at some 
> > > point.)
> > >
> > > For the series:
> > > Reviewed-by: Leif Lindholm 
> > >
> > > Pushed as b0bb325f20..0a7d8e7d93.
> > >
> > > On Mon, Jan 28, 2019 at 10:45:10AM +0100, Marcin Wojtas wrote:
> > > > Hi,
> > > >
> > > > The third version of the patchset moves the new common
> > > > header for Marvell SMC ID's to the IndustryStandard directory.
> > > > What is more important, now 3 regions (described by new PCDs)
> > > > are reserved separately. For that purpose a preparation
> > > > patch was added, which extract existing reservation code
> > > > into a new subroutine. More details can be found in
> > > > the changelog below and the commit messages.
> > > >
> > > > Patches are available in the github:
> > > >
> > > https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/dram-upstream-r20190128
> > > >
> > > > I'm looking forward to the comments and remarks.
> > > >
> > > > Best regards,
> > > > Marcin
> > > >
> > > > Changelog:
> > > > v2 -> v3
> > > > * 1/5
> > > >   - New patch - extract memory reservation to a separate routine
> > > >
> > > > * 2/2
> > > >   - Add new PCDs and reserve 3 regions (ARM-TF, PEI stack, OP-TEE)
> > > > separately
> > > >   - Update commit message accordingly
> > > >
> > > > * 3/5
> > > >   - Move MvSmc.h to Include/IndustryStandard
> > > >
> > > > * 4,5/5
> > > >   - Add Leif's RB
> > > >
> > > > v1 -> v2:
> > > > * 1/4
> > > >   - Improve commit log - mention single area size and new PEI stack base
> > > >
> > > > * 2/4 (new patch)
> > > >   - Add common header for Marvell SMC ID's
> > > >
> > > > * 3/4
> > > >   - Add function description comment
> > > >   - Define and use ARMADA7K8K_AP806_INDEX
> > > >   - Change function argument to EFI_PHYSICAL_ADDRESS
> > > >
> > > > * 4/4
> > > >   - Move new SMC ID to MvSmc.h
> > > >   - Include ArmadaSoCDescLib.h directly (instead indirectly via
> > > BoardDesc.h)
> > > >   - Remove ARMADA7K8K_AP806_INDEX macro
> > > >
> > > > Grzegorz Jaszczyk (2):
> > > >   Marvell/Library: ArmadaSoCDescLib: Add North Bridge description
> > > >   Marvell/Armada7k8k: Read DRAM settings from ARM-TF
> > > >
> > > > Marcin Wojtas (3):
> > > >   Marvell/Armada7k8k: Refactor reserving memory regions
> > > >   Marvell/Armada7k8k: Shift PEI stack base and extend memory reservation
> > > >   Marvell/Library: Introduce common header for the SMC ID's
> > > >
> > > >  Silicon/Marvell/Marvell.dec
> > >   |   8 +-
> > > >  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> > >   |  16 ++-
> > > >  Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLib.inf
> > >  |   3 +
> > > >
> > > Silicon/Marvell/Armada7k8k/Library/Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.inf
> > > |   8 +-
> > > >  Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.h
> > >   |  25 -
> > > >
> > > Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
> > >  |   6 ++
> > > >  Silicon/Marvell/Include/IndustryStandard/MvSmc.h
> > >  |  24 +
> > > >  Silicon/Marvell/Include/Library/ArmadaSoCDescLib.h
> > >  |  28 +
> > > >  Silicon/Marvell/Library/ComPhyLib/ComPhySipSvc.h
> > >  |   8 +-
> > > >  Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c
> > >   |  60 ---
> > > >
> > > Silicon/Marvell/Armada7k8k/Library/Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.c
> > >  | 107 +---
> > > >
> > > Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.c
> > >  |  34 +++
> > > >  Silicon/Marvell/Library/ComPhyLib/ComPhyCp110.c
> > >   |  14 +--
> > > >  13 files changed, 220 insertions(+), 121 deletions(-)
> > > >  create mode 100644 Silicon/Marvell/Include/IndustryStandard/MvSmc.h
> > > >
> > > > --
> > > > 2.7.4
> > > >
> 

Re: [edk2] [platforms: PATCH v3 0/5] Armada7k8k memory handling update

2019-01-31 Thread Leif Lindholm
On Thu, Jan 31, 2019 at 01:06:15PM +0100, Marcin Wojtas wrote:
> czw., 31 sty 2019 o 11:28 Leif Lindholm  napisał(a):
> >
> > On Thu, Jan 31, 2019 at 08:01:08AM +0100, Marcin Wojtas wrote:
> > > Hi Leif,
> > >
> > > Thanks a lot. While at it - do you think ArmPkg/Include/Library/ArmLib.h
> > > / ArmPkg/Library/ArmLib/ArmLib.c would be a proper place for it?
> >
> > As good a place as any. While not ARM-architecture specific, I feel
> > it's probably ARM-platform specific.
> >
> > I mean, hopefully we'll some day we'll get a sane reporting mechanism
> > of Secure-reserved regions by ARM-TF and we can drop this juggling in
> > Non-secure firmware.
> 
> Agree on ARM-TF dependency, but the code is IMO pretty generic itself.
> In the merged version I also used this routine to cut out a hole in
> the HoB for the reason not related to NS region - therefore I think
> even MdePkg/Library would be good to go :)

I don't really disagree with you, but that would be something to take
up with MdeModulePkg maintainers.

Also, I'm not seeing an obvious existing library to put it into. Would
it really be worth creating a new one for just this function?

/
Leif

> Marcin
> 
> > > Best regards,
> > > Marcin
> > >
> > > śr., 30 sty 2019 o 17:47 Leif Lindholm 
> > > napisał(a):
> > >
> > > > Thanks for the rework.
> > > >
> > > > (We should probably move that broken-out function to ArmPkg at some 
> > > > point.)
> > > >
> > > > For the series:
> > > > Reviewed-by: Leif Lindholm 
> > > >
> > > > Pushed as b0bb325f20..0a7d8e7d93.
> > > >
> > > > On Mon, Jan 28, 2019 at 10:45:10AM +0100, Marcin Wojtas wrote:
> > > > > Hi,
> > > > >
> > > > > The third version of the patchset moves the new common
> > > > > header for Marvell SMC ID's to the IndustryStandard directory.
> > > > > What is more important, now 3 regions (described by new PCDs)
> > > > > are reserved separately. For that purpose a preparation
> > > > > patch was added, which extract existing reservation code
> > > > > into a new subroutine. More details can be found in
> > > > > the changelog below and the commit messages.
> > > > >
> > > > > Patches are available in the github:
> > > > >
> > > > https://github.com/MarvellEmbeddedProcessors/edk2-open-platform/commits/dram-upstream-r20190128
> > > > >
> > > > > I'm looking forward to the comments and remarks.
> > > > >
> > > > > Best regards,
> > > > > Marcin
> > > > >
> > > > > Changelog:
> > > > > v2 -> v3
> > > > > * 1/5
> > > > >   - New patch - extract memory reservation to a separate routine
> > > > >
> > > > > * 2/2
> > > > >   - Add new PCDs and reserve 3 regions (ARM-TF, PEI stack, OP-TEE)
> > > > > separately
> > > > >   - Update commit message accordingly
> > > > >
> > > > > * 3/5
> > > > >   - Move MvSmc.h to Include/IndustryStandard
> > > > >
> > > > > * 4,5/5
> > > > >   - Add Leif's RB
> > > > >
> > > > > v1 -> v2:
> > > > > * 1/4
> > > > >   - Improve commit log - mention single area size and new PEI stack 
> > > > > base
> > > > >
> > > > > * 2/4 (new patch)
> > > > >   - Add common header for Marvell SMC ID's
> > > > >
> > > > > * 3/4
> > > > >   - Add function description comment
> > > > >   - Define and use ARMADA7K8K_AP806_INDEX
> > > > >   - Change function argument to EFI_PHYSICAL_ADDRESS
> > > > >
> > > > > * 4/4
> > > > >   - Move new SMC ID to MvSmc.h
> > > > >   - Include ArmadaSoCDescLib.h directly (instead indirectly via
> > > > BoardDesc.h)
> > > > >   - Remove ARMADA7K8K_AP806_INDEX macro
> > > > >
> > > > > Grzegorz Jaszczyk (2):
> > > > >   Marvell/Library: ArmadaSoCDescLib: Add North Bridge description
> > > > >   Marvell/Armada7k8k: Read DRAM settings from ARM-TF
> > > > >
> > > > > Marcin Wojtas (3):
> > > > >   Marvell/Armada7k8k: Refactor reserving memory regions
> > > > >   Marvell/Armada7k8k: Shift PEI stack base and extend memory 
> > > > > reservation
> > > > >   Marvell/Library: Introduce common header for the SMC ID's
> > > > >
> > > > >  Silicon/Marvell/Marvell.dec
> > > >   |   8 +-
> > > > >  Silicon/Marvell/Armada7k8k/Armada7k8k.dsc.inc
> > > >   |  16 ++-
> > > > >  Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLib.inf
> > > >  |   3 +
> > > > >
> > > > Silicon/Marvell/Armada7k8k/Library/Armada7k8kMemoryInitPeiLib/Armada7k8kMemoryInitPeiLib.inf
> > > > |   8 +-
> > > > >  Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.h
> > > >   |  25 -
> > > > >
> > > > Silicon/Marvell/Armada7k8k/Library/Armada7k8kSoCDescLib/Armada7k8kSoCDescLib.h
> > > >  |   6 ++
> > > > >  Silicon/Marvell/Include/IndustryStandard/MvSmc.h
> > > >  |  24 +
> > > > >  Silicon/Marvell/Include/Library/ArmadaSoCDescLib.h
> > > >  |  28 +
> > > > >  Silicon/Marvell/Library/ComPhyLib/ComPhySipSvc.h
> > > >  |   8 +-
> > > > >  Silicon/Marvell/Armada7k8k/Library/Armada7k8kLib/Armada7k8kLibMem.c
> > > >   

Re: [edk2] [PATCH v4 edk2-platforms 06/23] Platform/Raspberry/Pi3: Add RTC library

2019-01-31 Thread Pete Batard

On 2019.01.30 22:22, Leif Lindholm wrote:

First of all - this is something I would like to see contributed
directly to edk2 EmbeddedPkg. It's something me and Ard have discussed
adding at some point, but never getting around to.

I would also like to look into whether we could replace
PcdBootEpochSeconds with a -DBUILD_EPOCH=`date +%s` addition to the
CFLAGS in the .inf.


Okay, I'll look into both of these items.



Regards,

Leif

On Tue, Jan 29, 2019 at 04:26:38PM +, Pete Batard wrote:

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
  
Platform/Raspberry/Pi3/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
   | 221 
  
Platform/Raspberry/Pi3/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.inf
 |  43 
  2 files changed, 264 insertions(+)

diff --git 
a/Platform/Raspberry/Pi3/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
 
b/Platform/Raspberry/Pi3/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
new file mode 100644
index ..dea621ff03ef
--- /dev/null
+++ 
b/Platform/Raspberry/Pi3/Library/VirtualRealTimeClockLib/VirtualRealTimeClockLib.c
@@ -0,0 +1,221 @@
+/** @file
+ *
+ *  Implement dummy EFI RealTimeClock runtime services.
+ *
+ *  Copyright (c) 2018, Andrei Warkentin 
+ *  Copyright (c) Microsoft Corporation. All rights reserved.
+ *
+ *  This program and the accompanying materials
+ *  are licensed and made available under the terms and conditions of the BSD 
License
+ *  which accompanies this distribution.  The full text of the license may be 
found at
+ *  http://opensource.org/licenses/bsd-license.php
+ *
+ *  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
+ *  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
IMPLIED.
+ *
+ **/
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+   Returns the current time and date information, and the time-keeping 
capabilities
+   of the virtual RTC.
+
+   For simplicity, this LibGetTime does not report Years/Months, instead it 
will only report current
+   Day, Hours, Minutes and Seconds starting from the begining of CPU up-time. 
Otherwise, a more
+   complex logic will be required to account for leap years and days/month 
differences.
+
+   @param  Time  A pointer to storage to receive a snapshot of 
the current time.
+   @param  Capabilities  An optional pointer to a buffer to receive 
the real time clock
+   device's capabilities.
+
+   @retval EFI_SUCCESS   The operation completed successfully.
+   @retval EFI_INVALID_PARAMETER Time is NULL.
+   @retval EFI_DEVICE_ERROR  The time could not be retrieved due to 
hardware error.
+
+**/
+EFI_STATUS
+EFIAPI
+LibGetTime (
+  OUT EFI_TIME   *Time,
+  OUT EFI_TIME_CAPABILITIES  *Capabilities
+  )
+{
+  UINTN DataSize;
+  UINT64 Counter;
+  EFI_STATUS Status;
+  UINTN ElapsedSeconds;
+  UINT32 Remainder;
+  UINT32 Freq = ArmGenericTimerGetTimerFreq ();
+
+  if (Time == NULL) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  //
+  // Depend on ARM generic timer to report date/time relative to the
+  // start of CPU timer counting where date and time will always
+  // be relative to the date/time 1/1/1900 00H:00M:00S
+  //
+
+  ASSERT (Freq != 0);
+  if (Freq == 0) {
+return EFI_DEVICE_ERROR;
+  }
+
+  if (Capabilities) {
+Capabilities->Accuracy = 0;
+Capabilities->Resolution = Freq;
+Capabilities->SetsToZero = FALSE;
+  }
+
+  DataSize = sizeof (UINTN);
+  ElapsedSeconds = 0;
+  Status = EfiGetVariable (L"RtcEpochSeconds",
+ ,
+ NULL,
+ ,
+ );
+  if (EFI_ERROR (Status)) {
+ElapsedSeconds = PcdGet64 (PcdBootEpochSeconds);
+  }
+  Counter = GetPerformanceCounter ();
+  ElapsedSeconds += DivU64x32Remainder (Counter, Freq, );
+  EpochToEfiTime (ElapsedSeconds, Time);
+
+  //
+  // Frequency < 0x1, so Remainder < 0x1, then (Remainder * 
1,000,000,000)
+  // will not overflow 64-bit.
+  //
+  Time->Nanosecond = DivU64x32 (MultU64x64 ((UINT64)Remainder, 10U), 
Freq);
+
+  return EFI_SUCCESS;
+}
+
+
+/**
+   Sets the current local time and date information.
+
+   @param  Time  A pointer to the current time.
+
+   @retval EFI_SUCCESS   The operation completed successfully.
+   @retval EFI_INVALID_PARAMETER A time field is out of range.
+   @retval EFI_DEVICE_ERROR  The time could not be set due due to hardware 
error.
+
+**/
+EFI_STATUS
+EFIAPI
+LibSetTime (
+  IN EFI_TIME  *Time
+  )
+{
+  UINTN Epoch;
+
+  if (!IsTimeValid (Time)) {
+return EFI_INVALID_PARAMETER;
+  }
+
+  Epoch = EfiTimeToEpoch (Time);
+  return EfiSetVariable (L"RtcEpochSeconds", ,
+   EFI_VARIABLE_BOOTSERVICE_ACCESS |
+   EFI_VARIABLE_RUNTIME_ACCESS |
+   EFI_VARIABLE_NON_VOLATILE,
+   sizeof (Epoch),
+   );
+}
+
+
+/**
+   

Re: [edk2] [PATCH v4 edk2-platforms 20/23] Platform/Raspberry/Pi3: Add platform readme

2019-01-31 Thread Pete Batard

Hi Leif. Thanks for reviewing this patchset.

On 2019.01.30 21:50, Leif Lindholm wrote:

Hi Pete,

I will only have minor comments on this set, but I'll start with this
documentation.

On Tue, Jan 29, 2019 at 04:26:52PM +, Pete Batard wrote:

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
  Platform/Raspberry/Pi3/Readme.md | 259 
  Readme.md|   3 +
  2 files changed, 262 insertions(+)

diff --git a/Platform/Raspberry/Pi3/Readme.md b/Platform/Raspberry/Pi3/Readme.md
new file mode 100644
index ..7fb59ccdc321
--- /dev/null
+++ b/Platform/Raspberry/Pi3/Readme.md
@@ -0,0 +1,259 @@
+Raspberry Pi 3 EDK2 Platform Support
+
+
+# Summary
+
+This is a port of 64-bit Tiano Core UEFI firmware for the Raspberry Pi 3/3B+ 
platforms,
+based on [Ard Bisheuvel's 
64-bit](http://www.workofard.com/2017/02/uefi-on-the-pi/)
+and [Microsoft's 
32-bit](https://github.com/ms-iot/RPi-UEFI/tree/ms-iot/Pi3BoardPkg)
+implementations, as maintained by [Andrei 
Warkentin](https://github.com/andreiw/RaspberryPiPkg).
+
+This is meant as a generally useful 64-bit ATF + UEFI implementation for the 
Raspberry
+Pi 3/3B+ which should be good enough for most kind of UEFI development, as 
well as for
+running consummer Operating Systems in such as Linux or Windows.
+
+Raspberry Pi is a trademark of the [Raspberry Pi 
Foundation](http://www.raspberrypi.org).
+
+# Status
+
+This firmware, that has been validated to compile against the current
+[edk2](https://github.com/tianocore/edk2)/[edk2-platforms](https://github.com/tianocore/edk2-platforms),
+should be able to boot Linux (SUSE, Ubuntu), NetBSD, FreeBSD as well as 
Windows 10 ARM64
+(full GUI version).
+
+It also provides support for ATF ([Arm Trusted 
Platform](https://github.com/ARM-software/arm-trusted-firmware)).
+
+HDMI and the mini-UART serial port can be used for output devices, with 
mirrored output.
+USB keyboards and the mini-UART serial port can be used as input.
+
+The boot order is currently hardcoded, first to the USB ports and then to the 
uSD card.
+If there no bootable media media is found, the UEFI Shell is launched.
+Esc enters platform setup. F1 boots the UEFI Shell.
+
+# Building
+
+(These instructions were validated against the latest edk2 / edk2-platforms /
+edk2-non-osi as of 2019.01.27, on a Debian 9.6 x64 system).
+
+You may need to install the relevant compilation tools. Especially you should 
have the
+ACPI Source Language (ASL) compiler, `nasm` as well as a native compiler 
installed.


nasm? The x86 assembler?


I'll remove that.


+On a Debian system, you can get these prerequisites installed with:
+```
+sudo apt-get install build-essential acpica-tools nasm uuid-dev
+```
+
+**IMPORTANT:** We recommend the use of the Linaro GCC for compilation instead 
of
+your system's native ARM64 GCC cross compiler.


This sounds like something written in the days of GCC 4.8. I doubt it
has any relevance today.


It very much had until circa one month ago, as we observed early 
Synchronous Exceptions when trying to use the native Debian ARM64 
compiler, which we did not observe with Linaro's toolchain. We even had 
trouble (similar issue) with recent Linaro toolchains at some stage, 
which is why, until v3, we recommended an older version, but recent 
tests showed that the latest Linaro GCC (2019.02) appeared to be okay, 
which is why I removed the previous requirement to use exclusively 
Linaro's 2017.10 GCC 5.5.


Besides, I think it's preferable when a project highlights precisely how 
they build their own binaries, and with which toolchain, so that, if 
anybody experiences an issue with their own build, they can compare 
their setup with the maintainer's "official" one.



Also, and this applies both above and below: I am trying very hard to
get rid of (mostly unnecessary) platform-specific build instructions.
The top-level Readme.md in this repository contains basic build
instructions. I would much prefer if you can refer to that instead and
drop everything after the # Building header above...


Okay. This is a bit at odds with the goal I'm trying to achieve here, 
which is to save time and bewilderment from developers who might be 
trying to build this specific platform and encounter an issue where 
they'll want to eliminate the possibility that their setup/configuration 
is the problem.


I've ran in too many of "works on my machine" not top want to also 
provide "here is exactly how the official developer's machine was set up 
when they ran their built" from the get go, to try to alleviate the 
usual headaches of trying to solve environmental issues... Furthermore, 
given the popularity of the Raspberry Pi platform, my guess is that 
we're going to get quite a few people who aren't that familiar with the 
EDK2, or even building things, in general and who'll want a set of 
"copy/paste exactly this in your shell and you *should* end 

Re: [edk2] [RFC] Proposal to split Pkgs

2019-01-31 Thread Andrew Fish via edk2-devel



> On Jan 28, 2019, at 9:59 PM, Ni, Ray  wrote:
> 
> Hello,
> I'd like to propose to split today's BIG packages in following ways:
> 
> ==Overview =
> 
> 1. Separate Industry standard definitions from UEFI and PI interfaces.

Ray,

>From a big picture point of view lets talk about customer impact

Splitting the MdePkg means:
1) Every INF file needs a new  [Packages] layout, so has to change. 
2) Every DSC file needs to update [LibraryClasses] pathing.

Moving the drivers around:
1) Every DSC file has to change to update the path to the driver
2) Every FDF file has to change to update the path to the driver. 

I'd point out forcing every 3rd party module (library, driver, or application) 
to change is a much bigger impact that forcing a change to a projects target 
platform (DSC, FDF). 

I'm trying to figure out how to make a common code base that spans several 
generations of vendor code. So obviously today every module depends of MdePkg, 
and each new product is going to require new drivers for the chipset and 
peripherals. So lets say I'm a 3rd party graphics vendor does this mean I need 
and edk2 version of an INF and an edk3 version (no more MdePkg) of the INF as 
my customers are going to move at different rates? On the flip side how do I 
make a common platform tree if my vendor for work station chipsets lags behind 
my other chipset vendor in regards to moving to edk3. Does that mean I have to 
port that vendors code to edk3, which does not sound bad until you realize that 
every code drop from the vendor I need to remerge my edk3 changes back on top 
of it. Seems like a lot of work. 

Thus I think we need to ask the question do we need to leave the MdePkg around 
for compatibility? Do we need an INF syntax that supports edk2 and edk3 (Like 
the #ifdef we had that supported EDK and edk2 includes back in the day). We 
could have edk2 and edk3 INF files for very module?  Do we need to build a 
synthetic MdePkg that gets you the correct packages paths for the new include 
layout? I guess we could just make MdePkg an alias in the INF file for the 3 
(?) new packages? Or do we not change all the include paths?

Seems like we are creating our own Python 2.* vs. 3.* mess to make it easier to 
maintain the packages? I'm not saying it is wrong, but we should ask the 
question how is going to impact the edk2 consumers. 

Thanks,

Andrew Fish

> 2. Separate UEFI and PI interfaces from implementations.
>a. Separate UEFI and PI interfaces to different packages
>b. Separate PI PEI, DXE and MM phase interfaces to different packages
> 3. Separate different features into feature packages.
>Feature interface may be in the feature package to provide minimal
>common interface packages.
> 
> The POC code is in https://github.com/jyao1/edk2/tree/ReOrg.
> It basically split the EDKII common code to three directories:
> Core/, Device/, and Feature/.
> The code is in very early POC phase and only code in Core/ directory
> can pass the build.
> I would like to gather feedbacks through this RFC to see whether
> this splitting direction makes sense.
> Is there any other better ways of splitting?
> Or perhaps do not split in such a small granularity?
> Or perhaps Mike's work to move lib-c content to edk2-libc repo,
> to move real platform code to edk2-platform repo is enough for
> now?
> 
> ==More explanations =
> 
> There are 9 packages inside Core/ directory:
> 1. BasePkg
> Contains industry standard definitions (exclude UEFI and PI) and base
> libraries that non-UEFI and non-PI development can depend on.
> UEFI or PI development can also depend on this package.
> 2. UefiPkg
> Contains UEFI interfaces and libraries that UEFI driver-model driver
> development can depend on.
> 3. PiPeiPkg
> Contains PI interfaces and libraries for PEI phase that PEI module
> development can depend on.
> 4. PiDxePkg
> Contains PI interfaces and libraries for DXE phase that DXE module
> development can depend on.
> 5. PiMmPkg
> Contains PI interfaces and libraries for MM phase that MM/SMM
> module development can depend on.
> 6. MdeModulePkg (TianoPkg? Name is still TBD)
> Contains Tiano implementation specific interfaces and libraries.
> Developing modules for pure UEFI or PI should not depend on this package.
> 7. PeiFoundationPkg
> Contains the PEI foundation modules (PeiCore and DxeIpl) and supported
> libraries.
> 8. DxeFoundationPkg
> Contains the DXE foundation modules (DxeCore and RuntimeDxe) and
> supported libraries.
> 9. SmmFoundationPkg
> Contains the SMM foundation modules (SmmCore, SmmIpl and
> SmmCommunicationBuffer) and supported libraries.
> 
> These packages are positioned in different layers. The package in higher
> layer depends on all packages that are in lower layers.
> Layer 0: BasePkg.
> Layer 1: UefiPkg.
> Layer 2: PiPeiPkg 
> Layer 3: PiDxePkg
> Layer 4: PiMmPkg
> Layer 5: MdeModulePkg (TianoPkg?)
> 
> All other modules are put to 

[edk2] [PATCH v1 1/1] ShellPkg/UefiShellAcpiViewCommandLib: Fix PPTT cache attributes validation

2019-01-31 Thread Krzysztof Koch
Removed conditional pre-compiling for ARM CPUs because function
ValidateCacheAttributes(..) is based on ACPI PPTT specification.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Krzysztof Koch 
Reported-by: Zhichao Gao 
---

The code can be found at: 
https://github.com/KrzysztofKoch1/edk2/tree/woa_422_cache_valid_fix_v1

Notes:
v1:
- removed conditional precompilation[Krzysztof]

 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c
index 
bc56fe9ea1dd9c1e98a6a568d3f9191263bedc90..b6b420890a3494869020ed8bcc7b791fcf7d70f3
 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Pptt/PpttParser.c
@@ -86,11 +86,9 @@ ValidateCacheAttributes (
   IN VOID*  Context
   )
 {
-#if defined(MDE_CPU_ARM) || defined (MDE_CPU_AARCH64)
   // Reference: Advanced Configuration and Power Interface (ACPI) Specification
   //Version 6.2 Errata A, September 2017
   // Table 5-153: Cache Type Structure
-
   UINT8 Attributes;
   Attributes = *(UINT8*)Ptr;
 
@@ -102,7 +100,6 @@ ValidateCacheAttributes (
   );
 return;
   }
-#endif
 }
 
 /**
-- 
'Guid(CE165669-3EF3-493F-B85D-6190EE5B9759)'

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


Re: [edk2] [PATCH v4 edk2-platforms 00/23] Platform/Raspberry: Add Raspberry Pi 3 support

2019-01-31 Thread Pete Batard

On 2019.01.30 21:59, Leif Lindholm wrote:

Hi Pete,

I have two annoying pieces of feedback that apply to the whole set.

Firstly, I would really appreciate if we could have some sort of
commit messages rather than just subject lines.


I can work on that.


So, for ACPI, mention the provenance and limitations.
For SMBIOS, version supported and any relevant omissions or surprising
inclusions. And so on.

Secondly, we try to follow a //... pattern.
Could you possibly find it in your heart to do a global move and
search-and-replace of Platform/Raspberry to Platform/RaspberryPi?


Yes. I am realizing now that I thought it was called the "Raspberry 
Foundation", with the expectation that maybe in the future they might 
release a new platform called "Raspberry Jam" or something, hence my use 
of "Raspberry" for the organization. But it's correct denomination is 
really the "Raspberry Pi Foundation", so your remark does make sense.


And since it won't matter much to go one step further, I'll also apply 
the follow up remark to have:


Platform/RaspberryPi/RPi3/RPi3.dsc.


Best Regards,

Leif

On Tue, Jan 29, 2019 at 04:26:32PM +, Pete Batard wrote:

Changes applied to v4:

* Silicon/Broadcom/Include has been moved to Silicon/Broadcom/Bcm283x/Include.
   The [Packages] and [Includes] directives were also updated accordingly.
* Move the GpioLib function declarations into their own separate header.
* Add NOOPT to BUILD_TARGETS.
* Remove the no longer needed '-mcmodel=small' workaround from AcpiTables.

Changes not applied to v4:

* Ensure that all the ACPI tables _CID names, and the rest of the tables, are
   ACPI specs compliant, since we are constrained with regards to their usage
   for Microsoft Windows.


Preamble:

Because of its price point, ease of use and availability, the Raspberry Pi is
undeniably one of the most successful ARM platform in existence today. Its
widespread adoption therefore makes it a perfect fit as an EDK2 platform.

However, up until now, the Raspberry Pi hasn't been supported as a bona fide
platform in our repository. This series of patches remedies that by introducing
the Raspberry Pi 3 Model B and Model B+ as a viable EDK2 platform.

Notes regarding non-OSI content:

* Even though the ARM Trusted Firmware binary blobs are subject to a
   BSD-3-Clause licence, which may be compatible with the EDK2 one, we chose
   to follow the lead of other platforms that provide ATF binaries in non OSI.
   Ultimately, once there is a new dot release of ATF, we plan to remove these
   binaries and point to a dot release build configuartion.
* The Device Tree binaries (and source descriptors) are subject to a GPLv2
   license, as per the ones published by the Raspberry Pi Foundation.
* The Logo source code is under an EDK2 license, but the logo itself, which
   we obtained authorisation to use from the Raspberry Pi Foundation itself
   after detailing our planned usage, is subject to the trademark licensing
   terms put forward by the Foundation.

Additional Notes:

* Detailed instructions on how to build and test the platform firmware are
   included in the Readme.md found at the root of the platform.
* As detailed in the Readme, the resulting platform firmware has been
   successfully used to install and run Linux OSes, such as Ubuntu 18.10, as
   well as Windows 10 1809 (*full* UI version, not IoT).

Regards,

/Pete

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

  .../Raspberry/Pi3/AcpiTables/AcpiTables.h |   82 +
  .../Raspberry/Pi3/AcpiTables/AcpiTables.inf   |   46 +
  Platform/Raspberry/Pi3/AcpiTables/Csrt.aslc   |  332 +++
  Platform/Raspberry/Pi3/AcpiTables/Dbg2.aslc   |   34 +
  Platform/Raspberry/Pi3/AcpiTables/Dsdt.asl|  511 +
  Platform/Raspberry/Pi3/AcpiTables/Fadt.aslc   |   52 +
  Platform/Raspberry/Pi3/AcpiTables/Gtdt.aslc   |   33 +
  

Re: [edk2] [PATCH v4 edk2-platforms 20/23] Platform/Raspberry/Pi3: Add platform readme

2019-01-31 Thread Ard Biesheuvel
On Thu, 31 Jan 2019 at 15:13, Leif Lindholm  wrote:
>
> On Thu, Jan 31, 2019 at 12:30:22PM +, Pete Batard wrote:
> > Hi Leif. Thanks for reviewing this patchset.
> >
> > On 2019.01.30 21:50, Leif Lindholm wrote:
> > > Hi Pete,
> > >
> > > I will only have minor comments on this set, but I'll start with this
> > > documentation.
> > >
> > > On Tue, Jan 29, 2019 at 04:26:52PM +, Pete Batard wrote:
> > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > Signed-off-by: Pete Batard 
> > > > ---
> > > >   Platform/Raspberry/Pi3/Readme.md | 259 
> > > >   Readme.md|   3 +
> > > >   2 files changed, 262 insertions(+)
> > > >
> > > > diff --git a/Platform/Raspberry/Pi3/Readme.md 
> > > > b/Platform/Raspberry/Pi3/Readme.md
> > > > new file mode 100644
> > > > index ..7fb59ccdc321
> > > > --- /dev/null
> > > > +++ b/Platform/Raspberry/Pi3/Readme.md
> > > > @@ -0,0 +1,259 @@
> > > > +Raspberry Pi 3 EDK2 Platform Support
> > > > +
> > > > +
> > > > +# Summary
> > > > +
> > > > +This is a port of 64-bit Tiano Core UEFI firmware for the Raspberry Pi 
> > > > 3/3B+ platforms,
> > > > +based on [Ard Bisheuvel's 
> > > > 64-bit](http://www.workofard.com/2017/02/uefi-on-the-pi/)
> > > > +and [Microsoft's 
> > > > 32-bit](https://github.com/ms-iot/RPi-UEFI/tree/ms-iot/Pi3BoardPkg)
> > > > +implementations, as maintained by [Andrei 
> > > > Warkentin](https://github.com/andreiw/RaspberryPiPkg).
> > > > +
> > > > +This is meant as a generally useful 64-bit ATF + UEFI implementation 
> > > > for the Raspberry
> > > > +Pi 3/3B+ which should be good enough for most kind of UEFI 
> > > > development, as well as for
> > > > +running consummer Operating Systems in such as Linux or Windows.
> > > > +
> > > > +Raspberry Pi is a trademark of the [Raspberry Pi 
> > > > Foundation](http://www.raspberrypi.org).
> > > > +
> > > > +# Status
> > > > +
> > > > +This firmware, that has been validated to compile against the current
> > > > +[edk2](https://github.com/tianocore/edk2)/[edk2-platforms](https://github.com/tianocore/edk2-platforms),
> > > > +should be able to boot Linux (SUSE, Ubuntu), NetBSD, FreeBSD as well 
> > > > as Windows 10 ARM64
> > > > +(full GUI version).
> > > > +
> > > > +It also provides support for ATF ([Arm Trusted 
> > > > Platform](https://github.com/ARM-software/arm-trusted-firmware)).
> > > > +
> > > > +HDMI and the mini-UART serial port can be used for output devices, 
> > > > with mirrored output.
> > > > +USB keyboards and the mini-UART serial port can be used as input.
> > > > +
> > > > +The boot order is currently hardcoded, first to the USB ports and then 
> > > > to the uSD card.
> > > > +If there no bootable media media is found, the UEFI Shell is launched.
> > > > +Esc enters platform setup. F1 boots the UEFI 
> > > > Shell.
> > > > +
> > > > +# Building
> > > > +
> > > > +(These instructions were validated against the latest edk2 / 
> > > > edk2-platforms /
> > > > +edk2-non-osi as of 2019.01.27, on a Debian 9.6 x64 system).
> > > > +
> > > > +You may need to install the relevant compilation tools. Especially you 
> > > > should have the
> > > > +ACPI Source Language (ASL) compiler, `nasm` as well as a native 
> > > > compiler installed.
> > >
> > > nasm? The x86 assembler?
> >
> > I'll remove that.
> >
> > > > +On a Debian system, you can get these prerequisites installed with:
> > > > +```
> > > > +sudo apt-get install build-essential acpica-tools nasm uuid-dev
> > > > +```
> > > > +
> > > > +**IMPORTANT:** We recommend the use of the Linaro GCC for compilation 
> > > > instead of
> > > > +your system's native ARM64 GCC cross compiler.
> > >
> > > This sounds like something written in the days of GCC 4.8. I doubt it
> > > has any relevance today.
> >
> > It very much had until circa one month ago, as we observed early Synchronous
> > Exceptions when trying to use the native Debian ARM64 compiler, which we did
> > not observe with Linaro's toolchain. We even had trouble (similar issue)
> > with recent Linaro toolchains at some stage, which is why, until v3, we
> > recommended an older version, but recent tests showed that the latest Linaro
> > GCC (2019.02) appeared to be okay, which is why I removed the previous
> > requirement to use exclusively Linaro's 2017.10 GCC 5.5.
>
> Urgh. But that actually makes the above statement even more
> misleading. What you have isn't an issue with non-Linaro toolchains,
> you have an unidentified toolchain issue that you've triggered more
> frequently
>

Could you please check whether the broken toolchain in question has
the workaround for Cortex-A53 erratum 843419 enabled? (gcc -v will
tell you)

While playing with this port the other day, I noticed that the RPi3 is
affected by this, and the Debian kernels don't enable mitigations for
it either.

> I mean, it's not like the
> (Also, Linaro no longer releases GCC toolchains - if you try to grab a
> GCC8 

Re: [edk2] [PATCH v4 edk2-platforms 20/23] Platform/Raspberry/Pi3: Add platform readme

2019-01-31 Thread Ard Biesheuvel
On Thu, 31 Jan 2019 at 15:36, Ard Biesheuvel  wrote:
>
> On Thu, 31 Jan 2019 at 15:13, Leif Lindholm  wrote:
> >
> > On Thu, Jan 31, 2019 at 12:30:22PM +, Pete Batard wrote:
> > > Hi Leif. Thanks for reviewing this patchset.
> > >
> > > On 2019.01.30 21:50, Leif Lindholm wrote:
> > > > Hi Pete,
> > > >
> > > > I will only have minor comments on this set, but I'll start with this
> > > > documentation.
> > > >
> > > > On Tue, Jan 29, 2019 at 04:26:52PM +, Pete Batard wrote:
> > > > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > > > Signed-off-by: Pete Batard 
> > > > > ---
> > > > >   Platform/Raspberry/Pi3/Readme.md | 259 
> > > > >   Readme.md|   3 +
> > > > >   2 files changed, 262 insertions(+)
> > > > >
> > > > > diff --git a/Platform/Raspberry/Pi3/Readme.md 
> > > > > b/Platform/Raspberry/Pi3/Readme.md
> > > > > new file mode 100644
> > > > > index ..7fb59ccdc321
> > > > > --- /dev/null
> > > > > +++ b/Platform/Raspberry/Pi3/Readme.md
> > > > > @@ -0,0 +1,259 @@
> > > > > +Raspberry Pi 3 EDK2 Platform Support
> > > > > +
> > > > > +
> > > > > +# Summary
> > > > > +
> > > > > +This is a port of 64-bit Tiano Core UEFI firmware for the Raspberry 
> > > > > Pi 3/3B+ platforms,
> > > > > +based on [Ard Bisheuvel's 
> > > > > 64-bit](http://www.workofard.com/2017/02/uefi-on-the-pi/)
> > > > > +and [Microsoft's 
> > > > > 32-bit](https://github.com/ms-iot/RPi-UEFI/tree/ms-iot/Pi3BoardPkg)
> > > > > +implementations, as maintained by [Andrei 
> > > > > Warkentin](https://github.com/andreiw/RaspberryPiPkg).
> > > > > +
> > > > > +This is meant as a generally useful 64-bit ATF + UEFI implementation 
> > > > > for the Raspberry
> > > > > +Pi 3/3B+ which should be good enough for most kind of UEFI 
> > > > > development, as well as for
> > > > > +running consummer Operating Systems in such as Linux or Windows.
> > > > > +
> > > > > +Raspberry Pi is a trademark of the [Raspberry Pi 
> > > > > Foundation](http://www.raspberrypi.org).
> > > > > +
> > > > > +# Status
> > > > > +
> > > > > +This firmware, that has been validated to compile against the current
> > > > > +[edk2](https://github.com/tianocore/edk2)/[edk2-platforms](https://github.com/tianocore/edk2-platforms),
> > > > > +should be able to boot Linux (SUSE, Ubuntu), NetBSD, FreeBSD as well 
> > > > > as Windows 10 ARM64
> > > > > +(full GUI version).
> > > > > +
> > > > > +It also provides support for ATF ([Arm Trusted 
> > > > > Platform](https://github.com/ARM-software/arm-trusted-firmware)).
> > > > > +
> > > > > +HDMI and the mini-UART serial port can be used for output devices, 
> > > > > with mirrored output.
> > > > > +USB keyboards and the mini-UART serial port can be used as input.
> > > > > +
> > > > > +The boot order is currently hardcoded, first to the USB ports and 
> > > > > then to the uSD card.
> > > > > +If there no bootable media media is found, the UEFI Shell is 
> > > > > launched.
> > > > > +Esc enters platform setup. F1 boots the UEFI 
> > > > > Shell.
> > > > > +
> > > > > +# Building
> > > > > +
> > > > > +(These instructions were validated against the latest edk2 / 
> > > > > edk2-platforms /
> > > > > +edk2-non-osi as of 2019.01.27, on a Debian 9.6 x64 system).
> > > > > +
> > > > > +You may need to install the relevant compilation tools. Especially 
> > > > > you should have the
> > > > > +ACPI Source Language (ASL) compiler, `nasm` as well as a native 
> > > > > compiler installed.
> > > >
> > > > nasm? The x86 assembler?
> > >
> > > I'll remove that.
> > >
> > > > > +On a Debian system, you can get these prerequisites installed with:
> > > > > +```
> > > > > +sudo apt-get install build-essential acpica-tools nasm uuid-dev
> > > > > +```
> > > > > +
> > > > > +**IMPORTANT:** We recommend the use of the Linaro GCC for 
> > > > > compilation instead of
> > > > > +your system's native ARM64 GCC cross compiler.
> > > >
> > > > This sounds like something written in the days of GCC 4.8. I doubt it
> > > > has any relevance today.
> > >
> > > It very much had until circa one month ago, as we observed early 
> > > Synchronous
> > > Exceptions when trying to use the native Debian ARM64 compiler, which we 
> > > did
> > > not observe with Linaro's toolchain. We even had trouble (similar issue)
> > > with recent Linaro toolchains at some stage, which is why, until v3, we
> > > recommended an older version, but recent tests showed that the latest 
> > > Linaro
> > > GCC (2019.02) appeared to be okay, which is why I removed the previous
> > > requirement to use exclusively Linaro's 2017.10 GCC 5.5.
> >
> > Urgh. But that actually makes the above statement even more
> > misleading. What you have isn't an issue with non-Linaro toolchains,
> > you have an unidentified toolchain issue that you've triggered more
> > frequently
> >
>
> Could you please check whether the broken toolchain in question has
> the workaround for 

Re: [edk2] [PATCH edk2-platforms] Silicon/Bcm2836: add random number generator driver

2019-01-31 Thread Leif Lindholm
On Wed, Jan 30, 2019 at 08:39:43PM +0100, Ard Biesheuvel wrote:
> Expose the SoC's RNG peripheral via the EFI_RNG_PROTOCOL.
> This is used by Linux to seed the KASLR routines.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 

Not tested, but looks fine. Only question: could we add those few
#defines to IndustryStandard/Bcm2836.h (should that really be
#IndustryStandard, btw?) rather than creating a tiny standalone one?
(more below)

> ---
>  Silicon/Broadcom/Bcm283x/Drivers/RngDxe/RngDxe.c   | 204 
> 
>  Silicon/Broadcom/Bcm283x/Drivers/RngDxe/RngDxe.inf |  45 +
>  Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h |  26 +++
>  3 files changed, 275 insertions(+)
> 

> diff --git a/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h 
> b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h
> new file mode 100644
> index ..8274e2fe8f77
> --- /dev/null
> +++ b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h
> @@ -0,0 +1,26 @@
> + /** @file
> + *
> + *  Copyright (c) 2019 Linaro, Ltd. All rights reserved.
> + *
> + *  This program and the accompanying materials
> + *  are licensed and made available under the terms and conditions of the 
> BSD License
> + *  which accompanies this distribution.  The full text of the license may 
> be found at
> + *  http://opensource.org/licenses/bsd-license.php
> + *
> + *  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> + *  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> + *
> + **/
> +
> +#ifndef __BCM2836_RNG_H__
> +#define __BCM2836_RNG_H__
> +
> +#define RNG_BASE_ADDRESS   (BCM2836_SOC_REGISTERS + 0x00104000)

If we can't, this file needs to pull in Bcm2836.h anyway.

/
Leif

> +
> +#define RNG_CTRL   (RNG_BASE_ADDRESS + 0x0)
> +#define RNG_STATUS (RNG_BASE_ADDRESS + 0x4)
> +#define RNG_DATA   (RNG_BASE_ADDRESS + 0x8)
> +
> +#define RNG_CTRL_ENABLE0x1
> +
> +#endif /* __BCM2836_RNG_H__ */
> -- 
> 2.20.1
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel


Re: [edk2] [PATCH v4 edk2-platforms 20/23] Platform/Raspberry/Pi3: Add platform readme

2019-01-31 Thread Leif Lindholm
On Thu, Jan 31, 2019 at 12:30:22PM +, Pete Batard wrote:
> Hi Leif. Thanks for reviewing this patchset.
> 
> On 2019.01.30 21:50, Leif Lindholm wrote:
> > Hi Pete,
> > 
> > I will only have minor comments on this set, but I'll start with this
> > documentation.
> > 
> > On Tue, Jan 29, 2019 at 04:26:52PM +, Pete Batard wrote:
> > > Contributed-under: TianoCore Contribution Agreement 1.1
> > > Signed-off-by: Pete Batard 
> > > ---
> > >   Platform/Raspberry/Pi3/Readme.md | 259 
> > >   Readme.md|   3 +
> > >   2 files changed, 262 insertions(+)
> > > 
> > > diff --git a/Platform/Raspberry/Pi3/Readme.md 
> > > b/Platform/Raspberry/Pi3/Readme.md
> > > new file mode 100644
> > > index ..7fb59ccdc321
> > > --- /dev/null
> > > +++ b/Platform/Raspberry/Pi3/Readme.md
> > > @@ -0,0 +1,259 @@
> > > +Raspberry Pi 3 EDK2 Platform Support
> > > +
> > > +
> > > +# Summary
> > > +
> > > +This is a port of 64-bit Tiano Core UEFI firmware for the Raspberry Pi 
> > > 3/3B+ platforms,
> > > +based on [Ard Bisheuvel's 
> > > 64-bit](http://www.workofard.com/2017/02/uefi-on-the-pi/)
> > > +and [Microsoft's 
> > > 32-bit](https://github.com/ms-iot/RPi-UEFI/tree/ms-iot/Pi3BoardPkg)
> > > +implementations, as maintained by [Andrei 
> > > Warkentin](https://github.com/andreiw/RaspberryPiPkg).
> > > +
> > > +This is meant as a generally useful 64-bit ATF + UEFI implementation for 
> > > the Raspberry
> > > +Pi 3/3B+ which should be good enough for most kind of UEFI development, 
> > > as well as for
> > > +running consummer Operating Systems in such as Linux or Windows.
> > > +
> > > +Raspberry Pi is a trademark of the [Raspberry Pi 
> > > Foundation](http://www.raspberrypi.org).
> > > +
> > > +# Status
> > > +
> > > +This firmware, that has been validated to compile against the current
> > > +[edk2](https://github.com/tianocore/edk2)/[edk2-platforms](https://github.com/tianocore/edk2-platforms),
> > > +should be able to boot Linux (SUSE, Ubuntu), NetBSD, FreeBSD as well as 
> > > Windows 10 ARM64
> > > +(full GUI version).
> > > +
> > > +It also provides support for ATF ([Arm Trusted 
> > > Platform](https://github.com/ARM-software/arm-trusted-firmware)).
> > > +
> > > +HDMI and the mini-UART serial port can be used for output devices, with 
> > > mirrored output.
> > > +USB keyboards and the mini-UART serial port can be used as input.
> > > +
> > > +The boot order is currently hardcoded, first to the USB ports and then 
> > > to the uSD card.
> > > +If there no bootable media media is found, the UEFI Shell is launched.
> > > +Esc enters platform setup. F1 boots the UEFI Shell.
> > > +
> > > +# Building
> > > +
> > > +(These instructions were validated against the latest edk2 / 
> > > edk2-platforms /
> > > +edk2-non-osi as of 2019.01.27, on a Debian 9.6 x64 system).
> > > +
> > > +You may need to install the relevant compilation tools. Especially you 
> > > should have the
> > > +ACPI Source Language (ASL) compiler, `nasm` as well as a native compiler 
> > > installed.
> > 
> > nasm? The x86 assembler?
> 
> I'll remove that.
> 
> > > +On a Debian system, you can get these prerequisites installed with:
> > > +```
> > > +sudo apt-get install build-essential acpica-tools nasm uuid-dev
> > > +```
> > > +
> > > +**IMPORTANT:** We recommend the use of the Linaro GCC for compilation 
> > > instead of
> > > +your system's native ARM64 GCC cross compiler.
> > 
> > This sounds like something written in the days of GCC 4.8. I doubt it
> > has any relevance today.
> 
> It very much had until circa one month ago, as we observed early Synchronous
> Exceptions when trying to use the native Debian ARM64 compiler, which we did
> not observe with Linaro's toolchain. We even had trouble (similar issue)
> with recent Linaro toolchains at some stage, which is why, until v3, we
> recommended an older version, but recent tests showed that the latest Linaro
> GCC (2019.02) appeared to be okay, which is why I removed the previous
> requirement to use exclusively Linaro's 2017.10 GCC 5.5.

Urgh. But that actually makes the above statement even more
misleading. What you have isn't an issue with non-Linaro toolchains,
you have an unidentified toolchain issue that you've triggered more
frequently

I mean, it's not like the
(Also, Linaro no longer releases GCC toolchains - if you try to grab a
GCC8 toolchain from releases.linaro.org, you get redirected to
https://developer.arm.com/open-source/gnu-toolchain/gnu-a/downloads.)

> Besides, I think it's preferable when a project highlights precisely how
> they build their own binaries, and with which toolchain, so that, if anybody
> experiences an issue with their own build, they can compare their setup with
> the maintainer's "official" one.

Given what you say below, I think we actually understand each other
quite well So let's try to find a compromise we're both OK with.

My bottom line is that what I want in 

[edk2] [edk2-announce] February Community Meeting

2019-01-31 Thread stephano
We will be holding our February Community Meeting on the *2nd* Thursday 
of February to accommodate holiday schedules. Details are posted here:


https://www.tianocore.org/community-meeting/

Please contact me or post to the list anything you'd like to see discussed.

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


Re: [edk2] [PATCH edk2-platforms] Silicon/Bcm2836: add random number generator driver

2019-01-31 Thread Ard Biesheuvel
On Thu, 31 Jan 2019 at 16:05, Leif Lindholm  wrote:
>
> On Wed, Jan 30, 2019 at 08:39:43PM +0100, Ard Biesheuvel wrote:
> > Expose the SoC's RNG peripheral via the EFI_RNG_PROTOCOL.
> > This is used by Linux to seed the KASLR routines.
> >
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Ard Biesheuvel 
>
> Not tested, but looks fine. Only question: could we add those few
> #defines to IndustryStandard/Bcm2836.h (should that really be
> #IndustryStandard, btw?) rather than creating a tiny standalone one?
> (more below)
>

Sure.

Re IndustryStandard/, I deliberately chose something idiomatic for
EDK2, and this is the least inappropriate one. I could live with
Chipset/ as well, but dumping headers under Include/ directly is not
the solution IMO.

> > ---
> >  Silicon/Broadcom/Bcm283x/Drivers/RngDxe/RngDxe.c   | 204 
> > 
> >  Silicon/Broadcom/Bcm283x/Drivers/RngDxe/RngDxe.inf |  45 +
> >  Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h |  26 +++
> >  3 files changed, 275 insertions(+)
> >
>
> > diff --git a/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h 
> > b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h
> > new file mode 100644
> > index ..8274e2fe8f77
> > --- /dev/null
> > +++ b/Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836Rng.h
> > @@ -0,0 +1,26 @@
> > + /** @file
> > + *
> > + *  Copyright (c) 2019 Linaro, Ltd. All rights reserved.
> > + *
> > + *  This program and the accompanying materials
> > + *  are licensed and made available under the terms and conditions of the 
> > BSD License
> > + *  which accompanies this distribution.  The full text of the license may 
> > be found at
> > + *  http://opensource.org/licenses/bsd-license.php
> > + *
> > + *  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> > + *  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> > IMPLIED.
> > + *
> > + **/
> > +
> > +#ifndef __BCM2836_RNG_H__
> > +#define __BCM2836_RNG_H__
> > +
> > +#define RNG_BASE_ADDRESS   (BCM2836_SOC_REGISTERS + 0x00104000)
>
> If we can't, this file needs to pull in Bcm2836.h anyway.
>

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


Re: [edk2] [PATCH v4 edk2-platforms 01/23] Silicon/Broadcom/Bcm282x: Add interrupt driver

2019-01-31 Thread Leif Lindholm
On Tue, Jan 29, 2019 at 04:26:33PM +, Pete Batard wrote:
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Pete Batard 
> 
> Reviewed-by: Ard Biesheuvel 
> ---
>  Silicon/Broadcom/Bcm283x/Bcm283x.dec   |  23 ++
>  Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c   | 367 
> 
>  Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.inf |  48 +++
>  Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h|  72 

Another generic comment: "IndustryStandard" is something like ACPI,
SMBIOS, PCI, USB, MMC, ... (also including SoC/platform-specific
additions to the same).

I would be more comfortable with SoC-specific and Platform-specific
include files living directly in Include/.

/
Leif

>  4 files changed, 510 insertions(+)
> 
> diff --git a/Silicon/Broadcom/Bcm283x/Bcm283x.dec 
> b/Silicon/Broadcom/Bcm283x/Bcm283x.dec
> new file mode 100644
> index ..d193da4c0e1e
> --- /dev/null
> +++ b/Silicon/Broadcom/Bcm283x/Bcm283x.dec
> @@ -0,0 +1,23 @@
> +## @file
> +#
> +#  Copyright (c) 2019, Pete Batard 
> +#
> +#  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.
> +#
> +##
> +
> +[Defines]
> +  DEC_SPECIFICATION  = 0x0001001A
> +  PACKAGE_NAME   = Bcm283xPkg
> +  PACKAGE_GUID   = 900C0F44-1152-4FF9-B9C5-933E2918C831
> +  PACKAGE_VERSION= 1.0
> +
> +[Includes]
> +  Include
> diff --git a/Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c 
> b/Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c
> new file mode 100644
> index ..9058aa94ffb9
> --- /dev/null
> +++ b/Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c
> @@ -0,0 +1,367 @@
> +/** @file
> + *
> + *  Copyright (c) 2016, Linaro, Ltd. All rights reserved.
> + *
> + *  This program and the accompanying materials
> + *  are licensed and made available under the terms and conditions of the 
> BSD License
> + *  which accompanies this distribution.  The full text of the license may 
> be found at
> + *  http://opensource.org/licenses/bsd-license.php
> + *
> + *  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> + *  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> IMPLIED.
> + *
> + **/
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +
> +//
> +// This currently only implements support for the architected timer 
> interrupts
> +// on the per-CPU interrupt controllers.
> +//
> +#define NUM_IRQS(4)
> +
> +#ifdef MDE_CPU_AARCH64
> +#define ARM_ARCH_EXCEPTION_IRQ  EXCEPT_AARCH64_IRQ
> +#else
> +#define ARM_ARCH_EXCEPTION_IRQ  EXCEPT_ARM_IRQ
> +#endif
> +
> +STATIC CONST
> +EFI_PHYSICAL_ADDRESS RegBase = FixedPcdGet32 (PcdInterruptBaseAddress);
> +
> +//
> +// Notifications
> +//
> +STATIC EFI_EVENTmExitBootServicesEvent;
> +STATIC HARDWARE_INTERRUPT_HANDLER   mRegisteredInterruptHandlers[NUM_IRQS];
> +
> +/**
> +  Shutdown our hardware
> +
> +  DXE Core will disable interrupts and turn off the timer and disable 
> interrupts
> +  after all the event handlers have run.
> +
> +  @param[in]  Event   The Event that is being processed
> +  @param[in]  Context Event Context
> +**/
> +STATIC
> +VOID
> +EFIAPI
> +ExitBootServicesEvent (
> +  IN EFI_EVENT  Event,
> +  IN VOID   *Context
> +  )
> +{
> +  // Disable all interrupts
> +  MmioWrite32 (RegBase + BCM2836_INTC_TIMER_CONTROL_OFFSET, 0);
> +}
> +
> +/**
> +  Enable interrupt source Source.
> +
> +  @param This Instance pointer for this protocol
> +  @param Source   Hardware source of the interrupt
> +
> +  @retval EFI_SUCCESS   Source interrupt enabled.
> +  @retval EFI_DEVICE_ERROR  Hardware could not be programmed.
> +
> +**/
> +STATIC
> +EFI_STATUS
> +EFIAPI
> +EnableInterruptSource (
> +  IN EFI_HARDWARE_INTERRUPT_PROTOCOL*This,
> +  IN HARDWARE_INTERRUPT_SOURCE  Source
> +  )
> +{
> +  if (Source >= NUM_IRQS) {
> +ASSERT (FALSE);
> +return EFI_UNSUPPORTED;
> +  }
> +
> +  MmioOr32 (RegBase + BCM2836_INTC_TIMER_CONTROL_OFFSET, 1 << Source);
> +
> +  return EFI_SUCCESS;
> +}
> +
> +
> +/**
> +  Disable interrupt source Source.
> +
> +  @param This Instance pointer for this protocol
> +  @param Source   Hardware source of the interrupt
> +
> +  @retval EFI_SUCCESS   Source interrupt disabled.
> +  @retval EFI_DEVICE_ERROR  Hardware could not be programmed.
> +
> +**/
> +STATIC
> +EFI_STATUS
> +EFIAPI

Re: [edk2] Conditional Compilation support in INF file

2019-01-31 Thread stephano

On 1/30/2019 10:56 PM, Gao, Liming wrote:

Karunakar:
   There is one BZ https://bugzilla.tianocore.org/show_bug.cgi?id=1446 on 
Feature Flag expression in INF. INF spec has listed the syntax for it. But, 
BaseTools doesn't support it now. If you have the similar request, please add 
the information in BZ (including the usage model and expected edk2 release). 
And, stephano are working on Public Design and Bug Scrub Meetings. Then, we can 
talk the fix plan in public bug scrub meeting.



Design and Community Bug Triage meetings are indeed in the works.

I should have notifications out to the mailing list soon. I am traveling 
to FOSDEM today, so I should have an email out by the weekend.


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


Re: [edk2] [PATCH v4 edk2-platforms 01/23] Silicon/Broadcom/Bcm282x: Add interrupt driver

2019-01-31 Thread Ard Biesheuvel
On Thu, 31 Jan 2019 at 16:24, Leif Lindholm  wrote:
>
> On Tue, Jan 29, 2019 at 04:26:33PM +, Pete Batard wrote:
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Pete Batard 
> >
> > Reviewed-by: Ard Biesheuvel 
> > ---
> >  Silicon/Broadcom/Bcm283x/Bcm283x.dec   |  23 ++
> >  Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c   | 367 
> > 
> >  Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.inf |  48 +++
> >  Silicon/Broadcom/Bcm283x/Include/IndustryStandard/Bcm2836.h|  72 
>
> Another generic comment: "IndustryStandard" is something like ACPI,
> SMBIOS, PCI, USB, MMC, ... (also including SoC/platform-specific
> additions to the same).
>

Is that your interpretation? Or is this documented somewhere?

I could live with Chipset/, and I'm open to other suggestions, but the
Library vs Protocol vs IndustryStandard distinction is very useful
imo.


> I would be more comfortable with SoC-specific and Platform-specific
> include files living directly in Include/.
>


No, don't drop headers in Include/ please. The namespacing is one of
the things EDK2 actually gets right (assuming you define the paths
correctly in the package .dec file), and I'd hate to start dumping
headers at the root level because we cannot make up our minds what to
call the enclosing folder.

> >  4 files changed, 510 insertions(+)
> >
> > diff --git a/Silicon/Broadcom/Bcm283x/Bcm283x.dec 
> > b/Silicon/Broadcom/Bcm283x/Bcm283x.dec
> > new file mode 100644
> > index ..d193da4c0e1e
> > --- /dev/null
> > +++ b/Silicon/Broadcom/Bcm283x/Bcm283x.dec
> > @@ -0,0 +1,23 @@
> > +## @file
> > +#
> > +#  Copyright (c) 2019, Pete Batard 
> > +#
> > +#  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.
> > +#
> > +##
> > +
> > +[Defines]
> > +  DEC_SPECIFICATION  = 0x0001001A
> > +  PACKAGE_NAME   = Bcm283xPkg
> > +  PACKAGE_GUID   = 900C0F44-1152-4FF9-B9C5-933E2918C831
> > +  PACKAGE_VERSION= 1.0
> > +
> > +[Includes]
> > +  Include
> > diff --git a/Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c 
> > b/Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c
> > new file mode 100644
> > index ..9058aa94ffb9
> > --- /dev/null
> > +++ b/Silicon/Broadcom/Bcm283x/Drivers/InterruptDxe/InterruptDxe.c
> > @@ -0,0 +1,367 @@
> > +/** @file
> > + *
> > + *  Copyright (c) 2016, Linaro, Ltd. All rights reserved.
> > + *
> > + *  This program and the accompanying materials
> > + *  are licensed and made available under the terms and conditions of the 
> > BSD License
> > + *  which accompanies this distribution.  The full text of the license may 
> > be found at
> > + *  http://opensource.org/licenses/bsd-license.php
> > + *
> > + *  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
> > + *  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR 
> > IMPLIED.
> > + *
> > + **/
> > +
> > +#include 
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#include 
> > +
> > +#include 
> > +#include 
> > +
> > +//
> > +// This currently only implements support for the architected timer 
> > interrupts
> > +// on the per-CPU interrupt controllers.
> > +//
> > +#define NUM_IRQS(4)
> > +
> > +#ifdef MDE_CPU_AARCH64
> > +#define ARM_ARCH_EXCEPTION_IRQ  EXCEPT_AARCH64_IRQ
> > +#else
> > +#define ARM_ARCH_EXCEPTION_IRQ  EXCEPT_ARM_IRQ
> > +#endif
> > +
> > +STATIC CONST
> > +EFI_PHYSICAL_ADDRESS RegBase = FixedPcdGet32 (PcdInterruptBaseAddress);
> > +
> > +//
> > +// Notifications
> > +//
> > +STATIC EFI_EVENTmExitBootServicesEvent;
> > +STATIC HARDWARE_INTERRUPT_HANDLER   mRegisteredInterruptHandlers[NUM_IRQS];
> > +
> > +/**
> > +  Shutdown our hardware
> > +
> > +  DXE Core will disable interrupts and turn off the timer and disable 
> > interrupts
> > +  after all the event handlers have run.
> > +
> > +  @param[in]  Event   The Event that is being processed
> > +  @param[in]  Context Event Context
> > +**/
> > +STATIC
> > +VOID
> > +EFIAPI
> > +ExitBootServicesEvent (
> > +  IN EFI_EVENT  Event,
> > +  IN VOID   *Context
> > +  )
> > +{
> > +  // Disable all interrupts
> > +  MmioWrite32 (RegBase + BCM2836_INTC_TIMER_CONTROL_OFFSET, 0);
> > +}
> > +
> > +/**
> > +  Enable interrupt source Source.
> > +
> > +  @param This Instance pointer for this protocol
> > +  @param Source   Hardware source of the interrupt
> > +
> > +  @retval 

Re: [edk2] [PATCH v4 edk2-platforms 20/23] Platform/Raspberry/Pi3: Add platform readme

2019-01-31 Thread Pete Batard

On 2019.01.31 14:44, Ard Biesheuvel wrote:

On Thu, 31 Jan 2019 at 15:36, Ard Biesheuvel  wrote:


On Thu, 31 Jan 2019 at 15:13, Leif Lindholm  wrote:


On Thu, Jan 31, 2019 at 12:30:22PM +, Pete Batard wrote:

Hi Leif. Thanks for reviewing this patchset.

On 2019.01.30 21:50, Leif Lindholm wrote:

Hi Pete,

I will only have minor comments on this set, but I'll start with this
documentation.

On Tue, Jan 29, 2019 at 04:26:52PM +, Pete Batard wrote:

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Pete Batard 
---
   Platform/Raspberry/Pi3/Readme.md | 259 
   Readme.md|   3 +
   2 files changed, 262 insertions(+)

diff --git a/Platform/Raspberry/Pi3/Readme.md b/Platform/Raspberry/Pi3/Readme.md
new file mode 100644
index ..7fb59ccdc321
--- /dev/null
+++ b/Platform/Raspberry/Pi3/Readme.md
@@ -0,0 +1,259 @@
+Raspberry Pi 3 EDK2 Platform Support
+
+
+# Summary
+
+This is a port of 64-bit Tiano Core UEFI firmware for the Raspberry Pi 3/3B+ 
platforms,
+based on [Ard Bisheuvel's 
64-bit](http://www.workofard.com/2017/02/uefi-on-the-pi/)
+and [Microsoft's 
32-bit](https://github.com/ms-iot/RPi-UEFI/tree/ms-iot/Pi3BoardPkg)
+implementations, as maintained by [Andrei 
Warkentin](https://github.com/andreiw/RaspberryPiPkg).
+
+This is meant as a generally useful 64-bit ATF + UEFI implementation for the 
Raspberry
+Pi 3/3B+ which should be good enough for most kind of UEFI development, as 
well as for
+running consummer Operating Systems in such as Linux or Windows.
+
+Raspberry Pi is a trademark of the [Raspberry Pi 
Foundation](http://www.raspberrypi.org).
+
+# Status
+
+This firmware, that has been validated to compile against the current
+[edk2](https://github.com/tianocore/edk2)/[edk2-platforms](https://github.com/tianocore/edk2-platforms),
+should be able to boot Linux (SUSE, Ubuntu), NetBSD, FreeBSD as well as 
Windows 10 ARM64
+(full GUI version).
+
+It also provides support for ATF ([Arm Trusted 
Platform](https://github.com/ARM-software/arm-trusted-firmware)).
+
+HDMI and the mini-UART serial port can be used for output devices, with 
mirrored output.
+USB keyboards and the mini-UART serial port can be used as input.
+
+The boot order is currently hardcoded, first to the USB ports and then to the 
uSD card.
+If there no bootable media media is found, the UEFI Shell is launched.
+Esc enters platform setup. F1 boots the UEFI Shell.
+
+# Building
+
+(These instructions were validated against the latest edk2 / edk2-platforms /
+edk2-non-osi as of 2019.01.27, on a Debian 9.6 x64 system).
+
+You may need to install the relevant compilation tools. Especially you should 
have the
+ACPI Source Language (ASL) compiler, `nasm` as well as a native compiler 
installed.


nasm? The x86 assembler?


I'll remove that.


+On a Debian system, you can get these prerequisites installed with:
+```
+sudo apt-get install build-essential acpica-tools nasm uuid-dev
+```
+
+**IMPORTANT:** We recommend the use of the Linaro GCC for compilation instead 
of
+your system's native ARM64 GCC cross compiler.


This sounds like something written in the days of GCC 4.8. I doubt it
has any relevance today.


It very much had until circa one month ago, as we observed early Synchronous
Exceptions when trying to use the native Debian ARM64 compiler, which we did
not observe with Linaro's toolchain. We even had trouble (similar issue)
with recent Linaro toolchains at some stage, which is why, until v3, we
recommended an older version, but recent tests showed that the latest Linaro
GCC (2019.02) appeared to be okay, which is why I removed the previous
requirement to use exclusively Linaro's 2017.10 GCC 5.5.


Urgh. But that actually makes the above statement even more
misleading. What you have isn't an issue with non-Linaro toolchains,
you have an unidentified toolchain issue that you've triggered more
frequently



Could you please check whether the broken toolchain in question has
the workaround for Cortex-A53 erratum 843419 enabled? (gcc -v will
tell you)


It is.

On that subject, I have now ran a new series of tests, with the default 
AARCH64 Debian 9.7 compiler (gcc 6.3.0 20170516), and so far I have not 
been able to observe the Synchronous Exceptions that had us switch to 
the Linaro compiler.


It needs to be noted however that, since we ran into those, we did 
switch to using different ATF binaries, different VideoCore firmware, 
and removed some drivers (such as an HyperVisor) from the firmware. So 
there are quite a few elements that could have had an impact on the 
earlier issue.


I will continue to test with the default Debian compiler for now, and, 
if I don't see a resurgence of the issue, I'll remove the note about 
preferring a Linaro toolchain.



Also, given that Leif doesn't want the full hand-holding compilation 
instructions and that I have no intention to push back on that, I will 
remove that part