[PATCH 0/4] arm64: dts: rockchip: enable further peripherals on ArmSoM Sige5

[PATCH 0/4] arm64: dts: rockchip: enable further peripherals on ArmSoM Sige5

[Alexey Charkov]

Add support for the two USB type A ports, link up the CPU regulators for
DVFS, enable WiFi and Bluetooth.

The bluetooth part might warrant some discussion and thoughts from the
list, given that it's connected over UART and thus not discoverable. At
the same time, there are two revisions of the board which have different
Bluetooth chips soldered on: Realtek based on v1.1 and Broadcom based on
v1.2. I'm not sure if there is any way to determine board version from
software. Mine is v1.2, so the respective patch deals with the Broadcom
case only, but maybe it's better to move it into a .dtso and thus kick
the can down the road (i.e. make the user deal with board identification
and loading of the right overlay)? Thoughts welcome.

Best regards,
Alexey

Signed-off-by: Alexey Charkov <alchark@gmail.com>
---
Alexey Charkov (4):
      arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5
      arm64: dts: rockchip: enable USB A ports on ArmSoM Sige5
      arm64: dts: rockchip: enable wifi on ArmSoM Sige5
      arm64: dts: rockchip: enable bluetooth on ArmSoM Sige5

 .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 135 +++++++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3576.dtsi           |  16 +++
 2 files changed, 151 insertions(+)
---
base-commit: 546b1c9e93c2bb8cf5ed24e0be1c86bb089b3253
change-id: 20250602-sige5-updates-a162b501a1b1

Best regards,
-- 
Alexey Charkov <alchark@gmail.com>

[PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Alexey Charkov]

List both CPU supply regulators which drive the little and big CPU
clusters, respectively, so that cpufreq can pick them up.

Signed-off-by: Alexey Charkov <alchark@gmail.com>
---
 .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 28 ++++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
index b09e789c75c47fec7cf7e9810ab0dcca32d9404a..d9c129be55a0d997e04e6d677cdc98fb50353418 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
@@ -207,6 +207,22 @@ vcc_3v3_ufs_s0: regulator-vcc-ufs-s0 {
 	};
 };
 
+&cpu_b0 {
+	cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&cpu_b1 {
+	cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&cpu_b2 {
+	cpu-supply = <&vdd_cpu_big_s0>;
+};
+
+&cpu_b3 {
+	cpu-supply = <&vdd_cpu_big_s0>;
+};
+
 &combphy0_ps {
 	status = "okay";
 };
@@ -215,6 +231,18 @@ &cpu_l0 {
 	cpu-supply = <&vdd_cpu_lit_s0>;
 };
 
+&cpu_l1 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l2 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
+&cpu_l3 {
+	cpu-supply = <&vdd_cpu_lit_s0>;
+};
+
 &gmac0 {
 	phy-mode = "rgmii-id";
 	clock_in_out = "output";

-- 
2.49.0

[PATCH 2/4] arm64: dts: rockchip: enable USB A ports on ArmSoM Sige5

[Alexey Charkov]

Enable the two USB type A ports (USB2 and USB3) present on the ArmSoM
Sige5 board.

Both ports use just one xHCI controller, with the USB 2.0 signals fed
off the same USB OTG PHY through an onboard hub. VBUS of both ports is
controlled by the same GPIO regulator (VCC_USBHOST in the schematics,
toggled by GPIO4 RK_PA6).

Signed-off-by: Alexey Charkov <alchark@gmail.com>
---
 .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 38 ++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
index d9c129be55a0d997e04e6d677cdc98fb50353418..7ce1fb1380b0863c902fdd9cbc7454ee6011cf92 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
@@ -205,6 +205,24 @@ vcc_3v3_ufs_s0: regulator-vcc-ufs-s0 {
 		regulator-max-microvolt = <3300000>;
 		vin-supply = <&vcc_5v0_sys>;
 	};
+
+	vcc_5v0_host: regulator-vcc-5v0-host {
+		compatible = "regulator-fixed";
+		regulator-name = "vcc_5v0_host";
+		regulator-boot-on;
+		regulator-always-on;
+		regulator-min-microvolt = <5000000>;
+		regulator-max-microvolt = <5000000>;
+		enable-active-high;
+		gpio = <&gpio4 RK_PA4 GPIO_ACTIVE_HIGH>;
+		vin-supply = <&vcc_5v0_device>;
+		pinctrl-names = "default";
+		pinctrl-0 = <&usb_host_pwren>;
+	};
+};
+
+&combphy1_psu {
+	status = "okay";
 };
 
 &cpu_b0 {
@@ -757,6 +775,12 @@ pcie_reset: pcie-reset {
 			rockchip,pins = <2 RK_PB4 RK_FUNC_GPIO &pcfg_pull_up>;
 		};
 	};
+
+	usb {
+		usb_host_pwren: usb-host-pwren {
+			rockchip,pins = <4 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
 };
 
 &sai1 {
@@ -798,11 +822,25 @@ &sdmmc {
 	status = "okay";
 };
 
+&u2phy1 {
+	status = "okay";
+};
+
+&u2phy1_otg {
+	phy-supply = <&vcc_5v0_host>;
+	status = "okay";
+};
+
 &uart0 {
 	pinctrl-0 = <&uart0m0_xfer>;
 	status = "okay";
 };
 
+&usb_drd1_dwc3 {
+	dr_mode = "host";
+	status = "okay";
+};
+
 &vop {
 	status = "okay";
 };

-- 
2.49.0

[PATCH 3/4] arm64: dts: rockchip: enable wifi on ArmSoM Sige5

[Alexey Charkov]

ArmSoM Sige5 uses a soldered-on SDIO connected WiFi module. Namely,
board v1.1 uses a Realtek based BL-M8852BS2, while v1.2 uses a Broadcom
based BW3752-50B1.

Add required device tree nodes in the SoC .dtsi for the SDIO controller
and pinctrl / clock wiring in the board .dts for the module itself.

Signed-off-by: Alexey Charkov <alchark@gmail.com>
---
 .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 36 ++++++++++++++++++++++
 arch/arm64/boot/dts/rockchip/rk3576.dtsi           | 16 ++++++++++
 2 files changed, 52 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
index 7ce1fb1380b0863c902fdd9cbc7454ee6011cf92..dcd033859398312f7693bebb7f080ee4f2ecaa32 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
@@ -219,6 +219,15 @@ vcc_5v0_host: regulator-vcc-5v0-host {
 		pinctrl-names = "default";
 		pinctrl-0 = <&usb_host_pwren>;
 	};
+
+	sdio_pwrseq: sdio-pwrseq {
+		compatible = "mmc-pwrseq-simple";
+		clocks = <&hym8563>;
+		clock-names = "ext_clock";
+		pinctrl-names = "default";
+		pinctrl-0 = <&wifi_reg_on>;
+		reset-gpios = <&gpio1 RK_PC6 GPIO_ACTIVE_LOW>;
+	};
 };
 
 &combphy1_psu {
@@ -781,6 +790,16 @@ usb_host_pwren: usb-host-pwren {
 			rockchip,pins = <4 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
 		};
 	};
+
+	wireless-wlan {
+		wifi_wake_host: wifi-wake-host {
+			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+
+		wifi_reg_on: wifi-reg-on {
+			rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+		};
+	};
 };
 
 &sai1 {
@@ -808,6 +827,23 @@ &sdhci {
 	status = "okay";
 };
 
+&sdio {
+	bus-width = <4>;
+	cap-sdio-irq;
+	disable-wp;
+	keep-power-in-suspend;
+	mmc-pwrseq = <&sdio_pwrseq>;
+	no-sd;
+	no-mmc;
+	non-removable;
+	sd-uhs-sdr50;
+	sd-uhs-sdr104;
+	vmmc-supply = <&vcc_3v3_s3>;
+	vqmmc-supply = <&vcc_1v8_s3>;
+	wakeup-source;
+	status = "okay";
+};
+
 &sdmmc {
 	bus-width = <4>;
 	cap-mmc-highspeed;
diff --git a/arch/arm64/boot/dts/rockchip/rk3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
index 1086482f04792325dc4c22fb8ceeb27eef59afe4..a09582470bb7f654b711308da1e51fa8571ca1e8 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
@@ -1695,6 +1695,22 @@ sdmmc: mmc@2a310000 {
 			status = "disabled";
 		};
 
+		sdio: mmc@2a320000 {
+			compatible = "rockchip,rk3576-dw-mshc", "rockchip,rk3288-dw-mshc";
+			reg = <0x0 0x2a320000 0x0 0x4000>;
+			clocks = <&cru HCLK_SDIO>, <&cru CCLK_SRC_SDIO>;
+			clock-names = "biu", "ciu";
+			fifo-depth = <0x100>;
+			interrupts = <GIC_SPI 252 IRQ_TYPE_LEVEL_HIGH>;
+			max-frequency = <200000000>;
+			pinctrl-0 = <&sdmmc1m0_clk &sdmmc1m0_cmd &sdmmc1m0_bus4>;
+			pinctrl-names = "default";
+			power-domains = <&power RK3576_PD_SDGMAC>;
+			resets = <&cru SRST_H_SDIO>;
+			reset-names = "reset";
+			status = "disabled";
+		};
+
 		sdhci: mmc@2a330000 {
 			compatible = "rockchip,rk3576-dwcmshc", "rockchip,rk3588-dwcmshc";
 			reg = <0x0 0x2a330000 0x0 0x10000>;

-- 
2.49.0

[PATCH 4/4] arm64: dts: rockchip: enable bluetooth on ArmSoM Sige5

[Alexey Charkov]

ArmSoM Sige5 uses a soldered-on UART connected Bluetooth controller.
Namely, board v1.1 uses a Realtek based BL-M8852BS2, while v1.2 uses a
Broadcom based BW3752-50B1.

Add required device tree nodes to enable the Broadcom based module.

Signed-off-by: Alexey Charkov <alchark@gmail.com>
---
 .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 33 ++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
index dcd033859398312f7693bebb7f080ee4f2ecaa32..46e5d6e30898a0f937283e986f188947e10250ec 100644
--- a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
@@ -791,6 +791,20 @@ usb_host_pwren: usb-host-pwren {
 		};
 	};
 
+	wireless-bluetooth {
+		bt_reg_on: bt-reg-on {
+			rockchip,pins = <1 RK_PC7 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		host_wake_bt: host-wake-bt {
+			rockchip,pins = <1 RK_PD4 RK_FUNC_GPIO &pcfg_pull_up>;
+		};
+
+		bt_wake_host: bt-wake-host {
+			rockchip,pins = <0 RK_PB1 RK_FUNC_GPIO &pcfg_pull_down>;
+		};
+	};
+
 	wireless-wlan {
 		wifi_wake_host: wifi-wake-host {
 			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_down>;
@@ -872,6 +886,25 @@ &uart0 {
 	status = "okay";
 };
 
+&uart4 {
+	pinctrl-0 = <&uart4m1_xfer &uart4m1_ctsn &uart4m1_rtsn>;
+	pinctrl-names = "default";
+	uart-has-rtscts;
+	status = "okay";
+
+	bluetooth {
+		compatible = "brcm,bcm43438-bt";
+		clocks = <&hym8563>;
+		clock-names = "lpo";
+		device-wakeup-gpios = <&gpio1 RK_PD7 GPIO_ACTIVE_HIGH>;
+		interrupt-parent = <&gpio0>;
+		interrupts = <RK_PB1 IRQ_TYPE_EDGE_FALLING>;
+		pinctrl-0 = <&bt_reg_on>, <&bt_wake_host>, <&host_wake_bt>;
+		pinctrl-names = "default";
+		shutdown-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
+	};
+};
+
 &usb_drd1_dwc3 {
 	dr_mode = "host";
 	status = "okay";

-- 
2.49.0

Re: [PATCH 2/4] arm64: dts: rockchip: enable USB A ports on ArmSoM Sige5

[Nicolas Frattaroli]

On Tuesday, 3 June 2025 19:01:14 Central European Summer Time Alexey Charkov wrote:
> Enable the two USB type A ports (USB2 and USB3) present on the ArmSoM
> Sige5 board.
> 
> Both ports use just one xHCI controller, with the USB 2.0 signals fed
> off the same USB OTG PHY through an onboard hub. VBUS of both ports is
> controlled by the same GPIO regulator (VCC_USBHOST in the schematics,
> toggled by GPIO4 RK_PA6).
> 
> Signed-off-by: Alexey Charkov <alchark@gmail.com>
> ---
>  .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 38 ++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
> 

This is already done here:

https://lore.kernel.org/linux-rockchip/20250507-rk3576-sige5-usb-v3-4-89bf5a614ccf@collabora.com/

> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> index d9c129be55a0d997e04e6d677cdc98fb50353418..7ce1fb1380b0863c902fdd9cbc7454ee6011cf92 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> @@ -205,6 +205,24 @@ vcc_3v3_ufs_s0: regulator-vcc-ufs-s0 {
>  		regulator-max-microvolt = <3300000>;
>  		vin-supply = <&vcc_5v0_sys>;
>  	};
> +
> +	vcc_5v0_host: regulator-vcc-5v0-host {
> +		compatible = "regulator-fixed";
> +		regulator-name = "vcc_5v0_host";
> +		regulator-boot-on;
> +		regulator-always-on;
> +		regulator-min-microvolt = <5000000>;
> +		regulator-max-microvolt = <5000000>;
> +		enable-active-high;
> +		gpio = <&gpio4 RK_PA4 GPIO_ACTIVE_HIGH>;
> +		vin-supply = <&vcc_5v0_device>;
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&usb_host_pwren>;
> +	};
> +};
> +
> +&combphy1_psu {
> +	status = "okay";
>  };
>  
>  &cpu_b0 {
> @@ -757,6 +775,12 @@ pcie_reset: pcie-reset {
>  			rockchip,pins = <2 RK_PB4 RK_FUNC_GPIO &pcfg_pull_up>;
>  		};
>  	};
> +
> +	usb {
> +		usb_host_pwren: usb-host-pwren {
> +			rockchip,pins = <4 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
>  };
>  
>  &sai1 {
> @@ -798,11 +822,25 @@ &sdmmc {
>  	status = "okay";
>  };
>  
> +&u2phy1 {
> +	status = "okay";
> +};
> +
> +&u2phy1_otg {
> +	phy-supply = <&vcc_5v0_host>;
> +	status = "okay";
> +};
> +
>  &uart0 {
>  	pinctrl-0 = <&uart0m0_xfer>;
>  	status = "okay";
>  };
>  
> +&usb_drd1_dwc3 {
> +	dr_mode = "host";
> +	status = "okay";
> +};
> +
>  &vop {
>  	status = "okay";
>  };
> 
> 

Re: [PATCH 2/4] arm64: dts: rockchip: enable USB A ports on ArmSoM Sige5

[Alexey Charkov]

On Tue, Jun 3, 2025 at 9:51 PM Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
>
> On Tuesday, 3 June 2025 19:01:14 Central European Summer Time Alexey Charkov wrote:
> > Enable the two USB type A ports (USB2 and USB3) present on the ArmSoM
> > Sige5 board.
> >
> > Both ports use just one xHCI controller, with the USB 2.0 signals fed
> > off the same USB OTG PHY through an onboard hub. VBUS of both ports is
> > controlled by the same GPIO regulator (VCC_USBHOST in the schematics,
> > toggled by GPIO4 RK_PA6).
> >
> > Signed-off-by: Alexey Charkov <alchark@gmail.com>
> > ---
> >  .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 38 ++++++++++++++++++++++
> >  1 file changed, 38 insertions(+)
> >
>
> This is already done here:
>
> https://lore.kernel.org/linux-rockchip/20250507-rk3576-sige5-usb-v3-4-89bf5a614ccf@collabora.com/

Oh cool! Sorry I missed that one. Your series is much more
comprehensive, so this patch of mine can be dropped. Thanks for your
work!

Would you mind chiming in on the other patches here, given your
knowledge of the hardware?

By the way, you guys don't seem to carry those patches of yours in the
Collabora tree [1]? Nor the TSADC updates as far as I can tell.

[1] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/blob/rockchip-release/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts?ref_type=heads

Best regards,
Alexey

Re: [PATCH 2/4] arm64: dts: rockchip: enable USB A ports on ArmSoM Sige5

[Nicolas Frattaroli]

On Wednesday, 4 June 2025 08:52:51 Central European Summer Time Alexey Charkov wrote:
> On Tue, Jun 3, 2025 at 9:51 PM Nicolas Frattaroli
> <nicolas.frattaroli@collabora.com> wrote:
> >
> > On Tuesday, 3 June 2025 19:01:14 Central European Summer Time Alexey Charkov wrote:
> > > Enable the two USB type A ports (USB2 and USB3) present on the ArmSoM
> > > Sige5 board.
> > >
> > > Both ports use just one xHCI controller, with the USB 2.0 signals fed
> > > off the same USB OTG PHY through an onboard hub. VBUS of both ports is
> > > controlled by the same GPIO regulator (VCC_USBHOST in the schematics,
> > > toggled by GPIO4 RK_PA6).
> > >
> > > Signed-off-by: Alexey Charkov <alchark@gmail.com>
> > > ---
> > >  .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 38 ++++++++++++++++++++++
> > >  1 file changed, 38 insertions(+)
> > >
> >
> > This is already done here:
> >
> > https://lore.kernel.org/linux-rockchip/20250507-rk3576-sige5-usb-v3-4-89bf5a614ccf@collabora.com/
> 
> Oh cool! Sorry I missed that one. Your series is much more
> comprehensive, so this patch of mine can be dropped. Thanks for your
> work!
> 
> Would you mind chiming in on the other patches here, given your
> knowledge of the hardware?

I gave the others a brief look yesterday, I'll give a more in-depth look
and test today and send you my Tested-by and Reviewed-by.

> 
> By the way, you guys don't seem to carry those patches of yours in the
> Collabora tree [1]? Nor the TSADC updates as far as I can tell.
> 
> [1] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/blob/rockchip-release/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts?ref_type=heads
> 

Yeah, I just sent them upstream directly, since at this stage it wasn't a
SoC and board in wide enough circulation yet where a ready-to-use public
tree with all the in-flight patches made sense for the added chore of
rebasing things when new version of patch series get submitted imho.
Though since some of them have been languishing with no upstream response
for quite a while (*cough* TSADC *cough*) and some more RK3576 hardware,
notably the RADXA ROCK 4D, released in the meantime, it may make sense to
have them included in either our rockchip-release or rockchip-devel tree.

If you want to keep up to date on what's in flight, our RK3576 mainline
status matrix at https://col.la/rk3576status is usually kept fairly up to
date.

Hopefully once v6.16-rc1 drops, upstream maintainers/reviewers are in a
better position to take a look at some of those patch series again, I'll
resubmit them when the time comes. Nothing lights a fire like a RESEND
prefix in a series.

> Best regards,
> Alexey
> 

Kind regards,
Nicolas Frattaroli

Re: [PATCH 0/4] arm64: dts: rockchip: enable further peripherals on ArmSoM Sige5

[Rob Herring (Arm)]

On Tue, 03 Jun 2025 21:01:12 +0400, Alexey Charkov wrote:
> Add support for the two USB type A ports, link up the CPU regulators for
> DVFS, enable WiFi and Bluetooth.
> 
> The bluetooth part might warrant some discussion and thoughts from the
> list, given that it's connected over UART and thus not discoverable. At
> the same time, there are two revisions of the board which have different
> Bluetooth chips soldered on: Realtek based on v1.1 and Broadcom based on
> v1.2. I'm not sure if there is any way to determine board version from
> software. Mine is v1.2, so the respective patch deals with the Broadcom
> case only, but maybe it's better to move it into a .dtso and thus kick
> the can down the road (i.e. make the user deal with board identification
> and loading of the right overlay)? Thoughts welcome.
> 
> Best regards,
> Alexey
> 
> Signed-off-by: Alexey Charkov <alchark@gmail.com>
> ---
> Alexey Charkov (4):
>       arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5
>       arm64: dts: rockchip: enable USB A ports on ArmSoM Sige5
>       arm64: dts: rockchip: enable wifi on ArmSoM Sige5
>       arm64: dts: rockchip: enable bluetooth on ArmSoM Sige5
> 
>  .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 135 +++++++++++++++++++++
>  arch/arm64/boot/dts/rockchip/rk3576.dtsi           |  16 +++
>  2 files changed, 151 insertions(+)
> ---
> base-commit: 546b1c9e93c2bb8cf5ed24e0be1c86bb089b3253
> change-id: 20250602-sige5-updates-a162b501a1b1
> 
> Best regards,
> --
> Alexey Charkov <alchark@gmail.com>
> 
> 
> 


My bot found new DTB warnings on the .dts files added or changed in this
series.

Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
are fixed by another series. Ultimately, it is up to the platform
maintainer whether these warnings are acceptable or not. No need to reply
unless the platform maintainer has comments.

If you already ran DT checks and didn't see these error(s), then
make sure dt-schema is up to date:

  pip3 install dtschema --upgrade


This patch series was applied (using b4) to base:
 Base: using specified base-commit 546b1c9e93c2bb8cf5ed24e0be1c86bb089b3253

If this is not the correct base, please add 'base-commit' tag
(or use b4 which does this automatically)

New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/rockchip/' for 20250603-sige5-updates-v1-0-717e8ce4ab77@gmail.com:

arch/arm64/boot/dts/rockchip/rk3576-roc-pc.dtb: mmc@2a320000 (rockchip,rk3576-dw-mshc): compatible: 'oneOf' conditional failed, one must be fixed:
	['rockchip,rk3576-dw-mshc', 'rockchip,rk3288-dw-mshc'] is too long
	'rockchip,rk2928-dw-mshc' was expected
	'rockchip,rk3288-dw-mshc' was expected
	'rockchip,rk3576-dw-mshc' is not one of ['rockchip,px30-dw-mshc', 'rockchip,rk1808-dw-mshc', 'rockchip,rk3036-dw-mshc', 'rockchip,rk3128-dw-mshc', 'rockchip,rk3228-dw-mshc', 'rockchip,rk3308-dw-mshc', 'rockchip,rk3328-dw-mshc', 'rockchip,rk3368-dw-mshc', 'rockchip,rk3399-dw-mshc', 'rockchip,rk3528-dw-mshc', 'rockchip,rk3562-dw-mshc', 'rockchip,rk3568-dw-mshc', 'rockchip,rk3588-dw-mshc', 'rockchip,rv1108-dw-mshc', 'rockchip,rv1126-dw-mshc']
	from schema $id: http://devicetree.org/schemas/mmc/rockchip-dw-mshc.yaml#
arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dtb: mmc@2a320000 (rockchip,rk3576-dw-mshc): compatible: 'oneOf' conditional failed, one must be fixed:
	['rockchip,rk3576-dw-mshc', 'rockchip,rk3288-dw-mshc'] is too long
	'rockchip,rk2928-dw-mshc' was expected
	'rockchip,rk3288-dw-mshc' was expected
	'rockchip,rk3576-dw-mshc' is not one of ['rockchip,px30-dw-mshc', 'rockchip,rk1808-dw-mshc', 'rockchip,rk3036-dw-mshc', 'rockchip,rk3128-dw-mshc', 'rockchip,rk3228-dw-mshc', 'rockchip,rk3308-dw-mshc', 'rockchip,rk3328-dw-mshc', 'rockchip,rk3368-dw-mshc', 'rockchip,rk3399-dw-mshc', 'rockchip,rk3528-dw-mshc', 'rockchip,rk3562-dw-mshc', 'rockchip,rk3568-dw-mshc', 'rockchip,rk3588-dw-mshc', 'rockchip,rv1108-dw-mshc', 'rockchip,rv1126-dw-mshc']
	from schema $id: http://devicetree.org/schemas/mmc/rockchip-dw-mshc.yaml#
arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dtb: mmc@2a320000 (rockchip,rk3576-dw-mshc): Unevaluated properties are not allowed ('compatible' was unexpected)
	from schema $id: http://devicetree.org/schemas/mmc/rockchip-dw-mshc.yaml#
arch/arm64/boot/dts/rockchip/rk3576-evb1-v10.dtb: mmc@2a320000 (rockchip,rk3576-dw-mshc): compatible: 'oneOf' conditional failed, one must be fixed:
	['rockchip,rk3576-dw-mshc', 'rockchip,rk3288-dw-mshc'] is too long
	'rockchip,rk2928-dw-mshc' was expected
	'rockchip,rk3288-dw-mshc' was expected
	'rockchip,rk3576-dw-mshc' is not one of ['rockchip,px30-dw-mshc', 'rockchip,rk1808-dw-mshc', 'rockchip,rk3036-dw-mshc', 'rockchip,rk3128-dw-mshc', 'rockchip,rk3228-dw-mshc', 'rockchip,rk3308-dw-mshc', 'rockchip,rk3328-dw-mshc', 'rockchip,rk3368-dw-mshc', 'rockchip,rk3399-dw-mshc', 'rockchip,rk3528-dw-mshc', 'rockchip,rk3562-dw-mshc', 'rockchip,rk3568-dw-mshc', 'rockchip,rk3588-dw-mshc', 'rockchip,rv1108-dw-mshc', 'rockchip,rv1126-dw-mshc']
	from schema $id: http://devicetree.org/schemas/mmc/rockchip-dw-mshc.yaml#
arch/arm64/boot/dts/rockchip/rk3576-rock-4d.dtb: mmc@2a320000 (rockchip,rk3576-dw-mshc): compatible: 'oneOf' conditional failed, one must be fixed:
	['rockchip,rk3576-dw-mshc', 'rockchip,rk3288-dw-mshc'] is too long
	'rockchip,rk2928-dw-mshc' was expected
	'rockchip,rk3288-dw-mshc' was expected
	'rockchip,rk3576-dw-mshc' is not one of ['rockchip,px30-dw-mshc', 'rockchip,rk1808-dw-mshc', 'rockchip,rk3036-dw-mshc', 'rockchip,rk3128-dw-mshc', 'rockchip,rk3228-dw-mshc', 'rockchip,rk3308-dw-mshc', 'rockchip,rk3328-dw-mshc', 'rockchip,rk3368-dw-mshc', 'rockchip,rk3399-dw-mshc', 'rockchip,rk3528-dw-mshc', 'rockchip,rk3562-dw-mshc', 'rockchip,rk3568-dw-mshc', 'rockchip,rk3588-dw-mshc', 'rockchip,rv1108-dw-mshc', 'rockchip,rv1126-dw-mshc']
	from schema $id: http://devicetree.org/schemas/mmc/rockchip-dw-mshc.yaml#

Re: [PATCH 0/4] arm64: dts: rockchip: enable further peripherals on ArmSoM Sige5

[Alexey Charkov]

On Wed, Jun 4, 2025 at 5:58 PM Rob Herring (Arm) <robh@kernel.org> wrote:
>
>
> On Tue, 03 Jun 2025 21:01:12 +0400, Alexey Charkov wrote:
> > Add support for the two USB type A ports, link up the CPU regulators for
> > DVFS, enable WiFi and Bluetooth.
> >
> > The bluetooth part might warrant some discussion and thoughts from the
> > list, given that it's connected over UART and thus not discoverable. At
> > the same time, there are two revisions of the board which have different
> > Bluetooth chips soldered on: Realtek based on v1.1 and Broadcom based on
> > v1.2. I'm not sure if there is any way to determine board version from
> > software. Mine is v1.2, so the respective patch deals with the Broadcom
> > case only, but maybe it's better to move it into a .dtso and thus kick
> > the can down the road (i.e. make the user deal with board identification
> > and loading of the right overlay)? Thoughts welcome.
> >
> > Best regards,
> > Alexey
> >
> > Signed-off-by: Alexey Charkov <alchark@gmail.com>
> > ---
> > Alexey Charkov (4):
> >       arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5
> >       arm64: dts: rockchip: enable USB A ports on ArmSoM Sige5
> >       arm64: dts: rockchip: enable wifi on ArmSoM Sige5
> >       arm64: dts: rockchip: enable bluetooth on ArmSoM Sige5
> >
> >  .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 135 +++++++++++++++++++++
> >  arch/arm64/boot/dts/rockchip/rk3576.dtsi           |  16 +++
> >  2 files changed, 151 insertions(+)
> > ---
> > base-commit: 546b1c9e93c2bb8cf5ed24e0be1c86bb089b3253
> > change-id: 20250602-sige5-updates-a162b501a1b1
> >
> > Best regards,
> > --
> > Alexey Charkov <alchark@gmail.com>
> >
> >
> >
>
>
> My bot found new DTB warnings on the .dts files added or changed in this
> series.
>
> Some warnings may be from an existing SoC .dtsi. Or perhaps the warnings
> are fixed by another series. Ultimately, it is up to the platform
> maintainer whether these warnings are acceptable or not. No need to reply
> unless the platform maintainer has comments.
>
> If you already ran DT checks and didn't see these error(s), then
> make sure dt-schema is up to date:
>
>   pip3 install dtschema --upgrade
>
>
> This patch series was applied (using b4) to base:
>  Base: using specified base-commit 546b1c9e93c2bb8cf5ed24e0be1c86bb089b3253
>
> If this is not the correct base, please add 'base-commit' tag
> (or use b4 which does this automatically)
>
> New warnings running 'make CHECK_DTBS=y for arch/arm64/boot/dts/rockchip/' for 20250603-sige5-updates-v1-0-717e8ce4ab77@gmail.com:
>
> arch/arm64/boot/dts/rockchip/rk3576-roc-pc.dtb: mmc@2a320000 (rockchip,rk3576-dw-mshc): compatible: 'oneOf' conditional failed, one must be fixed:
>         ['rockchip,rk3576-dw-mshc', 'rockchip,rk3288-dw-mshc'] is too long
>         'rockchip,rk2928-dw-mshc' was expected
>         'rockchip,rk3288-dw-mshc' was expected
>         'rockchip,rk3576-dw-mshc' is not one of ['rockchip,px30-dw-mshc', 'rockchip,rk1808-dw-mshc', 'rockchip,rk3036-dw-mshc', 'rockchip,rk3128-dw-mshc', 'rockchip,rk3228-dw-mshc', 'rockchip,rk3308-dw-mshc', 'rockchip,rk3328-dw-mshc', 'rockchip,rk3368-dw-mshc', 'rockchip,rk3399-dw-mshc', 'rockchip,rk3528-dw-mshc', 'rockchip,rk3562-dw-mshc', 'rockchip,rk3568-dw-mshc', 'rockchip,rk3588-dw-mshc', 'rockchip,rv1108-dw-mshc', 'rockchip,rv1126-dw-mshc']
>         from schema $id: http://devicetree.org/schemas/mmc/rockchip-dw-mshc.yaml#
> arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dtb: mmc@2a320000 (rockchip,rk3576-dw-mshc): compatible: 'oneOf' conditional failed, one must be fixed:
>         ['rockchip,rk3576-dw-mshc', 'rockchip,rk3288-dw-mshc'] is too long

Should be just rockchip,rk3576-dw-mshc.

Thanks bot, and sorry for the noise - missed this one.

Best regards,
Alexey

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Nicolas Frattaroli]

On Tuesday, 3 June 2025 19:01:13 Central European Summer Time Alexey Charkov wrote:
> List both CPU supply regulators which drive the little and big CPU
> clusters, respectively, so that cpufreq can pick them up.
> 
> Signed-off-by: Alexey Charkov <alchark@gmail.com>
> ---
>  .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 28 ++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> index b09e789c75c47fec7cf7e9810ab0dcca32d9404a..d9c129be55a0d997e04e6d677cdc98fb50353418 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> @@ -207,6 +207,22 @@ vcc_3v3_ufs_s0: regulator-vcc-ufs-s0 {
>  	};
>  };
>  
> +&cpu_b0 {
> +	cpu-supply = <&vdd_cpu_big_s0>;
> +};
> +
> +&cpu_b1 {
> +	cpu-supply = <&vdd_cpu_big_s0>;
> +};
> +
> +&cpu_b2 {
> +	cpu-supply = <&vdd_cpu_big_s0>;
> +};
> +
> +&cpu_b3 {
> +	cpu-supply = <&vdd_cpu_big_s0>;
> +};
> +
>  &combphy0_ps {
>  	status = "okay";
>  };
> @@ -215,6 +231,18 @@ &cpu_l0 {
>  	cpu-supply = <&vdd_cpu_lit_s0>;
>  };
>  
> +&cpu_l1 {
> +	cpu-supply = <&vdd_cpu_lit_s0>;
> +};
> +
> +&cpu_l2 {
> +	cpu-supply = <&vdd_cpu_lit_s0>;
> +};
> +
> +&cpu_l3 {
> +	cpu-supply = <&vdd_cpu_lit_s0>;
> +};
> +
>  &gmac0 {
>  	phy-mode = "rgmii-id";
>  	clock_in_out = "output";
> 
> 

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

> so that cpufreq can pick them up.

Fwiw, even without this patch they're picked up by cpufreq-dt for me:

    user@trixie:~$ sudo cpupower frequency-info 
      analyzing CPU 5:
      driver: cpufreq-dt
      CPUs which run at the same hardware frequency: 4 5 6 7
      CPUs which need to have their frequency coordinated by software: 4 5 6 7
      maximum transition latency: 40.0 us
      hardware limits: 408 MHz - 2.30 GHz
      available frequency steps:  408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz, 1.61 GHz, 1.80 GHz, 2.02 GHz, 2.21 GHz, 2.30 GHz
      available cpufreq governors: ondemand userspace performance schedutil
      current policy: frequency should be within 408 MHz and 2.30 GHz.
                      The governor "schedutil" may decide which speed to use
                      within this range.
      current CPU frequency: 1.61 GHz (asserted by call to hardware)
    user@trixie:~$ uname -a
    Linux trixie 6.15.0-11173-g546b1c9e93c2 #2 SMP PREEMPT Wed Jun  4 20:32:52 CEST 2025 aarch64 GNU/Linux

this is more correct though of course.

Kind regards,
Nicolas Frattaroli

Re: [PATCH 3/4] arm64: dts: rockchip: enable wifi on ArmSoM Sige5

[Nicolas Frattaroli]

On Tuesday, 3 June 2025 19:01:15 Central European Summer Time Alexey Charkov wrote:
> ArmSoM Sige5 uses a soldered-on SDIO connected WiFi module. Namely,
> board v1.1 uses a Realtek based BL-M8852BS2, while v1.2 uses a Broadcom
> based BW3752-50B1.

Okay, so there's two board revisions, which makes this patch and the
following that adds bluetooth a problem. This patch here doesn't
seem to actually add the SDIO Wi-Fi module node where it'll differ,
so skirts around the issue AFAIU. It might also be that it's not
needed for you and I just don't notice because I have v1.1 where the
SDIO driver for that module doesn't exist yet iirc.

But what we should think about is first doing
- probably add a new compatible for armsom,sige5-v1.2
- git mv arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts \
         arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dtsi
- commit here like Sebastian Reichel had to do for [1]
- create a new arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
  that includes the dtsi and moves the model and compatible property
  there. Make sure the model includes v1.1 in the name, compatible
  should remain the same
- commit here that will be a squash commit like Sebastian Reichel
  had to do in [2]
- create a new arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5-v1.2.dts,
  could be adding the Wi-Fi node here to cut down on how many patches we
  do. I assume you only have the v1.2 board and can't test the older Wi-Fi,
  which is fine.
  compatible should probably be something like
    compatible = "armsom,sige5-v1.2", "armsom,sige5", "rockchip,rk3576";
  Don't forget to change the model property as well.

I know this will be a royal PITA, especially considering they'll likely
never produce v1.1 again and it now hogs the name, but keeping the
current dts as 1.1 may be the best way forward, as it keeps compat (though
the Wi-Fi changes won't affect anything already in there) and will stop
people from accidentally picking the higher number better DTS like what
happens with rockpro64 all the time where the non-numbered DTS is 2.1 and
the numbered one is 2.0 and people keep picking 2.0.

> 
> Add required device tree nodes in the SoC .dtsi for the SDIO controller
> and pinctrl / clock wiring in the board .dts for the module itself.
> 
> Signed-off-by: Alexey Charkov <alchark@gmail.com>
> ---
>  .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 36 ++++++++++++++++++++++
>  arch/arm64/boot/dts/rockchip/rk3576.dtsi           | 16 ++++++++++
>  2 files changed, 52 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> index 7ce1fb1380b0863c902fdd9cbc7454ee6011cf92..dcd033859398312f7693bebb7f080ee4f2ecaa32 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> @@ -219,6 +219,15 @@ vcc_5v0_host: regulator-vcc-5v0-host {
>  		pinctrl-names = "default";
>  		pinctrl-0 = <&usb_host_pwren>;
>  	};
> +
> +	sdio_pwrseq: sdio-pwrseq {
> +		compatible = "mmc-pwrseq-simple";
> +		clocks = <&hym8563>;
> +		clock-names = "ext_clock";
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&wifi_reg_on>;
> +		reset-gpios = <&gpio1 RK_PC6 GPIO_ACTIVE_LOW>;
> +	};
>  };
>  
>  &combphy1_psu {
> @@ -781,6 +790,16 @@ usb_host_pwren: usb-host-pwren {
>  			rockchip,pins = <4 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
>  		};
>  	};
> +
> +	wireless-wlan {
> +		wifi_wake_host: wifi-wake-host {
> +			rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_down>;
> +		};
> +
> +		wifi_reg_on: wifi-reg-on {
> +			rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> +		};
> +	};
>  };
>  
>  &sai1 {
> @@ -808,6 +827,23 @@ &sdhci {
>  	status = "okay";
>  };
>  
> +&sdio {
> +	bus-width = <4>;
> +	cap-sdio-irq;
> +	disable-wp;
> +	keep-power-in-suspend;
> +	mmc-pwrseq = <&sdio_pwrseq>;
> +	no-sd;
> +	no-mmc;
> +	non-removable;
> +	sd-uhs-sdr50;
> +	sd-uhs-sdr104;
> +	vmmc-supply = <&vcc_3v3_s3>;
> +	vqmmc-supply = <&vcc_1v8_s3>;
> +	wakeup-source;
> +	status = "okay";
> +};
> +
>  &sdmmc {
>  	bus-width = <4>;
>  	cap-mmc-highspeed;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576.dtsi

Okay, I think adding the sdio node to the SoC dtsi should be a separate
patch before this one.

> index 1086482f04792325dc4c22fb8ceeb27eef59afe4..a09582470bb7f654b711308da1e51fa8571ca1e8 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
> @@ -1695,6 +1695,22 @@ sdmmc: mmc@2a310000 {
>  			status = "disabled";
>  		};
>  
> +		sdio: mmc@2a320000 {
> +			compatible = "rockchip,rk3576-dw-mshc", "rockchip,rk3288-dw-mshc";
> +			reg = <0x0 0x2a320000 0x0 0x4000>;
> +			clocks = <&cru HCLK_SDIO>, <&cru CCLK_SRC_SDIO>;
> +			clock-names = "biu", "ciu";
> +			fifo-depth = <0x100>;
> +			interrupts = <GIC_SPI 252 IRQ_TYPE_LEVEL_HIGH>;
> +			max-frequency = <200000000>;
> +			pinctrl-0 = <&sdmmc1m0_clk &sdmmc1m0_cmd &sdmmc1m0_bus4>;
> +			pinctrl-names = "default";
> +			power-domains = <&power RK3576_PD_SDGMAC>;
> +			resets = <&cru SRST_H_SDIO>;
> +			reset-names = "reset";
> +			status = "disabled";
> +		};
> +
>  		sdhci: mmc@2a330000 {
>  			compatible = "rockchip,rk3576-dwcmshc", "rockchip,rk3588-dwcmshc";
>  			reg = <0x0 0x2a330000 0x0 0x10000>;
> 
>

So in conclusion:
- bindings patch adding v1.2 compatible
- SoC dtsi patch for the sdio node
- git mv patch
- rk3576-armsom-sige5.dts patch, ask maintainer to squash it into the
  previous patch, make it obvious by giving it the same subject or something
- rk3576-armsom-sige5-v1.2.dts patch

Sorry to drop all this on you, it's a little unpleasant and in-the-woods
with regards to preparing a patch series. Basically, the reason why I've
held off on this for the moment is that I don't have a v1.2 board and my
v1.1 board's Wi-Fi module doesn't seem to be supported (yet).

Kind regards,
Nicolas Frattaroli

[1]: https://lore.kernel.org/linux-rockchip/20250508-rock5bp-for-upstream-v2-1-677033cc1ac2@kernel.org/
[2]: https://lore.kernel.org/linux-rockchip/20250508-rock5bp-for-upstream-v2-2-677033cc1ac2@kernel.org/

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Alexey Charkov]

On Wed, Jun 4, 2025 at 10:38 PM Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
>
> On Tuesday, 3 June 2025 19:01:13 Central European Summer Time Alexey Charkov wrote:
> > List both CPU supply regulators which drive the little and big CPU
> > clusters, respectively, so that cpufreq can pick them up.
> >
> > Signed-off-by: Alexey Charkov <alchark@gmail.com>
> > ---
> >  .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 28 ++++++++++++++++++++++
> >  1 file changed, 28 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> > index b09e789c75c47fec7cf7e9810ab0dcca32d9404a..d9c129be55a0d997e04e6d677cdc98fb50353418 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> > @@ -207,6 +207,22 @@ vcc_3v3_ufs_s0: regulator-vcc-ufs-s0 {
> >       };
> >  };
> >
> > +&cpu_b0 {
> > +     cpu-supply = <&vdd_cpu_big_s0>;
> > +};
> > +
> > +&cpu_b1 {
> > +     cpu-supply = <&vdd_cpu_big_s0>;
> > +};
> > +
> > +&cpu_b2 {
> > +     cpu-supply = <&vdd_cpu_big_s0>;
> > +};
> > +
> > +&cpu_b3 {
> > +     cpu-supply = <&vdd_cpu_big_s0>;
> > +};
> > +
> >  &combphy0_ps {
> >       status = "okay";
> >  };
> > @@ -215,6 +231,18 @@ &cpu_l0 {
> >       cpu-supply = <&vdd_cpu_lit_s0>;
> >  };
> >
> > +&cpu_l1 {
> > +     cpu-supply = <&vdd_cpu_lit_s0>;
> > +};
> > +
> > +&cpu_l2 {
> > +     cpu-supply = <&vdd_cpu_lit_s0>;
> > +};
> > +
> > +&cpu_l3 {
> > +     cpu-supply = <&vdd_cpu_lit_s0>;
> > +};
> > +
> >  &gmac0 {
> >       phy-mode = "rgmii-id";
> >       clock_in_out = "output";
> >
> >
>
> Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
>
> > so that cpufreq can pick them up.
>
> Fwiw, even without this patch they're picked up by cpufreq-dt for me:
>
>     user@trixie:~$ sudo cpupower frequency-info
>       analyzing CPU 5:
>       driver: cpufreq-dt
>       CPUs which run at the same hardware frequency: 4 5 6 7
>       CPUs which need to have their frequency coordinated by software: 4 5 6 7
>       maximum transition latency: 40.0 us
>       hardware limits: 408 MHz - 2.30 GHz
>       available frequency steps:  408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz, 1.61 GHz, 1.80 GHz, 2.02 GHz, 2.21 GHz, 2.30 GHz
>       available cpufreq governors: ondemand userspace performance schedutil
>       current policy: frequency should be within 408 MHz and 2.30 GHz.
>                       The governor "schedutil" may decide which speed to use
>                       within this range.
>       current CPU frequency: 1.61 GHz (asserted by call to hardware)
>     user@trixie:~$ uname -a
>     Linux trixie 6.15.0-11173-g546b1c9e93c2 #2 SMP PREEMPT Wed Jun  4 20:32:52 CEST 2025 aarch64 GNU/Linux

Frequencies are fine, but I don't think the more power hungry big CPU
cluster gets any voltage scaling without it. Once I try to load the
system enough that the governor decides to bump the big cluster
frequency up, the regulator stays at 850000 microvolts, causing random
reboots when the whole cluster starts starving. With the patch,
voltage oscillates between 700000-737000 microvolts in idle and jumps
up to 950000 under load, and the system seems stable.

Here's what I used to monitor the voltage (there must be a better way
to do it, but it works):
sige5 ~ # watch cat `grep -r . /sys/class/regulator/*/name | grep
vdd_cpu_big_s0 | sed -e 's/name.*//'`/microvolts

And in another terminal:
sige5 ~ # stress-ng -c8

This might warrant a note in the commit message I guess :)

Thanks for your review and testing!

Best regards,
Alexey

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Nicolas Frattaroli]

On Wednesday, 4 June 2025 21:12:35 Central European Summer Time Alexey Charkov wrote:
> On Wed, Jun 4, 2025 at 10:38 PM Nicolas Frattaroli
> <nicolas.frattaroli@collabora.com> wrote:
> >
> > On Tuesday, 3 June 2025 19:01:13 Central European Summer Time Alexey Charkov wrote:
> > > List both CPU supply regulators which drive the little and big CPU
> > > clusters, respectively, so that cpufreq can pick them up.
> > >
> > > Signed-off-by: Alexey Charkov <alchark@gmail.com>
> > > ---
> > >  .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 28 ++++++++++++++++++++++
> > >  1 file changed, 28 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> > > index b09e789c75c47fec7cf7e9810ab0dcca32d9404a..d9c129be55a0d997e04e6d677cdc98fb50353418 100644
> > > --- a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> > > +++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> > > @@ -207,6 +207,22 @@ vcc_3v3_ufs_s0: regulator-vcc-ufs-s0 {
> > >       };
> > >  };
> > >
> > > +&cpu_b0 {
> > > +     cpu-supply = <&vdd_cpu_big_s0>;
> > > +};
> > > +
> > > +&cpu_b1 {
> > > +     cpu-supply = <&vdd_cpu_big_s0>;
> > > +};
> > > +
> > > +&cpu_b2 {
> > > +     cpu-supply = <&vdd_cpu_big_s0>;
> > > +};
> > > +
> > > +&cpu_b3 {
> > > +     cpu-supply = <&vdd_cpu_big_s0>;
> > > +};
> > > +
> > >  &combphy0_ps {
> > >       status = "okay";
> > >  };
> > > @@ -215,6 +231,18 @@ &cpu_l0 {
> > >       cpu-supply = <&vdd_cpu_lit_s0>;
> > >  };
> > >
> > > +&cpu_l1 {
> > > +     cpu-supply = <&vdd_cpu_lit_s0>;
> > > +};
> > > +
> > > +&cpu_l2 {
> > > +     cpu-supply = <&vdd_cpu_lit_s0>;
> > > +};
> > > +
> > > +&cpu_l3 {
> > > +     cpu-supply = <&vdd_cpu_lit_s0>;
> > > +};
> > > +
> > >  &gmac0 {
> > >       phy-mode = "rgmii-id";
> > >       clock_in_out = "output";
> > >
> > >
> >
> > Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> >
> > > so that cpufreq can pick them up.
> >
> > Fwiw, even without this patch they're picked up by cpufreq-dt for me:
> >
> >     user@trixie:~$ sudo cpupower frequency-info
> >       analyzing CPU 5:
> >       driver: cpufreq-dt
> >       CPUs which run at the same hardware frequency: 4 5 6 7
> >       CPUs which need to have their frequency coordinated by software: 4 5 6 7
> >       maximum transition latency: 40.0 us
> >       hardware limits: 408 MHz - 2.30 GHz
> >       available frequency steps:  408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz, 1.61 GHz, 1.80 GHz, 2.02 GHz, 2.21 GHz, 2.30 GHz
> >       available cpufreq governors: ondemand userspace performance schedutil
> >       current policy: frequency should be within 408 MHz and 2.30 GHz.
> >                       The governor "schedutil" may decide which speed to use
> >                       within this range.
> >       current CPU frequency: 1.61 GHz (asserted by call to hardware)
> >     user@trixie:~$ uname -a
> >     Linux trixie 6.15.0-11173-g546b1c9e93c2 #2 SMP PREEMPT Wed Jun  4 20:32:52 CEST 2025 aarch64 GNU/Linux
> 
> Frequencies are fine, but I don't think the more power hungry big CPU
> cluster gets any voltage scaling without it. Once I try to load the
> system enough that the governor decides to bump the big cluster
> frequency up, the regulator stays at 850000 microvolts, causing random
> reboots when the whole cluster starts starving. With the patch,
> voltage oscillates between 700000-737000 microvolts in idle and jumps
> up to 950000 under load, and the system seems stable.

Okay, that sounds pretty serious and in this case you should add the
following tag at the end of the commit message, usually as the first
thing after the line break:

  Fixes: 40f742b07ab2 ("arm64: dts: rockchip: Add rk3576-armsom-sige5 board")

That way, our stable kernel robot overlords will pick it up and
backport it to the kernels that already contain the mentioned commit.

> 
> Here's what I used to monitor the voltage (there must be a better way
> to do it, but it works):
> sige5 ~ # watch cat `grep -r . /sys/class/regulator/*/name | grep
> vdd_cpu_big_s0 | sed -e 's/name.*//'`/microvolts
> 
> And in another terminal:
> sige5 ~ # stress-ng -c8
> 
> This might warrant a note in the commit message I guess :)

Yes, definitely mention stuff like this in the commit message.

> 
> Thanks for your review and testing!
> 
> Best regards,
> Alexey
> 

Kind regards,
Nicolas Frattaroli

Re: [PATCH 3/4] arm64: dts: rockchip: enable wifi on ArmSoM Sige5

[Alexey Charkov]

On Wed, Jun 4, 2025 at 11:01 PM Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
>
> On Tuesday, 3 June 2025 19:01:15 Central European Summer Time Alexey Charkov wrote:
> > ArmSoM Sige5 uses a soldered-on SDIO connected WiFi module. Namely,
> > board v1.1 uses a Realtek based BL-M8852BS2, while v1.2 uses a Broadcom
> > based BW3752-50B1.
>
> Okay, so there's two board revisions, which makes this patch and the
> following that adds bluetooth a problem. This patch here doesn't
> seem to actually add the SDIO Wi-Fi module node where it'll differ,
> so skirts around the issue AFAIU. It might also be that it's not
> needed for you and I just don't notice because I have v1.1 where the
> SDIO driver for that module doesn't exist yet iirc.

The WiFi module actually probes just fine without explicitly listing
it in the device tree, because SDIO is enumerable (unlike
UART/serdev). Pin configs and the lpo clock are pulled in by the
mmc-pwrseq part, and with that it just works as long as the drivers
are in place (which is the case with the Broadcom module, but perhaps
not yet with the Realtek one).

I haven't tested the wake-host functionality, given that there is no
suspend support anyway (no Rockchip SiP communication support in
mainline, and nothing to ask ATF to suspend the main CPU like
downstream rockchip_pm_config.c does). Guess it doesn't work, because
nothing binds the respective GPIO to the WiFi driver right now. But I
do get a WiFi connection without it.

> But what we should think about is first doing
> - probably add a new compatible for armsom,sige5-v1.2
> - git mv arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts \
>          arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dtsi
> - commit here like Sebastian Reichel had to do for [1]
> - create a new arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
>   that includes the dtsi and moves the model and compatible property
>   there. Make sure the model includes v1.1 in the name, compatible
>   should remain the same
> - commit here that will be a squash commit like Sebastian Reichel
>   had to do in [2]

I believe another way to do this is with --break-rewrites, as Dragan did in [1]

[1] https://lore.kernel.org/all/9ffedc0e2ca7f167d9d795b2a8f43cb9f56a653b.1717923308.git.dsimic@manjaro.org/

> - create a new arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5-v1.2.dts,
>   could be adding the Wi-Fi node here to cut down on how many patches we
>   do. I assume you only have the v1.2 board and can't test the older Wi-Fi,
>   which is fine.
>   compatible should probably be something like
>     compatible = "armsom,sige5-v1.2", "armsom,sige5", "rockchip,rk3576";
>   Don't forget to change the model property as well.

Given that the user would have to manually feed an appropriate DTB for
their board to the bootloader, and given that the WiFi/BT module used
is the only difference between v1.1 vs. v1.2, this doesn't seem to be
much easier for users vs. applying a DTBO... But more churn in the
kernel just for that bluetooth function. With a DTBO we could keep the
same compatible and just move the Bluetooth node into an overlay.

Happy to go either way. Wonder what Heiko prefers?

> I know this will be a royal PITA, especially considering they'll likely
> never produce v1.1 again and it now hogs the name, but keeping the
> current dts as 1.1 may be the best way forward, as it keeps compat (though
> the Wi-Fi changes won't affect anything already in there) and will stop
> people from accidentally picking the higher number better DTS like what
> happens with rockpro64 all the time where the non-numbered DTS is 2.1 and
> the numbered one is 2.0 and people keep picking 2.0.

Quite a PITA indeed :)

> > Add required device tree nodes in the SoC .dtsi for the SDIO controller
> > and pinctrl / clock wiring in the board .dts for the module itself.
> >
> > Signed-off-by: Alexey Charkov <alchark@gmail.com>
> > ---
> >  .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 36 ++++++++++++++++++++++
> >  arch/arm64/boot/dts/rockchip/rk3576.dtsi           | 16 ++++++++++
> >  2 files changed, 52 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> > index 7ce1fb1380b0863c902fdd9cbc7454ee6011cf92..dcd033859398312f7693bebb7f080ee4f2ecaa32 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> > @@ -219,6 +219,15 @@ vcc_5v0_host: regulator-vcc-5v0-host {
> >               pinctrl-names = "default";
> >               pinctrl-0 = <&usb_host_pwren>;
> >       };
> > +
> > +     sdio_pwrseq: sdio-pwrseq {
> > +             compatible = "mmc-pwrseq-simple";
> > +             clocks = <&hym8563>;
> > +             clock-names = "ext_clock";
> > +             pinctrl-names = "default";
> > +             pinctrl-0 = <&wifi_reg_on>;
> > +             reset-gpios = <&gpio1 RK_PC6 GPIO_ACTIVE_LOW>;
> > +     };
> >  };
> >
> >  &combphy1_psu {
> > @@ -781,6 +790,16 @@ usb_host_pwren: usb-host-pwren {
> >                       rockchip,pins = <4 RK_PA4 RK_FUNC_GPIO &pcfg_pull_none>;
> >               };
> >       };
> > +
> > +     wireless-wlan {
> > +             wifi_wake_host: wifi-wake-host {
> > +                     rockchip,pins = <0 RK_PB0 RK_FUNC_GPIO &pcfg_pull_down>;
> > +             };
> > +
> > +             wifi_reg_on: wifi-reg-on {
> > +                     rockchip,pins = <1 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> > +             };
> > +     };
> >  };
> >
> >  &sai1 {
> > @@ -808,6 +827,23 @@ &sdhci {
> >       status = "okay";
> >  };
> >
> > +&sdio {
> > +     bus-width = <4>;
> > +     cap-sdio-irq;
> > +     disable-wp;
> > +     keep-power-in-suspend;
> > +     mmc-pwrseq = <&sdio_pwrseq>;
> > +     no-sd;
> > +     no-mmc;
> > +     non-removable;
> > +     sd-uhs-sdr50;
> > +     sd-uhs-sdr104;
> > +     vmmc-supply = <&vcc_3v3_s3>;
> > +     vqmmc-supply = <&vcc_1v8_s3>;
> > +     wakeup-source;
> > +     status = "okay";
> > +};
> > +
> >  &sdmmc {
> >       bus-width = <4>;
> >       cap-mmc-highspeed;
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3576.dtsi b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
>
> Okay, I think adding the sdio node to the SoC dtsi should be a separate
> patch before this one.

Fair enough, will split it out, thanks!

> > index 1086482f04792325dc4c22fb8ceeb27eef59afe4..a09582470bb7f654b711308da1e51fa8571ca1e8 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3576.dtsi
> > +++ b/arch/arm64/boot/dts/rockchip/rk3576.dtsi
> > @@ -1695,6 +1695,22 @@ sdmmc: mmc@2a310000 {
> >                       status = "disabled";
> >               };
> >
> > +             sdio: mmc@2a320000 {
> > +                     compatible = "rockchip,rk3576-dw-mshc", "rockchip,rk3288-dw-mshc";
> > +                     reg = <0x0 0x2a320000 0x0 0x4000>;
> > +                     clocks = <&cru HCLK_SDIO>, <&cru CCLK_SRC_SDIO>;
> > +                     clock-names = "biu", "ciu";
> > +                     fifo-depth = <0x100>;
> > +                     interrupts = <GIC_SPI 252 IRQ_TYPE_LEVEL_HIGH>;
> > +                     max-frequency = <200000000>;
> > +                     pinctrl-0 = <&sdmmc1m0_clk &sdmmc1m0_cmd &sdmmc1m0_bus4>;
> > +                     pinctrl-names = "default";
> > +                     power-domains = <&power RK3576_PD_SDGMAC>;
> > +                     resets = <&cru SRST_H_SDIO>;
> > +                     reset-names = "reset";
> > +                     status = "disabled";
> > +             };
> > +
> >               sdhci: mmc@2a330000 {
> >                       compatible = "rockchip,rk3576-dwcmshc", "rockchip,rk3588-dwcmshc";
> >                       reg = <0x0 0x2a330000 0x0 0x10000>;
> >
> >
>
> So in conclusion:
> - bindings patch adding v1.2 compatible
> - SoC dtsi patch for the sdio node
> - git mv patch
> - rk3576-armsom-sige5.dts patch, ask maintainer to squash it into the
>   previous patch, make it obvious by giving it the same subject or something
> - rk3576-armsom-sige5-v1.2.dts patch
>
> Sorry to drop all this on you, it's a little unpleasant and in-the-woods
> with regards to preparing a patch series. Basically, the reason why I've
> held off on this for the moment is that I don't have a v1.2 board and my
> v1.1 board's Wi-Fi module doesn't seem to be supported (yet).

No worries, thanks for delving into all this stuff with me - much appreciated!

Best regards,
Alexey

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Alexey Charkov]

On Wed, Jun 4, 2025 at 11:23 PM Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
>
> On Wednesday, 4 June 2025 21:12:35 Central European Summer Time Alexey Charkov wrote:
> > On Wed, Jun 4, 2025 at 10:38 PM Nicolas Frattaroli
> > <nicolas.frattaroli@collabora.com> wrote:
> > >
> > > On Tuesday, 3 June 2025 19:01:13 Central European Summer Time Alexey Charkov wrote:
> > > > List both CPU supply regulators which drive the little and big CPU
> > > > clusters, respectively, so that cpufreq can pick them up.
> > > >
> > > > Signed-off-by: Alexey Charkov <alchark@gmail.com>
> > > > ---
> > > >  .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 28 ++++++++++++++++++++++
> > > >  1 file changed, 28 insertions(+)
> > > >
> > > > diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> > > > index b09e789c75c47fec7cf7e9810ab0dcca32d9404a..d9c129be55a0d997e04e6d677cdc98fb50353418 100644
> > > > --- a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> > > > +++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> > > > @@ -207,6 +207,22 @@ vcc_3v3_ufs_s0: regulator-vcc-ufs-s0 {
> > > >       };
> > > >  };
> > > >
> > > > +&cpu_b0 {
> > > > +     cpu-supply = <&vdd_cpu_big_s0>;
> > > > +};
> > > > +
> > > > +&cpu_b1 {
> > > > +     cpu-supply = <&vdd_cpu_big_s0>;
> > > > +};
> > > > +
> > > > +&cpu_b2 {
> > > > +     cpu-supply = <&vdd_cpu_big_s0>;
> > > > +};
> > > > +
> > > > +&cpu_b3 {
> > > > +     cpu-supply = <&vdd_cpu_big_s0>;
> > > > +};
> > > > +
> > > >  &combphy0_ps {
> > > >       status = "okay";
> > > >  };
> > > > @@ -215,6 +231,18 @@ &cpu_l0 {
> > > >       cpu-supply = <&vdd_cpu_lit_s0>;
> > > >  };
> > > >
> > > > +&cpu_l1 {
> > > > +     cpu-supply = <&vdd_cpu_lit_s0>;
> > > > +};
> > > > +
> > > > +&cpu_l2 {
> > > > +     cpu-supply = <&vdd_cpu_lit_s0>;
> > > > +};
> > > > +
> > > > +&cpu_l3 {
> > > > +     cpu-supply = <&vdd_cpu_lit_s0>;
> > > > +};
> > > > +
> > > >  &gmac0 {
> > > >       phy-mode = "rgmii-id";
> > > >       clock_in_out = "output";
> > > >
> > > >
> > >
> > > Reviewed-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > > Tested-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > >
> > > > so that cpufreq can pick them up.
> > >
> > > Fwiw, even without this patch they're picked up by cpufreq-dt for me:
> > >
> > >     user@trixie:~$ sudo cpupower frequency-info
> > >       analyzing CPU 5:
> > >       driver: cpufreq-dt
> > >       CPUs which run at the same hardware frequency: 4 5 6 7
> > >       CPUs which need to have their frequency coordinated by software: 4 5 6 7
> > >       maximum transition latency: 40.0 us
> > >       hardware limits: 408 MHz - 2.30 GHz
> > >       available frequency steps:  408 MHz, 600 MHz, 816 MHz, 1.01 GHz, 1.20 GHz, 1.42 GHz, 1.61 GHz, 1.80 GHz, 2.02 GHz, 2.21 GHz, 2.30 GHz
> > >       available cpufreq governors: ondemand userspace performance schedutil
> > >       current policy: frequency should be within 408 MHz and 2.30 GHz.
> > >                       The governor "schedutil" may decide which speed to use
> > >                       within this range.
> > >       current CPU frequency: 1.61 GHz (asserted by call to hardware)
> > >     user@trixie:~$ uname -a
> > >     Linux trixie 6.15.0-11173-g546b1c9e93c2 #2 SMP PREEMPT Wed Jun  4 20:32:52 CEST 2025 aarch64 GNU/Linux
> >
> > Frequencies are fine, but I don't think the more power hungry big CPU
> > cluster gets any voltage scaling without it. Once I try to load the
> > system enough that the governor decides to bump the big cluster
> > frequency up, the regulator stays at 850000 microvolts, causing random
> > reboots when the whole cluster starts starving. With the patch,
> > voltage oscillates between 700000-737000 microvolts in idle and jumps
> > up to 950000 under load, and the system seems stable.
>
> Okay, that sounds pretty serious and in this case you should add the
> following tag at the end of the commit message, usually as the first
> thing after the line break:
>
>   Fixes: 40f742b07ab2 ("arm64: dts: rockchip: Add rk3576-armsom-sige5 board")
>
> That way, our stable kernel robot overlords will pick it up and
> backport it to the kernels that already contain the mentioned commit.

Will do, thanks!

Best regards,
Alexey

Re: [PATCH 3/4] arm64: dts: rockchip: enable wifi on ArmSoM Sige5

[Jimmy Hon]

>
> +&sdio {
> +       bus-width = <4>;
> +       cap-sdio-irq;
> +       disable-wp;
> +       keep-power-in-suspend;
> +       mmc-pwrseq = <&sdio_pwrseq>;
> +       no-sd;
> +       no-mmc;
> +       non-removable;
> +       sd-uhs-sdr50;
> +       sd-uhs-sdr104;
> +       vmmc-supply = <&vcc_3v3_s3>;
> +       vqmmc-supply = <&vcc_1v8_s3>;
> +       wakeup-source;
> +       status = "okay";
> +};

When you enable the sdio node on your v1.2 board with the broadcom
chip (using SYN43752), does the btsdio.ko bind to the device and
create an extra rfkill bluetooth node?

If so, you'll want to blacklist the SYN43752 chip in the btsdio.ko.
Similar to https://github.com/jimmyhon/linux/commit/81c14dc2dea2ceaea8d390188b352d32e278abc8
The original logic was introduced in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/bluetooth/btsdio.c?id=b4cdaba274247c9c841c6a682c08fa91fb3aa549

Jimmy

Re: [PATCH 3/4] arm64: dts: rockchip: enable wifi on ArmSoM Sige5

[Alexey Charkov]

On Thu, Jun 5, 2025 at 6:43 AM Jimmy Hon <honyuenkwun@gmail.com> wrote:
>
> >
> > +&sdio {
> > +       bus-width = <4>;
> > +       cap-sdio-irq;
> > +       disable-wp;
> > +       keep-power-in-suspend;
> > +       mmc-pwrseq = <&sdio_pwrseq>;
> > +       no-sd;
> > +       no-mmc;
> > +       non-removable;
> > +       sd-uhs-sdr50;
> > +       sd-uhs-sdr104;
> > +       vmmc-supply = <&vcc_3v3_s3>;
> > +       vqmmc-supply = <&vcc_1v8_s3>;
> > +       wakeup-source;
> > +       status = "okay";
> > +};
>
> When you enable the sdio node on your v1.2 board with the broadcom
> chip (using SYN43752), does the btsdio.ko bind to the device and
> create an extra rfkill bluetooth node?

Good question, I didn't have it enabled in my build:

# CONFIG_BT_HCIBTSDIO is not set

Let me add it and report back.

> If so, you'll want to blacklist the SYN43752 chip in the btsdio.ko.
> Similar to https://github.com/jimmyhon/linux/commit/81c14dc2dea2ceaea8d390188b352d32e278abc8
> The original logic was introduced in
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/bluetooth/btsdio.c?id=b4cdaba274247c9c841c6a682c08fa91fb3aa549

I will check, thank you for the pointers!

Best regards,
Alexey

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Diederik de Haas]

[-- Attachment #1: Type: text/plain, Size: 1538 bytes --]

On Tue Jun 3, 2025 at 7:01 PM CEST, Alexey Charkov wrote:
> List both CPU supply regulators which drive the little and big CPU
> clusters, respectively, so that cpufreq can pick them up.
>
> Signed-off-by: Alexey Charkov <alchark@gmail.com>
> ---
>  .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 28 ++++++++++++++++++++++
>  1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> index b09e789c75c47fec7cf7e9810ab0dcca32d9404a..d9c129be55a0d997e04e6d677cdc98fb50353418 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> @@ -207,6 +207,22 @@ vcc_3v3_ufs_s0: regulator-vcc-ufs-s0 {
>  	};
>  };
>  
> +&cpu_b0 {
> +	cpu-supply = <&vdd_cpu_big_s0>;
> +};
> +
> +&cpu_b1 {
> +	cpu-supply = <&vdd_cpu_big_s0>;
> +};
> +
> +&cpu_b2 {
> +	cpu-supply = <&vdd_cpu_big_s0>;
> +};
> +
> +&cpu_b3 {
> +	cpu-supply = <&vdd_cpu_big_s0>;
> +};
> +
>  &combphy0_ps {
>  	status = "okay";
>  };

The &cpu_bN nodes should come after the &combphy0_ps node.

Cheers,
  Diederik

> @@ -215,6 +231,18 @@ &cpu_l0 {
>  	cpu-supply = <&vdd_cpu_lit_s0>;
>  };
>  
> +&cpu_l1 {
> +	cpu-supply = <&vdd_cpu_lit_s0>;
> +};
> +
> +&cpu_l2 {
> +	cpu-supply = <&vdd_cpu_lit_s0>;
> +};
> +
> +&cpu_l3 {
> +	cpu-supply = <&vdd_cpu_lit_s0>;
> +};
> +
>  &gmac0 {
>  	phy-mode = "rgmii-id";
>  	clock_in_out = "output";


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Alexey Charkov]

On Thu, Jun 5, 2025 at 3:18 PM Diederik de Haas <didi.debian@cknow.org> wrote:
>
> On Tue Jun 3, 2025 at 7:01 PM CEST, Alexey Charkov wrote:
> > List both CPU supply regulators which drive the little and big CPU
> > clusters, respectively, so that cpufreq can pick them up.
> >
> > Signed-off-by: Alexey Charkov <alchark@gmail.com>
> > ---
> >  .../boot/dts/rockchip/rk3576-armsom-sige5.dts      | 28 ++++++++++++++++++++++
> >  1 file changed, 28 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> > index b09e789c75c47fec7cf7e9810ab0dcca32d9404a..d9c129be55a0d997e04e6d677cdc98fb50353418 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3576-armsom-sige5.dts
> > @@ -207,6 +207,22 @@ vcc_3v3_ufs_s0: regulator-vcc-ufs-s0 {
> >       };
> >  };
> >
> > +&cpu_b0 {
> > +     cpu-supply = <&vdd_cpu_big_s0>;
> > +};
> > +
> > +&cpu_b1 {
> > +     cpu-supply = <&vdd_cpu_big_s0>;
> > +};
> > +
> > +&cpu_b2 {
> > +     cpu-supply = <&vdd_cpu_big_s0>;
> > +};
> > +
> > +&cpu_b3 {
> > +     cpu-supply = <&vdd_cpu_big_s0>;
> > +};
> > +
> >  &combphy0_ps {
> >       status = "okay";
> >  };
>
> The &cpu_bN nodes should come after the &combphy0_ps node.

True, thanks for spotting it. Don't know why they ended up separated
from &cpu_l*

Best regards,
Alexey

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Piotr Oniszczuk]

> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 4 cze 2025, o godz. 21:12:
> 
> On Wed, Jun 4, 2025 at 10:38 PM Nicolas Frattaroli
> <nicolas.frattaroli@collabora.com> wrote:
>> 
>> 
> 
> Frequencies are fine, but I don't think the more power hungry big CPU
> cluster gets any voltage scaling without it. Once I try to load the
> system enough that the governor decides to bump the big cluster
> frequency up, the regulator stays at 850000 microvolts, causing random
> reboots when the whole cluster starts starving. With the patch,
> voltage oscillates between 700000-737000 microvolts in idle and jumps
> up to 950000 under load, and the system seems stable.
> 
> Here's what I used to monitor the voltage (there must be a better way
> to do it, but it works):
> sige5 ~ # watch cat `grep -r . /sys/class/regulator/*/name | grep
> vdd_cpu_big_s0 | sed -e 's/name.*//'`/microvolts
> 
> And in another terminal:
> sige5 ~ # stress-ng -c8

Alexey,
I see you are using rk3576 board like me (nanopi-m5)
Have you on your board correctly working cpu dvfs?
I mean: [1][desired clocks reported by kernel sysfs are in pair with [2[]cur clocks?
In my case i see mine cpu lives totally on it’s own with dvfs:

Requested is [1]
Running is [2]
Measured is [3]

random read 1:
Requested CPU4: 408 MHz 
Requested CPU0: 408 MHz 
Running CPU4: 1800 MHz 
Running CPU0: 1416 MHz 
Measured on HW: 1579.03 MHz

random read 2:
Requested CPU4: 1608 MHz 
Requested CPU0: 408 MHz 
Running CPU4: 2016 MHz 
Running CPU0: 1800 MHz 
Measured on HW: 410.33 MHz

random read 3:
Requested CPU4: 600 MHz 
Requested CPU0: 1800 MHz 
Running CPU4: 816 MHz 
Running CPU0: 1008 MHz 
Measured on HW: 2275.07 MHz

random read 4:
Requested CPU4: 1608 MHz 
Requested CPU0: 1200 MHz 
Running CPU4: 816 MHz 
Running CPU0: 816 MHz 
Measured on HW: 2114.58 MHz

this is on rk3576
on i.e allwinner h618 or rk3588 all looks quite normal - [1] and [2] are equal...  

my scaling governor is on_demand - so for sure clocks are dynamic - but i.e. on 3588 with the same binaries - i can't catch -at any random read - that requested is not equal to running while on 3576 almost any random read gives significant differences.
 
[1] scaling_cur_freq in sysfs
[2] cpuinfo_cur_freq in sysfs
[3] code to estimate arm cpu clock from http://uob-hpc.github.io/2017/11/22/arm-clock-freq.html
  
 

> 
> This might warrant a note in the commit message I guess :)
> 
> Thanks for your review and testing!
> 
> Best regards,
> Alexey
> 
> _______________________________________________
> Linux-rockchip mailing list
> Linux-rockchip@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-rockchip

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Alexey Charkov]

On Thu, Jun 5, 2025 at 5:22 PM Piotr Oniszczuk
<piotr.oniszczuk@gmail.com> wrote:
>
>
>
> > Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 4 cze 2025, o godz. 21:12:
> >
> > On Wed, Jun 4, 2025 at 10:38 PM Nicolas Frattaroli
> > <nicolas.frattaroli@collabora.com> wrote:
> >>
> >>
> >
> > Frequencies are fine, but I don't think the more power hungry big CPU
> > cluster gets any voltage scaling without it. Once I try to load the
> > system enough that the governor decides to bump the big cluster
> > frequency up, the regulator stays at 850000 microvolts, causing random
> > reboots when the whole cluster starts starving. With the patch,
> > voltage oscillates between 700000-737000 microvolts in idle and jumps
> > up to 950000 under load, and the system seems stable.
> >
> > Here's what I used to monitor the voltage (there must be a better way
> > to do it, but it works):
> > sige5 ~ # watch cat `grep -r . /sys/class/regulator/*/name | grep
> > vdd_cpu_big_s0 | sed -e 's/name.*//'`/microvolts
> >
> > And in another terminal:
> > sige5 ~ # stress-ng -c8
>
> Alexey,
> I see you are using rk3576 board like me (nanopi-m5)
> Have you on your board correctly working cpu dvfs?
> I mean: [1][desired clocks reported by kernel sysfs are in pair with [2[]cur clocks?
> In my case i see mine cpu lives totally on it’s own with dvfs:

Hi Piotr,

I haven't tried to validate actual running frequencies vs. requested
frequencies, but subjective performance and power consumption seem to
be in line with what I expect.

Big thing to note here is that on Rockchip the kernel does not really
set the CPU frequency directly. It only issues an SCMI request to the
ATF firmware with the desired target frequency and provides sufficient
voltage via the supply regulator as defined by the respective OPP.

What the ATF firmware (running on a dedicated MCU completely separate
from the OS) then does is it takes the desired target frequency,
matches it to a loop length for the PVTPLL block via an internal
lookup table, and PVTPLL then determines the stable frequency that
this particular chip specimen can run at with the provided loop length
and voltage. This frequency then gets applied to the hardware via the
CRU - and as you can imagine, it can well differ from what the kernel
was requesting via SCMI.

> Requested is [1]
> Running is [2]
> Measured is [3]
>
> random read 1:
> Requested CPU4: 408 MHz
> Requested CPU0: 408 MHz
> Running CPU4: 1800 MHz
> Running CPU0: 1416 MHz
> Measured on HW: 1579.03 MHz

Hmm, have you tried pinning a particular frequency on each of the
clusters, so that the governor doesn't change it while you are going
from the point where you read the "requested" frequency to "running"
and "measured"? Also I think it would be a good idea to "taskset" the
measuring thread to particular CPU cores - otherwise I'm not sure what
it shows when the scheduler can bounce the process between cores as it
pleases it.

> random read 2:
> Requested CPU4: 1608 MHz
> Requested CPU0: 408 MHz
> Running CPU4: 2016 MHz
> Running CPU0: 1800 MHz
> Measured on HW: 410.33 MHz
>
> random read 3:
> Requested CPU4: 600 MHz
> Requested CPU0: 1800 MHz
> Running CPU4: 816 MHz
> Running CPU0: 1008 MHz
> Measured on HW: 2275.07 MHz
>
> random read 4:
> Requested CPU4: 1608 MHz
> Requested CPU0: 1200 MHz
> Running CPU4: 816 MHz
> Running CPU0: 816 MHz
> Measured on HW: 2114.58 MHz
>
> this is on rk3576
> on i.e allwinner h618 or rk3588 all looks quite normal - [1] and [2] are equal...

Are these taken on the mainline kernel or Rockchip one? Binary BL31
from Rockchip or opensource TF-A? With big-core CPUs linked up to
their supply regulator (as per this patch) or without?

Can't see why the behavior would differ vs. RK3588 though, unless
there are some bugs somewhere.

Best regards,
Alexey

Re: [PATCH 3/4] arm64: dts: rockchip: enable wifi on ArmSoM Sige5

[Alexey Charkov]

On Thu, Jun 5, 2025 at 10:32 AM Alexey Charkov <alchark@gmail.com> wrote:
>
> On Thu, Jun 5, 2025 at 6:43 AM Jimmy Hon <honyuenkwun@gmail.com> wrote:
> >
> > >
> > > +&sdio {
> > > +       bus-width = <4>;
> > > +       cap-sdio-irq;
> > > +       disable-wp;
> > > +       keep-power-in-suspend;
> > > +       mmc-pwrseq = <&sdio_pwrseq>;
> > > +       no-sd;
> > > +       no-mmc;
> > > +       non-removable;
> > > +       sd-uhs-sdr50;
> > > +       sd-uhs-sdr104;
> > > +       vmmc-supply = <&vcc_3v3_s3>;
> > > +       vqmmc-supply = <&vcc_1v8_s3>;
> > > +       wakeup-source;
> > > +       status = "okay";
> > > +};
> >
> > When you enable the sdio node on your v1.2 board with the broadcom
> > chip (using SYN43752), does the btsdio.ko bind to the device and
> > create an extra rfkill bluetooth node?
>
> Good question, I didn't have it enabled in my build:
>
> # CONFIG_BT_HCIBTSDIO is not set
>
> Let me add it and report back.

So I've rebuilt it with btsdio.ko module enabled. As I boot the
system, WiFi (via SDIO) and Bluetooth (via UART) drivers get probed
and load their respective firmwares. btsdio.ko doesn't get
auto-loaded. If I load it manually after booting, it doesn't bind to
anything and doesn't create any extra rfkill nodes.

Is there anything else I need to check or look out for?

Best regards,
Alexey

> > If so, you'll want to blacklist the SYN43752 chip in the btsdio.ko.
> > Similar to https://github.com/jimmyhon/linux/commit/81c14dc2dea2ceaea8d390188b352d32e278abc8
> > The original logic was introduced in
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/bluetooth/btsdio.c?id=b4cdaba274247c9c841c6a682c08fa91fb3aa549
>
> I will check, thank you for the pointers!
>
> Best regards,
> Alexey

Re: [PATCH 3/4] arm64: dts: rockchip: enable wifi on ArmSoM Sige5

[Jimmy Hon]

On Thu, Jun 5, 2025 at 9:14 AM Alexey Charkov <alchark@gmail.com> wrote:
>
> On Thu, Jun 5, 2025 at 10:32 AM Alexey Charkov <alchark@gmail.com> wrote:
> >
> > On Thu, Jun 5, 2025 at 6:43 AM Jimmy Hon <honyuenkwun@gmail.com> wrote:
> > >
> > > >
> > > > +&sdio {
> > > > +       bus-width = <4>;
> > > > +       cap-sdio-irq;
> > > > +       disable-wp;
> > > > +       keep-power-in-suspend;
> > > > +       mmc-pwrseq = <&sdio_pwrseq>;
> > > > +       no-sd;
> > > > +       no-mmc;
> > > > +       non-removable;
> > > > +       sd-uhs-sdr50;
> > > > +       sd-uhs-sdr104;
> > > > +       vmmc-supply = <&vcc_3v3_s3>;
> > > > +       vqmmc-supply = <&vcc_1v8_s3>;
> > > > +       wakeup-source;
> > > > +       status = "okay";
> > > > +};
> > >
> > > When you enable the sdio node on your v1.2 board with the broadcom
> > > chip (using SYN43752), does the btsdio.ko bind to the device and
> > > create an extra rfkill bluetooth node?
> >
> > Good question, I didn't have it enabled in my build:
> >
> > # CONFIG_BT_HCIBTSDIO is not set
> >
> > Let me add it and report back.
>
> So I've rebuilt it with btsdio.ko module enabled. As I boot the
> system, WiFi (via SDIO) and Bluetooth (via UART) drivers get probed
> and load their respective firmwares. btsdio.ko doesn't get
> auto-loaded. If I load it manually after booting, it doesn't bind to
> anything and doesn't create any extra rfkill nodes.
>
> Is there anything else I need to check or look out for?
>
> Best regards,
> Alexey

That should be all you need to check. I guess they stopped incorrectly
advertising SDIO_DEVICE_CLASS for bluetooth.
Jimmy

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Piotr Oniszczuk]

> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 5 cze 2025, o godz. 15:42:
>> 
>>> 
>>> 
>> 
>> Alexey,
>> I see you are using rk3576 board like me (nanopi-m5)
>> Have you on your board correctly working cpu dvfs?
>> I mean: [1][desired clocks reported by kernel sysfs are in pair with [2[]cur clocks?
>> In my case i see mine cpu lives totally on it’s own with dvfs:
> 
> Hi Piotr,
> 
> I haven't tried to validate actual running frequencies vs. requested
> frequencies, but subjective performance and power consumption seem to
> be in line with what I expect.

well - my subjective l&f is that  - currently - my rk3576 seems „slower" than i.e. 4xA53 h618. 
This directed me to investigate this issue.
Test run was media player (mythtv) where ui has gl effects and ui gl transitions „speed” are quite proportional to cpu speed (and gpu).
My overall feeling is: ux is comparable to slow socs 4xA53@1.4GHz/G31. This is with mainline atf + collabora uboot [1] and on-demand gov.
I done test with replacing uboot from mainline atf + collabora uboot to bin. dump of vendor uboot (2017.09) and with this ux become almost as expected (i mean comparable with i.e. rk3399).

I done test with perf gov. and

1.collabora uboot[1] + mainline atf 2.13
2.collabora uboot[1] + rockchip rkbin bl31 blob [2]
3.vendor uboot (bin dump from friendlyelec ubuntu image)   

[a] on vendor uboot:
Requested CPU4: 2304 MHz 
Requested CPU0: 2208 MHz 
Running CPU4: 1008 MHz 
Running CPU0: 1008 MHz 
Measured on HW: 1580.11 MHz 

[b] on collabora uboot + mainline atf:
Requested CPU4: 2304 MHz
Requested CPU0: 2208 MHz
Running CPU4: 816 MHz
Running CPU0: 816 MHz
Measured on HW: 808.72 MHz   

[c] on collabora uboot + rockchip rkbin bl31 blob:
Requested CPU4: 2304 MHz
Requested CPU0: 2208 MHz
Running CPU4: 816 MHz
Running CPU0: 816 MHz
Measured on HW: 812.49 MHz

in all cases all clocks are constant as they should
Interesting that on collabora uboot [b][c] measured clock is 808 vs 1580 on vendor uboot [a]...
sw video decode conforms this diff: hd h264 gets cpu load: 172%[b][c] vs 87%[a]

….

> 
> 
> Are these taken on the mainline kernel or Rockchip one?

I tested:

6.15 mainline + some collabora patches

1.collabora uboot[1] + mainline atf 2.13
2.collabora uboot[1] + rockchip rkbin bl31 blob [2]
3.vendor uboot (bin dump from friendlyelec ubuntu image)   


> Binary BL31
> from Rockchip or opensource TF-A? With big-core CPUs linked up to
> their supply regulator (as per this patch)

yes

So summarising:

1. i see kind of issue with clock values (e.g. perf gov gives 800MHz on mainline atf). 
imho rot cause seems to be in collabora uboot

2. on-demand gov. seems behave much more like powersave.
this seems to be 3576 specific: 
-on 3588 change from perf to on_demand is hardly noticeable in ux
-on 3576 such change makes ux feeling noticeable slow (like 4xA53 soc)
i think this is more related to diff between scmi mcu gov algo in 3576 vs. 3588
(imho 3576 algo has high latency in clock increases when demand happens + too short delay for  clocks decreases to save power)
     


[1] https://gitlab.collabora.com/hardware-enablement/rockchip-3588/u-boot
[2] https://github.com/rockchip-linux/rkbin/blob/master/bin/rk35/rk3576_bl31_v1.15.elf

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Alexey Charkov]

On Sun, Jun 8, 2025 at 11:24 AM Piotr Oniszczuk
<piotr.oniszczuk@gmail.com> wrote:
> > Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 5 cze 2025, o godz. 15:42:
> >> Alexey,
> >> I see you are using rk3576 board like me (nanopi-m5)
> >> Have you on your board correctly working cpu dvfs?
> >> I mean: [1][desired clocks reported by kernel sysfs are in pair with [2[]cur clocks?
> >> In my case i see mine cpu lives totally on it’s own with dvfs:
> >
> > Hi Piotr,
> >
> > I haven't tried to validate actual running frequencies vs. requested
> > frequencies, but subjective performance and power consumption seem to
> > be in line with what I expect.
>
> well - my subjective l&f is that  - currently - my rk3576 seems „slower" than i.e. 4xA53 h618.

In my experience, native compilation of GCC 14 using 8 threads on
RK3576 (mainline with passive cooling and throttling enabled): 2 hours
6 minutes, on RK3588 (mainline with passive cooling via Radxa Rock 5B
case and throttling enabled but never kicking in): 1 hour 10 minutes

> This directed me to investigate this issue.
> Test run was media player (mythtv) where ui has gl effects and ui gl transitions „speed” are quite proportional to cpu speed (and gpu).
> My overall feeling is: ux is comparable to slow socs 4xA53@1.4GHz/G31. This is with mainline atf + collabora uboot [1] and on-demand gov.
> I done test with replacing uboot from mainline atf + collabora uboot to bin. dump of vendor uboot (2017.09) and with this ux become almost as expected (i mean comparable with i.e. rk3399).
>
> I done test with perf gov. and
>
> 1.collabora uboot[1] + mainline atf 2.13
> 2.collabora uboot[1] + rockchip rkbin bl31 blob [2]
> 3.vendor uboot (bin dump from friendlyelec ubuntu image)
>
> [a] on vendor uboot:
> Requested CPU4: 2304 MHz
> Requested CPU0: 2208 MHz
> Running CPU4: 1008 MHz
> Running CPU0: 1008 MHz
> Measured on HW: 1580.11 MHz
>
> [b] on collabora uboot + mainline atf:
> Requested CPU4: 2304 MHz
> Requested CPU0: 2208 MHz
> Running CPU4: 816 MHz
> Running CPU0: 816 MHz
> Measured on HW: 808.72 MHz
>
> [c] on collabora uboot + rockchip rkbin bl31 blob:
> Requested CPU4: 2304 MHz
> Requested CPU0: 2208 MHz
> Running CPU4: 816 MHz
> Running CPU0: 816 MHz
> Measured on HW: 812.49 MHz
>
> in all cases all clocks are constant as they should
> Interesting that on collabora uboot [b][c] measured clock is 808 vs 1580 on vendor uboot [a]...
> sw video decode conforms this diff: hd h264 gets cpu load: 172%[b][c] vs 87%[a]

Can't see how u-boot would affect CPU speed in Linux, as long as you
use comparable ATF images. Do you use the same kernel and dtb in all
these cases? Also, what's your thermal setup?

> So summarising:
>
> 1. i see kind of issue with clock values (e.g. perf gov gives 800MHz on mainline atf).
> imho rot cause seems to be in collabora uboot
>
> 2. on-demand gov. seems behave much more like powersave.
> this seems to be 3576 specific:
> -on 3588 change from perf to on_demand is hardly noticeable in ux

Not sure UX is a particularly good measure of CPU performance, as long
as you've got a properly accelerated DRM graphics pipeline. More
likely 2D/3D and memory.

By the way, I'd rather go for the "schedutil" governor, as it is more
forward-looking than "ondemand", thus should be more responsive to
load changes. It's also the default in modern distros AFAIR.

> -on 3576 such change makes ux feeling noticeable slow (like 4xA53 soc)
> i think this is more related to diff between scmi mcu gov algo in 3576 vs. 3588
> (imho 3576 algo has high latency in clock increases when demand happens + too short delay for  clocks decreases to save power)

There might be some difference in how PVTPLL behaves on RK3576 vs.
RK3588. But frankly first I would check if you are using comparable
ATF implementations (e.g. upstream TF-A in both cases), kernels and
thermal environment :)

Best regards,
Alexey

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Piotr Oniszczuk]

> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 9 cze 2025, o godz. 16:05:
> 
> On Sun, Jun 8, 2025 at 11:24 AM Piotr Oniszczuk
> <piotr.oniszczuk@gmail.com> wrote:
>>> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 5 cze 2025, o godz. 15:42:
>>>> Alexey,
>>>> I see you are using rk3576 board like me (nanopi-m5)
>>>> Have you on your board correctly working cpu dvfs?
>>>> I mean: [1][desired clocks reported by kernel sysfs are in pair with [2[]cur clocks?
>>>> In my case i see mine cpu lives totally on it’s own with dvfs:
>>> 
>>> Hi Piotr,
>>> 
>>> I haven't tried to validate actual running frequencies vs. requested
>>> frequencies, but subjective performance and power consumption seem to
>>> be in line with what I expect.
>> 
>> well - my subjective l&f is that  - currently - my rk3576 seems „slower" than i.e. 4xA53 h618.
> 
> In my experience, native compilation of GCC 14 using 8 threads on
> RK3576 (mainline with passive cooling and throttling enabled): 2 hours
> 6 minutes, on RK3588 (mainline with passive cooling via Radxa Rock 5B
> case and throttling enabled but never kicking in): 1 hour 10 minutes

by curiosity i looked randomly on 3576 vs 3588:
multithread passmark: 3675 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3576&id=6213)
multithread passmark: 4530 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3588&id=4906)

assuming 3588 as baseline, 3576 is approx 20% slower on multithread passmark (has ~0,8 comp power of 3588)
70 min compile on 3588 should take something like ~86min on 3576.
In your case 126min compile on 3576 shows 3576 offers 0,55 comp power of 3588.
Roughly 3576 should do this task in 40min less than you currently see i think
 

> Can't see how u-boot would affect CPU speed in Linux, as long as you
> use comparable ATF images. Do you use the same kernel and dtb in all
> these cases? Also, what's your thermal setup?

yes. in all cases only change was: uboot & atf
thermal is based on recent collabora series (+ recent pooling fix for clocks return from throttling) 

> 
> 
> Not sure UX is a particularly good measure of CPU performance, as long
> as you've got a properly accelerated DRM graphics pipeline. More
> likely 2D/3D and memory.

indeed.
For quantified look i’m looking on v.simple approach to estimate real clock is http://uob-hpc.github.io/2017/11/22/arm-clock-freq.html
by curiosity i looked what it reports on a53/a55/a72/a76 and it is surprisingly accurate :-)
on mine 3576 with collabora uboot+mainline atf is hows 800MHz (and in perf. gov it seems to be constant)

> 
> There might be some difference in how PVTPLL behaves on RK3576 vs.
> RK3588. But frankly first I would check if you are using comparable
> ATF implementations (e.g. upstream TF-A in both cases), kernels and
> thermal environment :)
 
all tests: the same 6.15.2 mainline + some collabora patches

diffs were: 
1.collabora uboot[1] + mainline atf 2.13
2.collabora uboot[1] + rockchip rkbin bl31 blob
3.vendor uboot (bin dump from friendlyelec ubuntu image)   

on 1/2 i see kind of issue with clock values (i.e. perf gov gives constant 800MHz on mainline atf).
3 seems to perform better - (i.e. perf gov gives constant 1500MHz so all is snappier/faster) 

as pvtpll is trying to reach target freq and ends with stable oper. freq for given cpu_vdd/temp/fab.cut - possible theory is: if cpu_vdd is wrongly driven, pvtpll programmed freq will way diff from req. (i.e. way too low).
monitoring vdd_big/vdd_lit shows constant 950mv for perf.gov (read from sysfs; not verified with multimeter as i don’t have pcb pdf with components layout so can’t identify i.e. vdd_big filtering caps c1007/c1008 to measure)

(.dxf file provided by friendlyelec [1] seems to be lacking comp. numbering)  

[1]: https://wiki.friendlyelec.com/wiki/images/e/e1/NanoPi_M5_2411_DXF.zip

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Alexey Charkov]

On Sun, Jun 15, 2025 at 8:00 PM Piotr Oniszczuk
<piotr.oniszczuk@gmail.com> wrote:
>
>
>
> > Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 9 cze 2025, o godz. 16:05:
> >
> > On Sun, Jun 8, 2025 at 11:24 AM Piotr Oniszczuk
> > <piotr.oniszczuk@gmail.com> wrote:
> >>> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 5 cze 2025, o godz. 15:42:
> >>>> Alexey,
> >>>> I see you are using rk3576 board like me (nanopi-m5)
> >>>> Have you on your board correctly working cpu dvfs?
> >>>> I mean: [1][desired clocks reported by kernel sysfs are in pair with [2[]cur clocks?
> >>>> In my case i see mine cpu lives totally on it’s own with dvfs:
> >>>
> >>> Hi Piotr,
> >>>
> >>> I haven't tried to validate actual running frequencies vs. requested
> >>> frequencies, but subjective performance and power consumption seem to
> >>> be in line with what I expect.
> >>
> >> well - my subjective l&f is that  - currently - my rk3576 seems „slower" than i.e. 4xA53 h618.
> >
> > In my experience, native compilation of GCC 14 using 8 threads on
> > RK3576 (mainline with passive cooling and throttling enabled): 2 hours
> > 6 minutes, on RK3588 (mainline with passive cooling via Radxa Rock 5B
> > case and throttling enabled but never kicking in): 1 hour 10 minutes
>
> by curiosity i looked randomly on 3576 vs 3588:
> multithread passmark: 3675 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3576&id=6213)
> multithread passmark: 4530 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3588&id=4906)
>
> assuming 3588 as baseline, 3576 is approx 20% slower on multithread passmark (has ~0,8 comp power of 3588)
> 70 min compile on 3588 should take something like ~86min on 3576.
> In your case 126min compile on 3576 shows 3576 offers 0,55 comp power of 3588.
> Roughly 3576 should do this task in 40min less than you currently see i think
>
>
> > Can't see how u-boot would affect CPU speed in Linux, as long as you
> > use comparable ATF images. Do you use the same kernel and dtb in all
> > these cases? Also, what's your thermal setup?
>
> yes. in all cases only change was: uboot & atf
> thermal is based on recent collabora series (+ recent pooling fix for clocks return from throttling)
>
> >
> >
> > Not sure UX is a particularly good measure of CPU performance, as long
> > as you've got a properly accelerated DRM graphics pipeline. More
> > likely 2D/3D and memory.
>
> indeed.
> For quantified look i’m looking on v.simple approach to estimate real clock is http://uob-hpc.github.io/2017/11/22/arm-clock-freq.html
> by curiosity i looked what it reports on a53/a55/a72/a76 and it is surprisingly accurate :-)
> on mine 3576 with collabora uboot+mainline atf is hows 800MHz (and in perf. gov it seems to be constant)
>
> >
> > There might be some difference in how PVTPLL behaves on RK3576 vs.
> > RK3588. But frankly first I would check if you are using comparable
> > ATF implementations (e.g. upstream TF-A in both cases), kernels and
> > thermal environment :)
>
> all tests: the same 6.15.2 mainline + some collabora patches
>
> diffs were:
> 1.collabora uboot[1] + mainline atf 2.13
> 2.collabora uboot[1] + rockchip rkbin bl31 blob
> 3.vendor uboot (bin dump from friendlyelec ubuntu image)
>
> on 1/2 i see kind of issue with clock values (i.e. perf gov gives constant 800MHz on mainline atf).
> 3 seems to perform better - (i.e. perf gov gives constant 1500MHz so all is snappier/faster)
>
> as pvtpll is trying to reach target freq and ends with stable oper. freq for given cpu_vdd/temp/fab.cut - possible theory is: if cpu_vdd is wrongly driven, pvtpll programmed freq will way diff from req. (i.e. way too low).

It is an interesting line of thought. After all, RK3576 boards I
looked at use an I2C connected PMIC, while RK3588 use an SPI connected
one. If there is some bug in the I2C bus glue for the PMIC driver,  it
could theoretically report updated voltage without always updating it
properly.

I still believe it succeeds more often than not though, because I
observe measured power consumption of around 5W under full load vs.
around 1.4W in idle (on ArmSoM Sige5). Which doesn't rule out some
transient weirdness.

> monitoring vdd_big/vdd_lit shows constant 950mv for perf.gov (read from sysfs; not verified with multimeter as i don’t have pcb pdf with components layout so can’t identify i.e. vdd_big filtering caps c1007/c1008 to measure)

Measuring voltages to within 0.1V precision (not just resolution)
sounds like a big ask of a multimeter IMHO :)

Best,
Alexey

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Alexey Charkov]

On Sun, Jun 15, 2025 at 8:00 PM Piotr Oniszczuk
<piotr.oniszczuk@gmail.com> wrote:
>
>
>
> > Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 9 cze 2025, o godz. 16:05:
> >
> > On Sun, Jun 8, 2025 at 11:24 AM Piotr Oniszczuk
> > <piotr.oniszczuk@gmail.com> wrote:
> >>> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 5 cze 2025, o godz. 15:42:
> >>>> Alexey,
> >>>> I see you are using rk3576 board like me (nanopi-m5)
> >>>> Have you on your board correctly working cpu dvfs?
> >>>> I mean: [1][desired clocks reported by kernel sysfs are in pair with [2[]cur clocks?
> >>>> In my case i see mine cpu lives totally on it’s own with dvfs:
> >>>
> >>> Hi Piotr,
> >>>
> >>> I haven't tried to validate actual running frequencies vs. requested
> >>> frequencies, but subjective performance and power consumption seem to
> >>> be in line with what I expect.
> >>
> >> well - my subjective l&f is that  - currently - my rk3576 seems „slower" than i.e. 4xA53 h618.
> >
> > In my experience, native compilation of GCC 14 using 8 threads on
> > RK3576 (mainline with passive cooling and throttling enabled): 2 hours
> > 6 minutes, on RK3588 (mainline with passive cooling via Radxa Rock 5B
> > case and throttling enabled but never kicking in): 1 hour 10 minutes
>
> by curiosity i looked randomly on 3576 vs 3588:
> multithread passmark: 3675 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3576&id=6213)
> multithread passmark: 4530 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3588&id=4906)
>
> assuming 3588 as baseline, 3576 is approx 20% slower on multithread passmark (has ~0,8 comp power of 3588)
> 70 min compile on 3588 should take something like ~86min on 3576.
> In your case 126min compile on 3576 shows 3576 offers 0,55 comp power of 3588.
> Roughly 3576 should do this task in 40min less than you currently see i think
>
>
> > Can't see how u-boot would affect CPU speed in Linux, as long as you
> > use comparable ATF images. Do you use the same kernel and dtb in all
> > these cases? Also, what's your thermal setup?
>
> yes. in all cases only change was: uboot & atf
> thermal is based on recent collabora series (+ recent pooling fix for clocks return from throttling)
>
> >
> >
> > Not sure UX is a particularly good measure of CPU performance, as long
> > as you've got a properly accelerated DRM graphics pipeline. More
> > likely 2D/3D and memory.
>
> indeed.
> For quantified look i’m looking on v.simple approach to estimate real clock is http://uob-hpc.github.io/2017/11/22/arm-clock-freq.html
> by curiosity i looked what it reports on a53/a55/a72/a76 and it is surprisingly accurate :-)
> on mine 3576 with collabora uboot+mainline atf is hows 800MHz (and in perf. gov it seems to be constant)
>
> >
> > There might be some difference in how PVTPLL behaves on RK3576 vs.
> > RK3588. But frankly first I would check if you are using comparable
> > ATF implementations (e.g. upstream TF-A in both cases), kernels and
> > thermal environment :)
>
> all tests: the same 6.15.2 mainline + some collabora patches
>
> diffs were:
> 1.collabora uboot[1] + mainline atf 2.13
> 2.collabora uboot[1] + rockchip rkbin bl31 blob
> 3.vendor uboot (bin dump from friendlyelec ubuntu image)
>
> on 1/2 i see kind of issue with clock values (i.e. perf gov gives constant 800MHz on mainline atf).
> 3 seems to perform better - (i.e. perf gov gives constant 1500MHz so all is snappier/faster)

There is indeed something weird going on. I've tried running sbc-bench
[1], and even though I observe dynamically varying CPU frequencies
after boot with schedutil governor, once sbc-bench switches the
governor to "performance" and goes through the OPPs in descending
frequency order, the CPUs seem to get stuck at the last applied low
frequency. Even after max frequency gets reverted from 408 MHz to
something higher, even after I switch the governor to something else -
no matter what. Only a reboot gets the higher frequencies 'unstuck'
for me.

These are all observed at around 55C SoC temperature, so throttling is
not an issue. Regulators are stuck at 950000 uV - way above 700000 uV
that the 408 MHz OPP requires (and power readings seem to match: I'm
getting about 2.3W consumption at 408 MHz in idle vs. normal idle
reading of 1.4W at around 1 GHz).

Not sure what's going on here, and I don't remember seeing anything
similar on RK3588. Thoughts welcome.

Best regards,
Alexey

[1] https://github.com/ThomasKaiser/sbc-bench

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Nicolas Frattaroli]

Hello,

+Cc Jonas Karlman as he is intimately familiar with RK3576 clock shenanigans by now,

On Wednesday, 18 June 2025 15:51:45 Central European Summer Time Alexey Charkov wrote:
> On Sun, Jun 15, 2025 at 8:00 PM Piotr Oniszczuk
> <piotr.oniszczuk@gmail.com> wrote:
> >
> >
> >
> > > Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 9 cze 2025, o godz. 16:05:
> > >
> > > On Sun, Jun 8, 2025 at 11:24 AM Piotr Oniszczuk
> > > <piotr.oniszczuk@gmail.com> wrote:
> > >>> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 5 cze 2025, o godz. 15:42:
> > >>>> Alexey,
> > >>>> I see you are using rk3576 board like me (nanopi-m5)
> > >>>> Have you on your board correctly working cpu dvfs?
> > >>>> I mean: [1][desired clocks reported by kernel sysfs are in pair with [2[]cur clocks?
> > >>>> In my case i see mine cpu lives totally on it’s own with dvfs:
> > >>>
> > >>> Hi Piotr,
> > >>>
> > >>> I haven't tried to validate actual running frequencies vs. requested
> > >>> frequencies, but subjective performance and power consumption seem to
> > >>> be in line with what I expect.
> > >>
> > >> well - my subjective l&f is that  - currently - my rk3576 seems „slower" than i.e. 4xA53 h618.
> > >
> > > In my experience, native compilation of GCC 14 using 8 threads on
> > > RK3576 (mainline with passive cooling and throttling enabled): 2 hours
> > > 6 minutes, on RK3588 (mainline with passive cooling via Radxa Rock 5B
> > > case and throttling enabled but never kicking in): 1 hour 10 minutes
> >
> > by curiosity i looked randomly on 3576 vs 3588:
> > multithread passmark: 3675 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3576&id=6213)
> > multithread passmark: 4530 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3588&id=4906)
> >
> > assuming 3588 as baseline, 3576 is approx 20% slower on multithread passmark (has ~0,8 comp power of 3588)
> > 70 min compile on 3588 should take something like ~86min on 3576.
> > In your case 126min compile on 3576 shows 3576 offers 0,55 comp power of 3588.
> > Roughly 3576 should do this task in 40min less than you currently see i think
> >
> >
> > > Can't see how u-boot would affect CPU speed in Linux, as long as you
> > > use comparable ATF images. Do you use the same kernel and dtb in all
> > > these cases? Also, what's your thermal setup?
> >
> > yes. in all cases only change was: uboot & atf
> > thermal is based on recent collabora series (+ recent pooling fix for clocks return from throttling)
> >
> > >
> > >
> > > Not sure UX is a particularly good measure of CPU performance, as long
> > > as you've got a properly accelerated DRM graphics pipeline. More
> > > likely 2D/3D and memory.
> >
> > indeed.
> > For quantified look i’m looking on v.simple approach to estimate real clock is http://uob-hpc.github.io/2017/11/22/arm-clock-freq.html
> > by curiosity i looked what it reports on a53/a55/a72/a76 and it is surprisingly accurate :-)
> > on mine 3576 with collabora uboot+mainline atf is hows 800MHz (and in perf. gov it seems to be constant)
> >
> > >
> > > There might be some difference in how PVTPLL behaves on RK3576 vs.
> > > RK3588. But frankly first I would check if you are using comparable
> > > ATF implementations (e.g. upstream TF-A in both cases), kernels and
> > > thermal environment :)
> >
> > all tests: the same 6.15.2 mainline + some collabora patches
> >
> > diffs were:
> > 1.collabora uboot[1] + mainline atf 2.13
> > 2.collabora uboot[1] + rockchip rkbin bl31 blob
> > 3.vendor uboot (bin dump from friendlyelec ubuntu image)
> >
> > on 1/2 i see kind of issue with clock values (i.e. perf gov gives constant 800MHz on mainline atf).
> > 3 seems to perform better - (i.e. perf gov gives constant 1500MHz so all is snappier/faster)
> 
> There is indeed something weird going on. I've tried running sbc-bench
> [1], and even though I observe dynamically varying CPU frequencies
> after boot with schedutil governor, once sbc-bench switches the
> governor to "performance" and goes through the OPPs in descending
> frequency order, the CPUs seem to get stuck at the last applied low
> frequency. Even after max frequency gets reverted from 408 MHz to
> something higher, even after I switch the governor to something else -
> no matter what. Only a reboot gets the higher frequencies 'unstuck'
> for me.
> 
> These are all observed at around 55C SoC temperature, so throttling is
> not an issue. Regulators are stuck at 950000 uV - way above 700000 uV
> that the 408 MHz OPP requires (and power readings seem to match: I'm
> getting about 2.3W consumption at 408 MHz in idle vs. normal idle
> reading of 1.4W at around 1 GHz).
> 
> Not sure what's going on here, and I don't remember seeing anything
> similar on RK3588. Thoughts welcome.

This may once again be a "accidentally uses wrong clock IDs" type
situation. The other possibility is that we're getting confused
between what we think the clock rate is and what SCMI actually set
the clock rate to.

Things to check is whether the right clock controller (scmi vs cru)
and the right clock id (check ATF source for this) is used.

Kind regards,
Nicolas Frattaroli

> 
> Best regards,
> Alexey
> 
> [1] https://github.com/ThomasKaiser/sbc-bench
> 

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Alexey Charkov]

On Wed, Jun 18, 2025 at 6:06 PM Nicolas Frattaroli
<nicolas.frattaroli@collabora.com> wrote:
>
> Hello,
>
> +Cc Jonas Karlman as he is intimately familiar with RK3576 clock shenanigans by now,
>
> On Wednesday, 18 June 2025 15:51:45 Central European Summer Time Alexey Charkov wrote:
> > On Sun, Jun 15, 2025 at 8:00 PM Piotr Oniszczuk
> > <piotr.oniszczuk@gmail.com> wrote:
> > >
> > >
> > >
> > > > Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 9 cze 2025, o godz. 16:05:
> > > >
> > > > On Sun, Jun 8, 2025 at 11:24 AM Piotr Oniszczuk
> > > > <piotr.oniszczuk@gmail.com> wrote:
> > > >>> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 5 cze 2025, o godz. 15:42:
> > > >>>> Alexey,
> > > >>>> I see you are using rk3576 board like me (nanopi-m5)
> > > >>>> Have you on your board correctly working cpu dvfs?
> > > >>>> I mean: [1][desired clocks reported by kernel sysfs are in pair with [2[]cur clocks?
> > > >>>> In my case i see mine cpu lives totally on it’s own with dvfs:
> > > >>>
> > > >>> Hi Piotr,
> > > >>>
> > > >>> I haven't tried to validate actual running frequencies vs. requested
> > > >>> frequencies, but subjective performance and power consumption seem to
> > > >>> be in line with what I expect.
> > > >>
> > > >> well - my subjective l&f is that  - currently - my rk3576 seems „slower" than i.e. 4xA53 h618.
> > > >
> > > > In my experience, native compilation of GCC 14 using 8 threads on
> > > > RK3576 (mainline with passive cooling and throttling enabled): 2 hours
> > > > 6 minutes, on RK3588 (mainline with passive cooling via Radxa Rock 5B
> > > > case and throttling enabled but never kicking in): 1 hour 10 minutes
> > >
> > > by curiosity i looked randomly on 3576 vs 3588:
> > > multithread passmark: 3675 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3576&id=6213)
> > > multithread passmark: 4530 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3588&id=4906)
> > >
> > > assuming 3588 as baseline, 3576 is approx 20% slower on multithread passmark (has ~0,8 comp power of 3588)
> > > 70 min compile on 3588 should take something like ~86min on 3576.
> > > In your case 126min compile on 3576 shows 3576 offers 0,55 comp power of 3588.
> > > Roughly 3576 should do this task in 40min less than you currently see i think
> > >
> > >
> > > > Can't see how u-boot would affect CPU speed in Linux, as long as you
> > > > use comparable ATF images. Do you use the same kernel and dtb in all
> > > > these cases? Also, what's your thermal setup?
> > >
> > > yes. in all cases only change was: uboot & atf
> > > thermal is based on recent collabora series (+ recent pooling fix for clocks return from throttling)
> > >
> > > >
> > > >
> > > > Not sure UX is a particularly good measure of CPU performance, as long
> > > > as you've got a properly accelerated DRM graphics pipeline. More
> > > > likely 2D/3D and memory.
> > >
> > > indeed.
> > > For quantified look i’m looking on v.simple approach to estimate real clock is http://uob-hpc.github.io/2017/11/22/arm-clock-freq.html
> > > by curiosity i looked what it reports on a53/a55/a72/a76 and it is surprisingly accurate :-)
> > > on mine 3576 with collabora uboot+mainline atf is hows 800MHz (and in perf. gov it seems to be constant)
> > >
> > > >
> > > > There might be some difference in how PVTPLL behaves on RK3576 vs.
> > > > RK3588. But frankly first I would check if you are using comparable
> > > > ATF implementations (e.g. upstream TF-A in both cases), kernels and
> > > > thermal environment :)
> > >
> > > all tests: the same 6.15.2 mainline + some collabora patches
> > >
> > > diffs were:
> > > 1.collabora uboot[1] + mainline atf 2.13
> > > 2.collabora uboot[1] + rockchip rkbin bl31 blob
> > > 3.vendor uboot (bin dump from friendlyelec ubuntu image)
> > >
> > > on 1/2 i see kind of issue with clock values (i.e. perf gov gives constant 800MHz on mainline atf).
> > > 3 seems to perform better - (i.e. perf gov gives constant 1500MHz so all is snappier/faster)
> >
> > There is indeed something weird going on. I've tried running sbc-bench
> > [1], and even though I observe dynamically varying CPU frequencies
> > after boot with schedutil governor, once sbc-bench switches the
> > governor to "performance" and goes through the OPPs in descending
> > frequency order, the CPUs seem to get stuck at the last applied low
> > frequency. Even after max frequency gets reverted from 408 MHz to
> > something higher, even after I switch the governor to something else -
> > no matter what. Only a reboot gets the higher frequencies 'unstuck'
> > for me.
> >
> > These are all observed at around 55C SoC temperature, so throttling is
> > not an issue. Regulators are stuck at 950000 uV - way above 700000 uV
> > that the 408 MHz OPP requires (and power readings seem to match: I'm
> > getting about 2.3W consumption at 408 MHz in idle vs. normal idle
> > reading of 1.4W at around 1 GHz).
> >
> > Not sure what's going on here, and I don't remember seeing anything
> > similar on RK3588. Thoughts welcome.
>
> This may once again be a "accidentally uses wrong clock IDs" type
> situation. The other possibility is that we're getting confused
> between what we think the clock rate is and what SCMI actually set
> the clock rate to.
>
> Things to check is whether the right clock controller (scmi vs cru)
> and the right clock id (check ATF source for this) is used.

Clock IDs in the kernel seem to match those in ATF, but I've noticed
what appears to be a buffer overflow in some of the SCMI clock names
defined in the opensource TF-A (thanks GCC 15 and its zealous
warnings):

alchark@alchark-surface ~/trusted-firmware-a $ make
CC=aarch64-unknown-linux-gnu-gcc PLAT=rk3576 -j12
Building rk3576
  CC      plat/rockchip/rk3576/scmi/rk3576_clk.c
plat/rockchip/rk3576/scmi/rk3576_clk.c:1102:154: error:
initializer-string for array of ‘char’ truncates NUL terminator but
destination lacks ‘nonstring’ attribute (17 chars into 16 available)
[-Werror=unterminated-string-initialization]
 1102 | stimer0_root, p_100m_24m, clk_stimer0_root_info,
&clk_scmi_ops_com_critical, rk3576_common_rates, false, true);
      |
                                              ^
plat/rockchip/rk3576/scmi/rk3576_clk.c:246:18: note: in definition of
macro ‘RK3576_SCMI_CLOCK_COM’
  246 |         .name = #_name,
         \
      |                  ^~~~~
plat/rockchip/rk3576/scmi/rk3576_clk.c:1103:154: error:
initializer-string for array of ‘char’ truncates NUL terminator but
destination lacks ‘nonstring’ attribute (17 chars into 16 available)
[-Werror=unterminated-string-initialization]
 1103 | stimer1_root, p_100m_24m, clk_stimer1_root_info,
&clk_scmi_ops_com_critical, rk3576_common_rates, false, true);
      |
                                              ^
plat/rockchip/rk3576/scmi/rk3576_clk.c:246:18: note: in definition of
macro ‘RK3576_SCMI_CLOCK_COM’
  246 |         .name = #_name,
         \
      |                  ^~~~~
plat/rockchip/rk3576/scmi/rk3576_clk.c:1107:155: error:
initializer-string for array of ‘char’ truncates NUL terminator but
destination lacks ‘nonstring’ attribute (17 chars into 16 available)
[-Werror=unterminated-string-initialization]
 1107 | ka_crypto_s, p_350m_175m_116m_24m, clk_pka_crypto_s_info,
&clk_scmi_ops_com, rk3576_common_rates, false, true);
      |
                                              ^
plat/rockchip/rk3576/scmi/rk3576_clk.c:246:18: note: in definition of
macro ‘RK3576_SCMI_CLOCK_COM’
  246 |         .name = #_name,
         \
      |                  ^~~~~
cc1: all warnings being treated as errors
make: *** [Makefile:1644:
/home/alchark/trusted-firmware-a/build/rk3576/release/bl31/rk3576_clk.o]
Error 1

And indeed, clock names such as "clk_stimer0_root" don't leave enough
space in .name for the null terminator (given that .name is defined as
char name[SCMI_CLOCK_NAME_LENGTH_MAX]; a.k.a. 16).

Not sure if the binary BL31 has a similar issue and if it can lead to
the observed weirdness in CPU frequency switching. Looping in XiaoDong
Huang who last touched those lines in the opensource TF-A - any
insights would be much appreciated!

Thanks a lot,
Alexey

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Alexey Charkov]

On Wed, Jun 18, 2025 at 6:48 PM Alexey Charkov <alchark@gmail.com> wrote:
>
> On Wed, Jun 18, 2025 at 6:06 PM Nicolas Frattaroli
> <nicolas.frattaroli@collabora.com> wrote:
> >
> > Hello,
> >
> > +Cc Jonas Karlman as he is intimately familiar with RK3576 clock shenanigans by now,
> >
> > On Wednesday, 18 June 2025 15:51:45 Central European Summer Time Alexey Charkov wrote:
> > > On Sun, Jun 15, 2025 at 8:00 PM Piotr Oniszczuk
> > > <piotr.oniszczuk@gmail.com> wrote:
> > > >
> > > >
> > > >
> > > > > Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 9 cze 2025, o godz. 16:05:
> > > > >
> > > > > On Sun, Jun 8, 2025 at 11:24 AM Piotr Oniszczuk
> > > > > <piotr.oniszczuk@gmail.com> wrote:
> > > > >>> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 5 cze 2025, o godz. 15:42:
> > > > >>>> Alexey,
> > > > >>>> I see you are using rk3576 board like me (nanopi-m5)
> > > > >>>> Have you on your board correctly working cpu dvfs?
> > > > >>>> I mean: [1][desired clocks reported by kernel sysfs are in pair with [2[]cur clocks?
> > > > >>>> In my case i see mine cpu lives totally on it’s own with dvfs:
> > > > >>>
> > > > >>> Hi Piotr,
> > > > >>>
> > > > >>> I haven't tried to validate actual running frequencies vs. requested
> > > > >>> frequencies, but subjective performance and power consumption seem to
> > > > >>> be in line with what I expect.
> > > > >>
> > > > >> well - my subjective l&f is that  - currently - my rk3576 seems „slower" than i.e. 4xA53 h618.
> > > > >
> > > > > In my experience, native compilation of GCC 14 using 8 threads on
> > > > > RK3576 (mainline with passive cooling and throttling enabled): 2 hours
> > > > > 6 minutes, on RK3588 (mainline with passive cooling via Radxa Rock 5B
> > > > > case and throttling enabled but never kicking in): 1 hour 10 minutes
> > > >
> > > > by curiosity i looked randomly on 3576 vs 3588:
> > > > multithread passmark: 3675 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3576&id=6213)
> > > > multithread passmark: 4530 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3588&id=4906)
> > > >
> > > > assuming 3588 as baseline, 3576 is approx 20% slower on multithread passmark (has ~0,8 comp power of 3588)
> > > > 70 min compile on 3588 should take something like ~86min on 3576.
> > > > In your case 126min compile on 3576 shows 3576 offers 0,55 comp power of 3588.
> > > > Roughly 3576 should do this task in 40min less than you currently see i think
> > > >
> > > >
> > > > > Can't see how u-boot would affect CPU speed in Linux, as long as you
> > > > > use comparable ATF images. Do you use the same kernel and dtb in all
> > > > > these cases? Also, what's your thermal setup?
> > > >
> > > > yes. in all cases only change was: uboot & atf
> > > > thermal is based on recent collabora series (+ recent pooling fix for clocks return from throttling)
> > > >
> > > > >
> > > > >
> > > > > Not sure UX is a particularly good measure of CPU performance, as long
> > > > > as you've got a properly accelerated DRM graphics pipeline. More
> > > > > likely 2D/3D and memory.
> > > >
> > > > indeed.
> > > > For quantified look i’m looking on v.simple approach to estimate real clock is http://uob-hpc.github.io/2017/11/22/arm-clock-freq.html
> > > > by curiosity i looked what it reports on a53/a55/a72/a76 and it is surprisingly accurate :-)
> > > > on mine 3576 with collabora uboot+mainline atf is hows 800MHz (and in perf. gov it seems to be constant)
> > > >
> > > > >
> > > > > There might be some difference in how PVTPLL behaves on RK3576 vs.
> > > > > RK3588. But frankly first I would check if you are using comparable
> > > > > ATF implementations (e.g. upstream TF-A in both cases), kernels and
> > > > > thermal environment :)
> > > >
> > > > all tests: the same 6.15.2 mainline + some collabora patches
> > > >
> > > > diffs were:
> > > > 1.collabora uboot[1] + mainline atf 2.13
> > > > 2.collabora uboot[1] + rockchip rkbin bl31 blob
> > > > 3.vendor uboot (bin dump from friendlyelec ubuntu image)
> > > >
> > > > on 1/2 i see kind of issue with clock values (i.e. perf gov gives constant 800MHz on mainline atf).
> > > > 3 seems to perform better - (i.e. perf gov gives constant 1500MHz so all is snappier/faster)
> > >
> > > There is indeed something weird going on. I've tried running sbc-bench
> > > [1], and even though I observe dynamically varying CPU frequencies
> > > after boot with schedutil governor, once sbc-bench switches the
> > > governor to "performance" and goes through the OPPs in descending
> > > frequency order, the CPUs seem to get stuck at the last applied low
> > > frequency. Even after max frequency gets reverted from 408 MHz to
> > > something higher, even after I switch the governor to something else -
> > > no matter what. Only a reboot gets the higher frequencies 'unstuck'
> > > for me.
> > >
> > > These are all observed at around 55C SoC temperature, so throttling is
> > > not an issue. Regulators are stuck at 950000 uV - way above 700000 uV
> > > that the 408 MHz OPP requires (and power readings seem to match: I'm
> > > getting about 2.3W consumption at 408 MHz in idle vs. normal idle
> > > reading of 1.4W at around 1 GHz).
> > >
> > > Not sure what's going on here, and I don't remember seeing anything
> > > similar on RK3588. Thoughts welcome.
> >
> > This may once again be a "accidentally uses wrong clock IDs" type
> > situation. The other possibility is that we're getting confused
> > between what we think the clock rate is and what SCMI actually set
> > the clock rate to.
> >
> > Things to check is whether the right clock controller (scmi vs cru)
> > and the right clock id (check ATF source for this) is used.
>
> Clock IDs in the kernel seem to match those in ATF, but I've noticed
> what appears to be a buffer overflow in some of the SCMI clock names
> defined in the opensource TF-A (thanks GCC 15 and its zealous
> warnings):

After some more testing, I tend to confirm what Piotr observed
earlier. Namely, frequency scaling acts weird on any ATF version (be
it binary BL31 or opensource TF-A), as long as mainline u-boot is
used. Using the u-boot binary extracted from the ArmSoM QWRT image
does not lead to "stuck" CPU frequencies when running sbc-bench.

I'm getting this with the exact same kernel build (6.16-rc1 with some
Sige5 related patches, namely v2 of this series, Nicolas' USB
enablement series and TSADC). The only other difference is that the
binary u-boot doesn't have EFI support, so I had to boot into the
ARM64 uncompressed Image instead of vmlinuz.efi, but those were both
taken from the same build.

What I'm observing during the sbc-bench run:
 - It switches the cpufreq governor from schedutil to performance
 - It goes through all CPU OPPs in descending frequency order
 --- While it does that when booted using mainline u-boot +
vmlinuz.efi: "hardware limits" line in "cpupower -c 0,4
frequency-info" changes with each OPP change (the max frequency
getting reduced sequentially), then it resets to the initial full
range, but the actual frequency stays stuck at the lowest possible
value
 --- While it does that when booted using binary u-boot + Image:
"hardware limits" line in "cpupower -c 0,4 frequency-info" doesn't
change, but the actual frequency gets reduced sequentially. Then after
the iteration over all OPPs is completed it returns to the highest
possible value, and adjusts dynamically based on thermal throttling as
the benchmark progresses

So it seems that it's not really linked to SCMI clocks or PVTPLL per
se, but rather what the binary u-boot configures differently vs.
mainline before the kernel takes over, or something in other firmware
services that the binary u-boot provides (?)

I'm wondering if there is any clock related functionality in the
OP-TEE? I didn't have any OP-TEE image in my mainline u-boot builds
(frankly, I don't even know where to grab one), but the binary u-boot
from ArmSoM advertises the following:

I/TC: OP-TEE version: 3.13.0-791-g185dc3c92 #hisping.lin (gcc version
10.2.1 20201103 (GNU Toolchain for the A-profile Architecture
10.2-2020.11 (arm-10.16))) #2 Tue Apr 16 11:05:25 CST 2024 aarch64,
fwver: v1.01

Any thoughts would be much appreciated.

Best regards,
Alexey

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Alexey Charkov]

On Fri, Jun 20, 2025 at 8:02 PM Alexey Charkov <alchark@gmail.com> wrote:
>
> On Wed, Jun 18, 2025 at 6:48 PM Alexey Charkov <alchark@gmail.com> wrote:
> >
> > On Wed, Jun 18, 2025 at 6:06 PM Nicolas Frattaroli
> > <nicolas.frattaroli@collabora.com> wrote:
> > >
> > > Hello,
> > >
> > > +Cc Jonas Karlman as he is intimately familiar with RK3576 clock shenanigans by now,
> > >
> > > On Wednesday, 18 June 2025 15:51:45 Central European Summer Time Alexey Charkov wrote:
> > > > On Sun, Jun 15, 2025 at 8:00 PM Piotr Oniszczuk
> > > > <piotr.oniszczuk@gmail.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > > > Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 9 cze 2025, o godz. 16:05:
> > > > > >
> > > > > > On Sun, Jun 8, 2025 at 11:24 AM Piotr Oniszczuk
> > > > > > <piotr.oniszczuk@gmail.com> wrote:
> > > > > >>> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 5 cze 2025, o godz. 15:42:
> > > > > >>>> Alexey,
> > > > > >>>> I see you are using rk3576 board like me (nanopi-m5)
> > > > > >>>> Have you on your board correctly working cpu dvfs?
> > > > > >>>> I mean: [1][desired clocks reported by kernel sysfs are in pair with [2[]cur clocks?
> > > > > >>>> In my case i see mine cpu lives totally on it’s own with dvfs:
> > > > > >>>
> > > > > >>> Hi Piotr,
> > > > > >>>
> > > > > >>> I haven't tried to validate actual running frequencies vs. requested
> > > > > >>> frequencies, but subjective performance and power consumption seem to
> > > > > >>> be in line with what I expect.
> > > > > >>
> > > > > >> well - my subjective l&f is that  - currently - my rk3576 seems „slower" than i.e. 4xA53 h618.
> > > > > >
> > > > > > In my experience, native compilation of GCC 14 using 8 threads on
> > > > > > RK3576 (mainline with passive cooling and throttling enabled): 2 hours
> > > > > > 6 minutes, on RK3588 (mainline with passive cooling via Radxa Rock 5B
> > > > > > case and throttling enabled but never kicking in): 1 hour 10 minutes
> > > > >
> > > > > by curiosity i looked randomly on 3576 vs 3588:
> > > > > multithread passmark: 3675 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3576&id=6213)
> > > > > multithread passmark: 4530 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3588&id=4906)
> > > > >
> > > > > assuming 3588 as baseline, 3576 is approx 20% slower on multithread passmark (has ~0,8 comp power of 3588)
> > > > > 70 min compile on 3588 should take something like ~86min on 3576.
> > > > > In your case 126min compile on 3576 shows 3576 offers 0,55 comp power of 3588.
> > > > > Roughly 3576 should do this task in 40min less than you currently see i think
> > > > >
> > > > >
> > > > > > Can't see how u-boot would affect CPU speed in Linux, as long as you
> > > > > > use comparable ATF images. Do you use the same kernel and dtb in all
> > > > > > these cases? Also, what's your thermal setup?
> > > > >
> > > > > yes. in all cases only change was: uboot & atf
> > > > > thermal is based on recent collabora series (+ recent pooling fix for clocks return from throttling)
> > > > >
> > > > > >
> > > > > >
> > > > > > Not sure UX is a particularly good measure of CPU performance, as long
> > > > > > as you've got a properly accelerated DRM graphics pipeline. More
> > > > > > likely 2D/3D and memory.
> > > > >
> > > > > indeed.
> > > > > For quantified look i’m looking on v.simple approach to estimate real clock is http://uob-hpc.github.io/2017/11/22/arm-clock-freq.html
> > > > > by curiosity i looked what it reports on a53/a55/a72/a76 and it is surprisingly accurate :-)
> > > > > on mine 3576 with collabora uboot+mainline atf is hows 800MHz (and in perf. gov it seems to be constant)
> > > > >
> > > > > >
> > > > > > There might be some difference in how PVTPLL behaves on RK3576 vs.
> > > > > > RK3588. But frankly first I would check if you are using comparable
> > > > > > ATF implementations (e.g. upstream TF-A in both cases), kernels and
> > > > > > thermal environment :)
> > > > >
> > > > > all tests: the same 6.15.2 mainline + some collabora patches
> > > > >
> > > > > diffs were:
> > > > > 1.collabora uboot[1] + mainline atf 2.13
> > > > > 2.collabora uboot[1] + rockchip rkbin bl31 blob
> > > > > 3.vendor uboot (bin dump from friendlyelec ubuntu image)
> > > > >
> > > > > on 1/2 i see kind of issue with clock values (i.e. perf gov gives constant 800MHz on mainline atf).
> > > > > 3 seems to perform better - (i.e. perf gov gives constant 1500MHz so all is snappier/faster)
> > > >
> > > > There is indeed something weird going on. I've tried running sbc-bench
> > > > [1], and even though I observe dynamically varying CPU frequencies
> > > > after boot with schedutil governor, once sbc-bench switches the
> > > > governor to "performance" and goes through the OPPs in descending
> > > > frequency order, the CPUs seem to get stuck at the last applied low
> > > > frequency. Even after max frequency gets reverted from 408 MHz to
> > > > something higher, even after I switch the governor to something else -
> > > > no matter what. Only a reboot gets the higher frequencies 'unstuck'
> > > > for me.
> > > >
> > > > These are all observed at around 55C SoC temperature, so throttling is
> > > > not an issue. Regulators are stuck at 950000 uV - way above 700000 uV
> > > > that the 408 MHz OPP requires (and power readings seem to match: I'm
> > > > getting about 2.3W consumption at 408 MHz in idle vs. normal idle
> > > > reading of 1.4W at around 1 GHz).
> > > >
> > > > Not sure what's going on here, and I don't remember seeing anything
> > > > similar on RK3588. Thoughts welcome.
> > >
> > > This may once again be a "accidentally uses wrong clock IDs" type
> > > situation. The other possibility is that we're getting confused
> > > between what we think the clock rate is and what SCMI actually set
> > > the clock rate to.
> > >
> > > Things to check is whether the right clock controller (scmi vs cru)
> > > and the right clock id (check ATF source for this) is used.
> >
> > Clock IDs in the kernel seem to match those in ATF, but I've noticed
> > what appears to be a buffer overflow in some of the SCMI clock names
> > defined in the opensource TF-A (thanks GCC 15 and its zealous
> > warnings):
>
> After some more testing, I tend to confirm what Piotr observed
> earlier. Namely, frequency scaling acts weird on any ATF version (be
> it binary BL31 or opensource TF-A), as long as mainline u-boot is
> used. Using the u-boot binary extracted from the ArmSoM QWRT image
> does not lead to "stuck" CPU frequencies when running sbc-bench.
>
> I'm getting this with the exact same kernel build (6.16-rc1 with some
> Sige5 related patches, namely v2 of this series, Nicolas' USB
> enablement series and TSADC). The only other difference is that the
> binary u-boot doesn't have EFI support, so I had to boot into the
> ARM64 uncompressed Image instead of vmlinuz.efi, but those were both
> taken from the same build.
>
> What I'm observing during the sbc-bench run:
>  - It switches the cpufreq governor from schedutil to performance
>  - It goes through all CPU OPPs in descending frequency order
>  --- While it does that when booted using mainline u-boot +
> vmlinuz.efi: "hardware limits" line in "cpupower -c 0,4
> frequency-info" changes with each OPP change (the max frequency
> getting reduced sequentially), then it resets to the initial full
> range, but the actual frequency stays stuck at the lowest possible
> value
>  --- While it does that when booted using binary u-boot + Image:
> "hardware limits" line in "cpupower -c 0,4 frequency-info" doesn't
> change, but the actual frequency gets reduced sequentially. Then after
> the iteration over all OPPs is completed it returns to the highest
> possible value, and adjusts dynamically based on thermal throttling as
> the benchmark progresses

Slight correction: it's not the "hardware limits" line, but rather
"current policy".

Note that booting mainline u-boot in non-EFI mode (using plain Image)
doesn't change the results above.

> So it seems that it's not really linked to SCMI clocks or PVTPLL per
> se, but rather what the binary u-boot configures differently vs.
> mainline before the kernel takes over, or something in other firmware
> services that the binary u-boot provides (?)
>
> I'm wondering if there is any clock related functionality in the
> OP-TEE? I didn't have any OP-TEE image in my mainline u-boot builds
> (frankly, I don't even know where to grab one), but the binary u-boot
> from ArmSoM advertises the following:
>
> I/TC: OP-TEE version: 3.13.0-791-g185dc3c92 #hisping.lin (gcc version
> 10.2.1 20201103 (GNU Toolchain for the A-profile Architecture
> 10.2-2020.11 (arm-10.16))) #2 Tue Apr 16 11:05:25 CST 2024 aarch64,
> fwver: v1.01

FTR: I've tried to bluntly wrap rk3576_bl32_v1.05.bin into an ELF file
using the following linker script and feed it as $TEE to the mainline
u-boot build, but the resulting u-boot-rockchip.bin gets stuck at boot
after checking hashes of ATF images, so I'm still lost as to how one
can check if the OP-TEE has any influence on the cpufreq behavior.

---
ENTRY(_binary_rk3576_bl32_v1_05_bin_start);

SECTIONS
{
        . = 0x08400000;
        .data : {
                *(.data)
        }
}
---

0x08400000 is the addr listed for BL32 in RK3576TRUST.ini in rkbin.

Best regards,
Alexey

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Heiko Stuebner]

Am Samstag, 21. Juni 2025, 21:35:56 Mitteleuropäische Sommerzeit schrieb Alexey Charkov:
> On Fri, Jun 20, 2025 at 8:02 PM Alexey Charkov <alchark@gmail.com> wrote:
> >
> > On Wed, Jun 18, 2025 at 6:48 PM Alexey Charkov <alchark@gmail.com> wrote:
> > >
> > > On Wed, Jun 18, 2025 at 6:06 PM Nicolas Frattaroli
> > > <nicolas.frattaroli@collabora.com> wrote:
> > > >
> > > > Hello,
> > > >
> > > > +Cc Jonas Karlman as he is intimately familiar with RK3576 clock shenanigans by now,
> > > >
> > > > On Wednesday, 18 June 2025 15:51:45 Central European Summer Time Alexey Charkov wrote:
> > > > > On Sun, Jun 15, 2025 at 8:00 PM Piotr Oniszczuk
> > > > > <piotr.oniszczuk@gmail.com> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > > Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 9 cze 2025, o godz. 16:05:
> > > > > > >
> > > > > > > On Sun, Jun 8, 2025 at 11:24 AM Piotr Oniszczuk
> > > > > > > <piotr.oniszczuk@gmail.com> wrote:
> > > > > > >>> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 5 cze 2025, o godz. 15:42:
> > > > > > >>>> Alexey,
> > > > > > >>>> I see you are using rk3576 board like me (nanopi-m5)
> > > > > > >>>> Have you on your board correctly working cpu dvfs?
> > > > > > >>>> I mean: [1][desired clocks reported by kernel sysfs are in pair with [2[]cur clocks?
> > > > > > >>>> In my case i see mine cpu lives totally on it’s own with dvfs:
> > > > > > >>>
> > > > > > >>> Hi Piotr,
> > > > > > >>>
> > > > > > >>> I haven't tried to validate actual running frequencies vs. requested
> > > > > > >>> frequencies, but subjective performance and power consumption seem to
> > > > > > >>> be in line with what I expect.
> > > > > > >>
> > > > > > >> well - my subjective l&f is that  - currently - my rk3576 seems „slower" than i.e. 4xA53 h618.
> > > > > > >
> > > > > > > In my experience, native compilation of GCC 14 using 8 threads on
> > > > > > > RK3576 (mainline with passive cooling and throttling enabled): 2 hours
> > > > > > > 6 minutes, on RK3588 (mainline with passive cooling via Radxa Rock 5B
> > > > > > > case and throttling enabled but never kicking in): 1 hour 10 minutes
> > > > > >
> > > > > > by curiosity i looked randomly on 3576 vs 3588:
> > > > > > multithread passmark: 3675 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3576&id=6213)
> > > > > > multithread passmark: 4530 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3588&id=4906)
> > > > > >
> > > > > > assuming 3588 as baseline, 3576 is approx 20% slower on multithread passmark (has ~0,8 comp power of 3588)
> > > > > > 70 min compile on 3588 should take something like ~86min on 3576.
> > > > > > In your case 126min compile on 3576 shows 3576 offers 0,55 comp power of 3588.
> > > > > > Roughly 3576 should do this task in 40min less than you currently see i think
> > > > > >
> > > > > >
> > > > > > > Can't see how u-boot would affect CPU speed in Linux, as long as you
> > > > > > > use comparable ATF images. Do you use the same kernel and dtb in all
> > > > > > > these cases? Also, what's your thermal setup?
> > > > > >
> > > > > > yes. in all cases only change was: uboot & atf
> > > > > > thermal is based on recent collabora series (+ recent pooling fix for clocks return from throttling)
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Not sure UX is a particularly good measure of CPU performance, as long
> > > > > > > as you've got a properly accelerated DRM graphics pipeline. More
> > > > > > > likely 2D/3D and memory.
> > > > > >
> > > > > > indeed.
> > > > > > For quantified look i’m looking on v.simple approach to estimate real clock is http://uob-hpc.github.io/2017/11/22/arm-clock-freq.html
> > > > > > by curiosity i looked what it reports on a53/a55/a72/a76 and it is surprisingly accurate :-)
> > > > > > on mine 3576 with collabora uboot+mainline atf is hows 800MHz (and in perf. gov it seems to be constant)
> > > > > >
> > > > > > >
> > > > > > > There might be some difference in how PVTPLL behaves on RK3576 vs.
> > > > > > > RK3588. But frankly first I would check if you are using comparable
> > > > > > > ATF implementations (e.g. upstream TF-A in both cases), kernels and
> > > > > > > thermal environment :)
> > > > > >
> > > > > > all tests: the same 6.15.2 mainline + some collabora patches
> > > > > >
> > > > > > diffs were:
> > > > > > 1.collabora uboot[1] + mainline atf 2.13
> > > > > > 2.collabora uboot[1] + rockchip rkbin bl31 blob
> > > > > > 3.vendor uboot (bin dump from friendlyelec ubuntu image)
> > > > > >
> > > > > > on 1/2 i see kind of issue with clock values (i.e. perf gov gives constant 800MHz on mainline atf).
> > > > > > 3 seems to perform better - (i.e. perf gov gives constant 1500MHz so all is snappier/faster)
> > > > >
> > > > > There is indeed something weird going on. I've tried running sbc-bench
> > > > > [1], and even though I observe dynamically varying CPU frequencies
> > > > > after boot with schedutil governor, once sbc-bench switches the
> > > > > governor to "performance" and goes through the OPPs in descending
> > > > > frequency order, the CPUs seem to get stuck at the last applied low
> > > > > frequency. Even after max frequency gets reverted from 408 MHz to
> > > > > something higher, even after I switch the governor to something else -
> > > > > no matter what. Only a reboot gets the higher frequencies 'unstuck'
> > > > > for me.
> > > > >
> > > > > These are all observed at around 55C SoC temperature, so throttling is
> > > > > not an issue. Regulators are stuck at 950000 uV - way above 700000 uV
> > > > > that the 408 MHz OPP requires (and power readings seem to match: I'm
> > > > > getting about 2.3W consumption at 408 MHz in idle vs. normal idle
> > > > > reading of 1.4W at around 1 GHz).
> > > > >
> > > > > Not sure what's going on here, and I don't remember seeing anything
> > > > > similar on RK3588. Thoughts welcome.
> > > >
> > > > This may once again be a "accidentally uses wrong clock IDs" type
> > > > situation. The other possibility is that we're getting confused
> > > > between what we think the clock rate is and what SCMI actually set
> > > > the clock rate to.
> > > >
> > > > Things to check is whether the right clock controller (scmi vs cru)
> > > > and the right clock id (check ATF source for this) is used.
> > >
> > > Clock IDs in the kernel seem to match those in ATF, but I've noticed
> > > what appears to be a buffer overflow in some of the SCMI clock names
> > > defined in the opensource TF-A (thanks GCC 15 and its zealous
> > > warnings):
> >
> > After some more testing, I tend to confirm what Piotr observed
> > earlier. Namely, frequency scaling acts weird on any ATF version (be
> > it binary BL31 or opensource TF-A), as long as mainline u-boot is
> > used. Using the u-boot binary extracted from the ArmSoM QWRT image
> > does not lead to "stuck" CPU frequencies when running sbc-bench.
> >
> > I'm getting this with the exact same kernel build (6.16-rc1 with some
> > Sige5 related patches, namely v2 of this series, Nicolas' USB
> > enablement series and TSADC). The only other difference is that the
> > binary u-boot doesn't have EFI support, so I had to boot into the
> > ARM64 uncompressed Image instead of vmlinuz.efi, but those were both
> > taken from the same build.
> >
> > What I'm observing during the sbc-bench run:
> >  - It switches the cpufreq governor from schedutil to performance
> >  - It goes through all CPU OPPs in descending frequency order
> >  --- While it does that when booted using mainline u-boot +
> > vmlinuz.efi: "hardware limits" line in "cpupower -c 0,4
> > frequency-info" changes with each OPP change (the max frequency
> > getting reduced sequentially), then it resets to the initial full
> > range, but the actual frequency stays stuck at the lowest possible
> > value
> >  --- While it does that when booted using binary u-boot + Image:
> > "hardware limits" line in "cpupower -c 0,4 frequency-info" doesn't
> > change, but the actual frequency gets reduced sequentially. Then after
> > the iteration over all OPPs is completed it returns to the highest
> > possible value, and adjusts dynamically based on thermal throttling as
> > the benchmark progresses
> 
> Slight correction: it's not the "hardware limits" line, but rather
> "current policy".
> 
> Note that booting mainline u-boot in non-EFI mode (using plain Image)
> doesn't change the results above.

I'm in a similar boat, while trying to make DSI run on the rk3576.
Andy from Rockchip was able to make it work "just" by using vendor-
firmware - while using mainline u-boot (with both mainline TF-A
or vendor TF-A) produces just black output.

I think when I did the mainline u-boot thing I took the "vendor"-code
from the armbian rk3576 vendor-u-boot ... but that actually may differ
from what the vendors provided?

Because at least looking at that code did not show any clock differences
to me.


> > So it seems that it's not really linked to SCMI clocks or PVTPLL per
> > se, but rather what the binary u-boot configures differently vs.
> > mainline before the kernel takes over, or something in other firmware
> > services that the binary u-boot provides (?)
> >
> > I'm wondering if there is any clock related functionality in the
> > OP-TEE? I didn't have any OP-TEE image in my mainline u-boot builds
> > (frankly, I don't even know where to grab one), but the binary u-boot
> > from ArmSoM advertises the following:
> >
> > I/TC: OP-TEE version: 3.13.0-791-g185dc3c92 #hisping.lin (gcc version
> > 10.2.1 20201103 (GNU Toolchain for the A-profile Architecture
> > 10.2-2020.11 (arm-10.16))) #2 Tue Apr 16 11:05:25 CST 2024 aarch64,
> > fwver: v1.01
> 
> FTR: I've tried to bluntly wrap rk3576_bl32_v1.05.bin into an ELF file
> using the following linker script and feed it as $TEE to the mainline
> u-boot build, but the resulting u-boot-rockchip.bin gets stuck at boot
> after checking hashes of ATF images, so I'm still lost as to how one
> can check if the OP-TEE has any influence on the cpufreq behavior.
> 
> ---
> ENTRY(_binary_rk3576_bl32_v1_05_bin_start);
> 
> SECTIONS
> {
>         . = 0x08400000;
>         .data : {
>                 *(.data)
>         }
> }
> ---
> 
> 0x08400000 is the addr listed for BL32 in RK3576TRUST.ini in rkbin.
> 
> Best regards,
> Alexey
> 

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Alexey Charkov]

On Sat, Jun 21, 2025 at 11:44 PM Heiko Stuebner <heiko@sntech.de> wrote:
>
> Am Samstag, 21. Juni 2025, 21:35:56 Mitteleuropäische Sommerzeit schrieb Alexey Charkov:
> > On Fri, Jun 20, 2025 at 8:02 PM Alexey Charkov <alchark@gmail.com> wrote:
> > >
> > > On Wed, Jun 18, 2025 at 6:48 PM Alexey Charkov <alchark@gmail.com> wrote:
> > > >
> > > > On Wed, Jun 18, 2025 at 6:06 PM Nicolas Frattaroli
> > > > <nicolas.frattaroli@collabora.com> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > +Cc Jonas Karlman as he is intimately familiar with RK3576 clock shenanigans by now,
> > > > >
> > > > > On Wednesday, 18 June 2025 15:51:45 Central European Summer Time Alexey Charkov wrote:
> > > > > > On Sun, Jun 15, 2025 at 8:00 PM Piotr Oniszczuk
> > > > > > <piotr.oniszczuk@gmail.com> wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 9 cze 2025, o godz. 16:05:
> > > > > > > >
> > > > > > > > On Sun, Jun 8, 2025 at 11:24 AM Piotr Oniszczuk
> > > > > > > > <piotr.oniszczuk@gmail.com> wrote:
> > > > > > > >>> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 5 cze 2025, o godz. 15:42:
> > > > > > > >>>> Alexey,
> > > > > > > >>>> I see you are using rk3576 board like me (nanopi-m5)
> > > > > > > >>>> Have you on your board correctly working cpu dvfs?
> > > > > > > >>>> I mean: [1][desired clocks reported by kernel sysfs are in pair with [2[]cur clocks?
> > > > > > > >>>> In my case i see mine cpu lives totally on it’s own with dvfs:
> > > > > > > >>>
> > > > > > > >>> Hi Piotr,
> > > > > > > >>>
> > > > > > > >>> I haven't tried to validate actual running frequencies vs. requested
> > > > > > > >>> frequencies, but subjective performance and power consumption seem to
> > > > > > > >>> be in line with what I expect.
> > > > > > > >>
> > > > > > > >> well - my subjective l&f is that  - currently - my rk3576 seems „slower" than i.e. 4xA53 h618.
> > > > > > > >
> > > > > > > > In my experience, native compilation of GCC 14 using 8 threads on
> > > > > > > > RK3576 (mainline with passive cooling and throttling enabled): 2 hours
> > > > > > > > 6 minutes, on RK3588 (mainline with passive cooling via Radxa Rock 5B
> > > > > > > > case and throttling enabled but never kicking in): 1 hour 10 minutes
> > > > > > >
> > > > > > > by curiosity i looked randomly on 3576 vs 3588:
> > > > > > > multithread passmark: 3675 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3576&id=6213)
> > > > > > > multithread passmark: 4530 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3588&id=4906)
> > > > > > >
> > > > > > > assuming 3588 as baseline, 3576 is approx 20% slower on multithread passmark (has ~0,8 comp power of 3588)
> > > > > > > 70 min compile on 3588 should take something like ~86min on 3576.
> > > > > > > In your case 126min compile on 3576 shows 3576 offers 0,55 comp power of 3588.
> > > > > > > Roughly 3576 should do this task in 40min less than you currently see i think
> > > > > > >
> > > > > > >
> > > > > > > > Can't see how u-boot would affect CPU speed in Linux, as long as you
> > > > > > > > use comparable ATF images. Do you use the same kernel and dtb in all
> > > > > > > > these cases? Also, what's your thermal setup?
> > > > > > >
> > > > > > > yes. in all cases only change was: uboot & atf
> > > > > > > thermal is based on recent collabora series (+ recent pooling fix for clocks return from throttling)
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Not sure UX is a particularly good measure of CPU performance, as long
> > > > > > > > as you've got a properly accelerated DRM graphics pipeline. More
> > > > > > > > likely 2D/3D and memory.
> > > > > > >
> > > > > > > indeed.
> > > > > > > For quantified look i’m looking on v.simple approach to estimate real clock is http://uob-hpc.github.io/2017/11/22/arm-clock-freq.html
> > > > > > > by curiosity i looked what it reports on a53/a55/a72/a76 and it is surprisingly accurate :-)
> > > > > > > on mine 3576 with collabora uboot+mainline atf is hows 800MHz (and in perf. gov it seems to be constant)
> > > > > > >
> > > > > > > >
> > > > > > > > There might be some difference in how PVTPLL behaves on RK3576 vs.
> > > > > > > > RK3588. But frankly first I would check if you are using comparable
> > > > > > > > ATF implementations (e.g. upstream TF-A in both cases), kernels and
> > > > > > > > thermal environment :)
> > > > > > >
> > > > > > > all tests: the same 6.15.2 mainline + some collabora patches
> > > > > > >
> > > > > > > diffs were:
> > > > > > > 1.collabora uboot[1] + mainline atf 2.13
> > > > > > > 2.collabora uboot[1] + rockchip rkbin bl31 blob
> > > > > > > 3.vendor uboot (bin dump from friendlyelec ubuntu image)
> > > > > > >
> > > > > > > on 1/2 i see kind of issue with clock values (i.e. perf gov gives constant 800MHz on mainline atf).
> > > > > > > 3 seems to perform better - (i.e. perf gov gives constant 1500MHz so all is snappier/faster)
> > > > > >
> > > > > > There is indeed something weird going on. I've tried running sbc-bench
> > > > > > [1], and even though I observe dynamically varying CPU frequencies
> > > > > > after boot with schedutil governor, once sbc-bench switches the
> > > > > > governor to "performance" and goes through the OPPs in descending
> > > > > > frequency order, the CPUs seem to get stuck at the last applied low
> > > > > > frequency. Even after max frequency gets reverted from 408 MHz to
> > > > > > something higher, even after I switch the governor to something else -
> > > > > > no matter what. Only a reboot gets the higher frequencies 'unstuck'
> > > > > > for me.
> > > > > >
> > > > > > These are all observed at around 55C SoC temperature, so throttling is
> > > > > > not an issue. Regulators are stuck at 950000 uV - way above 700000 uV
> > > > > > that the 408 MHz OPP requires (and power readings seem to match: I'm
> > > > > > getting about 2.3W consumption at 408 MHz in idle vs. normal idle
> > > > > > reading of 1.4W at around 1 GHz).
> > > > > >
> > > > > > Not sure what's going on here, and I don't remember seeing anything
> > > > > > similar on RK3588. Thoughts welcome.
> > > > >
> > > > > This may once again be a "accidentally uses wrong clock IDs" type
> > > > > situation. The other possibility is that we're getting confused
> > > > > between what we think the clock rate is and what SCMI actually set
> > > > > the clock rate to.
> > > > >
> > > > > Things to check is whether the right clock controller (scmi vs cru)
> > > > > and the right clock id (check ATF source for this) is used.
> > > >
> > > > Clock IDs in the kernel seem to match those in ATF, but I've noticed
> > > > what appears to be a buffer overflow in some of the SCMI clock names
> > > > defined in the opensource TF-A (thanks GCC 15 and its zealous
> > > > warnings):
> > >
> > > After some more testing, I tend to confirm what Piotr observed
> > > earlier. Namely, frequency scaling acts weird on any ATF version (be
> > > it binary BL31 or opensource TF-A), as long as mainline u-boot is
> > > used. Using the u-boot binary extracted from the ArmSoM QWRT image
> > > does not lead to "stuck" CPU frequencies when running sbc-bench.
> > >
> > > I'm getting this with the exact same kernel build (6.16-rc1 with some
> > > Sige5 related patches, namely v2 of this series, Nicolas' USB
> > > enablement series and TSADC). The only other difference is that the
> > > binary u-boot doesn't have EFI support, so I had to boot into the
> > > ARM64 uncompressed Image instead of vmlinuz.efi, but those were both
> > > taken from the same build.
> > >
> > > What I'm observing during the sbc-bench run:
> > >  - It switches the cpufreq governor from schedutil to performance
> > >  - It goes through all CPU OPPs in descending frequency order
> > >  --- While it does that when booted using mainline u-boot +
> > > vmlinuz.efi: "hardware limits" line in "cpupower -c 0,4
> > > frequency-info" changes with each OPP change (the max frequency
> > > getting reduced sequentially), then it resets to the initial full
> > > range, but the actual frequency stays stuck at the lowest possible
> > > value
> > >  --- While it does that when booted using binary u-boot + Image:
> > > "hardware limits" line in "cpupower -c 0,4 frequency-info" doesn't
> > > change, but the actual frequency gets reduced sequentially. Then after
> > > the iteration over all OPPs is completed it returns to the highest
> > > possible value, and adjusts dynamically based on thermal throttling as
> > > the benchmark progresses
> >
> > Slight correction: it's not the "hardware limits" line, but rather
> > "current policy".
> >
> > Note that booting mainline u-boot in non-EFI mode (using plain Image)
> > doesn't change the results above.
>
> I'm in a similar boat, while trying to make DSI run on the rk3576.
> Andy from Rockchip was able to make it work "just" by using vendor-
> firmware - while using mainline u-boot (with both mainline TF-A
> or vendor TF-A) produces just black output.
>
> I think when I did the mainline u-boot thing I took the "vendor"-code
> from the armbian rk3576 vendor-u-boot ... but that actually may differ
> from what the vendors provided?

Just tried booting into u-boot built from ArmSoM sources at [1] - same
issues as using mainline. Either I'm doing something stupid building
it (don't know what though), or the binary shipped in ArmSoM images is
indeed different from what the sources are.

FTR, my steps to build the vendor u-boot were:

make rk3576_defconfig
cp ~/rkbin/bin/rk35/rk3576_bl31_v1.15.elf bl31.elf
cp ~/rkbin/bin/rk35/rk3576_bl32_v1.05.bin tee.bin
make -j12
make u-boot.itb
./tools/mkimage -n rk3576 -T rksd -d
~/rkbin/bin/rk35/rk3576_ddr_lp4_2112MHz_lp5_2736MHz_v1.09.bin:spl/u-boot-spl-dtb.bin
idbloader.img

Then I wrote idbloader.img to eMMC starting from sector 64, u-boot.itb
starting from sector 16384. It boots, but exhibits the same "stuck"
CPU frequencies as with mainline u-boot.

FWIW, I've managed to load Rockchip BL32 as OP-TEE with mainline
u-boot too: turns out the right address to load it is 0x48400000 and
not 0x08400000. It didn't help with the problem though.

Best regards,
Alexey

[1] https://github.com/ArmSoM/u-boot/tree/rk3576-6.1-rk3.1

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Heiko Stuebner]

Am Samstag, 21. Juni 2025, 23:21:11 Mitteleuropäische Sommerzeit schrieb Alexey Charkov:
> On Sat, Jun 21, 2025 at 11:44 PM Heiko Stuebner <heiko@sntech.de> wrote:
> >
> > Am Samstag, 21. Juni 2025, 21:35:56 Mitteleuropäische Sommerzeit schrieb Alexey Charkov:
> > > On Fri, Jun 20, 2025 at 8:02 PM Alexey Charkov <alchark@gmail.com> wrote:
> > > >
> > > > On Wed, Jun 18, 2025 at 6:48 PM Alexey Charkov <alchark@gmail.com> wrote:
> > > > >
> > > > > On Wed, Jun 18, 2025 at 6:06 PM Nicolas Frattaroli
> > > > > <nicolas.frattaroli@collabora.com> wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > +Cc Jonas Karlman as he is intimately familiar with RK3576 clock shenanigans by now,
> > > > > >
> > > > > > On Wednesday, 18 June 2025 15:51:45 Central European Summer Time Alexey Charkov wrote:
> > > > > > > On Sun, Jun 15, 2025 at 8:00 PM Piotr Oniszczuk
> > > > > > > <piotr.oniszczuk@gmail.com> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > > Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 9 cze 2025, o godz. 16:05:
> > > > > > > > >
> > > > > > > > > On Sun, Jun 8, 2025 at 11:24 AM Piotr Oniszczuk
> > > > > > > > > <piotr.oniszczuk@gmail.com> wrote:
> > > > > > > > >>> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 5 cze 2025, o godz. 15:42:
> > > > > > > > >>>> Alexey,
> > > > > > > > >>>> I see you are using rk3576 board like me (nanopi-m5)
> > > > > > > > >>>> Have you on your board correctly working cpu dvfs?
> > > > > > > > >>>> I mean: [1][desired clocks reported by kernel sysfs are in pair with [2[]cur clocks?
> > > > > > > > >>>> In my case i see mine cpu lives totally on it’s own with dvfs:
> > > > > > > > >>>
> > > > > > > > >>> Hi Piotr,
> > > > > > > > >>>
> > > > > > > > >>> I haven't tried to validate actual running frequencies vs. requested
> > > > > > > > >>> frequencies, but subjective performance and power consumption seem to
> > > > > > > > >>> be in line with what I expect.
> > > > > > > > >>
> > > > > > > > >> well - my subjective l&f is that  - currently - my rk3576 seems „slower" than i.e. 4xA53 h618.
> > > > > > > > >
> > > > > > > > > In my experience, native compilation of GCC 14 using 8 threads on
> > > > > > > > > RK3576 (mainline with passive cooling and throttling enabled): 2 hours
> > > > > > > > > 6 minutes, on RK3588 (mainline with passive cooling via Radxa Rock 5B
> > > > > > > > > case and throttling enabled but never kicking in): 1 hour 10 minutes
> > > > > > > >
> > > > > > > > by curiosity i looked randomly on 3576 vs 3588:
> > > > > > > > multithread passmark: 3675 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3576&id=6213)
> > > > > > > > multithread passmark: 4530 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3588&id=4906)
> > > > > > > >
> > > > > > > > assuming 3588 as baseline, 3576 is approx 20% slower on multithread passmark (has ~0,8 comp power of 3588)
> > > > > > > > 70 min compile on 3588 should take something like ~86min on 3576.
> > > > > > > > In your case 126min compile on 3576 shows 3576 offers 0,55 comp power of 3588.
> > > > > > > > Roughly 3576 should do this task in 40min less than you currently see i think
> > > > > > > >
> > > > > > > >
> > > > > > > > > Can't see how u-boot would affect CPU speed in Linux, as long as you
> > > > > > > > > use comparable ATF images. Do you use the same kernel and dtb in all
> > > > > > > > > these cases? Also, what's your thermal setup?
> > > > > > > >
> > > > > > > > yes. in all cases only change was: uboot & atf
> > > > > > > > thermal is based on recent collabora series (+ recent pooling fix for clocks return from throttling)
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Not sure UX is a particularly good measure of CPU performance, as long
> > > > > > > > > as you've got a properly accelerated DRM graphics pipeline. More
> > > > > > > > > likely 2D/3D and memory.
> > > > > > > >
> > > > > > > > indeed.
> > > > > > > > For quantified look i’m looking on v.simple approach to estimate real clock is http://uob-hpc.github.io/2017/11/22/arm-clock-freq.html
> > > > > > > > by curiosity i looked what it reports on a53/a55/a72/a76 and it is surprisingly accurate :-)
> > > > > > > > on mine 3576 with collabora uboot+mainline atf is hows 800MHz (and in perf. gov it seems to be constant)
> > > > > > > >
> > > > > > > > >
> > > > > > > > > There might be some difference in how PVTPLL behaves on RK3576 vs.
> > > > > > > > > RK3588. But frankly first I would check if you are using comparable
> > > > > > > > > ATF implementations (e.g. upstream TF-A in both cases), kernels and
> > > > > > > > > thermal environment :)
> > > > > > > >
> > > > > > > > all tests: the same 6.15.2 mainline + some collabora patches
> > > > > > > >
> > > > > > > > diffs were:
> > > > > > > > 1.collabora uboot[1] + mainline atf 2.13
> > > > > > > > 2.collabora uboot[1] + rockchip rkbin bl31 blob
> > > > > > > > 3.vendor uboot (bin dump from friendlyelec ubuntu image)
> > > > > > > >
> > > > > > > > on 1/2 i see kind of issue with clock values (i.e. perf gov gives constant 800MHz on mainline atf).
> > > > > > > > 3 seems to perform better - (i.e. perf gov gives constant 1500MHz so all is snappier/faster)
> > > > > > >
> > > > > > > There is indeed something weird going on. I've tried running sbc-bench
> > > > > > > [1], and even though I observe dynamically varying CPU frequencies
> > > > > > > after boot with schedutil governor, once sbc-bench switches the
> > > > > > > governor to "performance" and goes through the OPPs in descending
> > > > > > > frequency order, the CPUs seem to get stuck at the last applied low
> > > > > > > frequency. Even after max frequency gets reverted from 408 MHz to
> > > > > > > something higher, even after I switch the governor to something else -
> > > > > > > no matter what. Only a reboot gets the higher frequencies 'unstuck'
> > > > > > > for me.
> > > > > > >
> > > > > > > These are all observed at around 55C SoC temperature, so throttling is
> > > > > > > not an issue. Regulators are stuck at 950000 uV - way above 700000 uV
> > > > > > > that the 408 MHz OPP requires (and power readings seem to match: I'm
> > > > > > > getting about 2.3W consumption at 408 MHz in idle vs. normal idle
> > > > > > > reading of 1.4W at around 1 GHz).
> > > > > > >
> > > > > > > Not sure what's going on here, and I don't remember seeing anything
> > > > > > > similar on RK3588. Thoughts welcome.
> > > > > >
> > > > > > This may once again be a "accidentally uses wrong clock IDs" type
> > > > > > situation. The other possibility is that we're getting confused
> > > > > > between what we think the clock rate is and what SCMI actually set
> > > > > > the clock rate to.
> > > > > >
> > > > > > Things to check is whether the right clock controller (scmi vs cru)
> > > > > > and the right clock id (check ATF source for this) is used.
> > > > >
> > > > > Clock IDs in the kernel seem to match those in ATF, but I've noticed
> > > > > what appears to be a buffer overflow in some of the SCMI clock names
> > > > > defined in the opensource TF-A (thanks GCC 15 and its zealous
> > > > > warnings):
> > > >
> > > > After some more testing, I tend to confirm what Piotr observed
> > > > earlier. Namely, frequency scaling acts weird on any ATF version (be
> > > > it binary BL31 or opensource TF-A), as long as mainline u-boot is
> > > > used. Using the u-boot binary extracted from the ArmSoM QWRT image
> > > > does not lead to "stuck" CPU frequencies when running sbc-bench.
> > > >
> > > > I'm getting this with the exact same kernel build (6.16-rc1 with some
> > > > Sige5 related patches, namely v2 of this series, Nicolas' USB
> > > > enablement series and TSADC). The only other difference is that the
> > > > binary u-boot doesn't have EFI support, so I had to boot into the
> > > > ARM64 uncompressed Image instead of vmlinuz.efi, but those were both
> > > > taken from the same build.
> > > >
> > > > What I'm observing during the sbc-bench run:
> > > >  - It switches the cpufreq governor from schedutil to performance
> > > >  - It goes through all CPU OPPs in descending frequency order
> > > >  --- While it does that when booted using mainline u-boot +
> > > > vmlinuz.efi: "hardware limits" line in "cpupower -c 0,4
> > > > frequency-info" changes with each OPP change (the max frequency
> > > > getting reduced sequentially), then it resets to the initial full
> > > > range, but the actual frequency stays stuck at the lowest possible
> > > > value
> > > >  --- While it does that when booted using binary u-boot + Image:
> > > > "hardware limits" line in "cpupower -c 0,4 frequency-info" doesn't
> > > > change, but the actual frequency gets reduced sequentially. Then after
> > > > the iteration over all OPPs is completed it returns to the highest
> > > > possible value, and adjusts dynamically based on thermal throttling as
> > > > the benchmark progresses
> > >
> > > Slight correction: it's not the "hardware limits" line, but rather
> > > "current policy".
> > >
> > > Note that booting mainline u-boot in non-EFI mode (using plain Image)
> > > doesn't change the results above.
> >
> > I'm in a similar boat, while trying to make DSI run on the rk3576.
> > Andy from Rockchip was able to make it work "just" by using vendor-
> > firmware - while using mainline u-boot (with both mainline TF-A
> > or vendor TF-A) produces just black output.
> >
> > I think when I did the mainline u-boot thing I took the "vendor"-code
> > from the armbian rk3576 vendor-u-boot ... but that actually may differ
> > from what the vendors provided?
> 
> Just tried booting into u-boot built from ArmSoM sources at [1] - same
> issues as using mainline. Either I'm doing something stupid building
> it (don't know what though), or the binary shipped in ArmSoM images is
> indeed different from what the sources are.

Can you list the versions you see for the _working_ binaries?

I.e. u-boot and friends may list someversion-gGITHASH thingy like your
OPTEE already does: OP-TEE version: 3.13.0-791-g185dc3c92 .
Also possibly the build date.

I.e. I'm wondering/hoping if we can match to some git commit.


Heiko


> 
> FTR, my steps to build the vendor u-boot were:
> 
> make rk3576_defconfig
> cp ~/rkbin/bin/rk35/rk3576_bl31_v1.15.elf bl31.elf
> cp ~/rkbin/bin/rk35/rk3576_bl32_v1.05.bin tee.bin
> make -j12
> make u-boot.itb
> ./tools/mkimage -n rk3576 -T rksd -d
> ~/rkbin/bin/rk35/rk3576_ddr_lp4_2112MHz_lp5_2736MHz_v1.09.bin:spl/u-boot-spl-dtb.bin
> idbloader.img
> 
> Then I wrote idbloader.img to eMMC starting from sector 64, u-boot.itb
> starting from sector 16384. It boots, but exhibits the same "stuck"
> CPU frequencies as with mainline u-boot.
> 
> FWIW, I've managed to load Rockchip BL32 as OP-TEE with mainline
> u-boot too: turns out the right address to load it is 0x48400000 and
> not 0x08400000. It didn't help with the problem though.
> 
> Best regards,
> Alexey
> 
> [1] https://github.com/ArmSoM/u-boot/tree/rk3576-6.1-rk3.1
> 

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Alexey Charkov]

On Sun, Jun 22, 2025 at 5:48 PM Heiko Stuebner <heiko@sntech.de> wrote:
>
> Am Samstag, 21. Juni 2025, 23:21:11 Mitteleuropäische Sommerzeit schrieb Alexey Charkov:
> > On Sat, Jun 21, 2025 at 11:44 PM Heiko Stuebner <heiko@sntech.de> wrote:
> > >
> > > Am Samstag, 21. Juni 2025, 21:35:56 Mitteleuropäische Sommerzeit schrieb Alexey Charkov:
> > > > On Fri, Jun 20, 2025 at 8:02 PM Alexey Charkov <alchark@gmail.com> wrote:
> > > > >
> > > > > On Wed, Jun 18, 2025 at 6:48 PM Alexey Charkov <alchark@gmail.com> wrote:
> > > > > >
> > > > > > On Wed, Jun 18, 2025 at 6:06 PM Nicolas Frattaroli
> > > > > > <nicolas.frattaroli@collabora.com> wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > +Cc Jonas Karlman as he is intimately familiar with RK3576 clock shenanigans by now,
> > > > > > >
> > > > > > > On Wednesday, 18 June 2025 15:51:45 Central European Summer Time Alexey Charkov wrote:
> > > > > > > > On Sun, Jun 15, 2025 at 8:00 PM Piotr Oniszczuk
> > > > > > > > <piotr.oniszczuk@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 9 cze 2025, o godz. 16:05:
> > > > > > > > > >
> > > > > > > > > > On Sun, Jun 8, 2025 at 11:24 AM Piotr Oniszczuk
> > > > > > > > > > <piotr.oniszczuk@gmail.com> wrote:
> > > > > > > > > >>> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 5 cze 2025, o godz. 15:42:
> > > > > > > > > >>>> Alexey,
> > > > > > > > > >>>> I see you are using rk3576 board like me (nanopi-m5)
> > > > > > > > > >>>> Have you on your board correctly working cpu dvfs?
> > > > > > > > > >>>> I mean: [1][desired clocks reported by kernel sysfs are in pair with [2[]cur clocks?
> > > > > > > > > >>>> In my case i see mine cpu lives totally on it’s own with dvfs:
> > > > > > > > > >>>
> > > > > > > > > >>> Hi Piotr,
> > > > > > > > > >>>
> > > > > > > > > >>> I haven't tried to validate actual running frequencies vs. requested
> > > > > > > > > >>> frequencies, but subjective performance and power consumption seem to
> > > > > > > > > >>> be in line with what I expect.
> > > > > > > > > >>
> > > > > > > > > >> well - my subjective l&f is that  - currently - my rk3576 seems „slower" than i.e. 4xA53 h618.
> > > > > > > > > >
> > > > > > > > > > In my experience, native compilation of GCC 14 using 8 threads on
> > > > > > > > > > RK3576 (mainline with passive cooling and throttling enabled): 2 hours
> > > > > > > > > > 6 minutes, on RK3588 (mainline with passive cooling via Radxa Rock 5B
> > > > > > > > > > case and throttling enabled but never kicking in): 1 hour 10 minutes
> > > > > > > > >
> > > > > > > > > by curiosity i looked randomly on 3576 vs 3588:
> > > > > > > > > multithread passmark: 3675 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3576&id=6213)
> > > > > > > > > multithread passmark: 4530 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3588&id=4906)
> > > > > > > > >
> > > > > > > > > assuming 3588 as baseline, 3576 is approx 20% slower on multithread passmark (has ~0,8 comp power of 3588)
> > > > > > > > > 70 min compile on 3588 should take something like ~86min on 3576.
> > > > > > > > > In your case 126min compile on 3576 shows 3576 offers 0,55 comp power of 3588.
> > > > > > > > > Roughly 3576 should do this task in 40min less than you currently see i think
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > Can't see how u-boot would affect CPU speed in Linux, as long as you
> > > > > > > > > > use comparable ATF images. Do you use the same kernel and dtb in all
> > > > > > > > > > these cases? Also, what's your thermal setup?
> > > > > > > > >
> > > > > > > > > yes. in all cases only change was: uboot & atf
> > > > > > > > > thermal is based on recent collabora series (+ recent pooling fix for clocks return from throttling)
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Not sure UX is a particularly good measure of CPU performance, as long
> > > > > > > > > > as you've got a properly accelerated DRM graphics pipeline. More
> > > > > > > > > > likely 2D/3D and memory.
> > > > > > > > >
> > > > > > > > > indeed.
> > > > > > > > > For quantified look i’m looking on v.simple approach to estimate real clock is http://uob-hpc.github.io/2017/11/22/arm-clock-freq.html
> > > > > > > > > by curiosity i looked what it reports on a53/a55/a72/a76 and it is surprisingly accurate :-)
> > > > > > > > > on mine 3576 with collabora uboot+mainline atf is hows 800MHz (and in perf. gov it seems to be constant)
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > There might be some difference in how PVTPLL behaves on RK3576 vs.
> > > > > > > > > > RK3588. But frankly first I would check if you are using comparable
> > > > > > > > > > ATF implementations (e.g. upstream TF-A in both cases), kernels and
> > > > > > > > > > thermal environment :)
> > > > > > > > >
> > > > > > > > > all tests: the same 6.15.2 mainline + some collabora patches
> > > > > > > > >
> > > > > > > > > diffs were:
> > > > > > > > > 1.collabora uboot[1] + mainline atf 2.13
> > > > > > > > > 2.collabora uboot[1] + rockchip rkbin bl31 blob
> > > > > > > > > 3.vendor uboot (bin dump from friendlyelec ubuntu image)
> > > > > > > > >
> > > > > > > > > on 1/2 i see kind of issue with clock values (i.e. perf gov gives constant 800MHz on mainline atf).
> > > > > > > > > 3 seems to perform better - (i.e. perf gov gives constant 1500MHz so all is snappier/faster)
> > > > > > > >
> > > > > > > > There is indeed something weird going on. I've tried running sbc-bench
> > > > > > > > [1], and even though I observe dynamically varying CPU frequencies
> > > > > > > > after boot with schedutil governor, once sbc-bench switches the
> > > > > > > > governor to "performance" and goes through the OPPs in descending
> > > > > > > > frequency order, the CPUs seem to get stuck at the last applied low
> > > > > > > > frequency. Even after max frequency gets reverted from 408 MHz to
> > > > > > > > something higher, even after I switch the governor to something else -
> > > > > > > > no matter what. Only a reboot gets the higher frequencies 'unstuck'
> > > > > > > > for me.
> > > > > > > >
> > > > > > > > These are all observed at around 55C SoC temperature, so throttling is
> > > > > > > > not an issue. Regulators are stuck at 950000 uV - way above 700000 uV
> > > > > > > > that the 408 MHz OPP requires (and power readings seem to match: I'm
> > > > > > > > getting about 2.3W consumption at 408 MHz in idle vs. normal idle
> > > > > > > > reading of 1.4W at around 1 GHz).
> > > > > > > >
> > > > > > > > Not sure what's going on here, and I don't remember seeing anything
> > > > > > > > similar on RK3588. Thoughts welcome.
> > > > > > >
> > > > > > > This may once again be a "accidentally uses wrong clock IDs" type
> > > > > > > situation. The other possibility is that we're getting confused
> > > > > > > between what we think the clock rate is and what SCMI actually set
> > > > > > > the clock rate to.
> > > > > > >
> > > > > > > Things to check is whether the right clock controller (scmi vs cru)
> > > > > > > and the right clock id (check ATF source for this) is used.
> > > > > >
> > > > > > Clock IDs in the kernel seem to match those in ATF, but I've noticed
> > > > > > what appears to be a buffer overflow in some of the SCMI clock names
> > > > > > defined in the opensource TF-A (thanks GCC 15 and its zealous
> > > > > > warnings):
> > > > >
> > > > > After some more testing, I tend to confirm what Piotr observed
> > > > > earlier. Namely, frequency scaling acts weird on any ATF version (be
> > > > > it binary BL31 or opensource TF-A), as long as mainline u-boot is
> > > > > used. Using the u-boot binary extracted from the ArmSoM QWRT image
> > > > > does not lead to "stuck" CPU frequencies when running sbc-bench.
> > > > >
> > > > > I'm getting this with the exact same kernel build (6.16-rc1 with some
> > > > > Sige5 related patches, namely v2 of this series, Nicolas' USB
> > > > > enablement series and TSADC). The only other difference is that the
> > > > > binary u-boot doesn't have EFI support, so I had to boot into the
> > > > > ARM64 uncompressed Image instead of vmlinuz.efi, but those were both
> > > > > taken from the same build.
> > > > >
> > > > > What I'm observing during the sbc-bench run:
> > > > >  - It switches the cpufreq governor from schedutil to performance
> > > > >  - It goes through all CPU OPPs in descending frequency order
> > > > >  --- While it does that when booted using mainline u-boot +
> > > > > vmlinuz.efi: "hardware limits" line in "cpupower -c 0,4
> > > > > frequency-info" changes with each OPP change (the max frequency
> > > > > getting reduced sequentially), then it resets to the initial full
> > > > > range, but the actual frequency stays stuck at the lowest possible
> > > > > value
> > > > >  --- While it does that when booted using binary u-boot + Image:
> > > > > "hardware limits" line in "cpupower -c 0,4 frequency-info" doesn't
> > > > > change, but the actual frequency gets reduced sequentially. Then after
> > > > > the iteration over all OPPs is completed it returns to the highest
> > > > > possible value, and adjusts dynamically based on thermal throttling as
> > > > > the benchmark progresses
> > > >
> > > > Slight correction: it's not the "hardware limits" line, but rather
> > > > "current policy".
> > > >
> > > > Note that booting mainline u-boot in non-EFI mode (using plain Image)
> > > > doesn't change the results above.
> > >
> > > I'm in a similar boat, while trying to make DSI run on the rk3576.
> > > Andy from Rockchip was able to make it work "just" by using vendor-
> > > firmware - while using mainline u-boot (with both mainline TF-A
> > > or vendor TF-A) produces just black output.
> > >
> > > I think when I did the mainline u-boot thing I took the "vendor"-code
> > > from the armbian rk3576 vendor-u-boot ... but that actually may differ
> > > from what the vendors provided?
> >
> > Just tried booting into u-boot built from ArmSoM sources at [1] - same
> > issues as using mainline. Either I'm doing something stupid building
> > it (don't know what though), or the binary shipped in ArmSoM images is
> > indeed different from what the sources are.
>
> Can you list the versions you see for the _working_ binaries?

Those are not as detailed as I'd like, as vendor builds seem to
override the default U-boot versioning rules (stripping the git hash
information off).

I've identified the following versions for the binary image that worked for me:

DDR init v1.03 (version string "DDR 81dd75088a wesley.yao
24/04/16-11:19:41,fwver: v1.03")
U-boot SPL 2017.09 (no traces of any particular git commit, version
string "U-Boot SPL 2017.09 (Aug 23 2024 - 00:47:39)")
U-boot proper 2017.09 (ditto, version string "U-Boot 2017.09 (Aug 23
2024 - 00:47:39 +0000) OpenWrt")
BL31 image v1.04 (version string
"v2.3():v2.3-749-g30018b771:derrick.huang, fwver: v1.04")
BL32 image v1.01 (version string "U3.13.0-791-g185dc3c92 #hisping.lin
(gcc version 10.2.1 20201103 (GNU Toolchain for the A-profile
Architecture 10.2-2020.11 (arm-10.16))) #2 Tue Apr 16 11:05:25 CST
2024 aarch64, fwver: v1.01")

> I.e. u-boot and friends may list someversion-gGITHASH thingy like your
> OPTEE already does: OP-TEE version: 3.13.0-791-g185dc3c92 .
> Also possibly the build date.

The build date is later than any commit I see in the ArmSoM repo
leading up to either of the two tags they have there ("rk3576" and
"rk3576-6.1-rk3.1", neither of them belonging to any published branch
there)

> I.e. I'm wondering/hoping if we can match to some git commit.

I've also noticed that ArmSoM SDK references the "boost" binary from
rkbin (rk3576_boost_v1.00.bin in particular), but it doesn't seem to
be present in the bootloader binary I'm looking at. The version string
of the SPL binary in rkbin as included in the SDK is also different
from what I'm seeing in the actual binary: SDK has "U-Boot SPL
2017.09-g57b8ceed1c3-240418 #lxh (Apr 19 2024 - 17:07:22), fwver:
v1.02".

I'll try and rebuild the vendor u-boot from source with these specific
versions of rkbin blobs (ddr v1.03, bl31 v1.04 and bl32 v1.01), but
the changelog in rkbin didn't mention anything that would seem
relevant to the issue I'm observing :(

Best regards,
Alexey

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Alexey Charkov]

On Mon, Jun 23, 2025 at 1:19 PM Alexey Charkov <alchark@gmail.com> wrote:
>
> On Sun, Jun 22, 2025 at 5:48 PM Heiko Stuebner <heiko@sntech.de> wrote:
> >
> > Am Samstag, 21. Juni 2025, 23:21:11 Mitteleuropäische Sommerzeit schrieb Alexey Charkov:
> > > On Sat, Jun 21, 2025 at 11:44 PM Heiko Stuebner <heiko@sntech.de> wrote:
> > > >
> > > > Am Samstag, 21. Juni 2025, 21:35:56 Mitteleuropäische Sommerzeit schrieb Alexey Charkov:
> > > > > On Fri, Jun 20, 2025 at 8:02 PM Alexey Charkov <alchark@gmail.com> wrote:
> > > > > >
> > > > > > On Wed, Jun 18, 2025 at 6:48 PM Alexey Charkov <alchark@gmail.com> wrote:
> > > > > > >
> > > > > > > On Wed, Jun 18, 2025 at 6:06 PM Nicolas Frattaroli
> > > > > > > <nicolas.frattaroli@collabora.com> wrote:
> > > > > > > >
> > > > > > > > Hello,
> > > > > > > >
> > > > > > > > +Cc Jonas Karlman as he is intimately familiar with RK3576 clock shenanigans by now,
> > > > > > > >
> > > > > > > > On Wednesday, 18 June 2025 15:51:45 Central European Summer Time Alexey Charkov wrote:
> > > > > > > > > On Sun, Jun 15, 2025 at 8:00 PM Piotr Oniszczuk
> > > > > > > > > <piotr.oniszczuk@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 9 cze 2025, o godz. 16:05:
> > > > > > > > > > >
> > > > > > > > > > > On Sun, Jun 8, 2025 at 11:24 AM Piotr Oniszczuk
> > > > > > > > > > > <piotr.oniszczuk@gmail.com> wrote:
> > > > > > > > > > >>> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 5 cze 2025, o godz. 15:42:
> > > > > > > > > > >>>> Alexey,
> > > > > > > > > > >>>> I see you are using rk3576 board like me (nanopi-m5)
> > > > > > > > > > >>>> Have you on your board correctly working cpu dvfs?
> > > > > > > > > > >>>> I mean: [1][desired clocks reported by kernel sysfs are in pair with [2[]cur clocks?
> > > > > > > > > > >>>> In my case i see mine cpu lives totally on it’s own with dvfs:
> > > > > > > > > > >>>
> > > > > > > > > > >>> Hi Piotr,
> > > > > > > > > > >>>
> > > > > > > > > > >>> I haven't tried to validate actual running frequencies vs. requested
> > > > > > > > > > >>> frequencies, but subjective performance and power consumption seem to
> > > > > > > > > > >>> be in line with what I expect.
> > > > > > > > > > >>
> > > > > > > > > > >> well - my subjective l&f is that  - currently - my rk3576 seems „slower" than i.e. 4xA53 h618.
> > > > > > > > > > >
> > > > > > > > > > > In my experience, native compilation of GCC 14 using 8 threads on
> > > > > > > > > > > RK3576 (mainline with passive cooling and throttling enabled): 2 hours
> > > > > > > > > > > 6 minutes, on RK3588 (mainline with passive cooling via Radxa Rock 5B
> > > > > > > > > > > case and throttling enabled but never kicking in): 1 hour 10 minutes
> > > > > > > > > >
> > > > > > > > > > by curiosity i looked randomly on 3576 vs 3588:
> > > > > > > > > > multithread passmark: 3675 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3576&id=6213)
> > > > > > > > > > multithread passmark: 4530 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3588&id=4906)
> > > > > > > > > >
> > > > > > > > > > assuming 3588 as baseline, 3576 is approx 20% slower on multithread passmark (has ~0,8 comp power of 3588)
> > > > > > > > > > 70 min compile on 3588 should take something like ~86min on 3576.
> > > > > > > > > > In your case 126min compile on 3576 shows 3576 offers 0,55 comp power of 3588.
> > > > > > > > > > Roughly 3576 should do this task in 40min less than you currently see i think
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > Can't see how u-boot would affect CPU speed in Linux, as long as you
> > > > > > > > > > > use comparable ATF images. Do you use the same kernel and dtb in all
> > > > > > > > > > > these cases? Also, what's your thermal setup?
> > > > > > > > > >
> > > > > > > > > > yes. in all cases only change was: uboot & atf
> > > > > > > > > > thermal is based on recent collabora series (+ recent pooling fix for clocks return from throttling)
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Not sure UX is a particularly good measure of CPU performance, as long
> > > > > > > > > > > as you've got a properly accelerated DRM graphics pipeline. More
> > > > > > > > > > > likely 2D/3D and memory.
> > > > > > > > > >
> > > > > > > > > > indeed.
> > > > > > > > > > For quantified look i’m looking on v.simple approach to estimate real clock is http://uob-hpc.github.io/2017/11/22/arm-clock-freq.html
> > > > > > > > > > by curiosity i looked what it reports on a53/a55/a72/a76 and it is surprisingly accurate :-)
> > > > > > > > > > on mine 3576 with collabora uboot+mainline atf is hows 800MHz (and in perf. gov it seems to be constant)
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > There might be some difference in how PVTPLL behaves on RK3576 vs.
> > > > > > > > > > > RK3588. But frankly first I would check if you are using comparable
> > > > > > > > > > > ATF implementations (e.g. upstream TF-A in both cases), kernels and
> > > > > > > > > > > thermal environment :)
> > > > > > > > > >
> > > > > > > > > > all tests: the same 6.15.2 mainline + some collabora patches
> > > > > > > > > >
> > > > > > > > > > diffs were:
> > > > > > > > > > 1.collabora uboot[1] + mainline atf 2.13
> > > > > > > > > > 2.collabora uboot[1] + rockchip rkbin bl31 blob
> > > > > > > > > > 3.vendor uboot (bin dump from friendlyelec ubuntu image)
> > > > > > > > > >
> > > > > > > > > > on 1/2 i see kind of issue with clock values (i.e. perf gov gives constant 800MHz on mainline atf).
> > > > > > > > > > 3 seems to perform better - (i.e. perf gov gives constant 1500MHz so all is snappier/faster)
> > > > > > > > >
> > > > > > > > > There is indeed something weird going on. I've tried running sbc-bench
> > > > > > > > > [1], and even though I observe dynamically varying CPU frequencies
> > > > > > > > > after boot with schedutil governor, once sbc-bench switches the
> > > > > > > > > governor to "performance" and goes through the OPPs in descending
> > > > > > > > > frequency order, the CPUs seem to get stuck at the last applied low
> > > > > > > > > frequency. Even after max frequency gets reverted from 408 MHz to
> > > > > > > > > something higher, even after I switch the governor to something else -
> > > > > > > > > no matter what. Only a reboot gets the higher frequencies 'unstuck'
> > > > > > > > > for me.
> > > > > > > > >
> > > > > > > > > These are all observed at around 55C SoC temperature, so throttling is
> > > > > > > > > not an issue. Regulators are stuck at 950000 uV - way above 700000 uV
> > > > > > > > > that the 408 MHz OPP requires (and power readings seem to match: I'm
> > > > > > > > > getting about 2.3W consumption at 408 MHz in idle vs. normal idle
> > > > > > > > > reading of 1.4W at around 1 GHz).
> > > > > > > > >
> > > > > > > > > Not sure what's going on here, and I don't remember seeing anything
> > > > > > > > > similar on RK3588. Thoughts welcome.
> > > > > > > >
> > > > > > > > This may once again be a "accidentally uses wrong clock IDs" type
> > > > > > > > situation. The other possibility is that we're getting confused
> > > > > > > > between what we think the clock rate is and what SCMI actually set
> > > > > > > > the clock rate to.
> > > > > > > >
> > > > > > > > Things to check is whether the right clock controller (scmi vs cru)
> > > > > > > > and the right clock id (check ATF source for this) is used.
> > > > > > >
> > > > > > > Clock IDs in the kernel seem to match those in ATF, but I've noticed
> > > > > > > what appears to be a buffer overflow in some of the SCMI clock names
> > > > > > > defined in the opensource TF-A (thanks GCC 15 and its zealous
> > > > > > > warnings):
> > > > > >
> > > > > > After some more testing, I tend to confirm what Piotr observed
> > > > > > earlier. Namely, frequency scaling acts weird on any ATF version (be
> > > > > > it binary BL31 or opensource TF-A), as long as mainline u-boot is
> > > > > > used. Using the u-boot binary extracted from the ArmSoM QWRT image
> > > > > > does not lead to "stuck" CPU frequencies when running sbc-bench.
> > > > > >
> > > > > > I'm getting this with the exact same kernel build (6.16-rc1 with some
> > > > > > Sige5 related patches, namely v2 of this series, Nicolas' USB
> > > > > > enablement series and TSADC). The only other difference is that the
> > > > > > binary u-boot doesn't have EFI support, so I had to boot into the
> > > > > > ARM64 uncompressed Image instead of vmlinuz.efi, but those were both
> > > > > > taken from the same build.
> > > > > >
> > > > > > What I'm observing during the sbc-bench run:
> > > > > >  - It switches the cpufreq governor from schedutil to performance
> > > > > >  - It goes through all CPU OPPs in descending frequency order
> > > > > >  --- While it does that when booted using mainline u-boot +
> > > > > > vmlinuz.efi: "hardware limits" line in "cpupower -c 0,4
> > > > > > frequency-info" changes with each OPP change (the max frequency
> > > > > > getting reduced sequentially), then it resets to the initial full
> > > > > > range, but the actual frequency stays stuck at the lowest possible
> > > > > > value
> > > > > >  --- While it does that when booted using binary u-boot + Image:
> > > > > > "hardware limits" line in "cpupower -c 0,4 frequency-info" doesn't
> > > > > > change, but the actual frequency gets reduced sequentially. Then after
> > > > > > the iteration over all OPPs is completed it returns to the highest
> > > > > > possible value, and adjusts dynamically based on thermal throttling as
> > > > > > the benchmark progresses
> > > > >
> > > > > Slight correction: it's not the "hardware limits" line, but rather
> > > > > "current policy".
> > > > >
> > > > > Note that booting mainline u-boot in non-EFI mode (using plain Image)
> > > > > doesn't change the results above.
> > > >
> > > > I'm in a similar boat, while trying to make DSI run on the rk3576.
> > > > Andy from Rockchip was able to make it work "just" by using vendor-
> > > > firmware - while using mainline u-boot (with both mainline TF-A
> > > > or vendor TF-A) produces just black output.
> > > >
> > > > I think when I did the mainline u-boot thing I took the "vendor"-code
> > > > from the armbian rk3576 vendor-u-boot ... but that actually may differ
> > > > from what the vendors provided?
> > >
> > > Just tried booting into u-boot built from ArmSoM sources at [1] - same
> > > issues as using mainline. Either I'm doing something stupid building
> > > it (don't know what though), or the binary shipped in ArmSoM images is
> > > indeed different from what the sources are.
> >
> > Can you list the versions you see for the _working_ binaries?
>
> Those are not as detailed as I'd like, as vendor builds seem to
> override the default U-boot versioning rules (stripping the git hash
> information off).
>
> I've identified the following versions for the binary image that worked for me:
>
> DDR init v1.03 (version string "DDR 81dd75088a wesley.yao
> 24/04/16-11:19:41,fwver: v1.03")
> U-boot SPL 2017.09 (no traces of any particular git commit, version
> string "U-Boot SPL 2017.09 (Aug 23 2024 - 00:47:39)")
> U-boot proper 2017.09 (ditto, version string "U-Boot 2017.09 (Aug 23
> 2024 - 00:47:39 +0000) OpenWrt")
> BL31 image v1.04 (version string
> "v2.3():v2.3-749-g30018b771:derrick.huang, fwver: v1.04")
> BL32 image v1.01 (version string "U3.13.0-791-g185dc3c92 #hisping.lin
> (gcc version 10.2.1 20201103 (GNU Toolchain for the A-profile
> Architecture 10.2-2020.11 (arm-10.16))) #2 Tue Apr 16 11:05:25 CST
> 2024 aarch64, fwver: v1.01")
>
> > I.e. u-boot and friends may list someversion-gGITHASH thingy like your
> > OPTEE already does: OP-TEE version: 3.13.0-791-g185dc3c92 .
> > Also possibly the build date.
>
> The build date is later than any commit I see in the ArmSoM repo
> leading up to either of the two tags they have there ("rk3576" and
> "rk3576-6.1-rk3.1", neither of them belonging to any published branch
> there)
>
> > I.e. I'm wondering/hoping if we can match to some git commit.
>
> I've also noticed that ArmSoM SDK references the "boost" binary from
> rkbin (rk3576_boost_v1.00.bin in particular), but it doesn't seem to
> be present in the bootloader binary I'm looking at. The version string
> of the SPL binary in rkbin as included in the SDK is also different
> from what I'm seeing in the actual binary: SDK has "U-Boot SPL
> 2017.09-g57b8ceed1c3-240418 #lxh (Apr 19 2024 - 17:07:22), fwver:
> v1.02".
>
> I'll try and rebuild the vendor u-boot from source with these specific
> versions of rkbin blobs (ddr v1.03, bl31 v1.04 and bl32 v1.01), but
> the changelog in rkbin didn't mention anything that would seem
> relevant to the issue I'm observing :(

Okay, I've bisected this.

TLDR: Linux and u-boot seem to have nothing to do with it, opensource
TF-A doesn't work, binary BL31 starting with v1.09 do not work. BL31
v1.08 and earlier work fine. Tested with vendor u-boot and with
2025.07-rc2, results are similar. OP-TEE presence does not affect the
results.

To test:
1. Build and apply a fresh u-boot-rockchip.bin using the DDR init and
BL31 from rkbin repo [1]
2. Run "watch cpupower -c 0,4 frequency-info" to observe how CPU
frequencies change
3. In a separate terminal, run "bash sbc-bench.sh -c" [2]
4. "Good" behavior:
    a. Once the cpufreq governor is switched to "performance" (if it
was anything different at boot), both CPU clusters go up to their max
frequencies
    b. While the benchmark runs through the stage where it says
"Checking cpufreq OPP", CPU frequencies consecutively decrease from
the max OPP frequency to the min
    c. After the benchmark finishes the stage where it says "Checking
cpufreq OPP", both CPU clusters go up to their max frequencies for the
rest of the benchmarking run
    "Bad" behavior:
    a. Once the cpufreq governor is switched to "performance" (if it
was anything different at boot), both CPU clusters stay at whatever
frequencies they were at when the switch occurred
    b. While the benchmark runs through the stage where it says
"Checking cpufreq OPP", CPU frequencies consecutively decrease from
the "pre-max" OPP frequency to the min (max frequency never gets
applied on either of the clusters!)
    c. After the benchmark finishes the stage where it says "Checking
cpufreq OPP", both CPU clusters stay at their min frequencies for the
rest of the benchmarking run

I suspect it has something to do with the topmost OPP somehow becoming
unselectable in ATF starting from binary BL31 v1.09 (and similarly in
opensource TF-A). This time I couldn't reproduce the "permanently
stuck" CPU frequencies though.

Here are the git bisect results (running in rkbin repo):

0b338fd6ae7ad816295a75c80b00968bb1868625 is the first bad commit
commit 0b338fd6ae7ad816295a75c80b00968bb1868625 (HEAD)
Author: XiaoDong Huang <derrick.huang@rock-chips.com>
Date:   Fri Jun 28 17:47:55 2024 +0800

    rk3576: bl31: update version to v1.09

    Build from ATF commit:
        286c013b2 plat: rockchip: rk3576: Add support to set low length
    update feature:
        286c013b2 plat: rockchip: rk3576: Add support to set low length
        5fb78cd64 rockchip: uart: switch to loopback mode before
checking busy status
        02ff3b0da rockchip: uart: save uart register once
        23bd4684e plat: rk3576: support to switch hptimer to 1G
        b4833e988 plat: rk3576: remove AUTOCS_EN_COUNT
        437ed59cb plat: rockchip: rk3576: support aclk_sencure_s enable
        6d8c67d6a plat: rk3576: support poweroff scu1 when cpu4~cpu7 off

    Change-Id: I0fcb5afefcc3865cf8c413b4c0ed00234d2675cb
    Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>

 RKTRUST/RK3576TRUST.ini                                   |   2 +-
 bin/rk35/{rk3576_bl31_v1.08.elf => rk3576_bl31_v1.09.elf} | Bin
349032 -> 349032 bytes
 doc/release/RK3576_CN.md                                  |  13 +++++++++++++
 doc/release/RK3576_EN.md                                  |  14 ++++++++++++++
 4 files changed, 28 insertions(+), 1 deletion(-)
 rename bin/rk35/{rk3576_bl31_v1.08.elf => rk3576_bl31_v1.09.elf} (82%)

[1] https://github.com/rockchip-linux/rkbin.git
[2] https://github.com/ThomasKaiser/sbc-bench

Derrick, if you could chime in on what might be going on here, that
would be greatly appreciated :)

Best regards,
Alexey

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Piotr Oniszczuk]

> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 23 cze 2025, o godz. 15:58:
> 
> On Mon, Jun 23, 2025 at 1:19 PM Alexey Charkov <alchark@gmail.com> wrote:
>> 
>> 
> 
> Okay, I've bisected this.
> 
> TLDR: Linux and u-boot seem to have nothing to do with it, opensource
> TF-A doesn't work, binary BL31 starting with v1.09 do not work. BL31
> v1.08 and earlier work fine.


just fyi: 
to confirm: replacing only bl31 to 1.08 makes all good
with perf gov. clocks staying on 2200/2300
clock estimations are predictable, constant and estimating constantly 2400
ux is „like” on 3588

Alexey: many thx for finding root cause component!
  
   

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Jonas Karlman]

On 2025-06-23 17:02, Piotr Oniszczuk wrote:
> 
> 
>> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 23 cze 2025, o godz. 15:58:
>>
>> On Mon, Jun 23, 2025 at 1:19 PM Alexey Charkov <alchark@gmail.com> wrote:
>>>
>>>
>>
>> Okay, I've bisected this.
>>
>> TLDR: Linux and u-boot seem to have nothing to do with it, opensource
>> TF-A doesn't work, binary BL31 starting with v1.09 do not work. BL31
>> v1.08 and earlier work fine.

v1.09 added support for 1 GHz hrtimer in addition to the normal 24 MHz
rate. Mainline U-Boot may only support use of 24 MHz hrtimer, unsure
what impact the hrtimer rate has. Mixing blobs with/without 1 GHz
support is known to cause issues. At one point the latest rkbin tree may
have contained incompatible rk3576 blobs (mixed 1 ghz vs 24 mhz rate).

Did you try with newer blobs, i.e. ddr init v1.09, bl31 v1.19 blobs [1]
and mainline U-Boot [2] ?

[1] https://github.com/radxa/rkbin/commits/develop-v2025.04/
[2] https://source.denx.de/u-boot/contributors/kwiboo/u-boot/-/commits/rk3576

Regards,
Jonas

> 
> 
> just fyi: 
> to confirm: replacing only bl31 to 1.08 makes all good
> with perf gov. clocks staying on 2200/2300
> clock estimations are predictable, constant and estimating constantly 2400
> ux is „like” on 3588
> 
> Alexey: many thx for finding root cause component!
>   
>    

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Jonas Karlman]

On 2025-06-23 15:58, Alexey Charkov wrote:
> On Mon, Jun 23, 2025 at 1:19 PM Alexey Charkov <alchark@gmail.com> wrote:
>>
>> On Sun, Jun 22, 2025 at 5:48 PM Heiko Stuebner <heiko@sntech.de> wrote:
>>>
>>> Am Samstag, 21. Juni 2025, 23:21:11 Mitteleuropäische Sommerzeit schrieb Alexey Charkov:
>>>> On Sat, Jun 21, 2025 at 11:44 PM Heiko Stuebner <heiko@sntech.de> wrote:
>>>>>
>>>>> Am Samstag, 21. Juni 2025, 21:35:56 Mitteleuropäische Sommerzeit schrieb Alexey Charkov:
>>>>>> On Fri, Jun 20, 2025 at 8:02 PM Alexey Charkov <alchark@gmail.com> wrote:
>>>>>>>
>>>>>>> On Wed, Jun 18, 2025 at 6:48 PM Alexey Charkov <alchark@gmail.com> wrote:
>>>>>>>>
>>>>>>>> On Wed, Jun 18, 2025 at 6:06 PM Nicolas Frattaroli
>>>>>>>> <nicolas.frattaroli@collabora.com> wrote:
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> +Cc Jonas Karlman as he is intimately familiar with RK3576 clock shenanigans by now,
>>>>>>>>>
>>>>>>>>> On Wednesday, 18 June 2025 15:51:45 Central European Summer Time Alexey Charkov wrote:
>>>>>>>>>> On Sun, Jun 15, 2025 at 8:00 PM Piotr Oniszczuk
>>>>>>>>>> <piotr.oniszczuk@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 9 cze 2025, o godz. 16:05:
>>>>>>>>>>>>
>>>>>>>>>>>> On Sun, Jun 8, 2025 at 11:24 AM Piotr Oniszczuk
>>>>>>>>>>>> <piotr.oniszczuk@gmail.com> wrote:
>>>>>>>>>>>>>> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 5 cze 2025, o godz. 15:42:
>>>>>>>>>>>>>>> Alexey,
>>>>>>>>>>>>>>> I see you are using rk3576 board like me (nanopi-m5)
>>>>>>>>>>>>>>> Have you on your board correctly working cpu dvfs?
>>>>>>>>>>>>>>> I mean: [1][desired clocks reported by kernel sysfs are in pair with [2[]cur clocks?
>>>>>>>>>>>>>>> In my case i see mine cpu lives totally on it’s own with dvfs:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Piotr,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I haven't tried to validate actual running frequencies vs. requested
>>>>>>>>>>>>>> frequencies, but subjective performance and power consumption seem to
>>>>>>>>>>>>>> be in line with what I expect.
>>>>>>>>>>>>>
>>>>>>>>>>>>> well - my subjective l&f is that  - currently - my rk3576 seems „slower" than i.e. 4xA53 h618.
>>>>>>>>>>>>
>>>>>>>>>>>> In my experience, native compilation of GCC 14 using 8 threads on
>>>>>>>>>>>> RK3576 (mainline with passive cooling and throttling enabled): 2 hours
>>>>>>>>>>>> 6 minutes, on RK3588 (mainline with passive cooling via Radxa Rock 5B
>>>>>>>>>>>> case and throttling enabled but never kicking in): 1 hour 10 minutes
>>>>>>>>>>>
>>>>>>>>>>> by curiosity i looked randomly on 3576 vs 3588:
>>>>>>>>>>> multithread passmark: 3675 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3576&id=6213
>>>>>>>>>>> multithread passmark: 4530 (https://www.cpubenchmark.net/cpu.php?cpu=Rockchip+RK3588&id=4906
>>>>>>>>>>>
>>>>>>>>>>> assuming 3588 as baseline, 3576 is approx 20% slower on multithread passmark (has ~0,8 comp power of 3588)
>>>>>>>>>>> 70 min compile on 3588 should take something like ~86min on 3576.
>>>>>>>>>>> In your case 126min compile on 3576 shows 3576 offers 0,55 comp power of 3588.
>>>>>>>>>>> Roughly 3576 should do this task in 40min less than you currently see i think
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Can't see how u-boot would affect CPU speed in Linux, as long as you
>>>>>>>>>>>> use comparable ATF images. Do you use the same kernel and dtb in all
>>>>>>>>>>>> these cases? Also, what's your thermal setup?
>>>>>>>>>>>
>>>>>>>>>>> yes. in all cases only change was: uboot & atf
>>>>>>>>>>> thermal is based on recent collabora series (+ recent pooling fix for clocks return from throttling)
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Not sure UX is a particularly good measure of CPU performance, as long
>>>>>>>>>>>> as you've got a properly accelerated DRM graphics pipeline. More
>>>>>>>>>>>> likely 2D/3D and memory.
>>>>>>>>>>>
>>>>>>>>>>> indeed.
>>>>>>>>>>> For quantified look i’m looking on v.simple approach to estimate real clock is http://uob-hpc.github.io/2017/11/22/arm-clock-freq.html
>>>>>>>>>>> by curiosity i looked what it reports on a53/a55/a72/a76 and it is surprisingly accurate :-)
>>>>>>>>>>> on mine 3576 with collabora uboot+mainline atf is hows 800MHz (and in perf. gov it seems to be constant)
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> There might be some difference in how PVTPLL behaves on RK3576 vs.
>>>>>>>>>>>> RK3588. But frankly first I would check if you are using comparable
>>>>>>>>>>>> ATF implementations (e.g. upstream TF-A in both cases), kernels and
>>>>>>>>>>>> thermal environment :)
>>>>>>>>>>>
>>>>>>>>>>> all tests: the same 6.15.2 mainline + some collabora patches
>>>>>>>>>>>
>>>>>>>>>>> diffs were:
>>>>>>>>>>> 1.collabora uboot[1] + mainline atf 2.13
>>>>>>>>>>> 2.collabora uboot[1] + rockchip rkbin bl31 blob
>>>>>>>>>>> 3.vendor uboot (bin dump from friendlyelec ubuntu image)
>>>>>>>>>>>
>>>>>>>>>>> on 1/2 i see kind of issue with clock values (i.e. perf gov gives constant 800MHz on mainline atf).
>>>>>>>>>>> 3 seems to perform better - (i.e. perf gov gives constant 1500MHz so all is snappier/faster)
>>>>>>>>>>
>>>>>>>>>> There is indeed something weird going on. I've tried running sbc-bench
>>>>>>>>>> [1], and even though I observe dynamically varying CPU frequencies
>>>>>>>>>> after boot with schedutil governor, once sbc-bench switches the
>>>>>>>>>> governor to "performance" and goes through the OPPs in descending
>>>>>>>>>> frequency order, the CPUs seem to get stuck at the last applied low
>>>>>>>>>> frequency. Even after max frequency gets reverted from 408 MHz to
>>>>>>>>>> something higher, even after I switch the governor to something else -
>>>>>>>>>> no matter what. Only a reboot gets the higher frequencies 'unstuck'
>>>>>>>>>> for me.
>>>>>>>>>>
>>>>>>>>>> These are all observed at around 55C SoC temperature, so throttling is
>>>>>>>>>> not an issue. Regulators are stuck at 950000 uV - way above 700000 uV
>>>>>>>>>> that the 408 MHz OPP requires (and power readings seem to match: I'm
>>>>>>>>>> getting about 2.3W consumption at 408 MHz in idle vs. normal idle
>>>>>>>>>> reading of 1.4W at around 1 GHz).
>>>>>>>>>>
>>>>>>>>>> Not sure what's going on here, and I don't remember seeing anything
>>>>>>>>>> similar on RK3588. Thoughts welcome.
>>>>>>>>>
>>>>>>>>> This may once again be a "accidentally uses wrong clock IDs" type
>>>>>>>>> situation. The other possibility is that we're getting confused
>>>>>>>>> between what we think the clock rate is and what SCMI actually set
>>>>>>>>> the clock rate to.
>>>>>>>>>
>>>>>>>>> Things to check is whether the right clock controller (scmi vs cru)
>>>>>>>>> and the right clock id (check ATF source for this) is used.
>>>>>>>>
>>>>>>>> Clock IDs in the kernel seem to match those in ATF, but I've noticed
>>>>>>>> what appears to be a buffer overflow in some of the SCMI clock names
>>>>>>>> defined in the opensource TF-A (thanks GCC 15 and its zealous
>>>>>>>> warnings):
>>>>>>>
>>>>>>> After some more testing, I tend to confirm what Piotr observed
>>>>>>> earlier. Namely, frequency scaling acts weird on any ATF version (be
>>>>>>> it binary BL31 or opensource TF-A), as long as mainline u-boot is
>>>>>>> used. Using the u-boot binary extracted from the ArmSoM QWRT image
>>>>>>> does not lead to "stuck" CPU frequencies when running sbc-bench.
>>>>>>>
>>>>>>> I'm getting this with the exact same kernel build (6.16-rc1 with some
>>>>>>> Sige5 related patches, namely v2 of this series, Nicolas' USB
>>>>>>> enablement series and TSADC). The only other difference is that the
>>>>>>> binary u-boot doesn't have EFI support, so I had to boot into the
>>>>>>> ARM64 uncompressed Image instead of vmlinuz.efi, but those were both
>>>>>>> taken from the same build.
>>>>>>>
>>>>>>> What I'm observing during the sbc-bench run:
>>>>>>>  - It switches the cpufreq governor from schedutil to performance
>>>>>>>  - It goes through all CPU OPPs in descending frequency order
>>>>>>>  --- While it does that when booted using mainline u-boot +
>>>>>>> vmlinuz.efi: "hardware limits" line in "cpupower -c 0,4
>>>>>>> frequency-info" changes with each OPP change (the max frequency
>>>>>>> getting reduced sequentially), then it resets to the initial full
>>>>>>> range, but the actual frequency stays stuck at the lowest possible
>>>>>>> value
>>>>>>>  --- While it does that when booted using binary u-boot + Image:
>>>>>>> "hardware limits" line in "cpupower -c 0,4 frequency-info" doesn't
>>>>>>> change, but the actual frequency gets reduced sequentially. Then after
>>>>>>> the iteration over all OPPs is completed it returns to the highest
>>>>>>> possible value, and adjusts dynamically based on thermal throttling as
>>>>>>> the benchmark progresses
>>>>>>
>>>>>> Slight correction: it's not the "hardware limits" line, but rather
>>>>>> "current policy".
>>>>>>
>>>>>> Note that booting mainline u-boot in non-EFI mode (using plain Image)
>>>>>> doesn't change the results above.
>>>>>
>>>>> I'm in a similar boat, while trying to make DSI run on the rk3576.
>>>>> Andy from Rockchip was able to make it work "just" by using vendor-
>>>>> firmware - while using mainline u-boot (with both mainline TF-A
>>>>> or vendor TF-A) produces just black output.
>>>>>
>>>>> I think when I did the mainline u-boot thing I took the "vendor"-code
>>>>> from the armbian rk3576 vendor-u-boot ... but that actually may differ
>>>>> from what the vendors provided?
>>>>
>>>> Just tried booting into u-boot built from ArmSoM sources at [1] - same
>>>> issues as using mainline. Either I'm doing something stupid building
>>>> it (don't know what though), or the binary shipped in ArmSoM images is
>>>> indeed different from what the sources are.
>>>
>>> Can you list the versions you see for the _working_ binaries?
>>
>> Those are not as detailed as I'd like, as vendor builds seem to
>> override the default U-boot versioning rules (stripping the git hash
>> information off).
>>
>> I've identified the following versions for the binary image that worked for me:
>>
>> DDR init v1.03 (version string "DDR 81dd75088a wesley.yao
>> 24/04/16-11:19:41,fwver: v1.03")
>> U-boot SPL 2017.09 (no traces of any particular git commit, version
>> string "U-Boot SPL 2017.09 (Aug 23 2024 - 00:47:39)")
>> U-boot proper 2017.09 (ditto, version string "U-Boot 2017.09 (Aug 23
>> 2024 - 00:47:39 +0000) OpenWrt")
>> BL31 image v1.04 (version string
>> "v2.3():v2.3-749-g30018b771:derrick.huang, fwver: v1.04")
>> BL32 image v1.01 (version string "U3.13.0-791-g185dc3c92 #hisping.lin
>> (gcc version 10.2.1 20201103 (GNU Toolchain for the A-profile
>> Architecture 10.2-2020.11 (arm-10.16))) #2 Tue Apr 16 11:05:25 CST
>> 2024 aarch64, fwver: v1.01")
>>
>>> I.e. u-boot and friends may list someversion-gGITHASH thingy like your
>>> OPTEE already does: OP-TEE version: 3.13.0-791-g185dc3c92 .
>>> Also possibly the build date.
>>
>> The build date is later than any commit I see in the ArmSoM repo
>> leading up to either of the two tags they have there ("rk3576" and
>> "rk3576-6.1-rk3.1", neither of them belonging to any published branch
>> there)
>>
>>> I.e. I'm wondering/hoping if we can match to some git commit.
>>
>> I've also noticed that ArmSoM SDK references the "boost" binary from
>> rkbin (rk3576_boost_v1.00.bin in particular), but it doesn't seem to
>> be present in the bootloader binary I'm looking at. The version string
>> of the SPL binary in rkbin as included in the SDK is also different
>> from what I'm seeing in the actual binary: SDK has "U-Boot SPL
>> 2017.09-g57b8ceed1c3-240418 #lxh (Apr 19 2024 - 17:07:22), fwver:
>> v1.02".
>>
>> I'll try and rebuild the vendor u-boot from source with these specific
>> versions of rkbin blobs (ddr v1.03, bl31 v1.04 and bl32 v1.01), but
>> the changelog in rkbin didn't mention anything that would seem
>> relevant to the issue I'm observing :(
> 
> Okay, I've bisected this.
> 
> TLDR: Linux and u-boot seem to have nothing to do with it, opensource
> TF-A doesn't work, binary BL31 starting with v1.09 do not work. BL31
> v1.08 and earlier work fine. Tested with vendor u-boot and with
> 2025.07-rc2, results are similar. OP-TEE presence does not affect the
> results.
> 
> To test:
> 1. Build and apply a fresh u-boot-rockchip.bin using the DDR init and
> BL31 from rkbin repo [1]
> 2. Run "watch cpupower -c 0,4 frequency-info" to observe how CPU
> frequencies change
> 3. In a separate terminal, run "bash sbc-bench.sh -c" [2]
> 4. "Good" behavior:
>     a. Once the cpufreq governor is switched to "performance" (if it
> was anything different at boot), both CPU clusters go up to their max
> frequencies
>     b. While the benchmark runs through the stage where it says
> "Checking cpufreq OPP", CPU frequencies consecutively decrease from
> the max OPP frequency to the min
>     c. After the benchmark finishes the stage where it says "Checking
> cpufreq OPP", both CPU clusters go up to their max frequencies for the
> rest of the benchmarking run
>     "Bad" behavior:
>     a. Once the cpufreq governor is switched to "performance" (if it
> was anything different at boot), both CPU clusters stay at whatever
> frequencies they were at when the switch occurred
>     b. While the benchmark runs through the stage where it says
> "Checking cpufreq OPP", CPU frequencies consecutively decrease from
> the "pre-max" OPP frequency to the min (max frequency never gets
> applied on either of the clusters!)
>     c. After the benchmark finishes the stage where it says "Checking
> cpufreq OPP", both CPU clusters stay at their min frequencies for the
> rest of the benchmarking run
> 
> I suspect it has something to do with the topmost OPP somehow becoming
> unselectable in ATF starting from binary BL31 v1.09 (and similarly in
> opensource TF-A). This time I couldn't reproduce the "permanently
> stuck" CPU frequencies though.

Open-source TF-A only seem to support rates up to 2208 MHz for cpub and
2016 MHz for cpul, see [3]. The opp-2304000000 should probably be
removed from rk3576.dtsi.

All rates starting from 816 MHz are expected to use the PVTPLL, i.e. the
configured osc ring length (by tf-a) and opp voltage (linux) will
regulate the rate. The measured rate can typically also be read from a
PVTPLL grf reg (0x18).

For the GPU clock I have an incoming series that switch to use GPU
PVTPLL instead of a normal PLL, see [4].

[3] https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/rockchip/rk3576/scmi/rk3576_clk.c#L264-L304
[4] https://github.com/Kwiboo/linux-rockchip/commits/next-20250428-rk35xx-scmi-gpu-clk/

Regards,
Jonas

> 
> Here are the git bisect results (running in rkbin repo):
> 
> 0b338fd6ae7ad816295a75c80b00968bb1868625 is the first bad commit
> commit 0b338fd6ae7ad816295a75c80b00968bb1868625 (HEAD)
> Author: XiaoDong Huang <derrick.huang@rock-chips.com>
> Date:   Fri Jun 28 17:47:55 2024 +0800
> 
>     rk3576: bl31: update version to v1.09
> 
>     Build from ATF commit:
>         286c013b2 plat: rockchip: rk3576: Add support to set low length
>     update feature:
>         286c013b2 plat: rockchip: rk3576: Add support to set low length
>         5fb78cd64 rockchip: uart: switch to loopback mode before
> checking busy status
>         02ff3b0da rockchip: uart: save uart register once
>         23bd4684e plat: rk3576: support to switch hptimer to 1G
>         b4833e988 plat: rk3576: remove AUTOCS_EN_COUNT
>         437ed59cb plat: rockchip: rk3576: support aclk_sencure_s enable
>         6d8c67d6a plat: rk3576: support poweroff scu1 when cpu4~cpu7 off
> 
>     Change-Id: I0fcb5afefcc3865cf8c413b4c0ed00234d2675cb
>     Signed-off-by: XiaoDong Huang <derrick.huang@rock-chips.com>
> 
>  RKTRUST/RK3576TRUST.ini                                   |   2 +-
>  bin/rk35/{rk3576_bl31_v1.08.elf => rk3576_bl31_v1.09.elf} | Bin
> 349032 -> 349032 bytes
>  doc/release/RK3576_CN.md                                  |  13 +++++++++++++
>  doc/release/RK3576_EN.md                                  |  14 ++++++++++++++
>  4 files changed, 28 insertions(+), 1 deletion(-)
>  rename bin/rk35/{rk3576_bl31_v1.08.elf => rk3576_bl31_v1.09.elf} (82%)
> 
> [1] https://github.com/rockchip-linux/rkbin.git
> [2] https://github.com/ThomasKaiser/sbc-bench
> 
> Derrick, if you could chime in on what might be going on here, that
> would be greatly appreciated :)
> 
> Best regards,
> Alexey

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Jonas Karlman]

On 2025-06-23 19:40, Jonas Karlman wrote:
> On 2025-06-23 17:02, Piotr Oniszczuk wrote:
>>
>>
>>> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 23 cze 2025, o godz. 15:58:
>>>
>>> On Mon, Jun 23, 2025 at 1:19 PM Alexey Charkov <alchark@gmail.com> wrote:
>>>>
>>>>
>>>
>>> Okay, I've bisected this.
>>>
>>> TLDR: Linux and u-boot seem to have nothing to do with it, opensource
>>> TF-A doesn't work, binary BL31 starting with v1.09 do not work. BL31
>>> v1.08 and earlier work fine.
> 
> v1.09 added support for 1 GHz hrtimer in addition to the normal 24 MHz
> rate. Mainline U-Boot may only support use of 24 MHz hrtimer, unsure
> what impact the hrtimer rate has. Mixing blobs with/without 1 GHz
> support is known to cause issues. At one point the latest rkbin tree may
> have contained incompatible rk3576 blobs (mixed 1 ghz vs 24 mhz rate).

Clarification:
Following boot1 parameter activates use of 1 GHz hrtimer, see [3].

This parameter was added to rkbin repo before all blobs was updated to
fully support use of the 1 ghz mode, and is the source for incompatible
blobs I referenced above.

  [BOOT1_PARAM]
  WORD_2=0x100

[3] https://github.com/rockchip-linux/rkbin/commit/cbbc6868221fb416d4f0d86a10e493dbbbc1f117

Regards,
Jonas

> 
> Did you try with newer blobs, i.e. ddr init v1.09, bl31 v1.19 blobs [1]
> and mainline U-Boot [2] ?
> 
> [1] https://github.com/radxa/rkbin/commits/develop-v2025.04/
> [2] https://source.denx.de/u-boot/contributors/kwiboo/u-boot/-/commits/rk3576
> 
> Regards,
> Jonas
> 
>>
>>
>> just fyi: 
>> to confirm: replacing only bl31 to 1.08 makes all good
>> with perf gov. clocks staying on 2200/2300
>> clock estimations are predictable, constant and estimating constantly 2400
>> ux is „like” on 3588
>>
>> Alexey: many thx for finding root cause component!
>>   
>>    
> 

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Heiko Stuebner]

Am Montag, 23. Juni 2025, 23:07:53 Mitteleuropäische Sommerzeit schrieb Jonas Karlman:
> On 2025-06-23 19:40, Jonas Karlman wrote:
> > On 2025-06-23 17:02, Piotr Oniszczuk wrote:
> >>
> >>
> >>> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 23 cze 2025, o godz. 15:58:
> >>>
> >>> On Mon, Jun 23, 2025 at 1:19 PM Alexey Charkov <alchark@gmail.com> wrote:
> >>>>
> >>>>
> >>>
> >>> Okay, I've bisected this.
> >>>
> >>> TLDR: Linux and u-boot seem to have nothing to do with it, opensource
> >>> TF-A doesn't work, binary BL31 starting with v1.09 do not work. BL31
> >>> v1.08 and earlier work fine.
> > 
> > v1.09 added support for 1 GHz hrtimer in addition to the normal 24 MHz
> > rate. Mainline U-Boot may only support use of 24 MHz hrtimer, unsure
> > what impact the hrtimer rate has. Mixing blobs with/without 1 GHz
> > support is known to cause issues. At one point the latest rkbin tree may
> > have contained incompatible rk3576 blobs (mixed 1 ghz vs 24 mhz rate).
> 
> Clarification:
> Following boot1 parameter activates use of 1 GHz hrtimer, see [3].
> 
> This parameter was added to rkbin repo before all blobs was updated to
> fully support use of the 1 ghz mode, and is the source for incompatible
> blobs I referenced above.
> 
>   [BOOT1_PARAM]
>   WORD_2=0x100

which I guess is something we don't do in u-boot at all right now?
Which would also mean, that something may have broken with the 24MHz mode
when the 1GHz thing was added. And nobody ever realized that because the
Rockchip thing uses that boot param for all of them?


> 
> [3] https://github.com/rockchip-linux/rkbin/commit/cbbc6868221fb416d4f0d86a10e493dbbbc1f117
> 
> Regards,
> Jonas
> 
> > 
> > Did you try with newer blobs, i.e. ddr init v1.09, bl31 v1.19 blobs [1]
> > and mainline U-Boot [2] ?
> > 
> > [1] https://github.com/radxa/rkbin/commits/develop-v2025.04/
> > [2] https://source.denx.de/u-boot/contributors/kwiboo/u-boot/-/commits/rk3576
> > 
> > Regards,
> > Jonas
> > 
> >>
> >>
> >> just fyi: 
> >> to confirm: replacing only bl31 to 1.08 makes all good
> >> with perf gov. clocks staying on 2200/2300
> >> clock estimations are predictable, constant and estimating constantly 2400
> >> ux is „like” on 3588
> >>
> >> Alexey: many thx for finding root cause component!
> >>   
> >>    
> > 
> 
> 

Re: [PATCH 1/4] arm64: dts: rockchip: list all CPU supplies on ArmSoM Sige5

[Alexey Charkov]

Hi Jonas,

On Mon, Jun 23, 2025 at 9:40 PM Jonas Karlman <jonas@kwiboo.se> wrote:
>
> On 2025-06-23 17:02, Piotr Oniszczuk wrote:
> >
> >
> >> Wiadomość napisana przez Alexey Charkov <alchark@gmail.com> w dniu 23 cze 2025, o godz. 15:58:
> >>
> >> On Mon, Jun 23, 2025 at 1:19 PM Alexey Charkov <alchark@gmail.com> wrote:
> >>>
> >>>
> >>
> >> Okay, I've bisected this.
> >>
> >> TLDR: Linux and u-boot seem to have nothing to do with it, opensource
> >> TF-A doesn't work, binary BL31 starting with v1.09 do not work. BL31
> >> v1.08 and earlier work fine.
>
> v1.09 added support for 1 GHz hrtimer in addition to the normal 24 MHz
> rate. Mainline U-Boot may only support use of 24 MHz hrtimer, unsure
> what impact the hrtimer rate has. Mixing blobs with/without 1 GHz
> support is known to cause issues. At one point the latest rkbin tree may
> have contained incompatible rk3576 blobs (mixed 1 ghz vs 24 mhz rate).
>
> Did you try with newer blobs, i.e. ddr init v1.09, bl31 v1.19 blobs [1]
> and mainline U-Boot [2] ?
>
> [1] https://github.com/radxa/rkbin/commits/develop-v2025.04/
> [2] https://source.denx.de/u-boot/contributors/kwiboo/u-boot/-/commits/rk3576

Thanks for the pointers! I've just tried the same with newer rkbin
blobs from Radxa's repo, as well as the tip of your rk3576 u-boot
branch. Same results: new blobs act weird, old blobs work fine (up to
and including bl31 v1.08).

> Clarification:
> Following boot1 parameter activates use of 1 GHz hrtimer, see [3].
>
> This parameter was added to rkbin repo before all blobs was updated to
> fully support use of the 1 ghz mode, and is the source for incompatible
> blobs I referenced above.
>
>   [BOOT1_PARAM]
>   WORD_2=0x100
>
> [3] https://github.com/rockchip-linux/rkbin/commit/cbbc6868221fb416d4f0d86a10e493dbbbc1f117

NB: I'm preparing the combined TPL+SPL+u-boot+ATF image
(u-boot-rockchip.bin) using the mainline u-boot binman-based approach,
not Rockchip boot_merger. So I don't think boot1_param gets applied
anywhere (for better or worse).

> > I suspect it has something to do with the topmost OPP somehow becoming
> > unselectable in ATF starting from binary BL31 v1.09 (and similarly in
> > opensource TF-A). This time I couldn't reproduce the "permanently
> > stuck" CPU frequencies though.
>
> Open-source TF-A only seem to support rates up to 2208 MHz for cpub and
> 2016 MHz for cpul, see [3]. The opp-2304000000 should probably be
> removed from rk3576.dtsi.

But both 2208 cpul and 2304 cpub rates work fine using bl31 v1.08, so
maybe the TF-A needs a fix instead? Or is this another case of
"overdrive mode" OPPs as with RK3588j?

Best regards,
Alexey