Re: [edk2] [PATCH] Maintainers.txt: Add Giri as 2nd maintainer

Thanks to open the bug. Yes, I will use your recommendation below when I check in the patch later. Thank you Yao Jiewen From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jordan Justen Sent: Thursday, September 8, 2016 1:06 PM To: Yao, Jiewen ;

Re: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

Hi Eric, Memory Page size Minimum (MPSMIN) is not exposed in the UEFI Scope. Any schedule when this issue would be address in the SCT tool ? Thanks, Ramesh -Original Message- From: Jin, Eric [mailto:eric@intel.com] Sent: 05 September 2016 10:54 To: Tian, Feng; Ramesh R.;

Re: [edk2] BootableImageSupportTest\StorageSecurityCommandProtocolTest

Hi Feng, With the device we have , we tried 512 as size and all the devices returns EFI_SUCCESS. Thanks, Ramesh -Original Message- From: Tian, Feng [mailto:feng.t...@intel.com] Sent: 05 September 2016 08:48 To: Ramesh R.; edk2-devel; Jin, Eric Cc: Tian, Feng Subject: RE:

Re: [edk2] [PATCH] Maintainers.txt: Add Giri as 2nd maintainer

On 2016-09-07 15:31:12, Yao, Jiewen wrote: >The problem I am seeing is “inconsistence”. > I opened this bug: https://tianocore.acgmultimedia.com/show_bug.cgi?id=113 For now, can you consider the one I recommended? It is 70 characters: Maintainers.txt: Add Giri as IntelFsp2*Pkg,

Re: [edk2] [Patch 0/4] BaseTools GNU makefile: Update GCC Flags to the specific one with BUILD_ prefix

Reviewed the series of 4 patches. Reviewed-by: Yonghong Zhu Best Regards, Zhu Yonghong -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming Gao Sent: Tuesday, September 06, 2016 12:00 PM To: edk2-devel@lists.01.org

[edk2] [PATCH v1 5/5] UefiCpuPkg/PiSmmCpuDxeSmm: Abstact processor features

Use newly created functions that abstract how XD/NX is detected, enabled, and disabled. Also, use a new function to determine if Branch Trace Storage is supported. Existing code is specific to Intel processors. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Joseph

[edk2] [PATCH v1 3/5] QuarkSocPkg/SmmCpuFeaturesLib: Abstact processor features

Create new functions to abstract how XD/NX is detected, enabled, and disabled. Also, create a new function to determine if Branch Trace Storage is supported. Existing code is specific to Intel processors. This provides NULL implementations of the new functions. Contributed-under: TianoCore

[edk2] [PATCH v1 4/5] OvmfPkg/SmmCpuFeaturesLib: Abstact processor features

Create new functions to abstract how XD/NX is detected, enabled, and disabled. Also, create a new function to determine if Branch Trace Storage is supported. Existing code is specific to Intel processors. This provides NULL implementations of the new functions. Contributed-under: TianoCore

[edk2] [PATCH v1 2/5] UefiCpuPkg/SmmCpuFeaturesLib: Abstact processor features

Create new functions to abstract how XD/NX is detected, enabled, and disabled. Also, create a new function to determine if Branch Trace Storage is supported. Existing code is specific to Intel processors. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Joseph Shifflett

[edk2] [PATCH v1 0/5] Abstract the detect/enable/disable of several x86 features

This series abstracts accesses to various x86 features. Existing code used Intel specific MSR accesses to detect support and to enable/disable features. Cc: Jeff Fan Cc: Michael D Kinney Cc: Kelly Steele Cc: Jordan

[edk2] [PATCH v1 1/5] UefiCpuPkg: SmmCpuFeaturesLib.h: Abstact processor features

Create new functions to abstract how XD/NX is detected, enabled, and disabled. Also, create a new function to determine if Branch Trace Storage is supported. Existing code is specific to Intel processors. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Joseph Shifflett

Re: [edk2] [PATCH] Maintainers.txt: Add Giri as 2nd maintainer

Agee with Jiewen to keep the doc and tool consistent. Also the patch prefix "[edk2][PATCH]" should be excluded as it is not part of the commit message title. Thanks, -Giri > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Yao, > Jiewen >

Re: [edk2] [PATCH] OvmfPkg/QemuBootOrderLib: drop too strict "/HD(" suffix from vblk prefix

Reviewed-by: Jordan Justen On 2016-09-07 04:42:43, Laszlo Ersek wrote: > Translating QEMU's virtio-block OpenFirmware device path to a UEFI device > path prefix was one of the earliest case handled in QemuBootOrderLib. At > that time, I terminated the translation

Re: [edk2] [PATCH] Maintainers.txt: Add Giri as 2nd maintainer

The problem I am seeing is “inconsistence”. The https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format mention 70 char as max. But the tool check 76 char. Can we make then consistent? Either change wiki to 76 char, or change tool to 70 char. Thank you Yao Jiewen From:

Re: [edk2] [PATCH] Maintainers.txt: Add Giri as 2nd maintainer

On 2016-09-07 10:49:21, Ard Biesheuvel wrote: > On 7 September 2016 at 18:39, Jordan Justen wrote: > > > > If it is difficult to make a good short subject > > line, then it might be a sign that the patch should be split. For > > example, you could split this patch in 2.

Re: [edk2] [PATCH] Maintainers.txt: Add Giri as 2nd maintainer

On 7 September 2016 at 18:39, Jordan Justen wrote: > On 2016-09-07 01:00:46, Yao, Jiewen wrote: >>Jordan >> >>I have a quick check: >> >>Here is my observation: >> >>1) From >> >>

Re: [edk2] [PATCH] Maintainers.txt: Add Giri as 2nd maintainer

On 2016-09-07 01:00:46, Yao, Jiewen wrote: >Jordan > >I have a quick check: > >Here is my observation: > >1) From > > https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format, >it mentions: > > o The length of 'Pkg-Module:

Re: [edk2] [PATCH] ShellPkg: pci -i -_e to print next capability

Change Looks good. Can you please clarify the commit message on why to change -_e type? Reviewed-by: Jaben Carsey > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Abdul Lateef Attar > Sent: Monday, September 05,

Re: [edk2] [PATCH v4 2/3] MdePkg/BaseMemoryLibOptDxe: add accelerated ARM routines

On 7 September 2016 at 15:52, Ard Biesheuvel wrote: > This adds ARM support to BaseMemoryLibOptDxe, partially based on the > cortex-strings library (ScanMem) and the existing CopyMem() implementation > from BaseMemoryLibStm in ArmPkg. > > All string routines are

Re: [edk2] CLANG cross-compilation issue

> On Sep 7, 2016, at 8:27 AM, Leif Lindholm wrote: > > Hi all, > > This is a report for the archive, rather than anything easily fixable. > While testing one of Ard's sets against CLANG, I tripped over a > behaviour exposed by commit a1b8baccc30b > (BaseTools GCC: use

[edk2] CLANG cross-compilation issue

Hi all, This is a report for the archive, rather than anything easily fixable. While testing one of Ard's sets against CLANG, I tripped over a behaviour exposed by commit a1b8baccc30b (BaseTools GCC: use 'gcc' as the linker command for GCC44 and later). This commit changes the CLANG profiles to

Re: [edk2] [PATCH 1/2] BaseTools/tools_def AARCH64: enable frame pointers for DEBUG builds

On Wed, Sep 07, 2016 at 09:21:54AM +0100, Ard Biesheuvel wrote: > Enable frame pointers on DEBUG builds so we can support backtraces in > crash dumps. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ard Biesheuvel This is really handy -

[edk2] [PATCH v4 1/3] MdePkg/BaseMemoryLib: widen aligned accesses to 32 or 64 bits

Since the default BaseMemoryLib should be callable from any context, including ones where unaligned accesses are not allowed, it implements InternalCopyMem() and InternalSetMem() using byte accesses only. However, especially in a context where the MMU is off, such narrow accesses may be

[edk2] [PATCH v4 2/3] MdePkg/BaseMemoryLibOptDxe: add accelerated ARM routines

This adds ARM support to BaseMemoryLibOptDxe, partially based on the cortex-strings library (ScanMem) and the existing CopyMem() implementation from BaseMemoryLibStm in ArmPkg. All string routines are accelerated except ScanMem16, ScanMem32, ScanMem64 and IsZeroBuffer, which can wait for another

[edk2] [PATCH v4 0/3] MdePkg: add ARM/AARCH64 support to BaseMemoryLib

This adds ARM and AARCH64 support to both BaseMemoryLib (generic C) and BaseMemoryLibOptDxe (accelerated). The former can be used anywhere, the latter only in places where the caches are guaranteed to be on, not only due to the unaligned accesses but also due to the fact that it uses DC ZVA

[edk2] [PATCH v4 3/3] MdePkg/BaseMemoryLibOptDxe: add accelerated AARCH64 routines

This adds AARCH64 support to BaseMemoryLibOptDxe, based on the cortex-strings library. All string routines are accelerated except ScanMem16, ScanMem32, ScanMem64 and IsZeroBuffer, which can wait for another day. (Very few occurrences exist in the codebase) Contributed-under: TianoCore

Re: [edk2] [PATCH] ArmPlatformPkg/PrePi: fix secondary stack base

On 7 September 2016 at 13:17, Ard Biesheuvel wrote: > On 7 September 2016 at 13:06, Michael Zimmermann > wrote: >> this bug was introduced by: >> d2fa09a ArmPlatformPkg/PrePi: switch to ASM_FUNC() asm macro >> >> Contributed-under: TianoCore

Re: [edk2] [PATCH 22/26] ArmPlatformPkg/PrePi: switch to ASM_FUNC() asm macro

On 7 September 2016 at 12:59, Ard Biesheuvel wrote: > On 7 September 2016 at 12:10, Ryan Harkin wrote: >> On 31 August 2016 at 05:33, Michael Zimmermann >> wrote: >>> reviewed should mean tested ;) >>> >>> took me

Re: [edk2] [PATCH] ArmPlatformPkg/PrePi: fix secondary stack base

On 7 September 2016 at 13:06, Michael Zimmermann wrote: > this bug was introduced by: > d2fa09a ArmPlatformPkg/PrePi: switch to ASM_FUNC() asm macro > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: M1cha > --- >

[edk2] [PATCH] ArmPlatformPkg/PrePi: fix secondary stack base

this bug was introduced by: d2fa09a ArmPlatformPkg/PrePi: switch to ASM_FUNC() asm macro Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: M1cha --- ArmPlatformPkg/PrePi/Arm/ModuleEntryPoint.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [edk2] [PATCH 22/26] ArmPlatformPkg/PrePi: switch to ASM_FUNC() asm macro

On 7 September 2016 at 12:10, Ryan Harkin wrote: > On 31 August 2016 at 05:33, Michael Zimmermann > wrote: >> reviewed should mean tested ;) >> >> took me some time to find out why my system currently doesn't boot anymore > > I have just

[edk2] [PATCH] OvmfPkg/QemuBootOrderLib: drop too strict "/HD(" suffix from vblk prefix

Translating QEMU's virtio-block OpenFirmware device path to a UEFI device path prefix was one of the earliest case handled in QemuBootOrderLib. At that time, I terminated the translation output (the UEFI devpath prefix) with a "/HD(" suffix. The intent was for the translation to prefix-match only

Re: [edk2] [PATCH 2/2] ArmPkg/DefaultExceptionHandlerLib AARCH64: add minimal backtrace to crash dump

On 7 September 2016 at 12:25, Michael Zimmermann wrote: >> However, looking at this >> code, this is still not sufficient to find the *next* frame pointer on >> the stack. > are you sure about that? this code looks like it does just that: >

Re: [edk2] [PATCH 2/2] ArmPkg/DefaultExceptionHandlerLib AARCH64: add minimal backtrace to crash dump

> However, looking at this > code, this is still not sufficient to find the *next* frame pointer on > the stack. are you sure about that? this code looks like it does just that: https://github.com/torvalds/linux/blob/master/arch/arm/kernel/stacktrace.c On Wed, Sep 7, 2016 at 1:03 PM, Ard

Re: [edk2] [PATCH 22/26] ArmPlatformPkg/PrePi: switch to ASM_FUNC() asm macro

On 31 August 2016 at 05:33, Michael Zimmermann wrote: > reviewed should mean tested ;) > > took me some time to find out why my system currently doesn't boot anymore I have just bisected my TC2 boot failure down to this patch too. > but here's the fix for this commit:

Re: [edk2] [PATCH 2/2] ArmPkg/DefaultExceptionHandlerLib AARCH64: add minimal backtrace to crash dump

On 7 September 2016 at 10:48, Michael Zimmermann wrote: > nice, can we do this for ARM too? I usually need to add DEBUG((...))'s all > over the place for hours until I found the reason for a fault. > This is going to be tricky. Unlike AARCH64, which unambiguously

Re: [edk2] [PATCH 2/2] ArmPkg/DefaultExceptionHandlerLib AARCH64: add minimal backtrace to crash dump

nice, can we do this for ARM too? I usually need to add DEBUG((...))'s all over the place for hours until I found the reason for a fault. Thanks Michael On Wed, Sep 7, 2016 at 10:21 AM, Ard Biesheuvel wrote: > When dumping the CPU state after an unhandled fault, walk

Re: [edk2] [PATCH 2/2] [edk2-staging/HTTPS-TLS][PATCH]: NetworkPkg/HttpDxe: Unrestrict TLSv

In TlsConfigureSession(), below piece of code should also be removed. Others is good to me. HttpInstance->TlsConfigData.Version.Major = TLS10_PROTOCOL_VERSION_MAJOR; HttpInstance->TlsConfigData.Version.Minor = TLS10_PROTOCOL_VERSION_MINOR; Reviewed-by: Wu Jiaxin

[edk2] [PATCH 1/2] BaseTools/tools_def AARCH64: enable frame pointers for DEBUG builds

Enable frame pointers on DEBUG builds so we can support backtraces in crash dumps. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- BaseTools/Conf/tools_def.template | 12 ++-- 1 file changed, 6 insertions(+), 6

Re: [edk2] [PATCH 1/2] [edk2-staging/HTTPS-TLS][PATCH]: CryptoPkg/TlsLib: TLS Ver negotiate

Thomas, Sorry for the delayed response. The patch is good to me, only one comments: > + TlsCtx = SSL_CTX_new (SSLv23_client_method ()); if (TlsCtx == NULL) > + { > +ASSERT (TlsCtx != NULL); > +return NULL; > + } I think we can remove the assert. Return NULL is fine here.

[edk2] [PATCH 2/2] ArmPkg/DefaultExceptionHandlerLib AARCH64: add minimal backtrace to crash dump

When dumping the CPU state after an unhandled fault, walk the stack frames and decode the return addresses so we can show a minimal backtrace. Unfortunately, we do not have sufficient information to show the function names, but at least we can see the modules and the return addresses inside the

Re: [edk2] [PATCH] Maintainers.txt: Add Giri as 2nd maintainer

Jordan I have a quick check: Here is my observation: 1) From https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format, it mentions: * The length of 'Pkg-Module: Brief-single-line-summary' should not exceed 70 characters 2) In the PatchCheck.py, we have

Re: [edk2] [PATCH] Maintainers.txt: Add Giri as 2nd maintainer

Jordan I got error from BaseTools\Scripts\PatchCheck.py, if I add it. Can you fix the tool to remove such limitation? === Checking patch file: C:\home\EdkIITransition\AllComboGit\edk2\0001-Maintainers.t xt-Add-Giri-as-2nd-maintainer-to-IntelF.patch The commit message format

Re: [edk2] [PATCH v3 0/3] MdePkg: add ARM/AARCH64 support to BaseMemoryLib

Reviewed-by: Liming Gao > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Wednesday, September 07, 2016 2:48 PM > To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; Gao, Liming > > Cc: Kinney, Michael D

Re: [edk2] [PATCH] Maintainers.txt: Add Giri as 2nd maintainer

What about this patch subject instead? Maintainers.txt: Add Giri as IntelFsp2*Pkg, IntelSiliconPkg maintainer This way we can see the affected packages from the subject line. -Jordan On 2016-09-06 18:21:10, Jiewen Yao wrote: > Add Giri as 2nd maintainer to IntelFsp2*Pkg and IntelSiliconPkg. >

[edk2] [PATCH] ArmPkg/ArmGicLib: use correct loop variable

The ArmGicLib API function GicGetCpuRedistributorBase () declares GicCpuRedistributorBase to iterate over the redistributors of all CPUs, but then inadvertently advances GicRedistributorBase instead. Reported-by: "Oliyil Kunnil, Vishal" Contributed-under: TianoCore

Re: [edk2] [PATCH v2 1/3] MdePkg/BaseMemoryLib: widen aligned accesses to 32 or 64 bits

On 7 September 2016 at 04:03, Gao, Liming wrote: > Ard: > In InternalMemSetMem, Value64 = (((UINT64)Value32) << 32) | Value32; may > cause the below link error with VS IA32 build. It (<<) should be replaced by > BaseLib LShift API > > BaseMemoryLib.lib(SetMem.obj) : error

[edk2] [PATCH v3 2/3] MdePkg/BaseMemoryLibOptDxe: add accelerated ARM routines

This adds ARM support to BaseMemoryLibOptDxe, partially based on the cortex-strings library (ScanMem) and the existing CopyMem() implementation from BaseMemoryLibStm in ArmPkg. All string routines are accelerated except ScanMem16, ScanMem32, ScanMem64 and IsZeroBuffer, which can wait for another

[edk2] [PATCH v3 0/3] MdePkg: add ARM/AARCH64 support to BaseMemoryLib

This adds ARM and AARCH64 support to both BaseMemoryLib (generic C) and BaseMemoryLibOptDxe (accelerated). The former can be used anywhere, the latter only in places where the caches are guaranteed to be on, not only due to the unaligned accesses but also due to the fact that it uses DC ZVA

[edk2] [PATCH v3 3/3] MdePkg/BaseMemoryLibOptDxe: add accelerated AARCH64 routines

This adds AARCH64 support to BaseMemoryLibOptDxe, based on the cortex-strings library. All string routines are accelerated except ScanMem16, ScanMem32, ScanMem64 and IsZeroBuffer, which can wait for another day. (Very few occurrences exist in the codebase) Contributed-under: TianoCore