[PATCH rtems] bsps/arm/imx*: Fix location of shared headers

2020-12-10 Thread Christian Mauderer 
When moving the headers from the imx BSP to the shared area, the wrong
directory has been selected. This patch fixes that problem.

Update #4180
---
 .../include/arm/freescale/imx/imx_iomuxreg.h  |  0
 .../include/arm/freescale/imx/imx_iomuxvar.h  |  0
 bsps/arm/{shared => }/include/bsp/imx-gpio.h  |  0
 bsps/arm/{shared => }/include/bsp/imx-iomux.h |  0
 spec/build/bsps/arm/imx/bspimx.yml| 11 +--
 spec/build/bsps/arm/imxrt/bspimxrt.yml| 11 +--
 6 files changed, 10 insertions(+), 12 deletions(-)
 rename bsps/arm/{shared => }/include/arm/freescale/imx/imx_iomuxreg.h (100%)
 rename bsps/arm/{shared => }/include/arm/freescale/imx/imx_iomuxvar.h (100%)
 rename bsps/arm/{shared => }/include/bsp/imx-gpio.h (100%)
 rename bsps/arm/{shared => }/include/bsp/imx-iomux.h (100%)

diff --git a/bsps/arm/shared/include/arm/freescale/imx/imx_iomuxreg.h 
b/bsps/arm/include/arm/freescale/imx/imx_iomuxreg.h
similarity index 100%
rename from bsps/arm/shared/include/arm/freescale/imx/imx_iomuxreg.h
rename to bsps/arm/include/arm/freescale/imx/imx_iomuxreg.h
diff --git a/bsps/arm/shared/include/arm/freescale/imx/imx_iomuxvar.h 
b/bsps/arm/include/arm/freescale/imx/imx_iomuxvar.h
similarity index 100%
rename from bsps/arm/shared/include/arm/freescale/imx/imx_iomuxvar.h
rename to bsps/arm/include/arm/freescale/imx/imx_iomuxvar.h
diff --git a/bsps/arm/shared/include/bsp/imx-gpio.h 
b/bsps/arm/include/bsp/imx-gpio.h
similarity index 100%
rename from bsps/arm/shared/include/bsp/imx-gpio.h
rename to bsps/arm/include/bsp/imx-gpio.h
diff --git a/bsps/arm/shared/include/bsp/imx-iomux.h 
b/bsps/arm/include/bsp/imx-iomux.h
similarity index 100%
rename from bsps/arm/shared/include/bsp/imx-iomux.h
rename to bsps/arm/include/bsp/imx-iomux.h
diff --git a/spec/build/bsps/arm/imx/bspimx.yml 
b/spec/build/bsps/arm/imx/bspimx.yml
index 5f448682ed..93628f0368 100644
--- a/spec/build/bsps/arm/imx/bspimx.yml
+++ b/spec/build/bsps/arm/imx/bspimx.yml
@@ -8,8 +8,7 @@ copyrights:
 cppflags: []
 enabled-by: true
 family: imx
-includes:
-  - bsps/arm/shared/include
+includes: []
 install:
 - destination: ${BSP_INCLUDEDIR}
   source:
@@ -21,16 +20,16 @@ install:
   - bsps/arm/imx/include/arm/freescale/imx/imx_ecspireg.h
   - bsps/arm/imx/include/arm/freescale/imx/imx_gpcreg.h
   - bsps/arm/imx/include/arm/freescale/imx/imx_i2creg.h
-  - bsps/arm/shared/include/arm/freescale/imx/imx_iomuxreg.h
-  - bsps/arm/shared/include/arm/freescale/imx/imx_iomuxvar.h
   - bsps/arm/imx/include/arm/freescale/imx/imx_srcreg.h
   - bsps/arm/imx/include/arm/freescale/imx/imx_uartreg.h
   - bsps/arm/imx/include/arm/freescale/imx/imx_wdogreg.h
+  - bsps/arm/include/arm/freescale/imx/imx_iomuxreg.h
+  - bsps/arm/include/arm/freescale/imx/imx_iomuxvar.h
 - destination: ${BSP_INCLUDEDIR}/bsp
   source:
-  - bsps/arm/shared/include/bsp/imx-gpio.h
   - bsps/arm/imx/include/bsp/irq.h
-  - bsps/arm/shared/include/bsp/imx-iomux.h
+  - bsps/arm/include/bsp/imx-gpio.h
+  - bsps/arm/include/bsp/imx-iomux.h
 - destination: ${BSP_INCLUDEDIR}/dev/clock
   source:
   - bsps/include/dev/clock/arm-generic-timer.h
diff --git a/spec/build/bsps/arm/imxrt/bspimxrt.yml 
b/spec/build/bsps/arm/imxrt/bspimxrt.yml
index 67161ba11f..bafd7ef3f9 100644
--- a/spec/build/bsps/arm/imxrt/bspimxrt.yml
+++ b/spec/build/bsps/arm/imxrt/bspimxrt.yml
@@ -8,8 +8,7 @@ copyrights:
 cppflags: []
 enabled-by: true
 family: imxrt
-includes:
-  - bsps/arm/shared/include
+includes: []
 install:
 - destination: ${BSP_INCLUDEDIR}
   source:
@@ -92,14 +91,14 @@ install:
   - bsps/arm/imxrt/include/tm27.h
 - destination: ${BSP_INCLUDEDIR}/arm/freescale/imx
   source:
-  - bsps/arm/shared/include/arm/freescale/imx/imx_iomuxreg.h
-  - bsps/arm/shared/include/arm/freescale/imx/imx_iomuxvar.h
+  - bsps/arm/include/arm/freescale/imx/imx_iomuxreg.h
+  - bsps/arm/include/arm/freescale/imx/imx_iomuxvar.h
 - destination: ${BSP_INCLUDEDIR}/bsp
   source:
   - bsps/arm/imxrt/include/bsp/flash-headers.h
   - bsps/arm/imxrt/include/bsp/irq.h
-  - bsps/arm/shared/include/bsp/imx-gpio.h
-  - bsps/arm/shared/include/bsp/imx-iomux.h
+  - bsps/arm/include/bsp/imx-gpio.h
+  - bsps/arm/include/bsp/imx-iomux.h
 - destination: ${BSP_INCLUDEDIR}/imxrt
   source:
   - bsps/arm/imxrt/include/imxrt/imxrt1050-pinfunc.h
-- 
2.26.2

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

RE: [PATCH v2] bsps: Fix GICv3 arm_gic_trigger_sgi()

2020-12-10 Thread Kinsey Moore 
-Original Message-
From: Sebastian Huber  
Sent: Wednesday, December 9, 2020 23:46
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH v2] bsps: Fix GICv3 arm_gic_trigger_sgi()

> On 10/12/2020 00:26, Kinsey Moore wrote:
>
>> -Original Message-
>> From: devel  On Behalf Of Sebastian Huber
>> Sent: Wednesday, December 9, 2020 10:33 To:devel@rtems.org
>> Subject: [PATCH v2] bsps: Fix GICv3 arm_gic_trigger_sgi()
>>
>>> diff --git a/bsps/shared/dev/irq/arm-gicv3.c 
>>> b/bsps/shared/dev/irq/arm-gicv3.c index db10371c72..569c7610c4 100644
>>> --- a/bsps/shared/dev/irq/arm-gicv3.c
>>> +++ b/bsps/shared/dev/irq/arm-gicv3.c
>>> @@ -356,7 +356,7 @@ void arm_gic_trigger_sgi(
>>> uint64_t value = ICC_SGIR_AFFINITY2(MPIDR_AFFINITY2_GET(mpidr))
>>>| ICC_SGIR_INTID(vector)
>>>| ICC_SGIR_AFFINITY1(MPIDR_AFFINITY1_GET(mpidr))
>>> - | ICC_SGIR_CPU_TARGET_LIST(1);
>>> + | ICC_SGIR_CPU_TARGET_LIST(targets);
>> I think my processor filter todo just above this code will need to be 
>> addressed along with this change for correct behavior on non-core 0 runs of 
>> tm27.
> Yes, I thought about non-core 0 test runs too, however, I guess a lot more 
> things will pop up if someone does this the first time. We could replace the 
> 1 with an 1 << (arm_cp15_get_multiprocessor_affinity() & 0xff).

That sounds good for the time being. I'll work on a patch to address the filter 
issues.

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

Re: [PATCH v2] bsps: Fix GICv3 arm_gic_trigger_sgi()

2020-12-10 Thread Sebastian Huber 

On 10/12/2020 14:26, Kinsey Moore wrote:


I think my processor filter todo just above this code will need to be addressed 
along with this change for correct behavior on non-core 0 runs of tm27.

Yes, I thought about non-core 0 test runs too, however, I guess a lot more things will 
pop up if someone does this the first time. We could replace the 1 with an 1 << 
(arm_cp15_get_multiprocessor_affinity() & 0xff).

That sounds good for the time being. I'll work on a patch to address the filter 
issues.


I removed the filter feature here:

https://lists.rtems.org/pipermail/devel/2020-December/063707.html

We could add a separate function

arm_gic_sgi_broadcast_to_other()

if needed.

--
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 v2] bsps: Fix GICv3 arm_gic_trigger_sgi()

2020-12-10 Thread Kinsey Moore 
-Original Message-
From: Sebastian Huber  
Sent: Thursday, December 10, 2020 07:31
To: Kinsey Moore ; devel@rtems.org
Subject: Re: [PATCH v2] bsps: Fix GICv3 arm_gic_trigger_sgi()

> I removed the filter feature here:
>
> https://lists.rtems.org/pipermail/devel/2020-December/063707.html
>
> We could add a separate function
>
> arm_gic_sgi_broadcast_to_other()
>
> if needed.

Those changes look good to me. 

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

[PATCH 1/2] bsps: Add GICv3 arm_gic_irq_processor_count()

2020-12-10 Thread Sebastian Huber 
Update #4202.
---
 bsps/include/dev/irq/arm-gic-irq.h |  7 +--
 bsps/shared/dev/irq/arm-gicv2.c|  7 +++
 bsps/shared/dev/irq/arm-gicv3.c| 27 +++
 3 files changed, 35 insertions(+), 6 deletions(-)

diff --git a/bsps/include/dev/irq/arm-gic-irq.h 
b/bsps/include/dev/irq/arm-gic-irq.h
index 34bf34353e..d4b197bbb7 100644
--- a/bsps/include/dev/irq/arm-gic-irq.h
+++ b/bsps/include/dev/irq/arm-gic-irq.h
@@ -116,12 +116,7 @@ void arm_interrupt_handler_dispatch(rtems_vector_number 
vector);
  */
 void gicvx_interrupt_dispatch(void);
 
-static inline uint32_t arm_gic_irq_processor_count(void)
-{
-  volatile gic_dist *dist = ARM_GIC_DIST;
-
-  return GIC_DIST_ICDICTR_CPU_NUMBER_GET(dist->icdictr) + 1;
-}
+uint32_t arm_gic_irq_processor_count(void);
 
 void arm_gic_irq_initialize_secondary_cpu(void);
 
diff --git a/bsps/shared/dev/irq/arm-gicv2.c b/bsps/shared/dev/irq/arm-gicv2.c
index bd614bc1d8..97f397dffd 100644
--- a/bsps/shared/dev/irq/arm-gicv2.c
+++ b/bsps/shared/dev/irq/arm-gicv2.c
@@ -269,3 +269,10 @@ void arm_gic_trigger_sgi(rtems_vector_number vector, 
uint32_t targets)
 #endif
 | GIC_DIST_ICDSGIR_SGIINTID(vector);
 }
+
+uint32_t arm_gic_irq_processor_count(void)
+{
+  volatile gic_dist *dist = ARM_GIC_DIST;
+
+  return GIC_DIST_ICDICTR_CPU_NUMBER_GET(dist->icdictr) + 1;
+}
diff --git a/bsps/shared/dev/irq/arm-gicv3.c b/bsps/shared/dev/irq/arm-gicv3.c
index 520a728170..a7170006b6 100644
--- a/bsps/shared/dev/irq/arm-gicv3.c
+++ b/bsps/shared/dev/irq/arm-gicv3.c
@@ -354,3 +354,30 @@ void arm_gic_trigger_sgi(rtems_vector_number vector, 
uint32_t targets)
 #endif
   WRITE64_SR(ICC_SGI1, value);
 }
+
+uint32_t arm_gic_irq_processor_count(void)
+{
+  volatile gic_dist *dist = ARM_GIC_DIST;
+  uint32_t cpu_count;
+
+  if ((dist->icddcr & GIC_DIST_ICDDCR_ARE_S) == 0) {
+cpu_count = GIC_DIST_ICDICTR_CPU_NUMBER_GET(dist->icdictr) + 1;
+  } else {
+int i;
+
+/* Assume that an interrupt export port exists */
+cpu_count = 0;
+
+for (i = 0; i < CPU_MAXIMUM_PROCESSORS; ++i) {
+  volatile gic_redist *redist = gicv3_get_redist(i);
+
+  if ((redist->icrtyper & GIC_REDIST_ICRTYPER_LAST) != 0) {
+break;
+  }
+
+  ++cpu_count;
+}
+  }
+
+  return cpu_count;
+}
-- 
2.26.2

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

[PATCH 2/2] bsps: Remove gicvx_interrupt_dispatch()

2020-12-10 Thread Sebastian Huber 
Avoid one level of indirection.

Update #4202.
---
 bsps/aarch64/shared/irq/irq-arm-gicvx-aarch64.c | 5 -
 bsps/arm/shared/irq/irq-arm-gicvx-aarch32.c | 5 -
 bsps/include/dev/irq/arm-gic-irq.h  | 6 --
 bsps/shared/dev/irq/arm-gicv2.c | 2 +-
 bsps/shared/dev/irq/arm-gicv3.c | 2 +-
 5 files changed, 2 insertions(+), 18 deletions(-)

diff --git a/bsps/aarch64/shared/irq/irq-arm-gicvx-aarch64.c 
b/bsps/aarch64/shared/irq/irq-arm-gicvx-aarch64.c
index 67839118e1..5caf717bf1 100644
--- a/bsps/aarch64/shared/irq/irq-arm-gicvx-aarch64.c
+++ b/bsps/aarch64/shared/irq/irq-arm-gicvx-aarch64.c
@@ -57,8 +57,3 @@ void arm_interrupt_facility_set_exception_handler(void)
 _AArch64_Exception_interrupt_nest
   );
 }
-
-void bsp_interrupt_dispatch(void)
-{
-  gicvx_interrupt_dispatch();
-}
diff --git a/bsps/arm/shared/irq/irq-arm-gicvx-aarch32.c 
b/bsps/arm/shared/irq/irq-arm-gicvx-aarch32.c
index b9267aecba..7c0462d04d 100644
--- a/bsps/arm/shared/irq/irq-arm-gicvx-aarch32.c
+++ b/bsps/arm/shared/irq/irq-arm-gicvx-aarch32.c
@@ -54,8 +54,3 @@ void arm_interrupt_facility_set_exception_handler(void)
 _ARMV4_Exception_interrupt
   );
 }
-
-void bsp_interrupt_dispatch(void)
-{
-  gicvx_interrupt_dispatch();
-}
diff --git a/bsps/include/dev/irq/arm-gic-irq.h 
b/bsps/include/dev/irq/arm-gic-irq.h
index d4b197bbb7..5270331624 100644
--- a/bsps/include/dev/irq/arm-gic-irq.h
+++ b/bsps/include/dev/irq/arm-gic-irq.h
@@ -110,12 +110,6 @@ void arm_interrupt_facility_set_exception_handler(void);
  */
 void arm_interrupt_handler_dispatch(rtems_vector_number vector);
 
-/**
- * This is the GICv1/GICv2/GICv3 interrupt dispatcher that is to be called 
from the
- * architecture-specific implementation of the IRQ handler.
- */
-void gicvx_interrupt_dispatch(void);
-
 uint32_t arm_gic_irq_processor_count(void);
 
 void arm_gic_irq_initialize_secondary_cpu(void);
diff --git a/bsps/shared/dev/irq/arm-gicv2.c b/bsps/shared/dev/irq/arm-gicv2.c
index 97f397dffd..74989a4de5 100644
--- a/bsps/shared/dev/irq/arm-gicv2.c
+++ b/bsps/shared/dev/irq/arm-gicv2.c
@@ -49,7 +49,7 @@
 #define CPUIF_ICCICR GIC_CPUIF_ICCICR_ENABLE
 #endif
 
-void gicvx_interrupt_dispatch(void)
+void bsp_interrupt_dispatch(void)
 {
   volatile gic_cpuif *cpuif = GIC_CPUIF;
   uint32_t icciar = cpuif->icciar;
diff --git a/bsps/shared/dev/irq/arm-gicv3.c b/bsps/shared/dev/irq/arm-gicv3.c
index a7170006b6..c024e58df3 100644
--- a/bsps/shared/dev/irq/arm-gicv3.c
+++ b/bsps/shared/dev/irq/arm-gicv3.c
@@ -143,7 +143,7 @@ static volatile gic_sgi_ppi *gicv3_get_sgi_ppi(uint32_t 
cpu_index)
 (BSP_ARM_GIC_REDIST_BASE + cpu_index * 0x2 + 0x1);
 }
 
-void gicvx_interrupt_dispatch(void)
+void bsp_interrupt_dispatch(void)
 {
   uint32_t icciar = READ_SR(ICC_IAR1);
   rtems_vector_number vector = GIC_CPUIF_ICCIAR_ACKINTID_GET(icciar);
-- 
2.26.2

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

[PATCH] arm: Optimize arm_interrupt_disable()

2020-12-10 Thread Sebastian Huber 
Update #4202.
---
 cpukit/score/cpu/arm/include/rtems/score/cpu.h | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpu.h 
b/cpukit/score/cpu/arm/include/rtems/score/cpu.h
index 8a8e8cc617..e5b23e7100 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/cpu.h
@@ -276,8 +276,6 @@ static inline uint32_t arm_interrupt_disable( void )
   uint32_t level;
 
 #if defined(ARM_MULTILIB_ARCH_V4)
-  uint32_t arm_switch_reg;
-
   /*
* Disable only normal interrupts (IRQ).
*
@@ -292,6 +290,16 @@ static inline uint32_t arm_interrupt_disable( void )
* operating system support for a FIQ, she can trigger a software interrupt 
and
* service the request in a two-step process.
*/
+#if __ARM_ARCH >= 7
+  __asm__ volatile (
+"mrs %0, cpsr\n"
+"cpsid i\n"
+"isb"
+: "=&r" (level)
+  );
+#else
+  uint32_t arm_switch_reg;
+
   __asm__ volatile (
 ARM_SWITCH_TO_ARM
 "mrs %[level], cpsr\n"
@@ -300,6 +308,7 @@ static inline uint32_t arm_interrupt_disable( void )
 ARM_SWITCH_BACK
 : [arm_switch_reg] "=&r" (arm_switch_reg), [level] "=&r" (level)
   );
+#endif
 #elif defined(ARM_MULTILIB_ARCH_V7M)
   uint32_t basepri = 0x80;
 
-- 
2.26.2

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

RE: [PATCH v1 0/1] bsps/arm: Fix MMU small pages support

2020-12-10 Thread Jan.Sommer 
If there are no objections, could someone please push the changes?

Cheers, 

Jan

> -Original Message-
> From: Sommer, Jan
> Sent: Tuesday, November 24, 2020 9:41 AM
> To: devel@rtems.org
> Cc: Sommer, Jan 
> Subject: [PATCH v1 0/1] bsps/arm: Fix MMU small pages support
> 
> Following the discussion on the mailinglist
> (https://lists.rtems.org/pipermail/users/2020-November/067978.html) here
> is a patch which rounds the address range of a section only to next 4kiB
> boundary for the ARM MMU if small pages are enabled.
> 
> This should close the following tickets:
> - https://devel.rtems.org/ticket/4184
> - https://devel.rtems.org/ticket/4185
> 
> Best regards,
> 
>  Jan
> 
> Jan Sommer (1):
>   bsps/arm: Fix MMU small pages support
> 
>  bsps/arm/include/bsp/arm-cp15-start.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --
> 2.17.1

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

[PATCH 1/2] tm27: Use generic cpu index accessor

2020-12-10 Thread Kinsey Moore 
The arm_cp15 function for accessing the current CPU index is specific
to ARMv7 while this header is used for ARMv8 as well. Instead, use a
generic accessor that is part of the standard CPU API.
---
 bsps/include/dev/irq/arm-gic-tm27.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/bsps/include/dev/irq/arm-gic-tm27.h 
b/bsps/include/dev/irq/arm-gic-tm27.h
index ca3663a0f8..fde3e6392c 100644
--- a/bsps/include/dev/irq/arm-gic-tm27.h
+++ b/bsps/include/dev/irq/arm-gic-tm27.h
@@ -31,7 +31,6 @@
 
 #include 
 #include 
-#include 
 
 #define MUST_WAIT_FOR_INTERRUPT 1
 
@@ -80,7 +79,7 @@ static inline void Cause_tm27_intr(void)
 {
   rtems_status_code sc = arm_gic_irq_generate_software_irq(
 ARM_GIC_TM27_IRQ_LOW,
-1U << (arm_cp15_get_multiprocessor_affinity() & 0xff)
+1U << _SMP_Get_current_processor()
   );
   assert(sc == RTEMS_SUCCESSFUL);
 }
@@ -94,7 +93,7 @@ static inline void Lower_tm27_intr(void)
 {
   rtems_status_code sc = arm_gic_irq_generate_software_irq(
 ARM_GIC_TM27_IRQ_HIGH,
-1U << (arm_cp15_get_multiprocessor_affinity() & 0xff)
+1U << _SMP_Get_current_processor()
   );
   assert(sc == RTEMS_SUCCESSFUL);
 }
-- 
2.20.1

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

[PATCH 2/2] bsps/gicv3: Resolve build warnings on 64bit

2020-12-10 Thread Kinsey Moore 
---
 bsps/shared/dev/irq/arm-gicv3.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bsps/shared/dev/irq/arm-gicv3.c b/bsps/shared/dev/irq/arm-gicv3.c
index 520a728170..db0ad5b952 100644
--- a/bsps/shared/dev/irq/arm-gicv3.c
+++ b/bsps/shared/dev/irq/arm-gicv3.c
@@ -134,13 +134,13 @@
 static volatile gic_redist *gicv3_get_redist(uint32_t cpu_index)
 {
   return (volatile gic_redist *)
-(BSP_ARM_GIC_REDIST_BASE + cpu_index * 0x2);
+((char*)BSP_ARM_GIC_REDIST_BASE + cpu_index * 0x2);
 }
 
 static volatile gic_sgi_ppi *gicv3_get_sgi_ppi(uint32_t cpu_index)
 {
   return (volatile gic_sgi_ppi *)
-(BSP_ARM_GIC_REDIST_BASE + cpu_index * 0x2 + 0x1);
+((char*)BSP_ARM_GIC_REDIST_BASE + cpu_index * 0x2 + 0x1);
 }
 
 void gicvx_interrupt_dispatch(void)
-- 
2.20.1

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

Re: CMake support

2020-12-10 Thread Robin Müller 
Hello,

I created a repository on github for the first version of what a CMake
support for RTEMS might look like:

https://github.com/rmspacefish/rtems-cmake

I tried to extract generic components like determining library paths into
functions  (RTEMSGeneric.cmake)
and there is a hardware specific file where flags for specific
BSPs/Architectures can be set (RTEMSHardware.cmake).

I was able to compile both the hello project and my STM32 blinky project
with really similar and short CMake files which simply call
rtems_general_config.
with a simple command like

cmake -DRTEMS_INST=$RTEMS_INST -DRTEMS_BSP=arm/stm32h7

or

cmake -DRTEMS_INST=$RTEMS_INST -DRTEMS_BSP=sparc/erc32

and then cmake --build .

I made a test repository containing everything :
https://github.com/rmspacefish/rtems-demo

Maybe this could be a part of the RTEMS repositories? In any case, I think
it can help people who would like to build their application
with CMake. The hello world example for CMake would be similar to building
the waf example for the sparc/erc32, with the difference that the
CMake support would have to be cloned and the build commands are a little
bit different.

Kind Regards
Robin


On Thu, 10 Dec 2020 at 03:26, Chris Johns  wrote:

> On 10/12/20 1:18 am, Joel Sherrill wrote:
> > As I read this thread, this morning, it occurred to me that the Users
> > Manual needs a chapter on build systems for end user applications.
> > It needs to cover fetching the settings from the pkgconfig files and
> using
> > waf, old Makefile infrastructure, etc. Guidance on using cmake, scons,
> > meson, Eclipse managed builds, and Visual Studio would probably be
> > of benefit. Or at least someone may care about each build system. Likely
> > no one individual cares about more than one or two. :)
>
> +1
>
> In this section ...
>
>
> https://docs.rtems.org/branches/master/user/exe/executables.html#building-an-application
>
> Chris
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: CMake support

2020-12-10 Thread Chris Johns 
On 11/12/20 8:51 am, Robin Müller wrote:
> Hello,
> 
> I created a repository on github for the first version of what a CMake support
> for RTEMS might look like:
> 
> https://github.com/rmspacefish/rtems-cmake
> 
> 

Awesome and thanks. :)

> I tried to extract generic components like determining library paths into
> functions  (RTEMSGeneric.cmake)
> and there is a hardware specific file where flags for specific
> BSPs/Architectures can be set (RTEMSHardware.cmake).
> 
> I was able to compile both the hello project and my STM32 blinky project with
> really similar and short CMake files which simply call rtems_general_config.
> with a simple command like
> 
> cmake -DRTEMS_INST=$RTEMS_INST -DRTEMS_BSP=arm/stm32h7

Would it be possible to align the naming to be consistent with the names we
currently have? We use --rtems-tools for the path to the tools so would
RTEMS_TOOLS work?

We also provide the ability to specify where RTEMS (the RTEMS BSP) is installed.
In some configurations we have a prefix, where the application or library being
built are installed plus the RTEMS tools path and the RTEMS BSP path. They can
all be the same or different.

I am not sure what cmake does for the prefix so I will use PREFIX in my 
examples:

 cmake -DPREFIX=/install-point -DRTEMS_BSP=arm/stm32h7

Internally RTEMS_TOOLS and RTEMS would be set to PREFIX.

 cmake -DPREFIX=/install-point -DRTEMS_TOOLS=/tools-path -DRTEMS_BSP=arm/stm32h7

RTEMS_TOOLS is defined and RTEMS is set to RTEMS_TOOLS.

Finally we can have:

 cmake -DPREFIX=/install-path \
   -DRTEMS_TOOLS=/tools-path
   -DRTEMS=/bsp-path \
   -DRTEMS_BSP=arm/stm32h7

All are left as defined on the command line.

We have this separation so you can build a set of tools and build different
branches of RTEMS and then different branches of the application or library for
any of those combinations. A typical user will use the first or second option
and if testing new releases or versions you can separate out the various paths.
Separating the paths lets you some parts without having to build all the parts.

> or
> 
> cmake -DRTEMS_INST=$RTEMS_INST -DRTEMS_BSP=sparc/erc32
> 
> and then cmake --build .
> 
> I made a test repository containing everything :
> https://github.com/rmspacefish/rtems-demo
> 
> 
> Maybe this could be a part of the RTEMS repositories? 

This could be possible. It will come down to people using the package and the
demand. The rtems_waf package is a top level RTEMS repo because it is used in
libbsd and examples.

The rtems-examples repo maybe be a good place to look at adding support and
making it visible to the wider RTEMS community. I am not sure if this would be a
submodule to github or not. I would love to hear what others think.

> In any case, I think it
> can help people who would like to build their application
> with CMake. The hello world example for CMake would be similar to building the
> waf example for the sparc/erc32, with the difference that the
> CMake support would have to be cloned and the build commands are a little bit
> different.

This is a really great start and I thank you for it. We are open to supporting
all build systems. It is about individuals providing the support and then being
thee to maintain it over a period of time.

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

Re: CMake support

2020-12-10 Thread Joel Sherrill 
On Thu, Dec 10, 2020 at 5:58 PM Chris Johns  wrote:

> On 11/12/20 8:51 am, Robin Müller wrote:
> > Hello,
> >
> > I created a repository on github for the first version of what a CMake
> support
> > for RTEMS might look like:
> >
> > https://github.com/rmspacefish/rtems-cmake
> > 
> >
>
> Awesome and thanks. :)
>

Agreed. Bear with us being picky. We want things to be as
consistent as possible across BSPs, architectures, RTEMS versions,
and (hopefully) build systems.


> > I tried to extract generic components like determining library paths into
> > functions  (RTEMSGeneric.cmake)
> > and there is a hardware specific file where flags for specific
> > BSPs/Architectures can be set (RTEMSHardware.cmake).
> >
> > I was able to compile both the hello project and my STM32 blinky project
> with
> > really similar and short CMake files which simply call
> rtems_general_config.
> > with a simple command like
> >
> > cmake -DRTEMS_INST=$RTEMS_INST -DRTEMS_BSP=arm/stm32h7
>
> Would it be possible to align the naming to be consistent with the names we
> currently have? We use --rtems-tools for the path to the tools so would
> RTEMS_TOOLS work?
>
> We also provide the ability to specify where RTEMS (the RTEMS BSP) is
> installed.
> In some configurations we have a prefix, where the application or library
> being
> built are installed plus the RTEMS tools path and the RTEMS BSP path. They
> can
> all be the same or different.
>
> I am not sure what cmake does for the prefix so I will use PREFIX in my
> examples:
>
>  cmake -DPREFIX=/install-point -DRTEMS_BSP=arm/stm32h7
>
> Internally RTEMS_TOOLS and RTEMS would be set to PREFIX.
>
>  cmake -DPREFIX=/install-point -DRTEMS_TOOLS=/tools-path
> -DRTEMS_BSP=arm/stm32h7
>
> RTEMS_TOOLS is defined and RTEMS is set to RTEMS_TOOLS.
>
> Finally we can have:
>
>  cmake -DPREFIX=/install-path \
>-DRTEMS_TOOLS=/tools-path
>-DRTEMS=/bsp-path \
>-DRTEMS_BSP=arm/stm32h7
>
> All are left as defined on the command line.
>
> We have this separation so you can build a set of tools and build different
> branches of RTEMS and then different branches of the application or
> library for
> any of those combinations. A typical user will use the first or second
> option
> and if testing new releases or versions you can separate out the various
> paths.
> Separating the paths lets you some parts without having to build all the
> parts.
>
> > or
> >
> > cmake -DRTEMS_INST=$RTEMS_INST -DRTEMS_BSP=sparc/erc32
> >
> > and then cmake --build .
> >
> > I made a test repository containing everything :
> > https://github.com/rmspacefish/rtems-demo
> > 
> >
> > Maybe this could be a part of the RTEMS repositories?
>
> This could be possible. It will come down to people using the package and
> the
> demand. The rtems_waf package is a top level RTEMS repo because it is used
> in
> libbsd and examples.
>
> The rtems-examples repo maybe be a good place to look at adding support and
> making it visible to the wider RTEMS community. I am not sure if this
> would be a
> submodule to github or not. I would love to hear what others think.
>

If it is just an example, I'd prefer not to have another git repo. But if
it turns out
to work like the waf where you can close the rtems_cmake repo as a
submodule,
execute a couple of commands, and poof you can build an application, I'd be
ok
with it being a repo. I hope that makes sense -- example vs reusable
infrastructure.

Thinking long term, when we have examples, not infrastructure,
rtems-examples could have a build_systems subdirectory and
then cmake, meson, scons, etc.

>
> > In any case, I think it
> > can help people who would like to build their application
> > with CMake. The hello world example for CMake would be similar to
> building the
> > waf example for the sparc/erc32, with the difference that the
> > CMake support would have to be cloned and the build commands are a
> little bit
> > different.
>
> This is a really great start and I thank you for it. We are open to
> supporting
> all build systems. It is about individuals providing the support and then
> being
> thee to maintain it over a period of time.
>

+1

--joel

>
> 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-docs commit] c-user: Generate Timer Manager documentation

2020-12-10 Thread Chris Johns 


On 10/12/20 4:41 pm, Sebastian Huber wrote:
> On 10/12/2020 03:24, Chris Johns wrote:
> 
>> On 9/12/20 7:20 pm, Sebastian Huber wrote:
>>> Module:    rtems-docs
>>> Branch:    master
>>> Commit:    d716c79070901195912526c6e49d43defad00bdd
>>> Changeset:
>>> http://git.rtems.org/rtems-docs/commit/?id=d716c79070901195912526c6e49d43defad00bdd
>>>
>>>
>>> Author:    Sebastian Huber 
>>> Date:  Wed Dec  2 08:17:12 2020 +0100
>>>
>>> c-user: Generate Timer Manager documentation
>>>
>>> The documentation is a consolidation of the comments in Doxygen markup
>>> and the documentation sources in Sphinx markup.  The documentation was
>>> transfered to interface specification items.  The documentation source
>>> files were generated from the items by a script.
>>>
>>> Update #3993.
>>>
>>> ---
>>>
>>>   c-user/timer/directives.rst   | 992 
>>> ++
>>>   c-user/timer/introduction.rst |  57 ++-
>>>   2 files changed, 674 insertions(+), 375 deletions(-)
>>>
>>> diff --git a/c-user/timer/directives.rst b/c-user/timer/directives.rst
>>> index d9b9877..d65f263 100644
>>> --- a/c-user/timer/directives.rst
>>> +++ b/c-user/timer/directives.rst
>>> @@ -1,463 +1,729 @@
>>>   .. SPDX-License-Identifier: CC-BY-SA-4.0
>>>   +.. Copyright (C) 2020 embedded brains GmbH 
>>> (http://www.embedded-brains.de)
>>>   .. Copyright (C) 1988, 2008 On-Line Applications Research Corporation 
>>> (OAR)
>>>   +.. 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
>>> +
>> We need a solution. I would prefer we resolve this before we add any more
>> instances of these links.
> I understand that cross-document links are a problem, however, these two links
> are in comments and thus don't show up in the generated documents. A link to 
> the
> bug reporting should always point to the latest information since there is 
> only
> one bug reporting procedure in the project at a time. The link to the howto
> could be branch-specific.

Yes I agree. My concern is a change in how master is hosted breaks the links.

>> Suggestions?
> We could add a script which performs some post processing after creation the 
> of
> the release branches.

What about 

https://www.rtems.org/support/bugs.html

If a redirect can be set up we could insulate these links from the location they
are.

Chris

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

Re: [PATCH 2/2] bsps/gicv3: Resolve build warnings on 64bit

2020-12-10 Thread Sebastian Huber 



On 10/12/2020 21:42, Kinsey Moore wrote:

---
  bsps/shared/dev/irq/arm-gicv3.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bsps/shared/dev/irq/arm-gicv3.c b/bsps/shared/dev/irq/arm-gicv3.c
index 520a728170..db0ad5b952 100644
--- a/bsps/shared/dev/irq/arm-gicv3.c
+++ b/bsps/shared/dev/irq/arm-gicv3.c
@@ -134,13 +134,13 @@
  static volatile gic_redist *gicv3_get_redist(uint32_t cpu_index)
  {
return (volatile gic_redist *)
-(BSP_ARM_GIC_REDIST_BASE + cpu_index * 0x2);
+((char*)BSP_ARM_GIC_REDIST_BASE + cpu_index * 0x2);
Ok, now I know why there was this (char *) cast. I am more in favour to 
cast this integer constant to (uintptr_t) to avoid the warning.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/2] tm27: Use generic cpu index accessor

2020-12-10 Thread Sebastian Huber 

On 10/12/2020 21:42, Kinsey Moore wrote:

The arm_cp15 function for accessing the current CPU index is specific
to ARMv7 while this header is used for ARMv8 as well. Instead, use a
generic accessor that is part of the standard CPU API.


I am fine with this fix, however, this is basically now the same 
approach as in my v2 patch:


https://lists.rtems.org/pipermail/devel/2020-December/063693.html

Since the tm27 test is configured to use only one CPU, the current 
processor is always 0.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1 0/1] bsps/arm: Fix MMU small pages support

2020-12-10 Thread Sebastian Huber 

On 10/12/2020 17:19, jan.som...@dlr.de wrote:

If there are no objections, could someone please push the changes?

Sorry for the delay, I checked them in.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-docs commit] c-user: Generate Timer Manager documentation

2020-12-10 Thread Sebastian Huber 

On 11/12/2020 01:35, Chris Johns wrote:

Suggestions?

We could add a script which performs some post processing after creation the of
the release branches.

What about 

https://www.rtems.org/support/bugs.html

If a redirect can be set up we could insulate these links from the location they
are.


I don't mind changing the link and regenerate the sources, but I think 
changing the documentation links is not good in general.


--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: What are level in the thread?

2020-12-10 Thread Richi Dubey 
Dear Dr. Sherrill,

Thank you for your answer. Your explanation has been helpful.

It would seem that we need a discussion of the types of critical sections,
> when they are used, and the difference between uniprocessor and symmetric
> processing configurations.

It'd be really helpful if someone can write about this in the
documentation.


This is a critical section which prevents thread context switches from
> occurring while the dispatch level is not zero. This is generally used so
> dispatching is deferred until the end of operations. It is also used so we
> do not attempt to switch to another thread while in the middle of an
> interrupt service routine

 Okay, so this is for the dispatch disable level, what about pin level? Is
it like a boolean value in some way, true for level 1 and false for 0?


On Sat, Dec 5, 2020 at 10:20 PM Joel Sherrill  wrote:

>
>
> On Sat, Dec 5, 2020, 12:15 AM Richi Dubey  wrote:
>
>> I tried searching it on Google and RTEMS Documentation, but couldn't find
>> anything that explains this.
>>
>> On Sat, Dec 5, 2020 at 11:34 AM Richi Dubey  wrote:
>>
>>> Hi,
>>>
>>> Can someone please help me understand what is meant by level? What is
>>> meant by the dispatch level and the pin level and other such definitions? I
>>> just want a high-level idea of what we achieve by having levels and why we
>>> need them.
>>>
>>
> This is a critical section which prevents thread context switches from
> occurring while the dispatch level is not zero. This is generally used so
> dispatching is deferred until the end of operations. It is also used so we
> do not attempt to switch to another thread while in the middle of an
> interrupt service routine
>
> I would think this was documented somewhere but honestly I don't know
> where.  If someone has a suggestion , then we should add it.
>
> It would seem that we need a discussion of the types of critical sections,
> when they are used, and the difference between uniprocessor and symmetric
> processing configurations.
>
>>
>>> Why do we have:
>>>
>>>  _Assert( cpu_self->thread_dispatch_disable_level == 1 );
>>>
>>> in some codes?
>>>
>>
> This means that the software should not be called when dispatching is
> disabled. This may mean not from an interrupt service routine although that
> is by implication since you could have checked the interrupt nest level.
> This can prevent some methods from being called from a user extension.
>
> --joel
>
>> ___
>> 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: Which threads execute _Thread_Handler ?

2020-12-10 Thread Richi Dubey 
Thanks for your replies.

Great suggestion about setting up a breakpoint at _Thread_Handler. After
setting the breakpoint, the code run by Strong_APA does not break, whereas
the default scheduler's code does break:



Default Scheduler (That executes correctly without error):

Thread 1 hit Breakpoint 7, Tasks (argument=0) at
/home/richi/quick-start/src/rtems/c/src/../../testsuites/tmtests/tm24/task1.c:110
110  Task_count++;
(gdb) b _Thread_Handler
Breakpoint 8 at 0x10a67e: file
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threadhandler.c,
line 88.
(gdb) c
Continuing.

Thread 1 hit Breakpoint 8, _Thread_Handler () at
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threadhandler.c:88
88  executing = _Thread_Executing;
(gdb)
Continuing.

Thread 1 hit Breakpoint 7, Tasks (argument=0) at
/home/richi/quick-start/src/rtems/c/src/../../testsuites/tmtests/tm24/task1.c:110
110  Task_count++;


Strong APA execution (The execution that fails/give error):

Thread 1 hit Breakpoint 7, Tasks (argument=0) at
/home/richi/quick-start/src/rtems/c/src/../../testsuites/tmtests/tm24/task1.c:110
110  Task_count++;
(gdb) b _Thread_Handler
Breakpoint 8 at 0x1086b2: file
/home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threadhandler.c,
line 88.
(gdb) c
Continuing.

Thread 1 hit Breakpoint 5, _Terminate



I am going to investigate the scheduler's role in this.

Thanks,
Richi.

On Mon, Dec 7, 2020 at 11:09 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 05/12/2020 07:13, Richi Dubey wrote:
>
> >
> > The stack trace for the thread looks like this:
> >
> > Tasks (entry function) -> rtems_task_wake_after
> > ->_Thread_Dispatch_direct -> _Thread_Do_dispatch (where the
> > _Context_switch function call lies), how can then the heir thread
> > start executing from the _Thread_Handler? I do not see it in the trace
> > at all.
> The context of new threads is set up by _Thread_Load_environment().
>
> --
> 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: Which threads execute _Thread_Handler ?

2020-12-10 Thread Richi Dubey 
Also, it's weird that neither of the code breaks on setting a breakpoint
at _Thread_Load_environment for the threads that have 'Tasks' as their
entry function.

On Fri, Dec 11, 2020 at 1:07 PM Richi Dubey  wrote:

> Thanks for your replies.
>
> Great suggestion about setting up a breakpoint at _Thread_Handler. After
> setting the breakpoint, the code run by Strong_APA does not break, whereas
> the default scheduler's code does break:
>
>
> 
> Default Scheduler (That executes correctly without error):
>
> Thread 1 hit Breakpoint 7, Tasks (argument=0) at
> /home/richi/quick-start/src/rtems/c/src/../../testsuites/tmtests/tm24/task1.c:110
> 110  Task_count++;
> (gdb) b _Thread_Handler
> Breakpoint 8 at 0x10a67e: file
> /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threadhandler.c,
> line 88.
> (gdb) c
> Continuing.
>
> Thread 1 hit Breakpoint 8, _Thread_Handler () at
> /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threadhandler.c:88
> 88  executing = _Thread_Executing;
> (gdb)
> Continuing.
>
> Thread 1 hit Breakpoint 7, Tasks (argument=0) at
> /home/richi/quick-start/src/rtems/c/src/../../testsuites/tmtests/tm24/task1.c:110
> 110  Task_count++;
> 
>
> Strong APA execution (The execution that fails/give error):
> 
> Thread 1 hit Breakpoint 7, Tasks (argument=0) at
> /home/richi/quick-start/src/rtems/c/src/../../testsuites/tmtests/tm24/task1.c:110
> 110  Task_count++;
> (gdb) b _Thread_Handler
> Breakpoint 8 at 0x1086b2: file
> /home/richi/quick-start/src/rtems/c/src/../../cpukit/score/src/threadhandler.c,
> line 88.
> (gdb) c
> Continuing.
>
> Thread 1 hit Breakpoint 5, _Terminate
>
> 
>
> I am going to investigate the scheduler's role in this.
>
> Thanks,
> Richi.
>
> On Mon, Dec 7, 2020 at 11:09 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> On 05/12/2020 07:13, Richi Dubey wrote:
>>
>> >
>> > The stack trace for the thread looks like this:
>> >
>> > Tasks (entry function) -> rtems_task_wake_after
>> > ->_Thread_Dispatch_direct -> _Thread_Do_dispatch (where the
>> > _Context_switch function call lies), how can then the heir thread
>> > start executing from the _Thread_Handler? I do not see it in the trace
>> > at all.
>> The context of new threads is set up by _Thread_Load_environment().
>>
>> --
>> 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