Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 24/02/2020 06:57, Vijay Kumar Banerjee wrote:
> 
> 
> On Sun, Feb 23, 2020 at 11:46 PM Alan Cudmore  > wrote:
> 
> Hi Christian,
> Thanks for the quick response. I followed the instructions in the
> docs.rtems.org  manual and generated the dtb
> from the FreeBSD commit
> that Vijay suggested. It still resulted in an exception in the same
> function.
> 
> Do you know if a specific commit of rtems-libbsd is required to work
> with that dtb?
> I tried master, and then the "5-freebsd-12" branch.
> 
> Thanks,
> Alan
> 
> Hi Alan,
> 
> I checked with the usb01 and ping01 tests running on libbsd master
> and the dtb from the commit mentioned by Christian. I can't reproduce
> the error and it seems to run as expected. I'm not sure where the
> error might be coming from. Below I'm pasting the contents of my uEnv.txt
> If the error isn't in the uEnv, I can send you my sd card image(offlist)
> so that you
> can try that on your board and that might give some hint on what was going
> wrong.
> 
> ```
> setenv bootdelay 5
> uenvcmd=run boot
> boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0 0x8800
> am335x-boneblack.dtb ; fdt addr 0x8800; bootm 0x8080 - 0x8800
> ```
> 
> Best regards,
> Vijay

Hello Alan,

another point: You know that your exception is in fdt_ro_probe_. So I
assume you have a debugger connected? Can you post a full backtrace so
that we can see from which driver the exception comes from?

Best regards

Christian

> 
> On Sun, Feb 23, 2020 at 11:32 AM Christian Mauderer
> mailto:l...@c-mauderer.de>> wrote:
> >
> > On 23/02/2020 17:07, Alan Cudmore wrote:
> > > I have been trying to bring up RTEMS with rtems-libbsd on the
> > > beaglebone black (latest master).
> > >
> > > I can run the regular RTEMS samples on the board, and a couple
> of the
> > > rtems-libbsd testsuite examples run as well.
> > >
> > > The samples such as ping01 and usb01 get a fatal exception in the
> > > function fdt_ro_probe_ , leading me to believe that maybe I am not
> > > using the correct device tree blob.
> > >
> > > I'm using the instructions here:
> > > https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
> > >
> > > And I have am loading am335x-boneblack.dtb that I copied from a
> linux
> > > u-boot build. The instructions talk about getting the one from the
> > > FreeBSD repository, but there are many other files included in that
> > > dts source.
> > >
> > > What dtb is normally used for the Beaglebone black RTEMS libbsd
> testing?
> > >
> > > Is the dtb needed for the non-libbsd BSP?
> > >
> > > Also, is the ethernet supported on the RTEMS beagle BSP, or do I
> need
> > > libbsd to get ethernet?
> > >
> > > Thanks,
> > > Alan
> >
> > Hello Alan,
> >
> > I recommend to use the FreeBSD device trees. libbsd is FreeBSD
> based and
> > therefore works best with them. Normally I would suggest to use the
> > version matching the FreeBSD commit used in libbsd. But
> unfortunately in
> > the last commit that doesn't seem to work. Vijay had some problems
> with
> > it and noted that the version from FreeBSD commit
> > 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
> >
> > Regarding Ethernet support: As far as I know there is no support
> for the
> > legacy stack. But the one in libbsd worked fine the last time I tested
> > it (which was when I ported it). If you really want to use the legacy
> > stack please note that it is still an IPv4 only one and therefore
> it is
> > quite limited nowadays.
> >
> > Best regards
> >
> > Christian
> ___
> 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
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 24/02/2020 07:01, Chris Johns wrote:
> 
> 
>> On 24 Feb 2020, at 5:32 am, Christian Mauderer  wrote:
>>
>> On 23/02/2020 17:07, Alan Cudmore wrote:
>>> I have been trying to bring up RTEMS with rtems-libbsd on the
>>> beaglebone black (latest master).
>>>
>>> I can run the regular RTEMS samples on the board, and a couple of the
>>> rtems-libbsd testsuite examples run as well.
>>>
>>> The samples such as ping01 and usb01 get a fatal exception in the
>>> function fdt_ro_probe_ , leading me to believe that maybe I am not
>>> using the correct device tree blob.
>>>
>>> I'm using the instructions here:
>>> https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
>>>
>>> And I have am loading am335x-boneblack.dtb that I copied from a linux
>>> u-boot build. The instructions talk about getting the one from the
>>> FreeBSD repository, but there are many other files included in that
>>> dts source.
>>>
>>> What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
>>>
>>> Is the dtb needed for the non-libbsd BSP?
>>>
>>> Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
>>> libbsd to get ethernet?
>>>
>>> Thanks,
>>> Alan
>>
>> Hello Alan,
>>
>> I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
>> therefore works best with them. Normally I would suggest to use the
>> version matching the FreeBSD commit used in libbsd. But unfortunately in
>> the last commit that doesn't seem to work. Vijay had some problems with
>> it and noted that the version from FreeBSD commit
>> 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
> 
> Is this with 5 branch in Libbsd?
> 
> I am a little confused about the branch to package in a release and also 
> which FDT files we need for which branch. If different I feel a release will 
> makes things more complicated. This flies into the BSP  vertical stack 
> building in the RSB. 
> 
> I am working on releasing and I hope this does not block things. 
> 
> Chris

Hello Chris,

the non-working device tree is for the master branch from a few weeks
back. I didn't tested it with the 5-freebsd-12 branch.

Again: In the normal case I would just suggest to use the FDT sources
that match the FreeBSD commit we use for libbsd. That worked best for me
in the past. But in the current referenced commit FreeBSD has updated
the device tree sources to the ones from a recent Linux version and the
drivers haven't been adapted yet (on master - I expect that it works
better on 5-freebsd-12).

Regarding the release: I don't think you pack the FDT files (yet), do
you? So I don't see why there should be a reason for this topic to block
the release.

Note that the exact FDT version used for different BSPs is still a
bigger problem. Some BSPs expect a version provided by a board
manufacturer. Some use a random Linux DTB. And some work well with the
ones from FreeBSD (which is just a snapshot of the Linux ones) - that's
the method I prefer because it works well with libbsd most of the time.
I think currently the right device tree for the board is only documented
in the User Manual (if it is documented).

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: SPDX License Identifier Only and Full Copy?

[Andrew Butterfield]

Hi Sebastian,

a quick question 
- does the Doxygen block requirement also apply to test programs 
(xxtest/init.c),
either hand-written or model-generated?

Regards, Andrew

> On 24 Feb 2020, at 07:52, Sebastian Huber 
>  wrote:
> 
> Hello,
> 
> I updated the File Template section:
> 
> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html
> 
> Please have a look at it and check if it is all right for you.
> 
> -- 
> 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.hu...@embedded-brains.de
> PGP : Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel


Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
Lero@TCD, Head of Software Foundations & Verification Research Group
School of Computer Science and Statistics,
Room G.39, O'Reilly Institute, Trinity College, University of Dublin
 http://www.scss.tcd.ie/Andrew.Butterfield/


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

Re: SPDX License Identifier Only and Full Copy?

[Sebastian Huber]

Hello Andrew,

On 24/02/2020 10:48, Andrew Butterfield wrote:

Hi Sebastian,

a quick question
- does the Doxygen block requirement also apply to test programs 
(xxtest/init.c),
either hand-written or model-generated?


we currently don't use Doxygen in the tests. There is some test 
documentation in the *.doc files of the test suite. I would like to 
improve the test documentation with the test specification items, but 
this is a future topic.


It is probably a good approach to add some documentation to generated 
files if it is available at a higher level.


--
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.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: SPDX License Identifier Only and Full Copy?

[Joel Sherrill]

On Mon, Feb 24, 2020, 6:03 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Andrew,
>
> On 24/02/2020 10:48, Andrew Butterfield wrote:
> > Hi Sebastian,
> >
> > a quick question
> > - does the Doxygen block requirement also apply to test programs
> (xxtest/init.c),
> > either hand-written or model-generated?
>
> we currently don't use Doxygen in the tests. There is some test
> documentation in the *.doc files of the test suite. I would like to
> improve the test documentation with the test specification items, but
> this is a future topic.
>
> It is probably a good approach to add some documentation to generated
> files if it is available at a higher level.
>

It would be good if the tests had at least file level Doxygen. But that's a
lot of retrofitting.

Andrew may not realise that Doxygen is newer than RTEMS and that all
Doxygen comments are later additions or conversions of the previous comment
format.

>
> --
> 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.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ___
> 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: SPDX License Identifier Only and Full Copy?

[Andrew Butterfield]

Hi Joel,
 any test files we develop (at Lero/TCD) will be generated by python tools, 
so we could include file level Doxygen quite easily, if that is helpful.

Regards, Andrew

> On 24 Feb 2020, at 12:22, Joel Sherrill  wrote:
> 
> 
> 
> On Mon, Feb 24, 2020, 6:03 AM Sebastian Huber 
>  > wrote:
> Hello Andrew,
> 
> On 24/02/2020 10:48, Andrew Butterfield wrote:
> > Hi Sebastian,
> > 
> > a quick question
> > - does the Doxygen block requirement also apply to test programs 
> > (xxtest/init.c),
> > either hand-written or model-generated?
> 
> we currently don't use Doxygen in the tests. There is some test 
> documentation in the *.doc files of the test suite. I would like to 
> improve the test documentation with the test specification items, but 
> this is a future topic.
> 
> It is probably a good approach to add some documentation to generated 
> files if it is available at a higher level.
> 
> It would be good if the tests had at least file level Doxygen. But that's a 
> lot of retrofitting.
> 
> Andrew may not realise that Doxygen is newer than RTEMS and that all Doxygen 
> comments are later additions or conversions of the previous comment format.
> 
> -- 
> 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.hu...@embedded-brains.de 
> 
> PGP : Public key available on request.
> 
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ___
> devel mailing list
> devel@rtems.org 
> http://lists.rtems.org/mailman/listinfo/devel 
> 

Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
Lero@TCD, Head of Software Foundations & Verification Research Group
School of Computer Science and Statistics,
Room G.39, O'Reilly Institute, Trinity College, University of Dublin
 http://www.scss.tcd.ie/Andrew.Butterfield/


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

[PATCH 2/2] rtems: Add rtems_scheduler_map_from_posix_priority()

[Sebastian Huber]

Update #3881.
---
 cpukit/Makefile.am   |  1 +
 cpukit/include/rtems/rtems/tasks.h   | 18 
 cpukit/rtems/src/schedulermapfromposix.c | 70 
 testsuites/sptests/spscheduler01/init.c  | 44 
 4 files changed, 133 insertions(+)
 create mode 100644 cpukit/rtems/src/schedulermapfromposix.c

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index f5374efab7..9ed260addb 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -769,6 +769,7 @@ librtemscpu_a_SOURCES += 
rtems/src/schedulergetprocessorset.c
 librtemscpu_a_SOURCES += rtems/src/scheduleridentbyprocessor.c
 librtemscpu_a_SOURCES += rtems/src/scheduleridentbyprocessorset.c
 librtemscpu_a_SOURCES += rtems/src/schedulerident.c
+librtemscpu_a_SOURCES += rtems/src/schedulermapfromposix.c
 librtemscpu_a_SOURCES += rtems/src/schedulermaptoposix.c
 librtemscpu_a_SOURCES += rtems/src/schedulerremoveprocessor.c
 librtemscpu_a_SOURCES += rtems/src/sem.c
diff --git a/cpukit/include/rtems/rtems/tasks.h 
b/cpukit/include/rtems/rtems/tasks.h
index 9f4d918149..3ee7946df2 100644
--- a/cpukit/include/rtems/rtems/tasks.h
+++ b/cpukit/include/rtems/rtems/tasks.h
@@ -754,6 +754,24 @@ rtems_status_code rtems_scheduler_map_to_posix_priority(
   int *posix_priority
 );
 
+/**
+ * @brief Map a POSIX thread priority to the corresonding task priority.
+ *
+ * @param scheduler_id Identifier of the scheduler instance.
+ * @param posix_priority The POSIX thread priority to map.
+ * @param[out] priority Pointer to a task priority value.
+ *
+ * @retval RTEMS_SUCCESSFUL Successful operation.
+ * @retval RTEMS_INVALID_ADDRESS The @a priority parameter is @c NULL.
+ * @retval RTEMS_INVALID_ID Invalid scheduler instance identifier.
+ * @retval RTEMS_INVALID_PRIORITY Invalid POSIX thread priority.
+ */
+rtems_status_code rtems_scheduler_map_from_posix_priority(
+  rtems_id scheduler_id,
+  int  posix_priority,
+  rtems_task_priority *priority
+);
+
 /**@}*/
 
 #ifdef __cplusplus
diff --git a/cpukit/rtems/src/schedulermapfromposix.c 
b/cpukit/rtems/src/schedulermapfromposix.c
new file mode 100644
index 00..ccf56e1465
--- /dev/null
+++ b/cpukit/rtems/src/schedulermapfromposix.c
@@ -0,0 +1,70 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup ClassicTasks
+ *
+ * @brief Implementation of rtems_scheduler_map_from_posix_priority().
+ */
+
+/*
+ * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ *
+ * 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.
+ */
+
+#if HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+
+rtems_status_code rtems_scheduler_map_from_posix_priority(
+  rtems_id scheduler_id,
+  int  posix_priority,
+  rtems_task_priority *priority
+)
+{
+  const Scheduler_Control *scheduler;
+  Priority_Control core_priority;
+  bool valid;
+
+  if ( priority == NULL ) {
+return RTEMS_INVALID_ADDRESS;
+  }
+
+  scheduler = _Scheduler_Get_by_id( scheduler_id );
+  if ( scheduler == NULL ) {
+return RTEMS_INVALID_ID;
+  }
+
+  core_priority = _POSIX_Priority_To_core( scheduler, posix_priority, &valid );
+  if ( !valid ) {
+return RTEMS_INVALID_PRIORITY;
+  }
+
+  *priority = _RTEMS_Priority_From_core( scheduler, core_priority );
+  return RTEMS_SUCCESSFUL;
+}
diff --git a/testsuites/sptests/spscheduler01/init.c 
b/testsuites/sptests/spscheduler01/init.c
index 3b94adf36f..f086cb05c0 100644
--- a/testsuites/sptests/spscheduler01/init.c
+++ b/testsuites/sptests/spscheduler01/init.c
@@ -534,6 +534,49 @@ static void test_scheduler_map_to_posix(void)
   rtems_test_as

[PATCH 1/2] rtems: Add rtems_scheduler_map_to_posix_priority()

[Sebastian Huber]

Update #3881.
---
 cpukit/Makefile.am  |  1 +
 cpukit/include/rtems/rtems/tasks.h  | 18 
 cpukit/rtems/src/schedulermaptoposix.c  | 81 +
 testsuites/sptests/spscheduler01/init.c | 52 ++---
 4 files changed, 145 insertions(+), 7 deletions(-)
 create mode 100644 cpukit/rtems/src/schedulermaptoposix.c

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 85b427848a..f5374efab7 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -769,6 +769,7 @@ librtemscpu_a_SOURCES += 
rtems/src/schedulergetprocessorset.c
 librtemscpu_a_SOURCES += rtems/src/scheduleridentbyprocessor.c
 librtemscpu_a_SOURCES += rtems/src/scheduleridentbyprocessorset.c
 librtemscpu_a_SOURCES += rtems/src/schedulerident.c
+librtemscpu_a_SOURCES += rtems/src/schedulermaptoposix.c
 librtemscpu_a_SOURCES += rtems/src/schedulerremoveprocessor.c
 librtemscpu_a_SOURCES += rtems/src/sem.c
 librtemscpu_a_SOURCES += rtems/src/semcreate.c
diff --git a/cpukit/include/rtems/rtems/tasks.h 
b/cpukit/include/rtems/rtems/tasks.h
index 307b1b13aa..9f4d918149 100644
--- a/cpukit/include/rtems/rtems/tasks.h
+++ b/cpukit/include/rtems/rtems/tasks.h
@@ -736,6 +736,24 @@ rtems_status_code rtems_scheduler_get_maximum_priority(
   rtems_task_priority *priority
 );
 
+/**
+ * @brief Map a task priority to the corresonding POSIX thread priority.
+ *
+ * @param scheduler_id Identifier of the scheduler instance.
+ * @param priority The task priority to map.
+ * @param[out] posix_priority Pointer to a POSIX thread priority value.
+ *
+ * @retval RTEMS_SUCCESSFUL Successful operation.
+ * @retval RTEMS_INVALID_ADDRESS The @a posix_priority parameter is @c NULL.
+ * @retval RTEMS_INVALID_ID Invalid scheduler instance identifier.
+ * @retval RTEMS_INVALID_PRIORITY Invalid task priority.
+ */
+rtems_status_code rtems_scheduler_map_to_posix_priority(
+  rtems_id scheduler_id,
+  rtems_task_priority  priority,
+  int *posix_priority
+);
+
 /**@}*/
 
 #ifdef __cplusplus
diff --git a/cpukit/rtems/src/schedulermaptoposix.c 
b/cpukit/rtems/src/schedulermaptoposix.c
new file mode 100644
index 00..12215b89e1
--- /dev/null
+++ b/cpukit/rtems/src/schedulermaptoposix.c
@@ -0,0 +1,81 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup ClassicTasks
+ *
+ * @brief Implementation of rtems_scheduler_map_to_posix_priority().
+ */
+
+/*
+ * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ *
+ * 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.
+ */
+
+#if HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+#include 
+#include 
+
+rtems_status_code rtems_scheduler_map_to_posix_priority(
+  rtems_id scheduler_id,
+  rtems_task_priority  priority,
+  int *posix_priority
+)
+{
+  const Scheduler_Control *scheduler;
+  Priority_Control core_priority;
+  bool valid;
+  int  maybe_priority;
+
+  if ( posix_priority == NULL ) {
+return RTEMS_INVALID_ADDRESS;
+  }
+
+  scheduler = _Scheduler_Get_by_id( scheduler_id );
+  if ( scheduler == NULL ) {
+return RTEMS_INVALID_ID;
+  }
+
+  core_priority = _RTEMS_Priority_To_core( scheduler, priority, &valid );
+  if ( !valid ) {
+return RTEMS_INVALID_PRIORITY;
+  }
+
+  maybe_priority = _POSIX_Priority_From_core( scheduler, core_priority );
+
+  if ( maybe_priority < POSIX_SCHEDULER_MINIMUM_PRIORITY ) {
+return RTEMS_INVALID_PRIORITY;
+  }
+
+  if ( maybe_priority >= scheduler->maximum_priority ) {
+return RTEMS_INVALID_PRIORITY;
+  }
+
+  *posix_priority = maybe_priority;
+  return RTEMS_SUCCESSFUL;
+}
diff --git a/testsuites/sptests/sp

Re: Device Tree Blob for Beaglebone Black?

[Alan Cudmore]

Hi Vijay,
My uEnv.txt was very similar, but I did not have the "fdt addr
0x8800" command. But that did not seem to help. I still get a
fatal exception when trying to run the usb01 and ping01 programs.

Do you think the u-boot version matters?
I am using the following:
- MLO and u-boot.img from a buildroot linux build. ( u-boot 2018.1)
- RTEMS kernel master from about a week ago ( samples like unlimited
and ticker work )
- rtems-libbsd 5-freebsd-12 branch
- The am335x-boneblack.dtb compiled from the suggested commit from the
FreeBSD github repository.

I don't have a debugger, so I looked up the PC address from the register dump.
For the ping01 sample the PC indicates that it is in the fdt_ro_probe_ function.
For the usb01, it seems to crash in an termios program.

## Transferring control to RTEMS (at address 8000) ...

RTEMS Beagleboard: am335x-based
ARM Debug: 0x4b141000
*** LIBBSD PING 1 TEST ***

*** FATAL ***
fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)

R0   = 0x R8  = 0x
R1   = 0xfeed R9  = 0x
R2   = 0x0007 R10 = 0x0064
R3   = 0x006e6573 R11 = 0x802520a0
R4   = 0x0007 R12 = 0x01010101
R5   = 0xfff7 SP  = 0x8027589c
R6   = 0x80150dac LR  = 0x8011b1d0
R7   = 0x PC  = 0x8011a11c
CPSR = 0x0113 VEC = 0x0004
RTEMS version: 5.0.0.588646279951ff696f3893a4c2e79aa1ba67fccf
RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (57011908b007), Newlib d14714c69)
executing thread ID: 0x08a010001
executing thread name: UI1

One more question:
I am converting the images using the following commands:
arm-rtems5-objcopy $1.exe -O binary $1.bin
gzip -9 $1.bin
mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n RTEMS
-d $1.bin.gz $1-app.img

Are the 0x8000. addresses correct in the mkimage command? It seems
that the RTEMS executable considers the start of RAM to be 0x8000.

It might be good to have an image I can try.

Thanks for the help!
Alan

On Mon, Feb 24, 2020 at 12:57 AM Vijay Kumar Banerjee
 wrote:
>
>
>
> On Sun, Feb 23, 2020 at 11:46 PM Alan Cudmore  wrote:
>>
>> Hi Christian,
>> Thanks for the quick response. I followed the instructions in the
>> docs.rtems.org manual and generated the dtb from the FreeBSD commit
>> that Vijay suggested. It still resulted in an exception in the same
>> function.
>>
>> Do you know if a specific commit of rtems-libbsd is required to work
>> with that dtb?
>> I tried master, and then the "5-freebsd-12" branch.
>>
>> Thanks,
>> Alan
>>
> Hi Alan,
>
> I checked with the usb01 and ping01 tests running on libbsd master
> and the dtb from the commit mentioned by Christian. I can't reproduce
> the error and it seems to run as expected. I'm not sure where the
> error might be coming from. Below I'm pasting the contents of my uEnv.txt
> If the error isn't in the uEnv, I can send you my sd card image(offlist) so 
> that you
> can try that on your board and that might give some hint on what was going
> wrong.
>
> ```
> setenv bootdelay 5
> uenvcmd=run boot
> boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0 0x8800 
> am335x-boneblack.dtb ; fdt addr 0x8800; bootm 0x8080 - 0x8800
> ```
>
> Best regards,
> Vijay
>>
>> On Sun, Feb 23, 2020 at 11:32 AM Christian Mauderer  
>> wrote:
>> >
>> > On 23/02/2020 17:07, Alan Cudmore wrote:
>> > > I have been trying to bring up RTEMS with rtems-libbsd on the
>> > > beaglebone black (latest master).
>> > >
>> > > I can run the regular RTEMS samples on the board, and a couple of the
>> > > rtems-libbsd testsuite examples run as well.
>> > >
>> > > The samples such as ping01 and usb01 get a fatal exception in the
>> > > function fdt_ro_probe_ , leading me to believe that maybe I am not
>> > > using the correct device tree blob.
>> > >
>> > > I'm using the instructions here:
>> > > https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
>> > >
>> > > And I have am loading am335x-boneblack.dtb that I copied from a linux
>> > > u-boot build. The instructions talk about getting the one from the
>> > > FreeBSD repository, but there are many other files included in that
>> > > dts source.
>> > >
>> > > What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
>> > >
>> > > Is the dtb needed for the non-libbsd BSP?
>> > >
>> > > Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
>> > > libbsd to get ethernet?
>> > >
>> > > Thanks,
>> > > Alan
>> >
>> > Hello Alan,
>> >
>> > I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
>> > therefore works best with them. Normally I would suggest to use the
>> > version matching the FreeBSD commit used in libbsd. But unfortunately in
>> > the last commit that doesn't seem to work. Vijay had some problems with
>> > it and noted that the version from FreeBSD commit
>> > 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
>> >
>> > Regarding Ethernet support: As far as I know there is no support for the
>> > legacy stack. But the one in libbsd worked

Re: SPDX License Identifier Only and Full Copy?

[Joel Sherrill]

On Mon, Feb 24, 2020 at 6:46 AM Andrew Butterfield <
andrew.butterfi...@scss.tcd.ie> wrote:

> Hi Joel,
>  any test files we develop (at Lero/TCD) will be generated by python
> tools,
> so we could include file level Doxygen quite easily, if that is helpful.
>

If we have a desired pattern for test cases, that would be good to define
before
you generate more code. At least the file blocks are good to have.

For sure, I hate to get even further behind on this.

On another project, I tried to use Doxygen to capture the tests and defined
special group named UnitTests and then used @test followed by a paragraph
and bullet list of all the test cases.

It seems like Doxygen would have a really good way to do this but I haven't
found it. :(

--joel

>
> Regards, Andrew
>
> On 24 Feb 2020, at 12:22, Joel Sherrill  wrote:
>
>
>
> On Mon, Feb 24, 2020, 6:03 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello Andrew,
>>
>> On 24/02/2020 10:48, Andrew Butterfield wrote:
>> > Hi Sebastian,
>> >
>> > a quick question
>> > - does the Doxygen block requirement also apply to test programs
>> (xxtest/init.c),
>> > either hand-written or model-generated?
>>
>> we currently don't use Doxygen in the tests. There is some test
>> documentation in the *.doc files of the test suite. I would like to
>> improve the test documentation with the test specification items, but
>> this is a future topic.
>>
>> It is probably a good approach to add some documentation to generated
>> files if it is available at a higher level.
>>
>
> It would be good if the tests had at least file level Doxygen. But that's
> a lot of retrofitting.
>
> Andrew may not realise that Doxygen is newer than RTEMS and that all
> Doxygen comments are later additions or conversions of the previous comment
> format.
>
>>
>> --
>> 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.hu...@embedded-brains.de
>> PGP : Public key available on request.
>>
>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
>
> 
> Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
> Lero@TCD, Head of Software Foundations & Verification Research Group
> School of Computer Science and Statistics,
> Room G.39, O'Reilly Institute, Trinity College, University of Dublin
>  http://www.scss.tcd.ie/Andrew.Butterfield/
> 
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Testing BSP package using beaglebone black

[Gedare Bloom]

Hello John,

On Sun, Feb 23, 2020 at 10:16 PM John kongtcheu  wrote:
>
> Hello,
> I was just testing the bsp package using beagleboard and I ran into an error 
> when trying to build the bsp. I received the error
> checking for arm-rtems5-gcc... no
> configure: error: no acceptable cc found in $PATH
You need to first build and install the RTEMS Toolchain for the ARM
target (arm-rtems5) to your PATH. You can follow a similar approach as
taken to build the sparc toolchain in the Getting Started guide, but
replace sparc with arm.

> Makefile:740: recipe for target 'beagleboardxm' failed
You need to configure for the beagleboneblack BSP, not the
beagleboardxm BSP. Can you show your command line for configure to
RTEMS?

> make[2]: *** [beagleboardxm] Error 1
> make[2]: Leaving directory 
> '/home/kingkong/Coding-Projects/build/beagle-black/arm-rtems5/c'
> Makefile:289: recipe for target 'all-recursive' failed
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory 
> '/home/kingkong/Coding-Projects/build/beagle-black/arm-rtems5/c'
> For more extensive details see the screenshot below. I tried re-bootstraping 
> and following the guide for the hello-world example, but I still received the 
> same error message. I was using the guide listed on the ideas page 
> ("http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html";)
> The current path I used was /home/kingkong/Coding-Projects/rtems/5/bin:$PATH.

That Guide is outdated. You can follow many of the steps in it, but
you should use our official repositories instead of Ben's forks on
github. All the support needed for BBB has been merged into our repos
by now. I think you might find better up-to-date instructions if you
look at blog posts from GSoC Students who worked on BBB in the last
couple of years.

There is also user documentation for the beagle at
https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#beagle

> Thank you for your help
>
> ___
> 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: Testing BSP package using beaglebone black

[Gedare Bloom]

On Mon, Feb 24, 2020 at 8:44 AM Gedare Bloom  wrote:
>
> Hello John,
>
> On Sun, Feb 23, 2020 at 10:16 PM John kongtcheu  
> wrote:
> >
> > Hello,
> > I was just testing the bsp package using beagleboard and I ran into an 
> > error when trying to build the bsp. I received the error
> > checking for arm-rtems5-gcc... no
> > configure: error: no acceptable cc found in $PATH
> You need to first build and install the RTEMS Toolchain for the ARM
> target (arm-rtems5) to your PATH. You can follow a similar approach as
> taken to build the sparc toolchain in the Getting Started guide, but
> replace sparc with arm.
>
> > Makefile:740: recipe for target 'beagleboardxm' failed
> You need to configure for the beagleboneblack BSP, not the
> beagleboardxm BSP. Can you show your command line for configure to
> RTEMS?
>
> > make[2]: *** [beagleboardxm] Error 1
> > make[2]: Leaving directory 
> > '/home/kingkong/Coding-Projects/build/beagle-black/arm-rtems5/c'
> > Makefile:289: recipe for target 'all-recursive' failed
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory 
> > '/home/kingkong/Coding-Projects/build/beagle-black/arm-rtems5/c'
> > For more extensive details see the screenshot below. I tried 
> > re-bootstraping and following the guide for the hello-world example, but I 
> > still received the same error message. I was using the guide listed on the 
> > ideas page 
> > ("http://www.shrike-systems.com/beagleboard-xm-beaglebone-black-and-everything-else-rtems-on-the-beagles.html";)
> > The current path I used was 
> > /home/kingkong/Coding-Projects/rtems/5/bin:$PATH.
>
> That Guide is outdated. You can follow many of the steps in it, but
> you should use our official repositories instead of Ben's forks on
> github. All the support needed for BBB has been merged into our repos
> by now. I think you might find better up-to-date instructions if you
> look at blog posts from GSoC Students who worked on BBB in the last
> couple of years.
>
> There is also user documentation for the beagle at
> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#beagle
>
> > Thank you for your help
> >

PS: Instead of attaching a screenshot of a terminal, you can attach a
text file of the terminal output. That would be more likely to be
analyzed completely.

> > ___
> > 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: rtems-boot-image tool: Raspberry Pi

[Gedare Bloom]

Hi Niteesh,

On Sun, Feb 23, 2020 at 11:34 PM G. S. Niteesh  wrote:
>
> Hii,
>
> This is a follow-up message since this thread has been unnoticed for a while.
>
2 days over a weekend is not a while. It is typical that you would not
receive responses over a weekend, or that if your response relies on a
small number of experts that it might take even longer to get an
answer. Usually it is good to wait about a week before you ping your
own email.

Gedare

> Thank you,
> Niteesh
>
> On Fri, Feb 21, 2020 at 8:15 PM G. S. Niteesh  wrote:
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] added fesetexeptflag() test to the psxfenv test

[Eshan dhawan]

---
 testsuites/psxtests/psxfenv01/init.c | 36 
 1 file changed, 31 insertions(+), 5 deletions(-)

diff --git a/testsuites/psxtests/psxfenv01/init.c 
b/testsuites/psxtests/psxfenv01/init.c
index cdb0fa596e..8ffb9395b9 100644
--- a/testsuites/psxtests/psxfenv01/init.c
+++ b/testsuites/psxtests/psxfenv01/init.c
@@ -46,6 +46,9 @@
 #include 
 #include 
 #include 
+#include 
+
+#define rtems_test_assert(x) assert(x) 
 
 const char rtems_test_name[] = "PSXFENV 01";
 
@@ -71,19 +74,19 @@ rtems_task Init(rtems_task_argument ignored)
 r = fesetenv(FE_DFL_ENV);
 if (r)
   printf("fesetenv ==> %d\n", r);
-rtems_test_assert( r == 0 );
+assert( r == 0 );
 
 /* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
 puts( "feclearexcept(FE_ALL_EXCEPT)." );
 r = feclearexcept(FE_ALL_EXCEPT);
 if (r)
   printf("feclearexcept ==> 0x%x\n", r);
-rtems_test_assert( r == 0 );
+assert( r == 0 );
 
 r = fetestexcept( FE_ALL_EXCEPT );
 if (r)
   printf("fetestexcept ==> 0x%x\n", r);
-rtems_test_assert( r == 0 );
+assert( r == 0 );
 
 /* Test 'FE_DIVBYZERO' */
 puts( "Divide by zero and confirm fetestexcept()" );
@@ -91,12 +94,22 @@ rtems_task Init(rtems_task_argument ignored)
 b = 1.0;
 c = b/a;
 (void) c;
+/* Test fegetexceptflag() and fesetexceptflag().*/
+r=fegetexceptflag(&excepts,FE_ALL_EXCEPT);
+if(r)
+  printf("fegetexceptflag ==> 0x%x\n", r);
+assert(r == 0);
+
+r=fesetexceptflag(&excepts, FE_ALL_EXCEPT);
+if(r)
+  printf("fesetexceptflag ==> 0x%x\n", r);
+assert(r == 0);
+
 
-fegetexceptflag(&excepts,FE_ALL_EXCEPT);
 
 #ifdef FE_DIVBYZERO
 r = feraiseexcept(FE_DIVBYZERO);
-rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
+assert( fetestexcept( FE_DIVBYZERO ) );
 #endif
 
 /* Test 'FE_INEXACT' */
@@ -125,3 +138,16 @@ rtems_task Init(rtems_task_argument ignored)
 #define CONFIGURE_INIT
 #include 
 /* end of file */
+
+
+/*
+fegetenv()
+
+fegetround()
+feholdexcept()
+
+fesetexceptflag()
+fesetround()
+
+feupdateenv()
+*/
-- 
2.17.1

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

[PATCH v1] added test for fegetexeptflag and fesetexeptflag

[Eshan dhawan]

---
 testsuites/psxtests/psxfenv01/init.c | 27 +--
 1 file changed, 9 insertions(+), 18 deletions(-)

diff --git a/testsuites/psxtests/psxfenv01/init.c 
b/testsuites/psxtests/psxfenv01/init.c
index 8ffb9395b9..05f3cdc880 100644
--- a/testsuites/psxtests/psxfenv01/init.c
+++ b/testsuites/psxtests/psxfenv01/init.c
@@ -47,8 +47,9 @@
 #include 
 #include 
 #include 
+#include 
+
 
-#define rtems_test_assert(x) assert(x) 
 
 const char rtems_test_name[] = "PSXFENV 01";
 
@@ -74,19 +75,19 @@ rtems_task Init(rtems_task_argument ignored)
 r = fesetenv(FE_DFL_ENV);
 if (r)
   printf("fesetenv ==> %d\n", r);
-assert( r == 0 );
+rtems_test_assert( r == 0 );
 
 /* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
 puts( "feclearexcept(FE_ALL_EXCEPT)." );
 r = feclearexcept(FE_ALL_EXCEPT);
 if (r)
   printf("feclearexcept ==> 0x%x\n", r);
-assert( r == 0 );
+rtems_test_assert( r == 0 );
 
 r = fetestexcept( FE_ALL_EXCEPT );
 if (r)
   printf("fetestexcept ==> 0x%x\n", r);
-assert( r == 0 );
+rtems_test_assert( r == 0 );
 
 /* Test 'FE_DIVBYZERO' */
 puts( "Divide by zero and confirm fetestexcept()" );
@@ -98,18 +99,19 @@ rtems_task Init(rtems_task_argument ignored)
 r=fegetexceptflag(&excepts,FE_ALL_EXCEPT);
 if(r)
   printf("fegetexceptflag ==> 0x%x\n", r);
-assert(r == 0);
+rtems_test_assert(r == 0);
 
 r=fesetexceptflag(&excepts, FE_ALL_EXCEPT);
 if(r)
   printf("fesetexceptflag ==> 0x%x\n", r);
-assert(r == 0);
+rtems_test_assert(r == 0);
 
+ 
 
 
 #ifdef FE_DIVBYZERO
 r = feraiseexcept(FE_DIVBYZERO);
-assert( fetestexcept( FE_DIVBYZERO ) );
+rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
 #endif
 
 /* Test 'FE_INEXACT' */
@@ -140,14 +142,3 @@ rtems_task Init(rtems_task_argument ignored)
 /* end of file */
 
 
-/*
-fegetenv()
-
-fegetround()
-feholdexcept()
-
-fesetexceptflag()
-fesetround()
-
-feupdateenv()
-*/
-- 
2.17.1

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

Re: [PATCH] added fesetexeptflag() test to the psxfenv test

[Eshan Dhawan]

I have added test for fegetflagexept and fesetflagexept in psxfenv test
suite
can someone check the test case for the correctness
it runs fine in riscv
also i have sent another patch to change assert() back to
rtems_test_assert()

On Mon, Feb 24, 2020 at 9:18 PM Eshan dhawan 
wrote:

> ---
>  testsuites/psxtests/psxfenv01/init.c | 36 
>  1 file changed, 31 insertions(+), 5 deletions(-)
>
> diff --git a/testsuites/psxtests/psxfenv01/init.c
> b/testsuites/psxtests/psxfenv01/init.c
> index cdb0fa596e..8ffb9395b9 100644
> --- a/testsuites/psxtests/psxfenv01/init.c
> +++ b/testsuites/psxtests/psxfenv01/init.c
> @@ -46,6 +46,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +#define rtems_test_assert(x) assert(x)
>
>  const char rtems_test_name[] = "PSXFENV 01";
>
> @@ -71,19 +74,19 @@ rtems_task Init(rtems_task_argument ignored)
>  r = fesetenv(FE_DFL_ENV);
>  if (r)
>printf("fesetenv ==> %d\n", r);
> -rtems_test_assert( r == 0 );
> +assert( r == 0 );
>
>  /* Test 'feclearexcept()' and 'fetestexcept()' in one go. */
>  puts( "feclearexcept(FE_ALL_EXCEPT)." );
>  r = feclearexcept(FE_ALL_EXCEPT);
>  if (r)
>printf("feclearexcept ==> 0x%x\n", r);
> -rtems_test_assert( r == 0 );
> +assert( r == 0 );
>
>  r = fetestexcept( FE_ALL_EXCEPT );
>  if (r)
>printf("fetestexcept ==> 0x%x\n", r);
> -rtems_test_assert( r == 0 );
> +assert( r == 0 );
>
>  /* Test 'FE_DIVBYZERO' */
>  puts( "Divide by zero and confirm fetestexcept()" );
> @@ -91,12 +94,22 @@ rtems_task Init(rtems_task_argument ignored)
>  b = 1.0;
>  c = b/a;
>  (void) c;
> +/* Test fegetexceptflag() and fesetexceptflag().*/
> +r=fegetexceptflag(&excepts,FE_ALL_EXCEPT);
> +if(r)
> +  printf("fegetexceptflag ==> 0x%x\n", r);
> +assert(r == 0);
> +
> +r=fesetexceptflag(&excepts, FE_ALL_EXCEPT);
> +if(r)
> +  printf("fesetexceptflag ==> 0x%x\n", r);
> +assert(r == 0);
> +
>
> -fegetexceptflag(&excepts,FE_ALL_EXCEPT);
>
>  #ifdef FE_DIVBYZERO
>  r = feraiseexcept(FE_DIVBYZERO);
> -rtems_test_assert( fetestexcept( FE_DIVBYZERO ) );
> +assert( fetestexcept( FE_DIVBYZERO ) );
>  #endif
>
>  /* Test 'FE_INEXACT' */
> @@ -125,3 +138,16 @@ rtems_task Init(rtems_task_argument ignored)
>  #define CONFIGURE_INIT
>  #include 
>  /* end of file */
> +
> +
> +/*
> +fegetenv()
> +
> +fegetround()
> +feholdexcept()
> +
> +fesetexceptflag()
> +fesetround()
> +
> +feupdateenv()
> +*/
> --
> 2.17.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: SPDX License Identifier Only and Full Copy?

[Gedare Bloom]

On Mon, Feb 24, 2020 at 12:53 AM Sebastian Huber
 wrote:
>
> Hello,
>
> I updated the File Template section:
>
> https://docs.rtems.org/branches/master/eng/coding-file-hdr.html
>
> Please have a look at it and check if it is all right for you.
>
Thanks. A few notes:
* licence -> license
* Do we have rules yet for using pydoc in python source? Should we? if
so, should we also specify a header block for Python files? This might
be a discussion for a separate thread.
* Any file headers for rst documents? I guess the CC-BY-SA-4.0 is sufficient.

> --
> 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.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ___
> 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: rtems-boot-image tool: Raspberry Pi

[G. S. Niteesh]

I am sorry. I'll make sure it doesn't happen again.

On Mon, Feb 24, 2020 at 9:18 PM Gedare Bloom  wrote:

> Hi Niteesh,
>
> On Sun, Feb 23, 2020 at 11:34 PM G. S. Niteesh  wrote:
> >
> > Hii,
> >
> > This is a follow-up message since this thread has been unnoticed for a
> while.
> >
> 2 days over a weekend is not a while. It is typical that you would not
> receive responses over a weekend, or that if your response relies on a
> small number of experts that it might take even longer to get an
> answer. Usually it is good to wait about a week before you ping your
> own email.
>
> Gedare
>
> > Thank you,
> > Niteesh
> >
> > On Fri, Feb 21, 2020 at 8:15 PM G. S. Niteesh  wrote:
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Device Tree Blob for Beaglebone Black?

[Vijay Kumar Banerjee]

On Mon, Feb 24, 2020 at 8:16 PM Alan Cudmore  wrote:

> Hi Vijay,
> My uEnv.txt was very similar, but I did not have the "fdt addr
> 0x8800" command. But that did not seem to help. I still get a
> fatal exception when trying to run the usb01 and ping01 programs.
>
> Do you think the u-boot version matters?
> I am using the following:
> - MLO and u-boot.img from a buildroot linux build. ( u-boot 2018.1)
>
I don't think it's making much difference. I'm currently running u-boot
2018.11

> - RTEMS kernel master from about a week ago ( samples like unlimited
> and ticker work )
> - rtems-libbsd 5-freebsd-12 branch
>
I haven't tested with 5-freebsd-12 branch but it runs fine on master
branch.

> - The am335x-boneblack.dtb compiled from the suggested commit from the
> FreeBSD github repository.
>
> This one is fine.

> I don't have a debugger, so I looked up the PC address from the register
> dump.
> For the ping01 sample the PC indicates that it is in the fdt_ro_probe_
> function.
> For the usb01, it seems to crash in an termios program.
>
> ## Transferring control to RTEMS (at address 8000) ...
>
> RTEMS Beagleboard: am335x-based
> ARM Debug: 0x4b141000
> *** LIBBSD PING 1 TEST ***
>
> *** FATAL ***
> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
>
> R0   = 0x R8  = 0x
> R1   = 0xfeed R9  = 0x
> R2   = 0x0007 R10 = 0x0064
> R3   = 0x006e6573 R11 = 0x802520a0
> R4   = 0x0007 R12 = 0x01010101
> R5   = 0xfff7 SP  = 0x8027589c
> R6   = 0x80150dac LR  = 0x8011b1d0
> R7   = 0x PC  = 0x8011a11c
> CPSR = 0x0113 VEC = 0x0004
> RTEMS version: 5.0.0.588646279951ff696f3893a4c2e79aa1ba67fccf
> RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (57011908b007), Newlib
> d14714c69)
> executing thread ID: 0x08a010001
> executing thread name: UI1
>
> One more question:
> I am converting the images using the following commands:
> arm-rtems5-objcopy $1.exe -O binary $1.bin
> gzip -9 $1.bin
> mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n RTEMS
> -d $1.bin.gz $1-app.img
>
> Mine is similar with a slight change in OS option:

arm-rtems5-objcopy $executable -O binary $TMPDIR/${base}.bin
gzip -9 $TMPDIR/${base}.bin
mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n RTEMS -d
$TMPDIR/${base}.bin.gz $TMPDIR/$app

Are the 0x8000. addresses correct in the mkimage command? It seems
> that the RTEMS executable considers the start of RAM to be 0x8000.
>
> Yes, the start address is correct.

> It might be good to have an image I can try.
>
> I'll send that to you offlist shortly :)

> Thanks for the help!
> Alan
>
> On Mon, Feb 24, 2020 at 12:57 AM Vijay Kumar Banerjee
>  wrote:
> >
> >
> >
> > On Sun, Feb 23, 2020 at 11:46 PM Alan Cudmore 
> wrote:
> >>
> >> Hi Christian,
> >> Thanks for the quick response. I followed the instructions in the
> >> docs.rtems.org manual and generated the dtb from the FreeBSD commit
> >> that Vijay suggested. It still resulted in an exception in the same
> >> function.
> >>
> >> Do you know if a specific commit of rtems-libbsd is required to work
> >> with that dtb?
> >> I tried master, and then the "5-freebsd-12" branch.
> >>
> >> Thanks,
> >> Alan
> >>
> > Hi Alan,
> >
> > I checked with the usb01 and ping01 tests running on libbsd master
> > and the dtb from the commit mentioned by Christian. I can't reproduce
> > the error and it seems to run as expected. I'm not sure where the
> > error might be coming from. Below I'm pasting the contents of my uEnv.txt
> > If the error isn't in the uEnv, I can send you my sd card image(offlist)
> so that you
> > can try that on your board and that might give some hint on what was
> going
> > wrong.
> >
> > ```
> > setenv bootdelay 5
> > uenvcmd=run boot
> > boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0 0x8800
> am335x-boneblack.dtb ; fdt addr 0x8800; bootm 0x8080 - 0x8800
> > ```
> >
> > Best regards,
> > Vijay
> >>
> >> On Sun, Feb 23, 2020 at 11:32 AM Christian Mauderer 
> wrote:
> >> >
> >> > On 23/02/2020 17:07, Alan Cudmore wrote:
> >> > > I have been trying to bring up RTEMS with rtems-libbsd on the
> >> > > beaglebone black (latest master).
> >> > >
> >> > > I can run the regular RTEMS samples on the board, and a couple of
> the
> >> > > rtems-libbsd testsuite examples run as well.
> >> > >
> >> > > The samples such as ping01 and usb01 get a fatal exception in the
> >> > > function fdt_ro_probe_ , leading me to believe that maybe I am not
> >> > > using the correct device tree blob.
> >> > >
> >> > > I'm using the instructions here:
> >> > > https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
> >> > >
> >> > > And I have am loading am335x-boneblack.dtb that I copied from a
> linux
> >> > > u-boot build. The instructions talk about getting the one from the
> >> > > FreeBSD repository, but there are many other files included in that
> >> > > dts source.
> >> > >
> >> > > What dtb is normally used for the Beaglebone blac

Project query : [Improve Coverage Analysis Toolset]

[Anmol Mishra]

Hello, My name is Anmol, I am a Google Summer of Code,
Student developer aspirant for 2020.
I have completed the Hello-world task.

I am interested in Ticket #2920 i.e "Improve Coverage Analysis Toolset". I
know that Dr. Joel is the owner and Dr. Gedare has reported it. Is there
any mentor interested to mentor me for this project, I sincerely want to
commit myself to this project? and Is this project under high priority to
be considered for GSoC?


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

tar/psx/bsdtar on CentOS 8

[Joel Sherrill]

Hi

CentOS 8 does not have a package for pax. It does have a package for
bsdtar.

Is bsdtar sufficient for the tests? I don't call the precise issue we
favored pax over
GNU tar.

If so, could testsuites/libtests/configure.ac accept both?

Pax appears to be used only for the dl* and tar* tests. I had thought about
it
not being a hard fail but those seem like bad tests to drop out.

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

Re: Device Tree Blob for Beaglebone Black?

[Alan Cudmore]

It looks like the mkimage command difference fixed the crash.

The original BSP README:
https://git.rtems.org/rtems/tree/bsps/arm/beagle/README
$ mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n
RTEMS -d $exe.bin.gz rtems-app.img

The docs.rtems.org beagle BSP readme:
https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n RTEMS
-d app.bin.gz rtems-app.img

Thanks for the help! Next is trying to get the ethernet to communicate
with a host!

Alan

On Mon, Feb 24, 2020 at 12:08 PM Vijay Kumar Banerjee
 wrote:
>
>
>
>
> On Mon, Feb 24, 2020 at 8:16 PM Alan Cudmore  wrote:
>>
>> Hi Vijay,
>> My uEnv.txt was very similar, but I did not have the "fdt addr
>> 0x8800" command. But that did not seem to help. I still get a
>> fatal exception when trying to run the usb01 and ping01 programs.
>>
>> Do you think the u-boot version matters?
>> I am using the following:
>> - MLO and u-boot.img from a buildroot linux build. ( u-boot 2018.1)
>
> I don't think it's making much difference. I'm currently running u-boot 
> 2018.11
>>
>> - RTEMS kernel master from about a week ago ( samples like unlimited
>> and ticker work )
>> - rtems-libbsd 5-freebsd-12 branch
>
> I haven't tested with 5-freebsd-12 branch but it runs fine on master branch.
>>
>> - The am335x-boneblack.dtb compiled from the suggested commit from the
>> FreeBSD github repository.
>>
> This one is fine.
>>
>> I don't have a debugger, so I looked up the PC address from the register 
>> dump.
>> For the ping01 sample the PC indicates that it is in the fdt_ro_probe_ 
>> function.
>> For the usb01, it seems to crash in an termios program.
>>
>> ## Transferring control to RTEMS (at address 8000) ...
>>
>> RTEMS Beagleboard: am335x-based
>> ARM Debug: 0x4b141000
>> *** LIBBSD PING 1 TEST ***
>>
>> *** FATAL ***
>> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
>>
>> R0   = 0x R8  = 0x
>> R1   = 0xfeed R9  = 0x
>> R2   = 0x0007 R10 = 0x0064
>> R3   = 0x006e6573 R11 = 0x802520a0
>> R4   = 0x0007 R12 = 0x01010101
>> R5   = 0xfff7 SP  = 0x8027589c
>> R6   = 0x80150dac LR  = 0x8011b1d0
>> R7   = 0x PC  = 0x8011a11c
>> CPSR = 0x0113 VEC = 0x0004
>> RTEMS version: 5.0.0.588646279951ff696f3893a4c2e79aa1ba67fccf
>> RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (57011908b007), Newlib d14714c69)
>> executing thread ID: 0x08a010001
>> executing thread name: UI1
>>
>> One more question:
>> I am converting the images using the following commands:
>> arm-rtems5-objcopy $1.exe -O binary $1.bin
>> gzip -9 $1.bin
>> mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n RTEMS
>> -d $1.bin.gz $1-app.img
>>
> Mine is similar with a slight change in OS option:
>
> arm-rtems5-objcopy $executable -O binary $TMPDIR/${base}.bin
> gzip -9 $TMPDIR/${base}.bin
> mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n RTEMS -d 
> $TMPDIR/${base}.bin.gz $TMPDIR/$app
>
>> Are the 0x8000. addresses correct in the mkimage command? It seems
>> that the RTEMS executable considers the start of RAM to be 0x8000.
>>
> Yes, the start address is correct.
>>
>> It might be good to have an image I can try.
>>
> I'll send that to you offlist shortly :)
>>
>> Thanks for the help!
>> Alan
>>
>> On Mon, Feb 24, 2020 at 12:57 AM Vijay Kumar Banerjee
>>  wrote:
>> >
>> >
>> >
>> > On Sun, Feb 23, 2020 at 11:46 PM Alan Cudmore  
>> > wrote:
>> >>
>> >> Hi Christian,
>> >> Thanks for the quick response. I followed the instructions in the
>> >> docs.rtems.org manual and generated the dtb from the FreeBSD commit
>> >> that Vijay suggested. It still resulted in an exception in the same
>> >> function.
>> >>
>> >> Do you know if a specific commit of rtems-libbsd is required to work
>> >> with that dtb?
>> >> I tried master, and then the "5-freebsd-12" branch.
>> >>
>> >> Thanks,
>> >> Alan
>> >>
>> > Hi Alan,
>> >
>> > I checked with the usb01 and ping01 tests running on libbsd master
>> > and the dtb from the commit mentioned by Christian. I can't reproduce
>> > the error and it seems to run as expected. I'm not sure where the
>> > error might be coming from. Below I'm pasting the contents of my uEnv.txt
>> > If the error isn't in the uEnv, I can send you my sd card image(offlist) 
>> > so that you
>> > can try that on your board and that might give some hint on what was going
>> > wrong.
>> >
>> > ```
>> > setenv bootdelay 5
>> > uenvcmd=run boot
>> > boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0 0x8800 
>> > am335x-boneblack.dtb ; fdt addr 0x8800; bootm 0x8080 - 0x8800
>> > ```
>> >
>> > Best regards,
>> > Vijay
>> >>
>> >> On Sun, Feb 23, 2020 at 11:32 AM Christian Mauderer  
>> >> wrote:
>> >> >
>> >> > On 23/02/2020 17:07, Alan Cudmore wrote:
>> >> > > I have been trying to bring up RTEMS with rtems-libbsd on the
>> >> > > beaglebone black (latest master).
>> >> > >
>> >> > > I can run the regular R

RE: Tool Roadmap for the RTEMS Pre-Qualification

[Jose Valdez]

Hello Gedare,

In the sequence of your last e-mail, I spent some time to putting to work again 
the CLANG Static Analyzer.
About one year ago, I run the CLANG Static Analyzer version 7.0.0 in my Debian 
9 machine. I followed the next steps to install it:

tar xvf llvm-7.0.0.src.tar.xz
mv llvm-7.0.0.src llvm
cd llvm/tools/
tar xvf ../../cfe-7.0.0.src.tar.xz
mv cfe-7.0.0.src/ clang
cd clang/tools/
tar xvf ../../../../clang-tools-extra-7.0.0.src.tar.xz
mv clang-tools-extra-7.0.0.src/ extra
cd ../../../../
mkdir build
cd build/
cmake -G "Unix Makefiles" ../llvm
make

Meanwhile, I upgraded my machine to Debian 10 and I tried to install the CLANG 
Static Analyzer head version (11).
This version did not work for me and I tried (successfully) the default CLANG 
package provided in the system (version 7.0.1-8):

sudo apt-get install clang-format clang-tidy clang-tools clang libc++-dev 
libc++1 libc++abi-dev libc++abi1 libclang-dev libclang1 liblldb-dev 
libllvm-ocaml-dev libomp-dev libomp5 lld lldb llvm-dev llvm-runtime llvm 
python-clang

Note that the "build from source" CLANG installation (steps above) takes about 
10 hours! If your system provides a default CLANG package, I suggest to use it, 
to avoid the long-time build from source.

After installing the CLANG, you need to install the rtems source builder, clone 
and bootstrap RTEMS (as usual).
After this you shall follow the following steps, the example here is for gr740 
which is a 4-core SPARC target:

1) Change the file rtems-master/cpukit/include/rtems/score/cpustdatomic.h, by 
removing the "const" qualifier on the parameter "*obj" of the header of the 
functions _CPU_atomic_Load_uint, _CPU_atomic_Load_ulong and 
_CPU_atomic_Load_uintptr.

-> I cannot explain you very well the rationale of this step, but there
-> is a conflict with the "const" qualifier in these variables when
-> CLANG scans RTEMS


2) Set the C_INCLUDE_PATH environment variable: export 
C_INCLUDE_PATH=/sparc-rtems5/include/:/lib/gcc/sparc-rtems5/7.3.0/include/
Note that the order of the two paths matter (do not revert the order of these 
two paths).

-> This is for CLANG to know the path of the RTEMS included files from the 
source builder tools.

3) Add the toolchain binary folder to the path variable:
export PATH=/bin:${PATH}

4) In the build directory (placed alongside RTEMS) execute the following 
commands:

scan-build --use-cc=/bin/sparc-rtems5-gcc 
--use-c++=/bin/sparc-rtems5-g++ 
--analyzer-target=sparc-rtems-unknown ../rtems/configure --target=sparc-rtems5 
--disable-posix --enable-smp --enable-cxx --disable-networking --enable-drvmgr 
--disable-tests --prefix= CFLAGS="-D__CLANG_ATOMICS 
-D__rtems__"  --enable-rtemsbsp="gr740"

scan-build --use-cc=/bin/sparc-rtems5-gcc 
--use-c++=/bin/sparc-rtems5-g++ 
--analyzer-target=sparc-rtems-unknown make all

-> Note that each normal RTEMS step is preceded by " scan-build 
--use-cc=/bin/sparc-rtems5-gcc 
--use-c++=/bin/sparc-rtems5-g++ 
--analyzer-target=sparc-rtems-unknown ". If you install the CLANG Static 
Analyzer from the source (i.e not use the sytem one), then in the scan-build 
command you shall precede it with its complete path. The flags 
CFLAGS="-D__CLANG_ATOMICS -D__rtems__" for the scan-build to run (they are not 
used in a normal RTEMS compilation).

The e-mail with the results of scan-build was blocked in your server.

Tell me if you are able to build it.

For the

"It might be better to have a parseable intermediate output for the results in 
a well-structured format (e.g., XML, yaml, etc.). The report in sphinx makes 
sense, but there should be a structured output file that could be used for 
example by other report generators."

I agree that it might be convenient, and probably not hard to do.

José

-Original Message-
From: Gedare Bloom [mailto:ged...@rtems.org]
Sent: quarta-feira, 19 de fevereiro de 2020 19:03
To: Jose Valdez
Cc: sebastian huber; rtems-de...@rtems.org
Subject: Re: Tool Roadmap for the RTEMS Pre-Qualification

On Wed, Feb 19, 2020 at 8:44 AM Jose Valdez  wrote:
>
> Hello Gedare,
>
> Thank you for your review.
>
> Please find my answers below.
>
> Best regards
>
> José
>
> -Original Message-
> From: Gedare Bloom [mailto:ged...@rtems.org]
> Sent: quarta-feira, 19 de fevereiro de 2020 15:05
> To: Jose Valdez
> Cc: sebastian huber; rtems-de...@rtems.org
> Subject: Re: Tool Roadmap for the RTEMS Pre-Qualification
>
> Hi Jose,
>
> Thank you for the detailed information. I have a few questions:
> 1) Will the output of test analysis and report generator tools be
> plaintext, and will it be structured or unstructured (flat file)?
>
>
> [Jose] The final output will be in sphinx (rst) format.
>

It might be better to have a parseable intermediate output for the results in a 
well-structured format (e.g., XML, yaml, etc.). The report in sphinx makes 
sense, but there should be a structured output file that could be used for 
example by other report generators.

> 2) Do you consider the covoar tool a

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 24/02/2020 19:43, Alan Cudmore wrote:
> It looks like the mkimage command difference fixed the crash.
> 
> The original BSP README:
> https://git.rtems.org/rtems/tree/bsps/arm/beagle/README
> $ mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n
> RTEMS -d $exe.bin.gz rtems-app.img
> 
> The docs.rtems.org beagle BSP readme:
> https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
> mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n RTEMS
> -d app.bin.gz rtems-app.img

I think that the README is heavily outdated. Is there some information
left in it that isn't in the User Manual (docs.rtems.org)? If no: Would
you like to send a patch that removes it?

> 
> Thanks for the help! Next is trying to get the ethernet to communicate
> with a host!
> 
> Alan
> 
> On Mon, Feb 24, 2020 at 12:08 PM Vijay Kumar Banerjee
>  wrote:
>>
>>
>>
>>
>> On Mon, Feb 24, 2020 at 8:16 PM Alan Cudmore  wrote:
>>>
>>> Hi Vijay,
>>> My uEnv.txt was very similar, but I did not have the "fdt addr
>>> 0x8800" command. But that did not seem to help. I still get a
>>> fatal exception when trying to run the usb01 and ping01 programs.
>>>
>>> Do you think the u-boot version matters?
>>> I am using the following:
>>> - MLO and u-boot.img from a buildroot linux build. ( u-boot 2018.1)
>>
>> I don't think it's making much difference. I'm currently running u-boot 
>> 2018.11
>>>
>>> - RTEMS kernel master from about a week ago ( samples like unlimited
>>> and ticker work )
>>> - rtems-libbsd 5-freebsd-12 branch
>>
>> I haven't tested with 5-freebsd-12 branch but it runs fine on master branch.
>>>
>>> - The am335x-boneblack.dtb compiled from the suggested commit from the
>>> FreeBSD github repository.
>>>
>> This one is fine.
>>>
>>> I don't have a debugger, so I looked up the PC address from the register 
>>> dump.
>>> For the ping01 sample the PC indicates that it is in the fdt_ro_probe_ 
>>> function.
>>> For the usb01, it seems to crash in an termios program.
>>>
>>> ## Transferring control to RTEMS (at address 8000) ...
>>>
>>> RTEMS Beagleboard: am335x-based
>>> ARM Debug: 0x4b141000
>>> *** LIBBSD PING 1 TEST ***
>>>
>>> *** FATAL ***
>>> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
>>>
>>> R0   = 0x R8  = 0x
>>> R1   = 0xfeed R9  = 0x
>>> R2   = 0x0007 R10 = 0x0064
>>> R3   = 0x006e6573 R11 = 0x802520a0
>>> R4   = 0x0007 R12 = 0x01010101
>>> R5   = 0xfff7 SP  = 0x8027589c
>>> R6   = 0x80150dac LR  = 0x8011b1d0
>>> R7   = 0x PC  = 0x8011a11c
>>> CPSR = 0x0113 VEC = 0x0004
>>> RTEMS version: 5.0.0.588646279951ff696f3893a4c2e79aa1ba67fccf
>>> RTEMS tools: 7.5.0 20191114 (RTEMS 5, RSB 5 (57011908b007), Newlib 
>>> d14714c69)
>>> executing thread ID: 0x08a010001
>>> executing thread name: UI1
>>>
>>> One more question:
>>> I am converting the images using the following commands:
>>> arm-rtems5-objcopy $1.exe -O binary $1.bin
>>> gzip -9 $1.bin
>>> mkimage -A arm -O rtems -T kernel -a 0x8000 -e 0x8000 -n RTEMS
>>> -d $1.bin.gz $1-app.img
>>>
>> Mine is similar with a slight change in OS option:
>>
>> arm-rtems5-objcopy $executable -O binary $TMPDIR/${base}.bin
>> gzip -9 $TMPDIR/${base}.bin
>> mkimage -A arm -O linux -T kernel -a 0x8000 -e 0x8000 -n RTEMS -d 
>> $TMPDIR/${base}.bin.gz $TMPDIR/$app
>>
>>> Are the 0x8000. addresses correct in the mkimage command? It seems
>>> that the RTEMS executable considers the start of RAM to be 0x8000.
>>>
>> Yes, the start address is correct.
>>>
>>> It might be good to have an image I can try.
>>>
>> I'll send that to you offlist shortly :)
>>>
>>> Thanks for the help!
>>> Alan
>>>
>>> On Mon, Feb 24, 2020 at 12:57 AM Vijay Kumar Banerjee
>>>  wrote:



 On Sun, Feb 23, 2020 at 11:46 PM Alan Cudmore  
 wrote:
>
> Hi Christian,
> Thanks for the quick response. I followed the instructions in the
> docs.rtems.org manual and generated the dtb from the FreeBSD commit
> that Vijay suggested. It still resulted in an exception in the same
> function.
>
> Do you know if a specific commit of rtems-libbsd is required to work
> with that dtb?
> I tried master, and then the "5-freebsd-12" branch.
>
> Thanks,
> Alan
>
 Hi Alan,

 I checked with the usb01 and ping01 tests running on libbsd master
 and the dtb from the commit mentioned by Christian. I can't reproduce
 the error and it seems to run as expected. I'm not sure where the
 error might be coming from. Below I'm pasting the contents of my uEnv.txt
 If the error isn't in the uEnv, I can send you my sd card image(offlist) 
 so that you
 can try that on your board and that might give some hint on what was going
 wrong.

 ```
 setenv bootdelay 5
 uenvcmd=run boot
 boot=fatload mmc 0 0x8080 rtems-app.img ; fatload mmc 0 0x8800 
 am335x-boneblack.dtb ; fdt addr 0x8800; bootm 0x8080

[PATCH] Fix typo in error message

[clrrm]

From: Cláudio Maia 

---
 tester/rtems-test | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tester/rtems-test b/tester/rtems-test
index 3eb5701..520366a 100755
--- a/tester/rtems-test
+++ b/tester/rtems-test
@@ -39,4 +39,4 @@ elif test -f ${base}/share/rtems/${PYTHON_WRAPPER}; then
   PYTHON_CMD=${base}/share/rtems/${cmd}
   . ${base}/share/rtems/${PYTHON_WRAPPER}
 fi
-echo "error: RTEMS Toolkit python wrapper not found, plrease report"
+echo "error: RTEMS Toolkit python wrapper not found, please report"
-- 
2.17.1

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

Re: Status of implementation of fenv.h test suites

[Eshan Dhawan]

For implementation of fegetround() and fesetround()

basic details :
https://pubs.opengroup.org/onlinepubs/9699919799/functions/fegetround.html

As I used fesetround() to change the rounding direction it returns a
successful result
but when I test fegetround() for the same rounding direction then it fails
and just returns rounding to nearest.


On Thu, Feb 20, 2020 at 7:28 PM Joel Sherrill  wrote:

>
>
> On Thu, Feb 20, 2020 at 2:33 AM Vaibhav Gupta 
> wrote:
>
>>
>>
>> On Thu, Feb 20, 2020, 12:47 PM Eshan Dhawan 
>> wrote:
>>
>>> Hello
>>>  The current fenv.h test suite  supports only basic functions that check
>>> that fenv.h environment is present or not
>>> I would like to extend the test suite further
>>> What more functions can be added to it.
>>>
>> Test all the functions of fenv.h:
>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fenv.h.html
>>
>
> Here is the FreeBSD test.
>
> http://web.mit.edu/freebsd/head/tools/regression/lib/msun/test-fenv.c
>
> It needs to account for not having the functionality at least.
>
>
>>
>>
>> -- Vaibhav Gupta
>>
>>>
>>> -Eshan Dhawan
>>> ___
>>> 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
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

pkg-config RTEMS BSP files in master branch cause me problems

[Peter Dufault]

The files that get installed (for example as 
"lib/pkgconfig/arm-rtems5-xilinx_zynq_a9_qemu.pc") are making my life difficult 
in that they add compile and link flags that are difficult to over-ride and I 
need to in some situations.

It states clearly in the file "Warning: This stuff is experimental and may be 
changed at any time".  Am I missing instructions on how to avoid using it in 
the first place, or how to over-ride it in certain situations?

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering

This email is delivered through the public internet using protocols subject to 
interception and tampering.

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

Re: Device Tree Blob for Beaglebone Black?

[Chris Johns]

> On 24 Feb 2020, at 7:39 pm, Christian Mauderer 
>  wrote:
> 
> On 24/02/2020 07:01, Chris Johns wrote:
>> 
>> 
 On 24 Feb 2020, at 5:32 am, Christian Mauderer  wrote:
>>> 
>>> On 23/02/2020 17:07, Alan Cudmore wrote:
 I have been trying to bring up RTEMS with rtems-libbsd on the
 beaglebone black (latest master).
 
 I can run the regular RTEMS samples on the board, and a couple of the
 rtems-libbsd testsuite examples run as well.
 
 The samples such as ping01 and usb01 get a fatal exception in the
 function fdt_ro_probe_ , leading me to believe that maybe I am not
 using the correct device tree blob.
 
 I'm using the instructions here:
 https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
 
 And I have am loading am335x-boneblack.dtb that I copied from a linux
 u-boot build. The instructions talk about getting the one from the
 FreeBSD repository, but there are many other files included in that
 dts source.
 
 What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
 
 Is the dtb needed for the non-libbsd BSP?
 
 Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
 libbsd to get ethernet?
 
 Thanks,
 Alan
>>> 
>>> Hello Alan,
>>> 
>>> I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
>>> therefore works best with them. Normally I would suggest to use the
>>> version matching the FreeBSD commit used in libbsd. But unfortunately in
>>> the last commit that doesn't seem to work. Vijay had some problems with
>>> it and noted that the version from FreeBSD commit
>>> 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
>> 
>> Is this with 5 branch in Libbsd?
>> 
>> I am a little confused about the branch to package in a release and also 
>> which FDT files we need for which branch. If different I feel a release will 
>> makes things more complicated. This flies into the BSP  vertical stack 
>> building in the RSB. 
>> 
>> I am working on releasing and I hope this does not block things. 
>> 
>> Chris
> 
> Hello Chris,
> 
> the non-working device tree is for the master branch from a few weeks
> back. I didn't tested it with the 5-freebsd-12 branch.

Which FDT files are needed for the 5-freebsd-12 branch? I could assume the
12-release branch in the FreeBSD repo however this is a guess, unfriendly on our
part and time consuming to sort out. I am not sure how we improve this and how
we should manage FDT source but we need to address the issue.

There are long time RTEMS users including myself struggling with this so it is a
clear indication in my mind we have an issue we need to improve.

> > Again: In the normal case I would just suggest to use the FDT sources
> that match the FreeBSD commit we use for libbsd. That worked best for me
> in the past. But in the current referenced commit FreeBSD has updated
> the device tree sources to the ones from a recent Linux version and the
> drivers haven't been adapted yet (on master - I expect that it works
> better on 5-freebsd-12).
> 
> Regarding the release: I don't think you pack the FDT files (yet), do
> you? 

No I do not but then should I be the one doing this in a release. I would have
thought this is a core issue for the BSPs that depend on FDT blobs at runtime.

I am up to libbsd with the release packaging. I can build a beagleboneblack as a
vertical stack up to libbsd and then I hit the issue of using master and not the
5-freebsd-12 branch and after that is the rtems_waf submodule naming. I would
like to resolve this in the RSB however before I do this I would like to resolve
the FDT files so I make a single pass over this.

> So I don't see why there should be a reason for this topic to block
> the release.

I do. To not handle this is to create a release where the files in the release
package crash a beagleboneblack with libbsd unless you manually get the correct
set of FDT files. This is unhelpful for users in a release context.

Consider a release called rtems-libbsd-5.0.5.tar.xz that you build. Some of the
libbsd tests work and some do not. Is the RTEMS release broken? You have never
used RTEMS and you have never used libbsd. It is all new, untested and
unfamiliar and when you follow a simple example to start networking it crashes.
After a bit of digging or a post to the user list and you find out you are
suppose to find FDT files to match from deep in the FreeBSD source. This is not
user friendly and we have not packaged what is needed to run a board. FDT is
important to RTEMS so it is important we manage it.

I would like this resolved this and for the RTEMS 5 release. The more that help
and contribute the quicker it is done and sooner I can release RTEMS 5.

> Note that the exact FDT version used for different BSPs is still a
> bigger problem. 

I see it as the same problem, it is just bigger in size than a BBB.

> Some BSPs expect a version provided by a board
> manufacturer. S

Re: Status of implementation of fenv.h test suites

[Joel Sherrill]

On Mon, Feb 24, 2020 at 1:33 PM Eshan Dhawan 
wrote:

> For implementation of fegetround() and fesetround()
>
> basic details :
> https://pubs.opengroup.org/onlinepubs/9699919799/functions/fegetround.html
>
> As I used fesetround() to change the rounding direction it returns a
> successful result
> but when I test fegetround() for the same rounding direction then it fails
> and just returns rounding to nearest.
>

Which architecture? Assuming this was on RTEMS, which BSP?

Behavior is allowed to vary a bit if the rounding mode is not supported.
Likely not supported
if you were using soft floating point.

--joel


>
>
> On Thu, Feb 20, 2020 at 7:28 PM Joel Sherrill  wrote:
>
>>
>>
>> On Thu, Feb 20, 2020 at 2:33 AM Vaibhav Gupta 
>> wrote:
>>
>>>
>>>
>>> On Thu, Feb 20, 2020, 12:47 PM Eshan Dhawan 
>>> wrote:
>>>
 Hello
  The current fenv.h test suite  supports only basic functions that
 check that fenv.h environment is present or not
 I would like to extend the test suite further
 What more functions can be added to it.

>>> Test all the functions of fenv.h:
>>> https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fenv.h.html
>>>
>>
>> Here is the FreeBSD test.
>>
>> http://web.mit.edu/freebsd/head/tools/regression/lib/msun/test-fenv.c
>>
>> It needs to account for not having the functionality at least.
>>
>>
>>>
>>>
>>> -- Vaibhav Gupta
>>>

 -Eshan Dhawan
 ___
 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
>>
>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Waf Build System Status in RTEMS?

[Chris Johns]

On 21/2/20 11:11 pm, Sebastian Huber wrote:
> On 21/02/2020 12:26, Hesham Almatary wrote:
>> On Fri, 21 Feb 2020 at 11:07, Sebastian Huber
>>   wrote:
>>> Hello Hesham,
>>>
>>> On 20/02/2020 16:40, Hesham Almatary wrote:
 Hello,

 Are there any progress updates to the Waf build system integration in 
 RTEMS?

 I have pulled [1] and it seems like it hasn't got many updates since
 December. I wonder what's still remaining/blocking to merge it, or at
 least push it as a development branch (without re-writing history)
 that others, including me, can use it and submit patches against.

 [1] git://git.rtems.org/sebh/rtems.git
>>> technically, the new build system is ready for integration into the
>>> master branch. I would need about one day to rebase and test it before
>>> the push. The integration is currently blocked since Chris and Joel had
>>> no time to look at it.
>>>
>> Thanks for your input, Sebastian. Is there a recommended branch I
>> should be based on? I noticed there's "build" and "build-next".
> 
> The "build" branch contains the state of the first review. I updated
> "build-next" a couple of times to integrate the changes on the RTEMS master.
> 
>> Do you intend to re-write git history in either?
> 
> Yes, when I started with the build system work I didn't expect a more than two
> months review period.

I have discussed this merge with Joel. We have decided to release RTEMS 5 before
we merge a new build system. A release with parallel build systems is confusing
and distracting.

I think we are close to a release if master can stay stable. The milestone
ticket page ...

 https://devel.rtems.org/milestone/5.1

... shows 43 in progress and 2 closed. Help with the tickets will help progress
things.

I am working on moving the libbsd release to the 5-freebsd-12 branch and the
side effects that causes. I will need reports of a libbsd release snapshort
running on ...

 beagleboneblack, imx7, xilinx_zynq_zedboard, qoriq_e500

I can do this for the beagleboneblack and xilinx_zynq_zedboard.

Finally there is the FDT file managements, I would like a resolution on a
suitable path to get FDT files into a release and at least one BSP to support
this. I have selected the BeagleBone Black because I have one to test on.

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

Re: Waf Build System Status in RTEMS?

[Joel Sherrill]

On Mon, Feb 24, 2020, 4:50 PM Chris Johns  wrote:

> On 21/2/20 11:11 pm, Sebastian Huber wrote:
> > On 21/02/2020 12:26, Hesham Almatary wrote:
> >> On Fri, 21 Feb 2020 at 11:07, Sebastian Huber
> >>   wrote:
> >>> Hello Hesham,
> >>>
> >>> On 20/02/2020 16:40, Hesham Almatary wrote:
>  Hello,
> 
>  Are there any progress updates to the Waf build system integration in
> RTEMS?
> 
>  I have pulled [1] and it seems like it hasn't got many updates since
>  December. I wonder what's still remaining/blocking to merge it, or at
>  least push it as a development branch (without re-writing history)
>  that others, including me, can use it and submit patches against.
> 
>  [1] git://git.rtems.org/sebh/rtems.git
> >>> technically, the new build system is ready for integration into the
> >>> master branch. I would need about one day to rebase and test it before
> >>> the push. The integration is currently blocked since Chris and Joel had
> >>> no time to look at it.
> >>>
> >> Thanks for your input, Sebastian. Is there a recommended branch I
> >> should be based on? I noticed there's "build" and "build-next".
> >
> > The "build" branch contains the state of the first review. I updated
> > "build-next" a couple of times to integrate the changes on the RTEMS
> master.
> >
> >> Do you intend to re-write git history in either?
> >
> > Yes, when I started with the build system work I didn't expect a more
> than two
> > months review period.
>
> I have discussed this merge with Joel. We have decided to release RTEMS 5
> before
> we merge a new build system. A release with parallel build systems is
> confusing
> and distracting.
>

We discussed this multiple times over the years and planned a final release
with the autoconf build system. We already did more motion toward a new
build system with file movement and reorganisation. I'm not saying that
doing that was bad and it is good for comparing old and new build systems
but we need a release. It is long overdue.

Also I have had multiple emails with people not wanting to base an
application on a git version. This pushes them to 4.11 for SMP which I
don't think we want. And the master is better on multiple counts than 4.11.


> I think we are close to a release if master can stay stable. The milestone
> ticket page ...
>
>  https://devel.rtems.org/milestone/5.1
>
> ... shows 43 in progress and 2 closed. Help with the tickets will help
> progress
> things.
>

As will testing and fixing what's reported.

Jeff is setting up some CIT machinery for RTEMS testing. I have him
focusing on the snapshots first.

>
> I am working on moving the libbsd release to the 5-freebsd-12 branch and
> the
> side effects that causes. I will need reports of a libbsd release snapshort
> running on ...
>
>  beagleboneblack, imx7, xilinx_zynq_zedboard, qoriq_e500
>
> I can do this for the beagleboneblack and xilinx_zynq_zedboard.
>
> Finally there is the FDT file managements, I would like a resolution on a
> suitable path to get FDT files into a release and at least one BSP to
> support
> this. I have selected the BeagleBone Black because I have one to test on.
>

This seems to be more of a pain in the ass than finding a good qemu
version. We need to find a way to handle this.

I repeat.. we need a release. Kids, grandkids ...

>
> Chris
> ___
> 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: pkg-config RTEMS BSP files in master branch cause me problems

[Chris Johns]

On 25/2/20 7:50 am, Peter Dufault wrote:
> The files that get installed (for example as 
> "lib/pkgconfig/arm-rtems5-xilinx_zynq_a9_qemu.pc") are making my life 
> difficult in that they add compile and link flags that are difficult to 
> over-ride and I need to in some situations.

Yes this is true.

> It states clearly in the file "Warning: This stuff is experimental and may be 
> changed at any time".  Am I missing instructions on how to avoid using it in 
> the first place, or how to over-ride it in certain situations?

Unfortunately you are not. The core issue is simple, a BSP config in RTEMS is a
makefile fragment and the flags in those files are joined to together with the
standard RTEMS build flags such as warnings, optimization levels, ete. There is
no easy way to separate these flags in make when exporting these flags to a .pc
file and it was at this point the effort halted many years ago. Some BSPs work
however getting them all to work was too big a task. The new waf build system
will address this by providing a managed set of flags. Until then the rtems_waf
package manages this by filtering the flags using the code ...

https://git.rtems.org/rtems_waf/tree/rtems.py#n839

... and rtems-tool's rtemstoolkit as well with this code ...

https://git.rtems.org/rtems-tools/tree/rtemstoolkit/rld-cc.cpp#n79

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

Re: Status of implementation of fenv.h test suites

[Eshan Dhawan]

Sent from my iPhone

>> On 25-Feb-2020, at 4:20 AM, Joel Sherrill  wrote:
> 
> 
> 
>> On Mon, Feb 24, 2020 at 1:33 PM Eshan Dhawan  wrote:
>> For implementation of fegetround() and fesetround()
>> 
>> basic details : 
>> https://pubs.opengroup.org/onlinepubs/9699919799/functions/fegetround.html
>> 
>> As I used fesetround() to change the rounding direction it returns a 
>> successful result 
>> but when I test fegetround() for the same rounding direction then it fails 
>> and just returns rounding to nearest.
> 
> Which architecture? Assuming this was on RTEMS, which BSP?
> 
I am using rv32imac bsp 

> Behaviour is allowed to vary a bit if the rounding mode is not supported. 
> Likely not supported
> if you were using soft floating point.
> 
> --joel
>  
I will add all the rounding direction test cases for fesetround and fegetround 
And you can check them

--eshan   
>> 
>> 
>>> On Thu, Feb 20, 2020 at 7:28 PM Joel Sherrill  wrote:
>>> 
>>> 
 On Thu, Feb 20, 2020 at 2:33 AM Vaibhav Gupta  
 wrote:
 
 
> On Thu, Feb 20, 2020, 12:47 PM Eshan Dhawan  
> wrote:
> Hello 
>  The current fenv.h test suite  supports only basic functions that check 
> that fenv.h environment is present or not 
> I would like to extend the test suite further 
> What more functions can be added to it.
 
 Test all the functions of fenv.h:
 https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fenv.h.html
>>> 
>>> Here is the FreeBSD test. 
>>> 
>>> http://web.mit.edu/freebsd/head/tools/regression/lib/msun/test-fenv.c
>>> 
>>> It needs to account for not having the functionality at least.
>>>  
 
 
 -- Vaibhav Gupta
> 
> -Eshan Dhawan 
> ___
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS test

[John kongtcheu]

Hello,
I'm trying to run the rtems-test after closing my computer and switching
operating systems(dual booted computer), but weirdly enough, I received the
message
rtems-test: command not found
So I attempted running the command for rtems-tools, but then the message I
received was
 ./rtems-test --lists-bsps
error: RTEMS Toolkit python wrapper not found, plrease report
Understand, I had previously been able to run the rtems-test command fine
before, this was only after I turned off ubuntu, turned on Windows, and
then turned off Windows and turned on ubuntu that this error occurred.
I'd greatly appreciate help in this mater.
Thank you,
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Device Tree Blob for Beaglebone Black?

[Christian Mauderer]

On 24/02/2020 23:26, Chris Johns wrote:
>> On 24 Feb 2020, at 7:39 pm, Christian Mauderer 
>>  wrote:
>>
>> On 24/02/2020 07:01, Chris Johns wrote:
>>>
>>>
> On 24 Feb 2020, at 5:32 am, Christian Mauderer  wrote:

 On 23/02/2020 17:07, Alan Cudmore wrote:
> I have been trying to bring up RTEMS with rtems-libbsd on the
> beaglebone black (latest master).
>
> I can run the regular RTEMS samples on the board, and a couple of the
> rtems-libbsd testsuite examples run as well.
>
> The samples such as ping01 and usb01 get a fatal exception in the
> function fdt_ro_probe_ , leading me to believe that maybe I am not
> using the correct device tree blob.
>
> I'm using the instructions here:
> https://git.rtems.org/rtems-docs/tree/user/bsps/arm/beagle.rst
>
> And I have am loading am335x-boneblack.dtb that I copied from a linux
> u-boot build. The instructions talk about getting the one from the
> FreeBSD repository, but there are many other files included in that
> dts source.
>
> What dtb is normally used for the Beaglebone black RTEMS libbsd testing?
>
> Is the dtb needed for the non-libbsd BSP?
>
> Also, is the ethernet supported on the RTEMS beagle BSP, or do I need
> libbsd to get ethernet?
>
> Thanks,
> Alan

 Hello Alan,

 I recommend to use the FreeBSD device trees. libbsd is FreeBSD based and
 therefore works best with them. Normally I would suggest to use the
 version matching the FreeBSD commit used in libbsd. But unfortunately in
 the last commit that doesn't seem to work. Vijay had some problems with
 it and noted that the version from FreeBSD commit
 19a6ceb89dbacf74697d493e48c388767126d418 works fine.
>>>
>>> Is this with 5 branch in Libbsd?
>>>
>>> I am a little confused about the branch to package in a release and also 
>>> which FDT files we need for which branch. If different I feel a release 
>>> will makes things more complicated. This flies into the BSP  vertical stack 
>>> building in the RSB. 
>>>
>>> I am working on releasing and I hope this does not block things. 
>>>
>>> Chris
>>
>> Hello Chris,
>>
>> the non-working device tree is for the master branch from a few weeks
>> back. I didn't tested it with the 5-freebsd-12 branch.
> 
> Which FDT files are needed for the 5-freebsd-12 branch? I could assume the
> 12-release branch in the FreeBSD repo however this is a guess, unfriendly on 
> our
> part and time consuming to sort out. I am not sure how we improve this and how
> we should manage FDT source but we need to address the issue.

Same problem here. The topic already popped up multiple times and I
can't really answer it.

Like I said multiple time: My approach is to use the fdt that matches
the FreeBSD commit used in libbsd. So for the 5-freebsd-12 branch that
is the one from FreeBSD commit 0d1c391321b34b3025cf0e72f2231d836ff76da8.
But it's not a rule that works for all BSPs. Some BSPs are adapted to
use a board manufacturers DTB or some random Linux one.

> 
> There are long time RTEMS users including myself struggling with this so it 
> is a
> clear indication in my mind we have an issue we need to improve.
> 
>>> Again: In the normal case I would just suggest to use the FDT sources
>> that match the FreeBSD commit we use for libbsd. That worked best for me
>> in the past. But in the current referenced commit FreeBSD has updated
>> the device tree sources to the ones from a recent Linux version and the
>> drivers haven't been adapted yet (on master - I expect that it works
>> better on 5-freebsd-12).
>>
>> Regarding the release: I don't think you pack the FDT files (yet), do
>> you? 
> 
> No I do not but then should I be the one doing this in a release. I would have
> thought this is a core issue for the BSPs that depend on FDT blobs at runtime.
> 
> I am up to libbsd with the release packaging. I can build a beagleboneblack 
> as a
> vertical stack up to libbsd and then I hit the issue of using master and not 
> the
> 5-freebsd-12 branch and after that is the rtems_waf submodule naming. I would
> like to resolve this in the RSB however before I do this I would like to 
> resolve
> the FDT files so I make a single pass over this.
> 
>> So I don't see why there should be a reason for this topic to block
>> the release.
> 
> I do. To not handle this is to create a release where the files in the release
> package crash a beagleboneblack with libbsd unless you manually get the 
> correct
> set of FDT files. This is unhelpful for users in a release context.
> 
> Consider a release called rtems-libbsd-5.0.5.tar.xz that you build. Some of 
> the
> libbsd tests work and some do not. Is the RTEMS release broken? You have never
> used RTEMS and you have never used libbsd. It is all new, untested and
> unfamiliar and when you follow a simple example to start networking it 
> crashes.
> After a bit of digging or a post to the user list and y

[PATCH 2/2] c-user: rtems_scheduler_map_from_posix_priority()

[Sebastian Huber]

Close #3881.
---
 c-user/scheduling_concepts.rst | 40 
 1 file changed, 40 insertions(+)

diff --git a/c-user/scheduling_concepts.rst b/c-user/scheduling_concepts.rst
index 4106d41..12316b7 100644
--- a/c-user/scheduling_concepts.rst
+++ b/c-user/scheduling_concepts.rst
@@ -40,6 +40,9 @@ The directives provided by the scheduler manager are:
 - rtems_scheduler_map_to_posix_priority_ - Map task priority to POSIX thread
   prority
 
+- rtems_scheduler_map_from_posix_priority_ - Map POSIX thread priority to task
+  prority
+
 - rtems_scheduler_get_processor_ - Get current processor index
 
 - rtems_scheduler_get_processor_maximum_ - Get processor maximum
@@ -741,6 +744,43 @@ NOTES:
 
\clearpage
 
+.. _rtems_scheduler_map_from_posix_priority:
+
+SCHEDULER_MAP_TO_POSIX_PRIORITY - Map POSIX thread prority to task priority
+---
+
+CALLING SEQUENCE:
+.. code-block:: c
+
+rtems_status_code rtems_scheduler_map_from_posix_priority(
+rtems_id scheduler_id,
+int  posix_priority,
+rtems_task_priority *priority
+);
+
+DIRECTIVE STATUS CODES:
+.. list-table::
+ :class: rtems-table
+
+ * - ``RTEMS_SUCCESSFUL``
+   - Successful operation.
+ * - ``RTEMS_INVALID_ADDRESS``
+   - The ``priority`` parameter is ``NULL``.
+ * - ``RTEMS_INVALID_ID``
+   - Invalid scheduler instance identifier.
+ * - ``RTEMS_INVALID_PRIORITY``
+   - Invalid POSIX thread priority.
+
+DESCRIPTION:
+Maps a POSIX thread priority to the corresponding task priority.
+
+NOTES:
+None.
+
+.. raw:: latex
+
+   \clearpage
+
 .. _rtems_scheduler_get_processor:
 
 SCHEDULER_GET_PROCESSOR - Get current processor index
-- 
2.16.4

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

[PATCH 1/2] c-user: rtems_scheduler_map_to_posix_priority()

[Sebastian Huber]

Update #3881.
---
 c-user/scheduling_concepts.rst | 40 
 1 file changed, 40 insertions(+)

diff --git a/c-user/scheduling_concepts.rst b/c-user/scheduling_concepts.rst
index 22d39e1..4106d41 100644
--- a/c-user/scheduling_concepts.rst
+++ b/c-user/scheduling_concepts.rst
@@ -37,6 +37,9 @@ The directives provided by the scheduler manager are:
 
 - rtems_scheduler_get_maximum_priority_ - Get maximum task priority of a 
scheduler
 
+- rtems_scheduler_map_to_posix_priority_ - Map task priority to POSIX thread
+  prority
+
 - rtems_scheduler_get_processor_ - Get current processor index
 
 - rtems_scheduler_get_processor_maximum_ - Get processor maximum
@@ -701,6 +704,43 @@ NOTES:
 
\clearpage
 
+.. _rtems_scheduler_map_to_posix_priority:
+
+SCHEDULER_MAP_TO_POSIX_PRIORITY - Map task priority to POSIX thread prority
+---
+
+CALLING SEQUENCE:
+.. code-block:: c
+
+rtems_status_code rtems_scheduler_map_to_posix_priority(
+rtems_id scheduler_id,
+rtems_task_priority  priority,
+int *posix_priority
+);
+
+DIRECTIVE STATUS CODES:
+.. list-table::
+ :class: rtems-table
+
+ * - ``RTEMS_SUCCESSFUL``
+   - Successful operation.
+ * - ``RTEMS_INVALID_ADDRESS``
+   - The ``posix_priority`` parameter is ``NULL``.
+ * - ``RTEMS_INVALID_ID``
+   - Invalid scheduler instance identifier.
+ * - ``RTEMS_INVALID_PRIORITY``
+   - Invalid task priority.
+
+DESCRIPTION:
+Maps a task priority to the corresponding POSIX thread priority.
+
+NOTES:
+None.
+
+.. raw:: latex
+
+   \clearpage
+
 .. _rtems_scheduler_get_processor:
 
 SCHEDULER_GET_PROCESSOR - Get current processor index
-- 
2.16.4

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

RTEMS 5 libdl bugs

[Sebastian Huber]

Hello,

there are six libdl bugs reported for RTEMS 5:

https://devel.rtems.org/query?status=accepted&status=assigned&status=reopened&component=lib%2Fdl&milestone=5.1&group=status&col=id&col=summary&col=owner&col=type&col=priority&col=component&col=version&order=priority

Are they release blockers or can they move to a new milestone?

Chris, if you don't want to work on them please re-assign the tickets to 
Needs Funding.


--
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.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel