[lowrisc-dev] Re: lowRISC kernel changes rebased over stock 4.19

Dr Jonathan Kimmitt jrrk2 at cam.ac.uk
Tue Oct 30 21:04:36 GMT 2018

Sent from my iPhone

> On 30 Oct 2018, at 19:02, Gabriel L. Somlo <gsomlo at gmail.com> wrote:
> Hi Jonathan,
> First off, thank you and all other lowRISC developers for v0.6 (and also
> for your earlier hard work making this system available)!
You are welcome. It means a lot for somebody to embrace our work so enthusiastically.

> I am working on a project where I need to get pretty deep under the hood,
> and actually understand how everything hangs together. For that kind of
> effort, I think it would be a huge help to distill changes from standard,
> upstream projects to a concise, minimally invasive patch set rebased
> over latest upstream versions, in a way that can be easily kept distinct
> and up-to-date as the upstream projects evolve.
> I've managed to successfully use https://github.com/riscv/riscv-gnu-toolchain
> directly to build every other component of lowRISC v0.6 (specifically
> busybox, the kernel, and bbl). That makes it possible to ignore any current
> differences between the toolchain fork included in rocket-chip/riscv-tools
> and "upstream" :)
The Rocket core repository has a dire warning against using anything other than their tools, but I guess that dates back to the days when CSR numbers were rather unstable.

> Next, I looked at the kernel, and tried to figure out how I can ignore
> everything that is *not* lowRISC, and focus only on the specific bits that
> *are*! So I came up with the following set of six patches on top of the
> latest (4.19) upstream kernel:

The LowRISC-QuickStart repo has some patches similar to yours based on the 4.18 kernel. The 4.19 was not out when those were prepared.
>    https://github.com/gsomlo/riscv-linux/tree/gls-lowrisc-4.19-v00
> This is exactly six commits added to stock upstream:
>    1/6: keyboard driver (uart and ps2-over-usb)
>    2/6: vga console driver
>    3/6: xilinx/nexys4ddr ethernet driver
>    4/6: microSD card reader
>    5/6: GPIO driver (inserted on top of microSD driver .c file)
>    6/6: lowRISC-specific defconfig (separate from default RISC-V defconfig)
> I specifically avoided cleaning up indentation and running anything
> through checkpatch, to give you a chance to ensure these are roughly the
> same files as what's currently present in lowrisc's own v0.6 fork of the
> linux source tree (okay, I removed some trailing whitespaces, but
> managed to contain my OCD from making further changes *beyond* that :)
I’ve been using emacs to edit my source code since 1987. It tends to be over enthusiastic about blanks.

> With the following patch against riscv-pk's lowrisc.dts:
> ==========================================================================
> diff --git a/machine/lowrisc.dts b/machine/lowrisc.dts
> index 6e3c4c2..13a79e5 100644
> --- a/machine/lowrisc.dts
> +++ b/machine/lowrisc.dts
> @@ -14,6 +14,7 @@
>    cpus {
>        #address-cells = <1>;
>        #size-cells = <0>;
> +        timebase-frequency = <500000>;
>        cpu at 0 {
>            clock-frequency = <0>;
>            compatible = "sifive,rocket0", "riscv";
> @@ -33,7 +34,6 @@
>            reg = <0>;
>            riscv,isa = "rv64imafdc";
>            status = "okay";
> -            timebase-frequency = <500000>;
>            tlb-split;
>            L3: interrupt-controller {
>                #interrupt-cells = <1>;
> ==========================================================================
The capability to have different cpus at different clock rates arrived rather late in the day.
> ...it is possible to avoid touching arch/riscv/kernel/time.c and/or
> drivers/clocksource/riscv_timer.c altogether, and use the unmodified
> upstream clock initialization code path.
> I've built and tested this successfully on the nexys4ddr (with only
> busybox for now), using the latest 4.19 kernel and standard
> riscv/riscv-gnu-toolchain:
>  make ARCH=riscv lowrisc_defconfig
>  cp ../initramfs.cpio .
>  make ARCH=riscv CROSS_COMPILE=riscv64-unknown-linux-gnu-
> ... then built the bbl (boot.bin) file after applying the above
> mentioned patch to the device tree source file.
> I'd like to run the newly introduced .[ch] files through
> scripts/checkpatch.pl and generally bring them up to kernel coding
> standards, but wanted to get your overall opinion, thoughs, and
> feedback before I started doing anything like that :)

Your assistance is gratefully received, and I get the idea behind rebasing to 4.19, but what about Synchronization with a particular version of Verilog? Would you want to add a version register in each Verilog device to ensure the Linux driver matches the hardware description during booting?

For the same reason the kernel maintainer might not be too enthusiastic about integrating and maintaining something as ephemeral as an FPGA net list.

> Please let me know what you think.

I think cutting down the size of the needed eco system is an excellent notion. If you could share more details of your intended application that would be especially interesting for us.

> Regards,
> --Gabriel


More information about the lowrisc-dev mailing list