Re: [PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

2020-06-03 Thread Chris Johns 
On 4/6/20 3:22 pm, Sebastian Huber wrote:
> This approach avoids the need to actively register a device tree. This could
> simplify the low level startup a bit. The draw back is that it needs a special
> feature of the linker for the tests.

But we already use this feature and need it for the tests to link so does it
matter if it is used here?

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

Re: [PATCH 2/2] Adding strong and weak definitions

2020-06-03 Thread Sebastian Huber 

On 02/06/2020 15:52, Richi Dubey wrote:


---
  user/glossary/index.rst | 15 +++
  1 file changed, 15 insertions(+)

diff --git a/user/glossary/index.rst b/user/glossary/index.rst
index 5648b39..2ae0fdf 100644
--- a/user/glossary/index.rst
+++ b/user/glossary/index.rst
@@ -16,6 +16,21 @@ Glossary
  
APA

  Arbitrary Processor Affinity
+
+Weak APA: Invariant for this model states that for any backlogged 
task(task not


Space before (.

We should use the term "thread" in general definitions in favour of "task".

I think "backlogged thread" should be new term.

The terms "weak APA" and "strong APA" should be individual items. The 
term "APA" should give references to the specializations.


The glossary is generated from specification items:

https://git.rtems.org/sebh/rtems-qual.git/tree/spec/glos/term

I will work on a documentation how this works in the next days.


+yet assigned a processor), all the processors in its affinity mask are
+occupied by higher-priority tasks. That is, there is no candidate
+task for preemption scheduled on any of the processors(in a backlogged
+task's affinity mask) on which the backlogged task may execute. Linux's
+push-pull scheduling is an example of weak-APA scheduling.

"weak APA" vs. "weak-APA"

+
+Strong APA: In this model, on the arrival of a task, every task reachable
+from the newly arrived task is checked to see if an existing task can
+be shifted(or deallocated its processor) and newly arrived task can take
+its place if the newly arrived task has a higher priority. Similar 
analysis is
+done when a task finishes its execution.
+
+Learn more at: https://people.mpi-sws.org/~bbb/papers/talks/rtss14f.pdf


We already have a bibtex entry for this:

common/refs.bib-@inproceedings{Cerqueira:2014:LPA,
common/refs.bib-  author    = {Cerqueira, Felipe and Gujarati, Arpan and 
Brandenburg, Björn B.},
common/refs.bib-  title = {{Linux’s Processor Affinity API, Refined: 
Shifting Real-Time Tasks towards Higher Schedulability}},
common/refs.bib-  booktitle = {Proceedings of the 35th IEEE Real-Time 
Systems Symposium (RTSS 2014)},

common/refs.bib-  year  = {2014},
common/refs.bib:  url   = 
{http://www.mpi-sws.org/~bbb/papers/pdf/rtss14f.pdf},

common/refs.bib-}

Please use :cite:`Cerqueira:2014:LPA`.

  
API

  Application Programming Interface

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

Re: [PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

2020-06-03 Thread Sebastian Huber 

On 01/06/2020 20:55, Niteesh G. S. wrote:

On Fri, May 29, 2020 at 6:49 PM Sebastian Huber 
> wrote:


On 29/05/2020 12:41, Niteesh G. S. wrote:

Hello Sebastian,

> Hello,
>
> On Fri, May 29, 2020 at 12:52 PM Sebastian Huber
> mailto:sebastian.hu...@embedded-brains.de>
> >> wrote:
>
>     Hello,
>
>     since this code is not BSP-specific it should be located in
>     cpukit. How
>     many FreeBSD source files do you intend to import within
this project?
>
>
> This code depends on a bsp that has FDT support. We first
imported it to
> cpukit but then decided to move it to bsps/shared since we
weren't able to
> import BSP related files (bsp/fdt.h in this case) from cpukit.

Please think about how BSP dependencies can be avoided since this
will
also allow us to write unit tests for this infrastructure. One
option is
to add an API to register the device tree. BSPs which have a
device tree
do this before the API is used. Unit tests override the device
tree to
run the test cases.

From what I understood, the API will have the responsibility to 
provide all objects
which will be used by the FreeBSD source. In the current case, it is 
the DTB.
During testing, we override the DTB that will be supplied by the BSP 
with a custom

one like the one in libfdt test. Please correct if I misunderstood it.

Can you please provide some pointers on how to implement one? Or 
please point

to sources of something similar if available.

I can think of a really simple design where the API holds a reference 
to the FDT blob
which it gets through the register function. Under normal operation, 
the BSP will register
the FDT during start up. And while testing just the before running the 
test we can override
the FDT reference by again registering with a custom FDT blob. But I 
don't think this
would scale well in the future. So, please mention about the design 
and implementation

of the API.


I think your proposed approach is fine in general.

The goal should be to move this stuff to cpukit and add tests for it to 
the standard test suite (for example testsuites/libtests/devicetree*).


An alternative to registering a pointer would be to define a provider 
function (currently this is bsp_fdt_get()). Tests can use a wrapper 
function with support from the linker:


const void *test_device_tree;

const void *__wrap_bsp_fdt_get(void)

{

    if (test_device_tree != NULL) {

        return test_device_tree;

    }

    return __real_bsp_fdt_get();

}

This approach avoids the need to actively register a device tree. This 
could simplify the low level startup a bit. The draw back is that it 
needs a special feature of the linker for the tests.


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

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-03 Thread Chris Johns 
On 4/6/20 2:31 pm, Gedare Bloom wrote:
> On Wed, Jun 3, 2020 at 1:53 PM Mritunjay Sharma
>  wrote:
>>
>> Hello everyone,
>>
>> As suggested by Heinz, I started building for xilinx_zynq_a9_qemu
>> with a little modification in ptp cfg file.
>>
>> The netinet is no longer a problem here but another problem has come as 
>> follows:
>>
>> ../../ptpd-2.3.1/src/dep/startup.c: In function 'ptpdStartup':

Is this from sourceforge?

How does the ptpd-2.3.1 source code relate to the github repo
https://github.com/ptpd/ptpd ?

I have been referencing the github repo.

>> ../../ptpd-2.3.1/src/dep/startup.c:948:29: error: 'CPU_LEVEL_WHICH' 
>> undeclared (first use in this function)
>>if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
>>  ^~~
>> ../../ptpd-2.3.1/src/dep/startup.c:948:46: error: 'CPU_WHICH_PID' undeclared 
>> (first use in this function)
>>if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
>>   ^
> 
> These are from BSD. This probably needs to be compiled with libbsd
> somehow? or picking up its header files...

In the github version this code is conditional on sys/cpuset.h being present.

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

Re: GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-03 Thread Gedare Bloom 
On Wed, Jun 3, 2020 at 1:53 PM Mritunjay Sharma
 wrote:
>
> Hello everyone,
>
> As suggested by Heinz, I started building for xilinx_zynq_a9_qemu
> with a little modification in ptp cfg file.
>
> The netinet is no longer a problem here but another problem has come as 
> follows:
>
> ../../ptpd-2.3.1/src/dep/startup.c: In function 'ptpdStartup':
> ../../ptpd-2.3.1/src/dep/startup.c:948:29: error: 'CPU_LEVEL_WHICH' 
> undeclared (first use in this function)
>if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
>  ^~~
> ../../ptpd-2.3.1/src/dep/startup.c:948:46: error: 'CPU_WHICH_PID' undeclared 
> (first use in this function)
>if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
>   ^

These are from BSD. This probably needs to be compiled with libbsd
somehow? or picking up its header files...

> Makefile:629: recipe for target 'dep/startup.o' failed
> make[2]: Leaving directory 
> '/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-arm-rtems5-1/build-cxc/src'
> make[2]: *** [dep/startup.o] Error 1
> Makefile:502: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory 
> '/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-arm-rtems5-1/build-cxc'
> Makefile:412: recipe for target 'all' failed
> make: *** [all] Error 2
> shell cmd failed: /bin/sh -ex  
> /home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-arm-rtems5-1/do-build
> error: building ptpd-2.3.1-arm-rtems5-1
>   See error report: rsb-report-ptpd-2.3.1-arm-rtems5-1.txt
> Build Set: Time 0:00:21.081476
>
> I am also attaching the log file and trace report.
>
> Thanks,
> Mritunjay
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/5] bsps/shared/freebsd: Import OFW files from FreeBSD.

2020-06-03 Thread Niteesh G. S. 
Hello,

This email is a reminder since this thread has lost activity.

Thanks,
Niteesh.

On Tue, Jun 2, 2020 at 12:25 AM Niteesh G. S.  wrote:

> On Fri, May 29, 2020 at 6:49 PM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 29/05/2020 12:41, Niteesh G. S. wrote:
>>
> Hello Sebastian,
>
>> > Hello,
>> >
>> > On Fri, May 29, 2020 at 12:52 PM Sebastian Huber
>> > > > > wrote:
>> >
>> > Hello,
>> >
>> > since this code is not BSP-specific it should be located in
>> > cpukit. How
>> > many FreeBSD source files do you intend to import within this
>> project?
>> >
>> >
>> > This code depends on a bsp that has FDT support. We first imported it to
>> > cpukit but then decided to move it to bsps/shared since we weren't able
>> to
>> > import BSP related files (bsp/fdt.h in this case) from cpukit.
>>
>> Please think about how BSP dependencies can be avoided since this will
>> also allow us to write unit tests for this infrastructure. One option is
>> to add an API to register the device tree. BSPs which have a device tree
>> do this before the API is used. Unit tests override the device tree to
>> run the test cases.
>
>
> From what I understood, the API will have the responsibility to provide
> all objects
> which will be used by the FreeBSD source. In the current case, it is the
> DTB.
> During testing, we override the DTB that will be supplied by the BSP with
> a custom
> one like the one in libfdt test. Please correct if I misunderstood it.
>
> Can you please provide some pointers on how to implement one? Or please
> point
> to sources of something similar if available.
>
> I can think of a really simple design where the API holds a reference to
> the FDT blob
> which it gets through the register function. Under normal operation, the
> BSP will register
> the FDT during start up. And while testing just the before running the
> test we can override
> the FDT reference by again registering with a custom FDT blob. But I don't
> think this
> would scale well in the future. So, please mention about the design and
> implementation
> of the API.
>
> Thanks,
> Niteesh.
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Fwd: Build Linux: FAILED 5/bsps/pc on x86_64-linux-gnu (i386-rtems5-kernel-pc686-1)

2020-06-03 Thread Chris Johns 
On 4/6/20 12:45 pm, Chris Johns wrote:
> On 29/5/20 9:49 am, Joel Sherrill wrote:
>> On Thu, May 28, 2020, 6:20 PM Chris Johns > > wrote:
>>
>> On 29/5/20 7:08 am, Joel Sherrill wrote:
>> > On Thu, May 28, 2020 at 12:54 PM Sebastian Huber
>> > > 
>> > > >> wrote:
>> >
>> >     On 28/05/2020 18:43, Joel Sherrill wrote:
>> >
>> >      > I just did pc on the master and it failed for me.
>> >
>> >     Works for me:
>> >
>> >     installing: 5/bsps/pc -> /build/rtems/5
>> >     Staging Size: 1.385GB
>> >     Build Set: Time 0:25:50.735059
>> > Weird.
>> >
>> > I see the problem. If the prefix is somewhere new and clean, it works
>> > fine. If I keep using the same directory where I previously installed
>> > tools, it fails.
>> >
>> > Wonder what Chris can say about this?
>> >
>>
>> I suggest taking a look at the logs in detail to see what is happening
>>
>>
>> Thanks but I have done that to the mailing list and to a ticket. The probe 
>> for
>> gethostbyname fails 
>>
> 
> Oh ok, sorry about that. I had not made the connection between the postings
> until just now. I am taking a look.

I ran a build of a new release snapshot I am testing 

https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2006-1/

... and built the pc BSP twice using the same prefix on Ubuntu without error.

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

Re: Fwd: Build Linux: FAILED 5/bsps/pc on x86_64-linux-gnu (i386-rtems5-kernel-pc686-1)

2020-06-03 Thread Chris Johns 
On 29/5/20 9:49 am, Joel Sherrill wrote:
> On Thu, May 28, 2020, 6:20 PM Chris Johns  > wrote:
> 
> On 29/5/20 7:08 am, Joel Sherrill wrote:
> > On Thu, May 28, 2020 at 12:54 PM Sebastian Huber
> >  
> >  >> wrote:
> >
> >     On 28/05/2020 18:43, Joel Sherrill wrote:
> >
> >      > I just did pc on the master and it failed for me.
> >
> >     Works for me:
> >
> >     installing: 5/bsps/pc -> /build/rtems/5
> >     Staging Size: 1.385GB
> >     Build Set: Time 0:25:50.735059
> > Weird.
> >
> > I see the problem. If the prefix is somewhere new and clean, it works
> > fine. If I keep using the same directory where I previously installed
> > tools, it fails.
> >
> > Wonder what Chris can say about this?
> >
> 
> I suggest taking a look at the logs in detail to see what is happening
> 
> 
> Thanks but I have done that to the mailing list and to a ticket. The probe for
> gethostbyname fails 
> 

Oh ok, sorry about that. I had not made the connection between the postings
until just now. I am taking a look.

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

rtems source with build html doxygen output

2020-06-03 Thread Chris Johns 
Hi,

In fixing the doxygen support I accidentally have the doxygen built HTML output
in the source tar file. As this link shows it is 28M ...

https://ftp.rtems.org/pub/rtems/releases/5/5.0.0/5.0.0-m2006-1/sources/

I like the idea of this being there. What do you think?

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

Re: [PATCH] SPARC fenv support

2020-06-03 Thread Joel Sherrill 
This looks great. By chat, you confirmed, you did the
multilib compile and link spot check plus it the psxfenv
test runs on erc32. Go ahead and submit this to newlib@.

The code has ifdefs for 64-bits. RTEMS has sparc64 support so
it would be straight forward to follow the x86_64 and i386 pattern
to add support for sparc64 right after it is merged.

NOTE: We do not have anyway to execute sparc64 code AFAIK so
this would be just the multilib compile and link test portion.

Great job!

--joel

On Wed, Jun 3, 2020 at 5:22 PM Eshan dhawan  wrote:

> Signed-off-by: Eshan dhawan 
> ---
>  newlib/configure.host   |   1 +
>  newlib/libc/machine/sparc/sys/fenv.h|  85 +
>  newlib/libm/machine/configure.in|   1 +
>  newlib/libm/machine/sparc/Makefile.am   |  21 ++
>  newlib/libm/machine/sparc/configure.in  |  11 +
>  newlib/libm/machine/sparc/feclearexcept.c   |   7 +
>  newlib/libm/machine/sparc/fegetenv.c|   7 +
>  newlib/libm/machine/sparc/fegetexceptflag.c |   7 +
>  newlib/libm/machine/sparc/fegetround.c  |   7 +
>  newlib/libm/machine/sparc/feholdexcept.c|   7 +
>  newlib/libm/machine/sparc/fenv.c| 350 
>  newlib/libm/machine/sparc/feraiseexcept.c   |   7 +
>  newlib/libm/machine/sparc/fesetenv.c|   7 +
>  newlib/libm/machine/sparc/fesetexceptflag.c |   7 +
>  newlib/libm/machine/sparc/fesetround.c  |   7 +
>  newlib/libm/machine/sparc/fetestexcept.c|   7 +
>  newlib/libm/machine/sparc/feupdateenv.c |   7 +
>  17 files changed, 546 insertions(+)
>  create mode 100644 newlib/libc/machine/sparc/sys/fenv.h
>  create mode 100644 newlib/libm/machine/sparc/Makefile.am
>  create mode 100644 newlib/libm/machine/sparc/configure.in
>  create mode 100644 newlib/libm/machine/sparc/feclearexcept.c
>  create mode 100644 newlib/libm/machine/sparc/fegetenv.c
>  create mode 100644 newlib/libm/machine/sparc/fegetexceptflag.c
>  create mode 100644 newlib/libm/machine/sparc/fegetround.c
>  create mode 100644 newlib/libm/machine/sparc/feholdexcept.c
>  create mode 100644 newlib/libm/machine/sparc/fenv.c
>  create mode 100644 newlib/libm/machine/sparc/feraiseexcept.c
>  create mode 100644 newlib/libm/machine/sparc/fesetenv.c
>  create mode 100644 newlib/libm/machine/sparc/fesetexceptflag.c
>  create mode 100644 newlib/libm/machine/sparc/fesetround.c
>  create mode 100644 newlib/libm/machine/sparc/fetestexcept.c
>  create mode 100644 newlib/libm/machine/sparc/feupdateenv.c
>
> diff --git a/newlib/configure.host b/newlib/configure.host
> index a84c0c80a..f31f8bd1a 100644
> --- a/newlib/configure.host
> +++ b/newlib/configure.host
> @@ -321,6 +321,7 @@ case "${host_cpu}" in
> machine_dir=sh
> ;;
>sparc*)
> +   libm_machine_dir=sparc
> machine_dir=sparc
> # FIXME: Might wish to make MALLOC_ALIGNMENT more generic.
> newlib_cflags="${newlib_cflags} -DMALLOC_ALIGNMENT=8"
> diff --git a/newlib/libc/machine/sparc/sys/fenv.h
> b/newlib/libc/machine/sparc/sys/fenv.h
> new file mode 100644
> index 0..0d8fb13ea
> --- /dev/null
> +++ b/newlib/libc/machine/sparc/sys/fenv.h
> @@ -0,0 +1,85 @@
> +/* $NetBSD: fenv.h,v 1.2 2017/01/14 12:00:13 martin Exp $  */
> +
> +/*-
> + * Copyright (c) 2004-2005 David Schultz 
> + * All rights reserved.
> + *
> + * 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 AUTHOR 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 AUTHOR 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.
> + *
> + * $FreeBSD$
> + */
> +
> +#ifndef_SYS_FENV_H_
> +#define_SYS_FENV_H_
> +
> +#include 
> +
> +#ifdef __arch64__
> +typedefuint64_tfenv_t;
> +typedefuint64_tfexcept_t;
> +#else
> +typedefuint32_tfenv_t;
> +typedefuint32_t

[PATCH] SPARC fenv support

2020-06-03 Thread Eshan dhawan 
Signed-off-by: Eshan dhawan 
---
 newlib/configure.host   |   1 +
 newlib/libc/machine/sparc/sys/fenv.h|  85 +
 newlib/libm/machine/configure.in|   1 +
 newlib/libm/machine/sparc/Makefile.am   |  21 ++
 newlib/libm/machine/sparc/configure.in  |  11 +
 newlib/libm/machine/sparc/feclearexcept.c   |   7 +
 newlib/libm/machine/sparc/fegetenv.c|   7 +
 newlib/libm/machine/sparc/fegetexceptflag.c |   7 +
 newlib/libm/machine/sparc/fegetround.c  |   7 +
 newlib/libm/machine/sparc/feholdexcept.c|   7 +
 newlib/libm/machine/sparc/fenv.c| 350 
 newlib/libm/machine/sparc/feraiseexcept.c   |   7 +
 newlib/libm/machine/sparc/fesetenv.c|   7 +
 newlib/libm/machine/sparc/fesetexceptflag.c |   7 +
 newlib/libm/machine/sparc/fesetround.c  |   7 +
 newlib/libm/machine/sparc/fetestexcept.c|   7 +
 newlib/libm/machine/sparc/feupdateenv.c |   7 +
 17 files changed, 546 insertions(+)
 create mode 100644 newlib/libc/machine/sparc/sys/fenv.h
 create mode 100644 newlib/libm/machine/sparc/Makefile.am
 create mode 100644 newlib/libm/machine/sparc/configure.in
 create mode 100644 newlib/libm/machine/sparc/feclearexcept.c
 create mode 100644 newlib/libm/machine/sparc/fegetenv.c
 create mode 100644 newlib/libm/machine/sparc/fegetexceptflag.c
 create mode 100644 newlib/libm/machine/sparc/fegetround.c
 create mode 100644 newlib/libm/machine/sparc/feholdexcept.c
 create mode 100644 newlib/libm/machine/sparc/fenv.c
 create mode 100644 newlib/libm/machine/sparc/feraiseexcept.c
 create mode 100644 newlib/libm/machine/sparc/fesetenv.c
 create mode 100644 newlib/libm/machine/sparc/fesetexceptflag.c
 create mode 100644 newlib/libm/machine/sparc/fesetround.c
 create mode 100644 newlib/libm/machine/sparc/fetestexcept.c
 create mode 100644 newlib/libm/machine/sparc/feupdateenv.c

diff --git a/newlib/configure.host b/newlib/configure.host
index a84c0c80a..f31f8bd1a 100644
--- a/newlib/configure.host
+++ b/newlib/configure.host
@@ -321,6 +321,7 @@ case "${host_cpu}" in
machine_dir=sh
;;
   sparc*)
+   libm_machine_dir=sparc
machine_dir=sparc
# FIXME: Might wish to make MALLOC_ALIGNMENT more generic.
newlib_cflags="${newlib_cflags} -DMALLOC_ALIGNMENT=8"
diff --git a/newlib/libc/machine/sparc/sys/fenv.h 
b/newlib/libc/machine/sparc/sys/fenv.h
new file mode 100644
index 0..0d8fb13ea
--- /dev/null
+++ b/newlib/libc/machine/sparc/sys/fenv.h
@@ -0,0 +1,85 @@
+/* $NetBSD: fenv.h,v 1.2 2017/01/14 12:00:13 martin Exp $  */
+
+/*-
+ * Copyright (c) 2004-2005 David Schultz 
+ * All rights reserved.
+ *
+ * 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 AUTHOR 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 AUTHOR 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.
+ *
+ * $FreeBSD$
+ */
+
+#ifndef_SYS_FENV_H_
+#define_SYS_FENV_H_
+
+#include 
+
+#ifdef __arch64__
+typedefuint64_tfenv_t;
+typedefuint64_tfexcept_t;
+#else
+typedefuint32_tfenv_t;
+typedefuint32_tfexcept_t;
+#endif
+
+/*
+ * Exception flags
+ *
+ * Symbols are defined in such a way, to correspond to the accrued
+ * exception bits (aexc) fields of FSR.
+ */
+#defineFE_INEXACT  0x0020  /* 10 */
+#defineFE_DIVBYZERO0x0040  /* 000100 */
+#defineFE_UNDERFLOW0x0080  /* 001000 */
+#defineFE_OVERFLOW 0x0100  /* 01 */
+#defineFE_INVALID  0x0200  /* 10 */
+
+#defineFE_ALL_EXCEPT   (FE_DIVBYZERO | FE_INEXACT | \
+FE_INVALID | FE_OVERFLOW | FE_UNDERFLOW)
+
+/*
+ * Rounding modes
+ *
+ * We can't just use the hardware bit values here, because that would
+ * make FE_UPWARD and FE_DOWNWARD negative,

GSoC 2020: [rtems/rsb]: Error while adding ptp support. This time building for xilinx_zynq_a9_qemu

2020-06-03 Thread Mritunjay Sharma 
Hello everyone,

As suggested by Heinz, I started building for xilinx_zynq_a9_qemu
with a little modification in ptp cfg file.

The netinet is no longer a problem here but another problem has come as
follows:

../../ptpd-2.3.1/src/dep/startup.c: In function 'ptpdStartup':
../../ptpd-2.3.1/src/dep/startup.c:948:29: error: 'CPU_LEVEL_WHICH'
undeclared (first use in this function)
   if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
 ^~~
../../ptpd-2.3.1/src/dep/startup.c:948:46: error: 'CPU_WHICH_PID'
undeclared (first use in this function)
   if(cpuset_setaffinity(CPU_LEVEL_WHICH, CPU_WHICH_PID,
  ^
Makefile:629: recipe for target 'dep/startup.o' failed
make[2]: Leaving directory
'/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-arm-rtems5-1/build-cxc/src'
make[2]: *** [dep/startup.o] Error 1
Makefile:502: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
'/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-arm-rtems5-1/build-cxc'
Makefile:412: recipe for target 'all' failed
make: *** [all] Error 2
shell cmd failed: /bin/sh -ex
 
/home/mritunjay/development/rtems/rsb/rtems/build/ptpd-2.3.1-arm-rtems5-1/do-build
error: building ptpd-2.3.1-arm-rtems5-1
  See error report: rsb-report-ptpd-2.3.1-arm-rtems5-1.txt
Build Set: Time 0:00:21.081476

I am also attaching the log file and trace report.

Thanks,
Mritunjay
RTEMS Tools Project - Source Builder Error Report
 Build: error: building ptpd-2.3.1-arm-rtems5-1
 Command Line: ../source-builder/sb-set-builder --log=log 
--prefix=/home/mritunjay/development/rtems/5 
--with-tools=/home/mritunjay/development/rtems/5 --host=arm-rtems5 
--with-rtems-bsp=xilinx_zynq_a9_qemu net/ptpd
 Python: 2.7.17 (default, Apr 15 2020, 17:20:14) [GCC 7.5.0]
 
git://git.rtems.org/rtems-source-builder.git/origin/855818015a378a8333754625296f3b15ce52aadd-modified
 Linux mritunjay-XPS-15-9570 5.3.0-51-generic #44~18.04.2-Ubuntu SMP Thu Apr 23 
14:27:18 UTC 2020 x86_64
Tail of the build log:
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for gawk... (cached) mawk
checking for arm-rtems5-gcc... arm-rtems5-gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... yes
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether arm-rtems5-gcc accepts -g... yes
checking for arm-rtems5-gcc option to accept ISO C89... none needed
checking whether arm-rtems5-gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of arm-rtems5-gcc... gcc3
checking for arm-rtems5-gcc option to accept ISO C99... none needed
checking build system type... x86_64-unknown-linux-gnu
checking host system type... arm-unknown-rtems5
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by arm-rtems5-gcc... 
/home/mritunjay/development/rtems/5/arm-rtems5/bin/ld
checking if the linker (/home/mritunjay/development/rtems/5/arm-rtems5/bin/ld) 
is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... 
/home/mritunjay/development/rtems/5/bin/arm-rtems5-nm -B
checking the name lister (/home/mritunjay/development/rtems/5/bin/arm-rtems5-nm 
-B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to 
arm-unknown-rtems5 format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain 
format... func_convert_file_noop
checking for /home/mritunjay/development/rtems/5/arm-rtems5/bin/ld option to 
reload object files... -r
checking for arm-rtems5-objdump... arm-rtems5-objdump
checking how to recognize dependent libraries... unknown
checking for arm-rtems5-dlltool... no
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for arm-rtems5-ar... arm-rtems5-ar
checking for archiver @FILE support... @
checking for arm-rtems5-strip... (cached) arm-rtems5-strip
checking for arm-rtems5-ranlib... arm-rtems5-ranlib
checking command to parse /home/mritunjay/development/rtems/5/bin/arm-rtems5-nm 
-B output from arm-rtems5-gcc object... failed
checking for sysroot... no
checking for arm-rtems5-mt... no
checking for mt... mt

RE: libbsd fails to build on master for i386

2020-06-03 Thread Jan.Sommer 
Hi Jeff,

yes, this is known, but IIRC the libbsd should build, if you turn off the e1000 
module in the buildset.
We prepared the iflib patchset for the FreeBSD branch first, because of the 
upcoming release.
There is also one in preparation for master, but got delayed since I wanted to 
finish the SMP patches for RTEMS 5.1 first.

Cheers,

   Jan

From: devel [mailto:devel-boun...@rtems.org] On Behalf Of Jeff Mayes
Sent: Wednesday, June 3, 2020 7:16 PM
To: 'devel@rtems.org'
Subject: libbsd fails to build on master for i386

Hi
On i386, the libbsd build (actually linking) fails on master branch.  FWIW, it 
succeeds on the FreeBSD branch.  Output below...

Thanks
Jeff

...
...
/home/mayes/dev/rtems/5/lib/gcc/i386-rtems5/7.5.0/../../../../i386-rtems5/bin/ld:
 ./libbsd.a(if_em.c.18.o):(.rodata.em_methods+0x2c): undefined reference to 
`iflib_device_suspend'
/home/mayes/dev/rtems/5/lib/gcc/i386-rtems5/7.5.0/../../../../i386-rtems5/bin/ld:
 ./libbsd.a(if_em.c.18.o):(.rodata.em_methods+0x34): undefined reference to 
`iflib_device_resume'
/home/mayes/dev/rtems/5/lib/gcc/i386-rtems5/7.5.0/../../../../i386-rtems5/bin/ld:
 ./libbsd.a(igb_txrx.c.18.o): in function `igb_isc_rxd_pkt_get':
/home/mayes/dev/rtems-libbsd/build/i386-rtems5-pc386-default/../../freebsd/sys/dev/e1000/igb_txrx.c:433:
 undefined reference to `iflib_get_ifp'
collect2: error: ld returned 1 exit status

Waf: Leaving directory 
`/home/mayes/dev/rtems-libbsd/build/i386-rtems5-pc386-default'
Build failed
-> task in 'arphole.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'lagg01.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'ping01.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'evdev01.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'pf01.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'pf02.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'dhcpcd02.exe' failed with exit status 1 (run with -v to display 
more information)
-> task in 'media01.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'dhcpcd01.exe' failed with exit status 1 (run with -v to display 
more information)
-> task in 'nfs01.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'foobarclient.exe' failed with exit status 1 (run with -v to display 
more information)
-> task in 'ppp01.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'foobarserver.exe' failed with exit status 1 (run with -v to display 
more information)
-> task in 'ftpd01.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'rcconf02.exe' failed with exit status 1 (run with -v to display 
more information)

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

libbsd fails to build on PowerPC

2020-06-03 Thread Jeff Mayes 
Hi,
libbsd fails to build on PowerPC on both the master branch and the FreeBSD 
branch.  Output below...

Thanks
Jeff

...
...
[1207/1970] Compiling rtemsbsd/rtems/rtems-bsd-rc-conf-net.c
[1208/1970] Compiling freebsd/sys/crypto/blowfish/bf_ecb.c
In file included from 
/home/mayes/dev/rtems-powerpc/powerpc-rtems5/psim/lib/include/bsp.h:59:0,
 from ../../freebsd/sys/arm/ti/ti_cpuid.h:35,
 from ../../freebsd/sys/arm/ti/ti_scm.c:74:
/home/mayes/dev/rtems-powerpc/powerpc-rtems5/psim/lib/include/libcpu/io.h:53:20:
 error: redefinition of 'eieio'
static inline void eieio(void)
^
In file included from ../../freebsd/sys/sys/systm.h:45:0,
 from ../../freebsd/sys/arm/ti/ti_scm.c:56:
../../freebsd/sys/powerpc/include/machine/cpufunc.h:168:1: note: previous 
definition of 'eieio' was here
eieio(void)
^

Waf: Leaving directory 
`/home/mayes/dev/rtems-libbsd/build/powerpc-rtems5-psim-default'
Build failed
-> task in 'bsd' failed with exit status 1 (run with -v to display more 
information)

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

libbsd fails to build on master for i386

2020-06-03 Thread Jeff Mayes 
Hi
On i386, the libbsd build (actually linking) fails on master branch.  FWIW, it 
succeeds on the FreeBSD branch.  Output below...

Thanks
Jeff

...
...
/home/mayes/dev/rtems/5/lib/gcc/i386-rtems5/7.5.0/../../../../i386-rtems5/bin/ld:
 ./libbsd.a(if_em.c.18.o):(.rodata.em_methods+0x2c): undefined reference to 
`iflib_device_suspend'
/home/mayes/dev/rtems/5/lib/gcc/i386-rtems5/7.5.0/../../../../i386-rtems5/bin/ld:
 ./libbsd.a(if_em.c.18.o):(.rodata.em_methods+0x34): undefined reference to 
`iflib_device_resume'
/home/mayes/dev/rtems/5/lib/gcc/i386-rtems5/7.5.0/../../../../i386-rtems5/bin/ld:
 ./libbsd.a(igb_txrx.c.18.o): in function `igb_isc_rxd_pkt_get':
/home/mayes/dev/rtems-libbsd/build/i386-rtems5-pc386-default/../../freebsd/sys/dev/e1000/igb_txrx.c:433:
 undefined reference to `iflib_get_ifp'
collect2: error: ld returned 1 exit status

Waf: Leaving directory 
`/home/mayes/dev/rtems-libbsd/build/i386-rtems5-pc386-default'
Build failed
-> task in 'arphole.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'lagg01.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'ping01.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'evdev01.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'pf01.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'pf02.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'dhcpcd02.exe' failed with exit status 1 (run with -v to display 
more information)
-> task in 'media01.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'dhcpcd01.exe' failed with exit status 1 (run with -v to display 
more information)
-> task in 'nfs01.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'foobarclient.exe' failed with exit status 1 (run with -v to display 
more information)
-> task in 'ppp01.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'foobarserver.exe' failed with exit status 1 (run with -v to display 
more information)
-> task in 'ftpd01.exe' failed with exit status 1 (run with -v to display more 
information)
-> task in 'rcconf02.exe' failed with exit status 1 (run with -v to display 
more information)

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