.../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
This series adds dt-bindings and initial device tree for the following Rockchip RK3528A boards: - Radxa ROCK 2A/2F - ArmSoM Sige1 - FriendlyElec NanoPi Zero2 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 -- 2.49.0
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. 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. 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 >
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) 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 >> >
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. 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 >>>
On Sun, Jul 13, 2025 at 10:56:59PM +0200, 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. 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 :-( Regards, Yao Zi [1]: https://github.com/rockchip-linux/kernel, branch develop-5.10 > 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 > > > >
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: > > 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. > > 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 > > > 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 > > > > > > > _______________________________________________ > Linux-rockchip mailing list > Linux-rockchip@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-rockchip >
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. 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 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 >>>>
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 :) > 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 >>>>>
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 > >>>>> >
Am 15.07.25 um 20:56 schrieb Heiko Stübner: > 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. The issue I was seeing is that there actually *is* a variant called 'RK3528' which at least according to the latest datasheets slightly differs from 'RK3528A'. We are doing development based on 'RK3528A' and calling it 'rockchip,rk3528' which might make it hard to add the non-A-variant in future (unless we call it 'rockchip,the-actual-rk3528'). > > 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 >>>>>>> > > >
Hi, > The issue I was seeing is that there actually *is* a variant called > 'RK3528' which at least according to the latest datasheets slightly differs > from 'RK3528A'. We are doing development based on 'RK3528A' and calling it > 'rockchip,rk3528' which might make it hard to add the non-A-variant in > future (unless we call it 'rockchip,the-actual-rk3528'). I think this can be ignored, because rockchip only provides RK3528A chip. RK3528A should be a revised version of RK3528, which solves some bugs, so we have never seen the silk screen printed with RK3528. Thanks, Chukun -- 2.25.1
> Hi, > >> The issue I was seeing is that there actually *is* a variant called >> 'RK3528' which at least according to the latest datasheets slightly differs >> from 'RK3528A'. We are doing development based on 'RK3528A' and calling it >> 'rockchip,rk3528' which might make it hard to add the non-A-variant in >> future (unless we call it 'rockchip,the-actual-rk3528'). > I think this can be ignored, because rockchip only provides RK3528A chip. > RK3528A should be a revised version of RK3528, which solves some bugs, > so we have never seen the silk screen printed with RK3528. Thanks for sharing that inside. I wonder why there's an v1.4 of "Rockchip RK3528 Datasheet" dated 2024-05-12 which differs from v1.4 "Rockchip RK3528A Datasheet" dated 2025-05-12. Anyway: If everybody is happy as-is I guess it's fine. > Thanks, > Chukun > > -- > 2.25.1 >
> >> Hi, >> >>> The issue I was seeing is that there actually *is* a variant called >>> 'RK3528' which at least according to the latest datasheets slightly >>> differs >>> from 'RK3528A'. We are doing development based on 'RK3528A' and >>> calling it >>> 'rockchip,rk3528' which might make it hard to add the non-A-variant in >>> future (unless we call it 'rockchip,the-actual-rk3528'). >> I think this can be ignored, because rockchip only provides RK3528A >> chip. >> RK3528A should be a revised version of RK3528, which solves some bugs, >> so we have never seen the silk screen printed with RK3528. > Thanks for sharing that inside. > I wonder why there's an v1.4 of "Rockchip RK3528 Datasheet" dated > 2024-05-12 which differs from v1.4 "Rockchip RK3528A Datasheet" dated > 2025-05-12. Anyway: If everybody is happy as-is I guess it's fine. > Just for the record: There actually is a non-A version of the RK3528, which I actually own (but forgot about - perhaps my subconscious made me reply to this thread). It's on the Mango Pi MK28 board [0][1][2] - which, to my knowledge, is one of the first RK3528-based SBCs. [0] https://mangopi.org/m28k [1] https://x.com/mangopi_sbc/status/1729384633979322512 [2] https://pbs.twimg.com/ext_tw_video_thumb/1729382603202170880/pu/img/k-mVxtpl3ey4V3sX.jpg:large >> Thanks, >> Chukun >> >> -- >> 2.25.1 >>
Hi, > Just for the record: There actually is a non-A version of the > RK3528, which I actually own (but forgot about - perhaps my subconscious > made me reply to this thread). It's on the Mango Pi M28K board [0][1][2] - > which, to my knowledge, is one of the first RK3528-based SBCs. Thanks for sharing this. M28S is an engineering test board, and the official version was later renamed M28K. The MangoPi M28K board uses the RK3528A SoC. As for the M28S board, the silkscreen of SoC is indeed RK3528. [1] But then the interesting thing comes, uboot reports it is RK3528A: U-Boot 2025.07-rc1-OpenWrt-r30114-9b777547be (Jun 18 2025 - 18:35:23 +0000) Model: Generic RK3528 SoC: RK3528A DRAM: 2 GiB Core: 130 devices, 20 uclasses, devicetree: separate MMC: mmc@ffbf0000: 0, mmc@ffc30000: 1 Loading Environment from nowhere... OK In: serial@ff9f0000 Out: serial@ff9f0000 Err: serial@ff9f0000 Hit any key to stop autoboot: 0 [1] https://imgur.com/a/ddLsnmt Thanks, Chukun -- 2.25.1
Hi, > Hi, > >> Just for the record: There actually is a non-A version of the >> RK3528, which I actually own (but forgot about - perhaps my subconscious >> made me reply to this thread). It's on the Mango Pi M28K board [0][1][2] - >> which, to my knowledge, is one of the first RK3528-based SBCs. > Thanks for sharing this. M28S is an engineering test board, and the official > version was later renamed M28K. The MangoPi M28K board uses the RK3528A SoC. I'm not sure where you are getting your information from, but as I told before I actually *own* this board in the non-development version and it has an RK3528 SoC/silkscreen - I just was too lazy to photograph it my own - but I did now [0] [0] https://imgur.com/a/6jwx4dC > As for the M28S board, the silkscreen of SoC is indeed RK3528. [1] > But then the interesting thing comes, uboot reports it is RK3528A: > > U-Boot 2025.07-rc1-OpenWrt-r30114-9b777547be (Jun 18 2025 - 18:35:23 +0000) > > Model: Generic RK3528 > SoC: RK3528A > DRAM: 2 GiB > Core: 130 devices, 20 uclasses, devicetree: separate > MMC: mmc@ffbf0000: 0, mmc@ffc30000: 1 > Loading Environment from nowhere... OK > In: serial@ff9f0000 > Out: serial@ff9f0000 > Err: serial@ff9f0000 > Hit any key to stop autoboot: 0 > > [1] https://imgur.com/a/ddLsnmt > > Thanks, > Chukun > > -- > 2.25.1 >
Hi, > I'm not sure where you are getting your information from, but as I told > before I actually *own* this board in the non-development version and it > has an RK3528 SoC/silkscreen - I just was too lazy to photograph it my own > but I did now [0] I have the MangoPi M28S, M28K and M28C boards. The M28K board does have a silkscreen of RK3528A. [2] Regardless of whether the silkscreen is RK3528 or RK3528A, U-Boot reports that the SoC on these boards is RK3528A. (via OTP [1]) So one possibility is that Rockchip forgot to update the silkscreen. Comparison chip block diagram: 1. Earlier version: https://docs.armsom.org/img/sige/rk3528.png 2. Final version: https://docs.radxa.com/img/e/e20c/radxa-e20c-chip-diagram.webp The difference seems to be that RK3528 uses I2S while RK3528A uses SAI. But from the updated diagram here [3], RK3528 also uses the SAI interface. Rockchip BSP does not make any distinction between RK3528 and RK3528A, so it is meaningless to continue to worry about non-A versions. [1] https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-rockchip/rk3528/rk3528.c#L131 [2] https://x.com/mangopi_sbc/status/1847851624804602316?t=5hwScxgwCAAid0eCJgrP5w&s=19 [3] https://x.com/mangopi_sbc/status/1785115827437760769?t=H5PXRDwbjOfBYa7QotjIZw&s=19 -- 2.25.1
Am 21.07.25 um 16:00 schrieb Chukun Pan: > Hi, > >> I'm not sure where you are getting your information from, but as I told >> before I actually *own* this board in the non-development version and it >> has an RK3528 SoC/silkscreen - I just was too lazy to photograph it my own >> but I did now [0] > I have the MangoPi M28S, M28K and M28C boards. > The M28K board does have a silkscreen of RK3528A. [2] Nope. Are you really questioning my picture? Ridiculous ... see [0] > Regardless of whether the silkscreen is RK3528 or RK3528A, > U-Boot reports that the SoC on these boards is RK3528A. (via OTP [1]) > So one possibility is that Rockchip forgot to update the silkscreen. > > Comparison chip block diagram: > 1. Earlier version: https://docs.armsom.org/img/sige/rk3528.png > 2. Final version: https://docs.radxa.com/img/e/e20c/radxa-e20c-chip-diagram.webp > > The difference seems to be that RK3528 uses I2S while RK3528A uses SAI. > But from the updated diagram here [3], RK3528 also uses the SAI interface. > > Rockchip BSP does not make any distinction between RK3528 and RK3528A, > so it is meaningless to continue to worry about non-A versions. I'm sort of impressed on with which conviction you continue to claim plain wrong things: [1], [2], [3]. I'm fine if upstream decides not to care. But it is and remains wrong to claim that the other version does not exist - otherwise I doubt Rockchip would have gone to the trouble of building the distinction into their SDK AND publishing different datasheets. [0] https://wikidevi.wi-cat.ru/MangoPi_M28K [1] https://github.com/HermanChen/mpp/blob/develop/osal/mpp_soc.c#L957-L982 [2] https://github.com/rockchip-linux/kernel/blob/develop-6.1/drivers/soc/rockchip/rockchip-cpuinfo.c#L212-L218 [3] https://github.com/rockchip-linux/u-boot/commit/89e1f532de7747d2e962644330666fb1b465926b > [1] https://github.com/u-boot/u-boot/blob/master/arch/arm/mach-rockchip/rk3528/rk3528.c#L131 > [2] https://x.com/mangopi_sbc/status/1847851624804602316?t=5hwScxgwCAAid0eCJgrP5w&s=19 > [3] https://x.com/mangopi_sbc/status/1785115827437760769?t=H5PXRDwbjOfBYa7QotjIZw&s=19 > > -- > 2.25.1 >
Hi, > Nope. > > Are you really questioning my picture? Ridiculous ... see [0] No, I mean some boards of this model have SoC silkscreen RK3528 and others have RK3528A. The same is true for another Hinlink H28K SBC. > I'm sort of impressed on with which conviction you continue to claim > plain wrong things: [1], [2], [3]. If you spend a few minutes running mainline u-boot or BSP kernel on your RK3528 board before blaming me: BL31: INFO: rk_otp_init finish! INFO: RK3528 SoC (0x101) mainline u-boot: ------ U-Boot 2025.07-... Model: Generic RK3528 SoC: RK3528A ------ BSP kernel: [ 0.768514] rockchip-cpuinfo cpuinfo: SoC : 35281000 [ 0.768990] rockchip-cpuinfo cpuinfo: Serial : ... > I'm fine if upstream decides not to care. But it is and remains wrong > to claim that the other version does not exist Unless Rockchip says they fused the wrong OTP during production. Regardless of the SoC silkscreen, the chip type on OTP is the same, so how does Rockchip distinguish these chips? -- 2.25.1
> Hi, > >> Nope. >> >> Are you really questioning my picture? Ridiculous ... see [0] > No, I mean some boards of this model have SoC silkscreen RK3528 and > others have RK3528A. The same is true for another Hinlink H28K SBC. > >> I'm sort of impressed on with which conviction you continue to claim >> plain wrong things: [1], [2], [3]. > If you spend a few minutes running mainline u-boot or BSP kernel > on your RK3528 board before blaming me: I can't see the point here: I don't think it matters wether you or I actually have this version on any of our boards. It exists: you may like it or not. This picture was actually a reply to your claim "... so we have never seen the silk screen printed with RK3528 ... " in your mail dated 2025/07/19. Initially my only question was, why we don't use "rockchip,rk3528a" as compatible when working on boards where the silkscreens says exactly that. It was obviously copied from vendor and now it's "too late", "too complicated" or something, idk and I'm fine with it. > BL31: > INFO: rk_otp_init finish! > INFO: RK3528 SoC (0x101) > > mainline u-boot: > ------ > U-Boot 2025.07-... > > Model: Generic RK3528 > SoC: RK3528A > ------ > > BSP kernel: > [ 0.768514] rockchip-cpuinfo cpuinfo: SoC : 35281000 > [ 0.768990] rockchip-cpuinfo cpuinfo: Serial : ... > >> I'm fine if upstream decides not to care. But it is and remains wrong >> to claim that the other version does not exist > Unless Rockchip says they fused the wrong OTP during production. > Regardless of the SoC silkscreen, the chip type on OTP is the same, > so how does Rockchip distinguish these chips? Please read the rest of my previous reply where I sent code locations where and how they do. > > -- > 2.25.1 > >
On Sat, 12 Jul 2025 17:37:42 +0000, Jonas Karlman wrote: > This series adds dt-bindings and initial device tree for the following > Rockchip RK3528A boards: > - Radxa ROCK 2A/2F > - ArmSoM Sige1 > - FriendlyElec NanoPi Zero2 > > 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 > > -- > 2.49.0 > > > My bot found new DTB warnings on the .dts files added or changed in this series. Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings are fixed by another series. Ultimately, it is up to the platform maintainer whether these warnings are acceptable or not. No need to reply unless the platform maintainer has comments. If you already ran DT checks and didn't see these error(s), then make sure dt-schema is up to date: pip3 install dtschema --upgrade This patch series was applied (using b4) to base: Base: attempting to guess base-commit... Base: tags/v6.16-rc1-53-g96cbdfdd3ac2 (exact match) If this is not the correct base, please add 'base-commit' tag (or use b4 which does this automatically) New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/rockchip/' for 20250712173805.584586-1-jonas@kwiboo.se: arch/arm64/boot/dts/rockchip/rk3528-armsom-sige1.dtb: /soc/power-management@ff600000: failed to match any schema with compatible: ['rockchip,rk3528-pmu', 'syscon', 'simple-mfd'] arch/arm64/boot/dts/rockchip/rk3528-armsom-sige1.dtb: /soc/power-management@ff600000/power-controller: failed to match any schema with compatible: ['rockchip,rk3528-power-controller'] arch/arm64/boot/dts/rockchip/rk3528-armsom-sige1.dtb: gpu@ff700000 (rockchip,rk3528-mali): compatible: 'oneOf' conditional failed, one must be fixed: ['rockchip,rk3528-mali', 'arm,mali-450'] is too short 'allwinner,sun8i-a23-mali' was expected 'rockchip,rk3528-mali' is not one of ['allwinner,sun4i-a10-mali', 'allwinner,sun7i-a20-mali', 'allwinner,sun8i-h3-mali', 'allwinner,sun8i-r40-mali', 'allwinner,sun50i-a64-mali', 'rockchip,rk3036-mali', 'rockchip,rk3066-mali', 'rockchip,rk3128-mali', 'rockchip,rk3188-mali', 'rockchip,rk3228-mali', 'samsung,exynos4210-mali', 'st,stih410-mali', 'stericsson,db8500-mali', 'xlnx,zynqmp-mali'] 'rockchip,rk3528-mali' is not one of ['allwinner,sun50i-h5-mali', 'amlogic,meson8-mali', 'amlogic,meson8b-mali', 'amlogic,meson-gxbb-mali', 'amlogic,meson-gxl-mali', 'hisilicon,hi6220-mali', 'mediatek,mt7623-mali', 'rockchip,rk3328-mali'] 'allwinner,sun7i-a20-mali' was expected 'arm,mali-400' was expected from schema $id: http://devicetree.org/schemas/gpu/arm,mali-utgard.yaml# arch/arm64/boot/dts/rockchip/rk3528-armsom-sige1.dtb: /soc/gpu@ff700000: failed to match any schema with compatible: ['rockchip,rk3528-mali', 'arm,mali-450'] arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dtb: /soc/power-management@ff600000: failed to match any schema with compatible: ['rockchip,rk3528-pmu', 'syscon', 'simple-mfd'] arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dtb: /soc/power-management@ff600000/power-controller: failed to match any schema with compatible: ['rockchip,rk3528-power-controller'] arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dtb: gpu@ff700000 (rockchip,rk3528-mali): compatible: 'oneOf' conditional failed, one must be fixed: ['rockchip,rk3528-mali', 'arm,mali-450'] is too short 'allwinner,sun8i-a23-mali' was expected 'rockchip,rk3528-mali' is not one of ['allwinner,sun4i-a10-mali', 'allwinner,sun7i-a20-mali', 'allwinner,sun8i-h3-mali', 'allwinner,sun8i-r40-mali', 'allwinner,sun50i-a64-mali', 'rockchip,rk3036-mali', 'rockchip,rk3066-mali', 'rockchip,rk3128-mali', 'rockchip,rk3188-mali', 'rockchip,rk3228-mali', 'samsung,exynos4210-mali', 'st,stih410-mali', 'stericsson,db8500-mali', 'xlnx,zynqmp-mali'] 'rockchip,rk3528-mali' is not one of ['allwinner,sun50i-h5-mali', 'amlogic,meson8-mali', 'amlogic,meson8b-mali', 'amlogic,meson-gxbb-mali', 'amlogic,meson-gxl-mali', 'hisilicon,hi6220-mali', 'mediatek,mt7623-mali', 'rockchip,rk3328-mali'] 'allwinner,sun7i-a20-mali' was expected 'arm,mali-400' was expected from schema $id: http://devicetree.org/schemas/gpu/arm,mali-utgard.yaml# arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dtb: /soc/gpu@ff700000: failed to match any schema with compatible: ['rockchip,rk3528-mali', 'arm,mali-450'] arch/arm64/boot/dts/rockchip/rk3528-nanopi-zero2.dtb: /soc/power-management@ff600000: failed to match any schema with compatible: ['rockchip,rk3528-pmu', 'syscon', 'simple-mfd'] arch/arm64/boot/dts/rockchip/rk3528-nanopi-zero2.dtb: /soc/power-management@ff600000/power-controller: failed to match any schema with compatible: ['rockchip,rk3528-power-controller'] arch/arm64/boot/dts/rockchip/rk3528-nanopi-zero2.dtb: gpu@ff700000 (rockchip,rk3528-mali): compatible: 'oneOf' conditional failed, one must be fixed: ['rockchip,rk3528-mali', 'arm,mali-450'] is too short 'allwinner,sun8i-a23-mali' was expected 'rockchip,rk3528-mali' is not one of ['allwinner,sun4i-a10-mali', 'allwinner,sun7i-a20-mali', 'allwinner,sun8i-h3-mali', 'allwinner,sun8i-r40-mali', 'allwinner,sun50i-a64-mali', 'rockchip,rk3036-mali', 'rockchip,rk3066-mali', 'rockchip,rk3128-mali', 'rockchip,rk3188-mali', 'rockchip,rk3228-mali', 'samsung,exynos4210-mali', 'st,stih410-mali', 'stericsson,db8500-mali', 'xlnx,zynqmp-mali'] 'rockchip,rk3528-mali' is not one of ['allwinner,sun50i-h5-mali', 'amlogic,meson8-mali', 'amlogic,meson8b-mali', 'amlogic,meson-gxbb-mali', 'amlogic,meson-gxl-mali', 'hisilicon,hi6220-mali', 'mediatek,mt7623-mali', 'rockchip,rk3328-mali'] 'allwinner,sun7i-a20-mali' was expected 'arm,mali-400' was expected from schema $id: http://devicetree.org/schemas/gpu/arm,mali-utgard.yaml# arch/arm64/boot/dts/rockchip/rk3528-nanopi-zero2.dtb: /soc/gpu@ff700000: failed to match any schema with compatible: ['rockchip,rk3528-mali', 'arm,mali-450'] arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dtb: /soc/power-management@ff600000: failed to match any schema with compatible: ['rockchip,rk3528-pmu', 'syscon', 'simple-mfd'] arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dtb: /soc/power-management@ff600000/power-controller: failed to match any schema with compatible: ['rockchip,rk3528-power-controller'] arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dtb: gpu@ff700000 (rockchip,rk3528-mali): compatible: 'oneOf' conditional failed, one must be fixed: ['rockchip,rk3528-mali', 'arm,mali-450'] is too short 'allwinner,sun8i-a23-mali' was expected 'rockchip,rk3528-mali' is not one of ['allwinner,sun4i-a10-mali', 'allwinner,sun7i-a20-mali', 'allwinner,sun8i-h3-mali', 'allwinner,sun8i-r40-mali', 'allwinner,sun50i-a64-mali', 'rockchip,rk3036-mali', 'rockchip,rk3066-mali', 'rockchip,rk3128-mali', 'rockchip,rk3188-mali', 'rockchip,rk3228-mali', 'samsung,exynos4210-mali', 'st,stih410-mali', 'stericsson,db8500-mali', 'xlnx,zynqmp-mali'] 'rockchip,rk3528-mali' is not one of ['allwinner,sun50i-h5-mali', 'amlogic,meson8-mali', 'amlogic,meson8b-mali', 'amlogic,meson-gxbb-mali', 'amlogic,meson-gxl-mali', 'hisilicon,hi6220-mali', 'mediatek,mt7623-mali', 'rockchip,rk3328-mali'] 'allwinner,sun7i-a20-mali' was expected 'arm,mali-400' was expected from schema $id: http://devicetree.org/schemas/gpu/arm,mali-utgard.yaml# arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dtb: /soc/gpu@ff700000: failed to match any schema with compatible: ['rockchip,rk3528-mali', 'arm,mali-450']
© 2016 - 2025 Red Hat, Inc.