Re: [edk2] [RFC PATCH 0/8] small C model and LLVM/clang support for AARCH64

Ard, The bottom line is that we are still losing around 40 KB on padding in total, If I understand correctly you're saying because of limitations in the AArch64 LLVM/clang toolchain we must suffer some sort of code size increase (of which you made great progress in minimizing) because of its

Re: [edk2] Authentication status for signed FVs extracted in PEI

ionStatus field. Eugene -Original Message- From: Zeng, Star [mailto:star.z...@intel.com] Sent: Monday, November 09, 2015 6:43 AM To: Cohen, Eugene <eug...@hp.com>; edk2-devel@lists.01.org Cc: Zeng, Star <star.z...@intel.com> Subject: RE: Authentication status for signed FVs extracted

Re: [edk2] Authentication status for signed FVs extracted in PEI

I raised this as an issue with PIWG. In the meantime feel free to provide some historical context for why this hasn't been an issue in other implementations. Thanks, Eugene -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, Eugene Sent

Re: [edk2] [PATCH] MdeModulePkg: PeiCore: fix issue where AuthenticationStatus is not propagated correctly to encapsulated FVs by ensuring that the FvInfo2 PPI is installed before the FvInfo PPI

From: Zeng, Star [mailto:star.z...@intel.com] Sent: Monday, November 09, 2015 6:47 AM To: Cohen, Eugene <eug...@hp.com>; Tian, Feng <feng.t...@intel.com>; edk2-devel@lists.01.org Cc: Thompson, Mark L. <mark.l.thomp...@hp.com>; Dellaquila, Katie <katie.dellaqu...@hp.com

Re: [edk2] Authentication status for signed FVs extracted in PEI

ther FV HOB includes authentication status. Thanks Liming > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zeng, > Star > Sent: Tuesday, November 10, 2015 6:19 PM > To: Cohen, Eugene; edk2-devel@lists.01.org > Subject: Re: [edk2] Au

Re: [edk2] Authentication status for signed FVs extracted in PEI

ssage- From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] Sent: Tuesday, November 10, 2015 7:06 PM To: Cohen, Eugene <eug...@hp.com>; Gao, Liming <liming@intel.com>; Zeng, Star <star.z...@intel.com>; edk2-devel@lists.01.org; Kinney, Michael D <michael.d.kin.

Re: [edk2] [PATCH] MdeModulePkg PeiCore: PEI dispatcher need retry to process NOT_DISPATCHED FV

Good catch. Reviewed-by: Eugene Cohen -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng Sent: Wednesday, November 11, 2015 3:07 AM To: edk2-devel@lists.01.org Cc: Liming Gao Subject: [edk2] [PATCH]

Re: [edk2] Authentication status for signed FVs extracted in PEI

I'm guessing that people are choosing different approaches for packaging up PEI and DXE phase components than we are. Thanks, Eugene -Original Message- From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] Sent: Tuesday, November 10, 2015 12:54 PM To: Cohen, Eugene <eug...@hp.com>; G

Re: [edk2] [PATCH] MdeModulePkg: PeiCore: fix issue where AuthenticationStatus is not propagated correctly to encapsulated FVs by ensuring that the FvInfo2 PPI is installed before the FvInfo PPI

Star, Feel free to shorten the title as necessary and commit. Thanks for reviewing this. Eugene -Original Message- From: Zeng, Star [mailto:star.z...@intel.com] Sent: Monday, November 09, 2015 10:14 PM To: Cohen, Eugene <eug...@hp.com>; Tian, Feng <feng.t...@intel.com>;

Re: [edk2] SecurityPkg: PeiRsa2048Sha256GuidedSectionExtractLib error handling

ree? Thanks, Eugene -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zhang, Chao B Sent: Sunday, November 01, 2015 6:51 PM To: Cohen, Eugene <eug...@hp.com> Cc: edk2-devel@lists.01.org Subject: Re: [edk2] SecurityPkg: PeiRsa2048Sha256Guide

[edk2] SecurityPkg: PeiRsa2048Sha256GuidedSectionExtractLib error handling

Dear SecurityPkg maintainer, I'm trying to track down the best way for platform policy to handle an authentication failure in the PEI Rsa2048Sha256 guided section extraction library and ran across this curious state near the end of Rsa2048Sha256GuidedSectionHandler. // // Temp solution

Re: [edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole D-cache maintenance operations

sage- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Tuesday, November 03, 2015 7:30 AM To: Cohen, Eugene <eug...@hp.com> Cc: edk2-devel@lists.01.org; leif.lindh...@linaro.org; mark.rutl...@arm.com; ler...@redhat.com Subject: Re: [edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole

Re: [edk2] Authentication status for signed FVs extracted in PEI

-devel-boun...@lists.01.org] On Behalf Of Cohen, Eugene Sent: Friday, November 06, 2015 11:12 AM To: edk2-devel@lists.01.org Cc: Thompson, Mark L. (Boise IPG) <mark.l.thomp...@hp.com> Subject: [edk2] Authentication status for signed FVs extracted in PEI I'm confused about something and hop

[edk2] [PATCH] MdeModulePkg: PeiCore: fix issue where AuthenticationStatus is not propagated correctly to encapsulated FVs by ensuring that the FvInfo2 PPI is installed before the FvInfo PPI

Dear MdeModulePkg maintainer, MdeModulePkg: PeiCore: fix issue where AuthenticationStatus is not propagated correctly to encapsulated FVs by ensuring that the FvInfo2 PPI is installed before the FvInfo PPI This patch fixes an issue in PEI with encapsulated FV images where the

Re: [edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole D-cache maintenance operations

, November 04, 2015 1:03 AM To: Cohen, Eugene <eug...@hp.com> Cc: edk2-devel@lists.01.org; leif.lindh...@linaro.org; mark.rutl...@arm.com; ler...@redhat.com Subject: Re: [edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole D-cache maintenance operations On 3 November 2015 at 23:19, Co

Re: [edk2] Strange behavior of the DS-5 debugger on AARCH64 with step-by-step debugging in uefi

Vladimir, Since the UEFI images are PE-COFF but DS-5 builds ELF there is a conversion process in the edk2 build. This can result in a couple of issues with debug if not handled correctly: 1. The start of the image for debugger load purposes must be adjusted to reflect the PE/TE header in the

[edk2] Authentication status for signed FVs extracted in PEI

I'm confused about something and hope I can help some help understanding this. If we have a signed FV that is extracted in PEI it doesn't look like the AuthenticationStatus gets propagated to DXE. The hob doesn't store authentication status and the core products FVB with AuthenticationStatus

Re: [edk2] [PATCH 08/10] ArmCacheMaintenanceLib: disallow whole D-cache maintenance operations

Please don't remove this functionality. At times we do want to use this library to turn off the cache in preparation for going to another environment (say, loading an OS) and this is useful. Eugene -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf

[edk2] [PATCH] SecurityPkg: fix Rsa2048Sha256GuidedSectionExtractLib issue causing section overruns and possible hangs due to bad output size calculation (updated)

ON_SIZE(InputSection) - sizeof (RSA_2048_SHA_256_SECTION_HEADER); } return EFI_SUCCESS; -- -Original Message- From: Zhang, Chao B [mailto:chao.b.zh...@intel.com] Sent: Wednesday, October 14, 2015 9:32 PM To: Cohen, Eugene <eug...@hp.com> Cc: edk2-devel@lists.01.org S

[edk2] Is the edk2 FV INF format documented?

Is the FV inf format documented? It looks like we have crisp specifications for the other files (module inf, dsc, dec, fdf, etc) but I didn't see anything about the FV .INF files. I realize the intent may be that this is a private definition between build.py and GenFv but we have some

Re: [edk2] [PATCH 0/4] CryptoPkg: fix ARM and RVCT issues

Ard, > As far as patch #4 is concerned, let's wait for confirmation from Eugene, also > regarding the issue of reporting defect against RVCT (if there is a point in > doing so) You're referring to "[PATCH 4/4] CryptoPkg/OpensslLib: ignore more false positive warnings for RVCT" and the idea of

Re: [edk2] HII ConfigRouting Assert - Why?

just this. Thanks! Eugene > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > Of Dong, Eric > Sent: Monday, December 07, 2015 6:31 AM > To: Cohen, Eugene <eug...@hp.com>; edk2-devel@lists.01.org > Subject: Re: [edk2] HII Co

Re: [edk2] [PATCH 0/4] CryptoPkg: fix ARM and RVCT issues

lists.01.org] On Behalf > Of Cohen, Eugene > Sent: Monday, December 07, 2015 6:32 AM > To: Ard Biesheuvel <ard.biesheu...@linaro.org>; Long, Qin > <qin.l...@intel.com> > Cc: edk2-devel@lists.01.org; dw...@infradead.org > Subject: Re: [edk2] [PATCH 0/4] CryptoPkg: fix A

Re: [edk2] [PATCH] ArmPkg: update InvalidateInstructionCacheRange to flush only to PoU

Reviewed-by: Eugene Cohen <eug...@hp.com> > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Monday, December 07, 2015 12:06 AM > To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; Cohen, Eugene > <eug...@hp.com> > C

Re: [edk2] [PATCH] ArmPkg/ArmLib: mark all cached mappings as (inner) shareable

I'd like to dig up this thread because I suspect there's something that is fundamentally misunderstood. On at least one older non-MP processor (Cortex-A8) this change just forces all accesses to be uncached - this is true for L1 I+D and L2. There's nothing strange about the L2 subsystem or

[edk2] [PATCH v2] MdeModulePkg: allow DxeIpl to load without permanent memory

[This patch is updated from v1 to defer publication of the decompression and extraction PPIs until after permanent memory is installed. Tested for normal boots and our temporary memory S3 resume path.] This enable S3 resume from temporary memory. The normal boot path still enforces the

Re: [edk2] [PATCH] ArmPkg/ArmV7Mmu: prefer non shareable memory on non-coherent hardware

sage- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Tuesday, December 08, 2015 7:03 AM > To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; Cohen, Eugene > <eug...@hp.com> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> > Subject: [PATCH

Re: [edk2] [PATCH 3/3] ArmPkg: update RVCT assembly functions to use new RVCT_ASM_EXPORT macro

heuvel [mailto:ard.biesheu...@linaro.org] > Sent: Wednesday, December 02, 2015 9:42 AM > To: Cohen, Eugene <eug...@hp.com> > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH 3/3] ArmPkg: update RVCT assembly functions to > use new RVCT_ASM_EXPORT macro > > On 25 Nove

Re: [edk2] [PATCH] ArmPkg: Convert whole-cache InvalidateInstructionCache to just ASSERT

can do for the line wrapping. Thanks, Eugene > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Tuesday, December 01, 2015 11:42 AM > To: Cohen, Eugene <eug...@hp.com> > Cc: leif.lindh...@linaro.org; edk2-devel@lists.01.org > Sub

[edk2] HII ConfigRouting Assert - Why?

In the HiiDatabaseDxe driver there's an ASSERT that seems oddly placed to me: if (IsEfiVarStore) { // // Call the GetVariable function to extract settings. // Status = GetConfigRespFromEfiVarStore(This, EfiVarStoreInfo, ConfigRequest, , ); FreePool

Re: [edk2] [PATCH] MdeModulePkg: allow DxeIpl to load without permanent memory to enable S3 resume from temporary memory

nt: Thursday, December 03, 2015 4:22 PM > To: Cohen, Eugene <eug...@hp.com>; Laszlo Ersek > <ler...@redhat.com>; Zeng, Star <star.z...@intel.com>; edk2- > de...@lists.01.org <edk2-de...@ml01.01.org>; Liming Gao > <liming@intel.com> > Subject: Re

[edk2] [PATCH] MdeModulePkg: Convert HiiDatabaseDxe ConfigRouting ASSERT to return an error

This should just return an error and not assert. We hit this when testing with a client that was trying to access the old IP4_CONFIG on firmware implementing IP4_CONFIG2. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eugene Cohen ---

Re: [edk2] [PATCH] MdeModulePkg: allow DxeIpl to load without permanent memory to enable S3 resume from temporary memory

> I'll admit that I don't fully understand the details and the expected > implications of this change, but: OVMF does install permanent PEI RAM on > the S3 resume path, and it would be nice if that wouldn't break. > > ... If this is a very intrusive change, can it be made dependent on a >

[edk2] [PATCH v2] ArmPkg: update RVCT assembly functions to use new RVCT_ASM_EXPORT macro

This has the effect of splitting assembly functions into their own sections so the linker can remove unused ones to save space. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eugene Cohen --- .../ArmCpuLib/ArmCortexA9Lib/ArmCortexA9Helper.asm | 5 +-

Re: [edk2] [PATCH 3/3] ArmPkg: update RVCT assembly functions to use new RVCT_ASM_EXPORT macro

-Original Message- > From: Cohen, Eugene > Sent: Wednesday, December 02, 2015 12:04 PM > To: Ard Biesheuvel <ard.biesheu...@linaro.org> > Cc: edk2-devel@lists.01.org > Subject: RE: [edk2] [PATCH 3/3] ArmPkg: update RVCT assembly > functions to use new RVCT_ASM_E

Re: [edk2] [PATCH] MdeModulePkg: allow DxeIpl to load without permanent memory to enable S3 resume from temporary memory

Tim, > Personally, I don't see this as a positive change. The PEI flow from the > earliest days has said: at the end of PEI there is memory and there is a > boot mode (see 11.2.1). You can see this assumption in 2.5 and 9.1 of > the PI specification, where the result of the PEI Foundation (not

[edk2] [PATCH] ArmPkg: Convert whole-cache InvalidateInstructionCache to just ASSERT

In SVN 18756 ("disallow whole D-cache maintenance operations") InvalidateInstructionCache was modified to remove the full data cache clean but left the full instruction cache invalidate. The change was made to address issues in the set/way clean methodology but the resulting code could lead

Re: [edk2] [PATCH v2 1/3] BaseTools RVCT: use scatter file to implement minimum section alignment

th this change since it's a nasty surprise when you update and realize your debug tools are broken. Reviewed-by: Eugene Cohen <eug...@hp.com> Eugene > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Tuesday, December 01, 2015 10:38 AM

[edk2] Nested FD files in one FDF

We have a need to have one FD image embedded in another (two copies of an identical FD image). So in our platform FDF file we'd like to define one FD for the "outer" region and another FD for the "inner" region. We then would like to specify in the outer FD a file that is the inner FD.

[edk2] [PATCH] ArmPkg: add typecast in UncachedMemoryAllocationLib to fix build warning

Small warning fix. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eugene Cohen --- .../Library/UncachedMemoryAllocationLib/UncachedMemoryAllocationLib.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[edk2] [PATCH 2/3] ArmPkg: create RVCT assembler macro to centralize EXPORT, AREA, and function label definition

In response to Leifs request earlier, this adds a new RVCT assembler macro to centralize the exporting of assembly functions including the EXPORT directive (so the linker can see it), the AREA directive (so it's in its own section for code size reasons) and the function label itself. This

[edk2] [PATCH 3/3] ArmPkg: update RVCT assembly functions to use new RVCT_ASM_EXPORT macro

This has the effect of splitting assembly functions into their own sections so the linker can remove unused ones to save space. This has been tested to build with ArmPkg.dsc with RVCT 4. The majority of the conversion was performed with the attached python script. Contributed-under: TianoCore

[edk2] [PATCH] ArmPkg: Initialize variable in UncachedMemoryAllocationLib's AllocatePagesFromList to fix build warning

Addressing Ard and Laszlo's feedback. Updated subject. Moved initialization to separate line. Removed the typecast which was a carryover from a more strict convention we use in our private code. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eugene Cohen

Re: [edk2] [PATCH 3/3] ArmPkg: update RVCT assembly functions to use new RVCT_ASM_EXPORT macro

pass return if __name__ == "__main__": #print "call with args: %s" % sys.argv[1] #files = glob.glob(sys.argv[1]) #print "files is %s" % files #ProcessFiles(files) ProcessFiles(sys.argv[1:]) -Original Message- From: edk2-devel

Re: [edk2] Ip4Config to Ip4Config2 Transition

he old NVRAM in the case where the new version isn't found? Thanks, Eugene -Original Message- From: Wu, Jiaxin [mailto:jiaxin...@intel.com] Sent: Thursday, November 19, 2015 11:00 PM To: Ye, Ting <ting...@intel.com>; Cohen, Eugene <eug...@hp.com>; edk2-devel@lists.01.or

[edk2] [PATCH] ArmPkg: add missing MigratePeiServicesTablePointer function required by update to the PeiServicesTablePointerLib in svn 15115

As of SVN 15115 the PEI core needs a MigratePeiServicesTablePointer function. Background: The ArmPkg variant of the PeiServicesTablePointerLib implements the standard PEI Services table retrieval mechanism as defined in the PI Specification Volume 1 section 5.4.4 using the PIDRURW registers.

[edk2] ArmPlatformPkg: Non-compliant PeiServicesTablePointerLib implementation

In ArmPlatformPkg there is an implementation of the PeiServicesTablePointer library that uses the "global variable" creation. (I don't know what the purpose is of these "global variables" but they seem to be incompatible with the philosophy of PI/edk2 which is all about decentralizing stuff -

[edk2] [PATCH] CryptoPkg: Fix ARM RVCT 4 build

n < eug...@hp.com> Eugene -----Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Tuesday, November 24, 2015 9:56 AM To: Cohen, Eugene <eug...@hp.com>; Leif Lindholm <leif.lindh...@arm.com>; Leif Lindholm <leif.lindh...@linaro.org> Cc: D

[edk2] [PATCH] ShellPkg: fix RVCT warning due to CONST in typecast

Building the latest shell on RVCT exposed this warning: ShellPkg\Application\Shell\Shell.c(1090,69): error #191-D: type qualifier is meaningless on cast type The CONST in the cast was deemed meaningless. Removing the CONST fixed the warning. --- edk2/ShellPkg/Application/Shell/Shell.c | 2

Re: [edk2] [PATCH 1/3] ArmPkg: factor out softfloat support from StdLib/LibC/SoftFloat

[mailto:ard.biesheu...@linaro.org] Sent: Friday, November 27, 2015 1:52 AM To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; ler...@redhat.com; Cohen, Eugene <eug...@hp.com>; qin.l...@intel.com Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> Subject: [PATCH 1/3] ArmPkg: factor out softfloat

Re: [edk2] [PATCH v2 2/4] ArmPkg/ArmSoftFloatLib: add support for RVCT

.lindh...@linaro.org] Sent: Saturday, November 28, 2015 3:17 AM To: Ard Biesheuvel <ard.biesheu...@linaro.org> Cc: edk2-devel@lists.01.org; Laszlo Ersek <ler...@redhat.com>; Cohen, Eugene <eug...@hp.com>; qlong <qin.l...@intel.com> Subject: Re: [PATCH v2 2/4] ArmPkg/ArmSoft

[edk2] [PATCH] ArmPkg: update InvalidateInstructionCacheRange to flush only to point of unification (PoU)

This patch updates the ArmPkg variant of InvalidateInstructionCacheRange to flush the data cache only to the point of unification (PoU). This improves performance and also allows invalidation in scenarios where it would be inappropriate to flush to the point of coherency (like when executing

[edk2] CryptoPkg: OpenSSL build issue with RVCT

Using RVCT 4, I get the following error building openssl-1.0.2d: 1> Building ... c:\bios_24s\edk2\CryptoPkg\Library\OpensslLib\OpensslLib.inf [ARM] [snip] c:\bios_24s\edk2\CryptoPkg\Library\OpensslLib\openssl-1.0.2d\crypto\cryptlib.c

Re: [edk2] CryptoPkg: OpenSSL build issue with RVCT

ctx->current_cert = x; -- Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eugene Cohen < eug...@hp.com> Thanks, Eugene -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Long, Qin Sent: Monday, November 23, 2

[edk2] [PATCH] ShellPkg: Wrong return status for Ifconfig.c

The Ifconfig command handler tries to return an EFI_STATUS when the return type should be SHELL_STATUS. RVCT 4 is (correctly) flagging this as an error: edk2\ShellPkg\Library\UefiShellNetwork1CommandsLib\Ifconfig.c(1387,10): error #188-D: enumerated type mixed with another type I haven't

Re: [edk2] CryptoPkg: OpenSSL build issue with RVCT

already have these responsibilities identified? Eugene -Original Message- From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] Sent: Tuesday, November 24, 2015 8:49 AM To: David Woodhouse <dw...@infradead.org> Cc: Cohen, Eugene <eug...@hp.com>; Long, Qin <qin.l...@intel.co

Re: [edk2] ArmPkg: Dead code stripping

Contribution Agreement 1.0 Signed-off-by: Eugene Cohen eug...@hp.com<mailto:eug...@hp.com> -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, Eugene Sent: Thursday, November 19, 2015 5:53 AM To: edk2-devel@lists.01.org Subject: [edk2] ArmPkg

[edk2] Ip4Config to Ip4Config2 Transition

Jiaxin Wu, I'm updating edk2 to a new version that includes the removal of legacy Ip4Config and addition of the new Ip4Config2 protocol. I'm wondering what this does to network settings already stored in NVRAM? Does the data get lost or will the new driver preserve the existing settings?

Re: [edk2] TCP4: Failure to Acknowledge due to DPC Dispatch Nesting (+PATCH)

> We have been testing a change where nesting of DPCs is prevented - > in DispatchDPC we check if we are already processing a dispatch and > exit if we are. (We also modified the dispatch loop to keep looping > until the DPC queues are emptied.) With this approach we still meet > the same-TPL

[edk2] [PATCH] BaseTools: make build report tolerant of FVs specified by name

:edk2-devel-boun...@lists.01.org] On Behalf > Of Cohen, Eugene > Sent: Wednesday, January 13, 2016 7:40 AM > To: edk2-devel@lists.01.org; yonghong@intel.com; Gao, Liming > (liming@intel.com) <liming@intel.com> > Subject: [edk2] BaseTools: BuildReport.py crashes for FV_IM

[edk2] BaseTools: BuildReport.py crashes for FV_IMAGE provided by file

Dear Basetools maintainer, We have an FDF file where we're creating an encapsulated FV where the FV contents come from the filesystem instead of from a named FDF section. The FD processing works fine in this case but the build report generator tool crashes. Here's an example of how we

Re: [edk2] Connecting all devices at boot

> If I duplicate the call to BdsLibConnectAll() [2], then boot works as > expected. On first boot, the boot order is created correctly and EFI > Network pulls down a file and boots it. I have seen components that have asynchronous initialization characteristics, meaning that they returns from

[edk2] PeiCore Image.c: PcdShadowPeimOnBoot affects DXE Core IPL

In the PEI Core's image loading area, there is some logic that decides whether an image should be loaded into allocated memory or left in place: // Allocate Memory for the image when memory is ready, and image is relocatable. // On normal boot, PcdShadowPeimOnBoot decides whether load PEIM

Re: [edk2] Variable length PcdRsa2048Sha256PublicKeyBuffer PCD

6 9:59 AM > To: Cohen, Eugene <eug...@hp.com>; edk2-devel@lists.01.org; Kinney, > Michael D <michael.d.kin...@intel.com> > Cc: Zhang, Chao B <chao.b.zh...@intel.com> > Subject: RE: Variable length PcdRsa2048Sha256PublicKeyBuffer PCD > > Eugene, > > I can

Re: [edk2] MdePkg/SmmMemLib: Insufficient abstraction for CPU physical address size

tracker? Thanks, Eugene > -Original Message- > From: Kinney, Michael D [mailto:michael.d.kin...@intel.com] > Sent: Wednesday, February 03, 2016 11:54 AM > To: Cohen, Eugene <eug...@hp.com>; edk2-devel@lists.01.org; Fan, > Jeff <jeff@intel.com>; Kinney,

[edk2] Variable length PcdRsa2048Sha256PublicKeyBuffer PCD

Dear SecurityPkg maintainer, The SecurityPkg Rsa2048Sha256 system depends on a dynamic PCD called gEfiSecurityPkgTokenSpaceGuid.PcdRsa2048Sha256PublicKeyBuffer . This stores a set of hashes used to verify public keys. It appears that the length of this PCD is determined at build time. How we

[edk2] MdePkg/SmmMemLib: Insufficient abstraction for CPU physical address size

In SmmMemLib there's a routine to determine the maximum physical address supported by a processor: // // Get physical address bits supported. // Hob = GetFirstHob (EFI_HOB_TYPE_CPU); if (Hob != NULL) { PhysicalAddressBits = ((EFI_HOB_CPU *) Hob)->SizeOfMemorySpace; } else {

Re: [edk2] [PATCH] ArmPkg: AArch64 exception handling init configures HCR in EL2

> > + if (ArmReadCurrentEL() == AARCH64_EL2) { > > +HcrReg = ArmReadHcr(); > > + > > +// set AMO, IMO, and FMO so all available async exceptions go to EL2 > > +// (EL3 takes precedence over this and may choose to own FIQ > regardless) > > +HcrReg |= (ARM_HCR_FMO | ARM_HCR_IMO |

[edk2] [PATCH] MdePkg: Fix AArch64 DAIF interrupt mask definitions

The AArch64 DAIF bits are different for reading (mrs) versus writing (msr). The bitmask definitions assumed they were the same causing incorrect results when trying to determine the current interrupt state through GetInterruptState. The logic for interpreting the DAIF read data using the csel

[edk2] [PATCH] ArmPkg: Fix AArch64 interrupt read masks

The AArch64 DAIF bits are different for reading (mrs) versus writing (msr). The bitmask definitions assumed they were the same causing incorrect results when trying to determine the current interrupt state through ArmGetInterruptState. The logic for interpreting the DAIF read data using the csel

Re: [edk2] [PATCH] MdePkg: Fix AArch64 DAIF interrupt mask definitions

> > -csel w0, w1, w0, ne > > +csel w0, w1, w0, eq // if Z=1 (eq) return 1, else 0 > > Again, could we replace these three instructions with 'cinc w0, wzr, eq' while > we're at it? No objections here - I'm new to these conditional selection instructions. My preference is for

[edk2] [PATCH] ArmPkg: AArch64 exception handling init configures HCR in EL2

In AArch64 if UEFI is executing at EL2 the IMO/FMO/AMO bits must be set to enable asynchronous exception (interrupt) delivery to EL2. Since these bits are under control of EL2 firmware (UEFI/DXE) we set them when exception handling is being initialized. Contributed-under: TianoCore Contribution

[edk2] [PATCH] BaseTools: Update ARM/AArch64 GenFv vector processing for encapsulated FVs

Instead of only handling SEC Core or PEI Core instances in the outer FV, the GenFv tool will now recurse into FV image FFS files to look for instances in encapsulated FVs so the vector area can be updated appropriately. Tested on ARM and AArch64 platforms. Contributed-under: TianoCore

Re: [edk2] [Patch] MdeModulePkg: Update PeiCore dispatcher to handle PEIM and PEI_CORE only

> When PcdShadowPeimOnBoot is FALSE, they are not copied to > memory and > execute from their original locations. Here, this policy should only > apply for PEIM and PEI_CORE, not for other file type, such as > DXE_CORE. Tested-by: Eugene Cohen Sorry for the delay in testing this

[edk2] [PATCH] ArmPkg: DefaultExceptionHandler fixes for use with DxeCore

Modify the DefaultExceptionHandler (uefi-variant) so it can be used by DxeCore (via CpuExceptionHandlerLib) where the debug info table is not yet published at library constructor time. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eugene Cohen ---

Re: [edk2] "echo" objcopy not needed doesn't actually work

Andrew, > Each line of the recipe in the makefile should invoke a unique instance > of the shell. Thus it seems you are invoking the wrong shell so take a > look at: > https://www.gnu.org/software/make/manual/html_node/Choosing- > the-Shell.html In this case we're basically trying to execute a

[edk2] [PATCH v2] BaseTools: Update ARM/AArch64 GenFv vector processing for encapsulated FVs

(Second revision of patch which adds two missing #defines for ARM instructions) Instead of only handling SEC Core or PEI Core instances in the outer FV, the GenFv tool will now recurse into FV image FFS files to look for instances in encapsulated FVs so the vector area can be updated

Re: [edk2] [PATCH] BaseTools: Update ARM/AArch64 GenFv vector processing for encapsulated FVs

> Is it necessary to add check in GetChildFvFromFfs()? I see FfsRebase() > has set mArm value. Liming, In my experiments the answer is 'yes' because when GenFv is called for the outer FV this is the only mechanism where we can find the embedded SEC or PEI cores. Perhaps you can help me

Re: [edk2] [PATCH 1/2] BeagleBoardPkg: move to ARM version of CpuExceptionHandlerLib

Series Reviewed-by: Eugene Cohen > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf > Of Ard Biesheuvel > Sent: Wednesday, March 16, 2016 8:08 AM > To: edk2-devel@lists.01.org; leif.lindh...@linaro.org > Cc: Ard Biesheuvel

[edk2] Shell Path Issues with "../.."

Dear ShellPkg maintainer, We're seeing some weird stuff related to '..' in the shell. The issue is that when we try to cd up two levels using the "../.." notation we only go up one level: FS0:\dir1\dir2\dir3\> FS0:\dir1\dir2\dir3\> cd ..\.. FS0:\dir1\dir2\> The same issue occurs using

Re: [edk2] Error while loading a symbol file (No Debug Directory)

> This is very odd. The commit in question introduces two new > implementations of CpuExceptionHandlerLib, but does not yet use them > anywhere. The next patch updates CpuDxe to start using the default > (non-copying) one. What are your resolutions for CpuExceptionHandlerLib in > your .DSC, and do

Re: [edk2] [PATCH 1/7] ArmPkg/AsmMacroIoLibV8: remove undocumented assumption from ELx macros

Alexei and Ard, > The suggested code for EL1_OR_EL2 macro: > > mrsSAFE_XREG, CurrentEL ;\ > cmpSAFE_XREG, #0x8 ;\ > b.eq 2f ;\ > tbnz SAFE_XREG, #2, 1f;\ > b .;// We should never get here > > will successfully branch to 1f label in

Re: [edk2] [PATCH 2/7] ArmPkg/ArmExceptionLib: fold exception handler prologue into vector table

> So refactor this code into a single macro, and expand it into each vector > table > slot. > + .macro ExceptionEntry, val > + // Move the stackpointer so we can reach our structure with the str > instruction. > + sub sp, sp, #(FP_CONTEXT_SIZE + SYS_CONTEXT_SIZE) > + > + // Save all the

Re: [edk2] [PATCH 5/7] ArmPkg/ArmExceptionLib: make build time define visible to the compiler

alf Of > Ard Biesheuvel > Sent: Thursday, March 17, 2016 7:20 AM > To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; Cohen, Eugene > <eug...@hp.com> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> > Subject: [edk2] [PATCH 5/7] ArmPkg/ArmExceptionLib: make b

Re: [edk2] [PATCH 1/7] ArmPkg/AsmMacroIoLibV8: remove undocumented assumption from ELx macros

-Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Thursday, March 17, 2016 7:20 AM > To: edk2-devel@lists.01.org; leif.lindh...@linaro.org; Cohen, Eugene > <eug...@hp.com> > Cc: Ard Biesheuvel <ard.biesheu...@linaro.org> > Subject: [PA

Re: [edk2] [PATCH v2 3/3] ArmPkg: Update CpuDxe to use CpuExceptionHandlerLib

Ard, > The patches look fine to me. I will proceed and apply the first two. > However, this third one needs to wait until all users of CpuDxe have > the correct resolution for CpuExceptionHandlerLib. I think this is > only ArmVirtPkg/ArmVirt.dsc.inc, but I'd like a nod from Leif before > pushing

[edk2] [PATCH 3/3] ArmPkg: Update CpuDxe to use CpuExceptionHandlerLib

Use the new ARM/AArch64 implementation of the base CpuExceptionHandlerLib library from CpuDxe to centralize exception handling. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eugene Cohen --- ArmPkg/Drivers/CpuDxe/AArch64/Exception.c| 154 -

[edk2] [PATCH 1/3] ArmPkg: Add ArmReadHcr to enable read-modify-write of HCR

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eugene Cohen --- ArmPkg/Include/Chipset/AArch64.h | 5 + ArmPkg/Library/ArmLib/AArch64/AArch64Support.S | 6 ++ 2 files changed, 11 insertions(+) diff --git

Re: [edk2] [PATCH 2/3] ArmPkg: ARM/AArch64 implementation of CpuExceptionHandlerLib

Ard, > > + // > > + // Patch in the common Assembly exception handler > > + // > > + Offset = (UINTN)CommonExceptionEntry - > (UINTN)ExceptionHandlersStart; > > + *(UINTN *)((UINT8 *)(UINTN)(BaseAddress + Offset)) = > (UINTN)AsmCommonExceptionEntry; > > + > > Why is this needed?

[edk2] [PATCH v2 1/3] ArmPkg: Add ArmReadHcr to enable read-modify-write of HCR

Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eugene Cohen --- ArmPkg/Include/Chipset/AArch64.h | 5 + ArmPkg/Library/ArmLib/AArch64/AArch64Support.S | 6 ++ 2 files changed, 11 insertions(+) diff --git

[edk2] [PATCH v2 2/3] ArmPkg: ARM/AArch64 implementation of CpuExceptionHandlerLib

Introduce ARM and AArch64 instances of the CpuExceptionHandlerLib which provides exception handling and registration of handlers regardless of execution phase. Two variants of the ArmExceptionLib are provided: one where exception handlers reside within the module (meeting appropriate

[edk2] [PATCH v2 3/3] ArmPkg: Update CpuDxe to use CpuExceptionHandlerLib

Use the new ARM/AArch64 implementation of the base CpuExceptionHandlerLib library from CpuDxe to centralize exception handling. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Eugene Cohen --- ArmPkg/Drivers/CpuDxe/AArch64/Exception.c| 154 -

Re: [edk2] [PATCH 0/3] Implement ARM/AArch64 instance of CpuExceptionHandlerLib

remain unchanged. Eugene > -Original Message- > From: Cohen, Eugene > Sent: Thursday, March 03, 2016 4:05 PM > To: edk2-devel@lists.01.org; 'Ard Biesheuvel' > <ard.biesheu...@linaro.org>; Leif Lindholm <leif.lindh...@linaro.org> > Subject: [PATCH 0/3]

Re: [edk2] [PATCH] BaseTools: Update ARM/AArch64 GenFv vector processing for encapsulated FVs

> Ard Biesheuvel > Sent: Monday, February 29, 2016 10:10 AM > To: Cohen, Eugene <eug...@hp.com> > Cc: edk2-devel@lists.01.org > Subject: Re: [edk2] [PATCH] BaseTools: Update ARM/AArch64 GenFv vector > processing for encapsulated FVs > > On 17 February 2016 at 14:39, Co

Re: [edk2] [PATCH v2] BaseTools: Update ARM/AArch64 GenFv vector processing for encapsulated FVs

orceRebase to true? Thanks, Eugene > -Original Message- > From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] > Sent: Wednesday, March 02, 2016 1:12 AM > To: Cohen, Eugene <eug...@hp.com> > Cc: edk2-devel@lists.01.org; Gao, Liming (liming@intel.com) > <l

Re: [edk2] [PATCH v2] BaseTools: Update ARM/AArch64 GenFv vector processing for encapsulated FVs

> I suppose the output of the final GenFv is what matters, right? I expected to see stuff like "UpdateArmResetVectorIfNeeded updating AArch64 SEC vector" - obviously that's not being emitted. Just to double-check, you did rebuild BaseTools, right? > FvForceRebase does improve the situation

Re: [edk2] "echo" objcopy not needed doesn't actually work

Liming, > The GCC binary > tools is got from > https://sourceforge.net/projects/edk2developertoolsforwindows/file > s/Tool%20Chain%20Binaries/. If you only use gcc ARM, you can set > GCC49_DLL=%UEFI_BUILD_TOOLS%\gcc492- > arm\bin\;%UEFI_BUILD_TOOLS%\gcc492-arm\dll\ This is my issue. I obtained

Re: [edk2] "echo" objcopy not needed doesn't actually work

> Maybe I'm confused. Are you using nmake or GNU make? I though you were > using GNU make and could fix it with the MAKESHELL variable. Andrew, this is GNU make on Windows. I think you are suggesting that some other shell other than the stock cmd.exe would handle this quoted echo command

Re: [edk2] TCP4: Failure to Acknowledge due to DPC Dispatch Nesting

Adding some maintainers... We are looking forward to a response. Thanks, Eugene > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Cohen, Eugene > Sent: Friday, May 20, 2016 2:11 PM > To: edk2-devel@lists.01.org > Cc: Vaugh

Re: [edk2] TCP4: Failure to Acknowledge due to DPC Dispatch Nesting

@intel.com] Sent: Monday, May 23, 2016 8:45 PM To: Ye, Ting <ting...@intel.com>; Cohen, Eugene <eug...@hp.com>; edk2-devel@lists.01.org; Wu, Jiaxin <jiaxin...@intel.com>; Zhang, Lubo <lubo.zh...@intel.com> Cc: Vaughn, Gregory (IPG LJ Printer Lab) <greg.vau...@hp.com> S

  1   2   >