[PATCH v4 3/3] rockchip: spl: Add support for booting from UFS
Alexey Charkov
alchark at gmail.com
Fri Jan 16 15:29:38 CET 2026
On Fri, Jan 16, 2026 at 2:50 PM Quentin Schulz <quentin.schulz at cherry.de> wrote:
>
> Hi Alexey,
>
> On 1/16/26 11:08 AM, Alexey Charkov wrote:
> > Hi Quentin,
> >
> > On Wed, Jan 14, 2026 at 10:05 PM Quentin Schulz
> > <quentin.schulz at cherry.de> wrote:
> >>
> >> Hi Alexey,
> >>
> >> On 1/8/26 6:50 PM, Alexey Charkov wrote:
> >>> Add the required architecture-specific lookups to enable U-boot SPL to
> >>> load images from UFS storage devices on Rockchip RK3576, which has a
> >>> boot ROM capable of loading the SPL image from UFS.
> >>>
> >>> This also requires the DM_RESET framework to be available in SPL, as
> >>> the UFS driver uses it.
> >>
> >> If it is a hard dependency, why is it not specified as such in the
> >> symbol directly instead of relying on imply's at the ARCH level? This
> >> will also be "painful" once a new Rockchip SoC has UFS support as we'll
> >> need to forget not to add those imply.
> >
> > Fair enough, will convert it into a "select" under Rockchip UFS,
> > thanks for pointing it out!
> >
>
> Watch out for select, it may not be doing what you want, see
> https://www.kernel.org/doc/html/latest/kbuild/kconfig-language.html#menu-attributes
> at the notes in the select bullet item.
Ouch. Alright, thank you for pointing it out.
> >>> Signed-off-by: Alexey Charkov <alchark at gmail.com>
> >>> ---
> >>> arch/arm/dts/rk3576-u-boot.dtsi | 13 ++++++++++++-
> >>> arch/arm/include/asm/arch-rockchip/bootrom.h | 1 +
> >>> arch/arm/mach-rockchip/Kconfig | 3 +++
> >>> arch/arm/mach-rockchip/rk3576/rk3576.c | 1 +
> >>> arch/arm/mach-rockchip/spl-boot-order.c | 14 ++++++++++++++
> >>> drivers/reset/Kconfig | 9 +++++++++
> >>> drivers/reset/Makefile | 2 +-
> >>> 7 files changed, 41 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/arch/arm/dts/rk3576-u-boot.dtsi b/arch/arm/dts/rk3576-u-boot.dtsi
> >>> index dc3771b556a3..84d9f39fd407 100644
> >>> --- a/arch/arm/dts/rk3576-u-boot.dtsi
> >>> +++ b/arch/arm/dts/rk3576-u-boot.dtsi
> >>> @@ -12,7 +12,7 @@
> >>> };
> >>>
> >>> chosen {
> >>> - u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci;
> >>> + u-boot,spl-boot-order = "same-as-spl", &sdmmc, &sdhci, &ufshc;
> >>> };
> >>>
> >>> dmc {
> >>> @@ -81,6 +81,12 @@
> >>> bootph-some-ram;
> >>> };
> >>>
> >>> +&gpio4 {
> >>> + /* Used for resetting the UFS device during initialization */
> >>> + bootph-pre-ram;
> >>> + bootph-some-ram;
> >>> +};
> >>> +
> >>
> >> Is it always GPIO4 for the reset GPIO for UFS? Seems like something that
> >> should probably be put in a board -u-boot.dtsi instead?
> >
> > It is in fact always GPIO4 pin D0. It's multiplexed to a
>
> This is probably the typical Rockchip BS :) It is the "same" for SD CD
> or WP pins. They have a hardware-controlled mode for pin A which is
> usually a black box for SW (nothing to do, it "works"). But nothing
> prevents you from using another GPIO for that (just have to be careful
> about the voltage level I guess, here it seems to be 1.2V for the
> domain, which isn't that usual I guess.
I bet that the boot ROM might get picky there, and only work with
GPIO4_D0. But if the UFS chip is not meant to be used as the primary
boot device - sure, can't see why not. On the other hand, there's not
much direct gain for board designers from using a different pin, and
people tend to just stick with Rockchip reference schematics unless
something different is explicitly required for their design, so my
money is on "it will be GPIO4 for all RK3576 boards".
Extra consideration in the same stream: the pin itself is defined in
rk3576.dtsi upstream, not in board-specific .dts files.
> > somehow-hardware-controlled pin inconspicuously called UFS_RSTn within
> > VCCIO7_IOC_GPIOD_IOMUX_SEL_L, but I couldn't find how it's supposed to
> > operate in a hardware-controlled mode (it's not described in the TRM).
>
> I guess it automagically does stuff in the silicon when initializing (or
> doing a controller reset for example, don't know). Your guess is as good
> as mine :)
>
> > Mainline Linux does the same thing as I do here (GPIO mode [1]), while
> > Rockchip's own U-boot code switches the pin to the hardware-controlled
> > mode [2] and never touches anything about device resets from then on -
> > which feels like a potentially fragile black box to me. Hardware
>
> Yes, we've had our share of SD CD signal issues with the
> hardware-controlled one. I actually switched one of our devices to use
> GPIO instead (see
> https://elixir.bootlin.com/linux/v6.18.5/source/arch/arm64/boot/dts/rockchip/rk3588-tiger-haikou.dts#L272),
> so I understand not wanting to rely on that ;)
Indeed. Also Shawn's recent series for RK3576 to a similar effect [1]
[1] https://lore.kernel.org/linux-rockchip/1768524932-163929-1-git-send-email-shawn.lin@rock-chips.com/
> > controlled mode would also deviate from the upstream DT binding, as it
> > stipulates a GPIO for device resets [3].
> >
>
> Not asking for this, rather wondering if we should really have this at
> the SoC level rather than the board level. If it can be any GPIO why
> forcing all boards to have GPIO4 bank "enabled" in SPL + U-Boot proper
> before reloc. It isn't the first SoC to have that (also see all SoC
> u-boot.dtsi having the UART controller from the reference design
> "enabled"), and I don't think it's planned for us to have a product on
> it, so... not a blocker from my side :)
I believe that the boards which don't use UFS for early boot will just
compile it out, together with the respective GPIO code. Then the only
downside for them is a marginally larger SPL DTB - but not on a scale
that matters for RK3576. And those that use UFS for early boot will
likely want it to be on the pin expected by the boot ROM, then having
the prerequisites already defined makes life easier for them (and it's
not much different from having e.g. FSPI0/1 and eMMC enabled by
default even for boards that don't use them).
> > [1] https://github.com/torvalds/linux/blob/master/drivers/ufs/host/ufs-rockchip.c#L220-L231
> > [2] https://github.com/rockchip-linux/u-boot/blob/next-dev/drivers/ufs/ufs-rockchip.c#L222
> > [3] https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/ufs/rockchip%2Crk3576-ufshc.yaml#L53-L58
> >
> >>> &ioc_grf {
> >>> bootph-all;
> >>> };
> >>> @@ -176,6 +182,11 @@
> >>> bootph-pre-ram;
> >>> };
> >>>
> >>> +&ufshc {
> >>> + bootph-pre-ram;
> >>> + bootph-some-ram;
> >>> +};
> >>> +
> >>> &xin24m {
> >>> bootph-all;
> >>> };
> >>> diff --git a/arch/arm/include/asm/arch-rockchip/bootrom.h b/arch/arm/include/asm/arch-rockchip/bootrom.h
> >>> index b15938c021d6..f9ecb6858f04 100644
> >>> --- a/arch/arm/include/asm/arch-rockchip/bootrom.h
> >>> +++ b/arch/arm/include/asm/arch-rockchip/bootrom.h
> >>> @@ -51,6 +51,7 @@ enum {
> >>> BROM_BOOTSOURCE_SPINOR = 3,
> >>> BROM_BOOTSOURCE_SPINAND = 4,
> >>> BROM_BOOTSOURCE_SD = 5,
> >>> + BROM_BOOTSOURCE_UFS = 7,
> >>
> >> Hopefully this will be the same value for all upcoming SoCs with UFS
> >> (and not used for something else :) ).
> >
> > Well it's hard to guarantee (otherwise Jonas wouldn't have had to add
> > a translation function [4] for the IDs that changed in RK3576). Maybe
> > at some point we'll have to switch to a lookup table per each SoC
> > variant if these keep changing, but thankfully that point is not today
> > :)
> >
>
> See
> https://lore.kernel.org/devicetree-spec/ebc08400-c16d-4ed0-b487-9aabe13bbf0f@pengutronix.de/
Ooooh that sounds like a discussion that can potentially stretch out
for a long time. I'd much rather use a value that works for the only
chip where it matters now (RK3576), then solve the problem whenever it
arises (if it does). After all, bootrom.h is not ABI, and DT is, so it
is much easier to fix up bootrom.h without stepping on too many toes.
Furthermore, I'm not even sure that /chosen/bootsource can address the
issue here, because boot ROM's won't magically start passing DT
phandles to the bootloader, so there will still be an ID->node lookup
table somewhere in early code (with potentially per-SoC overrides).
Which is exactly what we have here.
Thanks a lot,
Alexey
More information about the U-Boot
mailing list