[PATCH v4 7/7] bsps/stm32f4: Fix GPIO port guards and ISR bug

[Duc Doan]

Changes GPIO port guards from variant to #ifdef
of ports. Fixed ISR memory-leak bug. Changed GPIO
functions to extern and added comments for them.
---
 bsps/arm/stm32f4/gpio/gpio.c| 182 
 bsps/arm/stm32f4/include/bsp/stm32f4_gpio.h | 167 ++
 2 files changed, 238 insertions(+), 111 deletions(-)

diff --git a/bsps/arm/stm32f4/gpio/gpio.c b/bsps/arm/stm32f4/gpio/gpio.c
index ac4d3b4f56..5bcff71b2d 100644
--- a/bsps/arm/stm32f4/gpio/gpio.c
+++ b/bsps/arm/stm32f4/gpio/gpio.c
@@ -54,58 +54,6 @@ static rtems_status_code stm32f4_gpio_destroy(
 rtems_gpio *base
 );
 
-static rtems_status_code stm32f4_gpio_init(
-rtems_gpio *base
-);
-
-static rtems_status_code stm32f4_gpio_deinit(
-rtems_gpio *base
-);
-
-static rtems_status_code stm32f4_gpio_set_pin_mode(
-rtems_gpio *base,
-rtems_gpio_pin_mode mode
-);
-
-static rtems_status_code stm32f4_gpio_set_pull(
-rtems_gpio *base,
-rtems_gpio_pull pull
-);
-
-static rtems_status_code stm32f4_gpio_configure_interrupt(
-rtems_gpio *base, 
-rtems_gpio_isr isr,
-void *arg,
-rtems_gpio_interrupt_trig trig,
-rtems_gpio_pull pull
-);
-
-static rtems_status_code stm32f4_gpio_remove_interrupt(
-rtems_gpio *base
-);
-
-static rtems_status_code stm32f4_gpio_enable_interrupt(
-rtems_gpio *base
-);
-
-static rtems_status_code stm32f4_gpio_disable_interrupt(
-rtems_gpio *base
-);
-
-static rtems_status_code stm32f4_gpio_read(
-rtems_gpio *base,
-rtems_gpio_pin_state *value
-);
-
-static rtems_status_code stm32f4_gpio_write(
-rtems_gpio *base,
-rtems_gpio_pin_state value
-);
-
-static rtems_status_code stm32f4_gpio_toggle(
-rtems_gpio *base
-);
-
 /*/
 
 /**
@@ -126,11 +74,39 @@ static const rtems_gpio_handlers stm32f4_gpio_handlers = {
 };
 
 static GPIO_TypeDef * const GPIOx[] = {
-GPIOA, GPIOB, GPIOC, GPIOD, GPIOE,
-GPIOF, GPIOG, GPIOH, GPIOI,
-#ifdef STM32F429X
-GPIOJ, GPIOK
-#endif /* STM32F429X */
+#ifdef GPIOA_BASE
+GPIOA
+#endif /* GPIOA_BASE */
+#ifdef GPIOB_BASE
+, GPIOB
+#endif /* GPIOB_BASE */
+#ifdef GPIOC_BASE
+, GPIOC
+#endif /* GPIOC_BASE */
+#ifdef GPIOD_BASE
+, GPIOD
+#endif /* GPIOD_BASE */
+#ifdef GPIOE_BASE
+, GPIOE
+#endif /* GPIOE_BASE */
+#ifdef GPIOF_BASE
+, GPIOF
+#endif /* GPIOF_BASE */
+#ifdef GPIOG_BASE
+, GPIOG
+#endif /* GPIOG_BASE */
+#ifdef GPIOH_BASE
+, GPIOH
+#endif /* GPIOH_BASE */
+#ifdef GPIOI_BASE
+, GPIOI
+#endif /* GPIOI_BASE */
+#ifdef GPIOJ_BASE
+, GPIOJ
+#endif /* GPIOJ_BASE */
+#ifdef GPIOK_BASE
+, GPIOK
+#endif /* GPIOK_BASE */
 };
 
 static unsigned int const EXTIx_IRQn[] = {
@@ -206,6 +182,7 @@ typedef struct {
 } stm32f4_interrupt;
 
 static stm32f4_interrupt isr_table[16]; 
+static bool isr_registered[16] = {0};
 
 void exti_handler(void *arg);
 
@@ -253,41 +230,61 @@ rtems_status_code stm32f4_gpio_init(rtems_gpio *base) {
 stm32f4_gpio *gpio = get_gpio_from_base(base);
 
 switch ((uintptr_t) gpio->port) {
+#ifdef GPIOA_BASE
 case (uintptr_t) GPIOA:
 __HAL_RCC_GPIOA_CLK_ENABLE();
 break;
+#endif /* GPIOA_BASE */
+#ifdef GPIOB_BASE
 case (uintptr_t) GPIOB:
 __HAL_RCC_GPIOB_CLK_ENABLE();
 break;
+#endif /* GPIOB_BASE */
+#ifdef GPIOC_BASE
 case (uintptr_t) GPIOC:
 __HAL_RCC_GPIOC_CLK_ENABLE();
 break;
+#endif /* GPIOC_BASE */
+#ifdef GPIOD_BASE
 case (uintptr_t) GPIOD:
 __HAL_RCC_GPIOD_CLK_ENABLE();
 break;
+#endif /* GPIOD_BASE */
+#ifdef GPIOE_BASE
 case (uintptr_t) GPIOE:
 __HAL_RCC_GPIOE_CLK_ENABLE();
 break;
+#endif /* GPIOE_BASE */
+#ifdef GPIOF_BASE
 case (uintptr_t) GPIOF:
 __HAL_RCC_GPIOF_CLK_ENABLE();
 break;
+#endif /* GPIOF_BASE */
+#ifdef GPIOG_BASE
 case (uintptr_t) GPIOG:
 __HAL_RCC_GPIOG_CLK_ENABLE();
 break;
+#endif /* GPIOG_BASE */
+#ifdef GPIOH_BASE
 case (uintptr_t) GPIOH:
 __HAL_RCC_GPIOH_CLK_ENABLE();
 break;
+#endif /* GPIOH_BASE */
+#ifdef GPIOI_BASE
 case (uintptr_t) GPIOI:
 __HAL_RCC_GPIOI_CLK_ENABLE();
 break;
-#ifdef STM32F429X
+#endif /* GPIOI_BASE */
+#ifdef GPIOJ_BASE
 case (uintptr_t) GPIOJ:
 __HAL_RCC_GPIOJ_CLK_ENABLE();
 break;
+#endif /* GPIOJ_BASE */
+#ifdef GPIOK_BASE
 case (uintptr_t) GPIOK:
 __HAL_RCC_GPIOK_CLK_ENABLE();
 break;
-#endif /* STM32F429X */
+#endif /* GPIOK_BASE */
 default:
 return RTEMS_UNSATISFIED;
 }
@@ -295,50 +292,6 @@ rtems_status_code stm32f4_gpio_init(rtems_gpio *base) {
 }
 
 rtems_status_code stm32f4_gpio_deinit(rtems_gpio *base) {
-/*
-stm32f4_gpio *gpio = get_gpio_from_base(base);
-
-switch ((uintptr_t) gpio->port) {
-case (uintptr_t) 

[PATCH v4 6/7] bsps/stm32f4: Add missing GPIO functionality

[Duc Doan]

---
 bsps/arm/stm32f4/gpio/gpio.c| 32 +
 bsps/arm/stm32f4/include/bsp/stm32f4_gpio.h | 20 +
 2 files changed, 52 insertions(+)

diff --git a/bsps/arm/stm32f4/gpio/gpio.c b/bsps/arm/stm32f4/gpio/gpio.c
index efc005bd9f..ac4d3b4f56 100644
--- a/bsps/arm/stm32f4/gpio/gpio.c
+++ b/bsps/arm/stm32f4/gpio/gpio.c
@@ -562,3 +562,35 @@ void exti_handler(void *arg) {
 }
 }
 
+/ STM32F4 Other specific GPIO functions /
+void stm32f4_gpio_lock_pin(
+rtems_gpio *base
+)
+{
+stm32f4_gpio *gpio = get_gpio_from_base(base);
+LL_GPIO_LockPin(
+gpio->port,
+STM32F4_GET_HAL_GPIO_PIN(gpio->pin)
+);
+}
+
+void stm32f4_gpio_set_af(
+rtems_gpio *base,
+uint32_t alternate
+)
+{
+stm32f4_gpio *gpio = get_gpio_from_base(base);
+if (gpio->pin < 8)
+LL_GPIO_SetAFPin_0_7(
+gpio->port,
+STM32F4_GET_HAL_GPIO_PIN(gpio->pin),
+alternate
+);
+else
+LL_GPIO_SetAFPin_8_15(
+gpio->port,
+STM32F4_GET_HAL_GPIO_PIN(gpio->pin),
+alternate
+);
+}
+
diff --git a/bsps/arm/stm32f4/include/bsp/stm32f4_gpio.h 
b/bsps/arm/stm32f4/include/bsp/stm32f4_gpio.h
index eecd87b3fd..814b1b4105 100644
--- a/bsps/arm/stm32f4/include/bsp/stm32f4_gpio.h
+++ b/bsps/arm/stm32f4/include/bsp/stm32f4_gpio.h
@@ -53,4 +53,24 @@ typedef struct {
 GPIO_TypeDef *port;
 } stm32f4_gpio;
 
+/**
+  * @brief Lock configuration of a pin.
+  *
+  * @param[in] base The pointer to the GPIO object.
+  */
+extern void stm32f4_gpio_lock_pin(
+rtems_gpio *base
+);
+
+/**
+  * @brief Sets the alternate function for a pin.
+  *
+  * @param[in] base The pointer to the GPIO object.
+  * @param alternate Alternate function, from 0-15.
+  */
+extern void stm32f4_gpio_set_af(
+rtems_gpio *base,
+uint32_t alternate
+);
+
 #endif /* LIBBSP_ARM_STM32F4_BSP_GPIO */
-- 
2.36.1

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

[PATCH v4 5/7] bsps: Update license text

[Duc Doan]

This patch updates the license text of GPIO API
files and STM32F4 GPIO files.
---
 bsps/arm/stm32f4/gpio/gpio.c| 35 +++
 bsps/arm/stm32f4/include/bsp/stm32f4_gpio.h | 27 ---
 bsps/include/bsp/gpio2.h| 37 +
 bsps/shared/dev/gpio/gpio.c | 33 --
 4 files changed, 91 insertions(+), 41 deletions(-)

diff --git a/bsps/arm/stm32f4/gpio/gpio.c b/bsps/arm/stm32f4/gpio/gpio.c
index d7cac7fd58..efc005bd9f 100644
--- a/bsps/arm/stm32f4/gpio/gpio.c
+++ b/bsps/arm/stm32f4/gpio/gpio.c
@@ -1,19 +1,28 @@
-/**
-  * @file
-  *
-  * @ingroup rtems_bsp/arm/stm32f4
-  *
-  * @brief RTEMS GPIO new API implementation for STM32F4.
-  *
-  * @note RTEMS_GPIO_PINMODE_BSP_SPECIFIC is Alternate mode for STM32F4 BSP
-  */
+/* SPDX-License-Identifier: BSD-2-Clause */
 
 /*
- *  Copyright (c) 2022 Duc Doan 
+ * Copyright (C) 2022 Duc Doan (dtbpkmte at gmail.com)
+ *
+ * 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.
  *
- *  The license and distribution terms for this file may be
- *  found in the file LICENSE in this distribution or at
- *  http://www.rtems.org/license/LICENSE.
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
  */
 
 #include 
diff --git a/bsps/arm/stm32f4/include/bsp/stm32f4_gpio.h 
b/bsps/arm/stm32f4/include/bsp/stm32f4_gpio.h
index 8f21539709..eecd87b3fd 100644
--- a/bsps/arm/stm32f4/include/bsp/stm32f4_gpio.h
+++ b/bsps/arm/stm32f4/include/bsp/stm32f4_gpio.h
@@ -1,9 +1,28 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
 /*
- *  Copyright (c) 2022 Duc Doan 
+ * Copyright (C) 2022 Duc Doan (dtbpkmte at gmail.com)
+ *
+ * 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.
  *
- *  The license and distribution terms for this file may be
- *  found in the file LICENSE in this distribution or at
- *  http://www.rtems.org/license/LICENSE.
+ * 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_STM32F4_BSP_GPIO
diff --git a/bsps/include/bsp/gpio2.h b/bsps/include/bsp/gpio2.h
index e4a106da8b..0040e30505 100644
--- a/bsps/include/bsp/gpio2.h
+++ b/bsps/include/bsp/gpio2.h
@@ -1,18 +1,29 @@
-/**
-  * @file
-  *
-  * @ingroup rtems_gpio2
-  *
-  * @brief RTEMS GPIO new API definition.
-  */
+/* SPDX-License-Identifier: BSD-2-Clause */
 
 /*
-*  Copyright (c) 2022 Duc Doan 
-*
-*  The license and distribution terms for this file may be
-*  found in the file LICENSE in this distribution or at
-*  http://www.rtems.org/license/LICENSE.
-*/
+ * Copyright (C) 2022 Duc Doan (dtbpkmte at gmail.com)
+ *
+ * 

[PATCH v4 4/7] bsps/stm32f4: Add GPIO implementation for STM32F4

[Duc Doan]

---
 bsps/arm/stm32f4/gpio/gpio.c  | 555 ++
 bsps/arm/stm32f4/include/bsp.h|   4 -
 bsps/arm/stm32f4/include/bsp/stm32f4_gpio.h   |  37 ++
 bsps/arm/stm32f4/include/bsp/stm32f4_hal.h|  17 +
 bsps/arm/stm32f4/start/bspstart.c |   7 +-
 bsps/arm/stm32f4/start/bspstarthook.c |   8 +
 spec/build/bsps/arm/stm32f4/grp.yml   |   6 +-
 spec/build/bsps/arm/stm32f4/obj.yml   |   1 +
 spec/build/bsps/arm/stm32f4/optengpio.yml |  16 +
 .../build/bsps/arm/stm32f4/optnumgpioctrl.yml |  16 +
 10 files changed, 658 insertions(+), 9 deletions(-)
 create mode 100644 bsps/arm/stm32f4/gpio/gpio.c
 create mode 100644 bsps/arm/stm32f4/include/bsp/stm32f4_gpio.h
 create mode 100644 bsps/arm/stm32f4/include/bsp/stm32f4_hal.h
 create mode 100644 spec/build/bsps/arm/stm32f4/optengpio.yml
 create mode 100644 spec/build/bsps/arm/stm32f4/optnumgpioctrl.yml

diff --git a/bsps/arm/stm32f4/gpio/gpio.c b/bsps/arm/stm32f4/gpio/gpio.c
new file mode 100644
index 00..d7cac7fd58
--- /dev/null
+++ b/bsps/arm/stm32f4/gpio/gpio.c
@@ -0,0 +1,555 @@
+/**
+  * @file
+  *
+  * @ingroup rtems_bsp/arm/stm32f4
+  *
+  * @brief RTEMS GPIO new API implementation for STM32F4.
+  *
+  * @note RTEMS_GPIO_PINMODE_BSP_SPECIFIC is Alternate mode for STM32F4 BSP
+  */
+
+/*
+ *  Copyright (c) 2022 Duc Doan 
+ *
+ *  The license and distribution terms for this file may be
+ *  found in the file LICENSE in this distribution or at
+ *  http://www.rtems.org/license/LICENSE.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/*** Helpers */
+/**
+  * @brief Macro to get stm32f4_gpio object from a base rtems_gpio
+  *object.
+  *
+  * This is a wrapper of RTEMS_CONTAINER_OF macro
+  *
+  * @param base The pointer to a rtems_gpio object
+  * @retval The pointer to the stm32f4_gpio object owning
+  * the specified rtems_gpio object
+  */
+#define get_gpio_from_base(base) \
+RTEMS_CONTAINER_OF(base, stm32f4_gpio, base)
+
+/*** GPIO API ***/
+static rtems_status_code stm32f4_gpio_get(
+uint32_t interm_pin,
+rtems_gpio **out
+);
+
+static rtems_status_code stm32f4_gpio_destroy(
+rtems_gpio *base
+);
+
+static rtems_status_code stm32f4_gpio_init(
+rtems_gpio *base
+);
+
+static rtems_status_code stm32f4_gpio_deinit(
+rtems_gpio *base
+);
+
+static rtems_status_code stm32f4_gpio_set_pin_mode(
+rtems_gpio *base,
+rtems_gpio_pin_mode mode
+);
+
+static rtems_status_code stm32f4_gpio_set_pull(
+rtems_gpio *base,
+rtems_gpio_pull pull
+);
+
+static rtems_status_code stm32f4_gpio_configure_interrupt(
+rtems_gpio *base, 
+rtems_gpio_isr isr,
+void *arg,
+rtems_gpio_interrupt_trig trig,
+rtems_gpio_pull pull
+);
+
+static rtems_status_code stm32f4_gpio_remove_interrupt(
+rtems_gpio *base
+);
+
+static rtems_status_code stm32f4_gpio_enable_interrupt(
+rtems_gpio *base
+);
+
+static rtems_status_code stm32f4_gpio_disable_interrupt(
+rtems_gpio *base
+);
+
+static rtems_status_code stm32f4_gpio_read(
+rtems_gpio *base,
+rtems_gpio_pin_state *value
+);
+
+static rtems_status_code stm32f4_gpio_write(
+rtems_gpio *base,
+rtems_gpio_pin_state value
+);
+
+static rtems_status_code stm32f4_gpio_toggle(
+rtems_gpio *base
+);
+
+/*/
+
+/**
+  * @brief STM32F4 GPIO handlers
+  */
+static const rtems_gpio_handlers stm32f4_gpio_handlers = {
+.init = stm32f4_gpio_init,
+.deinit = stm32f4_gpio_deinit,
+.set_pin_mode = stm32f4_gpio_set_pin_mode,
+.set_pull = stm32f4_gpio_set_pull,
+.configure_interrupt = stm32f4_gpio_configure_interrupt,
+.remove_interrupt = stm32f4_gpio_remove_interrupt,
+.enable_interrupt = stm32f4_gpio_enable_interrupt,
+.disable_interrupt = stm32f4_gpio_disable_interrupt,
+.read = stm32f4_gpio_read,
+.write = stm32f4_gpio_write,
+.toggle = stm32f4_gpio_toggle
+};
+
+static GPIO_TypeDef * const GPIOx[] = {
+GPIOA, GPIOB, GPIOC, GPIOD, GPIOE,
+GPIOF, GPIOG, GPIOH, GPIOI,
+#ifdef STM32F429X
+GPIOJ, GPIOK
+#endif /* STM32F429X */
+};
+
+static unsigned int const EXTIx_IRQn[] = {
+EXTI0_IRQn,
+EXTI1_IRQn,
+EXTI2_IRQn,
+EXTI3_IRQn,
+EXTI4_IRQn,
+EXTI9_5_IRQn,
+EXTI9_5_IRQn,
+EXTI9_5_IRQn,
+EXTI9_5_IRQn,
+EXTI9_5_IRQn,
+EXTI15_10_IRQn,
+EXTI15_10_IRQn,
+EXTI15_10_IRQn,
+EXTI15_10_IRQn,
+EXTI15_10_IRQn,
+EXTI15_10_IRQn
+};
+
+/**
+  * @brief Converts intermediate pin number to port pointer.
+  *
+  * Intermediate pin number is a way of numerically labeling
+  * pins. Pins are labeled incrementally across all ports.
+  * Pins 0-15 from port A are 0-15. Pins 0-15 from port B are
+  * 16-31. And so on.
+  *
+  * @param interm_pin is the intermediate pin number
+  */
+#define STM32F4_GET_PORT(interm_pin) (GPIOx[ ( interm_pin ) / 16 ])
+
+/**
+  * @brief Converts 

[PATCH v4 3/7] bsps: Add GPIO API

[Duc Doan]

This is the new GPIO API. The header file is
gpio2.h.
---
 bsps/include/bsp/gpio2.h| 526 
 bsps/shared/dev/gpio/gpio.c | 189 +
 spec/build/bsps/obj.yml |   2 +-
 3 files changed, 716 insertions(+), 1 deletion(-)
 create mode 100644 bsps/include/bsp/gpio2.h
 create mode 100644 bsps/shared/dev/gpio/gpio.c

diff --git a/bsps/include/bsp/gpio2.h b/bsps/include/bsp/gpio2.h
new file mode 100644
index 00..e4a106da8b
--- /dev/null
+++ b/bsps/include/bsp/gpio2.h
@@ -0,0 +1,526 @@
+/**
+  * @file
+  *
+  * @ingroup rtems_gpio2
+  *
+  * @brief RTEMS GPIO new API definition.
+  */
+
+/*
+*  Copyright (c) 2022 Duc Doan 
+*
+*  The license and distribution terms for this file may be
+*  found in the file LICENSE in this distribution or at
+*  http://www.rtems.org/license/LICENSE.
+*/
+
+#ifndef LIBBSP_BSP_GPIO2_H
+#define LIBBSP_BSP_GPIO2_H
+
+#include 
+#include 
+
+/**
+  * Configure the maximum number of GPIO controllers used in
+  * a application.
+  *
+  * The macro CONFIGURE_GPIO_MAXIMUM_CONTROLLERS can be
+  * defined in application code. If it is not defined,
+  * it will default to BSP_GPIO_NUM_CONTROLLERS. If BSP's
+  * number of controllers is not defined, it will default
+  * to 1.
+  */
+#ifndef CONFIGURE_GPIO_MAXIMUM_CONTROLLERS
+
+#ifndef BSP_GPIO_NUM_CONTROLLERS
+#define CONFIGURE_GPIO_MAXIMUM_CONTROLLERS 1
+#else
+#define CONFIGURE_GPIO_MAXIMUM_CONTROLLERS BSP_GPIO_NUM_CONTROLLERS
+#endif /* BSP_GPIO_NUM_CONTROLLERS */
+
+#endif /* CONFIGURE_GPIO_MAXIMUM_CONTROLLERS */
+
+#ifdef __cplusplus
+extern "C" {
+#endif /* __cplusplus */
+
+/**
+  * @name GPIO data structures
+  *
+  * @{
+  */
+
+/**
+  * @brief GPIO bit set and reset enumeration.
+  */
+typedef enum {
+RTEMS_GPIO_PIN_RESET = 0,
+RTEMS_GPIO_PIN_SET = 1
+} rtems_gpio_pin_state;
+
+/**
+  * @brief GPIO pin modes. 
+  */
+typedef enum {
+RTEMS_GPIO_PINMODE_OUTPUT = 0,
+RTEMS_GPIO_PINMODE_OUTPUT_PP = 0,
+RTEMS_GPIO_PINMODE_OUTPUT_OD = 1,
+RTEMS_GPIO_PINMODE_INPUT = 2,
+RTEMS_GPIO_PINMODE_ANALOG = 3,
+RTEMS_GPIO_PINMODE_BSP_SPECIFIC = 4
+} rtems_gpio_pin_mode;
+
+/**
+  * @brief GPIO pull resistor configuration. Defines pull-up or 
+  *pull-down activation.
+  */
+typedef enum {
+RTEMS_GPIO_NOPULL,
+RTEMS_GPIO_PULLUP,
+RTEMS_GPIO_PULLDOWN
+} rtems_gpio_pull;
+
+/**
+  * @brief Interrupt modes enumeration.
+  */
+typedef enum {
+RTEMS_GPIO_INT_TRIG_NONE = 0,
+RTEMS_GPIO_INT_TRIG_FALLING,
+RTEMS_GPIO_INT_TRIG_RISING,
+RTEMS_GPIO_INT_TRIG_BOTH_EDGES,
+RTEMS_GPIO_INT_TRIG_LOW,
+RTEMS_GPIO_INT_TRIG_HIGH
+} rtems_gpio_interrupt_trig;
+
+typedef struct rtems_gpio_handlers rtems_gpio_handlers;
+typedef struct rtems_gpio rtems_gpio;
+/**
+  * @brief Typedef of the function pointer of an ISR.
+  */
+typedef void (*rtems_gpio_isr)(void *);
+
+/**
+  * @brief Structure containing pointers to handlers of a
+  *BSP/driver. Each BSP/driver must define its own 
+  *handlers and create an object of this structure
+  *with pointers to those handlers.
+  */
+struct rtems_gpio_handlers {
+/**
+  * @brief This member is the pointer to an initialize handler. 
+  *
+  * This handler could be used to perform some set up steps for
+  * a GPIO object (which means a pin or a port).
+  */
+rtems_status_code (*init)(rtems_gpio *);
+
+/**
+  * @brief This member is the pointer to a deinitialize handler. 
+  *
+  * This handler could be used to deinitialize a GPIO object.
+  */
+rtems_status_code (*deinit)(rtems_gpio *);
+
+/**
+  * @brief This member is the pointer to a handler for setting 
+  *pin mode. 
+  *
+  * Pin modes are from rtems_gpio_pin_mode enumeration.
+  */
+rtems_status_code (*set_pin_mode)(rtems_gpio *, rtems_gpio_pin_mode);
+
+/**
+  * @brief This member is the pointer to a handler for setting
+  *pull resistor mode. 
+  *
+  * Pull resistor modes are from rtems_gpio_pull enumeration.
+  */
+rtems_status_code (*set_pull)(rtems_gpio *, rtems_gpio_pull);
+
+/**
+  * @brief This member is the pointer to a handler for configuring
+  *interrupt of a pin. 
+  * 
+  * This handler should register ISR and its argument, interrupt
+  * trigger mode, and pull resister mode for the pin.
+  *
+  * @note Enabling interrupt should be done in enable_interrupt()
+  *   handler.
+  */
+rtems_status_code (*configure_interrupt)(rtems_gpio *, rtems_gpio_isr, 
void *, rtems_gpio_interrupt_trig, rtems_gpio_pull);
+
+/**
+  * @brief This member is the pointer to a handler for removing
+  *interrupt settings of a pin. 
+  *
+  * Interrupt settings can be ISR address, pin configuration, etc.
+  */
+rtems_status_code (*remove_interrupt)(rtems_gpio *);
+
+/**
+  * @brief This member is the pointer to a 

[PATCH v4 2/7] bsps/arm: Integrate and build STM32F4 HAL

[Duc Doan]

This patch is too large so I cannot send via email. Please find it here:
https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/e21e1fa527da67533f797ed3dc6fc70cf245725b

---
 .gitignore| 1 +
 bsps/arm/include/cmsis_compiler.h |   266 +
 bsps/arm/include/cmsis_gcc.h  |  1152 +-
 bsps/arm/include/cmsis_version.h  |39 +
 bsps/arm/include/core_cm4.h   |  4066 +--
 bsps/arm/include/core_cm7.h   |   582 +-
 bsps/arm/include/legacy/cmsis_gcc.h   |  1375 ++
 bsps/arm/include/legacy/core_cm7.h|  2515 ++
 bsps/arm/include/mpu_armv7.h  |   270 +
 bsps/arm/stm32f4/hal/system_stm32f4xx.c   |   747 +
 bsps/arm/stm32f4/include/bsp.h| 4 +
 bsps/arm/stm32f4/include/bsp/io.h | 4 +
 .../stm32f4/include/stm32_assert_template.h   |56 -
 bsps/arm/stm32f4/include/stm32f401xc.h|  8641 +++
 bsps/arm/stm32f4/include/stm32f401xe.h|  8641 +++
 bsps/arm/stm32f4/include/stm32f405xx.h| 14310 +++
 bsps/arm/stm32f4/include/stm32f407xx.h| 15607 
 bsps/arm/stm32f4/include/stm32f410cx.h|  7357 ++
 bsps/arm/stm32f4/include/stm32f410rx.h|  7361 ++
 bsps/arm/stm32f4/include/stm32f410tx.h|  7306 ++
 bsps/arm/stm32f4/include/stm32f411xe.h|  8680 +++
 bsps/arm/stm32f4/include/stm32f412cx.h| 13507 ++
 bsps/arm/stm32f4/include/stm32f412rx.h| 14500 +++
 bsps/arm/stm32f4/include/stm32f412vx.h| 14512 +++
 bsps/arm/stm32f4/include/stm32f412zx.h| 14537 +++
 bsps/arm/stm32f4/include/stm32f413xx.h| 15462 
 bsps/arm/stm32f4/include/stm32f415xx.h| 14595 +++
 bsps/arm/stm32f4/include/stm32f417xx.h| 15887 
 bsps/arm/stm32f4/include/stm32f423xx.h| 15615 
 bsps/arm/stm32f4/include/stm32f427xx.h| 16827 +
 bsps/arm/stm32f4/include/stm32f429xx.h| 17185 +
 bsps/arm/stm32f4/include/stm32f437xx.h| 17129 +
 bsps/arm/stm32f4/include/stm32f439xx.h| 17479 +
 bsps/arm/stm32f4/include/stm32f446xx.h| 15981 
 bsps/arm/stm32f4/include/stm32f469xx.h| 20278 +++
 bsps/arm/stm32f4/include/stm32f479xx.h| 20575 
 bsps/arm/stm32f4/include/stm32f4xx.h  |   305 +
 ...l_conf_template.h => stm32f4xx_hal_conf.h} | 6 +
 bsps/arm/stm32f4/include/system_stm32f4xx.h   |   104 +
 bsps/arm/stm32f4/start/bspstart.c |   202 +-
 bsps/arm/stm32f4/start/bspstart_old.c |   297 +
 spec/build/bsps/arm/grp.yml   | 5 +-
 spec/build/bsps/arm/stm32f4/grp.yml   |12 +-
 spec/build/bsps/arm/stm32f4/obj.yml   |   220 +
 spec/build/bsps/arm/stm32f4/optenhal.yml  |16 +
 spec/build/bsps/arm/stm32f4/opthse.yml|17 +
 spec/build/bsps/arm/stm32f4/optusehse.yml |16 +
 spec/build/bsps/arm/stm32f4/optvariant.yml|24 +
 spec/build/bsps/obj.yml   | 1 +
 49 files changed, 331831 insertions(+), 2443 deletions(-)
 create mode 100644 bsps/arm/include/cmsis_compiler.h
 create mode 100644 bsps/arm/include/cmsis_version.h
 create mode 100644 bsps/arm/include/legacy/cmsis_gcc.h
 create mode 100644 bsps/arm/include/legacy/core_cm7.h
 create mode 100644 bsps/arm/include/mpu_armv7.h
 create mode 100644 bsps/arm/stm32f4/hal/system_stm32f4xx.c
 delete mode 100644 bsps/arm/stm32f4/include/stm32_assert_template.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f401xc.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f401xe.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f405xx.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f407xx.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f410cx.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f410rx.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f410tx.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f411xe.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f412cx.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f412rx.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f412vx.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f412zx.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f413xx.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f415xx.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f417xx.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f423xx.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f427xx.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f429xx.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f437xx.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f439xx.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f446xx.h
 create mode 100644 bsps/arm/stm32f4/include/stm32f469xx.h
 create mode 100644 

[PATCH v4 1/7] bsps/stm32f4 Include STM32F4 HAL

[Duc Doan]

This patch is too large so I cannot send via email. Please find it here:
https://github.com/dtbpkmte/GSoC-2022-RTEMS/commit/098ca07151bb9186c7681c45f8474cf1441acb40

---
 .../stm32f4/hal/Legacy/stm32f4xx_hal_can.c| 1679 
 .../stm32f4/hal/Legacy/stm32f4xx_hal_eth.c| 2307 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal.c  |  615 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_adc.c  | 2110 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_adc_ex.c   | 1112 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_can.c  | 2462 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_cec.c  |  996 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_cortex.c   |  502 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_crc.c  |  328 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_cryp.c | 7132 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_cryp_ex.c  |  680 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dac.c  | 1341 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dac_ex.c   |  495 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dcmi.c | 1161 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dcmi_ex.c  |  182 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dfsdm.c| 4423 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dma.c  | 1305 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dma2d.c| 2126 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dma_ex.c   |  313 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dsi.c  | 2760 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_eth.c  | 3112 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_exti.c |  547 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_flash.c|  775 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_flash_ex.c | 1347 +++
 .../stm32f4/hal/stm32f4xx_hal_flash_ramfunc.c |  172 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_fmpi2c.c   | 6864 +++
 .../arm/stm32f4/hal/stm32f4xx_hal_fmpi2c_ex.c |  258 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_fmpsmbus.c | 2749 ++
 .../stm32f4/hal/stm32f4xx_hal_fmpsmbus_ex.c   |  145 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_gpio.c |  533 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_hash.c | 3514 
 bsps/arm/stm32f4/hal/stm32f4xx_hal_hash_ex.c  | 1040 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_hcd.c  | 1728 
 bsps/arm/stm32f4/hal/stm32f4xx_hal_i2c.c  | 7524 
 bsps/arm/stm32f4/hal/stm32f4xx_hal_i2c_ex.c   |  182 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_i2s.c  | 2094 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_i2s_ex.c   | 1135 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_irda.c | 2687 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_iwdg.c |  262 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_lptim.c| 2484 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_ltdc.c | 2215 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_ltdc_ex.c  |  151 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_mmc.c  | 3201 +++
 .../stm32f4/hal/stm32f4xx_hal_msp_template.c  |  100 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_nand.c | 2405 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_nor.c  | 1543 
 bsps/arm/stm32f4/hal/stm32f4xx_hal_pccard.c   |  946 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_pcd.c  | 2387 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_pcd_ex.c   |  341 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_pwr.c  |  571 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_pwr_ex.c   |  600 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_qspi.c | 2915 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_rcc.c  | 1122 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_rcc_ex.c   | 3784 
 bsps/arm/stm32f4/hal/stm32f4xx_hal_rng.c  |  867 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_rtc.c  | 1896 
 bsps/arm/stm32f4/hal/stm32f4xx_hal_rtc_ex.c   | 1878 
 bsps/arm/stm32f4/hal/stm32f4xx_hal_sai.c  | 2554 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_sai_ex.c   |  310 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_sd.c   | 3277 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_sdram.c| 1308 +++
 .../arm/stm32f4/hal/stm32f4xx_hal_smartcard.c | 2364 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_smbus.c| 2784 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_spdifrx.c  | 1627 
 bsps/arm/stm32f4/hal/stm32f4xx_hal_spi.c  | 3915 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_sram.c | 1110 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_tim.c  | 7621 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_tim_ex.c   | 2428 ++
 ...tm32f4xx_hal_timebase_rtc_alarm_template.c |  318 +
 ...m32f4xx_hal_timebase_rtc_wakeup_template.c |  293 +
 .../hal/stm32f4xx_hal_timebase_tim_template.c |  177 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_uart.c | 3751 
 bsps/arm/stm32f4/hal/stm32f4xx_hal_usart.c| 2838 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_wwdg.c |  420 +
 bsps/arm/stm32f4/hal/stm32f4xx_ll_adc.c   |  922 ++
 bsps/arm/stm32f4/hal/stm32f4xx_ll_crc.c   |  103 +
 bsps/arm/stm32f4/hal/stm32f4xx_ll_dac.c   |  280 +
 bsps/arm/stm32f4/hal/stm32f4xx_ll_dma.c   |  423 +
 bsps/arm/stm32f4/hal/stm32f4xx_ll_dma2d.c |  594 ++
 bsps/arm/stm32f4/hal/stm32f4xx_ll_exti.c  |  212 +
 bsps/arm/stm32f4/hal/stm32f4xx_ll_fmc.c   | 1498 
 

[PATCH v4 0/7] *** New GPIO API and implementation for STM32F4 BSP ***

[Duc Doan]

Dear all,

These patches add a new GPIO API that aims at portability. GPIO of STM32F4 BSP 
has been implemented using this API. The sample application code can be found 
at https://github.com/dtbpkmte/GSoC-2022-RTEMS-Sample-Apps.

The newest branch is stm32f4-gpio.

v2:

- Made get_gpio_from_base() a macro instead of a function
- Added missing cppflags in spec/build/bsps/arm/grp.yml
- Optimized STM32F4_GET_HAL_GPIO_PIN() and STM32F4_GET_LL_EXTI_LINE()
- Optimized functions by switching from HAL to LL
- Made stm32f4_gpio_deinit() return RTEMS_NOT_IMPLEMENTED, because disabling 
clock might
affect all pins in a port
- Add const to static helper arrays to make sure they are placed on ROM

v3:

- Removed rtems_gpio_begin()
- bsp_gpio_register_controllers() now needs to be called from hook1
(can be configured by option STM32F4_ENABLE_GENERIC_GPIO)
- Updated license text for API files and STM32F4 GPIO files

v4:

- Fixed GPIO port guards
- Fixed potential memory-leak bug of STM32F4 GPIO interrupt system
- Added comments to STM32F4 GPIO functions and made them extern

Duc Doan (7):
  bsps/stm32f4 Include STM32F4 HAL
  bsps/arm: Integrate and build STM32F4 HAL
  bsps: Add GPIO API
  bsps/stm32f4: Add GPIO implementation for STM32F4
  bsps: Update license text
  bsps/stm32f4: Add missing GPIO functionality
  bsps/stm32f4: Fix GPIO port guards and ISR bug

 .gitignore| 1 +
 bsps/arm/include/cmsis_compiler.h |   266 +
 bsps/arm/include/cmsis_gcc.h  |  1152 +-
 bsps/arm/include/cmsis_version.h  |39 +
 bsps/arm/include/core_cm4.h   |  4066 +--
 bsps/arm/include/core_cm7.h   |   582 +-
 bsps/arm/include/legacy/cmsis_gcc.h   |  1375 ++
 bsps/arm/include/legacy/core_cm7.h|  2515 ++
 bsps/arm/include/mpu_armv7.h  |   270 +
 bsps/arm/stm32f4/gpio/gpio.c  |   556 +
 .../stm32f4/hal/Legacy/stm32f4xx_hal_can.c|  1679 ++
 .../stm32f4/hal/Legacy/stm32f4xx_hal_eth.c|  2307 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal.c  |   615 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_adc.c  |  2110 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_adc_ex.c   |  1112 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_can.c  |  2462 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_cec.c  |   996 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_cortex.c   |   502 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_crc.c  |   328 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_cryp.c |  7132 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_cryp_ex.c  |   680 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dac.c  |  1341 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dac_ex.c   |   495 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dcmi.c |  1161 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dcmi_ex.c  |   182 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dfsdm.c|  4423 
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dma.c  |  1305 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dma2d.c|  2126 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dma_ex.c   |   313 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_dsi.c  |  2760 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_eth.c  |  3112 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_exti.c |   547 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_flash.c|   775 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_flash_ex.c |  1347 +
 .../stm32f4/hal/stm32f4xx_hal_flash_ramfunc.c |   172 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_fmpi2c.c   |  6864 ++
 .../arm/stm32f4/hal/stm32f4xx_hal_fmpi2c_ex.c |   258 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_fmpsmbus.c |  2749 +++
 .../stm32f4/hal/stm32f4xx_hal_fmpsmbus_ex.c   |   145 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_gpio.c |   533 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_hash.c |  3514 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_hash_ex.c  |  1040 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_hcd.c  |  1728 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_i2c.c  |  7524 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_i2c_ex.c   |   182 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_i2s.c  |  2094 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_i2s_ex.c   |  1135 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_irda.c |  2687 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_iwdg.c |   262 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_lptim.c|  2484 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_ltdc.c |  2215 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_ltdc_ex.c  |   151 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_mmc.c  |  3201 +++
 .../stm32f4/hal/stm32f4xx_hal_msp_template.c  |   100 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_nand.c |  2405 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_nor.c  |  1543 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_pccard.c   |   946 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_pcd.c  |  2387 ++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_pcd_ex.c   |   341 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_pwr.c  |   571 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_pwr_ex.c   |   600 +
 bsps/arm/stm32f4/hal/stm32f4xx_hal_qspi.c |  2915 +++
 bsps/arm/stm32f4/hal/stm32f4xx_hal_rcc.c  

RE: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711

[Alan Cudmore]

Hi Noor,The plan works for me. Focus on Aarch64 and we can try to merge/consolidate headers after that.I don’t mind looking at GitHub branches to review work in progress. Is that OK with everyone else?Thanks,Alan  From: Noor AmanSent: Friday, July 22, 2022 11:10 AMTo: Alan CudmoreCc: j...@rtems.org; rtems-de...@rtems.org; Hesham Moustafa; William MooreSubject: Re: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711 Hey Alan, Sorry for the late reply. So here's my plan. I initially thought of editing the raspberrypi.h and making it compatible for every RPi bsp. But I think I'll just be working on Aarch64 only. So I'll define everything related to bcm2711, not bcm283x. And After I complete with RPi4 bsp, we can work on how to merge both the headers. Following up with some additional thoughts:I have already forked rtems github repo on my profile. https://github.com/0xNoor/rtems .Here's the link. I've added 2 additional branches named as noor-dev and noor-master. noor-master server as the backup branch just in case i break anything in my noor-dev branch. I keep on updating the branches with RTEMS:master branch. So every time I have a question, I just need to point to the part of the repo? I think that would be ok to do. So do I need to do this for getting a review too? And Thanks for rt-thread link. It solves my issue for mailbox and others too :)  On Fri, 22 Jul 2022 at 18:24, Alan Cudmore  wrote:Hi Noor,Following up with some additional thoughts:My approach for development for this BSP would be to focus on getting it working on a GitHub fork of the RTEMS repo. It could be messy while you are getting it working, but that is the fun part, in my opinion. If you need help or advice, you could send a message pointing us to parts of your repository.Once you have it working, we can figure out the best way to integrate it. Again, in my opinion, once you have something working, moving code around and reformatting is the easy part!Finally, you can submit the patches of the working BSP.Does this sound like a reasonable to everyone? It may not make sense for the community to review patches that may end up changing as the BSP is developed. I am taking a similar approach.. I have been slowly working on a BSP for the Kendryte K210 RISC-V processor. I have it working now, but soon I need to get input for the best way to integrate it with the existing RISC-V BSPs. Thanks for working on this!Alan  From: Alan CudmoreSent: Thursday, July 21, 2022 10:59 PMTo: j...@rtems.orgCc: Noor Aman; rtems-de...@rtems.org; Hesham Moustafa; William MooreSubject: Re: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711 Joel, I don't think we need to commit the file now.Some suggestions:- Let's not put RPI2 or RPI3 defines or ifdefs in the file if it's only going to be for the Aarch64 RPI4 BSP- If it will be only used for the RPI4, it might be confusing to have the BCM2836 defines rather than using BCM2711- If we really can share most of the defines between the RPI2 and RPI4 bsps, is there any way we can have a common include in the bsps/shared directory? Something like bcm_soc.h that has common defines for all raspberry Pi models? That would require changes to the Raspberry Pi 1 and 2 BSPs but it would avoid duplication of code.I also wonder if we can end up taking advantage of shared drivers such as the pl011 serial driver. Another source of info that may be helpful is the RT-Thread RTOS. They have RPI 2, 3, and 4 BSPs. The RPI4 has 32 and 64 bit versions. In addition the RTOS is Apache 2.0 licensed, so that may be easier to re-use (Please correct me if I'm wrong on the license usage!)https://github.com/RT-Thread/rt-thread/tree/master/bsp/raspberry-pi/raspi4-64 Thanks,Alan On Thu, Jul 21, 2022 at 2:01 PM Joel Sherrill  wrote:  On Thu, Jul 21, 2022 at 12:32 PM Noor Aman  wrote:I dont think this would be visible to any other application until or unless user explicitly include this header 'raspberrypi.h' in their application. And as of now, this header is only placed in bsps/arm/raspberrypi/includes. Sorry. My mistake. I was thinking it was in bsp.h. :( For my project I'm thinking of using this header with my project with bcm2711 addresses included. For my project, this header will go under bsps/aarch64/raspberrypi/includes. So I don't think this will create any problem for other BSPs.  This will be ok. A file has to explicitly include it. If you think it is ready to commit, I'm happy to do it if Alan or someone else also acks. --joel  On Thu, Jul 21, 2022, 10:16 PM Joel Sherrill  wrote:This looks generally ok but is all this visible to any application that includes bsp.h?  It might all need to be moved into a separate header to avoid contaminating everyone's namespace. On Thu, Jul 21, 2022, 10:56 AM Noor Aman  wrote:A brief gist of what i found compatible with the older code---COMPATIBLE HEADER BCM2835 timer- 

Re: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711

[Noor Aman]

Hey Alan, Sorry for the late reply.
So here's my plan. I initially thought of editing the raspberrypi.h and
making it compatible for every RPi bsp. But I think I'll just be working on
Aarch64 only. So I'll define everything related to bcm2711, not bcm283x.
And After I complete with RPi4 bsp, we can work on how to merge both the
headers.

> Following up with some additional thoughts:
>
I have already forked rtems github repo on my profile.
https://github.com/0xNoor/rtems .Here's the link. I've added 2 additional
branches named as noor-dev and noor-master. noor-master server as the
backup branch just in case i break anything in my noor-dev branch. I keep
on updating the branches with RTEMS:master branch.

So every time I have a question, I just need to point to the part of the
repo? I think that would be ok to do. So do I need to do this for getting a
review too?
And Thanks for rt-thread link. It solves my issue for mailbox and others
too :)


On Fri, 22 Jul 2022 at 18:24, Alan Cudmore  wrote:

> Hi Noor,
>
> Following up with some additional thoughts:
>
>- My approach for development for this BSP would be to focus on
>getting it working on a GitHub fork of the RTEMS repo. It could be messy
>while you are getting it working, but that is the fun part, in my opinion.
>If you need help or advice, you could send a message pointing us to parts
>of your repository.
>- Once you have it working, we can figure out the best way to
>integrate it. Again, in my opinion, once you have something working, moving
>code around and reformatting is the easy part!
>- Finally, you can submit the patches of the working BSP.
>
> Does this sound like a reasonable to everyone? It may not make sense for
> the community to review patches that may end up changing as the BSP is
> developed.
>
>
>
> I am taking a similar approach.. I have been slowly working on a BSP for
> the Kendryte K210 RISC-V processor. I have it working now, but soon I need
> to get input for the best way to integrate it with the existing RISC-V BSPs.
>
>
>
> Thanks for working on this!
>
> Alan
>
>
>
>
>
> *From: *Alan Cudmore 
> *Sent: *Thursday, July 21, 2022 10:59 PM
> *To: *j...@rtems.org
> *Cc: *Noor Aman ; rtems-de...@rtems.org
> ; Hesham Moustafa ; William
> Moore 
> *Subject: *Re: [PATCH] Arm/raspberrypi.h: Added relevant headers for the
> bcm2711
>
>
>
> Joel, I don't think we need to commit the file now.
>
> Some suggestions:
>
> - Let's not put RPI2 or RPI3 defines or ifdefs in the file if it's only
> going to be for the Aarch64 RPI4 BSP
>
> - If it will be only used for the RPI4, it might be confusing to have the
> BCM2836 defines rather than using BCM2711
>
> - If we really can share most of the defines between the RPI2 and RPI4
> bsps, is there any way we can have a common include in the bsps/shared
> directory? Something like bcm_soc.h that has common defines for all
> raspberry Pi models? That would require changes to the Raspberry Pi 1 and 2
> BSPs but it would avoid duplication of code.
>
> I also wonder if we can end up taking advantage of shared drivers such as
> the pl011 serial driver.
>
>
>
> Another source of info that may be helpful is the RT-Thread RTOS. They
> have RPI 2, 3, and 4 BSPs. The RPI4 has 32 and 64 bit versions. In addition
> the RTOS is Apache 2.0 licensed, so that may be easier to re-use (Please
> correct me if I'm wrong on the license usage!)
>
>
> https://github.com/RT-Thread/rt-thread/tree/master/bsp/raspberry-pi/raspi4-64
>
>
>
> Thanks,
>
> Alan
>
>
>
> On Thu, Jul 21, 2022 at 2:01 PM Joel Sherrill  wrote:
>
>
>
>
>
> On Thu, Jul 21, 2022 at 12:32 PM Noor Aman  wrote:
>
> I dont think this would be visible to any other application until or
> unless user explicitly include this header 'raspberrypi.h' in their
> application. And as of now, this header is only placed in
> bsps/arm/raspberrypi/includes.
>
>
>
> Sorry. My mistake. I was thinking it was in bsp.h. :(
>
>
>
> For my project I'm thinking of using this header with my project with
> bcm2711 addresses included. For my project, this header will go under
> bsps/aarch64/raspberrypi/includes. So I don't think this will create any
> problem for other BSPs.
>
>
>
> This will be ok. A file has to explicitly include it.
>
>
>
> If you think it is ready to commit, I'm happy to do it if Alan or someone
> else also acks.
>
>
>
> --joel
>
>
>
> On Thu, Jul 21, 2022, 10:16 PM Joel Sherrill  wrote:
>
> This looks generally ok but is all this visible to any application that
> includes bsp.h?
>
>
>
> It might all need to be moved into a separate header to avoid
> contaminating everyone's namespace.
>
>
>
> On Thu, Jul 21, 2022, 10:56 AM Noor Aman  wrote:
>
> A brief gist of what i found compatible with the older code
>
> ---COMPATIBLE HEADER---
>
> - BCM2835 timer
>
> - GPIO
>
> - AUX
>
> - GPU timer
>
> ---DIDNT CHECK---
>
> - SPI
>
> - I2C
>
> ---MINOR CHNAGE---
>
> - IRQ
>
> - FIQ
>
> ---NOT SURE ABOUT---
>
> - Watchdog
>
> - Power management

Re: [PATCH 1/2] basp/aarch64: Make the unexpected sections origin address 64bit

[Kinsey Moore]

Has this patch been tested with ILP32? I suspect that this line might 
need to get yanked out to a shared lp64 linkcmds.base and a shared ilp32 
linkcmds.base or this line pulled up into the bsp-specific linkcmds 
variants.



Kinsey

On 7/22/2022 01:35, chr...@rtems.org wrote:

From: Chris Johns 

Update #4684
---
  bsps/aarch64/shared/start/linkcmds.base | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/aarch64/shared/start/linkcmds.base 
b/bsps/aarch64/shared/start/linkcmds.base
index bcdf4715d7..f4639bd990 100644
--- a/bsps/aarch64/shared/start/linkcmds.base
+++ b/bsps/aarch64/shared/start/linkcmds.base
@@ -56,7 +56,7 @@ bsp_stack_hyp_size = DEFINED (bsp_stack_hyp_size) ? 
bsp_stack_hyp_size : 0;
  bsp_stack_hyp_size = ALIGN (bsp_stack_hyp_size, bsp_stack_align);
  
  MEMORY {

-   UNEXPECTED_SECTIONS : ORIGIN = 0x, LENGTH = 0
+   UNEXPECTED_SECTIONS : ORIGIN = 0x, LENGTH = 0
  }
  
  SECTIONS {

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

RE: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711

[Alan Cudmore]

Hi Noor,Following up with some additional thoughts:My approach for development for this BSP would be to focus on getting it working on a GitHub fork of the RTEMS repo. It could be messy while you are getting it working, but that is the fun part, in my opinion. If you need help or advice, you could send a message pointing us to parts of your repository.Once you have it working, we can figure out the best way to integrate it. Again, in my opinion, once you have something working, moving code around and reformatting is the easy part!Finally, you can submit the patches of the working BSP.Does this sound like a reasonable to everyone? It may not make sense for the community to review patches that may end up changing as the BSP is developed. I am taking a similar approach.. I have been slowly working on a BSP for the Kendryte K210 RISC-V processor. I have it working now, but soon I need to get input for the best way to integrate it with the existing RISC-V BSPs. Thanks for working on this!Alan  From: Alan CudmoreSent: Thursday, July 21, 2022 10:59 PMTo: j...@rtems.orgCc: Noor Aman; rtems-de...@rtems.org; Hesham Moustafa; William MooreSubject: Re: [PATCH] Arm/raspberrypi.h: Added relevant headers for the bcm2711 Joel, I don't think we need to commit the file now.Some suggestions:- Let's not put RPI2 or RPI3 defines or ifdefs in the file if it's only going to be for the Aarch64 RPI4 BSP- If it will be only used for the RPI4, it might be confusing to have the BCM2836 defines rather than using BCM2711- If we really can share most of the defines between the RPI2 and RPI4 bsps, is there any way we can have a common include in the bsps/shared directory? Something like bcm_soc.h that has common defines for all raspberry Pi models? That would require changes to the Raspberry Pi 1 and 2 BSPs but it would avoid duplication of code.I also wonder if we can end up taking advantage of shared drivers such as the pl011 serial driver. Another source of info that may be helpful is the RT-Thread RTOS. They have RPI 2, 3, and 4 BSPs. The RPI4 has 32 and 64 bit versions. In addition the RTOS is Apache 2.0 licensed, so that may be easier to re-use (Please correct me if I'm wrong on the license usage!)https://github.com/RT-Thread/rt-thread/tree/master/bsp/raspberry-pi/raspi4-64 Thanks,Alan On Thu, Jul 21, 2022 at 2:01 PM Joel Sherrill  wrote:  On Thu, Jul 21, 2022 at 12:32 PM Noor Aman  wrote:I dont think this would be visible to any other application until or unless user explicitly include this header 'raspberrypi.h' in their application. And as of now, this header is only placed in bsps/arm/raspberrypi/includes. Sorry. My mistake. I was thinking it was in bsp.h. :( For my project I'm thinking of using this header with my project with bcm2711 addresses included. For my project, this header will go under bsps/aarch64/raspberrypi/includes. So I don't think this will create any problem for other BSPs.  This will be ok. A file has to explicitly include it. If you think it is ready to commit, I'm happy to do it if Alan or someone else also acks. --joel  On Thu, Jul 21, 2022, 10:16 PM Joel Sherrill  wrote:This looks generally ok but is all this visible to any application that includes bsp.h?  It might all need to be moved into a separate header to avoid contaminating everyone's namespace. On Thu, Jul 21, 2022, 10:56 AM Noor Aman  wrote:A brief gist of what i found compatible with the older code---COMPATIBLE HEADER BCM2835 timer- GPIO- AUX- GPU timer---DIDNT CHECK SPI- I2C---MINOR CHNAGE IRQ- FIQ---NOT SURE ABOUT Watchdog- Power management- Mailbox register I didnt get any info about power management or watchdog or mailboxes. (It isnt in the BCM2835 Documention too I think??) And to answer your question Alan about if the Aarch64 would require a DTB or not which you asked me quite earlier. I can say now, you dont, because every address is defined here already so no need for the DTB.   diff --git a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.hindex eeb48c42f1..a4ed2a01d1 100644--- a/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h+++ b/bsps/aarch64/raspberrypi/include/bsp/raspberrypi.h@@ -52,15 +52,23 @@  * @{  */ -#if (BSP_IS_RPI2 == 1)-  #define RPI_PERIPHERAL_BASE    0x3F00+#if (RPI_BSP == RPI2)+  #define RPI_PERIPHERAL_BASE    0X3F00   #define BASE_OFFSET            0X3F00++#elif (RPI_BSP == RPI4)+  #define RPI_PERIPHERAL_BASE 0xFE00+  #define BASE_OFFSET 0xFE00+  #define RPI_PERIPHERAL_SIZE    0x0180+ #else   #define RPI_PERIPHERAL_BASE    0x2000   #define BASE_OFFSET            0X5E00+   #endif -#define RPI_PERIPHERAL_SIZE      0x0100+#ifndef RPI_PERIPHERAL_SIZE+#define RPI_PERIPHERAL_SIZE     0x0100  /**  * @name Bus to Physical address translation@@ -543,6 +551,188 @@ #define BCM2836_IRQ_SOURCE_PMU            0x0200 #define 

Re: [PATCH] score: Remove PRIORITY_PSEUDO_ISR thread priority

[Sebastian Huber]

On 21.07.22 16:20, Joel Sherrill wrote:



On Thu, Jul 21, 2022 at 12:53 AM Sebastian Huber 
> wrote:


Hello Gedare and Joel,

On 15.07.22 10:43, Sebastian Huber wrote:
 > The uniprocessor schedulers had some special case logic for the
 > PRIORITY_PSEUDO_ISR priority.  Tasks with a priority of
PRIORITY_PSEUDO_ISR
 > were allowed to preempt a not preemptible task.  If other higher
priority task
 > are made ready while a PRIORITY_PSEUDO_ISR task preempts a not
preemptible
 > task, then the other tasks run before the not preemptible task. 
This made the

 > RTEMS_NO_PREEMPT mode ineffective.
 >
 > Remove the PRIORITY_PSEUDO_ISR special case logic.  This
simplifies the
 > uniprocessor schedulers.  Move the uniprocessor-specific
scheduler support to
 > the new header file .
 >
 > Close #2365.


I'm guessing that  PRIORITY_PSEUDO_ISR wasn't used outside RTEMS itself
and likely only historically for the Timer Server Thread. The protection 
for that
thread was reworked as part of the SMP efforts. If it is used outside 
RTEMS,

that would be a user facing breakage and should be documented.

If you think all the use cases of PRIORITY_PSEUDO_ISR are accounted for,
I'm ok with removing it.


The pseudo-interrupt priority is mentioned in a glossary entry:

priority boosting
A simple approach to extend the priority inheritance protocol for
clustered scheduling is priority boosting.  In case a mutex is 
owned by a
task of another cluster, then the priority of the owner task is 
raised to

an artificially high priority, the pseudo-interrupt priority.

This entry was added for the clustered scheduling documentation and 
needs to be changed.


I found no reference to the no-preempt break of the pseudo-interrupt 
priority in the documentation. I doubt that there is an application 
which relies on this extraordinary feature.


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

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

Re: Integrating the Formal Methods part of Qualification

[andrew.butterfi...@scss.tcd.ie]

Dear RTEMS developers,

thanks for the feedback below - I want to wrap this up and move to the next 
step.

I propose to produce a complete draft of a formal methods section for the 
Software Engineering manual in rtems-docs
This will add a "Formal Verification" section just after the existing "Test 
Framework" section.

This will allow developers to get a much better idea of what is proposed, and 
for me to get feedback.

For now, the section will state clearly at the start that this is a proposal 
and that the tooling and resources it describes
won't yet be available in RTEMS proper.

Files likely to be modified in rtems-docs:
eng/index.rst
common/refs.bib

I'll add in  eng/formal-verification.rst

I'll then submit patches for review in the usual way.

Regards,
  Andrew



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



On 11/07/2022, 12:43, "devel on behalf of 
andrew.butterfi...@scss.tcd.ie" 
mailto:devel-boun...@rtems.org> on behalf of 
andrew.butterfi...@scss.tcd.ie> wrote:

On 6 Jul 2022, at 20:07, Gedare Bloom  wrote:

On Sun, Jul 3, 2022 at 7:49 PM Chris Johns  wrote:

On 2/7/2022 12:59 am, Andrew Butterfield wrote:
On 1 Jul 2022, at 00:59, Chris Johns mailto:chr...@rtems.org>> wrote:

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

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

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

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

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

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

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

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

How do you feel I should best proceed?

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

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

Thanks.
+1



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

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


Where are you looking to add these pieces?

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

Using rtems-central is fine.
Do they require anything currently located in rtems-central? Are the
models or YAML files related to the current specification files? I
know I'm guilty of not spending the time yet to deeply learn
rtems-central, but I would like to know that these files will fit
within that repo as it currently is intended to operate.

At the moment there is nothing in rtems-central directly related to this. All 
the python
scripts there support the tools/specs that Sebastian and 

Re: [PATCH 2/2] aarch64/versal: Support DDRMC0 region 0 and 1

[Chris Johns]

On 22/7/2022 4:35 pm, chr...@rtems.org wrote:
> +void bsp_r1_heap_extend(void);
> +void bsp_r1_heap_extend(void)
> +{
> +  const aarch64_mmu_config_entry* r1 = _r1_region[0];
> +  if (false && r1->begin != r1->end) {

Hmmm, I left a check in while debugging something and removing the false is
crashing. I am looking into this.

> +rtems_heap_extend((void*) r1->begin, r1->end - r1->begin);
> +  }
> +}

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

[PATCH 2/2] aarch64/versal: Support DDRMC0 region 0 and 1

[chrisj]

From: Chris Johns 

- Support DDRMC0 region 0 up to 2G in size

- Support DDRMC0 region 1 with DDR memory greater than 2G
  up to the DDRMC0 max amount

- Extend the heap with region 1's memory

Closes #4684
---
 bsps/aarch64/xilinx-versal/include/bsp.h  |  9 
 bsps/aarch64/xilinx-versal/start/bspstart.c   |  2 +
 .../aarch64/xilinx-versal/start/bspstartmmu.c | 36 ++
 .../aarch64/xilinx-versal/linkcmds_lp64.yml   | 48 +--
 4 files changed, 90 insertions(+), 5 deletions(-)

diff --git a/bsps/aarch64/xilinx-versal/include/bsp.h 
b/bsps/aarch64/xilinx-versal/include/bsp.h
index 2017e10ade..0bd93f28bc 100644
--- a/bsps/aarch64/xilinx-versal/include/bsp.h
+++ b/bsps/aarch64/xilinx-versal/include/bsp.h
@@ -47,6 +47,7 @@
 #ifndef ASM
 
 #include 
+#include 
 #include 
 
 #include 
@@ -61,6 +62,14 @@ extern "C" {
 
 #define BSP_RESET_SMC
 
+/*
+ * DDRMC mapping
+ */
+LINKER_SYMBOL(bsp_r0_ram_base)
+LINKER_SYMBOL(bsp_r0_ram_end)
+LINKER_SYMBOL(bsp_r1_ram_base)
+LINKER_SYMBOL(bsp_r1_ram_end)
+
 /**
  * @brief Versal specific set up of the MMU.
  *
diff --git a/bsps/aarch64/xilinx-versal/start/bspstart.c 
b/bsps/aarch64/xilinx-versal/start/bspstart.c
index 2f0048ddf3..86b3024dd2 100644
--- a/bsps/aarch64/xilinx-versal/start/bspstart.c
+++ b/bsps/aarch64/xilinx-versal/start/bspstart.c
@@ -38,6 +38,8 @@
 #include 
 #include 
 
+#include 
+
 void bsp_start( void )
 {
   bsp_interrupt_initialize();
diff --git a/bsps/aarch64/xilinx-versal/start/bspstartmmu.c 
b/bsps/aarch64/xilinx-versal/start/bspstartmmu.c
index 5949111d0d..c2fcd62c9f 100644
--- a/bsps/aarch64/xilinx-versal/start/bspstartmmu.c
+++ b/bsps/aarch64/xilinx-versal/start/bspstartmmu.c
@@ -38,6 +38,9 @@
 #include 
 #include 
 
+#include 
+#include 
+
 BSP_START_DATA_SECTION static const aarch64_mmu_config_entry
 versal_mmu_config_table[] = {
   AARCH64_MMU_DEFAULT_SECTIONS,
@@ -57,6 +60,24 @@ versal_mmu_config_table[] = {
 .begin = 0xff00U,
 .end = 0xffc0U,
 .flags = AARCH64_MMU_DEVICE
+  }, { /* DDRMC0_region1_mem, if not used size is 0 and ignored */
+.begin = (uintptr_t) bsp_r1_ram_base,
+.end = (uintptr_t) bsp_r1_ram_end,
+.flags = AARCH64_MMU_DATA_RW_CACHED
+  }
+};
+
+/*
+ * Create an MMU table to get the R1 base and end. This avoids
+ * relocation errors as the R1 addresses are in the upper A64 address
+ * space.
+ */
+static const aarch64_mmu_config_entry
+bsp_r1_region[] = {
+  { /* DDRMC0_region1_mem, if not used size is 0 and ignored */
+.begin = (uintptr_t) bsp_r1_ram_base,
+.end = (uintptr_t) bsp_r1_ram_end,
+.flags = 0
   }
 };
 
@@ -78,3 +99,18 @@ versal_setup_mmu_and_cache( void )
 
   aarch64_mmu_enable();
 }
+
+void bsp_r1_heap_extend(void);
+void bsp_r1_heap_extend(void)
+{
+  const aarch64_mmu_config_entry* r1 = _r1_region[0];
+  if (false && r1->begin != r1->end) {
+rtems_heap_extend((void*) r1->begin, r1->end - r1->begin);
+  }
+}
+
+RTEMS_SYSINIT_ITEM(
+  bsp_r1_heap_extend,
+  RTEMS_SYSINIT_MALLOC,
+  RTEMS_SYSINIT_ORDER_LAST
+);
diff --git a/spec/build/bsps/aarch64/xilinx-versal/linkcmds_lp64.yml 
b/spec/build/bsps/aarch64/xilinx-versal/linkcmds_lp64.yml
index 76c0220f0e..ca353d2662 100644
--- a/spec/build/bsps/aarch64/xilinx-versal/linkcmds_lp64.yml
+++ b/spec/build/bsps/aarch64/xilinx-versal/linkcmds_lp64.yml
@@ -4,7 +4,8 @@ content: |
   /* SPDX-License-Identifier: BSD-2-Clause */
 
   /*
-   * Copyright (C) 2021 Gedare Bloom  
+   * Copyright (C) 2021 Gedare Bloom 
+   * Copyright (C) 2022 Chris Johns 
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
@@ -28,10 +29,41 @@ content: |
* POSSIBILITY OF SUCH DAMAGE.
*/
 
+  /*
+   * The RAM supports 32G of DDR4 or LPDDR memory using DDRMC0.
+   *
+   * The DDR Conroller (DDRC) has two regions R0 and R1. R0 is
+   * in the A32 address space and R1 is in the A64 address space.
+   */
+  DDRMC0_REGION_0_BASE = 0x000;
+  DDRMC0_REGION_0_LENGTH = 0x0008000;
+  DDRMC0_REGION_1_BASE = 0x008;
+  DDRMC0_REGION_1_LENGTH = 0x010;
+
+  BSP_RAM_BASE = ${BSP_XILINX_VERSAL_RAM_BASE};
+
+  BSP_R0_RAM_BASE = DDRMC0_REGION_0_BASE;
+  BSP_R0_RAM_LENGTH =
+ ${BSP_XILINX_VERSAL_RAM_LENGTH} >= DDRMC0_REGION_0_LENGTH ?
+ DDRMC0_REGION_0_LENGTH - BSP_RAM_BASE : 
${BSP_XILINX_VERSAL_RAM_LENGTH};
+  BSP_R0_RAM_END = BSP_RAM_BASE + BSP_R0_RAM_LENGTH;
+
+  BSP_R1_RAM_BASE = DDRMC0_REGION_1_BASE;
+  BSP_R1_RAM_LENGTH =
+ ${BSP_XILINX_VERSAL_RAM_LENGTH} >= DDRMC0_REGION_0_LENGTH ?
+ ${BSP_XILINX_VERSAL_RAM_LENGTH} - DDRMC0_REGION_0_LENGTH : 0;
+
+  AARCH64_MMU_TT_PAGES_SIZE = 0x1000 * ${AARCH64_MMU_TRANSLATION_TABLE_PAGES};
+
   MEMORY {
-RAM   : ORIGIN = ${BSP_XILINX_VERSAL_RAM_BASE} + 
${BSP_XILINX_VERSAL_LOAD_OFFSET}, LENGTH = ${BSP_XILINX_VERSAL_RAM_LENGTH} - 
${BSP_XILINX_VERSAL_LOAD_OFFSET} - ${BSP_XILINX_VERSAL_NOCACHE_LENGTH} - 
(0x1000 * 

[PATCH 1/2] basp/aarch64: Make the unexpected sections origin address 64bit

[chrisj]

From: Chris Johns 

Update #4684
---
 bsps/aarch64/shared/start/linkcmds.base | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/aarch64/shared/start/linkcmds.base 
b/bsps/aarch64/shared/start/linkcmds.base
index bcdf4715d7..f4639bd990 100644
--- a/bsps/aarch64/shared/start/linkcmds.base
+++ b/bsps/aarch64/shared/start/linkcmds.base
@@ -56,7 +56,7 @@ bsp_stack_hyp_size = DEFINED (bsp_stack_hyp_size) ? 
bsp_stack_hyp_size : 0;
 bsp_stack_hyp_size = ALIGN (bsp_stack_hyp_size, bsp_stack_align);
 
 MEMORY {
-   UNEXPECTED_SECTIONS : ORIGIN = 0x, LENGTH = 0
+   UNEXPECTED_SECTIONS : ORIGIN = 0x, LENGTH = 0
 }
 
 SECTIONS {
-- 
2.19.1

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

versal: Support DDRMC0 region 0 and 1

[chrisj]

The Versal's DDRMC0 supports two separate regions. Region 0 is
from 0 up to 2G where the Versal's hard IP regions start. DDR
memory above the 2G mark is moved to region 1 and its base
address is in the A64 address space.

The patch will place all memory up to 2G in region 0 and if
more is present it is located in region 1. An MMU entry for the
region 1 memory is provided and the memory is added to the heap.

Chris


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