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

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

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

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 t

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

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 1

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

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

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 Modu

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

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] [Pa

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

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

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

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 Sign

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

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 SH

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

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

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: Tho

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

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_PROT

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

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 t

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,

[edk2] Shell compatibility with non-FAT filesystems

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

[edk2] PEI_DEPEX and DXE_DEPEX in .INF files

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 =

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

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

Re: [edk2] 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\u

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

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

[edk2] Check Ata device supports CHS

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 bi

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

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

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

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-d

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

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: BaseOrderedCollectionRedBl

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

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

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

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', poss

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

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_CA

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

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 b