[PATCH 07/10] bsp/arm: Report correct maximal cache line length for ARM Cortex-A + L2C-310.

Sebastian Huber sebastian.huber at embedded-brains.de
Mon Jul 4 08:06:58 UTC 2016



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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.




More information about the devel mailing list