Fwd: Upstream Linux-on-LiteX kernel patches?

[Tim 'mithro' Ansell]

---------- Forwarded message ---------
From: Drew Fustini <pdp7...@gmail.com>
Date: Tue, 7 Jan 2020 at 12:20
Subject: Upstream Linux-on-LiteX kernel patches?
To: <cra...@pm.me>, mhol...@antmicro.com <mhol...@antmicro.com>, Filip Kokosinski <fkoko...@antmicro.com>, Robert Winkler <rwin...@antmicro.com>, Daniel Craviee <dcra...@internships.antmicro.com>
Cc: <se...@xobs.io>, Tim Ansell <mit...@mithis.com>, <flo...@enjoy-digital.fr>, <marek...@gmail.com>

Hello, I recently started using Linux-on-LiteX with an ECP5 board [0]
and Tim (mithro) pointed me to the Linux kernel patches that are used
for it [1].  I am writing you as your names are in the git log for
that directory.

I am curious if there has been any activity so far to get these
patches into the upstream kernel.  The PWM driver [2] looks reasonable
and seems like it would make sense to post to the PWM mailing list
[3].

Thank you,
Drew

[0] https://blog.oshpark.com/2019/12/20/boot-linux-on-this-hackaday-supercon-badge-with-this-sdram-cartridge/
[1] https://github.com/litex-hub/linux-on-litex-vexriscv/tree/master/buildroot/board/litex_vexriscv/patches/linux
[2] https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/buildroot/board/litex_vexriscv/patches/linux/0010-pwm-add-LiteX-PWM-driver.patch
[3] https://www.spinics.net/lists/linux-pwm/

[Joel Stanley]

Hi Drew,

> Hello, I recently started using Linux-on-LiteX with an ECP5 board [0]
> and Tim (mithro) pointed me to the Linux kernel patches that are used
> for it [1]. I am writing you as your names are in the git log for
> that directory
>

> I am curious if there has been any activity so far to get these
> patches into the upstream kernel. The PWM driver [2] looks reasonable
> and seems like it would make sense to post to the PWM mailing list
> [3].

I assume that you're using it with a riscv CPU?

I wrote the ethernet driver a few years ago, running on or1k. It found
it's way into common use without being complete (it never freed
incoming data, so would OOM the machine after a period of time). This
got fixed at some point. The last I saw it had some hacks applied to
have it run without a interrupt controller, as I assume the riscv soc
lacked this hardware.

I would like to test it and send it out. To do this we need some
gateware to run it on. I don't have a supercon badge, so I would be
looking to test on an arty. Can you point me towards some gateware?

I will put together a kernel tree to test on. From there we can also
test the ethernet and pwm drivers and send them off for the 5.6 merge
window.

Cheers,

Joel

[Drew Fustini]

On Wed, Jan 8, 2020 at 9:18 AM Joel Stanley <jo...@jms.id.au> wrote:
> > Hello, I recently started using Linux-on-LiteX with an ECP5 board [0]
> > and Tim (mithro) pointed me to the Linux kernel patches that are used
> > for it [1]. I am writing you as your names are in the git log for
> > that directory
> >
> > I am curious if there has been any activity so far to get these
> > patches into the upstream kernel. The PWM driver [2] looks reasonable
> > and seems like it would make sense to post to the PWM mailing list
> > [3].
>
> I assume that you're using it with a riscv CPU?

Yes, the VexRiscV:
https://github.com/litex-hub/linux-on-litex-vexriscv

> I wrote the ethernet driver a few years ago, running on or1k. It found
> it's way into common use without being complete (it never freed
> incoming data, so would OOM the machine after a period of time). This
> got fixed at some point. The last I saw it had some hacks applied to
> have it run without a interrupt controller, as I assume the riscv soc
> lacked this hardware.
>
> I would like to test it and send it out. To do this we need some
> gateware to run it on. I don't have a supercon badge, so I would be
> looking to test on an arty. Can you point me towards some gateware?

Tim - do you have suggestion of the gateware to use for testing?

> I will put together a kernel tree to test on. From there we can also
> test the ethernet and pwm drivers and send them off for the 5.6 merge
> window.

Thanks,
Drew

[Drew Fustini]

Mateusz, thank you for the detailed explanation of the work that has
been done so far.

Would the work that has been done on UART driver for mor1kx also work
for VexRiscV?

Is this something where I can help by testing with Linux-on-LiteX-VexRiscv?

I'm cc'ing linux...@googlegroups.com now that I know it exists.

thanks,
drew

On Wed, Jan 8, 2020 at 8:43 AM Mateusz Holenko <mhol...@antmicro.com> wrote:
>
> Hi Drew!
>
> We started the effort by creating a patchset with the UART driver and
> plan to follow with another one - openrisc (mor1kx-based) platform.
>
> The driver has already been reviewed twice, you can access the latest
> patchset here: https://lore.kernel.org/patchwork/cover/1143352.
>
> We are currently working on a modification to LiteX UART core that
> provides additional CSR which could be used to detect endianness of
> the system at runtime (as suggested in one of the comments). Adding a
> CSR in LiteX is very simple, but it results in changing of the layout
> of generated registers (which breaks the model in our simulation
> framework - Renode - https://renode.io), so we are also working on a
> more general approach that would allow to extend LiteX cores in a
> deterministic manner. Having this done, we will move forward with the
> V3 of the UART patchset.
>
> Best regards,
> Mateusz

>
> On Tue, Jan 7, 2020 at 8:20 PM Drew Fustini <pdp7...@gmail.com> wrote:
> >
> > Hello, I recently started using Linux-on-LiteX with an ECP5 board [0]
> > and Tim (mithro) pointed me to the Linux kernel patches that are used
> > for it [1]. I am writing you as your names are in the git log for

> > that directory.

> >
> > I am curious if there has been any activity so far to get these
> > patches into the upstream kernel. The PWM driver [2] looks reasonable
> > and seems like it would make sense to post to the PWM mailing list
> > [3].
> >

> > Thank you,
> > Drew
> >
> > [0] https://blog.oshpark.com/2019/12/20/boot-linux-on-this-hackaday-supercon-badge-with-this-sdram-cartridge/
> > [1] https://github.com/litex-hub/linux-on-litex-vexriscv/tree/master/buildroot/board/litex_vexriscv/patches/linux
> > [2] https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/buildroot/board/litex_vexriscv/patches/linux/0010-pwm-add-LiteX-PWM-driver.patch
> > [3] https://www.spinics.net/lists/linux-pwm/
>
>
>

> --
> Mateusz Holenko
> Antmicro Ltd | www.antmicro.com
> Roosevelta 22, 60-829 Poznan, Poland

[Florent Kermarrec]

Hi all,

thanks for the effort in this! just a few things:

@Mateusz: for additional CSR in LiteX UART, as Tim suggests the feature is already in SoCController:
https://github.com/enjoy-digital/litex/blob/master/litex/soc/integration/soc_core.py#L46-L49SoCController
I think the features that are in the SoC to ease CPU/software support should be located in a single module
and we should avoid duplicating it in the different cores.

Also upstreaming things is very good, but we also have to be aware that we will loose some flexibility
we currently have with patches, so we really need to think now how we can facilitate the work in the
future with drivers already upstreamed:

- As @Mateusz says, it's easy to add CSR in LiteX and it works well when software is also build directly
with LiteX. But when drivers and OSes are involved and when software can't be recompiled, we loose
some flexibility. For now, it's possible to give fixed location to CSR regions, but it's not possible
to give fixed location for the CSR of a Module (this is determined automatically). I'm happy to work
with you on that @Mateusz since i also wanted to remove this limitation. Feel free to create an issue
or PR on LiteX so that we can work on that together.

- It can take some time and some iterations to find a good gateware/software architecture, so i think
we should only upstream things for which we already have a good feedback. I'm not aware of how much
work is needed to upstream patches to the kernel but i'd just like to avoid a situation where we have
new ideas to improve the gateware but just don't change things just because the drivers is already
upstreamed and it's too much work to change it. Having kernel developers involved in the process would
be very valuable.

- An argument against reactions like the ones we saw when posting the Linux-on-LiteX-Vexriscv results:
"why aren't you using the regular UART16550 drivers" and that we will probably have again, is that
here both gateware and software are flexible and we can take advantage of that to be simple/efficient
on both: Most of the cores were developed to be simple and minimal on the gateware side to take
advantage of the software, but if things needs to be changed on the gateware to assist the software,

simplify the driver or just be similar to others drivers, it's possible and things can be discussed.

@Joel: For the Arty, there are pre-built bitstreams in:
https://github.com/litex-hub/linux-on-litex-vexriscv-prebuilt
You should be able to just use the prebuilt FPGA bitstreams and kernel images. Then if you want
to work on the LiteEth driver, just re-compiling the kernel with buildroot should be enough, no need
to re-generate the gateware.

Florent

--
You received this message because you are subscribed to the Google Groups "Linux for LiteX FPGA SoC" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-litex...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-litex/CAEf4M_DqA3dVaw%3D%2BiDFBVMF2-FHK6SzMN-YbCMqGKXUZ-g38HQ%40mail.gmail.com.

[Hasjim Williams]

Hi all,

I was planning on working on this, this week.

And hope to give a small talk on it, next Tuesday at linux.conf.au 2020:

https://lca2020.linux.org.au/schedule/presentation/214/

Hopefully we can get some other kernel developers involved in the process.

Hasjim

To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-litex/CA%2B96J6KgktNrinA3osnTKTXnh5d6xgboT7J%3DmGAcdVTEf%2Bo1MQ%40mail.gmail.com.

[Joel Stanley]

On Wed, 8 Jan 2020 at 11:21, Florent Kermarrec <flo...@enjoy-digital.fr> wrote:
>
> @Joel: For the Arty, there are pre-built bitstreams in:
> https://github.com/litex-hub/linux-on-litex-vexriscv-prebuilt
> You should be able to just use the prebuilt FPGA bitstreams and kernel images. Then if you want
> to work on the LiteEth driver, just re-compiling the kernel with buildroot should be enough, no need
> to re-generate the gateware.

Thanks for the link.

There doesn't appear to be a way to link the bitstream back to the
source it was compiled from. How do I discover the csr layout for a
given bitstream?

Cheers,

Joel

[Florent Kermarrec]

There doesn't appear to be a way to link the bitstream back to the
source it was compiled from. How do I discover the csr layout for a
given bitstream?

You can use the files attached (or if you only have LiteX installed, no need for Vivado, just do: ./make --board=arty to regenerate them).

Florent

[Hasjim Williams]

LiteX BIOS should print the revs of part of the trees used, IIRC.

-- 

You received this message because you are subscribed to the Google Groups "Linux for LiteX FPGA SoC" group.

To unsubscribe from this group and stop receiving emails from it, send an email to linux-litex...@googlegroups.com.

To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-litex/CACPK8Xckn8ydGnxHp1K2AckadSY98%2B0BN0Qm3p9BHCQVZaVn5A%40mail.gmail.com.

[Joel Stanley]

Thanks, that worked for me.

Taking a look at the generated deice tree snippet:

mac0: mac@f0003800 {
compatible = "litex,liteeth";
reg = <0x0 0xf0003800 0x0 0x7c
0x0 0xf0003000 0x0 0x0a
0x0 0xb0000000 0x0 0x2000>;
tx-fifo-depth = <2>;
rx-fifo-depth = <2>;
};

The ethernet device still lacks an IRQ. When we used the peripheral in
the or1k soc it had one. Can we get that hooked up for the riscv?

[Mateusz Holenko]

VexRiscv has a custom IRQ handling, based on non-standard CSRs - we
have recently created a Linux driver for VexRiscv's IRQ controller:
https://github.com/litex-hub/linux-on-litex-vexriscv/blob/master/buildroot/board/litex_vexriscv/patches/linux/0013-drivers-irqchip-add-VexRiscv-interrupt-controller-driver.patch.

In the generated device tree you should find "intc0" node that
represents the controller, so the liteeth's irq can be routed there:

mac0: mac@f0003800 {
compatible = "litex,liteeth";
reg = <0x0 0xf0003800 0x0 0x7c
0x0 0xf0003000 0x0 0x0a
0x0 0xb0000000 0x0 0x2000>;
tx-fifo-depth = <2>;
rx-fifo-depth = <2>;

interrupt-parent = <&intc0>;
interrupts = <0x03>;
};