[PATCH v5 6/9] efi: Show the location of the bounce buffer when debugging
Sughosh Ganu
sughosh.ganu at linaro.org
Tue Dec 3 13:52:22 CET 2024
On Tue, 3 Dec 2024 at 18:11, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>
> On 03.12.24 13:06, Sughosh Ganu wrote:
> > On Sun, 1 Dec 2024 at 20:58, Simon Glass <sjg at chromium.org> wrote:
> >>
> >> The EFI_LOADER_BOUNCE_BUFFER feature was added many years ago. It is
> >> still needed and 24 boards (lx2160ardb_tfa_stmm,
> >> lx2162aqds_tfa_SECURE_BOOT and the like) use it.
> >>
> >> This feature uses EFI page allocation to create a 64MB buffer 'in space'
> >> without any knowledge of where boards intend to load their images. This
> >> may result in image corruption or other problems.
> >>
> >> For example, if the feature is enabled on qemu_arm64 it puts the EFI
> >> bounce buffer at 1045MB, with the kernel at 1028MB and the ramdisk at
> >> 1088MB. The kernel is probably smaller than 27MB but the buffer does
> >> overlap the ramdisk.
> >>
> >> The solution is probably to use BOUNCE_BUFFER instead, with the EFI
> >> version being dropped. For now, show the address of the EFI bounce
> >> buffer so people have a better chance to debug any problem.
> >>
> >> Signed-off-by: Simon Glass <sjg at chromium.org>
> >> ---
> >> In response to questions on how to show this problem:
> >>
> >> First, add CONFIG_EFI_LOADER_BOUNCE_BUFFER=y to
> >> configs/qemu_arm64_defconfig and build
> >>
> >> Then, to run:
> >> qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 \
> >> -bios u-boot.bin
> >>
> >> U-Boot 2024.10-00809-gae29e5f76e4a-dirty (Oct 11 2024 - 11:48:46 -0600)
> >>
> >> DRAM: 128 MiB
> >> Core: 51 devices, 14 uclasses, devicetree: board
> >> Flash: 64 MiB
> >> Loading Environment from Flash... *** Warning - bad CRC, using default environment
> >>
> >> In: serial,usbkbd
> >> Out: serial,vidconsole
> >> Err: serial,vidconsole
> >> No USB controllers found
> >> Net: eth0: virtio-net#32
> >>
> >> starting USB...
> >> No USB controllers found
> >> Hit any key to stop autoboot: 0
> >> => bootefi hello
> >> Enabling coop memory
> >> No EFI system partition
> >> No EFI system partition
> >> Failed to persist EFI variables
> >> Missing TPMv2 device for EFI_TCG_PROTOCOL
> >> Missing RNG device for EFI_RNG_PROTOCOL
> >> Warning: EFI bounce buffer 000000004157f000-000000004557f000
> >> Not loaded from disk
> >> Booting /MemoryMapped(0x0,0x47763730,0x31b0)
> >> EFI: Call: efi_load_image(false, efi_root, file_path, source_buffer, source_size, &handle)
> >> EFI: 0 returned by efi_load_image(false, efi_root, file_path, source_buffer, source_size, &handle)
> >> Hello, world!
> >> Running on UEFI 2.10
> >> Firmware vendor: Das U-Boot
> >> Firmware revision: 20241000
> >> Have device tree
> >> Load options: <none>
> >> File path: <none>
> >> Boot device: /MemoryMapped(0x0,0x47763730,0x31b0)
> >> => print kernel_addr_r
> >> kernel_addr_r=0x40400000
> >> => print ramdisk_addr_r
> >> ramdisk_addr_r=0x44000000
> >> =>
> >>
> >> The EFI bounce buffer overlaps with the ramdisk.
> >
> > Why can't we "allocate" sane values for the env variables in question,
> > similar to what is being done for the apple and qcom boards -- you can
> > refer to arch/arm/mach-apple/board.c:board_late_init(). We won't be
> > facing these issues then. Eventually, there can be a common, platform
> > agnostic function to initialise these values. So, just as a PoC, I
> > added this code to the qemu-arm.c, and no longer observe any overlaps.
> >
> > diff --git a/board/emulation/qemu-arm/qemu-arm.c
> > b/board/emulation/qemu-arm/qemu-arm.c
> > index 6095cb02b23..bad787f7a65 100644
> > --- a/board/emulation/qemu-arm/qemu-arm.c
> > +++ b/board/emulation/qemu-arm/qemu-arm.c
> > @@ -109,6 +109,9 @@ int board_init(void)
> >
> > int board_late_init(void)
> > {
> > +
> > + u32 status = 0;
> > +
> > /*
> > * Make sure virtio bus is enumerated so that peripherals
> > * on the virtio bus can be discovered by their drivers
> > @@ -119,6 +122,14 @@ int board_late_init(void)
> > if (CONFIG_IS_ENABLED(USB_KEYBOARD))
> > usb_init();
> >
> > + status |= env_set_hex("loadaddr", lmb_alloc(SZ_2M, SZ_2M));
> > + status |= env_set_hex("fdt_addr_r", lmb_alloc(SZ_2M, SZ_2M));
> > + status |= env_set_hex("kernel_addr_r", lmb_alloc(SZ_2M, SZ_2M));
> > + status |= env_set_hex("ramdisk_addr_r", lmb_alloc(SZ_8M, SZ_2M));
>
> Hello Sughosh,
>
> avoiding fixed addresses would make sense for most boards.
>
> Your suggested memory reservations for the kernel and initrd are way too
> small. On my system I find
>
> decompressed kernel - 67 MiB
> initrd - 77 MiB
>
> scriptaddr is missing.
>
> ARM have address restrictions (see function efi_get_max_initrd_addr()):
>
> armv7:
> max_init_rd_addr =
> round_down(image_addr, SZ_4M) + SZ_512M
>
> armv8:
> #define VA_BITS_MIN (48)
> max_init_rd_addr =
> round_down(image_addr, SZ_1G) + (1UL << (VA_BITS_MIN - 1))
>
> These are not modeled in your suggestion.
>
> I would suggest to make a single <= 512 MiB allocation for both initrd
> and kernel to keep both together and then assign the addresses in the
> allocated area, e.g.
>
> kerneladdr = lmb_alloc(SZ_512M, SZ_4M);
> if (!kerneladdr)
> goto err;
> if (env_set_hex("kernel_addr_r", kerneladdr))
> goto err;
> if (env_set_hex("initrd_addr_r", kerneladdr + SZ_256M))
> goto err;
Yes, I simply wanted to illustrate here that there would not be an
issue of overlaps if we used the lmb API's to get memory addresses. In
fact, this logic that you have pasted above can be added through the
reserve event function that Simon is introducing in this series -- one
of the functions can reserve memory for all these env variables. I
don't see the need to allocate some separate memory region for EFI
though. Thanks.
-sughosh
>
> Best regards
>
> Heinrich
>
> > +
> > + if (status)
> > + log_warning("late_init: Failed to set run time variables\n");
> > +
> > return 0;
> > }
> >
> >
> > U-Boot 2025.01-rc3-00042-gacab6e78aca7-dirty (Dec 03 2024 - 17:17:42 +0530)
> >
> > DRAM: 512 MiB
> > EFI bounce buffer 000000005957f000-000000005d57f000
> > Core: 51 devices, 14 uclasses, devicetree: board
> > Flash: 64 MiB
> > Loading Environment from Flash... *** Warning - bad CRC, using default
> > environment
> >
> > In: serial,usbkbd
> > Out: serial,vidconsole
> > Err: serial,vidconsole
> > No USB controllers found
> > Net: eth0: virtio-net#31
> >
> > starting USB...
> > No USB controllers found
> > Hit any key to stop autoboot: 0
> >
> > => bdinfo
> >
> > ...
> >
> > lmb_dump_all:
> > memory.count = 0x1
> > memory[0] [0x40000000-0x5fffffff], 0x20000000 bytes, flags: none
> > reserved.count = 0x3
> > reserved[0] [0x58600000-0x593fffff], 0xe00000 bytes, flags: none
> > reserved[1] [0x5957c000-0x5d57efff], 0x4003000 bytes, flags:
> > no-notify, no-overwrite
> > reserved[2] [0x5d57fde0-0x5fffffff], 0x2a80220 bytes, flags: no-overwrite
> >
> > ...
> >
> > => printenv kernel_addr_r
> > kernel_addr_r=58e00000
> > => printenv ramdisk_addr_r
> > ramdisk_addr_r=58600000
> > => printenv fdt_addr_r
> > fdt_addr_r=59000000
> > => printenv loadaddr
> > loadaddr=59200000
> >
> > -sughosh
> >
> >>
> >> Changes in v5:
> >> - Drop the word 'warning'
> >>
> >> Changes in v4:
> >> - Reword the commit message since this feature is needed
> >>
> >> lib/efi_loader/efi_bootbin.c | 9 +++++++++
> >> 1 file changed, 9 insertions(+)
> >>
> >> diff --git a/lib/efi_loader/efi_bootbin.c b/lib/efi_loader/efi_bootbin.c
> >> index 7e7a6bf31aa..9a880251b47 100644
> >> --- a/lib/efi_loader/efi_bootbin.c
> >> +++ b/lib/efi_loader/efi_bootbin.c
> >> @@ -208,6 +208,15 @@ efi_status_t efi_binary_run(void *image, size_t size, void *fdt)
> >> return -1;
> >> }
> >>
> >> +#ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER
> >> + /*
> >> + * Add a warning about this buffer, since it may conflict with other
> >> + * things
> >> + */
> >> + log_debug("EFI bounce buffer %p-%p\n", efi_bounce_buffer,
> >> + efi_bounce_buffer + EFI_LOADER_BOUNCE_BUFFER_SIZE);
> >> +#endif
> >> +
> >> ret = efi_install_fdt(fdt);
> >> if (ret != EFI_SUCCESS)
> >> return ret;
> >> --
> >> 2.43.0
> >>
>
More information about the U-Boot
mailing list