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

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

[Jonas Karlman]

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

[PATCH v3 1/6] dt-bindings: arm: rockchip: Add Radxa ROCK 2A/2F

[Jonas Karlman]

The ROCK 2A and ROCK 2F is a high-performance single board computer
developed by Radxa, based on the Rockchip RK3528A SoC.

Add devicetree binding documentation for the Radxa ROCK 2A and ROCK 2F
boards.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
v3: Collect a-b tag
v2: No change
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 28db6bd6aa5b..c5690098f2ed 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -881,6 +881,13 @@ properties:
           - const: radxa,rock
           - const: rockchip,rk3188
 
+      - description: Radxa ROCK 2A/2F
+        items:
+          - enum:
+              - radxa,rock-2a
+              - radxa,rock-2f
+          - const: rockchip,rk3528
+
       - description: Radxa ROCK Pi 4A/A+/B/B+/C
         items:
           - enum:
-- 
2.49.0

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

[Jonas Karlman]

The ROCK 2A and ROCK 2F is a high-performance single board computer
developed by Radxa, based on the Rockchip RK3528A SoC.

Add initial device tree for the Radxa ROCK 2A and ROCK 2F boards.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
---
v3: Rename led nodes to led-0/led-1 (Chukun Pan)
v2: Limit sdmmc max-frequency to 100 MHz (Yao Zi)

Schematics:
- https://dl.radxa.com/rock2/2a/v1.2/radxa_rock_2a_v1.2_schematic.pdf
- https://dl.radxa.com/rock2/2f/radxa_rock2f_v1.01_schematic.pdf
---
 arch/arm64/boot/dts/rockchip/Makefile         |   2 +
 .../boot/dts/rockchip/rk3528-rock-2.dtsi      | 293 ++++++++++++++++++
 .../boot/dts/rockchip/rk3528-rock-2a.dts      |  82 +++++
 .../boot/dts/rockchip/rk3528-rock-2f.dts      |  10 +
 4 files changed, 387 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 099520962ffb..4cb6106b16f2 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -90,6 +90,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-rock-pi-n10.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-radxa-e20c.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-rock-2a.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-rock-2f.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3562-evb2-v10.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg-arc-d.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg-arc-s.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi b/arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi
new file mode 100644
index 000000000000..aedc7ee9ee46
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi
@@ -0,0 +1,293 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pwm/pwm.h>
+#include "rk3528.dtsi"
+
+/ {
+	aliases {
+		i2c1 = &i2c1;
+		mmc0 = &sdhci;
+		mmc1 = &sdmmc;
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:1500000n8";
+	};
+
+	adc-keys {
+		compatible = "adc-keys";
+		io-channels = <&saradc 0>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+		poll-interval = <100>;
+
+		button-maskrom {
+			label = "MASKROM";
+			linux,code = <KEY_SETUP>;
+			press-threshold-microvolt = <0>;
+		};
+	};
+
+	leds: leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&state_led_b>;
+
+		led-0 {
+			color = <LED_COLOR_ID_BLUE>;
+			default-state = "on";
+			function = LED_FUNCTION_HEARTBEAT;
+			gpios = <&gpio1 RK_PA3 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	vdd_0v9: regulator-0v9-vdd {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_0v9";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <900000>;
+		regulator-max-microvolt = <900000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_ddr: regulator-1v1-vcc-ddr {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_ddr";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1100000>;
+		regulator-max-microvolt = <1100000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_1v8: regulator-1v8-vcc {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v8";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vcc_3v3>;
+	};
+
+	vcc_3v3: regulator-3v3-vcc {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_3v3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_wifi: regulator-3v3-vcc-wifi {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpios = <&gpio4 RK_PA4 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_wifi_pwr>;
+		regulator-name = "vcc_wifi";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc_3v3>;
+	};
+
+	vcc5v0_sys: regulator-5v0-vcc-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+	};
+
+	vcc5v0_usb20: regulator-5v0-vcc-usb20 {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpios = <&gpio0 RK_PA1 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_host_en>;
+		regulator-name = "vcc5v0_usb20";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vccio_sd: regulator-vccio-sd {
+		compatible = "regulator-gpio";
+		gpios = <&gpio1 RK_PC1 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&sdmmc_vol_ctrl_h>;
+		regulator-name = "vccio_sd";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <3300000>;
+		states = <1800000 0x0>, <3300000 0x1>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vdd_arm: regulator-vdd-arm {
+		compatible = "pwm-regulator";
+		pwms = <&pwm1 0 5000 PWM_POLARITY_INVERTED>;
+		pwm-supply = <&vcc5v0_sys>;
+		regulator-name = "vdd_arm";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <746000>;
+		regulator-max-microvolt = <1201000>;
+		regulator-settling-time-up-us = <250>;
+	};
+
+	vdd_logic: regulator-vdd-logic {
+		compatible = "pwm-regulator";
+		pwms = <&pwm2 0 5000 PWM_POLARITY_INVERTED>;
+		pwm-supply = <&vcc5v0_sys>;
+		regulator-name = "vdd_logic";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <705000>;
+		regulator-max-microvolt = <1006000>;
+		regulator-settling-time-up-us = <250>;
+	};
+
+	rfkill {
+		compatible = "rfkill-gpio";
+		label = "rfkill-wlan";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_reg_on_h>;
+		radio-type = "wlan";
+		shutdown-gpios = <&gpio1 RK_PA6 GPIO_ACTIVE_HIGH>;
+	};
+};
+
+&cpu0 {
+	cpu-supply = <&vdd_arm>;
+};
+
+&cpu1 {
+	cpu-supply = <&vdd_arm>;
+};
+
+&cpu2 {
+	cpu-supply = <&vdd_arm>;
+};
+
+&cpu3 {
+	cpu-supply = <&vdd_arm>;
+};
+
+&gpu {
+	mali-supply = <&vdd_logic>;
+	status = "okay";
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1m0_xfer>;
+	status = "okay";
+
+	eeprom@50 {
+		compatible = "belling,bl24c16a", "atmel,24c16";
+		reg = <0x50>;
+		pagesize = <16>;
+		read-only;
+		vcc-supply = <&vcc_3v3>;
+	};
+};
+
+&pinctrl {
+	bluetooth {
+		bt_wake_host_h: bt-wake-host-h {
+			rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		host_wake_bt_h: host-wake-bt-h {
+			rockchip,pins = <1 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	leds {
+		state_led_b: state-led-b {
+			rockchip,pins = <1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	sdmmc {
+		sdmmc_vol_ctrl_h: sdmmc-vol-ctrl-h {
+			rockchip,pins = <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	usb {
+		usb_host_en: usb-host-en {
+			rockchip,pins = <0 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	wifi {
+		usb_wifi_pwr: usb-wifi-pwr {
+			rockchip,pins = <4 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		wifi_reg_on_h: wifi-reg-on-h {
+			rockchip,pins = <1 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		wifi_wake_host_h: wifi-wake-host-h {
+			rockchip,pins = <1 RK_PA7 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+};
+
+&pwm1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm1m0_pins>;
+	status = "okay";
+};
+
+&pwm2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm2m0_pins>;
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcc_1v8>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	cap-mmc-highspeed;
+	mmc-hs200-1_8v;
+	no-sd;
+	no-sdio;
+	non-removable;
+	vmmc-supply = <&vcc_3v3>;
+	vqmmc-supply = <&vcc_1v8>;
+	status = "okay";
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	disable-wp;
+	max-frequency = <100000000>;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc_3v3>;
+	vqmmc-supply = <&vccio_sd>;
+	status = "okay";
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0m0_xfer>;
+	status = "okay";
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts b/arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts
new file mode 100644
index 000000000000..c03ae1dd3456
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts
@@ -0,0 +1,82 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3528-rock-2.dtsi"
+
+/ {
+	model = "Radxa ROCK 2A";
+	compatible = "radxa,rock-2a", "rockchip,rk3528";
+
+	aliases {
+		ethernet0 = &gmac1;
+	};
+
+	vcc5v0_usb30_otg: regulator-5v0-vcc-usb30-otg {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpios = <&gpio1 RK_PC3 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_otg_en>;
+		regulator-name = "vcc5v0_usb30_otg";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+};
+
+&gmac1 {
+	clock_in_out = "output";
+	phy-handle = <&rgmii_phy>;
+	phy-mode = "rgmii-id";
+	phy-supply = <&vcc_3v3>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&rgmii_miim>, <&rgmii_tx_bus2>, <&rgmii_rx_bus2>,
+		    <&rgmii_rgmii_clk>, <&rgmii_rgmii_bus>;
+	status = "okay";
+};
+
+&leds {
+	pinctrl-names = "default";
+	pinctrl-0 = <&state_led_b>, <&sys_led_g>;
+
+	led-1 {
+		color = <LED_COLOR_ID_GREEN>;
+		default-state = "on";
+		function = LED_FUNCTION_STATUS;
+		gpios = <&gpio3 RK_PC1 GPIO_ACTIVE_LOW>;
+		linux,default-trigger = "default-on";
+	};
+};
+
+&mdio1 {
+	rgmii_phy: ethernet-phy@1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <0x1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&gmac1_rstn_l>;
+		reset-assert-us = <20000>;
+		reset-deassert-us = <100000>;
+		reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&pinctrl {
+	ethernet {
+		gmac1_rstn_l: gmac1-rstn-l {
+			rockchip,pins = <4 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	leds {
+		sys_led_g: sys-led-g {
+			rockchip,pins = <3 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	usb {
+		usb_otg_en: usb-otg-en {
+			rockchip,pins = <1 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts b/arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts
new file mode 100644
index 000000000000..3e2b9b685cb2
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3528-rock-2.dtsi"
+
+/ {
+	model = "Radxa ROCK 2F";
+	compatible = "radxa,rock-2f", "rockchip,rk3528";
+};
-- 
2.49.0

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

[Yao Zi]

On Sat, Jul 12, 2025 at 05:37:44PM +0000, Jonas Karlman wrote:
> The ROCK 2A and ROCK 2F is a high-performance single board computer
> developed by Radxa, based on the Rockchip RK3528A SoC.
> 
> Add initial device tree for the Radxa ROCK 2A and ROCK 2F boards.
> 
> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>

Tested on my Radxa 2A board, the SD card could be read out at 45MB/s,
the GbE port reaches 942Mbps with iperf, and the EEPROM could be read
out correctly. I also saw the heartbeat LED blinking,

Tested-by: Yao Zi <ziyao@disroot.org>

> ---
> v3: Rename led nodes to led-0/led-1 (Chukun Pan)
> v2: Limit sdmmc max-frequency to 100 MHz (Yao Zi)
> 
> Schematics:
> - https://dl.radxa.com/rock2/2a/v1.2/radxa_rock_2a_v1.2_schematic.pdf
> - https://dl.radxa.com/rock2/2f/radxa_rock2f_v1.01_schematic.pdf
> ---
>  arch/arm64/boot/dts/rockchip/Makefile         |   2 +
>  .../boot/dts/rockchip/rk3528-rock-2.dtsi      | 293 ++++++++++++++++++
>  .../boot/dts/rockchip/rk3528-rock-2a.dts      |  82 +++++
>  .../boot/dts/rockchip/rk3528-rock-2f.dts      |  10 +
>  4 files changed, 387 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts

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

[Nicolas Frattaroli]

Hi Jonas,

see comments in-line.

On Saturday, 12 July 2025 19:37:44 Central European Summer Time Jonas Karlman wrote:
> The ROCK 2A and ROCK 2F is a high-performance single board computer
> developed by Radxa, based on the Rockchip RK3528A SoC.
> 
> Add initial device tree for the Radxa ROCK 2A and ROCK 2F boards.
> 
> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
> ---
> v3: Rename led nodes to led-0/led-1 (Chukun Pan)
> v2: Limit sdmmc max-frequency to 100 MHz (Yao Zi)
> 
> Schematics:
> - https://dl.radxa.com/rock2/2a/v1.2/radxa_rock_2a_v1.2_schematic.pdf
> - https://dl.radxa.com/rock2/2f/radxa_rock2f_v1.01_schematic.pdf
> ---
>  arch/arm64/boot/dts/rockchip/Makefile         |   2 +
>  .../boot/dts/rockchip/rk3528-rock-2.dtsi      | 293 ++++++++++++++++++
>  .../boot/dts/rockchip/rk3528-rock-2a.dts      |  82 +++++
>  .../boot/dts/rockchip/rk3528-rock-2f.dts      |  10 +
>  4 files changed, 387 insertions(+)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts
> 
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index 099520962ffb..4cb6106b16f2 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -90,6 +90,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-rock-pi-n10.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-radxa-e20c.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-rock-2a.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-rock-2f.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3562-evb2-v10.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg-arc-d.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg-arc-s.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi b/arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi
> new file mode 100644
> index 000000000000..aedc7ee9ee46
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi
> [...]
> +
> +&pinctrl {
> +	bluetooth {
> +		bt_wake_host_h: bt-wake-host-h {
> +			rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>;
> +		};
> +
> +		host_wake_bt_h: host-wake-bt-h {
> +			rockchip,pins = <1 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	leds {
> +		state_led_b: state-led-b {
> +			rockchip,pins = <1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	sdmmc {
> +		sdmmc_vol_ctrl_h: sdmmc-vol-ctrl-h {
> +			rockchip,pins = <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	usb {
> +		usb_host_en: usb-host-en {
> +			rockchip,pins = <0 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	wifi {
> +		usb_wifi_pwr: usb-wifi-pwr {
> +			rockchip,pins = <4 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +
> +		wifi_reg_on_h: wifi-reg-on-h {
> +			rockchip,pins = <1 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;

I don't see an external pull-up or pull-down in the schematic. I'm not
sure what the recommended practice is; should we have a pull direction
set in the SoC's pin controller in these cases, or leave it floating?

> +		};
> +
> +		wifi_wake_host_h: wifi-wake-host-h {
> +			rockchip,pins = <1 RK_PA7 RK_FUNC_GPIO &pcfg_pull_down>;
> +		};
> +	};
> +};
> +
> +&pwm1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pwm1m0_pins>;
> +	status = "okay";
> +};
> +
> +&pwm2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pwm2m0_pins>;
> +	status = "okay";
> +};
> +
> +&saradc {
> +	vref-supply = <&vcc_1v8>;
> +	status = "okay";
> +};
> +
> +&sdhci {
> +	bus-width = <8>;
> +	cap-mmc-highspeed;
> +	mmc-hs200-1_8v;
> +	no-sd;
> +	no-sdio;
> +	non-removable;
> +	vmmc-supply = <&vcc_3v3>;
> +	vqmmc-supply = <&vcc_1v8>;
> +	status = "okay";
> +};
> +
> +&sdmmc {
> +	bus-width = <4>;
> +	cap-mmc-highspeed;
> +	cap-sd-highspeed;
> +	disable-wp;
> +	max-frequency = <100000000>;

Any reason why we reduce this from the 150000000 in the SoC .dtsi?
Using the frequency the SoC .dtsi uses seems to work for me on the
ROCK 2A:

  [    0.347556] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
  [    0.547362] mmc_host mmc1: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
  [    0.814405] dwmmc_rockchip ffc30000.mmc: Successfully tuned phase to 248
  [    0.815407] mmc1: new UHS-I speed SDR104 SDXC card at address aaaa
  [    0.817030] mmcblk1: mmc1:aaaa SH64G 59.5 GiB
  [    0.820943]  mmcblk1: p1 p2

> +	sd-uhs-sdr104;
> +	vmmc-supply = <&vcc_3v3>;
> +	vqmmc-supply = <&vccio_sd>;
> +	status = "okay";
> +};
> +
> +&uart0 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&uart0m0_xfer>;
> +	status = "okay";
> +};
> diff --git a/arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts b/arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts
> new file mode 100644
> index 000000000000..c03ae1dd3456
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts
> [...]
> +
> +&pinctrl {
> +	ethernet {
> +		gmac1_rstn_l: gmac1-rstn-l {
> +			rockchip,pins = <4 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;

Same concern as with wifi-reg-on-h, there's no external pull resistor
in the schematic.

> +		};
> +	};
> +
> +	leds {
> +		sys_led_g: sys-led-g {
> +			rockchip,pins = <3 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +
> +	usb {
> +		usb_otg_en: usb-otg-en {
> +			rockchip,pins = <1 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
> +};
> diff --git a/arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts b/arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts
> new file mode 100644
> index 000000000000..3e2b9b685cb2
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts
> @@ -0,0 +1,10 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include "rk3528-rock-2.dtsi"
> +
> +/ {
> +	model = "Radxa ROCK 2F";
> +	compatible = "radxa,rock-2f", "rockchip,rk3528";
> +};
> 

Other than the indicated comments,

Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

ensured the pinctrls were correct, checked that they correspond to the
GPIOs being used in the devices associated with them. Also checked the
rock 2a schematic to verify that the vccio_sd switching setup is
correct, i.e. that high is indeed 3.3V and low is 1.8V.

And:

Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>

test-booted on a ROCK 2A, tested that SD card shows up, made sure
ethernet works as well, also ensured that the adc key works.

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

[Jonas Karlman]

Hi Nicolas,

On 7/14/2025 11:44 AM, Nicolas Frattaroli wrote:
> Hi Jonas,
> 
> see comments in-line.
> 
> On Saturday, 12 July 2025 19:37:44 Central European Summer Time Jonas Karlman wrote:
>> The ROCK 2A and ROCK 2F is a high-performance single board computer
>> developed by Radxa, based on the Rockchip RK3528A SoC.
>>
>> Add initial device tree for the Radxa ROCK 2A and ROCK 2F boards.
>>
>> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
>> ---
>> v3: Rename led nodes to led-0/led-1 (Chukun Pan)
>> v2: Limit sdmmc max-frequency to 100 MHz (Yao Zi)
>>
>> Schematics:
>> - https://dl.radxa.com/rock2/2a/v1.2/radxa_rock_2a_v1.2_schematic.pdf
>> - https://dl.radxa.com/rock2/2f/radxa_rock2f_v1.01_schematic.pdf
>> ---
>>  arch/arm64/boot/dts/rockchip/Makefile         |   2 +
>>  .../boot/dts/rockchip/rk3528-rock-2.dtsi      | 293 ++++++++++++++++++
>>  .../boot/dts/rockchip/rk3528-rock-2a.dts      |  82 +++++
>>  .../boot/dts/rockchip/rk3528-rock-2f.dts      |  10 +
>>  4 files changed, 387 insertions(+)
>>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi
>>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts
>>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts
>>
>> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
>> index 099520962ffb..4cb6106b16f2 100644
>> --- a/arch/arm64/boot/dts/rockchip/Makefile
>> +++ b/arch/arm64/boot/dts/rockchip/Makefile
>> @@ -90,6 +90,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
>>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
>>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-rock-pi-n10.dtb
>>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-radxa-e20c.dtb
>> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-rock-2a.dtb
>> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-rock-2f.dtb
>>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3562-evb2-v10.dtb
>>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg-arc-d.dtb
>>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg-arc-s.dtb
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi b/arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi
>> new file mode 100644
>> index 000000000000..aedc7ee9ee46
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi
>> [...]
>> +
>> +&pinctrl {
>> +	bluetooth {
>> +		bt_wake_host_h: bt-wake-host-h {
>> +			rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>;
>> +		};
>> +
>> +		host_wake_bt_h: host-wake-bt-h {
>> +			rockchip,pins = <1 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
>> +		};
>> +	};
>> +
>> +	leds {
>> +		state_led_b: state-led-b {
>> +			rockchip,pins = <1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
>> +		};
>> +	};
>> +
>> +	sdmmc {
>> +		sdmmc_vol_ctrl_h: sdmmc-vol-ctrl-h {
>> +			rockchip,pins = <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
>> +		};
>> +	};
>> +
>> +	usb {
>> +		usb_host_en: usb-host-en {
>> +			rockchip,pins = <0 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
>> +		};
>> +	};
>> +
>> +	wifi {
>> +		usb_wifi_pwr: usb-wifi-pwr {
>> +			rockchip,pins = <4 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
>> +		};
>> +
>> +		wifi_reg_on_h: wifi-reg-on-h {
>> +			rockchip,pins = <1 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
> 
> I don't see an external pull-up or pull-down in the schematic. I'm not
> sure what the recommended practice is; should we have a pull direction
> set in the SoC's pin controller in these cases, or leave it floating?

This is at least what I have done for gpio output pins in the past, see
other defines for a wifi_reg_on_h in tree.

My (possible wrong) reasoning is that this pin is used as a gpio output
pin and the output value should determin high/low. For this perticiular
board the wifi_reg_on_h pin is referenced as shutdown-gpios in the
rfkill-gpio node, so when this is initialized the output value should be
set high/low and the internal pull value no longer has a real purpose.

Please correct me if my reasoning is wrong :-)

> 
>> +		};
>> +
>> +		wifi_wake_host_h: wifi-wake-host-h {
>> +			rockchip,pins = <1 RK_PA7 RK_FUNC_GPIO &pcfg_pull_down>;
>> +		};
>> +	};
>> +};
>> +
>> +&pwm1 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pwm1m0_pins>;
>> +	status = "okay";
>> +};
>> +
>> +&pwm2 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&pwm2m0_pins>;
>> +	status = "okay";
>> +};
>> +
>> +&saradc {
>> +	vref-supply = <&vcc_1v8>;
>> +	status = "okay";
>> +};
>> +
>> +&sdhci {
>> +	bus-width = <8>;
>> +	cap-mmc-highspeed;
>> +	mmc-hs200-1_8v;
>> +	no-sd;
>> +	no-sdio;
>> +	non-removable;
>> +	vmmc-supply = <&vcc_3v3>;
>> +	vqmmc-supply = <&vcc_1v8>;
>> +	status = "okay";
>> +};
>> +
>> +&sdmmc {
>> +	bus-width = <4>;
>> +	cap-mmc-highspeed;
>> +	cap-sd-highspeed;
>> +	disable-wp;
>> +	max-frequency = <100000000>;
> 
> Any reason why we reduce this from the 150000000 in the SoC .dtsi?

Please see v1 of this series, Yao Zi reported issues when 150 MHz was
usued with a SD-card that works with 150 MHz on the Radxa E20C.

Vendor kernel seem to change drive strenght of clk pin, but that did not
improve the situation, so I changed it to use a lower rate for now.

> Using the frequency the SoC .dtsi uses seems to work for me on the
> ROCK 2A:
> 
>   [    0.347556] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
>   [    0.547362] mmc_host mmc1: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
>   [    0.814405] dwmmc_rockchip ffc30000.mmc: Successfully tuned phase to 248
>   [    0.815407] mmc1: new UHS-I speed SDR104 SDXC card at address aaaa
>   [    0.817030] mmcblk1: mmc1:aaaa SH64G 59.5 GiB
>   [    0.820943]  mmcblk1: p1 p2

Using 150 MHz also worked with my 2A/3F boards and the two SD-cards I
could test.

> 
>> +	sd-uhs-sdr104;
>> +	vmmc-supply = <&vcc_3v3>;
>> +	vqmmc-supply = <&vccio_sd>;
>> +	status = "okay";
>> +};
>> +
>> +&uart0 {
>> +	pinctrl-names = "default";
>> +	pinctrl-0 = <&uart0m0_xfer>;
>> +	status = "okay";
>> +};
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts b/arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts
>> new file mode 100644
>> index 000000000000..c03ae1dd3456
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts
>> [...]
>> +
>> +&pinctrl {
>> +	ethernet {
>> +		gmac1_rstn_l: gmac1-rstn-l {
>> +			rockchip,pins = <4 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
> 
> Same concern as with wifi-reg-on-h, there's no external pull resistor
> in the schematic.

Same resoning as above, this pin is used as the Ethernet PHY reset-gpios
pin. Here the bootloader (U-Boot) will also configure this pin with a
gpio output value to trigger a PHY reset.

I can change these to pull-down as that seem to be the reset value for
these two pins, if I understand the schematic and PinOut correctly, if
you have a strong opinion on that these defines are wrong.

Regards,
Jonas

> 
>> +		};
>> +	};
>> +
>> +	leds {
>> +		sys_led_g: sys-led-g {
>> +			rockchip,pins = <3 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
>> +		};
>> +	};
>> +
>> +	usb {
>> +		usb_otg_en: usb-otg-en {
>> +			rockchip,pins = <1 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
>> +		};
>> +	};
>> +};
>> diff --git a/arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts b/arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts
>> new file mode 100644
>> index 000000000000..3e2b9b685cb2
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts
>> @@ -0,0 +1,10 @@
>> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
>> +
>> +/dts-v1/;
>> +
>> +#include "rk3528-rock-2.dtsi"
>> +
>> +/ {
>> +	model = "Radxa ROCK 2F";
>> +	compatible = "radxa,rock-2f", "rockchip,rk3528";
>> +};
>>
> 
> Other than the indicated comments,
> 
> Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> 
> ensured the pinctrls were correct, checked that they correspond to the
> GPIOs being used in the devices associated with them. Also checked the
> rock 2a schematic to verify that the vccio_sd switching setup is
> correct, i.e. that high is indeed 3.3V and low is 1.8V.
> 
> And:
> 
> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> 
> test-booted on a ROCK 2A, tested that SD card shows up, made sure
> ethernet works as well, also ensured that the adc key works.
> 
> 

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

[Nicolas Frattaroli]

Hi Jonas,

On Monday, 14 July 2025 12:49:24 Central European Summer Time Jonas Karlman wrote:
> Hi Nicolas,
> 
> On 7/14/2025 11:44 AM, Nicolas Frattaroli wrote:
> > Hi Jonas,
> > 
> > see comments in-line.
> > 
> > On Saturday, 12 July 2025 19:37:44 Central European Summer Time Jonas Karlman wrote:
> >> The ROCK 2A and ROCK 2F is a high-performance single board computer
> >> developed by Radxa, based on the Rockchip RK3528A SoC.
> >>
> >> Add initial device tree for the Radxa ROCK 2A and ROCK 2F boards.
> >>
> >> Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
> >> ---
> >> v3: Rename led nodes to led-0/led-1 (Chukun Pan)
> >> v2: Limit sdmmc max-frequency to 100 MHz (Yao Zi)
> >>
> >> Schematics:
> >> - https://dl.radxa.com/rock2/2a/v1.2/radxa_rock_2a_v1.2_schematic.pdf
> >> - https://dl.radxa.com/rock2/2f/radxa_rock2f_v1.01_schematic.pdf
> >> ---
> >>  arch/arm64/boot/dts/rockchip/Makefile         |   2 +
> >>  .../boot/dts/rockchip/rk3528-rock-2.dtsi      | 293 ++++++++++++++++++
> >>  .../boot/dts/rockchip/rk3528-rock-2a.dts      |  82 +++++
> >>  .../boot/dts/rockchip/rk3528-rock-2f.dts      |  10 +
> >>  4 files changed, 387 insertions(+)
> >>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi
> >>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts
> >>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts
> >>
> >> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> >> index 099520962ffb..4cb6106b16f2 100644
> >> --- a/arch/arm64/boot/dts/rockchip/Makefile
> >> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> >> @@ -90,6 +90,8 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
> >>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
> >>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-rock-pi-n10.dtb
> >>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-radxa-e20c.dtb
> >> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-rock-2a.dtb
> >> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-rock-2f.dtb
> >>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3562-evb2-v10.dtb
> >>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg-arc-d.dtb
> >>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3566-anbernic-rg-arc-s.dtb
> >> diff --git a/arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi b/arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi
> >> new file mode 100644
> >> index 000000000000..aedc7ee9ee46
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/rockchip/rk3528-rock-2.dtsi
> >> [...]
> >> +
> >> +&pinctrl {
> >> +	bluetooth {
> >> +		bt_wake_host_h: bt-wake-host-h {
> >> +			rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>;
> >> +		};
> >> +
> >> +		host_wake_bt_h: host-wake-bt-h {
> >> +			rockchip,pins = <1 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
> >> +		};
> >> +	};
> >> +
> >> +	leds {
> >> +		state_led_b: state-led-b {
> >> +			rockchip,pins = <1 RK_PA3 RK_FUNC_GPIO &pcfg_pull_none>;
> >> +		};
> >> +	};
> >> +
> >> +	sdmmc {
> >> +		sdmmc_vol_ctrl_h: sdmmc-vol-ctrl-h {
> >> +			rockchip,pins = <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
> >> +		};
> >> +	};
> >> +
> >> +	usb {
> >> +		usb_host_en: usb-host-en {
> >> +			rockchip,pins = <0 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
> >> +		};
> >> +	};
> >> +
> >> +	wifi {
> >> +		usb_wifi_pwr: usb-wifi-pwr {
> >> +			rockchip,pins = <4 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
> >> +		};
> >> +
> >> +		wifi_reg_on_h: wifi-reg-on-h {
> >> +			rockchip,pins = <1 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
> > 
> > I don't see an external pull-up or pull-down in the schematic. I'm not
> > sure what the recommended practice is; should we have a pull direction
> > set in the SoC's pin controller in these cases, or leave it floating?
> 
> This is at least what I have done for gpio output pins in the past, see
> other defines for a wifi_reg_on_h in tree.
> 
> My (possible wrong) reasoning is that this pin is used as a gpio output
> pin and the output value should determin high/low. For this perticiular
> board the wifi_reg_on_h pin is referenced as shutdown-gpios in the
> rfkill-gpio node, so when this is initialized the output value should be
> set high/low and the internal pull value no longer has a real purpose.
> 
> Please correct me if my reasoning is wrong :-)

Your explanation makes sense to me. I don't know which way is the right
way, but I assume setting pulls does indeed not do much because any
effect they'd have would already be way too late in the power cycle.

> 
> > 
> >> +		};
> >> +
> >> +		wifi_wake_host_h: wifi-wake-host-h {
> >> +			rockchip,pins = <1 RK_PA7 RK_FUNC_GPIO &pcfg_pull_down>;
> >> +		};
> >> +	};
> >> +};
> >> +
> >> +&pwm1 {
> >> +	pinctrl-names = "default";
> >> +	pinctrl-0 = <&pwm1m0_pins>;
> >> +	status = "okay";
> >> +};
> >> +
> >> +&pwm2 {
> >> +	pinctrl-names = "default";
> >> +	pinctrl-0 = <&pwm2m0_pins>;
> >> +	status = "okay";
> >> +};
> >> +
> >> +&saradc {
> >> +	vref-supply = <&vcc_1v8>;
> >> +	status = "okay";
> >> +};
> >> +
> >> +&sdhci {
> >> +	bus-width = <8>;
> >> +	cap-mmc-highspeed;
> >> +	mmc-hs200-1_8v;
> >> +	no-sd;
> >> +	no-sdio;
> >> +	non-removable;
> >> +	vmmc-supply = <&vcc_3v3>;
> >> +	vqmmc-supply = <&vcc_1v8>;
> >> +	status = "okay";
> >> +};
> >> +
> >> +&sdmmc {
> >> +	bus-width = <4>;
> >> +	cap-mmc-highspeed;
> >> +	cap-sd-highspeed;
> >> +	disable-wp;
> >> +	max-frequency = <100000000>;
> > 
> > Any reason why we reduce this from the 150000000 in the SoC .dtsi?
> 
> Please see v1 of this series, Yao Zi reported issues when 150 MHz was
> usued with a SD-card that works with 150 MHz on the Radxa E20C.
> 
> Vendor kernel seem to change drive strenght of clk pin, but that did not
> improve the situation, so I changed it to use a lower rate for now.

Oops, thanks for pointing this out. Yeah, that makes sense to me then.

> 
> > Using the frequency the SoC .dtsi uses seems to work for me on the
> > ROCK 2A:
> > 
> >   [    0.347556] mmc_host mmc1: Bus speed (slot 0) = 400000Hz (slot req 400000Hz, actual 400000HZ div = 0)
> >   [    0.547362] mmc_host mmc1: Bus speed (slot 0) = 148500000Hz (slot req 150000000Hz, actual 148500000HZ div = 0)
> >   [    0.814405] dwmmc_rockchip ffc30000.mmc: Successfully tuned phase to 248
> >   [    0.815407] mmc1: new UHS-I speed SDR104 SDXC card at address aaaa
> >   [    0.817030] mmcblk1: mmc1:aaaa SH64G 59.5 GiB
> >   [    0.820943]  mmcblk1: p1 p2
> 
> Using 150 MHz also worked with my 2A/3F boards and the two SD-cards I
> could test.
> 
> > 
> >> +	sd-uhs-sdr104;
> >> +	vmmc-supply = <&vcc_3v3>;
> >> +	vqmmc-supply = <&vccio_sd>;
> >> +	status = "okay";
> >> +};
> >> +
> >> +&uart0 {
> >> +	pinctrl-names = "default";
> >> +	pinctrl-0 = <&uart0m0_xfer>;
> >> +	status = "okay";
> >> +};
> >> diff --git a/arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts b/arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts
> >> new file mode 100644
> >> index 000000000000..c03ae1dd3456
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/rockchip/rk3528-rock-2a.dts
> >> [...]
> >> +
> >> +&pinctrl {
> >> +	ethernet {
> >> +		gmac1_rstn_l: gmac1-rstn-l {
> >> +			rockchip,pins = <4 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
> > 
> > Same concern as with wifi-reg-on-h, there's no external pull resistor
> > in the schematic.
> 
> Same resoning as above, this pin is used as the Ethernet PHY reset-gpios
> pin. Here the bootloader (U-Boot) will also configure this pin with a
> gpio output value to trigger a PHY reset.
> 
> I can change these to pull-down as that seem to be the reset value for
> these two pins, if I understand the schematic and PinOut correctly, if
> you have a strong opinion on that these defines are wrong.

I don't feel strongly about the pinctrl at all, I think your explanation
that U-Boot got there before us puts a nail in the coffin of whether
they should be set at all; if anything, we'd probably make the device
even less happy by needlessly toggling the reset again with a pull
before it then gets toggled again by the Linux driver.

Everything looks good to me with those questions of mine cleared up,
thanks for working on this!

Kind regards,
Nicolas Frattaroli

> 
> Regards,
> Jonas
> 
> > 
> >> +		};
> >> +	};
> >> +
> >> +	leds {
> >> +		sys_led_g: sys-led-g {
> >> +			rockchip,pins = <3 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
> >> +		};
> >> +	};
> >> +
> >> +	usb {
> >> +		usb_otg_en: usb-otg-en {
> >> +			rockchip,pins = <1 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
> >> +		};
> >> +	};
> >> +};
> >> diff --git a/arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts b/arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts
> >> new file mode 100644
> >> index 000000000000..3e2b9b685cb2
> >> --- /dev/null
> >> +++ b/arch/arm64/boot/dts/rockchip/rk3528-rock-2f.dts
> >> @@ -0,0 +1,10 @@
> >> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> >> +
> >> +/dts-v1/;
> >> +
> >> +#include "rk3528-rock-2.dtsi"
> >> +
> >> +/ {
> >> +	model = "Radxa ROCK 2F";
> >> +	compatible = "radxa,rock-2f", "rockchip,rk3528";
> >> +};
> >>
> > 
> > Other than the indicated comments,
> > 
> > Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > 
> > ensured the pinctrls were correct, checked that they correspond to the
> > GPIOs being used in the devices associated with them. Also checked the
> > rock 2a schematic to verify that the vccio_sd switching setup is
> > correct, i.e. that high is indeed 3.3V and low is 1.8V.
> > 
> > And:
> > 
> > Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > 
> > test-booted on a ROCK 2A, tested that SD card shows up, made sure
> > ethernet works as well, also ensured that the adc key works.
> > 
> > 
> 
> 

[PATCH v3 3/6] dt-bindings: arm: rockchip: Add ArmSoM Sige1

[Jonas Karlman]

The Sige1 is a single board computer developed by ArmSoM, based on the
Rockchip RK3528A SoC.

Add devicetree binding documentation for the ArmSoM Sige1 board.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
v3: Collect a-b tag
v2: No change
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index c5690098f2ed..43f6403ecad6 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -54,6 +54,11 @@ properties:
           - const: ariaboard,photonicat
           - const: rockchip,rk3568
 
+      - description: ArmSoM Sige1 board
+        items:
+          - const: armsom,sige1
+          - const: rockchip,rk3528
+
       - description: ArmSoM Sige5 board
         items:
           - const: armsom,sige5
-- 
2.49.0

[PATCH v3 4/6] arm64: dts: rockchip: Add ArmSoM Sige1

[Jonas Karlman]

The Sige1 is a single board computer developed by ArmSoM, based on the
Rockchip RK3528A SoC.

Add initial device tree for the ArmSoM Sige1 board.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
---
Changes in v3:
- Rename led nodes to led-0/led-1 (Chukun Pan)
- Remove pinctrl* props from sdio0 (Chukun Pan)

Changes in v2:
- Drop regulator-boot-on from usb 2.0 host regulators (Chukun Pan)
- Change rfkill to sdio-pwrseq (Chukun Pan)
- Drop clock-output-names prop from rtc node (Chukun Pan)
- Add bluetooth and wifi nodes (Chukun Pan)
- Enable use of DMA for bluetooth on uart2

Schematics: https://drive.google.com/drive/folders/15uvc2lcOAKP0enXezASUhVFLuzkq3IEX
---
 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../boot/dts/rockchip/rk3528-armsom-sige1.dts | 465 ++++++++++++++++++
 2 files changed, 466 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-armsom-sige1.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 4cb6106b16f2..206fb8572cf7 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -89,6 +89,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64-screen.dtbo
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-rock-pi-n10.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-armsom-sige1.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-radxa-e20c.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-rock-2a.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-rock-2f.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3528-armsom-sige1.dts b/arch/arm64/boot/dts/rockchip/rk3528-armsom-sige1.dts
new file mode 100644
index 000000000000..8ff0dff5b606
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3528-armsom-sige1.dts
@@ -0,0 +1,465 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pwm/pwm.h>
+#include "rk3528.dtsi"
+
+/ {
+	model = "ArmSoM Sige1";
+	compatible = "armsom,sige1", "rockchip,rk3528";
+
+	aliases {
+		ethernet0 = &gmac1;
+		i2c0 = &i2c0;
+		mmc0 = &sdhci;
+		mmc1 = &sdmmc;
+		mmc2 = &sdio0;
+		serial0 = &uart0;
+		serial2 = &uart2;
+	};
+
+	chosen {
+		stdout-path = "serial0:1500000n8";
+	};
+
+	adc-keys {
+		compatible = "adc-keys";
+		io-channels = <&saradc 0>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+		poll-interval = <100>;
+
+		button-maskrom {
+			label = "MASKROM";
+			linux,code = <KEY_SETUP>;
+			press-threshold-microvolt = <0>;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&g_led>, <&r_led>;
+
+		led-0 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "on";
+			function = LED_FUNCTION_HEARTBEAT;
+			gpios = <&gpio3 RK_PB3 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+		};
+
+		led-1 {
+			color = <LED_COLOR_ID_RED>;
+			default-state = "on";
+			function = LED_FUNCTION_STATUS;
+			gpios = <&gpio3 RK_PB2 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "default-on";
+		};
+	};
+
+	vcc0v6_ddr: regulator-0v6-vcc-ddr {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc0v6_ddr";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <600000>;
+		regulator-max-microvolt = <600000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vdd_0v9: regulator-0v9-vdd {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_0v9";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <900000>;
+		regulator-max-microvolt = <900000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_ddr: regulator-1v1-vcc-ddr {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_ddr";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1100000>;
+		regulator-max-microvolt = <1100000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_1v8: regulator-1v8-vcc {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v8";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vcc_3v3>;
+	};
+
+	vcc1v8_ddr: regulator-1v8-vcc-ddr {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc1v8_ddr";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_3v3: regulator-3v3-vcc {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_3v3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc_dcin>;
+	};
+
+	vcc3v3_sd: regulator-3v3-vcc-sd {
+		compatible = "regulator-fixed";
+		gpios = <&gpio4 RK_PA1 GPIO_ACTIVE_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&sdmmc_pwren_l>;
+		regulator-name = "vcc3v3_sd";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc_3v3>;
+	};
+
+	vcc5v0_sys: regulator-5v0-vcc-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc_dcin>;
+	};
+
+	vcc5v0_usb1_host: regulator-5v0-vcc-usb1-host {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpios = <&gpio4 RK_PB1 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb20_host1_drv_h>;
+		regulator-name = "vcc5v0_usb1_host";
+		regulator-always-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_usb2_host: regulator-5v0-vcc-usb2-host {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpios = <&gpio4 RK_PB0 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb20_host2_drv_h>;
+		regulator-name = "vcc5v0_usb2_host";
+		regulator-always-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc5v0_usb_otg: regulator-5v0-vcc-usb-otg {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpios = <&gpio1 RK_PB4 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb20_otg0_drv_h>;
+		regulator-name = "vcc5v0_usb_otg";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_dcin: regulator-vcc-dcin {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_dcin";
+		regulator-always-on;
+		regulator-boot-on;
+	};
+
+	vccio_sd: regulator-vccio-sd {
+		compatible = "regulator-gpio";
+		gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&sdmmc_vol_ctrl_h>;
+		regulator-name = "vccio_sd";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <3300000>;
+		states = <1800000 0x0>, <3300000 0x1>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vdd_arm: regulator-vdd-arm {
+		compatible = "pwm-regulator";
+		pwms = <&pwm3 0 5000 PWM_POLARITY_INVERTED>;
+		pwm-supply = <&vcc5v0_sys>;
+		regulator-name = "vdd_arm";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <746000>;
+		regulator-max-microvolt = <1201000>;
+		regulator-settling-time-up-us = <250>;
+	};
+
+	vdd_logic: regulator-vdd-logic {
+		compatible = "pwm-regulator";
+		pwms = <&pwm2 0 5000 PWM_POLARITY_INVERTED>;
+		pwm-supply = <&vcc5v0_sys>;
+		regulator-name = "vdd_logic";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <705000>;
+		regulator-max-microvolt = <1006000>;
+		regulator-settling-time-up-us = <250>;
+	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_reg_on_h>, <&clkm1_32k_out>;
+		post-power-on-delay-ms = <200>;
+		reset-gpios = <&gpio1 RK_PA6 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&cpu0 {
+	cpu-supply = <&vdd_arm>;
+};
+
+&cpu1 {
+	cpu-supply = <&vdd_arm>;
+};
+
+&cpu2 {
+	cpu-supply = <&vdd_arm>;
+};
+
+&cpu3 {
+	cpu-supply = <&vdd_arm>;
+};
+
+&gmac1 {
+	clock_in_out = "output";
+	phy-handle = <&rgmii_phy>;
+	phy-mode = "rgmii-id";
+	phy-supply = <&vcc_3v3>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&rgmii_miim>, <&rgmii_tx_bus2>, <&rgmii_rx_bus2>,
+		    <&rgmii_rgmii_clk>, <&rgmii_rgmii_bus>;
+	status = "okay";
+};
+
+&gpu {
+	mali-supply = <&vdd_logic>;
+	status = "okay";
+};
+
+&i2c0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c0m0_xfer>;
+	status = "okay";
+
+	hym8563: rtc@51 {
+		compatible = "haoyu,hym8563";
+		reg = <0x51>;
+		#clock-cells = <0>;
+		interrupt-parent = <&gpio4>;
+		interrupts = <RK_PA0 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&rtc_int_l>;
+		wakeup-source;
+	};
+};
+
+&mdio1 {
+	rgmii_phy: ethernet-phy@1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <0x1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&gmac1_rstn_l>;
+		reset-assert-us = <20000>;
+		reset-deassert-us = <100000>;
+		reset-gpios = <&gpio4 RK_PB5 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&pinctrl {
+	bluetooth {
+		bt_reg_on_h: bt-reg-on-h {
+			rockchip,pins = <1 RK_PC1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		bt_wake_host_h: bt-wake-host-h {
+			rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		host_wake_bt_h: host-wake-bt-h {
+			rockchip,pins = <3 RK_PC3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	ethernet {
+		gmac1_rstn_l: gmac1-rstn-l {
+			rockchip,pins = <4 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	leds {
+		g_led: g-led {
+			rockchip,pins = <3 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		r_led: r-led {
+			rockchip,pins = <3 RK_PB2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	rtc {
+		rtc_int_l: rtc-int-l {
+			rockchip,pins = <4 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	sdmmc {
+		sdmmc_vol_ctrl_h: sdmmc-vol-ctrl-h {
+			rockchip,pins = <4 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		sdmmc_pwren_l: sdmmc-pwren-l {
+			rockchip,pins = <4 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	usb {
+		usb20_host1_drv_h: usb20-host1-drv-h {
+			rockchip,pins = <4 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		usb20_host2_drv_h: usb20-host2-drv-h {
+			rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		usb20_otg0_drv_h: usb20-otg0-drv-h {
+			rockchip,pins = <1 RK_PB4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	wifi {
+		wifi_reg_on_h: wifi-reg-on-h {
+			rockchip,pins = <1 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		wifi_wake_host_h: wifi-wake-host-h {
+			rockchip,pins = <1 RK_PA7 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+};
+
+&pwm2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm2m0_pins>;
+	status = "okay";
+};
+
+&pwm3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm3m0_pins>;
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcc_1v8>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	cap-mmc-highspeed;
+	mmc-hs200-1_8v;
+	no-sd;
+	no-sdio;
+	non-removable;
+	vmmc-supply = <&vcc_3v3>;
+	vqmmc-supply = <&vcc_1v8>;
+	status = "okay";
+};
+
+&sdio0 {
+	bus-width = <4>;
+	cap-sd-highspeed;
+	cap-sdio-irq;
+	disable-wp;
+	keep-power-in-suspend;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	no-mmc;
+	no-sd;
+	non-removable;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc_3v3>;
+	vqmmc-supply = <&vcc_1v8>;
+	#address-cells = <1>;
+	#size-cells = <0>;
+	status = "okay";
+
+	wifi@1 {
+		compatible = "brcm,bcm4329-fmac";
+		reg = <1>;
+		clocks = <&cru CLK_DEEPSLOW>;
+		clock-names = "lpo";
+		interrupt-parent = <&gpio1>;
+		interrupts = <RK_PA7 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "host-wake";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_wake_host_h>;
+	};
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	disable-wp;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc3v3_sd>;
+	vqmmc-supply = <&vccio_sd>;
+	status = "okay";
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0m0_xfer>;
+	status = "okay";
+};
+
+&uart2 {
+	dma-names = "tx", "rx";
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart2m1_xfer>, <&uart2m1_ctsn>, <&uart2m1_rtsn>;
+	uart-has-rtscts;
+	status = "okay";
+
+	bluetooth {
+		compatible = "brcm,bcm43438-bt";
+		clocks = <&cru CLK_DEEPSLOW>;
+		clock-names = "lpo";
+		device-wakeup-gpios = <&gpio3 RK_PC3 GPIO_ACTIVE_HIGH>;
+		interrupt-parent = <&gpio1>;
+		interrupts = <RK_PC2 IRQ_TYPE_LEVEL_HIGH>;
+		interrupt-names = "host-wakeup";
+		pinctrl-names = "default";
+		pinctrl-0 = <&bt_reg_on_h>, <&bt_wake_host_h>, <&host_wake_bt_h>;
+		shutdown-gpios = <&gpio1 RK_PC1 GPIO_ACTIVE_HIGH>;
+		vbat-supply = <&vcc_3v3>;
+		vddio-supply = <&vcc_1v8>;
+	};
+};
-- 
2.49.0

Re: [PATCH v3 4/6] arm64: dts: rockchip: Add ArmSoM Sige1

[Chukun Pan]

Hi,

> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3528-armsom-sige1.dts
> ...
> +&sdio0 {
> +	bus-width = <4>;
> +	cap-sd-highspeed;
> +	cap-sdio-irq;
> +	disable-wp;

I don't think sdio needs disable-wp?

Thanks,
Chukun

--
2.25.1

Re: [PATCH v3 4/6] arm64: dts: rockchip: Add ArmSoM Sige1

[Jonas Karlman]

Hi Chukun,

On 7/15/2025 4:01 PM, Chukun Pan wrote:
> Hi,
> 
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/rockchip/rk3528-armsom-sige1.dts
>> ...
>> +&sdio0 {
>> +	bus-width = <4>;
>> +	cap-sd-highspeed;
>> +	cap-sdio-irq;
>> +	disable-wp;
> 
> I don't think sdio needs disable-wp?

I thinks your are correct:

  disable-wp:
    $ref: /schemas/types.yaml#/definitions/flag
    description:
      When set, no physical write-protect line is present. This
      property should only be specified when the controller has a
      dedicated write-protect detection logic. If a GPIO is always used
      for the write-protect detection logic, it is sufficient to not
      specify the wp-gpios property in the absence of a write-protect
      line. Not used in combination with eMMC or SDIO.

It mention 'not used in combination with eMMC or SDIO', yet I see
multiple boards where disable-wp is currently used with eMMC and SDIO.

Do you have anything else to remark before I send a v4 with this prop
removed?

Regards,
Jonas

> 
> Thanks,
> Chukun
> 
> --
> 2.25.1
> 

Re: [PATCH v3 4/6] arm64: dts: rockchip: Add ArmSoM Sige1

[Chukun Pan]

Hi,

> It mention 'not used in combination with eMMC or SDIO', yet I see
> multiple boards where disable-wp is currently used with eMMC and SDIO.

This seems to be a DT bug introduced from the bsp kernel.

> Do you have anything else to remark before I send a v4 with this prop
> removed?

No further questions, thanks for your work.

Thanks,
Chukun

--
2.25.1

[PATCH v3 5/6] dt-bindings: arm: rockchip: Add FriendlyElec NanoPi Zero2

[Jonas Karlman]

The NanoPi Zero2 is small single board computer developed by
FriendlyElec, based on the Rockchip RK3528A SoC.

Add devicetree binding documentation for the FriendlyElec NanoPi Zero2
board.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
---
v3: Collect a-b tag
v2: No change
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 43f6403ecad6..e3d3d483de4a 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -325,6 +325,11 @@ properties:
               - friendlyarm,nanopi-r6s
           - const: rockchip,rk3588s
 
+      - description: FriendlyElec NanoPi Zero2
+        items:
+          - const: friendlyarm,nanopi-zero2
+          - const: rockchip,rk3528
+
       - description: FriendlyElec NanoPC T6 series boards
         items:
           - enum:
-- 
2.49.0

[PATCH v3 6/6] arm64: dts: rockchip: Add FriendlyElec NanoPi Zero2

[Jonas Karlman]

The NanoPi Zero2 is a small single board computer developed by
FriendlyElec, based on the Rockchip RK3528A SoC.

Add initial device tree for the FriendlyElec NanoPi Zero2 board.

Signed-off-by: Jonas Karlman <jonas@kwiboo.se>
Tested-by: Yao Zi <ziyao@disroot.org>
---
Changes in v3:
- Rename led nodes to led-0/led-1 (Chukun Pan)

Changes in v2:
- Drop clock-output-names prop from rtc node (Chukun Pan)
- Collect t-b tag

Schematics: https://wiki.friendlyelec.com/wiki/images/3/37/NanoPi_Zero2_2407_SCH.pdf
---
 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../boot/dts/rockchip/rk3528-nanopi-zero2.dts | 340 ++++++++++++++++++
 2 files changed, 341 insertions(+)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3528-nanopi-zero2.dts

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 206fb8572cf7..0662fcf00628 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -90,6 +90,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-sapphire-excavator.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399pro-rock-pi-n10.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-armsom-sige1.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-nanopi-zero2.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-radxa-e20c.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-rock-2a.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3528-rock-2f.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3528-nanopi-zero2.dts b/arch/arm64/boot/dts/rockchip/rk3528-nanopi-zero2.dts
new file mode 100644
index 000000000000..9f683033c5f3
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3528-nanopi-zero2.dts
@@ -0,0 +1,340 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pwm/pwm.h>
+#include "rk3528.dtsi"
+
+/ {
+	model = "FriendlyElec NanoPi Zero2";
+	compatible = "friendlyarm,nanopi-zero2", "rockchip,rk3528";
+
+	aliases {
+		ethernet0 = &gmac1;
+		i2c1 = &i2c1;
+		mmc0 = &sdhci;
+		mmc1 = &sdmmc;
+		serial0 = &uart0;
+	};
+
+	chosen {
+		stdout-path = "serial0:1500000n8";
+	};
+
+	adc-keys-0 {
+		compatible = "adc-keys";
+		io-channels = <&saradc 0>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+		poll-interval = <100>;
+
+		button-maskrom {
+			label = "MASK";
+			linux,code = <KEY_SETUP>;
+			press-threshold-microvolt = <0>;
+		};
+	};
+
+	adc-keys-1 {
+		compatible = "adc-keys";
+		io-channels = <&saradc 1>;
+		io-channel-names = "buttons";
+		keyup-threshold-microvolt = <1800000>;
+		poll-interval = <100>;
+
+		button-recovery {
+			label = "RECOVERY";
+			linux,code = <KEY_VENDOR>;
+			press-threshold-microvolt = <0>;
+		};
+	};
+
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <&led1>, <&led_sys>;
+
+		led-0 {
+			color = <LED_COLOR_ID_RED>;
+			default-state = "on";
+			function = LED_FUNCTION_HEARTBEAT;
+			gpios = <&gpio4 RK_PB0 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "heartbeat";
+		};
+
+		led-1 {
+			color = <LED_COLOR_ID_GREEN>;
+			default-state = "on";
+			function = LED_FUNCTION_STATUS;
+			gpios = <&gpio4 RK_PB1 GPIO_ACTIVE_HIGH>;
+			linux,default-trigger = "default-on";
+		};
+	};
+
+	vcc0v6_ddr: regulator-0v6-vcc-ddr {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc0v6_ddr";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <600000>;
+		regulator-max-microvolt = <600000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vdd_0v9: regulator-0v9-vdd {
+		compatible = "regulator-fixed";
+		regulator-name = "vdd_0v9";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <900000>;
+		regulator-max-microvolt = <900000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_ddr: regulator-1v1-vcc-ddr {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_ddr";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1100000>;
+		regulator-max-microvolt = <1100000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc_1v8: regulator-1v8-vcc {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_1v8";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <1800000>;
+		vin-supply = <&vcc_3v3>;
+	};
+
+	vcc_3v3: regulator-3v3-vcc {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_3v3";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vcc3v3_sd: regulator-3v3-vcc-sd {
+		compatible = "regulator-fixed";
+		gpios = <&gpio4 RK_PA1 GPIO_ACTIVE_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&sdmmc_pwren_l>;
+		regulator-name = "vcc3v3_sd";
+		regulator-min-microvolt = <3300000>;
+		regulator-max-microvolt = <3300000>;
+		vin-supply = <&vcc_3v3>;
+	};
+
+	vcc5v0_sys: regulator-5v0-vcc-sys {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc5v0_sys";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+	};
+
+	usb2_host_5v: regulator-5v0-usb2-host {
+		compatible = "regulator-fixed";
+		enable-active-high;
+		gpios = <&gpio4 RK_PB5 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb20_host1_pwren>;
+		regulator-name = "usb2_host_5v";
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vccio_sd: regulator-vccio-sd {
+		compatible = "regulator-gpio";
+		gpios = <&gpio4 RK_PB6 GPIO_ACTIVE_HIGH>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&sdmmc_vol_ctrl_h>;
+		regulator-name = "vccio_sd";
+		regulator-min-microvolt = <1800000>;
+		regulator-max-microvolt = <3300000>;
+		states = <1800000 0x0>, <3300000 0x1>;
+		vin-supply = <&vcc5v0_sys>;
+	};
+
+	vdd_arm: regulator-vdd-arm {
+		compatible = "pwm-regulator";
+		pwms = <&pwm1 0 5000 PWM_POLARITY_INVERTED>;
+		pwm-supply = <&vcc5v0_sys>;
+		regulator-name = "vdd_arm";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <746000>;
+		regulator-max-microvolt = <1201000>;
+		regulator-settling-time-up-us = <250>;
+	};
+
+	vdd_logic: regulator-vdd-logic {
+		compatible = "pwm-regulator";
+		pwms = <&pwm2 0 5000 PWM_POLARITY_INVERTED>;
+		pwm-supply = <&vcc5v0_sys>;
+		regulator-name = "vdd_logic";
+		regulator-always-on;
+		regulator-boot-on;
+		regulator-min-microvolt = <705000>;
+		regulator-max-microvolt = <1006000>;
+		regulator-settling-time-up-us = <250>;
+	};
+};
+
+&cpu0 {
+	cpu-supply = <&vdd_arm>;
+};
+
+&cpu1 {
+	cpu-supply = <&vdd_arm>;
+};
+
+&cpu2 {
+	cpu-supply = <&vdd_arm>;
+};
+
+&cpu3 {
+	cpu-supply = <&vdd_arm>;
+};
+
+&gmac1 {
+	clock_in_out = "output";
+	phy-handle = <&rgmii_phy>;
+	phy-mode = "rgmii-id";
+	phy-supply = <&vcc_3v3>;
+	pinctrl-names = "default";
+	pinctrl-0 = <&rgmii_miim>, <&rgmii_tx_bus2>, <&rgmii_rx_bus2>,
+		    <&rgmii_rgmii_clk>, <&rgmii_rgmii_bus>;
+	status = "okay";
+};
+
+&gpu {
+	mali-supply = <&vdd_logic>;
+	status = "okay";
+};
+
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1m0_xfer>;
+	status = "okay";
+
+	hym8563: rtc@51 {
+		compatible = "haoyu,hym8563";
+		reg = <0x51>;
+		#clock-cells = <0>;
+		interrupt-parent = <&gpio4>;
+		interrupts = <RK_PC1 IRQ_TYPE_LEVEL_LOW>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&rtc_int_l>;
+		wakeup-source;
+	};
+};
+
+&mdio1 {
+	rgmii_phy: ethernet-phy@1 {
+		compatible = "ethernet-phy-ieee802.3-c22";
+		reg = <0x1>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&gmac1_rstn_l>;
+		reset-assert-us = <20000>;
+		reset-deassert-us = <100000>;
+		reset-gpios = <&gpio4 RK_PC2 GPIO_ACTIVE_LOW>;
+	};
+};
+
+&pinctrl {
+	ethernet {
+		gmac1_rstn_l: gmac1-rstn-l {
+			rockchip,pins = <4 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	leds {
+		led1: led1 {
+			rockchip,pins = <4 RK_PB1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		led_sys: led-sys {
+			rockchip,pins = <4 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	rtc {
+		rtc_int_l: rtc-int-l {
+			rockchip,pins = <4 RK_PC1 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+	};
+
+	sdmmc {
+		sdmmc_vol_ctrl_h: sdmmc-vol-ctrl-h {
+			rockchip,pins = <4 RK_PB6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+
+		sdmmc_pwren_l: sdmmc-pwren-l {
+			rockchip,pins = <4 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+
+	usb {
+		usb20_host1_pwren: usb20-host1-pwren {
+			rockchip,pins = <4 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
+};
+
+&pwm1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm1m0_pins>;
+	status = "okay";
+};
+
+&pwm2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&pwm2m0_pins>;
+	status = "okay";
+};
+
+&saradc {
+	vref-supply = <&vcc_1v8>;
+	status = "okay";
+};
+
+&sdhci {
+	bus-width = <8>;
+	cap-mmc-highspeed;
+	mmc-hs200-1_8v;
+	no-sd;
+	no-sdio;
+	non-removable;
+	vmmc-supply = <&vcc_3v3>;
+	vqmmc-supply = <&vcc_1v8>;
+	status = "okay";
+};
+
+&sdmmc {
+	bus-width = <4>;
+	cap-mmc-highspeed;
+	cap-sd-highspeed;
+	disable-wp;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc3v3_sd>;
+	vqmmc-supply = <&vccio_sd>;
+	status = "okay";
+};
+
+&uart0 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart0m0_xfer>;
+	status = "okay";
+};
-- 
2.49.0

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

[Alex Bee]

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
> 

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

[Jonas Karlman]

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

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

[Alex Bee]

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

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

[Jonas Karlman]

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

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

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

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

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

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


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

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

[Alex Bee]

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

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

[Chukun Pan]

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

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

[Alex Bee]

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

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

[Alex Bee]

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

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

[Chukun Pan]

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

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

[Alex Bee]

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
>

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

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

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

[Alex Bee]

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
>

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

[Chukun Pan]

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

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

[Alex Bee]

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

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

[Yao Zi]

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

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

[Nicolas Frattaroli]

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
> 

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

[Rob Herring (Arm)]

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']