RISC-V interrupt vectoring

[Joel Sherrill]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170703/8fe85c85/attachment-0002.html>