seldridge
commented
7 years ago Thanks for this. No, it shouldn't take that long t run. To give you a rough time estimate, this should finish in around 5 minutes. You can run the emulator verbosely to get some better idea of what's going on or where it's getting stuck or at least where it's spinning with:
./emulator-rocketchip-RoccExampleConfig +verbose pk ../../../rocket-rocc-examples/build/test-accumulator 2>&1 | spike-dasmNote: this software currently does not work with rocket-chip's master branch for several reasons:
- The definition of the config string is in flux and I don't believe that the Proxy Kernel will read it correctly (this should cause an assertion to fail in
riscv-pk/machine/configstring.c). You can further patch the proxy kernel by hard-coding the values that are supposed to be read in those functions. (see: https://github.com/ucb-bar/rocket-chip/issues/467) - Rocket-chip's master branch won't actually build RoCCs (https://github.com/ucb-bar/rocket-chip/issues/558). I have a partial solution for this, but it doesn't work for multi-RoCC setups like RoccExampleConfig.
Without fixing the former, you should have the proxy kernel firing off an assertion. Without fixing the latter, you should always get illegal instruction exceptions because rocket-chip has been built without support for custom instructions.
Since you aren't seeing one or the other of these... you may be seeing problems related to a mismatch of rocket-chip and riscv-tools. Can you verify the commits that you're on for those?
I am able to get this to work when using the following combinations:
rocket-chip-- c5310938riscv-tools-- cd78e37 (note: this is newer that what the above rocket-chip commit is pointing at)
And I've patched the proxy kernel in the following way:
diff --git a/machine/configstring.c b/machine/configstring.c
index fb2fed7..f3f21d2 100644
--- a/machine/configstring.c
+++ b/machine/configstring.c
@@ -6,12 +6,7 @@
static void query_mem(const char* config_string)
{
- query_result res = query_config_string(config_string, "ram{0{addr");
- assert(res.start);
- uintptr_t base = get_uint(res);
- assert(base == DRAM_BASE);
- res = query_config_string(config_string, "ram{0{size");
- mem_size = get_uint(res);
+ mem_size = 0x10000000;
}
static void query_rtc(const char* config_string)
diff --git a/machine/minit.c b/machine/minit.c
index b3f2c86..54ff88e 100644
--- a/machine/minit.c
+++ b/machine/minit.c
@@ -19,6 +19,7 @@ static void mstatus_init()
uintptr_t ms = 0;
ms = INSERT_FIELD(ms, MSTATUS_VM, VM_CHOICE);
ms = INSERT_FIELD(ms, MSTATUS_FS, 1);
+ ms = INSERT_FIELD(ms, MSTATUS_XS, 1);
write_csr(mstatus, ms);
// Make sure the hart actually supports the VM mode we wantRunning this, I'm seeing the following:
> time ./emulator-rocketchip-RoccExampleConfig -c pk ~/repos/github.com/seldridge/rocket-rocc-examples/build/test-accumulator
[INFO] Write R[1] = 0xdead
[INFO] Read R[1]
[INFO] Received 0xdead
[INFO] Accum R[1] with 0xffffffffffffe042
[INFO] Read R[1]
[INFO] Received 0xbeef
[INFO] Load 0xbad (virt: 0x0xfeefac0, phys: 0x0x8ffffac0) via L1 data cache
[INFO] Read R[1]
[INFO] Received 0xbad
Completed after 5614110 cycles
real 5m32.001s
user 5m30.534s
sys 0m0.461sLet me know if this is able to get it working for you.
bjoernveit
I did everything the Readme said, but when I ran the testaccumulator, it never terminated. I gave it 3 hours. Is this something anybody has come across and knows how to fix this? Is there any chance I would've had to be more patient?
In case anybody is wondering, I did not forget the pk, I ran:
./emulator-rocketchip-RoccExampleConfig pk ../../../rocket-rocc-examples/build/test-accumulator