Hello Andre,
On 2024-05-01 11:30, Andre Przywara wrote:
On Tue, 30 Apr 2024 13:10:41 +0200
Dragan Simic <dsimic@xxxxxxxxxxx> wrote:
On 2024-04-30 12:46, Andre Przywara wrote:
> On Tue, 30 Apr 2024 02:01:42 +0200
> Dragan Simic <dsimic@xxxxxxxxxxx> wrote:
>> Thank you very much for reviewing my patch in such a detailed way!
>> It's good to know that the values in the Allwinner datasheets match
>> with the observed reality, so to speak. :)
>
> YW, and yes, I like to double check things when it comes to Allwinner
> documentation ;-) And it was comparably easy for this problem.
Double checking is always good, IMHO. :)
> Out of curiosity: what triggered that patch? Trying to get rid of false
> warning/error messages?
Yes, one of the motivators was to get rid of the false kernel warning,
and the other was to have the cache information nicely available
through
lscpu(1). I already did the same for a few Rockchip SoCs, [1][2][3]
so
a couple of Allwinner SoCs were the next on my mental TODO list. :)
Thanks for doing this!
I'm glad that you like all these patches. :)
And do you plan to address the H616 as well? It's a bit more tricky
there,
since there are two die revisions out: one with 256(?)KB of L2, one
with
1MB(!). We know how to tell them apart, so I could provide some TF-A
code
to patch that up in the DT. The kernel DT copy could go with 256KB
then.
I have no boards based on the Allwinner H616, so it wasn't on my
radar.
Though, I'd be happy to prepare and submit a similar kernel patch for
the H616, if you'd then take it further and submit a TF-A patch that
fixes the DT according to the detected die revision? Did I understand
the plan right?
Yes, that was the idea. I have a working version of that TF-A patch
now,
just need to figure out some details about the best way to only build
this
for the H616 port.
Nice, the kernel patch for the H616 SoC dtsi is now on the list, [4]
please have a look. Please let me know when your follow-up TF-A patch
gets submitted upstream, so I can watch it.
Neither the data sheet nor the user manual mention the cache sizes for
the
H616, but I checked the CSSIDR_EL1 register readouts on both an old
H616
and a new H618, and they confirm that the former has 256 KB L2, and the
latter 1MB.
Oh wow, 1 MB of L2 cache is quite a lot for such an SoC, which is
actually very nice to see. Thumbs up for Allwinner not skimping on
the L2 cache in that H616 die revision. :)
Also I ran tinymembench on two boards to confirm this,
community benchmarks results are available here:
https://github.com/ThomasKaiser/sbc-bench/blob/master/Results.md
The OrangePi Zero2 and OrangePi Zero3 are good examples, respectively.
Associativity and cache line size are dictated by the Arm Cortex cores,
and the L1I & L1D sizes are the same as in the other SoCs.
I've included the most important benchmark results in the H616 SoC
dtsi patch, [4] which actually now serves as an additional reference
for the cache sizes.
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=67a6a98575974416834c2294853b3814376a7ce7
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=8612169a05c5e979af033868b7a9b177e0f9fcdf
[3]
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=b72633ba5cfa932405832de25d0f0a11716903b4
[4]
https://lore.kernel.org/linux-sunxi/9d52e6d338a059618d894abb0764015043330c2b.1714727227.git.dsimic@xxxxxxxxxxx/
