[PATCH v2 1/3] spl: Make UFS available for SPL builds

[Alexey Charkov]

On Mon, Jan 5, 2026 at 10:15 PM Alexey Charkov <alchark at gmail.com> wrote:
>
> Hi Tom, Neil,
>
> Your replies came pretty much simultaneously :)
>
> On Mon, Jan 5, 2026 at 7:18 PM Tom Rini <trini at konsulko.com> 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 <alchark at gmail.com>
> > [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 <neil.armstrong at linaro.org> 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.

Quick update. I can confirm that the following one-liner works just
fine instead of my open-coded version:

diff --git a/drivers/ufs/ufs-uclass.c b/drivers/ufs/ufs-uclass.c
index 3c8e4299259c..eb2882d35e03 100644
--- a/drivers/ufs/ufs-uclass.c
+++ b/drivers/ufs/ufs-uclass.c
@@ -2257,7 +2257,7 @@ static int ufs_scsi_buffer_aligned(struct
udevice *scsi_dev, struct bounce_buffe
                return 0;
        }
 #endif
-       return 1;
+       return (ulong)state->user_buffer >= CFG_SYS_SDRAM_BASE;
 }
 #endif /* CONFIG_BOUNCE_BUFFER */

Would anything of this sort be acceptable? Happy to adjust in v3.

I'm guessing that DMA reads to an address not in SDRAM is a niche
situation, so no one should be too upset about them going through a
bounce buffer. Furthermore, this block of code would currently only
apply to Rockchip RK3576 and Renesas gen4/gen5 by the virtue of
Kconfig dependencies.

Best regards,
Alexey