[PATCH] doxygen: Replace main page

[Sebastian Huber]

Replace the main page with a high level description of the RTEMS feature
set similar to:

https://docs.rtems.org/branches/master/user/overview/index.html#features

The replaced content can be found in the RTEMS Classic API Guide:

https://docs.rtems.org/branches/master/c-user/overview.html

https://docs.rtems.org/branches/master/c-user/key_concepts.html

Update #3705.
---
 cpukit/include/rtems/rtems/mainpage.h | 1078 -
 1 file changed, 166 insertions(+), 912 deletions(-)

diff --git a/cpukit/include/rtems/rtems/mainpage.h 
b/cpukit/include/rtems/rtems/mainpage.h
index f168cc3395..d284429d20 100644
--- a/cpukit/include/rtems/rtems/mainpage.h
+++ b/cpukit/include/rtems/rtems/mainpage.h
@@ -10,8 +10,7 @@
  */
 
 /*
- *  COPYRIGHT (c) 1989-2014.
- *  On-Line Applications Research Corporation (OAR).
+ * Copyright (C) 2021 embedded brains GmbH & Co. KG
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -38,914 +37,169 @@
 /**
  * @mainpage
  *
- * The RTEMS real-time operating systems is a layered system with each of the
- * public APIs implemented in terms of a common foundation layer called the
- * SuperCore.  This is the Doxygen generated documentation for the RTEMS CPU
- * Kit including the Classic API, POSIX API and SuperCore.
- */
-
-/**
- * @page RTEMSPreface RTEMS History and Introduction
- *
- * In recent years, the cost required to develop a software product has
- * increased significantly while the target hardware costs have decreased. Now
- * a larger portion of money is expended in developing, using, and maintaining
- * software. The trend in computing costs is the complete dominance of software
- * over hardware costs. Because of this, it is necessary that formal
- * disciplines be established to increase the probability that software is
- * characterized by a high degree of correctness, maintainability, and
- * portability. In addition, these disciplines must promote practices that aid
- * in the consistent and orderly development of a software system within
- * schedule and budgetary constraints. To be effective, these disciplines must
- * adopt standards which channel individual software efforts toward a common
- * goal.
- *
- * The push for standards in the software development field has been met with
- * various degrees of success. The Microprocessor Operating Systems Interfaces
- * (MOSI) effort has experienced only limited success. As popular as the UNIX
- * operating system has grown, the attempt to develop a standard interface
- * definition to allow portable application development has only recently begun
- * to produce the results needed in this area. Unfortunately, very little
- * effort has been expended to provide standards addressing the needs of the
- * real-time community. Several organizations have addressed this need during
- * recent years.
- *
- * The Real Time Executive Interface Definition (RTEID) was developed by
- * Motorola with technical input from Software Components Group. RTEID was
- * adopted by the VMEbus International Trade Association (VITA) as a baseline
- * draft for their proposed standard multiprocessor, real-time executive
- * interface, Open Real-Time Kernel Interface Definition (ORKID). These two
- * groups are currently working together with the IEEE P1003.4 committee to
- * insure that the functionality of their proposed standards is adopted as the
- * real-time extensions to POSIX.
- *
- * This emerging standard defines an interface for the development of real-time
- * software to ease the writing of real-time application programs that are
- * directly portable across multiple real-time executive implementations. This
- * interface includes both the source code interfaces and run-time behavior as
- * seen by a real-time application. It does not include the details of how a
- * kernel implements these functions. The standard's goal is to serve as a
- * complete definition of external interfaces so that application code that
- * conforms to these interfaces will execute properly in all real-time
- * executive environments. With the use of a standards compliant executive,
- * routines that acquire memory blocks, create and manage message queues,
- * establish and use semaphores, and send and receive signals need not be
- * redeveloped for a different real-time environment as long as the new
- * environment is compliant with the standard. Software developers need only
- * concentrate on the hardware dependencies of the real-time system.
- * Furthermore, most hardware dependencies for real-time applications can be
- * localized to the device drivers.
- *
- * A compliant executive provides simple and flexible real-time
- * multiprocessing. It easily lends itself to both tightly-coupled and
- * loosely-coupled configurations (depending on the system hardware
- * configuration). Objects such as tasks, queues, events, signals, semaphores,
- * 

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

[Sebastian Huber]

On 26.07.23 06:58, Sebastian Huber wrote:

On 26.07.23 00:08, Chris Johns wrote:

On 26/7/2023 4:27 am, Joel Sherrill wrote:

On Tue, Jul 25, 2023 at 12:15 PM Sebastian Huber
>

wrote:

 On 25.07.23 19:09, Joel Sherrill wrote:
 >
 > On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber
 > mailto:sebastian.hu...@embedded-brains.de>
 > >> wrote:
 >
 >     Allow the user to set the version control key.
 >     ---
 >       spec/build/cpukit/grp.yml             |  2 ++
 >       spec/build/cpukit/optversionvckey.yml | 20 ++
 >       wscript                               | 38 
---

 >       3 files changed, 44 insertions(+), 16 deletions(-)
 >       create mode 100644 spec/build/cpukit/optversionvckey.yml
 >
 >     diff --git a/spec/build/cpukit/grp.yml 
b/spec/build/cpukit/grp.yml

 >     index e07e975d7d..fbeab45b5c 100644
 >     --- a/spec/build/cpukit/grp.yml
 >     +++ b/spec/build/cpukit/grp.yml
 >     @@ -18,6 +18,8 @@ links:
 >         uid: cpuopts
 >       - role: build-dependency
 >         uid: cfghdr
 >     +- role: build-dependency
 >     +  uid: optversionvckey
 >       - role: build-dependency
 >         uid: libdebugger
 >       - role: build-dependency
 >     diff --git a/spec/build/cpukit/optversionvckey.yml
 >     b/spec/build/cpukit/optversionvckey.yml
 >     new file mode 100644
 >     index 00..7197381342
 >     --- /dev/null
 >     +++ b/spec/build/cpukit/optversionvckey.yml
 >     @@ -0,0 +1,20 @@
 >     +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 >     +actions:
 >     +- get-string: null
 >     +- env-assign: null
 >     +build-type: option
 >     +copyrights:
 >     +- Copyright (C) 2022, 2023 embedded brains GmbH & Co. KG
 >     +default:
 >     +- enabled-by: true
 >     +  value: ''
 >     +description: |
 >     +  If defined to a non-empty value, then the value will be 
used for

 >     the version
 >     +  control key returned by rtems_version() and
 >     rtems_version_control_key(),
 >     +  otherwise the value will be determined by the Git 
repository

 >     containing the
 >     +  waf top directory.
 >
 >
 > And would this change for a release tarball?

 Which RTEMS_VERSION_VC_KEY has a release tarball? What happens 
if you

 unpack an release archive in an external Git repository?


I don't know but think we should discuss it.

Chris should speak up since the release scripts are his and this
might be used by the distribution packaging he has made available.
I am not sure what the purpose of this change is. It would be good to 
understand
what it is for. The RTEMS_VERSION_VC_KEY could mean a number of things 
such as a

means to set the git hash in sources not in a git repo but that is guess.


Yes, this is helpful if you have the RTEMS sources not in a Git 
repository or the Git repository has the wrong commit (git subtree for 
example).


It could be also useful for the release archive. We could use this scheme:

* If the value is "git", then get the value from git.

* If the value is "", then we use no version key.

* Otherwise we set the key to the value.

For the release archive we would set the default value of the option 
from "git" to "".


I sent a patch with this approach:

https://lists.rtems.org/pipermail/devel/2023-July/075989.html

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

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

[PATCH v2] build: Add optional RTEMS_VERSION_CONTROL_KEY

[Sebastian Huber]

Allow the user to set the version control key.
---
 spec/build/cpukit/grp.yml  |  2 ++
 spec/build/cpukit/optversioncontrolkey.yml | 21 
 wscript| 38 +-
 3 files changed, 45 insertions(+), 16 deletions(-)
 create mode 100644 spec/build/cpukit/optversioncontrolkey.yml

diff --git a/spec/build/cpukit/grp.yml b/spec/build/cpukit/grp.yml
index e07e975d7d..eeaefcba91 100644
--- a/spec/build/cpukit/grp.yml
+++ b/spec/build/cpukit/grp.yml
@@ -18,6 +18,8 @@ links:
   uid: cpuopts
 - role: build-dependency
   uid: cfghdr
+- role: build-dependency
+  uid: optversioncontrolkey
 - role: build-dependency
   uid: libdebugger
 - role: build-dependency
diff --git a/spec/build/cpukit/optversioncontrolkey.yml 
b/spec/build/cpukit/optversioncontrolkey.yml
new file mode 100644
index 00..36dfeeb82a
--- /dev/null
+++ b/spec/build/cpukit/optversioncontrolkey.yml
@@ -0,0 +1,21 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- env-assign: null
+build-type: option
+copyrights:
+- Copyright (C) 2022, 2023 embedded brains GmbH & Co. KG
+default:
+- enabled-by: true
+  value: git
+description: |
+  This option defines what is returned by the directives rtems_version() and
+  rtems_version_control_key().  If the value is "git", then the version key is
+  determined by the Git repository containing the waf top directory for each
+  build process.  If the value is the empty string "", then no version key is
+  used.  Otherwise, the value is used as the version key.
+enabled-by: true
+format: '{}'
+links: []
+name: RTEMS_VERSION_CONTROL_KEY
+type: build
diff --git a/wscript b/wscript
index 862000513d..e80c3800b6 100755
--- a/wscript
+++ b/wscript
@@ -58,38 +58,44 @@ def no_unicode(value):
 
 
 class VersionControlKeyHeader:
-_content = None
+_git_commit = None
 
 @staticmethod
 def write(bld, filename):
-if VersionControlKeyHeader._content is None:
-from waflib.Build import Context
-from waflib.Errors import WafError
-
-content = """/*
+content = """/*
  * Automatically generated. Do not edit.
  */
 #if !defined(_RTEMS_VERSION_VC_KEY_H_)
 #define _RTEMS_VERSION_VC_KEY_H_
 """
-try:
-rev = bld.cmd_and_log("git rev-parse HEAD",
-  quiet=Context.STDOUT).strip()
-content += """#define RTEMS_VERSION_VC_KEY "{}"
+rev = bld.env.RTEMS_VERSION_CONTROL_KEY
+if rev == "git":
+rev = VersionControlKeyHeader._git_commit
+if rev is None:
+from waflib.Build import Context
+from waflib.Errors import WafError
+
+try:
+rev = bld.cmd_and_log("git rev-parse HEAD",
+  quiet=Context.STDOUT).strip()
+except WafError:
+rev = ""
+VersionControlKeyHeader._git_commit = rev
+if rev:
+content += """#define RTEMS_VERSION_VC_KEY "{}"
 """.format(rev)
-except WafError:
-content += """/* No version control key found; release? */
+else:
+content += """/* No version control key found; release? */
 """
-content += """#endif
+content += """#endif
 """
-VersionControlKeyHeader._content = content
 f = bld.bldnode.make_node(filename)
 f.parent.mkdir()
 try:
 if content != f.read():
-f.write(VersionControlKeyHeader._content)
+f.write(content)
 except:
-f.write(VersionControlKeyHeader._content)
+f.write(content)
 
 
 class EnvWrapper(object):
-- 
2.35.3

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

Re: style patches - discuss

[Sebastian Huber]

On 25.07.23 23:41, Gedare Bloom wrote:

I have sent two initial patches to begin the style reformat. The
clang-format file is not quite 100%, and it's also not usable by
anyone else (as I wait for changes to be accepted upstream).

A few things to note:
* We can always manually override style with good reason. If you see
something like that in a patch, please let me know.
* I have started to avoid changing the __asm __ ... blocks, as
clang-format doesn't do a great job with those at the moment.
* clang-format also doesn't know how to indent broken if/for loops
like we prefer. So i may need to continue manual intervention on those
until I can get around to teaching it how. I believe that is doable,
but will take me some time to implement and get upstream.
* clang-format also has a preference to break function declarations
differently than we do. It will prefer to break after the function
return type/decorators, rather than in the parameter list. This may be
something we can tune. For now, I fix this manually.

I may prepare a few more patches tomorrow, but I will leave these two
for the time being for feedback.


Thanks for the samples. A good test file is 
cpukit/score/src/threadqenqueue.c.


In the samples, there are a lot of changes in everything involving () 
and []. I think we should either


* aim for a configuration which performs a minimum set of changes in 
files which are close to the existing score style, or


* choose a standard style.

--
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] score/arm: style fixes

[Sebastian Huber]

On 25.07.23 23:38, Gedare Bloom wrote:

diff --git a/cpukit/score/cpu/arm/aarch32-psma-init.c 
b/cpukit/score/cpu/arm/aarch32-psma-init.c
index 93a3673a98..b30cb5e308 100644
--- a/cpukit/score/cpu/arm/aarch32-psma-init.c
+++ b/cpukit/score/cpu/arm/aarch32-psma-init.c
@@ -46,7 +46,7 @@
  #include 
  
  #define AARCH32_PMSA_REGION_MAX \

-  ( ( AARCH32_MPUIR_REGION_MASK >> AARCH32_MPUIR_REGION_SHIFT ) + 1 )
+  ((AARCH32_MPUIR_REGION_MASK >> AARCH32_MPUIR_REGION_SHIFT) + 1)
  
  static void _AArch32_PMSA_Configure(

const AArch32_PMSA_Region *regions,
@@ -57,36 +57,36 @@ static void _AArch32_PMSA_Configure(
size_t   ri;
uint32_t sctlr;
  
-  for ( ri = 0 ; ri < region_used; ++ri ) {

+  for ( ri = 0; ri < region_used; ++ri ) {
  uint32_t prbar;
  uint32_t prlar;
  uint32_t attr;
  
-prbar = regions[ ri ].base;

-prlar = regions[ ri ].limit;
-attr = regions[ ri ].attributes;
+prbar = regions[ri].base;
+prlar = regions[ri].limit;
+attr  = regions[ri].attributes;
  
-prbar |= ( attr >> 6 ) & 0x3fU;

+prbar |= (attr >> 6) & 0x3fU;
  prlar |= attr & 0x3fU;
  
-_AArch32_Write_prselr( ri );

+_AArch32_Write_prselr(ri);
  _ARM_Instruction_synchronization_barrier();
-_AArch32_Write_prbar( prbar );
-_AArch32_Write_prlar( prlar );
+_AArch32_Write_prbar(prbar);
+_AArch32_Write_prlar(prlar);
}


The existing style had the spaces which are removed here. I think this 
would lead to a lot of changes in score.


--
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] build: Add optional RTEMS_VERSION_VC_KEY

[Sebastian Huber]

On 26.07.23 00:08, Chris Johns wrote:

On 26/7/2023 4:27 am, Joel Sherrill wrote:

On Tue, Jul 25, 2023 at 12:15 PM Sebastian Huber
mailto:sebastian.hu...@embedded-brains.de>>
wrote:

 On 25.07.23 19:09, Joel Sherrill wrote:
 >
 > On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber
 > mailto:sebastian.hu...@embedded-brains.de>
 > >> wrote:
 >
 >     Allow the user to set the version control key.
 >     ---
 >       spec/build/cpukit/grp.yml             |  2 ++
 >       spec/build/cpukit/optversionvckey.yml | 20 ++
 >       wscript                               | 38 
---
 >       3 files changed, 44 insertions(+), 16 deletions(-)
 >       create mode 100644 spec/build/cpukit/optversionvckey.yml
 >
 >     diff --git a/spec/build/cpukit/grp.yml b/spec/build/cpukit/grp.yml
 >     index e07e975d7d..fbeab45b5c 100644
 >     --- a/spec/build/cpukit/grp.yml
 >     +++ b/spec/build/cpukit/grp.yml
 >     @@ -18,6 +18,8 @@ links:
 >         uid: cpuopts
 >       - role: build-dependency
 >         uid: cfghdr
 >     +- role: build-dependency
 >     +  uid: optversionvckey
 >       - role: build-dependency
 >         uid: libdebugger
 >       - role: build-dependency
 >     diff --git a/spec/build/cpukit/optversionvckey.yml
 >     b/spec/build/cpukit/optversionvckey.yml
 >     new file mode 100644
 >     index 00..7197381342
 >     --- /dev/null
 >     +++ b/spec/build/cpukit/optversionvckey.yml
 >     @@ -0,0 +1,20 @@
 >     +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 >     +actions:
 >     +- get-string: null
 >     +- env-assign: null
 >     +build-type: option
 >     +copyrights:
 >     +- Copyright (C) 2022, 2023 embedded brains GmbH & Co. KG
 >     +default:
 >     +- enabled-by: true
 >     +  value: ''
 >     +description: |
 >     +  If defined to a non-empty value, then the value will be used for
 >     the version
 >     +  control key returned by rtems_version() and
 >     rtems_version_control_key(),
 >     +  otherwise the value will be determined by the Git repository
 >     containing the
 >     +  waf top directory.
 >
 >
 > And would this change for a release tarball?

 Which RTEMS_VERSION_VC_KEY has a release tarball? What happens if you
 unpack an release archive in an external Git repository?


I don't know but think we should discuss it.

Chris should speak up since the release scripts are his and this
might be used by the distribution packaging he has made available.

I am not sure what the purpose of this change is. It would be good to understand
what it is for. The RTEMS_VERSION_VC_KEY could mean a number of things such as a
means to set the git hash in sources not in a git repo but that is guess.


Yes, this is helpful if you have the RTEMS sources not in a Git 
repository or the Git repository has the wrong commit (git subtree for 
example).


It could be also useful for the release archive. We could use this scheme:

* If the value is "git", then get the value from git.

* If the value is "", then we use no version key.

* Otherwise we set the key to the value.

For the release archive we would set the default value of the option 
from "git" to "".


--
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] build: Export BSP base and family via pkg-config

[Sebastian Huber]

On 25.07.23 20:26, Joel Sherrill wrote:


On Tue, Jul 25, 2023 at 12:19 PM Sebastian Huber 
> wrote:




On 25.07.23 19:15, Gedare Bloom wrote:
 > On Tue, Jul 25, 2023 at 11:11 AM Sebastian Huber
 > mailto:sebastian.hu...@embedded-brains.de>>  wrote:
 >>
 >>
 >> On 25.07.23 18:01, Gedare Bloom wrote:
 >>> On Tue, Jul 25, 2023 at 5:13 AM Sebastian Huber
 >>> mailto:sebastian.hu...@embedded-brains.de>>   wrote:
  This allows application and library build systems to derive option
  values from the BSP base and family names.
  ---
     spec/build/bsps/pkgconfig.yml | 2 ++
     1 file changed, 2 insertions(+)
 
  diff --git a/spec/build/bsps/pkgconfig.yml
b/spec/build/bsps/pkgconfig.yml
  index e08c83fe27..afaffbbf0f 100644
  --- a/spec/build/bsps/pkgconfig.yml
  +++ b/spec/build/bsps/pkgconfig.yml
  @@ -15,6 +15,8 @@ content: |
       ABI_FLAGS=${ABI_FLAGS}
       RTEMS_ARCH=${ARCH}
       RTEMS_BSP=${BSP_NAME}
  +  RTEMS_BSP_BASE=${BSP_BASE}
  +  RTEMS_BSP_FAMILY=${BSP_FAMILY}
 >>> These expose a little bit of the internal working of the build
system.
 >>> I think it's fine, since these two fields should not change
over time.
 >>> But, it commits us to maintain this mapping and these variables.
 >> We had the RTEMS_BSP also in the old build system, but it was
actually
 >> what is now the RTEMS_BSP_BASE in this patch. With the
user-defined BSP
 >> names we have for:
 >>
 >> [arch/user_bsp_name]
 >> INHERIT = system_bsp_name
 >>
 >> This results in:
 >>
 >> RTEMS_BSP = user_bsp_name
 >> RTEMS_BSP_BASE = system_bsp_name
 >>
 >> Maybe we should change this to:
 >>
 >> RTEMS_BSP = system_bsp_name
 >> RTEMS_BSP_NAME = user_bsp_name
 >>
 > This would make more sense. I don't know what it might break to make
 > this change now though, as external build tools may rely on the
 > current definition of RTEMS_BSP?

Yes, this is a bit tricky since the BSP name is also encoded in the
*.pc
file name: ${arch}-rtems6-{user_bsp_name}.pc. This is an argument for
keeping RTEMS_BSP = user_bsp_name.


I would agree with that since that's the name the user expects and will be
part of any installed path, pkg config file, etc.

That leaves RTEMS_BSP_NAME is not great. How about RTEMS_BSP_CANONICAL?


I would not reinvent a new name. In the documentation this canonical is 
called base. So, I think the patch is fine as is.


--
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] score/arm: style fixes

[Gedare Bloom]

On Tue, Jul 25, 2023 at 5:03 PM Joel Sherrill  wrote:
>
>
>
> On Tue, Jul 25, 2023 at 5:53 PM Gedare Bloom  wrote:
>>
>> On Tue, Jul 25, 2023 at 4:48 PM Joel Sherrill  wrote:
>> >
>> > I may have missed something. Commented in one place.
>> >
>> > It looks like mostly spaces inside () and variable/parameter declaration 
>> > changes.
>> >
>> Yes, for the most part those are the least consistent so far.
>>
>> > On Tue, Jul 25, 2023 at 4:38 PM Gedare Bloom  wrote:
>> >> diff --git a/cpukit/score/cpu/arm/armv7m-isr-dispatch.c 
>> >> b/cpukit/score/cpu/arm/armv7m-isr-dispatch.c
>> >> index ea168969ba..dfc125d545 100644
>> >> --- a/cpukit/score/cpu/arm/armv7m-isr-dispatch.c
>> >> +++ b/cpukit/score/cpu/arm/armv7m-isr-dispatch.c
>> >> @@ -43,7 +43,7 @@
>> >>
>> >>  #ifdef ARM_MULTILIB_ARCH_V7M
>> >>
>> >> -static void __attribute__((naked)) _ARMV7M_Thread_dispatch( void )
>> >> +static void __attribute__((naked)) _ARMV7M_Thread_dispatch(void)
>> >>  {
>> >>__asm__ volatile (
>> >>  "bl _Thread_Dispatch\n"
>> >> @@ -53,7 +53,7 @@ static void __attribute__((naked)) 
>> >> _ARMV7M_Thread_dispatch( void )
>> >>);
>> >>  }
>> >>
>> >> -static void _ARMV7M_Trigger_lazy_floating_point_context_save( void )
>> >> +static void _ARMV7M_Trigger_lazy_floating_point_context_save(void)
>> >>  {
>> >>  #ifdef ARM_MULTILIB_VFP
>> >>__asm__ volatile (
>> >> @@ -62,7 +62,7 @@ static void 
>> >> _ARMV7M_Trigger_lazy_floating_point_context_save( void )
>> >>  #endif
>> >>  }
>> >>
>> >> -void _ARMV7M_Pendable_service_call( void )
>> >> +void _ARMV7M_Pendable_service_call(void)
>> >>  {
>> >>Per_CPU_Control *cpu_self = _Per_CPU_Get();
>> >>
>> >> @@ -73,7 +73,7 @@ void _ARMV7M_Pendable_service_call( void )
>> >> * this interrupt service may be delayed until interrupts are enable 
>> >> again.
>> >> */
>> >>if (
>> >> -( cpu_self->isr_nest_level | cpu_self->thread_dispatch_disable_level 
>> >> ) == 0
>> >> +(cpu_self->isr_nest_level | cpu_self->thread_dispatch_disable_level) 
>> >> == 0
>> >>) {
>> >
>> >
>> > Does this fit on a single line?
>> >
>> No. it's like two characters short. In fact, i had to do this one
>> manually. otherwise, it breaks as
>> if ( (...
>> ) == 0 ) {
>
>
> ! instead of == 0? :)

I'm not sure I want to nitpick on code changes during this pass. Feel
free to send a patch for code changes though ;)

>>
>>
>> > Ignoring the fact it is using bitwise operations on two integer counters. 
>> > Perhaps
>> > it should be a +?
>> >
>> separate problem I suppose. That is a little bit of a suspicious bit of 
>> logic.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score/arm: style fixes

[Joel Sherrill]

On Tue, Jul 25, 2023 at 5:53 PM Gedare Bloom  wrote:

> On Tue, Jul 25, 2023 at 4:48 PM Joel Sherrill  wrote:
> >
> > I may have missed something. Commented in one place.
> >
> > It looks like mostly spaces inside () and variable/parameter declaration
> changes.
> >
> Yes, for the most part those are the least consistent so far.
>
> > On Tue, Jul 25, 2023 at 4:38 PM Gedare Bloom  wrote:
> >> diff --git a/cpukit/score/cpu/arm/armv7m-isr-dispatch.c
> b/cpukit/score/cpu/arm/armv7m-isr-dispatch.c
> >> index ea168969ba..dfc125d545 100644
> >> --- a/cpukit/score/cpu/arm/armv7m-isr-dispatch.c
> >> +++ b/cpukit/score/cpu/arm/armv7m-isr-dispatch.c
> >> @@ -43,7 +43,7 @@
> >>
> >>  #ifdef ARM_MULTILIB_ARCH_V7M
> >>
> >> -static void __attribute__((naked)) _ARMV7M_Thread_dispatch( void )
> >> +static void __attribute__((naked)) _ARMV7M_Thread_dispatch(void)
> >>  {
> >>__asm__ volatile (
> >>  "bl _Thread_Dispatch\n"
> >> @@ -53,7 +53,7 @@ static void __attribute__((naked))
> _ARMV7M_Thread_dispatch( void )
> >>);
> >>  }
> >>
> >> -static void _ARMV7M_Trigger_lazy_floating_point_context_save( void )
> >> +static void _ARMV7M_Trigger_lazy_floating_point_context_save(void)
> >>  {
> >>  #ifdef ARM_MULTILIB_VFP
> >>__asm__ volatile (
> >> @@ -62,7 +62,7 @@ static void
> _ARMV7M_Trigger_lazy_floating_point_context_save( void )
> >>  #endif
> >>  }
> >>
> >> -void _ARMV7M_Pendable_service_call( void )
> >> +void _ARMV7M_Pendable_service_call(void)
> >>  {
> >>Per_CPU_Control *cpu_self = _Per_CPU_Get();
> >>
> >> @@ -73,7 +73,7 @@ void _ARMV7M_Pendable_service_call( void )
> >> * this interrupt service may be delayed until interrupts are enable
> again.
> >> */
> >>if (
> >> -( cpu_self->isr_nest_level |
> cpu_self->thread_dispatch_disable_level ) == 0
> >> +(cpu_self->isr_nest_level |
> cpu_self->thread_dispatch_disable_level) == 0
> >>) {
> >
> >
> > Does this fit on a single line?
> >
> No. it's like two characters short. In fact, i had to do this one
> manually. otherwise, it breaks as
> if ( (...
> ) == 0 ) {
>

! instead of == 0? :)

>
> > Ignoring the fact it is using bitwise operations on two integer
> counters. Perhaps
> > it should be a +?
> >
> separate problem I suppose. That is a little bit of a suspicious bit of
> logic.
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score/arm: style fixes

[Gedare Bloom]

On Tue, Jul 25, 2023 at 4:48 PM Joel Sherrill  wrote:
>
> I may have missed something. Commented in one place.
>
> It looks like mostly spaces inside () and variable/parameter declaration 
> changes.
>
Yes, for the most part those are the least consistent so far.

> On Tue, Jul 25, 2023 at 4:38 PM Gedare Bloom  wrote:
>> diff --git a/cpukit/score/cpu/arm/armv7m-isr-dispatch.c 
>> b/cpukit/score/cpu/arm/armv7m-isr-dispatch.c
>> index ea168969ba..dfc125d545 100644
>> --- a/cpukit/score/cpu/arm/armv7m-isr-dispatch.c
>> +++ b/cpukit/score/cpu/arm/armv7m-isr-dispatch.c
>> @@ -43,7 +43,7 @@
>>
>>  #ifdef ARM_MULTILIB_ARCH_V7M
>>
>> -static void __attribute__((naked)) _ARMV7M_Thread_dispatch( void )
>> +static void __attribute__((naked)) _ARMV7M_Thread_dispatch(void)
>>  {
>>__asm__ volatile (
>>  "bl _Thread_Dispatch\n"
>> @@ -53,7 +53,7 @@ static void __attribute__((naked)) 
>> _ARMV7M_Thread_dispatch( void )
>>);
>>  }
>>
>> -static void _ARMV7M_Trigger_lazy_floating_point_context_save( void )
>> +static void _ARMV7M_Trigger_lazy_floating_point_context_save(void)
>>  {
>>  #ifdef ARM_MULTILIB_VFP
>>__asm__ volatile (
>> @@ -62,7 +62,7 @@ static void 
>> _ARMV7M_Trigger_lazy_floating_point_context_save( void )
>>  #endif
>>  }
>>
>> -void _ARMV7M_Pendable_service_call( void )
>> +void _ARMV7M_Pendable_service_call(void)
>>  {
>>Per_CPU_Control *cpu_self = _Per_CPU_Get();
>>
>> @@ -73,7 +73,7 @@ void _ARMV7M_Pendable_service_call( void )
>> * this interrupt service may be delayed until interrupts are enable 
>> again.
>> */
>>if (
>> -( cpu_self->isr_nest_level | cpu_self->thread_dispatch_disable_level ) 
>> == 0
>> +(cpu_self->isr_nest_level | cpu_self->thread_dispatch_disable_level) == >> 0
>>) {
>
>
> Does this fit on a single line?
>
No. it's like two characters short. In fact, i had to do this one
manually. otherwise, it breaks as
if ( (...
) == 0 ) {

> Ignoring the fact it is using bitwise operations on two integer counters. 
> Perhaps
> it should be a +?
>
separate problem I suppose. That is a little bit of a suspicious bit of logic.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: style patches - discuss

[Gedare Bloom]

https://git.rtems.org/gedare/rtems.git/log/?h=aarch64-reformat
https://git.rtems.org/gedare/rtems.git/log/?h=arm-reformat

On Tue, Jul 25, 2023 at 3:56 PM Chris Johns  wrote:
>
> On 26/7/2023 7:41 am, Gedare Bloom wrote:
> > I have sent two initial patches to begin the style reformat. The
> > clang-format file is not quite 100%, and it's also not usable by
> > anyone else (as I wait for changes to be accepted upstream).
> >
> > A few things to note:
> > * We can always manually override style with good reason. If you see
> > something like that in a patch, please let me know.
> > * I have started to avoid changing the __asm __ ... blocks, as
> > clang-format doesn't do a great job with those at the moment.
> > * clang-format also doesn't know how to indent broken if/for loops
> > like we prefer. So i may need to continue manual intervention on those
> > until I can get around to teaching it how. I believe that is doable,
> > but will take me some time to implement and get upstream.
> > * clang-format also has a preference to break function declarations
> > differently than we do. It will prefer to break after the function
> > return type/decorators, rather than in the parameter list. This may be
> > something we can tune. For now, I fix this manually.
> >
> > I may prepare a few more patches tomorrow, but I will leave these two
> > for the time being for feedback.
>
> Is there a branch in a repo I can look at to see the files with the style 
> applied?
>
> Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] score/arm: style fixes

[Joel Sherrill]

I may have missed something. Commented in one place.

It looks like mostly spaces inside () and variable/parameter declaration
changes.

On Tue, Jul 25, 2023 at 4:38 PM Gedare Bloom  wrote:

> ---
>  cpukit/score/cpu/arm/__aeabi_read_tp.c|   2 +-
>  cpukit/score/cpu/arm/__tls_get_addr.c |   4 +-
>  .../score/cpu/arm/aarch32-psma-init-default.c |   2 +-
>  cpukit/score/cpu/arm/aarch32-psma-init.c  |  82 -
>  cpukit/score/cpu/arm/arm-exception-default.c  |   6 +-
>  .../score/cpu/arm/arm-exception-frame-print.c | 159 --
>  cpukit/score/cpu/arm/armv4-sync-synchronize.c |   2 +-
>  cpukit/score/cpu/arm/armv7-thread-idle.c  |   4 +-
>  .../score/cpu/arm/armv7m-context-initialize.c |  14 +-
>  cpukit/score/cpu/arm/armv7m-context-restore.c |   4 +-
>  .../score/cpu/arm/armv7m-exception-default.c  |  26 +--
>  .../cpu/arm/armv7m-exception-handler-get.c|   4 +-
>  .../cpu/arm/armv7m-exception-handler-set.c|  19 +--
>  .../cpu/arm/armv7m-exception-priority-get.c   |   8 +-
>  .../arm/armv7m-exception-priority-handler.c   |   8 +-
>  .../cpu/arm/armv7m-exception-priority-set.c   |   8 +-
>  cpukit/score/cpu/arm/armv7m-initialize.c  |   2 +-
>  cpukit/score/cpu/arm/armv7m-isr-dispatch.c|  20 +--
>  cpukit/score/cpu/arm/armv7m-isr-enter-leave.c |   4 +-
>  cpukit/score/cpu/arm/armv7m-isr-level-get.c   |   2 +-
>  cpukit/score/cpu/arm/armv7m-isr-level-set.c   |   4 +-
>  .../score/cpu/arm/armv7m-isr-vector-install.c |   8 +-
>  .../cpu/arm/armv7m-multitasking-start-stop.c  |   4 +-
>  cpukit/score/cpu/arm/cpu.c|  51 +++---
>  24 files changed, 209 insertions(+), 238 deletions(-)
>
> diff --git a/cpukit/score/cpu/arm/__aeabi_read_tp.c
> b/cpukit/score/cpu/arm/__aeabi_read_tp.c
> index 0f4eba8d9a..e3bc529f18 100644
> --- a/cpukit/score/cpu/arm/__aeabi_read_tp.c
> +++ b/cpukit/score/cpu/arm/__aeabi_read_tp.c
> @@ -37,8 +37,8 @@
>  #include "config.h"
>  #endif
>
> -#include 
>  #include 
> +#include 
>
>  #ifndef RTEMS_SMP
>
> diff --git a/cpukit/score/cpu/arm/__tls_get_addr.c
> b/cpukit/score/cpu/arm/__tls_get_addr.c
> index 7ef42fdcb4..fe38368812 100644
> --- a/cpukit/score/cpu/arm/__tls_get_addr.c
> +++ b/cpukit/score/cpu/arm/__tls_get_addr.c
> @@ -47,8 +47,8 @@ void *__tls_get_addr(const TLS_Index *ti);
>  void *__tls_get_addr(const TLS_Index *ti)
>  {
>const Thread_Control *executing = _Thread_Get_executing();
> -  void *tls_data = (char *) executing->Registers.thread_id
> -+ _TLS_Get_thread_control_block_area_size();
> +  void *tls_data  = (char *)
> executing->Registers.thread_id;
> +  tls_data += _TLS_Get_thread_control_block_area_size();
>
>assert(ti->module == 1);
>
> diff --git a/cpukit/score/cpu/arm/aarch32-psma-init-default.c
> b/cpukit/score/cpu/arm/aarch32-psma-init-default.c
> index 615e7a528a..8ef8b5233a 100644
> --- a/cpukit/score/cpu/arm/aarch32-psma-init-default.c
> +++ b/cpukit/score/cpu/arm/aarch32-psma-init-default.c
> @@ -42,7 +42,7 @@
>
>  #if __ARM_ARCH >= 8 && __ARM_ARCH_PROFILE == 'R'
>
> -void _AArch32_PMSA_Initialize_default( void )
> +void _AArch32_PMSA_Initialize_default(void)
>  {
>_AArch32_PMSA_Initialize(
>  AARCH32_PMSA_MEM_ATTR(
> diff --git a/cpukit/score/cpu/arm/aarch32-psma-init.c
> b/cpukit/score/cpu/arm/aarch32-psma-init.c
> index 93a3673a98..b30cb5e308 100644
> --- a/cpukit/score/cpu/arm/aarch32-psma-init.c
> +++ b/cpukit/score/cpu/arm/aarch32-psma-init.c
> @@ -46,7 +46,7 @@
>  #include 
>
>  #define AARCH32_PMSA_REGION_MAX \
> -  ( ( AARCH32_MPUIR_REGION_MASK >> AARCH32_MPUIR_REGION_SHIFT ) + 1 )
> +  ((AARCH32_MPUIR_REGION_MASK >> AARCH32_MPUIR_REGION_SHIFT) + 1)
>
>  static void _AArch32_PMSA_Configure(
>const AArch32_PMSA_Region *regions,
> @@ -57,36 +57,36 @@ static void _AArch32_PMSA_Configure(
>size_t   ri;
>uint32_t sctlr;
>
> -  for ( ri = 0 ; ri < region_used; ++ri ) {
> +  for ( ri = 0; ri < region_used; ++ri ) {
>  uint32_t prbar;
>  uint32_t prlar;
>  uint32_t attr;
>
> -prbar = regions[ ri ].base;
> -prlar = regions[ ri ].limit;
> -attr = regions[ ri ].attributes;
> +prbar = regions[ri].base;
> +prlar = regions[ri].limit;
> +attr  = regions[ri].attributes;
>
> -prbar |= ( attr >> 6 ) & 0x3fU;
> +prbar |= (attr >> 6) & 0x3fU;
>  prlar |= attr & 0x3fU;
>
> -_AArch32_Write_prselr( ri );
> +_AArch32_Write_prselr(ri);
>  _ARM_Instruction_synchronization_barrier();
> -_AArch32_Write_prbar( prbar );
> -_AArch32_Write_prlar( prlar );
> +_AArch32_Write_prbar(prbar);
> +_AArch32_Write_prlar(prlar);
>}
>
> -  for ( ri = region_used ; ri < region_max; ++ri ) {
> -_AArch32_Write_prselr( ri );
> +  for ( ri = region_used; ri < region_max; ++ri ) {
> +_AArch32_Write_prselr(ri);
>  _ARM_Instruction_synchronization_barrier();
> -_AArch32_Write_prbar( 0 );
> -_AArch32_Write_prlar( 0 );
> +_AArch32_Write_prbar(0);
> +_AArch32_Write_prlar(0);
>}

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

[Chris Johns]

On 26/7/2023 4:27 am, Joel Sherrill wrote:
> On Tue, Jul 25, 2023 at 12:15 PM Sebastian Huber
>  >
> wrote:
> 
> On 25.07.23 19:09, Joel Sherrill wrote:
> >
> > On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber
> >  
> >  >> wrote:
> >
> >     Allow the user to set the version control key.
> >     ---
> >       spec/build/cpukit/grp.yml             |  2 ++
> >       spec/build/cpukit/optversionvckey.yml | 20 ++
> >       wscript                               | 38 
> ---
> >       3 files changed, 44 insertions(+), 16 deletions(-)
> >       create mode 100644 spec/build/cpukit/optversionvckey.yml
> >
> >     diff --git a/spec/build/cpukit/grp.yml b/spec/build/cpukit/grp.yml
> >     index e07e975d7d..fbeab45b5c 100644
> >     --- a/spec/build/cpukit/grp.yml
> >     +++ b/spec/build/cpukit/grp.yml
> >     @@ -18,6 +18,8 @@ links:
> >         uid: cpuopts
> >       - role: build-dependency
> >         uid: cfghdr
> >     +- role: build-dependency
> >     +  uid: optversionvckey
> >       - role: build-dependency
> >         uid: libdebugger
> >       - role: build-dependency
> >     diff --git a/spec/build/cpukit/optversionvckey.yml
> >     b/spec/build/cpukit/optversionvckey.yml
> >     new file mode 100644
> >     index 00..7197381342
> >     --- /dev/null
> >     +++ b/spec/build/cpukit/optversionvckey.yml
> >     @@ -0,0 +1,20 @@
> >     +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> >     +actions:
> >     +- get-string: null
> >     +- env-assign: null
> >     +build-type: option
> >     +copyrights:
> >     +- Copyright (C) 2022, 2023 embedded brains GmbH & Co. KG
> >     +default:
> >     +- enabled-by: true
> >     +  value: ''
> >     +description: |
> >     +  If defined to a non-empty value, then the value will be used for
> >     the version
> >     +  control key returned by rtems_version() and
> >     rtems_version_control_key(),
> >     +  otherwise the value will be determined by the Git repository
> >     containing the
> >     +  waf top directory.
> >
> >
> > And would this change for a release tarball?
> 
> Which RTEMS_VERSION_VC_KEY has a release tarball? What happens if you
> unpack an release archive in an external Git repository?
> 
> 
> I don't know but think we should discuss it. 
> 
> Chris should speak up since the release scripts are his and this 
> might be used by the distribution packaging he has made available.

I am not sure what the purpose of this change is. It would be good to understand
what it is for. The RTEMS_VERSION_VC_KEY could mean a number of things such as a
means to set the git hash in sources not in a git repo but that is guess.

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

Re: [PATCH rtems-docs 0/2] Sphinx Version Check

[Chris Johns]

Looks good.

Thanks
Chris

On 26/7/2023 6:25 am, Joel Sherrill wrote:
> Hi
> 
> There has been Discord and email discussion that upgrading to Sphinx >=
> 6.0 breaks unordered bullet lists. But using Sphinx < 6.0 does not
> produce correct results with the patch which enabled us to use newer
> versions of Sphinx. There are two patches in this series.
> 
> (1) Reverts the patch which broke document generation. Hopefully this
> can be reapplied once someone with time and more Sphinx knowledge than I
> have figures out what is actually broken.
> 
> (2) Enhances the Sphinx version check to be able to check for a version
> greater than a minimum (current behavior) or if the Sphinx version is
> within an acceptable range. The acceptable min/max versions are set at
> the top of the file.
> 
> I think these are simple patches to unwedge documentation generation
> until a solution allowing us to upgrade is figured out. Then the minimum
> can be changed to 6.0 and maximum to None.
> 
> OK to commit?
> 
> --joel
> 
> Joel Sherrill (2):
>   layout.html: Revert patch forcing Spinx to >= 6.0
>   common/waf.py: Add option to check maximum Sphinx version
> 
>  common/sphinx_rtd_theme_rtems/layout.html |  2 --
>  common/waf.py | 17 ++---
>  2 files changed, 14 insertions(+), 5 deletions(-)
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: style patches - discuss

[Chris Johns]

On 26/7/2023 7:41 am, Gedare Bloom wrote:
> I have sent two initial patches to begin the style reformat. The
> clang-format file is not quite 100%, and it's also not usable by
> anyone else (as I wait for changes to be accepted upstream).
> 
> A few things to note:
> * We can always manually override style with good reason. If you see
> something like that in a patch, please let me know.
> * I have started to avoid changing the __asm __ ... blocks, as
> clang-format doesn't do a great job with those at the moment.
> * clang-format also doesn't know how to indent broken if/for loops
> like we prefer. So i may need to continue manual intervention on those
> until I can get around to teaching it how. I believe that is doable,
> but will take me some time to implement and get upstream.
> * clang-format also has a preference to break function declarations
> differently than we do. It will prefer to break after the function
> return type/decorators, rather than in the parameter list. This may be
> something we can tune. For now, I fix this manually.
> 
> I may prepare a few more patches tomorrow, but I will leave these two
> for the time being for feedback.

Is there a branch in a repo I can look at to see the files with the style 
applied?

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

Re: [PATCH] score/arm: style fixes

[Gedare Bloom]

On Tue, Jul 25, 2023 at 3:38 PM Gedare Bloom  wrote:
>
> ---
>  cpukit/score/cpu/arm/__aeabi_read_tp.c|   2 +-
>  cpukit/score/cpu/arm/__tls_get_addr.c |   4 +-
>  .../score/cpu/arm/aarch32-psma-init-default.c |   2 +-
>  cpukit/score/cpu/arm/aarch32-psma-init.c  |  82 -
>  cpukit/score/cpu/arm/arm-exception-default.c  |   6 +-
>  .../score/cpu/arm/arm-exception-frame-print.c | 159 --
>  cpukit/score/cpu/arm/armv4-sync-synchronize.c |   2 +-
>  cpukit/score/cpu/arm/armv7-thread-idle.c  |   4 +-
>  .../score/cpu/arm/armv7m-context-initialize.c |  14 +-
>  cpukit/score/cpu/arm/armv7m-context-restore.c |   4 +-
>  .../score/cpu/arm/armv7m-exception-default.c  |  26 +--
>  .../cpu/arm/armv7m-exception-handler-get.c|   4 +-
>  .../cpu/arm/armv7m-exception-handler-set.c|  19 +--
>  .../cpu/arm/armv7m-exception-priority-get.c   |   8 +-
>  .../arm/armv7m-exception-priority-handler.c   |   8 +-
>  .../cpu/arm/armv7m-exception-priority-set.c   |   8 +-
>  cpukit/score/cpu/arm/armv7m-initialize.c  |   2 +-
>  cpukit/score/cpu/arm/armv7m-isr-dispatch.c|  20 +--
>  cpukit/score/cpu/arm/armv7m-isr-enter-leave.c |   4 +-
>  cpukit/score/cpu/arm/armv7m-isr-level-get.c   |   2 +-
>  cpukit/score/cpu/arm/armv7m-isr-level-set.c   |   4 +-
>  .../score/cpu/arm/armv7m-isr-vector-install.c |   8 +-
>  .../cpu/arm/armv7m-multitasking-start-stop.c  |   4 +-
>  cpukit/score/cpu/arm/cpu.c|  51 +++---
>  24 files changed, 209 insertions(+), 238 deletions(-)
>
> diff --git a/cpukit/score/cpu/arm/__aeabi_read_tp.c 
> b/cpukit/score/cpu/arm/__aeabi_read_tp.c
> index 0f4eba8d9a..e3bc529f18 100644
> --- a/cpukit/score/cpu/arm/__aeabi_read_tp.c
> +++ b/cpukit/score/cpu/arm/__aeabi_read_tp.c
> @@ -37,8 +37,8 @@
>  #include "config.h"
>  #endif
>
> -#include 
>  #include 
> +#include 
>
>  #ifndef RTEMS_SMP
>
> diff --git a/cpukit/score/cpu/arm/__tls_get_addr.c 
> b/cpukit/score/cpu/arm/__tls_get_addr.c
> index 7ef42fdcb4..fe38368812 100644
> --- a/cpukit/score/cpu/arm/__tls_get_addr.c
> +++ b/cpukit/score/cpu/arm/__tls_get_addr.c
> @@ -47,8 +47,8 @@ void *__tls_get_addr(const TLS_Index *ti);
>  void *__tls_get_addr(const TLS_Index *ti)
>  {
>const Thread_Control *executing = _Thread_Get_executing();
> -  void *tls_data = (char *) executing->Registers.thread_id
> -+ _TLS_Get_thread_control_block_area_size();
> +  void *tls_data  = (char *) executing->Registers.thread_id;
This one I manually edited, as the alignment and breaking causes it to
be quite ugly. I should add a blank line here though, after the decls.
> +  tls_data += _TLS_Get_thread_control_block_area_size();
>
>assert(ti->module == 1);
>
> diff --git a/cpukit/score/cpu/arm/aarch32-psma-init-default.c 
> b/cpukit/score/cpu/arm/aarch32-psma-init-default.c
> index 615e7a528a..8ef8b5233a 100644
> --- a/cpukit/score/cpu/arm/aarch32-psma-init-default.c
> +++ b/cpukit/score/cpu/arm/aarch32-psma-init-default.c
> @@ -42,7 +42,7 @@
>
>  #if __ARM_ARCH >= 8 && __ARM_ARCH_PROFILE == 'R'
>
> -void _AArch32_PMSA_Initialize_default( void )
> +void _AArch32_PMSA_Initialize_default(void)
>  {
>_AArch32_PMSA_Initialize(
>  AARCH32_PMSA_MEM_ATTR(
> diff --git a/cpukit/score/cpu/arm/aarch32-psma-init.c 
> b/cpukit/score/cpu/arm/aarch32-psma-init.c
> index 93a3673a98..b30cb5e308 100644
> --- a/cpukit/score/cpu/arm/aarch32-psma-init.c
> +++ b/cpukit/score/cpu/arm/aarch32-psma-init.c
> @@ -46,7 +46,7 @@
>  #include 
>
>  #define AARCH32_PMSA_REGION_MAX \
> -  ( ( AARCH32_MPUIR_REGION_MASK >> AARCH32_MPUIR_REGION_SHIFT ) + 1 )
> +  ((AARCH32_MPUIR_REGION_MASK >> AARCH32_MPUIR_REGION_SHIFT) + 1)
>
>  static void _AArch32_PMSA_Configure(
>const AArch32_PMSA_Region *regions,
> @@ -57,36 +57,36 @@ static void _AArch32_PMSA_Configure(
>size_t   ri;
>uint32_t sctlr;
>
> -  for ( ri = 0 ; ri < region_used; ++ri ) {
> +  for ( ri = 0; ri < region_used; ++ri ) {
>  uint32_t prbar;
>  uint32_t prlar;
>  uint32_t attr;
>
> -prbar = regions[ ri ].base;
> -prlar = regions[ ri ].limit;
> -attr = regions[ ri ].attributes;
> +prbar = regions[ri].base;
> +prlar = regions[ri].limit;
> +attr  = regions[ri].attributes;
>
> -prbar |= ( attr >> 6 ) & 0x3fU;
> +prbar |= (attr >> 6) & 0x3fU;
>  prlar |= attr & 0x3fU;
>
> -_AArch32_Write_prselr( ri );
> +_AArch32_Write_prselr(ri);
>  _ARM_Instruction_synchronization_barrier();
> -_AArch32_Write_prbar( prbar );
> -_AArch32_Write_prlar( prlar );
> +_AArch32_Write_prbar(prbar);
> +_AArch32_Write_prlar(prlar);
>}
>
> -  for ( ri = region_used ; ri < region_max; ++ri ) {
> -_AArch32_Write_prselr( ri );
> +  for ( ri = region_used; ri < region_max; ++ri ) {
> +_AArch32_Write_prselr(ri);
>  _ARM_Instruction_synchronization_barrier();
> -_AArch32_Write_prbar( 0 );
> -_AArch32_Write_prlar( 0 );
> +_AArch32_Write_prbar(0);
> +_AArch32_Write_prlar(0);

style patches - discuss

[Gedare Bloom]

I have sent two initial patches to begin the style reformat. The
clang-format file is not quite 100%, and it's also not usable by
anyone else (as I wait for changes to be accepted upstream).

A few things to note:
* We can always manually override style with good reason. If you see
something like that in a patch, please let me know.
* I have started to avoid changing the __asm __ ... blocks, as
clang-format doesn't do a great job with those at the moment.
* clang-format also doesn't know how to indent broken if/for loops
like we prefer. So i may need to continue manual intervention on those
until I can get around to teaching it how. I believe that is doable,
but will take me some time to implement and get upstream.
* clang-format also has a preference to break function declarations
differently than we do. It will prefer to break after the function
return type/decorators, rather than in the parameter list. This may be
something we can tune. For now, I fix this manually.

I may prepare a few more patches tomorrow, but I will leave these two
for the time being for feedback.

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

[PATCH] score/arm: style fixes

[Gedare Bloom]

---
 cpukit/score/cpu/arm/__aeabi_read_tp.c|   2 +-
 cpukit/score/cpu/arm/__tls_get_addr.c |   4 +-
 .../score/cpu/arm/aarch32-psma-init-default.c |   2 +-
 cpukit/score/cpu/arm/aarch32-psma-init.c  |  82 -
 cpukit/score/cpu/arm/arm-exception-default.c  |   6 +-
 .../score/cpu/arm/arm-exception-frame-print.c | 159 --
 cpukit/score/cpu/arm/armv4-sync-synchronize.c |   2 +-
 cpukit/score/cpu/arm/armv7-thread-idle.c  |   4 +-
 .../score/cpu/arm/armv7m-context-initialize.c |  14 +-
 cpukit/score/cpu/arm/armv7m-context-restore.c |   4 +-
 .../score/cpu/arm/armv7m-exception-default.c  |  26 +--
 .../cpu/arm/armv7m-exception-handler-get.c|   4 +-
 .../cpu/arm/armv7m-exception-handler-set.c|  19 +--
 .../cpu/arm/armv7m-exception-priority-get.c   |   8 +-
 .../arm/armv7m-exception-priority-handler.c   |   8 +-
 .../cpu/arm/armv7m-exception-priority-set.c   |   8 +-
 cpukit/score/cpu/arm/armv7m-initialize.c  |   2 +-
 cpukit/score/cpu/arm/armv7m-isr-dispatch.c|  20 +--
 cpukit/score/cpu/arm/armv7m-isr-enter-leave.c |   4 +-
 cpukit/score/cpu/arm/armv7m-isr-level-get.c   |   2 +-
 cpukit/score/cpu/arm/armv7m-isr-level-set.c   |   4 +-
 .../score/cpu/arm/armv7m-isr-vector-install.c |   8 +-
 .../cpu/arm/armv7m-multitasking-start-stop.c  |   4 +-
 cpukit/score/cpu/arm/cpu.c|  51 +++---
 24 files changed, 209 insertions(+), 238 deletions(-)

diff --git a/cpukit/score/cpu/arm/__aeabi_read_tp.c 
b/cpukit/score/cpu/arm/__aeabi_read_tp.c
index 0f4eba8d9a..e3bc529f18 100644
--- a/cpukit/score/cpu/arm/__aeabi_read_tp.c
+++ b/cpukit/score/cpu/arm/__aeabi_read_tp.c
@@ -37,8 +37,8 @@
 #include "config.h"
 #endif
 
-#include 
 #include 
+#include 
 
 #ifndef RTEMS_SMP
 
diff --git a/cpukit/score/cpu/arm/__tls_get_addr.c 
b/cpukit/score/cpu/arm/__tls_get_addr.c
index 7ef42fdcb4..fe38368812 100644
--- a/cpukit/score/cpu/arm/__tls_get_addr.c
+++ b/cpukit/score/cpu/arm/__tls_get_addr.c
@@ -47,8 +47,8 @@ void *__tls_get_addr(const TLS_Index *ti);
 void *__tls_get_addr(const TLS_Index *ti)
 {
   const Thread_Control *executing = _Thread_Get_executing();
-  void *tls_data = (char *) executing->Registers.thread_id
-+ _TLS_Get_thread_control_block_area_size();
+  void *tls_data  = (char *) executing->Registers.thread_id;
+  tls_data += _TLS_Get_thread_control_block_area_size();
 
   assert(ti->module == 1);
 
diff --git a/cpukit/score/cpu/arm/aarch32-psma-init-default.c 
b/cpukit/score/cpu/arm/aarch32-psma-init-default.c
index 615e7a528a..8ef8b5233a 100644
--- a/cpukit/score/cpu/arm/aarch32-psma-init-default.c
+++ b/cpukit/score/cpu/arm/aarch32-psma-init-default.c
@@ -42,7 +42,7 @@
 
 #if __ARM_ARCH >= 8 && __ARM_ARCH_PROFILE == 'R'
 
-void _AArch32_PMSA_Initialize_default( void )
+void _AArch32_PMSA_Initialize_default(void)
 {
   _AArch32_PMSA_Initialize(
 AARCH32_PMSA_MEM_ATTR(
diff --git a/cpukit/score/cpu/arm/aarch32-psma-init.c 
b/cpukit/score/cpu/arm/aarch32-psma-init.c
index 93a3673a98..b30cb5e308 100644
--- a/cpukit/score/cpu/arm/aarch32-psma-init.c
+++ b/cpukit/score/cpu/arm/aarch32-psma-init.c
@@ -46,7 +46,7 @@
 #include 
 
 #define AARCH32_PMSA_REGION_MAX \
-  ( ( AARCH32_MPUIR_REGION_MASK >> AARCH32_MPUIR_REGION_SHIFT ) + 1 )
+  ((AARCH32_MPUIR_REGION_MASK >> AARCH32_MPUIR_REGION_SHIFT) + 1)
 
 static void _AArch32_PMSA_Configure(
   const AArch32_PMSA_Region *regions,
@@ -57,36 +57,36 @@ static void _AArch32_PMSA_Configure(
   size_t   ri;
   uint32_t sctlr;
 
-  for ( ri = 0 ; ri < region_used; ++ri ) {
+  for ( ri = 0; ri < region_used; ++ri ) {
 uint32_t prbar;
 uint32_t prlar;
 uint32_t attr;
 
-prbar = regions[ ri ].base;
-prlar = regions[ ri ].limit;
-attr = regions[ ri ].attributes;
+prbar = regions[ri].base;
+prlar = regions[ri].limit;
+attr  = regions[ri].attributes;
 
-prbar |= ( attr >> 6 ) & 0x3fU;
+prbar |= (attr >> 6) & 0x3fU;
 prlar |= attr & 0x3fU;
 
-_AArch32_Write_prselr( ri );
+_AArch32_Write_prselr(ri);
 _ARM_Instruction_synchronization_barrier();
-_AArch32_Write_prbar( prbar );
-_AArch32_Write_prlar( prlar );
+_AArch32_Write_prbar(prbar);
+_AArch32_Write_prlar(prlar);
   }
 
-  for ( ri = region_used ; ri < region_max; ++ri ) {
-_AArch32_Write_prselr( ri );
+  for ( ri = region_used; ri < region_max; ++ri ) {
+_AArch32_Write_prselr(ri);
 _ARM_Instruction_synchronization_barrier();
-_AArch32_Write_prbar( 0 );
-_AArch32_Write_prlar( 0 );
+_AArch32_Write_prbar(0);
+_AArch32_Write_prlar(0);
   }
 
   _ARM_Data_synchronization_barrier();
-  sctlr = _AArch32_Read_sctlr();
+  sctlr  = _AArch32_Read_sctlr();
   sctlr |= AARCH32_SCTLR_M | AARCH32_SCTLR_I | AARCH32_SCTLR_C;
-  sctlr &= ~( AARCH32_SCTLR_A | AARCH32_SCTLR_BR );
-  _AArch32_Write_sctlr( sctlr );
+  sctlr &= ~(AARCH32_SCTLR_A | AARCH32_SCTLR_BR);
+  _AArch32_Write_sctlr(sctlr);
   _ARM_Instruction_synchronization_barrier();
 }
 
@@ -109,16 

[PATCH] score/aarch64: style fixes

[Gedare Bloom]

---
 .../cpu/aarch64/aarch64-exception-default.c   |  22 +--
 .../aarch64/aarch64-exception-frame-print.c   | 155 ++
 .../score/cpu/aarch64/aarch64-thread-idle.c   |   2 +-
 cpukit/score/cpu/aarch64/cpu.c|  61 ---
 4 files changed, 132 insertions(+), 108 deletions(-)

diff --git a/cpukit/score/cpu/aarch64/aarch64-exception-default.c 
b/cpukit/score/cpu/aarch64/aarch64-exception-default.c
index f1591cbd5d..df15193996 100644
--- a/cpukit/score/cpu/aarch64/aarch64-exception-default.c
+++ b/cpukit/score/cpu/aarch64/aarch64-exception-default.c
@@ -46,9 +46,9 @@
 #include 
 #include 
 
-void _AArch64_Exception_default( CPU_Exception_frame *frame )
+void _AArch64_Exception_default(CPU_Exception_frame *frame)
 {
-  uint64_t EC = AARCH64_ESR_EL1_EC_GET( frame->register_syndrome );
+  uint64_t EC = AARCH64_ESR_EL1_EC_GET(frame->register_syndrome);
 
   /* Emulate FPSR flags for FENV if a FPU exception occurred */
   if ( EC == 0x2c ) {
@@ -59,19 +59,19 @@ void _AArch64_Exception_default( CPU_Exception_frame *frame 
)
  * functions executed in that context will need this information to be
  * accurate.
  */
-uint64_t ISS = AARCH64_ESR_EL1_EC_GET( frame->register_syndrome );
+uint64_t ISS = AARCH64_ESR_EL1_EC_GET(frame->register_syndrome);
 
 /* If the exception bits are valid, use them */
-if ( ( ISS & ( 1 << 23 ) ) != 0 ) {
+if ( (ISS & (1 << 23)) != 0 ) {
   /* The bits of the lower byte match the FPSR exception bits */
-  frame->register_fpsr |= ( ISS & 0xff );
+  frame->register_fpsr |= (ISS & 0xff);
 }
   }
 
-  rtems_fatal( RTEMS_FATAL_SOURCE_EXCEPTION, (rtems_fatal_code) frame );
+  rtems_fatal(RTEMS_FATAL_SOURCE_EXCEPTION, (rtems_fatal_code) frame);
 }
 
-void _CPU_Exception_disable_thread_dispatch( void )
+void _CPU_Exception_disable_thread_dispatch(void)
 {
   Per_CPU_Control *cpu_self = _Per_CPU_Get();
 
@@ -88,9 +88,9 @@ void _AArch64_Exception_frame_copy(
   *new_ef = *old_ef;
 }
 
-int _CPU_Exception_frame_get_signal( CPU_Exception_frame *ef )
+int _CPU_Exception_frame_get_signal(CPU_Exception_frame *ef)
 {
-  uint64_t EC = AARCH64_ESR_EL1_EC_GET( ef->register_syndrome );
+  uint64_t EC = AARCH64_ESR_EL1_EC_GET(ef->register_syndrome);
 
   switch ( EC ) {
 case 0x1:  /* WFI */
@@ -115,13 +115,13 @@ int _CPU_Exception_frame_get_signal( CPU_Exception_frame 
*ef )
   }
 }
 
-void _CPU_Exception_frame_set_resume( CPU_Exception_frame *ef, void *address )
+void _CPU_Exception_frame_set_resume(CPU_Exception_frame *ef, void *address)
 {
   ef->register_pc = address;
 }
 
 #define AARCH64_INSTRUCTION_SIZE 4
-void  _CPU_Exception_frame_make_resume_next_instruction( CPU_Exception_frame 
*ef )
+void _CPU_Exception_frame_make_resume_next_instruction(CPU_Exception_frame *ef)
 {
   ef->register_pc += AARCH64_INSTRUCTION_SIZE;
 }
diff --git a/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c 
b/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
index c5b477c72f..e0fbab68dc 100644
--- a/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
+++ b/cpukit/score/cpu/aarch64/aarch64-exception-frame-print.c
@@ -44,37 +44,37 @@
 
 #include 
 
+#include 
 #include 
 #include 
-#include 
 
 typedef struct {
-   char *s;
-   size_t n;
+  char  *s;
+  size_t n;
 } String_Context;
 
-static void _CPU_Put_char( int c, void *arg )
+static void _CPU_Put_char(int c, void *arg)
 {
   String_Context *sctx = arg;
-  size_t n = sctx->n;
+  size_t  n= sctx->n;
 
-  if (n > 0) {
+  if ( n > 0 ) {
 char *s = sctx->s;
-*s = (char) c;
+*s  = (char) c;
 sctx->s = s + 1;
 sctx->n = n - 1;
   }
 }
 
 static void _CPU_Binary_sprintf(
-  char *s,
-  size_t maxlen,
+  char*s,
+  size_t   maxlen,
   uint32_t num_bits,
   uint32_t value
 )
 {
   String_Context sctx;
-  uint32_t mask;
+  uint32_t   mask;
 
   sctx.s = s;
   sctx.n = maxlen;
@@ -82,14 +82,14 @@ static void _CPU_Binary_sprintf(
   mask = 1 << (num_bits - 1);
 
   while ( mask != 0 ) {
-_IO_Printf( _CPU_Put_char, , "%d", (value & mask ? 1 : 0) );
+_IO_Printf(_CPU_Put_char, , "%d", (value & mask ? 1 : 0));
 mask >>= 1;
   }
 
   s[num_bits] = '\0';
 }
 
-static const char* _CPU_Exception_class_to_string( uint16_t exception_class )
+static const char *_CPU_Exception_class_to_string(uint16_t exception_class)
 {
   /* The 80 character limit is intentionally ignored for these strings. */
   switch ( exception_class ) {
@@ -142,82 +142,107 @@ static const char* _CPU_Exception_class_to_string( 
uint16_t exception_class )
   }
 }
 
-void _CPU_Exception_frame_print( const CPU_Exception_frame *frame )
+void _CPU_Exception_frame_print(const CPU_Exception_frame *frame)
 {
-  uint32_t ec;
-  uint32_t il;
-  uint32_t iss;
-  char ec_str[7];
-  char iss_str[26];
-  int  i;
+  uint32_t ec;
+  uint32_t il;
+  uint32_t iss;
+  char ec_str[7];
+  char iss_str[26];
+  int  

[PATCH rtems-docs 2/2] common/waf.py: Add option to check maximum Sphinx version

[Joel Sherrill]

Updates #4928.
---
 common/waf.py | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/common/waf.py b/common/waf.py
index 0bd166a..6efe038 100644
--- a/common/waf.py
+++ b/common/waf.py
@@ -16,7 +16,11 @@ from waflib.Build import BuildContext
 import latex
 import conf
 
+# Sphinx >= 6 are currently broken. 
+# If you do not want to check for a maximum version, set it to None.
 sphinx_min_version = (1, 3)
+sphinx_max_version = (5, 9)
+#sphinx_max_version = None
 
 def version_cmdline(ctx):
 return '-Drelease="%s" -Dversion="%s" -Drtems_major="%s" ' \
@@ -84,7 +88,7 @@ class linkcheck(BuildContext):
 cmd = 'linkcheck'
 fun = 'cmd_linkcheck'
 
-def check_sphinx_version(ctx, minver):
+def check_sphinx_version(ctx, minver, maxver):
 try:
 import sphinx
 except:
@@ -115,6 +119,9 @@ def check_sphinx_version(ctx, minver):
 ctx.fatal("Sphinx version cannot be checked or Sphinx is not 
installed")
 if ver < minver:
 ctx.fatal("Sphinx version is too old: %s" % ".".join(map(str, ver)))
+if maxver is not None:
+if ver > maxver:
+ctx.fatal("Sphinx version is too new: %s" % ".".join(map(str, 
ver)))
 return ver
 
 def sphinx_options(ctx):
@@ -206,8 +213,12 @@ def cmd_configure(ctx):
 ctx.find_program("sphinx-build", var="BIN_SPHINX_BUILD", mandatory = 
True)
 ctx.find_program("aspell", var = "BIN_ASPELL", mandatory = False)
 
-ctx.start_msg("Checking if Sphinx is at least %s.%s" % 
sphinx_min_version)
-ver = check_sphinx_version(ctx, sphinx_min_version)
+if sphinx_max_version is None:
+  ctx.start_msg("Checking if Sphinx is at least %s.%s" % 
sphinx_min_version)
+else:
+  ctx.start_msg("Checking if Sphinx is between %s.%s and %s.%s" % 
(sphinx_min_version + sphinx_max_version))
+
+ver = check_sphinx_version(ctx, sphinx_min_version, sphinx_max_version)
 ctx.end_msg("yes (%s)" % ".".join(map(str, ver)))
 
 ctx.start_msg("Checking Sphinx Options ")
-- 
2.31.1

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

[PATCH rtems-docs 1/2] layout.html: Revert patch forcing Spinx to >= 6.0

[Joel Sherrill]

Unfortunately, updating past Sphinx 5.x results in unordered bullet
lists not formatting correctly as show in a screen capture attached
to #4928. Revert this patch until the issue is resolved and output
is reviewed for other potential issues.

From: Utkarsh Verma 
Date: Wed, 14 Jun 2023 05:36:26 +
Subject: [PATCH] eng: Fix builds for newer Sphinx versions (>=7)

The current Sphinx theme depends on the `style` parameter which got
deprecated in v5.1 and finally got removed in v7. Now, the `styles` key
should be preferred which is a list of stylesheets. This commit
implements this change.

Updates #4915.
Updates #4928.
---
 common/sphinx_rtd_theme_rtems/layout.html | 2 --
 1 file changed, 2 deletions(-)

diff --git a/common/sphinx_rtd_theme_rtems/layout.html 
b/common/sphinx_rtd_theme_rtems/layout.html
index 91d67b5..0fe6c65 100644
--- a/common/sphinx_rtd_theme_rtems/layout.html
+++ b/common/sphinx_rtd_theme_rtems/layout.html
@@ -67,9 +67,7 @@
   {%- endblock %}
 
   {# CSS #}
-  {% for style in styles %}
   
-  {% endfor %}
   
   {%- for css in css_files %}
 {%- if css|attr("rel") %}
-- 
2.31.1

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

[PATCH rtems-docs 0/2] Sphinx Version Check

[Joel Sherrill]

Hi

There has been Discord and email discussion that upgrading to Sphinx >=
6.0 breaks unordered bullet lists. But using Sphinx < 6.0 does not
produce correct results with the patch which enabled us to use newer
versions of Sphinx. There are two patches in this series.

(1) Reverts the patch which broke document generation. Hopefully this
can be reapplied once someone with time and more Sphinx knowledge than I
have figures out what is actually broken.

(2) Enhances the Sphinx version check to be able to check for a version
greater than a minimum (current behavior) or if the Sphinx version is
within an acceptable range. The acceptable min/max versions are set at
the top of the file.

I think these are simple patches to unwedge documentation generation
until a solution allowing us to upgrade is figured out. Then the minimum
can be changed to 6.0 and maximum to None.

OK to commit?

--joel

Joel Sherrill (2):
  layout.html: Revert patch forcing Spinx to >= 6.0
  common/waf.py: Add option to check maximum Sphinx version

 common/sphinx_rtd_theme_rtems/layout.html |  2 --
 common/waf.py | 17 ++---
 2 files changed, 14 insertions(+), 5 deletions(-)

-- 
2.31.1

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

Re: [PATCH 8/8] sys: Add files to Doxygen group

[Gedare Bloom]

On Tue, Jul 25, 2023 at 1:17 PM Gedare Bloom  wrote:
>
> On Tue, Jul 25, 2023 at 11:31 AM Sebastian Huber
>  wrote:
> >
> > On 25.07.23 17:55, Gedare Bloom wrote:
> > > priority.h and endian.h are imported code. We should modify with care.
> > > I'm not opposed, we just have to think twice.
> >
> > endian.h is now actually in Newlib. We should remove it at some point in
> > time.
> >
> > I synchronized a couple of files in the past and I don't think these
> > comment blocks at the begin of the file will cause issues in the future.
> >
> Agreed. Just one other thing, I think we prefer the SPDX to be the
> first line of the file where we control it.
>
nevermind, those got cut off by the patch context. ignore my noise.
This looks fine to me.

> > --
> > 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 8/8] sys: Add files to Doxygen group

[Gedare Bloom]

On Tue, Jul 25, 2023 at 11:31 AM Sebastian Huber
 wrote:
>
> On 25.07.23 17:55, Gedare Bloom wrote:
> > priority.h and endian.h are imported code. We should modify with care.
> > I'm not opposed, we just have to think twice.
>
> endian.h is now actually in Newlib. We should remove it at some point in
> time.
>
> I synchronized a couple of files in the past and I don't think these
> comment blocks at the begin of the file will cause issues in the future.
>
Agreed. Just one other thing, I think we prefer the SPDX to be the
first line of the file where we control it.

> --
> 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] build: Add optional RTEMS_VERSION_VC_KEY

[Joel Sherrill]

On Tue, Jul 25, 2023 at 12:15 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 25.07.23 19:09, Joel Sherrill wrote:
> >
> > On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber
> >  > > wrote:
> >
> > Allow the user to set the version control key.
> > ---
> >   spec/build/cpukit/grp.yml |  2 ++
> >   spec/build/cpukit/optversionvckey.yml | 20 ++
> >   wscript   | 38
> ---
> >   3 files changed, 44 insertions(+), 16 deletions(-)
> >   create mode 100644 spec/build/cpukit/optversionvckey.yml
> >
> > diff --git a/spec/build/cpukit/grp.yml b/spec/build/cpukit/grp.yml
> > index e07e975d7d..fbeab45b5c 100644
> > --- a/spec/build/cpukit/grp.yml
> > +++ b/spec/build/cpukit/grp.yml
> > @@ -18,6 +18,8 @@ links:
> > uid: cpuopts
> >   - role: build-dependency
> > uid: cfghdr
> > +- role: build-dependency
> > +  uid: optversionvckey
> >   - role: build-dependency
> > uid: libdebugger
> >   - role: build-dependency
> > diff --git a/spec/build/cpukit/optversionvckey.yml
> > b/spec/build/cpukit/optversionvckey.yml
> > new file mode 100644
> > index 00..7197381342
> > --- /dev/null
> > +++ b/spec/build/cpukit/optversionvckey.yml
> > @@ -0,0 +1,20 @@
> > +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> > +actions:
> > +- get-string: null
> > +- env-assign: null
> > +build-type: option
> > +copyrights:
> > +- Copyright (C) 2022, 2023 embedded brains GmbH & Co. KG
> > +default:
> > +- enabled-by: true
> > +  value: ''
> > +description: |
> > +  If defined to a non-empty value, then the value will be used for
> > the version
> > +  control key returned by rtems_version() and
> > rtems_version_control_key(),
> > +  otherwise the value will be determined by the Git repository
> > containing the
> > +  waf top directory.
> >
> >
> > And would this change for a release tarball?
>
> Which RTEMS_VERSION_VC_KEY has a release tarball? What happens if you
> unpack an release archive in an external Git repository?
>

I don't know but think we should discuss it.

Chris should speak up since the release scripts are his and this
might be used by the distribution packaging he has made available.

--joel

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

Re: [PATCH] build: Export BSP base and family via pkg-config

[Joel Sherrill]

On Tue, Jul 25, 2023 at 12:19 PM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

>
>
> On 25.07.23 19:15, Gedare Bloom wrote:
> > On Tue, Jul 25, 2023 at 11:11 AM Sebastian Huber
> >   wrote:
> >>
> >>
> >> On 25.07.23 18:01, Gedare Bloom wrote:
> >>> On Tue, Jul 25, 2023 at 5:13 AM Sebastian Huber
> >>>wrote:
>  This allows application and library build systems to derive option
>  values from the BSP base and family names.
>  ---
> spec/build/bsps/pkgconfig.yml | 2 ++
> 1 file changed, 2 insertions(+)
> 
>  diff --git a/spec/build/bsps/pkgconfig.yml
> b/spec/build/bsps/pkgconfig.yml
>  index e08c83fe27..afaffbbf0f 100644
>  --- a/spec/build/bsps/pkgconfig.yml
>  +++ b/spec/build/bsps/pkgconfig.yml
>  @@ -15,6 +15,8 @@ content: |
>   ABI_FLAGS=${ABI_FLAGS}
>   RTEMS_ARCH=${ARCH}
>   RTEMS_BSP=${BSP_NAME}
>  +  RTEMS_BSP_BASE=${BSP_BASE}
>  +  RTEMS_BSP_FAMILY=${BSP_FAMILY}
> >>> These expose a little bit of the internal working of the build system.
> >>> I think it's fine, since these two fields should not change over time.
> >>> But, it commits us to maintain this mapping and these variables.
> >> We had the RTEMS_BSP also in the old build system, but it was actually
> >> what is now the RTEMS_BSP_BASE in this patch. With the user-defined BSP
> >> names we have for:
> >>
> >> [arch/user_bsp_name]
> >> INHERIT = system_bsp_name
> >>
> >> This results in:
> >>
> >> RTEMS_BSP = user_bsp_name
> >> RTEMS_BSP_BASE = system_bsp_name
> >>
> >> Maybe we should change this to:
> >>
> >> RTEMS_BSP = system_bsp_name
> >> RTEMS_BSP_NAME = user_bsp_name
> >>
> > This would make more sense. I don't know what it might break to make
> > this change now though, as external build tools may rely on the
> > current definition of RTEMS_BSP?
>
> Yes, this is a bit tricky since the BSP name is also encoded in the *.pc
> file name: ${arch}-rtems6-{user_bsp_name}.pc. This is an argument for
> keeping RTEMS_BSP = user_bsp_name.
>

I would agree with that since that's the name the user expects and will be
part of any installed path, pkg config file, etc.

That leaves RTEMS_BSP_NAME is not great. How about RTEMS_BSP_CANONICAL?

RTEMS_BSP_FAMILY has been around a long time and should be well understood.
I certainly have explained the concept in the class for a LONG LONG time
even is
there are examples like erc32 and leon3 which overlap CPU, family, and BSP
names.
But powerpc -> motorola_shared -> mvme2100 -> user name or
arm -> xilinx-zynq -> xilinx_zynq_zedboard -> user name w/cfg do make sense.

We are encouraging users to "derive" custom BSPs based on specific
configurations
of existing ones. Makes sense to add a naming layer.

--joel

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

Re: [PATCH 8/8] sys: Add files to Doxygen group

[Sebastian Huber]

On 25.07.23 17:55, Gedare Bloom wrote:

priority.h and endian.h are imported code. We should modify with care.
I'm not opposed, we just have to think twice.


endian.h is now actually in Newlib. We should remove it at some point in 
time.


I synchronized a couple of files in the past and I don't think these 
comment blocks at the begin of the file will cause issues in the future.


--
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] build: Export BSP base and family via pkg-config

[Sebastian Huber]

On 25.07.23 19:15, Gedare Bloom wrote:

On Tue, Jul 25, 2023 at 11:11 AM Sebastian Huber
  wrote:



On 25.07.23 18:01, Gedare Bloom wrote:

On Tue, Jul 25, 2023 at 5:13 AM Sebastian Huber
   wrote:

This allows application and library build systems to derive option
values from the BSP base and family names.
---
   spec/build/bsps/pkgconfig.yml | 2 ++
   1 file changed, 2 insertions(+)

diff --git a/spec/build/bsps/pkgconfig.yml b/spec/build/bsps/pkgconfig.yml
index e08c83fe27..afaffbbf0f 100644
--- a/spec/build/bsps/pkgconfig.yml
+++ b/spec/build/bsps/pkgconfig.yml
@@ -15,6 +15,8 @@ content: |
 ABI_FLAGS=${ABI_FLAGS}
 RTEMS_ARCH=${ARCH}
 RTEMS_BSP=${BSP_NAME}
+  RTEMS_BSP_BASE=${BSP_BASE}
+  RTEMS_BSP_FAMILY=${BSP_FAMILY}

These expose a little bit of the internal working of the build system.
I think it's fine, since these two fields should not change over time.
But, it commits us to maintain this mapping and these variables.

We had the RTEMS_BSP also in the old build system, but it was actually
what is now the RTEMS_BSP_BASE in this patch. With the user-defined BSP
names we have for:

[arch/user_bsp_name]
INHERIT = system_bsp_name

This results in:

RTEMS_BSP = user_bsp_name
RTEMS_BSP_BASE = system_bsp_name

Maybe we should change this to:

RTEMS_BSP = system_bsp_name
RTEMS_BSP_NAME = user_bsp_name


This would make more sense. I don't know what it might break to make
this change now though, as external build tools may rely on the
current definition of RTEMS_BSP?


Yes, this is a bit tricky since the BSP name is also encoded in the *.pc 
file name: ${arch}-rtems6-{user_bsp_name}.pc. This is an argument for 
keeping RTEMS_BSP = user_bsp_name.


--
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] build: Export BSP base and family via pkg-config

[Gedare Bloom]

On Tue, Jul 25, 2023 at 11:11 AM Sebastian Huber
 wrote:
>
>
>
> On 25.07.23 18:01, Gedare Bloom wrote:
> > On Tue, Jul 25, 2023 at 5:13 AM Sebastian Huber
> >   wrote:
> >> This allows application and library build systems to derive option
> >> values from the BSP base and family names.
> >> ---
> >>   spec/build/bsps/pkgconfig.yml | 2 ++
> >>   1 file changed, 2 insertions(+)
> >>
> >> diff --git a/spec/build/bsps/pkgconfig.yml b/spec/build/bsps/pkgconfig.yml
> >> index e08c83fe27..afaffbbf0f 100644
> >> --- a/spec/build/bsps/pkgconfig.yml
> >> +++ b/spec/build/bsps/pkgconfig.yml
> >> @@ -15,6 +15,8 @@ content: |
> >> ABI_FLAGS=${ABI_FLAGS}
> >> RTEMS_ARCH=${ARCH}
> >> RTEMS_BSP=${BSP_NAME}
> >> +  RTEMS_BSP_BASE=${BSP_BASE}
> >> +  RTEMS_BSP_FAMILY=${BSP_FAMILY}
> > These expose a little bit of the internal working of the build system.
> > I think it's fine, since these two fields should not change over time.
> > But, it commits us to maintain this mapping and these variables.
>
> We had the RTEMS_BSP also in the old build system, but it was actually
> what is now the RTEMS_BSP_BASE in this patch. With the user-defined BSP
> names we have for:
>
> [arch/user_bsp_name]
> INHERIT = system_bsp_name
>
> This results in:
>
> RTEMS_BSP = user_bsp_name
> RTEMS_BSP_BASE = system_bsp_name
>
> Maybe we should change this to:
>
> RTEMS_BSP = system_bsp_name
> RTEMS_BSP_NAME = user_bsp_name
>
This would make more sense. I don't know what it might break to make
this change now though, as external build tools may rely on the
current definition of RTEMS_BSP?

> The RTEMS_BSP_FAMILY is quite handy if you want to for example enable a
> network interface driver for a couple of BSPs. You don't have to
> enumerate all variants that exist now and in the future.
>
Yes, I see that. I'm fine with the addition, it makes sense.

> --
> 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] build: Add optional RTEMS_VERSION_VC_KEY

[Sebastian Huber]

On 25.07.23 19:09, Joel Sherrill wrote:


On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber 
> wrote:


Allow the user to set the version control key.
---
  spec/build/cpukit/grp.yml             |  2 ++
  spec/build/cpukit/optversionvckey.yml | 20 ++
  wscript                               | 38 ---
  3 files changed, 44 insertions(+), 16 deletions(-)
  create mode 100644 spec/build/cpukit/optversionvckey.yml

diff --git a/spec/build/cpukit/grp.yml b/spec/build/cpukit/grp.yml
index e07e975d7d..fbeab45b5c 100644
--- a/spec/build/cpukit/grp.yml
+++ b/spec/build/cpukit/grp.yml
@@ -18,6 +18,8 @@ links:
    uid: cpuopts
  - role: build-dependency
    uid: cfghdr
+- role: build-dependency
+  uid: optversionvckey
  - role: build-dependency
    uid: libdebugger
  - role: build-dependency
diff --git a/spec/build/cpukit/optversionvckey.yml
b/spec/build/cpukit/optversionvckey.yml
new file mode 100644
index 00..7197381342
--- /dev/null
+++ b/spec/build/cpukit/optversionvckey.yml
@@ -0,0 +1,20 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- env-assign: null
+build-type: option
+copyrights:
+- Copyright (C) 2022, 2023 embedded brains GmbH & Co. KG
+default:
+- enabled-by: true
+  value: ''
+description: |
+  If defined to a non-empty value, then the value will be used for
the version
+  control key returned by rtems_version() and
rtems_version_control_key(),
+  otherwise the value will be determined by the Git repository
containing the
+  waf top directory.


And would this change for a release tarball?


Which RTEMS_VERSION_VC_KEY has a release tarball? What happens if you 
unpack an release archive in an external Git repository?


--
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] bsps/arm: fix nested extern decl. warnings brought by CMSIS files update

[Karel Gardas]

On 7/25/23 17:23, Sebastian Huber wrote:

On 25.07.23 16:20, Karel Gardas wrote:

On 7/25/23 15:32, Sebastian Huber wrote:



On 21.07.23 17:37, Karel Gardas wrote:

---
  bsps/arm/include/cmsis_gcc.h | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/bsps/arm/include/cmsis_gcc.h 
b/bsps/arm/include/cmsis_gcc.h

index 4f0762d6dc..9e867348d2 100644
--- a/bsps/arm/include/cmsis_gcc.h
+++ b/bsps/arm/include/cmsis_gcc.h
@@ -30,7 +30,9 @@
  #pragma GCC diagnostic ignored "-Wsign-conversion"
  #pragma GCC diagnostic ignored "-Wconversion"
  #pragma GCC diagnostic ignored "-Wunused-parameter"
-
+#ifdef __rtems__
+#pragma GCC diagnostic ignored "-Wnested-externs"
+#endif /* __rtems__ */
  /* Fallback for __has_builtin */
  #ifndef __has_builtin
    #define __has_builtin(x) (0)


I would disable this warning only in __cmsis_start() with a push/pop 
pragma.


Done!

Ideally, the guidelines would be in the RTEMS Software Engineering 
manual before we added the Apache 2.0 files. We should avoid that every 
contributor has to figure out what to do. I you think that this 
__rtems__ stuff is enough, then just document it. Zephyr for example has 
a clear process to add new licenses:


https://docs.zephyrproject.org/latest/contribute/external.html


Indeed, but we're not living in ideal world unfortunately. Zephyr is 
completely different league in terms of man-power available to the 
project. We need to live with what we have.


Anyway, I've submitted new version of the patch and hopefully also be 
more compliant with the terms of the Apache 2.0 license.


Thanks!
Karel

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

Re: [PATCH] build: Export BSP base and family via pkg-config

[Sebastian Huber]

On 25.07.23 18:01, Gedare Bloom wrote:

On Tue, Jul 25, 2023 at 5:13 AM Sebastian Huber
  wrote:

This allows application and library build systems to derive option
values from the BSP base and family names.
---
  spec/build/bsps/pkgconfig.yml | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/spec/build/bsps/pkgconfig.yml b/spec/build/bsps/pkgconfig.yml
index e08c83fe27..afaffbbf0f 100644
--- a/spec/build/bsps/pkgconfig.yml
+++ b/spec/build/bsps/pkgconfig.yml
@@ -15,6 +15,8 @@ content: |
ABI_FLAGS=${ABI_FLAGS}
RTEMS_ARCH=${ARCH}
RTEMS_BSP=${BSP_NAME}
+  RTEMS_BSP_BASE=${BSP_BASE}
+  RTEMS_BSP_FAMILY=${BSP_FAMILY}

These expose a little bit of the internal working of the build system.
I think it's fine, since these two fields should not change over time.
But, it commits us to maintain this mapping and these variables.


We had the RTEMS_BSP also in the old build system, but it was actually 
what is now the RTEMS_BSP_BASE in this patch. With the user-defined BSP 
names we have for:


[arch/user_bsp_name]
INHERIT = system_bsp_name

This results in:

RTEMS_BSP = user_bsp_name
RTEMS_BSP_BASE = system_bsp_name

Maybe we should change this to:

RTEMS_BSP = system_bsp_name
RTEMS_BSP_NAME = user_bsp_name

The RTEMS_BSP_FAMILY is quite handy if you want to for example enable a 
network interface driver for a couple of BSPs. You don't have to 
enumerate all variants that exist now and in the future.


--
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] bsps/arm: fix nested extern decl. warnings brought by CMSIS files update

[Karel Gardas]

---
 bsps/arm/include/cmsis_gcc.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/bsps/arm/include/cmsis_gcc.h b/bsps/arm/include/cmsis_gcc.h
index 4f0762d6dc..f8267ded0d 100644
--- a/bsps/arm/include/cmsis_gcc.h
+++ b/bsps/arm/include/cmsis_gcc.h
@@ -1,3 +1,6 @@
+/*
+ * The file was modified by RTEMS contributors.
+ */
 /**//**
  * @file cmsis_gcc.h
  * @briefCMSIS compiler GCC header file
@@ -136,6 +139,10 @@
  */
 __STATIC_FORCEINLINE __NO_RETURN void __cmsis_start(void)
 {
+#ifdef __rtems__
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wnested-externs"
+#endif /* __rtems__ */
   extern void _start(void) __NO_RETURN;
 
   typedef struct __copy_table {
@@ -154,6 +161,10 @@ __STATIC_FORCEINLINE __NO_RETURN void __cmsis_start(void)
   extern const __zero_table_t __zero_table_start__;
   extern const __zero_table_t __zero_table_end__;
 
+#ifdef __rtems__
+#pragma GCC diagnostic pop
+#endif /* __rtems__ */
+
   for (__copy_table_t const* pTable = &__copy_table_start__; pTable < 
&__copy_table_end__; ++pTable) {
 for(uint32_t i=0u; iwlen; ++i) {
   pTable->dest[i] = pTable->src[i];
-- 
2.25.1

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

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

[Joel Sherrill]

On Tue, Jul 25, 2023 at 10:12 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Allow the user to set the version control key.
> ---
>  spec/build/cpukit/grp.yml |  2 ++
>  spec/build/cpukit/optversionvckey.yml | 20 ++
>  wscript   | 38 ---
>  3 files changed, 44 insertions(+), 16 deletions(-)
>  create mode 100644 spec/build/cpukit/optversionvckey.yml
>
> diff --git a/spec/build/cpukit/grp.yml b/spec/build/cpukit/grp.yml
> index e07e975d7d..fbeab45b5c 100644
> --- a/spec/build/cpukit/grp.yml
> +++ b/spec/build/cpukit/grp.yml
> @@ -18,6 +18,8 @@ links:
>uid: cpuopts
>  - role: build-dependency
>uid: cfghdr
> +- role: build-dependency
> +  uid: optversionvckey
>  - role: build-dependency
>uid: libdebugger
>  - role: build-dependency
> diff --git a/spec/build/cpukit/optversionvckey.yml
> b/spec/build/cpukit/optversionvckey.yml
> new file mode 100644
> index 00..7197381342
> --- /dev/null
> +++ b/spec/build/cpukit/optversionvckey.yml
> @@ -0,0 +1,20 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +actions:
> +- get-string: null
> +- env-assign: null
> +build-type: option
> +copyrights:
> +- Copyright (C) 2022, 2023 embedded brains GmbH & Co. KG
> +default:
> +- enabled-by: true
> +  value: ''
> +description: |
> +  If defined to a non-empty value, then the value will be used for the
> version
> +  control key returned by rtems_version() and rtems_version_control_key(),
> +  otherwise the value will be determined by the Git repository containing
> the
> +  waf top directory.
>

And would this change for a release tarball?

I'm reading this as a project specific version string in addition to major
and minor.

And that if used, it would be the responsibility of the user to track that
back to revision control hash.

If so, this likely needs a bit more written.

Right?

--joel


> +enabled-by: true
> +format: '{}'
> +links: []
> +name: RTEMS_VERSION_VC_KEY
> +type: build
> diff --git a/wscript b/wscript
> index 862000513d..2026d55070 100755
> --- a/wscript
> +++ b/wscript
> @@ -58,38 +58,44 @@ def no_unicode(value):
>
>
>  class VersionControlKeyHeader:
> -_content = None
> +_git_commit = None
>
>  @staticmethod
>  def write(bld, filename):
> -if VersionControlKeyHeader._content is None:
> -from waflib.Build import Context
> -from waflib.Errors import WafError
> -
> -content = """/*
> +content = """/*
>   * Automatically generated. Do not edit.
>   */
>  #if !defined(_RTEMS_VERSION_VC_KEY_H_)
>  #define _RTEMS_VERSION_VC_KEY_H_
>  """
> -try:
> -rev = bld.cmd_and_log("git rev-parse HEAD",
> -  quiet=Context.STDOUT).strip()
> -content += """#define RTEMS_VERSION_VC_KEY "{}"
> +rev = bld.env.RTEMS_VERSION_VC_KEY
> +if not rev:
> +rev = VersionControlKeyHeader._git_commit
> +if rev is None:
> +from waflib.Build import Context
> +from waflib.Errors import WafError
> +
> +try:
> +rev = bld.cmd_and_log("git rev-parse HEAD",
> +  quiet=Context.STDOUT).strip()
> +except WafError:
> +rev = ""
> +VersionControlKeyHeader._git_commit = rev
> +if rev:
> +content += """#define RTEMS_VERSION_VC_KEY "{}"
>  """.format(rev)
> -except WafError:
> -content += """/* No version control key found; release? */
> +else:
> +content += """/* No version control key found; release? */
>  """
> -content += """#endif
> +content += """#endif
>  """
> -VersionControlKeyHeader._content = content
>  f = bld.bldnode.make_node(filename)
>  f.parent.mkdir()
>  try:
>  if content != f.read():
> -f.write(VersionControlKeyHeader._content)
> +f.write(content)
>  except:
> -f.write(VersionControlKeyHeader._content)
> +f.write(content)
>
>
>  class EnvWrapper(object):
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] import Apache License 2.0 text file

[Gedare Bloom]

ok

On Tue, Jul 25, 2023 at 10:17 AM Karel Gardas  wrote:
>
> ---
>  LICENSE.Apache-2.0 | 202 +
>  1 file changed, 202 insertions(+)
>  create mode 100644 LICENSE.Apache-2.0
>
> diff --git a/LICENSE.Apache-2.0 b/LICENSE.Apache-2.0
> new file mode 100644
> index 00..d645695673
> --- /dev/null
> +++ b/LICENSE.Apache-2.0
> @@ -0,0 +1,202 @@
> +
> + Apache License
> +   Version 2.0, January 2004
> +http://www.apache.org/licenses/
> +
> +   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
> +
> +   1. Definitions.
> +
> +  "License" shall mean the terms and conditions for use, reproduction,
> +  and distribution as defined by Sections 1 through 9 of this document.
> +
> +  "Licensor" shall mean the copyright owner or entity authorized by
> +  the copyright owner that is granting the License.
> +
> +  "Legal Entity" shall mean the union of the acting entity and all
> +  other entities that control, are controlled by, or are under common
> +  control with that entity. For the purposes of this definition,
> +  "control" means (i) the power, direct or indirect, to cause the
> +  direction or management of such entity, whether by contract or
> +  otherwise, or (ii) ownership of fifty percent (50%) or more of the
> +  outstanding shares, or (iii) beneficial ownership of such entity.
> +
> +  "You" (or "Your") shall mean an individual or Legal Entity
> +  exercising permissions granted by this License.
> +
> +  "Source" form shall mean the preferred form for making modifications,
> +  including but not limited to software source code, documentation
> +  source, and configuration files.
> +
> +  "Object" form shall mean any form resulting from mechanical
> +  transformation or translation of a Source form, including but
> +  not limited to compiled object code, generated documentation,
> +  and conversions to other media types.
> +
> +  "Work" shall mean the work of authorship, whether in Source or
> +  Object form, made available under the License, as indicated by a
> +  copyright notice that is included in or attached to the work
> +  (an example is provided in the Appendix below).
> +
> +  "Derivative Works" shall mean any work, whether in Source or Object
> +  form, that is based on (or derived from) the Work and for which the
> +  editorial revisions, annotations, elaborations, or other modifications
> +  represent, as a whole, an original work of authorship. For the purposes
> +  of this License, Derivative Works shall not include works that remain
> +  separable from, or merely link (or bind by name) to the interfaces of,
> +  the Work and Derivative Works thereof.
> +
> +  "Contribution" shall mean any work of authorship, including
> +  the original version of the Work and any modifications or additions
> +  to that Work or Derivative Works thereof, that is intentionally
> +  submitted to Licensor for inclusion in the Work by the copyright owner
> +  or by an individual or Legal Entity authorized to submit on behalf of
> +  the copyright owner. For the purposes of this definition, "submitted"
> +  means any form of electronic, verbal, or written communication sent
> +  to the Licensor or its representatives, including but not limited to
> +  communication on electronic mailing lists, source code control systems,
> +  and issue tracking systems that are managed by, or on behalf of, the
> +  Licensor for the purpose of discussing and improving the Work, but
> +  excluding communication that is conspicuously marked or otherwise
> +  designated in writing by the copyright owner as "Not a Contribution."
> +
> +  "Contributor" shall mean Licensor and any individual or Legal Entity
> +  on behalf of whom a Contribution has been received by Licensor and
> +  subsequently incorporated within the Work.
> +
> +   2. Grant of Copyright License. Subject to the terms and conditions of
> +  this License, each Contributor hereby grants to You a perpetual,
> +  worldwide, non-exclusive, no-charge, royalty-free, irrevocable
> +  copyright license to reproduce, prepare Derivative Works of,
> +  publicly display, publicly perform, sublicense, and distribute the
> +  Work and such Derivative Works in Source or Object form.
> +
> +   3. Grant of Patent License. Subject to the terms and conditions of
> +  this License, each Contributor hereby grants to You a perpetual,
> +  worldwide, non-exclusive, no-charge, royalty-free, irrevocable
> +  (except as stated in this section) patent license to make, have made,
> +  use, offer to sell, sell, import, and otherwise transfer the Work,
> +  where such license applies only to those patent claims licensable
> +  by such 

[PATCH] import Apache License 2.0 text file

[Karel Gardas]

---
 LICENSE.Apache-2.0 | 202 +
 1 file changed, 202 insertions(+)
 create mode 100644 LICENSE.Apache-2.0

diff --git a/LICENSE.Apache-2.0 b/LICENSE.Apache-2.0
new file mode 100644
index 00..d645695673
--- /dev/null
+++ b/LICENSE.Apache-2.0
@@ -0,0 +1,202 @@
+
+ Apache License
+   Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+  "License" shall mean the terms and conditions for use, reproduction,
+  and distribution as defined by Sections 1 through 9 of this document.
+
+  "Licensor" shall mean the copyright owner or entity authorized by
+  the copyright owner that is granting the License.
+
+  "Legal Entity" shall mean the union of the acting entity and all
+  other entities that control, are controlled by, or are under common
+  control with that entity. For the purposes of this definition,
+  "control" means (i) the power, direct or indirect, to cause the
+  direction or management of such entity, whether by contract or
+  otherwise, or (ii) ownership of fifty percent (50%) or more of the
+  outstanding shares, or (iii) beneficial ownership of such entity.
+
+  "You" (or "Your") shall mean an individual or Legal Entity
+  exercising permissions granted by this License.
+
+  "Source" form shall mean the preferred form for making modifications,
+  including but not limited to software source code, documentation
+  source, and configuration files.
+
+  "Object" form shall mean any form resulting from mechanical
+  transformation or translation of a Source form, including but
+  not limited to compiled object code, generated documentation,
+  and conversions to other media types.
+
+  "Work" shall mean the work of authorship, whether in Source or
+  Object form, made available under the License, as indicated by a
+  copyright notice that is included in or attached to the work
+  (an example is provided in the Appendix below).
+
+  "Derivative Works" shall mean any work, whether in Source or Object
+  form, that is based on (or derived from) the Work and for which the
+  editorial revisions, annotations, elaborations, or other modifications
+  represent, as a whole, an original work of authorship. For the purposes
+  of this License, Derivative Works shall not include works that remain
+  separable from, or merely link (or bind by name) to the interfaces of,
+  the Work and Derivative Works thereof.
+
+  "Contribution" shall mean any work of authorship, including
+  the original version of the Work and any modifications or additions
+  to that Work or Derivative Works thereof, that is intentionally
+  submitted to Licensor for inclusion in the Work by the copyright owner
+  or by an individual or Legal Entity authorized to submit on behalf of
+  the copyright owner. For the purposes of this definition, "submitted"
+  means any form of electronic, verbal, or written communication sent
+  to the Licensor or its representatives, including but not limited to
+  communication on electronic mailing lists, source code control systems,
+  and issue tracking systems that are managed by, or on behalf of, the
+  Licensor for the purpose of discussing and improving the Work, but
+  excluding communication that is conspicuously marked or otherwise
+  designated in writing by the copyright owner as "Not a Contribution."
+
+  "Contributor" shall mean Licensor and any individual or Legal Entity
+  on behalf of whom a Contribution has been received by Licensor and
+  subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+  this License, each Contributor hereby grants to You a perpetual,
+  worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+  copyright license to reproduce, prepare Derivative Works of,
+  publicly display, publicly perform, sublicense, and distribute the
+  Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+  this License, each Contributor hereby grants to You a perpetual,
+  worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+  (except as stated in this section) patent license to make, have made,
+  use, offer to sell, sell, import, and otherwise transfer the Work,
+  where such license applies only to those patent claims licensable
+  by such Contributor that are necessarily infringed by their
+  Contribution(s) alone or by combination of their Contribution(s)
+  with the Work to which such Contribution(s) was submitted. If You
+  institute patent litigation against 

Re: [PATCH] build: Export BSP base and family via pkg-config

[Gedare Bloom]

On Tue, Jul 25, 2023 at 5:13 AM Sebastian Huber
 wrote:
>
> This allows application and library build systems to derive option
> values from the BSP base and family names.
> ---
>  spec/build/bsps/pkgconfig.yml | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/spec/build/bsps/pkgconfig.yml b/spec/build/bsps/pkgconfig.yml
> index e08c83fe27..afaffbbf0f 100644
> --- a/spec/build/bsps/pkgconfig.yml
> +++ b/spec/build/bsps/pkgconfig.yml
> @@ -15,6 +15,8 @@ content: |
>ABI_FLAGS=${ABI_FLAGS}
>RTEMS_ARCH=${ARCH}
>RTEMS_BSP=${BSP_NAME}
> +  RTEMS_BSP_BASE=${BSP_BASE}
> +  RTEMS_BSP_FAMILY=${BSP_FAMILY}

These expose a little bit of the internal working of the build system.
I think it's fine, since these two fields should not change over time.
But, it commits us to maintain this mapping and these variables.

>RTEMS_MAJOR=${__RTEMS_MAJOR__}
>RTEMS_MINOR=${__RTEMS_MINOR__}
>RTEMS_REVISION=${__RTEMS_REVISION__}
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 7/8] timecounter: Add files to Doxygen group

[Gedare Bloom]

Same thing here, these are imported files.

On Tue, Jul 25, 2023 at 2:49 AM Sebastian Huber
 wrote:
>
> Update #3707.
> ---
>  cpukit/include/machine/_timecounter.h | 2 ++
>  cpukit/include/sys/_ffcounter.h   | 9 +
>  cpukit/include/sys/timeffc.h  | 9 +
>  cpukit/include/sys/timepps.h  | 9 +
>  cpukit/include/sys/timetc.h   | 9 +
>  cpukit/include/sys/timex.h| 9 +
>  6 files changed, 47 insertions(+)
>
> diff --git a/cpukit/include/machine/_timecounter.h 
> b/cpukit/include/machine/_timecounter.h
> index 127e5f6fd3..e20e051f84 100644
> --- a/cpukit/include/machine/_timecounter.h
> +++ b/cpukit/include/machine/_timecounter.h
> @@ -3,6 +3,8 @@
>  /**
>   * @file
>   *
> + * @ingroup RTEMSScoreTimecounter
> + *
>   * @brief This header file provides timecounter definitions for the kernel 
> space
>   *   (_KERNEL is defined before including ) and RTEMS.
>   */
> diff --git a/cpukit/include/sys/_ffcounter.h b/cpukit/include/sys/_ffcounter.h
> index d83c48cd44..802c7d3224 100644
> --- a/cpukit/include/sys/_ffcounter.h
> +++ b/cpukit/include/sys/_ffcounter.h
> @@ -1,3 +1,12 @@
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreTimecounter
> + *
> + * @brief This header file provides interfaces of the feed-forward clock
> + *   counter.
> + */
> +
>  /*-
>   * Copyright (c) 2011 The University of Melbourne
>   * All rights reserved.
> diff --git a/cpukit/include/sys/timeffc.h b/cpukit/include/sys/timeffc.h
> index c04de97f1d..13abd37a2b 100644
> --- a/cpukit/include/sys/timeffc.h
> +++ b/cpukit/include/sys/timeffc.h
> @@ -1,3 +1,12 @@
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreTimecounter
> + *
> + * @brief This header file provides interfaces of the feed-back and
> + *   feed-forward clock implementations.
> + */
> +
>  /*-
>   * Copyright (c) 2011 The University of Melbourne
>   * All rights reserved.
> diff --git a/cpukit/include/sys/timepps.h b/cpukit/include/sys/timepps.h
> index 030c734477..502d93833e 100644
> --- a/cpukit/include/sys/timepps.h
> +++ b/cpukit/include/sys/timepps.h
> @@ -1,3 +1,12 @@
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreTimecounter
> + *
> + * @brief This header file provides interfaces of the Pulse Per Second (PPS)
> + *   support.
> + */
> +
>  /*-
>   * 
> 
>   * "THE BEER-WARE LICENSE" (Revision 42):
> diff --git a/cpukit/include/sys/timetc.h b/cpukit/include/sys/timetc.h
> index 1ef58b378d..8f2537692c 100644
> --- a/cpukit/include/sys/timetc.h
> +++ b/cpukit/include/sys/timetc.h
> @@ -1,3 +1,12 @@
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreTimecounter
> + *
> + * @brief This header file provides interfaces of the timecounter
> + *   implementation.
> + */
> +
>  /*-
>   * 
> 
>   * "THE BEER-WARE LICENSE" (Revision 42):
> diff --git a/cpukit/include/sys/timex.h b/cpukit/include/sys/timex.h
> index 8e763bb30f..36b1fcdb5a 100644
> --- a/cpukit/include/sys/timex.h
> +++ b/cpukit/include/sys/timex.h
> @@ -1,3 +1,12 @@
> +/**
> + * @file
> + *
> + * @ingroup RTEMSScoreTimecounter
> + *
> + * @brief This header file provides interfaces of the Network Time Protocol
> + *   (NTP) support.
> + */
> +
>  /*-
>   ***
>   **
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 0/8] Add files to Doxygen groups

[Gedare Bloom]

Looks good except my comment about the cpukit/include/sys files
imported from Bsd

On Tue, Jul 25, 2023 at 2:49 AM Sebastian Huber
 wrote:
>
> Frank Kühndel (1):
>   bsps/sparc: Add files to Doxygen groups
>
> Sebastian Huber (7):
>   libtest: Place files into a Doxygen group
>   rtems: Add files to Doxygen groups
>   score: Add files to Doxygen groups
>   libcsupport: Add file to Doxygen group
>   posix: Add files to Doxygen group
>   timecounter: Add files to Doxygen group
>   sys: Add files to Doxygen group
>
>  bsps/shared/rtems-version.c   |  9 ++
>  bsps/sparc/include/bsp/gnatcommon.h   | 15 +++
>  bsps/sparc/include/bsp/gr_leon4_n2x.h | 10 +-
>  bsps/sparc/include/drvmgr/leon2_amba_bus.h| 10 +-
>  bsps/sparc/leon3/clock/ckinit.c   | 13 +--
>  bsps/sparc/leon3/console/printk_support.c | 11 ++-
>  bsps/sparc/leon3/start/bspstart.c | 14 ++-
>  bsps/sparc/leon3/start/cache.c|  8 ++
>  bsps/sparc/leon3/start/cpucounter.c   |  8 ++
>  bsps/sparc/leon3/start/eirq.c | 11 ++-
>  bsps/sparc/shared/irq/bsp_isr_handler.c   |  9 ++
>  cpukit/doxygen/top-level-groups.h |  8 ++
>  cpukit/include/machine/_timecounter.h |  2 +
>  cpukit/include/rtems/linkersets.h | 50 --
>  cpukit/include/rtems/posix/posixapi.h |  6 +-
>  cpukit/include/rtems/posix/spinlockimpl.h |  8 +-
>  cpukit/include/rtems/sysinit.h| 91 ++-
>  cpukit/include/rtems/test-info.h  |  9 ++
>  cpukit/include/rtems/test.h   | 13 ++-
>  cpukit/include/rtems/thread.h | 21 +
>  cpukit/include/sys/_ffcounter.h   |  9 ++
>  cpukit/include/sys/endian.h   |  9 ++
>  cpukit/include/sys/priority.h |  8 ++
>  cpukit/include/sys/statvfs.h  |  7 +-
>  cpukit/include/sys/timeffc.h  |  9 ++
>  cpukit/include/sys/timepps.h  |  9 ++
>  cpukit/include/sys/timetc.h   |  9 ++
>  cpukit/include/sys/timex.h|  9 ++
>  cpukit/libcsupport/src/malloc_p.h | 11 ++-
>  cpukit/libtest/t-test-busy-tick.c |  3 +-
>  cpukit/libtest/t-test-busy.c  |  3 +-
>  cpukit/libtest/t-test-checks-eno.c| 13 ++-
>  cpukit/libtest/t-test-checks-psx.c|  5 +-
>  cpukit/libtest/t-test-checks.c| 13 ++-
>  cpukit/libtest/t-test-hash-sha256.c   | 13 ++-
>  cpukit/libtest/t-test-interrupt.c |  3 +-
>  cpukit/libtest/t-test-rtems-context.c | 13 ++-
>  cpukit/libtest/t-test-rtems-fds.c | 13 ++-
>  cpukit/libtest/t-test-rtems-heap.c| 13 ++-
>  cpukit/libtest/t-test-rtems-measure.c | 13 ++-
>  cpukit/libtest/t-test-rtems-memory.c  |  9 ++
>  cpukit/libtest/t-test-rtems-objs.c|  5 +-
>  cpukit/libtest/t-test-rtems-posix-keys.c  |  5 +-
>  cpukit/libtest/t-test-rtems.c | 13 ++-
>  cpukit/libtest/t-test-rtems.h |  5 +-
>  cpukit/libtest/t-test-thread-switch.c |  3 +-
>  cpukit/libtest/t-test-time.c  | 13 ++-
>  cpukit/libtest/t-test.c   | 13 ++-
>  cpukit/libtest/testbeginend.c |  9 ++
>  cpukit/sapi/src/cpucounterconverter.c |  9 ++
>  cpukit/sapi/src/version.c |  2 +-
>  cpukit/score/cpu/no_cpu/cpuidle.c |  9 ++
>  .../cpu/sparc/include/libcpu/grlib-tn-0018.h  |  9 ++
>  cpukit/score/cpu/sparc/syscall.h  |  8 ++
>  54 files changed, 528 insertions(+), 95 deletions(-)
>
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 8/8] sys: Add files to Doxygen group

[Gedare Bloom]

priority.h and endian.h are imported code. We should modify with care.
I'm not opposed, we just have to think twice.

On Tue, Jul 25, 2023 at 2:49 AM Sebastian Huber
 wrote:
>
> Canonicalize brief descriptions.
>
> Update #3707.
> ---
>  cpukit/doxygen/top-level-groups.h | 8 
>  cpukit/include/sys/endian.h   | 9 +
>  cpukit/include/sys/priority.h | 8 
>  cpukit/include/sys/statvfs.h  | 7 ---
>  4 files changed, 29 insertions(+), 3 deletions(-)
>
> diff --git a/cpukit/doxygen/top-level-groups.h 
> b/cpukit/doxygen/top-level-groups.h
> index fd32db347a..9d34b3e3dd 100644
> --- a/cpukit/doxygen/top-level-groups.h
> +++ b/cpukit/doxygen/top-level-groups.h
> @@ -40,6 +40,14 @@
>   *   RTEMS.
>   */
>
> +/**
> + * @defgroup RTEMSAPISystemLibrary System Library
> + *
> + * @ingroup RTEMSAPI
> + *
> + * @brief This group contains the system library APIs of RTEMS.
> + */
> +
>  /**
>   * @defgroup RTEMSDeviceDrivers Device Drivers
>   *
> diff --git a/cpukit/include/sys/endian.h b/cpukit/include/sys/endian.h
> index 0849a6a90b..cdd6201736 100644
> --- a/cpukit/include/sys/endian.h
> +++ b/cpukit/include/sys/endian.h
> @@ -1,3 +1,12 @@
> +/**
> + * @file
> + *
> + * @ingroup RTEMSAPISystemLibrary
> + *
> + * @brief This header file provides interfaces of the system endianness
> + *   support.
> + */
> +
>  /*-
>   * Copyright (c) 2002 Thomas Moestl 
>   * All rights reserved.
> diff --git a/cpukit/include/sys/priority.h b/cpukit/include/sys/priority.h
> index 855edb63c2..37d0d938dc 100644
> --- a/cpukit/include/sys/priority.h
> +++ b/cpukit/include/sys/priority.h
> @@ -1,3 +1,11 @@
> +/**
> + * @file
> + *
> + * @ingroup RTEMSAPISystemLibrary
> + *
> + * @brief This header file provides interfaces of the process priority 
> support.
> + */
> +
>  /*-
>   * SPDX-License-Identifier: BSD-4-Clause
>   *
> diff --git a/cpukit/include/sys/statvfs.h b/cpukit/include/sys/statvfs.h
> index 52d8e9d3fa..655f9a596c 100644
> --- a/cpukit/include/sys/statvfs.h
> +++ b/cpukit/include/sys/statvfs.h
> @@ -3,10 +3,11 @@
>  /**
>   * @file
>   *
> - * @brief Interface to the statvfs() Set of API Methods
> + * @ingroup RTEMSAPISystemLibrary
>   *
> - * This include file defines the interface to the statvfs() set of
> - * API methods. The statvfs as defined by the SUS:
> + * @brief This header file provides the statvfs() and fstatvfs() interfaces.
> + *
> + * The statvfs() is defined by the SUS:
>   *
>   * - 
> http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/statvfs.h.html
>   */
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/arm: fix nested extern decl. warnings brought by CMSIS files update

[Christian MAUDERER]

On 2023-07-25 16:20, Karel Gardas wrote:

On 7/25/23 15:32, Sebastian Huber wrote:



On 21.07.23 17:37, Karel Gardas wrote:

---
  bsps/arm/include/cmsis_gcc.h | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/bsps/arm/include/cmsis_gcc.h b/bsps/arm/include/cmsis_gcc.h
index 4f0762d6dc..9e867348d2 100644
--- a/bsps/arm/include/cmsis_gcc.h
+++ b/bsps/arm/include/cmsis_gcc.h
@@ -30,7 +30,9 @@
  #pragma GCC diagnostic ignored "-Wsign-conversion"
  #pragma GCC diagnostic ignored "-Wconversion"
  #pragma GCC diagnostic ignored "-Wunused-parameter"
-
+#ifdef __rtems__
+#pragma GCC diagnostic ignored "-Wnested-externs"
+#endif /* __rtems__ */
  /* Fallback for __has_builtin */
  #ifndef __has_builtin
    #define __has_builtin(x) (0)


I would disable this warning only in __cmsis_start() with a push/pop 
pragma.


Will look into it. The way it was done was to reuse as much as possible 
of the current file infrastructure.



I think you have to add also a

  * Modifications Copyright (C) Karel Gardas

if you change the file, see also:


It's a shame to need to copyright single liners. IMHO license does not 
require that precisely. What about to just add:


/* The file was modified for the purposes of RTEMS project */

right at the beginning (1st line) of file?



Apache clearly states that modified files have to be marked:

4.b.: You must cause any modified files to carry prominent notices 
stating that You changed the files


Not sure whether the big 'You' means that it is a person or a project. 
RTEMS project distributes the files so "adapted by RTEMS contributors" 
might work?


By the way: I just noted that we now most likely also need a 
LICENSE.Apache-2.0 file in the root directory of RTEMS.



https://softwareengineering.stackexchange.com/questions/220068/file-with-apache-2-0-and-my-modifications

In general, some advice for dealing with Apache 2.0 files in the RTEMS 
Software Engineering manual would be nice.


That would be great to have, but who would do that? > Or perhaps we may
distill right behavioral patterns from our competitors: Zephyr/NuttX?

E.g. 
https://github.com/apache/nuttx/commits/master/net/tcp/tcp_getsockopt.c 
-- file modified by several persons and none is mentioned (do all of 
them have signed contributor agreement with ASF?)


and

https://github.com/zephyrproject-rtos/zephyr/commits/main/kernel/paging/statistics.c
 -- file modified by jfisher-no (from Nordic Semiconductor) and yet, file 
clearly copyrighted by Intel and no message about modification by anyone else.



Nuttx and Zephyr are both Apache-Licensed. Both files that you have 
linked seem to be developed for the systems. At least I didn't find an 
"import from xyz" commit or similar hint. I think that makes the 
situation different compared to our import of Apache licensed third 
party code into a non-Apache licensed project.


Another idea my be to go with what Joel suggested in the original 
CMSISv5 inclusion thread: put any modification into #ifdef __rtems__ / 
#endif and make that clearly visible that file was changed this way. 
Nothing more needed...


Marking changes with #ifdef __rtems__ is always a good idea because it 
makes porting the changes during the next update simpler.


I would expect that at least a general "modified for RTEMS" or "modified 
by RTEMS contributors" statement is still necessary.


If you want to get a definitive answer what is the right solution and 
end all the discussions, you might consider asking that question on the 
FSFE License Question list and post the result here and / or add it to 
the manual (assuming that they agree that the answer is published):


  https://fsfe.org/activities/legal.en.html

Best regards

Christian



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


--

embedded brains GmbH & Co. KG
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: HRA 117265
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/arm: fix nested extern decl. warnings brought by CMSIS files update

[Sebastian Huber]

On 25.07.23 16:20, Karel Gardas wrote:

On 7/25/23 15:32, Sebastian Huber wrote:



On 21.07.23 17:37, Karel Gardas wrote:

---
  bsps/arm/include/cmsis_gcc.h | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/bsps/arm/include/cmsis_gcc.h b/bsps/arm/include/cmsis_gcc.h
index 4f0762d6dc..9e867348d2 100644
--- a/bsps/arm/include/cmsis_gcc.h
+++ b/bsps/arm/include/cmsis_gcc.h
@@ -30,7 +30,9 @@
  #pragma GCC diagnostic ignored "-Wsign-conversion"
  #pragma GCC diagnostic ignored "-Wconversion"
  #pragma GCC diagnostic ignored "-Wunused-parameter"
-
+#ifdef __rtems__
+#pragma GCC diagnostic ignored "-Wnested-externs"
+#endif /* __rtems__ */
  /* Fallback for __has_builtin */
  #ifndef __has_builtin
    #define __has_builtin(x) (0)


I would disable this warning only in __cmsis_start() with a push/pop 
pragma.


Will look into it. The way it was done was to reuse as much as possible 
of the current file infrastructure.



I think you have to add also a

  * Modifications Copyright (C) Karel Gardas

if you change the file, see also:


It's a shame to need to copyright single liners. IMHO license does not 
require that precisely. What about to just add:


/* The file was modified for the purposes of RTEMS project */

right at the beginning (1st line) of file?


https://softwareengineering.stackexchange.com/questions/220068/file-with-apache-2-0-and-my-modifications

In general, some advice for dealing with Apache 2.0 files in the RTEMS 
Software Engineering manual would be nice.


That would be great to have, but who would do that? Or perhaps we may 
distill right behavioral patterns from our competitors: Zephyr/NuttX?


E.g. 
https://github.com/apache/nuttx/commits/master/net/tcp/tcp_getsockopt.c 
-- file modified by several persons and none is mentioned (do all of 
them have signed contributor agreement with ASF?)


and

https://github.com/zephyrproject-rtos/zephyr/commits/main/kernel/paging/statistics.c
 -- file modified by jfisher-no (from Nordic Semiconductor) and yet, file 
clearly copyrighted by Intel and no message about modification by anyone else.


I guess that the contributions to the origin of the work do not count as 
redistributions, but I am not a license expert.




Another idea my be to go with what Joel suggested in the original 
CMSISv5 inclusion thread: put any modification into #ifdef __rtems__ / 
#endif and make that clearly visible that file was changed this way. 
Nothing more needed...


Ideally, the guidelines would be in the RTEMS Software Engineering 
manual before we added the Apache 2.0 files. We should avoid that every 
contributor has to figure out what to do. I you think that this 
__rtems__ stuff is enough, then just document it. Zephyr for example has 
a clear process to add new licenses:


https://docs.zephyrproject.org/latest/contribute/external.html

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

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

[PATCH] build: Add optional RTEMS_VERSION_VC_KEY

[Sebastian Huber]

Allow the user to set the version control key.
---
 spec/build/cpukit/grp.yml |  2 ++
 spec/build/cpukit/optversionvckey.yml | 20 ++
 wscript   | 38 ---
 3 files changed, 44 insertions(+), 16 deletions(-)
 create mode 100644 spec/build/cpukit/optversionvckey.yml

diff --git a/spec/build/cpukit/grp.yml b/spec/build/cpukit/grp.yml
index e07e975d7d..fbeab45b5c 100644
--- a/spec/build/cpukit/grp.yml
+++ b/spec/build/cpukit/grp.yml
@@ -18,6 +18,8 @@ links:
   uid: cpuopts
 - role: build-dependency
   uid: cfghdr
+- role: build-dependency
+  uid: optversionvckey
 - role: build-dependency
   uid: libdebugger
 - role: build-dependency
diff --git a/spec/build/cpukit/optversionvckey.yml 
b/spec/build/cpukit/optversionvckey.yml
new file mode 100644
index 00..7197381342
--- /dev/null
+++ b/spec/build/cpukit/optversionvckey.yml
@@ -0,0 +1,20 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- env-assign: null
+build-type: option
+copyrights:
+- Copyright (C) 2022, 2023 embedded brains GmbH & Co. KG
+default:
+- enabled-by: true
+  value: ''
+description: |
+  If defined to a non-empty value, then the value will be used for the version
+  control key returned by rtems_version() and rtems_version_control_key(),
+  otherwise the value will be determined by the Git repository containing the
+  waf top directory.
+enabled-by: true
+format: '{}'
+links: []
+name: RTEMS_VERSION_VC_KEY
+type: build
diff --git a/wscript b/wscript
index 862000513d..2026d55070 100755
--- a/wscript
+++ b/wscript
@@ -58,38 +58,44 @@ def no_unicode(value):
 
 
 class VersionControlKeyHeader:
-_content = None
+_git_commit = None
 
 @staticmethod
 def write(bld, filename):
-if VersionControlKeyHeader._content is None:
-from waflib.Build import Context
-from waflib.Errors import WafError
-
-content = """/*
+content = """/*
  * Automatically generated. Do not edit.
  */
 #if !defined(_RTEMS_VERSION_VC_KEY_H_)
 #define _RTEMS_VERSION_VC_KEY_H_
 """
-try:
-rev = bld.cmd_and_log("git rev-parse HEAD",
-  quiet=Context.STDOUT).strip()
-content += """#define RTEMS_VERSION_VC_KEY "{}"
+rev = bld.env.RTEMS_VERSION_VC_KEY
+if not rev:
+rev = VersionControlKeyHeader._git_commit
+if rev is None:
+from waflib.Build import Context
+from waflib.Errors import WafError
+
+try:
+rev = bld.cmd_and_log("git rev-parse HEAD",
+  quiet=Context.STDOUT).strip()
+except WafError:
+rev = ""
+VersionControlKeyHeader._git_commit = rev
+if rev:
+content += """#define RTEMS_VERSION_VC_KEY "{}"
 """.format(rev)
-except WafError:
-content += """/* No version control key found; release? */
+else:
+content += """/* No version control key found; release? */
 """
-content += """#endif
+content += """#endif
 """
-VersionControlKeyHeader._content = content
 f = bld.bldnode.make_node(filename)
 f.parent.mkdir()
 try:
 if content != f.read():
-f.write(VersionControlKeyHeader._content)
+f.write(content)
 except:
-f.write(VersionControlKeyHeader._content)
+f.write(content)
 
 
 class EnvWrapper(object):
-- 
2.35.3

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

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

[Christian MAUDERER]

Hello Joel,

On 2023-07-25 16:14, Joel Sherrill wrote:



On Tue, Jul 25, 2023 at 9:08 AM Christian MAUDERER 
> wrote:


Hello Joel,

On 2023-07-25 15:46, Joel Sherrill wrote:
 >
 >
 > On Tue, Jul 25, 2023 at 5:02 AM Christian MAUDERER
 > mailto:christian.maude...@embedded-brains.de>
 > >> wrote:
 >
 >     Hello,
 >
 >     I noted that some BSPs are missing in the config files in the
 >     rtems-tools repo. If I didn't miss one it's:
 >
 >           - aarch64, raspberrypi4b
 >           - aarch64, xilinx_zynqmp_lp64_cfc400x
 >           - arm, imxrt1166-cm7-saltshaker
 >           - arm, stm32h750b-dk
 >           - powerpc, mvme2700
 >           - powerpc, phycore_mpc5554
 >           - riscv, kendrytek210
 >           - x86_64, amd64efi
 >
 >     One of the BSPs is from me. I don't know of the other ones.


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

 >
 >     I noted the configuration files in that repo just now more or
less by
 >     chance when playing around with rtems-bsp-builder. I wasn't
aware that
 >     we have a second list beneath the one printed by the `rtems-bsps`
 >     script
 >     or `waf bsp-list` in the RTEMS repo.


I would hope they are related under the hood. But rtems-bsps already can
produce the bsp list in a lot of formats. Perhaps just having it product the
ini file would help.



Could be useful as a first step, yes. If I find some time, I'll take a 
look at that.



 >
 >
 > Yep. The list of bsps in the ini files for rtems-bsp-builder get
out of
 > date.
 > I was probably the last one to try to sync them back in March.
 >
 > We need some scripting to check them both ways -- additions from
rtems
 > and deletions from RTEMS need to be reflected.
 >
 > If we had some tool which checked this, I'd be happy to run it to the
 > cron jobs that do build sweeps and Coverity runs.
 >

Wouldn't it be better to try to integrate the information from the ini
files into the yml files of the new build system? That way they
can't go
out of sync. Or is there a special reason that they have to be separate?


Chris would have to answer this. At this point, I don't think the tools 
know

about the RTEMS repo. But rtems-bsp-builder is special so it could ask
rtems to generate that ini file. That might be easy.



I tried it with rtems-bsp-builder and that one should know the sources. 
Otherwise, it can't build the BSPs. But it's possible that the ini files 
are used in other tools too.


I'll wait for a day or two whether Chris has an answer.



  From a quick glance, every BSP would need an additional "exclude-smp"
and "tier" parameter for that.


Long term, that would be good information to have anyway.


 >
 >     Did I miss that I should have updated rtems-tools (and with
that the
 >     rtems-source-builder) every time I have added a BSP in the
past? Or
 >     would it only make problems if I would update these files
manually
 >     because they are usually created by some script during the
release
 >     process?
 >
 >
 > Yes. And we all forget to do it.

To be honest: I haven't known these files or completely erased that I
ever knew them from my memory till a few hours ago. I'll try to
remember
that I have to adapt them if I add a new BSP from now on.


I only randomly trip across them myself.


 >
 > I don't know if it is documented at all. It should be. I don't
know where it
 > would go. Tooling to check consistency would help.
 >
 > The other part of this is the forgotten concept of BSP tiers.
Tier 1 is for
 > BSPs with test results reported on real hardware. We don't see that
 > regularly.
 >
 > Tier 2 is simulator testing. We do a lot of that. Speaking for
Chris,
 > he'd like
 > to see the tests annotated for those not passing.
 >
 > Tier 3 is "it builds" and we do a good job of keeping that going.
I'm
 > not sure
 > we have been on a warning search and destroy lately though.
 >
 > Tier 4 is "does not build". These tend to be transient or
precursors to the
 > architecture losing tooling and us dropping it.

Yes, these are documented:
https://docs.rtems.org/branches/master/user/hardware/tiers.html


I think the Tiers might start to live again as soon as we have a CI/CD
system and the checks for the tiers are automated with that. Till then,
the tires will most 

Re: [PATCH] bsps/arm: fix nested extern decl. warnings brought by CMSIS files update

[Karel Gardas]

On 7/25/23 15:32, Sebastian Huber wrote:



On 21.07.23 17:37, Karel Gardas wrote:

---
  bsps/arm/include/cmsis_gcc.h | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/bsps/arm/include/cmsis_gcc.h b/bsps/arm/include/cmsis_gcc.h
index 4f0762d6dc..9e867348d2 100644
--- a/bsps/arm/include/cmsis_gcc.h
+++ b/bsps/arm/include/cmsis_gcc.h
@@ -30,7 +30,9 @@
  #pragma GCC diagnostic ignored "-Wsign-conversion"
  #pragma GCC diagnostic ignored "-Wconversion"
  #pragma GCC diagnostic ignored "-Wunused-parameter"
-
+#ifdef __rtems__
+#pragma GCC diagnostic ignored "-Wnested-externs"
+#endif /* __rtems__ */
  /* Fallback for __has_builtin */
  #ifndef __has_builtin
    #define __has_builtin(x) (0)


I would disable this warning only in __cmsis_start() with a push/pop 
pragma.


Will look into it. The way it was done was to reuse as much as possible 
of the current file infrastructure.



I think you have to add also a

  * Modifications Copyright (C) Karel Gardas

if you change the file, see also:


It's a shame to need to copyright single liners. IMHO license does not 
require that precisely. What about to just add:


/* The file was modified for the purposes of RTEMS project */

right at the beginning (1st line) of file?


https://softwareengineering.stackexchange.com/questions/220068/file-with-apache-2-0-and-my-modifications

In general, some advice for dealing with Apache 2.0 files in the RTEMS 
Software Engineering manual would be nice.


That would be great to have, but who would do that? Or perhaps we may 
distill right behavioral patterns from our competitors: Zephyr/NuttX?


E.g. 
https://github.com/apache/nuttx/commits/master/net/tcp/tcp_getsockopt.c 
-- file modified by several persons and none is mentioned (do all of 
them have signed contributor agreement with ASF?)


and

https://github.com/zephyrproject-rtos/zephyr/commits/main/kernel/paging/statistics.c 
-- file modified by jfisher-no (from Nordic Semiconductor) and yet, file 
clearly copyrighted by Intel and no message about modification by anyone 
else.


Another idea my be to go with what Joel suggested in the original 
CMSISv5 inclusion thread: put any modification into #ifdef __rtems__ / 
#endif and make that clearly visible that file was changed this way. 
Nothing more needed...


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

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

[Joel Sherrill]

On Tue, Jul 25, 2023 at 9:08 AM Christian MAUDERER <
christian.maude...@embedded-brains.de> wrote:

> Hello Joel,
>
> On 2023-07-25 15:46, Joel Sherrill wrote:
> >
> >
> > On Tue, Jul 25, 2023 at 5:02 AM Christian MAUDERER
> >  > > wrote:
> >
> > Hello,
> >
> > I noted that some BSPs are missing in the config files in the
> > rtems-tools repo. If I didn't miss one it's:
> >
> >   - aarch64, raspberrypi4b
> >   - aarch64, xilinx_zynqmp_lp64_cfc400x
> >   - arm, imxrt1166-cm7-saltshaker
> >   - arm, stm32h750b-dk
> >   - powerpc, mvme2700
> >   - powerpc, phycore_mpc5554
> >   - riscv, kendrytek210
> >   - x86_64, amd64efi
> >
> > One of the BSPs is from me. I don't know of the other ones.
>

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


> >
> > I noted the configuration files in that repo just now more or less by
> > chance when playing around with rtems-bsp-builder. I wasn't aware
> that
> > we have a second list beneath the one printed by the `rtems-bsps`
> > script
> > or `waf bsp-list` in the RTEMS repo.
>

I would hope they are related under the hood. But rtems-bsps already can
produce the bsp list in a lot of formats. Perhaps just having it product the
ini file would help.


> >
> >
> > Yep. The list of bsps in the ini files for rtems-bsp-builder get out of
> > date.
> > I was probably the last one to try to sync them back in March.
> >
> > We need some scripting to check them both ways -- additions from rtems
> > and deletions from RTEMS need to be reflected.
> >
> > If we had some tool which checked this, I'd be happy to run it to the
> > cron jobs that do build sweeps and Coverity runs.
> >
>
> Wouldn't it be better to try to integrate the information from the ini
> files into the yml files of the new build system? That way they can't go
> out of sync. Or is there a special reason that they have to be separate?
>

Chris would have to answer this. At this point, I don't think the tools
know
about the RTEMS repo. But rtems-bsp-builder is special so it could ask
rtems to generate that ini file. That might be easy.


>
>  From a quick glance, every BSP would need an additional "exclude-smp"
> and "tier" parameter for that.
>

Long term, that would be good information to have anyway.

>
> >
> > Did I miss that I should have updated rtems-tools (and with that the
> > rtems-source-builder) every time I have added a BSP in the past? Or
> > would it only make problems if I would update these files manually
> > because they are usually created by some script during the release
> > process?
> >
> >
> > Yes. And we all forget to do it.
>
> To be honest: I haven't known these files or completely erased that I
> ever knew them from my memory till a few hours ago. I'll try to remember
> that I have to adapt them if I add a new BSP from now on.
>

I only randomly trip across them myself.

>
> >
> > I don't know if it is documented at all. It should be. I don't know
> where it
> > would go. Tooling to check consistency would help.
> >
> > The other part of this is the forgotten concept of BSP tiers. Tier 1 is
> for
> > BSPs with test results reported on real hardware. We don't see that
> > regularly.
> >
> > Tier 2 is simulator testing. We do a lot of that. Speaking for Chris,
> > he'd like
> > to see the tests annotated for those not passing.
> >
> > Tier 3 is "it builds" and we do a good job of keeping that going. I'm
> > not sure
> > we have been on a warning search and destroy lately though.
> >
> > Tier 4 is "does not build". These tend to be transient or precursors to
> the
> > architecture losing tooling and us dropping it.
>
> Yes, these are documented:
> https://docs.rtems.org/branches/master/user/hardware/tiers.html
>
> I think the Tiers might start to live again as soon as we have a CI/CD
> system and the checks for the tiers are automated with that. Till then,
> the tires will most likely only be checked sporadically.
>

Chris and I sometimes poke at people with hardware to produce reports
but it doesn't happen enough.

--joel


>
> Best regards
>
> Christian
>
> >
> > --joel
> >
> >
> > Best regards
> >
> > Christian
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Christian MAUDERER]

Hello Joel,

On 2023-07-25 15:46, Joel Sherrill wrote:



On Tue, Jul 25, 2023 at 5:02 AM Christian MAUDERER 
> wrote:


Hello,

I noted that some BSPs are missing in the config files in the
rtems-tools repo. If I didn't miss one it's:

      - aarch64, raspberrypi4b
      - aarch64, xilinx_zynqmp_lp64_cfc400x
      - arm, imxrt1166-cm7-saltshaker
      - arm, stm32h750b-dk
      - powerpc, mvme2700
      - powerpc, phycore_mpc5554
      - riscv, kendrytek210
      - x86_64, amd64efi

One of the BSPs is from me. I don't know of the other ones.

I noted the configuration files in that repo just now more or less by
chance when playing around with rtems-bsp-builder. I wasn't aware that
we have a second list beneath the one printed by the `rtems-bsps`
script
or `waf bsp-list` in the RTEMS repo.


Yep. The list of bsps in the ini files for rtems-bsp-builder get out of 
date.

I was probably the last one to try to sync them back in March.

We need some scripting to check them both ways -- additions from rtems
and deletions from RTEMS need to be reflected.

If we had some tool which checked this, I'd be happy to run it to the
cron jobs that do build sweeps and Coverity runs.



Wouldn't it be better to try to integrate the information from the ini 
files into the yml files of the new build system? That way they can't go 
out of sync. Or is there a special reason that they have to be separate?


From a quick glance, every BSP would need an additional "exclude-smp" 
and "tier" parameter for that.




Did I miss that I should have updated rtems-tools (and with that the
rtems-source-builder) every time I have added a BSP in the past? Or
would it only make problems if I would update these files manually
because they are usually created by some script during the release
process?


Yes. And we all forget to do it.


To be honest: I haven't known these files or completely erased that I 
ever knew them from my memory till a few hours ago. I'll try to remember 
that I have to adapt them if I add a new BSP from now on.




I don't know if it is documented at all. It should be. I don't know where it
would go. Tooling to check consistency would help.

The other part of this is the forgotten concept of BSP tiers. Tier 1 is for
BSPs with test results reported on real hardware. We don't see that 
regularly.


Tier 2 is simulator testing. We do a lot of that. Speaking for Chris, 
he'd like

to see the tests annotated for those not passing.

Tier 3 is "it builds" and we do a good job of keeping that going. I'm 
not sure

we have been on a warning search and destroy lately though.

Tier 4 is "does not build". These tend to be transient or precursors to the
architecture losing tooling and us dropping it.


Yes, these are documented: 
https://docs.rtems.org/branches/master/user/hardware/tiers.html


I think the Tiers might start to live again as soon as we have a CI/CD 
system and the checks for the tiers are automated with that. Till then, 
the tires will most likely only be checked sporadically.


Best regards

Christian



--joel


Best regards

Christian

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

Re: [PATCH] score: Add workaround for GCC bug

[Joel Sherrill]

On Tue, Jul 25, 2023 at 8:55 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 25.07.23 15:52, Joel Sherrill wrote:
> > Is something similar going to be needed for architecture and BSP
> > specific IDLE threads?
>
> You have to run gcov to figure this out. The GCC bug seems to trigger
> only in very specific circumstances.
>

OK. Just something to be aware of then.

Thanks.

--joel

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

Re: [PATCH] score: Add workaround for GCC bug

[Sebastian Huber]

On 25.07.23 15:52, Joel Sherrill wrote:
Is something similar going to be needed for architecture and BSP 
specific IDLE threads?


You have to run gcov to figure this out. The GCC bug seems to trigger 
only in very specific circumstances.


--
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] score: Add workaround for GCC bug

[Joel Sherrill]

Is something similar going to be needed for architecture and BSP specific
IDLE threads?

--joel

On Tue, Jul 25, 2023 at 1:09 AM Chris Johns  wrote:

> OK
>
> Chris
>
> On 25/7/2023 4:04 pm, Sebastian Huber wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
> >
> > This GCC bug leads to an incomplete code coverage status.
> >
> > Update #4932.
> > ---
> >  cpukit/score/cpu/no_cpu/cpuidle.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/cpukit/score/cpu/no_cpu/cpuidle.c
> b/cpukit/score/cpu/no_cpu/cpuidle.c
> > index bff1309d39..a6001e73b0 100644
> > --- a/cpukit/score/cpu/no_cpu/cpuidle.c
> > +++ b/cpukit/score/cpu/no_cpu/cpuidle.c
> > @@ -33,6 +33,13 @@
> >
> >  void *_CPU_Thread_Idle_body( uintptr_t ignored )
> >  {
> > +  /*
> > +   * This is a workaround for:
> > +   *
> > +   * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
> > +   */
> > +  __asm__ volatile ("");
> > +
> >while ( true ) {
> >  /* Do nothing */
> >}
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Joel Sherrill]

On Tue, Jul 25, 2023 at 5:02 AM Christian MAUDERER <
christian.maude...@embedded-brains.de> wrote:

> Hello,
>
> I noted that some BSPs are missing in the config files in the
> rtems-tools repo. If I didn't miss one it's:
>
>  - aarch64, raspberrypi4b
>  - aarch64, xilinx_zynqmp_lp64_cfc400x
>  - arm, imxrt1166-cm7-saltshaker
>  - arm, stm32h750b-dk
>  - powerpc, mvme2700
>  - powerpc, phycore_mpc5554
>  - riscv, kendrytek210
>  - x86_64, amd64efi
>
> One of the BSPs is from me. I don't know of the other ones.
>
> I noted the configuration files in that repo just now more or less by
> chance when playing around with rtems-bsp-builder. I wasn't aware that
> we have a second list beneath the one printed by the `rtems-bsps` script
> or `waf bsp-list` in the RTEMS repo.
>

Yep. The list of bsps in the ini files for rtems-bsp-builder get out of
date.
I was probably the last one to try to sync them back in March.

We need some scripting to check them both ways -- additions from rtems
and deletions from RTEMS need to be reflected.

If we had some tool which checked this, I'd be happy to run it to the
cron jobs that do build sweeps and Coverity runs.


> Did I miss that I should have updated rtems-tools (and with that the
> rtems-source-builder) every time I have added a BSP in the past? Or
> would it only make problems if I would update these files manually
> because they are usually created by some script during the release process?
>

Yes. And we all forget to do it.

I don't know if it is documented at all. It should be. I don't know where it
would go. Tooling to check consistency would help.

The other part of this is the forgotten concept of BSP tiers. Tier 1 is for
BSPs with test results reported on real hardware. We don't see that
regularly.

Tier 2 is simulator testing. We do a lot of that. Speaking for Chris, he'd
like
to see the tests annotated for those not passing.

Tier 3 is "it builds" and we do a good job of keeping that going. I'm not
sure
we have been on a warning search and destroy lately though.

Tier 4 is "does not build". These tend to be transient or precursors to the
architecture losing tooling and us dropping it.

--joel

>
> Best regards
>
> Christian
> --
> 
> embedded brains GmbH & Co. KG
> 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: HRA 117265
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1 2/2] bsps/stm32h7: Configure UART clocks when enabled

[Kinsey Moore]

Unfortunately, this board is not publicly advertised or available and so a
dedicated BSP in RTEMS is not really appropriate. It seems that the current
"stm32h7" BSP should be renamed to stm32h743i-eval for clarity, but I'm
sure that would affect existing users. I'll just have to keep the BSP
changes private and upstream what I can.

Thanks,
Kinsey

On Tue, Jul 25, 2023 at 8:27 AM Karel Gardas 
wrote:

> On 7/24/23 23:17, Kinsey Moore wrote:
>
> [...]
>
> > There is no other UART1 connector provided on the board. So I do not
> > see
> > reason why you add all other UARTs into #ifdefs for this particular
> > board/bsp variant? And hence my question about your motivation and
> > where
> > you are heading...
> >
> >
> > Given that, I now understand the confusion. I have a board in hand that
> > will never see an upstream BSP and I was hoping to be able to configure
> > the base STM32H7 BSP for it, but what I interpreted as the "base"
> > STM32H7 BSP is not actually a generic base BSP. I was also contemplating
> > moving more of the peripheral configuration into shared files since the
> > enable/disable configuration items are already there and it would be
> > convenient for the various BSPs to exist as some custom code and then a
> > selection of presets for those configuration items. I'll have to think
> > about the best way forward for the project I'm working with.
>
> I guess the philosophy in stm32h7 is to avoid cpp directives even in
> case of a bit more code duplication.
>
> So if I may ask, just copy board directory structure, name it after your
> board and tweak the copied files there. No need to #ifdefing in
> different board which would not use that.
>
> And btw, I'm using the same for Precidata SL-3011 (board on market, but
> BSP and firmware not ready for RTEMS 6, will be submitted for RTEMS 7
> probably) and for Arduino Portenta H7 (ditto but even less mature
> codewise).
>
> Thanks!
> Karel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/arm: fix nested extern decl. warnings brought by CMSIS files update

[Sebastian Huber]

On 21.07.23 17:37, Karel Gardas wrote:

---
  bsps/arm/include/cmsis_gcc.h | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/bsps/arm/include/cmsis_gcc.h b/bsps/arm/include/cmsis_gcc.h
index 4f0762d6dc..9e867348d2 100644
--- a/bsps/arm/include/cmsis_gcc.h
+++ b/bsps/arm/include/cmsis_gcc.h
@@ -30,7 +30,9 @@
  #pragma GCC diagnostic ignored "-Wsign-conversion"
  #pragma GCC diagnostic ignored "-Wconversion"
  #pragma GCC diagnostic ignored "-Wunused-parameter"
-
+#ifdef __rtems__
+#pragma GCC diagnostic ignored "-Wnested-externs"
+#endif /* __rtems__ */
  /* Fallback for __has_builtin */
  #ifndef __has_builtin
#define __has_builtin(x) (0)


I would disable this warning only in __cmsis_start() with a push/pop pragma.

I think you have to add also a

 * Modifications Copyright (C) Karel Gardas

if you change the file, see also:

https://softwareengineering.stackexchange.com/questions/220068/file-with-apache-2-0-and-my-modifications

In general, some advice for dealing with Apache 2.0 files in the RTEMS 
Software Engineering manual would be nice.


--
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 v1 2/2] bsps/stm32h7: Configure UART clocks when enabled

[Karel Gardas]

On 7/24/23 23:17, Kinsey Moore wrote:

[...]


There is no other UART1 connector provided on the board. So I do not
see
reason why you add all other UARTs into #ifdefs for this particular
board/bsp variant? And hence my question about your motivation and
where
you are heading...


Given that, I now understand the confusion. I have a board in hand that 
will never see an upstream BSP and I was hoping to be able to configure 
the base STM32H7 BSP for it, but what I interpreted as the "base" 
STM32H7 BSP is not actually a generic base BSP. I was also contemplating 
moving more of the peripheral configuration into shared files since the 
enable/disable configuration items are already there and it would be 
convenient for the various BSPs to exist as some custom code and then a 
selection of presets for those configuration items. I'll have to think 
about the best way forward for the project I'm working with.


I guess the philosophy in stm32h7 is to avoid cpp directives even in 
case of a bit more code duplication.


So if I may ask, just copy board directory structure, name it after your 
board and tweak the copied files there. No need to #ifdefing in 
different board which would not use that.


And btw, I'm using the same for Precidata SL-3011 (board on market, but 
BSP and firmware not ready for RTEMS 6, will be submitted for RTEMS 7 
probably) and for Arduino Portenta H7 (ditto but even less mature codewise).


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

Re: [PATCH] bsps/arm: fix installation broken by recent CMSIS files update

[Karel Gardas]

Hello Christian,

the patch fixing warnings is already submitted for review.

https://lists.rtems.org/pipermail/devel/2023-July/075881.html

Thanks,
Karel

On 7/25/23 12:07, Christian MAUDERER wrote:

Hello Karel,

I tested with the patch from Chris (which is identical to yours) and I 
have no problems building and installing the imx7, imxrt1052 and 
imxrt1166-cm7-saltshaker BSP and libbsd from master for these BSPs.


The only point that I have noted are a lot of new warnings when building 
the BSP. Example:


../../../../../rtems-sources/rtems/bsps/arm/include/cmsis_gcc.h:139:15: 
warning: nested extern declaration of '_start' [-Wnested-externs]

   139 |   extern void _start(void) __NO_RETURN;

Best regards

Christian

On 2023-07-25 08:55, Karel Gardas wrote:


Sure! Not a problem, I was just waiting for Christian to confirm its 
also working on his side.


Thanks,
Karel

On 7/25/23 03:34, Chris Johns wrote:

Hi Karel,

I did not see this and made and pushed a similar patch. Thanks for 
this and

sorry for not checking closely as I missed it on the first pass.

Thanks
Chris

On 25/7/2023 1:53 am, Karel Gardas wrote:

---
  spec/build/bsps/arm/grp.yml | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/spec/build/bsps/arm/grp.yml b/spec/build/bsps/arm/grp.yml
index 1058f58d92..a48cd80d74 100644
--- a/spec/build/bsps/arm/grp.yml
+++ b/spec/build/bsps/arm/grp.yml
@@ -10,12 +10,13 @@ includes: []
  install:
  - destination: ${BSP_INCLUDEDIR}
    source:
+  - bsps/arm/include/cachel1_armv7.h
+  - bsps/arm/include/cmsis_compiler.h
    - bsps/arm/include/cmsis_gcc.h
+  - bsps/arm/include/cmsis_version.h
    - bsps/arm/include/core_cm7.h
    - bsps/arm/include/core_cm4.h
-  - bsps/arm/include/core_cmFunc.h
-  - bsps/arm/include/core_cmInstr.h
-  - bsps/arm/include/core_cmSimd.h
+  - bsps/arm/include/mpu_armv7.h
    - bsps/arm/include/uart.h
  - destination: ${BSP_INCLUDEDIR}/bsp
    source:


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




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

[PATCH] score: Move formatted I/O functions

[Sebastian Huber]

These functions do not belong to an super core service.
---
 cpukit/{score/src => dev}/iobase64.c  |   4 +-
 cpukit/{score/src => dev}/ioprintf.c  |   4 +-
 cpukit/{score/src => dev}/iovprintf.c |   4 +-
 cpukit/include/rtems/dev/io.h | 119 ++-
 cpukit/include/rtems/score/gcov.h |   2 +-
 cpukit/include/rtems/score/io.h   | 142 --
 cpukit/libcsupport/src/vprintk.c  |   2 +-
 cpukit/libtest/t-test-hash-sha256.c   |   2 +-
 cpukit/libtest/t-test.c   |   2 +-
 cpukit/libtrace/record/record-dump-base64.c   |   2 +-
 cpukit/libtrace/record/record-dump-zbase64.c  |   2 +-
 .../aarch64/aarch64-exception-frame-print.c   |   2 +-
 cpukit/score/src/hash.c   |   2 +-
 spec/build/cpukit/librtemscpu.yml |   7 +-
 testsuites/sptests/spprintk/init.c|   2 +-
 testsuites/validation/tc-task-delete.c|   2 +-
 testsuites/validation/tc-terminate.c  |   2 +-
 17 files changed, 138 insertions(+), 164 deletions(-)
 rename cpukit/{score/src => dev}/iobase64.c (98%)
 rename cpukit/{score/src => dev}/ioprintf.c (97%)
 rename cpukit/{score/src => dev}/iovprintf.c (99%)
 delete mode 100644 cpukit/include/rtems/score/io.h

diff --git a/cpukit/score/src/iobase64.c b/cpukit/dev/iobase64.c
similarity index 98%
rename from cpukit/score/src/iobase64.c
rename to cpukit/dev/iobase64.c
index 27b977c8a0..0ac70d3ddb 100644
--- a/cpukit/score/src/iobase64.c
+++ b/cpukit/dev/iobase64.c
@@ -3,7 +3,7 @@
 /**
  * @file
  *
- * @ingroup RTEMSScoreIO
+ * @ingroup RTEMSDeviceIO
  *
  * @brief This source file contains the implementation of
  *   _IO_Base64() and _IO_Base64url().
@@ -27,7 +27,7 @@
  * PERFORMANCE OF THIS SOFTWARE.
  */
 
-#include 
+#include 
 
 static void
 _IO_Put(int c, void *arg, IO_Put_char put_char)
diff --git a/cpukit/score/src/ioprintf.c b/cpukit/dev/ioprintf.c
similarity index 97%
rename from cpukit/score/src/ioprintf.c
rename to cpukit/dev/ioprintf.c
index 8ae4213ab1..1f16389b47 100644
--- a/cpukit/score/src/ioprintf.c
+++ b/cpukit/dev/ioprintf.c
@@ -3,7 +3,7 @@
 /**
  * @file
  *
- * @ingroup RTEMSScoreIO
+ * @ingroup RTEMSDeviceIO
  *
  * @brief This source file contains the implementation of
  *   _IO_Printf().
@@ -38,7 +38,7 @@
 #include "config.h"
 #endif
 
-#include 
+#include 
 
 int _IO_Printf( IO_Put_char put_char, void *arg, char const  *fmt, ... )
 {
diff --git a/cpukit/score/src/iovprintf.c b/cpukit/dev/iovprintf.c
similarity index 99%
rename from cpukit/score/src/iovprintf.c
rename to cpukit/dev/iovprintf.c
index 0e8eb0b47b..99b11b691d 100644
--- a/cpukit/score/src/iovprintf.c
+++ b/cpukit/dev/iovprintf.c
@@ -1,7 +1,7 @@
 /**
  * @file
  *
- * @ingroup RTEMSScoreIO
+ * @ingroup RTEMSDeviceIO
  *
  * @brief This source file contains the implementation of
  *   _IO_Vprintf().
@@ -45,7 +45,7 @@
  * @(#)subr_prf.c  8.3 (Berkeley) 1/21/94
  */
 
-#include 
+#include 
 
 #include 
 __FBSDID("$FreeBSD: head/sys/kern/subr_prf.c 336417 2018-07-17 14:56:54Z markj 
$");
diff --git a/cpukit/include/rtems/dev/io.h b/cpukit/include/rtems/dev/io.h
index 4d041bcafc..93f384a551 100644
--- a/cpukit/include/rtems/dev/io.h
+++ b/cpukit/include/rtems/dev/io.h
@@ -10,7 +10,7 @@
  */
 
 /*
- * Copyright (C) 2021 embedded brains GmbH & Co. KG
+ * Copyright (C) 2017, 2023 embedded brains GmbH & Co. KG
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -37,6 +37,10 @@
 #ifndef _RTEMS_DEV_IO_H
 #define _RTEMS_DEV_IO_H
 
+#include 
+
+#include 
+
 #ifdef __cplusplus
 extern "C" {
 #endif /* __cplusplus */
@@ -51,6 +55,119 @@ extern "C" {
  * @{
  */
 
+/**
+ * @brief This type defines the put character handler.
+ *
+ * @param c is the character to put.
+ *
+ * @param arg is the user-provided argument.
+ */
+typedef void ( *IO_Put_char )( int c, void *arg );
+
+/**
+ * @brief Prints characters using the put character handler according to the
+ *   format string.
+ *
+ * @param put_char is the put character handler.
+ *
+ * @param arg is the user-provided argument for the put character handler.
+ *
+ * @param fmt is the printf()-style format string.
+ *
+ * @param ... is the list of parameters required by the format string.
+ *
+ * @return Returns the count of put characters.
+ */
+int _IO_Printf(
+  IO_Put_char  put_char,
+  void*arg,
+  char const  *fmt,
+  ...
+) RTEMS_PRINTFLIKE( 3, 4 );
+
+/**
+ * @brief Prints characters using the put character handler according to the
+ *   format string.
+ *
+ * @param put_char is the put character handler.
+ *
+ * @param arg is the user-provided argument for the put character handler.
+ *
+ * @param fmt is the printf()-style format string.
+ *
+ * @param ap is the argument list required by the format string.
+ *
+ * @return Returns the count of put characters.
+ */
+int _IO_Vprintf(
+  IO_Put_char  

[PATCH] build: Export BSP base and family via pkg-config

[Sebastian Huber]

This allows application and library build systems to derive option
values from the BSP base and family names.
---
 spec/build/bsps/pkgconfig.yml | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/spec/build/bsps/pkgconfig.yml b/spec/build/bsps/pkgconfig.yml
index e08c83fe27..afaffbbf0f 100644
--- a/spec/build/bsps/pkgconfig.yml
+++ b/spec/build/bsps/pkgconfig.yml
@@ -15,6 +15,8 @@ content: |
   ABI_FLAGS=${ABI_FLAGS}
   RTEMS_ARCH=${ARCH}
   RTEMS_BSP=${BSP_NAME}
+  RTEMS_BSP_BASE=${BSP_BASE}
+  RTEMS_BSP_FAMILY=${BSP_FAMILY}
   RTEMS_MAJOR=${__RTEMS_MAJOR__}
   RTEMS_MINOR=${__RTEMS_MINOR__}
   RTEMS_REVISION=${__RTEMS_REVISION__}
-- 
2.35.3

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

Re: [PATCH] bsps/arm: fix installation broken by recent CMSIS files update

[Christian MAUDERER]

Hello Karel,

I tested with the patch from Chris (which is identical to yours) and I 
have no problems building and installing the imx7, imxrt1052 and 
imxrt1166-cm7-saltshaker BSP and libbsd from master for these BSPs.


The only point that I have noted are a lot of new warnings when building 
the BSP. Example:


../../../../../rtems-sources/rtems/bsps/arm/include/cmsis_gcc.h:139:15: 
warning: nested extern declaration of '_start' [-Wnested-externs] 


  139 |   extern void _start(void) __NO_RETURN;

Best regards

Christian

On 2023-07-25 08:55, Karel Gardas wrote:


Sure! Not a problem, I was just waiting for Christian to confirm its 
also working on his side.


Thanks,
Karel

On 7/25/23 03:34, Chris Johns wrote:

Hi Karel,

I did not see this and made and pushed a similar patch. Thanks for 
this and

sorry for not checking closely as I missed it on the first pass.

Thanks
Chris

On 25/7/2023 1:53 am, Karel Gardas wrote:

---
  spec/build/bsps/arm/grp.yml | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/spec/build/bsps/arm/grp.yml b/spec/build/bsps/arm/grp.yml
index 1058f58d92..a48cd80d74 100644
--- a/spec/build/bsps/arm/grp.yml
+++ b/spec/build/bsps/arm/grp.yml
@@ -10,12 +10,13 @@ includes: []
  install:
  - destination: ${BSP_INCLUDEDIR}
    source:
+  - bsps/arm/include/cachel1_armv7.h
+  - bsps/arm/include/cmsis_compiler.h
    - bsps/arm/include/cmsis_gcc.h
+  - bsps/arm/include/cmsis_version.h
    - bsps/arm/include/core_cm7.h
    - bsps/arm/include/core_cm4.h
-  - bsps/arm/include/core_cmFunc.h
-  - bsps/arm/include/core_cmInstr.h
-  - bsps/arm/include/core_cmSimd.h
+  - bsps/arm/include/mpu_armv7.h
    - bsps/arm/include/uart.h
  - destination: ${BSP_INCLUDEDIR}/bsp
    source:


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


--

embedded brains GmbH & Co. KG
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: HRA 117265
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Outdated list of BSPs in rtems-tools/config

[Christian MAUDERER]

Hello,

I noted that some BSPs are missing in the config files in the 
rtems-tools repo. If I didn't miss one it's:


- aarch64, raspberrypi4b
- aarch64, xilinx_zynqmp_lp64_cfc400x
- arm, imxrt1166-cm7-saltshaker
- arm, stm32h750b-dk
- powerpc, mvme2700
- powerpc, phycore_mpc5554
- riscv, kendrytek210
- x86_64, amd64efi

One of the BSPs is from me. I don't know of the other ones.

I noted the configuration files in that repo just now more or less by 
chance when playing around with rtems-bsp-builder. I wasn't aware that 
we have a second list beneath the one printed by the `rtems-bsps` script 
or `waf bsp-list` in the RTEMS repo.


Did I miss that I should have updated rtems-tools (and with that the 
rtems-source-builder) every time I have added a BSP in the past? Or 
would it only make problems if I would update these files manually 
because they are usually created by some script during the release process?


Best regards

Christian
--

embedded brains GmbH & Co. KG
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: HRA 117265
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 8/8] sys: Add files to Doxygen group

[Sebastian Huber]

Canonicalize brief descriptions.

Update #3707.
---
 cpukit/doxygen/top-level-groups.h | 8 
 cpukit/include/sys/endian.h   | 9 +
 cpukit/include/sys/priority.h | 8 
 cpukit/include/sys/statvfs.h  | 7 ---
 4 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/cpukit/doxygen/top-level-groups.h 
b/cpukit/doxygen/top-level-groups.h
index fd32db347a..9d34b3e3dd 100644
--- a/cpukit/doxygen/top-level-groups.h
+++ b/cpukit/doxygen/top-level-groups.h
@@ -40,6 +40,14 @@
  *   RTEMS.
  */
 
+/**
+ * @defgroup RTEMSAPISystemLibrary System Library
+ *
+ * @ingroup RTEMSAPI
+ *
+ * @brief This group contains the system library APIs of RTEMS.
+ */
+
 /**
  * @defgroup RTEMSDeviceDrivers Device Drivers
  *
diff --git a/cpukit/include/sys/endian.h b/cpukit/include/sys/endian.h
index 0849a6a90b..cdd6201736 100644
--- a/cpukit/include/sys/endian.h
+++ b/cpukit/include/sys/endian.h
@@ -1,3 +1,12 @@
+/**
+ * @file
+ *
+ * @ingroup RTEMSAPISystemLibrary
+ *
+ * @brief This header file provides interfaces of the system endianness
+ *   support.
+ */
+
 /*-
  * Copyright (c) 2002 Thomas Moestl 
  * All rights reserved.
diff --git a/cpukit/include/sys/priority.h b/cpukit/include/sys/priority.h
index 855edb63c2..37d0d938dc 100644
--- a/cpukit/include/sys/priority.h
+++ b/cpukit/include/sys/priority.h
@@ -1,3 +1,11 @@
+/**
+ * @file
+ *
+ * @ingroup RTEMSAPISystemLibrary
+ *
+ * @brief This header file provides interfaces of the process priority support.
+ */
+
 /*-
  * SPDX-License-Identifier: BSD-4-Clause
  *
diff --git a/cpukit/include/sys/statvfs.h b/cpukit/include/sys/statvfs.h
index 52d8e9d3fa..655f9a596c 100644
--- a/cpukit/include/sys/statvfs.h
+++ b/cpukit/include/sys/statvfs.h
@@ -3,10 +3,11 @@
 /**
  * @file
  *
- * @brief Interface to the statvfs() Set of API Methods
+ * @ingroup RTEMSAPISystemLibrary
  *
- * This include file defines the interface to the statvfs() set of
- * API methods. The statvfs as defined by the SUS:
+ * @brief This header file provides the statvfs() and fstatvfs() interfaces.
+ *
+ * The statvfs() is defined by the SUS:
  *
  * - http://www.opengroup.org/onlinepubs/009695399/basedefs/sys/statvfs.h.html
  */
-- 
2.35.3

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

[PATCH 6/8] posix: Add files to Doxygen group

[Sebastian Huber]

Canonicalize brief descriptions.

Update #3707.
---
 cpukit/include/rtems/posix/posixapi.h | 6 +++---
 cpukit/include/rtems/posix/spinlockimpl.h | 8 
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/cpukit/include/rtems/posix/posixapi.h 
b/cpukit/include/rtems/posix/posixapi.h
index 24c1dc51e0..5d78573ef7 100644
--- a/cpukit/include/rtems/posix/posixapi.h
+++ b/cpukit/include/rtems/posix/posixapi.h
@@ -3,10 +3,10 @@
 /**
  * @file
  *
- * @brief POSIX API Implementation
+ * @ingroup POSIXAPI
  *
- * This include file defines the top level interface to the POSIX API
- * implementation in RTEMS.
+ * @brief This header file provides interfaces used by the POSIX API
+ *   implementation.
  */
 
 /*
diff --git a/cpukit/include/rtems/posix/spinlockimpl.h 
b/cpukit/include/rtems/posix/spinlockimpl.h
index 855e57cc14..10424f1961 100644
--- a/cpukit/include/rtems/posix/spinlockimpl.h
+++ b/cpukit/include/rtems/posix/spinlockimpl.h
@@ -2,11 +2,11 @@
 
 /**
  * @file
- * 
- * @brief Inlined Routines from the POSIX Spinlock Manager
  *
- * This file contains the static inlin implementation of the inlined
- * routines from the POSIX Spinlock Manager.
+ * @ingroup POSIXAPI
+ *
+ * @brief This header file provides interfaces used by the POSIX Spinlock
+ *   implementation.
  */
 
 /*
-- 
2.35.3

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

[PATCH 7/8] timecounter: Add files to Doxygen group

[Sebastian Huber]

Update #3707.
---
 cpukit/include/machine/_timecounter.h | 2 ++
 cpukit/include/sys/_ffcounter.h   | 9 +
 cpukit/include/sys/timeffc.h  | 9 +
 cpukit/include/sys/timepps.h  | 9 +
 cpukit/include/sys/timetc.h   | 9 +
 cpukit/include/sys/timex.h| 9 +
 6 files changed, 47 insertions(+)

diff --git a/cpukit/include/machine/_timecounter.h 
b/cpukit/include/machine/_timecounter.h
index 127e5f6fd3..e20e051f84 100644
--- a/cpukit/include/machine/_timecounter.h
+++ b/cpukit/include/machine/_timecounter.h
@@ -3,6 +3,8 @@
 /**
  * @file
  *
+ * @ingroup RTEMSScoreTimecounter
+ *
  * @brief This header file provides timecounter definitions for the kernel 
space
  *   (_KERNEL is defined before including ) and RTEMS.
  */
diff --git a/cpukit/include/sys/_ffcounter.h b/cpukit/include/sys/_ffcounter.h
index d83c48cd44..802c7d3224 100644
--- a/cpukit/include/sys/_ffcounter.h
+++ b/cpukit/include/sys/_ffcounter.h
@@ -1,3 +1,12 @@
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreTimecounter
+ *
+ * @brief This header file provides interfaces of the feed-forward clock
+ *   counter.
+ */
+
 /*-
  * Copyright (c) 2011 The University of Melbourne
  * All rights reserved.
diff --git a/cpukit/include/sys/timeffc.h b/cpukit/include/sys/timeffc.h
index c04de97f1d..13abd37a2b 100644
--- a/cpukit/include/sys/timeffc.h
+++ b/cpukit/include/sys/timeffc.h
@@ -1,3 +1,12 @@
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreTimecounter
+ *
+ * @brief This header file provides interfaces of the feed-back and
+ *   feed-forward clock implementations.
+ */
+
 /*-
  * Copyright (c) 2011 The University of Melbourne
  * All rights reserved.
diff --git a/cpukit/include/sys/timepps.h b/cpukit/include/sys/timepps.h
index 030c734477..502d93833e 100644
--- a/cpukit/include/sys/timepps.h
+++ b/cpukit/include/sys/timepps.h
@@ -1,3 +1,12 @@
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreTimecounter
+ *
+ * @brief This header file provides interfaces of the Pulse Per Second (PPS)
+ *   support.
+ */
+
 /*-
  * 
  * "THE BEER-WARE LICENSE" (Revision 42):
diff --git a/cpukit/include/sys/timetc.h b/cpukit/include/sys/timetc.h
index 1ef58b378d..8f2537692c 100644
--- a/cpukit/include/sys/timetc.h
+++ b/cpukit/include/sys/timetc.h
@@ -1,3 +1,12 @@
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreTimecounter
+ *
+ * @brief This header file provides interfaces of the timecounter
+ *   implementation.
+ */
+
 /*-
  * 
  * "THE BEER-WARE LICENSE" (Revision 42):
diff --git a/cpukit/include/sys/timex.h b/cpukit/include/sys/timex.h
index 8e763bb30f..36b1fcdb5a 100644
--- a/cpukit/include/sys/timex.h
+++ b/cpukit/include/sys/timex.h
@@ -1,3 +1,12 @@
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreTimecounter
+ *
+ * @brief This header file provides interfaces of the Network Time Protocol
+ *   (NTP) support.
+ */
+
 /*-
  ***
  **
-- 
2.35.3

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

[PATCH 4/8] score: Add files to Doxygen groups

[Sebastian Huber]

Update #3707.
---
 cpukit/score/cpu/no_cpu/cpuidle.c | 9 +
 cpukit/score/cpu/sparc/include/libcpu/grlib-tn-0018.h | 9 +
 cpukit/score/cpu/sparc/syscall.h  | 8 
 3 files changed, 26 insertions(+)

diff --git a/cpukit/score/cpu/no_cpu/cpuidle.c 
b/cpukit/score/cpu/no_cpu/cpuidle.c
index a6001e73b0..dbaf109905 100644
--- a/cpukit/score/cpu/no_cpu/cpuidle.c
+++ b/cpukit/score/cpu/no_cpu/cpuidle.c
@@ -1,5 +1,14 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreCPU
+ *
+ * @brief This source file contains the implementation of the
+ *   _CPU_Thread_Idle_body().
+ */
+
 /*
  * Copyright (C) 2013, 2014 embedded brains GmbH & Co. KG
  *
diff --git a/cpukit/score/cpu/sparc/include/libcpu/grlib-tn-0018.h 
b/cpukit/score/cpu/sparc/include/libcpu/grlib-tn-0018.h
index bb43234128..10f34c6123 100644
--- a/cpukit/score/cpu/sparc/include/libcpu/grlib-tn-0018.h
+++ b/cpukit/score/cpu/sparc/include/libcpu/grlib-tn-0018.h
@@ -1,5 +1,14 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreCPUSPARC
+ *
+ * @brief This header file provides interfaces of the GRLIB-TN-0018 LEON3FT
+ *   RETT Restart Errata fixes.
+ */
+
 /*
  * Copyright (C) 2020 Cobham Gaisler AB
  *
diff --git a/cpukit/score/cpu/sparc/syscall.h b/cpukit/score/cpu/sparc/syscall.h
index 2f20886840..6fc8fa3a6f 100644
--- a/cpukit/score/cpu/sparc/syscall.h
+++ b/cpukit/score/cpu/sparc/syscall.h
@@ -1 +1,9 @@
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreCPUSPARC
+ *
+ * @brief This header file provides system call interfaces.
+ */
+
 #define SYS_exit1
-- 
2.35.3

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

[PATCH 2/8] rtems: Add files to Doxygen groups

[Sebastian Huber]

Provide basic Doxygen comments.

Update #3706.
Update #3707.
---
 bsps/shared/rtems-version.c   |  9 +++
 cpukit/include/rtems/linkersets.h | 50 ---
 cpukit/include/rtems/sysinit.h| 91 ---
 cpukit/include/rtems/thread.h | 21 +++
 cpukit/sapi/src/cpucounterconverter.c |  9 +++
 cpukit/sapi/src/version.c |  2 +-
 6 files changed, 150 insertions(+), 32 deletions(-)

diff --git a/bsps/shared/rtems-version.c b/bsps/shared/rtems-version.c
index b12504a1c9..aaac5a07f3 100644
--- a/bsps/shared/rtems-version.c
+++ b/bsps/shared/rtems-version.c
@@ -1,3 +1,12 @@
+/**
+ * @file
+ *
+ * @ingroup RTEMSImplClassic
+ *
+ * @brief This source file contains the implementation of
+ *   rtems_board_support_package() and the definition of ::_RTEMS_version.
+ */
+
 /*
  *  COPYRIGHT (c) 2003, Ralf Corsepius, Ulm, Germany.
  *  COPYRIGHT (c) 2003, On-Line Applications Research Corporation (OAR).
diff --git a/cpukit/include/rtems/linkersets.h 
b/cpukit/include/rtems/linkersets.h
index ef1b0d38d4..a5d7b1b037 100644
--- a/cpukit/include/rtems/linkersets.h
+++ b/cpukit/include/rtems/linkersets.h
@@ -1,5 +1,13 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
+/**
+ * @file
+ *
+ * @ingroup RTEMSAPILinkerSets
+ *
+ * @brief This header file provides the linker sets API.
+ */
+
 /*
  * Copyright (C) 2015, 2020 embedded brains GmbH & Co. KG
  *
@@ -34,6 +42,36 @@
 extern "C" {
 #endif /* __cplusplus */
 
+/**
+ * @ingroup RTEMSImpl
+ *
+ * @brief Obfuscates a pointer to prevent compiler optimizations.
+ *
+ * @param ptr is the pointer to obfuscate.
+ *
+ * @return Returns the unsigned integer representation of the obfuscated
+ *   pointer.
+ */
+static inline uintptr_t _Linker_set_Obfuscate( const void *ptr )
+{
+  uintptr_t addr;
+
+  addr = (uintptr_t) ptr;
+  RTEMS_OBFUSCATE_VARIABLE( addr );
+
+  return addr;
+}
+
+/**
+ * @defgroup RTEMSAPILinkerSets Linker Sets
+ *
+ * @ingroup RTEMSAPI
+ *
+ * @brief This group contains the linker sets API.
+ *
+ * @{
+ */
+
 #define RTEMS_LINKER_SET_BEGIN( set ) \
   _Linker_set_##set##_begin
 
@@ -129,16 +167,6 @@ extern "C" {
   decl \
   RTEMS_SECTION( ".rtemsrwset." #set ".content" )
 
-static inline uintptr_t _Linker_set_Obfuscate( const void *ptr )
-{
-  uintptr_t addr;
-
-  addr = (uintptr_t) ptr;
-  RTEMS_OBFUSCATE_VARIABLE( addr );
-
-  return addr;
-}
-
 #define RTEMS_LINKER_SET_SIZE( set ) \
   ( _Linker_set_Obfuscate( RTEMS_LINKER_SET_END( set ) ) \
 - _Linker_set_Obfuscate( RTEMS_LINKER_SET_BEGIN( set ) ) )
@@ -157,6 +185,8 @@ static inline uintptr_t _Linker_set_Obfuscate( const void 
*ptr )
 ++item \
   )
 
+/** @} */
+
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
diff --git a/cpukit/include/rtems/sysinit.h b/cpukit/include/rtems/sysinit.h
index b973ecfc91..3e6f4d9933 100644
--- a/cpukit/include/rtems/sysinit.h
+++ b/cpukit/include/rtems/sysinit.h
@@ -1,7 +1,15 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
+/**
+ * @file
+ *
+ * @ingroup RTEMSAPISystemInit
+ *
+ * @brief This header file provides the API of the @ref RTEMSAPISystemInit.
+ */
+
 /*
- * Copyright (C) 2015, 2020 embedded brains GmbH & Co. KG
+ * Copyright (C) 2015, 2023 embedded brains GmbH & Co. KG
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
@@ -34,6 +42,54 @@
 extern "C" {
 #endif /* __cplusplus */
 
+/**
+ * @ingroup RTEMSImpl
+ *
+ * @brief Enables a verbose system initialization.
+ */
+void _Sysinit_Verbose( void );
+
+/**
+ * @ingroup RTEMSImpl
+ *
+ * @brief Creates the system initialization item associated with the handler
+ *   and index.
+ *
+ * The enum helps to detect typos in the module and order parameters of
+ * RTEMS_SYSINIT_ITEM().
+ */
+#define _RTEMS_SYSINIT_INDEX_ITEM( handler, index ) \
+  enum { _Sysinit_##handler = index }; \
+  RTEMS_LINKER_ROSET_ITEM_ORDERED( \
+_Sysinit, \
+rtems_sysinit_item, \
+handler, \
+index \
+  ) = { handler }
+
+/**
+ * @ingroup RTEMSImpl
+ *
+ * @brief Creates the system initialization item associated with the handler,
+ *   module, and order.
+ *
+ * This helper macro is used to perform parameter expansion in
+ * RTEMS_SYSINIT_ITEM().
+ */
+#define _RTEMS_SYSINIT_ITEM( handler, module, order ) \
+  _RTEMS_SYSINIT_INDEX_ITEM( handler, 0x##module##order )
+
+/**
+ * @defgroup RTEMSAPISystemInit System Initialization Support
+ *
+ * @ingroup RTEMSAPI
+ *
+ * @brief The system initialization support provides an ordered invocation of
+ *   system initialization handlers registered in a linker set.
+ *
+ * @{
+ */
+
 /*
  * The value of each module define must consist of exactly six hexadecimal
  * digits without a 0x-prefix.  A 0x-prefix is concatenated with the module and
@@ -133,29 +189,22 @@ typedef struct {
   rtems_sysinit_handler handler;
 } rtems_sysinit_item;
 
-/* The enum helps to detect typos in the module and order parameters */
-#define 

[PATCH 3/8] bsps/sparc: Add files to Doxygen groups

[Sebastian Huber]

From: Frank Kühndel 

Update #3707.
---
 bsps/sparc/include/bsp/gnatcommon.h| 15 +++
 bsps/sparc/include/bsp/gr_leon4_n2x.h  | 10 +-
 bsps/sparc/include/drvmgr/leon2_amba_bus.h | 10 +-
 bsps/sparc/leon3/clock/ckinit.c| 13 +++--
 bsps/sparc/leon3/console/printk_support.c  | 11 ---
 bsps/sparc/leon3/start/bspstart.c  | 14 +-
 bsps/sparc/leon3/start/cache.c |  8 
 bsps/sparc/leon3/start/cpucounter.c|  8 
 bsps/sparc/leon3/start/eirq.c  | 11 +--
 bsps/sparc/shared/irq/bsp_isr_handler.c|  9 +
 10 files changed, 91 insertions(+), 18 deletions(-)

diff --git a/bsps/sparc/include/bsp/gnatcommon.h 
b/bsps/sparc/include/bsp/gnatcommon.h
index 1a04449293..40e8829bb9 100644
--- a/bsps/sparc/include/bsp/gnatcommon.h
+++ b/bsps/sparc/include/bsp/gnatcommon.h
@@ -1,3 +1,18 @@
+/**
+ * @file
+ *
+ * @ingroup RTEMSImplGnat
+ *
+ * @brief This header file provides interfaces of the
+ *   gnat/rtems interrupts and exception handling.
+ */
+
+/**
+ * @defgroup RTEMSImplGnat GNAT/RTEMS interrupts and exception handling
+ *
+ * @ingroup RTEMSImpl
+ */
+
 #ifndef __GNATCOMMON_H
 #define __GNATCOMMON_H
 
diff --git a/bsps/sparc/include/bsp/gr_leon4_n2x.h 
b/bsps/sparc/include/bsp/gr_leon4_n2x.h
index 79ea53f953..97ca6d5dfb 100644
--- a/bsps/sparc/include/bsp/gr_leon4_n2x.h
+++ b/bsps/sparc/include/bsp/gr_leon4_n2x.h
@@ -1,7 +1,15 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
-/*  GR-CPCI-LEON4-N2X (NGFP) PCI Peripheral driver
+/**
+ * @file
  *
+ * @ingroup RTEMSBSPsSPARCLEON3
+ *
+ * @brief This header file provides interfaces of the
+ *   GR-CPCI-LEON4-N2X (NGFP) PCI Peripheral driver.
+ */
+
+/*
  *  COPYRIGHT (c) 2013.
  *  Cobham Gaisler AB.
  *
diff --git a/bsps/sparc/include/drvmgr/leon2_amba_bus.h 
b/bsps/sparc/include/drvmgr/leon2_amba_bus.h
index 93e05442af..0dea2a9426 100644
--- a/bsps/sparc/include/drvmgr/leon2_amba_bus.h
+++ b/bsps/sparc/include/drvmgr/leon2_amba_bus.h
@@ -1,7 +1,15 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
-/*  LEON2 Hardcoded bus driver interface.
+/**
+ * @file
  *
+ * @ingroup RTEMSBSPsSPARCLEON2
+ *
+ * @brief This header file provides interfaces of the
+ *   LEON2 Hardcoded bus driver.
+ */
+
+/*
  *  COPYRIGHT (c) 2008.
  *  Cobham Gaisler AB.
  *
diff --git a/bsps/sparc/leon3/clock/ckinit.c b/bsps/sparc/leon3/clock/ckinit.c
index 60ef5d3ab6..c335652a56 100644
--- a/bsps/sparc/leon3/clock/ckinit.c
+++ b/bsps/sparc/leon3/clock/ckinit.c
@@ -1,13 +1,14 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
-/*
- *  Clock Tick Device Driver
- *
- *  This routine initializes LEON timer 1 which used for the clock tick.
+/**
+ * @file
  *
- *  The tick frequency is directly programmed to the configured number of
- *  microseconds per tick.
+ * @ingroup RTEMSBSPsSPARCLEON3
  *
+ * @brief This source file contains the Clock Driver implementation.
+ */
+
+/*
  *  COPYRIGHT (c) 1989-2006.
  *  On-Line Applications Research Corporation (OAR).
  *
diff --git a/bsps/sparc/leon3/console/printk_support.c 
b/bsps/sparc/leon3/console/printk_support.c
index 9e260d2eac..fd23a5033f 100644
--- a/bsps/sparc/leon3/console/printk_support.c
+++ b/bsps/sparc/leon3/console/printk_support.c
@@ -1,10 +1,15 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
-/*
- *  This file contains the TTY driver for the serial ports on the LEON.
+/**
+ * @file
  *
- *  This driver uses the termios pseudo driver.
+ * @ingroup RTEMSBSPsSPARCLEON3
  *
+ * @brief This source file contains the definition of ::BSP_output_char and
+ *   ::BSP_poll_char.
+ */
+
+/*
  *  COPYRIGHT (c) 1989-1999.
  *  On-Line Applications Research Corporation (OAR).
  *
diff --git a/bsps/sparc/leon3/start/bspstart.c 
b/bsps/sparc/leon3/start/bspstart.c
index dec92320e1..2c3844f78d 100644
--- a/bsps/sparc/leon3/start/bspstart.c
+++ b/bsps/sparc/leon3/start/bspstart.c
@@ -1,11 +1,15 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
-/*
- *  This set of routines starts the application.  It includes application,
- *  board, and monitor specific initialization and configuration.
- *  The generic CPU dependent initialization has been performed
- *  before any of these are invoked.
+/**
+ * @file
+ *
+ * @ingroup RTEMSBSPsSPARCLEON3
  *
+ * @brief This source file contains the implementation of bsp_start() and
+ *   definitions of BSP-specific objects.
+ */
+
+/*
  *  COPYRIGHT (c) 2011
  *  Aeroflex Gaisler
  *
diff --git a/bsps/sparc/leon3/start/cache.c b/bsps/sparc/leon3/start/cache.c
index 5049b7f81c..11af2f4d01 100644
--- a/bsps/sparc/leon3/start/cache.c
+++ b/bsps/sparc/leon3/start/cache.c
@@ -1,3 +1,11 @@
+/**
+ * @file
+ *
+ * @ingroup RTEMSBSPsSPARCLEON3
+ *
+ * @brief This source file contains the implementation of the Cache Manager.
+ */
+
 /*
  * Copyright (c) 2014 embedded brains GmbH & Co. KG
  *
diff --git a/bsps/sparc/leon3/start/cpucounter.c 
b/bsps/sparc/leon3/start/cpucounter.c
index 

[PATCH 0/8] Add files to Doxygen groups

[Sebastian Huber]

Frank Kühndel (1):
  bsps/sparc: Add files to Doxygen groups

Sebastian Huber (7):
  libtest: Place files into a Doxygen group
  rtems: Add files to Doxygen groups
  score: Add files to Doxygen groups
  libcsupport: Add file to Doxygen group
  posix: Add files to Doxygen group
  timecounter: Add files to Doxygen group
  sys: Add files to Doxygen group

 bsps/shared/rtems-version.c   |  9 ++
 bsps/sparc/include/bsp/gnatcommon.h   | 15 +++
 bsps/sparc/include/bsp/gr_leon4_n2x.h | 10 +-
 bsps/sparc/include/drvmgr/leon2_amba_bus.h| 10 +-
 bsps/sparc/leon3/clock/ckinit.c   | 13 +--
 bsps/sparc/leon3/console/printk_support.c | 11 ++-
 bsps/sparc/leon3/start/bspstart.c | 14 ++-
 bsps/sparc/leon3/start/cache.c|  8 ++
 bsps/sparc/leon3/start/cpucounter.c   |  8 ++
 bsps/sparc/leon3/start/eirq.c | 11 ++-
 bsps/sparc/shared/irq/bsp_isr_handler.c   |  9 ++
 cpukit/doxygen/top-level-groups.h |  8 ++
 cpukit/include/machine/_timecounter.h |  2 +
 cpukit/include/rtems/linkersets.h | 50 --
 cpukit/include/rtems/posix/posixapi.h |  6 +-
 cpukit/include/rtems/posix/spinlockimpl.h |  8 +-
 cpukit/include/rtems/sysinit.h| 91 ++-
 cpukit/include/rtems/test-info.h  |  9 ++
 cpukit/include/rtems/test.h   | 13 ++-
 cpukit/include/rtems/thread.h | 21 +
 cpukit/include/sys/_ffcounter.h   |  9 ++
 cpukit/include/sys/endian.h   |  9 ++
 cpukit/include/sys/priority.h |  8 ++
 cpukit/include/sys/statvfs.h  |  7 +-
 cpukit/include/sys/timeffc.h  |  9 ++
 cpukit/include/sys/timepps.h  |  9 ++
 cpukit/include/sys/timetc.h   |  9 ++
 cpukit/include/sys/timex.h|  9 ++
 cpukit/libcsupport/src/malloc_p.h | 11 ++-
 cpukit/libtest/t-test-busy-tick.c |  3 +-
 cpukit/libtest/t-test-busy.c  |  3 +-
 cpukit/libtest/t-test-checks-eno.c| 13 ++-
 cpukit/libtest/t-test-checks-psx.c|  5 +-
 cpukit/libtest/t-test-checks.c| 13 ++-
 cpukit/libtest/t-test-hash-sha256.c   | 13 ++-
 cpukit/libtest/t-test-interrupt.c |  3 +-
 cpukit/libtest/t-test-rtems-context.c | 13 ++-
 cpukit/libtest/t-test-rtems-fds.c | 13 ++-
 cpukit/libtest/t-test-rtems-heap.c| 13 ++-
 cpukit/libtest/t-test-rtems-measure.c | 13 ++-
 cpukit/libtest/t-test-rtems-memory.c  |  9 ++
 cpukit/libtest/t-test-rtems-objs.c|  5 +-
 cpukit/libtest/t-test-rtems-posix-keys.c  |  5 +-
 cpukit/libtest/t-test-rtems.c | 13 ++-
 cpukit/libtest/t-test-rtems.h |  5 +-
 cpukit/libtest/t-test-thread-switch.c |  3 +-
 cpukit/libtest/t-test-time.c  | 13 ++-
 cpukit/libtest/t-test.c   | 13 ++-
 cpukit/libtest/testbeginend.c |  9 ++
 cpukit/sapi/src/cpucounterconverter.c |  9 ++
 cpukit/sapi/src/version.c |  2 +-
 cpukit/score/cpu/no_cpu/cpuidle.c |  9 ++
 .../cpu/sparc/include/libcpu/grlib-tn-0018.h  |  9 ++
 cpukit/score/cpu/sparc/syscall.h  |  8 ++
 54 files changed, 528 insertions(+), 95 deletions(-)

-- 
2.35.3

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

[PATCH 5/8] libcsupport: Add file to Doxygen group

[Sebastian Huber]

Update #3707.
---
 cpukit/libcsupport/src/malloc_p.h | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/cpukit/libcsupport/src/malloc_p.h 
b/cpukit/libcsupport/src/malloc_p.h
index ac25cd31d1..115198cb40 100644
--- a/cpukit/libcsupport/src/malloc_p.h
+++ b/cpukit/libcsupport/src/malloc_p.h
@@ -1,8 +1,15 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
-/*
- *  RTEMS Malloc Family Internal Header
+/**
+ * @file
+ *
+ * @ingroup libcsupport
  *
+ * @brief This header file provides interfaces used by the memory allocator
+ *   implementation.
+ */
+
+/*
  *  COPYRIGHT (c) 1989-2007.
  *  On-Line Applications Research Corporation (OAR).
  *
-- 
2.35.3

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

[PATCH 1/8] libtest: Place files into a Doxygen group

[Sebastian Huber]

Canonicalize the file headers.

Update #3707.
---
 cpukit/include/rtems/test-info.h |  9 +
 cpukit/include/rtems/test.h  | 13 +++--
 cpukit/libtest/t-test-busy-tick.c|  3 ++-
 cpukit/libtest/t-test-busy.c |  3 ++-
 cpukit/libtest/t-test-checks-eno.c   | 13 +++--
 cpukit/libtest/t-test-checks-psx.c   |  5 -
 cpukit/libtest/t-test-checks.c   | 13 +++--
 cpukit/libtest/t-test-hash-sha256.c  | 13 +++--
 cpukit/libtest/t-test-interrupt.c|  3 ++-
 cpukit/libtest/t-test-rtems-context.c| 13 +++--
 cpukit/libtest/t-test-rtems-fds.c| 13 +++--
 cpukit/libtest/t-test-rtems-heap.c   | 13 +++--
 cpukit/libtest/t-test-rtems-measure.c| 13 +++--
 cpukit/libtest/t-test-rtems-memory.c |  9 +
 cpukit/libtest/t-test-rtems-objs.c   |  5 +++--
 cpukit/libtest/t-test-rtems-posix-keys.c |  5 +++--
 cpukit/libtest/t-test-rtems.c| 13 +++--
 cpukit/libtest/t-test-rtems.h|  5 +++--
 cpukit/libtest/t-test-thread-switch.c|  3 ++-
 cpukit/libtest/t-test-time.c | 13 +++--
 cpukit/libtest/t-test.c  | 13 +++--
 cpukit/libtest/testbeginend.c|  9 +
 22 files changed, 169 insertions(+), 33 deletions(-)

diff --git a/cpukit/include/rtems/test-info.h b/cpukit/include/rtems/test-info.h
index 055ed4f25b..c1b41ccc6e 100644
--- a/cpukit/include/rtems/test-info.h
+++ b/cpukit/include/rtems/test-info.h
@@ -1,5 +1,14 @@
 /* SPDX-License-Identifier: BSD-2-Clause */
 
+/**
+ * @file
+ *
+ * @ingroup RTEMSTestFramework
+ *
+ * @brief This header file provides interfaces of the
+ *   RTEMS Test Framework.
+ */
+
 /*
  * Copyright (C) 2014, 2018 embedded brains GmbH & Co. KG
  *
diff --git a/cpukit/include/rtems/test.h b/cpukit/include/rtems/test.h
index 79313343a0..04eebd6e75 100644
--- a/cpukit/include/rtems/test.h
+++ b/cpukit/include/rtems/test.h
@@ -1,6 +1,15 @@
-/*
- * SPDX-License-Identifier: BSD-2-Clause
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSTestFramework
  *
+ * @brief This header file provides interfaces of the
+ *   RTEMS Test Framework.
+ */
+
+/*
  * Copyright (C) 2017, 2021 embedded brains GmbH & Co. KG
  *
  * Redistribution and use in source and binary forms, with or without
diff --git a/cpukit/libtest/t-test-busy-tick.c 
b/cpukit/libtest/t-test-busy-tick.c
index b7fed247fa..5e45757f24 100644
--- a/cpukit/libtest/t-test-busy-tick.c
+++ b/cpukit/libtest/t-test-busy-tick.c
@@ -5,7 +5,8 @@
  *
  * @ingroup RTEMSTestFrameworkImpl
  *
- * @brief Implementation of T_get_one_clock_tick_busy().
+ * @brief This source file contains the implementation of
+ *   T_get_one_clock_tick_busy().
  */
 
 /*
diff --git a/cpukit/libtest/t-test-busy.c b/cpukit/libtest/t-test-busy.c
index 8583284087..e28fa3e5e4 100644
--- a/cpukit/libtest/t-test-busy.c
+++ b/cpukit/libtest/t-test-busy.c
@@ -5,7 +5,8 @@
  *
  * @ingroup RTEMSTestFrameworkImpl
  *
- * @brief Implementation of T_busy().
+ * @brief This source file contains the implementation of
+ *   T_busy().
  */
 
 /*
diff --git a/cpukit/libtest/t-test-checks-eno.c 
b/cpukit/libtest/t-test-checks-eno.c
index 5b450ccf99..48736915b4 100644
--- a/cpukit/libtest/t-test-checks-eno.c
+++ b/cpukit/libtest/t-test-checks-eno.c
@@ -1,6 +1,15 @@
-/*
- * SPDX-License-Identifier: BSD-2-Clause
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSTestFrameworkImpl
  *
+ * @brief This source file contains the implementation of
+ *   T_strerror(), T_check_eno(), and T_check_eno_success().
+ */
+
+/*
  * Copyright (C) 2018 embedded brains GmbH & Co. KG
  *
  * Redistribution and use in source and binary forms, with or without
diff --git a/cpukit/libtest/t-test-checks-psx.c 
b/cpukit/libtest/t-test-checks-psx.c
index 5394ea537a..5d6ec25bda 100644
--- a/cpukit/libtest/t-test-checks-psx.c
+++ b/cpukit/libtest/t-test-checks-psx.c
@@ -3,7 +3,10 @@
 /**
  * @file
  *
- * @brief
+ * @ingroup RTEMSTestFrameworkImpl
+ *
+ * @brief This source file contains the implementation of
+ *   T_check_psx_error() and T_check_psx_success().
  */
 
 /*
diff --git a/cpukit/libtest/t-test-checks.c b/cpukit/libtest/t-test-checks.c
index 40479a8277..b83e83f1f3 100644
--- a/cpukit/libtest/t-test-checks.c
+++ b/cpukit/libtest/t-test-checks.c
@@ -1,6 +1,15 @@
-/*
- * SPDX-License-Identifier: BSD-2-Clause
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSTestFrameworkImpl
  *
+ * @brief This source file contains the implementation of various RTEMS Test
+ *   Framework check functions.
+ */
+
+/*
  * Copyright (C) 2018 embedded brains GmbH & Co. KG
  *
  * Redistribution and use in source and binary forms, with or without
diff --git a/cpukit/libtest/t-test-hash-sha256.c 
b/cpukit/libtest/t-test-hash-sha256.c
index a9aa4df023..e937f81ddf 100644
--- 

Re: [PATCH] bsps/arm: fix installation broken by recent CMSIS files update

[Karel Gardas]

Sure! Not a problem, I was just waiting for Christian to confirm its 
also working on his side.


Thanks,
Karel

On 7/25/23 03:34, Chris Johns wrote:

Hi Karel,

I did not see this and made and pushed a similar patch. Thanks for this and
sorry for not checking closely as I missed it on the first pass.

Thanks
Chris

On 25/7/2023 1:53 am, Karel Gardas wrote:

---
  spec/build/bsps/arm/grp.yml | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/spec/build/bsps/arm/grp.yml b/spec/build/bsps/arm/grp.yml
index 1058f58d92..a48cd80d74 100644
--- a/spec/build/bsps/arm/grp.yml
+++ b/spec/build/bsps/arm/grp.yml
@@ -10,12 +10,13 @@ includes: []
  install:
  - destination: ${BSP_INCLUDEDIR}
source:
+  - bsps/arm/include/cachel1_armv7.h
+  - bsps/arm/include/cmsis_compiler.h
- bsps/arm/include/cmsis_gcc.h
+  - bsps/arm/include/cmsis_version.h
- bsps/arm/include/core_cm7.h
- bsps/arm/include/core_cm4.h
-  - bsps/arm/include/core_cmFunc.h
-  - bsps/arm/include/core_cmInstr.h
-  - bsps/arm/include/core_cmSimd.h
+  - bsps/arm/include/mpu_armv7.h
- bsps/arm/include/uart.h
  - destination: ${BSP_INCLUDEDIR}/bsp
source:


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

Re: [PATCH] score: Add workaround for GCC bug

[Chris Johns]

OK

Chris

On 25/7/2023 4:04 pm, Sebastian Huber wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
> 
> This GCC bug leads to an incomplete code coverage status.
> 
> Update #4932.
> ---
>  cpukit/score/cpu/no_cpu/cpuidle.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/cpukit/score/cpu/no_cpu/cpuidle.c 
> b/cpukit/score/cpu/no_cpu/cpuidle.c
> index bff1309d39..a6001e73b0 100644
> --- a/cpukit/score/cpu/no_cpu/cpuidle.c
> +++ b/cpukit/score/cpu/no_cpu/cpuidle.c
> @@ -33,6 +33,13 @@
>  
>  void *_CPU_Thread_Idle_body( uintptr_t ignored )
>  {
> +  /*
> +   * This is a workaround for:
> +   *
> +   * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
> +   */
> +  __asm__ volatile ("");
> +
>while ( true ) {
>  /* Do nothing */
>}
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[RSB PATCH] rtems/kernel: Update to the current kernel

[chrisj]

From: Chris Johns 

- Pick up the Beatnik support for the legacy driver
---
 rtems/config/tools/rtems-kernel-6.cfg | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/rtems/config/tools/rtems-kernel-6.cfg 
b/rtems/config/tools/rtems-kernel-6.cfg
index f2174c7..c9c884f 100644
--- a/rtems/config/tools/rtems-kernel-6.cfg
+++ b/rtems/config/tools/rtems-kernel-6.cfg
@@ -2,10 +2,10 @@
 # RTEMS 6
 #
 
-%define rtems_kernel_version a83dc4a469429e29cdd18eddbd1b9fff3f4328d8
+%define rtems_kernel_version c1d9dcbbb2a436256b49d9a0c322c78261509264
 
 %hash sha512 rtems-kernel-%{rtems_kernel_version}.tar.bz2 \
-   
baWt7QkFo2YlzV4pTnnZ8agonhdrWN4Z8yMgV6/vgZs+cRw59xRq69KfWzgqVZDpaA0l3nuiLqNaxqEh2fMXMw==
+   
dH0PgnSQ1k6pTCP/NhIgWzhDjHqFuLI03RBhbjaRFvRs5CUbZIG+x8opTb13czga/cUhOBd9JC7x557FkX0seA==
 #
 # The RTEMS build instructions.
 #
-- 
2.37.1

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

[PATCH] score: Add workaround for GCC bug

[Sebastian Huber]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658

This GCC bug leads to an incomplete code coverage status.

Update #4932.
---
 cpukit/score/cpu/no_cpu/cpuidle.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/cpukit/score/cpu/no_cpu/cpuidle.c 
b/cpukit/score/cpu/no_cpu/cpuidle.c
index bff1309d39..a6001e73b0 100644
--- a/cpukit/score/cpu/no_cpu/cpuidle.c
+++ b/cpukit/score/cpu/no_cpu/cpuidle.c
@@ -33,6 +33,13 @@
 
 void *_CPU_Thread_Idle_body( uintptr_t ignored )
 {
+  /*
+   * This is a workaround for:
+   *
+   * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108658
+   */
+  __asm__ volatile ("");
+
   while ( true ) {
 /* Do nothing */
   }
-- 
2.35.3

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