Hi,
On 2/20/25 11:42 AM, Stafford Horne wrote:
Hi Sahil,
Sorry I missed replying to your last mail.
No worries :)
On Wed, Feb 19, 2025 at 01:08:18AM +0530, Sahil Siddiq wrote:
Hi,
On 2/12/25 8:59 PM, Sahil Siddiq wrote:
Hi,
I have started working on implementing cacheinfo support for OpenRISC, and
I have got a few queries.
Q1.
Does OpenRISC support multilevel cache hierarchy? I couldn't find anything
in the architecture manual [1] mentioning the possibility of a multilevel
cache hierarchy. I wasn't able to find anything in the verilog implementation
either [2].
Currently all implementations support only a single level of cache. I think if
we would support multiple levels ever we could use device tree to define L2
caches, etc.
See for example:
Documentation/devicetree/bindings/cache/freescale-l2cache.txt
These are the device tree bindings for a freescale l2cache.
Got it, this makes sense.
Q2.
In /sys/devices/system/cpu/cpuX/cache, each indexY directory corresponds
to a CPU cache. According to the OpenRISC 1000 Architecture specification [1],
it is possible to have a unified cache. In such a case, registers controlling
the instruction and data cache represent the same thing (section 9.1 of the
manual).
Consequently, should there be only one index (i.e. index0), or should there
be 2 index directories (index0 and index1) with identical content? If a unified
cache is used, will the DCP and ICP bits both be set in the UPR register?
If we have a unified cache, I think there is actually no way to tell its unified
from the configuration registers. So I think we have to treat it as if we have
both iCache and dCache.
So we should have index0 and index1.
Understood. I guess another configuration register can be added in the future,
if ever there's a requirement to distinguish between a unified and split cache.
Q3.
Cache-related arithmetic performed in
arch/openrisc/kernel/setup.c:setup_cpuinfo() [3]
cannot be avoided. But we can expose this info in sysfs instead of cpuinfo as
specified in this mail [4]. So, I was thinking of moving these calculations to
arch/openrisc/kernel/cacheinfo.c in init_cache_level().
What are your thoughts on this?
Yes, I think so too.
Another thing I noticed in the current implementation is that these calculations
are performed for icache and dcache before using the UPR register to check if
they even exist. Should these calculations instead be performed after
determining
that they exist?
[...]
Yes, that would be better.
Thank you for the clarification.
Building on my previous mail, I noticed another thing:
On 1/25/25 1:00 PM, Stafford Horne wrote:
On my x86 machine I see:
$ tree /sys/devices/system/cpu/cpu0/cache/
/sys/devices/system/cpu/cpu0/cache/
├── index0
│ ├── coherency_line_size
│ ├── id
│ ├── level
│ ├── number_of_sets
│ ├── physical_line_partition
│ ├── shared_cpu_list
On or1k I only see (no cache info yet):
$ tree /sys/devices/system/cpu/cpu0/
/sys/devices/system/cpu/cpu0/
|-- of_node -> ../../../../firmware/devicetree/base/cpus/cpu@0
|-- subsystem -> ../../../../bus/cpu
|-- topology
| |-- core_cpus
| |-- core_cpus_list
| |-- core_id
| |-- core_siblings
| |-- core_siblings_list
| |-- package_cpus
| |-- package_cpus_list
| |-- physical_package_id
| |-- thread_siblings
| `-- thread_siblings_list
`-- uevent
But we do have some cache info available via cpuinfo:
$ cat /proc/cpuinfo | head -n16
processor : 0
cpu : OpenRISC-13
revision : 8
frequency : 20000000
dcache size : 256 bytes
dcache block size : 16 bytes
dcache ways : 1
icache size : 32 bytes
icache block size : 16 bytes
icache ways : 2
immu : 128 entries, 1 ways
dmmu : 128 entries, 1 ways
bogomips : 40.00
features : orbis32 orfpx32
While I can see icache and dcache info in /proc/cpuinfo, dmesg reports
that the caches have been disabled.
OF: reserved mem: Reserved memory: No reserved-memory node in the DT
CPU: OpenRISC-13 (revision 8) @20 MHz
-- dcache disabled
-- icache disabled
-- dmmu: 128 entries, 1 way(s)
-- immu: 128 entries, 1 way(s)
-- additional features:
-- power management
-- PIC
-- timer
This is because the value of upr is 0x719 and the value of SPR_UPR_DCP is
0x2. ANDing both values gives 0 which, according to the arch manual [1], means
there's no dcache. The same thing applies to icache.
If you are using qemu this is correct.
target/openrisc/cpu.c: cpu->env.upr = UPR_UP | UPR_DMP | UPR_IMP |
UPR_PICP | UPR_TTP | UPR_PMP;
Yes, I am using QEMU.
There is no cache in qemu as we use the actual host cpu cache to speed up
memory operations. You could modify qemu to help with testing your cacheinfo
changes though.
I'll modify QEMU in that case. It'll help verify that cache-related calculations
are performed correctly only after detecting they exist.
Thanks,
Sahil
