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

[Heiko Stuebner <heiko@sntech.de>]

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
>