On 17.08.26 21:41, Alexander Graf via groups.io wrote: > We want to chain-load UEFI from a functional UEFI environment. This is > useful for example to enable new core UEFI functionality or different > DXE drivers that would be more difficult to build against the running > version. It also lets us test UefiPayloadPkg under QEMU/OVMF without > building coreboot or Slim Bootloader first. > > This series adds ChainloadApp, a UEFI application that starts > UEFIPAYLOAD.fd from inside an already-running UEFI environment. > Everything is discovered, not configured: the UEFI memory map and GCD > map give the memory topology, ACPI SPCR gives the serial console, ACPI > MCFG gives the ECAM aperture, ACPI MADT gives the GIC on AArch64, and > the configuration table gives RSDP and SMBIOS. There are no > platform-specific addresses in the series. > > No core package is touched. The series lands in ArmPkg (1 patch), > ArmPlatformPkg (1) and UefiPayloadPkg (21). Endpoint BARs that the > outer firmware left at zero are programmed by ChainloadApp itself, > through ECAM located from the ACPI MCFG, before the payload is > launched, so the payload's light enumeration finds every BAR assigned > and a stock UEFIPAYLOAD.fd works unmodified. > > Patches 03, 04, 05 and 06 are independent bug fixes for existing > coreboot and Slim Bootloader users. Each one fixes a crash, an assert > or a silent memory loss that exists today, with no dependency on > chainloading, and each changes behaviour unconditionally because that > is the point of it. Everything else that could affect an existing > build is behind an option that defaults to the current value: > CHAINLOAD_DEFAULTS, VIRTIO_ENABLE and PcdPublishMcfgAsReservedMemory > are all FALSE unless a platform turns them on. One caveat on that > claim: I have not booted a coreboot board or a Slim Bootloader > platform with this series applied, so the compatibility argument comes > from reading the code. If someone with either can test it, I would > rather hear about a regression before this lands than after. > > All four tip configurations build clean (X64 and AArch64, DEBUG and > RELEASE), every commit builds individually across both architectures > and both CHAINLOAD_DEFAULTS values (92/92), and the chainloaded > payload boots under an outer edk2-based firmware: Ubuntu 24.04 arm64 > on AArch64, Windows Server 2025, Ubuntu 24.04 and FreeBSD 14.3 on X64, > DEBUG and RELEASE each. Memory handed to the OS matches a direct boot > of the same payload to within 100 KiB (0.005 %) on the AArch64 > reference platform. An ACPI/SMBIOS pointer scan on both architectures > found nothing in what the payload hands the OS that points into > memory reclaimed from the outer firmware. > > To reproduce: > > cd /path/to/edk2 > source edksetup.sh > ARCH=X64 BUILD_TARGET=DEBUG ./UefiPayloadPkg/BuildChainloadEmbedded.sh > ARCH=AARCH64 BUILD_TARGET=DEBUG ./UefiPayloadPkg/BuildChainloadEmbedded.sh > > UefiPayloadPkg/ChainloadApp/README.md has the exact QEMU command lines > for both architectures.
I only saw after posting that edk2 is now using pull requests. I created one here: https://github.com/tianocore/edk2/pull/12983 Alex -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#122108): https://edk2.groups.io/g/devel/message/122108 Mute This Topic: https://groups.io/mt/120797177/21656 Group Owner: [email protected] Unsubscribe: https://edk2.groups.io/g/devel/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
