Bacport of ARM cache, RTL and TMS570 to RTEMS 4.11 Was: Simple question about RTL

[Pavel Pisa]

Hello Alan,

thanks much for test.

On Monday 03 of October 2016 03:40:46 Alan Cudmore wrote:
> Hi Pavel,
> I have built the Raspberry Pi 1 and 2 BSPs with the latest 4.11 branch. I
> plan on testing them soon.
>
> I also tried to build the 4.11 sparc/sis BSP, but it failed to compile:
> ../../../../../../../rtems-src/rtems-4.11/c/src/../../cpukit/libdl/rtl-obj.
>c:585:47: error: 'CPU_CACHE_LINE_BYTES' undeclared (first use in this
> function) old_end = (uintptr_t)sync_ctx->end_va & ~(CPU_CACHE_LINE_BYTES -
> 1);
>
> It looks like rtl-obj.c uses CPU_CACHE_LINE_BYTES, but a grep only shows
> that is defined for ARM.

This bug falls on my head. I have not noticed that it is not defined
on 4.11 same as on the master.

I have introduced that for ARM to change hardcodded aligned
to 4.12 style. The right think id probably to return this to hardcoded
value

#if defined(ARM_MULTILIB_CACHE_LINE_MAX_64)
  #define CPU_CACHE_LINE_BYTES 32
#else
  #define CPU_CACHE_LINE_BYTES 64
#endif

#define CPU_STRUCTURE_ALIGNMENT __attribute__ ((aligned (CPU_CACHE_LINE_BYTES )))


> Do we need to back port these defines for the other CPU architectures as
> well?

As for RTL, the line size is used only for optimization, merging
directly following sections to the single region so it is not critical
if value is instruction/data cache line max/min

    old_end = (uintptr_t)sync_ctx->end_va & ~(CPU_CACHE_LINE_BYTES - 1);
    new_start = (uintptr_t)sect->base & ~(CPU_CACHE_LINE_BYTES - 1);
    if ( (sect->base <  sync_ctx->start_va) ||

So any value returned from the cache manager can be used there

  rtems_cache_get_maximal_line_size()

  rtems_cache_get_instruction_line_size()

  rtems_cache_get_data_line_size()

I would would prefer rtems_cache_get_maximal_line_size()
and to use this for both master and 4.11 to keep consistency.

What is preferred change for CPU_CACHE_LINE_BYTES removal from 4.11 ARM?
I am inclined it to remove it to ensure same behavior over all architectures.
Introduction would help with compatibility but it I think that other architectures
should not be touched by this ARM bring up.

Best wishes,

Pavel