date:20170516

Re: [edk2] Can I do this in an INF file?

2017-05-16 Thread Andrew Fish

Liming,

Why does INF syntax support [LibraryClasses.common.DXE_RUNTIME_DRIVER] if it 
does nothing? 

https://edk2-docs.gitbooks.io/edk-ii-inf-specification/content/3_edk_ii_inf_file_format/36_[libraryclasses]_sections.html

Thanks,

Andrew Fish


> On May 16, 2017, at 6:46 PM, Andrew Fish  wrote:
> 
>> 
>> On May 16, 2017, at 6:41 PM, Gao, Liming > > wrote:
>> 
>> Andrew:
>> There is no such usage. INF can specify source files for the different 
>> ARCHs, but not specify source files for the different module type. In fact, 
>> INF module type is fixed. It can't be changed to other type in build time. 
>> If you expect the library to be linked to the different type driver with the 
>> different sources, you may create two version INF files to include the 
>> different source files.  
>> 
> 
> Liming,
> 
> Thanks. Yes given how the build system works what I asked is not possible. 
> 
> I ended up doing it the correct way and made an instance of the 
> UefiRuntimeLib to link against. 
> 
> Thanks,
> 
> Andrew Fish
> 
>> Thanks
>> Liming
>>> -Original Message-
>>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>>> Andrew Fish
>>> Sent: Wednesday, May 17, 2017 7:43 AM
>>> To: edk2-devel 
>>> Subject: [edk2] Can I do this in an INF file?
>>> 
>>> I'm trying to cross compile a runtime library to work in an Application (for
>>> testing). I can't seem to restrict files and libs to specific module types?
>>> 
>>> [Sources.common.UEFI_APPLICATION]
>>> FakeRuntime.c
>>> 
>>> 
>>> [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>>> UefiRuntimeLib
>>> 
>>> Am I using the wrong syntax?
>>> 
>>> Thanks,
>>> 
>>> Andrew Fish
>>> ___
>>> 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-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] Can I do this in an INF file?

2017-05-16 Thread Andrew Fish


> On May 16, 2017, at 6:41 PM, Gao, Liming  wrote:
> 
> Andrew:
>  There is no such usage. INF can specify source files for the different 
> ARCHs, but not specify source files for the different module type. In fact, 
> INF module type is fixed. It can't be changed to other type in build time. If 
> you expect the library to be linked to the different type driver with the 
> different sources, you may create two version INF files to include the 
> different source files.  
> 

Liming,

Thanks. Yes given how the build system works what I asked is not possible. 

I ended up doing it the correct way and made an instance of the UefiRuntimeLib 
to link against. 

Thanks,

Andrew Fish

> Thanks
> Liming
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Andrew Fish
>> Sent: Wednesday, May 17, 2017 7:43 AM
>> To: edk2-devel 
>> Subject: [edk2] Can I do this in an INF file?
>> 
>> I'm trying to cross compile a runtime library to work in an Application (for
>> testing). I can't seem to restrict files and libs to specific module types?
>> 
>> [Sources.common.UEFI_APPLICATION]
>> FakeRuntime.c
>> 
>> 
>> [LibraryClasses.common.DXE_RUNTIME_DRIVER]
>> UefiRuntimeLib
>> 
>> Am I using the wrong syntax?
>> 
>> Thanks,
>> 
>> Andrew Fish
>> ___
>> 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-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Can I do this in an INF file?

2017-05-16 Thread Gao, Liming

Andrew:
  There is no such usage. INF can specify source files for the different ARCHs, 
but not specify source files for the different module type. In fact, INF module 
type is fixed. It can't be changed to other type in build time. If you expect 
the library to be linked to the different type driver with the different 
sources, you may create two version INF files to include the different source 
files.  

Thanks
Liming
>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>Andrew Fish
>Sent: Wednesday, May 17, 2017 7:43 AM
>To: edk2-devel 
>Subject: [edk2] Can I do this in an INF file?
>
>I'm trying to cross compile a runtime library to work in an Application (for
>testing). I can't seem to restrict files and libs to specific module types?
>
>[Sources.common.UEFI_APPLICATION]
>  FakeRuntime.c
>
>
>[LibraryClasses.common.DXE_RUNTIME_DRIVER]
>  UefiRuntimeLib
>
>Am I using the wrong syntax?
>
>Thanks,
>
>Andrew Fish
>___
>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] [RFC] PCD: Database size optimization for multi-SKU

2017-05-16 Thread Zeng, Star

Tim,

Yes, right. The PCD_DATABASE_INIT.BuildVersion will be increased for the PCD 
database format change to support multi-SKU. That is the rule we maintain the 
PCD database. :)


Thanks,
Star
From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Wednesday, May 17, 2017 2:04 AM
To: Zeng, Star ; edk2-devel@lists.01.org
Cc: Zeng, Star ; Kinney, Michael D 
; Gao, Liming ; Zhu, Yonghong 

Subject: RE: [RFC] PCD: Database size optimization for multi-SKU


Star-



One more requirement that I propose is the the format update be detectable 
easily by inspection of the binary image. We have tools that dump and 
manipulate the PCD database and the revision or version number allows us to 
support multiple core versions. I think this is already your intent and I want 
to make it an explicit requirement.



Other than that, I think this is a much needed change for multi-sku firmware 
images.



Thanks,

Tim



Sent from my Windows 10 phone



From: Star Zeng
Sent: Tuesday, May 16, 2017 7:33 AM
To: edk2-devel@lists.01.org
Cc: Star Zeng; Michael 
Kinney; Liming 
Gao; Tim Lewis; 
Yonghong Zhu
Subject: [RFC] PCD: Database size optimization for multi-SKU


- Requirement
Reduce PCD database size for multi-SKU case to save image size at build time 
and memory resource at boot time.


- Current limitation
When multiple SKUs are enabled, the full set of PCD values for all SKUs will be 
generated into PCD database,
and HOB will be created for the PCD database, the HOB will consume much memory 
resource when many SKUs are specified,
but the HOB length and pre-memory phase memory resource are limited.


- Proposal
BaseTools can generate the optimized PCD database to save the image size at 
build time,
the optimized PCD database layout will be like below, the PCD database will be 
composed of the full
default SKU data(PCD_DATABASE_INIT) and the non-default SKU delta 
data(PCD_DATABASE_SKU_DELTA).
PCD driver will build HOB to store the full default SKU data, and patch HOB 
data based on
non-default SKU delta data for the SKU set by SetSku(), it can save memory 
resource at boot time.

//
// PCD database layout:
// +-+
// | PCD_DATABASE_INIT (DEFAULT SKU) |
// +-+
// | PCD_DATABASE_SKU_DELTA (SKU A)  |
// +-+
// | PCD_DATABASE_SKU_DELTA (SKU B)  |
// +-+
// | ..  |
// +-+
//

The patch below shows the detailed PCD database format change.

BaseTools, PCD database and driver updates are needed for this proposal.
BaseTools can even be intelligent to generate smallest SKU delta based on the 
PCD values for different SKUs and the relationship between SKUs.
For single SKU (default) case, this proposal is expected to have no impact.
Note: For multi-SKU case, PCD database format will be changed, so PCD driver 
will have to be updated together with BaseTools.

Cc: Michael Kinney 
>
Cc: Liming Gao >
Cc: Tim Lewis >
Cc: Yonghong Zhu >

---
 .../Include/Guid/PcdDataBaseSignatureGuid.h| 32 +-
 1 file changed, 25 insertions(+), 7 deletions(-)

diff --git a/MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h 
b/MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h
index d2e848800b75..0069823458cd 100644
--- a/MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h
+++ b/MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h
@@ -62,11 +62,6 @@ typedef struct  {
 } DYNAMICEX_MAPPING;

 typedef struct {
-  UINT32  SkuDataStartOffset;   // Offset(with DATUM TYPE info) from the 
PCD_DB.
-  UINT32  SkuIdTableOffset; // Offset from the PCD_DB.
-} SKU_HEAD;
-
-typedef struct {
   UINT32  StringIndex;  // Offset in String Table in units of UINT8.
   UINT32  DefaultValueOffset;   // Offset of the Default Value.
   UINT16  GuidTableIndex;   // Offset in Guid Table in units of GUID.
@@ -115,7 +110,6 @@ typedef struct {
 // Padding is needed to keep necessary alignment
 //
 //SKU_ID SkuIdTable[];// SkuIds system 
supports.
-//SKU_ID SkuIndexTable[]; // SkuIds for 
each PCD with SKU enable.
 //UINT64 ValueUint64[];
 //UINT32 ValueUint32[];
 //VPD_HEAD   VpdHead[];   // VPD Offset
@@ -125,7 +119,6 @@ typedef struct {

[edk2] Can I do this in an INF file?

2017-05-16 Thread Andrew Fish

I'm trying to cross compile a runtime library to work in an Application (for 
testing). I can't seem to restrict files and libs to specific module types?

[Sources.common.UEFI_APPLICATION]
  FakeRuntime.c


[LibraryClasses.common.DXE_RUNTIME_DRIVER] 
  UefiRuntimeLib

Am I using the wrong syntax?

Thanks,

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

Re: [edk2] [RFC v4 06/13] OvmfPkg:AmdSevDxe: add AmdSevDxe driver

2017-05-16 Thread Brijesh Singh




On 05/16/2017 12:56 PM, Jordan Justen wrote:

On 2017-05-16 05:04:58, Brijesh Singh wrote:

Hi Jordan,

On 5/15/17 12:47 PM, Jordan Justen wrote:

On 2017-05-11 11:01:57, Brijesh Singh wrote:


We basically need some kind of guarantee that this driver is run before any 
other
drivers or libs access MMIO register/buffers. In additional to clearing 
encryption
bit from MMIO spaces, the driver also installs IOMMU protocol. So far, IOMMU 
protocol
is directly consumed by PciHostBridgeDxe driver and QemuFwCfgDxeLib.

What about adding a NULL protocol named
gOvmfIoMmuDetectionProtocolGuid? (Better name suggestions welcomed. :)
Then we can use this protocol in a depex where needed.

It should be doable, If I find better name then I will use that :)

Maybe we should consider naming the driver IoMmuDxe instead?

I think the generic PciRoot bridge driver shouldn't need this in the
depex because it will not start until the BDS phase, and the IoMmuDxe
driver would have been dispatched by then.

Are you suggesting that we introduce a new IoMmuDxe driver and install
IOMMU protocol unconditionally ?


No. I'm suggesting we have a new protocol that only exists to allow
dependency expressions to know that we've attempted to detect an IoMmu
implementation.



Okay got it thanks.


The driver would "install" the protocol with a NULL pointer regardless
of whether the IoMmu protocol was installed. Maybe
gOvmfIoMmuDetectionAttemptedProtocolGuid would be a better name?

The DXE fw-cfg library should then list this under depex. I think the
PCI Host bridge driver doesn't require the depex for the reason I
mentioned abobe.

The gEdkiiIoMmuProtocolGuid protocol would only be installed be
installed when detected like your patches currently do.

This method should allow the driver runtime order dependency to be
explicitly indicated.

Regarding the 'IoMmuDxe' name, I was suggesting that AmdSevDxe be
renamed to IoMmuDxe. Since we would be installing the 'we tried to
detect iommu' protocol, it probably makes sense to put all the iommu
implementation support into a single driver and only install the
'detection attempted' protocol it after trying to detect all supported
iommu implementations.

There could be an issue with this. FvbServicesRuntimeDxe.inf is in the
apriori currently if SMM_REQUIRE is set, so if it needs the iommu
treatment, then this wouldn't work. This driver does use MM I/O just
below 4GB. I don't think your current patches would change how this
driver runs since it doesn't use the PCI host bridge protocol, so I
guess it is ok?



We do need to ensure that AmdSevDxe runs before FvbServicesRuntimeDxe.inf.
As you rightly pointed, FvbServicesRuntimeDxe uses MM I/O below 4GB hence
we need to clear encryption attribute from MMIO space before QemuFlash
detection logic is invoked. In my patch set, I have listed AmdSevDxe.inf before
FvbServicesRuntimeDxe.inf to ensure that we clear the MMIO before QemuFlash
detection logic from FvbServicesRuntimeDxe.inf is invoked.

Here is fdt file snippet after my patches.

APRIORI DXE {
   INF  MdeModulePkg/Universal/DevicePathDxe/DevicePathDxe.inf
   INF  MdeModulePkg/Universal/PCD/Dxe/Pcd.inf
   INF  OvmfPkg/AmdSevDxe/AmdSevDxe.inf
 !if $(SMM_REQUIRE) == FALSE
   INF  OvmfPkg/QemuFlashFvbServicesRuntimeDxe/FvbServicesRuntimeDxe.inf
 !endif
 }



(It would be nice to get FvbServicesRuntimeDxe.inf out of the apriori
too, but that is a separate issue.)



Yes, if we can move that out from Apriori then maybe also need to add some
kind of depex to ensure that it gets called after we clear memory encryption
bit from MMIO regions.

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

Re: [edk2] [RFC] PCD: Database size optimization for multi-SKU

2017-05-16 Thread Tim Lewis

Star-



One more requirement that I propose is the the format update be detectable 
easily by inspection of the binary image. We have tools that dump and 
manipulate the PCD database and the revision or version number allows us to 
support multiple core versions. I think this is already your intent and I want 
to make it an explicit requirement.



Other than that, I think this is a much needed change for multi-sku firmware 
images.



Thanks,

Tim



Sent from my Windows 10 phone



From: Star Zeng
Sent: Tuesday, May 16, 2017 7:33 AM
To: edk2-devel@lists.01.org
Cc: Star Zeng; Michael 
Kinney; Liming 
Gao; Tim Lewis; 
Yonghong Zhu
Subject: [RFC] PCD: Database size optimization for multi-SKU



- Requirement
Reduce PCD database size for multi-SKU case to save image size at build time 
and memory resource at boot time.


- Current limitation
When multiple SKUs are enabled, the full set of PCD values for all SKUs will be 
generated into PCD database,
and HOB will be created for the PCD database, the HOB will consume much memory 
resource when many SKUs are specified,
but the HOB length and pre-memory phase memory resource are limited.


- Proposal
BaseTools can generate the optimized PCD database to save the image size at 
build time,
the optimized PCD database layout will be like below, the PCD database will be 
composed of the full
default SKU data(PCD_DATABASE_INIT) and the non-default SKU delta 
data(PCD_DATABASE_SKU_DELTA).
PCD driver will build HOB to store the full default SKU data, and patch HOB 
data based on
non-default SKU delta data for the SKU set by SetSku(), it can save memory 
resource at boot time.

//
// PCD database layout:
// +-+
// | PCD_DATABASE_INIT (DEFAULT SKU) |
// +-+
// | PCD_DATABASE_SKU_DELTA (SKU A)  |
// +-+
// | PCD_DATABASE_SKU_DELTA (SKU B)  |
// +-+
// | ..  |
// +-+
//

The patch below shows the detailed PCD database format change.

BaseTools, PCD database and driver updates are needed for this proposal.
BaseTools can even be intelligent to generate smallest SKU delta based on the 
PCD values for different SKUs and the relationship between SKUs.
For single SKU (default) case, this proposal is expected to have no impact.
Note: For multi-SKU case, PCD database format will be changed, so PCD driver 
will have to be updated together with BaseTools.

Cc: Michael Kinney 
Cc: Liming Gao 
Cc: Tim Lewis 
Cc: Yonghong Zhu 

---
 .../Include/Guid/PcdDataBaseSignatureGuid.h| 32 +-
 1 file changed, 25 insertions(+), 7 deletions(-)

diff --git a/MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h 
b/MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h
index d2e848800b75..0069823458cd 100644
--- a/MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h
+++ b/MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h
@@ -62,11 +62,6 @@ typedef struct  {
 } DYNAMICEX_MAPPING;

 typedef struct {
-  UINT32  SkuDataStartOffset;   // Offset(with DATUM TYPE info) from the 
PCD_DB.
-  UINT32  SkuIdTableOffset; // Offset from the PCD_DB.
-} SKU_HEAD;
-
-typedef struct {
   UINT32  StringIndex;  // Offset in String Table in units of UINT8.
   UINT32  DefaultValueOffset;   // Offset of the Default Value.
   UINT16  GuidTableIndex;   // Offset in Guid Table in units of GUID.
@@ -115,7 +110,6 @@ typedef struct {
 // Padding is needed to keep necessary alignment
 //
 //SKU_ID SkuIdTable[];// SkuIds system 
supports.
-//SKU_ID SkuIndexTable[]; // SkuIds for 
each PCD with SKU enable.
 //UINT64 ValueUint64[];
 //UINT32 ValueUint32[];
 //VPD_HEAD   VpdHead[];   // VPD Offset
@@ -125,7 +119,6 @@ typedef struct {
 //STRING_HEADStringHead[];// String PCD
 //PCD_NAME_INDEX PcdNameTable[];  // PCD name 
index info. It can be accessed by the PcdNameTableOffset.
 //VARIABLE_HEAD  VariableHead[];  // HII PCD
-//SKU_HEAD   SkuHead[];   // Store SKU 
info for each PCD with SKU enable.
 //UINT8  StringTable[];   // String for 
String PCD value and HII PCD Variable Name. It can be accessed by 
StringTableOffset.
 //SIZE_INFO  SizeTable[]; // MaxSize and 
CurSize for String PCD. It can be accessed by SizeTableOffset.

Re: [edk2] [RFC v4 06/13] OvmfPkg:AmdSevDxe: add AmdSevDxe driver

2017-05-16 Thread Jordan Justen

On 2017-05-16 05:04:58, Brijesh Singh wrote:
> Hi Jordan,
> 
> On 5/15/17 12:47 PM, Jordan Justen wrote:
> > On 2017-05-11 11:01:57, Brijesh Singh wrote:
> >>
> >> We basically need some kind of guarantee that this driver is run before 
> >> any other
> >> drivers or libs access MMIO register/buffers. In additional to clearing 
> >> encryption
> >> bit from MMIO spaces, the driver also installs IOMMU protocol. So far, 
> >> IOMMU protocol
> >> is directly consumed by PciHostBridgeDxe driver and QemuFwCfgDxeLib.
> > What about adding a NULL protocol named
> > gOvmfIoMmuDetectionProtocolGuid? (Better name suggestions welcomed. :)
> > Then we can use this protocol in a depex where needed.
> It should be doable, If I find better name then I will use that :)
> > Maybe we should consider naming the driver IoMmuDxe instead?
> >
> > I think the generic PciRoot bridge driver shouldn't need this in the
> > depex because it will not start until the BDS phase, and the IoMmuDxe
> > driver would have been dispatched by then.
> Are you suggesting that we introduce a new IoMmuDxe driver and install
> IOMMU protocol unconditionally ?

No. I'm suggesting we have a new protocol that only exists to allow
dependency expressions to know that we've attempted to detect an IoMmu
implementation.

The driver would "install" the protocol with a NULL pointer regardless
of whether the IoMmu protocol was installed. Maybe
gOvmfIoMmuDetectionAttemptedProtocolGuid would be a better name?

The DXE fw-cfg library should then list this under depex. I think the
PCI Host bridge driver doesn't require the depex for the reason I
mentioned abobe.

The gEdkiiIoMmuProtocolGuid protocol would only be installed be
installed when detected like your patches currently do.

This method should allow the driver runtime order dependency to be
explicitly indicated.

Regarding the 'IoMmuDxe' name, I was suggesting that AmdSevDxe be
renamed to IoMmuDxe. Since we would be installing the 'we tried to
detect iommu' protocol, it probably makes sense to put all the iommu
implementation support into a single driver and only install the
'detection attempted' protocol it after trying to detect all supported
iommu implementations.

There could be an issue with this. FvbServicesRuntimeDxe.inf is in the
apriori currently if SMM_REQUIRE is set, so if it needs the iommu
treatment, then this wouldn't work. This driver does use MM I/O just
below 4GB. I don't think your current patches would change how this
driver runs since it doesn't use the PCI host bridge protocol, so I
guess it is ok?

(It would be nice to get FvbServicesRuntimeDxe.inf out of the apriori
too, but that is a separate issue.)

-Jordan

> I was hoping that we install IOMMU
> protocol only when SEV is enabled. A non-SEV guest will still use the
> old approach.  I was minimizing changes into non-SEV code flow.  Please
> note that since AmdSevDxe driver does *two* things; a) clear C-bit from
> MMIO b) installs IOMMU protocol hence I will not able to remove 
> AmdSevDxe completely.  But I can remove IOMMU protocol installation part
> from AmdSevDxe and move it into new IoMmuDxe driver.  Please let me know
> if this is what you are asking.  thanks
> 
> -Brijesh
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg/BaseLib: Fix PathRemoveLastItem to ignore consecutive '\'

2017-05-16 Thread Jeff Westfahl


Hi Ray,

The problem with 'ls ..\..\' that I'm trying to solve here is the call to 
PathRemoveLastItem from within PathCleanUpDirectories. This intermediate 
path is not clean. Here is a log of the operations performed on a path as 
it goes through PathCleanUpDirectories:


FS2:\ABC\DEF\> ls ..\..
ShellCommandRunLs: FullPath FS2:\ABC\DEF\..\..
ShellCommandRunLs: PathName ..\..
PathCleanUpDirectories: Entry: FS2:\ABC\DEF\..\..\*
PathCleanUpDirectories: Stp4a: FS2:\ABC\DEF\
PathRemoveLastItem: Entry FS2:\ABC\DEF\
PathRemoveLastItem: Exit1 FS2:\ABC\
PathCleanUpDirectories: Stp4b: FS2:\ABC\
PathCleanUpDirectories: Stp4c: FS2:\ABC\\..\*
PathCleanUpDirectories: Stp4a: FS2:\ABC\\
PathRemoveLastItem: Entry FS2:\ABC\\
PathRemoveLastItem: Exit1 FS2:\ABC\
PathCleanUpDirectories: Stp4b: FS2:\ABC\
PathCleanUpDirectories: Stp4c: FS2:\ABC\\*
PathCleanUpDirectories: Step5: FS2:\ABC\*
PathCleanUpDirectories: Exit:  FS2:\ABC\*

As you can see, on the second iteration through the while loop (Step 4) on 
PathCleanUpDirectories that removes all of the "\..", we pass an unclean 
path to PathRemoveLastItem.


It's difficult to fix this problem in PathCleanUpDirectories because the 
unclean path can be, well, unclean. For example, "FS2:\ABC\DEF\....".


Please let me know what you think.

Regards,
Jeff

On Tue, 16 May 2017, Ni, Ruiyu wrote:


Jeff,
PathRemoveLastItem() is expected to be called after PathCleanUpDirectories().
E.g.: what should we expect PathRemoveLastItem() do for "fs0:\a\b\..\"?
So PathRemoveLastItem() expects the incoming path is cleaned.

Thanks/Ray


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
Jeff Westfahl
Sent: Saturday, May 13, 2017 12:01 AM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Ni, Ruiyu
; Carsey, Jaben ; Gao, Liming

Subject: [edk2] [PATCH] MdePkg/BaseLib: Fix PathRemoveLastItem to ignore
consecutive '\'

This patch makes PathRemoveLastItem ignore consecutive occurrences of
the '\' path separator.

Consider a path like "FS0:\ABC\DEF\\", noting the consecutive '\' path
separator characters at the end. The expected result of
PathRemoveLastItem on such a path is "FS0:\ABC\". However, what we get is
"FS0:\ABC\DEF\".

We can see the result of this behavior with 'ls' in the EFI shell. Go a couple 
of
folders deep into a filesystem and try 'ls ..\..'. Here's an example, with a
filesystem with folder ABC in the root, with subfolder DEF.

FS0:\ABC\DEF\> ls ..
Directory of: FS0:\ABC\
05/12/2017  15:46  8,192  .
05/12/2017  15:46  0  ..
05/12/2017  15:46  8,192  DEF
  0 File(s)   0 bytes
  3 Dir(s)
FS0:\ABC\DEF\> ls ..\..
Directory of: FS0:\ABC\
05/12/2017  15:46  8,192  .
05/12/2017  15:46  0  ..
05/12/2017  15:46  8,192  DEF
  0 File(s)   0 bytes
  3 Dir(s)
fs0:\ABC\DEF\>

As you can see, 'ls ..\..' lists only the parent folder. This patch resolves the
issue so that 'ls ..\..' lists the grandparent folder.

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Ruiyu Ni 
Cc: Jaben Carsey 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Westfahl 
---
 MdePkg/Library/BaseLib/FilePaths.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/MdePkg/Library/BaseLib/FilePaths.c
b/MdePkg/Library/BaseLib/FilePaths.c
index 203045c..bbaf140 100644
--- a/MdePkg/Library/BaseLib/FilePaths.c
+++ b/MdePkg/Library/BaseLib/FilePaths.c
@@ -37,9 +37,7 @@ PathRemoveLastItem(
   ; Walker != NULL && *Walker != CHAR_NULL
   ; Walker++
  ){
-if (*Walker == L'\\' && *(Walker + 1) != CHAR_NULL) {
-  LastSlash = Walker+1;
-} else if (*Walker == L':' && *(Walker + 1) != L'\\' && *(Walker + 1) !=
CHAR_NULL) {
+if ((*Walker == L'\\' || *Walker == L':') && *(Walker + 1) != L'\\'
+ && *(Walker + 1) != CHAR_NULL) {
   LastSlash = Walker+1;
 }
   }
--
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

[edk2] [RFC] PCD: Database size optimization for multi-SKU

2017-05-16 Thread Star Zeng

- Requirement
Reduce PCD database size for multi-SKU case to save image size at build time 
and memory resource at boot time.


- Current limitation
When multiple SKUs are enabled, the full set of PCD values for all SKUs will be 
generated into PCD database,
and HOB will be created for the PCD database, the HOB will consume much memory 
resource when many SKUs are specified,
but the HOB length and pre-memory phase memory resource are limited.


- Proposal
BaseTools can generate the optimized PCD database to save the image size at 
build time,
the optimized PCD database layout will be like below, the PCD database will be 
composed of the full
default SKU data(PCD_DATABASE_INIT) and the non-default SKU delta 
data(PCD_DATABASE_SKU_DELTA).
PCD driver will build HOB to store the full default SKU data, and patch HOB 
data based on
non-default SKU delta data for the SKU set by SetSku(), it can save memory 
resource at boot time.

//
// PCD database layout:
// +-+
// | PCD_DATABASE_INIT (DEFAULT SKU) |
// +-+
// | PCD_DATABASE_SKU_DELTA (SKU A)  |
// +-+
// | PCD_DATABASE_SKU_DELTA (SKU B)  |
// +-+
// | ..  |
// +-+
//

The patch below shows the detailed PCD database format change.

BaseTools, PCD database and driver updates are needed for this proposal.
BaseTools can even be intelligent to generate smallest SKU delta based on the 
PCD values for different SKUs and the relationship between SKUs.
For single SKU (default) case, this proposal is expected to have no impact.
Note: For multi-SKU case, PCD database format will be changed, so PCD driver 
will have to be updated together with BaseTools.

Cc: Michael Kinney 
Cc: Liming Gao 
Cc: Tim Lewis 
Cc: Yonghong Zhu 

---
 .../Include/Guid/PcdDataBaseSignatureGuid.h| 32 +-
 1 file changed, 25 insertions(+), 7 deletions(-)

diff --git a/MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h 
b/MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h
index d2e848800b75..0069823458cd 100644
--- a/MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h
+++ b/MdeModulePkg/Include/Guid/PcdDataBaseSignatureGuid.h
@@ -62,11 +62,6 @@ typedef struct  {
 } DYNAMICEX_MAPPING;
 
 typedef struct {
-  UINT32  SkuDataStartOffset;   // Offset(with DATUM TYPE info) from the 
PCD_DB.
-  UINT32  SkuIdTableOffset; // Offset from the PCD_DB.
-} SKU_HEAD;
-
-typedef struct {
   UINT32  StringIndex;  // Offset in String Table in units of UINT8.
   UINT32  DefaultValueOffset;   // Offset of the Default Value.
   UINT16  GuidTableIndex;   // Offset in Guid Table in units of GUID.
@@ -115,7 +110,6 @@ typedef struct {
 // Padding is needed to keep necessary alignment
 //
 //SKU_ID SkuIdTable[];// SkuIds system 
supports.
-//SKU_ID SkuIndexTable[]; // SkuIds for 
each PCD with SKU enable.
 //UINT64 ValueUint64[];
 //UINT32 ValueUint32[];
 //VPD_HEAD   VpdHead[];   // VPD Offset
@@ -125,7 +119,6 @@ typedef struct {
 //STRING_HEADStringHead[];// String PCD
 //PCD_NAME_INDEX PcdNameTable[];  // PCD name 
index info. It can be accessed by the PcdNameTableOffset.
 //VARIABLE_HEAD  VariableHead[];  // HII PCD
-//SKU_HEAD   SkuHead[];   // Store SKU 
info for each PCD with SKU enable.
 //UINT8  StringTable[];   // String for 
String PCD value and HII PCD Variable Name. It can be accessed by 
StringTableOffset.
 //SIZE_INFO  SizeTable[]; // MaxSize and 
CurSize for String PCD. It can be accessed by SizeTableOffset.
 //UINT16 ValueUint16[];
@@ -134,6 +127,31 @@ typedef struct {
 
 } PCD_DATABASE_INIT;
 
+typedef struct {
+  UINT32Offset:24;
+  UINT32Data:8;
+} PCD_DATABASE_SKU_DELTA_DATA;
+
+typedef struct {
+  SKU_IDSkuId;
+  SKU_IDSkuIdCompared;
+  UINT32Length;
+  //PCD_DATABASE_SKU_DELTA_DATA   DeltaData[]
+} PCD_DATABASE_SKU_DELTA;
+
+//
+// PCD database layout:
+// +-+
+// | PCD_DATABASE_INIT (DEFAULT SKU) |
+// +-+
+// | PCD_DATABASE_SKU_DELTA (SKU A)  |
+// +-+
+// | PCD_DATABASE_SKU_DELTA (SKU B)  |
+// +-+
+// | ..  |
+// +-+
+//
+
 //
 // PEI and DXE Pcd driver use the same PCD database
 //
-- 
2.7.0.windows.1

___
edk2-devel mailing

[edk2] How to look up ACPI device node from DXE driver

2017-05-16 Thread Evgeny Yakovlev

I am writing a DXE driver for a paravirtualized HyperV storage device for
OvmfPkg. Host hypervisor exposes the presence of this device through ACPI
device node in DSDT. Specific AML path itself may be different from host to
host but device UID is always a string: "VMBus".

I was hoping to be able to walk DSDT table in my DXE driver to locate this
device node and start publishing necessary protocols, but I am having
trouble figuring out how to do this, i.e. are there any support libraries
or protocols to traverse ACPI tables or how do I have to do that manually.
Will be glad for any advice, thanks.
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdePkg: Fix undefined behavior on variadic parameters

2017-05-16 Thread Sergei Temerkhanov

On Tue, May 16, 2017 at 8:10 AM, Gao, Liming  wrote:
> Sergey:
>   Could you give more detail on the undefined behavior on variadic parameters?
>
>   I see https://bugzilla.tianocore.org/show_bug.cgi?id=410 describe this 
> issues found in the latest CLANG tool chain. Do you find other tool chain 
> reports it?

Yes, this is exactly the bug this patch fixes.

As per the C99 standard:
"The parameter parmN is the identifier of the rightmost parameter in
the variable parameter list in the function definition (the one just
before the , ...). If the parameter parmN is declared with the
register storage class, with a function or array type, or with a type
that is not compatible with the type that results after application of
the default argument promotions, the behavior is undefined."

That's exactly the case here since BOOLEAN is a typedef for unsigned
char. It undergoes a promotion to an unsigned int which is not a
compatible type for unsigned char. Correct me if I'm wrong.

Regards,
Sergey

>
> Thanks
> Liming
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
>> Sergey Temerkhanov
>> Sent: Tuesday, May 16, 2017 10:57 AM
>> To: edk2-devel@lists.01.org
>> Subject: [edk2] [PATCH] MdePkg: Fix undefined behavior on variadic parameters
>>
>> Fix undefined behavior by avoiding parameter type promotion
>>
>> Signed-off-by: Sergey Temerkhanov 
>> ---
>>  MdePkg/Include/Library/UefiLib.h | 2 +-
>>  MdePkg/Library/UefiLib/UefiLib.c | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/MdePkg/Include/Library/UefiLib.h 
>> b/MdePkg/Include/Library/UefiLib.h
>> index 0b14792..4e4697c 100644
>> --- a/MdePkg/Include/Library/UefiLib.h
>> +++ b/MdePkg/Include/Library/UefiLib.h
>> @@ -818,7 +818,7 @@ CHAR8 *
>>  EFIAPI
>>  GetBestLanguage (
>>IN CONST CHAR8  *SupportedLanguages,
>> -  IN BOOLEAN  Iso639Language,
>> +  IN UINTN  Iso639Language,
>>...
>>);
>>
>> diff --git a/MdePkg/Library/UefiLib/UefiLib.c 
>> b/MdePkg/Library/UefiLib/UefiLib.c
>> index a7eee01..74528ec 100644
>> --- a/MdePkg/Library/UefiLib/UefiLib.c
>> +++ b/MdePkg/Library/UefiLib/UefiLib.c
>> @@ -1514,7 +1514,7 @@ CHAR8 *
>>  EFIAPI
>>  GetBestLanguage (
>>IN CONST CHAR8  *SupportedLanguages,
>> -  IN BOOLEAN  Iso639Language,
>> +  IN UINTN  Iso639Language,
>>...
>>)
>>  {
>> --
>> 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] [RFC v4 06/13] OvmfPkg:AmdSevDxe: add AmdSevDxe driver

2017-05-16 Thread Brijesh Singh

Hi Jordan,

On 5/15/17 12:47 PM, Jordan Justen wrote:
> On 2017-05-11 11:01:57, Brijesh Singh wrote:
>>
>> We basically need some kind of guarantee that this driver is run before any 
>> other
>> drivers or libs access MMIO register/buffers. In additional to clearing 
>> encryption
>> bit from MMIO spaces, the driver also installs IOMMU protocol. So far, IOMMU 
>> protocol
>> is directly consumed by PciHostBridgeDxe driver and QemuFwCfgDxeLib.
> What about adding a NULL protocol named
> gOvmfIoMmuDetectionProtocolGuid? (Better name suggestions welcomed. :)
> Then we can use this protocol in a depex where needed.
It should be doable, If I find better name then I will use that :)
> Maybe we should consider naming the driver IoMmuDxe instead?
>
> I think the generic PciRoot bridge driver shouldn't need this in the
> depex because it will not start until the BDS phase, and the IoMmuDxe
> driver would have been dispatched by then.
Are you suggesting that we introduce a new IoMmuDxe driver and install
IOMMU protocol unconditionally ? I was hoping that we install IOMMU
protocol only when SEV is enabled. A non-SEV guest will still use the
old approach.  I was minimizing changes into non-SEV code flow.  Please
note that since AmdSevDxe driver does *two* things; a) clear C-bit from
MMIO b) installs IOMMU protocol hence I will not able to remove 
AmdSevDxe completely.  But I can remove IOMMU protocol installation part
from AmdSevDxe and move it into new IoMmuDxe driver.  Please let me know
if this is what you are asking.  thanks

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

[edk2] [PATCH 2/2] ArmPlatformPkg: Timer access for non-secure EL1/0

2017-05-16 Thread evan . lloyd

From: Sami Mujawar 

According to Section 2.3.6 of the "UEFI Specification 2.6 Errata A";
the primary CPU must be configured such that 'Timer access must be
provided to non-secure EL1 and EL0 by setting bits EL1PCTEN and
EL1PCEN in register CNTHCTL_EL2.'

This commit adds this missing set-up to the PrePi and PrePeiCore
modules.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Sami Mujawar 
Signed-off-by: Evan Lloyd 
---
 ArmPlatformPkg/PrePi/AArch64/ArchPrePi.c   | 9 -
 ArmPlatformPkg/PrePeiCore/AArch64/Helper.S | 9 -
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/ArmPlatformPkg/PrePi/AArch64/ArchPrePi.c 
b/ArmPlatformPkg/PrePi/AArch64/ArchPrePi.c
index 
217986107e44185c2c6e11ca8a417fad659cde2f..4da590805aaae4016952c0e5e9ce90c1897e37c4
 100644
--- a/ArmPlatformPkg/PrePi/AArch64/ArchPrePi.c
+++ b/ArmPlatformPkg/PrePi/AArch64/ArchPrePi.c
@@ -1,6 +1,6 @@
 /** @file
 *
-*  Copyright (c) 2011-2013, ARM Limited. All rights reserved.
+*  Copyright (c) 2011-2017, ARM Limited. All rights reserved.
 *
 *  This program and the accompanying materials
 *  are licensed and made available under the terms and conditions of the BSD 
License
@@ -29,5 +29,12 @@ ArchInitialize (
   if (ArmReadCurrentEL () == AARCH64_EL2) {
 // Trap General Exceptions. All exceptions that would be routed to EL1 are 
routed to EL2
 ArmWriteHcr (ARM_HCR_TGE);
+
+/* Enable Timer access for non-secure EL1 and EL0
+   The cnthctl_el2 register bits are architecturally
+   UNKNOWN on reset.
+   Disable event stream as it is not in use at this stage
+*/
+ArmWriteCntHctl (CNTHCTL_EL2_EL1PCTEN | CNTHCTL_EL2_EL1PCEN);
   }
 }
diff --git a/ArmPlatformPkg/PrePeiCore/AArch64/Helper.S 
b/ArmPlatformPkg/PrePeiCore/AArch64/Helper.S
index 
5f35484b1259f8b85c370de2cde945db2b799c13..b4f35b7ff5d389ecf61c025f85bb6cf8fcce793d
 100644
--- a/ArmPlatformPkg/PrePeiCore/AArch64/Helper.S
+++ b/ArmPlatformPkg/PrePeiCore/AArch64/Helper.S
@@ -1,5 +1,5 @@
 
#
-#  Copyright (c) 2011-2013, ARM Limited. All rights reserved.
+#  Copyright (c) 2011-2017, ARM Limited. All rights reserved.
 #
 #  This program and the accompanying materials
 #  are licensed and made available under the terms and conditions of the BSD 
License
@@ -36,6 +36,13 @@ ASM_FUNC(SetupExceptionLevel2)
 
msr cptr_el2, xzr  // Disable copro traps to EL2
 
+   // Enable Timer access for non-secure EL1 and EL0
+   // The cnthctl_el2 register bits are architecturally
+   // UNKNOWN on reset.
+   // Disable event stream as it is not in use at this stage
+   mov x0, #(CNTHCTL_EL2_EL1PCTEN | CNTHCTL_EL2_EL1PCEN)
+   msr cnthctl_el2, x0
+
ret
 
 ASM_FUNCTION_REMOVE_IF_UNREFERENCED
-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

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

[edk2] [PATCH 0/2] Initialize CNTHCTL

2017-05-16 Thread evan . lloyd

From: Evan 

A pair of minor patches to correct an omission.
This patch set enables timer access as required by the UEFI
specification.
The first patch adds accessors for the register to ArmPkg,
the second fixes the error in ArmPlatofrmPkg.
They are in different packages, but dependent.
As the responsible adults involved are the same, I hope that is
acceptable.

The code can be examined at:
https://github.com/EvanLloyd/tianocore/tree/initialize_cnthctl_v1


Sami Mujawar (2):
  ArmPkg: Add CNTHCTL_EL2 support functions
  ArmPlatformPkg: Timer access for non-secure EL1/0

 ArmPkg/Include/Chipset/AArch64.h   | 12 +++-
 ArmPlatformPkg/PrePi/AArch64/ArchPrePi.c   |  9 -
 ArmPkg/Library/ArmLib/AArch64/AArch64Support.S | 10 ++
 ArmPlatformPkg/PrePeiCore/AArch64/Helper.S |  9 -
 4 files changed, 37 insertions(+), 3 deletions(-)

-- 
Guid("CE165669-3EF3-493F-B85D-6190EE5B9759")

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

[edk2] [PATCH 1/2] ArmPkg: Add CNTHCTL_EL2 support functions

2017-05-16 Thread evan . lloyd

From: Sami Mujawar 

Added helper functions for reading and writing the
CNTHCTL_EL2 register.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Sami Mujawar 
Signed-off-by: Evan Lloyd 
---
 ArmPkg/Include/Chipset/AArch64.h   | 12 +++-
 ArmPkg/Library/ArmLib/AArch64/AArch64Support.S | 10 ++
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/ArmPkg/Include/Chipset/AArch64.h b/ArmPkg/Include/Chipset/AArch64.h
index 
cebfc5da426a44bb97505ed9c1da3b2b2e35a0cc..76c2cc735ef3196273b28c7a804048d8e1f6d123
 100644
--- a/ArmPkg/Include/Chipset/AArch64.h
+++ b/ArmPkg/Include/Chipset/AArch64.h
@@ -1,7 +1,7 @@
 /** @file
 
   Copyright (c) 2008 - 2009, Apple Inc. All rights reserved.
-  Copyright (c) 2011 - 2015, ARM Ltd. All rights reserved.
+  Copyright (c) 2011 - 2017, ARM Ltd. All rights reserved.
 
   This program and the accompanying materials
   are licensed and made available under the terms and conditions of the BSD 
License
@@ -235,4 +235,14 @@ ArmWriteCptr (
   IN  UINT64 Cptr
   );
 
+UINT32
+ArmReadCntHctl (
+  VOID
+  );
+
+VOID
+ArmWriteCntHctl (
+  IN UINT32 CntHctl
+  );
+
 #endif // __AARCH64_H__
diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S 
b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
index 
6e8074a4868979d2fa3b850e1e588862179f829a..dde6a756528f3abf1bd5a142448e42122a9bd8fa
 100644
--- a/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
+++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Support.S
@@ -480,4 +480,14 @@ ASM_FUNC(ArmReadCurrentEL)
   mrs   x0, CurrentEL
   ret
 
+// UINT32 ArmReadCntHctl(VOID)
+ASM_FUNC(ArmReadCntHctl)
+  mrs   x0, cnthctl_el2
+  ret
+
+// VOID ArmWriteCntHctl(UINT32 CntHctl)
+ASM_FUNC(ArmWriteCntHctl)
+  msr   cnthctl_el2, x0
+  ret
+
 ASM_FUNCTION_REMOVE_IF_UNREFERENCED
-- 
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][edk2-platforms/devel-MinnowBoard3-UDK2017] Update GenBiosId

2017-05-16 Thread Lu, ShifeiX A

Reviewed-by: lushifex 


Shifei

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of zwei4
Sent: Tuesday, May 16, 2017 4:41 PM
To: edk2-devel@lists.01.org
Subject: [edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Update 
GenBiosId

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: zwei4 
---
 Platform/BroxtonPlatformPkg/BuildBios.sh|  12 
 .../Common/Tools/GenBiosId/GenBiosId| Bin 12236 -> 36128 bytes
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/Platform/BroxtonPlatformPkg/BuildBios.sh 
b/Platform/BroxtonPlatformPkg/BuildBios.sh
index 88ea12f8c..cadffc70d 100644
--- a/Platform/BroxtonPlatformPkg/BuildBios.sh
+++ b/Platform/BroxtonPlatformPkg/BuildBios.sh
@@ -271,10 +271,6 @@ cp -f 
$WORKSPACE/Silicon/BroxtonSoC/BroxtonFspPkg/ApolloLakeFspBinPkg/FspBin/FSP
 cp -f 
$WORKSPACE/Silicon/BroxtonSoC/BroxtonFspPkg/ApolloLakeFspBinPkg/FspBin/FSP_M.Fv 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 cp -f 
$WORKSPACE/Silicon/BroxtonSoC/BroxtonFspPkg/ApolloLakeFspBinPkg/FspBin/FSP_S.Fv 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 
-
-grep "_PCD_VALUE_" 
$BUILD_PATH/IA32/BroxtonPlatformPkg/PlatformPei/PlatformPei/DEBUG/AutoGen.h > 
FlashMap.h
-
-
 #echo "Running fce..."
 ## Extract Hii data from build and store in HiiDefaultData.txt  #wine 
PlatformTools/FCE/FCE.exe read -i $BUILD_PATH/FV/SOC.fd > 
$BUILD_PATH/FV/HiiDefaultData.txt 1>>EDK2.log 2>&1 @@ -292,7 +288,7 @@ cp 
$BUILD_PATH/FV/SOC.fd $BUILD_PATH/FV/Bxt"$Arch".fd  VERSION_MAJOR=$(grep 
'^VERSION_MAJOR' Conf/BiosId.env | cut -d ' ' -f 3 | cut -c 1-4)  
VERSION_MINOR=$(grep '^VERSION_MINOR' Conf/BiosId.env | cut -d ' ' -f 3 | cut 
-c 1-2)  
BIOS_Name="$BOARD_ID""$SV_String""$Arch"_"$BUILD_TYPE"_"$VERSION_MAJOR"_"$VERSION_MINOR"
-cp -f $BUILD_PATH/FV/Bxt"$Arch".fd  
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch/$BIOS_Name.ROM
+
 cp -f $BUILD_PATH/FV/FVOBB.Fv  
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 cp -f $BUILD_PATH/FV/FVOBBX.Fv 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 cp -f $BUILD_PATH/FV/FVIBBR.Fv 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
@@ -302,7 +298,7 @@ cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/B_Stepping/Spi
 cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/B_Stepping/SpiChunk2.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/B_Stepping/SpiChunk3.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/B_Stepping/GCC/NvStorage.Fv
 $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
-cp FlashMap.h $WORKSPACE/$BIOS_Name.map
+
 
 
 #
@@ -316,12 +312,12 @@ cat FVIBBM.Fv FSP_M.Fv > IBB.Fv
 
 cat FSP_S.Fv FVIBBR.Fv FVOBB.Fv FVOBBX.Fv > OBB.Fv
 
-cat SpiChunk1.bin IBBL.Fv IBB.Fv SpiChunk2.bin OBB.Fv NvStorage.Fv 
SpiChunk3.bin > MINNOWV3.X64.0063.IFWI.SPI.bin
+cat SpiChunk1.bin IBBL.Fv IBB.Fv SpiChunk2.bin OBB.Fv NvStorage.Fv 
+SpiChunk3.bin > $BIOS_Name"_GCC".bin
 
 popd
 
 echo
-echo SPI IFWI location: 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch/MINNOWV3.X64.0063.IFWI.SPI.bin
+echo SPI IFWI location: 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch/$BIOS_Name"_GCC".bin
 echo
 echo  The EDKII BIOS build has successfully completed. 
  echo diff --git 
a/Platform/BroxtonPlatformPkg/Common/Tools/GenBiosId/GenBiosId 
b/Platform/BroxtonPlatformPkg/Common/Tools/GenBiosId/GenBiosId
index 
ef1578f2bcb8922905e0693035245c4329809aa7..dc9f28554594043fb2e981e96601f2851d19bb91
 100755 GIT binary patch literal 36128 
zcmdUY3w%`7)$cwtd7L3(CLsX=NEjXwup}fr!%HV2feA*4knm7(@|uv;WG0=N@DR~x
zK#hpS*0!{@gxcC#TU)Aa1zI6KuF}@F=(W~rzfZmvYf`GkN0nMN_rLbp>&(f?1pD2u
zzx(^$4RiKdYp>T{`*B`-pWIYlxx%4of|EmBDhNB5?vo_rD8!*Ii7HyLa0#EdSWFcu
zpd{nxlO>cJ5a;KWYR+}V=R}@_U$Mg=6gzwp;QS(kEI4NmDJOgJZ*
zl*wZ}CtgZbuf-Y(_KlY)a-Re^ztbQK$eFGyo(p9es(XrKsrqrQP%*o;
zrGCM@*{zNFtu3LB?fKh_7vwLPR}c*s%#rmb{lvR+b@6!kW=~P%YU
z`>zP0sxdfBii16A$Sy>!oE#8c1U1#5=ib5IQ8?0?Mc%R3RQ5hJNKR

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Update GenBiosId

2017-05-16 Thread zwei4

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: zwei4 
---
 Platform/BroxtonPlatformPkg/BuildBios.sh|  12 
 .../Common/Tools/GenBiosId/GenBiosId| Bin 12236 -> 36128 bytes
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/Platform/BroxtonPlatformPkg/BuildBios.sh 
b/Platform/BroxtonPlatformPkg/BuildBios.sh
index 88ea12f8c..cadffc70d 100644
--- a/Platform/BroxtonPlatformPkg/BuildBios.sh
+++ b/Platform/BroxtonPlatformPkg/BuildBios.sh
@@ -271,10 +271,6 @@ cp -f 
$WORKSPACE/Silicon/BroxtonSoC/BroxtonFspPkg/ApolloLakeFspBinPkg/FspBin/FSP
 cp -f 
$WORKSPACE/Silicon/BroxtonSoC/BroxtonFspPkg/ApolloLakeFspBinPkg/FspBin/FSP_M.Fv 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 cp -f 
$WORKSPACE/Silicon/BroxtonSoC/BroxtonFspPkg/ApolloLakeFspBinPkg/FspBin/FSP_S.Fv 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 
-
-grep "_PCD_VALUE_" 
$BUILD_PATH/IA32/BroxtonPlatformPkg/PlatformPei/PlatformPei/DEBUG/AutoGen.h > 
FlashMap.h
-
-
 #echo "Running fce..."
 ## Extract Hii data from build and store in HiiDefaultData.txt
 #wine PlatformTools/FCE/FCE.exe read -i $BUILD_PATH/FV/SOC.fd > 
$BUILD_PATH/FV/HiiDefaultData.txt 1>>EDK2.log 2>&1
@@ -292,7 +288,7 @@ cp $BUILD_PATH/FV/SOC.fd $BUILD_PATH/FV/Bxt"$Arch".fd
 VERSION_MAJOR=$(grep '^VERSION_MAJOR' Conf/BiosId.env | cut -d ' ' -f 3 | cut 
-c 1-4)
 VERSION_MINOR=$(grep '^VERSION_MINOR' Conf/BiosId.env | cut -d ' ' -f 3 | cut 
-c 1-2)
 
BIOS_Name="$BOARD_ID""$SV_String""$Arch"_"$BUILD_TYPE"_"$VERSION_MAJOR"_"$VERSION_MINOR"
-cp -f $BUILD_PATH/FV/Bxt"$Arch".fd  
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch/$BIOS_Name.ROM
+
 cp -f $BUILD_PATH/FV/FVOBB.Fv  
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 cp -f $BUILD_PATH/FV/FVOBBX.Fv 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 cp -f $BUILD_PATH/FV/FVIBBR.Fv 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
@@ -302,7 +298,7 @@ cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/B_Stepping/Spi
 cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/B_Stepping/SpiChunk2.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/B_Stepping/SpiChunk3.bin
  $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
 cp -f 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Binaries/IFWI/B_Stepping/GCC/NvStorage.Fv
 $WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
-cp FlashMap.h $WORKSPACE/$BIOS_Name.map
+
 
 
 #
@@ -316,12 +312,12 @@ cat FVIBBM.Fv FSP_M.Fv > IBB.Fv
 
 cat FSP_S.Fv FVIBBR.Fv FVOBB.Fv FVOBBX.Fv > OBB.Fv
 
-cat SpiChunk1.bin IBBL.Fv IBB.Fv SpiChunk2.bin OBB.Fv NvStorage.Fv 
SpiChunk3.bin > MINNOWV3.X64.0063.IFWI.SPI.bin
+cat SpiChunk1.bin IBBL.Fv IBB.Fv SpiChunk2.bin OBB.Fv NvStorage.Fv 
SpiChunk3.bin > $BIOS_Name"_GCC".bin
 
 popd
 
 echo
-echo SPI IFWI location: 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch/MINNOWV3.X64.0063.IFWI.SPI.bin
+echo SPI IFWI location: 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch/$BIOS_Name"_GCC".bin
 echo
 echo  The EDKII BIOS build has successfully completed. 

 echo
diff --git a/Platform/BroxtonPlatformPkg/Common/Tools/GenBiosId/GenBiosId 
b/Platform/BroxtonPlatformPkg/Common/Tools/GenBiosId/GenBiosId
index 
ef1578f2bcb8922905e0693035245c4329809aa7..dc9f28554594043fb2e981e96601f2851d19bb91
 100755
GIT binary patch
literal 36128
zcmdUY3w%`7)$cwtd7L3(CLsX=NEjXwup}fr!%HV2feA*4knm7(@|uv;WG0=N@DR~x
zK#hpS*0!{@gxcC#TU)Aa1zI6KuF}@F=(W~rzfZmvYf`GkN0nMN_rLbp>&(f?1pD2u
zzx(^$4RiKdYp>T{`*B`-pWIYlxx%4of|EmBDhNB5?vo_rD8!*Ii7HyLa0#EdSWFcu
zpd{nxlO>cJ5a;KWYR+}V=R}@_U$Mg=6gzwp;QS(kEI4NmDJOgJZ*
zl*wZ}CtgZbuf-Y(_KlY)a-Re^ztbQK$eFGyo(p9es(XrKsrqrQP%*o;
zrGCM@*{zNFtu3LB?fKh_7vwLPR}c*s%#rmb{lvR+b@6!kW=~P%YU
z`>zP0sxdfBii16A$Sy>!oE#8c1U1#5=ib5IQ8?0?Mc%R3RQ5hJNKR

Re: [edk2] [PATCH] MdePkg/BaseLib: Fix PathRemoveLastItem to ignore consecutive '\'

2017-05-16 Thread Ni, Ruiyu

Jeff,
PathRemoveLastItem() is expected to be called after PathCleanUpDirectories().
E.g.: what should we expect PathRemoveLastItem() do for "fs0:\a\b\..\"?
So PathRemoveLastItem() expects the incoming path is cleaned.

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Jeff Westfahl
> Sent: Saturday, May 13, 2017 12:01 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Ni, Ruiyu
> ; Carsey, Jaben ; Gao, Liming
> 
> Subject: [edk2] [PATCH] MdePkg/BaseLib: Fix PathRemoveLastItem to ignore
> consecutive '\'
> 
> This patch makes PathRemoveLastItem ignore consecutive occurrences of
> the '\' path separator.
> 
> Consider a path like "FS0:\ABC\DEF\\", noting the consecutive '\' path
> separator characters at the end. The expected result of
> PathRemoveLastItem on such a path is "FS0:\ABC\". However, what we get is
> "FS0:\ABC\DEF\".
> 
> We can see the result of this behavior with 'ls' in the EFI shell. Go a 
> couple of
> folders deep into a filesystem and try 'ls ..\..'. Here's an example, with a
> filesystem with folder ABC in the root, with subfolder DEF.
> 
> FS0:\ABC\DEF\> ls ..
> Directory of: FS0:\ABC\
> 05/12/2017  15:46  8,192  .
> 05/12/2017  15:46  0  ..
> 05/12/2017  15:46  8,192  DEF
>   0 File(s)   0 bytes
>   3 Dir(s)
> FS0:\ABC\DEF\> ls ..\..
> Directory of: FS0:\ABC\
> 05/12/2017  15:46  8,192  .
> 05/12/2017  15:46  0  ..
> 05/12/2017  15:46  8,192  DEF
>   0 File(s)   0 bytes
>   3 Dir(s)
> fs0:\ABC\DEF\>
> 
> As you can see, 'ls ..\..' lists only the parent folder. This patch resolves 
> the
> issue so that 'ls ..\..' lists the grandparent folder.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Ruiyu Ni 
> Cc: Jaben Carsey 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jeff Westfahl 
> ---
>  MdePkg/Library/BaseLib/FilePaths.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/MdePkg/Library/BaseLib/FilePaths.c
> b/MdePkg/Library/BaseLib/FilePaths.c
> index 203045c..bbaf140 100644
> --- a/MdePkg/Library/BaseLib/FilePaths.c
> +++ b/MdePkg/Library/BaseLib/FilePaths.c
> @@ -37,9 +37,7 @@ PathRemoveLastItem(
>; Walker != NULL && *Walker != CHAR_NULL
>; Walker++
>   ){
> -if (*Walker == L'\\' && *(Walker + 1) != CHAR_NULL) {
> -  LastSlash = Walker+1;
> -} else if (*Walker == L':' && *(Walker + 1) != L'\\' && *(Walker + 1) !=
> CHAR_NULL) {
> +if ((*Walker == L'\\' || *Walker == L':') && *(Walker + 1) != L'\\'
> + && *(Walker + 1) != CHAR_NULL) {
>LastSlash = Walker+1;
>  }
>}
> --
> 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

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] GCC build script change.

2017-05-16 Thread zwei4

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: zwei4 
---
 BuildBIOS.sh |  8 ++-
 Platform/BroxtonPlatformPkg/BuildBios.sh | 86 
 Platform/BroxtonPlatformPkg/BuildIFWI.sh |  4 +-
 3 files changed, 52 insertions(+), 46 deletions(-)

diff --git a/BuildBIOS.sh b/BuildBIOS.sh
index 49a9e1b12..0dece1f77 100755
--- a/BuildBIOS.sh
+++ b/BuildBIOS.sh
@@ -8,6 +8,12 @@
 # THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
 # WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 #
+Target_Flag=Release
+if [ "$1" == "Debug" ]; then
+  Target_Flag=Debug
+fi
+
+echo $Target_Flag
 
 export WORKSPACE=`pwd`
 export 
PACKAGES_PATH=$WORKSPACE:$WORKSPACE/Core:$WORKSPACE/Silicon/:$WORKSPACE/Platform:$WORKSPACE/Platform/BroxtonPlatformPkg:$WORKSPACE/Silicon/BroxtonSoC:$WORKSPACE/Platform/BroxtonPlatformPkg/Common
@@ -16,5 +22,5 @@ export 
PACKAGES_PATH=$WORKSPACE:$WORKSPACE/Core:$WORKSPACE/Silicon/:$WORKSPACE/P
 
 make -C BaseTools
 
-./Platform/BroxtonPlatformPkg/BuildIFWI.sh APLI Release
+. ./Platform/BroxtonPlatformPkg/BuildIFWI.sh APLI $Target_Flag
 
diff --git a/Platform/BroxtonPlatformPkg/BuildBios.sh 
b/Platform/BroxtonPlatformPkg/BuildBios.sh
index 3963c887a..88ea12f8c 100644
--- a/Platform/BroxtonPlatformPkg/BuildBios.sh
+++ b/Platform/BroxtonPlatformPkg/BuildBios.sh
@@ -76,19 +76,9 @@ cp $WORKSPACE/BaseTools/Conf/tools_def.template 
$WORKSPACE/Conf/tools_def.txt
 cp $WORKSPACE/BaseTools/Conf/build_rule.template $WORKSPACE/Conf/build_rule.txt
 
 
-## Get gcc version to determine which tool_def.template to use.
-## If gcc version is 4.6 or before, use default. If not, use new one.
-GCCVERSION=$(gcc --version | grep 'gcc' | grep '[0-9]' | cut -d ' ' -f 4 | cut 
-d '.' -f 2)
-if (($GCCVERSION > 6)); then
-  echo "GCC version is 4.7 or after"
-  TOOL_CHAIN_TAG=GCC47
-else
-  echo "Type 'gcc --version' to check version"
-  echo "Please update GCC version to 4.7 or later"
-  ErrorExit
-fi
 
-#make -C BaseTools > /dev/null
+
+TOOL_CHAIN_TAG=GCC5
 
 ## Define platform specific environment variables.
 PLATFORM_NAME=BroxtonPlatformPkg
@@ -268,28 +258,32 @@ build $Build_Flags
 ##**
 ## Post Build processing and cleanup
 ##**
+
+#
+# FSP Rebase and Split
+#
+#   0xFEF7A000 = gIntelFsp2WrapperTokenSpaceGuid.PcdFlashFvFspBase = 
$(CAR_BASE_ADDRESS) + $(BLD_RAM_DATA_SIZE) + $(FSP_RAM_DATA_SIZE) + 
$(FSP_EMP_DATA_SIZE) + $(BLD_IBBM_SIZE)
+pushd  $WORKSPACE/Silicon/BroxtonSoC/BroxtonFspPkg/ApolloLakeFspBinPkg/FspBin
+python $WORKSPACE/Core/IntelFsp2Pkg/Tools/SplitFspBin.py rebase -f 
ApolloLakeFsp.fd -c m -b 0xFEF7A000 -o ./ -n FSP.fd
+python $WORKSPACE/Core/IntelFsp2Pkg/Tools/SplitFspBin.py split -f FSP.fd -o ./ 
-n FSP.Fv
+popd
+cp -f 
$WORKSPACE/Silicon/BroxtonSoC/BroxtonFspPkg/ApolloLakeFspBinPkg/FspBin/FSP_T.Fv 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
+cp -f 
$WORKSPACE/Silicon/BroxtonSoC/BroxtonFspPkg/ApolloLakeFspBinPkg/FspBin/FSP_M.Fv 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
+cp -f 
$WORKSPACE/Silicon/BroxtonSoC/BroxtonFspPkg/ApolloLakeFspBinPkg/FspBin/FSP_S.Fv 
$WORKSPACE/Platform/BroxtonPlatformPkg/Common/Tools/Stitch
+
+
 grep "_PCD_VALUE_" 
$BUILD_PATH/IA32/BroxtonPlatformPkg/PlatformPei/PlatformPei/DEBUG/AutoGen.h > 
FlashMap.h
 
+
 #echo "Running fce..."
 ## Extract Hii data from build and store in HiiDefaultData.txt
 #wine PlatformTools/FCE/FCE.exe read -i $BUILD_PATH/FV/SOC.fd > 
$BUILD_PATH/FV/HiiDefaultData.txt 1>>EDK2.log 2>&1
 
 ## copy the Setup variable to the SetupDefault variable and save changes to 
BxtXXX.fd
 #wine PlatformTools/FCE/FCE.exe mirror -i $BUILD_PATH/FV/SOC.fd -o 
$BUILD_PATH/FV/Bxt"$Arch".fd Setup SetupDefault 1>>EDK2.log 2>&1
-echo "Skip FCE tool..."
+#echo "Skip FCE tool..."
 cp $BUILD_PATH/FV/SOC.fd $BUILD_PATH/FV/Bxt"$Arch".fd
 
-##echo Running KeyEnroll...
-## RestrictedBegin
-##if /i not "$Platform_Type" == "$eNB_RVP" (
-##   call $PLATFORM_PACKAGE/Restricted/Internal/Tools/KeyEnroll/KeyEnroll.bat  
$BUILD_PATH  $BUILD_PATH/FV/Vlv"$Arch".fd 1>>EDK2.log 2>&1
-##) else if /i "$Platform_Type" == "$eNB_RVP" (
-##   call 
$PLATFORM_PACKAGE/Restricted/Internal/Tools/KeyEnroll/BBAY-KeyEnroll.bat  
$BUILD_PATH  $BUILD_PATH/FV/Vlv"$Arch".fd 1>>EDK2.log 2>&1
-##)
-##   if %ERRORLEVEL% NEQ 0 goto BldFail
-## RestrictedEnd
-echo Skip "KeyEnroll tool..."
-
 ## Set the Board_Id, Build_Type, Version_Major, and Version_Minor environment 
variables
 ##find /v "#" Conf\BiosId.env > ver_strings
 ##for /f "tokens=1,3" %%i in (ver_strings) do set %%i=%%j
@@ -298,28 +292,36 @@ echo Skip "KeyEnroll tool..."
 VERSION_MAJOR=$(grep '^VERSION_MAJOR' Conf/BiosId.env | cut -d ' ' -f 3 | cut 
-c 1-4)
 VERSION_MINOR=$(grep '^VERSION_MINOR' Conf/BiosId.env | cut -d ' ' -f 3 | cut 
-c 1-2)

Re: [edk2] Can I do this in an INF file?

Re: [edk2] Can I do this in an INF file?

Re: [edk2] Can I do this in an INF file?

Re: [edk2] [RFC] PCD: Database size optimization for multi-SKU

[edk2] Can I do this in an INF file?

Re: [edk2] [RFC v4 06/13] OvmfPkg:AmdSevDxe: add AmdSevDxe driver

Re: [edk2] [RFC] PCD: Database size optimization for multi-SKU

Re: [edk2] [RFC v4 06/13] OvmfPkg:AmdSevDxe: add AmdSevDxe driver

Re: [edk2] [PATCH] MdePkg/BaseLib: Fix PathRemoveLastItem to ignore consecutive '\'

[edk2] [RFC] PCD: Database size optimization for multi-SKU

[edk2] How to look up ACPI device node from DXE driver

Re: [edk2] [PATCH] MdePkg: Fix undefined behavior on variadic parameters

Re: [edk2] [RFC v4 06/13] OvmfPkg:AmdSevDxe: add AmdSevDxe driver

[edk2] [PATCH 2/2] ArmPlatformPkg: Timer access for non-secure EL1/0

[edk2] [PATCH 0/2] Initialize CNTHCTL

[edk2] [PATCH 1/2] ArmPkg: Add CNTHCTL_EL2 support functions

Re: [edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Update GenBiosId

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] Update GenBiosId

Re: [edk2] [PATCH] MdePkg/BaseLib: Fix PathRemoveLastItem to ignore consecutive '\'

[edk2] [Patch][edk2-platforms/devel-MinnowBoard3-UDK2017] GCC build script change.

20 matches

Site Navigation

Mail list logo

Footer information