OpenRISC 1000 Multicore Virtual Platform (or1kmvp)
This repository contains the source code of
or1kmvp, an OpenRISC 1000
Multicore Virtual Platform based on SystemC/TLM. It models a regular
symmetric multiprocessor design with a configurable number of processors and
a set of I/O peripherals.
or1kmvp is detailed enough to run the Linux
kernel and fast enough to allow interactive command-line use.
Depending on the host computer, this full system simulator reaches a total
performance of around 35 MIPS (which are split among all instruction set
simulators present in the system).
It is intended to be used by software developers to test and run parallel
OpenRISC applications without the need for physical OpenRISC hardware.
Furthermore, it can also be used as a starting point for custom SystemC
and OpenRISC based Virtual Platforms.
Build & Installation
In order to build
or1kmvp, you need the following prerequisite software
SystemC: the underlying simulation engine
or1kiss: the OpenRISC 1000 instruction set simulator
vcml: a SystemC addon library with TLM models for peripherals etc.
libelf: for reading ELF binaries
cmake: is used as the build system
These libraries should have guides on how to build them that take precedence over this one. However, for convenience, this is the full build procedure:
sudo apt-get install cmake libelf-dev # Ubuntu sudo yum install cmake3 libelf-dev # Centos
Download and build SystemC. Make sure to set the environment variables
wget http://www.accellera.org/images/downloads/standards/systemc/systemc-2.3.1a.tar.gz tar -xzf systemc-2.3.1a.tar.gz && cd systemc-2.3.1a export SYSTEMC_HOME=`pwd` export TARGET_ARCH=linux64 mkdir BUILD && cd BUILD ../configure --prefix=$SYSTEMC_HOME --enable-optimize --enable-static CXXFLAGS="-std=c++11" make -j 4 && make install
Clone and build
vcml. Make sure to set the environment variable
vcmlrequires SystemC, but
cmakeshould be able to locate it automatically if you have set
SYSTEMC_HOMEas indicated in the previous step:
git clone https://github.com/janweinstock/vcml.git && cd vcml mkdir -p BUILD/RELEASE/BUILD && cd BUILD/RELEASE/BUILD cmake ../../.. -DCMAKE_INSTALL_PREFIX=.. -DCMAKE_BUILD_TYPE=RELEASE make -j 4 && make install export VCML_HOME=`pwd`/..
Clone and build
or1kiss. Make sure to set the environment variable
OR1KISS_HOMEafterwards as indicated below:
git clone https://github.com/janweinstock/or1kiss.git && cd or1kiss mkdir -p BUILD/RELEASE/BUILD && cd BUILD/RELEASE/BUILD cmake ../../.. -DCMAKE_INSTALL_PREFIX=.. -DCMAKE_BUILD_TYPE=RELEASE make -j 4 && make install export OR1KISS_HOME=`pwd`/..
Once the prerequisites are done, we can start building
or1kmvp. First chose directories for building and deployment:
<source-dir> location of your repo copy, e.g. /home/jan/or1kmvp <build-dir> location to store object files, e.g. /home/jan/or1kmvp/BUILD <install-dir> output directory for binaries, e.g. /opt/or1kmvp
Configure and build the project. If you get an error, make sure the following environment variables are set correctly:
SYSTEMC_HOME(see step 2)
TARGET_ARCH(see step 2)
VCML_HOME(see step 3)
OR1KISS_HOME(see step 4)
Configuration is done with
cmakeusing the regular parameters:
mkdir -p <build-dir> cd <build-dir> cmake <source-dir> -DCMAKE_INSTALL_PREFIX=<install-dir> -DCMAKE_BUILD_TYPE=RELEASE make -j 4 && make install
After installing, the following new files and directories should be present:
<install-dir>/bin/or1kmvp # simulator binary <install-dir>/config/ # directory holding example configuration files
Note that in order to boot Linux, you will additionally need the kernel image, a compiled device tree and an initrd. These large binary files are not included in this repository, but can be found in the release list of this project.
To start simulation, you can run
<install-dir>/bin/or1kmvp -f <install-dir>/config/[up.cfg|smp2.cfg]
up.cfg constructs a uniprocessor system, while
smp2.cfg yields a
dual core system. Note that, if you have built
or1kmvp directly from source,
you will additionally need Linux kernel images, compiled device tree files and
an initrd and place them in
<install-dir>/sw. These files are referenced by
smp2.cfg, so you need to name them accordingly.
The simulator can run with networking support, if a tap device has been created before starting the simulation. Assuming one of the default platform config files is being used, you can run the following commands to enable networking:
sudo <install-dir>/bin/or1kmvp-tapnet start tap0 <install-dir>/bin/or1kmvp -f up.cfg ... use the simulator ... sudo <install-dir>/bin/or1kmvp-tapnet stop tap0
From within the simulator, you can use
wget etc. to test
the network connection. In its default configuration, the host PC has the IP
10.0.0.1 and the VP uses
also sets up NAT, allowing the simulator to connect to the internet using the
host as a gateway.
From the host you can connect to a running simulator using
telnet 10.0.0.2 ssh [email protected]
It is possible to connect GDB to a running simulation and investigate what each
processor is doing. The debug context is bare-metal, meaning you will need
a bare-metal debugger, i.e.,
or1k-elf-gdb. To connect to a VP running Linux,
you can try the following (use port
55100 + coreid when running SMP):
or1k-gdb-elf <install-dir>/sw/vmlinux-4.20.0.elf (gdb) target remote :55100 (gdb) ... do stuff on core 0... (gdb) detach # disconnect (gdb) target remote :55101 (gdb) ... do stuff on core 1... (gdb) kill # terminate simulation
By default, the processor will not wait for GDB and instead immediatly start
executing code. To change that, you can use the
command line switch to tell CPU0 to wait for GDB.
Also note, that while an individual core is stopped, the SystemC simulation
still continues and simulation time passes. To stop the entire simulation when
a core is stopped by GDB, you can use
To debug software that is running within Linux, you can simply use the
gdbserver utility with an active network connection between host and
simulator (see Networking):
on the VP: # gdbserver :54321 ./myprogram on the host using or1k-linux-gdb: (gdb) target remote 10.0.0.2:54321 (gdb) ... do stuff ... (gdb) kill
This is the memory map of the system. Kernel device trees must be kept in sync with this.
0: 0x00000000 .. 0x07ffffff -> memory 1: 0x90000000 .. 0x90001fff -> uart8250 2: 0x92000000 .. 0x92001fff -> ethoc 3: 0x98000000 .. 0x98001fff -> ompic
Note that the default configuration for this system comes with 128MB of memory.
You can increase this using the
system.mem.size property (either via a
config file or via the
-c command line switch). If you change memory size,
the default memory map will automatically adjust.
The Linux system uses
dev/mmcblk0p1 as its root filesystem. You can either
modify it directly from within the simulation (make sure
writable) or on your host PC. For the latter, do the following:
sudo losetup -f -P <install-dir>/sw/sdcard0.img # setup /dev/loopXX losetup -a | grep sdcard0.gpt # figure out which loop device was used # figure out which loop device was used, it should have two partitions p1/p2 sudo mount /dev/loopXXp1 /mnt # make your changes in /mnt sudo umount /mnt sudo losetup -d /dev/loopXX # detach loop device
This project is licensed under the Apache-2.0 license – see the LICENSE file for details.