Re: [PATCH v3 0/6] arm64: dts: rockchip: Add ROCK 2A/2F, Sige1 and NanoPi Zero2

Heiko Stübner
2025-07-15T20:21:48Z

Am Montag, 14. Juli 2025, 07:53:09 Mitteleuropäische Sommerzeit schrieb Alex Bee:
> Hi Jonas, Hi Yao,
>
> > Hi Alex,
> >
> > On 7/13/2025 10:56 PM, Alex Bee wrote:
> >> Hi Jonas,
> >>
> >>> Hi Alex,
> >>>
> >>> On 7/13/2025 9:13 PM, Alex Bee wrote:
> >>>> Hi list, Hi Jonas,
> >>>>
> >>>>> 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.
> > Not sure, possible due to lack of technical documentation for this SoC,
> > to my knowledge all upstream development has been done without any
> > access to a TRM for the SoC.
> Hhm, OK: Without any documentation, I'm seeing "RK3528A" silkscreened
> directly on the SoC package :)

So ... the TRM I meanwhile got, calls itself
"Rockchip RK3528A Technical Reference Manual"
in the title and
"RK3528A TRM (Part 1)"
on each page.

The one thing with an "A" I remember was the rk3066a. There even was
a rk3066b variant ... which was quite different, but I've never seen any
products using that variant.

So for the things to do:

- renaming devicetree _files_ later is no problem ... the given "guarantee"
is that the kernel is supposed to boot with an old devicetree blob, you
found in the attic ;-) . (if it follows established bindings)
- renaming compatibles is more difficult - and a lot of stuff already
calls itself rk3528 - without-a in a bunch of bindings.

So part of me just sees continuing without-a as the way to go, that
rk3518 mentioned below even has a different number ;-)

And wait until an actual rk3528 b-c-whatever variant needing different
stuff comes along.

Heiko

>
> > Based on vendor code (u-boot and linux) there does not seem to be
> > anything special about the A-variant, so my thinking has always been
> > that the A-variant may have just been an updated/fixed hw revision and
> > is the version that went into newer production devices.
> >
> > The recently released U-Boot 2025.07 is referencing the filename
> > rk3528-radxa-e20c.dtb from the synced devicetree-rebasing tree. So a
> > possible rename will affect a future release of U-Boot, and possible
> > devices in the field depending on when a rename would land in linux.
> >
> > For this series I tried to just follow what is currently used for the
> > Radxa E20C.
> >
> > If I am correct there is now also a RK3518 tvbox variant of this SoC,
> > do not know how that would fit into all this :-S
> Yeah, that's why I started comparing the features - and according to
> RK3518's datasheet it only has the features I mentioned in my first mail
> for RK3528A minus PCIe and the ability to connect an external ethernet phy
> to the gmac controller (it probably has only one). Well, it's version 1.0 of
> the datasheet ...
>
> Regards,
> Alex
>
> > Regards,
> > Jonas
> >
> >> Regards,
> >> Alex
> >>> 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.
> >>>
> >>>> 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
> >>>
> >>>> Regards,
> >>>> Alex
> >>>>> 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
> >>>>>
> >>>>> 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
> >>>>>
>