Re: [PATCH rtems-lwip v1 0/9] Bring in devel patches and add ZynqMP

2022-07-01 Thread Vijay Kumar Banerjee
On Fri, Jul 1, 2022 at 8:19 PM Kinsey Moore  wrote:
>
> On 7/1/2022 18:50, Vijay Kumar Banerjee wrote:
>
> On Fri, Jul 1, 2022 at 5:49 PM Vijay Kumar Banerjee  wrote:
>
> Hi Kinsey,
>
> This patchset is looking great. Thank you!
> Unfortunately, I won't be able to test the BBB right away but I see
> that most patches are probably from the devel branch of lwip, which I
>
> correction: most of BBB related changes. :)
>
> It should actually be all of the BBB related changes, I just squashed some of 
> them together since I was doing a pretty heavy rework anyway.

Makes sense.
>
>
> You mentioned on Discord that a couple of the patches didn't make it through. 
> You can find the entire patch set on top of main here:
>
> https://github.com/KinseyMoore/rtems-lwip

Thanks for posting the repo link.


Best regards,
Vijay
>
> Kinsey
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: [PATCH rtems-lwip v1 0/9] Bring in devel patches and add ZynqMP

2022-07-01 Thread Kinsey Moore

On 7/1/2022 18:50, Vijay Kumar Banerjee wrote:

On Fri, Jul 1, 2022 at 5:49 PM Vijay Kumar Banerjee  wrote:

Hi Kinsey,

This patchset is looking great. Thank you!
Unfortunately, I won't be able to test the BBB right away but I see
that most patches are probably from the devel branch of lwip, which I

correction: most of BBB related changes. :)


It should actually be all of the BBB related changes, I just squashed 
some of them together since I was doing a pretty heavy rework anyway.



You mentioned on Discord that a couple of the patches didn't make it 
through. You can find the entire patch set on top of main here:


https://github.com/KinseyMoore/rtems-lwip


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

Re: [PATCH rtems-lwip v1 0/9] Bring in devel patches and add ZynqMP

2022-07-01 Thread Vijay Kumar Banerjee
On Fri, Jul 1, 2022 at 5:49 PM Vijay Kumar Banerjee  wrote:
>
> Hi Kinsey,
>
> This patchset is looking great. Thank you!
> Unfortunately, I won't be able to test the BBB right away but I see
> that most patches are probably from the devel branch of lwip, which I
correction: most of BBB related changes. :)

> tested before. I am going to wait till Tuesday, to get any comments or
> objections from others. If no changes are required, I will push these
> patches on Tuesday.
>
> Best regards,
> Vijay
>
>
> On Fri, Jul 1, 2022 at 4:32 PM Kinsey Moore  wrote:
> >
> > This brings in a significantly cleaned up version of the remaining
> > patches on the devel branch and adds support for ZynqMP CGEMs. I have
> > tested CGEM0 on QEMU and CGEM3 on hardware. I am unable to test on the
> > BeagleBoneBlack at the moment, so I'd appreciate a double-check to
> > ensure I haven't broken it.
> >
> >
> > ___
> > 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-lwip v1 0/9] Bring in devel patches and add ZynqMP

2022-07-01 Thread Vijay Kumar Banerjee
Hi Kinsey,

This patchset is looking great. Thank you!
Unfortunately, I won't be able to test the BBB right away but I see
that most patches are probably from the devel branch of lwip, which I
tested before. I am going to wait till Tuesday, to get any comments or
objections from others. If no changes are required, I will push these
patches on Tuesday.

Best regards,
Vijay


On Fri, Jul 1, 2022 at 4:32 PM Kinsey Moore  wrote:
>
> This brings in a significantly cleaned up version of the remaining
> patches on the devel branch and adds support for ZynqMP CGEMs. I have
> tested CGEM0 on QEMU and CGEM3 on hardware. I am unable to test on the
> BeagleBoneBlack at the moment, so I'd appreciate a double-check to
> ensure I haven't broken it.
>
>
> ___
> 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


[PATCH rtems-lwip v1 7/9] rtemslwip: Add zynqmp xilinx adapter code

2022-07-01 Thread Kinsey Moore
---
 rtemslwip/include/arch/eth_lwip_default.h |   0
 rtemslwip/include/bspconfig.h |   0
 rtemslwip/xilinx/FreeRTOS.h   |  38 +++
 rtemslwip/xilinx/semphr.h |   0
 rtemslwip/xilinx/sleep.h  |  34 ++
 rtemslwip/xilinx/timers.h |   0
 rtemslwip/xilinx/xil_printf.h |  33 ++
 rtemslwip/xilinx/xil_smc.h|   0
 rtemslwip/xilinx/xil_spinlock.h   |   0
 rtemslwip/xilinx/xpseudo_asm.h|  33 ++
 rtemslwip/zynqmp/lwipopts.h   | 121 ++
 rtemslwip/zynqmp/xemacps_g.c  |  79 ++
 rtemslwip/zynqmp/xil_shims.c  |  91 
 rtemslwip/zynqmp/xlwipconfig.h|  38 +++
 rtemslwip/zynqmp/xparameters.h| 113 
 rtemslwip/zynqmp/xparameters_ps.h |  68 
 rtemslwip/zynqmp/xtopology_g.c|  67 
 rtemslwip/zynqmp_hardware/netstart.c  |  66 
 rtemslwip/zynqmp_qemu/netstart.c  |  66 
 19 files changed, 847 insertions(+)
 create mode 100644 rtemslwip/include/arch/eth_lwip_default.h
 create mode 100644 rtemslwip/include/bspconfig.h
 create mode 100644 rtemslwip/xilinx/FreeRTOS.h
 create mode 100644 rtemslwip/xilinx/semphr.h
 create mode 100644 rtemslwip/xilinx/sleep.h
 create mode 100644 rtemslwip/xilinx/timers.h
 create mode 100644 rtemslwip/xilinx/xil_printf.h
 create mode 100644 rtemslwip/xilinx/xil_smc.h
 create mode 100644 rtemslwip/xilinx/xil_spinlock.h
 create mode 100644 rtemslwip/xilinx/xpseudo_asm.h
 create mode 100644 rtemslwip/zynqmp/lwipopts.h
 create mode 100644 rtemslwip/zynqmp/xemacps_g.c
 create mode 100644 rtemslwip/zynqmp/xil_shims.c
 create mode 100644 rtemslwip/zynqmp/xlwipconfig.h
 create mode 100644 rtemslwip/zynqmp/xparameters.h
 create mode 100644 rtemslwip/zynqmp/xparameters_ps.h
 create mode 100644 rtemslwip/zynqmp/xtopology_g.c
 create mode 100644 rtemslwip/zynqmp_hardware/netstart.c
 create mode 100644 rtemslwip/zynqmp_qemu/netstart.c

diff --git a/rtemslwip/include/arch/eth_lwip_default.h 
b/rtemslwip/include/arch/eth_lwip_default.h
new file mode 100644
index 000..e69de29
diff --git a/rtemslwip/include/bspconfig.h b/rtemslwip/include/bspconfig.h
new file mode 100644
index 000..e69de29
diff --git a/rtemslwip/xilinx/FreeRTOS.h b/rtemslwip/xilinx/FreeRTOS.h
new file mode 100644
index 000..c63d4fa
--- /dev/null
+++ b/rtemslwip/xilinx/FreeRTOS.h
@@ -0,0 +1,38 @@
+/*
+ * Copyright (C) 2022 On-Line Applications Research Corporation (OAR)
+ * Written by Kinsey Moore 
+ *
+ * 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 FREERTOS_H
+#define FREERTOS_H
+
+typedef long BaseType_t;
+
+BaseType_t xPortInstallInterruptHandler(
+  uint8_t   ucInterruptID,
+  XInterruptHandler pxHandler,
+  void *pvCallBackRef
+);
+
+#endif /* FREERTOS_H */
diff --git a/rtemslwip/xilinx/semphr.h b/rtemslwip/xilinx/semphr.h
new file mode 100644
index 000..e69de29
diff --git a/rtemslwip/xilinx/sleep.h b/rtemslwip/xilinx/sleep.h
new file mode 100644
index 000..4a4fbdf
--- /dev/null
+++ b/rtemslwip/xilinx/sleep.h
@@ -0,0 +1,34 @@
+/*
+ * Copyright (C) 2022 On-Line Applications Research Corporation (OAR)
+ * Written by Kinsey Moore 
+ *
+ * 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, 

[PATCH rtems-lwip v1 8/9] lwip.py: Add zynqmp driver build

2022-07-01 Thread Kinsey Moore
---
 lwip.py | 49 +
 1 file changed, 49 insertions(+)

diff --git a/lwip.py b/lwip.py
index ec8481e..335fb18 100644
--- a/lwip.py
+++ b/lwip.py
@@ -29,6 +29,34 @@ from rtems_waf import rtems
 import yaml
 import os
 
+xilinx_drv_incl = ''
+xilinx_drv_incl += 
'./embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/include '
+xilinx_drv_incl += './embeddedsw/lib/bsp/standalone/src/common '
+xilinx_drv_incl += './embeddedsw/XilinxProcessorIPLib/drivers/common/src/ '
+xilinx_drv_incl += './embeddedsw/XilinxProcessorIPLib/drivers/scugic/src '
+xilinx_drv_incl += './embeddedsw/XilinxProcessorIPLib/drivers/emacps/src '
+xilinx_drv_incl += './rtemslwip/xilinx '
+
+xilinx_aarch64_drv_incl = ''
+xilinx_aarch64_drv_incl += './rtemslwip/zynqmp '
+xilinx_aarch64_drv_incl += 
'./embeddedsw/lib/bsp/standalone/src/arm/ARMv8/64bit '
+xilinx_aarch64_drv_incl += './embeddedsw/lib/bsp/standalone/src/arm/common/gcc 
'
+xilinx_aarch64_drv_incl += './embeddedsw/lib/bsp/standalone/src/arm/common '
+
+# These sources are explicitly listed instead of using walk_sources below
+# because multiple BSPs of varying architecture are expected to use code from
+# the embeddedsw repository.
+xilinx_aarch64_driver_source = [
+
'./embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xadapter.c',
+
'./embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xpqueue.c',
+
'./embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xemacpsif_physpeed.c',
+
'./embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xemacpsif_hw.c',
+'./embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_bdring.c',
+'./embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps.c',
+'./embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_control.c',
+'./embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_intr.c',
+'./embeddedsw/lib/bsp/standalone/src/common/xil_assert.c'
+]
 
 def build(bld):
 source_files = []
@@ -77,6 +105,27 @@ def build(bld):
 drv_incl += './rtemslwip/beaglebone ./cpsw/src/include '
 driver_source.extend(walk_sources('./cpsw/src'))
 
+# These files will only compile for BSPs on Xilinx hardware
+is_xilinx_bsp = False
+is_aarch64_bsp = False
+is_qemu = False
+if bld.env.RTEMS_ARCH_BSP.startswith('aarch64-rtems6-xilinx_zynqmp'):
+is_xilinx_bsp = True
+is_aarch64_bsp = True
+if bld.env.RTEMS_ARCH_BSP.endswith('_qemu'):
+is_qemu = True
+if is_xilinx_bsp:
+
driver_source.extend(walk_sources('./embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif'))
+drv_incl += xilinx_drv_incl
+if is_aarch64_bsp:
+driver_source.extend(walk_sources('./rtemslwip/zynqmp'))
+if is_qemu:
+driver_source.extend(walk_sources('./rtemslwip/zynqmp_qemu'))
+else:
+
driver_source.extend(walk_sources('./rtemslwip/zynqmp_hardware'))
+driver_source.extend(xilinx_aarch64_driver_source)
+drv_incl += xilinx_aarch64_drv_incl
+
 bld(features ='c',
 target='lwip_obj',
 cflags='-g -Wall -O0',
-- 
2.30.2

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


[PATCH rtems-lwip v1 9/9] lwip.py: Remove dead code

2022-07-01 Thread Kinsey Moore
---
 lwip.py | 8 
 1 file changed, 8 deletions(-)

diff --git a/lwip.py b/lwip.py
index 335fb18..3e89026 100644
--- a/lwip.py
+++ b/lwip.py
@@ -75,14 +75,6 @@ def build(bld):
 source_files.append('./uLan/ports/os/rtems/arch/sys_arch.c')
 source_files.append('./rtemslwip/common/syslog.c')
 
-#source_files.append('./lwip/ports/port/sys_arch.c')
-#source_files.append('./lwip/ports/port/perf.c')
-#source_files.append('./lwip/ports/port/netif/fifo.c')
-#source_files.append('./lwip/ports/port/netif/list.c')
-#source_files.append('./lwip/ports/port/netif/pcapif.c')
-#source_files.append('./lwip/ports/port/netif/sio.c')
-#source_files.append('./lwip/ports/port/netif/tapif.c')
-
 def walk_sources(path):
 sources = []
 for root, dirs, files in os.walk(path):
-- 
2.30.2

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


[PATCH rtems-lwip v1 6/9] xemacps: Avoid using memset on device memory

2022-07-01 Thread Kinsey Moore
It is not safe to use memset with device memory. Device memory has
strict access alignment requirements that memset may not respect since
it can be optimized to use unaligned accesses. This avoids use of memset
with device memory.
---
 .../drivers/emacps/src/xemacps_bdring.c  | 9 +
 1 file changed, 9 insertions(+)

diff --git 
a/embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_bdring.c 
b/embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_bdring.c
index 829f37c..1cbfa18 100644
--- a/embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_bdring.c
+++ b/embeddedsw/XilinxProcessorIPLib/drivers/emacps/src/xemacps_bdring.c
@@ -225,7 +225,16 @@ LONG XEmacPs_BdRingCreate(XEmacPs_BdRing * RingPtr, 
UINTPTR PhysAddr,
 *  - Clear the entire space
 *  - Setup each BD's BDA field with the physical address of the next BD
 */
+#ifndef __rtems__
(void)memset((void *) VirtAddrLoc, 0, (RingPtr->Separation * BdCount));
+#else
+   unsigned char* mem = (unsigned char *) VirtAddrLoc;
+   int len = RingPtr->Separation * BdCount;
+   while (len-- > 0) {
+   *mem = 0;
+   mem++;
+   }
+#endif
 
BdVirtAddr = VirtAddrLoc;
BdPhyAddr = PhysAddr + RingPtr->Separation;
-- 
2.30.2

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


[PATCH rtems-lwip v1 4/9] lwip: Add support for SMP systems

2022-07-01 Thread Kinsey Moore
For BSPs that support SMP, the sys_arch_protect and sys_arch_unprotect
calls must use a global mutex instead of a local CPU interrupt disable
to protect critical sections.
---
 uLan/ports/os/rtems/arch/sys_arch.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/uLan/ports/os/rtems/arch/sys_arch.c 
b/uLan/ports/os/rtems/arch/sys_arch.c
index fa344a1..d51810b 100644
--- a/uLan/ports/os/rtems/arch/sys_arch.c
+++ b/uLan/ports/os/rtems/arch/sys_arch.c
@@ -57,10 +57,22 @@ sys_now()
   return temp;
 }
 
+#ifdef __rtems__
+#if RTEMS_SMP
+sys_mutex_t sys_arch_mutex;
+#endif
+#endif
+
 void
 sys_init(void)
 {
   //  Is called to initialize the sys_arch layer.
+#ifdef __rtems__
+#if RTEMS_SMP
+  // initialize global sys arch protect mutex
+  sys_mutex_new(_arch_mutex);
+#endif
+#endif
   return;
 }
 
@@ -364,16 +376,25 @@ sys_request_irq(unsigned int irqnum, sys_irq_handler_t 
handler,
 sys_prot_t
 sys_arch_protect()
 {
+#if RTEMS_SMP
+  sys_mutex_lock(_arch_mutex);
+  return 0;
+#else
   sys_prot_t pval;
 
   rtems_interrupt_disable(pval);
   return pval;
+#endif
 }
 
 void
 sys_arch_unprotect(sys_prot_t pval)
 {
+#if RTEMS_SMP
+  sys_mutex_unlock(_arch_mutex);
+#else
   rtems_interrupt_enable(pval);
+#endif
 }
 err_t
 sys_mbox_trypost_fromisr(sys_mbox_t *q, void *msg)
-- 
2.30.2

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


[PATCH rtems-lwip v1 3/9] telnetd01: Break out network startup

2022-07-01 Thread Kinsey Moore
This moves network startup in to a BSP-defined function so that tests
can be more generic.
---
 rtemslwip/beaglebone/netstart.c | 43 +
 rtemslwip/include/netstart.h| 41 +++
 rtemslwip/test/telnetd01/init.c | 26 +---
 3 files changed, 107 insertions(+), 3 deletions(-)
 create mode 100644 rtemslwip/beaglebone/netstart.c
 create mode 100644 rtemslwip/include/netstart.h

diff --git a/rtemslwip/beaglebone/netstart.c b/rtemslwip/beaglebone/netstart.c
new file mode 100644
index 000..33384b6
--- /dev/null
+++ b/rtemslwip/beaglebone/netstart.c
@@ -0,0 +1,43 @@
+/*
+ * Copyright (C) 2022 On-Line Applications Research Corporation (OAR)
+ * Written by Kinsey Moore 
+ *
+ * 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.
+ */
+
+#include 
+#include "soc_AM335x.h"
+#include "beaglebone.h"
+#include 
+
+int start_networking(
+  struct netif  *net_interface,
+  ip_addr_t *ipaddr,
+  ip_addr_t *netmask,
+  ip_addr_t *gateway,
+  unsigned char *mac_ethernet_address
+)
+{
+  tcpip_init( NULL, NULL );
+
+  return 0;
+}
diff --git a/rtemslwip/include/netstart.h b/rtemslwip/include/netstart.h
new file mode 100644
index 000..d5c58d4
--- /dev/null
+++ b/rtemslwip/include/netstart.h
@@ -0,0 +1,41 @@
+/*
+ * Copyright (C) 2022 On-Line Applications Research Corporation (OAR)
+ * Written by Kinsey Moore 
+ *
+ * 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 _RTEMSLWIP_NETSTART_H
+#define _RTEMSLWIP_NETSTART_H
+#include 
+#include 
+#include 
+
+int start_networking(
+  struct netif  *net_interface,
+  ip_addr_t *ipaddr,
+  ip_addr_t *netmask,
+  ip_addr_t *gateway,
+  unsigned char *mac_ethernet_address
+);
+
+#endif
diff --git a/rtemslwip/test/telnetd01/init.c b/rtemslwip/test/telnetd01/init.c
index 0a20bd8..a671fdd 100644
--- a/rtemslwip/test/telnetd01/init.c
+++ b/rtemslwip/test/telnetd01/init.c
@@ -28,13 +28,15 @@
 
 #include 
 #include 
-#include 
+#include 
 
 #include 
 
+#include 
+
 const char rtems_test_name[] = "TELNETD 1";
 
-//struct rtems_bsdnet_config rtems_bsdnet_config;
+struct netif net_interface;
 
 rtems_shell_env_t env;
 
@@ -86,10 +88,28 @@ rtems_shell_cmd_t shell_NETINFO_Command = {
 static rtems_task Init( rtems_task_argument argument )
 {
   rtems_status_code sc;
+  int ret;
 
   TEST_BEGIN();
 
-  lwip_init();
+  ip_addr_t ipaddr, netmask, gw;
+
+  IP_ADDR4( , 10, 0, 2, 14 );
+  IP_ADDR4( , 

[PATCH rtems-lwip v1 0/9] Bring in devel patches and add ZynqMP

2022-07-01 Thread Kinsey Moore
This brings in a significantly cleaned up version of the remaining
patches on the devel branch and adds support for ZynqMP CGEMs. I have
tested CGEM0 on QEMU and CGEM3 on hardware. I am unable to test on the
BeagleBoneBlack at the moment, so I'd appreciate a double-check to
ensure I haven't broken it.


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


[PATCH rtems-lwip v1 1/9] uLan: Update sys_arch and fix additions

2022-07-01 Thread Kinsey Moore
This updates sys_arch.c and sys_arch.h to the latest versions from the
upstream repository at hash 9e6ce84f2071bf0fbe3922db1cacf00823b2bdc1 and
updates the modifications to be compliant with how this project handles
modifications to upstream sources.
---
 uLan/ports/os/rtems/arch/sys_arch.c |  7 ++-
 uLan/ports/os/rtems/arch/sys_arch.h | 25 +++--
 2 files changed, 29 insertions(+), 3 deletions(-)

diff --git a/uLan/ports/os/rtems/arch/sys_arch.c 
b/uLan/ports/os/rtems/arch/sys_arch.c
index ca7f8be..fa344a1 100644
--- a/uLan/ports/os/rtems/arch/sys_arch.c
+++ b/uLan/ports/os/rtems/arch/sys_arch.c
@@ -269,7 +269,11 @@ sys_thread_new(const char *name, lwip_thread_fn function, 
void *arg, int stack_s
   rtems_status_code res;
 
   res = rtems_task_create(
+#ifdef __rtems__
+rtems_build_name(name[0], name[1], name[2], name[3]),
+#else
 rtems_build_name('L', 'W', 'I', 'P'),
+#endif
 prio,
 stack_size,
 RTEMS_PREEMPT,
@@ -356,6 +360,7 @@ sys_request_irq(unsigned int irqnum, sys_irq_handler_t 
handler,
   return (res != RTEMS_SUCCESSFUL) ? -1 : 0;
 }
 
+#ifdef __rtems__
 sys_prot_t
 sys_arch_protect()
 {
@@ -375,4 +380,4 @@ sys_mbox_trypost_fromisr(sys_mbox_t *q, void *msg)
 {
   return sys_mbox_trypost(q, msg);
 }
-
+#endif
diff --git a/uLan/ports/os/rtems/arch/sys_arch.h 
b/uLan/ports/os/rtems/arch/sys_arch.h
index c89abd4..a80244d 100644
--- a/uLan/ports/os/rtems/arch/sys_arch.h
+++ b/uLan/ports/os/rtems/arch/sys_arch.h
@@ -41,9 +41,8 @@
 
 #include 
 #include 
-#include 
 #include 
-//#include "eth_lwip_default.h"
+#include "arch/eth_lwip_default.h"
 
 /* Typedefs for the various port-specific types. */
 #if defined(NO_SYS) && NO_SYS
@@ -101,8 +100,30 @@ sys_arch_unmask_interrupt_source(unsigned int x)
   bsp_interrupt_vector_enable(x);
 }
 
+#ifndef __rtems__
+static inline sys_prot_t
+sys_arch_protect(void)
+{
+  sys_prot_t pval;
+
+  rtems_interrupt_disable(pval);
+  return pval;
+}
+
+static inline void
+sys_arch_unprotect(sys_prot_t pval)
+{
+  rtems_interrupt_enable(pval);
+}
+
+static inline void
+sys_arch_data_sync_barier(void){
+  _ARM_Data_synchronization_barrier();
+}
+#else
 sys_prot_t sys_arch_protect();
 
 void sys_arch_unprotect(sys_prot_t pval);
+#endif
 
 #endif /* __ARCH_SYS_ARCH_H__ */
-- 
2.30.2

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


Re: Integrating the Formal Methods part of Qualification

2022-07-01 Thread andrew.butterfi...@scss.tcd.ie
-Original Message-
From: Chris Johns 


On 28/6/2022 11:09 pm, andrew.butterfi...@scss.tcd.ie wrote:
> Dear RTEMS Developers,
> 
> While the validation tests from the RTEMS pre-qualification activity are
> now merged into the RTEMS master, the work done in investigating and 
> deploying formal methods techniques is not yet merged.
> 
> The activity had two main phases: a planning phase (Nov 2018-Oct 2019) 
> that explored various formal techniques, followed by an execution phase 
> (Oct 2019-Nov 2021) that then applied selected techniques to selected 
> parts of RTEMS. Some discussions occurred with the RTEMS community 
> via the mailings lists over this time. A short third phase (Nov 2021 - 
Dec 2021) 
> then reported on the outcomes. Each phase resulted in a technical report.
> 
> The key decision made was to use Promela/SPIN for test generation, and 
> to apply it to the Chains API, the Event Manager, and the SMP scheduler
> thread queues. This involved developing models in the Promela language 
> and using the SPIN model-checker tool to both check their correctness
> and to generate execution scenarios that could be used to generate tests.
> Tools were developed using Python 3.8 to support this. Initial 
documentation 
> about tools and how to use them was put into the 2nd phase report.

Congratulations for the work and results you and others have managed to 
achieve.
It is exciting to see this happening with RTEMS and being made public.

> We now come to the part where we explore the best way to integrate this
> into RTEMS. I am proposing to do this under the guidance of Sebastian 
Huber.
> 
> The first suggested step is adding in new documentation to the RTEMS 
> Software Engineering manual, as a new Formal Methods chapter. This would 
> provide some motivation, as well as a "howto".
> 
> I assume that I would initially describe the proposed changes using the 
patch 
> review process described in the section on Preparing and Sending Patches 
in 
> the User Manual.
> 
> How do you feel I should best proceed?

It is hard for me to answer until I understand what is being submitted and 
who
maintains it? I am sure you understand this due to the specialised nature 
of the
work.

Indeed, I quite agree.  I have some short answers below, with suggestions.

What will be submitted, ie SPIN files, scripts, etc?

Promela/SPIN model files (ASCII text, C-like syntax)
C template files (.h,.c) to assist test code generation
YAML files to provide a mapping from model concepts to RTEMS C test code 
python scripts to automate the test generation
Documentation - largely RTEMS compliant sphinx sources (.rst)

Where are you looking to add these pieces?

Everything except the documentation could live in a top-level folder ('formal') 
in rtems-central.
In fact there is no particular constraint from my perspective for where they 
can go.
 
The plan would be to add the pertinent parts of our project documentation into 
new chapters
in the RTEMS software engineering manual. So that would be eng/ in the 
rtems-docs repo.

How is the verification run against the code? Do we manage regression 
testing
and is that even possible?

The python scripts basically run SPIN in such a way as to generate scenarios 
that model
correct behaviour which then get turned into standard RTEMS test programs. 
These all
get added into a new testsuite in the rtems repo (testsuites/models, say).
They are properly integrated into the RTEMS test system, so get built and run 
by waf.
This is similar to how the tests generated by Sebastian in 
testsuites/validation are handled.
 
>From the perspective of a user that works out of git.rtems.org/rtems, 
there will be no obvious impact - just some extra tests in among the ones that 
already exist.

I hope my simple questions highlight a lack of understand on how this works 
and
how we maintain it and use it once integrated.

I intend to continue to work and maintain this for the foreseeable future. I 
would hope as this beds in that other Promela/SPIN users out there will also 
get more involved over time.
 
It is expected that Promela models will be as static as the corresponding APIs. 
They capture the specified behaviour of API calls, not their detailed 
implementation.
 
The python scripts should also be fairly stable, although I can see some 
tweaking for a while to improve workflow issues that might arise.
 
There are some extra python libraries that are required over and above what is 
currently specified in rtems-central/requirements.txt

Thanks
Chris

Thanks,
  Andrew

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


Re: Integrating the Formal Methods part of Qualification

2022-07-01 Thread andrew.butterfi...@scss.tcd.ie

On 1 Jul 2022, at 00:59, Chris Johns 
mailto:chr...@rtems.org>> wrote:

On 28/6/2022 11:09 pm, 
andrew.butterfi...@scss.tcd.ie wrote:

Dear RTEMS Developers,

While the validation tests from the RTEMS pre-qualification activity are
now merged into the RTEMS master, the work done in investigating and
deploying formal methods techniques is not yet merged.

The activity had two main phases: a planning phase (Nov 2018-Oct 2019)
that explored various formal techniques, followed by an execution phase
(Oct 2019-Nov 2021) that then applied selected techniques to selected
parts of RTEMS. Some discussions occurred with the RTEMS community
via the mailings lists over this time. A short third phase (Nov 2021 - Dec 2021)
then reported on the outcomes. Each phase resulted in a technical report.

The key decision made was to use Promela/SPIN for test generation, and
to apply it to the Chains API, the Event Manager, and the SMP scheduler
thread queues. This involved developing models in the Promela language
and using the SPIN model-checker tool to both check their correctness
and to generate execution scenarios that could be used to generate tests.
Tools were developed using Python 3.8 to support this. Initial documentation
about tools and how to use them was put into the 2nd phase report.

Congratulations for the work and results you and others have managed to achieve.
It is exciting to see this happening with RTEMS and being made public.


We now come to the part where we explore the best way to integrate this
into RTEMS. I am proposing to do this under the guidance of Sebastian Huber.

The first suggested step is adding in new documentation to the RTEMS
Software Engineering manual, as a new Formal Methods chapter. This would
provide some motivation, as well as a "howto".

I assume that I would initially describe the proposed changes using the patch
review process described in the section on Preparing and Sending Patches in
the User Manual.

How do you feel I should best proceed?

It is hard for me to answer until I understand what is being submitted and who
maintains it? I am sure you understand this due to the specialised nature of the
work.

Indeed, I quite agree.  I have some short answers below, with suggestions.



What will be submitted, ie SPIN files, scripts, etc?

Promela/SPIN model files (ASCII text, C-like syntax)
C template files (.h,.c) to assist test code generation
YAML files to provide a mapping from model concepts to RTEMS C test code
python scripts to automate the test generation
Documentation - largely RTEMS compliant sphinx sources (.rst)


Where are you looking to add these pieces?

Everything except the documentation could live in a top-level folder ('formal') 
in rtems-central.
In fact there is no particular constraint from my perspective for where they 
can go.

The plan would be to add the pertinent parts of our project documentation into 
new chapters
in the RTEMS software engineering manual. So that would be eng/ in the 
rtems-docs repo.



How is the verification run against the code? Do we manage regression testing
and is that even possible?

The python scripts basically run SPIN in such a way as to generate scenarios 
that model
correct behaviour which then get turned into standard RTEMS test programs. 
These all
get added into a new testsuite in the rtems repo (testsuites/models, say).
They are properly integrated into the RTEMS test system, so get built and run 
by waf.
This is similar to how the tests generated by Sebastian in 
testsuites/validation are handled.

From the perspective of a user that works out of 
git.rtems.org/rtems,
there will be no obvious impact - just some extra tests in among the ones that 
already exist.


I hope my simple questions highlight a lack of understand on how this works and
how we maintain it and use it once integrated.

I intend to continue to work and maintain this for the foreseeable future. I 
would hope as this beds in that other Promela/SPIN users out there will also 
get more involved over time.

It is expected that Promela models will be as static as the corresponding APIs. 
They capture the specified behaviour of API calls, not their detailed 
implementation.

The python scripts should also be fairly stable, although I can see some 
tweaking for a while to improve workflow issues that might arise.

There are some extra python libraries that are required over and above what is 
currently specified in rtems-central/requirements.txt


Thanks
Chris

Thanks,
  Andrew



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

[PATCH v2] irq/arm-gicv3.h: Customize ICC_IGRPEN0/1 init

2022-07-01 Thread Sebastian Huber
Use the existing WRITE_SR() abstraction to access the interrupt group 0 and 1
enable registers.  This fixes the build for the AArch32 target.
---
 bsps/include/dev/irq/arm-gicv3.h  | 30 ---
 spec/build/bsps/aarch64/a53/grp.yml   |  2 ++
 spec/build/bsps/aarch64/a53/obj.yml   |  1 -
 spec/build/bsps/aarch64/a72/grp.yml   |  2 ++
 spec/build/bsps/aarch64/a72/obj.yml   |  1 -
 spec/build/bsps/aarch64/grp.yml   |  1 -
 spec/build/bsps/aarch64/xilinx-versal/grp.yml |  2 ++
 spec/build/bsps/aarch64/xilinx-versal/obj.yml |  1 -
 spec/build/bsps/arm/fvp/grp.yml   |  2 ++
 spec/build/bsps/arm/fvp/obj.yml   |  1 -
 spec/build/bsps/arm/grp.yml   |  1 -
 spec/build/bsps/objarmgic.yml | 21 +
 spec/build/bsps/optarmgic-icc-igrpen0.yml | 20 +
 spec/build/bsps/optarmgic-icc-igrpen1.yml | 17 +++
 14 files changed, 78 insertions(+), 24 deletions(-)
 create mode 100644 spec/build/bsps/objarmgic.yml
 create mode 100644 spec/build/bsps/optarmgic-icc-igrpen0.yml
 create mode 100644 spec/build/bsps/optarmgic-icc-igrpen1.yml

diff --git a/bsps/include/dev/irq/arm-gicv3.h b/bsps/include/dev/irq/arm-gicv3.h
index a79368ebdf..4cd8cfaaed 100644
--- a/bsps/include/dev/irq/arm-gicv3.h
+++ b/bsps/include/dev/irq/arm-gicv3.h
@@ -116,9 +116,11 @@ extern "C" {
 #else /* ARM_MULTILIB_ARCH_V4 */
 
 /* AArch64 GICv3 registers are not named in GCC */
-#define ICC_IGRPEN0 "S3_0_C12_C12_6, %0"
-#define ICC_IGRPEN1 "S3_0_C12_C12_7, %0"
+#define ICC_IGRPEN0_EL1 "S3_0_C12_C12_6, %0"
+#define ICC_IGRPEN1_EL1 "S3_0_C12_C12_7, %0"
 #define ICC_IGRPEN1_EL3 "S3_6_C12_C12_7, %0"
+#define ICC_IGRPEN0 ICC_IGRPEN0_EL1
+#define ICC_IGRPEN1 ICC_IGRPEN1_EL1
 #define ICC_PMR "S3_0_C4_C6_0, %0"
 #define ICC_EOIR1   "S3_0_C12_C12_1, %0"
 #define ICC_SRE "S3_0_C12_C12_5, %0"
@@ -300,20 +302,6 @@ static void gicv3_init_dist(volatile gic_dist *dist)
   }
 }
 
-/*
- * A better way to access these registers than special opcodes
- */
-#define isb() __asm __volatile("isb" : : : "memory")
-
-#define  WRITE_SPECIALREG(reg, _val)\
-  __asm __volatile("msr  " __STRING(reg) ", %0" : : "r"((uint64_t)_val))
-
-#define  gic_icc_write(reg, val)\
-do {\
-  WRITE_SPECIALREG(icc_ ##reg ##_el1, val); \
-  isb();\
-} while (0)
-
 static void gicv3_init_cpu_interface(uint32_t cpu_index)
 {
   uint32_t sre_value = 0x7;
@@ -334,8 +322,14 @@ static void gicv3_init_cpu_interface(uint32_t cpu_index)
 sgi_ppi->icspiprior[id] = PRIORITY_DEFAULT;
   }
 
-  /* Enable interrupt groups 0 and 1 */
-  gic_icc_write(IGRPEN1, 1);
+  /* Initialize the group 0 and 1 interrupt enable */
+#ifdef BSP_ARM_GIC_ICC_IGRPEN0
+  WRITE_SR(ICC_IGRPEN0, BSP_ARM_GIC_ICC_IGRPEN0);
+#endif
+#ifdef BSP_ARM_GIC_ICC_IGRPEN1
+  WRITE_SR(ICC_IGRPEN1, BSP_ARM_GIC_ICC_IGRPEN1);
+#endif
+
   WRITE_SR(ICC_CTLR, 0x0);
 }
 
diff --git a/spec/build/bsps/aarch64/a53/grp.yml 
b/spec/build/bsps/aarch64/a53/grp.yml
index 091f18d6f5..2f23915a81 100644
--- a/spec/build/bsps/aarch64/a53/grp.yml
+++ b/spec/build/bsps/aarch64/a53/grp.yml
@@ -32,6 +32,8 @@ links:
   uid: ../../obj
 - role: build-dependency
   uid: ../../objirq
+- role: build-dependency
+  uid: ../../objarmgic
 - role: build-dependency
   uid: ../../objmem
 - role: build-dependency
diff --git a/spec/build/bsps/aarch64/a53/obj.yml 
b/spec/build/bsps/aarch64/a53/obj.yml
index 242631fba2..33c0884b85 100644
--- a/spec/build/bsps/aarch64/a53/obj.yml
+++ b/spec/build/bsps/aarch64/a53/obj.yml
@@ -26,7 +26,6 @@ source:
 - bsps/shared/dev/btimer/btimer-cpucounter.c
 - bsps/shared/dev/clock/arm-generic-timer.c
 - bsps/shared/dev/getentropy/getentropy-cpucounter.c
-- bsps/shared/dev/irq/arm-gicv3.c
 - bsps/shared/dev/serial/console-termios-init.c
 - bsps/shared/dev/serial/console-termios.c
 - bsps/shared/irq/irq-default-handler.c
diff --git a/spec/build/bsps/aarch64/a72/grp.yml 
b/spec/build/bsps/aarch64/a72/grp.yml
index 341f832a61..4cd4719a62 100644
--- a/spec/build/bsps/aarch64/a72/grp.yml
+++ b/spec/build/bsps/aarch64/a72/grp.yml
@@ -32,6 +32,8 @@ links:
   uid: ../../obj
 - role: build-dependency
   uid: ../../objirq
+- role: build-dependency
+  uid: ../../objarmgic
 - role: build-dependency
   uid: ../../objmem
 - role: build-dependency
diff --git a/spec/build/bsps/aarch64/a72/obj.yml 
b/spec/build/bsps/aarch64/a72/obj.yml
index f797762b41..4fb5e59ba3 100644
--- a/spec/build/bsps/aarch64/a72/obj.yml
+++ b/spec/build/bsps/aarch64/a72/obj.yml
@@ -26,7 +26,6 @@ source:
 - bsps/shared/dev/btimer/btimer-cpucounter.c
 - bsps/shared/dev/clock/arm-generic-timer.c
 - bsps/shared/dev/getentropy/getentropy-cpucounter.c
-- bsps/shared/dev/irq/arm-gicv3.c
 - bsps/shared/dev/serial/console-termios-init.c
 - bsps/shared/dev/serial/console-termios.c
 - bsps/shared/irq/irq-default-handler.c

Re: [gcc v2] Enable some features for RTEMS in libstdc++

2022-07-01 Thread Sebastian Huber

On 09.06.22 20:19, Sebastian Huber wrote:

Remove RTEMS support from crossconfig.m4 since this code is not used due to
"with_newlib" being "yes".

libstdc++-v3/ChangeLog:

* configure: Regnerate.
* configure.ac (newlib, *-rtems*): Enable TLS support for all RTEMS
targets except bfin, lm32, mips, moxie, or1k, and v850.
For all RTEMS targets, define HAVE_ALIGNED_ALLOC, HAVE_AT_QUICK_EXIT,
HAVE_LINK, HAVE_POLL, HAVE_QUICK_EXIT, HAVE_READLINK, HAVE_SETENV,
HAVE_SLEEP, HAVE_SOCKATMARK, HAVE_STRERROR_L, HAVE_SYMLINK,
HAVE_TRUNCATE, and HAVE_USLEEP.


I integrated the patch in GCC 13. It is available through the rtems7 
tools in the RSB. See also:


https://lists.rtems.org/pipermail/devel/2022-June/072119.html

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

[PATCH v2 10/13] gcov: Add wrapper to dump the gcov info

2022-07-01 Thread Sebastian Huber
Update #4670.
---
 cpukit/libtest/testgcovbspreset.c | 54 +++
 cpukit/libtest/testgcovcpufatalhalt.c | 54 +++
 spec/build/cpukit/librtemstest.yml|  2 +
 3 files changed, 110 insertions(+)
 create mode 100644 cpukit/libtest/testgcovbspreset.c
 create mode 100644 cpukit/libtest/testgcovcpufatalhalt.c

diff --git a/cpukit/libtest/testgcovbspreset.c 
b/cpukit/libtest/testgcovbspreset.c
new file mode 100644
index 00..6e10615f8c
--- /dev/null
+++ b/cpukit/libtest/testgcovbspreset.c
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSTest
+ *
+ * @brief This source file contains the implementation of a wrapper for
+ *   bsp_reset() which dumps the gcov information using
+ *   rtems_test_gcov_dump_info() before the real bsp_reset() is called.
+ */
+
+/*
+ * Copyright (C) 2021, 2022 embedded brains GmbH
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+
+#include 
+
+void __real_bsp_reset( void );
+
+void __wrap_bsp_reset( void );
+
+void __wrap_bsp_reset( void )
+{
+  rtems_test_gcov_dump_info();
+  __real_bsp_reset();
+}
diff --git a/cpukit/libtest/testgcovcpufatalhalt.c 
b/cpukit/libtest/testgcovcpufatalhalt.c
new file mode 100644
index 00..dd8f10149c
--- /dev/null
+++ b/cpukit/libtest/testgcovcpufatalhalt.c
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSTest
+ *
+ * @brief This source file contains the implementation of a wrapper for
+ *   _CPU_Fatal_halt() which dumps the gcov information using
+ *   rtems_test_gcov_dump_info() before the real _CPU_Fatal_halt() is called.
+ */
+
+/*
+ * Copyright (C) 2021, 2022 embedded brains GmbH
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+
+#include 
+
+void __real__CPU_Fatal_halt( uint32_t source, CPU_Uint32ptr error );
+
+void __wrap__CPU_Fatal_halt( uint32_t source, CPU_Uint32ptr error );
+
+void __wrap__CPU_Fatal_halt( uint32_t source, CPU_Uint32ptr error )
+{
+  rtems_test_gcov_dump_info();
+  __real__CPU_Fatal_halt( source, error );
+}
diff --git a/spec/build/cpukit/librtemstest.yml 
b/spec/build/cpukit/librtemstest.yml
index cb04690066..ddbf6e3e76 100644
--- a/spec/build/cpukit/librtemstest.yml
+++ b/spec/build/cpukit/librtemstest.yml
@@ -38,6 

[PATCH v2 11/13] build: Add RTEMS_GCOV_COVERAGE option

2022-07-01 Thread Sebastian Huber
Update #4670.
---
 spec/build/bsps/optcflags.yml  |  2 +-
 spec/build/cpukit/cpuopts.yml  | 10 +
 spec/build/cpukit/grp.yml  |  2 ++
 spec/build/cpukit/optcoverage.yml  | 16 ++
 spec/build/cpukit/optcoveragecflags.yml| 20 +
 spec/build/cpukit/optcoverageldflags.yml   | 25 ++
 spec/build/cpukit/optnocoveragecflags.yml  | 18 
 spec/build/cpukit/optnocoverageldflags.yml | 18 
 spec/build/testsuites/grp.yml  |  3 ++-
 testsuites/validation/tc-terminate.c   |  2 +-
 testsuites/validation/ts-config.h  |  2 +-
 11 files changed, 114 insertions(+), 4 deletions(-)
 create mode 100644 spec/build/cpukit/optcoverage.yml
 create mode 100644 spec/build/cpukit/optcoveragecflags.yml
 create mode 100644 spec/build/cpukit/optcoverageldflags.yml
 create mode 100644 spec/build/cpukit/optnocoveragecflags.yml
 create mode 100644 spec/build/cpukit/optnocoverageldflags.yml

diff --git a/spec/build/bsps/optcflags.yml b/spec/build/bsps/optcflags.yml
index ef03940bff..302f1723a6 100644
--- a/spec/build/bsps/optcflags.yml
+++ b/spec/build/bsps/optcflags.yml
@@ -1,7 +1,7 @@
 SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 actions:
 - set-value: |
-${BSP_OPTIMIZATION_FLAGS}
+${BSP_OPTIMIZATION_FLAGS} ${COVERAGE_COMPILER_FLAGS}
 - substitute: null
 - split: null
 - env-assign: null
diff --git a/spec/build/cpukit/cpuopts.yml b/spec/build/cpukit/cpuopts.yml
index 301d49ccea..86cc7f676a 100644
--- a/spec/build/cpukit/cpuopts.yml
+++ b/spec/build/cpukit/cpuopts.yml
@@ -67,6 +67,16 @@ links:
   uid: optszoff
 - role: build-dependency
   uid: optsztime
+- role: build-dependency
+  uid: optcoverage
+- role: build-dependency
+  uid: optcoveragecflags
+- role: build-dependency
+  uid: optnocoveragecflags
+- role: build-dependency
+  uid: optcoverageldflags
+- role: build-dependency
+  uid: optnocoverageldflags
 - role: build-dependency
   uid: optversion
 target: cpukit/include/rtems/score/cpuopts.h
diff --git a/spec/build/cpukit/grp.yml b/spec/build/cpukit/grp.yml
index ec9cab2167..76e57aed96 100644
--- a/spec/build/cpukit/grp.yml
+++ b/spec/build/cpukit/grp.yml
@@ -2,11 +2,13 @@ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 build-type: group
 cflags:
 - ${CPUKIT_OPTIMIZATION_FLAGS}
+- ${COVERAGE_COMPILER_FLAGS}
 copyrights:
 - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
 cppflags: []
 cxxflags:
 - ${CPUKIT_OPTIMIZATION_FLAGS}
+- ${COVERAGE_COMPILER_FLAGS}
 enabled-by: true
 includes: []
 install: []
diff --git a/spec/build/cpukit/optcoverage.yml 
b/spec/build/cpukit/optcoverage.yml
new file mode 100644
index 00..7c7013fe43
--- /dev/null
+++ b/spec/build/cpukit/optcoverage.yml
@@ -0,0 +1,16 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-boolean: null
+- env-enable: null
+- define-condition: null
+build-type: option
+copyrights:
+- Copyright (C) 2022 embedded brains GmbH (http://www.embedded-brains.de)
+default: false
+default-by-variant: []
+description: |
+  Enable the code and branch coverage support.
+enabled-by: true
+links: []
+name: RTEMS_GCOV_COVERAGE
+type: build
diff --git a/spec/build/cpukit/optcoveragecflags.yml 
b/spec/build/cpukit/optcoveragecflags.yml
new file mode 100644
index 00..08cc79eb6c
--- /dev/null
+++ b/spec/build/cpukit/optcoveragecflags.yml
@@ -0,0 +1,20 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- split: null
+- env-assign: null
+build-type: option
+copyrights:
+- Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
+default:
+- --coverage
+- -fprofile-info-section=.rtemsroset.gcov_info.content
+- -fprofile-update=atomic
+default-by-variant: []
+description: |
+  Compiler flags recommended for components which should generate coverage
+  information.
+enabled-by: RTEMS_GCOV_COVERAGE
+links: []
+name: COVERAGE_COMPILER_FLAGS
+type: build
diff --git a/spec/build/cpukit/optcoverageldflags.yml 
b/spec/build/cpukit/optcoverageldflags.yml
new file mode 100644
index 00..600c89e770
--- /dev/null
+++ b/spec/build/cpukit/optcoverageldflags.yml
@@ -0,0 +1,25 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- split: null
+- env-assign: null
+build-type: option
+copyrights:
+- Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
+default:
+- -Wl,--wrap=_CPU_Fatal_halt
+- -Wl,--wrap=bsp_reset
+- -Wl,--start-group
+- -lrtemsbsp
+- -lrtemscpu
+- -lrtemstest
+- -lgcov
+- -Wl,--end-group
+default-by-variant: []
+description: |
+  Linker flags recommended for executables which contain modules with coverage
+  information.
+enabled-by: RTEMS_GCOV_COVERAGE
+links: []
+name: COVERAGE_LINKER_FLAGS
+type: build
diff --git a/spec/build/cpukit/optnocoveragecflags.yml 
b/spec/build/cpukit/optnocoveragecflags.yml
new file mode 100644
index 

[PATCH v2 08/13] gcov: Add fork(), etc. gcov wrappers

2022-07-01 Thread Sebastian Huber
The compiler wraps fork(), etc. system calls if coverage generation is enabled.
These functions must be provided by the system.  For RTEMS, they just return an
error status.

Update #4670.
---
 cpukit/libcsupport/src/gcovfork.c | 94 +++
 spec/build/cpukit/librtemscpu.yml |  1 +
 2 files changed, 95 insertions(+)
 create mode 100644 cpukit/libcsupport/src/gcovfork.c

diff --git a/cpukit/libcsupport/src/gcovfork.c 
b/cpukit/libcsupport/src/gcovfork.c
new file mode 100644
index 00..763412d735
--- /dev/null
+++ b/cpukit/libcsupport/src/gcovfork.c
@@ -0,0 +1,94 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup libcsupport
+ *
+ * @brief This source file contains functions required by GCC if code and
+ *   branch coverage instrumentation (gcov) is enabled.
+ */
+
+/*
+ * Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+
+#include 
+
+#include 
+
+int __gcov_execl( const char *, char *, ... );
+
+int __gcov_execl( const char *path, char *arg, ... )
+{
+  rtems_set_errno_and_return_minus_one( ENOSYS );
+}
+
+int __gcov_execlp( const char *, char *, ... );
+
+int __gcov_execlp( const char *path, char *arg, ... )
+{
+  rtems_set_errno_and_return_minus_one( ENOSYS );
+}
+
+int __gcov_execle( const char *, char *, ... );
+
+int __gcov_execle( const char *path, char *arg, ... )
+{
+  rtems_set_errno_and_return_minus_one( ENOSYS );
+}
+
+int __gcov_execv( const char *, char *const[] );
+
+int __gcov_execv( const char *path, char *const argv[] )
+{
+  rtems_set_errno_and_return_minus_one( ENOSYS );
+}
+
+int __gcov_execvp( const char *, char *const[] );
+
+int __gcov_execvp( const char *path, char *const argv[] )
+{
+  rtems_set_errno_and_return_minus_one( ENOSYS );
+}
+
+int __gcov_execve( const char *, char *const[], char *const[] );
+
+int __gcov_execve( const char *path, char *const argv[], char *const envp[] )
+{
+  rtems_set_errno_and_return_minus_one( ENOSYS );
+}
+
+pid_t __gcov_fork( void );
+
+pid_t __gcov_fork( void )
+{
+  rtems_set_errno_and_return_minus_one( ENOSYS );
+}
diff --git a/spec/build/cpukit/librtemscpu.yml 
b/spec/build/cpukit/librtemscpu.yml
index 965419c389..4a8a0ee1ad 100644
--- a/spec/build/cpukit/librtemscpu.yml
+++ b/spec/build/cpukit/librtemscpu.yml
@@ -640,6 +640,7 @@ source:
 - cpukit/libcsupport/src/ftruncate.c
 - cpukit/libcsupport/src/ftrylockfile.c
 - cpukit/libcsupport/src/funlockfile.c
+- cpukit/libcsupport/src/gcovfork.c
 - cpukit/libcsupport/src/getchark.c
 - cpukit/libcsupport/src/getdents.c
 - cpukit/libcsupport/src/getegid.c
-- 
2.35.3

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


[PATCH v2 05/13] build: Add cppflags, cflags, cxxflags to groups

2022-07-01 Thread Sebastian Huber
Propagate the group defined cppflags, cflags, and cxxflags from parent groups
to child items through the build item context.

Update #4670.
---
 spec/build/bsps/aarch64/a53/grp.yml  | 3 +++
 spec/build/bsps/aarch64/a72/grp.yml  | 3 +++
 spec/build/bsps/aarch64/grp.yml  | 3 +++
 spec/build/bsps/aarch64/xilinx-versal/grp.yml| 3 +++
 spec/build/bsps/aarch64/xilinx-versal/grp_qemu.yml   | 3 +++
 spec/build/bsps/aarch64/xilinx-versal/grp_vck190.yml | 3 +++
 spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml| 3 +++
 spec/build/bsps/aarch64/xilinx-zynqmp/grp_zu3eg.yml  | 5 -
 spec/build/bsps/arm/beagle/grp.yml   | 3 +++
 spec/build/bsps/arm/csb337/grp.yml   | 3 +++
 spec/build/bsps/arm/fvp/grp.yml  | 3 +++
 spec/build/bsps/arm/grp.yml  | 3 +++
 spec/build/bsps/arm/lm3s69xx/grp.yml | 3 +++
 spec/build/bsps/arm/lpc176x/grp.yml  | 3 +++
 spec/build/bsps/arm/lpc24xx/grp.yml  | 3 +++
 spec/build/bsps/arm/lpc32xx/grp.yml  | 3 +++
 spec/build/bsps/arm/raspberrypi/grp.yml  | 3 +++
 spec/build/bsps/arm/rtl22xx/grp.yml  | 3 +++
 spec/build/bsps/arm/stm32f4/grp.yml  | 3 +++
 spec/build/bsps/arm/stm32h7/grp.yml  | 3 +++
 spec/build/bsps/arm/tms570/grp.yml   | 3 +++
 spec/build/bsps/arm/xilinx-zynq/grp.yml  | 3 +++
 spec/build/bsps/bfin/grp.yml | 3 +++
 spec/build/bsps/grpmake.yml  | 3 +++
 spec/build/bsps/i386/grp.yml | 3 +++
 spec/build/bsps/i386/pc386/grp.yml   | 3 +++
 spec/build/bsps/lm32/grp.yml | 3 +++
 spec/build/bsps/lm32/lm32_evr/grp.yml| 3 +++
 spec/build/bsps/m68k/gen68360/grp.yml| 3 +++
 spec/build/bsps/m68k/genmcf548x/grp.yml  | 3 +++
 spec/build/bsps/m68k/grp.yml | 3 +++
 spec/build/bsps/m68k/mvme162/grp.yml | 3 +++
 spec/build/bsps/microblaze/grp.yml   | 3 +++
 spec/build/bsps/microblaze/microblaze_fpga/grp.yml   | 3 +++
 spec/build/bsps/mips/grp.yml | 3 +++
 spec/build/bsps/or1k/grp.yml | 3 +++
 spec/build/bsps/powerpc/gen5200/grp.yml  | 3 +++
 spec/build/bsps/powerpc/gen83xx/grp.yml  | 3 +++
 spec/build/bsps/powerpc/grp.yml  | 3 +++
 spec/build/bsps/powerpc/motorola_powerpc/grp.yml | 3 +++
 spec/build/bsps/powerpc/mpc55xxevb/grp.yml   | 3 +++
 spec/build/bsps/powerpc/qoriq/grp.yml| 3 +++
 spec/build/bsps/powerpc/tqm8xx/grp.yml   | 3 +++
 spec/build/bsps/riscv/griscv/grp.yml | 3 +++
 spec/build/bsps/riscv/grp.yml| 3 +++
 spec/build/bsps/riscv/riscv/grp.yml  | 3 +++
 spec/build/bsps/sh/shsim/grp.yml | 3 +++
 spec/build/bsps/sparc/grp.yml| 3 +++
 spec/build/bsps/sparc/leon2/grp.yml  | 3 +++
 spec/build/bsps/sparc/leon3/grp.yml  | 3 +++
 spec/build/bsps/sparc64/grp.yml  | 3 +++
 spec/build/bsps/v850/gdbv850sim/grp.yml  | 3 +++
 spec/build/bsps/x86_64/grp.yml   | 3 +++
 spec/build/cpukit/grp.yml| 3 +++
 spec/build/grp.yml   | 3 +++
 spec/build/testsuites/ada/grp.yml| 3 +++
 spec/build/testsuites/benchmarks/grp.yml | 3 +++
 spec/build/testsuites/fstests/grp.yml| 3 +++
 spec/build/testsuites/grp.yml| 3 +++
 spec/build/testsuites/libtests/grp.yml   | 3 +++
 spec/build/testsuites/mptests/grp.yml| 3 +++
 spec/build/testsuites/psxtests/grp.yml   | 3 +++
 spec/build/testsuites/psxtmtests/grp.yml | 3 +++
 spec/build/testsuites/rhealstone/grp.yml | 3 +++
 spec/build/testsuites/samples/grp.yml| 3 +++
 spec/build/testsuites/smptests/grp.yml   | 3 +++
 spec/build/testsuites/sptests/grp.yml| 3 +++
 spec/build/testsuites/tmtests/grp.yml| 3 +++
 spec/build/testsuites/unit/grp.yml   | 3 +++
 spec/build/testsuites/validation/grp.yml | 3 +++
 wscript  | 6 +++---
 71 files changed, 214 insertions(+), 4 deletions(-)

diff --git a/spec/build/bsps/aarch64/a53/grp.yml 
b/spec/build/bsps/aarch64/a53/grp.yml
index cc6418da75..091f18d6f5 100644
--- a/spec/build/bsps/aarch64/a53/grp.yml
+++ b/spec/build/bsps/aarch64/a53/grp.yml
@@ -1,7 +1,10 @@
 SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 build-type: group
+cflags: []
 copyrights:
 - Copyright (C) 2020 On-Line Applications Research (OAR)
+cppflags: 

[PATCH v2 12/13] samples/minimum: Prevent a stack overflow

2022-07-01 Thread Sebastian Huber
Prevent a stack overflow if RTEMS_COVERAGE is enabled.
---
 testsuites/samples/minimum/init.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/testsuites/samples/minimum/init.c 
b/testsuites/samples/minimum/init.c
index c988d6d750..4238c47659 100644
--- a/testsuites/samples/minimum/init.c
+++ b/testsuites/samples/minimum/init.c
@@ -81,7 +81,12 @@ static void *Init( uintptr_t ignored )
  *  demonstrates that the user can specify how small of a minimum
  *  stack they want.
  */
+#ifdef RTEMS_COVERAGE
+#define CONFIGURE_MINIMUM_TASK_STACK_SIZE \
+  (CPU_STACK_MINIMUM_SIZE - CPU_STACK_ALIGNMENT)
+#else
 #define CONFIGURE_MINIMUM_TASK_STACK_SIZE 512
+#endif
 
 /*
  * Keep the interrupt/initialization stack as is.  Otherwise, the test may fail
-- 
2.35.3

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


[PATCH v2 13/13] libtests/crypt01: Avoid stack overflows

2022-07-01 Thread Sebastian Huber
The SHA512 functions may use huge amounts of stack space if compiled without
optimization.
---
 testsuites/libtests/crypt01/init.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/testsuites/libtests/crypt01/init.c 
b/testsuites/libtests/crypt01/init.c
index 0944aa60f7..26ba70e250 100644
--- a/testsuites/libtests/crypt01/init.c
+++ b/testsuites/libtests/crypt01/init.c
@@ -36,6 +36,8 @@
 #include 
 #include 
 
+#include 
+
 #include "tmacros.h"
 
 const char rtems_test_name[] = "CRYPT 1";
@@ -234,18 +236,20 @@ static void Init(rtems_task_argument arg)
   test_sha512();
   test_generic();
 
+  rtems_test_assert(!rtems_stack_checker_is_blown());
   TEST_END();
   rtems_test_exit(0);
 }
 
 #define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
+#define CONFIGURE_STACK_CHECKER_ENABLED
 
 #define CONFIGURE_MAXIMUM_TASKS 1
 
 #define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
 
-#define CONFIGURE_INIT_TASK_STACK_SIZE (2 * RTEMS_MINIMUM_STACK_SIZE)
+#define CONFIGURE_INIT_TASK_STACK_SIZE (8 * RTEMS_MINIMUM_STACK_SIZE)
 
 #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
 
-- 
2.35.3

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


[PATCH v2 06/13] build: Fix optimization flags definition order

2022-07-01 Thread Sebastian Huber
OPTIMIZATION_FLAGS must be defined before /build/bsp/bspopts is processed.

Update #4670.
---
 spec/build/bsps/arm/beagle/bspboardorig.yml   | 4 ++--
 spec/build/bsps/arm/beagle/bspboardxm.yml | 4 ++--
 spec/build/bsps/arm/beagle/bspboneblack.yml   | 4 ++--
 spec/build/bsps/arm/beagle/bspbonewhite.yml   | 4 ++--
 spec/build/bsps/arm/csb337/bspcsb337.yml  | 4 ++--
 spec/build/bsps/arm/csb337/bspcsb637.yml  | 4 ++--
 spec/build/bsps/arm/csb337/bspkit637v6.yml| 4 ++--
 spec/build/bsps/arm/fvp/bspcortexr52.yml  | 4 ++--
 spec/build/bsps/arm/lm3s69xx/bsplm3s3749.yml  | 4 ++--
 spec/build/bsps/arm/lm3s69xx/bsplm3s6965.yml  | 4 ++--
 spec/build/bsps/arm/lm3s69xx/bsplm4f120.yml   | 4 ++--
 spec/build/bsps/arm/lm3s69xx/bspqemu.yml  | 4 ++--
 spec/build/bsps/arm/lpc176x/bsplpc1768mbed.yml| 4 ++--
 spec/build/bsps/arm/lpc176x/bsplpc1768mbedahbram.yml  | 4 ++--
 spec/build/bsps/arm/lpc176x/bsplpc1768mbedahbrameth.yml   | 4 ++--
 spec/build/bsps/arm/lpc24xx/bsplpc17xxearam.yml   | 4 ++--
 spec/build/bsps/arm/lpc24xx/bsplpc17xxearomint.yml| 4 ++--
 spec/build/bsps/arm/lpc24xx/bsplpc17xxplx800ram.yml   | 4 ++--
 spec/build/bsps/arm/lpc24xx/bsplpc17xxplx800romint.yml| 4 ++--
 spec/build/bsps/arm/lpc24xx/bsplpc2362.yml| 4 ++--
 spec/build/bsps/arm/lpc24xx/bsplpc23xxtli800.yml  | 4 ++--
 spec/build/bsps/arm/lpc24xx/bsplpc24xxea.yml  | 4 ++--
 spec/build/bsps/arm/lpc24xx/bsplpc40xxearam.yml   | 4 ++--
 spec/build/bsps/arm/lpc24xx/bsplpc40xxearomint.yml| 4 ++--
 spec/build/bsps/arm/lpc24xx/bspncsram.yml | 4 ++--
 spec/build/bsps/arm/lpc24xx/bspncsromext.yml  | 4 ++--
 spec/build/bsps/arm/lpc24xx/bspncsromint.yml  | 4 ++--
 spec/build/bsps/arm/lpc24xx/bspplx800ram.yml  | 4 ++--
 spec/build/bsps/arm/lpc24xx/bspplx800romint.yml   | 4 ++--
 spec/build/bsps/arm/lpc32xx/bsplpc32xxmzx.yml | 4 ++--
 spec/build/bsps/arm/lpc32xx/bspmzxstage1.yml  | 4 ++--
 spec/build/bsps/arm/lpc32xx/bspmzxstage2.yml  | 4 ++--
 spec/build/bsps/arm/lpc32xx/bspphycore.yml| 4 ++--
 spec/build/bsps/arm/raspberrypi/bspraspberrypi.yml| 4 ++--
 spec/build/bsps/arm/raspberrypi/bspraspberrypi2.yml   | 4 ++--
 spec/build/bsps/arm/rtl22xx/bsprtl22xx.yml| 4 ++--
 spec/build/bsps/arm/rtl22xx/bsprtl22xxt.yml   | 4 ++--
 spec/build/bsps/arm/stm32f4/bspstm32f105rc.yml| 4 ++--
 spec/build/bsps/arm/stm32f4/bspstm32f4.yml| 4 ++--
 spec/build/bsps/arm/tms570/bspls3137hdk.yml   | 4 ++--
 spec/build/bsps/arm/tms570/bspls3137hdkintram.yml | 4 ++--
 spec/build/bsps/arm/tms570/bspls3137hdksdram.yml  | 4 ++--
 spec/build/bsps/arm/tms570/bspls3137hdkwithloader.yml | 4 ++--
 spec/build/bsps/arm/xilinx-zynq/bspqemu.yml   | 4 ++--
 spec/build/bsps/arm/xilinx-zynq/bspzc702.yml  | 4 ++--
 spec/build/bsps/arm/xilinx-zynq/bspzc706.yml  | 4 ++--
 spec/build/bsps/arm/xilinx-zynq/bspzedboard.yml   | 4 ++--
 spec/build/bsps/i386/pc386/bsppc386.yml   | 4 ++--
 spec/build/bsps/i386/pc386/bsppc486.yml   | 4 ++--
 spec/build/bsps/i386/pc386/bsppc586.yml   | 4 ++--
 spec/build/bsps/i386/pc386/bsppc586sse.yml| 4 ++--
 spec/build/bsps/i386/pc386/bsppc686.yml   | 4 ++--
 spec/build/bsps/i386/pc386/bsppcp4.yml| 4 ++--
 spec/build/bsps/lm32/lm32_evr/bspgdbsim.yml   | 4 ++--
 spec/build/bsps/lm32/lm32_evr/bsplm32evr.yml  | 4 ++--
 spec/build/bsps/m68k/gen68360/bspgen68360.yml | 4 ++--
 spec/build/bsps/m68k/gen68360/bspgen68360040.yml  | 4 ++--
 spec/build/bsps/m68k/gen68360/bsppgh360.yml   | 4 ++--
 spec/build/bsps/m68k/genmcf548x/bspcobra5475.yml  | 4 ++--
 spec/build/bsps/m68k/genmcf548x/bspm5484fireengine.yml| 4 ++--
 spec/build/bsps/m68k/mvme162/bspmvme162.yml   | 4 ++--
 spec/build/bsps/m68k/mvme162/bspmvme162lx.yml | 4 ++--
 spec/build/bsps/microblaze/microblaze_fpga/bspkcu105.yml  | 4 ++--
 spec/build/bsps/microblaze/microblaze_fpga/bspkcu105_qemu.yml | 4 ++--
 64 files changed, 128 insertions(+), 128 deletions(-)

diff --git a/spec/build/bsps/arm/beagle/bspboardorig.yml 
b/spec/build/bsps/arm/beagle/bspboardorig.yml
index 92eb7001fd..02423f64a6 100644
--- a/spec/build/bsps/arm/beagle/bspboardorig.yml
+++ b/spec/build/bsps/arm/beagle/bspboardorig.yml

[PATCH v2 09/13] gcov: Add functions to dump the gcov information

2022-07-01 Thread Sebastian Huber
Update #4670.
---
 cpukit/include/rtems/score/gcov.h   |  66 ++
 cpukit/include/rtems/score/io.h |   4 +
 cpukit/include/rtems/test-info.h|   6 ++
 cpukit/libtest/testgcovdumpinfo.c   |  66 ++
 cpukit/score/src/gcovinfoset.c  |  42 +
 cpukit/score/src/iogcovdumpinfo.c   |  97 +
 cpukit/score/src/iogcovdumpinfobase64.c | 111 
 spec/build/cpukit/librtemscpu.yml   |   3 +
 spec/build/cpukit/librtemstest.yml  |   1 +
 testsuites/validation/tc-terminate.c|   3 +-
 10 files changed, 398 insertions(+), 1 deletion(-)
 create mode 100644 cpukit/include/rtems/score/gcov.h
 create mode 100644 cpukit/libtest/testgcovdumpinfo.c
 create mode 100644 cpukit/score/src/gcovinfoset.c
 create mode 100644 cpukit/score/src/iogcovdumpinfo.c
 create mode 100644 cpukit/score/src/iogcovdumpinfobase64.c

diff --git a/cpukit/include/rtems/score/gcov.h 
b/cpukit/include/rtems/score/gcov.h
new file mode 100644
index 00..de8206fac5
--- /dev/null
+++ b/cpukit/include/rtems/score/gcov.h
@@ -0,0 +1,66 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreGcov
+ *
+ * @brief This header file provides the interfaces of the
+ *   @ref RTEMSScoreGcov.
+ */
+
+/*
+ * Copyright (c) 2013-2014 embedded brains GmbH.  All rights reserved.
+ *
+ * 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 _RTEMS_SCORE_GCOV_H
+#define _RTEMS_SCORE_GCOV_H
+
+#include 
+
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+/**
+ * @defgroup RTEMSScoreGcov Gcov Support
+ *
+ * @ingroup RTEMSScore
+ *
+ * @brief This group contains the gocv support.
+ *
+ * @{
+ */
+
+RTEMS_LINKER_ROSET_DECLARE( gcov_info, const struct gcov_info * );
+
+/** @} */
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* _RTEMS_SCORE_GCOV_H */
diff --git a/cpukit/include/rtems/score/io.h b/cpukit/include/rtems/score/io.h
index 106418f185..097cb9bdfe 100644
--- a/cpukit/include/rtems/score/io.h
+++ b/cpukit/include/rtems/score/io.h
@@ -141,6 +141,10 @@ int _IO_Base64url(
  */
 void _IO_Relax( void );
 
+void _IO_Gcov_dump_info( IO_Put_char put_char, void *arg );
+
+void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg );
+
 /** @} */ 
 
 #ifdef __cplusplus
diff --git a/cpukit/include/rtems/test-info.h b/cpukit/include/rtems/test-info.h
index 1bc963249c..c7c6c2438d 100644
--- a/cpukit/include/rtems/test-info.h
+++ b/cpukit/include/rtems/test-info.h
@@ -331,6 +331,12 @@ RTEMS_NO_RETURN void rtems_test_run(
   const RTEMS_TEST_STATE state
 );
 
+/**
+ * @brief Dumps the gcov information as a base64 encoded gcfn and gcda data
+ *   stream using rtems_put_char().
+ */
+void rtems_test_gcov_dump_info( void );
+
 /** @} */
 
 #ifdef __cplusplus
diff --git a/cpukit/libtest/testgcovdumpinfo.c 
b/cpukit/libtest/testgcovdumpinfo.c
new file mode 100644
index 00..4276d9e1c3
--- /dev/null
+++ b/cpukit/libtest/testgcovdumpinfo.c
@@ -0,0 +1,66 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSTest
+ *
+ * @brief This source file contains the implementation of
+ *   rtems_test_gcov_dump_info().
+ */
+
+/*
+ * Copyright (C) 2021, 2022 embedded brains GmbH
+ *
+ * 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

[PATCH v2 00/13] Support gcov instrumentation

2022-07-01 Thread Sebastian Huber
This patch set adds support to build the RTEMS libraries with gcov
instrumentation to get code and branch coverage.  There are some improvements
necessary in the build system to support different compiler flags for libraries
and tests.  In general, code coverage is enabled by the new RTEMS_COVERAGE
build configuration option.  The user can fine tune the build through the
BSP_OPTIMIZATION_FLAGS, CPUKIT_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and
COVERAGE_COMPILER_FLAGS, COVERAGE_LINKER_FLAGS options.  The gcov information
is dumped after each test case in a base64 encoded gcfn and gcda data stream.
It looks like this:

*** BEGIN OF GCOV INFO BASE64 ***
bmZjZyAxMkJSL3RtcC9zaC9iLXJ0ZW1zL2FybS94aWxpbnhfenlucV9hOV9xZW11L2NwdWtp
dC9saWJjc3VwcG9ydC9zcmMvX19nZXR0b2QuYy42NS5nY2RhAGFkY2cgMTJCPoT6qo6mcBUB
DOOrF1pxp0aIPrK7wAAAoQHwAQwAAADTfDdNQYCYwJ9ZRL0AAKEBIAQA
...
srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAAoQH4AQwAAACYh8U9/rgJ5hMc
ig8AAKEB2P///wEMN3+9YAwMW8gTHIoPAAChAdj///8BDDAwMx4TuamFPrK7
wAAAoQHwAQwAAACvassJzDNWd/lKs3wAAKEB8P///wA=
*** END OF GCOV INFO BASE64 ***

On the host you can decode the block and pipe it through the gcov-tool to
produce the *.gcda files.  Example Python code:

block = some regex stuff to get the block between the BEGIN/END OF ...
stream = base64.b64decode(block)
subprocess.run(["arm-rtems6-gcov-tool", "merge-stream"], input=stream)

v2:

* Rename RTEMS_COVERAGE in RTEMS_GCOV_COVERAGE

* Add  and provide gcov_info linker set in separate file.

* Split LIBRARY_OPTIMIZATION_FLAGS in BSP_OPTIMIZATION_FLAGS and
  CPUKIT_OPTIMIZATION_FLAGS.

Sebastian Huber (13):
  build: Add more flags to BuildItemContext
  build: Move BSP_INCLUDES split
  build: Fix identifier pattern
  build: Improve value substitution
  build: Add cppflags, cflags, cxxflags to groups
  build: Fix optimization flags definition order
  build: Allow separate optimization flags
  gcov: Add fork(), etc. gcov wrappers
  gcov: Add functions to dump the gcov information
  gcov: Add wrapper to dump the gcov info
  build: Add RTEMS_GCOV_COVERAGE option
  samples/minimum: Prevent a stack overflow
  libtests/crypt01: Avoid stack overflows

 cpukit/include/rtems/score/gcov.h |  66 ++
 cpukit/include/rtems/score/io.h   |   4 +
 cpukit/include/rtems/test-info.h  |   6 +
 cpukit/libcsupport/src/gcovfork.c |  94 ++
 cpukit/libtest/testgcovbspreset.c |  54 
 cpukit/libtest/testgcovcpufatalhalt.c |  54 
 cpukit/libtest/testgcovdumpinfo.c |  66 ++
 cpukit/score/src/gcovinfoset.c|  42 ++
 cpukit/score/src/iogcovdumpinfo.c |  97 ++
 cpukit/score/src/iogcovdumpinfobase64.c   | 111 
 spec/build/bsps/aarch64/a53/grp.yml   |   3 +
 spec/build/bsps/aarch64/a72/grp.yml   |   3 +
 spec/build/bsps/aarch64/grp.yml   |   3 +
 spec/build/bsps/aarch64/xilinx-versal/grp.yml |   3 +
 .../bsps/aarch64/xilinx-versal/grp_qemu.yml   |   3 +
 .../bsps/aarch64/xilinx-versal/grp_vck190.yml |   3 +
 spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml |   3 +
 .../bsps/aarch64/xilinx-zynqmp/grp_zu3eg.yml  |   5 +-
 spec/build/bsps/arm/beagle/bspboardorig.yml   |   4 +-
 spec/build/bsps/arm/beagle/bspboardxm.yml |   4 +-
 spec/build/bsps/arm/beagle/bspboneblack.yml   |   4 +-
 spec/build/bsps/arm/beagle/bspbonewhite.yml   |   4 +-
 spec/build/bsps/arm/beagle/grp.yml|   3 +
 spec/build/bsps/arm/csb337/bspcsb337.yml  |   4 +-
 spec/build/bsps/arm/csb337/bspcsb637.yml  |   4 +-
 spec/build/bsps/arm/csb337/bspkit637v6.yml|   4 +-
 spec/build/bsps/arm/csb337/grp.yml|   3 +
 spec/build/bsps/arm/fvp/bspcortexr52.yml  |   4 +-
 spec/build/bsps/arm/fvp/grp.yml   |   3 +
 spec/build/bsps/arm/grp.yml   |   3 +
 spec/build/bsps/arm/lm3s69xx/bsplm3s3749.yml  |   4 +-
 spec/build/bsps/arm/lm3s69xx/bsplm3s6965.yml  |   4 +-
 spec/build/bsps/arm/lm3s69xx/bsplm4f120.yml   |   4 +-
 spec/build/bsps/arm/lm3s69xx/bspqemu.yml  |   4 +-
 spec/build/bsps/arm/lm3s69xx/grp.yml  |   3 +
 .../build/bsps/arm/lpc176x/bsplpc1768mbed.yml |   4 +-
 .../bsps/arm/lpc176x/bsplpc1768mbedahbram.yml |   4 +-
 .../arm/lpc176x/bsplpc1768mbedahbrameth.yml   |   4 +-
 spec/build/bsps/arm/lpc176x/grp.yml   |   3 +
 .../bsps/arm/lpc24xx/bsplpc17xxearam.yml  |   4 +-
 .../bsps/arm/lpc24xx/bsplpc17xxearomint.yml   |   4 +-
 .../bsps/arm/lpc24xx/bsplpc17xxplx800ram.yml  |   4 +-
 .../arm/lpc24xx/bsplpc17xxplx800romint.yml|   4 +-
 spec/build/bsps/arm/lpc24xx/bsplpc2362.yml|   4 +-
 .../bsps/arm/lpc24xx/bsplpc23xxtli800.yml |   4 +-
 spec/build/bsps/arm/lpc24xx/bsplpc24xxea.yml  |   4 +-
 .../bsps/arm/lpc24xx/bsplpc40xxearam.yml  |   4 +-
 .../bsps/arm/lpc24xx/bsplpc40xxearomint.yml   |   4 +-
 

[PATCH v2 07/13] build: Allow separate optimization flags

2022-07-01 Thread Sebastian Huber
Allow separate optimization flags for the BSP, cpukit, and tests.  For example,
the BSP and cpukit may be built without optimization if coverage
instrumentation is enabled, however, the tests may still use optimization.

Update #4670.
---
 spec/build/bsps/bspopts.yml   |  8 
 spec/build/bsps/optbspoptflags.yml| 18 ++
 spec/build/bsps/optcflags.yml | 17 +
 spec/build/bsps/optcpukitoptflags.yml | 18 ++
 spec/build/bsps/opto0.yml |  4 +---
 spec/build/bsps/opto1.yml |  4 +---
 spec/build/bsps/opto2.yml |  4 +---
 spec/build/bsps/optog.yml |  4 +---
 spec/build/bsps/optos.yml |  4 +---
 spec/build/bsps/opttestoptflags.yml   | 18 ++
 spec/build/cpukit/grp.yml |  6 --
 spec/build/testsuites/grp.yml |  6 --
 wscript   |  2 +-
 13 files changed, 93 insertions(+), 20 deletions(-)
 create mode 100644 spec/build/bsps/optbspoptflags.yml
 create mode 100644 spec/build/bsps/optcflags.yml
 create mode 100644 spec/build/bsps/optcpukitoptflags.yml
 create mode 100644 spec/build/bsps/opttestoptflags.yml

diff --git a/spec/build/bsps/bspopts.yml b/spec/build/bsps/bspopts.yml
index d43136e94e..4a4c06d321 100644
--- a/spec/build/bsps/bspopts.yml
+++ b/spec/build/bsps/bspopts.yml
@@ -7,6 +7,12 @@ guard: __BSP_OPTIONS_H
 include-headers: []
 install-path: ${BSP_INCLUDEDIR}
 links:
+- role: build-dependency
+  uid: optbspoptflags
+- role: build-dependency
+  uid: optcpukitoptflags
+- role: build-dependency
+  uid: opttestoptflags
 - role: build-dependency
   uid: optabi
 - role: build-dependency
@@ -17,6 +23,8 @@ links:
   uid: optfatalverb
 - role: build-dependency
   uid: optincludes
+- role: build-dependency
+  uid: optcflags
 - role: build-dependency
   uid: optlinkflags
 - role: build-dependency
diff --git a/spec/build/bsps/optbspoptflags.yml 
b/spec/build/bsps/optbspoptflags.yml
new file mode 100644
index 00..40dbb6c7ab
--- /dev/null
+++ b/spec/build/bsps/optbspoptflags.yml
@@ -0,0 +1,18 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- substitute: null
+- split: null
+- env-assign: null
+build-type: option
+copyrights:
+- Copyright (C) 2022 embedded brains GmbH (http://www.embedded-brains.de)
+default: ${OPTIMIZATION_FLAGS}
+default-by-variant: []
+description: |
+  Optimization flags passed to C and C++ compilers for the BSP.
+enabled-by: true
+format: '{}'
+links: []
+name: BSP_OPTIMIZATION_FLAGS
+type: build
diff --git a/spec/build/bsps/optcflags.yml b/spec/build/bsps/optcflags.yml
new file mode 100644
index 00..ef03940bff
--- /dev/null
+++ b/spec/build/bsps/optcflags.yml
@@ -0,0 +1,17 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- set-value: |
+${BSP_OPTIMIZATION_FLAGS}
+- substitute: null
+- split: null
+- env-assign: null
+build-type: option
+copyrights:
+- Copyright (C) 2022 embedded brains GmbH (http://www.embedded-brains.de)
+default: null
+default-by-variant: []
+description: ''
+enabled-by: true
+links: []
+name: BSP_CFLAGS
+type: build
diff --git a/spec/build/bsps/optcpukitoptflags.yml 
b/spec/build/bsps/optcpukitoptflags.yml
new file mode 100644
index 00..3baec4b8c8
--- /dev/null
+++ b/spec/build/bsps/optcpukitoptflags.yml
@@ -0,0 +1,18 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- substitute: null
+- split: null
+- env-assign: null
+build-type: option
+copyrights:
+- Copyright (C) 2022 embedded brains GmbH (http://www.embedded-brains.de)
+default: ${OPTIMIZATION_FLAGS}
+default-by-variant: []
+description: |
+  Optimization flags passed to C and C++ compilers for the CPU kit.
+enabled-by: true
+format: '{}'
+links: []
+name: CPUKIT_OPTIMIZATION_FLAGS
+type: build
diff --git a/spec/build/bsps/opto0.yml b/spec/build/bsps/opto0.yml
index 406286980f..9f54709c07 100644
--- a/spec/build/bsps/opto0.yml
+++ b/spec/build/bsps/opto0.yml
@@ -3,8 +3,6 @@ actions:
 - get-string: null
 - split: null
 - env-assign: null
-- env-append: CFLAGS
-- env-append: CXXFLAGS
 build-type: option
 copyrights:
 - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
@@ -15,7 +13,7 @@ default:
 - -ffunction-sections
 default-by-variant: []
 description: |
-  Optimization flags passed to the C and C++ compiler
+  Default optimization flags for C and C++ compilers.
 enabled-by: true
 links: []
 name: OPTIMIZATION_FLAGS
diff --git a/spec/build/bsps/opto1.yml b/spec/build/bsps/opto1.yml
index 52d285c2ab..e0668a887b 100644
--- a/spec/build/bsps/opto1.yml
+++ b/spec/build/bsps/opto1.yml
@@ -3,8 +3,6 @@ actions:
 - get-string: null
 - split: null
 - env-assign: null
-- env-append: CFLAGS
-- env-append: CXXFLAGS
 build-type: option
 copyrights:
 - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
@@ -15,7 +13,7 @@ default:
 - -ffunction-sections
 default-by-variant: 

[PATCH v2 01/13] build: Add more flags to BuildItemContext

2022-07-01 Thread Sebastian Huber
Add cppflags, cflags, and cxxflags to BuildItemContext.  This allows to
propagate the flags from parent items to child items.

Update #4670.
---
 wscript | 93 +++--
 1 file changed, 70 insertions(+), 23 deletions(-)

diff --git a/wscript b/wscript
index 8ad0ed30b1..e6abdaa7b5 100755
--- a/wscript
+++ b/wscript
@@ -513,6 +513,9 @@ class GroupItem(Item):
 def prepare_build(self, bld, bic):
 return BuildItemContext(
 bic.includes + self.get_values(bld, "includes"),
+bic.cppflags,
+bic.cflags,
+bic.cxxflags,
 self.data["use-before"] + bic.use + self.data["use-after"],
 bic.ldflags + self.get_values(bld, "ldflags"),
 bic.objects,
@@ -578,13 +581,24 @@ class ObjectsItem(Item):
 def __init__(self, uid, data):
 super(ObjectsItem, self).__init__(uid, data)
 
+def prepare_build(self, bld, bic):
+return BuildItemContext(
+bic.includes + self.substitute(bld, self.data["includes"]),
+bic.cppflags + self.substitute(bld, self.data["cppflags"]),
+bic.cflags + self.substitute(bld, self.data["cflags"]),
+bic.cxxflags + self.substitute(bld, self.data["cxxflags"]),
+bic.use,
+bic.ldflags,
+bic.objects,
+)
+
 def do_build(self, bld, bic):
 bld.objects(
-asflags=self.substitute(bld, self.data["cppflags"]),
-cflags=self.substitute(bld, self.data["cflags"]),
-cppflags=self.substitute(bld, self.data["cppflags"]),
-cxxflags=self.substitute(bld, self.data["cxxflags"]),
-includes=bic.includes + self.substitute(bld, 
self.data["includes"]),
+asflags=bic.cppflags,
+cflags=bic.cflags,
+cppflags=bic.cppflags,
+cxxflags=bic.cxxflags,
+includes=bic.includes,
 source=self.data["source"],
 target=self.uid,
 )
@@ -600,15 +614,23 @@ class BSPItem(Item):
 
 def prepare_build(self, bld, bic):
 return BuildItemContext(
-bic.includes + bld.env.BSP_INCLUDES.split(), [], [], []
+bic.includes
++ bld.env.BSP_INCLUDES.split()
++ self.substitute(bld, self.data["includes"]),
+self.substitute(bld, self.data["cppflags"]),
+self.substitute(bld, self.data["cflags"]),
+[],
+[],
+[],
+[],
 )
 
 def do_build(self, bld, bic):
 bld(
-cflags=self.substitute(bld, self.data["cflags"]),
-cppflags=self.substitute(bld, self.data["cppflags"]),
+cflags=bic.cflags,
+cppflags=bic.cppflags,
 features="c cstlib",
-includes=bic.includes + self.substitute(bld, 
self.data["includes"]),
+includes=bic.includes,
 install_path="${BSP_LIBDIR}",
 source=self.data["source"],
 target="rtemsbsp",
@@ -622,15 +644,23 @@ class LibraryItem(Item):
 super(LibraryItem, self).__init__(uid, data)
 
 def prepare_build(self, bld, bic):
-return BuildItemContext(bic.includes, [], [], [])
+return BuildItemContext(
+bic.includes + self.substitute(bld, self.data["includes"]),
+bic.cppflags + self.substitute(bld, self.data["cppflags"]),
+bic.cflags + self.substitute(bld, self.data["cflags"]),
+bic.cxxflags + self.substitute(bld, self.data["cxxflags"]),
+bic.use,
+bic.ldflags,
+[],
+)
 
 def do_build(self, bld, bic):
 bld(
-cflags=self.substitute(bld, self.data["cflags"]),
-cppflags=self.substitute(bld, self.data["cppflags"]),
-cxxflags=self.substitute(bld, self.data["cxxflags"]),
+cflags=bic.cflags,
+cppflags=bic.cppflags,
+cxxflags=bic.cxxflags,
 features="c cxx cstlib",
-includes=bic.includes + self.substitute(bld, 
self.data["includes"]),
+includes=bic.includes,
 install_path=self.data["install-path"],
 source=self.data["source"],
 target=self.get(bld, "target"),
@@ -650,22 +680,32 @@ class TestProgramItem(Item):
 return [{"and": [{"not": self.exclude}, self.data["enabled-by"]]}]
 
 def prepare_build(self, bld, bic):
-return BuildItemContext(bic.includes, bic.use, bic.ldflags, [])
+return BuildItemContext(
+bic.includes + self.substitute(bld, self.data["includes"]),
+bic.cppflags
++ bld.env[self.cppflags]
++ self.substitute(bld, self.data["cppflags"]),
+bic.cflags + self.substitute(bld, self.data["cflags"]),
+bic.cxxflags + self.substitute(bld, self.data["cxxflags"]),
+self.data["use-before"] + bic.use + self.data["use-after"],
+

[PATCH v2 04/13] build: Improve value substitution

2022-07-01 Thread Sebastian Huber
The waf build system uses lists for tool flags.  The build items may use
variable substitution.  Add the ability to use the variable substitution in
lists.  For example:

MORE_FLAGS = ['-more', '-flags']

flags:
- -some-flag
- ${MORE_FLAGS}

Before this change, the ${MORE_FLAGS} was substituted to "-more -flags".  This
would be passed by waf as a single command line argument to the tool.

After this change, the ${MORE_FLAGS} list extends the flags list:

flags = ['-some-flag', '-more', '-flags']

This list extension is performed if a list element consists of exactly one
variable.

Update #4670.
---
 wscript | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/wscript b/wscript
index 731d1402ff..6ad230aca5 100755
--- a/wscript
+++ b/wscript
@@ -115,6 +115,9 @@ class Template(string.Template):
 idpattern = "[_A-Za-z][_A-Za-z0-9:#]*"
 
 
+_VAR_PATTERN = re.compile("\$\{?(" + Template.idpattern + ")\}?$")
+
+
 def _is_enabled_op_and(enabled, enabled_by):
 for next_enabled_by in enabled_by:
 if not _is_enabled(enabled, next_enabled_by):
@@ -249,18 +252,22 @@ class Item(object):
 )
 )
 if isinstance(value, list):
-return [self.substitute(ctx, subvalue) for subvalue in value]
+more = []
+for item in value:
+if isinstance(item, str):
+m = _VAR_PATTERN.match(item)
+else:
+m = None
+if m:
+more.extend(ctx.env[m.group(1).strip("{}")])
+else:
+more.append(self.substitute(ctx, item))
+return more
 return value
 
 def get(self, ctx, name):
 return self.substitute(ctx, self.data[name])
 
-def get_values(self, ctx, name):
-more = []
-for value in self.data[name]:
-more.extend(self.substitute(ctx, value).split())
-return more
-
 def install_target(self, bld):
 install_path = self.data["install-path"]
 if install_path:
@@ -512,12 +519,12 @@ class GroupItem(Item):
 
 def prepare_build(self, bld, bic):
 return BuildItemContext(
-bic.includes + self.get_values(bld, "includes"),
+bic.includes + self.substitute(bld, self.data["includes"]),
 bic.cppflags,
 bic.cflags,
 bic.cxxflags,
 self.data["use-before"] + bic.use + self.data["use-after"],
-bic.ldflags + self.get_values(bld, "ldflags"),
+bic.ldflags + self.substitute(bld, self.data["ldflags"]),
 bic.objects,
 )
 
-- 
2.35.3

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


[PATCH v2 03/13] build: Fix identifier pattern

2022-07-01 Thread Sebastian Huber
Allow upper case characters in identifiers.

Update #4670.
---
 wscript | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/wscript b/wscript
index 38910f2816..731d1402ff 100755
--- a/wscript
+++ b/wscript
@@ -112,7 +112,7 @@ class EnvWrapper(object):
 
 
 class Template(string.Template):
-idpattern = "[_a-z][_a-z0-9:#]*"
+idpattern = "[_A-Za-z][_A-Za-z0-9:#]*"
 
 
 def _is_enabled_op_and(enabled, enabled_by):
-- 
2.35.3

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


[PATCH v2 02/13] build: Move BSP_INCLUDES split

2022-07-01 Thread Sebastian Huber
The goal is to let the build items define as much as possible.
---
 spec/build/bsps/optincludes.yml | 1 +
 wscript | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/spec/build/bsps/optincludes.yml b/spec/build/bsps/optincludes.yml
index 0b4a71031c..ea57fe3e05 100644
--- a/spec/build/bsps/optincludes.yml
+++ b/spec/build/bsps/optincludes.yml
@@ -3,6 +3,7 @@ actions:
 - set-value: |
 bsps/include bsps/${ARCH}/include bsps/${ARCH}/${BSP_FAMILY}/include
 - substitute: null
+- split: null
 - env-assign: null
 build-type: option
 copyrights:
diff --git a/wscript b/wscript
index e6abdaa7b5..38910f2816 100755
--- a/wscript
+++ b/wscript
@@ -615,7 +615,7 @@ class BSPItem(Item):
 def prepare_build(self, bld, bic):
 return BuildItemContext(
 bic.includes
-+ bld.env.BSP_INCLUDES.split()
++ bld.env.BSP_INCLUDES
 + self.substitute(bld, self.data["includes"]),
 self.substitute(bld, self.data["cppflags"]),
 self.substitute(bld, self.data["cflags"]),
-- 
2.35.3

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


[PATCH] samples/cdtest: Test execeptions during system init

2022-07-01 Thread Sebastian Huber
Update #4668.
Update #4672.
---
 testsuites/samples/cdtest/main.cc | 44 ---
 1 file changed, 35 insertions(+), 9 deletions(-)

diff --git a/testsuites/samples/cdtest/main.cc 
b/testsuites/samples/cdtest/main.cc
index 894e404ba1..44cdaf84bb 100644
--- a/testsuites/samples/cdtest/main.cc
+++ b/testsuites/samples/cdtest/main.cc
@@ -25,9 +25,11 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef RTEMS_TEST_IO_STREAM
@@ -44,13 +46,6 @@ extern rtems_task main_task(rtems_task_argument);
 
 static int num_inst = 0;
 
-static void check_begin_of_test(void)
-{
-  if ( num_inst == 0 ) {
-TEST_BEGIN();
-  }
-}
-
 static void check_end_of_test(void)
 {
   if ( num_inst == 0 ) {
@@ -62,7 +57,6 @@ class AClass {
 public:
   AClass(const char *p = "LOCAL" ) : ptr( p )
 {
-check_begin_of_test();
 num_inst++;
 printf(
   "%s: Hey I'm in base class constructor number %d for %p.\n",
@@ -104,7 +98,6 @@ class BClass : public AClass {
 public:
   BClass(const char *p = "LOCAL" ) : AClass( p )
 {
-check_begin_of_test();
 num_inst++;
 printf(
   "%s: Hey I'm in derived class constructor number %d for %p.\n",
@@ -244,3 +237,36 @@ rtems_task main_task(
 printf( "Global Dtors should be called after this line\n" );
 exit(0);
 }
+
+static void early_exception()
+{
+try
+{
+  throw "early exception";
+}
+catch( const char *e )
+{
+  rtems_test_assert(strcmp(e, "early exception") == 0);
+  throw "early exception 2";
+}
+}
+
+static void test_exceptions_during_system_init()
+{
+TEST_BEGIN();
+
+try
+{
+  early_exception();
+}
+catch( const char *e )
+{
+  rtems_test_assert(strcmp(e, "early exception 2") == 0);
+}
+}
+
+RTEMS_SYSINIT_ITEM(
+test_exceptions_during_system_init,
+RTEMS_SYSINIT_IDLE_THREADS,
+RTEMS_SYSINIT_ORDER_LAST
+);
-- 
2.35.3

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


[PATCH v2] sppps01: Add test case for early returns of pps_event()

2022-07-01 Thread Gabriel Moyano
---
 testsuites/sptests/sppps01/init.c | 49 +--
 1 file changed, 46 insertions(+), 3 deletions(-)

diff --git a/testsuites/sptests/sppps01/init.c 
b/testsuites/sptests/sppps01/init.c
index 996a3a1e16..7779f7d9e7 100644
--- a/testsuites/sptests/sppps01/init.c
+++ b/testsuites/sptests/sppps01/init.c
@@ -46,6 +46,7 @@ const char rtems_test_name[] = "SPPPS 1";
 struct test_pps_device {
   struct pps_state pps;
   rtems_id task_waiting;
+  int wokenup;
 };
 
 typedef struct {
@@ -59,9 +60,9 @@ T_TEST_CASE( WaitPPSEventDefaultHandler )
   struct test_pps_device pps_dev;
   struct pps_fetch_args fetch;
 
+  memset( _dev, 0, sizeof( pps_dev ) );
   pps_dev.task_waiting = RTEMS_INVALID_ID;
 
-  memset( _dev.pps, 0, sizeof( pps_dev.pps ) );
   pps_dev.pps.ppscap = PPS_CAPTUREBOTH;
   pps_init_abi( _dev.pps );
   pps_dev.pps.ppsparam.mode = PPS_CAPTUREASSERT;
@@ -76,6 +77,48 @@ T_TEST_CASE( WaitPPSEventDefaultHandler )
   T_eq_int( status, ETIMEDOUT );
 }
 
+static void fake_wakeup(struct pps_state *pps)
+{
+  struct test_pps_device *pps_dev;
+
+  pps_dev = RTEMS_CONTAINER_OF( pps, struct test_pps_device, pps );
+  pps_dev->wokenup++;
+}
+
+T_TEST_CASE( PPSEventEarlyReturns )
+{
+  struct test_pps_device pps_dev;
+
+  memset( _dev, 0, sizeof( pps_dev ) );
+  pps_dev.task_waiting = RTEMS_INVALID_ID;
+
+  pps_dev.pps.ppscap = PPS_CAPTUREBOTH;
+  pps_init_abi( _dev.pps );
+  pps_dev.pps.wakeup = fake_wakeup;
+  pps_dev.pps.ppsparam.mode = PPS_CAPTUREASSERT;
+
+  pps_capture( _dev.pps );
+  /* Trigger event with a different event than the one previously selected */
+  pps_event( _dev.pps, PPS_CAPTURECLEAR );
+  T_eq_int( pps_dev.wokenup, 0 );
+
+  pps_dev.pps.ppsparam.mode = PPS_CAPTURECLEAR;
+
+  /* Wait th_generation to be updated */
+  rtems_task_wake_after(1);
+  pps_event( _dev.pps, PPS_CAPTURECLEAR );
+  T_eq_int( pps_dev.wokenup, 0 );
+
+  /* Save current timecounter in pps_state object */
+  pps_capture( _dev.pps );
+  pps_event( _dev.pps, PPS_CAPTURECLEAR );
+  T_eq_int( pps_dev.wokenup, 0 );
+
+  pps_capture( _dev.pps );
+  pps_event( _dev.pps, PPS_CAPTURECLEAR );
+  T_eq_int( pps_dev.wokenup, 1 );
+}
+
 static void wakeup(struct pps_state *pps)
 {
   struct test_pps_device *pps_dev;
@@ -120,7 +163,7 @@ static void pps_task(rtems_task_argument arg)
   sc = rtems_event_send( ctx->main_task, PPS_EVENT_RECEIVED );
   T_rsc_success( sc );
 
-  rtems_task_delete(rtems_task_self());
+  rtems_task_exit();
 }
 
 T_TEST_CASE( WakeupTaskWithPPSEvent )
@@ -134,11 +177,11 @@ T_TEST_CASE( WakeupTaskWithPPSEvent )
   rtems_task_priority pps_task_prio = 1;
   rtems_event_set out;
 
+  memset( _dev, 0, sizeof( pps_dev ) );
   pps_dev.task_waiting = RTEMS_INVALID_ID;
   ctx.pps_dev = _dev;
   ctx.main_task = rtems_task_self();
 
-  memset( _dev.pps, 0, sizeof( pps_dev.pps ) );
   pps_dev.pps.ppscap = PPS_CAPTUREBOTH;
   pps_init_abi( _dev.pps );
   pps_dev.pps.wait = wait;
-- 
2.25.1

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


Re: [PATCH 00/12] Support gcov instrumentation

2022-07-01 Thread Chris Johns
On 1/7/2022 4:25 pm, Sebastian Huber wrote:
> On 01.07.22 08:22, Chris Johns wrote:
 I am encouraged by some of the generated code I have reviewed. I like what 
 it
 does.

>> I am a little lost with the difference between 
>> LIBRARY_OPTIMIZATION_FLAGS and
>> OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference 
>> between
>> them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can 
>> set
>> from an INI file?
> Currently the OPTIMIZATION_FLAGS are used for all code (code for 
> libraries and
> code for tests).  With this change you can build the libraries with -O0 
> and
> the
> tests with -O2 for example.
 Oh so if I understand this the LIBRARY_OPTIMIZATION_FLAGS are per library?
>>> Not per library, the LIBRARY_OPTIMIZATION_FLAGS are used for all libraries 
>>> in
>>> bsps and cpukit.
>> Is LIBRARY_OPTIMIZATION_FLAGS then a good choice? Would more direct naming 
>> like
>> BSP_OPTIMIZATION_FLAGS and CPUKIT_OPTIMIZATION_FLAGS be better? If this was 
>> in
>> the patch I would have understood exactly what they do.
> 
> The BSP is just a library: librtemsbsp.a. I can split 
> LIBRARY_OPTIMIZATION_FLAGS
> into BSP_OPTIMIZATION_FLAGS and CPUKIT_OPTIMIZATION_FLAGS if this helps.

I think it does.

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

Re: [PATCH 00/12] Support gcov instrumentation

2022-07-01 Thread Sebastian Huber



On 01.07.22 08:22, Chris Johns wrote:

I am encouraged by some of the generated code I have reviewed. I like what it
does.


I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and
OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between
them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can set
from an INI file?

Currently the OPTIMIZATION_FLAGS are used for all code (code for libraries and
code for tests).  With this change you can build the libraries with -O0 and the
tests with -O2 for example.

Oh so if I understand this the LIBRARY_OPTIMIZATION_FLAGS are per library?

Not per library, the LIBRARY_OPTIMIZATION_FLAGS are used for all libraries in
bsps and cpukit.

Is LIBRARY_OPTIMIZATION_FLAGS then a good choice? Would more direct naming like
BSP_OPTIMIZATION_FLAGS and CPUKIT_OPTIMIZATION_FLAGS be better? If this was in
the patch I would have understood exactly what they do.


The BSP is just a library: librtemsbsp.a. I can split 
LIBRARY_OPTIMIZATION_FLAGS into BSP_OPTIMIZATION_FLAGS and 
CPUKIT_OPTIMIZATION_FLAGS if this helps.


--
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 00/12] Support gcov instrumentation

2022-07-01 Thread Chris Johns
On 1/7/2022 4:03 pm, Sebastian Huber wrote:
> On 01.07.22 07:38, Chris Johns wrote:
 If this enable is specific to GCC's gcov then maybe we should clearly 
 label it
 as that and avoid overloading the term and any possible confusion that 
 might
 bring. For example RTEMS_GCOV_CONVERGE?
>>> It is not per se specific to GCC. Maybe we should name it
>>> RTEMS_COVERAGE_INSTRUMENTATION.
>> What if another approach to instrumented coverage is developed?
>>
>> Why the reluctance to RTEMS_GCOV_COVERAGE? I like it because it is direct.
> 
> Ok, I rename it to RTEMS_GCOV_COVERAGE.

Thanks.

> The user can fine tune the build through the
> LIBRARY_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and
> COVERAGE_COMPILER_FLAGS,
> COVERAGE_LINKER_FLAGS options.
 How would the LTO fat options be added? Would the pattern for
 COVERAGE_COMPILER_FLAGS flags be copied to add LTO_COMPILER_FLAGS?
>>> Do you have to specify the compiler flags also during linking if you use 
>>> LTO?
>> You add `-flto -ffat-lto-objects` to build the object files so they then 
>> contain
>> the data the lto pass in the linker needs to optimise across the object 
>> files.
> 
> The COVERAGE_LINKER_FLAGS are for the linking step. Are you required to pass 
> the
> compiler flags during linking if you use LTO?

Good question, I do not know. I think you can tall the linker to use LTO and to
not use LTO. I do not know what the default mode of the linker is when presented
with LTO enabled object files? The app I am building sets these flags in the
cflags and those are passed to the linker.

>> I am encouraged by some of the generated code I have reviewed. I like what it
>> does.
>>
 I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS 
 and
 OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between
 them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can 
 set
 from an INI file?
>>> Currently the OPTIMIZATION_FLAGS are used for all code (code for libraries 
>>> and
>>> code for tests).  With this change you can build the libraries with -O0 and 
>>> the
>>> tests with -O2 for example.
>> Oh so if I understand this the LIBRARY_OPTIMIZATION_FLAGS are per library?
> 
> Not per library, the LIBRARY_OPTIMIZATION_FLAGS are used for all libraries in
> bsps and cpukit.

Is LIBRARY_OPTIMIZATION_FLAGS then a good choice? Would more direct naming like
BSP_OPTIMIZATION_FLAGS and CPUKIT_OPTIMIZATION_FLAGS be better? If this was in
the patch I would have understood exactly what they do.

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

Re: [PATCH 08/12] gcov: Add functions to dump the gcov information

2022-07-01 Thread Chris Johns
On 1/7/2022 3:59 pm, Sebastian Huber wrote:
> On 01.07.22 07:48, Chris Johns wrote:
>> On 1/7/2022 3:00 pm, Sebastian Huber wrote:
>>> On 01.07.22 02:37, Chris Johns wrote:
> +void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg );
> +
 Why just a per char interface? Given this is in the score a buffer plus 
 length
 interface would make more sense? It would make the interface more 
 efficient.
>>>
>>> All the test output uses a single char output function. This is also used by
>>> _IO_Base64().
>>
>> That is a shame. Are you saying it is a lot of work to change?
> 
> I don't see a need for change. These are internal functions. They are not part
> of the API.

These types of patches load functionality into the score that is required to be
maintained and yet it is limited in scope in a small and simple way.

I see some of these things as powerful and a benefit to a wider part of the
community and it is exciting to see this happening. I am raising these questions
and probing what is being offered so we can understand the limitations and
possibly what might be needed.

 The per char could be a convenience function version of the buffer and 
 length
 call for those use cases than want it, ie 

> +static void _IO_Gcov_dump( const void *data, unsigned length, void *arg )
>>>
>>> If you really need this, you can call the libgcov functions directly.
>>
>> The title of this patch to the "score" says ...
>>
>>   "gcov: Add functions to dump the gcov information"
>>
>> If I have a large app and want to use this support am I restricted to a per
>> character interface rather than a buffer and length or I implement this again
>> directly? I am not sure I understand the purpose of this code in the score?
> 
> The purpose of the score functions are to provide an implementation for
> rtems_test_gcov_dump_info(). The RTEMS test suite simply requires a character
> output function.

Yes the testsuite is limited to a per char output path. I had missed the scoping
with `rtems_test_*`.

>> Is ESA going to use this gcov coverage for their applications?
> 
> They used gcov in the past with lots of local hacks.
> 
>>
>>> I can move the linker set definition to a separate file.
>>
>> I do not know how this relates.
> 
> If we move the RTEMS_LINKER_ROSET( gcov_info, const struct gcov_info * );
> definition to a separate file, you can use __gcov_info_to_gcda() in your
> application with a custom dump function.

If that provides a path we can work towards better support for applications then
I think that would be a good thing to do.

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

Re: [PATCH 00/12] Support gcov instrumentation

2022-07-01 Thread Sebastian Huber



On 01.07.22 07:38, Chris Johns wrote:

If this enable is specific to GCC's gcov then maybe we should clearly label it
as that and avoid overloading the term and any possible confusion that might
bring. For example RTEMS_GCOV_CONVERGE?

It is not per se specific to GCC. Maybe we should name it
RTEMS_COVERAGE_INSTRUMENTATION.

What if another approach to instrumented coverage is developed?

Why the reluctance to RTEMS_GCOV_COVERAGE? I like it because it is direct.


Ok, I rename it to RTEMS_GCOV_COVERAGE.




The user can fine tune the build through the
LIBRARY_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and
COVERAGE_COMPILER_FLAGS,
COVERAGE_LINKER_FLAGS options.

How would the LTO fat options be added? Would the pattern for
COVERAGE_COMPILER_FLAGS flags be copied to add LTO_COMPILER_FLAGS?

Do you have to specify the compiler flags also during linking if you use LTO?

You add `-flto -ffat-lto-objects` to build the object files so they then contain
the data the lto pass in the linker needs to optimise across the object files.


The COVERAGE_LINKER_FLAGS are for the linking step. Are you required to 
pass the compiler flags during linking if you use LTO?



I am encouraged by some of the generated code I have reviewed. I like what it 
does.


I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and
OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between
them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can set
from an INI file?

Currently the OPTIMIZATION_FLAGS are used for all code (code for libraries and
code for tests).  With this change you can build the libraries with -O0 and the
tests with -O2 for example.

Oh so if I understand this the LIBRARY_OPTIMIZATION_FLAGS are per library?


Not per library, the LIBRARY_OPTIMIZATION_FLAGS are used for all 
libraries in bsps and cpukit.


--
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] irq/arm-gicv3.h: Enable interrupt groups 0 and 1

2022-07-01 Thread Chris Johns
On 28/6/2022 1:14 pm, Kinsey Moore wrote:
> On 6/26/2022 22:37, Chris Johns wrote:
>> On 24/6/2022 7:43 pm, Sebastian Huber wrote:
>>> The GICv3 support is used by AArch32 (indicated by the ARM_MULTILIB_ARCH_V4
>>> define) and AArch64 targets.  Use the existing WRITE_SR() abstraction to 
>>> access
>>> the interrupt group 0 and 1 enable registers.  This fixes the build for the
>>> AArch32 target.
>> It needs to be tested on hardware before I am OK with it. It also needs EL3
>> firmware, ie TF-A, to correctly initialise a system.
>>
>> I would be OK with qemu if it can be shown it honours the security level
>> correctly. I however have no time to determine this as I have Versal hardware
>> that did not like the changes.
> I, unfortunately, have no way to test this on hardware but I would agree. I
> would not be inclined to trust qemu in this regard.
>>> ---
>>>   bsps/include/dev/irq/arm-gicv3.h | 23 ++-
>>>   1 file changed, 6 insertions(+), 17 deletions(-)
>>>
>>> diff --git a/bsps/include/dev/irq/arm-gicv3.h 
>>> b/bsps/include/dev/irq/arm-gicv3.h
>>> index a79368ebdf..7db7bad034 100644
>>> --- a/bsps/include/dev/irq/arm-gicv3.h
>>> +++ b/bsps/include/dev/irq/arm-gicv3.h
>>> @@ -116,9 +116,11 @@ extern "C" {
>>>   #else /* ARM_MULTILIB_ARCH_V4 */
>>>     /* AArch64 GICv3 registers are not named in GCC */
>> The FreeBSD would suggest this is not entirely true? May be it is for 
>> aarch32?
> IIRC, a select few were named and usable in GCC, but the vast majority were 
> not.
> This may have gotten better with more recent GCC releases since this comment 
> was
> written more than 2 years ago.
>>
>>> -#define ICC_IGRPEN0 "S3_0_C12_C12_6, %0"
>>> -#define ICC_IGRPEN1 "S3_0_C12_C12_7, %0"
>>> +#define ICC_IGRPEN0_EL1 "S3_0_C12_C12_6, %0"
>>> +#define ICC_IGRPEN1_EL1 "S3_0_C12_C12_7, %0"
>> This looks like it is only a label change and so it is the same opcode. Is 
>> that
>> correct?
> According to the ARMv8 TRM, this is the full proper name for it.
>>
>>>   #define ICC_IGRPEN1_EL3 "S3_6_C12_C12_7, %0"
>>> +#define ICC_IGRPEN0 ICC_IGRPEN0_EL1
>>> +#define ICC_IGRPEN1 ICC_IGRPEN1_EL1
>>>   #define ICC_PMR "S3_0_C4_C6_0, %0"
>>>   #define ICC_EOIR1   "S3_0_C12_C12_1, %0"
>>>   #define ICC_SRE "S3_0_C12_C12_5, %0"
>>> @@ -300,20 +302,6 @@ static void gicv3_init_dist(volatile gic_dist *dist)
>>>     }
>>>   }
>>>   -/*
>>> - * A better way to access these registers than special opcodes
>>> - */
>>> -#define isb() __asm __volatile("isb" : : : "memory")
>>> -
>>> -#define  WRITE_SPECIALREG(reg, _val)    \
>>> -  __asm __volatile("msr  " __STRING(reg) ", %0" : : "r"((uint64_t)_val))
>>> -
>>> -#define  gic_icc_write(reg, val)    \
>>> -do {    \
>>> -  WRITE_SPECIALREG(icc_ ##reg ##_el1, val); \
>>> -  isb();    \
>>> -} while (0)
>>> -
>>>   static void gicv3_init_cpu_interface(uint32_t cpu_index)
>>>   {
>>>     uint32_t sre_value = 0x7;
>>> @@ -335,7 +323,8 @@ static void gicv3_init_cpu_interface(uint32_t cpu_index)
>>>     }
>>>       /* Enable interrupt groups 0 and 1 */
>>> -  gic_icc_write(IGRPEN1, 1);'
>> This has been tested and works on a Versal.
>>
>>> +  WRITE_SR(ICC_IGRPEN0, 0x1);
>> This crashed in EL1 on a Versal with 2021.2 TF-A.
>>
>> Why do you need to set this here?
>>
>>> +  WRITE_SR(ICC_IGRPEN1, 0x1);
>> This instruction also generated an exception. It has been a while but I am
>> pretty sure I had to comment this one and when I did no interrupts happened. 
>> The
>> code I ported from FreeBSD worked.
>>
>> I also think the FreeBSD calls are easier to review and so maintain. I find
>> those ARM type registers difficult to find and check.
> The opcode S3_0_C12_C12_7 should be identical in behavior and assembly with 
> the
> name ICC_IGRPEN1_EL1. It's spelled out in the ARMv8 TRM on D12-3006.

I will take a look once the hardware becomes available to me.

I could be mistaken with that piece of the change but I seem to remember both
enable writes causing an issue and no writes resulting in no interrupts.

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

Re: [PATCH 08/12] gcov: Add functions to dump the gcov information

2022-06-30 Thread Sebastian Huber

On 01.07.22 07:48, Chris Johns wrote:

On 1/7/2022 3:00 pm, Sebastian Huber wrote:

On 01.07.22 02:37, Chris Johns wrote:

+void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg );
+

Why just a per char interface? Given this is in the score a buffer plus length
interface would make more sense? It would make the interface more efficient.


All the test output uses a single char output function. This is also used by
_IO_Base64().


That is a shame. Are you saying it is a lot of work to change?


I don't see a need for change. These are internal functions. They are 
not part of the API.





The per char could be a convenience function version of the buffer and length
call for those use cases than want it, ie 


+static void _IO_Gcov_dump( const void *data, unsigned length, void *arg )


If you really need this, you can call the libgcov functions directly.


The title of this patch to the "score" says ...

  "gcov: Add functions to dump the gcov information"

If I have a large app and want to use this support am I restricted to a per
character interface rather than a buffer and length or I implement this again
directly? I am not sure I understand the purpose of this code in the score?


The purpose of the score functions are to provide an implementation for 
rtems_test_gcov_dump_info(). The RTEMS test suite simply requires a 
character output function.




Is ESA going to use this gcov coverage for their applications?


They used gcov in the past with lots of local hacks.




I can move the linker set definition to a separate file.


I do not know how this relates.


If we move the RTEMS_LINKER_ROSET( gcov_info, const struct gcov_info * 
); definition to a separate file, you can use __gcov_info_to_gcda() in 
your application with a custom dump function.


--
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 08/12] gcov: Add functions to dump the gcov information

2022-06-30 Thread Chris Johns
On 1/7/2022 3:00 pm, Sebastian Huber wrote:
> On 01.07.22 02:37, Chris Johns wrote:
>>> +void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg );
>>> +
>> Why just a per char interface? Given this is in the score a buffer plus 
>> length
>> interface would make more sense? It would make the interface more efficient.
> 
> All the test output uses a single char output function. This is also used by
> _IO_Base64().

That is a shame. Are you saying it is a lot of work to change?

>> The per char could be a convenience function version of the buffer and length
>> call for those use cases than want it, ie 
>>
>>> +static void _IO_Gcov_dump( const void *data, unsigned length, void *arg )
> 
> If you really need this, you can call the libgcov functions directly. 

The title of this patch to the "score" says ...

 "gcov: Add functions to dump the gcov information"

If I have a large app and want to use this support am I restricted to a per
character interface rather than a buffer and length or I implement this again
directly? I am not sure I understand the purpose of this code in the score?

Is ESA going to use this gcov coverage for their applications?

> I can move the linker set definition to a separate file.

I do not know how this relates.

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


Re: [PATCH 00/12] Support gcov instrumentation

2022-06-30 Thread Chris Johns
On 1/7/2022 3:07 pm, Sebastian Huber wrote:
> On 01.07.22 03:19, Chris Johns wrote:
>> On 29/6/2022 4:30 pm, Sebastian Huber wrote:
>>> This patch set adds support to build the RTEMS libraries with gcov
>>> instrumentation to get code and branch coverage.  There are some 
>>> improvements
>>> necessary in the build system to support different compiler flags for 
>>> libraries
>>> and tests.  In general, code coverage is enabled by the new RTEMS_COVERAGE
>>> build configuration option.
>>
>> Does RTEMS_COVERAGE effect covoar and the coverage testing that tool and flow
>> provides?
> 
> The covoar uses uninstrumented code, so these two approaches are orthogonal. 
> You
> could even use both approaches at the same time. This makes little sense, but
> you could do it.

Agreed, it does not make sense. Someone new to RTEMS would not know what this
all means and may think they need to enable the option for any type of coverage.

>> If this enable is specific to GCC's gcov then maybe we should clearly label 
>> it
>> as that and avoid overloading the term and any possible confusion that might
>> bring. For example RTEMS_GCOV_CONVERGE?
> 
> It is not per se specific to GCC. Maybe we should name it
> RTEMS_COVERAGE_INSTRUMENTATION.

What if another approach to instrumented coverage is developed?

Why the reluctance to RTEMS_GCOV_COVERAGE? I like it because it is direct.

>>> The user can fine tune the build through the
>>> LIBRARY_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and
>>> COVERAGE_COMPILER_FLAGS,
>>> COVERAGE_LINKER_FLAGS options.
>>
>> How would the LTO fat options be added? Would the pattern for
>> COVERAGE_COMPILER_FLAGS flags be copied to add LTO_COMPILER_FLAGS?
> 
> Do you have to specify the compiler flags also during linking if you use LTO?

You add `-flto -ffat-lto-objects` to build the object files so they then contain
the data the lto pass in the linker needs to optimise across the object files.

I am encouraged by some of the generated code I have reviewed. I like what it 
does.

>> I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and
>> OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between
>> them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can set
>> from an INI file?
> 
> Currently the OPTIMIZATION_FLAGS are used for all code (code for libraries and
> code for tests).  With this change you can build the libraries with -O0 and 
> the
> tests with -O2 for example.

Oh so if I understand this the LIBRARY_OPTIMIZATION_FLAGS are per library?

>> I think the changes to cppflags, cflags and cxxflags are nice and a great
>> progression.
>>
>>>   The gcov information is dumped after each test
>>> case in a base64 encoded gcfn and gcda data stream.  It looks like this:
>>>
>>> *** BEGIN OF GCOV INFO BASE64 ***
>>> bmZjZyAxMkJSL3RtcC9zaC9iLXJ0ZW1zL2FybS94aWxpbnhfenlucV9hOV9xZW11L2NwdWtp
>>> dC9saWJjc3VwcG9ydC9zcmMvX19nZXR0b2QuYy42NS5nY2RhAGFkY2cgMTJCPoT6qo6mcBUB
>>> DOOrF1pxp0aIPrK7wAAAoQHwAQwAAADTfDdNQYCYwJ9ZRL0AAKEBIAQA
>>> ...
>>> srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAAoQH4AQwAAACYh8U9/rgJ5hMc
>>> ig8AAKEB2P///wEMN3+9YAwMW8gTHIoPAAChAdj///8BDDAwMx4TuamFPrK7
>>> wAAAoQHwAQwAAACvassJzDNWd/lKs3wAAKEB8P///wA=
>>> *** END OF GCOV INFO BASE64 ***
>>>
>>> On the host you can decode the block and pipe it through the gcov-tool to
>>> produce the *.gcda files.  Example Python code:
>>>
>>> block = some regex stuff to get the block between the BEGIN/END OF ...
>>> stream = base64.b64decode(block)
>>> subprocess.run(["arm-rtems6-gcov-tool", "merge-stream"], input=stream)
>>
>> Nice. Could  rtems-test detect this and then run that command if available?
> 
> Yes, this could be an option. Another is to produce a JSON report and then 
> run a
> second script.

Sure.

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

Re: [PATCH 00/12] Support gcov instrumentation

2022-06-30 Thread Sebastian Huber



On 01.07.22 03:19, Chris Johns wrote:

On 29/6/2022 4:30 pm, Sebastian Huber wrote:

This patch set adds support to build the RTEMS libraries with gcov
instrumentation to get code and branch coverage.  There are some improvements
necessary in the build system to support different compiler flags for libraries
and tests.  In general, code coverage is enabled by the new RTEMS_COVERAGE
build configuration option.


Does RTEMS_COVERAGE effect covoar and the coverage testing that tool and flow
provides?


The covoar uses uninstrumented code, so these two approaches are 
orthogonal. You could even use both approaches at the same time. This 
makes little sense, but you could do it.




If this enable is specific to GCC's gcov then maybe we should clearly label it
as that and avoid overloading the term and any possible confusion that might
bring. For example RTEMS_GCOV_CONVERGE?


It is not per se specific to GCC. Maybe we should name it 
RTEMS_COVERAGE_INSTRUMENTATION.





The user can fine tune the build through the
LIBRARY_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and 
COVERAGE_COMPILER_FLAGS,
COVERAGE_LINKER_FLAGS options.


How would the LTO fat options be added? Would the pattern for
COVERAGE_COMPILER_FLAGS flags be copied to add LTO_COMPILER_FLAGS?


Do you have to specify the compiler flags also during linking if you use 
LTO?




I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and
OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between
them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can set
from an INI file?


Currently the OPTIMIZATION_FLAGS are used for all code (code for 
libraries and code for tests).  With this change you can build the 
libraries with -O0 and the tests with -O2 for example.




I think the changes to cppflags, cflags and cxxflags are nice and a great
progression.


  The gcov information is dumped after each test
case in a base64 encoded gcfn and gcda data stream.  It looks like this:

*** BEGIN OF GCOV INFO BASE64 ***
bmZjZyAxMkJSL3RtcC9zaC9iLXJ0ZW1zL2FybS94aWxpbnhfenlucV9hOV9xZW11L2NwdWtp
dC9saWJjc3VwcG9ydC9zcmMvX19nZXR0b2QuYy42NS5nY2RhAGFkY2cgMTJCPoT6qo6mcBUB
DOOrF1pxp0aIPrK7wAAAoQHwAQwAAADTfDdNQYCYwJ9ZRL0AAKEBIAQA
...
srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAAoQH4AQwAAACYh8U9/rgJ5hMc
ig8AAKEB2P///wEMN3+9YAwMW8gTHIoPAAChAdj///8BDDAwMx4TuamFPrK7
wAAAoQHwAQwAAACvassJzDNWd/lKs3wAAKEB8P///wA=
*** END OF GCOV INFO BASE64 ***

On the host you can decode the block and pipe it through the gcov-tool to
produce the *.gcda files.  Example Python code:

block = some regex stuff to get the block between the BEGIN/END OF ...
stream = base64.b64decode(block)
subprocess.run(["arm-rtems6-gcov-tool", "merge-stream"], input=stream)


Nice. Could  rtems-test detect this and then run that command if available?


Yes, this could be an option. Another is to produce a JSON report and 
then run a second script.


--
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 08/12] gcov: Add functions to dump the gcov information

2022-06-30 Thread Sebastian Huber

On 01.07.22 02:37, Chris Johns wrote:

+void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg );
+

Why just a per char interface? Given this is in the score a buffer plus length
interface would make more sense? It would make the interface more efficient.


All the test output uses a single char output function. This is also 
used by _IO_Base64().




The per char could be a convenience function version of the buffer and length
call for those use cases than want it, ie 


+static void _IO_Gcov_dump( const void *data, unsigned length, void *arg )


If you really need this, you can call the libgcov functions directly. I 
can move the linker set definition to a separate file.


--
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 04/12] build: Improve value substitution

2022-06-30 Thread Sebastian Huber



On 01.07.22 02:18, Chris Johns wrote:

On 29/6/2022 4:30 pm, Sebastian Huber wrote:

The waf build system uses lists for tool flags.  The build items may use
variable substitution.  Add the ability to use the variable substitution in
lists.  For example:

MORE_FLAGS = ['-more', '-flags']

flags:
- -some-flag
- ${MORE_FLAGS}

Before this change, the ${MORE_FLAGS} was substituted to "-more -flags".  This
would be passed by waf as a single command line argument to the tool.

After this change, the ${MORE_FLAGS} list extends the flags list:

flags = ['-some-flag', '-more', '-flags']

This list extension is performed if a list element consists of exactly one
variable.


Is nesting supported?


You mean lists of lists? Yes, this would work, but we don't have lists 
of lists in the build system.


The variable substitution in general is not recursive 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 00/12] Support gcov instrumentation

2022-06-30 Thread Chris Johns
On 29/6/2022 4:30 pm, Sebastian Huber wrote:
> This patch set adds support to build the RTEMS libraries with gcov
> instrumentation to get code and branch coverage.  There are some improvements
> necessary in the build system to support different compiler flags for 
> libraries
> and tests.  In general, code coverage is enabled by the new RTEMS_COVERAGE
> build configuration option.

Does RTEMS_COVERAGE effect covoar and the coverage testing that tool and flow
provides?

If this enable is specific to GCC's gcov then maybe we should clearly label it
as that and avoid overloading the term and any possible confusion that might
bring. For example RTEMS_GCOV_CONVERGE?

> The user can fine tune the build through the
> LIBRARY_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and 
> COVERAGE_COMPILER_FLAGS,
> COVERAGE_LINKER_FLAGS options.

How would the LTO fat options be added? Would the pattern for
COVERAGE_COMPILER_FLAGS flags be copied to add LTO_COMPILER_FLAGS?

I am a little lost with the difference between LIBRARY_OPTIMIZATION_FLAGS and
OPTIMIZATION_FLAGS? RTEMS is always a library so what is difference between
them? Are the OPTIMIZATION_FLAGS the "-O" ones and still something I can set
from an INI file?

I think the changes to cppflags, cflags and cxxflags are nice and a great
progression.

>  The gcov information is dumped after each test
> case in a base64 encoded gcfn and gcda data stream.  It looks like this:
> 
> *** BEGIN OF GCOV INFO BASE64 ***
> bmZjZyAxMkJSL3RtcC9zaC9iLXJ0ZW1zL2FybS94aWxpbnhfenlucV9hOV9xZW11L2NwdWtp
> dC9saWJjc3VwcG9ydC9zcmMvX19nZXR0b2QuYy42NS5nY2RhAGFkY2cgMTJCPoT6qo6mcBUB
> DOOrF1pxp0aIPrK7wAAAoQHwAQwAAADTfDdNQYCYwJ9ZRL0AAKEBIAQA
> ...
> srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAAoQH4AQwAAACYh8U9/rgJ5hMc
> ig8AAKEB2P///wEMN3+9YAwMW8gTHIoPAAChAdj///8BDDAwMx4TuamFPrK7
> wAAAoQHwAQwAAACvassJzDNWd/lKs3wAAKEB8P///wA=
> *** END OF GCOV INFO BASE64 ***
> 
> On the host you can decode the block and pipe it through the gcov-tool to
> produce the *.gcda files.  Example Python code:
> 
> block = some regex stuff to get the block between the BEGIN/END OF ...
> stream = base64.b64decode(block)
> subprocess.run(["arm-rtems6-gcov-tool", "merge-stream"], input=stream)

Nice. Could  rtems-test detect this and then run that command if available?

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


Re: [PATCH 08/12] gcov: Add functions to dump the gcov information

2022-06-30 Thread Chris Johns
On 29/6/2022 4:30 pm, Sebastian Huber wrote:
> Update #4670.
> ---
>  cpukit/include/rtems/score/io.h |   4 +
>  cpukit/include/rtems/test-info.h|   6 ++
>  cpukit/libtest/testgcovdumpinfo.c   |  66 ++
>  cpukit/score/src/iogcovdumpinfo.c   | 101 +
>  cpukit/score/src/iogcovdumpinfobase64.c | 111 
>  spec/build/cpukit/librtemscpu.yml   |   2 +
>  spec/build/cpukit/librtemstest.yml  |   1 +
>  testsuites/validation/tc-terminate.c|   3 +-
>  8 files changed, 293 insertions(+), 1 deletion(-)
>  create mode 100644 cpukit/libtest/testgcovdumpinfo.c
>  create mode 100644 cpukit/score/src/iogcovdumpinfo.c
>  create mode 100644 cpukit/score/src/iogcovdumpinfobase64.c
> 
> diff --git a/cpukit/include/rtems/score/io.h b/cpukit/include/rtems/score/io.h
> index 106418f185..097cb9bdfe 100644
> --- a/cpukit/include/rtems/score/io.h
> +++ b/cpukit/include/rtems/score/io.h
> @@ -141,6 +141,10 @@ int _IO_Base64url(
>   */
>  void _IO_Relax( void );
>  
> +void _IO_Gcov_dump_info( IO_Put_char put_char, void *arg );
> +
> +void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg );
> +

Why just a per char interface? Given this is in the score a buffer plus length
interface would make more sense? It would make the interface more efficient.

The per char could be a convenience function version of the buffer and length
call for those use cases than want it, ie 

> +static void _IO_Gcov_dump( const void *data, unsigned length, void *arg )
> +{
> +  IO_Gcov_context *ctx;
> +  IO_Put_char  put_char;
> +  void*ctx_arg;
> +  const char  *in;
> +  const void  *end;
> +
> +  ctx = arg;
> +  in = data;
> +  end = in + length;
> +  put_char = ctx->put_char;
> +  ctx_arg = ctx->arg;
> +
> +  while ( in != end ) {
> +( *put_char )( *in, ctx_arg );
> +++in;
> +  }
> +}

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


Re: [PATCH 04/12] build: Improve value substitution

2022-06-30 Thread Chris Johns
On 29/6/2022 4:30 pm, Sebastian Huber wrote:
> The waf build system uses lists for tool flags.  The build items may use
> variable substitution.  Add the ability to use the variable substitution in
> lists.  For example:
> 
> MORE_FLAGS = ['-more', '-flags']
> 
> flags:
> - -some-flag
> - ${MORE_FLAGS}
> 
> Before this change, the ${MORE_FLAGS} was substituted to "-more -flags".  This
> would be passed by waf as a single command line argument to the tool.
> 
> After this change, the ${MORE_FLAGS} list extends the flags list:
> 
> flags = ['-some-flag', '-more', '-flags']
> 
> This list extension is performed if a list element consists of exactly one
> variable.

Is nesting supported?

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


Re: [PATCH] bsps/xilinx-zynq: Init debug console only once

2022-06-30 Thread Chris Johns
OK and thanks

Chris

On 29/6/2022 12:19 am, Sebastian Huber wrote:
> Initialize the debug console only once during early system initialization.
> ---
>  bsps/arm/xilinx-zynq/console/debug-console.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/bsps/arm/xilinx-zynq/console/debug-console.c 
> b/bsps/arm/xilinx-zynq/console/debug-console.c
> index 0e9b756f30..1423708bb7 100644
> --- a/bsps/arm/xilinx-zynq/console/debug-console.c
> +++ b/bsps/arm/xilinx-zynq/console/debug-console.c
> @@ -52,10 +52,7 @@ static void zynq_debug_console_init(void)
>  
>  static void zynq_debug_console_early_init(char c)
>  {
> -  rtems_termios_device_context *base =
> -_uart_instances[BSP_CONSOLE_MINOR].base;
> -
> -  zynq_uart_initialize(base);
> +  zynq_debug_console_init();
>zynq_debug_console_out(c);
>  }
>  
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel


Re: Congratulations to Two Core Developers

2022-06-30 Thread Chris Johns
Gedare and Hesham ... congratulations, this is fantastic news.

I know there has been a lot of work in these achievements and they are well
deserved.

Chris

On 29/6/2022 12:23 am, Joel Sherrill wrote:
> Hi
> 
> I'd like to congratulate two RTEMS core developers on recent significant
> achievements.
> 
> (1) Gedare Bloomwas granted tenure at the University of Colorado at Colorado
> Springs.
> 
> (2) Hesham Almatary has passed his Ph.D. viva/orals and is nearing graduation.
> 
> These are both major life events and the RTEMS Community would like to
> congratulate them.
> 
> --joel
> 
> ___
> 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: Integrating the Formal Methods part of Qualification

2022-06-30 Thread Chris Johns
On 28/6/2022 11:09 pm, andrew.butterfi...@scss.tcd.ie wrote:
> Dear RTEMS Developers,
> 
> While the validation tests from the RTEMS pre-qualification activity are
> now merged into the RTEMS master, the work done in investigating and 
> deploying formal methods techniques is not yet merged.
> 
> The activity had two main phases: a planning phase (Nov 2018-Oct 2019) 
> that explored various formal techniques, followed by an execution phase 
> (Oct 2019-Nov 2021) that then applied selected techniques to selected 
> parts of RTEMS. Some discussions occurred with the RTEMS community 
> via the mailings lists over this time. A short third phase (Nov 2021 - Dec 
> 2021) 
> then reported on the outcomes. Each phase resulted in a technical report.
> 
> The key decision made was to use Promela/SPIN for test generation, and 
> to apply it to the Chains API, the Event Manager, and the SMP scheduler
> thread queues. This involved developing models in the Promela language 
> and using the SPIN model-checker tool to both check their correctness
> and to generate execution scenarios that could be used to generate tests.
> Tools were developed using Python 3.8 to support this. Initial documentation 
> about tools and how to use them was put into the 2nd phase report.

Congratulations for the work and results you and others have managed to achieve.
It is exciting to see this happening with RTEMS and being made public.

> We now come to the part where we explore the best way to integrate this
> into RTEMS. I am proposing to do this under the guidance of Sebastian Huber.
> 
> The first suggested step is adding in new documentation to the RTEMS 
> Software Engineering manual, as a new Formal Methods chapter. This would 
> provide some motivation, as well as a "howto".
> 
> I assume that I would initially describe the proposed changes using the patch 
> review process described in the section on Preparing and Sending Patches in 
> the User Manual.
> 
> How do you feel I should best proceed?

It is hard for me to answer until I understand what is being submitted and who
maintains it? I am sure you understand this due to the specialised nature of the
work.

What will be submitted, ie SPIN files, scripts, etc?

Where are you looking to add these pieces?

How is the verification run against the code? Do we manage regression testing
and is that even possible?

I hope my simple questions highlight a lack of understand on how this works and
how we maintain it and use it once integrated.

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


Re: [PATCH] arm/gicv3: Fix building arm/r52

2022-06-30 Thread Chris Johns
On 30/6/2022 1:42 am, Sebastian Huber wrote:
> On 27/06/2022 08:27, Sebastian Huber wrote:
>> On 27/06/2022 05:02, Chris Johns wrote:
>>> On 24/6/2022 7:44 pm, Sebastian Huber wrote:
 On 20.06.22 04:03, chr...@rtems.org wrote:
> From: Chris Johns 
>
> ---
>    bsps/include/dev/irq/arm-gicv3.h | 5 +
>    1 file changed, 5 insertions(+)
>
> diff --git a/bsps/include/dev/irq/arm-gicv3.h
> b/bsps/include/dev/irq/arm-gicv3.h
> index a79368ebdf..aac02fa191 100644
> --- a/bsps/include/dev/irq/arm-gicv3.h
> +++ b/bsps/include/dev/irq/arm-gicv3.h
> @@ -335,7 +335,12 @@ static void gicv3_init_cpu_interface(uint32_t 
> cpu_index)
>  }
>        /* Enable interrupt groups 0 and 1 */
> +#ifdef ARM_MULTILIB_ARCH_V4
> +  WRITE_SR(ICC_IGRPEN0, 0x1);
> +  WRITE_SR(ICC_IGRPEN1, 0x1);
> +#else
>  gic_icc_write(IGRPEN1, 1);
> +#endif
>  WRITE_SR(ICC_CTLR, 0x0);
>    }

 I have a different patch to fix this:

 https://lists.rtems.org/pipermail/devel/2022-June/072056.html
>>>
>>> Does this change work on a real aarch64 with a suitably configured TF-A? The
>>> security profile of the TF-A needs to disable EL1 access to these registers 
>>> to
>>> see the issue.
>>
>> I don't have a hardware to test this change. I can do tests on a Cortex-R52
>> hardware.
>>
>> For the Cortex-R52, group 0 interrupts are signaled through FIQ exceptions 
>> and
>> group 1 interrupts are signaled through IRQ exceptions. This processor has no
>> secore/non-secure states.
> 
> I checked the GICv3 manual. The group 0 interrupts are always Secure if the
> system has at least two Security states. So, if RTEMS runs in Non-Secure mode,
> it cannot modify group 0 interrupts. 

Thanks, this was my understanding once the exceptions made me take a look.

> We have some things to consider:
> 
> 1. Count of system security states

I think there are registers available that detail this but I have not checked in
detail what can be read and when. I prefer we avoid any runtime management.

> 2. In which state RTEMS runs

We have to be able to run non-secure in EL1. The FPD scalar cores (A72) on the
Versal require this.

I take that requirement as saying we should keep away from anything that relates
to secure operations even for those cores that allow open access. FreeBSD and
Linux do not touch these registers and I think that is a wise path to follow.

> 3. What RTEMS needs to initialize

We have to assume this is handled by the code that is responsible for
establishing the secure state. For those cores that do not have or require a
vertical software stack it may be OK for the BSP may hold that configuration.

> We cannot simply use the target architecture to determine what to do during 
> GIC
> initialization.

Does the GiC need to handle this?

> I think we need some BSP options to control the initialization behaviour.

I am not sure this should be the responsibility of the BSP and RTEMS. I see it
as something the boot loaders and boot process should manage. For the ZynqMP and
Versal this and much much more is covered by TF-A. I recommend using TF-A for
the Versal simply because of support ARM provides in it ...

INFO:GICv3 with legacy support detected.

INFO:ARM GICv3 driver initialized in EL3

INFO:BL31: Initializing runtime services
WARNING: BL31: cortex_a72: CPU workaround for 859971 was missing!
WARNING: BL31: cortex_a72: CPU workaround for 1319367 was missing!
INFO:BL31: cortex_a72: CPU workaround for cve_2017_5715 was applied
INFO:BL31: cortex_a72: CPU workaround for cve_2018_3639 was applied


I prefer we do not attempt to get involved and complicate what this code is 
doing.

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

Re: [tools] tester: Normalize JSON and YAML reports

2022-06-30 Thread Chris Johns
On 30/6/2022 4:34 pm, Sebastian Huber wrote:
> On 30/06/2022 07:58, Sebastian Huber wrote:
>> On 29/06/2022 17:54, Kinsey Moore wrote:
>>> On 6/29/2022 04:34, Sebastian Huber wrote:
 On 29/06/2022 11:20, Chris Johns wrote:
>
>> On 29 Jun 2022, at 4:42 pm, Sebastian Huber
>>  wrote:
>>
>> On 29/06/2022 08:40, Sebastian Huber wrote:
>>> Report the same data in JSON and YAML reports.  Do not report redundant
>>> information.
>>> Update 4671.
>>
>> This patch changes the JSON reports. Are there already consumers for the
>> JSON reports so that we have to be backward compatible?
>
> Could compatibility be added back in if this proves to be an issue?
>
> I am wondering if that could be considered if comparability becomes an 
> issue.

 The JSON report was added by:

 commit 5fcaf843bdb491e2da14dc1af61806ac6d20bae5
 Author: Kinsey Moore 
 Date:   Wed Aug 21 16:34:12 2019 +

     Add JSON log generation

     Add log formatter hooks and JSON log formatter to the test 
 infrastructure
     for consumption by automated processes or report generators.


 I am not sure if these automated processes or report generators already 
 exist.

 The existing attribute names are quite inconsistent, for example "Command
 Line", "passed_count", "wrong-version_count". I would use lower case only
 with "-" as a separator. The JSON report should contain all information of 
 a
 test run.

 The new report looks like this:

 {
     "command-line": [
     "/opt/rtems/6/bin/rtems-test",
     "--rtems-bsp=xilinx_zynq_a9_qemu",
     "--report-format=json",
     "--report-path=report",
     "build/arm/xilinx_zynq_a9_qemu/testsuites/samples/"
     ],
     "end-time": "2022-06-28T14:08:47.595131",
     "host": "Linux-5.3.18-150300.59.76-default-x86_64-with-glibc2.3.4 
 (Linux
 lupus 5.3.18-150300.59.76-default #1 SMP Thu Jun 16 04:23:47 UTC 2022
 (2cc2ade) x86_64 x86_64)",
     "python": "3.6.15 (default, Sep 23 2021, 15:41:43) [GCC]",
     "reports": [
     {
     "arch": "arm",
     "bsp": "xilinx_zynq_a9_qemu",
     "command-line": "qemu-system-arm -no-reboot -nographic -net 
 none
 -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 256M -kernel
 build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
     "end-time": "2022-06-28T12:08:48.161691+00:00",
     "executable":
 "build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
     "executable-sha512":
 "413bc8a506053c95a0e1d93942cce9fd0d653f7b3cde42623085ce147aea324f4baeff7ce0102008322fb1341bc2b38defd3925a64144e47e13cc5f32185bf78",

     "output": [
     "qemu-system-arm: warning: nic cadence_gem.0 has no peer",
     "qemu-system-arm: warning: nic cadence_gem.1 has no peer",
     "",
     "",
     "*** BEGIN OF TEST CONSTRUCTOR/DESTRUCTOR ***",
     "*** TEST VERSION:
 6.0.0.3302b72754df5f37214e86dd68522189857772c7",
     "*** TEST STATE: EXPECTED_PASS",
     "*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API",
     "*** TEST TOOLS: 12.1.1 20220622 (RTEMS 6, RSB
 bf3f66c29a046ec1c5029e4f919b525947df6245, Newlib e7ffbdb)",
     "GLOBAL: Hey I'm in base class constructor number 1 for
 0x214474.",
     "GLOBAL: Hey I'm in base class constructor number 2 for
 0x214480.",
     "GLOBAL: Hey I'm in derived class constructor number 3 for
 0x214480.",
     "LOCAL: Hey I'm in base class constructor number 4 for
 0x228864.",
     ...


 "WRoZqtoO3A8BDJkUSmRGNOBaaHW1UwAAoQGQAQwAAABck8Bx+K/znDWWTEcA",

 "AKEB2P///wEMVP6TRqQZY+4+srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAA",

 "oQH4AQwAAADJyx1ZCnZ4l+m/XkMAAKEB0P///wEMN3+9YAwMW8gTHIoPAACh",

 "Adj///8BDBtxsj3zXZF/+UqzfAAAoQHwAQwwMDMeE7mphT6yu8AAAKEB",
 "8P///wEMr2rLCcwzVnf5SrN8AAChAfD///8A",
     "*** END OF GCOV INFO BASE64 ***",
     ""
     ],
     "result": "passed",
     "start-time": "2022-06-28T12:08:47.721822+00:00"
     }
     ],
     "start-time": "2022-06-28T14:08:47.595131"
 }

>>> There are no publicly available report generators for the existing format,
>>> but I do have one I use to generate STR documents for delivery using 
>>> mustache
>>> templates and further processing. The existing format was designed to be
>>> easily consumable by that and other simple templating mechanisms by 
>>> providing
>>> structure (test subsets) and 

Re: [tools] tester: Normalize JSON and YAML reports

2022-06-30 Thread Kinsey Moore

On 6/30/2022 01:34, Sebastian Huber wrote:



On 30/06/2022 07:58, Sebastian Huber wrote:

On 29/06/2022 17:54, Kinsey Moore wrote:

On 6/29/2022 04:34, Sebastian Huber wrote:

On 29/06/2022 11:20, Chris Johns wrote:


On 29 Jun 2022, at 4:42 pm, Sebastian Huber 
 wrote:


On 29/06/2022 08:40, Sebastian Huber wrote:
Report the same data in JSON and YAML reports.  Do not report 
redundant

information.
Update 4671.


This patch changes the JSON reports. Are there already consumers 
for the JSON reports so that we have to be backward compatible?


Could compatibility be added back in if this proves to be an issue?

I am wondering if that could be considered if comparability 
becomes an issue.


The JSON report was added by:

commit 5fcaf843bdb491e2da14dc1af61806ac6d20bae5
Author: Kinsey Moore 
Date:   Wed Aug 21 16:34:12 2019 +

    Add JSON log generation

    Add log formatter hooks and JSON log formatter to the test 
infrastructure

    for consumption by automated processes or report generators.


I am not sure if these automated processes or report generators 
already exist.


The existing attribute names are quite inconsistent, for example 
"Command Line", "passed_count", "wrong-version_count". I would use 
lower case only with "-" as a separator. The JSON report should 
contain all information of a test run.


The new report looks like this:

{
    "command-line": [
    "/opt/rtems/6/bin/rtems-test",
    "--rtems-bsp=xilinx_zynq_a9_qemu",
    "--report-format=json",
    "--report-path=report",
    "build/arm/xilinx_zynq_a9_qemu/testsuites/samples/"
    ],
    "end-time": "2022-06-28T14:08:47.595131",
    "host": 
"Linux-5.3.18-150300.59.76-default-x86_64-with-glibc2.3.4 (Linux 
lupus 5.3.18-150300.59.76-default #1 SMP Thu Jun 16 04:23:47 UTC 
2022 (2cc2ade) x86_64 x86_64)",

    "python": "3.6.15 (default, Sep 23 2021, 15:41:43) [GCC]",
    "reports": [
    {
    "arch": "arm",
    "bsp": "xilinx_zynq_a9_qemu",
    "command-line": "qemu-system-arm -no-reboot -nographic 
-net none -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 256M 
-kernel build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",

    "end-time": "2022-06-28T12:08:48.161691+00:00",
    "executable": 
"build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
    "executable-sha512": 
"413bc8a506053c95a0e1d93942cce9fd0d653f7b3cde42623085ce147aea324f4baeff7ce0102008322fb1341bc2b38defd3925a64144e47e13cc5f32185bf78", 


    "output": [
    "qemu-system-arm: warning: nic cadence_gem.0 has no 
peer",
    "qemu-system-arm: warning: nic cadence_gem.1 has no 
peer",

    "",
    "",
    "*** BEGIN OF TEST CONSTRUCTOR/DESTRUCTOR ***",
    "*** TEST VERSION: 
6.0.0.3302b72754df5f37214e86dd68522189857772c7",

    "*** TEST STATE: EXPECTED_PASS",
    "*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API",
    "*** TEST TOOLS: 12.1.1 20220622 (RTEMS 6, RSB 
bf3f66c29a046ec1c5029e4f919b525947df6245, Newlib e7ffbdb)",
    "GLOBAL: Hey I'm in base class constructor number 1 
for 0x214474.",
    "GLOBAL: Hey I'm in base class constructor number 2 
for 0x214480.",
    "GLOBAL: Hey I'm in derived class constructor 
number 3 for 0x214480.",
    "LOCAL: Hey I'm in base class constructor number 4 
for 0x228864.",

    ...


"WRoZqtoO3A8BDJkUSmRGNOBaaHW1UwAAoQGQAQwAAABck8Bx+K/znDWWTEcA", 



"AKEB2P///wEMVP6TRqQZY+4+srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAA", 



"oQH4AQwAAADJyx1ZCnZ4l+m/XkMAAKEB0P///wEMN3+9YAwMW8gTHIoPAACh", 



"Adj///8BDBtxsj3zXZF/+UqzfAAAoQHwAQwwMDMeE7mphT6yu8AAAKEB", 


"8P///wEMr2rLCcwzVnf5SrN8AAChAfD///8A",
    "*** END OF GCOV INFO BASE64 ***",
    ""
    ],
    "result": "passed",
    "start-time": "2022-06-28T12:08:47.721822+00:00"
    }
    ],
    "start-time": "2022-06-28T14:08:47.595131"
}

There are no publicly available report generators for the existing 
format, but I do have one I use to generate STR documents for 
delivery using mustache templates and further processing. The 
existing format was designed to be easily consumable by that and 
other simple templating mechanisms by providing structure (test 
subsets) and precalculating values that would otherwise be implicit 
in the data. Changes to the names of various fields should be easy 
to accommodate, but a more significant restructure is going to 
present problems continuing with any simple templating mechanism and 
would instead require a more comprehensive document generator for 
all cases.


I'm not necessarily opposed to this change as it significantly 
simplifies the report generation code, but it will definitely 
require some rework in my processes. I can't speak for any users of 
the YAML 

Re: [PATCH] libstdc++: retry removal of dir entries if dir removal fails

2022-06-30 Thread Sebastian Huber



On 30/06/2022 09:52, Alexandre Oliva via Gcc-patches wrote:

On Jun 27, 2022, Alexandre Oliva  wrote:


I see two potential ways to avoid this:

Another possibility occurred to me: seeking back to the entry we're
about to remove, before removing it.  Then, POSIX-compliant
implementations will just skip the removed entry and find the next one,
while RTEMS will find the next entry at the spot where the removed entry
used to be.

It is syscall-heavier, and it may invoke O(n^2) behavior for each
directory in remove_all, since prev_pos is quite likely to always hold
the initial offset, requiring scanning past more and more removed
entries after each removal, so I don't submit this formally for
inclusion, but post it FTR.  I've only confirmed that it solves the
problem on RTEMS, passing libstdc++ filesystem test, but I haven't
tested it further.


From my point of view this is behaviour is an RTEMS bug. Instead of 
adding tweaks for RTEMS, it would be better to report the issues and fix 
them in RTEMS. It could be also a Newlib issue.


--
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: [tools] tester: Normalize JSON and YAML reports

2022-06-30 Thread Sebastian Huber



On 30/06/2022 07:58, Sebastian Huber wrote:

On 29/06/2022 17:54, Kinsey Moore wrote:

On 6/29/2022 04:34, Sebastian Huber wrote:

On 29/06/2022 11:20, Chris Johns wrote:


On 29 Jun 2022, at 4:42 pm, Sebastian Huber 
 wrote:


On 29/06/2022 08:40, Sebastian Huber wrote:
Report the same data in JSON and YAML reports.  Do not report 
redundant

information.
Update 4671.


This patch changes the JSON reports. Are there already consumers 
for the JSON reports so that we have to be backward compatible?


Could compatibility be added back in if this proves to be an issue?

I am wondering if that could be considered if comparability becomes 
an issue.


The JSON report was added by:

commit 5fcaf843bdb491e2da14dc1af61806ac6d20bae5
Author: Kinsey Moore 
Date:   Wed Aug 21 16:34:12 2019 +

    Add JSON log generation

    Add log formatter hooks and JSON log formatter to the test 
infrastructure

    for consumption by automated processes or report generators.


I am not sure if these automated processes or report generators 
already exist.


The existing attribute names are quite inconsistent, for example 
"Command Line", "passed_count", "wrong-version_count". I would use 
lower case only with "-" as a separator. The JSON report should 
contain all information of a test run.


The new report looks like this:

{
    "command-line": [
    "/opt/rtems/6/bin/rtems-test",
    "--rtems-bsp=xilinx_zynq_a9_qemu",
    "--report-format=json",
    "--report-path=report",
    "build/arm/xilinx_zynq_a9_qemu/testsuites/samples/"
    ],
    "end-time": "2022-06-28T14:08:47.595131",
    "host": "Linux-5.3.18-150300.59.76-default-x86_64-with-glibc2.3.4 
(Linux lupus 5.3.18-150300.59.76-default #1 SMP Thu Jun 16 04:23:47 
UTC 2022 (2cc2ade) x86_64 x86_64)",

    "python": "3.6.15 (default, Sep 23 2021, 15:41:43) [GCC]",
    "reports": [
    {
    "arch": "arm",
    "bsp": "xilinx_zynq_a9_qemu",
    "command-line": "qemu-system-arm -no-reboot -nographic 
-net none -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 256M 
-kernel build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",

    "end-time": "2022-06-28T12:08:48.161691+00:00",
    "executable": 
"build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
    "executable-sha512": 
"413bc8a506053c95a0e1d93942cce9fd0d653f7b3cde42623085ce147aea324f4baeff7ce0102008322fb1341bc2b38defd3925a64144e47e13cc5f32185bf78", 


    "output": [
    "qemu-system-arm: warning: nic cadence_gem.0 has no 
peer",
    "qemu-system-arm: warning: nic cadence_gem.1 has no 
peer",

    "",
    "",
    "*** BEGIN OF TEST CONSTRUCTOR/DESTRUCTOR ***",
    "*** TEST VERSION: 
6.0.0.3302b72754df5f37214e86dd68522189857772c7",

    "*** TEST STATE: EXPECTED_PASS",
    "*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API",
    "*** TEST TOOLS: 12.1.1 20220622 (RTEMS 6, RSB 
bf3f66c29a046ec1c5029e4f919b525947df6245, Newlib e7ffbdb)",
    "GLOBAL: Hey I'm in base class constructor number 1 
for 0x214474.",
    "GLOBAL: Hey I'm in base class constructor number 2 
for 0x214480.",
    "GLOBAL: Hey I'm in derived class constructor number 
3 for 0x214480.",
    "LOCAL: Hey I'm in base class constructor number 4 
for 0x228864.",

    ...


"WRoZqtoO3A8BDJkUSmRGNOBaaHW1UwAAoQGQAQwAAABck8Bx+K/znDWWTEcA", 



"AKEB2P///wEMVP6TRqQZY+4+srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAA", 



"oQH4AQwAAADJyx1ZCnZ4l+m/XkMAAKEB0P///wEMN3+9YAwMW8gTHIoPAACh", 



"Adj///8BDBtxsj3zXZF/+UqzfAAAoQHwAQwwMDMeE7mphT6yu8AAAKEB", 


"8P///wEMr2rLCcwzVnf5SrN8AAChAfD///8A",
    "*** END OF GCOV INFO BASE64 ***",
    ""
    ],
    "result": "passed",
    "start-time": "2022-06-28T12:08:47.721822+00:00"
    }
    ],
    "start-time": "2022-06-28T14:08:47.595131"
}

There are no publicly available report generators for the existing 
format, but I do have one I use to generate STR documents for delivery 
using mustache templates and further processing. The existing format 
was designed to be easily consumable by that and other simple 
templating mechanisms by providing structure (test subsets) and 
precalculating values that would otherwise be implicit in the data. 
Changes to the names of various fields should be easy to accommodate, 
but a more significant restructure is going to present problems 
continuing with any simple templating mechanism and would instead 
require a more comprehensive document generator for all cases.


I'm not necessarily opposed to this change as it significantly 
simplifies the report generation code, but it will definitely require 
some rework in my processes. I can't speak for any users of the YAML 
report format, but it was committed over a year 

Re: [PATCH] sppps01: Add test case for early returns of pps_event()

2022-06-30 Thread Sebastian Huber



On 15/06/2022 15:08, Gabriel Moyano wrote:

---
  testsuites/sptests/sppps01/init.c | 42 +++
  1 file changed, 42 insertions(+)

diff --git a/testsuites/sptests/sppps01/init.c 
b/testsuites/sptests/sppps01/init.c
index 996a3a1e16..ee3fe1645b 100644
--- a/testsuites/sptests/sppps01/init.c
+++ b/testsuites/sptests/sppps01/init.c
@@ -76,6 +76,48 @@ T_TEST_CASE( WaitPPSEventDefaultHandler )
T_eq_int( status, ETIMEDOUT );
  }
  
+static int wokenup = 0;

+
+static void fake_wakeup(struct pps_state *pps)
+{
+wokenup++;
+}


I would move the wokenup into struct test_pps_device.

In the existing code, use rtems_task_exit() instead of 
rtems_task_delete(rtems_task_self()).


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

One test more for PPS API

2022-06-30 Thread Gabriel.Moyano
Hi Sebastian,

I added this test https://lists.rtems.org/pipermail/devel/2022-June/071926.html 
some time ago. Could you give me your feedback?

Thanks in advance,
Gabriel


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

Re: [tools] tester: Normalize JSON and YAML reports

2022-06-29 Thread Sebastian Huber

On 29/06/2022 17:54, Kinsey Moore wrote:

On 6/29/2022 04:34, Sebastian Huber wrote:

On 29/06/2022 11:20, Chris Johns wrote:


On 29 Jun 2022, at 4:42 pm, Sebastian Huber 
 wrote:


On 29/06/2022 08:40, Sebastian Huber wrote:
Report the same data in JSON and YAML reports.  Do not report 
redundant

information.
Update 4671.


This patch changes the JSON reports. Are there already consumers for 
the JSON reports so that we have to be backward compatible?


Could compatibility be added back in if this proves to be an issue?

I am wondering if that could be considered if comparability becomes 
an issue.


The JSON report was added by:

commit 5fcaf843bdb491e2da14dc1af61806ac6d20bae5
Author: Kinsey Moore 
Date:   Wed Aug 21 16:34:12 2019 +

    Add JSON log generation

    Add log formatter hooks and JSON log formatter to the test 
infrastructure

    for consumption by automated processes or report generators.


I am not sure if these automated processes or report generators 
already exist.


The existing attribute names are quite inconsistent, for example 
"Command Line", "passed_count", "wrong-version_count". I would use 
lower case only with "-" as a separator. The JSON report should 
contain all information of a test run.


The new report looks like this:

{
    "command-line": [
    "/opt/rtems/6/bin/rtems-test",
    "--rtems-bsp=xilinx_zynq_a9_qemu",
    "--report-format=json",
    "--report-path=report",
    "build/arm/xilinx_zynq_a9_qemu/testsuites/samples/"
    ],
    "end-time": "2022-06-28T14:08:47.595131",
    "host": "Linux-5.3.18-150300.59.76-default-x86_64-with-glibc2.3.4 
(Linux lupus 5.3.18-150300.59.76-default #1 SMP Thu Jun 16 04:23:47 
UTC 2022 (2cc2ade) x86_64 x86_64)",

    "python": "3.6.15 (default, Sep 23 2021, 15:41:43) [GCC]",
    "reports": [
    {
    "arch": "arm",
    "bsp": "xilinx_zynq_a9_qemu",
    "command-line": "qemu-system-arm -no-reboot -nographic 
-net none -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 256M 
-kernel build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",

    "end-time": "2022-06-28T12:08:48.161691+00:00",
    "executable": 
"build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
    "executable-sha512": 
"413bc8a506053c95a0e1d93942cce9fd0d653f7b3cde42623085ce147aea324f4baeff7ce0102008322fb1341bc2b38defd3925a64144e47e13cc5f32185bf78", 


    "output": [
    "qemu-system-arm: warning: nic cadence_gem.0 has no 
peer",
    "qemu-system-arm: warning: nic cadence_gem.1 has no 
peer",

    "",
    "",
    "*** BEGIN OF TEST CONSTRUCTOR/DESTRUCTOR ***",
    "*** TEST VERSION: 
6.0.0.3302b72754df5f37214e86dd68522189857772c7",

    "*** TEST STATE: EXPECTED_PASS",
    "*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API",
    "*** TEST TOOLS: 12.1.1 20220622 (RTEMS 6, RSB 
bf3f66c29a046ec1c5029e4f919b525947df6245, Newlib e7ffbdb)",
    "GLOBAL: Hey I'm in base class constructor number 1 
for 0x214474.",
    "GLOBAL: Hey I'm in base class constructor number 2 
for 0x214480.",
    "GLOBAL: Hey I'm in derived class constructor number 3 
for 0x214480.",
    "LOCAL: Hey I'm in base class constructor number 4 for 
0x228864.",

    ...


"WRoZqtoO3A8BDJkUSmRGNOBaaHW1UwAAoQGQAQwAAABck8Bx+K/znDWWTEcA", 



"AKEB2P///wEMVP6TRqQZY+4+srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAA", 



"oQH4AQwAAADJyx1ZCnZ4l+m/XkMAAKEB0P///wEMN3+9YAwMW8gTHIoPAACh", 



"Adj///8BDBtxsj3zXZF/+UqzfAAAoQHwAQwwMDMeE7mphT6yu8AAAKEB", 


"8P///wEMr2rLCcwzVnf5SrN8AAChAfD///8A",
    "*** END OF GCOV INFO BASE64 ***",
    ""
    ],
    "result": "passed",
    "start-time": "2022-06-28T12:08:47.721822+00:00"
    }
    ],
    "start-time": "2022-06-28T14:08:47.595131"
}

There are no publicly available report generators for the existing 
format, but I do have one I use to generate STR documents for delivery 
using mustache templates and further processing. The existing format was 
designed to be easily consumable by that and other simple templating 
mechanisms by providing structure (test subsets) and precalculating 
values that would otherwise be implicit in the data. Changes to the 
names of various fields should be easy to accommodate, but a more 
significant restructure is going to present problems continuing with any 
simple templating mechanism and would instead require a more 
comprehensive document generator for all cases.


I'm not necessarily opposed to this change as it significantly 
simplifies the report generation code, but it will definitely require 
some rework in my processes. I can't speak for any users of the YAML 
report format, but it was committed over a year and a half ago.


Ok, I will bring back the 

Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

2022-06-29 Thread oss

Hello Duc,

Am 29.06.22 um 13:46 schrieb Duc Doan:

Hello Christian,

I have been writing the complete API and also implementation for
STM32F4. A patch is coming soon.

On Mon, 2022-06-27 at 13:33 +0200, Christian MAUDERER wrote:

Regarding pin groups: I think it's worth to think a bit about how the
structure could be extended. You don't have to implement it right now
but you should have a plan what could be possible.

  From my point of view, there are two directions how that could be
implemented: Masks or lists.

If you have a mask (like 0x00108 for pin 3 and pin 8) it has the
advantage that it works fast for most controllers. Difficult is that
it
adds a limit to the maximum pin number depending on the size of the
mask. With that it works only for a few hardware models.

The other option is to add a list of pins instead of a mask. That
makes
it inefficient because most controllers will have to collect pins
into
masks and work with that.

Hm. Difficult. Maybe someone else has a good idea for that in the
next
few days.


I am thinking of later adding separate functions that handle pin
groups. I think it's quite hard to integrate into current functions
because of using virtual pin.

I have an assumption that needs confirmation: all microcontrollers (or
most of them) have register size equal to word size, and pin masks
should be at word size. Is that assumption correct? If so, maybe we can
just use unsigned int (or uintptr_t) for pin masks?


Not sure whether some 64bit controllers don't use 32bit registers. So 
it's not generally true that registers have the word size. It should 
work for most controllers (at least the ones I worked with) but I 
wouldn't guarantee it.


Beneath that: You most likely know my argument already: What about I2C 
or SPI chips. They can use register sizes that are not the same as the 
controllers register size (even if they are most likely only 8 bit most 
of the time at least for I2C).


Best regards

Christian



Best,

Duc Doan



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

Re: [tools] tester: Normalize JSON and YAML reports

2022-06-29 Thread Kinsey Moore

On 6/29/2022 04:34, Sebastian Huber wrote:

On 29/06/2022 11:20, Chris Johns wrote:


On 29 Jun 2022, at 4:42 pm, Sebastian Huber 
 wrote:


On 29/06/2022 08:40, Sebastian Huber wrote:
Report the same data in JSON and YAML reports.  Do not report 
redundant

information.
Update 4671.


This patch changes the JSON reports. Are there already consumers for 
the JSON reports so that we have to be backward compatible?


Could compatibility be added back in if this proves to be an issue?

I am wondering if that could be considered if comparability becomes 
an issue.


The JSON report was added by:

commit 5fcaf843bdb491e2da14dc1af61806ac6d20bae5
Author: Kinsey Moore 
Date:   Wed Aug 21 16:34:12 2019 +

    Add JSON log generation

    Add log formatter hooks and JSON log formatter to the test 
infrastructure

    for consumption by automated processes or report generators.


I am not sure if these automated processes or report generators 
already exist.


The existing attribute names are quite inconsistent, for example 
"Command Line", "passed_count", "wrong-version_count". I would use 
lower case only with "-" as a separator. The JSON report should 
contain all information of a test run.


The new report looks like this:

{
    "command-line": [
    "/opt/rtems/6/bin/rtems-test",
    "--rtems-bsp=xilinx_zynq_a9_qemu",
    "--report-format=json",
    "--report-path=report",
    "build/arm/xilinx_zynq_a9_qemu/testsuites/samples/"
    ],
    "end-time": "2022-06-28T14:08:47.595131",
    "host": "Linux-5.3.18-150300.59.76-default-x86_64-with-glibc2.3.4 
(Linux lupus 5.3.18-150300.59.76-default #1 SMP Thu Jun 16 04:23:47 
UTC 2022 (2cc2ade) x86_64 x86_64)",

    "python": "3.6.15 (default, Sep 23 2021, 15:41:43) [GCC]",
    "reports": [
    {
    "arch": "arm",
    "bsp": "xilinx_zynq_a9_qemu",
    "command-line": "qemu-system-arm -no-reboot -nographic 
-net none -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 256M 
-kernel build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",

    "end-time": "2022-06-28T12:08:48.161691+00:00",
    "executable": 
"build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
    "executable-sha512": 
"413bc8a506053c95a0e1d93942cce9fd0d653f7b3cde42623085ce147aea324f4baeff7ce0102008322fb1341bc2b38defd3925a64144e47e13cc5f32185bf78",

    "output": [
    "qemu-system-arm: warning: nic cadence_gem.0 has no 
peer",
    "qemu-system-arm: warning: nic cadence_gem.1 has no 
peer",

    "",
    "",
    "*** BEGIN OF TEST CONSTRUCTOR/DESTRUCTOR ***",
    "*** TEST VERSION: 
6.0.0.3302b72754df5f37214e86dd68522189857772c7",

    "*** TEST STATE: EXPECTED_PASS",
    "*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API",
    "*** TEST TOOLS: 12.1.1 20220622 (RTEMS 6, RSB 
bf3f66c29a046ec1c5029e4f919b525947df6245, Newlib e7ffbdb)",
    "GLOBAL: Hey I'm in base class constructor number 1 
for 0x214474.",
    "GLOBAL: Hey I'm in base class constructor number 2 
for 0x214480.",
    "GLOBAL: Hey I'm in derived class constructor number 3 
for 0x214480.",
    "LOCAL: Hey I'm in base class constructor number 4 for 
0x228864.",

    ...


"WRoZqtoO3A8BDJkUSmRGNOBaaHW1UwAAoQGQAQwAAABck8Bx+K/znDWWTEcA", 



"AKEB2P///wEMVP6TRqQZY+4+srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAA", 



"oQH4AQwAAADJyx1ZCnZ4l+m/XkMAAKEB0P///wEMN3+9YAwMW8gTHIoPAACh", 



"Adj///8BDBtxsj3zXZF/+UqzfAAAoQHwAQwwMDMeE7mphT6yu8AAAKEB", 


"8P///wEMr2rLCcwzVnf5SrN8AAChAfD///8A",
    "*** END OF GCOV INFO BASE64 ***",
    ""
    ],
    "result": "passed",
    "start-time": "2022-06-28T12:08:47.721822+00:00"
    }
    ],
    "start-time": "2022-06-28T14:08:47.595131"
}

There are no publicly available report generators for the existing 
format, but I do have one I use to generate STR documents for delivery 
using mustache templates and further processing. The existing format was 
designed to be easily consumable by that and other simple templating 
mechanisms by providing structure (test subsets) and precalculating 
values that would otherwise be implicit in the data. Changes to the 
names of various fields should be easy to accommodate, but a more 
significant restructure is going to present problems continuing with any 
simple templating mechanism and would instead require a more 
comprehensive document generator for all cases.


I'm not necessarily opposed to this change as it significantly 
simplifies the report generation code, but it will definitely require 
some rework in my processes. I can't speak for any users of the YAML 
report format, but it was committed over a year and a half ago.



Kinsey

___
devel mailing 

Re: [PATCH] arm/gicv3: Fix building arm/r52

2022-06-29 Thread Sebastian Huber

On 27/06/2022 08:27, Sebastian Huber wrote:

On 27/06/2022 05:02, Chris Johns wrote:

On 24/6/2022 7:44 pm, Sebastian Huber wrote:

On 20.06.22 04:03, chr...@rtems.org wrote:

From: Chris Johns 

---
   bsps/include/dev/irq/arm-gicv3.h | 5 +
   1 file changed, 5 insertions(+)

diff --git a/bsps/include/dev/irq/arm-gicv3.h 
b/bsps/include/dev/irq/arm-gicv3.h

index a79368ebdf..aac02fa191 100644
--- a/bsps/include/dev/irq/arm-gicv3.h
+++ b/bsps/include/dev/irq/arm-gicv3.h
@@ -335,7 +335,12 @@ static void gicv3_init_cpu_interface(uint32_t 
cpu_index)

 }
       /* Enable interrupt groups 0 and 1 */
+#ifdef ARM_MULTILIB_ARCH_V4
+  WRITE_SR(ICC_IGRPEN0, 0x1);
+  WRITE_SR(ICC_IGRPEN1, 0x1);
+#else
 gic_icc_write(IGRPEN1, 1);
+#endif
 WRITE_SR(ICC_CTLR, 0x0);
   }


I have a different patch to fix this:

https://lists.rtems.org/pipermail/devel/2022-June/072056.html


Does this change work on a real aarch64 with a suitably configured 
TF-A? The
security profile of the TF-A needs to disable EL1 access to these 
registers to

see the issue.


I don't have a hardware to test this change. I can do tests on a 
Cortex-R52 hardware.


For the Cortex-R52, group 0 interrupts are signaled through FIQ 
exceptions and group 1 interrupts are signaled through IRQ exceptions. 
This processor has no secore/non-secure states.


I checked the GICv3 manual. The group 0 interrupts are always Secure if 
the system has at least two Security states. So, if RTEMS runs in 
Non-Secure mode, it cannot modify group 0 interrupts. We have some 
things to consider:


1. Count of system security states

2. In which state RTEMS runs

3. What RTEMS needs to initialize

We cannot simply use the target architecture to determine what to do 
during GIC initialization. I think we need some BSP options to control 
the initialization behaviour.


--
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] score: Add _CPU_Use_thread_local_storage()

2022-06-29 Thread Sebastian Huber
At some point during system initialization, the idle threads are created.
Afterwards, the boot processor basically executes within the context of an idle
thread with thread dispatching disabled.  On some architectures, the
thread-local storage area of the associated thread must be set in dedicated
processor registers.  Add the new CPU port function to do this:

void _CPU_Use_thread_local_storage( const Context_Control *context )

Close #4672.
---
 .../cpu/aarch64/include/rtems/score/cpuimpl.h |  9 +++
 .../cpu/arm/include/rtems/score/cpuimpl.h | 13 ++
 .../cpu/bfin/include/rtems/score/cpuimpl.h|  7 +
 .../cpu/i386/include/rtems/score/cpuimpl.h| 26 +++
 .../cpu/lm32/include/rtems/score/cpuimpl.h|  7 +
 .../cpu/m68k/include/rtems/score/cpuimpl.h| 11 
 .../microblaze/include/rtems/score/cpuimpl.h  | 11 
 .../cpu/mips/include/rtems/score/cpuimpl.h|  7 +
 .../cpu/moxie/include/rtems/score/cpuimpl.h   |  7 +
 .../cpu/nios2/include/rtems/score/cpuimpl.h   | 12 +
 .../cpu/no_cpu/include/rtems/score/cpuimpl.h  | 17 
 .../cpu/or1k/include/rtems/score/cpuimpl.h|  7 +
 .../cpu/powerpc/include/rtems/score/cpuimpl.h | 16 
 .../cpu/riscv/include/rtems/score/cpuimpl.h   | 12 +
 .../cpu/sh/include/rtems/score/cpuimpl.h  |  7 +
 .../cpu/sparc/include/rtems/score/cpuimpl.h   | 12 +
 .../cpu/sparc64/include/rtems/score/cpuimpl.h |  7 +
 .../cpu/v850/include/rtems/score/cpuimpl.h|  7 +
 .../cpu/x86_64/include/rtems/score/cpuimpl.h  |  7 +
 cpukit/score/src/threadcreateidle.c   |  5 
 testsuites/sptests/sptls01/init.c | 20 +++---
 21 files changed, 223 insertions(+), 4 deletions(-)

diff --git a/cpukit/score/cpu/aarch64/include/rtems/score/cpuimpl.h 
b/cpukit/score/cpu/aarch64/include/rtems/score/cpuimpl.h
index ffdef2f30a..14836965ef 100644
--- a/cpukit/score/cpu/aarch64/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/aarch64/include/rtems/score/cpuimpl.h
@@ -162,6 +162,15 @@ RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( 
void )
   __asm__ volatile ( "nop" );
 }
 
+RTEMS_INLINE_ROUTINE void _CPU_Use_thread_local_storage(
+  const Context_Control *context
+)
+{
+  __asm__ volatile (
+"msr TPIDR_EL0, %0" : : "r" ( context->thread_id ) : "memory"
+  );
+}
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h 
b/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
index 0ce347c86f..4f20113b71 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/cpuimpl.h
@@ -160,6 +160,19 @@ RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( 
void )
   __asm__ volatile ( "nop" );
 }
 
+RTEMS_INLINE_ROUTINE void _CPU_Use_thread_local_storage(
+  const Context_Control *context
+)
+{
+#ifdef ARM_MULTILIB_HAS_THREAD_ID_REGISTER
+  __asm__ volatile (
+"mcr p15, 0, %0, c13, c0, 3" : : "r" ( context->thread_id ) : "memory"
+  );
+#else
+  (void) context;
+#endif
+}
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h 
b/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
index 1485abd365..91e57da4a0 100644
--- a/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/bfin/include/rtems/score/cpuimpl.h
@@ -59,6 +59,13 @@ RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( 
void )
   __asm__ volatile ( "nop" );
 }
 
+RTEMS_INLINE_ROUTINE void _CPU_Use_thread_local_storage(
+  const Context_Control *context
+)
+{
+  (void) context;
+}
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h 
b/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
index 31ec0ac8bb..71f2679dde 100644
--- a/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
+++ b/cpukit/score/cpu/i386/include/rtems/score/cpuimpl.h
@@ -80,6 +80,32 @@ RTEMS_INLINE_ROUTINE void _CPU_Instruction_no_operation( 
void )
   __asm__ volatile ( "nop" );
 }
 
+RTEMS_INLINE_ROUTINE void _CPU_Use_thread_local_storage(
+  const Context_Control *context
+)
+{
+  uint32_t tmp;
+  uint32_t cpu_index;
+
+#ifdef RTEMS_SMP
+  cpu_index = _CPU_SMP_Get_current_processor();
+#else
+  cpu_index = 0;
+#endif
+
+  __asm__ volatile (
+"movl " RTEMS_XSTRING( I386_CONTEXT_CONTROL_GS_0_OFFSET ) "(%2), %0\n"
+"movl %0, _Global_descriptor_table+24(,%1,8)\n"
+"movl " RTEMS_XSTRING( I386_CONTEXT_CONTROL_GS_1_OFFSET ) "(%2), %0\n"
+"movl %0, _Global_descriptor_table+28(,%1,8)\n"
+"leal 24(,%1,8), %0\n"
+"movl %0, %%gs\n"
+: "=" ( tmp )
+: "r" ( cpu_index ), "r" ( context )
+: "memory"
+  );
+}
+
 #ifdef __cplusplus
 }
 #endif
diff --git a/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h 
b/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
index eb0c058723..24e8e5cb41 100644
--- a/cpukit/score/cpu/lm32/include/rtems/score/cpuimpl.h
+++ 

Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP

2022-06-29 Thread Duc Doan
Hello Christian,

I have been writing the complete API and also implementation for
STM32F4. A patch is coming soon.

On Mon, 2022-06-27 at 13:33 +0200, Christian MAUDERER wrote:
> Regarding pin groups: I think it's worth to think a bit about how the
> structure could be extended. You don't have to implement it right now
> but you should have a plan what could be possible.
> 
>  From my point of view, there are two directions how that could be 
> implemented: Masks or lists.
> 
> If you have a mask (like 0x00108 for pin 3 and pin 8) it has the 
> advantage that it works fast for most controllers. Difficult is that
> it 
> adds a limit to the maximum pin number depending on the size of the 
> mask. With that it works only for a few hardware models.
> 
> The other option is to add a list of pins instead of a mask. That
> makes 
> it inefficient because most controllers will have to collect pins
> into 
> masks and work with that.
> 
> Hm. Difficult. Maybe someone else has a good idea for that in the
> next 
> few days.

I am thinking of later adding separate functions that handle pin
groups. I think it's quite hard to integrate into current functions
because of using virtual pin.

I have an assumption that needs confirmation: all microcontrollers (or
most of them) have register size equal to word size, and pin masks
should be at word size. Is that assumption correct? If so, maybe we can
just use unsigned int (or uintptr_t) for pin masks?

Best,

Duc Doan


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

Re: [tools] tester: Normalize JSON and YAML reports

2022-06-29 Thread Sebastian Huber

On 29/06/2022 11:20, Chris Johns wrote:



On 29 Jun 2022, at 4:42 pm, Sebastian Huber 
 wrote:

On 29/06/2022 08:40, Sebastian Huber wrote:

Report the same data in JSON and YAML reports.  Do not report redundant
information.
Update 4671.


This patch changes the JSON reports. Are there already consumers for the JSON 
reports so that we have to be backward compatible?


Could compatibility be added back in if this proves to be an issue?

I am wondering if that could be considered if comparability becomes an issue.


The JSON report was added by:

commit 5fcaf843bdb491e2da14dc1af61806ac6d20bae5
Author: Kinsey Moore 
Date:   Wed Aug 21 16:34:12 2019 +

Add JSON log generation

Add log formatter hooks and JSON log formatter to the test 
infrastructure

for consumption by automated processes or report generators.


I am not sure if these automated processes or report generators already 
exist.


The existing attribute names are quite inconsistent, for example 
"Command Line", "passed_count", "wrong-version_count". I would use lower 
case only with "-" as a separator. The JSON report should contain all 
information of a test run.


The new report looks like this:

{
"command-line": [
"/opt/rtems/6/bin/rtems-test",
"--rtems-bsp=xilinx_zynq_a9_qemu",
"--report-format=json",
"--report-path=report",
"build/arm/xilinx_zynq_a9_qemu/testsuites/samples/"
],
"end-time": "2022-06-28T14:08:47.595131",
"host": "Linux-5.3.18-150300.59.76-default-x86_64-with-glibc2.3.4 
(Linux lupus 5.3.18-150300.59.76-default #1 SMP Thu Jun 16 04:23:47 UTC 
2022 (2cc2ade) x86_64 x86_64)",

"python": "3.6.15 (default, Sep 23 2021, 15:41:43) [GCC]",
"reports": [
{
"arch": "arm",
"bsp": "xilinx_zynq_a9_qemu",
"command-line": "qemu-system-arm -no-reboot -nographic -net 
none -serial null -serial mon:stdio -M xilinx-zynq-a9 -m 256M -kernel 
build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",

"end-time": "2022-06-28T12:08:48.161691+00:00",
"executable": 
"build/arm/xilinx_zynq_a9_qemu/testsuites/samples/cdtest.exe",
"executable-sha512": 
"413bc8a506053c95a0e1d93942cce9fd0d653f7b3cde42623085ce147aea324f4baeff7ce0102008322fb1341bc2b38defd3925a64144e47e13cc5f32185bf78",

"output": [
"qemu-system-arm: warning: nic cadence_gem.0 has no peer",
"qemu-system-arm: warning: nic cadence_gem.1 has no peer",
"",
"",
"*** BEGIN OF TEST CONSTRUCTOR/DESTRUCTOR ***",
"*** TEST VERSION: 
6.0.0.3302b72754df5f37214e86dd68522189857772c7",

"*** TEST STATE: EXPECTED_PASS",
"*** TEST BUILD: RTEMS_DEBUG RTEMS_POSIX_API",
"*** TEST TOOLS: 12.1.1 20220622 (RTEMS 6, RSB 
bf3f66c29a046ec1c5029e4f919b525947df6245, Newlib e7ffbdb)",
"GLOBAL: Hey I'm in base class constructor number 1 for 
0x214474.",
"GLOBAL: Hey I'm in base class constructor number 2 for 
0x214480.",
"GLOBAL: Hey I'm in derived class constructor number 3 
for 0x214480.",
"LOCAL: Hey I'm in base class constructor number 4 for 
0x228864.",

...


"WRoZqtoO3A8BDJkUSmRGNOBaaHW1UwAAoQGQAQwAAABck8Bx+K/znDWWTEcA",

"AKEB2P///wEMVP6TRqQZY+4+srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAA",

"oQH4AQwAAADJyx1ZCnZ4l+m/XkMAAKEB0P///wEMN3+9YAwMW8gTHIoPAACh",

"Adj///8BDBtxsj3zXZF/+UqzfAAAoQHwAQwwMDMeE7mphT6yu8AAAKEB",
"8P///wEMr2rLCcwzVnf5SrN8AAChAfD///8A",
"*** END OF GCOV INFO BASE64 ***",
""
],
"result": "passed",
"start-time": "2022-06-28T12:08:47.721822+00:00"
}
],
"start-time": "2022-06-28T14:08:47.595131"
}

--
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: [tools] tester: Normalize JSON and YAML reports

2022-06-29 Thread Chris Johns

> On 29 Jun 2022, at 4:42 pm, Sebastian Huber 
>  wrote:
> 
> On 29/06/2022 08:40, Sebastian Huber wrote:
>> Report the same data in JSON and YAML reports.  Do not report redundant
>> information.
>> Update 4671.
> 
> This patch changes the JSON reports. Are there already consumers for the JSON 
> reports so that we have to be backward compatible?

Could compatibility be added back in if this proves to be an issue?

I am wondering if that could be considered if comparability becomes an issue. 

Chris


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

Re: [tools] tester: Normalize JSON and YAML reports

2022-06-29 Thread Sebastian Huber

On 29/06/2022 08:40, Sebastian Huber wrote:

Report the same data in JSON and YAML reports.  Do not report redundant
information.

Update 4671.


This patch changes the JSON reports. Are there already consumers for the 
JSON reports so that we have to be backward compatible?


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

[tools] tester: Normalize JSON and YAML reports

2022-06-29 Thread Sebastian Huber
Report the same data in JSON and YAML reports.  Do not report redundant
information.

Update 4671.
---
 tester/rt/test.py | 191 ++
 1 file changed, 40 insertions(+), 151 deletions(-)

diff --git a/tester/rt/test.py b/tester/rt/test.py
index 113936c..5b86804 100644
--- a/tester/rt/test.py
+++ b/tester/rt/test.py
@@ -218,76 +218,46 @@ def killall(tests):
 test.kill()
 
 
+def results_to_data(args, reports, start_time, end_time):
+data = {}
+data['command-line'] = args
+data['host'] = host.label(mode='all')
+data['python'] = sys.version.replace('\n', '')
+data['start-time'] = start_time.isoformat()
+data['end-time'] = start_time.isoformat()
+reports_data = []
+
+for name, run in reports.results.items():
+run_data = {}
+result = run['result']
+run_data['result'] = result
+output = []
+for line in run['output']:
+if line.startswith('] '):
+output.append(line[2:])
+elif line.startswith('=>  exe:'):
+run_data['command-line'] = line[9:]
+run_data['output'] = output
+run_data['executable'] = name
+run_data['executable-sha512'] = get_hash512(name)
+run_data['start-time'] = run['start'].isoformat()
+run_data['end-time'] = run['end'].isoformat()
+run_data['bsp'] = run['bsp']
+run_data['arch'] = run['bsp_arch']
+reports_data.append(run_data)
+
+data['reports'] = reports_data
+return data
+
+
 def generate_json_report(args, reports, start_time, end_time,
- total, json_file):
+ _total, json_file):
 import json
-import sys
-json_log = {}
-json_log['Command Line'] = " ".join(args)
-json_log['Python'] = sys.version.replace('\n', '')
-json_log['test_groups'] = []
-json_log['Host'] = host.label(mode='all')
-json_log['summary'] = {}
-json_log['summary']['passed_count'] = reports.passed
-json_log['summary']['failed_count'] = reports.failed
-json_log['summary']['user-input_count'] = reports.user_input
-json_log['summary']['expected-fail_count'] = reports.expected_fail
-json_log['summary']['indeterminate_count'] = reports.indeterminate
-json_log['summary']['benchmark_count'] = reports.benchmark
-json_log['summary']['timeout_count'] = reports.timeouts
-json_log['summary']['test-too-long_count'] = reports.test_too_long
-json_log['summary']['invalid_count'] = reports.invalids
-json_log['summary']['wrong-version_count'] = reports.wrong_version
-json_log['summary']['wrong-build_count'] = reports.wrong_build
-json_log['summary']['wrong-tools_count'] = reports.wrong_tools
-json_log['summary']['invalid-header_count'] = reports.wrong_header
-json_log['summary']['total_count'] = reports.total
-time_delta = end_time - start_time
-json_log['summary']['average_test_time'] = str(time_delta / total)
-json_log['summary']['testing_time'] = str(time_delta)
-
-result_types = [
-'failed', 'user-input', 'expected-fail', 'indeterminate',
-'benchmark', 'timeout', 'test-too-long', 'invalid', 
'wrong-version',
-'wrong-build', 'wrong-tools', 'wrong-header'
-]
-json_results = {}
-for result_type in result_types:
-json_log['summary'][result_type] = []
-
-# collate results for JSON log
-for name in reports.results:
-result_type = reports.results[name]['result']
-# map fatal-error on to failed since the report adds both to the 
failed count
-if result_type == "fatal-error":
-result_type = "failed"
-test_parts = name.split("/")
-test_category = test_parts[-2]
-test_name = test_parts[-1]
-if result_type != 'passed':
-json_log['summary'][result_type].append(test_name)
-if test_category not in json_results:
-json_results[test_category] = []
-json_result = {}
-# remove the file extension
-json_result["name"] = test_name.split('.')[0]
-json_result["result"] = result_type
-if result_type == "failed" or result_type == "timeout":
-json_result["output"] = reports.results[name]["output"]
-json_results[test_category].append(json_result)
-
-# convert results to a better format for report generation
-sorted_keys = sorted(json_results.keys())
-for i in range(len(sorted_keys)):
-results_log = {}
-results_log["index"] = i + 1
-results_log["name"] = sorted_keys[i]
-results_log["results"] = json_results[sorted_keys[i]]
-json_log["test_groups"].append(results_log)
-
-# write out JSON log
+
+data = results_to_data(args, reports, start_time, end_time);
+
 with open(json_file, 'w') as outfile:
-json.dump(json_log, outfile, sort_keys=True, indent=4)
+json.dump(data, outfile, 

[PATCH 08/12] gcov: Add functions to dump the gcov information

2022-06-29 Thread Sebastian Huber
Update #4670.
---
 cpukit/include/rtems/score/io.h |   4 +
 cpukit/include/rtems/test-info.h|   6 ++
 cpukit/libtest/testgcovdumpinfo.c   |  66 ++
 cpukit/score/src/iogcovdumpinfo.c   | 101 +
 cpukit/score/src/iogcovdumpinfobase64.c | 111 
 spec/build/cpukit/librtemscpu.yml   |   2 +
 spec/build/cpukit/librtemstest.yml  |   1 +
 testsuites/validation/tc-terminate.c|   3 +-
 8 files changed, 293 insertions(+), 1 deletion(-)
 create mode 100644 cpukit/libtest/testgcovdumpinfo.c
 create mode 100644 cpukit/score/src/iogcovdumpinfo.c
 create mode 100644 cpukit/score/src/iogcovdumpinfobase64.c

diff --git a/cpukit/include/rtems/score/io.h b/cpukit/include/rtems/score/io.h
index 106418f185..097cb9bdfe 100644
--- a/cpukit/include/rtems/score/io.h
+++ b/cpukit/include/rtems/score/io.h
@@ -141,6 +141,10 @@ int _IO_Base64url(
  */
 void _IO_Relax( void );
 
+void _IO_Gcov_dump_info( IO_Put_char put_char, void *arg );
+
+void _IO_Gcov_dump_info_base64( IO_Put_char put_char, void *arg );
+
 /** @} */ 
 
 #ifdef __cplusplus
diff --git a/cpukit/include/rtems/test-info.h b/cpukit/include/rtems/test-info.h
index 1bc963249c..c7c6c2438d 100644
--- a/cpukit/include/rtems/test-info.h
+++ b/cpukit/include/rtems/test-info.h
@@ -331,6 +331,12 @@ RTEMS_NO_RETURN void rtems_test_run(
   const RTEMS_TEST_STATE state
 );
 
+/**
+ * @brief Dumps the gcov information as a base64 encoded gcfn and gcda data
+ *   stream using rtems_put_char().
+ */
+void rtems_test_gcov_dump_info( void );
+
 /** @} */
 
 #ifdef __cplusplus
diff --git a/cpukit/libtest/testgcovdumpinfo.c 
b/cpukit/libtest/testgcovdumpinfo.c
new file mode 100644
index 00..4276d9e1c3
--- /dev/null
+++ b/cpukit/libtest/testgcovdumpinfo.c
@@ -0,0 +1,66 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSTest
+ *
+ * @brief This source file contains the implementation of
+ *   rtems_test_gcov_dump_info().
+ */
+
+/*
+ * Copyright (C) 2021, 2022 embedded brains GmbH
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+
+#include 
+#include 
+#include 
+
+ISR_LOCK_DEFINE( static, gcov_dump_lock, "gcov dump" );
+
+static bool gcov_dump_done;
+
+void rtems_test_gcov_dump_info( void )
+{
+  ISR_lock_Context lock_context;
+
+  _ISR_lock_ISR_disable_and_acquire( _dump_lock, _context );
+
+  if ( !gcov_dump_done ) {
+gcov_dump_done = true;
+
+_IO_Printf( rtems_put_char, NULL, "\n*** BEGIN OF GCOV INFO BASE64 ***\n" 
);
+_IO_Gcov_dump_info_base64( rtems_put_char, NULL );
+_IO_Printf( rtems_put_char, NULL, "\n*** END OF GCOV INFO BASE64 ***\n" );
+  }
+
+  _ISR_lock_Release_and_ISR_enable( _dump_lock, _context );
+}
diff --git a/cpukit/score/src/iogcovdumpinfo.c 
b/cpukit/score/src/iogcovdumpinfo.c
new file mode 100644
index 00..79a644106c
--- /dev/null
+++ b/cpukit/score/src/iogcovdumpinfo.c
@@ -0,0 +1,101 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreIO
+ *
+ * @brief This source file contains the implementation of _IO_Gcov_dump_info().
+ */
+
+/*
+ * Copyright (C) 2021, 2022 embedded brains GmbH
+ *
+ * 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 

[PATCH 06/12] build: Allow separate optimization flags

2022-06-29 Thread Sebastian Huber
Allow separate optimization flags for libraries and tests.  For example, the
libraries may be built without optimization if coverage instrumentation is
enabled, however, the tests may still use optimization.

Update #4670.
---
 spec/build/bsps/bspopts.yml |  6 ++
 spec/build/bsps/optcflags.yml   | 17 +
 spec/build/bsps/optliboptflags.yml  | 18 ++
 spec/build/bsps/opto0.yml   |  4 +---
 spec/build/bsps/opto1.yml   |  4 +---
 spec/build/bsps/opto2.yml   |  4 +---
 spec/build/bsps/optog.yml   |  4 +---
 spec/build/bsps/optos.yml   |  4 +---
 spec/build/bsps/opttestoptflags.yml | 18 ++
 spec/build/cpukit/grp.yml   |  6 --
 spec/build/testsuites/grp.yml   |  6 --
 wscript |  2 +-
 12 files changed, 73 insertions(+), 20 deletions(-)
 create mode 100644 spec/build/bsps/optcflags.yml
 create mode 100644 spec/build/bsps/optliboptflags.yml
 create mode 100644 spec/build/bsps/opttestoptflags.yml

diff --git a/spec/build/bsps/bspopts.yml b/spec/build/bsps/bspopts.yml
index d43136e94e..522b1865bc 100644
--- a/spec/build/bsps/bspopts.yml
+++ b/spec/build/bsps/bspopts.yml
@@ -7,6 +7,10 @@ guard: __BSP_OPTIONS_H
 include-headers: []
 install-path: ${BSP_INCLUDEDIR}
 links:
+- role: build-dependency
+  uid: optliboptflags
+- role: build-dependency
+  uid: opttestoptflags
 - role: build-dependency
   uid: optabi
 - role: build-dependency
@@ -17,6 +21,8 @@ links:
   uid: optfatalverb
 - role: build-dependency
   uid: optincludes
+- role: build-dependency
+  uid: optcflags
 - role: build-dependency
   uid: optlinkflags
 - role: build-dependency
diff --git a/spec/build/bsps/optcflags.yml b/spec/build/bsps/optcflags.yml
new file mode 100644
index 00..8035640ae3
--- /dev/null
+++ b/spec/build/bsps/optcflags.yml
@@ -0,0 +1,17 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- set-value: |
+${LIBRARY_OPTIMIZATION_FLAGS}
+- substitute: null
+- split: null
+- env-assign: null
+build-type: option
+copyrights:
+- Copyright (C) 2022 embedded brains GmbH (http://www.embedded-brains.de)
+default: null
+default-by-variant: []
+description: ''
+enabled-by: true
+links: []
+name: BSP_CFLAGS
+type: build
diff --git a/spec/build/bsps/optliboptflags.yml 
b/spec/build/bsps/optliboptflags.yml
new file mode 100644
index 00..039284299a
--- /dev/null
+++ b/spec/build/bsps/optliboptflags.yml
@@ -0,0 +1,18 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- substitute: null
+- split: null
+- env-assign: null
+build-type: option
+copyrights:
+- Copyright (C) 2022 embedded brains GmbH (http://www.embedded-brains.de)
+default: ${OPTIMIZATION_FLAGS}
+default-by-variant: []
+description: |
+  Optimization flags passed to the C and C++ compiler for libraries.
+enabled-by: true
+format: '{}'
+links: []
+name: LIBRARY_OPTIMIZATION_FLAGS
+type: build
diff --git a/spec/build/bsps/opto0.yml b/spec/build/bsps/opto0.yml
index 406286980f..9f54709c07 100644
--- a/spec/build/bsps/opto0.yml
+++ b/spec/build/bsps/opto0.yml
@@ -3,8 +3,6 @@ actions:
 - get-string: null
 - split: null
 - env-assign: null
-- env-append: CFLAGS
-- env-append: CXXFLAGS
 build-type: option
 copyrights:
 - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
@@ -15,7 +13,7 @@ default:
 - -ffunction-sections
 default-by-variant: []
 description: |
-  Optimization flags passed to the C and C++ compiler
+  Default optimization flags for C and C++ compilers.
 enabled-by: true
 links: []
 name: OPTIMIZATION_FLAGS
diff --git a/spec/build/bsps/opto1.yml b/spec/build/bsps/opto1.yml
index 52d285c2ab..e0668a887b 100644
--- a/spec/build/bsps/opto1.yml
+++ b/spec/build/bsps/opto1.yml
@@ -3,8 +3,6 @@ actions:
 - get-string: null
 - split: null
 - env-assign: null
-- env-append: CFLAGS
-- env-append: CXXFLAGS
 build-type: option
 copyrights:
 - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
@@ -15,7 +13,7 @@ default:
 - -ffunction-sections
 default-by-variant: []
 description: |
-  Optimization flags passed to the C and C++ compiler
+  Default optimization flags for C and C++ compilers.
 enabled-by: true
 links: []
 name: OPTIMIZATION_FLAGS
diff --git a/spec/build/bsps/opto2.yml b/spec/build/bsps/opto2.yml
index 071e5411d5..7b54556c5b 100644
--- a/spec/build/bsps/opto2.yml
+++ b/spec/build/bsps/opto2.yml
@@ -3,8 +3,6 @@ actions:
 - get-string: null
 - split: null
 - env-assign: null
-- env-append: CFLAGS
-- env-append: CXXFLAGS
 build-type: option
 copyrights:
 - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
@@ -15,7 +13,7 @@ default:
 - -ffunction-sections
 default-by-variant: []
 description: |
-  Optimization flags passed to the C and C++ compiler
+  Default optimization flags for C and C++ compilers.
 enabled-by: true
 links: []
 name: OPTIMIZATION_FLAGS
diff --git a/spec/build/bsps/optog.yml 

[PATCH 09/12] gcov: Add wrapper to dump the gcov info

2022-06-29 Thread Sebastian Huber
Update #4670.
---
 cpukit/libtest/testgcovbspreset.c | 54 +++
 cpukit/libtest/testgcovcpufatalhalt.c | 54 +++
 spec/build/cpukit/librtemstest.yml|  2 +
 3 files changed, 110 insertions(+)
 create mode 100644 cpukit/libtest/testgcovbspreset.c
 create mode 100644 cpukit/libtest/testgcovcpufatalhalt.c

diff --git a/cpukit/libtest/testgcovbspreset.c 
b/cpukit/libtest/testgcovbspreset.c
new file mode 100644
index 00..6e10615f8c
--- /dev/null
+++ b/cpukit/libtest/testgcovbspreset.c
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSTest
+ *
+ * @brief This source file contains the implementation of a wrapper for
+ *   bsp_reset() which dumps the gcov information using
+ *   rtems_test_gcov_dump_info() before the real bsp_reset() is called.
+ */
+
+/*
+ * Copyright (C) 2021, 2022 embedded brains GmbH
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+
+#include 
+
+void __real_bsp_reset( void );
+
+void __wrap_bsp_reset( void );
+
+void __wrap_bsp_reset( void )
+{
+  rtems_test_gcov_dump_info();
+  __real_bsp_reset();
+}
diff --git a/cpukit/libtest/testgcovcpufatalhalt.c 
b/cpukit/libtest/testgcovcpufatalhalt.c
new file mode 100644
index 00..dd8f10149c
--- /dev/null
+++ b/cpukit/libtest/testgcovcpufatalhalt.c
@@ -0,0 +1,54 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSTest
+ *
+ * @brief This source file contains the implementation of a wrapper for
+ *   _CPU_Fatal_halt() which dumps the gcov information using
+ *   rtems_test_gcov_dump_info() before the real _CPU_Fatal_halt() is called.
+ */
+
+/*
+ * Copyright (C) 2021, 2022 embedded brains GmbH
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+
+#include 
+
+void __real__CPU_Fatal_halt( uint32_t source, CPU_Uint32ptr error );
+
+void __wrap__CPU_Fatal_halt( uint32_t source, CPU_Uint32ptr error );
+
+void __wrap__CPU_Fatal_halt( uint32_t source, CPU_Uint32ptr error )
+{
+  rtems_test_gcov_dump_info();
+  __real__CPU_Fatal_halt( source, error );
+}
diff --git a/spec/build/cpukit/librtemstest.yml 
b/spec/build/cpukit/librtemstest.yml
index cb04690066..ddbf6e3e76 100644
--- a/spec/build/cpukit/librtemstest.yml
+++ b/spec/build/cpukit/librtemstest.yml
@@ -38,6 

[PATCH 12/12] libtests/crypt01: Avoid stack overflows

2022-06-29 Thread Sebastian Huber
The SHA512 functions may use huge amounts of stack space if compiled without
optimization.
---
 testsuites/libtests/crypt01/init.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/testsuites/libtests/crypt01/init.c 
b/testsuites/libtests/crypt01/init.c
index 0944aa60f7..26ba70e250 100644
--- a/testsuites/libtests/crypt01/init.c
+++ b/testsuites/libtests/crypt01/init.c
@@ -36,6 +36,8 @@
 #include 
 #include 
 
+#include 
+
 #include "tmacros.h"
 
 const char rtems_test_name[] = "CRYPT 1";
@@ -234,18 +236,20 @@ static void Init(rtems_task_argument arg)
   test_sha512();
   test_generic();
 
+  rtems_test_assert(!rtems_stack_checker_is_blown());
   TEST_END();
   rtems_test_exit(0);
 }
 
 #define CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER
 #define CONFIGURE_APPLICATION_NEEDS_SIMPLE_CONSOLE_DRIVER
+#define CONFIGURE_STACK_CHECKER_ENABLED
 
 #define CONFIGURE_MAXIMUM_TASKS 1
 
 #define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
 
-#define CONFIGURE_INIT_TASK_STACK_SIZE (2 * RTEMS_MINIMUM_STACK_SIZE)
+#define CONFIGURE_INIT_TASK_STACK_SIZE (8 * RTEMS_MINIMUM_STACK_SIZE)
 
 #define CONFIGURE_RTEMS_INIT_TASKS_TABLE
 
-- 
2.35.3

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


[PATCH 10/12] build: Add RTEMS_COVERAGE option

2022-06-29 Thread Sebastian Huber
Update #4670.
---
 spec/build/bsps/optcflags.yml  |  2 +-
 spec/build/cpukit/cpuopts.yml  | 10 +
 spec/build/cpukit/grp.yml  |  2 ++
 spec/build/cpukit/optcoverage.yml  | 16 ++
 spec/build/cpukit/optcoveragecflags.yml| 20 +
 spec/build/cpukit/optcoverageldflags.yml   | 25 ++
 spec/build/cpukit/optnocoveragecflags.yml  | 18 
 spec/build/cpukit/optnocoverageldflags.yml | 18 
 spec/build/testsuites/grp.yml  |  3 ++-
 9 files changed, 112 insertions(+), 2 deletions(-)
 create mode 100644 spec/build/cpukit/optcoverage.yml
 create mode 100644 spec/build/cpukit/optcoveragecflags.yml
 create mode 100644 spec/build/cpukit/optcoverageldflags.yml
 create mode 100644 spec/build/cpukit/optnocoveragecflags.yml
 create mode 100644 spec/build/cpukit/optnocoverageldflags.yml

diff --git a/spec/build/bsps/optcflags.yml b/spec/build/bsps/optcflags.yml
index 8035640ae3..7d63c95d41 100644
--- a/spec/build/bsps/optcflags.yml
+++ b/spec/build/bsps/optcflags.yml
@@ -1,7 +1,7 @@
 SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 actions:
 - set-value: |
-${LIBRARY_OPTIMIZATION_FLAGS}
+${LIBRARY_OPTIMIZATION_FLAGS} ${COVERAGE_COMPILER_FLAGS}
 - substitute: null
 - split: null
 - env-assign: null
diff --git a/spec/build/cpukit/cpuopts.yml b/spec/build/cpukit/cpuopts.yml
index 301d49ccea..86cc7f676a 100644
--- a/spec/build/cpukit/cpuopts.yml
+++ b/spec/build/cpukit/cpuopts.yml
@@ -67,6 +67,16 @@ links:
   uid: optszoff
 - role: build-dependency
   uid: optsztime
+- role: build-dependency
+  uid: optcoverage
+- role: build-dependency
+  uid: optcoveragecflags
+- role: build-dependency
+  uid: optnocoveragecflags
+- role: build-dependency
+  uid: optcoverageldflags
+- role: build-dependency
+  uid: optnocoverageldflags
 - role: build-dependency
   uid: optversion
 target: cpukit/include/rtems/score/cpuopts.h
diff --git a/spec/build/cpukit/grp.yml b/spec/build/cpukit/grp.yml
index 9958b0bd66..58b9757f54 100644
--- a/spec/build/cpukit/grp.yml
+++ b/spec/build/cpukit/grp.yml
@@ -2,11 +2,13 @@ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 build-type: group
 cflags:
 - ${LIBRARY_OPTIMIZATION_FLAGS}
+- ${COVERAGE_COMPILER_FLAGS}
 copyrights:
 - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
 cppflags: []
 cxxflags:
 - ${LIBRARY_OPTIMIZATION_FLAGS}
+- ${COVERAGE_COMPILER_FLAGS}
 enabled-by: true
 includes: []
 install: []
diff --git a/spec/build/cpukit/optcoverage.yml 
b/spec/build/cpukit/optcoverage.yml
new file mode 100644
index 00..f0bdfa4ca4
--- /dev/null
+++ b/spec/build/cpukit/optcoverage.yml
@@ -0,0 +1,16 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-boolean: null
+- env-enable: null
+- define-condition: null
+build-type: option
+copyrights:
+- Copyright (C) 2022 embedded brains GmbH (http://www.embedded-brains.de)
+default: false
+default-by-variant: []
+description: |
+  Enable the code and branch coverage support.
+enabled-by: true
+links: []
+name: RTEMS_COVERAGE
+type: build
diff --git a/spec/build/cpukit/optcoveragecflags.yml 
b/spec/build/cpukit/optcoveragecflags.yml
new file mode 100644
index 00..512eeffe56
--- /dev/null
+++ b/spec/build/cpukit/optcoveragecflags.yml
@@ -0,0 +1,20 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- split: null
+- env-assign: null
+build-type: option
+copyrights:
+- Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
+default:
+- --coverage
+- -fprofile-info-section=.rtemsroset.gcov_info.content
+- -fprofile-update=atomic
+default-by-variant: []
+description: |
+  Compiler flags recommended for components which should generate coverage
+  information.
+enabled-by: RTEMS_COVERAGE
+links: []
+name: COVERAGE_COMPILER_FLAGS
+type: build
diff --git a/spec/build/cpukit/optcoverageldflags.yml 
b/spec/build/cpukit/optcoverageldflags.yml
new file mode 100644
index 00..f13322cbee
--- /dev/null
+++ b/spec/build/cpukit/optcoverageldflags.yml
@@ -0,0 +1,25 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- split: null
+- env-assign: null
+build-type: option
+copyrights:
+- Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
+default:
+- -Wl,--wrap=_CPU_Fatal_halt
+- -Wl,--wrap=bsp_reset
+- -Wl,--start-group
+- -lrtemsbsp
+- -lrtemscpu
+- -lrtemstest
+- -lgcov
+- -Wl,--end-group
+default-by-variant: []
+description: |
+  Linker flags recommended for executables which contain modules with coverage
+  information.
+enabled-by: RTEMS_COVERAGE
+links: []
+name: COVERAGE_LINKER_FLAGS
+type: build
diff --git a/spec/build/cpukit/optnocoveragecflags.yml 
b/spec/build/cpukit/optnocoveragecflags.yml
new file mode 100644
index 00..561a99b0d4
--- /dev/null
+++ b/spec/build/cpukit/optnocoveragecflags.yml
@@ -0,0 +1,18 @@
+SPDX-License-Identifier: 

[PATCH 11/12] samples/minimum: Prevent a stack overflow

2022-06-29 Thread Sebastian Huber
Prevent a stack overflow if RTEMS_COVERAGE is enabled.
---
 testsuites/samples/minimum/init.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/testsuites/samples/minimum/init.c 
b/testsuites/samples/minimum/init.c
index c988d6d750..4238c47659 100644
--- a/testsuites/samples/minimum/init.c
+++ b/testsuites/samples/minimum/init.c
@@ -81,7 +81,12 @@ static void *Init( uintptr_t ignored )
  *  demonstrates that the user can specify how small of a minimum
  *  stack they want.
  */
+#ifdef RTEMS_COVERAGE
+#define CONFIGURE_MINIMUM_TASK_STACK_SIZE \
+  (CPU_STACK_MINIMUM_SIZE - CPU_STACK_ALIGNMENT)
+#else
 #define CONFIGURE_MINIMUM_TASK_STACK_SIZE 512
+#endif
 
 /*
  * Keep the interrupt/initialization stack as is.  Otherwise, the test may fail
-- 
2.35.3

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


[PATCH 05/12] build: Add cppflags, cflags, cxxflags to groups

2022-06-29 Thread Sebastian Huber
Propagate the group defined cppflags, cflags, and cxxflags from parent groups
to child items through the build item context.

Update #4670.
---
 spec/build/bsps/aarch64/a53/grp.yml  | 3 +++
 spec/build/bsps/aarch64/a72/grp.yml  | 3 +++
 spec/build/bsps/aarch64/grp.yml  | 3 +++
 spec/build/bsps/aarch64/xilinx-versal/grp.yml| 3 +++
 spec/build/bsps/aarch64/xilinx-versal/grp_qemu.yml   | 3 +++
 spec/build/bsps/aarch64/xilinx-versal/grp_vck190.yml | 3 +++
 spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml| 3 +++
 spec/build/bsps/aarch64/xilinx-zynqmp/grp_zu3eg.yml  | 5 -
 spec/build/bsps/arm/beagle/grp.yml   | 3 +++
 spec/build/bsps/arm/csb337/grp.yml   | 3 +++
 spec/build/bsps/arm/fvp/grp.yml  | 3 +++
 spec/build/bsps/arm/grp.yml  | 3 +++
 spec/build/bsps/arm/lm3s69xx/grp.yml | 3 +++
 spec/build/bsps/arm/lpc176x/grp.yml  | 3 +++
 spec/build/bsps/arm/lpc24xx/grp.yml  | 3 +++
 spec/build/bsps/arm/lpc32xx/grp.yml  | 3 +++
 spec/build/bsps/arm/raspberrypi/grp.yml  | 3 +++
 spec/build/bsps/arm/rtl22xx/grp.yml  | 3 +++
 spec/build/bsps/arm/stm32f4/grp.yml  | 3 +++
 spec/build/bsps/arm/stm32h7/grp.yml  | 3 +++
 spec/build/bsps/arm/tms570/grp.yml   | 3 +++
 spec/build/bsps/arm/xilinx-zynq/grp.yml  | 3 +++
 spec/build/bsps/bfin/grp.yml | 3 +++
 spec/build/bsps/grpmake.yml  | 3 +++
 spec/build/bsps/i386/grp.yml | 3 +++
 spec/build/bsps/i386/pc386/grp.yml   | 3 +++
 spec/build/bsps/lm32/grp.yml | 3 +++
 spec/build/bsps/lm32/lm32_evr/grp.yml| 3 +++
 spec/build/bsps/m68k/gen68360/grp.yml| 3 +++
 spec/build/bsps/m68k/genmcf548x/grp.yml  | 3 +++
 spec/build/bsps/m68k/grp.yml | 3 +++
 spec/build/bsps/m68k/mvme162/grp.yml | 3 +++
 spec/build/bsps/microblaze/grp.yml   | 3 +++
 spec/build/bsps/microblaze/microblaze_fpga/grp.yml   | 3 +++
 spec/build/bsps/mips/grp.yml | 3 +++
 spec/build/bsps/or1k/grp.yml | 3 +++
 spec/build/bsps/powerpc/gen5200/grp.yml  | 3 +++
 spec/build/bsps/powerpc/gen83xx/grp.yml  | 3 +++
 spec/build/bsps/powerpc/grp.yml  | 3 +++
 spec/build/bsps/powerpc/motorola_powerpc/grp.yml | 3 +++
 spec/build/bsps/powerpc/mpc55xxevb/grp.yml   | 3 +++
 spec/build/bsps/powerpc/qoriq/grp.yml| 3 +++
 spec/build/bsps/powerpc/tqm8xx/grp.yml   | 3 +++
 spec/build/bsps/riscv/griscv/grp.yml | 3 +++
 spec/build/bsps/riscv/grp.yml| 3 +++
 spec/build/bsps/riscv/riscv/grp.yml  | 3 +++
 spec/build/bsps/sh/shsim/grp.yml | 3 +++
 spec/build/bsps/sparc/grp.yml| 3 +++
 spec/build/bsps/sparc/leon2/grp.yml  | 3 +++
 spec/build/bsps/sparc/leon3/grp.yml  | 3 +++
 spec/build/bsps/sparc64/grp.yml  | 3 +++
 spec/build/bsps/v850/gdbv850sim/grp.yml  | 3 +++
 spec/build/bsps/x86_64/grp.yml   | 3 +++
 spec/build/cpukit/grp.yml| 3 +++
 spec/build/grp.yml   | 3 +++
 spec/build/testsuites/ada/grp.yml| 3 +++
 spec/build/testsuites/benchmarks/grp.yml | 3 +++
 spec/build/testsuites/fstests/grp.yml| 3 +++
 spec/build/testsuites/grp.yml| 3 +++
 spec/build/testsuites/libtests/grp.yml   | 3 +++
 spec/build/testsuites/mptests/grp.yml| 3 +++
 spec/build/testsuites/psxtests/grp.yml   | 3 +++
 spec/build/testsuites/psxtmtests/grp.yml | 3 +++
 spec/build/testsuites/rhealstone/grp.yml | 3 +++
 spec/build/testsuites/samples/grp.yml| 3 +++
 spec/build/testsuites/smptests/grp.yml   | 3 +++
 spec/build/testsuites/sptests/grp.yml| 3 +++
 spec/build/testsuites/tmtests/grp.yml| 3 +++
 spec/build/testsuites/unit/grp.yml   | 3 +++
 spec/build/testsuites/validation/grp.yml | 3 +++
 wscript  | 6 +++---
 71 files changed, 214 insertions(+), 4 deletions(-)

diff --git a/spec/build/bsps/aarch64/a53/grp.yml 
b/spec/build/bsps/aarch64/a53/grp.yml
index cc6418da75..091f18d6f5 100644
--- a/spec/build/bsps/aarch64/a53/grp.yml
+++ b/spec/build/bsps/aarch64/a53/grp.yml
@@ -1,7 +1,10 @@
 SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 build-type: group
+cflags: []
 copyrights:
 - Copyright (C) 2020 On-Line Applications Research (OAR)
+cppflags: 

[PATCH 00/12] Support gcov instrumentation

2022-06-29 Thread Sebastian Huber
This patch set adds support to build the RTEMS libraries with gcov
instrumentation to get code and branch coverage.  There are some improvements
necessary in the build system to support different compiler flags for libraries
and tests.  In general, code coverage is enabled by the new RTEMS_COVERAGE
build configuration option.  The user can fine tune the build through the
LIBRARY_OPTIMIZATION_FLAGS, TEST_OPTIMIZATION_FLAGS, and 
COVERAGE_COMPILER_FLAGS,
COVERAGE_LINKER_FLAGS options.  The gcov information is dumped after each test
case in a base64 encoded gcfn and gcda data stream.  It looks like this:

*** BEGIN OF GCOV INFO BASE64 ***
bmZjZyAxMkJSL3RtcC9zaC9iLXJ0ZW1zL2FybS94aWxpbnhfenlucV9hOV9xZW11L2NwdWtp
dC9saWJjc3VwcG9ydC9zcmMvX19nZXR0b2QuYy42NS5nY2RhAGFkY2cgMTJCPoT6qo6mcBUB
DOOrF1pxp0aIPrK7wAAAoQHwAQwAAADTfDdNQYCYwJ9ZRL0AAKEBIAQA
...
srvAAAChAfD///8BDMXOxS0Rhzqx6Old2wAAoQH4AQwAAACYh8U9/rgJ5hMc
ig8AAKEB2P///wEMN3+9YAwMW8gTHIoPAAChAdj///8BDDAwMx4TuamFPrK7
wAAAoQHwAQwAAACvassJzDNWd/lKs3wAAKEB8P///wA=
*** END OF GCOV INFO BASE64 ***

On the host you can decode the block and pipe it through the gcov-tool to
produce the *.gcda files.  Example Python code:

block = some regex stuff to get the block between the BEGIN/END OF ...
stream = base64.b64decode(block)
subprocess.run(["arm-rtems6-gcov-tool", "merge-stream"], input=stream)

Sebastian Huber (12):
  build: Add more flags to BuildItemContext
  build: Move BSP_INCLUDES split
  build: Fix identifier pattern
  build: Improve value substitution
  build: Add cppflags, cflags, cxxflags to groups
  build: Allow separate optimization flags
  gcov: Add fork(), etc. gcov wrappers
  gcov: Add functions to dump the gcov information
  gcov: Add wrapper to dump the gcov info
  build: Add RTEMS_COVERAGE option
  samples/minimum: Prevent a stack overflow
  libtests/crypt01: Avoid stack overflows

 cpukit/include/rtems/score/io.h   |   4 +
 cpukit/include/rtems/test-info.h  |   6 +
 cpukit/libcsupport/src/gcovfork.c |  94 ++
 cpukit/libtest/testgcovbspreset.c |  54 
 cpukit/libtest/testgcovcpufatalhalt.c |  54 
 cpukit/libtest/testgcovdumpinfo.c |  66 ++
 cpukit/score/src/iogcovdumpinfo.c | 101 +++
 cpukit/score/src/iogcovdumpinfobase64.c   | 111 
 spec/build/bsps/aarch64/a53/grp.yml   |   3 +
 spec/build/bsps/aarch64/a72/grp.yml   |   3 +
 spec/build/bsps/aarch64/grp.yml   |   3 +
 spec/build/bsps/aarch64/xilinx-versal/grp.yml |   3 +
 .../bsps/aarch64/xilinx-versal/grp_qemu.yml   |   3 +
 .../bsps/aarch64/xilinx-versal/grp_vck190.yml |   3 +
 spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml |   3 +
 .../bsps/aarch64/xilinx-zynqmp/grp_zu3eg.yml  |   5 +-
 spec/build/bsps/arm/beagle/grp.yml|   3 +
 spec/build/bsps/arm/csb337/grp.yml|   3 +
 spec/build/bsps/arm/fvp/grp.yml   |   3 +
 spec/build/bsps/arm/grp.yml   |   3 +
 spec/build/bsps/arm/lm3s69xx/grp.yml  |   3 +
 spec/build/bsps/arm/lpc176x/grp.yml   |   3 +
 spec/build/bsps/arm/lpc24xx/grp.yml   |   3 +
 spec/build/bsps/arm/lpc32xx/grp.yml   |   3 +
 spec/build/bsps/arm/raspberrypi/grp.yml   |   3 +
 spec/build/bsps/arm/rtl22xx/grp.yml   |   3 +
 spec/build/bsps/arm/stm32f4/grp.yml   |   3 +
 spec/build/bsps/arm/stm32h7/grp.yml   |   3 +
 spec/build/bsps/arm/tms570/grp.yml|   3 +
 spec/build/bsps/arm/xilinx-zynq/grp.yml   |   3 +
 spec/build/bsps/bfin/grp.yml  |   3 +
 spec/build/bsps/bspopts.yml   |   6 +
 spec/build/bsps/grpmake.yml   |   3 +
 spec/build/bsps/i386/grp.yml  |   3 +
 spec/build/bsps/i386/pc386/grp.yml|   3 +
 spec/build/bsps/lm32/grp.yml  |   3 +
 spec/build/bsps/lm32/lm32_evr/grp.yml |   3 +
 spec/build/bsps/m68k/gen68360/grp.yml |   3 +
 spec/build/bsps/m68k/genmcf548x/grp.yml   |   3 +
 spec/build/bsps/m68k/grp.yml  |   3 +
 spec/build/bsps/m68k/mvme162/grp.yml  |   3 +
 spec/build/bsps/microblaze/grp.yml|   3 +
 .../bsps/microblaze/microblaze_fpga/grp.yml   |   3 +
 spec/build/bsps/mips/grp.yml  |   3 +
 spec/build/bsps/optcflags.yml |  17 +++
 spec/build/bsps/optincludes.yml   |   1 +
 spec/build/bsps/optliboptflags.yml|  18 +++
 spec/build/bsps/opto0.yml |   4 +-
 spec/build/bsps/opto1.yml |   4 +-
 spec/build/bsps/opto2.yml |   4 +-
 spec/build/bsps/optog.yml |   4 +-
 spec/build/bsps/optos.yml |   4 +-
 spec/build/bsps/opttestoptflags.yml   |  18 +++
 spec/build/bsps/or1k/grp.yml  |   3 +
 

[PATCH 01/12] build: Add more flags to BuildItemContext

2022-06-29 Thread Sebastian Huber
Add cppflags, cflags, and cxxflags to BuildItemContext.  This allows to
propagate the flags from parent items to child items.

Update #4670.
---
 wscript | 93 +++--
 1 file changed, 70 insertions(+), 23 deletions(-)

diff --git a/wscript b/wscript
index 8ad0ed30b1..e6abdaa7b5 100755
--- a/wscript
+++ b/wscript
@@ -513,6 +513,9 @@ class GroupItem(Item):
 def prepare_build(self, bld, bic):
 return BuildItemContext(
 bic.includes + self.get_values(bld, "includes"),
+bic.cppflags,
+bic.cflags,
+bic.cxxflags,
 self.data["use-before"] + bic.use + self.data["use-after"],
 bic.ldflags + self.get_values(bld, "ldflags"),
 bic.objects,
@@ -578,13 +581,24 @@ class ObjectsItem(Item):
 def __init__(self, uid, data):
 super(ObjectsItem, self).__init__(uid, data)
 
+def prepare_build(self, bld, bic):
+return BuildItemContext(
+bic.includes + self.substitute(bld, self.data["includes"]),
+bic.cppflags + self.substitute(bld, self.data["cppflags"]),
+bic.cflags + self.substitute(bld, self.data["cflags"]),
+bic.cxxflags + self.substitute(bld, self.data["cxxflags"]),
+bic.use,
+bic.ldflags,
+bic.objects,
+)
+
 def do_build(self, bld, bic):
 bld.objects(
-asflags=self.substitute(bld, self.data["cppflags"]),
-cflags=self.substitute(bld, self.data["cflags"]),
-cppflags=self.substitute(bld, self.data["cppflags"]),
-cxxflags=self.substitute(bld, self.data["cxxflags"]),
-includes=bic.includes + self.substitute(bld, 
self.data["includes"]),
+asflags=bic.cppflags,
+cflags=bic.cflags,
+cppflags=bic.cppflags,
+cxxflags=bic.cxxflags,
+includes=bic.includes,
 source=self.data["source"],
 target=self.uid,
 )
@@ -600,15 +614,23 @@ class BSPItem(Item):
 
 def prepare_build(self, bld, bic):
 return BuildItemContext(
-bic.includes + bld.env.BSP_INCLUDES.split(), [], [], []
+bic.includes
++ bld.env.BSP_INCLUDES.split()
++ self.substitute(bld, self.data["includes"]),
+self.substitute(bld, self.data["cppflags"]),
+self.substitute(bld, self.data["cflags"]),
+[],
+[],
+[],
+[],
 )
 
 def do_build(self, bld, bic):
 bld(
-cflags=self.substitute(bld, self.data["cflags"]),
-cppflags=self.substitute(bld, self.data["cppflags"]),
+cflags=bic.cflags,
+cppflags=bic.cppflags,
 features="c cstlib",
-includes=bic.includes + self.substitute(bld, 
self.data["includes"]),
+includes=bic.includes,
 install_path="${BSP_LIBDIR}",
 source=self.data["source"],
 target="rtemsbsp",
@@ -622,15 +644,23 @@ class LibraryItem(Item):
 super(LibraryItem, self).__init__(uid, data)
 
 def prepare_build(self, bld, bic):
-return BuildItemContext(bic.includes, [], [], [])
+return BuildItemContext(
+bic.includes + self.substitute(bld, self.data["includes"]),
+bic.cppflags + self.substitute(bld, self.data["cppflags"]),
+bic.cflags + self.substitute(bld, self.data["cflags"]),
+bic.cxxflags + self.substitute(bld, self.data["cxxflags"]),
+bic.use,
+bic.ldflags,
+[],
+)
 
 def do_build(self, bld, bic):
 bld(
-cflags=self.substitute(bld, self.data["cflags"]),
-cppflags=self.substitute(bld, self.data["cppflags"]),
-cxxflags=self.substitute(bld, self.data["cxxflags"]),
+cflags=bic.cflags,
+cppflags=bic.cppflags,
+cxxflags=bic.cxxflags,
 features="c cxx cstlib",
-includes=bic.includes + self.substitute(bld, 
self.data["includes"]),
+includes=bic.includes,
 install_path=self.data["install-path"],
 source=self.data["source"],
 target=self.get(bld, "target"),
@@ -650,22 +680,32 @@ class TestProgramItem(Item):
 return [{"and": [{"not": self.exclude}, self.data["enabled-by"]]}]
 
 def prepare_build(self, bld, bic):
-return BuildItemContext(bic.includes, bic.use, bic.ldflags, [])
+return BuildItemContext(
+bic.includes + self.substitute(bld, self.data["includes"]),
+bic.cppflags
++ bld.env[self.cppflags]
++ self.substitute(bld, self.data["cppflags"]),
+bic.cflags + self.substitute(bld, self.data["cflags"]),
+bic.cxxflags + self.substitute(bld, self.data["cxxflags"]),
+self.data["use-before"] + bic.use + self.data["use-after"],
+

[PATCH 02/12] build: Move BSP_INCLUDES split

2022-06-29 Thread Sebastian Huber
The goal is to let the build items define as much as possible.
---
 spec/build/bsps/optincludes.yml | 1 +
 wscript | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/spec/build/bsps/optincludes.yml b/spec/build/bsps/optincludes.yml
index 0b4a71031c..ea57fe3e05 100644
--- a/spec/build/bsps/optincludes.yml
+++ b/spec/build/bsps/optincludes.yml
@@ -3,6 +3,7 @@ actions:
 - set-value: |
 bsps/include bsps/${ARCH}/include bsps/${ARCH}/${BSP_FAMILY}/include
 - substitute: null
+- split: null
 - env-assign: null
 build-type: option
 copyrights:
diff --git a/wscript b/wscript
index e6abdaa7b5..38910f2816 100755
--- a/wscript
+++ b/wscript
@@ -615,7 +615,7 @@ class BSPItem(Item):
 def prepare_build(self, bld, bic):
 return BuildItemContext(
 bic.includes
-+ bld.env.BSP_INCLUDES.split()
++ bld.env.BSP_INCLUDES
 + self.substitute(bld, self.data["includes"]),
 self.substitute(bld, self.data["cppflags"]),
 self.substitute(bld, self.data["cflags"]),
-- 
2.35.3

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


[PATCH 04/12] build: Improve value substitution

2022-06-29 Thread Sebastian Huber
The waf build system uses lists for tool flags.  The build items may use
variable substitution.  Add the ability to use the variable substitution in
lists.  For example:

MORE_FLAGS = ['-more', '-flags']

flags:
- -some-flag
- ${MORE_FLAGS}

Before this change, the ${MORE_FLAGS} was substituted to "-more -flags".  This
would be passed by waf as a single command line argument to the tool.

After this change, the ${MORE_FLAGS} list extends the flags list:

flags = ['-some-flag', '-more', '-flags']

This list extension is performed if a list element consists of exactly one
variable.

Update #4670.
---
 wscript | 25 -
 1 file changed, 16 insertions(+), 9 deletions(-)

diff --git a/wscript b/wscript
index 731d1402ff..6ad230aca5 100755
--- a/wscript
+++ b/wscript
@@ -115,6 +115,9 @@ class Template(string.Template):
 idpattern = "[_A-Za-z][_A-Za-z0-9:#]*"
 
 
+_VAR_PATTERN = re.compile("\$\{?(" + Template.idpattern + ")\}?$")
+
+
 def _is_enabled_op_and(enabled, enabled_by):
 for next_enabled_by in enabled_by:
 if not _is_enabled(enabled, next_enabled_by):
@@ -249,18 +252,22 @@ class Item(object):
 )
 )
 if isinstance(value, list):
-return [self.substitute(ctx, subvalue) for subvalue in value]
+more = []
+for item in value:
+if isinstance(item, str):
+m = _VAR_PATTERN.match(item)
+else:
+m = None
+if m:
+more.extend(ctx.env[m.group(1).strip("{}")])
+else:
+more.append(self.substitute(ctx, item))
+return more
 return value
 
 def get(self, ctx, name):
 return self.substitute(ctx, self.data[name])
 
-def get_values(self, ctx, name):
-more = []
-for value in self.data[name]:
-more.extend(self.substitute(ctx, value).split())
-return more
-
 def install_target(self, bld):
 install_path = self.data["install-path"]
 if install_path:
@@ -512,12 +519,12 @@ class GroupItem(Item):
 
 def prepare_build(self, bld, bic):
 return BuildItemContext(
-bic.includes + self.get_values(bld, "includes"),
+bic.includes + self.substitute(bld, self.data["includes"]),
 bic.cppflags,
 bic.cflags,
 bic.cxxflags,
 self.data["use-before"] + bic.use + self.data["use-after"],
-bic.ldflags + self.get_values(bld, "ldflags"),
+bic.ldflags + self.substitute(bld, self.data["ldflags"]),
 bic.objects,
 )
 
-- 
2.35.3

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


[PATCH 07/12] gcov: Add fork(), etc. gcov wrappers

2022-06-29 Thread Sebastian Huber
The compiler wraps fork(), etc. system calls if coverage generation is enabled.
These functions must be provided by the system.  For RTEMS, they just return an
error status.

Update #4670.
---
 cpukit/libcsupport/src/gcovfork.c | 94 +++
 spec/build/cpukit/librtemscpu.yml |  1 +
 2 files changed, 95 insertions(+)
 create mode 100644 cpukit/libcsupport/src/gcovfork.c

diff --git a/cpukit/libcsupport/src/gcovfork.c 
b/cpukit/libcsupport/src/gcovfork.c
new file mode 100644
index 00..763412d735
--- /dev/null
+++ b/cpukit/libcsupport/src/gcovfork.c
@@ -0,0 +1,94 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup libcsupport
+ *
+ * @brief This source file contains functions required by GCC if code and
+ *   branch coverage instrumentation (gcov) is enabled.
+ */
+
+/*
+ * Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+
+#include 
+
+#include 
+
+int __gcov_execl( const char *, char *, ... );
+
+int __gcov_execl( const char *path, char *arg, ... )
+{
+  rtems_set_errno_and_return_minus_one( ENOSYS );
+}
+
+int __gcov_execlp( const char *, char *, ... );
+
+int __gcov_execlp( const char *path, char *arg, ... )
+{
+  rtems_set_errno_and_return_minus_one( ENOSYS );
+}
+
+int __gcov_execle( const char *, char *, ... );
+
+int __gcov_execle( const char *path, char *arg, ... )
+{
+  rtems_set_errno_and_return_minus_one( ENOSYS );
+}
+
+int __gcov_execv( const char *, char *const[] );
+
+int __gcov_execv( const char *path, char *const argv[] )
+{
+  rtems_set_errno_and_return_minus_one( ENOSYS );
+}
+
+int __gcov_execvp( const char *, char *const[] );
+
+int __gcov_execvp( const char *path, char *const argv[] )
+{
+  rtems_set_errno_and_return_minus_one( ENOSYS );
+}
+
+int __gcov_execve( const char *, char *const[], char *const[] );
+
+int __gcov_execve( const char *path, char *const argv[], char *const envp[] )
+{
+  rtems_set_errno_and_return_minus_one( ENOSYS );
+}
+
+pid_t __gcov_fork( void );
+
+pid_t __gcov_fork( void )
+{
+  rtems_set_errno_and_return_minus_one( ENOSYS );
+}
diff --git a/spec/build/cpukit/librtemscpu.yml 
b/spec/build/cpukit/librtemscpu.yml
index 965419c389..4a8a0ee1ad 100644
--- a/spec/build/cpukit/librtemscpu.yml
+++ b/spec/build/cpukit/librtemscpu.yml
@@ -640,6 +640,7 @@ source:
 - cpukit/libcsupport/src/ftruncate.c
 - cpukit/libcsupport/src/ftrylockfile.c
 - cpukit/libcsupport/src/funlockfile.c
+- cpukit/libcsupport/src/gcovfork.c
 - cpukit/libcsupport/src/getchark.c
 - cpukit/libcsupport/src/getdents.c
 - cpukit/libcsupport/src/getegid.c
-- 
2.35.3

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


[PATCH 03/12] build: Fix identifier pattern

2022-06-29 Thread Sebastian Huber
Allow upper case characters in identifiers.

Update #4670.
---
 wscript | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/wscript b/wscript
index 38910f2816..731d1402ff 100755
--- a/wscript
+++ b/wscript
@@ -112,7 +112,7 @@ class EnvWrapper(object):
 
 
 class Template(string.Template):
-idpattern = "[_a-z][_a-z0-9:#]*"
+idpattern = "[_A-Za-z][_A-Za-z0-9:#]*"
 
 
 def _is_enabled_op_and(enabled, enabled_by):
-- 
2.35.3

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


Re: Congratulations to Two Core Developers

2022-06-28 Thread Vijay Kumar Banerjee
Congratulations, Gedare and Hesham!

I had the honor and privilege of working with both of you, and your
knowledge and passion have been a true inspiration to me.

Best,
Vijay

On Tue, Jun 28, 2022 at 8:23 AM Joel Sherrill  wrote:
>
> Hi
>
> I'd like to congratulate two RTEMS core developers on recent significant 
> achievements.
>
> (1) Gedare Bloom was granted tenure at the University of Colorado at Colorado 
> Springs.
>
> (2) Hesham Almatary has passed his Ph.D. viva/orals and is nearing graduation.
>
> These are both major life events and the RTEMS Community would like to 
> congratulate them.
>
> --joel
> ___
> 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


Congratulations to Two Core Developers

2022-06-28 Thread Joel Sherrill
Hi

I'd like to congratulate two RTEMS core developers on recent significant
achievements.

(1) Gedare Bloom was granted tenure at the University of Colorado at
Colorado Springs.

(2) Hesham Almatary has passed his Ph.D. viva/orals and is nearing
graduation.

These are both major life events and the RTEMS Community would like to
congratulate them.

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

[PATCH] bsps/xilinx-zynq: Init debug console only once

2022-06-28 Thread Sebastian Huber
Initialize the debug console only once during early system initialization.
---
 bsps/arm/xilinx-zynq/console/debug-console.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/bsps/arm/xilinx-zynq/console/debug-console.c 
b/bsps/arm/xilinx-zynq/console/debug-console.c
index 0e9b756f30..1423708bb7 100644
--- a/bsps/arm/xilinx-zynq/console/debug-console.c
+++ b/bsps/arm/xilinx-zynq/console/debug-console.c
@@ -52,10 +52,7 @@ static void zynq_debug_console_init(void)
 
 static void zynq_debug_console_early_init(char c)
 {
-  rtems_termios_device_context *base =
-_uart_instances[BSP_CONSOLE_MINOR].base;
-
-  zynq_uart_initialize(base);
+  zynq_debug_console_init();
   zynq_debug_console_out(c);
 }
 
-- 
2.35.3

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


Integrating the Formal Methods part of Qualification

2022-06-28 Thread andrew.butterfi...@scss.tcd.ie
Dear RTEMS Developers,

While the validation tests from the RTEMS pre-qualification activity are
now merged into the RTEMS master, the work done in investigating and 
deploying formal methods techniques is not yet merged.

The activity had two main phases: a planning phase (Nov 2018-Oct 2019) 
that explored various formal techniques, followed by an execution phase 
(Oct 2019-Nov 2021) that then applied selected techniques to selected 
parts of RTEMS. Some discussions occurred with the RTEMS community 
via the mailings lists over this time. A short third phase (Nov 2021 - Dec 
2021) 
then reported on the outcomes. Each phase resulted in a technical report.

The key decision made was to use Promela/SPIN for test generation, and 
to apply it to the Chains API, the Event Manager, and the SMP scheduler
thread queues. This involved developing models in the Promela language 
and using the SPIN model-checker tool to both check their correctness
and to generate execution scenarios that could be used to generate tests.
Tools were developed using Python 3.8 to support this. Initial documentation 
about tools and how to use them was put into the 2nd phase report.

We now come to the part where we explore the best way to integrate this
into RTEMS. I am proposing to do this under the guidance of Sebastian Huber.

The first suggested step is adding in new documentation to the RTEMS 
Software Engineering manual, as a new Formal Methods chapter. This would 
provide some motivation, as well as a "howto".

I assume that I would initially describe the proposed changes using the patch 
review process described in the section on Preparing and Sending Patches in 
the User Manual.

How do you feel I should best proceed?

Best regards,
  Andrew Butterfield,


Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204
Lero@TCD, Head of Software Foundations & Verification Research Group
School of Computer Science and Statistics,
Room G.39, O'Reilly Institute, Trinity College, University of Dublin
 http://www.scss.tcd.ie/Andrew.Butterfield/

 

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


Re: [PATCH] arm/gicv3: Fix building arm/r52

2022-06-27 Thread Kinsey Moore

On 6/27/2022 01:27, Sebastian Huber wrote:

On 27/06/2022 05:02, Chris Johns wrote:

On 24/6/2022 7:44 pm, Sebastian Huber wrote:

On 20.06.22 04:03, chr...@rtems.org wrote:

From: Chris Johns 

---
   bsps/include/dev/irq/arm-gicv3.h | 5 +
   1 file changed, 5 insertions(+)

diff --git a/bsps/include/dev/irq/arm-gicv3.h 
b/bsps/include/dev/irq/arm-gicv3.h

index a79368ebdf..aac02fa191 100644
--- a/bsps/include/dev/irq/arm-gicv3.h
+++ b/bsps/include/dev/irq/arm-gicv3.h
@@ -335,7 +335,12 @@ static void gicv3_init_cpu_interface(uint32_t 
cpu_index)

 }
       /* Enable interrupt groups 0 and 1 */
+#ifdef ARM_MULTILIB_ARCH_V4
+  WRITE_SR(ICC_IGRPEN0, 0x1);
+  WRITE_SR(ICC_IGRPEN1, 0x1);
+#else
 gic_icc_write(IGRPEN1, 1);
+#endif
 WRITE_SR(ICC_CTLR, 0x0);
   }


I have a different patch to fix this:

https://lists.rtems.org/pipermail/devel/2022-June/072056.html


Does this change work on a real aarch64 with a suitably configured 
TF-A? The
security profile of the TF-A needs to disable EL1 access to these 
registers to

see the issue.


I don't have a hardware to test this change. I can do tests on a 
Cortex-R52 hardware.


For the Cortex-R52, group 0 interrupts are signaled through FIQ 
exceptions and group 1 interrupts are signaled through IRQ exceptions. 
This processor has no secore/non-secure states.
I have reverified that this code works on my ZCU102 (ZynqMP) dev board 
with just the write to IGRPEN1, but I'm not sure it's what Chris would 
consider a suitably configured TF-A since it's a bit stale.



Kinsey

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

Re: [PATCH] irq/arm-gicv3.h: Enable interrupt groups 0 and 1

2022-06-27 Thread Kinsey Moore

On 6/26/2022 22:37, Chris Johns wrote:

On 24/6/2022 7:43 pm, Sebastian Huber wrote:

The GICv3 support is used by AArch32 (indicated by the ARM_MULTILIB_ARCH_V4
define) and AArch64 targets.  Use the existing WRITE_SR() abstraction to access
the interrupt group 0 and 1 enable registers.  This fixes the build for the
AArch32 target.

It needs to be tested on hardware before I am OK with it. It also needs EL3
firmware, ie TF-A, to correctly initialise a system.

I would be OK with qemu if it can be shown it honours the security level
correctly. I however have no time to determine this as I have Versal hardware
that did not like the changes.
I, unfortunately, have no way to test this on hardware but I would 
agree. I would not be inclined to trust qemu in this regard.

---
  bsps/include/dev/irq/arm-gicv3.h | 23 ++-
  1 file changed, 6 insertions(+), 17 deletions(-)

diff --git a/bsps/include/dev/irq/arm-gicv3.h b/bsps/include/dev/irq/arm-gicv3.h
index a79368ebdf..7db7bad034 100644
--- a/bsps/include/dev/irq/arm-gicv3.h
+++ b/bsps/include/dev/irq/arm-gicv3.h
@@ -116,9 +116,11 @@ extern "C" {
  #else /* ARM_MULTILIB_ARCH_V4 */
  
  /* AArch64 GICv3 registers are not named in GCC */

The FreeBSD would suggest this is not entirely true? May be it is for aarch32?
IIRC, a select few were named and usable in GCC, but the vast majority 
were not. This may have gotten better with more recent GCC releases 
since this comment was written more than 2 years ago.



-#define ICC_IGRPEN0 "S3_0_C12_C12_6, %0"
-#define ICC_IGRPEN1 "S3_0_C12_C12_7, %0"
+#define ICC_IGRPEN0_EL1 "S3_0_C12_C12_6, %0"
+#define ICC_IGRPEN1_EL1 "S3_0_C12_C12_7, %0"

This looks like it is only a label change and so it is the same opcode. Is that
correct?

According to the ARMv8 TRM, this is the full proper name for it.



  #define ICC_IGRPEN1_EL3 "S3_6_C12_C12_7, %0"
+#define ICC_IGRPEN0 ICC_IGRPEN0_EL1
+#define ICC_IGRPEN1 ICC_IGRPEN1_EL1
  #define ICC_PMR "S3_0_C4_C6_0, %0"
  #define ICC_EOIR1   "S3_0_C12_C12_1, %0"
  #define ICC_SRE "S3_0_C12_C12_5, %0"
@@ -300,20 +302,6 @@ static void gicv3_init_dist(volatile gic_dist *dist)
}
  }
  
-/*

- * A better way to access these registers than special opcodes
- */
-#define isb() __asm __volatile("isb" : : : "memory")
-
-#define  WRITE_SPECIALREG(reg, _val)\
-  __asm __volatile("msr  " __STRING(reg) ", %0" : : "r"((uint64_t)_val))
-
-#define  gic_icc_write(reg, val)\
-do {\
-  WRITE_SPECIALREG(icc_ ##reg ##_el1, val); \
-  isb();\
-} while (0)
-
  static void gicv3_init_cpu_interface(uint32_t cpu_index)
  {
uint32_t sre_value = 0x7;
@@ -335,7 +323,8 @@ static void gicv3_init_cpu_interface(uint32_t cpu_index)
}
  
/* Enable interrupt groups 0 and 1 */

-  gic_icc_write(IGRPEN1, 1);'

This has been tested and works on a Versal.


+  WRITE_SR(ICC_IGRPEN0, 0x1);

This crashed in EL1 on a Versal with 2021.2 TF-A.

Why do you need to set this here?


+  WRITE_SR(ICC_IGRPEN1, 0x1);

This instruction also generated an exception. It has been a while but I am
pretty sure I had to comment this one and when I did no interrupts happened. The
code I ported from FreeBSD worked.

I also think the FreeBSD calls are easier to review and so maintain. I find
those ARM type registers difficult to find and check.
The opcode S3_0_C12_C12_7 should be identical in behavior and assembly 
with the name ICC_IGRPEN1_EL1. It's spelled out in the ARMv8 TRM on 
D12-3006.


Kinsey

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


[PATCH 04/13] bsps/arm/beagle: Change license to BSD-2

2022-06-27 Thread Joel Sherrill
Updates #3053.
---
 bsps/arm/beagle/start/bspstart.c  | 25 ++---
 bsps/arm/beagle/start/bspstarthooks.c | 25 ++---
 2 files changed, 44 insertions(+), 6 deletions(-)

diff --git a/bsps/arm/beagle/start/bspstart.c b/bsps/arm/beagle/start/bspstart.c
index 8ad7a8cc36..83138f29dd 100644
--- a/bsps/arm/beagle/start/bspstart.c
+++ b/bsps/arm/beagle/start/bspstart.c
@@ -1,9 +1,28 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /*
  * Copyright (c) 2013 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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.
  */
 
 #include 
diff --git a/bsps/arm/beagle/start/bspstarthooks.c 
b/bsps/arm/beagle/start/bspstarthooks.c
index bdbdac29e6..3291c698b7 100644
--- a/bsps/arm/beagle/start/bspstarthooks.c
+++ b/bsps/arm/beagle/start/bspstarthooks.c
@@ -1,9 +1,28 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /*
  * Copyright (c) 2013 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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.
  */
 
 #include 
-- 
2.24.4

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


[PATCH 13/13] bsps/arm/realview-pbx-a9: Change license to BSD-2

2022-06-27 Thread Joel Sherrill
Updates #3053.
---
 .../realview-pbx-a9/console/console-config.c  | 25 ---
 .../realview-pbx-a9/console/console-polled.c  | 25 ---
 bsps/arm/realview-pbx-a9/include/bsp.h| 25 ---
 .../arm/realview-pbx-a9/include/bsp/console.h | 25 ---
 bsps/arm/realview-pbx-a9/include/bsp/irq.h| 25 ---
 bsps/arm/realview-pbx-a9/include/tm27.h   | 25 ---
 bsps/arm/realview-pbx-a9/start/bspreset.c | 25 ---
 bsps/arm/realview-pbx-a9/start/bspsmp.c   | 25 ---
 bsps/arm/realview-pbx-a9/start/bspstart.c | 25 ---
 .../arm/realview-pbx-a9/start/bspstarthooks.c | 25 ---
 bsps/arm/realview-pbx-a9/start/fb-config.c| 25 ---
 11 files changed, 242 insertions(+), 33 deletions(-)

diff --git a/bsps/arm/realview-pbx-a9/console/console-config.c 
b/bsps/arm/realview-pbx-a9/console/console-config.c
index 73523660a5..17fe7ef3cb 100644
--- a/bsps/arm/realview-pbx-a9/console/console-config.c
+++ b/bsps/arm/realview-pbx-a9/console/console-config.c
@@ -1,9 +1,28 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /*
  * Copyright (c) 2013-2014 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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.
  */
 
 #include 
diff --git a/bsps/arm/realview-pbx-a9/console/console-polled.c 
b/bsps/arm/realview-pbx-a9/console/console-polled.c
index 2b6044846c..25f4583cf2 100644
--- a/bsps/arm/realview-pbx-a9/console/console-polled.c
+++ b/bsps/arm/realview-pbx-a9/console/console-polled.c
@@ -1,9 +1,28 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /*
  * Copyright (c) 2013, 2018 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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.
  */
 
 #include 
diff --git a/bsps/arm/realview-pbx-a9/include/bsp.h 
b/bsps/arm/realview-pbx-a9/include/bsp.h
index 39023c3c91..d49c97663a 100644
--- a/bsps/arm/realview-pbx-a9/include/bsp.h
+++ b/bsps/arm/realview-pbx-a9/include/bsp.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
@@ -9,9 

[PATCH 11/13] bsps/arm/lpc32xx: Change license to BSD-2

2022-06-27 Thread Joel Sherrill
Updates #3053.
---
 bsps/arm/lpc32xx/console/console-config.c | 25 ---
 bsps/arm/lpc32xx/console/hsu.c| 25 ---
 bsps/arm/lpc32xx/i2c/i2c.c| 25 ---
 bsps/arm/lpc32xx/include/bsp.h| 25 ---
 bsps/arm/lpc32xx/include/bsp/boot.h   | 25 ---
 bsps/arm/lpc32xx/include/bsp/emc.h| 25 ---
 bsps/arm/lpc32xx/include/bsp/hsu.h| 25 ---
 bsps/arm/lpc32xx/include/bsp/i2c.h| 25 ---
 bsps/arm/lpc32xx/include/bsp/irq.h| 25 ---
 .../lpc32xx/include/bsp/lpc-clock-config.h| 25 ---
 .../lpc32xx/include/bsp/lpc-ethernet-config.h | 25 ---
 bsps/arm/lpc32xx/include/bsp/mmu.h| 25 ---
 bsps/arm/lpc32xx/include/tm27.h   | 25 ---
 bsps/arm/lpc32xx/irq/irq.c| 25 ---
 .../lpc32xx/nand/nand-mlc-erase-block-safe.c  | 25 ---
 bsps/arm/lpc32xx/nand/nand-mlc-read-blocks.c  | 25 ---
 bsps/arm/lpc32xx/nand/nand-mlc-write-blocks.c | 25 ---
 bsps/arm/lpc32xx/nand/nand-mlc.c  | 25 ---
 bsps/arm/lpc32xx/nand/nand-select.c   | 25 ---
 bsps/arm/lpc32xx/rtc/rtc-config.c | 25 ---
 bsps/arm/lpc32xx/start/boot.c | 25 ---
 bsps/arm/lpc32xx/start/bspidle.c  | 25 ---
 bsps/arm/lpc32xx/start/bspreset.c | 25 ---
 bsps/arm/lpc32xx/start/bspstart.c | 25 ---
 bsps/arm/lpc32xx/start/bspstarthooks.c| 25 ---
 bsps/arm/lpc32xx/start/emc.c  | 25 ---
 bsps/arm/lpc32xx/start/restart.c  | 25 ---
 bsps/arm/lpc32xx/start/system-clocks.c| 25 ---
 bsps/arm/lpc32xx/start/timer.c| 25 ---
 29 files changed, 638 insertions(+), 87 deletions(-)

diff --git a/bsps/arm/lpc32xx/console/console-config.c 
b/bsps/arm/lpc32xx/console/console-config.c
index 9d7b76fe9a..f89d8af66e 100644
--- a/bsps/arm/lpc32xx/console/console-config.c
+++ b/bsps/arm/lpc32xx/console/console-config.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
@@ -9,9 +11,26 @@
 /*
  * Copyright (c) 2009-2014 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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.
  */
 
 #include 
diff --git a/bsps/arm/lpc32xx/console/hsu.c b/bsps/arm/lpc32xx/console/hsu.c
index 5f0a42a797..9181d6f734 100644
--- a/bsps/arm/lpc32xx/console/hsu.c
+++ b/bsps/arm/lpc32xx/console/hsu.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
@@ -9,9 +11,26 @@
 /*
  * Copyright (c) 2010-2014 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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 

[PATCH 10/13] bsps/arm/lpc24xx: Change license to BSD-2

2022-06-27 Thread Joel Sherrill
Updates #3053.
---
 bsps/arm/lpc24xx/console/console-config.c | 25 ---
 bsps/arm/lpc24xx/console/uart-probe-1.c   | 25 ---
 bsps/arm/lpc24xx/console/uart-probe-2.c   | 25 ---
 bsps/arm/lpc24xx/console/uart-probe-3.c   | 25 ---
 bsps/arm/lpc24xx/fb/lcd.c | 25 ---
 bsps/arm/lpc24xx/include/bsp.h| 25 ---
 bsps/arm/lpc24xx/include/bsp/dma.h| 25 ---
 bsps/arm/lpc24xx/include/bsp/io.h | 25 ---
 bsps/arm/lpc24xx/include/bsp/irq.h| 25 ---
 bsps/arm/lpc24xx/include/bsp/lcd.h| 25 ---
 .../lpc24xx/include/bsp/lpc-clock-config.h| 25 ---
 .../lpc24xx/include/bsp/lpc-ethernet-config.h | 25 ---
 bsps/arm/lpc24xx/include/bsp/lpc17xx.h| 25 ---
 bsps/arm/lpc24xx/include/bsp/lpc24xx.h| 25 ---
 bsps/arm/lpc24xx/include/bsp/start-config.h   | 25 ---
 bsps/arm/lpc24xx/include/bsp/system-clocks.h  | 25 ---
 bsps/arm/lpc24xx/irq/irq-dispatch.c   | 25 ---
 bsps/arm/lpc24xx/irq/irq.c| 25 ---
 bsps/arm/lpc24xx/rtc/rtc-config.c | 25 ---
 bsps/arm/lpc24xx/start/bspidle.c  | 25 ---
 bsps/arm/lpc24xx/start/bspreset-armv4.c   | 25 ---
 bsps/arm/lpc24xx/start/bspstart.c | 25 ---
 bsps/arm/lpc24xx/start/bspstarthooks.c| 25 ---
 bsps/arm/lpc24xx/start/dma-copy.c | 25 ---
 bsps/arm/lpc24xx/start/dma.c  | 25 ---
 bsps/arm/lpc24xx/start/fb-config.c| 25 ---
 bsps/arm/lpc24xx/start/io.c   | 25 ---
 bsps/arm/lpc24xx/start/restart.c  | 25 ---
 .../lpc24xx/start/start-config-emc-dynamic.c  | 25 ---
 .../lpc24xx/start/start-config-emc-static.c   | 25 ---
 bsps/arm/lpc24xx/start/start-config-mpu.c | 25 ---
 bsps/arm/lpc24xx/start/start-config-pinsel.c  | 25 ---
 bsps/arm/lpc24xx/start/system-clocks.c| 25 ---
 bsps/arm/lpc24xx/start/timer.c| 25 ---
 34 files changed, 748 insertions(+), 102 deletions(-)

diff --git a/bsps/arm/lpc24xx/console/console-config.c 
b/bsps/arm/lpc24xx/console/console-config.c
index 2ca3426468..0160bfcd55 100644
--- a/bsps/arm/lpc24xx/console/console-config.c
+++ b/bsps/arm/lpc24xx/console/console-config.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
@@ -9,9 +11,26 @@
 /*
  * Copyright (c) 2008-2014 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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.
  */
 
 #include 
diff --git a/bsps/arm/lpc24xx/console/uart-probe-1.c 
b/bsps/arm/lpc24xx/console/uart-probe-1.c
index 8a4c148a0d..b6ec6e1e0d 100644
--- a/bsps/arm/lpc24xx/console/uart-probe-1.c
+++ b/bsps/arm/lpc24xx/console/uart-probe-1.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
@@ -9,9 +11,26 @@
 /*
  * Copyright (c) 2011-2014 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * 

[PATCH 12/13] bsps/arm/raspberrypi: Change license to BSD-2

2022-06-27 Thread Joel Sherrill
Updates #3053.
---
 bsps/arm/raspberrypi/start/bspsmp.c  | 25 +---
 bsps/arm/raspberrypi/start/bspsmp_init.c | 25 +---
 2 files changed, 44 insertions(+), 6 deletions(-)

diff --git a/bsps/arm/raspberrypi/start/bspsmp.c 
b/bsps/arm/raspberrypi/start/bspsmp.c
index 9dcfb0fb03..0ea54c1442 100644
--- a/bsps/arm/raspberrypi/start/bspsmp.c
+++ b/bsps/arm/raspberrypi/start/bspsmp.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
@@ -18,9 +20,26 @@
  * GSoC 2015 project and Altera Cyclone-V SMP code
  * by embedded brains GmbH
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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.
  */
 
 #include 
diff --git a/bsps/arm/raspberrypi/start/bspsmp_init.c 
b/bsps/arm/raspberrypi/start/bspsmp_init.c
index eed5b44fa9..600eb63d47 100644
--- a/bsps/arm/raspberrypi/start/bspsmp_init.c
+++ b/bsps/arm/raspberrypi/start/bspsmp_init.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
@@ -18,9 +20,26 @@
  * GSoC 2015 project and Altera Cyclone-V SMP code
  * by embedded brains GmbH
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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.
  */
 
 #include 
-- 
2.24.4

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


[PATCH 08/13] bsps/arm/lpc176x: Change license to BSD-2

2022-06-27 Thread Joel Sherrill
Updates #3053.
---
 bsps/arm/lpc176x/console/console-config.c | 25 ---
 bsps/arm/lpc176x/include/bsp.h| 25 ---
 bsps/arm/lpc176x/include/bsp/dma.h| 25 ---
 bsps/arm/lpc176x/include/bsp/irq.h| 25 ---
 .../lpc176x/include/bsp/lpc-clock-config.h| 25 ---
 bsps/arm/lpc176x/include/bsp/system-clocks.h  | 25 ---
 bsps/arm/lpc176x/irq/irq.c| 25 ---
 bsps/arm/lpc176x/rtc/rtc-config.c | 25 ---
 bsps/arm/lpc176x/start/bspidle.c  | 25 ---
 bsps/arm/lpc176x/start/bspstart.c | 25 ---
 bsps/arm/lpc176x/start/dma-copy.c | 25 ---
 bsps/arm/lpc176x/start/dma.c  | 25 ---
 bsps/arm/lpc176x/start/restart.c  | 25 ---
 bsps/arm/lpc176x/start/system-clocks.c| 25 ---
 14 files changed, 308 insertions(+), 42 deletions(-)

diff --git a/bsps/arm/lpc176x/console/console-config.c 
b/bsps/arm/lpc176x/console/console-config.c
index 17bc0c5bfc..6cb77874fc 100644
--- a/bsps/arm/lpc176x/console/console-config.c
+++ b/bsps/arm/lpc176x/console/console-config.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
@@ -9,9 +11,26 @@
 /*
  * Copyright (c) 2008-2014 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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.
  */
 
 #include 
diff --git a/bsps/arm/lpc176x/include/bsp.h b/bsps/arm/lpc176x/include/bsp.h
index 4acff24abf..f2865f39b1 100644
--- a/bsps/arm/lpc176x/include/bsp.h
+++ b/bsps/arm/lpc176x/include/bsp.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
@@ -9,9 +11,26 @@
 /*
  * Copyright (c) 2008-2013 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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 LIBBSP_ARM_LPC176X_BSP_H
diff --git a/bsps/arm/lpc176x/include/bsp/dma.h 
b/bsps/arm/lpc176x/include/bsp/dma.h
index ec72a6ea34..10117eb209 

[PATCH 09/13] bsps/arm/imxrt: Change license to BSD-2

2022-06-27 Thread Joel Sherrill
Updates #3053.
---
 bsps/arm/imxrt/start/bspstarthooks.c | 25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

diff --git a/bsps/arm/imxrt/start/bspstarthooks.c 
b/bsps/arm/imxrt/start/bspstarthooks.c
index 244c13b063..684c263152 100644
--- a/bsps/arm/imxrt/start/bspstarthooks.c
+++ b/bsps/arm/imxrt/start/bspstarthooks.c
@@ -1,9 +1,28 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /*
  * Copyright (c) 2013, 2018 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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.
  */
 
 #include 
-- 
2.24.4

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


[PATCH 07/13] bsps/arm/include: Change license to BSD-2

2022-06-27 Thread Joel Sherrill
Updates #3053.
---
 bsps/arm/include/bsp/arm-a9mpcore-clock.h | 25 ---
 bsps/arm/include/bsp/arm-a9mpcore-irq.h   | 25 ---
 bsps/arm/include/bsp/arm-a9mpcore-regs.h  | 25 ---
 bsps/arm/include/bsp/arm-a9mpcore-start.h | 25 ---
 bsps/arm/include/bsp/arm-errata.h | 25 ---
 bsps/arm/include/bsp/arm-pl050-regs.h | 25 ---
 bsps/arm/include/bsp/arm-pl050.h  | 25 ---
 bsps/arm/include/bsp/arm-pl111-fb.h   | 25 ---
 bsps/arm/include/bsp/arm-pl111-regs.h | 25 ---
 bsps/arm/include/bsp/arm-release-id.h | 25 ---
 bsps/arm/include/bsp/linker-symbols.h | 25 ---
 bsps/arm/include/bsp/lpc-dma.h| 25 ---
 bsps/arm/include/bsp/lpc-emc.h| 25 ---
 bsps/arm/include/bsp/lpc-i2s.h| 25 ---
 bsps/arm/include/bsp/lpc-lcd.h| 25 ---
 bsps/arm/include/bsp/lpc-timer.h  | 25 ---
 bsps/arm/include/bsp/start.h  | 25 ---
 17 files changed, 374 insertions(+), 51 deletions(-)

diff --git a/bsps/arm/include/bsp/arm-a9mpcore-clock.h 
b/bsps/arm/include/bsp/arm-a9mpcore-clock.h
index 8d6007ba03..80e3ca4934 100644
--- a/bsps/arm/include/bsp/arm-a9mpcore-clock.h
+++ b/bsps/arm/include/bsp/arm-a9mpcore-clock.h
@@ -1,9 +1,28 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /*
  * Copyright (c) 2013 Chris Johns .  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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 LIBBSP_ARM_SHARED_ARM_A9MPCORE_CLOCK_H
diff --git a/bsps/arm/include/bsp/arm-a9mpcore-irq.h 
b/bsps/arm/include/bsp/arm-a9mpcore-irq.h
index 60ba9f78e4..7b0f497498 100644
--- a/bsps/arm/include/bsp/arm-a9mpcore-irq.h
+++ b/bsps/arm/include/bsp/arm-a9mpcore-irq.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  *  @file
  *
@@ -9,9 +11,26 @@
 /*
  * Copyright (c) 2013 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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 

[PATCH 06/13] bsps/arm/imx: Change license to BSD-2

2022-06-27 Thread Joel Sherrill
Updates #3053.
---
 bsps/arm/imx/console/console-config.c | 25 ---
 bsps/arm/imx/i2c/imx-i2c.c| 25 ---
 .../include/arm/freescale/imx/imx_ecspireg.h  | 25 ---
 .../include/arm/freescale/imx/imx_gpcreg.h| 25 ---
 .../include/arm/freescale/imx/imx_i2creg.h| 25 ---
 .../include/arm/freescale/imx/imx_srcreg.h| 25 ---
 .../include/arm/freescale/imx/imx_uartreg.h   | 25 ---
 bsps/arm/imx/include/bsp.h| 25 ---
 bsps/arm/imx/include/bsp/irq.h| 25 ---
 bsps/arm/imx/include/tm27.h   | 25 ---
 bsps/arm/imx/spi/imx-ecspi.c  | 25 ---
 bsps/arm/imx/start/bspreset.c | 25 ---
 bsps/arm/imx/start/bspsmp.c   | 25 ---
 bsps/arm/imx/start/bspstart.c | 25 ---
 bsps/arm/imx/start/bspstarthooks.c| 25 ---
 bsps/arm/imx/start/ccm.c  | 25 ---
 16 files changed, 352 insertions(+), 48 deletions(-)

diff --git a/bsps/arm/imx/console/console-config.c 
b/bsps/arm/imx/console/console-config.c
index a65d7bff9f..e9e00eb421 100644
--- a/bsps/arm/imx/console/console-config.c
+++ b/bsps/arm/imx/console/console-config.c
@@ -1,9 +1,28 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /*
  * Copyright (c) 2017 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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.
  */
 
 #include 
diff --git a/bsps/arm/imx/i2c/imx-i2c.c b/bsps/arm/imx/i2c/imx-i2c.c
index a545a2913d..6799e98827 100644
--- a/bsps/arm/imx/i2c/imx-i2c.c
+++ b/bsps/arm/imx/i2c/imx-i2c.c
@@ -1,9 +1,28 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /*
  * Copyright (c) 2017 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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.
  */
 
 #include 
diff --git a/bsps/arm/imx/include/arm/freescale/imx/imx_ecspireg.h 

[PATCH 05/13] bsps/arm/csb337: Change license to BSD-2

2022-06-27 Thread Joel Sherrill
Updates #3053.
---
 bsps/arm/csb337/console/fbcons.c | 25 ++---
 bsps/arm/csb337/include/sed1356.h| 25 ++---
 bsps/arm/csb337/start/umonsupp.c | 25 ++---
 bsps/arm/csb337/umon/tfsDriver.c | 25 ++---
 bsps/arm/csb337/umon/umoncons.c  | 25 ++---
 bsps/arm/csb337/umon/umonrtemsglue.c | 25 ++---
 6 files changed, 132 insertions(+), 18 deletions(-)

diff --git a/bsps/arm/csb337/console/fbcons.c b/bsps/arm/csb337/console/fbcons.c
index 62e840938d..b53307436a 100644
--- a/bsps/arm/csb337/console/fbcons.c
+++ b/bsps/arm/csb337/console/fbcons.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /*
  *  LCD Console Output Driver for CSBx37
  */
@@ -9,9 +11,26 @@
  *  Modified by Fernando Nicodemos 
  *  from NCB - Sistemas Embarcados Ltda. (Brazil)
  *
- *  The license and distribution terms for this file may be
- *  found in the file LICENSE in this distribution or at
- *  http://www.rtems.org/license/LICENSE.
+ * 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.
  */
 
 #include 
diff --git a/bsps/arm/csb337/include/sed1356.h 
b/bsps/arm/csb337/include/sed1356.h
index 583a2a3a77..54ec2dfeee 100644
--- a/bsps/arm/csb337/include/sed1356.h
+++ b/bsps/arm/csb337/include/sed1356.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
@@ -23,9 +25,26 @@
  *  Modified by Fernando Nicodemos 
  *  from NCB - Sistemas Embarcados Ltda. (Brazil)
  *
- *  The license and distribution terms for this file may be
- *  found in the file LICENSE in this distribution or at
- *  http://www.rtems.org/license/LICENSE.
+ * 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 __SED1356_h
diff --git a/bsps/arm/csb337/start/umonsupp.c b/bsps/arm/csb337/start/umonsupp.c
index d4bf731c5d..0f0ebafcc9 100644
--- a/bsps/arm/csb337/start/umonsupp.c
+++ b/bsps/arm/csb337/start/umonsupp.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /*
  *  COPYRIGHT (c) 1989-2009.
  *  On-Line Applications Research Corporation (OAR).
@@ -5,9 +7,26 @@
  *  Modified by Fernando Nicodemos 
  *  from NCB - Sistemas Embarcados Ltda. (Brazil)
  *
- *  The license and distribution terms for this file may be
- *  found in the file LICENSE in this distribution or at
- *  http://www.rtems.org/license/LICENSE.
+ * Redistribution and use in source and binary forms, with or 

[PATCH 03/13] bsps/arm/atsamv: Change license to BSD-2

2022-06-27 Thread Joel Sherrill
Updates #3053.
---
 bsps/arm/atsam/clock/systick-freq.c   | 25 ---
 bsps/arm/atsam/console/console.c  | 25 ---
 bsps/arm/atsam/console/debug-console.c| 25 ---
 bsps/arm/atsam/i2c/atsam_i2c_bus.c| 25 ---
 bsps/arm/atsam/i2c/atsam_i2c_init.c   | 25 ---
 bsps/arm/atsam/include/bsp.h  | 25 ---
 .../atsam/include/bsp/atsam-clock-config.h| 25 ---
 bsps/arm/atsam/include/bsp/atsam-i2c.h| 25 ---
 bsps/arm/atsam/include/bsp/atsam-spi.h| 25 ---
 bsps/arm/atsam/include/bsp/i2c.h  | 25 ---
 bsps/arm/atsam/include/bsp/iocopy.h   | 25 ---
 bsps/arm/atsam/include/bsp/irq.h  | 25 ---
 bsps/arm/atsam/include/bsp/pin-config.h   | 25 ---
 bsps/arm/atsam/include/bsp/power.h| 25 ---
 bsps/arm/atsam/include/bsp/sc16is752.h| 25 ---
 bsps/arm/atsam/include/bsp/spi.h  | 25 ---
 bsps/arm/atsam/rtc/rtc-config.c   | 25 ---
 bsps/arm/atsam/spi/atsam_spi_init.c   | 25 ---
 bsps/arm/atsam/spi/sc16is752.c| 25 ---
 bsps/arm/atsam/start/bspstart.c   | 25 ---
 bsps/arm/atsam/start/bspstarthooks.c  | 25 ---
 bsps/arm/atsam/start/getentropy-trng.c| 25 ---
 bsps/arm/atsam/start/iocopy.c | 25 ---
 bsps/arm/atsam/start/pin-config.c | 25 ---
 bsps/arm/atsam/start/pmc-config.c | 25 ---
 bsps/arm/atsam/start/power-clock.c| 25 ---
 bsps/arm/atsam/start/power-rtc.c  | 25 ---
 bsps/arm/atsam/start/power.c  | 25 ---
 bsps/arm/atsam/start/restart.c| 25 ---
 bsps/arm/atsam/start/sdram-config.c   | 25 ---
 30 files changed, 660 insertions(+), 90 deletions(-)

diff --git a/bsps/arm/atsam/clock/systick-freq.c 
b/bsps/arm/atsam/clock/systick-freq.c
index f89c66419f..87f6c2df59 100644
--- a/bsps/arm/atsam/clock/systick-freq.c
+++ b/bsps/arm/atsam/clock/systick-freq.c
@@ -1,9 +1,28 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /*
  * Copyright (c) 2016 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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.
  */
 
 #include 
diff --git a/bsps/arm/atsam/console/console.c b/bsps/arm/atsam/console/console.c
index 7ed41d84b3..189c42e47d 100644
--- a/bsps/arm/atsam/console/console.c
+++ b/bsps/arm/atsam/console/console.c
@@ -1,9 +1,28 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /*
  * Copyright (c) 2016 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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 

[PATCH 02/13] bsps/arm/altera-cyclone-v: Change license to BSD-2

2022-06-27 Thread Joel Sherrill
Updates #3053.
---
 .../altera-cyclone-v/console/console-config.c | 25 ---
 bsps/arm/altera-cyclone-v/i2c/i2cdrv-config.c | 25 ---
 bsps/arm/altera-cyclone-v/i2c/i2cdrv-config.h | 25 ---
 bsps/arm/altera-cyclone-v/i2c/i2cdrv.c| 25 ---
 bsps/arm/altera-cyclone-v/include/bsp.h   | 25 ---
 .../arm/altera-cyclone-v/include/bsp/i2cdrv.h | 25 ---
 bsps/arm/altera-cyclone-v/include/bsp/irq.h   | 25 ---
 bsps/arm/altera-cyclone-v/include/tm27.h  | 25 ---
 bsps/arm/altera-cyclone-v/rtc/rtc.c   | 25 ---
 bsps/arm/altera-cyclone-v/start/bspclean.c| 25 ---
 bsps/arm/altera-cyclone-v/start/bspreset.c| 25 ---
 bsps/arm/altera-cyclone-v/start/bspsmp.c  | 25 ---
 bsps/arm/altera-cyclone-v/start/bspstart.c| 25 ---
 .../altera-cyclone-v/start/bspstarthooks.c| 25 ---
 bsps/arm/altera-cyclone-v/start/mmu-config.c  | 25 ---
 15 files changed, 330 insertions(+), 45 deletions(-)

diff --git a/bsps/arm/altera-cyclone-v/console/console-config.c 
b/bsps/arm/altera-cyclone-v/console/console-config.c
index 283cda20a2..b19748e653 100644
--- a/bsps/arm/altera-cyclone-v/console/console-config.c
+++ b/bsps/arm/altera-cyclone-v/console/console-config.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
@@ -7,9 +9,26 @@
 /*
  * Copyright (c) 2013-2014 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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.
  */
 
 #include 
diff --git a/bsps/arm/altera-cyclone-v/i2c/i2cdrv-config.c 
b/bsps/arm/altera-cyclone-v/i2c/i2cdrv-config.c
index f596075a58..61c7a1a411 100644
--- a/bsps/arm/altera-cyclone-v/i2c/i2cdrv-config.c
+++ b/bsps/arm/altera-cyclone-v/i2c/i2cdrv-config.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
@@ -7,9 +9,26 @@
 /*
  * Copyright (c) 2014 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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 

[PATCH 00/13] Change license of ARM BSPs to BSD-2

2022-06-27 Thread Joel Sherrill
Hi

This patch set is generated by scripting which looks for files with the
RTEMS GPL, a single copyright line, and written by OAR, embedded brains,
Chris Johns, or Gedare Bloom. This is a good first step at relicensing
the easy to recognize files.

After doing this to all architectures, the next step will be to make a
similar pass for more submitters. And then unfortunately to continue to
track down people.

--joel

Joel Sherrill (13):
  bsps/arm/shared: Change license to BSD-2
  bsps/arm/altera-cyclone-v: Change license to BSD-2
  bsps/arm/atsamv: Change license to BSD-2
  bsps/arm/beagle: Change license to BSD-2
  bsps/arm/csb337: Change license to BSD-2
  bsps/arm/imx: Change license to BSD-2
  bsps/arm/include: Change license to BSD-2
  bsps/arm/lpc176x: Change license to BSD-2
  bsps/arm/imxrt: Change license to BSD-2
  bsps/arm/lpc24xx: Change license to BSD-2
  bsps/arm/lpc32xx: Change license to BSD-2
  bsps/arm/raspberrypi: Change license to BSD-2
  bsps/arm/realview-pbx-a9: Change license to BSD-2

 .../altera-cyclone-v/console/console-config.c | 25 ---
 bsps/arm/altera-cyclone-v/i2c/i2cdrv-config.c | 25 ---
 bsps/arm/altera-cyclone-v/i2c/i2cdrv-config.h | 25 ---
 bsps/arm/altera-cyclone-v/i2c/i2cdrv.c| 25 ---
 bsps/arm/altera-cyclone-v/include/bsp.h   | 25 ---
 .../arm/altera-cyclone-v/include/bsp/i2cdrv.h | 25 ---
 bsps/arm/altera-cyclone-v/include/bsp/irq.h   | 25 ---
 bsps/arm/altera-cyclone-v/include/tm27.h  | 25 ---
 bsps/arm/altera-cyclone-v/rtc/rtc.c   | 25 ---
 bsps/arm/altera-cyclone-v/start/bspclean.c| 25 ---
 bsps/arm/altera-cyclone-v/start/bspreset.c| 25 ---
 bsps/arm/altera-cyclone-v/start/bspsmp.c  | 25 ---
 bsps/arm/altera-cyclone-v/start/bspstart.c| 25 ---
 .../altera-cyclone-v/start/bspstarthooks.c| 25 ---
 bsps/arm/altera-cyclone-v/start/mmu-config.c  | 25 ---
 bsps/arm/atsam/clock/systick-freq.c   | 25 ---
 bsps/arm/atsam/console/console.c  | 25 ---
 bsps/arm/atsam/console/debug-console.c| 25 ---
 bsps/arm/atsam/i2c/atsam_i2c_bus.c| 25 ---
 bsps/arm/atsam/i2c/atsam_i2c_init.c   | 25 ---
 bsps/arm/atsam/include/bsp.h  | 25 ---
 .../atsam/include/bsp/atsam-clock-config.h| 25 ---
 bsps/arm/atsam/include/bsp/atsam-i2c.h| 25 ---
 bsps/arm/atsam/include/bsp/atsam-spi.h| 25 ---
 bsps/arm/atsam/include/bsp/i2c.h  | 25 ---
 bsps/arm/atsam/include/bsp/iocopy.h   | 25 ---
 bsps/arm/atsam/include/bsp/irq.h  | 25 ---
 bsps/arm/atsam/include/bsp/pin-config.h   | 25 ---
 bsps/arm/atsam/include/bsp/power.h| 25 ---
 bsps/arm/atsam/include/bsp/sc16is752.h| 25 ---
 bsps/arm/atsam/include/bsp/spi.h  | 25 ---
 bsps/arm/atsam/rtc/rtc-config.c   | 25 ---
 bsps/arm/atsam/spi/atsam_spi_init.c   | 25 ---
 bsps/arm/atsam/spi/sc16is752.c| 25 ---
 bsps/arm/atsam/start/bspstart.c   | 25 ---
 bsps/arm/atsam/start/bspstarthooks.c  | 25 ---
 bsps/arm/atsam/start/getentropy-trng.c| 25 ---
 bsps/arm/atsam/start/iocopy.c | 25 ---
 bsps/arm/atsam/start/pin-config.c | 25 ---
 bsps/arm/atsam/start/pmc-config.c | 25 ---
 bsps/arm/atsam/start/power-clock.c| 25 ---
 bsps/arm/atsam/start/power-rtc.c  | 25 ---
 bsps/arm/atsam/start/power.c  | 25 ---
 bsps/arm/atsam/start/restart.c| 25 ---
 bsps/arm/atsam/start/sdram-config.c   | 25 ---
 bsps/arm/beagle/start/bspstart.c  | 25 ---
 bsps/arm/beagle/start/bspstarthooks.c | 25 ---
 bsps/arm/csb337/console/fbcons.c  | 25 ---
 bsps/arm/csb337/include/sed1356.h | 25 ---
 bsps/arm/csb337/start/umonsupp.c  | 25 ---
 bsps/arm/csb337/umon/tfsDriver.c  | 25 ---
 bsps/arm/csb337/umon/umoncons.c   | 25 ---
 bsps/arm/csb337/umon/umonrtemsglue.c  | 25 ---
 bsps/arm/imx/console/console-config.c | 25 ---
 bsps/arm/imx/i2c/imx-i2c.c| 25 ---
 

[PATCH 01/13] bsps/arm/shared: Change license to BSD-2

2022-06-27 Thread Joel Sherrill
Updates #3053.
---
 bsps/arm/shared/cache/cache-cp15.c| 25 ---
 bsps/arm/shared/cache/cache-cp15.h| 25 ---
 bsps/arm/shared/cache/cache-v7m.c | 25 ---
 bsps/arm/shared/clock/clock-a9mpcore.c| 25 ---
 bsps/arm/shared/clock/clock-nxp-lpc.c | 25 ---
 .../cp15/arm-cp15-set-exception-handler.c | 25 ---
 .../shared/cp15/arm-cp15-set-ttb-entries.c| 25 ---
 .../arm/shared/cpucounter/cpucounter-armv7m.c | 25 ---
 bsps/arm/shared/fb/arm-pl111.c| 25 ---
 bsps/arm/shared/serial/arm-pl050.c| 25 ---
 bsps/arm/shared/start/arm-a9mpcore-smp.c  | 25 ---
 bsps/arm/shared/start/bsp-start-memcpy.S  | 25 ---
 bsps/arm/shared/start/bspreset-armv7m.c   | 25 ---
 13 files changed, 286 insertions(+), 39 deletions(-)

diff --git a/bsps/arm/shared/cache/cache-cp15.c 
b/bsps/arm/shared/cache/cache-cp15.c
index 9a58146277..4ad9965529 100644
--- a/bsps/arm/shared/cache/cache-cp15.c
+++ b/bsps/arm/shared/cache/cache-cp15.c
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @file
  *
@@ -9,9 +11,26 @@
 /*
  * Copyright (C) 2009, 2018 embedded brains GmbH
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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.
  */
 
 #include 
diff --git a/bsps/arm/shared/cache/cache-cp15.h 
b/bsps/arm/shared/cache/cache-cp15.h
index 8d2d2c9fe2..0e1297a84d 100644
--- a/bsps/arm/shared/cache/cache-cp15.h
+++ b/bsps/arm/shared/cache/cache-cp15.h
@@ -1,3 +1,5 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /**
  * @ingroup RTEMSBSPsARMShared
  *
@@ -9,9 +11,26 @@
 /*
  * Copyright (c) 2014 embedded brains GmbH.  All rights reserved.
  *
- * The license and distribution terms for this file may be
- * found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
+ * 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 LIBBSP_ARM_SHARED_CACHE_L1_H
diff --git a/bsps/arm/shared/cache/cache-v7m.c 
b/bsps/arm/shared/cache/cache-v7m.c
index f5a9e208e5..ee68e7f9db 100644
--- a/bsps/arm/shared/cache/cache-v7m.c
+++ 

  1   2   3   4   5   6   7   8   9   10   >