What do you use Debian for (in lowrisc)?
by Manuel A. Fernandez Montecelo
Hi,
I was surprised the other day to learn that you run Debian in
lowrisc-based devices, I thought that you would be using buildroot or
some similar embedded distro.
So I got curious... what do you use it for? Just to have a base system
and basic tools, but less basic than buildroot? To run specialised
things on top of that base, like tests, benchmarks or special programs?
To test many areas, e.g. run many software and see impact on performance
or whether the software can run at all and crashes?
Also, if we can do something specific for you to help you with your
tasks, please tell.
Cheers.
--
Manuel A. Fernandez Montecelo <manuel.montezelo(a)gmail.com>
4 years, 5 months
rebasing to current rocket-chip git master
by Gabriel L. Somlo
Hi Jonathan,
I managed to build a working lowRISC bitstream using the
latest/current sources from github.com/freechipsproject/rocket-chip
I tried to sort through the changes as best as I could (not familiar
with Chisel/Scala, so lots of mental interpolation :) Any comments and
feedback that would help us come up with a better split and/or better
commit blurbs that would explain what's going on would be, as always,
much appreciated:
https://github.com/gsomlo/rocket-chip/tree/gls-lowrisc-v00
The only modification to the lowrisc top-level project was this:
========================================================
diff --git a/vsrc/AsyncResetReg.v b/vsrc/AsyncResetReg.v
index abb9fef..6bca7dc 100644
--- a/vsrc/AsyncResetReg.v
+++ b/vsrc/AsyncResetReg.v
@@ -33,11 +33,12 @@ module AsyncResetReg (
input clk,
input rst);
+parameter RESET_VALUE = 0;
always @(posedge clk or posedge rst) begin
if (rst) begin
- q <= 1'b0;
+ q <= RESET_VALUE;
end else if (en) begin
q <= d;
end
========================================================
... which should be a no-op if built against the current v0.6 tree.
Thanks,
--Gabriel
4 years, 6 months
[riscv-pk rebase 0/7] RFC: lowRISC changes vs. upstream riscv-pk
by Gabriel L. Somlo
Hi,
I have made an attempt to isolate lowRISC changes against upstream
riscv-pk, along the same principle discussed in the linux-4.19 thread
over the past few days. The meaningful lowRISC specific modifications
against upstream are available online at
https://github.com/gsomlo/riscv-pk/tree/gls-lowrisc-181102-v00
However, I thought it might make sense to send them out to the mailing
list as well, so that we may discuss them individually -- particularly
the ones I'm unsure I actually understand :)
The first two patches I'm fairly comfortable with, containing the
addition of the hardcoded Device Tree blob, and, respectively, support
for lowRISC's particular flavor of UART.
Patches 3..7 are the ones I either can't test (e.g., FreeBSD support),
or can't figure out why they would be needed (I can build bbl -- a.k.a.
boot.bin, even if I leave them out -- and it works great! :)
Would the lowRISC devs please be so kind and reply to each individual
patch with an appropriate explanation of why we would want to keep it,
and, if so, details on why it's needed and how it goes about meeting
that stated goal?
I'm volunteering to curate those replies and publish a re-spin of the
patch set on github, complete with informative commit blurbs, where it
should be available to everyone, in particular lowRISC devs if/when
there's interest in switching to an upstream + rebased changes model.
Thanks much,
--Gabriel
Gabriel L. Somlo (7):
lowrisc: add hard-coded custom device tree description
lowrisc: support for probing/utilization of lowRISC-specific UART
lowrisc: RFC: update for FreeBSD compatibility
lowrisc: RFC: add "-g" to CFLAGS and LDFLAGS in Makefile, configure
lowrisc: RFC: zero out bss after gdb load
lowrisc: RFC: change MAX_HARTS to 1, even if atomics are available
lowrisc: RFC: don't probe for Host Target Interface (htif)
Makefile.in | 7 ++-
bbl/bbl.c | 2 +-
bbl/bbl.lds | 1 +
configure | 4 +-
configure.ac | 2 +-
machine/lowrisc.dts | 123 ++++++++++++++++++++++++++++++++++++++++++
machine/machine.mk.in | 4 +-
machine/mentry.S | 26 +++++++--
machine/minit.c | 3 +-
machine/mtrap.c | 27 ++--------
machine/mtrap.h | 2 +-
machine/uartLR.c | 38 +++++++++++++
machine/uartLR.h | 14 +++++
pk/frontend.c | 2 +-
pk/pk.lds | 1 +
15 files changed, 220 insertions(+), 36 deletions(-)
create mode 100644 machine/lowrisc.dts
create mode 100644 machine/uartLR.c
create mode 100644 machine/uartLR.h
--
2.17.2
4 years, 7 months
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, 7 months
