This function may be used to burn a couple of processor cycles with
minimum impact on the system bus. It may be used in busy wait loops.
Since it is a global function, it is possible to wrap it in device
driver test code.
---
cpukit/include/rtems/score/io.h | 8 +
cpukit/score/src/iorelax.
Using rtems_interrupt_entry_install() instead of
rtems_interrupt_handler_install() avoids a dependency on the dynamic memory
allocation.
---
bsps/sparc/leon3/start/bspsmp.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/bsps/sparc/leon3/start/bspsmp.c b/bsps/spar
Using rtems_interrupt_entry_install() instead of
rtems_interrupt_handler_install() avoids a dependency on the dynamic memory
allocation.
---
bsps/sparc/leon3/clock/ckinit.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/bsps/sparc/leon3/clock/ckinit.c b/bsps/sp
Using rtems_interrupt_entry_install() instead of
rtems_interrupt_handler_install() avoids a dependency on the dynamic memory
allocation.
Use Interrupt Manager directives instead of a BSP-specific API. Use inline
functions. In SMP configurations, set an affinity to all online processors and
raise
Since the trap table is now statically initialized, there is no need to
invalidate the instruction cache.
---
bsps/sparc/leon3/start/bspsmp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bsps/sparc/leon3/start/bspsmp.c b/bsps/sparc/leon3/start/bspsmp.c
index 74f9df5404..acd9
The AArch64 cache implementation does not define
rtems_cache_disable_data(), but declares that it does via
CPU_CACHE_SUPPORT_PROVIDES_DISABLE_DATA. The existing implementation of
_CPU_cache_disable_data() is sufficient to enable this functionality
without the erroneous cache feature flag.
Closes #
On 10/12/2021 16:49, Kinsey Moore wrote:
The AArch64 cache implementation does not define
rtems_cache_disable_data(), but declares that it does via
CPU_CACHE_SUPPORT_PROVIDES_DISABLE_DATA. The existing implementation of
_CPU_cache_disable_data() is sufficient to enable this functionality
without
On 10/12/21 6:20 pm, Christian MAUDERER wrote:
> Am 09.12.21 um 22:09 schrieb Chris Johns:
>> On 9/12/21 6:47 pm, Christian MAUDERER wrote:
>>
>> Given it is in maybe we let it sit and it there is feedback we come back and
>> take another look?
>
> No problem with that. I will try to be extra sens