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
<[email protected]> 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 <[email protected]>
---
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/[email protected]/
Cheers,Quentin
