On Thu, Jan 23, 2025 at 12:25:59AM +0530, Sahil Siddiq wrote:
> Hi,
>
> On 1/13/25 12:01 PM, Stafford Horne wrote:
> > On Mon, Jan 13, 2025 at 11:42:08AM +0530, Sahil Siddiq wrote:
> > > Hi,
> > >
> > > Thank you for your reply.
> > >
> > > On 1/12/25 12:58 PM, Stafford Horne wrote:
> > > > Hi Sunil,
> > > >
> > > > +CC List
> > > >
> > > > yes, the cacheinfo task is still open. There are many things that are
> > > > still not
> > > > implemented in OpenRISC, you can always just look under the kernel
> > > > Documentation/features.
> > > >
> > > > For example:
> > > >
> > > > < shorne@antec ~/work/linux > grep -r -e openrisc.*TODO
> > > > Documentation/features | column -t
> > > > Documentation/features/vm/huge-vmap/arch-support.txt:
> > > > | openrisc: | TODO |
> > > > Documentation/features/vm/ELF-ASLR/arch-support.txt:
> > > > | openrisc: | TODO |
> > > > Documentation/features/vm/ioremap_prot/arch-support.txt:
> > > > | openrisc: | TODO |
> > > > Documentation/features/vm/pte_special/arch-support.txt:
> > > > | openrisc: | TODO |
> > > > Documentation/features/perf/kprobes-event/arch-support.txt:
> > > > | openrisc: | TODO |
> > > > ...
> > >
> > > Got it. I did find this list in the online documentation [1] but I
> > > couldn't find
> > > the cacheinfo task listed there.
> >
> > Right, not all features have config flags that are documented.
> >
>
> Understood. Do you know how one finds these flags? I wasn't able
> to find much related to cpu or caches in arch/openrisc/Kconfig [1].
> I did find the usage of ARCH_HAS_CPU_CACHE_ALIASING in
> include/linux/cacheinfo.h [2]. I am not sure if this is relevant.
Not all features are enabled using ARCH_ flags. The cacheinfo apis are always
enabled and compiled, even for or1k now. But if we look, we see the default
implementation is defined with __weak symbols:
drivers/base/cacheinfo.c
include/linux/cacheinfo.h
int __weak init_cache_level(unsigned int cpu)
{
return -ENOENT;
}
int __weak populate_cache_leaves(unsigned int cpu)
{
return -ENOENT;
}
In order for us to add support I think all we will need to do is define these
functions under arch/openrisc.
We can look to cpuinfo_or1k for how in openrisc we can pull cache details from
the UPR registers in (we can maybe just get the info from the cpuinfo_or1k
structure):
arch/openrisc/kernel/setup.c
You can read about the background of the cacheinfo work and motivations in the
original patch series:
https://lore.kernel.org/all/[email protected]/
> > > > How far have you come with OpenRISC so far? If you haven't already I
> > > > suggest
> > > > working through:
> > > >
> > > > - Get a simulator, I use QEMU for most development as it's faster
> > > > and supports
> > > > more memory than most FPGA. Final verification can be done on an
> > > > FPGA.
> > > > - Get a working compiler toolchain.
> > > > - Compile and boot the openrisc kernel.
> > > > - Build a userspace environment, either buildroot, toybox or busybox.
> > > >
> > > > I have some tools to help with this in or1k-utils [1], also there are
> > > > prebuilt
> > > > environments and docs in the linux kernel [2] and qemu [3].
> > >
> > > I don't have an environment set up yet. I'll start with the steps above.
> > > I'll use
> > > QEMU for development. I don't have an FPGA with me currently.
>
> I have set up a fairly basic environment. I built both QEMU and
> openrisc-linux from the master branch. I used a prebuilt compiler
> toolchain to build openrisc-linux and busybox, and manually
> created an initramfs image. I used the default configuration
> options to build linux.
>
> The userspace environment only has utilities that are provided
> by busybox. Only the following filesystems have been mounted -
> rootfs, devtmpfs, sys, proc and tmpfs.
>
> I tried to understand the workings of some of the scripts in
> or1k-utils. There were a few things that I didn't understand
> and I'll need some more time to wrap my head around them. I
> don't think this should hinder the cacheinfo task though.
>
> Is there anything else that I'll need to set up in the environment
> before progressing?
I think its a good start. As long as /sys is available in your environment
it should be enough for you to test your changes.
> I don't see any cache-related info in /sys. Based on what I have
> understood, it'll be possible to fetch these details once cacheinfo
> is supported.
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
> > > > At the momoment, I am also thinking of what to work on next for
> > > > OpenRISC, there is:
> > > >
> > > > - kexec
> > > > - jump_label
> > > > - kprobes
> > > > - perf_events
> > > > - ftrace
> > >
> > > Is the virtio task [2] also still a part of the roadmap? I can't find
> > > that either
> > > in the TODO list.
> >
> > The virtio task is still possible but will be more advanced and may need
> > some
> > architecture changes to support hypervisors.
>
> Got it.
I am slowly working on kexec support right now.
-Stafford
