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