Hello,

+To: kever, as he may have some insight on the differences between
RK3528 and RK3528A.

On Monday, 14 July 2025 03:00:08 Central European Summer Time Yao Zi wrote:

On Sun, Jul 13, 2025 at 10:56:59PM +0200, Alex Bee wrote:

quoted

Hi Jonas,

quoted

Hi Alex,

On 7/13/2025 9:13 PM, Alex Bee wrote:

quoted

Hi list, Hi Jonas,

quoted

This series adds dt-bindings and initial device tree for the following
Rockchip RK3528A boards:
- Radxa ROCK 2A/2F
- ArmSoM Sige1
- FriendlyElec NanoPi Zero2

this only sub-related to this series: Is there any particular reason, why
we call the compatible "rockchip,rk3528" and not "rockchip,rk3528a"? From
what I can see all boards currently supported (and those in this series)
are having the RK3528A version of the SoC. I didn't follow the development
here, but there are differences - I did a quick compare of the datasheets
of those two SoC versions - it looks like RK3528 version has USB3-DRD
controller, while RK3528A has USB3 host-only controller. Also it seems to
have different video codec IPs and the DRAM controller additionally
supports LPDDR4X.

What datasheet versions did you check? I can only find:
- RK3528 Rev 1.0 (2023-05-22)
- RK3528A Rev 1.2 (2024-04-10)

I used

2023-07-12 Revision V1.0

which didn't include these features - which is interesting: Why would a
SoC vendor not try to sell all features in the first place :)

But I now double checked in

2025-05-12 Revision 1.4

and you are right: It appears there also for RK3528A.

The only difference I could now make out by comparing v1.4 of both versions
is the cipher engine: RK3528 additionally supports "SM2/SM3/SM4 cipher" -
but still it exists and additionally the different video codec (if mpp
userspace library is correct about that).

Anyway: My question was more about: Why didn't we choose the correct
compatible from the beginning? And of course the dts files would have to be
renamed if the compatible is changed, as they are named according to their
SoC-compatible.

Just like what Jonas said, I was not aware of any technical
documentation at the time of writing the basic devicetree, and even for
now the only datasheet I manage to find is the 2023 revision about
RK3528 without A suffix, so I didn't realize the difference between
RK3528 and RK3528A, but just followed the vendor code and devicetree[1],
where only RK3528 is mentioned :-(

I wouldn't be too worried about getting this wrong, the only set-in-
stone part of this is the name of the device tree for devices and the
compatible; we can still rename rk3528.dtsi to rk3528a.dtsi and shuffle
things around internally. Furthermore, if the only difference is
something that can be enumerated at runtime (e.g. if a different set
of supported features in the crypto accel is identifiable with some
config register bits initial value), then I don't think we need to
distinguish them at all.

As another data point, rkbin mentions "Add support for rk3528A" in the
changelog file `doc/release/RK3528_EN.md` for `rk3528_bl31_v1.15.elf`.

Someone could contrast and compare that BL31 binary with the v1.14 one
to see if they have any immediately obvious differences.

My personal guess for what happened here is that they switched
the packaging process after release to optimize supply, like what
happened with RK3568 -> RK3568B2, and the only change is some OTP
values to identify the chip variant. This would also explain why
everything we've seen on the market so far, at least to my knowledge,
has been RK3528A.

Kind regards,
Nicolas Frattaroli

Regards,
Yao Zi

[1]: https://github.com/rockchip-linux/kernel, branch develop-5.10

quoted

Regards,
Alex

quoted

And both list LPDDR4X support and the A-variant seem to list USB3-DRD
support, did you mix them up above?

I think these SoCs are similar to rk3228/rk3229, rk3228h/rk3328 and now
rk3528/rk3528a, in that only the second variant support VP9 decoding.

Use of rockchip,rk3528a compatible could be something to change,
could also be something that bootloader set at runtime, similar to
what it does for rk3288w.

quoted

I guess it would be good to discuss this before this series is merged,
because re-naming *.dts files after they have been in a release is somewhat
impossible.

I think renaming the device tree files is unnecessary, as there seem to
be very little difference. All boards I have come across are currently
RK3528A variants. How would we treat the Radxa E20C?, it is not named
rk3528-radxa-e20c.dtb, yet uses the A-variant.

For mainline U-Boot I have included printing out the SoC-variant,
however the compatible is not adjusted:

   Model: Radxa E20C
   SoC:   RK3528A
   DRAM:  2 GiB

Regards,
Jonas

quoted

Regards,
Alex

quoted

The bt/wifi_reg_on pins are described in the device tree using
rfkill-gpio nodes.

Changes in v3:
- Rename led nodes to led-0/led-1
- Remove pinctrl* props from sdio0
- Collect a-b tags

Changes in v2:
- Limit sdmmc max-frequency to 100 MHz on ROCK 2A/2F
- Drop clock-output-names prop from rtc node on Sige1 and NanoPi Zero2
- Drop regulator-boot-on from usb 2.0 host regulators on Sige1
- Add bluetooth and wifi nodes on Sige1
- Collect t-b tag for NanoPi Zero2

These boards can be booted from emmc or sd-card using the U-Boot 2025.07
generic-rk3528 target or work-in-progress patches for these boards [1].

For working bluetooth on ArmSoM Sige1 the patch "arm64: dts: rockchip:
Fix UART DMA support for RK3528" [2] is required.

[1] https://source.denx.de/u-boot/contributors/kwiboo/u-boot/-/commits/rk3528
[2] https://lore.kernel.org/r/20250709210831.3170458-1-jonas@kwiboo.se (local)

Jonas Karlman (6):
    dt-bindings: arm: rockchip: Add Radxa ROCK 2A/2F
    arm64: dts: rockchip: Add Radxa ROCK 2A/2F
    dt-bindings: arm: rockchip: Add ArmSoM Sige1
    arm64: dts: rockchip: Add ArmSoM Sige1
    dt-bindings: arm: rockchip: Add FriendlyElec NanoPi Zero2
    arm64: dts: rockchip: Add FriendlyElec NanoPi Zero2

   .../devicetree/bindings/arm/rockchip.yaml     |  17 +
   arch/arm64/boot/dts/rockchip/Makefile         |   4 +
   .../boot/dts/rockchip/rk3528-armsom-sige1.dts | 465 ++++++++++++++++++
   .../boot/dts/rockchip/rk3528-nanopi-zero2.dts | 340 +++++++++++++
   .../boot/dts/rockchip/rk3528-rock-2.dtsi      | 293 +++++++++++
   .../boot/dts/rockchip/rk3528-rock-2a.dts      |  82 +++
   .../boot/dts/rockchip/rk3528-rock-2f.dts      |  10 +
   7 files changed, 1211 insertions(+)
   create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-armsom-sige1.dts
   create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-nanopi-zero2.dts
   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

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip