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

Alexey Charkov
2025-06-24T07:41:39Z

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