Optimization issue in RISC-V BSP

Joel Sherrill joel at rtems.org
Tue Aug 1 04:15:07 UTC 2017


On Jul 31, 2017 10:54 PM, "Hesham Almatary" <heshamelmatary at gmail.com>
wrote:

On Tue, Aug 1, 2017 at 10:13 AM, Denis Obrezkov <denisobrezkov at gmail.com>
wrote:
> 2017-08-01 2:01 GMT+02:00 Hesham Almatary <heshamelmatary at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170731/74978545/attachment-0002.html>


More information about the devel mailing list