Re: [PATCH] cpu-supplement: Add ARM BSPs chapter
On 26/10/17 08:22, Sebastian Huber wrote: Please review this patch carefully. It adds a new chapter "ARM Board Support Packages" following the "ARM Specific Information" chapter. It adds a template structure for other BSPs. Where should we place common BSP configuration options like BSP_PRESS_KEY_FOR_RESET? We probably don't want to add a copy and paste version to every BSP section. Any comments with respect to the BSP documentation? It makes little sense to start with this work if the general direction is unclear. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS Tier Allocations.
On 27/10/17 07:13, Chris Johns wrote: On 26/10/2017 18:50, Sebastian Huber wrote: with the change to the INI format files, the target_pretest_command target_exe_filter_command disappeared. Oh I changed some names as part of a clean up. I am not sure how I can invoke the tester for a board using U-Boot connected via TTY or telnet. Do you have an example command line? Of course, with the removal of my local set up there is nothing left in the BSP configurations as examples. A command line is: $ sudo rtems-test --rtems-tools=/opt/work/rtems/4.12 \ --rtems-bsp=xilinx_zynq_zedboard \ --timeout=60 --log=t.txt \ --user-config=$HOME/.rtemstesterrc \ --mail . How did you setup your mail configuration? A sudo /opt/rtems-4.12/bin/rtems-test --rtems-bsp=imx7 --rtems-tools=/opt/rtems-4.12 /build/git-build/b-imx7/arm-rtems4.12/c/imx7/testsuites/samples/ticker/ --timeout=180 --user-config=$HOME/.rtemstesterrc --debug-trace=output --log=l.txt --mail-from="sebastian.hu...@embedded-brains.de" --mail yields error: no valid from address for mail -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/3] score: _Chain_Insert_ordered_unprotected()
Change the chain order relation to use a directly specified left hand
side value. This is similar to _RBTree_Insert_inline() and helps the
compiler to better optimize the code.
---
cpukit/score/include/rtems/score/chainimpl.h | 27 ++
.../include/rtems/score/schedulerprioritysmpimpl.h | 12 +++--
.../include/rtems/score/schedulersimpleimpl.h | 38 +-
.../score/include/rtems/score/schedulersmpimpl.h | 58 +++---
cpukit/score/src/coremsginsert.c | 12 +++--
cpukit/score/src/schedulerpriorityaffinitysmp.c| 11 ++--
cpukit/score/src/schedulersimplesmp.c | 32 +---
cpukit/score/src/schedulerstrongapa.c | 12 +++--
testsuites/sptests/spchain/init.c | 19 ---
9 files changed, 149 insertions(+), 72 deletions(-)
diff --git a/cpukit/score/include/rtems/score/chainimpl.h
b/cpukit/score/include/rtems/score/chainimpl.h
index 21c0e6b026..c94c051198 100644
--- a/cpukit/score/include/rtems/score/chainimpl.h
+++ b/cpukit/score/include/rtems/score/chainimpl.h
@@ -830,14 +830,14 @@ RTEMS_INLINE_ROUTINE bool
_Chain_Get_with_empty_check_unprotected(
/**
* @brief Chain node order.
*
- * @param[in] left The left node.
- * @param[in] right The right node.
+ * @param[in] left The left hand side.
+ * @param[in] right The right hand side.
*
* @retval true According to the order the left node precedes the right node.
* @retval false Otherwise.
*/
typedef bool ( *Chain_Node_order )(
- const Chain_Node *left,
+ const void *left,
const Chain_Node *right
);
@@ -848,20 +848,25 @@ typedef bool ( *Chain_Node_order )(
* relation holds for all nodes from the head up to the inserted node. Nodes
* after the inserted node are not moved.
*
- * @param[in,out] chain The chain.
- * @param[in,out] to_insert The node to insert.
+ * @param[in] the_chain The chain.
+ * @param[in] to_insert The node to insert.
+ * @param[in] left The left hand side passed to the order relation. It must
+ * correspond to the node to insert. The separate left hand side parameter
+ * may help the compiler to generate better code if it is stored in a local
+ * variable.
* @param[in] order The order relation.
*/
RTEMS_INLINE_ROUTINE void _Chain_Insert_ordered_unprotected(
- Chain_Control *chain,
- Chain_Node *to_insert,
- Chain_Node_order order
+ Chain_Control*the_chain,
+ Chain_Node *to_insert,
+ const void *left,
+ Chain_Node_order order
)
{
- const Chain_Node *tail = _Chain_Immutable_tail( chain );
- Chain_Node *next = _Chain_First( chain );
+ const Chain_Node *tail = _Chain_Immutable_tail( the_chain );
+ Chain_Node *next = _Chain_First( the_chain );
- while ( next != tail && !( *order )( to_insert, next ) ) {
+ while ( next != tail && !( *order )( left, next ) ) {
next = _Chain_Next( next );
}
diff --git a/cpukit/score/include/rtems/score/schedulerprioritysmpimpl.h
b/cpukit/score/include/rtems/score/schedulerprioritysmpimpl.h
index f37414c7a8..073a7ade06 100644
--- a/cpukit/score/include/rtems/score/schedulerprioritysmpimpl.h
+++ b/cpukit/score/include/rtems/score/schedulerprioritysmpimpl.h
@@ -88,19 +88,23 @@ static inline void
_Scheduler_priority_SMP_Move_from_ready_to_scheduled(
Scheduler_Node*ready_to_scheduled
)
{
- Scheduler_priority_SMP_Context *self =
-_Scheduler_priority_SMP_Get_self( context );
- Scheduler_priority_SMP_Node *node =
-_Scheduler_priority_SMP_Node_downcast( ready_to_scheduled );
+ Scheduler_priority_SMP_Context *self;
+ Scheduler_priority_SMP_Node*node;
+ Priority_Controlpriority;
+
+ self = _Scheduler_priority_SMP_Get_self( context );
+ node = _Scheduler_priority_SMP_Node_downcast( ready_to_scheduled );
_Scheduler_priority_Ready_queue_extract(
&node->Base.Base.Node.Chain,
&node->Ready_queue,
&self->Bit_map
);
+ priority = node->Base.priority;
_Chain_Insert_ordered_unprotected(
&self->Base.Scheduled,
&node->Base.Base.Node.Chain,
+&priority,
_Scheduler_SMP_Insert_priority_fifo_order
);
}
diff --git a/cpukit/score/include/rtems/score/schedulersimpleimpl.h
b/cpukit/score/include/rtems/score/schedulersimpleimpl.h
index c94f9b3bdb..ec74cdc586 100644
--- a/cpukit/score/include/rtems/score/schedulersimpleimpl.h
+++ b/cpukit/score/include/rtems/score/schedulersimpleimpl.h
@@ -39,49 +39,63 @@ RTEMS_INLINE_ROUTINE Scheduler_simple_Context *
}
RTEMS_INLINE_ROUTINE bool _Scheduler_simple_Insert_priority_lifo_order(
- const Chain_Node *to_insert,
+ const void *to_insert,
const Chain_Node *next
)
{
- const Thread_Control *thread_to_insert = (const Thread_Control *) to_insert;
- const Thread_Control *thread_next = (const Thread_Control *) next;
+ const Priority_Control *priority_to_insert;
+ const Thread_Control *thread_next;
- return _Thread_Get_priority( thread_to_insert )
-<= _Thread_Get_priority( thread_next );
+ p
[PATCH 3/3] score: Use Processor_mask instead of cpu_set_t
---
.../include/rtems/score/schedulerpriorityaffinitysmp.h | 4 ++--
cpukit/score/src/schedulerpriorityaffinitysmp.c | 16 +---
2 files changed, 7 insertions(+), 13 deletions(-)
diff --git a/cpukit/score/include/rtems/score/schedulerpriorityaffinitysmp.h
b/cpukit/score/include/rtems/score/schedulerpriorityaffinitysmp.h
index 6ae7ac5e76..d988d5752a 100644
--- a/cpukit/score/include/rtems/score/schedulerpriorityaffinitysmp.h
+++ b/cpukit/score/include/rtems/score/schedulerpriorityaffinitysmp.h
@@ -167,9 +167,9 @@ typedef struct {
Scheduler_priority_SMP_Node Base;
/**
- * Structure containing affinity set data and size
+ * @brief The thread processor affinity set.
*/
- cpu_set_t affinity;
+ Processor_mask Affinity;
} Scheduler_priority_affinity_SMP_Node;
/** @} */
diff --git a/cpukit/score/src/schedulerpriorityaffinitysmp.c
b/cpukit/score/src/schedulerpriorityaffinitysmp.c
index a948eef0fc..72b4ffb600 100644
--- a/cpukit/score/src/schedulerpriorityaffinitysmp.c
+++ b/cpukit/score/src/schedulerpriorityaffinitysmp.c
@@ -84,11 +84,7 @@ void _Scheduler_priority_affinity_SMP_Node_initialize(
* All we add is affinity information to the basic SMP node.
*/
the_node = _Scheduler_priority_affinity_SMP_Node_downcast( node );
- _Processor_mask_To_cpu_set_t(
-_SMP_Get_online_processors(),
-sizeof( the_node->affinity ),
-&the_node->affinity
- );
+ _Processor_mask_Assign( &the_node->Affinity, _SMP_Get_online_processors() );
}
/*
@@ -156,7 +152,7 @@ static Scheduler_Node
*_Scheduler_priority_affinity_SMP_Get_highest_ready(
/*
* Can this thread run on this CPU?
*/
- if ( CPU_ISSET( (int) victim_cpu_index, &node->affinity ) ) {
+ if ( _Processor_mask_Is_set( &node->Affinity, victim_cpu_index ) ) {
highest = &node->Base.Base.Base;
break;
}
@@ -233,7 +229,7 @@ static Scheduler_Node *
_Scheduler_priority_affinity_SMP_Get_lowest_scheduled(
thread = _Scheduler_Node_get_owner( &node->Base.Base.Base );
cpu_index = _Per_CPU_Get_index( _Thread_Get_CPU( thread ) );
-if ( CPU_ISSET( (int) cpu_index, &filter->affinity ) ) {
+if ( _Processor_mask_Is_set( &filter->Affinity, cpu_index ) ) {
lowest_scheduled = &node->Base.Base.Base;
break;
}
@@ -609,7 +605,6 @@ bool _Scheduler_priority_affinity_SMP_Set_affinity(
Scheduler_priority_affinity_SMP_Node *node;
States_Controlcurrent_state;
Processor_maskmy_affinity;
- cpu_set_t cpuset;
context = _Scheduler_Get_context( scheduler );
_Processor_mask_And( &my_affinity, &context->Processors, affinity );
@@ -618,14 +613,13 @@ bool _Scheduler_priority_affinity_SMP_Set_affinity(
return false;
}
- _Processor_mask_To_cpu_set_t( &my_affinity, sizeof( cpuset ), &cpuset );
node = _Scheduler_priority_affinity_SMP_Node_downcast( node_base );
/*
* The old and new set are the same, there is no point in
* doing anything.
*/
- if ( CPU_EQUAL( &cpuset, &node->affinity ) )
+ if ( _Processor_mask_Is_equal( &node->Affinity, affinity ) )
return true;
current_state = thread->current_state;
@@ -634,7 +628,7 @@ bool _Scheduler_priority_affinity_SMP_Set_affinity(
_Scheduler_priority_affinity_SMP_Block( scheduler, thread,
&node->Base.Base.Base );
}
- CPU_COPY( &cpuset, &node->affinity );
+ _Processor_mask_Assign( &node->Affinity, affinity );
if ( _States_Is_ready( current_state ) ) {
/*
--
2.12.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 1/3] score: Remove superfluous include
Update #3059.
---
cpukit/score/include/rtems/score/scheduler.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/cpukit/score/include/rtems/score/scheduler.h
b/cpukit/score/include/rtems/score/scheduler.h
index 38f3e710e7..669f82c48c 100644
--- a/cpukit/score/include/rtems/score/scheduler.h
+++ b/cpukit/score/include/rtems/score/scheduler.h
@@ -20,9 +20,6 @@
#define _RTEMS_SCORE_SCHEDULER_H
#include
-#if defined(RTEMS_SMP)
- #include
-#endif
#ifdef __cplusplus
extern "C" {
--
2.12.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH] c-user: Use configuration option as section name
This makes it easier to find the documentation for a given configuration option. Remove superfluous comments. --- c-user/configuring_a_system.rst | 1120 ++- 1 file changed, 396 insertions(+), 724 deletions(-) diff --git a/c-user/configuring_a_system.rst b/c-user/configuring_a_system.rst index c0b7151..0d4ebd7 100644 --- a/c-user/configuring_a_system.rst +++ b/c-user/configuring_a_system.rst @@ -54,8 +54,6 @@ systems can be easily configured using the mechanism and that using this mechanism will avoid internal RTEMS configuration changes impacting applications. -.. COMMENT: === Philosophy === - Default Value Selection Philosophy == @@ -65,8 +63,6 @@ possible. By default, no application resources are configured. The thread is configured and that at least one of the initialization task/thread tables is configured. -.. COMMENT: === Sizing the RTEMS Workspace === - .. _Sizing the RTEMS Workspace: Sizing the RTEMS Workspace @@ -134,8 +130,6 @@ when: Failure to provide enough space in the RTEMS Workspace may result in fatal run-time errors terminating the system. -.. COMMENT: === Potential Issues === - Potential Issues with RTEMS Workspace Size Estimation = @@ -165,8 +159,6 @@ In general, is very accurate when given enough information. However, it is quite easy to use a library and forget to account for its resources. -.. COMMENT: === Format to be followed for making changes in this file === - Format to be followed for making changes in this file = @@ -211,8 +203,6 @@ DESCRIPTION: NOTES: Any further notes. (No specific format) -.. COMMENT: === Configuration Example === - Configuration Example = @@ -295,8 +285,6 @@ things, the application implicitly used the following defaults: - The minimum task stack size will be that recommended by RTEMS for the target architecture. -.. COMMENT: === Unlimited Objects === - .. _Unlimited Objects: Unlimited Objects @@ -396,8 +384,6 @@ generally considered a safer embedded systems programming practice to know the system limits rather than experience an out of memory error at an arbitrary and largely unpredictable time in the field. -.. COMMENT: === Per Object Class Unlimited Object Instances === - .. _Per Object Class Unlimited Object Instances: Per Object Class Unlimited Object Instances @@ -427,8 +413,6 @@ Object maximum specifications can be evaluated with the ``rtems_resource_is_unlimited`` and``rtems_resource_maximum_per_allocation`` macros. -.. COMMENT: === Unlimited Object Instances === - .. _Unlimited Object Instances: Unlimited Object Instances @@ -439,12 +423,10 @@ provides the capability to make all object classes listed above operate in unlimited mode in a simple manner. The application developer is only responsible for enabling unlimited objects and specifying the allocation size. -.. COMMENT: === CONFIGURE_UNLIMITED_OBJECTS === - -.. _Enable Unlimited Object Instances: +.. _CONFIGURE_UNLIMITED_OBJECTS: -Enable Unlimited Object Instances -- +CONFIGURE_UNLIMITED_OBJECTS +--- .. index:: CONFIGURE_UNLIMITED_OBJECTS CONSTANT: @@ -469,12 +451,10 @@ NOTES: ``CONFIGURE_UNIFIED_WORK_AREAS`` so the system operates with a single pool of memory for both RTEMS and application memory allocations. -.. COMMENT: === CONFIGURE_UNLIMITED_ALLOCATION_SIZE === - -.. _Specify Unlimited Objects Allocation Size: +.. _CONFIGURE_UNLIMITED_ALLOCATION_SIZE: -Specify Unlimited Objects Allocation Size -- +CONFIGURE_UNLIMITED_ALLOCATION_SIZE +--- CONSTANT: ``CONFIGURE_UNLIMITED_ALLOCATION_SIZE`` @@ -506,20 +486,16 @@ NOTES: #define CONFIGURE_UNLIMITED_OBJECTS #define CONFIGURE_UNLIMITED_ALLOCATION_SIZE 5 -.. COMMENT: === Classic API Configuration === - Classic API Configuration = This section defines the Classic API related system configuration parameters supported by . -.. COMMENT: === CONFIGURE_MAXIMUM_TASKS === - -.. _Specify Maximum Classic API Tasks: +.. _CONFIGURE_MAXIMUM_TASKS: -Specify Maximum Classic API Tasks -- +CONFIGURE_MAXIMUM_TASKS +--- .. index:: CONFIGURE_MAXIMUM_TASKS CONSTANT: @@ -559,12 +535,10 @@ NOTES: .. COMMENT: XXX - Add xref to CONFIGURE_MAXIMUM_POSIX_THREADS. -.. COMMENT: === CONFIGURE_MAXIMUM_TIMERS === - -.. _Specify Maximum Classic API Timers: +.. _CONFIGURE_MAXIMUM_TIMERS: -Specify Maximum Classic API Timers --- +CONFIGURE_MAXIMUM_TIMERS + .. index:: CONFIGURE_MAXIMUM_TIMERS CONSTANT: @@ -586,12 +560,10 @@ DESCRIPTION: NOTES: This object class can be configu
[PATCH] CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
Close #3170. Update #3199. --- c-user/configuring_a_system.rst | 38 ++ 1 file changed, 38 insertions(+) diff --git a/c-user/configuring_a_system.rst b/c-user/configuring_a_system.rst index 0d4ebd7..2890a95 100644 --- a/c-user/configuring_a_system.rst +++ b/c-user/configuring_a_system.rst @@ -3822,6 +3822,44 @@ NOTES: BSPs should be constructed in a manner that allows ``printk()`` to work properly without the need for the console driver to be configured. +The ``CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER`` configuration option is +mutually exclusive with the +``CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER`` configuration option. + +.. _CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER: + +CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER +- +.. index:: CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER + +CONSTANT: +``CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER`` + +DATA TYPE: +Boolean feature macro. + +RANGE: +Defined or undefined. + +DEFAULT VALUE: +This is not defined by default. + +DESCRIPTION: +``CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER`` is defined if the +application wishes to include the Simple Console Device Driver. + +NOTES: +This device driver is responsible for providing standard input and output +using */dev/console*. + +This device driver writes via ``rtems_putc()`` and reads via +``getchark()``. The Termios framework is not used. There is no support to +change device settings, e.g. baud, stop bits, parity, etc. + +The ``CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER`` configuration +option is mutually exclusive with the +``CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER`` configuration option. + .. _CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER: CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER -- 2.12.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 1/2] cpukit: Add the git hash to the version if built from git source.
On 06/11/2017 17:23, Sebastian Huber wrote: > How reliable is this Autoconf stuff? Haha, that is a leading question! I suppose it depends on how you use it or abuse it as we have in our case. > Do I have to re-build everything after each > Git checkout (cpuopts.h is included in nearly every header)? The hash is only updated when configure is run. It is not 100% full proof, something like a makefile check or the post-checkout would be needed if that path is taken. What I did was a "good attempt" at best. > Why can't we use a Git post-checkout hook (attached)? I tend to get a little uneasy when a VC tool is touching code in a project underneath another operation. It makes auditing more complicated. If you think the autoconf change is still not suitable I suppose something in the makefiles could perform the post-checkout functionality. We need a way for the build and test records to show what was being tested. We currently lack that information. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 2/2] libmisc/testsupport: Add RTEMS version, build and tools to the tests.
On 06/11/2017 17:41, Sebastian Huber wrote: > >> Do all tests call the begin function in libmisc? > > Yes, I hope that this is the case. https://git.rtems.org/rtems/tree/testsuites/support/include/buffer_test_io.h#n65 is not doing that. This needs to change. > Some tests use rtems_test_begin() directly. > These tests should be changed to use TEST_BEGIN() (or vice versa). I will take a look.I think the fewer macros we have the better. We may get test_io.h (buffer_test_io.h) down to nothing. > > You can do a "#define TEST_TYPE XXX", instead of the "#define TEST_STATE_XXX". > Sure that is a good idea. I will have a look and see what happens. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS Tier Allocations.
On 06/11/2017 21:20, Sebastian Huber wrote: > On 27/10/17 07:13, Chris Johns wrote: >> On 26/10/2017 18:50, Sebastian Huber wrote: >>> with the change to the INI format files, the >>> >>> target_pretest_command >>> target_exe_filter_command >>> >>> disappeared. >> Oh I changed some names as part of a clean up. >> >>> I am not sure how I can invoke the tester for a board using U-Boot >>> connected via TTY or telnet. Do you have an example command line? >> Of course, with the removal of my local set up there is nothing left in the >> BSP configurations as examples. >> >> A command line is: >> >>$ sudo rtems-test --rtems-tools=/opt/work/rtems/4.12 \ >> --rtems-bsp=xilinx_zynq_zedboard \ >> --timeout=60 --log=t.txt \ >> --user-config=$HOME/.rtemstesterrc \ >> --mail . > > How did you setup your mail configuration? $ cat ~/.mailrc | grep chrisj set from=chr...@rtems.org > A > > sudo /opt/rtems-4.12/bin/rtems-test --rtems-bsp=imx7 > --rtems-tools=/opt/rtems-4.12 > /build/git-build/b-imx7/arm-rtems4.12/c/imx7/testsuites/samples/ticker/ > --timeout=180 --user-config=$HOME/.rtemstesterrc --debug-trace=output > --log=l.txt --mail-from="sebastian.hu...@embedded-brains.de" --mail > > yields > > error: no valid from address for mail > This is a bug. I will fix this. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Building RTEMS with Clang?
Hi, I've come across this page [1], but it hasn't been updated since 2011. I'm wondering what's the status of Clang project and how feasible it's to build RTEMS with it. [1] https://devel.rtems.org/wiki/Projects/CLANG Cheers, -- Hesham ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Building RTEMS with Clang?
On Mon, Nov 6, 2017 at 5:23 PM, Hesham Almatary wrote: > Hi, > > I've come across this page [1], but it hasn't been updated since 2011. > I'm wondering what's the status of Clang project and how feasible it's > to build RTEMS with it. > That page is status from my attempt to compile RTEMS with clang. I got far enough to know that the bsp_specs were a gcc dependent issue that had to be addressed and that the bsp_specs were assumed to be present by the build system. Things got a lot better with Gaisler (Daniel H. cc'ed) putting serious effort into clang/llvm on the SPARC for RTEMS. They even added support for a compact instruction set like the Thumb. It would be interesting to see how their SPARC work improved the situation in general. That has not been evaluated. --joel > > [1] https://devel.rtems.org/wiki/Projects/CLANG > > Cheers, > -- > Hesham > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] c-user: Use configuration option as section name
On 06/11/2017 22:56, Sebastian Huber wrote: > This makes it easier to find the documentation for a given configuration > option. Can you please generate the HTML and PDF so we can review what this looks like? I have figured out indexes and I will sweep over the docs adding them soon. The CONFIGURE_ then can be added as indexes which puts them a few of clicks away from the top level so I am not sure about this change. I tend to like the English and not the exact constants. The current labels could do with a clean up. There is way more info in the headings than needs to be there. The docs clearly show the levels in the HTML format and while not as clear in the PDF is it OK. This means for example: Instantiate Classic API Initialization Task Table => Instantiate Classic Initialization Task Table Specifying Classic API Initialization Task Entry Point => Classic Initialization Task Entry Point Specify Maximum POSIX API Threads => Maximum POSIX Threads Classic API Initialization Tasks Table Configuration => Classic Initialization Tasks Table Configuration etc. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] c-user: Use configuration option as section name
On Mon, Nov 6, 2017 at 6:56 PM, Chris Johns wrote: > On 06/11/2017 22:56, Sebastian Huber wrote: > > This makes it easier to find the documentation for a given configuration > > option. > > Can you please generate the HTML and PDF so we can review what this looks > like? > > I have figured out indexes and I will sweep over the docs adding them > soon. The > CONFIGURE_ then can be added as indexes which puts them a few of > clicks away > from the top level so I am not sure about this change. I tend to like the > English and not the exact constants. > > The current labels could do with a clean up. There is way more info in the > headings than needs to be there. The docs clearly show the levels in the > HTML > format and while not as clear in the PDF is it OK. This means for example: > > Instantiate Classic API Initialization Task Table => > Instantiate Classic Initialization Task Table > > Specifying Classic API Initialization Task Entry Point => > Classic Initialization Task Entry Point > > Specify Maximum POSIX API Threads => Maximum POSIX Threads > > Classic API Initialization Tasks Table Configuration => > Classic Initialization Tasks Table Configuration > +1 Another option -- if it fits -- is to do something like the directives and UNIX man pages. "cmd - English phrase". The risk here is that this may be too long. > > etc. > > 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
[PATCH] cpukit: Add a Version API.
Provide functions to get the version string, major, minor and revision
numbers and the version control identifer that is a unique tag for
the version control system.
Update #3199.
---
cpukit/sapi/Makefile.am| 35 +++-
cpukit/sapi/include/rtems/version.h| 76 ++
cpukit/sapi/preinstall.am | 4 ++
cpukit/sapi/src/version.c | 61 +
cpukit/sapi/vc-ident.sh| 38 +
cpukit/sapi/version-vc-ident.h.in | 7 +++
testsuites/sptests/Makefile.am | 1 +
testsuites/sptests/configure.ac| 1 +
testsuites/sptests/spversion01/Makefile.am | 20 +++
testsuites/sptests/spversion01/init.c | 58
testsuites/sptests/spversion01/spversion01.doc | 24
testsuites/sptests/spversion01/spversion01.scn | 21 +++
12 files changed, 345 insertions(+), 1 deletion(-)
create mode 100644 cpukit/sapi/include/rtems/version.h
create mode 100644 cpukit/sapi/src/version.c
create mode 100755 cpukit/sapi/vc-ident.sh
create mode 100644 cpukit/sapi/version-vc-ident.h.in
create mode 100644 testsuites/sptests/spversion01/Makefile.am
create mode 100644 testsuites/sptests/spversion01/init.c
create mode 100644 testsuites/sptests/spversion01/spversion01.doc
create mode 100644 testsuites/sptests/spversion01/spversion01.scn
diff --git a/cpukit/sapi/Makefile.am b/cpukit/sapi/Makefile.am
index 50d065be7e..b8cd096b47 100644
--- a/cpukit/sapi/Makefile.am
+++ b/cpukit/sapi/Makefile.am
@@ -22,6 +22,7 @@ include_rtems_HEADERS += include/rtems/rbtree.h
include_rtems_HEADERS += include/rtems/scheduler.h
include_rtems_HEADERS += include/rtems/timecounter.h
include_rtems_HEADERS += include/rtems/timespec.h
+include_rtems_HEADERS += include/rtems/version.h
EXTRA_DIST = include/rtems/README
@@ -34,7 +35,7 @@ libsapi_a_SOURCES = src/extension.c src/extensioncreate.c \
src/getversionstring.c \
src/chainappendnotify.c src/chaingetnotify.c src/chaingetwait.c \
src/chainprependnotify.c src/rbheap.c src/interrtext.c \
-src/fatalsrctext.c
+src/fatalsrctext.c src/version.c
libsapi_a_SOURCES += src/chainprotected.c
libsapi_a_SOURCES += src/cpucounterconverter.c
libsapi_a_SOURCES += src/delayticks.c
@@ -47,5 +48,37 @@ libsapi_a_SOURCES += src/profilingreportxml.c
libsapi_a_SOURCES += src/tcsimpleinstall.c
libsapi_a_CPPFLAGS = $(AM_CPPFLAGS)
+#
+# Create a new Version VC Ident header if the VC state has changed.
+#
+.PHONY: version-vc-ident.h
+
+vc_ident_stamp = $(am__leading_dot)vc-ident-stamp
+
+$(vc_ident_stamp): version-vc-ident.h.in vc-ident.sh
+ @+rm -f $(vc_ident_stamp)
+
+version-vc-ident.h: $(vc_ident_stamp) vc-ident.sh version-vc-ident.h.in
+ @+current_vc_ident=""; \
+ if test -f $(vc_ident_stamp); then \
+current_vc_ident=`cat $(vc_ident_stamp)`; \
+ fi; \
+ vc_ident=`$(top_srcdir)/sapi/vc-ident.sh $(top_srcdir)
$$current_vc_ident`; \
+ if test "$$vc_ident" != "matches"; then \
+ echo "Generating version-vc-ident.h"; \
+ if test "$$vc_ident" == "release"; then \
+ vc_ident="\/\* No version control found; release\? \*\/"; \
+ else \
+ vc_ident="#define RTEMS_VERSION_VC_IDENT \"$$vc_ident\""; \
+ fi; \
+ cat $(top_srcdir)/sapi/version-vc-ident.h.in | \
+ sed -e "s/@VERSION_VC_IDENT@/$$vc_ident/g" > ../version-vc-ident.h;
\
+ echo "$$vc_ident" > $(vc_ident_stamp); \
+ fi
+
+all-local: version-vc-ident.h
+
+src/version.c: version-vc-ident.h
+
include $(srcdir)/preinstall.am
include $(top_srcdir)/automake/local.am
diff --git a/cpukit/sapi/include/rtems/version.h
b/cpukit/sapi/include/rtems/version.h
new file mode 100644
index 00..d9fe4d9eff
--- /dev/null
+++ b/cpukit/sapi/include/rtems/version.h
@@ -0,0 +1,76 @@
+/**
+ * @file
+ *
+ * @brief Version API.
+ */
+
+/*
+ * Copyright (C) 2017.
+ * Chris Johns
+ *
+ * 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.
+ */
+
+#ifndef _RTEMS_VERSION_H
+#define _RTEMS_VERSION_H
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/**
+ * @defgroup ClassicVersion Version
+ *
+ * @ingroup ClassicVersion
+ *
+ * @brief The Version API provides functions to return the version or parts of
+ * the version of RTEMS you are using.
+ */
+/**@{**/
+
+/**
+ * @brief Returns the version string.
+ *
+ * @retval text The version as a string.
+ */
+const char *rtems_version( void );
+
+/**
+ * @brief Returns the version's major number.
+ *
+ * @retval int The version's major number.
+ */
+int rtems_version_major( void );
+
+/**
+ * @brief Returns the version's minor number.
+ *
+ * @retval int The version's minor number.
+ */
+int rtems_version_minor( void );
+
+/**
+ * @brief Returns the version's revisi
Re: [PATCH 1/2] cpukit: Add the git hash to the version if built from git source.
On 07/11/2017 08:49, Chris Johns wrote: >> Why can't we use a Git post-checkout hook (attached)? > > I tend to get a little uneasy when a VC tool is touching code in a project > underneath another operation. It makes auditing more complicated. If you think > the autoconf change is still not suitable I suppose something in the makefiles > could perform the post-checkout functionality. > I have used make and posted a patch. If pushed I will follow up with the documentation for the Version API. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] termios: Fix canonical mode
In canonical mode, input is made available line by line. We must stop
the canonical buffer filling upon reception of an end-of-line character.
Close #3218.
---
cpukit/libcsupport/src/termios.c | 6 ++-
testsuites/libtests/termios09/init.c | 97
2 files changed, 81 insertions(+), 22 deletions(-)
diff --git a/cpukit/libcsupport/src/termios.c b/cpukit/libcsupport/src/termios.c
index 7a114a74b9..8303e9f18d 100644
--- a/cpukit/libcsupport/src/termios.c
+++ b/cpukit/libcsupport/src/termios.c
@@ -1570,8 +1570,10 @@ fillBufferQueue (struct rtems_termios_tty *tty)
/* continue processing new character */
if (tty->termios.c_lflag & ICANON) {
-if (siproc (c, tty))
- wait = false;
+if (siproc (c, tty)) {
+ /* In canonical mode, input is made available line by line */
+ return;
+}
} else {
siproc (c, tty);
if (tty->ccount >= tty->termios.c_cc[VMIN])
diff --git a/testsuites/libtests/termios09/init.c
b/testsuites/libtests/termios09/init.c
index 7509101682..62138bc213 100644
--- a/testsuites/libtests/termios09/init.c
+++ b/testsuites/libtests/termios09/init.c
@@ -36,6 +36,8 @@ const char rtems_test_name[] = "TERMIOS 9";
#define OUTPUT_BUFFER_SIZE 64
+#define INPUT_BUFFER_SIZE 64
+
static const char * const paths[DEVICE_COUNT] = {
"/interrupt",
"/polled"
@@ -47,7 +49,9 @@ typedef struct {
size_t output_pending;
size_t output_count;
char output_buf[OUTPUT_BUFFER_SIZE];
- int input_char;
+ size_t input_head;
+ size_t input_tail;
+ unsigned char input_buf[INPUT_BUFFER_SIZE];
int callback_counter;
} device_context;
@@ -64,8 +68,7 @@ static test_context test_instance = {
{
.base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("Interrupt")
}, {
- .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("Polled"),
- .input_char = -1
+ .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER("Polled")
}
}
};
@@ -112,9 +115,14 @@ static void write_interrupt(
static int read_polled(rtems_termios_device_context *base)
{
device_context *dev = (device_context *) base;
- int c = dev->input_char;
+ int c;
- dev->input_char = -1;
+ if (dev->input_head != dev->input_tail) {
+c = dev->input_buf[dev->input_head];
+dev->input_head = (dev->input_head + 1) % INPUT_BUFFER_SIZE;
+ } else {
+c = -1;
+ }
return c;
}
@@ -187,12 +195,16 @@ static void setup(test_context *ctx)
static void input(test_context *ctx, size_t i, char c)
{
+ device_context *dev = &ctx->devices[i];
+
switch (i) {
case INTERRUPT:
- rtems_termios_enqueue_raw_characters(ctx->devices[i].tty, &c, sizeof(c));
+ rtems_termios_enqueue_raw_characters(dev->tty, &c, sizeof(c));
break;
case POLLED:
- ctx->devices[i].input_char = (unsigned char) c;
+ dev->input_buf[dev->input_tail] = (unsigned char) c;
+ dev->input_tail = (dev->input_tail + 1) % INPUT_BUFFER_SIZE;
+ rtems_test_assert(dev->input_head != dev->input_tail);
break;
default:
rtems_test_assert(0);
@@ -523,11 +535,13 @@ static void test_rx_callback_icanon(test_context *ctx)
input(ctx, i, '\n');
rtems_test_assert(dev->callback_counter == 1);
- n = read(ctx->fds[i], buf, 3);
- rtems_test_assert(n == 3);
+ n = read(ctx->fds[i], buf, 2);
+ rtems_test_assert(n == 1);
rtems_test_assert(buf[0] == '\n');
- rtems_test_assert(buf[1] == 'a');
- rtems_test_assert(buf[2] == '\n');
+ n = read(ctx->fds[i], buf, 3);
+ rtems_test_assert(n == 2);
+ rtems_test_assert(buf[0] == 'a');
+ rtems_test_assert(buf[1] == '\n');
input(ctx, i, '\4');
rtems_test_assert(dev->callback_counter == 2);
@@ -538,11 +552,15 @@ static void test_rx_callback_icanon(test_context *ctx)
input(ctx, i, '\n');
rtems_test_assert(dev->callback_counter == 2);
- n = read(ctx->fds[i], buf, 2);
+ n = read(ctx->fds[i], buf, 1);
+ rtems_test_assert(n == 0);
+
+ n = read(ctx->fds[i], buf, 3);
rtems_test_assert(n == 2);
rtems_test_assert(buf[0] == 'b');
rtems_test_assert(buf[1] == '\n');
+ /* EOL */
input(ctx, i, '1');
rtems_test_assert(dev->callback_counter == 3);
@@ -552,12 +570,15 @@ static void test_rx_callback_icanon(test_context *ctx)
input(ctx, i, '\n');
rtems_test_assert(dev->callback_counter == 3);
- n = read(ctx->fds[i], buf, 3);
- rtems_test_assert(n == 3);
+ n = read(ctx->fds[i], buf, 2);
+ rtems_test_assert(n == 1);
rtems_test_assert(buf[0] == '1');
- rtems_test_assert(buf[1] == 'c');
- rtems_test_assert(buf[2] == '\n');
+ n = read(ctx->fds[i], buf, 3);
+ rtems_test_assert(n == 2);
+ rtems_test_assert(buf[0] == 'c');
+ rtems_test_assert(buf[1] == '\n');
+ /* EOL2 */
input(ctx, i, '2');
rtems_test_assert(dev->callback_counter == 4);
@@ -567,11 +588,13 @@ static void test_rx_callback_icanon(test_context *ctx)
input(ctx, i, '\n');
rtems_test_assert(dev->callback_counter == 4);
- n = read(
Re: RTEMS Tier Allocations.
On 06/11/17 23:03, Chris Johns wrote: On 06/11/2017 21:20, Sebastian Huber wrote: On 27/10/17 07:13, Chris Johns wrote: On 26/10/2017 18:50, Sebastian Huber wrote: with the change to the INI format files, the target_pretest_command target_exe_filter_command disappeared. Oh I changed some names as part of a clean up. I am not sure how I can invoke the tester for a board using U-Boot connected via TTY or telnet. Do you have an example command line? Of course, with the removal of my local set up there is nothing left in the BSP configurations as examples. A command line is: $ sudo rtems-test --rtems-tools=/opt/work/rtems/4.12 \ --rtems-bsp=xilinx_zynq_zedboard \ --timeout=60 --log=t.txt \ --user-config=$HOME/.rtemstesterrc \ --mail . How did you setup your mail configuration? $ cat ~/.mailrc | grep chrisj setfrom=chr...@rtems.org With the sudo, I have to add this file to the root user. Would it be possible to simply generate a raw mail file which can be sent later via an e-mail client? Some test machines may be not connected to the internet for example. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] tests: Use in all tests
On 07/11/2017 17:09, Sebastian Huber wrote: > Commit:7b00c2fac57740963d3c4d8bf1cf5eab3a31f22e > - rtems_test_begin(); > + TEST_BEGIN(); > - rtems_test_end(); > + TEST_END(); I am now confused $ arm-rtems4.12-nm `find . -name \*.exe` | grep rtems_test_begin 001118dc T rtems_test_begin 0011907c T rtems_test_begin and these are in libtests/math and libtests/capture01 which I suspect have been missed with this change. I think the macros TEST_BEGIN and TEST_END should go and the test strings in the libmisc/testsupport/test.h should be moved out of the header file and into testbeginend.c. I did point this out in ... https://lists.rtems.org/pipermail/devel/2017-November/019366.html Just to be clear what I am going to do: 1. Strip out as much of buffer_test_io.h as I can and rename it test_io.h. 2. Remove all TEST_BEGIN and TEST_END macro usage and move all test into testbeginend.c. 3. Add the banners for version, build and tools. Sebastian, how does this look to you? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] tests: Use in all tests
On 07/11/17 08:15, Chris Johns wrote: On 07/11/2017 17:09, Sebastian Huber wrote: Commit:7b00c2fac57740963d3c4d8bf1cf5eab3a31f22e - rtems_test_begin(); + TEST_BEGIN(); - rtems_test_end(); + TEST_END(); I am now confused $ arm-rtems4.12-nm `find . -name \*.exe` | grep rtems_test_begin 001118dc T rtems_test_begin 0011907c T rtems_test_begin and these are in libtests/math and libtests/capture01 which I suspect have been missed with this change. Ok, I will fix this. I think the macros TEST_BEGIN and TEST_END should go and the test strings in the libmisc/testsupport/test.h should be moved out of the header file and into testbeginend.c. I did point this out in ... https://lists.rtems.org/pipermail/devel/2017-November/019366.html Just to be clear what I am going to do: 1. Strip out as much of buffer_test_io.h as I can and rename it test_io.h. 2. Remove all TEST_BEGIN and TEST_END macro usage and move all test into testbeginend.c. 3. Add the banners for version, build and tools. Sebastian, how does this look to you? Yes, this is fine, but can we please unify this stuff first. Then you only have to change this in one place or do simple search and replace changes. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems commit] tests: Use in all tests
On 07/11/17 08:24, Sebastian Huber wrote: On 07/11/17 08:15, Chris Johns wrote: On 07/11/2017 17:09, Sebastian Huber wrote: Commit: 7b00c2fac57740963d3c4d8bf1cf5eab3a31f22e - rtems_test_begin(); + TEST_BEGIN(); - rtems_test_end(); + TEST_END(); I am now confused $ arm-rtems4.12-nm `find . -name \*.exe` | grep rtems_test_begin 001118dc T rtems_test_begin 0011907c T rtems_test_begin and these are in libtests/math and libtests/capture01 which I suspect have been missed with this change. Ok, I will fix this. Now, all tests should use the TEST_BEGIN() and TEST_END() macros. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit: Add a Version API.
On 07/11/17 06:46, Chris Johns wrote: +/** + * @brief Returns the version's VC ident. This is specific to the VC being + * used. + * + * @retval int The version's VC ident. + */ +const char *rtems_version_vc_ident( void ); Normally, we don't have abbreviations in the RTEMS API functions. What about rtems_version_magic()? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] c-user: Use configuration option as section name
On 07/11/17 01:56, Chris Johns wrote: On 06/11/2017 22:56, Sebastian Huber wrote: This makes it easier to find the documentation for a given configuration option. Can you please generate the HTML and PDF so we can review what this looks like? You can review it here: https://ftp.rtems.org/pub/rtems/people/sebh/c-user/html/index.html https://ftp.rtems.org/pub/rtems/people/sebh/c-user/c-user.pdf I have figured out indexes and I will sweep over the docs adding them soon. Sounds good. The CONFIGURE_ then can be added as indexes which puts them a few of clicks away from the top level so I am not sure about this change. I tend to like the English and not the exact constants. The current labels could do with a clean up. There is way more info in the headings than needs to be there. The docs clearly show the levels in the HTML format and while not as clear in the PDF is it OK. This means for example: Instantiate Classic API Initialization Task Table => Instantiate Classic Initialization Task Table Specifying Classic API Initialization Task Entry Point => Classic Initialization Task Entry Point Specify Maximum POSIX API Threads => Maximum POSIX Threads Classic API Initialization Tasks Table Configuration => Classic Initialization Tasks Table Configuration I (and some others using the manual) found it quite hard to quickly find the configuration options with these verbose section names. My next step would be to sort them alphabetically in each group. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
