Software interrupt for RISC-V

Kernel
1

bdawood wrote on Monday, July 08, 2019:

Hi,

We are currently using FreeRTOS for our RISC-V development. One particular
case I came across is that FreeRTOS trap_handlder doens’t handle at
Software interrupts. So as far as I can understand, it checks if the source
of the trap is async (i.e external IRQ or timer IRQ) or sync (probably due
to illegal access). However In our code we rely on issuing a software
interrupt to the core to do some stuff. So what happens is that FreeRTOS
check its an async interrupt but yet not an external interrupt and goes and
raise an assert (i.e ebreak instruction!!).

Is that actually the intended behavior? Am i missing something in here? Is
there a workaround for this?

Regards,

Bassem

2

rtel wrote on Monday, July 08, 2019:

Does your core have a CLINT?
How are you generating the software interrupt (which instruction or instructions) - is it sync or async?

Please reference line numbers here https://sourceforge.net/p/freertos/code/HEAD/tree/trunk/FreeRTOS/Source/portable/GCC/RISC-V/portASM.S to describe the path taken through the code when you raise the software interrupt.

3

bdawood wrote on Monday, July 08, 2019:

Yes we have a CLINT. We are generating SWI by writing 0x01 to the MSIP register of the CLINT (for whatever core we want to trigger).

Based on the link you posted, sequence as follows:

Regards,
Bassem

4

rtel wrote on Monday, July 08, 2019:

Thanks that is very helpful.

So if I understand correctly, as well as checking for 0x80000007 to see
if the exception was generated by a machine timer, we also need to check
for 0x80000003 to see if the exception was generated by a machine (at
this time, as only machine mode is supported, although that will change)
software interrupt - is that correct? If so, how should the software
interrupt be handled? It could be a separate callback into the
application code which would be clean but require the application writer
to provide more. Or it could use the same callback as the external
interrupts as the cause register can be read in the handler to determine
if it was a software interrupt - that would be much more clunky for the
application writer and make the asm code a bit more complex.

Either way I think this is a small change.

Thoughts? My preference would be the first method - have the user
provide an ‘software interrupt’ handler.

5

bdawood wrote on Monday, July 08, 2019:

Thanks for the reply.

  • Yes, your understanding is correct. we need to account for SWI (mcause = 0x80000003)

  • In my local branch I did a small patch that implemented option two. My main reasons were:
    1- Have a single entry point (and exit) for my interrupts (and use mcause to figure out the reason).
    2- Avoid adding an extra user configuration for our application developers
    3- That same function can used as a trap handler without the OS if required (that’s actually what we do intially until starting the FreeRTOS, which replaces mvec with its own).

  • One last question, Is it necessary ( or a policy) for FreeRTOS to check the exact source of interrupt and trap if unhandled? I would have expected that FreeRTOS would only capture the Timer TICK and pass every thing else up whatever the source of Interrupt is (i.e no need of the cause check in the first palce) (mainly talking about asynchronous interrupts).

Regards,
Bassem

6

rtel wrote on Monday, July 08, 2019:

Grateful if you can post your patched asm file.

To answer your question - not policy - this is a new port and we want to
see how people use the code and make sure we are providing what they
want/need, so this is a good conversation. The port will get developed
over time to add in more functionality.

7

bdawood wrote on Tuesday, July 09, 2019:

Sorry fo the late reply. See the attached file.

I took a different approach to remove the check on the source of the interrupt altogether (after checking its not a timer interrupt).