Re: arm-rtems5-g++ -std=c++11 and -std=c++0x support

[Mikhail Svetkin]

Good to know. Thank you!
Best regards,
Mikhail


On Mon, 7 Jan 2019 at 07:24, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 04/01/2019 22:12, Mikhail Svetkin wrote:
> > Hi,
> >
> > RTEMS supports only GNU extensions.
> >
> > You can use -std=gnu++11
>
> This was fixed recently. It should work now with -std=c++11.
>
> --
> 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

[PATCH 0/6] Rework overview chapter in User Manual

[Sebastian Huber]

Sebastian Huber (6):
  Remove build date from first page
  Update general copyright notice
  Remove superfluous word "Copyright"
  Add common header.rst to reduce copy and paste
  Update header.rst
  user: Rework overview

 bsp-howto/index.rst|  24 +-
 c-user/index.rst   |  24 +-
 common/conf.py |  25 +-
 common/header.rst  |  23 +
 common/rtemsstyle.sty  |   2 +-
 cpu-supplement/index.rst   |  24 +-
 develenv/index.rst |  24 +-
 eclipse/index.rst  |  24 +-
 eng/index.rst  |  24 +-
 filesystem/index.rst   |  24 +-
 networking/index.rst   |  24 +-
 porting/index.rst  |  24 +-
 posix-compliance/index.rst |  24 +-
 posix-users/index.rst  |  24 +-
 rsb/index.rst  |  24 +-
 shell/index.rst|  24 +-
 user/glossary/index.rst|  59 -
 user/index.rst |  24 +-
 user/overview/index.rst| 203 ++---
 user/start/index.rst   |   2 +
 20 files changed, 272 insertions(+), 378 deletions(-)
 create mode 100644 common/header.rst

-- 
2.16.4

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

[PATCH 1/6] Remove build date from first page

[Sebastian Huber]

The usage of a build date prevents reproducible builds.
---
 common/conf.py | 25 +
 1 file changed, 1 insertion(+), 24 deletions(-)

diff --git a/common/conf.py b/common/conf.py
index 60db066..8d5e6b8 100644
--- a/common/conf.py
+++ b/common/conf.py
@@ -1,26 +1,3 @@
-import datetime
-
-def build_date():
-now = datetime.date.today()
-m = now.strftime('%B')
-y = now.strftime('%Y')
-if now.day == 11:
-s = 'th'
-elif now.day % 10 == 1:
-s = 'st'
-elif now.day == 12:
-s = 'th'
-elif now.day % 10 == 2:
-s = 'nd'
-elif now.day == 13:
-s = 'th'
-elif now.day == 3:
-s = 'rd'
-else:
-s = 'th'
-d = '%2d%s' % (now.day, s)
-return '%s %s %s' % (d, m, y)
-
 extensions = [
"sphinx.ext.autodoc",
"sphinx.ext.coverage",
@@ -47,7 +24,7 @@ master_doc = 'index'
 
 # General information about the project.
 project = u'RTEMS Documentation Project'
-copyright = u'2018, RTEMS Project (built %s)' % (build_date())
+copyright = u'2018, RTEMS Project'
 
 # The version info for the project you're documenting, acts as replacement for
 # |version| and |release|, also used in various other places throughout the
-- 
2.16.4

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

[PATCH 2/6] Update general copyright notice

[Sebastian Huber]

Update year and add "and contributors".
---
 common/conf.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/conf.py b/common/conf.py
index 8d5e6b8..5be4568 100644
--- a/common/conf.py
+++ b/common/conf.py
@@ -24,7 +24,7 @@ master_doc = 'index'
 
 # General information about the project.
 project = u'RTEMS Documentation Project'
-copyright = u'2018, RTEMS Project'
+copyright = u'2018, 2019 RTEMS Project and contributors'
 
 # The version info for the project you're documenting, acts as replacement for
 # |version| and |release|, also used in various other places throughout the
-- 
2.16.4

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

[PATCH 3/6] Remove superfluous word "Copyright"

[Sebastian Huber]

The © symbol is sufficient.
---
 common/rtemsstyle.sty | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/rtemsstyle.sty b/common/rtemsstyle.sty
index 96313f1..5a7a4e4 100644
--- a/common/rtemsstyle.sty
+++ b/common/rtemsstyle.sty
@@ -44,7 +44,7 @@ gobble=0,
   {\rm\Huge \@title \par}%
   {\em\LARGE \py@release\releaseinfo \par}
   {\large
-   \copyright Copyright \rtemscopyright \par
+   \copyright \space \rtemscopyright \par
\py@authoraddress \par
   }%
 }%
-- 
2.16.4

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

[PATCH 5/6] Update header.rst

[Sebastian Huber]

Remove trailing slashes in URLs.  Fix bug reporting URL.
---
 common/header.rst | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/common/header.rst b/common/header.rst
index 1b34cb1..e0dcfe7 100644
--- a/common/header.rst
+++ b/common/header.rst
@@ -7,17 +7,17 @@ any product described in this document is assumed.  The 
authors reserve the
 right to revise this material and to make changes from time to time in the
 content hereof without obligation to notify anyone of such revision or changes.
 
-The RTEMS Project is hosted at http://www.rtems.org/.  Any inquiries concerning
+The RTEMS Project is hosted at https://www.rtems.org.  Any inquiries concerning
 RTEMS, its related support components, or its documentation should be directed
-to the Community Project hosted at http://www.rtems.org/.
+to the RTEMS Project community.
 
 .. topic:: RTEMS Online Resources
 
-    =
-  Home  https://www.rtems.org/
-  Developershttps://devel.rtems.org/
-  Documentation https://docs.rtems.org/
-  Bug Reporting https://devel.rtems.org/query
-  Mailing Lists https://lists.rtems.org/
-  Git Repositories  https://git.rtems.org/
-    =
+  
+Home  https://www.rtems.org
+Documentation https://docs.rtems.org
+Mailing Lists https://lists.rtems.org
+Bug Reporting https://devel.rtems.org/wiki/Developer/Bug_Reporting
+Git Repositories  https://git.rtems.org
+Developershttps://devel.rtems.org
+  
-- 
2.16.4

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

[PATCH 4/6] Add common header.rst to reduce copy and paste

[Sebastian Huber]

---
 bsp-howto/index.rst| 24 +---
 c-user/index.rst   | 24 +---
 common/header.rst  | 23 +++
 cpu-supplement/index.rst   | 24 +---
 develenv/index.rst | 24 +---
 eclipse/index.rst  | 24 +---
 eng/index.rst  | 24 +---
 filesystem/index.rst   | 24 +---
 networking/index.rst   | 24 +---
 porting/index.rst  | 24 +---
 posix-compliance/index.rst | 24 +---
 posix-users/index.rst  | 24 +---
 rsb/index.rst  | 24 +---
 shell/index.rst| 24 +---
 user/index.rst | 24 +---
 15 files changed, 37 insertions(+), 322 deletions(-)
 create mode 100644 common/header.rst

diff --git a/bsp-howto/index.rst b/bsp-howto/index.rst
index 147e145..bf47a4d 100644
--- a/bsp-howto/index.rst
+++ b/bsp-howto/index.rst
@@ -13,29 +13,7 @@ RTEMS BSP and Driver Guide (|version|).
  |  Creative Commons Attribution-ShareAlike 4.0 International Public License
  |  https://creativecommons.org/licenses/by-sa/4.0/legalcode
 
-The authors have used their best efforts in preparing this material.  These
-efforts include the development, research, and testing of the theories and
-programs to determine their effectiveness.  No warranty of any kind, expressed
-or implied, with regard to the software or the material contained in this
-document is provided.  No liability arising out of the application or use of
-any product described in this document is assumed.  The authors reserve the
-right to revise this material and to make changes from time to time in the
-content hereof without obligation to notify anyone of such revision or changes.
-
-The RTEMS Project is hosted at http://www.rtems.org/.  Any inquiries concerning
-RTEMS, its related support components, or its documentation should be directed
-to the Community Project hosted at http://www.rtems.org/.
-
-.. topic:: RTEMS Online Resources
-
-    =
-  Home  https://www.rtems.org/
-  Developershttps://devel.rtems.org/
-  Documentation https://docs.rtems.org/
-  Bug Reporting https://devel.rtems.org/query
-  Mailing Lists https://lists.rtems.org/
-  Git Repositories  https://git.rtems.org/
-    =
+.. include:: ../common/header.rst
 
 .. toctree::
:maxdepth: 5
diff --git a/c-user/index.rst b/c-user/index.rst
index e0527b3..eec7d89 100644
--- a/c-user/index.rst
+++ b/c-user/index.rst
@@ -13,29 +13,7 @@ RTEMS Classic API Guide (|version|).
  |  Creative Commons Attribution-ShareAlike 4.0 International Public License
  |  https://creativecommons.org/licenses/by-sa/4.0/legalcode
 
-The authors have used their best efforts in preparing this material.  These
-efforts include the development, research, and testing of the theories and
-programs to determine their effectiveness.  No warranty of any kind, expressed
-or implied, with regard to the software or the material contained in this
-document is provided.  No liability arising out of the application or use of
-any product described in this document is assumed.  The authors reserve the
-right to revise this material and to make changes from time to time in the
-content hereof without obligation to notify anyone of such revision or changes.
-
-The RTEMS Project is hosted at http://www.rtems.org/.  Any inquiries concerning
-RTEMS, its related support components, or its documentation should be directed
-to the Community Project hosted at http://www.rtems.org/.
-
-.. topic:: RTEMS Online Resources
-
-    =
-  Home  https://www.rtems.org/
-  Developershttps://devel.rtems.org/
-  Documentation https://docs.rtems.org/
-  Bug Reporting https://devel.rtems.org/query
-  Mailing Lists https://lists.rtems.org/
-  Git Repositories  https://git.rtems.org/
-    =
+.. include:: ../common/header.rst
 
 .. toctree::
 :maxdepth: 5
diff --git a/common/header.rst b/common/header.rst
new file mode 100644
index 000..1b34cb1
--- /dev/null
+++ b/common/header.rst
@@ -0,0 +1,23 @@
+The authors have used their best efforts in preparing this material.  These
+efforts include the development, research, and testing of the theories and
+programs to determine their effectiveness.  No warranty of any kind, expressed
+or implied, with regard to the software or the material contained in this
+document is provided.  No liability arising out of the application or use of
+any product described in this document is assumed.  The authors reserve the
+right to revise this material and to make changes from time to time in the
+content hereof with

[PATCH 6/6] user: Rework overview

[Sebastian Huber]

Move "Overview", "Real-time Applicaiton Systems" and "Real-time
Executive" chapters as sections into new "Introduction" chapter.  Add
"Feature" section.
---
 user/glossary/index.rst |  59 +-
 user/overview/index.rst | 203 +---
 user/start/index.rst|   2 +
 3 files changed, 233 insertions(+), 31 deletions(-)

diff --git a/user/glossary/index.rst b/user/glossary/index.rst
index ddb1c34..a11da7b 100644
--- a/user/glossary/index.rst
+++ b/user/glossary/index.rst
@@ -11,6 +11,12 @@ Glossary
 architectures follow the GCC architecture model as RTEMS needs an GCC
 architecture compiler for each support RTEMS architecture.
 
+  APA
+Arbitrary Processor Affinity
+
+  API
+Application Programming Interface
+
   Binutils
 GNU Binary Utilities such as the assembler ``as``, linker ``ld`` and a
 range of other tools used in the development of software.
@@ -23,6 +29,12 @@ Glossary
   Buildbot
 A continuous inteagration build server.
 
+  C11
+ISO/IEC 9899:2011
+
+  C++11
+ISO/IEC 14882:2011
+
   Crosscompiler
 
 A compiler built to run on a Host that generate code for another
@@ -31,12 +43,33 @@ Glossary
   DLL
 Dynamically Linker Library used on Windows.
 
+  EDF
+Earliest Deadline First
+
+  EMB²
+`Embedded Multicore Building Blocks `_
+
+  FAT
+File Allocation Table
+
+  Futex
+Fast User-Space Locking
+
+  IMFS
+In-Memory File System
+
+  JFFS2
+Journalling Flash File System version 2
+
   GCC
-GNU Compiler Tool chain. It is the GNU C/C++ compiler, binutils and GDB.
+GNU Compiler Collection
 
   GDB
 GNU Debugger
 
+  GNU
+GNU's Not Unix
+
   Host
 The computer and operating system that hosts the RTEMS development tools
 such as the compiler, linker and debugger.
@@ -49,6 +82,9 @@ Glossary
   MinGW64
 Minimal GNU system for 64bit Windows. MinGW64 is not the MinGW project.
 
+  MrsP
+Multiprocessor Resource-Sharing Protocol
+
   MSYS2
 Minimal System 2 is a fork of the MinGW project's MSYS tool and the MinGW
 MSYS tool is a fork of Cygwin project. The Cygwin project provides a POSIX
@@ -57,6 +93,15 @@ Glossary
 has a simplified path structure to make it easier to building native 
Windows
 programs.
 
+  NFSv2
+Network File System version 2
+
+  OMIP
+:math:`O(m)` Independence-Preserving Protocol
+
+  OpenMP
+Open Multi-Processing
+
   POSIX
 Portable Operating System Interface is a standard that lets software be
 portable between compliant operating systems.
@@ -65,6 +110,9 @@ Glossary
 A path used when building a package so all parts of the package reside
 under that path.
 
+  RFS
+RTEMS File System
+
   RSB
 RTEMS Source Builder is part of the RTEMS Tools Project. It builds packages
 such as the tools for the RTEMS operating system.
@@ -75,6 +123,9 @@ Glossary
 variety of open standard application programming interfaces (API) and
 interface standards such as POSIX and BSD sockets.
 
+  SMP
+Symmetric Multiprocessing
+
   Target
 A target is the hardware or simulator a BSP built executable runs on.
 
@@ -84,5 +135,11 @@ Glossary
   Testsuite
 RTEMS test suite located in the ``testsuites/`` directory.
 
+  TLS
+Thread-Local Storage
+
   Waf
 Waf build system.  For more information see http://www.waf.io/
+
+  YAFFS2
+`Yet Another Flash File System version 2 
`_
diff --git a/user/overview/index.rst b/user/overview/index.rst
index 76bac36..84a6033 100644
--- a/user/overview/index.rst
+++ b/user/overview/index.rst
@@ -1,60 +1,189 @@
 .. comment SPDX-License-Identifier: CC-BY-SA-4.0
 
+Introduction
+
+
 Overview
-
+
+
+You are someone looking for a real-time operating system.  This document
+
+- presents the basic features of RTEMS, so that you can decide if it is worth 
to
+  look at,
+
+- gives you a :ref:`quick start ` to install all the tools
+  necessary to work with RTEMS, and
+
+- helps you to build an example application on top of RTEMS.
+
+Features
+
+
+The Real-Time Executive for Multiprocessor Systems (:ref:term:`RTEMS`) is a
+multi-threaded, single address-space, real-time operating system with no
+kernel-space/user-space separation.  It is capable to operate in an
+:ref:term:`SMP` configuration providing a state of the art feature set.
+
+RTEMS is licensed under a
+`modified GPL 2.0 or later license with an exception for static linking 
`_
+[#]_.  It exposes no license requirements on application code.  The third-party
+software used and distributed by RTEMS which may be linked to the application
+is licensed under permissive open source licenses.  Everything necessary to
+build RTEMS applications is available as open source software.  This makes you
+completely vendor independent.
+
+RTEMS provides the following basic feature set

Re: [PATCH 1/6] Remove build date from first page

[Chris Johns]

> On 7 Jan 2019, at 10:03 pm, Sebastian Huber 
>  wrote:
> 
> The usage of a build date prevents reproducible builds.

-1

I prefer a build date being present. For unreleased it marks the online builds 
and for releases it tags the day built. 

I have never seen this being a requirement for docs output. What drives the 
need for this?

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

Re: [PATCH 1/6] Remove build date from first page

[Sebastian Huber]

On 07/01/2019 12:39, Chris Johns wrote:

On 7 Jan 2019, at 10:03 pm, Sebastian Huber 
 wrote:

The usage of a build date prevents reproducible builds.

-1

I prefer a build date being present. For unreleased it marks the online builds 
and for releases it tags the day built.


Adding the Git commit to the documents would be more useful. The build 
date is completely arbitrary.




I have never seen this being a requirement for docs output. What drives the 
need for this?


I think this build date is only misleading information.

--
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: [PATCH 1/6] Remove build date from first page

[Sebastian Huber]

On 07/01/2019 12:49, Sebastian Huber wrote:

On 07/01/2019 12:39, Chris Johns wrote:
On 7 Jan 2019, at 10:03 pm, Sebastian Huber 
 wrote:


The usage of a build date prevents reproducible builds.

-1

I prefer a build date being present. For unreleased it marks the 
online builds and for releases it tags the day built.


Adding the Git commit to the documents would be more useful. The build 
date is completely arbitrary.


What do you think about replacing the date with a Git commit hash? I can 
try to do this.


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

[PATCH] Extend delay in PSXFILE01 test with one tick

[Jiri Gaisler]

Checking of atime in psxfile01 (line 713) can fail since a delay for
rtems_clock_get_ticks_per_second (line 699) gives a delay of less than
one second, depending on when the last tick occurred. atime is measured
in whole seconds, and a fast processor might read the file before a new
second occurs. Add one tick to the delay will solve the problem.

Jiri.

diff --git a/testsuites/psxtests/psxfile01/test.c b/testsuites/psxtests/psxfile01/test.c
index 1ea3dad503..121b08f648 100644
--- a/testsuites/psxtests/psxfile01/test.c
+++ b/testsuites/psxtests/psxfile01/test.c
@@ -696,7 +696,7 @@ since new path is not valid");
   ctime2 = buf.st_ctime;
 
 
-  status = rtems_task_wake_after( rtems_clock_get_ticks_per_second() );
+  status = rtems_task_wake_after( rtems_clock_get_ticks_per_second() + 1);
   rewind( file );
   while ( fgets(buffer, 128, file) )
 printf( "%s", buffer );
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] build: Call rtems-syms with the $(CC) of the build

[Sebastian Huber]

This enables support for non-standard compiler names, e.g.
sparc-rtems6-gcc.
---
 testsuites/libtests/Makefile.am | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/testsuites/libtests/Makefile.am b/testsuites/libtests/Makefile.am
index 810f65db8e..467c8a28d0 100644
--- a/testsuites/libtests/Makefile.am
+++ b/testsuites/libtests/Makefile.am
@@ -344,7 +344,7 @@ dl01-tar.h: dl01.tar
 dl01-tar.o: dl01-tar.c dl01-tar.h
$(AM_V_CC)$(COMPILE) -c -o $@ $<
 dl01-sym.o: dl01.pre
-   $(AM_V_GEN)rtems-syms -e -c "$(CFLAGS)" -o $@ $<
+   $(AM_V_GEN)rtems-syms -e -C $(CC) -c "$(CFLAGS)" -o $@ $<
 dl01$(EXEEXT):  $(dl01_OBJECTS) $(dl01_DEPENDENCIES) dl01-sym.o
@rm -f $@
$(AM_V_CCLD)$(LINK.c) $(CPU_CFLAGS) $(AM_CFLAGS) $(AM_LDFLAGS) -o $@ $+
@@ -377,7 +377,7 @@ dl02-tar.h: dl02.tar
 dl02-tar.o: dl02-tar.c dl02-tar.h
$(AM_V_CC)$(COMPILE) -c -o $@ $<
 dl02-sym.o: dl02.pre
-   $(AM_V_GEN)rtems-syms -e -c "$(CFLAGS)" -o $@ $<
+   $(AM_V_GEN)rtems-syms -e -C $(CC) -c "$(CFLAGS)" -o $@ $<
 dl02$(EXEEXT):  $(dl02_OBJECTS) $(dl02_DEPENDENCIES) dl02-sym.o
@rm -f $@
$(AM_V_CCLD)$(LINK.c) $(CPU_CFLAGS) $(AM_CFLAGS) $(AM_LDFLAGS) -o $@ $+
@@ -420,7 +420,7 @@ dl04-tar.h: dl04.tar
 dl04-tar.o: dl04-tar.c dl04-tar.h
$(AM_V_CC)$(COMPILE) -c -o $@ $<
 dl04-sym.o: dl04.pre
-   $(AM_V_GEN)rtems-syms -e -c "$(CFLAGS)" -o $@ $<
+   $(AM_V_GEN)rtems-syms -e -C $(CC) -c "$(CFLAGS)" -o $@ $<
 dl04$(EXEEXT):  $(dl04_OBJECTS) $(dl04_DEPENDENCIES) dl04-sym.o
@rm -f $@
$(AM_V_CXXLD)$(LINK.cc) $(CPU_CFLAGS) $(AM_CFLAGS) $(AM_LDFLAGS) -o $@ 
$+
@@ -454,7 +454,7 @@ dl05-tar.h: dl05.tar
 dl05-tar.o: dl05-tar.c dl05-tar.h
$(AM_V_CC)$(COMPILE) -c -o $@ $<
 dl05-sym.o: dl05.pre
-   $(AM_V_GEN)rtems-syms -e -c "$(CFLAGS)" -o $@ $<
+   $(AM_V_GEN)rtems-syms -e -C $(CC) -c "$(CFLAGS)" -o $@ $<
 dl05$(EXEEXT): $(dl05_OBJECTS) $(dl05_DEPENDENCIES) dl05-sym.o
@rm -f $@
$(AM_V_CXXLD)$(LINK.cc) $(CPU_CFLAGS) $(AM_CFLAGS) $(AM_LDFLAGS) -o $@ 
$+
@@ -504,7 +504,7 @@ dl06-tar.h: dl06.tar
 dl06-tar.o: dl06-tar.c dl06-tar.h
$(AM_V_CC)$(COMPILE) -c -o $@ $<
 dl06-sym.o: dl06.pre
-   $(AM_V_GEN)rtems-syms -e -c "$(CFLAGS)" -o $@ $<
+   $(AM_V_GEN)rtems-syms -e -C $(CC) -c "$(CFLAGS)" -o $@ $<
 dl06$(EXEEXT): $(dl06_OBJECTS) dl06-sym.o
@rm -f $@
$(AM_V_CCLD)$(LINK.c) $(CPU_CFLAGS) $(AM_CFLAGS) $(AM_LDFLAGS) -o $@ $+
@@ -543,7 +543,7 @@ dl07-tar.h: dl07.tar
 dl07-tar.o: dl07-tar.c dl07-tar.h
$(AM_V_CC)$(COMPILE) -c -o $@ $<
 dl07-sym.o: dl07.pre
-   $(AM_V_GEN)rtems-syms -e -c "$(CFLAGS)" -o $@ $<
+   $(AM_V_GEN)rtems-syms -e -C $(CC) -c "$(CFLAGS)" -o $@ $<
 dl07$(EXEEXT):  $(dl07_OBJECTS) $(dl07_DEPENDENCIES) dl07-sym.o
@rm -f $@
$(AM_V_CCLD)$(LINK.c) $(CPU_CFLAGS) $(AM_CFLAGS) $(AM_LDFLAGS) -o $@ $+
-- 
2.16.4

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

[PATCH] build: Call rtems-ld with the $(CC) of the build

[Sebastian Huber]

This enables support for non-standard compiler names, e.g.
sparc-rtems6-gcc.
---
 testsuites/libtests/Makefile.am | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/testsuites/libtests/Makefile.am b/testsuites/libtests/Makefile.am
index 467c8a28d0..37bfd77e0c 100644
--- a/testsuites/libtests/Makefile.am
+++ b/testsuites/libtests/Makefile.am
@@ -491,9 +491,10 @@ dl06-o1.o: dl06/dl06-o1.c Makefile
 dl06-o2.o: dl06/dl06-o2.c Makefile
$(AM_V_CC)$(COMPILE) -c -o $@ $<
 dl06.rap: dl06.pre dl06-o1.o dl06-o2.o
-   $(AM_V_GEN)rtems-ld -r $(RTEMS_BUILD_ROOT) -c "$(CPU_CFLAGS)" \
+   $(AM_V_GEN)rtems-ld -r $(RTEMS_BUILD_ROOT) \
+ -C $(CC) -c "$(CPU_CFLAGS)" \
  -O rap -b $< -e rtems_main -s \
--o $@ $(filter-out dl06.pre,$+) -lm
+ -o $@ $(filter-out dl06.pre,$+) -lm
 dl06.tar: dl06.rap
@rm -f $@
$(AM_V_GEN)$(PAX) -w -f $@ $<
-- 
2.16.4

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

Re: [PATCH] 6: Add unstable RTEMS 6 tool chain

[Sebastian Huber]

I was able to build all tools except epiphany on a FreeBSD 11 machine. I 
built the erc32 BSP and did a test run. One problem was this:


rtems-test --rtems-bsp=erc32 --rtems-tools=/opt/rtems/6 
/home/user/build/b-erc32

RTEMS Testing - Tester, 5.0.not_released
 Command Line: /opt/rtems/6/bin/rtems-test --rtems-bsp=erc32 
--rtems-tools=/opt/rtems/6 /home/user/build/b-erc32
 Python: 2.7.12 (default, Oct 29 2016, 13:38:04) [GCC 4.2.1 Compatible 
FreeBSD Clang 3.8.0 (tags/RELEASE_380/final 262564)]
Host: FreeBSD-11.1-RELEASE-p1-amd64-64bit-ELF (FreeBSD FreeBSDBuild 
11.1-RELEASE-p1 FreeBSD 11.1-RELEASE-p1 #0: Wed Aug  9 11:55:48 UTC 2017 
r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 amd64)
[  3/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | 
sparc/erc32: whetstone.exe
[  6/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | 
sparc/erc32: fsdosfsformat01.exe
[  1/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | 
sparc/erc32: dhrystone.exe
[  2/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | 
sparc/erc32: linpack.exe
[  5/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | 
sparc/erc32: fsclose01.exe
[  4/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | 
sparc/erc32: fsbdpart01.exe
[  8/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | 
sparc/erc32: fsdosfsname02.exe
[  7/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | 
sparc/erc32: fsdosfsname01.exe
error: gdb exec: /opt/rtems/6/bin/sparc-rtems5-gdb: No such file or 
directory


I fixed this with a symbolic link:

ln -s /opt/rtems/6/bin/sparc-rtems6-gdb /opt/rtems/6/bin/sparc-rtems5-gdb

I will try to automate this to get a weekly update.

What do we want to do with failing targets? I will probably take care of 
the main stream targets, but what about epiphany?


--
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: [PATCH 1/6] Remove build date from first page

[Joel Sherrill]

We need some indication for automated builds on RTEMS.org that the server
actually did build something. The script that builds the docs on the server
should create a file and put the build time in it.

On Mon, Jan 7, 2019, 5:04 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de wrote:

> The usage of a build date prevents reproducible builds.
> ---
>  common/conf.py | 25 +
>  1 file changed, 1 insertion(+), 24 deletions(-)
>
> diff --git a/common/conf.py b/common/conf.py
> index 60db066..8d5e6b8 100644
> --- a/common/conf.py
> +++ b/common/conf.py
> @@ -1,26 +1,3 @@
> -import datetime
> -
> -def build_date():
> -now = datetime.date.today()
> -m = now.strftime('%B')
> -y = now.strftime('%Y')
> -if now.day == 11:
> -s = 'th'
> -elif now.day % 10 == 1:
> -s = 'st'
> -elif now.day == 12:
> -s = 'th'
> -elif now.day % 10 == 2:
> -s = 'nd'
> -elif now.day == 13:
> -s = 'th'
> -elif now.day == 3:
> -s = 'rd'
> -else:
> -s = 'th'
> -d = '%2d%s' % (now.day, s)
> -return '%s %s %s' % (d, m, y)
> -
>  extensions = [
> "sphinx.ext.autodoc",
> "sphinx.ext.coverage",
> @@ -47,7 +24,7 @@ master_doc = 'index'
>
>  # General information about the project.
>  project = u'RTEMS Documentation Project'
> -copyright = u'2018, RTEMS Project (built %s)' % (build_date())
> +copyright = u'2018, RTEMS Project'
>
>  # The version info for the project you're documenting, acts as
> replacement for
>  # |version| and |release|, also used in various other places throughout
> the
> --
> 2.16.4
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/6] Remove build date from first page

[Sebastian Huber]

On 07/01/2019 14:43, Joel Sherrill wrote:
We need some indication for automated builds on RTEMS.org that the 
server actually did build something. The script that builds the docs 
on the server should create a file and put the build time in it.


Built something is good, but built the right thing is better. I would 
like to replace the date with a Git commit hash.


--
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: arm-rtems5-g++ -std=c++11 and -std=c++0x support

[Misra, Avinash]

Hi Sebastian,

Thanks for letting me know. Do you know which version fixes this?

I’m currently using commit fdd3b85022b3fb9484f36e3b4cf755b584093cb1 I believe.

Thanks,
Avi


From: Mikhail Svetkin 
Sent: Monday, January 7, 2019 4:17 AM
To: Sebastian Huber 
Cc: Misra, Avinash ; rtems-de...@rtems.org 

Subject: Re: arm-rtems5-g++ -std=c++11 and -std=c++0x support

Good to know. Thank you!
Best regards,
Mikhail


On Mon, 7 Jan 2019 at 07:24, Sebastian Huber 
mailto:sebastian.hu...@embedded-brains.de>> 
wrote:
On 04/01/2019 22:12, Mikhail Svetkin wrote:
> Hi,
>
> RTEMS supports only GNU extensions.
>
> You can use -std=gnu++11

This was fixed recently. It should work now with -std=c++11.

--
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: arm-rtems5-g++ -std=c++11 and -std=c++0x support

[Sebastian Huber]

Please try the current master with up to date tools. I think a Newlib 
update was necessary for this.


On 07/01/2019 14:54, Misra, Avinash wrote:


Hi Sebastian,

Thanks for letting me know. Do you know which version fixes this?

I’m currently using commit fdd3b85022b3fb9484f36e3b4cf755b584093cb1 I 
believe.


Thanks,

Avi

*From:*Mikhail Svetkin 
*Sent:* Monday, January 7, 2019 4:17 AM
*To:* Sebastian Huber 
*Cc:* Misra, Avinash ; rtems-de...@rtems.org 


*Subject:* Re: arm-rtems5-g++ -std=c++11 and -std=c++0x support

Good to know. Thank you!

Best regards,
Mikhail

On Mon, 7 Jan 2019 at 07:24, Sebastian Huber 
> wrote:


On 04/01/2019 22:12, Mikhail Svetkin wrote:
> Hi,
>
> RTEMS supports only GNU extensions.
>
> You can use -std=gnu++11

This was fixed recently. It should work now with -std=c++11.

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



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

Status of RISCV port on sis

[Jiri Gaisler]

I have now made a bsp for a RISCV/GRLIB system, and have been running
the testsuite on sis/RISCV. I have a few remaining failures:

$ rtems-test --rtems-bsp=riscv-sis riscv-rtems5/c/grlib/testsuites
--log=all.txt

Passed:    569
Failed:  5
User Input:  5
Expected Fail:   0
Indeterminate:   0
Benchmark:   3
Timeout: 0
Invalid: 0
Wrong Version:   0
Wrong Build: 0
Wrong Tools: 0
--
Total: 582
Failures:
 sp37.exe
 spintrcritical07.exe
 spintrcritical11.exe
 spintrcritical12.exe
 spintrcritical15.exe
User Input:
 monitor.exe
 termios.exe
 top.exe
 capture.exe
 fileio.exe
Benchmark:
 whetstone.exe
 dhrystone.exe
 linpack.exe
Average test time: 0:00:00.483282
Testing time : 0:04:41.270156

The sp37 test fails with an interesting error:

 *** BEGIN OF TEST SP 37 ***
] *** TEST VERSION: 5.0.0.eba55a6ad63a1433f50ba0d627394f447bacd04f-modified
] *** TEST STATE: EXPECTED-PASS
] *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
] *** TEST TOOLS: 9.0.0 20181112 (RTEMS 5, RSB
96673d751ab488d5d892ae67c1842aef9d5c068b, Newlib
df6915f029ac9acd2b479ea898388cbd7dda4974)
]
/home/jiri/ibm/src/rtems/rtems.seb/c/src/../../testsuites/sptests/sp37/init.c:
185 normal_interrupt_level != _ISR_Get_level()
]
] *** FATAL ***

The RISCV port has only two interrupt levels (on/off), and it seems that
when a task at level one (irq off) is deleted, the heir inherits
interrupt level one rather then restore its original level. Has anyone
seen this on RISCV before? It is probably something in my setup (sim or
bsp) but the test runs without interrupts and always fails the same way
regardless of compiler optimization etc.

The spintrcriticalXX tests fail with a zapped return address during
interrupt return, I am still looking into this.

Any inputs are welcome, as I have some problems of debugging this ...

Jiri.



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

Re: Status of RISCV port on sis

[Sebastian Huber]

On 07/01/2019 15:21, Jiri Gaisler wrote:

The sp37 test fails with an interesting error:

  *** BEGIN OF TEST SP 37 ***
] *** TEST VERSION: 5.0.0.eba55a6ad63a1433f50ba0d627394f447bacd04f-modified
] *** TEST STATE: EXPECTED-PASS
] *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
] *** TEST TOOLS: 9.0.0 20181112 (RTEMS 5, RSB
96673d751ab488d5d892ae67c1842aef9d5c068b, Newlib
df6915f029ac9acd2b479ea898388cbd7dda4974)
]
/home/jiri/ibm/src/rtems/rtems.seb/c/src/../../testsuites/sptests/sp37/init.c:
185 normal_interrupt_level != _ISR_Get_level()
]
] *** FATAL ***

The RISCV port has only two interrupt levels (on/off), and it seems that
when a task at level one (irq off) is deleted, the heir inherits
interrupt level one rather then restore its original level. Has anyone
seen this on RISCV before? It is probably something in my setup (sim or
bsp) but the test runs without interrupts and always fails the same way
regardless of compiler optimization etc.


This is indeed an interesting case. The RISC-V and ARM context switch 
code no longer saves and restores the interrupt status. You probably 
found a weak spot in threaddispatch.c:


void _Thread_Do_dispatch( Per_CPU_Control *cpu_self, ISR_Level level )
{
  Thread_Control *executing;

  _Assert( cpu_self->thread_dispatch_disable_level == 1 );

#if defined(RTEMS_SCORE_ROBUST_THREAD_DISPATCH)
  if (
    !_ISR_Is_enabled( level )
#if defined(RTEMS_SMP)
  && rtems_configuration_is_smp_enabled()
#endif
  ) {
    _Internal_error( INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT );
  }
#endif

I think we have to remove the rtems_configuration_is_smp_enabled() 
condition. Deleting the thread with interrupts disabled should result in 
a fatal error (INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT).


--
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: Status of RISCV port on sis

[Jiri Gaisler]

On 1/7/19 3:31 PM, Sebastian Huber wrote:
> On 07/01/2019 15:21, Jiri Gaisler wrote:
>> The sp37 test fails with an interesting error:
>>
>>   *** BEGIN OF TEST SP 37 ***
>> ] *** TEST VERSION:
>> 5.0.0.eba55a6ad63a1433f50ba0d627394f447bacd04f-modified
>> ] *** TEST STATE: EXPECTED-PASS
>> ] *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
>> ] *** TEST TOOLS: 9.0.0 20181112 (RTEMS 5, RSB
>> 96673d751ab488d5d892ae67c1842aef9d5c068b, Newlib
>> df6915f029ac9acd2b479ea898388cbd7dda4974)
>> ]
>> /home/jiri/ibm/src/rtems/rtems.seb/c/src/../../testsuites/sptests/sp37/init.c:
>>
>> 185 normal_interrupt_level != _ISR_Get_level()
>> ]
>> ] *** FATAL ***
>>
>> The RISCV port has only two interrupt levels (on/off), and it seems that
>> when a task at level one (irq off) is deleted, the heir inherits
>> interrupt level one rather then restore its original level. Has anyone
>> seen this on RISCV before? It is probably something in my setup (sim or
>> bsp) but the test runs without interrupts and always fails the same way
>> regardless of compiler optimization etc.
>
> This is indeed an interesting case. The RISC-V and ARM context switch
> code no longer saves and restores the interrupt status. You probably
> found a weak spot in threaddispatch.c:
>
> void _Thread_Do_dispatch( Per_CPU_Control *cpu_self, ISR_Level level )
> {
>   Thread_Control *executing;
>
>   _Assert( cpu_self->thread_dispatch_disable_level == 1 );
>
> #if defined(RTEMS_SCORE_ROBUST_THREAD_DISPATCH)
>   if (
>     !_ISR_Is_enabled( level )
> #if defined(RTEMS_SMP)
>   && rtems_configuration_is_smp_enabled()
> #endif
>   ) {
>     _Internal_error( INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT );
>   }
> #endif
>
> I think we have to remove the rtems_configuration_is_smp_enabled()
> condition. Deleting the thread with interrupts disabled should result
> in a fatal error (INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT).


I compared this with SPARC/leon3, which has 16 levels (0 - 15). At level
15, interrupts are effectively disabled but the interrupt level is still
restored and sp37 test works. At the moment I do not compile with SMP
and I don't have RTEMS_SCORE_ROBUST_THREAD_DISPATCH defined. So none of
the above code is active ...


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

Re: Status of RISCV port on sis

[Sebastian Huber]

On 07/01/2019 15:47, Jiri Gaisler wrote:

On 1/7/19 3:31 PM, Sebastian Huber wrote:

On 07/01/2019 15:21, Jiri Gaisler wrote:

The sp37 test fails with an interesting error:

   *** BEGIN OF TEST SP 37 ***
] *** TEST VERSION:
5.0.0.eba55a6ad63a1433f50ba0d627394f447bacd04f-modified
] *** TEST STATE: EXPECTED-PASS
] *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
] *** TEST TOOLS: 9.0.0 20181112 (RTEMS 5, RSB
96673d751ab488d5d892ae67c1842aef9d5c068b, Newlib
df6915f029ac9acd2b479ea898388cbd7dda4974)
]
/home/jiri/ibm/src/rtems/rtems.seb/c/src/../../testsuites/sptests/sp37/init.c:

185 normal_interrupt_level != _ISR_Get_level()
]
] *** FATAL ***

The RISCV port has only two interrupt levels (on/off), and it seems that
when a task at level one (irq off) is deleted, the heir inherits
interrupt level one rather then restore its original level. Has anyone
seen this on RISCV before? It is probably something in my setup (sim or
bsp) but the test runs without interrupts and always fails the same way
regardless of compiler optimization etc.

This is indeed an interesting case. The RISC-V and ARM context switch
code no longer saves and restores the interrupt status. You probably
found a weak spot in threaddispatch.c:

void _Thread_Do_dispatch( Per_CPU_Control *cpu_self, ISR_Level level )
{
   Thread_Control *executing;

   _Assert( cpu_self->thread_dispatch_disable_level == 1 );

#if defined(RTEMS_SCORE_ROBUST_THREAD_DISPATCH)
   if (
     !_ISR_Is_enabled( level )
#if defined(RTEMS_SMP)
   && rtems_configuration_is_smp_enabled()
#endif
   ) {
     _Internal_error( INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT );
   }
#endif

I think we have to remove the rtems_configuration_is_smp_enabled()
condition. Deleting the thread with interrupts disabled should result
in a fatal error (INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT).

I compared this with SPARC/leon3, which has 16 levels (0 - 15). At level
15, interrupts are effectively disabled but the interrupt level is still
restored and sp37 test works. At the moment I do not compile with SMP
and I don't have RTEMS_SCORE_ROBUST_THREAD_DISPATCH defined. So none of
the above code is active ...



This is another bug, the RISC-V should have this:

#define CPU_ENABLE_ROBUST_THREAD_DISPATCH TRUE

--
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: Status of RISCV port on sis

[Jiri Gaisler]

On 1/7/19 3:55 PM, Sebastian Huber wrote:
> On 07/01/2019 15:47, Jiri Gaisler wrote:
>> On 1/7/19 3:31 PM, Sebastian Huber wrote:
>>> On 07/01/2019 15:21, Jiri Gaisler wrote:
 The sp37 test fails with an interesting error:

    *** BEGIN OF TEST SP 37 ***
 ] *** TEST VERSION:
 5.0.0.eba55a6ad63a1433f50ba0d627394f447bacd04f-modified
 ] *** TEST STATE: EXPECTED-PASS
 ] *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
 ] *** TEST TOOLS: 9.0.0 20181112 (RTEMS 5, RSB
 96673d751ab488d5d892ae67c1842aef9d5c068b, Newlib
 df6915f029ac9acd2b479ea898388cbd7dda4974)
 ]
 /home/jiri/ibm/src/rtems/rtems.seb/c/src/../../testsuites/sptests/sp37/init.c:

 185 normal_interrupt_level != _ISR_Get_level()
 ]
 ] *** FATAL ***

 The RISCV port has only two interrupt levels (on/off), and it seems that
 when a task at level one (irq off) is deleted, the heir inherits
 interrupt level one rather then restore its original level. Has anyone
 seen this on RISCV before? It is probably something in my setup (sim or
 bsp) but the test runs without interrupts and always fails the same way
 regardless of compiler optimization etc.
>>> This is indeed an interesting case. The RISC-V and ARM context switch
>>> code no longer saves and restores the interrupt status. You probably
>>> found a weak spot in threaddispatch.c:
>>>
>>> void _Thread_Do_dispatch( Per_CPU_Control *cpu_self, ISR_Level level )
>>> {
>>>    Thread_Control *executing;
>>>
>>>    _Assert( cpu_self->thread_dispatch_disable_level == 1 );
>>>
>>> #if defined(RTEMS_SCORE_ROBUST_THREAD_DISPATCH)
>>>    if (
>>>  !_ISR_Is_enabled( level )
>>> #if defined(RTEMS_SMP)
>>>    && rtems_configuration_is_smp_enabled()
>>> #endif
>>>    ) {
>>>  _Internal_error( INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT );
>>>    }
>>> #endif
>>>
>>> I think we have to remove the rtems_configuration_is_smp_enabled()
>>> condition. Deleting the thread with interrupts disabled should result
>>> in a fatal error (INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT).
>> I compared this with SPARC/leon3, which has 16 levels (0 - 15). At level
>> 15, interrupts are effectively disabled but the interrupt level is still
>> restored and sp37 test works. At the moment I do not compile with SMP
>> and I don't have RTEMS_SCORE_ROBUST_THREAD_DISPATCH defined. So none of
>> the above code is active ...
>>
>
> This is another bug, the RISC-V should have this:
>
> #define CPU_ENABLE_ROBUST_THREAD_DISPATCH TRUE
>
So I added this define and now I get a couple of more fails:

Passed:    562
Failed: 12
User Input:  5
Expected Fail:   0
Indeterminate:   0
Benchmark:   3
Timeout: 0
Invalid: 0
Wrong Version:   0
Wrong Build: 0
Wrong Tools: 0
--
Total: 582
Failures:
 sp01.exe
 sp14.exe
 sp37.exe
 spcbssched01.exe
 spedfsched01.exe
 spfifo03.exe
 spfifo05.exe
 spintrcritical06.exe
 spintrcritical07.exe
 spintrcritical11.exe
 spintrcritical12.exe
 spintrcritical15.exe

The spintrcritical fails as before, while the other tests fail with:

 fatal code: 31 (INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT)

Should I take it that the RISC-V port is not quite ready for prime-time ...?

It's not a major problem for me, I will work on adding SMP support to my grlib 
bsp instead. That should keep me busy for a while ... :-)





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

Re: [PATCH 1/6] Remove build date from first page

[Chris Johns]

On 7/1/19 11:30 pm, Sebastian Huber wrote:
> On 07/01/2019 12:49, Sebastian Huber wrote:
>> On 07/01/2019 12:39, Chris Johns wrote:
 On 7 Jan 2019, at 10:03 pm, Sebastian Huber
  wrote:

 The usage of a build date prevents reproducible builds.
>>> -1
>>>
>>> I prefer a build date being present. For unreleased it marks the online
>>> builds and for releases it tags the day built.
>>
>> Adding the Git commit to the documents would be more useful. The build date 
>> is
>> completely arbitrary.
> 
> What do you think about replacing the date with a Git commit hash? I can try 
> to
> do this.
> 

For branch builds this is OK and I am happy to see it added and for releases we
also need to have the release details.

Technically a hash is all that is needed so it is correct if you need to
determined the exact source used but is this what people expect with
documentation, ie is a date expected?

The catalog holds the build date which is shown if you point a browser at the
documentation. Our online page has this.

If the users and community are OK with no date in the documentation then I am
OK. I am still not sure how repeatable builds of docs can be made because of the
dependence on so many other parts that can vary. I also do not know how you
perform the comparison on a PDF.

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

[PATCH] psxhdrs: Add POSIX API Signature Compliance Tests for errno.h

[Jacob Shin]

---
 testsuites/psxtests/psxhdrs/errno/errno.c | 44 +++
 1 file changed, 44 insertions(+)
 create mode 100755 testsuites/psxtests/psxhdrs/errno/errno.c

diff --git a/testsuites/psxtests/psxhdrs/errno/errno.c 
b/testsuites/psxtests/psxhdrs/errno/errno.c
new file mode 100755
index 00..242d778019
--- /dev/null
+++ b/testsuites/psxtests/psxhdrs/errno/errno.c
@@ -0,0 +1,44 @@
+/**
+ *  @file
+ *  @brief errno API Conformance Test
+ */
+
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2019 Jacob Shin
+ *
+ * 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.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+
+int test( void );
+
+int test( void )
+{
+   return (errno == ERANGE);
+}
\ No newline at end of file
-- 
2.17.1

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

Re: [PATCH] 6: Add unstable RTEMS 6 tool chain

[Chris Johns]

On 7/1/19 11:58 pm, Sebastian Huber wrote:
> I was able to build all tools except epiphany on a FreeBSD 11 machine. I built
> the erc32 BSP and did a test run. One problem was this:
> 
> rtems-test --rtems-bsp=erc32 --rtems-tools=/opt/rtems/6 
> /home/user/build/b-erc32
> RTEMS Testing - Tester, 5.0.not_released
>  Command Line: /opt/rtems/6/bin/rtems-test --rtems-bsp=erc32
> --rtems-tools=/opt/rtems/6 /home/user/build/b-erc32
>  Python: 2.7.12 (default, Oct 29 2016, 13:38:04) [GCC 4.2.1 Compatible FreeBSD
> Clang 3.8.0 (tags/RELEASE_380/final 262564)]
> Host: FreeBSD-11.1-RELEASE-p1-amd64-64bit-ELF (FreeBSD FreeBSDBuild
> 11.1-RELEASE-p1 FreeBSD 11.1-RELEASE-p1 #0: Wed Aug  9 11:55:48 UTC 2017
> r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 amd64)
> [  3/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | sparc/erc32:
> whetstone.exe
> [  6/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | sparc/erc32:
> fsdosfsformat01.exe
> [  1/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | sparc/erc32:
> dhrystone.exe
> [  2/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | sparc/erc32:
> linpack.exe
> [  5/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | sparc/erc32:
> fsclose01.exe
> [  4/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | sparc/erc32:
> fsbdpart01.exe
> [  8/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | sparc/erc32:
> fsdosfsname02.exe
> [  7/589] p:0   f:0   u:0   e:0   I:0   B:0   t:0   i:0   W:0   | sparc/erc32:
> fsdosfsname01.exe
> error: gdb exec: /opt/rtems/6/bin/sparc-rtems5-gdb: No such file or directory
> 

Ouch.

> I fixed this with a symbolic link:
> 
> ln -s /opt/rtems/6/bin/sparc-rtems6-gdb /opt/rtems/6/bin/sparc-rtems5-gdb

I thought there was a version option but I cannot see it. Please raise a ticket
on me to add a --version option to allow this to handled cleanly.

> I will try to automate this to get a weekly update.

What is updated each week?

> What do we want to do with failing targets? 

The tier structure should handle this.

> I will probably take care of the
> main stream targets, but what about epiphany?

The arch is placed in tier 5 for a release and removed after the release is 
made.

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

Re: [PATCH 1/6] Remove build date from first page

[Sebastian Huber]

On 08/01/2019 02:59, Chris Johns wrote:

On 7/1/19 11:30 pm, Sebastian Huber wrote:

On 07/01/2019 12:49, Sebastian Huber wrote:

On 07/01/2019 12:39, Chris Johns wrote:

On 7 Jan 2019, at 10:03 pm, Sebastian Huber
 wrote:

The usage of a build date prevents reproducible builds.

-1

I prefer a build date being present. For unreleased it marks the online
builds and for releases it tags the day built.

Adding the Git commit to the documents would be more useful. The build date is
completely arbitrary.

What do you think about replacing the date with a Git commit hash? I can try to
do this.


For branch builds this is OK and I am happy to see it added and for releases we
also need to have the release details.

Technically a hash is all that is needed so it is correct if you need to
determined the exact source used but is this what people expect with
documentation, ie is a date expected?

The catalog holds the build date which is shown if you point a browser at the
documentation. Our online page has this.

If the users and community are OK with no date in the documentation then I am
OK. I am still not sure how repeatable builds of docs can be made because of the
dependence on so many other parts that can vary. I also do not know how you
perform the comparison on a PDF.


What about the Git commit hash and the check in date of the commit?

--
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: [PATCH 1/6] Remove build date from first page

[Chris Johns]

> On 8 Jan 2019, at 5:19 pm, Sebastian Huber 
>  wrote:
> 
>> On 08/01/2019 02:59, Chris Johns wrote:
>>> On 7/1/19 11:30 pm, Sebastian Huber wrote:
 On 07/01/2019 12:49, Sebastian Huber wrote:
 On 07/01/2019 12:39, Chris Johns wrote:
>> On 7 Jan 2019, at 10:03 pm, Sebastian Huber
>>  wrote:
>> 
>> The usage of a build date prevents reproducible builds.
> -1
> 
> I prefer a build date being present. For unreleased it marks the online
> builds and for releases it tags the day built.
 Adding the Git commit to the documents would be more useful. The build 
 date is
 completely arbitrary.
>>> What do you think about replacing the date with a Git commit hash? I can 
>>> try to
>>> do this.
>>> 
>> For branch builds this is OK and I am happy to see it added and for releases 
>> we
>> also need to have the release details.
>> 
>> Technically a hash is all that is needed so it is correct if you need to
>> determined the exact source used but is this what people expect with
>> documentation, ie is a date expected?
>> 
>> The catalog holds the build date which is shown if you point a browser at the
>> documentation. Our online page has this.
>> 
>> If the users and community are OK with no date in the documentation then I am
>> OK. I am still not sure how repeatable builds of docs can be made because of 
>> the
>> dependence on so many other parts that can vary. I also do not know how you
>> perform the comparison on a PDF.
> 
> What about the Git commit hash and the check in date of the commit?

That is a good idea. The catalogue can still have the build date and the PDF 
has the creation date in it’s properties. 

Chris

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

Re: Status of RISCV port on sis

[Sebastian Huber]

On 07/01/2019 16:38, Jiri Gaisler wrote:

On 1/7/19 3:55 PM, Sebastian Huber wrote:

On 07/01/2019 15:47, Jiri Gaisler wrote:

On 1/7/19 3:31 PM, Sebastian Huber wrote:

On 07/01/2019 15:21, Jiri Gaisler wrote:

The sp37 test fails with an interesting error:

    *** BEGIN OF TEST SP 37 ***
] *** TEST VERSION:
5.0.0.eba55a6ad63a1433f50ba0d627394f447bacd04f-modified
] *** TEST STATE: EXPECTED-PASS
] *** TEST BUILD: RTEMS_NETWORKING RTEMS_POSIX_API
] *** TEST TOOLS: 9.0.0 20181112 (RTEMS 5, RSB
96673d751ab488d5d892ae67c1842aef9d5c068b, Newlib
df6915f029ac9acd2b479ea898388cbd7dda4974)
]
/home/jiri/ibm/src/rtems/rtems.seb/c/src/../../testsuites/sptests/sp37/init.c:

185 normal_interrupt_level != _ISR_Get_level()
]
] *** FATAL ***

The RISCV port has only two interrupt levels (on/off), and it seems that
when a task at level one (irq off) is deleted, the heir inherits
interrupt level one rather then restore its original level. Has anyone
seen this on RISCV before? It is probably something in my setup (sim or
bsp) but the test runs without interrupts and always fails the same way
regardless of compiler optimization etc.

This is indeed an interesting case. The RISC-V and ARM context switch
code no longer saves and restores the interrupt status. You probably
found a weak spot in threaddispatch.c:

void _Thread_Do_dispatch( Per_CPU_Control *cpu_self, ISR_Level level )
{
    Thread_Control *executing;

    _Assert( cpu_self->thread_dispatch_disable_level == 1 );

#if defined(RTEMS_SCORE_ROBUST_THREAD_DISPATCH)
    if (
  !_ISR_Is_enabled( level )
#if defined(RTEMS_SMP)
    && rtems_configuration_is_smp_enabled()
#endif
    ) {
  _Internal_error( INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT );
    }
#endif

I think we have to remove the rtems_configuration_is_smp_enabled()
condition. Deleting the thread with interrupts disabled should result
in a fatal error (INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT).

I compared this with SPARC/leon3, which has 16 levels (0 - 15). At level
15, interrupts are effectively disabled but the interrupt level is still
restored and sp37 test works. At the moment I do not compile with SMP
and I don't have RTEMS_SCORE_ROBUST_THREAD_DISPATCH defined. So none of
the above code is active ...


This is another bug, the RISC-V should have this:

#define CPU_ENABLE_ROBUST_THREAD_DISPATCH TRUE


So I added this define and now I get a couple of more fails:

Passed:    562
Failed: 12
User Input:  5
Expected Fail:   0
Indeterminate:   0
Benchmark:   3
Timeout: 0
Invalid: 0
Wrong Version:   0
Wrong Build: 0
Wrong Tools: 0
--
Total: 582
Failures:
  sp01.exe
  sp14.exe
  sp37.exe
  spcbssched01.exe
  spedfsched01.exe
  spfifo03.exe
  spfifo05.exe
  spintrcritical06.exe
  spintrcritical07.exe
  spintrcritical11.exe
  spintrcritical12.exe
  spintrcritical15.exe

The spintrcritical fails as before, while the other tests fail with:

  fatal code: 31 (INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT)

Should I take it that the RISC-V port is not quite ready for prime-time ...?


The problem with the robust thread dispatch is only in part a RISC-V 
specific problem. I work on this currently. It is not clear why the 
failures didn't show up on the Qemu test runs.


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