summaryrefslogtreecommitdiff
path: root/cmd/blkmap.c
diff options
context:
space:
mode:
authorTom Rini <trini@konsulko.com>2025-03-26 14:07:09 -0600
committerTom Rini <trini@konsulko.com>2025-03-26 14:07:09 -0600
commitdf11ac859d366d96f749f2b9c3d2d5c564b325bc (patch)
tree7f22d24b51d695d43fce63b6a2ebcda582399a16 /cmd/blkmap.c
parentb052de94fa14577cb5d9e724edeb09fee674d582 (diff)
parent61e0a20aecf4af6cdc223bd8cd1bd82fe5e3d9f6 (diff)
Merge tag 'efi-next-26032025' of https://source.denx.de/u-boot/custodians/u-boot-tpm into next
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.
Diffstat (limited to 'cmd/blkmap.c')
-rw-r--r--cmd/blkmap.c9
1 files changed, 7 insertions, 2 deletions
diff --git a/cmd/blkmap.c b/cmd/blkmap.c
index 164f80f1387..86a123b1cd3 100644
--- a/cmd/blkmap.c
+++ b/cmd/blkmap.c
@@ -62,13 +62,18 @@ static int do_blkmap_map_mem(struct map_ctx *ctx, int argc, char *const argv[])
{
phys_addr_t addr;
int err;
+ bool preserve = false;
if (argc < 2)
return CMD_RET_USAGE;
addr = hextoul(argv[1], NULL);
- err = blkmap_map_pmem(ctx->dev, ctx->blknr, ctx->blkcnt, addr);
+ if (argc == 3 && !strcmp(argv[2], "preserve"))
+ preserve = true;
+
+ err = blkmap_map_pmem(ctx->dev, ctx->blknr, ctx->blkcnt, addr,
+ preserve);
if (err) {
printf("Unable to map %#llx at block 0x" LBAF ": %d\n",
(unsigned long long)addr, ctx->blknr, err);
@@ -221,7 +226,7 @@ U_BOOT_CMD_WITH_SUBCMDS(
"blkmap create <label> - create device\n"
"blkmap destroy <label> - destroy device\n"
"blkmap map <label> <blk#> <cnt> linear <interface> <dev> <blk#> - device mapping\n"
- "blkmap map <label> <blk#> <cnt> mem <addr> - memory mapping\n",
+ "blkmap map <label> <blk#> <cnt> mem <addr> [preserve] - memory mapping\n",
U_BOOT_SUBCMD_MKENT(info, 2, 1, do_blkmap_common),
U_BOOT_SUBCMD_MKENT(part, 2, 1, do_blkmap_common),
U_BOOT_SUBCMD_MKENT(dev, 4, 1, do_blkmap_common),