Mailbox RPi patch and rtems_cache_* probably broken on RPi

[Pavel Pisa]

Hello all,

I have checked how are rtems_cache_* operations implemented/linked
to the RTEMS RPi1 image and I have found that they are stubbed

   0xad94 <rtems_cache_flush_multiple_data_lines>:	bx	lr
   0xad98 <rtems_cache_invalidate_multiple_data_lines>:	bx	lr

RTEMS has been configured as

../../../git/rtems/configure --target=arm-rtems4.12 --prefix=/opt/rtems4.12 \
  --enable-rtems-inlines --disable-multiprocessing --enable-cxx \
  --enable-rdbg --enable-maintainer-mode --enable-tests=samples \
  --disable-networking --enable-posix --disable-itron --disable-ada \
  --disable-expada --disable-multilib --disable-docs \
  --enable-rtemsbsp="raspberrypi"

This seems suspicious.

rtems_cache_flush_multiple_data_lines( const void * d_addr, size_t n_bytes )
{
#if defined(CPU_DATA_CACHE_ALIGNMENT)
#if defined(CPU_CACHE_SUPPORT_PROVIDES_RANGE_FUNCTIONS)
  _CPU_cache_flush_data_range( d_addr, n_bytes );
#else
  const void * final_address;
.......
#endif
#endif
}

and result is that CPU_DATA_CACHE_ALIGNMENT is not defined
for (my) raspberrypi build !!!!!!!!

I see cache alignment defined in ARM case only for ARM_ARCH_5TEJ

rtems/c/src/lib/libcpu/arm/shared/include/cache_.h 

#ifdef __ARM_ARCH_5TEJ__
  #include <libcpu/arm-cp15.h>

  #define CPU_DATA_CACHE_ALIGNMENT 32
  #define CPU_INSTRUCTION_CACHE_ALIGNMENT 32

and then only for Cortex-M

rtems/c/src/lib/libbsp/arm/shared/armv7m/include/cache_.h

so that is strange and even size 32 bytes which is correct only
for subset of CPUs. RPi2 is Cortex-A7 based for example
and it includes 64 bytes length data cache lines.
But it may be better to define smaller value than
larger, because smaller leads to double line flushing
then skipping the lines. But for cache line aligned
allocation it is more disastrous to define smaller
cache line size because then cacheline aligned allocations
would lead to share of device owned area with CPU modified
data which means that data in shared line received
from device can be lost due reading/dirtying other
part from CPU. To make things safe it would worth
to define not only
  CPU_DATA_CACHE_ALIGNMENT
but even
  CPU_MAXIMAL_CACHE_ALIGNMENT
which should be used for allocation.
Or CPU_CACHE_LINE_BYTES plays this role?

If my findins are right that it has to break many things,
DMA, Ethernet controllers accessing main memory etc.

I miss in RTEMS cache manager some operation
to ensure sync of range from data cache to instruction
cache which is important for RTL support.
Such operation can be optimized to not flush
unnecessarily data from shared cache (usually L2)
when we need only to propagate them between local
CPU L1 data to all CPUs L1 code.

Best wishes,

             Pavel