On 04/07/16 10:00, Pavel Pisa wrote:
On Monday 04 of July 2016 07:31:23 Sebastian Huber wrote:
>Does it make sense to use the new
>
>ARM_MULTILIB_CACHE_LINE_MAX_64B
>
>here?
ARM_MULTILIB_CACHE_LINE_MAX_64B (CPU_CACHE_LINE_BYTES 64) is required
for superset of BSPs which really need CPU_MAXIMAL_CACHE_ALIGNMENT to be
set to 64. CPU kit can be build once for whole class of targets
( GCC multilib arm-rtems4.12/lib/thumb/armv7-a )
and there is no way to correct compiled in data structures
alignment for concrete BSP during linking.
On the other hand /c/src/lib/libbsp/arm/shared/arm-l2c-310/cache_.h
is compiled for each BSP separately which means that it can be tuned
to not require 64 bytes for dynamic allocation when given Cortex-A
variant has needs only 32 bytes alignment required .
CPU_MAXIMAL_CACHE_ALIGNMENT
has to be greater or equal than the CPU_CACHE_LINE_BYTES.
But that check is already provided in cache_manager.c.
So for there is no difference now. But it can be tuned
per cache_.h and for some ARM cores can be maximal system cache
line length can be even obtained dynamically from CP15.
So I think that independence of these two has some reason
even that they are same for now.
Ok, makes sense.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
