* [PATCH 1/4] dt-bindings: vendor-prefixes: Add HINLINK
2025-08-18 10:00 [PATCH 0/4] arm64: dts: rockchip: Add HINLINK H66K/H68K Chukun Pan
@ 2025-08-18 10:00 ` Chukun Pan
2025-08-18 10:00 ` [PATCH 2/4] dt-bindings: arm: rockchip: Add HINLINK H66K / H68K Chukun Pan
` (4 subsequent siblings)
5 siblings, 0 replies; 24+ messages in thread
From: Chukun Pan @ 2025-08-18 10:00 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Chukun Pan, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
linux-arm-kernel, linux-rockchip, linux-kernel, devicetree
Add vendor prefix for HINLINK, which is an SBC manufacturer.
Link: https://www.hinlink.cn/
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index a92261b10c52..7ce1970d3125 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -648,6 +648,8 @@ patternProperties:
description: HiDeep Inc.
"^himax,.*":
description: Himax Technologies, Inc.
+ "^hinlink,.*":
+ description: Shenzhen HINLINK Technology Co., Ltd.
"^hirschmann,.*":
description: Hirschmann Automation and Control GmbH
"^hisi,.*":
--
2.25.1
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH 2/4] dt-bindings: arm: rockchip: Add HINLINK H66K / H68K
2025-08-18 10:00 [PATCH 0/4] arm64: dts: rockchip: Add HINLINK H66K/H68K Chukun Pan
2025-08-18 10:00 ` [PATCH 1/4] dt-bindings: vendor-prefixes: Add HINLINK Chukun Pan
@ 2025-08-18 10:00 ` Chukun Pan
2025-08-18 10:00 ` [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K Chukun Pan
` (3 subsequent siblings)
5 siblings, 0 replies; 24+ messages in thread
From: Chukun Pan @ 2025-08-18 10:00 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Chukun Pan, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
linux-arm-kernel, linux-rockchip, linux-kernel, devicetree
The HINLINK H66K/H68K are 2.5GbE SBC based on the RK3568 SoC.
Add devicetree binding documentation for them.
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
---
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..870c318fc8d4 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -683,6 +683,13 @@ properties:
- const: hardkernel,odroid-m2
- const: rockchip,rk3588s
+ - description: HINLINK H66K / H68K
+ items:
+ - enum:
+ - hinlink,h66k
+ - hinlink,h68k
+ - const: rockchip,rk3568
+
- description: Hugsun X99 TV Box
items:
- const: hugsun,x99
--
2.25.1
^ permalink raw reply related [flat|nested] 24+ messages in thread* [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K
2025-08-18 10:00 [PATCH 0/4] arm64: dts: rockchip: Add HINLINK H66K/H68K Chukun Pan
2025-08-18 10:00 ` [PATCH 1/4] dt-bindings: vendor-prefixes: Add HINLINK Chukun Pan
2025-08-18 10:00 ` [PATCH 2/4] dt-bindings: arm: rockchip: Add HINLINK H66K / H68K Chukun Pan
@ 2025-08-18 10:00 ` Chukun Pan
2025-08-30 21:14 ` Erik Beck
2025-08-18 10:00 ` [PATCH 4/4] arm64: dts: rockchip: Add HINLINK H66K Chukun Pan
` (2 subsequent siblings)
5 siblings, 1 reply; 24+ messages in thread
From: Chukun Pan @ 2025-08-18 10:00 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Chukun Pan, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
linux-arm-kernel, linux-rockchip, linux-kernel, devicetree
The HINLINK H68K is a development board with the
Rockchip RK3568 SoC. It has the following features:
- 2/4GB LPDDR4
- 1x HDMI Type A
- 3.5mm jack with mic
- 1x PCIE 2.0 WiFi slot
- 1x USB 3.0, 2x USB 2.0
- 2x 1GbE RTL8211F Ethernet
- 2x 2.5GbE RTL8125B Ethernet
- MicroSD card slot / eMMC 32GB
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../boot/dts/rockchip/rk3568-hinlink-h68k.dts | 83 +++
.../boot/dts/rockchip/rk3568-hinlink-opc.dtsi | 666 ++++++++++++++++++
3 files changed, 750 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-hinlink-h68k.dts
create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-hinlink-opc.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 099520962ffb..09c810cb64a4 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -130,6 +130,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-bpi-r2-pro.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-evb1-v10.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-fastrhino-r66s.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-fastrhino-r68s.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-hinlink-h68k.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-lubancat-2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-mecsbc.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-nanopi-r5c.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-hinlink-h68k.dts b/arch/arm64/boot/dts/rockchip/rk3568-hinlink-h68k.dts
new file mode 100644
index 000000000000..793ee651b868
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-hinlink-h68k.dts
@@ -0,0 +1,83 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3568-hinlink-opc.dtsi"
+
+/ {
+ model = "HINLINK H68K";
+ compatible = "hinlink,h68k", "rockchip,rk3568";
+
+ aliases {
+ ethernet0 = &gmac0;
+ ethernet1 = &gmac1;
+ };
+};
+
+&gmac0 {
+ assigned-clocks = <&cru SCLK_GMAC0_RX_TX>, <&cru SCLK_GMAC0>;
+ assigned-clock-parents = <&cru SCLK_GMAC0_RGMII_SPEED>;
+ assigned-clock-rates = <0>, <125000000>;
+ clock_in_out = "output";
+ phy-handle = <&rgmii_phy0>;
+ phy-mode = "rgmii-id";
+ phy-supply = <&vcc3v3_sys>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac0_miim
+ &gmac0_tx_bus2
+ &gmac0_rx_bus2
+ &gmac0_rgmii_clk
+ &gmac0_rgmii_bus
+ &gmac0_rstn>;
+ status = "okay";
+};
+
+&gmac1 {
+ assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>;
+ assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>;
+ assigned-clock-rates = <0>, <125000000>;
+ clock_in_out = "output";
+ phy-handle = <&rgmii_phy1>;
+ phy-mode = "rgmii-id";
+ phy-supply = <&vcc3v3_sys>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&gmac1m1_miim
+ &gmac1m1_tx_bus2
+ &gmac1m1_rx_bus2
+ &gmac1m1_rgmii_clk
+ &gmac1m1_rgmii_bus
+ &gmac1_rstn>;
+ status = "okay";
+};
+
+&mdio0 {
+ rgmii_phy0: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0x1>;
+ reset-assert-us = <20000>;
+ reset-deassert-us = <100000>;
+ reset-gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&mdio1 {
+ rgmii_phy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0x1>;
+ reset-assert-us = <20000>;
+ reset-deassert-us = <100000>;
+ reset-gpios = <&gpio1 RK_PB0 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&pinctrl {
+ gmac {
+ gmac0_rstn: gmac0-rstn {
+ rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ gmac1_rstn: gmac1-rstn {
+ rockchip,pins = <1 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-hinlink-opc.dtsi b/arch/arm64/boot/dts/rockchip/rk3568-hinlink-opc.dtsi
new file mode 100644
index 000000000000..14f3839ca091
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-hinlink-opc.dtsi
@@ -0,0 +1,666 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#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 <dt-bindings/soc/rockchip,vop2.h>
+#include "rk3568.dtsi"
+
+/ {
+ aliases {
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc0;
+ };
+
+ chosen {
+ stdout-path = "serial2:1500000n8";
+ };
+
+ hdmi-con {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
+ ir-receiver {
+ compatible = "gpio-ir-receiver";
+ gpios = <&gpio0 RK_PC2 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm3_ir_m0>;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+ pinctrl-names = "default";
+ pinctrl-0 = <&factory>;
+
+ button-factory {
+ label = "factory";
+ linux,code = <KEY_RESTART>;
+ gpios = <&gpio0 RK_PA0 GPIO_ACTIVE_LOW>;
+ debounce-interval = <50>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&green_led>, <&red_led>, <&work_led>;
+
+ led-0 {
+ color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_WAN;
+ gpios = <&gpio3 RK_PA5 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "netdev";
+ };
+
+ led-1 {
+ color = <LED_COLOR_ID_AMBER>;
+ function = LED_FUNCTION_DISK;
+ gpios = <&gpio3 RK_PA7 GPIO_ACTIVE_HIGH>;
+ };
+
+ led-2 {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ };
+ };
+
+ vcc0v9_2g5: regulator-0v9-vcc-2g5 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc0v9_2g5";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vcc12v_dcinp: regulator-12v-vcc-dcinp {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc12v_dcinp";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ };
+
+ vcc3v3_pi6c_05: regulator-3v3-vcc-pi6c-05 {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&lan_power_en>;
+ regulator-name = "vcc3v3_pi6c_05";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ vcc3v3_sd: regulator-3v3-vcc-sd {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sd_pwren>;
+ regulator-name = "vcc3v3_sd";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc3v3_sys>;
+ };
+
+ vcc3v3_sys: regulator-3v3-vcc-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc3v3_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ 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 = <&vcc12v_dcinp>;
+ };
+
+ vcc5v0_usb30_otg0: regulator-5v0-vcc-usb30-otg0 {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usb_power_en>;
+ regulator-name = "vcc5v0_usb30_otg0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ vin-supply = <&vcc5v0_sys>;
+ };
+};
+
+&combphy0 {
+ status = "okay";
+};
+
+&combphy1 {
+ status = "okay";
+};
+
+&combphy2 {
+ status = "okay";
+};
+
+&cpu0 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&cpu1 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&cpu2 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&cpu3 {
+ cpu-supply = <&vdd_cpu>;
+};
+
+&gpu {
+ mali-supply = <&vdd_gpu>;
+ status = "okay";
+};
+
+&hdmi {
+ avdd-0v9-supply = <&vdda0v9_image>;
+ avdd-1v8-supply = <&vcca1v8_image>;
+ status = "okay";
+};
+
+&hdmi_in {
+ hdmi_in_vp0: endpoint {
+ remote-endpoint = <&vp0_out_hdmi>;
+ };
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
+&hdmi_sound {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ vdd_cpu: regulator@1c {
+ compatible = "tcs,tcs4525";
+ reg = <0x1c>;
+ fcs,suspend-voltage-selector = <1>;
+ regulator-name = "vdd_cpu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1150000>;
+ regulator-ramp-delay = <2300>;
+ vin-supply = <&vcc5v0_sys>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ rk809: pmic@20 {
+ compatible = "rockchip,rk809";
+ reg = <0x20>;
+ #clock-cells = <1>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA3 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pmic_int>;
+ system-power-controller;
+ wakeup-source;
+
+ vcc1-supply = <&vcc3v3_sys>;
+ vcc2-supply = <&vcc3v3_sys>;
+ vcc3-supply = <&vcc3v3_sys>;
+ vcc4-supply = <&vcc3v3_sys>;
+ vcc5-supply = <&vcc3v3_sys>;
+ vcc6-supply = <&vcc3v3_sys>;
+ vcc7-supply = <&vcc3v3_sys>;
+ vcc8-supply = <&vcc3v3_sys>;
+ vcc9-supply = <&vcc3v3_sys>;
+
+ regulators {
+ vdd_logic: DCDC_REG1 {
+ regulator-name = "vdd_logic";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdd_gpu: DCDC_REG2 {
+ regulator-name = "vdd_gpu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_ddr: DCDC_REG3 {
+ regulator-name = "vcc_ddr";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-initial-mode = <0x2>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ };
+ };
+
+ vdd_npu: DCDC_REG4 {
+ regulator-name = "vdd_npu";
+ regulator-initial-mode = <0x2>;
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-ramp-delay = <6001>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_1v8: DCDC_REG5 {
+ regulator-name = "vcc_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda0v9_image: LDO_REG1 {
+ regulator-name = "vdda0v9_image";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda_0v9: LDO_REG2 {
+ regulator-name = "vdda_0v9";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vdda0v9_pmu: LDO_REG3 {
+ regulator-name = "vdda0v9_pmu";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <900000>;
+
+ regulator-state-mem {
+ regulator-on-in-suspend;
+ regulator-suspend-microvolt = <900000>;
+ };
+ };
+
+ vccio_acodec: LDO_REG4 {
+ regulator-name = "vccio_acodec";
+ regulator-always-on;
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vccio_sd: LDO_REG5 {
+ regulator-name = "vccio_sd";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3_pmu: LDO_REG6 {
+ regulator-name = "vcc3v3_pmu";
+ 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>;
+ };
+ };
+
+ vcca_1v8: LDO_REG7 {
+ regulator-name = "vcca_1v8";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcca1v8_pmu: LDO_REG8 {
+ regulator-name = "vcca1v8_pmu";
+ 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>;
+ };
+ };
+
+ vcca1v8_image: LDO_REG9 {
+ regulator-name = "vcca1v8_image";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc_3v3: SWITCH_REG1 {
+ regulator-name = "vcc_3v3";
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+
+ vcc3v3: SWITCH_REG2 {
+ regulator-name = "vcc3v3";
+ regulator-always-on;
+ regulator-boot-on;
+
+ regulator-state-mem {
+ regulator-off-in-suspend;
+ };
+ };
+ };
+ };
+};
+
+&i2c2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c2m1_xfer>;
+ status = "okay";
+};
+
+&i2s0_8ch {
+ status = "okay";
+};
+
+&pcie2x1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_perstn>;
+ reset-gpios = <&gpio2 RK_PD6 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&vcc3v3_pi6c_05>;
+ status = "okay";
+};
+
+&pcie30phy {
+ data-lanes = <1 2>;
+ status = "okay";
+};
+
+&pcie3x1 {
+ num-lanes = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&lan_resetb>;
+ reset-gpios = <&gpio3 RK_PA4 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&vcc3v3_pi6c_05>;
+ status = "okay";
+};
+
+&pcie3x2 {
+ num-lanes = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&lan_reseta>;
+ reset-gpios = <&gpio2 RK_PD0 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&vcc3v3_pi6c_05>;
+ status = "okay";
+};
+
+&pinctrl {
+ keys {
+ factory: factory {
+ rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ leds {
+ green_led: green-led {
+ rockchip,pins = <3 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ red_led: red-led {
+ rockchip,pins = <3 RK_PA7 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ work_led: work-led {
+ rockchip,pins = <3 RK_PB0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ ir {
+ pwm3_ir_m0: pwm3-ir-m0 {
+ rockchip,pins = <0 RK_PC2 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ mmc {
+ sd_pwren: sd-pwren {
+ rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pcie {
+ lan_power_en: lan-power-en {
+ rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ lan_reseta: lan-reseta {
+ rockchip,pins = <2 RK_PD0 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ lan_resetb: lan-resetb {
+ rockchip,pins = <3 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ wifi_perstn: wifi-perstn {
+ rockchip,pins = <2 RK_PD6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ pmic {
+ pmic_int: pmic-int {
+ rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO &pcfg_pull_up>;
+ };
+ };
+
+ usb {
+ usb_power_en: usb-power-en {
+ rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+};
+
+&pmu_io_domains {
+ pmuio1-supply = <&vcc3v3_pmu>;
+ pmuio2-supply = <&vcc3v3_pmu>;
+ vccio1-supply = <&vccio_acodec>;
+ vccio2-supply = <&vcc_1v8>;
+ vccio3-supply = <&vccio_sd>;
+ vccio4-supply = <&vcc_1v8>;
+ vccio5-supply = <&vcc_3v3>;
+ vccio6-supply = <&vcc_1v8>;
+ vccio7-supply = <&vcc_3v3>;
+ status = "okay";
+};
+
+&pwm0 {
+ status = "okay";
+};
+
+&saradc {
+ vref-supply = <&vcca_1v8>;
+ status = "okay";
+};
+
+/* Via Type-C adapter */
+&sata0 {
+ status = "okay";
+};
+
+&sdhci {
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ max-frequency = <200000000>;
+ mmc-hs200-1_8v;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>;
+ vmmc-supply = <&vcc_3v3>;
+ vqmmc-supply = <&vcc_1v8>;
+ status = "okay";
+};
+
+&sdmmc0 {
+ bus-width = <4>;
+ cap-sd-highspeed;
+ cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
+ disable-wp;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdmmc0_bus4 &sdmmc0_clk &sdmmc0_cmd &sdmmc0_det>;
+ sd-uhs-sdr50;
+ vmmc-supply = <&vcc3v3_sd>;
+ vqmmc-supply = <&vccio_sd>;
+ status = "okay";
+};
+
+&tsadc {
+ rockchip,hw-tshut-mode = <1>;
+ rockchip,hw-tshut-polarity = <0>;
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&usb_host0_ehci {
+ status = "okay";
+};
+
+&usb_host0_ohci {
+ status = "okay";
+};
+
+&usb_host1_ehci {
+ status = "okay";
+};
+
+&usb_host1_ohci {
+ status = "okay";
+};
+
+&usb_host1_xhci {
+ status = "okay";
+};
+
+&usb2phy0 {
+ status = "okay";
+};
+
+&usb2phy0_host {
+ phy-supply = <&vcc5v0_usb30_otg0>;
+ status = "okay";
+};
+
+&usb2phy1 {
+ status = "okay";
+};
+
+&usb2phy1_host {
+ phy-supply = <&vcc5v0_usb30_otg0>;
+ status = "okay";
+};
+
+&usb2phy1_otg {
+ phy-supply = <&vcc5v0_usb30_otg0>;
+ status = "okay";
+};
+
+&vop {
+ assigned-clocks = <&cru DCLK_VOP0>, <&cru DCLK_VOP1>;
+ assigned-clock-parents = <&pmucru PLL_HPLL>, <&cru PLL_VPLL>;
+ status = "okay";
+};
+
+&vop_mmu {
+ status = "okay";
+};
+
+&vp0 {
+ vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
+ reg = <ROCKCHIP_VOP2_EP_HDMI0>;
+ remote-endpoint = <&hdmi_in_vp0>;
+ };
+};
--
2.25.1
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K
2025-08-18 10:00 ` [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K Chukun Pan
@ 2025-08-30 21:14 ` Erik Beck
2025-08-30 21:30 ` Andrew Lunn
2025-09-01 7:00 ` Chukun Pan
0 siblings, 2 replies; 24+ messages in thread
From: Erik Beck @ 2025-08-30 21:14 UTC (permalink / raw)
To: Chukun Pan
Cc: Heiko Stuebner, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
linux-arm-kernel, linux-rockchip, linux-kernel, devicetree
On Mon, 18 Aug 2025 18:00:08 +0800
Chukun Pan <amadeus@jmu.edu.cn> wrote:
> The HINLINK H68K is a development board with the
> Rockchip RK3568 SoC. It has the following features:
>
> - 2/4GB LPDDR4
> - 1x HDMI Type A
> - 3.5mm jack with mic
> - 1x PCIE 2.0 WiFi slot
> - 1x USB 3.0, 2x USB 2.0
> - 2x 1GbE RTL8211F Ethernet
> - 2x 2.5GbE RTL8125B Ethernet
> - MicroSD card slot / eMMC 32GB
>
> Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
> ---
> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> .../boot/dts/rockchip/rk3568-hinlink-h68k.dts | 83 +++
> .../boot/dts/rockchip/rk3568-hinlink-opc.dtsi | 666 ++++++++++++++++++
> 3 files changed, 750 insertions(+)
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-hinlink-h68k.dts
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-hinlink-opc.dtsi
>
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile
> b/arch/arm64/boot/dts/rockchip/Makefile index 099520962ffb..09c810cb64a4
> 100644 --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -130,6 +130,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-bpi-r2-pro.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-evb1-v10.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-fastrhino-r66s.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-fastrhino-r68s.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-hinlink-h68k.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-lubancat-2.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-mecsbc.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-nanopi-r5c.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-hinlink-h68k.dts
> b/arch/arm64/boot/dts/rockchip/rk3568-hinlink-h68k.dts new file mode 100644
> index 000000000000..793ee651b868
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3568-hinlink-h68k.dts
> @@ -0,0 +1,83 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include "rk3568-hinlink-opc.dtsi"
> +
> +/ {
> + model = "HINLINK H68K";
> + compatible = "hinlink,h68k", "rockchip,rk3568";
> +
> + aliases {
> + ethernet0 = &gmac0;
> + ethernet1 = &gmac1;
> + };
> +};
> +
> +&gmac0 {
> + assigned-clocks = <&cru SCLK_GMAC0_RX_TX>, <&cru SCLK_GMAC0>;
> + assigned-clock-parents = <&cru SCLK_GMAC0_RGMII_SPEED>;
> + assigned-clock-rates = <0>, <125000000>;
> + clock_in_out = "output";
> + phy-handle = <&rgmii_phy0>;
> + phy-mode = "rgmii-id";
Please change phy-mode here to "rgmii". This change will yield an ethernet
speed throughput change of a factor of 100+.
> + phy-supply = <&vcc3v3_sys>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&gmac0_miim
> + &gmac0_tx_bus2
> + &gmac0_rx_bus2
> + &gmac0_rgmii_clk
> + &gmac0_rgmii_bus
> + &gmac0_rstn>;
> + status = "okay";
> +};
> +
> +&gmac1 {
> + assigned-clocks = <&cru SCLK_GMAC1_RX_TX>, <&cru SCLK_GMAC1>;
> + assigned-clock-parents = <&cru SCLK_GMAC1_RGMII_SPEED>;
> + assigned-clock-rates = <0>, <125000000>;
> + clock_in_out = "output";
> + phy-handle = <&rgmii_phy1>;
> + phy-mode = "rgmii-id";
Same as above: Please change phy-mode here to "rgmii". This change will yield
an ethernet speed throughput change of a factor of 100+.
> + phy-supply = <&vcc3v3_sys>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&gmac1m1_miim
> + &gmac1m1_tx_bus2
> + &gmac1m1_rx_bus2
> + &gmac1m1_rgmii_clk
> + &gmac1m1_rgmii_bus
> + &gmac1_rstn>;
> + status = "okay";
> +};
> +
> +&mdio0 {
> + rgmii_phy0: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0x1>;
> + reset-assert-us = <20000>;
> + reset-deassert-us = <100000>;
> + reset-gpios = <&gpio2 RK_PD3 GPIO_ACTIVE_LOW>;
> + };
> +};
> +
> +&mdio1 {
> + rgmii_phy1: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0x1>;
> + reset-assert-us = <20000>;
> + reset-deassert-us = <100000>;
> + reset-gpios = <&gpio1 RK_PB0 GPIO_ACTIVE_LOW>;
> + };
> +};
> +
> +&pinctrl {
> + gmac {
> + gmac0_rstn: gmac0-rstn {
> + rockchip,pins = <2 RK_PD3 RK_FUNC_GPIO
> &pcfg_pull_none>;
> + };
> +
> + gmac1_rstn: gmac1-rstn {
> + rockchip,pins = <1 RK_PB0 RK_FUNC_GPIO
> &pcfg_pull_none>;
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/rockchip/rk3568-hinlink-opc.dtsi
> b/arch/arm64/boot/dts/rockchip/rk3568-hinlink-opc.dtsi new file mode 100644
> index 000000000000..14f3839ca091
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3568-hinlink-opc.dtsi
> @@ -0,0 +1,666 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +#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 <dt-bindings/soc/rockchip,vop2.h>
> +#include "rk3568.dtsi"
> +
> +/ {
> + aliases {
> + mmc0 = &sdhci;
> + mmc1 = &sdmmc0;
> + };
> +
> + chosen {
> + stdout-path = "serial2:1500000n8";
> + };
> +
> + hdmi-con {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <&hdmi_out_con>;
> + };
> + };
> + };
> +
> + ir-receiver {
> + compatible = "gpio-ir-receiver";
> + gpios = <&gpio0 RK_PC2 GPIO_ACTIVE_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwm3_ir_m0>;
> + };
> +
> + keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&factory>;
> +
> + button-factory {
> + label = "factory";
> + linux,code = <KEY_RESTART>;
> + gpios = <&gpio0 RK_PA0 GPIO_ACTIVE_LOW>;
> + debounce-interval = <50>;
> + };
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&green_led>, <&red_led>, <&work_led>;
> +
> + led-0 {
> + color = <LED_COLOR_ID_BLUE>;
> + function = LED_FUNCTION_WAN;
> + gpios = <&gpio3 RK_PA5 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "netdev";
> + };
> +
> + led-1 {
> + color = <LED_COLOR_ID_AMBER>;
> + function = LED_FUNCTION_DISK;
> + gpios = <&gpio3 RK_PA7 GPIO_ACTIVE_HIGH>;
> + };
> +
> + led-2 {
> + color = <LED_COLOR_ID_GREEN>;
> + function = LED_FUNCTION_STATUS;
> + gpios = <&gpio3 RK_PB0 GPIO_ACTIVE_HIGH>;
> + linux,default-trigger = "default-on";
> + };
> + };
> +
> + vcc0v9_2g5: regulator-0v9-vcc-2g5 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc0v9_2g5";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <900000>;
> + vin-supply = <&vcc5v0_sys>;
> + };
> +
> + vcc12v_dcinp: regulator-12v-vcc-dcinp {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc12v_dcinp";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <12000000>;
> + regulator-max-microvolt = <12000000>;
> + };
> +
> + vcc3v3_pi6c_05: regulator-3v3-vcc-pi6c-05 {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&lan_power_en>;
> + regulator-name = "vcc3v3_pi6c_05";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vcc5v0_sys>;
> + };
> +
> + vcc3v3_sd: regulator-3v3-vcc-sd {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio0 RK_PA6 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sd_pwren>;
> + regulator-name = "vcc3v3_sd";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vcc3v3_sys>;
> + };
> +
> + vcc3v3_sys: regulator-3v3-vcc-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + vin-supply = <&vcc5v0_sys>;
> + };
> +
> + 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 = <&vcc12v_dcinp>;
> + };
> +
> + vcc5v0_usb30_otg0: regulator-5v0-vcc-usb30-otg0 {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio0 RK_PA5 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&usb_power_en>;
> + regulator-name = "vcc5v0_usb30_otg0";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + vin-supply = <&vcc5v0_sys>;
> + };
> +};
> +
> +&combphy0 {
> + status = "okay";
> +};
> +
> +&combphy1 {
> + status = "okay";
> +};
> +
> +&combphy2 {
> + status = "okay";
> +};
> +
> +&cpu0 {
> + cpu-supply = <&vdd_cpu>;
> +};
> +
> +&cpu1 {
> + cpu-supply = <&vdd_cpu>;
> +};
> +
> +&cpu2 {
> + cpu-supply = <&vdd_cpu>;
> +};
> +
> +&cpu3 {
> + cpu-supply = <&vdd_cpu>;
> +};
> +
> +&gpu {
> + mali-supply = <&vdd_gpu>;
> + status = "okay";
> +};
> +
> +&hdmi {
> + avdd-0v9-supply = <&vdda0v9_image>;
> + avdd-1v8-supply = <&vcca1v8_image>;
> + status = "okay";
> +};
> +
> +&hdmi_in {
> + hdmi_in_vp0: endpoint {
> + remote-endpoint = <&vp0_out_hdmi>;
> + };
> +};
> +
> +&hdmi_out {
> + hdmi_out_con: endpoint {
> + remote-endpoint = <&hdmi_con_in>;
> + };
> +};
> +
> +&hdmi_sound {
> + status = "okay";
> +};
> +
> +&i2c0 {
> + status = "okay";
> +
> + vdd_cpu: regulator@1c {
> + compatible = "tcs,tcs4525";
> + reg = <0x1c>;
> + fcs,suspend-voltage-selector = <1>;
> + regulator-name = "vdd_cpu";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <800000>;
> + regulator-max-microvolt = <1150000>;
> + regulator-ramp-delay = <2300>;
> + vin-supply = <&vcc5v0_sys>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + rk809: pmic@20 {
> + compatible = "rockchip,rk809";
> + reg = <0x20>;
> + #clock-cells = <1>;
> + interrupt-parent = <&gpio0>;
> + interrupts = <RK_PA3 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pmic_int>;
> + system-power-controller;
> + wakeup-source;
> +
> + vcc1-supply = <&vcc3v3_sys>;
> + vcc2-supply = <&vcc3v3_sys>;
> + vcc3-supply = <&vcc3v3_sys>;
> + vcc4-supply = <&vcc3v3_sys>;
> + vcc5-supply = <&vcc3v3_sys>;
> + vcc6-supply = <&vcc3v3_sys>;
> + vcc7-supply = <&vcc3v3_sys>;
> + vcc8-supply = <&vcc3v3_sys>;
> + vcc9-supply = <&vcc3v3_sys>;
> +
> + regulators {
> + vdd_logic: DCDC_REG1 {
> + regulator-name = "vdd_logic";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-initial-mode = <0x2>;
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-ramp-delay = <6001>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vdd_gpu: DCDC_REG2 {
> + regulator-name = "vdd_gpu";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-initial-mode = <0x2>;
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-ramp-delay = <6001>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_ddr: DCDC_REG3 {
> + regulator-name = "vcc_ddr";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-initial-mode = <0x2>;
> +
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + };
> + };
> +
> + vdd_npu: DCDC_REG4 {
> + regulator-name = "vdd_npu";
> + regulator-initial-mode = <0x2>;
> + regulator-min-microvolt = <500000>;
> + regulator-max-microvolt = <1350000>;
> + regulator-ramp-delay = <6001>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_1v8: DCDC_REG5 {
> + regulator-name = "vcc_1v8";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vdda0v9_image: LDO_REG1 {
> + regulator-name = "vdda0v9_image";
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <900000>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vdda_0v9: LDO_REG2 {
> + regulator-name = "vdda_0v9";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <900000>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vdda0v9_pmu: LDO_REG3 {
> + regulator-name = "vdda0v9_pmu";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <900000>;
> + regulator-max-microvolt = <900000>;
> +
> + regulator-state-mem {
> + regulator-on-in-suspend;
> + regulator-suspend-microvolt =
> <900000>;
> + };
> + };
> +
> + vccio_acodec: LDO_REG4 {
> + regulator-name = "vccio_acodec";
> + regulator-always-on;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vccio_sd: LDO_REG5 {
> + regulator-name = "vccio_sd";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc3v3_pmu: LDO_REG6 {
> + regulator-name = "vcc3v3_pmu";
> + 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>;
> + };
> + };
> +
> + vcca_1v8: LDO_REG7 {
> + regulator-name = "vcca_1v8";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcca1v8_pmu: LDO_REG8 {
> + regulator-name = "vcca1v8_pmu";
> + 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>;
> + };
> + };
> +
> + vcca1v8_image: LDO_REG9 {
> + regulator-name = "vcca1v8_image";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc_3v3: SWITCH_REG1 {
> + regulator-name = "vcc_3v3";
> + regulator-always-on;
> + regulator-boot-on;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> +
> + vcc3v3: SWITCH_REG2 {
> + regulator-name = "vcc3v3";
> + regulator-always-on;
> + regulator-boot-on;
> +
> + regulator-state-mem {
> + regulator-off-in-suspend;
> + };
> + };
> + };
> + };
> +};
> +
> +&i2c2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c2m1_xfer>;
> + status = "okay";
> +};
> +
> +&i2s0_8ch {
> + status = "okay";
> +};
> +
> +&pcie2x1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&wifi_perstn>;
> + reset-gpios = <&gpio2 RK_PD6 GPIO_ACTIVE_HIGH>;
> + vpcie3v3-supply = <&vcc3v3_pi6c_05>;
> + status = "okay";
> +};
> +
> +&pcie30phy {
> + data-lanes = <1 2>;
> + status = "okay";
> +};
> +
> +&pcie3x1 {
> + num-lanes = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&lan_resetb>;
> + reset-gpios = <&gpio3 RK_PA4 GPIO_ACTIVE_HIGH>;
> + vpcie3v3-supply = <&vcc3v3_pi6c_05>;
> + status = "okay";
> +};
> +
> +&pcie3x2 {
> + num-lanes = <1>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&lan_reseta>;
> + reset-gpios = <&gpio2 RK_PD0 GPIO_ACTIVE_HIGH>;
> + vpcie3v3-supply = <&vcc3v3_pi6c_05>;
> + status = "okay";
> +};
> +
> +&pinctrl {
> + keys {
> + factory: factory {
> + rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO
> &pcfg_pull_up>;
> + };
> + };
> +
> + leds {
> + green_led: green-led {
> + rockchip,pins = <3 RK_PA5 RK_FUNC_GPIO
> &pcfg_pull_none>;
> + };
> +
> + red_led: red-led {
> + rockchip,pins = <3 RK_PA7 RK_FUNC_GPIO
> &pcfg_pull_none>;
> + };
> +
> + work_led: work-led {
> + rockchip,pins = <3 RK_PB0 RK_FUNC_GPIO
> &pcfg_pull_none>;
> + };
> + };
> +
> + ir {
> + pwm3_ir_m0: pwm3-ir-m0 {
> + rockchip,pins = <0 RK_PC2 RK_FUNC_GPIO
> &pcfg_pull_none>;
> + };
> + };
> +
> + mmc {
> + sd_pwren: sd-pwren {
> + rockchip,pins = <0 RK_PA6 RK_FUNC_GPIO
> &pcfg_pull_none>;
> + };
> + };
> +
> + pcie {
> + lan_power_en: lan-power-en {
> + rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO
> &pcfg_pull_none>;
> + };
> +
> + lan_reseta: lan-reseta {
> + rockchip,pins = <2 RK_PD0 RK_FUNC_GPIO
> &pcfg_pull_none>;
> + };
> +
> + lan_resetb: lan-resetb {
> + rockchip,pins = <3 RK_PA4 RK_FUNC_GPIO
> &pcfg_pull_none>;
> + };
> +
> + wifi_perstn: wifi-perstn {
> + rockchip,pins = <2 RK_PD6 RK_FUNC_GPIO
> &pcfg_pull_none>;
> + };
> + };
> +
> + pmic {
> + pmic_int: pmic-int {
> + rockchip,pins = <0 RK_PA3 RK_FUNC_GPIO
> &pcfg_pull_up>;
> + };
> + };
> +
> + usb {
> + usb_power_en: usb-power-en {
> + rockchip,pins = <0 RK_PA5 RK_FUNC_GPIO
> &pcfg_pull_none>;
> + };
> + };
> +};
> +
> +&pmu_io_domains {
> + pmuio1-supply = <&vcc3v3_pmu>;
> + pmuio2-supply = <&vcc3v3_pmu>;
> + vccio1-supply = <&vccio_acodec>;
> + vccio2-supply = <&vcc_1v8>;
> + vccio3-supply = <&vccio_sd>;
> + vccio4-supply = <&vcc_1v8>;
> + vccio5-supply = <&vcc_3v3>;
> + vccio6-supply = <&vcc_1v8>;
> + vccio7-supply = <&vcc_3v3>;
> + status = "okay";
> +};
> +
> +&pwm0 {
> + status = "okay";
> +};
> +
> +&saradc {
> + vref-supply = <&vcca_1v8>;
> + status = "okay";
> +};
> +
> +/* Via Type-C adapter */
> +&sata0 {
> + status = "okay";
> +};
> +
> +&sdhci {
> + bus-width = <8>;
> + cap-mmc-highspeed;
> + max-frequency = <200000000>;
> + mmc-hs200-1_8v;
> + non-removable;
> + pinctrl-names = "default";
> + pinctrl-0 = <&emmc_bus8 &emmc_clk &emmc_cmd &emmc_datastrobe>;
> + vmmc-supply = <&vcc_3v3>;
> + vqmmc-supply = <&vcc_1v8>;
> + status = "okay";
> +};
> +
> +&sdmmc0 {
> + bus-width = <4>;
> + cap-sd-highspeed;
> + cd-gpios = <&gpio0 RK_PA4 GPIO_ACTIVE_LOW>;
> + disable-wp;
> + pinctrl-names = "default";
> + pinctrl-0 = <&sdmmc0_bus4 &sdmmc0_clk &sdmmc0_cmd &sdmmc0_det>;
> + sd-uhs-sdr50;
> + vmmc-supply = <&vcc3v3_sd>;
> + vqmmc-supply = <&vccio_sd>;
> + status = "okay";
> +};
> +
> +&tsadc {
> + rockchip,hw-tshut-mode = <1>;
> + rockchip,hw-tshut-polarity = <0>;
> + status = "okay";
> +};
> +
> +&uart2 {
> + status = "okay";
> +};
> +
> +&usb_host0_ehci {
> + status = "okay";
> +};
> +
> +&usb_host0_ohci {
> + status = "okay";
> +};
> +
> +&usb_host1_ehci {
> + status = "okay";
> +};
> +
> +&usb_host1_ohci {
> + status = "okay";
> +};
> +
> +&usb_host1_xhci {
> + status = "okay";
> +};
> +
> +&usb2phy0 {
> + status = "okay";
> +};
> +
> +&usb2phy0_host {
> + phy-supply = <&vcc5v0_usb30_otg0>;
> + status = "okay";
> +};
> +
> +&usb2phy1 {
> + status = "okay";
> +};
> +
> +&usb2phy1_host {
> + phy-supply = <&vcc5v0_usb30_otg0>;
> + status = "okay";
> +};
> +
> +&usb2phy1_otg {
> + phy-supply = <&vcc5v0_usb30_otg0>;
> + status = "okay";
> +};
> +
> +&vop {
> + assigned-clocks = <&cru DCLK_VOP0>, <&cru DCLK_VOP1>;
> + assigned-clock-parents = <&pmucru PLL_HPLL>, <&cru PLL_VPLL>;
> + status = "okay";
> +};
> +
> +&vop_mmu {
> + status = "okay";
> +};
> +
> +&vp0 {
> + vp0_out_hdmi: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
> + reg = <ROCKCHIP_VOP2_EP_HDMI0>;
> + remote-endpoint = <&hdmi_in_vp0>;
> + };
> +};
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K
2025-08-30 21:14 ` Erik Beck
@ 2025-08-30 21:30 ` Andrew Lunn
2025-08-30 22:21 ` Erik Beck
2025-09-01 7:00 ` Chukun Pan
1 sibling, 1 reply; 24+ messages in thread
From: Andrew Lunn @ 2025-08-30 21:30 UTC (permalink / raw)
To: Erik Beck
Cc: Chukun Pan, Heiko Stuebner, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, linux-arm-kernel, linux-rockchip,
linux-kernel, devicetree
> > +&gmac0 {
> > + assigned-clocks = <&cru SCLK_GMAC0_RX_TX>, <&cru SCLK_GMAC0>;
> > + assigned-clock-parents = <&cru SCLK_GMAC0_RGMII_SPEED>;
> > + assigned-clock-rates = <0>, <125000000>;
> > + clock_in_out = "output";
> > + phy-handle = <&rgmii_phy0>;
> > + phy-mode = "rgmii-id";
>
> Please change phy-mode here to "rgmii". This change will yield an ethernet
> speed throughput change of a factor of 100+.
Rockchip by default do bad things with RGMII delays.
tx_delay:
description: Delay value for TXD timing.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x7F
default: 0x30
rx_delay:
description: Delay value for RXD timing.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 0x7F
default: 0x10
Try setting both of these to 0. And then use 'rgmii-id'.
Andrew
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K
2025-08-30 21:30 ` Andrew Lunn
@ 2025-08-30 22:21 ` Erik Beck
2025-08-31 14:48 ` Erik Beck
0 siblings, 1 reply; 24+ messages in thread
From: Erik Beck @ 2025-08-30 22:21 UTC (permalink / raw)
To: Andrew Lunn
Cc: Chukun Pan, Heiko Stuebner, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, linux-arm-kernel, linux-rockchip,
linux-kernel, devicetree
> On Aug 30, 2025, at 17:38, Andrew Lunn <andrew@lunn.ch> wrote:
>
>
>>
>>> +&gmac0 {
>>> + assigned-clocks = <&cru SCLK_GMAC0_RX_TX>, <&cru SCLK_GMAC0>;
>>> + assigned-clock-parents = <&cru SCLK_GMAC0_RGMII_SPEED>;
>>> + assigned-clock-rates = <0>, <125000000>;
>>> + clock_in_out = "output";
>>> + phy-handle = <&rgmii_phy0>;
>>> + phy-mode = "rgmii-id";
>>
>> Please change phy-mode here to "rgmii". This change will yield an ethernet
>> speed throughput change of a factor of 100+.
>
> Rockchip by default do bad things with RGMII delays.
>
> tx_delay:
> description: Delay value for TXD timing.
> $ref: /schemas/types.yaml#/definitions/uint32
> minimum: 0
> maximum: 0x7F
> default: 0x30
>
> rx_delay:
> description: Delay value for RXD timing.
> $ref: /schemas/types.yaml#/definitions/uint32
> minimum: 0
> maximum: 0x7F
> default: 0x10
>
> Try setting both of these to 0. And then use 'rgmii-id'.
>
> Andrew
Thank you!
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K
2025-08-30 22:21 ` Erik Beck
@ 2025-08-31 14:48 ` Erik Beck
2025-08-31 15:53 ` Andrew Lunn
0 siblings, 1 reply; 24+ messages in thread
From: Erik Beck @ 2025-08-31 14:48 UTC (permalink / raw)
To: Andrew Lunn
Cc: Chukun Pan, Heiko Stuebner, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, linux-arm-kernel, linux-rockchip,
linux-kernel, devicetree
On Sat, 30 Aug 2025 18:21:18 -0400
Erik Beck <xunil@tahomasoft.com> wrote:
> > On Aug 30, 2025, at 17:38, Andrew Lunn <andrew@lunn.ch> wrote:
> >
> >
> >>
> >>> +&gmac0 {
> >>> + assigned-clocks = <&cru SCLK_GMAC0_RX_TX>, <&cru SCLK_GMAC0>;
> >>> + assigned-clock-parents = <&cru SCLK_GMAC0_RGMII_SPEED>;
> >>> + assigned-clock-rates = <0>, <125000000>;
> >>> + clock_in_out = "output";
> >>> + phy-handle = <&rgmii_phy0>;
> >>> + phy-mode = "rgmii-id";
> >>
> >> Please change phy-mode here to "rgmii". This change will yield an
> >> ethernet speed throughput change of a factor of 100+.
> >
> > Rockchip by default do bad things with RGMII delays.
> >
> > tx_delay:
> > description: Delay value for TXD timing.
> > $ref: /schemas/types.yaml#/definitions/uint32
> > minimum: 0
> > maximum: 0x7F
> > default: 0x30
> >
> > rx_delay:
> > description: Delay value for RXD timing.
> > $ref: /schemas/types.yaml#/definitions/uint32
> > minimum: 0
> > maximum: 0x7F
> > default: 0x10
> >
> > Try setting both of these to 0. And then use 'rgmii-id'.
> >
> > Andrew
Setting both gmac0 and gmac1 to phy-mode=rgmii-id with tx/rx delay set to
<0x0> yields about a 7x improvement from ~6 Mbs (with phy-mode=rgmii-id and
tx/rx delay unset) to about 43 Mbps, which is still well below the ~950 Mbs
with phy-mode=rgmii and tx/rx delay unset.
Regards,
Erik
>
> Thank you!
> >
> > _______________________________________________
> > Linux-rockchip mailing list
> > Linux-rockchip@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K
2025-08-31 14:48 ` Erik Beck
@ 2025-08-31 15:53 ` Andrew Lunn
2025-08-31 16:28 ` Erik Beck
0 siblings, 1 reply; 24+ messages in thread
From: Andrew Lunn @ 2025-08-31 15:53 UTC (permalink / raw)
To: Erik Beck
Cc: Chukun Pan, Heiko Stuebner, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, linux-arm-kernel, linux-rockchip,
linux-kernel, devicetree
> > > Rockchip by default do bad things with RGMII delays.
> > >
> > > tx_delay:
> > > description: Delay value for TXD timing.
> > > $ref: /schemas/types.yaml#/definitions/uint32
> > > minimum: 0
> > > maximum: 0x7F
> > > default: 0x30
> > >
> > > rx_delay:
> > > description: Delay value for RXD timing.
> > > $ref: /schemas/types.yaml#/definitions/uint32
> > > minimum: 0
> > > maximum: 0x7F
> > > default: 0x10
> > >
> > > Try setting both of these to 0. And then use 'rgmii-id'.
> > >
> > > Andrew
> Setting both gmac0 and gmac1 to phy-mode=rgmii-id with tx/rx delay set to
> <0x0> yields about a 7x improvement from ~6 Mbs (with phy-mode=rgmii-id and
> tx/rx delay unset) to about 43 Mbps, which is still well below the ~950 Mbs
> with phy-mode=rgmii and tx/rx delay unset.
You need to split the problem into two. Rx delays and Tx delays. Use
something like iperf in UDP mode, to send a stream of UDP packets, or
receive a stream of UDP packets. TCP is bad for this sort of testing
because Rx and Tx are interconnected due to flow control and
retransmissions.
Try small values of rx_delay to see if you can improve the Rx
performance. Try small values to tx_delay, to see if you can improve
the Tx performance.
One problem we have with rx_delay and tx_delay is that they are
magic. We have no idea what they mean. The RGMII standard says there
should be a 2ns delay between data and clock. A poorly designed board
could mean the MAC/PHY pair needs to insert say 1.8ns or 2.2ns, not
2ns as defined by the RGMiI standard. Rockchip also seem to encourage
using rx_delay and tx_delay, so i would not be surprised to find
Rockchip boards are often poorly designed and don't follow the RGMII
standard.
rx_delay/tx_delay can probably insert 0.2ns of delay, but it probably
cannot insert -0.2ns of delay. So it could be, you cannot improve
it. If that is the case, we need to consider another solution.
Andrew
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K
2025-08-31 15:53 ` Andrew Lunn
@ 2025-08-31 16:28 ` Erik Beck
2025-09-01 0:47 ` Andrew Lunn
0 siblings, 1 reply; 24+ messages in thread
From: Erik Beck @ 2025-08-31 16:28 UTC (permalink / raw)
To: Andrew Lunn
Cc: Chukun Pan, Heiko Stuebner, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, linux-arm-kernel, linux-rockchip,
linux-kernel, devicetree
On Sun, 31 Aug 2025 17:53:19 +0200
Andrew Lunn <andrew@lunn.ch> wrote:
> > > > Rockchip by default do bad things with RGMII delays.
> > > >
> > > > tx_delay:
> > > > description: Delay value for TXD timing.
> > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > minimum: 0
> > > > maximum: 0x7F
> > > > default: 0x30
> > > >
> > > > rx_delay:
> > > > description: Delay value for RXD timing.
> > > > $ref: /schemas/types.yaml#/definitions/uint32
> > > > minimum: 0
> > > > maximum: 0x7F
> > > > default: 0x10
> > > >
> > > > Try setting both of these to 0. And then use 'rgmii-id'.
> > > >
> > > > Andrew
> > Setting both gmac0 and gmac1 to phy-mode=rgmii-id with tx/rx delay set to
> > <0x0> yields about a 7x improvement from ~6 Mbs (with phy-mode=rgmii-id
> > and tx/rx delay unset) to about 43 Mbps, which is still well below the
> > ~950 Mbs with phy-mode=rgmii and tx/rx delay unset.
>
> You need to split the problem into two. Rx delays and Tx delays. Use
> something like iperf in UDP mode, to send a stream of UDP packets, or
> receive a stream of UDP packets. TCP is bad for this sort of testing
> because Rx and Tx are interconnected due to flow control and
> retransmissions.
>
> Try small values of rx_delay to see if you can improve the Rx
> performance. Try small values to tx_delay, to see if you can improve
> the Tx performance.
>
OK, thanks.
Just so I am clear, the units are tenths of nanoseconds? So <0x02> is .2
nanoseconds?
> One problem we have with rx_delay and tx_delay is that they are
> magic. We have no idea what they mean. The RGMII standard says there
> should be a 2ns delay between data and clock. A poorly designed board
> could mean the MAC/PHY pair needs to insert say 1.8ns or 2.2ns, not
> 2ns as defined by the RGMiI standard. Rockchip also seem to encourage
> using rx_delay and tx_delay, so i would not be surprised to find
> Rockchip boards are often poorly designed and don't follow the RGMII
> standard.
>
> rx_delay/tx_delay can probably insert 0.2ns of delay, but it probably
> cannot insert -0.2ns of delay. So it could be, you cannot improve
> it. If that is the case, we need to consider another solution.
>
> Andrew
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K
2025-08-31 16:28 ` Erik Beck
@ 2025-09-01 0:47 ` Andrew Lunn
0 siblings, 0 replies; 24+ messages in thread
From: Andrew Lunn @ 2025-09-01 0:47 UTC (permalink / raw)
To: Erik Beck
Cc: Chukun Pan, Heiko Stuebner, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, linux-arm-kernel, linux-rockchip,
linux-kernel, devicetree
> Just so I am clear, the units are tenths of nanoseconds? So <0x02> is .2
> nanoseconds?
Quoting myself:
> > One problem we have with rx_delay and tx_delay is that they are
> > magic. we have no idea what they mean.
I very much doubt 0x02 is 0.2 nano seconds. If you have an
oscilloscope which can handle the signals, you could measure it and
see how the delay changes with different values. But developers have
done that in the past, with mixed results.
Andrew
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K
2025-08-30 21:14 ` Erik Beck
2025-08-30 21:30 ` Andrew Lunn
@ 2025-09-01 7:00 ` Chukun Pan
2025-09-01 10:24 ` Erik Beck
1 sibling, 1 reply; 24+ messages in thread
From: Chukun Pan @ 2025-09-01 7:00 UTC (permalink / raw)
To: xunil
Cc: amadeus, conor+dt, devicetree, heiko, krzk+dt, linux-arm-kernel,
linux-kernel, linux-rockchip
Hi,
> Please change phy-mode here to "rgmii". This change will yield an
> ethernet speed throughput change of a factor of 100+.
> Same as above: Please change phy-mode here to "rgmii". This change
> will yield an ethernet speed throughput change of a factor of 100+.
This doesn't make sense. When I first submitted it to coolsnowwolf/lede
in 2022, I used "rgmii-id" as the phy-mode, and it worked:
https://github.com/coolsnowwolf/lede/blob/master/target/linux/rockchip/files/arch/arm64/boot/dts/rockchip/rk3568-opc-h68k.dts#L24
Are you experiencing issues with both eth0 and eth1 or just one of them?
Are you using the generic-rk3568 target for U-Boot?
I can't reproduce your problem in my test.
eth0/gmac1 (as lan):
root@OpenWrt:~# iperf3 -c 192.168.1.100
Connecting to host 192.168.1.100, port 5201
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 29 sender
[ 5] 0.00-10.04 sec 1.10 GBytes 936 Mbits/sec receiver
root@OpenWrt:~# iperf3 -c 192.168.1.100 -R
Connecting to host 192.168.1.100, port 5201
Reverse mode, remote host 192.168.1.100 is sending
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.04 sec 1.10 GBytes 939 Mbits/sec 1 sender
[ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec receiver
eth1/gmac0 (as wan):
root@OpenWrt:~# iperf3 -c 192.168.0.2 -P 4
Connecting to host 192.168.0.2, port 5201
[ ID] Interval Transfer Bitrate Retr
[SUM] 0.00-10.00 sec 1.10 GBytes 945 Mbits/sec 1191 sender
[SUM] 0.00-10.05 sec 1.09 GBytes 935 Mbits/sec receiver
root@OpenWrt:~# iperf3 -c 192.168.0.2 -R
Connecting to host 192.168.0.2, port 5201
Reverse mode, remote host 192.168.0.2 is sending
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.06 sec 1.10 GBytes 939 Mbits/sec 6 sender
[ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec receiver
--
2.25.1
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K
2025-09-01 7:00 ` Chukun Pan
@ 2025-09-01 10:24 ` Erik Beck
2025-09-01 14:06 ` Erik Beck
2025-09-01 16:25 ` Erik Beck
0 siblings, 2 replies; 24+ messages in thread
From: Erik Beck @ 2025-09-01 10:24 UTC (permalink / raw)
To: Chukun Pan
Cc: conor+dt, devicetree, heiko, krzk+dt, linux-arm-kernel,
linux-kernel, linux-rockchip, Andrew Lunn
On Mon, 1 Sep 2025 15:00:08 +0800
Chukun Pan <amadeus@jmu.edu.cn> wrote:
> Hi,
>
> > Please change phy-mode here to "rgmii". This change will yield an
> > ethernet speed throughput change of a factor of 100+.
>
> > Same as above: Please change phy-mode here to "rgmii". This change
> > will yield an ethernet speed throughput change of a factor of 100+.
>
> This doesn't make sense. When I first submitted it to coolsnowwolf/lede
> in 2022, I used "rgmii-id" as the phy-mode, and it worked:
> https://github.com/coolsnowwolf/lede/blob/master/target/linux/rockchip/files/arch/arm64/boot/dts/rockchip/rk3568-opc-h68k.dts#L24
>
> Are you experiencing issues with both eth0 and eth1 or just one of them?
> Are you using the generic-rk3568 target for U-Boot?
>
Hi Chukun, thanks for your response.
At Andrew Lunn's suggestion, I'm doing
more granular and rigorous testing, now using iperf3. I'll post more details
of results here after I retest a couple of scenarios.
However, I will report now that so far, I'm getting better (faster) and more
consistent results using iperf3.
~Erik
> I can't reproduce your problem in my test.
>
> eth0/gmac1 (as lan):
> root@OpenWrt:~# iperf3 -c 192.168.1.100
> Connecting to host 192.168.1.100, port 5201
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 29 sender
> [ 5] 0.00-10.04 sec 1.10 GBytes 936 Mbits/sec
> receiver
>
> root@OpenWrt:~# iperf3 -c 192.168.1.100 -R
> Connecting to host 192.168.1.100, port 5201
> Reverse mode, remote host 192.168.1.100 is sending
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-10.04 sec 1.10 GBytes 939 Mbits/sec 1 sender
> [ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec
> receiver
>
> eth1/gmac0 (as wan):
> root@OpenWrt:~# iperf3 -c 192.168.0.2 -P 4
> Connecting to host 192.168.0.2, port 5201
> [ ID] Interval Transfer Bitrate Retr
> [SUM] 0.00-10.00 sec 1.10 GBytes 945 Mbits/sec 1191
> sender [SUM] 0.00-10.05 sec 1.09 GBytes 935 Mbits/sec
> receiver
>
> root@OpenWrt:~# iperf3 -c 192.168.0.2 -R
> Connecting to host 192.168.0.2, port 5201
> Reverse mode, remote host 192.168.0.2 is sending
> [ ID] Interval Transfer Bitrate Retr
> [ 5] 0.00-10.06 sec 1.10 GBytes 939 Mbits/sec 6 sender
> [ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec
> receiver
>
> --
> 2.25.1
>
>
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K
2025-09-01 10:24 ` Erik Beck
@ 2025-09-01 14:06 ` Erik Beck
2025-09-02 7:00 ` Chukun Pan
2025-09-01 16:25 ` Erik Beck
1 sibling, 1 reply; 24+ messages in thread
From: Erik Beck @ 2025-09-01 14:06 UTC (permalink / raw)
To: Chukun Pan
Cc: conor+dt, devicetree, heiko, krzk+dt, linux-arm-kernel,
linux-kernel, linux-rockchip, Andrew Lunn
On Mon, 1 Sep 2025 06:24:37 -0400
Erik Beck <xunil@tahomasoft.com> wrote:
> On Mon, 1 Sep 2025 15:00:08 +0800
> Chukun Pan <amadeus@jmu.edu.cn> wrote:
>
> > Hi,
> >
> > > Please change phy-mode here to "rgmii". This change will yield an
> > > ethernet speed throughput change of a factor of 100+.
> >
> > > Same as above: Please change phy-mode here to "rgmii". This change
> > > will yield an ethernet speed throughput change of a factor of 100+.
> >
> > This doesn't make sense. When I first submitted it to coolsnowwolf/lede
> > in 2022, I used "rgmii-id" as the phy-mode, and it worked:
> > https://github.com/coolsnowwolf/lede/blob/master/target/linux/rockchip/files/arch/arm64/boot/dts/rockchip/rk3568-opc-h68k.dts#L24
> >
> > Are you experiencing issues with both eth0 and eth1 or just one of them?
> > Are you using the generic-rk3568 target for U-Boot?
> >
>
> Hi Chukun, thanks for your response.
>
> At Andrew Lunn's suggestion, I'm doing
> more granular and rigorous testing, now using iperf3. I'll post more details
> of results here after I retest a couple of scenarios.
>
> However, I will report now that so far, I'm getting better (faster) and more
> consistent results using iperf3.
>
> ~Erik
Below are my results.
In summary, the speeds in certain scenarios are closer than in others.
Pooling everything together, at the eyeball level, things look pretty similar
across using RGMII-ID and RGMII (no internal delay). If I were to run these
tests repeatedly, pool the results, and do a statistical comparison (probably
with a Kolmogorov-Smirnov (KS) test or similar), I doubt I could reject the
null hypothesis of no significant difference between the two sample
distributions.
So what I said earlier regarding rgmii vs rgmii-id DOES NOT hold up under
more rigorous and careful testing.
Thanks,
Erik
___________________________
Results with (gmac0 & gmac1) phy-mode = "rgmii-id", tx_rx_delay unspecified
(kernel on boot sets tx_delay = 0x30 and rx_delay = 0x10 itself, both gmacs)
eth0/wan
iperf3 -s -F VidTest-1.4Gb.mp4
{openwrt device is 192.168.2.241}
{desktop on openwrt WAN is 192.168.2.90}
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.2.241, port 44414
[ 5] local 192.168.2.90 port 5201 connected to 192.168.2.241 port 44422
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 112 MBytes 935 Mbits/sec
[ 5] 1.00-2.00 sec 112 MBytes 939 Mbits/sec
[ 5] 2.00-3.00 sec 112 MBytes 940 Mbits/sec
[ 5] 3.00-4.00 sec 112 MBytes 939 Mbits/sec
[ 5] 4.00-5.00 sec 112 MBytes 939 Mbits/sec
[ 5] 5.00-6.00 sec 112 MBytes 939 Mbits/sec
[ 5] 6.00-7.00 sec 112 MBytes 938 Mbits/sec
[ 5] 7.00-8.00 sec 112 MBytes 940 Mbits/sec
[ 5] 8.00-9.00 sec 112 MBytes 938 Mbits/sec
[ 5] 9.00-10.00 sec 112 MBytes 940 Mbits/sec
[ 5] 10.00-10.00 sec 384 KBytes 815 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
Sent 1.09 GByte / 1.09 GByte (100%) of VidTest-1.4Gb.mp4
[ 5] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec receiver
-----------------------------------------------------------
< Reverse >
iperf3 -s
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.2.241, port 45870
[ 5] local 192.168.2.90 port 5201 connected to 192.168.2.241 port 45886
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 114 MBytes 953 Mbits/sec 120 158 KBytes
[ 5] 1.00-2.00 sec 112 MBytes 935 Mbits/sec 143 141 KBytes
[ 5] 2.00-3.00 sec 110 MBytes 923 Mbits/sec 131 195 KBytes
[ 5] 3.00-4.00 sec 112 MBytes 939 Mbits/sec 142 167 KBytes
[ 5] 4.00-5.00 sec 112 MBytes 942 Mbits/sec 136 133 KBytes
[ 5] 5.00-6.00 sec 111 MBytes 929 Mbits/sec 119 175 KBytes
[ 5] 6.00-7.00 sec 111 MBytes 932 Mbits/sec 126 115 KBytes
[ 5] 7.00-8.00 sec 112 MBytes 943 Mbits/sec 150 113 KBytes
[ 5] 8.00-9.00 sec 105 MBytes 884 Mbits/sec 28 110 KBytes
[ 5] 9.00-10.00 sec 112 MBytes 938 Mbits/sec 140 160 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.08 GBytes 932 Mbits/sec 1235 sender
eth1/lan
iperf3 -s -F VidTest-1.4Gb.mp4
-----------------------------------------------------------
{openwrt device is 192.168.1.1}
{Laptop attached to openwrt is 192.168.1.134}
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.1.1, port 53876
[ 5] local 192.168.1.134 port 5201 connected to 192.168.1.1 port 53890
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 31.9 MBytes 267 Mbits/sec
[ 5] 1.00-2.00 sec 32.5 MBytes 273 Mbits/sec
[ 5] 2.00-3.00 sec 33.6 MBytes 282 Mbits/sec
[ 5] 3.00-4.00 sec 29.2 MBytes 245 Mbits/sec
[ 5] 4.00-5.00 sec 33.8 MBytes 283 Mbits/sec
[ 5] 5.00-6.00 sec 32.6 MBytes 274 Mbits/sec
[ 5] 6.00-7.00 sec 34.1 MBytes 286 Mbits/sec
[ 5] 7.00-8.00 sec 35.0 MBytes 294 Mbits/sec
[ 5] 8.00-9.00 sec 33.6 MBytes 282 Mbits/sec
[ 5] 9.00-10.00 sec 32.8 MBytes 275 Mbits/sec
[ 5] 10.00-10.00 sec 128 KBytes 872 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
Sent 329 MByte / 329 MByte (100%) of VidTest-1.4Gb.mp4
[ 5] 0.00-10.00 sec 329 MBytes 276 Mbits/sec receiver
-----------------------------------------------------------
< reverse >
iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[ 5] local 192.168.1.134 port 60508 connected to 192.168.1.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 113 MBytes 948 Mbits/sec 0 393 KBytes
[ 5] 1.00-2.00 sec 111 MBytes 931 Mbits/sec 0 411 KBytes
[ 5] 2.00-3.00 sec 112 MBytes 935 Mbits/sec 0 433 KBytes
[ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec 0 433 KBytes
[ 5] 4.00-5.00 sec 111 MBytes 934 Mbits/sec 0 433 KBytes
[ 5] 5.00-6.00 sec 111 MBytes 932 Mbits/sec 0 433 KBytes
[ 5] 6.00-7.00 sec 111 MBytes 930 Mbits/sec 0 433 KBytes
[ 5] 7.00-8.00 sec 111 MBytes 934 Mbits/sec 0 433 KBytes
[ 5] 8.00-9.00 sec 111 MBytes 932 Mbits/sec 0 433 KBytes
[ 5] 9.00-10.00 sec 113 MBytes 944 Mbits/sec 0 573 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.09 GBytes 936 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.09 GBytes 933 Mbits/sec receiver
Throughput (wan (eth0) -> lan (eth1) -> laptop)
Desktop <------> Laptop via Openwrt
192.168.2.90 192.168.1.134
iperf3 -c 192.168.2.90
Connecting to host 192.168.2.90, port 5201
[ 5] local 192.168.1.134 port 54694 connected to 192.168.2.90 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 106 MBytes 889 Mbits/sec 0 461 KBytes
[ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec 0 461 KBytes
[ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec 0 461 KBytes
[ 5] 3.00-4.00 sec 111 MBytes 934 Mbits/sec 0 461 KBytes
[ 5] 4.00-5.00 sec 111 MBytes 932 Mbits/sec 0 461 KBytes
[ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec 0 461 KBytes
[ 5] 6.00-7.00 sec 111 MBytes 931 Mbits/sec 0 503 KBytes
[ 5] 7.00-8.00 sec 112 MBytes 938 Mbits/sec 0 503 KBytes
[ 5] 8.00-9.00 sec 111 MBytes 931 Mbits/sec 0 503 KBytes
[ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec 0 503 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.08 GBytes 929 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.08 GBytes 927 Mbits/sec receive
< Reverse >
iperf3 -c 192.168.2.90
Connecting to host 192.168.2.90, port 5201
[ 5] local 192.168.1.134 port 54694 connected to 192.168.2.90 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 106 MBytes 889 Mbits/sec 0 461 KBytes
[ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec 0 461 KBytes
[ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec 0 461 KBytes
[ 5] 3.00-4.00 sec 111 MBytes 934 Mbits/sec 0 461 KBytes
[ 5] 4.00-5.00 sec 111 MBytes 932 Mbits/sec 0 461 KBytes
[ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec 0 461 KBytes
[ 5] 6.00-7.00 sec 111 MBytes 931 Mbits/sec 0 503 KBytes
[ 5] 7.00-8.00 sec 112 MBytes 938 Mbits/sec 0 503 KBytes
[ 5] 8.00-9.00 sec 111 MBytes 931 Mbits/sec 0 503 KBytes
[ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec 0 503 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.08 GBytes 929 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.08 GBytes 927 Mbits/sec receive
---------
Results with (gmac0 & gmac1) phy-mode = "rgmii", tx_rx_delay unspecified
(kernel on boot sets tx_delay = 0x30 and rx_delay = 0x10 itself, both gmacs)
eth0/wan
iperf3 -s -F VidTest-1.4Gb.mp4
{openwrt device is 192.168.2.241}
{desktop on openwrt WAN is 192.168.2.90}
iperf3 -s -F VidTest-1.4Gb.mp4
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.2.241, port 35070
[ 5] local 192.168.2.90 port 5201 connected to 192.168.2.241 port 35084
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 112 MBytes 936 Mbits/sec
[ 5] 1.00-2.00 sec 112 MBytes 939 Mbits/sec
[ 5] 2.00-3.00 sec 112 MBytes 938 Mbits/sec
[ 5] 3.00-4.00 sec 112 MBytes 939 Mbits/sec
[ 5] 4.00-5.00 sec 112 MBytes 939 Mbits/sec
[ 5] 5.00-6.00 sec 112 MBytes 940 Mbits/sec
[ 5] 6.00-7.00 sec 112 MBytes 938 Mbits/sec
[ 5] 7.00-8.00 sec 112 MBytes 940 Mbits/sec
[ 5] 8.00-9.00 sec 112 MBytes 939 Mbits/sec
[ 5] 9.00-10.00 sec 112 MBytes 939 Mbits/sec
[ 5] 10.00-10.00 sec 384 KBytes 869 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
Sent 1.09 GByte / 1.09 GByte (100%) of VidTest-1.4Gb.mp4
[ 5] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec receiver
-----------------------------------------------------------
<reverse>
Accepted connection from 192.168.2.241, port 51650
[ 5] local 192.168.2.90 port 5201 connected to 192.168.2.241 port 51660
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 114 MBytes 953 Mbits/sec 168 209 KBytes
[ 5] 1.00-2.00 sec 112 MBytes 938 Mbits/sec 224 148 KBytes
[ 5] 2.00-3.00 sec 112 MBytes 940 Mbits/sec 196 158 KBytes
[ 5] 3.00-4.00 sec 112 MBytes 943 Mbits/sec 196 180 KBytes
[ 5] 4.00-5.00 sec 112 MBytes 937 Mbits/sec 196 187 KBytes
[ 5] 5.00-6.00 sec 112 MBytes 940 Mbits/sec 196 195 KBytes
[ 5] 6.00-7.00 sec 112 MBytes 937 Mbits/sec 196 204 KBytes
[ 5] 7.00-8.00 sec 112 MBytes 940 Mbits/sec 224 136 KBytes
[ 5] 8.00-9.00 sec 112 MBytes 940 Mbits/sec 196 158 KBytes
[ 5] 9.00-10.00 sec 110 MBytes 922 Mbits/sec 196 188 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec 1988 sender
Sent 1.09 GByte / 1.09 GByte (100%) of VidTest-1.4Gb.mp4
-----------------------------------------------------------
eth1/lan
{192.168.1.1 is Openwrt device}
{192.168.1.134 is laptop directly attached to Openwrt}
iperf3 -s -F VidTest-1.4Gb.mp4
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.1.1, port 40866
[ 5] local 192.168.1.134 port 5201 connected to 192.168.1.1 port 40868
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 67.4 MBytes 565 Mbits/sec
[ 5] 1.00-2.00 sec 69.4 MBytes 582 Mbits/sec
[ 5] 2.00-3.00 sec 65.9 MBytes 553 Mbits/sec
[ 5] 3.00-4.00 sec 66.5 MBytes 558 Mbits/sec
[ 5] 4.00-5.00 sec 70.2 MBytes 589 Mbits/sec
[ 5] 5.00-6.00 sec 52.5 MBytes 440 Mbits/sec
[ 5] 6.00-7.00 sec 67.2 MBytes 564 Mbits/sec
[ 5] 7.00-8.00 sec 70.2 MBytes 589 Mbits/sec
[ 5] 8.00-9.00 sec 57.9 MBytes 486 Mbits/sec
[ 5] 9.00-10.00 sec 66.9 MBytes 561 Mbits/sec
[ 5] 10.00-10.00 sec 128 KBytes 909 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
Sent 654 MByte / 654 MByte (100%) of VidTest-1.4Gb.mp4
[ 5] 0.00-10.00 sec 654 MBytes 549 Mbits/sec receiver
< reverse >
iperf3 -c 192.168.1.134 --reverse
Connecting to host 192.168.1.134, port 5201
Reverse mode, remote host 192.168.1.134 is sending
[ 5] local 192.168.1.1 port 58380 connected to 192.168.1.134 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 104 MBytes 870 Mbits/sec
[ 5] 1.00-2.00 sec 98.5 MBytes 826 Mbits/sec
[ 5] 2.00-3.00 sec 89.9 MBytes 754 Mbits/sec
[ 5] 3.00-4.00 sec 87.4 MBytes 733 Mbits/sec
[ 5] 4.00-5.00 sec 97.0 MBytes 814 Mbits/sec
[ 5] 5.00-6.00 sec 95.5 MBytes 801 Mbits/sec
[ 5] 6.00-7.00 sec 82.1 MBytes 689 Mbits/sec
[ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 654 MBytes 549 Mbits/sec 235 sender
[ 5] 0.00-10.00 sec 654 MBytes 549 Mbits/sec receiver
Throughput (wan (eth0) -> lan (eth1) -> laptop)
Desktop <------> Laptop via Openwrt
192.168.2.90 192.168.1.134
iperf3 -c 192.168.2.90
Connecting to host 192.168.2.90, port 5201
[ 5] local 192.168.1.134 port 44380 connected to 192.168.2.90 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 91.8 MBytes 769 Mbits/sec 15 76.4 KBytes
[ 5] 1.00-2.00 sec 99.5 MBytes 835 Mbits/sec 11 102 KBytes
[ 5] 2.00-3.00 sec 98.8 MBytes 828 Mbits/sec 12 167 KBytes
[ 5] 3.00-4.00 sec 95.4 MBytes 800 Mbits/sec 17 126 KBytes
[ 5] 4.00-5.00 sec 106 MBytes 890 Mbits/sec 9 117 KBytes
[ 5] 5.00-6.00 sec 96.5 MBytes 810 Mbits/sec 15 123 KBytes
[ 5] 6.00-7.00 sec 99.6 MBytes 835 Mbits/sec 13 144 KBytes
[ 5] 7.00-8.00 sec 100 MBytes 842 Mbits/sec 15 58.0 KBytes
[ 5] 8.00-9.00 sec 96.1 MBytes 806 Mbits/sec 15 115 KBytes
[ 5] 9.00-10.00 sec 95.4 MBytes 800 Mbits/sec 14 126 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 980 MBytes 822 Mbits/sec 136 sender
[ 5] 0.00-10.00 sec 979 MBytes 821 Mbits/sec receiver
< reverse >
perf3 -c 192.168.2.90 --reverse
Connecting to host 192.168.2.90, port 5201
Reverse mode, remote host 192.168.2.90 is sending
[ 5] local 192.168.1.134 port 51148 connected to 192.168.2.90 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 40.6 MBytes 340 Mbits/sec
[ 5] 1.00-2.00 sec 54.9 MBytes 460 Mbits/sec
[ 5] 2.00-3.00 sec 49.6 MBytes 416 Mbits/sec
[ 5] 3.00-4.00 sec 47.4 MBytes 397 Mbits/sec
[ 5] 4.00-5.00 sec 45.9 MBytes 385 Mbits/sec
[ 5] 5.00-6.00 sec 52.8 MBytes 443 Mbits/sec
[ 5] 6.00-7.00 sec 45.1 MBytes 379 Mbits/sec
[ 5] 7.00-8.00 sec 46.1 MBytes 387 Mbits/sec
[ 5] 8.00-9.00 sec 42.8 MBytes 359 Mbits/sec
[ 5] 9.00-10.00 sec 40.6 MBytes 341 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 467 MBytes 392 Mbits/sec 403 sender
[ 5] 0.00-10.00 sec 466 MBytes 391 Mbits/sec receiver
____________________________________
>
> > I can't reproduce your problem in my test.
> >
> > eth0/gmac1 (as lan):
> > root@OpenWrt:~# iperf3 -c 192.168.1.100
> > Connecting to host 192.168.1.100, port 5201
> > [ ID] Interval Transfer Bitrate Retr
> > [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 29
> > sender [ 5] 0.00-10.04 sec 1.10 GBytes 936 Mbits/sec
> > receiver
> >
> > root@OpenWrt:~# iperf3 -c 192.168.1.100 -R
> > Connecting to host 192.168.1.100, port 5201
> > Reverse mode, remote host 192.168.1.100 is sending
> > [ ID] Interval Transfer Bitrate Retr
> > [ 5] 0.00-10.04 sec 1.10 GBytes 939 Mbits/sec 1
> > sender [ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec
> > receiver
> >
> > eth1/gmac0 (as wan):
> > root@OpenWrt:~# iperf3 -c 192.168.0.2 -P 4
> > Connecting to host 192.168.0.2, port 5201
> > [ ID] Interval Transfer Bitrate Retr
> > [SUM] 0.00-10.00 sec 1.10 GBytes 945 Mbits/sec 1191
> > sender [SUM] 0.00-10.05 sec 1.09 GBytes 935 Mbits/sec
> > receiver
> >
> > root@OpenWrt:~# iperf3 -c 192.168.0.2 -R
> > Connecting to host 192.168.0.2, port 5201
> > Reverse mode, remote host 192.168.0.2 is sending
> > [ ID] Interval Transfer Bitrate Retr
> > [ 5] 0.00-10.06 sec 1.10 GBytes 939 Mbits/sec 6
> > sender [ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec
> > receiver
> >
> > --
> > 2.25.1
> >
> >
> >
> > _______________________________________________
> > Linux-rockchip mailing list
> > Linux-rockchip@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K
2025-09-01 14:06 ` Erik Beck
@ 2025-09-02 7:00 ` Chukun Pan
2025-09-02 12:10 ` Erik Beck
0 siblings, 1 reply; 24+ messages in thread
From: Chukun Pan @ 2025-09-02 7:00 UTC (permalink / raw)
To: xunil
Cc: amadeus, andrew, conor+dt, devicetree, heiko, krzk+dt,
linux-arm-kernel, linux-kernel, linux-rockchip
Hi,
> So what I said earlier regarding rgmii vs rgmii-id DOES NOT hold up
> under more rigorous and careful testing.
So the following question does not exist?
>> Changing this makes a huge difference in the ethernet throughput speed. With
>> rgmii-id mode specified, throughput is about 6.5 Mbs. Changing this to rgmii
>> mode increases throughput to about 960 Mbs.
If the iperf3 test does not reach Gigabit, you can run it in
multiple threads. e.g. `iperf3 -c xxx -P 4`
--
2.25.1
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K
2025-09-02 7:00 ` Chukun Pan
@ 2025-09-02 12:10 ` Erik Beck
0 siblings, 0 replies; 24+ messages in thread
From: Erik Beck @ 2025-09-02 12:10 UTC (permalink / raw)
To: Chukun Pan
Cc: andrew, conor+dt, devicetree, heiko, krzk+dt, linux-arm-kernel,
linux-kernel, linux-rockchip
On Tue, 2 Sep 2025 15:00:19 +0800
Chukun Pan <amadeus@jmu.edu.cn> wrote:
> Hi,
Greetings!
>
> > So what I said earlier regarding rgmii vs rgmii-id DOES NOT hold up
> > under more rigorous and careful testing.
>
> So the following question does not exist?
Yes, that is correct. My earlier question/comment/concern about a huge speed
difference between rgmii-id mode and rmgmii doesn't seem to exist when more
careful experiments and testing methods are used. I'll elaborate some more
below. And I apologize for any inconvenience.
> >> Changing this makes a huge difference in the ethernet throughput speed.
> >> With rgmii-id mode specified, throughput is about 6.5 Mbs. Changing this
> >> to rgmii mode increases throughput to about 960 Mbs.
>
I'm still a bit surprised that my first test method (web-based, like fast.com
or self-hosted internal download speeds) gave such different results from more
comprehensive and careful testing with iperf3. While certainly web-based
methods can't target a particular interface, nor do they have many other
potential adjustments or refinements (UDP vs TCP, etc), they have been and
continue to be a useful tool for me to get quick information about the status
and health of my network and its devices.
> If the iperf3 test does not reach Gigabit, you can run it in
> multiple threads. e.g. `iperf3 -c xxx -P 4`
Thanks for the tip.
I remain keenly interested in seeing a patch for the Hinlink/LinkStar devices
make it into the mainline kernel. Please let me know how I can help your
(and others) efforts to accomplish that.
Regards,
Erik
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K
2025-09-01 10:24 ` Erik Beck
2025-09-01 14:06 ` Erik Beck
@ 2025-09-01 16:25 ` Erik Beck
1 sibling, 0 replies; 24+ messages in thread
From: Erik Beck @ 2025-09-01 16:25 UTC (permalink / raw)
To: Chukun Pan
Cc: conor+dt, devicetree, heiko, krzk+dt, linux-arm-kernel,
linux-kernel, linux-rockchip, Andrew Lunn
Resending due to mailer error.
>>>> On Mon, 1 Sep 2025 06:24:37 -0400
>>>> Erik Beck <xunil@tahomasoft.com> wrote:
> On Mon, 1 Sep 2025 15:00:08 +0800
> Chukun Pan <amadeus@jmu.edu.cn> wrote:
>
> > Hi,
> >
> > > Please change phy-mode here to "rgmii". This change will yield an
> > > ethernet speed throughput change of a factor of 100+.
> >
> > > Same as above: Please change phy-mode here to "rgmii". This change
> > > will yield an ethernet speed throughput change of a factor of 100+.
> >
> > This doesn't make sense. When I first submitted it to coolsnowwolf/lede
> > in 2022, I used "rgmii-id" as the phy-mode, and it worked:
> > https://github.com/coolsnowwolf/lede/blob/master/target/linux/rockchip/files/arch/arm64/boot/dts/rockchip/rk3568-opc-h68k.dts#L24
> >
> > Are you experiencing issues with both eth0 and eth1 or just one of them?
> > Are you using the generic-rk3568 target for U-Boot?
> >
>
> Hi Chukun, thanks for your response.
>
> At Andrew Lunn's suggestion, I'm doing
> more granular and rigorous testing, now using iperf3. I'll post more details
> of results here after I retest a couple of scenarios.
>
> However, I will report now that so far, I'm getting better (faster) and more
> consistent results using iperf3.
>
> ~Erik
Below are my results.
In summary, the speeds in certain scenarios are closer than in others.
Pooling everything together, at the eyeball level, things look pretty similar
across using RGMII-ID and RGMII (no internal delay). If I were to run these
tests repeatedly, pool the results, and do a statistical comparison (probably
with a Kolmogorov-Smirnov (KS) test or similar), I doubt I could reject the
null hypothesis of no significant difference between the two sample
distributions.
So what I said earlier regarding rgmii vs rgmii-id DOES NOT hold up under
more rigorous and careful testing.
Thanks,
Erik
___________________________
Results with (gmac0 & gmac1) phy-mode = "rgmii-id", tx_rx_delay unspecified
(kernel on boot sets tx_delay = 0x30 and rx_delay = 0x10 itself, both gmacs)
eth0/wan
iperf3 -s -F VidTest-1.4Gb.mp4
{openwrt device is 192.168.2.241}
{desktop on openwrt WAN is 192.168.2.90}
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.2.241, port 44414
[ 5] local 192.168.2.90 port 5201 connected to 192.168.2.241 port 44422
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 112 MBytes 935 Mbits/sec
[ 5] 1.00-2.00 sec 112 MBytes 939 Mbits/sec
[ 5] 2.00-3.00 sec 112 MBytes 940 Mbits/sec
[ 5] 3.00-4.00 sec 112 MBytes 939 Mbits/sec
[ 5] 4.00-5.00 sec 112 MBytes 939 Mbits/sec
[ 5] 5.00-6.00 sec 112 MBytes 939 Mbits/sec
[ 5] 6.00-7.00 sec 112 MBytes 938 Mbits/sec
[ 5] 7.00-8.00 sec 112 MBytes 940 Mbits/sec
[ 5] 8.00-9.00 sec 112 MBytes 938 Mbits/sec
[ 5] 9.00-10.00 sec 112 MBytes 940 Mbits/sec
[ 5] 10.00-10.00 sec 384 KBytes 815 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
Sent 1.09 GByte / 1.09 GByte (100%) of VidTest-1.4Gb.mp4
[ 5] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec receiver
-----------------------------------------------------------
< Reverse >
iperf3 -s
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.2.241, port 45870
[ 5] local 192.168.2.90 port 5201 connected to 192.168.2.241 port 45886
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 114 MBytes 953 Mbits/sec 120 158 KBytes
[ 5] 1.00-2.00 sec 112 MBytes 935 Mbits/sec 143 141 KBytes
[ 5] 2.00-3.00 sec 110 MBytes 923 Mbits/sec 131 195 KBytes
[ 5] 3.00-4.00 sec 112 MBytes 939 Mbits/sec 142 167 KBytes
[ 5] 4.00-5.00 sec 112 MBytes 942 Mbits/sec 136 133 KBytes
[ 5] 5.00-6.00 sec 111 MBytes 929 Mbits/sec 119 175 KBytes
[ 5] 6.00-7.00 sec 111 MBytes 932 Mbits/sec 126 115 KBytes
[ 5] 7.00-8.00 sec 112 MBytes 943 Mbits/sec 150 113 KBytes
[ 5] 8.00-9.00 sec 105 MBytes 884 Mbits/sec 28 110 KBytes
[ 5] 9.00-10.00 sec 112 MBytes 938 Mbits/sec 140 160 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.08 GBytes 932 Mbits/sec 1235 sender
eth1/lan
iperf3 -s -F VidTest-1.4Gb.mp4
-----------------------------------------------------------
{openwrt device is 192.168.1.1}
{Laptop attached to openwrt is 192.168.1.134}
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.1.1, port 53876
[ 5] local 192.168.1.134 port 5201 connected to 192.168.1.1 port 53890
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 31.9 MBytes 267 Mbits/sec
[ 5] 1.00-2.00 sec 32.5 MBytes 273 Mbits/sec
[ 5] 2.00-3.00 sec 33.6 MBytes 282 Mbits/sec
[ 5] 3.00-4.00 sec 29.2 MBytes 245 Mbits/sec
[ 5] 4.00-5.00 sec 33.8 MBytes 283 Mbits/sec
[ 5] 5.00-6.00 sec 32.6 MBytes 274 Mbits/sec
[ 5] 6.00-7.00 sec 34.1 MBytes 286 Mbits/sec
[ 5] 7.00-8.00 sec 35.0 MBytes 294 Mbits/sec
[ 5] 8.00-9.00 sec 33.6 MBytes 282 Mbits/sec
[ 5] 9.00-10.00 sec 32.8 MBytes 275 Mbits/sec
[ 5] 10.00-10.00 sec 128 KBytes 872 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
Sent 329 MByte / 329 MByte (100%) of VidTest-1.4Gb.mp4
[ 5] 0.00-10.00 sec 329 MBytes 276 Mbits/sec receiver
-----------------------------------------------------------
< reverse >
iperf3 -c 192.168.1.1
Connecting to host 192.168.1.1, port 5201
[ 5] local 192.168.1.134 port 60508 connected to 192.168.1.1 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 113 MBytes 948 Mbits/sec 0 393 KBytes
[ 5] 1.00-2.00 sec 111 MBytes 931 Mbits/sec 0 411 KBytes
[ 5] 2.00-3.00 sec 112 MBytes 935 Mbits/sec 0 433 KBytes
[ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec 0 433 KBytes
[ 5] 4.00-5.00 sec 111 MBytes 934 Mbits/sec 0 433 KBytes
[ 5] 5.00-6.00 sec 111 MBytes 932 Mbits/sec 0 433 KBytes
[ 5] 6.00-7.00 sec 111 MBytes 930 Mbits/sec 0 433 KBytes
[ 5] 7.00-8.00 sec 111 MBytes 934 Mbits/sec 0 433 KBytes
[ 5] 8.00-9.00 sec 111 MBytes 932 Mbits/sec 0 433 KBytes
[ 5] 9.00-10.00 sec 113 MBytes 944 Mbits/sec 0 573 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.09 GBytes 936 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.09 GBytes 933 Mbits/sec receiver
Throughput (wan (eth0) -> lan (eth1) -> laptop)
Desktop <------> Laptop via Openwrt
192.168.2.90 192.168.1.134
iperf3 -c 192.168.2.90
Connecting to host 192.168.2.90, port 5201
[ 5] local 192.168.1.134 port 54694 connected to 192.168.2.90 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 106 MBytes 889 Mbits/sec 0 461 KBytes
[ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec 0 461 KBytes
[ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec 0 461 KBytes
[ 5] 3.00-4.00 sec 111 MBytes 934 Mbits/sec 0 461 KBytes
[ 5] 4.00-5.00 sec 111 MBytes 932 Mbits/sec 0 461 KBytes
[ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec 0 461 KBytes
[ 5] 6.00-7.00 sec 111 MBytes 931 Mbits/sec 0 503 KBytes
[ 5] 7.00-8.00 sec 112 MBytes 938 Mbits/sec 0 503 KBytes
[ 5] 8.00-9.00 sec 111 MBytes 931 Mbits/sec 0 503 KBytes
[ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec 0 503 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.08 GBytes 929 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.08 GBytes 927 Mbits/sec receive
< Reverse >
iperf3 -c 192.168.2.90
Connecting to host 192.168.2.90, port 5201
[ 5] local 192.168.1.134 port 54694 connected to 192.168.2.90 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 106 MBytes 889 Mbits/sec 0 461 KBytes
[ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec 0 461 KBytes
[ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec 0 461 KBytes
[ 5] 3.00-4.00 sec 111 MBytes 934 Mbits/sec 0 461 KBytes
[ 5] 4.00-5.00 sec 111 MBytes 932 Mbits/sec 0 461 KBytes
[ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec 0 461 KBytes
[ 5] 6.00-7.00 sec 111 MBytes 931 Mbits/sec 0 503 KBytes
[ 5] 7.00-8.00 sec 112 MBytes 938 Mbits/sec 0 503 KBytes
[ 5] 8.00-9.00 sec 111 MBytes 931 Mbits/sec 0 503 KBytes
[ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec 0 503 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.08 GBytes 929 Mbits/sec 0 sender
[ 5] 0.00-10.00 sec 1.08 GBytes 927 Mbits/sec receive
---------
Results with (gmac0 & gmac1) phy-mode = "rgmii", tx_rx_delay unspecified
(kernel on boot sets tx_delay = 0x30 and rx_delay = 0x10 itself, both gmacs)
eth0/wan
iperf3 -s -F VidTest-1.4Gb.mp4
{openwrt device is 192.168.2.241}
{desktop on openwrt WAN is 192.168.2.90}
iperf3 -s -F VidTest-1.4Gb.mp4
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.2.241, port 35070
[ 5] local 192.168.2.90 port 5201 connected to 192.168.2.241 port 35084
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 112 MBytes 936 Mbits/sec
[ 5] 1.00-2.00 sec 112 MBytes 939 Mbits/sec
[ 5] 2.00-3.00 sec 112 MBytes 938 Mbits/sec
[ 5] 3.00-4.00 sec 112 MBytes 939 Mbits/sec
[ 5] 4.00-5.00 sec 112 MBytes 939 Mbits/sec
[ 5] 5.00-6.00 sec 112 MBytes 940 Mbits/sec
[ 5] 6.00-7.00 sec 112 MBytes 938 Mbits/sec
[ 5] 7.00-8.00 sec 112 MBytes 940 Mbits/sec
[ 5] 8.00-9.00 sec 112 MBytes 939 Mbits/sec
[ 5] 9.00-10.00 sec 112 MBytes 939 Mbits/sec
[ 5] 10.00-10.00 sec 384 KBytes 869 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
Sent 1.09 GByte / 1.09 GByte (100%) of VidTest-1.4Gb.mp4
[ 5] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec receiver
-----------------------------------------------------------
<reverse>
Accepted connection from 192.168.2.241, port 51650
[ 5] local 192.168.2.90 port 5201 connected to 192.168.2.241 port 51660
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 114 MBytes 953 Mbits/sec 168 209 KBytes
[ 5] 1.00-2.00 sec 112 MBytes 938 Mbits/sec 224 148 KBytes
[ 5] 2.00-3.00 sec 112 MBytes 940 Mbits/sec 196 158 KBytes
[ 5] 3.00-4.00 sec 112 MBytes 943 Mbits/sec 196 180 KBytes
[ 5] 4.00-5.00 sec 112 MBytes 937 Mbits/sec 196 187 KBytes
[ 5] 5.00-6.00 sec 112 MBytes 940 Mbits/sec 196 195 KBytes
[ 5] 6.00-7.00 sec 112 MBytes 937 Mbits/sec 196 204 KBytes
[ 5] 7.00-8.00 sec 112 MBytes 940 Mbits/sec 224 136 KBytes
[ 5] 8.00-9.00 sec 112 MBytes 940 Mbits/sec 196 158 KBytes
[ 5] 9.00-10.00 sec 110 MBytes 922 Mbits/sec 196 188 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 1.09 GBytes 939 Mbits/sec 1988 sender
Sent 1.09 GByte / 1.09 GByte (100%) of VidTest-1.4Gb.mp4
-----------------------------------------------------------
eth1/lan
{192.168.1.1 is Openwrt device}
{192.168.1.134 is laptop directly attached to Openwrt}
iperf3 -s -F VidTest-1.4Gb.mp4
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------
Accepted connection from 192.168.1.1, port 40866
[ 5] local 192.168.1.134 port 5201 connected to 192.168.1.1 port 40868
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 67.4 MBytes 565 Mbits/sec
[ 5] 1.00-2.00 sec 69.4 MBytes 582 Mbits/sec
[ 5] 2.00-3.00 sec 65.9 MBytes 553 Mbits/sec
[ 5] 3.00-4.00 sec 66.5 MBytes 558 Mbits/sec
[ 5] 4.00-5.00 sec 70.2 MBytes 589 Mbits/sec
[ 5] 5.00-6.00 sec 52.5 MBytes 440 Mbits/sec
[ 5] 6.00-7.00 sec 67.2 MBytes 564 Mbits/sec
[ 5] 7.00-8.00 sec 70.2 MBytes 589 Mbits/sec
[ 5] 8.00-9.00 sec 57.9 MBytes 486 Mbits/sec
[ 5] 9.00-10.00 sec 66.9 MBytes 561 Mbits/sec
[ 5] 10.00-10.00 sec 128 KBytes 909 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
Sent 654 MByte / 654 MByte (100%) of VidTest-1.4Gb.mp4
[ 5] 0.00-10.00 sec 654 MBytes 549 Mbits/sec receiver
< reverse >
iperf3 -c 192.168.1.134 --reverse
Connecting to host 192.168.1.134, port 5201
Reverse mode, remote host 192.168.1.134 is sending
[ 5] local 192.168.1.1 port 58380 connected to 192.168.1.134 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 104 MBytes 870 Mbits/sec
[ 5] 1.00-2.00 sec 98.5 MBytes 826 Mbits/sec
[ 5] 2.00-3.00 sec 89.9 MBytes 754 Mbits/sec
[ 5] 3.00-4.00 sec 87.4 MBytes 733 Mbits/sec
[ 5] 4.00-5.00 sec 97.0 MBytes 814 Mbits/sec
[ 5] 5.00-6.00 sec 95.5 MBytes 801 Mbits/sec
[ 5] 6.00-7.00 sec 82.1 MBytes 689 Mbits/sec
[ 5] 7.00-8.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 8.00-9.00 sec 0.00 Bytes 0.00 bits/sec
[ 5] 9.00-10.00 sec 0.00 Bytes 0.00 bits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 654 MBytes 549 Mbits/sec 235 sender
[ 5] 0.00-10.00 sec 654 MBytes 549 Mbits/sec receiver
Throughput (wan (eth0) -> lan (eth1) -> laptop)
Desktop <------> Laptop via Openwrt
192.168.2.90 192.168.1.134
iperf3 -c 192.168.2.90
Connecting to host 192.168.2.90, port 5201
[ 5] local 192.168.1.134 port 44380 connected to 192.168.2.90 port 5201
[ ID] Interval Transfer Bitrate Retr Cwnd
[ 5] 0.00-1.00 sec 91.8 MBytes 769 Mbits/sec 15 76.4 KBytes
[ 5] 1.00-2.00 sec 99.5 MBytes 835 Mbits/sec 11 102 KBytes
[ 5] 2.00-3.00 sec 98.8 MBytes 828 Mbits/sec 12 167 KBytes
[ 5] 3.00-4.00 sec 95.4 MBytes 800 Mbits/sec 17 126 KBytes
[ 5] 4.00-5.00 sec 106 MBytes 890 Mbits/sec 9 117 KBytes
[ 5] 5.00-6.00 sec 96.5 MBytes 810 Mbits/sec 15 123 KBytes
[ 5] 6.00-7.00 sec 99.6 MBytes 835 Mbits/sec 13 144 KBytes
[ 5] 7.00-8.00 sec 100 MBytes 842 Mbits/sec 15 58.0 KBytes
[ 5] 8.00-9.00 sec 96.1 MBytes 806 Mbits/sec 15 115 KBytes
[ 5] 9.00-10.00 sec 95.4 MBytes 800 Mbits/sec 14 126 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 980 MBytes 822 Mbits/sec 136 sender
[ 5] 0.00-10.00 sec 979 MBytes 821 Mbits/sec receiver
< reverse >
perf3 -c 192.168.2.90 --reverse
Connecting to host 192.168.2.90, port 5201
Reverse mode, remote host 192.168.2.90 is sending
[ 5] local 192.168.1.134 port 51148 connected to 192.168.2.90 port 5201
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 40.6 MBytes 340 Mbits/sec
[ 5] 1.00-2.00 sec 54.9 MBytes 460 Mbits/sec
[ 5] 2.00-3.00 sec 49.6 MBytes 416 Mbits/sec
[ 5] 3.00-4.00 sec 47.4 MBytes 397 Mbits/sec
[ 5] 4.00-5.00 sec 45.9 MBytes 385 Mbits/sec
[ 5] 5.00-6.00 sec 52.8 MBytes 443 Mbits/sec
[ 5] 6.00-7.00 sec 45.1 MBytes 379 Mbits/sec
[ 5] 7.00-8.00 sec 46.1 MBytes 387 Mbits/sec
[ 5] 8.00-9.00 sec 42.8 MBytes 359 Mbits/sec
[ 5] 9.00-10.00 sec 40.6 MBytes 341 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 467 MBytes 392 Mbits/sec 403 sender
[ 5] 0.00-10.00 sec 466 MBytes 391 Mbits/sec receiver
____________________________________
>
> > I can't reproduce your problem in my test.
> >
> > eth0/gmac1 (as lan):
> > root@OpenWrt:~# iperf3 -c 192.168.1.100
> > Connecting to host 192.168.1.100, port 5201
> > [ ID] Interval Transfer Bitrate Retr
> > [ 5] 0.00-10.00 sec 1.10 GBytes 942 Mbits/sec 29
> > sender [ 5] 0.00-10.04 sec 1.10 GBytes 936 Mbits/sec
> > receiver
> >
> > root@OpenWrt:~# iperf3 -c 192.168.1.100 -R
> > Connecting to host 192.168.1.100, port 5201
> > Reverse mode, remote host 192.168.1.100 is sending
> > [ ID] Interval Transfer Bitrate Retr
> > [ 5] 0.00-10.04 sec 1.10 GBytes 939 Mbits/sec 1
> > sender [ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec
> > receiver
> >
> > eth1/gmac0 (as wan):
> > root@OpenWrt:~# iperf3 -c 192.168.0.2 -P 4
> > Connecting to host 192.168.0.2, port 5201
> > [ ID] Interval Transfer Bitrate Retr
> > [SUM] 0.00-10.00 sec 1.10 GBytes 945 Mbits/sec 1191
> > sender [SUM] 0.00-10.05 sec 1.09 GBytes 935 Mbits/sec
> > receiver
> >
> > root@OpenWrt:~# iperf3 -c 192.168.0.2 -R
> > Connecting to host 192.168.0.2, port 5201
> > Reverse mode, remote host 192.168.0.2 is sending
> > [ ID] Interval Transfer Bitrate Retr
> > [ 5] 0.00-10.06 sec 1.10 GBytes 939 Mbits/sec 6
> > sender [ 5] 0.00-10.00 sec 1.10 GBytes 941 Mbits/sec
> > receiver
> >
> > --
> > 2.25.1
> >
> >
> >
> > _______________________________________________
> > Linux-rockchip mailing list
> > Linux-rockchip@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip
>
^ permalink raw reply [flat|nested] 24+ messages in thread
* [PATCH 4/4] arm64: dts: rockchip: Add HINLINK H66K
2025-08-18 10:00 [PATCH 0/4] arm64: dts: rockchip: Add HINLINK H66K/H68K Chukun Pan
` (2 preceding siblings ...)
2025-08-18 10:00 ` [PATCH 3/4] arm64: dts: rockchip: Add HINLINK H68K Chukun Pan
@ 2025-08-18 10:00 ` Chukun Pan
2025-08-18 17:27 ` [PATCH 0/4] arm64: dts: rockchip: Add HINLINK H66K/H68K Conor Dooley
2025-08-24 10:54 ` Heiko Stuebner
5 siblings, 0 replies; 24+ messages in thread
From: Chukun Pan @ 2025-08-18 10:00 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Chukun Pan, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
linux-arm-kernel, linux-rockchip, linux-kernel, devicetree
The HINLINK H66K is a development board with the
Rockchip RK3568 SoC. It has the following features:
- 2/4GB LPDDR4
- 1x HDMI Type A
- 3.5mm jack with mic
- 1x PCIE 2.0 WiFi slot
- 1x USB 3.0, 2x USB 2.0
- 2x 2.5GbE RTL8125B Ethernet
- MicroSD card slot / eMMC 32GB
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
---
arch/arm64/boot/dts/rockchip/Makefile | 1 +
arch/arm64/boot/dts/rockchip/rk3568-hinlink-h66k.dts | 10 ++++++++++
2 files changed, 11 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3568-hinlink-h66k.dts
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 09c810cb64a4..93e547a1c77b 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -130,6 +130,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-bpi-r2-pro.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-evb1-v10.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-fastrhino-r66s.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-fastrhino-r68s.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-hinlink-h66k.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-hinlink-h68k.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-lubancat-2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3568-mecsbc.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-hinlink-h66k.dts b/arch/arm64/boot/dts/rockchip/rk3568-hinlink-h66k.dts
new file mode 100644
index 000000000000..bc51123d53f5
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3568-hinlink-h66k.dts
@@ -0,0 +1,10 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3568-hinlink-opc.dtsi"
+
+/ {
+ model = "HINLINK H66K";
+ compatible = "hinlink,h66k", "rockchip,rk3568";
+};
--
2.25.1
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: [PATCH 0/4] arm64: dts: rockchip: Add HINLINK H66K/H68K
2025-08-18 10:00 [PATCH 0/4] arm64: dts: rockchip: Add HINLINK H66K/H68K Chukun Pan
` (3 preceding siblings ...)
2025-08-18 10:00 ` [PATCH 4/4] arm64: dts: rockchip: Add HINLINK H66K Chukun Pan
@ 2025-08-18 17:27 ` Conor Dooley
2025-08-24 10:54 ` Heiko Stuebner
5 siblings, 0 replies; 24+ messages in thread
From: Conor Dooley @ 2025-08-18 17:27 UTC (permalink / raw)
To: Chukun Pan
Cc: Heiko Stuebner, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
linux-arm-kernel, linux-rockchip, linux-kernel, devicetree
[-- Attachment #1: Type: text/plain, Size: 216 bytes --]
On Mon, Aug 18, 2025 at 06:00:05PM +0800, Chukun Pan wrote:
> dt-bindings: vendor-prefixes: Add HINLINK
> dt-bindings: arm: rockchip: Add HINLINK H66K / H68K
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 0/4] arm64: dts: rockchip: Add HINLINK H66K/H68K
2025-08-18 10:00 [PATCH 0/4] arm64: dts: rockchip: Add HINLINK H66K/H68K Chukun Pan
` (4 preceding siblings ...)
2025-08-18 17:27 ` [PATCH 0/4] arm64: dts: rockchip: Add HINLINK H66K/H68K Conor Dooley
@ 2025-08-24 10:54 ` Heiko Stuebner
2025-08-30 21:11 ` Erik Beck
5 siblings, 1 reply; 24+ messages in thread
From: Heiko Stuebner @ 2025-08-24 10:54 UTC (permalink / raw)
To: Chukun Pan
Cc: Heiko Stuebner, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
linux-arm-kernel, linux-rockchip, linux-kernel, devicetree
On Mon, 18 Aug 2025 18:00:05 +0800, Chukun Pan wrote:
> The HINLINK H66K and H68K are development boards with the Rockchip
> RK3568 SoC. These boards are all SoM plus expansion board structures.
>
> Both boards can be booted from eMMC or SD-card using the
> U-Boot 2025.07 generic-rk3568 target.
>
> The SoM board has CPU, RAM, eMMC and RK809 PMIC.
> There is no schematic for this part.
>
> [...]
Applied, thanks!
[1/4] dt-bindings: vendor-prefixes: Add HINLINK
commit: 7d11b8c260ea68ce8f420ad467b04b21ea34b011
[2/4] dt-bindings: arm: rockchip: Add HINLINK H66K / H68K
commit: 4bef07b79ab1ef7d963eaa2c37948030e418d538
[3/4] arm64: dts: rockchip: Add HINLINK H68K
commit: 86a504b82f8d0e34f99ab9607712e7942c919fa3
[4/4] arm64: dts: rockchip: Add HINLINK H66K
commit: bb9ef44f05c9558d58e3c9da141e93af1aa11c1f
Best regards,
--
Heiko Stuebner <heiko@sntech.de>
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: [PATCH 0/4] arm64: dts: rockchip: Add HINLINK H66K/H68K
2025-08-24 10:54 ` Heiko Stuebner
@ 2025-08-30 21:11 ` Erik Beck
2025-08-30 21:26 ` Andrew Lunn
0 siblings, 1 reply; 24+ messages in thread
From: Erik Beck @ 2025-08-30 21:11 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Chukun Pan, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
linux-arm-kernel, linux-rockchip, linux-kernel, devicetree
On Sun, 24 Aug 2025 12:54:40 +0200
Heiko Stuebner <heiko@sntech.de> wrote:
> On Mon, 18 Aug 2025 18:00:05 +0800, Chukun Pan wrote:
> > The HINLINK H66K and H68K are development boards with the Rockchip
> > RK3568 SoC. These boards are all SoM plus expansion board structures.
> >
> > Both boards can be booted from eMMC or SD-card using the
> > U-Boot 2025.07 generic-rk3568 target.
> >
> > The SoM board has CPU, RAM, eMMC and RK809 PMIC.
> > There is no schematic for this part.
> >
> > [...]
>
> Applied, thanks!
Hi, apologies in advance if I'm going against protocol, but I'm still really
new at the techniques for Linux patch development.
As you may recall, I've been working on a similar patch for the nearly
identical SeeedStudio LinkStar H68K (v1). I found this recent work from
Chukun earlier today; my work, in part, relied on an offshoot of Chukun's
work from circa 2022 and other inspirations from other rk3568 boards.
(See
https://lore.kernel.org/linux-devicetree/20250723135008.1077970-1-amadeus@jmu.edu.cn/
for example.)
Chukun's work from 18 August 2025 is better and more complete than where my
code currently is, with one exception: the gmac0/1 phy-modes.
As I worked on my dts, I discovered that the 1Gb ethernet ports, using an
RTL8211, don't support rgmii-id mode; only rgmii.
(https://www.realtek.com/Product/Index?id=3976&cate_id=786).
Changing this makes a huge difference in the ethernet throughput speed. With
rgmii-id mode specified, throughput is about 6.5 Mbs. Changing this to rgmii
mode increases throughput to about 960 Mbs.
I tested this on Chukun's code by making that change, and essentially
backporting to my OpenWRT testing profile, using kernel 6.12 and U-Boot 25.04
(also backporting the Hinlink dts to U-Boot).
I saw this over 100x speed difference both with my tree and Chukun's.
I'll make a note of this in Chukun's patch email for the dts shortly.
I'd like to help support further development of the HinLink/Linkstar patches,
and am happy to base whatever assistance I can provide off Chukun's work.
Please advise on how I can best contribute.
Regards,
Erik
>
> [1/4] dt-bindings: vendor-prefixes: Add HINLINK
> commit: 7d11b8c260ea68ce8f420ad467b04b21ea34b011
> [2/4] dt-bindings: arm: rockchip: Add HINLINK H66K / H68K
> commit: 4bef07b79ab1ef7d963eaa2c37948030e418d538
> [3/4] arm64: dts: rockchip: Add HINLINK H68K
> commit: 86a504b82f8d0e34f99ab9607712e7942c919fa3
> [4/4] arm64: dts: rockchip: Add HINLINK H66K
> commit: bb9ef44f05c9558d58e3c9da141e93af1aa11c1f
>
> Best regards,
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/4] arm64: dts: rockchip: Add HINLINK H66K/H68K
2025-08-30 21:11 ` Erik Beck
@ 2025-08-30 21:26 ` Andrew Lunn
2025-08-30 22:20 ` Erik Beck
0 siblings, 1 reply; 24+ messages in thread
From: Andrew Lunn @ 2025-08-30 21:26 UTC (permalink / raw)
To: Erik Beck
Cc: Heiko Stuebner, Chukun Pan, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, linux-arm-kernel, linux-rockchip,
linux-kernel, devicetree
> As I worked on my dts, I discovered that the 1Gb ethernet ports, using an
> RTL8211, don't support rgmii-id mode; only rgmii.
> (https://www.realtek.com/Product/Index?id=3976&cate_id=786).
Which exact RTL8211 does the board use? You link to information for
the RTL8211FD(I)-CG, which i assume is supported in Linux as RTL8211F.
https://elixir.bootlin.com/linux/v6.16.3/source/drivers/net/phy/realtek/realtek_main.c#L519
This indicates it supports all four RGMII modes. And in general, all
PHY drivers in Linux for RGMII PHYs support all four RGMII modes.
> Changing this makes a huge difference in the ethernet throughput speed. With
> rgmii-id mode specified, throughput is about 6.5 Mbs. Changing this to rgmii
> mode increases throughput to about 960 Mbs.
Here is some more information about that the four RGMII modes mean,
and how you should use them in Linux:
https://elixir.bootlin.com/linux/v6.16.3/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L264
Andrew
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/4] arm64: dts: rockchip: Add HINLINK H66K/H68K
2025-08-30 21:26 ` Andrew Lunn
@ 2025-08-30 22:20 ` Erik Beck
2025-08-31 13:55 ` Erik Beck
0 siblings, 1 reply; 24+ messages in thread
From: Erik Beck @ 2025-08-30 22:20 UTC (permalink / raw)
To: Andrew Lunn
Cc: Heiko Stuebner, Chukun Pan, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, linux-arm-kernel, linux-rockchip,
linux-kernel, devicetree
> On Aug 30, 2025, at 17:30, Andrew Lunn <andrew@lunn.ch> wrote:
>
>
>>
>> As I worked on my dts, I discovered that the 1Gb ethernet ports, using an
>> RTL8211, don't support rgmii-id mode; only rgmii.
>> (https://www.realtek.com/Product/Index?id=3976&cate_id=786).
>
> Which exact RTL8211 does the board use? You link to information for
> the RTL8211FD(I)-CG, which i assume is supported in Linux as RTL8211F.
Thanks Andrew; It isn't clear to me which specific variation it has. I'll take another look at the boot logs and see. The silkscreen on the chips are faint, but will look there too.
>
> https://elixir.bootlin.com/linux/v6.16.3/source/drivers/net/phy/realtek/realtek_main.c#L519
>
> This indicates it supports all four RGMII modes. And in general, all
> PHY drivers in Linux for RGMII PHYs support all four RGMII modes.
>
>> Changing this makes a huge difference in the ethernet throughput speed. With
>> rgmii-id mode specified, throughput is about 6.5 Mbs. Changing this to rgmii
>> mode increases throughput to about 960 Mbs.
>
> Here is some more information about that the four RGMII modes mean,
> and how you should use them in Linux:
>
> https://elixir.bootlin.com/linux/v6.16.3/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L264
>
> Andrew
Thank you!
>
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: [PATCH 0/4] arm64: dts: rockchip: Add HINLINK H66K/H68K
2025-08-30 22:20 ` Erik Beck
@ 2025-08-31 13:55 ` Erik Beck
0 siblings, 0 replies; 24+ messages in thread
From: Erik Beck @ 2025-08-31 13:55 UTC (permalink / raw)
To: Andrew Lunn
Cc: Heiko Stuebner, Chukun Pan, Rob Herring, Conor Dooley,
Krzysztof Kozlowski, linux-arm-kernel, linux-rockchip,
linux-kernel, devicetree
On Sat, 30 Aug 2025 18:20:50 -0400
Erik Beck <xunil@tahomasoft.com> wrote:
> > On Aug 30, 2025, at 17:30, Andrew Lunn <andrew@lunn.ch> wrote:
> >
> >
> >>
> >> As I worked on my dts, I discovered that the 1Gb ethernet ports, using an
> >> RTL8211, don't support rgmii-id mode; only rgmii.
> >> (https://www.realtek.com/Product/Index?id=3976&cate_id=786).
> >
> > Which exact RTL8211 does the board use? You link to information for
> > the RTL8211FD(I)-CG, which i assume is supported in Linux as RTL8211F.
>
> Thanks Andrew; It isn't clear to me which specific variation it has. I'll
> take another look at the boot logs and see. The silkscreen on the chips are
> faint, but will look there too.
dmesg reports it is an RTL8211F.
> >
> > https://elixir.bootlin.com/linux/v6.16.3/source/drivers/net/phy/realtek/realtek_main.c#L519
> >
> > This indicates it supports all four RGMII modes. And in general, all
> > PHY drivers in Linux for RGMII PHYs support all four RGMII modes.
> >
> >> Changing this makes a huge difference in the ethernet throughput speed.
> >> With rgmii-id mode specified, throughput is about 6.5 Mbs. Changing this
> >> to rgmii mode increases throughput to about 960 Mbs.
> >
> > Here is some more information about that the four RGMII modes mean,
> > and how you should use them in Linux:
> >
> > https://elixir.bootlin.com/linux/v6.16.3/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L264
> >
> > Andrew
>
> Thank you!
> >
> > _______________________________________________
> > Linux-rockchip mailing list
> > Linux-rockchip@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply [flat|nested] 24+ messages in thread