Re: [PATCH] Add RTEMS 4.12 build set

2015-11-11 Thread Chris Johns 
On 11/11/2015 6:45 pm, Sebastian Huber wrote:
> 
> I already use Binutils 2.25.
> 

I think Joel has this working. I hope he will answer when he turns up.

> 
> Does this break 4.11?
> 

There is a 4.11 branch.

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

Re: [rtems-libbsd commit] Delete broken Makefile, use waf instead

2015-11-11 Thread Chris Johns 
On 10/11/2015 8:22 pm, Sebastian Huber wrote:
> 
> Delete broken Makefile, use waf instead
> 

Do you need to change the updating script to not generate it again?

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

Re: Mentors Wanted for Google Code In (High School Students)

2015-11-11 Thread Saket Sinha 
Hi Joel,

I would like to volunteer for mentoring for Google  Code-In program.



Regards,
Saket Sinha


On Wed, Nov 4, 2015 at 4:01 AM, Joel Sherrill  wrote:
> Hi
>
> We need mentors to participate in the Google Code-In program. This is not a
> commitment
> like the Google Summer of Code. The focus is on high school students and
> smaller tasks
> any RTEMS user should be capable of performing. The tasks should take less
> than a day
> normally for the student.
>
> All contact will be via email. Mentoring is normally on a "first come, first
> served" basis. You
> answer email or review work when you can as students post it.
>
> We have done this twice in the past and it has been very rewarding.
>
> Please email me if you are curious and have questions or want to mentor.
>
> Thanks.
>
> --joel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-libbsd commit] Delete broken Makefile, use waf instead

2015-11-11 Thread Sebastian Huber 



On 11/11/15 10:17, Chris Johns wrote:

On 10/11/2015 8:22 pm, Sebastian Huber wrote:

>
>Delete broken Makefile, use waf instead
>

Do you need to change the updating script to not generate it again?


I am not sure, maybe we should remove the Makefile support entirely.

--
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-libbsd commit] Delete broken Makefile, use waf instead

2015-11-11 Thread Chris Johns 
On 11/11/2015 9:27 PM, Sebastian Huber wrote:
> 
> I am not sure, maybe we should remove the Makefile support entirely.
> 

Yes.

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

[PATCH 2/2] Fix interrupt epilogue for ARMv7-AR and PowerPC

2015-11-11 Thread Sebastian Huber 
---
 .../bspsupport/ppc_exc_async_normal.S  | 25 
 cpukit/score/cpu/arm/arm_exc_interrupt.S   | 27 ++
 2 files changed, 52 insertions(+)

diff --git 
a/c/src/lib/libcpu/powerpc/new-exceptions/bspsupport/ppc_exc_async_normal.S 
b/c/src/lib/libcpu/powerpc/new-exceptions/bspsupport/ppc_exc_async_normal.S
index 59e621f..6a1ea34 100644
--- a/c/src/lib/libcpu/powerpc/new-exceptions/bspsupport/ppc_exc_async_normal.S
+++ b/c/src/lib/libcpu/powerpc/new-exceptions/bspsupport/ppc_exc_async_normal.S
@@ -423,6 +423,31 @@ thread_dispatching_done:
 #endif
PPC_GPR_LOADHANDLER_REGISTER, HANDLER_OFFSET(r1)
 
+   /*
+* We must clear reservations here, since otherwise compare-and-swap
+* atomic operations with interrupts enabled may yield wrong results.
+* A compare-and-swap atomic operation is generated by the compiler
+* like this:
+*
+*   .L1:
+* lwarx  r9, r0, r3
+* cmpw   r9, r4
+* bne-   .L2
+* stwcx. r5, r0, r3
+* bne-   .L1
+*   .L2:
+*
+* Consider the following scenario.  A thread is interrupted right
+* before the stwcx.  The interrupt updates the value using a
+* compare-and-swap sequence.  Everything is fine up to this point.
+* The interrupt performs now a compare-and-swap sequence which fails
+* with a branch to .L2.  The current processor has now a reservation.
+* The interrupt returns without further stwcx.  The thread updates the
+* value using the unrelated reservation of the interrupt.
+*/
+   li  SCRATCH_0_REGISTER, HANDLER_OFFSET
+   stwcx.  SCRATCH_0_REGISTER, r1, SCRATCH_0_REGISTER
+
/* Restore SRR0, SRR1, CR, CTR, XER, and LR */
mtsrr0  SCRATCH_0_REGISTER
PPC_GPR_LOADSCRATCH_0_REGISTER, SCRATCH_0_OFFSET(r1)
diff --git a/cpukit/score/cpu/arm/arm_exc_interrupt.S 
b/cpukit/score/cpu/arm/arm_exc_interrupt.S
index 7930c32..fcb1510 100644
--- a/cpukit/score/cpu/arm/arm_exc_interrupt.S
+++ b/cpukit/score/cpu/arm/arm_exc_interrupt.S
@@ -209,6 +209,33 @@ thread_dispatch_done:
/* Restore EXCHANGE_LR and EXCHANGE_SPSR registers from exchange area */
ldmia   sp!, {EXCHANGE_LR, EXCHANGE_SPSR}
 
+#ifdef ARM_MULTILIB_HAS_LOAD_STORE_EXCLUSIVE
+   /*
+* We must clear reservations here, since otherwise compare-and-swap
+* atomic operations with interrupts enabled may yield wrong results.
+* A compare-and-swap atomic operation is generated by the compiler
+* like this:
+*
+*   .L1:
+* ldrex r1, [r0]
+* cmp   r1, r3
+* bne   .L2
+* strex r3, r2, [r0]
+* cmp   r3, #0
+* bne   .L1
+*   .L2:
+*
+* Consider the following scenario.  A thread is interrupted right
+* before the strex.  The interrupt updates the value using a
+* compare-and-swap sequence.  Everything is fine up to this point.
+* The interrupt performs now a compare-and-swap sequence which fails
+* with a branch to .L2.  The current processor has now a reservation.
+* The interrupt returns without further strex.  The thread updates the
+* value using the unrelated reservation of the interrupt.
+*/
+   clrex
+#endif
+
/* Return from interrupt */
subspc, lr, #4
 
-- 
1.8.4.5

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

[PATCH 1/2] Introduce general purpose system server event

2015-11-11 Thread Sebastian Huber 
Use this event for the interrupt server to avoid conflicts with
application events used by interrupt handlers.
---
 c/src/lib/libbsp/shared/src/irq-server.c | 8 +++-
 cpukit/rtems/include/rtems/rtems/event.h | 5 +++--
 cpukit/rtems/src/timerserver.c   | 4 ++--
 3 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/c/src/lib/libbsp/shared/src/irq-server.c 
b/c/src/lib/libbsp/shared/src/irq-server.c
index 5e5dbf1..3537493 100644
--- a/c/src/lib/libbsp/shared/src/irq-server.c
+++ b/c/src/lib/libbsp/shared/src/irq-server.c
@@ -27,8 +27,6 @@
 
 #include 
 
-#define BSP_INTERRUPT_EVENT RTEMS_EVENT_13
-
 RTEMS_INTERRUPT_LOCK_DEFINE(
   static,
   bsp_interrupt_server_lock,
@@ -73,7 +71,7 @@ static void bsp_interrupt_server_trigger(void *arg)
 ++bsp_interrupt_server_errors;
   }
 
-  rtems_event_send(bsp_interrupt_server_id, BSP_INTERRUPT_EVENT);
+  rtems_event_system_send(bsp_interrupt_server_id, RTEMS_EVENT_SYSTEM_SERVER);
 }
 
 static bsp_interrupt_server_entry *bsp_interrupt_server_get_entry(void)
@@ -106,8 +104,8 @@ static void bsp_interrupt_server_task(rtems_task_argument 
arg)
 rtems_event_set events = 0;
 bsp_interrupt_server_entry *e = NULL;
 
-sc = rtems_event_receive(
-  BSP_INTERRUPT_EVENT,
+sc = rtems_event_system_receive(
+  RTEMS_EVENT_SYSTEM_SERVER,
   RTEMS_EVENT_ALL | RTEMS_WAIT,
   RTEMS_NO_TIMEOUT,
   &events
diff --git a/cpukit/rtems/include/rtems/rtems/event.h 
b/cpukit/rtems/include/rtems/rtems/event.h
index 012452a..4263a4b 100644
--- a/cpukit/rtems/include/rtems/rtems/event.h
+++ b/cpukit/rtems/include/rtems/rtems/event.h
@@ -319,9 +319,10 @@ rtems_status_code rtems_event_receive (
 #define RTEMS_EVENT_SYSTEM_NETWORK_CLOSE RTEMS_EVENT_26
 
 /**
- * @brief Reserved system event for the timer server.
+ * @brief Reserved system event for the server threads, e.g timer or interrupt
+ * server.
  */
-#define RTEMS_EVENT_SYSTEM_TIMER_SERVER RTEMS_EVENT_30
+#define RTEMS_EVENT_SYSTEM_SERVER RTEMS_EVENT_30
 
 /**
  * @brief Reserved system event for transient usage.
diff --git a/cpukit/rtems/src/timerserver.c b/cpukit/rtems/src/timerserver.c
index 29e7bc4..7d75780 100644
--- a/cpukit/rtems/src/timerserver.c
+++ b/cpukit/rtems/src/timerserver.c
@@ -256,7 +256,7 @@ static rtems_task _Timer_server_Body(
 );
 
 (void) rtems_event_system_receive(
-  RTEMS_EVENT_SYSTEM_TIMER_SERVER,
+  RTEMS_EVENT_SYSTEM_SERVER,
   RTEMS_EVENT_ALL | RTEMS_WAIT,
   RTEMS_NO_TIMEOUT,
   &events
@@ -281,7 +281,7 @@ static void _Timer_server_Wakeup(
 _Timer_server_Get_seconds
   );
 
-  (void) rtems_event_system_send( id, RTEMS_EVENT_SYSTEM_TIMER_SERVER );
+  (void) rtems_event_system_send( id, RTEMS_EVENT_SYSTEM_SERVER );
 }
 
 static void _Timer_server_Initialize_watchdogs(
-- 
1.8.4.5

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

[PATCH] score: Fix race condition on SMP

2015-11-11 Thread Sebastian Huber 
We must ensure that the Thread_Control::Wait information update is
visible to the target thread before we update its wait flags, otherwise
we may return out of date events or a wrong status.
---
 cpukit/rtems/src/eventseize.c |  6 +
 cpukit/rtems/src/eventsurrender.c | 55 +++
 cpukit/score/src/threadtimeout.c  | 47 +++--
 3 files changed, 67 insertions(+), 41 deletions(-)

diff --git a/cpukit/rtems/src/eventseize.c b/cpukit/rtems/src/eventseize.c
index a9290b3..9c41b77 100644
--- a/cpukit/rtems/src/eventseize.c
+++ b/cpukit/rtems/src/eventseize.c
@@ -100,6 +100,12 @@ void _Event_Seize(
 
   _Thread_Set_state( executing, block_state );
 
+  /*
+   * See _Event_Surrender() and _Thread_Timeout(), corresponding atomic
+   * variable is Thread_Control::Wait::flags.
+   */
+  _Atomic_Fence( ATOMIC_ORDER_ACQUIRE );
+
   success = _Thread_Wait_flags_try_change(
 executing,
 intend_to_block,
diff --git a/cpukit/rtems/src/eventsurrender.c 
b/cpukit/rtems/src/eventsurrender.c
index 1565860..6a14467 100644
--- a/cpukit/rtems/src/eventsurrender.c
+++ b/cpukit/rtems/src/eventsurrender.c
@@ -34,6 +34,20 @@ static void _Event_Satisfy(
   *(rtems_event_set *) the_thread->Wait.return_argument = seized_events;
 }
 
+static bool _Event_Is_blocking_on_event(
+  const Thread_Control *the_thread,
+  Thread_Wait_flags wait_class
+)
+{
+  Thread_Wait_flags wait_flags;
+  Thread_Wait_flags wait_mask;
+
+  wait_flags = _Thread_Wait_flags_get( the_thread );
+  wait_mask = THREAD_WAIT_CLASS_MASK | THREAD_WAIT_STATE_READY_AGAIN;
+
+  return ( wait_flags & wait_mask ) == wait_class;
+}
+
 static bool _Event_Is_satisfied(
   const Thread_Control *the_thread,
   rtems_event_set   pending_events,
@@ -59,46 +73,43 @@ void _Event_Surrender(
   ISR_lock_Context  *lock_context
 )
 {
-  rtems_event_set   pending_events;
-  rtems_event_set   seized_events;
-  Thread_Wait_flags wait_flags;
-  bool  unblock;
+  rtems_event_set pending_events;
+  rtems_event_set seized_events;
+  boolunblock;
 
   _Thread_Lock_acquire_default_critical( the_thread, lock_context );
 
   _Event_sets_Post( event_in, &event->pending_events );
   pending_events = event->pending_events;
 
-  wait_flags = _Thread_Wait_flags_get( the_thread );
-
   if (
-( wait_flags & THREAD_WAIT_CLASS_MASK ) == wait_class
+_Event_Is_blocking_on_event( the_thread, wait_class )
   && _Event_Is_satisfied( the_thread, pending_events, &seized_events )
   ) {
-Thread_Wait_flags intend_to_block;
-Thread_Wait_flags blocked;
-bool success;
+Thread_Wait_flags ready_again;
+bool  success;
+
+_Event_Satisfy( the_thread, event, pending_events, seized_events );
 
-intend_to_block = wait_class | THREAD_WAIT_STATE_INTEND_TO_BLOCK;
-blocked = wait_class | THREAD_WAIT_STATE_BLOCKED;
+/* See _Event_Seize() */
+_Atomic_Fence( ATOMIC_ORDER_RELEASE );
 
+ready_again = wait_class | THREAD_WAIT_STATE_READY_AGAIN;
 success = _Thread_Wait_flags_try_change_critical(
   the_thread,
-  intend_to_block,
-  wait_class | THREAD_WAIT_STATE_READY_AGAIN
+  wait_class | THREAD_WAIT_STATE_INTEND_TO_BLOCK,
+  ready_again
 );
+
 if ( success ) {
-  _Event_Satisfy( the_thread, event, pending_events, seized_events );
   unblock = false;
-} else if ( _Thread_Wait_flags_get( the_thread ) == blocked ) {
-  _Event_Satisfy( the_thread, event, pending_events, seized_events );
-  _Thread_Wait_flags_set(
-the_thread,
-wait_class | THREAD_WAIT_STATE_READY_AGAIN
+} else {
+  _Assert(
+_Thread_Wait_flags_get( the_thread )
+  == wait_class | THREAD_WAIT_STATE_BLOCKED
   );
+  _Thread_Wait_flags_set( the_thread, ready_again );
   unblock = true;
-} else {
-  unblock = false;
 }
   } else {
 unblock = false;
diff --git a/cpukit/score/src/threadtimeout.c b/cpukit/score/src/threadtimeout.c
index 0e04998..45c2292 100644
--- a/cpukit/score/src/threadtimeout.c
+++ b/cpukit/score/src/threadtimeout.c
@@ -39,35 +39,44 @@ void _Thread_Timeout( Objects_Id id, void *arg )
   void  *thread_lock;
   ISR_lock_Context   lock_context;
   Thread_Wait_flags  wait_flags;
-  Thread_Wait_flags  wait_class;
-  Thread_Wait_flags  intend_to_block;
-  Thread_Wait_flags  blocked;
-  bool   success;
   bool   unblock;
 
   the_thread = arg;
   thread_lock = _Thread_Lock_acquire( the_thread, &lock_context );
 
   wait_flags = _Thread_Wait_flags_get( the_thread );
-  wait_class = wait_flags & THREAD_WAIT_CLASS_MASK;
-  intend_to_block = wait_class | THREAD_WAIT_STATE_INTEND_TO_BLOCK;
-  blocked = wait_class | THREAD_WAIT_STATE_BLOCKED;
-  success = _Thread_Wait_flags_try_change_critical(
-the_thread,
-intend_to_block,
-wait_class | THREAD_WAIT_STATE_READY_AGAIN
-  );
 
-  if ( success ) {
+  if ( ( wait_flags & THREAD_WAIT_STATE_

Re: TMS570 BSP updates and LwIP support

2015-11-11 Thread Gedare Bloom 
On Tue, Nov 10, 2015 at 1:30 PM, Martin Galvan
 wrote:
> On Mon, Nov 9, 2015 at 8:30 PM, Pavel Pisa  wrote:
>> If you intend to use 4.11 for production, please, test our changes
>> and suggest if they are appropriate for 4.11.
>
> Are you planning to merge this to 4.11? I don't know how the RTEMS
> team manages their branches, but I assumed any changes to 4.11 are
> bug-fixes instead of new features.
>
Right. Although we sometimes allowed features into BSPs in the past,
we are trying to move toward a tighter release window and only apply
patches on releases that address specific tickets/bugs.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add RTEMS 4.12 build set

2015-11-11 Thread Joel Sherrill 
On Nov 10, 2015 6:56 AM, "Sebastian Huber" <
sebastian.hu...@embedded-brains.de> wrote:
>
>
>
> On 08/11/15 01:05, Chris Johns wrote:
>>
>> Are there any architecture regressions with gcc-6?
>
>
> m32c, moxie, v850 don't work with GCC 6.

Are there gcc PRs filed for all of these?

> epiphany and or1k still use non-FSF GCC.

Yeah.. The or1k has made progress now that all contributors have signed the
paperwork. There was a hold out.

>
>>
>> What archs have to actually run?
>
>
> arm, powerpc, sparc.
>

Did you try any others?

>>
>> I am happy to move to gcc-6 for archs we know are working. For those
>> that do not I am not so sure we should move them.
>
>
> The broken targets use the 4.11 configuration.
>
>
> --
> Sebastian Huber, embedded brains GmbH
>
> Address : Dornierstr. 4, D-82178 Puchheim, Germany
> Phone   : +49 89 189 47 41-16
> Fax : +49 89 189 47 41-09
> E-Mail  : sebastian.hu...@embedded-brains.de
> PGP : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] Add RTEMS 4.12 build set

2015-11-11 Thread Sebastian Huber 

On 11/11/15 14:54, Joel Sherrill wrote:



On Nov 10, 2015 6:56 AM, "Sebastian Huber" 
> wrote:

>
>
>
> On 08/11/15 01:05, Chris Johns wrote:
>>
>> Are there any architecture regressions with gcc-6?
>
>
> m32c, moxie, v850 don't work with GCC 6.

Are there gcc PRs filed for all of these?



Not by me. GCC development in general seems to be quite dead on the m32c 
and v850 targets.



>> What archs have to actually run?
>
>
> arm, powerpc, sparc.
>

Did you try any others?



No.

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

Mentors Wanted for Google Code In (High School Students)

2015-11-11 Thread Martin Galvan 
Hi Joel, I'm interested in being a mentor. Let me know if I can be of any help!
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: TMS570 BSP updates and LwIP support

2015-11-11 Thread Pavel Pisa 
Hello Gedare

On Wednesday 11 of November 2015 14:53:37 Gedare Bloom wrote:
> On Tue, Nov 10, 2015 at 1:30 PM, Martin Galvan
>
>  wrote:
> > On Mon, Nov 9, 2015 at 8:30 PM, Pavel Pisa  wrote:
> >> If you intend to use 4.11 for production, please, test our changes
> >> and suggest if they are appropriate for 4.11.
> >
> > Are you planning to merge this to 4.11? I don't know how the RTEMS
> > team manages their branches, but I assumed any changes to 4.11 are
> > bug-fixes instead of new features.
>
> Right. Although we sometimes allowed features into BSPs in the past,
> we are trying to move toward a tighter release window and only apply
> patches on releases that address specific tickets/bugs.

I understand. TMS570 BSP has been allowed to go in a last minute
on maintainers willingness and it is still considered a work in
progress state. But Martin Galvan and may it be others use it
already as a base of their work so it worth to have it in stable
branch.

As for actual set of proposed changes, the EMAC header files
are not used inside RTEMS still and fix of incorrect missing
file is necessary for building external code (LwIP). Pinmux
is code, which is not used by RTEMS yet. POM use conditionalization
and changed use for cases where necessary is fix of very
annoying issue which hangs system randomly due some
bus collisions resulting in POM engine timeouts (confirmed
for code fetches by Ti). The UART close is a bug.

So I hope that these changes should not cause problems even to TMS570
users. In the fact, they should  resolve their problems.

I can put them to the tickets if it is preferred. But if the series can
be applied is one go it would be easier.

Best wishes,

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

Re: TMS570 BSP updates and LwIP support

2015-11-11 Thread Martin Galvan 
On Wed, Nov 11, 2015 at 11:49 AM, Pavel Pisa  wrote:
> Hello Gedare
> I understand. TMS570 BSP has been allowed to go in a last minute
> on maintainers willingness and it is still considered a work in
> progress state. But Martin Galvan and may it be others use it
> already as a base of their work so it worth to have it in stable
> branch.

FWIW we have this working fine (so far) using Halcogen with a couple
minor changes on our side. I personally would prefer that only the bug
fixes (e.g. the POM stuff) are merged into 4.11 and the new code goes
directly into the mainline.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel