Hi Tom, Neil, Your replies came pretty much simultaneously :)
On Mon, Jan 5, 2026 at 7:18 PM Tom Rini <[email protected]> wrote: > > On Mon, Jan 05, 2026 at 07:05:36PM +0400, Alexey Charkov wrote: > > > Add minimal infrastructure to build SPL images with support for UFS > > storage devices. This also pulls in SCSI support and charset functions, > > which are dependencies of the UFS code. > > > > With this, only a fixed offset is supported for loading the next image, > > which should be specified in CONFIG_SPL_UFS_RAW_U_BOOT_SECTOR as the > > number of 4096-byte sectors into the UFS block device. > > > > Signed-off-by: Alexey Charkov <[email protected]> > [snip] > > +config SPL_UFS_SUPPORT > > + bool "Support loading from UFS" > > + select SPL_LOAD_BLOCK > > + help > > + Enable support for UFS in SPL. This allows > > + use of UFS devices such as hard drives and flash drivers for > > + loading U-Boot. > > + > > +config SPL_UFS_BOUNCE_BUF > > + bool "Use a bounce buffer for UFS loading" > > + depends on SPL_UFS_SUPPORT > > + default y if ARCH_ROCKCHIP > > + help > > + On some platforms the UFS host controller may be unable to load all > > + image segments directly to their required memory locations (e.g. due > > + to DMA constraints). This option enables an interim bounce buffer in > > + system RAM to let such platforms boot directly from UFS, at a cost > > of > > + an additional memory move while loading the image. > > So, the full U-Boot rockchip UFS driver does not use the generic > BOUNCE_BUFFER mechanism. Is this because of memory constraints in SPL? > Second, can we not just re-use the generic bounce buffer code > (common/bouncebuf.c) ? Thanks. On Mon, Jan 5, 2026 at 7:22 PM Neil Armstrong <[email protected]> wrote: > Can't this be replaced by the SCSI bounce buffer ? Thanks for the pointers. Frankly, I've overlooked the existing generic functionality, being somewhat new to the codebase. It seems that the current UFSHC driver only deals with broken 64-bit addressing when deciding to use a generic bounce buffer, while the constraint in this case is that part of the FIT image containing the ATF wants to load itself not to system RAM, but to a PMU SRAM region, which is inaccessible to the UFSHC's DMA engine either due to security firewall settings (as Jonas Karlman proposed in his comments to v1 of this series) or some other reason. I guess I could add a per-variant override of the scsi_ops ->buffer_aligned() callback (which in turn gets propagated to blk_ops), checking if the requested buffer is above/below the start of RAM on Rockchip RK3576 specifically? Just wondering whether that would be considered an abuse of the interface, given that it's not really anything to do with alignment as the callback name implies. Best regards, Alexey
