On Fri, Apr 24, 2015 at 6:38 PM, Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > > ----- Hesham ALMatary <heshamelmat...@gmail.com> schrieb: >> ^^ >> s/already/only >> >> Both are working fine with or1k. Let me know which is better. I'd >> suggest getting rid of the static declaration as sparc (the only other >> CPU that empty-implements the same function) implements it without >> "static". >> > > Providing an empty implementation is wrong. Thus function needs to get > removed for the SPARC. > Agreed. If deleted will this break other SPARC BSPs that depend on this empty implementation? I don't know which SPARC BSPs do. >> >> On Fri, Apr 24, 2015 at 6:20 PM, Hesham ALMatary >> <heshamelmat...@gmail.com> wrote: >> > 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.sherr...@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.sherr...@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.sherr...@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@rtems.org >> >>>> http://lists.rtems.org/mailman/listinfo/devel >> >>> >> >>> >> >> >> >> -- >> >> Joel Sherrill, Ph.D. Director of Research & Development >> >> joel.sherr...@oarcorp.com On-Line Applications Research >> >> Ask me about RTEMS: a free RTOS Huntsville AL 35805 >> >> Support Available (256) 722-9985 >> >> >> > >> > >> > >> > -- >> > Hesham >> >> >> >> -- >> Hesham >> _______________________________________________ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > -- > 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.
-- Hesham _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
