Running RISCV applications on the proxy kernel

[Rafael]

Hello all,

I'm currently struggling to run RISC-V applications on top of the proxy kernel (pk) on an C++ RTL simulator of the BOOM processor. 

I can run it using "spike pk hello", but when I try to run it in BOOM, the BOOM's program counter gets stuck at 0x100. I suspect there is an ISA mismatch.

There's also another thing that I'm struggling to understand:

When you say that an application runs ON THE TOP of pk, what exactly does that mean? Because, as I understand, pk is just a bunch of RISC-V code that is loaded into the memory TOGETHER with the application's binary of interest (a process that I still don't understand).

Also, can I compile pk and statically link it to the application, so I would not have to pass pk as a parameter?

In other words, can I compile it with something like gcc pk.o hello.o -o hello?

[Karsten Merker]

On Wed, Oct 11, 2017 at 07:29:18AM -0700, Rafael wrote:

> I'm currently struggling to run RISC-V applications on top of
> the proxy kernel (pk) on an C++ RTL simulator of the BOOM
> processor. 
>
> I can run it using "spike pk hello", but when I try to run it
> in BOOM, the BOOM's program counter gets stuck at 0x100. I
> suspect there is an ISA mismatch.

Just a wild guess as you mention a possible ISA mismatch:

IIRC it was mentioned in past discussions that BOOM doesn't
implement the C extension, and AFAIK the gcc build from the
riscv-tools repository defaults to generating C instructions,
so that might perhaps be the source of your problem.

Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.

[Christopher Celio]

Whenever you use rocket-chip (or BOOM), you must build the riscv-tools that is linked to as a submodule within rocket-chip/riscv-tools. That is the only way to guarantee compatibility.

The v1 and v2 tagged releases (as well as the current master branch of boom) use priv 1.9 and a copy of riscv-tools from Jan 5 [1]. The unstable boom-devel branch of rocket-chip (devel branch of boom) uses the latest priv 1.10 --- and that does require changing the riscv-tools/build.sh to generate a rv64imafd compiler instead of the default rv64gc.


[1] (https://github.com/riscv/riscv-tools/tree/cd78e37f72cfc2a452a0c11744586084fbae1dcd)

-Chris

> --
> You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
> To post to this group, send email to sw-...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/20171011180005.dp3mulvru422w3yr%40excalibur.cnev.de.

[Rafael B.T]

Thank you for your support.

I also forgot to ask one more thing. 

I know there are two different ways to load the application binary in the BOOM simulator, one of them is a simple method in a file called mm.cc, where the bytes of the applications are simply read from the .hex file and loaded to a vector. The other way uses the htif interface, in a method called load_mem in htif.cc. Should I load pk in the htif method? Or should I use the method in mm.cc? Does it even make any difference? 

Thank you a lot in advance.

> To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+unsubscribe@groups.riscv.org.

> To post to this group, send email to sw-...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.

[Christopher Celio]

In very old versions of boom/rocket-chip, you could load binaries into target memory as a .hex file. That was magic and thus very fast. The htif method loads the binary by sending ~64b payloads to the target over thousands of cycles. It is slower.

-Chris