date:20230724




On 25.07.23 04:31, Vijay Kumar Banerjee wrote:

On Mon, Jul 24, 2023 at 10:09 AM Sebastian Huber
  wrote:

On 20.07.23 03:10, Vijay Kumar Banerjee wrote:

Add CONFIGURE_APPLICATION_NEEDS_LIBI2C_DRIVER define

Do we really need this? What happens if an I2C device needs interrupts
during initialization?


the libi2c initialize calls rtems_io_register_driver, which requires
`CONFIGURE_MAXIMUM_DRIVERS` defined from the application. In some
BSPs, like mvme3100, libi2c is initialized at sysinit, causing the
application to crash without the define. Adding this confdefs macro
allows the user to add the libi2c if it is needed by the app, or omit
it without crashing the system. In its current state, libi2c requires
the BSP to handle registering the buses and drivers after
initialization, the interrupt can be handled by the BSP I2C handler.


Ok, maybe one option is to use IMFS_make_generic_node() instead of using 
rtems_io_register_driver(). Another option is to use the new I2C framework.


If you really need this new application configuration option, then 
please document it:


https://docs.rtems.org/branches/master/eng/req/howto.html#application-configuration-options

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

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

Re: [PATCH v2] c-user: Link task entry and global construction


On 25.07.23 04:30, Gedare Bloom wrote:

OK. Next time if you can just comment on the v1 that there's a v2. thanks


Sorry, I try to remember this next time. Thanks for having a look at 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] score: Move _IO_Relax() to new

On 24.07.23 21:45, Joel Sherrill wrote:

On Mon, Jul 24, 2023 at 10:49 AM Sebastian Huber 
> wrote:

On 24.07.23 17:34, Joel Sherrill wrote:
 >
 > What about the other io methods in score like for gcov and hashing?
 > Is there a better location for those?

We could move everything in rtems/score/io.h to rtems/dev/io.h. The
gcov
stuff could be moved to rtems/test-gcov.h.

OK. When looking at the score/, those stood out as not being strictly 
related

to normal score functionality.

Will moving the gcov stuff to rtems/test-gcov.h still leave it available 
to users?

If an application wants coverage, it has to do the same things. Right?

An application can use this stuff, however, I think it is a bit too 
early to make it a public API.

--
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] 6: Use GDB 13.2

On 25.07.23 03:43, Chris Johns wrote:

On 24/7/2023 9:53 pm, Sebastian Huber wrote:

Hello Karel,

On 24.07.23 13:15, Karel Gardas wrote:

this together with also libexpat patch builds fine on:

- macOS 13.4.1
- FreeBSD 13.2
- Ubuntu 20.04

thanks for the testing.

btw, recently Joel remarked that gdb from 7/ makes troubles building on fbsd
12.x. I verified the same on fbsd 13.x and Hesham noted on discord that he has
the same issues on macOS. GBD from 7/rtems-* complains about missing libmpfr.

[...]
checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... no
configure: error: Building GDB requires GMP 4.2+, and MPFR 3.1.0+.
Try the --with-gmp and/or --with-mpfr options to specify
their locations. If you obtained GMP and/or MPFR from a vendor
distribution package, make sure that you have installed both the libraries
and the header files. They may be located in separate packages.
shell cmd failed: /bin/sh -ex
/usr/home/karel/git/rtems-source-builder/rtems/build/aarch64-rtems7-gdb-22e69d8-x86_64-freebsd13.2-1/do-build
error: building aarch64-rtems7-gdb-22e69d8-x86_64-freebsd13.2-1

Obviusly gdb from 6/ does not hence there is probably some bit missing in 7/
which is already fixed in 6/

Actually I don't know how this should be handled. Some libraries are added to
rtems/config/6/rtems-default.bset others seem to be specific tool files. The 7/
tools should a minimum set of patches. Things should be directly fixed in the
upstream projects.

We have been moving to build support libraries, such as GMP, separately and not
by links into the source tree of gcc. MacOS M silicon requires a specific option
for GMP to work and this has resulted in us building these libraries before
building the packages that depend on them because the upstream provide no means
to inject specific options. GDB added GMP and it seems more are being added so
we need to add support to build them before GDB and remove the symlink'ing into
the GCC source tree. The GMP change should provide a suitable template for doing
this.

So, ISL, MPC, MPFR, etc. should also move to the top level configuration?

--
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 rtems 2/3] confdefs: Add configure macro for libi2c

2023-07-24 Thread Vijay Kumar Banerjee

Hi Sebastian,

On Mon, Jul 24, 2023 at 10:09 AM Sebastian Huber
 wrote:
>
> On 20.07.23 03:10, Vijay Kumar Banerjee wrote:
> > Add CONFIGURE_APPLICATION_NEEDS_LIBI2C_DRIVER define
>
> Do we really need this? What happens if an I2C device needs interrupts
> during initialization?
>

the libi2c initialize calls rtems_io_register_driver, which requires
`CONFIGURE_MAXIMUM_DRIVERS` defined from the application. In some
BSPs, like mvme3100, libi2c is initialized at sysinit, causing the
application to crash without the define. Adding this confdefs macro
allows the user to add the libi2c if it is needed by the app, or omit
it without crashing the system. In its current state, libi2c requires
the BSP to handle registering the buses and drivers after
initialization, the interrupt can be handled by the BSP I2C handler.

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

Re: [PATCH v2] c-user: Link task entry and global construction

2023-07-24 Thread Gedare Bloom

OK. Next time if you can just comment on the v1 that there's a v2. thanks

On Sun, Jul 23, 2023 at 11:51 PM Sebastian Huber
 wrote:
>
> ---
> v2: Mention global construction in application configuration options.
>
>  c-user/config/classic-init-task.rst  |  5 -
>  c-user/config/idle-task.rst  |  5 -
>  c-user/config/posix-init-thread.rst  |  5 -
>  c-user/glossary.rst  | 13 +
>  c-user/initialization/operations.rst | 25 +++--
>  c-user/rtems_data_types.rst  |  2 +-
>  c-user/task/directives.rst   |  6 +++---
>  7 files changed, 44 insertions(+), 17 deletions(-)
>
> diff --git a/c-user/config/classic-init-task.rst 
> b/c-user/config/classic-init-task.rst
> index 43ab95c..2f1baad 100644
> --- a/c-user/config/classic-init-task.rst
> +++ b/c-user/config/classic-init-task.rst
> @@ -405,7 +405,7 @@ initialization task is configured.
>
>  .. rubric:: NOTES:
>
> -The application shall define exactly one of the following configuration
> +The application shall define at least one of the following configuration
>  options
>
>  * ``CONFIGURE_RTEMS_INIT_TASKS_TABLE``,
> @@ -415,3 +415,6 @@ options
>  * :ref:`CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION`
>
>  otherwise a compile time error in the configuration file will occur.
> +
> +The Classic API initialization task performs the
> +:ref:`GlobalConstruction`.
> diff --git a/c-user/config/idle-task.rst b/c-user/config/idle-task.rst
> index e98ad83..793fb5c 100644
> --- a/c-user/config/idle-task.rst
> +++ b/c-user/config/idle-task.rst
> @@ -123,7 +123,7 @@ If this configuration option is defined, then it is 
> mandatory to configure a
>  user IDLE task with the :ref:`CONFIGURE_IDLE_TASK_BODY` configuration option,
>  otherwise a compile time error in the configuration file will occur.
>
> -The application shall define exactly one of the following configuration
> +The application shall define at least one of the following configuration
>  options
>
>  * :ref:`CONFIGURE_RTEMS_INIT_TASKS_TABLE`,
> @@ -134,6 +134,9 @@ options
>
>  otherwise a compile time error in the configuration file will occur.
>
> +If no Classic API initialization task and no POSIX API initialization thread
> +is configured, then no :ref:`GlobalConstruction` is performed.
> +
>  .. Generated from spec:/acfg/if/idle-task-stack-size
>
>  .. raw:: latex
> diff --git a/c-user/config/posix-init-thread.rst 
> b/c-user/config/posix-init-thread.rst
> index 8a8b9b5..d4439a6 100644
> --- a/c-user/config/posix-init-thread.rst
> +++ b/c-user/config/posix-init-thread.rst
> @@ -151,7 +151,7 @@ initialization thread is configured.
>
>  .. rubric:: NOTES:
>
> -The application shall define exactly one of the following configuration
> +The application shall define at least one of the following configuration
>  options
>
>  * :ref:`CONFIGURE_RTEMS_INIT_TASKS_TABLE`,
> @@ -162,6 +162,9 @@ options
>
>  otherwise a compile time error in the configuration file will occur.
>
> +If no Classic API initialization task is configured, then the POSIX API
> +initialization thread performs the :ref:`GlobalConstruction`.
> +
>  .. rubric:: CONSTRAINTS:
>
>  The configuration option is not included in the pre-qualified feature set of
> diff --git a/c-user/glossary.rst b/c-user/glossary.rst
> index 0962f44..8d86691 100644
> --- a/c-user/glossary.rst
> +++ b/c-user/glossary.rst
> @@ -476,6 +476,10 @@ Glossary
>  An object that has been created with the GLOBAL attribute and 
> exported to
>  all nodes in a multiprocessor system.
>
> +global construction
> +In the global construction, the C++ global constructors and 
> constructor
> +functions are invoked.  See :ref:`GlobalConstruction`.
> +
>  GNAT
>  *GNAT* is the :term:`GNU` compiler for Ada, integrated into the
>  :term:`GCC`.
> @@ -1379,6 +1383,15 @@ Glossary
>  A data structure associated with each task used by RTEMS to manage 
> that
>  task.
>
> +task entry
> +The task entry is invoked to execute the task's job.  Before the 
> task entry
> +is invoked, the thread begin :term:`user extensions` run in the 
> context of
> +the task.  After the return of the task entry, the thread exitted 
> user
> +extensions run in the context of the task.  The first user 
> initialization
> +task performs the :term:`global construction` after running the 
> thread begin
> +extensions and before the task entry is invoked.  See also
> +:ref:`InterfaceRtemsTaskStart`.
> +
>  task migration
>  Task migration happens in case a task stops execution on one 
> processor
>  and resumes execution on another processor.
> diff --git a/c-user/initialization/operations.rst 
> b/c-user/initialization/operations.rst
> index db5c94b..e7d310c 100644
> --- a/c-user/initialization/operations.rst
> +++ b/c-user/initialization/operations.rst
> @@ -285,19 +285,24 @@ Many of RTEMS actions

Re: [PATCH] c-user: Link task entry and global construction

2023-07-24 Thread Gedare Bloom

looks good

On Sat, Jul 22, 2023 at 4:54 AM Sebastian Huber
 wrote:
>
> ---
>  c-user/glossary.rst  | 13 +
>  c-user/initialization/operations.rst | 25 +++--
>  c-user/rtems_data_types.rst  |  2 +-
>  c-user/task/directives.rst   |  6 +++---
>  4 files changed, 32 insertions(+), 14 deletions(-)
>
> diff --git a/c-user/glossary.rst b/c-user/glossary.rst
> index 0962f44..8d86691 100644
> --- a/c-user/glossary.rst
> +++ b/c-user/glossary.rst
> @@ -476,6 +476,10 @@ Glossary
>  An object that has been created with the GLOBAL attribute and 
> exported to
>  all nodes in a multiprocessor system.
>
> +global construction
> +In the global construction, the C++ global constructors and 
> constructor
> +functions are invoked.  See :ref:`GlobalConstruction`.
> +
>  GNAT
>  *GNAT* is the :term:`GNU` compiler for Ada, integrated into the
>  :term:`GCC`.
> @@ -1379,6 +1383,15 @@ Glossary
>  A data structure associated with each task used by RTEMS to manage 
> that
>  task.
>
> +task entry
> +The task entry is invoked to execute the task's job.  Before the 
> task entry
> +is invoked, the thread begin :term:`user extensions` run in the 
> context of
> +the task.  After the return of the task entry, the thread exitted 
> user
> +extensions run in the context of the task.  The first user 
> initialization
> +task performs the :term:`global construction` after running the 
> thread begin
> +extensions and before the task entry is invoked.  See also
> +:ref:`InterfaceRtemsTaskStart`.
> +
>  task migration
>  Task migration happens in case a task stops execution on one 
> processor
>  and resumes execution on another processor.
> diff --git a/c-user/initialization/operations.rst 
> b/c-user/initialization/operations.rst
> index db5c94b..e7d310c 100644
> --- a/c-user/initialization/operations.rst
> +++ b/c-user/initialization/operations.rst
> @@ -285,19 +285,24 @@ Many of RTEMS actions during initialization are based 
> upon the contents of the
>  Configuration Table.  For more information regarding the format and contents 
> of
>  this table, please refer to the chapter :ref:`Configuring a System`.
>
> +.. index:: global construction
> +
> +.. _GlobalConstruction:
> +
>  Global Construction
>  ---
>
> -The global construction is carried out by the first Classic API 
> initialization
> -task (first is defined by index zero in the Classic API initialization task
> -configuration table).  If no Classic API initialization task exists, then it 
> is
> -carried out by the first POSIX API initialization thread.  If no 
> initialization
> -task or thread exists, then no global construction is performed, see for
> -example :ref:`Specify Idle Task Performs Application Initialization`.  The
> -Classic API task or POSIX API thread which carries out global construction is
> -called the main thread.
> -
> -Global construction runs before the entry function of the main thread.  The
> +The :term:`global construction` is carried out by the Classic API
> +initialization task.  If no Classic API initialization task exists, then it 
> is
> +carried out by the POSIX API initialization thread.  If no initialization 
> task
> +or thread exists, then no global construction is performed.  The Classic API
> +task or POSIX API thread which carries out global construction is called the
> +main thread.  For configuration options related to initialization tasks, see
> +:ref:`CONFIGURE_RTEMS_INIT_TASKS_TABLE`,
> +:ref:`CONFIGURE_POSIX_INIT_THREAD_TABLE`, and
> +:ref:`CONFIGURE_IDLE_TASK_INITIALIZES_APPLICATION`.
> +
> +Global construction runs before the :term:`task entry` of the main thread.  
> The
>  configuration of the main thread must take the global construction into
>  account.  In particular, the main thread stack size, priority, attributes and
>  initial modes must be set accordingly.  Thread-local objects and POSIX key
> diff --git a/c-user/rtems_data_types.rst b/c-user/rtems_data_types.rst
> index a311509..8e4274b 100644
> --- a/c-user/rtems_data_types.rst
> +++ b/c-user/rtems_data_types.rst
> @@ -1523,7 +1523,7 @@ extension set.
>  rtems_task_entry
>  
>
> -This type defines the entry point of an RTEMS task.
> +This type defines the :term:`task entry` point of an RTEMS task.
>
>  .. Generated from spec:/rtems/userext/if/task-exitted
>
> diff --git a/c-user/task/directives.rst b/c-user/task/directives.rst
> index f4b65f5..d976905 100644
> --- a/c-user/task/directives.rst
> +++ b/c-user/task/directives.rst
> @@ -624,9 +624,9 @@ Starts the task.
>  .. rubric:: DESCRIPTION:
>
>  This directive readies the task, specified by ``id``, for execution based on
> -the priority and execution mode specified when the task was created.  The 
> entry
> -point of the task is given in ``entry_point``. The task's entry

Re: [PATCH] membench: Add memory benchmark programs

2023-07-24 Thread Gedare Bloom

On Mon, Jul 24, 2023 at 2:01 AM Sebastian Huber
 wrote:
>
> On 21.07.23 09:43, Chris Johns wrote:
> > On 21/7/2023 3:28 pm, Sebastian Huber wrote:
> >> On 21.07.23 03:27, Chris Johns wrote:
> >>> On 21/7/2023 3:51 am, Sebastian Huber wrote:
>  On 20.07.23 18:58, Gedare Bloom wrote:
> > On Thu, Jul 20, 2023 at 7:42 AM Sebastian Huber
> >   wrote:
> >> These memory benchmark programs are not supposed to run.  Instead, they
> >> can be analysed on the host system to measure the memory usage of
> >> features.  See the membench module of rtems-central.
> >>
> > This needs some kind of documentation and probably a README inside of
> > membench with that information.
> 
>  Ok, I can add a README.md.
> 
> >
> > This appears to be about benchmarking the program size (static memory
> > usage) only? If so, make that clear in the README / log note. I think
> > it's in the doxygen already so that's helpful.
> 
>  Yes, it measures only the static memory size required for certain 
>  operating
>  system services. See 4.7 Memory Usage Benchmarks in:
> 
>  https://ftp.rtems.org/pub/rtems/people/sebh/rtems-6-sparc-gr740-uni-6-scf.pdf
> >>>
> >>> Should `static` be part of naming?
> >>
> >> Yes, good idea.
> >>
> >>>
> > What happens when the membench gets built, and then someone runs
> > $> rtems-test build/${ARCH}/${BSP}/testsuites
> >
> > Because I don't see anything that is filtering these executables.
> 
>  They are filtered out due to the *.norun.* pattern:>
>  target: testsuites/membench/mem-scheduler-add-cpu.norun.exe
> 
> >>>
> >>> Currently tests with `norun` assume the build fails if there is an issue 
> >>> with a
> >>> test. This is why we allow these tests and they are tagged `norun`.
> >>
> >> We already have a couple of norun tests in libtests. This filtering is 
> >> simple
> >> and works fine why would you want to change it?
> >
> > I am not asking for that to change. After a build we will have a set of 
> > norun
> > tests and in that set are some that are be used for other purposes, eg 
> > memory
> > analysis, but that information is not available in the project. The norun 
> > could
> > be extended to be .norun.memstatic.exe and so the executables that form a
> > specific subset can be found and analysed.
>
> The modules used to analyze static memory benchmarks know how to find
> them. The pattern is currently f"{path}/mem-{module}-{name}.norun.exe".
> We could of course use also a different pattern or no pattern at all,
> since the specification knows exactly which executable is associated
> with which item.
>
> >
> > The tests have been self contained for a long time and I would like that to
> > continue. ELF notes has been discussed in the past however we do not yet 
> > support
> > that so we need to find other ways to handling things.
>
> The static memory benchmarks are not useful individually. You have to
> know the relationship between them to get the results. For example, what
> is the cost of using API call X in terms of static memory usage?
>
> >
> >>> Are they suppose to be checked or are they informational? Is something 
> >>> going to
> >>> be added to the project, for example in rtems-tools.git, to allow these 
> >>> tests to
> >>> be checked?
> >>
> >> Currently, they are just informational,
> >
> > I do not understand. What information, for what purpose and for whom?
>
> I would have a look at the section 4.7 Memory Usage Benchmarks in to get
> an idea:
>
> https://ftp.rtems.org/pub/rtems/people/sebh/rtems-6-sparc-gr740-uni-6-scf.pdf
>
> This is just one application. You could also use the static memory
> benchmarks in a CI runner to catch memory usage regressions.
>
We should have a use or plan for them. Adding the output as part of
build tests is a good start. Maybe we can tie them into the build
visualization project in the future.

> >
> >> All the stuff to analyze this and work with
> >> the specification is in rtems-central.git. If you think this needs to be
> >> changed, then I am happy to discuss this.
> >


There is a philosophical discussion to be had here, and a debate of
sorts. IIRC the original intent of rtems-central was to provide a
centralized workflow for developers and pre-qualification to be a
"repo of repos". Now, it contains a lot of core support code itself.
The current design creates a dependency loop among repositories, which
IMO should be avoided.  I'm happy to hear other perspectives.

I would suggest promoting (maturing) out some of the code in
rtems-central into existing/new support repositories where
appropriate. This would be a good opportunity to start to pull out and
modularize pieces of rtems-central.git. If it makes more sense to add
a new top-level repo to support some of the content generation, then
so be it. I would find this easier to comprehend. I do see that this
may be a bit involved at present. The sphinxcontent.py generator

Re: [PATCH] 6: Use GDB 13.2

2023-07-24 Thread Chris Johns

On 24/7/2023 9:53 pm, Sebastian Huber wrote:
> Hello Karel,
> 
> On 24.07.23 13:15, Karel Gardas wrote:
>>
>> this together with also libexpat patch builds fine on:
>>
>> - macOS 13.4.1
>> - FreeBSD 13.2
>> - Ubuntu 20.04
> 
> thanks for the testing.
> 
>>
>> btw, recently Joel remarked that gdb from 7/ makes troubles building on fbsd
>> 12.x. I verified the same on fbsd 13.x and Hesham noted on discord that he 
>> has
>> the same issues on macOS. GBD from 7/rtems-* complains about missing libmpfr.
>>
>> [...]
>> checking for the correct version of gmp.h... yes
>> checking for the correct version of mpfr.h... no
>> configure: error: Building GDB requires GMP 4.2+, and MPFR 3.1.0+.
>> Try the --with-gmp and/or --with-mpfr options to specify
>> their locations.  If you obtained GMP and/or MPFR from a vendor
>> distribution package, make sure that you have installed both the libraries
>> and the header files.  They may be located in separate packages.
>> shell cmd failed: /bin/sh -ex
>> /usr/home/karel/git/rtems-source-builder/rtems/build/aarch64-rtems7-gdb-22e69d8-x86_64-freebsd13.2-1/do-build
>> error: building aarch64-rtems7-gdb-22e69d8-x86_64-freebsd13.2-1
>>
>> Obviusly gdb from 6/ does not hence there is probably some bit missing in 7/
>> which is already fixed in 6/
> 
> Actually I don't know how this should be handled. Some libraries are added to
> rtems/config/6/rtems-default.bset others seem to be specific tool files. The 
> 7/
> tools should a minimum set of patches. Things should be directly fixed in the
> upstream projects.

We have been moving to build support libraries, such as GMP, separately and not
by links into the source tree of gcc. MacOS M silicon requires a specific option
for GMP to work and this has resulted in us building these libraries before
building the packages that depend on them because the upstream provide no means
to inject specific options. GDB added GMP and it seems more are being added so
we need to add support to build them before GDB and remove the symlink'ing into
the GCC source tree. The GMP change should provide a suitable template for doing
this.

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

2023-07-24 Thread Chris Johns

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

[PATCH] bsps/arm: Fix CMSIS v5 install files list

2023-07-24 Thread chrisj

From: Chris Johns 

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

___
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

On Mon, Jul 24, 2023 at 3:30 PM Karel Gardas 
wrote:

>
>   Hello Kinsey,
>
> honestly I don't know what to do about this patch. Let me explain a bit
> history behind STM32h7. It was originally submitted by embedded brains
> guys (Sebastian main, Christian added few things later) supporting the
> only eval board of that time stm32h743-eval(2). Sebastian also added
> support for nucleo with h743zi and Robin Mueller fixed several things on
> that. So this was 2 boards supported. Then I came and added support for
> 3 more boards where two was with 2 BSPs variants each (one for M7 and
> one for M4). Due to amount of code in #ifdef for various boards we (my
> customer and me) have decided to de-cpp code a bit and divide it into
> different supported board directories. Basically we have also followed a
> lead by embedded brains guys and their imxrt bsps family (and boards
> directory). This was accepted and now you have this boards directory
> with different boards providing just as lean as possible configuration
> in C files sharing some common generic in bspstarthooks.c from start
> subdirectory.
>
> So basically the idea was to avoid complex #ifdefs and rather copy clean
> C files around. (as much as possible, realistically).
>
> Now, your patch seems to be going a bit in reverse direction and I do
> not see clearly the motivation behind it, why do you do that this way?
>
> I mean, you edit peripherals clock for stm32h743-eval(2) board BSP.
> AFAIK this file is not reused on any other BSP variant (different board)
> at all.
> The board in question (stm32h743-eval) supports only UART1 on its
> ST-Link or DB-9 canon connection. The UART1 is shared between those two
> mechanisms, which one is used, you define by jumper placed on the board.
> 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.

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




 Hello Kinsey,

honestly I don't know what to do about this patch. Let me explain a bit 
history behind STM32h7. It was originally submitted by embedded brains 
guys (Sebastian main, Christian added few things later) supporting the 
only eval board of that time stm32h743-eval(2). Sebastian also added 
support for nucleo with h743zi and Robin Mueller fixed several things on 
that. So this was 2 boards supported. Then I came and added support for 
3 more boards where two was with 2 BSPs variants each (one for M7 and 
one for M4). Due to amount of code in #ifdef for various boards we (my 
customer and me) have decided to de-cpp code a bit and divide it into 
different supported board directories. Basically we have also followed a 
lead by embedded brains guys and their imxrt bsps family (and boards 
directory). This was accepted and now you have this boards directory 
with different boards providing just as lean as possible configuration 
in C files sharing some common generic in bspstarthooks.c from start 
subdirectory.


So basically the idea was to avoid complex #ifdefs and rather copy clean 
C files around. (as much as possible, realistically).


Now, your patch seems to be going a bit in reverse direction and I do 
not see clearly the motivation behind it, why do you do that this way?


I mean, you edit peripherals clock for stm32h743-eval(2) board BSP. 
AFAIK this file is not reused on any other BSP variant (different board) 
at all.
The board in question (stm32h743-eval) supports only UART1 on its 
ST-Link or DB-9 canon connection. The UART1 is shared between those two 
mechanisms, which one is used, you define by jumper placed on the board. 
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...


Thanks!
Karel



On 7/24/23 20:28, Kinsey Moore wrote:

This change allows configuration of all enabled UART clocks without
direct modificaton of the exiting BSP.
---
  .../stm/stm32h743i-eval/stm32h7-config-per.c  | 41 +--
  1 file changed, 38 insertions(+), 3 deletions(-)

diff --git a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-per.c 
b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-per.c
index 8ca665915f..dcce247a51 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-per.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-per.c
@@ -32,9 +32,34 @@
  #include 
  
  const RCC_PeriphCLKInitTypeDef stm32h7_config_peripheral_clocks = {

-  .PeriphClockSelection = RCC_PERIPHCLK_RTC | RCC_PERIPHCLK_USART3
-| RCC_PERIPHCLK_FDCAN | RCC_PERIPHCLK_USART1 | RCC_PERIPHCLK_I2C1
-| RCC_PERIPHCLK_USB | RCC_PERIPHCLK_FMC | RCC_PERIPHCLK_RNG,
+  .PeriphClockSelection = RCC_PERIPHCLK_RTC
+| RCC_PERIPHCLK_FDCAN | RCC_PERIPHCLK_I2C1
+| RCC_PERIPHCLK_USB | RCC_PERIPHCLK_FMC | RCC_PERIPHCLK_RNG
+#ifdef STM32H7_CONSOLE_ENABLE_USART1
+| RCC_PERIPHCLK_USART1
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_USART2
+| RCC_PERIPHCLK_USART2
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_USART3
+| RCC_PERIPHCLK_USART3
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_UART4
+| RCC_PERIPHCLK_UART4
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_UART5
+| RCC_PERIPHCLK_UART5
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_USART6
+| RCC_PERIPHCLK_USART6
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_UART7
+| RCC_PERIPHCLK_UART7
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_UART8
+| RCC_PERIPHCLK_UART8
+#endif
+  ,
.PLL2.PLL2M = 3,
.PLL2.PLL2N = 48,
.PLL2.PLL2P = 1,
@@ -53,8 +78,18 @@ const RCC_PeriphCLKInitTypeDef 
stm32h7_config_peripheral_clocks = {
.PLL3.PLL3FRACN = 0,
.FmcClockSelection = RCC_FMCCLKSOURCE_PLL2,
.FdcanClockSelection = RCC_FDCANCLKSOURCE_PLL,
+#if defined(STM32H7_CONSOLE_ENABLE_USART2) \
+  || defined(STM32H7_CONSOLE_ENABLE_USART3) \
+  || defined(STM32H7_CONSOLE_ENABLE_UART4) \
+  || defined(STM32H7_CONSOLE_ENABLE_UART5) \
+  || defined(STM32H7_CONSOLE_ENABLE_UART7) \
+  || defined(STM32H7_CONSOLE_ENABLE_UART8)
.Usart234578ClockSelection = RCC_USART234578CLKSOURCE_D2PCLK1,
+#endif
+#if defined(STM32H7_CONSOLE_ENABLE_USART1) \
+  || defined(STM32H7_CONSOLE_ENABLE_USART6)
.Usart16ClockSelection = RCC_USART16CLKSOURCE_D2PCLK2,
+#endif
.I2c123ClockSelection = RCC_I2C123CLKSOURCE_D2PCLK1,
.UsbClockSelection = RCC_USBCLKSOURCE_PLL3,
.RTCClockSelection = RCC_RTCCLKSOURCE_LSE,


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

Re: [PATCH v1 1/2] bsps/stm32h7: Make UART7 pins configurable

Hi Karel,
I happen to have a board in hand that doesn't nominally use UART7, but has
been reconfigured to use it since the typical USART1 connection was ripped
off of the board. It won't ever have a public BSP, but I'm using the base
stm32h7 BSP with the right options layered on top to get the necessary
functionality. I have a few more pieces that I'm condensing into proper
options that will let me make use of the rest of the board's functionality.

Kinsey

On Mon, Jul 24, 2023 at 3:06 PM Karel Gardas 
wrote:

>
> Hello Kinsey,
>
> I think the patch looks good, although I've not verified precise
> PIN/REGs assignment value. I trust you test this somehow otherwise you
> would not submit it. And this steers my curiosity. The only board (from
> ST Micro) I know which provides connection to UART7 is stm32h735g-dk
> which is not supported by RTEMS due to missing MCU support in old HAL
> code. I submitted new HAL patches last week but they are not in yet. So
> if this is not company secrete let me ask, what board you are using with
> UART7 connection?
>
> Thanks,
> Karel
>
> On 7/24/23 20:28, Kinsey Moore wrote:
> > This change allows for the pins assigned to UART7 to be reconfigured via
> > config.ini.
> > ---
> >   bsps/arm/stm32h7/console/console-uart7-cfg.c|  4 ++--
> >   spec/build/bsps/arm/stm32h7/grp.yml |  4 
> >   .../build/bsps/arm/stm32h7/optuart7gpiopins.yml | 17 +
> >   .../build/bsps/arm/stm32h7/optuart7gpioregs.yml | 17 +
> >   4 files changed, 40 insertions(+), 2 deletions(-)
> >   create mode 100644 spec/build/bsps/arm/stm32h7/optuart7gpiopins.yml
> >   create mode 100644 spec/build/bsps/arm/stm32h7/optuart7gpioregs.yml
> >
> > diff --git a/bsps/arm/stm32h7/console/console-uart7-cfg.c
> b/bsps/arm/stm32h7/console/console-uart7-cfg.c
> > index dca19e652d..2ced4cf9c2 100644
> > --- a/bsps/arm/stm32h7/console/console-uart7-cfg.c
> > +++ b/bsps/arm/stm32h7/console/console-uart7-cfg.c
> > @@ -33,9 +33,9 @@
> >
> >   const stm32h7_uart_config stm32h7_uart7_config = {
> > .gpio = {
> > -.regs = GPIOB,
> > +.regs = STM32H7_UART7_GPIO_REGS,
> >   .config = {
> > -  .Pin = GPIO_PIN_3 | GPIO_PIN_4,
> > +  .Pin = STM32H7_UART7_GPIO_PINS,
> > .Mode = GPIO_MODE_AF_PP,
> > .Pull = GPIO_NOPULL,
> > .Speed = GPIO_SPEED_FREQ_LOW,
> > diff --git a/spec/build/bsps/arm/stm32h7/grp.yml
> b/spec/build/bsps/arm/stm32h7/grp.yml
> > index 595762c665..239df9b898 100644
> > --- a/spec/build/bsps/arm/stm32h7/grp.yml
> > +++ b/spec/build/bsps/arm/stm32h7/grp.yml
> > @@ -106,6 +106,10 @@ links:
> > uid: optusart3gpiopins
> >   - role: build-dependency
> > uid: optusart3gpioregs
> > +- role: build-dependency
> > +  uid: optuart7gpiopins
> > +- role: build-dependency
> > +  uid: optuart7gpioregs
> >   - role: build-dependency
> > uid: optvariant
> >   - role: build-dependency
> > diff --git a/spec/build/bsps/arm/stm32h7/optuart7gpiopins.yml
> b/spec/build/bsps/arm/stm32h7/optuart7gpiopins.yml
> > new file mode 100644
> > index 00..0252bdab7c
> > --- /dev/null
> > +++ b/spec/build/bsps/arm/stm32h7/optuart7gpiopins.yml
> > @@ -0,0 +1,17 @@
> > +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> > +actions:
> > +- get-string: null
> > +- define-unquoted: null
> > +build-type: option
> > +copyrights:
> > +- Copyright (C) 2023 On-Line Applications Research (OAR)
> > +default:
> > +- enabled-by: true
> > +  value: ( GPIO_PIN_3 | GPIO_PIN_4 )
> > +description: |
> > +  GPIO pins used for the UART7 pin configuration.
> > +enabled-by: true
> > +format: '{}'
> > +links: []
> > +name: STM32H7_UART7_GPIO_PINS
> > +type: build
> > diff --git a/spec/build/bsps/arm/stm32h7/optuart7gpioregs.yml
> b/spec/build/bsps/arm/stm32h7/optuart7gpioregs.yml
> > new file mode 100644
> > index 00..16ce3bf526
> > --- /dev/null
> > +++ b/spec/build/bsps/arm/stm32h7/optuart7gpioregs.yml
> > @@ -0,0 +1,17 @@
> > +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> > +actions:
> > +- get-string: null
> > +- define-unquoted: null
> > +build-type: option
> > +copyrights:
> > +- Copyright (C) 2023 On-Line Applications Research (OAR)
> > +default:
> > +- enabled-by: true
> > +  value: GPIOB
> > +description: |
> > +  GPIO registers used for the UART7 pin configuration.
> > +enabled-by: true
> > +format: '{}'
> > +links: []
> > +name: STM32H7_UART7_GPIO_REGS
> > +type: build
>
> ___
> 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 1/2] bsps/stm32h7: Make UART7 pins configurable




Hello Kinsey,

I think the patch looks good, although I've not verified precise 
PIN/REGs assignment value. I trust you test this somehow otherwise you 
would not submit it. And this steers my curiosity. The only board (from 
ST Micro) I know which provides connection to UART7 is stm32h735g-dk 
which is not supported by RTEMS due to missing MCU support in old HAL 
code. I submitted new HAL patches last week but they are not in yet. So 
if this is not company secrete let me ask, what board you are using with 
UART7 connection?


Thanks,
Karel

On 7/24/23 20:28, Kinsey Moore wrote:

This change allows for the pins assigned to UART7 to be reconfigured via
config.ini.
---
  bsps/arm/stm32h7/console/console-uart7-cfg.c|  4 ++--
  spec/build/bsps/arm/stm32h7/grp.yml |  4 
  .../build/bsps/arm/stm32h7/optuart7gpiopins.yml | 17 +
  .../build/bsps/arm/stm32h7/optuart7gpioregs.yml | 17 +
  4 files changed, 40 insertions(+), 2 deletions(-)
  create mode 100644 spec/build/bsps/arm/stm32h7/optuart7gpiopins.yml
  create mode 100644 spec/build/bsps/arm/stm32h7/optuart7gpioregs.yml

diff --git a/bsps/arm/stm32h7/console/console-uart7-cfg.c 
b/bsps/arm/stm32h7/console/console-uart7-cfg.c
index dca19e652d..2ced4cf9c2 100644
--- a/bsps/arm/stm32h7/console/console-uart7-cfg.c
+++ b/bsps/arm/stm32h7/console/console-uart7-cfg.c
@@ -33,9 +33,9 @@
  
  const stm32h7_uart_config stm32h7_uart7_config = {

.gpio = {
-.regs = GPIOB,
+.regs = STM32H7_UART7_GPIO_REGS,
  .config = {
-  .Pin = GPIO_PIN_3 | GPIO_PIN_4,
+  .Pin = STM32H7_UART7_GPIO_PINS,
.Mode = GPIO_MODE_AF_PP,
.Pull = GPIO_NOPULL,
.Speed = GPIO_SPEED_FREQ_LOW,
diff --git a/spec/build/bsps/arm/stm32h7/grp.yml 
b/spec/build/bsps/arm/stm32h7/grp.yml
index 595762c665..239df9b898 100644
--- a/spec/build/bsps/arm/stm32h7/grp.yml
+++ b/spec/build/bsps/arm/stm32h7/grp.yml
@@ -106,6 +106,10 @@ links:
uid: optusart3gpiopins
  - role: build-dependency
uid: optusart3gpioregs
+- role: build-dependency
+  uid: optuart7gpiopins
+- role: build-dependency
+  uid: optuart7gpioregs
  - role: build-dependency
uid: optvariant
  - role: build-dependency
diff --git a/spec/build/bsps/arm/stm32h7/optuart7gpiopins.yml 
b/spec/build/bsps/arm/stm32h7/optuart7gpiopins.yml
new file mode 100644
index 00..0252bdab7c
--- /dev/null
+++ b/spec/build/bsps/arm/stm32h7/optuart7gpiopins.yml
@@ -0,0 +1,17 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- define-unquoted: null
+build-type: option
+copyrights:
+- Copyright (C) 2023 On-Line Applications Research (OAR)
+default:
+- enabled-by: true
+  value: ( GPIO_PIN_3 | GPIO_PIN_4 )
+description: |
+  GPIO pins used for the UART7 pin configuration.
+enabled-by: true
+format: '{}'
+links: []
+name: STM32H7_UART7_GPIO_PINS
+type: build
diff --git a/spec/build/bsps/arm/stm32h7/optuart7gpioregs.yml 
b/spec/build/bsps/arm/stm32h7/optuart7gpioregs.yml
new file mode 100644
index 00..16ce3bf526
--- /dev/null
+++ b/spec/build/bsps/arm/stm32h7/optuart7gpioregs.yml
@@ -0,0 +1,17 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- define-unquoted: null
+build-type: option
+copyrights:
+- Copyright (C) 2023 On-Line Applications Research (OAR)
+default:
+- enabled-by: true
+  value: GPIOB
+description: |
+  GPIO registers used for the UART7 pin configuration.
+enabled-by: true
+format: '{}'
+links: []
+name: STM32H7_UART7_GPIO_REGS
+type: build


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

Re: [PATCH] score: Move _IO_Relax() to new

2023-07-24 Thread Joel Sherrill

On Mon, Jul 24, 2023 at 10:49 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 24.07.23 17:34, Joel Sherrill wrote:
> >
> > What about the other io methods in score like for gcov and hashing?
> > Is there a better location for those?
>
> We could move everything in rtems/score/io.h to rtems/dev/io.h. The gcov
> stuff could be moved to rtems/test-gcov.h.
>

OK. When looking at the score/, those stood out as not being strictly
related
to normal score functionality.

Will moving the gcov stuff to rtems/test-gcov.h still leave it available to
users?
If an application wants coverage, it has to do the same things. Right?

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

[PATCH v1 1/2] bsps/stm32h7: Make UART7 pins configurable

This change allows for the pins assigned to UART7 to be reconfigured via
config.ini.
---
 bsps/arm/stm32h7/console/console-uart7-cfg.c|  4 ++--
 spec/build/bsps/arm/stm32h7/grp.yml |  4 
 .../build/bsps/arm/stm32h7/optuart7gpiopins.yml | 17 +
 .../build/bsps/arm/stm32h7/optuart7gpioregs.yml | 17 +
 4 files changed, 40 insertions(+), 2 deletions(-)
 create mode 100644 spec/build/bsps/arm/stm32h7/optuart7gpiopins.yml
 create mode 100644 spec/build/bsps/arm/stm32h7/optuart7gpioregs.yml

diff --git a/bsps/arm/stm32h7/console/console-uart7-cfg.c 
b/bsps/arm/stm32h7/console/console-uart7-cfg.c
index dca19e652d..2ced4cf9c2 100644
--- a/bsps/arm/stm32h7/console/console-uart7-cfg.c
+++ b/bsps/arm/stm32h7/console/console-uart7-cfg.c
@@ -33,9 +33,9 @@
 
 const stm32h7_uart_config stm32h7_uart7_config = {
   .gpio = {
-.regs = GPIOB,
+.regs = STM32H7_UART7_GPIO_REGS,
 .config = {
-  .Pin = GPIO_PIN_3 | GPIO_PIN_4,
+  .Pin = STM32H7_UART7_GPIO_PINS,
   .Mode = GPIO_MODE_AF_PP,
   .Pull = GPIO_NOPULL,
   .Speed = GPIO_SPEED_FREQ_LOW,
diff --git a/spec/build/bsps/arm/stm32h7/grp.yml 
b/spec/build/bsps/arm/stm32h7/grp.yml
index 595762c665..239df9b898 100644
--- a/spec/build/bsps/arm/stm32h7/grp.yml
+++ b/spec/build/bsps/arm/stm32h7/grp.yml
@@ -106,6 +106,10 @@ links:
   uid: optusart3gpiopins
 - role: build-dependency
   uid: optusart3gpioregs
+- role: build-dependency
+  uid: optuart7gpiopins
+- role: build-dependency
+  uid: optuart7gpioregs
 - role: build-dependency
   uid: optvariant
 - role: build-dependency
diff --git a/spec/build/bsps/arm/stm32h7/optuart7gpiopins.yml 
b/spec/build/bsps/arm/stm32h7/optuart7gpiopins.yml
new file mode 100644
index 00..0252bdab7c
--- /dev/null
+++ b/spec/build/bsps/arm/stm32h7/optuart7gpiopins.yml
@@ -0,0 +1,17 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- define-unquoted: null
+build-type: option
+copyrights:
+- Copyright (C) 2023 On-Line Applications Research (OAR)
+default:
+- enabled-by: true
+  value: ( GPIO_PIN_3 | GPIO_PIN_4 )
+description: |
+  GPIO pins used for the UART7 pin configuration.
+enabled-by: true
+format: '{}'
+links: []
+name: STM32H7_UART7_GPIO_PINS
+type: build
diff --git a/spec/build/bsps/arm/stm32h7/optuart7gpioregs.yml 
b/spec/build/bsps/arm/stm32h7/optuart7gpioregs.yml
new file mode 100644
index 00..16ce3bf526
--- /dev/null
+++ b/spec/build/bsps/arm/stm32h7/optuart7gpioregs.yml
@@ -0,0 +1,17 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- define-unquoted: null
+build-type: option
+copyrights:
+- Copyright (C) 2023 On-Line Applications Research (OAR)
+default:
+- enabled-by: true
+  value: GPIOB
+description: |
+  GPIO registers used for the UART7 pin configuration.
+enabled-by: true
+format: '{}'
+links: []
+name: STM32H7_UART7_GPIO_REGS
+type: build
-- 
2.39.2

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

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

This change allows configuration of all enabled UART clocks without
direct modificaton of the exiting BSP.
---
 .../stm/stm32h743i-eval/stm32h7-config-per.c  | 41 +--
 1 file changed, 38 insertions(+), 3 deletions(-)

diff --git a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-per.c 
b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-per.c
index 8ca665915f..dcce247a51 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-per.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-config-per.c
@@ -32,9 +32,34 @@
 #include 
 
 const RCC_PeriphCLKInitTypeDef stm32h7_config_peripheral_clocks = {
-  .PeriphClockSelection = RCC_PERIPHCLK_RTC | RCC_PERIPHCLK_USART3
-| RCC_PERIPHCLK_FDCAN | RCC_PERIPHCLK_USART1 | RCC_PERIPHCLK_I2C1
-| RCC_PERIPHCLK_USB | RCC_PERIPHCLK_FMC | RCC_PERIPHCLK_RNG,
+  .PeriphClockSelection = RCC_PERIPHCLK_RTC
+| RCC_PERIPHCLK_FDCAN | RCC_PERIPHCLK_I2C1
+| RCC_PERIPHCLK_USB | RCC_PERIPHCLK_FMC | RCC_PERIPHCLK_RNG
+#ifdef STM32H7_CONSOLE_ENABLE_USART1
+| RCC_PERIPHCLK_USART1
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_USART2
+| RCC_PERIPHCLK_USART2
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_USART3
+| RCC_PERIPHCLK_USART3
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_UART4
+| RCC_PERIPHCLK_UART4
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_UART5
+| RCC_PERIPHCLK_UART5
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_USART6
+| RCC_PERIPHCLK_USART6
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_UART7
+| RCC_PERIPHCLK_UART7
+#endif
+#ifdef STM32H7_CONSOLE_ENABLE_UART8
+| RCC_PERIPHCLK_UART8
+#endif
+  ,
   .PLL2.PLL2M = 3,
   .PLL2.PLL2N = 48,
   .PLL2.PLL2P = 1,
@@ -53,8 +78,18 @@ const RCC_PeriphCLKInitTypeDef 
stm32h7_config_peripheral_clocks = {
   .PLL3.PLL3FRACN = 0,
   .FmcClockSelection = RCC_FMCCLKSOURCE_PLL2,
   .FdcanClockSelection = RCC_FDCANCLKSOURCE_PLL,
+#if defined(STM32H7_CONSOLE_ENABLE_USART2) \
+  || defined(STM32H7_CONSOLE_ENABLE_USART3) \
+  || defined(STM32H7_CONSOLE_ENABLE_UART4) \
+  || defined(STM32H7_CONSOLE_ENABLE_UART5) \
+  || defined(STM32H7_CONSOLE_ENABLE_UART7) \
+  || defined(STM32H7_CONSOLE_ENABLE_UART8)
   .Usart234578ClockSelection = RCC_USART234578CLKSOURCE_D2PCLK1,
+#endif
+#if defined(STM32H7_CONSOLE_ENABLE_USART1) \
+  || defined(STM32H7_CONSOLE_ENABLE_USART6)
   .Usart16ClockSelection = RCC_USART16CLKSOURCE_D2PCLK2,
+#endif
   .I2c123ClockSelection = RCC_I2C123CLKSOURCE_D2PCLK1,
   .UsbClockSelection = RCC_USBCLKSOURCE_PLL3,
   .RTCClockSelection = RCC_RTCCLKSOURCE_LSE,
-- 
2.39.2

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

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

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

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

Re: [PATCH] score: Move _IO_Relax() to new


On 24.07.23 17:34, Joel Sherrill wrote:


What about the other io methods in score like for gcov and hashing?
Is there a better location for those?


We could move everything in rtems/score/io.h to rtems/dev/io.h. The gcov 
stuff could be moved to rtems/test-gcov.h.


--
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: Move _IO_Relax() to new

2023-07-24 Thread Joel Sherrill

No comments on this. Thanks and push it.

I think you sent this the day we lost power for 8 hours. :(

What about the other io methods in score like for gcov and hashing?
Is there a better location for those?

--joel

On Mon, Jul 24, 2023 at 10:13 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Joel,
>
> On 18.07.23 09:59, Sebastian Huber wrote:
> > This function is not a super core service.
>
> any comments to this patch?
>
> --
> 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: Move _IO_Relax() to new


Hello Joel,

On 18.07.23 09:59, Sebastian Huber wrote:

This function is not a super core service.


any comments to this patch?

--
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 rtems 2/3] confdefs: Add configure macro for libi2c


On 20.07.23 03:10, Vijay Kumar Banerjee wrote:

Add CONFIGURE_APPLICATION_NEEDS_LIBI2C_DRIVER define


Do we really need this? What happens if an I2C device needs interrupts 
during initialization?


--
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 rtems 1/2] bsps/shared: Add MCP7940M RTC driver

2023-07-24 Thread Christian Mauderer

The MCP7940M is a I2C RTC chip. The new driver uses the dev/i2c API to
support the RTC. It is written with the intention, that the driver can
be adapted to other RTCs with a similar register layout by just
replacing the initialization function.
---
 bsps/include/libchip/mcp7940m-rtc.h | 103 
 bsps/shared/dev/rtc/mcp7940m.c  | 362 
 spec/build/bsps/obj.yml |   2 +
 3 files changed, 467 insertions(+)
 create mode 100644 bsps/include/libchip/mcp7940m-rtc.h
 create mode 100644 bsps/shared/dev/rtc/mcp7940m.c

diff --git a/bsps/include/libchip/mcp7940m-rtc.h 
b/bsps/include/libchip/mcp7940m-rtc.h
new file mode 100644
index 00..266400dfba
--- /dev/null
+++ b/bsps/include/libchip/mcp7940m-rtc.h
@@ -0,0 +1,103 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 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
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef LIBCHIP_MCP7940M_RTC_H
+#define LIBCHIP_MCP7940M_RTC_H
+
+#include 
+#include 
+#include 
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+extern const rtc_fns rtc_mcp7940m_fns;
+bool rtc_mcp7940m_probe(int minor);
+
+/*
+ * It is expected, that the RTC can be accessed as a raw file. A pointer to a
+ * constant string with the name of that device has to be passed to the table
+ * initializer.
+ *
+ * The MCP7940M uses an EEPROM-like interface. So you could for example use the
+ * following initialization:
+ *
+ * Define a context for the RTC somewhere:
+ *
+ *   static struct mcp7940m_rtc rtc_ctx =
+ * MCP7940M_RTC_INITIALIZER("/dev/i2c-1", 0x6F, true);
+ *
+ * Then you can use the following for the RTC_Table:
+ *
+ *   MCP7940M_RTC_TBL_ENTRY("/dev/rtc", _ctx)
+ */
+
+struct mcp7940m_rtc {
+  /** Just initialize with RTEMS_MUTEX_INITIALIZER('mcp7940'). */
+  rtems_mutex mutex;
+
+  /** The path of the I2C bus device. */
+  const char *i2c_bus_path;
+
+  /** I2C address. */
+  uint8_t i2c_addr;
+
+  /** True if a crystal should be used. False if an oscillator is connected. */
+  bool crystal;
+
+  /** Whether the RTC has already been initialized. Used internally. */
+  bool initialized;
+};
+
+#define MCP7940M_RTC_INITIALIZER(i2c_path, i2c_address, has_crystal) { \
+.mutex = RTEMS_MUTEX_INITIALIZER("mcp7940m"), \
+.i2c_bus_path = i2c_path, \
+.i2c_addr = i2c_address, \
+.crystal = has_crystal, \
+.initialized = false, \
+  }
+
+#define MCP7940M_RTC_TBL_ENTRY(dev_name, mcp7940m_rtc_ctx) \
+  { \
+.sDeviceName = dev_name, \
+.deviceType = RTC_CUSTOM, \
+.pDeviceFns = _mcp7940m_fns, \
+.deviceProbe = rtc_mcp7940m_probe, \
+.pDeviceParams = (void *)mcp7940m_rtc_ctx, \
+.ulCtrlPort1 = 0, \
+.ulDataPort = 0, \
+.getRegister = NULL, \
+.setRegister = NULL, \
+  }
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* LIBCHIP_MCP7940M_RTC_H */
diff --git a/bsps/shared/dev/rtc/mcp7940m.c b/bsps/shared/dev/rtc/mcp7940m.c
new file mode 100644
index 00..78a4f21b58
--- /dev/null
+++ b/bsps/shared/dev/rtc/mcp7940m.c
@@ -0,0 +1,362 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 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
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the

[PATCH rtems 2/2] bsps/arm/imx: Enable shared RTC support

2023-07-24 Thread Christian Mauderer

This allows to use a I2C RTC together with this BSP.
---
 spec/build/bsps/arm/imx/bspimx.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/spec/build/bsps/arm/imx/bspimx.yml 
b/spec/build/bsps/arm/imx/bspimx.yml
index 63733dd5a4..51c2413409 100644
--- a/spec/build/bsps/arm/imx/bspimx.yml
+++ b/spec/build/bsps/arm/imx/bspimx.yml
@@ -103,6 +103,7 @@ source:
 - bsps/shared/dev/getentropy/getentropy-cpucounter.c
 - bsps/shared/dev/irq/arm-gicv2.c
 - bsps/shared/dev/irq/arm-gicv2-get-attributes.c
+- bsps/shared/dev/rtc/rtc-support.c
 - bsps/shared/dev/serial/console-termios.c
 - bsps/shared/irq/irq-default-handler.c
 - bsps/shared/start/bsp-fdt.c
-- 
2.35.3

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

Re: [PATCH] bsps/arm: replace CMSIS v4 with CMSIS v5 files

2023-07-24 Thread Christian MAUDERER


Hello Karel,

with this change, it seems that I can't install an ARM BSP anymore. The 
core_cmFunc.h and similar files are missing now. I assume that some old 
headers have to be removed, and new headers added to the yml files. Is 
it necessary to install all the new headers or only some of them?


Best regards

Christian

On 2023-07-13 23:05, Karel Gardas wrote:

CAVEAT: license change from BSD to Apache2 license!

Explanation:
The imported files come from CMSIS v5 project available on:

https://github.com/ARM-software/CMSIS_5/tree/develop

The files imported are located inside the CMSIS/Core/Include
project sub-directory.

The project does not provide any NOTICE file in its root directory nor
in the directory of the imported files.
The NOTICE file and its usage in the Apache 2 license was/is
so far the only issue mentioned in discussion of RTEMS developers/users
when considering inclusion of the code under Apache 2 license
into the RTEMS project.
Since the CMSIS v5 project is free from this legal hinder, we may freely
use it and update files to the latest version.

Technical: the patch replaces code from 2015 with the latest version
which brings quite a lot of bug fixes and most importantly opens
possibilities to support MCUs based on new ARM cores.
---
  bsps/arm/include/cachel1_armv7.h  |  441 +++
  bsps/arm/include/cmsis_compiler.h |  303 ++
  bsps/arm/include/cmsis_gcc.h  | 3592 +
  bsps/arm/include/cmsis_version.h  |   39 +
  bsps/arm/include/core_cm4.h   |  629 ++--
  bsps/arm/include/core_cm7.h   | 4922 ++---
  bsps/arm/include/core_cmFunc.h|   87 -
  bsps/arm/include/core_cmInstr.h   |   88 -
  bsps/arm/include/core_cmSimd.h|   97 -
  bsps/arm/include/mpu_armv7.h  |  275 ++
  10 files changed, 6113 insertions(+), 4360 deletions(-)
  create mode 100644 bsps/arm/include/cachel1_armv7.h
  create mode 100644 bsps/arm/include/cmsis_compiler.h
  create mode 100644 bsps/arm/include/cmsis_version.h
  delete mode 100644 bsps/arm/include/core_cmFunc.h
  delete mode 100644 bsps/arm/include/core_cmInstr.h
  delete mode 100644 bsps/arm/include/core_cmSimd.h
  create mode 100644 bsps/arm/include/mpu_armv7.h


--

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] 6: Use GDB 13.2

Hello Karel,

On 24.07.23 13:15, Karel Gardas wrote:

this together with also libexpat patch builds fine on:

- macOS 13.4.1
- FreeBSD 13.2
- Ubuntu 20.04

thanks for the testing.

btw, recently Joel remarked that gdb from 7/ makes troubles building on
fbsd 12.x. I verified the same on fbsd 13.x and Hesham noted on discord
that he has the same issues on macOS. GBD from 7/rtems-* complains about
missing libmpfr.

error: building aarch64-rtems7-gdb-22e69d8-x86_64-freebsd13.2-1

Obviusly gdb from 6/ does not hence there is probably some bit missing
in 7/ which is already fixed in 6/

Actually I don't know how this should be handled. Some libraries are
added to rtems/config/6/rtems-default.bset others seem to be specific
tool files. The 7/ tools should a minimum set of patches. Things should
be directly fixed in the upstream projects.

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

Re: [PATCH] 6: Use GDB 13.2




Hello Sebastian,

this together with also libexpat patch builds fine on:

- macOS 13.4.1
- FreeBSD 13.2
- Ubuntu 20.04

btw, recently Joel remarked that gdb from 7/ makes troubles building on 
fbsd 12.x. I verified the same on fbsd 13.x and Hesham noted on discord 
that he has the same issues on macOS. GBD from 7/rtems-* complains about 
missing libmpfr.


[...]
checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... no
configure: error: Building GDB requires GMP 4.2+, and MPFR 3.1.0+.
Try the --with-gmp and/or --with-mpfr options to specify
their locations.  If you obtained GMP and/or MPFR from a vendor
distribution package, make sure that you have installed both the libraries
and the header files.  They may be located in separate packages.
shell cmd failed: /bin/sh -ex 
/usr/home/karel/git/rtems-source-builder/rtems/build/aarch64-rtems7-gdb-22e69d8-x86_64-freebsd13.2-1/do-build

error: building aarch64-rtems7-gdb-22e69d8-x86_64-freebsd13.2-1

Obviusly gdb from 6/ does not hence there is probably some bit missing 
in 7/ which is already fixed in 6/


Thanks,
Karel

On 7/24/23 10:54, Sebastian Huber wrote:

Prepare for RTEMS 6.1 release.

Update #4921.
---
  rtems/config/6/rtems-default.bset |  2 +-
  rtems/config/6/rtems-microblaze.bset  |  2 +-
  rtems/config/tools/rtems-gdb-13.2.cfg | 17 +
  3 files changed, 19 insertions(+), 2 deletions(-)
  create mode 100644 rtems/config/tools/rtems-gdb-13.2.cfg

diff --git a/rtems/config/6/rtems-default.bset 
b/rtems/config/6/rtems-default.bset
index b1c81a0..4416c65 100644
--- a/rtems/config/6/rtems-default.bset
+++ b/rtems/config/6/rtems-default.bset
@@ -12,7 +12,7 @@
  %defineifnot with_rtems_dtc  devel/dtc-1.6.1-1
  %defineifnot with_rtems_expatdevel/expat-2.4.8-1
  %defineifnot with_rtems_gmp  devel/gmp-6.2.1
-%defineifnot with_rtems_gdb  tools/rtems-gdb-13.1
+%defineifnot with_rtems_gdb  tools/rtems-gdb-13.2
  %defineifnot with_rtems_binutils tools/rtems-binutils-2.39
  %defineifnot with_rtems_gcc  tools/rtems-gcc-12-newlib-head
  %defineifnot with_rtems_toolstools/rtems-tools-6
diff --git a/rtems/config/6/rtems-microblaze.bset 
b/rtems/config/6/rtems-microblaze.bset
index 95fe17e..1870935 100644
--- a/rtems/config/6/rtems-microblaze.bset
+++ b/rtems/config/6/rtems-microblaze.bset
@@ -13,7 +13,7 @@
  
  devel/expat-2.4.8-1

  devel/gmp-6.2.1
-tools/rtems-gdb-13.1
+tools/rtems-gdb-13.2
  
  tools/rtems-xilinx-binutils-2.36

  tools/rtems-xilinx-gcc-10-newlib-head
diff --git a/rtems/config/tools/rtems-gdb-13.2.cfg 
b/rtems/config/tools/rtems-gdb-13.2.cfg
new file mode 100644
index 000..655ffe2
--- /dev/null
+++ b/rtems/config/tools/rtems-gdb-13.2.cfg
@@ -0,0 +1,17 @@
+#
+# GDB 13.2
+#
+
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define gdb_version 13.2
+%define gdb_src_ext xz
+%hash sha512 gdb-%{gdb_version}.tar.xz \
+   
gYXT4Rq2Da//WGClAWV3v+fddUfvAevIZ7wkdgPYK3T/dMTylJLH0q7lcHb1K+M+KJ9Ma0FKS4cNSzAEkJ9MNA==
+
+%patch add gdb -p1 --rsb-file=gdb-14067-python-config.diff 
https://sourceware.org/bugzilla/attachment.cgi?id=14783=raw
+%hash sha512 gdb-14067-python-config.diff \
+   
HiCV0eQulk0W+G5uu1gCvUn5Ns6bF6RxqOO9kcSi8zpfEHOMzphlOv5cz0IDN5Q8m94na1kRVy++4z6qc43t3w==
+
+%include %{_configdir}/gdb-common-1.cfg


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

[PATCH] 6: Use libexpat 2.5.0

This version contains security fixes.  Prepare for RTEMS 6.1 release.

Update #4921.
---
 bare/config/devel/expat-2.5.0-1.cfg  | 20 
 rtems/config/6/rtems-default.bset|  2 +-
 rtems/config/6/rtems-microblaze.bset |  2 +-
 rtems/config/7/rtems-default.bset|  2 +-
 4 files changed, 23 insertions(+), 3 deletions(-)
 create mode 100644 bare/config/devel/expat-2.5.0-1.cfg

diff --git a/bare/config/devel/expat-2.5.0-1.cfg 
b/bare/config/devel/expat-2.5.0-1.cfg
new file mode 100644
index 000..37188af
--- /dev/null
+++ b/bare/config/devel/expat-2.5.0-1.cfg
@@ -0,0 +1,20 @@
+#
+# Expat 2.5.0
+#
+
+%if %{release} == %{nil}
+%define release 1
+%endif
+
+%include %{_configdir}/base.cfg
+
+%define expat_version 2.5.0
+%define expat_version_dir R_2_5_0
+
+%hash sha512 expat-%{expat_version}.tar.gz \
+  
8f99pfr7R9zW4PDYkoJqum3nZQnISXvAA4LxEJq44qk9OWlD27UiFkVwRJk6Odc3KASK32UNjoPigYntx7eEAg==
+
+#
+# The Expat build instructions. We use 2.xx Release 1.
+#
+%include %{_configdir}/expat-2-1.cfg
diff --git a/rtems/config/6/rtems-default.bset 
b/rtems/config/6/rtems-default.bset
index 4416c65..2f6992f 100644
--- a/rtems/config/6/rtems-default.bset
+++ b/rtems/config/6/rtems-default.bset
@@ -10,7 +10,7 @@
 #  --with-rtems-gcc=tools/rtems-gcc-head-newlib-head
 #
 %defineifnot with_rtems_dtc  devel/dtc-1.6.1-1
-%defineifnot with_rtems_expatdevel/expat-2.4.8-1
+%defineifnot with_rtems_expatdevel/expat-2.5.0-1
 %defineifnot with_rtems_gmp  devel/gmp-6.2.1
 %defineifnot with_rtems_gdb  tools/rtems-gdb-13.2
 %defineifnot with_rtems_binutils tools/rtems-binutils-2.39
diff --git a/rtems/config/6/rtems-microblaze.bset 
b/rtems/config/6/rtems-microblaze.bset
index 1870935..f17c59d 100644
--- a/rtems/config/6/rtems-microblaze.bset
+++ b/rtems/config/6/rtems-microblaze.bset
@@ -11,7 +11,7 @@
 # GDB needs expat so it needs to be built before.
 #
 
-devel/expat-2.4.8-1
+devel/expat-2.5.0-1
 devel/gmp-6.2.1
 tools/rtems-gdb-13.2
 
diff --git a/rtems/config/7/rtems-default.bset 
b/rtems/config/7/rtems-default.bset
index 0a8fcac..3abfd78 100644
--- a/rtems/config/7/rtems-default.bset
+++ b/rtems/config/7/rtems-default.bset
@@ -10,7 +10,7 @@
 #  --with-rtems-gcc=tools/rtems-gcc-head-newlib-head
 #
 %defineifnot with_rtems_dtc  devel/dtc-1.6.1-1
-%defineifnot with_rtems_expatdevel/expat-2.4.8-1
+%defineifnot with_rtems_expatdevel/expat-2.5.0-1
 %defineifnot with_rtems_gmp  devel/gmp-6.2.1
 %defineifnot with_rtems_gdb  tools/rtems-gdb-head
 %defineifnot with_rtems_binutils tools/rtems-binutils-head
-- 
2.35.3

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

[PATCH] 6: Use GDB 13.2

Prepare for RTEMS 6.1 release.

Update #4921.
---
 rtems/config/6/rtems-default.bset |  2 +-
 rtems/config/6/rtems-microblaze.bset  |  2 +-
 rtems/config/tools/rtems-gdb-13.2.cfg | 17 +
 3 files changed, 19 insertions(+), 2 deletions(-)
 create mode 100644 rtems/config/tools/rtems-gdb-13.2.cfg

diff --git a/rtems/config/6/rtems-default.bset 
b/rtems/config/6/rtems-default.bset
index b1c81a0..4416c65 100644
--- a/rtems/config/6/rtems-default.bset
+++ b/rtems/config/6/rtems-default.bset
@@ -12,7 +12,7 @@
 %defineifnot with_rtems_dtc  devel/dtc-1.6.1-1
 %defineifnot with_rtems_expatdevel/expat-2.4.8-1
 %defineifnot with_rtems_gmp  devel/gmp-6.2.1
-%defineifnot with_rtems_gdb  tools/rtems-gdb-13.1
+%defineifnot with_rtems_gdb  tools/rtems-gdb-13.2
 %defineifnot with_rtems_binutils tools/rtems-binutils-2.39
 %defineifnot with_rtems_gcc  tools/rtems-gcc-12-newlib-head
 %defineifnot with_rtems_toolstools/rtems-tools-6
diff --git a/rtems/config/6/rtems-microblaze.bset 
b/rtems/config/6/rtems-microblaze.bset
index 95fe17e..1870935 100644
--- a/rtems/config/6/rtems-microblaze.bset
+++ b/rtems/config/6/rtems-microblaze.bset
@@ -13,7 +13,7 @@
 
 devel/expat-2.4.8-1
 devel/gmp-6.2.1
-tools/rtems-gdb-13.1
+tools/rtems-gdb-13.2
 
 tools/rtems-xilinx-binutils-2.36
 tools/rtems-xilinx-gcc-10-newlib-head
diff --git a/rtems/config/tools/rtems-gdb-13.2.cfg 
b/rtems/config/tools/rtems-gdb-13.2.cfg
new file mode 100644
index 000..655ffe2
--- /dev/null
+++ b/rtems/config/tools/rtems-gdb-13.2.cfg
@@ -0,0 +1,17 @@
+#
+# GDB 13.2
+#
+
+%include %{_configdir}/checks.cfg
+%include %{_configdir}/base.cfg
+
+%define gdb_version 13.2
+%define gdb_src_ext xz
+%hash sha512 gdb-%{gdb_version}.tar.xz \
+   
gYXT4Rq2Da//WGClAWV3v+fddUfvAevIZ7wkdgPYK3T/dMTylJLH0q7lcHb1K+M+KJ9Ma0FKS4cNSzAEkJ9MNA==
+
+%patch add gdb -p1 --rsb-file=gdb-14067-python-config.diff 
https://sourceware.org/bugzilla/attachment.cgi?id=14783=raw
+%hash sha512 gdb-14067-python-config.diff \
+   
HiCV0eQulk0W+G5uu1gCvUn5Ns6bF6RxqOO9kcSi8zpfEHOMzphlOv5cz0IDN5Q8m94na1kRVy++4z6qc43t3w==
+
+%include %{_configdir}/gdb-common-1.cfg
-- 
2.35.3

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

Re: [PATCH] membench: Add memory benchmark programs