RISC-V interrupt vectoring
Denis Obrezkov
denisobrezkov at gmail.com
Wed Jul 5 13:50:26 UTC 2017
2017-07-05 15:42 GMT+02:00 Joel Sherrill <joel at rtems.org>:
>
>
> On Jul 5, 2017 8:12 AM, "Denis Obrezkov" <denisobrezkov at gmail.com> wrote:
>
> 2017-07-05 14:44 GMT+02:00 Joel Sherrill <joel at rtems.org>:
>
>>
>>
>> On Jul 5, 2017 7:22 AM, "Gedare Bloom" <gedare at rtems.org> wrote:
>>
>> 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/cl
>> ockdrv_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.
>>
>>
>> Good spot Gedare. Could it be a math error in the assembly before you get
>> near here? Perhaps computing the offset I to an array of vectors wrong and
>> adding it to the base address of the handler?
>>
>>
>> > --
>> > Regards, Denis Obrezkov
>> >
>> > _______________________________________________
>> > devel mailing list
>> > devel at rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>> Okey, I will investigate this.
> Also, I wrote a small function:
> static void Clock_driver_timecounter_tick ( void )
> {
> rtems_clock_tick ();
> };
>
> So, I was able to proceed further.
> Also, I deleted printk's, but now I haven't figured out what's happening,
> the program just continues executing:
> #0 0x2040efb8 in _Chain_Get_first_unprotected (the_chain=0x80000a18
> <_RTEMS_tasks_Information+60>) at ../../cpukit/../../../hifive1/
> lib/include/rtems/score/chainimpl.h:593
> #1 0x2040f012 in _Chain_Get_unprotected (the_chain=0x80000a18
> <_RTEMS_tasks_Information+60>) at ../../cpukit/../../../hifive1/
> lib/include/rtems/score/chainimpl.h:631
> #2 0x2040f184 in _Freechain_Get (freechain=0x80000a18
> <_RTEMS_tasks_Information+60>, allocator=0x2040eb7a <_Workspace_Allocate>,
> number_nodes_to_extend=0, node_size=72)
> at /home/reprofy/Projects/riscv/rtems/development/rtems/kernel/
> rtems-riscv/c/src/../../cpukit/score/src/freechain.c:61
> #3 0x2040909e in _Thread_Initialize (information=0x800009dc
> <_RTEMS_tasks_Information>, the_thread=0x80000fd0, scheduler=0x20413a18
> <_Scheduler_Table>, stack_area=0x0, stack_size=0,
> is_fp=false, priority=1, is_preemptible=true,
> budget_algorithm=THREAD_CPU_BUDGET_ALGORITHM_NONE, budget_callout=0x0,
> isr_level=0, name=...)
> at /home/reprofy/Projects/riscv/rtems/development/rtems/kernel/
> rtems-riscv/c/src/../../cpukit/score/src/threadinitialize.c:111
> #4 0x20401c90 in rtems_task_create (name=1413558560, initial_priority=1,
> stack_size=0, initial_modes=0, attribute_set=0, id=0x80001750)
> at /home/reprofy/Projects/riscv/rtems/development/rtems/kernel/
> rtems-riscv/c/src/../../cpukit/rtems/src/taskcreate.c:97
> #5 0x2040046e in Init (argument=0) at /home/reprofy/Projects/riscv/r
> tems/development/rtems/kernel/rtems-riscv/c/src/../../
> testsuites/samples/ticker/init.c:58
> #6 0x204088ea in _Thread_Entry_adaptor_idle (executing=0x80000d30)
> at /home/reprofy/Projects/riscv/rtems/development/rtems/kernel/
> rtems-riscv/c/src/../../cpukit/score/src/threadentryadaptoridle.c:25
> #7 0x204119f0 in _Thread_Handler () at /home/reprofy/Projects/riscv/r
> tems/development/rtems/kernel/rtems-riscv/c/src/../../
> cpukit/score/src/threadhandler.c:73
> #8 0x2041198e in _User_extensions_Thread_exitted (executing=0x80000d30)
> at ../../cpukit/../../../hifive1/lib/include/rtems/score/userextimpl.h:298
>
>
> Is this still minimum? The thread is falling out the bottom and returning.
> This is normal for that test as I have mentioned previously.
>
> If you want to continue with it, put a while(1) loop in the Init task body
> so it never exits.
>
>
>
>
> --
> Regards, Denis Obrezkov
>
>
> No, this is a low ticker example.
--
Regards, Denis Obrezkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170705/a247ac2e/attachment.html>
More information about the devel
mailing list