date:20230914

Re: [rtems commit] libdl: Add support to import base image TLS symbols

2023-09-14 Thread Chris Johns

On 14/9/2023 4:55 pm, Sebastian Huber wrote:
> On 14.09.23 08:34, Sebastian Huber wrote:
>> This seems to break the mips build:
>>
>> cpukit/libdl/rtl-tls.c:104:2: error: #error unsupported architecture
>>    104 | #error unsupported architecture
>>    |  ^
>>
> 
> Also the moxie and 64-bit powerpc (qoriq_e6500_64) no longer build with the
> error above.

Yes. It was decided this be a hard error so it gets fixed. The newlib TLS change
broke libdl and it is being fixed for the release. I have done what I can and
know about but some archs need help from those who know about it.

I am not sure about moxie, if it does not have TLS support it can disabled.

The issue I faced was no score interface to get the TLS base for a thread to
determine a symbol's offset. If we had that and something to say if TLS is
supported libdl would be easy to fix.

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

[PATCH] rtems: rtems_configuration_get_interrupt_stack_size()

2023-09-14 Thread Sebastian Huber

Fix rtems_configuration_get_interrupt_stack_size() for some code models.

The _ISR_Stack_size symbol has an arbitrary absolute address and may not
be representable in the code model used by the compiler.

Update #4953.
---
 cpukit/include/rtems/config.h|  2 +-
 cpukit/include/rtems/score/isr.h | 14 +-
 cpukit/score/src/isr.c   |  2 ++
 3 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/cpukit/include/rtems/config.h b/cpukit/include/rtems/config.h
index 8aef7d034b..8eee31053f 100644
--- a/cpukit/include/rtems/config.h
+++ b/cpukit/include/rtems/config.h
@@ -480,7 +480,7 @@ const char *rtems_get_version_string( void );
  * @endparblock
  */
 #define rtems_configuration_get_interrupt_stack_size() \
-  ((size_t) _ISR_Stack_size)
+  ((size_t) _ISR_Stack_size_object)
 
 /* Generated from spec:/rtems/config/if/get-maximum-extensions */
 
diff --git a/cpukit/include/rtems/score/isr.h b/cpukit/include/rtems/score/isr.h
index bb1f3cee50..96ad816245 100644
--- a/cpukit/include/rtems/score/isr.h
+++ b/cpukit/include/rtems/score/isr.h
@@ -98,13 +98,25 @@ extern ISR_Handler_entry _ISR_Vector_table[ 
CPU_INTERRUPT_NUMBER_OF_VECTORS ];
 #endif
 
 /**
- * @brief Global symbol with a value equal to the configure interrupt stack 
size.
+ * @brief Provides the configured interrupt stack size through an address.
+ *
+ * The address of this global symbol is equal to the configured interrupt stack
+ * size.  The address of this symbol has an arbitrary value an may not be
+ * representable in the code model used by the compiler.
  *
  * This global symbol is defined by the application configuration option
  * CONFIGURE_INIT_TASK_STACK_SIZE via .
  */
 RTEMS_DECLARE_GLOBAL_SYMBOL( _ISR_Stack_size );
 
+/**
+ * @brief Provides the configured interrupt stack size through an object.
+ *
+ * This object is provided to avoid issues with the _ISR_Stack_size symbol
+ * address and the code model used by the compiler.
+ */
+extern const char * const volatile _ISR_Stack_size_object;
+
 /**
  * @brief The interrupt stack area begin.
  *
diff --git a/cpukit/score/src/isr.c b/cpukit/score/src/isr.c
index 75df00e228..7337028b0f 100644
--- a/cpukit/score/src/isr.c
+++ b/cpukit/score/src/isr.c
@@ -44,6 +44,8 @@
 #include 
 #include 
 
+const char * const volatile _ISR_Stack_size_object = _ISR_Stack_size;
+
 void _ISR_Handler_initialization( void )
 {
   uint32_t  cpu_max;
-- 
2.35.3

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

Re: [rtems commit] libdl: Add support to import base image TLS symbols

2023-09-14 Thread Sebastian Huber


On 14.09.23 09:12, Chris Johns wrote:

On 14/9/2023 4:55 pm, Sebastian Huber wrote:

On 14.09.23 08:34, Sebastian Huber wrote:

This seems to break the mips build:

cpukit/libdl/rtl-tls.c:104:2: error: #error unsupported architecture
    104 | #error unsupported architecture
    |  ^


Also the moxie and 64-bit powerpc (qoriq_e6500_64) no longer build with the
error above.

Yes. It was decided this be a hard error so it gets fixed. The newlib TLS change
broke libdl and it is being fixed for the release. I have done what I can and
know about but some archs need help from those who know about it.


An intentionally broken build is not really helpful. There are also 
other bugs left to fix, for example:


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

How can I check if my patches break the build if it is already broken?



I am not sure about moxie, if it does not have TLS support it can disabled.


moxie and mips don't have TLS support.



The issue I faced was no score interface to get the TLS base for a thread to
determine a symbol's offset. If we had that and something to say if TLS is
supported libdl would be easy to fix.


Why don't we add this interface if it simplifies things?

--
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: [rtems commit] libdl: Add support to import base image TLS symbols

2023-09-14 Thread Chris Johns

On 14/9/2023 5:20 pm, Sebastian Huber wrote:
> On 14.09.23 09:12, Chris Johns wrote:
>> On 14/9/2023 4:55 pm, Sebastian Huber wrote:
>>> On 14.09.23 08:34, Sebastian Huber wrote:
 This seems to break the mips build:

 cpukit/libdl/rtl-tls.c:104:2: error: #error unsupported architecture
     104 | #error unsupported architecture
     |  ^

>>> Also the moxie and 64-bit powerpc (qoriq_e6500_64) no longer build with the
>>> error above.
>> Yes. It was decided this be a hard error so it gets fixed. The newlib TLS 
>> change
>> broke libdl and it is being fixed for the release. I have done what I can and
>> know about but some archs need help from those who know about it.
> 
> An intentionally broken build is not really helpful.

Yes it is not ideal but leaving libdl broken with no one knowing is also not
helpful. We needed a circuit breaker.

> There are also other bugs left to fix, for example:
> 
> https://devel.rtems.org/ticket/4953
> 
> How can I check if my patches break the build if it is already broken?

Like I said it is not a prefect solution and we need to resolve this as a team.
I have done some of the hard work in libdl to get things under way but I need
help in the TLS score area.

>> I am not sure about moxie, if it does not have TLS support it can disabled.
> 
> moxie and mips don't have TLS support.
> 
>>
>> The issue I faced was no score interface to get the TLS base for a thread to
>> determine a symbol's offset. If we had that and something to say if TLS is
>> supported libdl would be easy to fix.
> 
> Why don't we add this interface if it simplifies things?

Yes please, that would be good. I do not know the TSL support well enough to do
a decent job of it.

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

Re: [rtems commit] libdl: Add support to import base image TLS symbols

2023-09-14 Thread Sebastian Huber


On 14.09.23 09:38, Chris Johns wrote:

The issue I faced was no score interface to get the TLS base for a thread to
determine a symbol's offset. If we had that and something to say if TLS is
supported libdl would be easy to fix.

Why don't we add this interface if it simplifies things?

Yes please, that would be good. I do not know the TSL support well enough to do
a decent job of it.


Which interface do you need?

--
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: [rtems commit] libdl: Add support to import base image TLS symbols

2023-09-14 Thread Chris Johns

On 14/9/2023 5:58 pm, Sebastian Huber wrote:
> On 14.09.23 09:38, Chris Johns wrote:
 The issue I faced was no score interface to get the TLS base for a thread 
 to
 determine a symbol's offset. If we had that and something to say if TLS is
 supported libdl would be easy to fix.
>>> Why don't we add this interface if it simplifies things?
>> Yes please, that would be good. I do not know the TSL support well enough to 
>> do
>> a decent job of it.
> 
> Which interface do you need?

A define that says TLS is support for an arch?

A call that returns the base address for an arch? I have added some in libdl:

https://git.rtems.org/rtems/tree/cpukit/libdl/rtl-tls.c

however having this in score would mean a new arch does not break libdl.

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

Re: [rtems commit] libdl: Add support to import base image TLS symbols

2023-09-14 Thread Sebastian Huber




On 14.09.23 10:51, Chris Johns wrote:

On 14/9/2023 5:58 pm, Sebastian Huber wrote:

On 14.09.23 09:38, Chris Johns wrote:

The issue I faced was no score interface to get the TLS base for a thread to
determine a symbol's offset. If we had that and something to say if TLS is
supported libdl would be easy to fix.

Why don't we add this interface if it simplifies things?

Yes please, that would be good. I do not know the TSL support well enough to do
a decent job of it.

Which interface do you need?

A define that says TLS is support for an arch?

A call that returns the base address for an arch? I have added some in libdl:

https://git.rtems.org/rtems/tree/cpukit/libdl/rtl-tls.c

however having this in score would mean a new arch does not break libdl.


Yes, this should be definitely added to the CPU port. What is the 
purpose of rtems_rtl_tls_get_base()? It seems to be unused.


--
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] cpukit/riscv : RISCV multitasking with non SMP

2023-09-14 Thread Sebastian Huber


Hello Kevin,

On 18.08.23 14:37, EYSSARTIER Kevin wrote:

Classified as: {OPEN}


Hello Sebastian,


The level shall be zero. If it is non-zero, then this is an application



bug resulting in the INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT



fatal error. This error happens also if you call operating system



services which block with interrupts disabled.


That is what I observed when calling printf. Is it a normal behavior ?

In that case, indeed my patch is useless.


I updated the sp37 test case. Could you please run this test case on 
your system without your changes?


If you call printf() with interrupts disabled or within an ISR, then you 
get this fatal error. printf() is a complex function which may even 
allocate dynamic memory in some cases.


--
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: [rtems commit] libdl: Add support to import base image TLS symbols

2023-09-14 Thread Joel Sherrill

On Thu, Sep 14, 2023 at 4:33 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 14.09.23 10:51, Chris Johns wrote:
> > On 14/9/2023 5:58 pm, Sebastian Huber wrote:
> >> On 14.09.23 09:38, Chris Johns wrote:
> > The issue I faced was no score interface to get the TLS base for a
> thread to
> > determine a symbol's offset. If we had that and something to say if
> TLS is
> > supported libdl would be easy to fix.
>  Why don't we add this interface if it simplifies things?
> >>> Yes please, that would be good. I do not know the TSL support well
> enough to do
> >>> a decent job of it.
> >> Which interface do you need?
> > A define that says TLS is support for an arch?
> >
> > A call that returns the base address for an arch? I have added some in
> libdl:
> >
> > https://git.rtems.org/rtems/tree/cpukit/libdl/rtl-tls.c
> >
> > however having this in score would mean a new arch does not break libdl.
>
> Yes, this should be definitely added to the CPU port. What is the
> purpose of rtems_rtl_tls_get_base()? It seems to be unused.
>

MIPS does not have TLS support. GCC generates a specific illegal
instruction and the exception handler does the right thing.

Is there a way to tell GCC to use a function call? That would be
much easier across all the secondary architectures.

--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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Add Formal Verification chapter v4

2023-09-14 Thread Gedare Bloom

Thanks, I left comments on your pull request.

On Wed, Sep 6, 2023 at 7:26 AM andrew.butterfi...@scss.tcd.ie
 wrote:
>
> Ping
>
> (I've let this sit a while  - time to wake it up!)
>
> 
> Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
> Lero@TCD, Head of Software Foundations & Verification Research Group
> School of Computer Science and Statistics,
> Room G.39, O'Reilly Institute, Trinity College, University of Dublin
> http://www.scss.tcd.ie/Andrew.Butterfield/ 
> 
> 
>
>
>
>
>
>
>
>
> -Original Message-
> From: devel mailto:devel-boun...@rtems.org>> on 
> behalf of "andrew.butterfi...@scss.tcd.ie 
> "  >
> Date: Tuesday 18 July 2023 at 13:54
> To: "rtems-de...@rtems.org " 
> mailto:rtems-de...@rtems.org>>
> Subject: Add Formal Verification chapter v4
>
>
> Dear all,
> I've attached a patch-set for v4 of the proposal to add a formal verification 
> chapter to the Software Engineering manual.
> (I can’t do git-mail)
>
>
> I've setup a pull-request at https://github.com/RTEMS/rtems-docs/pull/6 
>  for review purposes.
>
>
> Regards,
> Andrew
> 
> Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
> Lero@TCD, Head of Software Foundations & Verification Research Group
> School of Computer Science and Statistics,
> Room G.39, O'Reilly Institute, Trinity College, University of Dublin
> http://www.scss.tcd.ie/Andrew.Butterfield/ 
>  
>  
> ;>
> 
>
>
>
>
>
>
>
>
>
>
>
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Outdated list of BSPs in rtems-tools/config

2023-09-14 Thread oss

Hello Peter,

Am 13.09.23 um 19:22 schrieb Peter Dufault:

On Jul 25, 2023, at 10:14 , Joel Sherrill wrote:

Most of those are recent and from a lot of different people. GSoC, Kinsey,
you, Vijay or Chris, Karel, etc. But I wonder about that phycore_mpc5554. I
think it has been around a LONG time.

I'm cleaning my in-box, and I missed a reference to te Phycore-MPC5554 BSP in
July.

I am the one who added the Phycore-mpc5554 as a minor refinement to the Freescale MPC55xx
embedded board BSPs developed by "eb".

It *is* time to retire the Phytec board as that board is no longer available.

But, I hope we can keep it around for a while as I now need to work on a
follow-up to that BSP.

That thread was not about retiring or deprecating BSPs. It was about
some missing BSPs in the rtems-tools/config files. So if it is still
necessary, I don't think the BSP should be removed.

One of my clients uses the Phycore-MPC5554. They missed the end-of life
announcement for that board. They need to quickly update to something very
compatible, and a BSP based on the PHYTEC MPC5674F will work, the MPC5674F has
all the functionality they require without software changes.

I'd like to keep the Phycore-MPC5554 BSP alive and kicking while I develop
equivalent MPC5674F support.

OK for me.

A related question. I think "eb" has a "gwlcfm" target that uses this NXP architecture in one of
their products. "eb", are you planning another "gwlcfm", or are you done with that, and what
platform would you move to? I'd like to learn about an architecture that works as well as the old Motorola
architecture does without custom FPGA programming.

I think it's possible that a new batch of the gwlcfm hardware will be
manufactured in the next few years. But it's quite unlikely that the
software will get an upgrade.

The question about a good architecture is quite difficult because it's
always quite application specific.

For RTEMS work that I do, usually a customer already selected a chip
(most of the time some ARM). Therefore, I can't pick a platform that
often. For eb-projects, we usually use NXP or ST chips. On the NXP it
would be i.MX or now also i.MXRT and for ST it's one of the many STM32
chips.

Personally I would like to play a bit with Risc-V chips. But I haven't
found any time yet. Additionally, it seems that there are still not that
many manufacturers that produce Risc-V chips.

If I leave the old Motorola PowerPC's architecture targeted at engine control,
I will miss how the ADC DMA chain works together with the eTPU and also
schedules the output so cleanly do background motor control, and other timing
intensive applications, so that the main CPU is free to e.g. run RTEMS (and in
my case position servo control).

Difficult. Best bet is some NXP chip because they have quite some
peripherals that are still based on the Motorola chips. But I think you
know these chips already and it seems that they are not a good enough
replacement. Otherwise, you wouldn't ask.

At the moment a lot of chips start to provide two different ARM cores.
One bigger (often Cortex-A; sometimes multicore) and one smaller one
(most of the time Cortex-M). I haven't used both CPUs of these dual CPU
systems yet. But in theory they should allow some quite nice division of
tasks: The small CPU can handle the timing intensive application (maybe
with some bare metal code). The second CPU can handle higher level
control and communication. It would be interesting to implement
something like that.

Best regards

Christian

Peter
-
Peter Dufault
HD Associates, Inc. Software and System Engineering

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

Re: Outdated list of BSPs in rtems-tools/config

2023-09-14 Thread Thomas DOERFLER


Hello Peter,

just my two cents regarding eTPU: NXP has more or less left the PowerPC 
architecture and favor ARM for automotive applications.


But the MPC5xxx controllers were developed in some sort of cooperation 
with ST microelectronics. And ST is still actively playing with this 
family. E.g. the SPC564 is still equipped with the eTPU. So the legend 
lives on ;-)


wkr,

Thomas.

Am 14.09.23 um 21:22 schrieb o...@c-mauderer.de:

Hello Peter,

Am 13.09.23 um 19:22 schrieb Peter Dufault:




On Jul 25, 2023, at 10:14 , Joel Sherrill  wrote:

Most of those are recent and from a lot of different people. GSoC, 
Kinsey,
you, Vijay or Chris, Karel, etc. But I wonder about that 
phycore_mpc5554. I

think it has been around a LONG time.



I'm cleaning my in-box, and I missed a reference to te Phycore-MPC5554 
BSP in July.


I am the one who added the Phycore-mpc5554 as a minor refinement to 
the Freescale MPC55xx embedded board BSPs developed by "eb".


It *is* time to retire the Phytec board as that board is no longer 
available.


But, I hope we can keep it around for a while as I now need to work on 
a follow-up to that BSP.


That thread was not about retiring or deprecating BSPs. It was about 
some missing BSPs in the rtems-tools/config files. So if it is still 
necessary, I don't think the BSP should be removed.




One of my clients uses the Phycore-MPC5554.  They missed the end-of 
life announcement for that board. They need to quickly update to 
something very compatible, and a BSP based on the PHYTEC MPC5674F will 
work, the MPC5674F has all the functionality they require without 
software changes.


I'd like to keep the Phycore-MPC5554 BSP alive and kicking while I 
develop equivalent MPC5674F support.




OK for me.

A related question. I think "eb" has a "gwlcfm" target that uses this 
NXP architecture in one of their products.  "eb", are you planning 
another "gwlcfm", or are you done with that, and what platform would 
you move to?  I'd like to learn about an architecture that works as 
well as the old Motorola architecture does without custom FPGA 
programming.




I think it's possible that a new batch of the gwlcfm hardware will be 
manufactured in the next few years. But it's quite unlikely that the 
software will get an upgrade.


The question about a good architecture is quite difficult because it's 
always quite application specific.


For RTEMS work that I do, usually a customer already selected a chip 
(most of the time some ARM). Therefore, I can't pick a platform that 
often. For eb-projects, we usually use NXP or ST chips. On the NXP it 
would be i.MX or now also i.MXRT and for ST it's one of the many STM32 
chips.


Personally I would like to play a bit with Risc-V chips. But I haven't 
found any time yet. Additionally, it seems that there are still not that 
many manufacturers that produce Risc-V chips.



If I leave the old Motorola PowerPC's architecture targeted at engine 
control, I will miss how the ADC DMA chain works together with the 
eTPU and also schedules the output so cleanly do background motor 
control, and other timing intensive applications, so that the main CPU 
is free to e.g. run RTEMS (and in my case position servo control).


Difficult. Best bet is some NXP chip because they have quite some 
peripherals that are still based on the Motorola chips. But I think you 
know these chips already and it seems that they are not a good enough 
replacement. Otherwise, you wouldn't ask.


At the moment a lot of chips start to provide two different ARM cores. 
One bigger (often Cortex-A; sometimes multicore) and one smaller one 
(most of the time Cortex-M). I haven't used both CPUs of these dual CPU 
systems yet. But in theory they should allow some quite nice division of 
tasks: The small CPU can handle the timing intensive application (maybe 
with some bare metal code). The second CPU can handle higher level 
control and communication. It would be interesting to implement 
something like that.


Best regards

Christian



Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering




___
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


--
embedded brains GmbH & Co. KG
Herr Thomas DOERFLER
Dornierstr. 4
82178 Puchheim
Germany
email: thomas.doerf...@embedded-brains.de
phone: +49- 89-18 94 741 -12
mobil: +49-176-15 22 06 - 02

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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: Outdated list of BSPs in rtems-tools/config

2023-09-14 Thread Karel Gardas




  Hello Thomas,

On 9/14/23 21:35, Thomas DOERFLER wrote:

Hello Peter,

just my two cents regarding eTPU: NXP has more or less left the PowerPC 
architecture and favor ARM for automotive applications.


But the MPC5xxx controllers were developed in some sort of cooperation 
with ST microelectronics. And ST is still actively playing with this 
family. E.g. the SPC564 is still equipped with the eTPU. So the legend 
lives on ;-)


indeed, but even ST Micro probably plans to migrate their customers 
slowly to their brand new ARM-based chips for automotive: Stellar 32-bit 
Automotive MCUs [1]. Although I must add that "Longetivity" is extended 
to 20 years for your mentioned SPC56x, whatever that means exactly...


Anyway, I'm afraid, sun is setting on PPC even in automotive business...

Cheers,
Karel

[1]: 
https://www.st.com/en/automotive-microcontrollers/stellar-32-bit-automotive-mcus.html

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

Re: [rtems commit] libdl: Add support to import base image TLS symbols

2023-09-14 Thread Chris Johns

On 14/9/2023 7:33 pm, Sebastian Huber wrote:
> On 14.09.23 10:51, Chris Johns wrote:
>> On 14/9/2023 5:58 pm, Sebastian Huber wrote:
>>> On 14.09.23 09:38, Chris Johns wrote:
>> The issue I faced was no score interface to get the TLS base for a 
>> thread to
>> determine a symbol's offset. If we had that and something to say if TLS 
>> is
>> supported libdl would be easy to fix.
> Why don't we add this interface if it simplifies things?
 Yes please, that would be good. I do not know the TSL support well enough 
 to do
 a decent job of it.
>>> Which interface do you need?
>> A define that says TLS is support for an arch?
>>
>> A call that returns the base address for an arch? I have added some in libdl:
>>
>> https://git.rtems.org/rtems/tree/cpukit/libdl/rtl-tls.c
>>
>> however having this in score would mean a new arch does not break libdl.
> 
> Yes, this should be definitely added to the CPU port. What is the purpose of
> rtems_rtl_tls_get_base()? It seems to be unused.

It is used by the symbol table loader so is referenced in the symbol table
generated code ...

https://git.rtems.org/rtems-tools/tree/linkers/rtems-syms.cpp#n66
https://git.rtems.org/rtems-tools/tree/linkers/rtems-syms.cpp#n319

A TLS symbol is an offset into the TLS area. I encountered two problems. First I
could not find a way to equate a TLS symbol offset to a label in asm or C and
second the offsets move with each link phase and with the 2 stage linking the
offsets move. As a result the offset needs to be computer at runtime. To do this
the base image TLS symbols each get a small piece of code that determines the
offset at runtime. The symbol table in the target contains the TLS area offset
in an arch ABI specific format. The relocs know how to handle the offset the
symbol holds.

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

Re: [rtems commit] libdl: Add support to import base image TLS symbols

[PATCH] rtems: rtems_configuration_get_interrupt_stack_size()

Re: [rtems commit] libdl: Add support to import base image TLS symbols

Re: [rtems commit] libdl: Add support to import base image TLS symbols

Re: [rtems commit] libdl: Add support to import base image TLS symbols

Re: [rtems commit] libdl: Add support to import base image TLS symbols

Re: [rtems commit] libdl: Add support to import base image TLS symbols

Re: [PATCH] cpukit/riscv : RISCV multitasking with non SMP

Re: [rtems commit] libdl: Add support to import base image TLS symbols

Re: Add Formal Verification chapter v4

Re: Outdated list of BSPs in rtems-tools/config

Re: Outdated list of BSPs in rtems-tools/config

Re: Outdated list of BSPs in rtems-tools/config

Re: [rtems commit] libdl: Add support to import base image TLS symbols

14 matches

Site Navigation

Mail list logo

Footer information