On 23/09/2020 12:24, Daniel Hellstrom wrote:
>> 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
We already have multilibs for these variants:
sparc-rtems6-gcc -print-multi-lib
.;
soft;@msoft-float
v8;@mcpu=v8
leon3;@mcpu=leon3
leon3v7;@mcpu=leon3v7
leon;@mcpu=leon
leon3/gr712rc;@mcpu=leon3@mfix-gr712rc
leon3v7/gr712rc;@mcpu=leon3v7@mfix-gr712rc
leon/ut699;@mcpu=leon@mfix-ut699
leon/at697f;@mcpu=leon@mfix-at697f
soft/v8;@msoft-float@mcpu=v8
soft/leon3;@msoft-float@mcpu=leon3
soft/leon3v7;@msoft-float@mcpu=leon3v7
soft/leon;@msoft-float@mcpu=leon
soft/leon3/gr712rc;@msoft-float@mcpu=leon3@mfix-gr712rc
soft/leon3v7/gr712rc;@msoft-float@mcpu=leon3v7@mfix-gr712rc
soft/leon/ut699;@msoft-float@mcpu=leon@mfix-ut699
soft/leon/at697f;@msoft-float@mcpu=leon@mfix-at697f
So adding a built-in define __FIX_LEON3FT_TN0018 to GCC 10 (and clang)
would be my preferred way to add this define for RTEMS. External users
can still define __FIX_LEON3FT_TN0018 on the command line or a header
file if needed.
Independent of this we need a ticket for the TN0018.
--
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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
