lowRISC kernel changes rebased over stock 4.19
by Gabriel L. Somlo
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)!
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" :)
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:
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 :)
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@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>;
==========================================================================
...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 :)
Please let me know what you think.
Regards,
--Gabriel
4 years, 4 months
Simulation of lowRISC refresh-v0.6
by Lucien Anti-Spam
Hi devs,
I was sort of bashing my way through the v0.5 for simulation when v0.6 came out. I thought it would be an easy move over; however it appears it maybe untested/broken?
There seem to have been quite a bit of folder and tech movement. Here is what I noticed initially
vcs/vsim folders:* Immediately I noticed the rule for "lowrisc_srcs" is wrong but can be fixed with $(MODEL) vs $(PROJECT),* then I noticed that the constants are no longer from scala but a hard-coded set (aww, scala way was quite sexy),* and then I noticed the verilog_srcs didnt match up any more, and I stopped here.
Whats the general thoughts on simulation now?
Cheers,Luc
4 years, 4 months
building lowRISC binaries with current riscv-gnu-toolchain?
by Gabriel L. Somlo
Hi,
I'm trying to bring together a reasonably current hardware+software
riscv environment, and lowRISC (on nexys4-ddr) appeared to be the most
likely candidate :)
So I managed to replicate the entire from-source build process for
"lowrisc-chip-ethernet-v05", including the bitstream (with Vivado),
and riscv-tools (riscv-fesvr, riscv-isa-sim, riscv-gnu-toolchain,
busybox, the kernel, and the bbl bootloader).
I also managed to build poky, but as it turns out I can leave that
out, and still get a minimal busybox-in-initramfs working, bootable
system.
So far, so good.
I would, however, like to move toward upgrading this system to more
modern/recent/upstream components.
Busybox is easy, I can build 1.28.3 (currently the latest) with the
included toolchain, and things are still OK.
This is where I got stuck, though:
I can't build a more recent kernel (e.g. 4.19-rc8) with the included
toolchain.
So I grabbed the sources for https://github.com/riscv/riscv-gnu-toolchain
and built it for multilib, including "rv64imafd-lp64" which I believe
"should" work on the lowRISC implementation of the ISA.
However, if I try building a statically linked busybox binary with the
new/upstream toolchain, I'm getting either a signal-7 bus error or a
signal-4 illegal opcode error from the existing (working) lowRISC
kernel.
I noticed that, when using "file" on Fedora28, busybox compiled with
the lowRISC version of the toolchain looks like this:
busybox: ELF 64-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically linked, for GNU/Linux 2.6.32, stripped
whereas the one compiled with the new upstream toolchain says:
busybox: ELF 64-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically linked, for GNU/Linux 3.0.0, stripped
I haven't dug into it any further so far. I'm wondering though, did I
get the "-march=rv64imafd -mabi=lp64" right? I also tried "-mabi=lp64d"
without success. These were selected based on the "RV64G" string spit
out by /proc/cpuinfo.
Any help or clue as to what I'm doing wrong much appreciated.
Is there a better way to get to a relatively up-to-date
(ISA-bitstream, toolchain, kernel, busybox) tuple (e.g. with a
different board?)
Thanks much,
--Gabriel
4 years, 4 months
