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.
> -- > Regards, Denis Obrezkov > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
