Re: [PATCH rtems-lwip] lwip: Split sources into origin directories

2022-06-01 Thread Pavel Pisa 
Dear Vijay,

On Thursday 02 of June 2022 05:56:56 Vijay Kumar Banerjee wrote:
> I have pushed this patch and I would like to add a note regarding that.

thanks for the work and time.

> This patch started interesting discussions about the possible ways to
> organize code from multiple sources. Pavel also raised an issue with
> the directory name "uLan". Since the repository is still in a personal
> area and still in the development stage, we can make rapid changes to
> the repository. We will change the directory name from uLan to
> something that's more suitable,

please no uLAN it is RS-485 protocol. Yes it has and reuses our sysless
firware base project and uses OOMK build system which we use
for build of GNU/Linux, sysless, RTEMS, NuttX and even Windows
applications. Because I used our port of LwIP which uses OMK
build to test it in RTEMS I have named it lwip-omk and because
we use the code in our instruments firmware which use OMK build,
sysless and often uLAN protocol it ended in the repo under
uLAN project.

https://sourceforge.net/p/ulan/lwip-omk/ci/omk-devel/tree/

But using this project name in the case where
OMK buid system is unwanted, there is nor RS-485 connection
and no use of other libraries and bare metal support from
that PiKRON project is so misleading, that I have to insist
to not use uLAN label...

I suggest to have only ports directory at the rtems-lwip
toplevel. We should go through the process to relicense
all (where we are authors or where we can contact author)
to RTEMS mainline acceptable licence. If there is some problematic
driver then it stays in 

  ports/driver/driver_name

directory so it will be separated and license precisely defined
in that directory.

I still see in the driers base only our own tms570_emac.
So what is the plan for integrating others?

It would be great to have there at least two working
ports because then it will be seen how to select them
on the build system level.

Thanks for updating project documentation

https://devel.rtems.org/wiki/Packages/LWIP

There is another task to solve. In the OMK build,
there has been made possible to configure the most
of the LwIP options from the project top level
config.omk and config.target. It should be considered,
how buffers size, count and many other featires will
be configured in actual RSB build. Problem is that
LwIP on targets with little memory (it worked on
256 kB TMS570LS3137) and on the other hand configuration
for some bigger systems as is  Gaisler GR740 or somethink
NOEL-V based can be significantly different when
megabytes of RAM can be used.

By the way, I am presenting at

9th International Workshop on Analogue and Mixed-Signal
Integrated Circuits for Space Applications
https://indico.esa.int/event/388/

and I have met there people from TTTech
and they can have interrest to try RTEMS
even on their TTEthernet space ASIC
internal Leon 2 core. But it is memory
constrained environment so for TCP/IP non-real time
traffic they most probably cannot use BSD stack,
so LwIP + RTEMS can be the option there.

But it is necessary to put project into some
reusable shape. Unfortunately I do not have
time to work on it some intensive way now
and I do not know RSB stuff enough.

On the other hand, if they express real interest,
I can try, if I am able attract some students
from our universitywho can work on the project.
I invest a lot to pass knowledge for their serious
work in this area.

By the way, we have switched our Computer Architectures
course to RISC-V in this run

  https://cw.fel.cvut.cz/wiki/courses/b35apo/en/start

including simulator

  https://github.com/cvut/qtrvsim

and public recording (even English, sorry Czenglish)

  https://www.youtube.com/playlist?list=PLQL6z4JeTTQnTrML7HgagbjdpCtvdyu0M

Best wishes,

Pavel Pisa

==
 PiKRON s.r.o.   Phone/Fax: +420 284684676
 Kankovskeho 1235Phone: +420 234697622
 182 00 Praha 8  WWW:   http://www.pikron.com/
 Czech Republic  e-mail:  pik...@pikron.com
==
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/3] bsps/stm32h7: set default printk instance on nucleo-h743zi BSP to USART3

2022-06-01 Thread Sebastian Huber 

These three patches and the stm32h747i-disco-m4 patch are all right.

--
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-lwip] lwip: Split sources into origin directories

2022-06-01 Thread Vijay Kumar Banerjee 
Hello everyone,

I have pushed this patch and I would like to add a note regarding that.

This patch started interesting discussions about the possible ways to
organize code from multiple sources. Pavel also raised an issue with
the directory name "uLan". Since the repository is still in a personal
area and still in the development stage, we can make rapid changes to
the repository. We will change the directory name from uLan to
something that's more suitable, but for now, I pushed the patch so
that Kinsey can continue working on other patches. There is also a
discussion on the included licenses. I believe that the approach in
that direction will also mature as we keep bringing new patches and
involve the wider community.

Thank you to everyone for providing valuable feedback.

Best regards,
Vijay

On Tue, May 31, 2022 at 8:04 PM Vijay Kumar Banerjee  wrote:
>
> On Tue, May 31, 2022 at 3:13 PM Kinsey Moore  wrote:
> >
> > On 5/12/2022 16:30, Vijay Kumar Banerjee wrote:
> > > On Sat, Apr 16, 2022 at 10:48 AM Pavel Pisa  
> > > wrote:
> > >> Hello Joel,
> > >>
> > >> On Saturday 16 of April 2022 17:26:02 Joel Sherrill wrote:
> > >>> Ok. Any suggestions for a directory name? :)
> > >> I am not in the full sync and I have lost the tracks where
> > >> are all RTEMS LwIP repo copies.
> > >>
> > >> Do we speak about https://git.rtems.org/vijay/rtems-lwip.git ?
> > >>
> > > Yes
> > Given that a better directory name doesn't appear to be forthcoming, is
> > there anything else preventing this patch from going in as a starting
> > point to further improvements?
> > >
> > >> If it is that way then LwIP uses practice to put integration
> > >> stuff into "ports" directory so I would leave the structure
> > >> under LwIP as it is
> > >>
> > >>ports/os/rtems/arch/sys_arch.c
> > >>
> > >> Or if you want to somehow separate sources into more repos
> > >> then possible but would complicate keep the drivers and targets
> > >> in a sync in future.  I am losing tracks of the build tools etc...
> > >> I hope that when it settles the simple instructions
> > >> would be added on the integration page
> > >>
> > >>https://devel.rtems.org/wiki/Packages/LWIP
> > >>
> > >> If you need to move ports/os/rtems/arch/sys_arch.c under some directory,
> > >> then it should be something like
> > >>
> > >>rtems-support/ports/os/rtems/arch/sys_arch.c
> > >>
> > > This would be a good idea. We can put all RTEMS-related ports into a
> > > separate directory. If there's any driver-specific port, that can also
> > > be added there and waf can be taught to pick up the right one
> > > according to the target.
> > I'm about to start some additional work for lwIP support on ZynqMP. I'll
> > see about breaking any code written specifically by RTEMS developers
> > (just Vijay at this point) into a rtemslwip directory (similar to
> > rtemsbsd in rtems-libbsd).
>
> I will push this into the repository so that we can keep working on it
> incrementally.
>
> Thank you.
> > >
> > >> if the code can be used over all RTEMS targets. Which should be
> > >> a goal anyway and I have initiated it such way years ago.
> > >> But I am not sure why to not let code in the actual
> > >> lwip/ports/drivers together as well. I see that
> > >> in devel branch is the most of our TMS570 code wiped
> > >> out... hmm.. why. There is
> > >>
> > >>   lwip/ports/drivers/bbb
> > >>
> > >> this location seems to me as OK.
> > >> In the suggested changes is
> > >>
> > >> {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/phy_dp83848h.c
> > >>
> > >> I agree with move of all TMS570 specific code under
> > >>
> > >>/ports/driver/tms570_emac
> > >>
> > > I agree with this approach, as it allows adding sources with
> > > problematic license (like STM) into its own directory and a warning
> > > can be added to waf while building those targets.
> > >
> > >> Again if all these shuffles are done only for some license changes
> > >> I would prefer to be noticed and I think that I would not be blocked
> > >> by any of my former studnets nor the faculty to relicense code.
> > >> I would inform the faculty (where I am only left from former group,
> > >> where I have lead part of this development, part was at my company)
> > >> as well as students.
> > >>
> > >> I would prefer if real developer names who invested time into work
> > >> are included at least as Authors in the files but the copyright can
> > >> be moved to RTEMS foundation or whatever.
> > >>
> > >> But as I have said I have lost track and hope that stuff will survive
> > >> in some form till the time when I have some free time or studnet
> > >> to work on the project as his/her theses, GSoC etc...
> > >> I have used the code with external OMK make, I agree that this
> > >> is not right way forward but I wait for outcome of these who
> > >> have more experience with RSB and related tools and propose
> > >> integration.
> >
> > As long as the code is licensed appropriately for inclusion in this
> > project, I see no

[PATCH 3/3] bsps/stm32h7: set SDRAM 1 size to 0 by default on nucleo-h743zi BSP

2022-06-01 Thread Karel Gardas 
Nucleo does not have any SDRAM, so 0 size is the only possible right
choice here.

Sponsored-By:   Precidata
---
 spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml 
b/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml
index ed5cf8737b..9a29e9f04f 100644
--- a/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml
+++ b/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml
@@ -11,6 +11,7 @@ default-by-variant:
   - arm/stm32h757i-eval-m4
   - arm/stm32h747i-disco
   - arm/stm32h747i-disco-m4
+  - arm/nucleo-h743zi
 enabled-by: true
 format: '{:#010x}'
 links: []
-- 
2.25.1

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

[PATCH 2/3] bsps/stm32h7: set default linkage to flash for nucleo-h743zi BSP

2022-06-01 Thread Karel Gardas 
Nucleo does not have any SDRAM so default linkage to SDRAM does not make
any sense here.

Sponsored-By:   Precidata
---
 spec/build/bsps/arm/stm32h7/optlinkcmds.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/spec/build/bsps/arm/stm32h7/optlinkcmds.yml 
b/spec/build/bsps/arm/stm32h7/optlinkcmds.yml
index 197b384d03..3103deef84 100644
--- a/spec/build/bsps/arm/stm32h7/optlinkcmds.yml
+++ b/spec/build/bsps/arm/stm32h7/optlinkcmds.yml
@@ -11,6 +11,7 @@ default-by-variant:
   - arm/stm32h757i-eval-m4
   - arm/stm32h747i-disco
   - arm/stm32h747i-disco-m4
+  - arm/nucleo-h743zi
 enabled-by: true
 format: '{}'
 links: []
-- 
2.25.1

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

[PATCH 1/3] bsps/stm32h7: set default printk instance on nucleo-h743zi BSP to USART3

2022-06-01 Thread Karel Gardas 
This is the default configuration of the board out of the box.
Any other possible/supported configuration requires soldering,
so definitely not out of the box experience.

Sponsored-By:   Precidata
---
 spec/build/bsps/arm/stm32h7/optprintkinstance.yml | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/spec/build/bsps/arm/stm32h7/optprintkinstance.yml 
b/spec/build/bsps/arm/stm32h7/optprintkinstance.yml
index 6eaf4a2011..5e87aaab1f 100644
--- a/spec/build/bsps/arm/stm32h7/optprintkinstance.yml
+++ b/spec/build/bsps/arm/stm32h7/optprintkinstance.yml
@@ -3,7 +3,10 @@ actions:
 - define-unquoted: null
 build-type: option
 default: stm32h7_usart1_instance
-default-by-variant: []
+default-by-variant:
+- value: stm32h7_usart3_instance
+  variants:
+  - arm/nucleo-h743zi
 enabled-by: true
 format: '{}'
 links: []
-- 
2.25.1

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

[PATCH] bsps/stm32h7: add stm32h747i-disco-m4 BSP variant

2022-06-01 Thread Karel Gardas 
This patch adds stm32h747i-disco-m4 BSP variant and puts it in sync
with the stm32h747i-disco BSP variant hardware support. That means,
only USART 1, 2 and UART 8 are enabled. Also SDRAM 2 is set to 32MB,
SDRAM 1 size is set to 0.

Sponsored-By:   Precidata
---
 spec/build/bsps/arm/stm32h7/abi.yml   |  1 +
 .../arm/stm32h7/bspstm32h747i-disco-m4.yml| 24 +++
 spec/build/bsps/arm/stm32h7/optbootcore.yml   |  1 +
 spec/build/bsps/arm/stm32h7/optenuart4.yml|  1 +
 spec/build/bsps/arm/stm32h7/optenuart5.yml|  1 +
 spec/build/bsps/arm/stm32h7/optenuart7.yml|  1 +
 spec/build/bsps/arm/stm32h7/optenuart9.yml|  1 +
 spec/build/bsps/arm/stm32h7/optenusart10.yml  |  1 +
 spec/build/bsps/arm/stm32h7/optenusart3.yml   |  1 +
 spec/build/bsps/arm/stm32h7/optenusart6.yml   |  1 +
 spec/build/bsps/arm/stm32h7/optlinkcmds.yml   |  1 +
 .../bsps/arm/stm32h7/optmemflashorigin.yml|  1 +
 spec/build/bsps/arm/stm32h7/optmemflashsz.yml |  1 +
 .../build/bsps/arm/stm32h7/optmemsdram1sz.yml |  1 +
 .../build/bsps/arm/stm32h7/optmemsdram2sz.yml |  1 +
 spec/build/bsps/arm/stm32h7/optpwrsupply.yml  |  1 +
 .../arm/stm32h7/optusart1alternatefunc.yml|  1 +
 .../bsps/arm/stm32h7/optusart1gpiopins.yml|  1 +
 .../bsps/arm/stm32h7/optusart1gpioregs.yml|  1 +
 spec/build/bsps/arm/stm32h7/optvariant.yml|  1 +
 20 files changed, 43 insertions(+)
 create mode 100644 spec/build/bsps/arm/stm32h7/bspstm32h747i-disco-m4.yml

diff --git a/spec/build/bsps/arm/stm32h7/abi.yml 
b/spec/build/bsps/arm/stm32h7/abi.yml
index dd751cb72e..38cb179707 100644
--- a/spec/build/bsps/arm/stm32h7/abi.yml
+++ b/spec/build/bsps/arm/stm32h7/abi.yml
@@ -16,6 +16,7 @@ default-by-variant:
   - -mfloat-abi=hard
   variants:
   - arm/stm32h757i-eval-m4
+  - arm/stm32h747i-disco-m4
 enabled-by: true
 links: []
 name: ABI_FLAGS
diff --git a/spec/build/bsps/arm/stm32h7/bspstm32h747i-disco-m4.yml 
b/spec/build/bsps/arm/stm32h7/bspstm32h747i-disco-m4.yml
new file mode 100644
index 00..6356ccf942
--- /dev/null
+++ b/spec/build/bsps/arm/stm32h7/bspstm32h747i-disco-m4.yml
@@ -0,0 +1,24 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+arch: arm
+bsp: stm32h747i-disco-m4
+build-type: bsp
+cflags: []
+copyrights:
+- Copyright (C) 2022 Karel Gardas 
+cppflags: []
+enabled-by: true
+family: stm32h7
+includes: []
+install: []
+links:
+- role: build-dependency
+  uid: grp
+- role: build-dependency
+  uid: tststm32h757i-eval
+source:
+- bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-config-clk.c
+- bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-config-osc.c
+- bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-config-per.c
+- bsps/arm/stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c
+- bsps/shared/cache/nocache.c
+type: build
diff --git a/spec/build/bsps/arm/stm32h7/optbootcore.yml 
b/spec/build/bsps/arm/stm32h7/optbootcore.yml
index 6d1a500ede..2a0c5504f8 100644
--- a/spec/build/bsps/arm/stm32h7/optbootcore.yml
+++ b/spec/build/bsps/arm/stm32h7/optbootcore.yml
@@ -15,6 +15,7 @@ default-by-variant:
 - value: CORE_CM4
   variants:
   - arm/stm32h757i-eval-m4
+  - arm/stm32h747i-disco-m4
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenuart4.yml 
b/spec/build/bsps/arm/stm32h7/optenuart4.yml
index d165f4144e..11cdb1088c 100644
--- a/spec/build/bsps/arm/stm32h7/optenuart4.yml
+++ b/spec/build/bsps/arm/stm32h7/optenuart4.yml
@@ -9,6 +9,7 @@ default-by-variant:
   - arm/stm32h757i-eval
   - arm/stm32h757i-eval-m4
   - arm/stm32h747i-disco
+  - arm/stm32h747i-disco-m4
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenuart5.yml 
b/spec/build/bsps/arm/stm32h7/optenuart5.yml
index f691d9bbc4..722ebb2bdf 100644
--- a/spec/build/bsps/arm/stm32h7/optenuart5.yml
+++ b/spec/build/bsps/arm/stm32h7/optenuart5.yml
@@ -10,6 +10,7 @@ default-by-variant:
   - arm/stm32h757i-eval
   - arm/stm32h757i-eval-m4
   - arm/stm32h747i-disco
+  - arm/stm32h747i-disco-m4
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenuart7.yml 
b/spec/build/bsps/arm/stm32h7/optenuart7.yml
index dc160d31dc..c4cef258c0 100644
--- a/spec/build/bsps/arm/stm32h7/optenuart7.yml
+++ b/spec/build/bsps/arm/stm32h7/optenuart7.yml
@@ -10,6 +10,7 @@ default-by-variant:
   - arm/stm32h757i-eval
   - arm/stm32h757i-eval-m4
   - arm/stm32h747i-disco
+  - arm/stm32h747i-disco-m4
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenuart9.yml 
b/spec/build/bsps/arm/stm32h7/optenuart9.yml
index aec036bd22..009766e291 100644
--- a/spec/build/bsps/arm/stm32h7/optenuart9.yml
+++ b/spec/build/bsps/arm/stm32h7/optenuart9.yml
@@ -10,6 +10,7 @@ default-by-variant:
   - arm/stm32h757i-eval
   - arm/stm32h757i-eval-m4
   - arm/stm32h747i-disco
+  - arm/stm32h747i-disco-m4
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenusart10.yml 
b/spec/build/bsps/arm/stm32h7/optenu

Re: [PATCH] devel/spike-1.0.0: bump hash

2022-06-01 Thread Ryan Long 



On 6/1/2022 7:36 AM, Gedare Bloom wrote:

What/Why did this change? Where we not using a release before?
I'm not sure. Their Github only shows two releases. One's from 2019 and 
the latest is from late 2021. The last time the hash was bumped was in 
2020 by Joel, so I'm guessing that was changing it to the 1.0.0 release, 
and this just bumps it to 1.1.0. Maybe it was in beta at the time.


Looks ok otherwise.

On Wed, May 25, 2022 at 12:31 PM Ryan Long  wrote:

Bump the hash of spike to match the 1.1.0 release

Closes #4660
---
  bare/config/devel/spike-1.1.0.cfg | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/bare/config/devel/spike-1.1.0.cfg 
b/bare/config/devel/spike-1.1.0.cfg
index 644b754..73cf3c2 100644
--- a/bare/config/devel/spike-1.1.0.cfg
+++ b/bare/config/devel/spike-1.1.0.cfg
@@ -8,9 +8,9 @@

  %include %{_configdir}/base.cfg

-%define spike_version 66b44bfbedda562a32e4a2cd0716afbf731b69cd
+%define spike_version 530af85d83781a3dae31a4ace84a573ec255fefa

-%hash sha512 spike-%{spike_version}.tar.gz 
a98fc9e564edb3bb471f04063484a5d056befb8b2258b96de2d238cf27d1d5544c2782c91c7731b8f0aa03012eb3d39de33e4f30927349e38c7e131e8241b92f
+%hash sha512 spike-%{spike_version}.tar.gz 
D+9XugRwrZJ8undjx3x3CILr4VSdeaNsTTUZYeENFPZy6MG7TiQAY5umaUr/oOr6vWCq7YjFhqwjPI+fcieqYw==

  #
  # The spike build instructions. We use 1.x.x Release 1.
--
2.30.2

___
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] cpukit/libmisc/capture: fix capture bug

2022-06-01 Thread Gedare Bloom 
On Mon, May 23, 2022 at 1:40 AM  wrote:
>
> From: Tian Ye 
>
What is the bug this fixes? Is there an open ticket for it?

> ---
>  cpukit/libmisc/capture/capture.c | 30 
>  cpukit/libmisc/capture/capture_support.c |  8 +--
>  2 files changed, 32 insertions(+), 6 deletions(-)
>
> diff --git a/cpukit/libmisc/capture/capture.c 
> b/cpukit/libmisc/capture/capture.c
> index 2228d135b8..886b4f62ed 100644
> --- a/cpukit/libmisc/capture/capture.c
> +++ b/cpukit/libmisc/capture/capture.c
> @@ -292,6 +292,23 @@ rtems_capture_find_control (rtems_name name, rtems_id id)
>return control;
>  }
>
> +static bool
> +rtems_capture_uninitialize_control (rtems_tcb *tcb, void *arg)
> +{
> +rtems_name name = rtems_build_name(0, 0, 0, 0);
> +rtems_id   id;
> +
> +id = tcb->Object.id;
> +if (rtems_capture_task_api (id) != OBJECTS_POSIX_API)
> +rtems_object_get_classic_name (id, &name);
> +if (rtems_capture_match_name_id (((rtems_capture_control *)arg)->name,
> +((rtems_capture_control *)arg)->id, name, id))
> +{
> +tcb->Capture.control = NULL;

Should this 'return true' to short-circuit the thread_iterate?

> +}
> +return false;
> +}
> +
>  /*
>   * This function checks if a new control structure matches
>   * the given task and sets the control if it does.
> @@ -699,6 +716,7 @@ rtems_capture_close (void)
>{
>  rtems_capture_control* delete = control;
>  control = control->next;
> +_Thread_Iterate (rtems_capture_uninitialize_control, (void *)delete);
>  free (delete);
>}
>
> @@ -789,6 +807,7 @@ rtems_capture_flush (bool prime)
>{
>  rtems_interrupt_lock_context lock_context_global;
>  uint32_t cpu;
> +uint32_t*cpu_flags;
>
>  rtems_interrupt_lock_acquire (&capture_lock_global, 
> &lock_context_global);
>
> @@ -800,16 +819,17 @@ rtems_capture_flush (bool prime)
>
>  _Thread_Iterate (rtems_capture_flush_tcb, NULL);
>
> -if (prime)
> -  capture_flags_global &= ~(RTEMS_CAPTURE_TRIGGERED | 
> RTEMS_CAPTURE_OVERFLOW);
> -else
> -  capture_flags_global &= ~RTEMS_CAPTURE_OVERFLOW;
> +if (prime) {
> +  capture_flags_global &= ~RTEMS_CAPTURE_TRIGGERED;
> +}

I don't know what this (and following) change is doing.

>
>  for (cpu=0; cpu < rtems_scheduler_get_processor_maximum(); cpu++) {
>RTEMS_INTERRUPT_LOCK_REFERENCE( lock, &(capture_lock_on_cpu( cpu )) )
>rtems_interrupt_lock_context lock_context_per_cpu;
>
>rtems_interrupt_lock_acquire (lock, &lock_context_per_cpu);
> +  cpu_flags = &(capture_flags_on_cpu (cpu));
> +  *cpu_flags &= ~RTEMS_CAPTURE_OVERFLOW;
>capture_count_on_cpu(cpu) = 0;
>if (capture_records_on_cpu(cpu).buffer)
>  rtems_capture_buffer_flush( &capture_records_on_cpu(cpu) );
> @@ -885,6 +905,8 @@ rtems_capture_watch_del (rtems_name name, rtems_id id)
>
>*prev_control = control->next;
>
> +  _Thread_Iterate (rtems_capture_uninitialize_control, (void *)control);
> +
>rtems_interrupt_lock_release (&capture_lock_global, &lock_context);
>
>free (control);
> diff --git a/cpukit/libmisc/capture/capture_support.c 
> b/cpukit/libmisc/capture/capture_support.c
> index 5b685479d7..fb4ccfe2d8 100644
> --- a/cpukit/libmisc/capture/capture_support.c
> +++ b/cpukit/libmisc/capture/capture_support.c
> @@ -247,7 +247,7 @@ rtems_capture_print_record_capture(int
>  cpu,
>  {
>fprintf(stdout,"%2i ", cpu);
>rtems_capture_print_timestamp (rec->time);
> -  fprintf (stdout, " %12" PRId32 " ", (uint32_t) diff);
> +  fprintf (stdout, " %12" PRIu32 " ", (uint32_t) diff);
>rtems_monitor_dump_id (rec->task_id);
>if (name != NULL)
>{
> @@ -439,7 +439,11 @@ rtems_capture_print_watch_list (void)
>  fprintf (stdout, " ");
>  rtems_monitor_dump_id (rtems_capture_control_id (control));
>  fprintf (stdout, " ");
> -rtems_monitor_dump_name (rtems_capture_control_name (control));
> +char name[5] = "";

This should be declared at the start of the block/function.

> +if (rtems_capture_control_name(control) != 0) {
> +_Objects_Name_to_string((Objects_Name)rtems_capture_control_name 
> (control), false, name, 5);
This line is too long, although there are other style problems
throughout this patch. Hopefully we'll have automation to help that.
Also, I'd prefer sizeof() or a const/define macro value instead of the
hard-coded 5.

> +}
> +fprintf(stdout, "%s", name);
>  flags = rtems_capture_control_flags (control);
>  fprintf (stdout, " %c%c ",
>   rtems_capture_watch_global_on () ? 'g' : '-',
> --
> 2.25.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing

Re: [PATCH rtems] bsps/atsam: Fix type of options

2022-06-01 Thread Gedare Bloom 
ok

On Mon, May 23, 2022 at 6:16 AM Christian Mauderer
 wrote:
>
> ATSAM_CONSOLE_DEVICE_INDEX and ATSAM_CONSOLE_DEVICE_TYPE have to be
> integers like suggested by their description. Otherwise it's not
> possible to select (for example) USART2 as console device.
> ---
>  spec/build/bsps/arm/atsam/optconidx.yml  | 4 ++--
>  spec/build/bsps/arm/atsam/optcontype.yml | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/spec/build/bsps/arm/atsam/optconidx.yml 
> b/spec/build/bsps/arm/atsam/optconidx.yml
> index 42fb3b142a..1c0723c594 100644
> --- a/spec/build/bsps/arm/atsam/optconidx.yml
> +++ b/spec/build/bsps/arm/atsam/optconidx.yml
> @@ -1,11 +1,11 @@
>  SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  actions:
> -- get-boolean: null
> +- get-integer: null
>  - define-condition: null
>  build-type: option
>  copyrights:
>  - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> -default: true
> +default: 1
>  default-by-variant: []
>  description: |
>device index for /dev/console (default 1, e.g. USART1)
> diff --git a/spec/build/bsps/arm/atsam/optcontype.yml 
> b/spec/build/bsps/arm/atsam/optcontype.yml
> index eddbee1063..fd0daa8999 100644
> --- a/spec/build/bsps/arm/atsam/optcontype.yml
> +++ b/spec/build/bsps/arm/atsam/optcontype.yml
> @@ -1,11 +1,11 @@
>  SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>  actions:
> -- get-boolean: null
> +- get-integer: null
>  - define-condition: null
>  build-type: option
>  copyrights:
>  - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> -default: false
> +default: 0
>  default-by-variant: []
>  description: |
>device type for /dev/console, use 0 for USART and 1 for UART (default 
> USART)
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd 2/2] if_ffec: Allow PHY that is connected to other FFEC

2022-06-01 Thread Gedare Bloom 
Should this be upstreamed?

On Mon, May 23, 2022 at 6:22 AM Christian Mauderer
 wrote:
>
> The i.MX6UL (and some others from the i.MX family) have shared MDIO
> lines for multiple FFECs. This patch allows to use the MDIO interface
> from another Ethernet controller.
>
> Note that you have to make sure that the FFECs are initialized in the
> right order. Normally that can be done via FDT.
> ---
>  freebsd/sys/dev/ffec/if_ffec.c | 120 +
>  1 file changed, 120 insertions(+)
>
> diff --git a/freebsd/sys/dev/ffec/if_ffec.c b/freebsd/sys/dev/ffec/if_ffec.c
> index 4c1e147b..316e077c 100644
> --- a/freebsd/sys/dev/ffec/if_ffec.c
> +++ b/freebsd/sys/dev/ffec/if_ffec.c
> @@ -209,6 +209,11 @@ struct ffec_softc {
> int rx_ic_count;/* RW, valid values 0..255 */
> int tx_ic_time;
> int tx_ic_count;
> +#ifdef __rtems__
> +
> +   device_tmdio_device;
> +   struct mtx  mdio_mtx;
> +#endif /* __rtems__ */
>  };
>
>  static struct resource_spec irq_res_spec[MAX_IRQ_COUNT + 1] = {
> @@ -376,6 +381,13 @@ ffec_miibus_readreg(device_t dev, int phy, int reg)
> int val;
>
> sc = device_get_softc(dev);
> +#ifdef __rtems__
> +   if (sc->mdio_device) {
> +   return (MIIBUS_READREG(sc->mdio_device, phy, reg));
> +   }
> +
> +   mtx_lock(&sc->mdio_mtx);
> +#endif /* __rtems__ */
>
> WR4(sc, FEC_IER_REG, FEC_IER_MII);
>
> @@ -386,11 +398,17 @@ ffec_miibus_readreg(device_t dev, int phy, int reg)
>
> if (!ffec_miibus_iowait(sc)) {
> device_printf(dev, "timeout waiting for mii read\n");
> +#ifdef __rtems__
> +   mtx_unlock(&sc->mdio_mtx);
> +#endif /* __rtems__ */
> return (-1); /* All-ones is a symptom of bad mdio. */
> }
>
> val = RD4(sc, FEC_MMFR_REG) & FEC_MMFR_DATA_MASK;
>
> +#ifdef __rtems__
> +   mtx_unlock(&sc->mdio_mtx);
> +#endif /* __rtems__ */
> return (val);
>  }
>
> @@ -400,6 +418,13 @@ ffec_miibus_writereg(device_t dev, int phy, int reg, int 
> val)
> struct ffec_softc *sc;
>
> sc = device_get_softc(dev);
> +#ifdef __rtems__
> +   if (sc->mdio_device) {
> +   return (MIIBUS_WRITEREG(sc->mdio_device, phy, reg, val));
> +   }
> +
> +   mtx_lock(&sc->mdio_mtx);
> +#endif /* __rtems__ */
>
> WR4(sc, FEC_IER_REG, FEC_IER_MII);
>
> @@ -411,9 +436,15 @@ ffec_miibus_writereg(device_t dev, int phy, int reg, int 
> val)
>
> if (!ffec_miibus_iowait(sc)) {
> device_printf(dev, "timeout waiting for mii write\n");
> +#ifdef __rtems__
> +   mtx_unlock(&sc->mdio_mtx);
> +#endif /* __rtems__ */
> return (-1);
> }
>
> +#ifdef __rtems__
> +   mtx_unlock(&sc->mdio_mtx);
> +#endif /* __rtems__ */
> return (0);
>  }
>
> @@ -1577,6 +1608,9 @@ ffec_detach(device_t dev)
> if (sc->mem_res != NULL)
> bus_release_resource(dev, SYS_RES_MEMORY, 0, sc->mem_res);
>
> +#ifdef __rtems__
> +   mtx_destroy(&sc->mtx);
> +#endif /* __rtems__ */
> FFEC_LOCK_DESTROY(sc);
> return (0);
>  }
> @@ -1726,6 +1760,80 @@ ffec_set_txic(struct ffec_softc *sc)
> ffec_set_ic(sc, FEC_TXIC0_REG, sc->tx_ic_count, sc->tx_ic_time);
>  }
>
> +#ifdef __rtems__
> +int
> +ffec_get_phy_information(
> +   struct ffec_softc *sc,
> +   phandle_t node,
> +   device_t dev,
> +   int *phy_addr
> +)
> +{
> +   phandle_t phy_node;
> +   phandle_t parent_node;
> +   pcell_t phy_handle, phy_reg;
> +   device_t other;
> +   phandle_t xref;
> +
> +   /* Search for the phy-handle and get the address */
> +
> +   if (OF_getencprop(node, "phy-handle", (void *)&phy_handle,
> +   sizeof(phy_handle)) <= 0)
> +   return (ENXIO);
> +
> +   phy_node = OF_node_from_xref(phy_handle);
> +
> +   if (OF_getencprop(phy_node, "reg", (void *)&phy_reg,
> +   sizeof(phy_reg)) <= 0)
> +   return (ENXIO);
> +
> +   *phy_addr = phy_reg;
> +
> +   /* Detect whether PHY handle is connected to this or another FFEC. */
> +   parent_node = phy_node;
> +
> +   while (parent_node != 0) {
> +   if (parent_node == node) {
> +   /* PHY is directly connected. That's easy. */
> +   sc->mdio_device = NULL;
> +   return 0;
> +   }
> +
> +   /*
> +* Check whether the node is also an Ethernet controller. Do
> +* that by just assuming that every Ethernet controller has a
> +* PHY attached to it.
> +*/
> +   if (OF_getencprop(parent_node, "phy-handle",
> +   (void *)&phy_handle, sizeof(phy_handle)) > 0) {
> +   /*
> +* Try to find the device of the other Ethernet
> +

Re: [PATCH rtems-libbsd 1/2] if_ffec: Reduce buffer size

2022-06-01 Thread Gedare Bloom 
On Mon, May 23, 2022 at 6:21 AM Christian Mauderer
 wrote:
>
> Typical embedded systems don't have that much memory. Reduce the buffer
> size to something more sensible for the usual type of application.
> ---
>  freebsd/sys/dev/ffec/if_ffec.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/freebsd/sys/dev/ffec/if_ffec.c b/freebsd/sys/dev/ffec/if_ffec.c
> index 47c0f770..4c1e147b 100644
> --- a/freebsd/sys/dev/ffec/if_ffec.c
> +++ b/freebsd/sys/dev/ffec/if_ffec.c
> @@ -139,9 +139,17 @@ static struct ofw_compat_data compat_data[] = {
>  /*
>   * Driver data and defines.  The descriptor counts must be a power of two.
>   */
> +#ifndef __rtems__
>  #defineRX_DESC_COUNT   512
> +#else /* __rtems__ */
> +#defineRX_DESC_COUNT   64
> +#endif /* __rtems__ */

Do we need some way to control this parameter? Or, how will this
appear if it breaks something?

>  #defineRX_DESC_SIZE(sizeof(struct ffec_hwdesc) * RX_DESC_COUNT)
> +#ifndef __rtems__
>  #defineTX_DESC_COUNT   512
> +#else /* __rtems__ */
> +#defineTX_DESC_COUNT   64
> +#endif /* __rtems__ */
>  #defineTX_DESC_SIZE(sizeof(struct ffec_hwdesc) * TX_DESC_COUNT)
>  #defineTX_MAX_DMA_SEGS 8
>
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems] bsps/imx: Enable clock of ETH2

2022-06-01 Thread Gedare Bloom 
On Mon, May 23, 2022 at 6:22 AM Christian Mauderer
 wrote:
>
> ---
>  bsps/arm/imx/start/bspstart.c | 13 +
>  1 file changed, 13 insertions(+)
>
> diff --git a/bsps/arm/imx/start/bspstart.c b/bsps/arm/imx/start/bspstart.c
> index 04d48d1558..e9cca49200 100644
> --- a/bsps/arm/imx/start/bspstart.c
> +++ b/bsps/arm/imx/start/bspstart.c
> @@ -161,6 +161,18 @@ static void imx_find_gic(const void *fdt)
>  #endif
>  }
>
> +static void imx_ccm_enable_eth2_clk(void)
> +{
> +  const void *fdt = bsp_fdt_get();
> +
> +  if (imx_is_imx6(fdt)) {
> +volatile uint32_t *ccm_pll_enet_set = (void *)0x020c80e4;
Should this magic address be a #define somewhere?

> +const uint32_t ccm_pll_enet_enet2_125m_en = (1 << 20);
> +
> +*ccm_pll_enet_set = ccm_pll_enet_enet2_125m_en;
> +  }
> +}
> +
>  void bsp_start(void)
>  {
>imx_find_gic(bsp_fdt_get());
> @@ -169,4 +181,5 @@ void bsp_start(void)
>  bsp_section_nocacheheap_begin,
>  (uintptr_t) bsp_section_nocacheheap_size
>);
> +  imx_ccm_enable_eth2_clk();
>  }
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] user: Document Zynq network

2022-06-01 Thread Gedare Bloom 
ok

On Mon, May 23, 2022 at 7:13 AM Sebastian Huber
 wrote:
>
> Content is from rtems-libbsd/libbsd.txt with minor modifications.
> ---
>  user/bsps/arm/xilinx-zynq.rst | 18 +-
>  1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/user/bsps/arm/xilinx-zynq.rst b/user/bsps/arm/xilinx-zynq.rst
> index 29f9cb0..0ac4487 100644
> --- a/user/bsps/arm/xilinx-zynq.rst
> +++ b/user/bsps/arm/xilinx-zynq.rst
> @@ -1,6 +1,6 @@
>  .. SPDX-License-Identifier: CC-BY-SA-4.0
>
> -.. Copyright (C) 2020 Chris Johns (chr...@rtems.org)
> +.. Copyright (C) 2015, 2020 Chris Johns (chr...@rtems.org)
>
>  xilinx-zynq
>  ===
> @@ -49,6 +49,22 @@ tools or a bootloader will be overwritten.
>  The settings for the console driver can be changed by the user
>  application through the termios API afterwards.
>
> +Network
> +---
> +
> +The Cadence network interface driver of LibBSD works on the Xilinx Zynq
> +platform. The hardware checksum support works on real hardware but does not
> +seem to be supported on Qemu therefore the default state is to disable
> +``IFCAP_TXCSUM`` and ``IFCAP_RXCSUM`` and this can be enabled from the shell
> +with:
> +
> +.. code-block:: none
> +
> +ifconfig cgem0 rxcsum txcsum
> +
> +or with an ``ioctl()`` call to the network interface driver with 
> ``SIOCSIFCAP``
> +and the mask ``IFCAP_TXCSUM`` and ``IFCAP_RXCSUM`` set.
> +
>  Debugging with xilinx_zynq_a9_qemu
>  --
>
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] devel/spike-1.0.0: bump hash

2022-06-01 Thread Gedare Bloom 
What/Why did this change? Where we not using a release before?

Looks ok otherwise.

On Wed, May 25, 2022 at 12:31 PM Ryan Long  wrote:
>
> Bump the hash of spike to match the 1.1.0 release
>
> Closes #4660
> ---
>  bare/config/devel/spike-1.1.0.cfg | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/bare/config/devel/spike-1.1.0.cfg 
> b/bare/config/devel/spike-1.1.0.cfg
> index 644b754..73cf3c2 100644
> --- a/bare/config/devel/spike-1.1.0.cfg
> +++ b/bare/config/devel/spike-1.1.0.cfg
> @@ -8,9 +8,9 @@
>
>  %include %{_configdir}/base.cfg
>
> -%define spike_version 66b44bfbedda562a32e4a2cd0716afbf731b69cd
> +%define spike_version 530af85d83781a3dae31a4ace84a573ec255fefa
>
> -%hash sha512 spike-%{spike_version}.tar.gz 
> a98fc9e564edb3bb471f04063484a5d056befb8b2258b96de2d238cf27d1d5544c2782c91c7731b8f0aa03012eb3d39de33e4f30927349e38c7e131e8241b92f
> +%hash sha512 spike-%{spike_version}.tar.gz 
> D+9XugRwrZJ8undjx3x3CILr4VSdeaNsTTUZYeENFPZy6MG7TiQAY5umaUr/oOr6vWCq7YjFhqwjPI+fcieqYw==
>
>  #
>  # The spike build instructions. We use 1.x.x Release 1.
> --
> 2.30.2
>
> ___
> 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 1/4] bsps/stm32h7: add board C files for stm32h747i-disco BSP

2022-06-01 Thread Sebastian Huber 

On 01/06/2022 14:23, Karel Gardas wrote:

Besides C files for the BSP variant the patch also provides license
clarification on system_stm32h7xx.c file which is provided
in boards/stm/stm32h747i-disco directory.
The files comes from STM32CubeH7 project and references "root directory"
in its license comment and it's not clear where this points out.
Let's add clarification comment about it and also based on it
and resulting license let's add SPDX license identifier.

Sponsored-By:   Precidata


Thanks, the patch set looks good.
--
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 4/4] bsps/stm32h7: set default SDRAM x sizes on stm32h747i-disco BSP

2022-06-01 Thread Karel Gardas 
This means:

SDRAM 1: 0
SDRAM 2: 32 MB

Sponsored-By:   Precidata
---
 spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml | 1 +
 spec/build/bsps/arm/stm32h7/optmemsdram2sz.yml | 1 +
 2 files changed, 2 insertions(+)

diff --git a/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml 
b/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml
index 82267648a4..4a243b0261 100644
--- a/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml
+++ b/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml
@@ -9,6 +9,7 @@ default-by-variant:
   - arm/stm32h7b3i-dk
   - arm/stm32h757i-eval
   - arm/stm32h757i-eval-m4
+  - arm/stm32h747i-disco
 enabled-by: true
 format: '{:#010x}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optmemsdram2sz.yml 
b/spec/build/bsps/arm/stm32h7/optmemsdram2sz.yml
index 9fa8accbf4..57ded49f23 100644
--- a/spec/build/bsps/arm/stm32h7/optmemsdram2sz.yml
+++ b/spec/build/bsps/arm/stm32h7/optmemsdram2sz.yml
@@ -8,6 +8,7 @@ default-by-variant:
   variants:
   - arm/stm32h757i-eval
   - arm/stm32h757i-eval-m4
+  - arm/stm32h747i-disco
 enabled-by: true
 format: '{:#010x}'
 links: []
-- 
2.25.1

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

[PATCH 3/4] bsps/stm32h7: disable all unsupported U(S)ARTs on stm32h747i-disco BSP

2022-06-01 Thread Karel Gardas 
This patch disables all U(S)ARTs which are not supported by the board
itself and its provided connectors. That means only USART1 and 2
and UART8 are enabled.

Sponsored-By:   Precidata
---
 spec/build/bsps/arm/stm32h7/optenuart4.yml   | 1 +
 spec/build/bsps/arm/stm32h7/optenuart5.yml   | 1 +
 spec/build/bsps/arm/stm32h7/optenuart7.yml   | 1 +
 spec/build/bsps/arm/stm32h7/optenuart9.yml   | 1 +
 spec/build/bsps/arm/stm32h7/optenusart10.yml | 1 +
 spec/build/bsps/arm/stm32h7/optenusart3.yml  | 1 +
 spec/build/bsps/arm/stm32h7/optenusart6.yml  | 1 +
 7 files changed, 7 insertions(+)

diff --git a/spec/build/bsps/arm/stm32h7/optenuart4.yml 
b/spec/build/bsps/arm/stm32h7/optenuart4.yml
index 73c1ebef1c..d165f4144e 100644
--- a/spec/build/bsps/arm/stm32h7/optenuart4.yml
+++ b/spec/build/bsps/arm/stm32h7/optenuart4.yml
@@ -8,6 +8,7 @@ default-by-variant:
   variants:
   - arm/stm32h757i-eval
   - arm/stm32h757i-eval-m4
+  - arm/stm32h747i-disco
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenuart5.yml 
b/spec/build/bsps/arm/stm32h7/optenuart5.yml
index e445f2834f..f691d9bbc4 100644
--- a/spec/build/bsps/arm/stm32h7/optenuart5.yml
+++ b/spec/build/bsps/arm/stm32h7/optenuart5.yml
@@ -9,6 +9,7 @@ default-by-variant:
   - arm/stm32h7b3i-dk
   - arm/stm32h757i-eval
   - arm/stm32h757i-eval-m4
+  - arm/stm32h747i-disco
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenuart7.yml 
b/spec/build/bsps/arm/stm32h7/optenuart7.yml
index 225c9efa22..dc160d31dc 100644
--- a/spec/build/bsps/arm/stm32h7/optenuart7.yml
+++ b/spec/build/bsps/arm/stm32h7/optenuart7.yml
@@ -9,6 +9,7 @@ default-by-variant:
   - arm/stm32h7b3i-dk
   - arm/stm32h757i-eval
   - arm/stm32h757i-eval-m4
+  - arm/stm32h747i-disco
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenuart9.yml 
b/spec/build/bsps/arm/stm32h7/optenuart9.yml
index 864948fc91..aec036bd22 100644
--- a/spec/build/bsps/arm/stm32h7/optenuart9.yml
+++ b/spec/build/bsps/arm/stm32h7/optenuart9.yml
@@ -9,6 +9,7 @@ default-by-variant:
   - arm/stm32h7b3i-dk
   - arm/stm32h757i-eval
   - arm/stm32h757i-eval-m4
+  - arm/stm32h747i-disco
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenusart10.yml 
b/spec/build/bsps/arm/stm32h7/optenusart10.yml
index b60acf62a4..ee4f5785d9 100644
--- a/spec/build/bsps/arm/stm32h7/optenusart10.yml
+++ b/spec/build/bsps/arm/stm32h7/optenusart10.yml
@@ -9,6 +9,7 @@ default-by-variant:
   - arm/stm32h7b3i-dk
   - arm/stm32h757i-eval
   - arm/stm32h757i-eval-m4
+  - arm/stm32h747i-disco
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenusart3.yml 
b/spec/build/bsps/arm/stm32h7/optenusart3.yml
index 798aaed2a5..af6cd5185f 100644
--- a/spec/build/bsps/arm/stm32h7/optenusart3.yml
+++ b/spec/build/bsps/arm/stm32h7/optenusart3.yml
@@ -9,6 +9,7 @@ default-by-variant:
   - arm/stm32h7b3i-dk
   - arm/stm32h757i-eval
   - arm/stm32h757i-eval-m4
+  - arm/stm32h747i-disco
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenusart6.yml 
b/spec/build/bsps/arm/stm32h7/optenusart6.yml
index a8ab30cba5..fbf0b16e77 100644
--- a/spec/build/bsps/arm/stm32h7/optenusart6.yml
+++ b/spec/build/bsps/arm/stm32h7/optenusart6.yml
@@ -9,6 +9,7 @@ default-by-variant:
   - arm/stm32h7b3i-dk
   - arm/stm32h757i-eval
   - arm/stm32h757i-eval-m4
+  - arm/stm32h747i-disco
 enabled-by: true
 format: '{}'
 links: []
-- 
2.25.1

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

[PATCH 2/4] bsps/stm32h7: add configuration and enable build of stm32h747i-disco BSP

2022-06-01 Thread Karel Gardas 
Sponsored-By:   Precidata
---
 .../bsps/arm/stm32h7/bspstm32h747i-disco.yml  | 24 +++
 spec/build/bsps/arm/stm32h7/optbootcore.yml   |  1 +
 spec/build/bsps/arm/stm32h7/optlinkcmds.yml   |  1 +
 spec/build/bsps/arm/stm32h7/optpwrsupply.yml  |  1 +
 .../arm/stm32h7/optusart1alternatefunc.yml|  1 +
 .../bsps/arm/stm32h7/optusart1gpiopins.yml|  1 +
 .../bsps/arm/stm32h7/optusart1gpioregs.yml|  1 +
 spec/build/bsps/arm/stm32h7/optvariant.yml|  3 +++
 8 files changed, 33 insertions(+)
 create mode 100644 spec/build/bsps/arm/stm32h7/bspstm32h747i-disco.yml

diff --git a/spec/build/bsps/arm/stm32h7/bspstm32h747i-disco.yml 
b/spec/build/bsps/arm/stm32h7/bspstm32h747i-disco.yml
new file mode 100644
index 00..dcd5216391
--- /dev/null
+++ b/spec/build/bsps/arm/stm32h7/bspstm32h747i-disco.yml
@@ -0,0 +1,24 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+arch: arm
+bsp: stm32h747i-disco
+build-type: bsp
+cflags: []
+copyrights:
+- Copyright (C) 2022 Karel Gardas 
+cppflags: []
+enabled-by: true
+family: stm32h7
+includes: []
+install: []
+links:
+- role: build-dependency
+  uid: grp
+- role: build-dependency
+  uid: tststm32h757i-eval
+source:
+- bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-config-clk.c
+- bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-config-osc.c
+- bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-config-per.c
+- bsps/arm/stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c
+- bsps/arm/shared/cache/cache-v7m.c
+type: build
diff --git a/spec/build/bsps/arm/stm32h7/optbootcore.yml 
b/spec/build/bsps/arm/stm32h7/optbootcore.yml
index e6f52e8631..6d1a500ede 100644
--- a/spec/build/bsps/arm/stm32h7/optbootcore.yml
+++ b/spec/build/bsps/arm/stm32h7/optbootcore.yml
@@ -11,6 +11,7 @@ default-by-variant:
 - value: CORE_CM7
   variants:
   - arm/stm32h757i-eval
+  - arm/stm32h747i-disco
 - value: CORE_CM4
   variants:
   - arm/stm32h757i-eval-m4
diff --git a/spec/build/bsps/arm/stm32h7/optlinkcmds.yml 
b/spec/build/bsps/arm/stm32h7/optlinkcmds.yml
index c3c76f9496..5632a3416a 100644
--- a/spec/build/bsps/arm/stm32h7/optlinkcmds.yml
+++ b/spec/build/bsps/arm/stm32h7/optlinkcmds.yml
@@ -9,6 +9,7 @@ default-by-variant:
   - arm/stm32h7b3i-dk
   - arm/stm32h757i-eval
   - arm/stm32h757i-eval-m4
+  - arm/stm32h747i-disco
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optpwrsupply.yml 
b/spec/build/bsps/arm/stm32h7/optpwrsupply.yml
index c974654366..94b2403da7 100644
--- a/spec/build/bsps/arm/stm32h7/optpwrsupply.yml
+++ b/spec/build/bsps/arm/stm32h7/optpwrsupply.yml
@@ -9,6 +9,7 @@ default-by-variant:
   - arm/stm32h7b3i-dk
   - arm/stm32h757i-eval
   - arm/stm32h757i-eval-m4
+  - arm/stm32h747i-disco
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optusart1alternatefunc.yml 
b/spec/build/bsps/arm/stm32h7/optusart1alternatefunc.yml
index 049ed6a3ac..61982d94ed 100644
--- a/spec/build/bsps/arm/stm32h7/optusart1alternatefunc.yml
+++ b/spec/build/bsps/arm/stm32h7/optusart1alternatefunc.yml
@@ -7,6 +7,7 @@ default-by-variant:
 - value: GPIO_AF7_USART1
   variants:
   - arm/stm32h7b3i-dk
+  - arm/stm32h747i-disco
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optusart1gpiopins.yml 
b/spec/build/bsps/arm/stm32h7/optusart1gpiopins.yml
index 1580ded243..5150dd2d04 100644
--- a/spec/build/bsps/arm/stm32h7/optusart1gpiopins.yml
+++ b/spec/build/bsps/arm/stm32h7/optusart1gpiopins.yml
@@ -7,6 +7,7 @@ default-by-variant:
 - value: ( GPIO_PIN_9 | GPIO_PIN_10 )
   variants:
   - arm/stm32h7b3i-dk
+  - arm/stm32h747i-disco
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optusart1gpioregs.yml 
b/spec/build/bsps/arm/stm32h7/optusart1gpioregs.yml
index 233a5ac813..d91fe73d37 100644
--- a/spec/build/bsps/arm/stm32h7/optusart1gpioregs.yml
+++ b/spec/build/bsps/arm/stm32h7/optusart1gpioregs.yml
@@ -7,6 +7,7 @@ default-by-variant:
 - value: GPIOA
   variants:
   - arm/stm32h7b3i-dk
+  - arm/stm32h747i-disco
 - value: GPIOB
   variants:
   - arm/stm32h757i-eval
diff --git a/spec/build/bsps/arm/stm32h7/optvariant.yml 
b/spec/build/bsps/arm/stm32h7/optvariant.yml
index ade5d5931d..b7ce814e52 100644
--- a/spec/build/bsps/arm/stm32h7/optvariant.yml
+++ b/spec/build/bsps/arm/stm32h7/optvariant.yml
@@ -21,6 +21,9 @@ default-by-variant:
   variants:
 - arm/stm32h757i-eval
 - arm/stm32h757i-eval-m4
+- value: STM32H747xx
+  variants:
+  - arm/stm32h747i-disco
 enabled-by: true
 format: '{}'
 links: []
-- 
2.25.1

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

[PATCH 1/4] bsps/stm32h7: add board C files for stm32h747i-disco BSP

2022-06-01 Thread Karel Gardas 
Besides C files for the BSP variant the patch also provides license
clarification on system_stm32h7xx.c file which is provided
in boards/stm/stm32h747i-disco directory.
The files comes from STM32CubeH7 project and references "root directory"
in its license comment and it's not clear where this points out.
Let's add clarification comment about it and also based on it
and resulting license let's add SPDX license identifier.

Sponsored-By:   Precidata
---
 .../stm/stm32h747i-disco/stm32h7-config-clk.c |  45 ++
 .../stm/stm32h747i-disco/stm32h7-config-osc.c |  50 ++
 .../stm/stm32h747i-disco/stm32h7-config-per.c |  39 ++
 .../stm/stm32h747i-disco/system_stm32h7xx.c   | 602 ++
 4 files changed, 736 insertions(+)
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-config-clk.c
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-config-osc.c
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-config-per.c
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c

diff --git a/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-config-clk.c 
b/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-config-clk.c
new file mode 100644
index 00..c4ea947c3c
--- /dev/null
+++ b/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-config-clk.c
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2022 Karel Gardas 
+ *
+ * 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.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+
+const RCC_ClkInitTypeDef stm32h7_config_clocks = {
+  .ClockType = RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_SYSCLK
+| RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2
+| RCC_CLOCKTYPE_D3PCLK1 | RCC_CLOCKTYPE_D1PCLK1,
+  .SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK,
+  .SYSCLKDivider = RCC_SYSCLK_DIV1,
+  .AHBCLKDivider = RCC_HCLK_DIV2,
+  .APB3CLKDivider = RCC_APB3_DIV2,
+  .APB1CLKDivider = RCC_APB1_DIV2,
+  .APB2CLKDivider = RCC_APB2_DIV2,
+  .APB4CLKDivider = RCC_APB4_DIV2
+};
diff --git a/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-config-osc.c 
b/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-config-osc.c
new file mode 100644
index 00..4f294c455d
--- /dev/null
+++ b/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-config-osc.c
@@ -0,0 +1,50 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2022 Karel Gardas 
+ *
+ * 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 SOFTWAR

Re: [PATCH] user/bsps/arm: improve stm32h7 BSP description

2022-06-01 Thread Gedare Bloom 
Looks good to me.

On Wed, May 18, 2022 at 1:02 PM Karel Gardas  wrote:
>
> This patch adds kind of HOWTO to the stm32h7 BSP description. The howto
> discusses various tools from STM tool-chain and how to use them in order
> to configure board for RTEMS and to upload RTEMS application binary
> to the board. The patch also adds more supported boards to the table.
>
> Sponsored-By:   Precidata
> ---
>  user/bsps/arm/stm32h7.rst | 544 --
>  1 file changed, 528 insertions(+), 16 deletions(-)
>
> diff --git a/user/bsps/arm/stm32h7.rst b/user/bsps/arm/stm32h7.rst
> index b508595..ec7440f 100644
> --- a/user/bsps/arm/stm32h7.rst
> +++ b/user/bsps/arm/stm32h7.rst
> @@ -2,16 +2,36 @@
>
>  .. Copyright (C) 2020 embedded brains GmbH
>
> +.. Copyright (C) 2022 Karel Gardas 
> +
>  stm32h7
>  ===
>
>  This BSP supports the
>  `STM32H7 Series 
> `_.
>
> -The BSP is known to run on these boards:
> +The BSP is known to run on these boards on specified core with using 
> specified BSP variant.
> +
> +.. table::
> +
> +  
> +--+---++
> +  | Board name   
> | Core name |  BSP variant name  |
> +  
> +==+===++
> +  |`STM32H743I-EVAL 2 
> `_| M7| 
> arm/stm32h7|
> +  
> +--+---++
> +  |`STM32H743ZI-Nucleo 
> `_ | M7| 
> arm/nucleo-h743zi  |
> +  
> +--+---++
> +  |`STM32H7B3I-DK 
> `_  | M7   
>  | arm/stm32h7b3i-dk  |
> +  
> +--+---++
> +  |`STM32H757I-EVAL 
> `_  | M7
> | arm/stm32h757i-eval|
> +  |  
> +---++
> +  |  
> | M4| arm/stm32h757i-eval-m4 |
> +  
> +--+---++
> +  |`STM32H747I-DISCO 
> `_| M7| 
> arm/stm32h747i-disco   |
> +  |  
> +---++
> +  |  
> | M4| arm/stm32h747i-disco-m4|
> +  
> +--+---++
>
> -* `STM32H743I-EVAL 2 
> `_
> -* `STM32H743ZI-Nucleo 
> `_
>
>  Clock Driver
>  
> @@ -23,20 +43,28 @@ boards, so it is recommended to check the default values 
> of the BSP.
>  Console Driver
>  --
>
> -The console driver supports the on-chip UART and USART modules.
> -Different board variations use different GPIO pins and blocks for the default
> -communication UART and it is recommended to check whether the default
> -configuration provided is valid in the BSP.
> +The console driver supports the on-chip UART and USART modules. Even
> +the MCU supports about 10 U(S)ARTs, only those supported by the chosen
> +board are enabled by default configuration. The board needs to support
> +some kind of connector-based connection to the U(S)ART in order for the
> +feature to be considered supported here.
> +..
> +.. Leaving previous notes here as a comment. They may still be useful
> +.. and incorporated into the later version of the document.
> +..
> +.. Different board variations use different GPIO pins and blocks for the 
> default
> +.. communication UART and it is recommended to check whether the default
> +.. configuration provided is valid in the BSP.
>
> -To specify that the BSP should be built for the STM32H743ZI-Nucleo board,
> -users can supply ``STM32H743ZI_NUCLEO = True`` to ``config.ini`` when
> -building the BSP.
> +.. To specify that the BSP should be built for the STM32H743ZI-Nucleo board,
> +.. users can supply ``STM32H743ZI_NUCLEO = True`` to ``config.ini`` whe

Re: AW: AW: [PATCH] kern_tc.c: Update pps_event() for uniprocessor configurations

2022-06-01 Thread Sebastian Huber 

On 01/06/2022 11:19, gabriel.moy...@dlr.de wrote:

On 01/06/2022 08:55,gabriel.moy...@dlr.de  wrote:

On 30/05/2022 09:29, Gabriel Moyano wrote:

Since pps->capgen is not used in uniprocessor configurations, there
is no need to verified if it is equal to zero

Update #2349
---
cpukit/score/src/kern_tc.c | 4 
1 file changed, 4 insertions(+)

diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c
index 92739d8edd..897f81511e 100644
--- a/cpukit/score/src/kern_tc.c
+++ b/cpukit/score/src/kern_tc.c
@@ -2165,7 +2165,11 @@ pps_event(struct pps_state *pps, int event)
if ((event & pps->ppsparam.mode) == 0)
return;
/* If the timecounter was wound up underneath us, bail out. */
+#if defined(RTEMS_SMP)
if (pps->capgen == 0 || pps->capgen !=
+#else
+   if (pps->capgen !=
+#endif
atomic_load_acq_int(&pps->capth->th_generation))
return;


I think this fix is incomplete. What is with:

void
pps_capture(struct pps_state *pps)
{
struct timehands *th;

KASSERT(pps != NULL, ("NULL pps pointer in pps_capture"));
th = timehands;
pps->capgen = atomic_load_acq_int(&th->th_generation);
pps->capth = th;
#ifdef FFCLOCK
pps->capffth = fftimehands;
#endif
pps->capcount = th->th_counter->tc_get_timecount(th->th_counter);
atomic_thread_fence_acq();
if (pps->capgen != th->th_generation)
pps->capgen = 0;
}

I don't know why there is this "if" in the code. I will ask on a FreeBSD 
mailing list.


I think it is for the case that th_generation has changed in between
saving the th and th_counter. If this happens pps->capgen is set to 0
and later pps_event() returns earlier. Since for uniprocessor
th_generation equal to 0 is not used, I guess we can removed this if
for those configurations

I asked on a FreeBSD mailing list:

https://lists.freebsd.org/archives/freebsd-hackers/2022-June/001165.html


Thanks for asking.
I'll prepare and send a new patch removing the "if" for uniprocessor 
configurations just in case.


Please wait with a new patch for a response from FreeBSD.

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

AW: AW: [PATCH] kern_tc.c: Update pps_event() for uniprocessor configurations

2022-06-01 Thread Gabriel.Moyano 
> On 01/06/2022 08:55, gabriel.moy...@dlr.de wrote:
> >> On 30/05/2022 09:29, Gabriel Moyano wrote:
> >>> Since pps->capgen is not used in uniprocessor configurations, there
> >>> is no need to verified if it is equal to zero
> >>>
> >>> Update #2349
> >>> ---
> >>>cpukit/score/src/kern_tc.c | 4 
> >>>1 file changed, 4 insertions(+)
> >>>
> >>> diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c
> >>> index 92739d8edd..897f81511e 100644
> >>> --- a/cpukit/score/src/kern_tc.c
> >>> +++ b/cpukit/score/src/kern_tc.c
> >>> @@ -2165,7 +2165,11 @@ pps_event(struct pps_state *pps, int event)
> >>>   if ((event & pps->ppsparam.mode) == 0)
> >>>   return;
> >>>   /* If the timecounter was wound up underneath us, bail out. */
> >>> +#if defined(RTEMS_SMP)
> >>>   if (pps->capgen == 0 || pps->capgen !=
> >>> +#else
> >>> + if (pps->capgen !=
> >>> +#endif
> >>>   atomic_load_acq_int(&pps->capth->th_generation))
> >>>   return;
> >>>
> >>
> >> I think this fix is incomplete. What is with:
> >>
> >> void
> >> pps_capture(struct pps_state *pps)
> >> {
> >>struct timehands *th;
> >>
> >>KASSERT(pps != NULL, ("NULL pps pointer in pps_capture"));
> >>th = timehands;
> >>pps->capgen = atomic_load_acq_int(&th->th_generation);
> >>pps->capth = th;
> >> #ifdef FFCLOCK
> >>pps->capffth = fftimehands;
> >> #endif
> >>pps->capcount = th->th_counter->tc_get_timecount(th->th_counter);
> >>atomic_thread_fence_acq();
> >>if (pps->capgen != th->th_generation)
> >>pps->capgen = 0;
> >> }
> >>
> >> I don't know why there is this "if" in the code. I will ask on a FreeBSD 
> >> mailing list.
> >>
> >
> > I think it is for the case that th_generation has changed in between
> > saving the th and th_counter. If this happens pps->capgen is set to 0
> > and later pps_event() returns earlier. Since for uniprocessor
> > th_generation equal to 0 is not used, I guess we can removed this if
> > for those configurations
> 
> I asked on a FreeBSD mailing list:
> 
> https://lists.freebsd.org/archives/freebsd-hackers/2022-June/001165.html
> 

Thanks for asking.
I'll prepare and send a new patch removing the "if" for uniprocessor 
configurations just in case.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/7] bsps/stm32h7: enable cache and MPU only on Cortex-M7

2022-06-01 Thread Sebastian Huber 

On 30/05/2022 01:36, Karel Gardas wrote:

diff --git a/bsps/arm/stm32h7/start/bspstarthooks.c 
b/bsps/arm/stm32h7/start/bspstarthooks.c
index ef26af5eba..dd8f544e52 100644
--- a/bsps/arm/stm32h7/start/bspstarthooks.c
+++ b/bsps/arm/stm32h7/start/bspstarthooks.c
@@ -101,7 +101,7 @@ void bsp_start_hook_0(void)
  HAL_Init();
  SystemInit_ExtMemCtl();
}
-
+#if __CORTEX_M == 0x07U
if ((SCB->CCR & SCB_CCR_IC_Msk) == 0) {
  SCB_EnableICache();
}


The entire patch set is fine, but please keep the black line above.

--
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: AW: [PATCH] kern_tc.c: Update pps_event() for uniprocessor configurations

2022-06-01 Thread Sebastian Huber 

On 01/06/2022 08:55, gabriel.moy...@dlr.de wrote:

On 30/05/2022 09:29, Gabriel Moyano wrote:

Since pps->capgen is not used in uniprocessor configurations, there is
no need to verified if it is equal to zero

Update #2349
---
   cpukit/score/src/kern_tc.c | 4 
   1 file changed, 4 insertions(+)

diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c
index 92739d8edd..897f81511e 100644
--- a/cpukit/score/src/kern_tc.c
+++ b/cpukit/score/src/kern_tc.c
@@ -2165,7 +2165,11 @@ pps_event(struct pps_state *pps, int event)
if ((event & pps->ppsparam.mode) == 0)
return;
/* If the timecounter was wound up underneath us, bail out. */
+#if defined(RTEMS_SMP)
if (pps->capgen == 0 || pps->capgen !=
+#else
+   if (pps->capgen !=
+#endif
atomic_load_acq_int(&pps->capth->th_generation))
return;



I think this fix is incomplete. What is with:

void
pps_capture(struct pps_state *pps)
{
struct timehands *th;

KASSERT(pps != NULL, ("NULL pps pointer in pps_capture"));
th = timehands;
pps->capgen = atomic_load_acq_int(&th->th_generation);
pps->capth = th;
#ifdef FFCLOCK
pps->capffth = fftimehands;
#endif
pps->capcount = th->th_counter->tc_get_timecount(th->th_counter);
atomic_thread_fence_acq();
if (pps->capgen != th->th_generation)
pps->capgen = 0;
}

I don't know why there is this "if" in the code. I will ask on a FreeBSD 
mailing list.



I think it is for the case that th_generation has changed in between saving the th 
and th_counter. If this happens pps->capgen is set to 0 and later pps_event() 
returns earlier. Since for uniprocessor th_generation equal to 0 is not used, I 
guess we can removed this if for those configurations


I asked on a FreeBSD mailing list:

https://lists.freebsd.org/archives/freebsd-hackers/2022-June/001165.html

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

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