[PATCH v5 1/2] dt-bindings: arm: rockchip: add support for Radxa ROCK Pi E v3.0

[PATCH v5 1/2] dt-bindings: arm: rockchip: add support for Radxa ROCK Pi E v3.0

[FUKAUMI Naoki]

Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the Rockchip
RK3328 chip.

[1] https://radxa.com/products/rockpi/pie

Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
---
Changes in v5:
- revert compatible string
- describe rockchip.yaml properly
Changes in v4:
- update compatible string for OpenWrt
- drop A-b tag
Changes in v3:
- collect A-b tag
Changes in v2:
- fix typo in commit message
- add missing --- in commit message
- add new section instead of new item in rockchip.yaml
---
 Documentation/devicetree/bindings/arm/rockchip.yaml | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index 1f23b8b05a8f..684b779b2a40 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -795,7 +795,9 @@ properties:
 
       - description: Radxa ROCK Pi E
         items:
-          - const: radxa,rockpi-e
+          - enum:
+              - radxa,rockpi-e
+              - radxa,rockpi-e-v3
           - const: rockchip,rk3328
 
       - description: Radxa ROCK Pi N8
-- 
2.43.0

[PATCH v5 2/2] arm64: dts: rockchip: add support for Radxa ROCK Pi E v3.0

[FUKAUMI Naoki]

Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the Rockchip
RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT configurations:

- Rockchip RK3328 SoC
- Quad A53 CPU
- 512MB/1GB/2GB DDR4 RAM
- 4/8/16/32GB eMMC
- Micro SD Card slot
- WiFi 4 and BT 4, or WiFi 5 and BT 5
- 1x 1000M Ethernet supporting PoE with add‑on PoE HAT
- 1x 100M Ethernet
- 1x USB 3.0 Type-A port (Host)
- 1x 4-ring 3.5mm headphone jack
- 40 Pin GPIO header

[1] https://radxa.com/products/rockpi/pie

Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
---
Changes in v5:
- revert compatible string
Changes in v4:
- update compatible string for OpenWrt
Changes in v3:
- fix conflict for recent change
Changes in v2:
- fix typo in commit message
- add missing --- in commit message
---
 arch/arm64/boot/dts/rockchip/Makefile         |   1 +
 .../boot/dts/rockchip/rk3328-rock-pi-e-v3.dts |  15 +
 .../boot/dts/rockchip/rk3328-rock-pi-e.dts    | 460 +-----------------
 ...28-rock-pi-e.dts => rk3328-rock-pi-e.dtsi} |   5 -
 4 files changed, 31 insertions(+), 450 deletions(-)
 create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dts
 rewrite arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts (97%)
 copy arch/arm64/boot/dts/rockchip/{rk3328-rock-pi-e.dts => rk3328-rock-pi-e.dtsi} (98%)

diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index cb309b1975ba..cc74cd17850a 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -25,6 +25,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-r2s-plus.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-orangepi-r1-plus.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-orangepi-r1-plus-lts.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e-v3.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-cc.dtb
 dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-pc.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dts
new file mode 100644
index 000000000000..ad9c4c562914
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3328-rock-pi-e.dtsi"
+
+/ {
+	model = "Radxa ROCK Pi E v3.0";
+	compatible = "radxa,rockpi-e-v3", "rockchip,rk3328";
+
+	aliases {
+		mmc0 = &emmc;
+		mmc1 = &sdmmc;
+	};
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
dissimilarity index 97%
index 3e08e2fd0a78..0929df3c803a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
@@ -1,445 +1,15 @@
-// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
-/*
- * (C) Copyright 2020 Chen-Yu Tsai <wens@csie.org>
- *
- * Based on ./rk3328-rock64.dts, which is
- *
- * Copyright (c) 2017 PINE64
- */
-
-/dts-v1/;
-
-#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/input/input.h>
-#include <dt-bindings/leds/common.h>
-#include <dt-bindings/pinctrl/rockchip.h>
-
-#include "rk3328.dtsi"
-
-/ {
-	model = "Radxa ROCK Pi E";
-	compatible = "radxa,rockpi-e", "rockchip,rk3328";
-
-	aliases {
-		ethernet0 = &gmac2io;
-		ethernet1 = &gmac2phy;
-		mmc0 = &sdmmc;
-		mmc1 = &emmc;
-	};
-
-	chosen {
-		stdout-path = "serial2:1500000n8";
-	};
-
-	adc-keys {
-		compatible = "adc-keys";
-		io-channels = <&saradc 0>;
-		io-channel-names = "buttons";
-		keyup-threshold-microvolt = <1750000>;
-
-		/* This button is unpopulated out of the factory. */
-		button-recovery {
-			label = "Recovery";
-			linux,code = <KEY_VENDOR>;
-			press-threshold-microvolt = <10000>;
-		};
-	};
-
-	gmac_clkin: external-gmac-clock {
-		compatible = "fixed-clock";
-		clock-frequency = <125000000>;
-		clock-output-names = "gmac_clkin";
-		#clock-cells = <0>;
-	};
-
-	leds {
-		compatible = "gpio-leds";
-		pinctrl-0 = <&led_pin>;
-		pinctrl-names = "default";
-
-		led-0 {
-			color = <LED_COLOR_ID_BLUE>;
-			gpios = <&gpio3 RK_PA5 GPIO_ACTIVE_LOW>;
-			linux,default-trigger = "heartbeat";
-		};
-	};
-
-	vcc_sd: sdmmc-regulator {
-		compatible = "regulator-fixed";
-		gpio = <&gpio0 RK_PD6 GPIO_ACTIVE_LOW>;
-		pinctrl-names = "default";
-		pinctrl-0 = <&sdmmc0m1_pin>;
-		regulator-name = "vcc_sd";
-		regulator-boot-on;
-		vin-supply = <&vcc_io>;
-	};
-
-	vcc_host_5v: vcc-host-5v-regulator {
-		compatible = "regulator-fixed";
-		gpio = <&gpio3 RK_PA7 GPIO_ACTIVE_HIGH>;
-		pinctrl-names = "default";
-		pinctrl-0 = <&usb30_host_drv>;
-		enable-active-high;
-		regulator-name = "vcc_host_5v";
-		regulator-always-on;
-		regulator-boot-on;
-		vin-supply = <&vcc_sys>;
-	};
-
-	vcc_sys: vcc-sys {
-		compatible = "regulator-fixed";
-		regulator-name = "vcc_sys";
-		regulator-always-on;
-		regulator-boot-on;
-		regulator-min-microvolt = <5000000>;
-		regulator-max-microvolt = <5000000>;
-	};
-
-	vcc_wifi: vcc-wifi-regulator {
-		compatible = "regulator-fixed";
-		gpio = <&gpio0 RK_PA0 GPIO_ACTIVE_LOW>;
-		pinctrl-names = "default";
-		pinctrl-0 = <&wifi_en>;
-		regulator-name = "vcc_wifi";
-		regulator-always-on;
-		regulator-boot-on;
-		vin-supply = <&vcc_io>;
-	};
-};
-
-&analog_sound {
-	status = "okay";
-};
-
-&codec {
-	status = "okay";
-};
-
-&cpu0 {
-	cpu-supply = <&vdd_arm>;
-};
-
-&cpu1 {
-	cpu-supply = <&vdd_arm>;
-};
-
-&cpu2 {
-	cpu-supply = <&vdd_arm>;
-};
-
-&cpu3 {
-	cpu-supply = <&vdd_arm>;
-};
-
-&emmc {
-	bus-width = <8>;
-	cap-mmc-highspeed;
-	mmc-ddr-1_8v;
-	mmc-hs200-1_8v;
-	non-removable;
-	pinctrl-names = "default";
-	pinctrl-0 = <&emmc_clk>, <&emmc_cmd>, <&emmc_bus8>;
-	vmmc-supply = <&vcc_io>;
-	vqmmc-supply = <&vcc18_emmc>;
-	status = "okay";
-};
-
-&gmac2io {
-	assigned-clocks = <&cru SCLK_MAC2IO>, <&cru SCLK_MAC2IO_EXT>;
-	assigned-clock-parents = <&gmac_clkin>, <&gmac_clkin>;
-	clock_in_out = "input";
-	phy-handle = <&rtl8211>;
-	phy-mode = "rgmii";
-	phy-supply = <&vcc_io>;
-	pinctrl-names = "default";
-	pinctrl-0 = <&rgmiim1_pins>;
-	snps,aal;
-	snps,rxpbl = <0x4>;
-	snps,txpbl = <0x4>;
-	tx_delay = <0x26>;
-	rx_delay = <0x11>;
-	status = "okay";
-
-	mdio {
-		compatible = "snps,dwmac-mdio";
-		#address-cells = <1>;
-		#size-cells = <0>;
-
-		rtl8211: ethernet-phy@1 {
-			reg = <1>;
-			pinctrl-0 = <&eth_phy_int_pin>, <&eth_phy_reset_pin>;
-			pinctrl-names = "default";
-			interrupt-parent = <&gpio1>;
-			interrupts = <24 IRQ_TYPE_LEVEL_LOW>;
-			reset-assert-us = <10000>;
-			reset-deassert-us = <50000>;
-			reset-gpios = <&gpio1 RK_PC2 GPIO_ACTIVE_LOW>;
-		};
-	};
-};
-
-&gmac2phy {
-	status = "okay";
-};
-
-&gpio0 {
-	gpio-line-names =
-		/* GPIO0_A0 - A7 */
-		"", "", "", "", "", "", "", "",
-		/* GPIO0_B0 - B7 */
-		"", "", "", "", "", "", "", "",
-		/* GPIO0_C0 - C7 */
-		"", "", "", "", "", "", "", "",
-		/* GPIO0_D0 - D7 */
-		"", "", "", "pin-15 [GPIO0_D3]", "", "", "", "";
-};
-
-&gpio1 {
-	gpio-line-names =
-		/* GPIO1_A0 - A7 */
-		"", "", "", "", "", "", "", "",
-		/* GPIO1_B0 - B7 */
-		"", "", "", "", "", "", "", "",
-		/* GPIO1_C0 - C7 */
-		"", "", "", "", "", "", "", "",
-		/* GPIO1_D0 - D7 */
-		"", "", "", "", "pin-07 [GPIO1_D4]", "", "", "";
-};
-
-&gpio2 {
-	gpio-line-names =
-		/* GPIO2_A0 - A7 */
-		"pin-08 [GPIO2_A0]", "pin-10 [GPIO2_A1]", "pin-11 [GPIO2_A2]",
-		"pin-13 [GPIO2-A3]", "pin-27 [GPIO2_A4]", "pin-28 [GPIO2_A5]",
-		"pin-33 [GPIO2_A6]", "",
-		/* GPIO2_B0 - B7 */
-		"", "", "", "", "pin-26 [GPIO2_B4]", "", "", "pin-36 [GPIO2_B7]",
-		/* GPIO2_C0 - C7 */
-		"pin-32 [GPIO2_C0]", "pin-35 [GPIO2_C1]", "pin-12 [GPIO2_C2]",
-		"pin-38 [GPIO2_C3]", "pin-29 [GPIO2_C4]", "pin-31 [GPIO2_C5]",
-		"pin-37 [GPIO2_C6]", "pin-40 [GPIO2_C7]",
-		/* GPIO2_D0 - D7 */
-		"", "", "", "", "", "", "", "";
-};
-
-&gpio3 {
-	gpio-line-names =
-		/* GPIO3_A0 - A7 */
-		"pin-23 [GPIO3_A0]", "pin-19 [GPIO3_A1]", "pin-21 [GPIO3_A2]",
-		"", "pin-03 [GPIO3_A4]", "", "pin-05 [GPIO3_A6]", "",
-		/* GPIO3_B0 - B7 */
-		"pin-24 [GPIO3_B0]", "", "", "", "", "", "", "",
-		/* GPIO3_C0 - C7 */
-		"", "", "", "", "", "", "", "",
-		/* GPIO3_D0 - D7 */
-		"", "", "", "", "", "", "", "";
-};
-
-&i2c1 {
-	status = "okay";
-
-	rk805: pmic@18 {
-		compatible = "rockchip,rk805";
-		reg = <0x18>;
-		interrupt-parent = <&gpio0>;
-		interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
-		#clock-cells = <1>;
-		clock-output-names = "xin32k", "rk805-clkout2";
-		gpio-controller;
-		#gpio-cells = <2>;
-		pinctrl-names = "default";
-		pinctrl-0 = <&pmic_int_l>;
-		rockchip,system-power-controller;
-		wakeup-source;
-
-		vcc1-supply = <&vcc_sys>;
-		vcc2-supply = <&vcc_sys>;
-		vcc3-supply = <&vcc_sys>;
-		vcc4-supply = <&vcc_sys>;
-		vcc5-supply = <&vcc_io>;
-		vcc6-supply = <&vcc_sys>;
-
-		regulators {
-			vdd_log: DCDC_REG1 {
-				regulator-name = "vdd_log";
-				regulator-always-on;
-				regulator-boot-on;
-				regulator-min-microvolt = <712500>;
-				regulator-max-microvolt = <1450000>;
-				regulator-ramp-delay = <12500>;
-
-				regulator-state-mem {
-					regulator-on-in-suspend;
-					regulator-suspend-microvolt = <1000000>;
-				};
-			};
-
-			vdd_arm: DCDC_REG2 {
-				regulator-name = "vdd_arm";
-				regulator-always-on;
-				regulator-boot-on;
-				regulator-min-microvolt = <712500>;
-				regulator-max-microvolt = <1450000>;
-				regulator-ramp-delay = <12500>;
-
-				regulator-state-mem {
-					regulator-on-in-suspend;
-					regulator-suspend-microvolt = <950000>;
-				};
-			};
-
-			vcc_ddr: DCDC_REG3 {
-				regulator-name = "vcc_ddr";
-				regulator-always-on;
-				regulator-boot-on;
-
-				regulator-state-mem {
-					regulator-on-in-suspend;
-				};
-			};
-
-			vcc_io: DCDC_REG4 {
-				regulator-name = "vcc_io";
-				regulator-always-on;
-				regulator-boot-on;
-				regulator-min-microvolt = <3300000>;
-				regulator-max-microvolt = <3300000>;
-
-				regulator-state-mem {
-					regulator-on-in-suspend;
-					regulator-suspend-microvolt = <3300000>;
-				};
-			};
-
-			vcc_18: LDO_REG1 {
-				regulator-name = "vcc_18";
-				regulator-always-on;
-				regulator-boot-on;
-				regulator-min-microvolt = <1800000>;
-				regulator-max-microvolt = <1800000>;
-
-				regulator-state-mem {
-					regulator-on-in-suspend;
-					regulator-suspend-microvolt = <1800000>;
-				};
-			};
-
-			vcc18_emmc: LDO_REG2 {
-				regulator-name = "vcc18_emmc";
-				regulator-always-on;
-				regulator-boot-on;
-				regulator-min-microvolt = <1800000>;
-				regulator-max-microvolt = <1800000>;
-
-				regulator-state-mem {
-					regulator-on-in-suspend;
-					regulator-suspend-microvolt = <1800000>;
-				};
-			};
-
-			vdd_10: LDO_REG3 {
-				regulator-name = "vdd_10";
-				regulator-always-on;
-				regulator-boot-on;
-				regulator-min-microvolt = <1000000>;
-				regulator-max-microvolt = <1000000>;
-
-				regulator-state-mem {
-					regulator-on-in-suspend;
-					regulator-suspend-microvolt = <1000000>;
-				};
-			};
-		};
-	};
-};
-
-&i2s1 {
-	status = "okay";
-};
-
-&io_domains {
-	pmuio-supply = <&vcc_io>;
-	vccio1-supply = <&vcc_io>;
-	vccio2-supply = <&vcc18_emmc>;
-	vccio3-supply = <&vcc_io>;
-	vccio4-supply = <&vcc_io>;
-	vccio5-supply = <&vcc_io>;
-	vccio6-supply = <&vcc_io>;
-	status = "okay";
-};
-
-&pinctrl {
-	ephy {
-		eth_phy_int_pin: eth-phy-int-pin {
-			rockchip,pins = <1 RK_PD0 RK_FUNC_GPIO &pcfg_pull_down>;
-		};
-
-		eth_phy_reset_pin: eth-phy-reset-pin {
-			rockchip,pins = <1 RK_PC2 RK_FUNC_GPIO &pcfg_pull_down>;
-		};
-	};
-
-	leds {
-		led_pin: led-pin {
-			rockchip,pins = <3 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
-		};
-	};
-
-	pmic {
-		pmic_int_l: pmic-int-l {
-			rockchip,pins = <0 RK_PA2 RK_FUNC_GPIO &pcfg_pull_up>;
-		};
-	};
-
-	usb3 {
-		usb30_host_drv: usb30-host-drv {
-			rockchip,pins = <3 RK_PA7 RK_FUNC_GPIO &pcfg_pull_none>;
-		};
-	};
-
-	wifi {
-		wifi_en: wifi-en {
-			rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>;
-		};
-	};
-};
-
-&sdmmc {
-	bus-width = <4>;
-	cap-sd-highspeed;
-	disable-wp;
-	pinctrl-names = "default";
-	pinctrl-0 = <&sdmmc0_clk>, <&sdmmc0_cmd>, <&sdmmc0_dectn>, <&sdmmc0_bus4>;
-	vmmc-supply = <&vcc_sd>;
-	status = "okay";
-};
-
-&saradc {
-	vref-supply = <&vcc_18>;
-	status = "okay";
-};
-
-&tsadc {
-	status = "okay";
-};
-
-&u2phy {
-	status = "okay";
-};
-
-&u2phy_host {
-	status = "okay";
-};
-
-&uart2 {
-	status = "okay";
-};
-
-&usbdrd3 {
-	dr_mode = "host";
-	status = "okay";
-};
-
-&usb_host0_ehci {
-	status = "okay";
-};
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3328-rock-pi-e.dtsi"
+
+/ {
+	model = "Radxa ROCK Pi E";
+	compatible = "radxa,rockpi-e", "rockchip,rk3328";
+
+	aliases {
+		mmc0 = &sdmmc;
+		mmc1 = &emmc;
+	};
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dtsi
similarity index 98%
copy from arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
copy to arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dtsi
index 3e08e2fd0a78..bb01143dc91a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dtsi
@@ -17,14 +17,9 @@
 #include "rk3328.dtsi"
 
 / {
-	model = "Radxa ROCK Pi E";
-	compatible = "radxa,rockpi-e", "rockchip,rk3328";
-
 	aliases {
 		ethernet0 = &gmac2io;
 		ethernet1 = &gmac2phy;
-		mmc0 = &sdmmc;
-		mmc1 = &emmc;
 	};
 
 	chosen {
-- 
2.43.0

Re: [PATCH v5 2/2] arm64: dts: rockchip: add support for Radxa ROCK Pi E v3.0

[Heiko Stübner]

Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki:
> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the Rockchip
> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT configurations:
> 
> - Rockchip RK3328 SoC
> - Quad A53 CPU
> - 512MB/1GB/2GB DDR4 RAM
> - 4/8/16/32GB eMMC
> - Micro SD Card slot
> - WiFi 4 and BT 4, or WiFi 5 and BT 5
> - 1x 1000M Ethernet supporting PoE with add‑on PoE HAT
> - 1x 100M Ethernet
> - 1x USB 3.0 Type-A port (Host)
> - 1x 4-ring 3.5mm headphone jack
> - 40 Pin GPIO header
> 
> [1] https://radxa.com/products/rockpi/pie
> 
> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
> ---
> Changes in v5:
> - revert compatible string
> Changes in v4:
> - update compatible string for OpenWrt
> Changes in v3:
> - fix conflict for recent change
> Changes in v2:
> - fix typo in commit message
> - add missing --- in commit message
> ---
>  arch/arm64/boot/dts/rockchip/Makefile         |   1 +
>  .../boot/dts/rockchip/rk3328-rock-pi-e-v3.dts |  15 +
>  .../boot/dts/rockchip/rk3328-rock-pi-e.dts    | 460 +-----------------
>  ...28-rock-pi-e.dts => rk3328-rock-pi-e.dtsi} |   5 -
>  4 files changed, 31 insertions(+), 450 deletions(-)
>  create mode 100644 arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dts
>  rewrite arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts (97%)
>  copy arch/arm64/boot/dts/rockchip/{rk3328-rock-pi-e.dts => rk3328-rock-pi-e.dtsi} (98%)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index cb309b1975ba..cc74cd17850a 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -25,6 +25,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-nanopi-r2s-plus.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-orangepi-r1-plus.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-orangepi-r1-plus-lts.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock64.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e-v3.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-rock-pi-e.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-cc.dtb
>  dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3328-roc-pc.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dts
> new file mode 100644
> index 000000000000..ad9c4c562914
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dts
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include "rk3328-rock-pi-e.dtsi"
> +
> +/ {
> +	model = "Radxa ROCK Pi E v3.0";
> +	compatible = "radxa,rockpi-e-v3", "rockchip,rk3328";
> +
> +	aliases {
> +		mmc0 = &emmc;
> +		mmc1 = &sdmmc;
> +	};
> +};

> diff --git a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> dissimilarity index 97%
> index 3e08e2fd0a78..0929df3c803a 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e.dts
> @@ -1,445 +1,15 @@

[...]

> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include "rk3328-rock-pi-e.dtsi"
> +
> +/ {
> +	model = "Radxa ROCK Pi E";
> +	compatible = "radxa,rockpi-e", "rockchip,rk3328";
> +
> +	aliases {
> +		mmc0 = &sdmmc;
> +		mmc1 = &emmc;
> +	};
> +};

can you please describe what is different in that v3 board?
Describing what is different to require a separate board should've been
part of the commit message.

Because from those changes, the bottom line currently seems to be
the same board with swapped mmc aliases?

Heiko

Re: [PATCH v5 2/2] arm64: dts: rockchip: add support for Radxa ROCK Pi E v3.0

[FUKAUMI Naoki]

Hi,

On 8/17/24 07:11, Heiko Stübner wrote:
> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki:
>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the Rockchip
>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT configurations:
>>
>> - Rockchip RK3328 SoC
>> - Quad A53 CPU
>> - 512MB/1GB/2GB DDR4 RAM
(snip)
> can you please describe what is different in that v3 board?
> Describing what is different to require a separate board should've been
> part of the commit message.
> 
> Because from those changes, the bottom line currently seems to be
> the same board with swapped mmc aliases?

it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E).
different bootloader (U-Boot) is required.

adding v3 dts seems not to be so important for Linux, but it's very 
important for U-Boot and OpenWrt(it includes bootloader for distributed 
binary).

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

> Heiko
> 
> 
> 
> 
> 

Re: [PATCH v5 2/2] arm64: dts: rockchip: add support for Radxa ROCK Pi E v3.0

[Dragan Simic]

Hello Fukaumi,

On 2024-08-17 00:20, FUKAUMI Naoki wrote:
> On 8/17/24 07:11, Heiko Stübner wrote:
>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki:
>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the 
>>> Rockchip
>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT 
>>> configurations:
>>> 
>>> - Rockchip RK3328 SoC
>>> - Quad A53 CPU
>>> - 512MB/1GB/2GB DDR4 RAM
> (snip)
>> can you please describe what is different in that v3 board?
>> Describing what is different to require a separate board should've 
>> been
>> part of the commit message.
>> 
>> Because from those changes, the bottom line currently seems to be
>> the same board with swapped mmc aliases?
> 
> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E).
> different bootloader (U-Boot) is required.
> 
> adding v3 dts seems not to be so important for Linux, but it's very
> important for U-Boot and OpenWrt(it includes bootloader for
> distributed binary).

Aren't there different methods that allow such board variants to be
supported in U-Boot, with no need for a separate DT in the kernel?
IIRC, there are already more than a few examples of such board variants,
which require different DRAM initialization, which is covered in U-Boot
by providing different builds that use the same DT.

Re: [PATCH v5 2/2] arm64: dts: rockchip: add support for Radxa ROCK Pi E v3.0

[Dragan Simic]

On 2024-08-17 21:28, Dragan Simic wrote:
> Hello Fukaumi,
> 
> On 2024-08-17 00:20, FUKAUMI Naoki wrote:
>> On 8/17/24 07:11, Heiko Stübner wrote:
>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki:
>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the 
>>>> Rockchip
>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT 
>>>> configurations:
>>>> 
>>>> - Rockchip RK3328 SoC
>>>> - Quad A53 CPU
>>>> - 512MB/1GB/2GB DDR4 RAM
>> (snip)
>>> can you please describe what is different in that v3 board?
>>> Describing what is different to require a separate board should've 
>>> been
>>> part of the commit message.
>>> 
>>> Because from those changes, the bottom line currently seems to be
>>> the same board with swapped mmc aliases?
>> 
>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E).
>> different bootloader (U-Boot) is required.
>> 
>> adding v3 dts seems not to be so important for Linux, but it's very
>> important for U-Boot and OpenWrt(it includes bootloader for
>> distributed binary).
> 
> Aren't there different methods that allow such board variants to be
> supported in U-Boot, with no need for a separate DT in the kernel?
> IIRC, there are already more than a few examples of such board 
> variants,
> which require different DRAM initialization, which is covered in U-Boot
> by providing different builds that use the same DT.

As an example, please have a look at the following files in U-Boot:

- arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
- arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi
- configs/nanopi-m4-rk3399_defconfig
- configs/nanopi-m4-2gb-rk3399_defconfig

Basically, there's no need for separate DTs in the kernel, just to 
support
board variants with different DRAM types in U-Boot.

Re: [PATCH v5 2/2] arm64: dts: rockchip: add support for Radxa ROCK Pi E v3.0

[FUKAUMI Naoki]

Hi,

On 8/18/24 04:51, Dragan Simic wrote:
> On 2024-08-17 21:28, Dragan Simic wrote:
>> Hello Fukaumi,
>>
>> On 2024-08-17 00:20, FUKAUMI Naoki wrote:
>>> On 8/17/24 07:11, Heiko Stübner wrote:
>>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki:
>>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the Rockchip
>>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT configurations:
>>>>>
>>>>> - Rockchip RK3328 SoC
>>>>> - Quad A53 CPU
>>>>> - 512MB/1GB/2GB DDR4 RAM
>>> (snip)
>>>> can you please describe what is different in that v3 board?
>>>> Describing what is different to require a separate board should've been
>>>> part of the commit message.
>>>>
>>>> Because from those changes, the bottom line currently seems to be
>>>> the same board with swapped mmc aliases?
>>>
>>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E).
>>> different bootloader (U-Boot) is required.
>>>
>>> adding v3 dts seems not to be so important for Linux, but it's very
>>> important for U-Boot and OpenWrt(it includes bootloader for
>>> distributed binary).
>>
>> Aren't there different methods that allow such board variants to be
>> supported in U-Boot, with no need for a separate DT in the kernel?
>> IIRC, there are already more than a few examples of such board variants,
>> which require different DRAM initialization, which is covered in U-Boot
>> by providing different builds that use the same DT.
> 
> As an example, please have a look at the following files in U-Boot:
> 
> - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
> - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi
> - configs/nanopi-m4-rk3399_defconfig
> - configs/nanopi-m4-2gb-rk3399_defconfig
> 
> Basically, there's no need for separate DTs in the kernel, just to support
> board variants with different DRAM types in U-Boot.

OpenWrt firmware upgrading tool (sysupgrade) refers "compatible" string 
to validate new firmware file is surely "for this board".

currently both Pi E dts have "radxa,rockpi-e", it makes flashing wrong 
firmware (include bootloaer, U-Boot) possible.

Radxa ROCK Pi E v1.x(DDR3) and ROCK Pi E v3(DDR4) are different 
incompatible boards, it must have different "compatible" string.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

Re: [PATCH v5 2/2] arm64: dts: rockchip: add support for Radxa ROCK Pi E v3.0

[FUKAUMI Naoki]

On 8/18/24 05:04, FUKAUMI Naoki wrote:
> Hi,
> 
> On 8/18/24 04:51, Dragan Simic wrote:
>> On 2024-08-17 21:28, Dragan Simic wrote:
>>> Hello Fukaumi,
>>>
>>> On 2024-08-17 00:20, FUKAUMI Naoki wrote:
>>>> On 8/17/24 07:11, Heiko Stübner wrote:
>>>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki:
>>>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the 
>>>>>> Rockchip
>>>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT 
>>>>>> configurations:
>>>>>>
>>>>>> - Rockchip RK3328 SoC
>>>>>> - Quad A53 CPU
>>>>>> - 512MB/1GB/2GB DDR4 RAM
>>>> (snip)
>>>>> can you please describe what is different in that v3 board?
>>>>> Describing what is different to require a separate board should've 
>>>>> been
>>>>> part of the commit message.
>>>>>
>>>>> Because from those changes, the bottom line currently seems to be
>>>>> the same board with swapped mmc aliases?
>>>>
>>>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E).
>>>> different bootloader (U-Boot) is required.
>>>>
>>>> adding v3 dts seems not to be so important for Linux, but it's very
>>>> important for U-Boot and OpenWrt(it includes bootloader for
>>>> distributed binary).
>>>
>>> Aren't there different methods that allow such board variants to be
>>> supported in U-Boot, with no need for a separate DT in the kernel?
>>> IIRC, there are already more than a few examples of such board variants,
>>> which require different DRAM initialization, which is covered in U-Boot
>>> by providing different builds that use the same DT.
>>
>> As an example, please have a look at the following files in U-Boot:
>>
>> - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
>> - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi
>> - configs/nanopi-m4-rk3399_defconfig
>> - configs/nanopi-m4-2gb-rk3399_defconfig
>>
>> Basically, there's no need for separate DTs in the kernel, just to 
>> support
>> board variants with different DRAM types in U-Boot.
> 
> OpenWrt firmware upgrading tool (sysupgrade) refers "compatible" string 
> to validate new firmware file is surely "for this board".
> 
> currently both Pi E dts have "radxa,rockpi-e", it makes flashing wrong 
> firmware (include bootloaer, U-Boot) possible.

^Currently both Pi E firmware have ...

> Radxa ROCK Pi E v1.x(DDR3) and ROCK Pi E v3(DDR4) are different 
> incompatible boards, it must have different "compatible" string.
> 
> Best regards,
> 
> -- 
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.

Re: [PATCH v5 2/2] arm64: dts: rockchip: add support for Radxa ROCK Pi E v3.0

[Dragan Simic]

On 2024-08-17 22:04, FUKAUMI Naoki wrote:
> On 8/18/24 04:51, Dragan Simic wrote:
>> On 2024-08-17 21:28, Dragan Simic wrote:
>>> On 2024-08-17 00:20, FUKAUMI Naoki wrote:
>>>> On 8/17/24 07:11, Heiko Stübner wrote:
>>>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki:
>>>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the 
>>>>>> Rockchip
>>>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT 
>>>>>> configurations:
>>>>>> 
>>>>>> - Rockchip RK3328 SoC
>>>>>> - Quad A53 CPU
>>>>>> - 512MB/1GB/2GB DDR4 RAM
>>>> (snip)
>>>>> can you please describe what is different in that v3 board?
>>>>> Describing what is different to require a separate board should've 
>>>>> been
>>>>> part of the commit message.
>>>>> 
>>>>> Because from those changes, the bottom line currently seems to be
>>>>> the same board with swapped mmc aliases?
>>>> 
>>>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E).
>>>> different bootloader (U-Boot) is required.
>>>> 
>>>> adding v3 dts seems not to be so important for Linux, but it's very
>>>> important for U-Boot and OpenWrt(it includes bootloader for
>>>> distributed binary).
>>> 
>>> Aren't there different methods that allow such board variants to be
>>> supported in U-Boot, with no need for a separate DT in the kernel?
>>> IIRC, there are already more than a few examples of such board 
>>> variants,
>>> which require different DRAM initialization, which is covered in 
>>> U-Boot
>>> by providing different builds that use the same DT.
>> 
>> As an example, please have a look at the following files in U-Boot:
>> 
>> - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
>> - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi
>> - configs/nanopi-m4-rk3399_defconfig
>> - configs/nanopi-m4-2gb-rk3399_defconfig
>> 
>> Basically, there's no need for separate DTs in the kernel, just to 
>> support
>> board variants with different DRAM types in U-Boot.
> 
> OpenWrt firmware upgrading tool (sysupgrade) refers "compatible"
> string to validate new firmware file is surely "for this board".
> 
> currently both Pi E dts have "radxa,rockpi-e", it makes flashing wrong
> firmware (include bootloaer, U-Boot) possible.

Could you, please, explain what's the actual issue with OpenWrt?  I did
read some GitHub issue that described it, IIRC, but I was unable to 
fully
understand what's the underlying issue.

> Radxa ROCK Pi E v1.x(DDR3) and ROCK Pi E v3(DDR4) are different
> incompatible boards, it must have different "compatible" string.

Well, the above-mentioned Nano Pi M4 boards share the same DT and the 
same
"compatible" value, because for all consumers of the DT, except for 
U-Boot
that can already handle the differences, they are the same boards.

Re: [PATCH v5 2/2] arm64: dts: rockchip: add support for Radxa ROCK Pi E v3.0

[FUKAUMI Naoki]

On 8/18/24 05:12, Dragan Simic wrote:
> On 2024-08-17 22:04, FUKAUMI Naoki wrote:
>> On 8/18/24 04:51, Dragan Simic wrote:
>>> On 2024-08-17 21:28, Dragan Simic wrote:
>>>> On 2024-08-17 00:20, FUKAUMI Naoki wrote:
>>>>> On 8/17/24 07:11, Heiko Stübner wrote:
>>>>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki:
>>>>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the 
>>>>>>> Rockchip
>>>>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT 
>>>>>>> configurations:
>>>>>>>
>>>>>>> - Rockchip RK3328 SoC
>>>>>>> - Quad A53 CPU
>>>>>>> - 512MB/1GB/2GB DDR4 RAM
>>>>> (snip)
>>>>>> can you please describe what is different in that v3 board?
>>>>>> Describing what is different to require a separate board should've 
>>>>>> been
>>>>>> part of the commit message.
>>>>>>
>>>>>> Because from those changes, the bottom line currently seems to be
>>>>>> the same board with swapped mmc aliases?
>>>>>
>>>>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E).
>>>>> different bootloader (U-Boot) is required.
>>>>>
>>>>> adding v3 dts seems not to be so important for Linux, but it's very
>>>>> important for U-Boot and OpenWrt(it includes bootloader for
>>>>> distributed binary).
>>>>
>>>> Aren't there different methods that allow such board variants to be
>>>> supported in U-Boot, with no need for a separate DT in the kernel?
>>>> IIRC, there are already more than a few examples of such board 
>>>> variants,
>>>> which require different DRAM initialization, which is covered in U-Boot
>>>> by providing different builds that use the same DT.
>>>
>>> As an example, please have a look at the following files in U-Boot:
>>>
>>> - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
>>> - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi
>>> - configs/nanopi-m4-rk3399_defconfig
>>> - configs/nanopi-m4-2gb-rk3399_defconfig
>>>
>>> Basically, there's no need for separate DTs in the kernel, just to 
>>> support
>>> board variants with different DRAM types in U-Boot.
>>
>> OpenWrt firmware upgrading tool (sysupgrade) refers "compatible"
>> string to validate new firmware file is surely "for this board".
>>
>> currently both Pi E dts have "radxa,rockpi-e", it makes flashing wrong
>> firmware (include bootloaer, U-Boot) possible.
> 
> Could you, please, explain what's the actual issue with OpenWrt?  I did
> read some GitHub issue that described it, IIRC, but I was unable to fully
> understand what's the underlying issue.

$ wget 
https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz
$ strings openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz 
| grep metadata
{  "metadata_version": "1.1", "compat_version": "1.0", 
"supported_devices":["radxa,rock-pi-e"], "version": { "dist": "OpenWrt", 
"version": "SNAPSHOT", "revision": "r27160-b72c4b5386", "target": 
"rockchip/armv8", "board": "radxa_rock-pi-e" } }

$ wget 
https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz
$ strings 
openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz | grep 
metadata
{  "metadata_version": "1.1", "compat_version": "1.0", 
"supported_devices":["radxa,rock-pi-e-v3"], "version": { "dist": 
"OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386", 
"target": "rockchip/armv8", "board": "radxa_rock-pi-e-v3" } }

since they are incompatible firmware, it needs to have different 
"supported_devices" string. if both are "radxa,rockpi-e", firmware 
validation will not work correctly.

(currently both values are wrong, it needs to be fixed, but it's another 
story)

>> Radxa ROCK Pi E v1.x(DDR3) and ROCK Pi E v3(DDR4) are different
>> incompatible boards, it must have different "compatible" string.
> 
> Well, the above-mentioned Nano Pi M4 boards share the same DT and the same
> "compatible" value, because for all consumers of the DT, except for U-Boot
> that can already handle the differences, they are the same boards.

(un)fortunately Nano Pi M4 boards seems not to be supported by OpenWrt

  https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

Re: [PATCH v5 2/2] arm64: dts: rockchip: add support for Radxa ROCK Pi E v3.0

[FUKAUMI Naoki]

for the record,

 
https://openwrt.org/docs/guide-developer/device-support-policies#modeldevice_name
  https://openwrt.org/docs/techref/sysupgrade

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

On 8/18/24 05:28, FUKAUMI Naoki wrote:
> On 8/18/24 05:12, Dragan Simic wrote:
>> On 2024-08-17 22:04, FUKAUMI Naoki wrote:
>>> On 8/18/24 04:51, Dragan Simic wrote:
>>>> On 2024-08-17 21:28, Dragan Simic wrote:
>>>>> On 2024-08-17 00:20, FUKAUMI Naoki wrote:
>>>>>> On 8/17/24 07:11, Heiko Stübner wrote:
>>>>>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki:
>>>>>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the 
>>>>>>>> Rockchip
>>>>>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT 
>>>>>>>> configurations:
>>>>>>>>
>>>>>>>> - Rockchip RK3328 SoC
>>>>>>>> - Quad A53 CPU
>>>>>>>> - 512MB/1GB/2GB DDR4 RAM
>>>>>> (snip)
>>>>>>> can you please describe what is different in that v3 board?
>>>>>>> Describing what is different to require a separate board 
>>>>>>> should've been
>>>>>>> part of the commit message.
>>>>>>>
>>>>>>> Because from those changes, the bottom line currently seems to be
>>>>>>> the same board with swapped mmc aliases?
>>>>>>
>>>>>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E).
>>>>>> different bootloader (U-Boot) is required.
>>>>>>
>>>>>> adding v3 dts seems not to be so important for Linux, but it's very
>>>>>> important for U-Boot and OpenWrt(it includes bootloader for
>>>>>> distributed binary).
>>>>>
>>>>> Aren't there different methods that allow such board variants to be
>>>>> supported in U-Boot, with no need for a separate DT in the kernel?
>>>>> IIRC, there are already more than a few examples of such board 
>>>>> variants,
>>>>> which require different DRAM initialization, which is covered in 
>>>>> U-Boot
>>>>> by providing different builds that use the same DT.
>>>>
>>>> As an example, please have a look at the following files in U-Boot:
>>>>
>>>> - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
>>>> - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi
>>>> - configs/nanopi-m4-rk3399_defconfig
>>>> - configs/nanopi-m4-2gb-rk3399_defconfig
>>>>
>>>> Basically, there's no need for separate DTs in the kernel, just to 
>>>> support
>>>> board variants with different DRAM types in U-Boot.
>>>
>>> OpenWrt firmware upgrading tool (sysupgrade) refers "compatible"
>>> string to validate new firmware file is surely "for this board".
>>>
>>> currently both Pi E dts have "radxa,rockpi-e", it makes flashing wrong
>>> firmware (include bootloaer, U-Boot) possible.
>>
>> Could you, please, explain what's the actual issue with OpenWrt?  I did
>> read some GitHub issue that described it, IIRC, but I was unable to fully
>> understand what's the underlying issue.
> 
> $ wget 
> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz
> $ strings openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz 
> | grep metadata
> {  "metadata_version": "1.1", "compat_version": "1.0", 
> "supported_devices":["radxa,rock-pi-e"], "version": { "dist": "OpenWrt", 
> "version": "SNAPSHOT", "revision": "r27160-b72c4b5386", "target": 
> "rockchip/armv8", "board": "radxa_rock-pi-e" } }
> 
> $ wget 
> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz
> $ strings 
> openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz | grep 
> metadata
> {  "metadata_version": "1.1", "compat_version": "1.0", 
> "supported_devices":["radxa,rock-pi-e-v3"], "version": { "dist": 
> "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386", 
> "target": "rockchip/armv8", "board": "radxa_rock-pi-e-v3" } }
> 
> since they are incompatible firmware, it needs to have different 
> "supported_devices" string. if both are "radxa,rockpi-e", firmware 
> validation will not work correctly.
> 
> (currently both values are wrong, it needs to be fixed, but it's another 
> story)
> 
>>> Radxa ROCK Pi E v1.x(DDR3) and ROCK Pi E v3(DDR4) are different
>>> incompatible boards, it must have different "compatible" string.
>>
>> Well, the above-mentioned Nano Pi M4 boards share the same DT and the 
>> same
>> "compatible" value, because for all consumers of the DT, except for 
>> U-Boot
>> that can already handle the differences, they are the same boards.
> 
> (un)fortunately Nano Pi M4 boards seems not to be supported by OpenWrt
> 
>   https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/
> 
> Best regards,
> 
> -- 
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.

Re: [PATCH v5 2/2] arm64: dts: rockchip: add support for Radxa ROCK Pi E v3.0

[Dragan Simic]

On 2024-08-17 22:28, FUKAUMI Naoki wrote:
> On 8/18/24 05:12, Dragan Simic wrote:
>> On 2024-08-17 22:04, FUKAUMI Naoki wrote:
>>> On 8/18/24 04:51, Dragan Simic wrote:
>>>> On 2024-08-17 21:28, Dragan Simic wrote:
>>>>> On 2024-08-17 00:20, FUKAUMI Naoki wrote:
>>>>>> On 8/17/24 07:11, Heiko Stübner wrote:
>>>>>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki:
>>>>>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the 
>>>>>>>> Rockchip
>>>>>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT 
>>>>>>>> configurations:
>>>>>>>> 
>>>>>>>> - Rockchip RK3328 SoC
>>>>>>>> - Quad A53 CPU
>>>>>>>> - 512MB/1GB/2GB DDR4 RAM
>>>>>> (snip)
>>>>>>> can you please describe what is different in that v3 board?
>>>>>>> Describing what is different to require a separate board 
>>>>>>> should've been
>>>>>>> part of the commit message.
>>>>>>> 
>>>>>>> Because from those changes, the bottom line currently seems to be
>>>>>>> the same board with swapped mmc aliases?
>>>>>> 
>>>>>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E).
>>>>>> different bootloader (U-Boot) is required.
>>>>>> 
>>>>>> adding v3 dts seems not to be so important for Linux, but it's 
>>>>>> very
>>>>>> important for U-Boot and OpenWrt(it includes bootloader for
>>>>>> distributed binary).
>>>>> 
>>>>> Aren't there different methods that allow such board variants to be
>>>>> supported in U-Boot, with no need for a separate DT in the kernel?
>>>>> IIRC, there are already more than a few examples of such board 
>>>>> variants,
>>>>> which require different DRAM initialization, which is covered in 
>>>>> U-Boot
>>>>> by providing different builds that use the same DT.
>>>> 
>>>> As an example, please have a look at the following files in U-Boot:
>>>> 
>>>> - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
>>>> - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi
>>>> - configs/nanopi-m4-rk3399_defconfig
>>>> - configs/nanopi-m4-2gb-rk3399_defconfig
>>>> 
>>>> Basically, there's no need for separate DTs in the kernel, just to 
>>>> support
>>>> board variants with different DRAM types in U-Boot.
>>> 
>>> OpenWrt firmware upgrading tool (sysupgrade) refers "compatible"
>>> string to validate new firmware file is surely "for this board".
>>> 
>>> currently both Pi E dts have "radxa,rockpi-e", it makes flashing 
>>> wrong
>>> firmware (include bootloaer, U-Boot) possible.
>> 
>> Could you, please, explain what's the actual issue with OpenWrt?  I 
>> did
>> read some GitHub issue that described it, IIRC, but I was unable to 
>> fully
>> understand what's the underlying issue.
> 
> $ wget
> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz
> $ strings
> openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz | grep
> metadata
> {  "metadata_version": "1.1", "compat_version": "1.0",
> "supported_devices":["radxa,rock-pi-e"], "version": { "dist":
> "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386",
> "target": "rockchip/armv8", "board": "radxa_rock-pi-e" } }
> 
> $ wget
> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz
> $ strings
> openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz |
> grep metadata
> {  "metadata_version": "1.1", "compat_version": "1.0",
> "supported_devices":["radxa,rock-pi-e-v3"], "version": { "dist":
> "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386",
> "target": "rockchip/armv8", "board": "radxa_rock-pi-e-v3" } }
> 
> since they are incompatible firmware, it needs to have different
> "supported_devices" string. if both are "radxa,rockpi-e", firmware
> validation will not work correctly.
> 
> (currently both values are wrong, it needs to be fixed, but it's 
> another story)
> 
>>> Radxa ROCK Pi E v1.x(DDR3) and ROCK Pi E v3(DDR4) are different
>>> incompatible boards, it must have different "compatible" string.
>> 
>> Well, the above-mentioned Nano Pi M4 boards share the same DT and the 
>> same
>> "compatible" value, because for all consumers of the DT, except for 
>> U-Boot
>> that can already handle the differences, they are the same boards.
> 
> (un)fortunately Nano Pi M4 boards seems not to be supported by OpenWrt
> 
>  https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/

Thanks for the explanations.  As discussed further in #linux-rockchip
on Libera.Chat, we do need a general solution for this issue, which 
would
get us covered for all the board variants that use different DRAM chips,
which are currently known to U-Boot only.

I'll keep thinking about this in the next couple of days, and I'll come
back with an update.

Re: [PATCH v5 2/2] arm64: dts: rockchip: add support for Radxa ROCK Pi E v3.0

[Dragan Simic]

Hello Naoki,

On 2024-08-18 00:30, Dragan Simic wrote:
> On 2024-08-17 22:28, FUKAUMI Naoki wrote:
>> On 8/18/24 05:12, Dragan Simic wrote:
>>> On 2024-08-17 22:04, FUKAUMI Naoki wrote:
>>>> On 8/18/24 04:51, Dragan Simic wrote:
>>>>> On 2024-08-17 21:28, Dragan Simic wrote:
>>>>>> On 2024-08-17 00:20, FUKAUMI Naoki wrote:
>>>>>>> On 8/17/24 07:11, Heiko Stübner wrote:
>>>>>>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI 
>>>>>>>> Naoki:
>>>>>>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the 
>>>>>>>>> Rockchip
>>>>>>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT 
>>>>>>>>> configurations:
>>>>>>>>> 
>>>>>>>>> - Rockchip RK3328 SoC
>>>>>>>>> - Quad A53 CPU
>>>>>>>>> - 512MB/1GB/2GB DDR4 RAM
>>>>>>> (snip)
>>>>>>>> can you please describe what is different in that v3 board?
>>>>>>>> Describing what is different to require a separate board 
>>>>>>>> should've been
>>>>>>>> part of the commit message.
>>>>>>>> 
>>>>>>>> Because from those changes, the bottom line currently seems to 
>>>>>>>> be
>>>>>>>> the same board with swapped mmc aliases?
>>>>>>> 
>>>>>>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E).
>>>>>>> different bootloader (U-Boot) is required.
>>>>>>> 
>>>>>>> adding v3 dts seems not to be so important for Linux, but it's 
>>>>>>> very
>>>>>>> important for U-Boot and OpenWrt(it includes bootloader for
>>>>>>> distributed binary).
>>>>>> 
>>>>>> Aren't there different methods that allow such board variants to 
>>>>>> be
>>>>>> supported in U-Boot, with no need for a separate DT in the kernel?
>>>>>> IIRC, there are already more than a few examples of such board 
>>>>>> variants,
>>>>>> which require different DRAM initialization, which is covered in 
>>>>>> U-Boot
>>>>>> by providing different builds that use the same DT.
>>>>> 
>>>>> As an example, please have a look at the following files in U-Boot:
>>>>> 
>>>>> - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
>>>>> - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi
>>>>> - configs/nanopi-m4-rk3399_defconfig
>>>>> - configs/nanopi-m4-2gb-rk3399_defconfig
>>>>> 
>>>>> Basically, there's no need for separate DTs in the kernel, just to 
>>>>> support
>>>>> board variants with different DRAM types in U-Boot.
>>>> 
>>>> OpenWrt firmware upgrading tool (sysupgrade) refers "compatible"
>>>> string to validate new firmware file is surely "for this board".
>>>> 
>>>> currently both Pi E dts have "radxa,rockpi-e", it makes flashing 
>>>> wrong
>>>> firmware (include bootloaer, U-Boot) possible.
>>> 
>>> Could you, please, explain what's the actual issue with OpenWrt?  I 
>>> did
>>> read some GitHub issue that described it, IIRC, but I was unable to 
>>> fully
>>> understand what's the underlying issue.
>> 
>> $ wget
>> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz
>> $ strings
>> openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz | grep
>> metadata
>> {  "metadata_version": "1.1", "compat_version": "1.0",
>> "supported_devices":["radxa,rock-pi-e"], "version": { "dist":
>> "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386",
>> "target": "rockchip/armv8", "board": "radxa_rock-pi-e" } }
>> 
>> $ wget
>> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz
>> $ strings
>> openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz |
>> grep metadata
>> {  "metadata_version": "1.1", "compat_version": "1.0",
>> "supported_devices":["radxa,rock-pi-e-v3"], "version": { "dist":
>> "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386",
>> "target": "rockchip/armv8", "board": "radxa_rock-pi-e-v3" } }
>> 
>> since they are incompatible firmware, it needs to have different
>> "supported_devices" string. if both are "radxa,rockpi-e", firmware
>> validation will not work correctly.
>> 
>> (currently both values are wrong, it needs to be fixed, but it's 
>> another story)
>> 
>>>> Radxa ROCK Pi E v1.x(DDR3) and ROCK Pi E v3(DDR4) are different
>>>> incompatible boards, it must have different "compatible" string.
>>> 
>>> Well, the above-mentioned Nano Pi M4 boards share the same DT and the 
>>> same
>>> "compatible" value, because for all consumers of the DT, except for 
>>> U-Boot
>>> that can already handle the differences, they are the same boards.
>> 
>> (un)fortunately Nano Pi M4 boards seems not to be supported by OpenWrt
>> 
>>  https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/
> 
> Thanks for the explanations.  As discussed further in #linux-rockchip
> on Libera.Chat, we do need a general solution for this issue, which 
> would
> get us covered for all the board variants that use different DRAM 
> chips,
> which are currently known to U-Boot only.
> 
> I'll keep thinking about this in the next couple of days, and I'll come
> back with an update.

As a separate thought, is there some way to detect the actual ROCK Pi E
board variant at runtime, using some GPIO line, ADC readout, or 
something
similar?  That would help with making it possible to have a single 
U-Boot
build for both board variants.

Re: [PATCH v5 2/2] arm64: dts: rockchip: add support for Radxa ROCK Pi E v3.0

[FUKAUMI Naoki]

Hi,

On 8/26/24 20:25, Dragan Simic wrote:
> Hello Naoki,
> 
> On 2024-08-18 00:30, Dragan Simic wrote:
>> On 2024-08-17 22:28, FUKAUMI Naoki wrote:
>>> On 8/18/24 05:12, Dragan Simic wrote:
>>>> On 2024-08-17 22:04, FUKAUMI Naoki wrote:
>>>>> On 8/18/24 04:51, Dragan Simic wrote:
>>>>>> On 2024-08-17 21:28, Dragan Simic wrote:
>>>>>>> On 2024-08-17 00:20, FUKAUMI Naoki wrote:
>>>>>>>> On 8/17/24 07:11, Heiko Stübner wrote:
>>>>>>>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki:
>>>>>>>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the 
>>>>>>>>>> Rockchip
>>>>>>>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT 
>>>>>>>>>> configurations:
>>>>>>>>>>
>>>>>>>>>> - Rockchip RK3328 SoC
>>>>>>>>>> - Quad A53 CPU
>>>>>>>>>> - 512MB/1GB/2GB DDR4 RAM
>>>>>>>> (snip)
>>>>>>>>> can you please describe what is different in that v3 board?
>>>>>>>>> Describing what is different to require a separate board 
>>>>>>>>> should've been
>>>>>>>>> part of the commit message.
>>>>>>>>>
>>>>>>>>> Because from those changes, the bottom line currently seems to be
>>>>>>>>> the same board with swapped mmc aliases?
>>>>>>>>
>>>>>>>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E).
>>>>>>>> different bootloader (U-Boot) is required.
>>>>>>>>
>>>>>>>> adding v3 dts seems not to be so important for Linux, but it's very
>>>>>>>> important for U-Boot and OpenWrt(it includes bootloader for
>>>>>>>> distributed binary).
>>>>>>>
>>>>>>> Aren't there different methods that allow such board variants to be
>>>>>>> supported in U-Boot, with no need for a separate DT in the kernel?
>>>>>>> IIRC, there are already more than a few examples of such board 
>>>>>>> variants,
>>>>>>> which require different DRAM initialization, which is covered in 
>>>>>>> U-Boot
>>>>>>> by providing different builds that use the same DT.
>>>>>>
>>>>>> As an example, please have a look at the following files in U-Boot:
>>>>>>
>>>>>> - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
>>>>>> - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi
>>>>>> - configs/nanopi-m4-rk3399_defconfig
>>>>>> - configs/nanopi-m4-2gb-rk3399_defconfig
>>>>>>
>>>>>> Basically, there's no need for separate DTs in the kernel, just to 
>>>>>> support
>>>>>> board variants with different DRAM types in U-Boot.
>>>>>
>>>>> OpenWrt firmware upgrading tool (sysupgrade) refers "compatible"
>>>>> string to validate new firmware file is surely "for this board".
>>>>>
>>>>> currently both Pi E dts have "radxa,rockpi-e", it makes flashing wrong
>>>>> firmware (include bootloaer, U-Boot) possible.
>>>>
>>>> Could you, please, explain what's the actual issue with OpenWrt?  I did
>>>> read some GitHub issue that described it, IIRC, but I was unable to 
>>>> fully
>>>> understand what's the underlying issue.
>>>
>>> $ wget
>>> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz
>>> $ strings
>>> openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz | grep
>>> metadata
>>> {  "metadata_version": "1.1", "compat_version": "1.0",
>>> "supported_devices":["radxa,rock-pi-e"], "version": { "dist":
>>> "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386",
>>> "target": "rockchip/armv8", "board": "radxa_rock-pi-e" } }
>>>
>>> $ wget
>>> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz
>>> $ strings
>>> openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz |
>>> grep metadata
>>> {  "metadata_version": "1.1", "compat_version": "1.0",
>>> "supported_devices":["radxa,rock-pi-e-v3"], "version": { "dist":
>>> "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386",
>>> "target": "rockchip/armv8", "board": "radxa_rock-pi-e-v3" } }
>>>
>>> since they are incompatible firmware, it needs to have different
>>> "supported_devices" string. if both are "radxa,rockpi-e", firmware
>>> validation will not work correctly.
>>>
>>> (currently both values are wrong, it needs to be fixed, but it's 
>>> another story)
>>>
>>>>> Radxa ROCK Pi E v1.x(DDR3) and ROCK Pi E v3(DDR4) are different
>>>>> incompatible boards, it must have different "compatible" string.
>>>>
>>>> Well, the above-mentioned Nano Pi M4 boards share the same DT and 
>>>> the same
>>>> "compatible" value, because for all consumers of the DT, except for 
>>>> U-Boot
>>>> that can already handle the differences, they are the same boards.
>>>
>>> (un)fortunately Nano Pi M4 boards seems not to be supported by OpenWrt
>>>
>>>  https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/
>>
>> Thanks for the explanations.  As discussed further in #linux-rockchip
>> on Libera.Chat, we do need a general solution for this issue, which would
>> get us covered for all the board variants that use different DRAM chips,
>> which are currently known to U-Boot only.
>>
>> I'll keep thinking about this in the next couple of days, and I'll come
>> back with an update.
> 
> As a separate thought, is there some way to detect the actual ROCK Pi E
> board variant at runtime, using some GPIO line, ADC readout, or something
> similar?  That would help with making it possible to have a single U-Boot
> build for both board variants.

as far as I know, no difference. (I asked my colleague)
I will compare schematics.

but, if there is difference, is it possible to replace RAM 
initialization on u-boot?

btw, RFC:
 
https://github.com/RadxaNaoki/u-boot/commit/ff1aa39ffb725d10fbb1608062debe6657f40acc

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

Re: [PATCH v5 2/2] arm64: dts: rockchip: add support for Radxa ROCK Pi E v3.0

[FUKAUMI Naoki]

Hi,

RFC:
https://patchwork.ozlabs.org/project/uboot/patch/20240827013111.633-1-naoki@radxa.com/

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

On 8/27/24 08:20, FUKAUMI Naoki wrote:
> Hi,
> 
> On 8/26/24 20:25, Dragan Simic wrote:
>> Hello Naoki,
>>
>> On 2024-08-18 00:30, Dragan Simic wrote:
>>> On 2024-08-17 22:28, FUKAUMI Naoki wrote:
>>>> On 8/18/24 05:12, Dragan Simic wrote:
>>>>> On 2024-08-17 22:04, FUKAUMI Naoki wrote:
>>>>>> On 8/18/24 04:51, Dragan Simic wrote:
>>>>>>> On 2024-08-17 21:28, Dragan Simic wrote:
>>>>>>>> On 2024-08-17 00:20, FUKAUMI Naoki wrote:
>>>>>>>>> On 8/17/24 07:11, Heiko Stübner wrote:
>>>>>>>>>> Am Freitag, 16. August 2024, 23:34:29 CEST schrieb FUKAUMI Naoki:
>>>>>>>>>>> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the 
>>>>>>>>>>> Rockchip
>>>>>>>>>>> RK3328 chip that ships in a number of RAM/eMMC/WiFi/BT 
>>>>>>>>>>> configurations:
>>>>>>>>>>>
>>>>>>>>>>> - Rockchip RK3328 SoC
>>>>>>>>>>> - Quad A53 CPU
>>>>>>>>>>> - 512MB/1GB/2GB DDR4 RAM
>>>>>>>>> (snip)
>>>>>>>>>> can you please describe what is different in that v3 board?
>>>>>>>>>> Describing what is different to require a separate board 
>>>>>>>>>> should've been
>>>>>>>>>> part of the commit message.
>>>>>>>>>>
>>>>>>>>>> Because from those changes, the bottom line currently seems to be
>>>>>>>>>> the same board with swapped mmc aliases?
>>>>>>>>>
>>>>>>>>> it's new board which uses DDR4 RAM (instead of DDR3 RAM on Pi E).
>>>>>>>>> different bootloader (U-Boot) is required.
>>>>>>>>>
>>>>>>>>> adding v3 dts seems not to be so important for Linux, but it's 
>>>>>>>>> very
>>>>>>>>> important for U-Boot and OpenWrt(it includes bootloader for
>>>>>>>>> distributed binary).
>>>>>>>>
>>>>>>>> Aren't there different methods that allow such board variants to be
>>>>>>>> supported in U-Boot, with no need for a separate DT in the kernel?
>>>>>>>> IIRC, there are already more than a few examples of such board 
>>>>>>>> variants,
>>>>>>>> which require different DRAM initialization, which is covered in 
>>>>>>>> U-Boot
>>>>>>>> by providing different builds that use the same DT.
>>>>>>>
>>>>>>> As an example, please have a look at the following files in U-Boot:
>>>>>>>
>>>>>>> - arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi
>>>>>>> - arch/arm/dts/rk3399-nanopi-m4-2gb-u-boot.dtsi
>>>>>>> - configs/nanopi-m4-rk3399_defconfig
>>>>>>> - configs/nanopi-m4-2gb-rk3399_defconfig
>>>>>>>
>>>>>>> Basically, there's no need for separate DTs in the kernel, just 
>>>>>>> to support
>>>>>>> board variants with different DRAM types in U-Boot.
>>>>>>
>>>>>> OpenWrt firmware upgrading tool (sysupgrade) refers "compatible"
>>>>>> string to validate new firmware file is surely "for this board".
>>>>>>
>>>>>> currently both Pi E dts have "radxa,rockpi-e", it makes flashing 
>>>>>> wrong
>>>>>> firmware (include bootloaer, U-Boot) possible.
>>>>>
>>>>> Could you, please, explain what's the actual issue with OpenWrt?  I 
>>>>> did
>>>>> read some GitHub issue that described it, IIRC, but I was unable to 
>>>>> fully
>>>>> understand what's the underlying issue.
>>>>
>>>> $ wget
>>>> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz
>>>> $ strings
>>>> openwrt-rockchip-armv8-radxa_rock-pi-e-ext4-sysupgrade.img.gz | grep
>>>> metadata
>>>> {  "metadata_version": "1.1", "compat_version": "1.0",
>>>> "supported_devices":["radxa,rock-pi-e"], "version": { "dist":
>>>> "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386",
>>>> "target": "rockchip/armv8", "board": "radxa_rock-pi-e" } }
>>>>
>>>> $ wget
>>>> https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz
>>>> $ strings
>>>> openwrt-rockchip-armv8-radxa_rock-pi-e-v3-ext4-sysupgrade.img.gz |
>>>> grep metadata
>>>> {  "metadata_version": "1.1", "compat_version": "1.0",
>>>> "supported_devices":["radxa,rock-pi-e-v3"], "version": { "dist":
>>>> "OpenWrt", "version": "SNAPSHOT", "revision": "r27160-b72c4b5386",
>>>> "target": "rockchip/armv8", "board": "radxa_rock-pi-e-v3" } }
>>>>
>>>> since they are incompatible firmware, it needs to have different
>>>> "supported_devices" string. if both are "radxa,rockpi-e", firmware
>>>> validation will not work correctly.
>>>>
>>>> (currently both values are wrong, it needs to be fixed, but it's 
>>>> another story)
>>>>
>>>>>> Radxa ROCK Pi E v1.x(DDR3) and ROCK Pi E v3(DDR4) are different
>>>>>> incompatible boards, it must have different "compatible" string.
>>>>>
>>>>> Well, the above-mentioned Nano Pi M4 boards share the same DT and 
>>>>> the same
>>>>> "compatible" value, because for all consumers of the DT, except for 
>>>>> U-Boot
>>>>> that can already handle the differences, they are the same boards.
>>>>
>>>> (un)fortunately Nano Pi M4 boards seems not to be supported by OpenWrt
>>>>
>>>>  https://downloads.openwrt.org/snapshots/targets/rockchip/armv8/
>>>
>>> Thanks for the explanations.  As discussed further in #linux-rockchip
>>> on Libera.Chat, we do need a general solution for this issue, which 
>>> would
>>> get us covered for all the board variants that use different DRAM chips,
>>> which are currently known to U-Boot only.
>>>
>>> I'll keep thinking about this in the next couple of days, and I'll come
>>> back with an update.
>>
>> As a separate thought, is there some way to detect the actual ROCK Pi E
>> board variant at runtime, using some GPIO line, ADC readout, or something
>> similar?  That would help with making it possible to have a single U-Boot
>> build for both board variants.
> 
> as far as I know, no difference. (I asked my colleague)
> I will compare schematics.
> 
> but, if there is difference, is it possible to replace RAM 
> initialization on u-boot?
> 
> btw, RFC:
> 
> https://github.com/RadxaNaoki/u-boot/commit/ff1aa39ffb725d10fbb1608062debe6657f40acc
> 
> -- 
> FUKAUMI Naoki
> Radxa Computer (Shenzhen) Co., Ltd.

Re: [PATCH v5 1/2] dt-bindings: arm: rockchip: add support for Radxa ROCK Pi E v3.0

[Krzysztof Kozlowski]

On 16/08/2024 23:34, FUKAUMI Naoki wrote:
> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the Rockchip
> RK3328 chip.
> 
> [1] https://radxa.com/products/rockpi/pie
> 
> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>

Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>

Best regards,
Krzysztof

Re: [PATCH v5 1/2] dt-bindings: arm: rockchip: add support for Radxa ROCK Pi E v3.0

[Rob Herring (Arm)]

On Sat, 17 Aug 2024 06:34:28 +0900, FUKAUMI Naoki wrote:
> Radxa ROCK Pi E v3.0 is a compact networking SBC[1] using the Rockchip
> RK3328 chip.
> 
> [1] https://radxa.com/products/rockpi/pie
> 
> Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
> ---
> Changes in v5:
> - revert compatible string
> - describe rockchip.yaml properly
> Changes in v4:
> - update compatible string for OpenWrt
> - drop A-b tag
> Changes in v3:
> - collect A-b tag
> Changes in v2:
> - fix typo in commit message
> - add missing --- in commit message
> - add new section instead of new item in rockchip.yaml
> ---
>  Documentation/devicetree/bindings/arm/rockchip.yaml | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 


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


New warnings running 'make CHECK_DTBS=y rockchip/rk3328-rock-pi-e-v3.dtb rockchip/rk3328-rock-pi-e.dtb' for 20240816213429.1093-1-naoki@radxa.com:

arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dtb: hdmi@ff3c0000: interrupts: [[0, 35, 4], [0, 71, 4]] is too long
	from schema $id: http://devicetree.org/schemas/display/rockchip/rockchip,dw-hdmi.yaml#
arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dtb: /phy@ff430000: failed to match any schema with compatible: ['rockchip,rk3328-hdmi-phy']
arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dtb: /clock-controller@ff440000: failed to match any schema with compatible: ['rockchip,rk3328-cru', 'rockchip,cru', 'syscon']
arch/arm64/boot/dts/rockchip/rk3328-rock-pi-e-v3.dtb: /clock-controller@ff440000: failed to match any schema with compatible: ['rockchip,rk3328-cru', 'rockchip,cru', 'syscon']