2017-07-05 15:42 GMT+02:00 Joel Sherrill <j...@rtems.org>: > > > On Jul 5, 2017 8:12 AM, "Denis Obrezkov" <denisobrez...@gmail.com> wrote: > > 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/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@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
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
