[PATCH] score: Disable thread dispatching earlier

[Sebastian Huber]

Disable thread dispatching earlier on secondary processors.  This ensures that
fatal error and per-CPU job handlers are called with thread dispatching
disabled.  On the boot processor, the thread dispatching is already disabled by
_Thread_Dispatch_initialization().
---
 cpukit/score/src/smp.c | 6 ++
 cpukit/score/src/threadstartmultitasking.c | 6 --
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/cpukit/score/src/smp.c b/cpukit/score/src/smp.c
index 125c54e1ba..0dc8830c46 100644
--- a/cpukit/score/src/smp.c
+++ b/cpukit/score/src/smp.c
@@ -253,6 +253,12 @@ void _SMP_Start_multitasking_on_secondary_processor(
 
   cpu_index_self = _Per_CPU_Get_index( cpu_self );
 
+  /*
+   * Call fatal error and per-CPU job handlers with thread dispatching
+   * disabled.
+   */
+  cpu_self->thread_dispatch_disable_level = 1;
+
   if ( cpu_index_self >= rtems_configuration_get_maximum_processors() ) {
 _SMP_Fatal( SMP_FATAL_MULTITASKING_START_ON_INVALID_PROCESSOR );
   }
diff --git a/cpukit/score/src/threadstartmultitasking.c 
b/cpukit/score/src/threadstartmultitasking.c
index 76187efe80..5cc2051be4 100644
--- a/cpukit/score/src/threadstartmultitasking.c
+++ b/cpukit/score/src/threadstartmultitasking.c
@@ -51,12 +51,6 @@ void _Thread_Start_multitasking( void )
 #if defined(RTEMS_SMP)
   _Per_CPU_Set_state( cpu_self, PER_CPU_STATE_UP );
   _SMP_Try_to_process_message( cpu_self, SMP_MESSAGE_FORCE_PROCESSING );
-
-  /*
-   * Threads begin execution in the _Thread_Handler() function.   This
-   * function will set the thread dispatch disable level to zero.
-   */
-  cpu_self->thread_dispatch_disable_level = 1;
 #endif
 
   heir = _Thread_Get_heir_and_make_it_executing( cpu_self );
-- 
2.34.1

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

Re: [PATCH 1/2] cpukit/aarch64: Keep state across context switch

[Sebastian Huber]

On 28/02/2022 20:18, Kinsey Moore wrote:


On 2/28/2022 12:19, Sebastian Huber wrote:

On 26/02/2022 08:03, Kinsey Moore wrote:

On 2/26/2022 00:53, Sebastian Huber wrote:

On 26/02/2022 00:41, Kinsey Moore wrote:
This may also be an issue for ARM, RISC-V and others as it doesn't 
appear that ARM saves CPSR during context switch and I couldn't 
tell that RISC-V does this either, though I'm less familiar with it.


This doesn't look like the right way to fix this issue.

There is currently the assumption that all processors start 
multitasking with a context switch to _Thread_Handler() which sets 
the interrupt level. It is possible to construct a scenario in which 
we start multitasking with a migration of a thread which already 
executed the _Thread_Handler() prologue. This would result in an 
execution with disabled interrupts. I think the proper fix for this 
scenario is to enable interrupts in 
_CPU_SMP_Prepare_start_multitasking().


Doing a context switch with interrupts disabled is a fatal 
application error on all architectures with


#define CPU_ENABLE_ROBUST_THREAD_DISPATCH TRUE

or enabled SMP support.

Ok, great. I was wondering if that was the case and this is 
definitely the kind of feedback I was looking for. I'll adjust the 
patch set to reflect that. I still wonder if this is an issue on 
other SMP CPU ports, though, since most of them don't implement that 
hook, either.


I would like to have a closer look at this next week then I am back 
from holidays.


Enabling interrupts in _CPU_SMP_Prepare_start_multitasking() would not 
work since we use the interrupt stack at this point. We should add a 
ticket and a test case for this (I can do this next week). How did you 
observe this bug?


I was only able to observe this bug once the 2/2 patch is applied and 
that optimization opens a race condition (adding a few no-ops to the 
Per_CPU_Control accessor prevents it from appearing) in the 
sppercpudata01 test on SMP configurations since the task is migrating 
across CPUs as CPUs are coming online. The race condition resolves 
nominally in 90% of cases so while it's not a frequent failure it is 
reproducible.


I added a ticket and a test case:

http://devel.rtems.org/ticket/4627

Could you please check if the test case fails currently on your aarch64 
target?


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [GSoC-Entry PATCH] RTEMS port for Raspberry pi 4 AArch64

[Gedare Bloom]

Hi Mohd Noor Aman,

Got it, thanks.

Hopefully you can entice a mentor to express interest in the port :)
That always helps. We'll get proposal preparation started in earnest
soon.

Gedare

On Mon, Mar 7, 2022 at 9:28 PM Noor Aman  wrote:
>
> Hello, This is my patch for qualifying the RTEMS GSoC program. I have
> attached a screenshot to show the running modified hello world. I have
> created an entry in the GSoC 2022 page too.
>
>
> diff --git a/testsuites/samples/hello/init.c
> b/testsuites/samples/hello/init.c
> index 34ded37c55..5e2ec70adc 100644
> --- a/testsuites/samples/hello/init.c
> +++ b/testsuites/samples/hello/init.c
> @@ -22,7 +22,7 @@ static rtems_task Init(
>  {
>rtems_print_printer_fprintf_putc(&rtems_test_printer);
>TEST_BEGIN();
> -  printf( "Hello World\n" );
> +  printf( "Hello World from Mohd Noor Aman AKA katana-flinger\n" );
>TEST_END();
>rtems_test_exit( 0 );
>  }
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score: Disable thread dispatching earlier

[Gedare Bloom]

looks ok to me

On Tue, Mar 8, 2022 at 1:50 AM Sebastian Huber
 wrote:
>
> Disable thread dispatching earlier on secondary processors.  This ensures that
> fatal error and per-CPU job handlers are called with thread dispatching
> disabled.  On the boot processor, the thread dispatching is already disabled 
> by
> _Thread_Dispatch_initialization().
> ---
>  cpukit/score/src/smp.c | 6 ++
>  cpukit/score/src/threadstartmultitasking.c | 6 --
>  2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/cpukit/score/src/smp.c b/cpukit/score/src/smp.c
> index 125c54e1ba..0dc8830c46 100644
> --- a/cpukit/score/src/smp.c
> +++ b/cpukit/score/src/smp.c
> @@ -253,6 +253,12 @@ void _SMP_Start_multitasking_on_secondary_processor(
>
>cpu_index_self = _Per_CPU_Get_index( cpu_self );
>
> +  /*
> +   * Call fatal error and per-CPU job handlers with thread dispatching
> +   * disabled.
> +   */
> +  cpu_self->thread_dispatch_disable_level = 1;
> +
>if ( cpu_index_self >= rtems_configuration_get_maximum_processors() ) {
>  _SMP_Fatal( SMP_FATAL_MULTITASKING_START_ON_INVALID_PROCESSOR );
>}
> diff --git a/cpukit/score/src/threadstartmultitasking.c 
> b/cpukit/score/src/threadstartmultitasking.c
> index 76187efe80..5cc2051be4 100644
> --- a/cpukit/score/src/threadstartmultitasking.c
> +++ b/cpukit/score/src/threadstartmultitasking.c
> @@ -51,12 +51,6 @@ void _Thread_Start_multitasking( void )
>  #if defined(RTEMS_SMP)
>_Per_CPU_Set_state( cpu_self, PER_CPU_STATE_UP );
>_SMP_Try_to_process_message( cpu_self, SMP_MESSAGE_FORCE_PROCESSING );
> -
> -  /*
> -   * Threads begin execution in the _Thread_Handler() function.   This
> -   * function will set the thread dispatch disable level to zero.
> -   */
> -  cpu_self->thread_dispatch_disable_level = 1;
>  #endif
>
>heir = _Thread_Get_heir_and_make_it_executing( cpu_self );
> --
> 2.34.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] mpci: Simplify expressions

[Gedare Bloom]

On Mon, Mar 7, 2022 at 11:52 PM Sebastian Huber
 wrote:
>
> Use that rtems_configuration_get_user_multiprocessing_table() returns never
> NULL if RTEMS_MULTIPROCESSING defined.
> ---
>  bsps/m68k/mvme147s/start/bspstart.c |  2 +-
>  bsps/riscv/griscv/include/amba.h|  3 +--
>  bsps/sparc/leon3/btimer/btimer.c|  5 ++---
>  bsps/sparc/leon3/include/leon.h |  3 +--
>  cpukit/libmisc/monitor/mon-editor.c |  6 --
>  cpukit/libmisc/stackchk/check.c | 10 --
>  6 files changed, 9 insertions(+), 20 deletions(-)
>
> diff --git a/bsps/m68k/mvme147s/start/bspstart.c 
> b/bsps/m68k/mvme147s/start/bspstart.c
> index 497b644150..e5eb48f108 100644
> --- a/bsps/m68k/mvme147s/start/bspstart.c
> +++ b/bsps/m68k/mvme147s/start/bspstart.c
> @@ -58,7 +58,7 @@ void bsp_start( void )
>
>  #if defined(RTEMS_MULTIPROCESSING)
>node_number = (uint8_t)
> -(rtems_configuration_get_user_multiprocessing_table()->node - 1) & 0xF;
> +rtems_configuration_get_user_multiprocessing_table()->node - 1;

node is never 0?

>  #else
> node_number = 1;
>  #endif
> diff --git a/bsps/riscv/griscv/include/amba.h 
> b/bsps/riscv/griscv/include/amba.h
> index 292660d5c1..b615389df4 100644
> --- a/bsps/riscv/griscv/include/amba.h
> +++ b/bsps/riscv/griscv/include/amba.h
> @@ -46,8 +46,7 @@
>  #define GRLIB_APB_SLAVES 16
>
>  #if defined(RTEMS_MULTIPROCESSING)
> -  #define GRLIB_CLOCK_INDEX \
> -   (rtems_configuration_get_user_multiprocessing_table() ? GRLIB_Cpu_Index : 
> 0)
> +  #define GRLIB_CLOCK_INDEX GRLIB_Cpu_Index
>  #else
>#define GRLIB_CLOCK_INDEX 0
>  #endif
> diff --git a/bsps/sparc/leon3/btimer/btimer.c 
> b/bsps/sparc/leon3/btimer/btimer.c
> index 9e9f2b02fc..03bbfe06e7 100644
> --- a/bsps/sparc/leon3/btimer/btimer.c
> +++ b/bsps/sparc/leon3/btimer/btimer.c
> @@ -23,10 +23,9 @@
>
>  #if defined(RTEMS_MULTIPROCESSING)
>#define LEON3_TIMER_INDEX \
> -  ((rtems_configuration_get_user_multiprocessing_table()) ? \
> -(rtems_configuration_get_user_multiprocessing_table()->node) - 1 : 1)
> +(rtems_configuration_get_user_multiprocessing_table()->node)

This is not the same value, but

>  #else
> -  #define LEON3_TIMER_INDEX 0
> +  #define LEON3_TIMER_INDEX 1

I guess this corrects the off-by-1?

>  #endif
>
>  bool benchmark_timer_find_average_overhead;
> diff --git a/bsps/sparc/leon3/include/leon.h b/bsps/sparc/leon3/include/leon.h
> index 5fadb08052..e03185f927 100644
> --- a/bsps/sparc/leon3/include/leon.h
> +++ b/bsps/sparc/leon3/include/leon.h
> @@ -325,8 +325,7 @@ extern rtems_interrupt_lock LEON3_IrqCtrl_Lock;
>  #define LEON_REG_TIMER_COUNTER_CURRENT_MODE_MASK  0x0003
>
>  #if defined(RTEMS_MULTIPROCESSING)
> -  #define LEON3_CLOCK_INDEX \
> -   (rtems_configuration_get_user_multiprocessing_table() ? LEON3_Cpu_Index : 
> 0)
> +  #define LEON3_CLOCK_INDEX LEON3_Cpu_Index
>  #else
>#define LEON3_CLOCK_INDEX 0
>  #endif
> diff --git a/cpukit/libmisc/monitor/mon-editor.c 
> b/cpukit/libmisc/monitor/mon-editor.c
> index 6957fee9c8..bea0fc28ba 100644
> --- a/cpukit/libmisc/monitor/mon-editor.c
> +++ b/cpukit/libmisc/monitor/mon-editor.c
> @@ -499,12 +499,6 @@ rtems_monitor_command_read(char *command,
>/*
> * put node number in the prompt if we are multiprocessing
> */
> -#if defined(RTEMS_MULTIPROCESSING)
> -  if (!rtems_configuration_get_user_multiprocessing_table ())
> -snprintf (monitor_prompt, sizeof(monitor_prompt), "%s",
> - (env_prompt == NULL) ? MONITOR_PROMPT: env_prompt);
> -  else /*  */
> -#endif
>if (rtems_monitor_default_node != rtems_monitor_node)
>  snprintf (monitor_prompt, sizeof(monitor_prompt),
>"%" PRId32 "-%s-%" PRId32 "", rtems_monitor_node,
> diff --git a/cpukit/libmisc/stackchk/check.c b/cpukit/libmisc/stackchk/check.c
> index fa0c3ea1ed..437a0476c3 100644
> --- a/cpukit/libmisc/stackchk/check.c
> +++ b/cpukit/libmisc/stackchk/check.c
> @@ -278,12 +278,10 @@ static void Stack_check_report_blown_task(
>}
>
>#if defined(RTEMS_MULTIPROCESSING)
> -if (rtems_configuration_get_user_multiprocessing_table()) {
> -  printk(
> -"node: 0x%08" PRIxPTR "\n",
> -  (intptr_t) 
> rtems_configuration_get_user_multiprocessing_table()->node
> -  );
> -}
> +printk(
> +  "node: 0x%08" PRIxPTR "\n",
> +(intptr_t) rtems_configuration_get_user_multiprocessing_table()->node
> +);
>#endif
>
>rtems_fatal(
> --
> 2.34.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] mpci: Simplify expressions

[Sebastian Huber]

On 08/03/2022 14:56, Gedare Bloom wrote:

On Mon, Mar 7, 2022 at 11:52 PM Sebastian Huber
  wrote:

Use that rtems_configuration_get_user_multiprocessing_table() returns never
NULL if RTEMS_MULTIPROCESSING defined.
---
  bsps/m68k/mvme147s/start/bspstart.c |  2 +-
  bsps/riscv/griscv/include/amba.h|  3 +--
  bsps/sparc/leon3/btimer/btimer.c|  5 ++---
  bsps/sparc/leon3/include/leon.h |  3 +--
  cpukit/libmisc/monitor/mon-editor.c |  6 --
  cpukit/libmisc/stackchk/check.c | 10 --
  6 files changed, 9 insertions(+), 20 deletions(-)

diff --git a/bsps/m68k/mvme147s/start/bspstart.c 
b/bsps/m68k/mvme147s/start/bspstart.c
index 497b644150..e5eb48f108 100644
--- a/bsps/m68k/mvme147s/start/bspstart.c
+++ b/bsps/m68k/mvme147s/start/bspstart.c
@@ -58,7 +58,7 @@ void bsp_start( void )

  #if defined(RTEMS_MULTIPROCESSING)
node_number = (uint8_t)
-(rtems_configuration_get_user_multiprocessing_table()->node - 1) & 0xF;
+rtems_configuration_get_user_multiprocessing_table()->node - 1;

node is never 0?


This would be a configuration error which is checked by:

#if CONFIGURE_MP_NODE_NUMBER < 1
  #error "CONFIGURE_MP_NODE_NUMBER must be greater than or equal to one"
#endif

#if CONFIGURE_MP_NODE_NUMBER > CONFIGURE_MP_MAXIMUM_NODES
  #error "CONFIGURE_MP_NODE_NUMBER must be less than or equal to 
CONFIGURE_MP_MAXIMUM_NODES"

#endif




  #else
 node_number = 1;
  #endif
diff --git a/bsps/riscv/griscv/include/amba.h b/bsps/riscv/griscv/include/amba.h
index 292660d5c1..b615389df4 100644
--- a/bsps/riscv/griscv/include/amba.h
+++ b/bsps/riscv/griscv/include/amba.h
@@ -46,8 +46,7 @@
  #define GRLIB_APB_SLAVES 16

  #if defined(RTEMS_MULTIPROCESSING)
-  #define GRLIB_CLOCK_INDEX \
-   (rtems_configuration_get_user_multiprocessing_table() ? GRLIB_Cpu_Index : 0)
+  #define GRLIB_CLOCK_INDEX GRLIB_Cpu_Index
  #else
#define GRLIB_CLOCK_INDEX 0
  #endif
diff --git a/bsps/sparc/leon3/btimer/btimer.c b/bsps/sparc/leon3/btimer/btimer.c
index 9e9f2b02fc..03bbfe06e7 100644
--- a/bsps/sparc/leon3/btimer/btimer.c
+++ b/bsps/sparc/leon3/btimer/btimer.c
@@ -23,10 +23,9 @@

  #if defined(RTEMS_MULTIPROCESSING)
#define LEON3_TIMER_INDEX \
-  ((rtems_configuration_get_user_multiprocessing_table()) ? \
-(rtems_configuration_get_user_multiprocessing_table()->node) - 1 : 1)
+(rtems_configuration_get_user_multiprocessing_table()->node)

This is not the same value, but


  #else
-  #define LEON3_TIMER_INDEX 0
+  #define LEON3_TIMER_INDEX 1

I guess this corrects the off-by-1?


Sorry, this should be probably an extra patch. See remark in:

https://lists.rtems.org/pipermail/devel/2022-March/070744.html

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] cpukit/aarch64: Keep state across context switch

[Kinsey Moore]

On 3/8/2022 02:52, Sebastian Huber wrote:

On 28/02/2022 20:18, Kinsey Moore wrote:


On 2/28/2022 12:19, Sebastian Huber wrote:

On 26/02/2022 08:03, Kinsey Moore wrote:

On 2/26/2022 00:53, Sebastian Huber wrote:

On 26/02/2022 00:41, Kinsey Moore wrote:
This may also be an issue for ARM, RISC-V and others as it 
doesn't appear that ARM saves CPSR during context switch and I 
couldn't tell that RISC-V does this either, though I'm less 
familiar with it.


This doesn't look like the right way to fix this issue.

There is currently the assumption that all processors start 
multitasking with a context switch to _Thread_Handler() which sets 
the interrupt level. It is possible to construct a scenario in 
which we start multitasking with a migration of a thread which 
already executed the _Thread_Handler() prologue. This would result 
in an execution with disabled interrupts. I think the proper fix 
for this scenario is to enable interrupts in 
_CPU_SMP_Prepare_start_multitasking().


Doing a context switch with interrupts disabled is a fatal 
application error on all architectures with


#define CPU_ENABLE_ROBUST_THREAD_DISPATCH TRUE

or enabled SMP support.

Ok, great. I was wondering if that was the case and this is 
definitely the kind of feedback I was looking for. I'll adjust the 
patch set to reflect that. I still wonder if this is an issue on 
other SMP CPU ports, though, since most of them don't implement 
that hook, either.


I would like to have a closer look at this next week then I am back 
from holidays.


Enabling interrupts in _CPU_SMP_Prepare_start_multitasking() would 
not work since we use the interrupt stack at this point. We should 
add a ticket and a test case for this (I can do this next week). How 
did you observe this bug?


I was only able to observe this bug once the 2/2 patch is applied and 
that optimization opens a race condition (adding a few no-ops to the 
Per_CPU_Control accessor prevents it from appearing) in the 
sppercpudata01 test on SMP configurations since the task is migrating 
across CPUs as CPUs are coming online. The race condition resolves 
nominally in 90% of cases so while it's not a frequent failure it is 
reproducible.


I added a ticket and a test case:

http://devel.rtems.org/ticket/4627

Could you please check if the test case fails currently on your 
aarch64 target?


I have verified that this test case fails under QEMU and on the hardware 
target.


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

Re: Warnings when building sparc/leon3

[Joel Sherrill]

On Tue, Mar 8, 2022 at 12:45 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 07/03/2022 19:19, Joel Sherrill wrote:
> >
> >
> > On Mon, Mar 7, 2022 at 11:54 AM Sebastian Huber
> >  > > wrote:
> >
> > On 07/03/2022 17:48, Joel Sherrill wrote:
> >  > This appears to be because
> >  > rtems_configuration_get_user_multiprocessing_table() always
> returns a
> >  > non-NULL value when RTEMS_MULTIPROCESSING is defined. This must
> > be a change
> >  > versus previous behavior.
> >  >
> >  > Ryan and I noticed that the specific cases cited here appeared to
> be
> >  > wrapped in ifdef RTEMS_MULTIPROCESSING so didn't need to worry
> > about it.
> >  > But something has changed that impacts public facing behavior.
> >
> > I think this is the related ticket:
> >
> > https://devel.rtems.org/ticket/3735
> > 
> >
> >
> > OK. But apparently this was used to tell the difference between a
> > single node system in MP configuration and a node within an
> > MP configuration.  My grep shows some uses are really dereferencing
> > the table but others like the one in amba.h:153 to define the clock
> > index looks wrong. THere is similar code in leon.h:
> >
> > #if defined(RTEMS_MULTIPROCESSING)
> >#define LEON3_CLOCK_INDEX \
> > (rtems_configuration_get_user_multiprocessing_table() ?
> > LEON3_Cpu_Index : 0)
>
>
> > #else
> >#define LEON3_CLOCK_INDEX 0
> > #endif
> >
> > That's the type of pattern that needs addressing. That test is
> > asking in multiprocessing is configured in the application not
> > in the build.
>
> The rtems_configuration_get_user_multiprocessing_table() ? X : Y
> expressions can be simplified to X.
>

That does not preserve the semantics of the original. In the original
implementation, it could return NULL for an application configured
to be a single processor with no distributed multiprocessing in use.

The change gets rid of the warning but doesn't 'retain the intent.

>
> This change needs to be looked at (the comment in the file header makes
> no sense after this change):
>
> commit 7f3c6cee09ee44b627b11de34248aba485c789b3
> Author: Joel Sherrill 
> Date:   Tue Dec 4 22:20:55 2007 +
>
>  2007-12-04  Joel Sherrill 
>
>  * amba/amba.c, clock/ckinit.c, console/console.c,
> include/bsp.h,
>  startup/bspstart.c, timer/timer.c: Move
> interrupt_stack_size field
>  from CPU Table to Configuration Table. Eliminate CPU Table
> from all
>  ports. Delete references to CPU Table in all forms.
>
> diff --git a/c/src/lib/libbsp/sparc/leon3/timer/timer.c
> b/c/src/lib/libbsp/sparc/leon3/timer/timer.c
> index 9d6f89a593..2c1127a30a 100644
> --- a/c/src/lib/libbsp/sparc/leon3/timer/timer.c
> +++ b/c/src/lib/libbsp/sparc/leon3/timer/timer.c
> @@ -22,12 +22,13 @@
>
>   #include 
>
> -extern rtems_configuration_table Configuration;
> -
> -#define LEON3_TIMER_INDEX \
> -  (Configuration.User_multiprocessing_table ?  \
> - (Configuration.User_multiprocessing_table)->maximum_nodes + \
> - (Configuration.User_multiprocessing_table)->node - 1 : 1)
> +#if defined(RTEMS_MULTIPROCESSING)
> +  #define LEON3_TIMER_INDEX \
> +  (rtems_configuration_get_user_multiprocessing_table() ? : \
> +(rtems_configuration_get_user_multiprocessing_table()->node) -
> 1 : 1)
> +#else
> +  #define LEON3_TIMER_INDEX 0
> +#endif
>
>   rtems_boolean Timer_driver_Find_average_overhead;
>
>
>
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Warnings when building sparc/leon3

[Sebastian Huber]

On 08/03/2022 15:23, Joel Sherrill wrote:



On Tue, Mar 8, 2022 at 12:45 AM Sebastian Huber 
> wrote:


On 07/03/2022 19:19, Joel Sherrill wrote:
 >
 >
 > On Mon, Mar 7, 2022 at 11:54 AM Sebastian Huber
 > mailto:sebastian.hu...@embedded-brains.de>
 > >> wrote:
 >
 >     On 07/03/2022 17:48, Joel Sherrill wrote:
 >      > This appears to be because
 >      > rtems_configuration_get_user_multiprocessing_table()
always returns a
 >      > non-NULL value when RTEMS_MULTIPROCESSING is defined. This
must
 >     be a change
 >      > versus previous behavior.
 >      >
 >      > Ryan and I noticed that the specific cases cited here
appeared to be
 >      > wrapped in ifdef RTEMS_MULTIPROCESSING so didn't need to worry
 >     about it.
 >      > But something has changed that impacts public facing behavior.
 >
 >     I think this is the related ticket:
 >
 > https://devel.rtems.org/ticket/3735

 >     >
 >
 >
 > OK. But apparently this was used to tell the difference between a
 > single node system in MP configuration and a node within an
 > MP configuration.  My grep shows some uses are really dereferencing
 > the table but others like the one in amba.h:153 to define the clock
 > index looks wrong. THere is similar code in leon.h:
 >
 > #if defined(RTEMS_MULTIPROCESSING)
 >    #define LEON3_CLOCK_INDEX \
 >     (rtems_configuration_get_user_multiprocessing_table() ?
 > LEON3_Cpu_Index : 0)


 > #else
 >    #define LEON3_CLOCK_INDEX 0
 > #endif
 >
 > That's the type of pattern that needs addressing. That test is
 > asking in multiprocessing is configured in the application not
 > in the build.

The rtems_configuration_get_user_multiprocessing_table() ? X : Y
expressions can be simplified to X.


That does not preserve the semantics of the original. In the original
implementation, it could return NULL for an application configured
to be a single processor with no distributed multiprocessing in use.

The change gets rid of the warning but doesn't 'retain the intent.


If you think the original behaviour of 
rtems_configuration_get_user_multiprocessing_table() is important, then 
it should be documented and tested.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Warnings when building sparc/leon3

[Joel Sherrill]

On Tue, Mar 8, 2022 at 8:31 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 08/03/2022 15:23, Joel Sherrill wrote:
> >
> >
> > On Tue, Mar 8, 2022 at 12:45 AM Sebastian Huber
> >  > > wrote:
> >
> > On 07/03/2022 19:19, Joel Sherrill wrote:
> >  >
> >  >
> >  > On Mon, Mar 7, 2022 at 11:54 AM Sebastian Huber
> >  >  > 
> >  >  > >> wrote:
> >  >
> >  > On 07/03/2022 17:48, Joel Sherrill wrote:
> >  >  > This appears to be because
> >  >  > rtems_configuration_get_user_multiprocessing_table()
> > always returns a
> >  >  > non-NULL value when RTEMS_MULTIPROCESSING is defined. This
> > must
> >  > be a change
> >  >  > versus previous behavior.
> >  >  >
> >  >  > Ryan and I noticed that the specific cases cited here
> > appeared to be
> >  >  > wrapped in ifdef RTEMS_MULTIPROCESSING so didn't need to
> worry
> >  > about it.
> >  >  > But something has changed that impacts public facing
> behavior.
> >  >
> >  > I think this is the related ticket:
> >  >
> >  > https://devel.rtems.org/ticket/3735
> > 
> >  >  > >
> >  >
> >  >
> >  > OK. But apparently this was used to tell the difference between a
> >  > single node system in MP configuration and a node within an
> >  > MP configuration.  My grep shows some uses are really
> dereferencing
> >  > the table but others like the one in amba.h:153 to define the
> clock
> >  > index looks wrong. THere is similar code in leon.h:
> >  >
> >  > #if defined(RTEMS_MULTIPROCESSING)
> >  >#define LEON3_CLOCK_INDEX \
> >  > (rtems_configuration_get_user_multiprocessing_table() ?
> >  > LEON3_Cpu_Index : 0)
> >
> >
> >  > #else
> >  >#define LEON3_CLOCK_INDEX 0
> >  > #endif
> >  >
> >  > That's the type of pattern that needs addressing. That test is
> >  > asking in multiprocessing is configured in the application not
> >  > in the build.
> >
> > The rtems_configuration_get_user_multiprocessing_table() ? X : Y
> > expressions can be simplified to X.
> >
> >
> > That does not preserve the semantics of the original. In the original
> > implementation, it could return NULL for an application configured
> > to be a single processor with no distributed multiprocessing in use.
> >
> > The change gets rid of the warning but doesn't 'retain the intent.
>
> If you think the original behaviour of
> rtems_configuration_get_user_multiprocessing_table() is important, then
> it should be documented and tested.
>

The original behavior can't be re-implemented. When you made changes
so there was always an MPCI Table, it fundamentally broke the assumption
that one might not be present when MP is enabled.

I don't want it reverted. I wish all the cases where it was checking for
NULL
that broke when it could no longer be NULL were addressed at the time.
There had to be warnings if that configuration had been built.

We need to fix the use cases to align with the new behavior.  You fixed
some in Leon3 and Ryan has a patch for some in cpukit.

--joel

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Warnings when building sparc/leon3

[Sebastian Huber]

On 08/03/2022 15:40, Joel Sherrill wrote:


On Tue, Mar 8, 2022 at 8:31 AM Sebastian Huber 
> wrote:


On 08/03/2022 15:23, Joel Sherrill wrote:
 >
 >
 > On Tue, Mar 8, 2022 at 12:45 AM Sebastian Huber
 > mailto:sebastian.hu...@embedded-brains.de>
 > >> wrote:
 >
 >     On 07/03/2022 19:19, Joel Sherrill wrote:
 >      >
 >      >
 >      > On Mon, Mar 7, 2022 at 11:54 AM Sebastian Huber
 >      > mailto:sebastian.hu...@embedded-brains.de>
 >     >
 >      > 
 >           >
 >      >     On 07/03/2022 17:48, Joel Sherrill wrote:
 >      >      > This appears to be because
 >      >      > rtems_configuration_get_user_multiprocessing_table()
 >     always returns a
 >      >      > non-NULL value when RTEMS_MULTIPROCESSING is
defined. This
 >     must
 >      >     be a change
 >      >      > versus previous behavior.
 >      >      >
 >      >      > Ryan and I noticed that the specific cases cited here
 >     appeared to be
 >      >      > wrapped in ifdef RTEMS_MULTIPROCESSING so didn't
need to worry
 >      >     about it.
 >      >      > But something has changed that impacts public
facing behavior.
 >      >
 >      >     I think this is the related ticket:
 >      >
 >      > https://devel.rtems.org/ticket/3735

 >     >
 >      >     
 >     >>
 >      >
 >      >
 >      > OK. But apparently this was used to tell the difference
between a
 >      > single node system in MP configuration and a node within an
 >      > MP configuration.  My grep shows some uses are really
dereferencing
 >      > the table but others like the one in amba.h:153 to define
the clock
 >      > index looks wrong. THere is similar code in leon.h:
 >      >
 >      > #if defined(RTEMS_MULTIPROCESSING)
 >      >    #define LEON3_CLOCK_INDEX \
 >      >     (rtems_configuration_get_user_multiprocessing_table() ?
 >      > LEON3_Cpu_Index : 0)
 >
 >
 >      > #else
 >      >    #define LEON3_CLOCK_INDEX 0
 >      > #endif
 >      >
 >      > That's the type of pattern that needs addressing. That test is
 >      > asking in multiprocessing is configured in the application not
 >      > in the build.
 >
 >     The rtems_configuration_get_user_multiprocessing_table() ? X : Y
 >     expressions can be simplified to X.
 >
 >
 > That does not preserve the semantics of the original. In the original
 > implementation, it could return NULL for an application configured
 > to be a single processor with no distributed multiprocessing in use.
 >
 > The change gets rid of the warning but doesn't 'retain the intent.

If you think the original behaviour of
rtems_configuration_get_user_multiprocessing_table() is important, then
it should be documented and tested.


The original behavior can't be re-implemented. When you made changes
so there was always an MPCI Table, it fundamentally broke the assumption
that one might not be present when MP is enabled.


We could change rtems_configuration_get_user_multiprocessing_table() to 
return NULL if CONFIGURE_MP_APPLICATION is not defined.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Warnings when building sparc/leon3

[Joel Sherrill]

On Tue, Mar 8, 2022 at 8:46 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 08/03/2022 15:40, Joel Sherrill wrote:
> >
> > On Tue, Mar 8, 2022 at 8:31 AM Sebastian Huber
> >  > > wrote:
> >
> > On 08/03/2022 15:23, Joel Sherrill wrote:
> >  >
> >  >
> >  > On Tue, Mar 8, 2022 at 12:45 AM Sebastian Huber
> >  >  > 
> >  >  > >> wrote:
> >  >
> >  > On 07/03/2022 19:19, Joel Sherrill wrote:
> >  >  >
> >  >  >
> >  >  > On Mon, Mar 7, 2022 at 11:54 AM Sebastian Huber
> >  >  >  > 
> >  >  > >
> >  >  >  > 
> >  >  >  >  >  >
> >  >  > On 07/03/2022 17:48, Joel Sherrill wrote:
> >  >  >  > This appears to be because
> >  >  >  > rtems_configuration_get_user_multiprocessing_table()
> >  > always returns a
> >  >  >  > non-NULL value when RTEMS_MULTIPROCESSING is
> > defined. This
> >  > must
> >  >  > be a change
> >  >  >  > versus previous behavior.
> >  >  >  >
> >  >  >  > Ryan and I noticed that the specific cases cited
> here
> >  > appeared to be
> >  >  >  > wrapped in ifdef RTEMS_MULTIPROCESSING so didn't
> > need to worry
> >  >  > about it.
> >  >  >  > But something has changed that impacts public
> > facing behavior.
> >  >  >
> >  >  > I think this is the related ticket:
> >  >  >
> >  >  > https://devel.rtems.org/ticket/3735
> > 
> >  >  > >
> >  >  >  > 
> >  >  > >>
> >  >  >
> >  >  >
> >  >  > OK. But apparently this was used to tell the difference
> > between a
> >  >  > single node system in MP configuration and a node within an
> >  >  > MP configuration.  My grep shows some uses are really
> > dereferencing
> >  >  > the table but others like the one in amba.h:153 to define
> > the clock
> >  >  > index looks wrong. THere is similar code in leon.h:
> >  >  >
> >  >  > #if defined(RTEMS_MULTIPROCESSING)
> >  >  >#define LEON3_CLOCK_INDEX \
> >  >  > (rtems_configuration_get_user_multiprocessing_table() ?
> >  >  > LEON3_Cpu_Index : 0)
> >  >
> >  >
> >  >  > #else
> >  >  >#define LEON3_CLOCK_INDEX 0
> >  >  > #endif
> >  >  >
> >  >  > That's the type of pattern that needs addressing. That
> test is
> >  >  > asking in multiprocessing is configured in the application
> not
> >  >  > in the build.
> >  >
> >  > The rtems_configuration_get_user_multiprocessing_table() ? X
> : Y
> >  > expressions can be simplified to X.
> >  >
> >  >
> >  > That does not preserve the semantics of the original. In the
> original
> >  > implementation, it could return NULL for an application configured
> >  > to be a single processor with no distributed multiprocessing in
> use.
> >  >
> >  > The change gets rid of the warning but doesn't 'retain the intent.
> >
> > If you think the original behaviour of
> > rtems_configuration_get_user_multiprocessing_table() is important,
> then
> > it should be documented and tested.
> >
> >
> > The original behavior can't be re-implemented. When you made changes
> > so there was always an MPCI Table, it fundamentally broke the assumption
> > that one might not be present when MP is enabled.
>
> We could change rtems_configuration_get_user_multiprocessing_table() to
> return NULL if CONFIGURE_MP_APPLICATION is not defined.
>

That's how it is now.

#if defined(RTEMS_MULTIPROCESSING)
  #define rtems_configuration_get_user_multiprocessing_table() \
( &_MPCI_Configuration )
#else
  #define rtems_configuration_get_user_multiprocessing_table() NULL
#endif

I think all the use cases Ryan and I saw were protected by ifdef
RTEMS_MULTIPROCESSING. Perhaps this just should not be defined
if it isn't configured.

--joel

>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> 

Re: Warnings when building sparc/leon3

[Sebastian Huber]

On 08/03/2022 15:52, Joel Sherrill wrote:

We could change rtems_configuration_get_user_multiprocessing_table() to
return NULL if CONFIGURE_MP_APPLICATION is not defined.


That's how it is now.

#if defined(RTEMS_MULTIPROCESSING)
   #define rtems_configuration_get_user_multiprocessing_table() \
     ( &_MPCI_Configuration )


This could be change to something like:

( _MPCI_Application ? &_MPCI_Configuration : NULL )

With

#ifdef CONFIGURE_MP_APPLICATION

const bool _MPCI_Application = true;

#else

const bool _MPCI_Application = false;

#endif


#else
   #define rtems_configuration_get_user_multiprocessing_table() NULL
#endif

I think all the use cases Ryan and I saw were protected by ifdef
RTEMS_MULTIPROCESSING. Perhaps this just should not be defined
if it isn't configured.


The API directives are always provided.

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Warnings when building sparc/leon3

[Joel Sherrill]

On Tue, Mar 8, 2022 at 9:18 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 08/03/2022 15:52, Joel Sherrill wrote:
> > We could change rtems_configuration_get_user_multiprocessing_table()
> to
> > return NULL if CONFIGURE_MP_APPLICATION is not defined.
> >
> >
> > That's how it is now.
> >
> > #if defined(RTEMS_MULTIPROCESSING)
> >#define rtems_configuration_get_user_multiprocessing_table() \
> >  ( &_MPCI_Configuration )
>
> This could be change to something like:
>
> ( _MPCI_Application ? &_MPCI_Configuration : NULL )
>
>
This would reflect the original semantics and be better.

Ryan's patch would not be needed in this case.


> With
>
> #ifdef CONFIGURE_MP_APPLICATION
>
> const bool _MPCI_Application = true;
>
> #else
>
> const bool _MPCI_Application = false;
>
> #endif
>
> > #else
> >#define rtems_configuration_get_user_multiprocessing_table() NULL
> > #endif
> >
> > I think all the use cases Ryan and I saw were protected by ifdef
> > RTEMS_MULTIPROCESSING. Perhaps this just should not be defined
> > if it isn't configured.
>
> The API directives are always provided.
>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] SMP: Fix start multitasking for some targets

[Sebastian Huber]

The previous SMP multitasking start assumed that the initial heir thread of a
processor starts execution in _Thread_Handler().  The _Thread_Handler() sets
the interrupt state explicitly by _ISR_Set_level() before it calls the thread
entry.  Under certain timing conditions, processors may perform an initial
context switch to a thread which already executes its thread body (see
smptests/smpstart01).  In this case, interrupts are disabled after the context
switch on targets which do not save/restore the interrupt state during a
context switch (aarch64, arm, and riscv).

Close #4627.
---
 cpukit/score/cpu/aarch64/cpu_asm.S  | 17 +
 .../score/cpu/aarch64/include/rtems/score/cpu.h |  4 
 cpukit/score/cpu/arm/cpu_asm.S  | 12 
 cpukit/score/cpu/arm/include/rtems/score/cpu.h  |  4 
 .../score/cpu/riscv/include/rtems/score/cpu.h   |  4 
 cpukit/score/cpu/riscv/riscv-context-switch.S   | 15 +++
 cpukit/score/src/threadstartmultitasking.c  |  3 +++
 7 files changed, 59 insertions(+)

diff --git a/cpukit/score/cpu/aarch64/cpu_asm.S 
b/cpukit/score/cpu/aarch64/cpu_asm.S
index 2379698336..6321acde90 100644
--- a/cpukit/score/cpu/aarch64/cpu_asm.S
+++ b/cpukit/score/cpu/aarch64/cpu_asm.S
@@ -202,5 +202,22 @@ DEFINE_FUNCTION_AARCH64(_CPU_Context_restore)
str x5, [x2, #PER_CPU_OFFSET_EXECUTING]
 #endif
 
+   b   .L_check_is_executing
+
+DEFINE_FUNCTION_AARCH64(_AArch64_Start_multitasking)
+#ifdef AARCH64_MULTILIB_ARCH_V8_ILP32
+   /* Sanitize input for ILP32 ABI */
+   mov w0, w0
+#endif
+
+   mov x1, x0
+   GET_SELF_CPU_CONTROLreg_2
+
+   /* Switch the stack to the temporary interrupt stack of this processor 
*/
+   add sp, x2, #(PER_CPU_INTERRUPT_FRAME_AREA + 
CPU_INTERRUPT_FRAME_SIZE)
+
+   /* Enable interrupts */
+   msr DAIFClr, #0x2
+
b   .L_check_is_executing
 #endif
diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h 
b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
index e1d9f0a5c2..fdc0e3d929 100644
--- a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
@@ -285,6 +285,10 @@ void _CPU_Context_Initialize(
   {
 context->is_executing = is_executing;
   }
+
+  RTEMS_NO_RETURN void _AArch64_Start_multitasking( Context_Control *heir );
+
+  #define _CPU_Start_multitasking( _heir ) _AArch64_Start_multitasking( _heir )
 #endif
 
 #define _CPU_Context_Restart_self( _the_context ) \
diff --git a/cpukit/score/cpu/arm/cpu_asm.S b/cpukit/score/cpu/arm/cpu_asm.S
index 54d6f70b0d..d52a43f70d 100644
--- a/cpukit/score/cpu/arm/cpu_asm.S
+++ b/cpukit/score/cpu/arm/cpu_asm.S
@@ -181,6 +181,18 @@ DEFINE_FUNCTION_ARM(_CPU_Context_restore)
/* Update the executing */
str r5, [r2, #PER_CPU_OFFSET_EXECUTING]
 
+   b   .L_check_is_executing
+
+DEFINE_FUNCTION_ARM(_ARM_Start_multitasking)
+   mov r1, r0
+   GET_SELF_CPU_CONTROLr2
+
+   /* Switch the stack to the temporary interrupt stack of this processor 
*/
+   add sp, r2, #(PER_CPU_INTERRUPT_FRAME_AREA + 
CPU_INTERRUPT_FRAME_SIZE)
+
+   /* Enable IRQ interrupts */
+   cpsie   i
+
b   .L_check_is_executing
 #endif
 
diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpu.h 
b/cpukit/score/cpu/arm/include/rtems/score/cpu.h
index da521528a4..7ac180ac26 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/cpu.h
@@ -443,6 +443,10 @@ void _CPU_Context_Initialize(
   {
 context->is_executing = is_executing;
   }
+
+  RTEMS_NO_RETURN void _ARM_Start_multitasking( Context_Control *heir );
+
+  #define _CPU_Start_multitasking( _heir ) _ARM_Start_multitasking( _heir )
 #endif
 
 #define _CPU_Context_Restart_self( _the_context ) \
diff --git a/cpukit/score/cpu/riscv/include/rtems/score/cpu.h 
b/cpukit/score/cpu/riscv/include/rtems/score/cpu.h
index 05ef2709ba..471c6c6c3e 100644
--- a/cpukit/score/cpu/riscv/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/riscv/include/rtems/score/cpu.h
@@ -509,6 +509,10 @@ static inline void _CPU_Context_Set_is_executing(
   context->is_executing = is_executing;
 }
 
+RTEMS_NO_RETURN void _RISCV_Start_multitasking( Context_Control *heir );
+
+#define _CPU_Start_multitasking( _heir ) _RISCV_Start_multitasking( _heir )
+
 #endif /* RTEMS_SMP */
 
 /** Type that can store a 32-bit integer or a pointer. */
diff --git a/cpukit/score/cpu/riscv/riscv-context-switch.S 
b/cpukit/score/cpu/riscv/riscv-context-switch.S
index 3c0368886e..cfaff444b0 100644
--- a/cpukit/score/cpu/riscv/riscv-context-switch.S
+++ b/cpukit/score/cpu/riscv/riscv-context-switch.S
@@ -40,6 +40,9 @@
 PUBLIC(_CPU_Context_switch)
 PUBLIC(_CPU_Context_switch_no_return)
 PUBLIC(_CPU_Context_restore)
+#ifdef RTEMS_SMP
+PUBLIC(_RISCV_Start_multitasking)
+#endif
 
 SYM(_CPU_Context_switch):
 SYM(_CPU_Context_switch_no_return):
@@ -17

Re: [PATCH 1/2] cpukit/aarch64: Keep state across context switch

[Sebastian Huber]

On 08/03/2022 15:06, Kinsey Moore wrote:

On 3/8/2022 02:52, Sebastian Huber wrote:

On 28/02/2022 20:18, Kinsey Moore wrote:


On 2/28/2022 12:19, Sebastian Huber wrote:

On 26/02/2022 08:03, Kinsey Moore wrote:

On 2/26/2022 00:53, Sebastian Huber wrote:

On 26/02/2022 00:41, Kinsey Moore wrote:
This may also be an issue for ARM, RISC-V and others as it 
doesn't appear that ARM saves CPSR during context switch and I 
couldn't tell that RISC-V does this either, though I'm less 
familiar with it.


This doesn't look like the right way to fix this issue.

There is currently the assumption that all processors start 
multitasking with a context switch to _Thread_Handler() which sets 
the interrupt level. It is possible to construct a scenario in 
which we start multitasking with a migration of a thread which 
already executed the _Thread_Handler() prologue. This would result 
in an execution with disabled interrupts. I think the proper fix 
for this scenario is to enable interrupts in 
_CPU_SMP_Prepare_start_multitasking().


Doing a context switch with interrupts disabled is a fatal 
application error on all architectures with


#define CPU_ENABLE_ROBUST_THREAD_DISPATCH TRUE

or enabled SMP support.

Ok, great. I was wondering if that was the case and this is 
definitely the kind of feedback I was looking for. I'll adjust the 
patch set to reflect that. I still wonder if this is an issue on 
other SMP CPU ports, though, since most of them don't implement 
that hook, either.


I would like to have a closer look at this next week then I am back 
from holidays.


Enabling interrupts in _CPU_SMP_Prepare_start_multitasking() would 
not work since we use the interrupt stack at this point. We should 
add a ticket and a test case for this (I can do this next week). How 
did you observe this bug?


I was only able to observe this bug once the 2/2 patch is applied and 
that optimization opens a race condition (adding a few no-ops to the 
Per_CPU_Control accessor prevents it from appearing) in the 
sppercpudata01 test on SMP configurations since the task is migrating 
across CPUs as CPUs are coming online. The race condition resolves 
nominally in 90% of cases so while it's not a frequent failure it is 
reproducible.


I added a ticket and a test case:

http://devel.rtems.org/ticket/4627

Could you please check if the test case fails currently on your 
aarch64 target?


I have verified that this test case fails under QEMU and on the hardware 
target.


Thanks for the test, could you please have a look at this patch:

https://lists.rtems.org/pipermail/devel/2022-March/070760.html

--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] microblaze: Add JFFS2 AXI QSPI driver

[Alex White]

ping

On Wed, Mar 2, 2022 at 8:30 PM Alex White  wrote:
>
> This driver has been tested with Micron NOR Flash via AXI Quad SPI.
> ---
>  .../microblaze_fpga/fs/jffs2_qspi.c           | 319 ++
>  .../microblaze_fpga/include/bsp/jffs2_qspi.h  |  56 +++
>  .../bsps/microblaze/microblaze_fpga/grp.yml   |   6 +
>  .../bsps/microblaze/microblaze_fpga/obj.yml   |   2 +
>  .../microblaze_fpga/optspibaseaddress.yml     |  18 +
>  .../microblaze/microblaze_fpga/optspiirq.yml  |  17 +
>  6 files changed, 418 insertions(+)
>  create mode 100644 bsps/microblaze/microblaze_fpga/fs/jffs2_qspi.c
>  create mode 100644 bsps/microblaze/microblaze_fpga/include/bsp/jffs2_qspi.h
>  create mode 100644 
> spec/build/bsps/microblaze/microblaze_fpga/optspibaseaddress.yml
>  create mode 100644 spec/build/bsps/microblaze/microblaze_fpga/optspiirq.yml
>
> diff --git a/bsps/microblaze/microblaze_fpga/fs/jffs2_qspi.c 
> b/bsps/microblaze/microblaze_fpga/fs/jffs2_qspi.c
> new file mode 100644
> index 00..39328b6b7c
> --- /dev/null
> +++ b/bsps/microblaze/microblaze_fpga/fs/jffs2_qspi.c
> @@ -0,0 +1,319 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup RTEMSBSPsMicroblaze
> + *
> + * @brief MicroBlaze AXI QSPI JFFS2 flash driver implementation
> + */
> +
> +/*
> + * Copyright (C) 2022 On-Line Applications Research Corporation (OAR)
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *    notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *    notice, this list of conditions and the following disclaimer in the
> + *    documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#define BLOCK_SIZE (64UL * 1024UL)
> +#define FLASH_SIZE (32UL * BLOCK_SIZE)
> +#define FLASH_PAGE_SIZE        256
> +#define FLASH_NUM_CS           2
> +#define FLASH_DEVICE_ID        0xbb19 /* Type: 0xbb, Capacity: 0x19 */
> +#define BUS_PATH          "/dev/spi-0"
> +#define FLASH_MOUNT_POINT "/mnt"
> +
> +#define READ_WRITE_EXTRA_BYTES 4
> +#define WRITE_ENABLE_BYTES     1
> +#define SECTOR_ERASE_BYTES     4
> +
> +#define COMMAND_QUAD_WRITE     0x32
> +#define COMMAND_SECTOR_ERASE   0xD8
> +#define COMMAND_QUAD_READ      0x6B
> +#define COMMAND_STATUSREG_READ 0x05
> +#define COMMAND_WRITE_ENABLE   0x06
> +#define FLASH_SR_IS_READY_MASK 0x01
> +
> +typedef struct {
> +  rtems_jffs2_flash_control super;
> +  int                       fd;
> +} flash_control;
> +
> +static uint8_t ReadBuffer[FLASH_PAGE_SIZE + READ_WRITE_EXTRA_BYTES + 4];
> +static uint8_t WriteBuffer[FLASH_PAGE_SIZE + READ_WRITE_EXTRA_BYTES + 4];
> +
> +static flash_control *get_flash_control( rtems_jffs2_flash_control *super )
> +{
> +  return (flash_control *) super;
> +}
> +
> +static int flash_wait_for_ready( flash_control *self )
> +{
> +  uint8_t rv     = 0;
> +  uint8_t status = 0;
> +
> +  WriteBuffer[0] = COMMAND_STATUSREG_READ;
> +
> +  struct spi_ioc_transfer mesg = {
> +    .tx_buf        = WriteBuffer,
> +    .rx_buf        = ReadBuffer,
> +    .len           = 2,
> +    .bits_per_word = 8,
> +    .cs            = 0
> +  };
> +
> +  do {
> +    rv = ioctl( self->fd, SPI_IOC_MESSAGE( 1 ), &mesg );
> +    if ( rv != 0 ) {
> +      return -EIO;
> +    }
> +
> +    status = ReadBuffer[1];
> +  } while ( (status & FLASH_SR_IS_READY_MASK) != 0 );
> +
> +  return 0;
> +}
> +
> +static int flash_write_enable( flash_control *self )
> +{
> +  uint8_t rv = 0;
> +
> +  rv = flash_wait_for_ready( self );
> +  if ( rv != 0 ) {
> +    return rv;
> +  }
> +
> +  WriteBuffer[0] = COMMAND_WRITE_ENABLE;
> +
> +  struct spi_ioc_transfer mesg = {
> +    .tx_buf        = WriteBuffer,
> +    .len           = WRITE_ENABLE_BYTES,
> +    .bits_per_word = 8,
> +    .cs 

Re: [PATCH] SMP: Fix start multitasking for some targets

[Kinsey Moore]

The AArch64 changes look reasonable and resolve the bug I observed in 
both the test case you provided as well as the test where I initially 
discovered it.



Thanks,

Kinsey

On 3/8/2022 12:28, Sebastian Huber wrote:

The previous SMP multitasking start assumed that the initial heir thread of a
processor starts execution in _Thread_Handler().  The _Thread_Handler() sets
the interrupt state explicitly by _ISR_Set_level() before it calls the thread
entry.  Under certain timing conditions, processors may perform an initial
context switch to a thread which already executes its thread body (see
smptests/smpstart01).  In this case, interrupts are disabled after the context
switch on targets which do not save/restore the interrupt state during a
context switch (aarch64, arm, and riscv).

Close #4627.
---
  cpukit/score/cpu/aarch64/cpu_asm.S  | 17 +
  .../score/cpu/aarch64/include/rtems/score/cpu.h |  4 
  cpukit/score/cpu/arm/cpu_asm.S  | 12 
  cpukit/score/cpu/arm/include/rtems/score/cpu.h  |  4 
  .../score/cpu/riscv/include/rtems/score/cpu.h   |  4 
  cpukit/score/cpu/riscv/riscv-context-switch.S   | 15 +++
  cpukit/score/src/threadstartmultitasking.c  |  3 +++
  7 files changed, 59 insertions(+)

diff --git a/cpukit/score/cpu/aarch64/cpu_asm.S 
b/cpukit/score/cpu/aarch64/cpu_asm.S
index 2379698336..6321acde90 100644
--- a/cpukit/score/cpu/aarch64/cpu_asm.S
+++ b/cpukit/score/cpu/aarch64/cpu_asm.S
@@ -202,5 +202,22 @@ DEFINE_FUNCTION_AARCH64(_CPU_Context_restore)
str x5, [x2, #PER_CPU_OFFSET_EXECUTING]
  #endif
  
+	b	.L_check_is_executing

+
+DEFINE_FUNCTION_AARCH64(_AArch64_Start_multitasking)
+#ifdef AARCH64_MULTILIB_ARCH_V8_ILP32
+   /* Sanitize input for ILP32 ABI */
+   mov w0, w0
+#endif
+
+   mov x1, x0
+   GET_SELF_CPU_CONTROLreg_2
+
+   /* Switch the stack to the temporary interrupt stack of this processor 
*/
+   add sp, x2, #(PER_CPU_INTERRUPT_FRAME_AREA + 
CPU_INTERRUPT_FRAME_SIZE)
+
+   /* Enable interrupts */
+   msr DAIFClr, #0x2
+
b   .L_check_is_executing
  #endif
diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h 
b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
index e1d9f0a5c2..fdc0e3d929 100644
--- a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
@@ -285,6 +285,10 @@ void _CPU_Context_Initialize(
{
  context->is_executing = is_executing;
}
+
+  RTEMS_NO_RETURN void _AArch64_Start_multitasking( Context_Control *heir );
+
+  #define _CPU_Start_multitasking( _heir ) _AArch64_Start_multitasking( _heir )
  #endif
  
  #define _CPU_Context_Restart_self( _the_context ) \

diff --git a/cpukit/score/cpu/arm/cpu_asm.S b/cpukit/score/cpu/arm/cpu_asm.S
index 54d6f70b0d..d52a43f70d 100644
--- a/cpukit/score/cpu/arm/cpu_asm.S
+++ b/cpukit/score/cpu/arm/cpu_asm.S
@@ -181,6 +181,18 @@ DEFINE_FUNCTION_ARM(_CPU_Context_restore)
/* Update the executing */
str r5, [r2, #PER_CPU_OFFSET_EXECUTING]
  
+	b	.L_check_is_executing

+
+DEFINE_FUNCTION_ARM(_ARM_Start_multitasking)
+   mov r1, r0
+   GET_SELF_CPU_CONTROLr2
+
+   /* Switch the stack to the temporary interrupt stack of this processor 
*/
+   add sp, r2, #(PER_CPU_INTERRUPT_FRAME_AREA + 
CPU_INTERRUPT_FRAME_SIZE)
+
+   /* Enable IRQ interrupts */
+   cpsie   i
+
b   .L_check_is_executing
  #endif
  
diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpu.h b/cpukit/score/cpu/arm/include/rtems/score/cpu.h

index da521528a4..7ac180ac26 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/cpu.h
@@ -443,6 +443,10 @@ void _CPU_Context_Initialize(
{
  context->is_executing = is_executing;
}
+
+  RTEMS_NO_RETURN void _ARM_Start_multitasking( Context_Control *heir );
+
+  #define _CPU_Start_multitasking( _heir ) _ARM_Start_multitasking( _heir )
  #endif
  
  #define _CPU_Context_Restart_self( _the_context ) \

diff --git a/cpukit/score/cpu/riscv/include/rtems/score/cpu.h 
b/cpukit/score/cpu/riscv/include/rtems/score/cpu.h
index 05ef2709ba..471c6c6c3e 100644
--- a/cpukit/score/cpu/riscv/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/riscv/include/rtems/score/cpu.h
@@ -509,6 +509,10 @@ static inline void _CPU_Context_Set_is_executing(
context->is_executing = is_executing;
  }
  
+RTEMS_NO_RETURN void _RISCV_Start_multitasking( Context_Control *heir );

+
+#define _CPU_Start_multitasking( _heir ) _RISCV_Start_multitasking( _heir )
+
  #endif /* RTEMS_SMP */
  
  /** Type that can store a 32-bit integer or a pointer. */

diff --git a/cpukit/score/cpu/riscv/riscv-context-switch.S 
b/cpukit/score/cpu/riscv/riscv-context-switch.S
index 3c0368886e..cfaff444b0 100644
--- a/cpukit/score/cpu/riscv/riscv-context-switch.S
+++ b/cpukit/score/cpu/riscv/riscv-context-switch.S
@@ -40,6 +40,9 

Re: [PATCH] mpci: Simplify expressions

[Gedare Bloom]

On Tue, Mar 8, 2022 at 6:59 AM Sebastian Huber
 wrote:
>
> On 08/03/2022 14:56, Gedare Bloom wrote:
> > On Mon, Mar 7, 2022 at 11:52 PM Sebastian Huber
> >   wrote:
> >> Use that rtems_configuration_get_user_multiprocessing_table() returns never
> >> NULL if RTEMS_MULTIPROCESSING defined.
> >> ---
> >>   bsps/m68k/mvme147s/start/bspstart.c |  2 +-
> >>   bsps/riscv/griscv/include/amba.h|  3 +--
> >>   bsps/sparc/leon3/btimer/btimer.c|  5 ++---
> >>   bsps/sparc/leon3/include/leon.h |  3 +--
> >>   cpukit/libmisc/monitor/mon-editor.c |  6 --
> >>   cpukit/libmisc/stackchk/check.c | 10 --
> >>   6 files changed, 9 insertions(+), 20 deletions(-)
> >>
> >> diff --git a/bsps/m68k/mvme147s/start/bspstart.c 
> >> b/bsps/m68k/mvme147s/start/bspstart.c
> >> index 497b644150..e5eb48f108 100644
> >> --- a/bsps/m68k/mvme147s/start/bspstart.c
> >> +++ b/bsps/m68k/mvme147s/start/bspstart.c
> >> @@ -58,7 +58,7 @@ void bsp_start( void )
> >>
> >>   #if defined(RTEMS_MULTIPROCESSING)
> >> node_number = (uint8_t)
> >> -(rtems_configuration_get_user_multiprocessing_table()->node - 1) & 
> >> 0xF;
> >> +rtems_configuration_get_user_multiprocessing_table()->node - 1;
> > node is never 0?
>
> This would be a configuration error which is checked by:
>
> #if CONFIGURE_MP_NODE_NUMBER < 1
>#error "CONFIGURE_MP_NODE_NUMBER must be greater than or equal to one"
> #endif
>
> #if CONFIGURE_MP_NODE_NUMBER > CONFIGURE_MP_MAXIMUM_NODES
>#error "CONFIGURE_MP_NODE_NUMBER must be less than or equal to
> CONFIGURE_MP_MAXIMUM_NODES"
> #endif
>
> >
> >>   #else
> >>  node_number = 1;
> >>   #endif
> >> diff --git a/bsps/riscv/griscv/include/amba.h 
> >> b/bsps/riscv/griscv/include/amba.h
> >> index 292660d5c1..b615389df4 100644
> >> --- a/bsps/riscv/griscv/include/amba.h
> >> +++ b/bsps/riscv/griscv/include/amba.h
> >> @@ -46,8 +46,7 @@
> >>   #define GRLIB_APB_SLAVES 16
> >>
> >>   #if defined(RTEMS_MULTIPROCESSING)
> >> -  #define GRLIB_CLOCK_INDEX \
> >> -   (rtems_configuration_get_user_multiprocessing_table() ? 
> >> GRLIB_Cpu_Index : 0)
> >> +  #define GRLIB_CLOCK_INDEX GRLIB_Cpu_Index
> >>   #else
> >> #define GRLIB_CLOCK_INDEX 0
> >>   #endif
> >> diff --git a/bsps/sparc/leon3/btimer/btimer.c 
> >> b/bsps/sparc/leon3/btimer/btimer.c
> >> index 9e9f2b02fc..03bbfe06e7 100644
> >> --- a/bsps/sparc/leon3/btimer/btimer.c
> >> +++ b/bsps/sparc/leon3/btimer/btimer.c
> >> @@ -23,10 +23,9 @@
> >>
> >>   #if defined(RTEMS_MULTIPROCESSING)
> >> #define LEON3_TIMER_INDEX \
> >> -  ((rtems_configuration_get_user_multiprocessing_table()) ? \
> >> -(rtems_configuration_get_user_multiprocessing_table()->node) - 1 
> >> : 1)
> >> +(rtems_configuration_get_user_multiprocessing_table()->node)
> > This is not the same value, but
> >
> >>   #else
> >> -  #define LEON3_TIMER_INDEX 0
> >> +  #define LEON3_TIMER_INDEX 1
> > I guess this corrects the off-by-1?
>
> Sorry, this should be probably an extra patch. See remark in:
>
> https://lists.rtems.org/pipermail/devel/2022-March/070744.html
>
OK, I hadn't caught that discussion. The problem of dropping in and
out of the list :)

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsp/altera-cyclone-v: fix the creation of reserved memory regions

[Sebastian Huber]

Hello Marcus,

I have problems to apply this patch e-mail. Could you please send it as 
an attachment.


--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax:   +49-89-18 94 741 - 08

Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel