On 2014-05-13 21:40, Andre Marques wrote:
On 05/09/14 07:04, Sebastian Huber wrote:
On 2014-05-08 18:51, Andre Marques wrote:
On 05/05/14 11:50, Sebastian Huber wrote:
On 2014-05-05 12:43, Andre Marques wrote:
Any thoughts on this?
Why not use C11 atomic operations?
Well, I didn't know they existed, thank you!
Since I have not used them before, please check if I'm thinking this right.
1. Include rtems/score/atomic.h
2. Initialize variable with ATOMIC_INITIALIZER_* as per
http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__RTEMS.html#ga676563e3ec750e9faa2727eea8ed99e1
3. Use _Atomic_Load_* to read the variable value and _Atomic_Store_* to set a
new value to the variable
4. As for memory models I'm thinking in using ATOMIC_ORDER_ACQUIRE to load and
ATOMIC_ORDER_RELEASE to store.
You can also use the _Atomic_Fence() in some situations. If you work with
devices, then the C11 atomic operations may be not sufficient.
In cpu.h we have on the ARM:
static inline void _ARM_Data_memory_barrier( void )
{
__asm__ volatile ( "dmb" : : : "memory" );
}
static inline void _ARM_Data_synchronization_barrier( void )
{
__asm__ volatile ( "dsb" : : : "memory" );
}
static inline void _ARM_Instruction_synchronization_barrier( void )
{
__asm__ volatile ( "isb" : : : "memory" );
}
Yes this memory concern is related to multiple devices working at the same time.
For what kind of synchronization do you need these barriers?
If I understood, I should use the C11 atomic operations to access the variables
(representing a memory register), along with the arm memory barriers?
Those cpu.h functions call the memory barrier instructions, but from the little
I know about the arm1176 (armv6) used on the RPi it does not support the memory
barrier instructions (dmb, dsb and isb), but instead relies on a coprocessor
instruction
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0360f/I1014942.html
I naively tried to call the _ARM_Data_memory_barrier () on the Raspberry Pi BSP
and it gave me
Error: selected processor does not support ARM mode `dmb'
I just called it, I did not made any other preparation or includes, so this may
be my fault.
This suggests (or confirms) that the inline assembly to implement those memory
barriers are lacking (for the RPi BSP at least).
Thanks for the help.
Maybe you can do something like in the attached patch.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
diff --git a/cpukit/score/cpu/arm/rtems/score/arm.h b/cpukit/score/cpu/arm/rtems/score/arm.h
index bb78cbe..a105f17 100644
--- a/cpukit/score/cpu/arm/rtems/score/arm.h
+++ b/cpukit/score/cpu/arm/rtems/score/arm.h
@@ -42,6 +42,7 @@ extern "C" {
|| defined(__ARM_ARCH_7M__)
#define ARM_MULTILIB_HAS_WFI
#define ARM_MULTILIB_HAS_LOAD_STORE_EXCLUSIVE
+ #define ARM_MULTILIB_HAS_BARRIER_INSTRUCTIONS
#endif
#if defined(__ARM_ARCH_7A__) \
diff --git a/cpukit/score/cpu/arm/rtems/score/cpu.h b/cpukit/score/cpu/arm/rtems/score/cpu.h
index d53be60..162c530 100644
--- a/cpukit/score/cpu/arm/rtems/score/cpu.h
+++ b/cpukit/score/cpu/arm/rtems/score/cpu.h
@@ -301,17 +301,29 @@ extern uint32_t arm_cpu_mode;
static inline void _ARM_Data_memory_barrier( void )
{
+#ifdef ARM_MULTILIB_HAS_BARRIER_INSTRUCTIONS
__asm__ volatile ( "dmb" : : : "memory" );
+#else
+ /* Add CP15 stuff here */
+#endif
}
static inline void _ARM_Data_synchronization_barrier( void )
{
+#ifdef ARM_MULTILIB_HAS_BARRIER_INSTRUCTIONS
__asm__ volatile ( "dsb" : : : "memory" );
+#else
+ /* Add CP15 stuff here */
+#endif
}
static inline void _ARM_Instruction_synchronization_barrier( void )
{
+#ifdef ARM_MULTILIB_HAS_BARRIER_INSTRUCTIONS
__asm__ volatile ( "isb" : : : "memory" );
+#else
+ /* Add CP15 stuff here */
+#endif
}
static inline uint32_t arm_interrupt_disable( void )
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
