Re: [edk2] [PATCH] BaseTools: Add rules to build NASM source file into a binary

Jordan: Yes if NASM_PREFIX or IASL_PREFIX could be auto set. OK. I got it. I have no other comments. Reviewed-by: Gao, Liming Thanks Liming -Original Message- From: Jordan Justen [mailto:jljus...@gmail.com] Sent: Monday, August 04, 2014 2:53 PM To: edk2-devel@lists.sourceforge.ne

Re: [edk2] [PATCH] BaseTools: Add AArch64 ADR_PREL_LO21 and R_AARCH64_CONDBR19 relocations

Olivier, The patch is good to me. Reviewed-by: Yingke Liu mailto:yingke.d@intel.com>> Thanks, Dennis From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Saturday, August 02, 2014 2:22 AM To: edk2-devel@lists.sourceforge.net; Wang, Yu Cc: Harry Liebel Subject: Re: [edk2] [PATCH] BaseT

Re: [edk2] [RFC v1 00/17] Introduce Mp Service protocol to UefiCpuPkg

On Fri, 2014-08-01 at 05:45 +, Fan, Jeff wrote: > Chen, > > Because this is a serial patches, could you zip and send your > UefiCpuPkg/CpuDxe to my mailbox or this mail list. Thanks! Hi all, I had pushed my local 'mpservice' patches to github: https://github.com/ChenFanFnst/edk2/tre

[edk2] NetLib as a Library class in ArmPlatformPkg/Bds/Bds.inf

Hi, The latest edk2/ArmPlatformPkg/Bds/Bds.inf puts NetLib as a required Library class. Some ARM based platforms (including ours) uses ArmPlatformPkg/Bds as the Boot Device Selection source. However, for such platforms, NetLib support can sometimes be optional for the BDS stage, causing compi

Re: [edk2] making UEFI driver part of optrom

Hi Vladimir, We are building the UEFI driver ROM image using EBC compiler using below method: EfiRom -f vendorid -i deviceid -l classcode -o ABCD.rom -ec ABCD.efi Does building the UEFI driver ROM image using EBC compiler (EfiROM utility), address the below requirements stated in section 13.4.2 o

[edk2] FW: SF.net SVN: edk2:[15731] trunk/edk2/ShellPkg

Hello Jaben, Interestingly it was a feature I was thinking to add to the Shell specification a couple of month ago because we needed it. But I have just seen it has been added to the latest Shell spec. Are you planning to implement this feature in the next few weeks? If no, ARM Ltd could do it. R

[edk2] AARCH64 UEFI and EL3

Hi, The current AARCH64 UEFI is designed to run entirely in EL2 with the assumption that the ARM Trusted FW (ATF) running in EL3 and launching UEFI in EL2. As a result if we try to use the UEFI bootloader as a bare-metal debug tool (w/o the ATF, BootROM and so on..), we get an assertion failure

Re: [edk2] StdLib: the long standing build error

Any update on this issue? Thanks, Olivier From: Carsey, Jaben [mailto:jaben.car...@intel.com] Sent: 03 June 2014 18:06 To: Olivier Martin; edk2-devel@lists.sourceforge.net; Mcdaniel, Daryl Cc: Harry Liebel; Mitchell, Mark L; Carsey, Jaben Subject: RE: StdLib: the long standing build error

Re: [edk2] [RFC v1 00/17] Introduce Mp Service protocol to UefiCpuPkg

Chen, Thanks! I will review your patches and feedback in later time. :-) Jeff -Original Message- From: chen.fan.f...@cn.fujitsu.com [mailto:chen.fan.f...@cn.fujitsu.com] Sent: Monday, August 04, 2014 3:40 PM To: edk2-devel@lists.sourceforge.net Cc: Fan, Jeff; Jordan Justen Subject: Re:

Re: [edk2] AARCH64 UEFI and EL3

To be more clear, I wouldn't call this "UEFI in EL3" since UEFI is really the OS/driver interface, instead I would call it something like "SEC/PEI in EL3". Note that SEC and PEI are described in the PI specification and don't existing in the UEFI specification. We too are looking at this same

Re: [edk2] FW: SF.net SVN: edk2:[15731] trunk/edk2/ShellPkg

Olivier, this is something HP implemented and added for inclusion in the shell spec a long time ago. We have contributed the implementation of dynamic command handling and Jaben is in the process of integrating it. Hopefully Jaben will be able to integrate the implementation shortly so you can

[edk2] [PATCH] CryptoPkg: Fix OpenSslLib build for ARM

The ARM toolchain definitions are configured to treat warnings as errors. The openssl code has numerous warnings so this patch tells the ARM RVCT compiler to ignore those warnings. This patch also fixes an issue where the openssl compiler flags were not being provided for the RVCT toolchain.

Re: [edk2] [PATCH 1/2] MdePkg: introduce RbTreeLib

On 08/03/14 21:17, Kinney, Michael D wrote: > If the library is type BASE, then why do you need UefiBaseTypes.h? > For libs of type BASE, the return status codes should be RETURN_* > instead of EFI_*. That may reduce the dependency on > UefiBaseTypes.h. Ah, good point! And indeed I think the sol

Re: [edk2] [PATCH] CryptoPkg: Fix OpenSslLib build for ARM

If I was the CryptoPkg maintainer I would probably request to add the correlation between the warning numbers and their associated warning messages. I did that for SctPkg: # 167: "argument of type is incompatible with parameter of type # " # (caused here by passing typed pointers to f

Re: [edk2] [PATCH 1/2] MdePkg: introduce RbTreeLib

Laszlo, The incomplete types between lib class .h and lib instance is not something we done anywhere else. I prefer the lib class .h file to be able to stand on its own. Meaning it can be included by a module, but if not lib instance is linked to the module, the module should still be able to

Re: [edk2] [edk2-buildtools] [PATCH 2/3] MdePkg: Introduced BaseStackCheckLib

Recommended value does not mean unique value. Anyway, no one has commented whether this value should be kept in the code or be replaced by a PCD. So, I will keep the original code. I will send a new patchset in the next couple of minutes to define this class instance as NULL instead of BASE. O

[edk2] [PATCH v2 0/3] Added support for GCC stack protector for ARM architectures (BaseTools & MdePkg)

Changeloc compare to first version: - Added 'Reviewed-by: Yingke Liu ' for the BaseTools changes - Fixed line endings into the MdePkg patch - Replaced BASE by NULL for LIBRARY_CLASS - Fixed Andrew Fish email address Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Andrew Fis

[edk2] [PATCH v2 2/3] ARM Packages: Added support for GCC stack protector

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin --- ArmPkg/ArmPkg.dsc | 8 ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc | 21 - ArmPlatformPkg/ArmPlatformPkg.dsc | 22 ++

[edk2] [PATCH v2 3/3] BaseTools: Added support for GCC stack protector for ARM architecture

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Olivier Martin Reviewed-by: Yingke Liu --- BaseTools/Conf/tools_def.template | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/BaseTools/Conf/tools_def.template b/BaseTools/Conf/too

[edk2] [PATCH v2 1/3] MdePkg: Introduced BaseStackCheckLib

This library only support GCC, RVCT and XCode for now. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Andrew Fish Signed-off-by: Olivier Martin --- .../Library/BaseStackCheckLib/BaseStackCheckGcc.c | 62 ++ .../BaseStackCheckLib/BaseStackCheckLib.inf

Re: [edk2] [edk2-buildtools] [PATCH 2/3] MdePkg: Introduced BaseStackCheckLib

On Aug 4, 2014, at 8:30 AM, Olivier Martin wrote: > Recommended value does not mean unique value. Anyway, no one has commented > whether this value should be kept in the code or be replaced by a PCD. So, I > will keep the original code. > I will send a new patchset in the next couple of minute

Re: [edk2] [edk2-buildtools] [PATCH 2/3] MdePkg: Introduced BaseStackCheckLib

The benefit of the FixedPcd was to be an easy alternative between the recommended constant value and the random number. A Firmware vendor might want to use a different canary value as the open source project. Olivier From: Andrew Fish [mailto:af...@apple.com] Sent: 04 August 2014 16:44 To

Re: [edk2] NetLib as a Library class in ArmPlatformPkg/Bds/Bds.inf

On Aug 4, 2014, at 1:42 AM, bhupesh.sha...@freescale.com wrote: > Hi, > > The latest edk2/ArmPlatformPkg/Bds/Bds.inf puts NetLib as a required Library > class. > > Some ARM based platforms (including ours) uses ArmPlatformPkg/Bds as the Boot > Device Selection source. > > However, for such p

Re: [edk2] [edk2-buildtools] [PATCH 2/3] MdePkg: Introduced BaseStackCheckLib

On Aug 4, 2014, at 8:50 AM, Olivier Martin wrote: > The benefit of the FixedPcd was to be an easy alternative between the > recommended constant value and the random number. > A Firmware vendor might want to use a different canary value as the open > source project. > I guess the PCD could

Re: [edk2] [PATCH 1/2] MdePkg: introduce RbTreeLib

On 08/04/14 17:02, Kinney, Michael D wrote: > The incomplete types between lib class .h and lib instance is not > something we done anywhere else. I prefer the lib class .h file to > be able to stand on its own. It is able. > Meaning it can be included by a module, but if not lib instance is

Re: [edk2] [PATCH 1/2] MdePkg: introduce RbTreeLib

On Aug 4, 2014, at 9:55 AM, Laszlo Ersek wrote: > On 08/04/14 17:02, Kinney, Michael D wrote: > >> The incomplete types between lib class .h and lib instance is not >> something we done anywhere else. I prefer the lib class .h file to >> be able to stand on its own. > > It is able. > >> Me

[edk2] ShellPkg: Fix comments

Bjorge, Can you review? Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jaben Carsey HandleParsingLib.h.patch Description: HandleParsingLib.h.patch -- Infragistics Professional Build stunning Wi

Re: [edk2] ShellPkg: Fix comments

Reviewed-by: Erik Bjorge From: Carsey, Jaben Sent: Monday, August 04, 2014 1:07 PM To: Bjorge, Erik C Cc: edk2-devel@lists.sourceforge.net; Carsey, Jaben Subject: ShellPkg: Fix comments Bjorge, Can you review? Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jaben Carsey

Re: [edk2] [RFC 1/2] EDK II Contributions.txt: Update patch format information

> -Original Message- > From: Justen, Jordan L > Sent: Friday, August 01, 2014 6:03 PM > To: edk2-devel@lists.sourceforge.net; Carsey, Jaben; edk2- > de...@lists.sourceforge.net > Subject: Re: [edk2] [RFC 1/2] EDK II Contributions.txt: Update patch format > information > Importance: High >

Re: [edk2] [PATCH 1/2] MdePkg: introduce RbTreeLib

Laszlo, Thanks for the detailed response. I agree that use of VOID * prevents the compiler from helping with type checking. This is why you see many existing structures that do use VOID * have a Signature field at the beginning and functions that use those structures check the Signature va

[edk2] ShellPkg: Add new UEFI Shell 2.1 protocol and fix comments in handle parsing

Bjorge, Can you check this please? Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jaben Carsey UefiHandleParsingLib.patch Description: UefiHandleParsingLib.patch UefiHandleParsingLib.uni Description: UefiHandleParsingLib.uni --

Re: [edk2] ShellPkg: Add new UEFI Shell 2.1 protocol and fix comments in handle parsing

Reviewed-by: Erik Bjorge From: Carsey, Jaben Sent: Monday, August 04, 2014 2:14 PM To: Bjorge, Erik C Cc: edk2-devel@lists.sourceforge.net; Carsey, Jaben Subject: ShellPkg: Add new UEFI Shell 2.1 protocol and fix comments in handle parsing Bjorge, Can you check this please? Contributed-under

Re: [edk2] [RFC v1 00/17] Introduce Mp Service protocol to UefiCpuPkg

chen.fan.f...@cn.fujitsu.com [mailto:chen.fan.f...@cn.fujitsu.com] wrote: ]On Fri, 2014-08-01 at 05:45 +, Fan, Jeff wrote: ]> Chen, ]> ]> Because this is a serial patches, could you zip and send your ]UefiCpuPkg/CpuDxe to my mailbox or this mail list. Thanks! ]Hi all, ] ] I had pushed my

[edk2] ShellPkg: Update Shell Protocol header with new function prototypes and structure

Erik, Can you review? This adds the new APIs for UEFI Shell 2.1 and makes a new structure for shell implementations that are conformant to this new spec. It does not affect existing implementations. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jaben Carsey EfiSh

[edk2] ShellPkg: Add Dynamic GUID registration into the current GUID<->String conversion process

Erik, Can you review? Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jaben Carsey DynamicGuid.patch Description: DynamicGuid.patch -- Infragistics Professional Build stunning WinForms apps t

Re: [edk2] [RFC 1/2] EDK II Contributions.txt: Update patch format information

On 2014-08-04 13:28:12, Carsey, Jaben wrote: > > -Original Message- > > From: Justen, Jordan L > > Sent: Friday, August 01, 2014 6:03 PM > > To: edk2-devel@lists.sourceforge.net; Carsey, Jaben; edk2- > > de...@lists.sourceforge.net > > Subject: Re: [edk2] [RFC 1/2] EDK II Contributions.txt:

Re: [edk2] [RFC 1/2] EDK II Contributions.txt: Update patch format information

> -Original Message- > From: Justen, Jordan L > Sent: Monday, August 04, 2014 4:16 PM > To: Carsey, Jaben; edk2-devel@lists.sourceforge.net > Subject: Re: [edk2] [RFC 1/2] EDK II Contributions.txt: Update patch format > information > Importance: High > > On 2014-08-04 13:28:12, Carsey, J

Re: [edk2] [RFC 1/2] EDK II Contributions.txt: Update patch format information

On 2014-08-04 16:21:27, Carsey, Jaben wrote: > > From: Justen, Jordan L > > On 2014-08-04 13:28:12, Carsey, Jaben wrote: > > > > From: Justen, Jordan L > > > > On 2014-08-01 17:13:45, Carsey, Jaben wrote: > > > > > I find that replying with another patch is often much more useful > > > > > than I t

Re: [edk2] [RFC 1/2] EDK II Contributions.txt: Update patch format information

I guess I don’t know what motivates these changes. What is the problem in our current process that we are resolving? If we just want git people to be happy, what are they unhappy about? We don’t reject their patches so far as I know... We don’t seem to be having problems where we need to know

Re: [edk2] [RFC v1 00/17] Introduce Mp Service protocol to UefiCpuPkg

On Mon, 2014-08-04 at 17:01 -0500, Scott Duplichan wrote: > chen.fan.f...@cn.fujitsu.com [mailto:chen.fan.f...@cn.fujitsu.com] wrote: > > ]On Fri, 2014-08-01 at 05:45 +, Fan, Jeff wrote: > ]> Chen, > ]> > ]> Because this is a serial patches, could you zip and send your > ]UefiCpuPkg/CpuDxe

Re: [edk2] [RFC 1/2] EDK II Contributions.txt: Update patch format information

On 2014-08-04 17:44:32, Carsey, Jaben wrote: > I guess I don’t know what motivates these changes. What is the > problem in our current process that we are resolving? If we just > want git people to be happy, what are they unhappy about? We don’t > reject their patches so far as I know... Do we

Re: [edk2] [PATCH] CryptoPkg: Fix OpenSslLib build for ARM

Thanks, Martin & Eugene. Eugene, would you like to update your patch to add this kind of correlation description about the warning number & messages as Martin's comments? Best Regards & Thanks, LONG, Qin From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Monday, August 04, 2014 10:29 P

[edk2] [PATCH v2 0/3] MdePkg: ordered collections, AppPkg: unit tester

Addressing Mike's comments. Library class and library instance have been split apart (patches 1 & 2). Changes are broken out per patch, in the git-notes sections. Retested. Public branch: . Laszlo Ersek (3): MdePkg: introduce OrderedCollectionL

[edk2] [PATCH v2 1/3] MdePkg: introduce OrderedCollectionLib library class

This library class provides a set of APIs to manage an ordered collection of items: - Init(), - UnInit(), - Insert(), - Delete(), - IsEmpty(), - Next(), - Prev(), - Min(), - Max(), - Find(), - UserStruct(), - Validate(). There are many ways to implement an ordered collection. Depending on the freq

[edk2] [PATCH v2 3/3] AppPkg: introduce OrderedCollectionTest

In this patch a small application is added to AppPkg, with the following two goals: - demonstrate how to use OrderedCollectionLib, - allow users to test and "fuzz" BaseOrderedCollectionRedBlackTreeLib in particular, entering API "commands" interactively, or providing them from a script file. A

[edk2] [PATCH v2 2/3] MdePkg: introduce BaseOrderedCollectionRedBlackTreeLib library instance

edk2 should have a fast and easy-to-use associative array (a dictionary) type. Red-black trees have O(log(n)) worst case time complexity for lookup, insertion, and deletion (where n is the number of nodes in the tree). They support minimum and maximum lookup with the same time complexity, hence re

Re: [edk2] [edk2-buildtools] [PATCH 2/3] MdePkg: Introduced BaseStackCheckLib

Martin: I am fine to use FixedPcd for value 0x0AFF. Have you plan to add this PCD in your patch? Thanks Liming From: Olivier Martin [mailto:olivier.mar...@arm.com] Sent: Monday, August 04, 2014 11:51 PM To: 'Andrew Fish' Cc: Gao, Liming; Kinney, Michael D; edk2-buildtools-de...@lists.sourcefor

Re: [edk2] [RFC 2/2] EDK II Contributions.txt: Note acceptable contribution licenses

Reviewed-by: Mark Doran Fix "BDS" to read "BSD" (two instances) and I think it's good to go. -- Cheers,   Mark.   -Original Message- From: Justen, Jordan L Sent: Friday, August 1, 2014 3:52 PM To: edk2-devel@lists.sourceforge.net Cc: Justen, Jordan L; Doran, Mark Subject: [RFC 2/2] EDK