Hi Sahil, Sorry I missed replying to your last mail. I hope the below answers help.
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. > > 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 > > aunified > > 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. > > 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. > 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; 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. -Stafford > Thanks, > Sahil > > [1] > https://raw.githubusercontent.com/openrisc/doc/master/openrisc-arch-1.4-rev0.pdf > (Section 16.3)
