Re: [PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

2020-09-23 Thread Niteesh G. S. 
Hello,

On Sat, Sep 19, 2020 at 4:13 PM Christian Mauderer 
wrote:

> Hello Niteesh,
>
> sorry for adding another delay: I think the new build system needs a bit
> of time to settle. As soon as there are some more PASS in the table that
> Sebastian created [1] (especially for beagle) we should try to get these
> patches merged. Before that I would like to avoid big changes because it
> might get hard to distinguish new bugs from build system bugs.


No problem. Currently, I have my university exams going on and also I am
waiting for my logic analyzer. As soon as it arrives I'll start verifying
the previous
drivers and finish refactoring the other ones.

Thanks,
Niteesh.



>
> Best regards
>
> Christian
>
> [1] https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist
>
> On 16/09/2020 19:05, Niteesh G. S. wrote:
> > Hello,
> >
> > Sorry for the delay, I was a bit occupied with my university work.
> > Now since the new build system is merged I would like to get my
> > GSoC work merged too.
> >
> > The goal of this series patches is to implement the OFW API into RTEMS
> > and modify libBSD to use this RTEMS API instead of its own.
> >
> > Thanks,
> > Niteesh.
> >
> > On Wed, Sep 16, 2020 at 10:33 PM G S Niteesh Babu  > > wrote:
> >
> > RTEMS OFW is a FDT only implementation of the OpenFirmWare
> > interface. This API is created to be compatible with FreeBSD
> > OpenFirmWare interface. The main intention is to make
> > porting of FreeBSD drivers to RTEMS easier.
> >
> > Most functions implemented have an direct one-one mapping
> > with the original OFW API and some extra auxiliary functions
> > were implemented to make working with device trees easier in
> > RTEMS.
> >
> > Update #3784
> > ---
> >  bsps/include/ofw/ofw.h| 548 +++
> >  bsps/include/ofw/ofw_compat.h |  74 
> >  bsps/shared/ofw/ofw.c | 682
> ++
> >  spec/build/bsps/obj.yml   |   5 +
> >  4 files changed, 1309 insertions(+)
> >  create mode 100644 bsps/include/ofw/ofw.h
> >  create mode 100644 bsps/include/ofw/ofw_compat.h
> >  create mode 100644 bsps/shared/ofw/ofw.c
> >
> > diff --git a/bsps/include/ofw/ofw.h b/bsps/include/ofw/ofw.h
> > new file mode 100644
> > index 00..411010be89
> > --- /dev/null
> > +++ b/bsps/include/ofw/ofw.h
> > @@ -0,0 +1,548 @@
> > +/* SPDX-License-Identifier: BSD-2-Clause */
> > +
> > +/**
> > + * @file
> > + *
> > + * @ingroup ofw
> > + *
> > + * RTEMS FDT implementation of OpenFirmWare Interface.
> > + *
> > + * RTEMS OFW is a FDT only implementation of the OpenFirmWare
> > interface.
> > + * This API is created to be compatible with FreeBSD OpenFirmWare
> > interface.
> > + * The main intention is to make porting of FreeBSD drivers to
> > RTEMS easier.
> > + */
> > +
> > +/*
> > + * Copyright (C) 2020 Niteesh Babu G S  > >
> > + *
> > + * Redistribution and use in source and binary forms, with or
> without
> > + * modification, are permitted provided that the following
> conditions
> > + * are met:
> > + * 1. Redistributions of source code must retain the above copyright
> > + *notice, this list of conditions and the following disclaimer.
> > + * 2. Redistributions in binary form must reproduce the above
> copyright
> > + *notice, this list of conditions and the following disclaimer
> > in the
> > + *documentation and/or other materials provided with the
> > distribution.
> > + *
> > + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> > CONTRIBUTORS "AS IS"
> > + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> > LIMITED TO, THE
> > + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
> > PARTICULAR PURPOSE
> > + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> > CONTRIBUTORS BE
> > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
> OR
> > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
> PROCUREMENT OF
> > + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> > BUSINESS
> > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> > WHETHER IN
> > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> > OTHERWISE)
> > + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
> > ADVISED OF THE
> > + * POSSIBILITY OF SUCH DAMAGE.
> > + */
> > +
> > +#ifndef _OFW_H
> > +#define _OFW_H
> > +
> > +#ifdef __cplusplus
> > +extern "C" {
> > +#endif
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +/**
> > + * Represents a node in the device tree. The offset from fdtp to
> > node

running pc686 samples on QEMU on RTEMS 5.1?

2020-09-23 Thread Cudmore, Alan P. (GSFC-5820) 
NASA’s Core Flight System open source bundle has support for the RTEMS 4.11 
pc686 BSP.
RTEMS is built with the following options:
../rtems/configure --target=i386-rtems4.11 \
--enable-rtemsbsp=pc686 \
--prefix=${HOME}/rtems-4.11 \
--enable-networking \
--enable-cxx \
--disable-posix \
--disable-deprecated \
BSP_ENABLE_VGA=0 \
CLOCK_DRIVER_USE_TSC=1 \
USE_COM1_AS_CONSOLE=1 \
BSP_PRESS_KEY_FOR_RESET=0 \
BSP_RESET_BOARD_AT_EXIT=1

And the code (or samples such as ticker) are run with the following QEMU 
command:


qemu-system-i386 -m 128 \

-kernel core-cpu1.exe \

-drive file=fat:rw:${INSTALL_DIR}/cpu1,format=raw \

-nographic \

-no-reboot

(Where core-cpu1.exe is the cross compiled application. I can also run 
ticker.exe and other samples with this command )

When I build the pc686 BSP with the same examples and try running on QEMU with 
the same options, QEMU returns immediately.

Is there a different set of options I should use for the pc686 BSP on RTEMS 5.1?

Thanks,
Alan

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Need help debugging sp02.exe run on Strong APA scheduler

2020-09-23 Thread Joel Sherrill 
On Wed, Sep 23, 2020 at 11:54 AM Richi Dubey  wrote:

> Thanks for the advice.
>
> I feel something is going wrong when we're trying to delete a suspended
> task because maybe I'm not handling the suspension/deletion of tasks
> properly in my code. Do you think this might be true for my code
> 
> ?
>

That's a specific scheduler action and combination of object states. It is
quite possible something is not processed correctly by your scheduler.
Deleting a suspended thread would not require any actions on the Ready set
of threads, for example.

--joel



>
> On Wed, Sep 23, 2020 at 12:41 AM Joel Sherrill  wrote:
>
>> This isn't a proper solution but a debug technique. When stepping
>> and running result in different behavior, it is sometimes useful to
>> run to a specific point and look at data structures for anomalies.
>>
>> Since TA1 never prints, I wonder if something went wrong with the
>> data structures before INIT deletes itself at the bottom.
>>
>> --joel
>>
>>
>> On Tue, Sep 22, 2020 at 12:40 PM Richi Dubey 
>> wrote:
>>
>>> Hi,
>>>
>>> I've been trying to debug why sp02 keeps failing on Strong APA scheduler
>>> and it's hard for me to debug because there are different points at which
>>> the same program breaks on gdb even though this is a single processor test.
>>> I have attached the different error logs. In error.txt, we can see that the
>>> execution fails somewhere in _Context_Switch while it is not the case when
>>> I step inside in case II, and other random things like these keep
>>> happening. I'd appreciate it if you direct my thoughts.
>>>
>>> I'm testing the source over this
>>>  and
>>> this
>>> 
>>> patch.
>>>
>>> Thanks,
>>> Richi.
>>> ___
>>> devel mailing list
>>> devel@rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: running pc686 samples on QEMU on RTEMS 5.1?

2020-09-23 Thread Karel Gardas 
On 9/23/20 11:02 PM, Cudmore, Alan P. (GSFC-5820) wrote:
> NASA’s Core Flight System open source bundle has support for the RTEMS
> 4.11 pc686 BSP.
> 
> RTEMS is built with the following options:
> 
> ../rtems/configure --target=i386-rtems4.11 \
> 
>     --enable-rtemsbsp=pc686 \
> 
>     --prefix=${HOME}/rtems-4.11 \
> 
>     --enable-networking \
> 
>     --enable-cxx \
> 
>     --disable-posix \
> 
>     --disable-deprecated \
> 
>     BSP_ENABLE_VGA=0 \
>


^ don't do that. Last time I've checked this option was buggy, e.g.
reset BSP happen instantly.

>     CLOCK_DRIVER_USE_TSC=1 \
> 

^ do you need to do that? It's decided on runtime.

>     USE_COM1_AS_CONSOLE=1 \
> 

^ this option is long gone, hence without any effect, you can remove it.

>     BSP_PRESS_KEY_FOR_RESET=0 \
> 
>     BSP_RESET_BOARD_AT_EXIT=1   
> 

^ no needed as you are using their default values.

> And the code (or samples such as ticker) are run with the following QEMU
> command:
> 
>  
> 
> qemu-system-i386 -m 128 \
> 
> -kernel core-cpu1.exe \
> 
>     -drive file=fat:rw:${INSTALL_DIR}/cpu1,format=raw \
> 
>     -nographic \
> 
>     -no-reboot
> 

^ this looks fine, you can also try -append "--video=off
--console=/dev/com1" -- which would basically mean what you used to use
in 4.x with those BSP compile time options above. E.g. console on COM1.

But to have it working, you need to IIRC! remove disabling of VGA.

Please consult
https://docs.rtems.org/branches/master/user/bsps/bsps-i386.html#pc386 --
for more information.

Hope this helps,
Karel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Need help debugging sp02.exe run on Strong APA scheduler

2020-09-23 Thread Richi Dubey 
Thanks for the advice.

I feel something is going wrong when we're trying to delete a suspended
task because maybe I'm not handling the suspension/deletion of tasks
properly in my code. Do you think this might be true for my code

?

On Wed, Sep 23, 2020 at 12:41 AM Joel Sherrill  wrote:

> This isn't a proper solution but a debug technique. When stepping
> and running result in different behavior, it is sometimes useful to
> run to a specific point and look at data structures for anomalies.
>
> Since TA1 never prints, I wonder if something went wrong with the
> data structures before INIT deletes itself at the bottom.
>
> --joel
>
>
> On Tue, Sep 22, 2020 at 12:40 PM Richi Dubey  wrote:
>
>> Hi,
>>
>> I've been trying to debug why sp02 keeps failing on Strong APA scheduler
>> and it's hard for me to debug because there are different points at which
>> the same program breaks on gdb even though this is a single processor test.
>> I have attached the different error logs. In error.txt, we can see that the
>> execution fails somewhere in _Context_Switch while it is not the case when
>> I step inside in case II, and other random things like these keep
>> happening. I'd appreciate it if you direct my thoughts.
>>
>> I'm testing the source over this
>>  and
>> this 
>> patch.
>>
>> Thanks,
>> Richi.
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/3] grlib: Some clean ups

2020-09-23 Thread Joel Sherrill 
Any chance this might address any of the Coverity issues in the grlib code?

If so, it would be nice to apply this to the 5 branch.

On Wed, Sep 23, 2020 at 10:09 AM Daniel Hellstrom 
wrote:

> Hi Sebastian,
>
> The patch set looks good. Thanks!
>
> /Daniel
>
>On 2020-09-18 10:00, Sebastian Huber wrote:
>
> Sebastian Huber (3):
>   grlib: Remove superfluous forward decls
>   grlib: Remove unused conversion macros
>   grlib: Add ambapp_common_info to derived types
>
>  bsps/include/grlib/ambapp.h   | 48 ++-
>  bsps/shared/grlib/amba/ambapp.c   | 14 
>  bsps/shared/grlib/amba/ambapp_freq.c  |  2 +-
>  bsps/shared/grlib/ascs/grascs.c   |  2 +-
>  bsps/shared/grlib/can/satcan.c|  2 +-
>  bsps/shared/grlib/drvmgr/ambapp_bus.c | 20 +--
>  bsps/shared/grlib/pci/grpci.c |  2 +-
>  bsps/shared/grlib/pci/grpci2.c|  4 +--
>  bsps/shared/grlib/pci/pcif.c  |  2 +-
>  bsps/shared/grlib/slink/grslink.c |  2 +-
>  bsps/shared/grlib/spw/grspw_pkt.c |  2 +-
>  bsps/shared/grlib/stat/l4stat.c   |  2 +-
>  bsps/sparc/leon3/console/console.c|  2 +-
>  bsps/sparc/leon3/net/leon_open_eth.c  |  2 +-
>  14 files changed, 46 insertions(+), 60 deletions(-)
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/3] grlib: Some clean ups

2020-09-23 Thread Daniel Hellstrom 

Hi Sebastian,

The patch set looks good. Thanks!

/Daniel


  


On 2020-09-18 10:00, Sebastian Huber wrote:

Sebastian Huber (3):
   grlib: Remove superfluous forward decls
   grlib: Remove unused conversion macros
   grlib: Add ambapp_common_info to derived types

  bsps/include/grlib/ambapp.h   | 48 ++-
  bsps/shared/grlib/amba/ambapp.c   | 14 
  bsps/shared/grlib/amba/ambapp_freq.c  |  2 +-
  bsps/shared/grlib/ascs/grascs.c   |  2 +-
  bsps/shared/grlib/can/satcan.c|  2 +-
  bsps/shared/grlib/drvmgr/ambapp_bus.c | 20 +--
  bsps/shared/grlib/pci/grpci.c |  2 +-
  bsps/shared/grlib/pci/grpci2.c|  4 +--
  bsps/shared/grlib/pci/pcif.c  |  2 +-
  bsps/shared/grlib/slink/grslink.c |  2 +-
  bsps/shared/grlib/spw/grspw_pkt.c |  2 +-
  bsps/shared/grlib/stat/l4stat.c   |  2 +-
  bsps/sparc/leon3/console/console.c|  2 +-
  bsps/sparc/leon3/net/leon_open_eth.c  |  2 +-
  14 files changed, 46 insertions(+), 60 deletions(-)

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 00/26] leon: various fixes and TN0018 errata workaround

2020-09-23 Thread Gedare Bloom 
On Wed, Sep 23, 2020 at 4:34 AM Daniel Hellstrom  wrote:
>
> Hi Sebastian,
>
> Thanks for asking and sorry for dropping the ball on these.
>
> The status is that two needs updating (BSD license for new CAN files and
> the last tn0018 patch needs some redesign based on feedback) and the
> others are accepted for master. I've sent an response on the tn0018
> errata patch just now. I would like to push them on the 5 and master
> branches. To get them onto 5, should  I create a ticket for the whole
> patch set? I will try getting this done next next couple of days, and
> have a look at you patches too, thanks!
>

It would be good to separate them logically to the TN-0018 errata
fixes vs the CAN/grlib improvements. The concern for pushing them to 5
is that they touch core sparc files, but since you guys are releasing
them this way in RCC I'm also comfortable with it. I didn't see any
changes outside the sparc (since currently grlib is sparc-specific
too). We'll need those tickets to help us with the dot-release notes.

> Kind Regards,
> Daniel
>
> On 2020-09-18 10:03, Sebastian Huber wrote:
> > Hallo Daniel,
> >
> > what are your plans with respect to this patch set?
> >
> > Please also have a look at:
> >
> > https://lists.rtems.org/pipermail/devel/2020-September/062176.html
> >
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1] bsps/pc386: Add missing license header

2020-09-23 Thread Joel Sherrill 
I filed issues for the 5 branch and master and then pushed this.

Thanks for the patch.

--joel

On Wed, Sep 23, 2020 at 5:37 AM Jan Sommer  wrote:

> ---
>  bsps/i386/pc386/start/bspsmp.c | 26 ++
>  1 file changed, 26 insertions(+)
>
> diff --git a/bsps/i386/pc386/start/bspsmp.c
> b/bsps/i386/pc386/start/bspsmp.c
> index 026f86916fd..2e09b36a8a9 100644
> --- a/bsps/i386/pc386/start/bspsmp.c
> +++ b/bsps/i386/pc386/start/bspsmp.c
> @@ -1,3 +1,29 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/*
> + * Copyright (C) 2020 Jan Sommer, Deutsches Zentrum für Luft- und
> Raumfahrt e. V. (DLR)
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> "AS IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
> THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
> PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
> BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
> THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
>
>  #include 
>
> --
> 2.17.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v1] bsps/pc386: Add missing license header

2020-09-23 Thread Jan Sommer 
---
 bsps/i386/pc386/start/bspsmp.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/bsps/i386/pc386/start/bspsmp.c b/bsps/i386/pc386/start/bspsmp.c
index 026f86916fd..2e09b36a8a9 100644
--- a/bsps/i386/pc386/start/bspsmp.c
+++ b/bsps/i386/pc386/start/bspsmp.c
@@ -1,3 +1,29 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2020 Jan Sommer, Deutsches Zentrum für Luft- und Raumfahrt e. 
V. (DLR)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
 
 #include 
 
-- 
2.17.1

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 00/26] leon: various fixes and TN0018 errata workaround

2020-09-23 Thread Daniel Hellstrom 

Hi Sebastian,

Thanks for asking and sorry for dropping the ball on these.

The status is that two needs updating (BSD license for new CAN files and 
the last tn0018 patch needs some redesign based on feedback) and the 
others are accepted for master. I've sent an response on the tn0018 
errata patch just now. I would like to push them on the 5 and master 
branches. To get them onto 5, should  I create a ticket for the whole 
patch set? I will try getting this done next next couple of days, and 
have a look at you patches too, thanks!


Kind Regards,
Daniel

On 2020-09-18 10:03, Sebastian Huber wrote:

Hallo Daniel,

what are your plans with respect to this patch set?

Please also have a look at:

https://lists.rtems.org/pipermail/devel/2020-September/062176.html


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2020-09-23 Thread Daniel Hellstrom 

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

Re: libbsd master is broken with powerpc

2020-09-23 Thread Chris Johns 
On 23/9/20 4:15 pm, Sebastian Huber wrote:
> On 23/09/2020 07:11, Chris Johns wrote:
> 
>> Sorry for the noise. I pulled the wrong repo. Update the repo and it builds.
> 
> I worked on the libbsd build in the last days.

Yes and it was my mistake I had not updated the right repo.

> This is my final status:
> 
> https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist
> 
> What we need now are test runs with build done by the new build system.
> 

Yes. I am playing with the pc686 at the moment to get to that point.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: libbsd master is broken with powerpc

2020-09-23 Thread Sebastian Huber 

On 23/09/2020 07:11, Chris Johns wrote:


Sorry for the noise. I pulled the wrong repo. Update the repo and it builds.


I worked on the libbsd build in the last days. This is my final status:

https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist

What we need now are test runs with build done by the new build system.

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel