Is there a way to test all case in real bsp automatically?

2020-11-10 Thread small...@aliyun.com 
hi, all
Recently, I was testing rtems-5.1 in xilinx bsp. There are many test cases 
which need compile and burn to bsp each time.
If I test 100 cases, I need compile and burn 100 times manually. This is boring.
Is there a way to test 100 cases in one compilation and burning ?
Thanks very much.



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

Re: [PATCH] bsp/atsam: Fix XDMAD status

2020-11-10 Thread Christian Mauderer 

On 10/11/2020 06:34, Chris Johns wrote:

On 9/11/20 7:20 pm, Christian Mauderer wrote:

I would like to apply this patch to master (ticket #4173) and to the 5 branch
(ticket #4172). It would be great if someone could have a look and acknowledge 
it.


OK for 5.

Chris



Thanks. I'll give it another day and then commit it.

Best regards

Christian

--

embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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

[PATCH 1/2] libtest: Make test case allocator configurable

2020-11-10 Thread Sebastian Huber 
---
 cpukit/include/rtems/test.h   |  7 ++
 cpukit/libtest/t-test-malloc.c| 80 ++---
 cpukit/libtest/t-test.c   | 88 +++
 cpukit/libtest/testrun.c  |  2 +
 testsuites/libtests/ttest01/init.c|  2 +
 testsuites/smptests/smpmulticast01/init.c |  4 +-
 testsuites/validation/ts-validation-0.c   |  2 +
 7 files changed, 110 insertions(+), 75 deletions(-)

diff --git a/cpukit/include/rtems/test.h b/cpukit/include/rtems/test.h
index 935e796bf0..e24d9d29ac 100644
--- a/cpukit/include/rtems/test.h
+++ b/cpukit/include/rtems/test.h
@@ -2253,6 +2253,10 @@ T_time T_case_begin_time(void);
 
 /** @} */
 
+void *T_heap_allocate(size_t, void *);
+
+void T_heap_deallocate(void *, void *);
+
 void *T_malloc(size_t);
 
 void *T_calloc(size_t, size_t);
@@ -2286,6 +2290,9 @@ typedef struct {
void *putchar_arg;
T_verbosity verbosity;
T_time (*now)(void);
+   void *(*allocate)(size_t, void *);
+   void (*deallocate)(void *, void *);
+   void *allocator_arg;
size_t action_count;
const T_action *actions;
 } T_config;
diff --git a/cpukit/libtest/t-test-malloc.c b/cpukit/libtest/t-test-malloc.c
index 369bff9a57..c54b5f6672 100644
--- a/cpukit/libtest/t-test-malloc.c
+++ b/cpukit/libtest/t-test-malloc.c
@@ -29,84 +29,16 @@
 
 #include 
 
-#ifdef __BIGGEST_ALIGNMENT__
-#define T_BIGGEST_ALIGNMENT __BIGGEST_ALIGNMENT__
-#else
-#define T_BIGGEST_ALIGNMENT sizeof(long long)
-#endif
-
-typedef struct __attribute__((__aligned__(T_BIGGEST_ALIGNMENT))) {
-   T_destructor base;
-   void (*destroy)(void *);
-} T_malloc_destructor;
-
-static void
-T_malloc_destroy(T_destructor *base)
-{
-   T_malloc_destructor *dtor;
-
-   dtor = (T_malloc_destructor *)(uintptr_t)base;
-
-   if (dtor->destroy != NULL) {
-   (*dtor->destroy)(dtor + 1);
-   }
-
-   free(dtor);
-}
-
-static void *
-T_do_malloc(size_t size, void (*destroy)(void *))
-{
-   T_malloc_destructor *dtor;
-   size_t new_size;
-
-   new_size = sizeof(*dtor) + size;
-   if (new_size <= size) {
-   return NULL;
-   }
-
-   dtor = malloc(new_size);
-   if (dtor != NULL) {
-   dtor->destroy = destroy;
-   T_add_destructor(&dtor->base, T_malloc_destroy);
-   ++dtor;
-   }
-
-   return dtor;
-}
-
-void *
-T_malloc(size_t size)
-{
-   return T_do_malloc(size, NULL);
-}
-
-void *
-T_calloc(size_t nelem, size_t elsize)
-{
-   return T_zalloc(nelem * elsize, NULL);
-}
-
 void *
-T_zalloc(size_t size, void (*destroy)(void *))
+T_heap_allocate(size_t size, void *arg)
 {
-   void *p;
-
-   p = T_do_malloc(size, destroy);
-   if (p != NULL) {
-   p = memset(p, 0, size);
-   }
-
-   return p;
+   (void)arg;
+   return malloc(size);
 }
 
 void
-T_free(void *ptr)
+T_heap_deallocate(void *ptr, void *arg)
 {
-   T_malloc_destructor *dtor;
-
-   dtor = ptr;
-   --dtor;
-   T_remove_destructor(&dtor->base);
-   free(dtor);
+   (void)arg;
+   free(ptr);
 }
diff --git a/cpukit/libtest/t-test.c b/cpukit/libtest/t-test.c
index 11f1cf70e9..64c3d33703 100644
--- a/cpukit/libtest/t-test.c
+++ b/cpukit/libtest/t-test.c
@@ -1299,3 +1299,91 @@ T_get_scope(const char * const * const *desc, char *buf, 
size_t n,
 
return n - c;
 }
+
+#ifdef __BIGGEST_ALIGNMENT__
+#define T_BIGGEST_ALIGNMENT __BIGGEST_ALIGNMENT__
+#else
+#define T_BIGGEST_ALIGNMENT sizeof(long long)
+#endif
+
+typedef struct __attribute__((__aligned__(T_BIGGEST_ALIGNMENT))) {
+   T_destructor base;
+   void (*destroy)(void *);
+} T_malloc_destructor;
+
+static void
+T_malloc_destroy(T_destructor *base)
+{
+   const T_config *config;
+   T_malloc_destructor *dtor;
+
+   dtor = (T_malloc_destructor *)(uintptr_t)base;
+
+   if (dtor->destroy != NULL) {
+   (*dtor->destroy)(dtor + 1);
+   }
+
+   config = T_instance.config;
+   (*config->deallocate)(dtor, config->allocator_arg);
+}
+
+static void *
+T_do_malloc(size_t size, void (*destroy)(void *))
+{
+   const T_config *config;
+   T_malloc_destructor *dtor;
+   size_t new_size;
+
+   new_size = sizeof(*dtor) + size;
+   if (new_size <= size) {
+   return NULL;
+   }
+
+   config = T_instance.config;
+   dtor = (*config->allocate)(new_size, config->allocator_arg);
+   if (dtor != NULL) {
+   dtor->destroy = destroy;
+   T_add_destructor(&dtor->base, T_malloc_destroy);
+   ++dtor;
+   }
+
+   return dtor;
+}
+
+void *
+T_malloc(size_t size)
+{
+   return T_do_malloc(size, NULL);
+}
+
+void *
+T_calloc(size_t nelem, size_t elsize)
+{
+   return T_zalloc(nelem * elsize, NULL);
+}
+
+void *
+T_zalloc(size_t size, void (*destroy)(void *))
+{
+   void *p;
+
+   p = T_do_malloc(size, destroy);
+   if (p !=

[PATCH 2/2] libtest: Simplify runtime measurement support

2020-11-10 Thread Sebastian Huber 
Use the test case allocator functions T_zalloc() and T_malloc().
Restore the task affinity of the runner task.
---
 cpukit/libtest/t-test-rtems-measure.c | 64 +++
 1 file changed, 25 insertions(+), 39 deletions(-)

diff --git a/cpukit/libtest/t-test-rtems-measure.c 
b/cpukit/libtest/t-test-rtems-measure.c
index 162aad0e93..bba8bd5dac 100644
--- a/cpukit/libtest/t-test-rtems-measure.c
+++ b/cpukit/libtest/t-test-rtems-measure.c
@@ -43,7 +43,6 @@ typedef struct {
 } load_context;
 
 struct T_measure_runtime_context {
-   T_destructor destructor;
size_t sample_count;
T_ticks *samples;
size_t cache_line_size;
@@ -52,6 +51,9 @@ struct T_measure_runtime_context {
rtems_id runner;
uint32_t load_count;
load_context *load_contexts;
+#ifdef RTEMS_SMP
+   cpu_set_t cpus;
+#endif
 };
 
 static unsigned int
@@ -127,34 +129,28 @@ load_worker(rtems_task_argument arg)
 }
 
 static void
-destroy_worker(const T_measure_runtime_context *ctx)
+destroy(void *ptr)
 {
+   const T_measure_runtime_context *ctx;
uint32_t load;
 
+   ctx = ptr;
+
for (load = 0; load < ctx->load_count; ++load) {
const load_context *lctx;
 
lctx = &ctx->load_contexts[load];
 
-   if (lctx->chunk != ctx->chunk) {
-   free(RTEMS_DEVOLATILE(unsigned int *, lctx->chunk));
-   }
-
 
if (lctx->id != 0) {
-   rtems_task_delete(lctx->id);
+   (void)rtems_task_delete(lctx->id);
}
}
-}
 
-static void
-destroy(T_destructor *dtor)
-{
-   T_measure_runtime_context *ctx;
-
-   ctx = (T_measure_runtime_context *)dtor;
-   destroy_worker(ctx);
-   free(ctx);
+#ifdef RTEMS_SMP
+   (void)rtems_task_set_affinity(RTEMS_SELF, sizeof(ctx->cpus),
+   &ctx->cpus);
+#endif
 }
 
 static void *
@@ -166,7 +162,7 @@ add_offset(const volatile void *p, uintptr_t o)
 static void *
 align_up(const volatile void *p, uintptr_t a)
 {
-   return (void *)(((uintptr_t)p + a - 1) & ~(a - 1));
+   return (void *)RTEMS_ALIGN_UP((uintptr_t)p, a);
 }
 
 T_measure_runtime_context *
@@ -178,7 +174,6 @@ T_measure_runtime_create(const T_measure_runtime_config 
*config)
size_t chunk_size;
size_t load_size;
uint32_t load_count;
-   bool success;
uint32_t i;
 #ifdef RTEMS_SMP
cpu_set_t cpu;
@@ -203,13 +198,21 @@ T_measure_runtime_create(const T_measure_runtime_config 
*config)
load_count = rtems_scheduler_get_processor_maximum();
load_size = load_count * sizeof(ctx->load_contexts[0]);
 
-   ctx = malloc(sizeof(*ctx) + sample_size + load_size + chunk_size +
-   2 * cache_line_size);
+   ctx = T_zalloc(sizeof(*ctx) + sample_size + load_size + chunk_size +
+   2 * cache_line_size, destroy);
 
if (ctx == NULL) {
return NULL;
}
 
+#ifdef RTEMS_SMP
+   (void)rtems_task_get_affinity(RTEMS_SELF, sizeof(ctx->cpus),
+   &ctx->cpus);
+   CPU_ZERO(&cpu);
+   CPU_SET(0, &cpu);
+   (void)rtems_task_set_affinity(RTEMS_SELF, sizeof(cpu), &cpu);
+#endif
+
ctx->sample_count = config->sample_count;
ctx->samples = add_offset(ctx, sizeof(*ctx));
ctx->cache_line_size = cache_line_size;
@@ -221,9 +224,6 @@ T_measure_runtime_create(const T_measure_runtime_config 
*config)
ctx->samples = align_up(ctx->samples, cache_line_size);
ctx->chunk = align_up(ctx->chunk, cache_line_size);
 
-   memset(ctx->load_contexts, 0, load_size);
-   success = true;
-
for (i = 0; i < load_count; ++i) {
rtems_status_code sc;
rtems_id id;
@@ -242,16 +242,14 @@ T_measure_runtime_create(const T_measure_runtime_config 
*config)
RTEMS_MAXIMUM_PRIORITY - 1, RTEMS_MINIMUM_STACK_SIZE,
RTEMS_DEFAULT_MODES, RTEMS_DEFAULT_ATTRIBUTES, &id);
if (sc != RTEMS_SUCCESSFUL) {
-   success = false;
-   break;
+   return NULL;
}
 
lctx = &ctx->load_contexts[i];
-
lctx->master = ctx;
lctx->id = id;
 
-   lctx->chunk = malloc(chunk_size);
+   lctx->chunk = T_malloc(chunk_size);
if (lctx->chunk == NULL) {
lctx->chunk = ctx->chunk;
}
@@ -272,18 +270,6 @@ T_measure_runtime_create(const T_measure_runtime_config 
*config)
suspend_worker(lctx);
}
 
-   if (success) {
-#ifdef RTEMS_SMP
-   CPU_ZERO(&cpu);
-   CPU_SET(0, &cpu);
-   (void)rtems_task_set_affinity(RTEMS_SELF, sizeof(cpu), &cpu);
-#endif
-   } else {
-   destroy(&ctx->destructor);
-   return NULL;
-   }
-
-   T_add_destructor(&ctx->destructor, dest

Re: [PATCH 1/2] libtest: Make test case allocator configurable

2020-11-10 Thread Sebastian Huber 

Please ignore this patch. I will simplify it in a v2 of the patch set.

--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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] eng: Rework and clarify Doxygen Guidelines

2020-11-10 Thread Sebastian Huber 

Hello Joel,

On 09/11/2020 15:37, Sebastian Huber wrote:

On 09/11/2020 15:12, Joel Sherrill wrote:

On Mon, Nov 9, 2020 at 8:02 AM Sebastian Huber 
> wrote:


    ---
     eng/coding-doxygen.rst  | 210
    
     eng/coding-file-hdr.rst |   2 +
     2 files changed, 149 insertions(+), 63 deletions(-)

    diff --git a/eng/coding-doxygen.rst b/eng/coding-doxygen.rst
    index f4308ef..b2e6b61 100644
    --- a/eng/coding-doxygen.rst
    +++ b/eng/coding-doxygen.rst
    @@ -16,12 +16,13 @@ In the RTEMS source code, CamelCase is rarely
    used, so this makes it easier to
     search and replace Doxygen groups.  It avoids ambiguous 
references to

     functions, types, defines, macros, and groups.  All groups shall
    have an
     ``RTEMS`` prefix.  This makes it possible to include the RTEMS
    files with
    -Doxygen comments in a larger project without name conflicts.
    +Doxygen comments in a larger project without name conflicts. The
    group name
    +shall use `Title Case
    >`_.

     .. code:: c

         /**
    -     * @defgroup RTEMSScoreThread
    +     * @defgroup RTEMSScoreThread Thread Handler
          *
          * @ingrop RTEMSScore
          *
    @@ -36,18 +37,28 @@ global variable declaration shall belong to at
    least one Doxygen group.  Use
     ``@defgroup`` and ``@addtogroup`` with ``@{`` and ``@}`` brackets
    to add
     members to a group.  A group shall be defined at most once. Each
    group shall
     be documented with an ``@brief`` description and an optional 
detailed

    -description.  The ``@brief`` description shall use
    -`Title Case >`_.
    -Use grammatically correct sentences for the detailed descriptions.
    +description.  Use grammatically correct sentences for the
    ``@brief`` and
    +detailed descriptions.
    +
    +For the ``@brief`` description use phrases like this:
    +
    +* This group contains ... and so on.
    +
    +* The XYZ Handler provides ... and so on.
    +
    +* The ABC Component contains ... and so on.


I don't know where the idea @brief should be short sentences came from.
I reviewed the Doxgyen HTML and PDF output and come to the conclusion 
that the use of Title Case makes no sense for the brief descriptions.

@brief is used to make table of contents type pages and those should
read more like titles than the first sentence of the detailed 
description.


https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/doxygen/modules.html 
 

That Doxgyen removes a trailing '.' from the brief descriptions is a 
bug or feature. I didn't find a corresponding view in the PDF.


If you look at the PDF, it really is used for the Table of Contents and
a sentence is quite odd there.

It should read like a chapter title


I looked at the PDF output and the brief descriptions are not included 
in the table of contents. The group names are included in the table of 
contents. For the group names Title Case should be used. The brief 
descriptions are the first sentence of the module description. This is 
identical to the HTML output.


Please have a look at:

https://ftp.rtems.org/pub/rtems/people/sebh/refman.pdf

https://ftp.rtems.org/pub/rtems/releases/5/5.1/docs/html/doxygen/group__ClassicEvent.html#details 



You also have the autobrief options which use the first line (until 
the first dot) as the brief description.



do you still have issues with this change?

--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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

Code coverage via GCOV

2020-11-10 Thread Sebastian Huber 

Hello,

I reviewed a bit how the code coverage information is produced by GCC 
and what libgcov does. I think if we want to use GCOV in RTEMS to get 
code coverage in all system states, then we need some tweaks in GCC:


https://gcc.gnu.org/pipermail/gcc/2020-November/234164.html

--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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: Fatal exceptions on context-switching for more than two isolated threads

2020-11-10 Thread Utkarsh Rai 
On Thu, Nov 5, 2020 at 11:45 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 04/11/2020 19:38, Gedare Bloom wrote:
>
> >>   Based on the above suggestions I tried to move the
> User_extensions_Iterator storage to the TCB by adding a new field to the
> structure, but that did not compile(userextimpl.h is not included with
> thread.h because of cyclic dependency).
> >> This made me try out a naive hack, I defined a structure similar to the
> User_extensions_Iterator and then added the field to the TCB. The next
> problem that I faced was during the creation of the idle thread. Since an
> idle thread is created during system
> >> initialization, the 'executing' pointer pointing the TCB is null, and
> hence referencing to the iterator placed in the TCB for the idle thread
> fails. This was resolved by separating the cases for an idle thread and
> other threads. After that I was able to successfully isolate more than two
> thread stacks.
> >> Can you please suggest a more acceptable approach for resolving this
> issue?
> >>
> > At a high level the approach you took makes sense. You have moved the
> > user extensions to the TCB, and then avoid accessing it in case the
> > TCB is null (i.e., the initial context switch). I'd need to see the
> > code to make any further critical analysis. But it sounds acceptable
> > to me.
> The executing thread pointer can be NULL and there is already a check
> for this in _User_extensions_Iterate(). In this case you can use a
> member in the _Per_CPU_Information[].
>
> --
> 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.
>
>
Based on your comments I have made the following changes in the user
extension iterator scheme. Some of the code is still hackish( if-else
conditional for handling TCB pointer when it is NULL ) and I would request
your suggestions on the same.

diff --git a/cpukit/include/rtems/score/percpu.h
b/cpukit/include/rtems/score/percpu.h
index 31bc2b0bff..6e15f4b1ba 100644
--- a/cpukit/include/rtems/score/percpu.h
+++ b/cpukit/include/rtems/score/percpu.h
@@ -25,7 +25,7 @@
   #include 
 #else
   #include 
-  #include 
+  #include 
   #include 
   #include 
   #include 
@@ -339,6 +339,20 @@ typedef enum {
   PER_CPU_WATCHDOG_COUNT
 } Per_CPU_Watchdog_index;

+#if defined ( RTEMS_THREAD_STACK_PROTECTION )
+  /**
+   * @brief  Per CPU user extensions iterator structure
+   *
+   * This structure is used to refer to the user extensions iterator when
+   * thread stack protection is configured.
+  */
+typedef struct Per_CPU_User_extensions_Iterator {
+  Chain_Iterator   Iterator;
+  struct Per_CPU_User_extensions_Iterator *previous;
+} Per_CPU_User_extensions_Iterator;
+#endif
+
+
 /**
  *  @brief Per CPU Core Structure
  *
@@ -595,6 +609,10 @@ typedef struct Per_CPU_Control {
 bool boot;
   #endif

+  #if defined (RTEMS_THREAD_STACK_PROTECTION)
+Per_CPU_User_extensions_Iterator iter;
+  #endif
+
   struct Record_Control *record;

   Per_CPU_Stats Stats;
diff --git a/cpukit/include/rtems/score/thread.h
b/cpukit/include/rtems/score/thread.h
index ee0aee5b79..98b85a66af 100644
--- a/cpukit/include/rtems/score/thread.h
+++ b/cpukit/include/rtems/score/thread.h
@@ -636,6 +636,13 @@ struct Thread_Action {
   Thread_Action_handler handler;
 };

+#if defined (RTEMS_THREAD_STACK_PROTECTION)
+  typedef struct Thread_User_extensions_Iterator {
+Chain_Iterator   Iterator;
+struct Thread_User_extensions_Iterator *previous;
+  } Thread_User_extensions_Iterator;
+#endif
+
 /**
  * @brief Per-thread information for POSIX Keys.
  */
@@ -864,6 +871,10 @@ struct _Thread_Control {
*/
   struct _pthread_cleanup_context *last_cleanup_context;

+#if defined (RTEMS_THREAD_STACK_PROTECTION)
+  Thread_User_extensions_Iterator iter;
+#endif
+
   /**
* @brief LIFO list of user extensions iterators.
*/
diff --git a/cpukit/score/src/userextiterate.c
b/cpukit/score/src/userextiterate.c
index 06665a2d7a..814e695018 100644
--- a/cpukit/score/src/userextiterate.c
+++ b/cpukit/score/src/userextiterate.c
@@ -181,22 +181,47 @@ void _User_extensions_Iterate(

   _User_extensions_Acquire( &lock_context );

-  _Chain_Iterator_initialize(
+  if ( executing != NULL ) {
+executing->iter.previous = executing->last_user_extensions_iterator;
+executing->last_user_extensions_iterator = &executing->iter;
+
+ _Chain_Iterator_initialize(
 &_User_extensions_List.Active,
 &_User_extensions_List.Iterators,
-&iter.Iterator,
+&executing->iter.Iterator,
 direction
   );

-  if ( executing != NULL ) {
-iter.previous = executing->last_user_extensions_iterator;
-executing->last_user_extensions_iterator = &iter;
+while ( ( node = _Chai

Re: [PATCH 4/4] eng: Clarify "Coding Conventions" introduction

2020-11-10 Thread Gedare Bloom 
all 4 look good to me.

On Thu, Nov 5, 2020 at 11:43 AM Sebastian Huber
 wrote:
>
> ---
>  eng/coding-conventions.rst | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/eng/coding-conventions.rst b/eng/coding-conventions.rst
> index 5dd8df5..e34cd74 100644
> --- a/eng/coding-conventions.rst
> +++ b/eng/coding-conventions.rst
> @@ -9,11 +9,11 @@
>  Coding Conventions
>  **
>
> -The style of RTEMS is generally consistent in the core areas.
> -This page attempts to capture generally accepted practices.
> -When in doubt, consult the code around you or look in cpukit/rtems.
> -See the sister page `Doxygen Recommendations 
> `_.
> -for examples that illustrate style rules and Doxygen usage.
> +The style of RTEMS is generally consistent in the core areas.  This section
> +attempts to capture generally accepted practices.  When in doubt, consult the
> +code around you, look in the RTEMS sources in the directories
> +:file:`cpukit/include/rtems/score` and :file:`cpukit/score`, or ask on the
> +:r:list:`devel`.
>
>  Source Documentation
>  
> --
> 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 rtems 8/8] jffs2: Replace non-ASCII copyright character

2020-11-10 Thread Gedare Bloom 
Let's leave the imported code the way they are for easier
integration/maintenance, I think.

On Mon, Nov 9, 2020 at 12:29 AM Christian Mauderer
 wrote:
>
> On 09/11/2020 07:58, Sebastian Huber wrote:
> > On 07/11/2020 14:23, Christian Mauderer wrote:
> >
> >> diff --git a/cpukit/libfs/src/jffs2/include/linux/jffs2.h
> >> b/cpukit/libfs/src/jffs2/include/linux/jffs2.h
> >> index a18b719f49..202cb46b8d 100644
> >> --- a/cpukit/libfs/src/jffs2/include/linux/jffs2.h
> >> +++ b/cpukit/libfs/src/jffs2/include/linux/jffs2.h
> >> @@ -1,8 +1,8 @@
> >>   /*
> >>* JFFS2 -- Journalling Flash File System, Version 2.
> >>*
> >> - * Copyright © 2001-2007 Red Hat, Inc.
> >> - * Copyright © 2004-2010 David Woodhouse
> >> + * Copyright (c) 2001-2007 Red Hat, Inc.
> >> + * Copyright (c) 2004-2010 David Woodhouse
> > This code is imported from Linux. Do we really have to change this?
> >
>
> Hello Sebastian,
>
> like already stated in the introduction mail: I'm not really sure about
> this one and about patch 6 and 7 myself because they touch imported
> code. So no problem if we don't add the last three ones.
>
> Best regards
>
> Christian
>
> --
> 
> embedded brains GmbH
> 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
> PGP: Public key available on request.
>
> embedded brains GmbH
> 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: Is there a way to test all case in real bsp automatically?

2020-11-10 Thread Chris Johns 
On 10/11/20 7:27 pm, small...@aliyun.com wrote:
> hi, all
> Recently, I was testing rtems-5.1 in xilinx bsp. There are many test cases 
> which
> need compile and burn to bsp each time.
> If I test 100 cases, I need compile and burn 100 times manually. This is 
> boring.
> Is there a way to test 100 cases in one compilation and burning ?
> Thanks very much.

For the Zynq I build and run uboot with a configuration to TFTP load an image.
The uboot configuration can seen at [1].

I then configure RTEMS Tester [2] with the configuration for a Zedboard with:

tftp_port  = 9101
bsp_tty_dev= cs-ser-2:30003
target_pretest_command = rtems-zynq-mkimg @EXE@
target_exe_filter  = /\.exe/.exe.img/
target_on_command  = cs-pw-ctl 1 toggle-on 2 4
target_off_command = cs-pw-ctl 1 off 2
target_reset_command   = cs-pw-ctl 1 toggle-on 2 3

where port 9101 is a redirected port using the TFTP proxy server in RTEMS Tools,
cs-ser-2 is a RPi box running ser2net for the console, the rtems-zynq-mkimg
command is attached, and cs-pw-ctl is a custom command to control a network
based power switch. The configuration can be saved in $HOME/.rtemstesterrc.

Recent RTEMS Tools have a Python base TFTP server you can test with and a TFTP
proxy that lets you proxy and share a single TFTP port out to many ports using
the MAC address of the board.

You can also use the mkimage.py command in RTEMS Tools if you do not have a
mkimage available on your host.

Chris

[1] https://docs.rtems.org/branches/master/user/testing/tftp.html#u-boot-set-up
[2] 
https://docs.rtems.org/branches/master/user/testing/tftp.html#bsp-configuration
#! /bin/sh
set -e

OBJCOPY_FOR_TARGET=/opt/work/rtems/5/bin/arm-rtems5-objcopy
OBJCOPY="$OBJCOPY_FOR_TARGET"

START_ADDR=0x00104000
ENTRY_ADDR=0x00104000

for EXE_NAME in $*
do
 if [ ! -f $EXE_NAME ]; then
  echo "error: not found: $EXE_NAME"
  exit 1
 fi
 echo "Image: $EXE_NAME"
 ${OBJCOPY} -R -S --strip-debug -O binary "$EXE_NAME" "$EXE_NAME.bin" || exit 1
 cat "$EXE_NAME.bin" | gzip -9 >"$EXE_NAME.gz"
 mkimage \
   -A arm -O rtems -T kernel -a $START_ADDR -e $ENTRY_ADDR -n "RTEMS" \
   -d "$EXE_NAME.gz" "$EXE_NAME.img"
done

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

Re: [PATCH] libtests/dl06: Add -lm

2020-11-10 Thread Chris Johns 
On 10/11/20 6:32 pm, Sebastian Huber wrote:
> On 09/11/2020 23:42, Chris Johns wrote:
> 
>> On 9/11/20 6:24 pm, Sebastian Huber wrote:
>>> On 09/11/2020 02:23, Chris Johns wrote:
>>>
 On 3/11/20 3:39 am, Sebastian Huber wrote:
> There is probably something wrong with this test program.  If it is 
> compiled
> without function/data sections, no optimization, and no linker garbage
> collection, then there is an undefined reference to atan2() and tan().
 These symbols are referenced in the loaded module ...

 https://git.rtems.org/rtems/tree/testsuites/libtests/dl06/dl06-o2.c

 This test gets rtems-ld with the RAP format to collect the atan1 and tan 
 code
 into the loaded module. They should not be present in the base image. The 
 libm
 library is used because it is_not_  part of the standard libraries linked
 and is
 available everywhere.

> Fix this issue by adding -lm.
 Is the error linking the base kernel image or the RAP loadable module?

 If it is the loadable module and this is how you add the libraries to be
 searched to the rtems-ld command then the fix is needed and there is no
 problem.
 If the error was in the base kernel image then I suggest something else is
 wrong
 because those symbols should not be present in the base image. If the build
 system can support options for just rtems-ld then adding it there would be
 good.
>>> The error is in this command:
>>>
>>>
>>> [4044/4050] Processing link:
>>> build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl06/dl06-o1.o
>>> build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl06/dl06-o2.o
>>> build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl06/dl06-tar.o
>>> build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl06/init.o
>>> build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl06/dl-load.o
>>> build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl06/dl06-sym.o ->
>>> build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl06.exe
>>> 08:21:03 runner ['/build/rtems/6/bin/arm-rtems6-gcc', '-qnolinkcmds', '-T',
>>> 'linkcmds.realview_pbx_a9_qemu',
>>> '/home/EB/sebastian_h/git-rtems-6/build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl06/dl06-o1.o',
>>>
>>> '/home/EB/sebastian_h/git-rtems-6/build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl06/dl06-o2.o',
>>>
>> These should not be linked into the base image. They are in the RAP image in
>> dl06-tar.o.
> What shouldn't be linked in? The entire object files or only some functions 
> in it?

In this test dl06-o1.o and dl06-o2.o.

In general any code placed in the tar file to be dynamically load. Linking the
code to be loaded into the base image potentinally breaks the test.

>>> '/home/EB/sebastian_h/git-rtems-6/build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl06/dl06-tar.o',
>>>
>>> '/home/EB/sebastian_h/git-rtems-6/build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl06/init.o',
>>>
>>> '/home/EB/sebastian_h/git-rtems-6/build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl06/dl-load.o',
>>>
>>> '/home/EB/sebastian_h/git-rtems-6/build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl06/dl06-sym.o',
>>>
>>> '-o/home/EB/sebastian_h/git-rtems-6/build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl06.exe',
>>>
>>> '-Wl,--wrap=printf', '-Wl,--wrap=puts', '-L.', '-lrtemscpu', '-lrtemsbsp',
>>> '-lrtemstest', '-qrtems', '-march=armv7-a', '-mthumb', '-mfpu=neon',
>>> '-mfloat-abi=hard', '-mtune=cortex-a9',
>>> '-L/home/EB/sebastian_h/git-rtems-6/bsps/arm/shared/start',
>>> '-L/home/EB/sebastian_h/git-rtems-6/bsps/arm/realview-pbx-a9/start']
>>> /build/rtems/6/lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld:
>>> /home/EB/sebastian_h/git-rtems-6/build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl06/dl06-o2.o:
>>>
>>> in function `dl_o2_func2':
>>> /home/EB/sebastian_h/git-rtems-6/testsuites/libtests/dl06/dl06-o2.c:31:
>>> undefined reference to `atan2'
>>> /build/rtems/6/lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld:
>>> /home/EB/sebastian_h/git-rtems-6/build/arm/realview_pbx_a9_qemu/testsuites/libtests/dl06/dl06-o2.o:
>>>
>>> in function `dl_o2_func3':
>>>
>>> /home/EB/sebastian_h/git-rtems-6/testsuites/libtests/dl06/dl06-o2.c:37:
>>> undefined reference to `tan'
>>>
>>> I used the following config.ini:
>>>
>>> [arm/realview_pbx_a9_qemu]
>>> BUILD_LIBTESTS = True
>>> OPTIMIZATION_FLAGS = -O0 -g
>>> LDFLAGS =
>>>
 More of a concern is no error. I wonder if the code is being inlined when 
 there
 is FPU support. Maybe the test needs to create a library linking to it to 
 be
 more robust?
>>> Using these functions without -fno-builtin is not really robust.
>> Would adding a pragma for this option to dl06-o1.c and dl06-o2.c be 
>> acceptable
>> as a solution?
> I am not sure if a pragma works for these options. We can add -fno-builtin=tan
> -fno-builtin=atan2. We can use also some global volatile variables which seems
> to work for the math tests.

But only for dl

Re: Breaking Long Lines

2020-11-10 Thread Chris Johns 
On 10/11/20 6:38 pm, Thomas Doerfler wrote:
> Hi,
> 
> Am 10.11.20 um 06:33 schrieb Chris Johns:
>> On 9/11/20 5:50 pm, Sebastian Huber wrote:
>>> On 09/11/2020 01:52, Chris Johns wrote:
>>>
 On 6/11/20 7:11 pm, Sebastian Huber wrote:
> ...

   Avoid excess parentheses. Learn the operator precedence. rules.
>>>
>>> Yes, and I think this is a good rule.
>>
>> I am not sure it is a good rule and workable. Using it to handle indents is 
>> an
>> example of it breaking down. The ability to control an indent is a long held
>> tradition and editors like Emacs are designed to handle it yet it is not 
>> clear
>> if it is OK under this rule.
>>
> 
> I tried not to jump in for more than 24 hours.

:)

> But now I want to drop in
> my opinion. What is the whole purpose of a style guide? Is it to have a
> nice looking code layout, neat an tidy like a ideal front garden, or is
> it about readability/accessibility? We could write the whole of a C
> module into one line and it could work anyway, so what about a style guide?

We need something and I like what we have. It is a nice balance. I think some
parts of the guide deal with issues that appear over time. We also now have
better compiler checking these days, eg missing break statements, unused
variables, etc, and other things that safety people like such as always have
braces with nesting blocks.

> IMHO it should improve readability and understanding of what goes on in
> a certain module. The code should be readable and understandable not
> only for highly experienced C programmers, but also for newbies (if they
> tr Now back to paranthesis: Since we are very frugal with comments, we
> should at least make complex expressions easier to read by structuring
> them, where convenient, with parenthesis where it improves readability.

I agree.

> An alternative rule like "Learn the operator precedence" could lead to a
> similar sentence "Learn C block structure" to eliminate any code
> indentation rules, because these rules have the ONLY purpose to make the
> underlying code block structure easier to visualize and comprehend.

Yes I agree.

> So: my counter-rule would be "use paranthesis if you think it makes an
> expression easier to understand".

Nice. This is guide that does not paint itself into a corner.

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

Re: [PATCH 1/2] c-user: Generate Event Manager documentation

2020-11-10 Thread Chris Johns 
On 10/11/20 5:49 pm, Sebastian Huber wrote:
> Maybe we should remove the manual edit part entirely:
> 
> .. 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://docs.rtems.org/branches/master/user/support/bugs.html
> ..
> .. For information on updating and regenerating please refer to:
> ..
> .. https://docs.rtems.org/branches/master/eng/req/howto.html

Nice.

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

Re: [PATCH 00/11] Generate some header files

2020-11-10 Thread Chris Johns 
On 10/11/20 5:41 pm, Sebastian Huber wrote:
> On 10/11/2020 00:05, Chris Johns wrote:
> 
>> On 10/11/20 1:49 am, Sebastian Huber wrote:
>>> This patch set replaces some hand written header files of the Classic
>>> API with header files generated from specification items.  The main
>>> parts are the Event Manager and the Partition Manager.  The patches for
>>> the RTEMS Classic API Guide of these two managers is available here:
>>>
>>> https://lists.rtems.org/pipermail/devel/2020-November/063122.html
>>>
>>> I tried to follow the updated Doxygen guidelines:
>>>
>>> https://lists.rtems.org/pipermail/devel/2020-November/063119.html
>>>
>>> Sebastian Huber (11):
>>>    rtems: Include missing header file
>>>    rtems: Generate 
>>>    rtems: Generate 
>>>    rtems: Generate 
>>>    rtems: Generate 
>>>    rtems: Generate 
>>>    rtems: Generate 
>>>    rtems: Generate 
>>>    rtems: Generate 
>>>    rtems: Generate 
>>>    rtems: Generate 
>> Do these files need something that indicates they are generated and part of 
>> the
>> RTEMS Quality Process (RQP?)?
>>
>> I could not see anything.
> All the generated files have the standard header and the generated by comments
> or do you mean something else?

I was thinking of something like the recent change to the documentation source:

/*
 * This file is part of the RTEMS quality process and was automatically
 * generated. If you find something that needs to be fixed or changed
 * please post a report or patch to an RTEMS mailing list or raise a bug
 * report.
 */

I do not think we need the links as someone wanting to change an API header file
should know there are mailing lists and a bug reporting system.

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

Re: [PATCH 00/11] Generate some header files

2020-11-10 Thread Sebastian Huber 

On 11/11/2020 01:18, Chris Johns wrote:


On 10/11/20 5:41 pm, Sebastian Huber wrote:

On 10/11/2020 00:05, Chris Johns wrote:


On 10/11/20 1:49 am, Sebastian Huber wrote:

This patch set replaces some hand written header files of the Classic
API with header files generated from specification items.  The main
parts are the Event Manager and the Partition Manager.  The patches for
the RTEMS Classic API Guide of these two managers is available here:

https://lists.rtems.org/pipermail/devel/2020-November/063122.html

I tried to follow the updated Doxygen guidelines:

https://lists.rtems.org/pipermail/devel/2020-November/063119.html

Sebastian Huber (11):
    rtems: Include missing header file
    rtems: Generate 
    rtems: Generate 
    rtems: Generate 
    rtems: Generate 
    rtems: Generate 
    rtems: Generate 
    rtems: Generate 
    rtems: Generate 
    rtems: Generate 
    rtems: Generate 

Do these files need something that indicates they are generated and part of the
RTEMS Quality Process (RQP?)?

I could not see anything.

All the generated files have the standard header and the generated by comments
or do you mean something else?

I was thinking of something like the recent change to the documentation source:

/*
  * This file is part of the RTEMS quality process and was automatically
  * generated. If you find something that needs to be fixed or changed
  * please post a report or patch to an RTEMS mailing list or raise a bug
  * report.
  */

I do not think we need the links as someone wanting to change an API header file
should know there are mailing lists and a bug reporting system.
I would keep the links. It is not a lot of text. The header files 
contain the directive documentation which is also in the manuals. So, 
every user reviewing the API header file has a chance to fix typos, 
suggest a better wording, or otherwise improve the documentation.


--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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

[PATCH] Improve automatically generated warning

2020-11-10 Thread Sebastian Huber 
---
 c-user/config/bdbuf.rst | 9 -
 c-user/config/bsp-related.rst   | 9 -
 c-user/config/classic-api.rst   | 9 -
 c-user/config/classic-init-task.rst | 9 -
 c-user/config/device-driver.rst | 9 -
 c-user/config/event-record.rst  | 9 -
 c-user/config/filesystem.rst| 9 -
 c-user/config/general.rst   | 9 -
 c-user/config/idle-task.rst | 9 -
 c-user/config/mpci.rst  | 9 -
 c-user/config/posix-api.rst | 9 -
 c-user/config/posix-init-thread.rst | 9 -
 c-user/config/scheduler-general.rst | 9 -
 c-user/config/task-stack-alloc.rst  | 9 -
 c-user/io/directives.rst| 9 -
 c-user/io/introduction.rst  | 9 -
 eng/req/items.rst   | 9 -
 17 files changed, 68 insertions(+), 85 deletions(-)

diff --git a/c-user/config/bdbuf.rst b/c-user/config/bdbuf.rst
index e981f54..06399e0 100644
--- a/c-user/config/bdbuf.rst
+++ b/c-user/config/bdbuf.rst
@@ -3,11 +3,10 @@
 .. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
-.. Do not manually edit this file.  It 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 to an RTEMS mailing list or raise a bug report:
+.. 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://docs.rtems.org/branches/master/user/support/bugs.html
 ..
diff --git a/c-user/config/bsp-related.rst b/c-user/config/bsp-related.rst
index 71bcd58..3d0a3ca 100644
--- a/c-user/config/bsp-related.rst
+++ b/c-user/config/bsp-related.rst
@@ -3,11 +3,10 @@
 .. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
-.. Do not manually edit this file.  It 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 to an RTEMS mailing list or raise a bug report:
+.. 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://docs.rtems.org/branches/master/user/support/bugs.html
 ..
diff --git a/c-user/config/classic-api.rst b/c-user/config/classic-api.rst
index 90aec72..e44716a 100644
--- a/c-user/config/classic-api.rst
+++ b/c-user/config/classic-api.rst
@@ -3,11 +3,10 @@
 .. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
-.. Do not manually edit this file.  It 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 to an RTEMS mailing list or raise a bug report:
+.. 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://docs.rtems.org/branches/master/user/support/bugs.html
 ..
diff --git a/c-user/config/classic-init-task.rst 
b/c-user/config/classic-init-task.rst
index 64a8f9f..4d3bf81 100644
--- a/c-user/config/classic-init-task.rst
+++ b/c-user/config/classic-init-task.rst
@@ -3,11 +3,10 @@
 .. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
-.. Do not manually edit this file.  It 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 to an RTEMS mailing list or raise a bug report:
+.. 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://docs.rtems.org/branches/master/user/support/bugs.html
 ..
diff --git a/c-user/config/device-driver.rst b/c-user/config/device-driver.rst
index 8915b0b..4fd8c71 100644
--- a/c-user/config/device-driver.rst
+++ b/c-user/config/device-driver.rst
@@ -3,11 +3,10 @@
 .. Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
 .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation (OAR)
 
-.. Do not manually edit this file.  It is

[PATCH] Improve automatically generated warning

2020-11-10 Thread Sebastian Huber 
---
 cpukit/doxygen/appl-config.h| 9 -
 cpukit/include/rtems.h  | 9 -
 cpukit/include/rtems/io.h   | 9 -
 testsuites/validation/tc-message-construct-errors.c | 9 -
 testsuites/validation/tc-task-construct-errors.c| 9 -
 testsuites/validation/ts-validation-0.c | 9 -
 6 files changed, 24 insertions(+), 30 deletions(-)

diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index fe567b6e0f..00230ac2d6 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -28,11 +28,10 @@
  */
 
 /*
- * Do not manually edit this file.  It 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 to an RTEMS mailing list or raise a bug report:
+ * 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://docs.rtems.org/branches/master/user/support/bugs.html
  *
diff --git a/cpukit/include/rtems.h b/cpukit/include/rtems.h
index 9b0765efda..d1b1452000 100644
--- a/cpukit/include/rtems.h
+++ b/cpukit/include/rtems.h
@@ -35,11 +35,10 @@
  */
 
 /*
- * Do not manually edit this file.  It 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 to an RTEMS mailing list or raise a bug report:
+ * 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://docs.rtems.org/branches/master/user/support/bugs.html
  *
diff --git a/cpukit/include/rtems/io.h b/cpukit/include/rtems/io.h
index bfbad457c4..92ffb6d51b 100644
--- a/cpukit/include/rtems/io.h
+++ b/cpukit/include/rtems/io.h
@@ -35,11 +35,10 @@
  */
 
 /*
- * Do not manually edit this file.  It 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 to an RTEMS mailing list or raise a bug report:
+ * 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://docs.rtems.org/branches/master/user/support/bugs.html
  *
diff --git a/testsuites/validation/tc-message-construct-errors.c 
b/testsuites/validation/tc-message-construct-errors.c
index 2493600312..d71e427b63 100644
--- a/testsuites/validation/tc-message-construct-errors.c
+++ b/testsuites/validation/tc-message-construct-errors.c
@@ -32,11 +32,10 @@
  */
 
 /*
- * Do not manually edit this file.  It 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 to an RTEMS mailing list or raise a bug report:
+ * 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://docs.rtems.org/branches/master/user/support/bugs.html
  *
diff --git a/testsuites/validation/tc-task-construct-errors.c 
b/testsuites/validation/tc-task-construct-errors.c
index 37873ba7d6..4dfd12dbb8 100644
--- a/testsuites/validation/tc-task-construct-errors.c
+++ b/testsuites/validation/tc-task-construct-errors.c
@@ -32,11 +32,10 @@
  */
 
 /*
- * Do not manually edit this file.  It 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 to an RTEMS mailing list or raise a bug report:
+ * 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://docs.rtems.org/branches/master/user/support/bugs.html
  *
diff --git a/testsuites/validation/ts-validation-0.c 
b/testsuites/validation/ts-validation-0.c
index baaa679c05..801023e249 100644
--- a/testsuites/validation/ts-validation-0.c
+++ b/testsuites/validation/ts-validation-0.c
@@ -32,11 +32,10 @@
  */
 
 /*
- * Do not manually edit this file.  It 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 to an RTEMS mailing list or raise a bug report:

Re: [PATCH] libtests/dl06: Add -lm

2020-11-10 Thread Sebastian Huber 

On 11/11/2020 00:58, Chris Johns wrote:


These should not be linked into the base image. They are in the RAP image in
dl06-tar.o.

What shouldn't be linked in? The entire object files or only some functions in 
it?

In this test dl06-o1.o and dl06-o2.o.

In general any code placed in the tar file to be dynamically load. Linking the
code to be loaded into the base image potentinally breaks the test.
Thanks for the explanation. I think I found no the real bug in the build 
specification. I will send a new patch.


--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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

[PATCH] dl06: Do not include loaded objs in base image

2020-11-10 Thread Sebastian Huber 
---
 spec/build/testsuites/libtests/dl06.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/spec/build/testsuites/libtests/dl06.yml 
b/spec/build/testsuites/libtests/dl06.yml
index 2f5d4ab08d..c5f1de49ad 100644
--- a/spec/build/testsuites/libtests/dl06.yml
+++ b/spec/build/testsuites/libtests/dl06.yml
@@ -24,6 +24,7 @@ do-build: |
   tar = path + "dl06.tar"
   self.tar(bld, dl06_rap, [path], tar)
   tar_c, tar_h = self.bin2c(bld, tar)
+  objs = []
   objs.append(self.cc(bld, bic, tar_c))
   objs.append(self.cc(bld, bic, path + "init.c", deps=[tar_h], 
cppflags=bld.env.TEST_DL06_CPPFLAGS))
   objs.append(dl_load_o)
-- 
2.26.2

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

Re: [PATCH] libtests/dl06: Add -lm

2020-11-10 Thread Sebastian Huber 

On 10/11/2020 08:32, Sebastian Huber wrote:

Would adding a pragma for this option to dl06-o1.c and dl06-o2.c be 
acceptable

as a solution?
I am not sure if a pragma works for these options. We can add 
-fno-builtin=tan -fno-builtin=atan2. We can use also some global 
volatile variables which seems to work for the math tests. 
I had a look at the test. We only need the -fno-builtin if we enable 
link time optimization.


--
embedded brains GmbH
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
PGP: Public key available on request.

embedded brains GmbH
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