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
<[email protected]
<mailto:[email protected]>> 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@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@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@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@daniel:/opt/rcc-1.3.0-gcc/src/samples$
sparc-gaisler-rtems5-gcc -dM -E empty.c -mcpu=leon3 |grep TN0018
daniel@daniel:/opt/rcc-1.3.0-gcc/src/samples$
sparc-gaisler-rtems5-gcc -dM -E empty.c -mcpu=leon |grep TN0018
daniel@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
[email protected] <mailto:[email protected]>
http://lists.rtems.org/mailman/listinfo/devel
From 26ff049693a0798813579c26ae0c91bbed3c2965 Mon Sep 17 00:00:00 2001
From: Daniel Hellstrom <[email protected]>
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
_______________________________________________
devel mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/devel
