[PATCH] sapi: Add rtems_chain_get_first_unprotected()

[Sebastian Huber]

---
 cpukit/sapi/include/rtems/chain.h | 10 ++
 doc/user/chains.t | 33 +
 testsuites/sptests/spchain/init.c |  7 +++
 3 files changed, 50 insertions(+)

diff --git a/cpukit/sapi/include/rtems/chain.h 
b/cpukit/sapi/include/rtems/chain.h
index 8da355d..4d586ff 100644
--- a/cpukit/sapi/include/rtems/chain.h
+++ b/cpukit/sapi/include/rtems/chain.h
@@ -624,6 +624,16 @@ RTEMS_INLINE_ROUTINE rtems_chain_node 
*rtems_chain_get_unprotected(
 }
 
 /**
+ * @brief See _Chain_Get_first_unprotected().
+ */
+RTEMS_INLINE_ROUTINE rtems_chain_node *rtems_chain_get_first_unprotected(
+  rtems_chain_control *the_chain
+)
+{
+  return _Chain_Get_first_unprotected( the_chain );
+}
+
+/**
  * @brief Insert a node on a chain
  *
  * This routine inserts @a the_node on a chain immediately following
diff --git a/doc/user/chains.t b/doc/user/chains.t
index e5dffc2..79e5984 100644
--- a/doc/user/chains.t
+++ b/doc/user/chains.t
@@ -35,6 +35,7 @@ provided by RTEMS is:
 @item @code{@value{DIRPREFIX}chain_extract_unprotected} - Extract the node 
from the chain (unprotected)
 @item @code{@value{DIRPREFIX}chain_get} - Return the first node on the chain
 @item @code{@value{DIRPREFIX}chain_get_unprotected} - Return the first node on 
the chain (unprotected)
+@item @code{@value{DIRPREFIX}chain_get_first_unprotected} - Get the first node 
on the chain (unprotected)
 @item @code{@value{DIRPREFIX}chain_insert} - Insert the node into the chain
 @item @code{@value{DIRPREFIX}chain_insert_unprotected} - Insert the node into 
the chain (unprotected)
 @item @code{@value{DIRPREFIX}chain_append} - Append the node to chain
@@ -661,6 +662,38 @@ interrupts.
 @c
 @c
 @page
+@subsection Get the First Node (unprotected)
+
+@cindex chain get first node
+
+@subheading CALLING SEQUENCE:
+
+@ifset is-C
+@findex @value{DIRPREFIX}chain_get_first_unprotected
+@example
+@value{DIRPREFIX}chain_node *@value{DIRPREFIX}chain_get_first_unprotected(
+  @value{DIRPREFIX}chain_control *the_chain
+);
+@end example
+@end ifset
+
+@subheading RETURNS:
+
+A pointer to the former first node is returned.
+
+@subheading DESCRIPTION:
+
+Removes the first node from the chain and returns a pointer to it.  In case the
+chain was empty, then the results are unpredictable.
+
+@subheading NOTES:
+
+The function does nothing to ensure the atomicity of the operation.
+
+@c
+@c
+@c
+@page
 @subsection Insert a Node
 
 @cindex chain insert a node
diff --git a/testsuites/sptests/spchain/init.c 
b/testsuites/sptests/spchain/init.c
index ca2e135..476629b 100644
--- a/testsuites/sptests/spchain/init.c
+++ b/testsuites/sptests/spchain/init.c
@@ -117,6 +117,13 @@ static void test_chain_first_and_last(void)
   puts( "INIT - Verify rtems_chain_is_last" );
   cnode = rtems_chain_last();
   rtems_test_assert( rtems_chain_is_last( cnode ) );
+
+  cnode = rtems_chain_get_first_unprotected(  );
+  rtems_test_assert( cnode ==  );
+  cnode = rtems_chain_first(  );
+  rtems_test_assert( cnode ==  );
+  cnode = rtems_chain_last(  );
+  rtems_test_assert( cnode ==  );
 }
 
 static void test_chain_with_notification(void)
-- 
1.8.4.5

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

Re: [wwwdocs] GCC 6 Release Notes for RTEMS

[Sebastian Huber]

Hello Gerald,

On 31/10/15 21:36, Gerald Pfeifer wrote:

Hi Sebastian,

what do you think about the follow-up patch below, on top of
your original patch?


thanks for the style changes.

--
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 2/2] Export _NCPUWORDS for Ada

[Sebastian Huber]

On 30/10/15 19:02, Joel Sherrill wrote:

On October 30, 2015 1:58:33 PM EDT, Jan Sommer<soja-li...@aries.uberspace.de>  
wrote:

>Am Friday 30 October 2015, 10:07:45 schrieb Sebastian Huber:

>>On 30/10/15 09:53, Jan Sommer wrote:

>> >Am Friday 30 October 2015, 07:50:16 schrieb Sebastian Huber:

>> >> >How is this tackled in the glibc/Linux support? Is the exact

>layout of

>> >> >the structures really interesting for Ada? I guess its sufficient

>to

>> >> >tell Ada the size and alignment of pthread_attr_t for example.
>> >> >

>> >In Linux they do it like this:
>> > type pthread_attr_t is record
>> >Data : char_array (1 .. OS_Constants.PTHREAD_ATTR_SIZE);
>> > end record;
>> > pragma Convention (C, pthread_attr_t);
>> > for pthread_attr_t'Alignment use

>Interfaces.C.unsigned_long'Alignment;

>> >
>> >That's probably the best solution. The gnat-rts changes values of

>the fields only using the corresponding pthread_set functions.

>> >If no one objects I would try to change the osinte-rtems.ads in the

>same manner.

>>
>>This would be my preferred solution.
>>
>>

>
>Ok, I have made the changes locally now, but how do I submit them to
>gcc?
>Do I create patches only for gcc 4.9.x or do I need to get it into
>trunk and it gets backported?
>Their contribute page does not read as clear to me as the rtems one.

I'm glad we have good instructions.:)

Given we want this on 4.9 and forward, it needs a gcc PR. Then reference that 
in the ChangLog entry. There is a gcc list for patches. Send it there.

Since this is RTEMS specific, Sebastian or I can commit it quickly.



Depending on the size of the patch and possible future patches we may 
need a copyright assignment with the FSF.


--
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: Trouble building RTEMS from master

[Sebastian Huber]

Should be fixed now.

--
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] Fix declaration of pthread-structs in s-osinte-rtems.ads

[Sebastian Huber]

On 31/10/15 16:47, Jan Sommer wrote:

Hi,

This patch changes the Ada-declaration of the pthread-related structs such as 
pthread_attr_t from a field-equivalent declaration to just reserving the right 
amount of memory.
It is only rtems related and essentially copies the way how the types are 
defined in s-osinte-linux.ads. It makes the declarations independent of a 
particular newlib-version and fixes the bug I filed here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68169


[...]


 -
 -- Signals --
@@ -448,6 +450,7 @@ package System.OS_Interface is
ss_low_priority : int;
ss_replenish_period : timespec;
ss_initial_budget   : timespec;
+  sched_ss_max_repl   : int;
 end record;
 pragma Convention (C, struct_sched_param);


Why is this structure not changed to an opaque size + alignment type 
like the other structures?


  
@@ -621,43 +624,34 @@ private

 end record;
 pragma Convention (C, timespec);
  
-   CLOCK_REALTIME :  constant clockid_t := 1;

-   CLOCK_MONOTONIC : constant clockid_t := 4;
+   CLOCK_REALTIME :  constant clockid_t := System.OS_Constants.CLOCK_REALTIME;
+   CLOCK_MONOTONIC : constant clockid_t := System.OS_Constants.CLOCK_MONOTONIC;
+
+   subtype char_array is Interfaces.C.char_array;
  
 type pthread_attr_t is record

-  is_initialized  : int;
-  stackaddr   : System.Address;
-  stacksize   : int;
-  contentionscope : int;
-  inheritsched: int;
-  schedpolicy : int;
-  schedparam  : struct_sched_param;
-  cputime_clocked_allowed : int;
-  detatchstate: int;
+  Data : char_array (1 .. OS_Constants.PTHREAD_ATTR_SIZE);
 end record;
 pragma Convention (C, pthread_attr_t);
+   for pthread_attr_t'Alignment use Interfaces.C.unsigned_long'Alignment;
  
 type pthread_condattr_t is record

-  flags   : int;
-  process_shared  : int;
+  Data : char_array (1 .. OS_Constants.PTHREAD_CONDATTR_SIZE);
 end record;
 pragma Convention (C, pthread_condattr_t);
+   for pthread_condattr_t'Alignment use Interfaces.C.int'Alignment;
  
 type pthread_mutexattr_t is record

-  is_initialized  : int;
-  process_shared  : int;
-  prio_ceiling: int;
-  protocol: int;
-  mutex_type  : int;
-  recursive   : int;
-   end record;
+  Data : char_array (1 .. OS_Constants.PTHREAD_MUTEXATTR_SIZE);
+   end  record;
 pragma Convention (C, pthread_mutexattr_t);
+   for pthread_mutexattr_t'Alignment use Interfaces.C.int'Alignment;

[...]

The alignment is sometimes int and sometimes unsigned long. I would 
change this to long long or double throughout, e.g. if we change the CPU 
mask type to uint64_t, then the alignment specified here is no longer 
correct.


--
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: Tools for RTEMS 4.12

[Sebastian Huber]

On 05/11/15 15:50, Daniel Gutson wrote:

On Thu, Nov 5, 2015 at 11:41 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de>  wrote:

>Hello,
>
>I would like to add the tools for RTEMS 4.12 to the RSB. The question is
>which GCC version should we use? Since our release process is so slow I tend
>to use GCC 6 since it includes support for OpenMP and C++11 threads out of
>the box. I use it currently for development and it works quite good at least
>on ARM and PowerPC.

Out of curiosity: OpenMP on ARM? Could you detail the core name?


What do you mean with core name? The Altera Cyclone V and Xilinx Zynq 
use Cortex-A9 MPCore if this is what you mean.




Thanks,

Daniel.

ps: we're successfully using gcc 5.2 with custom patches that make
RTEMS compile. We are currently working with the gcc community to
finish one of them. We can provide them here meanwhile.



What is the problem with 5.2? I didn't experience problems with this GCC 
branch.


--
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] Add RTEMS 4.12 build set

[Sebastian Huber]

---
 rtems/config/4.12/rtems-all.bset   | 17 
 rtems/config/4.12/rtems-arm.bset   |  4 ++
 rtems/config/4.12/rtems-autotools-base.bset| 23 +++
 rtems/config/4.12/rtems-autotools-internal.bset| 13 ++
 rtems/config/4.12/rtems-autotools.bset | 22 ++
 rtems/config/4.12/rtems-bfin.bset  |  3 ++
 rtems/config/4.12/rtems-default.bset   |  8 
 rtems/config/4.12/rtems-epiphany.bset  | 48 ++
 rtems/config/4.12/rtems-i386.bset  |  4 ++
 rtems/config/4.12/rtems-lm32.bset  |  3 ++
 rtems/config/4.12/rtems-m32c.bset  |  3 ++
 rtems/config/4.12/rtems-m68k.bset  |  3 ++
 rtems/config/4.12/rtems-microblaze.bset|  3 ++
 rtems/config/4.12/rtems-mips.bset  |  3 ++
 rtems/config/4.12/rtems-moxie.bset |  3 ++
 rtems/config/4.12/rtems-nios2.bset |  3 ++
 rtems/config/4.12/rtems-or1k.bset  | 43 +++
 rtems/config/4.12/rtems-powerpc.bset   |  4 ++
 rtems/config/4.12/rtems-sh.bset|  3 ++
 rtems/config/4.12/rtems-sparc.bset |  4 ++
 rtems/config/4.12/rtems-sparc64.bset   |  3 ++
 rtems/config/4.12/rtems-v850.bset  |  3 ++
 rtems/config/rtems-4.12-base.bset  |  7 
 ...tems-gcc-6-20151101-newlib-2.2.0.20151023-1.cfg | 16 
 rtems/config/tools/rtems-tools-4.12-1.cfg  |  1 +
 source-builder/config/gcc-6-1.cfg  | 31 ++
 26 files changed, 278 insertions(+)
 create mode 100644 rtems/config/4.12/rtems-all.bset
 create mode 100644 rtems/config/4.12/rtems-arm.bset
 create mode 100644 rtems/config/4.12/rtems-autotools-base.bset
 create mode 100644 rtems/config/4.12/rtems-autotools-internal.bset
 create mode 100644 rtems/config/4.12/rtems-autotools.bset
 create mode 100644 rtems/config/4.12/rtems-bfin.bset
 create mode 100644 rtems/config/4.12/rtems-default.bset
 create mode 100644 rtems/config/4.12/rtems-epiphany.bset
 create mode 100644 rtems/config/4.12/rtems-i386.bset
 create mode 100644 rtems/config/4.12/rtems-lm32.bset
 create mode 100644 rtems/config/4.12/rtems-m32c.bset
 create mode 100644 rtems/config/4.12/rtems-m68k.bset
 create mode 100644 rtems/config/4.12/rtems-microblaze.bset
 create mode 100644 rtems/config/4.12/rtems-mips.bset
 create mode 100644 rtems/config/4.12/rtems-moxie.bset
 create mode 100644 rtems/config/4.12/rtems-nios2.bset
 create mode 100644 rtems/config/4.12/rtems-or1k.bset
 create mode 100644 rtems/config/4.12/rtems-powerpc.bset
 create mode 100644 rtems/config/4.12/rtems-sh.bset
 create mode 100644 rtems/config/4.12/rtems-sparc.bset
 create mode 100644 rtems/config/4.12/rtems-sparc64.bset
 create mode 100644 rtems/config/4.12/rtems-v850.bset
 create mode 100644 rtems/config/rtems-4.12-base.bset
 create mode 100644 
rtems/config/tools/rtems-gcc-6-20151101-newlib-2.2.0.20151023-1.cfg
 create mode 100644 rtems/config/tools/rtems-tools-4.12-1.cfg
 create mode 100644 source-builder/config/gcc-6-1.cfg

diff --git a/rtems/config/4.12/rtems-all.bset b/rtems/config/4.12/rtems-all.bset
new file mode 100644
index 000..bc0766f
--- /dev/null
+++ b/rtems/config/4.12/rtems-all.bset
@@ -0,0 +1,17 @@
+4.12/rtems-arm
+4.12/rtems-bfin
+4.12/rtems-epiphany
+4.12/rtems-i386
+4.12/rtems-lm32
+4.12/rtems-m32c
+4.12/rtems-m68k
+4.12/rtems-microblaze
+4.12/rtems-mips
+4.12/rtems-moxie
+4.12/rtems-nios2
+4.12/rtems-or1k
+4.12/rtems-powerpc
+4.12/rtems-sh
+4.12/rtems-sparc
+4.12/rtems-sparc64
+4.12/rtems-v850
diff --git a/rtems/config/4.12/rtems-arm.bset b/rtems/config/4.12/rtems-arm.bset
new file mode 100644
index 000..ead6dda
--- /dev/null
+++ b/rtems/config/4.12/rtems-arm.bset
@@ -0,0 +1,4 @@
+%define release 1
+%define rtems_arch arm
+%define with_libgomp
+%include 4.12/rtems-default.bset
diff --git a/rtems/config/4.12/rtems-autotools-base.bset 
b/rtems/config/4.12/rtems-autotools-base.bset
new file mode 100644
index 000..f68df75
--- /dev/null
+++ b/rtems/config/4.12/rtems-autotools-base.bset
@@ -0,0 +1,23 @@
+#
+# Tools Set for RTEMS 4.12 Internal Autotools Stable
+#
+
+%define release 1
+
+%define rtems_arch none
+
+#
+# The RTEMS 4.12 base defines.
+#
+%include rtems-4.12-base.bset
+
+#
+# The autotools package.
+#
+package: rtems-%{rtems_version}-autotools-%{_host}-%{release}
+
+#
+# Tools configuration.
+#
+tools/rtems-autoconf-2.69-1
+tools/rtems-automake-1.12.6-1
diff --git a/rtems/config/4.12/rtems-autotools-internal.bset 
b/rtems/config/4.12/rtems-autotools-internal.bset
new file mode 100644
index 000..772c032
--- /dev/null
+++ b/rtems/config/4.12/rtems-autotools-internal.bset
@@ -0,0 +1,13 @@
+#
+# Tools Set for RTEMS 4.12 Internal Autotools Stable
+#
+# Do not use via the command line.
+#
+
+%define _internal_autotools yes
+%define _disable_collecting yes
+%define 

[PATCH] Add RTEMS linker sets

[Sebastian Huber]

Update #2408.
---
 c/src/lib/libbsp/arm/gba/startup/linkcmds  |   2 +
 c/src/lib/libbsp/avr/avrtest/startup/linkcmds  |   2 +
 c/src/lib/libbsp/bfin/TLL6527M/startup/linkcmds|   2 +
 c/src/lib/libbsp/bfin/bf537Stamp/startup/linkcmds  |   2 +
 c/src/lib/libbsp/bfin/eZKit533/startup/linkcmds|   2 +
 c/src/lib/libbsp/h8300/h8sim/startup/linkcmds  |   2 +
 c/src/lib/libbsp/lm32/lm32_evr/startup/linkcmds|   3 +-
 c/src/lib/libbsp/lm32/milkymist/startup/linkcmds   |   3 +-
 c/src/lib/libbsp/m32c/m32cbsp/startup/linkcmds |   3 +-
 c/src/lib/libbsp/m32r/m32rsim/startup/linkcmds |   3 +-
 c/src/lib/libbsp/m68k/av5282/startup/linkcmds  |   2 +
 c/src/lib/libbsp/m68k/av5282/startup/linkcmdsflash |   2 +
 c/src/lib/libbsp/m68k/av5282/startup/linkcmdsram   |   2 +
 c/src/lib/libbsp/m68k/csb360/startup/linkcmds  |   2 +
 c/src/lib/libbsp/m68k/gen68302/startup/linkcmds|   2 +
 c/src/lib/libbsp/m68k/gen68340/startup/linkcmds|   2 +
 c/src/lib/libbsp/m68k/gen68360/startup/linkcmds|   2 +
 .../libbsp/m68k/gen68360/startup/linkcmds.bootp|   2 +
 .../lib/libbsp/m68k/gen68360/startup/linkcmds.prom |   2 +
 c/src/lib/libbsp/m68k/idp/startup/linkcmds |   2 +
 .../lib/libbsp/m68k/mcf5206elite/startup/linkcmds  |   2 +
 .../m68k/mcf5206elite/startup/linkcmds.flash   |   2 +
 c/src/lib/libbsp/m68k/mcf52235/startup/linkcmds|   2 +
 c/src/lib/libbsp/m68k/mcf5225x/startup/linkcmds|   2 +
 c/src/lib/libbsp/m68k/mcf5235/startup/linkcmds |   2 +
 .../lib/libbsp/m68k/mcf5235/startup/linkcmdsflash  |   2 +
 c/src/lib/libbsp/m68k/mcf5235/startup/linkcmdsram  |   2 +
 c/src/lib/libbsp/m68k/mcf5329/startup/linkcmds |   2 +
 .../lib/libbsp/m68k/mcf5329/startup/linkcmdsflash  |   2 +
 c/src/lib/libbsp/m68k/mrm332/startup/linkcmds  |   2 +
 c/src/lib/libbsp/m68k/mvme136/startup/linkcmds |   2 +
 c/src/lib/libbsp/m68k/mvme147/startup/linkcmds |   2 +
 c/src/lib/libbsp/m68k/mvme147s/startup/linkcmds|   2 +
 c/src/lib/libbsp/m68k/mvme162/startup/linkcmds |   2 +
 c/src/lib/libbsp/m68k/mvme167/startup/linkcmds |   2 +
 c/src/lib/libbsp/m68k/ods68302/startup/debugger|   2 +
 c/src/lib/libbsp/m68k/ods68302/startup/linkcmds|   2 +
 c/src/lib/libbsp/m68k/ods68302/startup/rom |   2 +
 c/src/lib/libbsp/m68k/sim68000/startup/linkcmds|   2 +
 c/src/lib/libbsp/m68k/uC5282/startup/linkcmds  |   2 +
 c/src/lib/libbsp/mips/csb350/startup/linkcmds  |   2 +
 .../lib/libbsp/mips/genmongoosev/startup/linkcmds  |   2 +
 c/src/lib/libbsp/mips/hurricane/startup/linkcmds   |   2 +
 c/src/lib/libbsp/mips/rbtx4925/startup/linkcmds|   2 +
 c/src/lib/libbsp/mips/rbtx4938/startup/linkcmds|   2 +
 c/src/lib/libbsp/moxie/moxiesim/startup/linkcmds   |   3 +-
 c/src/lib/libbsp/nios2/nios2_iss/startup/linkcmds  |   3 +-
 c/src/lib/libbsp/powerpc/beatnik/startup/linkcmds  |   3 +-
 c/src/lib/libbsp/powerpc/ep1a/startup/linkcmds |   3 +-
 .../libbsp/powerpc/gen5200/startup/linkcmds.base   |   2 +
 .../lib/libbsp/powerpc/haleakala/startup/linkcmds  |   2 +
 c/src/lib/libbsp/powerpc/mbx8xx/startup/linkcmds   |   2 +
 .../lib/libbsp/powerpc/mpc8260ads/startup/linkcmds |   2 +
 c/src/lib/libbsp/powerpc/qemuppc/startup/linkcmds  |   3 +-
 .../lib/libbsp/powerpc/score603e/startup/linkcmds  |   3 +-
 c/src/lib/libbsp/powerpc/shared/startup/linkcmds   |   3 +-
 c/src/lib/libbsp/powerpc/ss555/startup/linkcmds|   2 +
 .../libbsp/powerpc/tqm8xx/startup/linkcmds.base|   3 +-
 c/src/lib/libbsp/powerpc/virtex4/startup/linkcmds  |   3 +-
 c/src/lib/libbsp/powerpc/virtex5/startup/linkcmds  |   3 +-
 c/src/lib/libbsp/sh/gensh1/startup/linkcmds|   3 +-
 c/src/lib/libbsp/sh/gensh2/startup/linkcmds|   3 +-
 c/src/lib/libbsp/sh/gensh2/startup/linkcmds.ram|   3 +-
 c/src/lib/libbsp/sh/gensh2/startup/linkcmds.rom|   3 +-
 c/src/lib/libbsp/sh/gensh4/startup/linkcmds|   2 +
 c/src/lib/libbsp/sh/gensh4/startup/linkcmds.rom|   2 +
 .../lib/libbsp/sh/gensh4/startup/linkcmds.rom2ram  |   2 +
 c/src/lib/libbsp/sh/shsim/startup/linkcmds.sim |   3 +-
 c/src/lib/libbsp/sparc64/shared/startup/linkcmds   |   2 +
 c/src/lib/libbsp/v850/gdbv850sim/startup/linkcmds  |   3 +-
 cpukit/score/Makefile.am   |   1 +
 cpukit/score/include/rtems/score/basedefs.h|  39 +++
 cpukit/score/include/rtems/score/linkerset.h   |  76 ++
 cpukit/score/preinstall.am |   4 +
 testsuites/sptests/Makefile.am |   1 +
 testsuites/sptests/configure.ac|   1 +
 testsuites/sptests/splinkerset01/Makefile.am   |  20 
 testsuites/sptests/splinkerset01/init.c| 115 +
 testsuites/sptests/splinkerset01/sets.c|  23 +
 testsuites/sptests/splinkerset01/splinkerset01.doc |  18 
 testsuites/sptests/splinkerset01/splinkerset01.h   |  32 ++
 

Re: [PATCH] Fix exception handler for supporting FPU

[Sebastian Huber]

On 07/10/15 09:04, Chris Johns wrote:

On 7/10/2015 4:33 pm, Sebastian Huber wrote:

>
>
>On 07/10/15 05:13, Chris Johns wrote:

>>On 23/09/2015 11:33 am, Gedare Bloom wrote:

>>> >ping. i will try to get to this tomorrow if no one else does.

>>What happened to this change?

>
>https://lists.rtems.org/pipermail/devel/2015-September/012612.html
>

Ah yes I remember now and why I could not find them on 4.11 branch. Are
they ok for 4.11?


I don't know. I wait for feedback.

--
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 3/3] C11 threads support

[Sebastian Huber]

Hello Jeff,

I sent the RTEMS implementation of this API to the RTEMS list only:

https://lists.rtems.org/pipermail/devel/2015-September/012597.html
https://lists.rtems.org/pipermail/devel/2015-September/012598.html

It is a slight modification of the FreeBSD libstdthreads. The original 
FreeBSD implementation uses , so it would be possible to add 
this as a default implementation for Newlib. I am not sure how to 
integrate this in the build system. If desired, this could be done in a 
second step.


On 08/10/15 00:04, Jeff Johnston wrote:

I am ok with this although I would like to hear that at least RTEMS or another 
configuration
supports or plans to support threads.h and functions.  C11 says that the flag 
__STDC_NO_THREADS__
can be used to indicate that threads.h and the functions are missing.


--
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 5/6] basdefs.h: Add and use RTEMS_UNUSED

[Sebastian Huber]

---
 .../libbsp/arm/shared/lpc/network/lpc-ethernet.c   |  6 ++--
 c/src/lib/libbsp/i386/pc386/console/fb_cirrus.c|  2 +-
 c/src/lib/libbsp/i386/shared/comm/uart.c   |  2 +-
 .../libbsp/powerpc/beatnik/network/if_em/if_em.c   |  2 +-
 .../lib/libbsp/powerpc/virtex4/startup/bspstart.c  |  4 +--
 .../lib/libbsp/powerpc/virtex5/startup/bspstart.c  |  4 +--
 c/src/lib/libbsp/sparc/shared/can/grcan.c  |  2 +-
 cpukit/ftpd/ftpd.c |  2 +-
 cpukit/libblock/src/bdpart-mount.c |  4 +--
 cpukit/libblock/src/bdpart-register.c  |  2 +-
 cpukit/libblock/src/blkdev.c   | 16 +--
 cpukit/libblock/src/flashdisk.c|  2 +-
 cpukit/libblock/src/media-server.c |  2 +-
 cpukit/libblock/src/media.c| 10 +++
 cpukit/libblock/src/nvdisk-sram.c  | 12 
 cpukit/libblock/src/nvdisk.c   |  2 +-
 cpukit/libblock/src/ramdisk-config.c   |  4 +--
 cpukit/libcsupport/src/__gettod.c  |  4 +--
 cpukit/libcsupport/src/__times.c   |  2 +-
 cpukit/libcsupport/src/_calloc_r.c |  3 +-
 cpukit/libcsupport/src/_free_r.c   |  3 +-
 cpukit/libcsupport/src/_malloc_r.c |  3 +-
 cpukit/libcsupport/src/_realloc_r.c|  3 +-
 cpukit/libcsupport/src/_rename_r.c |  2 +-
 cpukit/libcsupport/src/assocnamebad.c  |  2 +-
 cpukit/libcsupport/src/close.c |  2 +-
 cpukit/libcsupport/src/envlock.c   |  4 +--
 cpukit/libcsupport/src/fcntl.c |  2 +-
 cpukit/libcsupport/src/flockfile.c |  3 +-
 cpukit/libcsupport/src/fstat.c |  2 +-
 cpukit/libcsupport/src/ftrylockfile.c  |  3 +-
 cpukit/libcsupport/src/funlockfile.c   |  3 +-
 cpukit/libcsupport/src/getpid.c|  2 +-
 cpukit/libcsupport/src/isatty_r.c  |  3 +-
 cpukit/libcsupport/src/link.c  |  2 +-
 cpukit/libcsupport/src/lseek.c |  2 +-
 cpukit/libcsupport/src/newlibc_reent.c |  2 +-
 cpukit/libcsupport/src/open.c  |  2 +-
 cpukit/libcsupport/src/printk_plugin.c |  4 ++-
 cpukit/libcsupport/src/read.c  |  2 +-
 cpukit/libcsupport/src/rtems_heap_null_extend.c|  4 +--
 cpukit/libcsupport/src/setpgid.c   |  6 ++--
 cpukit/libcsupport/src/stat.c  |  4 +--
 cpukit/libcsupport/src/tcflow.c|  4 ++-
 cpukit/libcsupport/src/tcgetpgrp.c |  3 +-
 cpukit/libcsupport/src/tcsendbreak.c   |  4 +--
 cpukit/libcsupport/src/tcsetpgrp.c |  4 +--
 cpukit/libcsupport/src/unlink.c|  2 +-
 cpukit/libcsupport/src/write_r.c   |  2 +-
 cpukit/libfs/src/nfsclient/src/dirutils.c  |  2 +-
 cpukit/libmisc/capture/capture-cli.c   |  2 +-
 cpukit/libmisc/capture/capture.c   |  2 +-
 cpukit/libmisc/devnull/devnull.c   | 32 +++---
 cpukit/libmisc/devnull/devzero.c   | 32 +++---
 cpukit/libmisc/fb/mw_uid.c |  2 +-
 cpukit/libmisc/monitor/mon-command.c   |  2 +-
 cpukit/libmisc/monitor/mon-config.c|  8 +++---
 cpukit/libmisc/monitor/mon-driver.c|  4 +--
 cpukit/libmisc/monitor/mon-extension.c |  2 +-
 cpukit/libmisc/monitor/mon-itask.c |  4 +--
 cpukit/libmisc/monitor/mon-monitor.c   | 26 +-
 cpukit/libmisc/monitor/mon-network.c   |  8 +++---
 cpukit/libmisc/monitor/mon-part.c  |  4 +--
 cpukit/libmisc/monitor/mon-queue.c |  4 +--
 cpukit/libmisc/monitor/mon-region.c|  4 +--
 cpukit/libmisc/monitor/mon-sema.c  |  4 +--
 cpukit/libmisc/monitor/mon-server.c|  4 +--
 cpukit/libmisc/monitor/mon-symbols.c   |  4 +--
 cpukit/libmisc/monitor/mon-task.c  |  4 +--
 cpukit/libmisc/serdbg/termios_printk.c |  2 +-
 cpukit/libmisc/shell/cmds.c|  2 +-
 cpukit/libmisc/shell/err.h |  1 +
 cpukit/libmisc/shell/extern-cp.h   |  1 +
 cpukit/libmisc/shell/extern-ls.h   |  1 +
 cpukit/libmisc/shell/hexdump-odsyntax.c|  2 +-
 cpukit/libmisc/shell/main_dd.c |  2 +-
 cpukit/libmisc/shell/main_halt.c   |  4 +--
 cpukit/libmisc/shell/main_id.c |  4 +--
 cpukit/libmisc/shell/main_logoff.c |  4 +--
 cpukit/libmisc/shell/main_mount_nfs.c  |  4 +--
 cpukit/libmisc/shell/main_pwd.c|  4 +--
 

[PATCH 4/6] basdefs.h: Add and use RTEMS_DEPRECATED

[Sebastian Huber]

---
 c/src/librtems++/include/rtems++/rtemsTask.h   |  4 ++--
 cpukit/libblock/include/rtems/ide_part_table.h |  6 +++---
 cpukit/rtems/include/rtems/rtems/clock.h   |  2 +-
 cpukit/rtems/include/rtems/rtems/tasks.h   | 12 ++--
 cpukit/rtems/include/rtems/rtems/tasksimpl.h   |  2 +-
 cpukit/sapi/include/confdefs.h |  2 +-
 cpukit/sapi/include/rtems/extension.h  |  2 +-
 cpukit/sapi/include/rtems/io.h |  2 +-
 cpukit/score/include/rtems/score/basedefs.h|  8 +---
 cpukit/score/include/rtems/score/userext.h |  2 +-
 10 files changed, 22 insertions(+), 20 deletions(-)

diff --git a/c/src/librtems++/include/rtems++/rtemsTask.h 
b/c/src/librtems++/include/rtems++/rtemsTask.h
index 6a500b0..3aac25d 100644
--- a/c/src/librtems++/include/rtems++/rtemsTask.h
+++ b/c/src/librtems++/include/rtems++/rtemsTask.h
@@ -127,9 +127,9 @@ public:
 
   // notepad control
   const rtems_status_code get_note(const uint32_t notepad,
-   uint32_t& note) 
RTEMS_COMPILER_DEPRECATED_ATTRIBUTE;
+   uint32_t& note) RTEMS_DEPRECATED;
   const rtems_status_code set_note(const uint32_t notepad,
-   const uint32_t note) 
RTEMS_COMPILER_DEPRECATED_ATTRIBUTE;
+   const uint32_t note) RTEMS_DEPRECATED;
 
   // object id, and name
   const rtems_id id_is() const { return id; }
diff --git a/cpukit/libblock/include/rtems/ide_part_table.h 
b/cpukit/libblock/include/rtems/ide_part_table.h
index 261135c..c638e28 100644
--- a/cpukit/libblock/include/rtems/ide_part_table.h
+++ b/cpukit/libblock/include/rtems/ide_part_table.h
@@ -167,7 +167,7 @@ extern "C" {
  */
 void rtems_ide_part_table_free(
   rtems_disk_desc_t *disk_desc
-) RTEMS_COMPILER_DEPRECATED_ATTRIBUTE;
+) RTEMS_DEPRECATED;
 
 
 /*
@@ -188,7 +188,7 @@ void rtems_ide_part_table_free(
 rtems_status_code rtems_ide_part_table_get(
   const char *dev_name,
   rtems_disk_desc_t *disk_desc
-) RTEMS_COMPILER_DEPRECATED_ATTRIBUTE;
+) RTEMS_DEPRECATED;
 
 
 /*
@@ -206,7 +206,7 @@ rtems_status_code rtems_ide_part_table_get(
  */
 rtems_status_code rtems_ide_part_table_initialize(
   const char *dev_name
-) RTEMS_COMPILER_DEPRECATED_ATTRIBUTE;
+) RTEMS_DEPRECATED;
 
 #ifdef __cplusplus
 }
diff --git a/cpukit/rtems/include/rtems/rtems/clock.h 
b/cpukit/rtems/include/rtems/rtems/clock.h
index 18bbc62..453d001 100644
--- a/cpukit/rtems/include/rtems/rtems/clock.h
+++ b/cpukit/rtems/include/rtems/rtems/clock.h
@@ -91,7 +91,7 @@ typedef enum {
 rtems_status_code rtems_clock_get(
   rtems_clock_get_options  option,
   void*time_buffer
-) RTEMS_COMPILER_DEPRECATED_ATTRIBUTE;
+) RTEMS_DEPRECATED;
 
 /**
  * @brief Obtain Current Time of Day (Classic TOD)
diff --git a/cpukit/rtems/include/rtems/rtems/tasks.h 
b/cpukit/rtems/include/rtems/rtems/tasks.h
index dc12d0b..1ad537d 100644
--- a/cpukit/rtems/include/rtems/rtems/tasks.h
+++ b/cpukit/rtems/include/rtems/rtems/tasks.h
@@ -287,7 +287,7 @@ rtems_status_code rtems_task_get_note(
   rtems_idid,
   uint32_tnotepad,
   uint32_t   *note
-) RTEMS_COMPILER_DEPRECATED_ATTRIBUTE;
+) RTEMS_DEPRECATED;
 
 /**
  * @brief RTEMS Set Task Note
@@ -310,7 +310,7 @@ rtems_status_code rtems_task_set_note(
   rtems_id   id,
   uint32_t   notepad,
   uint32_t   note
-) RTEMS_COMPILER_DEPRECATED_ATTRIBUTE;
+) RTEMS_DEPRECATED;
 
 /**
  * @brief RTEMS Task Mode
@@ -472,7 +472,7 @@ rtems_status_code rtems_task_variable_add(
   rtems_id  tid,
   void**ptr,
   void(*dtor)(void *)
-) RTEMS_COMPILER_DEPRECATED_ATTRIBUTE;
+) RTEMS_DEPRECATED;
 
 /**
  *  @brief Get a per-task variable
@@ -487,7 +487,7 @@ rtems_status_code rtems_task_variable_get(
   rtems_id tid,
   void **ptr,
   void **result
-) RTEMS_COMPILER_DEPRECATED_ATTRIBUTE;
+) RTEMS_DEPRECATED;
 
 /**
  *  @brief RTEMS Delete Task Variable
@@ -501,7 +501,7 @@ rtems_status_code rtems_task_variable_get(
 rtems_status_code rtems_task_variable_delete(
   rtems_id  tid,
   void**ptr
-) RTEMS_COMPILER_DEPRECATED_ATTRIBUTE;
+) RTEMS_DEPRECATED;
 #endif
 
 #if defined(__RTEMS_HAVE_SYS_CPUSET_H__)
@@ -678,7 +678,7 @@ typedef struct {
*
*  @note MUST BE LAST ENTRY.
*/
-  uint32_t Notepads[ RTEMS_ZERO_LENGTH_ARRAY ] 
RTEMS_COMPILER_DEPRECATED_ATTRIBUTE;
+  uint32_t Notepads[ RTEMS_ZERO_LENGTH_ARRAY ] RTEMS_DEPRECATED;
 }  RTEMS_API_Control;
 
 /**
diff --git a/cpukit/rtems/include/rtems/rtems/tasksimpl.h 
b/cpukit/rtems/include/rtems/rtems/tasksimpl.h
index d35f681..5a493d7 100644
--- a/cpukit/rtems/include/rtems/rtems/tasksimpl.h
+++ b/cpukit/rtems/include/rtems/rtems/tasksimpl.h
@@ -78,7 +78,7 @@ void _RTEMS_tasks_Initialize_user_tasks( void );
 void _RTEMS_Tasks_Invoke_task_variable_dtor(
   Thread_Control*the_thread,
   rtems_task_variable_t *tvp
-) RTEMS_COMPILER_DEPRECATED_ATTRIBUTE;
+) RTEMS_DEPRECATED;
 #endif
 
 RTEMS_INLINE_ROUTINE Thread_Control *_RTEMS_tasks_Allocate(void)

[PATCH 2/6] basedefs.h: Add and use RTEMS_NO_RETURN

[Sebastian Huber]

---
 c/src/lib/libbsp/shared/include/bootcard.h|  2 +-
 c/src/lib/libbsp/shared/include/fatal.h   |  2 +-
 c/src/lib/libbsp/sparc/leon3/include/leon.h   |  2 +-
 cpukit/libcsupport/include/rtems/error.h  |  2 +-
 cpukit/libmisc/stackchk/check.c   |  2 +-
 cpukit/sapi/include/rtems/fatal.h |  6 +++---
 cpukit/sapi/include/rtems/init.h  |  4 ++--
 cpukit/score/cpu/arm/rtems/score/cpu.h|  4 ++--
 cpukit/score/cpu/avr/rtems/score/cpu.h|  2 +-
 cpukit/score/cpu/bfin/rtems/score/cpu.h   |  2 +-
 cpukit/score/cpu/epiphany/rtems/score/cpu.h   |  2 +-
 cpukit/score/cpu/h8300/rtems/score/cpu.h  |  2 +-
 cpukit/score/cpu/i386/rtems/score/cpu.h   |  2 +-
 cpukit/score/cpu/lm32/rtems/score/cpu.h   |  2 +-
 cpukit/score/cpu/m32c/rtems/score/cpu.h   |  4 ++--
 cpukit/score/cpu/m32r/rtems/score/cpu.h   |  4 ++--
 cpukit/score/cpu/m68k/rtems/score/cpu.h   |  2 +-
 cpukit/score/cpu/mips/rtems/score/cpu.h   |  2 +-
 cpukit/score/cpu/moxie/rtems/score/cpu.h  |  2 +-
 cpukit/score/cpu/nios2/rtems/score/cpu.h  |  4 ++--
 cpukit/score/cpu/no_cpu/rtems/score/cpu.h |  2 +-
 cpukit/score/cpu/or1k/rtems/score/cpu.h   |  2 +-
 cpukit/score/cpu/powerpc/rtems/score/cpu.h|  2 +-
 cpukit/score/cpu/sh/rtems/score/cpu.h |  2 +-
 cpukit/score/cpu/sparc/rtems/score/cpu.h  |  4 ++--
 cpukit/score/cpu/sparc/rtems/score/sparc.h|  2 +-
 cpukit/score/cpu/sparc64/rtems/score/cpu.h|  2 +-
 cpukit/score/cpu/v850/rtems/score/cpu.h   |  2 +-
 cpukit/score/include/rtems/score/assert.h |  2 +-
 cpukit/score/include/rtems/score/basedefs.h   | 10 ++
 cpukit/score/include/rtems/score/interr.h |  2 +-
 cpukit/score/include/rtems/score/smpimpl.h|  2 +-
 cpukit/score/include/rtems/score/threadimpl.h |  2 +-
 33 files changed, 46 insertions(+), 44 deletions(-)

diff --git a/c/src/lib/libbsp/shared/include/bootcard.h 
b/c/src/lib/libbsp/shared/include/bootcard.h
index c394602..53a1844 100644
--- a/c/src/lib/libbsp/shared/include/bootcard.h
+++ b/c/src/lib/libbsp/shared/include/bootcard.h
@@ -100,7 +100,7 @@ void bsp_reset(void);
  * This style of initialization ensures that the C++ global constructors are
  * executed after RTEMS is initialized.
  */
-void boot_card(const char *cmdline) RTEMS_COMPILER_NO_RETURN_ATTRIBUTE;
+void boot_card(const char *cmdline) RTEMS_NO_RETURN;
 
 #ifdef CONFIGURE_MALLOC_BSP_SUPPORTS_SBRK
   /**
diff --git a/c/src/lib/libbsp/shared/include/fatal.h 
b/c/src/lib/libbsp/shared/include/fatal.h
index 45db9d4..fe8e14e9 100644
--- a/c/src/lib/libbsp/shared/include/fatal.h
+++ b/c/src/lib/libbsp/shared/include/fatal.h
@@ -117,7 +117,7 @@ typedef enum {
   QORIQ_FATAL_SMP_IPI_HANDLER_INSTALL = BSP_FATAL_CODE_BLOCK(10)
 } bsp_fatal_code;
 
-RTEMS_COMPILER_NO_RETURN_ATTRIBUTE static inline void
+RTEMS_NO_RETURN static inline void
 bsp_fatal( bsp_fatal_code code )
 {
   rtems_fatal( RTEMS_FATAL_SOURCE_BSP, (rtems_fatal_code) code );
diff --git a/c/src/lib/libbsp/sparc/leon3/include/leon.h 
b/c/src/lib/libbsp/sparc/leon3/include/leon.h
index 8ad8a18..5ac1d71 100644
--- a/c/src/lib/libbsp/sparc/leon3/include/leon.h
+++ b/c/src/lib/libbsp/sparc/leon3/include/leon.h
@@ -376,7 +376,7 @@ void leon3_ext_irq_init(void);
 
 void bsp_debug_uart_init(void);
 
-void leon3_power_down_loop(void) RTEMS_COMPILER_NO_RETURN_ATTRIBUTE;
+void leon3_power_down_loop(void) RTEMS_NO_RETURN;
 
 static inline uint32_t leon3_get_cpu_count(
   volatile struct irqmp_regs *irqmp
diff --git a/cpukit/libcsupport/include/rtems/error.h 
b/cpukit/libcsupport/include/rtems/error.h
index c81cc66..f72d78c 100644
--- a/cpukit/libcsupport/include/rtems/error.h
+++ b/cpukit/libcsupport/include/rtems/error.h
@@ -130,7 +130,7 @@ int rtems_verror(
 void rtems_panic(
   const char *printf_format,
   ...
-) RTEMS_COMPILER_NO_RETURN_ATTRIBUTE;
+) RTEMS_NO_RETURN;
 
 extern int rtems_panic_in_progress;
 
diff --git a/cpukit/libmisc/stackchk/check.c b/cpukit/libmisc/stackchk/check.c
index dd64968..a442798 100644
--- a/cpukit/libmisc/stackchk/check.c
+++ b/cpukit/libmisc/stackchk/check.c
@@ -223,7 +223,7 @@ void rtems_stack_checker_begin_extension(
 void Stack_check_report_blown_task(
   Thread_Control *running,
   bool pattern_ok
-) RTEMS_COMPILER_NO_RETURN_ATTRIBUTE;
+) RTEMS_NO_RETURN;
 
 void Stack_check_report_blown_task(Thread_Control *running, bool pattern_ok)
 {
diff --git a/cpukit/sapi/include/rtems/fatal.h 
b/cpukit/sapi/include/rtems/fatal.h
index 6e5986a..b4b3b0f 100644
--- a/cpukit/sapi/include/rtems/fatal.h
+++ b/cpukit/sapi/include/rtems/fatal.h
@@ -16,7 +16,7 @@
 #ifndef _RTEMS_FATAL_H
 #define _RTEMS_FATAL_H
 
-#include  /* RTEMS_COMPILER_NO_RETURN_ATTRIBUTE */
+#include  /* RTEMS_NO_RETURN */
 #include 
 
 #ifdef __cplusplus
@@ -70,7 +70,7 @@ static inline void rtems_exception_frame_print(
  */
 void rtems_fatal_error_occurred(
   uint32_t   the_error
-) RTEMS_COMPILER_NO_RETURN_ATTRIBUTE;
+) RTEMS_NO_RETURN;
 
 /**

[PATCH 6/6] basdefs.h: Add and use RTEMS_PACKED

[Sebastian Huber]

---
 c/src/lib/libbsp/i386/pc386/include/edid.h   | 20 ++--
 c/src/lib/libbsp/i386/pc386/include/vbe3.h   | 14 +++---
 .../libbsp/i386/shared/realmode_int/realmode_int.c   |  4 ++--
 .../libbsp/i386/shared/realmode_int/realmode_int.h   |  2 +-
 c/src/lib/libcpu/i386/cpu.h  |  2 +-
 cpukit/score/include/rtems/score/basedefs.h  |  7 +--
 6 files changed, 26 insertions(+), 23 deletions(-)

diff --git a/c/src/lib/libbsp/i386/pc386/include/edid.h 
b/c/src/lib/libbsp/i386/pc386/include/edid.h
index 1120296..b8c00b1 100644
--- a/c/src/lib/libbsp/i386/pc386/include/edid.h
+++ b/c/src/lib/libbsp/i386/pc386/include/edid.h
@@ -87,7 +87,7 @@ typedef struct {
 uint8_t HorizontalBorder;
 uint8_t VerticalBorder;
 uint8_t Flags;
-} RTEMS_COMPILER_PACKED_ATTRIBUTE EDID_detailed_timing_descriptor;
+} RTEMS_PACKED EDID_detailed_timing_descriptor;
 
 EDID_INLINE_ROUTINE uint16_t DTD_horizontal_active (
 EDID_detailed_timing_descriptor *dtd)
@@ -165,7 +165,7 @@ typedef struct {
 uint8_t ColorPointWhite_x;
 uint8_t ColorPointWhite_y;
 uint8_t ColorPointWhiteGamma;
-} RTEMS_COMPILER_PACKED_ATTRIBUTE EDID_color_point_data;
+} RTEMS_PACKED EDID_color_point_data;
 
 /* Basic Display Parameters */
 /* Monitor Descriptor - Data Type Tag */
@@ -183,7 +183,7 @@ typedef struct {
 /* see  VESA, Generalized Timing Formula Standard - GTF
 Version 1.0, December 18, 1996 */
 uint8_t GTFStandard[8];
-} RTEMS_COMPILER_PACKED_ATTRIBUTE EDID_monitor_range_limits;
+} RTEMS_PACKED EDID_monitor_range_limits;
 
 #define EDID_DTT_MonitorName0xFC
 
@@ -225,11 +225,11 @@ typedef struct {
 uint8_t AddressableLinesLow;
 uint8_t AspectRatio_AddressableLinesHigh;
 uint8_t VerticalRate_PreferredVerticalRate;
-} RTEMS_COMPILER_PACKED_ATTRIBUTE EDID_CVT_3_byte_code_descriptor;
+} RTEMS_PACKED EDID_CVT_3_byte_code_descriptor;
 typedef struct {
 uint8_t VersionNumber;
 EDID_CVT_3_byte_code_descriptor cvt[4];
-} RTEMS_COMPILER_PACKED_ATTRIBUTE EDID_CVT_timing_codes_3B;
+} RTEMS_PACKED EDID_CVT_timing_codes_3B;
 
 EDID_INLINE_ROUTINE uint16_t edid1_CVT_addressable_lines_high (
 EDID_CVT_3_byte_code_descriptor *cvt)
@@ -251,7 +251,7 @@ EDID_INLINE_ROUTINE uint8_t edid1_CVT_aspect_ratio (
 typedef struct {
 uint8_t RevisionNumber;
 uint8_t EST_III[12];
-} RTEMS_COMPILER_PACKED_ATTRIBUTE EDID_established_timings_III;
+} RTEMS_PACKED EDID_established_timings_III;
 enum EST_III {
 EST_1152x864_75Hz   = 0,
 EST_1024x768_85Hz   = 1,
@@ -313,12 +313,12 @@ typedef struct {
 uint8_t DataTypeTag;
 uint8_t Flag2;
 uint8_t DescriptorData[13];
-} RTEMS_COMPILER_PACKED_ATTRIBUTE EDID_monitor_descriptor;
+} RTEMS_PACKED EDID_monitor_descriptor;
 
 union EDID_DTD_MD {
 EDID_detailed_timing_descriptor dtd;
 EDID_monitor_descriptor md;
-} RTEMS_COMPILER_PACKED_ATTRIBUTE;
+} RTEMS_PACKED;
 
 #define EDID1_STI_ImageAspectRatioOff   0
 #define EDID1_STI_ImageAspectRatioMask  0x3
@@ -333,7 +333,7 @@ union EDID_DTD_MD {
 typedef struct {
 uint8_t HorizontalActivePixels;
 uint8_t ImageAspectRatio_RefreshRate;
-} RTEMS_COMPILER_PACKED_ATTRIBUTE EDID_standard_timing_identification;
+} RTEMS_PACKED EDID_standard_timing_identification;
 
 /* Video Input Definition */
 /* Analog = 0, Digital = 1 */
@@ -446,7 +446,7 @@ typedef struct {
 union EDID_DTD_MD dtd_md[4];
 uint8_t ExtensionFlag;
 uint8_t Checksum;
-} RTEMS_COMPILER_PACKED_ATTRIBUTE EDID_edid1;
+} RTEMS_PACKED EDID_edid1;
 
 EDID_INLINE_ROUTINE uint16_t edid1_RedX (EDID_edid1 *edid) {
 return (edid->RedXHigh<<2) | (edid->GreenRedLow>>6);
diff --git a/c/src/lib/libbsp/i386/pc386/include/vbe3.h 
b/c/src/lib/libbsp/i386/pc386/include/vbe3.h
index 06f614f..b62ab6f 100644
--- a/c/src/lib/libbsp/i386/pc386/include/vbe3.h
+++ b/c/src/lib/libbsp/i386/pc386/include/vbe3.h
@@ -179,7 +179,7 @@ typedef struct {
 /** @brief Selector or Segment depending on whether this is used from 16bit
 protected mode or from real mode. */
 uint16_t selector;
-} RTEMS_COMPILER_PACKED_ATTRIBUTE VBE_far_pointer;
+} RTEMS_PACKED VBE_far_pointer;
 
 /**
  * @brief Protected mode info block as defined by VBE standard.
@@ -205,7 +205,7 @@ typedef struct {
 uint8_t   InProtectMode;
 /** Checksum byte for structure. Sum over all structure bytes gives 0. */
 uint8_t   Checksum;
-} RTEMS_COMPILER_PACKED_ATTRIBUTE VBE_protected_mode_info_block;
+} RTEMS_PACKED VBE_protected_mode_info_block;
 
 /** General VBE signature */
 #define VBE_SIGNATURE "VESA"
@@ -243,7 +243,7 @@ typedef struct {
 uint8_t   Reserved[222];
 /** Data Area for OEM Strings */
 uint8_t   OemData[256];
-} RTEMS_COMPILER_PACKED_ATTRIBUTE VBE_vbe_info_block;
+} RTEMS_PACKED VBE_vbe_info_block;
 
 /**
  * @brief Describes graphic's mode parameter.
@@ -345,7 +345,7 @@ typedef struct {
 uint32_t  MaxPixelClock;
 /** remainder of 

[PATCH 1/6] basedefs.h: Add compiler attributes

[Sebastian Huber]

---
 cpukit/score/include/rtems/score/basedefs.h | 41 -
 1 file changed, 40 insertions(+), 1 deletion(-)

diff --git a/cpukit/score/include/rtems/score/basedefs.h 
b/cpukit/score/include/rtems/score/basedefs.h
index 695ab8f..8e145f5 100644
--- a/cpukit/score/include/rtems/score/basedefs.h
+++ b/cpukit/score/include/rtems/score/basedefs.h
@@ -10,7 +10,7 @@
  *  COPYRIGHT (c) 1989-2007.
  *  On-Line Applications Research Corporation (OAR).
  *
- *  Copyright (c) 2010 embedded brains GmbH.
+ *  Copyright (c) 2010-2015 embedded brains GmbH.
  *
  *  The license and distribution terms for this file may be
  *  found in the file LICENSE in this distribution or at
@@ -187,6 +187,25 @@
 #endif
 
 /**
+ * @brief Instructs the compiler to place a specific variable or function in
+ * the specified section.
+ */
+#if defined(__GNUC__)
+  #define RTEMS_SECTION( _section ) __attribute__((__section__(_section)))
+#else
+  #define RTEMS_SECTION( _section )
+#endif
+
+/**
+ * @brief Instructs the compiler that a specific variable or function is used.
+ */
+#if defined(__GNUC__)
+  #define RTEMS_USED __attribute__((__used__))
+#else
+  #define RTEMS_USED
+#endif
+
+/**
  *  Instructs the compiler that a specific variable is deliberately unused.
  *  This can occur when reading volatile device memory or skipping arguments
  *  in a variable argument method.
@@ -316,6 +335,26 @@ extern void RTEMS_DEQUALIFY_types_not_compatible(void);
 #endif /*RTEMS_DEQUALIFY_DEPTHX*/
 #endif /*RTEMS_DEQUALIFY*/
 
+/**
+ * @brief Concatenates _x and _y without expanding.
+ */
+#define RTEMS_CONCAT( _x, _y ) _x##_y
+
+/**
+ * @brief Concatenates expansion of _x and expansion of _y.
+ */
+#define RTEMS_XCONCAT( _x, _y ) RTEMS_CONCAT( _x, _y )
+
+/**
+ * @brief Stringifies _x  without expanding.
+ */
+#define RTEMS_STRING( _x ) #_x
+
+/**
+ * @brief Stringifies expansion of _x.
+ */
+#define RTEMS_XSTRING( _x ) RTEMS_STRING( _x )
+
 #ifndef ASM
   #ifdef RTEMS_DEPRECATED_TYPES
 typedef bool boolean;
-- 
1.8.4.5

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

[PATCH 3/6] basdefs.h: Add RTEMS_PURE

[Sebastian Huber]

---
 cpukit/score/include/rtems/score/basedefs.h | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/cpukit/score/include/rtems/score/basedefs.h 
b/cpukit/score/include/rtems/score/basedefs.h
index 5575a06..9e6bc0a 100644
--- a/cpukit/score/include/rtems/score/basedefs.h
+++ b/cpukit/score/include/rtems/score/basedefs.h
@@ -171,12 +171,14 @@
  *  variables.
  */
 #ifdef __GNUC__
-  #define RTEMS_COMPILER_PURE_ATTRIBUTE \
- __attribute__ ((pure))
+  #define RTEMS_PURE __attribute__((__pure__))
 #else
-  #define RTEMS_COMPILER_PURE_ATTRIBUTE
+  #define RTEMS_PURE
 #endif
 
+/* Provided for backward compatibility */
+#define RTEMS_COMPILER_PURE_ATTRIBUTE RTEMS_PURE
+
 /**
  *  Instructs the compiler to issue a warning whenever a variable or function
  *  with this attribute will be used.
-- 
1.8.4.5

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

Re: [rtems commit] bsp/qoriq: Use U-Boot provided FDT

[Sebastian Huber]

On 20/10/15 00:46, Chris Johns wrote:

Was this patch posted tode...@rtems.org  for review?


No, since this is a BSP specific patch.



I do not remember any discussion about how BSPs and FDT will be
supported.


U-Boot supports FDT for several years now. So, all U-Boot based BSPs may 
use this option.



  I posted an RTEMS API for FDT which seems to have been ignored.


I didn't ignore this, but I thought this is an optional add-on? The 
libfdt is a well established API. I don't see an immediate need for an 
RTEMS specific API on top of this. The FDT is used before the high level 
parts of RTEMS are available, e.g. files.




Can you please describe this use of FDT in RTEMS and how this can used
by more than the immediate use you have for your BSP?


The use of FDT for BSPs is to get U-Boot provided parameters.



Where is the documentation on how this is to be used by the BSP it is
designed to support? I do not see now a user is to build an application
to use this.


This is not for the user. This is for device driver parameters and the 
low-level system startup.




Which BSPs is this new BSP API intended for?

I do not support this change and would like it reverted until a better
proposal is put forward.


What is your alternative? There is no way for a QorIQ device as complex 
as a T4240 without FDT.




On 19/10/2015 6:53 pm, Sebastian Huber wrote:

>  c/src/lib/libbsp/shared/include/fdt.h | 30 +++
>  c/src/lib/libbsp/shared/src/bsp-fdt.c | 59 ++

This is being adding the shared BSP API. Why?



This is useful for more than one BSP.

--
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] Add RTEMS linker sets

[Sebastian Huber]

On 14/10/15 23:16, Chris Johns wrote:

Is this for users or the kernel or both?


Its probably useful for both. The libbsd already uses this stuff.



Is there any documentation for using this?


Before I spend more time on this we have to make a project decision if 
we want to use linker sets or not. We have to decide if we want to use 
the lexicographical sorting of GNU ld or not. Linker sets are so wide 
spread used (e.g. global constructors, Linux, BSD) that I don't see a 
high risk that a particular architectures doesn't support it. In case a 
linker lacks support for the lexicographical sorting, then you just have 
to enumerate the sections by hand. That's the price for using bad tools.


We have to evaluate if a linker set based initialization is a problem 
for mission-critical or safety-critical applications.


--
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: Random lwIP Crashes in _POSIX_Mutex_Lock_support()

[Sebastian Huber]

On 20/10/15 16:02, Isaac Gutekunst wrote:

Hi Devel,

I'm pretty sure this is a devel question, not users.


I'm working with a colleague at Vecna to port lwIP to the STM32F7 BSP 
we've developed.


We have a basic HTTP server that prints out the current list of tasks. 
We refresh the page at a very high rate, and after about 1-30 minutes, 
get a crash.


Every time the exception is thrown after 
_CORE_mutex_Check_dispatch_for_seize( wait )  on line 254 of 
coremuteximpl.h. Every time this is inside a pthread_mutex_lock() call.



Here is the full backtrace:

stm32f_fatal_error_handler() at hal-fatal-error-handler.c:126 
0x800af92

_User_extensions_Fatal_visitor() at userextiterate.c:123 0x803212c
_User_extensions_Iterate() at userextiterate.c:166 0x80321c0
_User_extensions_Fatal() at userextimpl.h:254 0x802a85e
_Terminate() at interr.c:44 0x802a888
_CORE_mutex_Seize_body() at coremuteximpl.h:255 0x8068df0
_POSIX_Mutex_Lock_support() at mutexlocksupp.c:57 0x806907e
pthread_mutex_lock() at mutexlock.c:40 0x8068bee
sys_arch_sem_wait() at sys_arch.c:485 0x808da8a
sys_arch_mbox_fetch() at sys_arch.c:357 0x808d804
sys_timeouts_mbox_fetch() at timers.c:532 0x80883ce
tcpip_thread() at tcpip.c:95 0x808c170
_Thread_Handler() at threadhandler.c:102 0x806bbe8
_User_extensions_Thread_exitted() at userextimpl.h:244 0x806bb60
bsp_section_work_begin() at 0xc016a12c


However, the lwip code calling pthread_mutex_lock varies, but is 
consistently from lwIP.



Does this ring any bells?


Normally you get this if you obtain a locked mutex in interrupt context, 
but your stack trace says you are not.




As far as I can tell this would only occur if the caller of 
pthread_mutex_lock was in a "bad" state. I don't believe it is in an 
interrupt context, and don't know what other bad states could exist.


We have

#define _CORE_mutex_Check_dispatch_for_seize(_wait) \
  (!_Thread_Dispatch_is_enabled() \
&& (_wait) \
&& (_System_state_Get() >= SYSTEM_STATE_UP))

What is the thread dispatch disable level and the system state at this 
point?


In case the thread dispatch disable level is not zero, then something is 
probably broken in the operating system code which is difficult to find. 
Could be a general memory corruption problem too. Which RTEMS version do 
you use?


--
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: Suggestions for BSPs to Obsolete

[Sebastian Huber]

On 21/10/15 01:24, Chris Johns wrote:

On 21/10/2015 12:56 am, Joel Sherrill wrote:

On 10/20/2015 6:15 AM, Sebastian Huber wrote:

Maybe we should build a list of BSP directories and find maintainers for
each directory in some time frame. Then remove all BSPs without a
maintainer.

That is one approach. Another is defining tiers for the BSP
and being more aggressive about dropping them.

I think Chris has discussed his ideas on tiers before.
  

I think both will be needed. We are moving to Phabricator and having
areas developers can approve will be important. I am concerned if we do
not things will sit and not be pushed through.

I also think we will need tiers so we can manage the results from
buildbot. There are active and current BSPs we have no way of testing
because we do not have the hardware. If a user has a board and sets up a
slave to allow testing for that BSP it will reach a higher tier and we
have better testing.


Maybe we need something similar to the Linux maintainers list:

https://www.kernel.org/doc/linux/MAINTAINERS

--
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] RFS: Fix resource leak

[Sebastian Huber]

Close #2433.
---
 cpukit/libfs/src/rfs/rtems-rfs-rtems.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/cpukit/libfs/src/rfs/rtems-rfs-rtems.c 
b/cpukit/libfs/src/rfs/rtems-rfs-rtems.c
index 999dfb3..a0ade04 100644
--- a/cpukit/libfs/src/rfs/rtems-rfs-rtems.c
+++ b/cpukit/libfs/src/rfs/rtems-rfs-rtems.c
@@ -831,6 +831,8 @@ rtems_rfs_rtems_initialise 
(rtems_filesystem_mount_table_entry_t* mt_entry,
   rc = rtems_rfs_fs_open (mt_entry->dev, rtems, flags, max_held_buffers, );
   if (rc)
   {
+rtems_rfs_mutex_unlock (>access);
+rtems_rfs_mutex_destroy (>access);
 free (rtems);
 return rtems_rfs_rtems_error ("initialise: open", errno);
   }
-- 
1.8.4.5

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

Re: LwIP port using directly RTEMS semaphores and message queues

[Sebastian Huber]

On 12/10/15 01:15, Pavel Pisa wrote:

As for LwIP and RTEMS integration in general, does exists some
idea/implementation how to make LwIP sockets the fist class RTEMS
citizens/objects - i.e. to get file descriptor compatible with RTEMS
read, write etc. calls same as for native RTEMS stack?


An alternative is to integrate the RTEMS support for lwIP in the lwIP 
project.




I would like to see select() supporting socket objects together
with notification from character drivers as well one day
to port applications waiting for more event sources in one thread
possible. But I think that select() is not compatible with
drivers even in RTEMS integrated stack. It it?


I have a hack for select() support in drivers and pipe():

https://git.rtems.org/sebh/rtems.git/commit/?id=92a35861d4795075dcff3ebab177812c7422753f

Its not included in the main sources due to a lack of time, testing and 
I am not sure if its really useful.


--
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] Fix exception handler for supporting FPU

[Sebastian Huber]

On 07/10/15 05:13, Chris Johns wrote:

On 23/09/2015 11:33 am, Gedare Bloom wrote:

>ping. i will try to get to this tomorrow if no one else does.

What happened to this change?


https://lists.rtems.org/pipermail/devel/2015-September/012612.html

--
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: SMP support for Raspberry Pi 2

[Sebastian Huber]

On 08/07/15 14:54, Rohini Kulkarni wrote:
This piece of code gets the configured number of CPUs. I suppose this 
number is not specified and will have to be specified by me somewhere 
in the configurations. But I am unable to find out where.


For examples, please have a look at testsuite/smptests.

--
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: Code refactor for ARM bsp MMU initialization

[Sebastian Huber]

On 08/07/15 15:10, Rohini Kulkarni wrote:



On Wed, Jul 8, 2015 at 6:29 PM, Sebastian Huber
sebastian.hu...@embedded-brains.de
mailto:sebastian.hu...@embedded-brains.de wrote:

Hello Rohini,

please use git format-patch to generate the patches.

Actually,that is what I have used. I pasted the patch here from the
resulting file.


Better use git send-email, or send the file as is since this will 
preserve the commit message and author.





On 08/07/15 14:44, Rohini Kulkarni wrote:

+++ b/c/src/lib/libbsp/arm/raspberrypi/startup/bspstartmmu.c
@@ -0,0 +1,30 @@
+#define ARM_CP15_TEXT_SECTION BSP_START_TEXT_SECTION
+
+#include bsp/start.h
+#include bsp/arm-cp15-start.h
+#include bsp/linker-symbols.h
+#include libcpu/arm-cp15.h
+#include bsp/mm.h
+#include bsp.h
+
+uint32_t bsp_initial_mmu_ctrl_set;
+uint32_t bsp_initial_mmu_ctrl_clear;
+uint32_t domain_set;
+
+void raspberrypi_setup_mmu_and_cache(void)
+{
+#if (BSP_IS_RPI2 == 1)
+  /* Enable SMP in auxiliary control */
+  uint32_t actlr = arm_cp15_get_auxiliary_control();
+  actlr |= ARM_CORTEX_A9_ACTL_SMP;
+  arm_cp15_set_auxiliary_control(actlr);
+  bsp_initial_mmu_ctrl_clear = ARM_CP15_CTRL_A;
+  bsp_initial_mmu_ctrl_set = ARM_CP15_CTRL_AFE | ARM_CP15_CTRL_Z;
+#else
+  bsp_initial_mmu_ctrl_clear = 0;
+  bsp_initial_mmu_ctrl_set = ARM_CP15_CTRL_AFE |
ARM_CP15_CTRL_S | ARM_CP15_CTRL_XP;
+#endif
+  domain_set = ARM_MMU_DEFAULT_CLIENT_DOMAIN;
+
+  bsp_memory_management_initialize();
+}


Is there a reason, why you use global variables instead of
function parameters?

I have set them as extern in mm.h and are directly used in mminit.c
instead of being passed to bsp_memory_management_initialize. They will
be set by the bsp the source is being compiled for.


You should avoid global variables and functions in general. I don't see 
a necessity for them here.


--
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: SMP support for Raspberry Pi 2

[Sebastian Huber]

In the build tree, there are exactly two identical cpuopts.h files. In this 
file you must find a:
/* if SMP is enabled */
#define RTEMS_SMP 1-- 
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.huber at 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: GSoC 2015 RPi USB Support

[Sebastian Huber]

- Yurii Shevtsov unge...@gmail.com schrieb:
 No I haven't. I tried to write driver stub, but I got same issueson
 RPi. What are the qemu args? Can I run qemu in terminal?

You have to figure out how the linker set mechanism works in general.

-- 
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.huber at 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 QorIQ

[Sebastian Huber]

Hello Joel,

On 09/07/15 00:46, Joel Sherrill wrote:

Hi

I noticed the modification to qoriq_t2080rdb.cfg and wondered
how things were going. How many cores have you all seen running?


We use all 24 cores, the roadmap for this platform is 64 cores.


Any scaling issues?


Yes, there is a lot of work ahead. I work currently on optimized OpenMP 
support. Here we have the same problems that we already observed with 
the new network stack on SMP. The Classic API object identifier to 
object translation is a performance problem. The object creation is a 
major bottleneck (mainly due to the use of the allocator mutex) for 
OpenMP which dynamically creates objects.


I have a prototype implementation for self-contained objects which may 
be used for the locks etc. in Newlib, GCC and the network stack (see 
attached file), but this is something for post 4.11.


On the positive side is the low level stuff, the scheduler and thread 
dispatching works really well.


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

/*
 * Copyright (c) 2015 embedded brains GmbH.  All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *notice, this list of conditions and the following disclaimer in the
 *documentation and/or other materials provided with the distribution.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * AS IS AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

#ifndef _SYS_LOCK_H_
#define _SYS_LOCK_H_

#include sys/cdefs.h

__BEGIN_DECLS

struct _Thread_Control;

struct _Thread_queue_Heads;

struct _Ticket_lock_Control {
	unsigned int _next_ticket;
	unsigned int _now_serving;
};

struct _Thread_queue_Queue {
	struct _Thread_queue_Heads *_heads;
	struct _Ticket_lock_Control _Lock;
};

struct _Mutex_Control {
	struct _Thread_queue_Queue _Queue;
	struct _Thread_Control *_owner;
};

struct _Mutex_recursive_Control {
	struct _Mutex_Control _Mutex;
	unsigned int _nest_level;
};

struct _Semaphore_Control {
	struct _Thread_queue_Queue _Queue;
	unsigned int _count;
};

#define _MUTEX_INITIALIZER { { 0, { 0, 0 } }, 0 }

#define _MUTEX_RECURSIVE_INITIALIZER { _MUTEX_INITIALIZER, 0 }

#define _SEMAPHORE_INITIALIZER(_count) { { 0, { 0, 0 } }, _count }

static inline void
_Mutex_Initialize(struct _Mutex_Control *_mutex)
{
	struct _Mutex_Control _init = _MUTEX_INITIALIZER;

	*_mutex = _init;
}

void _Mutex_Acquire(struct _Mutex_Control *);

int _Mutex_Try_acquire(struct _Mutex_Control *);

void _Mutex_Release(struct _Mutex_Control *);

static inline void
_Mutex_Destroy(struct _Mutex_Control *_mutex)
{

	(void)_mutex;
}

static inline void
_Mutex_recursive_Initialize(struct _Mutex_recursive_Control *_mutex)
{
	struct _Mutex_recursive_Control _init = _MUTEX_RECURSIVE_INITIALIZER;

	*_mutex = _init;
}

void _Mutex_recursive_Acquire(struct _Mutex_recursive_Control *);

int _Mutex_recursive_Try_acquire(struct _Mutex_recursive_Control *);

void _Mutex_recursive_Release(struct _Mutex_recursive_Control *);

static inline void
_Mutex_recursive_Destroy(struct _Mutex_recursive_Control *_mutex)
{

	(void)_mutex;
}

static inline void
_Semaphore_Initialize(struct _Semaphore_Control *_semaphore,
unsigned int _count)
{
	struct _Semaphore_Control _init = _SEMAPHORE_INITIALIZER(_count);

	*_semaphore = _init;
}

void _Semaphore_Wait(struct _Semaphore_Control *);

void _Semaphore_Post(struct _Semaphore_Control *);

static inline void
_Semaphore_Destroy(struct _Semaphore_Control *_semaphore)
{

	(void)_semaphore;
}

typedef struct _Mutex_Control _LOCK_T;

typedef struct _Mutex_recursive_Control _LOCK_RECURSIVE_T;

#define __LOCK_INIT(_qualifier, _designator) \
  _qualifier _LOCK_T _designator = _MUTEX_INITIALIZER

#define __LOCK_INIT_RECURSIVE(_qualifier, _designator

Re: [PATCH-V4 1/1] sparc: Fix context switch on SMP

[Sebastian Huber]

Thanks, I check in this patch on the 4.11 branch.

--
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: building RTEMS 4.11 leon3 with floating point support?

[Sebastian Huber]

Hello Alan,

I am not sure how Gaisler manages this in their RCC, but I think for 
standard RTEMS we need additional BSPs (e.g. via leon3_fp.cfg and 
ngmp_fp.cfg configuration files).


On 17/08/15 17:29, Cudmore, Alan P. (GSFC-5820) wrote:

Hi,
We are currently trying to use the leon3 BSP for RTEMS 4.11.
We have used the 4.10 RCC/Gaisler tools with the Driver Manager in the 
past, but we would like to be on 4.11 for the SMP support.


When I build the 4.11 leon3 BSP, I seem to only have soft-float 
support. When I try to build with the —enable-multilib configure 
switch, the build fails. Before I start trying to determine the cause 
of the compile failure, I wanted to make sure I am enabling floating 
point support for the LEON3 correctly.


Thanks,
Alan




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


--
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] rbtree: Delete rtems_rbtree_find_control()

[Sebastian Huber]

This function is hard to support in alternative implementations.  It has
no internal use case.
---
 cpukit/sapi/include/rtems/rbtree.h| 10 --
 cpukit/score/include/rtems/score/rbtree.h | 25 -
 testsuites/sptests/sprbtree01/init.c  |  7 ---
 3 files changed, 42 deletions(-)

diff --git a/cpukit/sapi/include/rtems/rbtree.h 
b/cpukit/sapi/include/rtems/rbtree.h
index 2604189..271e4b5 100644
--- a/cpukit/sapi/include/rtems/rbtree.h
+++ b/cpukit/sapi/include/rtems/rbtree.h
@@ -378,16 +378,6 @@ RTEMS_INLINE_ROUTINE rtems_rbtree_node 
*rtems_rbtree_peek_max(
 }
 
 /**
- * @copydoc _RBTree_Find_control()
- */
-RTEMS_INLINE_ROUTINE rtems_rbtree_control *rtems_rbtree_find_control(
-  const rtems_rbtree_node *the_node
-)
-{
-  return _RBTree_Find_control( the_node );
-}
-
-/**
  * @copydoc _RBTree_Insert()
  */
 RTEMS_INLINE_ROUTINE rtems_rbtree_node *rtems_rbtree_insert(
diff --git a/cpukit/score/include/rtems/score/rbtree.h 
b/cpukit/score/include/rtems/score/rbtree.h
index 3e56625..b44c09e 100644
--- a/cpukit/score/include/rtems/score/rbtree.h
+++ b/cpukit/score/include/rtems/score/rbtree.h
@@ -388,31 +388,6 @@ RTEMS_INLINE_ROUTINE bool _RBTree_Is_root(
 }
 
 /**
- * @brief Finds the red-black tree control given a node in the tree.
- *
- * In case the node is not a node of a tree, then this function yields
- * unpredictable results.
- *
- * @param[in] the_node The node of interest.
- *
- * @return The red-black tree control of the node.
- */
-RTEMS_INLINE_ROUTINE RBTree_Control *_RBTree_Find_control(
-  const RBTree_Node *the_node
-)
-{
-  RBTree_Node*parent = the_node->parent;
-  RBTree_Control *rbtree;
-
-  do {
-rbtree = (RBTree_Control *) parent;
-parent = parent->parent;
-  } while ( parent != NULL );
-
-  return rbtree;
-}
-
-/**
  * @brief Initialize this RBTree as empty.
  *
  * This routine initializes @a the_rbtree to contain zero nodes.
diff --git a/testsuites/sptests/sprbtree01/init.c 
b/testsuites/sptests/sprbtree01/init.c
index c24d648..0fe72a4 100644
--- a/testsuites/sptests/sprbtree01/init.c
+++ b/testsuites/sptests/sprbtree01/init.c
@@ -2027,13 +2027,6 @@ rtems_task Init( rtems_task_argument ignored )
 rtems_test_exit(0);
   }
 
-  p = rb_find_unique(, _node.Node);
-  puts( "INIT - Verify rtems_rbtree_find_control" );
-  if (rtems_rbtree_find_control(p) != ) {
-puts ("INIT - ERROR ON RBTREE HEADER MISMATCH");
-rtems_test_exit(0);
-  }
-
   if ( _RBTree_Is_red( NULL ) != 0 )
 puts ( "INIT - ERROR ON RBTREE NULL IS RED MISMATCH" );
   if ( _RBTree_Is_red( rbtree1.root ) != 0 )
-- 
1.8.4.5

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

Re: [PATCH] rbtree: Delete rtems_rbtree_find_control()

[Sebastian Huber]

I would like to back port this patch to the 4.11 branch.

On 31/08/15 10:43, Sebastian Huber wrote:

This function is hard to support in alternative implementations.  It has
no internal use case.


--
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: [rtems commit] Add __synch_synchronize function for arm

[Sebastian Huber]

This file lacks a license header.

On 01/08/15 19:20, Joel Sherril wrote:

Module:rtems
Branch:4.11
Commit:1cf91e0b0a6e93a5344a9b4fc6c09f44ff95d1e2
Changeset: 
http://git.rtems.org/rtems/commit/?id=1cf91e0b0a6e93a5344a9b4fc6c09f44ff95d1e2

Author:Jan Sommer <summers...@web.de>
Date:  Sat Aug  1 05:43:12 2015 -0500

Add __synch_synchronize function for arm

Fixes link failure when linking Ada programs on the raspberry pi

---

  cpukit/score/cpu/arm/Makefile.am  | 1 +
  cpukit/score/cpu/arm/armv4-sync-synchronize.c | 9 +
  2 files changed, 10 insertions(+)

diff --git a/cpukit/score/cpu/arm/Makefile.am b/cpukit/score/cpu/arm/Makefile.am
index c051a48..4b242f0 100644
--- a/cpukit/score/cpu/arm/Makefile.am
+++ b/cpukit/score/cpu/arm/Makefile.am
@@ -27,6 +27,7 @@ libscorecpu_a_SOURCES += arm_exc_handler_high.c
  libscorecpu_a_SOURCES += arm-exception-frame-print.c
  libscorecpu_a_SOURCES += arm-exception-default.c
  libscorecpu_a_SOURCES += armv4-exception-default.S
+libscorecpu_a_SOURCES += armv4-sync-synchronize.c
  libscorecpu_a_SOURCES += armv7-thread-idle.c
  libscorecpu_a_SOURCES += armv7m-context-initialize.c
  libscorecpu_a_SOURCES += armv7m-context-restore.c
diff --git a/cpukit/score/cpu/arm/armv4-sync-synchronize.c 
b/cpukit/score/cpu/arm/armv4-sync-synchronize.c
new file mode 100644
index 000..6fcac05
--- /dev/null
+++ b/cpukit/score/cpu/arm/armv4-sync-synchronize.c
@@ -0,0 +1,9 @@
+void
+__sync_synchronize (void)
+{
+#ifdef ARM_MULTILIB_HAS_BARRIER_INSTRUCTIONS
+  asm volatile("dmb" : : : "memory");
+#else
+  asm volatile("" : : : "memory");
+#endif
+}
\ No newline at end of file

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


--
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 2/3] rbtree: Add _RBTree_Replace_node()

[Sebastian Huber]

On 31/08/15 16:30, Gedare Bloom wrote:

It's on the caller to ensure no ordering violation?


Yes, I added this function for the Linux rbtree support. One user is the 
JFFS2 file system.


--
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 1/3] rbtree: Replace implementation

[Sebastian Huber]

Use the BSD  implementation since it is faster, more
flexible and uses less storage.  See https://github.com/sebhub/rb-bench.
---
 cpukit/score/include/rtems/score/rbtree.h | 277 +
 cpukit/score/include/rtems/score/rbtreeimpl.h | 118 
 cpukit/score/src/rbtreeextract.c  | 190 +-
 cpukit/score/src/rbtreefind.c |  10 +-
 cpukit/score/src/rbtreeinsert.c   | 128 +---
 cpukit/score/src/rbtreenext.c |  57 +-
 testsuites/sptests/sprbtree01/init.c  | 853 +-
 7 files changed, 624 insertions(+), 1009 deletions(-)

diff --git a/cpukit/score/include/rtems/score/rbtree.h 
b/cpukit/score/include/rtems/score/rbtree.h
index b44c09e..077f2b1 100644
--- a/cpukit/score/include/rtems/score/rbtree.h
+++ b/cpukit/score/include/rtems/score/rbtree.h
@@ -18,9 +18,8 @@
 #ifndef _RTEMS_SCORE_RBTREE_H
 #define _RTEMS_SCORE_RBTREE_H
 
-#include 
-
-#include 
+#include 
+#include 
 
 #ifdef __cplusplus
 extern "C" {
@@ -40,54 +39,22 @@ extern "C" {
 /**@{*/
 
 /**
- *  @typedef RBTree_Node
+ * @brief Red-black tree node.
  *
- *  This type definition promotes the name for the RBTree Node used by
- *  all RTEMS code.  It is a separate type definition because a forward
- *  reference is required to define it.  See @ref RBTree_Node_struct for
- *  detailed information.
+ * This is used to manage each node (element) which is placed on a red-black
+ * tree.
  */
-typedef struct RBTree_Node_struct RBTree_Node;
+typedef struct RBTree_Node {
+  RB_ENTRY(RBTree_Node) Node;
+} RBTree_Node;
 
 /**
- * This enum type defines the colors available for the RBTree Nodes
- */
-typedef enum {
-  RBT_BLACK,
-  RBT_RED
-} RBTree_Color;
-
-/**
- *  @struct RBTree_Node_struct
- *
- *  This is used to manage each element (node) which is placed
- *  on a RBT.
- *
- *  @note Typically, a more complicated structure will use the
- *rbtree package.  The more complicated structure will
- *include a rbtree node as the first element in its
- *control structure.  It will then call the rbtree package
- *with a pointer to that node element.  The node pointer
- *and the higher level structure start at the same address
- *so the user can cast the pointers back and forth.
+ * @brief Red-black tree control.
  *
+ * This is used to manage a red-black tree.  A red-black tree consists of a
+ * tree of zero or more nodes.
  */
-struct RBTree_Node_struct {
-  /** This points to the node's parent */
-  RBTree_Node *parent;
-  /** child[0] points to the left child, child[1] points to the right child */
-  RBTree_Node *child[2];
-  /** The color of the node. Either red or black */
-  RBTree_Color color;
-};
-
-/**
- *  This type indicates the direction.
- */
-typedef enum {
-  RBT_LEFT=0,
-  RBT_RIGHT=1
-} RBTree_Direction;
+typedef RB_HEAD(RBTree_Control, RBTree_Node) RBTree_Control;
 
 /**
  * @brief Integer type for compare results.
@@ -117,41 +84,13 @@ typedef RBTree_Compare_result ( *RBTree_Compare )(
 );
 
 /**
- *  @struct RBTree_Control
- *
- * This is used to manage a RBT.  A rbtree consists of a tree of zero or more
- * nodes.
- *
- * @note This implementation does not require special checks for
- *   manipulating the root element of the RBT.
- *   To accomplish this the @a RBTree_Control structure can be overlaid
- *   with a @ref RBTree_Node structure to act as a "dummy root",
- *   which has a NULL parent and its left child is the root.
- */
-
-/* the RBTree_Control is actually part of the RBTree structure as an
- * RBTree_Node. The mapping of fields from RBTree_Control to RBTree_Node are:
- *   permanent_null == parent
- *   root == left
- *   first[0] == right
- */
-typedef struct {
-  /** This points to a NULL. Useful for finding the root. */
-  RBTree_Node *permanent_null;
-  /** This points to the root node of the RBT. */
-  RBTree_Node *root;
-  /** This points to the min and max nodes of this RBT. */
-  RBTree_Node *first[2];
-} RBTree_Control;
-
-/**
- *  @brief RBTree initializer for an empty rbtree with designator @a name.
+ * @brief Initializer for an empty red-black tree with designator @a name.
  */
 #define RBTREE_INITIALIZER_EMPTY( name ) \
-  { NULL, NULL, { NULL, NULL } }
+  RB_INITIALIZER( name )
 
 /**
- *  @brief RBTree definition for an empty rbtree with designator @a name.
+ * @brief Definition for an empty red-black tree with designator @a name.
  */
 #define RBTREE_DEFINE_EMPTY( name ) \
   RBTree_Control name = RBTREE_INITIALIZER_EMPTY( name )
@@ -201,6 +140,95 @@ RBTree_Node *_RBTree_Insert(
 );
 
 /**
+ * @brief Rebalances the red-black tree after insertion of the node.
+ *
+ * @param[in] the_rbtree The red-black tree control.
+ * @param[in] the_node The most recently inserted node.
+ */
+void _RBTree_Insert_color(
+  RBTree_Control *the_rbtree,
+  RBTree_Node*the_node
+);
+
+/**
+ * @brief Adds a child node to a parent node.
+ *
+ * @param[in] child The child node.
+ * @param[in] 

[PATCH 2/3] rbtree: Add _RBTree_Replace_node()

[Sebastian Huber]

---
 cpukit/score/Makefile.am  |  1 +
 cpukit/score/include/rtems/score/rbtree.h | 13 +++
 cpukit/score/src/rbtreereplace.c  | 61 +++
 3 files changed, 75 insertions(+)
 create mode 100644 cpukit/score/src/rbtreereplace.c

diff --git a/cpukit/score/Makefile.am b/cpukit/score/Makefile.am
index 507d49f..f727e60 100644
--- a/cpukit/score/Makefile.am
+++ b/cpukit/score/Makefile.am
@@ -286,6 +286,7 @@ libscore_a_SOURCES += src/freechain.c
 libscore_a_SOURCES += \
 src/rbtreeextract.c src/rbtreefind.c \
 src/rbtreeinsert.c src/rbtreeiterate.c src/rbtreenext.c
+libscore_a_SOURCES += src/rbtreereplace.c
 
 ## THREAD_C_FILES
 libscore_a_SOURCES += src/thread.c src/threadchangepriority.c \
diff --git a/cpukit/score/include/rtems/score/rbtree.h 
b/cpukit/score/include/rtems/score/rbtree.h
index 077f2b1..7e41c7a 100644
--- a/cpukit/score/include/rtems/score/rbtree.h
+++ b/cpukit/score/include/rtems/score/rbtree.h
@@ -470,6 +470,19 @@ RBTree_Node *_RBTree_Predecessor( const RBTree_Node *node 
);
  */
 RBTree_Node *_RBTree_Successor( const RBTree_Node *node );
 
+/**
+ * @brief Replaces a node in the red-black tree without a rebalance.
+ *
+ * @param[in] the_rbtree The red-black tree control.
+ * @param[in] victim The victim node.
+ * @param[in] replacement The replacement node.
+ */
+void _RBTree_Replace_node(
+  RBTree_Control *the_rbtree,
+  RBTree_Node*victim,
+  RBTree_Node*replacement
+);
+
 /**@}*/
 
 #ifdef __cplusplus
diff --git a/cpukit/score/src/rbtreereplace.c b/cpukit/score/src/rbtreereplace.c
new file mode 100644
index 000..7a54000
--- /dev/null
+++ b/cpukit/score/src/rbtreereplace.c
@@ -0,0 +1,61 @@
+/**
+ * @file
+ *
+ * @ingroup ScoreRBTree
+ *
+ * @brief _RBTree_Replace_node() implementation.
+ */
+
+/*
+ * Copyright (c) 2015 embedded brains GmbH.  All rights reserved.
+ *
+ *  embedded brains GmbH
+ *  Dornierstr. 4
+ *  82178 Puchheim
+ *  Germany
+ *  
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+#if HAVE_CONFIG_H
+  #include "config.h"
+#endif
+
+#include 
+
+void _RBTree_Replace_node(
+  RBTree_Control *the_rbtree,
+  RBTree_Node*victim,
+  RBTree_Node*replacement
+)
+{
+  RBTree_Node  *parent = _RBTree_Parent( victim );
+  RBTree_Node **link;
+  RBTree_Node  *child;
+
+  if (parent != NULL) {
+if ( victim == _RBTree_Left( parent ) ) {
+  link = _RBTree_Left_reference( parent );
+} else {
+  link = _RBTree_Right_reference( parent );
+}
+  } else {
+link = _RBTree_Root_reference( the_rbtree );
+  }
+  *link = replacement;
+
+  child = _RBTree_Left( victim );
+  if ( child != NULL ) {
+RB_PARENT( child, Node ) = replacement;
+  }
+
+  child = _RBTree_Right( victim );
+  if ( child != NULL ) {
+RB_PARENT( child, Node ) = replacement;
+  }
+
+  *replacement = *victim;
+}
-- 
1.8.4.5

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

[PATCH 3/3] JFFS2: Use RTEMS red-black tree implementation

[Sebastian Huber]

---
 cpukit/libfs/Makefile.am  |   1 -
 cpukit/libfs/src/jffs2/include/linux/rbtree.h | 128 ++--
 cpukit/libfs/src/jffs2/src/compat-rbtree.c| 422 --
 3 files changed, 98 insertions(+), 453 deletions(-)
 delete mode 100644 cpukit/libfs/src/jffs2/src/compat-rbtree.c

diff --git a/cpukit/libfs/Makefile.am b/cpukit/libfs/Makefile.am
index 678234b..7fccc2e 100644
--- a/cpukit/libfs/Makefile.am
+++ b/cpukit/libfs/Makefile.am
@@ -113,7 +113,6 @@ project_lib_LIBRARIES = libjffs2.a
 libjffs2_a_SOURCES =
 libjffs2_a_SOURCES += src/jffs2/src/build.c
 libjffs2_a_SOURCES += src/jffs2/src/compat-crc32.c
-libjffs2_a_SOURCES += src/jffs2/src/compat-rbtree.c
 libjffs2_a_SOURCES += src/jffs2/src/compr.c
 libjffs2_a_SOURCES += src/jffs2/src/compr_rtime.c
 libjffs2_a_SOURCES += src/jffs2/src/compr_zlib.c
diff --git a/cpukit/libfs/src/jffs2/include/linux/rbtree.h 
b/cpukit/libfs/src/jffs2/include/linux/rbtree.h
index 73cf937..17d93f0 100644
--- a/cpukit/libfs/src/jffs2/include/linux/rbtree.h
+++ b/cpukit/libfs/src/jffs2/include/linux/rbtree.h
@@ -1,50 +1,118 @@
-#ifndef_LINUX_RBTREE_H
-#define_LINUX_RBTREE_H
+#ifndef _LINUX_RBTREE_H
+#define _LINUX_RBTREE_H
 
-#include 
+#include 
 
 struct rb_node {
-   struct rb_node *rb_left;
-   struct rb_node *rb_right;
-   struct rb_node *rb_parent;
-   int rb_color;
+  struct rb_node *rb_left;
+  struct rb_node *rb_right;
+  struct rb_node *rb_parent;
+  int rb_color;
 };
 
+RTEMS_STATIC_ASSERT(
+  sizeof( struct rb_node ) == sizeof( RBTree_Node ),
+  rb_node_size
+);
+
+RTEMS_STATIC_ASSERT(
+  offsetof( struct rb_node, rb_left ) == offsetof( RBTree_Node, Node.rbe_left 
),
+  rb_node_left
+);
+
+RTEMS_STATIC_ASSERT(
+  offsetof( struct rb_node, rb_right ) == offsetof( RBTree_Node, 
Node.rbe_right ),
+  rb_node_right
+);
+
+RTEMS_STATIC_ASSERT(
+  offsetof( struct rb_node, rb_parent ) == offsetof( RBTree_Node, 
Node.rbe_parent ),
+  rb_node_parent
+);
+
+RTEMS_STATIC_ASSERT(
+  offsetof( struct rb_node, rb_color ) == offsetof( RBTree_Node, 
Node.rbe_color ),
+  rb_node_color
+);
+
 struct rb_root {
-   struct rb_node *rb_node;
+  struct rb_node *rb_node;
 };
-#define RB_ROOT ((struct rb_root){0})
-#define rb_entry(p, container, field)  \
-   ((container *) ((char *)p - offsetof(container, field)))
 
-#define RB_BLACK   0
-#define RB_RED 1
+RTEMS_STATIC_ASSERT(
+  sizeof( struct rb_root ) == sizeof( RBTree_Control ),
+  rb_root_size
+);
+
+RTEMS_STATIC_ASSERT(
+  offsetof( struct rb_root, rb_node ) == offsetof( RBTree_Control, rbh_root ),
+  rb_root_node
+);
+
+#undef RB_ROOT
+#define RB_ROOT ( (struct rb_root) { NULL } )
+
+#define rb_entry( p, container, field ) RTEMS_CONTAINER_OF( p, container, 
field )
+
+static inline void rb_insert_color( struct rb_node *node, struct rb_root *root)
+{
+  _RBTree_Insert_color( (RBTree_Control *) root, (RBTree_Node *) node );
+}
+
+static inline void rb_erase( struct rb_node *node, struct rb_root *root )
+{
+  _RBTree_Extract( (RBTree_Control *) root, (RBTree_Node *) node );
+}
 
+static inline struct rb_node *rb_next( struct rb_node *node )
+{
+  return (struct rb_node *) _RBTree_Successor( (RBTree_Node *) node );
+}
 
-extern void rb_insert_color(struct rb_node *, struct rb_root *);
-extern void rb_erase(struct rb_node *, struct rb_root *);
+static inline struct rb_node *rb_prev( struct rb_node *node )
+{
+  return (struct rb_node *) _RBTree_Predecessor( (RBTree_Node *) node );
+}
 
-extern struct rb_node *rb_next(struct rb_node *);
-extern struct rb_node *rb_prev(struct rb_node *);
-extern struct rb_node *rb_first(struct rb_root *);
-extern struct rb_node *rb_last(struct rb_root *);
+static inline struct rb_node *rb_first( struct rb_root *root )
+{
+  return (struct rb_node *) _RBTree_Minimum( (RBTree_Control *) root );
+}
 
-extern void rb_replace_node(struct rb_node *victim, struct rb_node *new, 
-   struct rb_root *root);
+static inline struct rb_node *rb_last( struct rb_root *root )
+{
+  return (struct rb_node *) _RBTree_Maximum( (RBTree_Control *) root );
+}
 
-static inline void rb_link_node(struct rb_node * node, struct rb_node * parent,
-   struct rb_node ** rb_link)
+static inline void rb_replace_node(
+  struct rb_node *victim,
+  struct rb_node *replacement, 
+  struct rb_root *root
+)
 {
-   node->rb_parent = parent;
-   node->rb_color = RB_RED;
-   node->rb_left = node->rb_right = NULL;
+  _RBTree_Replace_node(
+(RBTree_Control *) root,
+(RBTree_Node *) victim,
+(RBTree_Node *) replacement
+  );
+}
 
-   *rb_link = node;
+static inline void rb_link_node(
+  struct rb_node *node,
+  struct rb_node *parent,
+  struct rb_node **link
+)
+{
+  _RBTree_Add_child(
+(RBTree_Node *) node,
+(RBTree_Node *) parent,
+(RBTree_Node **) link
+  );
 }
 
-static inline struct rb_node *rb_parent(struct rb_node * node)
+static inline struct rb_node 

Re: [PATCH] [RTEMS] Update RTEMS thread model

[Sebastian Huber]

On 31/07/15 09:23, Sebastian Huber wrote:



On 31/07/15 09:10, Chris Johns wrote:

On 31/07/2015 4:44 pm, Sebastian Huber wrote:

>

>>Is this for 4.12 ?

>
>This is just a proof-of-concept patch, but it would be nice to include
>this in the next release along with the C11 threads support.
>

If you have tests and they are ok then why not put it in.



It is thoroughly tested in the libstdc++ test suite, unfortunately we 
have do adjust all test cases since they contain stuff like this:


// { dg-do run { target *-*-freebsd* *-*-dragonfly* *-*-netbsd* 
*-*-linux* *-*-gnu* *-*-solaris* *-*-cygwin *-*-darwin* 
powerpc-ibm-aix* } }
// { dg-options " -std=gnu++11 -pthread" { target *-*-freebsd* 
*-*-dragonfly* *-*-netbsd* *-*-linux* *-*-gnu* powerpc-ibm-aix* } }

// { dg-options " -std=gnu++11 -pthreads" { target *-*-solaris* } }
// { dg-options " -std=gnu++11 " { target *-*-cygwin *-*-darwin* } }
// { dg-require-cstdint "" }
// { dg-require-gthreads "" }

So, there is a target white list.



See also:

https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00019.html

https://devel.rtems.org/ticket/2402
https://devel.rtems.org/ticket/2403

The test results are not that bad. Some tests use files, which are not 
available to the RTEMS test driver. The main issues are due to thread 
cancel/exit misbehaviour of RTEMS. Shared mutexes are not implemented in 
general.


Target is arm-unknown-rtems4.11
Host   is arm-unknown-rtems4.11
Build  is x86_64-pc-linux-gnu

=== libstdc++ tests ===

Schedule of variations:
rtems-arm-realview_pbx_a9_qemu

Running target rtems-arm-realview_pbx_a9_qemu
Using 
/scratch/git-rtems-testing/dejagnu/boards/rtems-arm-realview_pbx_a9_qemu.exp 
as board description file for target.
Using /usr/share/dejagnu/config/sim.exp as generic interface file for 
target.
Using /usr/share/dejagnu/baseboards/basic-sim.exp as board description 
file for target.
Using 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/config/default.exp 
as tool-and-target-specific interface file.
Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-abi/abi.exp 
...
Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp 
...

FAIL: 25_algorithms/copy/streambuf_iterators/wchar_t/4.cc execution test
FAIL: 25_algorithms/find/istreambuf_iterators/wchar_t/2.cc execution test
FAIL: 25_algorithms/random_shuffle/moveable.cc execution test
FAIL: 27_io/basic_istream/extractors_other/wchar_t/2.cc execution test
FAIL: 27_io/basic_istream/get/wchar_t/2.cc execution test
FAIL: 27_io/basic_istream/ignore/wchar_t/3.cc execution test
FAIL: 27_io/basic_istream/seekg/wchar_t/sstream.cc execution test
FAIL: 27_io/basic_istream/tellg/wchar_t/sstream.cc execution test
FAIL: 27_io/basic_ostream/inserters_other/wchar_t/1.cc execution test
FAIL: 27_io/basic_stringbuf/setbuf/char/4.cc execution test
FAIL: 27_io/objects/wchar_t/12048-1.cc execution test
FAIL: 27_io/objects/wchar_t/12048-2.cc execution test
FAIL: 27_io/objects/wchar_t/12048-3.cc execution test
FAIL: 27_io/objects/wchar_t/12048-4.cc execution test
WARNING: program timed out.
FAIL: 30_threads/condition_variable/members/3.cc execution test
FAIL: 30_threads/shared_mutex/cons/1.cc (test for excess errors)
WARNING: 30_threads/shared_mutex/cons/1.cc compilation failed to produce 
executable

FAIL: 30_threads/shared_mutex/try_lock/1.cc (test for excess errors)
WARNING: 30_threads/shared_mutex/try_lock/1.cc compilation failed to 
produce executable

FAIL: 30_threads/shared_mutex/try_lock/2.cc (test for excess errors)
WARNING: 30_threads/shared_mutex/try_lock/2.cc compilation failed to 
produce executable

FAIL: 30_threads/shared_timed_mutex/try_lock/3.cc execution test
WARNING: program timed out.
FAIL: 30_threads/thread/native_handle/cancel.cc execution test
FAIL: 30_threads/timed_mutex/try_lock_until/57641.cc execution test
FAIL: tr1/8_c_compatibility/complex/50880.cc (test for excess errors)
WARNING: tr1/8_c_compatibility/complex/50880.cc compilation failed to 
produce executable

FAIL: tr1/8_c_compatibility/complex/functions.cc (test for excess errors)
Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp 
...
Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-xmethods/xmethods.exp 
...


=== libstdc++ Summary ===

# of expected passes8807
# of unexpected failures23
# of expected failures  65
# of unsupported tests  843

--
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] [RTEMS] Update RTEMS thread model

[Sebastian Huber]

For synchronization objects use the self-contained objects available via
Newlib .

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=ecaef05f6601f1e8acb78fb65b411a258f39988a

Enable the C++11 threads using .  So, the threads are only
supported in case the POSIX API is enabled in RTEMS.  In the long run
support for thread join and detach should be added to the API
independent RTEMS services.

libgcc/ChangeLog
2015-09-01  Sebastian Huber  <sebastian.hu...@embedded-brains.de>

* config/gthr-rtems.h (__GTHREADS_CXX0X): New.
(__GTHREAD_HAS_COND): Likewise.
(__gthread_t): Likewise.
(__gthread_cond_t): Likewise.
(__gthread_time_t): Likewise.
(__GTHREAD_MUTEX_INIT): Likewise.
(__GTHREAD_RECURSIVE_MUTEX_INIT): Likewise.
(__GTHREAD_COND_INIT): Likewise.
(__GTHREAD_COND_INIT_FUNCTION): Likewise.
(__GTHREAD_TIME_INIT): Likewise.
(__gthread_create): Likewise.
(__gthread_join): Likewise.
(__gthread_detach): Likewise.
(__gthread_equal): Likewise.
(__gthread_self): Likewise.
(__gthread_yield): Likewise.
(__gthread_cond_broadcast): Likewise.
(__gthread_cond_signal): Likewise.
(__gthread_cond_wait): Likewise.
(__gthread_cond_timedwait): Likewise.
(__gthread_cond_wait_recursive): Likewise.
(__gthread_cond_destroy): Likewise.
(rtems_gxx_once): Delete.
(rtems_gxx_key_create): Likewise.
(rtems_gxx_key_delete): Likewise.
(rtems_gxx_getspecific): Likewise.
(rtems_gxx_setspecific): Likewise.
(rtems_gxx_mutex_init): Likewise.
(rtems_gxx_mutex_destroy): Likewise.
(rtems_gxx_mutex_lock): Likewise.
(rtems_gxx_mutex_trylock): Likewise.
(rtems_gxx_mutex_unlock): Likewise.
(rtems_gxx_recursive_mutex_init): Likewise.
(rtems_gxx_recursive_mutex_lock): Likewise.
(rtems_gxx_recursive_mutex_trylock): Likewise.
(rtems_gxx_recursive_mutex_unlock): Likewise.
(__GTHREAD_ONCE_INIT): Use  initializer.
(__GTHREAD_MUTEX_INIT_FUNCTION): Use  function.
(__GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION): Likewise.
(__gthread_once): Likewise.
(__gthread_key_create): Likewise.
(__gthread_key_delete): Likewise.
(__gthread_getspecific): Likewise.
(__gthread_setspecific): Likewise.
(__gthread_key_t): Use  type.
(__gthread_once_t): Likewise
(__gthread_mutex_t): Use  type.
(__gthread_recursive_mutex_t): Likewise
(__gthread_mutex_lock): Use  function.
(__gthread_mutex_trylock): Likewise.
(__gthread_mutex_timedlock): Likewise.
(__gthread_mutex_unlock): Likewise.
(__gthread_mutex_destroy): Likewise.
(__gthread_recursive_mutex_lock): Likewise.
(__gthread_recursive_mutex_trylock): Likewise.
(__gthread_recursive_mutex_timedlock): Likewise.
(__gthread_recursive_mutex_unlock): Likewise.
(__gthread_recursive_mutex_destroy): Likewise.
---
 libgcc/config/gthr-rtems.h | 195 -
 1 file changed, 139 insertions(+), 56 deletions(-)

diff --git a/libgcc/config/gthr-rtems.h b/libgcc/config/gthr-rtems.h
index 23038c6..1aff329 100644
--- a/libgcc/config/gthr-rtems.h
+++ b/libgcc/config/gthr-rtems.h
@@ -27,134 +27,217 @@ see the files COPYING3 and COPYING.RUNTIME respectively.  
If not, see
 #ifndef GCC_GTHR_RTEMS_H
 #define GCC_GTHR_RTEMS_H
 
+#include 
+#include 
+#include 
+
 #ifdef __cplusplus
 extern "C" {
 #endif
 
 #define __GTHREADS 1
+#define __GTHREADS_CXX0X 1
+#define __GTHREAD_HAS_COND 1
+
+typedef pthread_t __gthread_t;
+typedef pthread_key_t __gthread_key_t;
+typedef pthread_once_t __gthread_once_t;
+typedef struct _Mutex_Control __gthread_mutex_t;
+typedef struct _Mutex_recursive_Control __gthread_recursive_mutex_t;
+typedef struct _Condition_Control __gthread_cond_t;
+typedef struct timespec __gthread_time_t;
+
+#define __GTHREAD_ONCE_INIT PTHREAD_ONCE_INIT
+#define __GTHREAD_MUTEX_INIT _MUTEX_INITIALIZER
+#define __GTHREAD_MUTEX_INIT_FUNCTION _Mutex_Initialize
+#define __GTHREAD_RECURSIVE_MUTEX_INIT _MUTEX_RECURSIVE_INITIALIZER
+#define __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION _Mutex_recursive_Initialize
+#define __GTHREAD_COND_INIT _CONDITION_INITIALIZER
+#define __GTHREAD_COND_INIT_FUNCTION _Condition_Initialize
+#define __GTHREAD_TIME_INIT {0, 0}
 
-#define __GTHREAD_ONCE_INIT  0
-#define __GTHREAD_MUTEX_INIT_FUNCTION  rtems_gxx_mutex_init
-#define __GTHREAD_RECURSIVE_MUTEX_INIT_FUNCTION  rtems_gxx_recursive_mutex_init
-
-/* Avoid dependency on rtems specific headers.  */
-typedef void *__gthread_key_t;
-typedef int   __gthread_once_t;
-typedef void *__gthread_mutex_t;
-typedef void *__gthread_recursive_mutex_t;
-
-/*
- * External functions provided by RTEMS. They are very similar to their POSIX
- * counterparts. A "Wrapper API&q

Re: [PATCH] [RTEMS] Update RTEMS thread model

[Sebastian Huber]

On 01/09/15 12:10, Sebastian Huber wrote:
Shared mutexes are not implemented in general. 


This works now also:

https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00027.html

--
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] posix: glibc compatibility

[Sebastian Huber]

---
 cpukit/posix/src/setcancelstate.c   | 7 +++
 cpukit/posix/src/setcanceltype.c| 7 +++
 testsuites/psxtests/psxcancel/init.c| 8 
 testsuites/psxtests/psxcancel/psxcancel.scn | 6 +++---
 4 files changed, 13 insertions(+), 15 deletions(-)

diff --git a/cpukit/posix/src/setcancelstate.c 
b/cpukit/posix/src/setcancelstate.c
index 0ae7339..a451c2c 100644
--- a/cpukit/posix/src/setcancelstate.c
+++ b/cpukit/posix/src/setcancelstate.c
@@ -50,9 +50,6 @@ int pthread_setcancelstate(
   if ( _ISR_Is_in_progress() )
 return EPROTO;
 
-  if ( !oldstate )
-return EINVAL;
-
   if ( state != PTHREAD_CANCEL_ENABLE && state != PTHREAD_CANCEL_DISABLE )
 return EINVAL;
 
@@ -61,7 +58,9 @@ int pthread_setcancelstate(
 executing = _Thread_Executing;
 thread_support =  executing ->API_Extensions[ THREAD_API_POSIX ];
 
-*oldstate = thread_support->cancelability_state;
+if (oldstate != NULL)
+  *oldstate = thread_support->cancelability_state;
+
 thread_support->cancelability_state = state;
 
 _POSIX_Thread_Evaluate_cancellation_and_enable_dispatch( executing );
diff --git a/cpukit/posix/src/setcanceltype.c b/cpukit/posix/src/setcanceltype.c
index 2ad7cc9..8c4687a 100644
--- a/cpukit/posix/src/setcanceltype.c
+++ b/cpukit/posix/src/setcanceltype.c
@@ -50,9 +50,6 @@ int pthread_setcanceltype(
   if ( _ISR_Is_in_progress() )
 return EPROTO;
 
-  if ( !oldtype )
-return EINVAL;
-
   if ( type != PTHREAD_CANCEL_DEFERRED && type != PTHREAD_CANCEL_ASYNCHRONOUS )
 return EINVAL;
 
@@ -61,7 +58,9 @@ int pthread_setcanceltype(
 executing = _Thread_Executing;
 thread_support =  executing ->API_Extensions[ THREAD_API_POSIX ];
 
-*oldtype = thread_support->cancelability_type;
+if ( oldtype != NULL )
+  *oldtype = thread_support->cancelability_type;
+
 thread_support->cancelability_type = type;
 
 _POSIX_Thread_Evaluate_cancellation_and_enable_dispatch( executing );
diff --git a/testsuites/psxtests/psxcancel/init.c 
b/testsuites/psxtests/psxcancel/init.c
index 2007529..4af4e76 100644
--- a/testsuites/psxtests/psxcancel/init.c
+++ b/testsuites/psxtests/psxcancel/init.c
@@ -95,17 +95,17 @@ void *countTaskAsync(void *ignored)
   TEST_BEGIN();
 
   /* generate some error conditions */
-  puts( "Init - pthread_setcancelstate - NULL oldstate - EINVAL" );
+  puts( "Init - pthread_setcancelstate - NULL oldstate" );
   sc = pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, NULL);
-  fatal_posix_service_status( sc, EINVAL, "cancel state EINVAL" );
+  fatal_posix_service_status( sc, 0, "cancel state NULL" );
 
   puts( "Init - pthread_setcancelstate - bad state - EINVAL" );
   sc = pthread_setcancelstate(12, );
   fatal_posix_service_status( sc, EINVAL, "cancel state EINVAL" );
 
-  puts( "Init - pthread_setcanceltype - NULL oldtype - EINVAL" );
+  puts( "Init - pthread_setcanceltype - NULL oldtype" );
   sc = pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, NULL);
-  fatal_posix_service_status( sc, EINVAL, "cancel type EINVAL" );
+  fatal_posix_service_status( sc, 0, "cancel type NULL" );
 
   puts( "Init - pthread_setcanceltype - bad type - EINVAL" );
   sc = pthread_setcanceltype(12, );
diff --git a/testsuites/psxtests/psxcancel/psxcancel.scn 
b/testsuites/psxtests/psxcancel/psxcancel.scn
index b51dd73..7bc9498 100644
--- a/testsuites/psxtests/psxcancel/psxcancel.scn
+++ b/testsuites/psxtests/psxcancel/psxcancel.scn
@@ -1,7 +1,7 @@
-*** POSIX CANCEL TEST ***
-Init - pthread_setcancelstate - NULL oldstate - EINVAL
+*** BEGIN OF TEST PSXCANCEL ***
+Init - pthread_setcancelstate - NULL oldstate
 Init - pthread_setcancelstate - bad state - EINVAL
-Init - pthread_setcanceltype - NULL oldtype - EINVAL
+Init - pthread_setcanceltype - NULL oldtype
 Init - pthread_setcanceltype - bad type - EINVAL
 Init - pthread_cancel - bad ID - EINVAL
 countTaskDeferred: elapsed time (second):  0
-- 
1.8.4.5

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

Re: [PATCH] [RTEMS] Update RTEMS thread model

[Sebastian Huber]

On 01/09/15 13:05, Sebastian Huber wrote:

On 01/09/15 12:10, Sebastian Huber wrote:
Shared mutexes are not implemented in general. 


This works now also:

https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00027.html



With this additional fix:

https://gcc.gnu.org/ml/gcc/2015-09/msg00021.html

We have these results:

Target is arm-unknown-rtems4.11
Host   is arm-unknown-rtems4.11
Build  is x86_64-pc-linux-gnu

=== libstdc++ tests ===

Schedule of variations:
rtems-arm-realview_pbx_a9_qemu/-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard

Running target 
rtems-arm-realview_pbx_a9_qemu/-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard
Using 
/scratch/git-rtems-testing/dejagnu/boards/rtems-arm-realview_pbx_a9_qemu.exp 
as board description file for target.
Using /usr/share/dejagnu/config/sim.exp as generic interface file for 
target.
Using /usr/share/dejagnu/baseboards/basic-sim.exp as board description 
file for target.
Using 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/config/default.exp 
as tool-and-target-specific interface file.
Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-abi/abi.exp 
...
Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp 
...

FAIL: 25_algorithms/copy/streambuf_iterators/wchar_t/4.cc execution test
FAIL: 25_algorithms/find/istreambuf_iterators/wchar_t/2.cc execution test
FAIL: 25_algorithms/random_shuffle/moveable.cc execution test
FAIL: 27_io/basic_istream/extractors_other/wchar_t/2.cc execution test
FAIL: 27_io/basic_istream/get/wchar_t/2.cc execution test
FAIL: 27_io/basic_istream/ignore/wchar_t/3.cc execution test
FAIL: 27_io/basic_istream/seekg/wchar_t/sstream.cc execution test
FAIL: 27_io/basic_istream/tellg/wchar_t/sstream.cc execution test
FAIL: 27_io/basic_ostream/inserters_other/wchar_t/1.cc execution test
FAIL: 27_io/basic_stringbuf/setbuf/char/4.cc execution test
FAIL: 27_io/objects/wchar_t/12048-1.cc execution test
FAIL: 27_io/objects/wchar_t/12048-2.cc execution test
FAIL: 27_io/objects/wchar_t/12048-3.cc execution test
FAIL: 27_io/objects/wchar_t/12048-4.cc execution test
WARNING: program timed out.
FAIL: 30_threads/async/42819.cc execution test
WARNING: program timed out.
FAIL: 30_threads/async/49668.cc execution test
WARNING: program timed out.
FAIL: 30_threads/async/any.cc execution test
WARNING: program timed out.
FAIL: 30_threads/async/async.cc execution test
WARNING: program timed out.
FAIL: 30_threads/condition_variable/members/3.cc execution test
FAIL: 30_threads/shared_timed_mutex/try_lock/3.cc execution test
WARNING: program timed out.
FAIL: 30_threads/thread/native_handle/cancel.cc execution test
FAIL: 30_threads/timed_mutex/try_lock_until/57641.cc execution test
FAIL: tr1/8_c_compatibility/complex/50880.cc (test for excess errors)
WARNING: tr1/8_c_compatibility/complex/50880.cc compilation failed to 
produce executable

FAIL: tr1/8_c_compatibility/complex/functions.cc (test for excess errors)
Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp 
...
Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-xmethods/xmethods.exp 
...


=== libstdc++ Summary ===

# of expected passes9029
# of unexpected failures24
# of expected failures  65
# of unsupported tests  726

Biggest issue: the thread cancel/exit problems. Since this is not an 
issue with the thread model, I will commit the patch tomorrow if nobody 
objects.


--
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] [RTEMS] Update RTEMS thread model

[Sebastian Huber]

On 02/09/15 02:50, Chris Johns wrote:

On 1/09/2015 8:52 pm, Daniel Gutson wrote:

>
>El 31/7/2015 3:28, "Chris Johns" <chr...@rtems.org
><mailto:chr...@rtems.org>> escribió:

>>
>>On 31/07/2015 4:11 pm, Sebastian Huber wrote:

>> >For synchronization objects use the self-contained objects available via
>> >Newlib .
>> >
>> >

>https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=ecaef05f6601f1e8acb78fb65b411a258f39988a

>> >
>> >Enable the C++11 threads using .  So, the threads are only
>> >supported in case the POSIX API is enabled in RTEMS.  In the long run
>> >support for thread join and detach should be added to the API
>> >independent RTEMS services.
>> >

>>
>>Is this for 4.12 ?
>>
>>What happens if I build RTEMS with --disable-posix ? If I use locale in
>>C++ it pulls in the 'once' support which pulls in this file which would
>>give unresolved externals. There is a PR against me for libstdc++ not
>>checking the return code. Is it time for the --enable-posix option to go
>>and to always nave it enabled ?

>
>Please don't. The POSIX layer takes valuable resurces and it is not
>always needed.
>

Maybe we should look into this and fix the reasons. Any code not
required should not be included. This is an on going effort in RTEMS and
it requires we expose the cases.


We have all the infrastructure to fix this. One part is

CFLAGS += -ffunction-sections -fdata-sections
LDFLAGS += -Wl,--gc-sections

The other part a linker set based initialization (fully implemented in 
libbsd). One issue is that we have to add support for this in all linker 
command files. So we need just someone who has time 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

Re: Outstanding Issues on 4.11 branch?

[Sebastian Huber]

Hello,

On 01/08/15 19:17, Joel Sherrill wrote:

Hi

There are a couple of issues I know of like
ticket 2376 (tftp ticket really needs a patch)
and some site administration to do.

But does anyone have any outstanding issues?


we still have no up to date 4.11 manuals on the rtems.org website.

I have no outstanding patches for the 4.11 branch. What else prevents 
the release?


--
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: Uniprocessor implementation of nested mutex problem of priority inversion.

[Sebastian Huber]

bh Gadia
>>>>>
>>>>> On Thu, Aug 13, 2015 at 9:10 AM, Saurabh Gadia
<ga...@usc.edu <mailto:ga...@usc.edu>> wrote:
>>>>>>
>>>>>> That is how we were doing in JPF. The validate method was
triggered
>>>>>> after every release of mutex by any thread and we would
check for all the
>>>>>> waiting threads on mutex's held by the holder. And if it
finds a thread with
>>>>>> higher priority blocked then it would panic or give
assertion failure.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Saurabh Gadia
>>>>>>
>>>>>> On Thu, Aug 13, 2015 at 9:08 AM, Gedare Bloom
<ged...@rtems.org <mailto:ged...@rtems.org>> wrote:
>>>>>>>
>>>>>>> Thanks. Would it be possible for you to turn the failure
cases into
>>>>>>> real test failures? In other words, add some logic to
detect the
>>>>>>> priority inversion and abort the test?
>>>>>>>
>>>>>>> Gedare
>>>>>>>
>>>>>>> On Thu, Aug 13, 2015 at 12:05 PM, Saurabh Gadia
<ga...@usc.edu <mailto:ga...@usc.edu>> wrote:
>>>>>>> > Hi,
>>>>>>> >
>>>>>>> > Following is the result of spsem04 test without the patch:
>>>>>>> >
>>>>>>> > *** BEGIN OF TEST SPSEM 4 ***
>>>>>>> >
>>>>>>> > init: S0 created
>>>>>>> >
>>>>>>> > init: S1 created
>>>>>>> >
>>>>>>> > init: TA01 created with priority 36
>>>>>>> >
>>>>>>> > init: TA02 created with priority 34
>>>>>>> >
>>>>>>> > init: TA03 created with priority 32
>>>>>>> >
>>>>>>> > TA01: started with priority 36
>>>>>>> >
>>>>>>> > TA01: priority 36, holding S0
>>>>>>> >
>>>>>>> > TA02: started with priority 34
>>>>>>> >
>>>>>>> > TA02: priority 34, holding S1
>>>>>>> >
>>>>>>> > TA01: priority 34, holding S0 and now creating TA03
>>>>>>> >
>>>>>>> > TA03: started with priority 32
>>>>>>> >
>>>>>>> > TA01: priority 34 Releasing s0 (This is priority
inheritance problem
>>>>>>> > as TA02
>>>>>>> > waits on mutex held by TA01 and has higher priority than
TA01. TA03
>>>>>>> > just
>>>>>>> > promotes the priority TA02.)
>>>>>>> >
>>>>>>> > TA02: priority 32, holding S1,S0
>>>>>>> >
>>>>>>> > TA02: priority 32 before releasing S0
>>>>>>> >
>>>>>>> > TA02: priority 32 after releasing S0
>>>>>>> >
>>>>>>> > TA02: priority 32 before releasing S1
>>>>>>> >
>>>>>>> > TA03: priority 32, holding S1
>>>>>>> >
>>>>>>> > TA03: priority 32
>>>>>>> >
>>>>>>> > TA03: suspending
>>>>>>> >
>>>>>>> > TA02: priority 34 after releasing S1
>>>>>>> >
>>>>>>> > TA02: suspending
>>>>>>> >
>>>>>>> > TA01: priority 36
>>>>>>> >
>>>>>>> > TA01: exiting
>>>>>>> >
>>>>>>> > *** END OF TEST SPSEM 4 ***
>>>>>>> >
>>>>>>> > You can see the difference in highlighted portions of
both outputs.
>>>>>>> >
>>>>>>> > Thanks,
>>>>>>> >
>>>>>>> > Saurabh Gadia
>>>>>>> >
>>>>>>> > On Thu, Aug 13, 2015 at 8:17 AM, Saurabh Gadia
<ga...@usc.edu <mailto:ga...@usc.edu>> wrote:
>>>>>>> >>
>>>>>>> >> Ok. I will mail you back soon.
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> On Thursday, August 13, 2015, Gedare Bloom
<ged...@rtems.org <mailto:ged...@rtems.org>> wrote:
>>>>>>> >>>
>>>>>>> >>> Saurabh,
>>>>>>> >>>
>>>>>>> >>> Please pull from rtems.git again, create a new branch from
>>>>>>> >>> 'master',
>>>>>>> >>> and apply your changes to the branch. It's too hard to
review code
>>>>>>> >>> that is not all by itself on a branch.
>>>>>>> >>>
>>>>>>> >>> Gedare
>>>>>>> >>>
>>>>>>> >>> On Thu, Aug 13, 2015 at 5:28 AM, Saurabh Gadia
<ga...@usc.edu <mailto:ga...@usc.edu>>
>>>>>>> >>> wrote:
>>>>>>> >>> > Hi,
>>>>>>> >>> >
>>>>>>> >>> > I have implemented uniprocessor model of nested
mutex problem in
>>>>>>> >>> > rtems.
>>>>>>> >>> > its
>>>>>>> >>> > still in basic form. I tried to multiplex it with
the existing
>>>>>>> >>> > solution
>>>>>>> >>> > but
>>>>>>> >>> > was finding hard time. To push ahead, I decided to
have separate
>>>>>>> >>> > functions
>>>>>>> >>> > for uniprocessor and SMP(kept default behavior) and
with your
>>>>>>> >>> > review
>>>>>>> >>> > comments will know what to do. Following is the link
for the git
>>>>>>> >>> > repo:
>>>>>>> >>> >
https://github.com/saurabhgadia4/rtems/commits/master and its JPF
>>>>>>> >>> > branch:
>>>>>>> >>> >
>>>>>>> >>> >
>>>>>>> >>> >

https://github.com/saurabhgadia4/lock-model/blob/uniproc-new1/rtems/Mutex.java
>>>>>>> >>> >
>>>>>>> >>> > I have also tested spsem01, 02, 03 test cases.
Following are the
>>>>>>> >>> > links
>>>>>>> >>> > for
>>>>>>> >>> > the test case results which states output before
solution and
>>>>>>> >>> > after
>>>>>>> >>> > applying
>>>>>>> >>> > the solution. I am still not getting whether my code
is passing
>>>>>>> >>> > spsem03
>>>>>>> >>> > test
>>>>>>> >>> > or not. How can I verify that?
>>>>>>> >>> >
>>>>>>> >>> > Test Case Link:
>>>>>>> >>> >
>>>>>>> >>> >
>>>>>>> >>> >

https://drive.google.com/folderview?id=0B44HRKVuGCkFfnFDVmxqQzZZUzljNUg4YmVPZmEybEp2Q0NNclpvS2FvemZ4Tm5Xa19nemM=sharing
>>>>>>> >>> >
>>>>>>> >>> > Thanks,
>>>>>>> >>> >
>>>>>>> >>> > Saurabh Gadia
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> --
>>>>>>> >> Thanks,
>>>>>>> >>
>>>>>>> >> Saurabh Gadia
>>>>>>> >>
>>>>>>> >
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Regards,
>> Cyrille Artho
>
>
>
> --
> Regards,
> Cyrille Artho




--
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 for nested mutex project solving priority inversion problem for uniprocessor.

[Sebastian Huber]

On 07/09/15 08:32, Cyrille Artho wrote:

Hi Sebastian,
I was not aware that deadlock detection was an objective.


It would be good to first clarify the requirements for a new mutex 
implementation. This is why I created the ticket. It doesn't make sense 
to add something which will be replaced in some months if we add OMIP 
support.



Cyclic lock usage could be detected but performance would decrease.


I think cyclic lock usage detection will be a simple side-effect of the 
horizontal nesting support. On SMP this is crucial since otherwise we 
may end up in a deadlock at spin lock level and this is bad.



Furthermore, this would also create possible issues with scheduling
fairness, so we would have to discuss that first.


What do you mean with scheduling fairness problems?


Deadlock detection for shared conditionals would be difficult, at
least in the general case.

On Mon, Sep 7, 2015 at 3:04 PM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:

Hello Saurabh,

On 05/09/15 01:52, Saurabh Gadia wrote:

This is the patch for solving priority inversion problem for uniprocessor
architecture. It works correctly for all test cases on master. For 4.11 the
patch get applied cleanly but the branch does not compile because of some
rbtree error(unrelated to project). Github link:
https://github.com/saurabhgadia4/rtems/tree/nested-mutex


I reviewed your patch. Basically you replaced the LIFO list of priorities
with a sorted list? Does it work with timeouts and external priority changes
(e.g. task A blocks on a mutex owned by O, another task B raises the
priority of A, will this raise the priority of O?)

Since all tests pass, test sptests/spsem03 passes, which shows that your
implementation doesn't support horizontal nesting.

There is no deadlock detection.

Please have a look at:

https://devel.rtems.org/ticket/2412

I think the suggested implementation would even work on SMP systems quite
well.

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

Re: Patch for nested mutex project solving priority inversion problem for uniprocessor.

[Sebastian Huber]

Hello Saurabh,

On 05/09/15 01:52, Saurabh Gadia wrote:
This is the patch for solving priority inversion problem for 
uniprocessor architecture. It works correctly for all test cases on 
master. For 4.11 the patch get applied cleanly but the branch does not 
compile because of some rbtree error(unrelated to project). Github 
link: https://github.com/saurabhgadia4/rtems/tree/nested-mutex


I reviewed your patch. Basically you replaced the LIFO list of 
priorities with a sorted list? Does it work with timeouts and external 
priority changes (e.g. task A blocks on a mutex owned by O, another task 
B raises the priority of A, will this raise the priority of O?)


Since all tests pass, test sptests/spsem03 passes, which shows that your 
implementation doesn't support horizontal nesting.


There is no deadlock detection.

Please have a look at:

https://devel.rtems.org/ticket/2412

I think the suggested implementation would even work on SMP systems 
quite well.


--
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] [RTEMS] Update RTEMS thread model

[Sebastian Huber]

Committed:

https://gcc.gnu.org/viewcvs/gcc?view=revision=227428

--
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 3/4] score: Implement SMP specific priority queue

[Sebastian Huber]

---
 cpukit/sapi/include/confdefs.h |   7 +-
 cpukit/score/include/rtems/score/threadq.h |  44 +++-
 cpukit/score/include/rtems/score/threadqimpl.h |  16 ++
 cpukit/score/src/thread.c  |   3 +-
 cpukit/score/src/threadinitialize.c|   4 +-
 cpukit/score/src/threadqops.c  |  70 +-
 doc/user/smp.t |  54 
 testsuites/smptests/Makefile.am|   1 +
 testsuites/smptests/configure.ac   |   1 +
 testsuites/smptests/smpmutex01/Makefile.am |  19 ++
 testsuites/smptests/smpmutex01/init.c  | 326 +
 testsuites/smptests/smpmutex01/smpmutex01.doc  |  14 ++
 testsuites/smptests/smpmutex01/smpmutex01.scn  |   2 +
 13 files changed, 545 insertions(+), 16 deletions(-)
 create mode 100644 testsuites/smptests/smpmutex01/Makefile.am
 create mode 100644 testsuites/smptests/smpmutex01/init.c
 create mode 100644 testsuites/smptests/smpmutex01/smpmutex01.doc
 create mode 100644 testsuites/smptests/smpmutex01/smpmutex01.scn

diff --git a/cpukit/sapi/include/confdefs.h b/cpukit/sapi/include/confdefs.h
index 4b438ff..66c8c7e 100644
--- a/cpukit/sapi/include/confdefs.h
+++ b/cpukit/sapi/include/confdefs.h
@@ -1008,9 +1008,10 @@ const rtems_libio_helper rtems_fs_init_helper =
 CONFIGURE_SCHEDULER_CONTROLS
   };
 
+  #define CONFIGURE_SCHEDULER_COUNT RTEMS_ARRAY_SIZE( _Scheduler_Table )
+
   #if defined(RTEMS_SMP)
-const size_t _Scheduler_Count =
-  RTEMS_ARRAY_SIZE( _Scheduler_Table );
+const size_t _Scheduler_Count = CONFIGURE_SCHEDULER_COUNT;
 
 const Scheduler_Assignment _Scheduler_Assignments[] = {
   #if defined(CONFIGURE_SMP_SCHEDULER_ASSIGNMENTS)
@@ -2970,7 +2971,7 @@ const rtems_libio_helper rtems_fs_init_helper =
   ( \
 _Configure_Object_RAM(_tasks, sizeof(Configuration_Thread_control)) \
   + _Configure_From_workspace(_Configure_Max_Objects(_tasks) \
-* sizeof(Thread_queue_Heads)) \
+* THREAD_QUEUE_HEADS_SIZE(CONFIGURE_SCHEDULER_COUNT)) \
   + _Configure_Max_Objects(_number_FP_tasks) \
 * _Configure_From_workspace(CONTEXT_FP_SIZE) \
   )
diff --git a/cpukit/score/include/rtems/score/threadq.h 
b/cpukit/score/include/rtems/score/threadq.h
index 2b58310..a877c4e 100644
--- a/cpukit/score/include/rtems/score/threadq.h
+++ b/cpukit/score/include/rtems/score/threadq.h
@@ -42,6 +42,26 @@ extern "C" {
 typedef struct _Thread_Control Thread_Control;
 
 /**
+ * @brief Thread priority queue.
+ */
+typedef struct {
+#if defined(RTEMS_SMP)
+  /**
+   * @brief Node to enqueue this queue in the FIFO chain of the corresponding
+   * heads structure.
+   *
+   * @see Thread_queue_Heads::Heads::Fifo.
+   */
+  Chain_Node Node;
+#endif
+
+  /**
+   * @brief The actual thread priority queue.
+   */
+  RBTree_Control Queue;
+} Thread_queue_Priority_queue;
+
+/**
  * @brief Thread queue heads.
  *
  * Each thread is equipped with spare thread queue heads in case it not
@@ -61,13 +81,19 @@ typedef struct _Thread_queue_Heads {
   union {
 /**
  * @brief This is the FIFO discipline list.
+ *
+ * On SMP configurations this FIFO is used to enqueue the per scheduler
+ * instance priority queues of this structure.  This ensures FIFO fairness
+ * among the highest priority thread of each scheduler instance.
  */
 Chain_Control Fifo;
 
+#if !defined(RTEMS_SMP)
 /**
  * @brief This is the set of threads for priority discipline waiting.
  */
-RBTree_Control Priority;
+Thread_queue_Priority_queue Priority;
+#endif
   } Heads;
 
   /**
@@ -81,8 +107,24 @@ typedef struct _Thread_queue_Heads {
* the thread queue heads dedicated to the thread queue of an object.
*/
   Chain_Node Free_node;
+
+#if defined(RTEMS_SMP)
+  /**
+   * @brief One priority queue per scheduler instance.
+   */
+  Thread_queue_Priority_queue Priority[ RTEMS_ZERO_LENGTH_ARRAY ];
+#endif
 } Thread_queue_Heads;
 
+#if defined(RTEMS_SMP)
+  #define THREAD_QUEUE_HEADS_SIZE( scheduler_count ) \
+( sizeof( Thread_queue_Heads ) \
+  + ( scheduler_count ) * sizeof( Thread_queue_Priority_queue ) )
+#else
+  #define THREAD_QUEUE_HEADS_SIZE( scheduler_count ) \
+sizeof( Thread_queue_Heads )
+#endif
+
 typedef struct {
   /**
* @brief The thread queue heads.
diff --git a/cpukit/score/include/rtems/score/threadqimpl.h 
b/cpukit/score/include/rtems/score/threadqimpl.h
index 3828f41..bf01eb7 100644
--- a/cpukit/score/include/rtems/score/threadqimpl.h
+++ b/cpukit/score/include/rtems/score/threadqimpl.h
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef __cplusplus
@@ -51,6 +52,21 @@ typedef struct {
 #endif
 } Thread_queue_Syslock_queue;
 
+RTEMS_INLINE_ROUTINE void _Thread_queue_Heads_initialize(
+  Thread_queue_Heads *heads
+)
+{
+#if defined(RTEMS_SMP)
+  size_t i;
+
+  for ( i = 0; i < _Scheduler_Count; ++i ) {
+_RBTree_Initialize_empty( >Priority[ i ].Queue );
+  }

[PATCH 1/4] smp: Documentation

[Sebastian Huber]

---
 doc/user/smp.t | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/doc/user/smp.t b/doc/user/smp.t
index 1b4849a..ba700e0 100644
--- a/doc/user/smp.t
+++ b/doc/user/smp.t
@@ -147,6 +147,44 @@ another processor.  So if we enable interrupts during this 
transition we have
 to provide an alternative task independent stack for this time frame.  This
 issue needs further investigation.
 
+@subsection Clustered/Partitioned Scheduling
+
+We have clustered scheduling in case the set of processors of a system is
+partitioned into non-empty pairwise-disjoint subsets. These subsets are called
+clusters.  Clusters with a cardinality of one are partitions.  Each cluster is
+owned by exactly one scheduler instance.
+
+Clustered/partitioned scheduling helps to control the worst-case latencies in
+the system, see @cite{Brandenburg, Bj??rn B.: Scheduling and Locking in
+Multiprocessor Real-Time Operating Systems. PhD thesis, 2011.
+@uref{http://www.cs.unc.edu/~bbb/diss/brandenburg-diss.pdf}}.  The goal is to
+reduce the amount of shared state in the system and thus prevention of lock
+contention. Modern multi-processor systems tend to have several layers of data
+and instruction caches. With clustered/partitioned scheduling it is possible to
+honour the cache topology of a system and thus avoid expensive cache
+synchronization traffic.  It is easy to implement.  The problem is to provide
+synchronization primitives for inter-partition synchronization. In RTEMS there
+are currently three means available
+
+@itemize @bullet
+@item events,
+@item message queues, and
+@item semaphores using the @ref{Semaphore Manager Multiprocessor Resource
+Sharing Protocol} (MrsP).
+@end itemize
+
+The clustered/partitioned scheduling approach enables separation of functions
+with real-time requirements and functions that profit from fairness and high
+throughput provided the scheduler instances are fully decoupled and adequate
+intra-partition synchronization primitives are used.  This is work in progress.
+
+For the configuration of clustered/partitioned schedulers see @ref{Configuring
+a System Configuring Clustered/Partitioned Schedulers}.
+
+To set the scheduler of a task see @ref{Symmetric Multiprocessing Services
+SCHEDULER_IDENT - Get ID of a scheduler} and @ref{Symmetric Multiprocessing
+Services TASK_SET_SCHEDULER - Set scheduler of a task}.
+
 @subsection Scheduler Helping Protocol
 
 The scheduler provides a helping protocol to support locking protocols like
-- 
1.8.4.5

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

[PATCH 2/4] score: Documentation

[Sebastian Huber]

---
 cpukit/score/include/rtems/score/threadq.h | 31 --
 1 file changed, 29 insertions(+), 2 deletions(-)

diff --git a/cpukit/score/include/rtems/score/threadq.h 
b/cpukit/score/include/rtems/score/threadq.h
index 8f2b138..2b58310 100644
--- a/cpukit/score/include/rtems/score/threadq.h
+++ b/cpukit/score/include/rtems/score/threadq.h
@@ -44,6 +44,13 @@ typedef struct _Thread_Control Thread_Control;
 /**
  * @brief Thread queue heads.
  *
+ * Each thread is equipped with spare thread queue heads in case it not
+ * enqueued on a thread queue.  The first thread enqueued on a thread queue
+ * will give its spare thread queue heads to this thread queue.  The threads
+ * arriving at the queue will add their thread queue heads to the free chain of
+ * the queue heads provided by the first thread enqueued.  Once a thread is
+ * dequeued it use the free chain to get new spare thread queue heads.
+ *
  * Uses a leading underscore in the structure name to allow forward
  * declarations in standard header files provided by Newlib and GCC.
  */
@@ -52,18 +59,38 @@ typedef struct _Thread_queue_Heads {
*  set of tasks which varies based upon the discipline.
*/
   union {
-/** This is the FIFO discipline list. */
+/**
+ * @brief This is the FIFO discipline list.
+ */
 Chain_Control Fifo;
-/** This is the set of threads for priority discipline waiting. */
+
+/**
+ * @brief This is the set of threads for priority discipline waiting.
+ */
 RBTree_Control Priority;
   } Heads;
 
+  /**
+   * @brief A chain with free thread queue heads providing the spare thread
+   * queue heads for a thread once it is dequeued.
+   */
   Chain_Control Free_chain;
 
+  /**
+   * @brief A chain node to add these thread queue heads to the free chain of
+   * the thread queue heads dedicated to the thread queue of an object.
+   */
   Chain_Node Free_node;
 } Thread_queue_Heads;
 
 typedef struct {
+  /**
+   * @brief The thread queue heads.
+   *
+   * This pointer is NULL, if and only if no threads are enqueued.  The first
+   * thread to enqueue will give its spare thread queue heads to this thread
+   * queue.
+   */
   Thread_queue_Heads *heads;
 
   /**
-- 
1.8.4.5

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

[PATCH 4/4] score: Implement priority boosting

[Sebastian Huber]

---
 cpukit/score/include/rtems/score/threadimpl.h  | 31 +
 cpukit/score/include/rtems/score/threadqimpl.h | 25 +++
 cpukit/score/src/coremutexseize.c  |  2 +-
 cpukit/score/src/coremutexsurrender.c  |  1 +
 cpukit/score/src/mutex.c   | 15 ---
 cpukit/score/src/threadchangepriority.c| 34 ++
 cpukit/score/src/threadqops.c  | 22 ++
 doc/user/sem.t |  5 +++
 doc/user/smp.t |  6 ++-
 testsuites/smptests/smpmutex01/init.c  | 61 +++---
 10 files changed, 189 insertions(+), 13 deletions(-)

diff --git a/cpukit/score/include/rtems/score/threadimpl.h 
b/cpukit/score/include/rtems/score/threadimpl.h
index 4656881..1092b65 100644
--- a/cpukit/score/include/rtems/score/threadimpl.h
+++ b/cpukit/score/include/rtems/score/threadimpl.h
@@ -437,6 +437,37 @@ void _Thread_Raise_priority(
 );
 
 /**
+ * @brief Inherit the priority of a thread.
+ *
+ * It changes the current priority of the inheritor thread to the current 
priority
+ * of the ancestor thread if it is higher than the current priority of the 
inheritor
+ * thread.  In this case the inheritor thread is appended to its new priority 
group
+ * in its scheduler instance.
+ *
+ * On SMP configurations, the priority is changed to PRIORITY_PSEUDO_ISR in
+ * case the own schedulers of the inheritor and ancestor thread differ 
(priority
+ * boosting).
+ *
+ * @param[in] inheritor The thread to inherit the priority.
+ * @param[in] ancestor The thread to bequeath its priority to the inheritor
+ *   thread.
+ */
+#if defined(RTEMS_SMP)
+void _Thread_Inherit_priority(
+  Thread_Control *inheritor,
+  Thread_Control *ancestor
+);
+#else
+RTEMS_INLINE_ROUTINE void _Thread_Inherit_priority(
+  Thread_Control *inheritor,
+  Thread_Control *ancestor
+)
+{
+  _Thread_Raise_priority( inheritor, ancestor->current_priority );
+}
+#endif
+
+/**
  * @brief Sets the current to the real priority of a thread.
  *
  * Sets the priority restore hint to false.
diff --git a/cpukit/score/include/rtems/score/threadqimpl.h 
b/cpukit/score/include/rtems/score/threadqimpl.h
index bf01eb7..510f886 100644
--- a/cpukit/score/include/rtems/score/threadqimpl.h
+++ b/cpukit/score/include/rtems/score/threadqimpl.h
@@ -522,6 +522,31 @@ RTEMS_INLINE_ROUTINE void _Thread_queue_Destroy(
 }
 
 /**
+ * @brief Boosts the priority of the thread if threads of another scheduler
+ * instance are enqueued on the thread queue.
+ *
+ * The thread queue must use the priority waiting discipline.
+ *
+ * @param[in] queue The actual thread queue.
+ * @param[in] the_thread The thread to boost the priority if necessary.
+ */
+#if defined(RTEMS_SMP)
+void _Thread_queue_Boost_priority(
+  Thread_queue_Queue *queue,
+  Thread_Control *the_thread
+);
+#else
+RTEMS_INLINE_ROUTINE void _Thread_queue_Boost_priority(
+  Thread_queue_Queue *queue,
+  Thread_Control *the_thread
+)
+{
+  (void) queue;
+  (void) the_thread;
+}
+#endif
+
+/**
  * @brief Compare two thread's priority for RBTree Insertion.
  *
  * @param[in] left points to the left thread's RBnode
diff --git a/cpukit/score/src/coremutexseize.c 
b/cpukit/score/src/coremutexseize.c
index ddc5d6b..8059659 100644
--- a/cpukit/score/src/coremutexseize.c
+++ b/cpukit/score/src/coremutexseize.c
@@ -75,7 +75,7 @@ void _CORE_mutex_Seize_interrupt_blocking(
 _Thread_queue_Release( _mutex->Wait_queue, lock_context );
 #endif
 
-_Thread_Raise_priority( holder, executing->current_priority );
+_Thread_Inherit_priority( holder, executing );
 
 #if !defined(RTEMS_SMP)
 _Thread_queue_Acquire( _mutex->Wait_queue, lock_context );
diff --git a/cpukit/score/src/coremutexsurrender.c 
b/cpukit/score/src/coremutexsurrender.c
index d3f965d..7d9c57f 100644
--- a/cpukit/score/src/coremutexsurrender.c
+++ b/cpukit/score/src/coremutexsurrender.c
@@ -209,6 +209,7 @@ CORE_mutex_Status _CORE_mutex_Surrender(
 case CORE_MUTEX_DISCIPLINES_PRIORITY_INHERIT:
   _CORE_mutex_Push_priority( the_mutex, the_thread );
   the_thread->resource_count++;
+  _Thread_queue_Boost_priority( _mutex->Wait_queue.Queue, 
the_thread );
   break;
 case CORE_MUTEX_DISCIPLINES_PRIORITY_CEILING:
   _CORE_mutex_Push_priority( the_mutex, the_thread );
diff --git a/cpukit/score/src/mutex.c b/cpukit/score/src/mutex.c
index ae637dd..f03bab7 100644
--- a/cpukit/score/src/mutex.c
+++ b/cpukit/score/src/mutex.c
@@ -112,9 +112,7 @@ static void _Mutex_Acquire_slow(
   ISR_lock_Context  *lock_context
 )
 {
-  /* Priority inheritance */
-  _Thread_Raise_priority( owner, executing->current_priority );
-
+  _Thread_Inherit_priority( owner, executing );
   _Thread_queue_Enqueue_critical(
 >Queue.Queue,
 MUTEX_TQ_OPERATIONS,
@@ -136,15 +134,22 @@ static void _Mutex_Release_slow(
 {
   if (heads != NULL) {
 const Thread_queue_Operations *operations;
-

Re: [PATCH] [RTEMS] Update RTEMS thread model

[Sebastian Huber]

On 02/09/15 13:27, Daniel Gutson wrote:



El 2/9/2015 5:17, "Sebastian Huber" 
<sebastian.hu...@embedded-brains.de 
<mailto:sebastian.hu...@embedded-brains.de>> escribió:

>
>
>
> On 01/09/15 13:05, Sebastian Huber wrote:
>>
>> On 01/09/15 12:10, Sebastian Huber wrote:
>>>
>>> Shared mutexes are not implemented in general.
>>
>>
>> This works now also:
>>
>> https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00027.html
>>
>
> With this additional fix:
>
> https://gcc.gnu.org/ml/gcc/2015-09/msg00021.html
>
> We have these results:
>
>
> Target is arm-unknown-rtems4.11
> Host   is arm-unknown-rtems4.11
> Build  is x86_64-pc-linux-gnu
>
> === libstdc++ tests ===
>
> Schedule of variations:
> 
rtems-arm-realview_pbx_a9_qemu/-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard

>
> Running target 
rtems-arm-realview_pbx_a9_qemu/-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard

>
> Using 
/scratch/git-rtems-testing/dejagnu/boards/rtems-arm-realview_pbx_a9_qemu.exp 
as board description file for target.
> Using /usr/share/dejagnu/config/sim.exp as generic interface file 
for target.
> Using /usr/share/dejagnu/baseboards/basic-sim.exp as board 
description file for target.
> Using 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/config/default.exp 
as tool-and-target-specific interface file.
> Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-abi/abi.exp 
...
> Running 
/home/EB/sebastian_h/archive/gcc-git/libstdc++-v3/testsuite/libstdc++-dg/conformance.exp 
...

> FAIL: 25_algorithms/copy/streambuf_iterators/wchar_t/4.cc execution test
> FAIL: 25_algorithms/find/istreambuf_iterators/wchar_t/2.cc execution 
test

> FAIL: 25_algorithms/random_shuffle/moveable.cc execution test

I'm very interested in this last one. Is this an XFail? Could you 
please post both the dejagnu test and the output?
We use move semantics everywhere and I'd want to be sure it's working 
OK. Specially since this doesn't seem to be related to concurrency but 
just algorithms.




I deleted the test tree. It will take a couple of days before I create a 
new one. I think it makes more sense if you run the tests yourself, so 
that you can debug them. I use the realview_pbx_a9_qemu BSP for this, 
since it is very easy to debug.


--
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] [RTEMS] Update RTEMS thread model

[Sebastian Huber]

On 02/09/15 13:32, Daniel Gutson wrote:



El 2/9/2015 5:28, "Sebastian Huber" 
<sebastian.hu...@embedded-brains.de 
<mailto:sebastian.hu...@embedded-brains.de>> escribió:

>
>
>
> On 02/09/15 02:50, Chris Johns wrote:
>>
>> On 1/09/2015 8:52 pm, Daniel Gutson wrote:
>>>
>>> >
>>> >El 31/7/2015 3:28, "Chris Johns" <chr...@rtems.org 
<mailto:chr...@rtems.org>

>>> ><mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> escribió:
>>>>
>>>> >>
>>>> >>On 31/07/2015 4:11 pm, Sebastian Huber wrote:
>>>>>
>>>>> >> >For synchronization objects use the self-contained objects 
available via

>>>>> >> >Newlib .
>>>>> >> >
>>>>> >> >
>>>
>>> 
>https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commit;h=ecaef05f6601f1e8acb78fb65b411a258f39988a

>>>>>
>>>>> >> >
>>>>> >> >Enable the C++11 threads using .  So, the threads 
are only
>>>>> >> >supported in case the POSIX API is enabled in RTEMS.  In the 
long run

>>>>> >> >support for thread join and detach should be added to the API
>>>>> >> >independent RTEMS services.
>>>>> >> >
>>>>
>>>> >>
>>>> >>Is this for 4.12 ?
>>>> >>
>>>> >>What happens if I build RTEMS with --disable-posix ? If I use 
locale in
>>>> >>C++ it pulls in the 'once' support which pulls in this file 
which would
>>>> >>give unresolved externals. There is a PR against me for 
libstdc++ not
>>>> >>checking the return code. Is it time for the --enable-posix 
option to go

>>>> >>and to always nave it enabled ?
>>>
>>> >
>>> >Please don't. The POSIX layer takes valuable resurces and it is not
>>> >always needed.
>>> >
>>
>> Maybe we should look into this and fix the reasons. Any code not
>> required should not be included. This is an on going effort in 
RTEMS and

>> it requires we expose the cases.
>
>
> We have all the infrastructure to fix this. One part is
>
> CFLAGS += -ffunction-sections -fdata-sections
> LDFLAGS += -Wl,--gc-sections
>
> The other part a linker set based initialization (fully implemented 
in libbsd). One issue is that we have to add support for this in all 
linker command files. So we need just someone who has time to do this.


Could you please create a ticket for this dumping all the useful 
informatiom you have in your head there :) since we are interested so 
we'll likely do it, and any further question can be discussed in the 
ticket.




https://devel.rtems.org/ticket/2407
https://devel.rtems.org/ticket/2408

--
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] smp: Documentation

[Sebastian Huber]

---
 doc/user/smp.t | 66 ++
 1 file changed, 66 insertions(+)

diff --git a/doc/user/smp.t b/doc/user/smp.t
index 2ab9aaf..a06be8a 100644
--- a/doc/user/smp.t
+++ b/doc/user/smp.t
@@ -465,6 +465,72 @@ architecture please consult the @cite{RTEMS CPU 
Architecture Supplement}.
 The only remaining user of task variables in the RTEMS code base is the Ada
 support.  So basically Ada is not available on RTEMS SMP.
 
+@subsection OpenMP
+
+OpenMP support for RTEMS is available via the GCC provided libgomp.  There is
+libgomp support for RTEMS in the POSIX configuration since GCC 4.9 (requires a
+Newlib snapshot after 2015-03-12). In GCC 6.1 or later (requires a Newlib
+snapshot after 2015-07-30 for  provided self-contained
+synchronization objects) there is RTEMS support in a RTEMS specific
+configuration which offers a significantly better performance compared to the
+POSIX configuration (the term configuration refers here to the libgomp
+configuration and should not be confused with the POSIX API provided by RTEMS).
+In addition scheduler instance specific thread pools may be defined.
+
+The run-time configuration of libgomp is done via environment variables
+documented in the @uref{https://gcc.gnu.org/onlinedocs/libgomp/, libgomp
+manual}.  The environment variables are evaluated in a constructor function
+which executes in the context of the first initialization task before the
+actual initialization task function is called (just like a global C++
+constructor).  To set application specific values, a higher priority
+constructor function must be used to set up the environment variables.
+
+@example
+@group
+#include 
+
+static void __attribute__((constructor(1000))) config_libgomp( void )
+@{
+  setenv( "OMP_DISPLAY_ENV", "VERBOSE", 1 );
+  setenv( "GOMP_SPINCOUNT", "3", 1 );
+  setenv( "GOMP_RTEMS_THREAD_POOLS", "1$2@@SCHD", 1 );
+@}
+@end group
+@end example
+
+The environment variable @env{GOMP_RTEMS_THREAD_POOLS} is RTEMS specific.  It
+determines the scheduler instance specific thread pools.  The format for
+@env{GOMP_RTEMS_THREAD_POOLS} is a list of optional
+@code{[$]@@} configurations
+separated by @code{:} where:
+
+@itemize @bullet
+@item @code{} is the thread pool count for this scheduler
+instance.
+@item @code{$} is an optional priority for the worker threads of a
+thread pool according to @code{pthread_setschedparam}.  In case a priority
+value is omitted, then a worker thread will inherit the priority of the OpenMP
+master thread that created it.  The priority of the worker thread is not
+changed after creation, even if a new OpenMP master thread using the worker has
+a different priority.
+@item @code{@@} is the scheduler instance name according to the
+RTEMS application configuration.
+@end itemize
+
+In case no thread pool configuration is specified for a scheduler instance,
+then each OpenMP master thread of this scheduler instance will use its own
+dynamically allocated thread pool.  To limit the worker thread count of the
+thread pools, each OpenMP master thread must call @code{omp_set_num_threads}.
+
+Lets suppose we have three scheduler instances @code{IO}, @code{WRK0}, and
+@code{WRK1} with @env{GOMP_RTEMS_THREAD_POOLS} set to
+@code{"1@@WRK0:3$4@@WRK1"}.  Then there are no thread pool restrictions for
+scheduler instance @code{IO}.  In the scheduler instance @code{WRK0} there is
+one thread pool available.  Since no priority is specified for this scheduler
+instance, the worker thread inherits the priority of the OpenMP master thread
+that created it.  In the scheduler instance @code{WRK1} there are three thread
+pools available and their worker threads run at priority four.
+
 @subsection Thread Dispatch Details
 
 This section gives background information to developers interested in the
-- 
1.8.4.5

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

Re: [PATCH 1/4] smp: Documentation

[Sebastian Huber]

On 03/09/15 16:59, Gedare Bloom wrote:

On Thu, Sep 3, 2015 at 8:01 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de>  wrote:

>---
>  doc/user/smp.t | 38 ++
>  1 file changed, 38 insertions(+)
>
>diff --git a/doc/user/smp.t b/doc/user/smp.t
>index 1b4849a..ba700e0 100644
>--- a/doc/user/smp.t
>+++ b/doc/user/smp.t
>@@ -147,6 +147,44 @@ another processor.  So if we enable interrupts during 
this transition we have
>  to provide an alternative task independent stack for this time frame.  This
>  issue needs further investigation.
>
>+@subsection Clustered/Partitioned Scheduling
>+
>+We have clustered scheduling in case the set of processors of a system is
>+partitioned into non-empty pairwise-disjoint subsets. These subsets are called
>+clusters.  Clusters with a cardinality of one are partitions.  Each cluster is
>+owned by exactly one scheduler instance.
>+
>+Clustered/partitioned scheduling helps to control the worst-case latencies in
>+the system, see @cite{Brandenburg, Björn B.: Scheduling and Locking in
>+Multiprocessor Real-Time Operating Systems. PhD thesis, 2011.
>+@uref{http://www.cs.unc.edu/~bbb/diss/brandenburg-diss.pdf}}.  The goal is to
>+reduce the amount of shared state in the system and thus prevention of lock
>+contention. Modern multi-processor systems tend to have several layers of data
>+and instruction caches. With clustered/partitioned scheduling it is possible 
to
>+honour the cache topology of a system and thus avoid expensive cache
>+synchronization traffic.  It is easy to implement.  The problem is to provide
>+synchronization primitives for inter-partition synchronization. In RTEMS there
>+are currently three means available
>+
>+@itemize @bullet
>+@item events,
>+@item message queues, and
>+@item semaphores using the @ref{Semaphore Manager Multiprocessor Resource
>+Sharing Protocol} (MrsP).
>+@end itemize
>+
>+The clustered/partitioned scheduling approach enables separation of functions
>+with real-time requirements and functions that profit from fairness and high
>+throughput provided the scheduler instances are fully decoupled and adequate
>+intra-partition synchronization primitives are used.  This is work in 
progress.

inter-partition? inter-partition doesn't make sense. Also, to be
general, it should really be inter-cluster, which goes for the above
use of "inter-partition" as well. Because of the use of partition in
Partitioned Scheduling, we have to be careful about the use of
partition in other places related to SMP scheduling, unfortunately.



Would it be better to replace "clustered/partitioned scheduling" with 
"clustered scheduling" throughout the manual and just mention that 
partitions are clusters with exactly one processor? So we have 
"inter-cluster synchronization" for synchronization that involves more 
than more cluster and "intra-cluster synchronization" for 
synchronization that involves exactly one cluster.


--
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] smp: Documentation

[Sebastian Huber]

On 03/09/15 17:09, Gedare Bloom wrote:

On Thu, Sep 3, 2015 at 8:46 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:

---
  doc/user/smp.t | 66 ++
  1 file changed, 66 insertions(+)

diff --git a/doc/user/smp.t b/doc/user/smp.t
index 2ab9aaf..a06be8a 100644
--- a/doc/user/smp.t
+++ b/doc/user/smp.t
@@ -465,6 +465,72 @@ architecture please consult the @cite{RTEMS CPU 
Architecture Supplement}.
  The only remaining user of task variables in the RTEMS code base is the Ada
  support.  So basically Ada is not available on RTEMS SMP.

+@subsection OpenMP
+
+OpenMP support for RTEMS is available via the GCC provided libgomp.  There is
+libgomp support for RTEMS in the POSIX configuration since GCC 4.9 (requires a
+Newlib snapshot after 2015-03-12). In GCC 6.1 or later (requires a Newlib
+snapshot after 2015-07-30 for  provided self-contained

Do these versions relate to any release versions of RTEMS, e.g. did
this stuff make it into the toolchains for 4.11? Translating between
gcc/newlib versions and RTEMS versions is a bit of work for casual
user to know if this support will be available or not for them.


In case the manual includes this section, then its supported by RTEMS. 
It helps to check if you use the right tool chain version. In general it 
would be nice to collect such information in a well known central place.





+synchronization objects) there is RTEMS support in a RTEMS specific

hyphenate: "RTEMS-specific" here and below.


+configuration which offers a significantly better performance compared to the

"libgomp configuration"


+POSIX configuration (the term configuration refers here to the libgomp
+configuration and should not be confused with the POSIX API provided by RTEMS).
+In addition scheduler instance specific thread pools may be defined.

Last sentence doesn't say why that matters. Perhaps just say something
about discussing this further below.


Hm, I wanted to say that the thread pools are new in GCC 6.1 and not 
available before.





+
+The run-time configuration of libgomp is done via environment variables
+documented in the @uref{https://gcc.gnu.org/onlinedocs/libgomp/, libgomp
+manual}.  The environment variables are evaluated in a constructor function
+which executes in the context of the first initialization task before the
+actual initialization task function is called (just like a global C++
+constructor).  To set application specific values, a higher priority

hyphenate: "application-specific"


+constructor function must be used to set up the environment variables.
+
+@example
+@group
+#include 
+
+static void __attribute__((constructor(1000))) config_libgomp( void )
+@{
+  setenv( "OMP_DISPLAY_ENV", "VERBOSE", 1 );
+  setenv( "GOMP_SPINCOUNT", "3", 1 );
+  setenv( "GOMP_RTEMS_THREAD_POOLS", "1$2@@SCHD", 1 );
+@}
+@end group
+@end example
+

The following discussion may warrant it's own subsection on Thread Pools.


+The environment variable @env{GOMP_RTEMS_THREAD_POOLS} is RTEMS specific.  It
+determines the scheduler instance specific thread pools.  The format for

hyphenate: "instance-specific"


Shouldn't this be "scheduler-instance-specific" ?

Maybe use "determines the thread pools for each scheduler instance".




+@env{GOMP_RTEMS_THREAD_POOLS} is a list of optional
+@code{[$]@@} configurations
+separated by @code{:} where:
+
+@itemize @bullet
+@item @code{} is the thread pool count for this scheduler
+instance.
+@item @code{$} is an optional priority for the worker threads of a
+thread pool according to @code{pthread_setschedparam}.  In case a priority
+value is omitted, then a worker thread will inherit the priority of the OpenMP
+master thread that created it.  The priority of the worker thread is not
+changed after creation, even if a new OpenMP master thread using the worker has

This statement "priority of the worker thread is not changed after
creation" probably is not accurate, in case of PIP/PCP or API calls to
change priority. It might be better to state that the priority is not
changed despite a change in the master thread?


The priority is implicitly the "real priority".  I think it is clear 
that protocols may do all sorts of stuff with the current priority of a 
thread.  Its not possible to change parameters of the worker threads by 
API calls.





+a different priority.
+@item @code{@@} is the scheduler instance name according to the
+RTEMS application configuration.
+@end itemize
+
+In case no thread pool configuration is specified for a scheduler instance,
+then each OpenMP master thread of this scheduler instance will use its own
+dynamically allocated thread pool.  To limit the worker thread count of the
+thread pools, each OpenMP master thread must call @code{omp_set_num_threads}.
+
+Lets suppose we have three scheduler i

[wwwdocs] GCC 6 Release Notes for RTEMS

[Sebastian Huber]

Index: htdocs/gcc-6/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
retrieving revision 1.25
diff -u -r1.25 changes.html
--- htdocs/gcc-6/changes.html   25 Aug 2015 22:27:46 -  1.25
+++ htdocs/gcc-6/changes.html   4 Sep 2015 06:21:14 -
@@ -203,6 +203,23 @@

 

+
+  
+The RTEMS thread model implementation changed.  For the mutexes
+self-contained objects defined in Newlib sys/lock.h are used
+instead of Classic API semaphores.  The keys for thread specific 
data and

+the once function are directly defined via pthread.h.
+Self-contained condition variables are provided via Newlib
+sys/lock.h.  The RTEMS thread model supports now the C++11
+threads.
+
+The OpenMP support uses now self-contained objects provided by 
Newlib
+sys/lock.h and offers a significantly better performance 
compared

+to the POSIX configuration of libgomp.  It is possible to
+configure thread pools for each scheduler instance via the environment
+variable GOMP_RTEMS_THREAD_POOLS.
+  
+
 


--
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] [RTEMS] Update RTEMS thread model

[Sebastian Huber]

On 03/09/15 15:47, Martin Galvan wrote:

Hi Sebastian! Thanks for your answer. There are a couple of things I
still don't get :)

On Thu, Sep 3, 2015 at 2:48 AM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:

I updated the rtems-testing repository.

1. You have to adjust the VERSIONS file.

Is this file meant to help the scripts download the tool sources
automatically (like RSB does), or does it just point to local
directories where I'm supposed to place them? If it downloads them
automatically, should I replace 'cvs' by 'git' for e.g. gdb?


GDB is managed by git and for GCC I would use the git mirror.




2. You need the latest Git versions of Newlib, GCC and RTEMS.

So I should manually build a cross-gcc from the gcc trunk? I think
that's past 5.2, will RTEMS build ok with that?

Also, should I apply the patch you posted here:

https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00019.html

?


No patches, just the latest versions, so GCC 6.0.




3. Use

./do_one -1 -r -g -v -M arm realview_pbx_a9_qemu

to run the GCC tests. Make sure the test runner "realview_pbx_a9_qemu"
works.

How can I test that? Should I build the realview_pbx_a9 BSP and run a
sample (e.g. ticker) on the latest Qemu?


The test runners are in "sim-scripts" make sure a "realview_pbx_a9_qemu 
-i ticker.exe" produces the expected output.





4. Use something similar

cd gcc/b-arm-gcc/arm-rtems4.11/libstdc++-v3/testsuite
make check 'RUNTESTFLAGS=  SIM=realview_pbx_a9_qemu
RTEMS_MAKEFILE_PATH=/scratch/git-rtems-testing/gcc/install-git/arm-rtems4.11/realview_pbx_a9_qemu
RTEMS_CONFIG_OBJ=/scratch/git-rtems-testing/gcc/b-arm-gcc/rtems_gcc_main.o
--target_board=rtems-arm-realview_pbx_a9_qemu{-march=armv7-a/-mthumb/-mfpu=neon/-mfloat-abi=hard}'

to run the libstdc++ tests.

Where does the /git-rtems-testing/gcc/install-git directory? I didn't
see an 'install-git' dir inside rtems-testing/gcc. Is it created after
doing make install on rtems-testing?


I don't remember. I set this up several months ago and now it just works.

--
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: Version Numbers

[Sebastian Huber]

On 28/07/15 09:48, Chris Johns wrote:

>>>>
>>>>Either scheme fits pretty well with RTEMS release cycle I think. Even
>>>>if we can get down to one release per year, the numbers won't grow
>>>>terribly fast.

>>>
>>>One release per year would be nice.
>>>

>>
>>We may need more flexibility.

>
>I just wanted to say, that the four years or so it took to release RTEMS 4.11 
was a bit long.
>

Yes I agree. I think Joel wants a 4.12 which is close to 4.11 but
stripped of various things we kept in 4.11.

Once we have 5.0 and waf, buildbot will decide when a release is ready.
When the feature set for the release is available and buildbot shows the
code is suitable it can be released. It might be months or just weeks.


We have the 4.11 release branch, but still no release. Independent of 
that, we have to adjust the version of the master. Will this be 4.12.99 
or 5.0.0?


--
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: Version Numbers

[Sebastian Huber]

On 10/09/15 09:49, Pavel Pisa wrote:

Hello Sebastian,

On Thursday 10 of September 2015 08:52:37 Sebastian Huber wrote:

On 28/07/15 09:48, Chris Johns wrote:

Either scheme fits pretty well with RTEMS release cycle I think.
Even if we can get down to one release per year, the numbers
won't grow terribly fast.

One release per year would be nice.

We may need more flexibility.

I just wanted to say, that the four years or so it took to release
RTEMS 4.11 was a bit long.

Yes I agree. I think Joel wants a 4.12 which is close to 4.11 but
stripped of various things we kept in 4.11.

Once we have 5.0 and waf, buildbot will decide when a release is ready.
When the feature set for the release is available and buildbot shows the
code is suitable it can be released. It might be months or just weeks.

We have the 4.11 release branch, but still no release. Independent of
that, we have to adjust the version of the master. Will this be 4.12.99
or 5.0.0?

If there is 4.12 planned then it should be 4.11.99.


Hm, yes.



As for 4.99 and 5.0, I am not big fan of today fashion
to have three or more major numbers per year as Firefox and Chrome
has. So if there is really significant API change then the major
version increase is appropriate but if there is not than to stay
with single one with minor up to 20 or 30 is reasonable.
On the other hand if minor should reach 50 or even 100 then
I am for major increase. May it be that rule to not go with
minor above 9 could be used.

But above is only my feeling. But rule that complete version increase
is monotonic in master branch and in release does not reach any
version in master is critical. I have code which builds (thanks to versions
macros) from 4.6 to 4.11.


There was some discussion about version numbers in this thread. See also:

https://devel.rtems.org/wiki/Developer/Release#RTEMSReleaseNumberingandNaming

"Version Numbering Scheme for GCC 5 and Up"

https://gcc.gnu.org/develop.html

In think we should simply use the same. This is more or less in line 
with the proposal from Gedare:


https://lists.rtems.org/pipermail/devel/2015-July/012056.html

--
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] Upgrade to 4.11.99.0

[Sebastian Huber]

---
 aclocal/version.m4| 4 ++--
 c/src/aclocal/version.m4  | 4 ++--
 cpukit/aclocal/version.m4 | 4 ++--
 testsuites/aclocal/version.m4 | 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/aclocal/version.m4 b/aclocal/version.m4
index 6ca81ac..6ced838 100644
--- a/aclocal/version.m4
+++ b/aclocal/version.m4
@@ -1,4 +1,4 @@
 AC_DEFUN([RTEMS_VERSIONING],
-m4_define([_RTEMS_VERSION],[4.10.99.0]))
+m4_define([_RTEMS_VERSION],[4.11.99.0]))
 
-m4_define([_RTEMS_API],[4.11])
+m4_define([_RTEMS_API],[4.12])
diff --git a/c/src/aclocal/version.m4 b/c/src/aclocal/version.m4
index 6ca81ac..6ced838 100644
--- a/c/src/aclocal/version.m4
+++ b/c/src/aclocal/version.m4
@@ -1,4 +1,4 @@
 AC_DEFUN([RTEMS_VERSIONING],
-m4_define([_RTEMS_VERSION],[4.10.99.0]))
+m4_define([_RTEMS_VERSION],[4.11.99.0]))
 
-m4_define([_RTEMS_API],[4.11])
+m4_define([_RTEMS_API],[4.12])
diff --git a/cpukit/aclocal/version.m4 b/cpukit/aclocal/version.m4
index 6ca81ac..6ced838 100644
--- a/cpukit/aclocal/version.m4
+++ b/cpukit/aclocal/version.m4
@@ -1,4 +1,4 @@
 AC_DEFUN([RTEMS_VERSIONING],
-m4_define([_RTEMS_VERSION],[4.10.99.0]))
+m4_define([_RTEMS_VERSION],[4.11.99.0]))
 
-m4_define([_RTEMS_API],[4.11])
+m4_define([_RTEMS_API],[4.12])
diff --git a/testsuites/aclocal/version.m4 b/testsuites/aclocal/version.m4
index 6ca81ac..6ced838 100644
--- a/testsuites/aclocal/version.m4
+++ b/testsuites/aclocal/version.m4
@@ -1,4 +1,4 @@
 AC_DEFUN([RTEMS_VERSIONING],
-m4_define([_RTEMS_VERSION],[4.10.99.0]))
+m4_define([_RTEMS_VERSION],[4.11.99.0]))
 
-m4_define([_RTEMS_API],[4.11])
+m4_define([_RTEMS_API],[4.12])
-- 
1.8.4.5

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

Re: [PATCH v3] ARMv7M: Fix exception handler for supporting FPU

[Sebastian Huber]

Is there a v4 missing?

On 14/09/15 23:49, Martin Galvan wrote:

Hi everyone! Just checking in, was Sudarshan's patch commited?

On Mon, Aug 31, 2015 at 4:49 PM, Gedare Bloom <ged...@rtems.org> wrote:

Martin's ticket works, and his commit can  #close it.

On Mon, Aug 31, 2015 at 3:22 PM, sudarshan.rajagopalan
<sudarshan.rajagopa...@vecna.com> wrote:

On 2015-08-31 13:39, Daniel Gutson wrote:

On Mon, Aug 31, 2015 at 2:34 PM, Gedare Bloom <ged...@rtems.org> wrote:

I'd approve 2 patches in case you want to give credit. First patch
with Sudarshan's fix, and Martin's improvement second.

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


--
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: OR1K does not build on master

[Sebastian Huber]

Hello,

On 10/09/15 20:01, Joel Sherrill wrote:

Hi

Fails like this. Patches appreciated.

or1k-rtems4.11-gcc --pipe -DHAVE_CONFIG_H   -I../../.. 
-I../../../../cpukit/../../../generic_or1k/lib/include   -O2 -O0 -g 
-Wall -Wmissing-prototypes -Wimplicit-function-declaration 
-Wstrict-prototypes -Wnested-externs -MT libscorecpu_a-cpu.o -MD -MP 
-MF .deps/libscorecpu_a-cpu.Tpo -c -o libscorecpu_a-cpu.o `test -f 
'cpu.c' || echo 
'../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/'`cpu.c
In file included from 
../../../../cpukit/../../../generic_or1k/lib/include/rtems/score/threadq.h:25:0,
 from 
../../../../cpukit/../../../generic_or1k/lib/include/rtems/score/thread.h:35,
 from 
../../../../cpukit/../../../generic_or1k/lib/include/rtems/score/heap.h:22,
 from 
../../../../cpukit/../../../generic_or1k/lib/include/rtems/score/wkspace.h:23,
 from 
../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/cpu.c:16:
../../../../cpukit/../../../generic_or1k/lib/include/rtems/score/rbtree.h:21:22: 
fatal error: sys/tree.h: No such file or directory

 #include 
  ^
compilation terminated.


I added  some months ago to Newlib:

2015-03-23  Sebastian Huber <sebastian.hu...@embedded-brains.de>

* libc/include/sys/tree.h: New file.

The or1k should use the upstream Newlib. If this is not possible, then 
we should add some Autoconf stuff to provide a  if necessary 
(similar to ).


--
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 for nested mutex project solving priority inversion problem for uniprocessor.

[Sebastian Huber]

On 11/09/15 02:25, Cyrille Artho wrote:

Dear all,
Please let me try to clarify:

1. Our understanding so far was that upon lock release, the priority
instantly gets reverted back to the previous priority. This also
applies for nested locks, i.e., a higher priority gets reverted
(stepwise) when releasing locks and does NOT persist until the last
lock is released.


Yes.



2. The current implementation relies on ordering but could perhaps be
changed, although this would require some time. The time needed to
verify the model would also increase substantially because unordered
locking creates a lot of new possibilities. (It could take several
days to verify a reasonable subset of all behaviors on multiple
cores.)


Unfortunately we have unordered mutex usage, e.g. in Newlib.



3. We have a working SMP implementation but it is very complex. It
either has to use a lot of different locks or a global lock for some
of the code. We were not able to eliminate any locks (the model shows
that data races result if we try), so the current algorithm seems to
be very complex for a multi-processor setting.


I think with the thread lock it will be moderately easy to implement. 
Its certainly not done in two weeks.




Other points:

4. We could add deadlock detection but it does NOT automatically come
with horizontal nesting (acquiring multiple locks). When acquiring
multiple locks, we check the availability of the next lock, but we do
not go down the entire lock chain. This could be implemented but would
cause additional overhead.


The general case deadlock detection is optional from my point of view, 
but at operating system level (SMP locks) there must not be a deadlock.




5. Timeout is currently not supported but could be implemented
relatively easily, although it would again take time to verify the
change.


Timeouts may complicate the things a lot. I tried to get rid of them, 
but they were desired by the community.




6. We could try to build a specialized data race detector RTEMS, to
show a data race in a version that uses too few locks. However,
building a data race detector that gives useful diagnostic information
takes some time. Adding data race detection that just outputs "data
race" when the common lock set is empty, is easier.

On Fri, Sep 11, 2015 at 9:14 AM, Saurabh Gadia <ga...@usc.edu> wrote:

Hi Sebastian,

Sorry for late reply. I was out of town and could not reply. I am bit
confused with above description which I need to get clarified:

1. replaced LIFO with sorted list:  I don't change the mutex order to make
the list sorted. Instead I promote the priorities so that we don't need to
change position of mutex in the chain and the list without any swapping of
mutex in chain becomes sorted and valid.


2. I was confused with spsem03 test cases. So I created spsem04 test case
which demonstrates that our implementation supports horizontal
implementation. It has the same scenario of test case 3 but now we can say
that horizontal nesting works correctly. you can find all description about
this test cases on link below.

https://docs.google.com/document/d/1RM427RKSoyrZrchEcDIx4etmtWqrFArzRRLWqcU8RK0/edit?usp=sharing

3. Your mentioned example is definitely supported by the our implementation.

I also need clarification on ticket 2412:

1. Is there something wrong with problem description?
 it says - "The allocator mutex is already owned, so the priority of the
low priority thread is raised to the priority of the high priority thread.
The memory allocation completes and the allocator mutex is released, since
the low priority thread still owns the file system instance mutex it
continues to execute with the high priority (the high priority thread is not
scheduled)"

Instead --> after releasing lock over allocator the low priority threads
priority will no longer be high as there is restoration of priority of on
mutex release. This is the behavior with our implementation. So low priority
thread will again be restored at its original priority after releasing
allocator lock.

I am not able to get what do we have to do in this ticket like what is the
problem we are trying to solve(objective, current behavior)

2. Our implementation is only for strict order mutex behavior and will not
work for unordered mutex operations. We will need complete different
implementation for unordered mutex operation.

3. Our SMP implementation has recursive mutex acquisition behavior for
supporting horizontal nesting? Will it be fine with RTEMS?

note: Cyrille please mention any other doubts if I have missed any.

Thanks,

Saurabh Gadia

On Sun, Sep 6, 2015 at 11:04 PM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:

Hello Saurabh,

On 05/09/15 01:52, Saurabh Gadia wrote:

This is the patch for solving priority inversion problem for uniprocessor
architecture. It works correctly for all test cases on master. For 4.11 the
patch get applied cleanly but the branch does not c

Re: rtems_set_errno_and_return_minus_one in driver not returning correct value

[Sebastian Huber]

On 11/09/15 10:10, Inderjit Singh wrote:
Can I presume that using errno with RTEMS does not work? To me I'm 
baffled that a RTEMS_SUCCESSFULL value must be returned in order to 
retain the errno value.


The standard drivers are quite primitive. You may have a look at IMFS 
generic nodes, if you want more control:


https://docs.rtems.org/doxygen/cpukit/html/group__IMFSGenericNodes.html

--
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 for nested mutex project solving priority inversion problem for uniprocessor.

[Sebastian Huber]

Hello Saurabh,

On 11/09/15 02:14, Saurabh Gadia wrote:

Hi Sebastian,

Sorry for late reply. I was out of town and could not reply. I am bit 
confused with above description which I need to get clarified:


1. replaced LIFO with sorted list:  I don't change the mutex order to 
make the list sorted. Instead I promote the priorities so that we 
don't need to change position of mutex in the chain and the list 
without any swapping of mutex in chain becomes sorted and valid.



2. I was confused with spsem03 test cases. So I created spsem04 test 
case which demonstrates that our implementation supports horizontal 
implementation. It has the same scenario of test case 3 but now we can 
say that horizontal nesting works correctly. you can find all 
description about this test cases on link below.


https://docs.google.com/document/d/1RM427RKSoyrZrchEcDIx4etmtWqrFArzRRLWqcU8RK0/edit?usp=sharing


sorry, I should have looked more carefully at your code. I missed the 
direct recursion in _Thread_Update_Priority_UP() during my first review. 
A limitless direct or indirect recursion a this level is absolutely 
unacceptable since this may corrupt the thread stack. This is not a real 
problem since it would be easy to change this into an iteration.


So the basic structure of your solution is similar to what I suggested 
in the ticket.




3. Your mentioned example is definitely supported by the our 
implementation.


I also need clarification on ticket 2412:

1. Is there something wrong with problem description?
it says - "The allocator mutex is already owned, so the priority 
of the low priority thread is raised to the priority of the high 
priority thread. The memory allocation completes and the allocator 
mutex is released, since the low priority thread still owns the file 
system instance mutex it continues to execute with the high priority 
(the high priority thread is not scheduled)"


Instead --> after releasing lock over allocator the low priority 
threads priority will no longer be high as there is restoration of 
priority of on mutex release. This is the behavior with our 
implementation. So low priority thread will again be restored at its 
original priority after releasing allocator lock.


*I am not able to get what do we have to do in this ticket like what 
is the problem we are trying to solve(objective, current behavior)

*


The problem description refers to the current master without your patch.


*
*
2. Our implementation is only for strict order mutex behavior and will 
not work for unordered mutex operations. We will need complete 
different implementation for unordered mutex operation.


Unfortunately we have unordered mutex operations in the real world, e.g.

https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=newlib/libc/stdio/fclose.c;h=cd271c490b2652db71727c9af8a19a14f3b36336;hb=HEAD#l112

This is why I suggested to use one priority queue per thread that 
aggregates all the priorities a thread has access to due to its owned 
mutexes (directly and indirectly). In addition this avoids additional 
storage space in the mutex object, which is important.




3. Our SMP implementation has recursive mutex acquisition behavior for 
supporting horizontal nesting? Will it be fine with RTEMS?


There are several race conditions on SMP configurations in your code, e.g.

_Thread_queue_Release( _mutex->Wait_queue, lock_context );
_Thread_Change_priority_UP( holder, the_mutex, 
executing->current_priority, false);


will not work on SMP, since the holder may have changed after the 
Thread_queue_Release().


A recursive SMP lock acquire is a bit problematic, since you need a 
context for each acquire/release pair. There are some options to solve 
this problem, but we have to make some trade-offs. Recursive mutex 
acquire may lead to deadlocks, so we must take care that we don't get 
deadlocks, since this would result in an infinite loop with interrupts 
disabled.




note: *Cyrille* please mention any other doubts if I have missed any.

Thanks,

Saurabh Gadia

On Sun, Sep 6, 2015 at 11:04 PM, Sebastian Huber 
<sebastian.hu...@embedded-brains.de 
<mailto:sebastian.hu...@embedded-brains.de>> wrote:


Hello Saurabh,

On 05/09/15 01:52, Saurabh Gadia wrote:

This is the patch for solving priority inversion problem for
uniprocessor architecture. It works correctly for all test
cases on master. For 4.11 the patch get applied cleanly but
the branch does not compile because of some rbtree
error(unrelated to project). Github link:
https://github.com/saurabhgadia4/rtems/tree/nested-mutex


I reviewed your patch. Basically you replaced the LIFO list of
priorities with a sorted list? Does it work with timeouts and
external priority changes (e.g. task A blocks on a mutex owned by
O, another task B raises the priority of A, will this raise the
priority of O?)

Since all tests pa

Re: rtems_set_errno_and_return_minus_one in driver not returning correct value

[Sebastian Huber]

On 11/09/15 13:28, Inderjit Singh wrote:

So basically you're saying is that i cannot use errno when using the primitve 
driver standard driver but use IMFS instead if I want to retain an errno value 
set in driver and that is recieved by the app.


Yes, if you are unlucky with what rtems_status_code_to_errno() does 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

Re: Patch for nested mutex project solving priority inversion problem for uniprocessor.

[Sebastian Huber]

On 14/09/15 02:24, Cyrille Artho wrote:

Hi Sebastian,
The example you linked to uses file locking meshed with mutexes. If
you consider them to be just locks, then you are right that their
accesses (acquire/release) are interleaved in an unordered way.


The locks are mutexes in Newlib.



For unordered lock releases, we would have to decide about the
semantics of stepping down the priority. If we have "acquire(a),
acquire(b), release(a), release(b)", then the priority is only stepped
down on the final release. If the releases are ordered, we may want to
step down the priority when b is release first, and then again when a
is released. Or we could choose not to step down the priority at all
until the final lock release.


I would use the dependency tree to determine the highest priority a 
thread can use. So, if you release(a) first, then the thread looses all 
the priorities inherited by a.


See also (only the picture, this handler should go away, since it has 
severe performance problems):


https://docs.rtems.org/doxygen/cpukit/html/group__ScoreResource.html#details



The latter is easier to implement but may result in unexpected(?)
behavior when locks are nested.

As for the scope of this project, larger design changes (and their
verification) will take a lot of time. To conclude this project, how
about changing the recursion to iteration so we have an implementation
that works for uniprocessor systems with nested locking/unlocking?


I would prefer to implement something with a potential longer life-time 
in the sources. The "Possible Implementation" described in 
https://devel.rtems.org/ticket/2412 may be good enough to implement OMIP 
later. The main difference to your approach is that the data structures 
are entirely contained in the thread control blocks. This is better in 
terms of the overall memory demand and hides implementation details from 
the mutex structure. Due to the per thread priority queue 
Thread_Priority_node::Inherited_priorities the ordering of mutex 
operations (acquire, release, timeout) doesn't matter.


With respect to the verification you can only verify a subset, e.g. 
consider only ordered acquire/release sequences if this helps.




On Fri, Sep 11, 2015 at 4:18 PM, Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:

Hello Saurabh,

On 11/09/15 02:14, Saurabh Gadia wrote:

Hi Sebastian,

Sorry for late reply. I was out of town and could not reply. I am bit
confused with above description which I need to get clarified:

1. replaced LIFO with sorted list:  I don't change the mutex order to make
the list sorted. Instead I promote the priorities so that we don't need to
change position of mutex in the chain and the list without any swapping of
mutex in chain becomes sorted and valid.


2. I was confused with spsem03 test cases. So I created spsem04 test case
which demonstrates that our implementation supports horizontal
implementation. It has the same scenario of test case 3 but now we can say
that horizontal nesting works correctly. you can find all description about
this test cases on link below.


https://docs.google.com/document/d/1RM427RKSoyrZrchEcDIx4etmtWqrFArzRRLWqcU8RK0/edit?usp=sharing


sorry, I should have looked more carefully at your code. I missed the direct
recursion in _Thread_Update_Priority_UP() during my first review. A
limitless direct or indirect recursion a this level is absolutely
unacceptable since this may corrupt the thread stack. This is not a real
problem since it would be easy to change this into an iteration.

So the basic structure of your solution is similar to what I suggested in
the ticket.


3. Your mentioned example is definitely supported by the our
implementation.

I also need clarification on ticket 2412:

1. Is there something wrong with problem description?
 it says - "The allocator mutex is already owned, so the priority of
the low priority thread is raised to the priority of the high priority
thread. The memory allocation completes and the allocator mutex is released,
since the low priority thread still owns the file system instance mutex it
continues to execute with the high priority (the high priority thread is not
scheduled)"

Instead --> after releasing lock over allocator the low priority threads
priority will no longer be high as there is restoration of priority of on
mutex release. This is the behavior with our implementation. So low priority
thread will again be restored at its original priority after releasing
allocator lock.

*I am not able to get what do we have to do in this ticket like what is
the problem we are trying to solve(objective, current behavior)
*


The problem description refers to the current master without your patch.


*
*
2. Our implementation is only for strict order mutex behavior and will not
work for unordered mutex operations. We will need complete different
implementation for unordered mutex operation.


Unfortunately we have unordered 

Re: [rtems-libbsd commit] builder.py: addTargetSourceCPUDependentSourceFiles

[Sebastian Huber]

- Chris Johns <chr...@rtems.org> schrieb:
> On 2/10/2015 8:33 am, Sebastian Huber wrote:
> > Why do you think it is wrong?
> 
> Because the check is for 'arm' and the file is 'mips'.

The mips variant is generic (C code only).  There is no functional change.  
Before this change we simply copied the file (one-to-N).

-- 
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.huber at 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: [rtems-libbsd commit] builder.py: addTargetSourceCPUDependentSourceFiles

[Sebastian Huber]

Why do you think it is wrong?

The background for this change is that we need an explicit one-to-one mapping 
of libbsd and original FreeBSD files.

- Chris Johns <chr...@rtems.org> schrieb:
> On 1/10/2015 2:56 am, Sebastian Huber wrote:
> > diff --git a/wscript b/wscript
> > index 673479f..88334e4 100644
> > --- a/wscript
> > +++ b/wscript
> > @@ -1053,42 +1053,41 @@ def build(bld):
> >'rtemsbsd/telnetd/pty.c',
> >'rtemsbsd/telnetd/telnetd.c']
> >  if bld.get_env()["RTEMS_ARCH"] == "arm":
> > -source += ['freebsd/sys/arm/arm/in_cksum.c']
> > +source += ['freebsd/sys/mips/mips/in_cksum.c']
> 
> This looks wrong and checking git it is wrong.
> 
> >  if bld.get_env()["RTEMS_ARCH"] == "avr":
> > -source += ['freebsd/sys/avr/avr/in_cksum.c']
> > +source += ['freebsd/sys/mips/mips/in_cksum.c']
> >  if bld.get_env()["RTEMS_ARCH"] == "bfin":
> > -source += ['freebsd/sys/bfin/bfin/in_cksum.c']
> > +source += ['freebsd/sys/mips/mips/in_cksum.c']
> >  if bld.get_env()["RTEMS_ARCH"] == "cflags":
> >  source += ['default']
> >  if bld.get_env()["RTEMS_ARCH"] == "h8300":
> > -source += ['freebsd/sys/h8300/h8300/in_cksum.c']
> > +source += ['freebsd/sys/mips/mips/in_cksum.c']
> >  if bld.get_env()["RTEMS_ARCH"] == "i386":
> >  source += ['freebsd/sys/i386/i386/in_cksum.c',
> > 'freebsd/sys/i386/i386/legacy.c',
> > 'freebsd/sys/x86/pci/pci_bus.c']
> >  if bld.get_env()["RTEMS_ARCH"] == "lm32":
> > -source += ['freebsd/sys/lm32/lm32/in_cksum.c']
> > +source += ['freebsd/sys/mips/mips/in_cksum.c']
> >  if bld.get_env()["RTEMS_ARCH"] == "m32c":
> > -source += ['freebsd/sys/m32c/m32c/in_cksum.c']
> > +source += ['freebsd/sys/mips/mips/in_cksum.c']
> >  if bld.get_env()["RTEMS_ARCH"] == "m32r":
> > -source += ['freebsd/sys/m32r/m32r/in_cksum.c']
> > +source += ['freebsd/sys/mips/mips/in_cksum.c']
> >  if bld.get_env()["RTEMS_ARCH"] == "m68k":
> > -source += ['freebsd/sys/m68k/m68k/in_cksum.c']
> > +source += ['freebsd/sys/mips/mips/in_cksum.c']
> >  if bld.get_env()["RTEMS_ARCH"] == "mips":
> >  source += ['freebsd/sys/mips/mips/in_cksum.c']
> >  if bld.get_env()["RTEMS_ARCH"] == "nios2":
> > -source += ['freebsd/sys/nios2/nios2/in_cksum.c']
> > +source += ['freebsd/sys/mips/mips/in_cksum.c']
> >  if bld.get_env()["RTEMS_ARCH"] == "powerpc":
> >  source += ['freebsd/sys/powerpc/powerpc/in_cksum.c']
> >  if bld.get_env()["RTEMS_ARCH"] == "sh":
> > -source += ['freebsd/sys/sh/sh/in_cksum.c']
> > +source += ['freebsd/sys/mips/mips/in_cksum.c']
> >  if bld.get_env()["RTEMS_ARCH"] == "sparc":
> > -source += ['freebsd/sys/mips/mips/in_cksum.c',
> > -   'freebsd/sys/sparc/sparc/in_cksum.c']
> > +source += ['freebsd/sys/mips/mips/in_cksum.c']
> >  if bld.get_env()["RTEMS_ARCH"] == "sparc64":
> >  source += ['freebsd/sys/sparc64/sparc64/in_cksum.c']
> >  if bld.get_env()["RTEMS_ARCH"] == "v850":
> > -source += ['freebsd/sys/v850/v850/in_cksum.c']
> > +source += ['freebsd/sys/mips/mips/in_cksum.c']
> 
> They all seem wrong which is a puzzling as to how this builds.
> 
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

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

FYI: GCC: Convert SPARC to LRA

[Sebastian Huber]

Hello,

https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00562.html

This means that GCC 6 needs thorough testing on SPARC.

--
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] Update RTEMS multilib for SPARC

[Sebastian Huber]

On 28/09/15 14:13, Daniel Hellstrom wrote:

Now that muser-mode is default the multilib definitions does not require to
specify that switch any more. Add UT699 to multilib after recent patches. Add
AT697F multilib since there are many LEON2 users running RTEMS.

To gcc/ChangeLog:

gcc/
* config/sparc/t-rtems: Remove -muser-mode, add ut699 and at697f
---
  gcc/config/sparc/t-rtems |   25 +++--
  1 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/gcc/config/sparc/t-rtems b/gcc/config/sparc/t-rtems
index adb6dcb..6f7cc6f 100644
--- a/gcc/config/sparc/t-rtems
+++ b/gcc/config/sparc/t-rtems
@@ -17,15 +17,20 @@
  # <http://www.gnu.org/licenses/>.
  #
  
-MULTILIB_OPTIONS = msoft-float mcpu=v8/mcpu=leon3/mcpu=leon3v7 muser-mode

-MULTILIB_DIRNAMES = soft v8 leon3 leon3v7 user-mode
+MULTILIB_OPTIONS = msoft-float mcpu=v8/mcpu=leon3/mcpu=leon3v7/mcpu=leon \
+  mfix-ut699/mfix-at697f
+MULTILIB_DIRNAMES = soft v8 leon3 leon3v7 leon ut699 at697f
  MULTILIB_MATCHES = msoft-float=mno-fpu
  
-MULTILIB_EXCEPTIONS = muser-mode

-MULTILIB_EXCEPTIONS += mcpu=leon3
-MULTILIB_EXCEPTIONS += mcpu=leon3v7
-MULTILIB_EXCEPTIONS += msoft-float/mcpu=leon3
-MULTILIB_EXCEPTIONS += msoft-float/mcpu=leon3v7
-MULTILIB_EXCEPTIONS += msoft-float/muser-mode
-MULTILIB_EXCEPTIONS += msoft-float/mcpu=v8/muser-mode
-MULTILIB_EXCEPTIONS += mcpu=v8/muser-mode
+MULTILIB_EXCEPTIONS = mfix-ut699
+MULTILIB_EXCEPTIONS += msoft-float/mfix-ut699
+MULTILIB_EXCEPTIONS += msoft-float/mcpu=v8/mfix-ut699
+MULTILIB_EXCEPTIONS += msoft-float/mcpu=leon3*/mfix-ut699
+MULTILIB_EXCEPTIONS += mcpu=v8/mfix-ut699
+MULTILIB_EXCEPTIONS += mcpu=leon3*/mfix-ut699
+MULTILIB_EXCEPTIONS += mfix-at697f
+MULTILIB_EXCEPTIONS += msoft-float/mfix-at697f
+MULTILIB_EXCEPTIONS += msoft-float/mcpu=v8/mfix-at697f
+MULTILIB_EXCEPTIONS += msoft-float/mcpu=leon3*/mfix-at697f
+MULTILIB_EXCEPTIONS += mcpu=v8/mfix-at697f
+MULTILIB_EXCEPTIONS += mcpu=leon3*/mfix-at697f


Why do we need so many variants with fixes for the UT699 (32-bit 
Fault-Tolerant LEON3FT SPARC V8 Processor) and the AT697F (LEON2-FT)? 
Why do we have no leon3 variant without fixes for the UT699 and AT697F? 
Which multilib do you suggest now for the NGMP/GR740?


--
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] Update RTEMS multilib for SPARC

[Sebastian Huber]

On 28/09/15 14:33, Sebastian Huber wrote:

On 28/09/15 14:13, Daniel Hellstrom wrote:
Now that muser-mode is default the multilib definitions does not 
require to
specify that switch any more. Add UT699 to multilib after recent 
patches. Add

AT697F multilib since there are many LEON2 users running RTEMS.

To gcc/ChangeLog:

gcc/
* config/sparc/t-rtems: Remove -muser-mode, add ut699 and at697f
---
  gcc/config/sparc/t-rtems |   25 +++--
  1 files changed, 15 insertions(+), 10 deletions(-)

diff --git a/gcc/config/sparc/t-rtems b/gcc/config/sparc/t-rtems
index adb6dcb..6f7cc6f 100644
--- a/gcc/config/sparc/t-rtems
+++ b/gcc/config/sparc/t-rtems
@@ -17,15 +17,20 @@
  # <http://www.gnu.org/licenses/>.
  #
  -MULTILIB_OPTIONS = msoft-float mcpu=v8/mcpu=leon3/mcpu=leon3v7 
muser-mode

-MULTILIB_DIRNAMES = soft v8 leon3 leon3v7 user-mode
+MULTILIB_OPTIONS = msoft-float 
mcpu=v8/mcpu=leon3/mcpu=leon3v7/mcpu=leon \

+   mfix-ut699/mfix-at697f
+MULTILIB_DIRNAMES = soft v8 leon3 leon3v7 leon ut699 at697f
  MULTILIB_MATCHES = msoft-float=mno-fpu
  -MULTILIB_EXCEPTIONS = muser-mode
-MULTILIB_EXCEPTIONS += mcpu=leon3
-MULTILIB_EXCEPTIONS += mcpu=leon3v7
-MULTILIB_EXCEPTIONS += msoft-float/mcpu=leon3
-MULTILIB_EXCEPTIONS += msoft-float/mcpu=leon3v7
-MULTILIB_EXCEPTIONS += msoft-float/muser-mode
-MULTILIB_EXCEPTIONS += msoft-float/mcpu=v8/muser-mode
-MULTILIB_EXCEPTIONS += mcpu=v8/muser-mode
+MULTILIB_EXCEPTIONS = mfix-ut699
+MULTILIB_EXCEPTIONS += msoft-float/mfix-ut699
+MULTILIB_EXCEPTIONS += msoft-float/mcpu=v8/mfix-ut699
+MULTILIB_EXCEPTIONS += msoft-float/mcpu=leon3*/mfix-ut699
+MULTILIB_EXCEPTIONS += mcpu=v8/mfix-ut699
+MULTILIB_EXCEPTIONS += mcpu=leon3*/mfix-ut699
+MULTILIB_EXCEPTIONS += mfix-at697f
+MULTILIB_EXCEPTIONS += msoft-float/mfix-at697f
+MULTILIB_EXCEPTIONS += msoft-float/mcpu=v8/mfix-at697f
+MULTILIB_EXCEPTIONS += msoft-float/mcpu=leon3*/mfix-at697f
+MULTILIB_EXCEPTIONS += mcpu=v8/mfix-at697f
+MULTILIB_EXCEPTIONS += mcpu=leon3*/mfix-at697f


Why do we need so many variants with fixes for the UT699 (32-bit 
Fault-Tolerant LEON3FT SPARC V8 Processor) and the AT697F (LEON2-FT)? 
Why do we have no leon3 variant without fixes for the UT699 and 
AT697F? Which multilib do you suggest now for the NGMP/GR740?




Sorry, for these stupid questions. Maybe we should change this file to 
use MULTILIB_REQUIRED, like on rs6000 and arm.


Which multilibs do we have after this change?

--
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: [rtems commit] score: Fix atomic compare exchange

[Sebastian Huber]

Hello Gedare,

this part of the compare exchange operation is not used in 4.11.  There are a 
couple of other issues with the low level SMP code that turned up after a 
review and this is a preparation patch.

- Am 25. Sep 2015 um 22:38 schrieb Gedare Bloom ged...@rtems.org:

> Sebastian,
> Does this need to go on 4.11 / ticket filed?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Update RTEMS multilib for SPARC

[Sebastian Huber]

On 28/09/15 15:20, Daniel Hellstrom wrote:

Which multilibs do we have after this change?


.;
soft;@msoft-float
v8;@mcpu=v8
leon3;@mcpu=leon3
leon3v7;@mcpu=leon3v7
leon;@mcpu=leon
leon/ut699;@mcpu=leon@mfix-ut699
leon/at697f;@mcpu=leon@mfix-at697f
soft/v8;@msoft-float@mcpu=v8
soft/leon3;@msoft-float@mcpu=leon3
soft/leon3v7;@msoft-float@mcpu=leon3v7
soft/leon;@msoft-float@mcpu=leon
soft/leon/ut699;@msoft-float@mcpu=leon@mfix-ut699
soft/leon/at697f;@msoft-float@mcpu=leon@mfix-at697f 


Ok, looks good. The change log entry should mention that you add 
-mcpu=leon multilibs as well.


It would be nice if you can update the RTEMS documentation accordingly 
similar to ARM and PowerPC, e.g.


https://docs.rtems.org/doc-current/share/rtems/html/cpu_supplement/ARM-Specific-Information-Multilibs.html#ARM-Specific-Information-Multilibs

--
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] Update RTEMS multilib for SPARC

[Sebastian Huber]

On 28/09/15 15:39, Daniel Hellstrom wrote:

On 09/28/2015 03:37 PM, Sebastian Huber wrote:



On 28/09/15 15:20, Daniel Hellstrom wrote:

Which multilibs do we have after this change?


.;
soft;@msoft-float
v8;@mcpu=v8
leon3;@mcpu=leon3
leon3v7;@mcpu=leon3v7
leon;@mcpu=leon
leon/ut699;@mcpu=leon@mfix-ut699
leon/at697f;@mcpu=leon@mfix-at697f
soft/v8;@msoft-float@mcpu=v8
soft/leon3;@msoft-float@mcpu=leon3
soft/leon3v7;@msoft-float@mcpu=leon3v7
soft/leon;@msoft-float@mcpu=leon
soft/leon/ut699;@msoft-float@mcpu=leon@mfix-ut699
soft/leon/at697f;@msoft-float@mcpu=leon@mfix-at697f 


Ok, looks good. The change log entry should mention that you add 
-mcpu=leon multilibs as well.


Ooh I forgot to mention that, I will add it to the comment. Otherwise 
is this okay to commit for 4.9, 5 and master now? 


Since this is a RTEMS only change, I think this is all right. Just make 
sure the change log entry format is all right. The statements end all 
with a '.' for example.


--
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: Memory protection on RTEMS?

[Sebastian Huber]

Hello Martin,

- Martin Galvan <martin.gal...@tallertechnologies.com> schrieb:
> Hi there! We were looking at the RTEMS SMP support, and wondered what
> would it take for the system to support some form of memory protection
> (say, an MPU). Is it possible, and if so, how hard would it be?

the question is, what is "some form of memory protection" for you?

A process model for RTEMS makes no sense. For this you better use a micro 
kernel or Linux.

The ARMv7-A and some PowerPC BSPs have write protection for code and read-only 
data. On some BSPs, read/write to the NULL pointer leads to an exception.  This 
is quite handy during development, but offers no real benefit for a production 
system.

For one customer we implemented a stack protection, a thread can only access 
its own stack, but this is quite non-standard.

> 
> We also saw this:
> 
> https://devel.rtems.org/wiki/Projects/MMU_Support
> 
> What's the status of this project?

I don't know. MMU support tends to be highly architecture specific, so the 
development of a general purpose API is quite difficult.

> 
> On the other hand, we noticed that LEON3 IP Cores usually implement an
> MMU instead of just an MPU. Would it be feasible to support that?

The GR740 has an IOMMU (chapter 17).

http://microelectronics.esa.int/ngmp/GR740-UM-DS-v1.pdf

-- 
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.huber at 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] [RTEMS] Update RTEMS thread model

[Sebastian Huber]

On 17/09/15 16:36, Aurelio Remonda wrote:

It is printing the "real time" but the time is set to a date early
>in the RTEMS development history. Look at the year. That's about the
>time the test was initially written.
>
>It is likely running faster than "real time" because it is a simulator.
>The numbers not ending in "5" is a bit unusual. The test consists of
>four tasks:
>
>+ one runs every 5 seconds
>+ one every 10
>+ one every 15
>+ IDLE
>
>It exits when one notices it has gone over 30 seconds.

Thank you Joel! I have another question if you don't mind: where i can find the 
realview_pbx_a9_qemu.exp file?
I can't find it in dejagnu/boards.


Sorry, I check this file in.

--
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: New BSP Advice

[Sebastian Huber]

Hello Isaac,

what is the license of the ST code? The last time I looked at this code 
it had a license incompatible to open source projects.


--
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 3/3] C11 threads support

[Sebastian Huber]

Import  from latest FreeBSD.  Move types and defines to
 so that it can be customized per target.

newlib/ChangeLog
2015-09-21  Sebastian Huber  <sebastian.hu...@embedded-brains.de>

* libc/include/threads.h: New.
* libc/sys/rtems/include/machine/_threads.h: Likewise.
---
 newlib/libc/include/threads.h| 93 
 newlib/libc/sys/rtems/include/machine/_threads.h | 54 ++
 2 files changed, 147 insertions(+)
 create mode 100644 newlib/libc/include/threads.h
 create mode 100644 newlib/libc/sys/rtems/include/machine/_threads.h

diff --git a/newlib/libc/include/threads.h b/newlib/libc/include/threads.h
new file mode 100644
index 000..9fb08b0
--- /dev/null
+++ b/newlib/libc/include/threads.h
@@ -0,0 +1,93 @@
+/*-
+ * Copyright (c) 2011 Ed Schouten <e...@freebsd.org>
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ */
+
+#ifndef _THREADS_H_
+#define_THREADS_H_
+
+#include 
+#include 
+
+typedef void (*tss_dtor_t)(void *);
+typedef int (*thrd_start_t)(void *);
+
+enum {
+   mtx_plain = 0x1,
+   mtx_recursive = 0x2,
+   mtx_timed = 0x4
+};
+
+enum {
+   thrd_busy = 1,
+   thrd_error = 2,
+   thrd_nomem = 3,
+   thrd_success = 4,
+   thrd_timedout = 5
+};
+
+#if !defined(__cplusplus) || __cplusplus < 201103L
+#definethread_local_Thread_local
+#endif
+
+__BEGIN_DECLS
+void   call_once(once_flag *, void (*)(void));
+intcnd_broadcast(cnd_t *);
+void   cnd_destroy(cnd_t *);
+intcnd_init(cnd_t *);
+intcnd_signal(cnd_t *);
+intcnd_timedwait(cnd_t *__restrict, mtx_t *__restrict __mtx,
+const struct timespec *__restrict)
+__requires_exclusive(*__mtx);
+intcnd_wait(cnd_t *, mtx_t *__mtx)
+__requires_exclusive(*__mtx);
+void   mtx_destroy(mtx_t *__mtx)
+__requires_unlocked(*__mtx);
+intmtx_init(mtx_t *__mtx, int)
+__requires_unlocked(*__mtx);
+intmtx_lock(mtx_t *__mtx)
+__locks_exclusive(*__mtx);
+intmtx_timedlock(mtx_t *__restrict __mtx,
+const struct timespec *__restrict)
+__trylocks_exclusive(thrd_success, *__mtx);
+intmtx_trylock(mtx_t *__mtx)
+__trylocks_exclusive(thrd_success, *__mtx);
+intmtx_unlock(mtx_t *__mtx)
+__unlocks(*__mtx);
+intthrd_create(thrd_t *, thrd_start_t, void *);
+thrd_t thrd_current(void);
+intthrd_detach(thrd_t);
+intthrd_equal(thrd_t, thrd_t);
+_Noreturn void
+   thrd_exit(int);
+intthrd_join(thrd_t, int *);
+intthrd_sleep(const struct timespec *, struct timespec *);
+void   thrd_yield(void);
+inttss_create(tss_t *, tss_dtor_t);
+void   tss_delete(tss_t);
+void * tss_get(tss_t);
+inttss_set(tss_t, void *);
+__END_DECLS
+
+#endif /* !_THREADS_H_ */
diff --git a/newlib/libc/sys/rtems/include/machine/_threads.h 
b/newlib/libc/sys/rtems/include/machine/_threads.h
new file mode 100644
index 000..24db21c
--- /dev/null
+++ b/newlib/libc/sys/rtems/include/machine/_threads.h
@@ -0,0 +1,54 @@
+/*
+ * Copyright (c) 2015 embedded brains GmbH.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ * "AS IS" AND ANY EXPR

[PATCH 2/2] libstdthreads: Add C11 threads

[Sebastian Huber]

---
 cpukit/Makefile.am |   1 +
 cpukit/configure.ac|   4 +
 cpukit/libstdthreads/Makefile.am   |  21 +
 cpukit/libstdthreads/call_once.c   |   6 +-
 cpukit/libstdthreads/cnd.c |  31 +-
 cpukit/libstdthreads/mtx.c |  48 +--
 cpukit/libstdthreads/thrd.c|   9 +-
 cpukit/libstdthreads/tss.c |   7 +-
 cpukit/wrapup/Makefile.am  |   1 +
 testsuites/sptests/Makefile.am |   3 +
 testsuites/sptests/configure.ac|   4 +
 testsuites/sptests/spstdthreads01/Makefile.am  |  19 +
 testsuites/sptests/spstdthreads01/init.c   | 438 +
 .../sptests/spstdthreads01/spstdthreads01.doc  |  35 ++
 .../sptests/spstdthreads01/spstdthreads01.scn  |   2 +
 15 files changed, 554 insertions(+), 75 deletions(-)
 create mode 100644 cpukit/libstdthreads/Makefile.am
 create mode 100644 testsuites/sptests/spstdthreads01/Makefile.am
 create mode 100644 testsuites/sptests/spstdthreads01/init.c
 create mode 100644 testsuites/sptests/spstdthreads01/spstdthreads01.doc
 create mode 100644 testsuites/sptests/spstdthreads01/spstdthreads01.scn

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index c9a4e0f..063a795 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -16,6 +16,7 @@ SUBDIRS += libmisc
 SUBDIRS += libmd
 SUBDIRS += libgnat
 SUBDIRS += libdl
+SUBDIRS += libstdthreads
 SUBDIRS += wrapup
 
 SUBDIRS += zlib
diff --git a/cpukit/configure.ac b/cpukit/configure.ac
index 14ce0f1..01da86d 100644
--- a/cpukit/configure.ac
+++ b/cpukit/configure.ac
@@ -141,6 +141,9 @@ AS_IF([test -n "$rtems_missing_header"],
 AC_CHECK_HEADERS([semaphore.h])
 AM_CONDITIONAL([HAVE_SEMAPHORE_H],[test x"$ac_cv_header_semaphore_h" = x"yes"])
 
+AC_CHECK_HEADERS([threads.h])
+AM_CONDITIONAL([HAVE_THREADS_H],[test x"$ac_cv_header_threads_h" = x"yes"])
+
 ## error out if libc doesn't provide stdint.h
 AS_IF([test x"${ac_cv_header_stdint_h}" != xyes],
 [AC_MSG_ERROR([Required header stdint.h not found])])
@@ -481,6 +484,7 @@ libmisc/Makefile
 libi2c/Makefile
 libmd/Makefile
 libdl/Makefile
+libstdthreads/Makefile
 zlib/Makefile
 ftpd/Makefile
 telnetd/Makefile
diff --git a/cpukit/libstdthreads/Makefile.am b/cpukit/libstdthreads/Makefile.am
new file mode 100644
index 000..8b4ffaa
--- /dev/null
+++ b/cpukit/libstdthreads/Makefile.am
@@ -0,0 +1,21 @@
+include $(top_srcdir)/automake/compile.am
+
+include_HEADERS =
+
+noinst_LIBRARIES = libstdthreads.a
+
+libstdthreads_a_CFLAGS = -std=c11
+libstdthreads_a_CPPFLAGS = $(AM_CPPFLAGS)
+
+libstdthreads_a_SOURCES =
+if HAVE_THREADS_H
+libstdthreads_a_SOURCES += call_once.c
+libstdthreads_a_SOURCES += cnd.c
+libstdthreads_a_SOURCES += mtx.c
+if HAS_PTHREADS
+libstdthreads_a_SOURCES += thrd.c
+endif
+libstdthreads_a_SOURCES += tss.c
+endif
+
+include $(top_srcdir)/automake/local.am
diff --git a/cpukit/libstdthreads/call_once.c b/cpukit/libstdthreads/call_once.c
index 2d7d6ff..9a577d6 100644
--- a/cpukit/libstdthreads/call_once.c
+++ b/cpukit/libstdthreads/call_once.c
@@ -26,13 +26,9 @@
  * $FreeBSD r228904 2011-12-26T21:51:53Z$
  */
 
-#include 
-__FBSDID("$FreeBSD$");
-
+#include 
 #include 
 
-#include "threads.h"
-
 void
 call_once(once_flag *flag, void (*func)(void))
 {
diff --git a/cpukit/libstdthreads/cnd.c b/cpukit/libstdthreads/cnd.c
index cccf728..7ed750a 100644
--- a/cpukit/libstdthreads/cnd.c
+++ b/cpukit/libstdthreads/cnd.c
@@ -1,5 +1,6 @@
 /*-
  * Copyright (c) 2011 Ed Schouten 
+ * Copyright (c) 2015 embedded brains GmbH 
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -26,20 +27,14 @@
  * $FreeBSD r228904 2011-12-26T21:51:53Z$
  */
 
-#include 
-__FBSDID("$FreeBSD$");
-
+#include 
 #include 
-#include 
-
-#include "threads.h"
 
 int
 cnd_broadcast(cnd_t *cond)
 {
 
-   if (pthread_cond_broadcast(cond) != 0)
-   return (thrd_error);
+   _Condition_Broadcast(cond);
return (thrd_success);
 }
 
@@ -47,29 +42,22 @@ void
 cnd_destroy(cnd_t *cond)
 {
 
-   (void)pthread_cond_destroy(cond);
+   _Condition_Destroy(cond);
 }
 
 int
 cnd_init(cnd_t *cond)
 {
 
-   switch (pthread_cond_init(cond, NULL)) {
-   case 0:
-   return (thrd_success);
-   case ENOMEM:
-   return (thrd_nomem);
-   default:
-   return (thrd_error);
-   }
+   _Condition_Initialize(cond);
+   return (thrd_success);
 }
 
 int
 cnd_signal(cnd_t *cond)
 {
 
-   if (pthread_cond_signal(cond) != 0)
-   return (thrd_error);
+   _Condition_Signal(cond);
return (thrd_success);
 }
 
@@ -78,7 +66,7 @@ cnd_timedwait(cnd_t *restrict cond, mtx_t *restrict mtx,
 const struct timespec *restrict ts)
 {
 
-   switch 

[PATCH 1/2] libstdthreads: Import from FreeBSD

[Sebastian Huber]

---
 cpukit/libstdthreads/call_once.c |  44 ++
 cpukit/libstdthreads/cnd.c   |  98 ++
 cpukit/libstdthreads/mtx.c   | 116 +++
 cpukit/libstdthreads/thrd.c  | 128 +++
 cpukit/libstdthreads/tss.c   |  69 +
 5 files changed, 455 insertions(+)
 create mode 100644 cpukit/libstdthreads/call_once.c
 create mode 100644 cpukit/libstdthreads/cnd.c
 create mode 100644 cpukit/libstdthreads/mtx.c
 create mode 100644 cpukit/libstdthreads/thrd.c
 create mode 100644 cpukit/libstdthreads/tss.c

diff --git a/cpukit/libstdthreads/call_once.c b/cpukit/libstdthreads/call_once.c
new file mode 100644
index 000..2d7d6ff
--- /dev/null
+++ b/cpukit/libstdthreads/call_once.c
@@ -0,0 +1,44 @@
+/*-
+ * Copyright (c) 2011 Ed Schouten 
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * $FreeBSD r228904 2011-12-26T21:51:53Z$
+ */
+
+#include 
+__FBSDID("$FreeBSD$");
+
+#include 
+
+#include "threads.h"
+
+void
+call_once(once_flag *flag, void (*func)(void))
+{
+
+   (void)pthread_once((pthread_once_t *)flag, func);
+}
+
+_Static_assert(sizeof(once_flag) == sizeof(pthread_once_t),
+"once_flag must be of the same size as pthread_once_t");
diff --git a/cpukit/libstdthreads/cnd.c b/cpukit/libstdthreads/cnd.c
new file mode 100644
index 000..cccf728
--- /dev/null
+++ b/cpukit/libstdthreads/cnd.c
@@ -0,0 +1,98 @@
+/*-
+ * Copyright (c) 2011 Ed Schouten 
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
+ * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
+ * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+ * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
+ * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
+ * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
+ * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
+ * SUCH DAMAGE.
+ *
+ * $FreeBSD r228904 2011-12-26T21:51:53Z$
+ */
+
+#include 
+__FBSDID("$FreeBSD$");
+
+#include 
+#include 
+
+#include "threads.h"
+
+int
+cnd_broadcast(cnd_t *cond)
+{
+
+   if (pthread_cond_broadcast(cond) != 0)
+   return (thrd_error);
+   return (thrd_success);
+}
+
+void
+cnd_destroy(cnd_t *cond)
+{
+
+   (void)pthread_cond_destroy(cond);
+}
+
+int
+cnd_init(cnd_t *cond)
+{
+
+   switch (pthread_cond_init(cond, NULL)) {
+   case 0:
+   return (thrd_success);
+   case ENOMEM:
+   return (thrd_nomem);
+   default:
+   return (thrd_error);
+   }
+}
+
+int
+cnd_signal(cnd_t *cond)
+{
+
+   if (pthread_cond_signal(cond) != 0)
+   return (thrd_error);
+   return (thrd_success);
+}
+
+int
+cnd_timedwait(cnd_t *restrict cond, 

Re: [PATCH v4] ARMv7M: Improve exception handler routine and add comments on SP selection

[Sebastian Huber]

On 18/09/15 23:53, Martin Galvan wrote:

This patch adds a brief description of how context state is saved into the
SP on exception entry, and makes a few changes to _ARMV7M_Exception_default
in order to make it a bit more efficient. I also removed the unused 'v7mfsz'
input parameter.

This should apply over Sudarshan's patch.


Is this this one

https://lists.rtems.org/pipermail/devel/2015-August/012382.html

?

--
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 1/3] Add FreeBSD style changes to

[Sebastian Huber]

newlib/ChangeLog
2015-09-21  Sebastian Huber  <sebastian.hu...@embedded-brains.de>

* libc/include/sys/cdefs.h: Add style changes of latest FreeBSD
version.
---
 newlib/libc/include/sys/cdefs.h | 64 -
 1 file changed, 32 insertions(+), 32 deletions(-)

diff --git a/newlib/libc/include/sys/cdefs.h b/newlib/libc/include/sys/cdefs.h
index f1747d0..d952ff6 100644
--- a/newlib/libc/include/sys/cdefs.h
+++ b/newlib/libc/include/sys/cdefs.h
@@ -100,33 +100,33 @@
 #if defined(__GNUC__) || defined(__INTEL_COMPILER)
 
 #if __GNUC__ >= 3 || defined(__INTEL_COMPILER)
-#define __GNUCLIKE_ASM 3
-#define __GNUCLIKE_MATH_BUILTIN_CONSTANTS
+#define__GNUCLIKE_ASM 3
+#define__GNUCLIKE_MATH_BUILTIN_CONSTANTS
 #else
-#define __GNUCLIKE_ASM 2
+#define__GNUCLIKE_ASM 2
 #endif
-#define __GNUCLIKE___TYPEOF 1
-#define __GNUCLIKE___OFFSETOF 1
-#define __GNUCLIKE___SECTION 1
+#define__GNUCLIKE___TYPEOF 1
+#define__GNUCLIKE___OFFSETOF 1
+#define__GNUCLIKE___SECTION 1
 
 #ifndef __INTEL_COMPILER
-# define __GNUCLIKE_CTOR_SECTION_HANDLING 1
+#define__GNUCLIKE_CTOR_SECTION_HANDLING 1
 #endif
 
-#define __GNUCLIKE_BUILTIN_CONSTANT_P 1
-# if defined(__INTEL_COMPILER) && defined(__cplusplus) \
-&& __INTEL_COMPILER < 800
-#  undef __GNUCLIKE_BUILTIN_CONSTANT_P
-# endif
+#define__GNUCLIKE_BUILTIN_CONSTANT_P 1
+#if defined(__INTEL_COMPILER) && defined(__cplusplus) && \
+   __INTEL_COMPILER < 800
+#undef __GNUCLIKE_BUILTIN_CONSTANT_P
+#endif
 
 #if (__GNUC_MINOR__ > 95 || __GNUC__ >= 3) && !defined(__INTEL_COMPILER)
-# define __GNUCLIKE_BUILTIN_VARARGS 1
-# define __GNUCLIKE_BUILTIN_STDARG 1
-# define __GNUCLIKE_BUILTIN_VAALIST 1
+#define__GNUCLIKE_BUILTIN_VARARGS 1
+#define__GNUCLIKE_BUILTIN_STDARG 1
+#define__GNUCLIKE_BUILTIN_VAALIST 1
 #endif
 
 #if defined(__GNUC__)
-# define __GNUC_VA_LIST_COMPATIBILITY 1
+#define__GNUC_VA_LIST_COMPATIBILITY 1
 #endif
 
 /*
@@ -137,23 +137,23 @@
 #endif
 
 #ifndef __INTEL_COMPILER
-# define __GNUCLIKE_BUILTIN_NEXT_ARG 1
-# define __GNUCLIKE_MATH_BUILTIN_RELOPS
+#define__GNUCLIKE_BUILTIN_NEXT_ARG 1
+#define__GNUCLIKE_MATH_BUILTIN_RELOPS
 #endif
 
-#define __GNUCLIKE_BUILTIN_MEMCPY 1
+#define__GNUCLIKE_BUILTIN_MEMCPY 1
 
 /* XXX: if __GNUC__ >= 2: not tested everywhere originally, where replaced */
-#define __CC_SUPPORTS_INLINE 1
-#define __CC_SUPPORTS___INLINE 1
-#define __CC_SUPPORTS___INLINE__ 1
+#define__CC_SUPPORTS_INLINE 1
+#define__CC_SUPPORTS___INLINE 1
+#define__CC_SUPPORTS___INLINE__ 1
 
-#define __CC_SUPPORTS___FUNC__ 1
-#define __CC_SUPPORTS_WARNING 1
+#define__CC_SUPPORTS___FUNC__ 1
+#define__CC_SUPPORTS_WARNING 1
 
-#define __CC_SUPPORTS_VARADIC_XXX 1 /* see varargs.h */
+#define__CC_SUPPORTS_VARADIC_XXX 1 /* see varargs.h */
 
-#define __CC_SUPPORTS_DYNAMIC_ARRAY_INIT 1
+#define__CC_SUPPORTS_DYNAMIC_ARRAY_INIT 1
 
 #endif /* __GNUC__ || __INTEL_COMPILER */
 
@@ -368,9 +368,9 @@
 #endif
 
 #if __GNUC_PREREQ__(3, 3)
-#define __nonnull(x)   __attribute__((__nonnull__(x)))
+#define__nonnull(x)__attribute__((__nonnull__(x)))
 #else
-#define __nonnull(x)
+#define__nonnull(x)
 #endif
 
 #if __GNUC_PREREQ__(3, 4)
@@ -433,11 +433,11 @@
  *   larger code.
  */
 #if __GNUC_PREREQ__(2, 96)
-#define __predict_true(exp) __builtin_expect((exp), 1)
-#define __predict_false(exp)__builtin_expect((exp), 0)
+#define__predict_true(exp) __builtin_expect((exp), 1)
+#define__predict_false(exp)__builtin_expect((exp), 0)
 #else
-#define __predict_true(exp) (exp)
-#define __predict_false(exp)(exp)
+#define__predict_true(exp) (exp)
+#define__predict_false(exp)(exp)
 #endif
 
 #if __GNUC_PREREQ__(4, 2)
-- 
1.8.4.5

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

[PATCH 2/3] Synchronize with FreeBSD

[Sebastian Huber]

newlib/ChangeLog
2015-09-21  Sebastian Huber  <sebastian.hu...@embedded-brains.de>

* libc/include/sys/cdefs.h: Synchronize with latest FreeBSD
version.
---
 newlib/libc/include/sys/cdefs.h | 160 ++--
 1 file changed, 138 insertions(+), 22 deletions(-)

diff --git a/newlib/libc/include/sys/cdefs.h b/newlib/libc/include/sys/cdefs.h
index d952ff6..773ac25 100644
--- a/newlib/libc/include/sys/cdefs.h
+++ b/newlib/libc/include/sys/cdefs.h
@@ -69,7 +69,9 @@
 /*
  * Testing against Clang-specific extensions.
  */
-
+#ifndef__has_attribute
+#define__has_attribute(x)  0
+#endif
 #ifndef__has_extension
 #define__has_extension __has_feature
 #endif
@@ -119,7 +121,7 @@
 #undef __GNUCLIKE_BUILTIN_CONSTANT_P
 #endif
 
-#if (__GNUC_MINOR__ > 95 || __GNUC__ >= 3) && !defined(__INTEL_COMPILER)
+#if (__GNUC_MINOR__ > 95 || __GNUC__ >= 3)
 #define__GNUCLIKE_BUILTIN_VARARGS 1
 #define__GNUCLIKE_BUILTIN_STDARG 1
 #define__GNUCLIKE_BUILTIN_VAALIST 1
@@ -229,8 +231,12 @@
 #define__unused
 #define__packed
 #define__aligned(x)
+#define__alloc_align(x)
+#define__alloc_size(x)
 #define__section(x)
+#define__weak_symbol
 #else
+#define__weak_symbol   __attribute__((__weak__))
 #if !__GNUC_PREREQ__(2, 5) && !defined(__INTEL_COMPILER)
 #define__dead2
 #define__pure2
@@ -242,7 +248,7 @@
 #define__unused
 /* XXX Find out what to do for __packed, __aligned and __section */
 #endif
-#if __GNUC_PREREQ__(2, 7)
+#if __GNUC_PREREQ__(2, 7) || defined(__INTEL_COMPILER)
 #define__dead2 __attribute__((__noreturn__))
 #define__pure2 __attribute__((__const__))
 #define__unused__attribute__((__unused__))
@@ -251,16 +257,17 @@
 #define__aligned(x)__attribute__((__aligned__(x)))
 #define__section(x)__attribute__((__section__(x)))
 #endif
-#if defined(__INTEL_COMPILER)
-#define __dead2__attribute__((__noreturn__))
-#define __pure2__attribute__((__const__))
-#define __unused   __attribute__((__unused__))
-#define __used __attribute__((__used__))
-#define __packed   __attribute__((__packed__))
-#define __aligned(x)   __attribute__((__aligned__(x)))
-#define __section(x)   __attribute__((__section__(x)))
+#if __GNUC_PREREQ__(4, 3) || __has_attribute(__alloc_size__)
+#define__alloc_size(x) __attribute__((__alloc_size__(x)))
+#else
+#define__alloc_size(x)
 #endif
+#if __GNUC_PREREQ__(4, 9) || __has_attribute(__alloc_align__)
+#define__alloc_align(x)__attribute__((__alloc_align__(x)))
+#else
+#define__alloc_align(x)
 #endif
+#endif /* lint */
 
 #if !__GNUC_PREREQ__(2, 95)
 #define__alignof(x)__offsetof(struct { char __a; x __b; }, __b)
@@ -270,7 +277,7 @@
  * Keywords added in C11.
  */
 
-#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L
+#if !defined(__STDC_VERSION__) || __STDC_VERSION__ < 201112L || defined(lint)
 
 #if !__has_extension(c_alignas)
 #if (defined(__cplusplus) && __cplusplus >= 201103L) || \
@@ -302,23 +309,28 @@
 #define_Noreturn   __dead2
 #endif
 
-#if __GNUC_PREREQ__(4, 6) && !defined(__cplusplus)
-/*  Do nothing: _Static_assert() works as per C11 */
-#elif !__has_extension(c_static_assert)
+#if !__has_extension(c_static_assert)
 #if (defined(__cplusplus) && __cplusplus >= 201103L) || \
 __has_extension(cxx_static_assert)
 #define_Static_assert(x, y)static_assert(x, y)
+#elif __GNUC_PREREQ__(4,6)
+/* Nothing, gcc 4.6 and higher has _Static_assert built-in */
 #elif defined(__COUNTER__)
 #define_Static_assert(x, y)__Static_assert(x, __COUNTER__)
 #define__Static_assert(x, y)   ___Static_assert(x, y)
-#define___Static_assert(x, y)  typedef char __assert_ ## y[(x) ? 1 : 
-1]
+#define___Static_assert(x, y)  typedef char __assert_ ## y[(x) ? 1 : 
-1] \
+   __unused
 #else
 #define_Static_assert(x, y)struct __hack
 #endif
 #endif
 
 #if !__has_extension(c_thread_local)
-/* XXX: Change this to test against C++11 when clang in base supports it. */
+/*
+ * XXX: Some compilers (Clang 3.3, GCC 4.7) falsely announce C++11 mode
+ * without actually supporting the thread_local keyword. Don't check for
+ * the presence of C++11 when defining _Thread_local.
+ */
 #if /* (defined(__cplusplus) && __cplusplus >= 201103L) || */ \
 __has_extension(cxx_thread_local)
 #define_Thread_local   thread_local
@@ -338,7 +350,8 @@
  * distinguish multiple cases.
  */
 
-#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L
+#if (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L) || \
+__has_extension(c_generic_selections)
 #define 

Re: [PATCH] [RTEMS] Update RTEMS thread model

[Sebastian Huber]

On 22/09/15 16:01, Aurelio Remonda wrote:

Thank you Sebastian! We were able to reproduce the tests.
The test we were interested in was 
25_algorithms/random_shuffle/moveable, this one fails, as we saw in 
your results (and ours as well). We debugged it and find out that all 
three VERIFY pass (cout of the same line gave us 1, is an equal) but 
we didn't get the exit code 0 at the end of the simulation. 
Apparently, this is making DejaGNU think something's wrong.
We find out that if we reduce the size of A (the array that contains 
the values being shuffled) the test runs correctly.


Ok, its a classic stack overflow (80 bytes on the stack, stack size 
is 256KiB).


--
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 v4] ARMv7M: Improve exception handler routine and add comments on SP selection

[Sebastian Huber]

Thanks for your patience. I checked in both patches. Please let me know 
if it works. In this case I add them to the 4.11 branch.


--
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] C11 support for

[Sebastian Huber]

Import some  function declarations from latest FreeBSD.

newlib/ChangeLog
2015-09-24  Sebastian Huber  <sebastian.hu...@embedded-brains.de>

* libc/include/stdlib.h (alloc_aligned): Declare.
(at_quick_exit): Likewise.
(quick_exit): Likewise.
---
 newlib/libc/include/stdlib.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/newlib/libc/include/stdlib.h b/newlib/libc/include/stdlib.h
index 38ac296..51a6f0a 100644
--- a/newlib/libc/include/stdlib.h
+++ b/newlib/libc/include/stdlib.h
@@ -280,6 +280,17 @@ extern long double strtold (const char *__restrict, char 
**__restrict);
 #endif
 #endif /* _HAVE_LONG_DOUBLE */
 
+/*
+ * If we're in a mode greater than C99, expose C11 functions.
+ */
+#if __ISO_C_VISIBLE >= 2011 || __cplusplus >= 201103L
+void * aligned_alloc(size_t, size_t) __malloc_like __alloc_align(1)
+   __alloc_size(2);
+intat_quick_exit(void (*)(void));
+_Noreturn void
+   quick_exit(int);
+#endif /* __ISO_C_VISIBLE >= 2011 */
+
 _END_STD_C
 
 #endif /* _STDLIB_H_ */
-- 
1.8.4.5

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

Re: New BSP Advice

[Sebastian Huber]

Hello Isaac,

this sounds all right in case all the files added to RTEMS provided by 
ST contain this header in the ZIP file distributed by ST. One commit 
should add all these files unmodified. A download link for this ZIP file 
in the commit message would be nice.


--
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: broken gcc 5.2

[Sebastian Huber]

Hello Daniel,

there was a discussion about this on this mailing list. I think the 
result was that GCC is working as intended:


https://lists.rtems.org/pipermail/devel/2015-July/011879.html

On 17/09/15 21:39, Daniel Gutson wrote:

Hi,

   we are working towards compiling RTEMS for gcc 5.2 (since we are
working in a fork of the latter).

We found a bug that Sebastian previously found, which I reported here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67618
Not only it causes calloc() to call itself (recursively), but the
(arguably) optimization severely breaks the semantic as shown in the
bug report.

Andres will fix it and will let you know about the progress.

Thanks,

Daniel.



--
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: Math lib inclusion in BSP

[Sebastian Huber]

On 24/09/15 21:49, sudarshan.rajagopalan wrote:


We are developing a new BSP that uses math.h in few of the BSP files. 
I do understand that the math library functions are not part of 
standard C library and has to be linked using "-lm". So I include 
"LD_LIBS  += -lm" in the custom .cgf config file but this doesn't seem 
to work. I think this has to be linked in a proper order. Could 
someone help with this? 


This seems to be a candidate for a FAQ:

https://lists.rtems.org/pipermail/devel/2014-October/008322.html

This patch would solve the problem:

https://lists.rtems.org/pipermail/devel/2014-September/008191.html

--
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 2/2] m68k/acinclude.m4: Regenerate to remove sim68000

[Sebastian Huber]

Hello Aun-Ali,

thanks, I committed your patches. However, I merged patch 1 and 2 of 
this series, so that the BSP removal consists of only one patch.


--
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 1/2] score: Statically initialize API extensions

[Sebastian Huber]

Update #2408.
---
 cpukit/sapi/src/exinit.c  | 2 --
 cpukit/score/include/rtems/score/apiext.h | 9 +
 cpukit/score/src/apiext.c | 6 +-
 3 files changed, 2 insertions(+), 15 deletions(-)

diff --git a/cpukit/sapi/src/exinit.c b/cpukit/sapi/src/exinit.c
index 98c4079..b29d8c0 100644
--- a/cpukit/sapi/src/exinit.c
+++ b/cpukit/sapi/src/exinit.c
@@ -101,8 +101,6 @@ void rtems_initialize_data_structures(void)
 _Objects_MP_Handler_early_initialization();
   #endif
 
-  _API_extensions_Initialization();
-
   _Thread_Dispatch_initialization();
 
   _User_extensions_Handler_initialization();
diff --git a/cpukit/score/include/rtems/score/apiext.h 
b/cpukit/score/include/rtems/score/apiext.h
index 8382673..44f16e5 100644
--- a/cpukit/score/include/rtems/score/apiext.h
+++ b/cpukit/score/include/rtems/score/apiext.h
@@ -81,14 +81,7 @@ typedef struct {
 /**
  *  This is the list of API extensions to the system initialization.
  */
-SCORE_EXTERN Chain_Control _API_extensions_List;
-
-/**
- *  @brief Initialize the API extensions handler.
- *
- *  This routine initializes the API extension handler.
- */
-void _API_extensions_Initialization( void );
+extern Chain_Control _API_extensions_List;
 
 /**
  *  @brief Add extension set to the active set.
diff --git a/cpukit/score/src/apiext.c b/cpukit/score/src/apiext.c
index 3d9121d..1d5ce96 100644
--- a/cpukit/score/src/apiext.c
+++ b/cpukit/score/src/apiext.c
@@ -19,13 +19,9 @@
 #include "config.h"
 #endif
 
-#include 
 #include 
 
-void _API_extensions_Initialization( void )
-{
- _Chain_Initialize_empty( &_API_extensions_List );
-}
+CHAIN_DEFINE_EMPTY( _API_extensions_List );
 
 void _API_extensions_Add(
   API_extensions_Control *the_extension
-- 
1.8.4.5

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

[PATCH 2/2] score: Delete unused API extensions

[Sebastian Huber]

Update #2408.
---
 cpukit/sapi/src/exinit.c  |  7 ---
 cpukit/score/include/rtems/score/apiext.h | 28 +---
 cpukit/score/src/apiext.c | 24 +---
 3 files changed, 2 insertions(+), 57 deletions(-)

diff --git a/cpukit/sapi/src/exinit.c b/cpukit/sapi/src/exinit.c
index b29d8c0..794ccb4 100644
--- a/cpukit/sapi/src/exinit.c
+++ b/cpukit/sapi/src/exinit.c
@@ -164,13 +164,6 @@ void rtems_initialize_before_drivers(void)
   #if defined(RTEMS_MULTIPROCESSING)
 _MPCI_Create_server();
   #endif
-
-  #if defined(FUNCTIONALITY_NOT_CURRENTLY_USED_BY_ANY_API)
-/*
- *  Run the API and BSPs predriver hook.
- */
-_API_extensions_Run_predriver();
-  #endif
 }
 
 void rtems_initialize_device_drivers(void)
diff --git a/cpukit/score/include/rtems/score/apiext.h 
b/cpukit/score/include/rtems/score/apiext.h
index 44f16e5..fca47f2 100644
--- a/cpukit/score/include/rtems/score/apiext.h
+++ b/cpukit/score/include/rtems/score/apiext.h
@@ -19,7 +19,6 @@
 #define _RTEMS_SCORE_APIEXT_H
 
 #include 
-#include 
 
 #ifdef __cplusplus
 extern "C" {
@@ -39,13 +38,6 @@ extern "C" {
  */
 /**@{*/
 
-#if defined(FUNCTIONALITY_NOT_CURRENTLY_USED_BY_ANY_API)
-  /**
-   *  This type defines the prototype of the Predriver Hook.
-   */
-  typedef void (*API_extensions_Predriver_hook)(void);
-#endif
-
 /**
  *  This type defines the prototype of the Postdriver Hook.
  */
@@ -58,16 +50,7 @@ typedef void (*API_extensions_Postdriver_hook)(void);
 typedef struct {
   /** This field allows this structure to be used with the Chain Handler. */
   Chain_Node  Node;
-  #if defined(FUNCTIONALITY_NOT_CURRENTLY_USED_BY_ANY_API)
-/**
- * This field is the callout invoked during RTEMS initialization after
- * RTEMS data structures are initialized before device driver 
initialization
- * has occurred.
- *
- * @note If this field is NULL, no extension is invoked.
- */
-API_extensions_Predriver_hook   predriver_hook;
-  #endif
+
   /**
* This field is the callout invoked during RTEMS initialization after
* RTEMS data structures and device driver initialization has occurred
@@ -94,15 +77,6 @@ void _API_extensions_Add(
   API_extensions_Control *the_extension
 );
 
-#if defined(FUNCTIONALITY_NOT_CURRENTLY_USED_BY_ANY_API)
-/**
- *  @brief Execute all pre-driver extensions.
- *
- *  This routine executes all of the predriver callouts.
- */
-  void _API_extensions_Run_predriver( void );
-#endif
-
 /**
  *  @brief Execute all post-driver extensions.
  *
diff --git a/cpukit/score/src/apiext.c b/cpukit/score/src/apiext.c
index 1d5ce96..fd8ca0f 100644
--- a/cpukit/score/src/apiext.c
+++ b/cpukit/score/src/apiext.c
@@ -30,25 +30,6 @@ void _API_extensions_Add(
   _Chain_Append( &_API_extensions_List, _extension->Node );
 }
 
-#if defined(FUNCTIONALITY_NOT_CURRENTLY_USED_BY_ANY_API)
-
-  void _API_extensions_Run_predriver( void )
-  {
-Chain_Node *the_node;
-API_extensions_Control *the_extension;
-
-for ( the_node = _Chain_First( &_API_extensions_List );
- !_Chain_Is_tail( &_API_extensions_List, the_node ) ;
- the_node = the_node->next ) {
-
-  the_extension = (API_extensions_Control *) the_node;
-
-  if ( the_extension->predriver_hook )
-   (*the_extension->predriver_hook)();
-}
-  }
-#endif
-
 void _API_extensions_Run_postdriver( void )
 {
   Chain_Node *the_node;
@@ -63,9 +44,6 @@ void _API_extensions_Run_postdriver( void )
 /*
  *  Currently all APIs configure this hook so it is always non-NULL.
  */
-#if defined(FUNCTIONALITY_NOT_CURRENTLY_USED_BY_ANY_API)
-if ( the_extension->postdriver_hook )
-#endif
-  (*the_extension->postdriver_hook)();
+(*the_extension->postdriver_hook)();
   }
 }
-- 
1.8.4.5

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

Re: [PATCH 2/2] m68k/acinclude.m4: Regenerate to remove sim68000

[Sebastian Huber]

On 08/12/15 07:35, Sebastian Huber wrote:

Hello Aun-Ali,

thanks, I committed your patches. However, I merged patch 1 and 2 of 
this series, so that the BSP removal consists of only one patch.




Ok, I updated the wiki page accordingly.

https://devel.rtems.org/wiki/Developer/Removing_a_BSP

--
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 v2] Add RTEMS linker sets

[Sebastian Huber]

If nobody complains, then I will commit this tomorrow, since I don't 
want to update this patch each time a BSP is removed.


--
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 v2] Use linker set for system initialization

[Sebastian Huber]

Sorry, wrong patch. Please ignore it.

--
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 v2] Add RTEMS linker sets

[Sebastian Huber]

Update #2408.
---
v2: Add documentation to user manual.

 c/src/lib/libbsp/arm/gba/startup/linkcmds  |   2 +
 c/src/lib/libbsp/avr/avrtest/startup/linkcmds  |   2 +
 c/src/lib/libbsp/bfin/TLL6527M/startup/linkcmds|   2 +
 c/src/lib/libbsp/bfin/bf537Stamp/startup/linkcmds  |   2 +
 c/src/lib/libbsp/bfin/eZKit533/startup/linkcmds|   2 +
 c/src/lib/libbsp/h8300/h8sim/startup/linkcmds  |   2 +
 c/src/lib/libbsp/lm32/lm32_evr/startup/linkcmds|   3 +-
 c/src/lib/libbsp/lm32/milkymist/startup/linkcmds   |   3 +-
 c/src/lib/libbsp/m32c/m32cbsp/startup/linkcmds |   3 +-
 c/src/lib/libbsp/m32r/m32rsim/startup/linkcmds |   3 +-
 c/src/lib/libbsp/m68k/av5282/startup/linkcmds  |   2 +
 c/src/lib/libbsp/m68k/av5282/startup/linkcmdsflash |   2 +
 c/src/lib/libbsp/m68k/av5282/startup/linkcmdsram   |   2 +
 c/src/lib/libbsp/m68k/csb360/startup/linkcmds  |   2 +
 c/src/lib/libbsp/m68k/gen68302/startup/linkcmds|   2 +
 c/src/lib/libbsp/m68k/gen68340/startup/linkcmds|   2 +
 c/src/lib/libbsp/m68k/gen68360/startup/linkcmds|   2 +
 .../libbsp/m68k/gen68360/startup/linkcmds.bootp|   2 +
 .../lib/libbsp/m68k/gen68360/startup/linkcmds.prom |   2 +
 c/src/lib/libbsp/m68k/idp/startup/linkcmds |   2 +
 .../lib/libbsp/m68k/mcf5206elite/startup/linkcmds  |   2 +
 .../m68k/mcf5206elite/startup/linkcmds.flash   |   2 +
 c/src/lib/libbsp/m68k/mcf52235/startup/linkcmds|   2 +
 c/src/lib/libbsp/m68k/mcf5225x/startup/linkcmds|   2 +
 c/src/lib/libbsp/m68k/mcf5235/startup/linkcmds |   2 +
 .../lib/libbsp/m68k/mcf5235/startup/linkcmdsflash  |   2 +
 c/src/lib/libbsp/m68k/mcf5235/startup/linkcmdsram  |   2 +
 c/src/lib/libbsp/m68k/mcf5329/startup/linkcmds |   2 +
 .../lib/libbsp/m68k/mcf5329/startup/linkcmdsflash  |   2 +
 c/src/lib/libbsp/m68k/mrm332/startup/linkcmds  |   2 +
 c/src/lib/libbsp/m68k/mvme136/startup/linkcmds |   2 +
 c/src/lib/libbsp/m68k/mvme147/startup/linkcmds |   2 +
 c/src/lib/libbsp/m68k/mvme147s/startup/linkcmds|   2 +
 c/src/lib/libbsp/m68k/mvme162/startup/linkcmds |   2 +
 c/src/lib/libbsp/m68k/mvme167/startup/linkcmds |   2 +
 c/src/lib/libbsp/m68k/ods68302/startup/debugger|   2 +
 c/src/lib/libbsp/m68k/ods68302/startup/linkcmds|   2 +
 c/src/lib/libbsp/m68k/ods68302/startup/rom |   2 +
 c/src/lib/libbsp/m68k/sim68000/startup/linkcmds|   2 +
 c/src/lib/libbsp/m68k/uC5282/startup/linkcmds  |   2 +
 c/src/lib/libbsp/mips/csb350/startup/linkcmds  |   2 +
 .../lib/libbsp/mips/genmongoosev/startup/linkcmds  |   2 +
 c/src/lib/libbsp/mips/hurricane/startup/linkcmds   |   2 +
 c/src/lib/libbsp/mips/rbtx4925/startup/linkcmds|   2 +
 c/src/lib/libbsp/mips/rbtx4938/startup/linkcmds|   2 +
 c/src/lib/libbsp/moxie/moxiesim/startup/linkcmds   |   3 +-
 c/src/lib/libbsp/nios2/nios2_iss/startup/linkcmds  |   3 +-
 c/src/lib/libbsp/powerpc/beatnik/startup/linkcmds  |   3 +-
 c/src/lib/libbsp/powerpc/ep1a/startup/linkcmds |   3 +-
 .../libbsp/powerpc/gen5200/startup/linkcmds.base   |   2 +
 .../lib/libbsp/powerpc/haleakala/startup/linkcmds  |   2 +
 c/src/lib/libbsp/powerpc/mbx8xx/startup/linkcmds   |   2 +
 .../lib/libbsp/powerpc/mpc8260ads/startup/linkcmds |   2 +
 c/src/lib/libbsp/powerpc/qemuppc/startup/linkcmds  |   3 +-
 .../lib/libbsp/powerpc/score603e/startup/linkcmds  |   3 +-
 c/src/lib/libbsp/powerpc/shared/startup/linkcmds   |   3 +-
 c/src/lib/libbsp/powerpc/ss555/startup/linkcmds|   2 +
 .../libbsp/powerpc/tqm8xx/startup/linkcmds.base|   3 +-
 c/src/lib/libbsp/powerpc/virtex4/startup/linkcmds  |   3 +-
 c/src/lib/libbsp/powerpc/virtex5/startup/linkcmds  |   3 +-
 c/src/lib/libbsp/sh/gensh1/startup/linkcmds|   3 +-
 c/src/lib/libbsp/sh/gensh2/startup/linkcmds|   3 +-
 c/src/lib/libbsp/sh/gensh2/startup/linkcmds.ram|   3 +-
 c/src/lib/libbsp/sh/gensh2/startup/linkcmds.rom|   3 +-
 c/src/lib/libbsp/sh/gensh4/startup/linkcmds|   2 +
 c/src/lib/libbsp/sh/gensh4/startup/linkcmds.rom|   2 +
 .../lib/libbsp/sh/gensh4/startup/linkcmds.rom2ram  |   2 +
 c/src/lib/libbsp/sh/shsim/startup/linkcmds.sim |   3 +-
 c/src/lib/libbsp/sparc64/shared/startup/linkcmds   |   2 +
 c/src/lib/libbsp/v850/gdbv850sim/startup/linkcmds  |   3 +-
 cpukit/score/Makefile.am   |   1 +
 cpukit/score/include/rtems/linkersets.h|  96 +
 cpukit/score/preinstall.am |   4 +
 doc/user/Makefile.am   |   9 +-
 doc/user/c_user.texi   |   2 +
 doc/user/example.texi  |   2 +-
 doc/user/linkersets.t  | 421 +
 testsuites/sptests/Makefile.am |   1 +
 testsuites/sptests/configure.ac|   1 +
 testsuites/sptests/splinkersets01/Makefile.am  |  23 ++
 testsuites/sptests/splinkersets01/init.c   | 152 
 

Linker Set Based Initialization

[Sebastian Huber]

Hello,

I checked in the support for linker sets 
(https://devel.rtems.org/ticket/2408). Please review the API


https://git.rtems.org/rtems/tree/cpukit/score/include/rtems/linkersets.h

and documentation

https://git.rtems.org/rtems/tree/doc/user/linkersets.t

carefully.  For an example please have a look at

https://git.rtems.org/rtems/tree/testsuites/sptests/splinkersets01

I will change the system initialization to use linker sets in the next 
couple of weeks. Once this is done, the way back is not easy. So, now is 
the best time to address potential issues.


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