MP-Rocketchip system communication
by Stefano Cillo
Good afternoon,
we are trying to implement a generic Rocketchip multiprocessor system with
accelerators, interconnected by a NoC.
We are currently designing the system on the Zedboard and trying to understand
the communication between the ARM core and the Rocketchip through the frontend
server. We'd like to put two (or more) Rocketchips on the AXI bus with
different addresses and configure them to execute different programs using
separate DDR spaces.
The problem is that if, in Vivado, we change the Rocketchip memory address
space from 512MB to 256MB it doesn't work. Therefore we are analyzing frontend
server code to understand where the RISC-V executable is loaded (in the fesvr-
code, and exactly at which address). We found the LOAD_ELF macro inside
elfloader.cc, which calls memif->write, which in turn calls htif->
[read|write]_packet, which finally calls htif_zedboard->write: this last
function however seems to write always to the same AXI address, that is the
Rocketchip starting address on the AXI bus.
We then would appreciate any hint on the files or functions responsible of the
ELF load address and the starting address of the Rocketchip execution, in order
to be able to change that address for each different Rocketchip and make the
cores run in parallel executing different programs.
We are aware that the fesvr is capable to run only one Rocketchip at a time,
and solve its system calls, but we will consider that problem later on.
Many thanks,
Stefano Cillo
7 years, 2 months
device tree
by Jamey Hicks
I've been working on RISC-V system integration with Bluespec and Draper. In
order to speed up testing, I'm running the kernel in qemu but have
connected it to peripherals on an FPGA.
https://github.com/cambridgehackers/riscv-qemu
Right now I'm just doing system integration, rather than developing new
peripherals. My goal was not to have to modify any drivers. I'm using BSV
to integrate Xilinx IP cores and Connectal to connect the software to the
hardware.
https://github.com/cambridgehackers/connectal/tree/master/tests/spikehw
I have a UART and the Xilinx AXI Interrupt Controller working and I'm
debugging a problem with the AXI I2C Controller device driver.
Without changing the software or BSV, I could connect qemu to bluesim or
Verilator.
Looking at qemu, it would be cool if it populated its device models based
on the device tree, so that one could emulate something that matched the
hardware.
I'm thinking about how to derive the hardware from some sort of
device-tree-ish specification.
If any of this is helpful to someone working on GSoC or anything else, I
would be happy to discuss the approach and the code.
Cheers,
Jamey Hicks
7 years, 2 months
[GSoC_16] Porting Xinu/xv6 to the lowRISC platform
by Shibjash Dutt
Hi,
I'm a student interested in porting either Xinu or xv6 to the
lowRISC platform, as part of this year's Google Summer of Code.
There was a thread posted earlier by another interested student, and a
subsequent
followup by asb. However, I have some questions of my own and would be glad if
the dev team could shed some light on them.
1) Alex Bradbury says targeting Spike or QEMU should be OK. As far as Spike is
concerned, how complete is it or expected to get? AFAIK Spike is somewhat
behind on some stuff, like tagged memory and full peripheral support. If my
project works on Spike, will it run (mostly) unmodified on the hardware?
2) I've built the GNU toolchain, Spike and the kernel. So far, it's pretty bare
bones and all the functionality is exposed through the HTIF. Are there any
short term plans to standardize an interface?
3) Apart from Wei Songs's excellent tutorial accompanying the v0.2 release,
and the phabricator wiki, are there any other sources of information or
documentation? Or is it read the code and figure it out :P
4) How strong would be the interest in such a project?
Thanks,
Shibjash
7 years, 3 months
Interested in GSoC opportunity [porting teaching os]
by Deepankar Tyagi
Hi,
I am a computer science student at undergrad level and would love to
contribute to lowRISC development efforts by porting a teaching OS.
I am currently in process of drafting proposal, this mail is an effort to
seek guidance in order to define goals, scope and timeline of project.
Read the tutorials to figure out how to set up development and testing
environment.
However somethings are not clear,
On the ideas page the statement is "Porting one of these to RISC-V and to
the lowRISC platform..."
#1 Since lowRISC is RISC V based then will porting process be different for
RISC V and lowRISC ?, also the toolchain in tutorial also mentions RISC V
only.
#2 Also I would be grateful if mentor(s) can give insight on what should be
deliverable by GSoC midterm.
#3 Does the mentor(s) have any preference between xv6 and xinu ?
#4 I do not have a FPGA board and will be developing / testing on
simulator, is that alright?
#5 Is there a preferred means to get/see the progress reports ?
Prior (relevant) experience:
My Last year GSoC project involved porting libevent and tor to a new
platform, full details about the same can be seen at
https://deepankar.io/gsoc.
Have also dealt with complex build systems, cross compilations and tweaked
parts of kernel , one such "experiment" is listed at
https://deepankar.io/experiments/details/android_kernel.
Never done a project exactly of this sort.
Some hyperlinks
Github <https://github.com/codebuff> || Linkedin
<https://www.linkedin.com/in/codebuff> || deepankar.io
Best Regards.
*Deepankar Tyagi*
7 years, 3 months
musl risc-v port & gsoc - resources & ideas
by Rich Felker
lowrisc.org has been accepted into Google Summer of Code 2016, and has
porting musl to risc-v as one of the suggested projects:
http://www.lowrisc.org/docs/gsoc-2016-ideas/
I'm very hopeful that we'll make the port happen this year. In this
email I'd like to go over some resources that may be helpful to
students interested in applying, and some ideas for other tasks that
could be included in proposals.
The musl wiki contains a porting page with some useful but
not-entirely-up-to-date information on porting musl to a new arch.
This is a good starting point, and updating it could actually be part
of the gsoc project. See http://wiki.musl-libc.org/wiki/Porting
Some information on recent changes can be found in the mailing list
archives. These threads pertain to changes to how ports are expected
to provide atomic primitives:
http://www.openwall.com/lists/musl/2015/05/17/2
http://www.openwall.com/lists/musl/2015/05/20/1
http://www.openwall.com/lists/musl/2016/01/10/6
which was committed here:
http://git.musl-libc.org/cgit/musl/commit/?id=1315596b510189b5159e742110b...
and other subsequent commits with per-arch improvements.
And these cover the bits deduplication:
http://www.openwall.com/lists/musl/2016/01/25/1
http://www.openwall.com/lists/musl/2016/01/27/9
which was committed here:
http://git.musl-libc.org/cgit/musl/commit/?id=4dfac11538cb20c848c30d75486...
Threads on the recent mips64 port work, which is almost ready for
merging, may also be helpful to read. It's broken up across several
threads but you can find most of the content in the January-March 2016
archives.
Since a port of musl to a new arch does not actually involve much
code, mainly attention to detail to make sure that all of the type
definitions/ABI/etc. are correct, I think that for a proposal to be
big enough to make a reasonable GSoC project, it should go beyond just
the basic porting. Some ideas for things to include would be:
- Improvement of porting documentation
- Feedback/patches on where there's too much redundancy between ports
and how to reduce it (i.e. making improvements to musl that reduce
the amount of code/headers needed for a new port).
- Patches for musl-cross and/or musl-cross-make (build systems for
generating a cross-compiler toolchain) to make it easy to build a
musl/riscv cross compiler.
- Optimizing performance-critical code like memcpy or floating point
math functions for riscv.
- Improving test coverage, especially for things that are easy to get
wrong in a new port.
I'll follow up with more ideas if I think of any.
Students interested in the project are welcome (and encouraged!) to
ask questions and discuss here on the musl list. Obviously everyone
should have in mind writing their own proposals but I want everyone to
have access to knowledge/resources/community for ideas.
Rich
7 years, 3 months
Problem compiling bare metal examples
by Alexis Ramos Amo
Hello all,
I've made some modifications in the project for nexys4. I've integrated an IP and changed the hierarchy by creating a wrapper for chip_top (the top identity in default untethered lowRISC) and my others verilog files.
I can create a bitstream without any problem but if I want to make a bare metal example alongside with my modification I get the following error
$make hello
[...]
vivado -mode batch -source ../../common/script/search_ramb.tcl -tclargs lowrisc-chip-imp > search-ramb.log
python ../../common/script/bmm_gen.py search-ramb.log src/boot.bmm 128 65536
Traceback (most recent call last):
File "../../common/script/bmm_gen.py", line 23, in <module>
if int(sys.argv[3]) % len(rams) != 0:
ZeroDivisionError: integer division or modulo by zero
make[1]: *** [src/boot.bmm] Error 1
How can I compile a program (in this case hello world) in order to be used with my project?
Kind Regards
Alexis
7 years, 3 months
Integrating more open-source IP for lowRISC on FPGAs (GSoC 2016)
by Radhika
Hi,
I'm interested in contributing to lowRISC and being a part of GSoC this
summer. I'm familiar with Verilog and am currently reading up on Chisel,
and am looking to work on an open-source memory controller for lowRISC.
For this project, what sort of order of implementation would you suggest?
Also, would you be able to suggest any relevant resources to go through for
additional information/knowledge?
Thanks,
Radhika
7 years, 3 months
