Re: [edk2] [PATCH 2/2] MdeModulePkg: Check D2H register status in AhciPioTransfer

[Tian, Feng]

Thanks Sava and Reza, it makes sense now.

Reviewed-by: Feng Tian 

-Original Message-
From: Reza Jelveh [mailto:reza.jel...@tuhh.de] 
Sent: Thursday, August 14, 2014 02:15
To: Tian, Feng
Cc: edk2-devel@lists.sourceforge.net; ag...@suse.de
Subject: Re: [edk2] [PATCH 2/2] MdeModulePkg: Check D2H register status in 
AhciPioTransfer

On 13/08/14 01:04, Tian, Feng wrote:
> Hi, Reza
> 
> Thanks for your effort, Reza. I made a little coding style enhancement based 
> on your proposed patch. please help view it.
> 
> PS: I am a little curious on "some Marvel controllers use D2H only instead of 
> PIO Setup FIS". If it's that case, does it mean current logic will never 
> break out the loop? Do we need enhance code to handle this?
No it won't break out, but the will instead time out. A. Sava explained the 
issue in his.

I'm attaching a patch with the things we talked about, but this results in 
duplicate code. There is only a little thing i can think of to reduce the 
duplicate breaks.

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [IntelFrameworkModulePkg] maintainer: LegacyBiosDxe thunk driver does not link with Xcode/clang.

[Li, Elvin]

Andrew:

It is good to me.



Reviewed-by: Elvin Li mailto:elvin...@intel.com>>

Thanks
Elvin
From: Andrew Fish [mailto:af...@apple.com]
Sent: Thursday, August 07, 2014 1:06 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [IntelFrameworkModulePkg] maintainer: LegacyBiosDxe thunk 
driver does not link with Xcode/clang.

LegacyBiosInt86() sets a pointer to 0 and dereferences it. From a C standard 
point of view this is considered undefined behavior. The clang optimizer emits 
a trap instruction and throws all the code after the reference away. The trap 
is replaced via a compiler flag to be a function that does not exist, and thus 
this is why we get a link failure.

The optimizer needs to avoid optimizations on a volatile variable, so the only 
safe way to write to zero in C is to use a volatile variable.   See 
http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Anderw Fish mailto:af...@apple.com>>

~/work/src/edk2(master)>git diff 
IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c
diff --git a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c 
b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c
index 3d9a8b9..a5d2f14 100644
--- a/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c
+++ b/IntelFrameworkModulePkg/Csm/LegacyBiosDxe/Thunk.c
@@ -57,7 +57,7 @@ LegacyBiosInt86 (
   IN  EFI_IA32_REGISTER_SET *Regs
   )
 {
-  UINT32  *VectorBase;
+  volatile UINT32  *VectorBase;


   Regs->X.Flags.Reserved1 = 1;
   Regs->X.Flags.Reserved2 = 0;


Thanks,

Andrew Fish

PS I finally got around to testing clang out on OVFM. Right now I'm in a "World 
of Hurt"(TM) trying to get UefiCpuPkg/Library/CpuExceptionHandlerLib to work. 
It seems that CpuExceptionHandlerLib assembly has a lot of X64 relocations that 
the Xcode linker does not support.
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

[Gao, Liming]

Yes. This is a possible solution. But, svn generated patch for UTF16 file is 
not good readability. 

This patch adds new UNI files. You can see them from ZIP files. 

Thanks
Liming
-Original Message-
From: El-Haj-Mahmoud, Samer [mailto:samer.el-haj-mahm...@hp.com] 
Sent: Thursday, August 14, 2014 10:26 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

Can we change the file encoding type svn property for uni files to make them 
utf16 instead of binary stream? This way we can actually include uni files in 
patches and see what changed.









-Original Message-
From: Gao, Liming [liming@intel.com]
Received: Wednesday, 13 Aug 2014, 9:17PM
To: edk2-devel@lists.sourceforge.net [edk2-devel@lists.sourceforge.net]
Subject: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

Hi, all
  Could you help review this patch? It includes the following changes 1-6 for 
MdePkg. The patch is a little big. For new added UNI file, I zip them together.

  The second patch for below item 7 will be sent later

Thanks
Liming
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Thursday, August 07, 2014 5:32 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] INF/DEC file updates to EDK II packages

Hello,

I wanted to let everyone know about a number of patch reviews for EDK II 
packages that will be sent out over the next couple of weeks.  These patches 
impact the order of content in INF/DEC files and comment blocks in INF/DEC 
files, and should not have any build or functionality impacts.  These patches 
will address the following issues:


1)  Usage information in INF file comment blocks are either incomplete or 
incorrect.  This includes usage information for 
Protocols/PPIs/GUIDs/PCDs/HOBs/Events/BootModes.  The syntax for usage 
information in comment blocks is defined in the EDK II Module Information (INF) 
Specification

2)  Add MODULE_UNI_FILE to INF [Defines] section along with UNI file that 
contains the localized Abstract and Description of a module.

a.   Addresses an information gap between INF files and the UEFI 
Distribution Packaging Specification XML schema

b.  There will be an associated update to UPT in BaseTools to consume 
MODULE_UNI_FILE and associated UNI file during UDP creation that performs the 
INF -> XML conversion.

c.   There will be an associated update to UPT in BaseTools to produce 
MODULE_UNI_FILE and associated UNI file during UDP installation that performs 
the XML -> INF conversion.

3)  Add [UserExtensions.TianoCore."ExtraFiles"] section to INF files along 
with associated UNI file that provides the localized Name of a module.

a.   [UserExtensions.TianoCore."ExtraFiles"] provides an easy method for a 
module to specify extra files not listed in [Sources] or [Binaries] sections to 
be added to a UDP without having to list the files in the UPT package 
information data file.

b.  There will be an associated update to UPT in BaseTools to package up 
files listed in [UserExtensions.TianoCore."ExtraFiles"] during UDP creation.

c.   UNI file contains localized name of a module to go along with the 
localized Abstract and Description from the MODULE_UNI_FILE.

4)  PCD information in DEC file comment blocks are either incomplete or 
incorrect.  This includes detailed description, @Prompt, @ValidRange, 
@ValidList, @Expression, and [Error.] validation error messages

5)  Add PACKAGE_UNI_FILE to DEC [Defines] section along with UNI file that 
contains the localized Abstract and Description of a package and localized 
strings associated with PCDs.

a.   Addresses an information gap between DEC files and the UEFI 
Distribution Packaging Specification XML schema

b.  There will be an associated update to UPT in BaseTools to consume 
PACKAGE_UNI_FILE and associated UNI file during UDP creation that performs the 
DEC -> XML conversion.

c.   There will be an associated update to UPT in BaseTools to produce 
PACKAGE_UNI_FILE and associated UNI file during UDP installation that performs 
the XML -> DEC conversion.

6)  Add [UserExtensions.TianoCore."ExtraFiles"] section to DEC files along 
with associated UNI file that provides the localized Name of a package.

a.   [UserExtensions.TianoCore."ExtraFiles"] provides an easy method for a 
package to specify extra files to be added to a UDP without having to list the 
files in the UPT package information data file.

b.  There will be an associated update to UPT in BaseTools to package up 
files listed in [UserExtensions.TianoCore."ExtraFiles"] during UDP creation.

c.   UNI file contains localized name of a package to go along with the 
localized Abstract and Description from the PACKAGE_UNI_FILE.

7)  Make sure order of DEC/INF content matches the order that UPT generates 
in the XML -> INF conversion

a.   This allows UDP packages installed by UPT to b

Re: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

[El-Haj-Mahmoud, Samer]

Can we change the file encoding type svn property for uni files to make them 
utf16 instead of binary stream? This way we can actually include uni files in 
patches and see what changed.









-Original Message-
From: Gao, Liming [liming@intel.com]
Received: Wednesday, 13 Aug 2014, 9:17PM
To: edk2-devel@lists.sourceforge.net [edk2-devel@lists.sourceforge.net]
Subject: [edk2] [Patch 1/2] [MdePkg] INF/DEC file updates to EDK II packages

Hi, all
  Could you help review this patch? It includes the following changes 1-6 for 
MdePkg. The patch is a little big. For new added UNI file, I zip them together.

  The second patch for below item 7 will be sent later

Thanks
Liming
From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Thursday, August 07, 2014 5:32 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] INF/DEC file updates to EDK II packages

Hello,

I wanted to let everyone know about a number of patch reviews for EDK II 
packages that will be sent out over the next couple of weeks.  These patches 
impact the order of content in INF/DEC files and comment blocks in INF/DEC 
files, and should not have any build or functionality impacts.  These patches 
will address the following issues:


1)  Usage information in INF file comment blocks are either incomplete or 
incorrect.  This includes usage information for 
Protocols/PPIs/GUIDs/PCDs/HOBs/Events/BootModes.  The syntax for usage 
information in comment blocks is defined in the EDK II Module Information (INF) 
Specification

2)  Add MODULE_UNI_FILE to INF [Defines] section along with UNI file that 
contains the localized Abstract and Description of a module.

a.   Addresses an information gap between INF files and the UEFI 
Distribution Packaging Specification XML schema

b.  There will be an associated update to UPT in BaseTools to consume 
MODULE_UNI_FILE and associated UNI file during UDP creation that performs the 
INF -> XML conversion.

c.   There will be an associated update to UPT in BaseTools to produce 
MODULE_UNI_FILE and associated UNI file during UDP installation that performs 
the XML -> INF conversion.

3)  Add [UserExtensions.TianoCore.”ExtraFiles”] section to INF files along 
with associated UNI file that provides the localized Name of a module.

a.   [UserExtensions.TianoCore.”ExtraFiles”] provides an easy method for a 
module to specify extra files not listed in [Sources] or [Binaries] sections to 
be added to a UDP without having to list the files in the UPT package 
information data file.

b.  There will be an associated update to UPT in BaseTools to package up 
files listed in [UserExtensions.TianoCore.”ExtraFiles”] during UDP creation.

c.   UNI file contains localized name of a module to go along with the 
localized Abstract and Description from the MODULE_UNI_FILE.

4)  PCD information in DEC file comment blocks are either incomplete or 
incorrect.  This includes detailed description, @Prompt, @ValidRange, 
@ValidList, @Expression, and [Error.] validation error messages

5)  Add PACKAGE_UNI_FILE to DEC [Defines] section along with UNI file that 
contains the localized Abstract and Description of a package and localized 
strings associated with PCDs.

a.   Addresses an information gap between DEC files and the UEFI 
Distribution Packaging Specification XML schema

b.  There will be an associated update to UPT in BaseTools to consume 
PACKAGE_UNI_FILE and associated UNI file during UDP creation that performs the 
DEC -> XML conversion.

c.   There will be an associated update to UPT in BaseTools to produce 
PACKAGE_UNI_FILE and associated UNI file during UDP installation that performs 
the XML -> DEC conversion.

6)  Add [UserExtensions.TianoCore.”ExtraFiles”] section to DEC files along 
with associated UNI file that provides the localized Name of a package.

a.   [UserExtensions.TianoCore.”ExtraFiles”] provides an easy method for a 
package to specify extra files to be added to a UDP without having to list the 
files in the UPT package information data file.

b.  There will be an associated update to UPT in BaseTools to package up 
files listed in [UserExtensions.TianoCore.”ExtraFiles”] during UDP creation.

c.   UNI file contains localized name of a package to go along with the 
localized Abstract and Description from the PACKAGE_UNI_FILE.

7)  Make sure order of DEC/INF content matches the order that UPT generates 
in the XML -> INF conversion

a.   This allows UDP packages installed by UPT to be compared against EDK 
II trunk/branches using standard diff utilities.

Patches for the following EDK II packages are being prepared

1)  MdePkg

2)  MdeModulePkg

3)  IntelFrameworkPkg

4)  IntelFrameworkModulePkg

5)  FatPkg

6)  ShellPkg

7)  PcAtChipsetPkg

8)  UefiCpuPkg

9)  SourceLevelDebugPkg

10)   CryptoPkg

11)   SecurityPkg

12)   NetworkPkg

Best regards,

Mike


--

Re: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature Verification Modules/Libraries

[Liu, Yingke D]

Mike,

The basetools part is good to me.
Reviewed-by: Yingke Liu 

Dennis

From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Tuesday, August 12, 2014 11:39 AM
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature 
Verification Modules/Libraries

Hello,

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney  
mailto:michael.d.kin...@intel.com>>

I have attached a set of patches for review that provide support for RSA 2048 
SHA 256 signing and verification encoded in a PI FFS GUIDED Encapsulation 
Section.  The primary use case of this feature is in support of signing and 
verification of encapsulated FVs for Recovery and Capsule Update, but can 
potentially be used for signing and verification of any content that can be 
stored in a PI conformant FFS file.  Signing operations are performed from 
python scripts that wrap OpenSsl command line utilities.  Verification 
operations are performed using the OpenSsl libraries in the CryptoPkg.

The guided encapsulation sections uses the UEFI 2.4 Specification defined GUID 
called EFI_CERT_TYPE_RSA2048_SHA256_GUID.  The data layout for the 
encapsulation section starts with the UEFI 2.4 Specification defined structure 
called EFI_CERT_BLOCK_RSA_2048_SHA256 followed immediately by the data.  The 
signing tool included in these patches performs encode/decode operations using 
this data layout.  HashType is set to the UEFI 2.4 Specification defined GUID 
called EFI_HASH_ALGORITHM_SHA256_GUID.

MdePkg/Include/Guid/WinCertificate.h
=
//
// WIN_CERTIFICATE_UEFI_GUID.CertType
//
#define EFI_CERT_TYPE_RSA2048_SHA256_GUID \
  {0xa7717414, 0xc616, 0x4977, {0x94, 0x20, 0x84, 0x47, 0x12, 0xa7, 0x35, 0xbf 
} }

///
/// WIN_CERTIFICATE_UEFI_GUID.CertData
///
typedef struct {
  EFI_GUID  HashType;
  UINT8 PublicKey[256];
  UINT8 Signature[256];
} EFI_CERT_BLOCK_RSA_2048_SHA256;

MdePkg/Include/Protocol/Hash.h
=
#define EFI_HASH_ALGORITHM_SHA256_GUID \
  { \
0x51aa59de, 0xfdf2, 0x4ea3, {0xbc, 0x63, 0x87, 0x5f, 0xb7, 0x84, 0x2e, 0xe9 
} \
  }

The verification operations require the use of public key(s).  A new PCD called 
gEfiSecurityPkgTokenSpaceGuid.PcdRsa2048Sha256PublicKeyBuffer is added to the 
SecurityPkg that supports one or more SHA 256 hashes of the public keys.  A SHA 
256 hash is performed to minimize the FLASH overhead of storing the public 
keys.  When a verification operation is performed, a SHA 256 hash is performed 
on EFI_CERT_BLOCK_RSA_2048_SHA256.PublicKey and a check is made to see if that 
hash matches any of the hashes in the new PCD.  It is recommended that this PCD 
always be configured in the DSC file as storage type of [PcdsDynamixExVpd], so 
the public keys are stored in a protected read-only region.

While working on this feature, I noticed that the CRC32 signing and 
verification feature was incomplete.  It only supported CRC32 based 
verification in the DXE Phase, so the attached patches also provide support for 
CRC32 based verification in the PEI Phase.

I also noticed that the most common method for incorporating guided section 
extraction libraries was to directly link them to the DXE Core, which is not 
very flexible.  The attached patches also add a generic section extraction PEIM 
and a generic section extraction DXE driver that can each be linked against one 
or more section extraction libraries.  This provides a platform developer with 
the option of providing section extraction services with the DXE Core or 
providing section extraction services with these generic PEIM/DXE Drivers.

Patch Summary
==

1)  BaseTools - Rsa2049Sha256Sign python script that can perform test 
signing or custom signing of PI FFS file GUIDed sections

a.   Wrapper for a set of OpenSsl command line utility operations

b.  OpenSsl command line tool must be installed in location that is in 
standard OS path or in path specified by OS environment variable called 
OPENSSL_PATH

c.   Provides standard EDK II command line arguments for a tool that 
encodes/decodes guided encapsulation section

Rsa2048Sha256Sign - Copyright (c) 2013 - 2014, Intel Corporation. All rights 
reserved.
usage: Rsa2048Sha256Sign -e|-d [options] 

positional arguments:
  input_filespecify the input filename

optional arguments:
  -eencode file
  -ddecode file
  -o filename, --output filename
specify the output filename
  --private-key PRIVATEKEYFILE
specify the private key filename. If not specified, a
test signing key is used.
  -v, --verbose increase output messages
  -q, --quiet   reduce output messages
  --debug [0-9] set debug level
  --version display the program version and exit
  -h, --helpdisplay this help text


2)  

Re: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature Verification Modules/Libraries

[Dong, Guo]

Hi Mike,

The changes to SecurityPkg look good to me.

Reviewed-by: Dong, Guo guo.d...@intel.com

Thanks,
Guo

From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Thursday, August 14, 2014 9:19 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature 
Verification Modules/Libraries

Feng,

I will update VALID_ARCHITECTURES.

Thanks,

Mike

From: Tian, Feng [mailto:feng.t...@intel.com]
Sent: Wednesday, August 13, 2014 6:02 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature 
Verification Modules/Libraries

My fault on comment 1:)

I forget FreePages in PeiMemoryAllocationLib is NOP as PEI phase doesn't 
support it.

Thanks
Feng

From: Tian, Feng
Sent: Thursday, August 14, 2014 08:47
To: edk2-devel@lists.sourceforge.net
Cc: Tian, Feng
Subject: RE: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature 
Verification Modules/Libraries

Hi, Mike

For MdeModulePkg part, I have two minor comments:

1)  CustomGuidedSectionExtract() in SectionExtractionPei.c: when 
OutputBuffer fails to allocate memory, looks like we should free ScratchBuffer 
as well. I see the DXE version has done such error handling but PEI don't:)

2)  For SectionExtractionPei.inf and SectionExtractionDxe.inf, shall we 
support IPF and EBC?

Others are good to me.

Reviewed-by: Feng Tian mailto:feng.t...@intel.com>>

Thanks
Feng


From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Tuesday, August 12, 2014 11:39
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature 
Verification Modules/Libraries

Hello,

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney  
mailto:michael.d.kin...@intel.com>>

I have attached a set of patches for review that provide support for RSA 2048 
SHA 256 signing and verification encoded in a PI FFS GUIDED Encapsulation 
Section.  The primary use case of this feature is in support of signing and 
verification of encapsulated FVs for Recovery and Capsule Update, but can 
potentially be used for signing and verification of any content that can be 
stored in a PI conformant FFS file.  Signing operations are performed from 
python scripts that wrap OpenSsl command line utilities.  Verification 
operations are performed using the OpenSsl libraries in the CryptoPkg.

The guided encapsulation sections uses the UEFI 2.4 Specification defined GUID 
called EFI_CERT_TYPE_RSA2048_SHA256_GUID.  The data layout for the 
encapsulation section starts with the UEFI 2.4 Specification defined structure 
called EFI_CERT_BLOCK_RSA_2048_SHA256 followed immediately by the data.  The 
signing tool included in these patches performs encode/decode operations using 
this data layout.  HashType is set to the UEFI 2.4 Specification defined GUID 
called EFI_HASH_ALGORITHM_SHA256_GUID.

MdePkg/Include/Guid/WinCertificate.h
=
//
// WIN_CERTIFICATE_UEFI_GUID.CertType
//
#define EFI_CERT_TYPE_RSA2048_SHA256_GUID \
  {0xa7717414, 0xc616, 0x4977, {0x94, 0x20, 0x84, 0x47, 0x12, 0xa7, 0x35, 0xbf 
} }

///
/// WIN_CERTIFICATE_UEFI_GUID.CertData
///
typedef struct {
  EFI_GUID  HashType;
  UINT8 PublicKey[256];
  UINT8 Signature[256];
} EFI_CERT_BLOCK_RSA_2048_SHA256;

MdePkg/Include/Protocol/Hash.h
=
#define EFI_HASH_ALGORITHM_SHA256_GUID \
  { \
0x51aa59de, 0xfdf2, 0x4ea3, {0xbc, 0x63, 0x87, 0x5f, 0xb7, 0x84, 0x2e, 0xe9 
} \
  }

The verification operations require the use of public key(s).  A new PCD called 
gEfiSecurityPkgTokenSpaceGuid.PcdRsa2048Sha256PublicKeyBuffer is added to the 
SecurityPkg that supports one or more SHA 256 hashes of the public keys.  A SHA 
256 hash is performed to minimize the FLASH overhead of storing the public 
keys.  When a verification operation is performed, a SHA 256 hash is performed 
on EFI_CERT_BLOCK_RSA_2048_SHA256.PublicKey and a check is made to see if that 
hash matches any of the hashes in the new PCD.  It is recommended that this PCD 
always be configured in the DSC file as storage type of [PcdsDynamixExVpd], so 
the public keys are stored in a protected read-only region.

While working on this feature, I noticed that the CRC32 signing and 
verification feature was incomplete.  It only supported CRC32 based 
verification in the DXE Phase, so the attached patches also provide support for 
CRC32 based verification in the PEI Phase.

I also noticed that the most common method for incorporating guided section 
extraction libraries was to directly link them to the DXE Core, which is not 
very flexible.  The attached patches also add a generic section extraction PEIM 
and a generic section extraction DXE driver that can each be linked against one 
or more sec

Re: [edk2] ShellPkg add size cast to bit operations

[Dong, Eric]

Reviewed-by: Eric Dong 

Thanks,
Eric

-Original Message-
From: Carsey, Jaben 
Sent: Tuesday, August 12, 2014 5:09 AM
To: edk2-devel@lists.sourceforge.net; Dong, Eric
Cc: Carsey, Jaben
Subject: RE: [edk2] ShellPkg add size cast to bit operations

Revised.  Thanks!  I didn't even notice the spelling error; I only noticed it 
was spaced in wrong. 

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, August 11, 2014 1:22 PM
> To: edk2-devel@lists.sourceforge.net; Dong, Eric
> Subject: Re: [edk2] ShellPkg add size cast to bit operations
> 
> On 08/11/14 22:00, Carsey, Jaben wrote:
> 
> > Index: Library/UefiShellDebug1CommandsLib/Pci.c
> >
> ==
> =
> > --- Library/UefiShellDebug1CommandsLib/Pci.c(revision 15753)
> > +++ Library/UefiShellDebug1CommandsLib/Pci.c(working copy)
> > @@ -1378,7 +1378,7 @@
> >Print strings that represent PCI device class, subclass and 
> > programmed
> I/F.
> >
> >@param[in] ClassCodePtr   Points to the memory which stores register
> Class Code in PCI
> > - configuation space.
> > +configuation space.
> 
> since the line is touched to fix the indentation, the typo in 
> "configu[r]ation"
> might as well be fixed
> 
> >@param[in] IncludePIF If the printed string should include the
> programming I/F part
> >  **/
> >  VOID
> > @@ -1391,9 +1391,9 @@
> >PCI_CLASS_STRINGS ClassStrings;
> >
> >ClassCode = 0;
> > -  ClassCode |= ClassCodePtr[0];
> > -  ClassCode |= (ClassCodePtr[1] << 8);
> > -  ClassCode |= (ClassCodePtr[2] << 16);
> > +  ClassCode |= (UINT23)ClassCodePtr[0];  ClassCode |= 
> > + (UINT23)(ClassCodePtr[1] << 8);  ClassCode |= 
> > + (UINT23)(ClassCodePtr[2] << 16);
> >
> >//
> >// Get name from class code
> 
> Probable typos, UINT23 <-> UINT32.
> 
> BTW I have no clue why the casts are necessary. (I guess MSVC was 
> yelling, for no good reason.)
> 
> Laszlo
> 
> 
> --
>  ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature Verification Modules/Libraries

[Kinney, Michael D]

Feng,

I will update VALID_ARCHITECTURES.

Thanks,

Mike

From: Tian, Feng [mailto:feng.t...@intel.com]
Sent: Wednesday, August 13, 2014 6:02 PM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature 
Verification Modules/Libraries

My fault on comment 1:)

I forget FreePages in PeiMemoryAllocationLib is NOP as PEI phase doesn't 
support it.

Thanks
Feng

From: Tian, Feng
Sent: Thursday, August 14, 2014 08:47
To: edk2-devel@lists.sourceforge.net
Cc: Tian, Feng
Subject: RE: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature 
Verification Modules/Libraries

Hi, Mike

For MdeModulePkg part, I have two minor comments:

1)  CustomGuidedSectionExtract() in SectionExtractionPei.c: when 
OutputBuffer fails to allocate memory, looks like we should free ScratchBuffer 
as well. I see the DXE version has done such error handling but PEI don't:)

2)  For SectionExtractionPei.inf and SectionExtractionDxe.inf, shall we 
support IPF and EBC?

Others are good to me.

Reviewed-by: Feng Tian mailto:feng.t...@intel.com>>

Thanks
Feng


From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Tuesday, August 12, 2014 11:39
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature 
Verification Modules/Libraries

Hello,

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney  
mailto:michael.d.kin...@intel.com>>

I have attached a set of patches for review that provide support for RSA 2048 
SHA 256 signing and verification encoded in a PI FFS GUIDED Encapsulation 
Section.  The primary use case of this feature is in support of signing and 
verification of encapsulated FVs for Recovery and Capsule Update, but can 
potentially be used for signing and verification of any content that can be 
stored in a PI conformant FFS file.  Signing operations are performed from 
python scripts that wrap OpenSsl command line utilities.  Verification 
operations are performed using the OpenSsl libraries in the CryptoPkg.

The guided encapsulation sections uses the UEFI 2.4 Specification defined GUID 
called EFI_CERT_TYPE_RSA2048_SHA256_GUID.  The data layout for the 
encapsulation section starts with the UEFI 2.4 Specification defined structure 
called EFI_CERT_BLOCK_RSA_2048_SHA256 followed immediately by the data.  The 
signing tool included in these patches performs encode/decode operations using 
this data layout.  HashType is set to the UEFI 2.4 Specification defined GUID 
called EFI_HASH_ALGORITHM_SHA256_GUID.

MdePkg/Include/Guid/WinCertificate.h
=
//
// WIN_CERTIFICATE_UEFI_GUID.CertType
//
#define EFI_CERT_TYPE_RSA2048_SHA256_GUID \
  {0xa7717414, 0xc616, 0x4977, {0x94, 0x20, 0x84, 0x47, 0x12, 0xa7, 0x35, 0xbf 
} }

///
/// WIN_CERTIFICATE_UEFI_GUID.CertData
///
typedef struct {
  EFI_GUID  HashType;
  UINT8 PublicKey[256];
  UINT8 Signature[256];
} EFI_CERT_BLOCK_RSA_2048_SHA256;

MdePkg/Include/Protocol/Hash.h
=
#define EFI_HASH_ALGORITHM_SHA256_GUID \
  { \
0x51aa59de, 0xfdf2, 0x4ea3, {0xbc, 0x63, 0x87, 0x5f, 0xb7, 0x84, 0x2e, 0xe9 
} \
  }

The verification operations require the use of public key(s).  A new PCD called 
gEfiSecurityPkgTokenSpaceGuid.PcdRsa2048Sha256PublicKeyBuffer is added to the 
SecurityPkg that supports one or more SHA 256 hashes of the public keys.  A SHA 
256 hash is performed to minimize the FLASH overhead of storing the public 
keys.  When a verification operation is performed, a SHA 256 hash is performed 
on EFI_CERT_BLOCK_RSA_2048_SHA256.PublicKey and a check is made to see if that 
hash matches any of the hashes in the new PCD.  It is recommended that this PCD 
always be configured in the DSC file as storage type of [PcdsDynamixExVpd], so 
the public keys are stored in a protected read-only region.

While working on this feature, I noticed that the CRC32 signing and 
verification feature was incomplete.  It only supported CRC32 based 
verification in the DXE Phase, so the attached patches also provide support for 
CRC32 based verification in the PEI Phase.

I also noticed that the most common method for incorporating guided section 
extraction libraries was to directly link them to the DXE Core, which is not 
very flexible.  The attached patches also add a generic section extraction PEIM 
and a generic section extraction DXE driver that can each be linked against one 
or more section extraction libraries.  This provides a platform developer with 
the option of providing section extraction services with the DXE Core or 
providing section extraction services with these generic PEIM/DXE Drivers.

Patch Summary
==

1)  BaseTools - Rsa2049Sha256Sign python script that can perform test 
signing or custom signing of PI FFS file GUIDed sections

a.   Wrapper for a set of OpenSsl com

Re: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature Verification Modules/Libraries

[Tian, Feng]

My fault on comment 1:)

I forget FreePages in PeiMemoryAllocationLib is NOP as PEI phase doesn't 
support it.

Thanks
Feng

From: Tian, Feng
Sent: Thursday, August 14, 2014 08:47
To: edk2-devel@lists.sourceforge.net
Cc: Tian, Feng
Subject: RE: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature 
Verification Modules/Libraries

Hi, Mike

For MdeModulePkg part, I have two minor comments:

1)  CustomGuidedSectionExtract() in SectionExtractionPei.c: when 
OutputBuffer fails to allocate memory, looks like we should free ScratchBuffer 
as well. I see the DXE version has done such error handling but PEI don't:)

2)  For SectionExtractionPei.inf and SectionExtractionDxe.inf, shall we 
support IPF and EBC?

Others are good to me.

Reviewed-by: Feng Tian mailto:feng.t...@intel.com>>

Thanks
Feng


From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Tuesday, August 12, 2014 11:39
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature 
Verification Modules/Libraries

Hello,

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney  
mailto:michael.d.kin...@intel.com>>

I have attached a set of patches for review that provide support for RSA 2048 
SHA 256 signing and verification encoded in a PI FFS GUIDED Encapsulation 
Section.  The primary use case of this feature is in support of signing and 
verification of encapsulated FVs for Recovery and Capsule Update, but can 
potentially be used for signing and verification of any content that can be 
stored in a PI conformant FFS file.  Signing operations are performed from 
python scripts that wrap OpenSsl command line utilities.  Verification 
operations are performed using the OpenSsl libraries in the CryptoPkg.

The guided encapsulation sections uses the UEFI 2.4 Specification defined GUID 
called EFI_CERT_TYPE_RSA2048_SHA256_GUID.  The data layout for the 
encapsulation section starts with the UEFI 2.4 Specification defined structure 
called EFI_CERT_BLOCK_RSA_2048_SHA256 followed immediately by the data.  The 
signing tool included in these patches performs encode/decode operations using 
this data layout.  HashType is set to the UEFI 2.4 Specification defined GUID 
called EFI_HASH_ALGORITHM_SHA256_GUID.

MdePkg/Include/Guid/WinCertificate.h
=
//
// WIN_CERTIFICATE_UEFI_GUID.CertType
//
#define EFI_CERT_TYPE_RSA2048_SHA256_GUID \
  {0xa7717414, 0xc616, 0x4977, {0x94, 0x20, 0x84, 0x47, 0x12, 0xa7, 0x35, 0xbf 
} }

///
/// WIN_CERTIFICATE_UEFI_GUID.CertData
///
typedef struct {
  EFI_GUID  HashType;
  UINT8 PublicKey[256];
  UINT8 Signature[256];
} EFI_CERT_BLOCK_RSA_2048_SHA256;

MdePkg/Include/Protocol/Hash.h
=
#define EFI_HASH_ALGORITHM_SHA256_GUID \
  { \
0x51aa59de, 0xfdf2, 0x4ea3, {0xbc, 0x63, 0x87, 0x5f, 0xb7, 0x84, 0x2e, 0xe9 
} \
  }

The verification operations require the use of public key(s).  A new PCD called 
gEfiSecurityPkgTokenSpaceGuid.PcdRsa2048Sha256PublicKeyBuffer is added to the 
SecurityPkg that supports one or more SHA 256 hashes of the public keys.  A SHA 
256 hash is performed to minimize the FLASH overhead of storing the public 
keys.  When a verification operation is performed, a SHA 256 hash is performed 
on EFI_CERT_BLOCK_RSA_2048_SHA256.PublicKey and a check is made to see if that 
hash matches any of the hashes in the new PCD.  It is recommended that this PCD 
always be configured in the DSC file as storage type of [PcdsDynamixExVpd], so 
the public keys are stored in a protected read-only region.

While working on this feature, I noticed that the CRC32 signing and 
verification feature was incomplete.  It only supported CRC32 based 
verification in the DXE Phase, so the attached patches also provide support for 
CRC32 based verification in the PEI Phase.

I also noticed that the most common method for incorporating guided section 
extraction libraries was to directly link them to the DXE Core, which is not 
very flexible.  The attached patches also add a generic section extraction PEIM 
and a generic section extraction DXE driver that can each be linked against one 
or more section extraction libraries.  This provides a platform developer with 
the option of providing section extraction services with the DXE Core or 
providing section extraction services with these generic PEIM/DXE Drivers.

Patch Summary
==

1)  BaseTools - Rsa2049Sha256Sign python script that can perform test 
signing or custom signing of PI FFS file GUIDed sections

a.   Wrapper for a set of OpenSsl command line utility operations

b.  OpenSsl command line tool must be installed in location that is in 
standard OS path or in path specified by OS environment variable called 
OPENSSL_PATH

c.   Provides standard EDK II command line arguments for a tool that 
encodes/decodes guided encapsulation section

Rsa2048Sha256Sig

Re: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature Verification Modules/Libraries

[Gao, Liming]

Feng:

1)   PEI has no FreePage or FreePool service. So, PEI implementation is not 
required to free the allocated memory resource.

From: Tian, Feng [mailto:feng.t...@intel.com]
Sent: Thursday, August 14, 2014 8:47 AM
To: edk2-devel@lists.sourceforge.net
Subject: Re: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature 
Verification Modules/Libraries

Hi, Mike

For MdeModulePkg part, I have two minor comments:

1)  CustomGuidedSectionExtract() in SectionExtractionPei.c: when 
OutputBuffer fails to allocate memory, looks like we should free ScratchBuffer 
as well. I see the DXE version has done such error handling but PEI don't:)

2)  For SectionExtractionPei.inf and SectionExtractionDxe.inf, shall we 
support IPF and EBC?

Others are good to me.

Reviewed-by: Feng Tian mailto:feng.t...@intel.com>>

Thanks
Feng


From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Tuesday, August 12, 2014 11:39
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature 
Verification Modules/Libraries

Hello,

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney  
mailto:michael.d.kin...@intel.com>>

I have attached a set of patches for review that provide support for RSA 2048 
SHA 256 signing and verification encoded in a PI FFS GUIDED Encapsulation 
Section.  The primary use case of this feature is in support of signing and 
verification of encapsulated FVs for Recovery and Capsule Update, but can 
potentially be used for signing and verification of any content that can be 
stored in a PI conformant FFS file.  Signing operations are performed from 
python scripts that wrap OpenSsl command line utilities.  Verification 
operations are performed using the OpenSsl libraries in the CryptoPkg.

The guided encapsulation sections uses the UEFI 2.4 Specification defined GUID 
called EFI_CERT_TYPE_RSA2048_SHA256_GUID.  The data layout for the 
encapsulation section starts with the UEFI 2.4 Specification defined structure 
called EFI_CERT_BLOCK_RSA_2048_SHA256 followed immediately by the data.  The 
signing tool included in these patches performs encode/decode operations using 
this data layout.  HashType is set to the UEFI 2.4 Specification defined GUID 
called EFI_HASH_ALGORITHM_SHA256_GUID.

MdePkg/Include/Guid/WinCertificate.h
=
//
// WIN_CERTIFICATE_UEFI_GUID.CertType
//
#define EFI_CERT_TYPE_RSA2048_SHA256_GUID \
  {0xa7717414, 0xc616, 0x4977, {0x94, 0x20, 0x84, 0x47, 0x12, 0xa7, 0x35, 0xbf 
} }

///
/// WIN_CERTIFICATE_UEFI_GUID.CertData
///
typedef struct {
  EFI_GUID  HashType;
  UINT8 PublicKey[256];
  UINT8 Signature[256];
} EFI_CERT_BLOCK_RSA_2048_SHA256;

MdePkg/Include/Protocol/Hash.h
=
#define EFI_HASH_ALGORITHM_SHA256_GUID \
  { \
0x51aa59de, 0xfdf2, 0x4ea3, {0xbc, 0x63, 0x87, 0x5f, 0xb7, 0x84, 0x2e, 0xe9 
} \
  }

The verification operations require the use of public key(s).  A new PCD called 
gEfiSecurityPkgTokenSpaceGuid.PcdRsa2048Sha256PublicKeyBuffer is added to the 
SecurityPkg that supports one or more SHA 256 hashes of the public keys.  A SHA 
256 hash is performed to minimize the FLASH overhead of storing the public 
keys.  When a verification operation is performed, a SHA 256 hash is performed 
on EFI_CERT_BLOCK_RSA_2048_SHA256.PublicKey and a check is made to see if that 
hash matches any of the hashes in the new PCD.  It is recommended that this PCD 
always be configured in the DSC file as storage type of [PcdsDynamixExVpd], so 
the public keys are stored in a protected read-only region.

While working on this feature, I noticed that the CRC32 signing and 
verification feature was incomplete.  It only supported CRC32 based 
verification in the DXE Phase, so the attached patches also provide support for 
CRC32 based verification in the PEI Phase.

I also noticed that the most common method for incorporating guided section 
extraction libraries was to directly link them to the DXE Core, which is not 
very flexible.  The attached patches also add a generic section extraction PEIM 
and a generic section extraction DXE driver that can each be linked against one 
or more section extraction libraries.  This provides a platform developer with 
the option of providing section extraction services with the DXE Core or 
providing section extraction services with these generic PEIM/DXE Drivers.

Patch Summary
==

1)  BaseTools - Rsa2049Sha256Sign python script that can perform test 
signing or custom signing of PI FFS file GUIDed sections

a.   Wrapper for a set of OpenSsl command line utility operations

b.  OpenSsl command line tool must be installed in location that is in 
standard OS path or in path specified by OS environment variable called 
OPENSSL_PATH

c.   Provides standard EDK II command line arguments for a tool that 
encodes/decodes guided encapsulati

Re: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature Verification Modules/Libraries

[Tian, Feng]

Hi, Mike

For MdeModulePkg part, I have two minor comments:

1)  CustomGuidedSectionExtract() in SectionExtractionPei.c: when 
OutputBuffer fails to allocate memory, looks like we should free ScratchBuffer 
as well. I see the DXE version has done such error handling but PEI don't:)

2)  For SectionExtractionPei.inf and SectionExtractionDxe.inf, shall we 
support IPF and EBC?

Others are good to me.

Reviewed-by: Feng Tian 

Thanks
Feng


From: Kinney, Michael D [mailto:michael.d.kin...@intel.com]
Sent: Tuesday, August 12, 2014 11:39
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] [Patch] RSA 2048 SHA 256 Signing Tools and Signature 
Verification Modules/Libraries

Hello,

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney  
mailto:michael.d.kin...@intel.com>>

I have attached a set of patches for review that provide support for RSA 2048 
SHA 256 signing and verification encoded in a PI FFS GUIDED Encapsulation 
Section.  The primary use case of this feature is in support of signing and 
verification of encapsulated FVs for Recovery and Capsule Update, but can 
potentially be used for signing and verification of any content that can be 
stored in a PI conformant FFS file.  Signing operations are performed from 
python scripts that wrap OpenSsl command line utilities.  Verification 
operations are performed using the OpenSsl libraries in the CryptoPkg.

The guided encapsulation sections uses the UEFI 2.4 Specification defined GUID 
called EFI_CERT_TYPE_RSA2048_SHA256_GUID.  The data layout for the 
encapsulation section starts with the UEFI 2.4 Specification defined structure 
called EFI_CERT_BLOCK_RSA_2048_SHA256 followed immediately by the data.  The 
signing tool included in these patches performs encode/decode operations using 
this data layout.  HashType is set to the UEFI 2.4 Specification defined GUID 
called EFI_HASH_ALGORITHM_SHA256_GUID.

MdePkg/Include/Guid/WinCertificate.h
=
//
// WIN_CERTIFICATE_UEFI_GUID.CertType
//
#define EFI_CERT_TYPE_RSA2048_SHA256_GUID \
  {0xa7717414, 0xc616, 0x4977, {0x94, 0x20, 0x84, 0x47, 0x12, 0xa7, 0x35, 0xbf 
} }

///
/// WIN_CERTIFICATE_UEFI_GUID.CertData
///
typedef struct {
  EFI_GUID  HashType;
  UINT8 PublicKey[256];
  UINT8 Signature[256];
} EFI_CERT_BLOCK_RSA_2048_SHA256;

MdePkg/Include/Protocol/Hash.h
=
#define EFI_HASH_ALGORITHM_SHA256_GUID \
  { \
0x51aa59de, 0xfdf2, 0x4ea3, {0xbc, 0x63, 0x87, 0x5f, 0xb7, 0x84, 0x2e, 0xe9 
} \
  }

The verification operations require the use of public key(s).  A new PCD called 
gEfiSecurityPkgTokenSpaceGuid.PcdRsa2048Sha256PublicKeyBuffer is added to the 
SecurityPkg that supports one or more SHA 256 hashes of the public keys.  A SHA 
256 hash is performed to minimize the FLASH overhead of storing the public 
keys.  When a verification operation is performed, a SHA 256 hash is performed 
on EFI_CERT_BLOCK_RSA_2048_SHA256.PublicKey and a check is made to see if that 
hash matches any of the hashes in the new PCD.  It is recommended that this PCD 
always be configured in the DSC file as storage type of [PcdsDynamixExVpd], so 
the public keys are stored in a protected read-only region.

While working on this feature, I noticed that the CRC32 signing and 
verification feature was incomplete.  It only supported CRC32 based 
verification in the DXE Phase, so the attached patches also provide support for 
CRC32 based verification in the PEI Phase.

I also noticed that the most common method for incorporating guided section 
extraction libraries was to directly link them to the DXE Core, which is not 
very flexible.  The attached patches also add a generic section extraction PEIM 
and a generic section extraction DXE driver that can each be linked against one 
or more section extraction libraries.  This provides a platform developer with 
the option of providing section extraction services with the DXE Core or 
providing section extraction services with these generic PEIM/DXE Drivers.

Patch Summary
==

1)  BaseTools - Rsa2049Sha256Sign python script that can perform test 
signing or custom signing of PI FFS file GUIDed sections

a.   Wrapper for a set of OpenSsl command line utility operations

b.  OpenSsl command line tool must be installed in location that is in 
standard OS path or in path specified by OS environment variable called 
OPENSSL_PATH

c.   Provides standard EDK II command line arguments for a tool that 
encodes/decodes guided encapsulation section

Rsa2048Sha256Sign - Copyright (c) 2013 - 2014, Intel Corporation. All rights 
reserved.
usage: Rsa2048Sha256Sign -e|-d [options] 

positional arguments:
  input_filespecify the input filename

optional arguments:
  -eencode file
  -ddecode file
  -o filename, --output filename
specify the output filename
  --private-key PRIVATEKEYFILE
  

Re: [edk2] Shell compatibility with non-FAT filesystems

[Felipe Mesquita]

Thank you all for your answers.
So in the end I was right to expect that the shell only relied on the
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL interface - I needed to be sure about it
before spending any further efforts trying to debug an implementation issue
=)

Thank you again for your help.


> From: Thomas Rognon 
> Date: Wed, Aug 13, 2014 at 4:30 PM
> Subject: Re: [edk2] Shell compatibility with non-FAT filesystems
> To: edk2-devel 
>
>
> Just to give you even more assurance that it's possible, I made a
> EFI_SIMPLE_FILE_SYSTEM_PROTOCOL/EFI_FILE_PROTOCOL wrapper for NTFS-3G that
> works great in every shell I've tested it on. Directory navigation was
> tricky to get working correctly. I ended up caching the directory list in
> EFI_FILE_PROTOCOL.Open() and just moving through the cached data structure
> in EFI_FILE_PROTOCOL.Read(). If the problem is an infinite loop, maybe look
> and see if you're implementing EFI_FILE_PROTOCOL.Set/GetPosition()
> correctly. Set/GetPosition() works differently for directories than it does
> for files.
>
> Thomas Rognon
>
>
> On Wed, Aug 13, 2014 at 2:11 PM, Andrew Fish  wrote:
>
>>
>> On Aug 13, 2014, at 10:34 AM, Felipe Mesquita <
>> felipe.mesqu...@lsbd.ufc.br> wrote:
>>
>> Hello,
>>
>> I'm implementing an UEFI driver that, in its Start() function, installs
>> an EFI_FILE_SYSTEM_PROTOCOL instance in the controller handle passed as
>> argument.
>> My expectation was that, once I had a consistent implementation for this
>> protocol(and the underlying EFI_FILE_PROTOCOL returned by it), I'd be able
>> to navigate through this filesystem using the shell as already happens with
>> FAT volumes.
>> After loading the driver and executing "map -r", a new volume/alias
>> appears(as *fsnt0:*, since the driver doesn't install an
>> EFI_BLOCK_IO_PROTOCOL), but I can't perform any filesystem operations on it
>> through the shell(trying to "ls" in it, for example, makes it loop
>> infinitely through several calls to Open, Close and GetInfo). When I
>> investigated what might have gone wrong, I noticed some hints(in the specs
>> and the source code itself) that seem to indicate that the shell assumes a
>> FAT filesystem or, at least, the existence of an EFI_BLOCK_IO_PROTOCOL
>> under the same handle.
>>
>> So here is my question: in order to navigate through a volume using the
>> shell, is it enough to provide a new EFI_FILE_SYSTEM_PROTOCOL instance? If
>> not, what other assumptions are made by the shell? Are there any
>> differences in the assumptions made by the shell versions?
>> The shell version I'm using is 2.31.
>>
>>
>> The emulators produce EFI_FILE_SYSTEM_PROTOCOL instance on top of Win
>> APIs/POSIX APIs, and they don’t produce EFI_BLOCK_IO_PROTOCOL.
>>
>> https://svn.code.sf.net/p/edk2/code/trunk/edk2/Nt32Pkg/WinNtSimpleFileSystemDxe/
>>
>>
>> https://svn.code.sf.net/p/edk2/code/trunk/edk2/EmulatorPkg/EmuSimpleFileSystemDxe/
>>
>> https://svn.code.sf.net/p/edk2/code/trunk/edk2/EmulatorPkg/Unix/Host/PosixFileSystem.c
>>
>> It may be easier to figure out the behavior from looking at the POSIX
>> example. I’m guessing your code is doing something that is confusing the
>> upper level code.
>>
>> If the shell is depending on EFI_BLOCK_IO_PROTOCOL then that would seem
>> like a bug. The shell naming a volume fsntX based on no BlockIO protocol is
>> probably a bad implementation choice in the shell but it should not impact
>> functionality.
>>
>> It looks like the edk2 shell does not make a lot of use of the data
>> returned by the EFI_BLOCK_IO_PROTOCOL:
>> ~/work/src/edk2/ShellPkg(master)>git grep EFI_BLOCK_IO_PROTOCOL
>> Library/UefiShellDebug1CommandsLib/Dblk.c:35:  *EFI_BLOCK_IO_PROTOCOL*
>>   *BlockIo;
>> Library/UefiShellDebug1CommandsLib/HexEdit/DiskImage.c:176:
>> *EFI_BLOCK_IO_PROTOCOL*   *BlkIo;
>> Library/UefiShellDebug1CommandsLib/HexEdit/DiskImage.c:346:
>> *EFI_BLOCK_IO_PROTOCOL*   *BlkIo;
>>
>> EFI_FILE_SYSTEM_PROTOCOL is NOT FAT centric in any way. EFI_FILE_INFO,
>> EFI_FILE_SYSTEM_INFO, and EFI_FILE_SYSTEM_VOLUME_LABEL should abstract the
>> caller from any FAT data structures. Also GetInfo() InformationType is a
>> EFI_GUID so you can define a GUID and associate it with a data structure to
>> give access to extra information about your file system if needed.
>>
>> If I had to guess you probably have in an issue in the way you are
>> returning directories and that is just confusing everything.
>>
>> Thanks,
>>
>> Andrew Fish
>>
>>
>> Thanks in advance,
>>
>> --
>> [image: LSBD] 
>> *Felipe Martins Mesquita*
>>
>> Technical Lead
>>
>> BSc in Computer Science - UFC
>>
>> GTalk: felipe.mesqu...@lsbd.ufc.br
>>
>> Skype: felipe.martins23
>>
>> --
>>
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>>
>>
>>
>>
>> --

Re: [edk2] Shell compatibility with non-FAT filesystems

[Thomas Rognon]

Just to give you even more assurance that it's possible, I made a
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL/EFI_FILE_PROTOCOL wrapper for NTFS-3G that
works great in every shell I've tested it on. Directory navigation was
tricky to get working correctly. I ended up caching the directory list in
EFI_FILE_PROTOCOL.Open() and just moving through the cached data structure
in EFI_FILE_PROTOCOL.Read(). If the problem is an infinite loop, maybe look
and see if you're implementing EFI_FILE_PROTOCOL.Set/GetPosition()
correctly. Set/GetPosition() works differently for directories than it does
for files.

Thomas Rognon


On Wed, Aug 13, 2014 at 2:11 PM, Andrew Fish  wrote:

>
> On Aug 13, 2014, at 10:34 AM, Felipe Mesquita 
> wrote:
>
> Hello,
>
> I'm implementing an UEFI driver that, in its Start() function, installs an
> EFI_FILE_SYSTEM_PROTOCOL instance in the controller handle passed as
> argument.
> My expectation was that, once I had a consistent implementation for this
> protocol(and the underlying EFI_FILE_PROTOCOL returned by it), I'd be able
> to navigate through this filesystem using the shell as already happens with
> FAT volumes.
> After loading the driver and executing "map -r", a new volume/alias
> appears(as *fsnt0:*, since the driver doesn't install an
> EFI_BLOCK_IO_PROTOCOL), but I can't perform any filesystem operations on it
> through the shell(trying to "ls" in it, for example, makes it loop
> infinitely through several calls to Open, Close and GetInfo). When I
> investigated what might have gone wrong, I noticed some hints(in the specs
> and the source code itself) that seem to indicate that the shell assumes a
> FAT filesystem or, at least, the existence of an EFI_BLOCK_IO_PROTOCOL
> under the same handle.
>
> So here is my question: in order to navigate through a volume using the
> shell, is it enough to provide a new EFI_FILE_SYSTEM_PROTOCOL instance? If
> not, what other assumptions are made by the shell? Are there any
> differences in the assumptions made by the shell versions?
> The shell version I'm using is 2.31.
>
>
> The emulators produce EFI_FILE_SYSTEM_PROTOCOL instance on top of Win
> APIs/POSIX APIs, and they don’t produce EFI_BLOCK_IO_PROTOCOL.
>
> https://svn.code.sf.net/p/edk2/code/trunk/edk2/Nt32Pkg/WinNtSimpleFileSystemDxe/
>
>
> https://svn.code.sf.net/p/edk2/code/trunk/edk2/EmulatorPkg/EmuSimpleFileSystemDxe/
>
> https://svn.code.sf.net/p/edk2/code/trunk/edk2/EmulatorPkg/Unix/Host/PosixFileSystem.c
>
> It may be easier to figure out the behavior from looking at the POSIX
> example. I’m guessing your code is doing something that is confusing the
> upper level code.
>
> If the shell is depending on EFI_BLOCK_IO_PROTOCOL then that would seem
> like a bug. The shell naming a volume fsntX based on no BlockIO protocol is
> probably a bad implementation choice in the shell but it should not impact
> functionality.
>
> It looks like the edk2 shell does not make a lot of use of the data
> returned by the EFI_BLOCK_IO_PROTOCOL:
> ~/work/src/edk2/ShellPkg(master)>git grep EFI_BLOCK_IO_PROTOCOL
> Library/UefiShellDebug1CommandsLib/Dblk.c:35:  *EFI_BLOCK_IO_PROTOCOL*
>   *BlockIo;
> Library/UefiShellDebug1CommandsLib/HexEdit/DiskImage.c:176:
> *EFI_BLOCK_IO_PROTOCOL*   *BlkIo;
> Library/UefiShellDebug1CommandsLib/HexEdit/DiskImage.c:346:
> *EFI_BLOCK_IO_PROTOCOL*   *BlkIo;
>
> EFI_FILE_SYSTEM_PROTOCOL is NOT FAT centric in any way. EFI_FILE_INFO,
> EFI_FILE_SYSTEM_INFO, and EFI_FILE_SYSTEM_VOLUME_LABEL should abstract the
> caller from any FAT data structures. Also GetInfo() InformationType is a
> EFI_GUID so you can define a GUID and associate it with a data structure to
> give access to extra information about your file system if needed.
>
> If I had to guess you probably have in an issue in the way you are
> returning directories and that is just confusing everything.
>
> Thanks,
>
> Andrew Fish
>
>
> Thanks in advance,
>
> --
> [image: LSBD] 
> *Felipe Martins Mesquita*
>
> Technical Lead
>
> BSc in Computer Science - UFC
>
> GTalk: felipe.mesqu...@lsbd.ufc.br
>
> Skype: felipe.martins23
>
> --
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
>
>
> --
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] Shell compatibility with non-FAT filesystems

[Andrew Fish]

On Aug 13, 2014, at 10:34 AM, Felipe Mesquita  
wrote:

> Hello,
> 
> I'm implementing an UEFI driver that, in its Start() function, installs an 
> EFI_FILE_SYSTEM_PROTOCOL instance in the controller handle passed as argument.
> My expectation was that, once I had a consistent implementation for this 
> protocol(and the underlying EFI_FILE_PROTOCOL returned by it), I'd be able to 
> navigate through this filesystem using the shell as already happens with FAT 
> volumes. 
> After loading the driver and executing "map -r", a new volume/alias 
> appears(as fsnt0:, since the driver doesn't install an 
> EFI_BLOCK_IO_PROTOCOL), but I can't perform any filesystem operations on it 
> through the shell(trying to "ls" in it, for example, makes it loop infinitely 
> through several calls to Open, Close and GetInfo). When I investigated what 
> might have gone wrong, I noticed some hints(in the specs and the source code 
> itself) that seem to indicate that the shell assumes a FAT filesystem or, at 
> least, the existence of an EFI_BLOCK_IO_PROTOCOL under the same handle.
> 
> So here is my question: in order to navigate through a volume using the 
> shell, is it enough to provide a new EFI_FILE_SYSTEM_PROTOCOL instance? If 
> not, what other assumptions are made by the shell? Are there any differences 
> in the assumptions made by the shell versions?
> The shell version I'm using is 2.31.
> 

The emulators produce EFI_FILE_SYSTEM_PROTOCOL instance on top of Win 
APIs/POSIX APIs, and they don’t produce EFI_BLOCK_IO_PROTOCOL. 
https://svn.code.sf.net/p/edk2/code/trunk/edk2/Nt32Pkg/WinNtSimpleFileSystemDxe/

https://svn.code.sf.net/p/edk2/code/trunk/edk2/EmulatorPkg/EmuSimpleFileSystemDxe/
https://svn.code.sf.net/p/edk2/code/trunk/edk2/EmulatorPkg/Unix/Host/PosixFileSystem.c

It may be easier to figure out the behavior from looking at the POSIX example. 
I’m guessing your code is doing something that is confusing the upper level 
code. 

If the shell is depending on EFI_BLOCK_IO_PROTOCOL then that would seem like a 
bug. The shell naming a volume fsntX based on no BlockIO protocol is probably a 
bad implementation choice in the shell but it should not impact functionality. 

It looks like the edk2 shell does not make a lot of use of the data returned by 
the EFI_BLOCK_IO_PROTOCOL:
~/work/src/edk2/ShellPkg(master)>git grep EFI_BLOCK_IO_PROTOCOL
Library/UefiShellDebug1CommandsLib/Dblk.c:35:  EFI_BLOCK_IO_PROTOCOL 
*BlockIo;
Library/UefiShellDebug1CommandsLib/HexEdit/DiskImage.c:176:  
EFI_BLOCK_IO_PROTOCOL   *BlkIo;
Library/UefiShellDebug1CommandsLib/HexEdit/DiskImage.c:346:  
EFI_BLOCK_IO_PROTOCOL   *BlkIo;

EFI_FILE_SYSTEM_PROTOCOL is NOT FAT centric in any way. EFI_FILE_INFO, 
EFI_FILE_SYSTEM_INFO, and EFI_FILE_SYSTEM_VOLUME_LABEL should abstract the 
caller from any FAT data structures. Also GetInfo() InformationType is a 
EFI_GUID so you can define a GUID and associate it with a data structure to 
give access to extra information about your file system if needed. 

If I had to guess you probably have in an issue in the way you are returning 
directories and that is just confusing everything.

Thanks,

Andrew Fish


> Thanks in advance,
> 
> -- 
> 
> Felipe Martins Mesquita
> Technical Lead
> BSc in Computer Science - UFC
> GTalk: felipe.mesqu...@lsbd.ufc.br
> Skype: felipe.martins23
> --
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 2/2] MdeModulePkg: Check D2H register status in AhciPioTransfer

[Reza Jelveh]

On 13/08/14 01:04, Tian, Feng wrote:
> Hi, Reza
> 
> Thanks for your effort, Reza. I made a little coding style enhancement based 
> on your proposed patch. please help view it.
> 
> PS: I am a little curious on "some Marvel controllers use D2H only instead of 
> PIO Setup FIS". If it's that case, does it mean current logic will never 
> break out the loop? Do we need enhance code to handle this?
No it won't break out, but the will instead time out. A. Sava explained the
issue in his.

I'm attaching a patch with the things we talked about, but this results in
duplicate code. There is only a little thing i can think of to reduce the
duplicate breaks.
>From b362cd4e50d4d9dd55eb6adb8940e94430e94bc7 Mon Sep 17 00:00:00 2001
From: Reza Jelveh 
Date: Wed, 6 Aug 2014 17:47:20 +0200
Subject: [PATCH 1/3] MdeModulePkg: Check D2H register status in
 AhciPioTransfer

Some AHCI controllers such as the Marvel 9230 controllers do not send
PIO Setup FIS when the PIO data-in command is completed. Instead they
just send a D2H FIS.

To accomodate for this possibility the status code of the D2H FIS is
checked.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Reza Jelveh 
---
 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c | 14 --
 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.h |  3 +++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
index 7fc7a28..487f516 100644
--- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
+++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
@@ -703,6 +703,7 @@ AhciPioTransfer (
   EFI_AHCI_COMMAND_LIST CmdList;
   UINT32PortTfd;
   UINT32PrdCount;
+  UINT8 D2HStatus;
   BOOLEAN   InfiniteWait;
 
   if (Timeout == 0) {
@@ -804,8 +805,17 @@ AhciPioTransfer (
   Offset = FisBaseAddr + EFI_AHCI_D2H_FIS_OFFSET;
   Status = AhciCheckMemSet (Offset, EFI_AHCI_FIS_TYPE_MASK, EFI_AHCI_FIS_REGISTER_D2H, NULL);
   if (!EFI_ERROR (Status)) {
-Status = EFI_DEVICE_ERROR;
-break;
+D2HStatus = *(volatile UINT8 *) (Offset + EFI_AHCI_D2H_FIS_STATUS_OFFSET);
+
+if ((D2HStatus & EFI_AHCI_D2H_FIS_ERR) != 0) {
+  Status = EFI_DEVICE_ERROR;
+  break;
+}
+
+PrdCount = *(volatile UINT32 *) (&(AhciRegisters->AhciCmdList[0].AhciCmdPrdbc));
+if (PrdCount == DataCount) {
+  break;
+}
   }
 
   //
diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.h b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.h
index 485b647..9fe1fb3 100644
--- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.h
+++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.h
@@ -78,12 +78,15 @@ typedef union {
 #define   EFI_AHCI_FIS_SET_DEVICE_LENGTH   8
 
 #define EFI_AHCI_D2H_FIS_OFFSET0x40
+#define   EFI_AHCI_D2H_FIS_STATUS_OFFSET   0x02
+#define   EFI_AHCI_D2H_FIS_ERR BIT0
 #define EFI_AHCI_DMA_FIS_OFFSET0x00
 #define EFI_AHCI_PIO_FIS_OFFSET0x20
 #define EFI_AHCI_SDB_FIS_OFFSET0x58
 #define EFI_AHCI_FIS_TYPE_MASK 0xFF
 #define EFI_AHCI_U_FIS_OFFSET  0x60
 
+
 //
 // Port register
 //
-- 
1.9.2

--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Shell compatibility with non-FAT filesystems

[Felipe Mesquita]

Hello,

I'm implementing an UEFI driver that, in its Start() function, installs an
EFI_FILE_SYSTEM_PROTOCOL instance in the controller handle passed as
argument.
My expectation was that, once I had a consistent implementation for this
protocol(and the underlying EFI_FILE_PROTOCOL returned by it), I'd be able
to navigate through this filesystem using the shell as already happens with
FAT volumes.
After loading the driver and executing "map -r", a new volume/alias
appears(as *fsnt0:*, since the driver doesn't install an
EFI_BLOCK_IO_PROTOCOL), but I can't perform any filesystem operations on it
through the shell(trying to "ls" in it, for example, makes it loop
infinitely through several calls to Open, Close and GetInfo). When I
investigated what might have gone wrong, I noticed some hints(in the specs
and the source code itself) that seem to indicate that the shell assumes a
FAT filesystem or, at least, the existence of an EFI_BLOCK_IO_PROTOCOL
under the same handle.

So here is my question: in order to navigate through a volume using the
shell, is it enough to provide a new EFI_FILE_SYSTEM_PROTOCOL instance? If
not, what other assumptions are made by the shell? Are there any
differences in the assumptions made by the shell versions?
The shell version I'm using is 2.31.

Thanks in advance,

-- 
[image: LSBD] 
*Felipe Martins Mesquita*

Technical Lead

BSc in Computer Science - UFC

GTalk: felipe.mesqu...@lsbd.ufc.br

Skype: felipe.martins23
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] PEI_DEPEX and DXE_DEPEX in .INF files

[Tim Lewis]

In trying to build a PEI from binaries, we tried the following:

[Defines]
  INF_VERSION= 0x00010016
  BASE_NAME  = CommonPolicyPei
  FILE_GUID  = 4CD976FF-A41B-43d4-A3A7-D67872066F76
  MODULE_TYPE= PEIM
  VERSION_STRING = 1.0

[Packages]

[Binaries.IA32]
  PE32|Vlv2DeviceRefCodeBinPkg/Ia32/CommonPolicyPei.efi
  PEI_DEPEX|Vlv2DeviceRefCodeBinPkg/Ia32/CommonPolicyPei.depex

Notice that the PEI DEPEX is specified via binary, not the [Depex] section. In 
fact, if you can't do this, it seems like that supporting the PEI_DEPEX binary 
type is not useful.  Here is the section of the .INF spec that is causing 
issues:

[cid:image001.png@01CFB6E1.6DE0CE60]

I would suggest that this wording be changed to "Module types PEIM, DXE_DRIVER, 
DXE_RUNTIME_DRIVER, DXE_SAL_DRIVER and DXE_SMM_DRIVER require a [Depex] section 
unless the dependencies are specified by a PEI_DEPEX or DXE_DEPEX in the 
[Binaries] section."

Tim
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] EDK II UNI Unicode File Specification Update

[Tim Lewis]

Larry -

Yes, this looks a much better separation.  A couple of comments:


1)  I still think that the separation of two separate .uni files for one 
INF seems awkward.

2)  It uses some grammar terms, but the font isn't changed. Using the font 
would help clarify that you are referring to a grammar term.

3)  I think that reference to UPT as the consumer seems a bit exclusive. 
Rather, I'd simply say that this is a means of extending the abstract and 
description information normally found in the module header. It 
extends/replaces the information found in the Abstract, Description, Copyright 
and Licenses part of the @file header in the .INF specification (see. After 
this, you can describe how the UPT uses this information (see how 3.3 in the 
.INF spec words this).

4)  We still need the to add some Build spec descriptions of these "objects 
(Packages, Module) and "attributes" (Abstract, Description, Copyright, Licenses)

Tim

From: Hauch, Larry [mailto:larry.ha...@intel.com]
Sent: Wednesday, August 13, 2014 9:57 AM
To: Tim Lewis
Cc: edk2-devel@lists.sourceforge.net
Subject: RE: EDK II UNI Unicode File Specification Update

Hi Tim,
So if we try simplifying this with the UNI Unicode File spec, then is the 
following acceptable?
Cheers,
Larry

Update Definition of  in section 2.1 Extended Backus-Naur Form (EBNF)

::= (\ua-\uf\uA-\uF\u0-\u9)



::=   L"string" 

   (\uA-\uZ\ua\uz)(\uA-\uZ\ua\uz\u0-\u9\u_)*



   ::= (\uA-\uZ\ua\uz)(\uA-\uZ\ua\uz\u0-\u9\u_)*



::= 


Add the following chapter.
3
Meta-Data UNI Files
In order to support distributions conforming to the UEFI PI Distribution 
Package Specification, Unicode files may be used to contain localization 
content passed along in the XML file for content that cannot be passed using 
ASCII characters.
The format of the Unicode files that contain the optional Module and Package 
localization content for distribution is as follows:

 ::= *

   +



 ::= {} {} {}


Additional Definitions used for Package Meta-Data Token Identifiers

 ::= (\u0-\u9\ua-\uf\uA-\uF)



 ::=  L"_" 



   ::= (\uA-\uZ\ua-\uz)(\uA-\uZ\ua-\uz\u0-\u9)*


Refer to Chapter 2.1, Unicode Strings File Format, Extended Backus-Naur Form 
(EBNF) for the definitions of CommentLine, BlankLine and UnicodeLines.
It is also recommended that the comment section at the start of the file use 
content consistent with content described for meta-data headers, including a 
start tag line, L"// @file", and include an abstract, description, copyright 
and license information.
3.1 Module Meta-Data
If a Module's INF file contains a MODULE_UNI_FILE entry in its [Defines] 
section, then that Unicode file may contain localization of the Module's 
Abstract and Description lines.
The Intel UEFI Packaging Tool, UPT, provided as part of the EDK II BaseTools 
will use following identifiers in the UnicodeLines' Token element to pass along 
localization of the Module's Abstract and Description. This file is created 
from the UEFI PI Distribution Package XML content by the Intel UEFI Packaging 
Tool during installation, and will be read from the file into the UEFI PI 
Distribution Package XML when creating a distribution.

L"STR_MODULE_ABSTRACT"

L"STR_MODULE_DESCRIPTION"

If a Module's INF file contains a Unicode file entry in its 
[UserExtensions.TianoCore."ExtraFiles"] section, then that Unicode file may 
contain a localized version of a User Interface name for the module as well as 
other content. This file is used to hold content that is not required by UEFI 
PI Distribution Package, but may be useful for User Interface tools. The 
following identifier may be used in the UnicodeLines' Token element to pass 
along the User Interface name of the module.

L"STR_PRORPERTIES_MODULE_NAME"
Other content may be provided in this file as the file itself will be carried 
along with the Module in a UEFI PI Distribution Package.
3.1 Package Meta-Data
If a Package's DEC file contains a PACKAGE_UNI_FILE entry in its [Defines] 
section, then that Unicode file may contain localization of the Package's 
Abstract and Description line as well as information used for PCD declarations. 
This file is created from the UEFI PI Distribution Package XML content by the 
Intel UEFI Packaging Tool during installation, and will be read from the file 
into the UEFI PI Distribution Package XML when creating a distribution.
The following identifiers are used in the UnicodeLines' Token element to pass 
along localization of the Package's Abstract and Description.

L"STR_PACKAGE_ABSTRACT"

L"STR_PACKAGE_DESCRIPTION"


The following describes the format for an identifier used in the UnicodeLines' 
Token element to pass along localization of a TokenSpaceGuid's Error messages 
that are referenced by an error number. The CName is the Token Space GUID's C 
Name declared in the DEC file's [Guids] section.

L"STR_"  "_ERR_" 


The following describes the format for an identifier

Re: [edk2] EDK II UNI Unicode File Specification Update

[Hauch, Larry]

Hi Tim,
So if we try simplifying this with the UNI Unicode File spec, then is the 
following acceptable?
Cheers,
Larry

Update Definition of  in section 2.1 Extended Backus-Naur Form (EBNF)

::= (\ua-\uf\uA-\uF\u0-\u9)



::=   L"string" 

   (\uA-\uZ\ua\uz)(\uA-\uZ\ua\uz\u0-\u9\u_)*



   ::= (\uA-\uZ\ua\uz)(\uA-\uZ\ua\uz\u0-\u9\u_)*



::= 


Add the following chapter.
3
Meta-Data UNI Files
In order to support distributions conforming to the UEFI PI Distribution 
Package Specification, Unicode files may be used to contain localization 
content passed along in the XML file for content that cannot be passed using 
ASCII characters.
The format of the Unicode files that contain the optional Module and Package 
localization content for distribution is as follows:

 ::= *

   +



 ::= {} {} {}


Additional Definitions used for Package Meta-Data Token Identifiers

 ::= (\u0-\u9\ua-\uf\uA-\uF)



 ::=  L"_" 



   ::= (\uA-\uZ\ua-\uz)(\uA-\uZ\ua-\uz\u0-\u9)*


Refer to Chapter 2.1, Unicode Strings File Format, Extended Backus-Naur Form 
(EBNF) for the definitions of CommentLine, BlankLine and UnicodeLines.
It is also recommended that the comment section at the start of the file use 
content consistent with content described for meta-data headers, including a 
start tag line, L"// @file", and include an abstract, description, copyright 
and license information.
3.1 Module Meta-Data
If a Module's INF file contains a MODULE_UNI_FILE entry in its [Defines] 
section, then that Unicode file may contain localization of the Module's 
Abstract and Description lines.
The Intel UEFI Packaging Tool, UPT, provided as part of the EDK II BaseTools 
will use following identifiers in the UnicodeLines' Token element to pass along 
localization of the Module's Abstract and Description. This file is created 
from the UEFI PI Distribution Package XML content by the Intel UEFI Packaging 
Tool during installation, and will be read from the file into the UEFI PI 
Distribution Package XML when creating a distribution.

L"STR_MODULE_ABSTRACT"

L"STR_MODULE_DESCRIPTION"

If a Module's INF file contains a Unicode file entry in its 
[UserExtensions.TianoCore."ExtraFiles"] section, then that Unicode file may 
contain a localized version of a User Interface name for the module as well as 
other content. This file is used to hold content that is not required by UEFI 
PI Distribution Package, but may be useful for User Interface tools. The 
following identifier may be used in the UnicodeLines' Token element to pass 
along the User Interface name of the module.

L"STR_PRORPERTIES_MODULE_NAME"
Other content may be provided in this file as the file itself will be carried 
along with the Module in a UEFI PI Distribution Package.
3.1 Package Meta-Data
If a Package's DEC file contains a PACKAGE_UNI_FILE entry in its [Defines] 
section, then that Unicode file may contain localization of the Package's 
Abstract and Description line as well as information used for PCD declarations. 
This file is created from the UEFI PI Distribution Package XML content by the 
Intel UEFI Packaging Tool during installation, and will be read from the file 
into the UEFI PI Distribution Package XML when creating a distribution.
The following identifiers are used in the UnicodeLines' Token element to pass 
along localization of the Package's Abstract and Description.

L"STR_PACKAGE_ABSTRACT"

L"STR_PACKAGE_DESCRIPTION"


The following describes the format for an identifier used in the UnicodeLines' 
Token element to pass along localization of a TokenSpaceGuid's Error messages 
that are referenced by an error number. The CName is the Token Space GUID's C 
Name declared in the DEC file's [Guids] section.

L"STR_"  "_ERR_" 


The following describes the format for an identifier used in the UnicodeLines' 
Token element to pass along localization of a PCD's HELP and PROMPT content.

L"STR_"  "_HELP"

L"STR_"  "_PROMPT"

If a Package's DEC file contains a Unicode file entry in its 
[UserExtensions.TianoCore."ExtraFiles"] section, then that Unicode file may 
contain a localized version of a User Interface name for the package as well as 
other content. This file is used to hold content that is not required by UEFI 
PI Distribution Package, but may be useful for User Interface tools. The 
following identifier may be used in the UnicodeLines' Token element to pass 
along the User Interface name of the package.

L"STR_PRORPERTIES_MODULE_NAME"
Other content may be provided in this file as the file itself will be carried 
along with the Package in a UEFI PI Distribution Package.


From: Tim Lewis [mailto:tim.le...@insyde.com]
Sent: Tuesday, August 12, 2014 3:46 PM
To: Hauch, Larry
Cc: edk2-devel@lists.sourceforge.net
Subject: RE: EDK II UNI Unicode File Specification Update

Larry -

As a tools developer and a QA team, we (Insyde) can tell you that the existing 
EBNF is hard to manage. We have rewritten it to be readable by t

Re: [edk2] [OVFM] Example usage of the BaseSerialPortLibIoPort OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf

[Olivier Martin]

I confirm Lazlo statements. It works the same on ARM (development)
platforms. We use Console Splitter.
We use EmbeddedPkg/SerialDxe to produce gEfiSerialIoProtocolGuid.


> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: 08 August 2014 17:59
> To: edk2-devel@lists.sourceforge.net
> Subject: Re: [edk2] [OVFM] Example usage of the BaseSerialPortLibIoPort
> OvmfPkg/Library/PlatformDebugLibIoPort/PlatformDebugLibIoPort.inf
> 
> On 08/08/14 15:41, Paolo Bonzini wrote:
> > Il 08/08/2014 00:49, Laszlo Ersek ha scritto:
> >> - Will this redirection break the terminal driver, for example? OVMF
> >> does make use of the serial port even when DEBUG() goes to the QEMU
> >> debug port. For example, thanks to ConSplitterDxe, the setup screens
> >> (Boot manager, Boot maintenance manager etc) are fully usable on the
> >> virtual serial port. I don't immediately see how that stack is
> built,
> >> but it should not be disturbed. (I don't know if this patch disturbs
> it,
> >> I'm asking.)
> >>
> >> ... TerminalDxe seems to consume gEfiSerialIoProtocolGuid, which
> seems
> >> to be provided by IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe.
> Hmm... I
> >> think that one doesn't depend on SerialPortLib. Good.
> >
> > Does that mean we lack an equivalent of IsaSerialDxe for ARM?
> There's
> > nothing in ArmPlatformPkg that produces gEfiSerialIoProtocolGuid.
> 
> See "EmbeddedPkg/SerialDxe". (EmbeddedPkg provides many modules for the
> ARM DSCs.)
> 
> EmbeddedPkg/SerialDxe itself depends on and delegates to SerialPortLib
> and SerialPortExtLib (eg. it calls SerialPortWrite()). If you run
> 
> $ git grep -l -E 'LIBRARY_CLASS *= *(SerialPortLib|SerialPortExtLib)'
> 
> there's a number of hits:
> 
>   ArmPkg/Library/SemiHostingSerialPortLib
>   ArmPlatformPkg/Library/PL011SerialPortLib
>   EmbeddedPkg/Library/TemplateSerialPortExtLib
>   EmbeddedPkg/Library/TemplateSerialPortLib
>   EmulatorPkg/Library/DxeEmuSerialPortLib
>   EmulatorPkg/Library/DxeEmuStdErrSerialPortLib
>   EmulatorPkg/Library/PeiEmuSerialPortLib
>   MdeModulePkg/Library/BaseSerialPortLib16550
>   MdePkg/Library/BaseSerialPortLibNull
>   Omap35xxPkg/Library/SerialPortLib
>   PcAtChipsetPkg/Library/SerialIoLib
> 
> Some of these are obviously emulators / null implementations, but some
> look like real hardware drivers usable on ARM (PL011SerialPortLib,
> Omap35xxPkg).
> 
> Running the same grep on Linaro's uefi-next tree
> , you get more:
> 
> - Omap44xxPkg/Library/SerialPortLib
> - SamsungPlatformPkg/ExynosPkg/Exynos5250/Library/SerialPortLib
> 
> Laszlo
> 
> 
> ---
> ---
> Want fast and easy access to all the code in your enterprise? Index and
> search up to 200,000 lines of code with a free copy of Black Duck
> Code Sight - the same software that powers the world's largest code
> search on Ohloh, the Black Duck Open Hub! Try it now.
> http://p.sf.net/sfu/bds
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel





--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] Check Ata device supports CHS

[Rafael Machado]

Hi everyone

It's a simple question.
Is there a way to detect if a ata storage device still accept CHS commands ?

I'm asking this because we're having some issues with a device that seems
to interpret the ATA comands as CHS when the bios is set to EHCI mode.
The command works correctly when the bios is set to IDE mode, but fails
with EHCI mode.

Any idea about this scenario ?

Thanks and Regards.
Rafael R. Machado
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH] Actually plug in BaseTools build on AArch64

[Olivier Martin]

Reviewed-By: Olivier Martin 

> -Original Message-
> From: Leif Lindholm [mailto:leif.lindh...@linaro.org]
> Sent: 12 August 2014 16:55
> To: edk2-devel@lists.sourceforge.net
> Subject: [edk2] [PATCH] Actually plug in BaseTools build on AArch64
> 
> Support for building BaseTools on AArch64 is available in the tree, but
> not currently "plugged in". This patch adds the required snippet.
> 
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Leif Lindholm 
> ---
>  Source/C/Makefiles/header.makefile |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Source/C/Makefiles/header.makefile
> b/Source/C/Makefiles/header.makefile
> index 6895f98..7939db0 100644
> --- a/Source/C/Makefiles/header.makefile
> +++ b/Source/C/Makefiles/header.makefile
> @@ -39,6 +39,10 @@ ifeq ($(ARCH), ARM)
>  ARCH_INCLUDE = -I $(MAKEROOT)/Include/Arm/
>  endif
> 
> +ifeq ($(ARCH), AARCH64)
> +ARCH_INCLUDE = -I $(MAKEROOT)/Include/AArch64/
> +endif
> +
>  INCLUDE = $(TOOL_INCLUDE) -I $(MAKEROOT) -I $(MAKEROOT)/Include/Common
> -I $(MAKEROOT)/Include/ -I $(MAKEROOT)/Include/IndustryStandard -I
> $(MAKEROOT)/Common/ -I .. -I . $(ARCH_INCLUDE)
>  CPPFLAGS = $(INCLUDE)
>  CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -fno-merge-constants -
> nostdlib -Wall -Werror -c -g
> --
> 1.7.10.4
> 
> 
> ---
> ---
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel





--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] AARCH64 ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c question. TCR adjusted but not written.

[Olivier Martin]

Am I missing something or the line 615 is doing what you were expected to
see:
https://github.com/tianocore/edk2/blob/master/ArmPkg/Library/ArmLib/AArch64/
AArch64Mmu.c#L615

 

Thanks,

Olivier

 

From: Kirkendall, Garrett [mailto:garrett.kirkend...@amd.com] 
Sent: 12 August 2014 21:54
To: edk2-devel@lists.sourceforge.net
Subject: [edk2] AARCH64 ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c question.
TCR adjusted but not written.

 

In ArmPkg/Library/ArmLib/AArch64/AArch64Mmu.c:ArmConfigureMmu()  there is a
section of code that puzzles me.

 

 

 

  // Translate the Memory Attributes into Translation Table Register
Attributes

  if ((TranslationTableAttribute ==
ARM_MEMORY_REGION_ATTRIBUTE_UNCACHED_UNBUFFERED) ||

  (TranslationTableAttribute ==
ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_UNCACHED_UNBUFFERED)) {

TCR |= TCR_SH_NON_SHAREABLE | TCR_RGN_OUTER_NON_CACHEABLE |
TCR_RGN_INNER_NON_CACHEABLE;

  } else if ((TranslationTableAttribute ==
ARM_MEMORY_REGION_ATTRIBUTE_WRITE_BACK) ||

  (TranslationTableAttribute ==
ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_WRITE_BACK)) {

TCR |= TCR_SH_INNER_SHAREABLE | TCR_RGN_OUTER_WRITE_BACK_ALLOC |
TCR_RGN_INNER_WRITE_BACK_ALLOC;

  } else if ((TranslationTableAttribute ==
ARM_MEMORY_REGION_ATTRIBUTE_WRITE_THROUGH) ||

  (TranslationTableAttribute ==
ARM_MEMORY_REGION_ATTRIBUTE_NONSECURE_WRITE_THROUGH)) {

TCR |= TCR_SH_NON_SHAREABLE | TCR_RGN_OUTER_WRITE_THROUGH |
TCR_RGN_INNER_WRITE_THROUGH;

  } else {

// If we failed to find a mapping that contains the root translation
table then it probably means the translation table

// is not mapped in the given memory map.

ASSERT (0);

Status = RETURN_UNSUPPORTED;

goto FREE_TRANSLATION_TABLE;

  }

 

 

 

The code will either adjust the TCR variable with the shareability bits
[13:8] or assert.  The problem is that I don't see where the code following
this does anything with that adjusted value.  Maybe I'm missing it, but I
just don't see it.  Is it actually supposed to be written back into the TCR
register, or is just intended to get to the return of the unsupported?

 

Garrett Kirkendall   Description: Description: Description: purple
SMTS Firmware Engineer | AMD Technology & Engineering
7171 Southwest Parkway, Austin, TX 78735 USA 
Description: Description: Description: image004
 facebook  |    amd.com

 
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH 0/2] MdePkg: BaseOrderedCollectionRedBlackTreeLib: suppress wrong warnings

[Laszlo Ersek]

Gcc-4.4 and VS2005 emit a number of false warnings, silence them.

Jordan, can you please help apply these? I'd like the commit messages to
stay intact. Thank you.

Laszlo Ersek (2):
  MdePkg: BaseOrderedCollectionRedBlackTreeLib: silence invalid gcc
warning
  MdePkg: BaseOrderedCollectionRedBlackTreeLib: silence invalid VS2005
warnings

 .../BaseOrderedCollectionRedBlackTreeLib.c   | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

-- 
1.8.3.1


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH 1/2] MdePkg: BaseOrderedCollectionRedBlackTreeLib: silence invalid gcc warning

[Laszlo Ersek]

Gcc-4.4 reports the following build failure:

  BaseOrderedCollectionRedBlackTreeLib.c:
In function 'OrderedCollectionInsert':
  BaseOrderedCollectionRedBlackTreeLib.c:586:
error: 'Result' may be used uninitialized in this function

This is incorrect. There are two areas of use of Result to consider:

- In the very first while loop. The warning is likely not about this code
  area, because Result is assigned directly before use.

- The last use of Result in the function. The build warning / error is
  incorrect. For Result to be uninitialized at that point, the very first
  while loop must not have been entered at all (because that loop assigns
  a value to Result). However, if that loop is never entered, then Parent
  is still NULL. And Parent==NULL implies that the use of Result is never
  reached, because we jump to the Done label just before it.

Assign an irrelevant value of 0 to Result at the beginning of the function
in order to silence the incorrect warning.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 .../BaseOrderedCollectionRedBlackTreeLib.c   | 1 +
 1 file changed, 1 insertion(+)

diff --git 
a/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c
 
b/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c
index fc554b7..9f40b70 100644
--- 
a/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c
+++ 
b/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c
@@ -589,6 +589,7 @@ OrderedCollectionInsert (
 
   Tmp = Tree->Root;
   Parent = NULL;
+  Result = 0;
 
   //
   // First look for a collision, saving the last examined node for the case
-- 
1.8.3.1



--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

[edk2] [PATCH 2/2] MdePkg: BaseOrderedCollectionRedBlackTreeLib: silence invalid VS2005 warnings

[Laszlo Ersek]

VS2005 reports the following build failure:

  BaseOrderedCollectionRedBlackTreeLib.c(151) : warning C4244:
'return' : conversion from 'int' to 'BOOLEAN', possible loss of data
  BaseOrderedCollectionRedBlackTreeLib.c(840) : warning C4244:
'return' : conversion from 'int' to 'BOOLEAN', possible loss of data

This is incorrect. The ISO C standard guarantees that the expressions in
question can only return values 0 and 1, both of which can be represented
by BOOLEAN (== UINT8, == unsigned char).

Silence the incorrect warnings with explicit casts to BOOLEAN.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek 
---
 .../BaseOrderedCollectionRedBlackTreeLib.c| 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c
 
b/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c
index 9f40b70..b37caf2 100644
--- 
a/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c
+++ 
b/MdePkg/Library/BaseOrderedCollectionRedBlackTreeLib/BaseOrderedCollectionRedBlackTreeLib.c
@@ -148,7 +148,7 @@ OrderedCollectionIsEmpty (
   IN CONST RED_BLACK_TREE *Tree
   )
 {
-  return Tree->Root == NULL;
+  return (BOOLEAN)(Tree->Root == NULL);
 }
 
 
@@ -838,7 +838,7 @@ NodeIsNullOrBlack (
   IN CONST RED_BLACK_TREE_NODE *Node
   )
 {
-  return Node == NULL || Node->Color == RedBlackTreeBlack;
+  return (BOOLEAN)(Node == NULL || Node->Color == RedBlackTreeBlack);
 }
 
 
-- 
1.8.3.1


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 1/2] OvmfPkg: enable SATA controller

[Reza Jelveh]

On 12/08/14 23:16, A. Sava wrote:
> Hi Reza,
> 
> Take note that regarding SataControllerDxe, there still remains a problem
> that effects Qemu functionality.
> 
> On this query:
> 
> Data32 = AhciReadReg (PciIo, R_AHCI_CAP);
> 
> SataPrivateData->IdeInit.ChannelCount = (UINT8) ((Data32 & B_AHCI_CAP_NPS)
> + 1);
> 
> qemu seems to always report 1 channel. This will end in only the first AHCI
> device being detected.
> 
> As a temporal workaround, to allow all AHCI channels detected, you
> could change the second line to:
> 
> SataPrivateData->IdeInit.ChannelCount = 6;
> 
> but if you can, you should probably promote a fix at qemu's side for this.

I've been debugging this last night. Are you sure that this is a Qemu bug? It
looks to me like it's an error in SataController.

SataController should not read CAP register in its start method. That's where
it installs the protocol for AtaAtapiPassthru to use. Rather it should be set
later by the init function.

The CAP register is read fine after AhciMode initialization, but
SataController reads its before attaching to the bus or something like that, I
think.


--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel

Re: [edk2] [PATCH 2/2] MdeModulePkg: Check D2H register status in AhciPioTransfer

[A. Sava]

Hi Feng,

Sounds like situation with Marvell is similar to Qemu.

As I wrote earlier in this thread, Qemu also doesn't use PIO Setup FIS, it
puts only D2H FIS at the end of a PIO command. That's why Reza checked if
there are other controllers that behave similarly, and he found that
Marvell would be one.

So, for both of them, it means that your patch will not break out at all,
as it will never get to check:
if (PrdCount == DataCount) { .. }

Cheers,
A. Sava


On Wed, Aug 13, 2014 at 4:04 AM, Tian, Feng  wrote:

> Hi, Reza
>
> Thanks for your effort, Reza. I made a little coding style enhancement
> based on your proposed patch. please help view it.
>
> PS: I am a little curious on "some Marvel controllers use D2H only instead
> of PIO Setup FIS". If it's that case, does it mean current logic will never
> break out the loop? Do we need enhance code to handle this?
>
> Thanks
> Feng
>
> -Original Message-
> From: Reza Jelveh [mailto:reza.jel...@tuhh.de]
> Sent: Tuesday, August 12, 2014 19:10
> To: Tian, Feng
> Cc: edk2-devel@lists.sourceforge.net; ag...@suse.de
> Subject: Re: [edk2] [PATCH 2/2] MdeModulePkg: Check D2H register status in
> AhciPioTransfer
>
> On 11/08/14 01:07, Tian, Feng wrote:
> > Hi, Reza
> >
> > IMHO, it should jump out the loop at the below point if we put break
> statement inside the new if.
> >
> > PrdCount = *(volatile UINT32 *)
> (&(AhciRegisters->AhciCmdList[0].AhciCmdPrdbc));
> > if (PrdCount == DataCount) {
> >   break;
> > }
> >
> > As I have no the test env, could you help me verify if it's true?
>
> I see what you mean now. Yes, this works fine, I also found out that
> apparently some Marvel controllers use D2H only instead of PIO Setup FIS.
> Intel controllers don't have that problem.
>
> I have adjusted the patch according to your suggestion.
>
>
> --
>
> ___
> edk2-devel mailing list
> edk2-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/edk2-devel
>
>
--
___
edk2-devel mailing list
edk2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-devel