Re: Contributing to OpenRISC Linux

[Stafford Horne <shorne@gmail.com>]

On Sat, Jan 25, 2025 at 07:30:43AM +0000, Stafford Horne wrote:
> 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/

Hi Sahil,

Also please check these comments [0] from Sudeep Holla and Stefan Kristiansson.

    >> 14/03/17 13:11, Stefan Kristiansson wrote:
    >>> On Tue, Mar 14, 2017 at 12:08:33PM +0000, Sudeep Holla wrote:
    >>>> On Tue, Feb 21, 2017 at 7:11 PM, Stafford Horne <shorne@gmail.com> wrote:
    >>>>> From: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi>
    >>>>>
    >>>>> Motivation for this is to be able to print the way information
    >>>>> properly in print_cpuinfo(), instead of hardcoding it to one.
    >>>>>
    >>>>
    >>>> Any particular reason not to use generic cacheinfo sysfs infrastructure ?
    >>>>
    >>>
    >>> No reason as far as I can see, the creation of this patch predates the
    >>> generic cacheinfo sysfs infrastructure.
    >>>
    >>> The patch itself doesn't add cache information to cpuinfo though,
    >>> only corrects a bug in the information that is already there.
    >>>
    >>> We should look into exposing the info in the generic cache info sysfs
    >>> and potentially removing the information from cpuinfo.

-Stafford

[0[] https://lkml.org/lkml/2017/3/14/639

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