4.11 BLOCKER - Multiple BSPs fail to build - cache changes?
Hesham ALMatary
heshamelmatary at gmail.com
Fri Apr 24 17:20:05 UTC 2015
Gedare,
The corresponding function declaration and implementation are included
from libcpu/shared. There are two solutions to fix this for the all
broken BSPs:
1- Get rid of _CPU_cache_invalidate_instruction_range declaration at
libcpu/shared/include/cache.h, since this functions is already called
at cache_manager.c
2- Get rid of the static keyword at cache_manager.c.
On Fri, Apr 24, 2015 at 6:13 PM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
>
>
> On 4/24/2015 12:07 PM, Hesham ALMatary wrote:
>> Hi,
>>
>> I believe this commit is the one which broke it [1], I'm going to
>> discard the usage of the shared cache_manager.c file and provide or1k
>> with private stubs.
>>
>> [1] https://github.com/RTEMS/rtems/commit/26c142e5ad4a63ad42baa17159c1821afe473a00
> This also broke two other architectures. Fixing it for the or1k is not
> sufficient.
> Please either provide proper caching for the or1k or fix it in a way that
> fixes all three architectures.
>> On Fri, Apr 24, 2015 at 5:16 PM, Joel Sherrill
>> <joel.sherrill at oarcorp.com> wrote:
>>> Hi
>>>
>>> Multiple BSPs failed to build in my overnight sweep. All
>>> bfin and or1k BSPs plus 18 m68k failed with this:
>>>
>>> ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:340:1:
>>> error: static declaration of '_CPU_cache_invalidate_instruction_range'
>>> follows non-static declaration
>>> _CPU_cache_invalidate_instruction_range(
>>> ^
>>> In file included from
>>> ../../../../../../../rtems/c/src/lib/libcpu/m68k/shared/cache/cache_.h:37:0,
>>> from
>>> ../../../../../../../rtems/c/src/lib/libcpu/m68k/../shared/src/cache_manager.c:39:
>>> ../../../../.././mcf5329/lib/include/libcpu/cache.h:30:6: note: previous
>>> declaration of '_CPU_cache_invalidate_instruction_range' was here
>>> void _CPU_cache_invalidate_instruction_range(const void *i_addr, size_t
>>> n_bytes);
>>> ^
>>>
>>> bfin/bf537Stamp, or1k/or1k_generic, and m68k/mvme136 should
>>> be sufficient to reproduce and fix the problem.
>>>
>>> --
>>> Joel Sherrill, Ph.D. Director of Research & Development
>>> joel.sherrill at OARcorp.com On-Line Applications Research
>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
>>> Support Available (256) 722-9985
>>>
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>
> --
> Joel Sherrill, Ph.D. Director of Research & Development
> joel.sherrill at OARcorp.com On-Line Applications Research
> Ask me about RTEMS: a free RTOS Huntsville AL 35805
> Support Available (256) 722-9985
>
--
Hesham
More information about the devel
mailing list