[PATCH 26/26] leon,tn-0018: work around GRLIB-TN-0018 errata
Daniel Hellstrom
daniel at gaisler.com
Wed Sep 23 10:24:58 UTC 2020
Hi,
Thank you for your comments. Sorry for my late reply, please see my
responses below.
On 2020-06-29 15:13, Joel Sherrill wrote:
>
>
> On Mon, Jun 29, 2020 at 8:02 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de
> <mailto: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?
>
Yes. Maybe that should not be our primary focus for RTEMS though.
> > 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?
>
We could turn on __FIX_LEON3FT_TN0018 define for the multilibs defined
in GCC, but make it RTEMS specific? Please see attached GCC patch. This
would take care of the mainstream users, and the other LEON3 users could
enable the fix by adding the -D manually by specifying the target CFLAGS
when doing RTEMS configure? I could live with that.
When building with the GCC patch it gives:
daniel at daniel:/opt/rcc-1.3.0-gcc/src/samples$
sparc-gaisler-rtems5-gcc -dM -E empty.c -mcpu=leon3 -mfix-gr712rc |grep
TN0018
#define __FIX_LEON3FT_TN0018 1
daniel at daniel:/opt/rcc-1.3.0-gcc/src/samples$
sparc-gaisler-rtems5-gcc -dM -E empty.c -mcpu=leon3 -mfix-ut700 |grep TN0018
#define __FIX_LEON3FT_TN0018 1
daniel at daniel:/opt/rcc-1.3.0-gcc/src/samples$
sparc-gaisler-rtems5-gcc -dM -E empty.c -mcpu=leon3 -mfix-ut699 |grep TN0018
#define __FIX_LEON3FT_TN0018 1
daniel at daniel:/opt/rcc-1.3.0-gcc/src/samples$
sparc-gaisler-rtems5-gcc -dM -E empty.c -mcpu=leon3 |grep TN0018
daniel at daniel:/opt/rcc-1.3.0-gcc/src/samples$
sparc-gaisler-rtems5-gcc -dM -E empty.c -mcpu=leon |grep TN0018
daniel at daniel:/opt/rcc-1.3.0-gcc/src/samples$
>
> 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.
Ok, makes sense. See above suggestion.
/Daniel
>
> --joel
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org <mailto: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/20200923/73c173d8/attachment-0001.html>
-------------- next part --------------
From 26ff049693a0798813579c26ae0c91bbed3c2965 Mon Sep 17 00:00:00 2001
From: Daniel Hellstrom <daniel at gaisler.com>
Date: Mon, 21 Sep 2020 14:36:03 +0200
Subject: [PATCH 1/1] rtems: add __FIX_LEON3FT_TN0018 for affected targets
Enable a define FIX_LEON3FT_TN0018 for the LEON3FT targets affecdted
by the GRLIB-TN-0018 errata described here:
https://www.gaisler.com/notes
---
gcc/config/sparc/rtemself.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/config/sparc/rtemself.h b/gcc/config/sparc/rtemself.h
index 6570590..ddec98c 100644
--- a/gcc/config/sparc/rtemself.h
+++ b/gcc/config/sparc/rtemself.h
@@ -33,6 +33,8 @@
builtin_assert ("system=rtems"); \
if (sparc_fix_b2bst) \
builtin_define ("__FIX_LEON3FT_B2BST"); \
+ if (sparc_fix_gr712rc || sparc_fix_ut700 || sparc_fix_ut699) \
+ builtin_define ("__FIX_LEON3FT_TN0018"); \
} \
while (0)
--
2.7.4
More information about the devel
mailing list