Re: Contributing to OpenRISC Linux

[Stafford Horne <shorne@gmail.com>]

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/1412084912-2767-1-git-send-email-sudeep.holla@arm.com/

> > > > 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