Hi Ilias, On Thu, 27 Mar 2025 at 15:19, Ilias Apalodimas <[email protected]> wrote: > > Hi Simon > > On Thu, 27 Mar 2025 at 15:33, Simon Glass <[email protected]> wrote: > > > > Hi Ilias, > > > > On Wed, 26 Mar 2025 at 02:37, Ilias Apalodimas > > <[email protected]> wrote: > > > > > > Hi Heinrich, > > > > > > On Mon, 24 Mar 2025 at 19:50, Heinrich Schuchardt <[email protected]> > > > wrote: > > > > > > > > On 17.03.25 14:38, Ilias Apalodimas wrote: > > > > > > > > %s/EFI_BOUNCE_BUFFER/CONFIG_EFI_LOADER_BOUNCE_BUFFER/ > > > > > > > > > The EFI subsystem defines its own bounce buffer for devices that > > > > > can't transfer data > 4GB. U-Boot already has a generic BOUNCE_BUFFER > > > > > which can be reused instead of defining another symbol. > > > > > The only limitation for EFI is that we don't know how big the file a > > > > > user > > > > > chooses to transfer is and as a result we can't depend on allocating > > > > > the > > > > > memory from the malloc area, which can prove too small. > > > > > > > > > > So allocate an EFI buffer of the correct size and pass it to the DM, > > > > > which already supports bounce buffering via > > > > > bounce_buffer_start_extalign() > > > > > > > > Looking at > > > > > > > > if (IS_ENABLED(CONFIG_BOUNCE_BUFFER) && desc->bb) { > > > > > > > > in drivers/block/blk-uclass.c the bounce buffer has to be explicitly > > > > enabled by the device driver. Only the scsi drivers sets bb = true. > > > > > > > > Cf. 81bd22e935dc ("rockchip: block: blk-uclass: add bounce buffer flag > > > > to blk_desc") > > > > > > > > Which device-drivers of the boards mentioned below do actually need > > > > bounce buffering? > > > > > > Unfortunately, I don't have any of the hardware to test and I havent > > > worked with that platform much. > > > That 'bb' variable and the fact that EFI needs bigger allocations is > > > why I ended up allocationg properly aligned memory from the EFI > > > subsystem. But as Mark pointed out, the cache flush is a no go for > > > now, so I'll drop this and see if I find time to rework the bounce > > > buffer logic overall > > > > There was quite a bit of discussion about all this in the context of > > my attempt to just add a message to warn the user[1] > > > > We might consider adding an event to reserve memory before relocation, > > along with a way to discover (in board_r) where the memory was > > allocated. That would make the solution more generic. > > I am not sure what you are trying to solve here. The EFI bounce buffer > after the LMB patches can't overwrite memory, nor can it be > overwritten.
I am thinking of we can create a single implementation of the bouncebuf logic which also works for EFI. I think the two sane things to do are: - restrict U-Boot to using memory below 4GB for platforms which have the DMA limitation - create (in board_f) a special region below 4GB for use with the bouncebuf logic > > Thanks > /Ilias > > > > > For the <4GB case we could perhaps add generic support for that in > > board_f, i.e. the ability to reserve a region for boards that need it. Regards, SImon > > [1] > > https://lore.kernel.org/u-boot/?q=%22Show+the+location+of+the+bounce+buffer+when+debugging%22
