arm64: cix: fix Orange Pi 6 Plus ACPI CPU topology#44
Conversation
Signed-off-by: coffnix <raphael@bsd.com.br>
|
The complete instructions for reproducing this acpi_override.cpio, including all commands, the Python script used to generate the PPTT, and the GRUB configuration, are available in Issue #43: |
|
Unless the SoC on the Orange Pi 6 Plus has advanced from the The vendor block-diagram at #43 seems to support this conclusion, as does direct inspection of the per-core |
I grabbed the settings from the Orange Pi 6 Plus DTB, and I'll review them. Thanks for pointing out that difference. While we're at it, could you also send me the cache topology from your board using the commands below, if they show the information?
thanks! |
After reviewing the comments, especially the information provided by @srcshelton, I realized that my previous PPTT implementation was still making an incorrect architectural assumption about the Cortex-A520 cluster. The original implementation modeled the efficiency cluster as having a shared 2 MiB L2 cache, resulting in the following hierarchy: However, this does not match what is described by the CIX documentation, the Linux Device Tree, nor the cache hierarchy exposed by the processor itself. According to the available documentation for the CD8160/CD8180 SoC, all twelve CPUs share a single 12 MiB DSU cache. The Device Tree also points every CPU toward the same top-level cache node. In addition, @srcshelton mentioned that reading the CLIDR_EL1/CCSIDR_EL1 registers directly indicates that the Cortex-A520 cores do not expose a private or shared L2 cache in the same way as the Cortex-A720 cores. Based on this information, I rewrote the PPTT generator. The main changes are:
The resulting hierarchy is now: The corresponding changes can be seen in the attached diff. After rebuilding the ACPI override and booting with the updated PPTT, Linux now reports:
This is significantly closer to the hardware topology described by the Device Tree and the available CIX documentation than the previous implementation. One interesting observation is that Linux now reports: instead of summing the placeholder nodes into the cache total. hwloc also renders these placeholder nodes as “0 KB” caches, which suggests this behavior comes from the Linux cacheinfo/PPTT parser rather than from the PPTT itself. At this point I believe the remaining question is how the Linux ACPI parser expects CPUs without a dedicated L2 cache to be represented inside PPTT while still maintaining the correct parent relationship to the shared DSU cache. I have attached both the updated Python generator and the corresponding diff so they can be reviewed. Finally, I would like to thank @srcshelton for pointing out the issue and providing the information about the cache hierarchy. That observation led to a much more accurate representation of the hardware topology. new script on: #43 (comment) |
|
I created this @srcshelton : Look: After instrumenting the kernel with a custom module that reads the architectural cache registers directly from every online CPU, we now have a much clearer picture of the actual cache hierarchy implemented by the CIX CD8160/CD8180. The Cortex-A720 cores (CPUs 0, 1, and 6 through 11) report CLIDR_EL1 = 0x54c3000123, which exposes a conventional three level hierarchy consisting of separate L1 instruction and data caches, a private unified 512 KiB L2 cache (CCSIDR_EL1 = 0x000003ff0000003a), and a shared unified 12 MiB L3 cache (CCSIDR_EL1 = 0x00003fff0000005a). In contrast, the Cortex-A520 cores (CPUs 2 through 5) report a completely different CLIDR_EL1 = 0x1482000023. These cores expose separate L1 instruction and data caches, followed by a unified cache whose CCSIDR_EL1 value is identical to the 12 MiB cache reported as L3 by the A720 cores, while reporting no L3 cache at all (CLIDR-type = 0 for level 3). In other words, the hardware itself presents the shared 12 MiB DSU cache as the last visible cache level for the A520 cluster, whereas the A720 cores expose the exact same physical cache as L3 behind their private 512 KiB L2 caches. This means both core types ultimately share the same 12 MiB DSU cache, but they expose different architectural views through CLIDR/CCSIDR. This observation explains why several PPTT layouts produced inconsistent results in lscpu and hwloc: the kernel attempts to reconcile the ACPI PPTT hierarchy with the cache topology reported by the processors themselves. The architectural registers are the definitive source of truth, and the dump confirms that any PPTT describing this SoC must accurately reflect these differing cache hierarchies instead of assuming that all cores expose identical cache levels. |
now: thanks again @srcshelton |
|
@coffnix on an MS-R1 from the Minisforum BIOS, this is what I get, its slightly different to what you posted above: 
Any idea why? L2 on mine shows as 4M in lscpu -C... |
3 participants
This pull request is related to issue #43:
#43
I attached a ready-to-use acpi_override.cpio to make validation easier.
It contains a corrected PPTT describing the proper cache hierarchy:
After applying the override, Linux, hwloc and XMRig all report the correct cache topology on the Orange Pi 6 Plus.
The acpi_override.cpio is provided only to simplify testing and validation of the fix. The actual firmware or ACPI source should be updated accordingly.