Re: RTEMS 5 RC1 Available

2020-06-28 Thread junkes 

Hello, Chris,
thank you very much for this first release candidate. I have 
successfully

installed it on a Mac with Catalina (10.15.5) for a BeagleboneBlack.
I was also able to create EPICS 7 with it and run it on the board.
This is really a great job you have done.

Heinz



On 2020-06-26 08:16, Chris Johns wrote:

Hello,

RTEMS 5 RC1 is available for testing. You can find the release at:

 https://ftp.rtems.org/pub/rtems/releases/5/rc/5.1.0-rc1

Please report your successes or problems here. You can also raise a
ticket if you prefer. Please select the 5.1 milestone.

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

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

Re: RTEMS 5 has branch

2020-06-28 Thread Chris Johns 

On 27/6/20 4:20 am, Sebastian Huber wrote:

On 26/06/2020 07:18, Chris Johns wrote:

If a patch is pushed to any of the release repos that changes a 
version number there needs to be a patch for the engineering manual 
that documents the change. I would like to collection all the changes 
that need to be made post branching. I am currently working on 
updating the release procedure section to provide a suitable location 
for these additions. 


Is there already a script to change the version? If not, should we add one?



There is no script. I think there should be time. At this point in time 
I was wanting to document that we have to do.


One option would be to add it to the rtems-qual repository and use these 
three items as the master data:


https://git.rtems.org/sebh/rtems.git/tree/spec/build/cpukit/optvermaj.yml?h=build 



https://git.rtems.org/sebh/rtems.git/tree/spec/build/cpukit/optvermin.yml?h=build 



https://git.rtems.org/sebh/rtems.git/tree/spec/build/cpukit/optverrev.yml?h=build 



All the release repositories need to be added added as submodules (RSB, 
rtems, rtems-docs) is already there.




I think this is a good idea and supports the kind of direction I see the 
central repo heading. The sooner we have it's name changed and moved to 
the top level the better.


Also I am coming to the view the release scripts needs to be transformed 
into python. The complexity needed is pushing the easy of maintenance.


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

Re: RTEMS 6

2020-06-28 Thread Chris Johns 

On 28/6/20 7:34 am, Joel Sherrill wrote:
On Fri, Jun 26, 2020, 1:11 PM Sebastian Huber 
> wrote:

in the rtems-release repository we have a rtems-notes-5.txt file.
Should
I already add an rtems-notes-6.txt so that we can build up this file
already during the development cycle?

A human written record will be better than hundreds of tickets. 
Summarised and more useful.


Please add rtems-notes-6.txt.

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

Re: RTEMS 5 has branch

2020-06-28 Thread Sebastian Huber 

On 29/06/2020 06:56, Chris Johns wrote:


On 27/6/20 4:20 am, Sebastian Huber wrote:

On 26/06/2020 07:18, Chris Johns wrote:

If a patch is pushed to any of the release repos that changes a 
version number there needs to be a patch for the engineering manual 
that documents the change. I would like to collection all the 
changes that need to be made post branching. I am currently working 
on updating the release procedure section to provide a suitable 
location for these additions. 


Is there already a script to change the version? If not, should we 
add one?




There is no script. I think there should be time. At this point in 
time I was wanting to document that we have to do.

Ok, lets start with the documentation and then we can add a script later.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 6

2020-06-28 Thread Sebastian Huber 

On 27/06/2020 23:34, Joel Sherrill wrote:



Should I prepare a GCC 10 based RTEMS 6 tool chain now? This will
require a couple of GCC machine option changes for powerpc and arm.


Are you killing spe BSPs?


Yes and powerpc/virtex (not powerpc/virtex5):

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

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



Should we remove the obsolete architectures and BSPs before or
after the
build system integration?


Epiphany is the only architecture I know that had taken to tier 4 and 
removal discussed. What else do you have in mind and why?


Only epiphany and powerpcspe.

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

Some cleanup of m32c:

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

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

[PATCH] smpstrongapa01: Improve readability

2020-06-28 Thread Richi Dubey 
---
 testsuites/smptests/smpstrongapa01/init.c | 60 ++-
 1 file changed, 38 insertions(+), 22 deletions(-)

diff --git a/testsuites/smptests/smpstrongapa01/init.c 
b/testsuites/smptests/smpstrongapa01/init.c
index bf8bc05231..d067f2b5b9 100644
--- a/testsuites/smptests/smpstrongapa01/init.c
+++ b/testsuites/smptests/smpstrongapa01/init.c
@@ -16,7 +16,7 @@
 #include "config.h"
 #endif
 
-#include "tmacros.h"
+#include 
 
 #include 
 
@@ -30,9 +30,22 @@ const char rtems_test_name[] = "SMPSTRONGAPA 1";
 
 #define ALL ((UINT32_C(1) << CPU_COUNT) - 1)
 
-#define IDLE UINT8_C(255)
+typedef enum {
+  T0,
+  T1,
+  T2,
+  T3,
+  T4,
+  T5,
+  T6,
+  T7,
+  T8,
+  T9,
+  T10,
+  T11,
+  IDLE
+} task_index;
 
-#define NAME rtems_build_name('S', 'A', 'P', 'A')
 
 typedef struct {
   enum {
@@ -43,7 +56,7 @@ typedef struct {
 KIND_UNBLOCK
   } kind;
 
-  size_t index;
+  task_index index;
 
   struct {
 rtems_task_priority priority;
@@ -102,17 +115,17 @@ typedef struct {
 
 static const test_action test_actions[] = {
   RESET,
-  UNBLOCK(  0,   0, IDLE, IDLE, IDLE),
-  UNBLOCK(  1,   0,1, IDLE, IDLE),
-  UNBLOCK(  2,   0,1,2, IDLE),
-  UNBLOCK(  3,   0,1,2,3),
-  UNBLOCK(  5,   0,1,2,3),
-  SET_PRIORITY( 3,  P(4),0,1,2,3),
-  SET_PRIORITY( 5,  P(3),0,1,2,5),
-  BLOCK(5,   0,1,2,3),
-  SET_AFFINITY( 5,   ALL,0,1,2,3),
+  UNBLOCK(  T0,   T0,  IDLE,  IDLE,  IDLE),
+  UNBLOCK(  T1,   T0,T1,  IDLE,  IDLE),
+  UNBLOCK(  T2,   T0,T1,T2,  IDLE),
+  UNBLOCK(  T3,   T0,T1,T2,T3),
+  UNBLOCK(  T5,   T0,T1,T2,T3),
+  SET_PRIORITY( T3,  P(4),T0,T1,T2,T3),
+  SET_PRIORITY( T5,  P(3),T0,T1,T2,T5),
+  BLOCK(T5,   T0,T1,T2,T3),
+  SET_AFFINITY( T5,   ALL,T0,T1,T2,T3),
   RESET,
-  UNBLOCK(  0,   0, IDLE, IDLE, IDLE),
+  UNBLOCK(  T0,   T0, IDLE, IDLE, IDLE),
   RESET
 };
 
@@ -130,7 +143,7 @@ static void set_affinity(rtems_id id, uint32_t cpu_set_32)
 {
   rtems_status_code sc;
   cpu_set_t cpu_set;
-  size_t i;
+  task_index i;
 
   CPU_ZERO(&cpu_set);
 
@@ -147,7 +160,7 @@ static void set_affinity(rtems_id id, uint32_t cpu_set_32)
 static void reset(test_context *ctx)
 {
   rtems_status_code sc;
-  size_t i;
+  task_index i;
 
   for (i = CPU_COUNT; i < TASK_COUNT; ++i) {
 set_priority(ctx->task_ids[i], P(i));
@@ -179,10 +192,10 @@ static void reset(test_context *ctx)
 
 static void check_cpu_allocations(test_context *ctx, const test_action *action)
 {
-  size_t i;
+  task_index i;
 
   for (i = 0; i < CPU_COUNT; ++i) {
-size_t e;
+task_index e;
 const Per_CPU_Control *c;
 const Thread_Control *h;
 
@@ -206,7 +219,7 @@ static void timer(rtems_id id, void *arg)
 {
   test_context *ctx;
   rtems_status_code sc;
-  size_t i;
+  task_index i;
 
   ctx = arg;
   i = ctx->action_index;
@@ -271,7 +284,7 @@ static void test(void)
 {
   test_context *ctx;
   rtems_status_code sc;
-  size_t i;
+  task_index i;
 
   ctx = &test_instance;
 
@@ -279,7 +292,7 @@ static void test(void)
 
   for (i = 0; i < TASK_COUNT; ++i) {
 sc = rtems_task_create(
-  NAME,
+  rtems_build_name(' ', ' ', 'T', '0' + i),
   P(i),
   RTEMS_MINIMUM_STACK_SIZE,
   RTEMS_DEFAULT_MODES,
@@ -292,7 +305,10 @@ static void test(void)
 rtems_test_assert(sc == RTEMS_SUCCESSFUL);
   }
 
-  sc = rtems_timer_create(NAME, &ctx->timer_id);
+  sc = rtems_timer_create(
+  rtems_build_name('S', 'A', 'P', 'A'),
+   &ctx->timer_id
+   );
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 
   sc = rtems_timer_fire_after(ctx->timer_id, 1, timer, ctx);
-- 
2.17.1

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

Re: [PATCH] smpstrongapa01: Improve readability

2020-06-28 Thread Richi Dubey 
Hi,

This is the 3rd version of the patch. I realised that the previous version
had a syntax error after I ran 'make' on the testsuite.
Please review this patch.

Thanks,
Richi.

On Mon, Jun 29, 2020 at 11:47 AM Richi Dubey  wrote:

> ---
>  testsuites/smptests/smpstrongapa01/init.c | 60 ++-
>  1 file changed, 38 insertions(+), 22 deletions(-)
>
> diff --git a/testsuites/smptests/smpstrongapa01/init.c
> b/testsuites/smptests/smpstrongapa01/init.c
> index bf8bc05231..d067f2b5b9 100644
> --- a/testsuites/smptests/smpstrongapa01/init.c
> +++ b/testsuites/smptests/smpstrongapa01/init.c
> @@ -16,7 +16,7 @@
>  #include "config.h"
>  #endif
>
> -#include "tmacros.h"
> +#include 
>
>  #include 
>
> @@ -30,9 +30,22 @@ const char rtems_test_name[] = "SMPSTRONGAPA 1";
>
>  #define ALL ((UINT32_C(1) << CPU_COUNT) - 1)
>
> -#define IDLE UINT8_C(255)
> +typedef enum {
> +  T0,
> +  T1,
> +  T2,
> +  T3,
> +  T4,
> +  T5,
> +  T6,
> +  T7,
> +  T8,
> +  T9,
> +  T10,
> +  T11,
> +  IDLE
> +} task_index;
>
> -#define NAME rtems_build_name('S', 'A', 'P', 'A')
>
>  typedef struct {
>enum {
> @@ -43,7 +56,7 @@ typedef struct {
>  KIND_UNBLOCK
>} kind;
>
> -  size_t index;
> +  task_index index;
>
>struct {
>  rtems_task_priority priority;
> @@ -102,17 +115,17 @@ typedef struct {
>
>  static const test_action test_actions[] = {
>RESET,
> -  UNBLOCK(  0,   0, IDLE, IDLE, IDLE),
> -  UNBLOCK(  1,   0,1, IDLE, IDLE),
> -  UNBLOCK(  2,   0,1,2, IDLE),
> -  UNBLOCK(  3,   0,1,2,3),
> -  UNBLOCK(  5,   0,1,2,3),
> -  SET_PRIORITY( 3,  P(4),0,1,2,3),
> -  SET_PRIORITY( 5,  P(3),0,1,2,5),
> -  BLOCK(5,   0,1,2,3),
> -  SET_AFFINITY( 5,   ALL,0,1,2,3),
> +  UNBLOCK(  T0,   T0,  IDLE,  IDLE,  IDLE),
> +  UNBLOCK(  T1,   T0,T1,  IDLE,  IDLE),
> +  UNBLOCK(  T2,   T0,T1,T2,  IDLE),
> +  UNBLOCK(  T3,   T0,T1,T2,T3),
> +  UNBLOCK(  T5,   T0,T1,T2,T3),
> +  SET_PRIORITY( T3,  P(4),T0,T1,T2,T3),
> +  SET_PRIORITY( T5,  P(3),T0,T1,T2,T5),
> +  BLOCK(T5,   T0,T1,T2,T3),
> +  SET_AFFINITY( T5,   ALL,T0,T1,T2,T3),
>RESET,
> -  UNBLOCK(  0,   0, IDLE, IDLE, IDLE),
> +  UNBLOCK(  T0,   T0, IDLE, IDLE, IDLE),
>RESET
>  };
>
> @@ -130,7 +143,7 @@ static void set_affinity(rtems_id id, uint32_t
> cpu_set_32)
>  {
>rtems_status_code sc;
>cpu_set_t cpu_set;
> -  size_t i;
> +  task_index i;
>
>CPU_ZERO(&cpu_set);
>
> @@ -147,7 +160,7 @@ static void set_affinity(rtems_id id, uint32_t
> cpu_set_32)
>  static void reset(test_context *ctx)
>  {
>rtems_status_code sc;
> -  size_t i;
> +  task_index i;
>
>for (i = CPU_COUNT; i < TASK_COUNT; ++i) {
>  set_priority(ctx->task_ids[i], P(i));
> @@ -179,10 +192,10 @@ static void reset(test_context *ctx)
>
>  static void check_cpu_allocations(test_context *ctx, const test_action
> *action)
>  {
> -  size_t i;
> +  task_index i;
>
>for (i = 0; i < CPU_COUNT; ++i) {
> -size_t e;
> +task_index e;
>  const Per_CPU_Control *c;
>  const Thread_Control *h;
>
> @@ -206,7 +219,7 @@ static void timer(rtems_id id, void *arg)
>  {
>test_context *ctx;
>rtems_status_code sc;
> -  size_t i;
> +  task_index i;
>
>ctx = arg;
>i = ctx->action_index;
> @@ -271,7 +284,7 @@ static void test(void)
>  {
>test_context *ctx;
>rtems_status_code sc;
> -  size_t i;
> +  task_index i;
>
>ctx = &test_instance;
>
> @@ -279,7 +292,7 @@ static void test(void)
>
>for (i = 0; i < TASK_COUNT; ++i) {
>  sc = rtems_task_create(
> -  NAME,
> +  rtems_build_name(' ', ' ', 'T', '0' + i),
>P(i),
>RTEMS_MINIMUM_STACK_SIZE,
>RTEMS_DEFAULT_MODES,
> @@ -292,7 +305,10 @@ static void test(void)
>  rtems_test_assert(sc == RTEMS_SUCCESSFUL);
>}
>
> -  sc = rtems_timer_create(NAME, &ctx->timer_id);
> +  sc = rtems_timer_create(
> +  rtems_build_name('S', 'A', 'P', 'A'),
> +   &ctx->timer_id
> +   );
>rtems_test_assert(sc == RTEMS_SUCCESSFUL);
>
>sc = rtems_timer_fire_after(ctx->timer_id, 1, timer, ctx);
> --
> 2.17.1
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel