Re: [PATCH rtems v3 3/7] cpu/armv7m: Add table based init for ARMV7M_MPU

[Christian Mauderer]

Am 19.11.20 um 10:15 schrieb Sebastian Huber:


On 19/11/2020 09:51, Christian Mauderer wrote:

+  mpu = _ARMV7M_MPU;
+  scb = _ARMV7M_SCB;
+
+  scb->shcsr &= ~ARMV7M_SCB_SHCSR_MEMFAULTENA;
I think it is not necessary to touch the shcsr. Disabling the MPU should 
be enough.


OK. I'll try it on the imxrt.


+  mpu->ctrl = 0;
+
+  _ARM_Data_synchronization_barrier();
+  _ARM_Instruction_synchronization_barrier();




--

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

Re: [PATCH rtems v3 3/7] cpu/armv7m: Add table based init for ARMV7M_MPU

[Christian Mauderer]

Am 19.11.20 um 10:14 schrieb Sebastian Huber:

On 19/11/2020 09:51, Christian Mauderer wrote:


+  _Assert(cfg_count > region_count);


  _Assert(cfg_count <= region_count)

With this change it is fine to check in.



Stupid mistake. Sorry. I'll fix it before check in.

I'll give the other patches one more day for review.

Best regards

Christian
--

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

[PATCH rtems v3 3/7] cpu/armv7m: Add table based init for ARMV7M_MPU

[Christian Mauderer]

Modify the MPU functions of the stm32h7 BSP to be table based and
available for all ARMV7M BSPs.

Update #4180
---
 bsps/arm/stm32h7/include/stm32h7/mpu-config.h |  44 +++
 bsps/arm/stm32h7/start/bspstarthooks.c| 120 +-
 bsps/arm/stm32h7/start/mpu-config.c   |  75 +++
 .../cpu/arm/include/rtems/score/armv7m.h  | 102 +++
 spec/build/bsps/arm/stm32h7/bspstm32h7.yml|   2 +
 5 files changed, 225 insertions(+), 118 deletions(-)
 create mode 100644 bsps/arm/stm32h7/include/stm32h7/mpu-config.h
 create mode 100644 bsps/arm/stm32h7/start/mpu-config.c

diff --git a/bsps/arm/stm32h7/include/stm32h7/mpu-config.h 
b/bsps/arm/stm32h7/include/stm32h7/mpu-config.h
new file mode 100644
index 00..274532
--- /dev/null
+++ b/bsps/arm/stm32h7/include/stm32h7/mpu-config.h
@@ -0,0 +1,44 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * 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, 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_STM32H7_STM32H7_MPU_CONFIG_H
+#define LIBBSP_ARM_STM32H7_STM32H7_MPU_CONFIG_H
+
+#include 
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+extern const ARMV7M_MPU_Region_config stm32h7_config_mpu_region[];
+extern const size_t stm32h7_config_mpu_region_count;
+
+#ifdef __cplusplus
+}
+#endif /* __cplusplus */
+
+#endif /* LIBBSP_ARM_STM32H7_STM32H7_MPU_CONFIG_H */
diff --git a/bsps/arm/stm32h7/start/bspstarthooks.c 
b/bsps/arm/stm32h7/start/bspstarthooks.c
index 565bd6876a..dcd4b0bef2 100644
--- a/bsps/arm/stm32h7/start/bspstarthooks.c
+++ b/bsps/arm/stm32h7/start/bspstarthooks.c
@@ -31,6 +31,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include 
@@ -83,123 +84,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;
-  volatile ARMV7M_SCB *scb;
-  uint32_t region_count;
-  uint32_t region;
-
-  mpu = _ARMV7M_MPU;
-  scb = _ARMV7M_SCB;
-
-  region_count = ARMV7M_MPU_TYPE_DREGION_GET(mpu->type);
-
-  for (region = 0; region < region_count; ++region) {
-mpu->rbar = ARMV7M_MPU_RBAR_VALID | region;
-mpu->rasr = 0;
-  }
-
-  set_region(
-mpu,
-0,
-ARMV7M_MPU_RASR_XN
-  | ARMV7M_MPU_RASR_AP(0x3)
-  | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
-  | ARMV7M_MPU_RASR_ENABLE,
-stm32h7_memory_sram_axi_begin,
-stm32h7_memory_sram_axi_end
-  );
-  set_region(
-mpu,
-1,
-ARMV7M_MPU_RASR_XN
-  | ARMV7M_MPU_RASR_AP(0x3)
-  | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
-  | ARMV7M_MPU_RASR_ENABLE,
-stm32h7_memory_sdram_1_begin,
-stm32h7_memory_sdram_1_end
-  );
-  set_region(
-mpu,
-2,
-ARMV7M_MPU_RASR_AP(0x5)
-  | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
-  | ARMV7M_MPU_RASR_ENABLE,
-bsp_section_start_begin,
-bsp_section_text_end
-  );
-  

[PATCH rtems v3 0/7] Add imxrt BSP

[Christian Mauderer]

Hello,

again an updated version. There haven't been relevant changes beneath
patch 3 (some follow up ones in 7) so I'm only sending patch 3.

Changes:

- renames like suggested by Sebastian
- the MPU is now disabled, set up and re-enabled
- every MPU region is only set up once due to that
- I moved the constants for STM32H7 into a separate file to enable the
  main advantage of that initialization: Allowing the user to provide
  a different configuration in his application.

Best regards

Christian


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

Re: [PATCH rtems v2 3/7] cpu/armv7m: Add table based init for ARMV7M_MPU

[Christian Mauderer]

Am 19.11.20 um 08:19 schrieb Sebastian Huber:

On 18/11/2020 15:45, Christian Mauderer wrote:


+/**
+ * Higher level region configuration.
+ *
+ * Allows to configure with begin and end which is more convenient for
+ * calculating the sizes from linker command file. Note that you 
still have to

+ * follow the following rules:
+ *
+ * - Begin address has to be aligned to 0x20 (lower 5 bits set to 0)
+ * - Sizes can only be a value of 2^x with a minimum of 32 Byte. If 
you have an

+ *   end address that is not aligned, the region will get bigger.
+ * - Later regions have higher priority.
+ */
+typedef struct {
+  const void *begin;
+  const void *end;
+  uint32_t flags;


uint32_t rasr;

I guess the flags are actually a value stored directly to the RASR?


+} ARMV7M_MPU_Region_Config;


ARMV7M_MPU_Region_config


+
  typedef struct {
    uint32_t dhcsr;
    uint32_t dcrsr;
@@ -611,6 +632,85 @@ void _ARMV7M_Supervisor_call( void );
  void _ARMV7M_Clock_handler( void );
+static inline uint32_t _ARMV7M_MPU_get_region_size(uintptr_t size)


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


_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;
+}
+
+static inline void _ARMV7M_MPU_disable_region(


_ARMV7M_MPU_Disable_region


+  volatile ARMV7M_MPU *mpu,
+  uint32_t region
+)
+{
+  mpu->rbar = ARMV7M_MPU_RBAR_VALID | region;
+  mpu->rasr = 0;
+}
+
+static inline void _ARMV7M_MPU_setup_from_config_and_enable(
+  const ARMV7M_MPU_Region_Config *cfg,
+  size_t cfg_count
+)


_ARMV7M_MPU_Setup

The config is implicit in the parameter. You don't necessarily enable a 
configured region. It depends on the user provided RASR value.



+{
+  volatile ARMV7M_MPU *mpu;
+  volatile ARMV7M_SCB *scb;
+  uint32_t region_count;
+  uint32_t region;
+
+  mpu = _ARMV7M_MPU;
+  scb = _ARMV7M_SCB;
+
+  region_count = ARMV7M_MPU_TYPE_DREGION_GET(mpu->type);
+
+  if (cfg_count > region_count) {
+    rtems_panic("invalid MPU config");
+  }


I think rtems_panic() is too heavy weight at this point. It uses 
printk(). Maybe just use _Assert(). I think we need some light weight 
general purpose fatal error which could just use the return address to 
identify the error location.



+
+  for (region = 0; region < region_count; ++region) {


for (region = cfg_count; region < region_count; ++region)

Only disable not configured regions?


I think I maybe have to disable the MPU first if I do that. Otherwise it 
is possible that there is (for example) a region 0 that prevents access 
to all memory and a high region (lets say 5) that allows access to 
program memory. As soon as I clear the high one but not the low one, the 
system will crash because it can't access the memory any more.


But most likely a similar situation can be constructed with cleaning all 
regions. I'll take a look at disabling MPU before setting it up.





+    _ARMV7M_MPU_disable_region(mpu, region);
+  }
+
+  for (region = 0; region < cfg_count; ++region) {
+    _ARMV7M_MPU_set_region(mpu, region, cfg->flags, cfg->begin, 
cfg->end);

+  }
+
+  mpu->ctrl = ARMV7M_MPU_CTRL_ENABLE | ARMV7M_MPU_CTRL_PRIVDEFENA;
+  scb->shcsr |= ARMV7M_SCB_SHCSR_MEMFAULTENA;
+
+  _ARM_Data_synchronization_barrier();
+  _ARM_Instruction_synchronization_barrier();
+}




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

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

[Christian Mauderer]

Thanks. I pushed it.

Am 18.11.20 um 17:17 schrieb Gedare Bloom:

Looks good, push it

On Wed, Nov 18, 2020 at 12:37 AM Christian Mauderer
 wrote:


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


--

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

[PATCH rtems v2 6/7] bsp/imxrt: Adapt imported files

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

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

[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 

[PATCH rtems v2 0/7] Add imxrt BSP

[Christian Mauderer]

Hello,

this is a second verson for the imxrt BSP. If no one objects, it will be
the last for this patch set.

I don't re-send the documentation and libbsd parts. For libbsd it will
be the same and for documentation it will be the one with changes like
discussed.

The BSD-3-clause license and console commands are now on the list for
review in separate mails.

The import patch is still the same. It will most likely hit the size
limit for the mailing list again.

Changes in this patch set:

- I replaced the transient event with a semaphore in the SPI driver.
- The MPU initialization is reworked. Now a user could adapt it by
  overwriting the variables in his application.
- I fixed a bug that I introduced in imx.

Best regards

Christian


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

[PATCH rtems v2 1/7] bsps/imx: Move imx_iomux to arm/shared

[Christian Mauderer]

Update #4180
---
 bsps/arm/imx/headers.am   |  2 -
 bsps/arm/imx/include/bsp.h|  2 -
 bsps/arm/imx/spi/imx-ecspi.c  |  1 +
 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 ++--
 10 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..8b95a79535 100644
--- a/bsps/arm/imx/include/bsp.h
+++ b/bsps/arm/imx/include/bsp.h
@@ -59,8 +59,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/imx/spi/imx-ecspi.c b/bsps/arm/imx/spi/imx-ecspi.c
index 26ba812f62..1ffc4d9798 100644
--- a/bsps/arm/imx/spi/imx-ecspi.c
+++ b/bsps/arm/imx/spi/imx-ecspi.c
@@ -15,6 +15,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
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 

[PATCH rtems v2 3/7] cpu/armv7m: Add table based init for ARMV7M_MPU

[Christian Mauderer]

Modify the MPU functions of the stm32h7 BSP to be table based and
available for all ARMV7M BSPs.

Update #4180
---
 bsps/arm/stm32h7/start/bspstarthooks.c| 168 ++
 .../cpu/arm/include/rtems/score/armv7m.h  | 100 +++
 2 files changed, 150 insertions(+), 118 deletions(-)

diff --git a/bsps/arm/stm32h7/start/bspstarthooks.c 
b/bsps/arm/stm32h7/start/bspstarthooks.c
index 565bd6876a..41c510aa4c 100644
--- a/bsps/arm/stm32h7/start/bspstarthooks.c
+++ b/bsps/arm/stm32h7/start/bspstarthooks.c
@@ -35,6 +35,52 @@
 
 #include 
 
+const ARMV7M_MPU_Region_Config
+  stm32h7_start_config_mpu_region [] = {
+{
+  .begin = stm32h7_memory_sram_axi_begin,
+  .end = stm32h7_memory_sram_axi_end,
+  .flags = ARMV7M_MPU_RASR_XN
+| ARMV7M_MPU_RASR_AP(0x3)
+| ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
+| ARMV7M_MPU_RASR_ENABLE,
+}, {
+  .begin = stm32h7_memory_sdram_1_begin,
+  .end = stm32h7_memory_sdram_1_end,
+  .flags = ARMV7M_MPU_RASR_XN
+| ARMV7M_MPU_RASR_AP(0x3)
+| ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
+| ARMV7M_MPU_RASR_ENABLE,
+}, {
+  .begin = bsp_section_start_begin,
+  .end = bsp_section_text_end,
+  .flags = ARMV7M_MPU_RASR_AP(0x5)
+| ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
+| ARMV7M_MPU_RASR_ENABLE,
+}, {
+  .begin = bsp_section_rodata_begin,
+  .end = bsp_section_rodata_end,
+  .flags = ARMV7M_MPU_RASR_XN
+| ARMV7M_MPU_RASR_AP(0x5)
+| ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
+| ARMV7M_MPU_RASR_ENABLE,
+}, {
+  .begin = bsp_section_nocache_begin,
+  .end = bsp_section_nocachenoload_end,
+  .flags = ARMV7M_MPU_RASR_XN
+| ARMV7M_MPU_RASR_AP(0x3)
+| ARMV7M_MPU_RASR_TEX(0x2)
+| ARMV7M_MPU_RASR_ENABLE,
+}, {
+  .begin = stm32h7_memory_null_begin,
+  .end = stm32h7_memory_null_end,
+  .flags = ARMV7M_MPU_RASR_XN | ARMV7M_MPU_RASR_ENABLE,
+}
+  };
+
+const size_t stm32h7_start_config_mpu_region_count =
+  RTEMS_ARRAY_SIZE(stm32h7_start_config_mpu_region);
+
 void HAL_MspInit(void)
 {
   __HAL_RCC_SYSCFG_CLK_ENABLE();
@@ -83,123 +129,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;
-  volatile ARMV7M_SCB *scb;
-  uint32_t region_count;
-  uint32_t region;
-
-  mpu = _ARMV7M_MPU;
-  scb = _ARMV7M_SCB;
-
-  region_count = ARMV7M_MPU_TYPE_DREGION_GET(mpu->type);
-
-  for (region = 0; region < region_count; ++region) {
-mpu->rbar = ARMV7M_MPU_RBAR_VALID | region;
-mpu->rasr = 0;
-  }
-
-  set_region(
-mpu,
-0,
-ARMV7M_MPU_RASR_XN
-  | ARMV7M_MPU_RASR_AP(0x3)
-  | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
-  | ARMV7M_MPU_RASR_ENABLE,
-stm32h7_memory_sram_axi_begin,
-stm32h7_memory_sram_axi_end
-  );
-  set_region(
-mpu,
-1,
-ARMV7M_MPU_RASR_XN
-  | ARMV7M_MPU_RASR_AP(0x3)
-  | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
-  | ARMV7M_MPU_RASR_ENABLE,
-stm32h7_memory_sdram_1_begin,
-stm32h7_memory_sdram_1_end
-  );
-  set_region(
-mpu,
-2,
-ARMV7M_MPU_RASR_AP(0x5)
-  | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
-  | ARMV7M_MPU_RASR_ENABLE,
-bsp_section_start_begin,
-bsp_section_text_end
-  );
-  set_region(
-mpu,
-3,
-ARMV7M_MPU_RASR_XN
-  | ARMV7M_MPU_RASR_AP(0x5)
-  | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
-  | ARMV7M_MPU_RASR_ENABLE,
-bsp_section_rodata_begin,
-bsp_section_rodata_end
-  );
-  set_region(
-mpu,
-4,
-ARMV7M_MPU_RASR_XN
-  | ARMV7M_MPU_RASR_AP(0x3)
-  | ARMV7M_MPU_RASR_TEX(0x2)
-  | ARMV7M_MPU_RASR_ENABLE,
-bsp_section_nocache_begin,
-bsp_section_nocachenoload_end
-  );
-  set_region(
-mpu,
-region - 1,
-ARMV7M_MPU_RASR_XN | ARMV7M_MPU_RASR_ENABLE,
-stm32h7_memory_null_begin,
-stm32h7_memory_null_end
-  );
-
-  mpu->ctrl = ARMV7M_MPU_CTRL_ENABLE | ARMV7M_MPU_CTRL_PRIVDEFENA;
-  scb->shcsr |= 

[PATCH rtems v2 2/7] bsps/imx: Move imx-gpio to arm/shared

[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

Re: [PATCHES] Add imxrt BSP

[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

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

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

[PATCH] shell: Add i2c and spi commands

[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[];
   _shell_RTC_Command,
 #endif
 
+#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \
+  && !defined(CONFIGURE_SHELL_NO_COMMAND_SPI)) \
+|| defined(CONFIGURE_SHELL_COMMAND_SPI)
+  _shell_SPI_Command,
+#endif
+
+#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \
+  && !defined(CONFIGURE_SHELL_NO_COMMAND_I2CDETECT)) \
+|| defined(CONFIGURE_SHELL_COMMAND_I2CDETECT)
+  _shell_I2CDETECT_Command,
+#endif
+
+#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \
+  && !defined(CONFIGURE_SHELL_NO_COMMAND_I2CGET)) \
+|| defined(CONFIGURE_SHELL_COMMAND_I2CGET)
+  _shell_I2CGET_Command,
+#endif
+
+#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \
+  && !defined(CONFIGURE_SHELL_NO_COMMAND_I2CSET)) \
+|| defined(CONFIGURE_SHELL_COMMAND_I2CSET)
+  _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 

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

[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

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

[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

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

[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

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

[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-libbsd 2/2] if_ffec: Fix cache handling on tx

[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

[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 8/9] bsp/imxrt: Adapt imported files

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

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

[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[];
   _shell_RTC_Command,
 #endif
 
+#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \
+  && !defined(CONFIGURE_SHELL_NO_COMMAND_SPI)) \
+|| defined(CONFIGURE_SHELL_COMMAND_SPI)
+  _shell_SPI_Command,
+#endif
+
+#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \
+  && !defined(CONFIGURE_SHELL_NO_COMMAND_I2CDETECT)) \
+|| defined(CONFIGURE_SHELL_COMMAND_I2CDETECT)
+  _shell_I2CDETECT_Command,
+#endif
+
+#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \
+  && !defined(CONFIGURE_SHELL_NO_COMMAND_I2CGET)) \
+|| defined(CONFIGURE_SHELL_COMMAND_I2CGET)
+  _shell_I2CGET_Command,
+#endif
+
+#if (defined(CONFIGURE_SHELL_COMMANDS_ALL) \
+  && !defined(CONFIGURE_SHELL_NO_COMMAND_I2CSET)) \
+|| defined(CONFIGURE_SHELL_COMMAND_I2CSET)
+  _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 command implemented 

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

[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

[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 

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

[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

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

[PATCHES] Add imxrt BSP

[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

[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

Re: [PATCH v2 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

[Christian Mauderer]

Hello,

sorry for the long delay. I tested it on xilinx-zynq-a9-qemu (which
doesn't have a FDT) and the test seems to run fine. So I'm OK with the
patches. If no one objects in the next two days, I'll commit them.

Best regards

Christian

On 03/11/2020 19:18, G S Niteesh Babu wrote:
> RTEMS OFW is a FDT only implementation of the OpenFirmWare
> interface. This API is created to be compatible with FreeBSD
> OpenFirmWare interface. The main intention is to make
> porting of FreeBSD drivers to RTEMS easier.
> 
> Most functions implemented have an direct one-one mapping
> with the original OFW API and some extra auxiliary functions
> were implemented to make working with device trees easier in
> RTEMS.
> 
> Update #3784
> ---
>  bsps/include/ofw/ofw.h| 548 +++
>  bsps/include/ofw/ofw_compat.h |  74 
>  bsps/shared/ofw/ofw.c | 682 ++
>  spec/build/bsps/obj.yml   |   5 +
>  4 files changed, 1309 insertions(+)
>  create mode 100644 bsps/include/ofw/ofw.h
>  create mode 100644 bsps/include/ofw/ofw_compat.h
>  create mode 100644 bsps/shared/ofw/ofw.c
> 
> diff --git a/bsps/include/ofw/ofw.h b/bsps/include/ofw/ofw.h
> new file mode 100644
> index 00..4c402671a4
> --- /dev/null
> +++ b/bsps/include/ofw/ofw.h
> @@ -0,0 +1,548 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup ofw
> + *
> + * RTEMS FDT implementation of OpenFirmWare Interface.
> + *
> + * RTEMS OFW is a FDT only implementation of the OpenFirmWare interface.
> + * This API is created to be compatible with FreeBSD OpenFirmWare interface.
> + * The main intention is to make porting of FreeBSD drivers to RTEMS easier.
> + */
> +
> +/*
> + * Copyright (C) 2020 Niteesh Babu G S 
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifndef _OFW_H
> +#define _OFW_H
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * Represents a node in the device tree. The offset from fdtp to node is used
> + * instead of fdt offset to make sure this is compatible with OF interface in
> + * FreeBSD.
> + */
> +typedef uint32_t  phandle_t;
> +/**
> + * Represents the effective phandle of the node.
> + */
> +typedef uint32_t  ihandle_t;
> +/**
> + * Represents the data type of the buffer.
> + */
> +typedef uint32_t  pcell_t;
> +
> +/**
> + * @struct rtems_ofw_memory_area
> + *
> + * This is used to represent elements(FDT properties) that define
> + * region of memory address.
> + */
> +typedef struct {
> +  /** The start address of the memory region. */
> +  uint32_t start;
> +  /** The size of the memory region. */
> +  uint32_t size;
> +} rtems_ofw_memory_area;
> +
> +/**
> + * @struct rtems_ofw_ranges
> + *
> + * This is used to represent the ranges property in the device tree.
> + */
> +typedef struct {
> +  /** The physical address within the child bus address space */
> +  uint32_t child_bus;
> +  /** The physical address within the parent bus address space */
> +  uint32_t parent_bus;
> +  /** The size of the range in the child’s address space */
> +  uint32_t size;
> +} rtems_ofw_ranges;
> +
> +/**
> + * @brief Gets the node that is next to @a node.
> + *
> + * @param[in] node Node offset
> + *
> + * @retval Peer node offset Successful operation.
> + * @retval 0 No peer node or invalid node handle
> + */
> +phandle_t rtems_ofw_peer(
> +  phandle_t   node
> +);
> +
> +/**
> + * @brief Gets the node that is the child of @a node.
> + *
> + * @param[in] node Node offset
> + *
> + * @retval child node offset Successful operation.
> + * @retval 0 No child node or invalid node handle

Re: [PATCH] bsp/atsam: Fix XDMAD status

[Christian Mauderer]

On 10/11/2020 06:34, Chris Johns wrote:

On 9/11/20 7:20 pm, Christian Mauderer wrote:

I would like to apply this patch to master (ticket #4173) and to the 5 branch
(ticket #4172). It would be great if someone could have a look and acknowledge 
it.


OK for 5.

Chris



Thanks. I'll give it another day and then commit it.

Best regards

Christian

--

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

Re: [PATCH v2 2/2] libtests/ofw01: Added a test for RTEMS OFW

[Christian Mauderer]

Hello Niteesh,

I've seen the patches. I have to run a test at least on one BSP with and
one without a FDT to make sure they don't break test runs.

Best regards

Christian

On 09/11/2020 04:45, Niteesh G. S. wrote:
> Hello,
> 
> Pinging again incase this patch missed your attention.
> 
> Thanks,
> Niteesh.
> 
> On Tue, Nov 3, 2020 at 11:49 PM G S Niteesh Babu  > wrote:
> 
> Added a basic test for the implemented RTEMS OFW
> API.
> ---
>  spec/build/testsuites/libtests/grp.yml   |   2 +
>  spec/build/testsuites/libtests/ofw01.yml |  21 +++
>  testsuites/libtests/ofw01/init.c         | 187 +++
>  testsuites/libtests/ofw01/ofw01.doc      |  29 
>  testsuites/libtests/ofw01/ofw01.scn      |   2 +
>  testsuites/libtests/ofw01/some.c         |  72 +
>  testsuites/libtests/ofw01/some.dts       |  76 +
>  testsuites/libtests/ofw01/some.h         |  15 ++
>  8 files changed, 404 insertions(+)
>  create mode 100644 spec/build/testsuites/libtests/ofw01.yml
>  create mode 100644 testsuites/libtests/ofw01/init.c
>  create mode 100644 testsuites/libtests/ofw01/ofw01.doc
>  create mode 100644 testsuites/libtests/ofw01/ofw01.scn
>  create mode 100644 testsuites/libtests/ofw01/some.c
>  create mode 100644 testsuites/libtests/ofw01/some.dts
>  create mode 100644 testsuites/libtests/ofw01/some.h
> 
> diff --git a/spec/build/testsuites/libtests/grp.yml
> b/spec/build/testsuites/libtests/grp.yml
> index b9ca014b0d..1aa136854a 100644
> --- a/spec/build/testsuites/libtests/grp.yml
> +++ b/spec/build/testsuites/libtests/grp.yml
> @@ -316,6 +316,8 @@ links:
>    uid: write
>  - role: build-dependency
>    uid: writev
> +- role: build-dependency
> +  uid: ofw01
>  type: build
>  use-after:
>  - rtemstest
> diff --git a/spec/build/testsuites/libtests/ofw01.yml
> b/spec/build/testsuites/libtests/ofw01.yml
> new file mode 100644
> index 00..8517c58bad
> --- /dev/null
> +++ b/spec/build/testsuites/libtests/ofw01.yml
> @@ -0,0 +1,21 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +build-type: test-program
> +cflags: []
> +copyrights:
> +- Copyright (C) 2020 Niteesh G S
> +cppflags: []
> +cxxflags: []
> +enabled-by: true
> +features: c cprogram
> +includes: []
> +ldflags:
> +- -Wl,--wrap=bsp_fdt_get
> +links: []
> +source:
> +- testsuites/libtests/ofw01/init.c
> +- testsuites/libtests/ofw01/some.c
> +stlib: []
> +target: testsuites/libtests/ofw01.exe
> +type: build
> +use-after: []
> +use-before: []
> diff --git a/testsuites/libtests/ofw01/init.c
> b/testsuites/libtests/ofw01/init.c
> new file mode 100644
> index 00..82ee5eb11f
> --- /dev/null
> +++ b/testsuites/libtests/ofw01/init.c
> @@ -0,0 +1,187 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/*
> + * Copyright (C) <2020> Niteesh G S  >
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *    notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *    notice, this list of conditions and the following disclaimer
> in the
> + *    documentation and/or other materials provided with the
> distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS "AS IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
> PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
> ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "some.h"
> +
> +#define BUF_SIZE 100
> +
> +const char rtems_test_name[] = "OFW 01";
> +

Re: [PATCH] bsp/atsam: Fix XDMAD status

[Christian Mauderer]

I would like to apply this patch to master (ticket #4173) and to the 5 
branch (ticket #4172). It would be great if someone could have a look 
and acknowledge it.


On 09/11/2020 09:16, Christian Mauderer wrote:

In "bsp/atsam: Simplify XDMAD_Handler()" (5f813694f68cee) the interrupt
callback has been made unconditional. That allowed to avoid some special
deadlock situations in error cases. But it removed part of the XDMAD
status handling.

This patch adds the ability to update the XDMAD status from the
callback if that is necessary for the driver.

Fixes #4172
---
  .../contrib/libraries/libchip/source/xdmad.c  | 60 ++-
  .../arm/atsam/include/libchip/include/xdmad.h |  4 ++
  2 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/bsps/arm/atsam/contrib/libraries/libchip/source/xdmad.c 
b/bsps/arm/atsam/contrib/libraries/libchip/source/xdmad.c
index 13b227036e..161cf0bee4 100644
--- a/bsps/arm/atsam/contrib/libraries/libchip/source/xdmad.c
+++ b/bsps/arm/atsam/contrib/libraries/libchip/source/xdmad.c
@@ -132,9 +132,66 @@ static uint32_t XDMAD_AllocateXdmacChannel(sXdmad *pXdmad,
return XDMAD_ALLOC_FAILED;
  }
  
+/*

+ * Update the internal xdmad state. Returns true if further processing in the
+ * callback is recommended.
+ *
+ * In an earlier version of the API this has been done by the interrupt handler
+ * directly. But in some cases the application might want to process some of 
the
+ * other interrupts too. Therefore the user callback should now decide itself
+ * whether this is necessary or not.
+ */
+bool XDMAD_UpdateStatusFromCallback(sXdmad *pXdmad,
+   uint32_t Channel,
+   uint32_t status)
+{
+   Xdmac *pXdmac;
+   uint32_t xdmaGlobalChStatus;
+   bool bExec;
+
+   bExec = false;
+   pXdmac = pXdmad->pXdmacs;
+   xdmaGlobalChStatus = XDMAC_GetGlobalChStatus(pXdmac);
+
+   if ((xdmaGlobalChStatus & (XDMAC_GS_ST0 << Channel)) == 0) {
+   uint32_t xdmaChannelIntMask;
+   sXdmadChannel *pCh;
+
+   pCh = >XdmaChannels[Channel];
+
+   xdmaChannelIntMask = XDMAC_GetChannelItMask(pXdmac, Channel);
+   status &= xdmaChannelIntMask;
+
+   if (status & XDMAC_CIS_BIS) {
+   if ((xdmaChannelIntMask & XDMAC_CIM_LIM) == 0) {
+   pCh->state = XDMAD_STATE_DONE;
+   bExec = true;
+   }
+   }
+
+   if (status & XDMAC_CIS_LIS) {
+   pCh->state = XDMAD_STATE_DONE;
+   bExec = true;
+   }
+
+   if (status & XDMAC_CIS_DIS) {
+   pCh->state = XDMAD_STATE_DONE;
+   bExec = true;
+   }
+   } else {
+   /* Block end interrupt for LLI dma mode */
+   if (XDMAC_GetChannelIsr(pXdmac, Channel) & XDMAC_CIS_BIS) {
+   bExec = true;
+   }
+   }
+
+   return bExec;
+}
+
  void XDMAD_DoNothingCallback(uint32_t Channel, void *pArg, uint32_t status)
  {
-   /* Do nothing */
+   /* Do nothing except status update */
+   XDMAD_UpdateStatusFromCallback((sXdmad *)pArg, Channel, status);
  }
  
  /*

@@ -157,6 +214,7 @@ static void XDMAD_SysInitialize(void)
  
  	for (j = 0; j < pXdmad->numChannels; j ++) {

pXdmad->XdmaChannels[j].fCallback = XDMAD_DoNothingCallback;
+   pXdmad->XdmaChannels[j].pArg = (void *)pXdmad;
}
  
  	sc = rtems_interrupt_handler_install(

diff --git a/bsps/arm/atsam/include/libchip/include/xdmad.h 
b/bsps/arm/atsam/include/libchip/include/xdmad.h
index 97e24c880b..cba3d052ab 100644
--- a/bsps/arm/atsam/include/libchip/include/xdmad.h
+++ b/bsps/arm/atsam/include/libchip/include/xdmad.h
@@ -241,6 +241,10 @@ extern eXdmadRC XDMAD_StartTransfer(sXdmad *pXdmad, 
uint32_t dwChannel);
  
  extern void XDMAD_DoNothingCallback(uint32_t Channel, void *pArg, uint32_t status);
  
+extern bool XDMAD_UpdateStatusFromCallback(sXdmad *pXdmad,

+   uint32_t Channel,
+   uint32_t status);
+
  extern eXdmadRC XDMAD_SetCallback(sXdmad *pXdmad,
   uint32_t 
dwChannel,
   
XdmadTransferCallback fCallback,



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

[PATCH] bsp/atsam: Fix XDMAD status

[Christian Mauderer]

In "bsp/atsam: Simplify XDMAD_Handler()" (5f813694f68cee) the interrupt
callback has been made unconditional. That allowed to avoid some special
deadlock situations in error cases. But it removed part of the XDMAD
status handling.

This patch adds the ability to update the XDMAD status from the
callback if that is necessary for the driver.

Fixes #4172
---
 .../contrib/libraries/libchip/source/xdmad.c  | 60 ++-
 .../arm/atsam/include/libchip/include/xdmad.h |  4 ++
 2 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/bsps/arm/atsam/contrib/libraries/libchip/source/xdmad.c 
b/bsps/arm/atsam/contrib/libraries/libchip/source/xdmad.c
index 13b227036e..161cf0bee4 100644
--- a/bsps/arm/atsam/contrib/libraries/libchip/source/xdmad.c
+++ b/bsps/arm/atsam/contrib/libraries/libchip/source/xdmad.c
@@ -132,9 +132,66 @@ static uint32_t XDMAD_AllocateXdmacChannel(sXdmad *pXdmad,
return XDMAD_ALLOC_FAILED;
 }
 
+/*
+ * Update the internal xdmad state. Returns true if further processing in the
+ * callback is recommended.
+ *
+ * In an earlier version of the API this has been done by the interrupt handler
+ * directly. But in some cases the application might want to process some of 
the
+ * other interrupts too. Therefore the user callback should now decide itself
+ * whether this is necessary or not.
+ */
+bool XDMAD_UpdateStatusFromCallback(sXdmad *pXdmad,
+   uint32_t Channel,
+   uint32_t status)
+{
+   Xdmac *pXdmac;
+   uint32_t xdmaGlobalChStatus;
+   bool bExec;
+
+   bExec = false;
+   pXdmac = pXdmad->pXdmacs;
+   xdmaGlobalChStatus = XDMAC_GetGlobalChStatus(pXdmac);
+
+   if ((xdmaGlobalChStatus & (XDMAC_GS_ST0 << Channel)) == 0) {
+   uint32_t xdmaChannelIntMask;
+   sXdmadChannel *pCh;
+
+   pCh = >XdmaChannels[Channel];
+
+   xdmaChannelIntMask = XDMAC_GetChannelItMask(pXdmac, Channel);
+   status &= xdmaChannelIntMask;
+
+   if (status & XDMAC_CIS_BIS) {
+   if ((xdmaChannelIntMask & XDMAC_CIM_LIM) == 0) {
+   pCh->state = XDMAD_STATE_DONE;
+   bExec = true;
+   }
+   }
+
+   if (status & XDMAC_CIS_LIS) {
+   pCh->state = XDMAD_STATE_DONE;
+   bExec = true;
+   }
+
+   if (status & XDMAC_CIS_DIS) {
+   pCh->state = XDMAD_STATE_DONE;
+   bExec = true;
+   }
+   } else {
+   /* Block end interrupt for LLI dma mode */
+   if (XDMAC_GetChannelIsr(pXdmac, Channel) & XDMAC_CIS_BIS) {
+   bExec = true;
+   }
+   }
+
+   return bExec;
+}
+
 void XDMAD_DoNothingCallback(uint32_t Channel, void *pArg, uint32_t status)
 {
-   /* Do nothing */
+   /* Do nothing except status update */
+   XDMAD_UpdateStatusFromCallback((sXdmad *)pArg, Channel, status);
 }
 
 /*
@@ -157,6 +214,7 @@ static void XDMAD_SysInitialize(void)
 
for (j = 0; j < pXdmad->numChannels; j ++) {
pXdmad->XdmaChannels[j].fCallback = XDMAD_DoNothingCallback;
+   pXdmad->XdmaChannels[j].pArg = (void *)pXdmad;
}
 
sc = rtems_interrupt_handler_install(
diff --git a/bsps/arm/atsam/include/libchip/include/xdmad.h 
b/bsps/arm/atsam/include/libchip/include/xdmad.h
index 97e24c880b..cba3d052ab 100644
--- a/bsps/arm/atsam/include/libchip/include/xdmad.h
+++ b/bsps/arm/atsam/include/libchip/include/xdmad.h
@@ -241,6 +241,10 @@ extern eXdmadRC XDMAD_StartTransfer(sXdmad *pXdmad, 
uint32_t dwChannel);
 
 extern void XDMAD_DoNothingCallback(uint32_t Channel, void *pArg, uint32_t 
status);
 
+extern bool XDMAD_UpdateStatusFromCallback(sXdmad *pXdmad,
+   uint32_t Channel,
+   uint32_t status);
+
 extern eXdmadRC XDMAD_SetCallback(sXdmad *pXdmad,
   uint32_t 
dwChannel,
   
XdmadTransferCallback fCallback,
-- 
2.26.2

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

Re: [PATCH rtems 8/8] jffs2: Replace non-ASCII copyright character

[Christian Mauderer]

On 09/11/2020 07:58, Sebastian Huber wrote:

On 07/11/2020 14:23, Christian Mauderer wrote:

diff --git a/cpukit/libfs/src/jffs2/include/linux/jffs2.h 
b/cpukit/libfs/src/jffs2/include/linux/jffs2.h

index a18b719f49..202cb46b8d 100644
--- a/cpukit/libfs/src/jffs2/include/linux/jffs2.h
+++ b/cpukit/libfs/src/jffs2/include/linux/jffs2.h
@@ -1,8 +1,8 @@
  /*
   * JFFS2 -- Journalling Flash File System, Version 2.
   *
- * Copyright © 2001-2007 Red Hat, Inc.
- * Copyright © 2004-2010 David Woodhouse
+ * Copyright (c) 2001-2007 Red Hat, Inc.
+ * Copyright (c) 2004-2010 David Woodhouse

This code is imported from Linux. Do we really have to change this?



Hello Sebastian,

like already stated in the introduction mail: I'm not really sure about 
this one and about patch 6 and 7 myself because they touch imported 
code. So no problem if we don't add the last three ones.


Best regards

Christian

--

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

[PATCH rtems 7/8] bsp/atsam: Replace non-ASCII characters

[Christian Mauderer]

From: Christian Mauderer 

Note that this replacement is pure guess. It has been done using a
unicode converter tool that spit out the pTq. That is most likely a math
notation for some vector operation.
---
 bsps/arm/atsam/contrib/libraries/libchip/source/aes.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/arm/atsam/contrib/libraries/libchip/source/aes.c 
b/bsps/arm/atsam/contrib/libraries/libchip/source/aes.c
index 010e7cf8d1..27f543218f 100644
--- a/bsps/arm/atsam/contrib/libraries/libchip/source/aes.c
+++ b/bsps/arm/atsam/contrib/libraries/libchip/source/aes.c
@@ -249,7 +249,7 @@ void AES_SetGcmHash(uint32_t *hash)
 
 /**
  * \brief Get The four 32-bit Tag which contain the final 128-bit GCM
- * Authentication tag ��T�� when GCM processing is complete.
+ * Authentication tag pTq when GCM processing is complete.
  * \param tag point to the word of the tag.
  */
 void AES_GetGcmTag(uint32_t *tag)
-- 
2.29.2

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

[PATCH rtems 6/8] bsp/atsam: Remove non-ASCII chars for microseconds

[Christian Mauderer]

From: Christian Mauderer 

---
 .../contrib/libraries/libboard/source/board_memories.c | 10 ++
 .../atsam/contrib/libraries/libchip/source/sdramc.c|  4 ++--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/bsps/arm/atsam/contrib/libraries/libboard/source/board_memories.c 
b/bsps/arm/atsam/contrib/libraries/libboard/source/board_memories.c
index e2f04caa8c..354196ab95 100644
--- a/bsps/arm/atsam/contrib/libraries/libboard/source/board_memories.c
+++ b/bsps/arm/atsam/contrib/libraries/libboard/source/board_memories.c
@@ -196,7 +196,8 @@ void BOARD_ConfigureSdram(void)
SDRAMC->SDRAMC_MDR = BOARD_Sdram_Config.sdramc_mdr;
 #endif /* __rtems__ */
 
-   /* 4. A minimum pause of 200 ��s is provided to precede any signal 
toggle.*/
+   /* 4. A minimum pause of 200 microseconds is provided to precede any
+   signal toggle.*/
for (i = 0; i < 10; i++);
 
/* 5. (1)A NOP command is issued to the SDRAM devices. The application 
must
@@ -277,10 +278,11 @@ void BOARD_ConfigureSdram(void)
 
/* 11. Write the refresh rate into the count field in the SDRAMC Refresh
Timer register. (Refresh rate = delay between refresh cycles).
-   The SDRAM device requires a refresh every 15.625 ��s or 7.81 ��s.
+   The SDRAM device requires a refresh every 15.625 or 7.81 microseconds.
With a 100 MHz frequency, the Refresh Timer Counter Register must be set
-   with the value 1562(15.625 ��s x 100 MHz) or 781(7.81 ��s x 100 MHz). */
-   // For IS42S16100E, 2048 refresh cycle every 32ms, every 15.625 ��s
+   with the value 1562(15.625 us x 100 MHz) or 781(7.81 us x 100 MHz). */
+   /* For IS42S16100E, 2048 refresh cycle every 32ms, every 15.625
+   microseconds. */
/* ((32 x 10(^-3))/2048) x150 x (10^6) */
 #ifndef __rtems__
SDRAMC->SDRAMC_TR = 1562;
diff --git a/bsps/arm/atsam/contrib/libraries/libchip/source/sdramc.c 
b/bsps/arm/atsam/contrib/libraries/libchip/source/sdramc.c
index ab5f2d8ec8..aca4a4448e 100644
--- a/bsps/arm/atsam/contrib/libraries/libchip/source/sdramc.c
+++ b/bsps/arm/atsam/contrib/libraries/libchip/source/sdramc.c
@@ -128,8 +128,8 @@ extern void SDRAMC_Configure(SSdramc_Memory *pMemory,
SDRAMC->SDRAMC_MDR = SDRAMC_MDR_MD_SDRAM;
 
/* Step 4 */
-   /* A minimum pause of 200 ��s is provided to precede any signal toggle.
-  (6 core cycles per iteration) */
+   /* A minimum pause of 200 microseconds is provided to precede any signal
+  toggle. (6 core cycles per iteration) */
for (dw = 0; dw < ((dwClockFrequency / 100) * 200 / 6); dw++);
 
/* Step 5. */
-- 
2.29.2

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

[PATCH rtems 3/8] bsps: Replace non-ASCII bullet points

[Christian Mauderer]

From: Christian Mauderer 

---
 bsps/shared/grlib/can/occan.c | 4 ++--
 bsps/shared/grlib/spw/grspw.c | 8 
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/bsps/shared/grlib/can/occan.c b/bsps/shared/grlib/can/occan.c
index 59b4f234f6..84402b8809 100644
--- a/bsps/shared/grlib/can/occan.c
+++ b/bsps/shared/grlib/can/occan.c
@@ -855,8 +855,8 @@ static int pelican_start(occan_priv *priv){
 #endif
 
/* core already in reset mode,
-*  � Exit reset mode 
-*  � Enter Single/Dual mode filtering.
+*  * Exit reset mode
+*  * Enter Single/Dual mode filtering.
 */
WRITE_REG(priv, >regs->mode, (priv->single_mode << 3));
 
diff --git a/bsps/shared/grlib/spw/grspw.c b/bsps/shared/grlib/spw/grspw.c
index 2e1e8e90e9..1b50cc642f 100644
--- a/bsps/shared/grlib/spw/grspw.c
+++ b/bsps/shared/grlib/spw/grspw.c
@@ -1475,10 +1475,10 @@ static rtems_device_driver grspw_control(
 
/* Get timeout from userspace
 *  timeout:
-*   �  -1 = Default timeout
-*   �  less than -1 = forever
-*   �  0   = no wait, proceed if link is up
-*   �  positive = specifies number of system clock 
ticks that 
+*   *  -1 = Default timeout
+*   *  less than -1 = forever
+*   *  0   = no wait, proceed if link is up
+*   *  positive = specifies number of system clock 
ticks that
 *   startup will wait for link to 
enter ready mode.
 */
timeout = (int)ioarg->buffer;
-- 
2.29.2

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

[PATCH rtems 2/8] bsps: Replace non-ASCII trademark symbol

[Christian Mauderer]

From: Christian Mauderer 

---
 bsps/arm/atsam/contrib/libraries/libboard/include/gmii.h | 2 +-
 bsps/arm/lm3s69xx/start/bspstart.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/bsps/arm/atsam/contrib/libraries/libboard/include/gmii.h 
b/bsps/arm/atsam/contrib/libraries/libboard/include/gmii.h
index e346143452..e9dc31e1e4 100644
--- a/bsps/arm/atsam/contrib/libraries/libboard/include/gmii.h
+++ b/bsps/arm/atsam/contrib/libraries/libboard/include/gmii.h
@@ -52,7 +52,7 @@
 #define GMII_ECR 0x18  // Expanded Control Register
 #define GMII_ICSR0x1B  // Interrupt Control/Status Register
 #define GMII_FC  0x1C  // Function Control
-#define GMII_LCSR0x1D  // LinkMD� Control/Status Register
+#define GMII_LCSR0x1D  // LinkMD(R) Control/Status Register
 #define GMII_PC1R0x1E  // PHY Control 1 Register
 #define GMII_PC2R0x1F  // PHY Control 2 Register
 
diff --git a/bsps/arm/lm3s69xx/start/bspstart.c 
b/bsps/arm/lm3s69xx/start/bspstart.c
index ea73b1e1c2..43b7b826bf 100644
--- a/bsps/arm/lm3s69xx/start/bspstart.c
+++ b/bsps/arm/lm3s69xx/start/bspstart.c
@@ -39,7 +39,7 @@ static void init_main_osc(void)
   syscon->rcc2 = rcc2;
 
   /*
-   As per a note in Stellaris� LM4F120H5QR Microcontroller Data
+   As per a note in Stellaris(R) LM4F120H5QR Microcontroller Data
Sheet on page 219: "When transitioning the system clock
configuration to use the MOSC as the fundamental clock source, the
MOSCDIS bit must be set prior to reselecting the MOSC or an
-- 
2.29.2

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

[PATCH rtems 0/8] Replace non ASCII-Characters in source files

[Christian Mauderer]

Hello,

this patch set is a follow up of the discussion in this mail thread:

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

It replaces a lot of non-ASCII characters that slipped into our code
base over the years. Note that I'm not sure whether the last three
patches are a good idea. They touch imported code and especially the
jffs2 stuff might get updated from upstream sources. So maybe keeping
the non-ASCII stuff there might is a better choice.

Best regards

Christian


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

[PATCH rtems 4/8] bsp/mpc83xx: Fix non-ASCII characters

[Christian Mauderer]

From: Christian Mauderer 

---
 bsps/powerpc/include/mpc83xx/mpc83xx.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/powerpc/include/mpc83xx/mpc83xx.h 
b/bsps/powerpc/include/mpc83xx/mpc83xx.h
index f48a5ce675..9613abd365 100644
--- a/bsps/powerpc/include/mpc83xx/mpc83xx.h
+++ b/bsps/powerpc/include/mpc83xx/mpc83xx.h
@@ -668,7 +668,7 @@ typedef struct m83xxUSB_DRRegisters_ {
   volatile uint32_t cdpr1; /* 0x3_1140 Crypto-channel 1 current descriptor 
pointer register R 0x___ 14.6.1.3/14-90 */
   volatile uint32_t */
 0x3_1180--0x3_11BF
-  DBn /*   volatile; uint32_t ff1, */ /* 0x3_1148 Crypto-channel 1 fetch FIFO 
address register W 0x___ 14.6.1.4/14-90 Crypto-channel 1 
descriptor buffers [0�7] R 0x___ 14.6.1.5/14-91 */
+  DBn /*   volatile; uint32_t ff1, */ /* 0x3_1148 Crypto-channel 1 fetch FIFO 
address register W 0x___ 14.6.1.4/14-90 Crypto-channel 1 
descriptor buffers [0..7] R 0x___ 14.6.1.5/14-91 */
   /* Channel 2-4: FIXME: same layout as channel 1*/
   /* Data Encryption Standard Execution Unit (DEU) */
   volatile uint32_t deumr; /* 0x3_2000 DEU mode register R/W 
0x___ 14.5.2.1/14-35 */
-- 
2.29.2

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

[PATCH rtems 1/8] bsps: Replace non-ASCII copyright character

[Christian Mauderer]

From: Christian Mauderer 

---
 bsps/arm/lm3s69xx/console/console-config.c | 2 +-
 bsps/arm/lm3s69xx/console/uart.c   | 2 +-
 bsps/arm/lm3s69xx/i2c/ssi.c| 2 +-
 bsps/arm/lm3s69xx/include/bsp/io.h | 2 +-
 bsps/arm/lm3s69xx/include/bsp/irq.h| 2 +-
 bsps/arm/lm3s69xx/include/bsp/lm3s69xx.h   | 2 +-
 bsps/arm/lm3s69xx/include/bsp/ssi.h| 2 +-
 bsps/arm/lm3s69xx/include/bsp/syscon.h | 2 +-
 bsps/arm/lm3s69xx/start/bspstart.c | 2 +-
 bsps/arm/lm3s69xx/start/io.c   | 2 +-
 bsps/arm/lm3s69xx/start/syscon.c   | 2 +-
 11 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/bsps/arm/lm3s69xx/console/console-config.c 
b/bsps/arm/lm3s69xx/console/console-config.c
index b702f0cd66..bce7a624aa 100644
--- a/bsps/arm/lm3s69xx/console/console-config.c
+++ b/bsps/arm/lm3s69xx/console/console-config.c
@@ -1,5 +1,5 @@
 /*
- * Copyright � 2013 Eugeniy Meshcheryakov 
+ * Copyright (c) 2013 Eugeniy Meshcheryakov 
  *
  * Copyright (c) 2011 Sebastian Huber.  All rights reserved.
  *
diff --git a/bsps/arm/lm3s69xx/console/uart.c b/bsps/arm/lm3s69xx/console/uart.c
index 67a85f4e96..f9e55dd362 100644
--- a/bsps/arm/lm3s69xx/console/uart.c
+++ b/bsps/arm/lm3s69xx/console/uart.c
@@ -1,5 +1,5 @@
 /*
- * Copyright � 2013 Eugeniy Meshcheryakov 
+ * Copyright (c) 2013 Eugeniy Meshcheryakov 
  *
  * Copyright (c) 2011 Sebastian Huber.  All rights reserved.
  *
diff --git a/bsps/arm/lm3s69xx/i2c/ssi.c b/bsps/arm/lm3s69xx/i2c/ssi.c
index 9469c611f0..3b4e8fca9c 100644
--- a/bsps/arm/lm3s69xx/i2c/ssi.c
+++ b/bsps/arm/lm3s69xx/i2c/ssi.c
@@ -1,5 +1,5 @@
 /*
- * Copyright � 2013 Eugeniy Meshcheryakov 
+ * Copyright (c) 2013 Eugeniy Meshcheryakov 
  *
  * The license and distribution terms for this file may be
  * found in the file LICENSE in this distribution or at
diff --git a/bsps/arm/lm3s69xx/include/bsp/io.h 
b/bsps/arm/lm3s69xx/include/bsp/io.h
index 3e3846e1c6..6dea463a56 100644
--- a/bsps/arm/lm3s69xx/include/bsp/io.h
+++ b/bsps/arm/lm3s69xx/include/bsp/io.h
@@ -7,7 +7,7 @@
  */
 
 /*
- * Copyright � 2013 Eugeniy Meshcheryakov 
+ * Copyright (c) 2013 Eugeniy Meshcheryakov 
  *
  * The license and distribution terms for this file may be
  * found in the file LICENSE in this distribution or at
diff --git a/bsps/arm/lm3s69xx/include/bsp/irq.h 
b/bsps/arm/lm3s69xx/include/bsp/irq.h
index dd49728881..ca7a462f7f 100644
--- a/bsps/arm/lm3s69xx/include/bsp/irq.h
+++ b/bsps/arm/lm3s69xx/include/bsp/irq.h
@@ -7,7 +7,7 @@
  */
 
 /*
- * Copyright � 2013 Eugeniy Meshcheryakov 
+ * Copyright (c) 2013 Eugeniy Meshcheryakov 
  *
  * Copyright (c) 2011 Sebastian Huber.  All rights reserved.
  *
diff --git a/bsps/arm/lm3s69xx/include/bsp/lm3s69xx.h 
b/bsps/arm/lm3s69xx/include/bsp/lm3s69xx.h
index 623b6ca45e..0a4a80760d 100644
--- a/bsps/arm/lm3s69xx/include/bsp/lm3s69xx.h
+++ b/bsps/arm/lm3s69xx/include/bsp/lm3s69xx.h
@@ -7,7 +7,7 @@
  */
 
 /*
- * Copyright � 2013 Eugeniy Meshcheryakov 
+ * Copyright (c) 2013 Eugeniy Meshcheryakov 
  *
  * Copyright (c) 2011 Sebastian Huber.  All rights reserved.
  *
diff --git a/bsps/arm/lm3s69xx/include/bsp/ssi.h 
b/bsps/arm/lm3s69xx/include/bsp/ssi.h
index 66d5302655..7463a19825 100644
--- a/bsps/arm/lm3s69xx/include/bsp/ssi.h
+++ b/bsps/arm/lm3s69xx/include/bsp/ssi.h
@@ -7,7 +7,7 @@
  */
 
 /*
- * Copyright � 2013 Eugeniy Meshcheryakov 
+ * Copyright (c) 2013 Eugeniy Meshcheryakov 
  *
  * The license and distribution terms for this file may be
  * found in the file LICENSE in this distribution or at
diff --git a/bsps/arm/lm3s69xx/include/bsp/syscon.h 
b/bsps/arm/lm3s69xx/include/bsp/syscon.h
index 2904138f4d..67ff69c50e 100644
--- a/bsps/arm/lm3s69xx/include/bsp/syscon.h
+++ b/bsps/arm/lm3s69xx/include/bsp/syscon.h
@@ -7,7 +7,7 @@
  */
 
 /*
- * Copyright � 2013 Eugeniy Meshcheryakov 
+ * Copyright (c) 2013 Eugeniy Meshcheryakov 
  *
  * The license and distribution terms for this file may be
  * found in the file LICENSE in this distribution or at
diff --git a/bsps/arm/lm3s69xx/start/bspstart.c 
b/bsps/arm/lm3s69xx/start/bspstart.c
index da3029e58c..ea73b1e1c2 100644
--- a/bsps/arm/lm3s69xx/start/bspstart.c
+++ b/bsps/arm/lm3s69xx/start/bspstart.c
@@ -3,7 +3,7 @@
  */
 
 /*
- * Copyright � 2013 Eugeniy Meshcheryakov 
+ * Copyright (c) 2013 Eugeniy Meshcheryakov 
  *
  * The license and distribution terms for this file may be
  * found in the file LICENSE in this distribution or at
diff --git a/bsps/arm/lm3s69xx/start/io.c b/bsps/arm/lm3s69xx/start/io.c
index b476e7b6dd..0f41f137dd 100644
--- a/bsps/arm/lm3s69xx/start/io.c
+++ b/bsps/arm/lm3s69xx/start/io.c
@@ -1,5 +1,5 @@
 /*
- * Copyright � 2013 Eugeniy Meshcheryakov 
+ * Copyright (c) 2013 Eugeniy Meshcheryakov 
  *
  * The license and distribution terms for this file may be
  * found in the file LICENSE in this distribution or at
diff --git a/bsps/arm/lm3s69xx/start/syscon.c b/bsps/arm/lm3s69xx/start/syscon.c
index 1f5a1a3596..60064c3102 100644
--- a/bsps/arm/lm3s69xx/start

[PATCH rtems 8/8] jffs2: Replace non-ASCII copyright character

[Christian Mauderer]

From: Christian Mauderer 

---
 cpukit/libfs/src/jffs2/include/linux/jffs2.h | 4 ++--
 cpukit/libfs/src/jffs2/src/acl.h | 2 +-
 cpukit/libfs/src/jffs2/src/build.c   | 4 ++--
 cpukit/libfs/src/jffs2/src/compr.c   | 8 
 cpukit/libfs/src/jffs2/src/compr.h   | 4 ++--
 cpukit/libfs/src/jffs2/src/compr_rtime.c | 4 ++--
 cpukit/libfs/src/jffs2/src/compr_rubin.c | 4 ++--
 cpukit/libfs/src/jffs2/src/compr_zlib.c  | 4 ++--
 cpukit/libfs/src/jffs2/src/debug.c   | 4 ++--
 cpukit/libfs/src/jffs2/src/debug.h   | 4 ++--
 cpukit/libfs/src/jffs2/src/dir-rtems.c   | 8 
 cpukit/libfs/src/jffs2/src/erase.c   | 4 ++--
 cpukit/libfs/src/jffs2/src/fs-rtems.c| 8 
 cpukit/libfs/src/jffs2/src/gc.c  | 4 ++--
 cpukit/libfs/src/jffs2/src/jffs2_fs_i.h  | 4 ++--
 cpukit/libfs/src/jffs2/src/jffs2_fs_sb.h | 4 ++--
 cpukit/libfs/src/jffs2/src/nodelist.c| 2 +-
 cpukit/libfs/src/jffs2/src/nodelist.h| 2 +-
 cpukit/libfs/src/jffs2/src/nodemgmt.c| 2 +-
 cpukit/libfs/src/jffs2/src/os-rtems.h| 4 ++--
 cpukit/libfs/src/jffs2/src/read.c| 2 +-
 cpukit/libfs/src/jffs2/src/readinode.c   | 2 +-
 cpukit/libfs/src/jffs2/src/scan.c| 2 +-
 cpukit/libfs/src/jffs2/src/summary.h | 2 +-
 cpukit/libfs/src/jffs2/src/write.c   | 2 +-
 cpukit/libfs/src/jffs2/src/xattr.h   | 2 +-
 26 files changed, 48 insertions(+), 48 deletions(-)

diff --git a/cpukit/libfs/src/jffs2/include/linux/jffs2.h 
b/cpukit/libfs/src/jffs2/include/linux/jffs2.h
index a18b719f49..202cb46b8d 100644
--- a/cpukit/libfs/src/jffs2/include/linux/jffs2.h
+++ b/cpukit/libfs/src/jffs2/include/linux/jffs2.h
@@ -1,8 +1,8 @@
 /*
  * JFFS2 -- Journalling Flash File System, Version 2.
  *
- * Copyright © 2001-2007 Red Hat, Inc.
- * Copyright © 2004-2010 David Woodhouse 
+ * Copyright (c) 2001-2007 Red Hat, Inc.
+ * Copyright (c) 2004-2010 David Woodhouse 
  *
  * Created by David Woodhouse 
  *
diff --git a/cpukit/libfs/src/jffs2/src/acl.h b/cpukit/libfs/src/jffs2/src/acl.h
index 2e2b5745c3..1114691c70 100644
--- a/cpukit/libfs/src/jffs2/src/acl.h
+++ b/cpukit/libfs/src/jffs2/src/acl.h
@@ -1,7 +1,7 @@
 /*
  * JFFS2 -- Journalling Flash File System, Version 2.
  *
- * Copyright © 2006  NEC Corporation
+ * Copyright (c) 2006  NEC Corporation
  *
  * Created by KaiGai Kohei 
  *
diff --git a/cpukit/libfs/src/jffs2/src/build.c 
b/cpukit/libfs/src/jffs2/src/build.c
index d35bc83bbb..ce9e258404 100644
--- a/cpukit/libfs/src/jffs2/src/build.c
+++ b/cpukit/libfs/src/jffs2/src/build.c
@@ -3,8 +3,8 @@
 /*
  * JFFS2 -- Journalling Flash File System, Version 2.
  *
- * Copyright © 2001-2007 Red Hat, Inc.
- * Copyright © 2004-2010 David Woodhouse 
+ * Copyright (c) 2001-2007 Red Hat, Inc.
+ * Copyright (c) 2004-2010 David Woodhouse 
  *
  * Created by David Woodhouse 
  *
diff --git a/cpukit/libfs/src/jffs2/src/compr.c 
b/cpukit/libfs/src/jffs2/src/compr.c
index a9e821a6a1..e9d5667116 100644
--- a/cpukit/libfs/src/jffs2/src/compr.c
+++ b/cpukit/libfs/src/jffs2/src/compr.c
@@ -3,11 +3,11 @@
 /*
  * JFFS2 -- Journalling Flash File System, Version 2.
  *
- * Copyright © 2001-2007 Red Hat, Inc.
- * Copyright © 2004-2010 David Woodhouse 
- * Copyright © 2004 Ferenc Havasi ,
+ * Copyright (c) 2001-2007 Red Hat, Inc.
+ * Copyright (c) 2004-2010 David Woodhouse 
+ * Copyright (c) 2004 Ferenc Havasi ,
  * University of Szeged, Hungary
- * Copyright © 2013 embedded brains GmbH 
+ * Copyright (c) 2013 embedded brains GmbH 
  *
  * Created by Arjan van de Ven 
  *
diff --git a/cpukit/libfs/src/jffs2/src/compr.h 
b/cpukit/libfs/src/jffs2/src/compr.h
index e6226e7258..cdf2c5c85a 100644
--- a/cpukit/libfs/src/jffs2/src/compr.h
+++ b/cpukit/libfs/src/jffs2/src/compr.h
@@ -1,9 +1,9 @@
 /*
  * JFFS2 -- Journalling Flash File System, Version 2.
  *
- * Copyright © 2004   Ferenc Havasi ,
+ * Copyright (c) 2004   Ferenc Havasi ,
  *   University of Szeged, Hungary
- * Copyright © 2004-2010 David Woodhouse 
+ * Copyright (c) 2004-2010 David Woodhouse 
  *
  * For licensing information, see the file 'LICENCE' in this directory.
  *
diff --git a/cpukit/libfs/src/jffs2/src/compr_rtime.c 
b/cpukit/libfs/src/jffs2/src/compr_rtime.c
index c8313ed234..c434c0b74f 100644
--- a/cpukit/libfs/src/jffs2/src/compr_rtime.c
+++ b/cpukit/libfs/src/jffs2/src/compr_rtime.c
@@ -3,8 +3,8 @@
 /*
  * JFFS2 -- Journalling Flash File System, Version 2.
  *
- * Copyright © 2001-2007 Red Hat, Inc.
- * Copyright © 2004-2010 David Woodhouse 
+ * Copyright (c) 2001-2007 Red Hat, Inc.
+ * Copyright (c) 2004-2010 David Woodhouse 
  *
  * Created by Arjan van de Ven 
  *
diff --git a/cpukit/libfs/src/jffs2/src/compr_rubin.c 
b/cpukit/libfs/src/jffs2/src/compr_rubin.c
index 91a1f354f5..d47f293eaa 100644
--- a/cpukit/libfs/src/jffs2/src/compr_rubin.c
+++ b/cpukit/libfs/src/jffs2/src/compr_rubin.c
@@ -3,8 +3,8 @@
 /*
  * JFFS2

Re: [PATCH rtems 0/8] Replace non ASCII-Characters in source files

[Christian Mauderer]

PS: In case the patches make problems due to some odd mail encoding: I
also pushed them as a branch here:

https://gitlab.com/c-mauderer/rtems/-/tree/cm/20201107_replace_non-ASCII


On 07/11/2020 14:23, Christian Mauderer wrote:
> Hello,
> 
> this patch set is a follow up of the discussion in this mail thread:
> 
> https://lists.rtems.org/pipermail/devel/2020-November/063092.html
> 
> It replaces a lot of non-ASCII characters that slipped into our code
> base over the years. Note that I'm not sure whether the last three
> patches are a good idea. They touch imported code and especially the
> jffs2 stuff might get updated from upstream sources. So maybe keeping
> the non-ASCII stuff there might is a better choice.
> 
> Best regards
> 
> Christian
> 
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems 5/8] bsp/rtl22xx: Fix non-ASCII character

[Christian Mauderer]

From: Christian Mauderer 

---
 bsps/arm/rtl22xx/console/uart.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/arm/rtl22xx/console/uart.c b/bsps/arm/rtl22xx/console/uart.c
index 2952e74508..c4ddd18b2c 100644
--- a/bsps/arm/rtl22xx/console/uart.c
+++ b/bsps/arm/rtl22xx/console/uart.c
@@ -262,7 +262,7 @@ static int _BSP_get_char(void)
 BSP_polling_getchar_function_type BSP_poll_char = _BSP_get_char;
 
 /*
- * init USART 0��8 bit, 1 Stop,No checkout, BPS115200
+ * init USART 0: 8 bit, 1 Stop,No checkout, BPS115200
  */
 void UART0_Ini(void)
 {
-- 
2.29.2

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

[PATCH] if_ffec: Fix cache handling on tx.

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

Re: 80 or 79 characters limit?

[Christian Mauderer]

On 05/11/2020 21:28, Gedare Bloom wrote:
> On Thu, Nov 5, 2020 at 1:14 PM Joel Sherrill  wrote:
>>
>> I tried at one point to figure out how to script the changes when I ran into 
>> them.
>> But it was easier to fix them by hand. If you have a simple script, it would 
>> be good
>> to have a home for it. We could grow it then.

Sorry, I didn't use a script either. I just wanted to try a tool on a
larger code base and blindly removed everything that has been a problem
for it.

>>
>> Not accepting unicode should be checked for patches and should be in
>> Coding Conventions.
>>
>> I think you made a couple of bad mapping choices.

See above: The target was not to have a good choice but just to get rid
of them. Never intended to create a real patch from it. But like I said:
I'll polish it a bit and send patches.

>>
>> - "(r)" for the registered symbol (circle R)
>> -  "u" for the micro Greek letter in usec and us (which is strange for usec)

For me "s" is a quite common short for seconds. And u is quite common
for replacing a micro if there is no special micro character. Most
likely in English there is a higher chance to mis-read it as an "us"
like the one in "tell us something" and therefore the short form is
considered strange ;-)

>>
>> Some I have no idea about.
>>
>> + aes.c - absolutely no idea
>> + rtl22xx/console/uart.c - maybe an x
>> + powerpc/include/mpc83xx/mpc83xx.h - maybe an x
>>
>> I think a patch series doing copyright symbols, (r), and u for micro
>> as individual changes would eliminate a lot and not be controversial.
>> That should leave the remaining for a second pass.
>>
>> One patch per character change is safer to review.
> "per kind of character"
> 
> feel free to send all the (C) together, etc.

OK.

> 
> I think the AES one is pTq, math notation for a vector product using 
> transpose.
> 
> I used https://www.branah.com/unicode-converter and put the UTF-8 we
> have in our repo in the box, and that gives some idea what it should
> be in the top unicode box. i.e., put "¡°T¡±" in the UTF-8 box and see
> what pops out on top

That's a nice tool. Thanks for the hint.

Best regards

Christian

> 
>>
>> --joel
>>
>>
>> On Thu, Nov 5, 2020 at 1:34 PM Christian Mauderer  wrote:
>>>
>>> Hello Joel,
>>>
>>> On 05/11/2020 20:15, Joel Sherrill wrote:
>>>>
>>>>
>>>> On Thu, Nov 5, 2020, 1:12 PM Christian Mauderer >>> <mailto:o...@c-mauderer.de>> wrote:
>>>>
>>>> Hello Joel and Sebastian,
>>>>
>>>> On 05/11/2020 16:44, Joel Sherrill wrote:
>>>> >
>>>> >
>>>> > On Thu, Nov 5, 2020, 9:26 AM Sebastian Huber
>>>> > >>> <mailto:sebastian.hu...@embedded-brains.de>
>>>> > <mailto:sebastian.hu...@embedded-brains.de
>>>> <mailto:sebastian.hu...@embedded-brains.de>>> wrote:
>>>> >
>>>> > Hello,
>>>> >
>>>> > I review currently the Coding Conventions. Should the 80
>>>> characters
>>>> > limit be really a 79 characters limit with the \n as the
>>>> invisible 80th
>>>> > character?
>>>> >
>>>> >
>>>> > Yes.
>>>> >
>>>> > As old as this makes me feel, I remember printers which did an
>>>> automatic
>>>> > linefeed and then the newline one if you hit column 80. So it
>>>> really is
>>>> > 79 unfortunately.
>>>>
>>>> I don't think printers with an automatic linefeed are a common use case
>>>> for reading the RTEMS source code nowadays. So that maybe isn't the 
>>>> best
>>>> reason for using 79 characters.
>>>>
>>>>
>>>> +1
>>>>
>>>>
>>>> I would suggest to use the same convention that most coding styles use
>>>> which seems to be 80 characters:
>>>>
>>>>   https://en.wikipedia.org/wiki/Characters_per_line#In_programming
>>>>
>>>> At least if there are no more recent examples for tools or editors 
>>>> where
>>>> 79 is a benefit. 80 seems just feels a bit more natural.
>>>>
>>>>
>>>> By the way: If we count '

Re: 80 or 79 characters limit?

[Christian Mauderer]

Hello Joel,

On 05/11/2020 20:15, Joel Sherrill wrote:
> 
> 
> On Thu, Nov 5, 2020, 1:12 PM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> Hello Joel and Sebastian,
> 
> On 05/11/2020 16:44, Joel Sherrill wrote:
> >
> >
> > On Thu, Nov 5, 2020, 9:26 AM Sebastian Huber
> >  <mailto:sebastian.hu...@embedded-brains.de>
> > <mailto:sebastian.hu...@embedded-brains.de
> <mailto:sebastian.hu...@embedded-brains.de>>> wrote:
> >
> >     Hello,
> >
> >     I review currently the Coding Conventions. Should the 80
> characters
> >     limit be really a 79 characters limit with the \n as the
> invisible 80th
> >     character?
> >
> >
> > Yes. 
> >
> > As old as this makes me feel, I remember printers which did an
> automatic
> > linefeed and then the newline one if you hit column 80. So it
> really is
> > 79 unfortunately.
> 
> I don't think printers with an automatic linefeed are a common use case
> for reading the RTEMS source code nowadays. So that maybe isn't the best
> reason for using 79 characters.
> 
> 
> +1
> 
> 
> I would suggest to use the same convention that most coding styles use
> which seems to be 80 characters:
> 
>   https://en.wikipedia.org/wiki/Characters_per_line#In_programming
> 
> At least if there are no more recent examples for tools or editors where
> 79 is a benefit. 80 seems just feels a bit more natural.
> 
> 
> By the way: If we count '\n': Should we count a tab '\t' as a single
> character, as 2, as 4 or as 8 ones?
> 
> 
> We shouldn't have tabs in code we own.

Good point.

> 
> What about the few Unicode
> characters that slipped in over the years?
> 
> 
> We also shouldn't have unicode characters randomly floating around. They
> tend to pop up in my experience when people copy from word processors
> and get fancy quotes. Those cases should be eliminated

Last time I stumbled across a tool that didn't like unicode characters I
found about 75 lines in RTEMS with unicode characters. I have been to
lazy to fix them back then. Mostly because some of them would have
needed some thought about what there should have been (I assume it has
been a microsecond in some cases, but still not sure). Attached you can
find a patch that should replaces most of them without much thought
about the content. If you think it's useful, I can polish it up a bit.

Best regards

Christian

> 
> 
> Best regards
> 
> Christian
> 
> >
> >
> >     --
> >     embedded brains GmbH
> >     Sebastian HUBER
> >     Dornierstr. 4
> >     82178 Puchheim
> >     Germany
> >     email: sebastian.hu...@embedded-brains.de
> <mailto:sebastian.hu...@embedded-brains.de>
> >     <mailto:sebastian.hu...@embedded-brains.de
> <mailto: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 <mailto:devel@rtems.org>
> <mailto:devel@rtems.org <mailto:devel@rtems.org>>
> >     http://lists.rtems.org/mailman/listinfo/devel
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org <mailto:devel@rtems.org>
> > http://lists.rtems.org/mailman/listinfo/devel
> >
> 
>From 0c216e723e10acbf1f4c9f28044e19ff408d8fab Mon Sep 17 00:00:00 2001
From: Christian Mauderer 
Date: Thu, 1 Oct 2020 23:15:33 +0200
Subject: [PATCH] Remove special chars.

---
 bsps/arm/atsam/contrib/libraries/libboard/include/gmii.h  | 2 +-
 .../contrib/libraries/libboard/source/board_memories.c| 8 
 bsps/arm/atsam/contrib/libraries/libchip/source/aes.c | 2 +-
 bsps/arm/atsam/contrib/libraries/libchip/source/sdramc.c  | 2 +-
 bsps/arm/lm3s69xx/console/console-config.c| 2 +-
 bsps/arm/lm3s69xx/console/uart.c  | 2 +-
 bsps/arm/lm3s69x

Re: 80 or 79 characters limit?

[Christian Mauderer]

Hello Joel and Sebastian,

On 05/11/2020 16:44, Joel Sherrill wrote:
> 
> 
> On Thu, Nov 5, 2020, 9:26 AM Sebastian Huber
>  > wrote:
> 
> Hello,
> 
> I review currently the Coding Conventions. Should the 80 characters
> limit be really a 79 characters limit with the \n as the invisible 80th
> character?
> 
> 
> Yes. 
> 
> As old as this makes me feel, I remember printers which did an automatic
> linefeed and then the newline one if you hit column 80. So it really is
> 79 unfortunately.

I don't think printers with an automatic linefeed are a common use case
for reading the RTEMS source code nowadays. So that maybe isn't the best
reason for using 79 characters.

I would suggest to use the same convention that most coding styles use
which seems to be 80 characters:

  https://en.wikipedia.org/wiki/Characters_per_line#In_programming

At least if there are no more recent examples for tools or editors where
79 is a benefit. 80 seems just feels a bit more natural.

By the way: If we count '\n': Should we count a tab '\t' as a single
character, as 2, as 4 or as 8 ones? What about the few Unicode
characters that slipped in over the years?

Best regards

Christian

> 
> 
> -- 
> 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
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

[Christian Mauderer]

Hello Niteesh,

On 03/11/2020 03:42, Niteesh G. S. wrote:
> Hello Christian,
> 
> On Tue, Nov 3, 2020 at 12:43 AM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> Hello Niteesh,
> 
> On 02/11/2020 18:06, Niteesh G. S. wrote:
> > ping.
> 
> Yes, of course you are right that it would be time to integrate it. The
> nasty part why I haven't started to do something into that direction is
> that we currently still have the old build system and the new in
> parallel. But I think we should start to integrate your code anyway.
> 
> Please correct me if I'm wrong: Currently there are two parts:
> 
> 1. Adding the OFW interface.
> 
> 2. Using in in BBB.
> 
> Is that correct?
> 
> There is also the FreeBSD structures to makeporting of drivers easy.
> I guess merging this after a thorough inspection should also not be
> an issue.
> 

Do the patches for the OFW interface and the FreeBSD structures still
work on a current RTEMS master?

Best regards

Christian

> 
> I think the first one should be not too hard. There are already some
> parts that use only the new build system. Wouldn't be a problem to do
> that with OFW too. So to all participating at the discussion: Is there
> any blocker left why we wouldn't integrate an updated version of the
> patches?
> 
>  
> The only blocker seen during the development was the license issue.
> But that is now resolved since we figured out that all the referenced
> code comes under the BSD 2 license.
>  
> 
> The second part is a bit harder. BBB is one of the BSPs that are quite
> entry friendly and therefore it should currently build with old and new
> build system till the old system is removed.
> 
>  
> OK. I'll wait until the old system gets removed, I still have some work left
> to do on the drivers.
> 
> Thanks,
> Niteesh
> 
> Best regards
> 
> Christian
> 
> >
> > On Thu, Sep 24, 2020 at 9:00 AM Niteesh G. S.
> mailto:niteesh...@gmail.com>
> > <mailto:niteesh...@gmail.com <mailto:niteesh...@gmail.com>>> wrote:
> >
> >     Hello,
> >
> >     On Sat, Sep 19, 2020 at 4:13 PM Christian Mauderer
> >     mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>> wrote:
> >
> >         Hello Niteesh,
> >
> >         sorry for adding another delay: I think the new build system
> >         needs a bit
> >         of time to settle. As soon as there are some more PASS in the
> >         table that
> >         Sebastian created [1] (especially for beagle) we should try to
> >         get these
> >         patches merged. Before that I would like to avoid big changes
> >         because it
> >         might get hard to distinguish new bugs from build system bugs.
> >
> >
> >     No problem. Currently, I have my university exams going on and
> also I am
> >     waiting for my logic analyzer. As soon as it arrives I'll start
> >     verifying the previous
> >     drivers and finish refactoring the other ones.
> >
> >     Thanks,
> >     Niteesh.
> >
> >      
> >
> >
> >         Best regards
> >
> >         Christian
> >
> >         [1]
> https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist
> >
> >         On 16/09/2020 19:05, Niteesh G. S. wrote:
> >         > Hello,
> >         >
> >         > Sorry for the delay, I was a bit occupied with my
> university work.
> >         > Now since the new build system is merged I would like to
> get my
> >         > GSoC work merged too.
> >         >
> >         > The goal of this series patches is to implement the OFW API
> >         into RTEMS
> >         > and modify libBSD to use this RTEMS API instead of its own.
> >         >
> >         > Thanks,
> >         > Niteesh.
> >         >
> >         > On Wed, Sep 16, 2020 at 10:33 PM G S Niteesh Babu
> >         mailto:niteesh...@gmail.com>
> <mailto:niteesh...@gmail.com <mailto:niteesh...@gmail.com>>
> >         > <mailto:niteesh...@gmail.com
> <mailto:niteesh...@gmail.com> <mailto:niteesh...@gmail.com
> <mailto:niteesh...@gmail.com>>>>
> &g

Re: [PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

[Christian Mauderer]

Hello Niteesh,

On 02/11/2020 18:06, Niteesh G. S. wrote:
> ping.

Yes, of course you are right that it would be time to integrate it. The
nasty part why I haven't started to do something into that direction is
that we currently still have the old build system and the new in
parallel. But I think we should start to integrate your code anyway.

Please correct me if I'm wrong: Currently there are two parts:

1. Adding the OFW interface.

2. Using in in BBB.

Is that correct?

I think the first one should be not too hard. There are already some
parts that use only the new build system. Wouldn't be a problem to do
that with OFW too. So to all participating at the discussion: Is there
any blocker left why we wouldn't integrate an updated version of the
patches?

The second part is a bit harder. BBB is one of the BSPs that are quite
entry friendly and therefore it should currently build with old and new
build system till the old system is removed.

Best regards

Christian

> 
> On Thu, Sep 24, 2020 at 9:00 AM Niteesh G. S.  <mailto:niteesh...@gmail.com>> wrote:
> 
> Hello,
> 
> On Sat, Sep 19, 2020 at 4:13 PM Christian Mauderer
> mailto:o...@c-mauderer.de>> wrote:
> 
> Hello Niteesh,
> 
> sorry for adding another delay: I think the new build system
> needs a bit
> of time to settle. As soon as there are some more PASS in the
> table that
> Sebastian created [1] (especially for beagle) we should try to
> get these
> patches merged. Before that I would like to avoid big changes
> because it
> might get hard to distinguish new bugs from build system bugs.
> 
> 
> No problem. Currently, I have my university exams going on and also I am
> waiting for my logic analyzer. As soon as it arrives I'll start
> verifying the previous
> drivers and finish refactoring the other ones.
> 
> Thanks,
> Niteesh.
> 
>  
> 
> 
> Best regards
> 
> Christian
> 
> [1] https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist
> 
> On 16/09/2020 19:05, Niteesh G. S. wrote:
> > Hello,
> >
> > Sorry for the delay, I was a bit occupied with my university work.
> > Now since the new build system is merged I would like to get my
> > GSoC work merged too.
> >
> > The goal of this series patches is to implement the OFW API
> into RTEMS
> > and modify libBSD to use this RTEMS API instead of its own.
> >
> > Thanks,
> > Niteesh.
> >
> > On Wed, Sep 16, 2020 at 10:33 PM G S Niteesh Babu
> mailto:niteesh...@gmail.com>
> > <mailto:niteesh...@gmail.com <mailto:niteesh...@gmail.com>>>
> wrote:
> >
> >     RTEMS OFW is a FDT only implementation of the OpenFirmWare
> >     interface. This API is created to be compatible with FreeBSD
> >     OpenFirmWare interface. The main intention is to make
> >     porting of FreeBSD drivers to RTEMS easier.
> >
> >     Most functions implemented have an direct one-one mapping
> >     with the original OFW API and some extra auxiliary functions
> >     were implemented to make working with device trees easier in
> >     RTEMS.
> >
> >     Update #3784
> >     ---
> >      bsps/include/ofw/ofw.h        | 548
> +++
> >      bsps/include/ofw/ofw_compat.h |  74 
> >      bsps/shared/ofw/ofw.c         | 682
> ++
> >      spec/build/bsps/obj.yml       |   5 +
> >      4 files changed, 1309 insertions(+)
> >      create mode 100644 bsps/include/ofw/ofw.h
> >      create mode 100644 bsps/include/ofw/ofw_compat.h
> >      create mode 100644 bsps/shared/ofw/ofw.c
> >
> >     diff --git a/bsps/include/ofw/ofw.h b/bsps/include/ofw/ofw.h
> >     new file mode 100644
> >     index 00..411010be89
> >     --- /dev/null
> >     +++ b/bsps/include/ofw/ofw.h
> >     @@ -0,0 +1,548 @@
> >     +/* SPDX-License-Identifier: BSD-2-Clause */
> >     +
> >     +/**
> >     + * @file
> >     + *
> >     + * @ingroup ofw
> >     + *
> >     + * RTEMS FDT implementation of OpenFirmWare Interface.
> >     + *
>   

[PATCH rtems-libbsd] wpa: Fix multiple definition of `hmac_md5`

[Christian Mauderer]

hmac_md5 is defined in dhcpcd and in wpa supplicant.
---
 freebsd/contrib/wpa/src/crypto/md5.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/freebsd/contrib/wpa/src/crypto/md5.h 
b/freebsd/contrib/wpa/src/crypto/md5.h
index 33f8426c..48afb955 100644
--- a/freebsd/contrib/wpa/src/crypto/md5.h
+++ b/freebsd/contrib/wpa/src/crypto/md5.h
@@ -11,6 +11,10 @@
 
 #define MD5_MAC_LEN 16
 
+#ifdef __rtems__
+#define hmac_md5_vectorwpa_hmac_md5_vector
+#define hmac_md5   wpa_hmac_md5
+#endif /* __rtems__ */
 int hmac_md5_vector(const u8 *key, size_t key_len, size_t num_elem,
const u8 *addr[], const size_t *len, u8 *mac);
 int hmac_md5(const u8 *key, size_t key_len, const u8 *data, size_t data_len,
-- 
2.28.0

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

Re: Legacy networking stack removal

[Christian Mauderer]

oject into the direction of
lwIP we should try to create a package repo so it can be build without a
lot of effort.

> 
> Unfortunately, this is a case where the RTEMS core developers are too
> nice. We don't want to leave users wanting. Many projects would have
> killed the old stack before now.  And I think it is long overdue for us. :)

Do you ask us to be a bit less nice to users? I'll have to create a link
so that I can reference this statement the next time we discuss a change
that could break something for users ;-)

Best regards

Christian

> 
> I am thinking 4-6 weeks after the transition from autoconf to waf, the
> stack should come out. With any luck, this will be in December.  Moving
> to waf is an ideal time to clean cruft and being just after the 5
> release, we left things in for that last release if that's what the
> outcome is.
> 
> --joel
> 
> 
> Peter
> -
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
> 
> This email is delivered through the public internet using protocols
> subject to interception and tampering.
> 
> 
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-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.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: License files missing on 5-freebsd-12 branch

[Christian Mauderer]

On 29/09/2020 03:35, Chris Johns wrote:
> On 28/9/20 9:45 pm, Christian Mauderer wrote:
>> Sorry for the delay. I didn't manage to do these before my vacation and
>> then I forgot them during vacation. I just pushed them.
> 
> No problem and thank you. I hope you had a relaxing vacation?
> 
> Chris
> 

Like every vacation, it was too short. Otherwise: Yes, it was relaxing.

Best regards

Christian

-- 
----
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-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.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: License files missing on 5-freebsd-12 branch

[Christian Mauderer]

On 17/09/2020 23:37, Chris Johns wrote:
> On 17/9/20 10:57 pm, Joel Sherrill wrote:
>> On Thu, Sep 17, 2020 at 4:33 AM Christian Mauderer
>> > <mailto:christian.maude...@embedded-brains.de>> wrote:
>>
>> Hello,
>>
>> Chris pinged me that I missed to add these patches to the 5-freebsd-12
>> branch. It would be good if we would add the license files to the
>> release branch too. This will allow users to easily find the correct
>> licenses.
>>
>>
>> +1  
> 
> OK to push.
> 
> Thanks
> Chris
> 

Sorry for the delay. I didn't manage to do these before my vacation and
then I forgot them during vacation. I just pushed them.

Best regards

Christian

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-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.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v1 1/2] bsps/shared/ofw: Implement RTEMS OFW interface

[Christian Mauderer]

Hello Niteesh,

sorry for adding another delay: I think the new build system needs a bit
of time to settle. As soon as there are some more PASS in the table that
Sebastian created [1] (especially for beagle) we should try to get these
patches merged. Before that I would like to avoid big changes because it
might get hard to distinguish new bugs from build system bugs.

Best regards

Christian

[1] https://devel.rtems.org/wiki/Release/6/Waf%20BSP%20Checklist

On 16/09/2020 19:05, Niteesh G. S. wrote:
> Hello,
> 
> Sorry for the delay, I was a bit occupied with my university work.
> Now since the new build system is merged I would like to get my
> GSoC work merged too.
> 
> The goal of this series patches is to implement the OFW API into RTEMS
> and modify libBSD to use this RTEMS API instead of its own.
> 
> Thanks,
> Niteesh.
> 
> On Wed, Sep 16, 2020 at 10:33 PM G S Niteesh Babu  > wrote:
> 
> RTEMS OFW is a FDT only implementation of the OpenFirmWare
> interface. This API is created to be compatible with FreeBSD
> OpenFirmWare interface. The main intention is to make
> porting of FreeBSD drivers to RTEMS easier.
> 
> Most functions implemented have an direct one-one mapping
> with the original OFW API and some extra auxiliary functions
> were implemented to make working with device trees easier in
> RTEMS.
> 
> Update #3784
> ---
>  bsps/include/ofw/ofw.h        | 548 +++
>  bsps/include/ofw/ofw_compat.h |  74 
>  bsps/shared/ofw/ofw.c         | 682 ++
>  spec/build/bsps/obj.yml       |   5 +
>  4 files changed, 1309 insertions(+)
>  create mode 100644 bsps/include/ofw/ofw.h
>  create mode 100644 bsps/include/ofw/ofw_compat.h
>  create mode 100644 bsps/shared/ofw/ofw.c
> 
> diff --git a/bsps/include/ofw/ofw.h b/bsps/include/ofw/ofw.h
> new file mode 100644
> index 00..411010be89
> --- /dev/null
> +++ b/bsps/include/ofw/ofw.h
> @@ -0,0 +1,548 @@
> +/* SPDX-License-Identifier: BSD-2-Clause */
> +
> +/**
> + * @file
> + *
> + * @ingroup ofw
> + *
> + * RTEMS FDT implementation of OpenFirmWare Interface.
> + *
> + * RTEMS OFW is a FDT only implementation of the OpenFirmWare
> interface.
> + * This API is created to be compatible with FreeBSD OpenFirmWare
> interface.
> + * The main intention is to make porting of FreeBSD drivers to
> RTEMS easier.
> + */
> +
> +/*
> + * Copyright (C) 2020 Niteesh Babu G S  >
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *    notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *    notice, this list of conditions and the following disclaimer
> in the
> + *    documentation and/or other materials provided with the
> distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
> CONTRIBUTORS "AS IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
> PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
> CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
> WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
> OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
> ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifndef _OFW_H
> +#define _OFW_H
> +
> +#ifdef __cplusplus
> +extern "C" {
> +#endif
> +
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * Represents a node in the device tree. The offset from fdtp to
> node is used
> + * instead of fdt offset to make sure this is compatible with OF
> interface in
> + * FreeBSD.
> + */
> +typedef uint32_t  phandle_t;
> +/**
> + * Represents the effective phandle of the node.
> + */
> +typedef uint32_t  ihandle_t;
> +/**
> + * Represents the data type of the buffer.
> + */
> +typedef uint32_t  pcell_t;
> +
> +/**
> + * @struct rtems_ofw_memory_area
> + *
> + * This is used to represent elements(FDT properties) that define
> + * region 

Re: How to use lvgl on pc386 BSP.

[Christian Mauderer]

Hello Karel,

I wasn't aware that there is a framebuffer driver in the PC BSP. Maybe
an alternative to using the BSP framebuffer driver could be to just port
the FreeBSD framebuffer driver for PC and use that one? That might could
be less work than fixing the PC BSPs driver.

If you want to continue to use the BSPs driver, I can try to have a more
detailled look at it. But like I said: I would expect that the FreeBSD
driver is simpler to use.

Best regards

Christian

On 19/09/2020 00:30, Karel Gardas wrote:
> On 9/18/20 11:51 PM, Karel Gardas wrote:
>> Whole demo output looks:
>>
>> i386: isr=0 irr=1
>> i386: isr=0 irr=1
>> FB_VESA_RM frame buffer -- driver initializing..
>>
>>
>> RTEMS LVGL HELLO WORLD
>>
>> nexus0: 
>> pcib0 pcibus 0
>> pci0:  on pcib0
>> pci0:  at device 0.0 (no driver attached)
>> pci0:  at device 1.0 (no driver attached)
>> pci0:  at device 1.1 (no driver attached)
>> pci0:  at device 1.3 (no driver attached)
>> pci0:  at device 2.0 (no driver attached)
>> pci0:  at device 3.0 (no driver attached)
>> cpu0
>> FB_VESA_RM open device
>> The framebuffer device was opened successfully.
>> FB_VESA_RM ioctl called, cmd=4602
>> fbxres 1024, fbyres 768
>> fbbpp 32
>> FB_VESA_RM ioctl called, cmd=4600
>> fbxres 1024, fbyres 768
>> fbbpp 32
>> 1024x768, 32bpp
>> 3145728 screen size.
>> Error: failed to map framebuffer device to memory: Not supported
>>
>>
> 
> ^ that was form Qemu, from my testing hw box it looks as follows. Sorry
> for the dead Reaktek. Also it looks like VBE bios is kind of limited
> since EDID recommended resolution is monitors native: 2560x1440, but
> BIOS does not support it hence offers 1920x1440 as most close.
> 
> i386: isr=0 irr=1
> FB_VESA_RM frame buffer -- driver initializing..
> 
> RTEMS LVGL HELLO WORLD
> 
> nexus0: 
> pcib0 pcibus 0
> pci0:  on pcib0
> pci0:  at device 0.0 (no driver attached)
> pcib1:  at device 1.0 on pci0
> pci1:  on pcib1
> pci1:  at device 5.0 (no driver attached)
> pci1:  at device 5.1 (no driver attached)
> pcib2:  irq 10 at device 10.0 on pci0
> pci2:  on pcib2
> re0:  port
> 0xd800-0xd8ff mem 0xfdfff000-0xfdff,0xfdff8000-0xfdffbfff irq 10 at
> device 0.0 on pci2
> re0: Chip rev. 0x2c00
> re0: MAC rev. 0x0020
> re0: PHY write failed
> re0: PHY write failed
> re0: PHY read failed
> re0: attaching PHYs failed
> device_attach: re0 attach returned 6
> pci0:  at device 17.0 (no driver attached)
> pci0:  at device 18.0 (no driver attached)
> pci0:  at device 18.2 (no driver attached)
> pci0:  at device 19.0 (no driver attached)
> pci0:  at device 19.2 (no driver attached)
> pci0:  at device 20.2 (no driver attached)
> pci0:  at device 20.3 (no driver attached)
> pcib3:  at device 20.4 on pci0
> pci3:  on pcib3
> re0: 
> port 0xe800-0xe8ff mem 0xfebffc00-0xfebffcff irq 3 at device 5.0 on pci3
> re0: Chip rev. 0x0400
> re0: MAC rev. 0x
> miibus0:  on re0
> rgephy0:  PHY 1 on miibus0
> rgephy0:  none, 10baseT, 10baseT-FDX, 10baseT-FDX-flow, 100baseTX,
> 100baseTX-FDX, 100baseTX-FDX-flow, 1000baseT, 1000baseT-master,
> 1000baseT-FDX, 1000baseT-FDX-master, 1000baseT-FDX-flow, 1w
> info: re0: Using defaults for TSO: 65518/35/2048
> info: re0: Ethernet address: 00:0e:2e:7b:da:0b
> pci0:  at device 20.5 (no driver attached)
> pci0:  at device 22.0 (no driver attached)
> pci0:  at device 22.2 (no driver attached)
> pci0:  at device 24.0 (no driver attached)
> pci0:  at device 24.1 (no driver attached)
> pci0:  at device 24.2 (no driver attached)
> pci0:  at device 24.3 (no driver attached)
> pci0: > at device 24.4 (no driver attached)
> cpu0
> TheFB_VESA_RM ioctl called, cmd=4602
> fbxres 1920, fbyres 1440
> fbbpp 32
> FB_VESA_RM ioctl called, cmd=4600
> fbxres 1920, fbyres 1440
> fbbpp 32
>  framebuffer device was opened successfully.
> 1920x1440, 32bpp
> 11059200 screen size.
> Error: failed to map framebuffer device to memory: Not supported
> 
> *** FATAL ***
> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
> --
> Exception 13 caught at PC  by thread 167837697
> --
> Processor execution context at time of the fault was  :
> --
>  EAX = 0EBX = 0 ECX = 3662e4EDX = 0
>  ESI = 0EDI = 3662bcEBP = ffESP = 3af0a8
> --
> Error code pushed by processor itself (if not 0) = 0
> --
> Call Stack Trace of EIP:
> 0xef7eef7e 0x
> *** FATAL ***
> fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
> --
> Exception 13 caught at PC 2ae863 by thread 167837697
> --
> Processor execution context at time of the fault was  :
> --
>  EAX = bEBX =   ECX 

Re: [PATCH rtems-libbsd 1/3] Add helper script to find licenses.

[Christian Mauderer]

On 17/09/2020 23:35, Chris Johns wrote:
> On 17/9/20 10:51 pm, Joel Sherrill wrote:
>> I think I'm ok on all three of these patches but some 
>> comments on the shell script. I can see where this is a
>> tedious but important check. And it can be improved easily.
>>
>> Since this smells like something Chris would poke me f
>> or and call a "Joel script" :)
> 
> Haha ...
> 
> This patch is only for the 5-freesd-12 branch and a script is fine. The script
> has made think for the master and 6-freebsd-12 branches libbsd.py should be
> taught to handle licenses so these are copied across as part of the import.
> 
> Chris
> 

Hello Chris and Joel,

I agree that this script is an ugly one. It has been hacked together
when I needed to import the license files and I didn't wanted to throw
it out of the window because I thought it might could be useful to find
some more missing license files in the future.

Please note that this script is already on master since quite a long
time and that I only cherry-picked the commits for the 5-freebsd-12
branch (and adapted the import patch to import the right version). So
thanks for the suggestions Joel but shouldn't these changes then be an
extra patch? Chris: You mentioned that libbsd.py should be taught to
handle licenses. Do you plan anything into that direction? In that case
touching the script wouldn't be really useful.

Best regards

Christian
-- 
----
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-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.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems-libbsd 3/3] Import FreeBSD license files.

[Christian Mauderer]

Fix #4082
---
 freebsd/COPYRIGHT | 126 ++
 freebsd/contrib/expat/COPYING |  21 +
 freebsd/contrib/libpcap/LICENSE   |  19 
 freebsd/contrib/libxo/LICENSE |  23 +
 freebsd/contrib/tcpdump/LICENSE   |  19 
 freebsd/contrib/wpa/COPYING   |  22 +
 freebsd/crypto/openssl/LICENSE| 125 +
 freebsd/sys/contrib/libsodium/LICENSE |  18 
 freebsd/sys/dev/e1000/LICENSE |  31 +++
 libbsd.py |  45 +
 10 files changed, 449 insertions(+)
 create mode 100644 freebsd/COPYRIGHT
 create mode 100644 freebsd/contrib/expat/COPYING
 create mode 100644 freebsd/contrib/libpcap/LICENSE
 create mode 100644 freebsd/contrib/libxo/LICENSE
 create mode 100644 freebsd/contrib/tcpdump/LICENSE
 create mode 100644 freebsd/contrib/wpa/COPYING
 create mode 100644 freebsd/crypto/openssl/LICENSE
 create mode 100644 freebsd/sys/contrib/libsodium/LICENSE
 create mode 100644 freebsd/sys/dev/e1000/LICENSE

diff --git a/freebsd/COPYRIGHT b/freebsd/COPYRIGHT
new file mode 100644
index ..4a40a9f3
--- /dev/null
+++ b/freebsd/COPYRIGHT
@@ -0,0 +1,126 @@
+# $FreeBSD$
+#  @(#)COPYRIGHT   8.2 (Berkeley) 3/21/94
+
+The compilation of software known as FreeBSD is distributed under the
+following terms:
+
+Copyright (c) 1992-2020 The FreeBSD Project.
+
+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 AUTHOR 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 AUTHOR 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 4.4BSD and 4.4BSD-Lite software is distributed under the following
+terms:
+
+All of the documentation and software included in the 4.4BSD and 4.4BSD-Lite
+Releases is copyrighted by The Regents of the University of California.
+
+Copyright 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
+   The Regents of the University of California.  All rights reserved.
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+1. Redistributions of source code must retain the above copyright
+   notice, this list of conditions and the following disclaimer.
+2. Redistributions in binary form must reproduce the above copyright
+   notice, this list of conditions and the following disclaimer in the
+   documentation and/or other materials provided with the distribution.
+3. All advertising materials mentioning features or use of this software
+   must display the following acknowledgement:
+This product includes software developed by the University of
+California, Berkeley and its contributors.
+4. Neither the name of the University 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 REGENTS 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 REGENTS 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 Institute of Electrical and Electronics Engineers and the American
+National Standards Committee X3, on Information Processing Systems have
+given us permission to reprint portions of their documentation.
+
+In the following statement, the phrase ``this text'' refers to portions
+of 

License files missing on 5-freebsd-12 branch

[Christian Mauderer]

Hello,

Chris pinged me that I missed to add these patches to the 5-freebsd-12
branch. It would be good if we would add the license files to the
release branch too. This will allow users to easily find the correct
licenses.

Best regards

Christian


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

[PATCH rtems-libbsd 2/3] builder.py: Add case for plain text files.

[Christian Mauderer]

Update #4082
---
 builder.py | 8 
 1 file changed, 8 insertions(+)

diff --git a/builder.py b/builder.py
index f5fe2afc..0eda461f 100755
--- a/builder.py
+++ b/builder.py
@@ -202,6 +202,9 @@ def revertFixLocalIncludes(data):
 data = re.sub('#include ]*)>', '#include "\\1"', data)
 return data
 
+def assertNothing(path):
+pass
+
 def assertHeaderFile(path):
 if path[-2] != '.' or path[-1] != 'h':
 print("*** " + path + " does not end in .h")
@@ -690,6 +693,11 @@ class Module(object):
reverseConverter, buildSystemComposer)]
 return files
 
+def addPlainTextFile(self, files):
+self.files += self.addFiles(files,
+FreeBSDPathComposer(), Converter(),
+Converter(), assertNothing)
+
 def addKernelSpaceHeaderFiles(self, files):
 self.files += self.addFiles(files,
 FreeBSDPathComposer(), 
FromFreeBSDToRTEMSHeaderConverter(),
-- 
2.26.2

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

Re: New build system ready for testing

[Christian Mauderer]

Hello Sebastian,

I get a linker error when I try to build libbsd for BBB (with a buildset that 
builds everything but netipsec):

-
/home/EB/christian_m/Projekte/rtems-bbb/install/rtems/6/lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld:
 ./libbsd.a(uipc_mbuf.c.20.o): in function `m_unmappedtouio':
/home/EB/christian_m/Projekte/rtems-bbb/libs/rtems-libbsd/build/arm-rtems6-beagleboneblack-noIPSec/../../freebsd/sys/kern/uipc_mbuf.c:1813:
 undefined reference to `PHYS_TO_VM_PAGE'
/home/EB/christian_m/Projekte/rtems-bbb/install/rtems/6/lib/gcc/arm-rtems6/10.2.1/../../../../arm-rtems6/bin/ld:
 
/home/EB/christian_m/Projekte/rtems-bbb/libs/rtems-libbsd/build/arm-rtems6-beagleboneblack-noIPSec/../../freebsd/sys/kern/uipc_mbuf.c:1814:
 undefined reference to `uiomove_fromphys'
collect2: error: ld returned 1 exit status
-

Configure line for libbsd is:

./waf configure \
--prefix=/home/EB/christian_m/Projekte/rtems-bbb//install/rtems/6 \
--rtems-bsps=arm/beagleboneblack \

--buildset=/home/EB/christian_m/Projekte/rtems-bbb//build/src/noipsec.ini \
--enable-warnings \
--optimization=2 \
--rtems-version=6

Adding your patch from ages ago to libbsd works to solve that:


https://gitlab.com/c-mauderer/rtems-libbsd/-/commit/c9474c0b228d91dff098d617234842d56af3c4d7.patch

But you haven't applied it to the libbsd master. So I assume that there is a 
better workaround for that problem? What's the correct solution?

Best regards

Christian

On 14/09/2020 09:07, Sebastian Huber wrote:
> Hello,
> 
> I checked in the new build system today. Now is a good time to test your
> favourite BSP if it still works. You find the user oriented
> documentation of build system here:
> 
> https://docs.rtems.org/branches/master/user/bld/index.html
> 
> The documentation for RTEMS maintainers is here:
> 
> https://docs.rtems.org/branches/master/eng/build-system.html
> 
> How to check the new build system for a particular BSP?
> 
> 1. Build the BSP with all tests enabled.
> 
> 2. Run the tests and compare the results with the old build system.
> Ideally use the RTEMS Tester to run the tests and report them to the
> RTEMS Project.
> 
> 3. Check if all BSP options are available (./waf bsp_defaults). Check
> the type and values of the BSP options.
> 
> 4. Check the linker command file.
> 
> 5. Check the compiler machine flags.
> 
> 6. Install the BSP and build your third-party libraries and applications
> with it.
> 

-- 
 
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-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.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: New Build System Status

[Christian Mauderer]

On 11/09/2020 09:19, Chris Johns wrote:
> On 11/9/20 5:14 pm, Sebastian Huber wrote:
>> are there any remaining issues which prevent the new build system from being
>> integrated? At the moment I just sit idle and wait. If there are technical
>> issues, I can fix them only if I know them.
> 
> I have none.

Hello Sebastian,

I think there has been one patch for libbsd that was necessary when
building the BSP with the new build system. You created it somewhen
during summer and I used it in a test build for a GSoC project:

https://gitlab.com/c-mauderer/rtems-libbsd/-/commit/c9474c0b228d91dff098d617234842d56af3c4d7

Beneath that I had no build system related problems for the BBB BSP.

Best regards

Christian

> 
>> I have a BSP using the new build system for the STM32H7 chips with Ethernet 
>> and
>> USB host support waiting for integration since April this year.
> 
> I have the C++ threads with attributes patch I posted last year waiting to be
> merged...
> 
> https://lists.rtems.org/pipermail/devel/2019-December/056436.html
> 
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
> 

-- 
----
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-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.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Virus Warning

[Christian Mauderer]

Hello,

I assume that most of you are careful anyway. But nonetheless a virus
warning: I received a message that pretends to be an answer to a RTEMS
mailing list post. The mail has a .doc file attached that contains a
virus. Text of the mail is:

--
Good afternoon!
It is regarding our recent conversation. Here is edits you have advised
to do:


--

I only received one such message per registered mail account. It
references some random conversations from about April 2020. The fake
mail is addressed directly to me (not to the list).

If you want to know more about the virus, see:

https://www.virustotal.com/gui/file/2e773d1c57ad270fa94ab01d98649f3c12b8d8b6b1cf007fbd7c1c8954a0a5b8/detection

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-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.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Determining Linux Distribution

[Christian Mauderer]

On 10/09/2020 18:31, Joel Sherrill wrote:
> 
> 
> On Thu, Sep 10, 2020 at 11:09 AM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> On 10/09/2020 00:25, Chris Johns wrote:
> > On 10/9/20 8:15 am, Joel Sherrill wrote:
> >> On Wed, Sep 9, 2020 at 4:06 PM Karel Gardas
> mailto:karel.gar...@centrum.cz>
> >> <mailto:karel.gar...@centrum.cz
> <mailto:karel.gar...@centrum.cz>>> wrote:
> >>
> >>     On 9/9/20 11:03 PM, Karel Gardas wrote:
> >>     > so Debian, Kali and OpenSuSE at least are not well handled
> by this
> >>     > script and it's quite fun since simple:
> >>
> >>     Can't judge author of the script. The post is from 2008! So I
> guess
> >>     /etc/os-release was not so wide spread among the Linuxes at
> that time...
> >>
> >> That looks promising and linux.py in rtems-toolkit should be easy
> to make do that.
> >
> > The code in linux.py that calls platform.dist() should be removed
> because the
> > call has been removed from Python 3 after 3.5.
> >
> > Chris
> 
> You have seen that there exists a python pip package to find out the
> distribution:
> 
> https://distro.readthedocs.io/en/latest/
> 
> 
> I assume we don't want to assume someone will use pip to load a package
> to use the RSB or rtems-tools.  Copying it into our tree gives us a package
> that will periodically need to be updated.
> 
> Chris.. what do you want to do?
> 
> --joel
>  

If it's not a critical information most likely we can also just do a
`uname` and a `cat /etc/os.release` or similar. That will cover _most_
modern distributions.

Best regards

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

Re: Determining Linux Distribution

[Christian Mauderer]

On 10/09/2020 00:25, Chris Johns wrote:
> On 10/9/20 8:15 am, Joel Sherrill wrote:
>> On Wed, Sep 9, 2020 at 4:06 PM Karel Gardas > > wrote:
>>
>> On 9/9/20 11:03 PM, Karel Gardas wrote:
>> > so Debian, Kali and OpenSuSE at least are not well handled by this
>> > script and it's quite fun since simple:
>>
>> Can't judge author of the script. The post is from 2008! So I guess
>> /etc/os-release was not so wide spread among the Linuxes at that time...
>>
>> That looks promising and linux.py in rtems-toolkit should be easy to make do 
>> that.
> 
> The code in linux.py that calls platform.dist() should be removed because the
> call has been removed from Python 3 after 3.5.
> 
> Chris

You have seen that there exists a python pip package to find out the
distribution:

https://distro.readthedocs.io/en/latest/

Best regards

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

Re: [PATCH rtems-libbsd 1/2] sdhci: Add some workarrounds for i.MX

[Christian Mauderer]

Hello Gedare,

I created a ticket for this in FreeBSD (I really hope I picked the right
way for this). I'll wait whether it needs some adaption and then re-send
an adapted patch for libbsd as soon as I have a version that is accepted
in FreeBSD.

Best regards

Christian

On 10/09/2020 09:05, Christian Mauderer wrote:
> Hello Gedare,
> 
> I'll have to rework some parts (the ones where I checked for the BSP)
> but I'll try.
> 
> Best regards
> 
> Christian>
> On 09/09/2020 17:58, Gedare Bloom wrote:
>> Can this be pushed upstream in a non-RTEMS specific way?
>>
>> On Wed, Sep 9, 2020 at 5:16 AM Christian Mauderer
>>  wrote:
>>>
>>> Some bits are in the wrong order. Beneath that, the interrupts can occur
>>> in an unexpected order. The DATA_AVAIL interrupt can occur at the same
>>> time as the DMA interrupt (or slightly before it). With that, the DMA
>>> and PIO interrupt handling doesn't work well together. Beneath that the
>>> DMA interrupt isn't only executed at block ends but also if all data is
>>> transfered. That can lead to problems with the DATA_END interrupt.
>>> Therefore check whether there is really data left to unload.
>>>
>>> Update #3869
>>> ---
>>>  freebsd/sys/dev/sdhci/fsl_sdhci.c | 41 +++
>>>  freebsd/sys/dev/sdhci/sdhci.c | 40 ++
>>>  2 files changed, 81 insertions(+)
>>>
>>> diff --git a/freebsd/sys/dev/sdhci/fsl_sdhci.c 
>>> b/freebsd/sys/dev/sdhci/fsl_sdhci.c
>>> index be3d1de3..acef1c4a 100644
>>> --- a/freebsd/sys/dev/sdhci/fsl_sdhci.c
>>> +++ b/freebsd/sys/dev/sdhci/fsl_sdhci.c
>>> @@ -74,6 +74,9 @@ uint32_t mpc85xx_get_system_clock(void);
>>>  #endif /* __rtems__ */
>>>  #endif
>>>
>>> +#ifndef __rtems__
>>> +#include 
>>> +#endif /* __rtems__ */
>>>  #include 
>>>
>>>  #include 
>>> @@ -168,6 +171,16 @@ struct fsl_sdhci_softc {
>>>  #define SDHC_PROT_CDSS (1 << 7)
>>>
>>>  #defineSDHC_SYS_CTRL   0x2c
>>> +#ifdef __rtems__
>>> +
>>> +/*
>>> + * Freescale messed up the INT DMA ERR bit and placed it at bit 28 instead 
>>> of
>>> + * bit 25 which would be standard.
>>> + */
>>> +#define SDHC_INT_DMAES (1 << 28)
>>> +
>>> +#define SDHC_CAN_DO_ADMA2  0x0010
>>> +#endif /* __rtems__ */
>>>
>>>  /*
>>>   * The clock enable bits exist in different registers for ESDHC vs USDHC, 
>>> but
>>> @@ -349,6 +362,16 @@ fsl_sdhci_read_4(device_t dev, struct sdhci_slot 
>>> *slot, bus_size_t off)
>>> val32 &= ~SDHCI_CAN_VDD_180;
>>> val32 &= ~SDHCI_CAN_DO_SUSPEND;
>>> val32 |= SDHCI_CAN_DO_8BITBUS;
>>> +#ifdef __rtems__
>>> +   /*
>>> +* Freescale signals ADMA2 capability via bit 20 (which 
>>> would be
>>> +* ADMA1) instead of 19.
>>> +*/
>>> +   if (val32 & SDHC_CAN_DO_ADMA2) {
>>> +   val32 &= ~SDHC_CAN_DO_ADMA2;
>>> +   val32 |= SDHCI_CAN_DO_ADMA2;
>>> +   }
>>> +#endif /* __rtems__ */
>>> return (val32);
>>> }
>>>
>>> @@ -373,6 +396,13 @@ fsl_sdhci_read_4(device_t dev, struct sdhci_slot 
>>> *slot, bus_size_t off)
>>>  * command with an R1B response, mix it into the hardware status.
>>>  */
>>> if (off == SDHCI_INT_STATUS) {
>>> +#ifdef __rtems__
>>> +   /* Fix messed up DMA error. */
>>> +   if (val32 & SDHC_INT_DMAES) {
>>> +   val32 &= ~SDHC_INT_DMAES;
>>> +   val32 |= SDHCI_INT_ADMAERR;
>>> +   }
>>> +#endif /* __rtems__ */
>>> return (val32 | sc->r1bfix_intmask);
>>> }
>>>
>>> @@ -519,6 +549,15 @@ fsl_sdhci_write_4(device_t dev, struct sdhci_slot 
>>> *slot, bus_size_t off, uint32_
>>> if (off == SDHCI_INT_STATUS) {
>>> sc->r1bfix_intmask &= ~val;
>>> }
>>> +#ifdef __rtems__
>>> +   /* Fix messed up DMA error. */
>>> +   if (off == SDHCI_INT_STATUS || off == SDHCI_INT_ENABLE || off == 
>>> SDHCI_SIGNAL_ENAB

Re: [PATCH rtems-libbsd 1/2] sdhci: Add some workarrounds for i.MX

[Christian Mauderer]

Hello Gedare,

I'll have to rework some parts (the ones where I checked for the BSP)
but I'll try.

Best regards

Christian

On 09/09/2020 17:58, Gedare Bloom wrote:
> Can this be pushed upstream in a non-RTEMS specific way?
> 
> On Wed, Sep 9, 2020 at 5:16 AM Christian Mauderer
>  wrote:
>>
>> Some bits are in the wrong order. Beneath that, the interrupts can occur
>> in an unexpected order. The DATA_AVAIL interrupt can occur at the same
>> time as the DMA interrupt (or slightly before it). With that, the DMA
>> and PIO interrupt handling doesn't work well together. Beneath that the
>> DMA interrupt isn't only executed at block ends but also if all data is
>> transfered. That can lead to problems with the DATA_END interrupt.
>> Therefore check whether there is really data left to unload.
>>
>> Update #3869
>> ---
>>  freebsd/sys/dev/sdhci/fsl_sdhci.c | 41 +++
>>  freebsd/sys/dev/sdhci/sdhci.c | 40 ++
>>  2 files changed, 81 insertions(+)
>>
>> diff --git a/freebsd/sys/dev/sdhci/fsl_sdhci.c 
>> b/freebsd/sys/dev/sdhci/fsl_sdhci.c
>> index be3d1de3..acef1c4a 100644
>> --- a/freebsd/sys/dev/sdhci/fsl_sdhci.c
>> +++ b/freebsd/sys/dev/sdhci/fsl_sdhci.c
>> @@ -74,6 +74,9 @@ uint32_t mpc85xx_get_system_clock(void);
>>  #endif /* __rtems__ */
>>  #endif
>>
>> +#ifndef __rtems__
>> +#include 
>> +#endif /* __rtems__ */
>>  #include 
>>
>>  #include 
>> @@ -168,6 +171,16 @@ struct fsl_sdhci_softc {
>>  #define SDHC_PROT_CDSS (1 << 7)
>>
>>  #defineSDHC_SYS_CTRL   0x2c
>> +#ifdef __rtems__
>> +
>> +/*
>> + * Freescale messed up the INT DMA ERR bit and placed it at bit 28 instead 
>> of
>> + * bit 25 which would be standard.
>> + */
>> +#define SDHC_INT_DMAES (1 << 28)
>> +
>> +#define SDHC_CAN_DO_ADMA2  0x0010
>> +#endif /* __rtems__ */
>>
>>  /*
>>   * The clock enable bits exist in different registers for ESDHC vs USDHC, 
>> but
>> @@ -349,6 +362,16 @@ fsl_sdhci_read_4(device_t dev, struct sdhci_slot *slot, 
>> bus_size_t off)
>> val32 &= ~SDHCI_CAN_VDD_180;
>> val32 &= ~SDHCI_CAN_DO_SUSPEND;
>> val32 |= SDHCI_CAN_DO_8BITBUS;
>> +#ifdef __rtems__
>> +   /*
>> +* Freescale signals ADMA2 capability via bit 20 (which 
>> would be
>> +* ADMA1) instead of 19.
>> +*/
>> +   if (val32 & SDHC_CAN_DO_ADMA2) {
>> +   val32 &= ~SDHC_CAN_DO_ADMA2;
>> +   val32 |= SDHCI_CAN_DO_ADMA2;
>> +   }
>> +#endif /* __rtems__ */
>> return (val32);
>> }
>>
>> @@ -373,6 +396,13 @@ fsl_sdhci_read_4(device_t dev, struct sdhci_slot *slot, 
>> bus_size_t off)
>>  * command with an R1B response, mix it into the hardware status.
>>  */
>> if (off == SDHCI_INT_STATUS) {
>> +#ifdef __rtems__
>> +   /* Fix messed up DMA error. */
>> +   if (val32 & SDHC_INT_DMAES) {
>> +   val32 &= ~SDHC_INT_DMAES;
>> +   val32 |= SDHCI_INT_ADMAERR;
>> +   }
>> +#endif /* __rtems__ */
>> return (val32 | sc->r1bfix_intmask);
>> }
>>
>> @@ -519,6 +549,15 @@ fsl_sdhci_write_4(device_t dev, struct sdhci_slot 
>> *slot, bus_size_t off, uint32_
>> if (off == SDHCI_INT_STATUS) {
>> sc->r1bfix_intmask &= ~val;
>> }
>> +#ifdef __rtems__
>> +   /* Fix messed up DMA error. */
>> +   if (off == SDHCI_INT_STATUS || off == SDHCI_INT_ENABLE || off == 
>> SDHCI_SIGNAL_ENABLE) {
>> +   if (val & SDHCI_INT_ADMAERR) {
>> +   val &= ~SDHCI_INT_ADMAERR;
>> +   val |= SDHC_INT_DMAES;
>> +   }
>> +   }
>> +#endif /* __rtems__ */
>>
>> WR4(sc, off, val);
>>  }
>> @@ -884,10 +923,12 @@ fsl_sdhci_attach(device_t dev)
>>
>> sc->slot.quirks |= SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK;
>>
>> +#if !defined(__rtems__) || !defined(LIBBSP_ARM_IMX_BSP_H)
>> /*
>>  * DMA is not really broken, I just haven't implemented it yet.
>>  */
>> sc->slot.quirks |= SDHCI_QUIRK_BROKEN_DMA;
>> +#endif /* 

Re: We are loosing patches

[Christian Mauderer]

On 09/09/2020 17:52, Gedare Bloom wrote:
> On Wed, Sep 9, 2020 at 8:16 AM Christian Mauderer
>  wrote:
>>
>> Hello Jan and Joel,
>>
>> On 09/09/2020 15:19, Joel Sherrill wrote:
>>>
>>>
>>> On Wed, Sep 9, 2020 at 3:43 AM >> <mailto:jan.som...@dlr.de>> wrote:
>>>
>>> I would like this idea.
>>> We got Gitlab this year and collaboration with it is pretty convenient.
>>> They also seem to hand out free licenses for OSS projects.
>>> I guess installing and maintaining an instance is probably quite
>>> some work.
>>>
>>>
>>> We use Gitlab community edition internally. On a recent non-RTEMS project,
>>> we pushed the Continuous Integration and Testing pretty hard. We built,
>>> tested, and did coverage for 4 configurations of the software for 3
>>> different
>>> Linux distributions using Docker on every push. We built Doxygen every time
>>> and ran the FACE Conformance Test Suite on multiple components. Plus
>>> had a  commercial tool that did MISRA/CERT compliance checking and MCDC
>>> coverage analysis. Everything ran well but the commercial tool took a
>>> fair amount of babying.
>>>
>>> We didn't use it for patch management though. We just required issues
>>> and you had to pass the CIT to merge. We did use milestones for light
>>> project management but only the basics of the ticketing system.
>>>
>>> One challenge RTEMS has with automated testing is the turnaround time.
>>> On the project I mentioned, everything took only a few minutes except the
>>> commercial tool which ended up taking 30 minutes. For RTEMS, building
>>> and testing everything is quite time consuming. The script I run takes
>>> about
>>> 1 day on an 8 core Xeon and ~2.5 days on the older quad-cores. I don't test
>>> anything on hardware in that cycle. Because of this, the testing part of CIT
>>> for RTEMS will likely always only be spot checking. But we could put more
>>> emphasis on say Doxygen builds always being warning free and the critical
>>> BSPs that are spot checked being warning free.
>>>
>>> The "critical set of BSPs" to be spot checked is up for discussion but
>>> ideally they would run on simulators and represent a realistic but broad
>>> subset. That makes the long version of the list something like sparc/leon3,
>>> arm/zynq_qemu, x86/pc, powerpc/psim and mips/jmr3904.
>>>
>>> This was a long reply to just cover what I think we could do for CIT on
>>> the RTEMS repo. Considering rtems-docs, examples, etc. adds other
>>> options.
>>
>> Also I agree that automated builds or checks could be an extension, that
>> is not really the core point. Part of these automated builds are already
>> done by buildbot.rtems.org.
>>
>>>
>>> Back to the patch management system.
>>
>> That's the part that (at the moment) was the starting point of my mail.
>>
>>>
>>> We have discussed having Patchwork and Phabricator in the past. I don't
>>> know if there is a true resistance to using such a tool but a lack of time.
>>> All system administration on rtems.org <http://rtems.org> is volunteer.
>>> That by itself is the
>>> biggest barrier.
>>
>> Regarding the administrative effort: I'm well aware that there is a lot
>> of work. And if my request adds additional workload, we should discuss
>> who can do that or how it can be funded. But I don't think that it is a
>> good situation that patches get lost or that _new_ contributors have to
>> ping a mail because no one has seen it between lot's of other mails.
>> Patches are valuable and they are the entry point for every new member
>> of our community.
>>
>> Beneath that: Our time is valuable too. If systems can collect all
>> relevant information for one patch set (including earlier versions,
>> comments, ...): Why do we waste so much time with searching that kind of
>> stuff on the mailing list. If you just have to use a single command to
>> apply the latest version of a patch set: Why do we have to find and
>> download the patches from the mailing list, apply them locally to the
>> correct repo, make sure that we did the right thing and then push them.
>>
>> So please let's not jump right into the administrative part of the
>> system or how many work it maybe would be to implement it. Let's first
>> find out whether a big part of our community could agree to a more
>> modern 

Re: We are loosing patches

[Christian Mauderer]

Hello Jan and Joel,

On 09/09/2020 15:19, Joel Sherrill wrote:
> 
> 
> On Wed, Sep 9, 2020 at 3:43 AM  <mailto:jan.som...@dlr.de>> wrote:
> 
> I would like this idea.
> We got Gitlab this year and collaboration with it is pretty convenient.
> They also seem to hand out free licenses for OSS projects.
> I guess installing and maintaining an instance is probably quite
> some work.
> 
> 
> We use Gitlab community edition internally. On a recent non-RTEMS project, 
> we pushed the Continuous Integration and Testing pretty hard. We built, 
> tested, and did coverage for 4 configurations of the software for 3
> different 
> Linux distributions using Docker on every push. We built Doxygen every time
> and ran the FACE Conformance Test Suite on multiple components. Plus 
> had a  commercial tool that did MISRA/CERT compliance checking and MCDC
> coverage analysis. Everything ran well but the commercial tool took a 
> fair amount of babying. 
> 
> We didn't use it for patch management though. We just required issues
> and you had to pass the CIT to merge. We did use milestones for light
> project management but only the basics of the ticketing system.
> 
> One challenge RTEMS has with automated testing is the turnaround time. 
> On the project I mentioned, everything took only a few minutes except the 
> commercial tool which ended up taking 30 minutes. For RTEMS, building 
> and testing everything is quite time consuming. The script I run takes
> about 
> 1 day on an 8 core Xeon and ~2.5 days on the older quad-cores. I don't test 
> anything on hardware in that cycle. Because of this, the testing part of CIT
> for RTEMS will likely always only be spot checking. But we could put more 
> emphasis on say Doxygen builds always being warning free and the critical 
> BSPs that are spot checked being warning free.  
> 
> The "critical set of BSPs" to be spot checked is up for discussion but 
> ideally they would run on simulators and represent a realistic but broad 
> subset. That makes the long version of the list something like sparc/leon3, 
> arm/zynq_qemu, x86/pc, powerpc/psim and mips/jmr3904. 
> 
> This was a long reply to just cover what I think we could do for CIT on
> the RTEMS repo. Considering rtems-docs, examples, etc. adds other 
> options.

Also I agree that automated builds or checks could be an extension, that
is not really the core point. Part of these automated builds are already
done by buildbot.rtems.org.

> 
> Back to the patch management system.

That's the part that (at the moment) was the starting point of my mail.

> 
> We have discussed having Patchwork and Phabricator in the past. I don't
> know if there is a true resistance to using such a tool but a lack of time.
> All system administration on rtems.org <http://rtems.org> is volunteer. 
> That by itself is the
> biggest barrier. 

Regarding the administrative effort: I'm well aware that there is a lot
of work. And if my request adds additional workload, we should discuss
who can do that or how it can be funded. But I don't think that it is a
good situation that patches get lost or that _new_ contributors have to
ping a mail because no one has seen it between lot's of other mails.
Patches are valuable and they are the entry point for every new member
of our community.

Beneath that: Our time is valuable too. If systems can collect all
relevant information for one patch set (including earlier versions,
comments, ...): Why do we waste so much time with searching that kind of
stuff on the mailing list. If you just have to use a single command to
apply the latest version of a patch set: Why do we have to find and
download the patches from the mailing list, apply them locally to the
correct repo, make sure that we did the right thing and then push them.

So please let's not jump right into the administrative part of the
system or how many work it maybe would be to implement it. Let's first
find out whether a big part of our community could agree to a more
modern approach of handling patches that can save time for contributors
and maintainers. As soon as we have one: Let's talk about what is
necessary to reach that solution. If it is a step forward, I'm sure we
will find a solution to handle the initial effort.

Best regards

Christian

> 
> --joel
> 
> Ph
> Best regards,
> 
>    Jan
> 
> > -Original Message-
> > From: devel  <mailto:devel-boun...@rtems.org>> On Behalf Of Christian Mauderer
> > Sent: Wednesday, September 9, 2020 10:24 AM
> > To: RTEMS Devel RTEMS mailto:devel@rtems.org>>
> > Subject: We are loosing patches
> >
> > Hello,
> >
> > triggered by a comment from Chris here
> >

Re: BSP Test Results

[Christian Mauderer]

On 09/09/2020 02:29, Chris Johns wrote:
[...]
> 
>> > Also I am not sure but hopefully the test reports do accurately reflect
>> host OS.
>>
>> There is a "Host" section at the top of the results log? It is just 
>> `uname -a`.
>>
>> I think that's sufficient as long as it can distinguish Linux distributions. 
> 
> Does Linux or Python on Linux provide a common means to find what distribution
> you are on? Do distributions based on another distro make a suitable the
> separation? A Linux distro expert will need to guide this. I have no idea.
> 

In theory there is the platform.linux_distribution() in python:

https://docs.python.org/3.7/library/platform.html#module-platform

But on my OpenSUSE 15.1 that failed to provide anything. Beneath that it
seems to be deprecated since Python 3.5.

A newer package that want to provide this functionality is "distro":

https://distro.readthedocs.io/en/latest/

Beneath that module, there is "/etc/os-release". It's a standard file
for systemd. So most likely most distros have it now:

https://www.freedesktop.org/software/systemd/man/os-release.html

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-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.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Christian Mauderer]

The imx_ccm_*_hz are all defined in RTEMS. So don't duplicate them in
libbsd. Otherwise some applications get linker errors.

Update #3869
---
 freebsd/sys/arm/freescale/imx/imx6_ccm.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/freebsd/sys/arm/freescale/imx/imx6_ccm.c 
b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
index 78bbd5c1..7fdb69b8 100644
--- a/freebsd/sys/arm/freescale/imx/imx6_ccm.c
+++ b/freebsd/sys/arm/freescale/imx/imx6_ccm.c
@@ -368,6 +368,7 @@ imx6_ccm_sata_enable(void)
return 0;
 }
 
+#ifndef __rtems__
 uint32_t
 imx_ccm_ecspi_hz(void)
 {
@@ -408,6 +409,7 @@ imx_ccm_ahb_hz(void)
 {
return (13200);
 }
+#endif /* __rtems__ */
 
 void
 imx_ccm_ipu_enable(int ipu)
-- 
2.26.2

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

[PATCH rtems-libbsd 1/2] sdhci: Add some workarrounds for i.MX

[Christian Mauderer]

Some bits are in the wrong order. Beneath that, the interrupts can occur
in an unexpected order. The DATA_AVAIL interrupt can occur at the same
time as the DMA interrupt (or slightly before it). With that, the DMA
and PIO interrupt handling doesn't work well together. Beneath that the
DMA interrupt isn't only executed at block ends but also if all data is
transfered. That can lead to problems with the DATA_END interrupt.
Therefore check whether there is really data left to unload.

Update #3869
---
 freebsd/sys/dev/sdhci/fsl_sdhci.c | 41 +++
 freebsd/sys/dev/sdhci/sdhci.c | 40 ++
 2 files changed, 81 insertions(+)

diff --git a/freebsd/sys/dev/sdhci/fsl_sdhci.c 
b/freebsd/sys/dev/sdhci/fsl_sdhci.c
index be3d1de3..acef1c4a 100644
--- a/freebsd/sys/dev/sdhci/fsl_sdhci.c
+++ b/freebsd/sys/dev/sdhci/fsl_sdhci.c
@@ -74,6 +74,9 @@ uint32_t mpc85xx_get_system_clock(void);
 #endif /* __rtems__ */
 #endif
 
+#ifndef __rtems__
+#include 
+#endif /* __rtems__ */
 #include 
 
 #include 
@@ -168,6 +171,16 @@ struct fsl_sdhci_softc {
 #define SDHC_PROT_CDSS (1 << 7)
 
 #defineSDHC_SYS_CTRL   0x2c
+#ifdef __rtems__
+
+/*
+ * Freescale messed up the INT DMA ERR bit and placed it at bit 28 instead of
+ * bit 25 which would be standard.
+ */
+#define SDHC_INT_DMAES (1 << 28)
+
+#define SDHC_CAN_DO_ADMA2  0x0010
+#endif /* __rtems__ */
 
 /*
  * The clock enable bits exist in different registers for ESDHC vs USDHC, but
@@ -349,6 +362,16 @@ fsl_sdhci_read_4(device_t dev, struct sdhci_slot *slot, 
bus_size_t off)
val32 &= ~SDHCI_CAN_VDD_180;
val32 &= ~SDHCI_CAN_DO_SUSPEND;
val32 |= SDHCI_CAN_DO_8BITBUS;
+#ifdef __rtems__
+   /*
+* Freescale signals ADMA2 capability via bit 20 (which would be
+* ADMA1) instead of 19.
+*/
+   if (val32 & SDHC_CAN_DO_ADMA2) {
+   val32 &= ~SDHC_CAN_DO_ADMA2;
+   val32 |= SDHCI_CAN_DO_ADMA2;
+   }
+#endif /* __rtems__ */
return (val32);
}

@@ -373,6 +396,13 @@ fsl_sdhci_read_4(device_t dev, struct sdhci_slot *slot, 
bus_size_t off)
 * command with an R1B response, mix it into the hardware status.
 */
if (off == SDHCI_INT_STATUS) {
+#ifdef __rtems__
+   /* Fix messed up DMA error. */
+   if (val32 & SDHC_INT_DMAES) {
+   val32 &= ~SDHC_INT_DMAES;
+   val32 |= SDHCI_INT_ADMAERR;
+   }
+#endif /* __rtems__ */
return (val32 | sc->r1bfix_intmask);
}
 
@@ -519,6 +549,15 @@ fsl_sdhci_write_4(device_t dev, struct sdhci_slot *slot, 
bus_size_t off, uint32_
if (off == SDHCI_INT_STATUS) {
sc->r1bfix_intmask &= ~val;
}
+#ifdef __rtems__
+   /* Fix messed up DMA error. */
+   if (off == SDHCI_INT_STATUS || off == SDHCI_INT_ENABLE || off == 
SDHCI_SIGNAL_ENABLE) {
+   if (val & SDHCI_INT_ADMAERR) {
+   val &= ~SDHCI_INT_ADMAERR;
+   val |= SDHC_INT_DMAES;
+   }
+   }
+#endif /* __rtems__ */
 
WR4(sc, off, val);
 }
@@ -884,10 +923,12 @@ fsl_sdhci_attach(device_t dev)
 
sc->slot.quirks |= SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK;
 
+#if !defined(__rtems__) || !defined(LIBBSP_ARM_IMX_BSP_H)
/*
 * DMA is not really broken, I just haven't implemented it yet.
 */
sc->slot.quirks |= SDHCI_QUIRK_BROKEN_DMA;
+#endif /* __rtems__ */
 
/*
 * Set the buffer watermark level to 128 words (512 bytes) for both read
diff --git a/freebsd/sys/dev/sdhci/sdhci.c b/freebsd/sys/dev/sdhci/sdhci.c
index ed6010e8..53d86fe8 100644
--- a/freebsd/sys/dev/sdhci/sdhci.c
+++ b/freebsd/sys/dev/sdhci/sdhci.c
@@ -68,6 +68,9 @@ __FBSDID("$FreeBSD$");
 #include 
 
 #include 
+#ifdef __rtems__
+#include 
+#endif /* __rtems__ */
 
 SYSCTL_NODE(_hw, OID_AUTO, sdhci, CTLFLAG_RD, 0, "sdhci driver");
 
@@ -766,6 +769,17 @@ sdhci_dma_alloc(struct sdhci_slot *slot)
else
slot->sdma_boundary = SDHCI_BLKSZ_SDMA_BNDRY_512K;
}
+#ifdef __rtems__
+#if defined(LIBBSP_ARM_IMX_BSP_H)
+   /*
+* i.MX6ULL doesn't have the SDMA Buffer Boundary bits. Instead the
+* BLKSIZE is one bit larger and would overlap the Buffer Boundary.
+* Setting the Buffer Boundary to 4K makes sure that the highest BLKSIZE
+* bit is always 0.
+*/
+   slot->sdma_boundary = SDHCI_BLKSZ_SDMA_BNDRY_4K;
+#endif
+#endif /* __rtems__ */
slot->sdma_bbufsz = SDHCI_SDMA_BNDRY_TO_BBUFSZ(slot->sdma_boundary);
 
/*
@@ -1896,6 +1910,10 @@ sdhci_start_data(struct sdhci_slot *slot, const struct 
mmc_data *data)
BUS_DMASYNC_PREWRITE);
}

We are loosing patches

[Christian Mauderer]

Hello,

triggered by a comment from Chris here

https://lists.rtems.org/pipermail/users/2020-September/067873.html

I started to take a look at patches from non maintainers and write after
approval maintainers for some months: I think in May and June we lost at
least one or two of the following ones:

https://lists.rtems.org/pipermail/devel/2020-May/059751.html
https://lists.rtems.org/pipermail/devel/2020-May/059771.html
https://lists.rtems.org/pipermail/devel/2020-May/059772.html
https://lists.rtems.org/pipermail/devel/2020-May/059773.html
https://lists.rtems.org/pipermail/devel/2020-June/060125.html
https://lists.rtems.org/pipermail/devel/2020-June/060231.html
https://lists.rtems.org/pipermail/devel/2020-June/060235.html

It's a bit hard to see exactly whether a later version has been added
with a different subject, merged with another patch or just has been
rejected for some reason. That's another problem with our current system.

I think we start to loose valuable contributions due to that. I also
found some patches where just no one responded because no one noted it
and the person sending the patch had to ping it some time later. That's
not really encouraging to continue participating for new contributors.

I even lost track of some of my own patches in the past and found out
about a month later that I should have pushed them long ago.

Maybe it would be a good idea to start at least discussing whether we
should change something to avoid these problems. I think our current
system has two main problems:

1. All patches go to one single devel mailing list. It's sometimes hard
to see which patches are for what repository. And small patches tend to
just vanish between lot of other mails.

2. We have a big problem seeing which patch sets are done, which are in
the middle of a discussion and which are rejected.

A lot of other projects use software to solve these problems. Linux uses
"patchwork" for it since a long time (which needs one mailing list per
project). Most other projects use systems with pull requests like github
or a self hosted gitlab for that kind of stuff.

Maybe we should think about following these examples and go one step to
more modern software development too? What do you think?

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-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.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: AArch64 support and sharing of various drivers

[Christian Mauderer]

On 04/09/2020 05:12, Chris Johns wrote:
> On 4/9/20 12:43 pm, Joel Sherrill wrote:
>> On Thu, Sep 3, 2020, 6:58 AM Christian Mauderer
>> > <mailto:christian.maude...@embedded-brains.de>> wrote:
>>
>> Hello Kinsey,
>>
>> On 01/09/2020 23:56, Kinsey Moore wrote:
>> > Hi,
>> >
>> > I’ve been working on proper AArch64 support for RTEMS
>>
>> That's great. It means good raspberry pi 4 support ;-)
>>
>> > (versus running
>> > 32-bit ARM RTEMS behind a bootloader or JTAG device that switches the
>> > CPU to AArch32 mode) and while the vast majority of the architecture
>> > support code is new, lives in its own aarch64 directories, and is
>> > unrelated to RTEMS’s ARM support, there are several drivers living in
>> > the ARM shared directory that are critical to AArch64 support and many
>> > more that could potentially be shared. Given the limited scope of
>> > initial bringup on Qemu, that list is currently: GICv3, GPT(timer), and
>> > PL011(uart). I don’t really see a precedent for this type of sharing
>> > other than the global bsps/shared and bsps/include directories. The
>> > global shared directories might make sense for the PL011 since it could
>> > theoretically be used by anything that supports AXI/AMBA, but the GIC
>> > and GPT drivers rely on ARM system registers to function with both
>> > AArch32 and AArch64.
>> >
>> >  
>> >
>> > In short, where should the GICv3 and GPT drivers be relocated along 
>> with
>> > their associated headers, if at all?
>> >
>>
>> I might get a similar problem with some drivers shared between some
>> PowerPC and ARM too (NXP reuses some of the Freescale PowerPC
>> peripherals in up to date ARM controllers). I think in theory we already
>> have such drivers that maybe should be shared but are copied or
>> re-implemented in multiple BSPs instead.
>>
>> The Gaisler IP drivers were moved up in the tree recently also.
>>
>> One possibility might would be to add all arm/shared to the aarch64 too.
>> But that is a bit unclear
>>
>>
>> shared/arm??
> 
> shared/dev/int
> shared/dev/serial
> 
> ?

shared/dev/ already exist. So maybe wouldn't be a bad choice.

> 
>>
>> shared/nxp
> 
> -1 , companies get taken over and change names.

Agreed. There are still a lot of "freescale/imx" files out there (for
example U-Boot) even if it is NXP since quite some time.

> 
>>
>> Or
>>
>> shared/IP/vendor?

Depends on how you mean that:

Is "vendor" a placeholder so that we for example get a driver

 shared/IP/arm/gicv3.c

In that case: Same problem with company names. Also it's unlikely that
ARM changes the name, it's not impossible. And we will get other vendors
in the same directory.

Or do you mean

shared/IP/vendor/gicv3.c

In that case the directory would be a bit of a big melting pot for all
drivers without any structure.

>>
>> They need to be above a single architecture to be shared across 
>> architectures.
>>
> 
> +1
> 
>> This is just SoC IP modules that are being reused.

Sooner or later we will get more drivers. Like I said: Currently I'm in
the evaluation phase for a project where maybe a DMA is shared between
PowerPC and ARM.

Best regards

Christian

> 
> So should be use the type and then the file names can be the part?
> 
> Chris
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-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.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: AArch64 support and sharing of various drivers

[Christian Mauderer]

Hello Kinsey,

On 01/09/2020 23:56, Kinsey Moore wrote:
> Hi,
> 
> I’ve been working on proper AArch64 support for RTEMS

That's great. It means good raspberry pi 4 support ;-)

> (versus running
> 32-bit ARM RTEMS behind a bootloader or JTAG device that switches the
> CPU to AArch32 mode) and while the vast majority of the architecture
> support code is new, lives in its own aarch64 directories, and is
> unrelated to RTEMS’s ARM support, there are several drivers living in
> the ARM shared directory that are critical to AArch64 support and many
> more that could potentially be shared. Given the limited scope of
> initial bringup on Qemu, that list is currently: GICv3, GPT(timer), and
> PL011(uart). I don’t really see a precedent for this type of sharing
> other than the global bsps/shared and bsps/include directories. The
> global shared directories might make sense for the PL011 since it could
> theoretically be used by anything that supports AXI/AMBA, but the GIC
> and GPT drivers rely on ARM system registers to function with both
> AArch32 and AArch64.
> 
>  
> 
> In short, where should the GICv3 and GPT drivers be relocated along with
> their associated headers, if at all?
> 

I might get a similar problem with some drivers shared between some
PowerPC and ARM too (NXP reuses some of the Freescale PowerPC
peripherals in up to date ARM controllers). I think in theory we already
have such drivers that maybe should be shared but are copied or
re-implemented in multiple BSPs instead.

One possibility might would be to add all arm/shared to the aarch64 too.
But that is a bit unclear.

But as long as the drivers compile for every BSP and are removed at link
time they maybe could just be moved to the general shared directory. We
also have other drivers there that are only used on a few BSPs. For
example the drivers in shared/net/* or shared/dev/ide/*

Best regards

Christian

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

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-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.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

[Christian Mauderer]

Hello Niteesh,

On 31/08/2020 08:23, Niteesh G. S. wrote:
> Hello,
> 
> I have submitted the final eval.
> 
> Thank you, everyone, for all the support throughout the project.

Thank you for your work during GSoC 2020.

> Though I couldn't
> get any of my patches merged.

I'm sure we manage to do that soon (as soon as the new build system is
there).

> I expect to spend a lot of time post-GSoC
> to get
> the work merged and contribute even more :).

That would be great. Feel free to continue asking any questions that you
have.

Best regards

Christian

> 
> Thanks,
> Niteesh. 
> On Sun, Aug 30, 2020 at 8:46 PM Gedare Bloom  <mailto:ged...@rtems.org>> wrote:
> 
> looks great
> 
> On Sun, Aug 30, 2020 at 6:55 AM Christian Mauderer
> mailto:o...@c-mauderer.de>> wrote:
> >
> > On 30/08/2020 14:38, Niteesh G. S. wrote:
> > > Hello,
> > >
> > > On Sun, Aug 30, 2020 at 4:12 PM Christian Mauderer
> mailto:o...@c-mauderer.de>
> > > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>> wrote:
> > >
> > >     Hello Niteesh,
> > >
> > >     On 30/08/2020 08:58, Niteesh G. S. wrote:
> > >     > Hello,
> > >     >
> > >     > I have updated the blog to contain the links to the commits
> > >     > instead of the branches. Please have a look again.
> > >     > https://gs-niteesh.github.io/finalreport/
> > >
> > >     >From my point of view, it looks good now. You missed the commit
> > >     with the
> > >     refactored i2c driver:
> > >
> > > Sorry about that. I fixed this.
> > >
> > >   
>  
> https://github.com/gs-niteesh/rtems/commit/be9bd605c40cf7cbcf3f527054fdbab2af39f52a
> > >
> > >     But if you don't have time left it's not a problem if it
> isn't there.
> > >
> > >     The Submission guidelines tell that "It must be easy to
> identify the
> > >     work you have done." From my point of view that was already
> quite clear
> > >     because the commits are all on top of the final branch. But
> Gedare is of
> > >     course right: Linking every commit is a bit more clear.
> > >
> > >
> > >     > And sorry to disturb on the weekend,  but we have only about
> > >     > a day left before the submission deadline, so I request
> > >     > everyone to please take a look and let me know if you would
> > >     > like to change anything.
> > >
> > >     No problem for disturbing in this case. Don't miss your
> deadline. It's
> > >     better to submit something that is not perfect than not
> submitting
> > >     anything. We would have no possibility to fix a missed
> submission.
> > >
> > >
> > > I have to submit it before tomorrow 11:30 PM IST. I'll leave it
> tonight
> > > for others to comment and will fill it tomorrow morning.
> >
> > Be really careful to not miss a deadline. Again: We have no chance of
> > fixing a missed deadline.
> >
> > Best regards
> >
> > Christian
> >
> > >
> > > Thanks,
> > > Niteesh.
> > >
> > >
> > >     Best regards
> > >
> > >     Christian
> > >
> > >     >
> > >     > Thanks,
> > >     > Niteesh.
> > >     >
> > >     > On Sun, Aug 30, 2020 at 2:24 AM Gedare Bloom
> mailto:ged...@rtems.org>
> > >     <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>
> > >     > <mailto:ged...@rtems.org <mailto:ged...@rtems.org>
> <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>>> wrote:
> > >     >
> > >     >     On Sat, Aug 29, 2020 at 8:31 AM Christian Mauderer
> > >     >     mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>
> > >     <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>>> wrote:
> > >     >     >
> > >     >     >
> > >     >     >
> > >     >     > On 29/08/2020

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

[Christian Mauderer]

On 30/08/2020 14:38, Niteesh G. S. wrote:
> Hello,
> 
> On Sun, Aug 30, 2020 at 4:12 PM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> Hello Niteesh,
> 
> On 30/08/2020 08:58, Niteesh G. S. wrote:
> > Hello,
> >
> > I have updated the blog to contain the links to the commits
> > instead of the branches. Please have a look again.
> > https://gs-niteesh.github.io/finalreport/
> 
> >From my point of view, it looks good now. You missed the commit
> with the
> refactored i2c driver:
> 
> Sorry about that. I fixed this. 
> 
> 
> https://github.com/gs-niteesh/rtems/commit/be9bd605c40cf7cbcf3f527054fdbab2af39f52a
> 
> But if you don't have time left it's not a problem if it isn't there.
> 
> The Submission guidelines tell that "It must be easy to identify the
> work you have done." From my point of view that was already quite clear
> because the commits are all on top of the final branch. But Gedare is of
> course right: Linking every commit is a bit more clear.
> 
> 
> > And sorry to disturb on the weekend,  but we have only about
> > a day left before the submission deadline, so I request
> > everyone to please take a look and let me know if you would
> > like to change anything.
> 
> No problem for disturbing in this case. Don't miss your deadline. It's
> better to submit something that is not perfect than not submitting
> anything. We would have no possibility to fix a missed submission.
> 
> 
> I have to submit it before tomorrow 11:30 PM IST. I'll leave it tonight
> for others to comment and will fill it tomorrow morning.

Be really careful to not miss a deadline. Again: We have no chance of
fixing a missed deadline.

Best regards

Christian

> 
> Thanks,
> Niteesh.
> 
> 
> Best regards
> 
> Christian
> 
> >
> > Thanks,
> > Niteesh.
> >
> > On Sun, Aug 30, 2020 at 2:24 AM Gedare Bloom  <mailto:ged...@rtems.org>
> > <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>> wrote:
> >
> >     On Sat, Aug 29, 2020 at 8:31 AM Christian Mauderer
>     >     mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>> wrote:
> >     >
> >     >
> >     >
> >     > On 29/08/2020 15:04, Niteesh G. S. wrote:
> >     > > Hello,
> >     > > On Sat, Aug 29, 2020 at 2:54 PM Christian Mauderer
> >     mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>
> >     > > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>>> wrote:
> >     > >
> >     > >     Hello Niteesh
> >     > >
> >     > >     On 29/08/2020 11:22, Niteesh G. S. wrote:
> >     > >     > On Sat, Aug 29, 2020 at 1:02 PM Christian Mauderer
> >     > >     mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>
> >     <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>>
> >     > >     > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>
> >     <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>>>> wrote:
> >     > >     >
> >     > >     >     On 29/08/2020 05:57, Niteesh G. S. wrote:
> >     > >     >     > On Sat, Aug 29, 2020 at 4:19 AM Gedare Bloom
> >     > >     mailto:ged...@rtems.org>
> <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>
> >     <mailto:ged...@rtems.org <mailto:ged...@rtems.org>
> <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>>
> >     > >     >     <mailto:ged...@rtems.org
> <mailto:ged...@rtems.org> <mailto:ged...@rtems.org
> <mailto:ged...@rtems.org>>
> >     <mailto:ged...@rtems.org <mailto:ged...@rtems.org>
> <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>>>
> >     > >     >     > <mailto:ged...@rtems.org
> <mailto:ged...@rtems.org> <mailto:ged...@rtems.org
&g

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

[Christian Mauderer]

Hello Niteesh,

On 30/08/2020 08:58, Niteesh G. S. wrote:
> Hello,
> 
> I have updated the blog to contain the links to the commits
> instead of the branches. Please have a look again.
> https://gs-niteesh.github.io/finalreport/

From my point of view, it looks good now. You missed the commit with the
refactored i2c driver:

https://github.com/gs-niteesh/rtems/commit/be9bd605c40cf7cbcf3f527054fdbab2af39f52a

But if you don't have time left it's not a problem if it isn't there.

The Submission guidelines tell that "It must be easy to identify the
work you have done." From my point of view that was already quite clear
because the commits are all on top of the final branch. But Gedare is of
course right: Linking every commit is a bit more clear.

> 
> And sorry to disturb on the weekend,  but we have only about
> a day left before the submission deadline, so I request
> everyone to please take a look and let me know if you would
> like to change anything.

No problem for disturbing in this case. Don't miss your deadline. It's
better to submit something that is not perfect than not submitting
anything. We would have no possibility to fix a missed submission.

Best regards

Christian

> 
> Thanks,
> Niteesh.
> 
> On Sun, Aug 30, 2020 at 2:24 AM Gedare Bloom  <mailto:ged...@rtems.org>> wrote:
> 
> On Sat, Aug 29, 2020 at 8:31 AM Christian Mauderer
> mailto:o...@c-mauderer.de>> wrote:
> >
> >
> >
> > On 29/08/2020 15:04, Niteesh G. S. wrote:
> > > Hello,
> > > On Sat, Aug 29, 2020 at 2:54 PM Christian Mauderer
> mailto:o...@c-mauderer.de>
> > > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>> wrote:
> > >
> > >     Hello Niteesh
> > >
> > >     On 29/08/2020 11:22, Niteesh G. S. wrote:
> > >     > On Sat, Aug 29, 2020 at 1:02 PM Christian Mauderer
> > >     mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>
> > >     > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>
> <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>>> wrote:
> > >     >
> > >     >     On 29/08/2020 05:57, Niteesh G. S. wrote:
> > >     >     > On Sat, Aug 29, 2020 at 4:19 AM Gedare Bloom
> > >     mailto:ged...@rtems.org>
> <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>
> > >     >     <mailto:ged...@rtems.org <mailto:ged...@rtems.org>
> <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>>
> > >     >     > <mailto:ged...@rtems.org <mailto:ged...@rtems.org>
> <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>
> > >     <mailto:ged...@rtems.org <mailto:ged...@rtems.org>
> <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>>>> wrote:
> > >     >     >
> > >     >     >     Are "Links to commits" 1-4 all the code you (are
> > >     claiming you)
> > >     >     wrote?
> > >     >     >     I just want to make sure. It looks fine to me.
> > >     >     >
> > >     >     > Yes, all the code in the commits is written by me.
> > >     >
> > >     >     I think maybe "Links to branches" would be a better
> title. It
> > >     is not a
> > >     >     single commit each but a few commits. Alternative
> would be to
> > >     add links
> > >     >     to each commit.
> > >     >
> > >     >
> > >     > I have changed the title to "Links to branches". Should I
> also add
> > >     links
> > >     > to the commits that were made in each phase at the end of the
> > >     summary of
> > >     > each phase?
> > >     >
> > >
> > >     If you want, you can do that.
> > >
> > >
> > > I did try that but it didn't work out well, especially with the
> OFW commit.
> > > Since I don't have the old commit I either had to leave that
> commit out
> > > in the first phase or I had to post the newer commit in the
> first phase
> > > itself which actually should in the last phase. So I decided to
> avoid adding
> > > the commits and just leave it out with the branches.
> >
> > That's OK too. Like I said: Mai

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

[Christian Mauderer]

On 29/08/2020 15:04, Niteesh G. S. wrote:
> Hello,
> On Sat, Aug 29, 2020 at 2:54 PM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> Hello Niteesh
> 
> On 29/08/2020 11:22, Niteesh G. S. wrote:
> > On Sat, Aug 29, 2020 at 1:02 PM Christian Mauderer
> mailto:o...@c-mauderer.de>
> > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>> wrote:
> >
> >     On 29/08/2020 05:57, Niteesh G. S. wrote:
> >     > On Sat, Aug 29, 2020 at 4:19 AM Gedare Bloom
> mailto:ged...@rtems.org>
> >     <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>
> >     > <mailto:ged...@rtems.org <mailto:ged...@rtems.org>
> <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>>> wrote:
> >     >
> >     >     Are "Links to commits" 1-4 all the code you (are
> claiming you)
> >     wrote?
> >     >     I just want to make sure. It looks fine to me.
> >     >
> >     > Yes, all the code in the commits is written by me.
> >
> >     I think maybe "Links to branches" would be a better title. It
> is not a
> >     single commit each but a few commits. Alternative would be to
> add links
> >     to each commit.
> >
> >
> > I have changed the title to "Links to branches". Should I also add
> links
> > to the commits that were made in each phase at the end of the
> summary of
> > each phase?
> >  
> 
> If you want, you can do that.
> 
> 
> I did try that but it didn't work out well, especially with the OFW commit.
> Since I don't have the old commit I either had to leave that commit out
> in the first phase or I had to post the newer commit in the first phase
> itself which actually should in the last phase. So I decided to avoid adding
> the commits and just leave it out with the branches.

That's OK too. Like I said: Main target was that it's clear that you
don't have four commits but a bit more.

> 
> 
> The main point of that change was to highlight that it's not 4 commits
> but a bit more.
> 
> >
> >      
> >
> >
> >     It has been quite a bit of back and forth during this GSoC
> project so I
> >     think the result is quite OK.
> >
> >     Best regards
> >
> >     Christian
> >
> >     >
> >     >     On Fri, Aug 28, 2020 at 12:07 PM Niteesh G. S.
> >     mailto:niteesh...@gmail.com>
> <mailto:niteesh...@gmail.com <mailto:niteesh...@gmail.com>>
> >     >     <mailto:niteesh...@gmail.com
> <mailto:niteesh...@gmail.com> <mailto:niteesh...@gmail.com
> <mailto:niteesh...@gmail.com>>>>
> >     wrote:
> >     >     >
> >     >     > Hello,
> >     >     >
> >     >     > I have prepared my final report for my project. You
> can have a
> >     >     look at it
> >     >     > here https://gs-niteesh.github.io/finalreport/. Please
> kindly
> >     >     review the report.
> >     >     >
> >     >     > Thanks,
> >     >     > Niteesh.
> >     >
> >     >
> >     > ___
> >     > devel mailing list
> >     > devel@rtems.org <mailto:devel@rtems.org>
> <mailto:devel@rtems.org <mailto:devel@rtems.org>>
> >     > http://lists.rtems.org/mailman/listinfo/devel
> >     >
> >
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

[Christian Mauderer]

Hello Niteesh

On 29/08/2020 11:22, Niteesh G. S. wrote:
> On Sat, Aug 29, 2020 at 1:02 PM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> On 29/08/2020 05:57, Niteesh G. S. wrote:
> > On Sat, Aug 29, 2020 at 4:19 AM Gedare Bloom  <mailto:ged...@rtems.org>
> > <mailto:ged...@rtems.org <mailto:ged...@rtems.org>>> wrote:
> >
> >     Are "Links to commits" 1-4 all the code you (are claiming you)
> wrote?
> >     I just want to make sure. It looks fine to me.
> >
> > Yes, all the code in the commits is written by me.
> 
> I think maybe "Links to branches" would be a better title. It is not a
> single commit each but a few commits. Alternative would be to add links
> to each commit.
> 
> 
> I have changed the title to "Links to branches". Should I also add links
> to the commits that were made in each phase at the end of the summary of
> each phase?
>  

If you want, you can do that.

The main point of that change was to highlight that it's not 4 commits
but a bit more.

> 
>  
> 
> 
> It has been quite a bit of back and forth during this GSoC project so I
> think the result is quite OK.
> 
> Best regards
> 
> Christian
> 
> >
> >     On Fri, Aug 28, 2020 at 12:07 PM Niteesh G. S.
> mailto:niteesh...@gmail.com>
> >     <mailto:niteesh...@gmail.com <mailto:niteesh...@gmail.com>>>
> wrote:
> >     >
> >     > Hello,
> >     >
> >     > I have prepared my final report for my project. You can have a
> >     look at it
> >     > here https://gs-niteesh.github.io/finalreport/. Please kindly
> >     review the report.
> >     >
> >     > Thanks,
> >     > Niteesh.
> >
> >
> > ___
> > devel mailing list
> > devel@rtems.org <mailto:devel@rtems.org>
> > http://lists.rtems.org/mailman/listinfo/devel
> >
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: GSoC 2020: Final Report (Beagle BSP: Add FDT based initialization)

[Christian Mauderer]

On 29/08/2020 05:57, Niteesh G. S. wrote:
> On Sat, Aug 29, 2020 at 4:19 AM Gedare Bloom  > wrote:
> 
> Are "Links to commits" 1-4 all the code you (are claiming you) wrote?
> I just want to make sure. It looks fine to me.
> 
> Yes, all the code in the commits is written by me.

I think maybe "Links to branches" would be a better title. It is not a
single commit each but a few commits. Alternative would be to add links
to each commit.

It has been quite a bit of back and forth during this GSoC project so I
think the result is quite OK.

Best regards

Christian

> 
> On Fri, Aug 28, 2020 at 12:07 PM Niteesh G. S.  > wrote:
> >
> > Hello,
> >
> > I have prepared my final report for my project. You can have a
> look at it
> > here https://gs-niteesh.github.io/finalreport/. Please kindly
> review the report.
> >
> > Thanks,
> > Niteesh.
> 
> 
> ___
> 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: Announce: RTEMS 5.1 Release

[Christian Mauderer]

On 26/08/2020 07:45, Chris Johns wrote:
> On 26/8/20 3:09 pm, me wrote:
>>> On 26/08/2020, at 1:04 PM, Chris Johns  wrote:
>>> Yes the plan is to have the waf build system in the RTEMS 6 release.
>> Cool, could you point me to a link of the RTEMS 6?
> 
> https://devel.rtems.org/wiki/Release/6
> 
> The waf build system is still under development in Sebastian's personal repo 
> ...
> 
> https://git.rtems.org/sebh/rtems.git/?h=build-2
> 
> It is either the build or build-2 branch. I am sorry I do not know which it 
> is.
> 
> Chris

You might also want to have a look at the new manuals. Sebastian has a
temporary version here:

https://ftp.rtems.org/pub/rtems/people/sebh/eng.pdf

https://ftp.rtems.org/pub/rtems/people/sebh/user.pdf
-- 
----
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-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.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps/shared/ofw: Implement RTEMS OFW interface

[Christian Mauderer]

On 18/08/2020 19:01, Niteesh G. S. wrote:
> 
> 
> On Tue, Aug 18, 2020 at 8:26 PM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> On 18/08/2020 11:25, Niteesh G. S. wrote:
> > How can we make this API FreeBSD compatible? We have to declare
> > defines for the OFW functions
> > Eg. #define OF_finddevice rtems_ofw_find_device
> 
> I think that was the plan, wasn't it?
> 
>  
> Is everyone OK with this? I am going to start working on it. I would like to
> get at least one of my patches merge readybefore GSoC ends. 

From the current timeframe I'm not sure whether the new build system is
ready till then. So for a merge we will need a backport. Sorry for that.
I expected the new build system to be integrated earlier. On the other
hand it shouldn't be too much work. Basically it means adding the two
sources into a file of the old build system instead of the new one.

> My other patches are somewhat dependent on this patch so I want to get
> this fixed first.
> 
> I also have a few questions now. If we do this change in libBSD and what
> about the imported drivers present in RTEMS? They have to define these
> translations locally in the driver itself. Or we should move openfirm.h into
> RTEMS. Both have their own problems. The first one will create a lot of
> redundant code And the second one has the following problems.
> 
> 1) Where to place openfirm.h in RTEMS?
> 2)  What about functions like OF_device_from_xref etc?
> These functions depend on the libBSD device struct one hack is to forward
> declare these in the openfirm.h implemented in RTEMS. Is everyone OK
> with this or is there any better solution to this?
> 3) We also modify the interface is that fine with BSD-4 license?
> 

There is a third possibility: You can place these defines in a header
(e.g. openfirm_compat.h) and include that in libbsds openfirm.h and in
the ported RTEMS drivers.

> 
> >
> > Should I change the openfirm.h in libBSD to this use these defines
> instead
> > of calling the functions in openfirm.c? Though there are some
> > functions which
> > for which this cannot be done.
> > Eg: OF_device_from_xref
> > For this, we will have to use the implementation present in openfirm.c
> 
> At least as long as no one implements a replacement, yes.
> 
> >
> >
> > On Tue, Aug 18, 2020 at 7:57 AM Chris Johns  <mailto:chr...@rtems.org>
> > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>> wrote:
> >
> >     On 17/8/20 2:57 pm, Niteesh G. S. wrote:
> >     > On Mon, Aug 17, 2020 at 3:49 AM Chris Johns
> mailto:chr...@rtems.org>
> >     <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>
> >     > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>
> <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>>> wrote:
> >     >
> >     >     On 16/8/20 11:19 pm, Niteesh G. S. wrote:
> >     >     >
> >     >     > On Sun, Aug 16, 2020 at 2:25 PM Chris Johns
> >     mailto:chr...@rtems.org>
> <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>
> >     >     <mailto:chr...@rtems.org <mailto:chr...@rtems.org>
> <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>>
> >     >     > <mailto:chr...@rtems.org <mailto:chr...@rtems.org>
> <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>
> >     <mailto:chr...@rtems.org <mailto:chr...@rtems.org>
> <mailto:chr...@rtems.org <mailto:chr...@rtems.org>>>>> wrote:
> >     >     >
> >     >     >     On 16/8/20 4:49 am, G S Niteesh Babu wrote:
> >     >     >     > ---
> >     >     >
> >     >     >     > +
> >     >     >     > +#ifdef HAVE_CONFIG_H
> >     >     >     > +#include "config.h"
> >     >     >     > +#endif
> >     >     >     > +
> >     >     >     > +#include 
> >     >     >     > +#include 
> >     >     >     > +#include 
> >     >     >     > +#include 
> >     >     >     > +#include 
> >     >     >     > +#include 
> >     >     >     > +
> >     >     >     > +const void *fdtp = NULL;
> >     >     >     > +
> >     >     >     > +static phandle_t rtems_fdt_offset_to_phandle( int
>  

Re: [PATCH] bsps/shared/ofw: Implement RTEMS OFW interface

[Christian Mauderer]

On 18/08/2020 11:25, Niteesh G. S. wrote:
> How can we make this API FreeBSD compatible? We have to declare
> defines for the OFW functions
> Eg. #define OF_finddevice rtems_ofw_find_device

I think that was the plan, wasn't it?

> 
> Should I change the openfirm.h in libBSD to this use these defines instead
> of calling the functions in openfirm.c? Though there are some
> functions which
> for which this cannot be done.
> Eg: OF_device_from_xref
> For this, we will have to use the implementation present in openfirm.c

At least as long as no one implements a replacement, yes.

> 
> 
> On Tue, Aug 18, 2020 at 7:57 AM Chris Johns  > wrote:
> 
> On 17/8/20 2:57 pm, Niteesh G. S. wrote:
> > On Mon, Aug 17, 2020 at 3:49 AM Chris Johns  
> > >> wrote:
> >
> >     On 16/8/20 11:19 pm, Niteesh G. S. wrote:
> >     >
> >     > On Sun, Aug 16, 2020 at 2:25 PM Chris Johns
> mailto:chr...@rtems.org>
> >     >
> >     > 
>  >     >
> >     >     On 16/8/20 4:49 am, G S Niteesh Babu wrote:
> >     >     > ---
> >     >
> >     >     > +
> >     >     > +#ifdef HAVE_CONFIG_H
> >     >     > +#include "config.h"
> >     >     > +#endif
> >     >     > +
> >     >     > +#include 
> >     >     > +#include 
> >     >     > +#include 
> >     >     > +#include 
> >     >     > +#include 
> >     >     > +#include 
> >     >     > +
> >     >     > +const void *fdtp = NULL;
> >     >     > +
> >     >     > +static phandle_t rtems_fdt_offset_to_phandle( int
> offset )
> >     >     > +{
> >     >     > +  if (offset < 0) {
> >     >     > +    return 0;
> >     >     > +  }
> >     >     > +
> >     >     > +  return (phandle_t)offset + fdt_off_dt_struct(fdtp);
> >     >     > +}
> >     >     > +
> >     >     > +static int rtems_fdt_phandle_to_offset( phandle_t
> handle )
> >     >     > +{
> >     >     > +  int off;
> >     >     > +  int fdt_off;
> >     >     > +
> >     >     > +  off = (int) handle;
> >     >     > +  fdt_off = fdt_off_dt_struct(fdtp);
> >     >     > +
> >     >     > +  if (off < fdt_off) {
> >     >     > +    return -1;
> >     >     > +
> >     >     > +  }
> >     >     > +
> >     >     > +  return off - fdt_off;
> >     >     > +}
> >     >     > +
> >     >     > +static void rtems_ofw_init( void ) {
> >     >     > +  int rv;
> >     >     > +  const void *fdt;
> >     >     > + 
> >     >     > +  fdt = bsp_fdt_get();
> >     >     > +
> >     >     > +  rv = fdt_check_header(fdt);
> >     >     > +
> >     >     > +  /*
> >     >     > +   * Is assert a good option to handle error?
> >     >     > +   * AFIAK there is no other way to recover from
> invalid FDT.
> >     >     > +   * On providing an invalid FDT most driver's will
> fail/crash anyway.
> >     >     > +   */
> >     >
> >     >     If you want to fail with an error I suggest a documented
> internal error. I
> >     >     however would prefer we fail in degraded manner but I
> understand this
> >     may not be
> >     >     possible.
> >     >
> >     >
> >     > During the initial discussion, we discussed adding a new
> error code in
> >     case of an
> >     > invalid FDT, something like BSP_INVALID_FDT. I had also sent
> a patch but
> >     then we
> >     > decided not to add one(for some reason that I don't
> remember). Instead, use
> >     > RTEMS_NOT_CONFIGURED. This has also been used in my previous
> OFW patch.
> >
> >     I am sorry I missed the discussion or I would have commented.
> Currently the FDT
> >     support in RTEMS is hostile. If you build a u-boot image and
> forget to add FDT
> >     support added you get a low level crash dump and that is
> unfriendly. I woud like
> >     to this changed.
> >
> > So should we add a proper fatal code in case of invalid FDT or FDT
> is not provided?
> > ARM, POWERPC and RISCV are the only architectures in RTEMS that
> use FDT.
> > Can we add an FDT check inside start.S before bsp_fdt_copy? and
> fail properly in
> > case of an invalid FDT.
> > Or is it a better idea to add the check inside bsp_fdt_copy but
> bsp_fdt_copy is
> > optional
> > in architectures like ARM, RISCV it is compile time guarded with
> > BSP_START_COPY_FDT_FROM_UBOOT
> 
> The crash only happens when you run libbsd so I feel the issue is in
> there. If
> support has been added to libbsd 

Re: RTEMS 5 on the start page of RTEMS.org

[Christian Mauderer]

Hello Joel,

I noted that we already have RC2 for 5.1. So most likely it's better to
wait for 5.1. Otherwise it's double work.

On 08/08/2020 18:17, Joel Sherrill wrote:
> 
> 
> On Sat, Aug 8, 2020, 10:56 AM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> Hello Joel,
> 
> On 08/08/2020 17:51, Joel Sherrill wrote:
> >
> >
>     > On Sat, Aug 8, 2020, 10:38 AM Christian Mauderer
> mailto:o...@c-mauderer.de>
> > <mailto:o...@c-mauderer.de <mailto:o...@c-mauderer.de>>> wrote:
> >
> >     Hello,
> >
> >     I noted that on the start page of www.rtems.org
> <http://www.rtems.org>
> >     <http://www.rtems.org>, there are still a lot
> >     of outdated references to the last release. One of the most
> obvious is
> >     the Documentation section on the right and the "Release and Active
> >     Development" section.
> >
> >     I don't think that our home page is in a git repo so that I
> could send a
> >     patch?
> >
> >
> > That would be nice but it isn't the way it is now. It is in Drupal
> now.
> > Personally I have decided an active CMS is too heavy for many
> websites.
> >
> > Hugo looks like a decent way for us to go as best I can tell. It is a
> > static site generator with lots of themes. But it takes work.
> >
> 
> I worked a bit with Hugo on some other pages. It's a nice system.
> 
> 
> As long as you have Go. :)

Right. That's a prerequisite.

If you start something with a static site generator: Tell me if I can
help with something.


Best regards

Christian

> 
> 
> >
> >
> >     Who would be able to update the links?
> >
> >
> > Me for one. Please file a ticket with specific changes and I will make
> > them. Please please please don't make me find everything and the right
> > destination. It is tedious enough executing the changes.
> 
> I'll try to find most locations in the next days. What format would be
> the best one for you? A screenshot with marked locations?
> 
> 
> You can do a text file if you want. Just name the box on the front page,
> text and link to change and new destination.
> 
> Usually they are easy to locate. 
> 
> Community > Mailing Lists should be new url
> 
> Probably will work for most.
> 
> If in text, just try. :)
> 
> --joel
> 
> 
> 
> 
> Best regards
> 
> Christian
> 
> >
> > --joel
> >
> >
> >     Best regards
> >
> >     Christian
> >     ___
> >     devel mailing list
> >     devel@rtems.org <mailto:devel@rtems.org>
> <mailto:devel@rtems.org <mailto: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] bsps/shared/ofw: Added and Documented RTEMS OFW interface

[Christian Mauderer]

s
> needed but it will make the API uniform.
>  

That will also make the API future proof. If someone somewhen decides to
change the implementation, the user already uses "rtems_ofw_prop_free"
instead of a plain "free" everywhere.

> 
> > + *
> > + * @retval  -1 Property is not found.
> > + * @retval   Number of values read.
> > + */
> > +size_t rtems_ofw_getencprop_alloc_multi(
> > +  phandle_t     node,
> > +  const char   *propname,
> > +  int           elsz,
> > +  void        **buf
> > +);
> > +
> > +/**
> > + * @brief Free's the buffers allocated by the rtems_ofw_*_alloc
> functions.
> > + *
> > + * @param[in] buf Buffer to be freed
> > + */
> > +void rtems_ofw_prop_free(
> > +  void   *buf
> > +);
> > +
> > +/**
> > + * @brief Finds the next property of @a node.
> > + *
> > + * Finds the next property of the node and when @a propname is
> NULL it returns
> > + * the value in the first property.
> > + *
> > + * @param[in] node Node offset
> > + * @param[in] propname Property name
> > + * @param[out] buf The value of the next property gets stored in
> this buffer
> > + * (Pre-allocated)
> > + * @param[in] len Length of the buffer
> > + *
> > + * @retval  -1 node or previous property does not exist
> > + * @retval   0 no more properties
> > + * @retval   1 success
> > + */
> > +int rtems_ofw_nextprop(
> > +  phandle_t    node,
> > +  const char  *propname,
> > +  char        *buf,
> > +  size_t       len
> > +);
> > +
> > +/**
> > + * @brief Sets the property @name of @a node to @a buf.
> > + *
> > + * @param[in] node Node offset
> > + * @param[in] name Property name
> > + * @param[in] buf Buffer containes the value to be set.
> typo; contains
> 
> Fixed. 
> 
> > + * @param[in] len Length of the buffer
> > + *
> > + * @retval  -1 node does not exist
> > + * @retval   0 on success
> > + * @retval   libFDT error codes on unsuccessful setting operation
> > + */
> > +int rtems_ofw_setprop(
> > +  phandle_t    node,
> > +  const char  *name,
> > +  const void  *buf,
> > +  size_t       len
> > +);
> > +
> > +/**
> > + * @brief Converts a device specifier to a fully qualified path name.
> > + *
> > + * @param[in] dev device specifier
> > + * @param[out] buf The path is filled into the buffer(Pre-allocated)
> > + * @param[in] length of the buffer
> > + *
> > + * @retval  -1 always. Unimplemented.
> > + */
> > +size_t rtems_ofw_canon(
> > +  const char  *dev,
> > +  char        *buf,
> > +  size_t       len
> > +);
> > +
> > +/**
> > + * @brief Finds the node at the given path
> > + *
> > + * @param[in] path to the node from root
> > + *
> > + * @retval  -1 node does not exist
> > + * @retval   node handle on success
> > + */
> > +phandle_t rtems_ofw_finddevice(
> > +  const char  *path
> > +);
> > +
> > +/**
> > + * @brief This routine converts effective phandle of @a node to
> node offset.
> @a xref?
> 
> Fixed. 
> 
> > + *
> > + * @param[in] xref Node phandle
> > + *
> > + * @retval Node offset on success
> > + * @retval Node phandle on failure
> > + */
> > +phandle_t rtems_ofw_node_from_xref(
> > +  phandle_t   xref
> > +);
> > +
> > +/**
> > + * @brief This routine converts node offset to effective phandle
> of @a node.
> > + *
> > + * @retval Node phandle on success
> > + * @retval Node offset on failure
> > + */
> > +phandle_t rtems_ofw_xref_from_node(
> > +  phandle_t   node
> > +);
> > +
> > +/*
> > + * instance handles(ihandle_t) as same as phandles in the FDT
> implementation
> > + * of OF interface.
> > + */
> stray comments?
> 
> 
> I'll add these comments to the type's documentation above.
> 
> I also wanted to add a few other functions that are nor part
> of the OF interface but would be really beneficial for RTEMS.
> 

Maybe make clear in the description that these don't have a mapping that
matches FreeBSD's OFW interface.

> Can I add the following functions?
> 1) rtems_ofw_get_reg
> 2) rtems_ofw_status_okay
> 3) rtems_ofw_get_interrupts
> 
> Since these functions are not part of OFW should I use FDT
> instead of OFW in the function names?
> eg: rtems_fdt_get_reg

Be carefull with "rtems_fdt". There is already a wrapper for libfdt with
these prefixes in cpukit/libmisc/rtems-fdt/rtems-fdt.c. And if you use
the types from this file, you should keep the prefix as "rtems_ofw".

Best regards

Christian

> 
> > +
> > +/**
> > + * @brief Converts @a instance handle to phandle.
> > + *
> > + * instance are same as node offsets in FDT.
> > + *
> > + * @param[in] instance Node offset
> > + *
> > + * @retval phandle of node on success.
> > + * @retval instance of node on failure.
> > + */
> > +phandle_t rtems_ofw_instance_to_package(
> > +  ihandle_t   instance
> > +);
> > +
> > +/**
> > + * @brief Find the node's path from phandle.
> > + *
> > + * @param[in] node Node offset
> > + * @param[out] buf Path is filled into this buffer(Pre-allocated).
> > + * @param[in] len Length of the buffer.
> > + *
> > + * @retval -1 always. Unimplemented.
> > + */
> > +size_t rtems_ofw_package_to_path(
> > +  phandle_t   node,
> > +  char       *buf,
> > +  size_t      len
> > +);
> > +
> > +/**
> > + * @brief Find the node's path from ihandle.
> > + *
> > + * @param[in] instance Node offset
> > + * @param[out] buf Path is filled into this buffer(Pre-allocated).
> > + * @param[in] len Length of the buffer.
> > + *
> > + * @retval -1 always. Unimplemented.
> > + */
> > +size_t rtems_ofw_instance_to_path(
> > +  ihandle_t  instance,
> > +  char      *buf,
> > +  size_t     len
> > +);
> > +
> > +#ifdef __cplusplus
> > +}
> > +#endif
> > +
> > +#endif /* _OFW_H */
> > \ No newline at end of file
> > --
> > 2.17.1
> >
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-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.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: RTEMS 5 on the start page of RTEMS.org

[Christian Mauderer]

Hello Joel,

On 08/08/2020 17:51, Joel Sherrill wrote:
> 
> 
> On Sat, Aug 8, 2020, 10:38 AM Christian Mauderer  <mailto:o...@c-mauderer.de>> wrote:
> 
> Hello,
> 
> I noted that on the start page of www.rtems.org
> <http://www.rtems.org>, there are still a lot
> of outdated references to the last release. One of the most obvious is
> the Documentation section on the right and the "Release and Active
> Development" section.
> 
> I don't think that our home page is in a git repo so that I could send a
> patch? 
> 
> 
> That would be nice but it isn't the way it is now. It is in Drupal now.
> Personally I have decided an active CMS is too heavy for many websites.
> 
> Hugo looks like a decent way for us to go as best I can tell. It is a
> static site generator with lots of themes. But it takes work.
> 

I worked a bit with Hugo on some other pages. It's a nice system.

> 
> 
> Who would be able to update the links?
> 
> 
> Me for one. Please file a ticket with specific changes and I will make
> them. Please please please don't make me find everything and the right
> destination. It is tedious enough executing the changes.

I'll try to find most locations in the next days. What format would be
the best one for you? A screenshot with marked locations?

Best regards

Christian

> 
> --joel
> 
> 
> Best regards
> 
> Christian
> ___
> devel mailing list
> devel@rtems.org <mailto:devel@rtems.org>
> http://lists.rtems.org/mailman/listinfo/devel
> 
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

RTEMS 5 on the start page of RTEMS.org

[Christian Mauderer]

Hello,

I noted that on the start page of www.rtems.org, there are still a lot
of outdated references to the last release. One of the most obvious is
the Documentation section on the right and the "Release and Active
Development" section.

I don't think that our home page is in a git repo so that I could send a
patch? Who would be able to update the links?

Best regards

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

Xilinx Zynq BSP and SD/eMMC

[Christian Mauderer]

Hello,

is someone using the Xilinx Zynq BSP (xilinx_zynq_zedboard to be exact)
with a SD driver? I didn't find one in libbsd for that BSP.

Best regards

Christian
-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-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.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH RTEMS 7/7] libtests/openfirmware: Added a testsuite for openfirmware

[Christian Mauderer]

Hello,

I think the big question is: Should we make that a public API and keep
it in cpukit or should we make it a BSP support code and move ti to the
bsps/shared section?

Sebastian and Gedare: Like Niteesh said: There have been some different
directions in the past. Which one should be the target?

Best regards

Christian

On 04/08/2020 20:36, Niteesh G. S. wrote:
> Ping.
> 
> On Sun, Aug 2, 2020 at 2:44 PM Niteesh G. S.  <mailto:niteesh...@gmail.com>> wrote:
> 
> Hello,
> 
> I went through some of my previous conversations to summarize the
> various directories
> suggested by people. Maybe this will help to come up with a conclusion.
> 
> In my first porting commit, I placed the files under
> cpukit/libfreebsd this caused issues like
> accessing BSP dependent functions like bsp_fdt_get() therefore
> Christian suggested moving
> the files to bsps/shared.
> https://lists.rtems.org/pipermail/devel/2020-May/059959.html
> I then posted the patches on the mailing lists after moving the
> files to bsps/shared. After this
> Sebastian suggested moving these back to cpukit since they are BSP
> independent. And add
> an API to register FDTs since this would allow for unit testing. But
> later instead of API we
> started using linker wrappers.
> https://lists.rtems.org/pipermail/devel/2020-May/059978.html
> https://lists.rtems.org/pipermail/devel/2020-June/060025.html
> Gedare also suggested having the files in cpukit since this would
> allow for easier synchronization
> with FreeBSD.
> https://lists.rtems.org/pipermail/devel/2020-May/059807.html
> 
> Thanks,
> Niteesh.
> 
> On Thu, Jul 30, 2020 at 1:03 AM Gedare Bloom  <mailto:ged...@rtems.org>> wrote:
> 
> On Wed, Jul 29, 2020 at 12:33 PM Christian Mauderer
> mailto:o...@c-mauderer.de>> wrote:
>     >
> >
> >
> > On 29/07/2020 20:21, Gedare Bloom wrote:
> > > On Wed, Jul 29, 2020 at 12:10 PM Christian Mauderer
>     mailto:o...@c-mauderer.de>> wrote:
> > >>
> > >> On 29/07/2020 19:55, Gedare Bloom wrote:
> > >>> On Wed, Jul 29, 2020 at 10:44 AM Christian Mauderer
> mailto:o...@c-mauderer.de>> wrote:
> > >>>>
> > >>>> On 29/07/2020 18:07, Gedare Bloom wrote:
> > >>>>> On Wed, Jul 15, 2020 at 12:32 AM G S Niteesh Babu
> mailto:niteesh...@gmail.com>> wrote:
> > >>>>>>
> > >>>>>> ---
> > >>>>>>  spec/build/testsuites/libtests/grp.yml        |   3 +
> > >>>>>>  .../testsuites/libtests/openfirmware01.yml    |  20 +++
> > >>>>>>  testsuites/libtests/openfirmware01/init.c     | 147
> ++
> > >>>>>>  .../openfirmware01/openfirmware01.doc         |  29 
> > >>>>>>  .../openfirmware01/openfirmware01.scn         |   2 +
> > >>>>>>  testsuites/libtests/openfirmware01/some.c     |  52
> +++
> > >>>>>>  testsuites/libtests/openfirmware01/some.dts   |  54
> +++
> > >>>>>>  testsuites/libtests/openfirmware01/some.h     |  15 ++
> > >>>>>>  8 files changed, 322 insertions(+)
> > >>>>>>  create mode 100644
> spec/build/testsuites/libtests/openfirmware01.yml
> > >>>>>>  create mode 100644
> testsuites/libtests/openfirmware01/init.c
> > >>>>>>  create mode 100644
> testsuites/libtests/openfirmware01/openfirmware01.doc
> > >>>>>>  create mode 100644
> testsuites/libtests/openfirmware01/openfirmware01.scn
> > >>>>>>  create mode 100644
> testsuites/libtests/openfirmware01/some.c
> > >>>>>>  create mode 100644
> testsuites/libtests/openfirmware01/some.dts
> > >>>>>>  create mode 100644
> testsuites/libtests/openfirmware01/some.h
> > >>>>>>
> > >>>>>> diff --git a/spec/build/testsuites/libtests/grp.yml
> b/spec/build/testsuites/libtests/grp.yml
> > >>>>>> index f1de6cd75f..56e84d2c89 100644
> > >>>>>> --- a/spec/build/testsuites/libtests/grp

Re: GSoC 2020: OFW Import To RTEMS License Issue

[Christian Mauderer]

I think for this one we can only hope that the original author agrees to
a re-licensing. Otherwise it is only possible to add a replacement.

On 04/08/2020 20:34, Niteesh G. S. wrote:
> ping.
> 
> 
> On Sat, Aug 1, 2020 at 2:11 PM Niteesh G. S.  > wrote:
> 
> 
> 
> On Sat, Aug 1, 2020 at 1:37 AM Joel Sherrill  > wrote:
> 
> 
> 
> On Fri, Jul 31, 2020 at 2:16 PM Niteesh G. S.
> mailto:niteesh...@gmail.com>> wrote:
> 
> Hello,
> 
> In a recent review of these patches
> https://lists.rtems.org/pipermail/devel/2020-July/060653.html
> Gedare mentioned that we cannot use these patches with the
> current license. More details regarding the conversation can be
> found in the following archive.
> https://lists.rtems.org/pipermail/devel/2020-July/061000.html
> 
> The following files have been ported to RTEMS to implement
> the OFW API.
> 1) openfirm.h  -- BSD-4 License
> 2) openfirm.c  -- BSD-4 License
> 3) ofw_fdt.c    -- BSD-2 License
> 
> The files with BSD4 cannot be used and Gedare suggested to
> check if we can remove the entire 4-clause cluster or remove
> clauses #3 and #4. I checked this along with the help of
> Christian
> and it seems that we can't remove those. Christian suggested
> that we can use the header file with the BSD-4 license to some
> extent but the source files to pose a problem. We also checked
> OpenBSD it has the same licensing.
> 
> 
> NetBSD appears to be the origin of the code and although I believe 
> they did a largely blanket change from BSD-4, this code is old and
> normally, I would doubt they found the original submitter.  Which 
> would be odd in this case because this is his website with email:
> 
> https://solfrank.net/Wolfgang/  
> 
> I have privately emailed to politely ask him to relicense it to
> BSD-2 
> for use in RTEMS. And try to do that in a way that gets it on a
> path 
> to get changed upstream.
> 
> Hopefully this will solve it.
> 
> 
> Thanks for doing this Joel :).
> 
> 
> 
> So we have come up with the following suggestions
> 1) Use the header files as it is.
> 
> 
> How close are you to being able to merge? Do we have time to let
> him answer?
> 
> 
> Yes, we do have a lot of time. All of my patches are based on the
> new build
> system so we won't be able to merge until the build system is
> merged. And
> also there are other things that have to be discussed regarding the
> patch.
> 
>  
> 
> 2) Most OF_* functions defined in openfirm.c have 1:1 mapping
> with the FDT implementation in ofw_fdt.c so there is a
> possibility
> to remove openfirm.c and only use openfirm.h and ofw_fdt.c.
> For those functions which don't have a 1:1 mapping, we can add
> an implementation in ofw_fdt.c. And remove the functions which
> don't have an FDT based implementation eg. OF_write, OF_open
> etc.
> 
> Also please remember that these patches were created with a goal
> to import the OFW into RTEMS and remove them from libBSD so
> will using the above approach has a chance of breaking libBSD 
> compatibility in the future?
> 
> 
> Yikes. That would mean having to create our own files that are
> compatible but don't have the license issue. 
> 
> And that our implementation is in a source transparent form that
> allows updates easily from the upstream source.
> 
> If we can't get relicense permission, I think we have to rewrite the
> BSD-4 code and provide compatible versions. :(
> 
> 
> As of now, this seems to be the only option but let's hope for someone
> to come up with a better approach or get the license relaxed.
> 
> Thanks,
> Niteesh
>  
> 
> 
> Thanks,
> Niteesh.
> ___
> 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] dosfs: Fix memory leak on failed mounts.

[Christian Mauderer]

Thanks for all Feedback. I integrated the changes suggested by
Sebastian, cretated the tickets and pushed to 5 and master.

Best regards

Christian

On 04/08/2020 07:41, Chris Johns wrote:
> On 4/8/20 2:22 am, Gedare Bloom wrote:
>>
>> a resource leak is a bug worth back-porting, especially with a simple fix.
>>
> 
> Ok to push to the 5 branch with a ticket.
> 
> Thanks
> Chris
> 

-- 
----
embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-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.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems] dosfs: Fix memory leak on failed mounts.

[Christian Mauderer]

Hello Sebastian,

On 03/08/2020 15:57, Sebastian Huber wrote:
> On 03/08/2020 15:16, Christian Mauderer wrote:
> 
>> diff --git a/cpukit/libfs/src/dosfs/msdos_init.c
>> b/cpukit/libfs/src/dosfs/msdos_init.c
>> index dc9c76437d..0649258fa7 100644
>> --- a/cpukit/libfs/src/dosfs/msdos_init.c
>> +++ b/cpukit/libfs/src/dosfs/msdos_init.c
>> @@ -102,10 +102,12 @@ int rtems_dosfs_initialize(
>>   int    rc = 0;
>>   const rtems_dosfs_mount_options   *mount_options = data;
>>   rtems_dosfs_convert_control   *converter;
>> +    bool   converter_created = false;
>>       if (mount_options == NULL || mount_options->converter ==
>> NULL) {
>>   converter = rtems_dosfs_create_default_converter();
>> +    converter_created = true;
>>   } else {
>>   converter = mount_options->converter;
>>   }
>> @@ -116,6 +118,9 @@ int rtems_dosfs_initialize(
>>     _file_handlers,
>>     _dir_handlers,
>>     converter);
>> +    if (rc != 0 && converter_created) {
>> +    converter->handler->destroy(converter);
>> +    }
>>   } else {
>>   errno = ENOMEM;
>>   rc = -1;
> Why can't we destroy the converter in both cases?

In theory we could. But then we have two cases that look the same to a
user but need a different handling:

1. `mount` failed before reaching rtems_dosfs_initialize (for example
because a wrong file system has been provided or a target directory
doesn't exist). In this case the user provided converter would _not_ be
destroyed.

2. `rtems_dosfs_initialize` failed and the converter is already destroyed.

In the first case the user would have to destroy the converter himself.
Otherwise he loses memory. In the second case if the user destroys the
converter again, it would be a use after free.

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-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.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH rtems] dosfs: Fix memory leak on failed mounts.

[Christian Mauderer]

PS: Is this a candidate for a backport to 5? How many tickets would I
have to create for it? One for 5 and one for 6?

On 03/08/2020 15:16, Christian Mauderer wrote:
> Currently if mount fails, a converter isn't destroyed. We have to take
> care of two cases:
> 
> 1. The user doesn't provide a converter.
> 
> In this case mounting a dosfs creates a default converter. This patch
> makes sure that the converter is destroyed again if mount failes for
> this case.
> 
> 2. The user provides a converter.
> 
> In this case it's not sure that the dosfs specific routines are reached
> because mount can fail before that. Therefore the user has to destroy
> the converter himself again. This patch adds a documentation for that
> and implements it in the media server.
> ---
>  cpukit/include/rtems/dosfs.h| 7 +++
>  cpukit/libblock/src/media.c | 1 +
>  cpukit/libfs/src/dosfs/msdos_init.c | 5 +
>  3 files changed, 13 insertions(+)
> 
> diff --git a/cpukit/include/rtems/dosfs.h b/cpukit/include/rtems/dosfs.h
> index 7691ed7e43..a79b00720a 100644
> --- a/cpukit/include/rtems/dosfs.h
> +++ b/cpukit/include/rtems/dosfs.h
> @@ -214,6 +214,9 @@ typedef struct {
>/**
> * @brief Converter implementation for new file system instance.
> *
> +   * Note: If you pass a converter to mount, you have to destroy it yourself 
> if
> +   * mount failed. In a good case it is destroyed at unmount.
> +   *
> * Before converters have been added to the RTEMS implementation of the FAT
> * file system, the implementation was:
> * - Short names were saved in code page format (as is still the case).
> @@ -270,6 +273,10 @@ typedef struct {
> *   RTEMS_FILESYSTEM_READ_WRITE,
> *   _opts
> * );
> +   *
> +   * if (rv != 0) {
> +   *   mount_opts.converter->handler->destroy(mount_opts.converter);
> +   * }
> *   } else {
> * rv = -1;
> * errno = ENOMEM;
> diff --git a/cpukit/libblock/src/media.c b/cpukit/libblock/src/media.c
> index 5b2b06b5b2..2964c19881 100644
> --- a/cpukit/libblock/src/media.c
> +++ b/cpukit/libblock/src/media.c
> @@ -504,6 +504,7 @@ static rtems_status_code mount_worker(
>  if (rv != 0) {
>rmdir(mount_path);
>free(mount_path);
> +  mount_options.converter->handler->destroy(mount_options.converter);
>  
>return RTEMS_IO_ERROR;
>  }
> diff --git a/cpukit/libfs/src/dosfs/msdos_init.c 
> b/cpukit/libfs/src/dosfs/msdos_init.c
> index dc9c76437d..0649258fa7 100644
> --- a/cpukit/libfs/src/dosfs/msdos_init.c
> +++ b/cpukit/libfs/src/dosfs/msdos_init.c
> @@ -102,10 +102,12 @@ int rtems_dosfs_initialize(
>  intrc = 0;
>  const rtems_dosfs_mount_options   *mount_options = data;
>  rtems_dosfs_convert_control   *converter;
> +bool   converter_created = false;
>  
>  
>  if (mount_options == NULL || mount_options->converter == NULL) {
>  converter = rtems_dosfs_create_default_converter();
> +converter_created = true;
>  } else {
>  converter = mount_options->converter;
>  }
> @@ -116,6 +118,9 @@ int rtems_dosfs_initialize(
>_file_handlers,
>_dir_handlers,
>converter);
> +if (rc != 0 && converter_created) {
> +converter->handler->destroy(converter);
> +}
>  } else {
>  errno = ENOMEM;
>  rc = -1;
> 

-- 

embedded brains GmbH
Herr Christian Mauderer
Dornierstr. 4
D-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.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH rtems] dosfs: Fix memory leak on failed mounts.

[Christian Mauderer]

Currently if mount fails, a converter isn't destroyed. We have to take
care of two cases:

1. The user doesn't provide a converter.

In this case mounting a dosfs creates a default converter. This patch
makes sure that the converter is destroyed again if mount failes for
this case.

2. The user provides a converter.

In this case it's not sure that the dosfs specific routines are reached
because mount can fail before that. Therefore the user has to destroy
the converter himself again. This patch adds a documentation for that
and implements it in the media server.
---
 cpukit/include/rtems/dosfs.h| 7 +++
 cpukit/libblock/src/media.c | 1 +
 cpukit/libfs/src/dosfs/msdos_init.c | 5 +
 3 files changed, 13 insertions(+)

diff --git a/cpukit/include/rtems/dosfs.h b/cpukit/include/rtems/dosfs.h
index 7691ed7e43..a79b00720a 100644
--- a/cpukit/include/rtems/dosfs.h
+++ b/cpukit/include/rtems/dosfs.h
@@ -214,6 +214,9 @@ typedef struct {
   /**
* @brief Converter implementation for new file system instance.
*
+   * Note: If you pass a converter to mount, you have to destroy it yourself if
+   * mount failed. In a good case it is destroyed at unmount.
+   *
* Before converters have been added to the RTEMS implementation of the FAT
* file system, the implementation was:
* - Short names were saved in code page format (as is still the case).
@@ -270,6 +273,10 @@ typedef struct {
*   RTEMS_FILESYSTEM_READ_WRITE,
*   _opts
* );
+   *
+   * if (rv != 0) {
+   *   mount_opts.converter->handler->destroy(mount_opts.converter);
+   * }
*   } else {
* rv = -1;
* errno = ENOMEM;
diff --git a/cpukit/libblock/src/media.c b/cpukit/libblock/src/media.c
index 5b2b06b5b2..2964c19881 100644
--- a/cpukit/libblock/src/media.c
+++ b/cpukit/libblock/src/media.c
@@ -504,6 +504,7 @@ static rtems_status_code mount_worker(
 if (rv != 0) {
   rmdir(mount_path);
   free(mount_path);
+  mount_options.converter->handler->destroy(mount_options.converter);
 
   return RTEMS_IO_ERROR;
 }
diff --git a/cpukit/libfs/src/dosfs/msdos_init.c 
b/cpukit/libfs/src/dosfs/msdos_init.c
index dc9c76437d..0649258fa7 100644
--- a/cpukit/libfs/src/dosfs/msdos_init.c
+++ b/cpukit/libfs/src/dosfs/msdos_init.c
@@ -102,10 +102,12 @@ int rtems_dosfs_initialize(
 intrc = 0;
 const rtems_dosfs_mount_options   *mount_options = data;
 rtems_dosfs_convert_control   *converter;
+bool   converter_created = false;
 
 
 if (mount_options == NULL || mount_options->converter == NULL) {
 converter = rtems_dosfs_create_default_converter();
+converter_created = true;
 } else {
 converter = mount_options->converter;
 }
@@ -116,6 +118,9 @@ int rtems_dosfs_initialize(
   _file_handlers,
   _dir_handlers,
   converter);
+if (rc != 0 && converter_created) {
+converter->handler->destroy(converter);
+}
 } else {
 errno = ENOMEM;
 rc = -1;
-- 
2.26.2

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

Re: BSP for pico and microzed

[Christian Mauderer]

On 31/07/2020 22:26, Joel Sherrill wrote:
> 
> 
> On Fri, Jul 31, 2020 at 3:04 PM Jonathan Brandmeyer
> mailto:jbrandme...@planetiq.com>> wrote:
> 
> On Fri, Jul 31, 2020 at 11:43 AM Joel Sherrill  > wrote:
> 
> Hi
> 
> Do any of the existing Zynq variants work on those? I recall
> posts about using them but not which variant was used.
> 
> 
> The zedboard BSP works as-is on the microzed.  However, you almost
> certainly want to set BSP_ZYNQ_RAM_LENGTH=1024M to get access to all
> of the DRAM.
> 
> The BSP also works as-is on the 7020 and 7030 Zynq family members as
> well.
> 
> 
> Thanks. 
> 
> Anyone with suggestions on how to make this more obvious? Should we add
> a couple more BSP variants here like we have in the SPARC BSPs to make
> things clear to end users?
> 
> --joel 

Hello Joel,

first a confirmation from my side: I had to do with a customer board
that used a Picozed 7030 just recently. It worked well. If you need a
more detailed configure line, I can look it up.

I don't think that adding more BSP variants would be an optimal solution
if no adaption is necessary for a specific variant. That will only lead
to a longer build time if you want to build all BSPs.

How about adding a bit more information like a list of boards the BSP
can handle in the user manual? We have a big Board Support Packages
section for that:

https://docs.rtems.org/branches/master/user/bsps/index.html

I did something like that when I extended the imx BSP to support
i.mx6ul/ull too:

https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#id11

Best regards

Christian

> 
> 
> -- 
> Jonathan Brandmeyer
> PlanetiQ
> 
> 
> ___
> 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 7/7] libtests/openfirmware: Added a testsuite for openfirmware

[Christian Mauderer]

On 29/07/2020 20:21, Gedare Bloom wrote:
> On Wed, Jul 29, 2020 at 12:10 PM Christian Mauderer  
> wrote:
>>
>> On 29/07/2020 19:55, Gedare Bloom wrote:
>>> On Wed, Jul 29, 2020 at 10:44 AM Christian Mauderer  
>>> wrote:
>>>>
>>>> On 29/07/2020 18:07, Gedare Bloom wrote:
>>>>> On Wed, Jul 15, 2020 at 12:32 AM G S Niteesh Babu  
>>>>> wrote:
>>>>>>
>>>>>> ---
>>>>>>  spec/build/testsuites/libtests/grp.yml|   3 +
>>>>>>  .../testsuites/libtests/openfirmware01.yml|  20 +++
>>>>>>  testsuites/libtests/openfirmware01/init.c | 147 ++
>>>>>>  .../openfirmware01/openfirmware01.doc |  29 
>>>>>>  .../openfirmware01/openfirmware01.scn |   2 +
>>>>>>  testsuites/libtests/openfirmware01/some.c |  52 +++
>>>>>>  testsuites/libtests/openfirmware01/some.dts   |  54 +++
>>>>>>  testsuites/libtests/openfirmware01/some.h |  15 ++
>>>>>>  8 files changed, 322 insertions(+)
>>>>>>  create mode 100644 spec/build/testsuites/libtests/openfirmware01.yml
>>>>>>  create mode 100644 testsuites/libtests/openfirmware01/init.c
>>>>>>  create mode 100644 testsuites/libtests/openfirmware01/openfirmware01.doc
>>>>>>  create mode 100644 testsuites/libtests/openfirmware01/openfirmware01.scn
>>>>>>  create mode 100644 testsuites/libtests/openfirmware01/some.c
>>>>>>  create mode 100644 testsuites/libtests/openfirmware01/some.dts
>>>>>>  create mode 100644 testsuites/libtests/openfirmware01/some.h
>>>>>>
>>>>>> diff --git a/spec/build/testsuites/libtests/grp.yml 
>>>>>> b/spec/build/testsuites/libtests/grp.yml
>>>>>> index f1de6cd75f..56e84d2c89 100644
>>>>>> --- a/spec/build/testsuites/libtests/grp.yml
>>>>>> +++ b/spec/build/testsuites/libtests/grp.yml
>>>>>> @@ -11,6 +11,7 @@ install: []
>>>>>>  ldflags:
>>>>>>  - -Wl,--wrap=printf
>>>>>>  - -Wl,--wrap=puts
>>>>>> +- -Wl,--wrap=bsp_fdt_get
>>>>>>  links:
>>>>>>  - role: build-dependency
>>>>>>uid: optbin2c
>>>>>> @@ -312,6 +313,8 @@ links:
>>>>>>uid: write
>>>>>>  - role: build-dependency
>>>>>>uid: writev
>>>>>> +- role: build-dependency
>>>>>> +  uid: openfirmware01
>>>>>>  type: build
>>>>>>  use-after:
>>>>>>  - rtemstest
>>>>>> diff --git a/spec/build/testsuites/libtests/openfirmware01.yml 
>>>>>> b/spec/build/testsuites/libtests/openfirmware01.yml
>>>>>> new file mode 100644
>>>>>> index 00..8feb69eb1e
>>>>>> --- /dev/null
>>>>>> +++ b/spec/build/testsuites/libtests/openfirmware01.yml
>>>>>> @@ -0,0 +1,20 @@
>>>>>> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>>>>>> +build-type: test-program
>>>>>> +cflags: []
>>>>>> +copyrights:
>>>>>> +- Copyright (C) 2020 Niteesh G S
>>>>>> +cppflags: []
>>>>>> +cxxflags: []
>>>>>> +enabled-by: true
>>>>>> +features: c cprogram
>>>>>> +includes: []
>>>>>> +ldflags: []
>>>>>> +links: []
>>>>>> +source:
>>>>>> +- testsuites/libtests/openfirmware01/init.c
>>>>>> +- testsuites/libtests/openfirmware01/some.c
>>>>>> +stlib: []
>>>>>> +target: testsuites/libtests/openfirmware01.exe
>>>>>> +type: build
>>>>>> +use-after: []
>>>>>> +use-before: []
>>>>>> diff --git a/testsuites/libtests/openfirmware01/init.c 
>>>>>> b/testsuites/libtests/openfirmware01/init.c
>>>>>> new file mode 100644
>>>>>> index 00..fc38e6c513
>>>>>> --- /dev/null
>>>>>> +++ b/testsuites/libtests/openfirmware01/init.c
>>>>>> @@ -0,0 +1,147 @@
>>>>>> +/* SPDX-License-Identifier: BSD-2-Clause */
>>>>>> +
>>>>>> +/*
>>>>>> + * Copyright (C) <2020> Niteesh G S 
>>>>&

Re: [PATCH RTEMS 7/7] libtests/openfirmware: Added a testsuite for openfirmware

[Christian Mauderer]

On 29/07/2020 19:55, Gedare Bloom wrote:
> On Wed, Jul 29, 2020 at 10:44 AM Christian Mauderer  
> wrote:
>>
>> On 29/07/2020 18:07, Gedare Bloom wrote:
>>> On Wed, Jul 15, 2020 at 12:32 AM G S Niteesh Babu  
>>> wrote:
>>>>
>>>> ---
>>>>  spec/build/testsuites/libtests/grp.yml|   3 +
>>>>  .../testsuites/libtests/openfirmware01.yml|  20 +++
>>>>  testsuites/libtests/openfirmware01/init.c | 147 ++
>>>>  .../openfirmware01/openfirmware01.doc |  29 
>>>>  .../openfirmware01/openfirmware01.scn |   2 +
>>>>  testsuites/libtests/openfirmware01/some.c |  52 +++
>>>>  testsuites/libtests/openfirmware01/some.dts   |  54 +++
>>>>  testsuites/libtests/openfirmware01/some.h |  15 ++
>>>>  8 files changed, 322 insertions(+)
>>>>  create mode 100644 spec/build/testsuites/libtests/openfirmware01.yml
>>>>  create mode 100644 testsuites/libtests/openfirmware01/init.c
>>>>  create mode 100644 testsuites/libtests/openfirmware01/openfirmware01.doc
>>>>  create mode 100644 testsuites/libtests/openfirmware01/openfirmware01.scn
>>>>  create mode 100644 testsuites/libtests/openfirmware01/some.c
>>>>  create mode 100644 testsuites/libtests/openfirmware01/some.dts
>>>>  create mode 100644 testsuites/libtests/openfirmware01/some.h
>>>>
>>>> diff --git a/spec/build/testsuites/libtests/grp.yml 
>>>> b/spec/build/testsuites/libtests/grp.yml
>>>> index f1de6cd75f..56e84d2c89 100644
>>>> --- a/spec/build/testsuites/libtests/grp.yml
>>>> +++ b/spec/build/testsuites/libtests/grp.yml
>>>> @@ -11,6 +11,7 @@ install: []
>>>>  ldflags:
>>>>  - -Wl,--wrap=printf
>>>>  - -Wl,--wrap=puts
>>>> +- -Wl,--wrap=bsp_fdt_get
>>>>  links:
>>>>  - role: build-dependency
>>>>uid: optbin2c
>>>> @@ -312,6 +313,8 @@ links:
>>>>uid: write
>>>>  - role: build-dependency
>>>>uid: writev
>>>> +- role: build-dependency
>>>> +  uid: openfirmware01
>>>>  type: build
>>>>  use-after:
>>>>  - rtemstest
>>>> diff --git a/spec/build/testsuites/libtests/openfirmware01.yml 
>>>> b/spec/build/testsuites/libtests/openfirmware01.yml
>>>> new file mode 100644
>>>> index 00..8feb69eb1e
>>>> --- /dev/null
>>>> +++ b/spec/build/testsuites/libtests/openfirmware01.yml
>>>> @@ -0,0 +1,20 @@
>>>> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>>>> +build-type: test-program
>>>> +cflags: []
>>>> +copyrights:
>>>> +- Copyright (C) 2020 Niteesh G S
>>>> +cppflags: []
>>>> +cxxflags: []
>>>> +enabled-by: true
>>>> +features: c cprogram
>>>> +includes: []
>>>> +ldflags: []
>>>> +links: []
>>>> +source:
>>>> +- testsuites/libtests/openfirmware01/init.c
>>>> +- testsuites/libtests/openfirmware01/some.c
>>>> +stlib: []
>>>> +target: testsuites/libtests/openfirmware01.exe
>>>> +type: build
>>>> +use-after: []
>>>> +use-before: []
>>>> diff --git a/testsuites/libtests/openfirmware01/init.c 
>>>> b/testsuites/libtests/openfirmware01/init.c
>>>> new file mode 100644
>>>> index 00..fc38e6c513
>>>> --- /dev/null
>>>> +++ b/testsuites/libtests/openfirmware01/init.c
>>>> @@ -0,0 +1,147 @@
>>>> +/* SPDX-License-Identifier: BSD-2-Clause */
>>>> +
>>>> +/*
>>>> + * Copyright (C) <2020> Niteesh G S 
>>>> + *
>>>> + * Redistribution and use in source and binary forms, with or without
>>>> + * modification, are permitted provided that the following conditions
>>>> + * are met:
>>>> + * 1. Redistributions of source code must retain the above copyright
>>>> + *notice, this list of conditions and the following disclaimer.
>>>> + * 2. Redistributions in binary form must reproduce the above copyright
>>>> + *notice, this list of conditions and the following disclaimer in the
>>>> + *documentation and/or other materials provided with the distribution.
>>>> + *
>>>> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 
>>>> "AS IS"
>>>> 

Re: [PATCH RTEMS 7/7] libtests/openfirmware: Added a testsuite for openfirmware

[Christian Mauderer]

On 29/07/2020 18:07, Gedare Bloom wrote:
> On Wed, Jul 15, 2020 at 12:32 AM G S Niteesh Babu  
> wrote:
>>
>> ---
>>  spec/build/testsuites/libtests/grp.yml|   3 +
>>  .../testsuites/libtests/openfirmware01.yml|  20 +++
>>  testsuites/libtests/openfirmware01/init.c | 147 ++
>>  .../openfirmware01/openfirmware01.doc |  29 
>>  .../openfirmware01/openfirmware01.scn |   2 +
>>  testsuites/libtests/openfirmware01/some.c |  52 +++
>>  testsuites/libtests/openfirmware01/some.dts   |  54 +++
>>  testsuites/libtests/openfirmware01/some.h |  15 ++
>>  8 files changed, 322 insertions(+)
>>  create mode 100644 spec/build/testsuites/libtests/openfirmware01.yml
>>  create mode 100644 testsuites/libtests/openfirmware01/init.c
>>  create mode 100644 testsuites/libtests/openfirmware01/openfirmware01.doc
>>  create mode 100644 testsuites/libtests/openfirmware01/openfirmware01.scn
>>  create mode 100644 testsuites/libtests/openfirmware01/some.c
>>  create mode 100644 testsuites/libtests/openfirmware01/some.dts
>>  create mode 100644 testsuites/libtests/openfirmware01/some.h
>>
>> diff --git a/spec/build/testsuites/libtests/grp.yml 
>> b/spec/build/testsuites/libtests/grp.yml
>> index f1de6cd75f..56e84d2c89 100644
>> --- a/spec/build/testsuites/libtests/grp.yml
>> +++ b/spec/build/testsuites/libtests/grp.yml
>> @@ -11,6 +11,7 @@ install: []
>>  ldflags:
>>  - -Wl,--wrap=printf
>>  - -Wl,--wrap=puts
>> +- -Wl,--wrap=bsp_fdt_get
>>  links:
>>  - role: build-dependency
>>uid: optbin2c
>> @@ -312,6 +313,8 @@ links:
>>uid: write
>>  - role: build-dependency
>>uid: writev
>> +- role: build-dependency
>> +  uid: openfirmware01
>>  type: build
>>  use-after:
>>  - rtemstest
>> diff --git a/spec/build/testsuites/libtests/openfirmware01.yml 
>> b/spec/build/testsuites/libtests/openfirmware01.yml
>> new file mode 100644
>> index 00..8feb69eb1e
>> --- /dev/null
>> +++ b/spec/build/testsuites/libtests/openfirmware01.yml
>> @@ -0,0 +1,20 @@
>> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>> +build-type: test-program
>> +cflags: []
>> +copyrights:
>> +- Copyright (C) 2020 Niteesh G S
>> +cppflags: []
>> +cxxflags: []
>> +enabled-by: true
>> +features: c cprogram
>> +includes: []
>> +ldflags: []
>> +links: []
>> +source:
>> +- testsuites/libtests/openfirmware01/init.c
>> +- testsuites/libtests/openfirmware01/some.c
>> +stlib: []
>> +target: testsuites/libtests/openfirmware01.exe
>> +type: build
>> +use-after: []
>> +use-before: []
>> diff --git a/testsuites/libtests/openfirmware01/init.c 
>> b/testsuites/libtests/openfirmware01/init.c
>> new file mode 100644
>> index 00..fc38e6c513
>> --- /dev/null
>> +++ b/testsuites/libtests/openfirmware01/init.c
>> @@ -0,0 +1,147 @@
>> +/* SPDX-License-Identifier: BSD-2-Clause */
>> +
>> +/*
>> + * Copyright (C) <2020> Niteesh G S 
>> + *
>> + * Redistribution and use in source and binary forms, with or without
>> + * modification, are permitted provided that the following conditions
>> + * are met:
>> + * 1. Redistributions of source code must retain the above copyright
>> + *notice, this list of conditions and the following disclaimer.
>> + * 2. Redistributions in binary form must reproduce the above copyright
>> + *notice, this list of conditions and the following disclaimer in the
>> + *documentation and/or other materials provided with the distribution.
>> + *
>> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS 
>> IS"
>> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
>> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR 
>> PURPOSE
>> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
>> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
>> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
>> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
>> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
>> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF 
>> THE
>> + * POSSIBILITY OF SUCH DAMAGE.
>> + */
>> +
>> +#ifdef HAVE_CONFIG_H
>> +#include "config.h"
>> +#endif
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "some.h"
>> +
>> +#define BUF_SIZE 100
>> +
>> +const char rtems_test_name[] = "OpenFirmWare 01";
>> +
>> +const void *__wrap_bsp_fdt_get(void);
>> +const void *__real_bsp_fdt_get(void);
>> +
>> +const void *__wrap_bsp_fdt_get(void)
>> +{
>> +if (some_bin != NULL) {
>> +return _bin[0];
>> +}
>> +return __real_bsp_fdt_get();
>> +}
>> +
>> +static void Init(rtems_task_argument arg)
>> +{
>> +int rv;
>> +phandle_t d;
>> +phandle_t l;
>> +phandle_t t;
>> +phandle_t root;
>> +