On 2014-07-04 11:56, Daniel Cederman wrote:
> I think it is a general bug if you change the trap responsible for the
> IPI after the start request of the secondary processors. At which point
> does this problem happen currently?
The trap responsible for IPIs is only set before the secondary
Thank you for your comments Joel!
> I really don't like adding calls to anything BSP_xxx in score/cpu.
>
> Can this be done in bsp_postdriver_hook() for the LEON3?
It is only the main cpu that calls bsp_postdriver_hook() and the cache
invalidation code needs to be run on the secondary cpus. I c
> I think it is a general bug if you change the trap responsible for the
> IPI after the start request of the secondary processors. At which point
> does this problem happen currently?
The trap responsible for IPIs is only set before the secondary
processors are started and is not changed after
On 2014-07-03 11:39, Daniel Cederman wrote:
A secondary processor might miss changes done to the trap table
if the instruction cache is not flushed. Once interrupts are enabled
any other required cache flushes can be ordered via the cache
manager.
I think it is a general bug if you change the t
On 7/3/2014 4:39 AM, Daniel Cederman wrote:
> A secondary processor might miss changes done to the trap table
> if the instruction cache is not flushed. Once interrupts are enabled
> any other required cache flushes can be ordered via the cache
> manager.
> ---
> c/src/lib/libbsp/sparc/leon3/star
A secondary processor might miss changes done to the trap table
if the instruction cache is not flushed. Once interrupts are enabled
any other required cache flushes can be ordered via the cache
manager.
---
c/src/lib/libbsp/sparc/leon3/startup/bspsmp.c |9 +
cpukit/score/cpu/sparc/rte
