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

[daniel at gaisler.com]

2020-10-16 07:33 skrev 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.

Agreed. I will update the patch to remove the patch to the BSPs config 
which adds the TN0018 build flags. When I tested my suggested 
sparc/rtems GCC-10 patch it worked for the above listed multilibs (only 
the affected ones defined the TN0018).

> 
> Independent of this we need a ticket for the TN0018.

I see you have created one, thanks.