On Jul 31, 2017 10:54 PM, "Hesham Almatary" <heshamelmat...@gmail.com> wrote:
On Tue, Aug 1, 2017 at 10:13 AM, Denis Obrezkov <denisobrez...@gmail.com> wrote: > 2017-08-01 2:01 GMT+02:00 Hesham Almatary <heshamelmat...@gmail.com>: >> >> Hi Denis, >> >> If you're not using interrupts (i.e. only using dummy clock), then >> trap_entry at start.S shouldn't be executed after bootstrap. That's >> why I suggested you use dummy clock first to figure out if the problem >> is with the context switch code or not. >> >> I'm not getting the full context/details; did you try with dummy clock >> first (interrupts disabled) and it didn't work? If so, you can set a >> breakpoint at trap_entry to check it's not being executed. > > > I checked that trap_entry saves registers properly. And I am trying to > implement interrupt-driven clock driver. > With it, I can at least obtain some ticks. > My point is when you're using the dummy clock driver first, you'll be able to figure out if the problem is with the context switch code, or your newly added/modified trap_entry handling and the clock driver. Not claiming the context switch code is 100% correct (especially for your BSP), but ticker works fine on Spike (riscv_generic BSP) with dummy clock driver. When approaching the register set of a cpu for a port, you have two look at them in three general classes: + Not preserved across subroutine calls + preserved across subroutine calls + Special registers If it is not preserved across a subroutine call, then it does not have to be in the context switch but is in the ISR context. If it is preserved across subroutine calls, then it is in the context switch. Special registers have to be analyzed. Some may have a magic value across the entire system life. Others will require special handling. Every register needs to be logically places in a class for management purposes. > As for now, I am getting an error on mret instruction, I will try to figure > out tomorrow, why it happens. > Also, in my debugger 'display /i $pc' suddenly started to work properly. > So, now I can debug a bit more efficient. > -- > Regards, Denis Obrezkov -- Hesham
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
