[PATCH v4 3/3] rockchip: spl: Add support for booting from UFS

[Quentin Schulz]

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.

>>> 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.

> 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 ;)

> 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 :)

> [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/

Cheers,Quentin