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. -- Tom
signature.asc
Description: PGP signature
