date:20160321

Re: [PATCH] [RSB 4.11] Bump OpenRISC versions

2016-03-21 Thread Hesham Almatary

Thanks Gedare. Both work fine with or1ksim and qemu.

On Tue, Mar 22, 2016 at 11:30 AM, Gedare Bloom  wrote:
> Hi Hesham,
>
> I think the 4.12 patch is there. (updates 2669)
>
> On Mon, Mar 21, 2016 at 6:49 PM, Hesham Almatary
>  wrote:
>> The patch works fine for 4.11 branches on both or1ksim and qemu. 4.12
>> patch will be really appreciated.
>>
>> On Mon, Mar 21, 2016 at 8:34 AM, Hesham Almatary
>>  wrote:
>>> On Mon, Mar 21, 2016 at 8:24 AM, Stefan Wallentowitz
>>>  wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 20.03.2016 22:17, Hesham Almatary wrote:
> Hi Stefan,
>
> Thanks you! The gcc-4.8 patch was aging, so updating it is great.
>
> Have you had a chance to build the or1k BSP and run ticker or hello
> on or1ksim with those new patches?
>
> Cheers, Hesham
>

 Hi,

 I have run hello and some other samples on an FPGA board. I will check
 or1ksim soon.

>>> Great. I'll build the whole RTEMS/or1k env again and test it,
>>> hopefully soon and will let you know how it goes.
>>>
 Best,
 Stefan

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2

 iEYEARECAAYFAlbvFQAACgkQuMYtsrn2U9x+rwCfaBnKaKSEKK8MLkp+T5eyXaZI
 WIsAoKTjGlsLEkxKnXV3osRVusynrH2U
 =q8DR
 -END PGP SIGNATURE-
>>>
>>>
>>>
>>> --
>>> Hesham
>>
>>
>>
>> --
>> Hesham
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel



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

Re: [PATCH] rtems: Rework rate-monotonic scheduler

2016-03-21 Thread Gedare Bloom

Looks good.

On Mon, Mar 21, 2016 at 10:40 AM, Sebastian Huber
 wrote:
> Use the default thread lock to protect rate-monotonic state changes.
> his avoids use of the Giant lock.  Split rtems_rate_monotonic_period()
> body into several static functions.  Introduce a new thread wait class
> THREAD_WAIT_CLASS_PERIOD for period objects to synchronize the blocking
> operation.
>
> Close #2631.
> ---
>  cpukit/rtems/include/rtems/rtems/ratemon.h |  20 +-
>  cpukit/rtems/include/rtems/rtems/ratemonimpl.h | 113 +++--
>  cpukit/rtems/src/ratemoncancel.c   |  65 +++---
>  cpukit/rtems/src/ratemondelete.c   |  39 ++--
>  cpukit/rtems/src/ratemongetstatistics.c|  61 +++--
>  cpukit/rtems/src/ratemongetstatus.c| 101 
>  cpukit/rtems/src/ratemonperiod.c   | 307 
> ++---
>  cpukit/rtems/src/ratemonresetstatistics.c  |  47 +---
>  cpukit/rtems/src/ratemontimeout.c  |  63 +++--
>  cpukit/score/include/rtems/score/threadimpl.h  |   7 +-
>  testsuites/sptests/spintrcritical08/init.c |  24 +-
>  11 files changed, 412 insertions(+), 435 deletions(-)
>
> diff --git a/cpukit/rtems/include/rtems/rtems/ratemon.h 
> b/cpukit/rtems/include/rtems/rtems/ratemon.h
> index 0159e5c..87bd064c 100644
> --- a/cpukit/rtems/include/rtems/rtems/ratemon.h
> +++ b/cpukit/rtems/include/rtems/rtems/ratemon.h
> @@ -84,24 +84,12 @@ typedef enum {
>
>/**
> * This value indicates the period is on the watchdog chain, and
> -   * the owner is blocked waiting on it.
> -   */
> -  RATE_MONOTONIC_OWNER_IS_BLOCKING,
> -
> -  /**
> -   * This value indicates the period is on the watchdog chain, and
> * running.  The owner should be executed or blocked waiting on
> * another object.
> */
>RATE_MONOTONIC_ACTIVE,
>
>/**
> -   * This value indicates the period is on the watchdog chain, and
> -   * has expired.  The owner should be blocked waiting for the next period.
> -   */
> -  RATE_MONOTONIC_EXPIRED_WHILE_BLOCKING,
> -
> -  /**
> * This value indicates the period is off the watchdog chain, and
> * has expired.  The owner is still executing and has taken too much
> * all time to complete this iteration of the period.
> @@ -194,8 +182,12 @@ typedef struct {
>  }  rtems_rate_monotonic_period_status;
>
>  /**
> - *  The following structure defines the control block used to manage
> - *  each period.
> + * @brief The following structure defines the control block used to manage 
> each
> + * period.
> + *
> + * State changes are protected by the default thread lock of the owner 
> thread.
> + * The owner thread is the thread that created the period object.  The owner
> + * thread field is immutable after object creation.
>   */
>  typedef struct {
>/** This field is the object management portion of a Period instance. */
> diff --git a/cpukit/rtems/include/rtems/rtems/ratemonimpl.h 
> b/cpukit/rtems/include/rtems/rtems/ratemonimpl.h
> index 3141bfa..28837a2 100644
> --- a/cpukit/rtems/include/rtems/rtems/ratemonimpl.h
> +++ b/cpukit/rtems/include/rtems/rtems/ratemonimpl.h
> @@ -8,6 +8,7 @@
>
>  /*  COPYRIGHT (c) 1989-2008.
>   *  On-Line Applications Research Corporation (OAR).
> + *  Copyright (c) 2016 embedded brains GmbH.
>   *
>   *  The license and distribution terms for this file may be
>   *  found in the file LICENSE in this distribution or at
> @@ -19,6 +20,9 @@
>
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>
>  #include 
>
> @@ -34,6 +38,15 @@ extern "C" {
>   * @{
>   */
>
> +#define RATE_MONOTONIC_INTEND_TO_BLOCK \
> +  ( THREAD_WAIT_CLASS_PERIOD | THREAD_WAIT_STATE_INTEND_TO_BLOCK )
> +
> +#define RATE_MONOTONIC_BLOCKED \
> +  ( THREAD_WAIT_CLASS_PERIOD | THREAD_WAIT_STATE_BLOCKED )
> +
> +#define RATE_MONOTONIC_READY_AGAIN \
> +  ( THREAD_WAIT_CLASS_PERIOD | THREAD_WAIT_STATE_READY_AGAIN )
> +
>  /**
>   *  @brief Rate Monotonic Period Class Management Structure
>   *
> @@ -55,86 +68,31 @@ RTEMS_INLINE_ROUTINE Rate_monotonic_Control 
> *_Rate_monotonic_Allocate( void )
>  _Objects_Allocate( &_Rate_monotonic_Information );
>  }
>
> -/**
> - *  @brief Allocates a period control block from
> - *  the inactive chain of free period control blocks.
> - *
> - *  This routine allocates a period control block from
> - *  the inactive chain of free period control blocks.
> - */
> -RTEMS_INLINE_ROUTINE void _Rate_monotonic_Free (
> -  Rate_monotonic_Control *the_period
> +RTEMS_INLINE_ROUTINE void _Rate_monotonic_Acquire_critical(
> +  Thread_Control   *the_thread,
> +  ISR_lock_Context *lock_context
>  )
>  {
> -  _Objects_Free( &_Rate_monotonic_Information, _period->Object );
> +  _Thread_Lock_acquire_default_critical( the_thread, lock_context );
>  }
>
> -/**
> - *  @brief Maps period IDs to period control blocks.
> - *
> - *  This function maps period IDs to period control blocks.
> - *  If ID corresponds to a local period, then it returns
> -

Re: [PATCH] [RSB 4.11] Bump OpenRISC versions

2016-03-21 Thread Gedare Bloom

Hi Hesham,

I think the 4.12 patch is there. (updates 2669)

On Mon, Mar 21, 2016 at 6:49 PM, Hesham Almatary
 wrote:
> The patch works fine for 4.11 branches on both or1ksim and qemu. 4.12
> patch will be really appreciated.
>
> On Mon, Mar 21, 2016 at 8:34 AM, Hesham Almatary
>  wrote:
>> On Mon, Mar 21, 2016 at 8:24 AM, Stefan Wallentowitz
>>  wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA1
>>>
>>> On 20.03.2016 22:17, Hesham Almatary wrote:
 Hi Stefan,

 Thanks you! The gcc-4.8 patch was aging, so updating it is great.

 Have you had a chance to build the or1k BSP and run ticker or hello
 on or1ksim with those new patches?

 Cheers, Hesham

>>>
>>> Hi,
>>>
>>> I have run hello and some other samples on an FPGA board. I will check
>>> or1ksim soon.
>>>
>> Great. I'll build the whole RTEMS/or1k env again and test it,
>> hopefully soon and will let you know how it goes.
>>
>>> Best,
>>> Stefan
>>>
>>> -BEGIN PGP SIGNATURE-
>>> Version: GnuPG v2
>>>
>>> iEYEARECAAYFAlbvFQAACgkQuMYtsrn2U9x+rwCfaBnKaKSEKK8MLkp+T5eyXaZI
>>> WIsAoKTjGlsLEkxKnXV3osRVusynrH2U
>>> =q8DR
>>> -END PGP SIGNATURE-
>>
>>
>>
>> --
>> Hesham
>
>
>
> --
> Hesham
> ___
> 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] [RSB 4.11] Bump OpenRISC versions

2016-03-21 Thread Hesham Almatary

The patch works fine for 4.11 branches on both or1ksim and qemu. 4.12
patch will be really appreciated.

On Mon, Mar 21, 2016 at 8:34 AM, Hesham Almatary
 wrote:
> On Mon, Mar 21, 2016 at 8:24 AM, Stefan Wallentowitz
>  wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 20.03.2016 22:17, Hesham Almatary wrote:
>>> Hi Stefan,
>>>
>>> Thanks you! The gcc-4.8 patch was aging, so updating it is great.
>>>
>>> Have you had a chance to build the or1k BSP and run ticker or hello
>>> on or1ksim with those new patches?
>>>
>>> Cheers, Hesham
>>>
>>
>> Hi,
>>
>> I have run hello and some other samples on an FPGA board. I will check
>> or1ksim soon.
>>
> Great. I'll build the whole RTEMS/or1k env again and test it,
> hopefully soon and will let you know how it goes.
>
>> Best,
>> Stefan
>>
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v2
>>
>> iEYEARECAAYFAlbvFQAACgkQuMYtsrn2U9x+rwCfaBnKaKSEKK8MLkp+T5eyXaZI
>> WIsAoKTjGlsLEkxKnXV3osRVusynrH2U
>> =q8DR
>> -END PGP SIGNATURE-
>
>
>
> --
> Hesham



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

Re: [PATCH 3/5] libstdthreads/thrd.c: Mark path as unreachable on GCC to resolve warning

2016-03-21 Thread Joel Sherrill

On Mon, Mar 21, 2016 at 7:33 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 21/03/16 13:31, Joel Sherrill wrote:
>
>>
>>
>> On Mon, Mar 21, 2016 at 1:26 AM, Sebastian Huber <
>> sebastian.hu...@embedded-brains.de > sebastian.hu...@embedded-brains.de>> wrote:
>>
>>
>>
>> On 20/03/16 21:40, Joel Sherrill wrote:
>>
>> ---
>>   cpukit/libstdthreads/thrd.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/cpukit/libstdthreads/thrd.c
>> b/cpukit/libstdthreads/thrd.c
>> index c2e439f..cc2d20f 100644
>> --- a/cpukit/libstdthreads/thrd.c
>> +++ b/cpukit/libstdthreads/thrd.c
>> @@ -96,6 +96,9 @@ thrd_exit(int res)
>>   {
>> pthread_exit((void *)(intptr_t)res);
>> +   #if defined(__GNUC__)
>> +   __builtin_unreachable();
>> +   #endif
>>   }
>> int
>>
>>
>> We should fix the pthread_exit() declaration instead, e.g. FreeBSD
>> has this:
>>
>> void  pthread_exit(void *) __dead2;
>>
>> Does that map to gcc noreturn? And does newlib have that?
>>
>
> Yes, or Noreturn if you use the appropriate C++ version. Needs
> .
>
>
That moves the noreturn warning.

/data/home/joel/test-gcc/install-head/sparc-rtems4.12/include/pthread.h: In
function 'pthread_exit':
../../../../../../rtems/c/src/../../cpukit/posix/src/pthreadexit.c:78:1:
warning: 'noreturn' function does return
 }
 ^

Other than marking pthread_exit's return as unreachable, do you have
another suggestion?

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

Re: GSoC 2016 Participation

2016-03-21 Thread Rahul Goradia

Thanks for the prompt reply.
Is there any other open project related to resource management or
scheduling in which I can contribute?

On Mon, Mar 21, 2016 at 8:00 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> They are already implemented, but since there is currently no use case for
> them, they are not included in the sources.
>
> On 21/03/16 15:29, Rahul Goradia wrote:
>
>> Will implementation of phase fair RW locks be considered in this GSOC?
>> I know I am very late to ask this question.
>> I have read the concept and theory of phase fair RW locks from reference
>> suggested in RTEMS( http://www.mpi-sws.org/~bbb/papers/pdf/rtsj11.pdf <
>> http://www.mpi-sws.org/%7Ebbb/papers/pdf/rtsj11.pdf>)
>>
>> On Mon, Mar 21, 2016 at 12:02 PM, Sebastian Huber <
>> sebastian.hu...@embedded-brains.de > sebastian.hu...@embedded-brains.de>> wrote:
>>
>>
>>
>> On 19/03/16 02:35, Gedare Bloom wrote:
>>
>> On Fri, Mar 18, 2016 at 6:03 PM, Павел
>> Мовчан> wrote:
>>
>> >Hello all,
>> >
>> >I want to work with RTEMS and do some work for it.
>> >I find SMP and "Condition Variables"(status?) is very
>> interesting for me. I
>>
>> SMP is moving fast right now. Sebastian Huber may have more to
>> say on
>> whether anything is worth trying for GSoC.
>>
>>
>> SMP and GSoC is maybe something for next year. The condition
>> variables are not suitable as a GSoC project.
>>
>> -- 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
>>
>>
>>
>>
>> --
>> Regards,
>>
>> Rahul Goradia
>> Assistant Professor,
>> Electronics and Communication Department,
>> G H Patel College of Engineering and Technology.
>> Contact Number : 9725203179
>>
>
> --
> 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.
>
>


-- 
Regards,

Rahul Goradia
Assistant Professor,
Electronics and Communication Department,
G H Patel College of Engineering and Technology.
Contact Number : 9725203179
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] rtems: Rework rate-monotonic scheduler

2016-03-21 Thread Sebastian Huber

Use the default thread lock to protect rate-monotonic state changes.
his avoids use of the Giant lock.  Split rtems_rate_monotonic_period()
body into several static functions.  Introduce a new thread wait class
THREAD_WAIT_CLASS_PERIOD for period objects to synchronize the blocking
operation.

Close #2631.
---
 cpukit/rtems/include/rtems/rtems/ratemon.h |  20 +-
 cpukit/rtems/include/rtems/rtems/ratemonimpl.h | 113 +++--
 cpukit/rtems/src/ratemoncancel.c   |  65 +++---
 cpukit/rtems/src/ratemondelete.c   |  39 ++--
 cpukit/rtems/src/ratemongetstatistics.c|  61 +++--
 cpukit/rtems/src/ratemongetstatus.c| 101 
 cpukit/rtems/src/ratemonperiod.c   | 307 ++---
 cpukit/rtems/src/ratemonresetstatistics.c  |  47 +---
 cpukit/rtems/src/ratemontimeout.c  |  63 +++--
 cpukit/score/include/rtems/score/threadimpl.h  |   7 +-
 testsuites/sptests/spintrcritical08/init.c |  24 +-
 11 files changed, 412 insertions(+), 435 deletions(-)

diff --git a/cpukit/rtems/include/rtems/rtems/ratemon.h 
b/cpukit/rtems/include/rtems/rtems/ratemon.h
index 0159e5c..87bd064c 100644
--- a/cpukit/rtems/include/rtems/rtems/ratemon.h
+++ b/cpukit/rtems/include/rtems/rtems/ratemon.h
@@ -84,24 +84,12 @@ typedef enum {
 
   /**
* This value indicates the period is on the watchdog chain, and
-   * the owner is blocked waiting on it.
-   */
-  RATE_MONOTONIC_OWNER_IS_BLOCKING,
-
-  /**
-   * This value indicates the period is on the watchdog chain, and
* running.  The owner should be executed or blocked waiting on
* another object.
*/
   RATE_MONOTONIC_ACTIVE,
 
   /**
-   * This value indicates the period is on the watchdog chain, and
-   * has expired.  The owner should be blocked waiting for the next period.
-   */
-  RATE_MONOTONIC_EXPIRED_WHILE_BLOCKING,
-
-  /**
* This value indicates the period is off the watchdog chain, and
* has expired.  The owner is still executing and has taken too much
* all time to complete this iteration of the period.
@@ -194,8 +182,12 @@ typedef struct {
 }  rtems_rate_monotonic_period_status;
 
 /**
- *  The following structure defines the control block used to manage
- *  each period.
+ * @brief The following structure defines the control block used to manage each
+ * period.
+ *
+ * State changes are protected by the default thread lock of the owner thread.
+ * The owner thread is the thread that created the period object.  The owner
+ * thread field is immutable after object creation.
  */
 typedef struct {
   /** This field is the object management portion of a Period instance. */
diff --git a/cpukit/rtems/include/rtems/rtems/ratemonimpl.h 
b/cpukit/rtems/include/rtems/rtems/ratemonimpl.h
index 3141bfa..28837a2 100644
--- a/cpukit/rtems/include/rtems/rtems/ratemonimpl.h
+++ b/cpukit/rtems/include/rtems/rtems/ratemonimpl.h
@@ -8,6 +8,7 @@
 
 /*  COPYRIGHT (c) 1989-2008.
  *  On-Line Applications Research Corporation (OAR).
+ *  Copyright (c) 2016 embedded brains GmbH.
  *
  *  The license and distribution terms for this file may be
  *  found in the file LICENSE in this distribution or at
@@ -19,6 +20,9 @@
 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 
@@ -34,6 +38,15 @@ extern "C" {
  * @{
  */
 
+#define RATE_MONOTONIC_INTEND_TO_BLOCK \
+  ( THREAD_WAIT_CLASS_PERIOD | THREAD_WAIT_STATE_INTEND_TO_BLOCK )
+
+#define RATE_MONOTONIC_BLOCKED \
+  ( THREAD_WAIT_CLASS_PERIOD | THREAD_WAIT_STATE_BLOCKED )
+
+#define RATE_MONOTONIC_READY_AGAIN \
+  ( THREAD_WAIT_CLASS_PERIOD | THREAD_WAIT_STATE_READY_AGAIN )
+
 /**
  *  @brief Rate Monotonic Period Class Management Structure
  *
@@ -55,86 +68,31 @@ RTEMS_INLINE_ROUTINE Rate_monotonic_Control 
*_Rate_monotonic_Allocate( void )
 _Objects_Allocate( &_Rate_monotonic_Information );
 }
 
-/**
- *  @brief Allocates a period control block from
- *  the inactive chain of free period control blocks.
- *
- *  This routine allocates a period control block from
- *  the inactive chain of free period control blocks.
- */
-RTEMS_INLINE_ROUTINE void _Rate_monotonic_Free (
-  Rate_monotonic_Control *the_period
+RTEMS_INLINE_ROUTINE void _Rate_monotonic_Acquire_critical(
+  Thread_Control   *the_thread,
+  ISR_lock_Context *lock_context
 )
 {
-  _Objects_Free( &_Rate_monotonic_Information, _period->Object );
+  _Thread_Lock_acquire_default_critical( the_thread, lock_context );
 }
 
-/**
- *  @brief Maps period IDs to period control blocks.
- *
- *  This function maps period IDs to period control blocks.
- *  If ID corresponds to a local period, then it returns
- *  the_period control pointer which maps to ID and location
- *  is set to OBJECTS_LOCAL.  Otherwise, location is set
- *  to OBJECTS_ERROR and the_period is undefined.
- */
-RTEMS_INLINE_ROUTINE Rate_monotonic_Control *_Rate_monotonic_Get (
-  Objects_Id id,
-  Objects_Locations *location
+RTEMS_INLINE_ROUTINE void _Rate_monotonic_Release(
+

Re: GSoC 2016 Participation

2016-03-21 Thread Rahul Goradia

Will implementation of phase fair RW locks be considered in this GSOC?
I know I am very late to ask this question.
I have read the concept and theory of phase fair RW locks from reference
suggested in RTEMS( http://www.mpi-sws.org/~bbb/papers/pdf/rtsj11.pdf)

On Mon, Mar 21, 2016 at 12:02 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 19/03/16 02:35, Gedare Bloom wrote:
>
>> On Fri, Mar 18, 2016 at 6:03 PM, Павел Мовчан
>> wrote:
>>
>>> >Hello all,
>>> >
>>> >I want to work with RTEMS and do some work for it.
>>> >I find SMP and "Condition Variables"(status?) is very interesting for
>>> me. I
>>>
>> SMP is moving fast right now. Sebastian Huber may have more to say on
>> whether anything is worth trying for GSoC.
>>
>>
> SMP and GSoC is maybe something for next year. The condition variables are
> not suitable as a GSoC project.
>
> --
> 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
>

-- 
Regards,

Rahul Goradia
Assistant Professor,
Electronics and Communication Department,
G H Patel College of Engineering and Technology.
Contact Number : 9725203179
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2016 Participation

2016-03-21 Thread Sebastian Huber

They are already implemented, but since there is currently no use case 
for them, they are not included in the sources.

On 21/03/16 15:29, Rahul Goradia wrote:

Will implementation of phase fair RW locks be considered in this GSOC?
I know I am very late to ask this question.
I have read the concept and theory of phase fair RW locks from 
reference suggested in RTEMS( 
http://www.mpi-sws.org/~bbb/papers/pdf/rtsj11.pdf 
)

On Mon, Mar 21, 2016 at 12:02 PM, Sebastian Huber 
> wrote:

On 19/03/16 02:35, Gedare Bloom wrote:

On Fri, Mar 18, 2016 at 6:03 PM, Павел
Мовчан> wrote:

>Hello all,
>
>I want to work with RTEMS and do some work for it.
>I find SMP and "Condition Variables"(status?) is very
interesting for me. I

SMP is moving fast right now. Sebastian Huber may have more to
say on
whether anything is worth trying for GSoC.

SMP and GSoC is maybe something for next year. The condition
variables are not suitable as a GSoC project.

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

--
Regards,

Rahul Goradia
Assistant Professor,
Electronics and Communication Department,
G H Patel College of Engineering and Technology.
Contact Number : 9725203179

--
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: Request for GPIO Examples

2016-03-21 Thread Worth Burruss

On 16 Mar 2016 at 2:30, punit vara wrote:

> > Hi
> >
> > Are there any example programs for the GPIO? I realize they would be
> > specific to the BBB or Pi but would appreciate getting some code.
> >
> > Thanks.
> >
> > --joel
> I tested GPIO APIs in Beaglebone black with LED blinking. You can look
> into https://github.com/punitvara/rtems_gsoc16 if it's useful for you.


Thank you, I was the one asking. It is what I was looking for.

Sorry it took so long to respond , I have been away from email.

Worth



> ___
> 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 3/5] libstdthreads/thrd.c: Mark path as unreachable on GCC to resolve warning

2016-03-21 Thread Sebastian Huber




On 21/03/16 13:31, Joel Sherrill wrote:



On Mon, Mar 21, 2016 at 1:26 AM, Sebastian Huber 
> wrote:




On 20/03/16 21:40, Joel Sherrill wrote:

---
  cpukit/libstdthreads/thrd.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/cpukit/libstdthreads/thrd.c
b/cpukit/libstdthreads/thrd.c
index c2e439f..cc2d20f 100644
--- a/cpukit/libstdthreads/thrd.c
+++ b/cpukit/libstdthreads/thrd.c
@@ -96,6 +96,9 @@ thrd_exit(int res)
  {
pthread_exit((void *)(intptr_t)res);
+   #if defined(__GNUC__)
+   __builtin_unreachable();
+   #endif
  }
int


We should fix the pthread_exit() declaration instead, e.g. FreeBSD
has this:

void  pthread_exit(void *) __dead2;

Does that map to gcc noreturn? And does newlib have that?


Yes, or Noreturn if you use the appropriate C++ version. Needs 
.


--
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/5] libstdthreads/thrd.c: Mark path as unreachable on GCC to resolve warning

2016-03-21 Thread Joel Sherrill

On Mon, Mar 21, 2016 at 1:26 AM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 20/03/16 21:40, Joel Sherrill wrote:
>
>> ---
>>   cpukit/libstdthreads/thrd.c | 3 +++
>>   1 file changed, 3 insertions(+)
>>
>> diff --git a/cpukit/libstdthreads/thrd.c b/cpukit/libstdthreads/thrd.c
>> index c2e439f..cc2d20f 100644
>> --- a/cpukit/libstdthreads/thrd.c
>> +++ b/cpukit/libstdthreads/thrd.c
>> @@ -96,6 +96,9 @@ thrd_exit(int res)
>>   {
>> pthread_exit((void *)(intptr_t)res);
>> +   #if defined(__GNUC__)
>> +   __builtin_unreachable();
>> +   #endif
>>   }
>> int
>>
>
> We should fix the pthread_exit() declaration instead, e.g. FreeBSD has
> this:
>
> void  pthread_exit(void *) __dead2;
>
> Does that map to gcc noreturn? And does newlib have that?

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

Re: 4.11 Branch Failures

2016-03-21 Thread Chris Johns


On 21/03/2016 17:29, Sebastian Huber wrote:


Its already fixed on the master.

https://git.rtems.org/rtems-tools/commit/?id=f027f37661fc8c12ab07f92982f0c86e4e0717de



Thanks.


 From my point of view we should not use branches for the RTEMS Tools
and RSB.


I had been undecided on this for a while and now I think it is a good 
idea have the release branches. I feel the other side of having to 
always check every change has not broken _all_ releases taken from it is 
too much.


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

Re: GSoC 2016 Participation

2016-03-21 Thread Sebastian Huber

On 19/03/16 02:35, Gedare Bloom wrote:

On Fri, Mar 18, 2016 at 6:03 PM, Павел Мовчан  wrote:

>Hello all,
>
>I want to work with RTEMS and do some work for it.
>I find SMP and "Condition Variables"(status?) is very interesting for me. I

SMP is moving fast right now. Sebastian Huber may have more to say on
whether anything is worth trying for GSoC.

SMP and GSoC is maybe something for next year. The condition variables 
are not suitable as a GSoC project.

--
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: 4.11 Branch Failures

2016-03-21 Thread Sebastian Huber




On 21/03/16 06:30, Chris Johns wrote:

On 21/03/2016 14:40, Joel Sherrill wrote:


(2) There is this group of powerpc BSPs failing on dl01:


  [snip]

No. If could be rtems-tld. What is the error?

mv dl01.pre.exe dl01.pre
rtems-syms -e -c "-mcpu=603e -mstrict-align -meabi -msdata=sysv
-fno-common -O2 -g -fno-keep-inline-functions -Wall -Wmissing-prototypes
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs" -o
dl-sym.o dl01.pre
powerpc-rtems4.11-gcc -B../../../../../brs5l/lib/ -specs bsp_specs
-qrtems -mcpu=603e -mstrict-align -meabi -msdata=sysv -fno-common -O2 -g
-fno-keep-inline-functions -Wall -Wmissing-prototypes
-Wimplicit-function-declaration -Wstrict-prototypes -Wnested-externs
  -mcpu=603e -mstrict-align -meabi -msdata=sysv -fno-common   \
 -o dl01.exe init.o dl-load.o dl-tar.o dl-sym.o
/home/joel/rtems-4.11-work/tools/4.11/lib/gcc/powerpc-rtems4.11/4.9.3/../../../../powerpc-rtems4.11/bin/ld: 


dl-sym.o: the target (rtems__rtl_base_globals_size) of a R_PPC_SDAREL16
relocation is in the wrong output section (.text)
dl-sym.o: In function `rtems_rtl_base_global_syms_init':
rld--bTdaaa.c:(.text+0x6): relocation truncated to fit: R_PPC_SDAREL16
against `rtems__rtl_base_globals_size'
collect2: error: ld returned 1 exit status
Makefile:662: recipe for target 'dl01.exe' failed


This means the rtems-syms tool needs to be taught how to create a 
suitable symbols file for the PowerPC. Sebastian are you able to have 
a look? 


Its already fixed on the master.

https://git.rtems.org/rtems-tools/commit/?id=f027f37661fc8c12ab07f92982f0c86e4e0717de

From my point of view we should not use branches for the RTEMS Tools 
and RSB.


--
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/5] libstdthreads/thrd.c: Mark path as unreachable on GCC to resolve warning

2016-03-21 Thread Sebastian Huber




On 20/03/16 21:40, Joel Sherrill wrote:

---
  cpukit/libstdthreads/thrd.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/cpukit/libstdthreads/thrd.c b/cpukit/libstdthreads/thrd.c
index c2e439f..cc2d20f 100644
--- a/cpukit/libstdthreads/thrd.c
+++ b/cpukit/libstdthreads/thrd.c
@@ -96,6 +96,9 @@ thrd_exit(int res)
  {
  
  	pthread_exit((void *)(intptr_t)res);

+   #if defined(__GNUC__)
+   __builtin_unreachable();
+   #endif
  }
  
  int


We should fix the pthread_exit() declaration instead, e.g. FreeBSD has this:

void  pthread_exit(void *) __dead2;

--
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] [RSB 4.11] Bump OpenRISC versions

Re: [PATCH] rtems: Rework rate-monotonic scheduler

Re: [PATCH] [RSB 4.11] Bump OpenRISC versions

Re: [PATCH] [RSB 4.11] Bump OpenRISC versions

Re: [PATCH 3/5] libstdthreads/thrd.c: Mark path as unreachable on GCC to resolve warning

Re: GSoC 2016 Participation

[PATCH] rtems: Rework rate-monotonic scheduler

Re: GSoC 2016 Participation

Re: GSoC 2016 Participation

Re: Request for GPIO Examples

Re: [PATCH 3/5] libstdthreads/thrd.c: Mark path as unreachable on GCC to resolve warning

Re: [PATCH 3/5] libstdthreads/thrd.c: Mark path as unreachable on GCC to resolve warning

Re: 4.11 Branch Failures

Re: GSoC 2016 Participation

Re: 4.11 Branch Failures

Re: [PATCH 3/5] libstdthreads/thrd.c: Mark path as unreachable on GCC to resolve warning

16 matches

Site Navigation

Mail list logo

Footer information