Re: [rtems-central] Add POSIX Timer FACE Behavior Configuration

[Sebastian Huber]

Hello Joel,

On 02/09/2022 18:25, Joel Sherrill wrote:

Updates #4691.
---
  config.yml |  2 ++
  spec/acfg/if/group-face.yml| 30 ++
  spec/acfg/if/posix-timer-face-behavior.yml | 23 +++
  3 files changed, 55 insertions(+)
  create mode 100644 spec/acfg/if/group-face.yml
  create mode 100644 spec/acfg/if/posix-timer-face-behavior.yml


thanks for adding the items. I check it in and regenerated the files in 
RTEMS and the documentation. Sorry for the bad state of rtems-central, I 
hope to clean this up in the next months.


--
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] config: Add SMP scheduler configuration errors

[Sebastian Huber]

Issue an error message if a SMP-specific scheduler is used and RTEMS_SMP
is disabled.  This might be a more informative compared to compiler or
linker errors.
---
 cpukit/include/rtems/scheduler.h | 20 
 1 file changed, 20 insertions(+)

diff --git a/cpukit/include/rtems/scheduler.h b/cpukit/include/rtems/scheduler.h
index d5c7e51ef5..a8004cb5e4 100644
--- a/cpukit/include/rtems/scheduler.h
+++ b/cpukit/include/rtems/scheduler.h
@@ -132,6 +132,10 @@
 #endif
 
 #ifdef CONFIGURE_SCHEDULER_EDF_SMP
+  #ifndef RTEMS_SMP
+#error "CONFIGURE_SCHEDULER_EDF_SMP cannot be used if RTEMS_SMP is 
disabled"
+  #endif
+
   #include 
 
   #ifndef CONFIGURE_MAXIMUM_PROCESSORS
@@ -198,6 +202,10 @@
 #endif
 
 #ifdef CONFIGURE_SCHEDULER_PRIORITY_AFFINITY_SMP
+  #ifndef RTEMS_SMP
+#error "CONFIGURE_SCHEDULER_PRIORITY_AFFINITY_SMP cannot be used if 
RTEMS_SMP is disabled"
+  #endif
+
   #include 
 
   #define SCHEDULER_PRIORITY_AFFINITY_SMP_CONTEXT_NAME( name ) \
@@ -230,6 +238,10 @@
 #endif
 
 #ifdef CONFIGURE_SCHEDULER_PRIORITY_SMP
+  #ifndef RTEMS_SMP
+#error "CONFIGURE_SCHEDULER_PRIORITY_SMP cannot be used if RTEMS_SMP is 
disabled"
+  #endif
+
   #include 
 
   #define SCHEDULER_PRIORITY_SMP_CONTEXT_NAME( name ) \
@@ -262,6 +274,10 @@
 #endif
 
 #ifdef CONFIGURE_SCHEDULER_STRONG_APA
+  #ifndef RTEMS_SMP
+#error "CONFIGURE_SCHEDULER_STRONG_APA cannot be used if RTEMS_SMP is 
disabled"
+  #endif
+
   #include 
 
   #ifndef CONFIGURE_MAXIMUM_PROCESSORS
@@ -324,6 +340,10 @@
 #endif
 
 #ifdef CONFIGURE_SCHEDULER_SIMPLE_SMP
+  #ifndef RTEMS_SMP
+#error "CONFIGURE_SCHEDULER_SIMPLE_SMP cannot be used if RTEMS_SMP is 
disabled"
+  #endif
+
   #include 
 
   #define SCHEDULER_SIMPLE_SMP_CONTEXT_NAME( name ) \
-- 
2.35.3

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

Re: [rtems-central] Add POSIX Timer FACE Behavior Configuration

[Joel Sherrill]

On Mon, Sep 5, 2022, 2:04 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello Joel,
>
> On 02/09/2022 18:25, Joel Sherrill wrote:
> > Updates #4691.
> > ---
> >   config.yml |  2 ++
> >   spec/acfg/if/group-face.yml| 30
> ++
> >   spec/acfg/if/posix-timer-face-behavior.yml | 23 +++
> >   3 files changed, 55 insertions(+)
> >   create mode 100644 spec/acfg/if/group-face.yml
> >   create mode 100644 spec/acfg/if/posix-timer-face-behavior.yml
>
> thanks for adding the items. I check it in and regenerated the files in
> RTEMS and the documentation. Sorry for the bad state of rtems-central, I
> hope to clean this up in the next months.
>

At least I figured out how to get it to generate. Needs to be and stay in
sync and have some improvement in error messages. But it did work.


It looks like you pushed everything. Is that right?

Thanks.



> --
> 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: For GSoC: RTEMS release notes new generator

[Mahmoud Abumandour]

Bump. Please consider reviewing as the final submissions open today.

Thanks,
Mahmoud

On Wed, Aug 31, 2022 at 8:43 PM Mahmoud Abumandour 
wrote:

> Hello all,
>
> Here, I present the current output of the new release notes generator that
> will be used in the release generation process. Currently, the generator is
> capable is generating markdown and reStructuredText. Both have minor flaws
> that, in my opinion, are somewhat acceptable.
>
> You can find a sample Markdown PDF for the 4.11.3 milestone here:
> https://drive.google.com/file/d/1S_aKZcJi6c2DX7bCXgt6R9gvVdXgn5Sm/view?usp=sharing
>
> And its reStructuredText counterpart here:
> https://drive.google.com/drive/folders/1mntfWm6gnHPUpliwHS_ClJYjjnMOhZZV
>
> The generator has been tested on generating files for the following dot
> releases 4.11.3, 5.1, 5.2, and 6.1 and it produces decent documents for all
> of them.
>
> You can access the code here and test it yourself:
> https://github.com/i3abghany/release-notes-generator
>
> For integrating the generator in the release workflow, do you recommend a
> certain way to go by in doing this? Maybe use the code as a submodule in
> the `rtems-release` repository and call it from the `rtems-release-notes`
> script in it?
>
> Also, the generator was initially designed to produce notes for *one* dot
> release at a time, but I found out the current generator goes up from the
> supplied *version *to the specified *revision*. Is this the desired
> behaviour in the new generator as well? I am asking as I took over
> development in the new generator and it did not conform to this behaviour,
> and I didn't know that it was followed in the `rtems-release` scripts.
>
> Thanks,
> Mahmoud
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] config: Add SMP scheduler configuration errors

[Joel Sherrill]

This looks good.

On Mon, Sep 5, 2022, 7:19 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Issue an error message if a SMP-specific scheduler is used and RTEMS_SMP
> is disabled.  This might be a more informative compared to compiler or
> linker errors.
> ---
>  cpukit/include/rtems/scheduler.h | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/cpukit/include/rtems/scheduler.h
> b/cpukit/include/rtems/scheduler.h
> index d5c7e51ef5..a8004cb5e4 100644
> --- a/cpukit/include/rtems/scheduler.h
> +++ b/cpukit/include/rtems/scheduler.h
> @@ -132,6 +132,10 @@
>  #endif
>
>  #ifdef CONFIGURE_SCHEDULER_EDF_SMP
> +  #ifndef RTEMS_SMP
> +#error "CONFIGURE_SCHEDULER_EDF_SMP cannot be used if RTEMS_SMP is
> disabled"
> +  #endif
> +
>#include 
>
>#ifndef CONFIGURE_MAXIMUM_PROCESSORS
> @@ -198,6 +202,10 @@
>  #endif
>
>  #ifdef CONFIGURE_SCHEDULER_PRIORITY_AFFINITY_SMP
> +  #ifndef RTEMS_SMP
> +#error "CONFIGURE_SCHEDULER_PRIORITY_AFFINITY_SMP cannot be used if
> RTEMS_SMP is disabled"
> +  #endif
> +
>#include 
>
>#define SCHEDULER_PRIORITY_AFFINITY_SMP_CONTEXT_NAME( name ) \
> @@ -230,6 +238,10 @@
>  #endif
>
>  #ifdef CONFIGURE_SCHEDULER_PRIORITY_SMP
> +  #ifndef RTEMS_SMP
> +#error "CONFIGURE_SCHEDULER_PRIORITY_SMP cannot be used if RTEMS_SMP
> is disabled"
> +  #endif
> +
>#include 
>
>#define SCHEDULER_PRIORITY_SMP_CONTEXT_NAME( name ) \
> @@ -262,6 +274,10 @@
>  #endif
>
>  #ifdef CONFIGURE_SCHEDULER_STRONG_APA
> +  #ifndef RTEMS_SMP
> +#error "CONFIGURE_SCHEDULER_STRONG_APA cannot be used if RTEMS_SMP is
> disabled"
> +  #endif
> +
>#include 
>
>#ifndef CONFIGURE_MAXIMUM_PROCESSORS
> @@ -324,6 +340,10 @@
>  #endif
>
>  #ifdef CONFIGURE_SCHEDULER_SIMPLE_SMP
> +  #ifndef RTEMS_SMP
> +#error "CONFIGURE_SCHEDULER_SIMPLE_SMP cannot be used if RTEMS_SMP is
> disabled"
> +  #endif
> +
>#include 
>
>#define SCHEDULER_SIMPLE_SMP_CONTEXT_NAME( name ) \
> --
> 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: [rtems-central] Add POSIX Timer FACE Behavior Configuration

[Sebastian Huber]

On 05/09/2022 15:12, Joel Sherrill wrote:


On Mon, Sep 5, 2022, 2:04 AM Sebastian Huber 
> wrote:


Hello Joel,

On 02/09/2022 18:25, Joel Sherrill wrote:
 > Updates #4691.
 > ---
 >   config.yml                                 |  2 ++
 >   spec/acfg/if/group-face.yml                | 30
++
 >   spec/acfg/if/posix-timer-face-behavior.yml | 23
+++
 >   3 files changed, 55 insertions(+)
 >   create mode 100644 spec/acfg/if/group-face.yml
 >   create mode 100644 spec/acfg/if/posix-timer-face-behavior.yml

thanks for adding the items. I check it in and regenerated the files in
RTEMS and the documentation. Sorry for the bad state of
rtems-central, I
hope to clean this up in the next months.


At least I figured out how to get it to generate. Needs to be and stay 
in sync and have some improvement in error messages. But it did work.


If you like, you could add an spec-glossary/glossary/face.yml file and 
reference it in the configuration items using ${/glossary/face:/term}.


--
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 v4] cpukit/dev/can: Added CAN support

[Prashanth S]

---
 cpukit/dev/can/can-queue.h   | 230 +++
 cpukit/dev/can/can.c | 503 +++
 cpukit/include/dev/can/can-msg.h | 105 +
 cpukit/include/dev/can/can.h | 282 +
 spec/build/cpukit/librtemscpu.yml|   5 +
 spec/build/testsuites/libtests/can01.yml |  20 +
 spec/build/testsuites/libtests/grp.yml   |   2 +
 testsuites/libtests/can01/can-loopback.c | 110 +
 testsuites/libtests/can01/init.c | 251 +++
 9 files changed, 1508 insertions(+)
 create mode 100644 cpukit/dev/can/can-queue.h
 create mode 100644 cpukit/dev/can/can.c
 create mode 100644 cpukit/include/dev/can/can-msg.h
 create mode 100644 cpukit/include/dev/can/can.h
 create mode 100644 spec/build/testsuites/libtests/can01.yml
 create mode 100644 testsuites/libtests/can01/can-loopback.c
 create mode 100644 testsuites/libtests/can01/init.c

diff --git a/cpukit/dev/can/can-queue.h b/cpukit/dev/can/can-queue.h
new file mode 100644
index 00..9a3610c908
--- /dev/null
+++ b/cpukit/dev/can/can-queue.h
@@ -0,0 +1,230 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup CANBus
+ *
+ * @brief Controller Area Network (CAN) Bus Implementation
+ *
+ */
+
+/*
+ * Copyright (C) 2022 Prashanth S 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifndef _DEV_CAN_CAN_QUEUE_H
+#define _DEV_CAN_CAN_QUEUE_H
+
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+/**
+ * @defgroup Controller Area Network (CAN) Driver
+ *
+ * @ingroup RTEMSDeviceDrivers
+ *
+ * @brief Controller Area Network (CAN) bus and device driver support.
+ *
+ * @{
+ */
+
+/**
+ * @defgroup CANBus CAN Bus Driver
+ *
+ * @ingroup CAN
+ *
+ * @{
+ */
+
+/**
+ * @brief Create CAN tx buffers.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ * @retval 0 Successful operation.
+ * @retval >0 error number in case of an error.
+ */
+static rtems_status_code can_create_tx_buffers(struct can_bus *bus);
+
+/**
+ * @brief Free CAN tx buffers.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ */
+static void can_free_tx_buffers(struct can_bus *bus);
+
+/**
+ * @brief Check for atleast one empty CAN tx buffer.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ * @retval true If atleast one CAN buffer is empty.
+ * @retval false If no CAN buffer is empty.
+ */
+static bool can_tx_buf_isempty(struct can_bus *bus);
+
+/**
+ * @brief Get a produced tx buffer to transmit from the tx fifo.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ * @retval can_msg Pointer to can_msg structure buffer.
+ * @retval NULL If no can_msg buffer.
+ */
+static struct can_msg *can_tx_get_data_buf(struct can_bus *bus);
+
+/**
+ * @brief Get a empty tx buffer.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ * @retval can_msg Pointer to can_msg structure buffer.
+ * @retval NULL If no empty can_msg buffer.
+ */
+static struct can_msg *can_tx_get_empty_buf(struct can_bus *bus);
+
+/**
+ * @brief Creates tx buffers for the CAN bus driver.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ * @retval rtems_status_code
+ */
+static rtems_status_code can_create_tx_buffers(struct can_bus *bus)
+{
+  bus->tx_fifo.pbuf = (struct can_msg *)malloc(CAN_TX_BUF_COUNT *
+  sizeof(struct can_msg));
+  if (bus->tx_fifo.pbuf == NULL) {
+CAN_ERR("can_create_tx_buffers: malloc failed\n");
+return RTEMS_NO_MEMORY;
+  }
+
+  bus->tx_fifo.empty_count = CAN_TX_BUF_COUNT;
+
+  return RTEMS_SUCCESSFUL;
+}
+
+/**
+ * @brief Free tx buffers for the CAN bus driver.
+ *
+ * @param[in] bus Bus control structure.
+ *
+ */
+static void can_free_tx_buffers(struct can_bus *bus)
+{
+  free(bus->tx_fifo

Re: [PATCH] powerpc: Add support for VRSAVE

[Chris Johns]

On 5/9/2022 4:36 pm, Sebastian Huber wrote:
> On 03/09/2022 01:17, Chris Johns wrote:
>> On 2/9/2022 2:27 pm, Sebastian Huber wrote:
>>> On 02.09.22 06:22, Sebastian Huber wrote:
 On 02.09.22 04:22, Chris Johns wrote:
> On 1/9/2022 6:26 pm, Sebastian Huber wrote:
>> The VRSAVE feature of the Altivec unit can be used to reduce the amount 
>> of
>> Altivec registers which need to be saved/restored during interrupt 
>> processing
>> and context switches.
> Which BSPs and hardware has this been tested on?
 The e6500 QoIQ BSPs.
>>> I mean QorIQ. We have this code since 2020 in production code. I just 
>>> forgot to
>>> integrate it.
>> I would like to have this tested on some of the older MVME boards. Do you 
>> still
>> have the mvme5500 (I think)? I can look at testing in an mvme2703 this week.
> 
> This will not work out of the box. In order to use the VRSAVE optimization, 
> you
> need also a corresponding multilib (-mvrsave), see GCC patch. The MVME BSPs 
> use
> a different exception and context switch code for the AltiVec support. You 
> would
> have to convert them first to the implementation used by the QorIQ BSPs. 
> Lastly,
> you also have add the -mvrsave flag to the ABI_FLAGS.

Thank you for the explanation. This was not apparent to me so maybe something in
the commit message to help anyone reviewing the change would help?

Which BSPs does this effect?

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

Re: [PATCH] powerpc: Add support for VRSAVE

[Sebastian Huber]

On 06/09/2022 07:29, Chris Johns wrote:

On 5/9/2022 4:36 pm, Sebastian Huber wrote:

On 03/09/2022 01:17, Chris Johns wrote:

On 2/9/2022 2:27 pm, Sebastian Huber wrote:

On 02.09.22 06:22, Sebastian Huber wrote:

On 02.09.22 04:22, Chris Johns wrote:

On 1/9/2022 6:26 pm, Sebastian Huber wrote:

The VRSAVE feature of the Altivec unit can be used to reduce the amount of
Altivec registers which need to be saved/restored during interrupt processing
and context switches.

Which BSPs and hardware has this been tested on?

The e6500 QoIQ BSPs.

I mean QorIQ. We have this code since 2020 in production code. I just forgot to
integrate it.

I would like to have this tested on some of the older MVME boards. Do you still
have the mvme5500 (I think)? I can look at testing in an mvme2703 this week.


This will not work out of the box. In order to use the VRSAVE optimization, you
need also a corresponding multilib (-mvrsave), see GCC patch. The MVME BSPs use
a different exception and context switch code for the AltiVec support. You would
have to convert them first to the implementation used by the QorIQ BSPs. Lastly,
you also have add the -mvrsave flag to the ABI_FLAGS.


Thank you for the explanation. This was not apparent to me so maybe something in
the commit message to help anyone reviewing the change would help?


Ok, I can add something to the commit message.



Which BSPs does this effect?


Only the QorIQ BSPs using the e6500 core and only if -mvrsave is added 
to the ABI_FLAGS (follow up patch).


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

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

Re: [PATCH] powerpc: Add support for VRSAVE

[Chris Johns]

On 6/9/2022 3:38 pm, Sebastian Huber wrote:
> On 06/09/2022 07:29, Chris Johns wrote:
>> On 5/9/2022 4:36 pm, Sebastian Huber wrote:
>>> On 03/09/2022 01:17, Chris Johns wrote:
 On 2/9/2022 2:27 pm, Sebastian Huber wrote:
> On 02.09.22 06:22, Sebastian Huber wrote:
>> On 02.09.22 04:22, Chris Johns wrote:
>>> On 1/9/2022 6:26 pm, Sebastian Huber wrote:
 The VRSAVE feature of the Altivec unit can be used to reduce the 
 amount of
 Altivec registers which need to be saved/restored during interrupt
 processing
 and context switches.
>>> Which BSPs and hardware has this been tested on?
>> The e6500 QoIQ BSPs.
> I mean QorIQ. We have this code since 2020 in production code. I just
> forgot to
> integrate it.
 I would like to have this tested on some of the older MVME boards. Do you 
 still
 have the mvme5500 (I think)? I can look at testing in an mvme2703 this 
 week.
>>>
>>> This will not work out of the box. In order to use the VRSAVE optimization, 
>>> you
>>> need also a corresponding multilib (-mvrsave), see GCC patch. The MVME BSPs 
>>> use
>>> a different exception and context switch code for the AltiVec support. You 
>>> would
>>> have to convert them first to the implementation used by the QorIQ BSPs. 
>>> Lastly,
>>> you also have add the -mvrsave flag to the ABI_FLAGS.
>>
>> Thank you for the explanation. This was not apparent to me so maybe 
>> something in
>> the commit message to help anyone reviewing the change would help?
> 
> Ok, I can add something to the commit message.
> 

Thanks

>>
>> Which BSPs does this effect?
> 
> Only the QorIQ BSPs using the e6500 core and only if -mvrsave is added to the
> ABI_FLAGS (follow up patch).

Great. I think this is important and valuable information.

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