RISC-V interrupt vectoring

[Denis Obrezkov]

2017-07-03 21:17 GMT+02:00 Joel Sherrill <joel at rtems.org>:

>
>
> On Jul 3, 2017 12:45 PM, "Denis Obrezkov" <denisobrezkov at gmail.com> wrote:
>
> 2017-07-03 19:09 GMT+02:00 Joel Sherrill <joel at rtems.org>:
>
>>
>>
>> On Jul 3, 2017 11:49 AM, "Denis Obrezkov" <denisobrezkov at gmail.com>
>> wrote:
>>
>> 2017-07-03 7:43 GMT+02:00 Hesham Almatary <heshamelmatary at gmail.com>:
>>
>>> On Mon, Jul 3, 2017 at 3:36 PM, Denis Obrezkov <denisobrezkov at gmail.com>
>>> wrote:
>>> > 2017-07-03 4:59 GMT+02:00 Hesham Almatary <heshamelmatary at gmail.com>:
>>> >>
>>> >> You can have a look at riscv-pk [1] as a RISC-V reference how to
>>> >> handle interrupts. RTEMS-wise, you can look at or1k and ARM code and
>>> >> how the platform-dependent interrupt handling code is linked to
>>> >> platform-independent one.
>>> >>
>>> >> mcause value can be used as an index to a software vector table that
>>> you
>>> >> set up.
>>> >>
>>> >> Why do you need software interrupts? GSoC-wise, I thought the plan was
>>> >> to develop UART/Console driver (which doesn't need interrupts), and
>>> >> use simulated ticker, as a first step. Then it will be easier to
>>> >> debug/proceed from there with interrupt handling code.
>>> >
>>> > I thought, I have to implement an interrupt console driver. Okay, then
>>> I am
>>> > going to
>>> > investigate a simulated ticker.
>>> Yeah that can be done in later stages, for optimisation purposes. But
>>> I think it's easier to implement it in polling mode first, just to get
>>> things working, then you can easily move to interrupt-based
>>> implementation. For example, if you've a polling console driver, you
>>> can debug using printk, when developing the clock driver. Once you get
>>> the clock driver working, you will have a more mature code for
>>> interrupt handling, which enables you to very easily implement
>>> interrupt-based UART driver.
>>> > --
>>> > Regards, Denis Obrezkov
>>>
>>>
>>>
>>> --
>>> Hesham
>>>
>>
>> It seems that vectored interrupts aren't available in FE310 SoC.
>> Thus, I will work with mcause register.
>> As for now, I want to:
>> * add local interrupt handlers
>> * add init code for counters initializtion (since we want to set up a
>> baudrate)
>> * implement a dummy clock driver
>>
>>
>> This is easy and just requires one line in the BSP Makefile.am and an
>> include in the .tcfg file to skip tests known to fail. See either the shsim
>> or v850sim BSPs based on gdb for examples.
>>
>> It also lets you have all the tests running so you can add your target to
>> RTEMS tester. :)
>>
>> * implement a polling uart
>>
>>
>> Personally I would do this as soon as possible and get printk working.
>> Very helpful and needed to run the tests with simulated clock tick with the
>> polled driver.
>>
>> The counter is only needed for math on the baud rate I would guess.
>>
>> * figure out how interrupts are handled in RTEMS
>> * implement global interrupt handlers
>> * implement a clock driver
>> * implement an interrupt-mode uart driver.
>>
>>
>>
>> --
>> Regards, Denis Obrezkov
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>> Ok, I will try to make a uart driver as soon as possible.
> I had some issues with dummy_clockdriver, I think there was a mistake,
> that an address of clock initialization function was wrong, so, I will
> investigate it tomorrow.
> Also, I have a problem, as I mentioned earlier, that the minimum example
> finished with the error ''INTERNAL_ERROR_THREAD_EXITTED".
>
>
> That is probably the correct behavior. It is not intended to be executed.
> It is just an example of how to strip down a configuration to get a program
> running. The Init thread is completely empty as I recall so it would return
> and fail like this.
>
> I would move on to hello. Use the existing sim clock driver and the polled
> console driver framework until this much all works. See how the two BSPs I
> mentioned earlier do things. That will minimize the amount of code you have
> to write until you can focus on the interrupts.
>
> Also.. hello world is the first step. Usually adding a delay/sleep call to
> that or using ticker/sp01 is how to debug a clock driver and interrupt
> driven console driver.
>
>
>
>
> --
> Regards, Denis Obrezkov
>
>
> Hesham, could you explain this code:

SYM(RISCV_Exception_default):
  nop
trap_entry:
        nop
  addi sp, sp, -272
  SREG x1, 8(sp)
  SREG x2, 16(sp)
....
  SREG x30, 240(sp)
  SREG x31, 248(sp)

Is this for 64-bit architecture?
why is there a 'nop' command and why you move sp to -272 (not 256)?


-- 
Regards, Denis Obrezkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170704/78176c37/attachment-0002.html>