RISC-V interrupt vectoring

Tue Jul 4 11:47:45 UTC 2017

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?

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