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

[Jonas Karlman <jonas@kwiboo.se>]

On 7/10/2025 6:41 PM, Yao Zi wrote:
> 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@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?

Sure, I will include the max-frequency = <100000000> in a v2 shortly.

Regards,
Jonas

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