Questasim + bare-metal program + physical memory access

[andreaskuster]

I am in currently in the process of integrating a DMA engine into the CVA6 SoC.

I would like to write a simple driver i.e. for the start, just read from / write to device registers in the physical memory space.

(1) Following the Running User-Space Applications with the frist-stage bootloader, pk and bbl i.e. make sim elf-bin=$RISCV/riscv64-unknown-elf/bin/pk target-options=hello.elf batch-mode=1 does work, however, we end up in virtual memory. Is there an (easy) way to either directly access physical memory from there or map it into the user space app? (i.e. accessing 0x8000_0000 produces a segfault).
Even though the --disable-vm option is still present, it does not seem to still be active anymore: riscv-software-src/riscv-pk#200

(2) Using the uart driver and running this as the main application make sim elf-bin=main.elf batch-mode=1 did not work.

#include "uart.h"

int main()
{
    init_uart(50000000, 115200);
    print_uart("Hello World!\r\n");

    return 0;
}

# [TRACER] Output filename is: trace_hart_0.log
warning: tohost and fromhost symbols not in ELF; can't communicate with target

(3) Adding the fromhost and tohost functionality from vm.c omited the warning, however, did not produce any output.

Any suggestions or examples on how this can be done efficiently would be appreciated.

[zarubaf]

• Ad (1): Yes, pk works in VM and likely doesn't map any IO space into VM, so that is going to be a difficult route for your target.
• Ad (2): That should really work. The UART should be displayed on stdout and in a file called uart.* (https://github.com/openhwgroup/cva6/blob/3ddf797e95923fd11113c8e443046105dfbf8843/corev_apu/tb/common/uart.sv). In that case you can ignore the warning that the tohost symbol isn't present. The only thing you lose is the end of test capabilities. What I do not remember whether the elf-bin=... still works. But you should be good at preloading it as you would do normally.
• Ad (3): Possible to use this as well to proxy a write system call to the host. In that case, I'd suggest looking at the syscall.c file, which is really the minimal working example for making syscalls over fromhost. Note that in this case, you need to disable the preloading and load the elf like you do with all the other applications.

[andreaskuster]

Thanks for your elaborate explanation. We found a neat solution that works pretty well. A small adjustment to the rtl code (i.e. correct use of the mock_uart andreaskuster@0072892) together with the right uart driver (https://github.com/andreaskuster/cva6/tree/4c653b2bcd1b35830a369c55cf8f1d4e677033f0/programs/test), one can simulate bare metal with Questasim using the command make sim elf-bin=programs/test/uarttest.elf batch-mode=1

Since this is probably very useful for anyone developing new SoC or core extensions, should I add a separate PR for that? As far as I can see, there is not really software code in the repo so far, that is why I am asking..

[KeithoHimself]

I need to be able to do this as well, i.e. develop bare metal software that does physical memory accesses as part of cva6 integration into a SoC device.

I thinks this should be added. Rationale: This assists SoC integration teams by:

1. Providing a "ready to run" example of the CVA6 that includes activity on the AXI4 interface
2. Providing a regressable test to insure Questa+uart+physical access works

[MikeOpenHWGroup]

Hi @andreaskuster, I think this issue is resolved but it is not certain. Can you provide an update?

[andreaskuster]

Hi @MikeOpenHWGroup
For me, this issue is resolved with my comment above. However, I kept it open with the question of whether you wanted to merge my solution ((RTL + C code) into mainstream cva6. There seems to be interest from @KeithoHimself and possibly others.

[JeanRochCoulon]

Related to #1569