> -Original Message-
> From: Albecki, Mateusz
> Sent: Friday, February 28, 2020 1:25 AM
> To: devel@edk2.groups.io
> Cc: Albecki, Mateusz; Wu, Hao A; Marcin Wojtas; Gao, Zhichao; Gao, Liming
> Subject: [PATCHv3 0/5] MdeModulePkg/SdMmcPciHcDxe: Refactor
> command processing
>
> This patch s
Implement another version of QemuLoadImageLib that uses LoadImage and
StartImage, but falls back to the legacy Linux loader code if that
fails. The logic in the legacy fallback routines is identical to the
current QEMU linux loader for X64 and IA32.
Note the use of a LoadedImage pseudo-protocol fo
In an upcoming patch, we will introduce a separate DXE driver that
exposes the virtual SimpleFileSystem implementation that carries the
kernel and initrd passed via the QEMU command line, and a separate
library that consumes it, to be incorporated into the boot manager.
Since the GUID used for the
Replace the open coded sequence to load Linux on x86 with a short and
generic sequence invoking QemuLoadImageLib, which can be provided by
a generic version that only supports the LoadImage and StartImage boot
services, and one that incorporates the entire legacy loading sequence
as well.
Ref: htt
The QemuLoadImageLib implementation we currently use for all OVMF
builds copies the behavior of the QEMU loader code that precedes it,
which is to disregard UEFI secure boot policies entirely when it comes
to loading kernel images that have been specified on the QEMU command
line. This behavior dev
Add the components that expose the QEMU abstract loader file system so
that we can switch over our PlatformBmLib over to it in a subsequent
patch.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/OvmfPkgIa32.dsc| 2 ++
OvmfPkg/OvmfPkgIa32.fdf
Linux v5.7 will introduce a new method to load the initial ramdisk
(initrd) from the loader, using the LoadFile2 protocol installed on a
special vendor GUIDed media device path.
Add support for this to our QEMU command line kernel/initrd loader.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id
Add the QEMU loader DXE driver and client library to the build for
our QEMU targeted implementations in ArmVirtPkg.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel
---
ArmVirtPkg/ArmVirtQemu.dsc | 2 ++
ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 1 +
We have no need for exposing the kernel command line as a file,
so remove support for that. Since the remaining blobs (kernel
and initrd) are typically much larger than a page, switch to
the page based allocator for blobs at the same time.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
S
Expose the existing implementation of an abstract filesystem exposing
the blobs passed to QEMU via the command line via a standalone DXE
driver.
Notable difference with the original code is the switch to a new vendor
GUIDed media device path, as opposed to a vendor GUID hardware device
path, which
Implement QemuLoadImageLib, and make it load the image provided by the
QEMU_EFI_LOADER_FS_MEDIA_GUID/kernel device path that we implemented
in a preceding patch in a separate DXE driver, using only the standard
LoadImage and StartImage boot services.
Ref: https://bugzilla.tianocore.org/show_bug.cg
Drop the QEMU loader file system implementation inside this library,
and switch to the separate QemuLoadImageLib library and the associated
driver to expose the kernel and initrd passed via the QEMU command line.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuve
On ArmVirtQemu, we require the kernel passed via the QEMU -kernel option
to have a PE/COFF header and an EFI stub, so that it can be loaded and
started using the LoadImage and StartImage boot services, respectively.
This means that, on builds that enable secure boot or measured boot, the
kernel ima
Introduce the QemuLoadImageLib library class that we will instantiate
to load the kernel image passed via the QEMU command line using the
standard LoadImage boot service.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel
---
OvmfPkg/Include/Library/QemuLoadIm
On x86, the kernel image consists of a setup block and the actual kernel,
and QEMU presents these as separate blobs, whereas on disk (and in terms
of PE/COFF image signing), they consist of a single image.
So add support to our FS loader driver to expose files via the abstract
file system that con
Hi,
On Wed, Feb 19, 2020 at 8:37 AM Vijayenthiran Subramaniam
wrote:
>
> Fix "use of logical '&&' with constant operand" error when built with
> CLANG38 toolchain.
>
> Signed-off-by: Vijayenthiran Subramaniam
> ---
>
> Changes since v1:
> - Fix Copyright year
>
> Notes:
> Fix Clan error re
Reviewed-by: Ray Ni
I will add the "STATIC" when pushing.
> -Original Message-
> From: devel@edk2.groups.io On Behalf Of Ni, Ray
> Sent: Monday, March 2, 2020 10:00 AM
> To: Leo Duran ; devel@edk2.groups.io
> Cc: Dong, Eric ; Laszlo Ersek
> Subject: Re: [edk2-devel] [PATCH] UefiCpuPkg/M
> On Mar 1, 2020, at 3:41 PM, Michael D Kinney
> wrote:
>
> Andrew,
>
> Thanks. I did not realize this was a struct with
> a single flexible array member. I agree that does
> not make sense.
>
> The top level struct here is a HOB that must be in
> contiguous memory. The HOB can vary in si
Currently brotli is used and customized by edk2 in BaseTools
and MdeModulePkg. These two patches make brotli a submodule in
edk2.
https://bugzilla.tianocore.org/show_bug.cgi?id=2558
https://bugzilla.tianocore.org/show_bug.cgi?id=2559
Cc: Liming Gao
Cc: Jian J Wang
Cc: Hao A Wu
Cc: Bob Feng
She
This patch was pushed.
https://github.com/tianocore/edk2/commit/2be4828af1c92a848af90429a9a0b44544c80553
Thanks,
Bob
-Original Message-
From: Gao, Liming
Sent: Thursday, February 27, 2020 10:57 PM
To: devel@edk2.groups.io; Feng, Bob C
Cc: Andrew Fish ; Laszlo Ersek ; Leif
Lindholm ; Ki
Leo,
The function name is the same as another local function defined in LocalApicLib.
You may need to add a STATIC keyword for this local function, or change it to a
different name.
Thanks,
Ray
> -Original Message-
> From: Leo Duran
> Sent: Saturday, February 29, 2020 11:06 PM
> To: deve
Andrew,
Thanks. I did not realize this was a struct with
a single flexible array member. I agree that does
not make sense.
The top level struct here is a HOB that must be in
contiguous memory. The HOB can vary in size based on
MicrocodeCount and StorageType. We are trying to make
it easy to
Hi Ray,
OvmfPkg and ArmVirtPkg platforms set PcdPlatformBootTimeOut in their
PlatformBootManagerLib instances, in BeforeConsole(). This generally
works, except for one aspect: in BdsEntry(), the Timeout UEFI variable
is set from the PCD before BeforeConsole() is called.
The Timeout variable is in
23 matches
Mail list logo
