On Fri, Aug 18, 2017 at 11:30 AM, Denis Obrezkov <denisobrez...@gmail.com> wrote: > 2017-08-17 23:58 GMT+02:00 Gedare Bloom <ged...@rtems.org>: >> >> On Thu, Aug 17, 2017 at 4:17 PM, Denis Obrezkov <denisobrez...@gmail.com> >> wrote: >> > 2017-08-17 22:07 GMT+02:00 Gedare Bloom <ged...@rtems.org>: >> >> >> >> On Thu, Aug 17, 2017 at 1:48 PM, Denis Obrezkov >> >> <denisobrez...@gmail.com> >> >> wrote: >> >> > 2017-08-17 17:25 GMT+02:00 Gedare Bloom <ged...@rtems.org>: >> >> >> >> >> >> On Wed, Aug 16, 2017 at 11:13 AM, Denis Obrezkov >> >> >> <denisobrez...@gmail.com> wrote: >> >> >> > --- >> >> >> > cpukit/score/cpu/riscv32/riscv-context-switch.S | 12 ++++++++++-- >> >> >> > 1 file changed, 10 insertions(+), 2 deletions(-) >> >> >> > >> >> >> > diff --git a/cpukit/score/cpu/riscv32/riscv-context-switch.S >> >> >> > b/cpukit/score/cpu/riscv32/riscv-context-switch.S >> >> >> > index a199596..bcdfe0e 100644 >> >> >> > --- a/cpukit/score/cpu/riscv32/riscv-context-switch.S >> >> >> > +++ b/cpukit/score/cpu/riscv32/riscv-context-switch.S >> >> >> > @@ -46,6 +46,7 @@ PUBLIC(restore) >> >> >> > >> >> >> > SYM(_CPU_Context_switch): >> >> >> > /* Disable interrupts and store all registers */ >> >> >> > + csrci mstatus, 0x8 >> >> >> Why is this necessary? >> >> >> >> >> >> > SREG x1, 4(a0) >> >> >> > SREG x2, 8(a0) >> >> >> > SREG x3, 12(a0) >> >> >> > @@ -78,8 +79,9 @@ SYM(_CPU_Context_switch): >> >> >> > SREG x30, 120(a0) >> >> >> > SREG x31, 124(a0) >> >> >> > >> >> >> > -SYM(restore): >> >> >> > >> >> >> > +SYM(restore): >> >> >> > + >> >> >> > LREG x1, 4(a1) >> >> >> > LREG x2, 8(a1) >> >> >> > LREG x3, 12(a1) >> >> >> > @@ -111,9 +113,15 @@ SYM(restore): >> >> >> > LREG x29, 116(a1) >> >> >> > LREG x30, 120(a1) >> >> >> > LREG x31, 124(a1) >> >> >> > - ret >> >> >> > + >> >> >> > + >> >> >> > + csrsi mstatus, 0x8 >> >> >> > + nop >> >> >> > + nop >> >> >> Why the nops? >> >> >> >> >> >> > + ret >> >> >> > >> >> >> > SYM(_CPU_Context_restore): >> >> >> > + csrci mstatus, 0x8 >> >> >> > mv a1, a0 >> >> >> > j restore >> >> >> > nop >> >> >> > -- >> >> >> > 2.1.4 >> >> >> > >> >> >> > _______________________________________________ >> >> >> > devel mailing list >> >> >> > devel@rtems.org >> >> >> > http://lists.rtems.org/mailman/listinfo/devel >> >> > >> >> > So, don't we turn off interrupts during the context switch? >> >> >> >> Nope, and turning them back on unconditionally is wrong too. >> >> >> >> > Yes, nops are unnecessary. >> >> > >> >> > >> >> > -- >> >> > Regards, Denis Obrezkov >> > >> > Ok, I was confused by this obsolete comment: >> > /* Disable interrupts and store all registers */ >> > Will remove all that enabling/disabling. >> > >> > Is the same true for start.S file with interrupted task's stack saving? >> > >> I'm not sure exactly what you're referring to, but usually start.S >> will, among other things, turn off and ack pending interrupts to >> quiesce the hardware before handing off the rest of system init to >> boot_card. Eventually RTEMS will enable interrupts again using the >> cpukit's interrupt_enable layer. >> >> > >> > >> > -- >> > Regards, Denis Obrezkov > > I mean when an interrupt occurs, the execution flow jumps to the trap > address. > Then, in my case all process'es registers are saved in a common stack > (I know that dedicated interrupt stack should be implemented, but I haven't > time to do that) > and then we jump to IRQ dispatching routine. After interrupt handling we > restore saved > registers. So, my question is - should we disable/enable interrupts during > interrupt handling? > Disabling: > https://github.com/embeddedden/rtems-riscv/blob/hifive1/c/src/lib/libbsp/riscv32/hifive1/start/start.S#L201 > Jump to dispatching routine: > https://github.com/embeddedden/rtems-riscv/blob/hifive1/c/src/lib/libbsp/riscv32/hifive1/start/start.S#L241 > Enabling interrupts back: > https://github.com/embeddedden/rtems-riscv/blob/hifive1/c/src/lib/libbsp/riscv32/hifive1/start/start.S#L285 > This interrupt handling is incomplete/broken I think. Keeping the interrupts turned off for the duration of RTEMS + User ISR handling is not "real-time". What other CPU did you look at to understand how to deal with interrupts?
Usually, the BSP will support installing interrupt handlers that jump to ISR_Handler(), which then sets up a safe "C" environment for the user handler to use. The ISR_Handler() should enable interrupts before invoking the user code. From what I can tell, your implementation of ISR_Handler doesn't do anything. Gedare > > -- > Regards, Denis Obrezkov _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
