Re: [PATCH 00/10] Raspberry Pi 2 (BCM2836) SMP support

[Pavel Pisa]

Hello Chris,

On Thursday 08 of September 2016 09:14:00 Chris Johns wrote:
> On 05/09/2016 00:38, Alan Cudmore wrote:
> > I applied your patches, and verified that my apps still work on the
> > Raspberry Pi 1 ( Pi Zero ). Now I am moving to the Pi 2 for some tests.
>
> I have verified a few tests running on RPi2 no-smp using HEAD on master.
> Well done to all who have made this happen, the support is looking
> really nice.
>
> My only issue is the BSP does not reset when it exits. I think all RPi
> variants should reset once finished because it will be a big help to
> automating test runs with the rtems-test command.

I have provided simple bsp_reset() for Raspberry Pi and pushed it into master.
I have not defined BSP specific bspclean.c. May it be that there could be
some problem with SMP shutdown without

#ifdef RTEMS_SMP
  if (src == RTEMS_FATAL_SOURCE_SMP && code == SMP_FATAL_SHUTDOWN_RESPONSE) {
while (true) {
  _ARM_Wait_for_event();
}
  }
#endif

But for simple testing it seems to work.

Best wishes,

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

[PATCH] rtems_waf: moved "import os.path" to the beginning of "bsp_configure" func def to avoid UnboundLocalError.

[Saeed Ehteshamifar]

In function 'bsp_configure' of rtems_bsd.py, when conf.options.rtems_libbsd
is None, os.path is not imported, which leads to "UnboundLocalError: local
variable 'os' referenced before assignment" error.

This patch tries to avoid that error.

-
diff --git a/rtems_bsd.py b/rtems_bsd.py
index eaff438..6074f4d 100644
--- a/rtems_bsd.py
+++ b/rtems_bsd.py
@@ -48,6 +48,7 @@ def options(opt):
help = 'Path to install RTEMS LibBSD (defauls to
prefix).')

 def bsp_configure(conf, arch_bsp):
+import os.path
 conf.check(header_name = 'dlfcn.h', features = 'c')
 if not rtems.check_posix(conf):
 conf.fatal("RTEMS kernel POSIX support is disabled; configure
RTEMS with --enable-posix")
@@ -56,7 +57,6 @@ def bsp_configure(conf, arch_bsp):
 if conf.options.rtems_libbsd is None:
 rtems_libbsd_path = conf.env.PREFIX
 else:
-import os.path
 if not os.path.exists(conf.options.rtems_libbsd):
 conf.fatal('RTEMS LibBSD not found')
 rtems_libbsd_path = conf.options.rtems_libbsd
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 8/8] score: Rework thread priority management

[Sebastian Huber]

Hello Gedare,

thanks for your quick review.

On 07/09/16 20:52, Gedare Bloom wrote:

On Tue, Sep 6, 2016 at 8:40 AM, Sebastian Huber
 wrote:

Add priority nodes which contribute to the overall thread priority.

The actual priority of a thread is now an aggregation of priority nodes.
The thread priority aggregation for the home scheduler instance of a
thread consists of at least one priority node, which is normally the
real priority of the thread.  The locking protocols (e.g. priority
ceiling and priority inheritance), rate-monotonic period objects and the
POSIX sporadic server add, change and remove priority nodes.

A thread changes its priority now immediately, e.g. priority changes are
not deferred until the thread releases its last resource.

Replace the _Thread_Change_priority() function with

  * _Thread_Priority_perform_actions(),
  * _Thread_Priority_add(),
  * _Thread_Priority_remove(),
  * _Thread_Priority_change(), and
  * _Thread_Priority_update().

Update #2412.
Update #2556.
[...]
+   */
+  RBTree_Control Contributors;
+

Is it the case that a priority node is only ever on one of these
"Contributors" trees at a time?


Yes, a priority node can be added to at most one tree at a time. This 
priority aggregation is a container for priority nodes and is itself a 
priority node.



[...]
+  struct {
+Priority_Actions Actions;
+
+/**
+ * @brief Count of threads to update the priority via
+ * _Thread_Priority_update().
+ */
+size_t update_count;
I'd prefer uint32_t for unsigned counters since usually size_t denotes
an object's (byte) size.


It is related to the update table, so I think size_t is the right type.




+
+/**
+ * @brief Threads to update the priority via _Thread_Priority_update().
+ */
+Thread_Control *update[ 2 ];

Why 2?


+  } Priority;
+
/**
 * @brief Invoked in case of a detected deadlock.
 *
@@ -237,7 +274,7 @@ typedef struct {
/**
 * @brief The actual thread priority queue.
 */
-  RBTree_Control Queue;
+  Priority_Aggregation Queue;
  } Thread_queue_Priority_queue;

  /**
@@ -289,6 +326,11 @@ typedef struct _Thread_queue_Heads {

  #if defined(RTEMS_SMP)
/**
+   * @brief Boost priority.

This note could be expanded (e.g. boosted by xxx). Thanks for
improving the doxy along the way!


The boosting stuff will go away soon. The main goal of OMIP is to get 
rid of priority boosting.





+   */
+  Priority_Node Boost_priority;
+
+  /**
 * @brief One priority queue per scheduler instance.
 */
Thread_queue_Priority_queue Priority[ RTEMS_ZERO_LENGTH_ARRAY ];
@@ -337,34 +379,33 @@ struct Thread_queue_Queue {
  };

  /**
- * @brief Thread queue priority change operation.
+ * @brief Thread queue action operation.
   *
   * @param[in] queue The actual thread queue.
   * @param[in] the_thread The thread.
- * @param[in] new_priority The new priority value.
- *
- * @see Thread_queue_Operations.
+ * @param[in] queue_context The thread queue context providing the thread queue
+ *   action set to perform.  Returns the thread queue action set to perform on
+ *   the thread queue owner or the empty set in case there is nothing to do.
   */
-typedef void ( *Thread_queue_Priority_change_operation )(
-  Thread_queue_Queue *queue,
-  Thread_Control *the_thread,
-  Priority_Controlnew_priority
+typedef void ( *Thread_queue_Priority_actions_operation )(
+  Thread_queue_Queue   *queue,
+  Priority_Actions *priority_actions
  );

  /**
   * @brief Thread queue enqueue operation.
   *
   * A potential thread to update the priority due to priority inheritance is
- * returned via the thread queue path.  This thread is handed over to
- * _Thread_Update_priority().
+ * returned via the thread queue context.  This thread is handed over to
+ * _Thread_Priority_update().
   *
   * @param[in] queue The actual thread queue.
   * @param[in] the_thread The thread to enqueue on the queue.
   */
  typedef void ( *Thread_queue_Enqueue_operation )(
-  Thread_queue_Queue *queue,
-  Thread_Control *the_thread,
-  Thread_queue_Path  *path
+  Thread_queue_Queue   *queue,
+  Thread_Control   *the_thread,
+  Thread_queue_Context *queue_context
  );

  /**
@@ -374,8 +415,9 @@ typedef void ( *Thread_queue_Enqueue_operation )(
   * @param[in] the_thread The thread to extract from the thread queue.
   */
  typedef void ( *Thread_queue_Extract_operation )(
-  Thread_queue_Queue *queue,
-  Thread_Control *the_thread
+  Thread_queue_Queue   *queue,
+  Thread_Control   *the_thread,
+  Thread_queue_Context *queue_context
  );

  /**
@@ -390,9 +432,10 @@ typedef void ( *Thread_queue_Extract_operation )(
   * @return The previous first thread on the queue.
   */
  typedef Thread_Control *( *Thread_queue_Surrender_operation )(
-  Thread_queue_Queue *queue,
-  Thread_queue_Heads *heads,
-  Thread_Control *previous_owner
+  Thread_queue_Queue   *queue,
+  Thread_queue_Heads   *heads,
+  

Re: [PATCH 00/10] Raspberry Pi 2 (BCM2836) SMP support

[Chris Johns]

On 05/09/2016 00:38, Alan Cudmore wrote:

I applied your patches, and verified that my apps still work on the Raspberry 
Pi 1 ( Pi Zero ). Now I am moving to the Pi 2 for some tests.


I have verified a few tests running on RPi2 no-smp using HEAD on master. 
Well done to all who have made this happen, the support is looking 
really nice.


My only issue is the BSP does not reset when it exits. I think all RPi 
variants should reset once finished because it will be a big help to 
automating test runs with the rtems-test command.


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