[PATCH 1/1] kern_tc.c: th_generation starts with 1 after overflow for single-core

2022-05-27 Thread Gabriel Moyano 
---
 cpukit/score/src/kern_tc.c | 23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c
index 89ece1fbde..3256b646ef 100644
--- a/cpukit/score/src/kern_tc.c
+++ b/cpukit/score/src/kern_tc.c
@@ -1659,9 +1659,9 @@ _Timecounter_Windup(struct bintime *new_boottimebin,
struct timecounter *tc;
struct timehands *th, *tho;
uint32_t delta, ncount;
-#if defined(RTEMS_SMP)
+#ifdef __rtems__
u_int ogen;
-#endif
+#endif /* __rtems__ */
int i;
time_t t;
 #ifdef __rtems__
@@ -1686,6 +1686,7 @@ _Timecounter_Windup(struct bintime *new_boottimebin,
memcpy(th, tho, offsetof(struct timehands, th_generation));
 #else
th = tho;
+   ogen = th->th_generation;
 #endif
if (new_boottimebin != NULL)
th->th_boottime = *new_boottimebin;
@@ -1783,7 +1784,7 @@ _Timecounter_Windup(struct bintime *new_boottimebin,
 #endif
}
 
-#if defined(RTEMS_SMP)
+#ifdef __rtems__
/*
 * Now that the struct timehands is again consistent, set the new
 * generation number, making sure to not make it zero.
@@ -1791,9 +1792,7 @@ _Timecounter_Windup(struct bintime *new_boottimebin,
if (++ogen == 0)
ogen = 1;
atomic_store_rel_int(&th->th_generation, ogen);
-#else
-   atomic_store_rel_int(&th->th_generation, th->th_generation + 1);
-#endif
+#endif /* __rtems__ */
 
/* Go live with the new struct timehands. */
 #ifdef FFCLOCK
@@ -2323,13 +2322,13 @@ _Timecounter_Tick_simple(uint32_t delta, uint32_t 
offset,
 {
struct bintime bt;
struct timehands *th;
-#if defined(RTEMS_SMP)
+#ifdef __rtems__
u_int ogen;
-#endif
+#endif /* __rtems__ */
 
th = timehands;
-#if defined(RTEMS_SMP)
ogen = th->th_generation;
+#if defined(RTEMS_SMP)
th->th_generation = 0;
atomic_thread_fence_rel();
 #endif
@@ -2344,7 +2343,7 @@ _Timecounter_Tick_simple(uint32_t delta, uint32_t offset,
bintime2timeval(&bt, &th->th_microtime);
bintime2timespec(&bt, &th->th_nanotime);
 
-#if defined(RTEMS_SMP)
+#ifdef __rtems__
/*
 * Now that the struct timehands is again consistent, set the new
 * generation number, making sure to not make it zero.
@@ -2352,9 +2351,7 @@ _Timecounter_Tick_simple(uint32_t delta, uint32_t offset,
if (++ogen == 0)
ogen = 1;
atomic_store_rel_int(&th->th_generation, ogen);
-#else
-   atomic_store_rel_int(&th->th_generation, th->th_generation + 1);
-#endif
+#endif /* __rtems__ */
 
/* Go live with the new struct timehands. */
time_second = th->th_microtime.tv_sec;
-- 
2.25.1

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

[PATCH 0/1] Solves th_generation overflow issue for single-core configuration

2022-05-27 Thread Gabriel Moyano 
After increasing th_generation if an overflow happens its value should be 1 
since 0 means that the timehand is being updated.
In single-core configurations, this wasn't corrected. This patch solves this 
issue for RTEMS 6.

Gabriel Moyano (1):
  kern_tc.c: th_generation starts with 1 after overflow for single-core

 cpukit/score/src/kern_tc.c | 23 ++-
 1 file changed, 10 insertions(+), 13 deletions(-)

-- 
2.25.1

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

Re: [PATCH 1/1] kern_tc.c: th_generation starts with 1 after overflow for single-core

2022-05-27 Thread Sebastian Huber 

Hello Gabriel,

the uniprocessor version uses an optimization at the reader side:

#if defined(RTEMS_SMP)
} while (gen == 0 || gen != th->th_generation);
#else
} while (gen != th->th_generation);
#endif

This is possible since the windup happens with interrupts disabled. I 
guess you need this optimization somewhere in the PPS/NTP code.


Could you please add the details to the commit message and not the cover 
letter. The cover letter is not committed.


Could you please have a look at:

https://lists.rtems.org/pipermail/devel/2022-May/071609.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

Re: [PATCH 1/1] kern_tc.c: th_generation starts with 1 after overflow for single-core

2022-05-27 Thread Sebastian Huber 

On 27.05.22 10:51, Sebastian Huber wrote:

Hello Gabriel,

the uniprocessor version uses an optimization at the reader side:

#if defined(RTEMS_SMP)
 } while (gen == 0 || gen != th->th_generation);
#else
 } while (gen != th->th_generation);
#endif

This is possible since the windup happens with interrupts disabled. I 
guess you need this optimization somewhere in the PPS/NTP code.


Could you please add the details to the commit message and not the cover 
letter. The cover letter is not committed.


Could you please have a look at:

https://lists.rtems.org/pipermail/devel/2022-May/071609.html


It would be also good to have a test case for the problem you are trying 
to fix. The PPS/NTP code is a bit complicated and the test coverage of 
this area is far below the score average.


--
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: [PATCH] score: Fix pps_fetch()

2022-05-27 Thread Gabriel.Moyano 
Hi Sebastian,

It is ok. Thx for adding this, I must have removed this "if" accidentally. 

> Return early only if there was a timeout, otherwise return the PPS info.
> 
> Update #2349.
> ---
>  cpukit/score/src/kern_tc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/cpukit/score/src/kern_tc.c b/cpukit/score/src/kern_tc.c index 
> c09900f096..2e3709a9ad 100644
> --- a/cpukit/score/src/kern_tc.c
> +++ b/cpukit/score/src/kern_tc.c
> @@ -1980,7 +1980,8 @@ pps_fetch(struct pps_fetch_args *fapi, struct pps_state 
> *pps)  #else /* __rtems__ */
>   _Assert(pps->wait != NULL);
>   err = (*pps->wait)(pps, fapi->timeout);
> - return (err);
> + if (err != 0)
> + return (err);
>  #endif /* __rtems__ */
>   }
>   }
> --
> 2.35.3

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

AW: [PATCH 1/1] kern_tc.c: th_generation starts with 1 after overflow for single-core

2022-05-27 Thread Gabriel.Moyano 
> On 27.05.22 10:51, Sebastian Huber wrote:
> > Hello Gabriel,
> >
> > the uniprocessor version uses an optimization at the reader side:
> >
> > #if defined(RTEMS_SMP)
> >  } while (gen == 0 || gen != th->th_generation); #else
> >  } while (gen != th->th_generation); #endif
> >
> > This is possible since the windup happens with interrupts disabled. I
> > guess you need this optimization somewhere in the PPS/NTP code.

Yes, you are right that is for the PPS code.
The value of th_generation is saved in pps_capture() and I shouldn't add a 
while waiting it to be different that 0 there.
If its value is 0, then the pps_event() returns early.
This is something that could happen in very particular circumstance (pps event 
happens when the th_generation is 0).

> > Could you please add the details to the commit message and not the
> > cover letter. The cover letter is not committed.

Sure.

> > Could you please have a look at:
> >
> > https://lists.rtems.org/pipermail/devel/2022-May/071609.html
> 
> It would be also good to have a test case for the problem you are trying to 
> fix. The PPS/NTP code is a bit complicated and the test
> coverage of this area is far below the score average.
> 

One way to test this is waiting to the overflow of th_generation, do you think 
that it is feasibly to add such a test if its duration is a long time?

Btw. Could you check this 
https://lists.rtems.org/pipermail/devel/2022-May/071662.html ?
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: AW: [PATCH 1/1] kern_tc.c: th_generation starts with 1 after overflow for single-core

2022-05-27 Thread Sebastian Huber 



On 27.05.22 11:49, gabriel.moy...@dlr.de wrote:

On 27.05.22 10:51, Sebastian Huber wrote:

Hello Gabriel,

the uniprocessor version uses an optimization at the reader side:

#if defined(RTEMS_SMP)
  } while (gen == 0 || gen != th->th_generation); #else
  } while (gen != th->th_generation); #endif

This is possible since the windup happens with interrupts disabled. I
guess you need this optimization somewhere in the PPS/NTP code.

Yes, you are right that is for the PPS code.
The value of th_generation is saved in pps_capture() and I shouldn't add a 
while waiting it to be different that 0 there.
If its value is 0, then the pps_event() returns early.
This is something that could happen in very particular circumstance (pps event 
happens when the th_generation is 0).


In uniprocessor configurations, we don't need the 0 special value. It is 
only required in SMP configurations since one processor may observe a 
timecounter update which is in progress on another processor.





Could you please add the details to the commit message and not the
cover letter. The cover letter is not committed.

Sure.


Could you please have a look at:

https://lists.rtems.org/pipermail/devel/2022-May/071609.html

It would be also good to have a test case for the problem you are trying to 
fix. The PPS/NTP code is a bit complicated and the test
coverage of this area is far below the score average.


One way to test this is waiting to the overflow of th_generation, do you think 
that it is feasibly to add such a test if its duration is a long time?


You may have a look at the 
testsuites/validation/tc-timecounter-get-smp.c test code for a hack how 
you can access the th_generation. If you want to use this hack a second 
time, then the struct timehand definition should move to a test header file.




Btw. Could you check 
thishttps://lists.rtems.org/pipermail/devel/2022-May/071662.html  ?


Thanks, I checked it in.

--
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] user/bsps/arm: improve stm32h7 BSP description

2022-05-27 Thread Karel Gardas 



ping.

I've submited this before my commit access and not sure either if the 
doc hacking although purely BSP specific counts as


"A BSP-specific patch may be checked in three work days after sending it 
to devel@rtems.org in case nobody explicitly rejected the patch."


from MAINTAINERS... So pinging...

Thanks,
Karel


On 5/18/22 21:02, 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 sho