Re: [edk2] Cross compiling EDK2 for Aarch64

[Leif Lindholm]

Hi Yehuda,

On Thu, Oct 08, 2015 at 08:24:07AM +, Yehuda Yitschak wrote:
> I am new to the EDK2 projects and for starters I am trying to cross
> compile the project for aarch64 on an x86_64 host
> 
> I looked around in Linaro website and Tiano-core website but
> couldn't find any instruction on how to _cross_ compile
> 
> I tried to follow the instruction here:
> https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/build
>
> but when I try to compile using the "build" command the build script
> uses the x86 compiler and naturally it fails

Any particular reason why you skipped past the first half of the page
to follow the instructions under the headline "The Hard Way"?

> I tried working around this by setting the environment variable
> GCC48_BIN however then the build system tries to call "make" from
> the path in GCC48_BIN which off course fails

This doesn't make sense.

Can you please provide some information on the actual steps you have
attempted, and the exact error output that yielded,  in order for us
to be able to help?

Regards,

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

[edk2] [PATCH] MdeModulePkg PiDxeS3BootScriptLib: Use PcdSet64S to instead of PcdSet64

[Star Zeng]

PcdSet## has no error status returned, then the caller has no idea about 
whether the set operation is successful or not.
PcdSet##S were added to return error status and PcdSet## APIs were put in 
ifndef DISABLE_NEW_DEPRECATED_INTERFACES condition.
To adopt PcdSet##S and further code development with 
DISABLE_NEW_DEPRECATED_INTERFACES defined, we need to Replace PcdSet## usage 
with PcdSet##S.

Normally, DynamicDefault PCD set is expected to be success, but DynamicHii PCD 
set failure is a legal case.
For this case, PcdS3BootScriptTablePrivateDataPtr and 
PcdS3BootScriptTablePrivateSmmDataPtr are expected to be DynamicDefault,
so use PcdSet64S to instead of PcdSet64 and assert when set failure.

Cc: Jiewen Yao 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c 
b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
index 24c6798..e7d2a24 100644
--- a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
+++ b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
@@ -454,7 +454,8 @@ S3BootScriptLibInitialize (
 }
 S3TablePtr = (VOID *) (UINTN) Buffer;
 
-PcdSet64 (PcdS3BootScriptTablePrivateDataPtr, (UINT64) (UINTN)S3TablePtr); 
+Status = PcdSet64S (PcdS3BootScriptTablePrivateDataPtr, (UINT64) 
(UINTN)S3TablePtr);
+ASSERT_EFI_ERROR (Status);
 ZeroMem (S3TablePtr, sizeof(SCRIPT_TABLE_PRIVATE_DATA));  
 //
 // Create event to notify the library system enter the SmmLocked phase.
@@ -506,7 +507,8 @@ S3BootScriptLibInitialize (
   return RETURN_OUT_OF_RESOURCES;
 }
 
-PcdSet64 (PcdS3BootScriptTablePrivateSmmDataPtr, (UINT64) 
(UINTN)S3TableSmmPtr);
+Status = PcdSet64S (PcdS3BootScriptTablePrivateSmmDataPtr, (UINT64) 
(UINTN)S3TableSmmPtr);
+ASSERT_EFI_ERROR (Status);
 ZeroMem (S3TableSmmPtr, sizeof(SCRIPT_TABLE_PRIVATE_DATA));
 
 //
-- 
1.9.5.msysgit.0

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

Re: [edk2] [PATCH] MdeModulePkg PiDxeS3BootScriptLib: Use PcdSet64S to instead of PcdSet64

[Yao, Jiewen]

Looks good.

-Original Message-
From: Zeng, Star 
Sent: Thursday, October 08, 2015 3:40 PM
To: edk2-devel@lists.01.org
Cc: Yao, Jiewen; Gao, Liming
Subject: [PATCH] MdeModulePkg PiDxeS3BootScriptLib: Use PcdSet64S to instead of 
PcdSet64

PcdSet## has no error status returned, then the caller has no idea about 
whether the set operation is successful or not.
PcdSet##S were added to return error status and PcdSet## APIs were put in 
ifndef DISABLE_NEW_DEPRECATED_INTERFACES condition.
To adopt PcdSet##S and further code development with 
DISABLE_NEW_DEPRECATED_INTERFACES defined, we need to Replace PcdSet## usage 
with PcdSet##S.

Normally, DynamicDefault PCD set is expected to be success, but DynamicHii PCD 
set failure is a legal case.
For this case, PcdS3BootScriptTablePrivateDataPtr and 
PcdS3BootScriptTablePrivateSmmDataPtr are expected to be DynamicDefault, so use 
PcdSet64S to instead of PcdSet64 and assert when set failure.

Cc: Jiewen Yao 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c 
b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
index 24c6798..e7d2a24 100644
--- a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
+++ b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
@@ -454,7 +454,8 @@ S3BootScriptLibInitialize (
 }
 S3TablePtr = (VOID *) (UINTN) Buffer;
 
-PcdSet64 (PcdS3BootScriptTablePrivateDataPtr, (UINT64) (UINTN)S3TablePtr); 
+Status = PcdSet64S (PcdS3BootScriptTablePrivateDataPtr, (UINT64) 
(UINTN)S3TablePtr);
+ASSERT_EFI_ERROR (Status);
 ZeroMem (S3TablePtr, sizeof(SCRIPT_TABLE_PRIVATE_DATA));  
 //
 // Create event to notify the library system enter the SmmLocked phase.
@@ -506,7 +507,8 @@ S3BootScriptLibInitialize (
   return RETURN_OUT_OF_RESOURCES;
 }
 
-PcdSet64 (PcdS3BootScriptTablePrivateSmmDataPtr, (UINT64) 
(UINTN)S3TableSmmPtr);
+Status = PcdSet64S (PcdS3BootScriptTablePrivateSmmDataPtr, (UINT64) 
(UINTN)S3TableSmmPtr);
+ASSERT_EFI_ERROR (Status);
 ZeroMem (S3TableSmmPtr, sizeof(SCRIPT_TABLE_PRIVATE_DATA));
 
 //
--
1.9.5.msysgit.0

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

[edk2] Cross compiling EDK2 for Aarch64

[Yehuda Yitschak]

Hello everyone

I am new to the EDK2 projects and for starters I am trying to cross compile the 
project for aarch64 on an x86_64 host

I looked around in Linaro website and Tiano-core website but couldn't find any 
instruction on how to _cross_ compile

I tried to follow the instruction here: 
https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/build
but when I try to compile using the "build" command the build script uses the 
x86 compiler and naturally it fails
I tried working around this by setting the environment variable GCC48_BIN 
however then the build system tries to call "make" from the path in GCC48_BIN 
which off course fails

I also found these instructions 
https://github.com/tianocore/tianocore.github.io/wiki/Unix-like_systems#Build_gcc_x64_UEFI_cross_compiler
But I'm not sure they apply to aarch64.

I appreciate any suggestions you can offer

Thanks in advance

---
Yehuda Yitschak
Marvell Semiconductor Ltd.

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

Re: [edk2] [PATCH 7/7] UefiCpuPkg: Add missing UefiCpuPkgTokenSpace include

[Laszlo Ersek]

On 10/07/15 23:11, Kinney, Michael D wrote:
> Laszlo,
> 
> Good question.  
> 
> It is a good practice to have the .h file for each GUID.  The .h file 
> contains the extern for the global variable associated with the GUID along 
> with data structures associated with the GUID.
> 
> For PCD token space GUIDs, there is no data structure and the AutoGen.h file 
> contains an extern to all token space GUIDs a module references, so the .h 
> file for the token space GUID is not required.
> 
> The C name for a Token space GUID (i.e. gUefiCpuPkgTokenSpaceGuid) would be 
> required in C code if the PcdLib PcdGetEx8 (),PcdGetEx16 (),PcdGetEx32 
> (),PcdGetEx64 (),PcdGetExBool (),or PcdGetExPtr () APIs are used.  Most 
> modules/libs do not use the 'Ex' versions of these, so it is very rare for a 
> module to use the C name for a Token space GUID.
> 
> I will remove the UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h from the 
> patch set.

Thank you for explaining me the PcdGetEx__() family of functions at the
same time :) I've been wondering about both them, and how one could
resolve token name collisions between different token spaces.
Apparently, with the Ex family (but it remains unnecessary in practice).

Thank you!
Laszlo

> 
> Thanks,
> 
> Mike
> 
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com] 
> Sent: Wednesday, October 07, 2015 10:38 AM
> To: Kinney, Michael D; edk2-de...@ml01.01.org
> Subject: Re: [edk2] [PATCH 7/7] UefiCpuPkg: Add missing UefiCpuPkgTokenSpace 
> include
> 
> On 10/05/15 01:57, Michael Kinney wrote:
>> Add missing include files for the token space GUID for the UefiCpuPkg
>> Add path to the token space include file to the UefiCpuPkg DEC file.
> 
> Is this usual? For example, gUefiOvmfPkgTokenSpaceGuid is also not
> defined anywhere else than in the DEC file.
> 
> What could a programmer use UEFICPUPKG_TOKEN_SPACE_GUID /
> gUefiCpuPkgTokenSpaceGuid for, in C source code?
> 
> ... Only the following packages / header files seem to expose their
> respective token space GUIDs in a similar way:
> 
> MdeModulePkg/Include/Guid/MdeModulePkgTokenSpace.h
> MdePkg/Include/Guid/MdePkgTokenSpace.h
> PcAtChipsetPkg/Include/Guid/PcAtChipsetTokenSpace.h
> PerformancePkg/Include/Guid/PerformancePkgTokenSpace.h
> SecurityPkg/Include/Guid/SecurityPkgTokenSpace.h
> ShellPkg/Include/Guid/ShellPkgTokenSpace.h
> Vlv2DeviceRefCodePkg/Include/Guid/Vlv2DeviceRefCodePkgTokenSpace.h
> 
> Thanks!
> Laszlo
> 
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Michael Kinney 
>> ---
>>  UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h | 25 
>> +
>>  UefiCpuPkg/UefiCpuPkg.dec  |  1 +
>>  2 files changed, 26 insertions(+)
>>  create mode 100644 UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
>>
>> diff --git a/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h 
>> b/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
>> new file mode 100644
>> index 000..6c4e671
>> --- /dev/null
>> +++ b/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
>> @@ -0,0 +1,25 @@
>> +/** @file
>> +GUID for UefiCpuPkg PCD Token Space
>> +
>> +Copyright (c) 2015, 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 _UEFICPUPKG_TOKEN_SPACE_GUID_H_
>> +#define _UEFICPUPKG_TOKEN_SPACE_GUID_H_
>> +
>> +#define UEFICPUPKG_TOKEN_SPACE_GUID \
>> +  { \
>> +0xac05bf33, 0x995a, 0x4ed4, { 0xaa, 0xb8, 0xef, 0x7a, 0xe8, 0xf, 0x5c, 
>> 0xb0 } \
>> +  }
>> +
>> +extern EFI_GUID gUefiCpuPkgTokenSpaceGuid;
>> +
>> +#endif
>> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
>> index e4b8030..e293390 100644
>> --- a/UefiCpuPkg/UefiCpuPkg.dec
>> +++ b/UefiCpuPkg/UefiCpuPkg.dec
>> @@ -51,6 +51,7 @@
>>SmmCpuFeaturesLib|Include/Library/SmmCpuFeaturesLib.h
>>  
>>  [Guids]
>> +  ## Include/Guid/UefiCpuPkgTokenSpace.h
>>gUefiCpuPkgTokenSpaceGuid  = { 0xac05bf33, 0x995a, 0x4ed4, { 0xaa, 
>> 0xb8, 0xef, 0x7a, 0xe8, 0xf, 0x5c, 0xb0 }}
>>  
>>  [Protocols]
>>
> 

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

Re: [edk2] Cross compiling EDK2 for Aarch64

[Leif Lindholm]

On Thu, Oct 08, 2015 at 10:04:24AM +, Yehuda Yitschak wrote:
> > > but when I try to compile using the "build" command the build script
> > > uses the x86 compiler and naturally it fails
> > 
> > Any particular reason why you skipped past the first half of the page to
> > follow the instructions under the headline "The Hard Way"?
> 
> 2 reasons.  I am unable to clone the uefi-tools git using "git clone 
> git://git.linaro.org/uefi/uefi-tools.git".  I get this output
>   Cloning into 'uefi-tools'...
>   fatal: unable to connect to git.linaro.org:
>   git.linaro.org[0: 54.247.55.40]: errno=Connection timed out
> maybe the GIT moved, or I have some permission issues ? 

Hmm, was one of our git mirrors temporarily down?
I just tested cloning from that IP, and it  works from here now.

If you have some firewall issues, maybe you could try with the http
protocol instead:
git clone http://git.linaro.org/uefi/uefi-tools.git

> Second, I wanted to get a better understanding of the build process

Fair enough.
I just found that bit tedious enough to hide it behind scripts :)

But one thing uefi-build.sh does is print the exact build command line
before building each platform, so it could still be useful for this.

> > > I tried working around this by setting the environment variable
> > > GCC48_BIN however then the build system tries to call "make" from the
> > > path in GCC48_BIN which off course fails
> > 
> > This doesn't make sense.
> > 
> > Can you please provide some information on the actual steps you have
> > attempted, and the exact error output that yielded,  in order for us to be
> > able to help?
> > 
> Following the "hard way" I perform these steps 
>   - git clone http://git.linaro.org/uefi/linaro-edk2.git
>   - cd linaro-edk2
>   - git checkout master
>   - . edksetup.sh
>   - make -C BaseTools
> Up to this point everything is working fine
> 
> When running 
>   "build -a ARM -b DEBUG -t GCC48 -p 
> ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-CTA5s.dsc -D 
> EDK2_ARMVE_STANDALONE=1" 
> I get an error saying the dsc file doesn't exist.

Yeah, we've dropped that platform, so should probably not be using it
in our command line example... My bad, I'll update wiki.

> I'm also interested in aarch64 so I changed the command to:
>   " build -a AARCH64 -b DEBUG -t GCC48 -p
>   ArmPlatformPkg/ArmVExpressPkg/ArmVExpress-FVP-AArch64.dsc -D
>   EDK2_ARMVE_STANDALONE=1"

Yes, when cross compiling you do need to point out which toolchain to use.
In my case, for the GCC48 profile, since I have the toolchain on my
PATH, I would do this by prepending
GCC48_AARCH64_PREFIX=aarch64-linux-gnu-
to the command line.

If it's not on your PATH, specify the full path (e.g. 
/usr/local/toolchains/linaro-aarch64/bin/aarch64-linux-gnu-).

> I don't have a aarch64 compiler installed properly using apt-get but
> I tried that before and that also didn't solve the problem

As long as you have an aarch64 toolchain installed somehow...

Regards,

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

Re: [edk2] [PATCH v3] Pkg-Module: Integrate new RngLib into RngDxe

[Kinney, Michael D]

LONG, Qin,

Do you know if the 10uS delay required in RdRandGetSeed128()?

Thanks,

Mike

>-Original Message-
>From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Long,
>Qin
>Sent: Wednesday, October 07, 2015 8:44 PM
>To: Justen, Jordan L; Thomas Palmer; edk2-devel@lists.01.org
>Subject: Re: [edk2] [PATCH v3] Pkg-Module: Integrate new RngLib into RngDxe
>
>Thomas,
>
>Thanks for doing this.
>I think it's better to separate your patch into two parts (one for MdePkg, and
>the other for SecurityPkg). Then you can CC me as Jordan's suggestion.
>
>
>Best Regards & Thanks,
>LONG, Qin
>
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
>> Jordan Justen
>> Sent: Thursday, October 08, 2015 11:36 AM
>> To: Thomas Palmer; edk2-devel@lists.01.org
>> Subject: Re: [edk2] [PATCH v3] Pkg-Module: Integrate new RngLib into
>> RngDxe
>>
>> In the subject line, 'Pkg-Module' should be something like 'MdePkg:'
>> or 'SecurityPkg/RandomNumberGenerator:'.
>>
>> On 2015-10-07 18:55:42, Thomas Palmer wrote:
>> > Use the new RngLib to provide the IA32/X64 random data for RngDxe.
>> > Remove x86 specific functions from RdRand files.
>> > Clean up files in RngDxe/IA32 and RngDxe/X64 that are subsumed by files
>> in BaseRngLib.
>> > Simplify RngDxe by using WriteUnaligned64 for both IA32 and X64
>> platforms.
>> > Create and use GetRandomNumber128 in RngDxe to leverage 128 bit
>> > support found in some HW RNG devices
>>
>> It sounds like you are doing about 5 things here. How about 5 patches?
>>
>> Each patch should only touch one package whenever possiable.
>>
>> Also, consider adding 'Cc:' near your Signed-off-by for the maintainers of a
>> package. (see Maintainers.txt)
>>
>> -Jordan
>>
>> > Contributed-under: TianoCore Contribution Agreement 1.0
>> > Signed-off-by: Thomas Palmer 
>> > ---
>> >  MdePkg/Include/Library/RngLib.h|   17 ++
>> >  MdePkg/Library/BaseRngLib/BaseRng.c|   32 +++
>> >  .../RngDxe/IA32/AsmRdRand.asm  |   67 -
>> >  .../RandomNumberGenerator/RngDxe/IA32/GccRdRand.c  |   69 --
>> >  .../RandomNumberGenerator/RngDxe/IA32/RdRandWord.c |  104 
>> > SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.c  |  256
>> > ++--
>> SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.h  |  151 +---
>> >  SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.c  |9 +-
>> >  .../RandomNumberGenerator/RngDxe/RngDxe.inf|   14 +-
>> >  .../RandomNumberGenerator/RngDxe/X64/AsmRdRand.asm |   83 ---
>> >  .../RandomNumberGenerator/RngDxe/X64/GccRdRand.c   |   95 
>> >  .../RandomNumberGenerator/RngDxe/X64/RdRandWord.c  |   70 --
>> >  SecurityPkg/SecurityPkg.dsc|3 +
>> >  13 files changed, 75 insertions(+), 895 deletions(-)  delete mode
>> > 100644
>> SecurityPkg/RandomNumberGenerator/RngDxe/IA32/AsmRdRand.asm
>> >  delete mode 100644
>> > SecurityPkg/RandomNumberGenerator/RngDxe/IA32/GccRdRand.c
>> >  delete mode 100644
>> > SecurityPkg/RandomNumberGenerator/RngDxe/IA32/RdRandWord.c
>> >  delete mode 100644
>> > SecurityPkg/RandomNumberGenerator/RngDxe/X64/AsmRdRand.asm
>> >  delete mode 100644
>> > SecurityPkg/RandomNumberGenerator/RngDxe/X64/GccRdRand.c
>> >  delete mode 100644
>> > SecurityPkg/RandomNumberGenerator/RngDxe/X64/RdRandWord.c
>> >
>> > diff --git a/MdePkg/Include/Library/RngLib.h
>> > b/MdePkg/Include/Library/RngLib.h index 157a931..ece4394 100644
>> > --- a/MdePkg/Include/Library/RngLib.h
>> > +++ b/MdePkg/Include/Library/RngLib.h
>> > @@ -66,4 +66,21 @@ GetRandomNumber64 (
>> >OUT UINT64*Rand
>> >);
>> >
>> > +/**
>> > +  Generates a 128-bit random number.
>> > +
>> > +  if Rand is NULL, then ASSERT().
>> > +
>> > +  @param[out] Rand Buffer pointer to store the 128-bit random value.
>> > +
>> > +  @retval TRUE Random number generated successfully.
>> > +  @retval FALSEFailed to generate the random number.
>> > +
>> > +**/
>> > +BOOLEAN
>> > +EFIAPI
>> > +GetRandomNumber128 (
>> > +  OUT UINT64*Rand
>> > +  );
>> > +
>> >  #endif  // __RNG_LIB_H__
>> > diff --git a/MdePkg/Library/BaseRngLib/BaseRng.c
>> > b/MdePkg/Library/BaseRngLib/BaseRng.c
>> > index 279df30..2c8df56 100644
>> > --- a/MdePkg/Library/BaseRngLib/BaseRng.c
>> > +++ b/MdePkg/Library/BaseRngLib/BaseRng.c
>> > @@ -155,3 +155,35 @@ GetRandomNumber64 (
>> >
>> >return FALSE;
>> >  }
>> > +
>> > +/**
>> > +  Generates a 128-bit random number.
>> > +
>> > +  if Rand is NULL, then ASSERT().
>> > +
>> > +  @param[out] Rand Buffer pointer to store the 128-bit random value.
>> > +
>> > +  @retval TRUE Random number generated successfully.
>> > +  @retval FALSEFailed to generate the random number.
>> > +
>> > +**/
>> > +BOOLEAN
>> > +EFIAPI
>> > +GetRandomNumber128 (
>> > +  OUT UINT64*Rand
>> > +  )

Re: [edk2] Support for UBI volumes and UBIFS?

[Welch, Brian J]

Hi Feng,

I have an embedded Linux system that currently uses eMMC storage and I am 
looking at modifying it to use a simple raw NAND-Flash controller instead.

The current system stores BIOS in the eMMC boot-partition.  The eMMC 
user-partition has a GPT with partitions defined for EFI (Fat32), OS kernel 
(raw), OS read-only filesystem (SquashFS), OS r/w filesystem (ext4).  The idea 
would be to move all of this onto a raw NAND device that is accessed via a raw 
NAND controller.

Since the raw NAND controller is simple, software is needed to perform 
wear-leveling, bad-block accounting, etc. which was previously done internally 
to the eMMC device.  I believe UBI can solve this by managing the raw NAND as 
UBI volumes.

Ideally, I would also like UEFI to be able to read and write the EFI partition 
for development purposes if nothing else.  I believe that I would need an 
additional software component to expose the UBI volume as a block device to 
support FAT32.  E.g., an FTL.

Brian


-Original Message-
From: Tian, Feng 
Sent: Wednesday, October 07, 2015 8:03 PM
To: Welch, Brian J; edk2-devel@lists.01.org
Cc: Tian, Feng
Subject: RE: Support for UBI volumes and UBIFS?

Hi, Brian

As far as I know, there is no changes on that.

Could you introduce further about your usage model? FAT32 for the first 
partition is not enough for boot?

Thanks
Feng

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Welch, 
Brian J
Sent: Tuesday, October 06, 2015 23:46
To: edk2-devel@lists.01.org
Subject: [edk2] Support for UBI volumes and UBIFS?

Hi,

I searched the list and the most recent topic I found was 10-months-old and 
said that no support for UBI/UBIFS was available at that time.

http://sourceforge.net/p/edk2/mailman/message/33144044/
That thread is similar to what I'm wanting to do, which is to have a raw flash 
device for boot which ideally would contain an EFI partition and at least one 
additional partition for the device's root filesystem.

I'm wondering if support/availability has changed since then.

Brian

___
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 7/7] UefiCpuPkg: Add missing UefiCpuPkgTokenSpace include

[Andrew Fish]

> On Oct 8, 2015, at 4:22 AM, Laszlo Ersek  wrote:
> 
> On 10/07/15 23:11, Kinney, Michael D wrote:
>> Laszlo,
>> 
>> Good question.  
>> 
>> It is a good practice to have the .h file for each GUID.  The .h file 
>> contains the extern for the global variable associated with the GUID along 
>> with data structures associated with the GUID.
>> 
>> For PCD token space GUIDs, there is no data structure and the AutoGen.h file 
>> contains an extern to all token space GUIDs a module references, so the .h 
>> file for the token space GUID is not required.
>> 
>> The C name for a Token space GUID (i.e. gUefiCpuPkgTokenSpaceGuid) would be 
>> required in C code if the PcdLib PcdGetEx8 (),PcdGetEx16 (),PcdGetEx32 
>> (),PcdGetEx64 (),PcdGetExBool (),or PcdGetExPtr () APIs are used.  Most 
>> modules/libs do not use the 'Ex' versions of these, so it is very rare for a 
>> module to use the C name for a Token space GUID.
>> 
>> I will remove the UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h from the 
>> patch set.
> 
> Thank you for explaining me the PcdGetEx__() family of functions at the
> same time :) I've been wondering about both them, and how one could
> resolve token name collisions between different token spaces.
> Apparently, with the Ex family (but it remains unnecessary in practice).
> 

It is only needed for modules that are not compiled together. 

Thanks,

Andrew Fish

> Thank you!
> Laszlo
> 
>> 
>> Thanks,
>> 
>> Mike
>> 
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com] 
>> Sent: Wednesday, October 07, 2015 10:38 AM
>> To: Kinney, Michael D; edk2-de...@ml01.01.org
>> Subject: Re: [edk2] [PATCH 7/7] UefiCpuPkg: Add missing UefiCpuPkgTokenSpace 
>> include
>> 
>> On 10/05/15 01:57, Michael Kinney wrote:
>>> Add missing include files for the token space GUID for the UefiCpuPkg
>>> Add path to the token space include file to the UefiCpuPkg DEC file.
>> 
>> Is this usual? For example, gUefiOvmfPkgTokenSpaceGuid is also not
>> defined anywhere else than in the DEC file.
>> 
>> What could a programmer use UEFICPUPKG_TOKEN_SPACE_GUID /
>> gUefiCpuPkgTokenSpaceGuid for, in C source code?
>> 
>> ... Only the following packages / header files seem to expose their
>> respective token space GUIDs in a similar way:
>> 
>> MdeModulePkg/Include/Guid/MdeModulePkgTokenSpace.h
>> MdePkg/Include/Guid/MdePkgTokenSpace.h
>> PcAtChipsetPkg/Include/Guid/PcAtChipsetTokenSpace.h
>> PerformancePkg/Include/Guid/PerformancePkgTokenSpace.h
>> SecurityPkg/Include/Guid/SecurityPkgTokenSpace.h
>> ShellPkg/Include/Guid/ShellPkgTokenSpace.h
>> Vlv2DeviceRefCodePkg/Include/Guid/Vlv2DeviceRefCodePkgTokenSpace.h
>> 
>> Thanks!
>> Laszlo
>> 
>>> 
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Michael Kinney 
>>> ---
>>> UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h | 25 
>>> +
>>> UefiCpuPkg/UefiCpuPkg.dec  |  1 +
>>> 2 files changed, 26 insertions(+)
>>> create mode 100644 UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
>>> 
>>> diff --git a/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h 
>>> b/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
>>> new file mode 100644
>>> index 000..6c4e671
>>> --- /dev/null
>>> +++ b/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
>>> @@ -0,0 +1,25 @@
>>> +/** @file
>>> +GUID for UefiCpuPkg PCD Token Space
>>> +
>>> +Copyright (c) 2015, 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 _UEFICPUPKG_TOKEN_SPACE_GUID_H_
>>> +#define _UEFICPUPKG_TOKEN_SPACE_GUID_H_
>>> +
>>> +#define UEFICPUPKG_TOKEN_SPACE_GUID \
>>> +  { \
>>> +0xac05bf33, 0x995a, 0x4ed4, { 0xaa, 0xb8, 0xef, 0x7a, 0xe8, 0xf, 0x5c, 
>>> 0xb0 } \
>>> +  }
>>> +
>>> +extern EFI_GUID gUefiCpuPkgTokenSpaceGuid;
>>> +
>>> +#endif
>>> diff --git a/UefiCpuPkg/UefiCpuPkg.dec b/UefiCpuPkg/UefiCpuPkg.dec
>>> index e4b8030..e293390 100644
>>> --- a/UefiCpuPkg/UefiCpuPkg.dec
>>> +++ b/UefiCpuPkg/UefiCpuPkg.dec
>>> @@ -51,6 +51,7 @@
>>>   SmmCpuFeaturesLib|Include/Library/SmmCpuFeaturesLib.h
>>> 
>>> [Guids]
>>> +  ## Include/Guid/UefiCpuPkgTokenSpace.h
>>>   gUefiCpuPkgTokenSpaceGuid  = { 0xac05bf33, 0x995a, 0x4ed4, { 0xaa, 
>>> 0xb8, 0xef, 0x7a, 0xe8, 0xf, 0x5c, 0xb0 }}
>>> 
>>> [Protocols]
>>> 
>> 
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing 

Re: [edk2] [PATCH v3 3/5] ArmPkg/ArmLib MMU: add functions to set/clear RO and XN bits on regions

[Leif Lindholm]

On Tue, Oct 06, 2015 at 01:48:19PM +0100, Ard Biesheuvel wrote:
> Use the refactored UpdateRegionMapping () to traverse the translation
> tables, splitting block entries along the way if required, and apply
> a mask + or on each to set or clear the PXN/UXN/XN or RO bits.
> 
> For now, the 32-bit ARM versions remain unimplemented.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Ard Biesheuvel 
> ---
>  ArmPkg/Include/Library/ArmLib.h| 24 ++
>  ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c | 90 
>  ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c | 36 
>  3 files changed, 150 insertions(+)
> 
> diff --git a/ArmPkg/Include/Library/ArmLib.h b/ArmPkg/Include/Library/ArmLib.h
> index c83a5a7f1b3c..b4768841bd9d 100644
> --- a/ArmPkg/Include/Library/ArmLib.h
> +++ b/ArmPkg/Include/Library/ArmLib.h
> @@ -661,4 +661,28 @@ ArmUnsetCpuActlrBit (
>IN  UINTNBits
>);
>  
> +RETURN_STATUS
> +ArmSetMemoryRegionNoExec (
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  IN  UINT64Length
> +  );
> +
> +RETURN_STATUS
> +ArmClearMemoryRegionNoExec (
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  IN  UINT64Length
> +  );
> +
> +RETURN_STATUS
> +ArmSetMemoryRegionReadOnly (
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  IN  UINT64Length
> +  );
> +
> +RETURN_STATUS
> +ArmClearMemoryRegionReadOnly (
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  IN  UINT64Length
> +  );
> +
>  #endif // __ARM_LIB__
> diff --git a/ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c 
> b/ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c
> index 60f5cf188db3..011b529e8d6b 100644
> --- a/ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c
> +++ b/ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c
> @@ -512,6 +512,96 @@ SetMemoryAttributes (
>return RETURN_SUCCESS;
>  }
>  
> +STATIC
> +RETURN_STATUS
> +SetMemoryRegionAttribute (
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  IN  UINT64Length,
> +  IN  UINT64Attributes,
> +  IN  UINT64BlockEntryMask
> +  )
> +{
> +  RETURN_STATUSStatus;
> +  UINT64   *RootTable;
> +
> +  RootTable = ArmGetTTBR0BaseAddress ();
> +
> +  Status = UpdateRegionMapping (RootTable, BaseAddress, Length, Attributes, 
> BlockEntryMask);
> +  if (RETURN_ERROR (Status)) {
> +return Status;
> +  }
> +
> +  // Invalidate all TLB entries so changes are synced
> +  ArmInvalidateTlb ();
> +
> +  return RETURN_SUCCESS;
> +}
> +
> +RETURN_STATUS
> +ArmSetMemoryRegionNoExec (
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  IN  UINT64Length
> +  )
> +{
> +  UINT64Val;
> +
> +  if (ArmReadCurrentEL () == AARCH64_EL1) {
> +Val = TT_PXN_MASK | TT_UXN_MASK;
> +  } else {
> +Val = TT_XN_MASK;
> +  }
> +
> +  return ArmSetMemoryRegionAttribute (
> +   BaseAddress,
> +   Length,
> +   Val,
> +   ~TT_ADDRESS_MASK_BLOCK_ENTRY);
> +}
> +
> +RETURN_STATUS
> +ArmClearMemoryRegionNoExec (
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  IN  UINT64Length
> +  )
> +{
> +  UINT64 Mask;
> +
> +  // XN maps to UXN in the EL1&0 translation regime
> +  Mask = ~(TT_ADDRESS_MASK_BLOCK_ENTRY | TT_PXN_MASK | TT_XN_MASK);
> +
> +  return ArmSetMemoryRegionAttribute (
> +   BaseAddress,
> +   Length,
> +   0,
> +   Mask);
> +}
> +
> +RETURN_STATUS
> +ArmSetMemoryRegionReadOnly (
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  IN  UINT64Length
> +  )
> +{
> +  return ArmSetMemoryRegionAttribute (
> +   BaseAddress,
> +   Length,
> +   TT_AP_RO_RO,
> +   ~TT_ADDRESS_MASK_BLOCK_ENTRY);
> +}
> +
> +RETURN_STATUS
> +ArmClearMemoryRegionReadOnly (
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  IN  UINT64Length
> +  )
> +{
> +  return ArmSetMemoryRegionAttribute (
> +   BaseAddress,
> +   Length,
> +   TT_AP_NO_RO,
> +   ~(TT_ADDRESS_MASK_BLOCK_ENTRY | TT_AP_MASK));
> +}
> +
>  RETURN_STATUS
>  EFIAPI
>  ArmConfigureMmu (
> diff --git a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c 
> b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c
> index d035ff3caa40..1287dfb1a9bb 100644
> --- a/ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c
> +++ b/ArmPkg/Library/ArmLib/ArmV7/ArmV7Mmu.c
> @@ -301,3 +301,39 @@ ArmConfigureMmu (
>ArmEnableMmu();
>return RETURN_SUCCESS;
>  }
> +
> +RETURN_STATUS
> +ArmSetMemoryRegionNoExec (
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  IN  UINT64Length
> +  )
> +{
> +  return RETURN_UNSUPPORTED;
> +}
> +
> +RETURN_STATUS
> +ArmClearMemoryRegionNoExec (
> +  IN  EFI_PHYSICAL_ADDRESS  BaseAddress,
> +  IN  UINT64Length
> +  )
> +{
> +  return RETURN_UNSUPPORTED;
> +}
> +
> +RETURN_STATUS
> 

Re: [edk2] [PATCH 7/7] UefiCpuPkg: Add missing UefiCpuPkgTokenSpace include

[Kinney, Michael D]

Andrew,

Yes.  The use of the Ex forms of the PCD Protocol/PPI APIs are required when 
modules are built separately.  The Ex forms of the PCD Protocol/PPI APIs are 
used even if the module source does not use the Ex APIs from the PcdLib if the 
PCDs are listed in a DynamicEx section of a DSC file.

The Ex APIs in the PcdLib are only required in the source code if a modules 
uses 2 PCDs from 2 different token spaces that happen to have the same token 
name.  The sources can select the correct PCD with the Ex API.

Best regards,

Mike


>-Original Message-
>From: af...@apple.com [mailto:af...@apple.com]
>Sent: Thursday, October 08, 2015 8:03 AM
>To: Laszlo Ersek
>Cc: Kinney, Michael D; edk2-de...@ml01.01.org
>Subject: Re: [edk2] [PATCH 7/7] UefiCpuPkg: Add missing
>UefiCpuPkgTokenSpace include
>
>
>> On Oct 8, 2015, at 4:22 AM, Laszlo Ersek  wrote:
>>
>> On 10/07/15 23:11, Kinney, Michael D wrote:
>>> Laszlo,
>>>
>>> Good question.
>>>
>>> It is a good practice to have the .h file for each GUID.  The .h file 
>>> contains
>the extern for the global variable associated with the GUID along with data
>structures associated with the GUID.
>>>
>>> For PCD token space GUIDs, there is no data structure and the AutoGen.h
>file contains an extern to all token space GUIDs a module references, so the .h
>file for the token space GUID is not required.
>>>
>>> The C name for a Token space GUID (i.e. gUefiCpuPkgTokenSpaceGuid)
>would be required in C code if the PcdLib PcdGetEx8 (),PcdGetEx16
>(),PcdGetEx32 (),PcdGetEx64 (),PcdGetExBool (),or PcdGetExPtr () APIs are
>used.  Most modules/libs do not use the 'Ex' versions of these, so it is very
>rare for a module to use the C name for a Token space GUID.
>>>
>>> I will remove the UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h from
>the patch set.
>>
>> Thank you for explaining me the PcdGetEx__() family of functions at the
>> same time :) I've been wondering about both them, and how one could
>> resolve token name collisions between different token spaces.
>> Apparently, with the Ex family (but it remains unnecessary in practice).
>>
>
>It is only needed for modules that are not compiled together.
>
>Thanks,
>
>Andrew Fish
>
>> Thank you!
>> Laszlo
>>
>>>
>>> Thanks,
>>>
>>> Mike
>>>
>>> -Original Message-
>>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>>> Sent: Wednesday, October 07, 2015 10:38 AM
>>> To: Kinney, Michael D; edk2-de...@ml01.01.org
>>> Subject: Re: [edk2] [PATCH 7/7] UefiCpuPkg: Add missing
>UefiCpuPkgTokenSpace include
>>>
>>> On 10/05/15 01:57, Michael Kinney wrote:
 Add missing include files for the token space GUID for the UefiCpuPkg
 Add path to the token space include file to the UefiCpuPkg DEC file.
>>>
>>> Is this usual? For example, gUefiOvmfPkgTokenSpaceGuid is also not
>>> defined anywhere else than in the DEC file.
>>>
>>> What could a programmer use UEFICPUPKG_TOKEN_SPACE_GUID /
>>> gUefiCpuPkgTokenSpaceGuid for, in C source code?
>>>
>>> ... Only the following packages / header files seem to expose their
>>> respective token space GUIDs in a similar way:
>>>
>>> MdeModulePkg/Include/Guid/MdeModulePkgTokenSpace.h
>>> MdePkg/Include/Guid/MdePkgTokenSpace.h
>>> PcAtChipsetPkg/Include/Guid/PcAtChipsetTokenSpace.h
>>> PerformancePkg/Include/Guid/PerformancePkgTokenSpace.h
>>> SecurityPkg/Include/Guid/SecurityPkgTokenSpace.h
>>> ShellPkg/Include/Guid/ShellPkgTokenSpace.h
>>> Vlv2DeviceRefCodePkg/Include/Guid/Vlv2DeviceRefCodePkgTokenSpace.h
>>>
>>> Thanks!
>>> Laszlo
>>>

 Contributed-under: TianoCore Contribution Agreement 1.0
 Signed-off-by: Michael Kinney 
 ---
 UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h | 25
>+
 UefiCpuPkg/UefiCpuPkg.dec  |  1 +
 2 files changed, 26 insertions(+)
 create mode 100644 UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h

 diff --git a/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
>b/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
 new file mode 100644
 index 000..6c4e671
 --- /dev/null
 +++ b/UefiCpuPkg/Include/Guid/UefiCpuPkgTokenSpace.h
 @@ -0,0 +1,25 @@
 +/** @file
 +GUID for UefiCpuPkg PCD Token Space
 +
 +Copyright (c) 2015, 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 _UEFICPUPKG_TOKEN_SPACE_GUID_H_
 +#define _UEFICPUPKG_TOKEN_SPACE_GUID_H_
 +
 +#define UEFICPUPKG_TOKEN_SPACE_GUID \
 +  { \
 +0xac05bf33, 0x995a, 

[edk2] [PATCH 1/3] MdePkg: Create GetRandomNumber128 in RngLib

[Thomas Palmer]

Declare GetRandomNumber128 in RngLib.h.
Create GetRandomNumber128 in BaseRngLib, which is simply calling 
GetRandomNumber64 twice

A GetRandomNumber128 function allows platforms with 128bit HWRNGs to save on IO 
overhead that comes from having to prime the HWRNG device before each read 
operation.  Using the HWRNG installed on the HP ProLiant m400 moonshot 
cartridge, this will save about 50ms per RAW Entropy operation as compared with 
calling GetRandomNumber64 twice.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer 
---
 MdePkg/Include/Library/RngLib.h |   17 +
 MdePkg/Library/BaseRngLib/BaseRng.c |   32 
 2 files changed, 49 insertions(+)

diff --git a/MdePkg/Include/Library/RngLib.h b/MdePkg/Include/Library/RngLib.h
index 157a931..ece4394 100644
--- a/MdePkg/Include/Library/RngLib.h
+++ b/MdePkg/Include/Library/RngLib.h
@@ -66,4 +66,21 @@ GetRandomNumber64 (
   OUT UINT64*Rand
   );
 
+/**
+  Generates a 128-bit random number.
+
+  if Rand is NULL, then ASSERT().
+
+  @param[out] Rand Buffer pointer to store the 128-bit random value.
+
+  @retval TRUE Random number generated successfully.
+  @retval FALSEFailed to generate the random number.
+
+**/
+BOOLEAN
+EFIAPI
+GetRandomNumber128 (
+  OUT UINT64*Rand
+  );
+
 #endif  // __RNG_LIB_H__
diff --git a/MdePkg/Library/BaseRngLib/BaseRng.c 
b/MdePkg/Library/BaseRngLib/BaseRng.c
index 279df30..2c8df56 100644
--- a/MdePkg/Library/BaseRngLib/BaseRng.c
+++ b/MdePkg/Library/BaseRngLib/BaseRng.c
@@ -155,3 +155,35 @@ GetRandomNumber64 (
 
   return FALSE;
 }
+
+/**
+  Generates a 128-bit random number.
+
+  if Rand is NULL, then ASSERT().
+
+  @param[out] Rand Buffer pointer to store the 128-bit random value.
+
+  @retval TRUE Random number generated successfully.
+  @retval FALSEFailed to generate the random number.
+
+**/
+BOOLEAN
+EFIAPI
+GetRandomNumber128 (
+  OUT UINT64*Rand
+  )
+{
+  ASSERT (Rand != NULL);
+
+  //
+  // Read first 64 bits
+  //
+  if (!GetRandomNumber64 (Rand)) {
+return FALSE;
+  }
+
+  //
+  // Read second 64 bits
+  //
+  return GetRandomNumber64 (++Rand);
+}
-- 
1.7.9.5

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

[edk2] [PATCH 2/3] SecurityPkg: Integrate new RngLib into RngDxe

[Thomas Palmer]

Use the new RngLib to provide the IA32/X64 random data for RngDxe.
Remove x86 specific functions from RdRand files.
Simplify RngDxe by using WriteUnaligned64 for all platforms.
Use GetRandomNumber128 in RngDxe to leverage 128 bit support provided by some 
HW RNG devices

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Thomas Palmer 
---
 SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.c  |  256 ++--
 SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.h  |  151 +---
 SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.c  |9 +-
 .../RandomNumberGenerator/RngDxe/RngDxe.inf|   14 +-
 SecurityPkg/SecurityPkg.dsc|3 +
 5 files changed, 26 insertions(+), 407 deletions(-)

diff --git a/SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.c 
b/SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.c
index 7e618dc..395b886 100644
--- a/SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.c
+++ b/SecurityPkg/RandomNumberGenerator/RngDxe/RdRand.c
@@ -2,6 +2,7 @@
   Support routines for RDRAND instruction access.
 
 Copyright (c) 2013, Intel Corporation. All rights reserved.
+(C) Copyright 2015 Hewlett Packard Enterprise Development LP
 This program and the accompanying materials
 are licensed and made available under the terms and conditions of the BSD 
License
 which accompanies this distribution.  The full text of the license may be 
found at
@@ -11,177 +12,11 @@ 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 "RdRand.h"
 #include "AesCore.h"
 
-//
-// Bit mask used to determine if RdRand instruction is supported.
-//
-#define RDRAND_MASK0x4000
-
-/**
-  Determines whether or not RDRAND instruction is supported by the host 
hardware.
-
-  @retval EFI_SUCCESS  RDRAND instruction supported.
-  @retval EFI_UNSUPPORTED  RDRAND instruction not supported.
-
-**/
-EFI_STATUS
-EFIAPI
-IsRdRandSupported (
-  VOID
-  )
-{
-  EFI_STATUS  Status;
-  UINT32  RegEax;
-  UINT32  RegEbx;
-  UINT32  RegEcx;
-  UINT32  RegEdx;
-  BOOLEAN IsIntelCpu;
-
-  Status = EFI_UNSUPPORTED;
-  IsIntelCpu = FALSE;
-  
-  //
-  // Checks whether the current processor is an Intel product by CPUID.
-  //
-  AsmCpuid (0, , , , );
-  if ((CompareMem ((CHAR8 *)(), "Genu", 4) == 0) &&
-  (CompareMem ((CHAR8 *)(), "ineI", 4) == 0) &&
-  (CompareMem ((CHAR8 *)(), "ntel", 4) == 0)) {
-IsIntelCpu = TRUE;
-  }
-
-  if (IsIntelCpu) {
-//
-// Determine RDRAND support by examining bit 30 of the ECX register 
returned by CPUID.
-// A value of 1 indicates that processor supports RDRAND instruction.
-//
-AsmCpuid (1, 0, 0, , 0);
-
-if ((RegEcx & RDRAND_MASK) == RDRAND_MASK) {
-  Status = EFI_SUCCESS;
-}
-  }
-
-  return Status;
-}
-
-/**
-  Calls RDRAND to obtain a 16-bit random number.
-
-  @param[out]  Rand  Buffer pointer to store the random result.
-  @param[in]   NeedRetry Determine whether or not to loop retry.
-
-  @retval EFI_SUCCESSRDRAND call was successful.
-  @retval EFI_NOT_READY  Failed attempts to call RDRAND.
-
-**/
-EFI_STATUS
-EFIAPI
-RdRand16 (
-  OUT UINT16   *Rand,
-  IN BOOLEAN   NeedRetry
-  )
-{
-  UINT32  Index;
-  UINT32  RetryCount;
-
-  if (NeedRetry) {
-RetryCount = RETRY_LIMIT;
-  } else {
-RetryCount = 1;
-  }
-
-  //
-  // Perform a single call to RDRAND, or enter a loop call until RDRAND 
succeeds.
-  //
-  for (Index = 0; Index < RetryCount; Index++) {
-if (RdRand16Step (Rand)) {
-  return EFI_SUCCESS;
-}
-  }
-  
-  return EFI_NOT_READY;
-}
-
-/**
-  Calls RDRAND to obtain a 32-bit random number.
-
-  @param[out]  Rand  Buffer pointer to store the random result.
-  @param[in]   NeedRetry Determine whether or not to loop retry.
-
-  @retval EFI_SUCCESSRDRAND call was successful.
-  @retval EFI_NOT_READY  Failed attempts to call RDRAND.
-
-**/
-EFI_STATUS
-EFIAPI
-RdRand32 (
-  OUT UINT32   *Rand,
-  IN BOOLEAN   NeedRetry
-  )
-{
-  UINT32  Index;
-  UINT32  RetryCount;
-
-  if (NeedRetry) {
-RetryCount = RETRY_LIMIT;
-  } else {
-RetryCount = 1;
-  }
-
-  //
-  // Perform a single call to RDRAND, or enter a loop call until RDRAND 
succeeds.
-  //
-  for (Index = 0; Index < RetryCount; Index++) {
-if (RdRand32Step (Rand)) {
-  return EFI_SUCCESS;
-}
-  }
-  
-  return EFI_NOT_READY;
-}
-
-/**
-  Calls RDRAND to obtain a 64-bit random number.
-
-  @param[out]  Rand  Buffer pointer to store the random result.
-  @param[in]   NeedRetry Determine whether or not to loop retry.
-
-  @retval EFI_SUCCESSRDRAND call was successful.
-  @retval EFI_NOT_READY  Failed attempts to call RDRAND.
-
-**/
-EFI_STATUS
-EFIAPI
-RdRand64 (
-  OUT UINT64   *Rand,
-  IN BOOLEAN   NeedRetry
-  )
-{
-  

Re: [edk2] Cross compiling EDK2 for Aarch64

[Laszlo Ersek]

On 10/08/15 10:24, Yehuda Yitschak wrote:
> Hello everyone
> 
> I am new to the EDK2 projects and for starters I am trying to cross compile 
> the project for aarch64 on an x86_64 host
> 
> I looked around in Linaro website and Tiano-core website but couldn't find 
> any instruction on how to _cross_ compile
> 
> I tried to follow the instruction here: 
> https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/build
> but when I try to compile using the "build" command the build script uses the 
> x86 compiler and naturally it fails
> I tried working around this by setting the environment variable GCC48_BIN 
> however then the build system tries to call "make" from the path in GCC48_BIN 
> which off course fails
> 
> I also found these instructions 
> https://github.com/tianocore/tianocore.github.io/wiki/Unix-like_systems#Build_gcc_x64_UEFI_cross_compiler
> But I'm not sure they apply to aarch64.
> 
> I appreciate any suggestions you can offer

Here's how I do it:

- download & install the latest cross-compiler toolchain from Linaro's
website, for example:

https://releases.linaro.org/15.06/components/toolchain/binaries/4.8/aarch64-linux-gnu/

The tarball you most probably want is

gcc-linaro-4.8-2015.06-x86_64_aarch64-linux-gnu.tar.xz

assuming you use Linux. If you use Windows, I guess you need:

gcc-linaro-4.8-2015.06-i686-mingw32_aarch64-linux-gnu.tar.xz

Now extract this somewhere, and put its "bin" directory on your PATH.
Notice that it has filenames like "aarch64-linux-gnu-gcc".

Once this is done, you can build ArmVirtQemu.dsc (for getting AARCH64
firmware that runs on "qemu-system-aarch64 -M virt") like this:

$ source edksetup.sh

$ export GCC48_AARCH64_PREFIX=aarch64-linux-gnu-

$ build \
-a AARCH64 \
-t GCC48 \
-p ArmVirtPkg/ArmVirtQemu.dsc \
-n 8 \
--report-file=.../build.aa64virt.report \
--log=.../build.aa64virt.log \
-b DEBUG \
-D DEBUG_PRINT_ERROR_LEVEL=0x8040004F \
-D SECURE_BOOT_ENABLE

(See "build --help" for what's what.)

The final firmware image is somewhere under the Build directory, you'll
have to consult the FDF file referenced with FLASH_DEFINITION in the DSC
file for finding out its name.

For example, "ArmVirtPkg/ArmVirtQemu.dsc" references
"ArmVirtPkg/ArmVirtQemu.fdf", and the latter has a section called
[FD.QEMU_EFI], so the file you'd look for under Build is "QEMU_EFI.fd".

For installing and/or running the firmware binary, further actions may
be necessary, of course. (In case of QEMU, the QEMU_EFI.fd file needs to
be padded to 64MB, etc etc, you can google the instructions in the
Linaro and Fedora wikis.)

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

Re: [edk2] Cross compiling EDK2 for Aarch64

[Laszlo Ersek]

Obviously I forgot one command (because it need not be reissued every time):

On 10/08/15 21:17, Laszlo Ersek wrote:
> On 10/08/15 10:24, Yehuda Yitschak wrote:
>> Hello everyone
>>
>> I am new to the EDK2 projects and for starters I am trying to cross compile 
>> the project for aarch64 on an x86_64 host
>>
>> I looked around in Linaro website and Tiano-core website but couldn't find 
>> any instruction on how to _cross_ compile
>>
>> I tried to follow the instruction here: 
>> https://wiki.linaro.org/LEG/Engineering/Kernel/UEFI/build
>> but when I try to compile using the "build" command the build script uses 
>> the x86 compiler and naturally it fails
>> I tried working around this by setting the environment variable GCC48_BIN 
>> however then the build system tries to call "make" from the path in 
>> GCC48_BIN which off course fails
>>
>> I also found these instructions 
>> https://github.com/tianocore/tianocore.github.io/wiki/Unix-like_systems#Build_gcc_x64_UEFI_cross_compiler
>> But I'm not sure they apply to aarch64.
>>
>> I appreciate any suggestions you can offer
> 
> Here's how I do it:
> 
> - download & install the latest cross-compiler toolchain from Linaro's
> website, for example:
> 
> https://releases.linaro.org/15.06/components/toolchain/binaries/4.8/aarch64-linux-gnu/
> 
> The tarball you most probably want is
> 
> gcc-linaro-4.8-2015.06-x86_64_aarch64-linux-gnu.tar.xz
> 
> assuming you use Linux. If you use Windows, I guess you need:
> 
> gcc-linaro-4.8-2015.06-i686-mingw32_aarch64-linux-gnu.tar.xz
> 
> Now extract this somewhere, and put its "bin" directory on your PATH.
> Notice that it has filenames like "aarch64-linux-gnu-gcc".
> 
> Once this is done, you can build ArmVirtQemu.dsc (for getting AARCH64
> firmware that runs on "qemu-system-aarch64 -M virt") like this:
> 
> $ source edksetup.sh

after this:

$ make -C "$EDK_TOOLS_PATH"

Thanks
Laszlo

> 
> $ export GCC48_AARCH64_PREFIX=aarch64-linux-gnu-
> 
> $ build \
> -a AARCH64 \
> -t GCC48 \
> -p ArmVirtPkg/ArmVirtQemu.dsc \
> -n 8 \
> --report-file=.../build.aa64virt.report \
> --log=.../build.aa64virt.log \
> -b DEBUG \
> -D DEBUG_PRINT_ERROR_LEVEL=0x8040004F \
> -D SECURE_BOOT_ENABLE
> 
> (See "build --help" for what's what.)
> 
> The final firmware image is somewhere under the Build directory, you'll
> have to consult the FDF file referenced with FLASH_DEFINITION in the DSC
> file for finding out its name.
> 
> For example, "ArmVirtPkg/ArmVirtQemu.dsc" references
> "ArmVirtPkg/ArmVirtQemu.fdf", and the latter has a section called
> [FD.QEMU_EFI], so the file you'd look for under Build is "QEMU_EFI.fd".
> 
> For installing and/or running the firmware binary, further actions may
> be necessary, of course. (In case of QEMU, the QEMU_EFI.fd file needs to
> be padded to 64MB, etc etc, you can google the instructions in the
> Linaro and Fedora wikis.)
> 
> 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] BaseTools/Scripts: Add PatchCheck.py script

[Laszlo Ersek]

On 10/08/15 04:53, Jordan Justen wrote:
> This script can be used to check some expected rules for EDK II
> patches. It only works on git formatted patches.
> 
> It checks both the commit message and the lines that are added in the
> patch diff.
> 
> In the commit message it verifies line lengths, signature formats, and
> the Contributed-under tag.
> 
> In the patch, it checks that line endings are CRLF for all files that
> don't have a .sh extension. It verifies that no trailing whitespace is
> present and that tab characters are not used.

Yay! :)

Immediate RFE: can it enforce a line length of 79 characters for lines
that a patch adds, to C or assembly source code (based on filename
suffix)? ;) And reject non-ASCII characters in the same?

Anyway, those are just ideas, and ideas are a dime a dozen. :)

Thanks
Laszlo

> 
> Patch contributors should use this script prior to submitting their
> patches. Package maintainers can also use it to verify incoming
> patches.
> 
> It can also be run by specifying a git revision list, so actual patch
> files are not always required.
> 
> For example, to checkout this last 5 patches in your git branch you
> can run:
> 
>   python PatchCheck.py HEAD~5..
> 
> Or, a shortcut (like git log):
> 
>   python PatchCheck.py -5
> 
> The --oneline option works similar to git log --oneline.
> 
> The --silent option enables silent operation.
> 
> The script supports python 2.7 and python 3.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Jordan Justen 
> Cc: Erik Bjorge 
> Cc: Yonghong Zhu 
> Cc: Liming Gao 
> ---
>  BaseTools/Scripts/PatchCheck.py | 607 
> 
>  1 file changed, 607 insertions(+)
>  create mode 100644 BaseTools/Scripts/PatchCheck.py
> 
> diff --git a/BaseTools/Scripts/PatchCheck.py b/BaseTools/Scripts/PatchCheck.py
> new file mode 100644
> index 000..340a997
> --- /dev/null
> +++ b/BaseTools/Scripts/PatchCheck.py
> @@ -0,0 +1,607 @@
> +## @file
> +#  Check a patch for various format issues
> +#
> +#  Copyright (c) 2015, 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.
> +#
> +
> +from __future__ import print_function
> +
> +VersionNumber = '0.1'
> +__copyright__ = "Copyright (c) 2015, Intel Corporation  All rights reserved."
> +
> +import email
> +import argparse
> +import os
> +import re
> +import subprocess
> +import sys
> +
> +class Verbose:
> +SILENT, ONELINE, NORMAL = range(3)
> +level = NORMAL
> +
> +class CommitMessageCheck:
> +"""Checks the contents of a git commit message."""
> +
> +def __init__(self, subject, message):
> +self.ok = True
> +
> +if subject is None and  message is None:
> +self.error('Commit message is missing!')
> +return
> +
> +self.subject = subject
> +self.msg = message
> +
> +self.check_contributed_under()
> +self.check_signed_off_by()
> +self.check_misc_signatures()
> +self.check_overall_format()
> +self.report_message_result()
> +
> +url = 
> 'https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format'
> +
> +def report_message_result(self):
> +if Verbose.level < Verbose.NORMAL:
> +return
> +if self.ok:
> +# All checks passed
> +return_code = 0
> +print('The commit message format passed all checks.')
> +else:
> +return_code = 1
> +if not self.ok:
> +print(self.url)
> +
> +def error(self, *err):
> +if self.ok and Verbose.level > Verbose.ONELINE:
> +print('The commit message format is not valid:')
> +self.ok = False
> +if Verbose.level < Verbose.NORMAL:
> +return
> +count = 0
> +for line in err:
> +prefix = (' *', '  ')[count > 0]
> +print(prefix, line)
> +count += 1
> +
> +def check_contributed_under(self):
> +cu_msg='Contributed-under: TianoCore Contribution Agreement 1.0'
> +if self.msg.find(cu_msg) < 0:
> +self.error('Missing Contributed-under! (Note: this must be ' +
> +   'added by the code contributor!)')
> +
> +@staticmethod
> +def make_signature_re(sig, re_input=False):
> +if re_input:
> +sub_re = sig
> +else:
> +sub_re = sig.replace('-', r'[-\s]+')
> +re_str = (r'^(?P' + 

Re: [edk2] [PATCH] MdeModulePkg PiDxeS3BootScriptLib: Use PcdSet64S to instead of PcdSet64

[Andrew Fish]

> On Oct 8, 2015, at 3:11 PM, Laszlo Ersek  wrote:
> 
> On 10/08/15 09:39, Star Zeng wrote:
>> PcdSet## has no error status returned, then the caller has no idea about 
>> whether the set operation is successful or not.
>> PcdSet##S were added to return error status and PcdSet## APIs were put in 
>> ifndef DISABLE_NEW_DEPRECATED_INTERFACES condition.
>> To adopt PcdSet##S and further code development with 
>> DISABLE_NEW_DEPRECATED_INTERFACES defined, we need to Replace PcdSet## usage 
>> with PcdSet##S.
>> 
>> Normally, DynamicDefault PCD set is expected to be success, but DynamicHii 
>> PCD set failure is a legal case.
> 
> I almost had a question here ("why?"), but looking at
> "MdeModulePkg/Universal/PCD/Dxe/Pcd.inf", I know why -- because
> PcdsDynamicHii is stored in the non-volatile varstore.
> 
>> For this case, PcdS3BootScriptTablePrivateDataPtr and 
>> PcdS3BootScriptTablePrivateSmmDataPtr are expected to be DynamicDefault,
>> so use PcdSet64S to instead of PcdSet64 and assert when set failure.
> 
> Okay, so this I don't understand.
> 
> First, I don't think that any platform would like to store S3
> bootscript-related stuff in nv variables.
> 

Historically I think there is an ACPI NVS memory region that the variable 
pointed to (going from memory so I may be a little off). 
The newer code uses the LockBox that is usually stored in SMM. 

> Second, "MdeModulePkg/MdeModulePkg.dec" restricts these PCDs to
> [PcdsDynamic, PcdsDynamicEx], so no platform DSC can make them
> PcdsDynamicHii.
> 

This is just confusing terminology/syntax….

From the DEC and INF point of view:
PcdDynamic means you use the PCD PPI/Protocol with the build generated Token
PcdDynamicEx means you use the PCD PPI/Protocol with the fixed Token and 
EFI_GUID from the .DEC. 

The DSC file also has a knob that controls how dynamic PCDs are stored. So 
PcdsDynamicHii is a PcdDynamic form, but the driver that implements the 
PPI/Protocol stores the data in an alternate location. 

Thanks,

Andrew Fish

> Therefore, I guess the patch is correct, but why is it necessary? Is it
> just to be compatible with DISABLE_NEW_DEPRECATED_INTERFACES?
> 
> Ah, I see. The commit message has three parts / arguments actually:
> 
> (1) general description of status checking vs. non-checking interfaces
> (2) argument why we should move to checked interfaces
> (3) argument why the check will always succeed.
> 
> Thanks
> Laszlo
> 
> 
>> 
>> Cc: Jiewen Yao 
>> Cc: Liming Gao 
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Star Zeng 
>> ---
>> MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c | 6 --
>> 1 file changed, 4 insertions(+), 2 deletions(-)
>> 
>> diff --git a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c 
>> b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
>> index 24c6798..e7d2a24 100644
>> --- a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
>> +++ b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
>> @@ -454,7 +454,8 @@ S3BootScriptLibInitialize (
>> }
>> S3TablePtr = (VOID *) (UINTN) Buffer;
>> 
>> -PcdSet64 (PcdS3BootScriptTablePrivateDataPtr, (UINT64) 
>> (UINTN)S3TablePtr); 
>> +Status = PcdSet64S (PcdS3BootScriptTablePrivateDataPtr, (UINT64) 
>> (UINTN)S3TablePtr);
>> +ASSERT_EFI_ERROR (Status);
>> ZeroMem (S3TablePtr, sizeof(SCRIPT_TABLE_PRIVATE_DATA));  
>> //
>> // Create event to notify the library system enter the SmmLocked phase.
>> @@ -506,7 +507,8 @@ S3BootScriptLibInitialize (
>>   return RETURN_OUT_OF_RESOURCES;
>> }
>> 
>> -PcdSet64 (PcdS3BootScriptTablePrivateSmmDataPtr, (UINT64) 
>> (UINTN)S3TableSmmPtr);
>> +Status = PcdSet64S (PcdS3BootScriptTablePrivateSmmDataPtr, (UINT64) 
>> (UINTN)S3TableSmmPtr);
>> +ASSERT_EFI_ERROR (Status);
>> ZeroMem (S3TableSmmPtr, sizeof(SCRIPT_TABLE_PRIVATE_DATA));
>> 
>> //
>> 
> 
> ___
> 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] MdeModulePkg PiDxeS3BootScriptLib: Use PcdSet64S to instead of PcdSet64

[Laszlo Ersek]

On 10/08/15 09:39, Star Zeng wrote:
> PcdSet## has no error status returned, then the caller has no idea about 
> whether the set operation is successful or not.
> PcdSet##S were added to return error status and PcdSet## APIs were put in 
> ifndef DISABLE_NEW_DEPRECATED_INTERFACES condition.
> To adopt PcdSet##S and further code development with 
> DISABLE_NEW_DEPRECATED_INTERFACES defined, we need to Replace PcdSet## usage 
> with PcdSet##S.
> 
> Normally, DynamicDefault PCD set is expected to be success, but DynamicHii 
> PCD set failure is a legal case.

I almost had a question here ("why?"), but looking at
"MdeModulePkg/Universal/PCD/Dxe/Pcd.inf", I know why -- because
PcdsDynamicHii is stored in the non-volatile varstore.

> For this case, PcdS3BootScriptTablePrivateDataPtr and 
> PcdS3BootScriptTablePrivateSmmDataPtr are expected to be DynamicDefault,
> so use PcdSet64S to instead of PcdSet64 and assert when set failure.

Okay, so this I don't understand.

First, I don't think that any platform would like to store S3
bootscript-related stuff in nv variables.

Second, "MdeModulePkg/MdeModulePkg.dec" restricts these PCDs to
[PcdsDynamic, PcdsDynamicEx], so no platform DSC can make them
PcdsDynamicHii.

Therefore, I guess the patch is correct, but why is it necessary? Is it
just to be compatible with DISABLE_NEW_DEPRECATED_INTERFACES?

Ah, I see. The commit message has three parts / arguments actually:

(1) general description of status checking vs. non-checking interfaces
(2) argument why we should move to checked interfaces
(3) argument why the check will always succeed.

Thanks
Laszlo


> 
> Cc: Jiewen Yao 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Star Zeng 
> ---
>  MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c 
> b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
> index 24c6798..e7d2a24 100644
> --- a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
> +++ b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
> @@ -454,7 +454,8 @@ S3BootScriptLibInitialize (
>  }
>  S3TablePtr = (VOID *) (UINTN) Buffer;
>  
> -PcdSet64 (PcdS3BootScriptTablePrivateDataPtr, (UINT64) 
> (UINTN)S3TablePtr); 
> +Status = PcdSet64S (PcdS3BootScriptTablePrivateDataPtr, (UINT64) 
> (UINTN)S3TablePtr);
> +ASSERT_EFI_ERROR (Status);
>  ZeroMem (S3TablePtr, sizeof(SCRIPT_TABLE_PRIVATE_DATA));  
>  //
>  // Create event to notify the library system enter the SmmLocked phase.
> @@ -506,7 +507,8 @@ S3BootScriptLibInitialize (
>return RETURN_OUT_OF_RESOURCES;
>  }
>  
> -PcdSet64 (PcdS3BootScriptTablePrivateSmmDataPtr, (UINT64) 
> (UINTN)S3TableSmmPtr);
> +Status = PcdSet64S (PcdS3BootScriptTablePrivateSmmDataPtr, (UINT64) 
> (UINTN)S3TableSmmPtr);
> +ASSERT_EFI_ERROR (Status);
>  ZeroMem (S3TableSmmPtr, sizeof(SCRIPT_TABLE_PRIVATE_DATA));
>  
>  //
> 

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

Re: [edk2] Driver Health Protocol, UI interaction and Intel DQ77MK vs. OVMF

[Bruce Cran]

On 10/8/15 9:04 PM, Ni, Ruiyu wrote:


OVMF used the old IntelFrameworkModulePkg/BDS.
The new MdeModulePkg/BDS automatically invokes the reparation upon boot.
I did a draft patch
(http://article.gmane.org/gmane.comp.bios.edk2.devel/759) but do not
have time to edit it to follow the review comments.
I may not have time to do it in this year. If it's urgent to you, you
can try this draft patch. It will be great if you can help to edit the
patch and get it reviewed and checked in to the OVMF Pkg.


Ah, thanks!
So currently if a device is required to boot, I guess the driver would 
need to automatically initiate the repair operation during the load 
process?   The card I'm working with is unfortunately rather easy to get 
into a state where a repair is needed; so it sounds as though I might 
need to wait until UEFI 2.6 or so until it will be safe to assume that 
the platform will automatically initiate a repair?


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

Re: [edk2] [PATCH 6/7] UefiCpiPkg: Add PiSmmCpuDxeSmm module

[Laszlo Ersek]

On 10/08/15 23:22, Kinney, Michael D wrote:
> Hi Laszlo,
> 
> A couple responses below.

Thanks much (again!); I think I can rework CpuS3DataDxe based on your
advice:

> 
> Mike
> 
>> -Original Message-
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Thursday, October 08, 2015 11:37 AM
>> To: Kinney, Michael D
>> Cc: edk2-de...@ml01.01.org
>> Subject: Re: [edk2] [PATCH 6/7] UefiCpiPkg: Add PiSmmCpuDxeSmm module

[snip]

>> Let my try to go through the fields of ACPI_CPU_DATA again, and see how
>> my CpuS3DataDxe could interace with the PiSmmCpuDxeSmm driver in this
>> patch:
>>
>> - APState was one that I removed from both drivers. We've discussed
>>  this above -- even keeping it wouldn't cause CpuS3DataDxe problems.
>>
>> - StartupVector is a strange field. In Quark, CpuMpDxe allocated it and
>>  populated it, and PiSmmCpuDxeSmm overwrote its contents during S3
>>  resume (which was fine), but not with the original contents saved to,
>>  and restored from, SMRAM, but with its *own* code.
>>
>>  IOW, PiSmmCpuDxeSmm only relied, at S3 resume, on the reserved
>>  buffer's *allocation*, which had been made by CpuMpDxe previously
>>  (= during boot). For that reason in CpuS3DataDxe, I didn't bother to
>>  fill in the buffer at all, just to allocate it.
> 
> Correct.  The requirement is to allocate a 4KB aligned buffer that is
> 4KB is size in usable memory below 1MB.
> 
>>
>>  *Plus* I added an ASSERT() to PiSmmCpuDxeSmm (function
>>  PrepareApStartupVector()) about the size of the pre-allocated buffer
>>  (constant 4KB) being big enough for the actual communications area,
>>  and the executable code, that PiSmmCpuDxeSmm would copy into it.
>>
>>  As far as I can see, in the PrepareApStartupVector() function in your
>>  patch 6/7, this silent size assumption (i.e., without an explicit
>>  assert) still exist. Am I correct?
> 
> Yes.  I agree that is a bad assumption.  We either need to state that
> 4KB is always enough, or we need a way for the module that allocates
> the buffer to know the size of the buffer required.  
> 
>>
>>  This is not necessarily a bug, but it should be spelled out as one of
>>  the requirements between CpuS3DataDxe and PiSmmCpuDxeSmm, so that
>> the
>>  former can accommodate the latter -- and the latter should preferably
>>  *enforce* that somehow.
>>
> 
> Agreed

For now I'll just stick with the current allocation in CpuS3DataDxe.

> 
>> - The (a) GdtrProfile, IdtrProfile, ApMachineCheckHandlerBase,
>>  ApMachineCheckHandlerSize; (b) StackAddress and StackSize; and
>>  (c) NumberOfCpus fields were filled in in three more patches. I
>>  assume the CpuS3DataDxe code would work with *this* PiSmmCpuDxeSmm
>>  too.
>>
>> Now, the trouble starts with the following fields:
>>
>> - The MTRR settings (in the MtrrTable field) are saved in a delayed
>>  manner, that is, not when CpuS3DataDxe collects the other data. This
>>  is why I had to write patches for UefiCpuPkg/CpuDxe too, so that it
>>  would reflect the most recent MTRR settings to a spot where
>>  PiSmmCpuDxeSmm could find them at SMM-ready-to-lock. Again I assume
>>  the (minimal) code currently in CpuS3DataDxe would work with *this*
>>  PiSmmCpuDxeSmm, however the functionality ultimately depends on
>>  UefiCpuPkg/CpuDxe changes too.
> 
> You could add an event to CpuS3DataDxe that save MTRR settings
> Into the structure at end of DXE.  On simple platforms, there may
> Not be any different in MTRR settings between the time the CPU driver
> runs and the end of DXE.  In that case, the MTRR settings can be 
> captured when the CPU driver runs and fills in the structure.

Saving MTRR settings and End-of-DXE is a great idea!

OVMF's BDS triggers End-of-DXE not much before it kicks
DxeSmmReadyToLock too (which in turn gets reflected as SmmReadyToLock to
SMM drivers, and then PiSmmCpuDxeSmm fetches and stashes ACPI_CPU_DATA
into SMRAM), and I think it's reasonable *not* to expect MTRR changes
between those two actions, within BDS.

With regard to my other UefiCpuPkg/CpuDxe patches, I think I'll keep
some of them, independently:
- "broadcast MTRR changes to APs"
- "sync MTRR settings to APs at MP startup"
- "provide EFI_MP_SERVICES_PROTOCOL when there's no AP"

because they seem useful. (I'll have to adapt them to your patches of
course.)

>> - PreSmmInitRegisterTable. The handling of this field in Quark's
>>  PiSmmCpuDxeSmm had a security bug (the registers weren't stashed in
>>  SMRAM between boot and S3 resume), but I can see that it is fixed in
>>  your patch, so that's great. However, since CpuMpDxe went to great
>>  lengths to put (ultimately) "nothing" in PreSmmInitRegisterTable, I
>>  decided to drop the field even from PiSmmCpuDxeSmm.
>>
>>  (See the commit message of "OvmfPkg: QuarkPort: drop
>>  ACPI_CPU_DATA.PreSmmInitRegisterTable".)
>>
>>  Now, this won't fly if CpuS3DataDxe has to talk to *this*
>>  PiSmmCpuDxeSmm. Hence I'll need to learn about a way to put a
>>  "well-formed nothing" in 

Re: [edk2] [PATCH] MdeModulePkg PiDxeS3BootScriptLib: Use PcdSet64S to instead of PcdSet64

[Zeng, Star]

On 2015/10/9 6:33, Andrew Fish wrote:



On Oct 8, 2015, at 3:11 PM, Laszlo Ersek  wrote:

On 10/08/15 09:39, Star Zeng wrote:

PcdSet## has no error status returned, then the caller has no idea about 
whether the set operation is successful or not.
PcdSet##S were added to return error status and PcdSet## APIs were put in 
ifndef DISABLE_NEW_DEPRECATED_INTERFACES condition.
To adopt PcdSet##S and further code development with 
DISABLE_NEW_DEPRECATED_INTERFACES defined, we need to Replace PcdSet## usage 
with PcdSet##S.

Normally, DynamicDefault PCD set is expected to be success, but DynamicHii PCD 
set failure is a legal case.


I almost had a question here ("why?"), but looking at
"MdeModulePkg/Universal/PCD/Dxe/Pcd.inf", I know why -- because
PcdsDynamicHii is stored in the non-volatile varstore.


For this case, PcdS3BootScriptTablePrivateDataPtr and 
PcdS3BootScriptTablePrivateSmmDataPtr are expected to be DynamicDefault,
so use PcdSet64S to instead of PcdSet64 and assert when set failure.


Okay, so this I don't understand.

First, I don't think that any platform would like to store S3
bootscript-related stuff in nv variables.



Historically I think there is an ACPI NVS memory region that the variable 
pointed to (going from memory so I may be a little off).
The newer code uses the LockBox that is usually stored in SMM.


Second, "MdeModulePkg/MdeModulePkg.dec" restricts these PCDs to
[PcdsDynamic, PcdsDynamicEx], so no platform DSC can make them
PcdsDynamicHii.



This is just confusing terminology/syntax….

 From the DEC and INF point of view:
PcdDynamic means you use the PCD PPI/Protocol with the build generated Token
PcdDynamicEx means you use the PCD PPI/Protocol with the fixed Token and 
EFI_GUID from the .DEC.

The DSC file also has a knob that controls how dynamic PCDs are stored. So 
PcdsDynamicHii is a PcdDynamic form, but the driver that implements the 
PPI/Protocol stores the data in an alternate location.


Right, thanks for the explanation.

Star



Thanks,

Andrew Fish


Therefore, I guess the patch is correct, but why is it necessary? Is it
just to be compatible with DISABLE_NEW_DEPRECATED_INTERFACES?

Ah, I see. The commit message has three parts / arguments actually:

(1) general description of status checking vs. non-checking interfaces
(2) argument why we should move to checked interfaces
(3) argument why the check will always succeed.

Thanks
Laszlo




Cc: Jiewen Yao 
Cc: Liming Gao 
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng 
---
MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c 
b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
index 24c6798..e7d2a24 100644
--- a/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
+++ b/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c
@@ -454,7 +454,8 @@ S3BootScriptLibInitialize (
 }
 S3TablePtr = (VOID *) (UINTN) Buffer;

-PcdSet64 (PcdS3BootScriptTablePrivateDataPtr, (UINT64) (UINTN)S3TablePtr);
+Status = PcdSet64S (PcdS3BootScriptTablePrivateDataPtr, (UINT64) 
(UINTN)S3TablePtr);
+ASSERT_EFI_ERROR (Status);
 ZeroMem (S3TablePtr, sizeof(SCRIPT_TABLE_PRIVATE_DATA));
 //
 // Create event to notify the library system enter the SmmLocked phase.
@@ -506,7 +507,8 @@ S3BootScriptLibInitialize (
   return RETURN_OUT_OF_RESOURCES;
 }

-PcdSet64 (PcdS3BootScriptTablePrivateSmmDataPtr, (UINT64) 
(UINTN)S3TableSmmPtr);
+Status = PcdSet64S (PcdS3BootScriptTablePrivateSmmDataPtr, (UINT64) 
(UINTN)S3TableSmmPtr);
+ASSERT_EFI_ERROR (Status);
 ZeroMem (S3TableSmmPtr, sizeof(SCRIPT_TABLE_PRIVATE_DATA));

 //



___
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] [PATCH 08/58] OvmfPkg: PlatformPei: account for TSEG size with PcdSmmSmramRequire set

[Laszlo Ersek]

Hi Jordan,

On 09/07/15 02:27, Jordan Justen wrote:
> Patches 7 & 8 Reviewed-by: Jordan Justen 

Thanks!

I addressed the comments I received thus far (I'm just not posting v2
yet). Ultimately I'll rebase this series to Mike's new, central
PiSmmCpuDxeSmm module (see it in "[edk2] [PATCH 0/7] UefiCpuPkg: Add CPU
SMM and SecCore"), and hopefully on even more central (or example)
driver code from him.

That should allow me to cut a huge chunk out of the middle of this series.

But, the parts starting at

"OvmfPkg: add PEIM for providing TSEG-as-SMRAM during PEI" (09/58)

and at

"OvmfPkg: QemuFlashFvbServicesRuntimeDxe: strip trailing whitespace" (46/58)

are really QEMU and/or OVMF-specific. Can you please continue reviewing
those?

Thanks!
Laszlo

> 
> On 2015-07-24 16:00:14, Laszlo Ersek wrote:
>> PlatformPei calls GetSystemMemorySizeBelow4gb() in three locations:
>>
>> - PublishPeiMemory(): on normal boot, the permanent PEI RAM is installed
>>   so that it ends with the RAM below 4GB,
>>
>> - QemuInitializeRam(): on normal boot, memory resource descriptor HOBs are
>>   created for the RAM below 4GB; plus MTRR attributes are set
>>   (independently of S3 vs. normal boot)
>>
>> - MemMapInitialization(): an MMIO resource descriptor HOB is created for
>>   PCI resource allocation, on normal boot, starting at max(RAM below 4GB,
>>   2GB).
>>
>> The first two of these is adjusted for the configured TSEG size, if
>> PcdSmmSmramRequire is set:
>>
>> - In PublishPeiMemory(), the permanent PEI RAM is kept under TSEG.
>>
>> - In QemuInitializeRam(), we must keep the DXE out of TSEG.
>>
>>   One idea would be to simply trim the [1MB .. LowerMemorySize] memory
>>   resource descriptor HOB, leaving a hole for TSEG in the memory space
>>   map.
>>
>>   The SMM IPL will however want to massage the caching attributes of the
>>   SMRAM range that it loads the SMM core into, with
>>   gDS->SetMemorySpaceAttributes(), and that won't work on a hole. So,
>>   instead of trimming this range, split the TSEG area off, and report it
>>   as a cacheable reserved memory resource.
>>
>>   Finally, since reserved memory can be allocated too, pre-allocate TSEG
>>   in InitializeRamRegions(), after QemuInitializeRam() returns. (Note that
>>   this step alone does not suffice without the resource descriptor HOB
>>   trickery: if we omit that, then the DXE IPL PEIM fails to load and start
>>   the DXE core.)
>>
>> - In MemMapInitialization(), the start of the PCI MMIO range is not
>>   affected.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek 
>> ---
>>  OvmfPkg/PlatformPei/PlatformPei.inf |  1 +
>>  OvmfPkg/PlatformPei/MemDetect.c | 34 +++-
>>  OvmfPkg/OvmfPkg.dec |  7 
>>  3 files changed, 41 insertions(+), 1 deletion(-)
>>
>> diff --git a/OvmfPkg/PlatformPei/PlatformPei.inf 
>> b/OvmfPkg/PlatformPei/PlatformPei.inf
>> index b9b0b20..0bf4c38 100644
>> --- a/OvmfPkg/PlatformPei/PlatformPei.inf
>> +++ b/OvmfPkg/PlatformPei/PlatformPei.inf
>> @@ -76,6 +76,7 @@ [Pcd]
>>gUefiOvmfPkgTokenSpaceGuid.PcdGuidedExtractHandlerTableSize
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfHostBridgePciDevId
>>gUefiOvmfPkgTokenSpaceGuid.PcdOvmfDecomprScratchEnd
>> +  gUefiOvmfPkgTokenSpaceGuid.PcdQ35TsegMbytes
>>gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdS3AcpiReservedMemorySize
>>gEfiMdePkgTokenSpaceGuid.PcdGuidedExtractHandlerTableAddress
>>gEfiMdeModulePkgTokenSpaceGuid.PcdVariableStoreSize
>> diff --git a/OvmfPkg/PlatformPei/MemDetect.c 
>> b/OvmfPkg/PlatformPei/MemDetect.c
>> index 649b484..cb3f3dd 100644
>> --- a/OvmfPkg/PlatformPei/MemDetect.c
>> +++ b/OvmfPkg/PlatformPei/MemDetect.c
>> @@ -214,6 +214,12 @@ PublishPeiMemory (
>>  MemorySize = PcdGet32 (PcdS3AcpiReservedMemorySize);
>>} else {
>>  LowerMemorySize = GetSystemMemorySizeBelow4gb ();
>> +if (FeaturePcdGet (PcdSmmSmramRequire)) {
>> +  //
>> +  // TSEG is chipped from the end of low RAM
>> +  //
>> +  LowerMemorySize -= FixedPcdGet8 (PcdQ35TsegMbytes) * SIZE_1MB;
>> +}
>>  
>>  PeiMemoryCap = GetPeiMemoryCap ();
>>  DEBUG ((EFI_D_INFO, "%a: mPhysMemAddressWidth=%d PeiMemoryCap=%u KB\n",
>> @@ -277,7 +283,18 @@ QemuInitializeRam (
>>  // Create memory HOBs
>>  //
>>  AddMemoryRangeHob (0, BASE_512KB + BASE_128KB);
>> -AddMemoryRangeHob (BASE_1MB, LowerMemorySize);
>> +
>> +if (FeaturePcdGet (PcdSmmSmramRequire)) {
>> +  UINT32 TsegSize;
>> +
>> +  TsegSize = FixedPcdGet8 (PcdQ35TsegMbytes) * SIZE_1MB;
>> +  AddMemoryRangeHob (BASE_1MB, LowerMemorySize - TsegSize);
>> +  AddReservedMemoryBaseSizeHob (LowerMemorySize - TsegSize, TsegSize,
>> +TRUE);
>> +} else {
>> +  AddMemoryRangeHob (BASE_1MB, LowerMemorySize);
>> +}
>> +
>>  if (UpperMemorySize != 0) {
>>AddUntestedMemoryBaseSizeHob (BASE_4GB, UpperMemorySize);
>>  }
>> @@ -409,5 

Re: [edk2] [PATCH v2 00/16] unify GCC command line options

[Bill Paul]

Of all the gin joints in all the towns in all the world, Bill Paul had to walk 
into mine at 10:30:26 on Monday 24 August 2015 and say:

> Of all the gin joints in all the towns in all the world, Ard Biesheuvel had
> to
> 
> walk into mine at 10:22:59 on Monday 24 August 2015 and say:
> > On 24 August 2015 at 19:20, Bill Paul  wrote:
> > > Of all the gin joints in all the towns in all the world, Ard Biesheuvel
> > > had to
> > > 
> > > walk into mine at 10:06:10 on Monday 24 August 2015 and say:
> > >> On 24 August 2015 at 19:02, Bill Paul  wrote:
> > >> > Of all the gin joints in all the towns in all the world, Ard
> > >> > Biesheuvel had to
> > 
> > >> > walk into mine at 09:54:08 on Monday 24 August 2015 and say:
> > [...]
> > 
> > >> >> Jordan suggested to drop UNIXGCC as well, and introduce MINGW
> > >> >> instead iff we want the MinGW PE/COFF GCC, and I think we do, if
> > >> >> only so that we have a LLP64 environment for X64 available to
> > >> >> those without the possibility or the desire to run a MS toolchains
> > >> >> under Windows.
> > >> > 
> > >> > People should be able to build a known-good crossbuild toolchain.
> > >> > This is the simplest way to provide that option.
> > >> 
> > >> Meh. The primary audience of this feature are people building UEFI for
> > >> X64 on X64, in which case the GCC4x options are arguably simpler. But
> > >> apparently we agree that we should keep it /and/ support it.
> > >> 
> > >> > By the way, do you think I can get you to update the
> > >> > mingw-gcc-build.py script while you're at it? :)
> > >> 
> > >> I proposed some updates here
> > >> http://thread.gmane.org/gmane.comp.bios.edk2.devel/1297
> > >> (with you on cc). Care to ack those?
> > > 
> > > Is there a particular reason why you chose to use binutils from
> > > www.kernel.org rather than from ftpmirror.gnu.org (other than "that's
> > > what it was doing before")?
> > 
> > Nope, that was it :-)
> > 
> > In fact, I vaguely remember noticing the kernel.org URL and thinking
> > "hmm that's odd" but for some reason, it did not provoke any action on
> > my part
> 
> My attention was drawn to it before because the specific version the script
> was looking for previously ceased to exist on www.kernel.org, which broke
> the script.
> 
> > > In my testing I used binutins 2.25 from gnu.org, and it worked ok. I
> > > thought it made more sense to get both packages from the same place.
> > > 
> > > source_files_common = {
> > > 
> > > 'binutils': {
> > > 
> > > 'url': 'http://ftpmirror.gnu.org/binutils/' + \
> > > 
> > >'binutils-$version.tar.bz2',
> > > 
> > > 'version': '2.25',
> > > 'md5': 'd9f3303f802a5b6b0bb73a335ab89d66',
> > > },
> > > 
> > > }
> > 
> > Yes, 2.25 would be even better. In fact, it might make sense to wait
> > for 2.26 to appear, since it adds support for --gc-sections (see the
> > other part of this thread) which brings performance of mingw in line
> > with ELF based GCC regarding code size.
> 
> Fair enough, as long as we don't have to wait too long. In any case, aside
> from this, the changes look ok to me.
> 
> -Bill

So... about that "as long as we don't have to wait too long" thing? I think 
it's been too long. :)

-Bill

-- 
=
-Bill Paul(510) 749-2329 | Senior Member of Technical Staff,
 wp...@windriver.com | Master of Unix-Fu - Wind River Systems
=
   "I put a dollar in a change machine. Nothing changed." - George Carlin
=
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel