+Marek Vasut too Hi Heinrich,
On Fri, 9 Aug 2024 at 13:02, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > > > > Am 9. August 2024 20:36:35 MESZ schrieb Simon Glass <s...@chromium.org>: > >Hi Heinrich, > > > >On Fri, 9 Aug 2024 at 11:32, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > >> > >> On 01.08.24 19:36, Simon Glass wrote: > >> > The EFI_LOADER_BOUNCE_BUFFER feature was added many years ago. It is not > >> > clear whether it is still needed, but 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 detect the problem. > >> > > >> > Note: I avoided converting this #ifdef to use IS_ENABLED() since I hope > >> > that the feature may be removed. > >> > >> EFI_BLOCK_IO_PROTOCOL.ReadBlocks() and > >> EFI_BLOCK_IO_PROTOCOL.WriteBlocks() are expected to block until all > >> bytes are transferred. > >> > >> The complete file transfer is chunked according to the size of the EFI > >> bounce buffer. > >> > >> Taking care of alignment issues would best handled by the block uclass. > >> > >> When CONFIG_BOUNCE_BUFFER=y, bounce_buffer_start_extalign() uses > >> memalign() which limits the bounce buffer to available malloc() memory > >> (typically < 2 MiB). > >> > >> I cannot see how blk_read() with CONFIG_BOUNCE_BUFFER=y will work if > >> blkcnt * desc->blksz is greater than the available malloc memory. > > > >Yes, it uses malloc(). The maximum read length on MMC, for example, > >seems to default to 32MB, although it is only 128KB on a few > >platforms. > > > >I am thinking we should be allocating space in the bloblist to hold > >all these sorts of things...it can be as large as needed and we can > >allocate space for it during relocation. > > > >> > >> Shouldn't the block uclass support chunking? > > > >It only supports readling whole blocks, if that is what you mean. Are > >you suggesting changing the blk API, or something else? > > It supports reading multiple blocks. If not all blocks fit into the memory > that can be assigned via memalgn, the block layer coud separate the blocks > into chunks. This would replace the EFI bounce buffer. Ah OK, yes it could do that. Regards, Simon