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 2014-07-03 11:37, Daniel Cederman wrote:
Adds functions that allows the user to specify which cores that should
perform the cache operation. SMP messages are sent to all the specified
cores and the caller waits until all cores have acknowledged that they
have flushed their cache. Implementatio
On 2014-07-03 11:37, Daniel Cederman wrote:
--- a/cpukit/score/include/rtems/score/smpimpl.h
+++ b/cpukit/score/include/rtems/score/smpimpl.h
@@ -159,7 +159,7 @@ static inline void _SMP_Inter_processor_interrupt_handler(
void )
* @param[in] cpu_index The target processor of the message.
*
On 2014-07-03 09:29, Daniel Hellstrom wrote:
By removing the bsp_reset() mechanism and instead relying on the
CPU_Fatal_halt() routine SMP and single-core can halt by updating
the _Internal_errors_What_happened structure and set the state to
SYSTEM_STATE_TERMINATED (the generic way). This will be
On 2014-07-03 16:55, Joel Sherrill wrote:
As an aside, should the _Internal_errors_What_happened
structure be filled in earlier in _Terminate? How about
just after disabling interrupts?
I think we should remove _Internal_errors_What_happened. It makes no sense on
SMP and the application can g
On 2014-07-03 11:39, Daniel Cederman wrote:
@@ -39,7 +40,9 @@ void bsp_start_on_secondary_processor()
{
uint32_t cpu_index_self = _CPU_SMP_Get_current_processor();
- leon3_set_cache_control_register(0x8F);
+ if( ! leon3_data_cache_snooping_enabled() )
+BSP_fatal_exit( LEON3_FATAL
On 4/07/2014 3:24 am, Joel Sherrill wrote:
On 7/3/2014 2:59 AM, Daniel Hellstrom wrote:
In order to support older toolchains and LEON3 v7 systems the
-mcpu=leon3 flag can not be used in the LEON3 BSP. The SMP
kernel however requires -mcpu=leon3 for the CAS support only
present in GCC-4.8 and GC
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
OK except one style comment.
On 7/3/2014 4:39 AM, Daniel Cederman wrote:
> The flush instruction on LEON flushes both the data and the instruction
> cache. Flushing of just the instruction cache can be done by setting
> the "flush instruction cache" bit in the cache control register.
> ---
> c/src
OK besides style comments.
On 7/3/2014 4:39 AM, Daniel Cederman wrote:
> Check that data cache snooping exists and is enabled on all cores.
> ---
> c/src/lib/libbsp/shared/include/fatal.h |1 +
> c/src/lib/libbsp/sparc/leon3/include/leon.h | 10 ++
> c/src/lib/libbsp/sparc/le
Seems reasonable. My only concern is creeping sysstate.h
into cpu.c but I think that's OK.
--joel
On 7/3/2014 4:39 AM, Daniel Cederman wrote:
> Changes to the trap table might be missed by other cores.
> If the system state is up, the other cores can be notified
> using SMP messages that they need
I don't know why but I don't see any code on this.
On 7/3/2014 4:39 AM, Daniel Cederman wrote:
> When entering up state, but before enabling interrupts,
> the icaches are flushed to make sure that changes to the trap
> table are visible. After up state the SMP cache manager is
> used to order cach
Comments inline. But mostly the same style comments.
Check that they aren't needed in other places. I didn't
note them everywhere.
On 7/3/2014 4:37 AM, Daniel Cederman wrote:
> Adds functions that allows the user to specify which cores that should
> perform the cache operation. SMP messages are se
I assume this is just fixing the types to match the
assumed prototype.
This needs a comment but if that's the intent, it is
OK.
On 7/3/2014 4:37 AM, Daniel Cederman wrote:
> ---
> cpukit/score/include/rtems/score/smpimpl.h |2 +-
> cpukit/score/src/smp.c |2 +-
> 2 fi
This is OK.
I assume there are other use cases to justify adding it.
On 7/3/2014 4:37 AM, Daniel Cederman wrote:
> Make _SMP_Broadcast_message() use the function to send a message to all CPUs
> except itself.
> ---
> cpukit/score/include/rtems/score/smpimpl.h | 10 ++
> cpukit/score/s
I don't know why but I don't see any file changes on this.
On 7/3/2014 4:37 AM, Daniel Cederman wrote:
> Adds functions to request cache operations on a set of cores.
>
> Daniel Cederman (3):
> score: Use consistent type for SMP messages
> score: Add function to send a SMP message to a set of
On 7/3/2014 2:59 AM, Daniel Hellstrom wrote:
> In order to support older toolchains and LEON3 v7 systems the
> -mcpu=leon3 flag can not be used in the LEON3 BSP. The SMP
> kernel however requires -mcpu=leon3 for the CAS support only
> present in GCC-4.8 and GCC-4.9.
I don't know if older tools is
On 7/3/2014 2:29 AM, Daniel Hellstrom wrote:
> By removing the bsp_reset() mechanism and instead relying on the
> CPU_Fatal_halt() routine SMP and single-core can halt by updating
> the _Internal_errors_What_happened structure and set the state to
> SYSTEM_STATE_TERMINATED (the generic way). This
I am wondering if I don't have a vision for what this
series of patches is trying to accomplish in whole.
And I am hung up on not wanting BSP references in
score. So I would like an elegant solution.
How does tweaking the bsp_reset() method not
address all of this? It is invoked along the _Termin
I don't have a problem with this in principle but reviewing
the earlier patches and seeing similar names in other
BSPs makes me wonder if we can't get a better name.
Isn't this really just bsp_reset?
I don't see needing the symbol BSP_fatal_exit().
On 7/3/2014 2:29 AM, Daniel Hellstrom wrote:
>
This looks good to me.
Also looks like you found one of those odd dead routines
I mentioned against the first patch in this series.
On 7/3/2014 2:29 AM, Daniel Hellstrom wrote:
> PATCHv2: unreachable code after SMP secondary CPU init or boot_card
> calls, is now removed instead of cleane
This looks mostly mechanical and the biggest issue is
what to do with the source in the generic shutdown
case. The first thing is that I think this is already handled
and the information is stored in
_Internal_errors_What_happened in score/src/interr.c
before _CPU_Fatal_halt() is invoked. I would
On 7/3/2014 7:49 AM, Richard Earnshaw wrote:
> On 03/07/14 13:17, Nicholas Clifton wrote:
>> Hi Jeff,
>>
>> > Pavel Pisa wrote:
>>> Index: newlib-2.1/newlib/libc/machine/arm/memchr.S
>>> ===
>>> --- newlib-2.1.orig/newlib/libc/machi
Check that data cache snooping exists and is enabled on all cores.
---
c/src/lib/libbsp/shared/include/fatal.h |1 +
c/src/lib/libbsp/sparc/leon3/include/leon.h | 10 ++
c/src/lib/libbsp/sparc/leon3/startup/bspsmp.c |8 ++--
3 files changed, 17 insertions(+), 2 deleti
The flush instruction on LEON flushes both the data and the instruction
cache. Flushing of just the instruction cache can be done by setting
the "flush instruction cache" bit in the cache control register.
---
c/src/lib/libbsp/sparc/leon3/include/cache_.h |4 +++-
c/src/lib/libbsp/sparc/leon3/
When entering up state, but before enabling interrupts,
the icaches are flushed to make sure that changes to the trap
table are visible. After up state the SMP cache manager is
used to order cache flushes whenever the trap table is altered.
Daniel Cederman (2):
bsp/sparc: Flush icache before fir
Changes to the trap table might be missed by other cores.
If the system state is up, the other cores can be notified
using SMP messages that they need to flush their icache.
If the up state has not been reached there is no need to
notify other cores. They will do an automatic flush of the
icache ju
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
Make _SMP_Broadcast_message() use the function to send a message to all CPUs
except itself.
---
cpukit/score/include/rtems/score/smpimpl.h | 10 ++
cpukit/score/src/smp.c | 15 ---
2 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/cpukit/s
Adds functions to request cache operations on a set of cores.
Daniel Cederman (3):
score: Use consistent type for SMP messages
score: Add function to send a SMP message to a set of CPUs
score: Add SMP support to the cache manager
c/src/lib/libcpu/shared/src/cache_manager.c | 166 +
Adds functions that allows the user to specify which cores that should
perform the cache operation. SMP messages are sent to all the specified
cores and the caller waits until all cores have acknowledged that they
have flushed their cache. Implementation is shown using both function
pointers and fu
---
cpukit/score/include/rtems/score/smpimpl.h |2 +-
cpukit/score/src/smp.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/cpukit/score/include/rtems/score/smpimpl.h
b/cpukit/score/include/rtems/score/smpimpl.h
index e2fee39..ba16c8f 100644
---
NGMP is a new BSP and is SMP capable which requires the
mcpu=leon3 flag. The LEON4 CPU is backwards compatible
with the LEON3.
---
c/src/lib/libbsp/sparc/leon3/make/custom/ngmp.cfg |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/c/src/lib/libbsp/sparc/leon3/make/custom/ng
In order to support older toolchains and LEON3 v7 systems the
-mcpu=leon3 flag can not be used in the LEON3 BSP. The SMP
kernel however requires -mcpu=leon3 for the CAS support only
present in GCC-4.8 and GCC-4.9.
---
.../libbsp/sparc/leon3/make/custom/leon3smp.cfg|8
1 files chan
By removing the bsp_reset() mechanism and instead relying on the
CPU_Fatal_halt() routine SMP and single-core can halt by updating
the _Internal_errors_What_happened structure and set the state to
SYSTEM_STATE_TERMINATED (the generic way). This will be better
for test scripts and debugger that can
PATCHv2: unreachable code after SMP secondary CPU init or boot_card
calls, is now removed instead of cleaned-up.
---
c/src/lib/libbsp/sparc/erc32/include/bsp.h |2 --
c/src/lib/libbsp/sparc/leon2/include/bsp.h |2 --
c/src/lib/libbsp/sparc/leon3/include/bsp.h |2 --
c/src/l
Without the source the error code does not say that much.
Let it be up to the CPU/BSP to determine the error code
reported on fatal shutdown.
This patch does not change the current behaviour, just
adds the option to handle the source of the fatal halt.
---
cpukit/score/cpu/arm/rtems/score/cpu.h
PATCHv2: BSP_fatal_halt renamed to _BSP_Fatal_halt
The Fatal_halt handler now have two options, either halt
as before or enter system error state to return to
debugger or simulator. The exit-code is now also
propagated to the debugger which is very useful for
testing.
The CPU_Fatal_halt handler w
PATCHv2: BSP_fatal_exit defined in header
Instead of calling the system call TA instruction directly it
is better paractise to isolate the trap implementation to the
system call functions.
BSP_fatal_exit() is added.
---
c/src/lib/libbsp/sparc/erc32/Makefile.am |1 +
c/src/lib/libbs
39 matches
Mail list logo
