[PATCH] eng: add Apache License 2.0 restriction

2023-07-26 Thread Karel Gardas 
---
 eng/license-requirements.rst | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/eng/license-requirements.rst b/eng/license-requirements.rst
index b2720f2..b9eea9a 100644
--- a/eng/license-requirements.rst
+++ b/eng/license-requirements.rst
@@ -98,9 +98,25 @@ these guidelines:
 * Advertising obligations are not acceptable.
 
 * Some license restrictions may be permissible. These will be considered
-  on a case-by-case basis.
+  on a case-by-case basis. See below for a list of such restrictions.
 
 In practice, these guidelines are not hard to follow. Critically,
 they protect the freedom of the RTEMS source code and that of end users
 to select the license and distribution terms they prefer for their
 RTEMS-based application.
+
+License restrictions
+
+
+* Apache License 2.0 in section 4 (b) requires modified files to carry
+  prominent notice about performed modification. In case you modify such
+  file and the notice is not there yet you are required to put notice
+  below at the top of the modified file. If the notice is already
+  there you don't need to add it second time.
+  The notice should look:
+
+  .. code-block:: c
+
+ /*
+  * The file was modified by RTEMS contributors.
+  */
-- 
2.25.1

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

Re: [PATCH] eng: add Apache License 2.0 restriction

2023-07-26 Thread Gedare Bloom 
On Wed, Jul 26, 2023 at 4:28 AM Karel Gardas  wrote:
>
> ---
>  eng/license-requirements.rst | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/eng/license-requirements.rst b/eng/license-requirements.rst
> index b2720f2..b9eea9a 100644
> --- a/eng/license-requirements.rst
> +++ b/eng/license-requirements.rst
> @@ -98,9 +98,25 @@ these guidelines:
>  * Advertising obligations are not acceptable.
>
>  * Some license restrictions may be permissible. These will be considered
> -  on a case-by-case basis.
> +  on a case-by-case basis. See below for a list of such restrictions.
>
>  In practice, these guidelines are not hard to follow. Critically,
>  they protect the freedom of the RTEMS source code and that of end users
>  to select the license and distribution terms they prefer for their
>  RTEMS-based application.
> +
> +License restrictions
> +
> +
> +* Apache License 2.0 in section 4 (b) requires modified files to carry
> +  prominent notice about performed modification. In case you modify such
> +  file and the notice is not there yet you are required to put notice
> +  below at the top of the modified file. If the notice is already
> +  there you don't need to add it second time.
> +  The notice should look:
> +
> +  .. code-block:: c
> +
> + /*
> +  * The file was modified by RTEMS contributors.
> +  */

Add a note about NOTICES (and that we currently don't have one.)

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

Re: [PATCH] score/arm: style fixes

2023-07-26 Thread Gedare Bloom 
On Tue, Jul 25, 2023 at 11:11 PM Sebastian Huber
 wrote:
>
> 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.
>

Yes, that is a great point. There was a brief discussion about this on
discord, and which spaces to have or not. With time, I can probably
get this handled on a case-by-case basis as needed. For example, if we
want to keep spaces inside of function arguments.

One of the examples we discussed is:
- _IO_Printf( _CPU_Put_char, &sctx, "%d", (value & mask ? 1 : 0) );
+ _IO_Printf( _CPU_Put_char, &sctx, "%d", ( value & mask ? 1 : 0 ) );

I think it should be relatively easy to add support in clang-format
for spaces that retains the original version. I'll have to sit on this
a bit longer probably to get it done.

> --
> 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: style patches - discuss

2023-07-26 Thread Gedare Bloom 
On Tue, Jul 25, 2023 at 11:15 PM Sebastian Huber
 wrote:
>
> 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.
>
I agree. i think I can get clang-format closer to that "minimum set"
but it seems to require still a few more modifications upstream.

Regarding spaces in [], I analyzed the score and found it was not
consistent, but more of the time there were not spaces:
$ grep -r "\[[^[:space:]]" | wc
   2615   17577  191765

$ grep -r "\[[[:space:]]" | wc
2231509   16393

So that one is manageable. The situation with spaces after parentheses
is trickier. There is a preference by some to avoid spaces in the
nested parentheses of arithmetic/logic expressions. This seems to be
somewhat consistent, but it is also a bit complicated to detect the
difference between:
z = ( x + y )
z = ( x + (x + y) )

Not impossible, but also not really standard anywhere that I have seen.

Gedare

> --
> 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] eng: add Apache License 2.0 restriction

2023-07-26 Thread Karel Gardas 
---
 eng/license-requirements.rst | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/eng/license-requirements.rst b/eng/license-requirements.rst
index b2720f2..537b45e 100644
--- a/eng/license-requirements.rst
+++ b/eng/license-requirements.rst
@@ -98,9 +98,33 @@ these guidelines:
 * Advertising obligations are not acceptable.
 
 * Some license restrictions may be permissible. These will be considered
-  on a case-by-case basis.
+  on a case-by-case basis. See below for a list of such restrictions.
 
 In practice, these guidelines are not hard to follow. Critically,
 they protect the freedom of the RTEMS source code and that of end users
 to select the license and distribution terms they prefer for their
 RTEMS-based application.
+
+License restrictions
+
+
+* Apache License 2.0 in section 4 (b) requires modified files to carry
+  prominent notice about performed modification. In case you modify such
+  file and the notice is not there yet you are required to put notice
+  below at the top of the modified file. If the notice is already
+  there you don't need to add it second time.
+  The notice should look:
+
+  .. code-block:: c
+
+ /*
+  * The file was modified by RTEMS contributors.
+  */
+
+ .. warning:: Do not import any project or files covered by the Apache
+  License 2.0 into the RTEMS project source tree without
+  discussing first with developers on the mailing list!
+  Handling of Apache License 2.0 projects is a bit
+  sensitive manner and RTEMS project is not prepared to
+  handle one kind of those projects yet. E.g. the projects
+  with NOTICE file present in the source tree.
-- 
2.25.1

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

[PATCH] bsps/stm32h7: Allow use of max temp range

2023-07-26 Thread Kinsey Moore 
This adds an option to allow operation of the CPU at its maximum
temperature range of 125F by reducing the CPU clock to 400MHz instead of
the 105F limit imposed by the default 480MHz CPU clock. This tradeoff is
detailed in table 122 in section 7.3.1 of the STM32H743VI datasheet. The
default remains at 480MHz/105F.
---
 .../stm/stm32h743i-eval/stm32h7-config-osc.c   |  8 
 spec/build/bsps/arm/stm32h7/bspstm32h7.yml |  2 ++
 spec/build/bsps/arm/stm32h7/optenthermal.yml   | 18 ++
 3 files changed, 28 insertions(+)
 create mode 100644 spec/build/bsps/arm/stm32h7/optenthermal.yml

diff --git a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-osc.c 
b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-osc.c
index df55a49b3c..016f772309 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-osc.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-osc.c
@@ -42,9 +42,17 @@ const RCC_OscInitTypeDef stm32h7_config_oscillator = {
   .PLL.PLLState = RCC_PLL_ON,
   .PLL.PLLSource = RCC_PLLSOURCE_HSE,
   .PLL.PLLM = 5,
+#ifdef STM32H7_OSC_ENABLE_MAX_THERMAL_RANGE
+  .PLL.PLLN = 160,
+#else
   .PLL.PLLN = 192,
+#endif
   .PLL.PLLP = 2,
+#ifdef STM32H7_OSC_ENABLE_MAX_THERMAL_RANGE
+  .PLL.PLLQ = 2,
+#else
   .PLL.PLLQ = 12,
+#endif
   .PLL.PLLR = 2,
   .PLL.PLLRGE = RCC_PLL1VCIRANGE_2,
   .PLL.PLLVCOSEL = RCC_PLL1VCOWIDE,
diff --git a/spec/build/bsps/arm/stm32h7/bspstm32h7.yml 
b/spec/build/bsps/arm/stm32h7/bspstm32h7.yml
index 0aaf1f0cc6..2614457bcc 100644
--- a/spec/build/bsps/arm/stm32h7/bspstm32h7.yml
+++ b/spec/build/bsps/arm/stm32h7/bspstm32h7.yml
@@ -13,6 +13,8 @@ install: []
 links:
 - role: build-dependency
   uid: grp
+- role: build-dependency
+  uid: optenthermal
 source:
 - bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-bspstarthooks.c
 - bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-clk.c
diff --git a/spec/build/bsps/arm/stm32h7/optenthermal.yml 
b/spec/build/bsps/arm/stm32h7/optenthermal.yml
new file mode 100644
index 00..ff79db213d
--- /dev/null
+++ b/spec/build/bsps/arm/stm32h7/optenthermal.yml
@@ -0,0 +1,18 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-boolean: null
+- define-condition: null
+build-type: option
+copyrights:
+- Copyright (C) 2023 On-Line Applications Research (OAR)
+default:
+- enabled-by: true
+  value: false
+description: |
+  Allow use of the maximum thermal range the CPU is capable of by reducing the
+  CPU clock to 400MHz
+enabled-by: true
+format: '{}'
+links: []
+name: STM32H7_OSC_ENABLE_MAX_THERMAL_RANGE
+type: build
-- 
2.39.2

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

Re: [PATCH] doxygen: Replace main page

2023-07-26 Thread Chris Johns 
On 26/7/2023 3:50 pm, Sebastian Huber wrote:
> 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:
> 

This makes sense.

> + * The Real-Time Executive for Multiprocessor Systems (RTEMS) is a
> + * multi-threaded, single address-space, real-time operating system with no
> + * kernel-space/user-space separation.  It is capable to operate in an SMP
> + * configuration providing a state of the art feature set.
> + *
> + * RTEMS is licensed under a [modified GPL 2.0 or later license with an
> + * exception for static linking](https://git.rtems.org/rtems/tree/LICENSE>).
> + * It exposes no license requirements on application code.  The third-party
> + * software used and distributed by RTEMS which may be linked to the
> + * application is licensed under permissive open source licenses.  Everything
> + * necessary to build RTEMS applications is available as open source 
> software.
> + * This makes you completely vendor independent.
> + *
> + * The goal is to use the [BSD 2-Clause
> + * license](https://git.rtems.org/rtems/tree/LICENSE.BSD-2-Clause) for new 
> code
> + * or code those copyright holder agreed to a license change, see
> + * [#3053](https://devel.rtems.org/ticket/3053) for the details.

Why all this detail about the licenses here?

I think it complicates things by adding another place it is mentioned. A list of
licences or a comment on how to determine the licenses yes.

I would have though we are now mostly BSD with some places still GLP+exception.

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

Re: [PATCH] doxygen: Replace main page

2023-07-26 Thread Joel Sherrill 
On Wed, Jul 26, 2023 at 12:50 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> 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
>

No. You are reformatting this. This text dates back to the beginnings of
RTEMS. You should NOT remove the OAR copyright.


>   *
>   * 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 depe

Re: [PATCH] build: Add optional RTEMS_VERSION_VC_KEY

2023-07-26 Thread Chris Johns 


On 26/7/2023 4:54 pm, Sebastian Huber wrote:
> On 26.07.23 08:20, Chris Johns wrote:
>> On 26/7/2023 3:44 pm, Sebastian Huber wrote:
>>> 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
>>   > > 
>>   > > >> 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
>> Can you please just explain the mechanics of how this gets used? While I 
>> could
>> try and guess but I would rather not. 😄
> 
> In the v2 patch you just have to do this for a release archive:
> 
> sed -i "s/  value: git/  value: ''/" 
> spec/build/cpukit/optversioncontrolkey.yml
> 

Does this mean the default is changed in the sources in the tarball?

Can the option be overridden in a config file?

>>
>> We have an established method in other repos of adding a VERSION file to the
>> source tarball. Why not follow that m

Re: [PATCH] doxygen: Replace main page

2023-07-26 Thread Sebastian Huber 



On 27.07.23 02:13, Joel Sherrill wrote:



On Wed, Jul 26, 2023 at 12:50 AM Sebastian Huber 
> wrote:


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


No. You are reformatting this. This text dates back to the beginnings of
RTEMS. You should NOT remove the OAR copyright.


I am quite careful with copyright, but everyone can make mistakes. This 
patch replaces the original content with the new features section from:


https://git.rtems.org/rtems-docs/commit/user/overview/index.rst?id=52f4890281a50d7d2e27386257cc9799d9152707

Which updated OAR Copyright line do you want to see in this patch? I 
will add it to v2 of the patch.


[...]

+ * The Real-Time Executive for Multiprocessor Systems (RTEMS) is a
+ * multi-threaded, single address-space, real-time operating system
with no
+ * kernel-space/user-space separation.  It is capable to operate in
an SMP
+ * configuration providing a state of the art feature set.
+ *
+ * RTEMS is licensed under a [modified GPL 2.0 or later license with an
+ * exception for static
linking](https://git.rtems.org/rtems/tree/LICENSE
>).
+ * It exposes no license requirements on application code.  The
third-party
+ * software used and distributed by RTEMS which may be linked to the
+ * application is licensed under permissive open source licenses. 
Everything

+ * necessary to build RTEMS applications is available as open
source software.
+ * This makes you completely vendor independent.
+ *
+ * The goal is to use the [BSD 2-Clause
+ * license](https://git.rtems.org/rtems/tree/LICENSE.BSD-2-Clause
) for new code
+ * or code those copyright holder agreed to a license change, see
+ * [#3053](https://devel.rtems.org/ticket/3053
) for the details.


This is true but out of date. The bulk of the target and BSP independent 
code
is BSD-2 and we state that first. There are older submissions -- 
primarily around

BSPs and a couple of architectures where GPL code is present.

We state now that we are BSD-2 with remnants of GPLv2 + exception and will
NOT accept code under the old license.


Yes, the patch is actually from 2021, but I was busy with other things 
in the meantime. I will reformulate this section for v2. The user manual 
probably needs also an update:


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

--
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

2023-07-26 Thread Sebastian Huber 

On 27.07.23 06:36, Chris Johns wrote:


On 26/7/2023 4:54 pm, Sebastian Huber wrote:

On 26.07.23 08:20, Chris Johns wrote:

On 26/7/2023 3:44 pm, Sebastian Huber wrote:

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
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 "".

I sent a patch with this approach:

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

Can you please just explain the mechanics of how this gets used? While I could
try and guess but I would rather not. 😄

In the v2 patch you just have to do this for a release archive:

sed -i "s/  value: git/  value: ''/" spec/build/cpukit/optversioncontrolkey.yml


Does this mean the default is changed in the sources in the tarball?


Yes, this is one option.



Can the option be overridden in a config file?


This depends on what we want. If you just change the default value, then 
you can change it in your config.ini. It will also show up in


./waf bspdefaults --rtems-bsps sparc/erc32| grep -B 10 VERSION
COVERAGE_COMPILER_FLAGS =
# Linker flags recommended for executables which contain modules which
# generate coverage information.
COVERAGE_LINKER_FLAGS =
# 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.

Re: [PATCH] bsps/stm32h7: Allow use of max temp range

2023-07-26 Thread Cedric Berger 

Hello,

On 26.07.23 22:48, Kinsey Moore wrote:

This adds an option to allow operation of the CPU at its maximum
temperature range of 125F by reducing the CPU clock to 400MHz instead of
the 105F limit imposed by the default 480MHz CPU clock. This tradeoff is
detailed in table 122 in section 7.3.1 of the STM32H743VI datasheet. The
default remains at 480MHz/105F.


I think it is very good to reduce the CPU clock this way. Does your 
patch also results in a decrease of operating voltage from VOS0 to VOS1?


In my opinion, the default "480MHz/105F" is not very serious: at that 
frequency + temperature, the chip has an expected lifetime of < 2 years.


See: 
https://www.st.com/resource/en/application_note/an5337-stm32h7-series-lifetime-estimates-stmicroelectronics.pdf


For our product, we might even reduce the clock further to 300MHZ to be 
able to use VOS2 voltage.


All that to say that imho, 1) the default should be 400MHz, and 2) if 
there is some configuration variable, maybe it should be based on the 
voltage, like "STM23H7_VCORE", with the following values:


- "VOS0": Freq = 480 MHz (the actual default)
- "VOS1": Freq = 400 MHz (your new proposed value)
- "VOS2": Freq = 300 MHz (a very conservative setting)
- "VOS3": Freq = 200 MHz (for very low power usage)

Cedric


---
  .../stm/stm32h743i-eval/stm32h7-config-osc.c   |  8 
  spec/build/bsps/arm/stm32h7/bspstm32h7.yml |  2 ++
  spec/build/bsps/arm/stm32h7/optenthermal.yml   | 18 ++
  3 files changed, 28 insertions(+)
  create mode 100644 spec/build/bsps/arm/stm32h7/optenthermal.yml

diff --git a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-osc.c 
b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-osc.c
index df55a49b3c..016f772309 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-osc.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-osc.c
@@ -42,9 +42,17 @@ const RCC_OscInitTypeDef stm32h7_config_oscillator = {
.PLL.PLLState = RCC_PLL_ON,
.PLL.PLLSource = RCC_PLLSOURCE_HSE,
.PLL.PLLM = 5,
+#ifdef STM32H7_OSC_ENABLE_MAX_THERMAL_RANGE
+  .PLL.PLLN = 160,
+#else
.PLL.PLLN = 192,
+#endif
.PLL.PLLP = 2,
+#ifdef STM32H7_OSC_ENABLE_MAX_THERMAL_RANGE
+  .PLL.PLLQ = 2,
+#else
.PLL.PLLQ = 12,
+#endif
.PLL.PLLR = 2,
.PLL.PLLRGE = RCC_PLL1VCIRANGE_2,
.PLL.PLLVCOSEL = RCC_PLL1VCOWIDE,
diff --git a/spec/build/bsps/arm/stm32h7/bspstm32h7.yml 
b/spec/build/bsps/arm/stm32h7/bspstm32h7.yml
index 0aaf1f0cc6..2614457bcc 100644
--- a/spec/build/bsps/arm/stm32h7/bspstm32h7.yml
+++ b/spec/build/bsps/arm/stm32h7/bspstm32h7.yml
@@ -13,6 +13,8 @@ install: []
  links:
  - role: build-dependency
uid: grp
+- role: build-dependency
+  uid: optenthermal
  source:
  - bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-bspstarthooks.c
  - bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-clk.c
diff --git a/spec/build/bsps/arm/stm32h7/optenthermal.yml 
b/spec/build/bsps/arm/stm32h7/optenthermal.yml
new file mode 100644
index 00..ff79db213d
--- /dev/null
+++ b/spec/build/bsps/arm/stm32h7/optenthermal.yml
@@ -0,0 +1,18 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-boolean: null
+- define-condition: null
+build-type: option
+copyrights:
+- Copyright (C) 2023 On-Line Applications Research (OAR)
+default:
+- enabled-by: true
+  value: false
+description: |
+  Allow use of the maximum thermal range the CPU is capable of by reducing the
+  CPU clock to 400MHz
+enabled-by: true
+format: '{}'
+links: []
+name: STM32H7_OSC_ENABLE_MAX_THERMAL_RANGE
+type: build

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

Re: style patches - discuss

2023-07-26 Thread Sebastian Huber 



On 26.07.23 17:17, Gedare Bloom wrote:

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


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.


I agree. i think I can get clang-format closer to that "minimum set"
but it seems to require still a few more modifications upstream.

Regarding spaces in [], I analyzed the score and found it was not
consistent, but more of the time there were not spaces:
$ grep -r "\[[^[:space:]]" | wc
2615   17577  191765

$ grep -r "\[[[:space:]]" | wc
 2231509   16393


You have to look also at the files and not just the overall count. The 
[x] style is mostly used on files outside the original score (newer 
contributions, CPU ports, BSD sources).


The style guide doesn't cover the [] explicitly, but I think we should 
just apply the rules for ():


https://docs.rtems.org/branches/master/eng/coding-formatting.html



So that one is manageable. The situation with spaces after parentheses
is trickier. There is a preference by some to avoid spaces in the
nested parentheses of arithmetic/logic expressions. This seems to be
somewhat consistent, but it is also a bit complicated to detect the
difference between:
z = ( x + y )
z = ( x + (x + y) )

Not impossible, but also not really standard anywhere that I have seen.


I would place spaces everywhere or nowhere around things involving ()[].

z = ( x + ( x + y ) )

or

z = (x + (x + y))

A main characteristic of the score style is the excessive use of spaces 
around everything, but only two spaces for indentation ;-)


--
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

No RTEMS documentation updates on the web site?

2023-07-26 Thread Sebastian Huber 

Hello,

it seems the RTEMS documentation on the web site is from 24th of January:

https://docs.rtems.org/

--
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