[PATCH v5 6/9] efi: Show the location of the bounce buffer when debugging

[Tom Rini]

On Tue, Dec 03, 2024 at 05:36:40PM +0530, 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.

There's two challenges. One challenge is that yes, we should make use of
LMB generally to allocate regions in the common case, like mach-apple
does. The second challenge is that everyone had agreed (I would swear)
that the EFI-specific bounce buffer needs to be removed and just use the
generic bounce buffer option. But no one has wanted to do the work, and
so Simon keeps posting some variant on this patch.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20241203/d63c1a7f/attachment.sig>