[PATCH 2/5] bsps/xilinx_zynq: Add cadence SPI driver to build system

2021-03-31 Thread Jan Sommer 
Closes #4369
---
 bsps/arm/headers.am| 2 ++
 c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am   | 3 +++
 c/src/lib/libbsp/arm/xilinx-zynqmp/Makefile.am | 3 +++
 3 files changed, 8 insertions(+)

diff --git a/bsps/arm/headers.am b/bsps/arm/headers.am
index 3d2b09effa..007412fee0 100644
--- a/bsps/arm/headers.am
+++ b/bsps/arm/headers.am
@@ -39,6 +39,8 @@ include_bsp_HEADERS += 
../../../../../bsps/arm/include/bsp/lpc-timer.h
 include_bsp_HEADERS += ../../../../../bsps/arm/include/bsp/start.h
 include_bsp_HEADERS += ../../../../../bsps/arm/include/bsp/zynq-uart-regs.h
 include_bsp_HEADERS += ../../../../../bsps/arm/include/bsp/zynq-uart.h
+include_bsp_HEADERS += ../../../../../bsps/arm/include/bsp/cadence-spi-regs.h
+include_bsp_HEADERS += ../../../../../bsps/arm/include/bsp/cadence-spi.h
 
 include_libcpudir = $(includedir)/libcpu
 include_libcpu_HEADERS =
diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am 
b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
index cfd59475c2..a04889d2e3 100644
--- a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
@@ -71,6 +71,9 @@ librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/shared/clock/clock-a9mpcore.
 # I2C
 librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/xilinx-zynq/i2c/cadence-i2c.c
 
+# SPI
+librtemsbsp_a_SOURCES += ../../../../../../bsps/arm/shared/spi/cadence-spi.c
+
 # Cache
 librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/shared/cache/cache-l2c-310.c
 
diff --git a/c/src/lib/libbsp/arm/xilinx-zynqmp/Makefile.am 
b/c/src/lib/libbsp/arm/xilinx-zynqmp/Makefile.am
index 0b49990ce7..793cd6616c 100644
--- a/c/src/lib/libbsp/arm/xilinx-zynqmp/Makefile.am
+++ b/c/src/lib/libbsp/arm/xilinx-zynqmp/Makefile.am
@@ -66,6 +66,9 @@ librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/shared/serial/zynq-uart-poll
 # Clock
 librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/shared/clock/clock-generic-timer.c
 
+# SPI
+librtemsbsp_a_SOURCES += ../../../../../../bsps/arm/shared/spi/cadence-spi.c
+
 # Cache
 librtemsbsp_a_SOURCES += ../../../../../../bsps/arm/shared/cache/cache-cp15.c
 
-- 
2.17.1

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

[PATCH 1/5] bsps/xilinx_zynq: Add SPI driver for cadence-spi

2021-03-31 Thread Jan Sommer 
Updates #4369
---
 bsps/arm/include/bsp/cadence-spi-regs.h |  84 +
 bsps/arm/include/bsp/cadence-spi.h  |  63 
 bsps/arm/shared/spi/cadence-spi.c   | 444 
 3 files changed, 591 insertions(+)
 create mode 100644 bsps/arm/include/bsp/cadence-spi-regs.h
 create mode 100644 bsps/arm/include/bsp/cadence-spi.h
 create mode 100644 bsps/arm/shared/spi/cadence-spi.c

diff --git a/bsps/arm/include/bsp/cadence-spi-regs.h 
b/bsps/arm/include/bsp/cadence-spi-regs.h
new file mode 100644
index 00..b4b2366b3d
--- /dev/null
+++ b/bsps/arm/include/bsp/cadence-spi-regs.h
@@ -0,0 +1,84 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2021 Jan Sommer, German Aerospace Center (DLR)
+ *
+ * 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_XILINX_ZYNQ_CADENCE_SPI_REGS_H
+#define LIBBSP_ARM_XILINX_ZYNQ_CADENCE_SPI_REGS_H
+
+#include 
+
+typedef struct {
+uint32_t config;
+#define CADENCE_SPI_CONFIG_MODEFAIL_EN BSP_BIT32(17)
+#define CADENCE_SPI_CONFIG_MANSTRT BSP_BIT32(16)
+#define CADENCE_SPI_CONFIG_MANSTRT_EN BSP_BIT32(15)
+#define CADENCE_SPI_CONFIG_MANUAL_CS BSP_BIT32(14)
+#define CADENCE_SPI_CONFIG_CS(val) BSP_FLD32(val, 10, 13)
+#define CADENCE_SPI_CONFIG_CS_GET(reg) BSP_FLD32GET(reg, 10, 13)
+#define CADENCE_SPI_CONFIG_CS_SET(reg, val) BSP_FLD32SET(reg, val, 10, 13)
+#define CADENCE_SPI_CONFIG_PERI_SEL BSP_BIT32(9)
+#define CADENCE_SPI_CONFIG_REF_CLK BSP_BIT32(8)
+#define CADENCE_SPI_CONFIG_BAUD_DIV(val) BSP_FLD32(val, 3, 5)
+#define CADENCE_SPI_CONFIG_BAUD_DIV_GET(reg) BSP_FLD32GET(reg, 3, 5)
+#define CADENCE_SPI_CONFIG_BAUD_DIV_SET(reg, val) BSP_FLD32SET(reg, val, 3, 5)
+#define CADENCE_SPI_CONFIG_CLK_PH BSP_BIT32(2)
+#define CADENCE_SPI_CONFIG_CLK_POL BSP_BIT32(1)
+#define CADENCE_SPI_CONFIG_MSTREN BSP_BIT32(0)
+   uint32_t irqstatus;
+   uint32_t irqenable;
+   uint32_t irqdisable;
+   uint32_t irqmask;
+#define CADENCE_SPI_IXR_TXUF BSP_BIT32(6)
+#define CADENCE_SPI_IXR_RXFULL BSP_BIT32(5)
+#define CADENCE_SPI_IXR_RXNEMPTY BSP_BIT32(4)
+#define CADENCE_SPI_IXR_TXFULL BSP_BIT32(3)
+#define CADENCE_SPI_IXR_TXOW BSP_BIT32(2)
+#define CADENCE_SPI_IXR_MODF BSP_BIT32(1)
+#define CADENCE_SPI_IXR_RXOVR BSP_BIT32(0)
+uint32_t spienable;
+#define CADENCE_SPI_EN BSP_BIT32(0)
+uint32_t delay;
+#define CADENCE_SPI_DELAY_DNSS(val) BSP_FLD32(val, 24, 31)
+#define CADENCE_SPI_DELAY_DNSS_GET(reg) BSP_FLD32GET(reg, 24, 31)
+#define CADENCE_SPI_DELAY_DNSS_SET(reg, val) BSP_FLD32SET(reg, val, 24, 31)
+#define CADENCE_SPI_DELAY_DBTWN(val) BSP_FLD32(val, 16, 23)
+#define CADENCE_SPI_DELAY_DBTWN_GET(reg) BSP_FLD32GET(reg, 16, 23)
+#define CADENCE_SPI_DELAY_DBTWN_SET(reg, val) BSP_FLD32SET(reg, val, 16, 23)
+#define CADENCE_SPI_DELAY_DAFTER(val) BSP_FLD32(val, 8, 15)
+#define CADENCE_SPI_DELAY_DAFTER_GET(reg) BSP_FLD32GET(reg, 8, 15)
+#define CADENCE_SPI_DELAY_DAFTER_SET(reg, val) BSP_FLD32SET(reg, val, 8, 15)
+#define CADENCE_SPI_DELAY_DINT(val) BSP_FLD32(val, 0, 7)
+#define CADENCE_SPI_DELAY_DINT_GET(reg) BSP_FLD32GET(reg, 0, 7)
+#define CADENCE_SPI_DELAY_DINT_SET(reg, val) BSP_FLD32SET(reg, val, 0, 7)
+   uint32_t txdata;
+   uint32_t rxdata;
+   uint32_t slave_idle_count;
+   uint32_t txthreshold;
+   uint32_t rxthreshold;
+   uint32_t moduleid;
+} cadence_spi;
+
+#endif /* LIBBSP_ARM_XILINX_ZYNQ_CADENCE_SPI_REGS_H */
diff --git a/bsps/arm/include/bsp/cadence-spi.h 
b/bsps/arm/include/bsp/cadence-spi.h
new file mode 100644
index 00..d97ede53c8
--- /dev/null
+++ b/bsps/arm/include/bsp/cadence-spi.h
@@ -0,0 +1,63 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2021 Jan Sommer, German Aerospace Center (DLR)
+ *
+ * Redis

[rtems5 PATCH 0/5] Backport zynq SPI drivers to rtems5

2021-03-31 Thread Jan Sommer 
This patchset backports:
- The cadence SPI driver (see: https://devel.rtems.org/ticket/4369)
- The xilinx axi SPI driver (see: https://devel.rtems.org/ticket/4370)
- The i2c and spi shell commands (see: https://devel.rtems.org/ticket/4371)

For the SPI drivers I didn't change any code (except the include paths)
I put them in bsps/arm/shared instead of bsps/shared, since rtems5 has
no aarch64 BSPs which could use them.

>From Christian's commit I only stripped the part for the waf build
system. I found the commands quite handy during driver development and
testing.

Best regards,

Jan

Christian Mauderer (1):
  shell: Add i2c and spi commands

Jan Sommer (4):
  bsps/xilinx_zynq: Add SPI driver for cadence-spi
  bsps/xilinx_zynq: Add cadence SPI driver to build system
  bsps/xilinx_zynq: Add SPI driver for xilinx-axi-spi
  bsps/xilinx_zynq: Add Xilinx AXI SPI driver to build

 bsps/arm/headers.am   |   4 +
 bsps/arm/include/bsp/cadence-spi-regs.h   |  84 
 bsps/arm/include/bsp/cadence-spi.h|  63 +++
 bsps/arm/include/bsp/xilinx-axi-spi-regs.h|  88 
 bsps/arm/include/bsp/xilinx-axi-spi.h |  67 +++
 bsps/arm/shared/spi/cadence-spi.c | 444 ++
 bsps/arm/shared/spi/xilinx-axi-spi.c  | 402 
 c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am  |   4 +
 .../lib/libbsp/arm/xilinx-zynqmp/Makefile.am  |   4 +
 cpukit/Makefile.am|   4 +
 cpukit/include/rtems/shellconfig.h|  28 ++
 cpukit/libmisc/shell/main_i2cdetect.c | 107 +
 cpukit/libmisc/shell/main_i2cget.c| 145 ++
 cpukit/libmisc/shell/main_i2cset.c| 124 +
 cpukit/libmisc/shell/main_spi.c   | 157 +++
 15 files changed, 1725 insertions(+)
 create mode 100644 bsps/arm/include/bsp/cadence-spi-regs.h
 create mode 100644 bsps/arm/include/bsp/cadence-spi.h
 create mode 100644 bsps/arm/include/bsp/xilinx-axi-spi-regs.h
 create mode 100644 bsps/arm/include/bsp/xilinx-axi-spi.h
 create mode 100644 bsps/arm/shared/spi/cadence-spi.c
 create mode 100644 bsps/arm/shared/spi/xilinx-axi-spi.c
 create mode 100644 cpukit/libmisc/shell/main_i2cdetect.c
 create mode 100644 cpukit/libmisc/shell/main_i2cget.c
 create mode 100644 cpukit/libmisc/shell/main_i2cset.c
 create mode 100644 cpukit/libmisc/shell/main_spi.c

-- 
2.17.1

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

[PATCH 3/5] bsps/xilinx_zynq: Add SPI driver for xilinx-axi-spi

2021-03-31 Thread Jan Sommer 
Updates #4370
---
 bsps/arm/include/bsp/xilinx-axi-spi-regs.h |  88 +
 bsps/arm/include/bsp/xilinx-axi-spi.h  |  67 
 bsps/arm/shared/spi/xilinx-axi-spi.c   | 402 +
 3 files changed, 557 insertions(+)
 create mode 100644 bsps/arm/include/bsp/xilinx-axi-spi-regs.h
 create mode 100644 bsps/arm/include/bsp/xilinx-axi-spi.h
 create mode 100644 bsps/arm/shared/spi/xilinx-axi-spi.c

diff --git a/bsps/arm/include/bsp/xilinx-axi-spi-regs.h 
b/bsps/arm/include/bsp/xilinx-axi-spi-regs.h
new file mode 100644
index 00..6211c5b97f
--- /dev/null
+++ b/bsps/arm/include/bsp/xilinx-axi-spi-regs.h
@@ -0,0 +1,88 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2021 Jan Sommer, German Aerospace Center (DLR)
+ *
+ * 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_XILINX_AXI_SPI_REGS_H
+#define LIBBSP_ARM_XILINX_AXI_SPI_REGS_H
+
+#include 
+
+typedef struct {
+uint32_t reserved1[7];
+uint32_t globalirq;
+#define XILINX_AXI_SPI_GLOBAL_IRQ_ENABLE BSP_BIT32(31)
+uint32_t irqstatus;
+uint32_t reserved2;
+uint32_t irqenable;
+#define XILINX_AXI_SPI_IRQ_CMD_ERR BSP_BIT32(13)
+#define XILINX_AXI_SPI_IRQ_LOOP_ERR BSP_BIT32(12)
+#define XILINX_AXI_SPI_IRQ_MSB_ERR BSP_BIT32(11)
+#define XILINX_AXI_SPI_IRQ_SLV_ERR BSP_BIT32(10)
+#define XILINX_AXI_SPI_IRQ_CPOL_CPHA_ERR BSP_BIT32(9)
+#define XILINX_AXI_SPI_IRQ_RXNEMPTY BSP_BIT32(8)
+#define XILINX_AXI_SPI_IRQ_CS_MODE BSP_BIT32(7)
+#define XILINX_AXI_SPI_IRQ_TXHALF BSP_BIT32(6)
+#define XILINX_AXI_SPI_IRQ_RXOVR BSP_BIT32(5)
+#define XILINX_AXI_SPI_IRQ_RXFULL BSP_BIT32(4)
+#define XILINX_AXI_SPI_IRQ_TXUF BSP_BIT32(3)
+#define XILINX_AXI_SPI_IRQ_TXEMPTY BSP_BIT32(2)
+#define XILINX_AXI_SPI_IRQ_SLV_MODF BSP_BIT32(1)
+#define XILINX_AXI_SPI_IRQ_MODF BSP_BIT32(0)
+uint32_t reserved3[5];
+uint32_t reset;
+#define XILINX_AXI_SPI_RESET 0x000a
+uint32_t reserved4[7];
+uint32_t control;
+#define XILINX_AXI_SPI_CONTROL_LSBFIRST BSP_BIT32(9)
+#define XILINX_AXI_SPI_CONTROL_MST_TRANS_INHIBIT BSP_BIT32(8)
+#define XILINX_AXI_SPI_CONTROL_MANUAL_CS BSP_BIT32(7)
+#define XILINX_AXI_SPI_CONTROL_RX_FIFO_RESET BSP_BIT32(6)
+#define XILINX_AXI_SPI_CONTROL_TX_FIFO_RESET BSP_BIT32(5)
+#define XILINX_AXI_SPI_CONTROL_CPHA BSP_BIT32(4)
+#define XILINX_AXI_SPI_CONTROL_CPOL BSP_BIT32(3)
+#define XILINX_AXI_SPI_CONTROL_MSTREN BSP_BIT32(2)
+#define XILINX_AXI_SPI_CONTROL_SPIEN BSP_BIT32(1)
+#define XILINX_AXI_SPI_CONTROL_LOOP BSP_BIT32(0)
+uint32_t status;
+#define XILINX_AXI_SPI_STATUS_CMD_ERR BSP_BIT32(10)
+#define XILINX_AXI_SPI_STATUS_LOOP_ERR BSP_BIT32(9)
+#define XILINX_AXI_SPI_STATUS_MSB_ERR BSP_BIT32(8)
+#define XILINX_AXI_SPI_STATUS_SLV_ERR BSP_BIT32(7)
+#define XILINX_AXI_SPI_STATUS_CPOL_CPHA_ERR BSP_BIT32(6)
+#define XILINX_AXI_SPI_STATUS_SLV_MODE BSP_BIT32(5)
+#define XILINX_AXI_SPI_STATUS_MODF BSP_BIT32(4)
+#define XILINX_AXI_SPI_STATUS_TXFULL BSP_BIT32(3)
+#define XILINX_AXI_SPI_STATUS_TXEMPTY BSP_BIT32(2)
+#define XILINX_AXI_SPI_STATUS_RXFULL BSP_BIT32(1)
+#define XILINX_AXI_SPI_STATUS_RXEMPTY BSP_BIT32(0)
+uint32_t txdata;
+uint32_t rxdata;
+uint32_t cs;
+uint32_t tx_fifo_len;
+uint32_t rx_fifo_len;
+} xilinx_axi_spi;
+
+#endif /* LIBBSP_ARM_XILINX_AXI_SPI_REGS_H */
diff --git a/bsps/arm/include/bsp/xilinx-axi-spi.h 
b/bsps/arm/include/bsp/xilinx-axi-spi.h
new file mode 100644
index 00..1f5e2a9989
--- /dev/null
+++ b/bsps/arm/include/bsp/xilinx-axi-spi.h
@@ -0,0 +1,67 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2021 Jan Sommer, German Aerospace Center (DLR)
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provide

[PATCH 5/5] shell: Add i2c and spi commands

2021-03-31 Thread Jan Sommer 
From: Christian Mauderer 

This adds some commands that are usefull for debugging simple serial
interfaces.

Even if they are a complete re-implementation, the i2c* commands use a
simmilar call like the Linux i2c tools.

Closes #4371
---
 cpukit/Makefile.am|   4 +
 cpukit/include/rtems/shellconfig.h|  28 +
 cpukit/libmisc/shell/main_i2cdetect.c | 107 ++
 cpukit/libmisc/shell/main_i2cget.c| 145 
 cpukit/libmisc/shell/main_i2cset.c| 124 
 cpukit/libmisc/shell/main_spi.c   | 157 ++
 6 files changed, 565 insertions(+)
 create mode 100644 cpukit/libmisc/shell/main_i2cdetect.c
 create mode 100644 cpukit/libmisc/shell/main_i2cget.c
 create mode 100644 cpukit/libmisc/shell/main_i2cset.c
 create mode 100644 cpukit/libmisc/shell/main_spi.c

diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am
index 51f38c84c7..18eda95543 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -1483,6 +1483,10 @@ librtemscpu_a_SOURCES += libmisc/shell/login_prompt.c
 librtemscpu_a_SOURCES += libmisc/shell/login_check.c
 librtemscpu_a_SOURCES += libmisc/shell/fdisk.c
 librtemscpu_a_SOURCES += libmisc/shell/main_rtc.c
+librtemscpu_a_SOURCES += libmisc/shell/main_spi.c
+librtemscpu_a_SOURCES += libmisc/shell/main_i2cdetect.c
+librtemscpu_a_SOURCES += libmisc/shell/main_i2cset.c
+librtemscpu_a_SOURCES += libmisc/shell/main_i2cget.c
 librtemscpu_a_SOURCES += libmisc/shell/dd-args.c
 librtemscpu_a_SOURCES += libmisc/shell/main_dd.c
 librtemscpu_a_SOURCES += libmisc/shell/dd-conv.c
diff --git a/cpukit/include/rtems/shellconfig.h 
b/cpukit/include/rtems/shellconfig.h
index 3e87d472d6..c5fcf4a45e 100644
--- a/cpukit/include/rtems/shellconfig.h
+++ b/cpukit/include/rtems/shellconfig.h
@@ -78,6 +78,10 @@ extern rtems_shell_cmd_t rtems_shell_DF_Command;
 extern rtems_shell_cmd_t rtems_shell_MD5_Command;
 
 extern rtems_shell_cmd_t rtems_shell_RTC_Command;
+extern rtems_shell_cmd_t rtems_shell_SPI_Command;
+extern rtems_shell_cmd_t rtems_shell_I2CDETECT_Command;
+extern rtems_shell_cmd_t rtems_shell_I2CGET_Command;
+extern rtems_shell_cmd_t rtems_shell_I2CSET_Command;
 
 extern rtems_shell_cmd_t rtems_shell_SHUTDOWN_Command;
 extern rtems_shell_cmd_t rtems_shell_CPUINFO_Command;
@@ -521,6 +525,30 @@ extern rtems_shell_alias_t * const 
rtems_shell_Initial_aliases[];
   &rtems_shell_RTC_Command,
 #endif
 
+#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \
+  && !defined(CONFIGURE_SHELL_NO_COMMAND_SPI)) \
+|| defined(CONFIGURE_SHELL_COMMAND_SPI)
+  &rtems_shell_SPI_Command,
+#endif
+
+#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \
+  && !defined(CONFIGURE_SHELL_NO_COMMAND_I2CDETECT)) \
+|| defined(CONFIGURE_SHELL_COMMAND_I2CDETECT)
+  &rtems_shell_I2CDETECT_Command,
+#endif
+
+#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \
+  && !defined(CONFIGURE_SHELL_NO_COMMAND_I2CGET)) \
+|| defined(CONFIGURE_SHELL_COMMAND_I2CGET)
+  &rtems_shell_I2CGET_Command,
+#endif
+
+#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \
+  && !defined(CONFIGURE_SHELL_NO_COMMAND_I2CSET)) \
+|| defined(CONFIGURE_SHELL_COMMAND_I2CSET)
+  &rtems_shell_I2CSET_Command,
+#endif
+
 /*
  *  System related commands
  */
diff --git a/cpukit/libmisc/shell/main_i2cdetect.c 
b/cpukit/libmisc/shell/main_i2cdetect.c
new file mode 100644
index 00..e953b4eaef
--- /dev/null
+++ b/cpukit/libmisc/shell/main_i2cdetect.c
@@ -0,0 +1,107 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2020 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.
+ */
+
+/*
+ * The

[PATCH 4/5] bsps/xilinx_zynq: Add Xilinx AXI SPI driver to build

2021-03-31 Thread Jan Sommer 
Closes #4370
---
 bsps/arm/headers.am| 2 ++
 c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am   | 1 +
 c/src/lib/libbsp/arm/xilinx-zynqmp/Makefile.am | 1 +
 3 files changed, 4 insertions(+)

diff --git a/bsps/arm/headers.am b/bsps/arm/headers.am
index 007412fee0..69a154f6b2 100644
--- a/bsps/arm/headers.am
+++ b/bsps/arm/headers.am
@@ -41,6 +41,8 @@ include_bsp_HEADERS += 
../../../../../bsps/arm/include/bsp/zynq-uart-regs.h
 include_bsp_HEADERS += ../../../../../bsps/arm/include/bsp/zynq-uart.h
 include_bsp_HEADERS += ../../../../../bsps/arm/include/bsp/cadence-spi-regs.h
 include_bsp_HEADERS += ../../../../../bsps/arm/include/bsp/cadence-spi.h
+include_bsp_HEADERS += 
../../../../../bsps/arm/include/bsp/xilinx-axi-spi-regs.h
+include_bsp_HEADERS += ../../../../../bsps/arm/include/bsp/xilinx-axi-spi.h
 
 include_libcpudir = $(includedir)/libcpu
 include_libcpu_HEADERS =
diff --git a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am 
b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
index a04889d2e3..449053b831 100644
--- a/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
+++ b/c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am
@@ -73,6 +73,7 @@ librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/xilinx-zynq/i2c/cadence-i2c.
 
 # SPI
 librtemsbsp_a_SOURCES += ../../../../../../bsps/arm/shared/spi/cadence-spi.c
+librtemsbsp_a_SOURCES += ../../../../../../bsps/arm/shared/spi/xilinx-axi-spi.c
 
 # Cache
 librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/shared/cache/cache-l2c-310.c
diff --git a/c/src/lib/libbsp/arm/xilinx-zynqmp/Makefile.am 
b/c/src/lib/libbsp/arm/xilinx-zynqmp/Makefile.am
index 793cd6616c..6686ca4e04 100644
--- a/c/src/lib/libbsp/arm/xilinx-zynqmp/Makefile.am
+++ b/c/src/lib/libbsp/arm/xilinx-zynqmp/Makefile.am
@@ -68,6 +68,7 @@ librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/shared/clock/clock-generic-t
 
 # SPI
 librtemsbsp_a_SOURCES += ../../../../../../bsps/arm/shared/spi/cadence-spi.c
+librtemsbsp_a_SOURCES += ../../../../../../bsps/arm/shared/spi/xilinx-axi-spi.c
 
 # Cache
 librtemsbsp_a_SOURCES += ../../../../../../bsps/arm/shared/cache/cache-cp15.c
-- 
2.17.1

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

Re: GSOC project: #4334 Replace Mongoose with Civetweb

2021-03-31 Thread Ayushman Mishra 
Sir,
I am trying to integrate mongoose web-server in simple rtems
application (https://devel.rtems.org/wiki/Developer/Mongoose_Web_Server),
for that I have to configure networking in rtems. I am using
xilinx_zynq_a9_qemu for simulation bsp and following steps given here
https://git.rtems.org/rtems-libbsd/tree/README.md but after doing
./waf install , i was not able to find qemu-system-arm in any
directory , I did sudo apt-get install qemu but then also
qemu-system-arm was not found . I discussed in discord channel and
started using rsb recipe devel/qemu4 (
$ ../source-builder/sb-set-builder --prefix=
devel/qemu4.bset ) present in branch 5 of rsb ( since master branch
doesn't have qemu4.bset ) but after building for few minutes it gave
BUILD FAILED error
( Last lines of error report:
 ../../glib-2.46.2/gio/gdbusauth.c: In function '_g_dbus_auth_run_server':
../../glib-2.46.2/gio/gdbusauth.c:1295:11: error: '%s' directive
argument is null [-Werror=format-overflow=]
 1295 |   debug_print ("SERVER: WaitingForBegin, read '%s'", line);
  |   ^~~~
cc1: some warnings being treated as errors
make[4]: *** [Makefile:3624: libgio_2_0_la-gdbusauth.lo] Error 1
make[4]: *** Waiting for unfinished jobs
make[4]: Leaving directory
'/home/ayush/quick-start1/src/rsb/rtems/build/glib-2.46.2-x86_64-linux-gnu-1/build/gio'
make[3]: *** [Makefile:4094: all-recursive] Error 1
make[3]: Leaving directory
'/home/ayush/quick-start1/src/rsb/rtems/build/glib-2.46.2-x86_64-linux-gnu-1/build/gio'
make[2]: *** [Makefile:1861: all] Error 2
make[2]: Leaving directory
'/home/ayush/quick-start1/src/rsb/rtems/build/glib-2.46.2-x86_64-linux-gnu-1/build/gio'
make[1]: *** [Makefile:1212: all-recursive] Error 1
make[1]: Leaving directory
'/home/ayush/quick-start1/src/rsb/rtems/build/glib-2.46.2-x86_64-linux-gnu-1/build'
make: *** [Makefile:854: all] Error 2
shell cmd failed: /bin/sh -ex
/home/ayush/quick-start1/src/rsb/rtems/build/glib-2.46.2-x86_64-linux-gnu-1/do-build
error: building glib-2.46.2-x86_64-linux-gnu-1
)
I think i am really stuck here and I would be highly obliged if you
can please provide some guidance in configuring networking and
integrating mongoose with simple rtems application.

Also I think creating a separate repository like rtems-civetweb would
make the tree more clearer to understand and easy to build and install
, since integrating it with rsb like a package may sometimes cause
build failed due to bugs in rsb.
thanks , Ayushman

On Tue, Mar 30, 2021 at 12:16 PM Christian MAUDERER
 wrote:
>
> Hello Ayushman, hello Gedare,
>
> Am 29.03.21 um 18:50 schrieb Gedare Bloom:
> > CC: Christian
> >
> > On Mon, Mar 29, 2021 at 10:34 AM Ayushman Mishra
> >  wrote:
> >>
> >> Sir ,
> >> It would be very helpful to know about potential mentors of (Replace 
> >> mongoose with civetweb) https://devel.rtems.org/ticket/4334 this project.
> >>
> > I think Christian is the most likely potential mentor.
> >
>
> Possible for the civetweb part. I have done quite a bit with mongoose or
> later civetweb. So most likely I should at least help on this project.
> But I don't think that building civetweb will be the critical part here.
> That is quite straightforward.
>
> The more tricky part of the project will be to find a way to make the
> configuration options available to the users. That means either creating
> a repo (similar to for example rtems-littlevgl) or some integration into
> RSB (no idea how to add options there). We should try to get someone
> with more experience in that area into this project too.
>
> >> On Mon, Mar 29, 2021, 9:39 PM Gedare Bloom  wrote:
> >>>
> >>> On Mon, Mar 29, 2021 at 9:49 AM Ayushman Mishra
> >>>  wrote:
> 
>  I have installed libbsd package (made
>  RTEMS_POSIX_API=True,RTEMS_NETWORKING=True in config.ini file to
>  enable POSIX and networking) but I am still confused about the work
> >>> That doesn't look right. RTEMS_NETWORKING=True enables the legacy
> >>> network stack. If you want to build libbsd, you need to check out
> >>> https://git.rtems.org/rtems-libbsd/
> >>>
>  already done in this project in past. Also after interacting on
>  discord I think completely replacing  mongoose with another web-server
>  is not a good option since it may rise some user complaints who are
>  already using old system and may find it difficult to instantly switch
>  over to new system , instead civetweb can be added as an extra new
>  web-server where user has a choice to either use old mongoose or the
>  new web server both having all dependencies and functionalities
>  available.
> 
> >>> No, we will replace mghttpd with civetweb. Anyone who still wants the
> >>> frozen version of mghttpd can revive it, but we want to replace it
> >>> moving forward.
>
> Agreed. We maybe can leave some hints where to get the current version
> of mghttpd (basically a commit number, a path and current build
> option

Re: [PATCH 1/3] rtems-bin2c.c: Define _GNU_SOURCE for strnlen()

2021-03-31 Thread Gedare Bloom 
The --subject-prefix is helpful to guide reviewers.
https://docs.rtems.org/branches/master/eng/vc-users.html#creating-a-patch

On Tue, Mar 30, 2021 at 3:16 PM Joel Sherrill  wrote:
>
> ---
>  misc/bin2c/rtems-bin2c.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/misc/bin2c/rtems-bin2c.c b/misc/bin2c/rtems-bin2c.c
> index 7ed79dd..397f2ad 100644
> --- a/misc/bin2c/rtems-bin2c.c
> +++ b/misc/bin2c/rtems-bin2c.c
> @@ -25,6 +25,7 @@
>   *
>   */
>
> +#define _GNU_SOURCE // for strnlen
>  #include 
>  #include 
>  #include 

The feature check for strnlen in glibc is now _POSIX_C_SOURCE >= 200809L


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

Re: [PATCH 2/3] misc/wscript: Specify C language version

2021-03-31 Thread Gedare Bloom 
Should we set the cstd version at the top-level?

On Tue, Mar 30, 2021 at 3:16 PM Joel Sherrill  wrote:
>
> CentOS 7 has gcc 4.8 which defaults to C90 and this results in warnings
> for code that is valid C99 but not C90.
> ---
>  misc/wscript | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/misc/wscript b/misc/wscript
> index 521eddf..21e7f75 100644
> --- a/misc/wscript
> +++ b/misc/wscript
> @@ -51,7 +51,8 @@ def build(bld):
>  #
>  conf['warningflags'] = ['-Wall', '-Wextra', '-pedantic']
>  conf['optflags'] = bld.env.C_OPTS
> -conf['cflags'] = ['-pipe', '-g'] + conf['optflags']
> +cstd = '-std=c99'
> +conf['cflags'] = [cstd] + ['-pipe', '-g'] + conf['optflags']
>  conf['linkflags'] = ['-g']
>
>  #
> --
> 1.8.3.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH 1/3] gen_uuid.c: Ignore return values from fcntl()

2021-03-31 Thread Ryan Long 
CID 1049146: Unchecked return value from library in get_clock().
CID 1049147: Unchecked return value from library in get_random_fd().

Closes #4280
---
 cpukit/libmisc/uuid/gen_uuid.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/cpukit/libmisc/uuid/gen_uuid.c b/cpukit/libmisc/uuid/gen_uuid.c
index 3ca75a0..9cd763d 100644
--- a/cpukit/libmisc/uuid/gen_uuid.c
+++ b/cpukit/libmisc/uuid/gen_uuid.c
@@ -164,8 +164,13 @@ static int get_random_fd(void)
fd = open("/dev/random", O_RDONLY | O_NONBLOCK);
if (fd >= 0) {
i = fcntl(fd, F_GETFD);
+   #ifdef __rtems__
+   if (i >= 0)
+   (void) fcntl(fd, F_SETFD, i | FD_CLOEXEC);
+   #else
if (i >= 0)
fcntl(fd, F_SETFD, i | FD_CLOEXEC);
+   #endif
}
 #endif
srand((getpid() << ((sizeof(pid_t)*CHAR_BIT)>>1)) ^ getuid() ^ 
tv.tv_sec ^ tv.tv_usec);
@@ -426,6 +431,9 @@ try_again:
}
rewind(state_f);
fl.l_type = F_UNLCK;
+   #ifdef __rtems__
+   (void)
+   #endif
fcntl(state_fd, F_SETLK, &fl);
}
 
-- 
1.8.3.1

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

[PATCH 2/3] main_cp.c: Ignore return value from stat()

2021-03-31 Thread Ryan Long 
CID 26051: Unchecked return value from library in main_cp().

Closes #4365
---
 cpukit/libmisc/shell/main_cp.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/cpukit/libmisc/shell/main_cp.c b/cpukit/libmisc/shell/main_cp.c
index cddbc95..bb31a35 100644
--- a/cpukit/libmisc/shell/main_cp.c
+++ b/cpukit/libmisc/shell/main_cp.c
@@ -254,10 +254,17 @@ main_cp(rtems_shell_cp_globals* cp_globals, int argc, 
char *argv[])
 * the initial mkdir().
 */
if (r == -1) {
+   #ifdef __rtems__
+   if (Rflag && (Lflag || Hflag))
+   (void) stat(*argv, &tmp_stat);
+   else
+   (void) lstat(*argv, &tmp_stat);
+   #else
if (Rflag && (Lflag || Hflag))
stat(*argv, &tmp_stat);
else
lstat(*argv, &tmp_stat);
+   #endif
 
if (S_ISDIR(tmp_stat.st_mode) && Rflag)
type = DIR_TO_DNE;
-- 
1.8.3.1

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

[PATCH 0/3] Unchecked return value from library patches

2021-03-31 Thread Ryan Long 
Hi,

For these patches, I just added #ifdefs and (void)'s to get rid of the issues.

Thanks,
Ryan

Ryan Long (3):
  gen_uuid.c: Ignore return values from fcntl()
  main_cp.c: Ignore return value from stat()
  main_help.c: Do not care what char is returned by getchar()

 cpukit/libmisc/shell/main_cp.c   | 7 +++
 cpukit/libmisc/shell/main_help.c | 2 +-
 cpukit/libmisc/uuid/gen_uuid.c   | 8 
 3 files changed, 16 insertions(+), 1 deletion(-)

-- 
1.8.3.1

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

[PATCH 3/3] main_help.c: Do not care what char is returned by getchar()

2021-03-31 Thread Ryan Long 
CID 1437650: Unchecked return value from library in rtems_shell_help().

Closes #4291
---
 cpukit/libmisc/shell/main_help.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/libmisc/shell/main_help.c b/cpukit/libmisc/shell/main_help.c
index 9f59e9d..564bc30 100644
--- a/cpukit/libmisc/shell/main_help.c
+++ b/cpukit/libmisc/shell/main_help.c
@@ -148,7 +148,7 @@ static int rtems_shell_help(
 line+= rtems_shell_help_cmd(shell_cmd);
   if (lines && (line > lines)) {
 printf("Press any key to continue...");
-getchar();
+(void) getchar();
 printf("\n");
 line = 0;
   }
-- 
1.8.3.1

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

RE: [rtems-tools commit] rld-process: Add named tempfile constructor

2021-03-31 Thread Alex White 
On Tue, Mar 30, 2021 at 10:30 PM Chris Johns  wrote:
>
> Hi,
>
> When I looked at this on vc@ I saw it is broken. I am sorry I did not pick 
> this
> up in the review.
>
> On 31/3/21 5:20 am, Joel Sherrill wrote:
> > Module:    rtems-tools
> > Branch:    master
> > Commit:    420d7a13672991a1480d06ac02190f2976b9253b
> > Changeset: 
> > http://git.rtems.org/rtems-tools/commit/?id=420d7a13672991a1480d06ac02190f2976b9253b
> >
> > Author:    Alex White 
> > Date:      Wed Mar  3 09:48:00 2021 -0600
> >
> > rld-process: Add named tempfile constructor
> >
> > This adds a new tempfile constructor for creating a named tempfile
> > rather than generating the name.
> >
> > ---
> >
> >  rtemstoolkit/rld-process.cpp | 11 +++
> >  rtemstoolkit/rld-process.h   |  7 +++
> >  2 files changed, 18 insertions(+)
> >
> > diff --git a/rtemstoolkit/rld-process.cpp b/rtemstoolkit/rld-process.cpp
> > index 30e0605..4160759 100644
> > --- a/rtemstoolkit/rld-process.cpp
> > +++ b/rtemstoolkit/rld-process.cpp
> > @@ -169,6 +169,17 @@ namespace rld
> >        _name = temporaries.get (suffix, _keep);
> >      }
> > 
> > +    tempfile::tempfile (const std::string& name,
> > +                        const std::string& suffix,
> > +                        bool               _keep)
>
> As a side issue this should be `keep` and not `_keep`. Could this please be
> fixed with fix that is needed.
>
> > +      : _name(name + suffix),
> > +        suffix(suffix),
> > +        overridden (false),
> > +        fd (-1),
> > +        level (0)
> > +    {
> > +    }
>
> This constructor is empty and so the file is not created in the temp path on
> Unix or Windows and it is not registered to be deleted. I am sorry I did not
> notice this before. How was this change tested?
>
> Now I think about this change I am not sure it is right. Why you are using 
> this
> interface when the file is not in a temp directory and is not being deleted?

Hi Chris,

This patch set up the interfaces used in the "covoar: Add option to create 
named objdumps" patch that I sent.

We determined that patch was not needed given its hacked-togetherness along 
with future speedups that we had in mind which would make it obsolete anyway.

This patch should have been removed from the set to be committed, but I forgot 
to send out a notice to exclude it. Sorry for the confusion.

This commit should be reverted.

Alex

>
> I have created a ticket ...
>
>  https://devel.rtems.org/ticket/4368
>
> Chris
> ___
> 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] Revert rld-process: Add named tempfile constructor

2021-03-31 Thread Joel Sherrill 
This patch reflected a temporary workaround which avoided regenerating
the temporary files for each symbol set. The need for redundant processing
is being eliminated in an upcoming patch series.

Hash: 420d7a13672991a1480d06ac02190f2976b9253b

>From 420d7a13672991a1480d06ac02190f2976b9253b Mon Sep 17 00:00:00 2001
From: Alex White 
Date: Wed, 3 Mar 2021 09:48:00 -0600
Subject: rld-process: Add named tempfile constructor

This adds a new tempfile constructor for creating a named tempfile
rather than generating the name.
---
 rtemstoolkit/rld-process.cpp | 11 ---
 rtemstoolkit/rld-process.h   |  7 ---
 2 files changed, 18 deletions(-)

diff --git a/rtemstoolkit/rld-process.cpp b/rtemstoolkit/rld-process.cpp
index 4160759..30e0605 100644
--- a/rtemstoolkit/rld-process.cpp
+++ b/rtemstoolkit/rld-process.cpp
@@ -169,17 +169,6 @@ namespace rld
   _name = temporaries.get (suffix, _keep);
 }
 
-tempfile::tempfile (const std::string& name,
-const std::string& suffix,
-bool   _keep)
-  : _name(name + suffix),
-suffix(suffix),
-overridden (false),
-fd (-1),
-level (0)
-{
-}
-
 tempfile::~tempfile ()
 {
   try
diff --git a/rtemstoolkit/rld-process.h b/rtemstoolkit/rld-process.h
index a9902b2..fc9b7bc 100644
--- a/rtemstoolkit/rld-process.h
+++ b/rtemstoolkit/rld-process.h
@@ -115,13 +115,6 @@ namespace rld
   tempfile (const std::string& suffix = ".rldxx", bool keep = false);
 
   /**
-   * Get a temporary file given a name and a suffix.
-   */
-  tempfile (const std::string& name,
-const std::string& suffix,
-bool   _keep = false);
-
-  /**
* Clean up the temporary file.
*/
   ~tempfile ();
-- 
1.8.3.1

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

Re: GSOC project: #4334 Replace Mongoose with Civetweb

2021-03-31 Thread Gedare Bloom 
On Wed, Mar 31, 2021 at 3:18 AM Ayushman Mishra
 wrote:
>
> Sir,
> I am trying to integrate mongoose web-server in simple rtems
> application (https://devel.rtems.org/wiki/Developer/Mongoose_Web_Server),
> for that I have to configure networking in rtems. I am using
> xilinx_zynq_a9_qemu for simulation bsp and following steps given here
> https://git.rtems.org/rtems-libbsd/tree/README.md but after doing
> ./waf install , i was not able to find qemu-system-arm in any
> directory , I did sudo apt-get install qemu but then also
> qemu-system-arm was not found . I discussed in discord channel and
> started using rsb recipe devel/qemu4 (
> $ ../source-builder/sb-set-builder --prefix=
> devel/qemu4.bset ) present in branch 5 of rsb ( since master branch
> doesn't have qemu4.bset ) but after building for few minutes it gave
> BUILD FAILED error

bare/devel/qemu.bset should get you a working version on qemu v5, I
would guess that should work.

> ( Last lines of error report:
>  ../../glib-2.46.2/gio/gdbusauth.c: In function '_g_dbus_auth_run_server':
> ../../glib-2.46.2/gio/gdbusauth.c:1295:11: error: '%s' directive
> argument is null [-Werror=format-overflow=]
>  1295 |   debug_print ("SERVER: WaitingForBegin, read '%s'", line);
>   |   ^~~~
> cc1: some warnings being treated as errors
> make[4]: *** [Makefile:3624: libgio_2_0_la-gdbusauth.lo] Error 1
> make[4]: *** Waiting for unfinished jobs
> make[4]: Leaving directory
> '/home/ayush/quick-start1/src/rsb/rtems/build/glib-2.46.2-x86_64-linux-gnu-1/build/gio'
> make[3]: *** [Makefile:4094: all-recursive] Error 1
> make[3]: Leaving directory
> '/home/ayush/quick-start1/src/rsb/rtems/build/glib-2.46.2-x86_64-linux-gnu-1/build/gio'
> make[2]: *** [Makefile:1861: all] Error 2
> make[2]: Leaving directory
> '/home/ayush/quick-start1/src/rsb/rtems/build/glib-2.46.2-x86_64-linux-gnu-1/build/gio'
> make[1]: *** [Makefile:1212: all-recursive] Error 1
> make[1]: Leaving directory
> '/home/ayush/quick-start1/src/rsb/rtems/build/glib-2.46.2-x86_64-linux-gnu-1/build'
> make: *** [Makefile:854: all] Error 2
> shell cmd failed: /bin/sh -ex
> /home/ayush/quick-start1/src/rsb/rtems/build/glib-2.46.2-x86_64-linux-gnu-1/do-build
> error: building glib-2.46.2-x86_64-linux-gnu-1
> )
I have the same problem trying to build qemu4, technically this is a
problem building glib-2.46.2.

> I think i am really stuck here and I would be highly obliged if you
> can please provide some guidance in configuring networking and
> integrating mongoose with simple rtems application.
>
> Also I think creating a separate repository like rtems-civetweb would
> make the tree more clearer to understand and easy to build and install
> , since integrating it with rsb like a package may sometimes cause
> build failed due to bugs in rsb.

This reasoning doesn't make too much sense to me. Do you have a
technical reason for a separate repo?

> thanks , Ayushman
>
> On Tue, Mar 30, 2021 at 12:16 PM Christian MAUDERER
>  wrote:
> >
> > Hello Ayushman, hello Gedare,
> >
> > Am 29.03.21 um 18:50 schrieb Gedare Bloom:
> > > CC: Christian
> > >
> > > On Mon, Mar 29, 2021 at 10:34 AM Ayushman Mishra
> > >  wrote:
> > >>
> > >> Sir ,
> > >> It would be very helpful to know about potential mentors of (Replace 
> > >> mongoose with civetweb) https://devel.rtems.org/ticket/4334 this project.
> > >>
> > > I think Christian is the most likely potential mentor.
> > >
> >
> > Possible for the civetweb part. I have done quite a bit with mongoose or
> > later civetweb. So most likely I should at least help on this project.
> > But I don't think that building civetweb will be the critical part here.
> > That is quite straightforward.
> >
> > The more tricky part of the project will be to find a way to make the
> > configuration options available to the users. That means either creating
> > a repo (similar to for example rtems-littlevgl) or some integration into
> > RSB (no idea how to add options there). We should try to get someone
> > with more experience in that area into this project too.
> >
> > >> On Mon, Mar 29, 2021, 9:39 PM Gedare Bloom  wrote:
> > >>>
> > >>> On Mon, Mar 29, 2021 at 9:49 AM Ayushman Mishra
> > >>>  wrote:
> > 
> >  I have installed libbsd package (made
> >  RTEMS_POSIX_API=True,RTEMS_NETWORKING=True in config.ini file to
> >  enable POSIX and networking) but I am still confused about the work
> > >>> That doesn't look right. RTEMS_NETWORKING=True enables the legacy
> > >>> network stack. If you want to build libbsd, you need to check out
> > >>> https://git.rtems.org/rtems-libbsd/
> > >>>
> >  already done in this project in past. Also after interacting on
> >  discord I think completely replacing  mongoose with another web-server
> >  is not a good option since it may rise some user complaints who are
> >  already using old system and may find it difficult to instantly switch
> >  over to n

Re: [PATCH] rld-cc: Add -target to recognised cflags

2021-03-31 Thread Gedare Bloom 
On Wed, Mar 31, 2021 at 12:19 AM Hesham Almatary
 wrote:
>
> Ping
>
Go ahead if you tested with gcc also.

> On Wed, 24 Mar 2021 at 09:57, Hesham Almatary  
> wrote:
>>
>> -target *-*-* flag is necessary for LLVM/Clang while cross-compiling
>> ---
>>  rtemstoolkit/rld-cc.cpp | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/rtemstoolkit/rld-cc.cpp b/rtemstoolkit/rld-cc.cpp
>> index bb03ff6..b424214 100644
>> --- a/rtemstoolkit/rld-cc.cpp
>> +++ b/rtemstoolkit/rld-cc.cpp
>> @@ -110,6 +110,7 @@ namespace rld
>>{ fg_include, "-I",   2, true,  0 },
>>{ fg_include, "-isystem", 2, true,  0 },
>>{ fg_include, "-sysroot", 2, true,  0 },
>> +  { fg_machine, "-target" , 2, false, 0 },
>>{ fg_machine, "-O",   1, false, 0 },
>>{ fg_machine, "-m",   1, false, 0 },
>>{ fg_machine, "-f",   1, false, 0 },
>> --
>> 2.25.1
>>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] covoar: Fix off-by-one in Coverage::finalizeSymbol()

2021-03-31 Thread Alex White 
The `rangeIndex` variable is 1 higher than the index at which the first
instruction address was found. This fixes the lookup after the loop to
account for that fact.
---
 tester/covoar/ObjdumpProcessor.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tester/covoar/ObjdumpProcessor.cc 
b/tester/covoar/ObjdumpProcessor.cc
index 62a06c5..1cfa877 100644
--- a/tester/covoar/ObjdumpProcessor.cc
+++ b/tester/covoar/ObjdumpProcessor.cc
@@ -60,7 +60,7 @@ namespace Coverage {
 lowAddress = coverageMap.getLowAddressOfRange(rangeIndex);
   }
 
-  uint32_t sizeWithoutNops = coverageMap.getSizeOfRange(rangeIndex);
+  uint32_t sizeWithoutNops = coverageMap.getSizeOfRange(rangeIndex - 1);
   uint32_t size = sizeWithoutNops;
   uint32_t highAddress = lowAddress + size - 1;
   uint32_t computedHighAddress = highAddress;
-- 
2.27.0

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

Re: [PATCH 1/3] gen_uuid.c: Ignore return values from fcntl()

2021-03-31 Thread Gedare Bloom 
On Wed, Mar 31, 2021 at 9:16 AM Ryan Long  wrote:
>
> CID 1049146: Unchecked return value from library in get_clock().
> CID 1049147: Unchecked return value from library in get_random_fd().
>
> Closes #4280
> ---
>  cpukit/libmisc/uuid/gen_uuid.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/cpukit/libmisc/uuid/gen_uuid.c b/cpukit/libmisc/uuid/gen_uuid.c
> index 3ca75a0..9cd763d 100644
> --- a/cpukit/libmisc/uuid/gen_uuid.c
> +++ b/cpukit/libmisc/uuid/gen_uuid.c
> @@ -164,8 +164,13 @@ static int get_random_fd(void)
> fd = open("/dev/random", O_RDONLY | O_NONBLOCK);
> if (fd >= 0) {
> i = fcntl(fd, F_GETFD);
> +   #ifdef __rtems__
> +   if (i >= 0)
> +   (void) fcntl(fd, F_SETFD, i | FD_CLOEXEC);
> +   #else
> if (i >= 0)
> fcntl(fd, F_SETFD, i | FD_CLOEXEC);
> +   #endif
You could do the same thing here as you did below, just put the #ifdef
after the if (i>=0)

The upstream is
https://github.com/karelzak/util-linux/blob/master/libuuid/src/gen_uuid.c
I wonder if we should update?

> }
>  #endif
> srand((getpid() << ((sizeof(pid_t)*CHAR_BIT)>>1)) ^ getuid() 
> ^ tv.tv_sec ^ tv.tv_usec);
> @@ -426,6 +431,9 @@ try_again:
> }
> rewind(state_f);
> fl.l_type = F_UNLCK;
> +   #ifdef __rtems__
> +   (void)
> +   #endif
> fcntl(state_fd, F_SETLK, &fl);
> }
>
> --
> 1.8.3.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/3] main_cp.c: Ignore return value from stat()

2021-03-31 Thread Gedare Bloom 
On Wed, Mar 31, 2021 at 9:16 AM Ryan Long  wrote:
>
> CID 26051: Unchecked return value from library in main_cp().
>
> Closes #4365
> ---
>  cpukit/libmisc/shell/main_cp.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/cpukit/libmisc/shell/main_cp.c b/cpukit/libmisc/shell/main_cp.c
> index cddbc95..bb31a35 100644
> --- a/cpukit/libmisc/shell/main_cp.c
> +++ b/cpukit/libmisc/shell/main_cp.c
> @@ -254,10 +254,17 @@ main_cp(rtems_shell_cp_globals* cp_globals, int argc, 
> char *argv[])
>  * the initial mkdir().
>  */
> if (r == -1) {
> +   #ifdef __rtems__
> +   if (Rflag && (Lflag || Hflag))
> +   (void) stat(*argv, &tmp_stat);
> +   else
> +   (void) lstat(*argv, &tmp_stat);
> +   #else
> if (Rflag && (Lflag || Hflag))
> stat(*argv, &tmp_stat);
> else
> lstat(*argv, &tmp_stat);
> +   #endif
>

Would it be better to keep each change localized? at first I didn't
really care for this approach that was taken in patch 1, but compared
to copy-pasting multiple lines of code, it might be simpler to deal
with fine-grained modifications, like this:

 if (Rflag && (Lflag || Hflag))
+   #ifdef __rtems__
+   (void)
+   #endif
 (void) stat(*argv, &tmp_stat);

> if (S_ISDIR(tmp_stat.st_mode) && Rflag)
> type = DIR_TO_DNE;
> --
> 1.8.3.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH 2/3] main_cp.c: Ignore return value from stat()

2021-03-31 Thread Ryan Long 
I'm assuming you accidentally left the (void) in after that #endif, but that's 
the approach that Joel and I did first.  After Joel saw it implemented, he said 
it made the code look too messy to him because of the if statements.

-Original Message-
From: Gedare Bloom  
Sent: Wednesday, March 31, 2021 11:17 AM
To: Ryan Long 
Cc: devel@rtems.org
Subject: Re: [PATCH 2/3] main_cp.c: Ignore return value from stat()

On Wed, Mar 31, 2021 at 9:16 AM Ryan Long  wrote:
>
> CID 26051: Unchecked return value from library in main_cp().
>
> Closes #4365
> ---
>  cpukit/libmisc/shell/main_cp.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/cpukit/libmisc/shell/main_cp.c 
> b/cpukit/libmisc/shell/main_cp.c index cddbc95..bb31a35 100644
> --- a/cpukit/libmisc/shell/main_cp.c
> +++ b/cpukit/libmisc/shell/main_cp.c
> @@ -254,10 +254,17 @@ main_cp(rtems_shell_cp_globals* cp_globals, int argc, 
> char *argv[])
>  * the initial mkdir().
>  */
> if (r == -1) {
> +   #ifdef __rtems__
> +   if (Rflag && (Lflag || Hflag))
> +   (void) stat(*argv, &tmp_stat);
> +   else
> +   (void) lstat(*argv, &tmp_stat);
> +   #else
> if (Rflag && (Lflag || Hflag))
> stat(*argv, &tmp_stat);
> else
> lstat(*argv, &tmp_stat);
> +   #endif
>

Would it be better to keep each change localized? at first I didn't really care 
for this approach that was taken in patch 1, but compared to copy-pasting 
multiple lines of code, it might be simpler to deal with fine-grained 
modifications, like this:

 if (Rflag && (Lflag || Hflag))
+   #ifdef __rtems__
+   (void)
+   #endif
 (void) stat(*argv, &tmp_stat);

> if (S_ISDIR(tmp_stat.st_mode) && Rflag)
> type = DIR_TO_DNE;
> --
> 1.8.3.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar: Fix off-by-one in Coverage::finalizeSymbol()

2021-03-31 Thread Gedare Bloom 
On Wed, Mar 31, 2021 at 10:05 AM Alex White  wrote:
>
> The `rangeIndex` variable is 1 higher than the index at which the first
> instruction address was found. This fixes the lookup after the loop to
> account for that fact.
> ---
>  tester/covoar/ObjdumpProcessor.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tester/covoar/ObjdumpProcessor.cc 
> b/tester/covoar/ObjdumpProcessor.cc
> index 62a06c5..1cfa877 100644
> --- a/tester/covoar/ObjdumpProcessor.cc
> +++ b/tester/covoar/ObjdumpProcessor.cc
> @@ -60,7 +60,7 @@ namespace Coverage {
>  lowAddress = coverageMap.getLowAddressOfRange(rangeIndex);
>}
>
> -  uint32_t sizeWithoutNops = coverageMap.getSizeOfRange(rangeIndex);
> +  uint32_t sizeWithoutNops = coverageMap.getSizeOfRange(rangeIndex - 1);

I guess this is because of the for loop. Maybe, you should prefer to
exit the for loop with the proper index?

Fixing an off-by-1 bug by subtracting one from the point of
consumption is a good way to ensure the bug occurs again if anyone
reuses the rangeIndex variable later.

>uint32_t size = sizeWithoutNops;
>uint32_t highAddress = lowAddress + size - 1;
>uint32_t computedHighAddress = highAddress;
> --
> 2.27.0
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/3] main_cp.c: Ignore return value from stat()

2021-03-31 Thread Gedare Bloom 
On Wed, Mar 31, 2021 at 10:21 AM Ryan Long  wrote:
>
> I'm assuming you accidentally left the (void) in after that #endif, but 
> that's the approach that Joel and I did first.  After Joel saw it 
> implemented, he said it made the code look too messy to him because of the if 
> statements.
>
Right. The thing is that we aren't looking to make this code clean,
we're optimizing for easier updates from the upstream. Generally, it
is easier to undo and redo small changes than large changes.

> -Original Message-
> From: Gedare Bloom 
> Sent: Wednesday, March 31, 2021 11:17 AM
> To: Ryan Long 
> Cc: devel@rtems.org
> Subject: Re: [PATCH 2/3] main_cp.c: Ignore return value from stat()
>
> On Wed, Mar 31, 2021 at 9:16 AM Ryan Long  wrote:
> >
> > CID 26051: Unchecked return value from library in main_cp().
> >
> > Closes #4365
> > ---
> >  cpukit/libmisc/shell/main_cp.c | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/cpukit/libmisc/shell/main_cp.c
> > b/cpukit/libmisc/shell/main_cp.c index cddbc95..bb31a35 100644
> > --- a/cpukit/libmisc/shell/main_cp.c
> > +++ b/cpukit/libmisc/shell/main_cp.c
> > @@ -254,10 +254,17 @@ main_cp(rtems_shell_cp_globals* cp_globals, int argc, 
> > char *argv[])
> >  * the initial mkdir().
> >  */
> > if (r == -1) {
> > +   #ifdef __rtems__
> > +   if (Rflag && (Lflag || Hflag))
> > +   (void) stat(*argv, &tmp_stat);
> > +   else
> > +   (void) lstat(*argv, &tmp_stat);
> > +   #else
> > if (Rflag && (Lflag || Hflag))
> > stat(*argv, &tmp_stat);
> > else
> > lstat(*argv, &tmp_stat);
> > +   #endif
> >
>
> Would it be better to keep each change localized? at first I didn't really 
> care for this approach that was taken in patch 1, but compared to 
> copy-pasting multiple lines of code, it might be simpler to deal with 
> fine-grained modifications, like this:
>
>  if (Rflag && (Lflag || Hflag))
> +   #ifdef __rtems__
> +   (void)
> +   #endif
>  (void) stat(*argv, &tmp_stat);
>
> > if (S_ISDIR(tmp_stat.st_mode) && Rflag)
> > type = DIR_TO_DNE;
> > --
> > 1.8.3.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/3] gen_uuid.c: Ignore return values from fcntl()

2021-03-31 Thread Joel Sherrill 
On Wed, Mar 31, 2021 at 11:13 AM Gedare Bloom  wrote:

> On Wed, Mar 31, 2021 at 9:16 AM Ryan Long  wrote:
> >
> > CID 1049146: Unchecked return value from library in get_clock().
> > CID 1049147: Unchecked return value from library in get_random_fd().
> >
> > Closes #4280
> > ---
> >  cpukit/libmisc/uuid/gen_uuid.c | 8 
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/cpukit/libmisc/uuid/gen_uuid.c
> b/cpukit/libmisc/uuid/gen_uuid.c
> > index 3ca75a0..9cd763d 100644
> > --- a/cpukit/libmisc/uuid/gen_uuid.c
> > +++ b/cpukit/libmisc/uuid/gen_uuid.c
> > @@ -164,8 +164,13 @@ static int get_random_fd(void)
> > fd = open("/dev/random", O_RDONLY | O_NONBLOCK);
> > if (fd >= 0) {
> > i = fcntl(fd, F_GETFD);
> > +   #ifdef __rtems__
> > +   if (i >= 0)
> > +   (void) fcntl(fd, F_SETFD, i |
> FD_CLOEXEC);
> > +   #else
> > if (i >= 0)
> > fcntl(fd, F_SETFD, i | FD_CLOEXEC);
> > +   #endif
> You could do the same thing here as you did below, just put the #ifdef
> after the if (i>=0)
>
> The upstream is
> https://github.com/karelzak/util-linux/blob/master/libuuid/src/gen_uuid.c
> I wonder if we should update?
>

Are you sure that's the master? That's not what the README in the directory
says.

I'm not opposed to updating the code in the directory but I want to make
sure it
comes from the right place.

And do we have any tests to ensure it works if it builds? This wasn't
included
in the last coverage I uploaded but I can ask Alex to turn it on.


> > }
> >  #endif
> > srand((getpid() << ((sizeof(pid_t)*CHAR_BIT)>>1)) ^
> getuid() ^ tv.tv_sec ^ tv.tv_usec);
> > @@ -426,6 +431,9 @@ try_again:
> > }
> > rewind(state_f);
> > fl.l_type = F_UNLCK;
> > +   #ifdef __rtems__
> > +   (void)
> > +   #endif
> > fcntl(state_fd, F_SETLK, &fl);
> > }
> >
> > --
> > 1.8.3.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/3] main_cp.c: Ignore return value from stat()

2021-03-31 Thread Joel Sherrill 
On Wed, Mar 31, 2021 at 11:24 AM Gedare Bloom  wrote:

> On Wed, Mar 31, 2021 at 10:21 AM Ryan Long  wrote:
> >
> > I'm assuming you accidentally left the (void) in after that #endif, but
> that's the approach that Joel and I did first.  After Joel saw it
> implemented, he said it made the code look too messy to him because of the
> if statements.
> >
> Right. The thing is that we aren't looking to make this code clean,
> we're optimizing for easier updates from the upstream. Generally, it
> is easier to undo and redo small changes than large changes.
>

If you are OK with an ugly #if (void) #endif, then I'm OK with it.

It is  ugly either way.

Make the void ifdef'ed. Sorry about the pendulum swinging.


> > -Original Message-
> > From: Gedare Bloom 
> > Sent: Wednesday, March 31, 2021 11:17 AM
> > To: Ryan Long 
> > Cc: devel@rtems.org
> > Subject: Re: [PATCH 2/3] main_cp.c: Ignore return value from stat()
> >
> > On Wed, Mar 31, 2021 at 9:16 AM Ryan Long  wrote:
> > >
> > > CID 26051: Unchecked return value from library in main_cp().
> > >
> > > Closes #4365
> > > ---
> > >  cpukit/libmisc/shell/main_cp.c | 7 +++
> > >  1 file changed, 7 insertions(+)
> > >
> > > diff --git a/cpukit/libmisc/shell/main_cp.c
> > > b/cpukit/libmisc/shell/main_cp.c index cddbc95..bb31a35 100644
> > > --- a/cpukit/libmisc/shell/main_cp.c
> > > +++ b/cpukit/libmisc/shell/main_cp.c
> > > @@ -254,10 +254,17 @@ main_cp(rtems_shell_cp_globals* cp_globals, int
> argc, char *argv[])
> > >  * the initial mkdir().
> > >  */
> > > if (r == -1) {
> > > +   #ifdef __rtems__
> > > +   if (Rflag && (Lflag || Hflag))
> > > +   (void) stat(*argv, &tmp_stat);
> > > +   else
> > > +   (void) lstat(*argv, &tmp_stat);
> > > +   #else
> > > if (Rflag && (Lflag || Hflag))
> > > stat(*argv, &tmp_stat);
> > > else
> > > lstat(*argv, &tmp_stat);
> > > +   #endif
> > >
> >
> > Would it be better to keep each change localized? at first I didn't
> really care for this approach that was taken in patch 1, but compared to
> copy-pasting multiple lines of code, it might be simpler to deal with
> fine-grained modifications, like this:
> >
> >  if (Rflag && (Lflag || Hflag))
> > +   #ifdef __rtems__
> > +   (void)
> > +   #endif
> >  (void) stat(*argv, &tmp_stat);
> >
> > > if (S_ISDIR(tmp_stat.st_mode) && Rflag)
> > > type = DIR_TO_DNE;
> > > --
> > > 1.8.3.1
> > >
> > > ___
> > > devel mailing list
> > > devel@rtems.org
> > > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RE: [PATCH] covoar: Fix off-by-one in Coverage::finalizeSymbol()

2021-03-31 Thread Alex White 
On Wed, Mar 31, 2021 at 11:22 AM Gedare Bloom  wrote:
>
> On Wed, Mar 31, 2021 at 10:05 AM Alex White  wrote:
> >
> > The `rangeIndex` variable is 1 higher than the index at which the first
> > instruction address was found. This fixes the lookup after the loop to
> > account for that fact.
> > ---
> >  tester/covoar/ObjdumpProcessor.cc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tester/covoar/ObjdumpProcessor.cc 
> > b/tester/covoar/ObjdumpProcessor.cc
> > index 62a06c5..1cfa877 100644
> > --- a/tester/covoar/ObjdumpProcessor.cc
> > +++ b/tester/covoar/ObjdumpProcessor.cc
> > @@ -60,7 +60,7 @@ namespace Coverage {
> >          lowAddress = coverageMap.getLowAddressOfRange(rangeIndex);
> >        }
> >
> > -      uint32_t sizeWithoutNops = coverageMap.getSizeOfRange(rangeIndex);
> > +      uint32_t sizeWithoutNops = coverageMap.getSizeOfRange(rangeIndex - 
> > 1);
>
> I guess this is because of the for loop. Maybe, you should prefer to
> exit the for loop with the proper index?

That is what I had before this code was initially reviewed:

for (rangeIndex = 0; ; rangeIndex++) {
  lowAddress = coverageMap.getLowAddressOfRange(rangeIndex);

  if (firstInstructionAddress == lowAddress) {
break;
  }
}

The suggestion was made to move the condition into the loop rather than
use `break`:

for (rangeIndex = 0;
 firstInstructionAddress != lowAddress;
 rangeIndex++) {
  lowAddress = coverageMap.getLowAddressOfRange(rangeIndex);
}

I did that without realizing it wasn't equivalent and didn't run enough
tests to catch it.

Am I missing something here? Could I go back to my first solution? Is
there a more elegant way?

Your most tedious code reviewee,

Alex

:)

>
> Fixing an off-by-1 bug by subtracting one from the point of
> consumption is a good way to ensure the bug occurs again if anyone
> reuses the rangeIndex variable later.

That is true.

>
> >        uint32_t size = sizeWithoutNops;
> >        uint32_t highAddress = lowAddress + size - 1;
> >        uint32_t computedHighAddress = highAddress;
> > --
> > 2.27.0
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/3] misc/wscript: Specify C language version

2021-03-31 Thread Joel Sherrill 
On Wed, Mar 31, 2021 at 9:56 AM Gedare Bloom  wrote:

> Should we set the cstd version at the top-level?
>

That's not what was done for C++ when I looked for examples. I suppose this
lets the C++ version vary by tool or library. And we did import some
third-party
code.

--joel


>
> On Tue, Mar 30, 2021 at 3:16 PM Joel Sherrill  wrote:
> >
> > CentOS 7 has gcc 4.8 which defaults to C90 and this results in warnings
> > for code that is valid C99 but not C90.
> > ---
> >  misc/wscript | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/misc/wscript b/misc/wscript
> > index 521eddf..21e7f75 100644
> > --- a/misc/wscript
> > +++ b/misc/wscript
> > @@ -51,7 +51,8 @@ def build(bld):
> >  #
> >  conf['warningflags'] = ['-Wall', '-Wextra', '-pedantic']
> >  conf['optflags'] = bld.env.C_OPTS
> > -conf['cflags'] = ['-pipe', '-g'] + conf['optflags']
> > +cstd = '-std=c99'
> > +conf['cflags'] = [cstd] + ['-pipe', '-g'] + conf['optflags']
> >  conf['linkflags'] = ['-g']
> >
> >  #
> > --
> > 1.8.3.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 1/3] gen_uuid.c: Ignore return values from fcntl()

2021-03-31 Thread Gedare Bloom 
On Wed, Mar 31, 2021 at 10:35 AM Joel Sherrill  wrote:
>
>
>
> On Wed, Mar 31, 2021 at 11:13 AM Gedare Bloom  wrote:
>>
>> On Wed, Mar 31, 2021 at 9:16 AM Ryan Long  wrote:
>> >
>> > CID 1049146: Unchecked return value from library in get_clock().
>> > CID 1049147: Unchecked return value from library in get_random_fd().
>> >
>> > Closes #4280
>> > ---
>> >  cpukit/libmisc/uuid/gen_uuid.c | 8 
>> >  1 file changed, 8 insertions(+)
>> >
>> > diff --git a/cpukit/libmisc/uuid/gen_uuid.c 
>> > b/cpukit/libmisc/uuid/gen_uuid.c
>> > index 3ca75a0..9cd763d 100644
>> > --- a/cpukit/libmisc/uuid/gen_uuid.c
>> > +++ b/cpukit/libmisc/uuid/gen_uuid.c
>> > @@ -164,8 +164,13 @@ static int get_random_fd(void)
>> > fd = open("/dev/random", O_RDONLY | O_NONBLOCK);
>> > if (fd >= 0) {
>> > i = fcntl(fd, F_GETFD);
>> > +   #ifdef __rtems__
>> > +   if (i >= 0)
>> > +   (void) fcntl(fd, F_SETFD, i | FD_CLOEXEC);
>> > +   #else
>> > if (i >= 0)
>> > fcntl(fd, F_SETFD, i | FD_CLOEXEC);
>> > +   #endif
>> You could do the same thing here as you did below, just put the #ifdef
>> after the if (i>=0)
>>
>> The upstream is
>> https://github.com/karelzak/util-linux/blob/master/libuuid/src/gen_uuid.c
>> I wonder if we should update?
>
>
> Are you sure that's the master? That's not what the README in the directory 
> says.
>
> I'm not opposed to updating the code in the directory but I want to make sure 
> it
> comes from the right place.
>
OK, I see there is
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/tree/lib/uuid
and there is the util-linux. I don't know how they are related and
whether they have forked from each other.

You're right, the e2fsprogs is the right upstream. I think they have
diverged, and it seems that the util-linux is more cactive and more
likely to be maintained into the future.

https://github.com/karelzak/util-linux/commits/master/libuuid/src
https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git/log/lib/uuid

That's as far down the Linux ecosystem rabbit hole I want to go.

> And do we have any tests to ensure it works if it builds? This wasn't included
> in the last coverage I uploaded but I can ask Alex to turn it on.
>
IDK anything about that either.

>>
>> > }
>> >  #endif
>> > srand((getpid() << ((sizeof(pid_t)*CHAR_BIT)>>1)) ^ 
>> > getuid() ^ tv.tv_sec ^ tv.tv_usec);
>> > @@ -426,6 +431,9 @@ try_again:
>> > }
>> > rewind(state_f);
>> > fl.l_type = F_UNLCK;
>> > +   #ifdef __rtems__
>> > +   (void)
>> > +   #endif
>> > fcntl(state_fd, F_SETLK, &fl);
>> > }
>> >
>> > --
>> > 1.8.3.1
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] covoar: Fix off-by-one in Coverage::finalizeSymbol()

2021-03-31 Thread Gedare Bloom 
On Wed, Mar 31, 2021 at 10:42 AM Alex White  wrote:
>
> On Wed, Mar 31, 2021 at 11:22 AM Gedare Bloom  wrote:
> >
> > On Wed, Mar 31, 2021 at 10:05 AM Alex White  wrote:
> > >
> > > The `rangeIndex` variable is 1 higher than the index at which the first
> > > instruction address was found. This fixes the lookup after the loop to
> > > account for that fact.
> > > ---
> > >  tester/covoar/ObjdumpProcessor.cc | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/tester/covoar/ObjdumpProcessor.cc 
> > > b/tester/covoar/ObjdumpProcessor.cc
> > > index 62a06c5..1cfa877 100644
> > > --- a/tester/covoar/ObjdumpProcessor.cc
> > > +++ b/tester/covoar/ObjdumpProcessor.cc
> > > @@ -60,7 +60,7 @@ namespace Coverage {
> > >  lowAddress = coverageMap.getLowAddressOfRange(rangeIndex);
> > >}
> > >
> > > -  uint32_t sizeWithoutNops = coverageMap.getSizeOfRange(rangeIndex);
> > > +  uint32_t sizeWithoutNops = coverageMap.getSizeOfRange(rangeIndex - 
> > > 1);
> >
> > I guess this is because of the for loop. Maybe, you should prefer to
> > exit the for loop with the proper index?
>
> That is what I had before this code was initially reviewed:
>
> for (rangeIndex = 0; ; rangeIndex++) {
>   lowAddress = coverageMap.getLowAddressOfRange(rangeIndex);
>
>   if (firstInstructionAddress == lowAddress) {
> break;
>   }
> }
>
> The suggestion was made to move the condition into the loop rather than
> use `break`:
>
> for (rangeIndex = 0;
>  firstInstructionAddress != lowAddress;
>  rangeIndex++) {
>   lowAddress = coverageMap.getLowAddressOfRange(rangeIndex);
> }
>
> I did that without realizing it wasn't equivalent and didn't run enough
> tests to catch it.
>
> Am I missing something here? Could I go back to my first solution? Is
> there a more elegant way?
>

Yes, since the first iteration will always happen, and you want to end
with the 'right' value in the iterator, a do-while loop is more
appropriate.

> Your most tedious code reviewee,
>
> Alex
>
> :)
>
> >
> > Fixing an off-by-1 bug by subtracting one from the point of
> > consumption is a good way to ensure the bug occurs again if anyone
> > reuses the rangeIndex variable later.
>
> That is true.
>
> >
> > >uint32_t size = sizeWithoutNops;
> > >uint32_t highAddress = lowAddress + size - 1;
> > >uint32_t computedHighAddress = highAddress;
> > > --
> > > 2.27.0
> > >
> > > ___
> > > devel mailing list
> > > devel@rtems.org
> > > http://lists.rtems.org/mailman/listinfo/devel
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/3] misc/wscript: Specify C language version

2021-03-31 Thread Gedare Bloom 
On Wed, Mar 31, 2021 at 10:44 AM Joel Sherrill  wrote:
>
>
>
> On Wed, Mar 31, 2021 at 9:56 AM Gedare Bloom  wrote:
>>
>> Should we set the cstd version at the top-level?
>
>
> That's not what was done for C++ when I looked for examples. I suppose this
> lets the C++ version vary by tool or library. And we did import some 
> third-party
> code.
>
ok, not a big deal to me, just thinking that setting a baseline
(especially for C) makes sense.

> --joel
>
>>
>>
>> On Tue, Mar 30, 2021 at 3:16 PM Joel Sherrill  wrote:
>> >
>> > CentOS 7 has gcc 4.8 which defaults to C90 and this results in warnings
>> > for code that is valid C99 but not C90.
>> > ---
>> >  misc/wscript | 3 ++-
>> >  1 file changed, 2 insertions(+), 1 deletion(-)
>> >
>> > diff --git a/misc/wscript b/misc/wscript
>> > index 521eddf..21e7f75 100644
>> > --- a/misc/wscript
>> > +++ b/misc/wscript
>> > @@ -51,7 +51,8 @@ def build(bld):
>> >  #
>> >  conf['warningflags'] = ['-Wall', '-Wextra', '-pedantic']
>> >  conf['optflags'] = bld.env.C_OPTS
>> > -conf['cflags'] = ['-pipe', '-g'] + conf['optflags']
>> > +cstd = '-std=c99'
>> > +conf['cflags'] = [cstd] + ['-pipe', '-g'] + conf['optflags']
>> >  conf['linkflags'] = ['-g']
>> >
>> >  #
>> > --
>> > 1.8.3.1
>> >
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH v2] covoar: Fix off-by-one in Coverage::finalizeSymbol()

2021-03-31 Thread Alex White 
The `rangeIndex` variable is 1 higher than the index at which the first
instruction address was found. This fixes the loop to set `rangeIndex`
correctly.
---
 tester/covoar/ObjdumpProcessor.cc | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/tester/covoar/ObjdumpProcessor.cc 
b/tester/covoar/ObjdumpProcessor.cc
index 62a06c5..c2ed3d5 100644
--- a/tester/covoar/ObjdumpProcessor.cc
+++ b/tester/covoar/ObjdumpProcessor.cc
@@ -52,13 +52,12 @@ namespace Coverage {
 throw rld::error( what, "Coverage::finalizeSymbol" );
   }
 
-  int rangeIndex;
+  int rangeIndex = -1;
   uint32_t lowAddress = UINT32_MAX;
-  for (rangeIndex = 0;
-   firstInstructionAddress != lowAddress;
-   rangeIndex++) {
+  do {
+rangeIndex++;
 lowAddress = coverageMap.getLowAddressOfRange(rangeIndex);
-  }
+  } while (firstInstructionAddress != lowAddress);
 
   uint32_t sizeWithoutNops = coverageMap.getSizeOfRange(rangeIndex);
   uint32_t size = sizeWithoutNops;
-- 
2.27.0

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

Re: [PATCH v2] covoar: Fix off-by-one in Coverage::finalizeSymbol()

2021-03-31 Thread Gedare Bloom 
ok

On Wed, Mar 31, 2021 at 11:22 AM Alex White  wrote:
>
> The `rangeIndex` variable is 1 higher than the index at which the first
> instruction address was found. This fixes the loop to set `rangeIndex`
> correctly.
> ---
>  tester/covoar/ObjdumpProcessor.cc | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/tester/covoar/ObjdumpProcessor.cc 
> b/tester/covoar/ObjdumpProcessor.cc
> index 62a06c5..c2ed3d5 100644
> --- a/tester/covoar/ObjdumpProcessor.cc
> +++ b/tester/covoar/ObjdumpProcessor.cc
> @@ -52,13 +52,12 @@ namespace Coverage {
>  throw rld::error( what, "Coverage::finalizeSymbol" );
>}
>
> -  int rangeIndex;
> +  int rangeIndex = -1;
>uint32_t lowAddress = UINT32_MAX;
> -  for (rangeIndex = 0;
> -   firstInstructionAddress != lowAddress;
> -   rangeIndex++) {
> +  do {
> +rangeIndex++;
>  lowAddress = coverageMap.getLowAddressOfRange(rangeIndex);
> -  }
> +  } while (firstInstructionAddress != lowAddress);
>
>uint32_t sizeWithoutNops = coverageMap.getSizeOfRange(rangeIndex);
>uint32_t size = sizeWithoutNops;
> --
> 2.27.0
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

GSoC Project : Packaging Programming Language for RTEMS

2021-03-31 Thread Eshan Dhawan 
Hello everyone,
For this GSoC I was planning to package programming language

- Adding an RSB recipe
- Example having at least bare-metal embedded configuration and use of
custom commands
- integrating with rtems shell
- write test script (I would have to go through that part )
and wrap all up with documentation

What would be the preferred starting programming language ?
and Is there any RSB Recipe that I an refer to as example ??
-- 
Thanks
- Eshan
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[libbsd] How to install machine header files?

2021-03-31 Thread Jan.Sommer 
Hello,

I stumbled upon some include path problems in libbsd while looking at Chris' 
ptpd port and I am not sure what is the recommended way to solve it.
It starts with "freebsd/sys/sys/bus.h" including "machine/_bus.h".
Currently, this will be the one from within "rtemsbd" which will redirect to 
"rtemsbsd/include/machine/bus.h" which is amd64 specific.
For the pc686 BSP this will create a compile error for applications which 
include "".

I tried to solve it by removing the "_bus.h" in rtemsbsd and installing the 
correct one from "freebsd/sys/i386/include/machine/_bus.h", but I am not sure 
how to tell waf to install the file.
Is there a way to add a single architecture specific header to the install 
headers?
I could add a corresponding path and wildcard to the "header-paths" in 
libbsd.py, but I am not sure if this is the right place.

Best regards,

Jan


Deutsches Zentrum für Luft- und Raumfahrt e. V. (DLR)
German Aerospace Center
Institute for Software Technology | Software for Space Systems and Interactive 
Visualization | Lilienthalplatz 7 | 38108 Braunschweig | Germany


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

Re: [PATCH rtems-docs] common/latex.py: use distro module for python3.5 and up

2021-03-31 Thread Chris Johns 
Do we need to support platform as well? I have lost track of which Python we
need build doco. I suspect it is only 3.

Chris

On 24/3/21 7:05 am, Vijay Kumar Banerjee wrote:
> ---
>  common/latex.py | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/common/latex.py b/common/latex.py
> index a042510..a1b3917 100644
> --- a/common/latex.py
> +++ b/common/latex.py
> @@ -3,8 +3,11 @@
>  #
>  
>  import os
> -import platform
>  import re
> +try:
> +from distro import linux_distribution
> +except:
> +from platform import linux_distribution
>  
>  package_test_preamble = ['\\newif\\ifsphinxKeepOldNames 
> \\sphinxKeepOldNamestrue',
>   '\documentclass[a4paper,11pt,english]{report}']
> @@ -82,7 +85,7 @@ def tex_test(test):
>  def host_name():
>  uname = os.uname()
>  if uname[0] == 'Linux':
> -distro = platform.dist()
> +distro = linux_distribution()
>  name = '%s/%s' % (uname[0], distro[0])
>  version = distro[1]
>  else:
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-libbsd] libbsd.py: Build i2c shell command

2021-03-31 Thread Chris Johns 
I am fine with this. I did not know it existed.

On 27/3/21 7:40 am, Vijay Kumar Banerjee wrote:
> ---
>  libbsd.py | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/libbsd.py b/libbsd.py
> index f7efda43..fe0566e7 100644
> --- a/libbsd.py
> +++ b/libbsd.py
> @@ -258,6 +258,7 @@ class rtems(builder.Module):
>  'rtems/rtems-bsd-rc-conf.c',
>  'rtems/rtems-bsd-set-if-input.c',
>  'rtems/rtems-bsd-shell-arp.c',
> +'rtems/rtems-bsd-shell-i2c.c',
>  'rtems/rtems-bsd-shell-ifconfig.c',
>  'rtems/rtems-bsd-shell-ifmcstat.c',
>  'rtems/rtems-bsd-shell-netstat.c',
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [rtems-tools commit] rld-process: Add named tempfile constructor

2021-03-31 Thread Chris Johns 
On 1/4/21 2:26 am, Alex White wrote:
> On Tue, Mar 30, 2021 at 10:30 PM Chris Johns  wrote:
>>
>> Hi,
>>
>> When I looked at this on vc@ I saw it is broken. I am sorry I did not pick 
>> this
>> up in the review.
>>
>> On 31/3/21 5:20 am, Joel Sherrill wrote:
>>> Module:    rtems-tools
>>> Branch:    master
>>> Commit:    420d7a13672991a1480d06ac02190f2976b9253b
>>> Changeset: 
>>> http://git.rtems.org/rtems-tools/commit/?id=420d7a13672991a1480d06ac02190f2976b9253b
>>>
>>> Author:    Alex White 
>>> Date:      Wed Mar  3 09:48:00 2021 -0600
>>>
>>> rld-process: Add named tempfile constructor
>>>
>>> This adds a new tempfile constructor for creating a named tempfile
>>> rather than generating the name.
>>>
>>> ---
>>>
>>>  rtemstoolkit/rld-process.cpp | 11 +++
>>>  rtemstoolkit/rld-process.h   |  7 +++
>>>  2 files changed, 18 insertions(+)
>>>
>>> diff --git a/rtemstoolkit/rld-process.cpp b/rtemstoolkit/rld-process.cpp
>>> index 30e0605..4160759 100644
>>> --- a/rtemstoolkit/rld-process.cpp
>>> +++ b/rtemstoolkit/rld-process.cpp
>>> @@ -169,6 +169,17 @@ namespace rld
>>>        _name = temporaries.get (suffix, _keep);
>>>      }
>>>
>>> +    tempfile::tempfile (const std::string& name,
>>> +                        const std::string& suffix,
>>> +                        bool               _keep)
>>
>> As a side issue this should be `keep` and not `_keep`. Could this please be
>> fixed with fix that is needed.
>>
>>> +      : _name(name + suffix),
>>> +        suffix(suffix),
>>> +        overridden (false),
>>> +        fd (-1),
>>> +        level (0)
>>> +    {
>>> +    }
>>
>> This constructor is empty and so the file is not created in the temp path on
>> Unix or Windows and it is not registered to be deleted. I am sorry I did not
>> notice this before. How was this change tested?
>>
>> Now I think about this change I am not sure it is right. Why you are using 
>> this
>> interface when the file is not in a temp directory and is not being deleted?
> 
> Hi Chris,
> 
> This patch set up the interfaces used in the "covoar: Add option to create 
> named objdumps" patch that I sent.
> 
> We determined that patch was not needed given its hacked-togetherness along 
> with future speedups that we had in mind which would make it obsolete anyway.
> 
> This patch should have been removed from the set to be committed, but I 
> forgot to send out a notice to exclude it. Sorry for the confusion.
> 
> This commit should be reverted.

Ah OK. Could you or Joel please close #4368 with this as a comment?

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

Re: [PATCH rtems-libbsd] libbsd.py: Build i2c shell command

2021-03-31 Thread Vijay Kumar Banerjee 
On Wed, Mar 31, 2021 at 4:20 PM Chris Johns  wrote:
>
> I am fine with this. I did not know it existed.
>
Thanks. Pushed.

Best regards,
Vijay
> On 27/3/21 7:40 am, Vijay Kumar Banerjee wrote:
> > ---
> >  libbsd.py | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libbsd.py b/libbsd.py
> > index f7efda43..fe0566e7 100644
> > --- a/libbsd.py
> > +++ b/libbsd.py
> > @@ -258,6 +258,7 @@ class rtems(builder.Module):
> >  'rtems/rtems-bsd-rc-conf.c',
> >  'rtems/rtems-bsd-set-if-input.c',
> >  'rtems/rtems-bsd-shell-arp.c',
> > +'rtems/rtems-bsd-shell-i2c.c',
> >  'rtems/rtems-bsd-shell-ifconfig.c',
> >  'rtems/rtems-bsd-shell-ifmcstat.c',
> >  'rtems/rtems-bsd-shell-netstat.c',
> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs] common/latex.py: use distro module for python3.5 and up

2021-03-31 Thread Vijay Kumar Banerjee 
On Wed, Mar 31, 2021 at 4:19 PM Chris Johns  wrote:
>
> Do we need to support platform as well? I have lost track of which Python we
> need build doco. I suspect it is only 3.

platform.dist is deprecated since 3.5 and removed in 3.7, so this was
certainly a piece of code that would fail with python>= 3.7, which
made me think that maybe python2 is still being used to build docs so
kept the platform import.


>
> Chris
>
> On 24/3/21 7:05 am, Vijay Kumar Banerjee wrote:
> > ---
> >  common/latex.py | 7 +--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >
> > diff --git a/common/latex.py b/common/latex.py
> > index a042510..a1b3917 100644
> > --- a/common/latex.py
> > +++ b/common/latex.py
> > @@ -3,8 +3,11 @@
> >  #
> >
> >  import os
> > -import platform
> >  import re
> > +try:
> > +from distro import linux_distribution
> > +except:
> > +from platform import linux_distribution
> >
> >  package_test_preamble = ['\\newif\\ifsphinxKeepOldNames 
> > \\sphinxKeepOldNamestrue',
> >   '\documentclass[a4paper,11pt,english]{report}']
> > @@ -82,7 +85,7 @@ def tex_test(test):
> >  def host_name():
> >  uname = os.uname()
> >  if uname[0] == 'Linux':
> > -distro = platform.dist()
> > +distro = linux_distribution()
> >  name = '%s/%s' % (uname[0], distro[0])
> >  version = distro[1]
> >  else:
> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs] common/latex.py: use distro module for python3.5 and up

2021-03-31 Thread Chris Johns 
On 1/4/21 11:03 am, Vijay Kumar Banerjee wrote:
> On Wed, Mar 31, 2021 at 4:19 PM Chris Johns  wrote:
>>
>> Do we need to support platform as well? I have lost track of which Python we
>> need build doco. I suspect it is only 3.
> 
> platform.dist is deprecated since 3.5 and removed in 3.7, so this was
> certainly a piece of code that would fail with python>= 3.7, which
> made me think that maybe python2 is still being used to build docs so
> kept the platform import.

Thank you for the explanation.

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

Re: [PATCH] rld-cc: Add -target to recognised cflags

2021-03-31 Thread Chris Johns 
On 1/4/21 3:04 am, Gedare Bloom wrote:
> On Wed, Mar 31, 2021 at 12:19 AM Hesham Almatary
>  wrote:
>>
>> Ping
>>
> Go ahead if you tested with gcc also.

Fine with me.

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

Re: [rtems5 PATCH 0/5] Backport zynq SPI drivers to rtems5

2021-03-31 Thread Chris Johns 
Hi Jan,

This looks good. Has this been tested on zync hardware? If no then some testing
is needed and if yes then please push.

Thanks
Chris

On 31/3/21 8:06 pm, Jan Sommer wrote:
> This patchset backports:
> - The cadence SPI driver (see: https://devel.rtems.org/ticket/4369)
> - The xilinx axi SPI driver (see: https://devel.rtems.org/ticket/4370)
> - The i2c and spi shell commands (see: https://devel.rtems.org/ticket/4371)
> 
> For the SPI drivers I didn't change any code (except the include paths)
> I put them in bsps/arm/shared instead of bsps/shared, since rtems5 has
> no aarch64 BSPs which could use them.
> 
> From Christian's commit I only stripped the part for the waf build
> system. I found the commands quite handy during driver development and
> testing.
> 
> Best regards,
> 
> Jan
> 
> Christian Mauderer (1):
>   shell: Add i2c and spi commands
> 
> Jan Sommer (4):
>   bsps/xilinx_zynq: Add SPI driver for cadence-spi
>   bsps/xilinx_zynq: Add cadence SPI driver to build system
>   bsps/xilinx_zynq: Add SPI driver for xilinx-axi-spi
>   bsps/xilinx_zynq: Add Xilinx AXI SPI driver to build
> 
>  bsps/arm/headers.am   |   4 +
>  bsps/arm/include/bsp/cadence-spi-regs.h   |  84 
>  bsps/arm/include/bsp/cadence-spi.h|  63 +++
>  bsps/arm/include/bsp/xilinx-axi-spi-regs.h|  88 
>  bsps/arm/include/bsp/xilinx-axi-spi.h |  67 +++
>  bsps/arm/shared/spi/cadence-spi.c | 444 ++
>  bsps/arm/shared/spi/xilinx-axi-spi.c  | 402 
>  c/src/lib/libbsp/arm/xilinx-zynq/Makefile.am  |   4 +
>  .../lib/libbsp/arm/xilinx-zynqmp/Makefile.am  |   4 +
>  cpukit/Makefile.am|   4 +
>  cpukit/include/rtems/shellconfig.h|  28 ++
>  cpukit/libmisc/shell/main_i2cdetect.c | 107 +
>  cpukit/libmisc/shell/main_i2cget.c| 145 ++
>  cpukit/libmisc/shell/main_i2cset.c| 124 +
>  cpukit/libmisc/shell/main_spi.c   | 157 +++
>  15 files changed, 1725 insertions(+)
>  create mode 100644 bsps/arm/include/bsp/cadence-spi-regs.h
>  create mode 100644 bsps/arm/include/bsp/cadence-spi.h
>  create mode 100644 bsps/arm/include/bsp/xilinx-axi-spi-regs.h
>  create mode 100644 bsps/arm/include/bsp/xilinx-axi-spi.h
>  create mode 100644 bsps/arm/shared/spi/cadence-spi.c
>  create mode 100644 bsps/arm/shared/spi/xilinx-axi-spi.c
>  create mode 100644 cpukit/libmisc/shell/main_i2cdetect.c
>  create mode 100644 cpukit/libmisc/shell/main_i2cget.c
>  create mode 100644 cpukit/libmisc/shell/main_i2cset.c
>  create mode 100644 cpukit/libmisc/shell/main_spi.c
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC project: #3850 Modular Network Stacks

2021-03-31 Thread Rajiv Vaidyanathan 
Dear mentors,

Thank you for providing information regarding the project. I have started
making the proposal for this ticket. I'll share it once I have a draft of
it ready.

Thanks and regards,
Rajiv

On Mon, 22 Mar 2021 at 21:43, Joel Sherrill  wrote:

>
>
> On Mon, Mar 22, 2021, 10:23 AM Christian Mauderer 
> wrote:
>
>> Hello Rajiv,
>>
>> Am 22.03.21 um 16:11 schrieb Rajiv Vaidyanathan:
>> > Dear mentors,
>> >
>> > Thankyou for providing information about the project. I want to pursue
>> > this as my GSoC project. From the above discussion, I understand that
>> > the following has to be done:
>> > 1. Collecting existing lwip drivers for BSPs and writing new ones.
>> > 2. Adding config files for driver management and also add lwip to the
>> > choice of networking stacks for RTEMS.
>> > 3. Write tests, examples and documentation
>> >
>>
>> The main point will be to create a build repo for lwip similar to the
>> repo for libbsd or the legacy stack (that is currently work in
>> progress). That repo should contain maybe one or two drivers as an
>> example how they should be integrated into the repo. You don't have to
>> find all possible drivers for all BSPs.
>>
>> That repo should contain tests and there should be at least basic
>> documentation how to use it. More documentation is better ;-)
>>
>> > Please let me know if I am missing anything.
>> >
>> > I have the following queries:
>> > 1. Should I buy a Beaglebone or can I do everything with QEMU? I have a
>> > Raspberry Pi 3B+. Can I use it for hardware testing instead?
>>
>> Basically every BSP should work as long as you find a lwip driver that
>> can work with it. I would suggest to look at the xilinx_zynq_a9_qemu and
>> whether you can find a driver for that. It works well with libbsd and an
>> emulated "cadence_gem" network interface. If you find a lwip driver for
>> that, it would be easy to debug that.
>>
>
> I'm prone to say the first focus should be on drivers that we can test
> with simulators specifically qemu.  That puts the Zynq, MPSoC, and PC high
> on the list. My second tier would be those we know have users now which is
> the STM H7 and whatever Alan Cudmore is using. For that tier, it should
> have just be helping merge and letting them test.
>
> Focusing on what can work on qemu and what users are actively using lwip
> on now should result in having a solid core of drivers to build from in the
> future. And it should avoid the pain of debugging a driver on real hardware
> while leaving the project with some that are easy to test.
>
>
>> If you want to use a Raspberry, that is OK too. But I'm not entirely
>> sure whether RTEMS run well out of the box on Raspberry 3B+. So please
>> test that before you focus too much on that platform. Also note that
>> debugging on a Raspberry needs extra hardware (same is true for
>> debugging on a Beagle). You most likely won't need too much debugging of
>> applications but it's nice to have it as a fall back if something
>> doesn't work.
>>
>
> I do not think anything newer than a raspberry 2 works without addressing
> some issues. This could easily turned into a time sucker that will have no
> benefit to having an lwip package.
>
>>
>> > 2. I have cloned the rtems-lwip repository. Is there any open issue and
>> > documentation I can look into to get more understanding about this
>> repos
>> > and the project in general?
>>
>> It's a personal repo of Vijay. So he might can give you some information
>> about it. I don't think that there is much documentation.
>>
>> Best regards
>>
>> Christian
>>
>> >
>> > Thanks and regards,
>> > Rajiv
>> >
>> > On Mon, 22 Mar 2021 at 01:06, Christian Mauderer > > > wrote:
>> >
>> >
>> >
>> > On 21/03/2021 18:53, Joel Sherrill wrote:
>> >  >
>> >  >
>> >  > On Sun, Mar 21, 2021, 12:47 PM Vijay Kumar Banerjee
>> > mailto:vi...@rtems.org>
>> >  > >> wrote:
>> >  >
>> >  > Hi Rajiv and Joel,
>> >  >
>> >  > On Sun, Mar 21, 2021 at 9:06 AM Joel Sherrill <
>> j...@rtems.org
>> > 
>> >  > >> wrote:
>> >  >  >
>> >  >  >
>> >  >  >
>> >  >  > On Sun, Mar 21, 2021, 9:20 AM Rajiv Vaidyanathan
>> >  > > > 
>> >  > > > >> wrote:
>> >  >  >>
>> >  >  >> Hello RTEMS community,
>> >  >  >>
>> >  >  >> I found the ticket: Modular Network Stacks interesting.
>> > It would
>> >  > be great if someone can tell the current status of this
>> > ticket and
>> >  > what contributions can be done as a GSoC project.
>> >  >  >>
>> >  >  >> In the prerequisites list given, I have experience in
>> UNIX
>> >  > socket programming (in C and python),

Re: [libbsd] How to install machine header files?

2021-03-31 Thread Chris Johns 
On 1/4/21 6:37 am, jan.som...@dlr.de wrote:
> Hello,
> 
> I stumbled upon some include path problems in libbsd while looking at Chris' 
> ptpd port and I am not sure what is the recommended way to solve it.
> It starts with "freebsd/sys/sys/bus.h" including "machine/_bus.h".
> Currently, this will be the one from within "rtemsbd" which will redirect to 
> "rtemsbsd/include/machine/bus.h" which is amd64 specific.
> For the pc686 BSP this will create a compile error for applications which 
> include "".

OK.

> I tried to solve it by removing the "_bus.h" in rtemsbsd and installing the 
> correct one from "freebsd/sys/i386/include/machine/_bus.h", but I am not sure 
> how to tell waf to install the file.
> Is there a way to add a single architecture specific header to the install 
> headers?

Yes 

https://git.rtems.org/rtems-libbsd/tree/libbsd.py#n111
https://git.rtems.org/rtems-libbsd/tree/libbsd.py#n2903

> I could add a corresponding path and wildcard to the "header-paths" in 
> libbsd.py, but I am not sure if this is the right place.

I think the PCI module is the place to handle this. I am sorry but I cannot see
the issue clear at the moment and I cannot invest time performing a build.

The addCPUDependentFreeBSDHeaderFiles() on line 2931 of libbsd.py in the PCI
module looks a little suspect because there is no list of archs provided. Could
the issue be as simple as the list of archs is not there and the list is empty?

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