Re: [edk2] Creating my own flashing app

On a secure platform you likely need to update using a secure capsule. https://github.com/tianocore/tianocore.github.io/wiki/Capsule-Based-Firmware-Update-and-Firmware-Recovery The capsule is the standard method, and then all the FLASH update code is part of the ROM. Generally since an EFI

Re: [edk2] Creating my own flashing app

Ok, so what is going wrong?  Have you looked at any of the flash tools in other open source projects? Kevin On Mon, Dec 3, 2018 at 10:45 PM -0600, "Guy Raviv" wrote: a whole SPI BIOS image. if i was not clear please tell me

Re: [edk2] Creating my own flashing app

a whole SPI BIOS image. if i was not clear please tell me what i'm missing. Thanks! Guy Virus-free. www.avg.com

Re: [edk2] Creating my own flashing app

Guy, What are you trying to FLASH? Thanks, Andrew Fish > On Dec 3, 2018, at 7:28 PM, Guy Raviv wrote: > > Hi, > > I want to create my own flashing utility. > Is there any EDKII App/Utilities that can help me? > > Thanks, > Guy > >

[edk2] EmbeddedPkg : Corrected flow for setting Buswidth for eMMC

Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Meenakshi Aggarwal --- EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/EmbeddedPkg/Universal/MmcDxe/MmcIdentification.c

[edk2] Creating my own flashing app

Hi, I want to create my own flashing utility. Is there any EDKII App/Utilities that can help me? Thanks, Guy Virus-free. www.avg.com

Re: [edk2] [PATCH edk2-platforms 14/27] Silicon/NXP: Add i.MX6 GPT and EPIT timer headers

Hi Leif, > -Original Message- > From: Leif Lindholm > Sent: Thursday, November 8, 2018 10:14 AM > To: Chris Co > Cc: edk2-devel@lists.01.org; Ard Biesheuvel ; > Michael D Kinney > Subject: Re: [PATCH edk2-platforms 14/27] Silicon/NXP: Add i.MX6 GPT and > EPIT timer headers > > On Fri,

Re: [edk2] [Patch v1 1/1] BaseTools: create and use a standard shared variable for '*'

Yes. I prefer not to change it. Best Regards, Zhu Yonghong -Original Message- From: Carsey, Jaben Sent: Monday, December 03, 2018 11:19 PM To: Zhu, Yonghong ; edk2-devel@lists.01.org Cc: Gao, Liming Subject: RE: [Patch v1 1/1] BaseTools: create and use a standard shared variable for

Re: [edk2] [PATCH edk2-platforms 09/27] Silicon/NXP: Add headers for SoC-specific i.MX packages to use

> -Original Message- > From: Leif Lindholm > Sent: Monday, December 3, 2018 1:43 AM > To: Chris Co > Cc: edk2-devel@lists.01.org; Ard Biesheuvel ; > Michael D Kinney > Subject: Re: [PATCH edk2-platforms 09/27] Silicon/NXP: Add headers for SoC- > specific i.MX packages to use > > On

Re: [edk2] [PATCH edk2-platforms 12/27] Silicon/NXP: Add i.MX6 I/O MUX library

Hi Leif, > -Original Message- > From: Leif Lindholm > Sent: Thursday, November 8, 2018 10:00 AM > To: Chris Co > Cc: edk2-devel@lists.01.org; Ard Biesheuvel ; > Michael D Kinney > Subject: Re: [PATCH edk2-platforms 12/27] Silicon/NXP: Add i.MX6 I/O MUX > library > > On Fri, Sep 21,

Re: [edk2] [PATCH v4 0/2] Remove DuetPkg and unused tools

> -Original Message- > From: Zhang, Shenglei > Sent: Monday, December 03, 2018 10:18 AM > To: edk2-devel@lists.01.org > Cc: Ni, Ruiyu; Wu, Hao A; Zhu, Yonghong; Gao, Liming > Subject: [PATCH v4 0/2] Remove DuetPkg and unused tools > > DuetPkg depends on Legacy BIOS to provide a UEFI

Re: [edk2] [PATCH] MdePkg-BaseLib: PathCleanUpDirectories fix

Liming and Mike, I don't feel there is any logical issue with this proposed fix. However, there is some shell code that fails when the fix is in place. I think that shell code probably should be changed; I'll see if I can make an acceptable change there first. Please disregard this patch; I'll

Re: [edk2] [edk2-announce] Research Request

On Monday, 3 December 2018 02:29:28 MST Laszlo Ersek wrote: > On 11/29/18 22:20, Rebecca Cran wrote: > > Would you be interested in going through this process with Phabricator, > > too? > Sure! Just tell me where to create an account. Go to https://code.bluestop.org/auth/register/ to create a new

Re: [edk2] SCT bugzilla topic?

Leif, Earlier, we used to use UTWG Mantis (for feature requests - https://mantis.uefi.org/mantis/view.php). After, UEFI-SCT became Open source, we did discuss to have the same infrastructure setup as edk2, which means using Bugzilla. However, I don't think we have created a SCT component or

Re: [edk2] SCT bugzilla topic?

I think "EDK2 Test product with an SCT component" is the best option. Thanks ... br --- Brian Richardson -- Director, Firmware Ecosystem Development brian.richard...@intel.com -- @intel_brian (Twitter & WeChat) https://software.intel.com/en-us/meet-the-developers/evangelists/team/brian-richardson

Re: [edk2] [edk2-announce] Research Request

Laszlo, Did you want to summarize your experience of our GitHub experiments? From your comments on the PRs, it sounded like the email notifications did not provide the level of detail that you desire for archival purposes. Stephano’s email suggested that as long as we have an alternative

Re: [edk2] [RFC] Proposal to add edk2-apps repository

On 12/03/18 16:07, Leif Lindholm wrote: > On Mon, Dec 03, 2018 at 03:11:33PM +0100, Laszlo Ersek wrote: >> On 11/30/18 07:03, Andrew Fish wrote: >>> Mike, >>> >>> As Krishna points out there are flavors of Apps. Do we want to have >>> different packages for different flavor of apps, or different

Re: [edk2] [PATCH 1/4] OvmfPkg: introduce ACPI Test Support data structure and GUID

On Sun, 25 Nov 2018 11:01:49 +0100 Laszlo Ersek wrote: > QEMU's test suite includes a set of cases called "BIOS tables test". Among > other things, it locates the RSD PTR ACPI table in guest RAM, and then > (chasing pointers to other ACPI tables) performs various sanity checks on > the

Re: [edk2] Pkcs7 crypto verification without openSSL

On Mon, 3 Dec 2018 at 13:55, Tomas Pilar (tpilar) wrote: > > > > On 03/12/2018 12:40, Ard Biesheuvel wrote: > > On Wed, 28 Nov 2018 at 18:40, Tomas Pilar (tpilar) > > wrote: > >> Hi, > >> > >> Are there any plans for a crypto library that does not pull in openSSL? > >> When I try to add

Re: [edk2] [PATCH v2 0/4] ArmVirtQemu: unmap page #0 to catch NULL pointer dereferences

On Fri, 30 Nov 2018 at 12:28, Ard Biesheuvel wrote: > > Rationale in patch #4. Patch #3 is a prerequisite patch that ensures > that we no longer need page #0 to be mapped for the NOR flash driver > to be able to expose it as a read/write block device. > > Patches #1 and #2 are fixes for the ARM

Re: [edk2] [Patch v1 1/1] BaseTools: create and use a standard shared variable for '*'

I was trying to change all use of *, without regard to the usage of it. Do you think that mathematical * should not be changed? -Jaben > -Original Message- > From: Zhu, Yonghong > Sent: Sunday, December 02, 2018 6:31 PM > To: Carsey, Jaben ; edk2-devel@lists.01.org > Cc: Gao, Liming ;

Re: [edk2] [RFC] Proposal to add edk2-apps repository

On Mon, Dec 03, 2018 at 03:11:33PM +0100, Laszlo Ersek wrote: > On 11/30/18 07:03, Andrew Fish wrote: > > Mike, > > > > As Krishna points out there are flavors of Apps. Do we want to have > > different packages for different flavor of apps, or different dirs in > > a more generic App package?

Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot

Hi Ard > -Original Message- > From: Ard Biesheuvel > Sent: Monday, December 3, 2018 7:35 PM > To: Laszlo Ersek > Cc: Udit Kumar ; Andrew Fish ; Leif > Lindholm ; Ruiyu Ni ; edk2- > de...@lists.01.org; Zeng, Star > Subject: Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct

[edk2] SCT bugzilla topic?

Hi Eric, Supreeth, Mike, I was looking to raise a feature request on UEFI SCT and didn't spot such a product. Should we create one? Or perhaps we should have an EDK2 Test product with an SCT component? Regards, Leif ___ edk2-devel mailing list

Re: [edk2] [RFC] Proposal to add edk2-apps repository

On 11/30/18 05:57, Kinney, Michael D wrote: > Virtual platforms such as Ovmf and EmulatorPkg should stay in edk2 > repo to support validation. Yes, and ArmVirtPkg too. Thanks, Laszlo ___ edk2-devel mailing list edk2-devel@lists.01.org

Re: [edk2] [RFC] Proposal to add edk2-apps repository

On 11/30/18 07:03, Andrew Fish wrote: > Mike, > > As Krishna points out there are flavors of Apps. Do we want to have > different packages for different flavor of apps, or different dirs in > a more generic App package? Maybe we should define classes of UEFI > Applications in the README.md and

Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot

On Mon, 3 Dec 2018 at 14:45, Laszlo Ersek wrote: > > On 12/03/18 11:03, Udit Kumar wrote: > > Hi Laszlo > > > >> Are you using the latest edk2? > > Yes, when I hit the bug, first step was to move to latest edk2. But this > > didn't helped. > > > > I am not sure, why we are keeping PL011 Fifo

Re: [edk2] [edk2-test][v2 Patch 0/3] Add VerifySignature() Test

On 12/03/18 08:53, Eric Jin wrote: > This is the cover letter. > The series of patches are listed below. > > uefi-sct/SctPkg:Format code style in PKCS7Verify > uefi-sct/SctPkg:Add VerifySignature() Func Test > uefi-sct/SctPkg:Add VerifySignature() Conf Test > > >

Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot

On 12/03/18 11:03, Udit Kumar wrote: > Hi Laszlo > >> Are you using the latest edk2? > Yes, when I hit the bug, first step was to move to latest edk2. But this > didn't helped. > > I am not sure, why we are keeping PL011 Fifo mode off in default > configuration. Sorry, I don't know:

Re: [edk2] [PATCH v2 4/4] ArmVirtPkg/QemuVirtMemInfoLib: trim the MMIO region mapping

On 11/30/18 12:28, Ard Biesheuvel wrote: > QEMU/mach-virt is rather unhelpful when it comes to tracking down > NULL pointer dereferences that occur while running in UEFI: since > we have NOR flash mapped at address 0x0, inadvertent reads go > unnoticed, and even most writes are silently dropped,

Re: [edk2] [PATCH v2 3/4] ArmVirtPkg/NorFlashQemuLib: disregard our primary FV

On 11/30/18 12:28, Ard Biesheuvel wrote: > The primary FV contains the firmware boot image, which is not > runtime updatable in our case. So exposing it to the NOR flash > driver is undesirable, since it may attempt to modify the NOR > flash contents. It is also rather pointless, since we don't >

Re: [edk2] [PATCH v2 6/6] BaseTools/CommonLib: drop definition of MAX_UINTN

On 11/30/18 23:45, Ard Biesheuvel wrote: > The maximum value that can be represented by the native word size > of the *target* should be irrelevant when compiling tools that > run on the build *host*. So drop the definition of MAX_UINTN, now > that we no longer use it. > > Contributed-under:

Re: [edk2] [PATCH v2 5/6] BaseTools/CommonLib: get rid of 'native' type string parsing routines

On 11/30/18 23:45, Ard Biesheuvel wrote: > Parsing a string into an integer variable of the native word size > is not defined for the BaseTools, since the same tools may be used > to build firmware for different targets with different native word > sizes. > > Contributed-under: TianoCore

Re: [edk2] [PATCH v2 4/6] BaseTools/DevicePath: use MAX_UINT16 as default device path max size

On 11/30/18 23:45, Ard Biesheuvel wrote: > Replace the default size limit of IsDevicePathValid() with a value > that does not depend on the native word size of the build host. > > 64 KB seems sufficient as the upper bound of a device path handled > by UEFI. > > Contributed-under: TianoCore

Re: [edk2] Pkcs7 crypto verification without openSSL

On 03/12/2018 12:40, Ard Biesheuvel wrote: > On Wed, 28 Nov 2018 at 18:40, Tomas Pilar (tpilar) > wrote: >> Hi, >> >> Are there any plans for a crypto library that does not pull in openSSL? When >> I try to add BaseCryptLib to be able to use FmpAuthenticationLib, my driver >> size baloons

Re: [edk2] [PATCH v2 3/6] BaseTools/DevicePath: use explicit 64-bit number parsing routines

On 11/30/18 23:45, Ard Biesheuvel wrote: > Replace invocations of StrHexToUintn() with StrHexToUint64(), so > that we can drop the former. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > Reviewed-by: Jaben Carsey > --- >

Re: [edk2] [PATCH v2 2/6] BaseTools/CommonLib: use explicit 64-bit type in Strtoi()

On 11/30/18 23:45, Ard Biesheuvel wrote: > Don't use the native word size string to number parsing routines, > but instead, use the 64-bit one and cast to UINTN. > > Currently, the only user is in Source/C/DevicePath/DevicePathFromText.c > which takes care to use Strtoi64 () unless it assumes the

Re: [edk2] [PATCH v2 1/6] BaseTools/CommonLib: avoid using 'native' word size in IP address handling

On 11/30/18 23:45, Ard Biesheuvel wrote: > In the context of the BaseTools, there is no such thing as a native word > size, given that the same set of tools may be used to build a firmware > image consisting of both 32-bit and 64-bit modules. > > So update StrToIpv4Address() and

Re: [edk2] Pkcs7 crypto verification without openSSL

On Wed, 28 Nov 2018 at 18:40, Tomas Pilar (tpilar) wrote: > > Hi, > > Are there any plans for a crypto library that does not pull in openSSL? When > I try to add BaseCryptLib to be able to use FmpAuthenticationLib, my driver > size baloons significantly (increase of ~0x3) and it seems like

Re: [edk2] [Patch 0/2] Update CPUID related definition.

On 12/03/18 07:30, Eric Dong wrote: > Update CPUID definition to follow SDM 2018'11 version, changes Include: > 1. Add new fields to the existed data structure, impact CPUIDs include: > 1. CPUID_THERMAL_POWER_MANAGEMENT 0x06 >

Re: [edk2] [PATCH v2 1/4] ArmPkg/ArmMmuLib ARM: handle unmapped section in GetMemoryRegion()

On 30/11/18 12:28, Ard Biesheuvel wrote: > GetMemoryRegion() is used to obtain the attributes of an existing > mapping, to permit permission attribute changes to be optimized > away if the attributes don't actually change. > > The current ARM code assumes that a section mapping or a page mapping

Re: [edk2] [PATCH v2 6/6] BaseTools/CommonLib: drop definition of MAX_UINTN

On 30/11/18 23:45, Ard Biesheuvel wrote: > The maximum value that can be represented by the native word size > of the *target* should be irrelevant when compiling tools that > run on the build *host*. So drop the definition of MAX_UINTN, now > that we no longer use it. > > Contributed-under:

Re: [edk2] [PATCH v2 5/6] BaseTools/CommonLib: get rid of 'native' type string parsing routines

On 30/11/18 23:45, Ard Biesheuvel wrote: > Parsing a string into an integer variable of the native word size > is not defined for the BaseTools, since the same tools may be used > to build firmware for different targets with different native word > sizes. > > Contributed-under: TianoCore

Re: [edk2] [PATCH v2 2/6] BaseTools/CommonLib: use explicit 64-bit type in Strtoi()

On 30/11/18 23:45, Ard Biesheuvel wrote: > Don't use the native word size string to number parsing routines, > but instead, use the 64-bit one and cast to UINTN. > > Currently, the only user is in Source/C/DevicePath/DevicePathFromText.c > which takes care to use Strtoi64 () unless it assumes the

Re: [edk2] [PATCH v2 3/6] BaseTools/DevicePath: use explicit 64-bit number parsing routines

On 30/11/18 23:45, Ard Biesheuvel wrote: > Replace invocations of StrHexToUintn() with StrHexToUint64(), so > that we can drop the former. > > Contributed-under: TianoCore Contribution Agreement 1.1 > Signed-off-by: Ard Biesheuvel > Reviewed-by: Jaben Carsey Reviewed-by: Philippe Mathieu-Daudé

Re: [edk2] [PATCH v2 1/6] BaseTools/CommonLib: avoid using 'native' word size in IP address handling

On 30/11/18 23:45, Ard Biesheuvel wrote: > In the context of the BaseTools, there is no such thing as a native word > size, given that the same set of tools may be used to build a firmware > image consisting of both 32-bit and 64-bit modules. > > So update StrToIpv4Address() and

Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot

Hi Laszlo > Are you using the latest edk2? Yes, when I hit the bug, first step was to move to latest edk2. But this didn't helped. I am not sure, why we are keeping PL011 Fifo mode off in default configuration. Regards Udit > -Original Message- > From: Laszlo Ersek > Sent:

Re: [edk2] Help on boot manager 'Boot Manager Menu' and direct boot

On 11/30/18 10:13, Udit Kumar wrote: > Thanks Laszlo/Andrew > Finally I manage to get logs from user-space, problem was fifo of PL011 > uart was not getting enable in case of direct boot. > But in case of boot via UiApp, some piece of code was setting serial port > attribute to enable this ( I

Re: [edk2] [PATCH edk2-platforms 09/27] Silicon/NXP: Add headers for SoC-specific i.MX packages to use

On Sat, Dec 01, 2018 at 12:22:17AM +, Chris Co wrote: > > If using EFI_ACPI prefix, these #defines really should be in edk2 MdePkg. > > And > > CSRT itself is, so that might not be a bad idea. > > > > > + > > > +#pragma pack(push, 1) > > > > I don't see this #pragma making any difference to

Re: [edk2] [edk2-announce] Research Request

On 11/29/18 22:20, Rebecca Cran wrote: > Would you be interested in going through this process with Phabricator, too? Sure! Just tell me where to create an account. Thanks, Laszlo > On November 29, 2018 at 2:48:18 AM, Laszlo Ersek > (ler...@redhat.com(mailto:ler...@redhat.com)) wrote: > >>

[edk2] [edk2-test][v2 Patch 2/3] uefi-sct/SctPkg:Add VerifySignature() Func Test

Enable the BBTestVerifySignatureFunctionTest() with 2 checkpoints below, it should be success. The Certificate/Hash/Digest/signedData are updated correspondingly. a)Signed hash was verified against caller-provided hash of content, the signer's certificate was not found in RevokedDb, and was found

[edk2] [edk2-test][v2 Patch 0/3] Add VerifySignature() Test

This is the cover letter. The series of patches are listed below. uefi-sct/SctPkg:Format code style in PKCS7Verify uefi-sct/SctPkg:Add VerifySignature() Func Test uefi-sct/SctPkg:Add VerifySignature() Conf Test .../EFI/Protocol/PKCS7Verify/BlackBoxTest/Guid.c | 93 +-

[edk2] [PATCH 5/5] StandaloneMmPkg: Update dependency on PeCoffExtraActionLib

From: Achin Gupta Replace DebugPeCoffExtraActionLib with StandaloneMmExtraActionLib Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Achin Gupta Signed-off-by: Sughosh Ganu --- StandaloneMmPkg/StandaloneMmPkg.dsc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[edk2] [edk2-test][v2 Patch 3/3] uefi-sct/SctPkg:Add VerifySignature() Conf Test

Enable the BBTestVerifySignatureConformanceTest() with checkpoints under 7 cases below, it should not be success. a)Signature is NULL/SignatureSize is 0/InHash is NULL /InHashSize is 0/AllowedDb is NULL b)Modify the Data in P7TestSignature to make it invalid c)Modify the Data in InHash to make it

[edk2] [PATCH 4/5] StandaloneMmPkg: Replace dependency on ArmMmuLib

From: Achin Gupta Use StandaloneMmMmuLib instead of ArmMmuLib in StandaloneMmPkg for AArch64 Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Achin Gupta Signed-off-by: Sughosh Ganu --- StandaloneMmPkg/StandaloneMmPkg.dsc | 2 +- 1 file changed, 1 insertion(+), 1

[edk2] [PATCH 3/5] StandaloneMmPkg: Zero data structure explicitly

From: Achin Gupta Introduction of the -mstrict-align flag results in GCC attempting to use memset to zero out the InitMmFoundationSvcArgs structure. In the absence of this C library function, this patch explicitly zeroes this data structure prior to use. Contributed-under: TianoCore

[edk2] [PATCH 2/5] StandaloneMmPkg: Enforce alignment check for AArch64

From: Achin Gupta On AArch64, Standalone MM during the SEC phase runs in S-EL0 with SCTLR_EL1.A=1. This patch adds the -mstrict-align compiler flag to ensure that the generated code is compliant with the runtime alignment checks. Contributed-under: TianoCore Contribution Agreement 1.1

[edk2] [PATCH 1/5] StandaloneMmPkg: Add missing dependency on PL011UartClockLib

From: Achin Gupta This patch fixes the dependency PL011UartLib has on PL011UartClockLib by including its implementation path in the StandaloneMm DSC file. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Achin Gupta Signed-off-by: Sughosh Ganu ---