RISC-V interrupt vectoring

[Denis Obrezkov]

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".


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