RFC Obseleting ods302 and gen68302 BSPs

2016-01-11 Thread Joel Sherrill 
Hi

If anyone has objections to removing these BSPs and associated variants,
please speak up. Otherwise, I will be shortly filing a ticket for each to
be removed prior to 4.12.

Thanks.

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

RFC Obsoleting mbx8xx BSP

2016-01-11 Thread Joel Sherrill 
Hi

If anyone has objections to removing these BSPs and associated variants,
please speak up. Otherwise, I will be shortly filing a ticket for each to
be removed prior to 4.12.

Thanks.

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

Re: Problem with system time in lpc176x bsp

2016-01-11 Thread Marcos Diaz 
Hi Sebastian,

we did some more testing and found out what's causing the problem. Based on what
I posted at https://lists.rtems.org/pipermail/devel/2015-December/013235.html,
the problem arises when the ticker interrupt occurs while a task is executing
one of the instructions that make up the following line:

is_count_pending = (systick->csr & ARMV7M_SYSTICK_CSR_COUNTFLAG) != 0;

which compiling with -O3 are:

ldr.w r3, [r9]
ubfx r5, r3, #16, #1
strb.w r5, [r8, #64]

If the SysTick counts to 0 and the ldr executes before the interrupt occurs,
R3 will have the CSR.COUNTFLAG bit set. Even though _ARMV7M_TC_at_tick will
clear the is_count_pending boolean, the task will still see it as true.

The solution we found is to simply disable interrupts while reading that flag.
We also use a local variable inside _ARMV7M_TC_is_pending instead of directly
returning the current value of the is_count_pending global, just in case.

Here's the patch that fixes it; this applies to the 4.11 branch.
Do we have to open a new thread for it to be applied to the mainline, or will
this suffice? Should we open a ticket for 4.11?

---
 .../arm/shared/armv7m/clock/armv7m-clock-config.c  | 38 +++---
 c/src/lib/libbsp/shared/clockdrv_shell.h   | 16 -
 cpukit/rtems/src/clocktick.c   |  6 +++-
 cpukit/sapi/include/rtems/timecounter.h| 35 
 cpukit/score/include/rtems/score/timecounter.h | 37 +++--
 cpukit/score/src/kern_tc.c | 16 -
 doc/bsp_howto/clock.t  | 13 +++-
 7 files changed, 130 insertions(+), 31 deletions(-)

diff --git a/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c 
b/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
index e78684c..53bd7cf 100644
--- a/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
+++ b/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
@@ -25,6 +25,8 @@ static void Clock_isr(void *arg);

 static rtems_timecounter_simple _ARMV7M_TC;

+static bool is_count_pending = false;
+
 static uint32_t _ARMV7M_TC_get(rtems_timecounter_simple *tc)
 {
   volatile ARMV7M_Systick *systick = _ARMV7M_Systick;
@@ -34,9 +36,20 @@ static uint32_t _ARMV7M_TC_get(rtems_timecounter_simple *tc)

 static bool _ARMV7M_TC_is_pending(rtems_timecounter_simple *tc)
 {
-  volatile ARMV7M_SCB *scb = _ARMV7M_SCB;
+  volatile ARMV7M_Systick *systick = _ARMV7M_Systick;
+  ISR_lock_Context lock_context;
+
+  _Timecounter_Acquire( &lock_context );
+  /* We use this bool since the hardware flag is reset each time it is read. */
+  if (!is_count_pending)
+  {
+is_count_pending = ((systick->csr & ARMV7M_SYSTICK_CSR_COUNTFLAG) != 0 );
+  }

-  return ((scb->icsr & ARMV7M_SCB_ICSR_PENDSTSET) != 0);
+  const bool is_pending_local = is_count_pending;
+
+  _Timecounter_Release( &lock_context );
+  return is_pending_local;
 }

 static uint32_t _ARMV7M_TC_get_timecount(struct timecounter *tc)
@@ -48,19 +61,23 @@ static uint32_t _ARMV7M_TC_get_timecount(struct timecounter 
*tc)
   );
 }

-static void _ARMV7M_TC_tick(void)
-{
-  rtems_timecounter_simple_downcounter_tick(&_ARMV7M_TC, _ARMV7M_TC_get);
-}
-
-static void _ARMV7M_Systick_at_tick(void)
+static void _ARMV7M_TC_at_tick(rtems_timecounter_simple *tc)
 {
   volatile ARMV7M_Systick *systick = _ARMV7M_Systick;
-
+  is_count_pending = false;
   /* Clear COUNTFLAG */
   systick->csr;
 }

+static void _ARMV7M_TC_tick(void)
+{
+  rtems_timecounter_simple_downcounter_tick(
+&_ARMV7M_TC,
+_ARMV7M_TC_get,
+_ARMV7M_TC_at_tick
+  );
+}
+
 static void _ARMV7M_Systick_handler(void)
 {
   _ARMV7M_Interrupt_service_enter();
@@ -111,9 +128,6 @@ static void _ARMV7M_Systick_cleanup(void)

 #define Clock_driver_timecounter_tick() _ARMV7M_TC_tick()

-#define Clock_driver_support_at_tick() \
-  _ARMV7M_Systick_at_tick()
-
 #define Clock_driver_support_initialize_hardware() \
   _ARMV7M_Systick_initialize()

diff --git a/c/src/lib/libbsp/shared/clockdrv_shell.h 
b/c/src/lib/libbsp/shared/clockdrv_shell.h
index d546fb8..96b962f 100644
--- a/c/src/lib/libbsp/shared/clockdrv_shell.h
+++ b/c/src/lib/libbsp/shared/clockdrv_shell.h
@@ -44,6 +44,13 @@
   #define Clock_driver_support_find_timer()
 #endif

+/**
+ * @brief Do nothing by default.
+ */
+#ifndef Clock_driver_support_at_tick
+  #define Clock_driver_support_at_tick()
+#endif
+
 /*
  * A specialized clock driver may use for example 
rtems_timecounter_tick_simple()
  * instead of the default.
@@ -108,7 +115,14 @@ rtems_isr Clock_isr(
   && _Thread_Executing->Start.entry_point
 == (Thread_Entry) rtems_configuration_get_idle_task()
   ) {
-_Timecounter_Tick_simple(interval, (*tc->tc_get_timecount)(tc));
+ISR_lock_Context lock_context;
+
+_Timecounter_Acquire(&lock_context);
+_Timecounter_Tick_simple(
+  interval,
+  (*tc->tc_get_timecount)(tc),
+  &lock_context

Re: Problem with system time in lpc176x bsp

2016-01-11 Thread Joel Sherrill 
At this point, a ticket is needed for anything applied to 4.11 that is not
release
mechanics related.

--joel

On Mon, Jan 11, 2016 at 11:47 AM, Marcos Diaz <
marcos.d...@tallertechnologies.com> wrote:

> Hi Sebastian,
>
> we did some more testing and found out what's causing the problem. Based
> on what
> I posted at
> https://lists.rtems.org/pipermail/devel/2015-December/013235.html,
> the problem arises when the ticker interrupt occurs while a task is
> executing
> one of the instructions that make up the following line:
>
> is_count_pending = (systick->csr & ARMV7M_SYSTICK_CSR_COUNTFLAG) != 0;
>
> which compiling with -O3 are:
>
> ldr.w r3, [r9]
> ubfx r5, r3, #16, #1
> strb.w r5, [r8, #64]
>
> If the SysTick counts to 0 and the ldr executes before the interrupt
> occurs,
> R3 will have the CSR.COUNTFLAG bit set. Even though _ARMV7M_TC_at_tick will
> clear the is_count_pending boolean, the task will still see it as true.
>
> The solution we found is to simply disable interrupts while reading that
> flag.
> We also use a local variable inside _ARMV7M_TC_is_pending instead of
> directly
> returning the current value of the is_count_pending global, just in case.
>
> Here's the patch that fixes it; this applies to the 4.11 branch.
> Do we have to open a new thread for it to be applied to the mainline, or
> will
> this suffice? Should we open a ticket for 4.11?
>
> ---
>  .../arm/shared/armv7m/clock/armv7m-clock-config.c  | 38
> +++---
>  c/src/lib/libbsp/shared/clockdrv_shell.h   | 16 -
>  cpukit/rtems/src/clocktick.c   |  6 +++-
>  cpukit/sapi/include/rtems/timecounter.h| 35
> 
>  cpukit/score/include/rtems/score/timecounter.h | 37
> +++--
>  cpukit/score/src/kern_tc.c | 16 -
>  doc/bsp_howto/clock.t  | 13 +++-
>  7 files changed, 130 insertions(+), 31 deletions(-)
>
> diff --git
> a/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
> b/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
> index e78684c..53bd7cf 100644
> --- a/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
> +++ b/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
> @@ -25,6 +25,8 @@ static void Clock_isr(void *arg);
>
>  static rtems_timecounter_simple _ARMV7M_TC;
>
> +static bool is_count_pending = false;
> +
>  static uint32_t _ARMV7M_TC_get(rtems_timecounter_simple *tc)
>  {
>volatile ARMV7M_Systick *systick = _ARMV7M_Systick;
> @@ -34,9 +36,20 @@ static uint32_t _ARMV7M_TC_get(rtems_timecounter_simple
> *tc)
>
>  static bool _ARMV7M_TC_is_pending(rtems_timecounter_simple *tc)
>  {
> -  volatile ARMV7M_SCB *scb = _ARMV7M_SCB;
> +  volatile ARMV7M_Systick *systick = _ARMV7M_Systick;
> +  ISR_lock_Context lock_context;
> +
> +  _Timecounter_Acquire( &lock_context );
> +  /* We use this bool since the hardware flag is reset each time it is
> read. */
> +  if (!is_count_pending)
> +  {
> +is_count_pending = ((systick->csr & ARMV7M_SYSTICK_CSR_COUNTFLAG) !=
> 0 );
> +  }
>
> -  return ((scb->icsr & ARMV7M_SCB_ICSR_PENDSTSET) != 0);
> +  const bool is_pending_local = is_count_pending;
> +
> +  _Timecounter_Release( &lock_context );
> +  return is_pending_local;
>  }
>
>  static uint32_t _ARMV7M_TC_get_timecount(struct timecounter *tc)
> @@ -48,19 +61,23 @@ static uint32_t _ARMV7M_TC_get_timecount(struct
> timecounter *tc)
>);
>  }
>
> -static void _ARMV7M_TC_tick(void)
> -{
> -  rtems_timecounter_simple_downcounter_tick(&_ARMV7M_TC, _ARMV7M_TC_get);
> -}
> -
> -static void _ARMV7M_Systick_at_tick(void)
> +static void _ARMV7M_TC_at_tick(rtems_timecounter_simple *tc)
>  {
>volatile ARMV7M_Systick *systick = _ARMV7M_Systick;
> -
> +  is_count_pending = false;
>/* Clear COUNTFLAG */
>systick->csr;
>  }
>
> +static void _ARMV7M_TC_tick(void)
> +{
> +  rtems_timecounter_simple_downcounter_tick(
> +&_ARMV7M_TC,
> +_ARMV7M_TC_get,
> +_ARMV7M_TC_at_tick
> +  );
> +}
> +
>  static void _ARMV7M_Systick_handler(void)
>  {
>_ARMV7M_Interrupt_service_enter();
> @@ -111,9 +128,6 @@ static void _ARMV7M_Systick_cleanup(void)
>
>  #define Clock_driver_timecounter_tick() _ARMV7M_TC_tick()
>
> -#define Clock_driver_support_at_tick() \
> -  _ARMV7M_Systick_at_tick()
> -
>  #define Clock_driver_support_initialize_hardware() \
>_ARMV7M_Systick_initialize()
>
> diff --git a/c/src/lib/libbsp/shared/clockdrv_shell.h
> b/c/src/lib/libbsp/shared/clockdrv_shell.h
> index d546fb8..96b962f 100644
> --- a/c/src/lib/libbsp/shared/clockdrv_shell.h
> +++ b/c/src/lib/libbsp/shared/clockdrv_shell.h
> @@ -44,6 +44,13 @@
>#define Clock_driver_support_find_timer()
>  #endif
>
> +/**
> + * @brief Do nothing by default.
> + */
> +#ifndef Clock_driver_support_at_tick
> +  #define Clock_driver_support_at_tick()
> +#endif
> +
>  /*
>   * A specialized clock driver may use for example
> rtems_timecounter_tick_simple()
>

Re: Problem with system time in lpc176x bsp

2016-01-11 Thread Marcos Díaz 
I will issue a ticket. But I noticed that in my patch I include changes to
common code that Sebastian suggested, and this will break any other BSP
that uses rtems timecounter simple downcounter or upcounter, since these
function's signatures changed. Should we update all BSPs? Or make changes
more locally to our BSP?  Meanwhile please do not apply the patch I sent.


On Mon, Jan 11, 2016 at 3:16 PM, Joel Sherrill  wrote:

> At this point, a ticket is needed for anything applied to 4.11 that is not
> release
> mechanics related.
>
> --joel
>
> On Mon, Jan 11, 2016 at 11:47 AM, Marcos Diaz <
> marcos.d...@tallertechnologies.com> wrote:
>
>> Hi Sebastian,
>>
>> we did some more testing and found out what's causing the problem. Based
>> on what
>> I posted at
>> https://lists.rtems.org/pipermail/devel/2015-December/013235.html,
>> the problem arises when the ticker interrupt occurs while a task is
>> executing
>> one of the instructions that make up the following line:
>>
>> is_count_pending = (systick->csr & ARMV7M_SYSTICK_CSR_COUNTFLAG) != 0;
>>
>> which compiling with -O3 are:
>>
>> ldr.w r3, [r9]
>> ubfx r5, r3, #16, #1
>> strb.w r5, [r8, #64]
>>
>> If the SysTick counts to 0 and the ldr executes before the interrupt
>> occurs,
>> R3 will have the CSR.COUNTFLAG bit set. Even though _ARMV7M_TC_at_tick
>> will
>> clear the is_count_pending boolean, the task will still see it as true.
>>
>> The solution we found is to simply disable interrupts while reading that
>> flag.
>> We also use a local variable inside _ARMV7M_TC_is_pending instead of
>> directly
>> returning the current value of the is_count_pending global, just in case.
>>
>> Here's the patch that fixes it; this applies to the 4.11 branch.
>> Do we have to open a new thread for it to be applied to the mainline, or
>> will
>> this suffice? Should we open a ticket for 4.11?
>>
>> ---
>>  .../arm/shared/armv7m/clock/armv7m-clock-config.c  | 38
>> +++---
>>  c/src/lib/libbsp/shared/clockdrv_shell.h   | 16 -
>>  cpukit/rtems/src/clocktick.c   |  6 +++-
>>  cpukit/sapi/include/rtems/timecounter.h| 35
>> 
>>  cpukit/score/include/rtems/score/timecounter.h | 37
>> +++--
>>  cpukit/score/src/kern_tc.c | 16 -
>>  doc/bsp_howto/clock.t  | 13 +++-
>>  7 files changed, 130 insertions(+), 31 deletions(-)
>>
>> diff --git
>> a/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
>> b/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
>> index e78684c..53bd7cf 100644
>> --- a/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
>> +++ b/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
>> @@ -25,6 +25,8 @@ static void Clock_isr(void *arg);
>>
>>  static rtems_timecounter_simple _ARMV7M_TC;
>>
>> +static bool is_count_pending = false;
>> +
>>  static uint32_t _ARMV7M_TC_get(rtems_timecounter_simple *tc)
>>  {
>>volatile ARMV7M_Systick *systick = _ARMV7M_Systick;
>> @@ -34,9 +36,20 @@ static uint32_t
>> _ARMV7M_TC_get(rtems_timecounter_simple *tc)
>>
>>  static bool _ARMV7M_TC_is_pending(rtems_timecounter_simple *tc)
>>  {
>> -  volatile ARMV7M_SCB *scb = _ARMV7M_SCB;
>> +  volatile ARMV7M_Systick *systick = _ARMV7M_Systick;
>> +  ISR_lock_Context lock_context;
>> +
>> +  _Timecounter_Acquire( &lock_context );
>> +  /* We use this bool since the hardware flag is reset each time it is
>> read. */
>> +  if (!is_count_pending)
>> +  {
>> +is_count_pending = ((systick->csr & ARMV7M_SYSTICK_CSR_COUNTFLAG) !=
>> 0 );
>> +  }
>>
>> -  return ((scb->icsr & ARMV7M_SCB_ICSR_PENDSTSET) != 0);
>> +  const bool is_pending_local = is_count_pending;
>> +
>> +  _Timecounter_Release( &lock_context );
>> +  return is_pending_local;
>>  }
>>
>>  static uint32_t _ARMV7M_TC_get_timecount(struct timecounter *tc)
>> @@ -48,19 +61,23 @@ static uint32_t _ARMV7M_TC_get_timecount(struct
>> timecounter *tc)
>>);
>>  }
>>
>> -static void _ARMV7M_TC_tick(void)
>> -{
>> -  rtems_timecounter_simple_downcounter_tick(&_ARMV7M_TC, _ARMV7M_TC_get);
>> -}
>> -
>> -static void _ARMV7M_Systick_at_tick(void)
>> +static void _ARMV7M_TC_at_tick(rtems_timecounter_simple *tc)
>>  {
>>volatile ARMV7M_Systick *systick = _ARMV7M_Systick;
>> -
>> +  is_count_pending = false;
>>/* Clear COUNTFLAG */
>>systick->csr;
>>  }
>>
>> +static void _ARMV7M_TC_tick(void)
>> +{
>> +  rtems_timecounter_simple_downcounter_tick(
>> +&_ARMV7M_TC,
>> +_ARMV7M_TC_get,
>> +_ARMV7M_TC_at_tick
>> +  );
>> +}
>> +
>>  static void _ARMV7M_Systick_handler(void)
>>  {
>>_ARMV7M_Interrupt_service_enter();
>> @@ -111,9 +128,6 @@ static void _ARMV7M_Systick_cleanup(void)
>>
>>  #define Clock_driver_timecounter_tick() _ARMV7M_TC_tick()
>>
>> -#define Clock_driver_support_at_tick() \
>> -  _ARMV7M_Systick_at_tick()
>> -
>>  #define Clock_driver_support_initialize_hardware() \
>>_ARMV7M_Systic

Re: Problem with system time in lpc176x bsp

2016-01-11 Thread Joel Sherrill 
On Mon, Jan 11, 2016 at 12:28 PM, Marcos Díaz <
marcos.d...@tallertechnologies.com> wrote:

> I will issue a ticket. But I noticed that in my patch I include changes to
> common code that Sebastian suggested, and this will break any other BSP
> that uses rtems timecounter simple downcounter or upcounter, since these
> function's signatures changed. Should we update all BSPs? Or make changes
> more locally to our BSP?  Meanwhile please do not apply the patch I sent.
>
>
I would prefer not to ship BSPs with bugs but fixing them comes with risks.
So I would lean to the same fix on the master and 4.11 branch fixing it
where it needs to be fixed.

What BSPs does this change impact?

--joel


>
> On Mon, Jan 11, 2016 at 3:16 PM, Joel Sherrill  wrote:
>
>> At this point, a ticket is needed for anything applied to 4.11 that is
>> not release
>> mechanics related.
>>
>> --joel
>>
>> On Mon, Jan 11, 2016 at 11:47 AM, Marcos Diaz <
>> marcos.d...@tallertechnologies.com> wrote:
>>
>>> Hi Sebastian,
>>>
>>> we did some more testing and found out what's causing the problem. Based
>>> on what
>>> I posted at
>>> https://lists.rtems.org/pipermail/devel/2015-December/013235.html,
>>> the problem arises when the ticker interrupt occurs while a task is
>>> executing
>>> one of the instructions that make up the following line:
>>>
>>> is_count_pending = (systick->csr & ARMV7M_SYSTICK_CSR_COUNTFLAG) != 0;
>>>
>>> which compiling with -O3 are:
>>>
>>> ldr.w r3, [r9]
>>> ubfx r5, r3, #16, #1
>>> strb.w r5, [r8, #64]
>>>
>>> If the SysTick counts to 0 and the ldr executes before the interrupt
>>> occurs,
>>> R3 will have the CSR.COUNTFLAG bit set. Even though _ARMV7M_TC_at_tick
>>> will
>>> clear the is_count_pending boolean, the task will still see it as true.
>>>
>>> The solution we found is to simply disable interrupts while reading that
>>> flag.
>>> We also use a local variable inside _ARMV7M_TC_is_pending instead of
>>> directly
>>> returning the current value of the is_count_pending global, just in case.
>>>
>>> Here's the patch that fixes it; this applies to the 4.11 branch.
>>> Do we have to open a new thread for it to be applied to the mainline, or
>>> will
>>> this suffice? Should we open a ticket for 4.11?
>>>
>>> ---
>>>  .../arm/shared/armv7m/clock/armv7m-clock-config.c  | 38
>>> +++---
>>>  c/src/lib/libbsp/shared/clockdrv_shell.h   | 16 -
>>>  cpukit/rtems/src/clocktick.c   |  6 +++-
>>>  cpukit/sapi/include/rtems/timecounter.h| 35
>>> 
>>>  cpukit/score/include/rtems/score/timecounter.h | 37
>>> +++--
>>>  cpukit/score/src/kern_tc.c | 16 -
>>>  doc/bsp_howto/clock.t  | 13 +++-
>>>  7 files changed, 130 insertions(+), 31 deletions(-)
>>>
>>> diff --git
>>> a/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
>>> b/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
>>> index e78684c..53bd7cf 100644
>>> --- a/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
>>> +++ b/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
>>> @@ -25,6 +25,8 @@ static void Clock_isr(void *arg);
>>>
>>>  static rtems_timecounter_simple _ARMV7M_TC;
>>>
>>> +static bool is_count_pending = false;
>>> +
>>>  static uint32_t _ARMV7M_TC_get(rtems_timecounter_simple *tc)
>>>  {
>>>volatile ARMV7M_Systick *systick = _ARMV7M_Systick;
>>> @@ -34,9 +36,20 @@ static uint32_t
>>> _ARMV7M_TC_get(rtems_timecounter_simple *tc)
>>>
>>>  static bool _ARMV7M_TC_is_pending(rtems_timecounter_simple *tc)
>>>  {
>>> -  volatile ARMV7M_SCB *scb = _ARMV7M_SCB;
>>> +  volatile ARMV7M_Systick *systick = _ARMV7M_Systick;
>>> +  ISR_lock_Context lock_context;
>>> +
>>> +  _Timecounter_Acquire( &lock_context );
>>> +  /* We use this bool since the hardware flag is reset each time it is
>>> read. */
>>> +  if (!is_count_pending)
>>> +  {
>>> +is_count_pending = ((systick->csr & ARMV7M_SYSTICK_CSR_COUNTFLAG)
>>> != 0 );
>>> +  }
>>>
>>> -  return ((scb->icsr & ARMV7M_SCB_ICSR_PENDSTSET) != 0);
>>> +  const bool is_pending_local = is_count_pending;
>>> +
>>> +  _Timecounter_Release( &lock_context );
>>> +  return is_pending_local;
>>>  }
>>>
>>>  static uint32_t _ARMV7M_TC_get_timecount(struct timecounter *tc)
>>> @@ -48,19 +61,23 @@ static uint32_t _ARMV7M_TC_get_timecount(struct
>>> timecounter *tc)
>>>);
>>>  }
>>>
>>> -static void _ARMV7M_TC_tick(void)
>>> -{
>>> -  rtems_timecounter_simple_downcounter_tick(&_ARMV7M_TC,
>>> _ARMV7M_TC_get);
>>> -}
>>> -
>>> -static void _ARMV7M_Systick_at_tick(void)
>>> +static void _ARMV7M_TC_at_tick(rtems_timecounter_simple *tc)
>>>  {
>>>volatile ARMV7M_Systick *systick = _ARMV7M_Systick;
>>> -
>>> +  is_count_pending = false;
>>>/* Clear COUNTFLAG */
>>>systick->csr;
>>>  }
>>>
>>> +static void _ARMV7M_TC_tick(void)
>>> +{
>>> +  rtems_timecounter_simple_downcounter_tick(
>>> +&_ARMV7M_TC,

Re: Problem with system time in lpc176x bsp

2016-01-11 Thread Marcos Díaz 
I made a fast search:
These BSPs use *rtems_timecounter_simple_downcounter*:
arm/shared/armv7m
m68k/mcf52235
m68k/mcf5225x
m68k/mcf5329
m68k/uC5282
powerpc/mpc55xxevb
sparc/erc32
sparc/leon2
sparc/leon3
sparc/shared

These use *rtems_timecounter_simple_upcounter*:
powerpc/mpc55xxevb
arm/lpc22xx

We should search a little more for the other changes but at least these
BSPs will be affected. Maybe we should wait Sebastian's opinion, since he
suggested the change in timecounter's signatures.

On Mon, Jan 11, 2016 at 3:44 PM, Joel Sherrill  wrote:

>
>
> On Mon, Jan 11, 2016 at 12:28 PM, Marcos Díaz <
> marcos.d...@tallertechnologies.com> wrote:
>
>> I will issue a ticket. But I noticed that in my patch I include changes
>> to common code that Sebastian suggested, and this will break any other BSP
>> that uses rtems timecounter simple downcounter or upcounter, since these
>> function's signatures changed. Should we update all BSPs? Or make changes
>> more locally to our BSP?  Meanwhile please do not apply the patch I sent.
>>
>>
> I would prefer not to ship BSPs with bugs but fixing them comes with risks.
> So I would lean to the same fix on the master and 4.11 branch fixing it
> where it needs to be fixed.
>
> What BSPs does this change impact?
>
> --joel
>
>
>>
>> On Mon, Jan 11, 2016 at 3:16 PM, Joel Sherrill  wrote:
>>
>>> At this point, a ticket is needed for anything applied to 4.11 that is
>>> not release
>>> mechanics related.
>>>
>>> --joel
>>>
>>> On Mon, Jan 11, 2016 at 11:47 AM, Marcos Diaz <
>>> marcos.d...@tallertechnologies.com> wrote:
>>>
 Hi Sebastian,

 we did some more testing and found out what's causing the problem.
 Based on what
 I posted at
 https://lists.rtems.org/pipermail/devel/2015-December/013235.html,
 the problem arises when the ticker interrupt occurs while a task is
 executing
 one of the instructions that make up the following line:

 is_count_pending = (systick->csr & ARMV7M_SYSTICK_CSR_COUNTFLAG) != 0;

 which compiling with -O3 are:

 ldr.w r3, [r9]
 ubfx r5, r3, #16, #1
 strb.w r5, [r8, #64]

 If the SysTick counts to 0 and the ldr executes before the interrupt
 occurs,
 R3 will have the CSR.COUNTFLAG bit set. Even though _ARMV7M_TC_at_tick
 will
 clear the is_count_pending boolean, the task will still see it as true.

 The solution we found is to simply disable interrupts while reading
 that flag.
 We also use a local variable inside _ARMV7M_TC_is_pending instead of
 directly
 returning the current value of the is_count_pending global, just in
 case.

 Here's the patch that fixes it; this applies to the 4.11 branch.
 Do we have to open a new thread for it to be applied to the mainline,
 or will
 this suffice? Should we open a ticket for 4.11?

 ---
  .../arm/shared/armv7m/clock/armv7m-clock-config.c  | 38
 +++---
  c/src/lib/libbsp/shared/clockdrv_shell.h   | 16 -
  cpukit/rtems/src/clocktick.c   |  6 +++-
  cpukit/sapi/include/rtems/timecounter.h| 35
 
  cpukit/score/include/rtems/score/timecounter.h | 37
 +++--
  cpukit/score/src/kern_tc.c | 16 -
  doc/bsp_howto/clock.t  | 13 +++-
  7 files changed, 130 insertions(+), 31 deletions(-)

 diff --git
 a/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
 b/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
 index e78684c..53bd7cf 100644
 --- a/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
 +++ b/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
 @@ -25,6 +25,8 @@ static void Clock_isr(void *arg);

  static rtems_timecounter_simple _ARMV7M_TC;

 +static bool is_count_pending = false;
 +
  static uint32_t _ARMV7M_TC_get(rtems_timecounter_simple *tc)
  {
volatile ARMV7M_Systick *systick = _ARMV7M_Systick;
 @@ -34,9 +36,20 @@ static uint32_t
 _ARMV7M_TC_get(rtems_timecounter_simple *tc)

  static bool _ARMV7M_TC_is_pending(rtems_timecounter_simple *tc)
  {
 -  volatile ARMV7M_SCB *scb = _ARMV7M_SCB;
 +  volatile ARMV7M_Systick *systick = _ARMV7M_Systick;
 +  ISR_lock_Context lock_context;
 +
 +  _Timecounter_Acquire( &lock_context );
 +  /* We use this bool since the hardware flag is reset each time it is
 read. */
 +  if (!is_count_pending)
 +  {
 +is_count_pending = ((systick->csr & ARMV7M_SYSTICK_CSR_COUNTFLAG)
 != 0 );
 +  }

 -  return ((scb->icsr & ARMV7M_SCB_ICSR_PENDSTSET) != 0);
 +  const bool is_pending_local = is_count_pending;
 +
 +  _Timecounter_Release( &lock_context );
 +  return is_pending_local;
  }

  static uint32_t _ARMV7M_TC_get_

Re: Problem with system time in lpc176x bsp

2016-01-11 Thread Sebastian Huber 
Hello,

I already created a ticket which blocks the 4.11 release for this bug:

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

I sent a new version of the patch to one of your previous threads some days ago:

https://lists.rtems.org/pipermail/devel/2016-January/013289.html

There is still a bug in it, since we must disable interrupts in the is pending 
function, but the general approach should work.

- Am 11. Jan 2016 um 20:05 schrieb Marcos Díaz 
marcos.d...@tallertechnologies.com:

> I made a fast search:
> These BSPs use *rtems_timecounter_simple_downcounter*:
> arm/shared/armv7m
> m68k/mcf52235
> m68k/mcf5225x
> m68k/mcf5329
> m68k/uC5282
> powerpc/mpc55xxevb
> sparc/erc32
> sparc/leon2
> sparc/leon3
> sparc/shared
> 
> These use *rtems_timecounter_simple_upcounter*:
> powerpc/mpc55xxevb
> arm/lpc22xx
> 
> We should search a little more for the other changes but at least these
> BSPs will be affected. Maybe we should wait Sebastian's opinion, since he
> suggested the change in timecounter's signatures.
> 
> On Mon, Jan 11, 2016 at 3:44 PM, Joel Sherrill  wrote:
> 
>>
>>
>> On Mon, Jan 11, 2016 at 12:28 PM, Marcos Díaz <
>> marcos.d...@tallertechnologies.com> wrote:
>>
>>> I will issue a ticket. But I noticed that in my patch I include changes
>>> to common code that Sebastian suggested, and this will break any other BSP
>>> that uses rtems timecounter simple downcounter or upcounter, since these
>>> function's signatures changed. Should we update all BSPs? Or make changes
>>> more locally to our BSP?  Meanwhile please do not apply the patch I sent.
>>>
>>>
>> I would prefer not to ship BSPs with bugs but fixing them comes with risks.
>> So I would lean to the same fix on the master and 4.11 branch fixing it
>> where it needs to be fixed.
>>
>> What BSPs does this change impact?
>>
>> --joel
>>
>>
>>>
>>> On Mon, Jan 11, 2016 at 3:16 PM, Joel Sherrill  wrote:
>>>
 At this point, a ticket is needed for anything applied to 4.11 that is
 not release
 mechanics related.

 --joel

 On Mon, Jan 11, 2016 at 11:47 AM, Marcos Diaz <
 marcos.d...@tallertechnologies.com> wrote:

> Hi Sebastian,
>
> we did some more testing and found out what's causing the problem.
> Based on what
> I posted at
> https://lists.rtems.org/pipermail/devel/2015-December/013235.html,
> the problem arises when the ticker interrupt occurs while a task is
> executing
> one of the instructions that make up the following line:
>
> is_count_pending = (systick->csr & ARMV7M_SYSTICK_CSR_COUNTFLAG) != 0;
>
> which compiling with -O3 are:
>
> ldr.w r3, [r9]
> ubfx r5, r3, #16, #1
> strb.w r5, [r8, #64]
>
> If the SysTick counts to 0 and the ldr executes before the interrupt
> occurs,
> R3 will have the CSR.COUNTFLAG bit set. Even though _ARMV7M_TC_at_tick
> will
> clear the is_count_pending boolean, the task will still see it as true.
>
> The solution we found is to simply disable interrupts while reading
> that flag.
> We also use a local variable inside _ARMV7M_TC_is_pending instead of
> directly
> returning the current value of the is_count_pending global, just in
> case.
>
> Here's the patch that fixes it; this applies to the 4.11 branch.
> Do we have to open a new thread for it to be applied to the mainline,
> or will
> this suffice? Should we open a ticket for 4.11?
>
> ---
>  .../arm/shared/armv7m/clock/armv7m-clock-config.c  | 38
> +++---
>  c/src/lib/libbsp/shared/clockdrv_shell.h   | 16 -
>  cpukit/rtems/src/clocktick.c   |  6 +++-
>  cpukit/sapi/include/rtems/timecounter.h| 35
> 
>  cpukit/score/include/rtems/score/timecounter.h | 37
> +++--
>  cpukit/score/src/kern_tc.c | 16 -
>  doc/bsp_howto/clock.t  | 13 +++-
>  7 files changed, 130 insertions(+), 31 deletions(-)
>
> diff --git
> a/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
> b/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
> index e78684c..53bd7cf 100644
> --- a/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
> +++ b/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
> @@ -25,6 +25,8 @@ static void Clock_isr(void *arg);
>
>  static rtems_timecounter_simple _ARMV7M_TC;
>
> +static bool is_count_pending = false;
> +
>  static uint32_t _ARMV7M_TC_get(rtems_timecounter_simple *tc)
>  {
>volatile ARMV7M_Systick *systick = _ARMV7M_Systick;
> @@ -34,9 +36,20 @@ static uint32_t
> _ARMV7M_TC_get(rtems_timecounter_simple *tc)
>
>  static bool _ARMV7M_TC_is_pending(rtems_timecounter_simple *tc)
>  {
> -  volatile ARMV7M_SCB *scb = _ARMV7M_SCB;
> +  vola

Re: Problem with system time in lpc176x bsp

2016-01-11 Thread Marcos Díaz 
Well, we could still use the patch you sent with the protection in is
pending, but I think this will break the BSPs I mentioned, since you
changed timecounter functions signatures. Am I right?

On Mon, Jan 11, 2016 at 4:18 PM, Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> I already created a ticket which blocks the 4.11 release for this bug:
>
> https://devel.rtems.org/ticket/2502
>
> I sent a new version of the patch to one of your previous threads some
> days ago:
>
> https://lists.rtems.org/pipermail/devel/2016-January/013289.html
>
> There is still a bug in it, since we must disable interrupts in the is
> pending function, but the general approach should work.
>
> - Am 11. Jan 2016 um 20:05 schrieb Marcos Díaz
> marcos.d...@tallertechnologies.com:
>
> > I made a fast search:
> > These BSPs use *rtems_timecounter_simple_downcounter*:
> > arm/shared/armv7m
> > m68k/mcf52235
> > m68k/mcf5225x
> > m68k/mcf5329
> > m68k/uC5282
> > powerpc/mpc55xxevb
> > sparc/erc32
> > sparc/leon2
> > sparc/leon3
> > sparc/shared
> >
> > These use *rtems_timecounter_simple_upcounter*:
> > powerpc/mpc55xxevb
> > arm/lpc22xx
> >
> > We should search a little more for the other changes but at least these
> > BSPs will be affected. Maybe we should wait Sebastian's opinion, since he
> > suggested the change in timecounter's signatures.
> >
> > On Mon, Jan 11, 2016 at 3:44 PM, Joel Sherrill  wrote:
> >
> >>
> >>
> >> On Mon, Jan 11, 2016 at 12:28 PM, Marcos Díaz <
> >> marcos.d...@tallertechnologies.com> wrote:
> >>
> >>> I will issue a ticket. But I noticed that in my patch I include changes
> >>> to common code that Sebastian suggested, and this will break any other
> BSP
> >>> that uses rtems timecounter simple downcounter or upcounter, since
> these
> >>> function's signatures changed. Should we update all BSPs? Or make
> changes
> >>> more locally to our BSP?  Meanwhile please do not apply the patch I
> sent.
> >>>
> >>>
> >> I would prefer not to ship BSPs with bugs but fixing them comes with
> risks.
> >> So I would lean to the same fix on the master and 4.11 branch fixing it
> >> where it needs to be fixed.
> >>
> >> What BSPs does this change impact?
> >>
> >> --joel
> >>
> >>
> >>>
> >>> On Mon, Jan 11, 2016 at 3:16 PM, Joel Sherrill  wrote:
> >>>
>  At this point, a ticket is needed for anything applied to 4.11 that is
>  not release
>  mechanics related.
> 
>  --joel
> 
>  On Mon, Jan 11, 2016 at 11:47 AM, Marcos Diaz <
>  marcos.d...@tallertechnologies.com> wrote:
> 
> > Hi Sebastian,
> >
> > we did some more testing and found out what's causing the problem.
> > Based on what
> > I posted at
> > https://lists.rtems.org/pipermail/devel/2015-December/013235.html,
> > the problem arises when the ticker interrupt occurs while a task is
> > executing
> > one of the instructions that make up the following line:
> >
> > is_count_pending = (systick->csr & ARMV7M_SYSTICK_CSR_COUNTFLAG) !=
> 0;
> >
> > which compiling with -O3 are:
> >
> > ldr.w r3, [r9]
> > ubfx r5, r3, #16, #1
> > strb.w r5, [r8, #64]
> >
> > If the SysTick counts to 0 and the ldr executes before the interrupt
> > occurs,
> > R3 will have the CSR.COUNTFLAG bit set. Even though
> _ARMV7M_TC_at_tick
> > will
> > clear the is_count_pending boolean, the task will still see it as
> true.
> >
> > The solution we found is to simply disable interrupts while reading
> > that flag.
> > We also use a local variable inside _ARMV7M_TC_is_pending instead of
> > directly
> > returning the current value of the is_count_pending global, just in
> > case.
> >
> > Here's the patch that fixes it; this applies to the 4.11 branch.
> > Do we have to open a new thread for it to be applied to the mainline,
> > or will
> > this suffice? Should we open a ticket for 4.11?
> >
> > ---
> >  .../arm/shared/armv7m/clock/armv7m-clock-config.c  | 38
> > +++---
> >  c/src/lib/libbsp/shared/clockdrv_shell.h   | 16 -
> >  cpukit/rtems/src/clocktick.c   |  6 +++-
> >  cpukit/sapi/include/rtems/timecounter.h| 35
> > 
> >  cpukit/score/include/rtems/score/timecounter.h | 37
> > +++--
> >  cpukit/score/src/kern_tc.c | 16 -
> >  doc/bsp_howto/clock.t  | 13 +++-
> >  7 files changed, 130 insertions(+), 31 deletions(-)
> >
> > diff --git
> > a/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
> > b/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
> > index e78684c..53bd7cf 100644
> > --- a/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
> > +++ b/c/src/lib/libbsp/arm/shared/armv7m/clock/armv7m-clock-config.c
> >>

Re: Problem with system time in lpc176x bsp

2016-01-11 Thread Joel Sherrill 
On Mon, Jan 11, 2016 at 1:25 PM, Marcos Díaz <
marcos.d...@tallertechnologies.com> wrote:

> Well, we could still use the patch you sent with the protection in is
> pending, but I think this will break the BSPs I mentioned, since you
> changed timecounter functions signatures. Am I right?
>
>
Let's just fix it right. The timecounters are new so getting them right in
the first release with
them is important.


> On Mon, Jan 11, 2016 at 4:18 PM, Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> Hello,
>>
>> I already created a ticket which blocks the 4.11 release for this bug:
>>
>> https://devel.rtems.org/ticket/2502
>>
>> I sent a new version of the patch to one of your previous threads some
>> days ago:
>>
>> https://lists.rtems.org/pipermail/devel/2016-January/013289.html
>>
>> There is still a bug in it, since we must disable interrupts in the is
>> pending function, but the general approach should work.
>>
>> - Am 11. Jan 2016 um 20:05 schrieb Marcos Díaz
>> marcos.d...@tallertechnologies.com:
>>
>> > I made a fast search:
>> > These BSPs use *rtems_timecounter_simple_downcounter*:
>> > arm/shared/armv7m
>> > m68k/mcf52235
>> > m68k/mcf5225x
>> > m68k/mcf5329
>> > m68k/uC5282
>> > powerpc/mpc55xxevb
>> > sparc/erc32
>> > sparc/leon2
>> > sparc/leon3
>> > sparc/shared
>> >
>> > These use *rtems_timecounter_simple_upcounter*:
>> > powerpc/mpc55xxevb
>> > arm/lpc22xx
>> >
>> > We should search a little more for the other changes but at least these
>> > BSPs will be affected. Maybe we should wait Sebastian's opinion, since
>> he
>> > suggested the change in timecounter's signatures.
>> >
>> > On Mon, Jan 11, 2016 at 3:44 PM, Joel Sherrill  wrote:
>> >
>> >>
>> >>
>> >> On Mon, Jan 11, 2016 at 12:28 PM, Marcos Díaz <
>> >> marcos.d...@tallertechnologies.com> wrote:
>> >>
>> >>> I will issue a ticket. But I noticed that in my patch I include
>> changes
>> >>> to common code that Sebastian suggested, and this will break any
>> other BSP
>> >>> that uses rtems timecounter simple downcounter or upcounter, since
>> these
>> >>> function's signatures changed. Should we update all BSPs? Or make
>> changes
>> >>> more locally to our BSP?  Meanwhile please do not apply the patch I
>> sent.
>> >>>
>> >>>
>> >> I would prefer not to ship BSPs with bugs but fixing them comes with
>> risks.
>> >> So I would lean to the same fix on the master and 4.11 branch fixing it
>> >> where it needs to be fixed.
>> >>
>> >> What BSPs does this change impact?
>> >>
>> >> --joel
>> >>
>> >>
>> >>>
>> >>> On Mon, Jan 11, 2016 at 3:16 PM, Joel Sherrill 
>> wrote:
>> >>>
>>  At this point, a ticket is needed for anything applied to 4.11 that
>> is
>>  not release
>>  mechanics related.
>> 
>>  --joel
>> 
>>  On Mon, Jan 11, 2016 at 11:47 AM, Marcos Diaz <
>>  marcos.d...@tallertechnologies.com> wrote:
>> 
>> > Hi Sebastian,
>> >
>> > we did some more testing and found out what's causing the problem.
>> > Based on what
>> > I posted at
>> > https://lists.rtems.org/pipermail/devel/2015-December/013235.html,
>> > the problem arises when the ticker interrupt occurs while a task is
>> > executing
>> > one of the instructions that make up the following line:
>> >
>> > is_count_pending = (systick->csr & ARMV7M_SYSTICK_CSR_COUNTFLAG) !=
>> 0;
>> >
>> > which compiling with -O3 are:
>> >
>> > ldr.w r3, [r9]
>> > ubfx r5, r3, #16, #1
>> > strb.w r5, [r8, #64]
>> >
>> > If the SysTick counts to 0 and the ldr executes before the interrupt
>> > occurs,
>> > R3 will have the CSR.COUNTFLAG bit set. Even though
>> _ARMV7M_TC_at_tick
>> > will
>> > clear the is_count_pending boolean, the task will still see it as
>> true.
>> >
>> > The solution we found is to simply disable interrupts while reading
>> > that flag.
>> > We also use a local variable inside _ARMV7M_TC_is_pending instead of
>> > directly
>> > returning the current value of the is_count_pending global, just in
>> > case.
>> >
>> > Here's the patch that fixes it; this applies to the 4.11 branch.
>> > Do we have to open a new thread for it to be applied to the
>> mainline,
>> > or will
>> > this suffice? Should we open a ticket for 4.11?
>> >
>> > ---
>> >  .../arm/shared/armv7m/clock/armv7m-clock-config.c  | 38
>> > +++---
>> >  c/src/lib/libbsp/shared/clockdrv_shell.h   | 16 -
>> >  cpukit/rtems/src/clocktick.c   |  6 +++-
>> >  cpukit/sapi/include/rtems/timecounter.h| 35
>> > 
>> >  cpukit/score/include/rtems/score/timecounter.h | 37
>> > +++--
>> >  cpukit/score/src/kern_tc.c | 16 -
>> >  doc/bsp_howto/clock.t  | 13 +++-
>> >  7 files changed, 130 insertions(+), 31 deletions(-)
>

Re: Rtems-test cortex-m3

2016-01-11 Thread Aurelio Remonda 
On Mon, Jan 11, 2016 at 3:47 AM, Sebastian Huber
 wrote:
>
>
> On 08/01/16 17:41, Aurelio Remonda wrote:
>>
>> Thanks for your answers! I am running the tests for
>> realview_pbx_a9_qemu for the moment.
>> I have a few questions if you don't mind
>>
>> With the git repository version of rtems
>> ./rtems-test --log=realview_pbx_a9_qemu
>> --rtems-bsp=realview_pbx_a9_qemu
>> --rtems-tools=/home/aurelio-remonda/rtems_a9/install
>>
>> /home/aurelio-remonda/rtems_a9/build/arm-rtems4.11/c/realview_pbx_a9_qemu/testsuites/
>>
>> The result is:
>>
>> Passed:   523
>> Failed: 4
>> Timeouts:   6
>> Invalid:0
>> -
>> Total:533
>>
>> Failures:
>>   sp69.exe
>>   psxcleanup02.exe
>>   sptimecounter02.exe
>>   psxcancel.exe
>> Timeouts:
>>   psxintrcritical01.exe
>>   spintrcritical11.exe
>>   spintrcritical07.exe
>>   spintrcritical12.exe
>>   spintrcritical06.exe
>>   spintrcritical15.exe
>> Average test time: 0:00:01.244372
>> Testing time : 0:11:03.250308
>>
>> Are those expected fails?
>
>
> Yes, one issue is that timing related tests work bad on Qemu.
>

So, those test never actually pass with qemu emulation?

>>
>> On the other hand:
>> When i try to run with the version of rtems we use:
>> ./rtems-test --log=realview_pbx_a9_qemu
>> --rtems-bsp=realview_pbx_a9_qemu
>> --rtems-tools=/home/aurelio-remonda/rtems_gnc/install
>>
>> /home/aurelio-remonda/rtems_gnc/build/arm-rtems4.11/c/realview_pbx_a9_qemu/testsuites/
>>
>> I get:
>> error: unknown application load error.
>> Any hints of what is the problem?
>>
>>
>
> I would run Qemu in the debugger to figure out the exact error.
>

This is previous to qemu emulation, i found out i was using the last
rtems-test when it failed. So i start looking the last commits on
rtems-test and found out that on:
https://git.rtems.org/rtems-tools/commit/?id=606c08c8b521dce0121cddcabcc23f3e25ad2ffd

On this particular piece of code of that patch:
diff --git a/rtemstoolkit/version.py b/rtemstoolkit/version.py
index 542a8e0..3c135b1 100644
--- a/rtemstoolkit/version.py
+++ b/rtemstoolkit/version.py
@@ -35,9 +35,8 @@
import sys
-import error
-import git
-import path
+from . import error
+from . import path

import git was deleted. Is this a mistake? I try adding the line and
the script runs propertly.
Please let me know if im wrong. Thank you in advance.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel