Interrupts strange behavior on RISC-V

[Denis Obrezkov]

2017-07-09 6:25 GMT+02:00 Hesham Almatary <heshamelmatary at gmail.com>:

> On Sun, Jul 9, 2017 at 10:46 AM, Joel Sherrill <joel at rtems.org> wrote:
> > Yeah!!
> >
> > Does this mean you have a ticker variant working now? With polled console
> > IO?
> >
> > I ask because that is a nice capability merge point. When merged, you
> move
> > from a large submission to review to smaller more incremental ones.
> Easier
> > to review, etc.
> +1
> >
> > On Jul 8, 2017 7:30 PM, "Denis Obrezkov" <denisobrezkov at gmail.com>
> wrote:
> >>
> >> I found the problem, I made a mistake in my code, instead of:
> >> if ((cause & MCAUSE_MTIME) == MCAUSE_MTIME) {
> >> I have written:
> >> if (cause & MCAUSE_MTIME) {
> >>
> >> now local interrupts work.
> >>
> >> 2017-07-08 19:18 GMT+02:00 Denis Obrezkov <denisobrezkov at gmail.com>:
> >>>
> >>>
> >>>
> >>> 2017-07-08 18:05 GMT+02:00 Joel Sherrill <joel at rtems.org>:
> >>>>
> >>>>
> >>>>
> >>>> On Jul 8, 2017 10:09 AM, "Denis Obrezkov" <denisobrezkov at gmail.com>
> >>>> wrote:
> >>>>
> >>>> Hello all,
> >>>> I worked with local interrupts last few days and found some strange
> >>>> behavior:
> >>>>
> >>>>
> >>>> I am trying to handle local interrupts.
> >>>> That's what I do, in my handler for timer interrupts:
> >>>> * disable timer interrupts in mie
> >>>> * read a current value from mtime
> >>>> * copy it to mtimecmp (both are 64bit width types)
> >>>> * add some big value to mtimecmp
> >>>> * enable timer interrupts in mie.
> >>>>
> >>>> And I have two boards and the problem is that on one of them
> interrupts
> >>>> are permanently generated because mip register is always 1 in mtip
> position,
> >>>> though mtimecmp is greater than mtime, and are not generated at all
> on the
> >>>> other.
> >>>>
> >>>> Is there a procedure for clearing the interrupt?
> >>>
> >>> Yes, it is written that external interrupts are cleared by PLIC
> (external
> >>> interrupt controller),
> >>> software interrupts are cleared I think by the main thread (I didn't
> find
> >>> it in docs), and timer
> >>> interrupts are cleared by writing the value in mtimecmp memory-mapped
> >>> register greater
> >>> than in mtime  (memory mapped register too.) [2, p.28]
> >>>>
> >>>> In this piece of code, I turn on interrupts:
> >>>> la t0, RISCV_Exception_default
> >>>> csrs mtvec, t0
> >>>> li t0, 0x88
> >>>> csrs mie, t0
> >>>> csrsi mstatus, 0x8
> >>>>
> >>>>
> >>>> Can you point us to the documentation and section where this timer
> >>>> behavior is defined? Sometimes having someone else read it can
> provide a
> >>>> different interpretation.
> >>>>
> >>>> And is there other code like Linux which deals with this timer? There
> >>>> may be a magic sequence you are missing
> >>>
> >>>
> >>> I wasn't able to find a magic sequence and didn't look at Linux code,
> but
> >>> I initialized it like in hifive1 example provided with FreedomStudio
> (IDE
> >>> for HiFive1).:
> >>> https://github.com/sifive/freedom-e-sdk/tree/master/bsp
> >>>
> >>> But these are the docs:
> >>> Description of mstatus register, which contains mie field for global
> >>> interrupt enabling (Ch 3.1.6):
> >>> [1] https://riscv.org/specifications/privileged-isa/
> >>> Description of the core, on which SoC is based (Ch 6 is about
> >>> interrupts):
> >>> [2] https://www.sifive.com/documentation/coreplex/e31-coreplex-manual/
> >>>
> >>> There are also description of the SoC:
> >>>
> >>> https://www.sifive.com/documentation/freedom-soc/
> freedom-e300-platform-reference-manual/
> >>> and description of the chip:
> >>> https://www.sifive.com/documentation/chips/freedom-e310-g000-manual/
> >>>
> >>> --
> >>> Regards, Denis Obrezkov
> >>
> >>
> >>
> >>
> >> --
> >> Regards, Denis Obrezkov
>
>
>
> --
> Hesham
>
No, it means only that interrupts work.
I want to initialize counters and implement uart driver.
And as for interrupts I think I have to utilize rtems interrupts.


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