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