[PATCH 26/26] leon,tn-0018: work around GRLIB-TN-0018 errata

[Joel Sherrill]

On Mon, Jun 29, 2020 at 8:02 AM Sebastian Huber <
sebastian.huber at 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 at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20200629/9270aaef/attachment.html>