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

[Sebastian Huber]

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 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

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 at mfix-gr712rc
leon3v7/gr712rc;@mcpu=leon3v7 at mfix-gr712rc
leon/ut699;@mcpu=leon at mfix-ut699
leon/at697f;@mcpu=leon at mfix-at697f
soft/v8;@msoft-float at mcpu=v8
soft/leon3;@msoft-float at mcpu=leon3
soft/leon3v7;@msoft-float at mcpu=leon3v7
soft/leon;@msoft-float at mcpu=leon
soft/leon3/gr712rc;@msoft-float at mcpu=leon3 at mfix-gr712rc
soft/leon3v7/gr712rc;@msoft-float at mcpu=leon3v7 at mfix-gr712rc
soft/leon/ut699;@msoft-float at mcpu=leon at mfix-ut699
soft/leon/at697f;@msoft-float at mcpu=leon at 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.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.