RISC-V interrupt vectoring

Wed Jul 5 12:21:58 UTC 2017

On Tue, Jul 4, 2017 at 7:47 AM, Denis Obrezkov <denisobrezkov at gmail.com> wrote:
> 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
>>
>>
>
> I found out, that I have an exception "Illegal instruction", I get this
> exception after I step in:
> 0x204007c2 in Clock_initialize (major=0, minor=0, pargp=0x0)
>     at
> /home/reprofy/Projects/riscv/rtems/development/rtems/kernel/rtems-riscv/c/src/lib/libbsp/riscv32/hifive1/../../shared/clockdrv_shell.h:182
>
>
> from
> 0x2040ef06 in rtems_io_initialize (major=0, minor=0, argument=0x0)
>     at
> /home/reprofy/Projects/riscv/rtems/development/rtems/kernel/rtems-riscv/c/src/../../cpukit/sapi/src/ioinitialize.c:36
>
> But this is a part of my disas output for 0x204007c2 address:
>    0x204007b8 <+16>:    sw      a2,-44(s0)
>    0x204007bc <+20>:    lui     a5,0x80001
>    0x204007c0 <+24>:    sw      zero,-1576(a5) # 0x800009d8
>    0x204007c4 <+28>:    sw      zero,-20(s0)
>    0x204007c8 <+32>:    lui     a5,0x80001
>    0x204007cc <+36>:    li      a4,1
>    0x204007ce <+38>:    sb      a4,-1580(a5) # 0x800009d4
>
> How is it possible?
>
It's suspicious that your EPC is 204007c2 but that does not correspond
with an instruction in your disassembly.

> --
> Regards, Denis Obrezkov
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel