Hello,
I have updated the blog [1] last week with some info on memory barriers
for the ARM achitecture.
As for the RPi BSP, the needed inline assembly may be implemented in
three ways:
1. Any explicit memory access is done through a function, which wraps
the memory access instruction with memory barrier calls (as the rpi-boot
code does [2]).
Garantees that all memory accesses are protected, but doubles the needed
calls. For instance, if I want to read two times:
call memory_barrier
read
call memory_barrier
call memory_barrier
read
call memory_barrier
The only advantage I see with this approach is that if the next memory
access does not call memory_barrier, it would be protected. But then if
the next does not call it either, the advantage is gone.
The point is that all memory access instructions must call
memory_barrier before. Calling memory_barrier after the memory access
leads to unnecessary memory_barrier calls.
2. The same as 1., but calling memory_barrier only before the memory
access instruction.
3. A new macro would be created with the inline assembly, and the memory
barrier is called when appropriate. The driver developer would call
memory_barrier when seen fit. This may lead to some hard to find bugs.
Any thoughts on this?
--André Marques
[1] - http://asuolgsoc2014.wordpress.com/2014/04/27/memory-barrier/
[2] - https://github.com/jncronin/rpi-boot/blob/master/mmio.c
_______________________________________________
rtems-devel mailing list
[email protected]
http://www.rtems.org/mailman/listinfo/rtems-devel
