Rockchip RK3576 can load its bootloader from UFS among other options, so this series adds the necessary bits and pieces to enable an end-to-end boot from UFS (boot ROM -> SPL -> U-boot proper -> kernel).
To achieve the above, this series goes through the following: - Patch 1 adjusts the existing SPL function for loading FIT images so that it doesn't try to immediately read an image fragment into its ultimate load address, as this causes trouble with a load address in a memory segment inaccessible by the storage device's DMA - Patch 2 introduces arch-independent code to enable SPL images to use UFS devices, including build system tweaks and a function to locate a U-boot image at a fixed UFS offset - Patch 3 adds device-reset functionality to the Rockchip UFS glue code, which is required for (at least some) UFS modules to respond to controller commands upon initial enumeration - Patch 4 ties it all together for Rockchip RK3576 This has been tested on a FriendlyElec NanoPi M5 board with a Biwin BWU3AKC46C256G UFS module. Note that booting directly from UFS masks the issue which patch 3 aims to address, because the boot ROM initializes the UFS module before handing over to U-boot. If, however, one boots SPL from FSPI1 with the same driver code, the module fails to respond unless patch 3 is applied. Patch 1 is necessary because at least on RK3576 the UFS controller cannot directly write the first section of the ATF image to its required load address (which happens to be in SRAM, not in system RAM). This is what the current spl_fit code tries to do unfortunately, leaving the UFS controller stuck in an error state. In this series I rely on the fact that all code paths in spl_fit which follow the initial load do either a memmove or a decompress operation, so the initial load address ultimately doesn't matter. I thus replace it with the Kconfig specified base load address unconditionally, on the assumption that this address is always accessible for writes. The memmove operation down the line then ensures that the CPU and not the DMA controller write the image to SRAM, which works. Note that in my experience none of the RK3576 boards actually boot current mainline U-boot versions without a single-word SRAM write before jumping to DDR initialization, as done in Kwiboo's commit at [1]. Therefore, to test this series I additionally applied commits ea2ebb491e2c..390668db9d13 from Kwiboo's rk3576 branch [2] (including ea2ebb491e2c), so any testers might want to: git cherry-pick a256b4182bd2..390668db9d13 from there before or after applying this series [1] https://source.denx.de/u-boot/contributors/kwiboo/u-boot/-/commit/390668db9d13b2cd0ac0077c15edb4b575ee28f9 [2] https://source.denx.de/u-boot/contributors/kwiboo/u-boot/-/commits/rk3576?ref_type=heads Signed-off-by: Alexey Charkov <[email protected]> --- Alexey Charkov (4): common/spl: fit: Avoid directly loading images to load_addr spl: Make UFS available for SPL builds ufs: rockchip: Add device reset support rockchip: spl: Add support for booting from UFS MAINTAINERS | 1 + arch/arm/dts/rk3576-u-boot.dtsi | 13 +++++++- arch/arm/include/asm/arch-rockchip/bootrom.h | 1 + arch/arm/include/asm/spl.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 ++++++++ common/spl/Kconfig | 16 +++++++++ common/spl/Makefile | 1 + common/spl/spl_fit.c | 6 +--- common/spl/spl_ufs.c | 49 ++++++++++++++++++++++++++++ drivers/Makefile | 1 + drivers/reset/Kconfig | 9 +++++ drivers/reset/Makefile | 2 +- drivers/scsi/Makefile | 3 ++ drivers/ufs/Kconfig | 1 + drivers/ufs/ufs-rockchip.c | 25 ++++++++++++++ drivers/ufs/ufs-rockchip.h | 1 + lib/Makefile | 1 + 19 files changed, 142 insertions(+), 7 deletions(-) --- base-commit: e09d04dae5aaef5cda6b648c9c0b8282fce05559 change-id: 20251210-rk3576-ufs-ac3bf4e87156 Best regards, -- Alexey Charkov <[email protected]>
