Re: [edk2] [Patch V4 4/4] MdeModulePkg: Add generic PciHostBridgeDxe driver.

Marcel, Please see my reply embedded below. On 2016-02-02 19:07, Laszlo Ersek wrote: On 02/01/16 16:07, Marcel Apfelbaum wrote: On 01/26/2016 07:17 AM, Ni, Ruiyu wrote: Laszlo, I now understand your problem. Can you tell me why OVMF needs multiple root bridges support? My understanding to

[edk2] [PATCH 2/2] MdeModulePkg: Add sample help information for HelloWorld application.

Since Shell supports finding help information from resource section of application image. We enhance the HelloWorld to add help information string. After the HelloWorld are loaded in system the help string will be stored in resource section of the application image. Cc: Feng Tian

[edk2] [PATCH 1/2] ShellPkg: Support finding help message embedded in resource section.

UEFI Shell scandalizes the help message in spec level so that a standalone UEFI shell application can never get "-?" switch, instead the Shell core (interpreter) detects the "-?" and finds .MAN file for that shell application in certain spec defined paths, then show the help extracted from that

[edk2] SCT Failure

Hi I installed SCT but when I try to run it the following happens: Load support files ... Load proxy files ... ERROR: Cannot do the operations. Status - Not Found Does SCT have a special requirement?(I'm using a PrePi config so I don't have Pei stuff i.e.). Michael

Re: [edk2] [PATCH 0/3] ArmVirtPkg: implement ArmVirtQemuKernel that executes from RAM

On 02/05/16 16:40, Ard Biesheuvel wrote: > On 5 February 2016 at 15:05, Ard Biesheuvel wrote: >> When emulating a full stack of ARM Trusted Firmware, OP-TEE, etc, UEFI will >> not >> be executed from (emulated) NOR flash but loaded in memory at an a priori >> unknown

Re: [edk2] [PATCH 0/3] ArmPlatformPkg/ArmJunoPkg: Adds SMBIOS data for ARM Juno

z and A53s at 800 Mhz. I assume the 650 is coming from "mArmDefaultType4_a53", so I guess there needs to be something smarter in there. And the amount of RAM should be fixed up too. Cheers, Ryan. [1] https://git.linaro.org/landing-teams/working/arm/edk2.git/shortlog/refs/tags/armlt-2016

Re: [edk2] manually booting efi file

> On Feb 5, 2016, at 6:44 AM, Michael Zimmermann > wrote: > > Lazlo, > > using 'FileDevicePath' works perfectly, thx :) > sth. else I stumbled on is this typedef: > typedef EFI_DEVICE_PATH_PROTOCOL EFI_DEVICE_PATH; > > I tried to find a way to convert from

[edk2] [PATCH] BaseTools-Source: Update displayed version information

Standardize the --version and --help text command-line options Updated tools to correctly display the Build number when using command-line option --version and exit successfully after termination. Ecc was also updated to print informational messages after the options are parsed. Cc: Zhu Yonghong

[edk2] Connecting all devices at boot

Hello all, I'm having a problem that is platform specific, but perhaps more of a generic problem. When ARM's Juno board boots, not all devices are connected. The first boot creates the boot variables and sets their order, meaning that we get the following list on the first attempt: EFI Misc

Re: [edk2] Connecting all devices at boot

> On Feb 5, 2016, at 9:56 AM, Cohen, Eugene wrote: > >> 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

Re: [edk2] [PATCH 0/3] ArmPlatformPkg/ArmJunoPkg: Adds SMBIOS data for ARM Juno

ltType4_a53", so I guess > there needs to be something smarter in there. > > And the amount of RAM should be fixed up too. > And I forgot to mention, that because I've removed Juno from EDK2 in my tree, I split your last patch into two: one for EDK2 and another for OpenPlatfor

Re: [edk2] Connecting all devices at boot

Hi Laszlo, On 5 February 2016 at 17:19, Laszlo Ersek wrote: > On 02/05/16 17:35, Ryan Harkin wrote: >> Hello all, >> >> I'm having a problem that is platform specific, but perhaps more of a >> generic problem. >> >> When ARM's Juno board boots, not all devices are connected.

Re: [edk2] Connecting all devices at boot

Hi Andrew, On 5 February 2016 at 18:39, Andrew Fish wrote: > >> On Feb 5, 2016, at 10:36 AM, Ryan Harkin wrote: >> >> Hi Laszlo, >> >> On 5 February 2016 at 17:19, Laszlo Ersek wrote: >>> On 02/05/16 17:35, Ryan Harkin wrote:

Re: [edk2] Connecting all devices at boot

On 02/05/16 19:26, Andrew Fish wrote: [snip] > In general connecting all drivers on boot is a performance bug. I agree in general, but for a QEMU VM specifically, bootable devices can show up and go away at every boot, at wildly different addresses, and there's no way to know about such changes

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

Re: [edk2] Connecting all devices at boot

> On Feb 5, 2016, at 10:36 AM, Ryan Harkin wrote: > > Hi Laszlo, > > On 5 February 2016 at 17:19, Laszlo Ersek wrote: >> On 02/05/16 17:35, Ryan Harkin wrote: >>> Hello all, >>> >>> I'm having a problem that is platform specific, but perhaps more of

Re: [edk2] Connecting all devices at boot

Hi Eugene, On 5 February 2016 at 17:56, Cohen, Eugene wrote: >> 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

Re: [edk2] [PATCH] BaseTools-Source: Update displayed version information

Reviewed-by: Erik Bjorge > -Original Message- > From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of > Larry Hauch > Sent: Friday, February 5, 2016 8:03 AM > To: edk2-devel@lists.01.org > Subject: [edk2] [PATCH] BaseTools-Source: Update

Re: [edk2] varstore compatibility between auth and non-auth

On 02/05/16 13:37, Laszlo Ersek wrote: > On 02/05/16 13:18, Gerd Hoffmann wrote: >> Hi, >> >>> So, my question is: is this intended and supported behavior (that is, >>> going from a Secure Boot-capable build to a Secure Boot-disabled build, >>> while preserving the contents & functionality of

Re: [edk2] [PATCH 0/3] ArmPlatformPkg/ArmJunoPkg: Adds SMBIOS data for ARM Juno

On 02/05/2016 10:55 AM, Ryan Harkin wrote: Hi Jeremy, I just wanted to follow up on this old patch series. I've pushed them into my tree for the 16.02 Platforms release [1]. I have an updated version for R2 that solves part of the R0/R1/R2 detection problems, as well as adding the A72's,

Re: [edk2] Connecting all devices at boot

On 02/05/16 18:56, Cohen, Eugene wrote: >> 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 >

Re: [edk2] Connecting all devices at boot

On 02/05/16 19:36, Ryan Harkin wrote: > Hi Laszlo, > > On 5 February 2016 at 17:19, Laszlo Ersek wrote: >> On 02/05/16 17:35, Ryan Harkin wrote: >>> Hello all, >>> >>> I'm having a problem that is platform specific, but perhaps more of a >>> generic problem. >>> >>> When ARM's

Re: [edk2] Connecting all devices at boot

Hi Laszlo, On 5 February 2016 at 18:50, Laszlo Ersek wrote: > On 02/05/16 19:36, Ryan Harkin wrote: >> Hi Laszlo, >> >> On 5 February 2016 at 17:19, Laszlo Ersek wrote: >>> On 02/05/16 17:35, Ryan Harkin wrote: Hello all, I'm having a problem

Re: [edk2] Connecting all devices at boot

> On Feb 5, 2016, at 10:47 AM, Ryan Harkin wrote: > > Hi Andrew, > > On 5 February 2016 at 18:39, Andrew Fish wrote: >> >>> On Feb 5, 2016, at 10:36 AM, Ryan Harkin wrote: >>> >>> Hi Laszlo, >>> >>> On 5 February 2016 at

[edk2] [PATCH] ArmPlatformPkg: remove used .dsc and .fdf files

The .dsc and .fdf files in ArmPlatformPkg are unused. Remove them as part of a general cleanup of ArmPlatformPkg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ryan Harkin --- ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc | 382

Re: [edk2] [PATCH v2 0/6] ArmPlatformPkg: remove unused code

On 4 February 2016 at 11:40, Ryan Harkin wrote: > On 3 February 2016 at 17:42, Leif Lindholm wrote: >> Hi Ryan, >> >> On Wed, Feb 03, 2016 at 05:09:28PM +, Ryan Harkin wrote: >>> This is an update to my original series titled: >>> >>>

Re: [edk2] [PATCH 0/3] ArmVirtPkg: implement ArmVirtQemuKernel that executes from RAM

On 5 February 2016 at 15:05, Ard Biesheuvel wrote: > When emulating a full stack of ARM Trusted Firmware, OP-TEE, etc, UEFI will > not > be executed from (emulated) NOR flash but loaded in memory at an a priori > unknown memory address and invoked from there. > > This

Re: [edk2] How do you get current timestamp in ms or ns ?

Thanks a lot Andrew. - I built the DUET image according to the ReadMe that you mentioned but ran into issues while creating the bootable disk. Is that one needed? - Where should I see the DEBUG prints from the DXE core exactly? Thanks, Estelle On Thu, Feb 4, 2016 at 2:42 PM, Andrew Fish

Re: [edk2] [PATCH] OvmfPkg: simplify VARIABLE_STORE_HEADER generation

Reviewed-by: Jordan Justen On 2016-02-05 12:41:53, Laszlo Ersek wrote: > Before the merger of the authenticated and non-authenticated variable > drivers (commit fa0737a839d0), we had to match the varstore header GUID in > "OvmfPkg/VarStore.fdf.inc" to

[edk2] [PATCH v3 1/4] ArmPlatformPkg: Add A72 CPU type

Add the A72 CPU type which is used in JunoR2. Signed-off-by: Jeremy Linton --- ArmPkg/Include/Chipset/AArch64.h | 1 + 1 file changed, 1 insertion(+) diff --git a/ArmPkg/Include/Chipset/AArch64.h b/ArmPkg/Include/Chipset/AArch64.h index e53605f..12fcbf6 100644 ---

[edk2] [PATCH v3 3/4] Convert ArmJunoDxe to use common juno revision code

Now that the code to detect the Juno revision is in the header go ahead and covert the ArmJunoDxe to use it. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeremy Linton --- .../ArmJunoPkg/Drivers/ArmJunoDxe/ArmJunoDxe.c | 66

[edk2] [PATCH v3 4/4] ArmPlatformPkg/ArmJunoPkg: Create SMBIOS/DMI data for Juno

SMBIOS data is consumed by a wide range of enterprise applications. Fill in the basic requirements of the SMBIOS specification by hardcoding the minimum required structures and data using Juno information. With this change both the EFI shell and linux dmidecode commands return useful information.

[edk2] [PATCH v3 2/4] Code to detect what juno revision we are running on.

The code to detect what juno revision we are running on is fairly small put it in a common header where it may be used in a couple places. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jeremy Linton ---

[edk2] [PATCH] OvmfPkg: simplify VARIABLE_STORE_HEADER generation

Before the merger of the authenticated and non-authenticated variable drivers (commit fa0737a839d0), we had to match the varstore header GUID in "OvmfPkg/VarStore.fdf.inc" to SECURE_BOOT_ENABLE, because the opposite GUID would cause either driver to fail an assertion. The header structures for

Re: [edk2] manually booting efi file

Since you asked here is a little more info: The file's EFI_FILE_PROTOCOL is insufficient information to find it as it just contains the path in file system for the file. That's the equivalent to saying "I want to open file directory/foo.txt". you need to give more context for success. To

[edk2] [PATCH v3 0/4] ArmPlatformPkg/ArmJunoPkg: Adds SMBIOS data for ARM Juno

V3 of this patch, adds support for JunoR2, and cleans up the board revision detection logic futher over V2. SMBIOS data is consumed by a wide range of enterprise applications. This patch adds basic SMBIOS data for the ARM Juno. Most of the data is static. The system memory layout and juno

Re: [edk2] [PATCH 0/3] ArmPlatformPkg/ArmJunoPkg: Adds SMBIOS data for ARM Juno

On 02/05/2016 10:55 AM, Ryan Harkin wrote: Hi Jeremy, I just wanted to follow up on this old patch series. I've pushed them into my tree for the 16.02 Platforms release [1]. If your preparing another release, please also pick up: "AtaBusDxe: Bounce buffer IO operations if unaligned" or

Re: [edk2] [PATCH v2 0/6] ArmPlatformPkg: remove unused code

On Fri, Feb 05, 2016 at 09:17:37AM +, Ryan Harkin wrote: > On 5 February 2016 at 08:42, Ard Biesheuvel wrote > >> Ard's last comment on the idea of removing FVP was: > >> > >> "I am happy to switch to OpenPlatformPkg for building those once it is > >> synced up with

Re: [edk2] [PATCH v2 0/6] ArmPlatformPkg: remove unused code

On 5 February 2016 at 08:42, Ard Biesheuvel wrote: > On 5 February 2016 at 09:18, Ryan Harkin wrote: >> On 4 February 2016 at 11:40, Ryan Harkin wrote: >>> On 3 February 2016 at 17:42, Leif Lindholm

Re: [edk2] [PATCH v2] ArmPlatformPkg: remove used .dsc and .fdf files

On 5 February 2016 at 10:53, Ryan Harkin wrote: > The .dsc and .fdf files in ArmPlatformPkg are unused. Remove them as > part of a general cleanup of ArmPlatformPkg. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Ryan Harkin

Re: [edk2] [PATCH] ArmPlatformPkg: remove used .dsc and .fdf files

'remove used .dsc and .fdf files'? You may want to change the title :D On Fri, Feb 5, 2016 at 9:05 AM, Ryan Harkin wrote: > The .dsc and .fdf files in ArmPlatformPkg are unused. Remove them as > part of a general cleanup of ArmPlatformPkg. > > Contributed-under:

Re: [edk2] [PATCH v2 6/6] Revert "ArmPlatformPkg: Create an ARM Platform DSC / FDF / ArmPlatformLib template"

On 4 February 2016 at 21:00, Carsey, Jaben wrote: >> -Original Message- >> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >> Laszlo Ersek >> Sent: Thursday, February 04, 2016 12:23 PM >> To: Ryan Harkin >> Cc: Ard

Re: [edk2] [PATCH v2 6/6] Revert "ArmPlatformPkg: Create an ARM Platform DSC / FDF / ArmPlatformLib template"

On 02/05/16 10:50, Ryan Harkin wrote: > On 4 February 2016 at 21:00, Carsey, Jaben wrote: >>> -Original Message- >>> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of >>> Laszlo Ersek >>> Sent: Thursday, February 04, 2016 12:23 PM >>> To: Ryan

Re: [edk2] [PATCH v2 0/6] ArmPlatformPkg: remove unused code

On 5 February 2016 at 09:18, Ryan Harkin wrote: > On 4 February 2016 at 11:40, Ryan Harkin wrote: >> On 3 February 2016 at 17:42, Leif Lindholm wrote: >>> Hi Ryan, >>> >>> On Wed, Feb 03, 2016 at 05:09:28PM +, Ryan

Re: [edk2] [PATCH v2] ArmPlatformPkg: remove used .dsc and .fdf files

Gah! I fixed the "used"->"unused" title in my tree, then git send-email'd the wrong sha id! I'm not having a good morning :-/ On 5 February 2016 at 09:55, Ard Biesheuvel wrote: > On 5 February 2016 at 10:53, Ryan Harkin wrote: >> The .dsc and

Re: [edk2] varstore compatibility between auth and non-auth

Hi, > So, my question is: is this intended and supported behavior (that is, > going from a Secure Boot-capable build to a Secure Boot-disabled build, > while preserving the contents & functionality of the variables), or just > a lucky coincidence that results from the design choices you made

[edk2] varstore compatibility between auth and non-auth

Hi Star, before you merged the two separate variable drivers in July 2015, each of the authenticated and the non-authenticated variable drivers would enforce its own GUID in the VARIABLE_STORE_HEADER.Signature field -- gEfiAuthenticatedVariableGuid and gEfiVariableGuid. The consequence was that

[edk2] manually booting efi file

Hi, how can I boot a EFI application if I have it's 'EFI_FILE_PROTOCOL'? 'BdsStartEfiApplication' does only accept a 'EFI_DEVICE_PATH'. Michael ___ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] manually booting efi file

On 02/05/16 12:44, Michael Zimmermann wrote: > Hi, > > how can I boot a EFI application if I have it's 'EFI_FILE_PROTOCOL'? > 'BdsStartEfiApplication' does only accept a 'EFI_DEVICE_PATH'. You could do the following: - call LocateHandle() to find all handles that have EFI_FILE_PROTOCOL

Re: [edk2] varstore compatibility between auth and non-auth

On 02/05/16 13:18, Gerd Hoffmann wrote: > Hi, > >> So, my question is: is this intended and supported behavior (that is, >> going from a Secure Boot-capable build to a Secure Boot-disabled build, >> while preserving the contents & functionality of the variables), or just >> a lucky coincidence

Re: [edk2] manually booting efi file

On 02/05/16 14:26, Michael Zimmermann wrote: > The problem is that there is no GUID for 'EFI_FILE_PROTOCOL' there's > only 'EFI_SIMPLE_FILE_SYSTEM_PROTOCOL' which I already have. Ah, sorry, I completely forgot about this. I've only ever worked with EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and

[edk2] [PATCH 1/3] ArmVirtPkg/EarlyFdtPL011: allow patchable PCD for initial DT base address

Allow the use of a patchable PCD for the initial DT base address recorded in gArmVirtTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress, so that the module can be reused by a relocatable version of ArmVirtQemu. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel

[edk2] [PATCH 2/3] ArmVirtPkg: introduce new ArmQemuRelocatablePlatformLib

This introduces ArmQemuRelocatablePlatformLib, which started out as a straight copy of ArmXenRelocatablePlatformLib, but has been modified so that ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf can be used with QEMU as well as with Xen. It retains the self relocation and FDT parsing for the

[edk2] [PATCH 3/3] ArmVirtPkg: implement ArmVirtQemuKernel

This implements a version of ArmVirtQemu that does not execute in place from emulated NOR flash, but implements the Linux kernel boot protocol, and executes from DRAM instead. This allows UEFI to be loaded as a payload by a previous bootloader stage such as ARM Trusted Firmware/OP-TEE.

[edk2] [PATCH 0/3] ArmVirtPkg: implement ArmVirtQemuKernel that executes from RAM

When emulating a full stack of ARM Trusted Firmware, OP-TEE, etc, UEFI will not be executed from (emulated) NOR flash but loaded in memory at an a priori unknown memory address and invoked from there. This implements a version of ArmVirtQemu called ArmVirtQemuKernel which borrows the self

Re: [edk2] manually booting efi file

The problem is that there is no GUID for 'EFI_FILE_PROTOCOL' there's only 'EFI_SIMPLE_FILE_SYSTEM_PROTOCOL' which I already have. I don't even understand the concept of a devicepath attached to a file since a file is not a device. How do the Shell or other boot manager load such files? On Fri,

Re: [edk2] manually booting efi file

well I do have both the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL and the related DevicePath already. But I guess that this is not enough since 'BdsStartEfiApplication' has to know which file to boot somehow. On Fri, Feb 5, 2016 at 2:34 PM, Alcantara, Paulo < paulo.alc.cavalca...@hp.com> wrote: > I don't

[edk2] [PATCH v2] ArmPlatformPkg: remove used .dsc and .fdf files

The .dsc and .fdf files in ArmPlatformPkg are unused. Remove them as part of a general cleanup of ArmPlatformPkg. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ryan Harkin --- ArmPlatformPkg/ArmPlatformPkg-2ndstage.dsc | 382

Re: [edk2] [PATCH 2/3] ArmVirtPkg: introduce new ArmQemuRelocatablePlatformLib

On 02/05/16 15:05, Ard Biesheuvel wrote: > This introduces ArmQemuRelocatablePlatformLib, which started out as a > straight copy of ArmXenRelocatablePlatformLib, but has been modified so > that ArmVirtPkg/PrePi/ArmVirtPrePiUniCoreRelocatable.inf can be used with > QEMU as well as with Xen. It

Re: [edk2] [PATCH 1/3] ArmVirtPkg/EarlyFdtPL011: allow patchable PCD for initial DT base address

On 02/05/16 15:05, Ard Biesheuvel wrote: > Allow the use of a patchable PCD for the initial DT base address recorded in > gArmVirtTokenSpaceGuid.PcdDeviceTreeInitialBaseAddress, so that the module > can be reused by a relocatable version of ArmVirtQemu. > > Contributed-under: TianoCore

Re: [edk2] [PATCH 3/3] ArmVirtPkg: implement ArmVirtQemuKernel

On 02/05/16 15:05, Ard Biesheuvel wrote: > This implements a version of ArmVirtQemu that does not execute in place from > emulated NOR flash, but implements the Linux kernel boot protocol, and > executes > from DRAM instead. This allows UEFI to be loaded as a payload by a previous > bootloader

[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] manually booting efi file

Lazlo, using 'FileDevicePath' works perfectly, thx :) sth. else I stumbled on is this typedef: typedef EFI_DEVICE_PATH_PROTOCOL EFI_DEVICE_PATH; I tried to find a way to convert from EFI_DEVICE_PATH_PROTOCOL to EFI_DEVICE_PATH until I saw that it's just an alias :P Thanks for everyone's help

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

Eugene: This PCD is for PeiCore and PEIM, not for DxeCore. I agree to update PeiCore to check FileType first, then apply this PCD. Thanks Liming -Original Message- From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Cohen, Eugene Sent: Friday, February 05, 2016

[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. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Liming Gao