[RISCV] Support for vector only RISCV core (ibex) ?

[mean00]

On riscV, the code is asserting if the direct mode of mtvec is not set to "0" i.e. if it is not in direct mode.

/ Check the least significant two bits of mtvec are 00 - indicating single vector mode. / __asm volatile( "csrr %0, mtvec" : "=r"( mtvec ) ); configASSERT( ( mtvec & 0x03UL ) == 0 );

There is the symetric issue in xPortStartFirstTask, when setting mtvec to point to freertos_trap_handler

Some cores (ibex) only supports vector mode

Would it be ok to have a configuration switch to allow for vectored mode ? Maybe, an additional table with all entries pointing to freertos_trap_handler ? If that's ok, i can try to propose a patch Thank you.

[mean00]

I've made a preliminary proof of concept available here : https://github.com/mean00/FreeRTOS-Kernel/commit/a0fd6a3e3c45c5b75c3bb655a1b8fbe938470106

It is a bit on the crude side, but enables freeRTOS to start on the ibex The main issue is that part of the changes are in the port.c (check mtvec is odd or even) and part is in portASM.S (where mtvec is set to its new value), which leads to 2 defines one in FreeRTOSConfig.h and one in the freertos_risc_v_chip_specific_extensions.h

Generally speaking, the configuration management can rapidly be complicated in riscV In may be a good idea to move the chip specific init (setting mtvec , configuring timer interrupt etc) to freertos_risc_v_chip_specific_extensions.c/.s, a sibling to freertos_risc_v_chip_specific_extensions.h which is per chip

(my actual working copy is simpler as it only supports vector mode, and it seems to work fine)

[dachalco]

Hi @mean00

If it's of interest, I would encourage you to open a PR and we would be happy to more technically analyze your proposal. From a glance at your linked code, it looks really good so far.

[dachalco]

@mean00

Haven't read the RISC-V ISA in a while so I can't immediately comment on the issue without reviewing a bit. Pinging colleagues who can immediately work or triage this. Otherwise will add to my triage and provide some more feedback soon.

[RichardBarry]

This is good stuff - the RISC-V port will evolve as we get requests to support additional hardware. We already have an action to determine the best way of supporting different chips. In an ideal world there would be just one port with the extensions headers (and maybe code files too as per your suggestion) - but if that risks a pre-processor tangle it may actually be beneficial to have a few similar port that behave slightly differently without depending on the pre-processor.

In this case I think your suggestion is good for the time being - but without a board that requires this mode I'm not sure how we can test it. Are there any simulators that work in that mode?

[mean00]

Hi OpenTitan (https://github.com/lowRISC/opentitan) is using an ibex core which only supports interrupt vector mode.

The project contains a verilator based emulator which can be debugged with their own version of OCD+riscV gdb (the emulator takes a long to to build but works)

The timer is slightly different but mostly compatible with the siFive one The interrupt controller is different too When trying FreeRTOS on the emulator/the FPGA board, the only other issue i saw was disabling interrupts while under interrupt, which was messing with exception state, i.e. would not continue very long after that.

[aggarg]

Fixed in the latest refactoring - https://github.com/FreeRTOS/FreeRTOS-Kernel/pull/444

Programming mtvec is now the responsibility of the application. Let me know if you still face any problem.