On Mon, Jun 29, 2020 at 8:02 AM Sebastian Huber < sebastian.hu...@embedded-brains.de> wrote:
> On 29/06/2020 14:34, Daniel Hellstrom wrote: > > > > > On 2020-06-29 13:57, Sebastian Huber wrote: > >> On 29/06/2020 13:28, Daniel Hellstrom wrote: > >> > >>> diff --git a/bsps/sparc/leon3/config/gr712rc.cfg > >>> b/bsps/sparc/leon3/config/gr712rc.cfg > >>> index 3852932..e8f0731 100644 > >>> --- a/bsps/sparc/leon3/config/gr712rc.cfg > >>> +++ b/bsps/sparc/leon3/config/gr712rc.cfg > >>> @@ -10,10 +10,11 @@ RTEMS_CPU=sparc > >>> # and (hopefully) optimize for it. > >>> # GCC and clang use different switches to select target: > >>> ifneq (,$(findstring clang,$(CC))) > >>> - CPU_CFLAGS = -mcpu=gr712rc > >>> + CPU_CFLAGS = -mcpu=gr712rc -D__FIX_LEON3FT_TN0018 > >>> else > >>> - CPU_CFLAGS = -mcpu=leon3 -mfix-gr712rc > >>> + CPU_CFLAGS = -mcpu=leon3 -mfix-gr712rc -D__FIX_LEON3FT_TN0018 > >>> endif > >>> +# -D__FIX_LEON3FT_TN0018 enables kernel work around for > >>> GRLIB-TN-0018 errata > >>> # optimize flag: typically -O2 > >>> CFLAGS_OPTIMIZE_V = -O2 -g > >>> diff --git a/bsps/sparc/leon3/config/ut699.cfg > >>> b/bsps/sparc/leon3/config/ut699.cfg > >>> index a8fff49..ed70cf5 100644 > >>> --- a/bsps/sparc/leon3/config/ut699.cfg > >>> +++ b/bsps/sparc/leon3/config/ut699.cfg > >>> @@ -8,7 +8,8 @@ RTEMS_CPU=sparc > >>> # This contains the compiler options necessary to select the > >>> CPU model > >>> # and (hopefully) optimize for it. > >>> -CPU_CFLAGS = -mcpu=leon -mfix-ut699 > >>> +# -D__FIX_LEON3FT_TN0018 enables kernel work around for > >>> GRLIB-TN-0018 errata > >>> +CPU_CFLAGS = -mcpu=leon -mfix-ut699 -D__FIX_LEON3FT_TN0018 > >>> # optimize flag: typically -O2 > >>> CFLAGS_OPTIMIZE_V = -O2 -g > >>> diff --git a/bsps/sparc/leon3/config/ut700.cfg > >>> b/bsps/sparc/leon3/config/ut700.cfg > >>> index bcca901..5c6fff8 100644 > >>> --- a/bsps/sparc/leon3/config/ut700.cfg > >>> +++ b/bsps/sparc/leon3/config/ut700.cfg > >>> @@ -8,7 +8,8 @@ RTEMS_CPU=sparc > >>> # This contains the compiler options necessary to select the > >>> CPU model > >>> # and (hopefully) optimize for it. > >>> -CPU_CFLAGS = -mcpu=leon3 -mfix-ut700 > >>> +# -D__FIX_LEON3FT_TN0018 enables kernel work around for > >>> GRLIB-TN-0018 errata > >>> +CPU_CFLAGS = -mcpu=leon3 -mfix-ut700 -D__FIX_LEON3FT_TN0018 > >>> # optimize flag: typically -O2 > >>> CFLAGS_OPTIMIZE_V = -O2 -g > >> Command line defines are discouraged and in cpukit only multilib > >> defined defines should be used. Can't you the existing > >> __FIX_LEON3FT_B2BST define to enable the errata workarounds? > > > > For UT700, for example, it is true that B2BST also needs to be > > defined, but in general a user may have TN0018 but not the B2BST since > > it was fixed in HW several years ago. > You mean users building for a custom chip design and a BSP which is not > integrated in the RTEMS Project? > > There is no fix needed to the compiler or newlib affecting the > > multilibs, the workaround can be implemented purely in the run-time > > time time which simplifies the impact on the user. When building > > multiple BSPs this is very convenient too since the configure line can > > remain the same regardless of the work around. The compiler does not > > emit any information about TN0018 or UT700 for example. > So far the rule was to use only multilib defined defines and CPU options > in the cpukit. I am not sure what we should do to address issues like > this. Maybe add CPU-specific CPU options? > This general pattern has forced some files to migrate from cpukit to libbsp/shared and be built with the BSP. The SPARC interrupt processing was moved during the SMP development because it needed to know some distinction not allowed in the cpukit. I don't like adding this as a -D on the compile like but that doesn't leave a good home. I sure don't want to add a bsp specific configure option for something like this. --joel > > _______________________________________________ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
