[PATCH 2/6] arm64: dts: rockchip: Add Radxa ROCK 2A/2F

[Yao Zi]

On Thu, Jul 10, 2025 at 01:56:02AM +0200, Jonas Karlman wrote:
> Hi,
> 
> On 7/9/2025 6:25 AM, Yao Zi wrote:
> > On Tue, Jul 08, 2025 at 10:48:52PM +0000, Jonas Karlman wrote:
> >> The ROCK 2A and ROCK 2F is a high-performance single board computer
> >> developed by Radxa, based on the Rockchip RK3528A SoC.
> >>
> >> Add initial device tree for the Radxa ROCK 2A and ROCK 2F boards.
> >>
> >> Signed-off-by: Jonas Karlman <jonas at kwiboo.se>
> >> ---
> >> Schematics:
> >> - https://dl.radxa.com/rock2/2a/v1.2/radxa_rock_2a_v1.2_schematic.pdf
> >> - https://dl.radxa.com/rock2/2f/radxa_rock2f_v1.01_schematic.pdf
> >> ---
> >>  arch/arm64/boot/dts/rockchip/Makefile         |   2 +
> >>  .../boot/dts/rockchip/rk3528-rock-2.dtsi      | 292 ++++++++++++++++++
> >>  .../boot/dts/rockchip/rk3528-rock-2a.dts      |  82 +++++
> >>  .../boot/dts/rockchip/rk3528-rock-2f.dts      |  10 +
> >>  4 files changed, 386 insertions(+)
> >>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi
> >>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts
> >>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts
> >  
> > While testing the patch on my Rock 2A board, I noticed one of my SDcard
> > that works perfectly on Radxa E20C and NanoPi Zero 2 cannot be correctly
> > read out under UHS-125-SDR mode,
> > 
> > 	# dd if=/dev/mmcblk1 of=/dev/null bs=4M count=4
> > 	[   18.616828] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
> > 	[   19.193315] mmc1: Skipping voltage switch
> > 	[   19.202046] mmc1: tried to HW reset card, got error -110
> > 	[   19.213312] mmcblk1: recovery failed!
> > 	[   19.213709] I/O error, dev mmcblk1, sector 0 op 0x0:(READ) flags 0x80700 phys_seg 256 prio class 0
> > 	[   19.225201] mmcblk1: recovery failed!
> > 	[   19.225530] I/O error, dev mmcblk1, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
> > 	[   19.226283] Buffer I/O error on dev mmcblk1, logical block 0, async page read
> > 	dd: /dev/mmcblk1: I/O error
> > 
> > which could be reproduced stably.
> > 
> > the SDMMC controller issued interesting messages during the tuning
> > process,
> > 
> > 	[    0.665246] mmc_host mmc1: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
> > 	[    0.851940] dwmmc_rockchip ffc30000.mmc: All phases work, using default phase 90.
> > 
> > but actually it doesn't work with phase = 90. If the frequency is
> > limited to 100MHz with max-frequency = <100000000> instead of the
> > default 150MHz, tuning results in a very different phase,
> > 
> > 	[    0.665483] mmc_host mmc1: Bus speed (slot 0) = 99600000Hz (slot req 100000000Hz, actual 99600000HZ div = 0)
> > 	[    1.166340] dwmmc_rockchip ffc30000.mmc: Successfully tuned phase to 141
> > 
> > and the card works, too. If I set rockchip,default-sample-phase to 141
> > in devicetree, the card could work at full 150MHz as well.
> > 
> > I think there's something wrong with the tuning process, or the board's
> > design cannot always run reliably at 150MHz.
> > 
> > Could you reproduce similar failures on Radxa 2A? If so, it may be
> > necessary to lower the SDMMC's maximum frequency for the board.
> 
> I have not been able to reproduce this issue on any of my ROCK 2A or 2F
> boards, my boards seem to tune phase to around 250-265 for the sd-cards
> I tested.
> 
> Could you try with something like this:
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi b/arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi
> index fc23c51836b15..a82791db55699 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi
> @@ -285,6 +285,10 @@
>  	status = "okay";
>  };
>  
> +&sdmmc_clk {
> +	rockchip,pins = <2 RK_PA5 1 &pcfg_pull_up_drv_level_3>;
> +};
> +
>  &uart0 {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&uart0m0_xfer>;
> 
> 
> Changing clk drive strength seem to be something that has been done in
> Radxa vendor kernel [1], could be something that we can include if it
> fixes your issue.

This seems to improve the situation a little, but doesn't solve the
issue. Among more than ten times of testing, the tuning process only
worked twice.

> The kernel I tested was built from [2].

I've tried this branch as well, but things don't improve.

Do you consider lower the clock-frequency acceptable?

> [1] https://github.com/radxa/kernel/commit/e9b33cbc97a902560d3f3b43b4d36a1a0ac68a50
> [2] https://github.com/Kwiboo/linux-rockchip/commits/next-20250708-rk3528-boards/
> 
> Regards,
> Jonas
> 
> > 
> > Regards,
> > Yao Zi
> 

Regards,
Yao Zi