Re: [PATCH 27/27] score: Restrict affinity for EDF SMP scheduler

2021-11-20 Thread Gedare Bloom
ok other than my comments. nothing looked major.

On Mon, Nov 15, 2021 at 10:14 AM Sebastian Huber
 wrote:
>
> The SMP EDF scheduler supports a one-to-one and one-to-all thread to
> processor affinity. It accepted affinity sets which are a proper
> subset of the online processor containing at least two processors owned by
> the scheduler. In this case it used a one-to-one thread to processor
> affinity. This leads to undefined behaviour if a processor is removed
> since the higher level check in rtems_scheduler_remove_processor() does
> not account for this implementation detail.
>
> Restrict the affinity set accepted by the SMP EDF scheduler to
>
> 1. all online processors, or
>
> 2. exactly one processor owned by the scheduler.
>
> Close #4545.
> ---
>  cpukit/score/src/scheduleredfsmp.c | 30 --
>  1 file changed, 24 insertions(+), 6 deletions(-)
>
> diff --git a/cpukit/score/src/scheduleredfsmp.c 
> b/cpukit/score/src/scheduleredfsmp.c
> index 93c3c126f7..96b530e912 100644
> --- a/cpukit/score/src/scheduleredfsmp.c
> +++ b/cpukit/score/src/scheduleredfsmp.c
> @@ -885,20 +885,38 @@ Status_Control _Scheduler_EDF_SMP_Set_affinity(
>  {
>Scheduler_Context  *context;
>Scheduler_EDF_SMP_Node *node;
> -  Processor_mask  local_affinity;
>uint8_t rqi;
>
>context = _Scheduler_Get_context( scheduler );
> -  _Processor_mask_And( _affinity, >Processors, affinity );
>
> -  if ( _Processor_mask_Is_zero( _affinity ) ) {
> -return STATUS_INVALID_NUMBER;
> -  }
> +  /*
> +   * We support a thread to processor affinity to all online processors and 
> an
> +   * affinity to exactly one processor owned by the scheduler.  This
> +   * restriction is necessary to avoid issues if processors are added or
> +   * removed to or from the scheduler.
> +   */
>
>if ( _Processor_mask_Is_equal( affinity, &_SMP_Online_processors ) ) {
>  rqi = 0;
>} else {
> -rqi = _Processor_mask_Find_last_set( _affinity );
> +Processor_mask local_affinity;
> +Processor_mask only_last_affinity;
> +uint32_t   last;
> +
> +_Processor_mask_And( _affinity, >Processors, affinity );
> +
> +if ( _Processor_mask_Is_zero( _affinity ) ) {
> +  return STATUS_INVALID_NUMBER;
> +}
> +
> +last = _Processor_mask_Find_last_set( _affinity );
> +_Processor_mask_From_index( _last_affinity, last - 1 );
> +
> +if ( !_Processor_mask_Is_equal( _affinity, _last_affinity ) ) 
> {
> +  return STATUS_INVALID_NUMBER;
> +}
> +
> +rqi = last;
>}
>
>node = _Scheduler_EDF_SMP_Node_downcast( node_base );
> --
> 2.26.2
>
> ___
> 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 15/27] score: Add SMP scheduler make/clean sticky

2021-11-20 Thread Gedare Bloom
On Mon, Nov 15, 2021 at 10:13 AM Sebastian Huber
 wrote:
>
> This patch fixes the following broken behaviour:
>
>   While a thread is scheduled on a helping scheduler, while it does not
>   own a MrsP semaphore, if it obtains a MrsP semaphore, then no
>   scheduler node using an idle thread and the ceiling priority of the
>   semaphore is unblocked for the home scheduler.
>
> This could lead to priority inversion issues and is not in line
> with the MrsP protocol.
>
> Introduce two new scheduler operations which are only enabled if
> RTEMS_SMP is defined.  The operations are used to make the scheduler
> node of the home scheduler sticky and to clean the sticky property.
> This helps to keep the sticky handing out of the frequently used
> priority update operation.
>
> Close #4532.
> ---
>  cpukit/include/rtems/score/mrspimpl.h |  19 ++-
>  cpukit/include/rtems/score/scheduler.h|  54 +++
>  cpukit/include/rtems/score/scheduleredfsmp.h  |  32 +
>  cpukit/include/rtems/score/schedulerimpl.h|  59 
>  .../score/schedulerpriorityaffinitysmp.h  |  32 +
>  .../rtems/score/schedulerprioritysmp.h|  32 +
>  .../include/rtems/score/schedulersimplesmp.h  |  32 +
>  cpukit/include/rtems/score/schedulersmpimpl.h |  84 +++
>  .../include/rtems/score/schedulerstrongapa.h  |  62 
>  cpukit/include/rtems/score/threadimpl.h   |  28 ++--
>  .../src/schedulerdefaultmakecleansticky.c |  52 +++
>  cpukit/score/src/scheduleredfsmp.c|  36 -
>  .../score/src/schedulerpriorityaffinitysmp.c  |  39 +-
>  cpukit/score/src/schedulerprioritysmp.c   |  37 -
>  cpukit/score/src/schedulersimplesmp.c |  37 -
>  cpukit/score/src/schedulerstrongapa.c |  37 -
>  cpukit/score/src/threadchangepriority.c   | 132 +-
>  cpukit/score/src/threadqenqueue.c |   6 +-
>  spec/build/cpukit/objsmp.yml  |   1 +
>  19 files changed, 720 insertions(+), 91 deletions(-)
>  create mode 100644 cpukit/score/src/schedulerdefaultmakecleansticky.c
>
> diff --git a/cpukit/include/rtems/score/mrspimpl.h 
> b/cpukit/include/rtems/score/mrspimpl.h
> index 3e64ad94e6..444586b4ab 100644
> --- a/cpukit/include/rtems/score/mrspimpl.h
> +++ b/cpukit/include/rtems/score/mrspimpl.h
> @@ -268,7 +268,7 @@ RTEMS_INLINE_ROUTINE Status_Control _MRSP_Claim_ownership(
>_MRSP_Set_owner( mrsp, executing );
>cpu_self = _Thread_queue_Dispatch_disable( queue_context );
>_MRSP_Release( mrsp, queue_context );
> -  _Thread_Priority_and_sticky_update( executing, 1 );
> +  _Thread_Priority_update_and_make_sticky( executing );
>_Thread_Dispatch_enable( cpu_self );
>return STATUS_SUCCESSFUL;
>  }
> @@ -384,13 +384,6 @@ RTEMS_INLINE_ROUTINE Status_Control 
> _MRSP_Wait_for_ownership(
>  _MRSP_Replace_priority( mrsp, executing, _priority );
>} else {
>  Per_CPU_Control *cpu_self;
> -int  sticky_level_change;
> -
> -if ( status != STATUS_DEADLOCK ) {
> -  sticky_level_change = -1;
> -} else {
> -  sticky_level_change = 0;
> -}
>
>  _ISR_lock_ISR_disable( _context->Lock_context.Lock_context );
>  _MRSP_Remove_priority( executing, _priority, queue_context );
> @@ -398,7 +391,13 @@ RTEMS_INLINE_ROUTINE Status_Control 
> _MRSP_Wait_for_ownership(
>_context->Lock_context.Lock_context
>  );
>  _ISR_lock_ISR_enable( _context->Lock_context.Lock_context );
> -_Thread_Priority_and_sticky_update( executing, sticky_level_change );
> +
> +if ( status != STATUS_DEADLOCK ) {
> +  _Thread_Priority_update_and_clean_sticky( executing );
> +} else {
> +  _Thread_Priority_update_only( executing );
> +}
> +
>  _Thread_Dispatch_enable( cpu_self );
>}
>
> @@ -493,7 +492,7 @@ RTEMS_INLINE_ROUTINE Status_Control _MRSP_Surrender(
>_context->Lock_context.Lock_context
>  );
>  _MRSP_Release( mrsp, queue_context );
> -_Thread_Priority_and_sticky_update( executing, -1 );
> +_Thread_Priority_update_and_clean_sticky( executing );
>  _Thread_Dispatch_enable( cpu_self );
>  return STATUS_SUCCESSFUL;
>}
> diff --git a/cpukit/include/rtems/score/scheduler.h 
> b/cpukit/include/rtems/score/scheduler.h
> index ad9d630023..2fd1fc567a 100644
> --- a/cpukit/include/rtems/score/scheduler.h
> +++ b/cpukit/include/rtems/score/scheduler.h
> @@ -134,6 +134,40 @@ typedef struct {
>  Thread_Scheduler_state   next_state
>);
>
> +  /**
> +   * @brief Makes the node sticky.
> +   *
> +   * This operation is used by _Thread_Priority_update_and_make_sticky().
> +   *

i think the "sticky" property needs more documentation now as it is
mandatory to implement in SMP schedulers (even if they all share the
same).

[...]

> diff --git a/cpukit/include/rtems/score/schedulersmpimpl.h 
> b/cpukit/include/rtems/score/schedulersmpimpl.h
> index 54ed976e85..68ae3718a0 100644
> --- 

Re: [PATCH 14/27] score: Add SMP scheduler idle exchange callback

2021-11-20 Thread Gedare Bloom
On Mon, Nov 15, 2021 at 10:14 AM Sebastian Huber
 wrote:
>
> Update #4531.
> ---
>  cpukit/include/rtems/score/schedulersmpimpl.h | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/cpukit/include/rtems/score/schedulersmpimpl.h 
> b/cpukit/include/rtems/score/schedulersmpimpl.h
> index 499cff5c6c..54ed976e85 100644
> --- a/cpukit/include/rtems/score/schedulersmpimpl.h
> +++ b/cpukit/include/rtems/score/schedulersmpimpl.h
> @@ -847,6 +847,7 @@ static inline void _Scheduler_SMP_Enqueue_to_scheduled(
>  ( *insert_scheduled )( context, node, priority );
>
>  _Scheduler_Exchange_idle_thread( node, lowest_scheduled );
> +( *allocate_processor )( context, node, lowest_scheduled, 
> _Thread_Get_CPU( _Scheduler_Node_get_user( node ) ) );

style: line length

>} else {
>  _Assert( action == SCHEDULER_TRY_TO_SCHEDULE_DO_BLOCK );
>  _Scheduler_SMP_Node_change_state( node, SCHEDULER_SMP_NODE_BLOCKED );
> @@ -1021,6 +1022,7 @@ static inline void _Scheduler_SMP_Enqueue_scheduled(
>( *insert_ready )( context, node, insert_priority );
>
>_Scheduler_Exchange_idle_thread( highest_ready, node );
> +  ( *allocate_processor )( context, highest_ready, node, 
> _Thread_Get_CPU( _Scheduler_Node_get_user( highest_ready ) ) );
>return;
>  } else {
>_Assert( action == SCHEDULER_TRY_TO_SCHEDULE_DO_BLOCK );
> @@ -,6 +1113,7 @@ static inline void 
> _Scheduler_SMP_Schedule_highest_ready(
>( *move_from_ready_to_scheduled )( context, highest_ready );
>
>_Scheduler_Exchange_idle_thread( highest_ready, victim );
> +  ( *allocate_processor )( context, highest_ready, victim, 
> _Thread_Get_CPU( _Scheduler_Node_get_user( highest_ready ) ) );
>  } else {
>_Assert( action == SCHEDULER_TRY_TO_SCHEDULE_DO_BLOCK );
>
> @@ -1184,6 +1187,7 @@ static inline void 
> _Scheduler_SMP_Preempt_and_schedule_highest_ready(
>( *move_from_ready_to_scheduled )( context, highest_ready );
>
>_Scheduler_Exchange_idle_thread( highest_ready, victim );
> +  ( *allocate_processor )( context, highest_ready, victim, 
> _Thread_Get_CPU( _Scheduler_Node_get_user( highest_ready ) ) );
>  } else {
>_Assert( action == SCHEDULER_TRY_TO_SCHEDULE_DO_BLOCK );
>
> --
> 2.26.2
>
> ___
> 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 13/27] score: Optimize SMP EDF move to ready operation

2021-11-20 Thread Gedare Bloom
On Mon, Nov 15, 2021 at 10:13 AM Sebastian Huber
 wrote:
>
> If a node is moved from the scheduled chain to the ready queue, then we
> know that it is the highest priority ready node.  So, it can be
> prepended to the ready queue without doing any comparisons.
>
I'm not certain on the logic here. It is possible for 2 threads X and
Y become ready simultaneously, such that:

X is higher priority than Y. X and Y are higher priority than Z. X
gets scheduled to replace Z, but there is no lower-priority/affine CPU
for Y to get scheduled, so Y will be ready. Then Z is not
higher-priority than Y so it shouldn't be directly prepended.

I think that could happen?

> Update #4531.
> ---
>  cpukit/score/src/scheduleredfsmp.c | 20 +---
>  1 file changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/cpukit/score/src/scheduleredfsmp.c 
> b/cpukit/score/src/scheduleredfsmp.c
> index 7da777e87a..27be08ac40 100644
> --- a/cpukit/score/src/scheduleredfsmp.c
> +++ b/cpukit/score/src/scheduleredfsmp.c
> @@ -374,15 +374,21 @@ static inline void 
> _Scheduler_EDF_SMP_Move_from_scheduled_to_ready(
>Scheduler_Node*scheduled_to_ready
>  )
>  {
> -  Priority_Control insert_priority;
> +  Scheduler_EDF_SMP_Context *self;
> +  Scheduler_EDF_SMP_Node*node;
> +  uint8_trqi;
> +  Scheduler_EDF_SMP_Ready_queue *ready_queue;
>
>_Scheduler_EDF_SMP_Extract_from_scheduled( context, scheduled_to_ready );
> -  insert_priority = _Scheduler_SMP_Node_priority( scheduled_to_ready );
> -  _Scheduler_EDF_SMP_Insert_ready(
> -context,
> -scheduled_to_ready,
> -insert_priority
> -  );
> +
> +  self = _Scheduler_EDF_SMP_Get_self( context );
> +  node = _Scheduler_EDF_SMP_Node_downcast( scheduled_to_ready );
> +  rqi = node->ready_queue_index;
> +  ready_queue = >Ready[ rqi ];
> +
> +  _Scheduler_EDF_SMP_Activate_ready_queue_if_necessary( self, rqi, 
> ready_queue );
> +  _RBTree_Initialize_node( >Base.Base.Node.RBTree );
> +  _RBTree_Prepend( _queue->Queue, >Base.Base.Node.RBTree );
>  }
>
>  static inline void _Scheduler_EDF_SMP_Move_from_ready_to_scheduled(
> --
> 2.26.2
>
> ___
> 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 12/27] score: Rework affine ready queue handling

2021-11-20 Thread Gedare Bloom
On Mon, Nov 15, 2021 at 10:13 AM Sebastian Huber
 wrote:
>
> Rework the handling of the affine ready queue for the EDF SMP scheduler.
> Do the queue handling in the node insert, move, and extract operations.
> Remove the queue handling from _Scheduler_EDF_SMP_Allocate_processor().
>
> Update #4531.
> ---
>  cpukit/include/rtems/score/scheduleredfsmp.h |  13 ++-
>  cpukit/score/src/scheduleredfsmp.c   | 106 ---
>  2 files changed, 77 insertions(+), 42 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/scheduleredfsmp.h 
> b/cpukit/include/rtems/score/scheduleredfsmp.h
> index 85e438e81d..e749b3d419 100644
> --- a/cpukit/include/rtems/score/scheduleredfsmp.h
> +++ b/cpukit/include/rtems/score/scheduleredfsmp.h
> @@ -79,9 +79,18 @@ typedef struct {
>RBTree_Control Queue;
>
>/**
> -   * @brief The scheduled thread of the corresponding processor.
> +   * @brief If this member is not NULL, then it references the scheduled 
> thread
> +   *   affine only to the corresponding processor, otherwise the processor is
> +   *   allocated to a thread which may execute on any of the processors owned
> +   *   by the scheduler.
> */
> -  Scheduler_EDF_SMP_Node *scheduled;
> +  Scheduler_EDF_SMP_Node *affine_scheduled;
> +
> +  /**
> +   * @brief This member referneces the thread allocated to the corresponding
typo: references

> +   *   processor.
> +   */
> +  Scheduler_EDF_SMP_Node *allocated;
>  } Scheduler_EDF_SMP_Ready_queue;
>
>  typedef struct {
> diff --git a/cpukit/score/src/scheduleredfsmp.c 
> b/cpukit/score/src/scheduleredfsmp.c
> index a915dbe511..7da777e87a 100644
> --- a/cpukit/score/src/scheduleredfsmp.c
> +++ b/cpukit/score/src/scheduleredfsmp.c
> @@ -196,21 +196,21 @@ static inline Scheduler_Node 
> *_Scheduler_EDF_SMP_Get_highest_ready(
>return _ready->Base.Base;
>  }
>
> -static inline void _Scheduler_EDF_SMP_Set_scheduled(
> +static inline void _Scheduler_EDF_SMP_Set_allocated(
>Scheduler_EDF_SMP_Context *self,
> -  Scheduler_EDF_SMP_Node*scheduled,
> +  Scheduler_EDF_SMP_Node*allocated,
>const Per_CPU_Control *cpu
>  )
>  {
> -  self->Ready[ _Per_CPU_Get_index( cpu ) + 1 ].scheduled = scheduled;
> +  self->Ready[ _Per_CPU_Get_index( cpu ) + 1 ].allocated = allocated;
>  }
>
> -static inline Scheduler_EDF_SMP_Node *_Scheduler_EDF_SMP_Get_scheduled(
> +static inline Scheduler_EDF_SMP_Node *_Scheduler_EDF_SMP_Get_allocated(
>const Scheduler_EDF_SMP_Context *self,
>uint8_t  rqi
>  )
>  {
> -  return self->Ready[ rqi ].scheduled;
> +  return self->Ready[ rqi ].allocated;
>  }
>
>  static inline Scheduler_Node *_Scheduler_EDF_SMP_Get_lowest_scheduled(
> @@ -226,20 +226,62 @@ static inline Scheduler_Node 
> *_Scheduler_EDF_SMP_Get_lowest_scheduled(
>
>if ( rqi != 0 ) {
>  Scheduler_EDF_SMP_Context *self;
> -Scheduler_EDF_SMP_Node*node;
> +Scheduler_EDF_SMP_Node*affine_scheduled;
>
>  self = _Scheduler_EDF_SMP_Get_self( context );
> -node = _Scheduler_EDF_SMP_Get_scheduled( self, rqi );
> +affine_scheduled = self->Ready[ rqi ].affine_scheduled;
>
> -if ( node->ready_queue_index > 0 ) {
> -  _Assert( node->ready_queue_index == rqi );
> -  return >Base.Base;
> +if ( affine_scheduled != NULL ) {
> +  _Assert( affine_scheduled->ready_queue_index == rqi );
> +  return _scheduled->Base.Base;
>  }
>}
>
>return _Scheduler_SMP_Get_lowest_scheduled( context, filter_base );
>  }
>
> +static inline void _Scheduler_EDF_SMP_Insert_scheduled(
> +  Scheduler_Context *context,
> +  Scheduler_Node*node_base,
> +  Priority_Control   priority_to_insert
> +)
> +{
> +  Scheduler_EDF_SMP_Context *self;
> +  Scheduler_EDF_SMP_Node*node;
> +  uint8_trqi;
> +  Scheduler_EDF_SMP_Ready_queue *ready_queue;
> +
> +  self = _Scheduler_EDF_SMP_Get_self( context );
> +  node = _Scheduler_EDF_SMP_Node_downcast( node_base );
> +  rqi = node->ready_queue_index;
> +  ready_queue = >Ready[ rqi ];
> +
> +  _Scheduler_SMP_Insert_scheduled( context, node_base, priority_to_insert );
> +
> +  if ( rqi != 0 ) {
> +ready_queue->affine_scheduled = node;
> +
> +if ( !_RBTree_Is_empty( _queue->Queue ) ) {
> +  _Chain_Extract_unprotected( _queue->Node );
> +}
> +  }
> +}
> +
> +static inline void _Scheduler_EDF_SMP_Activate_ready_queue_if_necessary(
> +  Scheduler_EDF_SMP_Context *self,
> +  uint8_trqi,
> +  Scheduler_EDF_SMP_Ready_queue *ready_queue
> +)
> +{
> +  if (
> +rqi != 0 &&
> +_RBTree_Is_empty( _queue->Queue ) &&
> +ready_queue->affine_scheduled == NULL
> +  ) {
> +_Chain_Append_unprotected( >Affine_queues, _queue->Node );
> +  }
> +}
> +
>  static inline void _Scheduler_EDF_SMP_Insert_ready(
>Scheduler_Context *context,
>Scheduler_Node*node_base,
> @@ -265,6 +307,7 @@ static inline void _Scheduler_EDF_SMP_Insert_ready(
>node->generation = generation;
>

Re: [PATCH 08/27] score: Add missing idle thread exchanges

2021-11-20 Thread Gedare Bloom
On Mon, Nov 15, 2021 at 10:13 AM Sebastian Huber
 wrote:
>
> Update #4531.
> ---
>  cpukit/include/rtems/score/schedulersmpimpl.h | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/cpukit/include/rtems/score/schedulersmpimpl.h 
> b/cpukit/include/rtems/score/schedulersmpimpl.h
> index 944b4fc976..a074b53a16 100644
> --- a/cpukit/include/rtems/score/schedulersmpimpl.h
> +++ b/cpukit/include/rtems/score/schedulersmpimpl.h
> @@ -1098,6 +1098,15 @@ static inline void 
> _Scheduler_SMP_Schedule_highest_ready(
>  victim,
>  _Scheduler_SMP_Release_idle_thread
>);
> +} else if ( action == SCHEDULER_TRY_TO_SCHEDULE_DO_IDLE_EXCHANGE ) {
> +  _Scheduler_SMP_Node_change_state(
> +highest_ready,
> +SCHEDULER_SMP_NODE_SCHEDULED
> +  );
> +
> +  ( *move_from_ready_to_scheduled )( context, highest_ready );
> +
> +  _Scheduler_Exchange_idle_thread( highest_ready, victim );
>  } else {
>_Assert( action == SCHEDULER_TRY_TO_SCHEDULE_DO_BLOCK );
>
> @@ -1162,6 +1171,15 @@ static inline void 
> _Scheduler_SMP_Preempt_and_schedule_highest_ready(
>  victim,
>  _Scheduler_SMP_Release_idle_thread
>);
> +} else if ( action == SCHEDULER_TRY_TO_SCHEDULE_DO_IDLE_EXCHANGE ) {
> +  _Scheduler_SMP_Node_change_state(
> +highest_ready,
> +SCHEDULER_SMP_NODE_SCHEDULED
> +  );
> +
> +  ( *move_from_ready_to_scheduled )( context, highest_ready );
> +
> +  _Scheduler_Exchange_idle_thread( highest_ready, victim );
>  } else {
>_Assert( action == SCHEDULER_TRY_TO_SCHEDULE_DO_BLOCK );
>

A bit unrelated, these two functions could be refactored/merged, with
a callout function passed in to select either _Scheduler_SMP_Preempt()
or _Scheduler_SMP_Allocate_processor().

> --
> 2.26.2
>
> ___
> 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 02/27] score: Add red-black tree append/prepend

2021-11-20 Thread Gedare Bloom
On Mon, Nov 15, 2021 at 10:13 AM Sebastian Huber
 wrote:
>
> These functions are a faster alternative to _RBTree_Insert_inline() if
> it is known that the new node is the maximum/minimum node.
>
> Update #4531.
> ---
>  cpukit/include/rtems/score/rbtreeimpl.h | 26 +++
>  cpukit/score/src/rbtreeappend.c | 58 +
>  cpukit/score/src/rbtreeprepend.c| 58 +
>  spec/build/cpukit/librtemscpu.yml   |  2 +
>  4 files changed, 144 insertions(+)
>  create mode 100644 cpukit/score/src/rbtreeappend.c
>  create mode 100644 cpukit/score/src/rbtreeprepend.c
>
> diff --git a/cpukit/include/rtems/score/rbtreeimpl.h 
> b/cpukit/include/rtems/score/rbtreeimpl.h
> index 597c24d771..0867240d59 100644
> --- a/cpukit/include/rtems/score/rbtreeimpl.h
> +++ b/cpukit/include/rtems/score/rbtreeimpl.h
> @@ -30,6 +30,32 @@ extern "C" {
>   * @{
>   */
>
> +/**
> + * @brief Appends the node to the red-black tree.
> + *
> + * The appended node is the new maximum node of the tree.  The caller shall
> + * ensure that the appended node is indeed the maximum node with respect to 
> the
> + * tree order.
> + *
> + * @param[in, out] the_rbtree is the red-black tree control.
> + *
> + * @param the_node[out] is the node to append.
> + */
> +void _RBTree_Append( RBTree_Control *the_rbtree, RBTree_Node *the_node );
> +
> +/**
> + * @brief Prepends the node to the red-black tree.
> + *
> + * The prepended node is the new minimum node of the tree.  The caller shall
> + * ensure that the prepended node is indeed the minimum node with respect to 
> the
> + * tree order.
> + *
> + * @param[in, out] the_rbtree is the red-black tree control.
> + *
> + * @param the_node[out] is the node to prepend.
> + */
> +void _RBTree_Prepend( RBTree_Control *the_rbtree, RBTree_Node *the_node );
> +
>  /**
>   * @brief Red-black tree visitor.
>   *
> diff --git a/cpukit/score/src/rbtreeappend.c b/cpukit/score/src/rbtreeappend.c
> new file mode 100644
> index 00..e36f6bc805
> --- /dev/null
> +++ b/cpukit/score/src/rbtreeappend.c
> @@ -0,0 +1,58 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreRBTree
> + *
> + * @brief This source file contains the implementation of
> + *   _RBTree_Append().
> + */
> +
> +/*
> + * Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include 
> +
> +void _RBTree_Append( RBTree_Control *the_rbtree, RBTree_Node *the_node )
> +{
> +  RBTree_Node **link;
> +  RBTree_Node  *parent;
> +
> +  link = _RBTree_Root_reference( the_rbtree );
> +  parent = NULL;
> +
> +  while ( *link != NULL ) {
> +parent = *link;
> +link = _RBTree_Right_reference( parent );
> +  }
> +
> +  _RBTree_Add_child( the_node, parent, link );
> +  _RBTree_Insert_color( the_rbtree, the_node );
> +}

Can this be simplified?
RBTree_Node *p = _RBTree_Maximum( the_rbtree );
RBTree_Insert_with_parent( the_rbtree, the_node, p,
_RBTree_Right_reference( p ) );

Similar below.

> diff --git a/cpukit/score/src/rbtreeprepend.c 
> b/cpukit/score/src/rbtreeprepend.c
> new file mode 100644
> index 00..f154f51d36
> --- /dev/null
> +++ b/cpukit/score/src/rbtreeprepend.c
> @@ -0,0 +1,58 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreRBTree
> + *
> + * @brief This source file contains the implementation of
> + *   _RBTree_Prepend().
> + */
> +
> +/*
> + * Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
> + *
> + * 

Re: [PATCH 1/2] cpukit: Enable debug for SMP AArch64

2021-11-20 Thread Gedare Bloom
This looks ok, along with the copyright clean-up. In the future please
separate non-functional (style, copyright, etc) changes from
functional patches to simplify review/approval/revision process.

One question I do have from this: the minimum APPROX size is 180
(+CPU_PER_CPU_CONTROL_SIZE + CPU_INTERRUPT_FRAME_SIZE)

So it seems there is some dead macro code following this.

  #elif PER_CPU_CONTROL_SIZE_APPROX > 128
is trivially true if it is reached, therefore
 #else
#define PER_CPU_CONTROL_SIZE_LOG2 7
  #endif
should never happen?


On Wed, Nov 17, 2021 at 11:03 AM Kinsey Moore  wrote:
>
> Ensure when both RTEMS_DEBUG is specified and pointers are large that
> enough space is allocated to accomodate the Per_CPU_Control structure.
> This changes the calculation to be more compositional instead of trying
> to list out every permutation of options possible.
> ---
>  cpukit/include/rtems/score/percpu.h | 31 -
>  1 file changed, 22 insertions(+), 9 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/percpu.h 
> b/cpukit/include/rtems/score/percpu.h
> index 6081653a86..0794f15f69 100644
> --- a/cpukit/include/rtems/score/percpu.h
> +++ b/cpukit/include/rtems/score/percpu.h
> @@ -38,18 +38,31 @@
>  extern "C" {
>  #endif
>
> -#if defined(RTEMS_SMP)
> -  #if defined(RTEMS_PROFILING)
> -#define PER_CPU_CONTROL_SIZE_APPROX \
> -  ( 512 + CPU_PER_CPU_CONTROL_SIZE + CPU_INTERRUPT_FRAME_SIZE )
> -  #elif defined(RTEMS_DEBUG) || CPU_SIZEOF_POINTER > 4
> -#define PER_CPU_CONTROL_SIZE_APPROX \
> -  ( 256 + CPU_PER_CPU_CONTROL_SIZE + CPU_INTERRUPT_FRAME_SIZE )
> +#if defined( RTEMS_SMP )
> +  #if defined( RTEMS_PROFILING )
> +#define PER_CPU_CONTROL_SIZE_PROFILING 332
> +  #else
> +#define PER_CPU_CONTROL_SIZE_PROFILING 0
> +  #endif
> +
> +  #if defined( RTEMS_DEBUG )
> +#define PER_CPU_CONTROL_SIZE_DEBUG 76
>#else
> -#define PER_CPU_CONTROL_SIZE_APPROX \
> -  ( 180 + CPU_PER_CPU_CONTROL_SIZE + CPU_INTERRUPT_FRAME_SIZE )
> +#define PER_CPU_CONTROL_SIZE_DEBUG 0
>#endif
>
> +  #if CPU_SIZEOF_POINTER > 4
> +#define PER_CPU_CONTROL_SIZE_BIG_POINTER 76
> +  #else
> +#define PER_CPU_CONTROL_SIZE_BIG_POINTER 0
> +  #endif
> +
> +  #define PER_CPU_CONTROL_SIZE_BASE 180
> +  #define PER_CPU_CONTROL_SIZE_APPROX \
> +( PER_CPU_CONTROL_SIZE_BASE + CPU_PER_CPU_CONTROL_SIZE + \
> +CPU_INTERRUPT_FRAME_SIZE + PER_CPU_CONTROL_SIZE_PROFILING + \
> +PER_CPU_CONTROL_SIZE_DEBUG + PER_CPU_CONTROL_SIZE_BIG_POINTER )
> +
>/*
> * This ensures that on SMP configurations the individual per-CPU controls
> * are on different cache lines to prevent false sharing.  This define can 
> be
> --
> 2.30.2
>
> ___
> 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 6/6] score: Properly continue the thread during restart

2021-11-20 Thread Gedare Bloom
On Mon, Nov 15, 2021 at 10:09 AM Sebastian Huber
 wrote:
>
> The _Thread_queue_Extract() does not deal with potential priority
> updates and the SMP locking protocol handling.  Use
> _Thread_queue_Continue().  For the POSIX signals processing this is
> currently probably unnecessary, however, the use case is similar to the
> restart so use the same appoach.
>
> Close #4546.
> ---
>  cpukit/include/rtems/score/status.h | 2 ++
>  cpukit/posix/src/psignalunblockthread.c | 4 ++--
>  cpukit/score/src/threadrestart.c| 4 ++--
>  3 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/status.h 
> b/cpukit/include/rtems/score/status.h
> index 236ae52d7b..96c0f1f9af 100644
> --- a/cpukit/include/rtems/score/status.h
> +++ b/cpukit/include/rtems/score/status.h
> @@ -106,6 +106,8 @@ typedef enum {
>  STATUS_BUILD( STATUS_CLASSIC_INCORRECT_STATE, EINVAL ),
>STATUS_INTERRUPTED =
>  STATUS_BUILD( STATUS_CLASSIC_INTERNAL_ERROR, EINTR ),
> +  STATUS_INTERNAL_ERROR =
> +STATUS_BUILD( STATUS_CLASSIC_INTERNAL_ERROR, ENOTSUP ),
>STATUS_INVALID_ADDRESS =
>  STATUS_BUILD( STATUS_CLASSIC_INVALID_ADDRESS, EFAULT ),
>STATUS_INVALID_ID =
> diff --git a/cpukit/posix/src/psignalunblockthread.c 
> b/cpukit/posix/src/psignalunblockthread.c
> index 1133234554..6921c14e46 100644
> --- a/cpukit/posix/src/psignalunblockthread.c
> +++ b/cpukit/posix/src/psignalunblockthread.c
> @@ -180,8 +180,8 @@ static void _POSIX_signals_Interrupt_thread( 
> Thread_Control *the_thread )
>  #if defined(RTEMS_MULTIPROCESSING)
>_Thread_MP_Extract_proxy( the_thread );
>  #endif
> -  the_thread->Wait.return_code = STATUS_INTERRUPTED;
> -  _Thread_queue_Extract( the_thread );
> +  _Thread_Timer_remove( the_thread );
> +  _Thread_Continue( the_thread, STATUS_INTERRUPTED );
>  }
>
It seems the same argument applies here that we should remove the
timer as early as possible to avoid spurious timeouts?

>  bool _POSIX_signals_Unblock_thread(
> diff --git a/cpukit/score/src/threadrestart.c 
> b/cpukit/score/src/threadrestart.c
> index 6423c421b4..657892931e 100644
> --- a/cpukit/score/src/threadrestart.c
> +++ b/cpukit/score/src/threadrestart.c
> @@ -118,7 +118,7 @@ static void _Thread_Remove_timer_and_continue( 
> Thread_Control *the_thread )
>  #if defined(RTEMS_MULTIPROCESSING)
>_Thread_MP_Extract_proxy( the_thread );
>  #endif
> -  _Thread_queue_Extract( the_thread );
> +  _Thread_Continue( the_thread, STATUS_INTERNAL_ERROR );
>  }
>

Both of the above functions are very similar to each other. Consider
refactoring so they (once again) share the same code? The only
difference appears to be the status they pass to Thread_Continue().
Just a thought.

>  static void _Thread_Add_to_zombie_registry( Thread_Control *the_thread )
> @@ -366,7 +366,7 @@ static void _Thread_Remove_life_change_request( 
> Thread_Control *the_thread )
>   * Do not remove states used for thread queues to avoid race conditions 
> on
>   * SMP configurations.  We could interrupt an extract operation on 
> another
>   * processor disregarding the thread wait flags.  Rely on
> - * _Thread_queue_Extract() for removal of these states.
> + * _Thread_Continue() for removal of these states.
>   */
>  _Thread_Clear_state_locked(
>the_thread,
> --
> 2.26.2
>
> ___
> 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 2/6] score: Add _Thread_MP_Extract_proxy()

2021-11-20 Thread Gedare Bloom
On Mon, Nov 15, 2021 at 10:09 AM Sebastian Huber
 wrote:
>
> Remove _Thread_queue_Extract_with_proxy() and move the proxy extraction
> to _Thread_MP_Extract_proxy().  Move similar code blocks of the previous
> caller of _Thread_queue_Extract_with_proxy() to helper functions.
>
> Update #4546.
> ---
>  cpukit/include/rtems/score/objectdata.h|  2 +-
>  cpukit/include/rtems/score/threadmp.h  | 13 ++
>  cpukit/include/rtems/score/threadqimpl.h   | 18 -
>  cpukit/posix/src/psignalunblockthread.c| 16 +---
>  cpukit/score/src/threadqextractwithproxy.c | 46 +++---
>  cpukit/score/src/threadrestart.c   | 17 +---
>  spec/build/cpukit/librtemscpu.yml  |  1 -
>  spec/build/cpukit/objmpci.yml  |  1 +
>  8 files changed, 60 insertions(+), 54 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/objectdata.h 
> b/cpukit/include/rtems/score/objectdata.h
> index 149498df9c..c7fb33ca5b 100644
> --- a/cpukit/include/rtems/score/objectdata.h
> +++ b/cpukit/include/rtems/score/objectdata.h
> @@ -286,7 +286,7 @@ struct Objects_Information {
>
>  #if defined(RTEMS_MULTIPROCESSING)
>/**
> -   * @brief This method is used by _Thread_queue_Extract_with_proxy().
> +   * @brief This method is used by _Thread_MP_Extract_proxy().
> *
> * This member is statically initialized and read-only.
> */
> diff --git a/cpukit/include/rtems/score/threadmp.h 
> b/cpukit/include/rtems/score/threadmp.h
> index 6cc68e6320..81a22e665e 100644
> --- a/cpukit/include/rtems/score/threadmp.h
> +++ b/cpukit/include/rtems/score/threadmp.h
> @@ -97,6 +97,19 @@ Thread_Control *_Thread_MP_Find_proxy (
>  #define _Thread_MP_Is_receive(_the_thread) \
>((_the_thread) == _MPCI_Receive_server_tcb)
>
> +/**
> + * @brief Extracts the proxy of the thread if necessary.
> + *
> + * This routine ensures that if there is a proxy for this thread on another
> + * node, it is also dealt with. A proxy is a data data that is on the thread
'data data' already existed / was copy-pasted, feel free to clean-up later
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


[PATCH 3/3] bsps/aarch64: use SMC API in bspreset-arm-psci

2021-10-16 Thread Gedare Bloom
---
 bsps/shared/start/bspreset-arm-psci.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/bsps/shared/start/bspreset-arm-psci.c 
b/bsps/shared/start/bspreset-arm-psci.c
index 215be5c9b5..bafdfe6299 100644
--- a/bsps/shared/start/bspreset-arm-psci.c
+++ b/bsps/shared/start/bspreset-arm-psci.c
@@ -37,9 +37,28 @@
 #include 
 #include 
 
+#if defined( AARCH64_MULTILIB_ARCH_V8 ) || \
+  defined( AARCH64_MULTILIB_ARCH_V8_ILP32 )
+#include 
+#endif
+
 void bsp_reset(void)
 {
uint32_t PSCI_FN_SYSTEM_RESET = 0x8409;
+#ifdef BSP_RESET_SMC
+  (void) _AArch64_SMC_Invoke(
+  PSCI_FN_SYSTEM_RESET,
+  0,
+  0,
+  0,
+  0,
+  0,
+  0,
+  0,
+  0,
+  NULL
+  );
+#else
__asm__ volatile(
 #if defined(AARCH64_MULTILIB_ARCH_V8) || 
defined(AARCH64_MULTILIB_ARCH_V8_ILP32)
"mov x0, %0\n"
@@ -53,4 +72,5 @@ void bsp_reset(void)
 #endif
: : "r" (PSCI_FN_SYSTEM_RESET)
);
+#endif
 }
-- 
2.25.1

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


[PATCH 1/3] aarch64: add internal API for secure monitor call (smc)

2021-10-16 Thread Gedare Bloom
---
 cpukit/score/cpu/aarch64/aarch64-smc.c| 72 
 .../aarch64/include/rtems/score/aarch64-smc.h | 84 +++
 spec/build/cpukit/cpuaarch64.yml  |  2 +
 3 files changed, 158 insertions(+)
 create mode 100644 cpukit/score/cpu/aarch64/aarch64-smc.c
 create mode 100644 cpukit/score/cpu/aarch64/include/rtems/score/aarch64-smc.h

diff --git a/cpukit/score/cpu/aarch64/aarch64-smc.c 
b/cpukit/score/cpu/aarch64/aarch64-smc.c
new file mode 100644
index 00..4cfee91a0b
--- /dev/null
+++ b/cpukit/score/cpu/aarch64/aarch64-smc.c
@@ -0,0 +1,72 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ *  @file
+ *
+ *  @brief Secure Monitor Call
+ */
+
+/*
+ * Copyright (C) 2021 Gedare Bloom 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+
+int _AArch64_SMC_Invoke(
+  int function_id,
+  uintptr_t arg0,
+  uintptr_t arg1,
+  uintptr_t arg2,
+  uintptr_t arg3,
+  uintptr_t arg4,
+  uintptr_t arg5,
+  uintptr_t arg6,
+  uintptr_t arg7,
+  AArch64_SMC_Return *result
+) {
+  int rv;
+
+  /* This only works for SMC that return 4 or fewer results. It may be extended
+   * up to the full 18 return results specified for SMC64, but then we would
+   * need to allocate a callee-saved register for *result */
+  __asm__ volatile(
+"smc  #0\n"
+"mov  %0, x0\n"
+"ldr  x15, [sp]\n"
+"cbz  x15, 0f\n"
+"stp  x0, x1, [x15]\n"
+"stp  x2, x3, [x15, #16]\n"
+"0:\n"
+: "=r" ( rv )
+:
+: "x0", "x1", "x2", "x3", "x15"
+  );
+
+  return rv;
+}
+
diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/aarch64-smc.h 
b/cpukit/score/cpu/aarch64/include/rtems/score/aarch64-smc.h
new file mode 100644
index 00..04f99f8bf3
--- /dev/null
+++ b/cpukit/score/cpu/aarch64/include/rtems/score/aarch64-smc.h
@@ -0,0 +1,84 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreCPUAArch64
+ *
+ * @brief This header file provides API to wrap secure monitor calls (smc).
+ */
+
+/*
+ * Copyright (C) 2021 Gedare Bloom 
+ *
+ * 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 _RTEMS_SCORE_AARCH64_SMC_H
+#define _RTEMS_SCORE_AARCH64_SMC_H
+
+#include 
+
+#ifdef __cplusplus
+extern

[PATCH 2/3] bsps/aarch64: use SMC API in bspsmp-arm-psci

2021-10-16 Thread Gedare Bloom
---
 bsps/shared/start/bspsmp-arm-psci.c | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/bsps/shared/start/bspsmp-arm-psci.c 
b/bsps/shared/start/bspsmp-arm-psci.c
index 1ff5b7bb89..749885ef7d 100644
--- a/bsps/shared/start/bspsmp-arm-psci.c
+++ b/bsps/shared/start/bspsmp-arm-psci.c
@@ -41,6 +41,7 @@
 #if defined( AARCH64_MULTILIB_ARCH_V8 ) || \
   defined( AARCH64_MULTILIB_ARCH_V8_ILP32 )
 #include 
+#include 
 #else
 #include 
 #endif
@@ -67,22 +68,33 @@ bool _CPU_SMP_Start_processor( uint32_t cpu_index )
   target_cpu &= ~( 0xffffUL );
   target_cpu |= cpu_index;
 
+#ifdef BSP_CPU_ON_USES_SMC
+  ret = _AArch64_SMC_Invoke(
+  PSCI_FN_SYSTEM_CPU_ON,
+  target_cpu,
+  _start,
+  0,
+  0,
+  0,
+  0,
+  0,
+  0,
+  NULL
+  );
+#else
   __asm__ volatile (
 "mov " REGISTER_PREFIX "0, %1\n"
 "mov " REGISTER_PREFIX "1, %2\n"
 "mov " REGISTER_PREFIX "2, %3\n"
 "mov " REGISTER_PREFIX "3, #0\n"
-#ifdef BSP_CPU_ON_USES_SMC
-"smc #0\n"
-#else
 "hvc #0\n"
-#endif
 "mov %0, " REGISTER_PREFIX "0\n"
 : "=r" ( ret ) : "r" ( PSCI_FN_SYSTEM_CPU_ON ), "r" ( target_cpu ),
 "r" ( _start )
 : REGISTER_PREFIX "0", REGISTER_PREFIX "1", REGISTER_PREFIX "2",
 REGISTER_PREFIX "3"
   );
+#endif
 
   if ( ret != 0 ) {
 return false;
-- 
2.25.1

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


[PATCH 0/3] Add Secure Monitor Call API

2021-10-16 Thread Gedare Bloom
These patches add and use an internal API to make
secure monitor call (SMC) invocations. SMC is used
currently in aarch64 for secondary processor boot
and bsp_reset. Although SMC is available on arm, it
does not appear to be currently used by any of arm
BSPs. So the current approach is only implemented
in the aarch64. Replicating the implementation for
arm (with SMC32) should be simple if needed, but
the placement of the API may need some more thought.
Currently, the only place that aarch64 and arm can
easily share code is underneath bsps/shared.
Also, it should be straightforward to add a similar
API for hypervisor call (HVC) invocations.

Gedare Bloom (3):
  aarch64: add internal API for secure monitor call (smc)
  bsps/aarch64: use SMC API in bspsmp-arm-psci
  bsps/aarch64: use SMC API in bspreset-arm-psci

 bsps/shared/start/bspreset-arm-psci.c | 20 +
 bsps/shared/start/bspsmp-arm-psci.c   | 20 -
 cpukit/score/cpu/aarch64/aarch64-smc.c| 72 
 .../aarch64/include/rtems/score/aarch64-smc.h | 84 +++
 spec/build/cpukit/cpuaarch64.yml  |  2 +
 5 files changed, 194 insertions(+), 4 deletions(-)
 create mode 100644 cpukit/score/cpu/aarch64/aarch64-smc.c
 create mode 100644 cpukit/score/cpu/aarch64/include/rtems/score/aarch64-smc.h

-- 
2.25.1

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


Re: [PATCH] score: Simplify _Watchdog_Next_first()

2021-10-11 Thread Gedare Bloom
ok

On Mon, Oct 11, 2021 at 5:24 AM Sebastian Huber
 wrote:
>
> ---
>  cpukit/include/rtems/score/watchdogimpl.h | 55 +++
>  1 file changed, 36 insertions(+), 19 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/watchdogimpl.h 
> b/cpukit/include/rtems/score/watchdogimpl.h
> index 7b364b8828..ba1a884a3d 100644
> --- a/cpukit/include/rtems/score/watchdogimpl.h
> +++ b/cpukit/include/rtems/score/watchdogimpl.h
> @@ -351,33 +351,50 @@ RTEMS_INLINE_ROUTINE bool _Watchdog_Is_scheduled(
>  }
>
>  /**
> - * @brief Sets the first node of the header.
> + * @brief Sets the first watchdog of the watchdog collection to the next
> + * watchdog of the current first watchdog.
>   *
> - * Sets the first node of the header to either the leftmost child node of the
> - *  watchdog control node, or if not present sets it to the right child node 
> of
> - * the watchdog control node. if both are not present, the new first node is
> - * the parent node of the current first node.
> + * This function may be used during watchdog removals, see _Watchdog_Remove()
> + * and _Watchdog_Tickle().
>   *
> - * @param[in, out] header The watchdog header.
> - * @param the_watchdog The watchdog control node for the operation.
> + * @param[in, out] header is the watchdog collection header.
> + *
> + * @param first is the current first watchdog which should be removed
> + *   afterwards.
>   */
>  RTEMS_INLINE_ROUTINE void _Watchdog_Next_first(
> -  Watchdog_Header  *header,
> -  Watchdog_Control *the_watchdog
> +  Watchdog_Header*header,
> +  const Watchdog_Control *first
>  )
>  {
> -  RBTree_Node *node = _RBTree_Right( _watchdog->Node.RBTree );
> -
> -  if ( node != NULL ) {
> -RBTree_Node *left;
> -
> -while ( ( left = _RBTree_Left( node ) ) != NULL ) {
> -  node = left;
> -}
> +  RBTree_Node *right;
>
> -header->first = node;
> +  /*
> +   * This function uses the following properties of red-black trees:
> +   *
> +   * 1. Every leaf (NULL) is black.
> +   *
> +   * 2. If a node is red, then both its children are black.
> +   *
> +   * 3. Every simple path from a node to a descendant leaf contains the same
> +   *number of black nodes.
> +   *
> +   * The first node has no left child.  So every path from the first node has
> +   * exactly one black node (including leafs).  The first node cannot have a
> +   * non-leaf black right child.  It may have a red right child.  In this 
> case
> +   * both children must be leafs.
> +   */
> +  _Assert( header->first == >Node.RBTree );
> +  _Assert( _RBTree_Left( >Node.RBTree ) == NULL );
> +  right = _RBTree_Right( >Node.RBTree );
> +
> +  if ( right != NULL ) {
> +_Assert( RB_COLOR( right, Node ) == RB_RED );
> +_Assert( _RBTree_Left( right ) == NULL );
> +_Assert( _RBTree_Right( right ) == NULL );
> +header->first = right;
>} else {
> -header->first = _RBTree_Parent( _watchdog->Node.RBTree );
> +header->first = _RBTree_Parent( >Node.RBTree );
>}
>  }
>
> --
> 2.31.1
>
> ___
> 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 v2 2/6] cpukit: Add Exception Manager

2021-09-30 Thread Gedare Bloom
You also might separate the exception manager addition away from the
topic of recoverable exceptions. This introduces/extends the classic
API, so it needs to be vetted carefully. Although the new header
claims to be a classic API, it appears to not follow classic API
conventions. You might need to think about what needs to be exposed to
the application level, and how, versus what should be internal. And
follow the conventions for classic API usage (e.g., opaque types not
pointers).

On Wed, Sep 22, 2021 at 6:17 PM Kinsey Moore  wrote:
>
> This adds the framework necessary to allow more generic handling of
> machine exceptions. This initial patch offers the ability to get the
> class of exception from the CPU_Exception_frame provided. Future
> extensions of the Exception Manager could include the ability to get
> the address of the exception if applicable or to resume execution at
> the next instruction or an arbitrary location.
> ---
>  cpukit/include/rtems/exception.h  | 166 ++
>  spec/build/cpukit/cpuopts.yml |   2 +
>  spec/build/cpukit/librtemscpu.yml |   1 +
>  spec/build/cpukit/optexceptionmanager.yml |  17 +++
>  4 files changed, 186 insertions(+)
>  create mode 100644 cpukit/include/rtems/exception.h
>  create mode 100644 spec/build/cpukit/optexceptionmanager.yml
>
> diff --git a/cpukit/include/rtems/exception.h 
> b/cpukit/include/rtems/exception.h
> new file mode 100644
> index 00..89edfd02b4
> --- /dev/null
> +++ b/cpukit/include/rtems/exception.h
> @@ -0,0 +1,166 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @brief This header file defines the Exception Manager API.
> + */
> +
> +/*
> + * Copyright (C) 2021 On-Line Applications Research Corporation (OAR)
> + *
> + * 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 _RTEMS_EXCEPTION_H
> +#define _RTEMS_EXCEPTION_H
> +
> +#include 
> +#include 
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +/**
> + * @defgroup RTEMSAPIClassicException Exception Manager
> + *
> + * @ingroup RTEMSAPIClassic
> + *

If this is an extension of the Classic API, then it should be
following classic api naming conventions, hence I'd expect this all to
be rtems_exception_xxx(). Please clarify.

> + * @brief The Exception Manager processes all machine exceptions and passes
> + *   any unhandled exceptions to the Fatal Error Manager.
> + */
> +
> +/**
> + *  The following lists the generic exception classes supported by the 
> Exception
> + *  Management API.
> + */
> +typedef enum {
> +  EXCEPTION_UNKNOWN,
> +  EXCEPTION_FPU,
> +  EXCEPTION_TAGGED_OVERFLOW,
> +  EXCEPTION_DIV_ZERO,
> +  EXCEPTION_DATA_ABORT_READ,
> +  EXCEPTION_DATA_ABORT_WRITE,
> +  EXCEPTION_DATA_ABORT_UNSPECIFIED,
> +  EXCEPTION_INSTRUCTION_ABORT,
> +  EXCEPTION_MMU_UNSPECIFIED,
> +  EXCEPTION_ACCESS_ALIGNMENT,
> +  EXCEPTION_SUPERVISOR,
> +  EXCEPTION_TRAPPED_INSTRUCTION,
> +  EXCEPTION_PC_ALIGNMENT,
> +  EXCEPTION_SP_ALIGNMENT,
> +  EXCEPTION_BREAKPOINT,
> +  EXCEPTION_BREAK_INSTRUCTION,
> +  EXCEPTION_STEP,
> +  EXCEPTION_WATCHPOINT,
> +  EXCEPTION_MAX
> +} Exception_Class;
> +

How did you derive these? Do they need some more documentation?

I'm not 100% on calling them "Classes". Types? Sources? I'm not sure.

> +/**
> + * @brief Resumes normal execution using the provided exception frame.
> + *
> + * This routine helps to avoid dead code in the exception handler epilogue 
> and
> + * does not return. This routine may assume that the provided pointer is 
> valid
> + * for resetting the exception stack.
> + *
> + * @param exception_frame The CPU_Exception_frame describing the machine
> + * 

Re: [PATCH v2 1/6] cpukit/aarch64: Use correct interrupt level types

2021-09-30 Thread Gedare Bloom
If the rest of the patch set isn't ready, please split this out for
separate submission. It looks fine to me.

On Wed, Sep 22, 2021 at 6:17 PM Kinsey Moore  wrote:
>
> All other architectures use uint32_t for interrupt levels and there is
> no reason not to do so on AArch64.
> ---
>  cpukit/score/cpu/aarch64/cpu.c | 4 ++--
>  cpukit/score/cpu/aarch64/include/rtems/score/cpu.h | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/cpukit/score/cpu/aarch64/cpu.c b/cpukit/score/cpu/aarch64/cpu.c
> index d09403a349..b36f55ae17 100644
> --- a/cpukit/score/cpu/aarch64/cpu.c
> +++ b/cpukit/score/cpu/aarch64/cpu.c
> @@ -146,7 +146,7 @@ void _CPU_Context_Initialize(
>}
>  }
>
> -void _CPU_ISR_Set_level( uint64_t level )
> +void _CPU_ISR_Set_level( uint32_t level )
>  {
>/* Set the mask bit if interrupts are disabled */
>level = level ? AARCH64_PSTATE_I : 0;
> @@ -156,7 +156,7 @@ void _CPU_ISR_Set_level( uint64_t level )
>);
>  }
>
> -uint64_t _CPU_ISR_Get_level( void )
> +uint32_t _CPU_ISR_Get_level( void )
>  {
>uint64_t level;
>
> diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h 
> b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
> index 82f74193a2..ae7e2bdcba 100644
> --- a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
> +++ b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
> @@ -204,9 +204,9 @@ static inline void 
> _AARCH64_Instruction_synchronization_barrier( void )
>__asm__ volatile ( "isb" : : : "memory" );
>  }
>
> -void _CPU_ISR_Set_level( uint64_t level );
> +void _CPU_ISR_Set_level( uint32_t level );
>
> -uint64_t _CPU_ISR_Get_level( void );
> +uint32_t _CPU_ISR_Get_level( void );
>
>  #if defined(AARCH64_DISABLE_INLINE_ISR_DISABLE_ENABLE)
>  uint64_t AArch64_interrupt_disable( void );
> --
> 2.30.2
>
> ___
> 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] cpukit/aarch64: Use correct context register sets

2021-09-30 Thread Gedare Bloom
looks ok to me.

On Thu, Sep 23, 2021 at 1:05 PM Kinsey Moore  wrote:
>
> Context validation for AArch64 was ported from the ARM implementation
> without a reinterpretation of the actual requirements. The spcontext01
> test just happened to pass because the set of scratch registers in ARM
> is a subset of the scratch registers in AArch64.
> ---
>  .../cpu/aarch64/aarch64-context-validate.S| 159 --
>  .../aarch64-context-volatile-clobber.S|  19 +++
>  2 files changed, 123 insertions(+), 55 deletions(-)
>
> diff --git a/cpukit/score/cpu/aarch64/aarch64-context-validate.S 
> b/cpukit/score/cpu/aarch64/aarch64-context-validate.S
> index 1e71bc5b3a..1daa0d6bf2 100644
> --- a/cpukit/score/cpu/aarch64/aarch64-context-validate.S
> +++ b/cpukit/score/cpu/aarch64/aarch64-context-validate.S
> @@ -44,35 +44,47 @@
>  #include 
>  #include 
>
> -/* These must be 8 byte aligned to avoid misaligned accesses */
> -#define FRAME_OFFSET_X4  0x00
> -#define FRAME_OFFSET_X5  0x08
> -#define FRAME_OFFSET_X6  0x10
> -#define FRAME_OFFSET_X7  0x18
> -#define FRAME_OFFSET_X8  0x20
> -#define FRAME_OFFSET_X9  0x28
> -#define FRAME_OFFSET_X10 0x30
> -#define FRAME_OFFSET_X11 0x38
> -#define FRAME_OFFSET_LR  0x40
> +/*
> + * This register size applies to X (integer) registers as well as the D 
> (lower
> + * half floating point) registers. It does not apply to V (full size floating
> + * point) registers or W (lower half integer) registers.
> + */
> +#define AARCH64_REGISTER_SIZE 8
> +
> +/* According to the AAPCS64, X19-X28 are callee-saved registers */
> +#define FRAME_OFFSET_X19  0x00
> +#define FRAME_OFFSET_X20  0x08
> +#define FRAME_OFFSET_X21  0x10
> +#define FRAME_OFFSET_X22  0x18
> +#define FRAME_OFFSET_X23  0x20
> +#define FRAME_OFFSET_X24  0x28
> +#define FRAME_OFFSET_X25  0x30
> +#define FRAME_OFFSET_X26  0x38
> +#define FRAME_OFFSET_X27  0x40
> +#define FRAME_OFFSET_X28  0x48
> +#define FRAME_OFFSET_LR   0x50
>
>  #ifdef AARCH64_MULTILIB_VFP
> -  /* These must be 16 byte aligned to avoid misaligned accesses */
> -  #define FRAME_OFFSET_V8  0x50
> -  #define FRAME_OFFSET_V9  0x60
> -  #define FRAME_OFFSET_V10 0x70
> -  #define FRAME_OFFSET_V11 0x80
> -  #define FRAME_OFFSET_V12 0x90
> -  #define FRAME_OFFSET_V13 0xA0
> -  #define FRAME_OFFSET_V14 0xB0
> -  #define FRAME_OFFSET_V15 0xC0
> +  /*
> +   * According to the AAPCS64, V8-V15 are callee-saved registers, but only 
> the
> +   * bottom 8 bytes are required to be saved which correspond to D8-D15.
> +   */
> +  #define FRAME_OFFSET_D8  0x58
> +  #define FRAME_OFFSET_D9  0x60
> +  #define FRAME_OFFSET_D10 0x68
> +  #define FRAME_OFFSET_D11 0x70
> +  #define FRAME_OFFSET_D12 0x78
> +  #define FRAME_OFFSET_D13 0x80
> +  #define FRAME_OFFSET_D14 0x88
> +  #define FRAME_OFFSET_D15 0x90
>
>/*
> * Force 16 byte alignment of the frame size to avoid stack pointer 
> alignment
> * exceptions.
> */
> -  #define FRAME_SIZE RTEMS_ALIGN_UP( FRAME_OFFSET_V15, 16 )
> +  #define FRAME_SIZE RTEMS_ALIGN_UP( FRAME_OFFSET_D15 + 
> AARCH64_REGISTER_SIZE, 16 )
>  #else
> -  #define FRAME_SIZE RTEMS_ALIGN_UP( FRAME_OFFSET_LR, 16 )
> +  #define FRAME_SIZE RTEMS_ALIGN_UP( FRAME_OFFSET_LR + 
> AARCH64_REGISTER_SIZE, 16 )
>  #endif
>
> .section.text
> @@ -83,25 +95,27 @@ FUNCTION_ENTRY(_CPU_Context_validate)
>
> sub sp, sp, #FRAME_SIZE
>
> -   str x4, [sp, #FRAME_OFFSET_X4]
> -   str x5, [sp, #FRAME_OFFSET_X5]
> -   str x6, [sp, #FRAME_OFFSET_X6]
> -   str x7, [sp, #FRAME_OFFSET_X7]
> -   str x8, [sp, #FRAME_OFFSET_X8]
> -   str x9, [sp, #FRAME_OFFSET_X9]
> -   str x10, [sp, #FRAME_OFFSET_X10]
> -   str x11, [sp, #FRAME_OFFSET_X11]
> +   str x19, [sp, #FRAME_OFFSET_X19]
> +   str x20, [sp, #FRAME_OFFSET_X20]
> +   str x21, [sp, #FRAME_OFFSET_X21]
> +   str x22, [sp, #FRAME_OFFSET_X22]
> +   str x23, [sp, #FRAME_OFFSET_X23]
> +   str x24, [sp, #FRAME_OFFSET_X24]
> +   str x25, [sp, #FRAME_OFFSET_X25]
> +   str x26, [sp, #FRAME_OFFSET_X26]
> +   str x27, [sp, #FRAME_OFFSET_X27]
> +   str x28, [sp, #FRAME_OFFSET_X28]
> str lr, [sp, #FRAME_OFFSET_LR]
>
>  #ifdef AARCH64_MULTILIB_VFP
> -   str d8, [sp, #FRAME_OFFSET_V8]
> -   str d9, [sp, #FRAME_OFFSET_V9]
> -   str d10, [sp, #FRAME_OFFSET_V10]
> -   str d11, [sp, #FRAME_OFFSET_V11]
> -   str d12, [sp, #FRAME_OFFSET_V12]
> -   str d13, [sp, #FRAME_OFFSET_V13]
> -   str d14, [sp, #FRAME_OFFSET_V14]
> -   str d15, [sp, #FRAME_OFFSET_V15]
> +   str d8, [sp, #FRAME_OFFSET_D8]
> +   str d9, [sp, #FRAME_OFFSET_D9]
> +   str d10, [sp, #FRAME_OFFSET_D10]
> +   str d11, [sp, #FRAME_OFFSET_D11]
> +   str d12, [sp, #FRAME_OFFSET_D12]
> +   str d13, [sp, #FRAME_OFFSET_D13]
> +   str d14, [sp, #FRAME_OFFSET_D14]
> +   

Re: [PATCHv5] improve the format error reporting on i386

2021-09-30 Thread Gedare Bloom
Joel, i think the patch looks good.

On Fri, Sep 24, 2021 at 6:19 PM zack leung  wrote:
>
> bump
>
>
> On Thu, 23 Sept 2021 at 00:21, zack leung  wrote:
>>
>> I can send an example of the exception if you want.
>>
>> zack
>>
>> On Wed, 22 Sept 2021 at 18:01, Gedare Bloom  wrote:
>>>
>>> Joel,
>>>
>>> This looks good to me. I don't know if you can easily test it?
>>>
>>> Gedare
>>>
>>> On Wed, Sep 22, 2021 at 11:26 AM zack leung  
>>> wrote:
>>> >
>>> > ll hex values now have 8 character width
>>> > thread id is now hex
>>> > updates #4203
>>> > ---
>>> >  cpukit/score/cpu/i386/cpu.c | 6 +++---
>>> >  1 file changed, 3 insertions(+), 3 deletions(-)
>>> >
>>> > diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
>>> > index 77b7a7161c..786cf8b0b6 100644
>>> > --- a/cpukit/score/cpu/i386/cpu.c
>>> > +++ b/cpukit/score/cpu/i386/cpu.c
>>> > @@ -215,16 +215,16 @@ void _CPU_Exception_frame_print (const
>>> > CPU_Exception_frame *ctx)
>>> >  {
>>> >unsigned int faultAddr = 0;
>>> >printk("--\n");
>>> > -  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
>>> > PRId32 "\n",
>>> > +  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread 0x%08"
>>> > PRIx32 "\n",
>>> >   ctx->idtIndex,
>>> >   ctx->eip,
>>> >   _Thread_Executing->Object.id);
>>> >printk("--\n");
>>> >printk("Processor execution context at time of the fault was  :\n");
>>> >printk("--\n");
>>> > -  printk(" EAX = %" PRIx32 "EBX = %" PRIx32 "ECX = %" PRIx32 "
>>> > EDX = %" PRIx32 "\n",
>>> > +  printk(" EAX =  0x%08" PRIx32 "EBX =  0x%08" PRIx32 "ECX =
>>> > 0x%08" PRIx32 "EDX =  0x%08" PRIx32 "\n",
>>> >   ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
>>> > -  printk(" ESI = %" PRIx32 "EDI = %" PRIx32 "EBP = %" PRIx32 "
>>> > ESP = %" PRIx32 "\n",
>>> > +  printk(" ESI = 0x%08" PRIx32 "EDI =  0x%08" PRIx32 "EBP =
>>> > 0x%08" PRIx32 "ESP =  0x%08" PRIx32 "\n",
>>> >   ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
>>> >printk("--\n");
>>> >printk("Error code pushed by processor itself (if not 0) = %" PRIx32
>>> > "\n",
>>> > --
>>> > 2.33.0
>>> > ___
>>> > 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] score: Remove _Thread_queue_Do_nothing_extract()

2021-09-30 Thread Gedare Bloom
ok

On Thu, Sep 30, 2021 at 5:51 AM Sebastian Huber
 wrote:
>
> This function was unused.  It was a relict of the thread queue rework done
> during the SMP support development.  In an early stage, the extract operation
> was called with a NULL thread queue.  However, this is no longer the case.  
> The
> extract operation is only called if we have a non-NULL thread queue.
> ---
>  cpukit/score/src/threadqops.c | 16 ++--
>  1 file changed, 2 insertions(+), 14 deletions(-)
>
> diff --git a/cpukit/score/src/threadqops.c b/cpukit/score/src/threadqops.c
> index a42876cf09..972af21265 100644
> --- a/cpukit/score/src/threadqops.c
> +++ b/cpukit/score/src/threadqops.c
> @@ -59,17 +59,6 @@ void _Thread_queue_Do_nothing_priority_actions(
>_Priority_Actions_initialize_empty( priority_actions );
>  }
>
> -static void _Thread_queue_Do_nothing_extract(
> -  Thread_queue_Queue   *queue,
> -  Thread_Control   *the_thread,
> -  Thread_queue_Context *queue_context
> -)
> -{
> -  (void) queue;
> -  (void) the_thread;
> -  (void) queue_context;
> -}
> -
>  static void _Thread_queue_Queue_enqueue(
>Thread_queue_Queue   *queue,
>Thread_Control   *the_thread,
> @@ -1461,12 +1450,11 @@ static Thread_Control 
> *_Thread_queue_Priority_inherit_surrender(
>  }
>
>  const Thread_queue_Operations _Thread_queue_Operations_default = {
> -  .priority_actions = _Thread_queue_Do_nothing_priority_actions,
> -  .extract = _Thread_queue_Do_nothing_extract
> +  .priority_actions = _Thread_queue_Do_nothing_priority_actions
>/*
> * The default operations are only used in _Thread_Priority_apply() and
> * _Thread_Continue() and do not have a thread queue associated with them, 
> so
> -   * the enqueue and first operations are superfluous.
> +   * the enqueue, extract, surrender, and first operations are superfluous.
> */
>  };
>
> --
> 2.26.2
>
> ___
> 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] score: Add Thread_queue_Deadlock_status

2021-09-30 Thread Gedare Bloom
On Fri, Sep 24, 2021 at 12:22 PM Sebastian Huber
 wrote:
>
> Replace the boolen return value with the new enum
> Thread_queue_Deadlock_status.  This improves the code readability.
> Improve documentation.  Shorten function names.
> ---
>  cpukit/include/rtems/score/threadqimpl.h | 50 ++-
>  cpukit/score/src/threadchangepriority.c  |  4 +-
>  cpukit/score/src/threadqenqueue.c| 63 ++--
>  cpukit/score/src/threadqops.c|  4 +-
>  4 files changed, 80 insertions(+), 41 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/threadqimpl.h 
> b/cpukit/include/rtems/score/threadqimpl.h
> index 22e0c7f069..d4fa8b8316 100644
> --- a/cpukit/include/rtems/score/threadqimpl.h
> +++ b/cpukit/include/rtems/score/threadqimpl.h
> @@ -1339,28 +1339,56 @@ void _Thread_queue_Unblock_proxy(
>  #endif
>
>  /**
> - * @brief Acquires the thread queue path in a critical section.
> + * @brief This is a status code to indicate if a deadlock was detected or 
> not.
> + */
> +typedef enum {
> +  /**
> +   * @brief The operation detected a deadlock.
> +   */
> +  THREAD_QUEUE_DEADLOCK_DETECTED,
> +
> +  /**
> +   * @brief The operation did not detect a deadlock.
> +   */
> +  THREAD_QUEUE_NO_DEADLOCK
> +} Thread_queue_Deadlock_status;
> +

A minor note, I might switch the order of the two enum values so that
THREAD_QUEUE_NO_DEADLOCK==0==false, as this is more consistent with
the previous usage of the bool variable statuses. However, this should
not matter since you replaced the only spots the boolean value was
being  used with explicit checks against the enum type. So feel free
to ignore :)

> +#if defined(RTEMS_SMP)
> +/**
> + * @brief Acquires the thread queue path.
>   *
> - * @param queue The thread queue queue.
> - * @param the_thread The thread for the operation.
> - * @param queue_context The thread queue context.
> + * The caller must own the thread queue lock.
> + *
> + * A acquired thread queue path must be released by calling
minor: A -> An

Rest of this looks good.

> + * _Thread_queue_Path_release() with the same thread queue context.
> + *
> + * @param queue is the thread queue queue.
> + *
> + * @param the_thread is the thread for the operation.
> + *
> + * @param queue_context is the thread queue context.
>   *
> - * @retval true The operation was successful.
> - * @retval false The operation failed.
> + * @retval THREAD_QUEUE_NO_DEADLOCK No deadlock was detected.
> + *
> + * @retval THREAD_QUEUE_DEADLOCK_DETECTED A deadlock was detected while
> + *   acquiring the thread queue path.  The thread queue path must still be
> + *   released by _Thread_queue_Path_release() in this case.
>   */
> -#if defined(RTEMS_SMP)
> -bool _Thread_queue_Path_acquire_critical(
> +Thread_queue_Deadlock_status _Thread_queue_Path_acquire(
>Thread_queue_Queue   *queue,
>Thread_Control   *the_thread,
>Thread_queue_Context *queue_context
>  );
>
>  /**
> - * @brief Releases the thread queue path in a critical section.
> + * @brief Releases the thread queue path.
>   *
> - * @param queue_context The thread queue context.
> + * The caller must have acquired the thread queue path with a corresponding
> + * _Thread_queue_Path_acquire().
> + *
> + * @param queue_context is the thread queue context.
>   */
> -void _Thread_queue_Path_release_critical(
> +void _Thread_queue_Path_release(
>Thread_queue_Context *queue_context
>  );
>  #endif
> diff --git a/cpukit/score/src/threadchangepriority.c 
> b/cpukit/score/src/threadchangepriority.c
> index 613d0cd7af..bd4fef279b 100644
> --- a/cpukit/score/src/threadchangepriority.c
> +++ b/cpukit/score/src/threadchangepriority.c
> @@ -278,11 +278,11 @@ static void _Thread_Priority_apply(
>
>if ( !_Priority_Actions_is_empty( _context->Priority.Actions ) ) {
>  #if defined(RTEMS_SMP)
> -_Thread_queue_Path_acquire_critical( queue, the_thread, queue_context );
> +(void) _Thread_queue_Path_acquire( queue, the_thread, queue_context );
>  #endif
>  _Thread_Priority_perform_actions( queue->owner, queue_context );
>  #if defined(RTEMS_SMP)
> -_Thread_queue_Path_release_critical( queue_context );
> +_Thread_queue_Path_release( queue_context );
>  #endif
>}
>  }
> diff --git a/cpukit/score/src/threadqenqueue.c 
> b/cpukit/score/src/threadqenqueue.c
> index 1b8b82eab9..ee5c6fff5e 100644
> --- a/cpukit/score/src/threadqenqueue.c
> +++ b/cpukit/score/src/threadqenqueue.c
> @@ -8,10 +8,9 @@
>   *   _Thread_queue_Do_dequeue(), _Thread_queue_Enqueue(),
>   *   _Thread_queue_Enqueue_do_nothing_extra(), 
> _Thread_queue_Enqueue_sticky(),
>   *   _Thread_queue_Extract(), _Thread_queue_Extract_locked(),
> - *   _Thread_queue_Path_acquire_critical(),
> - *   _Thread_queue_Path_release_critical(),
> + *   _Thread_queue_Path_acquire(), _Thread_queue_Path_release(),
>   *   _Thread_queue_Resume(),_Thread_queue_Surrender(),
> - *   _Thread_queue_Surrender_sticky().
> + *   _Thread_queue_Surrender_no_priority(), 

Re: [PATCH] score: Avoid dead code in thread queue surrender

2021-09-30 Thread Gedare Bloom
This looks ok

On Wed, Sep 29, 2021 at 11:40 PM Sebastian Huber
 wrote:
>
> On 23/09/2021 07:38, Sebastian Huber wrote:
> > For uniprocessor configurations, this patch removes dead code in the
> > _Thread_queue_Surrender() and _Thread_queue_Surrender_priority_ceiling()
> > functions.
> >
> > Dead code is removed from _Thread_queue_Surrender_sticky().
>
> Ping.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> 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: [PATCHv5] improve the format error reporting on i386

2021-09-22 Thread Gedare Bloom
Joel,

This looks good to me. I don't know if you can easily test it?

Gedare

On Wed, Sep 22, 2021 at 11:26 AM zack leung  wrote:
>
> ll hex values now have 8 character width
> thread id is now hex
> updates #4203
> ---
>  cpukit/score/cpu/i386/cpu.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
> index 77b7a7161c..786cf8b0b6 100644
> --- a/cpukit/score/cpu/i386/cpu.c
> +++ b/cpukit/score/cpu/i386/cpu.c
> @@ -215,16 +215,16 @@ void _CPU_Exception_frame_print (const
> CPU_Exception_frame *ctx)
>  {
>unsigned int faultAddr = 0;
>printk("--\n");
> -  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> PRId32 "\n",
> +  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread 0x%08"
> PRIx32 "\n",
>   ctx->idtIndex,
>   ctx->eip,
>   _Thread_Executing->Object.id);
>printk("--\n");
>printk("Processor execution context at time of the fault was  :\n");
>printk("--\n");
> -  printk(" EAX = %" PRIx32 "EBX = %" PRIx32 "ECX = %" PRIx32 "
> EDX = %" PRIx32 "\n",
> +  printk(" EAX =  0x%08" PRIx32 "EBX =  0x%08" PRIx32 "ECX =
> 0x%08" PRIx32 "EDX =  0x%08" PRIx32 "\n",
>   ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
> -  printk(" ESI = %" PRIx32 "EDI = %" PRIx32 "EBP = %" PRIx32 "
> ESP = %" PRIx32 "\n",
> +  printk(" ESI = 0x%08" PRIx32 "EDI =  0x%08" PRIx32 "EBP =
> 0x%08" PRIx32 "ESP =  0x%08" PRIx32 "\n",
>   ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
>printk("--\n");
>printk("Error code pushed by processor itself (if not 0) = %" PRIx32
> "\n",
> --
> 2.33.0
> ___
> 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: [PATCHv5] improve the format error reporting on i386

2021-09-22 Thread Gedare Bloom
On Tue, Sep 21, 2021 at 4:06 PM zack leung  wrote:
>
> all hex values now have 8 character width
> thread id is now hex
> ---
>  cpukit/score/cpu/i386/cpu.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
> index 77b7a7161c..786cf8b0b6 100644
> --- a/cpukit/score/cpu/i386/cpu.c
> +++ b/cpukit/score/cpu/i386/cpu.c
> @@ -215,16 +215,16 @@ void _CPU_Exception_frame_print (const
> CPU_Exception_frame *ctx)
>  {
>unsigned int faultAddr = 0;
>printk("--\n");
> -  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> PRId32 "\n",
> +  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> PRIx32 "\n",

The thread ID does not have 8 character fixed width.

>   ctx->idtIndex,
>   ctx->eip,
>   _Thread_Executing->Object.id);
>printk("--\n");
>printk("Processor execution context at time of the fault was  :\n");
>printk("--\n");
> -  printk(" EAX = %" PRIx32 "EBX = %" PRIx32 "ECX = %" PRIx32 "
> EDX = %" PRIx32 "\n",
> +  printk(" EAX =  0x%08" PRIx32 "EBX =  0x%08" PRIx32 "ECX =
> 0x%08" PRIx32 "EDX =  0x%08" PRIx32 "\n",
>   ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
> -  printk(" ESI = %" PRIx32 "EDI = %" PRIx32 "EBP = %" PRIx32 "
> ESP = %" PRIx32 "\n",
> +  printk(" ESI = 0x%08" PRIx32 "EDI =  0x%08" PRIx32 "EBP =
> 0x%08" PRIx32 "ESP =  0x%08" PRIx32 "\n",
>   ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
>printk("--\n");
>printk("Error code pushed by processor itself (if not 0) = %" PRIx32
> "\n",
> --
> 2.33.0
> ___
> 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 rtems-tools 3/3] tester/mvme2307: Add support for the MVME2307 (MVME2700) BSP

2021-09-22 Thread Gedare Bloom
ok

On Tue, Sep 21, 2021 at 1:42 AM  wrote:
>
> From: Chris Johns 
>
> - Assumes a stand alone TFTP server
> ---
>  tester/rtems/testing/bsps/mvme2307.ini | 59 ++
>  1 file changed, 59 insertions(+)
>  create mode 100644 tester/rtems/testing/bsps/mvme2307.ini
>
> diff --git a/tester/rtems/testing/bsps/mvme2307.ini 
> b/tester/rtems/testing/bsps/mvme2307.ini
> new file mode 100644
> index 000..b142aa9
> --- /dev/null
> +++ b/tester/rtems/testing/bsps/mvme2307.ini
> @@ -0,0 +1,59 @@
> +#
> +# RTEMS Tools Project (http://www.rtems.org/)
> +# Copyright 2021 Chris Johns (chr...@rtems.org)
> +# All rights reserved.
> +#
> +# This file is part of the RTEMS Tools package in 'rtems-tools'.
> +#
> +# 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 HOLDER 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.
> +#
> +
> +#
> +# The MVME2307 BSP
> +#
> +# This BSP uses the bootloader's network autoboot to boot the board. It
> +# does nothing but sleep for the test's timeout period.
> +#
> +# You need to:
> +#
> +#  1. Set up a TFTP server and provide a suitable path to copy the
> +# bootable image to.
> +#
> +#  2. Use the `env` command to enable network autoboot:
> +#   Network Auto Boot Enable [Y/N]   = N? y
> +#
> +#  3. Provide a script to power cycle the board
> +#
> +#  4. Provide a telnet connection to the serial port
> +#
> +#  5. Create a script that converts the executable to the
> +# bootable image and copy the image to the TFTP server.
> +#
> +[mvme2307]
> +bsp= mvme2307
> +arch   = powerpc
> +jobs   = 1
> +test_restarts  = 3
> +tester = %{_rtscripts}/wait.cfg
> +target_start_regex = ^Copyright Motorola Inc.*, All Rights Reserved
> +requires   = target_on_command, target_off_command, 
> target_reset_command, bsp_tty_dev
> --
> 2.24.1
>
> ___
> 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] score: Improve variable names in thread init

2021-09-22 Thread Gedare Bloom
ok

On Tue, Sep 21, 2021 at 5:36 AM Sebastian Huber
 wrote:
>
> ---
>  cpukit/score/src/threadinitialize.c | 50 ++---
>  1 file changed, 25 insertions(+), 25 deletions(-)
>
> diff --git a/cpukit/score/src/threadinitialize.c 
> b/cpukit/score/src/threadinitialize.c
> index e10eb1af88..81199a7044 100644
> --- a/cpukit/score/src/threadinitialize.c
> +++ b/cpukit/score/src/threadinitialize.c
> @@ -101,17 +101,17 @@ static void _Thread_Initialize_scheduler_and_wait_nodes(
>const Thread_Configuration *config
>  )
>  {
> -  Scheduler_Node  *scheduler_node;
> +  Scheduler_Node  *home_scheduler_node;
>  #if defined(RTEMS_SMP)
> -  Scheduler_Node  *scheduler_node_for_index;
> -  const Scheduler_Control *scheduler_for_index;
> +  Scheduler_Node  *scheduler_node;
> +  const Scheduler_Control *scheduler;
>size_t   scheduler_index;
>  #endif
>
>  #if defined(RTEMS_SMP)
> -  scheduler_node = NULL;
> -  scheduler_node_for_index = the_thread->Scheduler.nodes;
> -  scheduler_for_index = &_Scheduler_Table[ 0 ];
> +  home_scheduler_node = NULL;
> +  scheduler_node = the_thread->Scheduler.nodes;
> +  scheduler = &_Scheduler_Table[ 0 ];
>scheduler_index = 0;
>
>/*
> @@ -121,27 +121,27 @@ static void _Thread_Initialize_scheduler_and_wait_nodes(
> * configured.
> */
>while ( scheduler_index < _Scheduler_Count ) {
> -Priority_Control priority_for_index;
> +Priority_Control priority;
>
> -if ( scheduler_for_index == config->scheduler ) {
> -  priority_for_index = config->priority;
> -  scheduler_node = scheduler_node_for_index;
> +if ( scheduler == config->scheduler ) {
> +  priority = config->priority;
> +  home_scheduler_node = scheduler_node;
>  } else {
>/*
> * Use the idle thread priority for the non-home scheduler instances by
> * default.
> */
> -  priority_for_index = _Scheduler_Map_priority(
> -scheduler_for_index,
> -scheduler_for_index->maximum_priority
> +  priority = _Scheduler_Map_priority(
> +scheduler,
> +scheduler->maximum_priority
>);
>  }
>
>  _Scheduler_Node_initialize(
> -  scheduler_for_index,
> -  scheduler_node_for_index,
> +  scheduler,
> +  scheduler_node,
>the_thread,
> -  priority_for_index
> +  priority
>  );
>
>  /*
> @@ -149,9 +149,9 @@ static void _Thread_Initialize_scheduler_and_wait_nodes(
>   * configuration, the _Scheduler_Node_size constant is used to get the 
> next
>   * scheduler node.  Using sizeof( Scheduler_Node ) would be wrong.
>   */
> -scheduler_node_for_index = (Scheduler_Node *)
> -  ( (uintptr_t) scheduler_node_for_index + _Scheduler_Node_size );
> -++scheduler_for_index;
> +scheduler_node = (Scheduler_Node *)
> +  ( (uintptr_t) scheduler_node + _Scheduler_Node_size );
> +++scheduler;
>  ++scheduler_index;
>}
>
> @@ -159,23 +159,23 @@ static void _Thread_Initialize_scheduler_and_wait_nodes(
> * The thread is initialized to use exactly one scheduler node which is
> * provided by its home scheduler.
> */
> -  _Assert( scheduler_node != NULL );
> +  _Assert( home_scheduler_node != NULL );
>_Chain_Initialize_one(
>  _thread->Scheduler.Wait_nodes,
> -_node->Thread.Wait_node
> +_scheduler_node->Thread.Wait_node
>);
>_Chain_Initialize_one(
>  _thread->Scheduler.Scheduler_nodes,
> -_node->Thread.Scheduler_node.Chain
> +_scheduler_node->Thread.Scheduler_node.Chain
>);
>  #else
>/*
> * In uniprocessor configurations, the thread has exactly one scheduler 
> node.
> */
> -  scheduler_node = _Thread_Scheduler_get_home_node( the_thread );
> +  home_scheduler_node = _Thread_Scheduler_get_home_node( the_thread );
>_Scheduler_Node_initialize(
>  config->scheduler,
> -scheduler_node,
> +home_scheduler_node,
>  the_thread,
>  config->priority
>);
> @@ -189,7 +189,7 @@ static void _Thread_Initialize_scheduler_and_wait_nodes(
> */
>_Priority_Node_initialize( _thread->Real_priority, config->priority );
>_Priority_Initialize_one(
> -_node->Wait.Priority,
> +_scheduler_node->Wait.Priority,
>  _thread->Real_priority
>);
>
> --
> 2.31.1
>
> ___
> 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] score: Simplify _Thread_Try_initialize()

2021-09-22 Thread Gedare Bloom
ok

On Tue, Sep 21, 2021 at 5:25 AM Sebastian Huber
 wrote:
>
> Move a code block to its own new function
> _Thread_Initialize_scheduler_and_wait_nodes().  Add comments.
> ---
>  cpukit/score/src/threadinitialize.c | 180 +---
>  1 file changed, 108 insertions(+), 72 deletions(-)
>
> diff --git a/cpukit/score/src/threadinitialize.c 
> b/cpukit/score/src/threadinitialize.c
> index 9c1b809c3a..e10eb1af88 100644
> --- a/cpukit/score/src/threadinitialize.c
> +++ b/cpukit/score/src/threadinitialize.c
> @@ -96,6 +96,113 @@ void _Thread_Free(
>_Objects_Free( >Objects, _thread->Object );
>  }
>
> +static void _Thread_Initialize_scheduler_and_wait_nodes(
> +  Thread_Control *the_thread,
> +  const Thread_Configuration *config
> +)
> +{
> +  Scheduler_Node  *scheduler_node;
> +#if defined(RTEMS_SMP)
> +  Scheduler_Node  *scheduler_node_for_index;
> +  const Scheduler_Control *scheduler_for_index;
> +  size_t   scheduler_index;
> +#endif
> +
> +#if defined(RTEMS_SMP)
> +  scheduler_node = NULL;
> +  scheduler_node_for_index = the_thread->Scheduler.nodes;
> +  scheduler_for_index = &_Scheduler_Table[ 0 ];
> +  scheduler_index = 0;
> +
> +  /*
> +   * In SMP configurations, the thread has exactly one scheduler node for 
> each
> +   * configured scheduler.  Initialize the scheduler nodes of each scheduler.
> +   * The application configuration ensures that we have at least one 
> scheduler
> +   * configured.
> +   */
> +  while ( scheduler_index < _Scheduler_Count ) {
> +Priority_Control priority_for_index;
> +
> +if ( scheduler_for_index == config->scheduler ) {
> +  priority_for_index = config->priority;
> +  scheduler_node = scheduler_node_for_index;
> +} else {
> +  /*
> +   * Use the idle thread priority for the non-home scheduler instances by
> +   * default.
> +   */
> +  priority_for_index = _Scheduler_Map_priority(
> +scheduler_for_index,
> +scheduler_for_index->maximum_priority
> +  );
> +}
> +
> +_Scheduler_Node_initialize(
> +  scheduler_for_index,
> +  scheduler_node_for_index,
> +  the_thread,
> +  priority_for_index
> +);
> +
> +/*
> + * Since the size of a scheduler node depends on the application
> + * configuration, the _Scheduler_Node_size constant is used to get the 
> next
> + * scheduler node.  Using sizeof( Scheduler_Node ) would be wrong.
> + */
> +scheduler_node_for_index = (Scheduler_Node *)
> +  ( (uintptr_t) scheduler_node_for_index + _Scheduler_Node_size );
> +++scheduler_for_index;
> +++scheduler_index;
> +  }
> +
> +  /*
> +   * The thread is initialized to use exactly one scheduler node which is
> +   * provided by its home scheduler.
> +   */
> +  _Assert( scheduler_node != NULL );
> +  _Chain_Initialize_one(
> +_thread->Scheduler.Wait_nodes,
> +_node->Thread.Wait_node
> +  );
> +  _Chain_Initialize_one(
> +_thread->Scheduler.Scheduler_nodes,
> +_node->Thread.Scheduler_node.Chain
> +  );
> +#else
> +  /*
> +   * In uniprocessor configurations, the thread has exactly one scheduler 
> node.
> +   */
> +  scheduler_node = _Thread_Scheduler_get_home_node( the_thread );
> +  _Scheduler_Node_initialize(
> +config->scheduler,
> +scheduler_node,
> +the_thread,
> +config->priority
> +  );
> +#endif
> +
> +  /*
> +   * The current priority of the thread is initialized to exactly the real
> +   * priority of the thread.  During the lifetime of the thread, it may gain
> +   * more priority nodes, for example through locking protocols such as
> +   * priority inheritance or priority ceiling.
> +   */
> +  _Priority_Node_initialize( _thread->Real_priority, config->priority );
> +  _Priority_Initialize_one(
> +_node->Wait.Priority,
> +_thread->Real_priority
> +  );
> +
> +#if defined(RTEMS_SMP)
> +  RTEMS_STATIC_ASSERT( THREAD_SCHEDULER_BLOCKED == 0, Scheduler_state );
> +  the_thread->Scheduler.home_scheduler = config->scheduler;
> +  _ISR_lock_Initialize( _thread->Scheduler.Lock, "Thread Scheduler" );
> +  _ISR_lock_Initialize( _thread->Wait.Lock.Default, "Thread Wait 
> Default" );
> +  _Thread_queue_Gate_open( _thread->Wait.Lock.Tranquilizer );
> +  _RBTree_Initialize_node( _thread->Wait.Link.Registry_node );
> +#endif
> +}
> +
>  static bool _Thread_Try_initialize(
>Thread_Information *information,
>Thread_Control *the_thread,
> @@ -107,12 +214,6 @@ static bool _Thread_Try_initialize(
>char*stack_begin;
>char*stack_end;
>uintptr_tstack_align;
> -  Scheduler_Node  *scheduler_node;
> -#if defined(RTEMS_SMP)
> -  Scheduler_Node  *scheduler_node_for_index;
> -  const Scheduler_Control *scheduler_for_index;
> -  size_t   scheduler_index;
> -#endif
>Per_CPU_Control *cpu = _Per_CPU_Get_by_index( 0 );
>
>memset(
> @@ -182,78 

Re: [PATCH v4] improve the format of error reporting on i386

2021-09-21 Thread Gedare Bloom
On Mon, Sep 20, 2021 at 7:34 PM zack leung  wrote:
>
>   printk(" EAX = 0%08" PRIx32 "EBX = 0%08" PRIx32 "ECX = 0%08" PRIx32 
> "EDX = 0%08" PRIx32 "\n",
> should it look like this gedare? will send once you give the ok
>
missing x's 0x%08.

>
>
> On Sun, 19 Sept 2021 at 17:42, zack leung  wrote:
>>
>> Bumo
>>
>> Il ven 17 set 2021, 19:57 zack leung  ha scritto:
>>>
>>> Where am i missing it?
>>>
>>> Zack
>>>
>>> On Fri, 17 Sept 2021 at 23:15, Gedare Bloom  wrote:
>>>>
>>>> Hi Zack,
>>>>
>>>> I think you have also missed Joel's request to add an 8-character
>>>> width specifier.
>>>>
>>>> On Thu, Sep 16, 2021 at 6:19 PM zack leung  
>>>> wrote:
>>>> >
>>>> > Thread id is now a Hex value. formatting improved for hex values
>>>> > Updates #4203
>>>> > ---
>>>> >  cpukit/score/cpu/i386/cpu.c | 6 +++---
>>>> >  1 file changed, 3 insertions(+), 3 deletions(-)
>>>> >
>>>> > diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
>>>> > index 77b7a7161c..0f17cf0148 100644
>>>> > --- a/cpukit/score/cpu/i386/cpu.c
>>>> > +++ b/cpukit/score/cpu/i386/cpu.c
>>>> > @@ -215,16 +215,16 @@ void _CPU_Exception_frame_print (const
>>>> > CPU_Exception_frame *ctx)
>>>> >  {
>>>> >unsigned int faultAddr = 0;
>>>> >
>>>> > printk("--\n");
>>>> > -  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
>>>> > PRId32 "\n",
>>>> > +  printk("Exception %" PRIu32 " caught at PC 0x%" PRIx32 " by thread 
>>>> > 0x%"
>>>> > PRIx32 "\n",
>>>> >   ctx->idtIndex,
>>>> >   ctx->eip,
>>>> >   _Thread_Executing->Object.id);
>>>> >
>>>> > printk("--\n");
>>>> >printk("Processor execution context at time of the fault was  :\n");
>>>> >
>>>> > printk("--\n");
>>>> > -  printk(" EAX = %" PRIx32 "EBX = %" PRIx32 "ECX = %" PRIx32 "
>>>> > EDX = %" PRIx32 "\n",
>>>> > +  printk(" EAX = 0x%" PRIx32 "EBX = 0x%" PRIx32 "ECX = 0x%" 
>>>> > PRIx32
>>>> > "EDX = 0x%" PRIx32 "\n",
>>>> >   ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
>>>> > -  printk(" ESI = %" PRIx32 "EDI = %" PRIx32 "EBP = %" PRIx32 "
>>>> > ESP = %" PRIx32 "\n",
>>>> > +  printk(" ESI = 0x%" PRIx32 "EDI = 0x%" PRIx32 "EBP = 0x%" 
>>>> > PRIx32
>>>> > "ESP = 0x%" PRIx32 "\n",
>>>> >   ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
>>>> >
>>>> > printk("--\n");
>>>> >printk("Error code pushed by processor itself (if not 0) = %" PRIx32
>>>> > "\n",
>>>> > --
>>>> > 2.33.0
>>>> > ___
>>>> > 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 v2 5/5] cpukit: Add AArch64 SMP Support

2021-09-20 Thread Gedare Bloom
looks good, thanks. I'll follow-up later as I make progress on the
versal smp side too. that's still a bit broken.

On Mon, Sep 20, 2021 at 4:56 PM Kinsey Moore  wrote:
>
> Version 1 of this patch did not update the Versal BSP's usage of the MMU
> calls.
>
>
> Kinsey
>
> On 9/20/2021 17:43, Kinsey Moore wrote:
> > This adds SMP support for AArch64 in cpukit and for the ZynqMP BSPs.
> > ---
> >   bsps/aarch64/include/bsp/aarch64-mmu.h| 13 ++-
> >   bsps/aarch64/shared/start/aarch64-smp.c   | 85 +++
> >   bsps/aarch64/shared/start/start.S | 12 +--
> >   .../aarch64/xilinx-versal/start/bspstartmmu.c |  4 +-
> >   bsps/aarch64/xilinx-zynqmp/include/bsp.h  |  9 ++
> >   .../xilinx-zynqmp/start/bspstarthooks.c   | 40 -
> >   .../aarch64/xilinx-zynqmp/start/bspstartmmu.c | 28 --
> >   .../cpu/aarch64/aarch64-exception-interrupt.S |  6 +-
> >   cpukit/score/cpu/aarch64/cpu_asm.S| 78 -
> >   cpukit/score/cpu/aarch64/include/rtems/asm.h  |  5 ++
> >   .../cpu/aarch64/include/rtems/score/cpu.h | 13 ++-
> >   .../cpu/aarch64/include/rtems/score/cpuimpl.h | 67 ++-
> >   spec/build/bsps/aarch64/xilinx-zynqmp/abi.yml |  2 +
> >   spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml |  2 +
> >   .../bsps/aarch64/xilinx-zynqmp/objsmp.yml | 16 
> >   spec/build/cpukit/optsmp.yml  |  4 +
> >   testsuites/smptests/smpfatal08/init.c |  2 +-
> >   17 files changed, 350 insertions(+), 36 deletions(-)
> >   create mode 100644 bsps/aarch64/shared/start/aarch64-smp.c
> >   create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/objsmp.yml
> >
> > diff --git a/bsps/aarch64/include/bsp/aarch64-mmu.h 
> > b/bsps/aarch64/include/bsp/aarch64-mmu.h
> > index e82012576f..a5f6e846f3 100644
> > --- a/bsps/aarch64/include/bsp/aarch64-mmu.h
> > +++ b/bsps/aarch64/include/bsp/aarch64-mmu.h
> > @@ -385,17 +385,14 @@ BSP_START_TEXT_SECTION static inline void 
> > aarch64_mmu_setup_translation_table(
> >   }
> >
> >   BSP_START_TEXT_SECTION static inline void
> > -aarch64_mmu_setup_translation_table_and_enable(
> > -  const aarch64_mmu_config_entry *config_table,
> > -  size_t config_count
> > -)
> > +aarch64_mmu_enable( void )
> >   {
> > uint64_t sctlr;
> >
> > -  aarch64_mmu_setup_translation_table(
> > -config_table,
> > -config_count
> > -  );
> > +  /* CPUECTLR_EL1.SMPEN is already set on ZynqMP and is not writable */
> > +
> > +  /* Invalidate cache */
> > +  rtems_cache_invalidate_entire_data();
> >
> > /* Enable MMU and cache */
> > sctlr = _AArch64_Read_sctlr_el1();
> > diff --git a/bsps/aarch64/shared/start/aarch64-smp.c 
> > b/bsps/aarch64/shared/start/aarch64-smp.c
> > new file mode 100644
> > index 00..5ec7babce7
> > --- /dev/null
> > +++ b/bsps/aarch64/shared/start/aarch64-smp.c
> > @@ -0,0 +1,85 @@
> > +/* SPDX-License-Identifier: BSD-2-Clause */
> > +
> > +/**
> > + * @file
> > + *
> > + * @ingroup RTEMSBSPsAArch64Shared
> > + *
> > + * @brief SMP startup and interop code.
> > + */
> > +
> > +/*
> > + * Copyright (C) 2021 On-Line Applications Research Corporation (OAR)
> > + * Written by Kinsey Moore 
> > + *
> > + * 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.
> > + */
> > +
> > +#include 
> > +
> > +#include 
> > +
> > +static void bsp_inter_processor_interrupt( void *arg )
> > +{
> > +  _SMP_Inter_processor_interrupt_handler( _Per_CPU_Get() );
> > +}
> > +
> > +uint32_t _CPU_SMP_Initialize( void )
> > +{
> > +  return arm_gic_irq_processor_count();
> > +}
> > +
> > +void _CPU_SMP_Finalize_initialization( uint32_t cpu_count )
> > 

Re: [PATCH v4] improve the format of error reporting on i386

2021-09-20 Thread Gedare Bloom
On Mon, Sep 13, 2021 at 5:44 PM Joel Sherrill  wrote:
>
> On Sun, Sep 12, 2021 at 7:02 PM zack leung  wrote:
> >
> > Thread id is now a Hex value.
> > Updates #4203
> > ---
> > cpukit/score/cpu/i386/cpu.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
> > index 77b7a7161c..06af57418d 100644
> > --- a/cpukit/score/cpu/i386/cpu.c
> > +++ b/cpukit/score/cpu/i386/cpu.c
> > @@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const
> > CPU_Exception_frame *ctx)
> > {
> > unsigned int faultAddr = 0;
> > printk("--\n");
> > - printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> > PRId32 "\n",
> > + printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> > PRIx32 "\n",
>
> PC and ID should use  PC 0x%08" PRIx32.
>
> Prefixing with 0x to indicate that the number is hexadecimal. Printing
> it with leading zero's and 8 digits wide helps since the address and
> thread id are 32-bit (8 nibbles).  A thread id is usually printed like
> 0x0a010004
>
Zack ^

> Does this patch have all your other changes? I've slept since seeing
> this time and thought there were changes..
>
> --joel
>
> > ctx->idtIndex,
> > ctx->eip,
> > _Thread_Executing->Object.id);
> > --
> > 2.33.0
> > ___
> > 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH v4] improve the format of error reporting on i386

2021-09-17 Thread Gedare Bloom
Hi Zack,

I think you have also missed Joel's request to add an 8-character
width specifier.

On Thu, Sep 16, 2021 at 6:19 PM zack leung  wrote:
>
> Thread id is now a Hex value. formatting improved for hex values
> Updates #4203
> ---
>  cpukit/score/cpu/i386/cpu.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
> index 77b7a7161c..0f17cf0148 100644
> --- a/cpukit/score/cpu/i386/cpu.c
> +++ b/cpukit/score/cpu/i386/cpu.c
> @@ -215,16 +215,16 @@ void _CPU_Exception_frame_print (const
> CPU_Exception_frame *ctx)
>  {
>unsigned int faultAddr = 0;
>printk("--\n");
> -  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> PRId32 "\n",
> +  printk("Exception %" PRIu32 " caught at PC 0x%" PRIx32 " by thread 0x%"
> PRIx32 "\n",
>   ctx->idtIndex,
>   ctx->eip,
>   _Thread_Executing->Object.id);
>printk("--\n");
>printk("Processor execution context at time of the fault was  :\n");
>printk("--\n");
> -  printk(" EAX = %" PRIx32 "EBX = %" PRIx32 "ECX = %" PRIx32 "
> EDX = %" PRIx32 "\n",
> +  printk(" EAX = 0x%" PRIx32 "EBX = 0x%" PRIx32 "ECX = 0x%" PRIx32
> "EDX = 0x%" PRIx32 "\n",
>   ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
> -  printk(" ESI = %" PRIx32 "EDI = %" PRIx32 "EBP = %" PRIx32 "
> ESP = %" PRIx32 "\n",
> +  printk(" ESI = 0x%" PRIx32 "EDI = 0x%" PRIx32 "EBP = 0x%" PRIx32
> "ESP = 0x%" PRIx32 "\n",
>   ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
>printk("--\n");
>printk("Error code pushed by processor itself (if not 0) = %" PRIx32
> "\n",
> --
> 2.33.0
> ___
> 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 v3] Remove automake/autoconf from rtems 6 tools

2021-09-17 Thread Gedare Bloom
this looks right, just test it before pushing :)

On Thu, Sep 16, 2021 at 1:26 PM Joel Sherrill  wrote:
>
> These are unneeded with the waf build system.
>
> Closes #4081.
> ---
>  rtems/config/6/rtems-autotools-base.bset |  9 -
>  rtems/config/6/rtems-autotools-internal.bset | 11 ---
>  rtems/config/6/rtems-autotools.bset  | 25 -
>  rtems/config/6/rtems-default.bset|  2 --
>  rtems/config/6/rtems-microblaze.bset |  2 --
>  5 files changed, 49 deletions(-)
>  delete mode 100644 rtems/config/6/rtems-autotools-base.bset
>  delete mode 100644 rtems/config/6/rtems-autotools-internal.bset
>  delete mode 100644 rtems/config/6/rtems-autotools.bset
>
> diff --git a/rtems/config/6/rtems-autotools-base.bset 
> b/rtems/config/6/rtems-autotools-base.bset
> deleted file mode 100644
> index c6819c1..000
> --- a/rtems/config/6/rtems-autotools-base.bset
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -%define release 1
> -%define rtems_arch none
> -
> -%include 6/rtems-base.bset
> -
> -package: rtems-%{rtems_version}-autotools-%{_host}-%{release}
> -
> -tools/rtems-autoconf-2.69-1
> -tools/rtems-automake-1.12.6-1
> diff --git a/rtems/config/6/rtems-autotools-internal.bset 
> b/rtems/config/6/rtems-autotools-internal.bset
> deleted file mode 100644
> index 19d2f19..000
> --- a/rtems/config/6/rtems-autotools-internal.bset
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -#
> -# Do not use via the command line.
> -#
> -
> -%define _internal_autotools yes
> -%define _disable_collecting yes
> -%define _disable_packaging  yes
> -%define _disable_reporting  yes
> -%define _disable_installing yes
> -
> -%include 6/rtems-autotools-base.bset
> diff --git a/rtems/config/6/rtems-autotools.bset 
> b/rtems/config/6/rtems-autotools.bset
> deleted file mode 100644
> index e57d25d..000
> --- a/rtems/config/6/rtems-autotools.bset
> +++ /dev/null
> @@ -1,25 +0,0 @@
> -#
> -# Autoconf and automake are not relocatable and cannot be cross-compiled.
> -# RTEMS uses autoconf and automake and building RTEMS in the RSB requires
> -# bootstrapping and this requires a current autoconf and automake. The RSB
> -# provides to support by:
> -#
> -#  1. Building and installing autoconf and automake with a prefix to a
> -# temporary internal path.
> -#  2. Using the temporary internal build, build and install another copy
> -# using the final prefix location.
> -#
> -
> -#
> -# A magic internal path that would break if changes in the defaults.mc
> -# macro file are made.
> -#
> -%define _internal_autotools_path %{_tmppath}/sb-%{_uid}/${SB_PREFIX_CLEAN}
> -
> -#
> -# Disable emailing reports of this building for RTEMS.
> -#
> -%define mail_disable
> -
> -6/rtems-autotools-internal
> -6/rtems-autotools-base
> diff --git a/rtems/config/6/rtems-default.bset 
> b/rtems/config/6/rtems-default.bset
> index 1b60066..0c07b08 100644
> --- a/rtems/config/6/rtems-default.bset
> +++ b/rtems/config/6/rtems-default.bset
> @@ -3,8 +3,6 @@
>  #
>  %include 6/rtems-base.bset
>
> -6/rtems-autotools
> -
>  #
>  # Build gdb first to raise the Python install error as early as possible.
>  # GDB needs expat so it needs to be built before.
> diff --git a/rtems/config/6/rtems-microblaze.bset 
> b/rtems/config/6/rtems-microblaze.bset
> index 4b12899..3eb7a89 100644
> --- a/rtems/config/6/rtems-microblaze.bset
> +++ b/rtems/config/6/rtems-microblaze.bset
> @@ -6,8 +6,6 @@
>  #
>  %include 6/rtems-base.bset
>
> -6/rtems-autotools
> -
>  devel/dtc-1.6.0-1
>
>  #
> --
> 1.8.3.1
>
> ___
> 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 v2] Remove automake/autoconf from rtems 6 tools

2021-09-16 Thread Gedare Bloom
On Thu, Sep 16, 2021 at 8:56 AM Joel Sherrill  wrote:
>
> These are unneeded with the waf build system.
>
> Closes #4081.
> ---
>  bare/config/devel/autotools-base.bset  |  9 -
>  bare/config/devel/autotools-internal.bset  | 13 -
>  bare/config/devel/autotools.bset   | 14 --
Not these.

>  rtems/config/6/rtems-autotools-base.bset   |  9 -
>  rtems/config/6/rtems-autotools-internal.bset   | 11 ---
>  rtems/config/6/rtems-autotools.bset| 25 -
>  rtems/config/6/rtems-default.bset  |  2 --
>  rtems/config/6/rtems-microblaze.bset   |  2 --
Just these. The rtems-autotools* ones :)

>  rtems/config/tools/rtems-autoconf-2.69-1.cfg   | 23 ---
>  rtems/config/tools/rtems-automake-1.12.6-1.cfg | 23 ---
I don't think these can be removed either, I think they're used for
the gcc-cross build.

>  10 files changed, 131 deletions(-)
>  delete mode 100644 bare/config/devel/autotools-base.bset
>  delete mode 100644 bare/config/devel/autotools-internal.bset
>  delete mode 100644 bare/config/devel/autotools.bset
>  delete mode 100644 rtems/config/6/rtems-autotools-base.bset
>  delete mode 100644 rtems/config/6/rtems-autotools-internal.bset
>  delete mode 100644 rtems/config/6/rtems-autotools.bset
>  delete mode 100644 rtems/config/tools/rtems-autoconf-2.69-1.cfg
>  delete mode 100644 rtems/config/tools/rtems-automake-1.12.6-1.cfg
>
> diff --git a/bare/config/devel/autotools-base.bset 
> b/bare/config/devel/autotools-base.bset
> deleted file mode 100644
> index 22456ed..000
> --- a/bare/config/devel/autotools-base.bset
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -#
> -# Build set for autoconf, automake, and libtools.
> -#
> -
> -%define release 1
> -
> -devel/autoconf-2.69-1
> -devel/automake-1.12.6-1
> -devel/libtool-2.4.2-1
> diff --git a/bare/config/devel/autotools-internal.bset 
> b/bare/config/devel/autotools-internal.bset
> deleted file mode 100644
> index bad3890..000
> --- a/bare/config/devel/autotools-internal.bset
> +++ /dev/null
> @@ -1,13 +0,0 @@
> -#
> -# Tools Set for Internal Autotools Stable
> -#
> -# Do not use via the command line.
> -#
> -
> -%define _internal_autotools yes
> -%define _disable_collecting yes
> -%define _disable_packaging  yes
> -%define _disable_reporting  yes
> -%define _disable_installing yes
> -
> -%include devel/autotools-base.bset
> diff --git a/bare/config/devel/autotools.bset 
> b/bare/config/devel/autotools.bset
> deleted file mode 100644
> index 5fcafa4..000
> --- a/bare/config/devel/autotools.bset
> +++ /dev/null
> @@ -1,14 +0,0 @@
> -#
> -# Build set for autoconf, automake, and libtools.
> -#
> -
> -%define release 1
> -
> -#
> -# A magic internal path that would break if changes in the defaults.mc
> -# macro file are made.
> -#
> -%define _internal_autotools_path %{_tmppath}/sb-%{_uid}/${SB_PREFIX_CLEAN}
> -
> -devel/autotools-internal.bset
> -devel/autotools-base.bset
> diff --git a/rtems/config/6/rtems-autotools-base.bset 
> b/rtems/config/6/rtems-autotools-base.bset
> deleted file mode 100644
> index c6819c1..000
> --- a/rtems/config/6/rtems-autotools-base.bset
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -%define release 1
> -%define rtems_arch none
> -
> -%include 6/rtems-base.bset
> -
> -package: rtems-%{rtems_version}-autotools-%{_host}-%{release}
> -
> -tools/rtems-autoconf-2.69-1
> -tools/rtems-automake-1.12.6-1
> diff --git a/rtems/config/6/rtems-autotools-internal.bset 
> b/rtems/config/6/rtems-autotools-internal.bset
> deleted file mode 100644
> index 19d2f19..000
> --- a/rtems/config/6/rtems-autotools-internal.bset
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -#
> -# Do not use via the command line.
> -#
> -
> -%define _internal_autotools yes
> -%define _disable_collecting yes
> -%define _disable_packaging  yes
> -%define _disable_reporting  yes
> -%define _disable_installing yes
> -
> -%include 6/rtems-autotools-base.bset
> diff --git a/rtems/config/6/rtems-autotools.bset 
> b/rtems/config/6/rtems-autotools.bset
> deleted file mode 100644
> index e57d25d..000
> --- a/rtems/config/6/rtems-autotools.bset
> +++ /dev/null
> @@ -1,25 +0,0 @@
> -#
> -# Autoconf and automake are not relocatable and cannot be cross-compiled.
> -# RTEMS uses autoconf and automake and building RTEMS in the RSB requires
> -# bootstrapping and this requires a current autoconf and automake. The RSB
> -# provides to support by:
> -#
> -#  1. Building and installing autoconf and automake with a prefix to a
> -# temporary internal path.
> -#  2. Using the temporary internal build, build and install another copy
> -# using the final prefix location.
> -#
> -
> -#
> -# A magic internal path that would break if changes in the defaults.mc
> -# macro file are made.
> -#
> -%define _internal_autotools_path %{_tmppath}/sb-%{_uid}/${SB_PREFIX_CLEAN}
> -
> -#
> -# Disable emailing reports of this building for RTEMS.
> -#
> 

Re: [PATCH v4] improve the format of error reporting on i386

2021-09-16 Thread Gedare Bloom
Hi Zack,

Although we are not currently filtering HTML on this mailing list, it
is strongly preferred that you would send plaintext email when there's
no need for the HTML features. We may disable/filter HTML in the
future, as is now done for us...@rtems.org

This email could have been as easily sent in plaintext. Make sure
anything that is PRIx32 has a 0x prepended to it.

Thanks,
Gedare

On Wed, Sep 15, 2021 at 6:26 PM zack leung  wrote:
>
>
> printk("--\n");
> printk("Exception %" PRIu32 " caught at PC 0x%" PRIx32 " by thread 0x%" 
> PRIx32 "\n",
> ctx->idtIndex,
> ctx->eip,
> _Thread_Executing->Object.id);
> printk("--\n");
> printk("Processor execution context at time of the fault was :\n");
> printk("--\n");
> printk(" EAX = %" PRIx32 " EBX = 0x%" PRIx32 " ECX = %" PRIx32 " EDX = %" 
> PRIx32 "\n",
> ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
> printk(" ESI = 0x%" PRIx32 " EDI = 0x%" PRIx32 " EBP = 0x%" PRIx32 " ESP = 
> 0x%" PRIx32 "\n",
> ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
>
>
> Before I send my patch here is what i'll change . So i can do this for 
> example format the hex values with 0x and
> have the thread id as a hex value.
>
> On Wed, 15 Sept 2021 at 15:18, Gedare Bloom  wrote:
>>
>> On Mon, Sep 13, 2021 at 6:10 PM zack leung  wrote:
>> >
>> > Gedare told me just to change the ID when I submitted the other I sent you
>> > in discord. Sorry for things bouncing back and forth.
>> >
>>
>> I said not to change the `type` of the register context variables from
>> 32 to ptr. You can change their representation to hex that's fine by
>> me, with the fixed width and 0x prepended.
>>
>> > On Mon, 13 Sept 2021 at 23:44, Joel Sherrill  wrote:
>> >
>> > > On Sun, Sep 12, 2021 at 7:02 PM zack leung 
>> > > wrote:
>> > > >
>> > > > Thread id is now a Hex value.
>> > > > Updates #4203
>> > > > ---
>> > > > cpukit/score/cpu/i386/cpu.c | 2 +-
>> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
>> > > >
>> > > > diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
>> > > > index 77b7a7161c..06af57418d 100644
>> > > > --- a/cpukit/score/cpu/i386/cpu.c
>> > > > +++ b/cpukit/score/cpu/i386/cpu.c
>> > > > @@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const
>> > > > CPU_Exception_frame *ctx)
>> > > > {
>> > > > unsigned int faultAddr = 0;
>> > > > printk("--\n");
>> > > > - printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
>> > > > PRId32 "\n",
>> > > > + printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
>> > > > PRIx32 "\n",
>> > >
>> > > PC and ID should use  PC 0x%08" PRIx32.
>> > >
>> > > Prefixing with 0x to indicate that the number is hexadecimal. Printing
>> > > it with leading zero's and 8 digits wide helps since the address and
>> > > thread id are 32-bit (8 nibbles).  A thread id is usually printed like
>> > > 0x0a010004
>> > >
>> > > Does this patch have all your other changes? I've slept since seeing
>> > > this time and thought there were changes..
>> > >
>> > > --joel
>> > >
>> > > > ctx->idtIndex,
>> > > > ctx->eip,
>> > > > _Thread_Executing->Object.id);
>> > > > --
>> > > > 2.33.0
>> > > > ___
>> > > > 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH RSB] Remove automake/autoconf from rtems 6 tools

2021-09-16 Thread Gedare Bloom
Hi Joel,

On Thu, Sep 16, 2021 at 8:42 AM Joel Sherrill  wrote:
>
> These are unneeded with the waf build system.
>
> Closes #4081.

You should also git rm the rtems-autotools* files?


> ---
>  rtems/config/6/rtems-default.bset| 2 --
>  rtems/config/6/rtems-microblaze.bset | 2 --
>  2 files changed, 4 deletions(-)
>
> diff --git a/rtems/config/6/rtems-default.bset 
> b/rtems/config/6/rtems-default.bset
> index 1b60066..0c07b08 100644
> --- a/rtems/config/6/rtems-default.bset
> +++ b/rtems/config/6/rtems-default.bset
> @@ -3,8 +3,6 @@
>  #
>  %include 6/rtems-base.bset
>
> -6/rtems-autotools
> -
>  #
>  # Build gdb first to raise the Python install error as early as possible.
>  # GDB needs expat so it needs to be built before.
> diff --git a/rtems/config/6/rtems-microblaze.bset 
> b/rtems/config/6/rtems-microblaze.bset
> index 4b12899..3eb7a89 100644
> --- a/rtems/config/6/rtems-microblaze.bset
> +++ b/rtems/config/6/rtems-microblaze.bset
> @@ -6,8 +6,6 @@
>  #
>  %include 6/rtems-base.bset
>
> -6/rtems-autotools
> -
>  devel/dtc-1.6.0-1
>
>  #
> --
> 1.8.3.1
>
> ___
> 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 v1] bsps/riscv: Give enough time for clock driver initialization

2021-09-15 Thread Gedare Bloom
On Thu, Sep 9, 2021 at 2:39 AM  wrote:
>
> Sorry, for digging out this old patch.
>
> > On Mon, Jun 7, 2021 at 1:57 PM  wrote:
> >
> >
> > > -----Original Message-
> > > From: Gedare Bloom 
> > > Sent: Monday, June 7, 2021 7:00 PM
> > > To: Sommer, Jan 
> > > Cc: devel@rtems.org
> > > Subject: Re: [PATCH v1] bsps/riscv: Give enough time for clock driver
> > > initialization
> > >
> > > On Mon, Jun 7, 2021 at 9:47 AM Jan Sommer  wrote:
> > > >
> > > > - Clock driver initialization for secondary cores had to take less
> > > > than one tick
> > > > - If tick time is small (i.e. <= 1ms) setting up all cores could take
> > > > too long and a fatal error is thrown.
> > > > - Give at least 10 ms time for clock initialization to avoid this
> > > > error
> > >
> > > Is there a reason to pick 10?
> > >
> >
> > In qemu I (coarsely) measured 1.5ms for 8 cores.
> > So I thought this should add enough buffer to prevent a fatal error.
> > I probably could also reduce it to 5 ms.
> >
> > > I assume this blocks/idles the system until the interval elapses, so it 
> > > would be
> > > good to minimize waste (subject to Joel's noted rant about premature
> > > optimization).
> > >
> >
> > No. I'm more worried about boot time. :)
> >
>
> Would a few milliseconds be acceptable?
>

Is there any way to poll?

I'm not totally clear on the boot vs secondary processor
initialization sequence, and how closely they need to synchronize at
this stage.

What hardware do you have this problem with?

> >
> >
> > If you take a look at the clock initialization of the secondary cores 
> > (https://git.rtems.org/rtems/tree/bsps/riscv/riscv/clock/clockdrv.c#n178):
> >
> > _SMP_Othercast_action(riscv_clock_secondary_action, );
> >
> >   if (cmpval - riscv_clock_read_mtime(>mtime) >= interval) {
> > bsp_fatal(RISCV_FATAL_CLOCK_SMP_INIT);
> >   }
> >
> > It will put the first clock tick 10ms into the future (instead of just one 
> > tick), but it won't block the system initialization.
> > It only prevents entering the if condition by having a large enough value 
> > for interval, but the runtime of the clock initialization is the same.
> >
> > How does this impact the timeline for boot to first application thread?
> >
> > Is there a period where the system is up but only one core?
> >
> > Any other oddities I might be missing?
> >
>
> The main effect this has is that the interrupt of the first tick is delayed 
> by a few milliseconds, so that there is enough time for the timers of all 
> cores to initialize, even for configurations with short tick intervals.
> This should have a similar behavior as if the tick time itself would be long 
> (i.e. multiple milliseconds).
>
> Maybe, an alternative solution would be to do this in the 
> "riscv_clock_secondary_initialization".
> If the condition there (see below) fails, try again with a longer time 
> interval for the clock initialization and only fail if that didn't help 
> either.
> Then, it would not affect the situation where everything works fine right now 
> and just add a small penalty to the setups where it currently fails.
> Would this be acceptable?
>
>   178 static void riscv_clock_secondary_initialization(
>   179   volatile RISCV_CLINT_regs *clint,
>   180   uint64_t cmpval,
>   181   uint32_t interval
>   182 )
>   183 {
>   184 #if defined(RTEMS_SMP) && !defined(CLOCK_DRIVER_USE_ONLY_BOOT_PROCESSOR)
>   185   _SMP_Othercast_action(riscv_clock_secondary_action, );
>   186
>   187   if (cmpval - riscv_clock_read_mtime(>mtime) >= interval) {
>   188 bsp_fatal(RISCV_FATAL_CLOCK_SMP_INIT);
>   189   }
>   190 #endif
>   191 }
>
> Best regards,
>
> Jan
>
> > > > ---
> > > >  bsps/riscv/riscv/clock/clockdrv.c | 8 +++-
> > > >  1 file changed, 7 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/bsps/riscv/riscv/clock/clockdrv.c
> > > > b/bsps/riscv/riscv/clock/clockdrv.c
> > > > index 3afe86576f..102137aeab 100644
> > > > --- a/bsps/riscv/riscv/clock/clockdrv.c
> > > > +++ b/bsps/riscv/riscv/clock/clockdrv.c
> > > > @@ -211,7 +211,13 @@ static void riscv_clock_initialize(void)
> > > >tc->interval = interval;
> > > >
> > > >cmpval = riscv_clock_read_mtime(>mtime);
> > > > -  cmpval += int

Re: [PATCH] rtems: Fix message manager documentation

2021-09-15 Thread Gedare Bloom
ok

On Wed, Sep 15, 2021 at 3:48 AM Sebastian Huber
 wrote:
>
> Correct the description of the ``count`` parameter of
> rtems_message_queue_flush().
>
> Update #4508.
> ---
>  cpukit/include/rtems/rtems/message.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/cpukit/include/rtems/rtems/message.h 
> b/cpukit/include/rtems/rtems/message.h
> index f288d94445..28014f325e 100644
> --- a/cpukit/include/rtems/rtems/message.h
> +++ b/cpukit/include/rtems/rtems/message.h
> @@ -859,8 +859,8 @@ rtems_status_code rtems_message_queue_get_number_pending(
>   * @param id is the queue identifier.
>   *
>   * @param[out] count is the pointer to an uint32_t object.  When the 
> directive
> - *   call is successful, the number of unblocked tasks will be stored in this
> - *   object.
> + *   call is successful, the number of pending messages removed from the 
> queue
> + *   will be stored in this object.
>   *
>   * This directive removes all pending messages from the queue specified by
>   * ``id``.  The number of messages removed is returned in ``count``.  If no
> --
> 2.31.1
>
> ___
> 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 v2] c-user: Define lower and higher priority

2021-09-15 Thread Gedare Bloom
On Tue, Sep 14, 2021 at 10:21 AM Sebastian Huber
 wrote:
>
> ---
>  c-user/glossary.rst | 37 -
>  1 file changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/c-user/glossary.rst b/c-user/glossary.rst
> index 16a8b8d..94bf773 100644
> --- a/c-user/glossary.rst
> +++ b/c-user/glossary.rst
> @@ -398,6 +398,10 @@ Glossary
>  heterogeneous
>  A multiprocessor computer system composed of dissimilar processors.
>
> +higher priority
> +A :term:`task` ``H`` has a higher :term:`priority` than a task 
> ``L``, if
> +task ``H`` is more important than task ``L``.
> +
>  home scheduler
>  The home scheduler of a :term:`task` is a :term:`scheduler` which is 
> an
>  :term:`eligible scheduler` and which is assigned to the task during 
> its
> @@ -498,6 +502,10 @@ Glossary
>  A multiprocessor configuration where shared memory is not used for
>  communication.
>
> +lower priority
> +A :term:`task` ``L`` has a lower :term:`priority` than a task ``H``, 
> if
> +task ``L`` is less important than task ``H``.
> +
>  major number
>  The index of a device driver in the Device Driver Table.
>
> @@ -664,8 +672,22 @@ Glossary
>
>  priority
>  The priority is a mechanism used to represent the relative 
> importance of an
> -element in a set of items.  RTEMS uses :term:`task priorities  priority>` to determine
> -which :term:`task` should execute.
> +element in a set of items.
> +
> +For example, :term:`RTEMS` uses :term:`task priorities  priority>` to determine which
> +:term:`task` should execute on a processor.  In RTEMS, priorities are
> +represented by non-negative integers.
> +
> +For the Classic :term:`API`, if a numerical priority value ``A`` is 
> greater
> +than a numerical priority value ``B``, then ``A`` expresses a
> +:term:`higher priority` than ``B``.  If a numerical priority value 
> ``C`` is
> +less than a numerical priority value ``D``, then ``C`` expresses a
> +:term:`lower priority` than ``D``.
> +
> +For the :term:`POSIX` API, if a numerical priority value ``R`` is 
> less than
> +a numerical priority value ``S``, then ``R`` expresses a lower 
> priority than
> +``S``.  If a numerical priority value ``T`` is greater than a 
> numerical
> +priority value ``U``, then ``T`` expresses a higher priority than 
> ``U``.
>

These are backwards. Classic priorities with numerically greater
values indicate lower priorities. POSIX priorities with numerically
higher values express higher priorities.

>  priority boosting
>  A simple approach to extend the priority inheritance protocol for
> @@ -999,13 +1021,18 @@ Glossary
>  and resumes execution on another processor.
>
>  task priority
> -A task priority of a :term:`task` determines its importance relative 
> to
> -other tasks.  The scheduler use task priorities to determine which
> -:term:`ready task` gets a processor allocated, see :term:`scheduled 
> task`.  The
> +A task :term:`priority` of a :term:`task` determines its importance
> +relative to other tasks.
> +
> +The scheduler use task priorities to determine which :term:`ready 
> task` gets
> +a processor allocated, see :term:`scheduled task`.  The
>  :term:`eligible priorities ` of a task define the 
> position of the task in a
>  :term:`wait queue` which uses the priority discipline.  Each task 
> has at
>  least the :term:`real priority`.
>
> +Task priorities are used in :term:`wait queues ` which 
> use the priority
> +discipline to determine the dequeueing order of tasks.
> +
>  task processor affinity
>  The set of processors on which a task is allowed to execute.
>
> --
> 2.31.1
>
> ___
> 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 v4] improve the format of error reporting on i386

2021-09-15 Thread Gedare Bloom
On Mon, Sep 13, 2021 at 6:10 PM zack leung  wrote:
>
> Gedare told me just to change the ID when I submitted the other I sent you
> in discord. Sorry for things bouncing back and forth.
>

I said not to change the `type` of the register context variables from
32 to ptr. You can change their representation to hex that's fine by
me, with the fixed width and 0x prepended.

> On Mon, 13 Sept 2021 at 23:44, Joel Sherrill  wrote:
>
> > On Sun, Sep 12, 2021 at 7:02 PM zack leung 
> > wrote:
> > >
> > > Thread id is now a Hex value.
> > > Updates #4203
> > > ---
> > > cpukit/score/cpu/i386/cpu.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
> > > index 77b7a7161c..06af57418d 100644
> > > --- a/cpukit/score/cpu/i386/cpu.c
> > > +++ b/cpukit/score/cpu/i386/cpu.c
> > > @@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const
> > > CPU_Exception_frame *ctx)
> > > {
> > > unsigned int faultAddr = 0;
> > > printk("--\n");
> > > - printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> > > PRId32 "\n",
> > > + printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %"
> > > PRIx32 "\n",
> >
> > PC and ID should use  PC 0x%08" PRIx32.
> >
> > Prefixing with 0x to indicate that the number is hexadecimal. Printing
> > it with leading zero's and 8 digits wide helps since the address and
> > thread id are 32-bit (8 nibbles).  A thread id is usually printed like
> > 0x0a010004
> >
> > Does this patch have all your other changes? I've slept since seeing
> > this time and thought there were changes..
> >
> > --joel
> >
> > > ctx->idtIndex,
> > > ctx->eip,
> > > _Thread_Executing->Object.id);
> > > --
> > > 2.33.0
> > > ___
> > > 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH] eng: Add register block specification types

2021-09-11 Thread Gedare Bloom
On Fri, Sep 10, 2021 at 8:41 AM Sebastian Huber
 wrote:
>
> A register block may be used to specify the memory-mapped interface to
> the hardware.  Register blocks consist of register block members.
> Register block members are either instances of registers or instances of
> other register blocks.  Registers consists of bit fields.
>
> Update #3715.
> ---
> For examples see:
>
> https://git.rtems.org/rtems-central/tree/spec/dev/grlib/if
>
>  eng/req/items.rst | 334 ++
>  1 file changed, 334 insertions(+)
>
> diff --git a/eng/req/items.rst b/eng/req/items.rst
> index 1489f19..be6ab5f 100644
> --- a/eng/req/items.rst
> +++ b/eng/req/items.rst
> @@ -103,6 +103,8 @@ The specification item types have the following hierarchy:
>
>  * :ref:`SpecTypeInterfaceVariableItemType`
>
> +* :ref:`SpecTypeRegisterBlockItemType`
> +
>* :ref:`SpecTypeRequirementItemType`
>
>  * :ref:`SpecTypeFunctionalRequirementItemType`
> @@ -1143,6 +1145,8 @@ This type is refined by the following types:
>
>  * :ref:`SpecTypeInterfaceVariableItemType`
>
> +* :ref:`SpecTypeRegisterBlockItemType`
> +
>  .. _SpecTypeApplicationConfigurationGroupItemType:
>
>  Application Configuration Group Item Type
> @@ -1614,6 +1618,67 @@ name
>  notes
>  The attribute value shall be an :ref:`SpecTypeInterfaceNotes`.
>
> +.. _SpecTypeRegisterBlockItemType:
> +
> +Register Block Item Type
> +
> +
> +This type refines the :ref:`SpecTypeInterfaceItemType` through the
> +``interface-type`` attribute if the value is ``register-block``. This set of
> +attributes specifies a register block.  A register block may be used to 
> specify
> +the memory-mapped interface to the hardware.  Register blocks consist of
> +register block members specified by the ``definition`` attribute.  Register
> +block members are either instances of registers specified by the 
> ``registers``
> +attribute or instances of other register blocks specified by links with the
> +:ref:`SpecTypeRegisterBlockIncludeRole`.  Registers consists of bit fields 
> (see
> +:ref:`SpecTypeRegisterBitsDefinition`. All explicit attributes shall be
> +specified. The explicit attributes for this type are:
> +
> +brief
> +The attribute value shall be an :ref:`SpecTypeInterfaceBriefDescription`.
> +
> +definition
> +The attribute value shall be a list. Each list element shall be a
> +:ref:`SpecTypeRegisterBlockMemberDefinitionDirective`.
> +
> +description
> +The attribute value shall be an :ref:`SpecTypeInterfaceDescription`.
> +
> +identifier
> +The attribute value shall be an :ref:`SpecTypeInterfaceGroupIdentifier`.
> +
> +name
> +The attribute value shall be a string. It shall be the name of the 
> register
> +block.
> +
> +notes
> +The attribute value shall be an :ref:`SpecTypeInterfaceNotes`.
> +
> +register-block-group
> +The attribute value shall be a string. It shall be the name of the
> +interface group defined for the register block.  For the group identifier
> +see the ``identifier`` attribute.
> +
> +register-block-size
> +The attribute value shall be an integer number. It shall be the size in
> +bytes of the register block.
> +
> +register-block-type
> +The attribute value shall be a :ref:`SpecTypeRegisterBlockType`.
> +
> +register-prefix
> +The attribute value shall be an optional string. If the value is present,
> +then it will be used to prefix register bit field names, otherwise the
> +value of the ``name`` attribute will be used.
> +
> +registers
> +The attribute value shall be a list. Each list element shall be a
> +:ref:`SpecTypeRegisterDefinition`.
> +
> +In addition to the explicit attributes, generic attributes may be specified.
> +Each generic attribute key shall be a :ref:`SpecTypeName`. The attribute 
> value
> +may have any type.
> +
>  .. _SpecTypeRequirementItemType:
>
>  Requirement Item Type
> @@ -3733,6 +3798,12 @@ This type is used by the following types:
>
>  * :ref:`SpecTypeInterfaceVariableItemType`
>
> +* :ref:`SpecTypeRegisterBitsDefinition`
> +
> +* :ref:`SpecTypeRegisterBlockItemType`
> +
> +* :ref:`SpecTypeRegisterDefinition`
> +
>  .. _SpecTypeInterfaceCompoundDefinitionKind:
>
>  Interface Compound Definition Kind
> @@ -3992,6 +4063,12 @@ This type is used by the following types:
>
>  * :ref:`SpecTypeInterfaceVariableItemType`
>
> +* :ref:`SpecTypeRegisterBitsDefinition`
> +
> +* :ref:`SpecTypeRegisterBlockItemType`
> +
> +* :ref:`SpecTypeRegisterDefinition`
> +
>  .. _SpecTypeInterfaceEnabledByExpression:
>
>  Interface Enabled-By Expression
> @@ -4041,6 +4118,10 @@ This type is used by the following types:
>
>  * :ref:`SpecTypeInterfaceFunctionDefinitionVariant`
>
> +* :ref:`SpecTypeRegisterBitsDefinitionVariant`
> +
> +* :ref:`SpecTypeRegisterBlockMemberDefinitionVariant`
> +
>  .. _SpecTypeInterfaceEnumDefinitionKind:
>
>  Interface Enum Definition Kind
> @@ -4182,6 +4263,8 @@ This type is used by the 

Re: Subject: [PATCH] improve the format error reporting on i386

2021-09-10 Thread Gedare Bloom
Hi Zack,

Use git-rebase --interactive option, and reword the commit message.
The email comes through with an additional subject line, I'm not sure
if that is intended. You don't need to repeat the first line of the
commit message. It seems like the commit message you have used is:
---
improve the format error reporting on i386
score/i386: improve the format of exception reporting

Updates #4203."Updates #4203."
---
You should modify that commit message, and regenerate the patch/email.

-Gedare

On Fri, Sep 10, 2021 at 7:07 AM zack leung  wrote:
>
> Where are the duplicates been trying to fix the commit messages?
>
>  Thanks zack
> Il gio 9 set 2021, 22:30 Gedare Bloom  ha scritto:
>>
>> Hi Zack,
>>
>> It looks like something got a little messed up with your commit
>> message. Please see if you can fix it to remove the duplication(s).
>>
>> On Thu, Sep 9, 2021 at 6:00 PM zack leung  wrote:
>> >
>> > score/i386: improve the format of exception reporting
>> >
>> > Updates #4203."Updates #4203."
>> > ---
>> > cpukit/score/cpu/i386/cpu.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
>> > index 77b7a7161c..06af57418d 100644
>> > --- a/cpukit/score/cpu/i386/cpu.c
>> > +++ b/cpukit/score/cpu/i386/cpu.c
>> > @@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const 
>> > CPU_Exception_frame *ctx)
>> > {
>> > unsigned int faultAddr = 0;
>> > printk("--\n");
>> > - printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %" 
>> > PRId32 "\n",
>> > + printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %" 
>> > PRIx32 "\n",
>> > ctx->idtIndex,
>> > ctx->eip,
>> > _Thread_Executing->Object.id);
>> > --
>> > 2.33.0
>> > ___
>> > 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: Subject: [PATCH] improve the format error reporting on i386

2021-09-09 Thread Gedare Bloom
Hi Zack,

It looks like something got a little messed up with your commit
message. Please see if you can fix it to remove the duplication(s).

On Thu, Sep 9, 2021 at 6:00 PM zack leung  wrote:
>
> score/i386: improve the format of exception reporting
>
> Updates #4203."Updates #4203."
> ---
> cpukit/score/cpu/i386/cpu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
> index 77b7a7161c..06af57418d 100644
> --- a/cpukit/score/cpu/i386/cpu.c
> +++ b/cpukit/score/cpu/i386/cpu.c
> @@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const 
> CPU_Exception_frame *ctx)
> {
> unsigned int faultAddr = 0;
> printk("--\n");
> - printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %" PRId32 
> "\n",
> + printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %" PRIx32 
> "\n",
> ctx->idtIndex,
> ctx->eip,
> _Thread_Executing->Object.id);
> --
> 2.33.0
> ___
> 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] rtems: Generate

2021-09-09 Thread Gedare Bloom
This looks ok, but I am reminded that maybe the API for cache coherent
allocations is not well-defined in case the BSP doesn't support
coherent allocation. That's a separate, but related concern.

On Wed, Sep 8, 2021 at 11:58 AM Sebastian Huber
 wrote:
>
> Change license to BSD-2-Clause according to file histories and
> documentation re-licensing agreement.
>
> Update #3899.
> Update #3993.
> ---
>  cpukit/include/rtems/rtems/cache.h | 688 ++---
>  1 file changed, 532 insertions(+), 156 deletions(-)
>
> diff --git a/cpukit/include/rtems/rtems/cache.h 
> b/cpukit/include/rtems/rtems/cache.h
> index dfcb8f64d1..843d1ef99a 100644
> --- a/cpukit/include/rtems/rtems/cache.h
> +++ b/cpukit/include/rtems/rtems/cache.h
> @@ -1,294 +1,670 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
>  /**
>   * @file
>   *
> - * @ingroup ClassicCache
> + * @brief This header file defines the Cache Manager API.
> + */
> +
> +/*
> + * Copyright (C) 2016 Pavel Pisa
> + * Copyright (C) 2014, 2021 embedded brains GmbH 
> (http://www.embedded-brains.de)
> + * Copyright (C) 2000, 2008 On-Line Applications Research Corporation (OAR)
> + *
> + * 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.
>   */
>
> -/* COPYRIGHT (c) 1989-2013.
> - * On-Line Applications Research Corporation (OAR).
> +/*
> + * This file is part of the RTEMS quality process and was automatically
> + * generated.  If you find something that needs to be fixed or
> + * worded better please post a report or patch to an RTEMS mailing list
> + * or raise a bug report:
> + *
> + * https://www.rtems.org/bugs.html
>   *
> - * 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.
> + * For information on updating and regenerating please refer to the How-To
> + * section in the Software Requirements Engineering chapter of the
> + * RTEMS Software Engineering manual.  The manual is provided as a part of
> + * a release.  For development sources please refer to the online
> + * documentation at:
> + *
> + * https://docs.rtems.org
>   */
>
> +/* Generated from spec:/rtems/cache/if/header */
> +
>  #ifndef _RTEMS_RTEMS_CACHE_H
>  #define _RTEMS_RTEMS_CACHE_H
>
> -#include 
> -
> -#if defined( RTEMS_SMP )
> -#include 
> -#endif
> +#include 
> +#include 
>
>  #ifdef __cplusplus
>  extern "C" {
>  #endif
>
> +/* Generated from spec:/rtems/cache/if/group */
> +
>  /**
> - * @defgroup ClassicCache Cache
> + * @defgroup RTEMSAPIClassicCache Cache Manager
>   *
>   * @ingroup RTEMSAPIClassic
>   *
>   * @brief The Cache Manager provides functions to perform maintenance
> - * operations for data and instruction caches.
> + *   operations for data and instruction caches.
>   *
>   * The actual actions of the Cache Manager operations depend on the hardware
>   * and the implementation provided by the CPU architecture port or a board
>   * support package.  Cache implementations tend to be highly hardware
>   * dependent.
> - *
> - * @{
>   */
>
> +/* Generated from spec:/rtems/cache/if/aligned-malloc */
> +
>  /**
> - * @brief Returns the data cache line size in bytes.
> + * @ingroup RTEMSAPIClassicCache
>   *
> - * For multi-level caches this is the maximum of the cache line sizes of all
> - * levels.
> + * @brief Allocates memory from the C Program Heap which begins at a cache 
> line
> + *   boundary.
>   *
> - * @retval 0 No data cache is present.
> - * @retval positive The data cache line size in bytes.
> - */
> -size_t rtems_cache_get_data_line_size( void );
> -
> -/**
> - * @brief Returns the instruction cache line size in bytes.
> + * @param size is the size in 

Re: [PATCH] improve the format of error reporting on i386

2021-09-09 Thread Gedare Bloom
On Wed, Sep 8, 2021 at 6:02 PM zack leung  wrote:
>
> Thread ID is now  a hex value part of ticket #4203
>
Please add

Updates #4203.

To your commit message, on it's own line separated from the rest of
the commit message by a blank line.

The first part of your commit message should indicate the component
affected, e.g.,
"score/i386: improve the format of exception reporting

Updates #4203."

>
> On Wed, 8 Sept 2021 at 23:58, Zacchaeus Leung  
> wrote:
>>
>> diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
>> index 77b7a7161c..06af57418d 100644
>> --- a/cpukit/score/cpu/i386/cpu.c
>> +++ b/cpukit/score/cpu/i386/cpu.c
>> @@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const 
>> CPU_Exception_frame *ctx)
>>  {
>>unsigned int faultAddr = 0;
>>printk("--\n");
>> -  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %" 
>> PRId32 "\n",
>> +  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %" 
>> PRIx32 "\n",
>>  ctx->idtIndex,
>>  ctx->eip,
>>  _Thread_Executing->Object.id);
>> --
>> 2.33.0
>>
> ___
> 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] improve the format error reporting on i386

2021-09-08 Thread Gedare Bloom
On Tue, Sep 7, 2021 at 6:17 PM Zacchaeus Leung  wrote:
>
> ---
>  cpukit/score/cpu/i386/cpu.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/cpukit/score/cpu/i386/cpu.c b/cpukit/score/cpu/i386/cpu.c
> index 77b7a7161c..3c5b7db316 100644
> --- a/cpukit/score/cpu/i386/cpu.c
> +++ b/cpukit/score/cpu/i386/cpu.c
> @@ -215,7 +215,7 @@ void _CPU_Exception_frame_print (const 
> CPU_Exception_frame *ctx)
>  {
>unsigned int faultAddr = 0;
>printk("--\n");
> -  printk("Exception %" PRIu32 " caught at PC %" PRIx32 " by thread %" PRId32 
> "\n",
> +  printk("Exception %" PRIu32 " caught at PC %p" " by thread 0x%" PRIx32 
> "\n",

The fields of the ctx are uint32_t type, so I don't think changing the
format to %p is correct. Please submit just with the thread ID printed
in hex.

>  ctx->idtIndex,
>  ctx->eip,
>  _Thread_Executing->Object.id);
> @@ -224,7 +224,7 @@ void _CPU_Exception_frame_print (const 
> CPU_Exception_frame *ctx)
>printk("--\n");
>printk(" EAX = %" PRIx32 "   EBX = %" PRIx32 "   ECX = %" PRIx32 " 
>   EDX = %" PRIx32 "\n",
>  ctx->eax, ctx->ebx, ctx->ecx, ctx->edx);
> -  printk(" ESI = %" PRIx32 "   EDI = %" PRIx32 "   EBP = %" PRIx32 " 
>   ESP = %" PRIx32 "\n",
> +  printk(" ESI = %" PRIx32 "   EDI = %" PRIx32 "   EBP = %p" " ESP = 
> %p" "\n",

Ditto.

>  ctx->esi, ctx->edi, ctx->ebp, ctx->esp0);
>printk("--\n");
>printk("Error code pushed by processor itself (if not 0) = %" PRIx32 "\n",
> @@ -250,7 +250,7 @@ void _CPU_Exception_frame_print (const 
> CPU_Exception_frame *ctx)
> printk("Call Stack Trace of EIP:\n");
> if ( fp ) {
> for ( i=1; fp->up; fp=fp->up, i++ ) {
> -   printk("0x%08" PRIx32 " ",fp->pc);
> +   printk("0x%08"PRIx32 " ",fp->pc);
what's this change for?

> if ( ! (i&3) )
> printk("\n");
> }
> --
> 2.33.0
>
> ___
> 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: Ticket 4503

2021-09-08 Thread Gedare Bloom
Hi Zack,

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

The malloc implementation exists in the score as the Heap Manager. search
for "Heap_" within cpukit to get some ideas where to look.

@Joel are these two tickets duplicates?
https://devel.rtems.org/ticket/4503
https://devel.rtems.org/ticket/4271

-Gedare

On Tue, Sep 7, 2021 at 7:14 PM zack leung  wrote:

> I was wondering about ticket 4503. I was wondering where The required
> functionality should be in the underlying score/ capability used can be
> found to write this function. Also how does this relate  to
>
> Add common malloc family extension method malloc_usable_size()
> ?
> Thanks
> Zack
> ___
> 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: Does the arm/xilinx-zynqmp BSP work?

2021-09-07 Thread Gedare Bloom
Hi Chris,

What I understand about the arm/xilinx-zynqmp BSP is that it was made
to run RTEMS paravirtualized under Xen. It drops into aarch32 mode. It
probably can be replaced by the aarch64 version using the ilp32 once
that is stable, and someone can confirm the PV use case works.

Gedare

On Fri, Sep 3, 2021 at 9:51 PM Chris Johns  wrote:
>
> Hi,
>
> I am testing the console driver with the aarch64/xilinx_zynqmp_lp64_zu3eg BSP
> when I saw the BSP.
>
> Is this BSP still valid?
>
> Does this BSP work on real hardware?
>
> Who is looking after this BSP?
>
> Chris
> ___
> 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 v2 2/2] rtems-gcc-head-newlib-head.cfg: Add newlib patch

2021-09-07 Thread Gedare Bloom
Has this issue been raised with newlib? I didn't see anything on their
ml. The temporary workaround is fine with me.

On Fri, Sep 3, 2021 at 11:17 AM Ryan Long  wrote:
>
> Adds patch to add the -DPREFER_SIZE_OVER_SPEED flag to AArch64 tools
> builds with newlib. This forces the generation of AArch64 assembly from
> C sources instead of using the hand-optimized code in newlib since it
> does not support ILP32. This can be removed when it is fixed upstream.
>
> Updates #4510
> ---
>  rtems/config/tools/rtems-gcc-head-newlib-head.cfg | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg 
> b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
> index 4939ca5..c17895b 100644
> --- a/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
> +++ b/rtems/config/tools/rtems-gcc-head-newlib-head.cfg
> @@ -12,6 +12,9 @@
>  %define newlib_expand_name sourceware-mirror-newlib-cygwin-%{newlib_version}
>  %source set newlib --rsb-file=newlib-%{newlib_version}.tar.gz 
> https://codeload.github.com/RTEMS/sourceware-mirror-newlib-cygwin/tar.gz/%{newlib_version}
>  %hash sha512 newlib-%{newlib_version}.tar.gz 
> 9ded46b3077508ef05bbb4bf424777a0baa5aab9c7c0c902fb5529bb73b5b5034c35282e2dbf270cbcd44d84940a20ee270e329db4e4b501046978c18f78a11c
> +%
> +%patch add newlib -p1 
> https://devel.rtems.org/raw-attachment/ticket/4510/0001-configure.host-Add-DPREFER_SIZE_OVER_SPEED.patch
> +%hash sha512 0001-configure.host-Add-DPREFER_SIZE_OVER_SPEED.patch 
> rRg7bJoWjR11FQXmSHPxF8EfsFmBnTQcXXFWGZhbKFwyTvJ8EXfGMACI33u+OuvX+gNANMOJLyv27FcyTJseKg==
>
>  %define with_threads 1
>  %define with_plugin 0
> --
> 1.8.3.1
>
> ___
> 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] TraceWriterQEMU.cc: Change strncpy to memcpy

2021-09-01 Thread Gedare Bloom
On Thu, Aug 19, 2021 at 7:42 AM Ryan Long  wrote:
>
> CID 1506207: Buffer not null terminated
>
> Closes #4491
> ---
>  tester/covoar/TraceWriterQEMU.cc | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/tester/covoar/TraceWriterQEMU.cc 
> b/tester/covoar/TraceWriterQEMU.cc
> index c417745..be9b6e1 100644
> --- a/tester/covoar/TraceWriterQEMU.cc
> +++ b/tester/covoar/TraceWriterQEMU.cc
> @@ -106,7 +106,10 @@ namespace Trace {
>  //
>  //  Write the Header to the file
>  //
> -strncpy( header.magic, QEMU_TRACE_MAGIC, sizeof(header.magic) );
> +// The header.magic field is actually 12 bytes, but QEMU_TRACE_MAGIC is
> +// 13 bytes including the NULL.
> +const char qemu_trace_magic[13] = QEMU_TRACE_MAGIC;
> +memcpy( header.magic, qemu_trace_magic, sizeof(header.magic) );

Just to clarify, the header.magic should not be NULL terminated?

If so, then this is fine, but I don't think the temporary local
variable is needed though.
memcpy( header.magic, QEMU_TRACE_MAGIC, sizeof(header.magic) );
should work fine.

>  header.version = QEMU_TRACE_VERSION;
>  header.kind= QEMU_TRACE_KIND_RAW;  // XXX ??
>  header.sizeof_target_pc = 32;
> --
> 1.8.3.1
>
> ___
> 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 rtems-tools v1 4/4] ObjdumpProcessor.h: Remove inputBuffer_m

2021-09-01 Thread Gedare Bloom
On Wed, Sep 1, 2021 at 2:00 PM Ryan Long  wrote:
>
> Accidentally got left in, so it is being removed.
>
Change the commit message to say you're removing it because it is
unused. If you want to refer when it accidentally got left in, you can
include the commit hash, but it's not necessary to do so.

Otherwise, the patch series looks good to me.

> CID 1506210: Uninitialized pointer field
>
> Closes #4492
> ---
>  tester/covoar/ObjdumpProcessor.h | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/tester/covoar/ObjdumpProcessor.h 
> b/tester/covoar/ObjdumpProcessor.h
> index ed36981..6a207dd 100644
> --- a/tester/covoar/ObjdumpProcessor.h
> +++ b/tester/covoar/ObjdumpProcessor.h
> @@ -184,11 +184,6 @@ namespace Coverage {
>  );
>
>  /*!
> - * This member variable is a buffer for input
> - */
> -char* inputBuffer_m;
> -
> -/*!
>   * This member variable contains the symbols to be analyzed
>   */
>  DesiredSymbols& symbolsToAnalyze_m;
> --
> 1.8.3.1
>
> ___
> 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] TraceWriterQEMU.cc: Initialize header._pad

2021-09-01 Thread Gedare Bloom
ok

On Wed, Sep 1, 2021 at 12:52 PM Ryan Long  wrote:
>
> CID 1506204: Uninitialized scalar variable
>
> Closes #4488
> ---
>  tester/covoar/TraceWriterQEMU.cc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/tester/covoar/TraceWriterQEMU.cc 
> b/tester/covoar/TraceWriterQEMU.cc
> index c417745..cc849b6 100644
> --- a/tester/covoar/TraceWriterQEMU.cc
> +++ b/tester/covoar/TraceWriterQEMU.cc
> @@ -113,6 +113,7 @@ namespace Trace {
>  header.big_endian = false;
>  header.machine[0] = 0; // XXX ??
>  header.machine[1] = 0; // XXX ??
> +header._pad = 0;
>  status = ::fwrite( , sizeof(trace_header), 1, traceFile );
>  if (status != 1) {
>std::cerr << "Unable to write header to " << file << std::endl;
> --
> 1.8.3.1
>
> ___
> 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 v1 3/3] rld-dwarf.cpp: Initialize member variables

2021-09-01 Thread Gedare Bloom
seems alright to me.

On Tue, Aug 24, 2021 at 11:14 AM Ryan Long  wrote:
>
> Initialize member variables not listed.
>
> CID 1503019: Uninitialized scalar field.
>
> Closes #4500
> ---
>  rtemstoolkit/rld-dwarf.cpp | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/rtemstoolkit/rld-dwarf.cpp b/rtemstoolkit/rld-dwarf.cpp
> index 1eae50c..2d6f306 100644
> --- a/rtemstoolkit/rld-dwarf.cpp
> +++ b/rtemstoolkit/rld-dwarf.cpp
> @@ -679,12 +679,18 @@ namespace rld
>  machine_code_ (false),
>  external_ (false),
>  declaration_ (false),
> +prototyped_ (false),
>  inline_ (DW_INL_not_inlined),
>  entry_pc_ (0),
>  has_entry_pc_ (false),
>  pc_low_ (0),
>  pc_high_ (0),
>  ranges_ (debug),
> +name_ (),
> +linkage_name_ (),
> +decl_file_ (),
> +decl_line_ (0),
> +call_file_ (),
>  call_line_ (0)
>  {
>dwarf_bool db;
> @@ -819,6 +825,7 @@ namespace rld
>  machine_code_ (orig.machine_code_),
>  external_ (orig.external_),
>  declaration_ (orig.declaration_),
> +prototyped_ (orig.prototyped_),
>  inline_ (orig.inline_),
>  entry_pc_ (orig.entry_pc_),
>  has_entry_pc_ (orig.has_entry_pc_),
> @@ -827,6 +834,8 @@ namespace rld
>  ranges_ (orig.ranges_),
>  name_ (orig.name_),
>  linkage_name_ (orig.linkage_name_),
> +decl_file_ (orig.decl_file_),
> +decl_line_ (orig.decl_line_),
>  call_file_ (orig.call_file_),
>  call_line_ (orig.call_line_)
>  {
> @@ -986,7 +995,10 @@ namespace rld
>  ranges_ = rhs.ranges_;
>  name_ = rhs.name_;
>  linkage_name_ = rhs.linkage_name_;
> +decl_file_ = rhs.decl_file_;
> +decl_line_ = rhs.decl_line_;
>  call_file_ = rhs.call_file_;
> +call_line_ = rhs.call_line_;
>}
>return *this;
>  }
> --
> 1.8.3.1
>
> ___
> 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 rtems v1 1/2] bsps/zynq: Moved general i2c files to shared directories

2021-09-01 Thread Gedare Bloom
looks fine to me.

On Mon, Aug 23, 2021 at 4:41 PM Stephen Clark  wrote:
>
> Certain files related to the Zynq BSP's I2C driver are useable by the ZynqMP 
> BSP as well.
> Moved these files to shared directory in anticipation of I2C support for 
> ZynqMP.
> ---
>  .../include/bsp => include/dev/i2c}/cadence-i2c-regs.h  | 0
>  .../include/bsp => include/dev/i2c}/cadence-i2c.h   | 0
>  bsps/{arm/xilinx-zynq => shared/dev}/i2c/cadence-i2c.c  | 4 ++--
>  spec/build/bsps/arm/xilinx-zynq/obj.yml | 6 +++---
>  4 files changed, 5 insertions(+), 5 deletions(-)
>  rename bsps/{arm/xilinx-zynq/include/bsp => 
> include/dev/i2c}/cadence-i2c-regs.h (100%)
>  rename bsps/{arm/xilinx-zynq/include/bsp => include/dev/i2c}/cadence-i2c.h 
> (100%)
>  rename bsps/{arm/xilinx-zynq => shared/dev}/i2c/cadence-i2c.c (99%)
>
> diff --git a/bsps/arm/xilinx-zynq/include/bsp/cadence-i2c-regs.h 
> b/bsps/include/dev/i2c/cadence-i2c-regs.h
> similarity index 100%
> rename from bsps/arm/xilinx-zynq/include/bsp/cadence-i2c-regs.h
> rename to bsps/include/dev/i2c/cadence-i2c-regs.h
> diff --git a/bsps/arm/xilinx-zynq/include/bsp/cadence-i2c.h 
> b/bsps/include/dev/i2c/cadence-i2c.h
> similarity index 100%
> rename from bsps/arm/xilinx-zynq/include/bsp/cadence-i2c.h
> rename to bsps/include/dev/i2c/cadence-i2c.h
> diff --git a/bsps/arm/xilinx-zynq/i2c/cadence-i2c.c 
> b/bsps/shared/dev/i2c/cadence-i2c.c
> similarity index 99%
> rename from bsps/arm/xilinx-zynq/i2c/cadence-i2c.c
> rename to bsps/shared/dev/i2c/cadence-i2c.c
> index 07379992ce..91774fb926 100644
> --- a/bsps/arm/xilinx-zynq/i2c/cadence-i2c.c
> +++ b/bsps/shared/dev/i2c/cadence-i2c.c
> @@ -25,8 +25,8 @@
>   * POSSIBILITY OF SUCH DAMAGE.
>   */
>
> -#include 
> -#include 
> +#include 
> +#include 
>
>  #include 
>  #include 
> diff --git a/spec/build/bsps/arm/xilinx-zynq/obj.yml 
> b/spec/build/bsps/arm/xilinx-zynq/obj.yml
> index e81decaa3d..8a11a45dd3 100644
> --- a/spec/build/bsps/arm/xilinx-zynq/obj.yml
> +++ b/spec/build/bsps/arm/xilinx-zynq/obj.yml
> @@ -14,8 +14,8 @@ install:
>- bsps/arm/xilinx-zynq/include/tm27.h
>  - destination: ${BSP_INCLUDEDIR}/bsp
>source:
> -  - bsps/arm/xilinx-zynq/include/bsp/cadence-i2c-regs.h
> -  - bsps/arm/xilinx-zynq/include/bsp/cadence-i2c.h
> +  - bsps/include/dev/i2c/cadence-i2c-regs.h
> +  - bsps/include/dev/i2c/cadence-i2c.h
>- bsps/arm/xilinx-zynq/include/bsp/i2c.h
>- bsps/arm/xilinx-zynq/include/bsp/irq.h
>  links: []
> @@ -28,7 +28,7 @@ source:
>  - bsps/arm/xilinx-zynq/console/console-config.c
>  - bsps/arm/xilinx-zynq/console/console-init.c
>  - bsps/arm/xilinx-zynq/console/debug-console.c
> -- bsps/arm/xilinx-zynq/i2c/cadence-i2c.c
> +- bsps/shared/dev/i2c/cadence-i2c.c
>  - bsps/arm/xilinx-zynq/start/bspreset.c
>  - bsps/arm/xilinx-zynq/start/bspstart.c
>  - bsps/arm/xilinx-zynq/start/bspstarthooks.c
> --
> 2.27.0
>
> ___
> 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 5/5] score: Update priority only if necessary

2021-09-01 Thread Gedare Bloom
ok, just the one note about doxygen. thanks!

On Tue, Aug 31, 2021 at 5:24 AM Sebastian Huber
 wrote:
>
> In _Thread_queue_Flush_critical(), update the priority of the thread
> queue owner only if necessary.  The scheduler update priority operation
> could be expensive.
> ---
>  cpukit/include/rtems/score/threadqimpl.h |  4 ++--
>  cpukit/score/src/threadchangepriority.c  |  2 +-
>  cpukit/score/src/threadqflush.c  | 22 +-
>  3 files changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/threadqimpl.h 
> b/cpukit/include/rtems/score/threadqimpl.h
> index f42c67cc47..33cdb3058d 100644
> --- a/cpukit/include/rtems/score/threadqimpl.h
> +++ b/cpukit/include/rtems/score/threadqimpl.h
> @@ -366,8 +366,8 @@ RTEMS_INLINE_ROUTINE void 
> _Thread_queue_Context_clear_priority_updates(
>   *
>   * @return The priority update count of @a queue_context.
>   */
> -RTEMS_INLINE_ROUTINE size_t _Thread_queue_Context_save_priority_updates(
> -  Thread_queue_Context *queue_context
> +RTEMS_INLINE_ROUTINE size_t _Thread_queue_Context_get_priority_updates(
> +  const Thread_queue_Context *queue_context
>  )
>  {
>return queue_context->Priority.update_count;
> diff --git a/cpukit/score/src/threadchangepriority.c 
> b/cpukit/score/src/threadchangepriority.c
> index ac2e9a6d0c..613d0cd7af 100644
> --- a/cpukit/score/src/threadchangepriority.c
> +++ b/cpukit/score/src/threadchangepriority.c
> @@ -212,7 +212,7 @@ void _Thread_Priority_perform_actions(
> */
>
>the_thread = start_of_path;
> -  update_count = _Thread_queue_Context_save_priority_updates( queue_context 
> );
> +  update_count = _Thread_queue_Context_get_priority_updates( queue_context );
>
>while ( true ) {
>  Thread_queue_Queue *queue;
> diff --git a/cpukit/score/src/threadqflush.c b/cpukit/score/src/threadqflush.c
> index 357e3d696e..42b35a499b 100644
> --- a/cpukit/score/src/threadqflush.c
> +++ b/cpukit/score/src/threadqflush.c
> @@ -71,15 +71,15 @@ size_t _Thread_queue_Flush_critical(
>Thread_queue_Context  *queue_context
>  )
>  {
> -  size_t  flushed;
> -  Chain_Control   unblock;
> -  Thread_Control *owner;
> -  Chain_Node *node;
> -  Chain_Node *tail;
> +  size_tflushed;
> +  size_tpriority_updates;
> +  Chain_Control unblock;
> +  Chain_Node   *node;
> +  Chain_Node   *tail;
>
>flushed = 0;
> +  priority_updates = 0;
>_Chain_Initialize_empty(  );
> -  owner = queue->owner;
>
>while ( true ) {
>  Thread_queue_Heads *heads;
> @@ -99,8 +99,7 @@ size_t _Thread_queue_Flush_critical(
>
>  /*
>   * We do not have enough space in the queue context to collect all 
> priority
> - * updates, so clear it each time.  We unconditionally do the priority
> - * update for the owner later if it exists.
> + * updates, so clear it each time and accumulate the priority updates.
>   */
>  _Thread_queue_Context_clear_priority_updates( queue_context );
>
> @@ -120,6 +119,8 @@ size_t _Thread_queue_Flush_critical(
>);
>  }
>
> +priority_updates +=
> +  _Thread_queue_Context_get_priority_updates( queue_context );
>  ++flushed;
>}
>
> @@ -145,9 +146,12 @@ size_t _Thread_queue_Flush_critical(
>node = next;
>  } while ( node != tail );
>
> -if ( owner != NULL ) {
> +if ( priority_updates != 0 ) {
> +  Thread_Control  *owner;
>ISR_lock_Context lock_context;
>
> +  owner = queue->owner;
> +  _Assert( owner != NULL );
>_Thread_State_acquire( owner, _context );
>_Scheduler_Update_priority( owner );
>_Thread_State_release( owner, _context );
> --
> 2.26.2
>
> ___
> 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 2/5] score: Fix blocking message queue receive

2021-09-01 Thread Gedare Bloom
On Tue, Aug 31, 2021 at 5:24 AM Sebastian Huber
 wrote:
>
> In order to ensure FIFO fairness across schedulers, the thread queue
> surrender operation must be used to dequeue a thread from the thread
> queue.  The thread queue extract operation is intended for timeouts.
>

Please add a note like this to the doxygen for _Thread_queue_Extract().

> Add _Thread_queue_Resume() which may be used to make extracted or
> surrendered threads ready again.
>
> Remove the now unused _Thread_queue_Extract_critical() function.
>
> Close #4509.
> ---
>  cpukit/include/rtems/score/coremsgimpl.h | 20 
>  cpukit/include/rtems/score/threadqimpl.h | 59 ++--
>  cpukit/score/src/coremsgseize.c  | 20 
>  cpukit/score/src/threadqenqueue.c| 45 ++
>  4 files changed, 62 insertions(+), 82 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/coremsgimpl.h 
> b/cpukit/include/rtems/score/coremsgimpl.h
> index 161cf8f124..7f01769010 100644
> --- a/cpukit/include/rtems/score/coremsgimpl.h
> +++ b/cpukit/include/rtems/score/coremsgimpl.h
> @@ -616,7 +616,8 @@ RTEMS_INLINE_ROUTINE Thread_Control 
> *_CORE_message_queue_Dequeue_receiver(
>Thread_queue_Context*queue_context
>  )
>  {
> -  Thread_Control *the_thread;
> +  Thread_queue_Heads *heads;
> +  Thread_Control *the_thread;
>
>/*
> *  If there are pending messages, then there can't be threads
> @@ -634,14 +635,18 @@ RTEMS_INLINE_ROUTINE Thread_Control 
> *_CORE_message_queue_Dequeue_receiver(
> *  There must be no pending messages if there is a thread waiting to
> *  receive a message.
> */
> -  the_thread = _Thread_queue_First_locked(
> -_message_queue->Wait_queue,
> -the_message_queue->operations
> -  );
> -  if ( the_thread == NULL ) {
> +  heads = the_message_queue->Wait_queue.Queue.heads;
> +  if ( heads == NULL ) {
>  return NULL;
>}
>
> +  the_thread = ( *the_message_queue->operations->surrender )(
> +_message_queue->Wait_queue.Queue,
> +heads,
> +NULL,
> +queue_context
> +  );
> +
> *(size_t *) the_thread->Wait.return_argument = size;
> the_thread->Wait.count = (uint32_t) submit_type;
>
> @@ -651,9 +656,8 @@ RTEMS_INLINE_ROUTINE Thread_Control 
> *_CORE_message_queue_Dequeue_receiver(
>  size
>);
>
> -  _Thread_queue_Extract_critical(
> +  _Thread_queue_Resume(
>  _message_queue->Wait_queue.Queue,
> -the_message_queue->operations,
>  the_thread,
>  queue_context
>);
> diff --git a/cpukit/include/rtems/score/threadqimpl.h 
> b/cpukit/include/rtems/score/threadqimpl.h
> index 2465fc4499..0a24d2da3b 100644
> --- a/cpukit/include/rtems/score/threadqimpl.h
> +++ b/cpukit/include/rtems/score/threadqimpl.h
> @@ -975,56 +975,23 @@ void _Thread_queue_Unblock_critical(
>  );
>
>  /**
> - * @brief Extracts the thread from the thread queue and unblocks it.
> + * @brief Resumes the extracted or surrendered thread.
>   *
> - * The caller must be the owner of the thread queue lock.  This function will
> - * release the thread queue lock and restore the default thread lock.  Thread
> - * dispatching is disabled before the thread queue lock is released and an
> - * unblock is necessary.  Thread dispatching is enabled once the sequence to
> - * unblock the thread is complete.  This makes it possible to use the thread
> - * queue lock to protect the state of objects embedding the thread queue and
> - * directly enter _Thread_queue_Extract_critical() to finalize an operation 
> in
> - * case a waiting thread exists.
> - *
> - * @code
> - * #include 
> - *
> - * typedef struct {
> - *   Thread_queue_Control  Queue;
> - *   Thread_Control   *owner;
> - * } Mutex;
> + * This function makes the thread ready again.  If necessary, the thread is
> + * unblocked and its thread timer removed.
>   *
> - * void _Mutex_Release( Mutex *mutex )
> - * {
> - *   Thread_queue_Context  queue_context;
> - *   Thread_Control   *first;
> - *
> - *   _Thread_queue_Context_initialize( _context, NULL );
> - *   _Thread_queue_Acquire( >Queue, queue_context );
> - *
> - *   first = _Thread_queue_First_locked( >Queue );
> - *   mutex->owner = first;
> - *
> - *   if ( first != NULL ) {
> - * _Thread_queue_Extract_critical(
> - *   >Queue.Queue,
> - *   mutex->Queue.operations,
> - *   first,
> - *   _context
> - *   );
> - * }
> - * @endcode
> + * The thread shall have been extracted from the thread queue or surrendered 
> by
> + * the thread queue right before the call to this function.  The caller shall
> + * be the owner of the thread queue lock.
>   *
> - * @param queue The actual thread queue.
> - * @param operations The thread queue operations.
> - * @param[in, out] the_thread The thread to extract.
> - * @param[in, out] queue_context The thread queue context of the lock 
> acquire.
> + * @param queue is the actual thread queue.
> + * @param[in, out] the_thread is the thread to make ready and unblock.
> + * 

Re: [PATCH rtems] bsps/imxrt: Improve SPI driver

2021-09-01 Thread Gedare Bloom
looks ok, touching imxrt driver only

On Wed, Sep 1, 2021 at 7:55 AM Christian Mauderer
 wrote:
>
> It wasn't possible to keep the CS line low between multiple message
> descriptors in one transfer. This patch reworks the driver so that it is
> possible.
>
> Update #4180
> ---
>  bsps/arm/imxrt/spi/imxrt-lpspi.c | 197 +++
>  1 file changed, 124 insertions(+), 73 deletions(-)
>
> diff --git a/bsps/arm/imxrt/spi/imxrt-lpspi.c 
> b/bsps/arm/imxrt/spi/imxrt-lpspi.c
> index 06d8f715d9..80b47f9663 100644
> --- a/bsps/arm/imxrt/spi/imxrt-lpspi.c
> +++ b/bsps/arm/imxrt/spi/imxrt-lpspi.c
> @@ -43,16 +43,19 @@ struct imxrt_lpspi_bus {
>uint32_t src_clock_hz;
>clock_ip_name_t clock_ip;
>
> -  uint32_t msg_todo;
> -  const spi_ioc_transfer *msg;
>rtems_binary_semaphore sem;
> -  uint32_t tcr;
> +  bool cs_change_on_last_msg;
>
> +  uint32_t rx_msg_todo;
> +  const spi_ioc_transfer *rx_msg;
>size_t remaining_rx_size;
>uint8_t *rx_buf;
>
> +  uint32_t tx_msg_todo;
> +  const spi_ioc_transfer *tx_msg;
>size_t remaining_tx_size;
>const uint8_t *tx_buf;
> +
>uint32_t fifo_size;
>  };
>
> @@ -146,11 +149,7 @@ static void imxrt_lpspi_config(
>}
>
>tcr |= LPSPI_TCR_PCS(msg->cs);
> -
> -  if (!msg->cs_change) {
> -tcr |= LPSPI_TCR_CONT_MASK;
> -  }
> -
> +  tcr |= LPSPI_TCR_CONT_MASK;
>tcr |= LPSPI_TCR_FRAMESZ(word_size-1);
>
>if (ccr_orig != ccr) {
> @@ -159,9 +158,13 @@ static void imxrt_lpspi_config(
>  regs->CR |= LPSPI_CR_MEN_MASK;
>}
>
> -  /* No CONTC on first write. Otherwise upper 8 bits are not written. */
> -  regs->TCR = tcr;
> -  regs->TCR = tcr | LPSPI_TCR_CONTC_MASK | LPSPI_TCR_CONT_MASK;
> +  if (bus->cs_change_on_last_msg) {
> +/* No CONTC on first write. Otherwise upper 8 bits are not written. */
> +regs->TCR = tcr;
> +  }
> +  regs->TCR = tcr | LPSPI_TCR_CONTC_MASK;
> +
> +  bus->cs_change_on_last_msg = msg->cs_change;
>  }
>
>  static inline bool imxrt_lpspi_rx_fifo_not_empty(
> @@ -184,48 +187,72 @@ static inline bool imxrt_lpspi_tx_fifo_not_full(
>bus->fifo_size - 2;
>  }
>
> +static void imxrt_lpspi_next_tx_msg(
> +  struct imxrt_lpspi_bus *bus,
> +  volatile LPSPI_Type *regs
> +)
> +{
> +  if (bus->tx_msg_todo > 0) {
> +const spi_ioc_transfer *msg;
> +
> +msg = bus->tx_msg;
> +
> +imxrt_lpspi_config(bus, regs, msg);
> +bus->remaining_tx_size = msg->len;
> +bus->tx_buf = msg->tx_buf;
> +  }
> +}
> +
>  static void imxrt_lpspi_fill_tx_fifo(
>struct imxrt_lpspi_bus *bus,
>volatile LPSPI_Type *regs
>  )
>  {
>while(imxrt_lpspi_tx_fifo_not_full(bus, regs)
> -  && bus->remaining_tx_size > 0) {
> -if (bus->remaining_tx_size == 1) {
> -  regs->TCR &= ~(LPSPI_TCR_CONT_MASK);
> -}
> +  && (bus->tx_msg_todo > 0 || bus->remaining_tx_size > 0)) {
> +if (bus->remaining_tx_size > 0) {
> +  if (bus->remaining_tx_size == 1 && bus->tx_msg->cs_change) {
> +/*
> + * Necessary for getting the last data out of the Rx FIFO. See "i.MX
> + * RT1050 Processor Reference Manual Rev. 4" Chapter 47.3.2.2 
> "Receive
> + * FIFO and Data Match":
> + *
> + * "During a continuous transfer, if the transmit FIFO is empty, then
> + * the receive data is only written to the receive FIFO after the
> + * transmit FIFO is written or after the Transmit Command Register 
> (TCR)
> + * is written to end the frame."
> + */
> +regs->TCR &= ~(LPSPI_TCR_CONT_MASK);
> +  }
>
> -if (bus->tx_buf != NULL) {
> -  regs->TDR = bus->tx_buf[0];
> -  ++bus->tx_buf;
> -} else {
> -  regs->TDR = 0;
> +  if (bus->tx_buf != NULL) {
> +regs->TDR = bus->tx_buf[0];
> +++bus->tx_buf;
> +  } else {
> +regs->TDR = 0;
> +  }
> +  --bus->remaining_tx_size;
> +}
> +if (bus->remaining_tx_size == 0) {
> +  --bus->tx_msg_todo;
> +  ++bus->tx_msg;
> +  imxrt_lpspi_next_tx_msg(bus, regs);
>  }
> ---bus->remaining_tx_size;
>}
>  }
>
> -static void imxrt_lpspi_next_msg(
> +static void imxrt_lpspi_next_rx_msg(
>struct imxrt_lpspi_bus *bus,
>volatile LPSPI_Type *regs
>  )
>  {
> -  if (bus->msg_todo > 0) {
> +  if (bus->rx_msg_todo > 0) {
>  const spi_ioc_transfer *msg;
>
> -msg = bus->msg;
> +msg = bus->rx_msg;
>
> -imxrt_lpspi_config(bus, regs, msg);
> -bus->remaining_tx_size = msg->len;
>  bus->remaining_rx_size = msg->len;
>  bus->rx_buf = msg->rx_buf;
> -bus->tx_buf = msg->tx_buf;
> -
> -imxrt_lpspi_fill_tx_fifo(bus, regs);
> -regs->IER = LPSPI_IER_TDIE_MASK;
> -  } else {
> -regs->IER = 0;
> -rtems_binary_semaphore_post(>sem);
>}
>  }
>
> @@ -234,15 +261,22 @@ static void imxrt_lpspi_pull_data_from_rx_fifo(
>volatile LPSPI_Type *regs
>  )
>  {
> -  while (imxrt_lpspi_rx_fifo_not_empty(regs) && bus->remaining_rx_size > 0) {
> -uint32_t data;
> -
> -data = 

Re: [PATCH rtems-libbsd] imx: Remove ccm functions alredy defined in RTEMS

2021-08-31 Thread Gedare Bloom
Sorry, i think libbsd is still a bit slushy, wait for Chris to ok thx

On Tue, Aug 31, 2021 at 3:21 PM Gedare Bloom  wrote:
>
> ok
>
> On Tue, Aug 31, 2021 at 5:43 AM Christian Mauderer
>  wrote:
> >
> > The imx_ccm_*_hz are all defined in RTEMS. So don't duplicate them in
> > libbsd. Otherwise some applications get linker errors.
> >
> > Update #3869
> > ---
> >  freebsd/sys/arm/freescale/imx/imx6_ccm.c | 2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/freebsd/sys/arm/freescale/imx/imx6_ccm.c 
> > b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
> > index 78bbd5c1..7fdb69b8 100644
> > --- a/freebsd/sys/arm/freescale/imx/imx6_ccm.c
> > +++ b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
> > @@ -368,6 +368,7 @@ imx6_ccm_sata_enable(void)
> > return 0;
> >  }
> >
> > +#ifndef __rtems__
> >  uint32_t
> >  imx_ccm_ecspi_hz(void)
> >  {
> > @@ -408,6 +409,7 @@ imx_ccm_ahb_hz(void)
> >  {
> > return (13200);
> >  }
> > +#endif /* __rtems__ */
> >
> >  void
> >  imx_ccm_ipu_enable(int ipu)
> > --
> > 2.31.1
> >
> > ___
> > 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 rtems-libbsd] imx: Remove ccm functions alredy defined in RTEMS

2021-08-31 Thread Gedare Bloom
ok

On Tue, Aug 31, 2021 at 5:43 AM Christian Mauderer
 wrote:
>
> The imx_ccm_*_hz are all defined in RTEMS. So don't duplicate them in
> libbsd. Otherwise some applications get linker errors.
>
> Update #3869
> ---
>  freebsd/sys/arm/freescale/imx/imx6_ccm.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/freebsd/sys/arm/freescale/imx/imx6_ccm.c 
> b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
> index 78bbd5c1..7fdb69b8 100644
> --- a/freebsd/sys/arm/freescale/imx/imx6_ccm.c
> +++ b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
> @@ -368,6 +368,7 @@ imx6_ccm_sata_enable(void)
> return 0;
>  }
>
> +#ifndef __rtems__
>  uint32_t
>  imx_ccm_ecspi_hz(void)
>  {
> @@ -408,6 +409,7 @@ imx_ccm_ahb_hz(void)
>  {
> return (13200);
>  }
> +#endif /* __rtems__ */
>
>  void
>  imx_ccm_ipu_enable(int ipu)
> --
> 2.31.1
>
> ___
> 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 rtems-tools 2/2] misc: Add rtems-style command

2021-08-25 Thread Gedare Bloom
On Mon, Aug 16, 2021 at 4:14 PM Ida Delphine  wrote:
>
> Signed-off-by: Ida Delphine 
>
> This command helps to check for style issues or reformat code given a file
> or directory. There are 4 flags:
> * -c, --check : Checks for style issues
> * -r, --reformat : Reformats the code
> * -p, --path : Path to file or dir to be checked or reformatted
> * -i, --ignore : Files to be ignored when checking or reformatting
> * -v, --verbose : Produces a more detailed output.
> ---
>  misc/rtems-style|  16 +
>  misc/tools/style.py | 144 
>  2 files changed, 160 insertions(+)
>  create mode 100644 misc/rtems-style
>  create mode 100644 misc/tools/style.py
>
> diff --git a/misc/rtems-style b/misc/rtems-style
> new file mode 100644
> index 000..5a3e0e8
> --- /dev/null
> +++ b/misc/rtems-style
> @@ -0,0 +1,16 @@
> +#! /usr/bin/env python
> +

See 
https://docs.rtems.org/branches/master/eng/coding-file-hdr.html#python-file-template

I think this tool should be maybe rtems-c-style? It only focuses on C
and C Header files.

Maybe, later, we need to include rtems-asm-style and rtems-py-style?
Just some thoughts.

> +from __future__ import print_function
> +
> +import sys, os
> +
> +base = os.path.dirname(os.path.dirname(os.path.abspath(sys.argv[0])))
> +rtems = os.path.join(base, 'share', 'rtems')
> +sys.path = sys.path[0:1] + [rtems, base] + sys.path[1:]
> +
> +try:
> +import misc.tools.style
> +misc.tools.style.run()
> +except ImportError:
> +print("Incorrect RTEMS Tools installation", file = sys.stderr)
> +sys.exit(1)
> \ No newline at end of file
> diff --git a/misc/tools/style.py b/misc/tools/style.py
> new file mode 100644
> index 000..a101146
> --- /dev/null
> +++ b/misc/tools/style.py
> @@ -0,0 +1,144 @@
> +import argparse
> +import os
> +import sys
> +import re
> +
> +from rtemstoolkit import execute
> +from rtemstoolkit import git
> +
> +
> +def get_command():
> +from rtemstoolkit import check
> +
> +for version in ['', '8', '9', '10', '11']:
> +if check.check_exe(None, 'clang-format' + version):
> +command = 'clang-format' + version
> +return command
> +print("Clang-format not found in your system")
> +sys.exit(1)
> +
> +
> +def arguments():
> +parser = argparse.ArgumentParser(description="Tool for code formatting 
> and style checking \
> +for RTEMS")
> +parser.add_argument("-c", "--check", dest="check", help="Check for style 
> differences and \
> +report the number of issues if found", action="store_true")
> +parser.add_argument("-r", "--reformat", dest="reformat", help="Reformat 
> the file/directory \
> +with any style differences found", action="store_true")
> +parser.add_argument("-p", "--path", dest="path", help="The path to be 
> checked for style issues \
> +or reformatted")
> +parser.add_argument("--ignore", dest="ignore", help="Ignore files to be 
> checked or reformatted")
> +parser.add_argument("-v", "--verbose", dest="verbose", help="A more 
> detailed outline of the \
> +style issues", action='store_true')
> +return [parser.parse_args(), parser.print_usage()]
> +
> +
> +

Check the style of your Python code. Make sure it conforms
https://docs.rtems.org/branches/master/eng/python-devel.html

I think we only want two blank lines between function bodies.

> +def get_diff(path, ignore_file=None):
> +diff = ""
> +ex = execute.capture_execution()
> +
> +
> +def clang_to_git_diff(clang_output, path):

Why is this indented to here? I think this changes the visibility of
it to make it a nested function. Is this necessary/desired here?

> +import os
> +import tempfile
> +
> +fd, tmp_path = tempfile.mkstemp()
> +try:
> +with os.fdopen(fd, 'w') as tmp:

I think this is trying to open fd again?  Seems wrong, since the fd
file descriptor is already open? I'm not sure.

> +
> +tmp.write(clang_output)
> +repo = git.repo(".")

I wonder if we need to provide an argument to the location of the git
repo instead of assume the script runs from within it?

> +return repo.diff(['--no-index', path, tmp_path])
> +
> +finally:
> +os.remove(tmp_path)

Is this all the cleanup needed? what about closing the open fd?

> +
> +if os.path.isfile(path) == True:
> +cmd = get_command() + " --style=file " + path
> +output_clang = ex.command(command=cmd, shell=True)
> +output_clang = output_clang[2]
> +diff = clang_to_git_diff(output_clang, path)
> +else:
> +onlyfiles = [f for f in os.listdir(path)]
> +for file in onlyfiles:
> +file = os.path.join(path, file)
> +
> +if ignore_file is not None and file == ignore_file:

is there only one ignore_file? Shouldn't there be a set of them? I'm
not sure how this works.

> +continue
> +
> +  

Re: [PATCH] GcovData.cc: Remove ampersands where not needed

2021-08-23 Thread Gedare Bloom
ok

On Mon, Aug 23, 2021 at 9:49 AM Ryan Long  wrote:
>
> Removed some ampersands that were left in on accident.
> ---
>  tester/covoar/GcovData.cc | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tester/covoar/GcovData.cc b/tester/covoar/GcovData.cc
> index 44928a9..59412a6 100644
> --- a/tester/covoar/GcovData.cc
> +++ b/tester/covoar/GcovData.cc
> @@ -404,7 +404,7 @@ namespace Gcov {
>
>  // Read the gcov preamble and make sure it is the right length and has 
> the
>  // magic number
> -gcovFile.read( (char *) , sizeof( gcov_preamble ) );
> +gcovFile.read( (char *) preamble, sizeof( gcov_preamble ) );
>  if ( gcovFile.gcount() != sizeof( gcov_preamble ) ) {
>std::cerr << "Error while reading file preamble" << std::endl;
>return -1;
> @@ -429,7 +429,7 @@ namespace Gcov {
>  char buffer[512];
>  char intBuffer[16384];
>
> -gcovFile.read( (char *) , 8 );
> +gcovFile.read( (char *) intBuffer, 8 );
>  if ( gcovFile.gcount() != 8 ) {
>std::cerr << "ERROR: Unable to read Function ID & checksum" << 
> std::endl;
>return false;
> @@ -443,7 +443,7 @@ namespace Gcov {
>  function->setFunctionName( buffer, symbolsToAnalyze_m );
>  header.length -= readString( buffer, gcovFile );
>  function->setFileName( buffer );
> -gcovFile.read( (char*) , 4 * header.length );
> +gcovFile.read( (char*) intBuffer, 4 * header.length );
>  if (gcovFile.gcount() != 4 * header.length ) {
>std::cerr << "ERROR: Unable to read Function starting line number"
>  << std::endl;
> --
> 1.8.3.1
>
> ___
> 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 5/5] score: Delete unused rtems_ada_self

2021-08-20 Thread Gedare Bloom
these 5 look fine to me

On Mon, Aug 16, 2021 at 5:15 AM Sebastian Huber
 wrote:
>
> ---
>  cpukit/include/rtems/score/threadimpl.h | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/threadimpl.h 
> b/cpukit/include/rtems/score/threadimpl.h
> index 45c0795d9c..f25e347e33 100644
> --- a/cpukit/include/rtems/score/threadimpl.h
> +++ b/cpukit/include/rtems/score/threadimpl.h
> @@ -74,11 +74,6 @@ typedef struct {
>   */
>  extern Thread_Zombie_registry _Thread_Zombies;
>
> -/**
> - *  Self for the GNU Ada Run-Time
> - */
> -extern void *rtems_ada_self;
> -
>  /**
>   * @brief Object identifier of the global constructor thread.
>   *
> --
> 2.26.2
>
> ___
> 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] eng: Document use of BSP family for defaults

2021-08-20 Thread Gedare Bloom
ok

On Wed, Aug 18, 2021 at 3:29 AM Sebastian Huber
 wrote:
>
> Update #4468.
> ---
>  eng/build-system.rst | 4 ++--
>  eng/req/items.rst| 8 ++--
>  2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/eng/build-system.rst b/eng/build-system.rst
> index e76b606..030679d 100644
> --- a/eng/build-system.rst
> +++ b/eng/build-system.rst
> @@ -355,8 +355,8 @@ Add a Base BSP to a BSP Family
>  items ``spec:/build/bsps/arch/family/bsprst``,
>  ``spec:/build/bsps/arch/family/bspuvw``, and
>  ``spec:/build/bsps/arch/family/bspxyz`` just define the name of the base
> -BSP and set a link to the group item.  The base BSP names can be used for
> -example in the ``default-by-variant`` attribute of
> +BSP and set a link to the group item.  The base BSP and BSP family names
> +can be used for example in the ``default-by-variant`` attribute of
>  :ref:`SpecTypeBuildOptionItemType` items.  The items linked by the BSP
>  items are shown using relative UIDs.
>
> diff --git a/eng/req/items.rst b/eng/req/items.rst
> index e7727aa..51f3c3d 100644
> --- a/eng/req/items.rst
> +++ b/eng/req/items.rst
> @@ -719,8 +719,11 @@ default
>
>  default-by-variant
>  The attribute value shall be a list. Each list element shall be a
> -:ref:`SpecTypeBuildOptionDefaultByVariant`. The list is processed from 
> top
> -to bottom.  If a matching variant is found, then the processing stops.
> +:ref:`SpecTypeBuildOptionDefaultByVariant`. The list is checked two times
> +and processed from top to bottom. Firstly, the base BSP name is used to
> +match with a variant. Secondly, the BSP family name prefixed by ``bsps/``
> +is used to match with a variant.  If a matching variant is found, then 
> the
> +processing stops.
>
>  description
>  The attribute value shall be an optional string. It shall be the
> @@ -750,6 +753,7 @@ Please have a look at the following example:
>  default-by-variant:
>  - value: 9600
>variants:
> +  - bsps/powerpc/motorola_powerpc
>- m68k/m5484FireEngine
>- powerpc/hsc_cm01
>  - value: 19200
> --
> 2.26.2
>
> ___
> 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] gdb: prefere python3 if it is installed

2021-08-20 Thread Gedare Bloom
On Fri, Aug 20, 2021 at 2:02 AM Chris Johns  wrote:
>
> On 20/8/21 5:42 pm, Christian MAUDERER wrote:
> > Am 20.08.21 um 09:02 schrieb Chris Johns:
> >> On 20/8/21 4:48 pm, Christian MAUDERER wrote:
> >>> Hello,
> >>>
> >>> Am 20.08.21 um 03:49 schrieb Chris Johns:
> >>>> On 20/8/21 3:16 am, Joel Sherrill wrote:
> >>>>> On Thu, Aug 19, 2021 at 11:51 AM Gedare Bloom  wrote:
> >>>>>>
> >>>>>> I have no problem with this. I think it is sensible to look for
> >>>>>> python3 before python2. At some point we'll have to stop looking for
> >>>>>> python2 :)
> >>>>>
> >>>>> That is further in the future than I would have thought based on the
> >>>>> CentOS project changes. I still see user organizations with no plans
> >>>>> to move off CentOS 7. It will receive maintenance updates through
> >>>>> 2024-06-30.
> >>>>>
> >>>>> But on CentOS 7, I can load a Python 3.6, newer GCC, etc. so it isn't
> >>>>> that bad. I had to test something on a true 32-bit distribution this 
> >>>>> week
> >>>>> and even CentOS 7 (i386) wasn't as painful as I expected to setup.
> >>>>
> >>>> There will come a time when a change made cannot be easily tested by us 
> >>>> on
> >>>> python2 and that will in effect end our support. We are not there yet.
> >>>
> >>> STOP.
> >>
> >> Please do not do this again.
> >>
> >> That discussion took a wrong direction. We discussed deprecating python2 a
> >>> few times and I know that we will not do it before the big long living
> >>> distributions drop it. I can live with that and I don't want to re-start 
> >>> this
> >>> discussion with this patch.
> >>
> >> If Joel feels the need to make this statement he can and he has more than 
> >> earned
> >> the right to do so. His work and those he supports is important.
> >
> > Sorry, I didn't want to offend you, Joel or Gedare.
> >
> > I had that with discussions before that the original idea (here: giving 
> > priority
> > to python3 over python2 when building gdb) started to be buried by a 
> > similar but
> > slightly different one which has been already discussed multiple times 
> > (here:
> > deprecating python2). I wanted to avoid that.
> >
> > I should have worded that different. I'm sorry if I have offended you, Joel 
> > or
> > Gedare or anyone else.
>
> Thanks and none taken. I am clear on the focus of your posts so it is ok. :)
>
It would be fine without the STOP. Totally acceptable to express your
opinion and request that we not bikeshed your patch, we just want to
keep the tone of the list in the right direction which we all know can
be challenging in virtual, international communications. We understand
the intent here, but we just want to make sure to keep the list
friendly to all (who may lack some of our context). Thanks!

> >
> >>
> >>>
> >>>>
> >>>>>> On Thu, Aug 19, 2021 at 3:24 AM Christian MAUDERER
> >>>>>>  wrote:
> >>>>>>>
> >>>>>>> PS: I had the problem on the 5 branch of RTEMS source builder. I think
> >>>>>>> we should apply a patch to both: master and the 5 branch.
> >>>>>>>
> >>>>>>> Am 19.08.21 um 10:34 schrieb Christian Mauderer:
> >>>>>>>> More and more systems stop shipping python2. So we should start to
> >>>>>>>> prefer python3 over python2. For building gdb it is not only 
> >>>>>>>> necessary
> >>>>>>>> to have a python binary installed, but also the matching python-devel
> >>>>>>>> packet. On a lot of hosts that will now be more often python3-devel
> >>>>>>>> and not python2-devel.
> >>>>>>>> ---
> >>>>>>>>
> >>>>>>>> Note: Please see that patch more as an suggestion / base for
> >>>>>>>> discussion. I'm open to better solutions.
> >>>>>>>>
> >>>>>>>> My problem that triggered this patch was a build of a toolchain on a
> >>>>>>>> github CI/CD system that has been originally set up by one of our
> >>>&g

Re: [PATCH] aarch64: Add tests that are failing intermittently

2021-08-19 Thread Gedare Bloom
On Thu, Aug 19, 2021 at 11:43 AM Kinsey Moore  wrote:
>
> I've seen these failures on my local system, in our CI, and on a build
> server that I sometimes
> use for development/testing so if it's a configuration issue we're being
> pretty consistent about
> misconfiguration across some pretty different environments (docker,
> bare-metal, VM, different
> OSs, different QEMU versions). I've seen enough of the spintrcritical
> tests fail sporadically on
> QEMU to lump them all into this category. These are also tests that I
> have seen behave badly
> on ARMv7 QEMU on my local system (which doesn't rule out
> misconfiguration, but it's another
> data point).
>
Yes, for example, it may be a matter of qemu process counts spawned by
rtems-test, and the order in which tests get invoked could be a cause
for which ones don't work. I could easily see this happening, since
each test runtime will be fairly consistent, so you'll often see the
same tests running concurrently with each other. But, if you change
the order (e.g., by adding new tests), then we may see a new set of
sporadically failing testcases, will we just add those, or do we need
to re-examine this indetermine set periodically? Who will maintain
this list? That's kind of the root of my concern here.

> As far as your worry about marking these indeterminate, they're only
> being marked as such for
> QEMU BSPs. The ZynqMP hardware BSP doesn't have these testing carve-outs
> and runs all
> these tests flawlessly.
>
> These failures become much more common when there is otherwise load on
> the system and a
> lot of them disappear when you limit the tester to a single QEMU
> instance at a time.
>
I'm wondering if we should sacrifice testing speed for
coverage/quality. If throttling rtems-test leads to more reliable test
results, then it may be a better option than basically ignoring a
swath of our testsuite.

>
> Kinsey
>
>
> On 8/19/2021 11:58, Gedare Bloom wrote:
> > Can you explain the process for generating the lists of indeterminate
> > test results?
> >
> > I hate to circle this subject so many times, but is labeling sporadic
> > simulator failures as indeterminate results really the right thing to
> > do? Are these indeterminate tests reproducible on different
> > systems/qemus/loads? Or is it just what you observe locally when
> > running rtems-test on one specific system? I don't think I see nearly
> > so many spurious failures when I run rtems-test for example. I really
> > need to believe we're not just hiding a system configuration problem.
> >
> > I know I OK'd looking at the versal, but on second thought, I'd rather
> > leave the xilinx-versal/tstqemu.yml alone until the BSP is finished,
> > so revert that part of your patch. Sorry about that.
> >
> > Gedare
> >
> > On Thu, Aug 19, 2021 at 9:53 AM Ryan Long  wrote:
> >> - Change status of all spintrcritical tests to indeterminate, expanded upon
> >>comments.
> >> - Add indeterminate tests to xilinx-versal
> >> ---
> >>   spec/build/bsps/aarch64/a53/tsta53.yml| 40 ++---
> >>   spec/build/bsps/aarch64/xilinx-versal/tstqemu.yml | 54 
> >> ++-
> >>   spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml | 40 ++---
> >>   3 files changed, 120 insertions(+), 14 deletions(-)
> >>
> >> diff --git a/spec/build/bsps/aarch64/a53/tsta53.yml 
> >> b/spec/build/bsps/aarch64/a53/tsta53.yml
> >> index f263557..6e8f348 100644
> >> --- a/spec/build/bsps/aarch64/a53/tsta53.yml
> >> +++ b/spec/build/bsps/aarch64/a53/tsta53.yml
> >> @@ -1,20 +1,26 @@
> >>   SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> >>   actions:
> >>   - set-test-state:
> >> -# expected to fail, don't compile these
> >> +# This test fails when ran through rtems-tester because it does not
> >> +# produce any output.
> >>   minimum: exclude
> >>
> >> -# don't compile due to toolchain issues
> >> +# These tests do not compile due to an issue with the GNU Assembler.
> >> +# The issue has been filed(https://devel.rtems.org/ticket/4218).
> >> +# Once the issue has been fixed, these tests will be turned back on.
> >>   spconfig01: exclude
> >>   spmisc01: exclude
> >>
> >> -# tests that are passing intermittently
> >> +# These tests may or may not fail, however, they do pass on real 
> >> hardware.
> >> +# It seems to be an issue with QEMU.
> >>   spcpucounter01: indeterminate
> >> +sptimecounter01: indet

Re: [PATCH] aarch64: Add tests that are failing intermittently

2021-08-19 Thread Gedare Bloom
sues, see RTEMS issue #4218
> +# These tests do not compile due to an issue with the GNU Assembler.
> +# The issue has been filed(https://devel.rtems.org/ticket/4218).
> +# Once the issue has been fixed, these tests will be turned back on.
>  spconfig01: exclude
>  spmisc01: exclude
>
> +# These tests may or may not fail, however, they do pass on real 
> hardware.
> +# It seems to be an issue with Qemu.
> +spcpucounter01: indeterminate
> +sptimecounter01: indeterminate
> +rtmonuse: indeterminate
> +sp04: indeterminate
> +sp20: indeterminate
> +sp68: indeterminate
> +sp69: indeterminate
> +sp71: indeterminate
> +rtmonusxtimes01: indeterminate
> +spedfsched02: indeterminate
> +spedfsched04: indeterminate
> +psxtimes01: indeterminate
> +sprmsched01: indeterminate
> +sptimecounter02: indeterminate
> +sptimecounter04: indeterminate
> +ttest02: indeterminate
> +
> +# These tests may or may not fail, however, they do pass on real 
> hardware.
> +# It seems to be an issue with Qemu, and that this only occurs when the
> +# host machine is under a heavy load.
> +psx12: indeterminate
> +spintrcritical01: indeterminate
> +spintrcritical02: indeterminate
> +spintrcritical03: indeterminate
> +spintrcritical04: indeterminate
> +spintrcritical05: indeterminate
> +spintrcritical06: indeterminate
> +spintrcritical07: indeterminate
> +spintrcritical08: indeterminate
> +spintrcritical09: indeterminate
> +spintrcritical10: indeterminate
> +spintrcritical11: indeterminate
> +spintrcritical12: indeterminate
> +spintrcritical13: indeterminate
> +spintrcritical14: indeterminate
> +spintrcritical15: indeterminate
> +spintrcritical16: indeterminate
> +spintrcritical17: indeterminate
> +spintrcritical18: indeterminate
> +spintrcritical19: indeterminate
> +spintrcritical20: indeterminate
> +spintrcritical21: indeterminate
> +spintrcritical22: indeterminate
> +spintrcritical23: indeterminate
> +spintrcritical24: indeterminate
>  build-type: option
>  copyrights:
>  - Copyright (C) 2021 Gedare Bloom 
> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml 
> b/spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml
> index efe0b82..06929ed 100644
> --- a/spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml
> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/tstqemu.yml
> @@ -1,20 +1,26 @@
>  SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  actions:
>  - set-test-state:
> -# expected to fail
> +# This test fails when ran through rtems-tester because it does not
> +# produce any output.
>  minimum: exclude
>
> -# don't compile due to toolchain issues
> +# These tests do not compile due to an issue with the GNU Assembler.
> +# The issue has been filed(https://devel.rtems.org/ticket/4218).
> +# Once the issue has been fixed, these tests will be turned back on.
>  spconfig01: exclude
>  spmisc01: exclude
>
> -# tests that are passing intermittently
> +# These tests may or may not fail, however, they do pass on real 
> hardware.
> +# It seems to be an issue with Qemu.
>  spcpucounter01: indeterminate
> +sptimecounter01: indeterminate
>  rtmonuse: indeterminate
> -sp68: indeterminate
>  sp04: indeterminate
>  sp20: indeterminate
> +sp68: indeterminate
>  sp69: indeterminate
> +sp71: indeterminate
>  rtmonusxtimes01: indeterminate
>  spedfsched02: indeterminate
>  spedfsched04: indeterminate
> @@ -24,12 +30,34 @@ actions:
>  sptimecounter04: indeterminate
>  ttest02: indeterminate
>
> -# tests that pass nominally, but fail under Qemu when the host is under
> -# heavy load
> +# These tests may or may not fail, however, they do pass on real 
> hardware.
> +# It seems to be an issue with Qemu, and that this only occurs when the
> +# host machine is under a heavy load.
>  psx12: indeterminate
> +spintrcritical01: indeterminate
> +spintrcritical02: indeterminate
>  spintrcritical03: indeterminate
>  spintrcritical04: indeterminate
>  spintrcritical05: indeterminate
> +spintrcritical06: indeterminate
> +spintrcritical07: indeterminate
> +spintrcritical08: indeterminate
> +spintrcritical09: indeterminate
> +spintrcritical10: indeterminate
> +spintrcritical11: indeterminate
> +spintrcritical12: indeterminate
> +spintrcritical13: indeterminate
> +spintrcritical14: indeterminate
> +spintrcritical15: indeterminate
&g

Re: [PATCH] gdb: prefere python3 if it is installed

2021-08-19 Thread Gedare Bloom
I have no problem with this. I think it is sensible to look for
python3 before python2. At some point we'll have to stop looking for
python2 :)

On Thu, Aug 19, 2021 at 3:24 AM Christian MAUDERER
 wrote:
>
> PS: I had the problem on the 5 branch of RTEMS source builder. I think
> we should apply a patch to both: master and the 5 branch.
>
> Am 19.08.21 um 10:34 schrieb Christian Mauderer:
> > More and more systems stop shipping python2. So we should start to
> > prefer python3 over python2. For building gdb it is not only necessary
> > to have a python binary installed, but also the matching python-devel
> > packet. On a lot of hosts that will now be more often python3-devel
> > and not python2-devel.
> > ---
> >
> > Note: Please see that patch more as an suggestion / base for
> > discussion. I'm open to better solutions.
> >
> > My problem that triggered this patch was a build of a toolchain on a
> > github CI/CD system that has been originally set up by one of our
> > users (see [1] for the log). It seems that on the "macos-latest"
> > machines a python2 is installed but no python2 headers are found.
> > Homebrew - which could be used earlier on MacOS to install the
> > necessary headers - dropped the python@2 packet. So it seems that on a
> > modern MacOS there is no possibility to get python2 headers. If
> > python2 is still installed on the machine (for whatever reason), it is
> > not possible to successfully use RTEMS source builder to build a gdb.
> > If python3 is preferred instead, that should solve the problem.
> >
> > Note that at the moment I only tried it on my OpenSUSE-Linux machine.
> > For that I made sure that I have python2 and python3 installed but no
> > python-devel (which is python2 on OpenSUSE). Earlier I know that I
> > needed python-devel to build gdb. With this patch, I can build with
> > only python3-devel.
> >
> > I'll try to add that patch to the CI too to see whether it works on
> > MacOS. But I'm a bit unsure what other problems this patch could
> > trigger and therefore I want to start a discussion early.
> >
> > Best regards
> >
> > Christian
> >
> > [1] https://github.com/grisp/grisp2-rtems-toolchain/runs/3362717606
> >  Note: The "Get Errorinfo" step prints the rsb-report-*.txt
> >
> >
> >   source-builder/config/gdb-common-1.cfg | 6 +++---
> >   1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/source-builder/config/gdb-common-1.cfg 
> > b/source-builder/config/gdb-common-1.cfg
> > index 397d44d..42fe263 100644
> > --- a/source-builder/config/gdb-common-1.cfg
> > +++ b/source-builder/config/gdb-common-1.cfg
> > @@ -42,7 +42,7 @@
> >   # 2. Does the version of gdb specify a version of python that must be
> >   #used. Override with '%define gdb-python-version python2'.
> >   #
> > -# 3. Search for 'python2' and if not found search for 'python3'.
> > +# 3. Search for 'python3' and if not found search for 'python2'.
> >   #
> >   %if %{defined gdb-python2}
> > %define gdb-enable-python %{gdb_python2}
> > @@ -53,9 +53,9 @@
> >   %if %{defined gdb-python-version}
> > %define gdb-enable-python %(command -v %{gdb-python-version} || 
> > true)
> >   %else
> > -  %define gdb-enable-python %(command -v python2 || true)
> > +  %define gdb-enable-python %(command -v python3 || true)
> > %if %{gdb-enable-python} == %{nil}
> > -%define gdb-enable-python %(command -v python3 || true)
> > +%define gdb-enable-python %(command -v python2 || true)
> > %endif
> > %if %{gdb-enable-python} == %{nil}
> > %define gdb-enable-python %(command -v python || true})
> >
>
> --
> 
> embedded brains GmbH
> Herr Christian MAUDERER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: christian.maude...@embedded-brains.de
> phone: +49-89-18 94 741 - 18
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> 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: Xilinx Zynq console rx not working

2021-08-18 Thread Gedare Bloom
On Mon, Aug 16, 2021 at 11:13 PM Chris Johns  wrote:
>
> On 17/8/21 8:59 am, Chris Johns wrote:
> > On 16/8/21 11:03 pm, Kinsey Moore wrote:
> >> On 8/16/2021 04:45, Chris Johns wrote:
> >>> On 16/8/21 6:38 pm, Chris Johns wrote:
>  I have taken a closer look at the driver. I am receiving RX interrupts 
>  and the
>  characters are being queued however the receive FIFO trigger interrupt 
>  is only
>  raised when the FIFO reaches the set threshold of half the FIFO size. I 
>  suspect
>  there is an assumption the RX timeout will fire but it is not.
> 
> >>> Doing this is questionable 
> >>>
> >>> https://git.rtems.org/rtems/tree/bsps/shared/dev/serial/zynq-uart.c#n222
> >>>
> >>> You cannot send a character when touching the attributes. Where is this 
> >>> hardware
> >>> bug documented by Xilinx?
> >> The attributes are done being touched and the TX/RX enable flags are set 
> >> again
> >> before sending the character. I was seeing the same behavior on Zynq QEMU 
> >> even
> >> with this code removed.
> >>
> >> I couldn't find the hardware bug documented anywhere, but out of the 3 
> >> ZynqMP
> >> boards I have one requires this consistently.
> >
> > I suggest we use chip maker errata when documenting hardware bugs as it 
> > could
> > turn out to be a bug in a our code.
> >
> > This smells to me like a set up problem.
> >
> >>>
> >>> My application does this ...
> >>>
> >>>  if (tcgetattr(fileno(stdout), ) < 0)
> >>>  error_message();
> >>>  cfsetispeed (, B115200);
> >>>  cfsetospeed (, B115200);
> >>>  if (tcsetattr (fileno(stdout), TCSADRAIN, ) < 0)
> >>>  error_message();
> >>>  if (tcgetattr(fileno(stdin), ) < 0)
> >>>  error_message();
> >>>  cfsetispeed (, B115200);
> >>>  cfsetospeed (, B115200);
> >>>  if (tcsetattr (fileno(stdin), TCSADRAIN, ) < 0)
> >>>  error_message();
> >>>
> >>> and this kills the receive interrupts.
> >>
> >> Does removing the null character kick restore functionality for you in 
> >> this case?
> >
> > No it did not.
>
> I have read the Zynq-7000 TRM and the Versal ACAP TRM and there is a 
> difference
> in the wording around the RX timeout. It seems the RX timeout has evolved in 
> the
> Versal to a timer that can interrupt if data has entered the FIFO then no more
> within the timeout period and the FIFO trigger level has not been reached. The
> timer on the Zynq does not do this. It is something that can handle inter-gap
> checks for those serial protocols that require this and there a few of them.
> They delimit frames using time domain signalling. To make it work on a 
> zynq-7000
> I think you need to receive the first character (rtrig=1) then in the 
> interrupt
> handler raise the FIFO trigger level and prime the timer to achieve the Versal
> timer functionality. I cannot be bothered doing this.
>
> All we have is a console and that is a pretty basic use case for a UART. As a
> result I have lowered the RX trigger level to 1 and disabled the RX timer. I
> have also added support to send a FIFO full of data.
>
> The solution is not as optimal as it could be with the Versal UART. If this
> becomes a problem and someone wants a lower interrupt count we can look
> specialising the driver based on the variant of the UART or implement the 
> timer
> protocol I outlined above.
>
> I will create a patch and test on qemu and the Versal then post.
>

We should capture this discussion/outcome in the BSP doco:
https://docs.rtems.org/branches/master/user/bsps/index.html

> Chris
>
> ___
> 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: Xilinx Zynq console rx not working

2021-08-18 Thread Gedare Bloom
On Mon, Aug 16, 2021 at 4:59 PM Chris Johns  wrote:
>
> On 16/8/21 11:03 pm, Kinsey Moore wrote:
> > On 8/16/2021 04:45, Chris Johns wrote:
> >> On 16/8/21 6:38 pm, Chris Johns wrote:
> >>> I have taken a closer look at the driver. I am receiving RX interrupts 
> >>> and the
> >>> characters are being queued however the receive FIFO trigger interrupt is 
> >>> only
> >>> raised when the FIFO reaches the set threshold of half the FIFO size. I 
> >>> suspect
> >>> there is an assumption the RX timeout will fire but it is not.
> >>>
> >> Doing this is questionable 
> >>
> >> https://git.rtems.org/rtems/tree/bsps/shared/dev/serial/zynq-uart.c#n222
> >>
> >> You cannot send a character when touching the attributes. Where is this 
> >> hardware
> >> bug documented by Xilinx?
> > The attributes are done being touched and the TX/RX enable flags are set 
> > again
> > before sending the character. I was seeing the same behavior on Zynq QEMU 
> > even
> > with this code removed.
> >
> > I couldn't find the hardware bug documented anywhere, but out of the 3 
> > ZynqMP
> > boards I have one requires this consistently.
>
> I suggest we use chip maker errata when documenting hardware bugs as it could
> turn out to be a bug in a our code.
>
+1

> This smells to me like a set up problem.

Or even a hardware-specific defect in a shipped board. We've all seen
those before.

>
> >>
> >> My application does this ...
> >>
> >>  if (tcgetattr(fileno(stdout), ) < 0)
> >>  error_message();
> >>  cfsetispeed (, B115200);
> >>  cfsetospeed (, B115200);
> >>  if (tcsetattr (fileno(stdout), TCSADRAIN, ) < 0)
> >>  error_message();
> >>  if (tcgetattr(fileno(stdin), ) < 0)
> >>  error_message();
> >>  cfsetispeed (, B115200);
> >>  cfsetospeed (, B115200);
> >>  if (tcsetattr (fileno(stdin), TCSADRAIN, ) < 0)
> >>  error_message();
> >>
> >> and this kills the receive interrupts.
> >
> > Does removing the null character kick restore functionality for you in this 
> > case?
>
> No it did not.
>
> Chris
> ___
> 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] cpukit/mghttpd: Support all descriptors in select

2021-08-18 Thread Gedare Bloom
On Tue, Aug 17, 2021 at 7:20 AM Joel Sherrill  wrote:
>
> Looks ok.
>
> On Tue, Aug 17, 2021, 3:49 AM  wrote:
>>
>> From: Chris Johns 
>>
>> - Support all possible descriptors in a select call. Borrowed
>>   from Christain and his mDNS change in LibBSD
>>
>> - If select (or poll) fails pause for a bit rather than
>>   locking up in a hard loop

This raises again the different question about maintaining a fork of
mghttpd or replacing it with something else (civetweb?). Until we
resolve that, please protect this code with ifdef/ifndef blocks to
preserve changes.

>> ---
>>  cpukit/mghttpd/mongoose.c | 28 
>>  1 file changed, 28 insertions(+)
>>
>> diff --git a/cpukit/mghttpd/mongoose.c b/cpukit/mghttpd/mongoose.c
>> index 0736c836ec..5e7e68e7ea 100644
>> --- a/cpukit/mghttpd/mongoose.c
>> +++ b/cpukit/mghttpd/mongoose.c
>> @@ -81,6 +81,12 @@
>>  #include 
>>  #include 
>>
>> +#if __rtems__
>> +#include 
>> +#include 
>> +#include 
>> +#endif
>> +
remove changes outside of the #ifdef section

>>  #if defined(_WIN32) && !defined(__SYMBIAN32__) // Windows specific
>>  #undef _WIN32_WINNT
>>  #define _WIN32_WINNT 0x0400 // To make it link in VS2005
>> @@ -1516,13 +1522,32 @@ static int set_non_blocking_mode(SOCKET sock) {
>>  #ifndef HAVE_POLL
>>  static int poll(struct pollfd *pfd, int n, int milliseconds) {
>>struct timeval tv;
>> +#if __rtems__
>> +  #define set (*set_prealloc)
>> +  static fd_set *set_prealloc;
>> +  static size_t set_size;
>> +#else
>>fd_set set;
>> +#endif
>>int i, result;
>>SOCKET maxfd = 0;
>>
>>tv.tv_sec = milliseconds / 1000;
>>tv.tv_usec = (milliseconds % 1000) * 1000;
>> +#if __rtems__
>> +  if (set_prealloc == NULL) {
>> +set_size =
>> +  sizeof(fd_set) * (howmany(rtems_libio_number_iops, sizeof(fd_set) * 
>> 8));
>> +set_prealloc = malloc(set_size);
>> +if (set_prealloc == NULL) {
>> +  errno = ENOMEM;
>> +  return -1;
>> +}
>> +  }
>> +  memset(set_prealloc, 0, set_size);
>> +#else
>>FD_ZERO();
>> +#endif
>>
>>for (i = 0; i < n; i++) {
>>  FD_SET((SOCKET) pfd[i].fd, );
>> @@ -5367,6 +5392,9 @@ static void *master_thread(void *thread_func_param) {
>>accept_new_connection(>listening_sockets[i], ctx);
>>  }
>>}
>> +} else {
>> +  struct timespec t = { .tv_sec = 0, .tv_nsec = 5L };
>> +  nanosleep(, );
Add #ifdef __rtems__

>>  }
>>}
>>free(pfd);
>> --
>> 2.19.1
>>
>> ___
>> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH rtems 2/2] termios: Pass number of sent chars to l_start

2021-08-12 Thread Gedare Bloom
This is fine, but should do some testing on a few BSPs if you can.

On Thu, Aug 12, 2021 at 5:42 AM Christian Mauderer
 wrote:
>
> At the moment the line discipline start function (l_start) has no
> possibility to get feedback about the number of characters that have
> been sent. This patch passes that information via an additional
> parameter.
>
> The change might trigger a warning on existing code because of a pointer
> mismatch but it shouldn't break it. An existing function with the old
> API will just ignore the additional parameter.
>
> Update #4493
> ---
>  cpukit/include/rtems/termiostypes.h | 6 +-
>  cpukit/libcsupport/src/termios.c| 5 +++--
>  2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/cpukit/include/rtems/termiostypes.h 
> b/cpukit/include/rtems/termiostypes.h
> index ef2c958271..5821d52775 100644
> --- a/cpukit/include/rtems/termiostypes.h
> +++ b/cpukit/include/rtems/termiostypes.h
> @@ -367,6 +367,10 @@ typedef struct rtems_termios_tty {
> */
>rtems_idrxTaskId;
>rtems_idtxTaskId;
> +  /*
> +   * Information for the tx task how many characters have been dequeued.
> +   */
> +  int txTaskCharsDequeued;
>
>/*
> * line discipline related stuff
> @@ -482,7 +486,7 @@ struct rtems_termios_linesw {
>int (*l_read )(struct rtems_termios_tty *tp,rtems_libio_rw_args_t *args);
>int (*l_write)(struct rtems_termios_tty *tp,rtems_libio_rw_args_t *args);
>int (*l_rint )(int c,struct rtems_termios_tty *tp);
> -  int (*l_start)(struct rtems_termios_tty *tp);
> +  int (*l_start)(struct rtems_termios_tty *tp,int len);
>int (*l_ioctl)(struct rtems_termios_tty *tp,rtems_libio_ioctl_args_t 
> *args);
>int (*l_modem)(struct rtems_termios_tty *tp,int flags);
>  };
> diff --git a/cpukit/libcsupport/src/termios.c 
> b/cpukit/libcsupport/src/termios.c
> index 829c2bf158..4a4a7e77ac 100644
> --- a/cpukit/libcsupport/src/termios.c
> +++ b/cpukit/libcsupport/src/termios.c
> @@ -1969,6 +1969,7 @@ rtems_termios_dequeue_characters (void *ttyp, int len)
>  /*
>   * send wake up to transmitter task
>   */
> +tty->txTaskCharsDequeued = len;
>  sc = rtems_event_send(tty->txTaskId, TERMIOS_TX_START_EVENT);
>  if (sc != RTEMS_SUCCESSFUL)
>rtems_fatal_error_occurred (sc);
> @@ -1980,7 +1981,7 @@ rtems_termios_dequeue_characters (void *ttyp, int len)
>   * call PPP line discipline start function
>   */
>  if (rtems_termios_linesw[tty->t_line].l_start != NULL) {
> -  rtems_termios_linesw[tty->t_line].l_start(tty);
> +  rtems_termios_linesw[tty->t_line].l_start(tty, len);
>  }
>  return 0; /* nothing to output in IRQ... */
>}
> @@ -2015,7 +2016,7 @@ static rtems_task 
> rtems_termios_txdaemon(rtems_task_argument argument)
>   * call any line discipline start function
>   */
>  if (rtems_termios_linesw[tty->t_line].l_start != NULL) {
> -  rtems_termios_linesw[tty->t_line].l_start(tty);
> +  rtems_termios_linesw[tty->t_line].l_start(tty, 
> tty->txTaskCharsDequeued);
>
>if (tty->t_line == PPPDISC) {
>  /*
> --
> 2.31.1
>
> ___
> 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 rtems-libbsd] ppp: Fix transmitting data

2021-08-12 Thread Gedare Bloom
looks ok, but hold until chris pushes his big patches through I think.
(Not that it should conflict, but I think it will be better this way.)

On Thu, Aug 12, 2021 at 5:42 AM Christian Mauderer
 wrote:
>
> The pppstart expected that a driver write would somehow magically
> process all data passed to the write function. Because ppp disables all
> buffering that originally has been in termios, that assumption is not
> true for all but polled drivers.
>
> With this patch, the pppstart now gets and processes the feedback that
> is returned from the driver via rtems_termios_dequeue_characters.
>
> Fixes #4493
> ---
>  rtemsbsd/sys/net/if_ppp.c| 11 ++-
>  rtemsbsd/sys/net/if_pppvar.h |  1 +
>  rtemsbsd/sys/net/ppp_tty.c   | 32 
>  3 files changed, 35 insertions(+), 9 deletions(-)
>
> diff --git a/rtemsbsd/sys/net/if_ppp.c b/rtemsbsd/sys/net/if_ppp.c
> index 709f13e04..e134dc760 100644
> --- a/rtemsbsd/sys/net/if_ppp.c
> +++ b/rtemsbsd/sys/net/if_ppp.c
> @@ -313,11 +313,12 @@ static rtems_task ppp_txdaemon(rtems_task_argument arg)
>frag=0;
>
>/* initialize output values */
> -  sc->sc_outfcs= PPP_INITFCS;
> -  sc->sc_outbuf= (u_char *)0;
> -  sc->sc_outlen= (short   )0;
> -  sc->sc_outoff= (short   )0;
> -  sc->sc_outfcslen = (short   )0;
> +  sc->sc_outfcs= PPP_INITFCS;
> +  sc->sc_outbuf= (u_char *)0;
> +  sc->sc_outlen= (short   )0;
> +  sc->sc_outoff= (short   )0;
> +  sc->sc_outoff_update = false;
> +  sc->sc_outfcslen = (short   )0;
>
>  /*   printf("Start Transmit Packet..\n"); */
>
> diff --git a/rtemsbsd/sys/net/if_pppvar.h b/rtemsbsd/sys/net/if_pppvar.h
> index fdfb56df0..bd11bcbc4 100644
> --- a/rtemsbsd/sys/net/if_pppvar.h
> +++ b/rtemsbsd/sys/net/if_pppvar.h
> @@ -117,6 +117,7 @@ struct ppp_softc {
>
> struct  ifqueue sc_freeq;   /* free packets */
> short   sc_outoff;  /* output packet byte offset */
> +   boolsc_outoff_update;   /* outoff needs update in pppstart */
> short   sc_outflag; /* output status flag */
> short   sc_outlen;  /* length of output packet */
> short   sc_outfcslen;   /* length of output fcs data */
> diff --git a/rtemsbsd/sys/net/ppp_tty.c b/rtemsbsd/sys/net/ppp_tty.c
> index 80d4fee16..2e850dc77 100644
> --- a/rtemsbsd/sys/net/ppp_tty.c
> +++ b/rtemsbsd/sys/net/ppp_tty.c
> @@ -124,7 +124,7 @@ int pppread(struct rtems_termios_tty *tty, 
> rtems_libio_rw_args_t *rw_args);
>  int pppwrite(struct rtems_termios_tty *tty, rtems_libio_rw_args_t 
> *rw_args);
>  int ppptioctl(struct rtems_termios_tty *tty, rtems_libio_ioctl_args_t 
> *args);
>  int pppinput(int c, struct rtems_termios_tty *tty);
> -int pppstart(struct rtems_termios_tty *tp);
> +int pppstart(struct rtems_termios_tty *tp, int len);
>  u_short pppfcs(u_short fcs, u_char *cp, int len);
>  voidpppallocmbuf(struct ppp_softc *sc, struct mbuf **mp);
>
> @@ -557,7 +557,7 @@ pppasyncctlp(
>   * Called at spltty or higher.
>   */
>  int
> -pppstart(struct rtems_termios_tty *tp)
> +pppstart(struct rtems_termios_tty *tp, int len)
>  {
>u_char *sendBegin;
>u_long  ioffset = (u_long   )0;
> @@ -567,6 +567,13 @@ pppstart(struct rtems_termios_tty *tp)
>
>/* ensure input is valid and we are busy */
>if (( sc != NULL ) && ( sc->sc_outflag & SC_TX_BUSY )) {
> +/* Adapt offsets if necessary */
> +if ( sc->sc_outoff_update ) {
> +  sc->sc_stats.ppp_obytes += len;
> +  sc->sc_outoff += len;
> +  sc->sc_outoff_update = false;
> +}
> +
>  /* check to see if we need to get the next buffer */
>
>  /* Ready with PPP_FLAG Character ? */
> @@ -644,8 +651,25 @@ pppstart(struct rtems_termios_tty *tp)
>
>/* write out the character(s) and update the stats */
>(*tp->handler.write)(ctx, (char *)sendBegin, (ioffset > 0) ? ioffset : 
> 1);
> -  sc->sc_stats.ppp_obytes += (ioffset > 0) ? ioffset : 1;
> -  sc->sc_outoff += ioffset;
> +  /*
> +   * In case of polled drivers, everything is sent here. So adapt the
> +   * offsets. In case of interrupt or task driven drivers, we don't know
> +   * whether all characters have been sent. We only get feedback via
> +   * rtems_termios_dequeue_characters() function which is the one that is
> +   * calling us.
> +   */
> +  if (tp->handler.mode == TERMIOS_POLLED) {
> +sc->sc_stats.ppp_obytes += (ioffset > 0) ? ioffset : 1;
> +sc->sc_outoff += ioffset;
> +sc->sc_outoff_update = false;
> +  } else {
> +if (ioffset > 0) {
> +  sc->sc_outoff_update = true;
> +} else {
> +  sc->sc_outoff_update = false;
> +  sc->sc_stats.ppp_obytes += 1;
> +}
> +  }
>
>return (0);
>  }
> --
> 2.31.1
>
> 

Re: [PATCH v2] score: Replace priority prepend it with an enum

2021-08-12 Thread Gedare Bloom
looks good to me.

On Thu, Aug 12, 2021 at 8:26 AM Sebastian Huber
 wrote:
>
> Use the new Priority_Group_order enum instead of a boolean to indicated if a
> priority should be inserted as the first or last node into its priority group.
> This makes the code more expressive.  It is also a bit more efficient since a
> branch in _Scheduler_Node_set_priority() is avoided and a simple bitwise or
> operation can be used.
> ---
> v2:
>
> Rename Priority_Flags in Priority_Group_order.
>
>  cpukit/include/rtems/posix/muteximpl.h|  2 +-
>  cpukit/include/rtems/score/coremuteximpl.h|  2 +-
>  cpukit/include/rtems/score/priorityimpl.h | 44 ++-
>  cpukit/include/rtems/score/schedulerimpl.h| 12 -
>  .../include/rtems/score/schedulernodeimpl.h   | 30 ++---
>  cpukit/include/rtems/score/threadimpl.h   | 20 +
>  cpukit/posix/src/pthreadsetschedparam.c   |  2 +-
>  cpukit/posix/src/pthreadsetschedprio.c|  2 +-
>  cpukit/rtems/src/tasksetpriority.c|  2 +-
>  cpukit/score/src/scheduleredfreleasejob.c |  2 +-
>  cpukit/score/src/threadchangepriority.c   | 39 +---
>  cpukit/score/src/threadqops.c | 18 
>  cpukit/score/src/threadrestart.c  |  4 +-
>  testsuites/smptests/smpscheduler03/test.c | 33 +++---
>  14 files changed, 126 insertions(+), 86 deletions(-)
>
> diff --git a/cpukit/include/rtems/posix/muteximpl.h 
> b/cpukit/include/rtems/posix/muteximpl.h
> index 435b43634d..5d20bc1ef6 100644
> --- a/cpukit/include/rtems/posix/muteximpl.h
> +++ b/cpukit/include/rtems/posix/muteximpl.h
> @@ -273,7 +273,7 @@ RTEMS_INLINE_ROUTINE void _POSIX_Mutex_Set_priority(
>owner,
>_mutex->Priority_ceiling,
>priority_ceiling,
> -  false,
> +  PRIORITY_GROUP_LAST,
>queue_context
>  );
>  _Thread_Wait_release( owner, queue_context );
> diff --git a/cpukit/include/rtems/score/coremuteximpl.h 
> b/cpukit/include/rtems/score/coremuteximpl.h
> index cbc1e720fb..426c4c5a95 100644
> --- a/cpukit/include/rtems/score/coremuteximpl.h
> +++ b/cpukit/include/rtems/score/coremuteximpl.h
> @@ -375,7 +375,7 @@ RTEMS_INLINE_ROUTINE void 
> _CORE_ceiling_mutex_Set_priority(
>owner,
>_mutex->Priority_ceiling,
>priority_ceiling,
> -  false,
> +  PRIORITY_GROUP_LAST,
>queue_context
>  );
>  _Thread_Wait_release( owner, queue_context );
> diff --git a/cpukit/include/rtems/score/priorityimpl.h 
> b/cpukit/include/rtems/score/priorityimpl.h
> index 7a14ec97b8..2895a0c4a5 100644
> --- a/cpukit/include/rtems/score/priorityimpl.h
> +++ b/cpukit/include/rtems/score/priorityimpl.h
> @@ -37,6 +37,29 @@ extern "C" {
>   * @{
>   */
>
> + /**
> +  * @brief The priority group order determines if a priority node is inserted
> +  *   as the first or last node into its priority group.
> +  *
> +  * The values of the enumerators matter.  The least significant bit of a
> +  * ::Priority_Control value is not used for the actual priority of a node.
> +  * During insertion the least significant bit is used to determine the
> +  * ordering within a priority group based on the enumerator values.
> +  */
> +typedef enum {
> +  /**
> +   * @brief Priority group first option requests that the priority node is
> +   *   inserted as the first node into its priority group.
> +   */
> +  PRIORITY_GROUP_FIRST = 0,
> +
> +  /**
> +   * @brief Priority group last option requests that the priority node is
> +   *   inserted as the last node into its priority group.
> +   */
> +  PRIORITY_GROUP_LAST = 1
> +} Priority_Group_order;
> +
>  /**
>   * @brief Initializes the priority actions empty.
>   *
> @@ -465,7 +488,7 @@ typedef void ( *Priority_Add_handler )(
>
>  typedef void ( *Priority_Change_handler )(
>Priority_Aggregation *aggregation,
> -  bool  prepend_it,
> +  Priority_Group_order  group_order,
>Priority_Actions *actions,
>void *arg
>  );
> @@ -482,19 +505,19 @@ typedef void ( *Priority_Remove_handler )(
>   * This method does nothing.
>   *
>   * @param aggregation Is ignored by the method.
> - * @param prepend_it Is ignored by the method.
> + * @param group_order Is ignored by the method.
>   * @param actions Is ignored by the method.
>   * @param arg Is ignored by the method.
>   */
>  RTEMS_INLINE_ROUTINE void _Priority_Change_nothing(
>Priority_Aggregation *aggregation,
> -  bool  prepend_it,
> +  Priority_Group_order  group_order,
>Priority_Actions *actions,
>void *arg
>  )
>  {
>(void) aggregation;
> -  (void) prepend_it;
> +  (void) group_order;
>(void) actions;
>(void) arg;
>  }
> @@ -547,7 +570,7 @@ RTEMS_INLINE_ROUTINE void _Priority_Non_empty_insert(
>
>if ( is_new_minimum ) {
>  aggregation->Node.priority = node->priority;
> -( *change )( aggregation, false, actions, arg );
> +( *change )( aggregation, 

Re: [PATCH] GcovData.cc: Fix out-of-bounds access errors

2021-08-12 Thread Gedare Bloom
On Thu, Aug 12, 2021 at 7:54 AM Ryan Long  wrote:
>
> Would you need to check if length < sizeof(gcov_preamble) since length is 
> assigned that value?
>
No, but my question is about 'preamble'. If there's a difference
between 'preamble' and 'gcov_preamble', then that should be checked.
If they should be the same, that should be asserted, probably.

> -Original Message-----
> From: Gedare Bloom 
> Sent: Wednesday, August 11, 2021 11:13 AM
> To: Ryan Long 
> Cc: devel@rtems.org
> Subject: Re: [PATCH] GcovData.cc: Fix out-of-bounds access errors
>
> On Wed, Aug 11, 2021 at 8:06 AM Ryan Long  wrote:
> >
> > Adjusted number of bytes to be read
> >
> > CID 1506208: Out-of-bounds access
> > CID 1506209: Out-of-bounds access
> >
> > Closes #4485
> > ---
> >  tester/covoar/GcovData.cc | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/tester/covoar/GcovData.cc b/tester/covoar/GcovData.cc
> > index 02e7489..da0cc2a 100644
> > --- a/tester/covoar/GcovData.cc
> > +++ b/tester/covoar/GcovData.cc
> > @@ -129,7 +129,7 @@ namespace Gcov {
> >  preamble.timestamp = gcnoPreamble.timestamp;
> >
> >  //Write preamble
> > -gcdaFile.write( (char *)  , 4 * sizeof( preamble ) );
> > +gcdaFile.write( (char *)  , sizeof( preamble ) );
> >  if ( gcdaFile.fail() ) {
> >std::cerr << "Error while writing gcda preamble to a file "
> >  << gcdaFileName << std::endl; @@ -402,8 +402,8 @@
> > namespace Gcov {
> >  int length;
> >
> >  length = sizeof( gcov_preamble );
> > -gcovFile.read( (char *) , 4 * sizeof( gcov_preamble ) );
> > -if ( gcovFile.gcount() != 4 * sizeof( gcov_preamble ) ) {
> > +gcovFile.read( (char *) , length );
> Does something ensure that sizeof(preamble) < length?
>
> regardless, the patch looks like an improvement, go ahead.
>
> > +if ( gcovFile.gcount() != length ) {
> >std::cerr << "Error while reading file preamble" << std::endl;
> >return -1;
> >  }
> > --
> > 1.8.3.1
> >
> > ___
> > 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] score: Simplify _Scheduler_Tick()

2021-08-12 Thread Gedare Bloom
ok

On Thu, Aug 12, 2021 at 3:11 AM Sebastian Huber
 wrote:
>
> The NULL pointer check for the executing thread was introduced by
> commit:
>
> commit be3c257286ad870d8d1a64941cde53fd2d33a633
> Author: Sebastian Huber 
> Date:   Thu Jun 5 11:17:26 2014 +0200
>
> score: Avoid NULL pointer access
>
> Check that the executing thread is not NULL in _Scheduler_Tick().  It
> may be NULL in case the processor has an optional scheduler assigned and
> the system was not able to start the processor.
>
> However, it is no longer necessary since now the clock interrupt is
> distributed to the online processors.
> ---
>  cpukit/include/rtems/score/schedulerimpl.h | 26 ++
>  1 file changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/schedulerimpl.h 
> b/cpukit/include/rtems/score/schedulerimpl.h
> index 586f9e0ec8..7b0658073e 100644
> --- a/cpukit/include/rtems/score/schedulerimpl.h
> +++ b/cpukit/include/rtems/score/schedulerimpl.h
> @@ -611,12 +611,30 @@ RTEMS_INLINE_ROUTINE void _Scheduler_Cancel_job(
>   */
>  RTEMS_INLINE_ROUTINE void _Scheduler_Tick( const Per_CPU_Control *cpu )
>  {
> -  const Scheduler_Control *scheduler = _Scheduler_Get_by_CPU( cpu );
> -  Thread_Control *executing = cpu->executing;
> +  const Scheduler_Control *scheduler;
> +  Thread_Control  *executing;
> +
> +  scheduler = _Scheduler_Get_by_CPU( cpu );
>
> -  if ( scheduler != NULL && executing != NULL ) {
> -( *scheduler->Operations.tick )( scheduler, executing );
> +#if defined(RTEMS_SMP)
> +  if ( scheduler == NULL ) {
> +/*
> + * In SMP configurations, processors may be removed/added at runtime
> + * from/to a scheduler.  There may be still clock interrupts on currently
> + * unassigned processors.
> + */
> +return;
>}
> +#endif
> +
> +  /*
> +   * Each online processor has at least an idle thread as the executing 
> thread
> +   * even in case it has currently no scheduler assigned.  Clock interrupts 
> on
> +   * processors which are not online would be a severe bug of the Clock 
> Driver.
> +   */
> +  executing = _Per_CPU_Get_executing( cpu );
> +  _Assert( executing != NULL );
> +  ( *scheduler->Operations.tick )( scheduler, executing );
>  }
>
>  /**
> --
> 2.26.2
>
> ___
> 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 commit] Test needed for timer_create with CLOCK_MONOTONC

2021-08-11 Thread Gedare Bloom
this was the wrong patch version.

On Wed, Aug 11, 2021 at 11:03 AM Joel Sherrill  wrote:
>
> Module:rtems
> Branch:master
> Commit:8df57649b09f31a58660d9b3c2478195f15f40ce
> Changeset: 
> http://git.rtems.org/rtems/commit/?id=8df57649b09f31a58660d9b3c2478195f15f40ce
>
> Author:Zacchaeus Leung 
> Date:  Fri Aug  6 11:20:41 2021 -0400
>
> Test needed for timer_create with CLOCK_MONOTONC
>
> the timer_create() method can use CLOCK_MONOTONIC
> but there was  no test for this.
> Also it implements the functionality to
> create a CLOCK_MONOTONIC timer and gettime() .
> Closes #3888
>
> ---
>
>  cpukit/include/rtems/posix/timer.h|  1 +
>  cpukit/posix/src/psxtimercreate.c |  3 +-
>  cpukit/posix/src/timergettime.c   | 48 
> +--
>  testsuites/psxtests/psxtimer02/psxtimer.c | 26 +++
>  testsuites/psxtests/psxtimer02/psxtimer02.scn |  5 +++
>  5 files changed, 64 insertions(+), 19 deletions(-)
>
> diff --git a/cpukit/include/rtems/posix/timer.h 
> b/cpukit/include/rtems/posix/timer.h
> index bcbf07a..7ae0891 100644
> --- a/cpukit/include/rtems/posix/timer.h
> +++ b/cpukit/include/rtems/posix/timer.h
> @@ -48,6 +48,7 @@ typedef struct {
>uint32_t  ticks;  /* Number of ticks of the initialization */
>uint32_t  overrun;/* Number of expirations of the timer*/
>struct timespec   time;   /* Time at which the timer was started   */
> +  clockid_t clock_type; /* The type of timer */
>  } POSIX_Timer_Control;
>
>  /**
> diff --git a/cpukit/posix/src/psxtimercreate.c 
> b/cpukit/posix/src/psxtimercreate.c
> index a63cf1d..2b5a101 100644
> --- a/cpukit/posix/src/psxtimercreate.c
> +++ b/cpukit/posix/src/psxtimercreate.c
> @@ -40,7 +40,7 @@ int timer_create(
>  {
>POSIX_Timer_Control *ptimer;
>
> -  if ( clock_id != CLOCK_REALTIME )
> +  if (  clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC )
>  rtems_set_errno_and_return_minus_one( EINVAL );
>
>if ( !timerid )
> @@ -91,6 +91,7 @@ int timer_create(
>ptimer->timer_data.it_value.tv_nsec= 0;
>ptimer->timer_data.it_interval.tv_sec  = 0;
>ptimer->timer_data.it_interval.tv_nsec = 0;
> +  ptimer->clock_type = clock_id;
>
>_Watchdog_Preinitialize( >Timer, _Per_CPU_Get_snapshot() );
>_Watchdog_Initialize( >Timer, _POSIX_Timer_TSR );
> diff --git a/cpukit/posix/src/timergettime.c b/cpukit/posix/src/timergettime.c
> index ee2a566..f4b2596 100644
> --- a/cpukit/posix/src/timergettime.c
> +++ b/cpukit/posix/src/timergettime.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  /*
>   *  - When a timer is initialized, the value of the time in
> @@ -42,32 +43,43 @@ int timer_gettime(
>  )
>  {
>POSIX_Timer_Control *ptimer;
> -  ISR_lock_Context lock_context;
> -  uint64_t now;
> -  uint32_t remaining;
> +  ISR_lock_Context lock_context;
> +  Per_CPU_Control *cpu;
> +  struct timespec now;
> +  struct timespec expire;
> +  struct timespec result;
>
>if ( !value )
>  rtems_set_errno_and_return_minus_one( EINVAL );
>
>ptimer = _POSIX_Timer_Get( timerid, _context );
> -  if ( ptimer != NULL ) {
> -Per_CPU_Control *cpu;
> +  if ( ptimer == NULL ) {
> +rtems_set_errno_and_return_minus_one( EINVAL );
> +  }
>
> -cpu = _POSIX_Timer_Acquire_critical( ptimer, _context );
> -now = cpu->Watchdog.ticks;
> +  cpu = _POSIX_Timer_Acquire_critical( ptimer, _context );
> +  rtems_timespec_from_ticks( ptimer->Timer.expire,  );
>
> -if ( now < ptimer->Timer.expire ) {
> -  remaining = (uint32_t) ( ptimer->Timer.expire - now );
> -} else {
> -  remaining = 0;
> -}
> +  if ( ptimer->clock_type == CLOCK_MONOTONIC ) {
> +  _Timecounter_Nanouptime();
> +  } else  if (ptimer->clock_type == CLOCK_REALTIME) {
> +_TOD_Get();
> +  } else {
> +_POSIX_Timer_Release( cpu, _context );
> +rtems_set_errno_and_return_minus_one( EINVAL );
> +  }
>
> -_Timespec_From_ticks( remaining, >it_value );
> -value->it_interval = ptimer->timer_data.it_interval;
>
> -_POSIX_Timer_Release( cpu, _context );
> -return 0;
> + if ( rtems_timespec_less_than( ,  ) ) {
> +  rtems_timespec_subtract( , ,  );
> +  } else {
> +result.tv_nsec = 0;
> +result.tv_sec  = 0;
>}
>
> -  rtems_set_errno_and_return_minus_one( EINVAL );
> -}
> +  value->it_value = result;
> +  value->it_interval = ptimer->timer_data.it_interval;
> +
> +  _POSIX_Timer_Release( cpu, _context );
> +  return 0;
> +}
> \ No newline at end of file
> diff --git a/testsuites/psxtests/psxtimer02/psxtimer.c 
> b/testsuites/psxtests/psxtimer02/psxtimer.c
> index 9f79d33..874a789 100644
> --- a/testsuites/psxtests/psxtimer02/psxtimer.c
> +++ b/testsuites/psxtests/psxtimer02/psxtimer.c
> @@ -127,6 +127,32 @@ void *POSIX_Init (
>status = timer_delete( timer );
>fatal_posix_service_status_errno( status, EINVAL, "bad id" );
>
> +  puts( 

Re: [PATCH] GcovData.cc: Fix out-of-bounds access errors

2021-08-11 Thread Gedare Bloom
On Wed, Aug 11, 2021 at 8:06 AM Ryan Long  wrote:
>
> Adjusted number of bytes to be read
>
> CID 1506208: Out-of-bounds access
> CID 1506209: Out-of-bounds access
>
> Closes #4485
> ---
>  tester/covoar/GcovData.cc | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tester/covoar/GcovData.cc b/tester/covoar/GcovData.cc
> index 02e7489..da0cc2a 100644
> --- a/tester/covoar/GcovData.cc
> +++ b/tester/covoar/GcovData.cc
> @@ -129,7 +129,7 @@ namespace Gcov {
>  preamble.timestamp = gcnoPreamble.timestamp;
>
>  //Write preamble
> -gcdaFile.write( (char *)  , 4 * sizeof( preamble ) );
> +gcdaFile.write( (char *)  , sizeof( preamble ) );
>  if ( gcdaFile.fail() ) {
>std::cerr << "Error while writing gcda preamble to a file "
>  << gcdaFileName << std::endl;
> @@ -402,8 +402,8 @@ namespace Gcov {
>  int length;
>
>  length = sizeof( gcov_preamble );
> -gcovFile.read( (char *) , 4 * sizeof( gcov_preamble ) );
> -if ( gcovFile.gcount() != 4 * sizeof( gcov_preamble ) ) {
> +gcovFile.read( (char *) , length );
Does something ensure that sizeof(preamble) < length?

regardless, the patch looks like an improvement, go ahead.

> +if ( gcovFile.gcount() != length ) {
>std::cerr << "Error while reading file preamble" << std::endl;
>return -1;
>  }
> --
> 1.8.3.1
>
> ___
> 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: GSoC - Code Formatting and Style Checking for RTEMS score

2021-08-11 Thread Gedare Bloom
On Tue, Aug 10, 2021 at 3:21 PM Ida Delphine  wrote:
>
> Hi everyone,
> I was able to successfully build LLVM from source using "ninja" instead of 
> "make" after a couple of failed attempts because I kept running out of 
> resources.
>
> Is there anything else I am supposed to do as far building LLVM is concerned? 
> Or will every user first have to clone the llvm repo and build it from source 
> like I did?
>
I think it would be good to update/provide RSB recipe for newer
version(s) of LLVM. If you can do that after the GSoC coding period
ends, that would be great.

> On Fri, 16 Jul 2021, 5:28 am Chris Johns,  wrote:
>>
>> Hi,
>>
>> I will bring the discussion to the devel list and I hope the comments are in
>> line with the purpose of the project. Please correct what I say if it is not.
>>
>> The pre-commit script that is in github review is a good base and I believe 
>> it
>> solves that problem for those on Linux. It is a great start and it is nice 
>> to see.
>>
>> The work needs to mature and progress and that means a few things. I was
>> approached by Joel about where this would live in rtems-tools. As the script
>> stands it is not suitable for rtems-tool because the format is specific to 
>> the
>> score code in rtems.git.
>>
>> I think a pre-commit script needs to live in the repo it is for in a spot a 
>> user
>> can copy to the hooks directory of their repo. For example `git-hooks`.
>>
>> A git hooks script for rtems.git needs to run on all the supported hosts or 
>> we
>> may result in patches being left on the floor. If a contributor's host OS is 
>> not
>> supported and the patch is rejected for formatting reasons picked up by the
>> check the contributor may just walk away.
>>
>> The script should use `/usr/bin/env python3` and it needs to check for a 
>> range
>> of `clang-format` instances. FreeBSD has a package that installs the format
>> command as `clang-format10` for LLVM 10 and `clang-format11` for version 11.
>>
>> A contributor being able to run the script may depend on the host having a
>> package or packages installed. Given this is for RTEMS development that is 
>> fine.
>> The script needs to handle any set up errors nicely if something is missing. 
>> I
>> prefer we avoid the "experts" approach to error management.
>>
>> There is possible future work adding a command to rtems-tools. Ida and I
>> discussed this on discord and we decided a command called `rtems-style` 
>> would be
>> nice. It would be nice if that command checked, ie `--mode=check`, a style as
>> well as `--mode=reformat` to automatically reformat a source file.
>>
>> A command for rtems-tools has to support python2 and python3 and it has to
>> handle errors in suitable manner. Printing uncaught exception is not OK. It
>> should also be self contained and not depend on any pip python packages.
>>
>> If an `rtems-style` command is created and installed when rtems-tool is
>> installed the pre-commit git script could be made to use it and so the style 
>> is
>> held in a single location.
>>
>> Finally an rtems-style command could be extended to support python
>> (--lang=python) or other styles for other code formats. This is inline with 
>> our
>> other eco-system interfaces we provide.
>>
>> I hope this helps.
>>
>> Chris
>>
>> On 16/7/21 5:13 am, Ida Delphine wrote:
>> > I will check on this
>> >
>> > On Thu, Jul 15, 2021 at 3:39 PM Gedare Bloom > > <mailto:ged...@rtems.org>> wrote:
>> >
>> > On Thu, Jul 15, 2021 at 5:19 AM Ida Delphine > > <mailto:idad...@gmail.com>> wrote:
>> > >
>> > > Hello everyone,
>> > > From the discussion on discord it looks like clang-format cannot be
>> > installed on MacOS and FreeBSD. Is there any alternative or way to 
>> > have it
>> > on these operating systems?
>> > >
>> > What are the challenges with them? Can clang-format be built from
>> > source on those hosts?
>> >
>> > > On Wed, 5 May 2021, 10:21 pm Ida Delphine, > > <mailto:idad...@gmail.com>> wrote:
>> > >>
>> > >> Hello everyone,
>> > >>
>> > >> Regarding this project (https://devel.rtems.org/ticket/3860
>> > <https://devel.rtems.org/ticket/3860>) I went with clang-format as we 
>> > all
>> > agreed. I 

Re: [PATCH] bsps/raspberrypi: Add SEV Instruction for RPi SMP firmware changes.

2021-08-11 Thread Gedare Bloom
I think this looks fine. Joel, can you check it in?

On Wed, Aug 11, 2021 at 10:01 AM Pranav Dangi  wrote:
>
> ping
>
> On Mon, 9 Aug 2021, 16:43 pranav,  wrote:
>>
>> The Pi firmware added a wfe(wait for event), the cores 1-3 wait
>> for the start address being written to the mailbox register, followed
>> by a SEV poke to the mailbox that acts as a wfe wake-up event.
>> ---
>>  bsps/arm/raspberrypi/start/bspsmp.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/bsps/arm/raspberrypi/start/bspsmp.c 
>> b/bsps/arm/raspberrypi/start/bspsmp.c
>> index 44f7a1d376..9dcfb0fb03 100644
>> --- a/bsps/arm/raspberrypi/start/bspsmp.c
>> +++ b/bsps/arm/raspberrypi/start/bspsmp.c
>> @@ -42,6 +42,7 @@ bool _CPU_SMP_Start_processor( uint32_t cpu_index )
>>if (cpu_index != cpu_index_self) {
>>
>>  BCM2835_REG(BCM2836_MAILBOX_3_WRITE_SET_BASE + 0x10 * cpu_index) = 
>> (uint32_t)_start;
>> +_ARM_Send_event();
>>
>>  /*
>>   * Wait for secondary processor to complete its basic initialization so
>> --
>> 2.30.2
>>
> ___
> 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 2/2] score: Replace the single use of a sequence lock

2021-08-10 Thread Gedare Bloom
ok

On Tue, Aug 10, 2021 at 8:34 AM Sebastian Huber
 wrote:
>
> In SMP configurations, on 64-bit architectures use plain atomic
> operations to set/get the priority value of a scheduler node.  On 32-bit
> architectures use an ISR lock.  Using a sequence lock has no real
> benefit since it uses atomic read-modify-write operations for both the
> read and the write lock.  Simply use a ticket lock instead so that only
> one SMP synchronization primitive is used for everything.
> ---
>  cpukit/include/rtems/score/schedulernode.h| 14 ++--
>  .../include/rtems/score/schedulernodeimpl.h   | 64 +--
>  .../score/src/schedulerdefaultnodedestroy.c   |  4 +-
>  3 files changed, 57 insertions(+), 25 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/schedulernode.h 
> b/cpukit/include/rtems/score/schedulernode.h
> index 1dba200dca..e344479718 100644
> --- a/cpukit/include/rtems/score/schedulernode.h
> +++ b/cpukit/include/rtems/score/schedulernode.h
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  /**
>   * @addtogroup RTEMSScoreScheduler
> @@ -197,14 +197,20 @@ struct Scheduler_Node {
>   * least-significant bit which indicates if the thread should be appended
>   * (bit set) or prepended (bit cleared) to its priority group, see
>   * SCHEDULER_PRIORITY_APPEND().
> + *
> + * @see _Scheduler_Node_get_priority() and 
> _Scheduler_Node_set_priority().
>   */
> +#if defined(RTEMS_SMP) && CPU_SIZEOF_POINTER == 8
> +Atomic_Ulong value;
> +#else
>  Priority_Control value;
> +#endif
>
> -#if defined(RTEMS_SMP)
> +#if defined(RTEMS_SMP) && CPU_SIZEOF_POINTER != 8
>  /**
> - * @brief Sequence lock to synchronize priority value updates.
> + * @brief The lock protects the priority value.
>   */
> -SMP_sequence_lock_Control Lock;
> +ISR_lock_Control Lock;
>  #endif
>} Priority;
>  };
> diff --git a/cpukit/include/rtems/score/schedulernodeimpl.h 
> b/cpukit/include/rtems/score/schedulernodeimpl.h
> index 3da29bb37e..3f90d4a6f5 100644
> --- a/cpukit/include/rtems/score/schedulernodeimpl.h
> +++ b/cpukit/include/rtems/score/schedulernodeimpl.h
> @@ -100,13 +100,36 @@ RTEMS_INLINE_ROUTINE void _Scheduler_Node_do_initialize(
>node->Wait.Priority.scheduler = scheduler;
>node->user = the_thread;
>node->idle = NULL;
> -  _SMP_sequence_lock_Initialize( >Priority.Lock );
> +#if CPU_SIZEOF_POINTER != 8
> +  _ISR_lock_Initialize( >Priority.Lock, "Scheduler Node Priority" );
> +#endif
>  #else
>(void) scheduler;
>(void) the_thread;
>  #endif
>  }
>
> +/**
> + * @brief Destroys a node.
> + *
> + * @param scheduler is the scheduler of the node.
> + *
> + * @param[in, out] node is the node to destroy.
> + */
> +RTEMS_INLINE_ROUTINE void _Scheduler_Node_do_destroy(
> +  const struct _Scheduler_Control *scheduler,
> +  Scheduler_Node  *node
> +)
> +{
> +  (void) scheduler;
> +
> +#if defined(RTEMS_SMP) && CPU_SIZEOF_POINTER != 8
> +  _ISR_lock_Destroy( >Priority.Lock );
> +#else
> +  (void) node;
> +#endif
> +}
> +
>  /**
>   * @brief Gets the scheduler of the node.
>   *
> @@ -148,17 +171,18 @@ RTEMS_INLINE_ROUTINE Priority_Control 
> _Scheduler_Node_get_priority(
>  {
>Priority_Control priority;
>
> -#if defined(RTEMS_SMP)
> -  unsigned int seq;
> -
> -  do {
> -seq = _SMP_sequence_lock_Read_begin( >Priority.Lock );
> -#endif
> -
> -priority = node->Priority.value;
> +#if defined(RTEMS_SMP) && CPU_SIZEOF_POINTER == 8
> +  priority = _Atomic_Fetch_add_ulong(
> +>Priority.value,
> +0,
> +ATOMIC_ORDER_RELAXED
> +  );
> +#else
> +  ISR_lock_Context lock_context;
>
> -#if defined(RTEMS_SMP)
> -  } while ( _SMP_sequence_lock_Read_retry( >Priority.Lock, seq ) );
> +  _ISR_lock_Acquire( >Priority.Lock, _context );
> +  priority = node->Priority.value;
> +  _ISR_lock_Release( >Priority.Lock, _context );
>  #endif
>
>return priority;
> @@ -180,16 +204,18 @@ RTEMS_INLINE_ROUTINE void _Scheduler_Node_set_priority(
>Priority_Flagsflags
>  )
>  {
> -#if defined(RTEMS_SMP)
> -  unsigned int seq;
> -
> -  seq = _SMP_sequence_lock_Write_begin( >Priority.Lock );
> -#endif
> +#if defined(RTEMS_SMP) && CPU_SIZEOF_POINTER == 8
> +  _Atomic_Store_ulong(
> +>Priority.value,
> +new_priority | (Priority_Control) flags,
> +ATOMIC_ORDER_RELAXED
> +  );
> +#else
> +  ISR_lock_Context lock_context;
>
> +  _ISR_lock_Acquire( >Priority.Lock, _context );
>node->Priority.value = new_priority | ( (Priority_Control) flags );
> -
> -#if defined(RTEMS_SMP)
> -  _SMP_sequence_lock_Write_end( >Priority.Lock, seq );
> +  _ISR_lock_Release( >Priority.Lock, _context );
>  #endif
>  }
>
> diff --git a/cpukit/score/src/schedulerdefaultnodedestroy.c 
> b/cpukit/score/src/schedulerdefaultnodedestroy.c
> index 796896d854..33cdfd4c69 100644
> --- a/cpukit/score/src/schedulerdefaultnodedestroy.c
> +++ b/cpukit/score/src/schedulerdefaultnodedestroy.c
> @@ -21,12 +21,12 @@
>  

Re: [PATCH 1/2] score: Replace priority prepend it with flags

2021-08-10 Thread Gedare Bloom
This is a good cleanup. The naming seems a bit off to me, but it's all
internal so we can always adjust it later. (I think it should be
singular "Priority_Flag", but really it's not just a flag, it's
something like the "Priority_Discipline" -- I can't think what is the
right word however for how you decide to break ties.) So you can just
leave it be for now and ignore my rambling. :)

On Tue, Aug 10, 2021 at 8:34 AM Sebastian Huber
 wrote:
>
> Use an enum instead of a boolean to indicated if a priority should be
> appended or prepended to its priority group.  This makes the code more
> expressive and it a bit more efficient since a branch in
> _Scheduler_Node_set_priority() is avoided.
> ---
>  cpukit/include/rtems/posix/muteximpl.h|  2 +-
>  cpukit/include/rtems/score/coremuteximpl.h|  2 +-
>  cpukit/include/rtems/score/priorityimpl.h | 39 +--
>  cpukit/include/rtems/score/schedulerimpl.h| 12 +-
>  .../include/rtems/score/schedulernodeimpl.h   | 26 ++---
>  cpukit/include/rtems/score/threadimpl.h   | 20 +-
>  cpukit/posix/src/pthreadsetschedparam.c   |  2 +-
>  cpukit/posix/src/pthreadsetschedprio.c|  2 +-
>  cpukit/rtems/src/tasksetpriority.c|  2 +-
>  cpukit/score/src/scheduleredfreleasejob.c |  2 +-
>  cpukit/score/src/threadchangepriority.c   | 36 ++---
>  cpukit/score/src/threadqops.c | 18 -
>  cpukit/score/src/threadrestart.c  |  4 +-
>  testsuites/smptests/smpscheduler03/test.c | 33 +---
>  14 files changed, 116 insertions(+), 84 deletions(-)
>
> diff --git a/cpukit/include/rtems/posix/muteximpl.h 
> b/cpukit/include/rtems/posix/muteximpl.h
> index 4a475aac5e..4908f8f259 100644
> --- a/cpukit/include/rtems/posix/muteximpl.h
> +++ b/cpukit/include/rtems/posix/muteximpl.h
> @@ -273,7 +273,7 @@ RTEMS_INLINE_ROUTINE void _POSIX_Mutex_Set_priority(
>owner,
>_mutex->Priority_ceiling,
>priority_ceiling,
> -  false,
> +  PRIORITY_APPEND_FLAG,
>queue_context
>  );
>  _Thread_Wait_release( owner, queue_context );
> diff --git a/cpukit/include/rtems/score/coremuteximpl.h 
> b/cpukit/include/rtems/score/coremuteximpl.h
> index b281c52889..c97ffcf351 100644
> --- a/cpukit/include/rtems/score/coremuteximpl.h
> +++ b/cpukit/include/rtems/score/coremuteximpl.h
> @@ -377,7 +377,7 @@ RTEMS_INLINE_ROUTINE void 
> _CORE_ceiling_mutex_Set_priority(
>owner,
>_mutex->Priority_ceiling,
>priority_ceiling,
> -  false,
> +  PRIORITY_APPEND_FLAG,
>_context
>  );
>  _Thread_Wait_release_critical( owner, _context );
> diff --git a/cpukit/include/rtems/score/priorityimpl.h 
> b/cpukit/include/rtems/score/priorityimpl.h
> index 7a14ec97b8..4958bfc77f 100644
> --- a/cpukit/include/rtems/score/priorityimpl.h
> +++ b/cpukit/include/rtems/score/priorityimpl.h
> @@ -37,6 +37,24 @@ extern "C" {
>   * @{
>   */
>
> + /**
> +  * @brief The priority flags indicate if the priority should be appended or
> +  *   prepended to its priority group.
> +  */
> +typedef enum {
> +  /**
> +   * @brief Priority prepend flag indicates that the priority should be 
> prepended
> +   *   to its priority group.
> +   */
> +  PRIORITY_PREPEND_FLAG = 0,
> +
> +  /**
> +   * @brief Priority append flag indicates that the priority should be 
> appended
> +   *   to its priority group.
> +   */
> +  PRIORITY_APPEND_FLAG = 1
> +} Priority_Flags;
> +
>  /**
>   * @brief Initializes the priority actions empty.
>   *
> @@ -465,7 +483,7 @@ typedef void ( *Priority_Add_handler )(
>
>  typedef void ( *Priority_Change_handler )(
>Priority_Aggregation *aggregation,
> -  bool  prepend_it,
> +  Priority_Flagsflags,
>Priority_Actions *actions,
>void *arg
>  );
> @@ -482,19 +500,19 @@ typedef void ( *Priority_Remove_handler )(
>   * This method does nothing.
>   *
>   * @param aggregation Is ignored by the method.
> - * @param prepend_it Is ignored by the method.
> + * @param flags Is ignored by the method.
>   * @param actions Is ignored by the method.
>   * @param arg Is ignored by the method.
>   */
>  RTEMS_INLINE_ROUTINE void _Priority_Change_nothing(
>Priority_Aggregation *aggregation,
> -  bool  prepend_it,
> +  Priority_Flagsflags,
>Priority_Actions *actions,
>void *arg
>  )
>  {
>(void) aggregation;
> -  (void) prepend_it;
> +  (void) flags;
>(void) actions;
>(void) arg;
>  }
> @@ -547,7 +565,7 @@ RTEMS_INLINE_ROUTINE void _Priority_Non_empty_insert(
>
>if ( is_new_minimum ) {
>  aggregation->Node.priority = node->priority;
> -( *change )( aggregation, false, actions, arg );
> +( *change )( aggregation, PRIORITY_APPEND_FLAG, actions, arg );
>}
>  }
>
> @@ -619,7 +637,7 @@ RTEMS_INLINE_ROUTINE void _Priority_Extract(
>
>  if ( node->priority < min->priority ) {
>

Re: [PATCH] rtems: Fix rtems_partition_return_buffer()

2021-08-10 Thread Gedare Bloom
looks good, maybe one small clarification:

On Tue, Aug 10, 2021 at 4:44 AM Sebastian Huber
 wrote:
>
> The rtems_partition_return_buffer() wrongly accepted which were exactly
> at the buffer area end.  Use the buffer area limit address for the range
> checking.
>
> Close #4490.
> ---
>  cpukit/include/rtems/monitor.h|  2 +-
>  cpukit/include/rtems/rtems/partdata.h |  9 -
>  cpukit/libmisc/monitor/mon-part.c |  5 +++--
>  cpukit/rtems/src/partcreate.c |  8 ++--
>  cpukit/rtems/src/partreturnbuffer.c   | 17 ++---
>  5 files changed, 24 insertions(+), 17 deletions(-)
>
> diff --git a/cpukit/include/rtems/monitor.h b/cpukit/include/rtems/monitor.h
> index d0a79c03be..9367e2b6e8 100644
> --- a/cpukit/include/rtems/monitor.h
> +++ b/cpukit/include/rtems/monitor.h
> @@ -192,7 +192,7 @@ typedef struct {
>  rtems_name  name;
>/* end of common portion */
>rtems_attribute attribute;
> -  void *  start_addr;
> +  const void *start_addr;
>uint32_tlength;
>uint32_tbuf_size;
>uint32_tused_blocks;
> diff --git a/cpukit/include/rtems/rtems/partdata.h 
> b/cpukit/include/rtems/rtems/partdata.h
> index 4f4132ac6b..4c4eca3d17 100644
> --- a/cpukit/include/rtems/rtems/partdata.h
> +++ b/cpukit/include/rtems/rtems/partdata.h
> @@ -50,15 +50,14 @@ typedef struct {
>  #endif
>
>/**
> -   * @brief This member contains the physical starting address of the buffer
> -   *   area.
> +   * @brief This member contains the base address of the buffer area.
Probably it is clear, but could add here "This is the address of the
first valid byte in the buffer." to mirror the suggestion below that
clarifies the meaning of limit.

> */
> -  void *starting_address;
> +  const void *base_address;
>
>/**
> -   * @brief This member contains the size of the buffer area in bytes.
> +   * @brief This member contains the limit address of the buffer area.
Maybe add: "This is the address of the last valid byte in the buffer."

> */
> -  uintptr_t length;
> +  const void *limit_address;
>
>/**
> * @brief This member contains the size of each buffer in bytes.
> diff --git a/cpukit/libmisc/monitor/mon-part.c 
> b/cpukit/libmisc/monitor/mon-part.c
> index 18034cd58f..654700ebfc 100644
> --- a/cpukit/libmisc/monitor/mon-part.c
> +++ b/cpukit/libmisc/monitor/mon-part.c
> @@ -22,8 +22,9 @@ rtems_monitor_part_canonical(
>  const Partition_Control *rtems_part = (const Partition_Control *) 
> part_void;
>
>  canonical_part->attribute = rtems_part->attribute_set;
> -canonical_part->start_addr = rtems_part->starting_address;
> -canonical_part->length = rtems_part->length;
> +canonical_part->start_addr = rtems_part->base_address;
> +canonical_part->length = (uint32_t) ( (uintptr_t)
> +rtems_part->limit_address + 1 - (uintptr_t) rtems_part->base_address 
> );
>  canonical_part->buf_size = rtems_part->buffer_size;
>  canonical_part->used_blocks = rtems_part->number_of_used_blocks;
>  }
> diff --git a/cpukit/rtems/src/partcreate.c b/cpukit/rtems/src/partcreate.c
> index 012a416a1a..61249749f3 100644
> --- a/cpukit/rtems/src/partcreate.c
> +++ b/cpukit/rtems/src/partcreate.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -40,8 +41,11 @@ static void _Partition_Initialize(
>rtems_attributeattribute_set
>  )
>  {
> -  the_partition->starting_address  = starting_address;
> -  the_partition->length= length;
> +  const void *limit_address;
> +
> +  limit_address = _Addresses_Add_offset( starting_address, length - 1 );
> +  the_partition->base_address  = starting_address;
> +  the_partition->limit_address = limit_address;
>the_partition->buffer_size   = buffer_size;
>the_partition->attribute_set = attribute_set;
>the_partition->number_of_used_blocks = 0;
> diff --git a/cpukit/rtems/src/partreturnbuffer.c 
> b/cpukit/rtems/src/partreturnbuffer.c
> index f5ab7d85f9..68302f1163 100644
> --- a/cpukit/rtems/src/partreturnbuffer.c
> +++ b/cpukit/rtems/src/partreturnbuffer.c
> @@ -33,7 +33,7 @@ static bool _Partition_Is_address_on_buffer_boundary(
>
>offset = _Addresses_Subtract(
>  the_buffer,
> -the_partition->starting_address
> +the_partition->base_address
>);
>
>return ( offset % the_partition->buffer_size ) == 0;
> @@ -44,14 +44,17 @@ static bool _Partition_Is_address_a_buffer_begin(
> const void  *the_buffer
>  )
>  {
> -  void *starting;
> -  void *ending;
> +  const void *base;
> +  const void *limit;
>
> -  starting = the_partition->starting_address;
> -  ending   = _Addresses_Add_offset( starting, the_partition->length );
> +  base = the_partition->base_address;
> +  limit = the_partition->limit_address;
>
> -  return _Addresses_Is_in_range( the_buffer, starting, ending )
> -&& 

Re: [PATCH v7] Test needed for timer_create with CLOCK_MONOTONI

2021-08-09 Thread Gedare Bloom
Joel: This looks fine to me.

On Mon, Aug 9, 2021 at 3:58 PM Zacchaeus Leung  wrote:
>
> Closes #3889
> ---
>  cpukit/include/rtems/posix/timer.h|  1 +
>  cpukit/posix/src/psxtimercreate.c |  3 +-
>  cpukit/posix/src/timergettime.c   | 50 ---
>  testsuites/psxtests/psxtimer02/psxtimer.c | 26 ++
>  testsuites/psxtests/psxtimer02/psxtimer02.scn |  6 +++
>  5 files changed, 66 insertions(+), 20 deletions(-)
>
> diff --git a/cpukit/include/rtems/posix/timer.h 
> b/cpukit/include/rtems/posix/timer.h
> index bcbf07a65a..7ae089173a 100644
> --- a/cpukit/include/rtems/posix/timer.h
> +++ b/cpukit/include/rtems/posix/timer.h
> @@ -48,6 +48,7 @@ typedef struct {
>uint32_t  ticks;  /* Number of ticks of the initialization */
>uint32_t  overrun;/* Number of expirations of the timer*/
>struct timespec   time;   /* Time at which the timer was started   */
> +  clockid_t clock_type; /* The type of timer */
>  } POSIX_Timer_Control;
>
>  /**
> diff --git a/cpukit/posix/src/psxtimercreate.c 
> b/cpukit/posix/src/psxtimercreate.c
> index a63cf1d100..2b5a10140f 100644
> --- a/cpukit/posix/src/psxtimercreate.c
> +++ b/cpukit/posix/src/psxtimercreate.c
> @@ -40,7 +40,7 @@ int timer_create(
>  {
>POSIX_Timer_Control *ptimer;
>
> -  if ( clock_id != CLOCK_REALTIME )
> +  if ( clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC )
>  rtems_set_errno_and_return_minus_one( EINVAL );
>
>if ( !timerid )
> @@ -91,6 +91,7 @@ int timer_create(
>ptimer->timer_data.it_value.tv_nsec= 0;
>ptimer->timer_data.it_interval.tv_sec  = 0;
>ptimer->timer_data.it_interval.tv_nsec = 0;
> +  ptimer->clock_type = clock_id;
>
>_Watchdog_Preinitialize( >Timer, _Per_CPU_Get_snapshot() );
>_Watchdog_Initialize( >Timer, _POSIX_Timer_TSR );
> diff --git a/cpukit/posix/src/timergettime.c b/cpukit/posix/src/timergettime.c
> index ee2a566f0e..2ad841d517 100644
> --- a/cpukit/posix/src/timergettime.c
> +++ b/cpukit/posix/src/timergettime.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  /*
>   *  - When a timer is initialized, the value of the time in
> @@ -39,35 +40,46 @@
>  int timer_gettime(
>timer_ttimerid,
>struct itimerspec *value
> )
>  {
>POSIX_Timer_Control *ptimer;
> -  ISR_lock_Context lock_context;
> -  uint64_t now;
> -  uint32_t remaining;
> +  ISR_lock_Context lock_context;
> +  Per_CPU_Control *cpu;
> +  struct timespec now;
> +  struct timespec expire;
> +  struct timespec result;
>
>if ( !value )
>  rtems_set_errno_and_return_minus_one( EINVAL );
>
>ptimer = _POSIX_Timer_Get( timerid, _context );
> -  if ( ptimer != NULL ) {
> -Per_CPU_Control *cpu;
> +  if ( ptimer == NULL ) {
> +rtems_set_errno_and_return_minus_one( EINVAL );
> +  }
>
> -cpu = _POSIX_Timer_Acquire_critical( ptimer, _context );
> -now = cpu->Watchdog.ticks;
> +  cpu = _POSIX_Timer_Acquire_critical( ptimer, _context );
> +  rtems_timespec_from_ticks( ptimer->Timer.expire,  );
>
> -if ( now < ptimer->Timer.expire ) {
> -  remaining = (uint32_t) ( ptimer->Timer.expire - now );
> -} else {
> -  remaining = 0;
> -}
> +  if ( ptimer->clock_type == CLOCK_MONOTONIC ) {
> +_Timecounter_Nanouptime(  );
> +  } else  if ( ptimer->clock_type == CLOCK_REALTIME ) {
> +_TOD_Get(  );
> +  } else {
> +_POSIX_Timer_Release( cpu, _context );
> +rtems_set_errno_and_return_minus_one( EINVAL );
> +  }
>
> -_Timespec_From_ticks( remaining, >it_value );
> -value->it_interval = ptimer->timer_data.it_interval;
>
> -_POSIX_Timer_Release( cpu, _context );
> -return 0;
> +  if ( rtems_timespec_less_than( ,  ) ) {
> +rtems_timespec_subtract( , ,  );
> +  } else {
> +result.tv_nsec = 0;
> +result.tv_sec = 0;
>}
> -
> -  rtems_set_errno_and_return_minus_one( EINVAL );
> +
> +  value->it_value = result;
> +  value->it_interval = ptimer->timer_data.it_interval;
> +
> +  _POSIX_Timer_Release( cpu, _context );
> +  return 0;
>  }
> diff --git a/testsuites/psxtests/psxtimer02/psxtimer.c 
> b/testsuites/psxtests/psxtimer02/psxtimer.c
> index 9f79d33c42..1a79369efb 100644
> --- a/testsuites/psxtests/psxtimer02/psxtimer.c
> +++ b/testsuites/psxtests/psxtimer02/psxtimer.c
> @@ -126,6 +126,32 @@ void *POSIX_Init (
>puts( "timer_delete - bad id - EINVAL" );
>status = timer_delete( timer );
>fatal_posix_service_status_errno( status, EINVAL, "bad id" );
> +
> +  puts( "timer_create (monotonic) - bad timer id pointer - EINVAL" );
> +  status = timer_create( CLOCK_MONOTONIC, , NULL );
> +  fatal_posix_service_status_errno( status, EINVAL, "bad timer id" );
> +
> +  puts( "timer_create (monotonic) - OK" );
> +  status = timer_create( CLOCK_MONOTONIC, NULL,  );
> +  posix_service_failed( status, "timer_create OK" );
> +
> +  puts( "timer_create (monotonic) - too many - EAGAIN" 

Re: [PATCH v5] closes #3889 new defect Test needed for timer_create with CLOCK_MONOTONIC

2021-08-09 Thread Gedare Bloom
Your commit message was a little better before, just needed some
reformatting. This commit message you are using is not good, as
mentioned previously.

On Mon, Aug 9, 2021 at 12:44 PM Zacchaeus Leung
 wrote:
>
> Closes #3888
> ---
>  cpukit/include/rtems/posix/timer.h|  1 +
>  cpukit/posix/src/psxtimercreate.c |  3 +-
>  cpukit/posix/src/timergettime.c   | 50 ---
>  testsuites/psxtests/psxtimer02/psxtimer.c | 26 ++
>  testsuites/psxtests/psxtimer02/psxtimer02.scn |  6 +++
>  5 files changed, 66 insertions(+), 20 deletions(-)
>
> diff --git a/cpukit/include/rtems/posix/timer.h 
> b/cpukit/include/rtems/posix/timer.h
> index bcbf07a65a..7ae089173a 100644
> --- a/cpukit/include/rtems/posix/timer.h
> +++ b/cpukit/include/rtems/posix/timer.h
> @@ -48,6 +48,7 @@ typedef struct {
>uint32_t  ticks;  /* Number of ticks of the initialization */
>uint32_t  overrun;/* Number of expirations of the timer*/
>struct timespec   time;   /* Time at which the timer was started   */
> +  clockid_t clock_type; /* The type of timer */
>  } POSIX_Timer_Control;
>
>  /**
> diff --git a/cpukit/posix/src/psxtimercreate.c 
> b/cpukit/posix/src/psxtimercreate.c
> index a63cf1d100..2b5a10140f 100644
> --- a/cpukit/posix/src/psxtimercreate.c
> +++ b/cpukit/posix/src/psxtimercreate.c
> @@ -40,7 +40,7 @@ int timer_create(
>  {
>POSIX_Timer_Control *ptimer;
>
> -  if ( clock_id != CLOCK_REALTIME )
> +  if (  clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC )
Too many spaces after the ( I think?

>  rtems_set_errno_and_return_minus_one( EINVAL );
>
>if ( !timerid )
> @@ -91,6 +91,7 @@ int timer_create(
>ptimer->timer_data.it_value.tv_nsec= 0;
>ptimer->timer_data.it_interval.tv_sec  = 0;
>ptimer->timer_data.it_interval.tv_nsec = 0;
> +  ptimer->clock_type = clock_id;
>
>_Watchdog_Preinitialize( >Timer, _Per_CPU_Get_snapshot() );
>_Watchdog_Initialize( >Timer, _POSIX_Timer_TSR );
> diff --git a/cpukit/posix/src/timergettime.c b/cpukit/posix/src/timergettime.c
> index ee2a566f0e..2ad841d517 100644
> --- a/cpukit/posix/src/timergettime.c
> +++ b/cpukit/posix/src/timergettime.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  /*
>   *  - When a timer is initialized, the value of the time in
> @@ -39,35 +40,46 @@
>  int timer_gettime(
>timer_ttimerid,
>struct itimerspec *value
> -)
> +)
what's changing here?

>  {
>POSIX_Timer_Control *ptimer;
> -  ISR_lock_Context lock_context;
> -  uint64_t now;
> -  uint32_t remaining;
> +  ISR_lock_Context lock_context;
> +  Per_CPU_Control *cpu;
> +  struct timespec now;
> +  struct timespec expire;
> +  struct timespec result;
>
>if ( !value )
>  rtems_set_errno_and_return_minus_one( EINVAL );
>
>ptimer = _POSIX_Timer_Get( timerid, _context );
> -  if ( ptimer != NULL ) {
> -Per_CPU_Control *cpu;
> +  if ( ptimer == NULL ) {
> +rtems_set_errno_and_return_minus_one( EINVAL );
> +  }
>
> -cpu = _POSIX_Timer_Acquire_critical( ptimer, _context );
> -now = cpu->Watchdog.ticks;
> +  cpu = _POSIX_Timer_Acquire_critical( ptimer, _context );
> +  rtems_timespec_from_ticks( ptimer->Timer.expire,  );
>
> -if ( now < ptimer->Timer.expire ) {
> -  remaining = (uint32_t) ( ptimer->Timer.expire - now );
> -} else {
> -  remaining = 0;
> -}
> +  if ( ptimer->clock_type == CLOCK_MONOTONIC ) {
> +  _Timecounter_Nanouptime();
still need to fix the indent level here
> +  } else  if ( ptimer->clock_type == CLOCK_REALTIME ) {
> +_TOD_Get();
> +  } else {
> +_POSIX_Timer_Release( cpu, _context );
> +rtems_set_errno_and_return_minus_one( EINVAL );
> +  }
>
> -_Timespec_From_ticks( remaining, >it_value );
> -value->it_interval = ptimer->timer_data.it_interval;
>
> -_POSIX_Timer_Release( cpu, _context );
> -return 0;
> + if ( rtems_timespec_less_than( ,  ) ) {
> +  rtems_timespec_subtract( , ,  );
> +  } else {
> +  result.tv_nsec = 0;
> +  result.tv_sec  = 0;
>}
The indents here are still wrong. should be two spaces before if, and
four within the indented blocks. Also looks like there are two blank
spaces after result.tv_sec, it should only be 1

> -
> -  rtems_set_errno_and_return_minus_one( EINVAL );
> +
> +  value->it_value = result;
> +  value->it_interval = ptimer->timer_data.it_interval;
> +
> +  _POSIX_Timer_Release( cpu, _context );
> +  return 0;
>  }
> diff --git a/testsuites/psxtests/psxtimer02/psxtimer.c 
> b/testsuites/psxtests/psxtimer02/psxtimer.c
> index 9f79d33c42..1a79369efb 100644
> --- a/testsuites/psxtests/psxtimer02/psxtimer.c
> +++ b/testsuites/psxtests/psxtimer02/psxtimer.c
> @@ -126,6 +126,32 @@ void *POSIX_Init (
>puts( "timer_delete - bad id - EINVAL" );
>status = timer_delete( timer );
>fatal_posix_service_status_errno( status, EINVAL, "bad id" );
> +
> +  

Re: [PATCH rtems-libbsd v4] NFSv4 Patches

2021-08-09 Thread Gedare Bloom
Things look mostly fine to me. But the last patch:
kern/sys: Add NFSv4 client
* in the buildset configuration, should we use nfsv4 to be explicit?
Or you think 'nfs' is fine?

* freebsd/sys/fs/nfs/nfs_commonkrpc.c: there are random whitespace
changes without guards, and ws changes inside of #ifndef __rtems__.
These might be artifacts of including the .clang-format? Or your
editor got aggressive.

* freebsd/sys/fs/nfsclient/nfs_clvnops.c: ditto

* rtemsbsd/fs/nfsclient/nfs.c: tabs used for indents is inconsistent
with other rtemsbsd sources. Also, you can use the following instead
of memset() with 0:
  int some_array[10] = {0};

On Wed, Aug 4, 2021 at 2:53 AM  wrote:
>
> Hi,
>
> This the first group of patches for the NFSv4 port. This is the only
> part of the patches posted to devel, the complete series of patches
> can be downloaded from:
>
> https://ftp.rtems.org/pub/rtems/people/chrisj/nfsv4/patches/4/
>
> I have pushed the patch series to my personal repo:
>
> https://git.rtems.org/chrisj/rtems-libbsd.git/?h=4475-p4-4475-nfs
>
> The changes here:
>
> 1. Kernel symbols use a FreeBSD format (tab)
>
> 2. Fixed the lock to be as small as possible
>
> 3. Thread name is reference
>
> 4. Added code is now in the FreeBSD format
>
> 5. Other minor changes as highligthed in the first review
>
> Chris
>
> ___
> 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 v4] Test needed for timer_create with CLOCK_MONOTONIC

2021-08-09 Thread Gedare Bloom
Hi Zack,

Getting really close. I have just a few minor nits for you to fix up.

On Sun, Aug 8, 2021 at 7:15 PM Zacchaeus Leung  wrote:
>
> the timer_create() method can use CLOCK_MONOTONIC but there was  no test for 
> this. Also it implements the functionality to
Wrap commit message lines before 76 characters. It then looks cleaner
in git-log (which indents a tab).

> create a CLOCK_MONOTONIC timer and gettime() .

I'd like to see a blank line between the commit message and the Closes line.

> Closes #3888
I still don't know why you're closing this ticket?
https://devel.rtems.org/ticket/3888

> ---
>  cpukit/include/rtems/posix/timer.h|  1 +
>  cpukit/posix/src/psxtimercreate.c |  3 +-
>  cpukit/posix/src/timergettime.c   | 50 ---
>  testsuites/psxtests/psxtimer02/psxtimer.c | 26 ++
>  testsuites/psxtests/psxtimer02/psxtimer02.scn |  6 +++
>  5 files changed, 66 insertions(+), 20 deletions(-)
>
> diff --git a/cpukit/include/rtems/posix/timer.h 
> b/cpukit/include/rtems/posix/timer.h
> index bcbf07a65a..7ae089173a 100644
> --- a/cpukit/include/rtems/posix/timer.h
> +++ b/cpukit/include/rtems/posix/timer.h
> @@ -48,6 +48,7 @@ typedef struct {
>uint32_t  ticks;  /* Number of ticks of the initialization */
>uint32_t  overrun;/* Number of expirations of the timer*/
>struct timespec   time;   /* Time at which the timer was started   */
> +  clockid_t clock_type; /* The type of timer */
>  } POSIX_Timer_Control;
>
>  /**
> diff --git a/cpukit/posix/src/psxtimercreate.c 
> b/cpukit/posix/src/psxtimercreate.c
> index a63cf1d100..2b5a10140f 100644
> --- a/cpukit/posix/src/psxtimercreate.c
> +++ b/cpukit/posix/src/psxtimercreate.c
> @@ -40,7 +40,7 @@ int timer_create(
>  {
>POSIX_Timer_Control *ptimer;
>
> -  if ( clock_id != CLOCK_REALTIME )
> +  if (  clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC )
>  rtems_set_errno_and_return_minus_one( EINVAL );
>
>if ( !timerid )
> @@ -91,6 +91,7 @@ int timer_create(
>ptimer->timer_data.it_value.tv_nsec= 0;
>ptimer->timer_data.it_interval.tv_sec  = 0;
>ptimer->timer_data.it_interval.tv_nsec = 0;
> +  ptimer->clock_type = clock_id;
>
>_Watchdog_Preinitialize( >Timer, _Per_CPU_Get_snapshot() );
>_Watchdog_Initialize( >Timer, _POSIX_Timer_TSR );
> diff --git a/cpukit/posix/src/timergettime.c b/cpukit/posix/src/timergettime.c
> index ee2a566f0e..2ad841d517 100644
> --- a/cpukit/posix/src/timergettime.c
> +++ b/cpukit/posix/src/timergettime.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  /*
>   *  - When a timer is initialized, the value of the time in
> @@ -39,35 +40,46 @@
>  int timer_gettime(
>timer_ttimerid,
>struct itimerspec *value
> )
>  {
>POSIX_Timer_Control *ptimer;
> -  ISR_lock_Context lock_context;
> -  uint64_t now;
> -  uint32_t remaining;
> +  ISR_lock_Context lock_context;
> +  Per_CPU_Control *cpu;
> +  struct timespec now;
> +  struct timespec expire;
> +  struct timespec result;
>
>if ( !value )
>  rtems_set_errno_and_return_minus_one( EINVAL );
>
>ptimer = _POSIX_Timer_Get( timerid, _context );
> -  if ( ptimer != NULL ) {
> -Per_CPU_Control *cpu;
> +  if ( ptimer == NULL ) {
> +rtems_set_errno_and_return_minus_one( EINVAL );
> +  }
>
> -cpu = _POSIX_Timer_Acquire_critical( ptimer, _context );
> -now = cpu->Watchdog.ticks;
> +  cpu = _POSIX_Timer_Acquire_critical( ptimer, _context );
> +  rtems_timespec_from_ticks( ptimer->Timer.expire,  );
>
> -if ( now < ptimer->Timer.expire ) {
> -  remaining = (uint32_t) ( ptimer->Timer.expire - now );
> -} else {
> -  remaining = 0;
> -}
> +  if ( ptimer->clock_type == CLOCK_MONOTONIC ) {
> +  _Timecounter_Nanouptime();
indent

> +  } else  if ( ptimer->clock_type == CLOCK_REALTIME ) {
> +_TOD_Get();
indent

> +  } else {
> +  _POSIX_Timer_Release( cpu, _context );
> +  rtems_set_errno_and_return_minus_one( EINVAL );
indent

> +  }
>
> -_Timespec_From_ticks( remaining, >it_value );
> -value->it_interval = ptimer->timer_data.it_interval;
>
> -_POSIX_Timer_Release( cpu, _context );
> -return 0;
> + if ( rtems_timespec_less_than( ,  ) ) {
indent off-by-1

> +  rtems_timespec_subtract( , ,  );
too much indent

> +  } else {
> +  result.tv_nsec = 0;
> +  result.tv_sec  = 0;
too much indent

>}
> -
> -  rtems_set_errno_and_return_minus_one( EINVAL );
> +
> +  value->it_value = result;
> +  value->it_interval = ptimer->timer_data.it_interval;
> +
> +  _POSIX_Timer_Release( cpu, _context );
> +  return 0;
>  }
> diff --git a/testsuites/psxtests/psxtimer02/psxtimer.c 
> b/testsuites/psxtests/psxtimer02/psxtimer.c
> index 9f79d33c42..1a79369efb 100644
> --- a/testsuites/psxtests/psxtimer02/psxtimer.c
> +++ b/testsuites/psxtests/psxtimer02/psxtimer.c
> @@ -126,6 +126,32 @@ void *POSIX_Init (
>

Re: [PATCH] user: Update rsb-packages to reflect RTEMS 6 changes

2021-08-09 Thread Gedare Bloom
On Mon, Aug 9, 2021 at 9:18 AM Joel Sherrill  wrote:
>
> On Mon, Aug 9, 2021 at 10:07 AM Gedare Bloom  wrote:
> >
> > I have to think about this. The approach taken here just replaces 5.1
> > -> 6, it isn't updating the screengrabs. This means the tutorial isn't
> > "real" but that might be fine.
>
> He can replace the screenshots but that is not worth the trouble at
> this point IMO.
>
> > The other issue is that when we release, then this has to become 6 ->
> > 6.1 in the release, and 6 -> 7 in the master. How we manage this
> > becomes part of the release overhead.
>
> As Andrei pointed out, these sections trick you into thinking that
> you can ftp "releases" from the master. But they aren't right for the
> master if they say 5 or 6. I'm prone to have these type of sections
> have prominent warnings that they only apply to releases and not
> to fetching from git. At least that keeps the sections and flags them.
>
I'm ok with that.

> But it doesn't do anything about the burden of the release cycle.
>
Either we end up with instructions from an older release in a new one,
or we need a way to (automate) update for a release.

> --joel
>
> > On Fri, Aug 6, 2021 at 3:27 PM Ray Garza  wrote:
> > >
> > > This updates all references and examples in the rtems docs: 
> > > user/start/rsb-packages.rst to RTEMS 6
> > >
> > > ---
> > >  user/start/rsb-packages.rst | 68 ++---
> > >  1 file changed, 34 insertions(+), 34 deletions(-)
> > >
> > > diff --git a/user/start/rsb-packages.rst b/user/start/rsb-packages.rst
> > > index 3119318..891ea6a 100644
> > > --- a/user/start/rsb-packages.rst
> > > +++ b/user/start/rsb-packages.rst
> > > @@ -19,8 +19,8 @@ Return to here once you have completed these steps.
> > >
> > >  You have chosen an installation prefix, the BSP to build, the tool's
> > >  architecure and prepared the source for the RSB in the previous 
> > > sections.  We
> > > -have chosen :file:`$HOME/quick-start/rtems/5` as the installation 
> > > prefix, the
> > > -``erc32`` BSP and the SPARC architecture name of ``sparc-rtems5``, and 
> > > unpacked
> > > +have chosen :file:`$HOME/quick-start/rtems/6` as the installation 
> > > prefix, the
> > > +``erc32`` BSP and the SPARC architecture name of ``sparc-rtems6``, and 
> > > unpacked
> > >  the RSB source in :file:`$HOME/quick-start/src`.
> > >
> > >  You are now able to build :ref:`BSP Packages` or 3rd party libraries of 
> > > code if you
> > > @@ -72,36 +72,36 @@ BSP.
> > >  .. code-block:: none
> > >
> > >  cd $HOME/quick-start/src/rsb/rtems
> > > -../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5 \
> > > +../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 \
> > >  --with-rtems-tests=yes bsps/erc32
> > >
> > >  This command should output something like this:
> > >
> > >  .. code-block:: none
> > >
> > > -RTEMS Source Builder - Set Builder, 5.1.0
> > > +RTEMS Source Builder - Set Builder, 6 (4e6dc6431435)
> > >  Build Set: bsps/erc32
> > > -Build Set: 5/rtems-sparc.bset
> > > -Build Set: 5/rtems-autotools.bset
> > > -Build Set: 5/rtems-autotools-internal.bset
> > > +Build Set: 6/rtems-sparc.bset
> > > +Build Set: 6/rtems-autotools.bset
> > > +Build Set: 6/rtems-autotools-internal.bset
> > >  config: tools/rtems-autoconf-2.69-1.cfg
> > >  package: autoconf-2.69-x86_64-freebsd12.1-1
> > >  building: autoconf-2.69-x86_64-freebsd12.1-1
> > >  sizes: autoconf-2.69-x86_64-freebsd12.1-1: 7.505MB (installed: 
> > > 0.000B)
> > >  ...
> > > -building: protobuf-2.6.1-sparc-rtems5-1
> > > -sizes: protobuf-2.6.1-sparc-rtems5-1: 228.079MB (installed: 84.408MB)
> > > -cleaning: protobuf-2.6.1-sparc-rtems5-1
> > > -reporting: net/protobuf-2.6.1-1.cfg -> 
> > > protobuf-2.6.1-sparc-rtems5-1.txt
> > > -reporting: net/protobuf-2.6.1-1.cfg -> 
> > > protobuf-2.6.1-sparc-rtems5-1.xml
> > > -staging: protobuf-2.6.1-sparc-rtems5-1 -> 
> > > $HOME/quick-start/src/rsb/rtems/build/tmp/sb-500-staging
> > > -cleaning: protobuf-2.6.1-sparc-rtems5-1
> > > -Build Set: Time 0:00:23.564992
> > > -Build Set: Time 0:02:27.380299
> > > +building: protobuf-2.6.1-sparc

Re: [PATCH rtems-libbsd v3 2/3] rtemsbsd: Add interface support routines

2021-08-09 Thread Gedare Bloom
On Sun, Aug 8, 2021 at 7:22 PM Chris Johns  wrote:
>
> - Add the ability to check if an interface is up
> ---
>  libbsd.py  |   1 +
>  rtemsbsd/include/rtems/bsd/iface.h |  62 
>  rtemsbsd/rtems/rtems-bsd-iface.c   | 146 +
>  3 files changed, 209 insertions(+)
>  create mode 100644 rtemsbsd/include/rtems/bsd/iface.h
>  create mode 100644 rtemsbsd/rtems/rtems-bsd-iface.c
>
> diff --git a/libbsd.py b/libbsd.py
> index 09a1fbc4..6e09a07c 100644
> --- a/libbsd.py
> +++ b/libbsd.py
> @@ -253,6 +253,7 @@ class rtems(builder.Module):
>  'rtems/rtems-bsd-cxx.cc',
>  'rtems/rtems-bsd-get-ethernet-addr.c',
>  'rtems/rtems-bsd-ifconfig.c',
> +'rtems/rtems-bsd-iface.c',
>  'rtems/rtems-bsd-ifconfig-lo0.c',
>  'rtems/rtems-bsd-init-dhcp.c',
>  'rtems/rtems-bsd-rc-conf-net.c',
> diff --git a/rtemsbsd/include/rtems/bsd/iface.h 
> b/rtemsbsd/include/rtems/bsd/iface.h
> new file mode 100644
> index ..9e583b8a
> --- /dev/null
> +++ b/rtemsbsd/include/rtems/bsd/iface.h
> @@ -0,0 +1,62 @@
> +/**
> + * @file
> + *
> + * @ingroup rtems_bsd_rtems
> + *
> + * @brief This file provide a high level interface to simple interface
> + * support calls.
> + */
> +
> +/*
> + * Copyright (c) 2021. Chris Johns . 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 _RTEMS_BSD_IFACE_H_
> +#define _RTEMS_BSD_IFACE_H_
> +
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +struct rtems_bsd_iface {
> +   char name[IFNAMSIZ];
> +   int unit;
> +   struct in_addr address;
> +   size_t hw_len;
> +   uint8_t hw_address[16];
> +   struct ifreq ifr;
> +   int linkstate;
> +};
> +
> +/*
> + * These calls return 0 is successful and -1 and errno set on error.
> + */
> +int rtems_bsd_iface_get(const char *name, struct rtems_bsd_iface *iface);
> +int rtems_bsd_iface_link_state(const char *name, bool *state);
> +
> +#endif
> diff --git a/rtemsbsd/rtems/rtems-bsd-iface.c 
> b/rtemsbsd/rtems/rtems-bsd-iface.c
> new file mode 100644
> index ..4cf25a9b
> --- /dev/null
> +++ b/rtemsbsd/rtems/rtems-bsd-iface.c
> @@ -0,0 +1,146 @@
> +/**
> + * @file
> + *
> + * @ingroup rtems_bsd_rtems
> + *
> + * @brief Interface support routines
> + */
> +
> +/*
> + * Copyright (c) 2021. Chris Johns   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 

Re: [PATCH rtems-libbsd v3 1/3] rtemsbsd/bus: Add PCI support to the nexus bus

2021-08-09 Thread Gedare Bloom
On Sun, Aug 8, 2021 at 7:22 PM Chris Johns  wrote:
>
> - Add PCI IO region support
>
> - Add support map buffers to PCI address space
>
> - Add BSP conditional IO space support. Some PC implementations
>   have PCI IO space mapped differently to memory space and this needs
>   to be reflected in the busspace.
>
> - Include bsp.h to pick per BSP configuration.
>
> Closes #4245
> ---
>  rtemsbsd/include/machine/bus.h| 370 ++
>  rtemsbsd/rtems/rtems-kernel-bus-dma.c |   5 +-
>  rtemsbsd/rtems/rtems-kernel-nexus.c   |  52 +++-
>  3 files changed, 312 insertions(+), 115 deletions(-)
>
> diff --git a/rtemsbsd/include/machine/bus.h b/rtemsbsd/include/machine/bus.h
> index 2f0e7ad6..999f5d45 100644
> --- a/rtemsbsd/include/machine/bus.h
> +++ b/rtemsbsd/include/machine/bus.h
> @@ -6,9 +6,13 @@
>   * @brief TODO.
>   *
>   * File origin from FreeBSD 'sys/amd64/include/bus.h'.
> + *
> + * Conditionally supports PCI IO regions (IO Ports).
>   */
>
>  /*-
> + * Copyright (c) 2021 Chris Johns.  All rights reserved.
> + *
>   * Copyright (c) 2009, 2015 embedded brains GmbH.  All rights reserved.
>   *
>   *  embedded brains GmbH
> @@ -25,7 +29,7 @@
>   * 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 as
>   *the first lines of this file unmodified.
> @@ -34,7 +38,7 @@
>   *documentation and/or other materials provided with the distribution.
>   * 3. The name of the author may not be used to endorse or promote products
>   *derived from this software without specific prior written permission.
> - *
> + *
>   * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``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.
> @@ -123,9 +127,46 @@
>  #endif
>
>  #ifdef __i386__
> -  #error "your include paths are wrong"
> +  #error "x86 has its own bus.h; check your include paths are correct"
>  #endif
>
> +#include 
> +
> +/*
> + * BSP PCI Support
> + *
> + * The RTEMS Nexus bus support can optionaly support PC PCI spaces that
optionally

> + * mapped to BSP speciic address spaces. Add the following define to
specific

> + * the BSP header file to enable this support:
> + *
> + *  #define BSP_HAS_PC_PCI

Is there an rtems.git patch to add this to some BSP?

I might suggest BSP_HAS_PCI_IO_PORTS

> + *
> + * If enabled a BSP must the following IO region calls:
must support?

> + *
> + * inb  : read 8 bits
> + * outb : write 8 bits
> + * inw  : read 16 bits
> + * outw : write 16 bits
> + * inl  : read 32 bits
> + * outl : write 32 bits
> + *
> + * The BSP needs to provide the DRAM address space offset
> + * PCI_DRAM_OFFSET. This is the base address of the DRAM as seen by a
> + * PCI master.
> + *
> + * i386 BSPs have a special bus.h file and do not use this file.
> + */
> +
> +#ifdef BSP_HAS_PC_PCI
> +
> +/*
> + * Values for the bus space tag, not to be used directly by MI code.
> + */
> +#defineBSP_BUS_SPACE_IO0   /* space is i/o space */
> +#defineBSP_BUS_SPACE_MEM   1   /* space is mem space */
> +
> +#endif /* BSP_HAS_PC_PCI */
> +
>  /*
>   * Bus address alignment.
>   */
> @@ -144,6 +185,7 @@
>  /*
>   * Bus access.
>   */
> +#define BUS_SPACE_INVALID_DATA (~0)
Please use 0U here. I get the undefined behavior (UB) willies when I
see bit-twiddling on signed integer types.

>  #define BUS_SPACE_UNRESTRICTED (~0U)
>
>  /*
> @@ -222,6 +264,102 @@ bus_space_barrier(bus_space_tag_t bst __unused, 
> bus_space_handle_t bsh, bus_size
> /* Do nothing */
>  }
>
> +/*
> + * BSP Bus Space Map Support
> + *
> + * Provide as C macros in the BSP header (bsp.h) the following:

Not really clear to me under what conditions these should be provided.
This could be wrapped by #ifndef BSP_HAS_PC_PCI?

> + *
> + *  RTEMS_BSP_READ_1
> + *  RTEMS_BSP_READ_2
> + *  RTEMS_BSP_READ_4
> + *  RTEMS_BSP_READ_8
> + *  RTEMS_BSP_WRITE_1
> + *  RTEMS_BSP_WRITE_2
> + *  RTEMS_BSP_WRITE_4
> + *  RTEMS_BSP_WRITE_8
> + */
> +
> +static __inline uint8_t
> +bsp_bus_space_read_1(const uint8_t __volatile *bsp)
> +{
> +#if defined(RTEMS_BSP_READ_1)
> +   return RTEMS_BSP_READ_1(bsp);
> +#else
> +   return (*bsp);
> +#endif
> +}
> +
> +static __inline uint16_t
> +bsp_bus_space_read_2(const uint16_t __volatile *bsp)
> +{
> +#if defined(RTEMS_BSP_READ_2)
> +   return RTEMS_BSP_READ_2(bsp);
> +#else
> +   return (*bsp);
> +#endif
> +}
> +
> +static __inline uint32_t
> +bsp_bus_space_read_4(const uint32_t __volatile *bsp)
> +{
> +#if defined(RTEMS_BSP_READ_4)
> +   return RTEMS_BSP_READ_4(bsp);
> +#else
> +   return (*bsp);
> +#endif
> +}
> +
> +static __inline uint64_t
> 

Re: [PATCH] user: Update rsb-packages to reflect RTEMS 6 changes

2021-08-09 Thread Gedare Bloom
I have to think about this. The approach taken here just replaces 5.1
-> 6, it isn't updating the screengrabs. This means the tutorial isn't
"real" but that might be fine.

The other issue is that when we release, then this has to become 6 ->
6.1 in the release, and 6 -> 7 in the master. How we manage this
becomes part of the release overhead.

On Fri, Aug 6, 2021 at 3:27 PM Ray Garza  wrote:
>
> This updates all references and examples in the rtems docs: 
> user/start/rsb-packages.rst to RTEMS 6
>
> ---
>  user/start/rsb-packages.rst | 68 ++---
>  1 file changed, 34 insertions(+), 34 deletions(-)
>
> diff --git a/user/start/rsb-packages.rst b/user/start/rsb-packages.rst
> index 3119318..891ea6a 100644
> --- a/user/start/rsb-packages.rst
> +++ b/user/start/rsb-packages.rst
> @@ -19,8 +19,8 @@ Return to here once you have completed these steps.
>
>  You have chosen an installation prefix, the BSP to build, the tool's
>  architecure and prepared the source for the RSB in the previous sections.  We
> -have chosen :file:`$HOME/quick-start/rtems/5` as the installation prefix, the
> -``erc32`` BSP and the SPARC architecture name of ``sparc-rtems5``, and 
> unpacked
> +have chosen :file:`$HOME/quick-start/rtems/6` as the installation prefix, the
> +``erc32`` BSP and the SPARC architecture name of ``sparc-rtems6``, and 
> unpacked
>  the RSB source in :file:`$HOME/quick-start/src`.
>
>  You are now able to build :ref:`BSP Packages` or 3rd party libraries of code 
> if you
> @@ -72,36 +72,36 @@ BSP.
>  .. code-block:: none
>
>  cd $HOME/quick-start/src/rsb/rtems
> -../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5 \
> +../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/6 \
>  --with-rtems-tests=yes bsps/erc32
>
>  This command should output something like this:
>
>  .. code-block:: none
>
> -RTEMS Source Builder - Set Builder, 5.1.0
> +RTEMS Source Builder - Set Builder, 6 (4e6dc6431435)
>  Build Set: bsps/erc32
> -Build Set: 5/rtems-sparc.bset
> -Build Set: 5/rtems-autotools.bset
> -Build Set: 5/rtems-autotools-internal.bset
> +Build Set: 6/rtems-sparc.bset
> +Build Set: 6/rtems-autotools.bset
> +Build Set: 6/rtems-autotools-internal.bset
>  config: tools/rtems-autoconf-2.69-1.cfg
>  package: autoconf-2.69-x86_64-freebsd12.1-1
>  building: autoconf-2.69-x86_64-freebsd12.1-1
>  sizes: autoconf-2.69-x86_64-freebsd12.1-1: 7.505MB (installed: 0.000B)
>  ...
> -building: protobuf-2.6.1-sparc-rtems5-1
> -sizes: protobuf-2.6.1-sparc-rtems5-1: 228.079MB (installed: 84.408MB)
> -cleaning: protobuf-2.6.1-sparc-rtems5-1
> -reporting: net/protobuf-2.6.1-1.cfg -> protobuf-2.6.1-sparc-rtems5-1.txt
> -reporting: net/protobuf-2.6.1-1.cfg -> protobuf-2.6.1-sparc-rtems5-1.xml
> -staging: protobuf-2.6.1-sparc-rtems5-1 -> 
> $HOME/quick-start/src/rsb/rtems/build/tmp/sb-500-staging
> -cleaning: protobuf-2.6.1-sparc-rtems5-1
> -Build Set: Time 0:00:23.564992
> -Build Set: Time 0:02:27.380299
> +building: protobuf-2.6.1-sparc-rtems6
> +sizes: protobuf-2.6.1-sparc-rtems6: 228.079MB (installed: 84.408MB)
> +cleaning: protobuf-2.6.1-sparc-rtems6
> +reporting: net/protobuf-2.6.1-1.cfg -> protobuf-2.6.1-sparc-rtems6.txt
> +reporting: net/protobuf-2.6.1-1.cfg -> protobuf-2.6.1-sparc-rtems6.xml
> +staging: protobuf-2.6.1-sparc-rtems6 -> 
> $HOME/quick-start/src/rsb/rtems/build/tmp/sb-500-staging
> +cleaning: protobuf-2.6.1-sparc-rtems6
> +Build Set: Time 0:00:27.784056
> +Build Set: Time 0:02:32.697406
>  installing: bsps/erc32 -> $HOME/quick-start/rtems/
>  clean staging: bsps/erc32
> -Staging Size: 1.372GB
> -Build Set: Time 0:24:17.83979
> +Staging Size: 1.401GB
> +Build Set: Time 0:25:08.37754
>
>  The RSB BSP build can be customised with following RSB command line options:
>
> @@ -147,10 +147,10 @@ be a list of build sets. To view the avaliable build 
> sets run this command:
>  RTEMS package naming is based on the naming FreeBSD uses in its ports
>  collection.
>
> -This Quick Start Guide will build the BSD Library or :file:`5/rtems-libbsd`.
> +This Quick Start Guide will build the BSD Library or :file:`6/rtems-libbsd`.
>
>  An RTEMS package is hosted on RTEMS so the tool suite name needs to be 
> supplied
> -using the ``--host`` option, e.g. ``--host=sparc-rtem5``. The BSP needs to be
> +using the ``--host`` option, e.g. ``--host=sparc-rtem6``. The BSP needs to be
>  provided using the ``--with-rtems-bsp`` option,
>  e.g. ``--with-rtems-bsp=erc32``. The commands to build ``libbsd`` for the
>  ``erc32`` BSP are:
> @@ -158,25 +158,25 @@ e.g. ``--with-rtems-bsp=erc32``. The commands to build 
> ``libbsd`` for the
>  .. code-block:: none
>
>  cd $HOME/quick-start/src/rsb/rtems
> -../source-builder/sb-set-builder --prefix=$HOME/quick-start/rtems/5 \
> -  --host=sparc-rtems5 --with-rtems-bsp=erc32 

Re: [PATCH v4] bsps: Move optfdt* files to shared parent directory

2021-08-09 Thread Gedare Bloom
Hi Joel,

On Fri, Jul 16, 2021 at 10:40 AM Joel Sherrill  wrote:
>
> I'm doing a build sweep of all BSPs. When that completes, I plan to
> push this unless there are comments.
>
Did/can you push this?

> On Fri, Jul 16, 2021 at 9:51 AM pranav  wrote:
> >
> > ---
> >  .../arm/altera-cyclone-v/bspalteracyclonev.yml  |  8 
> >  spec/build/bsps/arm/beagle/grp.yml  |  8 
> >  spec/build/bsps/arm/beagle/optfdtcpyro.yml  | 16 
> >  spec/build/bsps/arm/beagle/optfdtmxsz.yml   | 17 -
> >  spec/build/bsps/arm/beagle/optfdtro.yml | 16 
> >  spec/build/bsps/arm/beagle/optfdtuboot.yml  | 16 
> >  spec/build/bsps/arm/imx/bspimx.yml  |  8 
> >  spec/build/bsps/arm/imx/optfdtcpyro.yml | 16 
> >  spec/build/bsps/arm/imx/optfdtmxsz.yml  | 17 -
> >  spec/build/bsps/arm/imx/optfdtro.yml| 16 
> >  spec/build/bsps/arm/imx/optfdtuboot.yml | 16 
> >  spec/build/bsps/arm/raspberrypi/grp.yml |  8 
> >  .../{arm/altera-cyclone-v => }/optfdtcpyro.yml  |  0
> >  .../{arm/altera-cyclone-v => }/optfdtmxsz.yml   |  0
> >  .../{arm/altera-cyclone-v => }/optfdtro.yml |  0
> >  .../{arm/altera-cyclone-v => }/optfdtuboot.yml  |  0
> >  spec/build/bsps/powerpc/qoriq/grp.yml   |  4 ++--
> >  spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml| 17 -
> >  spec/build/bsps/powerpc/qoriq/optfdtro.yml  | 16 
> >  spec/build/bsps/riscv/riscv/grp.yml |  8 
> >  spec/build/bsps/riscv/riscv/optfdtcpyro.yml | 16 
> >  spec/build/bsps/riscv/riscv/optfdtmxsz.yml  | 17 -
> >  spec/build/bsps/riscv/riscv/optfdtro.yml| 16 
> >  spec/build/bsps/riscv/riscv/optfdtuboot.yml | 16 
> >  24 files changed, 26 insertions(+), 246 deletions(-)
> >  delete mode 100644 spec/build/bsps/arm/beagle/optfdtcpyro.yml
> >  delete mode 100644 spec/build/bsps/arm/beagle/optfdtmxsz.yml
> >  delete mode 100644 spec/build/bsps/arm/beagle/optfdtro.yml
> >  delete mode 100644 spec/build/bsps/arm/beagle/optfdtuboot.yml
> >  delete mode 100644 spec/build/bsps/arm/imx/optfdtcpyro.yml
> >  delete mode 100644 spec/build/bsps/arm/imx/optfdtmxsz.yml
> >  delete mode 100644 spec/build/bsps/arm/imx/optfdtro.yml
> >  delete mode 100644 spec/build/bsps/arm/imx/optfdtuboot.yml
> >  rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtcpyro.yml (100%)
> >  rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtmxsz.yml (100%)
> >  rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtro.yml (100%)
> >  rename spec/build/bsps/{arm/altera-cyclone-v => }/optfdtuboot.yml (100%)
> >  delete mode 100644 spec/build/bsps/powerpc/qoriq/optfdtmxsz.yml
> >  delete mode 100644 spec/build/bsps/powerpc/qoriq/optfdtro.yml
> >  delete mode 100644 spec/build/bsps/riscv/riscv/optfdtcpyro.yml
> >  delete mode 100644 spec/build/bsps/riscv/riscv/optfdtmxsz.yml
> >  delete mode 100644 spec/build/bsps/riscv/riscv/optfdtro.yml
> >  delete mode 100644 spec/build/bsps/riscv/riscv/optfdtuboot.yml
> >
> > diff --git a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml 
> > b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> > index da567ddd79..a9f3f7dabf 100644
> > --- a/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> > +++ b/spec/build/bsps/arm/altera-cyclone-v/bspalteracyclonev.yml
> > @@ -73,15 +73,15 @@ links:
> >  - role: build-dependency
> >uid: optconuart1
> >  - role: build-dependency
> > -  uid: optfdtcpyro
> > +  uid: ../../optfdtcpyro
> >  - role: build-dependency
> >uid: optfdten
> >  - role: build-dependency
> > -  uid: optfdtmxsz
> > +  uid: ../../optfdtmxsz
> >  - role: build-dependency
> > -  uid: optfdtro
> > +  uid: ../../optfdtro
> >  - role: build-dependency
> > -  uid: optfdtuboot
> > +  uid: ../../optfdtuboot
> >  - role: build-dependency
> >uid: opti2cspeed
> >  - role: build-dependency
> > diff --git a/spec/build/bsps/arm/beagle/grp.yml 
> > b/spec/build/bsps/arm/beagle/grp.yml
> > index 1375913fd0..3452c3e5c8 100644
> > --- a/spec/build/bsps/arm/beagle/grp.yml
> > +++ b/spec/build/bsps/arm/beagle/grp.yml
> > @@ -22,13 +22,13 @@ links:
> >  - role: build-dependency
> >uid: optdm3730
> >  - role: build-dependency
> > -  uid: optfdtcpyro
> > +  uid: ../../optfdtcpyro
> >  - role: build-dependency
> > -  uid: optfdtmxsz
> > +  uid: ../../optfdtmxsz
> >  - role: build-dependency
> > -  uid: optfdtro
> > +  uid: ../../optfdtro
> >  - role: build-dependency
> > -  uid: optfdtuboot
> > +  uid: ../../optfdtuboot
> >  - role: build-dependency
> >uid: ../grp
> >  - role: build-dependency
> > diff --git a/spec/build/bsps/arm/beagle/optfdtcpyro.yml 
> > b/spec/build/bsps/arm/beagle/optfdtcpyro.yml
> > deleted file mode 100644
> > index 5ec59adf4d..00
> > --- 

Re: [PATCH v3] Test needed for timer_create with CLOCK_MONOTONIC

2021-08-07 Thread Gedare Bloom
On Fri, Aug 6, 2021 at 11:55 AM zack leung  wrote:
>
> How do i report the findings of the  psx and  tests?
>

You can just copy-paste the final part of the log file when you run
rtems-test. Or you can share the full log file as attachment

>
> Thanks
> Zack
>
> On Thu, 5 Aug 2021 at 19:23, Gedare Bloom  wrote:
>>
>> On Thu, Aug 5, 2021 at 12:36 PM Zacchaeus Leung
>>  wrote:
>> >
>> > the timer_create() method can use CLOCK_MONOTONIC but there was  no test 
>> > for this
>> >
>> The commit message needs to be improved, because this patch is doing
>> more than adding a "test", it is implementing the functionality to
>> create a CLOCK_MONOTONIC timer and to gettime() on it.
>>
>> > Closes #3888
>> https://devel.rtems.org/ticket/3888  ??
>>
>> >
>> > ---
>>
>> [...]
>>
>> > +
>> > + if ( rtems_timespec_less_than( ,  ) ) {
>> > +  rtems_timespec_subtract( , ,  );
>> > +} else {
>> > +  result.tv_nsec = 0;
>> > +  result.tv_sec  = 0;
>> > +}
>> The indentation level is wrong in this block.
>>
>> > +
>> > +  value->it_value = result;
>> > +  value->it_interval = ptimer->timer_data.it_interval;
>> > +
>> > +  _POSIX_Timer_Release( cpu, _context );
>> > +  return 0;
>> > +}
>> > \ No newline at end of file
>> > diff --git a/testsuites/psxtests/psxtimer02/psxtimer.c 
>> > b/testsuites/psxtests/psxtimer02/psxtimer.c
>> > index 9f79d33c42..1a79369efb 100644
>> > --- a/testsuites/psxtests/psxtimer02/psxtimer.c
>> > +++ b/testsuites/psxtests/psxtimer02/psxtimer.c
>> > @@ -126,6 +126,32 @@ void *POSIX_Init (
>> >puts( "timer_delete - bad id - EINVAL" );
>> >status = timer_delete( timer );
>> >fatal_posix_service_status_errno( status, EINVAL, "bad id" );
>> > +
>> > +  puts( "timer_create (monotonic) - bad timer id pointer - EINVAL" );
>> > +  status = timer_create( CLOCK_MONOTONIC, , NULL );
>> > +  fatal_posix_service_status_errno( status, EINVAL, "bad timer id" );
>> > +
>> > +  puts( "timer_create (monotonic) - OK" );
>> > +  status = timer_create( CLOCK_MONOTONIC, NULL,  );
>> > +  posix_service_failed( status, "timer_create OK" );
>> > +
>> > +  puts( "timer_create (monotonic) - too many - EAGAIN" );
>> > +  status = timer_create( CLOCK_MONOTONIC, NULL,  );
>> > +  fatal_posix_service_status_errno( status, EAGAIN, "too many" );
>> > +
>> > +  clock_gettime( CLOCK_MONOTONIC,  );
>> > +  itimer.it_value = now;
>> > +  itimer.it_value.tv_sec = itimer.it_value.tv_sec - 1;
>> > +  puts( "timer_settime (monotonic) - bad itimer value - previous time - 
>> > EINVAL" );
>> > +  status = timer_settime( timer, TIMER_ABSTIME, , NULL );
>> > +  fatal_posix_service_status_errno( status, EINVAL, "bad itimer value #3" 
>> > );
>> > +
>> > +  clock_gettime( CLOCK_MONOTONIC,  );
>> > +  itimer.it_value = now;
>> > +  itimer.it_value.tv_sec = itimer.it_value.tv_sec + 1;
>> > +  puts( "timer_settime (monotonic) - bad id - EINVAL" );
>> > +  status = timer_settime( timer1, TIMER_ABSTIME, , NULL );
>> > +  fatal_posix_service_status_errno( status, EINVAL, "bad id" );
>> >
>>
>> Please provide updated psxtimer02.scn and report the results for
>> running rtems-test for at least the sparc/erc32 with sis including the
>> sptests and psxtests. If you need help how to run rtems-test, consult
>> the documentation and ask questions.
>> https://docs.rtems.org/branches/master/user/testing/index.html
>>
>> >TEST_END();
>> >rtems_test_exit (0);
>> > --
>> > 2.32.0
>> >
>> > ___
>> > 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 v3] Test needed for timer_create with CLOCK_MONOTONIC

2021-08-05 Thread Gedare Bloom
On Thu, Aug 5, 2021 at 12:36 PM Zacchaeus Leung
 wrote:
>
> the timer_create() method can use CLOCK_MONOTONIC but there was  no test for 
> this
>
The commit message needs to be improved, because this patch is doing
more than adding a "test", it is implementing the functionality to
create a CLOCK_MONOTONIC timer and to gettime() on it.

> Closes #3888
https://devel.rtems.org/ticket/3888  ??

>
> ---

[...]

> +
> + if ( rtems_timespec_less_than( ,  ) ) {
> +  rtems_timespec_subtract( , ,  );
> +} else {
> +  result.tv_nsec = 0;
> +  result.tv_sec  = 0;
> +}
The indentation level is wrong in this block.

> +
> +  value->it_value = result;
> +  value->it_interval = ptimer->timer_data.it_interval;
> +
> +  _POSIX_Timer_Release( cpu, _context );
> +  return 0;
> +}
> \ No newline at end of file
> diff --git a/testsuites/psxtests/psxtimer02/psxtimer.c 
> b/testsuites/psxtests/psxtimer02/psxtimer.c
> index 9f79d33c42..1a79369efb 100644
> --- a/testsuites/psxtests/psxtimer02/psxtimer.c
> +++ b/testsuites/psxtests/psxtimer02/psxtimer.c
> @@ -126,6 +126,32 @@ void *POSIX_Init (
>puts( "timer_delete - bad id - EINVAL" );
>status = timer_delete( timer );
>fatal_posix_service_status_errno( status, EINVAL, "bad id" );
> +
> +  puts( "timer_create (monotonic) - bad timer id pointer - EINVAL" );
> +  status = timer_create( CLOCK_MONOTONIC, , NULL );
> +  fatal_posix_service_status_errno( status, EINVAL, "bad timer id" );
> +
> +  puts( "timer_create (monotonic) - OK" );
> +  status = timer_create( CLOCK_MONOTONIC, NULL,  );
> +  posix_service_failed( status, "timer_create OK" );
> +
> +  puts( "timer_create (monotonic) - too many - EAGAIN" );
> +  status = timer_create( CLOCK_MONOTONIC, NULL,  );
> +  fatal_posix_service_status_errno( status, EAGAIN, "too many" );
> +
> +  clock_gettime( CLOCK_MONOTONIC,  );
> +  itimer.it_value = now;
> +  itimer.it_value.tv_sec = itimer.it_value.tv_sec - 1;
> +  puts( "timer_settime (monotonic) - bad itimer value - previous time - 
> EINVAL" );
> +  status = timer_settime( timer, TIMER_ABSTIME, , NULL );
> +  fatal_posix_service_status_errno( status, EINVAL, "bad itimer value #3" );
> +
> +  clock_gettime( CLOCK_MONOTONIC,  );
> +  itimer.it_value = now;
> +  itimer.it_value.tv_sec = itimer.it_value.tv_sec + 1;
> +  puts( "timer_settime (monotonic) - bad id - EINVAL" );
> +  status = timer_settime( timer1, TIMER_ABSTIME, , NULL );
> +  fatal_posix_service_status_errno( status, EINVAL, "bad id" );
>

Please provide updated psxtimer02.scn and report the results for
running rtems-test for at least the sparc/erc32 with sis including the
sptests and psxtests. If you need help how to run rtems-test, consult
the documentation and ask questions.
https://docs.rtems.org/branches/master/user/testing/index.html

>TEST_END();
>rtems_test_exit (0);
> --
> 2.32.0
>
> ___
> 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 v2] STM32 lwIP addition and CMake support

2021-08-05 Thread Gedare Bloom
STM is not going to fix their Ultimate Liberty License at this time.
https://github.com/STMicroelectronics/STM32CubeH7/issues/139#issuecomment-890806010

So, we need to avoid using their example codes.

On Wed, Jun 9, 2021 at 12:16 PM Gedare Bloom  wrote:
>
> I joined the Issue. Thanks for working on this.
>
> On Wed, Jun 9, 2021 at 11:30 AM Robin Müller  
> wrote:
> >
> > I posted a reply but I think it did not go through. Will post it now.
> >
> > Kind Regards
> > Robin
> >
> > On Wed, 9 Jun 2021 at 18:31, Robin Müller  wrote:
> >>
> >> Hi,
> >>
> >> I received a reply from STM32 about the licensing issues. They requested 
> >> more specific information about the "vendor device restrictions"  for the 
> >> HAL code.
> >> The issue is here: 
> >> https://github.com/STMicroelectronics/STM32CubeH7/issues/139
> >> Can anyone provide more information about this (maybe even directly in the 
> >> issue) ? I can forward it to them as well. Thanks a lot in advance!
> >>
> >> Kind Regards
> >> Robin
> >>
> >> On Wed, 28 Apr 2021 at 02:45, Chris Johns  wrote:
> >>>
> >>> On 28/4/21 2:58 am, Robin Müller wrote:
> >>> > Okay, I can understand that you'd like to have one build system only. 
> >>> > We had the
> >>> > same issue with a former Makefile build system and the new CMake system 
> >>> > and
> >>> > decided to make the former system obsolete> because maintaining both of 
> >>> > them would be too much work
> >>> For RTEMS what we use has been selected for a range of important reasons 
> >>> and the
> >>> rtems-central repo and the qual work highlights the importance of those
> >>> decisions. Waf is a python framework for building software and in 
> >>> rtems.git our
> >>> build system support is written in a clearly defined portable language 
> >>> with
> >>> power helper libraries. We can run code formatters on our build system, 
> >>> have
> >>> unit tests and there is even source level debuggers. We treat the build 
> >>> system
> >>> like any other piece of code we have.
> >>>
> >>> > First thing I  can do is that I split up the patch and extract the CMake
> >>> > specific files. Concerning a clean solution to allow users to use CMake 
> >>> > without
> >>> > introducing files like CMakeLists.txt,
> >>> > I am not sure right now. Extracting the information required by CMake 
> >>> > would
> >>> > again require scripts to export source files and include paths.
> >>> > The simplest solution would still be a CMakeLists.txt file in the root 
> >>> > here
> >>> > which simply sets source files and include paths in the parent scope.
> >>> > which would again be another form of maintenance burden because it 
> >>> > still needs
> >>> > to figure out which port sources to add etc.
> >>>
> >>> What about scons, meson, or a plain Makefile for those who just want to 
> >>> use
> >>> make, then there is GNU make and BSD make, the list is large? Do we open 
> >>> the
> >>> repo up so all build systems are welcome? I think we would have to so we 
> >>> are not
> >>> picking favourites.
> >>>
> >>> Who tests these build system files when the package is released? As the 
> >>> person
> >>> who releases RTEMS I do not have the time or capability to do this.
> >>>
> >>> > The rtems-cmake support is able to live without CMakeLists.txt files in 
> >>> > RTEMS
> >>> > because the BSP is already compiled at that point. Doing something 
> >>> > similar
> >>> > would require a similar process like done in the BSP where rtems-lwip is
> >>> > compiled as a static library for a specific BSP,
> >>> > installed somewhere and then an application can link against it while 
> >>> > also
> >>> > including the headers.
> >>>
> >>> I welcome the idea of rtems-cmake to grow a community of those using 
> >>> cmake to
> >>> build RTEMS applications. It is great to see this happening.
> >>>
> >>> > For the RTEMS BSP this is done through provided PKG Config files. It 
> >>> > just seems
> >>>

Re: [PATCH v2] Test needed for timer_create with CLOCK_MONOTONIC

2021-08-05 Thread Gedare Bloom
On Thu, Aug 5, 2021 at 8:56 AM zack leung  wrote:
>
> Here you could add an assert that ptimer->clock_type ==
> CLOCK_MONOTONIC || ptimer->clock_type == CLOCK_REALTIME.
>
> Would I need to assert that the timer is not a valid timer type?  Also In 
> psxtimer create I check if the timer is invalid.
>
> I can do a similar if statement as I did in psxtimercreate
>
You don't need an if statement in this case, because it should never
happen under  normal circumstances. But maybe someone messed up how
they call this function

> if ( ptimer->clock_type != CLOCK_REALTIME && ptimer->clock_type != 
> CLOCK_MONOTONIC )
> rtems_set_errno_and_return_minus_one( EINVAL );
> Zack
>
> On Wed, 4 Aug 2021 at 16:02, Gedare Bloom  wrote:
>>
>> On Wed, Jul 28, 2021 at 6:28 PM Zacchaeus Leung
>>  wrote:
>> >
>> > the timer_create() method can use CLOCK_MONOTONIC but there was  no test 
>> > for this
>> >
>> > Closes #3888
>> > ---
>> >  cpukit/include/rtems/posix/timer.h|  1 +
>> >  cpukit/posix/src/psxtimercreate.c |  3 +-
>> >  cpukit/posix/src/timergettime.c   | 52 ++-
>> >  testsuites/psxtests/psxtimer02/psxtimer.c | 26 
>> >  4 files changed, 60 insertions(+), 22 deletions(-)
>> >
>> > diff --git a/cpukit/include/rtems/posix/timer.h 
>> > b/cpukit/include/rtems/posix/timer.h
>> > index bcbf07a65a..7ae089173a 100644
>> > --- a/cpukit/include/rtems/posix/timer.h
>> > +++ b/cpukit/include/rtems/posix/timer.h
>> > @@ -48,6 +48,7 @@ typedef struct {
>> >uint32_t  ticks;  /* Number of ticks of the initialization 
>> > */
>> >uint32_t  overrun;/* Number of expirations of the timer
>> > */
>> >struct timespec   time;   /* Time at which the timer was started   
>> > */
>> > +  clockid_t clock_type; /* The type of timer */
>> >  } POSIX_Timer_Control;
>> >
>> >  /**
>> > diff --git a/cpukit/posix/src/psxtimercreate.c 
>> > b/cpukit/posix/src/psxtimercreate.c
>> > index a63cf1d100..2b5a10140f 100644
>> > --- a/cpukit/posix/src/psxtimercreate.c
>> > +++ b/cpukit/posix/src/psxtimercreate.c
>> > @@ -40,7 +40,7 @@ int timer_create(
>> >  {
>> >POSIX_Timer_Control *ptimer;
>> >
>> > -  if ( clock_id != CLOCK_REALTIME )
>> > +  if (  clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC )
>> >  rtems_set_errno_and_return_minus_one( EINVAL );
>> >
>> >if ( !timerid )
>> > @@ -91,6 +91,7 @@ int timer_create(
>> >ptimer->timer_data.it_value.tv_nsec= 0;
>> >ptimer->timer_data.it_interval.tv_sec  = 0;
>> >ptimer->timer_data.it_interval.tv_nsec = 0;
>> > +  ptimer->clock_type = clock_id;
>> >
>> >_Watchdog_Preinitialize( >Timer, _Per_CPU_Get_snapshot() );
>> >_Watchdog_Initialize( >Timer, _POSIX_Timer_TSR );
>> > diff --git a/cpukit/posix/src/timergettime.c 
>> > b/cpukit/posix/src/timergettime.c
>> > index ee2a566f0e..b29d03efa1 100644
>> > --- a/cpukit/posix/src/timergettime.c
>> > +++ b/cpukit/posix/src/timergettime.c
>> > @@ -28,6 +28,7 @@
>> >  #include 
>> >  #include 
>> >  #include 
>> > +#include 
>> >
>> >  /*
>> >   *  - When a timer is initialized, the value of the time in
>> > @@ -39,35 +40,44 @@
>> >  int timer_gettime(
>> >timer_ttimerid,
>> >struct itimerspec *value
>> >  )
>> >
>> >  {
>> >POSIX_Timer_Control *ptimer;
>> > -  ISR_lock_Context lock_context;
>> > -  uint64_t now;
>> > -  uint32_t remaining;
>> > +  ISR_lock_Context lock_context;
>> > +  Per_CPU_Control *cpu;
>> > +  struct timespec now;
>> > +  struct timespec expire;
>> > +  struct timespec result;
>> >
>> >if ( !value )
>> >  rtems_set_errno_and_return_minus_one( EINVAL );
>> >
>> >ptimer = _POSIX_Timer_Get( timerid, _context );
>> > -  if ( ptimer != NULL ) {
>> > -Per_CPU_Control *cpu;
>> > -
>> > -cpu = _POSIX_Timer_Acquire_critical( ptimer, _context );
>> > -now = cpu->Watchdog.ticks;
>> > -
>> > -if ( now < ptimer->Timer.expire ) {
>> > -  remaining

Re: [PATCH v1 1/5] rtems-utils.h: Remove ostream_guard

2021-08-04 Thread Gedare Bloom
On Wed, Aug 4, 2021 at 4:47 PM Chris Johns  wrote:
>
> On 5/8/21 1:54 am, Ryan Long wrote:
> > ostream_guard did not fix the "Not restoring ostream format" Coverity
> > issues as hoped, so there's no reason to have it.
>
> Can you capture the missing pieces here?
>
Also, just because it didn't fix coverity, doesn't mean it's a bad
thing to do. It seemed reasonable to me to save/restore the format so
it is unmodified across calls.

> Chris
> ___
> 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] bsps/arm: fix off-by-1 in gicv3 processor count

2021-08-04 Thread Gedare Bloom
On Wed, Aug 4, 2021 at 11:50 AM Sebastian Huber
 wrote:
>
> On 04/08/2021 19:45, Sebastian Huber wrote:
> > On 04/08/2021 19:18, Gedare Bloom wrote:
> >> Hi Sebastian,
> >>
> >>
> >> On Wed, Aug 4, 2021 at 11:15 AM Gedare Bloom  wrote:
> >>> ---
> >>>   bsps/shared/dev/irq/arm-gicv3.c | 4 ++--
> >>>   1 file changed, 2 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/bsps/shared/dev/irq/arm-gicv3.c
> >>> b/bsps/shared/dev/irq/arm-gicv3.c
> >>> index ea123d325e..95021f6ddf 100644
> >>> --- a/bsps/shared/dev/irq/arm-gicv3.c
> >>> +++ b/bsps/shared/dev/irq/arm-gicv3.c
> >>> @@ -551,11 +551,11 @@ uint32_t arm_gic_irq_processor_count(void)
> >>>   for (i = 0; i < CPU_MAXIMUM_PROCESSORS; ++i) {
> >>> volatile gic_redist *redist = gicv3_get_redist(i);
> >>>
> >>> +  ++cpu_count;
> >>> +
> >>> if ((redist->icrtyper & GIC_REDIST_ICRTYPER_LAST) != 0) {
> >>>   break;
> >>> }
> >>> -
> >>> -  ++cpu_count;
> >>>   }
> >> Can you check my thinking here? I'm trying to implement SMP support
> >> for the versal on aarch64. The call to arm_gic_irq_processor_count()
> >> returns 1 through this code path. Since cpu_count is initialized to 0,
> >> I think we need to increment it each time we find an active processor,
> >> until we find the last active processor, which we also need to include
> >> in the count, because the cpu_count should be NUM_PROC + 1?
> >>
> >> After I make this change, I encounter other problems with the
> >> secondary processor initialization, but at least it tries to
> >> initialize/wait for core#1 then.
> >
> > The current logic is based on this text in the Cortex-R52 TRM for
> > GICR_TYPER[Last]:
> >
> > "In a processor configured with an interrupt export port, this bit is
> > set for the Redistributor associated with
> > the export port. Otherwise, in a system with n cores, this bit is set
> > for the Redistributor associated with
> > core n-1."
> >
> > I don't know how you can figure out if a processor has an interrupt
> > export port. Maybe there are better ways to figure out the processor
> > count. I would have a look at the Linux or U-Boot sources.
> >
From what I could tell, they use the MPIDR to determine cpu count and
boot vs secondary cpu:
U-Boot:
  https://github.com/u-boot/u-boot/blob/master/arch/arm/cpu/armv8/start.S#L179
  https://github.com/u-boot/u-boot/blob/master/arch/arm/include/asm/macro.h#L146

Linux:
  https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/smp.c#L559

I may try something like that out.

> > Independent of this, I had problems with the software generated
> > interrupts on Qemu and AArch64. They worked only once. This cases the
> > new interrupt manager tests to fail with a timeout.
>
> I have to check this on the FVP simulator. Maybe this simulator has two
> interrupt export ports or we have an off by one error.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/arm: fix off-by-1 in gicv3 processor count

2021-08-04 Thread Gedare Bloom
On Wed, Aug 4, 2021 at 11:18 AM Gedare Bloom  wrote:
>
> Hi Sebastian,
>
>
> On Wed, Aug 4, 2021 at 11:15 AM Gedare Bloom  wrote:
> >
> > ---
> >  bsps/shared/dev/irq/arm-gicv3.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/bsps/shared/dev/irq/arm-gicv3.c 
> > b/bsps/shared/dev/irq/arm-gicv3.c
> > index ea123d325e..95021f6ddf 100644
> > --- a/bsps/shared/dev/irq/arm-gicv3.c
> > +++ b/bsps/shared/dev/irq/arm-gicv3.c
> > @@ -551,11 +551,11 @@ uint32_t arm_gic_irq_processor_count(void)
> >  for (i = 0; i < CPU_MAXIMUM_PROCESSORS; ++i) {
> >volatile gic_redist *redist = gicv3_get_redist(i);
> >
> > +  ++cpu_count;
> > +
> >if ((redist->icrtyper & GIC_REDIST_ICRTYPER_LAST) != 0) {
> >  break;
> >}
> > -
> > -  ++cpu_count;
> >  }
> Can you check my thinking here? I'm trying to implement SMP support
> for the versal on aarch64. The call to arm_gic_irq_processor_count()
> returns 1 through this code path. Since cpu_count is initialized to 0,
> I think we need to increment it each time we find an active processor,
> until we find the last active processor, which we also need to include
> in the count, because the cpu_count should be NUM_PROC + 1?
>
PS: the versal has 2 cores. thanks

> After I make this change, I encounter other problems with the
> secondary processor initialization, but at least it tries to
> initialize/wait for core#1 then.
>
> Thanks,
> Gedare
>
> >}
> >
> > --
> > 2.25.1
> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH] bsps/arm: fix off-by-1 in gicv3 processor count

2021-08-04 Thread Gedare Bloom
Hi Sebastian,


On Wed, Aug 4, 2021 at 11:15 AM Gedare Bloom  wrote:
>
> ---
>  bsps/shared/dev/irq/arm-gicv3.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/bsps/shared/dev/irq/arm-gicv3.c b/bsps/shared/dev/irq/arm-gicv3.c
> index ea123d325e..95021f6ddf 100644
> --- a/bsps/shared/dev/irq/arm-gicv3.c
> +++ b/bsps/shared/dev/irq/arm-gicv3.c
> @@ -551,11 +551,11 @@ uint32_t arm_gic_irq_processor_count(void)
>  for (i = 0; i < CPU_MAXIMUM_PROCESSORS; ++i) {
>volatile gic_redist *redist = gicv3_get_redist(i);
>
> +  ++cpu_count;
> +
>if ((redist->icrtyper & GIC_REDIST_ICRTYPER_LAST) != 0) {
>  break;
>}
> -
> -  ++cpu_count;
>  }
Can you check my thinking here? I'm trying to implement SMP support
for the versal on aarch64. The call to arm_gic_irq_processor_count()
returns 1 through this code path. Since cpu_count is initialized to 0,
I think we need to increment it each time we find an active processor,
until we find the last active processor, which we also need to include
in the count, because the cpu_count should be NUM_PROC + 1?

After I make this change, I encounter other problems with the
secondary processor initialization, but at least it tries to
initialize/wait for core#1 then.

Thanks,
Gedare

>}
>
> --
> 2.25.1
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


[PATCH] bsps/arm: fix off-by-1 in gicv3 processor count

2021-08-04 Thread Gedare Bloom
---
 bsps/shared/dev/irq/arm-gicv3.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bsps/shared/dev/irq/arm-gicv3.c b/bsps/shared/dev/irq/arm-gicv3.c
index ea123d325e..95021f6ddf 100644
--- a/bsps/shared/dev/irq/arm-gicv3.c
+++ b/bsps/shared/dev/irq/arm-gicv3.c
@@ -551,11 +551,11 @@ uint32_t arm_gic_irq_processor_count(void)
 for (i = 0; i < CPU_MAXIMUM_PROCESSORS; ++i) {
   volatile gic_redist *redist = gicv3_get_redist(i);
 
+  ++cpu_count;
+
   if ((redist->icrtyper & GIC_REDIST_ICRTYPER_LAST) != 0) {
 break;
   }
-
-  ++cpu_count;
 }
   }
 
-- 
2.25.1

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


Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation

2021-08-04 Thread Gedare Bloom
On Wed, Aug 4, 2021 at 9:05 AM Christian MAUDERER
 wrote:
>
> Hello Gedare,
>
> Am 04.08.21 um 16:55 schrieb Gedare Bloom:
> > On Wed, Aug 4, 2021 at 4:18 AM Christian MAUDERER
> >  wrote:
> >>
> >> Hello Chris,
> >>
> >> Am 04.08.21 um 11:17 schrieb Chris Johns:
> >>>
> >>>
> >>> On 4/8/21 6:34 pm, Christian MAUDERER wrote:
> >>>> Hello Chris,
> >>>>
> >>>> Am 04.08.21 um 09:28 schrieb Chris Johns:
> >>>>> On 3/8/21 5:00 pm, Christian MAUDERER wrote:
> >>>>>> Hello,
> >>>>>>
> >>>>>> Am 03.08.21 um 04:07 schrieb Chris Johns:
> >>>>>>> On 3/8/21 3:24 am, Sebastian Huber wrote:
> >>>>>>>> On 02/08/2021 18:37, Vijay Kumar Banerjee wrote:
> >>>>>>>>> I think there should be a high-level user manual subsection for
> >>>>>>>>> networking that describes how the selection of the network stack
> >>>>>>>>> works. We can then add another subsection about lwip since legacy
> >>>>>>>>> already has one, and libbsd is getting added now.
> >>>>>>>>
> >>>>>>>> This sounds like a good approach.
> >>>>>>>>
> >>>>>>>
> >>>>>>> I agree.
> >>>>>>>
> >>>>>>> Chris
> >>>>>>
> >>>>>> Just so that we are all on the same page:
> >>>>>>
> >>>>>> That would be a number of new subsections in
> >>>>>> https://docs.rtems.org/branches/master/user/index.html:
> >>>>>>
> >>>>>> - 15. Selecting a Network Stack
> >>>>>> - 16. Add-on: libbsd Stack
> >>>>>> - 17. Add-on: lwIP
> >>>>>> - 18. Add-on: Legacy Network Stack
> >>>>>>
> >>>>>> Or was it meant to be only a section
> >>>>>
> >>>>> I think a single section so all things networking are grouped.
> >>>>
> >>>> That will result in either a deep nesting for the chapters or in very 
> >>>> hard to
> >>>> organize information because two levels are used up already.
> >>>>
> >>>> For example the current legacy network manual has a
> >>>>
> >>>> 5.3.1. Additional include files
> >>>>
> >>>> If we make one "networking" group, that would be
> >>>>
> >>>> 15. Networking
> >>>> 15.3 Legacy Network Stack
> >>>> 15.3.5 Using Networking in an RTEMS application
> >>>> 15.3.5.3 Initialization
> >>>> 15.3.5.3.1 Additional include files
> >>>>
> >>>> And please also note: I think we should see libbsd more as an Add-on 
> >>>> package and
> >>>> less as a pure network stack.
> >>>
> >>> Yes this is true and if your top level is LibBSD you do not see 
> >>> networking and
> >>> then networking becomes confusing if spread out in pieces. What would 
> >>> LibBSD and
> >>> Legacy Networking mean if you are new RTEMS? Is Legacy networking some 
> >>> form of
> >>> old embedded realtime protocol we support? :)
> >>>
> >>> Maybe Networking is about the history, features and options available in 
> >>> each
> >>> package (Selection) and the LibBSD part is a link to the networking 
> >>> section of
> >>> that package? This would mean the lwIP and Legacy network stack is still 
> >>> under
> >>> Networking.
> >>
> >> Hm. You are right that we have to somehow make it clear what features
> >> can be provided by the libraries.
> >>
> >>>
> >>> Does "Additional includes" etc need to be a numbered section? Why not 
> >>> just make
> >>> a heading in the block without it being a section?
> >>
> >> It was more or less an example that I just took from the current legacy
> >> networking manual. I think that manual should be about at the same
> >> location and I don't think that anyone wants to do a detailed re-write.
> >> So most likely we will just move the levels down.
> >>
> >>>
> >>>> It p

  1   2   3   4   5   6   7   8   9   10   >