mbox series

Pull request for efi-next-26032025

Message ID 20250326145850.918186-1-ilias.apalodimas@linaro.org
State New
Headers show
Series Pull request for efi-next-26032025 | expand

Pull-request

https://source.denx.de/u-boot/custodians/u-boot-tpm/ tags/efi-next-26032025

Message

Ilias Apalodimas March 26, 2025, 2:58 p.m. UTC 
Hi Tom,

An interesting series that allows us to boot installers and live images from EFI, without any
distro-specific quirks.

The following changes since commit 042c8f0cb1ea5f6988e8633799f7b550876f0ae6:

  Merge tag 'u-boot-imx-next-20250325' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx into next (2025-03-25 08:57:38 -0600)

are available in the Git repository at:

  https://source.denx.de/u-boot/custodians/u-boot-tpm/ tags/efi-next-26032025

for you to fetch changes up to 61e0a20aecf4af6cdc223bd8cd1bd82fe5e3d9f6:

  blkmap: pass information on ISO image to the OS (2025-03-26 13:28:08 +0200)

The CI https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/25336
suffers from the lmb issue but the same patches on top master work fine
https://source.denx.de/u-boot/custodians/u-boot-tpm/-/pipelines/25338

Please pull
/Ilias

----------------------------------------------------------------
When trying to boot an OS installer or a live image via EFI HTTP the
following happens
- U-Boot downloads the image and mounts it in memory
- The EFI subsystem is invoked and the image is started
- The OS calls ExitBootServices and the memory that holds the mounted
  image might get overwritten

This results in installers complaining that they can't find installer
medium or live images complaining they can't find the root filesystem.

ACPI already deals with it by having NFIT and NVDIMM to provide ramdisks
that need to be preserved by the OS. Linux and device trees have support
for persistent memory devices (pmem).

We can use them and inject a pmem node in the DT to preserve memory across the
entire boot sequence. Linux will just create a block device over the reserved
memory and installers/images can re-discover it.

This is what it looks like from the OS perspective:

nd_pmem namespace0.0: unable to guarantee persistence of writes
pmem0: p1 p2 p3
EXT4-fs (pmem0p3): mounted filesystem f40f64a4-5b41-4828-856e-caaae2c1c2a0 r/w with ordered data mode. Quota mode: disabled.
EXT4-fs (pmem0p3): re-mounted f40f64a4-5b41-4828-856e-caaae2c1c2a0 r/w. Quota mode: disabled.
Adding 45052k swap on /dev/pmem0p2.  Priority:-2 extents:1 across:45052k SS
root@genericarm64:~# mount | grep pmem
/dev/pmem0p3 on / type ext4 (rw,relatime)
/dev/pmem0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=iso8859-1,shortname=mixed,errors=remount-ro)

It's worth noting that Linux behaves differently with reserved memory
(at least on arm64) and that depends on kernel config options.
CONFIG_ZONE_DEVICES and CONFIG_ARM64_PMEM are such options. It boils down to
how the kernel tries to map pages. If devm_memremap_pages() gets called instead
of devm_memremap() mapping the memory fails.

The only safe way is to remove the memory from the EFI memory map,
rather than defining it as /reserved no-map;/ in the DT.

----------------------------------------------------------------
Ilias Apalodimas (2):
      efi_loader: allow for removal of memory from the EFI map
      efi_loader: remove memory occupied by a ramdisk from EFI memory map

Masahisa Kojima (1):
      fdt: add support for adding pmem nodes

Sughosh Ganu (5):
      efi_loader: remove unused code from copy_fdt()
      efi_loader: install device-tree on configuration table on every invocation
      blkmap: store type of blkmap slice in corresponding structure
      blkmap: add an attribute to preserve the mem mapping
      blkmap: pass information on ISO image to the OS

 boot/fdt_support.c            | 39 +++++++++++++++++++-
 boot/image-fdt.c              |  7 ++++
 cmd/blkmap.c                  |  9 ++++-
 drivers/block/blkmap.c        | 82 +++++++++++++++++++++++++++++++++++++++--
 drivers/block/blkmap_helper.c |  2 +-
 include/blkmap.h              | 33 ++++++++++++++++-
 include/efi.h                 | 13 +++++++
 include/efi_loader.h          | 15 ++++++++
 include/fdt_support.h         | 14 +++++++
 lib/efi_loader/efi_bootmgr.c  | 25 ++++++++++---
 lib/efi_loader/efi_helper.c   | 85 ++++++++++++++++++++++++++++++++++---------
 lib/efi_loader/efi_memory.c   | 34 +++++++++--------
 12 files changed, 310 insertions(+), 48 deletions(-)

Comments

Tom Rini March 27, 2025, 2:24 a.m. UTC | #1 
On Wed, 26 Mar 2025 16:58:50 +0200, Ilias Apalodimas wrote:

> An interesting series that allows us to boot installers and live images from EFI, without any
> distro-specific quirks.
> 
> The following changes since commit 042c8f0cb1ea5f6988e8633799f7b550876f0ae6:
> 
>   Merge tag 'u-boot-imx-next-20250325' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx into next (2025-03-25 08:57:38 -0600)
> 
> are available in the Git repository at:
> 
> [...]

Merged into u-boot/next, thanks!