This could explain a number of problems reported by students trying to
get their RPi peripherals working. The cache manager has never been a
robust and complete implementation. I think it must be carefully
looked at across targets (easier when we delete obsolete
architectures!).
It looks like every arch's cache_.h should be defining
CPU_DATA_CACHE_ALIGNMENT if it has a data cache. This requirement has
probably never been documented properly somewhere, and it rightly may
belong in the score/cpu/*/rtems/score/cpu.h.
I'm not sure what you mean by maximal cache alignment.
On Wed, Jun 22, 2016 at 5:15 PM, Pavel Pisa <ppisa4li...@pikron.com> wrote:
> 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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
