Re: [PATCH] score: Document Futex Handler

2021-09-01 Thread Joel Sherrill 
On Wed, Sep 1, 2021, 12:06 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 31/08/2021 22:31, Joel Sherrill wrote:
> > On Tue, Aug 31, 2021, 7:31 AM Sebastian Huber
> >  > > wrote:
> >
> > Use EAGIN instead of EWOULDBLOCK to be in line with the Linux man
> page.
> >
> >
> > EAGAIN AND Linux man page for what?
>
> The behaviour of the futex operations is defined by Linux:
>
> https://man7.org/linux/man-pages/man2/futex.2.html
>
> Using the same error numbers helps to avoid confusion.
>
> When you look at the history of the Linux man page you see that they
> replaced EWOULDBLOCK with EAGAIN over time. At the time of the RTEMS
> futex implementation they used EWOULDBLOCK.
>

Thanks. Just toss that in the commit. And perhaps somewhere the
documentation should say this is aligned with Linux

>
> --
> 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: Document Futex Handler

2021-09-01 Thread Sebastian Huber 



On 01/09/2021 14:03, Joel Sherrill wrote:



On Wed, Sep 1, 2021, 12:06 AM Sebastian Huber 
> wrote:


On 31/08/2021 22:31, Joel Sherrill wrote:
 > On Tue, Aug 31, 2021, 7:31 AM Sebastian Huber
 > mailto:sebastian.hu...@embedded-brains.de>
 > >> wrote:
 >
 >     Use EAGIN instead of EWOULDBLOCK to be in line with the Linux
man page.
 >
 >
 > EAGAIN AND Linux man page for what?

The behaviour of the futex operations is defined by Linux:

https://man7.org/linux/man-pages/man2/futex.2.html


Using the same error numbers helps to avoid confusion.

When you look at the history of the Linux man page you see that they
replaced EWOULDBLOCK with EAGAIN over time. At the time of the RTEMS
futex implementation they used EWOULDBLOCK.


Thanks. Just toss that in the commit. And perhaps somewhere the 
documentation should say this is aligned with Linux


Maybe something like this from the commit?

+/**
+ * @defgroup RTEMSScoreFutex Futex Handler
+ *
+ * @ingroup RTEMSScore
+ *
+ * @brief This group contains the Futex Handler implementation.
+ *
+ * The behaviour of the futex operations is defined by Linux, see also:
+ *
+ * https://man7.org/linux/man-pages/man2/futex.2.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] score: Document Futex Handler

2021-09-01 Thread Joel Sherrill 
On Wed, Sep 1, 2021 at 7:04 AM Sebastian Huber
 wrote:
>
>
>
> On 01/09/2021 14:03, Joel Sherrill wrote:
> >
> >
> > On Wed, Sep 1, 2021, 12:06 AM Sebastian Huber
> >  > > wrote:
> >
> > On 31/08/2021 22:31, Joel Sherrill wrote:
> >  > On Tue, Aug 31, 2021, 7:31 AM Sebastian Huber
> >  >  > 
> >  >  > >> wrote:
> >  >
> >  > Use EAGIN instead of EWOULDBLOCK to be in line with the Linux
> > man page.
> >  >
> >  >
> >  > EAGAIN AND Linux man page for what?
> >
> > The behaviour of the futex operations is defined by Linux:
> >
> > https://man7.org/linux/man-pages/man2/futex.2.html
> > 
> >
> > Using the same error numbers helps to avoid confusion.
> >
> > When you look at the history of the Linux man page you see that they
> > replaced EWOULDBLOCK with EAGAIN over time. At the time of the RTEMS
> > futex implementation they used EWOULDBLOCK.
> >
> >
> > Thanks. Just toss that in the commit. And perhaps somewhere the
> > documentation should say this is aligned with Linux
>
> Maybe something like this from the commit?

That looks good. Our future selves will appreciate the hint that this
is intended
to follow that API.

The comment says behaviour. Do we provide a compatible API at some level?
>
> +/**
> + * @defgroup RTEMSScoreFutex Futex Handler
> + *
> + * @ingroup RTEMSScore
> + *
> + * @brief This group contains the Futex Handler implementation.
> + *
> + * The behaviour of the futex operations is defined by Linux, see also:
> + *
> + * https://man7.org/linux/man-pages/man2/futex.2.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] score: Document Futex Handler

2021-09-01 Thread Sebastian Huber 

On 01/09/2021 14:45, Joel Sherrill wrote:

The comment says behaviour. Do we provide a compatible API at some level?


To some extent the API is compatible. The futex support is used for the 
OpenMP support in GCC (libgomp). We are able to use the Linux futex 
barrier implementation nearly one-to-one. The main difference is that in 
RTEMS we directly provide a futex object which contains the thread 
queue. In Linux a mapping from the physical address of the futex state 
to some futex object must be done.


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

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

[PATCH rtems] bsps/imxrt: Improve SPI driver

2021-09-01 Thread Christian Mauderer 
It wasn't possible to keep the CS line low between multiple message
descriptors in one transfer. This patch reworks the driver so that it is
possible.

Update #4180
---
 bsps/arm/imxrt/spi/imxrt-lpspi.c | 197 +++
 1 file changed, 124 insertions(+), 73 deletions(-)

diff --git a/bsps/arm/imxrt/spi/imxrt-lpspi.c b/bsps/arm/imxrt/spi/imxrt-lpspi.c
index 06d8f715d9..80b47f9663 100644
--- a/bsps/arm/imxrt/spi/imxrt-lpspi.c
+++ b/bsps/arm/imxrt/spi/imxrt-lpspi.c
@@ -43,16 +43,19 @@ struct imxrt_lpspi_bus {
   uint32_t src_clock_hz;
   clock_ip_name_t clock_ip;
 
-  uint32_t msg_todo;
-  const spi_ioc_transfer *msg;
   rtems_binary_semaphore sem;
-  uint32_t tcr;
+  bool cs_change_on_last_msg;
 
+  uint32_t rx_msg_todo;
+  const spi_ioc_transfer *rx_msg;
   size_t remaining_rx_size;
   uint8_t *rx_buf;
 
+  uint32_t tx_msg_todo;
+  const spi_ioc_transfer *tx_msg;
   size_t remaining_tx_size;
   const uint8_t *tx_buf;
+
   uint32_t fifo_size;
 };
 
@@ -146,11 +149,7 @@ static void imxrt_lpspi_config(
   }
 
   tcr |= LPSPI_TCR_PCS(msg->cs);
-
-  if (!msg->cs_change) {
-tcr |= LPSPI_TCR_CONT_MASK;
-  }
-
+  tcr |= LPSPI_TCR_CONT_MASK;
   tcr |= LPSPI_TCR_FRAMESZ(word_size-1);
 
   if (ccr_orig != ccr) {
@@ -159,9 +158,13 @@ static void imxrt_lpspi_config(
 regs->CR |= LPSPI_CR_MEN_MASK;
   }
 
-  /* No CONTC on first write. Otherwise upper 8 bits are not written. */
-  regs->TCR = tcr;
-  regs->TCR = tcr | LPSPI_TCR_CONTC_MASK | LPSPI_TCR_CONT_MASK;
+  if (bus->cs_change_on_last_msg) {
+/* No CONTC on first write. Otherwise upper 8 bits are not written. */
+regs->TCR = tcr;
+  }
+  regs->TCR = tcr | LPSPI_TCR_CONTC_MASK;
+
+  bus->cs_change_on_last_msg = msg->cs_change;
 }
 
 static inline bool imxrt_lpspi_rx_fifo_not_empty(
@@ -184,48 +187,72 @@ static inline bool imxrt_lpspi_tx_fifo_not_full(
   bus->fifo_size - 2;
 }
 
+static void imxrt_lpspi_next_tx_msg(
+  struct imxrt_lpspi_bus *bus,
+  volatile LPSPI_Type *regs
+)
+{
+  if (bus->tx_msg_todo > 0) {
+const spi_ioc_transfer *msg;
+
+msg = bus->tx_msg;
+
+imxrt_lpspi_config(bus, regs, msg);
+bus->remaining_tx_size = msg->len;
+bus->tx_buf = msg->tx_buf;
+  }
+}
+
 static void imxrt_lpspi_fill_tx_fifo(
   struct imxrt_lpspi_bus *bus,
   volatile LPSPI_Type *regs
 )
 {
   while(imxrt_lpspi_tx_fifo_not_full(bus, regs)
-  && bus->remaining_tx_size > 0) {
-if (bus->remaining_tx_size == 1) {
-  regs->TCR &= ~(LPSPI_TCR_CONT_MASK);
-}
+  && (bus->tx_msg_todo > 0 || bus->remaining_tx_size > 0)) {
+if (bus->remaining_tx_size > 0) {
+  if (bus->remaining_tx_size == 1 && bus->tx_msg->cs_change) {
+/*
+ * Necessary for getting the last data out of the Rx FIFO. See "i.MX
+ * RT1050 Processor Reference Manual Rev. 4" Chapter 47.3.2.2 "Receive
+ * FIFO and Data Match":
+ *
+ * "During a continuous transfer, if the transmit FIFO is empty, then
+ * the receive data is only written to the receive FIFO after the
+ * transmit FIFO is written or after the Transmit Command Register 
(TCR)
+ * is written to end the frame."
+ */
+regs->TCR &= ~(LPSPI_TCR_CONT_MASK);
+  }
 
-if (bus->tx_buf != NULL) {
-  regs->TDR = bus->tx_buf[0];
-  ++bus->tx_buf;
-} else {
-  regs->TDR = 0;
+  if (bus->tx_buf != NULL) {
+regs->TDR = bus->tx_buf[0];
+++bus->tx_buf;
+  } else {
+regs->TDR = 0;
+  }
+  --bus->remaining_tx_size;
+}
+if (bus->remaining_tx_size == 0) {
+  --bus->tx_msg_todo;
+  ++bus->tx_msg;
+  imxrt_lpspi_next_tx_msg(bus, regs);
 }
---bus->remaining_tx_size;
   }
 }
 
-static void imxrt_lpspi_next_msg(
+static void imxrt_lpspi_next_rx_msg(
   struct imxrt_lpspi_bus *bus,
   volatile LPSPI_Type *regs
 )
 {
-  if (bus->msg_todo > 0) {
+  if (bus->rx_msg_todo > 0) {
 const spi_ioc_transfer *msg;
 
-msg = bus->msg;
+msg = bus->rx_msg;
 
-imxrt_lpspi_config(bus, regs, msg);
-bus->remaining_tx_size = msg->len;
 bus->remaining_rx_size = msg->len;
 bus->rx_buf = msg->rx_buf;
-bus->tx_buf = msg->tx_buf;
-
-imxrt_lpspi_fill_tx_fifo(bus, regs);
-regs->IER = LPSPI_IER_TDIE_MASK;
-  } else {
-regs->IER = 0;
-rtems_binary_semaphore_post(&bus->sem);
   }
 }
 
@@ -234,15 +261,22 @@ static void imxrt_lpspi_pull_data_from_rx_fifo(
   volatile LPSPI_Type *regs
 )
 {
-  while (imxrt_lpspi_rx_fifo_not_empty(regs) && bus->remaining_rx_size > 0) {
-uint32_t data;
-
-data = regs->RDR;
-if (bus->rx_buf != NULL) {
-  *bus->rx_buf = data;
-  ++bus->rx_buf;
+  uint32_t data;
+  while (imxrt_lpspi_rx_fifo_not_empty(regs)
+  && (bus->rx_msg_todo > 0 || bus->remaining_rx_size > 0)) {
+if (bus->remaining_rx_size > 0) {
+  data = regs->RDR;
+  if (bus->rx_buf != NULL) {
+*bus->rx_buf = data;
+++bus->rx_buf;
+  }
+  --bus->remaining_rx_size;
+

Re: [PATCH v1 3/5] cpukit/aarch64: Add Exception Manager support

2021-09-01 Thread Sebastian Huber 

On 24/08/2021 01:50, Kinsey Moore wrote:

diff --git a/cpukit/score/cpu/aarch64/aarch64-exception-default.c 
b/cpukit/score/cpu/aarch64/aarch64-exception-default.c
index 2ebb3dee9f..e51e9453e1 100644
--- a/cpukit/score/cpu/aarch64/aarch64-exception-default.c
+++ b/cpukit/score/cpu/aarch64/aarch64-exception-default.c
@@ -43,8 +43,61 @@
  
  #include 

  #include 
+#include 
  
  void _AArch64_Exception_default( CPU_Exception_frame *frame )

  {
-  rtems_fatal( RTEMS_FATAL_SOURCE_EXCEPTION, (rtems_fatal_code) frame );
+  if ( rtems_exception_manage( frame ) == false ) {
+rtems_fatal( RTEMS_FATAL_SOURCE_EXCEPTION, (rtems_fatal_code) frame );
+  }
+}


This is exactly the approach I don't like. I don't think we need a new 
user extension for this. We can do the exception to signal mapping also 
in a fatal error extension.


We should avoid changes in the RTEMS API unless it is really necessary. 
 Using an existing extension is preferable to adding new ones.


The normal action in case a non-interrupt exception occurs is to log the 
context and then restart the system. For this, we only need an exception 
prologue which calls rtems_fatal() as robust and safe as possible. In 
particular, it should not use the stack of the context which caused the 
exception. Non-interrupt exceptions in the field are usually due to some 
abnormal program behaviour which usually happens rarely. Getting a good 
context of the error is important. Recursive exceptions due to errors in 
the exception handling are very bad in this respect.


Since rtems_fatal() does not return to the caller, we don't need an 
exception epilogue after the rtems_fatal() call. Such an epilogue would 
be dead code in most systems. I spent a lot of time in the past to avoid 
dead code, so this is one of the reasons why I don't like the proposed 
approach.


If a fatal error extension determined that it is safe to resume 
execution, then it could simply call a new architecture-specific 
function which uses the CPU exception frame to continue execution. This 
function is basically something like the exception epilogue which you 
have on AArch64 right now. The only difference is that it is not 
executed after a return from _AArch64_Exception_default() and instead 
explicitly invoked by a function call, for example 
_CPU_Exception_return( frame ).


So, my proposal would be something like this:

1. Processor jumps to exception prologue

2. Exception prologue saves the context to CPU exception frame

3. Exception prologue calls rtems_fatal() which does not return

For the signal mapping you provide a fatal extension:

1. If the source is not RTEMS_FATAL_SOURCE_EXCEPTION, then return 
(system terminates).


2. If the exception type cannot be handled, then return (system terminates).

3. Add a post-switch action to the executing thread.

4. Call _CPU_Exception_return( frame )

The  _CPU_Exception_return( frame ) should:

1. Save the CPU exception return information to the stack of the 
executing thread.


2. Switch to the stack of the executing thread and to thread context 
with interrupts disabled.


3. Do something similar to the interrupt return.

4. The thread dispatch will call the post-switch extension which could 
raise a signal.


This approach avoids a new user extension and it avoids a potentially 
dead code in the exception epilogue.



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

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

Re: [PATCH v1 3/5] cpukit/aarch64: Add Exception Manager support

2021-09-01 Thread Sebastian Huber 

On 01/09/2021 17:48, Sebastian Huber wrote:

So, my proposal would be something like this:

1. Processor jumps to exception prologue

2. Exception prologue saves the context to CPU exception frame

3. Exception prologue calls rtems_fatal() which does not return

For the signal mapping you provide a fatal extension:

1. If the source is not RTEMS_FATAL_SOURCE_EXCEPTION, then return 
(system terminates).


2. If the exception type cannot be handled, then return (system 
terminates).


3. Add a post-switch action to the executing thread.

4. Call _CPU_Exception_return( frame )

The  _CPU_Exception_return( frame ) should:

1. Save the CPU exception return information to the stack of the 
executing thread.


2. Switch to the stack of the executing thread and to thread context 
with interrupts disabled.


3. Do something similar to the interrupt return.

4. The thread dispatch will call the post-switch extension which could 
raise a signal.


This approach avoids a new user extension and it avoids a potentially 
dead code in the exception epilogue.


Chris, I guess you have something like this

_CPU_Exception_return( frame )

in libdebugger currently?

--
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] bsps/imxrt: Improve SPI driver

2021-09-01 Thread Gedare Bloom 
looks ok, touching imxrt driver only

On Wed, Sep 1, 2021 at 7:55 AM Christian Mauderer
 wrote:
>
> It wasn't possible to keep the CS line low between multiple message
> descriptors in one transfer. This patch reworks the driver so that it is
> possible.
>
> Update #4180
> ---
>  bsps/arm/imxrt/spi/imxrt-lpspi.c | 197 +++
>  1 file changed, 124 insertions(+), 73 deletions(-)
>
> diff --git a/bsps/arm/imxrt/spi/imxrt-lpspi.c 
> b/bsps/arm/imxrt/spi/imxrt-lpspi.c
> index 06d8f715d9..80b47f9663 100644
> --- a/bsps/arm/imxrt/spi/imxrt-lpspi.c
> +++ b/bsps/arm/imxrt/spi/imxrt-lpspi.c
> @@ -43,16 +43,19 @@ struct imxrt_lpspi_bus {
>uint32_t src_clock_hz;
>clock_ip_name_t clock_ip;
>
> -  uint32_t msg_todo;
> -  const spi_ioc_transfer *msg;
>rtems_binary_semaphore sem;
> -  uint32_t tcr;
> +  bool cs_change_on_last_msg;
>
> +  uint32_t rx_msg_todo;
> +  const spi_ioc_transfer *rx_msg;
>size_t remaining_rx_size;
>uint8_t *rx_buf;
>
> +  uint32_t tx_msg_todo;
> +  const spi_ioc_transfer *tx_msg;
>size_t remaining_tx_size;
>const uint8_t *tx_buf;
> +
>uint32_t fifo_size;
>  };
>
> @@ -146,11 +149,7 @@ static void imxrt_lpspi_config(
>}
>
>tcr |= LPSPI_TCR_PCS(msg->cs);
> -
> -  if (!msg->cs_change) {
> -tcr |= LPSPI_TCR_CONT_MASK;
> -  }
> -
> +  tcr |= LPSPI_TCR_CONT_MASK;
>tcr |= LPSPI_TCR_FRAMESZ(word_size-1);
>
>if (ccr_orig != ccr) {
> @@ -159,9 +158,13 @@ static void imxrt_lpspi_config(
>  regs->CR |= LPSPI_CR_MEN_MASK;
>}
>
> -  /* No CONTC on first write. Otherwise upper 8 bits are not written. */
> -  regs->TCR = tcr;
> -  regs->TCR = tcr | LPSPI_TCR_CONTC_MASK | LPSPI_TCR_CONT_MASK;
> +  if (bus->cs_change_on_last_msg) {
> +/* No CONTC on first write. Otherwise upper 8 bits are not written. */
> +regs->TCR = tcr;
> +  }
> +  regs->TCR = tcr | LPSPI_TCR_CONTC_MASK;
> +
> +  bus->cs_change_on_last_msg = msg->cs_change;
>  }
>
>  static inline bool imxrt_lpspi_rx_fifo_not_empty(
> @@ -184,48 +187,72 @@ static inline bool imxrt_lpspi_tx_fifo_not_full(
>bus->fifo_size - 2;
>  }
>
> +static void imxrt_lpspi_next_tx_msg(
> +  struct imxrt_lpspi_bus *bus,
> +  volatile LPSPI_Type *regs
> +)
> +{
> +  if (bus->tx_msg_todo > 0) {
> +const spi_ioc_transfer *msg;
> +
> +msg = bus->tx_msg;
> +
> +imxrt_lpspi_config(bus, regs, msg);
> +bus->remaining_tx_size = msg->len;
> +bus->tx_buf = msg->tx_buf;
> +  }
> +}
> +
>  static void imxrt_lpspi_fill_tx_fifo(
>struct imxrt_lpspi_bus *bus,
>volatile LPSPI_Type *regs
>  )
>  {
>while(imxrt_lpspi_tx_fifo_not_full(bus, regs)
> -  && bus->remaining_tx_size > 0) {
> -if (bus->remaining_tx_size == 1) {
> -  regs->TCR &= ~(LPSPI_TCR_CONT_MASK);
> -}
> +  && (bus->tx_msg_todo > 0 || bus->remaining_tx_size > 0)) {
> +if (bus->remaining_tx_size > 0) {
> +  if (bus->remaining_tx_size == 1 && bus->tx_msg->cs_change) {
> +/*
> + * Necessary for getting the last data out of the Rx FIFO. See "i.MX
> + * RT1050 Processor Reference Manual Rev. 4" Chapter 47.3.2.2 
> "Receive
> + * FIFO and Data Match":
> + *
> + * "During a continuous transfer, if the transmit FIFO is empty, then
> + * the receive data is only written to the receive FIFO after the
> + * transmit FIFO is written or after the Transmit Command Register 
> (TCR)
> + * is written to end the frame."
> + */
> +regs->TCR &= ~(LPSPI_TCR_CONT_MASK);
> +  }
>
> -if (bus->tx_buf != NULL) {
> -  regs->TDR = bus->tx_buf[0];
> -  ++bus->tx_buf;
> -} else {
> -  regs->TDR = 0;
> +  if (bus->tx_buf != NULL) {
> +regs->TDR = bus->tx_buf[0];
> +++bus->tx_buf;
> +  } else {
> +regs->TDR = 0;
> +  }
> +  --bus->remaining_tx_size;
> +}
> +if (bus->remaining_tx_size == 0) {
> +  --bus->tx_msg_todo;
> +  ++bus->tx_msg;
> +  imxrt_lpspi_next_tx_msg(bus, regs);
>  }
> ---bus->remaining_tx_size;
>}
>  }
>
> -static void imxrt_lpspi_next_msg(
> +static void imxrt_lpspi_next_rx_msg(
>struct imxrt_lpspi_bus *bus,
>volatile LPSPI_Type *regs
>  )
>  {
> -  if (bus->msg_todo > 0) {
> +  if (bus->rx_msg_todo > 0) {
>  const spi_ioc_transfer *msg;
>
> -msg = bus->msg;
> +msg = bus->rx_msg;
>
> -imxrt_lpspi_config(bus, regs, msg);
> -bus->remaining_tx_size = msg->len;
>  bus->remaining_rx_size = msg->len;
>  bus->rx_buf = msg->rx_buf;
> -bus->tx_buf = msg->tx_buf;
> -
> -imxrt_lpspi_fill_tx_fifo(bus, regs);
> -regs->IER = LPSPI_IER_TDIE_MASK;
> -  } else {
> -regs->IER = 0;
> -rtems_binary_semaphore_post(&bus->sem);
>}
>  }
>
> @@ -234,15 +261,22 @@ static void imxrt_lpspi_pull_data_from_rx_fifo(
>volatile LPSPI_Type *regs
>  )
>  {
> -  while (imxrt_lpspi_rx_fifo_not_empty(regs) && bus->remaining_rx_size > 0) {
> -uint32_t data;
> -
> -data = regs

Re: [PATCH 2/5] score: Fix blocking message queue receive

2021-09-01 Thread Gedare Bloom 
On Tue, Aug 31, 2021 at 5:24 AM Sebastian Huber
 wrote:
>
> In order to ensure FIFO fairness across schedulers, the thread queue
> surrender operation must be used to dequeue a thread from the thread
> queue.  The thread queue extract operation is intended for timeouts.
>

Please add a note like this to the doxygen for _Thread_queue_Extract().

> Add _Thread_queue_Resume() which may be used to make extracted or
> surrendered threads ready again.
>
> Remove the now unused _Thread_queue_Extract_critical() function.
>
> Close #4509.
> ---
>  cpukit/include/rtems/score/coremsgimpl.h | 20 
>  cpukit/include/rtems/score/threadqimpl.h | 59 ++--
>  cpukit/score/src/coremsgseize.c  | 20 
>  cpukit/score/src/threadqenqueue.c| 45 ++
>  4 files changed, 62 insertions(+), 82 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/coremsgimpl.h 
> b/cpukit/include/rtems/score/coremsgimpl.h
> index 161cf8f124..7f01769010 100644
> --- a/cpukit/include/rtems/score/coremsgimpl.h
> +++ b/cpukit/include/rtems/score/coremsgimpl.h
> @@ -616,7 +616,8 @@ RTEMS_INLINE_ROUTINE Thread_Control 
> *_CORE_message_queue_Dequeue_receiver(
>Thread_queue_Context*queue_context
>  )
>  {
> -  Thread_Control *the_thread;
> +  Thread_queue_Heads *heads;
> +  Thread_Control *the_thread;
>
>/*
> *  If there are pending messages, then there can't be threads
> @@ -634,14 +635,18 @@ RTEMS_INLINE_ROUTINE Thread_Control 
> *_CORE_message_queue_Dequeue_receiver(
> *  There must be no pending messages if there is a thread waiting to
> *  receive a message.
> */
> -  the_thread = _Thread_queue_First_locked(
> -&the_message_queue->Wait_queue,
> -the_message_queue->operations
> -  );
> -  if ( the_thread == NULL ) {
> +  heads = the_message_queue->Wait_queue.Queue.heads;
> +  if ( heads == NULL ) {
>  return NULL;
>}
>
> +  the_thread = ( *the_message_queue->operations->surrender )(
> +&the_message_queue->Wait_queue.Queue,
> +heads,
> +NULL,
> +queue_context
> +  );
> +
> *(size_t *) the_thread->Wait.return_argument = size;
> the_thread->Wait.count = (uint32_t) submit_type;
>
> @@ -651,9 +656,8 @@ RTEMS_INLINE_ROUTINE Thread_Control 
> *_CORE_message_queue_Dequeue_receiver(
>  size
>);
>
> -  _Thread_queue_Extract_critical(
> +  _Thread_queue_Resume(
>  &the_message_queue->Wait_queue.Queue,
> -the_message_queue->operations,
>  the_thread,
>  queue_context
>);
> diff --git a/cpukit/include/rtems/score/threadqimpl.h 
> b/cpukit/include/rtems/score/threadqimpl.h
> index 2465fc4499..0a24d2da3b 100644
> --- a/cpukit/include/rtems/score/threadqimpl.h
> +++ b/cpukit/include/rtems/score/threadqimpl.h
> @@ -975,56 +975,23 @@ void _Thread_queue_Unblock_critical(
>  );
>
>  /**
> - * @brief Extracts the thread from the thread queue and unblocks it.
> + * @brief Resumes the extracted or surrendered thread.
>   *
> - * The caller must be the owner of the thread queue lock.  This function will
> - * release the thread queue lock and restore the default thread lock.  Thread
> - * dispatching is disabled before the thread queue lock is released and an
> - * unblock is necessary.  Thread dispatching is enabled once the sequence to
> - * unblock the thread is complete.  This makes it possible to use the thread
> - * queue lock to protect the state of objects embedding the thread queue and
> - * directly enter _Thread_queue_Extract_critical() to finalize an operation 
> in
> - * case a waiting thread exists.
> - *
> - * @code
> - * #include 
> - *
> - * typedef struct {
> - *   Thread_queue_Control  Queue;
> - *   Thread_Control   *owner;
> - * } Mutex;
> + * This function makes the thread ready again.  If necessary, the thread is
> + * unblocked and its thread timer removed.
>   *
> - * void _Mutex_Release( Mutex *mutex )
> - * {
> - *   Thread_queue_Context  queue_context;
> - *   Thread_Control   *first;
> - *
> - *   _Thread_queue_Context_initialize( &queue_context, NULL );
> - *   _Thread_queue_Acquire( &mutex->Queue, queue_context );
> - *
> - *   first = _Thread_queue_First_locked( &mutex->Queue );
> - *   mutex->owner = first;
> - *
> - *   if ( first != NULL ) {
> - * _Thread_queue_Extract_critical(
> - *   &mutex->Queue.Queue,
> - *   mutex->Queue.operations,
> - *   first,
> - *   &queue_context
> - *   );
> - * }
> - * @endcode
> + * The thread shall have been extracted from the thread queue or surrendered 
> by
> + * the thread queue right before the call to this function.  The caller shall
> + * be the owner of the thread queue lock.
>   *
> - * @param queue The actual thread queue.
> - * @param operations The thread queue operations.
> - * @param[in, out] the_thread The thread to extract.
> - * @param[in, out] queue_context The thread queue context of the lock 
> acquire.
> + * @param queue is the actual thread queue.
> + * @param[in, out] the_thread is the

Re: [PATCH 5/5] score: Update priority only if necessary

2021-09-01 Thread Gedare Bloom 
ok, just the one note about doxygen. thanks!

On Tue, Aug 31, 2021 at 5:24 AM Sebastian Huber
 wrote:
>
> In _Thread_queue_Flush_critical(), update the priority of the thread
> queue owner only if necessary.  The scheduler update priority operation
> could be expensive.
> ---
>  cpukit/include/rtems/score/threadqimpl.h |  4 ++--
>  cpukit/score/src/threadchangepriority.c  |  2 +-
>  cpukit/score/src/threadqflush.c  | 22 +-
>  3 files changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/threadqimpl.h 
> b/cpukit/include/rtems/score/threadqimpl.h
> index f42c67cc47..33cdb3058d 100644
> --- a/cpukit/include/rtems/score/threadqimpl.h
> +++ b/cpukit/include/rtems/score/threadqimpl.h
> @@ -366,8 +366,8 @@ RTEMS_INLINE_ROUTINE void 
> _Thread_queue_Context_clear_priority_updates(
>   *
>   * @return The priority update count of @a queue_context.
>   */
> -RTEMS_INLINE_ROUTINE size_t _Thread_queue_Context_save_priority_updates(
> -  Thread_queue_Context *queue_context
> +RTEMS_INLINE_ROUTINE size_t _Thread_queue_Context_get_priority_updates(
> +  const Thread_queue_Context *queue_context
>  )
>  {
>return queue_context->Priority.update_count;
> diff --git a/cpukit/score/src/threadchangepriority.c 
> b/cpukit/score/src/threadchangepriority.c
> index ac2e9a6d0c..613d0cd7af 100644
> --- a/cpukit/score/src/threadchangepriority.c
> +++ b/cpukit/score/src/threadchangepriority.c
> @@ -212,7 +212,7 @@ void _Thread_Priority_perform_actions(
> */
>
>the_thread = start_of_path;
> -  update_count = _Thread_queue_Context_save_priority_updates( queue_context 
> );
> +  update_count = _Thread_queue_Context_get_priority_updates( queue_context );
>
>while ( true ) {
>  Thread_queue_Queue *queue;
> diff --git a/cpukit/score/src/threadqflush.c b/cpukit/score/src/threadqflush.c
> index 357e3d696e..42b35a499b 100644
> --- a/cpukit/score/src/threadqflush.c
> +++ b/cpukit/score/src/threadqflush.c
> @@ -71,15 +71,15 @@ size_t _Thread_queue_Flush_critical(
>Thread_queue_Context  *queue_context
>  )
>  {
> -  size_t  flushed;
> -  Chain_Control   unblock;
> -  Thread_Control *owner;
> -  Chain_Node *node;
> -  Chain_Node *tail;
> +  size_tflushed;
> +  size_tpriority_updates;
> +  Chain_Control unblock;
> +  Chain_Node   *node;
> +  Chain_Node   *tail;
>
>flushed = 0;
> +  priority_updates = 0;
>_Chain_Initialize_empty( &unblock );
> -  owner = queue->owner;
>
>while ( true ) {
>  Thread_queue_Heads *heads;
> @@ -99,8 +99,7 @@ size_t _Thread_queue_Flush_critical(
>
>  /*
>   * We do not have enough space in the queue context to collect all 
> priority
> - * updates, so clear it each time.  We unconditionally do the priority
> - * update for the owner later if it exists.
> + * updates, so clear it each time and accumulate the priority updates.
>   */
>  _Thread_queue_Context_clear_priority_updates( queue_context );
>
> @@ -120,6 +119,8 @@ size_t _Thread_queue_Flush_critical(
>);
>  }
>
> +priority_updates +=
> +  _Thread_queue_Context_get_priority_updates( queue_context );
>  ++flushed;
>}
>
> @@ -145,9 +146,12 @@ size_t _Thread_queue_Flush_critical(
>node = next;
>  } while ( node != tail );
>
> -if ( owner != NULL ) {
> +if ( priority_updates != 0 ) {
> +  Thread_Control  *owner;
>ISR_lock_Context lock_context;
>
> +  owner = queue->owner;
> +  _Assert( owner != NULL );
>_Thread_State_acquire( owner, &lock_context );
>_Scheduler_Update_priority( owner );
>_Thread_State_release( owner, &lock_context );
> --
> 2.26.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 rtems v1 1/2] bsps/zynq: Moved general i2c files to shared directories

2021-09-01 Thread Gedare Bloom 
looks fine to me.

On Mon, Aug 23, 2021 at 4:41 PM Stephen Clark  wrote:
>
> Certain files related to the Zynq BSP's I2C driver are useable by the ZynqMP 
> BSP as well.
> Moved these files to shared directory in anticipation of I2C support for 
> ZynqMP.
> ---
>  .../include/bsp => include/dev/i2c}/cadence-i2c-regs.h  | 0
>  .../include/bsp => include/dev/i2c}/cadence-i2c.h   | 0
>  bsps/{arm/xilinx-zynq => shared/dev}/i2c/cadence-i2c.c  | 4 ++--
>  spec/build/bsps/arm/xilinx-zynq/obj.yml | 6 +++---
>  4 files changed, 5 insertions(+), 5 deletions(-)
>  rename bsps/{arm/xilinx-zynq/include/bsp => 
> include/dev/i2c}/cadence-i2c-regs.h (100%)
>  rename bsps/{arm/xilinx-zynq/include/bsp => include/dev/i2c}/cadence-i2c.h 
> (100%)
>  rename bsps/{arm/xilinx-zynq => shared/dev}/i2c/cadence-i2c.c (99%)
>
> diff --git a/bsps/arm/xilinx-zynq/include/bsp/cadence-i2c-regs.h 
> b/bsps/include/dev/i2c/cadence-i2c-regs.h
> similarity index 100%
> rename from bsps/arm/xilinx-zynq/include/bsp/cadence-i2c-regs.h
> rename to bsps/include/dev/i2c/cadence-i2c-regs.h
> diff --git a/bsps/arm/xilinx-zynq/include/bsp/cadence-i2c.h 
> b/bsps/include/dev/i2c/cadence-i2c.h
> similarity index 100%
> rename from bsps/arm/xilinx-zynq/include/bsp/cadence-i2c.h
> rename to bsps/include/dev/i2c/cadence-i2c.h
> diff --git a/bsps/arm/xilinx-zynq/i2c/cadence-i2c.c 
> b/bsps/shared/dev/i2c/cadence-i2c.c
> similarity index 99%
> rename from bsps/arm/xilinx-zynq/i2c/cadence-i2c.c
> rename to bsps/shared/dev/i2c/cadence-i2c.c
> index 07379992ce..91774fb926 100644
> --- a/bsps/arm/xilinx-zynq/i2c/cadence-i2c.c
> +++ b/bsps/shared/dev/i2c/cadence-i2c.c
> @@ -25,8 +25,8 @@
>   * POSSIBILITY OF SUCH DAMAGE.
>   */
>
> -#include 
> -#include 
> +#include 
> +#include 
>
>  #include 
>  #include 
> diff --git a/spec/build/bsps/arm/xilinx-zynq/obj.yml 
> b/spec/build/bsps/arm/xilinx-zynq/obj.yml
> index e81decaa3d..8a11a45dd3 100644
> --- a/spec/build/bsps/arm/xilinx-zynq/obj.yml
> +++ b/spec/build/bsps/arm/xilinx-zynq/obj.yml
> @@ -14,8 +14,8 @@ install:
>- bsps/arm/xilinx-zynq/include/tm27.h
>  - destination: ${BSP_INCLUDEDIR}/bsp
>source:
> -  - bsps/arm/xilinx-zynq/include/bsp/cadence-i2c-regs.h
> -  - bsps/arm/xilinx-zynq/include/bsp/cadence-i2c.h
> +  - bsps/include/dev/i2c/cadence-i2c-regs.h
> +  - bsps/include/dev/i2c/cadence-i2c.h
>- bsps/arm/xilinx-zynq/include/bsp/i2c.h
>- bsps/arm/xilinx-zynq/include/bsp/irq.h
>  links: []
> @@ -28,7 +28,7 @@ source:
>  - bsps/arm/xilinx-zynq/console/console-config.c
>  - bsps/arm/xilinx-zynq/console/console-init.c
>  - bsps/arm/xilinx-zynq/console/debug-console.c
> -- bsps/arm/xilinx-zynq/i2c/cadence-i2c.c
> +- bsps/shared/dev/i2c/cadence-i2c.c
>  - bsps/arm/xilinx-zynq/start/bspreset.c
>  - bsps/arm/xilinx-zynq/start/bspstart.c
>  - bsps/arm/xilinx-zynq/start/bspstarthooks.c
> --
> 2.27.0
>
> ___
> 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 3/3] rld-dwarf.cpp: Initialize member variables

2021-09-01 Thread Gedare Bloom 
seems alright to me.

On Tue, Aug 24, 2021 at 11:14 AM Ryan Long  wrote:
>
> Initialize member variables not listed.
>
> CID 1503019: Uninitialized scalar field.
>
> Closes #4500
> ---
>  rtemstoolkit/rld-dwarf.cpp | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/rtemstoolkit/rld-dwarf.cpp b/rtemstoolkit/rld-dwarf.cpp
> index 1eae50c..2d6f306 100644
> --- a/rtemstoolkit/rld-dwarf.cpp
> +++ b/rtemstoolkit/rld-dwarf.cpp
> @@ -679,12 +679,18 @@ namespace rld
>  machine_code_ (false),
>  external_ (false),
>  declaration_ (false),
> +prototyped_ (false),
>  inline_ (DW_INL_not_inlined),
>  entry_pc_ (0),
>  has_entry_pc_ (false),
>  pc_low_ (0),
>  pc_high_ (0),
>  ranges_ (debug),
> +name_ (),
> +linkage_name_ (),
> +decl_file_ (),
> +decl_line_ (0),
> +call_file_ (),
>  call_line_ (0)
>  {
>dwarf_bool db;
> @@ -819,6 +825,7 @@ namespace rld
>  machine_code_ (orig.machine_code_),
>  external_ (orig.external_),
>  declaration_ (orig.declaration_),
> +prototyped_ (orig.prototyped_),
>  inline_ (orig.inline_),
>  entry_pc_ (orig.entry_pc_),
>  has_entry_pc_ (orig.has_entry_pc_),
> @@ -827,6 +834,8 @@ namespace rld
>  ranges_ (orig.ranges_),
>  name_ (orig.name_),
>  linkage_name_ (orig.linkage_name_),
> +decl_file_ (orig.decl_file_),
> +decl_line_ (orig.decl_line_),
>  call_file_ (orig.call_file_),
>  call_line_ (orig.call_line_)
>  {
> @@ -986,7 +995,10 @@ namespace rld
>  ranges_ = rhs.ranges_;
>  name_ = rhs.name_;
>  linkage_name_ = rhs.linkage_name_;
> +decl_file_ = rhs.decl_file_;
> +decl_line_ = rhs.decl_line_;
>  call_file_ = rhs.call_file_;
> +call_line_ = rhs.call_line_;
>}
>return *this;
>  }
> --
> 1.8.3.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1 3/5] cpukit/aarch64: Add Exception Manager support

2021-09-01 Thread Kinsey Moore 

On 9/1/2021 10:58, Sebastian Huber wrote:

On 01/09/2021 17:48, Sebastian Huber wrote:

So, my proposal would be something like this:

1. Processor jumps to exception prologue

2. Exception prologue saves the context to CPU exception frame

3. Exception prologue calls rtems_fatal() which does not return

For the signal mapping you provide a fatal extension:

1. If the source is not RTEMS_FATAL_SOURCE_EXCEPTION, then return 
(system terminates).


2. If the exception type cannot be handled, then return (system 
terminates).


3. Add a post-switch action to the executing thread.

4. Call _CPU_Exception_return( frame )

The  _CPU_Exception_return( frame ) should:

1. Save the CPU exception return information to the stack of the 
executing thread.


2. Switch to the stack of the executing thread and to thread context 
with interrupts disabled.


3. Do something similar to the interrupt return.

4. The thread dispatch will call the post-switch extension which 
could raise a signal.


This approach avoids a new user extension and it avoids a potentially 
dead code in the exception epilogue.


Chris, I guess you have something like this

_CPU_Exception_return( frame )

in libdebugger currently?

I expected that since libdebugger wasn't built on the fatal error 
extension mechanism that it wasn't suitable for that type of functionality.


One thing I've been trying to avoid with the current approach is manual 
unwinding of the exception stack and the side-effects of other fatal 
error extensions. I suppose I could orchestrate the ordering of existing 
extensions such that recoverable exception handlers run before anything 
else.



Kinsey

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

[PATCH] TraceWriterQEMU.cc: Initialize header._pad

2021-09-01 Thread Ryan Long 
CID 1506204: Uninitialized scalar variable

Closes #4488
---
 tester/covoar/TraceWriterQEMU.cc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tester/covoar/TraceWriterQEMU.cc b/tester/covoar/TraceWriterQEMU.cc
index c417745..cc849b6 100644
--- a/tester/covoar/TraceWriterQEMU.cc
+++ b/tester/covoar/TraceWriterQEMU.cc
@@ -113,6 +113,7 @@ namespace Trace {
 header.big_endian = false;
 header.machine[0] = 0; // XXX ??
 header.machine[1] = 0; // XXX ??
+header._pad = 0;
 status = ::fwrite( &header, sizeof(trace_header), 1, traceFile );
 if (status != 1) {
   std::cerr << "Unable to write header to " << file << std::endl;
-- 
1.8.3.1

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

[PATCH rtems-tools v1 0/4] Initialize pointer fields

2021-09-01 Thread Ryan Long 
Hi,

These patches will get rid of the "Uninitialized pointer field" Coverity
issues. I noticed that some other member variables were not initialized
while doing this, so I initialized them as well.

Thanks,
Ryan

Ryan Long (4):
  DesiredSymbols.h: Initialize symbolInfo
  GcovFunctionData.cc: Initialize member variables
  record-filter-zlib.cc: Initialize stream_'s fields
  ObjdumpProcessor.h: Remove inputBuffer_m

 tester/covoar/DesiredSymbols.h |  1 +
 tester/covoar/GcovFunctionData.cc  | 10 +++---
 tester/covoar/ObjdumpProcessor.h   |  5 -
 trace/record/record-filter-zlib.cc | 13 +
 4 files changed, 21 insertions(+), 8 deletions(-)

-- 
1.8.3.1

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

[PATCH rtems-tools v1 3/4] record-filter-zlib.cc: Initialize stream_'s fields

2021-09-01 Thread Ryan Long 
CID 1503020: Uninitialized pointer field

Closes #4434
---
 trace/record/record-filter-zlib.cc | 13 +
 1 file changed, 13 insertions(+)

diff --git a/trace/record/record-filter-zlib.cc 
b/trace/record/record-filter-zlib.cc
index 87b2cfe..62f1171 100644
--- a/trace/record/record-filter-zlib.cc
+++ b/trace/record/record-filter-zlib.cc
@@ -35,6 +35,19 @@
 
 ZlibFilter::ZlibFilter() : buffer_(65536)
 {
+  stream_.next_in   = nullptr;
+  stream_.avail_in  = 0;
+  stream_.total_in  = 0;
+  stream_.next_out  = nullptr;
+  stream_.avail_out = 0;
+  stream_.total_out = 0;
+  stream_.msg   = nullptr;
+  stream_.zalloc= nullptr;
+  stream_.zfree = nullptr;
+  stream_.opaque= nullptr;
+  stream_.data_type = 0;
+  stream_.adler = 0;
+  stream_.reserved  = 0;
   inflateInit(&stream_);
 }
 
-- 
1.8.3.1

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

[PATCH rtems-tools v1 1/4] DesiredSymbols.h: Initialize symbolInfo

2021-09-01 Thread Ryan Long 
CID 1399627: Uninitialized pointer field

Closes #4433
---
 tester/covoar/DesiredSymbols.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tester/covoar/DesiredSymbols.h b/tester/covoar/DesiredSymbols.h
index 7ea3a9a..dbeeb2c 100644
--- a/tester/covoar/DesiredSymbols.h
+++ b/tester/covoar/DesiredSymbols.h
@@ -179,6 +179,7 @@ namespace Coverage {
  */
 SymbolInformation() :
   baseAddress( 0 ),
+  sourceFile( NULL ),
   uncoveredBranches( NULL ),
   uncoveredRanges( NULL ),
   unifiedCoverageMap( NULL )
-- 
1.8.3.1

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

[PATCH rtems-tools v1 2/4] GcovFunctionData.cc: Initialize member variables

2021-09-01 Thread Ryan Long 
CID 1399640: Uninitialized pointer field

Closes #4432
---
 tester/covoar/GcovFunctionData.cc | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/tester/covoar/GcovFunctionData.cc 
b/tester/covoar/GcovFunctionData.cc
index aec04ce..847439b 100644
--- a/tester/covoar/GcovFunctionData.cc
+++ b/tester/covoar/GcovFunctionData.cc
@@ -19,9 +19,13 @@ namespace Gcov {
 
   GcovFunctionData::GcovFunctionData()
   {
-numberOfArcs   = 0;
-numberOfBlocks = 0;
-coverageMap= NULL;
+id  = 0;
+checksum= 0;
+firstLineNumber = 0;
+numberOfBlocks  = 0;
+numberOfArcs= 0;
+coverageMap = NULL;
+symbolInfo  = NULL;
   }
 
   GcovFunctionData::~GcovFunctionData()
-- 
1.8.3.1

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

[PATCH rtems-tools v1 4/4] ObjdumpProcessor.h: Remove inputBuffer_m

2021-09-01 Thread Ryan Long 
Accidentally got left in, so it is being removed.

CID 1506210: Uninitialized pointer field

Closes #4492
---
 tester/covoar/ObjdumpProcessor.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/tester/covoar/ObjdumpProcessor.h b/tester/covoar/ObjdumpProcessor.h
index ed36981..6a207dd 100644
--- a/tester/covoar/ObjdumpProcessor.h
+++ b/tester/covoar/ObjdumpProcessor.h
@@ -184,11 +184,6 @@ namespace Coverage {
 );
 
 /*!
- * This member variable is a buffer for input
- */
-char* inputBuffer_m;
-
-/*!
  * This member variable contains the symbols to be analyzed
  */
 DesiredSymbols& symbolsToAnalyze_m;
-- 
1.8.3.1

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

Re: [PATCH] TraceWriterQEMU.cc: Initialize header._pad

2021-09-01 Thread Gedare Bloom 
ok

On Wed, Sep 1, 2021 at 12:52 PM Ryan Long  wrote:
>
> CID 1506204: Uninitialized scalar variable
>
> Closes #4488
> ---
>  tester/covoar/TraceWriterQEMU.cc | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/tester/covoar/TraceWriterQEMU.cc 
> b/tester/covoar/TraceWriterQEMU.cc
> index c417745..cc849b6 100644
> --- a/tester/covoar/TraceWriterQEMU.cc
> +++ b/tester/covoar/TraceWriterQEMU.cc
> @@ -113,6 +113,7 @@ namespace Trace {
>  header.big_endian = false;
>  header.machine[0] = 0; // XXX ??
>  header.machine[1] = 0; // XXX ??
> +header._pad = 0;
>  status = ::fwrite( &header, sizeof(trace_header), 1, traceFile );
>  if (status != 1) {
>std::cerr << "Unable to write header to " << file << std::endl;
> --
> 1.8.3.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-tools v1 4/4] ObjdumpProcessor.h: Remove inputBuffer_m

2021-09-01 Thread Gedare Bloom 
On Wed, Sep 1, 2021 at 2:00 PM Ryan Long  wrote:
>
> Accidentally got left in, so it is being removed.
>
Change the commit message to say you're removing it because it is
unused. If you want to refer when it accidentally got left in, you can
include the commit hash, but it's not necessary to do so.

Otherwise, the patch series looks good to me.

> CID 1506210: Uninitialized pointer field
>
> Closes #4492
> ---
>  tester/covoar/ObjdumpProcessor.h | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/tester/covoar/ObjdumpProcessor.h 
> b/tester/covoar/ObjdumpProcessor.h
> index ed36981..6a207dd 100644
> --- a/tester/covoar/ObjdumpProcessor.h
> +++ b/tester/covoar/ObjdumpProcessor.h
> @@ -184,11 +184,6 @@ namespace Coverage {
>  );
>
>  /*!
> - * This member variable is a buffer for input
> - */
> -char* inputBuffer_m;
> -
> -/*!
>   * This member variable contains the symbols to be analyzed
>   */
>  DesiredSymbols& symbolsToAnalyze_m;
> --
> 1.8.3.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] TraceWriterQEMU.cc: Change strncpy to memcpy

2021-09-01 Thread Gedare Bloom 
On Thu, Aug 19, 2021 at 7:42 AM Ryan Long  wrote:
>
> CID 1506207: Buffer not null terminated
>
> Closes #4491
> ---
>  tester/covoar/TraceWriterQEMU.cc | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/tester/covoar/TraceWriterQEMU.cc 
> b/tester/covoar/TraceWriterQEMU.cc
> index c417745..be9b6e1 100644
> --- a/tester/covoar/TraceWriterQEMU.cc
> +++ b/tester/covoar/TraceWriterQEMU.cc
> @@ -106,7 +106,10 @@ namespace Trace {
>  //
>  //  Write the Header to the file
>  //
> -strncpy( header.magic, QEMU_TRACE_MAGIC, sizeof(header.magic) );
> +// The header.magic field is actually 12 bytes, but QEMU_TRACE_MAGIC is
> +// 13 bytes including the NULL.
> +const char qemu_trace_magic[13] = QEMU_TRACE_MAGIC;
> +memcpy( header.magic, qemu_trace_magic, sizeof(header.magic) );

Just to clarify, the header.magic should not be NULL terminated?

If so, then this is fine, but I don't think the temporary local
variable is needed though.
memcpy( header.magic, QEMU_TRACE_MAGIC, sizeof(header.magic) );
should work fine.

>  header.version = QEMU_TRACE_VERSION;
>  header.kind= QEMU_TRACE_KIND_RAW;  // XXX ??
>  header.sizeof_target_pc = 32;
> --
> 1.8.3.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH] TraceWriterQEMU.cc: Change strncpy to memcpy

2021-09-01 Thread Ryan Long 



-Original Message-
From: Gedare Bloom  
Sent: Wednesday, September 1, 2021 3:21 PM
To: Ryan Long 
Cc: devel@rtems.org
Subject: Re: [PATCH] TraceWriterQEMU.cc: Change strncpy to memcpy

On Thu, Aug 19, 2021 at 7:42 AM Ryan Long  wrote:
>
> CID 1506207: Buffer not null terminated
>
> Closes #4491
> ---
>  tester/covoar/TraceWriterQEMU.cc | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/tester/covoar/TraceWriterQEMU.cc 
> b/tester/covoar/TraceWriterQEMU.cc
> index c417745..be9b6e1 100644
> --- a/tester/covoar/TraceWriterQEMU.cc
> +++ b/tester/covoar/TraceWriterQEMU.cc
> @@ -106,7 +106,10 @@ namespace Trace {
>  //
>  //  Write the Header to the file
>  //
> -strncpy( header.magic, QEMU_TRACE_MAGIC, sizeof(header.magic) );
> +// The header.magic field is actually 12 bytes, but QEMU_TRACE_MAGIC is
> +// 13 bytes including the NULL.
> +const char qemu_trace_magic[13] = QEMU_TRACE_MAGIC;
> +memcpy( header.magic, qemu_trace_magic, sizeof(header.magic) );

Just to clarify, the header.magic should not be NULL terminated?
[Ryan Long] Correct. When I tried to increase the size of header.magic, it 
wouldn't run correctly.

If so, then this is fine, but I don't think the temporary local variable is 
needed though.
memcpy( header.magic, QEMU_TRACE_MAGIC, sizeof(header.magic) ); should work 
fine.

>  header.version = QEMU_TRACE_VERSION;
>  header.kind= QEMU_TRACE_KIND_RAW;  // XXX ??
>  header.sizeof_target_pc = 32;
> --
> 1.8.3.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] TraceWriterQEMU.cc: Change strncpy to memcpy

2021-09-01 Thread Joel Sherrill 
On Wed, Sep 1, 2021 at 3:26 PM Ryan Long  wrote:
>
>
>
> -Original Message-
> From: Gedare Bloom 
> Sent: Wednesday, September 1, 2021 3:21 PM
> To: Ryan Long 
> Cc: devel@rtems.org
> Subject: Re: [PATCH] TraceWriterQEMU.cc: Change strncpy to memcpy
>
> On Thu, Aug 19, 2021 at 7:42 AM Ryan Long  wrote:
> >
> > CID 1506207: Buffer not null terminated
> >
> > Closes #4491
> > ---
> >  tester/covoar/TraceWriterQEMU.cc | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/tester/covoar/TraceWriterQEMU.cc
> > b/tester/covoar/TraceWriterQEMU.cc
> > index c417745..be9b6e1 100644
> > --- a/tester/covoar/TraceWriterQEMU.cc
> > +++ b/tester/covoar/TraceWriterQEMU.cc
> > @@ -106,7 +106,10 @@ namespace Trace {
> >  //
> >  //  Write the Header to the file
> >  //
> > -strncpy( header.magic, QEMU_TRACE_MAGIC, sizeof(header.magic) );
> > +// The header.magic field is actually 12 bytes, but QEMU_TRACE_MAGIC is
> > +// 13 bytes including the NULL.
> > +const char qemu_trace_magic[13] = QEMU_TRACE_MAGIC;
> > +memcpy( header.magic, qemu_trace_magic, sizeof(header.magic) );
>
> Just to clarify, the header.magic should not be NULL terminated?
> [Ryan Long] Correct. When I tried to increase the size of header.magic, it 
> wouldn't run correctly.
>
> If so, then this is fine, but I don't think the temporary local variable is 
> needed though.
> memcpy( header.magic, QEMU_TRACE_MAGIC, sizeof(header.magic) ); should work 
> fine.

The qemu trace format for couverture has that format without the NUL
termination.
I'm not sure in their rationale for doing it that way but it is 12 magic bytes.

>
> >  header.version = QEMU_TRACE_VERSION;
> >  header.kind= QEMU_TRACE_KIND_RAW;  // XXX ??
> >  header.sizeof_target_pc = 32;
> > --
> > 1.8.3.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] TraceWriterQEMU.cc: Initialize header._pad

2021-09-01 Thread Joel Sherrill 
On Wed, Sep 1, 2021 at 3:13 PM Gedare Bloom  wrote:
>
> ok

And stupidly necessary to avoid having uninitialized fields spotted by
static analysis. :(

--joel
>
> On Wed, Sep 1, 2021 at 12:52 PM Ryan Long  wrote:
> >
> > CID 1506204: Uninitialized scalar variable
> >
> > Closes #4488
> > ---
> >  tester/covoar/TraceWriterQEMU.cc | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/tester/covoar/TraceWriterQEMU.cc 
> > b/tester/covoar/TraceWriterQEMU.cc
> > index c417745..cc849b6 100644
> > --- a/tester/covoar/TraceWriterQEMU.cc
> > +++ b/tester/covoar/TraceWriterQEMU.cc
> > @@ -113,6 +113,7 @@ namespace Trace {
> >  header.big_endian = false;
> >  header.machine[0] = 0; // XXX ??
> >  header.machine[1] = 0; // XXX ??
> > +header._pad = 0;
> >  status = ::fwrite( &header, sizeof(trace_header), 1, traceFile );
> >  if (status != 1) {
> >std::cerr << "Unable to write header to " << file << std::endl;
> > --
> > 1.8.3.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Key press to reset

2021-09-01 Thread Chris Johns 
Hi,

I know there has been a configuration option to wait for a key press before a
reset in some cases, ie PC BSP. I am now seeing it on BSPs that did not do this
before but do now. This is with the waf build.

Has something changed that effect the default for this setting?

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

Re: [PATCH rtems-libbsd] imx: Remove ccm functions alredy defined in RTEMS

2021-09-01 Thread Chris Johns 
On 1/9/21 4:24 pm, Christian MAUDERER wrote:
> Hello Gedare and Chris,
> 
> Am 01.09.21 um 07:55 schrieb Chris Johns:
>> On 1/9/21 7:26 am, Gedare Bloom wrote:
>>> Sorry, i think libbsd is still a bit slushy, wait for Chris to ok thx
> 
> I planned to wait for Chris work anyway.

I have pushed the changes so this change is OK to push. Thank you for your
patience and consideration.

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

Re: [PATCH v1 3/3] rld-dwarf.cpp: Initialize member variables

2021-09-01 Thread Chris Johns 
On 25/8/21 3:12 am, Ryan Long wrote:
> Initialize member variables not listed.
> 
> CID 1503019: Uninitialized scalar field.
> 
> Closes #4500
> ---
>  rtemstoolkit/rld-dwarf.cpp | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/rtemstoolkit/rld-dwarf.cpp b/rtemstoolkit/rld-dwarf.cpp
> index 1eae50c..2d6f306 100644
> --- a/rtemstoolkit/rld-dwarf.cpp
> +++ b/rtemstoolkit/rld-dwarf.cpp
> @@ -679,12 +679,18 @@ namespace rld
>  machine_code_ (false),
>  external_ (false),
>  declaration_ (false),
> +prototyped_ (false),
>  inline_ (DW_INL_not_inlined),
>  entry_pc_ (0),
>  has_entry_pc_ (false),
>  pc_low_ (0),
>  pc_high_ (0),
>  ranges_ (debug),
> +name_ (),
> +linkage_name_ (),

Did coverity ask for this to be added? Why do default constructors need to be 
added?

Chris

> +decl_file_ (),
> +decl_line_ (0),
> +call_file_ (),
>  call_line_ (0)
>  {
>dwarf_bool db;
> @@ -819,6 +825,7 @@ namespace rld
>  machine_code_ (orig.machine_code_),
>  external_ (orig.external_),
>  declaration_ (orig.declaration_),
> +prototyped_ (orig.prototyped_),
>  inline_ (orig.inline_),
>  entry_pc_ (orig.entry_pc_),
>  has_entry_pc_ (orig.has_entry_pc_),
> @@ -827,6 +834,8 @@ namespace rld
>  ranges_ (orig.ranges_),
>  name_ (orig.name_),
>  linkage_name_ (orig.linkage_name_),
> +decl_file_ (orig.decl_file_),
> +decl_line_ (orig.decl_line_),
>  call_file_ (orig.call_file_),
>  call_line_ (orig.call_line_)
>  {
> @@ -986,7 +995,10 @@ namespace rld
>  ranges_ = rhs.ranges_;
>  name_ = rhs.name_;
>  linkage_name_ = rhs.linkage_name_;
> +decl_file_ = rhs.decl_file_;
> +decl_line_ = rhs.decl_line_;
>  call_file_ = rhs.call_file_;
> +call_line_ = rhs.call_line_;
>}
>return *this;
>  }
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] score: Document thread queue operations

2021-09-01 Thread Sebastian Huber 
---
 cpukit/include/rtems/score/threadq.h | 44 ++--
 cpukit/include/rtems/score/threadqimpl.h | 17 +
 2 files changed, 51 insertions(+), 10 deletions(-)

diff --git a/cpukit/include/rtems/score/threadq.h 
b/cpukit/include/rtems/score/threadq.h
index 10476888d4..0362f84c98 100644
--- a/cpukit/include/rtems/score/threadq.h
+++ b/cpukit/include/rtems/score/threadq.h
@@ -406,6 +406,7 @@ typedef struct _Thread_queue_Heads {
 } Thread_queue_Heads;
 
 struct Thread_queue_Queue {
+#if defined(RTEMS_SMP)
   /**
* @brief Lock to protect this thread queue.
*
@@ -418,7 +419,6 @@ struct Thread_queue_Queue {
* @see _Thread_queue_Acquire(), _Thread_queue_Acquire_critical() and
* _Thread_queue_Release().
*/
-#if defined(RTEMS_SMP)
   SMP_ticket_lock_Control Lock;
 #endif
 
@@ -517,37 +517,61 @@ typedef Thread_Control *( *Thread_queue_First_operation )(
 );
 
 /**
- * @brief Thread queue operations.
+ * @brief The thread queue operations are used to implement the addition and
+ *   removal of threads to and from a thread queue and related tasks.
+ *
+ * The standard thread queue operation variants are:
+ *
+ * * ::_Thread_queue_Operations_default
+ *
+ * * ::_Thread_queue_Operations_FIFO
+ *
+ * * ::_Thread_queue_Operations_priority
+ *
+ * * ::_Thread_queue_Operations_priority_inherit
  *
  * @see _Thread_wait_Set_operations().
  */
 struct Thread_queue_Operations {
   /**
-   * @brief Thread queue priority actions operation.
+   * @brief This operation performs the thread queue priority actions.
+   *
+   * Priority actions are produced and processed during enqueue, extract, and
+   * surrender operations.
*/
   Thread_queue_Priority_actions_operation priority_actions;
 
   /**
-   * @brief Thread queue enqueue operation.
-   *
-   * Called by object routines to enqueue the thread.
+   * @brief This operation is used to enqueue the thread on the thread queue.
*/
   Thread_queue_Enqueue_operation enqueue;
 
   /**
-   * @brief Thread queue extract operation.
+   * @brief This operation is used to extract the thread from the thread queue.
*
-   * Called by object routines to extract a thread from a thread queue.
+   * The extract operation is intended for timeouts, thread restarts, and
+   * thread cancellation.  The surrender operation should be used to dequeue a
+   * thread from the thread queue.
*/
   Thread_queue_Extract_operation extract;
 
   /**
-   * @brief Thread queue surrender operation.
+   * @brief This operation is used to dequeue the thread from the thread queue
+   *   and optionally surrender the thread queue from a previous owner.
+   *
+   * In addition to the optional surrender, there is a subtle difference
+   * between the extract and dequeue of a thread from a thread queue.  In SMP
+   * configurations, FIFO fairness across schedulers for priority queues is
+   * only ensured for the dequeue operation and not for the extract operation.
*/
   Thread_queue_Surrender_operation surrender;
 
   /**
-   * @brief Thread queue first operation.
+   * @brief This operation returns the first thread on the thread queue.
+   *
+   * This operation shall be called only when the thread queue contains at
+   * least one thread.  Use ::Thread_queue_Queue::heads to determine if a
+   * thread queue is empty.
*/
   Thread_queue_First_operation first;
 };
diff --git a/cpukit/include/rtems/score/threadqimpl.h 
b/cpukit/include/rtems/score/threadqimpl.h
index 33cdb3058d..5d3edaf9e0 100644
--- a/cpukit/include/rtems/score/threadqimpl.h
+++ b/cpukit/include/rtems/score/threadqimpl.h
@@ -1396,12 +1396,29 @@ typedef struct {
 Wait_queue.Queue \
   )
 
+/**
+ * @brief The default thread queue operations are used when a thread is not
+ *   enqueued on a thread queue.
+ */
 extern const Thread_queue_Operations _Thread_queue_Operations_default;
 
+/**
+ * @brief The FIFO thread queue operations are used when a thread is enqueued
+ *   on a thread queue and provide FIFO ordering of enqueued threads.
+ */
 extern const Thread_queue_Operations _Thread_queue_Operations_FIFO;
 
+/**
+ * @brief The FIFO thread queue operations are used when a thread is enqueued
+ *   on a thread queue and provide priority ordering of enqueued threads.
+ */
 extern const Thread_queue_Operations _Thread_queue_Operations_priority;
 
+/**
+ * @brief The FIFO thread queue operations are used when a thread is enqueued
+ *   on a thread queue and provide priority ordering of enqueued threads with
+ *   support for priority inheritance.
+ */
 extern const Thread_queue_Operations _Thread_queue_Operations_priority_inherit;
 
 /**
-- 
2.26.2

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

Re: [PATCH 2/5] score: Fix blocking message queue receive

2021-09-01 Thread Sebastian Huber 

On 01/09/2021 18:58, Gedare Bloom wrote:

On Tue, Aug 31, 2021 at 5:24 AM Sebastian Huber
  wrote:

In order to ensure FIFO fairness across schedulers, the thread queue
surrender operation must be used to dequeue a thread from the thread
queue.  The thread queue extract operation is intended for timeouts.


Please add a note like this to the doxygen for _Thread_queue_Extract().


Thanks for the review. I didn't add this note, but instead I tried to 
add this information to the thread queue operations:


https://lists.rtems.org/pipermail/devel/2021-September/069107.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 rtems-libbsd] imx: Remove ccm functions alredy defined in RTEMS

2021-09-01 Thread Christian MAUDERER 

Am 02.09.21 um 04:57 schrieb Chris Johns:

On 1/9/21 4:24 pm, Christian MAUDERER wrote:

Hello Gedare and Chris,

Am 01.09.21 um 07:55 schrieb Chris Johns:

On 1/9/21 7:26 am, Gedare Bloom wrote:

Sorry, i think libbsd is still a bit slushy, wait for Chris to ok thx


I planned to wait for Chris work anyway.


I have pushed the changes so this change is OK to push. Thank you for your
patience and consideration.

Chris


Hello Chris,

that's great news. Thanks a lot for all your great improvements.

I noted that currently your patches are only on 6-freebsd-12. Do you 
plan to have the same (or a similar) patch set on master too? Background 
of the question: Normally I would push the patch to both branches. But 
if you have a similar patch set pending for master too, I think it would 
be a bad timing if I push my patch now.


Best regards

Christian
--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
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: Document thread queue operations

2021-09-01 Thread Chris Johns 
On 2/9/21 3:50 pm, Sebastian Huber wrote:
> ---
>  cpukit/include/rtems/score/threadq.h | 44 ++--
>  cpukit/include/rtems/score/threadqimpl.h | 17 +
>  2 files changed, 51 insertions(+), 10 deletions(-)
> 
> diff --git a/cpukit/include/rtems/score/threadq.h 
> b/cpukit/include/rtems/score/threadq.h
> index 10476888d4..0362f84c98 100644
> --- a/cpukit/include/rtems/score/threadq.h
> +++ b/cpukit/include/rtems/score/threadq.h
> @@ -406,6 +406,7 @@ typedef struct _Thread_queue_Heads {
>  } Thread_queue_Heads;
>  
>  struct Thread_queue_Queue {
> +#if defined(RTEMS_SMP)
>/**
> * @brief Lock to protect this thread queue.
> *
> @@ -418,7 +419,6 @@ struct Thread_queue_Queue {
> * @see _Thread_queue_Acquire(), _Thread_queue_Acquire_critical() and
> * _Thread_queue_Release().
> */
> -#if defined(RTEMS_SMP)
>SMP_ticket_lock_Control Lock;
>  #endif
>  
> @@ -517,37 +517,61 @@ typedef Thread_Control *( *Thread_queue_First_operation 
> )(
>  );
>  
>  /**
> - * @brief Thread queue operations.
> + * @brief The thread queue operations are used to implement the addition and
> + *   removal of threads to and from a thread queue and related tasks.

Addition and removal? Is there something better, insert and extract?

> + *
> + * The standard thread queue operation variants are:
> + *
> + * * ::_Thread_queue_Operations_default
> + *
> + * * ::_Thread_queue_Operations_FIFO
> + *
> + * * ::_Thread_queue_Operations_priority
> + *
> + * * ::_Thread_queue_Operations_priority_inherit
>   *
>   * @see _Thread_wait_Set_operations().
>   */
>  struct Thread_queue_Operations {
>/**
> -   * @brief Thread queue priority actions operation.
> +   * @brief This operation performs the thread queue priority actions.
> +   *
> +   * Priority actions are produced and processed during enqueue, extract, and
> +   * surrender operations.
> */
>Thread_queue_Priority_actions_operation priority_actions;
>  
>/**
> -   * @brief Thread queue enqueue operation.
> -   *
> -   * Called by object routines to enqueue the thread.
> +   * @brief This operation is used to enqueue the thread on the thread queue.

Where in the queue is the thread inserted?

> */
>Thread_queue_Enqueue_operation enqueue;
>  
>/**
> -   * @brief Thread queue extract operation.
> +   * @brief This operation is used to extract the thread from the thread 
> queue.
> *
> -   * Called by object routines to extract a thread from a thread queue.
> +   * The extract operation is intended for timeouts, thread restarts, and
> +   * thread cancellation.  The surrender operation should be used to dequeue 
> a
> +   * thread from the thread queue.

>From the start, end, or where it is in the queue?

> */
>Thread_queue_Extract_operation extract;
>  
>/**
> -   * @brief Thread queue surrender operation.
> +   * @brief This operation is used to dequeue the thread from the thread 
> queue
> +   *   and optionally surrender the thread queue from a previous owner.
> +   *
> +   * In addition to the optional surrender, there is a subtle difference
> +   * between the extract and dequeue of a thread from a thread queue.  In SMP
> +   * configurations, FIFO fairness across schedulers for priority queues is
> +   * only ensured for the dequeue operation and not for the extract 
> operation.

Dequeue or extract? There seems to be a mix of terms and I am not 100% if they
are the same or different? There is addition, enqueue, removal, dequeue, 
extract.

I have read the statement about the difference between dequeue and extract and I
am not sure what it means.

> */
>Thread_queue_Surrender_operation surrender;
>  
>/**
> -   * @brief Thread queue first operation.
> +   * @brief This operation returns the first thread on the thread queue.
> +   *
> +   * This operation shall be called only when the thread queue contains at
> +   * least one thread.  Use ::Thread_queue_Queue::heads to determine if a
> +   * thread queue is empty.

Shall? It is implies this call "shall" be made for every call?

> */
>Thread_queue_First_operation first;
>  };
> diff --git a/cpukit/include/rtems/score/threadqimpl.h 
> b/cpukit/include/rtems/score/threadqimpl.h
> index 33cdb3058d..5d3edaf9e0 100644
> --- a/cpukit/include/rtems/score/threadqimpl.h
> +++ b/cpukit/include/rtems/score/threadqimpl.h
> @@ -1396,12 +1396,29 @@ typedef struct {
>  Wait_queue.Queue \
>)
>  
> +/**
> + * @brief The default thread queue operations are used when a thread is not
> + *   enqueued on a thread queue.

What is the default set of operations compared to the operations below?

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

Re: [PATCH rtems-libbsd] imx: Remove ccm functions alredy defined in RTEMS

2021-09-01 Thread Chris Johns 



On 2/9/21 4:35 pm, Christian MAUDERER wrote:
> Am 02.09.21 um 04:57 schrieb Chris Johns:
>> On 1/9/21 4:24 pm, Christian MAUDERER wrote:
>>> Hello Gedare and Chris,
>>>
>>> Am 01.09.21 um 07:55 schrieb Chris Johns:
 On 1/9/21 7:26 am, Gedare Bloom wrote:
> Sorry, i think libbsd is still a bit slushy, wait for Chris to ok thx
>>>
>>> I planned to wait for Chris work anyway.
>>
>> I have pushed the changes so this change is OK to push. Thank you for your
>> patience and consideration.
>>
>> Chris
> 
> Hello Chris,
> 
> that's great news. Thanks a lot for all your great improvements.
> 
> I noted that currently your patches are only on 6-freebsd-12. Do you plan to
> have the same (or a similar) patch set on master too? Background of the
> question: Normally I would push the patch to both branches. But if you have a
> similar patch set pending for master too, I think it would be a bad timing if 
> I
> push my patch now.

Please push to master. It can be handled as part of that task.

I plan too but it is too big a task to get done unfunded. I have not had time to
look at it.

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

Re: [PATCH rtems] bsps/imxrt: Improve SPI driver

2021-09-01 Thread Christian MAUDERER 

Thanks.

Am 01.09.21 um 18:50 schrieb Gedare Bloom:

looks ok, touching imxrt driver only

On Wed, Sep 1, 2021 at 7:55 AM Christian Mauderer
 wrote:


It wasn't possible to keep the CS line low between multiple message
descriptors in one transfer. This patch reworks the driver so that it is
possible.

Update #4180
---
  bsps/arm/imxrt/spi/imxrt-lpspi.c | 197 +++
  1 file changed, 124 insertions(+), 73 deletions(-)

diff --git a/bsps/arm/imxrt/spi/imxrt-lpspi.c b/bsps/arm/imxrt/spi/imxrt-lpspi.c
index 06d8f715d9..80b47f9663 100644
--- a/bsps/arm/imxrt/spi/imxrt-lpspi.c
+++ b/bsps/arm/imxrt/spi/imxrt-lpspi.c
@@ -43,16 +43,19 @@ struct imxrt_lpspi_bus {
uint32_t src_clock_hz;
clock_ip_name_t clock_ip;

-  uint32_t msg_todo;
-  const spi_ioc_transfer *msg;
rtems_binary_semaphore sem;
-  uint32_t tcr;
+  bool cs_change_on_last_msg;

+  uint32_t rx_msg_todo;
+  const spi_ioc_transfer *rx_msg;
size_t remaining_rx_size;
uint8_t *rx_buf;

+  uint32_t tx_msg_todo;
+  const spi_ioc_transfer *tx_msg;
size_t remaining_tx_size;
const uint8_t *tx_buf;
+
uint32_t fifo_size;
  };

@@ -146,11 +149,7 @@ static void imxrt_lpspi_config(
}

tcr |= LPSPI_TCR_PCS(msg->cs);
-
-  if (!msg->cs_change) {
-tcr |= LPSPI_TCR_CONT_MASK;
-  }
-
+  tcr |= LPSPI_TCR_CONT_MASK;
tcr |= LPSPI_TCR_FRAMESZ(word_size-1);

if (ccr_orig != ccr) {
@@ -159,9 +158,13 @@ static void imxrt_lpspi_config(
  regs->CR |= LPSPI_CR_MEN_MASK;
}

-  /* No CONTC on first write. Otherwise upper 8 bits are not written. */
-  regs->TCR = tcr;
-  regs->TCR = tcr | LPSPI_TCR_CONTC_MASK | LPSPI_TCR_CONT_MASK;
+  if (bus->cs_change_on_last_msg) {
+/* No CONTC on first write. Otherwise upper 8 bits are not written. */
+regs->TCR = tcr;
+  }
+  regs->TCR = tcr | LPSPI_TCR_CONTC_MASK;
+
+  bus->cs_change_on_last_msg = msg->cs_change;
  }

  static inline bool imxrt_lpspi_rx_fifo_not_empty(
@@ -184,48 +187,72 @@ static inline bool imxrt_lpspi_tx_fifo_not_full(
bus->fifo_size - 2;
  }

+static void imxrt_lpspi_next_tx_msg(
+  struct imxrt_lpspi_bus *bus,
+  volatile LPSPI_Type *regs
+)
+{
+  if (bus->tx_msg_todo > 0) {
+const spi_ioc_transfer *msg;
+
+msg = bus->tx_msg;
+
+imxrt_lpspi_config(bus, regs, msg);
+bus->remaining_tx_size = msg->len;
+bus->tx_buf = msg->tx_buf;
+  }
+}
+
  static void imxrt_lpspi_fill_tx_fifo(
struct imxrt_lpspi_bus *bus,
volatile LPSPI_Type *regs
  )
  {
while(imxrt_lpspi_tx_fifo_not_full(bus, regs)
-  && bus->remaining_tx_size > 0) {
-if (bus->remaining_tx_size == 1) {
-  regs->TCR &= ~(LPSPI_TCR_CONT_MASK);
-}
+  && (bus->tx_msg_todo > 0 || bus->remaining_tx_size > 0)) {
+if (bus->remaining_tx_size > 0) {
+  if (bus->remaining_tx_size == 1 && bus->tx_msg->cs_change) {
+/*
+ * Necessary for getting the last data out of the Rx FIFO. See "i.MX
+ * RT1050 Processor Reference Manual Rev. 4" Chapter 47.3.2.2 "Receive
+ * FIFO and Data Match":
+ *
+ * "During a continuous transfer, if the transmit FIFO is empty, then
+ * the receive data is only written to the receive FIFO after the
+ * transmit FIFO is written or after the Transmit Command Register 
(TCR)
+ * is written to end the frame."
+ */
+regs->TCR &= ~(LPSPI_TCR_CONT_MASK);
+  }

-if (bus->tx_buf != NULL) {
-  regs->TDR = bus->tx_buf[0];
-  ++bus->tx_buf;
-} else {
-  regs->TDR = 0;
+  if (bus->tx_buf != NULL) {
+regs->TDR = bus->tx_buf[0];
+++bus->tx_buf;
+  } else {
+regs->TDR = 0;
+  }
+  --bus->remaining_tx_size;
+}
+if (bus->remaining_tx_size == 0) {
+  --bus->tx_msg_todo;
+  ++bus->tx_msg;
+  imxrt_lpspi_next_tx_msg(bus, regs);
  }
---bus->remaining_tx_size;
}
  }

-static void imxrt_lpspi_next_msg(
+static void imxrt_lpspi_next_rx_msg(
struct imxrt_lpspi_bus *bus,
volatile LPSPI_Type *regs
  )
  {
-  if (bus->msg_todo > 0) {
+  if (bus->rx_msg_todo > 0) {
  const spi_ioc_transfer *msg;

-msg = bus->msg;
+msg = bus->rx_msg;

-imxrt_lpspi_config(bus, regs, msg);
-bus->remaining_tx_size = msg->len;
  bus->remaining_rx_size = msg->len;
  bus->rx_buf = msg->rx_buf;
-bus->tx_buf = msg->tx_buf;
-
-imxrt_lpspi_fill_tx_fifo(bus, regs);
-regs->IER = LPSPI_IER_TDIE_MASK;
-  } else {
-regs->IER = 0;
-rtems_binary_semaphore_post(&bus->sem);
}
  }

@@ -234,15 +261,22 @@ static void imxrt_lpspi_pull_data_from_rx_fifo(
volatile LPSPI_Type *regs
  )
  {
-  while (imxrt_lpspi_rx_fifo_not_empty(regs) && bus->remaining_rx_size > 0) {
-uint32_t data;
-
-data = regs->RDR;
-if (bus->rx_buf != NULL) {
-  *bus->rx_buf = data;
-  ++bus->rx_buf;
+  uint32_t data;
+  while (imxrt_lpspi_rx_fifo_not_empty(regs)
+  && (bus->rx_msg_todo > 0 || bus->remaining_rx_size > 0)) {
+if (bus->r

Re: [PATCH rtems-libbsd] imx: Remove ccm functions alredy defined in RTEMS

2021-09-01 Thread Christian MAUDERER 

Am 02.09.21 um 08:40 schrieb Chris Johns:



On 2/9/21 4:35 pm, Christian MAUDERER wrote:

Am 02.09.21 um 04:57 schrieb Chris Johns:

On 1/9/21 4:24 pm, Christian MAUDERER wrote:

Hello Gedare and Chris,

Am 01.09.21 um 07:55 schrieb Chris Johns:

On 1/9/21 7:26 am, Gedare Bloom wrote:

Sorry, i think libbsd is still a bit slushy, wait for Chris to ok thx


I planned to wait for Chris work anyway.


I have pushed the changes so this change is OK to push. Thank you for your
patience and consideration.

Chris


Hello Chris,

that's great news. Thanks a lot for all your great improvements.

I noted that currently your patches are only on 6-freebsd-12. Do you plan to
have the same (or a similar) patch set on master too? Background of the
question: Normally I would push the patch to both branches. But if you have a
similar patch set pending for master too, I think it would be a bad timing if I
push my patch now.


Please push to master. It can be handled as part of that task.


OK. Thanks.

Best regards

Christian



I plan too but it is too big a task to get done unfunded. I have not had time to
look at it.

Chris



--

embedded brains GmbH
Herr Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
phone: +49-89-18 94 741 - 18
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