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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel