[PATCH rtems 1/9] Add License file for BSD-3-Clause

2020-11-17 Thread Christian Mauderer 
We have some files with a SPDX identifier for this license. Therefore
the license should be here too.
---
 LICENSE.BSD-3-Clause | 27 +++
 1 file changed, 27 insertions(+)
 create mode 100644 LICENSE.BSD-3-Clause

diff --git a/LICENSE.BSD-3-Clause b/LICENSE.BSD-3-Clause
new file mode 100644
index 00..09d01c1ff5
--- /dev/null
+++ b/LICENSE.BSD-3-Clause
@@ -0,0 +1,27 @@
+https://spdx.org/licenses/BSD-3-Clause
+
+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.
+3. Neither the name of the copyright holder nor the names of its
+   contributors may be used to endorse or promote products derived
+   from this software without specific prior written permission.
+
+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
+HOLDER 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.
-- 
2.26.2

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

[PATCH rtems 2/9] imx: Move imx_iomux to arm/shared

2020-11-17 Thread Christian Mauderer 
Update #4180
---
 bsps/arm/imx/headers.am   |  2 -
 bsps/arm/imx/include/bsp.h|  3 +-
 bsps/arm/shared/headers.am|  6 +++
 .../include/arm/freescale/imx/imx_iomuxreg.h  |  0
 .../include/arm/freescale/imx/imx_iomuxvar.h  |  0
 bsps/arm/shared/include/bsp/imx-iomux.h   | 49 +++
 .../{imx/start => shared/pins}/imx_iomux.c|  0
 c/src/lib/libbsp/arm/imx/Makefile.am  |  2 +-
 spec/build/bsps/arm/imx/bspimx.yml| 10 ++--
 9 files changed, 63 insertions(+), 9 deletions(-)
 create mode 100644 bsps/arm/shared/headers.am
 rename bsps/arm/{imx => shared}/include/arm/freescale/imx/imx_iomuxreg.h (100%)
 rename bsps/arm/{imx => shared}/include/arm/freescale/imx/imx_iomuxvar.h (100%)
 create mode 100644 bsps/arm/shared/include/bsp/imx-iomux.h
 rename bsps/arm/{imx/start => shared/pins}/imx_iomux.c (100%)

diff --git a/bsps/arm/imx/headers.am b/bsps/arm/imx/headers.am
index 9863f34300..e7a2418dea 100644
--- a/bsps/arm/imx/headers.am
+++ b/bsps/arm/imx/headers.am
@@ -11,8 +11,6 @@ include_arm_freescale_imx_HEADERS += 
../../../../../../bsps/arm/imx/include/arm/
 include_arm_freescale_imx_HEADERS += 
../../../../../../bsps/arm/imx/include/arm/freescale/imx/imx_ecspireg.h
 include_arm_freescale_imx_HEADERS += 
../../../../../../bsps/arm/imx/include/arm/freescale/imx/imx_gpcreg.h
 include_arm_freescale_imx_HEADERS += 
../../../../../../bsps/arm/imx/include/arm/freescale/imx/imx_i2creg.h
-include_arm_freescale_imx_HEADERS += 
../../../../../../bsps/arm/imx/include/arm/freescale/imx/imx_iomuxreg.h
-include_arm_freescale_imx_HEADERS += 
../../../../../../bsps/arm/imx/include/arm/freescale/imx/imx_iomuxvar.h
 include_arm_freescale_imx_HEADERS += 
../../../../../../bsps/arm/imx/include/arm/freescale/imx/imx_srcreg.h
 include_arm_freescale_imx_HEADERS += 
../../../../../../bsps/arm/imx/include/arm/freescale/imx/imx_uartreg.h
 include_arm_freescale_imx_HEADERS += 
../../../../../../bsps/arm/imx/include/arm/freescale/imx/imx_wdogreg.h
diff --git a/bsps/arm/imx/include/bsp.h b/bsps/arm/imx/include/bsp.h
index 99b7a0d1d7..c7e33985a9 100644
--- a/bsps/arm/imx/include/bsp.h
+++ b/bsps/arm/imx/include/bsp.h
@@ -42,6 +42,7 @@
 #include 
 
 #include 
+#include 
 
 #ifdef __cplusplus
 extern "C" {
@@ -59,8 +60,6 @@ extern uintptr_t imx_gic_dist_base;
 
 void *imx_get_reg_of_node(const void *fdt, int node);
 
-int imx_iomux_configure_pins(const void *fdt, uint32_t phandle);
-
 rtems_vector_number imx_get_irq_of_node(
   const void *fdt,
   int node,
diff --git a/bsps/arm/shared/headers.am b/bsps/arm/shared/headers.am
new file mode 100644
index 00..4fd7238f81
--- /dev/null
+++ b/bsps/arm/shared/headers.am
@@ -0,0 +1,6 @@
+## This file was generated by "./boostrap -H".
+
+include_arm_freescale_imxdir = $(includedir)/arm/freescale/imx
+include_arm_freescale_imx_HEADERS =
+include_arm_freescale_imx_HEADERS += 
../../../../../../bsps/arm/shared/include/arm/freescale/imx/imx_iomuxreg.h
+include_arm_freescale_imx_HEADERS += 
../../../../../../bsps/arm/shared/include/arm/freescale/imx/imx_iomuxvar.h
diff --git a/bsps/arm/imx/include/arm/freescale/imx/imx_iomuxreg.h 
b/bsps/arm/shared/include/arm/freescale/imx/imx_iomuxreg.h
similarity index 100%
rename from bsps/arm/imx/include/arm/freescale/imx/imx_iomuxreg.h
rename to bsps/arm/shared/include/arm/freescale/imx/imx_iomuxreg.h
diff --git a/bsps/arm/imx/include/arm/freescale/imx/imx_iomuxvar.h 
b/bsps/arm/shared/include/arm/freescale/imx/imx_iomuxvar.h
similarity index 100%
rename from bsps/arm/imx/include/arm/freescale/imx/imx_iomuxvar.h
rename to bsps/arm/shared/include/arm/freescale/imx/imx_iomuxvar.h
diff --git a/bsps/arm/shared/include/bsp/imx-iomux.h 
b/bsps/arm/shared/include/bsp/imx-iomux.h
new file mode 100644
index 00..60421807c0
--- /dev/null
+++ b/bsps/arm/shared/include/bsp/imx-iomux.h
@@ -0,0 +1,49 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSBSPsARM
+ *
+ * @brief Functions for imx iomux.
+ */
+
+/*
+ * Copyright (C) 2020 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, INDI

[PATCHES] Add imxrt BSP

2020-11-17 Thread Christian Mauderer 
Hello,

the following patches add a BSP for IMXRT1050-EVKB. In case the import
patch is too big: I pushed the patches here too:

https://gitlab.com/c-mauderer/rtems/-/tree/cm/20201117_imxrt

Best regards

Christian


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

[PATCH rtems 4/9] cpu/armv7m: Add _ARMV7M_MPU_set_region function

2020-11-17 Thread Christian Mauderer 
Make the MPU function defined in the STM32H7 BSP available for all
ARMV7M BSPs.

Update #4180
---
 bsps/arm/stm32h7/start/bspstarthooks.c| 48 +++
 .../cpu/arm/include/rtems/score/armv7m.h  | 37 ++
 2 files changed, 43 insertions(+), 42 deletions(-)

diff --git a/bsps/arm/stm32h7/start/bspstarthooks.c 
b/bsps/arm/stm32h7/start/bspstarthooks.c
index 565bd6876a..97745f0ee8 100644
--- a/bsps/arm/stm32h7/start/bspstarthooks.c
+++ b/bsps/arm/stm32h7/start/bspstarthooks.c
@@ -83,42 +83,6 @@ static void init_peripheral_clocks(void)
   }
 }
 
-static uint32_t get_region_size(uintptr_t size)
-{
-  if ((size & (size - 1)) == 0) {
-return ARMV7M_MPU_RASR_SIZE(30 - __builtin_clz(size));
-  } else {
-return ARMV7M_MPU_RASR_SIZE(31 - __builtin_clz(size));
-  }
-}
-
-static void set_region(
-  volatile ARMV7M_MPU *mpu,
-  uint32_t region,
-  uint32_t rasr,
-  const void *begin,
-  const void *end
-)
-{
-  uintptr_t size;
-  uint32_t rbar;
-
-  RTEMS_OBFUSCATE_VARIABLE(begin);
-  RTEMS_OBFUSCATE_VARIABLE(end);
-  size = (uintptr_t) end - (uintptr_t) begin;
-
-  if ( size > 0 ) {
-rbar = (uintptr_t) begin | region | ARMV7M_MPU_RBAR_VALID;
-rasr |= get_region_size(size);
-  } else {
-rbar = region;
-rasr = 0;
-  }
-
-  mpu->rbar = rbar;
-  mpu->rasr = rasr;
-}
-
 static void init_mpu(void)
 {
   volatile ARMV7M_MPU *mpu;
@@ -136,7 +100,7 @@ static void init_mpu(void)
 mpu->rasr = 0;
   }
 
-  set_region(
+  _ARMV7M_MPU_set_region(
 mpu,
 0,
 ARMV7M_MPU_RASR_XN
@@ -146,7 +110,7 @@ static void init_mpu(void)
 stm32h7_memory_sram_axi_begin,
 stm32h7_memory_sram_axi_end
   );
-  set_region(
+  _ARMV7M_MPU_set_region(
 mpu,
 1,
 ARMV7M_MPU_RASR_XN
@@ -156,7 +120,7 @@ static void init_mpu(void)
 stm32h7_memory_sdram_1_begin,
 stm32h7_memory_sdram_1_end
   );
-  set_region(
+  _ARMV7M_MPU_set_region(
 mpu,
 2,
 ARMV7M_MPU_RASR_AP(0x5)
@@ -165,7 +129,7 @@ static void init_mpu(void)
 bsp_section_start_begin,
 bsp_section_text_end
   );
-  set_region(
+  _ARMV7M_MPU_set_region(
 mpu,
 3,
 ARMV7M_MPU_RASR_XN
@@ -175,7 +139,7 @@ static void init_mpu(void)
 bsp_section_rodata_begin,
 bsp_section_rodata_end
   );
-  set_region(
+  _ARMV7M_MPU_set_region(
 mpu,
 4,
 ARMV7M_MPU_RASR_XN
@@ -185,7 +149,7 @@ static void init_mpu(void)
 bsp_section_nocache_begin,
 bsp_section_nocachenoload_end
   );
-  set_region(
+  _ARMV7M_MPU_set_region(
 mpu,
 region - 1,
 ARMV7M_MPU_RASR_XN | ARMV7M_MPU_RASR_ENABLE,
diff --git a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h 
b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
index c701e1037c..cb126a49ba 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
@@ -611,6 +611,43 @@ void _ARMV7M_Supervisor_call( void );
 
 void _ARMV7M_Clock_handler( void );
 
+static inline uint32_t _ARMV7M_MPU_get_region_size(uintptr_t size)
+{
+  if ((size & (size - 1)) == 0) {
+return ARMV7M_MPU_RASR_SIZE(30 - __builtin_clz(size));
+  } else {
+return ARMV7M_MPU_RASR_SIZE(31 - __builtin_clz(size));
+  }
+}
+
+static inline void _ARMV7M_MPU_set_region(
+  volatile ARMV7M_MPU *mpu,
+  uint32_t region,
+  uint32_t rasr,
+  const void *begin,
+  const void *end
+)
+{
+  uintptr_t size;
+  uint32_t rbar;
+
+  RTEMS_OBFUSCATE_VARIABLE(begin);
+  RTEMS_OBFUSCATE_VARIABLE(end);
+  size = (uintptr_t) end - (uintptr_t) begin;
+
+  if ( size > 0 ) {
+rbar = (uintptr_t) begin | region | ARMV7M_MPU_RBAR_VALID;
+rasr |= _ARMV7M_MPU_get_region_size(size);
+  } else {
+rbar = region;
+rasr = 0;
+  }
+
+  mpu->rbar = rbar;
+  mpu->rasr = rasr;
+}
+
+
 #endif /* ASM */
 
 #endif /* ARM_MULTILIB_ARCH_V7M */
-- 
2.26.2

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

[PATCH rtems 3/9] bsps/imx: Move imx-gpio to arm/shared

2020-11-17 Thread Christian Mauderer 
Update #4180
---
 bsps/arm/imx/headers.am | 5 -
 bsps/arm/shared/headers.am  | 5 +
 bsps/arm/{imx => shared}/include/bsp/imx-gpio.h | 0
 bsps/arm/{imx/gpio => shared/pins}/imx-gpio.c   | 0
 c/src/lib/libbsp/arm/imx/Makefile.am| 2 +-
 spec/build/bsps/arm/imx/bspimx.yml  | 4 ++--
 6 files changed, 8 insertions(+), 8 deletions(-)
 rename bsps/arm/{imx => shared}/include/bsp/imx-gpio.h (100%)
 rename bsps/arm/{imx/gpio => shared/pins}/imx-gpio.c (100%)

diff --git a/bsps/arm/imx/headers.am b/bsps/arm/imx/headers.am
index e7a2418dea..4db8035c38 100644
--- a/bsps/arm/imx/headers.am
+++ b/bsps/arm/imx/headers.am
@@ -17,9 +17,4 @@ include_arm_freescale_imx_HEADERS += 
../../../../../../bsps/arm/imx/include/arm/
 
 include_bspdir = $(includedir)/bsp
 include_bsp_HEADERS =
-include_bsp_HEADERS += ../../../../../../bsps/arm/imx/include/bsp/imx-gpio.h
 include_bsp_HEADERS += ../../../../../../bsps/arm/imx/include/bsp/irq.h
-
-include_dev_clockdir = $(includedir)/dev/clock
-include_dev_clock_HEADERS =
-include_dev_clock_HEADERS += 
../../../../../../bsps/include/dev/clock/arm-generic-timer.h
diff --git a/bsps/arm/shared/headers.am b/bsps/arm/shared/headers.am
index 4fd7238f81..34474400ec 100644
--- a/bsps/arm/shared/headers.am
+++ b/bsps/arm/shared/headers.am
@@ -4,3 +4,8 @@ include_arm_freescale_imxdir = $(includedir)/arm/freescale/imx
 include_arm_freescale_imx_HEADERS =
 include_arm_freescale_imx_HEADERS += 
../../../../../../bsps/arm/shared/include/arm/freescale/imx/imx_iomuxreg.h
 include_arm_freescale_imx_HEADERS += 
../../../../../../bsps/arm/shared/include/arm/freescale/imx/imx_iomuxvar.h
+
+include_bspdir = $(includedir)/bsp
+include_bsp_HEADERS =
+include_bsp_HEADERS += ../../../../../../bsps/arm/shared/include/bsp/imx-gpio.h
+include_bsp_HEADERS += 
../../../../../../bsps/arm/shared/include/bsp/imx-iomux.h
diff --git a/bsps/arm/imx/include/bsp/imx-gpio.h 
b/bsps/arm/shared/include/bsp/imx-gpio.h
similarity index 100%
rename from bsps/arm/imx/include/bsp/imx-gpio.h
rename to bsps/arm/shared/include/bsp/imx-gpio.h
diff --git a/bsps/arm/imx/gpio/imx-gpio.c b/bsps/arm/shared/pins/imx-gpio.c
similarity index 100%
rename from bsps/arm/imx/gpio/imx-gpio.c
rename to bsps/arm/shared/pins/imx-gpio.c
diff --git a/c/src/lib/libbsp/arm/imx/Makefile.am 
b/c/src/lib/libbsp/arm/imx/Makefile.am
index 80871a286c..c9537a773d 100644
--- a/c/src/lib/libbsp/arm/imx/Makefile.am
+++ b/c/src/lib/libbsp/arm/imx/Makefile.am
@@ -66,7 +66,7 @@ librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/shared/cache/cache-cp15.c
 librtemsbsp_a_SOURCES += 
../../../../../../bsps/arm/shared/cache/cache-v7ar-disable-data.S
 
 # GPIO
-librtemsbsp_a_SOURCES += ../../../../../../bsps/arm/imx/gpio/imx-gpio.c
+librtemsbsp_a_SOURCES += ../../../../../../bsps/arm/shared/pins/imx-gpio.c
 
 # I2C
 librtemsbsp_a_SOURCES += ../../../../../../bsps/arm/imx/i2c/imx-i2c.c
diff --git a/spec/build/bsps/arm/imx/bspimx.yml 
b/spec/build/bsps/arm/imx/bspimx.yml
index 442c631b3a..6b3cfdbb2e 100644
--- a/spec/build/bsps/arm/imx/bspimx.yml
+++ b/spec/build/bsps/arm/imx/bspimx.yml
@@ -28,7 +28,7 @@ install:
   - bsps/arm/imx/include/arm/freescale/imx/imx_wdogreg.h
 - destination: ${BSP_INCLUDEDIR}/bsp
   source:
-  - bsps/arm/imx/include/bsp/imx-gpio.h
+  - bsps/arm/shared/include/bsp/imx-gpio.h
   - bsps/arm/imx/include/bsp/irq.h
   - bsps/arm/shared/include/bsp/imx-iomux.h
 - destination: ${BSP_INCLUDEDIR}/dev/clock
@@ -83,7 +83,7 @@ links:
   uid: ../../bspopts
 source:
 - bsps/arm/imx/console/console-config.c
-- bsps/arm/imx/gpio/imx-gpio.c
+- bsps/arm/shared/pins/imx-gpio.c
 - bsps/arm/imx/i2c/imx-i2c.c
 - bsps/arm/imx/spi/imx-ecspi.c
 - bsps/arm/imx/start/bspreset.c
-- 
2.26.2

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

[PATCH rtems 7/9] bsp/imxrt: Fix warnings for imported files

2020-11-17 Thread Christian Mauderer 
Update #4180
---
 bsps/arm/imxrt/include/fsl_common.h   | 295 ++
 bsps/arm/imxrt/include/fsl_flexspi_nor_boot.h |   2 +
 .../imxrt/nxp/boards/evkbimxrt1050/pin_mux.c  |   4 +
 .../nxp/devices/MIMXRT1052/drivers/fsl_dcp.c  |   4 +
 .../devices/MIMXRT1052/drivers/fsl_spdif.c|   2 +
 5 files changed, 307 insertions(+)

diff --git a/bsps/arm/imxrt/include/fsl_common.h 
b/bsps/arm/imxrt/include/fsl_common.h
index 358f973b9e..76f943ebba 100644
--- a/bsps/arm/imxrt/include/fsl_common.h
+++ b/bsps/arm/imxrt/include/fsl_common.h
@@ -663,6 +663,301 @@ void DefaultISR(void);
 */
 void SDK_DelayAtLeastUs(uint32_t delay_us, uint32_t coreClock_Hz);
 
+#ifdef __rtems__
+/* Prototypes for IRQHandlers */
+void FLEXIO_CommonIRQHandler(void);
+void FLEXIO_DriverIRQHandler(void);
+void FLEXIO0_DriverIRQHandler(void);
+void FLEXIO1_DriverIRQHandler(void);
+void UART2_FLEXIO_DriverIRQHandler(void);
+void FLEXIO2_DriverIRQHandler(void);
+void FLEXIO3_DriverIRQHandler(void);
+void CAN0_DriverIRQHandler(void);
+void CAN1_DriverIRQHandler(void);
+void CAN2_DriverIRQHandler(void);
+void CAN3_DriverIRQHandler(void);
+void CAN4_DriverIRQHandler(void);
+void DMA_FLEXCAN0_INT_DriverIRQHandler(void);
+void DMA_FLEXCAN1_INT_DriverIRQHandler(void);
+void DMA_FLEXCAN2_INT_DriverIRQHandler(void);
+void ADMA_FLEXCAN0_INT_DriverIRQHandler(void);
+void ADMA_FLEXCAN1_INT_DriverIRQHandler(void);
+void ADMA_FLEXCAN2_INT_DriverIRQHandler(void);
+void USDHC0_DriverIRQHandler(void);
+void USDHC1_DriverIRQHandler(void);
+void USDHC2_DriverIRQHandler(void);
+void LPUART0_LPUART1_RX_DriverIRQHandler(void);
+void LPUART0_LPUART1_TX_DriverIRQHandler(void);
+void LPUART0_LPUART1_DriverIRQHandler(void);
+void LPUART0_TX_DriverIRQHandler(void);
+void LPUART0_RX_DriverIRQHandler(void);
+void LPUART0_DriverIRQHandler(void);
+void LPUART1_TX_DriverIRQHandler(void);
+void LPUART1_RX_DriverIRQHandler(void);
+void LPUART1_DriverIRQHandler(void);
+void LPUART2_TX_DriverIRQHandler(void);
+void LPUART2_RX_DriverIRQHandler(void);
+void LPUART2_DriverIRQHandler(void);
+void LPUART3_TX_DriverIRQHandler(void);
+void LPUART3_RX_DriverIRQHandler(void);
+void LPUART3_DriverIRQHandler(void);
+void LPUART4_TX_DriverIRQHandler(void);
+void LPUART4_RX_DriverIRQHandler(void);
+void LPUART4_DriverIRQHandler(void);
+void LPUART5_TX_DriverIRQHandler(void);
+void LPUART5_RX_DriverIRQHandler(void);
+void LPUART5_DriverIRQHandler(void);
+void LPUART6_TX_DriverIRQHandler(void);
+void LPUART6_RX_DriverIRQHandler(void);
+void LPUART6_DriverIRQHandler(void);
+void LPUART7_TX_DriverIRQHandler(void);
+void LPUART7_RX_DriverIRQHandler(void);
+void LPUART7_DriverIRQHandler(void);
+void LPUART8_TX_DriverIRQHandler(void);
+void LPUART8_RX_DriverIRQHandler(void);
+void LPUART8_DriverIRQHandler(void);
+void M4_0_LPUART_DriverIRQHandler(void);
+void M4_1_LPUART_DriverIRQHandler(void);
+void M4_LPUART_DriverIRQHandler(void);
+void DMA_UART0_INT_DriverIRQHandler(void);
+void DMA_UART1_INT_DriverIRQHandler(void);
+void DMA_UART2_INT_DriverIRQHandler(void);
+void DMA_UART3_INT_DriverIRQHandler(void);
+void DMA_UART4_INT_DriverIRQHandler(void);
+void ADMA_UART0_INT_DriverIRQHandler(void);
+void ADMA_UART1_INT_DriverIRQHandler(void);
+void ADMA_UART2_INT_DriverIRQHandler(void);
+void ADMA_UART3_INT_DriverIRQHandler(void);
+void DMA0_04_DriverIRQHandler(void);
+void DMA0_15_DriverIRQHandler(void);
+void DMA0_26_DriverIRQHandler(void);
+void DMA0_37_DriverIRQHandler(void);
+void DMA1_04_DriverIRQHandler(void);
+void DMA1_15_DriverIRQHandler(void);
+void DMA1_26_DriverIRQHandler(void);
+void DMA1_37_DriverIRQHandler(void);
+void DMA1_04_DriverIRQHandler(void);
+void DMA1_15_DriverIRQHandler(void);
+void DMA1_26_DriverIRQHandler(void);
+void DMA1_37_DriverIRQHandler(void);
+void DMA0_08_DriverIRQHandler(void);
+void DMA0_19_DriverIRQHandler(void);
+void DMA0_210_DriverIRQHandler(void);
+void DMA0_311_DriverIRQHandler(void);
+void DMA0_412_DriverIRQHandler(void);
+void DMA0_513_DriverIRQHandler(void);
+void DMA0_614_DriverIRQHandler(void);
+void DMA0_715_DriverIRQHandler(void);
+void DMA1_08_DriverIRQHandler(void);
+void DMA1_19_DriverIRQHandler(void);
+void DMA1_210_DriverIRQHandler(void);
+void DMA1_311_DriverIRQHandler(void);
+void DMA1_412_DriverIRQHandler(void);
+void DMA1_513_DriverIRQHandler(void);
+void DMA1_614_DriverIRQHandler(void);
+void DMA1_715_DriverIRQHandler(void);
+void DMA0_DMA16_DriverIRQHandler(void);
+void DMA1_DMA17_DriverIRQHandler(void);
+void DMA2_DMA18_DriverIRQHandler(void);
+void DMA3_DMA19_DriverIRQHandler(void);
+void DMA4_DMA20_DriverIRQHandler(void);
+void DMA5_DMA21_DriverIRQHandler(void);
+void DMA6_DMA22_DriverIRQHandler(void);
+void DMA7_DMA23_DriverIRQHandler(void);
+void DMA8_DMA24_DriverIRQHandler(void);
+void DMA9_DMA25_DriverIRQHandler(void);
+void DMA10_DMA26_DriverIRQHandler(void);
+void DMA11_DMA27_DriverIRQHandler(void);
+void DMA12_DMA28_DriverIRQHandler(void);
+void DMA13_DMA29_DriverIRQHandler(void);
+void DMA14_DMA30_Driver

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

2020-11-17 Thread 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.
---
 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 ++
 spec/build/cpukit/objshell.yml|   4 +
 7 files changed, 569 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 4e370ae639..2adfcf933f 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -1495,6 +1495,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.
+ */
+
+/*
+

[PATCH rtems 8/9] bsp/imxrt: Adapt imported files

2020-11-17 Thread Christian Mauderer 
Update #4180
---
 bsps/arm/imxrt/include/fsl_device_registers.h | 57 ++-
 bsps/arm/imxrt/include/fsl_flexspi_nor_boot.h |  6 ++
 ..._nor_config.h => fsl_flexspi_nor_config.h} |  0
 bsps/arm/imxrt/include/fsl_lpuart.h   |  4 ++
 bsps/arm/imxrt/include/fsl_pin_mux.h  |  4 ++
 .../nxp/boards/evkbimxrt1050/clock_config.c   | 12 
 .../imxrt/nxp/boards/evkbimxrt1050/pin_mux.c  |  6 ++
 .../devices/MIMXRT1052/drivers/fsl_lpuart.c   | 17 ++
 8 files changed, 80 insertions(+), 26 deletions(-)
 rename bsps/arm/imxrt/include/{evkbimxrt1050_flexspi_nor_config.h => 
fsl_flexspi_nor_config.h} (100%)

diff --git a/bsps/arm/imxrt/include/fsl_device_registers.h 
b/bsps/arm/imxrt/include/fsl_device_registers.h
index 54caf43ca6..00c3fc7036 100644
--- a/bsps/arm/imxrt/include/fsl_device_registers.h
+++ b/bsps/arm/imxrt/include/fsl_device_registers.h
@@ -1,36 +1,41 @@
-/*
- * Copyright 2014-2016 Freescale Semiconductor, Inc.
- * Copyright 2016-2018 NXP
- * All rights reserved.
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
  *
- * SPDX-License-Identifier: BSD-3-Clause
+ * @ingroup RTEMSBSPsARMimxrt
  *
+ * @brief Helper file for including registers for SDK drivers.
  */
 
-#ifndef __FSL_DEVICE_REGISTERS_H__
-#define __FSL_DEVICE_REGISTERS_H__
-
 /*
- * Include the cpu specific register header files.
+ * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
  *
- * The CPU macro should be declared in the project or makefile.
+ * 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.
  */
-#if (defined(CPU_MIMXRT1052CVJ5B) || defined(CPU_MIMXRT1052CVL5B) || 
defined(CPU_MIMXRT1052DVJ6B) || \
-defined(CPU_MIMXRT1052DVL6B))
-
-#define MIMXRT1052_SERIES
-
-/* CMSIS-style register definitions */
-#include "MIMXRT1052.h"
-/* CPU specific feature definitions */
-#include "MIMXRT1052_features.h"
 
-#else
-#error "No valid CPU defined!"
-#endif
+#ifndef FSL_DEVICE_REGISTERS_H
+#define FSL_DEVICE_REGISTERS_H
 
-#endif /* __FSL_DEVICE_REGISTERS_H__ */
+#include 
 
-/***
- * EOF
- 
**/
+#endif /* FSL_DEVICE_REGISTERS_H */
diff --git a/bsps/arm/imxrt/include/fsl_flexspi_nor_boot.h 
b/bsps/arm/imxrt/include/fsl_flexspi_nor_boot.h
index 7b256f6670..56995eca55 100644
--- a/bsps/arm/imxrt/include/fsl_flexspi_nor_boot.h
+++ b/bsps/arm/imxrt/include/fsl_flexspi_nor_boot.h
@@ -9,7 +9,9 @@
 #define __FLEXSPI_NOR_BOOT_H__
 
 #include 
+#ifndef __rtems__
 #include "board.h"
+#endif /* __rtems__ */
 
 /*! @name Driver version */
 /*@{*/
@@ -85,6 +87,7 @@ typedef struct _ivt_ {
 #define FLASH_BASE ((uint32_t)__FLASH_BASE)   
 #endif
 
+#ifndef __rtems__
 #if defined(XIP_BOOT_HEADER_DCD_ENABLE) && (1 == XIP_BOOT_HEADER_DCD_ENABLE)
 #define DCD_ADDRESS dcd_data
 #else
@@ -94,6 +97,7 @@ typedef struct _ivt_ {
 #define BOOT_DATA_ADDRESS &boot_data
 #define CSF_ADDRESS   0
 #define IVT_RSVD (uint32_t)(0x)
+#endif /* __rtems__ */
 
 /* 
  *  Boot Data 
@@ -114,11 +118,13 @@ typedef struct _boot_data_ {
 #endif /* __rtems__ */
 #define PLUGIN_FLAG   (uint32_t)0
 
+#ifndef __rtems__
 /* External Variables */
 const BOOT_DATA_T boot_data;
 #if defined(XIP_BOOT_HEADER_DCD_ENABLE) && (1 == XIP_BOOT_HEADER_DCD_ENABLE)
 extern const uint8_t dcd_data[];
 #endif
+#endif /* __rtems__ */
 
 #endif /* __FLEXSPI_NOR_BOOT_H__ */
 
diff --git a/bsps/arm/imxrt/include/evkbimxrt1050_flexspi_nor_config.h 
b/bsps/arm/imxrt/include/fsl_flexspi_nor_config.h
similarity index 100%
rename from bsps/arm/imxrt/include/evkbimxrt1050_flexspi_nor

[PATCH rtems-libbsd 2/2] if_ffec: Fix cache handling on tx

2020-11-17 Thread Christian Mauderer 
With the previous fix, it could happen that the end of the packet hasn't
been flushed. For example assume the following addresses:

ds_addr: 0x81c804A
ds_len: 0x57

In that case the data ends at 0x81c80a1. But due to the rounding the
area from 0x81c8040 to 0x81c80a0 would have been flushed.

This fix now first calculates the start and end address, aligns these
addresses and then recalculates the len that has to be flushed.

Update #4180
---
 freebsd/sys/dev/ffec/if_ffec.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/freebsd/sys/dev/ffec/if_ffec.c b/freebsd/sys/dev/ffec/if_ffec.c
index e8287ed2..47c0f770 100644
--- a/freebsd/sys/dev/ffec/if_ffec.c
+++ b/freebsd/sys/dev/ffec/if_ffec.c
@@ -714,15 +714,16 @@ ffec_encap(struct ifnet *ifp, struct ffec_softc *sc, 
struct mbuf *m0,
tx_desc->buf_paddr = segs[i].ds_addr;
tx_desc->flags2 = flags2;
 #ifdef __rtems__
-   uintptr_t addr_flush = (uintptr_t)segs[i].ds_addr;
+   uintptr_t first_flush = (uintptr_t)segs[i].ds_addr;
size_t len_flush = segs[i].ds_len;
 #ifdef CPU_CACHE_LINE_BYTES
+   uintptr_t last_flush = first_flush + len_flush;
/* mbufs should be cache line aligned. So we can just round. */
-   addr_flush = addr_flush & ~(CPU_CACHE_LINE_BYTES - 1);
-   len_flush = (len_flush + (CPU_CACHE_LINE_BYTES - 1)) &
-   ~(CPU_CACHE_LINE_BYTES - 1);
+   first_flush = rounddown2(first_flush, CPU_CACHE_LINE_BYTES);
+   last_flush = roundup2(last_flush, CPU_CACHE_LINE_BYTES);
+   len_flush = last_flush - first_flush;
 #endif
-   rtems_cache_flush_multiple_data_lines((void*)addr_flush,
+   rtems_cache_flush_multiple_data_lines((void*)first_flush,
len_flush);
 #endif /* __rtems__ */
 
-- 
2.26.2

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

[PATCH rtems-libbsd 1/2] imxrt: Add support

2020-11-17 Thread Christian Mauderer 
Update #4180
---
 rtemsbsd/include/bsp/nexus-devices.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/rtemsbsd/include/bsp/nexus-devices.h 
b/rtemsbsd/include/bsp/nexus-devices.h
index 18b4c012..630572a8 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -143,6 +143,14 @@ RTEMS_BSD_DRIVER_MMC;
 
 SYSINIT_DRIVER_REFERENCE(ofw_regulator_bus, simplebus);
 
+#elif defined(LIBBSP_ARM_IMXRT_BSP_H)
+
+RTEMS_BSD_DEFINE_NEXUS_DEVICE(ofwbus, 0, 0, NULL);
+SYSINIT_DRIVER_REFERENCE(simplebus, ofwbus);
+
+SYSINIT_DRIVER_REFERENCE(ffec, simplebus);
+SYSINIT_DRIVER_REFERENCE(ksz8091rnb, miibus);
+
 #elif defined(LIBBSP_ARM_LPC24XX_BSP_H)
 
 RTEMS_BSD_DEFINE_NEXUS_DEVICE(ohci, 0, 0, NULL);
-- 
2.26.2

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

[PATCH rtems-docs 2/2] user/bsps: Fix list in bsps-arm

2020-11-17 Thread Christian Mauderer 
Seems that some filenames haven't been added correctly.
---
 user/bsps/bsps-arm.rst | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/user/bsps/bsps-arm.rst b/user/bsps/bsps-arm.rst
index a63dd5f..f8a1d60 100644
--- a/user/bsps/bsps-arm.rst
+++ b/user/bsps/bsps-arm.rst
@@ -9,6 +9,7 @@ arm (ARM)
 .. include:: arm/altera-cyclone-v.rst
 .. include:: arm/atsam.rst
 .. include:: arm/beagle.rst
+.. include:: arm/bsp-stm32h7.rst
 .. include:: arm/csb336.rst
 .. include:: arm/csb337.rst
 .. include:: arm/edb7312.rst
@@ -17,8 +18,7 @@ arm (ARM)
 .. include:: arm/imxrt.rst
 .. include:: arm/lm3s69xx.rst
 .. include:: arm/lpc176x.rst
-.. include:: arm/imx.rst
-.. include:: arm/lpc32xx.rst
+.. include:: arm/lpc24xx.rst
 .. include:: arm/raspberrypi.rst
 .. include:: arm/realview-pbx-a9.rst
 .. include:: arm/rtl22xx.rst
-- 
2.26.2

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

[PATCH rtems-docs 1/2] user/bsps: Add imxrt

2020-11-17 Thread Christian Mauderer 
Update #4180
---
 user/bsps/arm/imxrt.rst | 174 
 user/bsps/bsps-arm.rst  |   1 +
 2 files changed, 175 insertions(+)
 create mode 100644 user/bsps/arm/imxrt.rst

diff --git a/user/bsps/arm/imxrt.rst b/user/bsps/arm/imxrt.rst
new file mode 100644
index 000..41c6bff
--- /dev/null
+++ b/user/bsps/arm/imxrt.rst
@@ -0,0 +1,174 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2020 embedded brains GmbH
+.. Copyright (C) 2020 Christian Mauderer
+
+imxrt (NXP i.MXRT)
+==
+
+This BSP offers only one variant, the `imxrt1052`. This variant supports the
+i.MXRT 1052 processor on a IMXRT1050-EVKB (tested with rev A1). You can also
+configure it to work with custom boards.
+
+Build Configuration Options
+---
+
+Please see the documentation of the `IMXRT_*` and `BSP_*` configuration options
+for that. You can generate a default set of options with::
+
+  ./waf bsp_defaults --rtems-bsps=arm/imxrt1052 > config.ini
+
+Boot Process
+
+
+There are two possible boot processes supported:
+
+1) The ROM code loads a configuration from HyperFlash (connected to FlexSPI),
+   does some initialization (based on device configuration data (DCD)) and then
+   starts the application. This is the default case. `linkcmds.flexspi` is used
+   for this case.
+
+2) Some custom bootloader does the basic initialization, loads the application
+   to SDRAM and starts it from there. Select the `linkcmds.sdram` for this.
+
+For programming the HyperFlash in case 1, you can use the on board debugger
+integrated into the IMXRT1050-EVKB. You can generate a flash image out of a
+compiled RTEMS application with for example::
+
+  arm-rtems6-objcopy -O binary 
build/arm/imxrt1052/testsuites/samples/hello.exe hello.bin
+
+Then just copy the generated binary to the mass storage provided by the
+debugger. Wait a bit till the mass storage vanishes and re-appears. After that,
+reset the board and the newly programmed application will start.
+
+For debugging: Create a special application with a `while(true)` loop at end of
+`bsp_start_hook_1`. Load that application into flash. Then remove the loop
+again, build your BSP for SDRAM and use a debugger to load the application into
+SDRAM after the BSP started from flash did the basic initialization.
+
+Flash Image
+---
+
+For booting from a HyperFlash (or other storage connected to FlexSPI), the ROM
+code of the i.MXRT first reads some special flash header information from a
+fixed location of the connected flash device. This consists of the Image vector
+table (IVT), Boot data and Device configuration data (DCD).
+
+In RTEMS, these flash headers are generated using some C-structures. If you use
+a board other then the IMXRT1050-EVKB, they have to be adapted. To do that
+re-define the following variables in your application (you only need the ones
+that need different values):
+
+.. code-block:: c
+
+  #include 
+  const uint8_t imxrt_dcd_data[] =
+  { /* Your DCD data here */ };
+  const ivt imxrt_image_vector_table =
+  { /* Your IVT here */ };
+  const BOOT_DATA_T imxrt_boot_data =
+  { /* Your boot data here */ };
+  const flexspi_nor_config_t imxrt_flexspi_config =
+  { /* Your FlexSPI config here */ };
+
+You can find the default definitions in `bsps/arm/imxrt/start/flash-*.c`. Take 
a
+look at the `i.MX RT1050 Processor Reference Manual, Rev. 4, 12/2019` chapter
+`9.7 Program image` for details about the contents.
+
+FDT
+---
+
+The BSP used a FDT based initialization. The FDT is linked into the 
application.
+You can find the default FDT used in the BSP in
+`bsps/arm/imxrt/dts/imxrt1050-evkb.dts`. To use your own FDT compile it and
+convert it into a C file with (replace `YOUR.dts` and simmilar with your FDT
+source names)::
+
+  sh> export BSP_DIR="${RTEMS_SRC_DIR}/bsps/arm/imxrt/"
+  sh> arm-rtems6-cpp -P -x assembler-with-cpp \
+  -I "${BSP_DIR}/include/" \
+  -include "YOUR.dts" /dev/null | \
+  dtc -@ -O dtb -o "YOUR.dtb" -b 0 -p 1024
+  sh> rtems-bin2c -C -N imxrt_dtb "YOUR.dtb" "YOUR.c"
+
+Make sure that your new c file is compiled and linked into the application.
+
+Clock Driver
+
+
+The clock driver uses the generic `ARMv7-M Clock`.
+
+IOMUX
+-
+
+The i.MXRT IOMUXC is initialized based on the FDT. For that, the `pinctrl-0`
+fields of all devices with a status of `ok` or `okay` will be parsed.
+
+Console Driver
+--
+
+LPUART drivers are registered based on the FDT. The special `rtems,path`
+attribute defines where the device file for the console is created.
+
+The `stdout-path` in the `chosen` node determines which LPUART is used for the
+console.
+
+I2C Driver
+--
+
+I2C drivers are registered based on the FDT. The special `rtems,path` attribute
+defines where the device file for the I2C bus is created.
+
+Limitations:
+
+* Only basic I2C is implemented. This is mostly a driver limitation and not a
+  hardwar

libdl: How to debug dl object with GDB

2020-11-17 Thread Hesham Almatary 
Hello,

I am trying to debug a dynamically loaded ELF object with GDB: My setup is:
rtems-riscv64:
GDB: GNU gdb (GDB) 10.0.50.20200904-git (build with RSB/rtems6)
Host: Ubuntu 20.04.1 LTS

GDB doesn't seem to notice when I dlopen an object (which gets loaded,
linked and run fine). Any instructions or idea how to troubleshoot
that further?

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

Re: GMP is now a required dependency for building GDB

2020-11-17 Thread Joel Sherrill 
On Tue, Nov 17, 2020 at 1:46 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> I tried to update the RTEMS 6/7 tools yesterday and all builds failed on
> my FreeBSD machine. The reason is this change in GDB:
>
> commit 1b4ac058f7daeb9bac9ab0e63a7e73535208dfef
> Author: Joel Brobecker 
> Date:   Sun Nov 15 03:08:40 2020 -0500
>
>  gdb: Make GMP a required dependency for building GDB
>
>  This commit modifies gdb's configure script to trigger an error
>  if we cannot find a usable libgmp.
>
>  For the record, making this a requirement was discussed in March 2018:
> https://sourceware.org/pipermail/gdb-patches/2018-March/147373.html
>
>  gdb/ChangeLog:
>
>  * configure.ac: Generate an error if a usable GMP library
>  could not be found.
>  * configure: Regenerate.
>
> The GMP library is not available by default on FreeBSD systems. For GCC
> we include a fixed version and build it together with GCC. What should
> be do for GDB?
>

I would lean to including the same version in GDB that we do in GCC.

Is this like gcc in that if they find it in the source tree, they will use
it?

--joel

>
> --
> embedded brains GmbH
> 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
> PGP: Public key available on request.
>
> embedded brains GmbH
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

How do we know what priority of the Init task is?

2020-11-17 Thread Richi Dubey 
Hi,

Sometimes the priority of the Init task is not mentioned in the source code
of the test suites of the headers files included in it (ex. see tm24
). Can
someone please let me know how we can understand what the priority of the
Init task is? Is there a constant value for Init's priority when it's not
explicitly mentioned?

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

How do I skip over a portion on code while debugging with GDB

2020-11-17 Thread Richi Dubey 
Hi,

When I am trying to debug the tm24 test suite, there's some line of code
 that
repeats the same code that creates a task around 100 times. Is there a way
I can skip that code while debugging? Please let me know.

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

Re: How do we know what priority of the Init task is?

2020-11-17 Thread Joel Sherrill 
On Tue, Nov 17, 2020, 9:50 AM Richi Dubey  wrote:

> Hi,
>
> Sometimes the priority of the Init task is not mentioned in the source
> code of the test suites of the headers files included in it (ex. see tm24
> ). Can
> someone please let me know how we can understand what the priority of the
> Init task is? Is there a constant value for Init's priority when it's not
> explicitly mentioned?
>

Yes. It defaults to 1. This is defaulted in one of the confdef subfiles now
and documented in the configuring a system chapter if the Classic API Guide

>
> Thanks,
> Richi.
> ___
> 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 1/9] Add License file for BSD-3-Clause

2020-11-17 Thread Gedare Bloom 
this is ok, would have preferred it separately ;)

On Tue, Nov 17, 2020 at 4:05 AM Christian Mauderer
 wrote:
>
> We have some files with a SPDX identifier for this license. Therefore
> the license should be here too.
> ---
>  LICENSE.BSD-3-Clause | 27 +++
>  1 file changed, 27 insertions(+)
>  create mode 100644 LICENSE.BSD-3-Clause
>
> diff --git a/LICENSE.BSD-3-Clause b/LICENSE.BSD-3-Clause
> new file mode 100644
> index 00..09d01c1ff5
> --- /dev/null
> +++ b/LICENSE.BSD-3-Clause
> @@ -0,0 +1,27 @@
> +https://spdx.org/licenses/BSD-3-Clause
> +
> +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.
> +3. Neither the name of the copyright holder nor the names of its
> +   contributors may be used to endorse or promote products derived
> +   from this software without specific prior written permission.
> +
> +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
> +HOLDER 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.
> --
> 2.26.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

2020-11-17 Thread Gedare Bloom 
These should be reviewed separately from the BSP addition. I'm not
really that good with the shell, so it would take me some time.

On Tue, Nov 17, 2020 at 4:05 AM Christian Mauderer
 wrote:
>
> 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.
> ---
>  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 ++
>  spec/build/cpukit/objshell.yml|   4 +
>  7 files changed, 569 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 4e370ae639..2adfcf933f 100644
> --- a/cpukit/Makefile.am
> +++ b/cpukit/Makefile.am
> @@ -1495,6 +1495,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 DA

Re: [PATCH rtems 1/9] Add License file for BSD-3-Clause

2020-11-17 Thread Christian Mauderer 
On 17/11/2020 18:29, Gedare Bloom wrote:
> this is ok, would have preferred it separately ;)

Hello Gedare,

yes, sorry. I shouldn't have hidden it in the patch set. I haven't
checked thoroughly enough before sending. I'll send it as a separate
patch tomorrow so that everyone is aware of it. Same is true for the i2c
and spi commands.

Best regards

Christian

> 
> On Tue, Nov 17, 2020 at 4:05 AM Christian Mauderer
>  wrote:
>>
>> We have some files with a SPDX identifier for this license. Therefore
>> the license should be here too.
>> ---
>>  LICENSE.BSD-3-Clause | 27 +++
>>  1 file changed, 27 insertions(+)
>>  create mode 100644 LICENSE.BSD-3-Clause
>>
>> diff --git a/LICENSE.BSD-3-Clause b/LICENSE.BSD-3-Clause
>> new file mode 100644
>> index 00..09d01c1ff5
>> --- /dev/null
>> +++ b/LICENSE.BSD-3-Clause
>> @@ -0,0 +1,27 @@
>> +https://spdx.org/licenses/BSD-3-Clause
>> +
>> +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.
>> +3. Neither the name of the copyright holder nor the names of its
>> +   contributors may be used to endorse or promote products derived
>> +   from this software without specific prior written permission.
>> +
>> +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
>> +HOLDER 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.
>> --
>> 2.26.2
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCHES] Add imxrt BSP

2020-11-17 Thread Gedare Bloom 
Everything except 5 looks good. I or someone else should take a closer
look at that.

On Tue, Nov 17, 2020 at 4:04 AM Christian Mauderer
 wrote:
>
> Hello,
>
> the following patches add a BSP for IMXRT1050-EVKB. In case the import
> patch is too big: I pushed the patches here too:
>
> https://gitlab.com/c-mauderer/rtems/-/tree/cm/20201117_imxrt
>
> Best regards
>
> Christian
>
>
> ___
> 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 1/9] Add License file for BSD-3-Clause

2020-11-17 Thread Gedare Bloom 
On Tue, Nov 17, 2020 at 10:32 AM Christian Mauderer  wrote:
>
> On 17/11/2020 18:29, Gedare Bloom wrote:
> > this is ok, would have preferred it separately ;)
>
> Hello Gedare,
>
> yes, sorry. I shouldn't have hidden it in the patch set. I haven't
> checked thoroughly enough before sending. I'll send it as a separate
> patch tomorrow so that everyone is aware of it. Same is true for the i2c
> and spi commands.
>
OK great, we're on the same page. I think the BSP itself would be
fine. There are a few ARM/shared changes but nothing looks
questionable to me at a glance.

> Best regards
>
> Christian
>
> >
> > On Tue, Nov 17, 2020 at 4:05 AM Christian Mauderer
> >  wrote:
> >>
> >> We have some files with a SPDX identifier for this license. Therefore
> >> the license should be here too.
> >> ---
> >>  LICENSE.BSD-3-Clause | 27 +++
> >>  1 file changed, 27 insertions(+)
> >>  create mode 100644 LICENSE.BSD-3-Clause
> >>
> >> diff --git a/LICENSE.BSD-3-Clause b/LICENSE.BSD-3-Clause
> >> new file mode 100644
> >> index 00..09d01c1ff5
> >> --- /dev/null
> >> +++ b/LICENSE.BSD-3-Clause
> >> @@ -0,0 +1,27 @@
> >> +https://spdx.org/licenses/BSD-3-Clause
> >> +
> >> +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.
> >> +3. Neither the name of the copyright holder nor the names of its
> >> +   contributors may be used to endorse or promote products derived
> >> +   from this software without specific prior written permission.
> >> +
> >> +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
> >> +HOLDER 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.
> >> --
> >> 2.26.2
> >>
> >> ___
> >> devel mailing list
> >> devel@rtems.org
> >> http://lists.rtems.org/mailman/listinfo/devel
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems-docs 1/2] user/bsps: Add imxrt

2020-11-17 Thread Gedare Bloom 
On Tue, Nov 17, 2020 at 4:09 AM Christian Mauderer
 wrote:
>
> Update #4180
> ---
>  user/bsps/arm/imxrt.rst | 174 
>  user/bsps/bsps-arm.rst  |   1 +
>  2 files changed, 175 insertions(+)
>  create mode 100644 user/bsps/arm/imxrt.rst
>
> diff --git a/user/bsps/arm/imxrt.rst b/user/bsps/arm/imxrt.rst
> new file mode 100644
> index 000..41c6bff
> --- /dev/null
> +++ b/user/bsps/arm/imxrt.rst
> @@ -0,0 +1,174 @@
> +.. SPDX-License-Identifier: CC-BY-SA-4.0
> +
> +.. Copyright (C) 2020 embedded brains GmbH
> +.. Copyright (C) 2020 Christian Mauderer
> +
> +imxrt (NXP i.MXRT)
> +==
> +
> +This BSP offers only one variant, the `imxrt1052`. This variant supports the
> +i.MXRT 1052 processor on a IMXRT1050-EVKB (tested with rev A1). You can also
> +configure it to work with custom boards.
> +
> +Build Configuration Options
> +---
> +
> +Please see the documentation of the `IMXRT_*` and `BSP_*` configuration 
> options
> +for that. You can generate a default set of options with::
one colon: I think?

> +
> +  ./waf bsp_defaults --rtems-bsps=arm/imxrt1052 > config.ini
> +
> +Boot Process
> +
> +
> +There are two possible boot processes supported:
> +
> +1) The ROM code loads a configuration from HyperFlash (connected to FlexSPI),
> +   does some initialization (based on device configuration data (DCD)) and 
> then
> +   starts the application. This is the default case. `linkcmds.flexspi` is 
> used
> +   for this case.
> +
> +2) Some custom bootloader does the basic initialization, loads the 
> application
> +   to SDRAM and starts it from there. Select the `linkcmds.sdram` for this.
> +
> +For programming the HyperFlash in case 1, you can use the on board debugger
> +integrated into the IMXRT1050-EVKB. You can generate a flash image out of a
> +compiled RTEMS application with for example::
> +
> +  arm-rtems6-objcopy -O binary 
> build/arm/imxrt1052/testsuites/samples/hello.exe hello.bin
> +
> +Then just copy the generated binary to the mass storage provided by the
> +debugger. Wait a bit till the mass storage vanishes and re-appears. After 
> that,
> +reset the board and the newly programmed application will start.
> +
> +For debugging: Create a special application with a `while(true)` loop at end 
> of
> +`bsp_start_hook_1`. Load that application into flash. Then remove the loop
> +again, build your BSP for SDRAM and use a debugger to load the application 
> into
> +SDRAM after the BSP started from flash did the basic initialization.
> +
> +Flash Image
> +---
> +
> +For booting from a HyperFlash (or other storage connected to FlexSPI), the 
> ROM
> +code of the i.MXRT first reads some special flash header information from a
> +fixed location of the connected flash device. This consists of the Image 
> vector
> +table (IVT), Boot data and Device configuration data (DCD).
> +
> +In RTEMS, these flash headers are generated using some C-structures. If you 
> use
> +a board other then the IMXRT1050-EVKB, they have to be adapted. To do that
s/then/than
s/they have/it has

> +re-define the following variables in your application (you only need the ones
> +that need different values):
> +
> +.. code-block:: c
> +
> +  #include 
> +  const uint8_t imxrt_dcd_data[] =
> +  { /* Your DCD data here */ };
> +  const ivt imxrt_image_vector_table =
> +  { /* Your IVT here */ };
> +  const BOOT_DATA_T imxrt_boot_data =
> +  { /* Your boot data here */ };
> +  const flexspi_nor_config_t imxrt_flexspi_config =
> +  { /* Your FlexSPI config here */ };
> +
> +You can find the default definitions in `bsps/arm/imxrt/start/flash-*.c`. 
> Take a
> +look at the `i.MX RT1050 Processor Reference Manual, Rev. 4, 12/2019` chapter
> +`9.7 Program image` for details about the contents.
> +
> +FDT
> +---
> +
> +The BSP used a FDT based initialization. The FDT is linked into the 
> application.
> +You can find the default FDT used in the BSP in
> +`bsps/arm/imxrt/dts/imxrt1050-evkb.dts`. To use your own FDT compile it and
> +convert it into a C file with (replace `YOUR.dts` and simmilar with your FDT
> +source names)::
> +
> +  sh> export BSP_DIR="${RTEMS_SRC_DIR}/bsps/arm/imxrt/"
> +  sh> arm-rtems6-cpp -P -x assembler-with-cpp \
> +  -I "${BSP_DIR}/include/" \
> +  -include "YOUR.dts" /dev/null | \
> +  dtc -@ -O dtb -o "YOUR.dtb" -b 0 -p 1024
> +  sh> rtems-bin2c -C -N imxrt_dtb "YOUR.dtb" "YOUR.c"
> +
> +Make sure that your new c file is compiled and linked into the application.
> +
> +Clock Driver
> +
> +
> +The clock driver uses the generic `ARMv7-M Clock`.
> +
> +IOMUX
> +-
> +
> +The i.MXRT IOMUXC is initialized based on the FDT. For that, the `pinctrl-0`
> +fields of all devices with a status of `ok` or `okay` will be parsed.
> +
> +Console Driver
> +--
> +
> +LPUART drivers are registered based on the FDT. The special `rtems,path`
> +attribute defines where the device fil

Re: How do we know what priority of the Init task is?

2020-11-17 Thread Richi Dubey 
Awesome, thanks!

On Tue, Nov 17, 2020 at 9:53 PM Joel Sherrill  wrote:

>
>
> On Tue, Nov 17, 2020, 9:50 AM Richi Dubey  wrote:
>
>> Hi,
>>
>> Sometimes the priority of the Init task is not mentioned in the source
>> code of the test suites of the headers files included in it (ex. see tm24
>> ). Can
>> someone please let me know how we can understand what the priority of the
>> Init task is? Is there a constant value for Init's priority when it's not
>> explicitly mentioned?
>>
>
> Yes. It defaults to 1. This is defaulted in one of the confdef subfiles
> now and documented in the configuring a system chapter if the Classic API
> Guide
>
>>
>> Thanks,
>> Richi.
>> ___
>> 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: How do I skip over a portion on code while debugging with GDB

2020-11-17 Thread Gedare Bloom 
Use 'next' to step by instructions in program order ignoring their
control flow. This also will skip over function calls.

On Tue, Nov 17, 2020 at 8:54 AM Richi Dubey  wrote:
>
> Hi,
>
> When I am trying to debug the tm24 test suite, there's some line of code that 
> repeats the same code that creates a task around 100 times. Is there a way I 
> can skip that code while debugging? Please let me know.
>
> Thanks,
> Richi.
> ___
> 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: How do I skip over a portion on code while debugging with GDB

2020-11-17 Thread Joel Sherrill 
Next is good but setting a breakpoint at the line after the task create
loop
is probably the solution here. Or "next NUMBER" to next a number of times.
Many gdb commands take a number.

Another interesting option is using continue and break conditions. You
could
then continue until the loop counter is 99 or something.

https://sourceware.org/gdb/onlinedocs/gdb/Continuing-and-Stepping.html

On Tue, Nov 17, 2020 at 12:41 PM Gedare Bloom  wrote:

> Use 'next' to step by instructions in program order ignoring their
> control flow. This also will skip over function calls.
>
> On Tue, Nov 17, 2020 at 8:54 AM Richi Dubey  wrote:
> >
> > Hi,
> >
> > When I am trying to debug the tm24 test suite, there's some line of code
> that repeats the same code that creates a task around 100 times. Is there a
> way I can skip that code while debugging? Please let me know.
> >
> > Thanks,
> > Richi.
> > ___
> > 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: Proposal for hardware configuration dependent performance limits

2020-11-17 Thread Chris Johns 


On 17/11/20 6:14 pm, Sebastian Huber wrote:
> 
> On 16/11/2020 23:42, Chris Johns wrote:
>> On 16/11/20 5:40 pm, Sebastian Huber wrote:
>>> On 16/11/2020 00:33, Chris Johns wrote:
>>>
>>> In the proposal, limits are specified like this:
>>>
>>>
>>> limits:
>>>   sparc/gr712rc:
>>>     DirtyCache:
>>>   max-upper-bound: 0.05
>>>   mean-upper-bound: 0.05
>>>     FullCache:
>>>   max-upper-bound: 0.05
>>>   mean-upper-bound: 0.05
>>>     HotCache:
>>>   max-upper-bound: 0.05
>>>   mean-upper-bound: 0.05
>>>     Load/1:
>>>   max-upper-bound: 0.1
>>>   mean-upper-bound: 0.1
>>>     Load/2:
>>>   max-upper-bound: 0.1
>>>   mean-upper-bound: 0.1
>>>     Load/3:
>>>   max-upper-bound: 0.1
>>>   mean-upper-bound: 0.1
>>>     Load/4:
>>>   max-upper-bound: 0.1
>>>   mean-upper-bound: 0.1
>>>
>>> This neglects that the limits are subject to a board configuration. One
>>> approach to cover this is the addition of a new BSP provided function:
>>>
>>> const char *rtems_get_hardware_performance_hash();
>>>
>>> The BSP feeds all performance related data into a hash function and
>> "data" here means configuration?
> Yes, hardware configuration.
 Why not make these values part of the BSP configuration? The defaults for 
 the
 BSP can have a set of suitable values. Different boards have different
 configurations to match and a separate kernel build.

>>> This doesn't work on BSPs which support configuration via a hardware
>>> enumeration, boot loader settings, or device trees. Also changes in the BSP
>>> options have no influence on the BSP name. Not only BSP configuration 
>>> influence
>>> performance, the CPU options play a role too, for example RTEMS_SMP. In 
>>> order to
>>> compare performance values over time we have to obtain the values under the 
>>> same
>>> conditions.
>> Maybe I am not understanding the context.
>>
>> A BSP, which ever one, has a set of options that configure it. An example is 
>> the
>> xilinx_zynq_zc702 and the `ZYNQ_RAM_LENGTH = 0x4000`. If I have 2 Zynq
>> circuits one with 256M and one with 1G I need to build and maintain 2 RTEMS
>> builds and from a purists point of view I need to maintain 2 builds of the 
>> exact
>> same application.
>>
>> I asked about the fixed memory and your answer was to use the BSP options, 
>> the
>> size is fixed in the linker command files via the BSP option. That is what I
>> have done.
>>
>> I would expect there exists a set of values for the xilinx_zynq_zc702 with no
>> SMP and with SMP as this BSP supports SMP. Those values would match all the
>> other settings for the BSP such as ZYNQ_CLOCK_CPU_1X, 
>> BSP_ARM_A9MPCORE_PERIPHCLK
>> etc. If my clock is different (and they are) I would need to supply a 
>> suitable
>> set of performance values if I wanted to pass those tests.
>>
>> I am not questioning the need for the values or the tests. I am suggesting 
>> the
>> values form part of the BSP settings so a user can adjust them to suite their
>> specific set up in the same way they adjust other BSP settings. I do not 
>> think
>> we should attempt to hold or manage an endless sets of possible values and I 
>> do
>> not see the need for complex encapsulation methods such as a base64 hashes. 
>> The
>> systems we interact with are too complex and list is endless.
> 
> I think it will be highly BSP-specific what parameters are relevant to the
> performance limits. This is why I suggested to add a function which can be
> implemented by each BSP.
> 
> const char *rtems_get_hardware_performance_something();
> 
> It should return a string which changes if a performance relevant parameter
> changed. If it is only SMP/no-SMP, ZYNQ_CLOCK_CPU_1X, and
> BSP_ARM_A9MPCORE_PERIPHCLK, then fine, just return "SMP/800MHz/400MHz" or 
> whatever.

I suggest you avoid heading down a path of specific strings, ie avoid something
meaningful a human can read. Also performance characteristics are a part of a
wider configuration topic. Maybe considering that would solve the performance
specific parts as well.

A label for a build of RTEMS is a good idea (see below) that could serve the
human readable part. I would consider computing a hash for the config.ini file,
ie the build, and embedding it. If you wanted to capture the state of the RTEMS
source built optionally compute a hash for the entire source tree and embed that
as well. You can then have calls such as:

const char* rtems_config_build_hash(void);
const char* rtems_config_source_hash(void);

 [ the last one could return "NOT-AVAILABLE" if not enabled ]

The key point is defining markers, with defaults if optional, then wrapping your
configuration management system rou

Re: [PATCH 7/8] validation/ts-performance-0: Add test suite

2020-11-17 Thread Chris Johns 
On 17/11/20 6:02 pm, Sebastian Huber wrote:
> On 17/11/2020 00:15, Chris Johns wrote:
> 
> new file mode 100644
> index 00..0f7db65a8e
> --- /dev/null
> +++ b/testsuites/validation/ts-default.h
> @@ -0,0 +1,237 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @brief This header file provides the default validation test suite 
> runner
> + *   and application configuration.
> + */
> [...]
> +#define CONFIGURE_SCHEDULER_EDF_SMP
> +
> +#include 
> +
> +RTEMS_SCHEDULER_EDF_SMP(a);
> +
> +RTEMS_SCHEDULER_EDF_SMP(b);
> +
> +RTEMS_SCHEDULER_EDF_SMP(c);
> +
> +#define CONFIGURE_SCHEDULER_TABLE_ENTRIES \
> +  RTEMS_SCHEDULER_TABLE_EDF_SMP(a, rtems_build_name('A', ' ', ' ', ' 
> ')), \
> +  RTEMS_SCHEDULER_TABLE_EDF_SMP(b, rtems_build_name('B', ' ', ' ', ' 
> ')), \
> +  RTEMS_SCHEDULER_TABLE_EDF_SMP(c, rtems_build_name('C', ' ', ' ', ' '))
> +
> +#define CONFIGURE_SCHEDULER_ASSIGNMENTS \
> +  RTEMS_SCHEDULER_ASSIGN(0, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_MANDATORY), 
> \
> +  RTEMS_SCHEDULER_ASSIGN(1, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL), \
> +  RTEMS_SCHEDULER_ASSIGN(2, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL), \
> +  RTEMS_SCHEDULER_ASSIGN(2, RTEMS_SCHEDULER_ASSIGN_PROCESSOR_OPTIONAL)
> +
 These seems specific but I ma not sure.
>>> This configuration provides enough resources to run a wide range of test 
>>> cases.
>>> For example, the SMP scheduler configuration with three schedulers can be 
>>> used
>>> to test most of the SMP support of RTEMS.
 Do tests depend on this configuration?
>>> Yes, if the configuration provides the necessary resources, they pass, 
>>> otherwise
>>> they fail.
>> Any particular reason for those schedulers in that order?
> Most tests use one processor. With just two processors you can probably test
> more than 90% of the RTEMS SMP support. Only some very specific corner cases
> need more than two processors. This is a general purpose test suite and the
> configuration will be adapted if a new test case needs something special. If 
> it
> is too special, then it can be added to a dedicated test suite.

I see and thanks for the explanation.

 Does the number of cores available effect this or the dependent tests? I 
 assume
 this is included in a number of tests.
>>> If a test needs three processors and a board has only two, then the test 
>>> case
>>> should fail.
>> Will those BSPs have the failing tests excluded?
> Currently, there is no support for the new test framework in the RTEMS Tester.
> You can only specify the expected state of a complete test suite. I hope to
> eventually add some support for the new test framework so that the expected
> state of individual test cases can be specified.

OK.

>>
>> I would like to be comfortable the tests and these set ups are not solely
>> focused on the LEON.
> I am not focused on the LEON. Why do you think something is LEON-specific in
> this test suite?

Nothing specific. I was wondering why that specific configuration over another.

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

Re: libdl: How to debug dl object with GDB

2020-11-17 Thread Chris Johns 



On 17/11/20 10:43 pm, Hesham Almatary wrote:
> Hello,
> 
> I am trying to debug a dynamically loaded ELF object with GDB: My setup is:
> rtems-riscv64:
> GDB: GNU gdb (GDB) 10.0.50.20200904-git (build with RSB/rtems6)
> Host: Ubuntu 20.04.1 LTS
> 
> GDB doesn't seem to notice when I dlopen an object (which gets loaded,
> linked and run fine). 

libdl has the NetBSD type support built in for debugging. A function is called
when a module is loaded and there is a table of modules GDB reads and then loads
the object file.

> Any instructions or idea how to troubleshoot that further?

At this point the simplest path is to get the load address(es) and load the
symbols with the VMA.

Anything else would require adding support to GDB or maybe a python module would
work. I am not sure if the python approach is possible.

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

[PATCH] Add License file for BSD-3-Clause

2020-11-17 Thread Christian Mauderer 
We have some files with a SPDX identifier for this license. Therefore
the license should be here too.
---

Note: This is a resubmission of the patch. Previously I submitted it together
with the patches that add a new imxrt BSP:

https://lists.rtems.org/pipermail/devel/2020-November/063273.html

I only noted that it would have been better separate after Gedare said it.

 LICENSE.BSD-3-Clause | 27 +++
 1 file changed, 27 insertions(+)
 create mode 100644 LICENSE.BSD-3-Clause

diff --git a/LICENSE.BSD-3-Clause b/LICENSE.BSD-3-Clause
new file mode 100644
index 00..09d01c1ff5
--- /dev/null
+++ b/LICENSE.BSD-3-Clause
@@ -0,0 +1,27 @@
+https://spdx.org/licenses/BSD-3-Clause
+
+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.
+3. Neither the name of the copyright holder nor the names of its
+   contributors may be used to endorse or promote products derived
+   from this software without specific prior written permission.
+
+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
+HOLDER 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.
-- 
2.26.2

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

[PATCH] shell: Add i2c and spi commands

2020-11-17 Thread 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.
---

Note: This is a resubmission of the patch. Previously I submitted it together
with the patches that add a new imxrt BSP:

https://lists.rtems.org/pipermail/devel/2020-November/063273.html

I only noted that it would have been better separate after Gedare said it.

 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 ++
 spec/build/cpukit/objshell.yml|   4 +
 7 files changed, 569 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 4e370ae639..2adfcf933f 100644
--- a/cpukit/Makefile.am
+++ b/cpukit/Makefile.am
@@ -1495,6 +1495,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
+ * INTERR

Re: [PATCH rtems-docs 1/2] user/bsps: Add imxrt

2020-11-17 Thread Christian Mauderer 

Am 17.11.20 um 18:41 schrieb Gedare Bloom:

On Tue, Nov 17, 2020 at 4:09 AM Christian Mauderer
 wrote:


Update #4180
---
  user/bsps/arm/imxrt.rst | 174 
  user/bsps/bsps-arm.rst  |   1 +
  2 files changed, 175 insertions(+)
  create mode 100644 user/bsps/arm/imxrt.rst

diff --git a/user/bsps/arm/imxrt.rst b/user/bsps/arm/imxrt.rst
new file mode 100644
index 000..41c6bff
--- /dev/null
+++ b/user/bsps/arm/imxrt.rst
@@ -0,0 +1,174 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2020 embedded brains GmbH
+.. Copyright (C) 2020 Christian Mauderer
+
+imxrt (NXP i.MXRT)
+==
+
+This BSP offers only one variant, the `imxrt1052`. This variant supports the
+i.MXRT 1052 processor on a IMXRT1050-EVKB (tested with rev A1). You can also
+configure it to work with custom boards.
+
+Build Configuration Options
+---
+
+Please see the documentation of the `IMXRT_*` and `BSP_*` configuration options
+for that. You can generate a default set of options with::

one colon: I think?



That's the start for the literal block below. Restructured Text allows 
three syntax variants for that. From Wikipedia:


::

  some literal text

This may also be used inline at the end of a paragraph, like so::

  some more literal text

.. code:: python

   print("A literal block directive explicitly marked as python code")


+
+  ./waf bsp_defaults --rtems-bsps=arm/imxrt1052 > config.ini
+
+Boot Process
+
+
+There are two possible boot processes supported:
+
+1) The ROM code loads a configuration from HyperFlash (connected to FlexSPI),
+   does some initialization (based on device configuration data (DCD)) and then
+   starts the application. This is the default case. `linkcmds.flexspi` is used
+   for this case.
+
+2) Some custom bootloader does the basic initialization, loads the application
+   to SDRAM and starts it from there. Select the `linkcmds.sdram` for this.
+
+For programming the HyperFlash in case 1, you can use the on board debugger
+integrated into the IMXRT1050-EVKB. You can generate a flash image out of a
+compiled RTEMS application with for example::
+
+  arm-rtems6-objcopy -O binary 
build/arm/imxrt1052/testsuites/samples/hello.exe hello.bin
+
+Then just copy the generated binary to the mass storage provided by the
+debugger. Wait a bit till the mass storage vanishes and re-appears. After that,
+reset the board and the newly programmed application will start.
+
+For debugging: Create a special application with a `while(true)` loop at end of
+`bsp_start_hook_1`. Load that application into flash. Then remove the loop
+again, build your BSP for SDRAM and use a debugger to load the application into
+SDRAM after the BSP started from flash did the basic initialization.
+
+Flash Image
+---
+
+For booting from a HyperFlash (or other storage connected to FlexSPI), the ROM
+code of the i.MXRT first reads some special flash header information from a
+fixed location of the connected flash device. This consists of the Image vector
+table (IVT), Boot data and Device configuration data (DCD).
+
+In RTEMS, these flash headers are generated using some C-structures. If you use
+a board other then the IMXRT1050-EVKB, they have to be adapted. To do that

s/then/than


Thanks.


s/they have/it has
I thought that multiple structures for multiple headers have to be 
adapted. Would it really be correct to use "it" for that?





+re-define the following variables in your application (you only need the ones
+that need different values):
+
+.. code-block:: c
+
+  #include 
+  const uint8_t imxrt_dcd_data[] =
+  { /* Your DCD data here */ };
+  const ivt imxrt_image_vector_table =
+  { /* Your IVT here */ };
+  const BOOT_DATA_T imxrt_boot_data =
+  { /* Your boot data here */ };
+  const flexspi_nor_config_t imxrt_flexspi_config =
+  { /* Your FlexSPI config here */ };
+
+You can find the default definitions in `bsps/arm/imxrt/start/flash-*.c`. Take 
a
+look at the `i.MX RT1050 Processor Reference Manual, Rev. 4, 12/2019` chapter
+`9.7 Program image` for details about the contents.
+
+FDT
+---
+
+The BSP used a FDT based initialization. The FDT is linked into the 
application.
+You can find the default FDT used in the BSP in
+`bsps/arm/imxrt/dts/imxrt1050-evkb.dts`. To use your own FDT compile it and
+convert it into a C file with (replace `YOUR.dts` and simmilar with your FDT
+source names)::
+
+  sh> export BSP_DIR="${RTEMS_SRC_DIR}/bsps/arm/imxrt/"
+  sh> arm-rtems6-cpp -P -x assembler-with-cpp \
+  -I "${BSP_DIR}/include/" \
+  -include "YOUR.dts" /dev/null | \
+  dtc -@ -O dtb -o "YOUR.dtb" -b 0 -p 1024
+  sh> rtems-bin2c -C -N imxrt_dtb "YOUR.dtb" "YOUR.c"
+
+Make sure that your new c file is compiled and linked into the application.
+
+Clock Driver
+
+
+The clock driver uses the generic `ARMv7-M Clock`.
+
+IOMUX
+-
+
+The i.MXRT IOMUXC is initialized based on the FDT. For

Re: [PATCHES] Add imxrt BSP

2020-11-17 Thread Christian Mauderer 

Hello Gedare,

Am 17.11.20 um 18:33 schrieb Gedare Bloom:

Everything except 5 looks good. I or someone else should take a closer
look at that.


Thanks for the review.

I noted that I most likely have to rework the MPU setup a bit. A table 
based approach (similar to the one used for ARMV7_CP15 based BSPs) would 
be better to allow a user to overwrite the table if he has a board with 
a slightly different memory configuration.




On Tue, Nov 17, 2020 at 4:04 AM Christian Mauderer
 wrote:


Hello,

the following patches add a BSP for IMXRT1050-EVKB. In case the import
patch is too big: I pushed the patches here too:

https://gitlab.com/c-mauderer/rtems/-/tree/cm/20201117_imxrt

Best regards

Christian


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


--

embedded brains GmbH
Christian MAUDERER
Dornierstr. 4
82178 Puchheim
Germany
email: christian.maude...@embedded-brains.de
Phone: +49-89-18 94 741 - 18
Fax:   +49-89-18 94 741 - 08
PGP: Public key available on request.

embedded brains GmbH
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