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