2017-07-05 14:44 GMT+02:00 Joel Sherrill <j...@rtems.org>:
>
>
> On Jul 5, 2017 7:22 AM, "Gedare Bloom" <ged...@rtems.org> wrote:
>
> On Tue, Jul 4, 2017 at 7:47 AM, Denis Obrezkov <denisobrez...@gmail.com>
> wrote:
> > 2017-07-03 21:17 GMT+02:00 Joel Sherrill <j...@rtems.org>:
> >>
> >>
> >>
> >> On Jul 3, 2017 12:45 PM, "Denis Obrezkov" <denisobrez...@gmail.com>
> wrote:
> >>
> >> 2017-07-03 19:09 GMT+02:00 Joel Sherrill <j...@rtems.org>:
> >>>
> >>>
> >>>
> >>> On Jul 3, 2017 11:49 AM, "Denis Obrezkov" <denisobrez...@gmail.com>
> >>> wrote:
> >>>
> >>> 2017-07-03 7:43 GMT+02:00 Hesham Almatary <heshamelmat...@gmail.com>:
> >>>>
> >>>> On Mon, Jul 3, 2017 at 3:36 PM, Denis Obrezkov <
> denisobrez...@gmail.com>
> >>>> wrote:
> >>>> > 2017-07-03 4:59 GMT+02:00 Hesham Almatary <heshamelmat...@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@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.
>
>
> 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@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/rtems/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/rtems/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
--
Regards, Denis Obrezkov
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
