<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,</p>
<p>Thank you for your comments. Sorry for my late reply, please see
my responses below.</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 2020-06-29 15:13, Joel Sherrill
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAF9ehCWBaeDmtU0AjuE_5thhZHR2KO_r80NG8LcqsrL66hs1+A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Jun 29, 2020 at 8:02
AM Sebastian Huber <<a
href="mailto:sebastian.huber@embedded-brains.de"
moz-do-not-send="true">sebastian.huber@embedded-brains.de</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">On 29/06/2020 14:34,
Daniel Hellstrom wrote:<br>
<br>
><br>
> On 2020-06-29 13:57, Sebastian Huber wrote:<br>
>> On 29/06/2020 13:28, Daniel Hellstrom wrote:<br>
>><br>
>>> diff --git
a/bsps/sparc/leon3/config/gr712rc.cfg <br>
>>> b/bsps/sparc/leon3/config/gr712rc.cfg<br>
>>> index 3852932..e8f0731 100644<br>
>>> --- a/bsps/sparc/leon3/config/gr712rc.cfg<br>
>>> +++ b/bsps/sparc/leon3/config/gr712rc.cfg<br>
>>> @@ -10,10 +10,11 @@ RTEMS_CPU=sparc<br>
>>> # and (hopefully) optimize for it.<br>
>>> # GCC and clang use different switches to
select target:<br>
>>> ifneq (,$(findstring clang,$(CC)))<br>
>>> - CPU_CFLAGS = -mcpu=gr712rc<br>
>>> + CPU_CFLAGS = -mcpu=gr712rc
-D__FIX_LEON3FT_TN0018<br>
>>> else<br>
>>> - CPU_CFLAGS = -mcpu=leon3 -mfix-gr712rc<br>
>>> + CPU_CFLAGS = -mcpu=leon3 -mfix-gr712rc
-D__FIX_LEON3FT_TN0018<br>
>>> endif<br>
>>> +# -D__FIX_LEON3FT_TN0018 enables kernel work
around for <br>
>>> GRLIB-TN-0018 errata<br>
>>> # optimize flag: typically -O2<br>
>>> CFLAGS_OPTIMIZE_V = -O2 -g<br>
>>> diff --git a/bsps/sparc/leon3/config/ut699.cfg
<br>
>>> b/bsps/sparc/leon3/config/ut699.cfg<br>
>>> index a8fff49..ed70cf5 100644<br>
>>> --- a/bsps/sparc/leon3/config/ut699.cfg<br>
>>> +++ b/bsps/sparc/leon3/config/ut699.cfg<br>
>>> @@ -8,7 +8,8 @@ RTEMS_CPU=sparc<br>
>>> # This contains the compiler options
necessary to select the <br>
>>> CPU model<br>
>>> # and (hopefully) optimize for it.<br>
>>> -CPU_CFLAGS = -mcpu=leon -mfix-ut699<br>
>>> +# -D__FIX_LEON3FT_TN0018 enables kernel work
around for <br>
>>> GRLIB-TN-0018 errata<br>
>>> +CPU_CFLAGS = -mcpu=leon -mfix-ut699
-D__FIX_LEON3FT_TN0018<br>
>>> # optimize flag: typically -O2<br>
>>> CFLAGS_OPTIMIZE_V = -O2 -g<br>
>>> diff --git a/bsps/sparc/leon3/config/ut700.cfg
<br>
>>> b/bsps/sparc/leon3/config/ut700.cfg<br>
>>> index bcca901..5c6fff8 100644<br>
>>> --- a/bsps/sparc/leon3/config/ut700.cfg<br>
>>> +++ b/bsps/sparc/leon3/config/ut700.cfg<br>
>>> @@ -8,7 +8,8 @@ RTEMS_CPU=sparc<br>
>>> # This contains the compiler options
necessary to select the <br>
>>> CPU model<br>
>>> # and (hopefully) optimize for it.<br>
>>> -CPU_CFLAGS = -mcpu=leon3 -mfix-ut700<br>
>>> +# -D__FIX_LEON3FT_TN0018 enables kernel work
around for <br>
>>> GRLIB-TN-0018 errata<br>
>>> +CPU_CFLAGS = -mcpu=leon3 -mfix-ut700
-D__FIX_LEON3FT_TN0018<br>
>>> # optimize flag: typically -O2<br>
>>> CFLAGS_OPTIMIZE_V = -O2 -g<br>
>> Command line defines are discouraged and in cpukit
only multilib <br>
>> defined defines should be used. Can't you the
existing <br>
>> __FIX_LEON3FT_B2BST define to enable the errata
workarounds?<br>
><br>
> For UT700, for example, it is true that B2BST also
needs to be <br>
> defined, but in general a user may have TN0018 but not
the B2BST since <br>
> it was fixed in HW several years ago. <br>
You mean users building for a custom chip design and a BSP
which is not <br>
integrated in the RTEMS Project?<br>
</blockquote>
</div>
</div>
</blockquote>
<p>Yes. Maybe that should not be our primary focus for RTEMS though.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAF9ehCWBaeDmtU0AjuE_5thhZHR2KO_r80NG8LcqsrL66hs1+A@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
> There is no fix needed to the compiler or newlib
affecting the <br>
> multilibs, the workaround can be implemented purely in
the run-time <br>
> time time which simplifies the impact on the user. When
building <br>
> multiple BSPs this is very convenient too since the
configure line can <br>
> remain the same regardless of the work around. The
compiler does not <br>
> emit any information about TN0018 or UT700 for example.
<br>
So far the rule was to use only multilib defined defines and
CPU options <br>
in the cpukit. I am not sure what we should do to address
issues like <br>
this. Maybe add CPU-specific CPU options?<br>
</blockquote>
</div>
</div>
</blockquote>
<p>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.<br>
</p>
<p>When building with the GCC patch it gives:</p>
<p><tt> <a class="moz-txt-link-abbreviated" href="mailto:daniel@daniel:/opt/rcc-1.3.0-gcc/src/samples$">daniel@daniel:/opt/rcc-1.3.0-gcc/src/samples$</a>
sparc-gaisler-rtems5-gcc -dM -E empty.c -mcpu=leon3
-mfix-gr712rc |grep TN0018</tt><tt><br>
</tt><tt> #define __FIX_LEON3FT_TN0018 1</tt><tt><br>
</tt><tt> <a class="moz-txt-link-abbreviated" href="mailto:daniel@daniel:/opt/rcc-1.3.0-gcc/src/samples$">daniel@daniel:/opt/rcc-1.3.0-gcc/src/samples$</a>
sparc-gaisler-rtems5-gcc -dM -E empty.c -mcpu=leon3 -mfix-ut700
|grep TN0018</tt><tt><br>
</tt><tt> #define __FIX_LEON3FT_TN0018 1</tt><tt><br>
</tt><tt> <a class="moz-txt-link-abbreviated" href="mailto:daniel@daniel:/opt/rcc-1.3.0-gcc/src/samples$">daniel@daniel:/opt/rcc-1.3.0-gcc/src/samples$</a>
sparc-gaisler-rtems5-gcc -dM -E empty.c -mcpu=leon3 -mfix-ut699
|grep TN0018</tt><tt><br>
</tt><tt> #define __FIX_LEON3FT_TN0018 1</tt><tt><br>
</tt><tt> <a class="moz-txt-link-abbreviated" href="mailto:daniel@daniel:/opt/rcc-1.3.0-gcc/src/samples$">daniel@daniel:/opt/rcc-1.3.0-gcc/src/samples$</a>
sparc-gaisler-rtems5-gcc -dM -E empty.c -mcpu=leon3 |grep
TN0018</tt><tt><br>
</tt><tt> <a class="moz-txt-link-abbreviated" href="mailto:daniel@daniel:/opt/rcc-1.3.0-gcc/src/samples$">daniel@daniel:/opt/rcc-1.3.0-gcc/src/samples$</a>
sparc-gaisler-rtems5-gcc -dM -E empty.c -mcpu=leon |grep TN0018</tt><tt><br>
</tt><tt> <a class="moz-txt-link-abbreviated" href="mailto:daniel@daniel:/opt/rcc-1.3.0-gcc/src/samples$">daniel@daniel:/opt/rcc-1.3.0-gcc/src/samples$</a></tt><br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAF9ehCWBaeDmtU0AjuE_5thhZHR2KO_r80NG8LcqsrL66hs1+A@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>This general pattern has forced some files to migrate
from cpukit to libbsp/shared</div>
<div>and be built with the BSP. The SPARC interrupt processing
was moved during the </div>
<div>SMP development because it needed to know some
distinction not allowed in</div>
<div>the cpukit.</div>
<div><br>
</div>
<div>I don't like adding this as a -D on the compile like but
that doesn't leave a good</div>
<div>home. I sure don't want to add a bsp specific configure
option for something like</div>
<div>this. <br>
</div>
</div>
</div>
</blockquote>
<p>Ok, makes sense. See above suggestion.<br>
</p>
<p>/Daniel</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAF9ehCWBaeDmtU0AjuE_5thhZHR2KO_r80NG8LcqsrL66hs1+A@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>--joel</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<br>
_______________________________________________<br>
devel mailing list<br>
<a href="mailto:devel@rtems.org" target="_blank"
moz-do-not-send="true">devel@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/devel"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.rtems.org/mailman/listinfo/devel</a></blockquote>
</div>
</div>
</blockquote>
</body>
</html>