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

[Alexey Charkov]

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.

Best regards,
Alexey