Optimization issue in RISC-V BSP

[Hesham Almatary]

On Tue, Aug 1, 2017 at 2:15 PM, Joel Sherrill <joel at rtems.org> wrote:
>
>
> 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
I agree. However, saving/restoring all of the GPRs (which is what the
current code doing) should allow us to ignore the above callee/caller
cases (for simplicity/correctness).

> + Special registers
Yes, this might be the issue, specifically if the port is using
interrupts. For example, mstatus/mcause/mepc might need to be saved
and/or reset.

What I'm suspicious of is that the trap_entry code is the problem,
since it didn't have a chance to get executed/tested on my Spike
(dummy clock simulated) BSP/Spike, especially after updating the port
from 2015 to 2017 (RISC-V ABI has changed).

>
> 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
>
>



-- 
Hesham