Re: [PATCH 06/13] config: Add rtems_malloc_task_stack_for_idle()

2022-09-30 Thread Chris Johns
On 30/9/2022 7:21 pm, Sebastian Huber wrote:
> Update #4524.
> ---
>  cpukit/doxygen/appl-config.h| 13 +
>  cpukit/include/rtems/rtems/config.h | 29 +-
>  cpukit/include/rtems/score/interr.h |  1 +
>  cpukit/sapi/src/interrtext.c|  3 +-
>  cpukit/sapi/src/malloctaskstackforidle.c| 59 +
>  spec/build/cpukit/librtemscpu.yml   |  1 +
>  spec/build/testsuites/sptests/grp.yml   |  2 +
>  spec/build/testsuites/sptests/spfatal36.yml | 19 +++
>  testsuites/sptests/spfatal36/init.c | 52 ++
>  testsuites/sptests/spfatal36/spfatal36.doc  | 11 
>  testsuites/sptests/spinternalerror02/init.c |  2 +-
>  testsuites/sptests/sptls04/init.c   |  2 +
>  12 files changed, 191 insertions(+), 3 deletions(-)
>  create mode 100644 cpukit/sapi/src/malloctaskstackforidle.c
>  create mode 100644 spec/build/testsuites/sptests/spfatal36.yml
>  create mode 100644 testsuites/sptests/spfatal36/init.c
>  create mode 100644 testsuites/sptests/spfatal36/spfatal36.doc
> 
> diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
> index aa6dbae648..ee647dc961 100644
> --- a/cpukit/doxygen/appl-config.h
> +++ b/cpukit/doxygen/appl-config.h
> @@ -4842,6 +4842,19 @@
>   * configuration options.  It is assumed that any memory allocated for the
>   * stack of an IDLE task will not be from the RTEMS Workspace or the memory
>   * statically allocated by default.
> + *
> + * For applications with a thread-local storage size which is completely
> + * unknown at the time the application configuration is defined, RTEMS 
> provides
> + * an IDLE task stack allocator which uses rtems_malloc(). 

I thought the TLS size was static and set by the linker? Has this changed?

I am confused about the relationship between an unknown TLS size and IDLE task?
And the relationship of the TLS size and stack size?

> * * The size of the
> + * allocated thread storage area is the sum of stack size defined by the
> + * #CONFIGURE_IDLE_TASK_STACK_SIZE configuration option and the actual
> + * thread-local storage size of the application.

The label CONFIGURE_IDLE_TASK_STACK_SIZE provides no insight into it being
effected by the TLS size.

> * * Define this configuration
> + * option to ``rtems_malloc_task_stack_for_idle`` to use this allocator.  If
> + * the memory allocation fails, then the system terminates with the
> + * INTERNAL_ERROR_CORE fatal source and the
> + * INTERNAL_ERROR_NO_MEMORY_FOR_IDLE_TASK_STACK fatal code during system
> + * initialization.
> + * @endparblock

I am confused about the how and why I would use this change?

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


Re: [PATCH] spec/pkgconfig: Allow builds to override headers

2022-09-30 Thread Chris Johns
On 1/10/2022 6:30 am, Kinsey Moore wrote:
> On 9/29/2022 16:19, Chris Johns wrote:
>> On 29/9/22 11:24 pm, Kinsey Moore wrote:
>>> On 9/28/2022 19:03, Chris Johns wrote:
 On 29/9/2022 7:13 am, Kinsey Moore wrote:
> This allows any builds targeting an installed RTEMS BSP to override
> headers in the installed BSP reliably, including headers previously
> installed by that or other builds. This includes applications, network
> stacks, libraries, and any other builds.
 I am a little confused by these comments. This change effects the 
 generated .pc
 file for a BSP so it is only used once it is installed.
>>> Correct, this is a fix for things like rtems-libbsd and rtems-lwip that 
>>> allows
>>> them to build correctly even if there are existing conflicting 
>>> installations of
>>> that library already installed in the BSP install.
>> So this is a change to aid developers of these packages who use a single 
>> prefix
>> for the tools, BSP and packages? I split the install paths up and that avoids
>> the problem.
> I guess I'm conflating a couple of different problems here. I'll take a closer
> look at how things behave when there is a separate installation path.

I just delete the effect piece. This is not the only reason to separate the
paths. Cleaning the builds away is an important test. We have been caught a few
times over the years.

 An install should update
 the headers at the same time the .pc is installed and made available so 
 what is
 old or previous? What are the "builds targeting" you refer too?
>>> "builds targeting an installed RTEMS BSP" refers to any external build that 
>>> uses
>>> installed RTEMS headers and libraries. These external builds can install 
>>> their
>>> own files in the BSP install.
>> Is this install or reinstall?
> The issues happen on reinstall since there is an existing header that has a
> higher priority in the include search paths than the local search paths.

OK

 I think defining the include search of RTEMS BSP and any vertical stack
 packages
 headers installed under the same prefix as system headers seems like the 
 right
 thing to do. However this change will silence warnings from RTEMS (and
 installed
 packages). Is that want we want?
>>> What warnings will this silence?
>> https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html
>>
>> This changes the level of warnings we currently have for a specific but
>> important group of packages that are based on rtems_waf or use .pc files. I
>> think this is important to consider.
> 
> It changes the warning level when used from the installed BSP, but we should
> still see these warnings when compiling RTEMS itself and packages compiled
> against an installed BSP using the .pc files (via rtems_waf or otherwise) will
> still display these warnings in their own headers since they will be used
> locally pre-installation.
> 
> There is still the issue of using existing headers in novel ways that could
> generate warnings which would be missed due to this change, but even then the
> documentation linked claims that macros instanced in non-system-header 
> locations
> are only immune to a small subset of warnings. I think it's worth the change
> given that installing additional packages into the installed BSP is common
> practice from what I've seen.

Yes there is a chance a warning is missed and I cannot answer if that is OK.
Maybe Joel would like to comment about this?

>>> It shouldn't affect RTEMS builds because RTEMS
>>> doesn't use the pkgconfg while building. It still places installed headers
>>> before actual system/tools headers in the include hierarchy, so any build 
>>> errors
>>> generated that way should be preserved.
>> Is Makefile.inc also updated? It effects some users of RTEMS but not all. Is
>> that important?
> I hunted for this earlier and missed it. It's apparently in make/custom and
> would need to be tweaked as well for consistency.

It should be consistent.

>> Is this something we should document as mandated for all users of BSP 
>> installed
>> headers?
> 
> It's worth putting it somewhere. Users of the .pc and Makefile.inc won't 
> notice
> or need to care for the most part, but anyone using non-standard external 
> build
> systems will need to know.

Agreed

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


Re: [PATCH] spec/pkgconfig: Allow builds to override headers

2022-09-30 Thread Kinsey Moore

On 9/29/2022 16:19, Chris Johns wrote:

On 29/9/22 11:24 pm, Kinsey Moore wrote:

On 9/28/2022 19:03, Chris Johns wrote:

On 29/9/2022 7:13 am, Kinsey Moore wrote:

This allows any builds targeting an installed RTEMS BSP to override
headers in the installed BSP reliably, including headers previously
installed by that or other builds. This includes applications, network
stacks, libraries, and any other builds.

I am a little confused by these comments. This change effects the generated .pc
file for a BSP so it is only used once it is installed.

Correct, this is a fix for things like rtems-libbsd and rtems-lwip that allows
them to build correctly even if there are existing conflicting installations of
that library already installed in the BSP install.

So this is a change to aid developers of these packages who use a single prefix
for the tools, BSP and packages? I split the install paths up and that avoids
the problem.
I guess I'm conflating a couple of different problems here. I'll take a 
closer look at how things behave when there is a separate installation path.



An install should update
the headers at the same time the .pc is installed and made available so what is
old or previous? What are the "builds targeting" you refer too?

"builds targeting an installed RTEMS BSP" refers to any external build that uses
installed RTEMS headers and libraries. These external builds can install their
own files in the BSP install.

Is this install or reinstall?
The issues happen on reinstall since there is an existing header that 
has a higher priority in the include search paths than the local search 
paths.



I think defining the include search of RTEMS BSP and any vertical stack packages
headers installed under the same prefix as system headers seems like the right
thing to do. However this change will silence warnings from RTEMS (and installed
packages). Is that want we want?

What warnings will this silence?

https://gcc.gnu.org/onlinedocs/cpp/System-Headers.html

This changes the level of warnings we currently have for a specific but
important group of packages that are based on rtems_waf or use .pc files. I
think this is important to consider.


It changes the warning level when used from the installed BSP, but we 
should still see these warnings when compiling RTEMS itself and packages 
compiled against an installed BSP using the .pc files (via rtems_waf or 
otherwise) will still display these warnings in their own headers since 
they will be used locally pre-installation.


There is still the issue of using existing headers in novel ways that 
could generate warnings which would be missed due to this change, but 
even then the documentation linked claims that macros instanced in 
non-system-header locations are only immune to a small subset of 
warnings. I think it's worth the change given that installing additional 
packages into the installed BSP is common practice from what I've seen.





It shouldn't affect RTEMS builds because RTEMS
doesn't use the pkgconfg while building. It still places installed headers
before actual system/tools headers in the include hierarchy, so any build errors
generated that way should be preserved.

Is Makefile.inc also updated? It effects some users of RTEMS but not all. Is
that important?
I hunted for this earlier and missed it. It's apparently in make/custom 
and would need to be tweaked as well for consistency.


Is this something we should document as mandated for all users of BSP installed
headers?


It's worth putting it somewhere. Users of the .pc and Makefile.inc won't 
notice or need to care for the most part, but anyone using non-standard 
external build systems will need to know.



Kinsey

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


[PATCH v2] c-user: Add application config info directives

2022-09-30 Thread Sebastian Huber
Close #4267.
Close #4269.
---
v2:

* Add types to directives.

* Clarify some directives.

 c-user/config/directives.rst   | 1543 
 c-user/config/index.rst|2 +
 c-user/config/intro.rst|   43 -
 c-user/config/introduction.rst |  222 +
 4 files changed, 1767 insertions(+), 43 deletions(-)
 create mode 100644 c-user/config/directives.rst
 create mode 100644 c-user/config/introduction.rst

diff --git a/c-user/config/directives.rst b/c-user/config/directives.rst
new file mode 100644
index 000..9981a0a
--- /dev/null
+++ b/c-user/config/directives.rst
@@ -0,0 +1,1543 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2009, 2021 embedded brains GmbH 
(http://www.embedded-brains.de)
+.. Copyright (C) 1988, 2021 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://www.rtems.org/bugs.html
+..
+.. For information on updating and regenerating please refer to the How-To
+.. section in the Software Requirements Engineering chapter of the
+.. RTEMS Software Engineering manual.  The manual is provided as a part of
+.. a release.  For development sources please refer to the online
+.. documentation at:
+..
+.. https://docs.rtems.org
+
+.. _ApplicationConfigurationInformationDirectives:
+
+Directives
+==
+
+This section details the directives of the Application Configuration
+Information. A subsection is dedicated to each of this manager's directives and
+lists the calling sequence, parameters, description, return values, and notes
+of the directive.
+
+.. Generated from spec:/rtems/config/if/get-build-label
+
+.. raw:: latex
+
+\clearpage
+
+.. index:: rtems_get_build_label()
+
+.. _InterfaceRtemsGetBuildLabel:
+
+rtems_get_build_label()
+---
+
+Gets the RTEMS build label.
+
+.. rubric:: CALLING SEQUENCE:
+
+.. code-block:: c
+
+const char *rtems_get_build_label( void );
+
+.. rubric:: DESCRIPTION:
+
+The build label is a user-provided string defined by the build configuration
+through the ``RTEMS_BUILD_LABEL`` build option.  The format of the string is
+completely user-defined.
+
+.. rubric:: RETURN VALUES:
+
+Returns a pointer to the RTEMS build label.
+
+.. rubric:: NOTES:
+
+The build label can be used to distinguish test suite results obtained from
+different build configurations.  A use case is to record test results with
+performance data to track performance regressions.  For this a database of
+performance limits is required.  The build label and the target hash obtained
+from :ref:`InterfaceRtemsGetTargetHash` can be used as a key to obtain
+performance limits.
+
+.. rubric:: CONSTRAINTS:
+
+The following constraints apply to this directive:
+
+* The directive may be called from within any runtime context.
+
+* The directive will not cause the calling task to be preempted.
+
+.. Generated from spec:/rtems/config/if/get-copyright-notice
+
+.. raw:: latex
+
+\clearpage
+
+.. index:: rtems_get_copyright_notice()
+
+.. _InterfaceRtemsGetCopyrightNotice:
+
+rtems_get_copyright_notice()
+
+
+Gets the RTEMS copyright notice.
+
+.. rubric:: CALLING SEQUENCE:
+
+.. code-block:: c
+
+const char *rtems_get_copyright_notice( void );
+
+.. rubric:: RETURN VALUES:
+
+Returns a pointer to the RTEMS copyright notice.
+
+.. rubric:: CONSTRAINTS:
+
+The following constraints apply to this directive:
+
+* The directive may be called from within any runtime context.
+
+* The directive will not cause the calling task to be preempted.
+
+.. Generated from spec:/rtems/config/if/get-target-hash
+
+.. raw:: latex
+
+\clearpage
+
+.. index:: rtems_get_target_hash()
+
+.. _InterfaceRtemsGetTargetHash:
+
+rtems_get_target_hash()
+---
+
+Gets the RTEMS target hash.
+
+.. rubric:: CALLING SEQUENCE:
+
+.. code-block:: c
+
+const char *rtems_get_target_hash( void );
+
+.. rubric:: DESCRIPTION:
+
+The target hash is calculated from BSP-specific values which characterize a
+target system.  The target hash is encoded as a base64url string.  The target
+hash algorithm is unspecified.
+
+.. rubric:: RETURN VALUES:
+
+Returns a pointer to the RTEMS target hash.
+
+.. rubric:: NOTES:
+
+For example, the device tree, settings of the memory controller, processor and
+bus frequencies, a serial number of a chip may be used to calculate the target
+hash.
+
+The target hash can be used to distinguish test suite results obtained from
+different target systems.  See also :ref:`InterfaceRtemsGetBuildLabel`.
+
+.. rubric:: CONSTRAINTS:
+
+The following constraints apply to this directive:
+
+* The directive may be called from within any runtime context.
+
+* The directive will not cause the calling task to be preempted.
+
+.. Generated from spec:

Re: [PATCH] c-user: Add application config info directives

2022-09-30 Thread Sebastian Huber

On 17/09/2022 09:31, Chris Johns wrote:

diff --git a/c-user/config/introduction.rst b/c-user/config/introduction.rst
new file mode 100644
index 000..d06662a
--- /dev/null
+++ b/c-user/config/introduction.rst
@@ -0,0 +1,221 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2009, 2021 embedded brains GmbH 
(http://www.embedded-brains.de)
+.. Copyright (C) 1988, 2021 On-Line Applications Research Corporation (OAR)

Is this right? I see in the diff fragments Gedare?


Yes, I think so. Gedare has a copyright in the unlimited objects section.

--
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] c-user: Add application config info directives

2022-09-30 Thread Sebastian Huber



On 17/09/2022 09:31, Chris Johns wrote:

+rtems_configuration_get_stack_allocate_init_hook()
+--
+
+Gets the thread stack allocator initialization hook configured for this
+application.
+
+.. rubric:: CALLING SEQUENCE:
+
+.. code-block:: c
+
+#define rtems_configuration_get_stack_allocate_init_hook()
+
+.. rubric:: RETURN VALUES:
+
+Returns the thread stack allocator initialization hook configured for this
+application.

The hooks being documented should specify the hook interface and then what and
when you would use this and under what constraints, ie what is locked, services
you can use etc.


Yes, but this doesn't belong to this location.




+
+.. rubric:: NOTES:
+
+See :ref:`CONFIGURE_TASK_STACK_ALLOCATOR_INIT`.


It should be added to the configuration options.

--
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] c-user: Add application config info directives

2022-09-30 Thread Sebastian Huber

On 17/09/2022 09:31, Chris Johns wrote:

+rtems_configuration_get_milliseconds_per_tick()
+---
+
+Gets the number of milliseconds per clock tick configured for this application.

There are other API calls that return this value. What should a user do?


I don't know another API function to get this value.

--
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] c-user: Add application config info directives

2022-09-30 Thread Sebastian Huber

On 17/09/2022 09:31, Chris Johns wrote:

+rtems_get_version_string()
+--
+
+Gets the RTEMS version string.
+
+.. rubric:: CALLING SEQUENCE:
+
+.. code-block:: c
+
+const char *rtems_get_version_string( void );
+
+.. rubric:: RETURN VALUES:
+
+Returns the pointer to the RTEMS version string.

Is the version string subject to change across releases or do as set this string
format?

Is it worth discussing the revision values and what they mean?


The version string contains a lot of stuff:

const char _RTEMS_version[] =
  "rtems-" RTEMS_VERSION " (" CPU_NAME "/" CPU_MODEL_NAME "/"
  RTEMS_XSTRING( RTEMS_BSP ) ")";

I don't know if we should specify a particular format.

--
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] c-user: Add application config info directives

2022-09-30 Thread Sebastian Huber

On 17/09/2022 09:31, Chris Johns wrote:

+rtems_get_copyright_notice()
+
+
+Gets the RTEMS copyright notice.

Subject to format changes, ie users should decode and expect backwards
compatibility?


I don't know. Currently it is just an arbitrary string.

--
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] c-user: Add types to macros

2022-09-30 Thread Sebastian Huber
---
 c-user/interrupt/directives.rst   | 56 ++-
 c-user/message/directives.rst |  2 +-
 c-user/object-services/directives.rst |  6 ++-
 c-user/task/directives.rst|  2 +-
 4 files changed, 44 insertions(+), 22 deletions(-)

diff --git a/c-user/interrupt/directives.rst b/c-user/interrupt/directives.rst
index d4855b6..ee3e121 100644
--- a/c-user/interrupt/directives.rst
+++ b/c-user/interrupt/directives.rst
@@ -128,7 +128,7 @@ Disables the maskable interrupts on the current processor.
 
 .. code-block:: c
 
-#define rtems_interrupt_disable( isr_cookie )
+void rtems_interrupt_disable( rtems_interrupt_level isr_cookie );
 
 .. rubric:: PARAMETERS:
 
@@ -218,7 +218,7 @@ Restores the previous interrupt level on the current 
processor.
 
 .. code-block:: c
 
-#define rtems_interrupt_enable( isr_cookie )
+void rtems_interrupt_enable( rtems_interrupt_level isr_cookie );
 
 .. rubric:: PARAMETERS:
 
@@ -280,7 +280,7 @@ Flashes interrupts on the current processor.
 
 .. code-block:: c
 
-#define rtems_interrupt_flash( isr_cookie )
+void rtems_interrupt_flash( rtems_interrupt_level isr_cookie );
 
 .. rubric:: PARAMETERS:
 
@@ -338,7 +338,7 @@ Disables the maskable interrupts on the current processor.
 
 .. code-block:: c
 
-#define rtems_interrupt_local_disable( isr_cookie )
+void rtems_interrupt_local_disable( rtems_interrupt_level isr_cookie );
 
 .. rubric:: PARAMETERS:
 
@@ -428,7 +428,7 @@ Restores the previous interrupt level on the current 
processor.
 
 .. code-block:: c
 
-#define rtems_interrupt_local_enable( isr_cookie )
+void rtems_interrupt_local_enable( rtems_interrupt_level isr_cookie );
 
 .. rubric:: PARAMETERS:
 
@@ -484,7 +484,7 @@ Checks if an ISR is in progress on the current processor.
 
 .. code-block:: c
 
-#define rtems_interrupt_is_in_progress()
+bool rtems_interrupt_is_in_progress( void );
 
 .. rubric:: DESCRIPTION:
 
@@ -525,7 +525,10 @@ Initializes the ISR lock.
 
 .. code-block:: c
 
-#define rtems_interrupt_lock_initialize( lock, name )
+void rtems_interrupt_lock_initialize(
+  rtems_interrupt_lock *lock,
+  const char   *name
+);
 
 .. rubric:: PARAMETERS:
 
@@ -561,7 +564,7 @@ Destroys the ISR lock.
 
 .. code-block:: c
 
-#define rtems_interrupt_lock_destroy( lock )
+void rtems_interrupt_lock_destroy( rtems_interrupt_lock *lock );
 
 .. rubric:: PARAMETERS:
 
@@ -605,7 +608,10 @@ Acquires the ISR lock.
 
 .. code-block:: c
 
-#define rtems_interrupt_lock_acquire( lock, lock_context )
+void rtems_interrupt_lock_acquire(
+  rtems_interrupt_lock *lock,
+  rtems_interrupt_lock_context *lock_context
+);
 
 .. rubric:: PARAMETERS:
 
@@ -679,7 +685,7 @@ Releases the ISR lock.
 
 .. code-block:: c
 
-#define rtems_interrupt_lock_release( lock, lock_context )
+void rtems_interrupt_lock_release( rtems_interrupt_lock_context *lock );
 
 .. rubric:: PARAMETERS:
 
@@ -737,7 +743,10 @@ Acquires the ISR lock from within an ISR.
 
 .. code-block:: c
 
-#define rtems_interrupt_lock_acquire_isr( lock, lock_context )
+void rtems_interrupt_lock_acquire_isr(
+  rtems_interrupt_lock *lock,
+  rtems_interrupt_lock_context *lock_context
+);
 
 .. rubric:: PARAMETERS:
 
@@ -800,7 +809,10 @@ Releases the ISR lock from within an ISR.
 
 .. code-block:: c
 
-#define rtems_interrupt_lock_release_isr( lock, lock_context )
+void rtems_interrupt_lock_release_isr(
+  rtems_interrupt_lock *lock,
+  rtems_interrupt_lock_context *lock_context
+);
 
 .. rubric:: PARAMETERS:
 
@@ -853,7 +865,9 @@ Disables maskable interrupts on the current processor.
 
 .. code-block:: c
 
-#define rtems_interrupt_lock_interrupt_disable( lock_context )
+void rtems_interrupt_lock_interrupt_disable(
+  rtems_interrupt_lock_context *lock_context
+);
 
 .. rubric:: PARAMETERS:
 
@@ -892,7 +906,7 @@ Declares an ISR lock object.
 
 .. code-block:: c
 
-#define RTEMS_INTERRUPT_LOCK_DECLARE( specifier, designator )
+RTEMS_INTERRUPT_LOCK_DECLARE( specifier, designator );
 
 .. rubric:: PARAMETERS:
 
@@ -926,7 +940,7 @@ Defines an ISR lock object.
 
 .. code-block:: c
 
-#define RTEMS_INTERRUPT_LOCK_DEFINE( specifier, designator, name )
+RTEMS_INTERRUPT_LOCK_DEFINE( specifier, designator, const char *name );
 
 .. rubric:: PARAMETERS:
 
@@ -968,7 +982,7 @@ Statically initializes an ISR lock object.
 
 .. code-block:: c
 
-#define RTEMS_INTERRUPT_LOCK_INITIALIZER( name )
+RTEMS_INTERRUPT_LOCK_INITIALIZER( const char *name );
 
 .. rubric:: PARAMETERS:
 
@@ -1001,7 +1015,7 @@ Defines an ISR lock member.
 
 .. code-block:: c
 
-#define RTEMS_INTERRUPT_LOCK_MEMBER( designator )
+RTEMS_INTERRUPT_LOCK_MEMBER( designator );
 
 .. rubric:: PARAMETERS:
 
@@ -1031,7 +1045,7 @@ Defines an ISR lock object reference.
 
 .. code-block:: c
 
-#define RTEMS_INTERRUPT_LOCK_REFERENCE( designato

Re: [PATCH rtems-docs v2] TFTPFS: New documentation

2022-09-30 Thread Frank Kühndel

ping!

Since this patch was sent in June to the list I will shortly recap the 
context:


* I extended the TFTP file system by block and window size options. 
These patches are already part of RTEMS.


* The patch below is the documentation for it. Version 1 of this patch 
has already been reviewed by Chris, Joel and Sebastian (many thanks 
again) and I fixed all raised issues (see 
https://lists.rtems.org/pipermail/devel/2022-June/071822.html).


* What is missing is an OK for this patch.

For your convenience, I put v2 of the generated filesystem.pdf for 
download at the link shown below. I hope the PDF is more convenient to 
read than the patch itself. Please, remind that only chapter "Trivial 
FTP Client Filesystem" is affected by this patch.


https://share.embedded-brains.de/index.php/s/Qg6aoX7kByxfQLZ

My question is: Do you have more critic or are you OK with v2 of this patch?

Thanks in advance
Frank

On 6/9/22 15:21, Frank Kuehndel wrote:

Subject:
[PATCH rtems-docs v2] TFTPFS: New documentation
From:
Frank Kuehndel 
Date:
6/9/22, 15:21

To:
devel@rtems.org


From: Frank Kühndel

---
  filesystem/index.rst   |   1 +
  filesystem/trivial_ftp.rst | 564 -
  2 files changed, 562 insertions(+), 3 deletions(-)

diff --git a/filesystem/index.rst b/filesystem/index.rst
index f4e2ed6..64a2f1d 100644
--- a/filesystem/index.rst
+++ b/filesystem/index.rst
@@ -9,6 +9,7 @@ RTEMS Filesystem Design Guide (|version|).
  .. topic:: Copyrights and License
  
  ||copy|  1988, 2015 On-Line Applications Research Corporation (OAR)

+||copy|  2022 embedded brains GmbH (http://www.embedded-brains.de)
  
  .. include:: ../common/license.rst
  
diff --git a/filesystem/trivial_ftp.rst b/filesystem/trivial_ftp.rst

index e43c036..3ef8bba 100644
--- a/filesystem/trivial_ftp.rst
+++ b/filesystem/trivial_ftp.rst
@@ -3,7 +3,565 @@
  Trivial FTP Client Filesystem
  *
  
-This chapter describes the Trivial FTP (TFTP) Client Filesystem.

+This chapter describes the Trivial File Transfer Protocol (TFTP) Client
+Filesystem.  TFTP is designed to be an especially simple protocol which
+uses the User Datagram Protocol (UDP) for data transfer over the Internet.
+Its purpose is to send a single file between to network nodes (client and
+server).  A file can be sent in both directions, i.e. a client can either
+read a file from a server or write a file to the server.
  
-This chapter should be written after the IMFS chapter is completed and describe

-the implementation of the TFTP.
+Besides reading or writing a file no other operations are supported.  That
+is, one cannot seek the file, not append to the end of a file, not open
+the file for reading and writing at the same time, not list directories,
+not move files and so on.
+
+TFTP is inherent insecure as it does not provide any means for
+authentication or encryption.  Therefore, it is highly recommended not
+to employ it on public networks.  Nevertheless, it is still widely used
+to load software and configuration data during early boot stages over
+a Local Area Network (LAN).
+
+RTEMS TFTP Filesystem Implementation
+
+
+The RTEMS TFTP filesystem implements a TFTP client which can be used
+through the file system.  With other words, one needs to mount the
+TFTP filesystem and can afterwards open a file for reading or writing
+below that mount point.  The content of that file is then effectively
+read from or written to the remote server.  The RTEMS implementation
+implements the following features:
+
+* `RFC 1350`_
+  *The TFTP Protocol (Revision 2)*
+* `RFC 2347`_
+*TFTP Option Extension*
+* `RFC 2348`_
+*TFTP Blocksize Option*
+* `RFC 7440`_
+*TFTP Windowsize Option*
+
+Many simple TFTP server do not support options (RFC 2347). Therefore, in
+case the server rejects the first request with options, the RTEMS client
+makes automatically a second attempt using only the "classical" RFC 1350.
+
+The implementation has the following shortcomings:
+
+* IPv6 is not supported (yet).
+
+* No congestion control is implemented.
+
+  (Congestion is simply expressed a network traffic jam which involves
+  package loss.)  This implementation would worsen a congestion situation
+  and squeeze out TCP connections.  If that is a concern in your setup,
+  it can be prevented by using value `1` as `windowsize` when mounting
+  the TFTP file system.
+
+* One must call ``open()``, ``read()``, ``write()`` and ``close()``
+  at a good pace.
+
+  TFTP is designed to read or write a whole already existing file in
+  one sweep.  It uses timeouts (of unspecified length) and it does not
+  know keep-alive messages.  If the client does not respond to the
+  server in due time, the server sets the connection faulty and d

[PATCH 09/13] score: Simplify casts

2022-09-30 Thread Sebastian Huber
---
 cpukit/include/rtems/score/tls.h | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/cpukit/include/rtems/score/tls.h b/cpukit/include/rtems/score/tls.h
index 9c90b6362b..abb0a748ad 100644
--- a/cpukit/include/rtems/score/tls.h
+++ b/cpukit/include/rtems/score/tls.h
@@ -167,17 +167,13 @@ uintptr_t _TLS_Get_allocation_size( void );
  */
 static inline void _TLS_Copy_and_clear( void *tls_data )
 {
-  tls_data = memcpy(
-tls_data,
-_TLS_Data_begin,
-(size_t) ((uintptr_t)_TLS_Data_size)
-  );
+  tls_data = memcpy( tls_data, _TLS_Data_begin, (uintptr_t) _TLS_Data_size );
 
   memset(
-(char *) tls_data + (size_t)((intptr_t) _TLS_BSS_begin) -
-  (size_t)((intptr_t) _TLS_Data_begin),
+(char *) tls_data +
+  (uintptr_t) _TLS_BSS_begin - (uintptr_t) _TLS_Data_begin,
 0,
-((size_t) (intptr_t)_TLS_BSS_size)
+(uintptr_t) _TLS_BSS_size
   );
 }
 
-- 
2.35.3

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


[PATCH 13/13] config: Add CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE

2022-09-30 Thread Sebastian Huber
By default, the IDLE task storage areas are statically allocated.  The size of
the task storage area is defined by the CONFIGURE_IDLE_TASK_STACK_SIZE
configuration option.  The task storage area contains the task stack, the
thread-local storage, and the floating-point context on architectures with a
separate floating-point context.  The size of the thread-local storage area is
defined at link time or by the CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE
configuration option.  The new CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE
configuration option is used to ensure that the IDLE task stack size has at
least the configured minimum size.  If the IDLE task stack size is too small,
for example because the thread-local storage size is too large, then the system
terminates with the INTERNAL_ERROR_CORE fatal source and the
INTERNAL_ERROR_IDLE_THREAD_STACK_TOO_SMALL fatal code during system
initialization.

Update #3835.
---
 cpukit/doxygen/appl-config.h  | 120 +++--
 cpukit/include/rtems/confdefs/percpu.h|  10 ++
 cpukit/include/rtems/score/interr.h   |   3 +-
 cpukit/include/rtems/score/threadidledata.h   |   8 +
 cpukit/sapi/src/interrtext.c  |   3 +-
 cpukit/score/src/threadcreateidle.c   |  24 ++-
 .../fatal-idle-thread-stack-too-small.yml |  20 +++
 spec/build/testsuites/validation/grp.yml  |   2 +
 testsuites/libtests/stackchk01/init.c |  30 +++-
 testsuites/libtests/stackchk01/stackchk01.doc |  12 +-
 testsuites/samples/minimum/init.c |   3 +
 testsuites/sptests/spinternalerror02/init.c   |   2 +-
 testsuites/validation/tc-acfg-default.c   |  51 +++---
 .../tr-fatal-idle-thread-stack-too-small.c| 169 ++
 .../tr-fatal-idle-thread-stack-too-small.h|  84 +
 .../ts-fatal-idle-thread-stack-too-small.c|  99 ++
 16 files changed, 589 insertions(+), 51 deletions(-)
 create mode 100644 
spec/build/testsuites/validation/fatal-idle-thread-stack-too-small.yml
 create mode 100644 testsuites/validation/tr-fatal-idle-thread-stack-too-small.c
 create mode 100644 testsuites/validation/tr-fatal-idle-thread-stack-too-small.h
 create mode 100644 testsuites/validation/ts-fatal-idle-thread-stack-too-small.c

diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index ee647dc961..7564bc4462 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -3400,13 +3400,66 @@
  */
 #define CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION
 
+/* Generated from spec:/acfg/if/idle-task-min-stack-size */
+
+/**
+ * @brief This configuration option is an integer define.
+ *
+ * The value of this configuration option defines the minimum stack size in
+ * bytes for every IDLE task in the system.
+ *
+ * @par Default Value
+ * #CPU_STACK_MINIMUM_SIZE / 4
+ *
+ * @par Value Constraints
+ * @parblock
+ * The value of the configuration option shall be large enough so that
+ *
+ * * the thread handler can call the thread switch extensions for the IDLE
+ *   task,
+ *
+ * * the thread handler can call the thread begin extensions for the IDLE task,
+ *
+ * * the thread handler can call the IDLE task body (see
+ *   #CONFIGURE_IDLE_TASK_BODY), and
+ *
+ * * the IDLE task can be interrupted by interrupt services.
+ * @endparblock
+ *
+ * @par Notes
+ * @parblock
+ * Adjusting this parameter should be done with caution.  Examining the actual
+ * stack usage using the stack checker usage reporting facility is recommended
+ * (see also #CONFIGURE_STACK_CHECKER_ENABLED).
+ *
+ * This parameter can be used to increase the minimum from that recommended.
+ * This can be used in higher memory systems to reduce the risk of stack
+ * overflow without performing analysis on actual consumption.
+ *
+ * By default, the IDLE task storage areas are statically allocated.  The size
+ * of the task storage area is defined by the #CONFIGURE_IDLE_TASK_STACK_SIZE
+ * configuration option.  The task storage area contains the task stack, the
+ * thread-local storage, and the floating-point context on architectures with a
+ * separate floating-point context.  The size of the thread-local storage area
+ * is defined at link time or by the
+ * #CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE configuration option.  This
+ * configuration option is used to ensure that the IDLE task stack size has at
+ * least the configured minimum size.  If the IDLE task stack size is too
+ * small, for example because the thread-local storage size is too large, then
+ * the system terminates with the INTERNAL_ERROR_CORE fatal source and the
+ * INTERNAL_ERROR_IDLE_THREAD_STACK_TOO_SMALL fatal code during system
+ * initialization.
+ * @endparblock
+ */
+#define CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE
+
 /* Generated from spec:/acfg/if/idle-task-stack-size */
 
 /**
  * @brief This configuration option is an integer define.
  *
- * The value of this configuration option defines the task stack size for an
- * IDLE task.
+ * The value of 

[PATCH 12/13] stackchk: Add rtems_stack_checker_iterate()

2022-09-30 Thread Sebastian Huber
---
 cpukit/include/rtems/stackchk.h |  75 +++
 cpukit/libmisc/stackchk/check.c | 158 +++-
 2 files changed, 170 insertions(+), 63 deletions(-)

diff --git a/cpukit/include/rtems/stackchk.h b/cpukit/include/rtems/stackchk.h
index 7968211a51..c836263925 100644
--- a/cpukit/include/rtems/stackchk.h
+++ b/cpukit/include/rtems/stackchk.h
@@ -90,6 +90,81 @@ void rtems_stack_checker_report_usage_with_plugin(
   const rtems_printer *printer
 );
 
+/**
+ * @brief This structure contains the stack information provided by the stack
+ *   checker for a stack.
+ */
+typedef struct {
+  /**
+   * @brief This member contains the object identifier associated with the
+   *   object using the stack.
+   *
+   * For interrupt stacks, the object identifier is the processor index.
+   */
+  rtems_id id;
+
+  /**
+   * @brief This member provides the object name associated with the
+   *   object using the stack.
+   *
+   * For interrupt stacks, the object name is "Interrupt Stack".
+   */
+  const char *name;
+
+  /**
+   * @brief This member provides the begin address of the stack area.
+   */
+  const void *begin;
+
+  /**
+   * @brief This member contains the size in byes of the stack area.
+   */
+  uintptr_t size;
+
+  /**
+   * @brief This member provides the current stack pointer of the stack.
+   *
+   * If the current stack pointer is not available, then the value is set to
+   * NULL.
+   */
+  const void *current;
+
+  /**
+   * @brief This member contains the size in byes of the used stack area.
+   *
+   * If the stack checker is not initialized, then the value is set to
+   * UINTPTR_MAX.
+   */
+  uintptr_t used;
+} rtems_stack_checker_info;
+
+/**
+ * @brief Visitor routines invoked by rtems_stack_checker_iterate() shall have
+ *   this type.
+ *
+ * @param info is the stack information.
+ *
+ * @param arg is the argument passed to rtems_stack_checker_iterate().
+ */
+typedef void ( *rtems_stack_checker_visitor )(
+  const rtems_stack_checker_info *info,
+  void   *arg
+);
+
+/**
+ * @brief Iterates over all stacks used by the system and invokes the visitor
+ *   routine for each stack.
+ *
+ * This method prints a stack usage report for the curently executing
+ * task.
+ *
+ * @param visitor is the visitor routine invoked for each stack.
+ *
+ * @param arg is the argument passed to each visitor routine invocation during
+ *   the iteration.
+ */
+void rtems_stack_checker_iterate( rtems_stack_checker_visitor visit, void *arg 
);
+
 /*
  *
  **  Prototyped only so the user extension can be installed **
diff --git a/cpukit/libmisc/stackchk/check.c b/cpukit/libmisc/stackchk/check.c
index 48342ce957..53b96f462c 100644
--- a/cpukit/libmisc/stackchk/check.c
+++ b/cpukit/libmisc/stackchk/check.c
@@ -413,134 +413,166 @@ static inline void *Stack_check_Find_high_water_mark(
 return (void *) base;
   #endif
 
-  return (void *)0;
+  return NULL;
 }
 
-static bool Stack_check_Dump_stack_usage(
-  const Stack_Control *stack,
-  const void  *current,
-  const char  *name,
-  uint32_t id,
-  const rtems_printer *printer
+static void Stack_check_Visit_stack(
+  const Stack_Control*stack,
+  const void *current,
+  const char *name,
+  rtems_idid,
+  rtems_stack_checker_visitor visit,
+  void*arg
 )
 {
-  uint32_t  size;
-  uint32_t  used;
-  void *low;
-  void *high_water_mark;
+  rtems_stack_checker_info info;
 
   /* This is likely to occur if the stack checker is not actually enabled */
   if ( stack->area == NULL ) {
-return false;
+return;
   }
 
-  low  = Stack_check_Usable_stack_start(stack);
-  size = Stack_check_Usable_stack_size(stack);
+  info.id = id;
+  info.name = name;
+  info.current = current;
+  info.begin  = Stack_check_Usable_stack_start( stack );
+  info.size = Stack_check_Usable_stack_size( stack );
 
-  high_water_mark = Stack_check_Find_high_water_mark(low, size);
+  if ( Stack_check_Initialized ) {
+void *high_water_mark;
 
-  if ( high_water_mark )
-used = Stack_check_Calculate_used( low, size, high_water_mark );
-  else
-used = 0;
+high_water_mark =
+  Stack_check_Find_high_water_mark( info.begin, info.size );
 
-  rtems_printf(
-printer,
-"0x%08" PRIx32 " %-21s 0x%08" PRIxPTR " 0x%08" PRIxPTR " 0x%08" PRIxPTR " 
%6" PRId32 " ",
-id,
-name,
-(uintptr_t) stack->area,
-(uintptr_t) stack->area + (uintptr_t) stack->size - 1,
-(uintptr_t) current,
-size
-  );
-
-  if (Stack_check_Initialized) {
-rtems_printf( printer, "%6" PRId32 "\n", used );
+if ( high_water_mark != NULL ) {
+  info.used =
+Stack_check_Calculate_used( info.begin, info.size, high_water_mark );
+} else {
+  info.used = 0;
+}
   } else {
-

[PATCH 05/13] config: Changeable size for IDLE stack allocator

2022-09-30 Thread Sebastian Huber
Allow the IDLE stack allocator to change the stack size.  This can be
used by applications with a very dynamic thread-local storage size to
adjust the thread storage area of the IDLE tasks dynamically.

Update #4524.
---
 cpukit/doxygen/appl-config.h |  2 +-
 cpukit/include/rtems/score/stack.h   | 17 -
 cpukit/score/src/stackallocatorforidle.c | 19 +--
 cpukit/score/src/threadcreateidle.c  |  4 ++--
 testsuites/sptests/spstkalloc03/init.c   |  4 ++--
 testsuites/sptests/spstkalloc04/init.c   |  4 ++--
 testsuites/validation/ts-config.h|  2 +-
 testsuites/validation/ts-default.h   |  4 ++--
 8 files changed, 31 insertions(+), 25 deletions(-)

diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index 005d47e7b1..aa6dbae648 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -4835,7 +4835,7 @@
  *
  * @par Value Constraints
  * The value of this configuration option shall be defined to a valid function
- * pointer of the type ``void *( *allocate )( uint32_t, size_t )``.
+ * pointer of the type ``void *( *allocate )( uint32_t, size_t * )``.
  *
  * @par Notes
  * This configuration option is independent of the other thread stack allocator
diff --git a/cpukit/include/rtems/score/stack.h 
b/cpukit/include/rtems/score/stack.h
index 360e4d61f6..7577ca0474 100644
--- a/cpukit/include/rtems/score/stack.h
+++ b/cpukit/include/rtems/score/stack.h
@@ -105,15 +105,22 @@ typedef void ( *Stack_Allocator_free )( void *addr );
  * The allocate for idle handler is optional even when the user thread stack
  * allocator and deallocator are configured.
  *
- * @param cpu Index of the CPU for the IDLE thread using this stack
- * @param stack_size The size of the stack area to allocate in bytes.
+ * @param cpu is the index of the CPU for the IDLE thread using this stack.
  *
- * @retval NULL Not enough memory.
- * @retval other Pointer to begin of stack area.
+ * @param stack_size[in, out] is pointer to a size_t object.  On function
+ *   entry, the object contains the proposed size of the stack area to allocate
+ *   in bytes.  The proposed size does not take the actual thread-local storage
+ *   size of the application into account.  The stack allocator can modify the
+ *   size to ensure that there is enough space available in the stack area for
+ *   the thread-local storage.
+ *
+ * @retval NULL There was not enough memory available to allocate a stack area.
+ *
+ * @return Returns the pointer to begin of the allocated stack area.
  */
 typedef void *( *Stack_Allocator_allocate_for_idle )(
   uint32_t  cpu,
-  size_tstack_size
+  size_t   *stack_size
 );
 
 /**
diff --git a/cpukit/score/src/stackallocatorforidle.c 
b/cpukit/score/src/stackallocatorforidle.c
index 76b6ace1f4..c97dde030f 100644
--- a/cpukit/score/src/stackallocatorforidle.c
+++ b/cpukit/score/src/stackallocatorforidle.c
@@ -34,27 +34,26 @@
 #include 
 
 /**
- * @brief Default stack allocator allocate for idle handler.
- *
- * The allocate for idle handler is optional even when the user thread stack
- * allocator and deallocator are configured.
+ * @brief Default stack allocator allocate for IDLE threads.
  *
  * The default allocator for IDLE thread stacks gets the memory from a
  * statically allocated area provided via confdefs.h.
  *
- * @param cpu_index Index of the CPU for the IDLE thread using this stack
- * @param stack_size The size of the stack area to allocate in bytes.
+ * @param cpu is the index of the CPU for the IDLE thread using this stack.
+ *
+ * @param stack_size[in] is pointer to a size_t object.  On function
+ *   entry, the object contains the size of the stack area to allocate in
+ *   bytes.
  *
- * @retval NULL Not enough memory (never returned).
- * @retval other Pointer to begin of stack area.
+ * @return Returns the pointer to begin of the allocated stack area.
  */
 static void *_Stack_Allocator_allocate_for_idle_default(
   uint32_t  cpu_index,
-  size_tstack_size
+  size_t   *stack_size
 )
 {
 #if defined(RTEMS_SMP)
-  return &_Thread_Idle_stacks[ cpu_index * stack_size ];
+  return &_Thread_Idle_stacks[ cpu_index * ( *stack_size ) ];
 #else
   _Assert( cpu_index == 0 );
   return &_Thread_Idle_stacks[ 0 ];
diff --git a/cpukit/score/src/threadcreateidle.c 
b/cpukit/score/src/threadcreateidle.c
index b5e0cfdc9b..3e3c7cfc83 100644
--- a/cpukit/score/src/threadcreateidle.c
+++ b/cpukit/score/src/threadcreateidle.c
@@ -73,9 +73,9 @@ static void _Thread_Create_idle_for_CPU( Per_CPU_Control *cpu 
)
* The IDLE thread stacks may be statically allocated or there may be a
* custom allocator provided just as with user threads.
*/
-  config.stack_area = (*_Stack_Allocator_allocate_for_idle)(
+  config.stack_area = ( *_Stack_Allocator_allocate_for_idle )(
 _Per_CPU_Get_index( cpu ),
-config.stack_size
+&config.stack_size
   );
 
   /*
diff --git a/testsuites/sptests/spstkalloc03/init.c 
b/testsuites/s

[PATCH 06/13] config: Add rtems_malloc_task_stack_for_idle()

2022-09-30 Thread Sebastian Huber
Update #4524.
---
 cpukit/doxygen/appl-config.h| 13 +
 cpukit/include/rtems/rtems/config.h | 29 +-
 cpukit/include/rtems/score/interr.h |  1 +
 cpukit/sapi/src/interrtext.c|  3 +-
 cpukit/sapi/src/malloctaskstackforidle.c| 59 +
 spec/build/cpukit/librtemscpu.yml   |  1 +
 spec/build/testsuites/sptests/grp.yml   |  2 +
 spec/build/testsuites/sptests/spfatal36.yml | 19 +++
 testsuites/sptests/spfatal36/init.c | 52 ++
 testsuites/sptests/spfatal36/spfatal36.doc  | 11 
 testsuites/sptests/spinternalerror02/init.c |  2 +-
 testsuites/sptests/sptls04/init.c   |  2 +
 12 files changed, 191 insertions(+), 3 deletions(-)
 create mode 100644 cpukit/sapi/src/malloctaskstackforidle.c
 create mode 100644 spec/build/testsuites/sptests/spfatal36.yml
 create mode 100644 testsuites/sptests/spfatal36/init.c
 create mode 100644 testsuites/sptests/spfatal36/spfatal36.doc

diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index aa6dbae648..ee647dc961 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -4842,6 +4842,19 @@
  * configuration options.  It is assumed that any memory allocated for the
  * stack of an IDLE task will not be from the RTEMS Workspace or the memory
  * statically allocated by default.
+ *
+ * For applications with a thread-local storage size which is completely
+ * unknown at the time the application configuration is defined, RTEMS provides
+ * an IDLE task stack allocator which uses rtems_malloc().  The size of the
+ * allocated thread storage area is the sum of stack size defined by the
+ * #CONFIGURE_IDLE_TASK_STACK_SIZE configuration option and the actual
+ * thread-local storage size of the application.  Define this configuration
+ * option to ``rtems_malloc_task_stack_for_idle`` to use this allocator.  If
+ * the memory allocation fails, then the system terminates with the
+ * INTERNAL_ERROR_CORE fatal source and the
+ * INTERNAL_ERROR_NO_MEMORY_FOR_IDLE_TASK_STACK fatal code during system
+ * initialization.
+ * @endparblock
  */
 #define CONFIGURE_TASK_STACK_ALLOCATOR_FOR_IDLE
 
diff --git a/cpukit/include/rtems/rtems/config.h 
b/cpukit/include/rtems/rtems/config.h
index 3d813c55b6..7c7f1e3aa3 100644
--- a/cpukit/include/rtems/rtems/config.h
+++ b/cpukit/include/rtems/rtems/config.h
@@ -10,7 +10,7 @@
  */
 
 /*
- * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
+ * Copyright (C) 2020, 2022 embedded brains GmbH 
(http://www.embedded-brains.de)
  * Copyright (C) 1989, 2008 On-Line Applications Research Corporation (OAR)
  *
  * Redistribution and use in source and binary forms, with or without
@@ -58,6 +58,7 @@
 #define _RTEMS_RTEMS_CONFIG_H
 
 #include 
+#include 
 #include 
 #include 
 
@@ -328,6 +329,32 @@ uint32_t rtems_configuration_get_maximum_tasks( void );
  */
 uint32_t rtems_configuration_get_maximum_timers( void );
 
+/* Generated from spec:/rtems/config/if/malloc-task-stack-for-idle */
+
+/**
+ * @ingroup RTEMSAPIConfig
+ *
+ * @brief Allocates a thread storage area for an IDLE task using
+ *   rtems_malloc().
+ *
+ * @param unused is an unused parameter.
+ *
+ * @param[in,out] size is the pointer to an size_t object.  At function entry,
+ *   the object contains the size of the thread storage area not accounting for
+ *   the thread-local storage size.  When the directive call is successful, the
+ *   size of the allocated thread storage area will be stored in this object.
+ *
+ * The thread storage size is determined by the #CONFIGURE_IDLE_TASK_STACK_SIZE
+ * application configuration option and the actual thread-local storage size of
+ * the application.  The memory is allocated using rtems_malloc().
+ *
+ * @return Returns the begin address of the allocated thread storage area.
+ *
+ * @par Notes
+ * See #CONFIGURE_TASK_STACK_ALLOCATOR_FOR_IDLE.
+ */
+void *rtems_malloc_task_stack_for_idle( uint32_t unused, size_t *size );
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/cpukit/include/rtems/score/interr.h 
b/cpukit/include/rtems/score/interr.h
index ae4966d6d8..6e6926ab61 100644
--- a/cpukit/include/rtems/score/interr.h
+++ b/cpukit/include/rtems/score/interr.h
@@ -229,6 +229,7 @@ typedef enum {
   INTERNAL_ERROR_NO_MEMORY_FOR_PER_CPU_DATA = 40,
   INTERNAL_ERROR_TOO_LARGE_TLS_SIZE = 41,
   INTERNAL_ERROR_RTEMS_INIT_TASK_CONSTRUCT_FAILED = 42,
+  INTERNAL_ERROR_NO_MEMORY_FOR_IDLE_TASK_STACK = 43
 } Internal_errors_Core_list;
 
 typedef CPU_Uint32ptr Internal_errors_t;
diff --git a/cpukit/sapi/src/interrtext.c b/cpukit/sapi/src/interrtext.c
index 383cc5bc0a..005cdc4508 100644
--- a/cpukit/sapi/src/interrtext.c
+++ b/cpukit/sapi/src/interrtext.c
@@ -83,7 +83,8 @@ static const char *const internal_error_text[] = {
   "INTERNAL_ERROR_ARC4RANDOM_GETENTROPY_FAIL",
   "INTERNAL_ERROR_NO_MEMORY_FOR_PER_CPU_DATA",
   "INTERNAL_ERROR_TOO_LARGE_TLS_SIZE",
-  "INTERNAL_ERROR_RTEMS_INIT_TA

[PATCH 08/13] score: Add CPU_THREAD_LOCAL_STORAGE_VARIANT

2022-09-30 Thread Sebastian Huber
Update #3835.
---
 bsps/powerpc/shared/cpu.c |   2 +-
 cpukit/include/rtems/score/tls.h  | 204 --
 cpukit/score/cpu/aarch64/cpu.c|   2 +-
 .../cpu/aarch64/include/rtems/score/cpuimpl.h |   3 +
 cpukit/score/cpu/arm/__aeabi_read_tp.c|   6 +-
 cpukit/score/cpu/arm/__tls_get_addr.c |   6 +-
 .../score/cpu/arm/armv7m-context-initialize.c |   2 +-
 cpukit/score/cpu/arm/cpu.c|  17 +-
 .../score/cpu/arm/include/rtems/score/cpu.h   |  10 +-
 .../cpu/arm/include/rtems/score/cpuimpl.h |   2 +
 .../cpu/bfin/include/rtems/score/cpuimpl.h|   2 +
 cpukit/score/cpu/i386/cpu.c   |   2 +-
 .../cpu/i386/include/rtems/score/cpuimpl.h|   2 +
 .../cpu/lm32/include/rtems/score/cpuimpl.h|   2 +
 cpukit/score/cpu/m68k/__m68k_read_tp.c|   4 +-
 cpukit/score/cpu/m68k/cpu.c   |   5 +-
 .../score/cpu/m68k/include/rtems/score/cpu.h  |   1 +
 .../cpu/m68k/include/rtems/score/cpuimpl.h|   2 +
 cpukit/score/cpu/microblaze/__tls_get_addr.c  |  10 +-
 cpukit/score/cpu/microblaze/cpu.c |   2 +-
 .../cpu/microblaze/include/rtems/score/cpu.h  |   1 +
 .../microblaze/include/rtems/score/cpuimpl.h  |   3 +
 .../cpu/mips/include/rtems/score/cpuimpl.h|   2 +
 .../cpu/moxie/include/rtems/score/cpuimpl.h   |   2 +
 .../cpu/nios2/include/rtems/score/cpuimpl.h   |   2 +
 .../cpu/nios2/nios2-context-initialize.c  |   5 +-
 .../cpu/no_cpu/include/rtems/score/cpuimpl.h  |  18 ++
 .../cpu/or1k/include/rtems/score/cpuimpl.h|   2 +
 .../cpu/powerpc/include/rtems/score/cpuimpl.h |   2 +
 .../cpu/riscv/include/rtems/score/cpuimpl.h   |   2 +
 .../cpu/riscv/riscv-context-initialize.c  |   2 +-
 .../cpu/sh/include/rtems/score/cpuimpl.h  |   2 +
 cpukit/score/cpu/sparc/cpu.c  |   2 +-
 .../cpu/sparc/include/rtems/score/cpuimpl.h   |   2 +
 cpukit/score/cpu/sparc64/cpu.c|   2 +-
 .../cpu/sparc64/include/rtems/score/cpuimpl.h |   2 +
 .../cpu/v850/include/rtems/score/cpuimpl.h|   2 +
 .../cpu/x86_64/include/rtems/score/cpuimpl.h  |   2 +
 cpukit/score/src/threadinitialize.c   |   6 +-
 cpukit/score/src/tlsallocsize.c   |  44 ++--
 40 files changed, 208 insertions(+), 183 deletions(-)

diff --git a/bsps/powerpc/shared/cpu.c b/bsps/powerpc/shared/cpu.c
index a06b8c0868..c38b60b4ee 100644
--- a/bsps/powerpc/shared/cpu.c
+++ b/bsps/powerpc/shared/cpu.c
@@ -130,7 +130,7 @@ void _CPU_Context_Initialize(
 #endif
 
   if ( tls_area != NULL ) {
-void *tls_block = _TLS_TCB_before_TLS_block_initialize( tls_area );
+void *tls_block = _TLS_Initialize_area( tls_area );
 
 the_ppc_context->tp = (uintptr_t) tls_block + 0x7000;
   }
diff --git a/cpukit/include/rtems/score/tls.h b/cpukit/include/rtems/score/tls.h
index ee4fb9a22e..9c90b6362b 100644
--- a/cpukit/include/rtems/score/tls.h
+++ b/cpukit/include/rtems/score/tls.h
@@ -10,7 +10,7 @@
  */
 
 /*
- * Copyright (c) 2014 embedded brains GmbH.  All rights reserved.
+ * Copyright (C) 2014, 2022 embedded brains GmbH
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -37,7 +37,7 @@
 #ifndef _RTEMS_SCORE_TLS_H
 #define _RTEMS_SCORE_TLS_H
 
-#include 
+#include 
 
 #include 
 
@@ -116,9 +116,9 @@ typedef struct {
 } TLS_Index;
 
 /**
- * @brief Gets the TLS size.
+ * @brief Gets the size of the thread-local storage data in bytes.
  *
- * @return The TLS size.
+ * @return Returns the size of the thread-local storage data in bytes.
  */
 static inline uintptr_t _TLS_Get_size( void )
 {
@@ -135,82 +135,64 @@ static inline uintptr_t _TLS_Get_size( void )
 }
 
 /**
- * @brief Returns the value aligned up to the stack alignment.
+ * @brief Gets the size of the thread control block area in bytes.
  *
- * @param val The value to align.
- *
- * @return The value aligned to the stack alignment.
+ * @return Returns the size of the thread control block area in bytes.
  */
-static inline uintptr_t _TLS_Align_up( uintptr_t val )
+static inline uintptr_t _TLS_Get_thread_control_block_area_size( void )
 {
-  uintptr_t alignment = CPU_STACK_ALIGNMENT;
+#if CPU_THREAD_LOCAL_STORAGE_VARIANT == 11
+  uintptr_t alignment;
 
-  return RTEMS_ALIGN_UP( val, alignment );
-}
+  alignment = (uintptr_t) _TLS_Alignment;
 
-/**
- * @brief Returns the size of the thread control block area size for this
- *  alignment, or the minimum size if alignment is too small.
- *
- * @param alignment The alignment for the operation.
- *
- * @return The size of the thread control block area.
- */
-static inline uintptr_t _TLS_Get_thread_control_block_area_size(
-  uintptr_t alignment
-)
-{
-  return alignment <= sizeof(TLS_Thread_control_block) ?
-sizeof(TLS_Thread_control_block) : alignment;
+  return RTEMS_ALIGN_UP( sizeof( TLS_Thread_control_block ), alignment );
+#else
+  return sizeof( TLS_Thread_control_block 

[PATCH 10/13] score: INTERNAL_ERROR_IDLE_THREAD_CREATE_FAILED

2022-09-30 Thread Sebastian Huber
Add the INTERNAL_ERROR_IDLE_THREAD_CREATE_FAILED fatal error in case the
creation of an idle thread fails.  This may happen due to a failing create
extension provided by the application.
---
 cpukit/include/rtems/score/interr.h   |   3 +-
 cpukit/sapi/src/interrtext.c  |   3 +-
 cpukit/score/src/threadcreateidle.c   |  12 +-
 .../fatal-idle-thread-create-failed.yml   |  20 +++
 spec/build/testsuites/validation/grp.yml  |   2 +
 testsuites/sptests/spinternalerror02/init.c   |   2 +-
 .../tr-fatal-idle-thread-create-failed.c  | 158 ++
 .../tr-fatal-idle-thread-create-failed.h  |  84 ++
 .../ts-fatal-idle-thread-create-failed.c  |  90 ++
 testsuites/validation/ts-fatal-sysinit.h  |   7 +
 10 files changed, 375 insertions(+), 6 deletions(-)
 create mode 100644 
spec/build/testsuites/validation/fatal-idle-thread-create-failed.yml
 create mode 100644 testsuites/validation/tr-fatal-idle-thread-create-failed.c
 create mode 100644 testsuites/validation/tr-fatal-idle-thread-create-failed.h
 create mode 100644 testsuites/validation/ts-fatal-idle-thread-create-failed.c

diff --git a/cpukit/include/rtems/score/interr.h 
b/cpukit/include/rtems/score/interr.h
index 6e6926ab61..1eeb93cc6e 100644
--- a/cpukit/include/rtems/score/interr.h
+++ b/cpukit/include/rtems/score/interr.h
@@ -229,7 +229,8 @@ typedef enum {
   INTERNAL_ERROR_NO_MEMORY_FOR_PER_CPU_DATA = 40,
   INTERNAL_ERROR_TOO_LARGE_TLS_SIZE = 41,
   INTERNAL_ERROR_RTEMS_INIT_TASK_CONSTRUCT_FAILED = 42,
-  INTERNAL_ERROR_NO_MEMORY_FOR_IDLE_TASK_STACK = 43
+  INTERNAL_ERROR_NO_MEMORY_FOR_IDLE_TASK_STACK = 43,
+  INTERNAL_ERROR_IDLE_THREAD_CREATE_FAILED = 44
 } Internal_errors_Core_list;
 
 typedef CPU_Uint32ptr Internal_errors_t;
diff --git a/cpukit/sapi/src/interrtext.c b/cpukit/sapi/src/interrtext.c
index 005cdc4508..85ccf13201 100644
--- a/cpukit/sapi/src/interrtext.c
+++ b/cpukit/sapi/src/interrtext.c
@@ -84,7 +84,8 @@ static const char *const internal_error_text[] = {
   "INTERNAL_ERROR_NO_MEMORY_FOR_PER_CPU_DATA",
   "INTERNAL_ERROR_TOO_LARGE_TLS_SIZE",
   "INTERNAL_ERROR_RTEMS_INIT_TASK_CONSTRUCT_FAILED",
-  "INTERNAL_ERROR_NO_MEMORY_FOR_IDLE_TASK_STACK"
+  "INTERNAL_ERROR_NO_MEMORY_FOR_IDLE_TASK_STACK",
+  "INTERNAL_ERROR_IDLE_THREAD_CREATE_FAILED"
 };
 
 const char *rtems_internal_error_text( rtems_fatal_code error )
diff --git a/cpukit/score/src/threadcreateidle.c 
b/cpukit/score/src/threadcreateidle.c
index 3e3c7cfc83..d2037b36f0 100644
--- a/cpukit/score/src/threadcreateidle.c
+++ b/cpukit/score/src/threadcreateidle.c
@@ -39,13 +39,16 @@
 #include "config.h"
 #endif
 
-#include 
-#include 
 #include 
+
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include 
@@ -66,6 +69,7 @@ static void _Thread_Create_idle_for_CPU( Per_CPU_Control *cpu 
)
   config.name = _Objects_Build_name( 'I', 'D', 'L', 'E' );
   config.is_fp = CPU_IDLE_TASK_IS_FP;
   config.is_preemptible = true;
+  config.stack_free = _Objects_Free_nothing;
   config.stack_size = _Thread_Idle_stack_size
 + CPU_IDLE_TASK_IS_FP * CONTEXT_FP_SIZE;
 
@@ -87,7 +91,9 @@ static void _Thread_Create_idle_for_CPU( Per_CPU_Control *cpu 
)
   _Assert( idle != NULL );
 
   status = _Thread_Initialize( &_Thread_Information, idle, &config );
-  _Assert_Unused_variable_equals( status, STATUS_SUCCESSFUL );
+  if ( status != STATUS_SUCCESSFUL ) {
+_Internal_error( INTERNAL_ERROR_IDLE_THREAD_CREATE_FAILED );
+  }
 
   /*
*  WARNING!!! This is necessary to "kick" start the system and
diff --git 
a/spec/build/testsuites/validation/fatal-idle-thread-create-failed.yml 
b/spec/build/testsuites/validation/fatal-idle-thread-create-failed.yml
new file mode 100644
index 00..49af89452a
--- /dev/null
+++ b/spec/build/testsuites/validation/fatal-idle-thread-create-failed.yml
@@ -0,0 +1,20 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: test-program
+cflags: []
+copyrights:
+- Copyright (C) 2022 embedded brains GmbH (http://www.embedded-brains.de)
+cppflags: []
+cxxflags: []
+enabled-by: true
+features: c cprogram
+includes: []
+ldflags: []
+links: []
+source:
+- testsuites/validation/tr-fatal-idle-thread-create-failed.c
+- testsuites/validation/ts-fatal-idle-thread-create-failed.c
+stlib: []
+target: testsuites/validation/ts-fatal-idle-thread-create-failed.exe
+type: build
+use-after: []
+use-before: []
diff --git a/spec/build/testsuites/validation/grp.yml 
b/spec/build/testsuites/validation/grp.yml
index b9205cc28c..7a5fbb1c90 100644
--- a/spec/build/testsuites/validation/grp.yml
+++ b/spec/build/testsuites/validation/grp.yml
@@ -17,6 +17,8 @@ links:
   uid: libvalidation
 - role: build-dependency
   uid: fatal-boot-processor-not-assigned-to-scheduler
+- role: build-dependency
+  uid: fatal-idle-thread-create-failed
 - role: build-dependency
   uid: fatal-init-task-construct-failed
 - role: build-dependency
diff --git a/testsuites/sptests/spint

[PATCH 11/13] stackchk: Avoid internal header file

2022-09-30 Thread Sebastian Huber
---
 cpukit/include/rtems/stackchk.h | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/cpukit/include/rtems/stackchk.h b/cpukit/include/rtems/stackchk.h
index 22d48c9d2b..7968211a51 100644
--- a/cpukit/include/rtems/stackchk.h
+++ b/cpukit/include/rtems/stackchk.h
@@ -40,9 +40,7 @@
 #ifndef _RTEMS_STACKCHK_H
 #define _RTEMS_STACKCHK_H
 
-#include  /* bool */
-
-#include  /* Thread_Control */
+#include 
 #include 
 
 /**
@@ -110,11 +108,11 @@ void rtems_stack_checker_report_usage_with_plugin(
  *   will automatically intialize itself.
  */
 bool rtems_stack_checker_create_extension(
-  Thread_Control *running,
-  Thread_Control *the_thread
+  rtems_tcb *running,
+  rtems_tcb *the_thread
 );
 
-void rtems_stack_checker_begin_extension( Thread_Control *executing );
+void rtems_stack_checker_begin_extension( rtems_tcb *executing );
 
 /**
  * @brief Stack Checker Task Context Switch Extension
@@ -128,8 +126,8 @@ void rtems_stack_checker_begin_extension( Thread_Control 
*executing );
  * @note This is called from the internal method _Thread_Dispatch.
  */
 void rtems_stack_checker_switch_extension(
-  Thread_Control *running,
-  Thread_Control *heir
+  rtems_tcb *running,
+  rtems_tcb *heir
 );
 
 /**
-- 
2.35.3

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


[PATCH 04/13] score: Require power of two CPU_STACK_MINIMUM_SIZE

2022-09-30 Thread Sebastian Huber
For most CPU ports this was already the case.  This makes it possible to use
the size as an object alignment using RTEMS_ALIGNED().
---
 cpukit/score/cpu/aarch64/include/rtems/score/cpu.h | 2 +-
 cpukit/score/cpu/moxie/include/rtems/score/cpu.h   | 2 +-
 cpukit/score/cpu/no_cpu/include/rtems/score/cpu.h  | 3 ++-
 cpukit/score/src/percpuasm.c   | 7 ++-
 4 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h 
b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
index 399e0fc802..aa4f90f1a8 100644
--- a/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/aarch64/include/rtems/score/cpu.h
@@ -102,7 +102,7 @@
 
 #define CPU_PROVIDES_ISR_IS_IN_PROGRESS FALSE
 
-#define CPU_STACK_MINIMUM_SIZE (1024 * 10)
+#define CPU_STACK_MINIMUM_SIZE (1024 * 8)
 
 /* This could be either 4 or 8, depending on the ABI in use.
  * Could also use __LP64__ or __ILP32__ */
diff --git a/cpukit/score/cpu/moxie/include/rtems/score/cpu.h 
b/cpukit/score/cpu/moxie/include/rtems/score/cpu.h
index b94d47ab31..cc1900a852 100644
--- a/cpukit/score/cpu/moxie/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/moxie/include/rtems/score/cpu.h
@@ -228,7 +228,7 @@ typedef struct {
  *
  *  XXX
  */
-#define CPU_STACK_MINIMUM_SIZE  (1536)
+#define CPU_STACK_MINIMUM_SIZE  (2048)
 
 /**
  * Size of a pointer.
diff --git a/cpukit/score/cpu/no_cpu/include/rtems/score/cpu.h 
b/cpukit/score/cpu/no_cpu/include/rtems/score/cpu.h
index 962fc486fc..9ef6f43eb9 100644
--- a/cpukit/score/cpu/no_cpu/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/no_cpu/include/rtems/score/cpu.h
@@ -554,7 +554,8 @@ extern Context_Control_fp _CPU_Null_fp_context;
  * @addtogroup RTEMSScoreCPUExampleContext
  * 
  * Should be large enough to run all RTEMS tests.  This ensures
- * that a "reasonable" small application should not have any problems.
+ * that a "reasonable" small application should not have any problems.  The
+ * size shall be a power of two.
  *
  * Port Specific Information:
  *
diff --git a/cpukit/score/src/percpuasm.c b/cpukit/score/src/percpuasm.c
index 6e5a727b76..4bd92be37d 100644
--- a/cpukit/score/src/percpuasm.c
+++ b/cpukit/score/src/percpuasm.c
@@ -44,7 +44,7 @@
 #include 
 
 #define PER_CPU_IS_POWER_OF_TWO( value ) \
-  ( ( ( ( value ) - 1 ) & ( value ) ) == 0 )
+  ( ( value ) > 1 && ( ( ( value ) - 1 ) & ( value ) ) == 0 )
 
 /*
  * The minimum alignment of two is due to the Heap Handler which uses the
@@ -72,6 +72,11 @@ RTEMS_STATIC_ASSERT(
   CPU_STACK_ALIGNMENT
 );
 
+RTEMS_STATIC_ASSERT(
+  PER_CPU_IS_POWER_OF_TWO( CPU_STACK_MINIMUM_SIZE ),
+  CPU_STACK_MINIMUM_SIZE
+);
+
 RTEMS_STATIC_ASSERT(
   sizeof(void *) == CPU_SIZEOF_POINTER,
   CPU_SIZEOF_POINTER
-- 
2.35.3

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


[PATCH 00/13] More robust idle thread creation and TLS handling

2022-09-30 Thread Sebastian Huber
This patch set started with an 8 byte overwrite of the interrupt stack while
porting an application from RTEMS 5 to 6.

The overwrite was due to a mismatch of the size returned by
_TLS_Get_allocation_size() and the actual usage of the area.  To fix this issue
it was necessary to add a new CPU port option:
CPU_THREAD_LOCAL_STORAGE_VARIANT.  I checked also the glibc implementations.
It seems that on some architectures (for example powerpc) the TCB is used for a
couple of more things.  For RTEMS, we don't really need the DTV and TCB.  It
could be useful for debuggers, however, then we probably need also some glibc
compatibility.

Add a new fatal error to catch a failing idle thread initialization:
INTERNAL_ERROR_IDLE_THREAD_CREATE_FAILED.  This can only happen if a thread
create extension fails for an idle thread.

Add a new CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE application configuration
option to ensure that the idle task stacks have at least the configured minimum
size.  To check the default value for this option, the stack checker was
improved by adding the rtems_stack_checker_iterate() directive which can be
used to query the current information of all stacks in the system.

Sebastian Huber (13):
  sptls0*: Enable stack checker
  sptls01: Disable file system and Newlib reentrancy
  sptls02: Fix alignment check
  score: Require power of two CPU_STACK_MINIMUM_SIZE
  config: Changeable size for IDLE stack allocator
  config: Add rtems_malloc_task_stack_for_idle()
  sptls02: Increase alignment of a TLS object
  score: Add CPU_THREAD_LOCAL_STORAGE_VARIANT
  score: Simplify casts
  score: INTERNAL_ERROR_IDLE_THREAD_CREATE_FAILED
  stackchk: Avoid internal header file
  stackchk: Add rtems_stack_checker_iterate()
  config: Add CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE

 bsps/powerpc/shared/cpu.c |   2 +-
 cpukit/doxygen/appl-config.h  | 121 +-
 cpukit/include/rtems/confdefs/percpu.h|  10 +
 cpukit/include/rtems/rtems/config.h   |  29 ++-
 cpukit/include/rtems/score/interr.h   |   3 +
 cpukit/include/rtems/score/stack.h|  17 +-
 cpukit/include/rtems/score/threadidledata.h   |   8 +
 cpukit/include/rtems/score/tls.h  | 210 +++---
 cpukit/include/rtems/stackchk.h   |  89 +++-
 cpukit/libmisc/stackchk/check.c   | 158 +++--
 cpukit/sapi/src/interrtext.c  |   5 +-
 cpukit/sapi/src/malloctaskstackforidle.c  |  59 +
 cpukit/score/cpu/aarch64/cpu.c|   2 +-
 .../cpu/aarch64/include/rtems/score/cpu.h |   2 +-
 .../cpu/aarch64/include/rtems/score/cpuimpl.h |   3 +
 cpukit/score/cpu/arm/__aeabi_read_tp.c|   6 +-
 cpukit/score/cpu/arm/__tls_get_addr.c |   6 +-
 .../score/cpu/arm/armv7m-context-initialize.c |   2 +-
 cpukit/score/cpu/arm/cpu.c|  17 +-
 .../score/cpu/arm/include/rtems/score/cpu.h   |  10 +-
 .../cpu/arm/include/rtems/score/cpuimpl.h |   2 +
 .../cpu/bfin/include/rtems/score/cpuimpl.h|   2 +
 cpukit/score/cpu/i386/cpu.c   |   2 +-
 .../cpu/i386/include/rtems/score/cpuimpl.h|   2 +
 .../cpu/lm32/include/rtems/score/cpuimpl.h|   2 +
 cpukit/score/cpu/m68k/__m68k_read_tp.c|   4 +-
 cpukit/score/cpu/m68k/cpu.c   |   5 +-
 .../score/cpu/m68k/include/rtems/score/cpu.h  |   1 +
 .../cpu/m68k/include/rtems/score/cpuimpl.h|   2 +
 cpukit/score/cpu/microblaze/__tls_get_addr.c  |  10 +-
 cpukit/score/cpu/microblaze/cpu.c |   2 +-
 .../cpu/microblaze/include/rtems/score/cpu.h  |   1 +
 .../microblaze/include/rtems/score/cpuimpl.h  |   3 +
 .../cpu/mips/include/rtems/score/cpuimpl.h|   2 +
 .../score/cpu/moxie/include/rtems/score/cpu.h |   2 +-
 .../cpu/moxie/include/rtems/score/cpuimpl.h   |   2 +
 .../cpu/nios2/include/rtems/score/cpuimpl.h   |   2 +
 .../cpu/nios2/nios2-context-initialize.c  |   5 +-
 .../cpu/no_cpu/include/rtems/score/cpu.h  |   3 +-
 .../cpu/no_cpu/include/rtems/score/cpuimpl.h  |  18 ++
 .../cpu/or1k/include/rtems/score/cpuimpl.h|   2 +
 .../cpu/powerpc/include/rtems/score/cpuimpl.h |   2 +
 .../cpu/riscv/include/rtems/score/cpuimpl.h   |   2 +
 .../cpu/riscv/riscv-context-initialize.c  |   2 +-
 .../cpu/sh/include/rtems/score/cpuimpl.h  |   2 +
 cpukit/score/cpu/sparc/cpu.c  |   2 +-
 .../cpu/sparc/include/rtems/score/cpuimpl.h   |   2 +
 cpukit/score/cpu/sparc64/cpu.c|   2 +-
 .../cpu/sparc64/include/rtems/score/cpuimpl.h |   2 +
 .../cpu/v850/include/rtems/score/cpuimpl.h|   2 +
 .../cpu/x86_64/include/rtems/score/cpuimpl.h  |   2 +
 cpukit/score/src/percpuasm.c  |   7 +-
 cpukit/score/src/stackallocatorforidle.c  |  19 +-
 cpukit/score/src/threadcreateidle.c   |  40 +++-
 cpukit/score/src/threadinitialize.c   |   6 +-
 cpukit/score/src/tlsallocsize.c   |  44 ++--
 spec/build/cpukit/librtemscpu.yml   

[PATCH 02/13] sptls01: Disable file system and Newlib reentrancy

2022-09-30 Thread Sebastian Huber
Update #4560.
---
 testsuites/sptests/sptls01/init.c | 35 ++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/testsuites/sptests/sptls01/init.c 
b/testsuites/sptests/sptls01/init.c
index 64860ec9c9..a1c55940d9 100644
--- a/testsuites/sptests/sptls01/init.c
+++ b/testsuites/sptests/sptls01/init.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "tmacros.h"
 
@@ -64,6 +65,24 @@ static void task(rtems_task_argument arg)
   rtems_test_assert(sc == RTEMS_SUCCESSFUL);
 }
 
+static void check_tls_size(void)
+{
+  uintptr_t tls_size;
+
+  tls_size = _TLS_Get_size();
+
+  if (tls_size != 1) {
+printk(
+  "WARNING: The thread-local storage size is %" PRIuPTR ".  It should be\n"
+  "exactly one for this test.  Check the BSP implementation.  The BSP\n"
+  "should not pull in thread-local storage objects such as errno for\n"
+  "this test.\n",
+  tls_size
+);
+rtems_test_assert(tls_size == 1);
+  }
+}
+
 static void test(void)
 {
   rtems_id id;
@@ -101,6 +120,7 @@ static void test(void)
 
 static void test_idle_during_system_init(void)
 {
+  rtems_print_printer_printk(&rtems_test_printer);
   TEST_BEGIN();
 
   check_tls_item(123);
@@ -111,6 +131,7 @@ static void Init(rtems_task_argument arg)
   test();
 
   rtems_test_assert(!rtems_stack_checker_is_blown());
+  check_tls_size();
   TEST_END();
 
   rtems_test_exit(0);
@@ -123,7 +144,19 @@ RTEMS_SYSINIT_ITEM(
 );
 
 #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
-#define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
+
+/*
+ * Avoid a dependency on errno which might be a thread-local object.  This test
+ * assumes that no thread-local storage object other than tls_item is present.
+ */
+#define CONFIGURE_APPLICATION_DISABLE_FILESYSTEM
+
+/*
+ * This test requires full control over the present thread-local objects.  In
+ * certain Newlib configurations, the Newlib reentrancy support may add
+ * thread-local objects.
+ */
+#define CONFIGURE_DISABLE_NEWLIB_REENTRANCY
 
 #define CONFIGURE_STACK_CHECKER_ENABLED
 
-- 
2.35.3

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


[PATCH 07/13] sptls02: Increase alignment of a TLS object

2022-09-30 Thread Sebastian Huber
Increase the alignment of a TLS object to the minimum stack size.  This may
provoke overflows in the TLS area calculations.
---
 testsuites/sptests/sptls02/init.cc | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/testsuites/sptests/sptls02/init.cc 
b/testsuites/sptests/sptls02/init.cc
index 39fc2a2a24..081b8c160d 100644
--- a/testsuites/sptests/sptls02/init.cc
+++ b/testsuites/sptests/sptls02/init.cc
@@ -48,7 +48,7 @@ alignas(256) static thread_local long a256 = 256;
 
 static thread_local long i0;
 
-alignas(512) static thread_local long a512;
+alignas(RTEMS_MINIMUM_STACK_SIZE) static thread_local long a;
 
 int seven()
 {
@@ -61,7 +61,7 @@ static void clobber()
i123 = 0xdead0001;
a256 = 0xdead0002;
i0 = 0xdead0003;
-   a512 = 0xdead0004;
+   a = 0xdead0004;
 }
 
 static long f456(bool clobber)
@@ -173,8 +173,8 @@ static void checkTLSValues()
RTEMS_OBFUSCATE_VARIABLE(addr);
rtems_test_assert((addr % 256) == 0);
rtems_test_assert(i0 == 0);
-   rtems_test_assert(a512 == 0);
-   addr = reinterpret_cast(&a512);
+   rtems_test_assert(a == 0);
+   addr = reinterpret_cast(&a);
RTEMS_OBFUSCATE_VARIABLE(addr);
rtems_test_assert((addr % 512) == 0);
rtems_test_assert(f456(false) == 456);
@@ -315,6 +315,8 @@ extern "C" void Init(rtems_task_argument arg)
 #define CONFIGURE_MAXIMUM_POSIX_KEYS 2
 #define CONFIGURE_MAXIMUM_POSIX_KEY_VALUE_PAIRS 2
 
+#define CONFIGURE_IDLE_TASK_STACK_SIZE (5 * RTEMS_MINIMUM_STACK_SIZE)
+
 #define CONFIGURE_INIT
 
 #include 
-- 
2.35.3

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


[PATCH 03/13] sptls02: Fix alignment check

2022-09-30 Thread Sebastian Huber
---
 testsuites/sptests/sptls02/init.cc | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/testsuites/sptests/sptls02/init.cc 
b/testsuites/sptests/sptls02/init.cc
index e4791cffd6..39fc2a2a24 100644
--- a/testsuites/sptests/sptls02/init.cc
+++ b/testsuites/sptests/sptls02/init.cc
@@ -169,10 +169,14 @@ static void checkTLSValues()
rtems_test_assert(extern_int == 7);
rtems_test_assert(i123 == 123);
rtems_test_assert(a256 == 256);
-   rtems_test_assert((a256 & 255) == 0);
+   uintptr_t addr = reinterpret_cast(&a256);
+   RTEMS_OBFUSCATE_VARIABLE(addr);
+   rtems_test_assert((addr % 256) == 0);
rtems_test_assert(i0 == 0);
rtems_test_assert(a512 == 0);
-   rtems_test_assert((a512 & 511) == 0);
+   addr = reinterpret_cast(&a512);
+   RTEMS_OBFUSCATE_VARIABLE(addr);
+   rtems_test_assert((addr % 512) == 0);
rtems_test_assert(f456(false) == 456);
rtems_test_assert(f0(false) == 0);
rtems_test_assert(C::c789() == 789);
-- 
2.35.3

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


[PATCH 01/13] sptls0*: Enable stack checker

2022-09-30 Thread Sebastian Huber
The thread-local storage area is located close to other stacks.  Try to detect
overwrites.
---
 testsuites/sptests/sptls01/init.c  | 4 
 testsuites/sptests/sptls02/init.cc | 4 
 testsuites/sptests/sptls03/init.c  | 4 
 3 files changed, 12 insertions(+)

diff --git a/testsuites/sptests/sptls01/init.c 
b/testsuites/sptests/sptls01/init.c
index efd0fb4c6c..64860ec9c9 100644
--- a/testsuites/sptests/sptls01/init.c
+++ b/testsuites/sptests/sptls01/init.c
@@ -30,6 +30,7 @@
 #endif
 
 #include 
+#include 
 #include 
 
 #include "tmacros.h"
@@ -109,6 +110,7 @@ static void Init(rtems_task_argument arg)
 {
   test();
 
+  rtems_test_assert(!rtems_stack_checker_is_blown());
   TEST_END();
 
   rtems_test_exit(0);
@@ -123,6 +125,8 @@ RTEMS_SYSINIT_ITEM(
 #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
 
+#define CONFIGURE_STACK_CHECKER_ENABLED
+
 #define CONFIGURE_MAXIMUM_TASKS 2
 
 #define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
diff --git a/testsuites/sptests/sptls02/init.cc 
b/testsuites/sptests/sptls02/init.cc
index 712358f978..e4791cffd6 100644
--- a/testsuites/sptests/sptls02/init.cc
+++ b/testsuites/sptests/sptls02/init.cc
@@ -36,6 +36,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -288,6 +289,7 @@ extern "C" void Init(rtems_task_argument arg)
testWorkerTask();
 
rtems_test_assert(rtems_resource_snapshot_check(&snapshot));
+   rtems_test_assert(!rtems_stack_checker_is_blown());
 
TEST_END();
 
@@ -297,6 +299,8 @@ extern "C" void Init(rtems_task_argument arg)
 #define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
 
+#define CONFIGURE_STACK_CHECKER_ENABLED
+
 #define CONFIGURE_MAXIMUM_TASKS 2
 #define CONFIGURE_MAXIMUM_SEMAPHORES 3
 
diff --git a/testsuites/sptests/sptls03/init.c 
b/testsuites/sptests/sptls03/init.c
index 6625327f45..119c0cb29c 100644
--- a/testsuites/sptests/sptls03/init.c
+++ b/testsuites/sptests/sptls03/init.c
@@ -29,6 +29,7 @@
 #include "config.h"
 #endif
 
+#include 
 #include 
 
 #include "tmacros.h"
@@ -55,6 +56,7 @@ static void Init(rtems_task_argument arg)
 
   test();
 
+  rtems_test_assert(!rtems_stack_checker_is_blown());
   TEST_END();
 
   rtems_test_exit(0);
@@ -75,6 +77,8 @@ static void Init(rtems_task_argument arg)
  */
 #define CONFIGURE_DISABLE_NEWLIB_REENTRANCY
 
+#define CONFIGURE_STACK_CHECKER_ENABLED
+
 #define CONFIGURE_MAXIMUM_TASKS 1
 
 #define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
-- 
2.35.3

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


[docs 3/5] c-user: INTERNAL_ERROR_NO_MEMORY_FOR_IDLE_TASK_STACK

2022-09-30 Thread Sebastian Huber
Document this fatal error.
---
 c-user/fatal-error/background.rst | 5 +
 1 file changed, 5 insertions(+)

diff --git a/c-user/fatal-error/background.rst 
b/c-user/fatal-error/background.rst
index 3bc170f..6b47ab3 100644
--- a/c-user/fatal-error/background.rst
+++ b/c-user/fatal-error/background.rst
@@ -361,3 +361,8 @@ INTERNAL_ERROR_RTEMS_INIT_TASK_CONSTRUCT_FAILED (42)
 The construction of the RTEMS initialization task failed.  This fatal error
 may occur during system initialization.  It is an application configuration
 error.
+
+INTERNAL_ERROR_NO_MEMORY_FOR_IDLE_TASK_STACK (43)
+There was not enough memory available to allocate an IDLE task stack.  This
+fatal error may occur during system initialization.  It is an application
+configuration error.
-- 
2.35.3

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


[docs 1/5] c-user: Add CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE

2022-09-30 Thread Sebastian Huber
---
 c-user/config/idle-task.rst| 95 --
 c-user/config/task-stack-alloc.rst | 39 ++--
 2 files changed, 124 insertions(+), 10 deletions(-)

diff --git a/c-user/config/idle-task.rst b/c-user/config/idle-task.rst
index 359f862..d7b43ae 100644
--- a/c-user/config/idle-task.rst
+++ b/c-user/config/idle-task.rst
@@ -1,6 +1,6 @@
 .. SPDX-License-Identifier: CC-BY-SA-4.0
 
-.. Copyright (C) 2020, 2021 embedded brains GmbH 
(http://www.embedded-brains.de)
+.. Copyright (C) 2020, 2022 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
@@ -134,6 +134,74 @@ options
 
 otherwise a compile time error in the configuration file will occur.
 
+.. Generated from spec:/acfg/if/idle-task-min-stack-size
+
+.. raw:: latex
+
+\clearpage
+
+.. index:: CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE
+.. index:: minimum task stack size
+
+.. _CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE:
+
+CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE
+--
+
+.. rubric:: CONSTANT:
+
+``CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE``
+
+.. rubric:: OPTION TYPE:
+
+This configuration option is an integer define.
+
+.. rubric:: DEFAULT VALUE:
+
+:c:macro:`CPU_STACK_MINIMUM_SIZE` / 4
+
+.. rubric:: DESCRIPTION:
+
+The value of this configuration option defines the minimum stack size in
+bytes for every :term:`IDLE task` in the system.
+
+.. rubric:: NOTES:
+
+Adjusting this parameter should be done with caution.  Examining the actual
+stack usage using the stack checker usage reporting facility is recommended
+(see also :ref:`CONFIGURE_STACK_CHECKER_ENABLED`).
+
+This parameter can be used to increase the minimum from that
+recommended. This can be used in higher memory systems to reduce the risk
+of stack overflow without performing analysis on actual consumption.
+
+By default, the IDLE task storage areas are statically allocated.  The size
+of the task storage area is defined by the 
:ref:`CONFIGURE_IDLE_TASK_STACK_SIZE`
+configuration option.  The task storage area contains the task stack, the
+thread-local storage, and the floating-point context on architectures with a
+separate floating-point context.  The size of the thread-local storage area
+is defined at link time or by the 
:ref:`CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE`
+configuration option.  This configuration option is used to ensure that the
+IDLE task stack size has at least the configured minimum size.  If the IDLE
+task stack size is too small, for example because the thread-local storage
+size is too large, then the system terminates with the
+:ref:`INTERNAL_ERROR_CORE ` fatal source and the
+:ref:`INTERNAL_ERROR_IDLE_THREAD_STACK_TOO_SMALL ` fatal code 
during
+system initialization.
+
+.. rubric:: CONSTRAINTS:
+
+The value of the configuration option shall be large enough so that
+
+* the thread handler can call the thread switch extensions for the IDLE task,
+
+* the thread handler can call the thread begin extensions for the IDLE task,
+
+* the thread handler can call the IDLE task body (see
+  :ref:`CONFIGURE_IDLE_TASK_BODY`), and
+
+* the IDLE task can be interrupted by interrupt services.
+
 .. Generated from spec:/acfg/if/idle-task-stack-size
 
 .. raw:: latex
@@ -165,13 +233,30 @@ defined by the :ref:`CONFIGURE_MINIMUM_TASK_STACK_SIZE` 
configuration option.
 
 .. rubric:: DESCRIPTION:
 
-The value of this configuration option defines the task stack size for an
-IDLE task.
+The value of this configuration option defines the task storage area size for
+an IDLE task.
 
 .. rubric:: NOTES:
 
-In SMP configurations, there is one IDLE task per configured processor, see
-:ref:`CONFIGURE_MAXIMUM_PROCESSORS`.
+Where the system was built with SMP support enabled, there is one IDLE task
+for each configured processor, see :ref:`CONFIGURE_MAXIMUM_PROCESSORS`.
+
+By default, the IDLE task storage areas are statically allocated.  The size
+of the task storage area for each IDLE task is defined by this configuration
+option.  The task storage area contains the task stack, the thread-local
+storage, and the floating-point context on architectures with a separate
+floating-point context.  The size of the thread-local storage area is defined
+at link time or by the :ref:`CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE` 
configuration
+option.  The :ref:`CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE` configuration 
option is used
+to ensure that the IDLE task stack size has at least the configured minimum
+size.  If the IDLE task stack size is too small, for example because the
+thread-local storage size is too large, then the system terminates with the
+:ref:`INTERNAL_ERROR_CORE ` fatal source and the
+:ref:`INTERNAL_ERROR_IDLE_THREAD_STACK_TOO_SMALL ` fatal code 
during
+system initialization.
+
+You can use the :ref:`CONFIGURE_TASK_STACK_ALLOCATOR_FOR_IDLE` configuration 
option
+to change

[docs 4/5] c-user: INTERNAL_ERROR_IDLE_THREAD_CREATE_FAILED

2022-09-30 Thread Sebastian Huber
Document this fatal error.
---
 c-user/fatal-error/background.rst | 5 +
 1 file changed, 5 insertions(+)

diff --git a/c-user/fatal-error/background.rst 
b/c-user/fatal-error/background.rst
index 6b47ab3..3c4212e 100644
--- a/c-user/fatal-error/background.rst
+++ b/c-user/fatal-error/background.rst
@@ -366,3 +366,8 @@ INTERNAL_ERROR_NO_MEMORY_FOR_IDLE_TASK_STACK (43)
 There was not enough memory available to allocate an IDLE task stack.  This
 fatal error may occur during system initialization.  It is an application
 configuration error.
+
+INTERNAL_ERROR_IDLE_THREAD_CREATE_FAILED (44)
+The creation of an IDLE task failed.  This fatal error may occur during
+system initialization.  It happens if a task create extension fails for an
+IDLE task.
-- 
2.35.3

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


[docs 2/5] c-user: INTERNAL_ERROR_RTEMS_INIT_TASK_CONSTRUCT_FAILED

2022-09-30 Thread Sebastian Huber
Document this fatal error.
---
 c-user/fatal-error/background.rst | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/c-user/fatal-error/background.rst 
b/c-user/fatal-error/background.rst
index 6932846..3bc170f 100644
--- a/c-user/fatal-error/background.rst
+++ b/c-user/fatal-error/background.rst
@@ -316,13 +316,13 @@ INTERNAL_ERROR_BAD_THREAD_DISPATCH_ENVIRONMENT (31)
 }
 
 INTERNAL_ERROR_RTEMS_INIT_TASK_CREATE_FAILED (32)
-Creation of an RTEMS initialization task failed.  This fatal error may
+The creation of the RTEMS initialization task failed.  This fatal error may
 occur during system initialization.  It is an application configuration
 error.
 
 INTERNAL_ERROR_POSIX_INIT_THREAD_CREATE_FAILED (33)
-Creation of a POSIX initialization thread failed.  This fatal error may
-occur during system initialization.  It is an application configuration
+The creation of the POSIX initialization thread failed.  This fatal error
+may occur during system initialization.  It is an application configuration
 error.
 
 INTERNAL_ERROR_LIBIO_STDOUT_FD_OPEN_FAILED (36)
@@ -356,3 +356,8 @@ INTERNAL_ERROR_TOO_LARGE_TLS_SIZE (41)
 :ref:`CONFIGURE_MAXIMUM_THREAD_LOCAL_STORAGE_SIZE 
`.
 You can get the thread-local storage size of an application using the RTEMS
 tool ``rtems-execinfo``.
+
+INTERNAL_ERROR_RTEMS_INIT_TASK_CONSTRUCT_FAILED (42)
+The construction of the RTEMS initialization task failed.  This fatal error
+may occur during system initialization.  It is an application configuration
+error.
-- 
2.35.3

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


[docs 5/5] c-user: INTERNAL_ERROR_IDLE_THREAD_STACK_TOO_SMALL

2022-09-30 Thread Sebastian Huber
Document this fatal error.
---
 c-user/fatal-error/background.rst | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/c-user/fatal-error/background.rst 
b/c-user/fatal-error/background.rst
index 3c4212e..ef1e2e1 100644
--- a/c-user/fatal-error/background.rst
+++ b/c-user/fatal-error/background.rst
@@ -371,3 +371,10 @@ INTERNAL_ERROR_IDLE_THREAD_CREATE_FAILED (44)
 The creation of an IDLE task failed.  This fatal error may occur during
 system initialization.  It happens if a task create extension fails for an
 IDLE task.
+
+INTERNAL_ERROR_IDLE_THREAD_STACK_TOO_SMALL (45)
+The task stack size of an IDLE task would have been less than the
+configured minimum stack size for IDLE tasks, see
+:ref:`CONFIGURE_IDLE_TASK_MINIMUM_STACK_SIZE 
`.
+This fatal error may occur during system initialization.  It is an
+application configuration error.
-- 
2.35.3

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


Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build

2022-09-30 Thread Chris Johns
On 30/9/2022 5:01 pm, Christian MAUDERER wrote:
>  The rtems-deployment repo doesn't have a .gitlab-ci.yml. Did you keep that 
> separate?

Sorry missed this. The plumbing is outside of that repo.

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


Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build

2022-09-30 Thread Chris Johns
On 30/9/2022 5:01 pm, Christian MAUDERER wrote:
> Am 30.09.22 um 08:48 schrieb Chris Johns:
>> On 30/9/2022 4:08 pm, Christian MAUDERER wrote:
>>> Am 30.09.22 um 07:37 schrieb Chris Johns:
 On 30/9/2022 3:33 pm, Christian MAUDERER wrote:
> Am 30.09.22 um 05:49 schrieb Chris Johns:
>> On 29/9/2022 9:50 pm, Chris Johns wrote:
>>> On 29/9/22 9:45 pm, Christian MAUDERER wrote:
 Hello Chris,

 thanks for the quick patch. With this qemu and microblaze work again 
 like
 expected.

 I tested all tools starting with devel/* and from the ones that work 
 only
 devel/autotools-internal didn't generate a tar archive. But that one 
 has a
 comment "Do not use via the command line" in the bset file so that is 
 most
 likely fine.

 Some of other devel/* packages didn't build in my test setup, but I 
 have
 never
 tested or used them before so that is probably a problem of my build
 environment
 or maybe a known bug.
>>>
>>> Thanks for the testing. I will push to the devel branch and 5.
>>>
>>
>> Tarfile creation is working however installing is not. I am working on 
>> fixing
>> this.
>>
>> Chris
>
> Sorry that I missed that. I only tried to generate the tar archives.

 Same. Testing a fix but it takes time to check properly.

 I am wondering if I can create a test mode in the deployment repo. The hard
 part
 is how to automatically check the build has worked.

 Chris
>>>
>>> I'm currently trying to create a basic CI/CD setup for testing our embedded
>>> brains patches using GitHub. At the moment it's still quite experimental and
>>> still a bit thrown together but it basically runs:
>>>
>>> https://github.com/embedded-brains/rtems-source-builder/actions/runs/3151126889
>>
>> Nice.
>>
>>> It didn't catch that bug because it doesn't use installed tools for the
>>> simulator runs, but maybe I can change that.
>>>
>>> If it works well enough, we maybe could re-use some scripts or work flows 
>>> to set
>>> up an official RTEMS CI/CD with whatever community preferred CI system. It
>>> shouldn't be too big of a problem to port the logic to Gitlab CI, Cirrus CI 
>>> or
>>> any other modern CI system.
>>
>> I have started https://git.rtems.org/chrisj/rtems-deployment.git/. I would 
>> like
>> it to be the landing place for this type of stuff if it fits. The repo is 
>> being
>> actively worked on by me.
> 
> I have seen that repo after you mentioned it recently, but I have to admit I
> haven't looked at it yet. From the name I have guessed that it is more for
> building release versions and not for continuous checks. I'll take a more
> detailed look.

CI is something that would come under deployment, it is the same process. In
your case the output is not used, it is for testing.

The repo can build buildsets that will fail and show them as a pass.

>> I can build RPMs on Rocky 8 and 9. These RPMs are the base for EPICS RPMs 
>> built
>> into docker containers used to build Gemini's EPICS based systems. All 
>> handled
>> via CI in gitlab.
> 
> That's quite interesting. Do you have a public GitLab instance where you build
> these or is that a private instance?

https://gitlab.com/nsf-noirlab/gemini/rtsw/epics-base/epics-base

> The rtems-deployment repo doesn't have a .gitlab-ci.yml. Did you keep that 
> separate?
$ ./waf configure --prefix=/opt/rtems --rsb=../rtems-source-builder
$ ./waf rpmspec
$ rpmbuild -bb out/test/dtc.spec

$ rpm -qi \
 out/buildroot/RPMS/x86_64/rtems-dtc-5-ddfcc320ab74_modified.el9.x86_64.rpm
Name: rtems-dtc
Version : 5
Release : ddfcc320ab74_modified.el9
Architecture: x86_64
Install Date: (not installed)
Group   : Unspecified
Size: 1191613
License : GPLv2, GPLv3, BSD-2
Signature   : (none)
Source RPM  : rtems-dtc-5-ddfcc320ab74_modified.el9.src.rpm
Build Date  : Friday 30 September 2022 05:24:31 PM
Build Host  : rocky.contemporary.net.au
Summary : RTEMS tools and board support package
Description :
This RPM is development tools and BSP for RTEMS

If you switch the RSB branch from 6 to 5 the same process works. That is really
important because users do not need to update their plumbing.

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


[RSB 5 PATCH 3/3] rtems/bsps: Optionally support arch/bsp if used

2022-09-30 Thread chrisj
From: Chris Johns 

Updates #4717
---
 rtems/config/rtems-bsp.cfg | 55 --
 1 file changed, 41 insertions(+), 14 deletions(-)

diff --git a/rtems/config/rtems-bsp.cfg b/rtems/config/rtems-bsp.cfg
index 801cd5c..af9ad3d 100644
--- a/rtems/config/rtems-bsp.cfg
+++ b/rtems/config/rtems-bsp.cfg
@@ -39,6 +39,44 @@
 %{pkgconfig crosscompile yes}
 %{pkgconfig filter-flags yes}
 
+#
+# We need a BSP from the user.
+#
+%ifn %{defined with_rtems_bsp}
+ %if %{rtems_bsp_error}
+  %error No RTEMS BSP specified: --with-rtems-bsp=bsp
+ %endif
+ %define with_rtems_bsp sparc/erc32
+%endif
+%define rtems_bsp %{with_rtems_bsp}
+
+#
+# If the BSP(s) have a '/' it is the arch/bsp notation.
+#
+%define is_arch_bsp %(echo %{rtems_bsp} | sed -e 's/.*\/.*/yes/g')
+%if %{is_arch_bsp} == yes
+ %define rtems_ab_bsps \
+  %(x=''; \
+   for b in %{rtems_bsp}; do x="$x "$(echo $b | sed -e 's/.*\///g'); 
done; \
+   echo $x)
+ %define rtems_ab_archs  \
+  %(x=''; \
+   for b in %{rtems_bsp}; do x="$x "$(echo $b | sed -e 's/\/.*//g'); 
done; \
+   echo $x | tr ' ' '\n' | sort | uniq)
+ %define rtems_arch_count %(echo %{rtems_ab_archs} | tr ' ' '\n' | wc -l)
+ %if %{rtems_arch_count} != 1
+  %error Invalid BSP architecture count
+ %endif
+ %define rtems_bsp%{rtems_ab_bsps}
+ %define rtems_target %{rtems_ab_archs}-rtems%{rtems_version}
+ %define rtems_host   %{rtems_target}
+%endif
+
+%define rtems_bsp_count %(echo %{rtems_bsp} | tr ' ' '\n' | wc -l)
+%if %{rtems_bsp_count} != 1
+  %error Building packages with more than one BSP is not supported
+%endif
+
 #
 # We need a host from the user to specifiy the RTEMS architecture and major
 # version. It can be defined in rtems_host.
@@ -52,17 +90,6 @@
  %endif
 %endif
 
-#
-# We need a BSP from the user.
-#
-%ifn %{defined with_rtems_bsp}
- %if %{rtems_bsp_error}
-  %error No RTEMS BSP specified: --with-rtems-bsp=bsp
- %endif
- %define with_rtems_bsp sparc/erc32
-%endif
-%define rtems_bsp %{with_rtems_bsp}
-
 #
 # If no tools or RTEMS provided use the prefix. If staging use the staging
 # root.
@@ -215,14 +242,14 @@
 #
 # Note: default BSP flags include the standard RTEMS libraries.
 #
-%define rtems-dep-check %(%{_sbdir}/sb/rtems-build-dep -c 
%{with_tools}/bin/%{rtems_bsp_cc}
+%define rtems-dep-check %{_sbdir}/sb/rtems-build-dep -c 
%{with_tools}/bin/%{rtems_bsp_cc}
 
-%define rtems-libbsd %{rtems-dep-check} -L %{rtems_bsp_libpath} -l libbsd.a)
+%define rtems-libbsd %(%{rtems-dep-check} -L %{rtems_bsp_libpath} -l libbsd.a)
 %if %{rtems-libbsd} == found
  %define rtems_bsp_libs %{rtems_bsp_libs} -lbsd -lm -lz
 %endif
 
-%define rtems-defaultconfig %{rtems-dep-check} -L %{rtems_bsp_libpath} -l 
librtemsdefaultconfig.a)
+%define rtems-defaultconfig %(%{rtems-dep-check} -L %{rtems_bsp_libpath} -l 
librtemsdefaultconfig.a)
 %if %{rtems-defaultconfig} == found
  %define rtems_bsp_libs %{rtems_bsp_libs} -lrtemsdefaultconfig
 %endif
-- 
2.37.1

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


[RSB 5 PATCH 2/3] sb/set-bulder: Fix installing builds when a single buildset

2022-09-30 Thread chrisj
From: Chris Johns 

- Always stage a build

- Install if installable and outter most buildset instance

Closes #4731
---
 source-builder/sb/setbuilder.py | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/source-builder/sb/setbuilder.py b/source-builder/sb/setbuilder.py
index db9446f..41f5589 100644
--- a/source-builder/sb/setbuilder.py
+++ b/source-builder/sb/setbuilder.py
@@ -227,7 +227,7 @@ class buildset:
 return self.install_mode() == 'installing'
 
 def installable(self):
-return not self.opts.no_install() or self.staging()
+return not self.opts.no_install() and self.installing()
 
 def staging(self):
 return not self.installing()
@@ -436,7 +436,7 @@ class buildset:
 # If installing switch to staging. Not sure if this is still
 # needed.
 #
-if self.installing():
+if nesting_count > 1 and self.installing():
 self.macros['install_mode'] = 'staging'
 
 try:
@@ -538,10 +538,10 @@ class buildset:
 #
 # Installing or staging ...
 #
-log.trace('_bset: %2d: %s: deps:%r no-install:%r' % \
+log.trace('_bset: %2d: mode: %s: deps:%r no-install:%r' % \
   (nesting_count, self.install_mode(),
deps is None, self.opts.no_install()))
-log.trace('_bset: %2d: %s: builds: %s' % \
+log.trace('_bset: %2d: mode: %s: builds: %s' % \
   (nesting_count, self.install_mode(),
', '.join([b.name() for b in builds])))
 if deps is None and not have_errors:
@@ -551,10 +551,9 @@ class buildset:
 if b.installable():
 prefix = b.config.expand('%{_prefix}')
 buildroot = path.join(b.config.expand('%{buildroot}'), 
prefix)
-if self.staging():
-prefix = b.config.expand('%{stagingroot}')
+self.install('staging', b.name(), buildroot, 
b.config.expand('%{stagingroot}'))
 if self.installable():
-self.install(self.install_mode(), b.name(), 
buildroot, prefix)
+self.install('installing', b.name(), buildroot, 
prefix)
 #
 # Sizes ...
 #
@@ -610,7 +609,7 @@ class buildset:
 #
 # If builds have been staged install into the final prefix.
 #
-if not have_errors:
+if self.installing() and not have_errors:
 stagingroot = macro_expand(self.macros, '%{stagingroot}')
 have_stagingroot = path.exists(stagingroot)
 do_install = not self.opts.no_install()
-- 
2.37.1

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


[RSB 5] Fixes to recent changes and a deployment change

2022-09-30 Thread chrisj
Hi,

If these changes are OK I will push the same patches to the devel
branch.

Chris


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


[RSB 5 PATCH 1/3] sb/execute: Fix incremental decoder with --dry-run

2022-09-30 Thread chrisj
From: Chris Johns 

Closes #4734
---
 source-builder/sb/execute.py | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/source-builder/sb/execute.py b/source-builder/sb/execute.py
index f470aba..e3809ec 100755
--- a/source-builder/sb/execute.py
+++ b/source-builder/sb/execute.py
@@ -182,7 +182,10 @@ class execute(object):
 
 if trace_threads:
 print('execute:_readthread: start')
-decoder = codecs.getincrementaldecoder(sys.stdout.encoding)()
+if sys.stdout.encoding is not None:
+decoder = codecs.getincrementaldecoder(sys.stdout.encoding)()
+else:
+decoder = None
 count = 0
 line = ''
 try:
@@ -202,7 +205,7 @@ class execute(object):
 _output_line(line + '\n', exe, prefix, out, count)
 break
 # str and bytes are the same type in Python2
-if type(data) is not str and type(data) is bytes:
+if decoder is not None and type(data) is not str and 
type(data) is bytes:
 data = decoder.decode(data)
 last_ch = data[-1]
 sd = (line + data).split('\n')
-- 
2.37.1

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


Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build

2022-09-30 Thread Christian MAUDERER

Am 30.09.22 um 08:48 schrieb Chris Johns:

On 30/9/2022 4:08 pm, Christian MAUDERER wrote:

Am 30.09.22 um 07:37 schrieb Chris Johns:

On 30/9/2022 3:33 pm, Christian MAUDERER wrote:

Am 30.09.22 um 05:49 schrieb Chris Johns:

On 29/9/2022 9:50 pm, Chris Johns wrote:

On 29/9/22 9:45 pm, Christian MAUDERER wrote:

Hello Chris,

thanks for the quick patch. With this qemu and microblaze work again like
expected.

I tested all tools starting with devel/* and from the ones that work only
devel/autotools-internal didn't generate a tar archive. But that one has a
comment "Do not use via the command line" in the bset file so that is most
likely fine.

Some of other devel/* packages didn't build in my test setup, but I have
never
tested or used them before so that is probably a problem of my build
environment
or maybe a known bug.


Thanks for the testing. I will push to the devel branch and 5.



Tarfile creation is working however installing is not. I am working on fixing
this.

Chris


Sorry that I missed that. I only tried to generate the tar archives.


Same. Testing a fix but it takes time to check properly.

I am wondering if I can create a test mode in the deployment repo. The hard part
is how to automatically check the build has worked.

Chris


I'm currently trying to create a basic CI/CD setup for testing our embedded
brains patches using GitHub. At the moment it's still quite experimental and
still a bit thrown together but it basically runs:

https://github.com/embedded-brains/rtems-source-builder/actions/runs/3151126889


Nice.


It didn't catch that bug because it doesn't use installed tools for the
simulator runs, but maybe I can change that.

If it works well enough, we maybe could re-use some scripts or work flows to set
up an official RTEMS CI/CD with whatever community preferred CI system. It
shouldn't be too big of a problem to port the logic to Gitlab CI, Cirrus CI or
any other modern CI system.


I have started https://git.rtems.org/chrisj/rtems-deployment.git/. I would like
it to be the landing place for this type of stuff if it fits. The repo is being
actively worked on by me.


I have seen that repo after you mentioned it recently, but I have to 
admit I haven't looked at it yet. From the name I have guessed that it 
is more for building release versions and not for continuous checks. 
I'll take a more detailed look.




I can build RPMs on Rocky 8 and 9. These RPMs are the base for EPICS RPMs built
into docker containers used to build Gemini's EPICS based systems. All handled
via CI in gitlab.


That's quite interesting. Do you have a public GitLab instance where you 
build these or is that a private instance? The rtems-deployment repo 
doesn't have a .gitlab-ci.yml. Did you keep that separate?


Best regards

Christian



To build an RPM you configure with the path to the RSB and then run `./waf
rpmspec`. A spec file is created you can use with `rpmbuild` to make an RPM. I
am keeping the generation and building of the RPM separate. By default the repo
builds a tarfile.

Once this repo stabilises I would like to see if it can move to the top level. I
am working on better documentation for it and with that some constraints about
what is offered.

Deployment is something varies and I hope this repo can grow to make common
solutions widely available. I am fine for organisation to send in specific
configurations if they are open to having them in the repo.

Chris


--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email:  christian.maude...@embedded-brains.de
phone:  +49-89-18 94 741 - 18
mobile: +49-176-152 206 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