from:"Karel Gardas"

[PATCH 6/7] bsps/stm32h7: set default SDRAM x sizes on stm32h757i-eval-m4 BSP

2022-05-16 Thread Karel Gardas

This means:

SDRAM 1: 0
SDRAM 2: 32 MB

Sponsored-By:   Precidata
---
 spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml | 1 +
 spec/build/bsps/arm/stm32h7/optmemsdram2sz.yml | 1 +
 2 files changed, 2 insertions(+)

diff --git a/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml 
b/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml
index 4825a6446b..82267648a4 100644
--- a/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml
+++ b/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml
@@ -8,6 +8,7 @@ default-by-variant:
   variants:
   - arm/stm32h7b3i-dk
   - arm/stm32h757i-eval
+  - arm/stm32h757i-eval-m4
 enabled-by: true
 format: '{:#010x}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optmemsdram2sz.yml 
b/spec/build/bsps/arm/stm32h7/optmemsdram2sz.yml
index dff8a772e4..9fa8accbf4 100644
--- a/spec/build/bsps/arm/stm32h7/optmemsdram2sz.yml
+++ b/spec/build/bsps/arm/stm32h7/optmemsdram2sz.yml
@@ -7,6 +7,7 @@ default-by-variant:
 - value: 33554432
   variants:
   - arm/stm32h757i-eval
+  - arm/stm32h757i-eval-m4
 enabled-by: true
 format: '{:#010x}'
 links: []
-- 
2.25.1

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

[PATCH 7/7] bsps/stm32h7: disable all U(S)ARTs except USART1 on stm32h757i-eval-m4 BSP

2022-05-16 Thread Karel Gardas

This patch disables all U(S)ARTs which are not supported by the board
itself and its provided connectors.

Sponsored-By:   Precidata
---
 spec/build/bsps/arm/stm32h7/optenuart4.yml   | 1 +
 spec/build/bsps/arm/stm32h7/optenuart5.yml   | 1 +
 spec/build/bsps/arm/stm32h7/optenuart7.yml   | 1 +
 spec/build/bsps/arm/stm32h7/optenuart8.yml   | 1 +
 spec/build/bsps/arm/stm32h7/optenuart9.yml   | 1 +
 spec/build/bsps/arm/stm32h7/optenusart10.yml | 1 +
 spec/build/bsps/arm/stm32h7/optenusart2.yml  | 1 +
 spec/build/bsps/arm/stm32h7/optenusart3.yml  | 1 +
 spec/build/bsps/arm/stm32h7/optenusart6.yml  | 1 +
 9 files changed, 9 insertions(+)

diff --git a/spec/build/bsps/arm/stm32h7/optenuart4.yml 
b/spec/build/bsps/arm/stm32h7/optenuart4.yml
index 8665f4c821..73c1ebef1c 100644
--- a/spec/build/bsps/arm/stm32h7/optenuart4.yml
+++ b/spec/build/bsps/arm/stm32h7/optenuart4.yml
@@ -7,6 +7,7 @@ default-by-variant:
 - value: false
   variants:
   - arm/stm32h757i-eval
+  - arm/stm32h757i-eval-m4
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenuart5.yml 
b/spec/build/bsps/arm/stm32h7/optenuart5.yml
index f32f719f49..e445f2834f 100644
--- a/spec/build/bsps/arm/stm32h7/optenuart5.yml
+++ b/spec/build/bsps/arm/stm32h7/optenuart5.yml
@@ -8,6 +8,7 @@ default-by-variant:
   variants:
   - arm/stm32h7b3i-dk
   - arm/stm32h757i-eval
+  - arm/stm32h757i-eval-m4
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenuart7.yml 
b/spec/build/bsps/arm/stm32h7/optenuart7.yml
index bd9ed8fe76..225c9efa22 100644
--- a/spec/build/bsps/arm/stm32h7/optenuart7.yml
+++ b/spec/build/bsps/arm/stm32h7/optenuart7.yml
@@ -8,6 +8,7 @@ default-by-variant:
   variants:
   - arm/stm32h7b3i-dk
   - arm/stm32h757i-eval
+  - arm/stm32h757i-eval-m4
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenuart8.yml 
b/spec/build/bsps/arm/stm32h7/optenuart8.yml
index 74304e1256..96b869907d 100644
--- a/spec/build/bsps/arm/stm32h7/optenuart8.yml
+++ b/spec/build/bsps/arm/stm32h7/optenuart8.yml
@@ -8,6 +8,7 @@ default-by-variant:
   variants:
   - arm/stm32h7b3i-dk
   - arm/stm32h757i-eval
+  - arm/stm32h757i-eval-m4
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenuart9.yml 
b/spec/build/bsps/arm/stm32h7/optenuart9.yml
index 76378c622d..864948fc91 100644
--- a/spec/build/bsps/arm/stm32h7/optenuart9.yml
+++ b/spec/build/bsps/arm/stm32h7/optenuart9.yml
@@ -8,6 +8,7 @@ default-by-variant:
   variants:
   - arm/stm32h7b3i-dk
   - arm/stm32h757i-eval
+  - arm/stm32h757i-eval-m4
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenusart10.yml 
b/spec/build/bsps/arm/stm32h7/optenusart10.yml
index 1558bdb017..b60acf62a4 100644
--- a/spec/build/bsps/arm/stm32h7/optenusart10.yml
+++ b/spec/build/bsps/arm/stm32h7/optenusart10.yml
@@ -8,6 +8,7 @@ default-by-variant:
   variants:
   - arm/stm32h7b3i-dk
   - arm/stm32h757i-eval
+  - arm/stm32h757i-eval-m4
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenusart2.yml 
b/spec/build/bsps/arm/stm32h7/optenusart2.yml
index 05f73df137..b49d3315e0 100644
--- a/spec/build/bsps/arm/stm32h7/optenusart2.yml
+++ b/spec/build/bsps/arm/stm32h7/optenusart2.yml
@@ -8,6 +8,7 @@ default-by-variant:
 - value: false
   variants:
   - arm/stm32h757i-eval
+  - arm/stm32h757i-eval-m4
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenusart3.yml 
b/spec/build/bsps/arm/stm32h7/optenusart3.yml
index 1d676fdc3c..798aaed2a5 100644
--- a/spec/build/bsps/arm/stm32h7/optenusart3.yml
+++ b/spec/build/bsps/arm/stm32h7/optenusart3.yml
@@ -8,6 +8,7 @@ default-by-variant:
   variants:
   - arm/stm32h7b3i-dk
   - arm/stm32h757i-eval
+  - arm/stm32h757i-eval-m4
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optenusart6.yml 
b/spec/build/bsps/arm/stm32h7/optenusart6.yml
index 17761be7c3..a8ab30cba5 100644
--- a/spec/build/bsps/arm/stm32h7/optenusart6.yml
+++ b/spec/build/bsps/arm/stm32h7/optenusart6.yml
@@ -8,6 +8,7 @@ default-by-variant:
   variants:
   - arm/stm32h7b3i-dk
   - arm/stm32h757i-eval
+  - arm/stm32h757i-eval-m4
 enabled-by: true
 format: '{}'
 links: []
-- 
2.25.1

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

[PATCH 5/7] bsps/stm32h7: add configuration and enable build of stm32h757i-eval-m4 BSP

2022-05-16 Thread Karel Gardas

This is minimalist configuration for the stm32h757i-eval-m4 BSP provided
here. The only general enhancement worth mention is a flash origin address
configuration which is needed for simplification as M4 core boots
from second flash bank which starts at 0x810 by default. The boot
address of the core may be changed by using STM32CubeProgrammer. If done
so then also BSP configuration needs to be changed accordingly.

As the BSP variant is running on M4 core, there is also more configuration
changes required here. E.g. boot core and ABI (compilation flags)
in comparison with stm32h757i-eval BSP. On the other hand, C code is shared
completely with this BSP variant.

Sponsored-By:   Precidata
---
 spec/build/bsps/arm/stm32h7/abi.yml   |  9 +++-
 .../arm/stm32h7/bspstm32h757i-eval-m4.yml | 23 +++
 spec/build/bsps/arm/stm32h7/grp.yml   |  2 ++
 .../build/bsps/arm/stm32h7/linkcmdsmemory.yml |  2 +-
 spec/build/bsps/arm/stm32h7/optbootcore.yml   |  3 +++
 spec/build/bsps/arm/stm32h7/optlinkcmds.yml   |  1 +
 .../bsps/arm/stm32h7/optmemflashorigin.yml| 19 +++
 spec/build/bsps/arm/stm32h7/optmemflashsz.yml |  6 -
 spec/build/bsps/arm/stm32h7/optpwrsupply.yml  |  1 +
 .../bsps/arm/stm32h7/optusart1gpioregs.yml|  1 +
 spec/build/bsps/arm/stm32h7/optvariant.yml|  1 +
 11 files changed, 65 insertions(+), 3 deletions(-)
 create mode 100644 spec/build/bsps/arm/stm32h7/bspstm32h757i-eval-m4.yml
 create mode 100644 spec/build/bsps/arm/stm32h7/optmemflashorigin.yml

diff --git a/spec/build/bsps/arm/stm32h7/abi.yml 
b/spec/build/bsps/arm/stm32h7/abi.yml
index 697220b1b1..dd751cb72e 100644
--- a/spec/build/bsps/arm/stm32h7/abi.yml
+++ b/spec/build/bsps/arm/stm32h7/abi.yml
@@ -8,7 +8,14 @@ default:
 - -mcpu=cortex-m7
 - -mfpu=fpv5-d16
 - -mfloat-abi=hard
-default-by-variant: []
+default-by-variant:
+- value:
+  - -mthumb
+  - -mcpu=cortex-m4
+  - -mfpu=fpv4-sp-d16
+  - -mfloat-abi=hard
+  variants:
+  - arm/stm32h757i-eval-m4
 enabled-by: true
 links: []
 name: ABI_FLAGS
diff --git a/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval-m4.yml 
b/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval-m4.yml
new file mode 100644
index 00..588b97f7c3
--- /dev/null
+++ b/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval-m4.yml
@@ -0,0 +1,23 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+arch: arm
+bsp: stm32h757i-eval-m4
+build-type: bsp
+cflags: []
+copyrights:
+- Copyright (C) 2022 Karel Gardas 
+cppflags: []
+enabled-by: true
+family: stm32h7
+includes: []
+install: []
+links:
+- role: build-dependency
+  uid: grp
+- role: build-dependency
+  uid: tststm32h757i-eval
+source:
+- bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-config-clk.c
+- bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-config-osc.c
+- bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-config-per.c
+- bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c
+type: build
diff --git a/spec/build/bsps/arm/stm32h7/grp.yml 
b/spec/build/bsps/arm/stm32h7/grp.yml
index 6e7036b6aa..c056a2034b 100644
--- a/spec/build/bsps/arm/stm32h7/grp.yml
+++ b/spec/build/bsps/arm/stm32h7/grp.yml
@@ -51,6 +51,8 @@ links:
   uid: optmemflashsz
 - role: build-dependency
   uid: optmemflashlatency
+- role: build-dependency
+  uid: optmemflashorigin
 - role: build-dependency
   uid: optmemitcmsz
 - role: build-dependency
diff --git a/spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml 
b/spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml
index 7ff7f3da5e..78f0308832 100644
--- a/spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml
+++ b/spec/build/bsps/arm/stm32h7/linkcmdsmemory.yml
@@ -3,7 +3,7 @@ content: |
   MEMORY {
 NULL: ORIGIN = 0x, LENGTH = 
${STM32H7_MEMORY_NULL_SIZE:#010x}
 ITCM: ORIGIN = ${STM32H7_MEMORY_NULL_SIZE:#010x}, LENGTH = 
${STM32H7_MEMORY_ITCM_SIZE:#010x}
-FLASH   : ORIGIN = 0x0800, LENGTH = 
${STM32H7_MEMORY_FLASH_SIZE:#010x}
+FLASH   : ORIGIN = ${STM32H7_MEMORY_FLASH_ORIGIN:#010x}, LENGTH = 
${STM32H7_MEMORY_FLASH_SIZE:#010x}
 DTCM: ORIGIN = 0x2000, LENGTH = 
${STM32H7_MEMORY_DTCM_SIZE:#010x}
 SRAM_AXI: ORIGIN = 0x2400, LENGTH = 
${STM32H7_MEMORY_SRAM_AXI_SIZE:#010x}
 SRAM_1  : ORIGIN = 0x3000, LENGTH = 
${STM32H7_MEMORY_SRAM_1_SIZE:#010x}
diff --git a/spec/build/bsps/arm/stm32h7/optbootcore.yml 
b/spec/build/bsps/arm/stm32h7/optbootcore.yml
index 53ffb496cc..e6f52e8631 100644
--- a/spec/build/bsps/arm/stm32h7/optbootcore.yml
+++ b/spec/build/bsps/arm/stm32h7/optbootcore.yml
@@ -11,6 +11,9 @@ default-by-variant:
 - value: CORE_CM7
   variants:
   - arm/stm32h757i-eval
+- value: CORE_CM4
+  variants:
+  - arm/stm32h757i-eval-m4
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optlinkcmds.yml 
b/spec/build/bsps/arm/stm32h7/optlinkcmds.yml
index d767ade48c..f6e50f31ae 100644
--- a/spec/build/bsps/arm/stm32h7/optlinkcmds.yml
+++ b/spec/build/bsps/arm/stm32h7

Re: [PATCH] rtemstoolkit:libelf: sync _libelf_config.h with FreeBSD

2022-05-12 Thread Karel Gardas




Chris,

this is one patch for rtems-tools required for compilation on M1. It 
would be fantastic if you update the snapshot of tools and either let me 
know or make source-builder working with the new snapshot.


I'm going to submit few more patches for source-builder to fix various 
compilation issues on M1, but I think it would be silly if I provide a 
patch for rtems-tools to be included in source builder instead of 
directly fixing the issue in the git.


Thanks!
Karel

On 5/12/22 09:19, Karel Gardas wrote:

This fixes compilation issue on Apple M1.
---
  .../elftoolchain/libelf/_libelf_config.h  | 62 +++
  1 file changed, 21 insertions(+), 41 deletions(-)

diff --git a/rtemstoolkit/elftoolchain/libelf/_libelf_config.h 
b/rtemstoolkit/elftoolchain/libelf/_libelf_config.h
index 102aa01..0f16f3a 100644
--- a/rtemstoolkit/elftoolchain/libelf/_libelf_config.h
+++ b/rtemstoolkit/elftoolchain/libelf/_libelf_config.h
@@ -23,28 +23,14 @@
   * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
   * SUCH DAMAGE.
   *
- * $Id: _libelf_config.h 3566 2017-08-31 02:28:40Z emaste $
+ * $Id: _libelf_config.h 3764 2019-06-28 21:44:46Z emaste $
   */
  
-#if defined(__APPLE__) || defined(__DragonFly__)

-
-#ifdefined(__amd64__)
-#defineLIBELF_ARCH EM_X86_64
-#defineLIBELF_BYTEORDERELFDATA2LSB
-#defineLIBELF_CLASSELFCLASS64
-#elif  defined(__i386__)
-#defineLIBELF_ARCH EM_386
-#defineLIBELF_BYTEORDERELFDATA2LSB
-#defineLIBELF_CLASSELFCLASS32
-#endif
-
-#endif /* __DragonFly__ */
-
-#ifdef __FreeBSD__
+#if defined(__APPLE__) || defined(__DragonFly__) || defined(__FreeBSD__)
  
  /*

   * Define LIBELF_{ARCH,BYTEORDER,CLASS} based on the machine architecture.
- * See also: .
+ * See also:  on FreeBSD.
   */
  
  #if	defined(__amd64__)

@@ -91,6 +77,16 @@
  #endif
  #define   LIBELF_CLASSELFCLASS32
  
+#elif	defined(__powerpc64__)

+
+#defineLIBELF_ARCH EM_PPC64
+#if__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+#defineLIBELF_BYTEORDERELFDATA2LSB
+#else
+#defineLIBELF_BYTEORDERELFDATA2MSB
+#endif
+#defineLIBELF_CLASSELFCLASS64
+
  #elif defined(__powerpc__)
  
  #define	LIBELF_ARCH		EM_PPC

@@ -103,6 +99,12 @@
  #define   LIBELF_BYTEORDERELFDATA2LSB
  #define   LIBELF_CLASSELFCLASS64
  
+#elif	defined(__riscv64)

+
+#defineLIBELF_ARCH EM_RISCV
+#defineLIBELF_BYTEORDERELFDATA2LSB
+#defineLIBELF_CLASSELFCLASS64
+
  #elif defined(__sparc__)
  
  #define	LIBELF_ARCH		EM_SPARCV9

@@ -110,9 +112,9 @@
  #define   LIBELF_CLASSELFCLASS64
  
  #else

-#error Unknown FreeBSD architecture.
+#error Unknown architecture.
  #endif
-#endif  /* __FreeBSD__ */
+#endif  /*  defined(__APPLE__) || defined(__DragonFly__) || 
defined(__FreeBSD__) */
  
  /*

   * Definitions for Minix3.
@@ -187,25 +189,3 @@
  #endif
  
  #endif /* defined(__linux__) || defined(__GNU__) || defined(__GLIBC__) */

-
-#if defined(__WIN32__) || defined(__CYGWIN__)
-
-#define LIBELF_VCSID(ID)
-
-#if defined(__amd64__)
-
-#define LIBELF_ARCH EM_X86_64
-#define LIBELF_BYTEORDERELFDATA2LSB
-#define LIBELF_CLASSELFCLASS64
-
-#elif   defined(__i386__)
-
-#define LIBELF_ARCH EM_386
-#define LIBELF_BYTEORDERELFDATA2LSB
-#define LIBELF_CLASSELFCLASS32
-
-#else
-#error  Unknown Windows architecture.
-#endif
-
-#endif  /* __WIN32__ || __CYGWIN__ */


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

Re: Apple M1 compilation issue.

2022-05-16 Thread Karel Gardas


On 5/16/22 17:33, Andreas Enge wrote:

Hello Karel,

Am Mon, May 16, 2022 at 04:33:42PM +0200 schrieb Karel Gardas:

Could you be so kind and in next release use latest available autotools to
generate configure script and associated files? This way, problematic
config.sub file is generated with the proper support for Apple M1 hardware
and everything should be working again.


actually this is already part of our release process. I just tried with
the latest release of autoconf, 2.71, and got the following:


--- mpc/build-aux/config.sub.orig   2022-05-11 09:20:51.0 +0200
+++ mpc/build-aux/config.sub2022-05-11 09:23:47.0 +0200
@@ -916,6 +916,10 @@
+   arm64-*)
+   cpu=aarch64
+   vendor=`echo "$basic_machine" | sed 's/-.*//'`
+   ;;


timestamp='2021-08-14'
 arm64-*)
 cpu=aarch64
 ;;

So there is no vendor part. Would that be enough for your purposes?


I think so, but I don't have hardware here to test anymore.

Thanks!
Karel

PS: I wonder where this is downloaded from. The git repository of autoconf
 itself has an older version of that file from 2021-01-08.
 Ah, here: git clone https://git.savannah.gnu.org/git/config.git
 shows a config.sub from 2022-01-03, which has the same arm64 line.


Indeed!

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

Re: Apple M1 compilation issue.

2022-05-16 Thread Karel Gardas


On 5/16/22 16:45, Paul Zimmermann wrote:

Dear Karel,

yes, we'll take care of that in the next release of MPC.




Thanks for assurance. That's perfectly fine for us since now we may 
apply patch locally and schedule its removal on another MPC release.


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

Re: [PATCH] ISL, MPC, MPFR: fix configuration issues on ARM64/Darwin host

2022-05-16 Thread Karel Gardas


On 5/13/22 15:57, Joel Sherrill wrote:
We do not put patches in RTEMS repos. File an rtems ticket, attach them, 
and reference them from there.


If they are needed upstream, please submit them to the appropriate projects.


Joel,

based on the discussion I've created https://devel.rtems.org/ticket/4657 
-- hopefully this will be enough to accept interim solution and fix M1 
compilation issues.
I'll follow the possible replies, links on their archives and link them 
as go into the ticket for your reference.


Thanks,
Karel

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

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

2022-06-25 Thread Karel Gardas




Hello Duc,

one reminder, your API should be more or less portable. That means the 
example which you produce as a testing example should be API-wise 
portable between various BSPs. Is that clear?


I know, I know, sometimes user led 1 on F4 is on different port/pin on 
F7 and then on H7 you get it on even different port/pin, but!


> stm32f4_gpio_get_ctrl(GPIOD, );

do you expect this to be called from app running on RPi4 for example? Or 
on beagle bone white? Or on stm32h757i-eval board?


Please generalize and make that bit portable too.

Thanks,
Karel

On 6/25/22 15:00, Duc Doan wrote:

Hello Christian,

I forgot to send the sample code. Here it a code to turn on an LED:

/*/

// Obtain the pointer to the instance (port D)
rtems_gpio_ctrl_t *ctrl;
stm32f4_gpio_get_ctrl(GPIOD, );

// enable clocks for port D
rtems_gpio_initialize(ctrl);

// configure the pin
rtems_gpio_set_pin_mode(ctrl, _PIN, RTEMS_GPIO_PINMODE_OUTPUT_PP);
rtems_gpio_set_pull(ctrl, _PIN, RTEMS_GPIO_PULLUP);

// output to LED
rtems_gpio_write(ctrl, _PIN, RTEMS_GPIO_PIN_SET);

/*/

Best,

Duc Doan
___
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: [libbsd 1/7] CONTRIBUTING.rst: Add FreeBSD baseline update hints

2022-07-07 Thread Karel Gardas


On 7/7/22 14:02, Sebastian Huber wrote:

+Performa the following steps to do a FreeBSD baseline update:


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

Re: [PATCH] bsps/arm/stm32f4 Optimize get pin and change from HAL to LL

2022-07-07 Thread Karel Gardas


On 7/7/22 13:11, Duc Doan wrote:

Maybe it's as simple as renaming the identifiers from stm32f4_gpio =>
stm32_gpio for clarity for most functions, and declaring these files
in
the H7 scripts.



I think I will wait for Karel's opinion about that.


I just need to catch a bit of breath and then I'll test your driver on 
H7. I need that anyway so better use your API than LL/HAL. I'll see what 
I can do till the end of this week...


Karel

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

Re: [PATCH v2 3/4] bsps: Add GPIO API

2022-07-07 Thread Karel Gardas




Hello Duc,

just two notes which bothers me most.

On 7/7/22 13:34, Duc Doan wrote:

This is the new GPIO API. The header file is
gpio2.h.
---
  bsps/include/bsp/gpio2.h| 538 
  bsps/shared/dev/gpio/gpio.c | 196 +
  spec/build/bsps/obj.yml |   2 +-
  3 files changed, 735 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..e99967cd47
--- /dev/null
+++ b/bsps/include/bsp/gpio2.h
@@ -0,0 +1,538 @@
+/**
+  * @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.
+*/


RTEMS project (Joel & others) perform huge effort in a way on 
relicensing RTEMS to BSD license. Please use new license header instead 
of this one which is old -- from GPL days. Open few random RTEMS files 
and you will see few license headers. Look for example into ... randomly 
picked :-) -- 
bsps/arm/stm32h7/boards/stm/nucleo-h743zi/stm32h7-bspstarthooks.c and 
modify this to your name/email...




+/**
+  * @brief Performs setup for GPIO functionality.
+  *
+  * This function calls bsp_gpio_register_controllers() and may
+  * perform additional initialization steps for GPIO functionality.
+  * It should be called by users before all GPIO operations, ideally
+  * when the application starts.
+  */
+extern void rtems_gpio_begin(
+void
+);


I don't like this _begin mentality here. I think this should be all done 
by BSP code based on actual BSP configuration.

Something like:
STM32F4_ENABLE_GENERIC_GPIO implemented as optengpio.yml in f4 spec and 
then based on its C preprocessor value just calls 
bsp_gpio_register_controllers from probably hook_1 and be done with that.


Sorry about that, 'begin' is too much RDBMS hooked thing here and when I 
see 'begin' I also expect 'commit' or 'rollback' somewhere down the 
line. :-)


Thanks,
Karel



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

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

2022-06-27 Thread Karel Gardas




Hello Duc,

just one remark.

On 6/27/22 05:34, Duc Doan wrote:


rtems_gpio_ctrl_t *ctrl0 = bsp_gpio_get_ctrl(60); //corresponds to
GPIOD pin 12 on F4


^ if your ctrl structure knows you are working with pin 60


rtems_gpio_write(ctrl, 60, RTEMS_GPIO_PIN_SET);


then you do not need to use it for write.

In fact I guess ctrl structure would contain some BSP specific data and 
since bsp_gpio_get_ctrl is BSP specific function for f4 that means in 
ctrl you will save your GPIOx and pin number -- e.g. hardware specific 
pin representation.


This means on write/read you do not need to map virtual pin -> physical 
pin again, but in fact use physical pin from ctrl and be as fast as 
possible.


Christian described everything else already so no need to add anything here.

I'm glad you are making this steady progress on this project.

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

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

2022-06-26 Thread Karel Gardas


On 6/26/22 10:49, Duc Doan wrote:

#define rtems_gpio_get_ctrl(_driver, _arg, _out) \
  _driver##_gpio_get_ctrl( _arg , _out )

In the application code:

rtems_gpio_get_ctrl(stm32f4, GPIOD, _ctrl);
rtems_gpio_get_ctrl(stm32f4, GPIOA, _ctrl);


It's only a different method of writing the same. It won't solve
Karels
problem because it still wouldn't compile on another BSP.



Do you mean this application code should compile on other BSPs without
changing the source?


Yes, that's exactly what portability means and that's exactly what is 
desired outcome of the API here -- if I'm not mistaken in your project 
outcome specification. :-)


I'm not expert here, so please bear with me, but as I see it, you will 
need to come with some abstraction for groups and pins and write API 
around it. Then in BSP you will perform/provide a mapping between your 
abstracted group/pins construct and between actual hardware. This way, 
if I take example from stm32f4 and try to compile on rpi4, it will 
compile well -- but it will not run well (probably!) of course. But API 
wise, it will compile. Now, to make it run, I'll need to connect LED 
example following BSP specific mapping and for that I need to consult 
BSP docs.



I am a bit confused about that because I thought
at least we still need to specify the pin/port. And if we have multiple
GPIO controllers, we still need to select one right?


Yes, and this needs to be done in abstract manner mapped down into 
actual BSP implementation code. Abstract mapping here ensure portability 
between BSPs/boards.


E.g. for stm32f4 you do not select GPIOA group and pin1, but you select 
group 0 and pin 1 and in f4 BSP this group 0 is mapped to GPIOA and pin 
1 is mapped to its pin 1. -- something like that.


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

[PATCH 1/5] bsps/stm32h7: import MT25TL01G QSPI memory low-level driver

2022-06-10 Thread Karel Gardas

Sponsored-By:   Precidata
---
 .../stm/Components/mt25tl01g/mt25tl01g.c  | 1046 +
 .../stm/Components/mt25tl01g/mt25tl01g.h  |  362 ++
 .../stm/Components/mt25tl01g/mt25tl01g_conf.h |   68 ++
 3 files changed, 1476 insertions(+)
 create mode 100644 bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c
 create mode 100644 bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.h
 create mode 100644 
bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g_conf.h

diff --git a/bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c 
b/bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c
new file mode 100644
index 00..740cdbbd27
--- /dev/null
+++ b/bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c
@@ -0,0 +1,1046 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
+/**
+  
**
+  * @fileMT25TL01G.c
+  * @author  MCD Application Team
+  * @brief   This file provides the MT25TL01G QSPI driver.
+  
**
+  * @attention
+  *
+  *  Copyright (c) 2016 STMicroelectronics.
+  * All rights reserved.
+  *
+  * This software component is licensed by ST under BSD 3-Clause license,
+  * the "License"; You may not use this file except in compliance with the
+  * License. You may obtain a copy of the License at:
+  *opensource.org/licenses/BSD-3-Clause
+  *
+  
**
+  */
+/* Includes 
--*/
+#include "mt25tl01g.h"
+/** @addtogroup BSP
+  * @{
+  */
+
+/** @addtogroup Components
+  * @{
+  */
+
+/** @addtogroup MT25TL01G
+  * @brief This file provides a set of functions needed to drive the
+  * MT25TL01G QSPI memory.
+  * @{
+  */
+/** @defgroup MT25TL01G_Exported_Functions MT25TL01G Exported Functions
+  * @{
+  */
+
+/**
+  * @brief  Return the configuration of the QSPI memory.
+  * @param  pInfo pointer on the configuration structure
+  * @retval QSPI memory status
+  */
+int32_t MT25TL01G_GetFlashInfo(MT25TL01G_Info_t *pInfo)
+{
+  pInfo->FlashSize  = MT25TL01G_FLASH_SIZE;
+  pInfo->EraseSectorSize= (2 * MT25TL01G_SUBSECTOR_SIZE);
+  pInfo->ProgPageSize   = MT25TL01G_PAGE_SIZE;
+  pInfo->EraseSectorsNumber = (MT25TL01G_FLASH_SIZE/pInfo->EraseSectorSize);
+  pInfo->ProgPagesNumber= (MT25TL01G_FLASH_SIZE/pInfo->ProgPageSize);
+  return MT25TL01G_OK;
+}
+
+/**
+  * @brief  This function set the QSPI memory in 4-byte address mode
+  *  SPI/QPI; 1-0-1/4-0-4
+  * @param  Ctx Component object pointer
+  * @param  Mode Interface mode
+  * @retval QSPI memory status
+  */
+int32_t MT25TL01G_Enter4BytesAddressMode(QSPI_HandleTypeDef *Ctx, 
MT25TL01G_Interface_t Mode)
+{
+  QSPI_CommandTypeDef s_command;
+
+  /* Initialize the command */
+  s_command.InstructionMode   = (Mode == MT25TL01G_QPI_MODE) ? 
QSPI_INSTRUCTION_4_LINES : QSPI_INSTRUCTION_1_LINE;
+  s_command.Instruction   = MT25TL01G_ENTER_4_BYTE_ADDR_MODE_CMD;
+  s_command.AddressMode   = QSPI_ADDRESS_NONE;
+  s_command.AlternateByteMode = QSPI_ALTERNATE_BYTES_NONE;
+  s_command.DataMode  = QSPI_DATA_NONE;
+  s_command.DummyCycles   = 0;
+  s_command.DdrMode   = QSPI_DDR_MODE_DISABLE;
+  s_command.DdrHoldHalfCycle  = QSPI_DDR_HHC_ANALOG_DELAY;
+  s_command.SIOOMode  = QSPI_SIOO_INST_EVERY_CMD;
+
+  /*write enable */
+  if( MT25TL01G_WriteEnable(Ctx,Mode)!=MT25TL01G_OK)
+  {
+return MT25TL01G_ERROR_COMMAND;
+  }
+  /* Send the command */
+  if (HAL_QSPI_Command(Ctx, _command, HAL_QPSI_TIMEOUT_DEFAULT_VALUE) != 
HAL_OK)
+  {
+return MT25TL01G_ERROR_COMMAND;
+  }
+
+  /* Configure automatic polling mode to wait the memory is ready */
+  else if(MT25TL01G_AutoPollingMemReady(Ctx,Mode)!=MT25TL01G_OK)
+  {
+return MT25TL01G_ERROR_COMMAND;
+  }
+
+  return MT25TL01G_OK;
+}
+
+/**
+  * @brief  Flash exit 4 Byte address mode. Effect 3/4 address byte commands 
only.
+  * SPI/QPI; 1-0-0/4-0-0
+  * @param  Ctx Component object pointer
+  * @param  Mode Interface mode
+  * @retval QSPI memory status
+  */
+int32_t MT25TL01G_Exit4BytesAddressMode(QSPI_HandleTypeDef *Ctx, 
MT25TL01G_Interface_t Mode)
+{
+  QSPI_CommandTypeDef s_command;
+
+  /* Initialize the command */
+  s_command.InstructionMode   = (Mode == MT25TL01G_QPI_MODE) ? 
QSPI_INSTRUCTION_4_LINES : QSPI_INSTRUCTION_1_LINE;
+  s_command.Instruction   = MT25TL01G_EXIT_4_BYTE_ADDR_MODE_CMD;
+  s_command.AddressMode   = QSPI_ADDRESS_NONE;
+  s_command.AlternateByteMode = QSPI_ALTERNATE_BYTES_NONE;
+  s_command.DataMode  = QSPI_DATA_NONE;
+  s_command.DummyCycles   = 0;
+  s_command.DdrMode   = QSPI_DDR_MODE_DISABLE;
+  s_command.DdrHoldHalfCycle  = QSPI_DDR_HHC_ANALOG_DELAY;
+  s_command.SIOOMode  =

[PATCH 2/5] bsps/stm32h7: import stm32h757i-eval QSPI memory high-level driver

2022-06-10 Thread Karel Gardas

Sponsored-By:   Precidata
---
 .../stm32h757i-eval/stm32h747i_eval_conf.h|  130 ++
 .../stm32h757i-eval/stm32h747i_eval_errno.h   |  105 ++
 .../stm32h757i-eval/stm32h747i_eval_qspi.c| 1088 +
 .../stm32h757i-eval/stm32h747i_eval_qspi.h|  284 +
 4 files changed, 1607 insertions(+)
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_conf.h
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_errno.h
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_qspi.c
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_qspi.h

diff --git a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_conf.h 
b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_conf.h
new file mode 100644
index 00..673125eec3
--- /dev/null
+++ b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_conf.h
@@ -0,0 +1,130 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
+/** 
+  
**
+  * @filestm32h747i_eval_config.h
+  * @author  MCD Application Team
+  * @brief   STM32H747I_EVAL board configuration file.
+  
**
+  * @attention
+  *
+  * Copyright (c) 2019 STMicroelectronics.
+  * All rights reserved.
+  *
+  * This software is licensed under terms that can be found in the LICENSE file
+  * in the root directory of this software component.
+  * If no LICENSE file comes with this software, it is provided AS-IS.
+  *
+  
**
+  */
+/*
+ * RTEMS committer clarification comment on license above:
+ *
+ * This file comes from STM32CubeH7 project and is located here:
+ * 
https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/BSP/STM32H747I-EVAL/stm32h747i_eval_conf_template.h
+ *
+ * The file root directory is:
+ * 
https://github.com/STMicroelectronics/STM32CubeH7/tree/master/Drivers/BSP/STM32H747I-EVAL
+ *
+ * This directory contains LICENSE.md file with a following license text:
+ *
+ * Copyright 2019 STMicroelectronics.
+ * 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. 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.
+ */
+  
+/* Define to prevent recursive inclusion 
-*/
+#ifndef STM32H747I_EVAL_CONFIG_H
+#define STM32H747I_EVAL_CONFIG_H
+
+#ifdef __cplusplus
+ extern "C" {
+#endif
+
+/* Includes 
--*/
+#include "stm32h7xx_hal.h"
+
+   /* COM define */
+#define USE_COM_LOG 0U
+   
+   /* IO class usage define */  
+#define USE_BSP_IO_CLASS1U
+   
+   /* JOY usage define */
+#define USE_BSP_JOY_FEATURE 1U
+   
+   /* POT usage define */   
+#define USE_BSP_POT_FEATURE 1U
+   
+   /* LCD controllers defines */
+#define USE_LCD_CTRL_OTM8009A   1U
+#define USE_LCD_CTRL_ADV75331U
+#define LCD_LAYER_0_ADDRESS 0xD000U
+#define LCD_LAYER_1_ADDRESS 0xD020U
+   
+   /* SD high performance usage define */
+#define USE_SD_HIGH_PERFORMANCE 0U
+   
+   /*DMA2D to fill RGB rectangle usage define*/
+#define USE_DMA2D_TO_FILL_RGB_RECT  0U
+   
+   /* Audio codecs defines */
+#define USE_AUDIO_CODEC_WM8994  1U
+#define USE_AUDIO_CODEC_ADV7533

[PATCH 3/5] bsps/stm32h7: allow config and usage of QSPI memory on stm32h757i-eval BSP

2022-06-10 Thread Karel Gardas

The QSPI memory is initialized and used only when the BSP configure file
sets QSPI memory size to non-zero value. Currently QSPI is run in memory
mapped mode which allows future RTEMS binary linkage and upload into QSPI
memory.

Sponsored-By:   Precidata
---
 .../stm/stm32h757i-eval/stm32h7-bspstarthooks.c | 17 +
 bsps/arm/stm32h7/include/bsp.h  |  1 +
 .../bsps/arm/stm32h7/bspstm32h757i-eval.yml |  5 -
 spec/build/bsps/arm/stm32h7/optmemquadspisz.yml |  1 +
 4 files changed, 23 insertions(+), 1 deletion(-)

diff --git 
a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c 
b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
index 8d34e357ee..9916b740ce 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
@@ -36,6 +36,22 @@
 
 #include 
 
+#if defined(STM32H7_MEMORY_QUADSPI_SIZE) && STM32H7_MEMORY_QUADSPI_SIZE > 0
+#include 
+BSP_QSPI_Init_t QSPinit;
+#endif
+
+void stm32h7_init_qspi(void)
+{
+#if defined(STM32H7_MEMORY_QUADSPI_SIZE) && STM32H7_MEMORY_QUADSPI_SIZE > 0
+/* let's initialize Quad SPI memory here for memory mapped mode */
+memset((void*)&(QSPI_Ctx[0]), 0, sizeof(QSPI_Ctx[0]));
+memset((void*), 0, sizeof(BSP_QSPI_Init_t));
+BSP_QSPI_Init(0, );
+BSP_QSPI_EnableMemoryMappedMode(0);
+#endif
+}
+
 void bsp_start_hook_0(void)
 {
   if ((RCC->AHB3ENR & RCC_AHB3ENR_FMCEN) == 0) {
@@ -52,6 +68,7 @@ void bsp_start_hook_0(void)
 HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_HSI, RCC_MCODIV_1);
 HAL_Init();
 SystemInit_ExtMemCtl();
+stm32h7_init_qspi();
   }
 
 #if __CORTEX_M == 0x07U
diff --git a/bsps/arm/stm32h7/include/bsp.h b/bsps/arm/stm32h7/include/bsp.h
index 08311bf51e..cd4d25c069 100644
--- a/bsps/arm/stm32h7/include/bsp.h
+++ b/bsps/arm/stm32h7/include/bsp.h
@@ -62,6 +62,7 @@ void stm32h7_init_power(void);
 void stm32h7_init_oscillator(void);
 void stm32h7_init_clocks(void);
 void stm32h7_init_peripheral_clocks(void);
+void stm32h7_init_qspi(void);
 
 /** @} */
 
diff --git a/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval.yml 
b/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval.yml
index 5d7ee1348d..7516e55a3f 100644
--- a/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval.yml
+++ b/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval.yml
@@ -8,7 +8,8 @@ copyrights:
 cppflags: []
 enabled-by: true
 family: stm32h7
-includes: []
+includes:
+- bsps/arm/stm32h7/boards/stm/stm32h757i-eval
 install: []
 links:
 - role: build-dependency
@@ -16,6 +17,8 @@ links:
 - role: build-dependency
   uid: tststm32h757i-eval
 source:
+- bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c
+- bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_qspi.c
 - bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
 - bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-config-clk.c
 - bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-config-osc.c
diff --git a/spec/build/bsps/arm/stm32h7/optmemquadspisz.yml 
b/spec/build/bsps/arm/stm32h7/optmemquadspisz.yml
index 11e5f943e0..9337610b45 100644
--- a/spec/build/bsps/arm/stm32h7/optmemquadspisz.yml
+++ b/spec/build/bsps/arm/stm32h7/optmemquadspisz.yml
@@ -1,6 +1,7 @@
 actions:
 - get-integer: null
 - env-assign: null
+- define-unquoted: null
 build-type: option
 default: 0
 default-by-variant: []
-- 
2.25.1

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

[PATCH 4/5] bsps/stm32h7: import stm32h747i-disco QSPI memory high-level driver

2022-06-10 Thread Karel Gardas

Sponsored-By:   Precidata
---
 .../stm32h747i_discovery_conf.h   |  119 ++
 .../stm32h747i_discovery_errno.h  |  106 ++
 .../stm32h747i_discovery_qspi.c   | 1100 +
 .../stm32h747i_discovery_qspi.h   |  286 +
 4 files changed, 1611 insertions(+)
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h747i_discovery_conf.h
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h747i_discovery_errno.h
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h747i_discovery_qspi.c
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h747i_discovery_qspi.h

diff --git 
a/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h747i_discovery_conf.h 
b/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h747i_discovery_conf.h
new file mode 100644
index 00..8cacaddb7e
--- /dev/null
+++ b/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h747i_discovery_conf.h
@@ -0,0 +1,119 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
+/**
+  
**
+  * @filestm32h747i_discovery_conf_template.h
+  * @author  MCD Application Team
+  * @brief   STM32H747I_DISCO board configuration file.
+  
**
+  * @attention
+  *
+  * Copyright (c) 2018 STMicroelectronics.
+  * All rights reserved.
+  *
+  * This software is licensed under terms that can be found in the LICENSE file
+  * in the root directory of this software component.
+  * If no LICENSE file comes with this software, it is provided AS-IS.
+  *
+  
**
+  */
+/*
+ * RTEMS committer clarification comment on license above:
+ *
+ * This file comes from STM32CubeH7 project and is located here:
+ * 
https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/BSP/STM32H747I-DISCO/stm32h747i_discovery_conf_template.h
+ *
+ * The file root directory is:
+ * 
https://github.com/STMicroelectronics/STM32CubeH7/tree/master/Drivers/BSP/STM32H747I-DISCO
+ *
+ * This directory contains LICENSE.md file with a following license text:
+ *
+ * Copyright 2019 STMicroelectronics.
+ * 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. 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.
+ */
+
+/* Define to prevent recursive inclusion 
-*/
+#ifndef STM32H747I_DISCO_CONF_H
+#define STM32H747I_DISCO_CONF_H
+
+#ifdef __cplusplus
+ extern "C" {
+#endif
+
+/* Includes 
--*/
+#include "stm32h7xx_hal.h"
+
+/* COM define */
+#define USE_COM_LOG 0U
+#define USE_BSP_COM_FEATURE 0U
+
+/* LCD controllers defines */
+#define USE_LCD_CTRL_OTM8009A   1U
+#define USE_LCD_CTRL_ADV75331U
+
+#define LCD_LAYER_0_ADDRESS 0xC000U
+#define LCD_LAYER_1_ADDRESS 0xC020U
+
+#define USE_DMA2D_TO_FILL_RGB_RECT  0U
+/* Camera sensors defines */
+#define USE_CAMERA_SENSOR_OV56401U
+#define USE_CAMERA_SENSOR_OV96551U
+
+/* SD interface defines */
+#define USE_SD_BUS_WIDE_4B  1U
+
+/* Audio codecs defines */
+#define USE_AUDIO_CODEC_WM8994  1U
+
+/* TS supported features defines */
+#define USE_TS_GESTURE  1U
+#define USE_TS_MULTI_TOUCH  1U
+

[PATCH 5/5] bsps/stm32h7: allow config and usage of QSPI memory on stm32h747i-disco BSP

2022-06-10 Thread Karel Gardas

The QSPI memory is initialized and used only when the BSP configure file
sets QSPI memory size to non-zero value. Currently QSPI is run in memory
mapped mode which allows future RTEMS binary linkage and upload into QSPI
memory.

Sponsored-By:   Precidata
---
 .../stm32h747i-disco/stm32h7-bspstarthooks.c| 17 +
 .../bsps/arm/stm32h7/bspstm32h747i-disco.yml|  5 -
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git 
a/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-bspstarthooks.c 
b/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-bspstarthooks.c
index 8d34e357ee..e18bc3bca9 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-bspstarthooks.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-bspstarthooks.c
@@ -36,6 +36,22 @@
 
 #include 
 
+#if defined(STM32H7_MEMORY_QUADSPI_SIZE) && STM32H7_MEMORY_QUADSPI_SIZE > 0
+#include 
+BSP_QSPI_Init_t QSPinit;
+#endif
+
+void stm32h7_init_qspi(void)
+{
+#if defined(STM32H7_MEMORY_QUADSPI_SIZE) && STM32H7_MEMORY_QUADSPI_SIZE > 0
+/* let's initialize Quad SPI memory here for memory mapped mode */
+memset((void*)&(QSPI_Ctx[0]), 0, sizeof(QSPI_Ctx[0]));
+memset((void*), 0, sizeof(BSP_QSPI_Init_t));
+BSP_QSPI_Init(0, );
+BSP_QSPI_EnableMemoryMappedMode(0);
+#endif
+}
+
 void bsp_start_hook_0(void)
 {
   if ((RCC->AHB3ENR & RCC_AHB3ENR_FMCEN) == 0) {
@@ -52,6 +68,7 @@ void bsp_start_hook_0(void)
 HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_HSI, RCC_MCODIV_1);
 HAL_Init();
 SystemInit_ExtMemCtl();
+stm32h7_init_qspi();
   }
 
 #if __CORTEX_M == 0x07U
diff --git a/spec/build/bsps/arm/stm32h7/bspstm32h747i-disco.yml 
b/spec/build/bsps/arm/stm32h7/bspstm32h747i-disco.yml
index 8b13d16844..9111bcf051 100644
--- a/spec/build/bsps/arm/stm32h7/bspstm32h747i-disco.yml
+++ b/spec/build/bsps/arm/stm32h7/bspstm32h747i-disco.yml
@@ -8,7 +8,8 @@ copyrights:
 cppflags: []
 enabled-by: true
 family: stm32h7
-includes: []
+includes:
+- bsps/arm/stm32h7/boards/stm/stm32h747i-disco
 install: []
 links:
 - role: build-dependency
@@ -16,6 +17,8 @@ links:
 - role: build-dependency
   uid: tststm32h757i-eval
 source:
+- bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c
+- bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h747i_discovery_qspi.c
 - bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-bspstarthooks.c
 - bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-config-clk.c
 - bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-config-osc.c
-- 
2.25.1

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

[PATCH 1/2] rtems-bsps-arm: add new stm32h7 BSP variants

2022-06-04 Thread Karel Gardas

---
 config/rtems-bsps-arm.ini | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/config/rtems-bsps-arm.ini b/config/rtems-bsps-arm.ini
index 85067ff..1d38f1a 100644
--- a/config/rtems-bsps-arm.ini
+++ b/config/rtems-bsps-arm.ini
@@ -44,7 +44,8 @@ bsps = altcycv_devkit,
realview_pbx_a9_qemu,
rtl22xx, rtl22xx_t,
smdk2410,
-   stm32f105rc, stm32f4, stm32h7,
+   stm32f105rc, stm32f4, stm32h7, stm32h7b3i-dk, stm32h757i-eval,
+   stm32h757i-eval-m4, stm32h747i-disco, stm32h747i-disco-m4,
tms570ls3137_hdk, tms570ls3137_hdk_intram,
tms570ls3137_hdk_sdram,
tms570ls3137_hdk_with_loader,
@@ -73,6 +74,8 @@ exclude-smp = atsamv,
   rtl22xx, rtl22xx_t,
   smdk2410,
   stm32f105rc, stm32f4, stm32h7,
+  stm32h7b3i-dk, stm32h757i-eval, stm32h757i-eval-m4,
+  stm32h747i-disco, stm32h747i-disco-m4,
   tms570ls3137_hdk, tms570ls3137_hdk_intram,
   tms570ls3137_hdk_sdram,
   tms570ls3137_hdk_with_loader
-- 
2.25.1

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

[PATCH 2/2] rtems-bsps-tiers: add new stm32h7 BSP variants to the tier-3

2022-06-04 Thread Karel Gardas

---
 config/rtems-bsps-tiers.ini | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/config/rtems-bsps-tiers.ini b/config/rtems-bsps-tiers.ini
index d5ebc39..512ebcb 100644
--- a/config/rtems-bsps-tiers.ini
+++ b/config/rtems-bsps-tiers.ini
@@ -70,7 +70,8 @@ bsps_arm = altcycv_devkit,
 realview_pbx_a9_qemu,
 rtl22xx, rtl22xx_t,
 smdk2410,
-stm32f105rc, stm32f4, stm32h7,
+stm32f105rc, stm32f4, stm32h7, stm32h7b3i-dk, stm32h757i-eval,
+stm32h757i-eval-m4, stm32h747i-disco, stm32h747i-disco-m4,
 tms570ls3137_hdk, tms570ls3137_hdk_intram,
 tms570ls3137_hdk_sdram,
 tms570ls3137_hdk_with_loader,
-- 
2.25.1

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

[PATCH] bsps/arm: fix installation of core_cm4.h

2022-06-06 Thread Karel Gardas

---
 spec/build/bsps/arm/grp.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/spec/build/bsps/arm/grp.yml b/spec/build/bsps/arm/grp.yml
index a8ebe07f15..b45f9a8c12 100644
--- a/spec/build/bsps/arm/grp.yml
+++ b/spec/build/bsps/arm/grp.yml
@@ -9,6 +9,7 @@ install:
   source:
   - bsps/arm/include/cmsis_gcc.h
   - bsps/arm/include/core_cm7.h
+  - bsps/arm/include/core_cm4.h
   - bsps/arm/include/core_cmFunc.h
   - bsps/arm/include/core_cmInstr.h
   - bsps/arm/include/core_cmSimd.h
-- 
2.25.1

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

[PATCH 2/2] bsps/stm32h7: remove external memory initialization from nucleo-h743zi BSP

2022-06-03 Thread Karel Gardas

Nucleo board does not provide any external memory so code does not have
any function here anyway.

Sponsored-By:   Precidata
---
 .../boards/stm/nucleo-h743zi/ext-mem-ctl.c| 478 --
 .../stm/nucleo-h743zi/stm32h7-bspstarthooks.c |   1 -
 .../bsps/arm/stm32h7/bspnucleoh743zi.yml  |   1 -
 3 files changed, 480 deletions(-)
 delete mode 100644 bsps/arm/stm32h7/boards/stm/nucleo-h743zi/ext-mem-ctl.c

diff --git a/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/ext-mem-ctl.c 
b/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/ext-mem-ctl.c
deleted file mode 100644
index a2ab9d8f1f..00
--- a/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/ext-mem-ctl.c
+++ /dev/null
@@ -1,478 +0,0 @@
-/**
-  
**
-  * @filesystem_stm32h7xx.c
-  * @author  MCD Application Team
-  * @brief   CMSIS Cortex-M Device Peripheral Access Layer System Source File.
-  *
-  *   This file provides two functions and one global variable to be called 
from 
-  *   user application:
-  *  - SystemInit(): This function is called at startup just after reset 
and 
-  *  before branch to main program. This call is made 
inside
-  *  the "startup_stm32h7xx.s" file.
-  *
-  *  - SystemCoreClock variable: Contains the core clock (HCLK), it can be 
used
-  *  by the user application to setup the 
SysTick 
-  *  timer or configure other parameters.
-  * 
-  *  - SystemCoreClockUpdate(): Updates the variable SystemCoreClock and 
must
-  * be called whenever the core clock is 
changed
-  * during program execution.
-  *
-  *
-  
**
-  * @attention
-  *
-  *  Copyright (c) 2017 STMicroelectronics.
-  * All rights reserved.
-  *
-  * This software component is licensed by ST under BSD 3-Clause license,
-  * the "License"; You may not use this file except in compliance with the
-  * License. You may obtain a copy of the License at:
-  *opensource.org/licenses/BSD-3-Clause
-  *
-  
**
-  */
-
-#include 
-
-#define DATA_IN_ExtSRAM
-#define DATA_IN_ExtSDRAM
-
-void  SystemInit_ExtMemCtl(void)
-{
-
-  #define  FMC_BMAP_Value0x0200/* FMC Bank Mapping 2 (SDRAM Bank2 
remapped) */
-
-  __IO uint32_t  tmp = 0;
-
-
-  /** SDRAM + SRAM 
***/
-
-  #if defined (DATA_IN_ExtSDRAM) && defined (DATA_IN_ExtSRAM)
-
-  register uint32_t   tmpreg = 0, timeout = 0x;
-  register __IO uint32_t  index;
-  
-  /*-- I/O Ports Configuration 
--*/
-
-  /* Enable GPIOD, GPIOE, GPIOF, GPIOG, GPIOH and GPIOI interface clock */
-  RCC->AHB4ENR |= 0x01F8;
-  
-  /* Delay after an RCC peripheral clock enabling */
-  tmp = READ_BIT(RCC->AHB4ENR, RCC_AHB4ENR_GPIOEEN);
-  
-  /* Connect PDx pins to FMC Alternate function */ 
-  GPIOD->AFR[0]  = 0x00CC00CC;
-  GPIOD->AFR[1]  = 0x;
-  /* Configure PDx pins in Alternate function mode */  
-  GPIOD->MODER   = 0xFAFA;
-  /* Configure PDx pins speed to 100 MHz */  
-  GPIOD->OSPEEDR = 0x0F0F;
-  /* Configure PDx pins Output type to push-pull */  
-  GPIOD->OTYPER  = 0x;
-  /* Configure PDx pins in Pull-up */
-  GPIOD->PUPDR   = 0x0505;
-
-  /* Connect PEx pins to FMC Alternate function */
-  GPIOE->AFR[0]  = 0xC00CC0CC;
-  GPIOE->AFR[1]  = 0x;
-  /* Configure PEx pins in Alternate function mode */ 
-  GPIOE->MODER   = 0xBEBA;
-  /* Configure PEx pins speed to 100 MHz */ 
-  GPIOE->OSPEEDR = 0xC3CF;
-  /* Configure PEx pins Output type to push-pull */  
-  GPIOE->OTYPER  = 0x;
-  /* Configure PEx pins in Pull-up */
-  GPIOE->PUPDR   = 0x4145;
-
-  /* Connect PFx pins to FMC Alternate function */
-  GPIOF->AFR[0]  = 0x00CC;
-  GPIOF->AFR[1]  = 0xC000;
-  /* Configure PFx pins in Alternate function mode */   
-  GPIOF->MODER   = 0xAABFFAAA;
-  /* Configure PFx pins speed to 100 MHz */ 
-  GPIOF->OSPEEDR = 0xFFC00FFF;
-  /* Configure PFx pins Output type to push-pull */  
-  GPIOF->OTYPER  = 0x;
-  /* Configure PFx pins in Pull-up */
-  GPIOF->PUPDR   = 0x55400555;
-
-  /* Connect PGx pins to FMC Alternate function */
-  GPIOG->AFR[0]  = 0x00CC;
-  GPIOG->AFR[1]  = 0xCC0C;
-  /* Configure PGx pins in Alternate function mode */ 
-  GPIOG->MODER   = 0xBFEEFAAA;
-  /* Configure PGx pins speed to 100 MHz */ 
-  GPIOG->OSPEEDR = 0xC0330FFF;
-  /* Configure PGx pins Output type to push-pull */  
-  GPIOG->OTYPER  = 0x;
-  /* Configure PGx pins in Pull-up */ 
-  GPIOG->PUPDR   = 0x40110555;
-  
-  /* Connect PHx pins to FMC Alternate function */
-

[PATCH 1/2] bsps/stm32h7: move BSP start hooks into boards subdirectories

2022-06-03 Thread Karel Gardas

The idea here is to prepare for better per-board specialization
of the hooks function code.

Sponsored-By:   Precidata
---
 .../stm/nucleo-h743zi/stm32h7-bspstarthooks.c | 78 +++
 .../stm32h743i-eval/stm32h7-bspstarthooks.c   | 78 +++
 .../stm32h747i-disco/stm32h7-bspstarthooks.c  | 78 +++
 .../stm32h757i-eval/stm32h7-bspstarthooks.c   | 78 +++
 .../stm/stm32h7b3i-dk/stm32h7-bspstarthooks.c | 78 +++
 bsps/arm/stm32h7/include/bsp.h|  6 ++
 bsps/arm/stm32h7/start/bspstarthooks.c| 48 +---
 .../bsps/arm/stm32h7/bspnucleoh743zi.yml  |  1 +
 spec/build/bsps/arm/stm32h7/bspstm32h7.yml|  1 +
 .../arm/stm32h7/bspstm32h747i-disco-m4.yml|  1 +
 .../bsps/arm/stm32h7/bspstm32h747i-disco.yml  |  1 +
 .../arm/stm32h7/bspstm32h757i-eval-m4.yml |  1 +
 .../bsps/arm/stm32h7/bspstm32h757i-eval.yml   |  1 +
 .../bsps/arm/stm32h7/bspstm32h7b3i-dk.yml |  1 +
 14 files changed, 407 insertions(+), 44 deletions(-)
 create mode 100644 
bsps/arm/stm32h7/boards/stm/nucleo-h743zi/stm32h7-bspstarthooks.c
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-bspstarthooks.c
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-bspstarthooks.c
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/stm32h7-bspstarthooks.c

diff --git a/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/stm32h7-bspstarthooks.c 
b/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/stm32h7-bspstarthooks.c
new file mode 100644
index 00..8d34e357ee
--- /dev/null
+++ b/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/stm32h7-bspstarthooks.c
@@ -0,0 +1,78 @@
+/* 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+void bsp_start_hook_0(void)
+{
+  if ((RCC->AHB3ENR & RCC_AHB3ENR_FMCEN) == 0) {
+/*
+ * Only perform the low-level initialization if necessary.  An initialized
+ * FMC indicates that a boot loader already performed the low-level
+ * initialization.
+ */
+SystemInit();
+stm32h7_init_power();
+stm32h7_init_oscillator();
+stm32h7_init_clocks();
+stm32h7_init_peripheral_clocks();
+HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_HSI, RCC_MCODIV_1);
+HAL_Init();
+SystemInit_ExtMemCtl();
+  }
+
+#if __CORTEX_M == 0x07U
+  if ((SCB->CCR & SCB_CCR_IC_Msk) == 0) {
+SCB_EnableICache();
+  }
+
+  if ((SCB->CCR & SCB_CCR_DC_Msk) == 0) {
+SCB_EnableDCache();
+  }
+
+  _ARMV7M_MPU_Setup(stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
+#endif
+}
+
+void bsp_start_hook_1(void)
+{
+  bsp_start_copy_sections_compact();
+#if __CORTEX_M == 0x07U
+  SCB_CleanDCache();
+  SCB_InvalidateICache();
+#endif
+  bsp_start_clear_bss();
+}
diff --git 
a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-bspstarthooks.c 
b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-bspstarthooks.c
new file mode 100644
index 00..8d34e357ee
--- /dev/null
+++ b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-bspstarthooks.c
@@ -0,0 +1,78 @@
+/* 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

Re: [PATCH 3/5] bsps/stm32h7: allow config and usage of QSPI memory on stm32h757i-eval BSP

2022-06-17 Thread Karel Gardas


On 6/15/22 17:05, Gedare Bloom wrote:

+#endif
+
+void stm32h7_init_qspi(void)


Also, is this function declared somewhere?

Probably what you should do is to add this function declaration to
stm32h747i_eval_qspi.h, and include that file here always?


Yes, it is in bsps/arm/stm32h7/include/bsp.h:

[...]
/* default functions */
void stm32h7_init_power(void);
void stm32h7_init_oscillator(void);
void stm32h7_init_clocks(void);
void stm32h7_init_peripheral_clocks(void);
void stm32h7_init_qspi(void);
[...]

I think it should stay there instead of being moved into ST Micro code.

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

Re: [PATCH 3/5] bsps/stm32h7: allow config and usage of QSPI memory on stm32h757i-eval BSP

2022-06-17 Thread Karel Gardas


On 6/15/22 17:00, Gedare Bloom wrote:

On Fri, Jun 10, 2022 at 6:49 AM Karel Gardas  wrote:


The QSPI memory is initialized and used only when the BSP configure file
sets QSPI memory size to non-zero value. Currently QSPI is run in memory
mapped mode which allows future RTEMS binary linkage and upload into QSPI
memory.

Sponsored-By:   Precidata
---
  .../stm/stm32h757i-eval/stm32h7-bspstarthooks.c | 17 +
  bsps/arm/stm32h7/include/bsp.h  |  1 +
  .../bsps/arm/stm32h7/bspstm32h757i-eval.yml |  5 -
  spec/build/bsps/arm/stm32h7/optmemquadspisz.yml |  1 +
  4 files changed, 23 insertions(+), 1 deletion(-)

diff --git 
a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c 
b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
index 8d34e357ee..9916b740ce 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
@@ -36,6 +36,22 @@

  #include 

+#if defined(STM32H7_MEMORY_QUADSPI_SIZE) && STM32H7_MEMORY_QUADSPI_SIZE > 0
+#include 
+BSP_QSPI_Init_t QSPinit;


Do you need this variable to be in the global namespace? Can it be a
static variable here?


I've just resent patch version just for 757i-eval to make review simpler 
where I've switch to static variable here. It has its own pros/cons:


+ not populating global namespace
+ not require explicit initialization
- require to be used after BSS is initialized

So it's really a question what is prefefrred way here.

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

[PATCH 1/5] bsps/stm32h7: import MT25TL01G QSPI memory low-level driver

2022-06-17 Thread Karel Gardas

Sponsored-By:   Precidata
---
 .../stm/Components/mt25tl01g/mt25tl01g.c  | 1046 +
 .../stm/Components/mt25tl01g/mt25tl01g.h  |  362 ++
 .../stm/Components/mt25tl01g/mt25tl01g_conf.h |   68 ++
 3 files changed, 1476 insertions(+)
 create mode 100644 bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c
 create mode 100644 bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.h
 create mode 100644 
bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g_conf.h

diff --git a/bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c 
b/bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c
new file mode 100644
index 00..740cdbbd27
--- /dev/null
+++ b/bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c
@@ -0,0 +1,1046 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
+/**
+  
**
+  * @fileMT25TL01G.c
+  * @author  MCD Application Team
+  * @brief   This file provides the MT25TL01G QSPI driver.
+  
**
+  * @attention
+  *
+  *  Copyright (c) 2016 STMicroelectronics.
+  * All rights reserved.
+  *
+  * This software component is licensed by ST under BSD 3-Clause license,
+  * the "License"; You may not use this file except in compliance with the
+  * License. You may obtain a copy of the License at:
+  *opensource.org/licenses/BSD-3-Clause
+  *
+  
**
+  */
+/* Includes 
--*/
+#include "mt25tl01g.h"
+/** @addtogroup BSP
+  * @{
+  */
+
+/** @addtogroup Components
+  * @{
+  */
+
+/** @addtogroup MT25TL01G
+  * @brief This file provides a set of functions needed to drive the
+  * MT25TL01G QSPI memory.
+  * @{
+  */
+/** @defgroup MT25TL01G_Exported_Functions MT25TL01G Exported Functions
+  * @{
+  */
+
+/**
+  * @brief  Return the configuration of the QSPI memory.
+  * @param  pInfo pointer on the configuration structure
+  * @retval QSPI memory status
+  */
+int32_t MT25TL01G_GetFlashInfo(MT25TL01G_Info_t *pInfo)
+{
+  pInfo->FlashSize  = MT25TL01G_FLASH_SIZE;
+  pInfo->EraseSectorSize= (2 * MT25TL01G_SUBSECTOR_SIZE);
+  pInfo->ProgPageSize   = MT25TL01G_PAGE_SIZE;
+  pInfo->EraseSectorsNumber = (MT25TL01G_FLASH_SIZE/pInfo->EraseSectorSize);
+  pInfo->ProgPagesNumber= (MT25TL01G_FLASH_SIZE/pInfo->ProgPageSize);
+  return MT25TL01G_OK;
+}
+
+/**
+  * @brief  This function set the QSPI memory in 4-byte address mode
+  *  SPI/QPI; 1-0-1/4-0-4
+  * @param  Ctx Component object pointer
+  * @param  Mode Interface mode
+  * @retval QSPI memory status
+  */
+int32_t MT25TL01G_Enter4BytesAddressMode(QSPI_HandleTypeDef *Ctx, 
MT25TL01G_Interface_t Mode)
+{
+  QSPI_CommandTypeDef s_command;
+
+  /* Initialize the command */
+  s_command.InstructionMode   = (Mode == MT25TL01G_QPI_MODE) ? 
QSPI_INSTRUCTION_4_LINES : QSPI_INSTRUCTION_1_LINE;
+  s_command.Instruction   = MT25TL01G_ENTER_4_BYTE_ADDR_MODE_CMD;
+  s_command.AddressMode   = QSPI_ADDRESS_NONE;
+  s_command.AlternateByteMode = QSPI_ALTERNATE_BYTES_NONE;
+  s_command.DataMode  = QSPI_DATA_NONE;
+  s_command.DummyCycles   = 0;
+  s_command.DdrMode   = QSPI_DDR_MODE_DISABLE;
+  s_command.DdrHoldHalfCycle  = QSPI_DDR_HHC_ANALOG_DELAY;
+  s_command.SIOOMode  = QSPI_SIOO_INST_EVERY_CMD;
+
+  /*write enable */
+  if( MT25TL01G_WriteEnable(Ctx,Mode)!=MT25TL01G_OK)
+  {
+return MT25TL01G_ERROR_COMMAND;
+  }
+  /* Send the command */
+  if (HAL_QSPI_Command(Ctx, _command, HAL_QPSI_TIMEOUT_DEFAULT_VALUE) != 
HAL_OK)
+  {
+return MT25TL01G_ERROR_COMMAND;
+  }
+
+  /* Configure automatic polling mode to wait the memory is ready */
+  else if(MT25TL01G_AutoPollingMemReady(Ctx,Mode)!=MT25TL01G_OK)
+  {
+return MT25TL01G_ERROR_COMMAND;
+  }
+
+  return MT25TL01G_OK;
+}
+
+/**
+  * @brief  Flash exit 4 Byte address mode. Effect 3/4 address byte commands 
only.
+  * SPI/QPI; 1-0-0/4-0-0
+  * @param  Ctx Component object pointer
+  * @param  Mode Interface mode
+  * @retval QSPI memory status
+  */
+int32_t MT25TL01G_Exit4BytesAddressMode(QSPI_HandleTypeDef *Ctx, 
MT25TL01G_Interface_t Mode)
+{
+  QSPI_CommandTypeDef s_command;
+
+  /* Initialize the command */
+  s_command.InstructionMode   = (Mode == MT25TL01G_QPI_MODE) ? 
QSPI_INSTRUCTION_4_LINES : QSPI_INSTRUCTION_1_LINE;
+  s_command.Instruction   = MT25TL01G_EXIT_4_BYTE_ADDR_MODE_CMD;
+  s_command.AddressMode   = QSPI_ADDRESS_NONE;
+  s_command.AlternateByteMode = QSPI_ALTERNATE_BYTES_NONE;
+  s_command.DataMode  = QSPI_DATA_NONE;
+  s_command.DummyCycles   = 0;
+  s_command.DdrMode   = QSPI_DDR_MODE_DISABLE;
+  s_command.DdrHoldHalfCycle  = QSPI_DDR_HHC_ANALOG_DELAY;
+  s_command.SIOOMode  =

[PATCH 2/5] bsps/stm32h7: import stm32h757i-eval QSPI memory high-level driver

2022-06-17 Thread Karel Gardas

Sponsored-By:   Precidata
---
 .../stm32h757i-eval/stm32h747i_eval_conf.h|  130 ++
 .../stm32h757i-eval/stm32h747i_eval_errno.h   |  105 ++
 .../stm32h757i-eval/stm32h747i_eval_qspi.c| 1088 +
 .../stm32h757i-eval/stm32h747i_eval_qspi.h|  284 +
 4 files changed, 1607 insertions(+)
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_conf.h
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_errno.h
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_qspi.c
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_qspi.h

diff --git a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_conf.h 
b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_conf.h
new file mode 100644
index 00..673125eec3
--- /dev/null
+++ b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_conf.h
@@ -0,0 +1,130 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
+/** 
+  
**
+  * @filestm32h747i_eval_config.h
+  * @author  MCD Application Team
+  * @brief   STM32H747I_EVAL board configuration file.
+  
**
+  * @attention
+  *
+  * Copyright (c) 2019 STMicroelectronics.
+  * All rights reserved.
+  *
+  * This software is licensed under terms that can be found in the LICENSE file
+  * in the root directory of this software component.
+  * If no LICENSE file comes with this software, it is provided AS-IS.
+  *
+  
**
+  */
+/*
+ * RTEMS committer clarification comment on license above:
+ *
+ * This file comes from STM32CubeH7 project and is located here:
+ * 
https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/BSP/STM32H747I-EVAL/stm32h747i_eval_conf_template.h
+ *
+ * The file root directory is:
+ * 
https://github.com/STMicroelectronics/STM32CubeH7/tree/master/Drivers/BSP/STM32H747I-EVAL
+ *
+ * This directory contains LICENSE.md file with a following license text:
+ *
+ * Copyright 2019 STMicroelectronics.
+ * 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. 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.
+ */
+  
+/* Define to prevent recursive inclusion 
-*/
+#ifndef STM32H747I_EVAL_CONFIG_H
+#define STM32H747I_EVAL_CONFIG_H
+
+#ifdef __cplusplus
+ extern "C" {
+#endif
+
+/* Includes 
--*/
+#include "stm32h7xx_hal.h"
+
+   /* COM define */
+#define USE_COM_LOG 0U
+   
+   /* IO class usage define */  
+#define USE_BSP_IO_CLASS1U
+   
+   /* JOY usage define */
+#define USE_BSP_JOY_FEATURE 1U
+   
+   /* POT usage define */   
+#define USE_BSP_POT_FEATURE 1U
+   
+   /* LCD controllers defines */
+#define USE_LCD_CTRL_OTM8009A   1U
+#define USE_LCD_CTRL_ADV75331U
+#define LCD_LAYER_0_ADDRESS 0xD000U
+#define LCD_LAYER_1_ADDRESS 0xD020U
+   
+   /* SD high performance usage define */
+#define USE_SD_HIGH_PERFORMANCE 0U
+   
+   /*DMA2D to fill RGB rectangle usage define*/
+#define USE_DMA2D_TO_FILL_RGB_RECT  0U
+   
+   /* Audio codecs defines */
+#define USE_AUDIO_CODEC_WM8994  1U
+#define USE_AUDIO_CODEC_ADV7533

[PATCH 3/5] bsps/stm32h7: allow config and usage of QSPI memory on stm32h757i-eval BSP

2022-06-17 Thread Karel Gardas

The QSPI memory is initialized and used only when the BSP configure file
sets QSPI memory size to non-zero value. Currently QSPI is run in memory
mapped mode which allows future RTEMS binary linkage and upload into QSPI
memory.

Sponsored-By:   Precidata
---
 .../stm/stm32h757i-eval/stm32h7-bspstarthooks.c | 17 +
 bsps/arm/stm32h7/include/bsp.h  |  1 +
 .../bsps/arm/stm32h7/bspstm32h757i-eval.yml |  5 -
 spec/build/bsps/arm/stm32h7/optmemquadspisz.yml |  1 +
 4 files changed, 23 insertions(+), 1 deletion(-)

diff --git 
a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c 
b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
index 8d34e357ee..1bb81e3b60 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
@@ -36,6 +36,22 @@
 
 #include 
 
+#include 
+static BSP_QSPI_Init_t QSPinit;
+
+void stm32h7_init_qspi(void)
+{
+#if defined(STM32H7_MEMORY_QUADSPI_SIZE) && STM32H7_MEMORY_QUADSPI_SIZE > 0
+/* let's initialize Quad SPI memory here for memory mapped mode */
+/* due to usage of static QSPinit variable please call this function
+   after bsp_start_clear_bss call since otherwise you would hit 
uninitialized
+   variable memory while accessing it and in addition the call to 
bsp_start_clear_bss
+   would wipe the variable content later after its initialization here. */
+BSP_QSPI_Init(0, );
+BSP_QSPI_EnableMemoryMappedMode(0);
+#endif
+}
+
 void bsp_start_hook_0(void)
 {
   if ((RCC->AHB3ENR & RCC_AHB3ENR_FMCEN) == 0) {
@@ -75,4 +91,5 @@ void bsp_start_hook_1(void)
   SCB_InvalidateICache();
 #endif
   bsp_start_clear_bss();
+  stm32h7_init_qspi();
 }
diff --git a/bsps/arm/stm32h7/include/bsp.h b/bsps/arm/stm32h7/include/bsp.h
index 08311bf51e..cd4d25c069 100644
--- a/bsps/arm/stm32h7/include/bsp.h
+++ b/bsps/arm/stm32h7/include/bsp.h
@@ -62,6 +62,7 @@ void stm32h7_init_power(void);
 void stm32h7_init_oscillator(void);
 void stm32h7_init_clocks(void);
 void stm32h7_init_peripheral_clocks(void);
+void stm32h7_init_qspi(void);
 
 /** @} */
 
diff --git a/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval.yml 
b/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval.yml
index 5d7ee1348d..7516e55a3f 100644
--- a/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval.yml
+++ b/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval.yml
@@ -8,7 +8,8 @@ copyrights:
 cppflags: []
 enabled-by: true
 family: stm32h7
-includes: []
+includes:
+- bsps/arm/stm32h7/boards/stm/stm32h757i-eval
 install: []
 links:
 - role: build-dependency
@@ -16,6 +17,8 @@ links:
 - role: build-dependency
   uid: tststm32h757i-eval
 source:
+- bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c
+- bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_qspi.c
 - bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
 - bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-config-clk.c
 - bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-config-osc.c
diff --git a/spec/build/bsps/arm/stm32h7/optmemquadspisz.yml 
b/spec/build/bsps/arm/stm32h7/optmemquadspisz.yml
index 11e5f943e0..9337610b45 100644
--- a/spec/build/bsps/arm/stm32h7/optmemquadspisz.yml
+++ b/spec/build/bsps/arm/stm32h7/optmemquadspisz.yml
@@ -1,6 +1,7 @@
 actions:
 - get-integer: null
 - env-assign: null
+- define-unquoted: null
 build-type: option
 default: 0
 default-by-variant: []
-- 
2.25.1

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

Re: Request for feedback for CAN message structure

2022-06-20 Thread Karel Gardas



IIRC Pavel asked to always being on cc to get CAN related email right to 
his inbox instead of email list boxes...


On 6/20/22 18:37, Prashanth S wrote:

Hi All,

This is a request for suggestions and feedback for the CAN message 
structure.


*CAN message structure that represents the can messages from application 
to driver:*


struct can_message {
uint32_t timestamp;
uint32_t id; // 32 bits to support extended id (29 bits)
uint16_t flags;    // RTR | BRS | EXT ...
uint8_t dlc; // (0 - 8) | 12 | 16 | 20 | 24 | 32 | 48 | 64
uint8_t res; // reserved for alignment.
uint8_t data[64]; // For supporting data transfer up to 64 bytes.
};

This is the CAN messages structure created based on the suggestions in 
the mail chain and looking through other CAN solutions (Nuttx, GRCAN, 
LinCAN).


Regards
Prashanth S


___
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: Problem with STM32 HAL license

2022-06-13 Thread Karel Gardas

On 6/13/22 18:27, Joel Sherrill wrote:
This impacts other imports from STM so I am curious what Karel,
Sebastian, and Andrei are seeing for the license in the code they are
importing and what they plan to do.

So far on H7, the HAL used is older code base which is clearly BSD-3
license:

https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/hal/stm32h7xx_hal.c#n22

however to support new boards or peripherals I've imported few files
which use the same unclear license message. I've clarified it in any
imported file like:

https://git.rtems.org/rtems/tree/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c#n35

the problem is obviously scalability of this solution and future merges.
You can do that one one/two board files, but probably not on whole HAL
with ~100 files.
I also remember that Sebastian recommended to completely replace this
license note with the specified license (to which note points). But I've
not done that due to reluctancy of touching STM license notes here and
hence came with committer clarification message below every such note.

Hence I asked Duc on discord to ask here for advice. BTW, new HAL for H7
will be probably in the same situation like Duc seing with current F4.

https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/STM32H7xx_HAL_Driver/Src/stm32h7xx_hal.c

So we definitely need to find a solution to this issue.

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

[PATCH 1/3] bsps/stm32h7: add board C files for nucleo-h7a3zi BSP

2022-07-24 Thread Karel Gardas

Besides C files for the BSP variant the patch also provides license
clarification on system_stm32h7xx.c file which is provided
in boards/stm/nucleo-h7a3zi directory.
The files comes from STM32CubeH7 project and references "root directory"
in its license comment and it's not clear where this points out.
Let's add clarification comment about it and also based on it
and resulting license let's add SPDX license identifier.
---
 .../stm/nucleo-h7a3zi/stm32h7-bspstarthooks.c |  77 
 .../stm/nucleo-h7a3zi/stm32h7-config-clk.c|  45 ++
 .../stm/nucleo-h7a3zi/stm32h7-config-osc.c|  49 +++
 .../stm/nucleo-h7a3zi/stm32h7-config-per.c|  49 +++
 .../stm/nucleo-h7a3zi/system_stm32h7xx.c  | 391 ++
 5 files changed, 611 insertions(+)
 create mode 100644 
bsps/arm/stm32h7/boards/stm/nucleo-h7a3zi/stm32h7-bspstarthooks.c
 create mode 100644 
bsps/arm/stm32h7/boards/stm/nucleo-h7a3zi/stm32h7-config-clk.c
 create mode 100644 
bsps/arm/stm32h7/boards/stm/nucleo-h7a3zi/stm32h7-config-osc.c
 create mode 100644 
bsps/arm/stm32h7/boards/stm/nucleo-h7a3zi/stm32h7-config-per.c
 create mode 100644 bsps/arm/stm32h7/boards/stm/nucleo-h7a3zi/system_stm32h7xx.c

diff --git a/bsps/arm/stm32h7/boards/stm/nucleo-h7a3zi/stm32h7-bspstarthooks.c 
b/bsps/arm/stm32h7/boards/stm/nucleo-h7a3zi/stm32h7-bspstarthooks.c
new file mode 100644
index 00..eda503925f
--- /dev/null
+++ b/bsps/arm/stm32h7/boards/stm/nucleo-h7a3zi/stm32h7-bspstarthooks.c
@@ -0,0 +1,77 @@
+/* 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+void bsp_start_hook_0(void)
+{
+  if ((RCC->AHB3ENR & RCC_AHB3ENR_FMCEN) == 0) {
+/*
+ * Only perform the low-level initialization if necessary.  An initialized
+ * FMC indicates that a boot loader already performed the low-level
+ * initialization.
+ */
+SystemInit();
+stm32h7_init_power();
+stm32h7_init_oscillator();
+stm32h7_init_clocks();
+stm32h7_init_peripheral_clocks();
+HAL_RCC_MCOConfig(RCC_MCO1, RCC_MCO1SOURCE_HSI, RCC_MCODIV_1);
+HAL_Init();
+  }
+
+#if __CORTEX_M == 0x07U
+  if ((SCB->CCR & SCB_CCR_IC_Msk) == 0) {
+SCB_EnableICache();
+  }
+
+  if ((SCB->CCR & SCB_CCR_DC_Msk) == 0) {
+SCB_EnableDCache();
+  }
+
+  _ARMV7M_MPU_Setup(stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
+#endif
+}
+
+void bsp_start_hook_1(void)
+{
+  bsp_start_copy_sections_compact();
+#if __CORTEX_M == 0x07U
+  SCB_CleanDCache();
+  SCB_InvalidateICache();
+#endif
+  bsp_start_clear_bss();
+}
diff --git a/bsps/arm/stm32h7/boards/stm/nucleo-h7a3zi/stm32h7-config-clk.c 
b/bsps/arm/stm32h7/boards/stm/nucleo-h7a3zi/stm32h7-config-clk.c
new file mode 100644
index 00..c7e62179ce
--- /dev/null
+++ b/bsps/arm/stm32h7/boards/stm/nucleo-h7a3zi/stm32h7-config-clk.c
@@ -0,0 +1,45 @@
+/* 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

[PATCH 3/3] bsps/stm32h7: disable Ethernet completely on nucleo-h7a3zi BSP

2022-07-24 Thread Karel Gardas

The board and hosted MCU do not provide any Ethernet support anyway.
---
 bsps/arm/stm32h7/start/stm32h7-hal-eth.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/arm/stm32h7/start/stm32h7-hal-eth.c 
b/bsps/arm/stm32h7/start/stm32h7-hal-eth.c
index 5fc75f0147..173d97c31f 100644
--- a/bsps/arm/stm32h7/start/stm32h7-hal-eth.c
+++ b/bsps/arm/stm32h7/start/stm32h7-hal-eth.c
@@ -33,7 +33,7 @@
 
 #include 
 
-#ifndef STM32H7B3xxQ
+#if !defined(STM32H7B3xxQ) && !defined(STM32H7A3xxQ)
 
 static const stm32h7_gpio_config gpiog = {
   .regs = GPIOG,
-- 
2.25.1

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

[PATCH 2/3] bsps/stm32h7: add configuration and enable build of nucleo-h7a3zi BSP

2022-07-24 Thread Karel Gardas

---
 .../bsps/arm/stm32h7/bspnucleoh7a3zi.yml  | 25 +++
 spec/build/bsps/arm/stm32h7/opthse.yml|  1 +
 spec/build/bsps/arm/stm32h7/optlinkcmds.yml   |  1 +
 .../bsps/arm/stm32h7/optmemflashlatency.yml   |  1 +
 .../build/bsps/arm/stm32h7/optmemsdram1sz.yml |  1 +
 .../bsps/arm/stm32h7/optmemsramaxisz.yml  |  1 +
 .../bsps/arm/stm32h7/optprintkinstance.yml|  1 +
 spec/build/bsps/arm/stm32h7/optpwrsupply.yml  |  1 +
 spec/build/bsps/arm/stm32h7/optvariant.yml|  3 +++
 9 files changed, 35 insertions(+)
 create mode 100644 spec/build/bsps/arm/stm32h7/bspnucleoh7a3zi.yml

diff --git a/spec/build/bsps/arm/stm32h7/bspnucleoh7a3zi.yml 
b/spec/build/bsps/arm/stm32h7/bspnucleoh7a3zi.yml
new file mode 100644
index 00..d3e47a528a
--- /dev/null
+++ b/spec/build/bsps/arm/stm32h7/bspnucleoh7a3zi.yml
@@ -0,0 +1,25 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+arch: arm
+bsp: nucleo-h7a3zi
+build-type: bsp
+cflags: []
+copyrights:
+- Copyright (C) 2021 embedded brains GmbH (http://www.embedded-brains.de)
+cppflags: []
+enabled-by: true
+family: stm32h7
+includes: []
+install: []
+links:
+- role: build-dependency
+  uid: grp
+- role: build-dependency
+  uid: tststm32h757i-eval
+source:
+- bsps/arm/stm32h7/boards/stm/nucleo-h7a3zi/stm32h7-bspstarthooks.c
+- bsps/arm/stm32h7/boards/stm/nucleo-h7a3zi/stm32h7-config-clk.c
+- bsps/arm/stm32h7/boards/stm/nucleo-h7a3zi/stm32h7-config-osc.c
+- bsps/arm/stm32h7/boards/stm/nucleo-h7a3zi/stm32h7-config-per.c
+- bsps/arm/stm32h7/boards/stm/nucleo-h7a3zi/system_stm32h7xx.c
+- bsps/arm/shared/cache/cache-v7m.c
+type: build
diff --git a/spec/build/bsps/arm/stm32h7/opthse.yml 
b/spec/build/bsps/arm/stm32h7/opthse.yml
index e5feef1114..9fcdc4d4fb 100644
--- a/spec/build/bsps/arm/stm32h7/opthse.yml
+++ b/spec/build/bsps/arm/stm32h7/opthse.yml
@@ -9,6 +9,7 @@ default-by-variant:
 - value: 800
   variants:
   - arm/nucleo-h743zi
+  - arm/nucleo-h7a3zi
 - value: 2400
   variants:
   - arm/stm32h7b3i-dk
diff --git a/spec/build/bsps/arm/stm32h7/optlinkcmds.yml 
b/spec/build/bsps/arm/stm32h7/optlinkcmds.yml
index 3103deef84..f28dfd78d3 100644
--- a/spec/build/bsps/arm/stm32h7/optlinkcmds.yml
+++ b/spec/build/bsps/arm/stm32h7/optlinkcmds.yml
@@ -12,6 +12,7 @@ default-by-variant:
   - arm/stm32h747i-disco
   - arm/stm32h747i-disco-m4
   - arm/nucleo-h743zi
+  - arm/nucleo-h7a3zi
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optmemflashlatency.yml 
b/spec/build/bsps/arm/stm32h7/optmemflashlatency.yml
index cf5422acb6..27d9b541d9 100644
--- a/spec/build/bsps/arm/stm32h7/optmemflashlatency.yml
+++ b/spec/build/bsps/arm/stm32h7/optmemflashlatency.yml
@@ -7,6 +7,7 @@ default-by-variant:
 - value: FLASH_LATENCY_6
   variants:
   - arm/stm32h7b3i-dk
+  - arm/nucleo-h7a3zi
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml 
b/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml
index 9a29e9f04f..395d3fb904 100644
--- a/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml
+++ b/spec/build/bsps/arm/stm32h7/optmemsdram1sz.yml
@@ -12,6 +12,7 @@ default-by-variant:
   - arm/stm32h747i-disco
   - arm/stm32h747i-disco-m4
   - arm/nucleo-h743zi
+  - arm/nucleo-h7a3zi
 enabled-by: true
 format: '{:#010x}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optmemsramaxisz.yml 
b/spec/build/bsps/arm/stm32h7/optmemsramaxisz.yml
index 89e116c1de..90fe7811a0 100644
--- a/spec/build/bsps/arm/stm32h7/optmemsramaxisz.yml
+++ b/spec/build/bsps/arm/stm32h7/optmemsramaxisz.yml
@@ -7,6 +7,7 @@ default-by-variant:
 - value: 0xA
   variants:
   - arm/stm32h7b3i-dk
+  - arm/nucleo-h7a3zi
 enabled-by: true
 format: '{:#010x}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optprintkinstance.yml 
b/spec/build/bsps/arm/stm32h7/optprintkinstance.yml
index 5e87aaab1f..10b6786a1f 100644
--- a/spec/build/bsps/arm/stm32h7/optprintkinstance.yml
+++ b/spec/build/bsps/arm/stm32h7/optprintkinstance.yml
@@ -7,6 +7,7 @@ default-by-variant:
 - value: stm32h7_usart3_instance
   variants:
   - arm/nucleo-h743zi
+  - arm/nucleo-h7a3zi
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optpwrsupply.yml 
b/spec/build/bsps/arm/stm32h7/optpwrsupply.yml
index effdbbffe0..9b5461fac7 100644
--- a/spec/build/bsps/arm/stm32h7/optpwrsupply.yml
+++ b/spec/build/bsps/arm/stm32h7/optpwrsupply.yml
@@ -11,6 +11,7 @@ default-by-variant:
   - arm/stm32h757i-eval-m4
   - arm/stm32h747i-disco
   - arm/stm32h747i-disco-m4
+  - arm/nucleo-h7a3zi
 enabled-by: true
 format: '{}'
 links: []
diff --git a/spec/build/bsps/arm/stm32h7/optvariant.yml 
b/spec/build/bsps/arm/stm32h7/optvariant.yml
index 720a40c63d..e2790a0f25 100644
--- a/spec/build/bsps/arm/stm32h7/optvariant.yml
+++ b/spec/build/bsps/arm/stm32h7/optvariant.yml
@@ -25,6 +25,9 @@ default-by-variant:
   variants:
   - arm/stm32h747i-disco
   - arm/stm32h747i-disco-m4
+- value: STM32H7A3xxQ
+  variants:
+- arm/nucleo-h7a3zi

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

2022-07-23 Thread Karel Gardas




Duc,

where have you taken F4 HAL exactly? I'm asking since your import is 
full of CRLF line endings which we try hard to eliminate in RTEMS while 
original is not. Proof:


$ git clone https://github.com/STMicroelectronics/STM32CubeF4.git
Cloning into 'STM32CubeF4'...
remote: Enumerating objects: 75365, done.
remote: Counting objects: 100% (1271/1271), done.
remote: Compressing objects: 100% (48/48), done.
remote: Total 75365 (delta 1231), reused 1229 (delta 1221), pack-reused 
74094

Receiving objects: 100% (75365/75365), 157.59 MiB | 6.87 MiB/s, done.
Resolving deltas: 100% (46903/46903), done.
Updating files: 100% (39125/39125), done.
rtems@silence:~/vcs$ cd STM32CubeF4/
rtems@silence:~/vcs/STM32CubeF4$
rtems@silence:~/vcs/STM32CubeF4$
rtems@silence:~/vcs/STM32CubeF4$ git ls-files --eol|grep crlf
rtems@silence:~/vcs/STM32CubeF4$


Please use the command above to review your CRLF files.

Thanks,
Karel

On 7/23/22 05:53, Duc Doan wrote:

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

Re: GCC version for RTEMS 6?

2022-04-29 Thread Karel Gardas


On 4/28/22 10:04, Sebastian Huber wrote:
More releases means more maintenance overhead. Since GCC 12 is under 
active upstream maintenance, compiler issues can be fixed by the GCC 
maintainers in contrast to GCC 10.


JFYI: gcc 12 was branched, rc1 is being built. More info here:
https://gcc.gnu.org/pipermail/gcc/2022-April/238617.html

Karel


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

Re: GCC version for RTEMS 6?

2022-04-28 Thread Karel Gardas




Hello,

I'd go with 12 if only a bit possible. Any major compiler change during 
the minor RTEMS release would not look good IMHO. It's way better to do 
major RTEMS version bump together with major compiler version bump and 
stick to that during the RTEMS release live cycle. That's my gut feeling 
about that.


Now, hard evidence. Do we have any table comparing test case results on 
all the (tier 1? /2?) platforms between GCC 10 and 12? That would be 
great to have that to see if there is any major regression in 12 and to 
possibly drive the decision based on hard facts.


Thanks!
Karel

On 4/27/22 08:57, Sebastian Huber wrote:

Hello,

we have to select a GCC version for the RTEMS 6 release. Currently, GCC 
10 is used, however, with the release of GCC 10.4 this year it will 
reach its end of life. Other options are GCC 11 and 12. GCC 12 will be 
released in the next weeks. It has some nice features:


* Initialization of stack variables:

https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-ftrivial-auto-var-init 



* Improved static analysis with -fanalyzer

* Improved gcov support, with the ability to back port changes from GCC 13:

https://gcc.gnu.org/pipermail/gcc-patches/2022-April/593536.html

* Upstream maintenance for the next three years

The draw back is that it is brand new.



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

Re: Update to GCC 12 for development branch (RTEMS 6)

2022-05-09 Thread Karel Gardas




Hello Sebastian,

thanks a lot for dealing with GCC 12 update. I'm just curious is there 
any reason to use GCC from git (post release version) and not vanilla 
12.1 release tarball from gcc.gnu.org?


Thanks!
Karel

On 5/9/22 14:54, Sebastian Huber wrote:

Hello,

I updated the RSB to use the latest GCC 12 release branch version. GCC 
12.1 was released on May 6th:


https://gcc.gnu.org/gcc-12/changes.html

One interesting GCC 12 feature for embedded systems is the default 
initialization of stack variables:


https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init 



I added a back port for improved gcov support for which I missed the GCC 
12 development stage:


https://gcc.gnu.org/onlinedocs/gcc/Freestanding-Environments.html#Freestanding-Environments 





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

Re: GCC version for RTEMS 6?

2022-05-05 Thread Karel Gardas


On 5/5/22 11:35, Chris Johns wrote:

I think this is a use case where something added to the RSB may be required to
make this easier. For example logic in a bset file would be nice.


Your idea is excellent, but I think we also may need something more simple and
history preserving for the time releases are already done.

Hence I sent a patch series creating config/6.1 as a preparation for 6.1 release
with gcc 10 and update 6 (as a 6 branch dev) with Sebastian's updated GCC 12).

Just meant as material for discussion.


I understand and thank you for contributing.

A release is the tarfiles and that is fixed.


Just checked https://ftp.rtems.org/pub/rtems/releases/5/5.1/ and you are 
right! I stand corrected, in this case indeed my patch series is useless.


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

Re: GCC version for RTEMS 6?

2022-05-05 Thread Karel Gardas


On 5/5/22 11:15, Karel Gardas wrote:
Hence I sent a patch series creating config/6.1 as a preparation for 6.1 
release with gcc 10 and update 6 (as a 6 branch dev) with Sebastian's 
updated GCC 12).


Oh, and I do not mean 6.1 should be done with GCC 10. Just we do have 
two sets now for testing and comparison.


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

[no subject]

2022-05-05 Thread Karel Gardas



This patch series creates 6.1 config directory and updates its files
to not use any from 6. It also updates 6's GCC to GCC 12 (gcc-head)
to easy testing and comparing for gcc 10 and 12 in preparation
of RTEMS 6.1 release.
General idea is that we will create config/
for any RTEMS release and that way keep tools and kernel releases
in sync forever. E.g. '6' and '7' are for branch/master developments
but '6.1', '6.2', '7.1' etc. are kept intact after the release.


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

[PATCH 1/3] 6.1: make as verbatim copy of files in 6

2022-05-05 Thread Karel Gardas

---
 rtems/config/6.1/rtems-aarch64.bset|  4 
 rtems/config/6.1/rtems-all.bset| 18 ++
 rtems/config/6.1/rtems-arm.bset|  4 
 rtems/config/6.1/rtems-base.bset   | 13 +
 rtems/config/6.1/rtems-bfin.bset   |  3 +++
 rtems/config/6.1/rtems-default.bset| 19 +++
 rtems/config/6.1/rtems-i386.bset   |  4 
 rtems/config/6.1/rtems-kernel.bset | 15 +++
 rtems/config/6.1/rtems-libbsd.bset |  8 
 rtems/config/6.1/rtems-llvm.bset   | 21 +
 rtems/config/6.1/rtems-lm32.bset   |  3 +++
 rtems/config/6.1/rtems-m68k.bset   |  3 +++
 rtems/config/6.1/rtems-microblaze.bset | 20 
 rtems/config/6.1/rtems-mips.bset   |  6 ++
 rtems/config/6.1/rtems-moxie.bset  |  5 +
 rtems/config/6.1/rtems-net-legacy.bset |  4 
 rtems/config/6.1/rtems-nios2.bset  |  3 +++
 rtems/config/6.1/rtems-or1k.bset   |  3 +++
 rtems/config/6.1/rtems-packages.bset   | 24 
 rtems/config/6.1/rtems-powerpc.bset|  4 
 rtems/config/6.1/rtems-riscv.bset  |  5 +
 rtems/config/6.1/rtems-sh.bset |  3 +++
 rtems/config/6.1/rtems-sparc.bset  |  6 ++
 rtems/config/6.1/rtems-sparc64.bset|  3 +++
 rtems/config/6.1/rtems-tools.bset  | 17 +
 rtems/config/6.1/rtems-v850.bset   |  3 +++
 rtems/config/6.1/rtems-x86_64.bset |  9 +
 27 files changed, 230 insertions(+)
 create mode 100644 rtems/config/6.1/rtems-aarch64.bset
 create mode 100644 rtems/config/6.1/rtems-all.bset
 create mode 100644 rtems/config/6.1/rtems-arm.bset
 create mode 100644 rtems/config/6.1/rtems-base.bset
 create mode 100644 rtems/config/6.1/rtems-bfin.bset
 create mode 100644 rtems/config/6.1/rtems-default.bset
 create mode 100644 rtems/config/6.1/rtems-i386.bset
 create mode 100644 rtems/config/6.1/rtems-kernel.bset
 create mode 100644 rtems/config/6.1/rtems-libbsd.bset
 create mode 100644 rtems/config/6.1/rtems-llvm.bset
 create mode 100644 rtems/config/6.1/rtems-lm32.bset
 create mode 100644 rtems/config/6.1/rtems-m68k.bset
 create mode 100644 rtems/config/6.1/rtems-microblaze.bset
 create mode 100644 rtems/config/6.1/rtems-mips.bset
 create mode 100644 rtems/config/6.1/rtems-moxie.bset
 create mode 100644 rtems/config/6.1/rtems-net-legacy.bset
 create mode 100644 rtems/config/6.1/rtems-nios2.bset
 create mode 100644 rtems/config/6.1/rtems-or1k.bset
 create mode 100644 rtems/config/6.1/rtems-packages.bset
 create mode 100644 rtems/config/6.1/rtems-powerpc.bset
 create mode 100644 rtems/config/6.1/rtems-riscv.bset
 create mode 100644 rtems/config/6.1/rtems-sh.bset
 create mode 100644 rtems/config/6.1/rtems-sparc.bset
 create mode 100644 rtems/config/6.1/rtems-sparc64.bset
 create mode 100644 rtems/config/6.1/rtems-tools.bset
 create mode 100644 rtems/config/6.1/rtems-v850.bset
 create mode 100644 rtems/config/6.1/rtems-x86_64.bset

diff --git a/rtems/config/6.1/rtems-aarch64.bset 
b/rtems/config/6.1/rtems-aarch64.bset
new file mode 100644
index 000..e3c91af
--- /dev/null
+++ b/rtems/config/6.1/rtems-aarch64.bset
@@ -0,0 +1,4 @@
+%define release 1
+%define rtems_arch aarch64
+%define with_libgomp
+%include 6/rtems-default.bset
diff --git a/rtems/config/6.1/rtems-all.bset b/rtems/config/6.1/rtems-all.bset
new file mode 100644
index 000..2503f2a
--- /dev/null
+++ b/rtems/config/6.1/rtems-all.bset
@@ -0,0 +1,18 @@
+6/rtems-aarch64
+6/rtems-arm
+6/rtems-bfin
+6/rtems-i386
+6/rtems-lm32
+6/rtems-m68k
+6/rtems-microblaze
+6/rtems-mips
+6/rtems-moxie
+6/rtems-nios2
+6/rtems-or1k
+6/rtems-powerpc
+6/rtems-riscv
+6/rtems-sh
+6/rtems-sparc
+6/rtems-sparc64
+6/rtems-v850
+6/rtems-x86_64
diff --git a/rtems/config/6.1/rtems-arm.bset b/rtems/config/6.1/rtems-arm.bset
new file mode 100644
index 000..425d66b
--- /dev/null
+++ b/rtems/config/6.1/rtems-arm.bset
@@ -0,0 +1,4 @@
+%define release 1
+%define rtems_arch arm
+%define with_libgomp
+%include 6/rtems-default.bset
diff --git a/rtems/config/6.1/rtems-base.bset b/rtems/config/6.1/rtems-base.bset
new file mode 100644
index 000..ba394ef
--- /dev/null
+++ b/rtems/config/6.1/rtems-base.bset
@@ -0,0 +1,13 @@
+%define rtems_version 6
+%define _target %{rtems_arch}-rtems%{rtems_version}
+%define gcc_version_message RTEMS %{rtems_version}, RSB %{_sbgit_id}, Newlib 
%{newlib_version}
+
+%include rtems-urls.bset
+
+%ifos win32 mingw ming32
+ %define rtems_waf_build_root_suffix %{waf_build_root_suffix}
+%else
+ %define rtems_waf_build_root_suffix %{nil}
+%endif
+
+package: rtems-%{rtems_version}-%{_target}-%{_host}-%{release}
diff --git a/rtems/config/6.1/rtems-bfin.bset b/rtems/config/6.1/rtems-bfin.bset
new file mode 100644
index 000..12a215e
--- /dev/null
+++ b/rtems/config/6.1/rtems-bfin.bset
@@ -0,0 +1,3 @@
+%define release 1
+%define rtems_arch bfin
+%include 6/rtems-default.bset
diff --git a/rtems/config/6.1/rtems-default.bset

[PATCH 3/3] 6: switch to use GCC 12 (gcc-head)

2022-05-05 Thread Karel Gardas

---
 rtems/config/6/rtems-default.bset | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/rtems/config/6/rtems-default.bset 
b/rtems/config/6/rtems-default.bset
index 731c9d8..381f916 100644
--- a/rtems/config/6/rtems-default.bset
+++ b/rtems/config/6/rtems-default.bset
@@ -15,5 +15,5 @@ devel/gmp-6.2.1
 tools/rtems-gdb-11.2
 
 tools/rtems-binutils-2.38
-tools/rtems-gcc-10-newlib-head
+tools/rtems-gcc-head-newlib-head
 tools/rtems-tools-6
-- 
2.25.1

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

[PATCH 2/3] 6.1: update 6 references to 6.1

2022-05-05 Thread Karel Gardas

---
 rtems/config/6.1/rtems-aarch64.bset| 2 +-
 rtems/config/6.1/rtems-arm.bset| 2 +-
 rtems/config/6.1/rtems-bfin.bset   | 2 +-
 rtems/config/6.1/rtems-default.bset| 2 +-
 rtems/config/6.1/rtems-i386.bset   | 2 +-
 rtems/config/6.1/rtems-lm32.bset   | 2 +-
 rtems/config/6.1/rtems-m68k.bset   | 2 +-
 rtems/config/6.1/rtems-microblaze.bset | 2 +-
 rtems/config/6.1/rtems-mips.bset   | 2 +-
 rtems/config/6.1/rtems-moxie.bset  | 2 +-
 rtems/config/6.1/rtems-nios2.bset  | 2 +-
 rtems/config/6.1/rtems-or1k.bset   | 2 +-
 rtems/config/6.1/rtems-powerpc.bset| 2 +-
 rtems/config/6.1/rtems-riscv.bset  | 2 +-
 rtems/config/6.1/rtems-sh.bset | 2 +-
 rtems/config/6.1/rtems-sparc.bset  | 2 +-
 rtems/config/6.1/rtems-sparc64.bset| 2 +-
 rtems/config/6.1/rtems-v850.bset   | 2 +-
 rtems/config/6.1/rtems-x86_64.bset | 2 +-
 19 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/rtems/config/6.1/rtems-aarch64.bset 
b/rtems/config/6.1/rtems-aarch64.bset
index e3c91af..bb66d70 100644
--- a/rtems/config/6.1/rtems-aarch64.bset
+++ b/rtems/config/6.1/rtems-aarch64.bset
@@ -1,4 +1,4 @@
 %define release 1
 %define rtems_arch aarch64
 %define with_libgomp
-%include 6/rtems-default.bset
+%include 6.1/rtems-default.bset
diff --git a/rtems/config/6.1/rtems-arm.bset b/rtems/config/6.1/rtems-arm.bset
index 425d66b..030f713 100644
--- a/rtems/config/6.1/rtems-arm.bset
+++ b/rtems/config/6.1/rtems-arm.bset
@@ -1,4 +1,4 @@
 %define release 1
 %define rtems_arch arm
 %define with_libgomp
-%include 6/rtems-default.bset
+%include 6.1/rtems-default.bset
diff --git a/rtems/config/6.1/rtems-bfin.bset b/rtems/config/6.1/rtems-bfin.bset
index 12a215e..a308a69 100644
--- a/rtems/config/6.1/rtems-bfin.bset
+++ b/rtems/config/6.1/rtems-bfin.bset
@@ -1,3 +1,3 @@
 %define release 1
 %define rtems_arch bfin
-%include 6/rtems-default.bset
+%include 6.1/rtems-default.bset
diff --git a/rtems/config/6.1/rtems-default.bset 
b/rtems/config/6.1/rtems-default.bset
index 731c9d8..1d03dc4 100644
--- a/rtems/config/6.1/rtems-default.bset
+++ b/rtems/config/6.1/rtems-default.bset
@@ -1,7 +1,7 @@
 #
 # Default tools configuration.
 #
-%include 6/rtems-base.bset
+%include 6.1/rtems-base.bset
 
 #
 # Build gdb first to raise the Python install error as early as possible.
diff --git a/rtems/config/6.1/rtems-i386.bset b/rtems/config/6.1/rtems-i386.bset
index a27319d..d236627 100644
--- a/rtems/config/6.1/rtems-i386.bset
+++ b/rtems/config/6.1/rtems-i386.bset
@@ -1,4 +1,4 @@
 %define release 1
 %define rtems_arch i386
 %define with_libgomp
-%include 6/rtems-default.bset
+%include 6.1/rtems-default.bset
diff --git a/rtems/config/6.1/rtems-lm32.bset b/rtems/config/6.1/rtems-lm32.bset
index b5afad1..476bc10 100644
--- a/rtems/config/6.1/rtems-lm32.bset
+++ b/rtems/config/6.1/rtems-lm32.bset
@@ -1,3 +1,3 @@
 %define release 1
 %define rtems_arch lm32
-%include 6/rtems-default.bset
+%include 6.1/rtems-default.bset
diff --git a/rtems/config/6.1/rtems-m68k.bset b/rtems/config/6.1/rtems-m68k.bset
index 0932d20..c10e9e3 100644
--- a/rtems/config/6.1/rtems-m68k.bset
+++ b/rtems/config/6.1/rtems-m68k.bset
@@ -1,3 +1,3 @@
 %define release 1
 %define rtems_arch m68k
-%include 6/rtems-default.bset
+%include 6.1/rtems-default.bset
diff --git a/rtems/config/6.1/rtems-microblaze.bset 
b/rtems/config/6.1/rtems-microblaze.bset
index ea59313..ee5689b 100644
--- a/rtems/config/6.1/rtems-microblaze.bset
+++ b/rtems/config/6.1/rtems-microblaze.bset
@@ -4,7 +4,7 @@
 #
 # Default tools configuration.
 #
-%include 6/rtems-base.bset
+%include 6.1/rtems-base.bset
 
 #
 # Build gdb first to raise the Python install error as early as possible.
diff --git a/rtems/config/6.1/rtems-mips.bset b/rtems/config/6.1/rtems-mips.bset
index 48771f3..1443a07 100644
--- a/rtems/config/6.1/rtems-mips.bset
+++ b/rtems/config/6.1/rtems-mips.bset
@@ -2,5 +2,5 @@
 %define rtems_arch mips
 %define gdb-sim-options --enable-sim-hardware
 %define win32-gdb-disable-sim
-%include 6/rtems-default.bset
+%include 6.1/rtems-default.bset
 tools/rtems-mipstx39-gdb-11.2
diff --git a/rtems/config/6.1/rtems-moxie.bset 
b/rtems/config/6.1/rtems-moxie.bset
index c86777e..f8a8a71 100644
--- a/rtems/config/6.1/rtems-moxie.bset
+++ b/rtems/config/6.1/rtems-moxie.bset
@@ -2,4 +2,4 @@
 %define rtems_arch moxie
 %define win32-gdb-disable-sim
 %define with_libgomp
-%include 6/rtems-default.bset
+%include 6.1/rtems-default.bset
diff --git a/rtems/config/6.1/rtems-nios2.bset 
b/rtems/config/6.1/rtems-nios2.bset
index 522eff5..86640de 100644
--- a/rtems/config/6.1/rtems-nios2.bset
+++ b/rtems/config/6.1/rtems-nios2.bset
@@ -1,3 +1,3 @@
 %define release 1
 %define rtems_arch nios2
-%include 6/rtems-default.bset
+%include 6.1/rtems-default.bset
diff --git a/rtems/config/6.1/rtems-or1k.bset b/rtems/config/6.1/rtems-or1k.bset
index c299c25..75fbb7b 100644
--- a/rtems/config/6.1/rtems-or1k.bset
+++ b/rtems/config/6.1/rtems-or1k.bset
@@ -1,3 +1,3 @@
 %define

Re: GCC version for RTEMS 6?

2022-05-05 Thread Karel Gardas


On 5/5/22 01:32, Chris Johns wrote:

On 4/5/2022 8:57 pm, Sebastian Huber wrote:

On 04/05/2022 09:11, Chris Johns wrote:

I updated the RTEMS 7 tools to use the GCC 12 release branch with a gcov back
port. You can test GCC 12 with a local patch for RTEMS 6:

diff --git a/rtems/config/6/rtems-default.bset
b/rtems/config/6/rtems-default.bset
index 731c9d8..381f916 100644
--- a/rtems/config/6/rtems-default.bset
+++ b/rtems/config/6/rtems-default.bset
@@ -15,5 +15,5 @@ devel/gmp-6.2.1
   tools/rtems-gdb-11.2

   tools/rtems-binutils-2.38
-tools/rtems-gcc-10-newlib-head
+tools/rtems-gcc-head-newlib-head
   tools/rtems-tools-6

Ah ok and thanks. I will take a look and report back. It will take a couple of
days for me to work through this.


Ok, thanks.



It would be nice to be able to handle this without changing anything.


I can commit this change if it helps.


This assumes it is ok and I prefer we get posted test results before such a
change. Until we have this we need to wait until we all each do a level of
testing we are happy with. A solution that lets us test would steam line this.

I think this is a use case where something added to the RSB may be required to
make this easier. For example logic in a bset file would be nice.


Your idea is excellent, but I think we also may need something more 
simple and history preserving for the time releases are already done.


Hence I sent a patch series creating config/6.1 as a preparation for 6.1 
release with gcc 10 and update 6 (as a 6 branch dev) with Sebastian's 
updated GCC 12).


Just meant as material for discussion.

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

Re: GCC version for RTEMS 6? (Can Ada be used?)

2022-04-27 Thread Karel Gardas


On 4/27/22 19:25, Frank Kühndel wrote:

I do not need ADA but ADA may be worth considering. With GCC 10 one
needed to have a GNAT 10 compiler installed to build the tools incl.
--with_ada. I presume, one would need a GNAT 12 to build ADA with the
GCC 12 sources? The current Fedora 35 has GNAT 11. All other distros I
know of have GNAT 10 at best (I have not checked on tumbleweed yet).
OpenSUSE may get ADA 12 from an unusual repro???


On https://gcc.gnu.org/install/prerequisites.html there is a text:

"
GNAT

In order to build GNAT, the Ada compiler, you need a working GNAT 
compiler (GCC version 5.1 or later).


...
"

is it outdated? If so, this would require some bugreport to gcc team?

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

Re: GCC version for RTEMS 6? (Can Ada be used?)

2022-04-27 Thread Karel Gardas


On 4/27/22 20:12, Frank Kühndel wrote:

Hi Karel,

On 4/27/22 19:46, Karel Gardas wrote:

On 4/27/22 19:25, Frank Kühndel wrote:

I do not need ADA but ADA may be worth considering. With GCC 10 one
needed to have a GNAT 10 compiler installed to build the tools incl.
--with_ada. I presume, one would need a GNAT 12 to build ADA with the
GCC 12 sources? The current Fedora 35 has GNAT 11. All other distros I
know of have GNAT 10 at best (I have not checked on tumbleweed yet).
OpenSUSE may get ADA 12 from an unusual repro???


On https://gcc.gnu.org/install/prerequisites.html there is a text:

"
GNAT

     In order to build GNAT, the Ada compiler, you need a working GNAT
compiler (GCC version 5.1 or later).

...
"

is it outdated? If so, this would require some bugreport to gcc team?


The text says too: "Other native compiler versions may work but this is
not guaranteed and will typically fail with hard to understand
compilation errors during the build."



Hmm, I see, thanks for correcting me, but your citation is missing one 
important detail:


"In order to build a cross compiler, it is strongly recommended to 
install the new compiler as native first, and then use it to build the 
cross compiler."


So I'm afraid this looks like ball is on the RSB side which should first 
build native compiler of required version -- for this you may use older 
GNAT (at least GCC 5.1) and then use exactly this compiler to build a 
cross-compiler.


E.g. GNAT 10 native -> GNAT 12 native -> GNAT 12 cross-compiler (RTEMS).

Is that correct?

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

Re: Building RTEMS 6 toolchain on a Mac

2022-04-27 Thread Karel Gardas


On 4/27/22 08:48, Sebastian Huber wrote:

On 27.04.22 08:45, Karel Gardas wrote:

On 4/27/22 06:46, Sebastian Huber wrote:

On 26.04.22 22:57, Karel Gardas wrote:

On 4/25/22 10:10, Sebastian Huber wrote:

Hello Heinz,

you are probably one of the first persons building GCC 12 on this 
platform. I checked in a change which could fix the problem.




Not sure if this is related, but after this hacking I'm no longer 
able to build neither 6/rtems-arm not 6/rtems-x86_64.


I changed the mpfr version from 3.1.4 to 4.1.0. This is the latest 
mpfr release and used by the GCC contrib/download_prerequisites 
script currently. If this version doesn't build on macOS, then it 
would be good to submit a bug report to mpfr.


The problem is that I'm perfectly able to build 4.1.0 including 
testsuite including its run on catalina. So the problem is somewhere 
else and rsb logging was just misleading...


The RTEMS 7 RSB configuration still uses mpfr-4.1.0 (and GCC 12), maybe 
you can check it here.


I'm a little bit confused since HEAD works fine with 7/rtems-arm and 
7/rtems-x86_64 on catalina. So I reverted patches up to:


me@mes-MacBook-Pro rtems % git log -1
commit 70f302e08c9053637f5eff7dfb52d3442aaf76cb (HEAD)
Author: Chris Johns 
Date:   Tue Apr 26 10:13:41 2022 +1000

gdb: Split python's version into major/minor and check for embed option

Closes #4631


and now, 6/rtems-x86_64 correctly fails as I reported, but 
7/rtems-x86_64 builds fine again.


Diffing shows quite major differences between rtems-default.bset files 
for 6/ and 7/ so I guess that's the reason...


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

Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL

2022-07-30 Thread Karel Gardas


On 7/30/22 16:32, o...@c-mauderer.de wrote:

  bsps/arm/include/cmsis_compiler.h |   266 +
  bsps/arm/include/cmsis_gcc.h  |  3460 +--
  bsps/arm/include/cmsis_version.h  |    39 +
  bsps/arm/include/core_cm4.h   |   524 +-
  bsps/arm/include/core_cm7.h   |  5186 ++--
  bsps/arm/include/mpu_armv7.h  |   270 +


Are the cmsis files from the same source or directly from ARM?

The cmsis_gcc.h has a lot of changes compared to the earlier version 
that has been present in RTEMS. A lot of the changes seem to be 
whitespace changes. Can these be avoided somehow (for example by using 
dos2unix before overwriting the file)?


In the discord chat there was one suggestion from Ho Kaido to move the 
files one level down and make them BSP specific. I'm not sure whether 
I'm for or against that idea. Advantage is that it makes BSPs 
independant from each other. Disadvantage is that it duplicates code.


I think I would try to avoid moving them down due to the code 
duplication but it raises the question: Which BSPs use the files too and 
did you try whether they still compile after the upgrade?


We have had this dicussion with Duc on discord IIRC when he started. He 
needed new CMSIS (v5) version due to new HAL which Duc claims depends on 
them. I have not verified that claim personally.


New CMSIS v5 brings obviously:

- by ARM maintained code (v4 is unmaintained IIRC)

but also:

- license change from BSD to Apache-2

At that time I've told Duc to continue with the code and not to worry 
about license changes -- as this would be longer discussion anyway. Not 
sure, but IIRC he also wrote to Sebastian asking for clarification -- 
well, not sure about that. Certainly IIRC I suggested that.


Anyway, I took Duc code and try H7 BSPs and to my surprise they compiles 
more or less all without any compilation related issue. Well, I've not 
tried M4 variants. So far I've not run full tester on this. I'll, but 
first I'd like to test his API if it's possible to also use with H7.


BTW: if RTEMS prefer old unmaintained BSD-3 ARM CSMIS code, then it's 
perhaps possible to go in F4 HAL history back and grab just the three 
with the v4 dependency. On the other hand, for ARM Apache-2 seems to be 
the way forward and for some ST.com depended code too -- so I guess 
RTEMS project will need to live with that fact somehow.


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

[PATCH] devel/sis: fix compilation of SIS on Mac OS X

2022-10-24 Thread Karel Gardas

SIS compiles on Mac OS X fine, but without providing --host/--build
configure options. Removing them solves the issue of configure not being
able to recognize arm64-darwin platform.
---
 source-builder/config/sis-2-1.cfg | 1 -
 1 file changed, 1 deletion(-)

diff --git a/source-builder/config/sis-2-1.cfg 
b/source-builder/config/sis-2-1.cfg
index a07b2db..a3b9515 100644
--- a/source-builder/config/sis-2-1.cfg
+++ b/source-builder/config/sis-2-1.cfg
@@ -43,7 +43,6 @@ Release:   %{release}
   fi
   CFLAGS="$SB_CFLAGS" \
   ./configure \
---build=%{_build} --host=%{_host} \
 --program-prefix="$SIS_PREFIX" \
 --prefix=${ac_prefix}
 
-- 
2.25.1

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

[PATCH] testproc/gsed: fix compilation of GNU sed on Mac OS X

2022-10-23 Thread Karel Gardas

GNU sed compiles on Mac OS X fine, but without providing --host/--build
configure options. Hence removing them solved the issue of configure
not being able to recognize arm64-darwin platform.
---
 source-builder/config/gsed-1.cfg | 1 -
 1 file changed, 1 deletion(-)

diff --git a/source-builder/config/gsed-1.cfg b/source-builder/config/gsed-1.cfg
index 828da50..87eb0fb 100644
--- a/source-builder/config/gsed-1.cfg
+++ b/source-builder/config/gsed-1.cfg
@@ -86,7 +86,6 @@ URL: https://www.gnu.org/software/sed/
 --mandir=%{gsed_mandir} \
 --infodir=%{gsed_infodir} \
 --datadir=%{gsed_datadir} \
---build=%{_build} --host=%{_host}
 
   %{__make} %{?_smp_mflags} all
 
-- 
2.25.1

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

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

2022-09-21 Thread Karel Gardas



The problem is that we still need to discuss licensing here. Randomly 
checked files from the HAL patch contains this as a license:


  * This software is licensed under terms that can be found in the 
LICENSE file

  * in the root directory of this software component.
  * If no LICENSE file comes with this software, it is provided AS-IS.

and in the past Sebastian suggested to clear the message hence I used 
something used here:


https://github.com/dtbpkmte/GSoC-2022-RTEMS/blob/master/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c


unfortunately whole F4 HAL would probably need such modification.


On the bright side, it looks like STM still holds on BSD-3 for their HAL 
code for F4?


https://github.com/STMicroelectronics/STM32CubeF4/blob/master/LICENSE.md

Would be great indeed.

BTW: sorry, I'm really out of the loop on this still trying to catch up 
with all the development in RTEMS over summer...


Karel



On 9/21/22 15:25, Joel Sherrill wrote:

This patch set has been sitting for almost 7 weeks. I was going to commit
it today but was asked to give one last the patch merge equivalent  of
""if anyone can show just cause why this patch and RTEMS cannot  be
joined together, let them speak now or forever hold their peace"

Or at least be nice about not holding their peace. :)

Two days and I merge this. I will aim for high noon on Friday.

--joel

On Sun, Aug 7, 2022 at 5:58 AM Duc Doan > wrote:


Dear all,

These patches are to address the issues in my previous versions. These
include GPIO API, ADC API and STM32F4 BSP implementation for them.

My repository is at: https://github.com/dtbpkmte/GSoC-2022-RTEMS
 (master
branch).
The sample application code for these APIs can be found at:
https://github.com/dtbpkmte/GSoC-2022-RTEMS-Sample-Apps
.

STM32F4 HAL source code is taken from ST's repo at:
https://github.com/STMicroelectronics/STM32CubeF4.git
 (Commit ID:
52757b5,
Release v1.27.1).

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

v5:
- Replace old HAL source code with the one from official repository
to remove
CRLF
- Added a peripherals API, which is a framework to add more APIs
that operates
on a GPIO pin
- Changed GPIO API to comply with the peripherals API
- Changed ADC API to comply with the peripherals API
- Changed STM32F4 implementation

v6:
- Split commits that add CMSIS and HAL
- Removed peripheral API
- Changed ADC API: this is now separate from GPIO API

Duc Doan (10):
   bsps/arm: Convert CMSIS files from CRLF to LF
   bsps/arm: Changed CMSIS files to v5
   build/bsps/arm: Add new CMSIS files v5 to build
   bsps/arm/stm32f4: Include STM32F4 HAL
   bsps/arm/stm32f4: Add HAL to build
   bsps/arm/stm32f4: Make bspstart use HAL
   bsps: Add GPIO API
   bsps/arm/stm32f4: GPIO Implementation
   bsps: Add ADC API
   bsps/arm/stm32f4: ADC API implementation

  bsps/arm/include/cmsis_compiler.h             |   266 +
  bsps/arm/include/cmsis_gcc.h                  |  3460 +--
  bsps/arm/include/cmsis_version.h              |    39 +
  bsps/arm/include/core_cm4.h                   |   524 +-
  bsps/arm/include/core_cm7.h                   |  5186 ++--
  bsps/arm/include/core_cmFunc.h                |   172 +-
  bsps/arm/include/core_cmInstr.h               |   174 +-
  bsps/arm/include/core_cmSimd.h                |   192 +-
  bsps/arm/include/mpu_armv7.h                  |   270 +
  bsps/arm/stm32f4/adc/adc.c                    |   495 +
  bsps/arm/stm32f4/gpio/gpio.c                  |   557 +
  .../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 ++

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

2022-09-21 Thread Karel Gardas


On 9/21/22 15:48, Karel Gardas wrote:
On the bright side, it looks like STM still holds on BSD-3 for their HAL 
code for F4?


https://github.com/STMicroelectronics/STM32CubeF4/blob/master/LICENSE.md

Would be great indeed.


After very quick investigation, everything under CMSIS is under Apache 
2.0 including this file:


https://github.com/STMicroelectronics/STM32CubeF4/blob/master/Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/system_stm32f4xx.c

which is probably copied here:

https://github.com/dtbpkmte/GSoC-2022-RTEMS/blob/master/bsps/arm/stm32f4/hal/system_stm32f4xx.c

Duc, am I right?

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

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

2022-09-22 Thread Karel Gardas

On 9/22/22 00:00, Gedare Bloom wrote:

On Wed, Sep 21, 2022 at 9:12 AM Joel Sherrill wrote:

On Wed, Sep 21, 2022 at 8:48 AM Karel Gardas wrote:

The problem is that we still need to discuss licensing here. Randomly
checked files from the HAL patch contains this as a license:

* This software is licensed under terms that can be found in the
LICENSE file
* in the root directory of this software component.
* If no LICENSE file comes with this software, it is provided AS-IS.

and in the past Sebastian suggested to clear the message hence I used
something used here:

https://github.com/dtbpkmte/GSoC-2022-RTEMS/blob/master/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c

I'm OK with an explanation like that but I hate to see that much duplicated
over and over. Would it be possible to put the lengthy explanation in one
place with the HAL addition and then have a short explanation in each file:

/*
* RTEMS committer clarification comment on license above:
*
* This file comes from STM32CubeH7 project from its Projects subdirectory. See
* RTEMS_PATH_TBD for details on the license for this file.
*/

With RTEMS_PATH_TBD probably easy to identify because it would
be something like bsps/arm/shared/STMHM7 and then the single
file with a name that is like LICENSE_STM32CubeH7.txt so it isn't just
LICENSE.txt which is easy to confuse.

Just a practical matter of avoiding duplication. We have precedence
for this over the project history.

This is just record keeping to maintain proper attribution, origin URL,
licensing, etc. without burden of duplication. They obviously thought it
was a duplication burden. We should use their trick and just point to
our location for that file. :)

It's not like we are trying to nick the code and not give credit. We are
likely in the small minority even doing this much. My expectations are
pretty low for most people/projects.

We had a discussion about this topic over on Discord. The general
resolution there was that we should consider importing the HAL code
as-is, and then layer on another patch to inject SPDX tags for the
appropriate license into each imported file. Then the committer (In
this case, Duk) should write up an ORIGIN kind of file to put into the
directory above the HAL to explain the history of the code there,
where it came from (URLs), how the licenses were sorted, and any other
information that helps understand the source of that code. This
balances the effort needed to update the HAL code later, since if it
changes only minimally, we can just re-import it, re-inject the SPDX
tags, and update the ORIGIN file. In this case, I'd say add something
like ORIGIN.HAL in the stm32f4 directory to capture the documentation
about the import process for the HAL.

Sounds good! Last remark and question. What about Apache 2.0 license
which covers at least some of the files from STM and which we use in
"hal" subdirectory. Is everything settled and the project may use such
files? In the past at least Sebastian and Chris were reserved and raised
some questions about Apache 2.0 license details...

Asking since this exactly applies to STM32H7 BSP HAL too so it'd ve
great to have that sorted out in the same way here.

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

Re: [PATCH v6 00/10] New GPIO, ADC API and STM32F4 BSP implementation

2022-09-22 Thread Karel Gardas

On 9/22/22 10:41, Sebastian Huber wrote:

On 22/09/2022 10:30, Karel Gardas wrote:

On 9/22/22 00:00, Gedare Bloom wrote:

On Wed, Sep 21, 2022 at 9:12 AM Joel Sherrill wrote:

On Wed, Sep 21, 2022 at 8:48 AM Karel Gardas
wrote:

The problem is that we still need to discuss licensing here. Randomly
checked files from the HAL patch contains this as a license:

* This software is licensed under terms that can be found in the
LICENSE file
* in the root directory of this software component.
* If no LICENSE file comes with this software, it is provided
AS-IS.

and in the past Sebastian suggested to clear the message hence I used
something used here:

https://github.com/dtbpkmte/GSoC-2022-RTEMS/blob/master/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c

I'm OK with an explanation like that but I hate to see that much
duplicated
over and over. Would it be possible to put the lengthy explanation
in one
place with the HAL addition and then have a short explanation in
each file:

/*
* RTEMS committer clarification comment on license above:
*
* This file comes from STM32CubeH7 project from its Projects
subdirectory. See

* RTEMS_PATH_TBD for details on the license for this file.
*/

Just a practical matter of avoiding duplication. We have precedence
for this over the project history.

This is just record keeping to maintain proper attribution, origin URL,
licensing, etc. without burden of duplication. They obviously
thought it

was a duplication burden. We should use their trick and just point to
our location for that file. :)

It's not like we are trying to nick the code and not give credit. We
are

likely in the small minority even doing this much. My expectations are
pretty low for most people/projects.

Sounds good! Last remark and question. What about Apache 2.0 license
which covers at least some of the files from STM and which we use in
"hal" subdirectory. Is everything settled and the project may use such
files? In the past at least Sebastian and Chris were reserved and
raised some questions about Apache 2.0 license details...

Asking since this exactly applies to STM32H7 BSP HAL too so it'd ve
great to have that sorted out in the same way here.

I don't like the Apache 2.0 license due to this clause:

"You must cause any modified files to carry prominent notices stating
that You changed the files; and"

With a need to use SPDX identitifer on top of every file the project may
probably also do:

(1) add an option of 'This file was changed by RTEMS project.' clausule
to top of the file probably below SPDX id for Apache 2.0 licensed files.

and

(2) implement git commit hook to check that every single file with
Apache 2.0 SPDX contains (1).

Would that fulfill requirements of Apache 2.0 license?

This means that the reviewer of RTEMS Project contributions has to check
this for each Apache 2.0 file.

We also have to check if imported Work as a NOTICE file, since then this
applies also:

"If the Work includes a "NOTICE" text file as part of its distribution,
then any Derivative Works that You distribute must include a readable
copy of the attribution notices contained within such NOTICE file,
excluding those notices that do not pertain to any part of the
Derivative Works, in at least one of the following places: within a
NOTICE text file distributed as part of the Derivative Works; within the
Source form or documentation, if provided along with the Derivative
Works; or, within a display generated by the Derivative Works, if and
wherever such third-party notices normally appear. The contents of the
NOTICE file are for informational purposes only and do not modify the
License. You may add Your own attribution notices within Derivative
Works that You distribute, alongside or as an addendum to the N

Re: How can I use the GCC -frandom-seed= option with the waf build system?

2022-09-23 Thread Karel Gardas


On 9/23/22 18:35, Sebastian Huber wrote:

Hello,

I have a question for the waf experts. How can I use the GCC 
-frandom-seed= option with the waf build system?


https://stackoverflow.com/questions/73829827/how-can-i-use-the-gcc-frandom-seed-file-name-option-with-the-waf-build-system 


Unix? Why not to use pure and simple -frandom-seed=$RANDOM ? E.g. I hope 
you'd like to have something there hence went for file name which will 
give you stable "random" value per every file compiled while $RANDOM 
will give you more randomness and certainly not the same value per same 
file...


Karel



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

Re: [PATCH rtems-docs v3] raspberrypi4.rst: Documentation for the new AArch64 Raspberry pi 4B BSP

2022-10-06 Thread Karel Gardas


On 10/6/22 20:14, Kinsey Moore wrote:
+Raspberry Pi uses a different mechanism to boot. First the GPU 
initializes,


A different mechanism as compared to what? Is this sentence important to 
users?


Should GPU be CPU, instead?


Sorry for hijacking, but no, this sentence is right. GPU core on RPi is 
responsible for running its own RTOS (IIRC ThreadX?) and initializing 
CPU and then booting it.


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

Re: [PATCH 1/3] build: Format build items

2023-01-19 Thread Karel Gardas




Sorry to hijack that thread, but correction is needed here.

On 1/20/23 01:03, Chris Johns wrote:

The FreeBSD single repo is about the kernel and base runtime. The ports are not
part of this so the analogy breaks down.


Certainly all BSDs have separated ports repos, but AFAIK all of them 
maintain so called base and in base there is kernel, libs, bin/sbin 
commands and most importantly *all* tool-chain required to build *all* 
this code to form whole OS. IMHO this rebuild whole OS distro is 
discussed here, isn't it? If not, I'm sorry for noise here...


Karel


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

Re: [PATCH 1/3] bsps/stm32h7: import MT25TL01G QSPI memory low-level driver

2023-01-30 Thread Karel Gardas


On 1/30/23 16:13, Gedare Bloom wrote:

On Fri, Jan 27, 2023 at 11:41 AM Karel Gardas  wrote:


Sponsored-By:   Precidata
---

No issue with the patch, but I think it is awkward to have this
"Sponsored-By" in an import patch.


Was also thinking about that. Whole work was sponsored including import 
of this code, but code obviously was not.


I'll remove that remark indeed.

Thanks!
Karel

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

Question w.r.t. crash inside select call from libbsd.

2023-01-30 Thread Karel Gardas




 Hello,

I'm debugging crash inside the select call from libbsd library. The code 
comes from few days old RTEMS and few days old libbsd trees. My naive 
configuration for the RTEMS is below.


The crash backtrace is:

_CPU_Fatal_halt (source=source@entry=9, error=, 
error@entry=604203640) at ../../../cpukit/score/cpu/arm/cpu.c:203

203   while ( true ) {
(gdb) where
#0  _CPU_Fatal_halt (source=source@entry=9, error=, 
error@entry=604203640)

at ../../../cpukit/score/cpu/arm/cpu.c:203
#1  0x080fb9b4 in _Terminate 
(the_source=the_source@entry=RTEMS_FATAL_SOURCE_EXCEPTION,

the_error=604203640) at ../../../cpukit/score/src/interr.c:58
#2  0x08104e56 in rtems_fatal (fatal_code=,
fatal_source=RTEMS_FATAL_SOURCE_EXCEPTION) at 
../../../cpukit/include/rtems/fatal.h:160

#3  _ARM_Exception_default (frame=)
at ../../../cpukit/score/cpu/arm/arm-exception-default.c:37
#4  
#5  _bsd_uma_zalloc_arg (zone=0x9, udata=udata@entry=0x0, 
flags=flags@entry=2)

at ../../freebsd/sys/vm/uma_core.c:2624
#6  0x0807c180 in uma_zalloc (flags=2, zone=)
at ../../freebsd/sys/vm/uma.h:356
#7  0x080b51b8 in rtems_bsd_thread_create (thread=0xd0003048 
<_RTEMS_tasks_Objects>,

wait=) at ../../rtemsbsd/rtems/rtems-kernel-thread.c:93
#8  0x080b5250 in rtems_bsd_get_curthread (wait=0)
at ../../rtemsbsd/rtems/rtems-kernel-thread.c:116
#9  0x0807e59a in select (nfds=1, readfds=readfds@entry=0xd000da30,
writefds=writefds@entry=0xd000da38, errorfds=errorfds@entry=0x0,
_bsd_timeout=_bsd_timeout@entry=0x0) at 
../../freebsd/sys/kern/sys_generic.c:1170



When I put breakpoint here and there I found strange fact that zone = 
0x0 in frame #5 and not 0x9:


Breakpoint 1, _bsd_uma_zalloc_arg (zone=0x0, udata=udata@entry=0x0, 
flags=flags@entry=2) at ../../freebsd/sys/vm/uma_core.c:2562

2562{
(gdb) next
2680bucket_free(zone, bucket, udata);
(gdb) next
2622critical_enter();
(gdb) next
196   cpu_self->thread_dispatch_disable_level = disable_level + 1;
(gdb) next
2622critical_enter();
(gdb) next
2624cache = >uz_cpu[cpu];
(gdb) next
_ARMV7M_Exception_default () at 
../../../cpukit/score/cpu/arm/armv7m-exception-default.c:51

51__asm__ volatile (
(gdb)


so with zone being NULL the crash is expected here. However I'm still 
curious if this is libbsd issue or my issue with naive configuration?


The platform is STM32H757i-eval board, the linking is using flash_sdram 
configuration. The board provides 16MB of SDRAM so hopefully this should 
be enough even for libbsd... The board configuration is more or less 
default except disabling of MPU alignment. If I don't do this, my 
testing app (quickjs) would not fit 2MB of CPU flash. When MPU alignment 
is disabled, I'm on 1.4MB of flash consumption (before disabling 2.3MB)


Any ideas how to debug this more are highly appreciated!

Thanks!
Karel



/*
 * Configure LibBSD.
 */

#define RTEMS_BSD_CONFIG_NET_PF_UNIX
#define RTEMS_BSD_CONFIG_NET_IF_BRIDGE
#define RTEMS_BSD_CONFIG_NET_IF_LAGG
#define RTEMS_BSD_CONFIG_NET_IF_VLAN
#define RTEMS_BSD_CONFIG_BSP_CONFIG
#define RTEMS_BSD_CONFIG_TERMIOS_KQUEUE_AND_POLL
#define RTEMS_BSD_CONFIG_INIT

#include 

/*
 * Configure RTEMS.
 */

/* This is enough to get a basic main() up. */
#define CONFIGURE_RTEMS_INIT_TASKS_TABLE
#define CONFIGURE_UNIFIED_WORK_AREAS
#define CONFIGURE_STACK_CHECKER_ENABLED

/* on smaller architectures lower the number or resources */
#define CONFIGURE_UNLIMITED_OBJECTS
#define CONFIGURE_MAXIMUM_USER_EXTENSIONS 8
#define CONFIGURE_MAXIMUM_DRIVERS 16
#define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS 32

/* Include basic device drivers needed to call delays */
#define CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_CONSOLE_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_STUB_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_ZERO_DRIVER
#define CONFIGURE_APPLICATION_NEEDS_LIBBLOCK

#define CONFIGURE_MAXIMUM_PROCESSORS CPU_MAXIMUM_PROCESSORS

/* #define CONFIGURE_DISABLE_BSP_SETTINGS*/

#define CONFIGURE_VERBOSE_SYSTEM_INITIALIZATION

#define CONFIGURE_MINIMUM_TASK_STACK_SIZE ( CPU_STACK_MINIMUM_SIZE * 4 )

#define CONFIGURE_INIT

#include 

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

[PATCH 1/3] bsps/stm32h7: import MT25TL01G QSPI memory low-level driver

2023-01-27 Thread Karel Gardas

Sponsored-By:   Precidata
---
 .../stm/Components/mt25tl01g/mt25tl01g.c  | 1046 +
 .../stm/Components/mt25tl01g/mt25tl01g.h  |  362 ++
 .../stm/Components/mt25tl01g/mt25tl01g_conf.h |   68 ++
 3 files changed, 1476 insertions(+)
 create mode 100644 bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c
 create mode 100644 bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.h
 create mode 100644 
bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g_conf.h

diff --git a/bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c 
b/bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c
new file mode 100644
index 00..740cdbbd27
--- /dev/null
+++ b/bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c
@@ -0,0 +1,1046 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
+/**
+  
**
+  * @fileMT25TL01G.c
+  * @author  MCD Application Team
+  * @brief   This file provides the MT25TL01G QSPI driver.
+  
**
+  * @attention
+  *
+  *  Copyright (c) 2016 STMicroelectronics.
+  * All rights reserved.
+  *
+  * This software component is licensed by ST under BSD 3-Clause license,
+  * the "License"; You may not use this file except in compliance with the
+  * License. You may obtain a copy of the License at:
+  *opensource.org/licenses/BSD-3-Clause
+  *
+  
**
+  */
+/* Includes 
--*/
+#include "mt25tl01g.h"
+/** @addtogroup BSP
+  * @{
+  */
+
+/** @addtogroup Components
+  * @{
+  */
+
+/** @addtogroup MT25TL01G
+  * @brief This file provides a set of functions needed to drive the
+  * MT25TL01G QSPI memory.
+  * @{
+  */
+/** @defgroup MT25TL01G_Exported_Functions MT25TL01G Exported Functions
+  * @{
+  */
+
+/**
+  * @brief  Return the configuration of the QSPI memory.
+  * @param  pInfo pointer on the configuration structure
+  * @retval QSPI memory status
+  */
+int32_t MT25TL01G_GetFlashInfo(MT25TL01G_Info_t *pInfo)
+{
+  pInfo->FlashSize  = MT25TL01G_FLASH_SIZE;
+  pInfo->EraseSectorSize= (2 * MT25TL01G_SUBSECTOR_SIZE);
+  pInfo->ProgPageSize   = MT25TL01G_PAGE_SIZE;
+  pInfo->EraseSectorsNumber = (MT25TL01G_FLASH_SIZE/pInfo->EraseSectorSize);
+  pInfo->ProgPagesNumber= (MT25TL01G_FLASH_SIZE/pInfo->ProgPageSize);
+  return MT25TL01G_OK;
+}
+
+/**
+  * @brief  This function set the QSPI memory in 4-byte address mode
+  *  SPI/QPI; 1-0-1/4-0-4
+  * @param  Ctx Component object pointer
+  * @param  Mode Interface mode
+  * @retval QSPI memory status
+  */
+int32_t MT25TL01G_Enter4BytesAddressMode(QSPI_HandleTypeDef *Ctx, 
MT25TL01G_Interface_t Mode)
+{
+  QSPI_CommandTypeDef s_command;
+
+  /* Initialize the command */
+  s_command.InstructionMode   = (Mode == MT25TL01G_QPI_MODE) ? 
QSPI_INSTRUCTION_4_LINES : QSPI_INSTRUCTION_1_LINE;
+  s_command.Instruction   = MT25TL01G_ENTER_4_BYTE_ADDR_MODE_CMD;
+  s_command.AddressMode   = QSPI_ADDRESS_NONE;
+  s_command.AlternateByteMode = QSPI_ALTERNATE_BYTES_NONE;
+  s_command.DataMode  = QSPI_DATA_NONE;
+  s_command.DummyCycles   = 0;
+  s_command.DdrMode   = QSPI_DDR_MODE_DISABLE;
+  s_command.DdrHoldHalfCycle  = QSPI_DDR_HHC_ANALOG_DELAY;
+  s_command.SIOOMode  = QSPI_SIOO_INST_EVERY_CMD;
+
+  /*write enable */
+  if( MT25TL01G_WriteEnable(Ctx,Mode)!=MT25TL01G_OK)
+  {
+return MT25TL01G_ERROR_COMMAND;
+  }
+  /* Send the command */
+  if (HAL_QSPI_Command(Ctx, _command, HAL_QPSI_TIMEOUT_DEFAULT_VALUE) != 
HAL_OK)
+  {
+return MT25TL01G_ERROR_COMMAND;
+  }
+
+  /* Configure automatic polling mode to wait the memory is ready */
+  else if(MT25TL01G_AutoPollingMemReady(Ctx,Mode)!=MT25TL01G_OK)
+  {
+return MT25TL01G_ERROR_COMMAND;
+  }
+
+  return MT25TL01G_OK;
+}
+
+/**
+  * @brief  Flash exit 4 Byte address mode. Effect 3/4 address byte commands 
only.
+  * SPI/QPI; 1-0-0/4-0-0
+  * @param  Ctx Component object pointer
+  * @param  Mode Interface mode
+  * @retval QSPI memory status
+  */
+int32_t MT25TL01G_Exit4BytesAddressMode(QSPI_HandleTypeDef *Ctx, 
MT25TL01G_Interface_t Mode)
+{
+  QSPI_CommandTypeDef s_command;
+
+  /* Initialize the command */
+  s_command.InstructionMode   = (Mode == MT25TL01G_QPI_MODE) ? 
QSPI_INSTRUCTION_4_LINES : QSPI_INSTRUCTION_1_LINE;
+  s_command.Instruction   = MT25TL01G_EXIT_4_BYTE_ADDR_MODE_CMD;
+  s_command.AddressMode   = QSPI_ADDRESS_NONE;
+  s_command.AlternateByteMode = QSPI_ALTERNATE_BYTES_NONE;
+  s_command.DataMode  = QSPI_DATA_NONE;
+  s_command.DummyCycles   = 0;
+  s_command.DdrMode   = QSPI_DDR_MODE_DISABLE;
+  s_command.DdrHoldHalfCycle  = QSPI_DDR_HHC_ANALOG_DELAY;
+  s_command.SIOOMode  =

[PATCH 2/3] bsps/stm32h7: import stm32h757i-eval QSPI memory high-level driver

2023-01-27 Thread Karel Gardas

Sponsored-By:   Precidata
---
 .../stm32h757i-eval/stm32h747i_eval_conf.h|  130 ++
 .../stm32h757i-eval/stm32h747i_eval_errno.h   |  105 ++
 .../stm32h757i-eval/stm32h747i_eval_qspi.c| 1088 +
 .../stm32h757i-eval/stm32h747i_eval_qspi.h|  284 +
 4 files changed, 1607 insertions(+)
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_conf.h
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_errno.h
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_qspi.c
 create mode 100644 
bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_qspi.h

diff --git a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_conf.h 
b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_conf.h
new file mode 100644
index 00..673125eec3
--- /dev/null
+++ b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_conf.h
@@ -0,0 +1,130 @@
+/* SPDX-License-Identifier: BSD-3-Clause */
+/** 
+  
**
+  * @filestm32h747i_eval_config.h
+  * @author  MCD Application Team
+  * @brief   STM32H747I_EVAL board configuration file.
+  
**
+  * @attention
+  *
+  * Copyright (c) 2019 STMicroelectronics.
+  * All rights reserved.
+  *
+  * This software is licensed under terms that can be found in the LICENSE file
+  * in the root directory of this software component.
+  * If no LICENSE file comes with this software, it is provided AS-IS.
+  *
+  
**
+  */
+/*
+ * RTEMS committer clarification comment on license above:
+ *
+ * This file comes from STM32CubeH7 project and is located here:
+ * 
https://github.com/STMicroelectronics/STM32CubeH7/blob/master/Drivers/BSP/STM32H747I-EVAL/stm32h747i_eval_conf_template.h
+ *
+ * The file root directory is:
+ * 
https://github.com/STMicroelectronics/STM32CubeH7/tree/master/Drivers/BSP/STM32H747I-EVAL
+ *
+ * This directory contains LICENSE.md file with a following license text:
+ *
+ * Copyright 2019 STMicroelectronics.
+ * 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. 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.
+ */
+  
+/* Define to prevent recursive inclusion 
-*/
+#ifndef STM32H747I_EVAL_CONFIG_H
+#define STM32H747I_EVAL_CONFIG_H
+
+#ifdef __cplusplus
+ extern "C" {
+#endif
+
+/* Includes 
--*/
+#include "stm32h7xx_hal.h"
+
+   /* COM define */
+#define USE_COM_LOG 0U
+   
+   /* IO class usage define */  
+#define USE_BSP_IO_CLASS1U
+   
+   /* JOY usage define */
+#define USE_BSP_JOY_FEATURE 1U
+   
+   /* POT usage define */   
+#define USE_BSP_POT_FEATURE 1U
+   
+   /* LCD controllers defines */
+#define USE_LCD_CTRL_OTM8009A   1U
+#define USE_LCD_CTRL_ADV75331U
+#define LCD_LAYER_0_ADDRESS 0xD000U
+#define LCD_LAYER_1_ADDRESS 0xD020U
+   
+   /* SD high performance usage define */
+#define USE_SD_HIGH_PERFORMANCE 0U
+   
+   /*DMA2D to fill RGB rectangle usage define*/
+#define USE_DMA2D_TO_FILL_RGB_RECT  0U
+   
+   /* Audio codecs defines */
+#define USE_AUDIO_CODEC_WM8994  1U
+#define USE_AUDIO_CODEC_ADV7533

[PATCH 3/3] bsps/stm32h7: allow config and usage of QSPI memory on stm32h757i-eval BSP

2023-01-27 Thread Karel Gardas

The QSPI memory is initialized and used only when the BSP configure file
sets QSPI memory size to non-zero value. Currently QSPI is run in memory
mapped mode which allows future RTEMS binary linkage and upload into QSPI
memory.

Sponsored-By:   Precidata
---
 .../stm/stm32h757i-eval/stm32h7-bspstarthooks.c | 17 +
 bsps/arm/stm32h7/include/bsp.h  |  1 +
 .../bsps/arm/stm32h7/bspstm32h757i-eval.yml |  5 -
 spec/build/bsps/arm/stm32h7/optmemquadspisz.yml |  5 +
 4 files changed, 27 insertions(+), 1 deletion(-)

diff --git 
a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c 
b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
index 8d34e357ee..1bb81e3b60 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
@@ -36,6 +36,22 @@
 
 #include 
 
+#include 
+static BSP_QSPI_Init_t QSPinit;
+
+void stm32h7_init_qspi(void)
+{
+#if defined(STM32H7_MEMORY_QUADSPI_SIZE) && STM32H7_MEMORY_QUADSPI_SIZE > 0
+/* let's initialize Quad SPI memory here for memory mapped mode */
+/* due to usage of static QSPinit variable please call this function
+   after bsp_start_clear_bss call since otherwise you would hit 
uninitialized
+   variable memory while accessing it and in addition the call to 
bsp_start_clear_bss
+   would wipe the variable content later after its initialization here. */
+BSP_QSPI_Init(0, );
+BSP_QSPI_EnableMemoryMappedMode(0);
+#endif
+}
+
 void bsp_start_hook_0(void)
 {
   if ((RCC->AHB3ENR & RCC_AHB3ENR_FMCEN) == 0) {
@@ -75,4 +91,5 @@ void bsp_start_hook_1(void)
   SCB_InvalidateICache();
 #endif
   bsp_start_clear_bss();
+  stm32h7_init_qspi();
 }
diff --git a/bsps/arm/stm32h7/include/bsp.h b/bsps/arm/stm32h7/include/bsp.h
index 08311bf51e..cd4d25c069 100644
--- a/bsps/arm/stm32h7/include/bsp.h
+++ b/bsps/arm/stm32h7/include/bsp.h
@@ -62,6 +62,7 @@ void stm32h7_init_power(void);
 void stm32h7_init_oscillator(void);
 void stm32h7_init_clocks(void);
 void stm32h7_init_peripheral_clocks(void);
+void stm32h7_init_qspi(void);
 
 /** @} */
 
diff --git a/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval.yml 
b/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval.yml
index 5d7ee1348d..7516e55a3f 100644
--- a/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval.yml
+++ b/spec/build/bsps/arm/stm32h7/bspstm32h757i-eval.yml
@@ -8,7 +8,8 @@ copyrights:
 cppflags: []
 enabled-by: true
 family: stm32h7
-includes: []
+includes:
+- bsps/arm/stm32h7/boards/stm/stm32h757i-eval
 install: []
 links:
 - role: build-dependency
@@ -16,6 +17,8 @@ links:
 - role: build-dependency
   uid: tststm32h757i-eval
 source:
+- bsps/arm/stm32h7/boards/stm/Components/mt25tl01g/mt25tl01g.c
+- bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h747i_eval_qspi.c
 - bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
 - bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-config-clk.c
 - bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-config-osc.c
diff --git a/spec/build/bsps/arm/stm32h7/optmemquadspisz.yml 
b/spec/build/bsps/arm/stm32h7/optmemquadspisz.yml
index 82c48c7683..f4e39d979b 100644
--- a/spec/build/bsps/arm/stm32h7/optmemquadspisz.yml
+++ b/spec/build/bsps/arm/stm32h7/optmemquadspisz.yml
@@ -2,10 +2,15 @@ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
 actions:
 - get-integer: null
 - env-assign: null
+- define-unquoted: null
 build-type: option
 copyrights:
 - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
 default:
+- enabled-by:
+  - arm/stm32h757i-eval
+  - arm/stm32h757i-eval-m4
+  value: 0x0800
 - enabled-by: true
   value: 0x
 description: |
-- 
2.25.1

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

Apple's Ventura OS issue with RSB.

2022-11-06 Thread Karel Gardas




 Folks,

upgraded to Ventura from Monterey and this breaks RSB for unknown 
reason. The issue looks like segfault/internal compiler error in GCC 
while compiling newlib.


6/rtems-sparc:

  CC   libc/stdlib/libc_a-strtoll_r.o
  CC   libm/complex/libm_a-cpowf.o
../../../../gnu-mirror-gcc-a5a6598/newlib/libm/complex/cexpf.c: In 
function 'cexpf':
../../../../gnu-mirror-gcc-a5a6598/newlib/libm/complex/cexpf.c:47:9: 
internal compiler error: Segmentation fault: 11

   47 | w = r * cosf(y) + r * sinf(y) * I;
  | ^
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).

See  for instructions.
make[6]: *** [libm/complex/libm_a-cexpf.o] Error 1
make[6]: *** Waiting for unfinished jobs
  CC   libc/stdlib/libc_a-strtoull_r.o
  CC   libc/stdlib/libc_a-wcstoll.o
  CC   libc/stdlib/libc_a-wcstoll_r.o
  CC   libc/stdlib/libc_a-wcstoull.o
  CC   libc/stdlib/libc_a-wcstoull_r.o
  CC   libc/stdlib/libc_a-atoll.o
make[5]: *** [all] Error 2
make[4]: *** [multi-do] Error 1
make[3]: *** [all-multi] Error 2
make[3]: *** Waiting for unfinished jobs



6/rtems-arm:

  CC   libm/common/libm_a-s_isinf.o
  CC   libm/common/libm_a-s_isinfd.o
../../../../../../gnu-mirror-gcc-a5a6598/newlib/libm/common/s_expm1.c: 
In function 'expm1':

  CC   libm/common/libm_a-s_isnan.o
../../../../../../gnu-mirror-gcc-a5a6598/newlib/libm/common/s_expm1.c:225:9: 
internal compiler error: in real_from_string, at real.cc:2131

  225 | hfx = 0.5*x;
  | ^~~
  CC   libm/common/libm_a-s_isnand.o
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).

See  for instructions.
make[6]: *** [libm/common/libm_a-s_expm1.o] Error 1
make[6]: *** Waiting for unfinished jobs
  CC   libm/common/libm_a-s_log1p.o
make[5]: *** [all] Error 2
make[4]: *** [multi-do] Error 1
make[3]: *** [all-multi] Error 2
make[2]: *** [all] Error 2
make[1]: *** [all-target-newlib] Error 2
make: *** [all] Error 2
shell cmd failed: /bin/sh -ex 
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gcc-a5a6598



So just HEADS UP to those using Mac OS X on Apple silicon!

Karel

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

Re: Apple's Ventura OS issue with RSB.

2022-11-06 Thread Karel Gardas




Side note before answering : the email was motivated by the fact that I 
provided few patches to RSB to make that working well on Monterey 
running on M1. This was just few weeks ago so I know, this was running 
well. Last week I've updated to Ventura and things felt apart. Hence the 
report here.


On 11/6/22 16:09, Joel Sherrill wrote:
Is the cross gcc compiled with the native compiler provided by Apple? 


Yes, it is.


The alternative would likely be you installing something special.


No, I keep OS as clean as possible and as stock as possible to be as 
close as possible to customer configuration.


I wonder if using gcc to compile it would work. But there's not a real 
solution.


Indeed, I'll see if I can do anything about that as that would also be 
usable for...




Seems like an issue which needs reporting to gcc.



indeed, the report here is probably minimal thing I should do.

Thanks,
Karel

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

Re: Apple's Ventura OS issue with RSB.

2022-11-08 Thread Karel Gardas

More info on this issue:

(1) the issue (internal compiler error) does not happen all the time. In
fact there are builds which even complete. The ratio failure/ok is 10/30
so far -- building in a loop 6/rtems-sparc.

(2) attempt to bootstrap with GCC failed even more miserably. At least
with GCC 12.x I installed from homebrew. The symptoms are fork sys call
failing and a lot of processes created during the configure stage of
various packages in a manner that it's too much. Basically RSB's
packages' configure scripts are a fork bomb for whatever reason here on
Ventura when attempting to use homebrew GCC 12.x. See below.

Due to nature of unpredictability this is not something worth reporting
to GCC team now IMHO. We need to investigate more.

Ryan, if I'm not mistaken you have M1 mini for RTEMS builds, is that
right? If so, do you still have Monterey on it? If so, could you be so
kind and loop building of RSB's 6/rtems-sparc and allow it run for some
time to see if by any mistake we have not overlooked the same stability
issues on Monterey too? Let's say 1-2 days run should be enough to tell
us more or give us some confidence if all builds pass well.

What I did to my clean config in order to compile RSB is:

- install xz (from homebrew is fine), side effect of this is you will
get Apple's command line developer tools installed too -- which you need.

- compile python3.10 from source -- you need to enable SSL on it
otherwise RSB would not be able to download from https.

- set paths to those two and run RSB

Nothing more was needed on Monterey in order to RSB compile...

Thanks!
Karel

Fork issues (example):

checking for unistd.h... (cached) yes
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure:
fork: Resource temporarily unavailable

checking for sys/param.h... (cached) yes
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure:
fork: Resource temporarily unavailable

checking for getpagesize... (cached) yes
checking for working mmap... no
checking for working strncmp... no
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure:
fork: Resource temporarily unavailable
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure:
fork: Resource temporarily unavailable

configure: updating cache ./config.cache
configure: creating ./config.status
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure:
fork: Resource temporarily unavailable

./config.status: fork: Resource temporarily unavailable
./config.status: fork: Resource temporarily unavailable
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure:
fork: Resource temporarily unavailable
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure:
fork: Resource temporarily unavailable

make[1]: *** [configure-libiberty] Error 1
rm: conftest.dSYM: is a directory
BSD nm
checking whether ln -s works... yes

On 11/6/22 16:09, Joel Sherrill wrote:
Is the cross gcc compiled with the native compiler provided by Apple?
The alternative would likely be you installing something special.

I wonder if using gcc to compile it would work. But there's not a real
solution.

Seems like an issue which needs reporting to gcc.

On Sun, Nov 6, 2022, 5:25 AM Karel Gardas wrote:

Folks,

upgraded to Ventura from Monterey and this breaks RSB for unknown
reason. The issue looks like segfault/internal compiler error in GCC
while compiling newlib.

6/rtems-sparc:

CC libc/stdlib/libc_a-strtoll_r.o
CC libm/complex/libm_a-cpowf.o
../../../../gnu-mirror-gcc-a5a6598/newlib/libm/complex/cexpf.c: In
function 'cexpf':
../../../../gnu-mirror-gcc-a5a6598/newlib/libm/complex/cexpf.c:47:9:
internal compiler error: Segmentation fault: 11
47 | w = r * cosf(y) + r * sinf(y) * I;
| ^
libbacktrace could not find executable to open
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See <https://gcc.gnu.org/bugs/ <https://gcc.gnu.org/bugs/>> for
instructions.
make[6]: *** [libm/complex/libm_a-cexpf.o] Error 1
make[6]: *** Waiting for unfinished jobs...

Re: Apple's Ventura OS issue with RSB.

2022-11-06 Thread Karel Gardas


On 11/6/22 22:42, Chris Johns wrote:

indeed, the report here is probably minimal thing I should do.


Sebastian has pushed updates to the tools to the RSB. Did you happen to pick up
those?


Not at all! I'm still on:

https://git.rtems.org/rtems-source-builder/commit/?id=b02f7788e8bec38bbab9c57f65802e473d492a9c

Exactly the code working on Monterey.

Karel

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

Re: Apple's Ventura OS issue with RSB.

2022-11-12 Thread Karel Gardas

Hi,

more info on the issue. So, with Ventura I went up to 95 builds of
6/rtems-sparc from which 29 failed.

I've found out that M1 Parallels supports installing Mac OS X
installation into the VM hence went ahead and installed Monterey to have
both OSes available on the same box. Now, in Monterey VM I did 54 builds
of 6/rtems-sparc and with 0 failures. All built fine.

As the issue is pretty random it's really hard to report anything
meaningful to any community. Hence just heads up to you, if you are on
Mac OS X, expect some issues with Ventura -- till hopefully Apple fixes
those...

Karel

On 11/8/22 10:15, Karel Gardas wrote:

More info on this issue:

(1) the issue (internal compiler error) does not happen all the time. In
fact there are builds which even complete. The ratio failure/ok is 10/30
so far -- building in a loop 6/rtems-sparc.

Due to nature of unpredictability this is not something worth reporting
to GCC team now IMHO. We need to investigate more.

What I did to my clean config in order to compile RSB is:

- install xz (from homebrew is fine), side effect of this is you will
get Apple's command line developer tools installed too -- which you need.

- compile python3.10 from source -- you need to enable SSL on it
otherwise RSB would not be able to download from https.

- set paths to those two and run RSB

Nothing more was needed on Monterey in order to RSB compile...

Thanks!
Karel

Fork issues (example):

checking whether strtoull is declared... no
checking whether strverscmp is declared... no
checking whether strnlen is declared... no
checking whether canonicalize_file_name must be declared... yes
checking for stdlib.h... (cached) yes
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure:
fork: Resource temporarily unavailable
checking for unistd.h... (cached) yes
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure:
fork: Resource temporarily unavailable
checking for sys/param.h... (cached) yes
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure:
fork: Resource temporarily unavailable
checking for getpagesize... (cached) yes
checking for working mmap... no
checking for working strncmp... no
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure:
fork: Resource temporarily unavailable
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure:
fork: Resource temporarily unavailable
configure: updating cache ./config.cache
configure: creating ./config.status
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure:
fork: Resource temporarily unavailable
./config.status: fork: Resource temporarily unavailable
./config.status: fork: Resource temporarily unavailable
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure:
fork: Resource temporarily unavailable
/Users/karel/src/macosx-fix-sis/rtems/build/arm-rtems6-gdb-11.2-arm64-apple-darwin22.1.0-1/gdb-11.2/libiberty/configure:
fork: Resource temporarily unavailable
make[1]: *** [configure-libiberty] Error 1
rm: conftest.dSYM: is a directory
BSD nm
checking whether ln -s works... yes

On 11/6/22 16:09, Joel Sherrill wrote:
Is the cross gcc compiled with the native compiler provided by Apple?
The alternative would likely be you installing something special.

I wonder if using gcc to compile it would work. But there's not a real
solution.

Seems like an issue which needs reporting to gcc.

On Sun, Nov 6, 2022, 5:25 AM Karel Gardas
wrote:

Folks,

upgraded to Ventura from Monterey and this breaks RSB for unknown
reason. The issue looks like segfault/internal compiler error in GCC
while compiling newlib.

6/rtems-sparc:

CC libc/stdlib/libc_a-strtoll_r.o
CC libm/complex/libm_a-cpowf.o

Re: Question w.r.t. crash inside select call from libbsd.

2023-01-31 Thread Karel Gardas


On 1/31/23 07:30, Sebastian Huber wrote:
so with zone being NULL the crash is expected here. However I'm still 
curious if this is libbsd issue or my issue with naive configuration?


Did you use select() before libbsd is initialized? Do you have more than 
64 file descriptors? In this case the fd set type is too small and you 
have a stack overflow.


And this is exactly what was happening and why I increase STACK size 
insanely. Anyway, thanks to your help, this is no longer happening.


Which branch of libbsd do you use? Maybe try out 
the other branch as well.


master. I've thought this is were development happens, isn't it?

Also noted interesting thing. If I modify buildset to remove all USB, I 
still get linked error USB related (missing functions) due to functions 
being used from device-nexus.h. Is this current behavior or have I did 
anything wrong again?


E.g. stm32h7 USB setup in libbsd is wrong for my board (causes RTEMS 
crash) so I've tried to disable that by build set modification (all 
dev_usb* = off) and this does not helped hence I've modified 
device-nexus.h also to not use dwg at all.
Hmm, looks like patch like attach may solve the issue? At least it did 
for my case here. But I don't know if this is the right way to attack 
this issue.


 From the 16MiB you already waste 4MiB for unused features if you use 
the latest 6-freebsd-12 branch of libbsd.


No, master here. Also I've not attempted to optimize for size yet as the 
project is currently still not done yet.


Thanks!
Karel

diff --git a/rtemsbsd/include/bsp/nexus-devices.h b/rtemsbsd/include/bsp/nexus-devices.h
index d98e6f76..11f74771 100644
--- a/rtemsbsd/include/bsp/nexus-devices.h
+++ b/rtemsbsd/include/bsp/nexus-devices.h
@@ -187,6 +187,7 @@ RTEMS_BSD_DRIVER_USB_MASS;
 RTEMS_BSD_DEFINE_NEXUS_DEVICE(stmac, 0, 0, NULL);
 SYSINIT_DRIVER_REFERENCE(ukphy, miibus);
 
+#if defined(RTEMS_BSD_MODULE_DEV_USB_CONTROLLER)
 static const rtems_bsd_device_resource dwcotg_res[] = {
 	{
 		.type = RTEMS_BSD_RES_MEMORY,
@@ -200,6 +201,8 @@ static const rtems_bsd_device_resource dwcotg_res[] = {
 };
 RTEMS_BSD_DEFINE_NEXUS_DEVICE(dwcotg, 0, RTEMS_ARRAY_SIZE(dwcotg_res),
 dwcotg_res);
+#endif
+
 RTEMS_BSD_DRIVER_ST_SDMMC(0, SDMMC1_BASE, DLYB_SDMMC1_BASE, SDMMC1_IRQn);
 RTEMS_BSD_DRIVER_MMC;
 RTEMS_BSD_DRIVER_USB;
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Help regarding Building x86_64 BSP

2023-03-07 Thread Karel Gardas


On 3/8/23 01:42, Joel Sherrill wrote:

Did you build the x86_64 tools and qemu using the RTEMS Source Builder?


Honestly, I do not remember, this is more than year old, but since this 
is in 6-tools directory, in fact in two incarnation, I would bet this 
was done by RSB:


$ find . -name 'edk2*'
./6-tools-2021-12-09-x86_64/share/qemu/edk2-i386-secure-code.fd
./6-tools-2021-12-09-x86_64/share/qemu/edk2-licenses.txt
./6-tools-2021-12-09-x86_64/share/qemu/edk2-x86_64-code.fd
./6-tools-2021-12-09-x86_64/share/qemu/edk2-x86_64-secure-code.fd
./6-tools-2021-12-09-x86_64/share/qemu/edk2-i386-code.fd
./6-tools-2021-12-09-x86_64/share/qemu/edk2-i386-vars.fd
./6-tools-2021-12-09-x86_64/share/qemu/edk2-aarch64-code.fd
./6-tools-2021-12-09-x86_64/share/qemu/edk2-arm-vars.fd
./6-tools-2021-12-09-x86_64/share/qemu/edk2-arm-code.fd
./6-tools-pc686-2021-11-20/share/qemu/edk2-arm-code.fd
./6-tools-pc686-2021-11-20/share/qemu/edk2-i386-vars.fd
./6-tools-pc686-2021-11-20/share/qemu/edk2-aarch64-code.fd
./6-tools-pc686-2021-11-20/share/qemu/edk2-i386-code.fd
./6-tools-pc686-2021-11-20/share/qemu/edk2-arm-vars.fd
./6-tools-pc686-2021-11-20/share/qemu/edk2-i386-secure-code.fd
./6-tools-pc686-2021-11-20/share/qemu/edk2-licenses.txt
./6-tools-pc686-2021-11-20/share/qemu/edk2-x86_64-code.fd
./6-tools-pc686-2021-11-20/share/qemu/edk2-x86_64-secure-code.fd

Karel



On Tue, Mar 7, 2023, 11:39 AM Karel Gardas  wrote:

On 3/7/23 19:24, Karel Gardas wrote:
 > On 3/7/23 15:05, Siddharth Khattar wrote:
 >> Hello all,
 >> So I was aiming to make a project to improve the amd64 BSP for
RTEMS
 >> (modify it according to ACPI standards along with other stuff) but
 >> first I would need to build it. Unfortunately there was no way to
 >> build it natively within RTEMS source. So, I needed to install QEMU
 >> and had to build the UEFI firmware,OVMF by Tianocore in order to
build
 >> it.
 >
 > Indeed, they still list Ubutnu 16.04 LTS as a build OS. Hmm, I
would go
 > with VM for this. You need to build it just once...

Investigating more, it looks like qemu build those too, so there is no
need to deal with TianoCore alone anymore. My 7.2.0 install contains:

$ find qemu-7.2.0/share/qemu/ -name 'edk2*'
qemu-7.2.0/share/qemu/edk2-arm-code.fd
qemu-7.2.0/share/qemu/edk2-x86_64-code.fd
qemu-7.2.0/share/qemu/edk2-arm-vars.fd
qemu-7.2.0/share/qemu/edk2-i386-secure-code.fd
qemu-7.2.0/share/qemu/edk2-x86_64-secure-code.fd
qemu-7.2.0/share/qemu/edk2-aarch64-code.fd
qemu-7.2.0/share/qemu/edk2-i386-code.fd
qemu-7.2.0/share/qemu/edk2-i386-vars.fd
qemu-7.2.0/share/qemu/edk2-licenses.txt

Ditto for Qemu build by RSB. Will send you tarball of scripts I'm using
for building and running rtems.exe on those...



Karel
___
devel mailing list
devel@rtems.org <mailto:devel@rtems.org>
http://lists.rtems.org/mailman/listinfo/devel
<http://lists.rtems.org/mailman/listinfo/devel>



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

Re: Help regarding Building x86_64 BSP

2023-03-12 Thread Karel Gardas

On 3/8/23 11:08, Frank Kühndel wrote:

Hello,

On 3/8/23 01:42, Joel Sherrill wrote:

Subject:
Re: Help regarding Building x86_64 BSP
From:
Joel Sherrill 
Date:
3/8/23, 01:42

To:
Karel Gardas 
CC:
"rtems-de...@rtems.org" 

Did you build the x86_64 tools and qemu using the RTEMS Source Builder?

The only information I can contribute to this discussion are the results 
our Continuous Integration Server currently creates when building x86_64 
tools with the RTEMS Source Builder:

almalinux 8.7: OK   [gcc (GCC) 8.5.0]
debian 11: OK   [gcc (Debian 10.2.1-6) 10.2.1]
fedora 37: Failure  [gcc (GCC) 12.2.1]
opensuse-leap 15.4: Failure [gcc (SUSE Linux) 12.2.1]
ubuntu 22.04: Failure   [gcc (Ubuntu 12.1.0-2ubuntu1~22.04) 12.1.0]

These builds were for RTEMS 6 and RSB 

Just a remark to table above. Ubuntu 22.04 LTS default GCC is 11.x and 
it's perfectly able to build x86_64 tools (tested by me).

On RHEL8, default gcc is 8.5.x and it should be ok.
On RHEL9, default gcc is 11.3.x and it should also be able to build 
tools fine.

The only issue on RHELx is that makeinfo is missing so you either need 
to install from different repo or by hand.

SLES testing in whatever form is out of my reach.

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

[PATCH] grub2.cfg: fix GRUB compilation with GCC 12.

2023-03-19 Thread Karel Gardas

---
 source-builder/config/grub2.cfg | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/source-builder/config/grub2.cfg b/source-builder/config/grub2.cfg
index 2333d6a..174b846 100644
--- a/source-builder/config/grub2.cfg
+++ b/source-builder/config/grub2.cfg
@@ -56,7 +56,8 @@ URL: https://www.gnu.org/software/grub/index.html
 --mandir=%{_mandir} --infodir=%{_infodir} \
 --with-platform=%{grub2_platform} \
 --target=%{grub2_target} \
---disable-libzfs   # broken on FreeBSD and not needed at all
+--disable-libzfs \ # broken on FreeBSD and not needed at all
+--disable-werror   # fixes compilation by GCC 12
 
   %{__make} %{?_smp_mflags} all
 
-- 
2.25.1

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

Re: Help regarding Building x86_64 BSP

2023-03-19 Thread Karel Gardas


On 3/8/23 11:08, Frank Kühndel wrote:
The build failures all happen when `building: 
grub2-2.06-x86_64-linux-gnu-1` which is the last build step. There are 
several similar errors. These are two of them taken from the build log:


cc1: all warnings being treated as errors
util/mkimage.c: In function ‘grub_install_generate_image’:
util/mkimage.c:1386:41: error: dangling pointer to ‘tmp_’ may be used 
[-Werror=d

angling-pointer=]
  1386 | PE_OHDR (o32, o64, header_size) = grub_host_to_target32 
(header_

size);
util/mkimage.c:857:28: note: ‘tmp_’ declared here
   857 |   __typeof__((o64)->field) tmp_;    \
   |    ^~~~
util/mkimage.c:1386:9: note: in expansion of macro ‘PE_OHDR’
  1386 | PE_OHDR (o32, o64, header_size) = grub_host_to_target32 
(header_

size);
   | ^~~
util/mkimage.c:1387:40: error: dangling pointer to ‘tmp_’ may be used 
[-Werror=d

angling-pointer=]
  1387 | PE_OHDR (o32, o64, entry_addr) = grub_host_to_target32 
(layout.s

tart_address);
util/mkimage.c:857:28: note: ‘tmp_’ declared here
   857 |   __typeof__((o64)->field) tmp_;    \
   |    ^~~~
util/mkimage.c:1387:9: note: in expansion of macro ‘PE_OHDR’
  1387 | PE_OHDR (o32, o64, entry_addr) = grub_host_to_target32 
(layout.s

tart_address);
   | ^~~

Maybe one needs a new version of grub sources for gcc 12?


GRUB 2.06 is the last available release. The release cadence is 2 years 
and next version should be released around this summer. I would not like 
to go to git version in the meantime, but rather stick to released version.


Possible and working (tested on Fedora 37 and Ubuntu 20.04) workaround 
is to use --disable-werror as all the related errors are just warnings.


The patch already sent, testing and reporting from your side would be 
highly appreciated.


Thanks,
Karel

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

Re: Problem when in booting amd64 BSP

2023-03-12 Thread Karel Gardas




Read https://www.mail-archive.com/devel@rtems.org/msg28484.html

Also, if you modify /boot/kernel/kernel on FBSD you can't really expect 
it to boot back for you magically. You have basically sent FBSD kernel 
to void...:-)


On 3/12/23 15:11, Siddharth Khattar wrote:
Hello all, So recently I was trying to run the amd64 BSP of RTEMS in 
order to be able to test on it for my GSoC 2023 project and was 
following the guide on RTEMS User Manual 9.18, it took me a few days to 
follow all the steps on it but after finally putting the hello.exe file 
(built for x86_64 & amd64) and copying it into /boot/kernel/kernel of 
the FreeBSD 11.2 virtual system, it crashed and now doesn't boot up at 
all. I tried doing the same even on a FreeBSD 13 virtual machine but it 
had the same problem and didn't end up booting for me. I also 
double-checked everything to make sure I wasn't making a silly mistake 
or having a small problem. The attached screenshot is from trying to 
boot it on the FreeBSD 13 virtual machine. If somebody has some idea why 
this error is occurring, I would really appreciate their help!


___
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] score/arm: improve printed exception information for Cortex-Mx CPUs

2023-03-15 Thread Karel Gardas

Sponsored-By:   Precidata
---
 .../score/cpu/arm/arm-exception-frame-print.c | 101 ++
 .../cpu/arm/include/rtems/score/armv7m.h  |  11 ++
 2 files changed, 112 insertions(+)

diff --git a/cpukit/score/cpu/arm/arm-exception-frame-print.c 
b/cpukit/score/cpu/arm/arm-exception-frame-print.c
index 4bb1efedec..6a773d9e2d 100644
--- a/cpukit/score/cpu/arm/arm-exception-frame-print.c
+++ b/cpukit/score/cpu/arm/arm-exception-frame-print.c
@@ -32,6 +32,9 @@
 #include 
 
 #include 
+#if defined(ARM_MULTILIB_ARCH_V7M)
+#include 
+#endif
 #include 
 
 static void _ARM_VFP_context_print( const ARM_VFP_context *vfp_context )
@@ -57,6 +60,103 @@ static void _ARM_VFP_context_print( const ARM_VFP_context 
*vfp_context )
 #endif
 }
 
+static void _ARM_Cortex_M_fault_info_print(void)
+{
+#if defined(ARM_MULTILIB_ARCH_V7M)
+/* prints content of additional debugging registers
+ * available on Cortex-Mx where x > 0 cores.
+ */
+uint32_t cfsr = _ARMV7M_SCB->cfsr;
+uint8_t mmfsr = ARMV7M_SCB_CFSR_MMFSR_GET(cfsr);
+uint8_t bfsr = (ARMV7M_SCB_CFSR_BFSR_GET(cfsr) >> 8);
+uint16_t ufsr = (ARMV7M_SCB_CFSR_UFSR_GET(cfsr) >> 16);
+uint32_t hfsr = _ARMV7M_SCB->hfsr;
+if (mmfsr > 0) {
+printk("MMFSR= 0x%08" PRIx32 " (memory fault)\n", mmfsr);
+if ((mmfsr & 0x1) != 0) {
+printk("  IACCVIOL   : 1  (instruction access violation)\n");
+}
+if ((mmfsr & 0x2) != 0) {
+printk("  DACCVIOL   : 1  (data access violation)\n");
+}
+if ((mmfsr & 0x8) != 0) {
+printk("  MUNSTKERR  : 1  (fault on unstacking on exception 
return)\n");
+}
+if ((mmfsr & 0x10) != 0) {
+printk("  MSTKERR: 1  (fault on stacking on exception 
entry)\n");
+}
+if ((mmfsr & 0x20) != 0) {
+printk("  MLSPERR: 1  (fault during lazy FP stack 
preservation)\n");
+}
+if ((mmfsr & 0x80) != 0) {
+printk("  MMFARVALID : 1 -> 0x%08" PRIx32 " (error address)\n", 
_ARMV7M_SCB->mmfar);
+}
+else {
+printk("  MMFARVALID : 0  (undetermined error address)\n");
+}
+}
+if (bfsr > 0) {
+printk("BFSR = 0x%08" PRIx32 " (bus fault)\n", bfsr);
+if ((bfsr & 0x1) != 0) {
+printk("  IBUSERR: 1  (instruction fetch error)\n");
+}
+if ((bfsr & 0x2) != 0) {
+printk("  PRECISERR  : 1  (data bus error with known exact 
location)\n");
+}
+if ((bfsr & 0x4) != 0) {
+printk("  IMPRECISERR: 1  (data bus error without known exact 
location)\n");
+}
+if ((bfsr & 0x8) != 0) {
+printk("  UNSTKERR   : 1  (fault on unstacking on exception 
return)\n");
+}
+if ((bfsr & 0x10) != 0) {
+printk("  STKERR : 1  (fault on stacking on exception 
entry)\n");
+}
+if ((bfsr & 0x20) != 0) {
+printk("  LSPERR : 1  (fault during lazy FP stack 
preservation)\n");
+}
+if ((bfsr & 0x80) != 0) {
+printk("  BFARVALID  : 1 -> 0x%08" PRIx32 "  (error address)\n", 
_ARMV7M_SCB->bfar);
+}
+else {
+printk("  BFARVALID  : 0  (undetermined error address)\n");
+}
+}
+if (ufsr > 0) {
+printk("UFSR = 0x%08" PRIx32 " (usage fault)\n", ufsr);
+if ((ufsr & 0x1) != 0) {
+printk("  UNDEFINSTR : 1  (undefined instruction issued)\n");
+}
+if ((ufsr & 0x2) != 0) {
+printk("  INVSTATE   : 1  (invalid instruction state (Thumb not 
set in EPSR or invalid IT state in EPSR))\n");
+}
+if ((ufsr & 0x4) != 0) {
+printk("  INVPC  : 1  (integrity check failure on 
EXC_RETURN)\n");
+}
+if ((ufsr & 0x8) != 0) {
+printk("  NOCP   : 1  (coprocessor instruction issued but 
coprocessor disabled or non existent)\n");
+}
+if ((ufsr & 0x100) != 0) {
+printk("  UNALIGNED  : 1  (unaligned access operation 
occurred)\n");
+}
+if ((ufsr & 0x200) != 0) {
+printk("  DIVBYZERO  : 1  (division by zero)");
+}
+}
+if ((hfsr & (ARMV7M_SCB_HFSR_VECTTBL_MASK | ARMV7M_SCB_HFSR_DEBUGEVT_MASK 
| ARMV7M_SCB_HFSR_FORCED_MASK)) != 0) {
+printk("HFSR = 0x%08" PRIx32 " (hard fault)\n", hfsr);
+if ((hfsr & ARMV7M_SCB_HFSR_VECTTBL_MASK) != 0) {
+printk("  VECTTBL: 1  (error in address located in vector 
table)\n");
+}
+if ((hfsr & ARMV7M_SCB_HFSR_FORCED_MASK) != 0) {
+printk("  FORCED : 1  (configurable fault escalated to hard 
fault)\n");
+}
+if ((hfsr & ARMV7M_SCB_HFSR_DEBUGEVT_MASK) != 0) {
+printk("  DEBUGEVT   : 1  (debug event occurred with debug system 
disabled)\n");
+}
+}
+#endif
+}
 void _CPU_Exception_frame_print( const CPU_Exception_frame *frame )
 {
   printk(
@@ -100,4 +200,5 @@

[PATCH] bsps/stm32h7: add comments explaining MPU setup

2023-03-15 Thread Karel Gardas

---
 bsps/arm/stm32h7/start/mpu-config.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/bsps/arm/stm32h7/start/mpu-config.c 
b/bsps/arm/stm32h7/start/mpu-config.c
index ce3c92ccb0..a3ebc065ec 100644
--- a/bsps/arm/stm32h7/start/mpu-config.c
+++ b/bsps/arm/stm32h7/start/mpu-config.c
@@ -31,6 +31,10 @@
 
 const ARMV7M_MPU_Region_config stm32h7_config_mpu_region [] = {
 {
+ /*| memory  | shareability  | privileged | unprivileged | executability |
+   |  type   |   |   perms|perms |   |
+   +-+---++--+---+ 
*/
+ /*  normal  | not shareable | RW | RW   | NO */
   .begin = stm32h7_memory_sram_axi_begin,
   .end = stm32h7_memory_sram_axi_end,
   .rasr = ARMV7M_MPU_RASR_XN
@@ -38,6 +42,7 @@ const ARMV7M_MPU_Region_config stm32h7_config_mpu_region [] = 
{
 | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
 | ARMV7M_MPU_RASR_ENABLE,
 }, {
+ /* normal  | not shareable | RW  | RW   | NO */
   .begin = stm32h7_memory_sdram_1_begin,
   .end = stm32h7_memory_sdram_1_end,
   .rasr = ARMV7M_MPU_RASR_XN
@@ -45,6 +50,7 @@ const ARMV7M_MPU_Region_config stm32h7_config_mpu_region [] = 
{
 | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
 | ARMV7M_MPU_RASR_ENABLE,
 }, {
+ /* normal  | not shareable | RW  | RW   | NO */
   .begin = stm32h7_memory_sdram_2_begin,
   .end = stm32h7_memory_sdram_2_end,
   .rasr = ARMV7M_MPU_RASR_XN
@@ -52,12 +58,14 @@ const ARMV7M_MPU_Region_config stm32h7_config_mpu_region [] 
= {
 | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
 | ARMV7M_MPU_RASR_ENABLE,
 }, {
+ /* normal  | not shareable | RO | no access| YES */
   .begin = bsp_section_start_begin,
   .end = bsp_section_text_end,
   .rasr = ARMV7M_MPU_RASR_AP(0x5)
 | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
 | ARMV7M_MPU_RASR_ENABLE,
 }, {
+ /* normal  | not shareable | RO | no access| NO */
   .begin = bsp_section_rodata_begin,
   .end = bsp_section_rodata_end,
   .rasr = ARMV7M_MPU_RASR_XN
@@ -65,6 +73,7 @@ const ARMV7M_MPU_Region_config stm32h7_config_mpu_region [] = 
{
 | ARMV7M_MPU_RASR_TEX(0x1) | ARMV7M_MPU_RASR_C | ARMV7M_MPU_RASR_B
 | ARMV7M_MPU_RASR_ENABLE,
 }, {
+ /* device  | not shareable | RW | RW   | NO */
   .begin = bsp_section_nocache_begin,
   .end = bsp_section_nocachenoload_end,
   .rasr = ARMV7M_MPU_RASR_XN
@@ -72,6 +81,7 @@ const ARMV7M_MPU_Region_config stm32h7_config_mpu_region [] = 
{
 | ARMV7M_MPU_RASR_TEX(0x2)
 | ARMV7M_MPU_RASR_ENABLE,
 }, {
+ /* n/a | n/a   | n/a| n/a  | NO */
   .begin = stm32h7_memory_null_begin,
   .end = stm32h7_memory_null_end,
   .rasr = ARMV7M_MPU_RASR_XN | ARMV7M_MPU_RASR_ENABLE,
-- 
2.25.1

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

Re: RISC-V link warning :base_sp.exe has a LOAD segment with RWX permissions

2023-03-14 Thread Karel Gardas




Probably a new binutils made by:

commit c58857dfdd8830871236261a3ef8399eff3b9b68
Author: Joel Sherrill 
Date:   Tue Feb 21 09:24:37 2023 -0600

Update to binutils 2.40 for rtems 6


Karel

On 3/14/23 15:45, Alan Cudmore wrote:

Hi,
I noticed that my RISC-V builds with the RTEMS master and RSB master now 
have this warning on each link:

[3405/4331] Linking build/riscv/rv64imafdc/testsuites/samples/minimum.exe
/home/alan/rtems/tools/6/lib/gcc/riscv-rtems6/12.2.1/../../../../riscv-rtems6/bin/ld:
 warning: 
/home/alan/rtems/rtems/build/riscv/rv64imafdc/testsuites/samples/base_sp.exe 
has a LOAD segment with RWX permissions

I was trying to back up commits in the RTEMS and RSB repositories to see 
when it started, but I have not figured it out yet.


My host is Ubuntu 20.04.1 LTS x86_64.

Thanks,
Alan

___
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] score/arm: make MPU setup more generic

2023-03-16 Thread Karel Gardas

This patch makes MPU setup more generic by adding capability to set
also control register. This way BSPs are allowed to enable MPU
also for hard faults by simply not setting PRIVDEFENA attribute
to control register. Compatibility with previous behavior and API
is preserved.

Sponsored-By:   Precidata
---
 cpukit/score/cpu/arm/include/rtems/score/armv7m.h | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h 
b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
index 744dca26d3..cfd676cce7 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
@@ -701,7 +701,8 @@ static inline void _ARMV7M_MPU_Disable_region(
   mpu->rasr = 0;
 }
 
-static inline void _ARMV7M_MPU_Setup(
+static inline void _ARMV7M_MPU_Setup_with_ctrl(
+  uint32_t ctrl,
   const ARMV7M_MPU_Region_config *cfg,
   size_t cfg_count
 )
@@ -737,13 +738,21 @@ static inline void _ARMV7M_MPU_Setup(
 _ARMV7M_MPU_Disable_region(mpu, region);
   }
 
-  mpu->ctrl = ARMV7M_MPU_CTRL_ENABLE | ARMV7M_MPU_CTRL_PRIVDEFENA;
+  mpu->ctrl = ctrl;
   scb->shcsr |= ARMV7M_SCB_SHCSR_MEMFAULTENA;
 
   _ARM_Data_synchronization_barrier();
   _ARM_Instruction_synchronization_barrier();
 }
 
+static inline void _ARMV7M_MPU_Setup(
+  const ARMV7M_MPU_Region_config *cfg,
+  size_t cfg_count
+)
+{
+  _ARMV7M_MPU_Setup_with_ctrl(ARMV7M_MPU_CTRL_ENABLE | 
ARMV7M_MPU_CTRL_PRIVDEFENA, cfg, cfg_count);
+}
+
 #endif /* ASM */
 
 #endif /* ARM_MULTILIB_ARCH_V7M */
-- 
2.25.1

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

[PATCH 2/2] score/arm: enhance ARMV7M MPU setup with capability to set control register

2023-03-16 Thread Karel Gardas

Due to API change, the patch also fixes affected BSPs and uses
value provided by MPU CTRL spec option there.

Sponsored-By:   Precidata
---
 bsps/arm/imxrt/start/bspstarthooks.c   | 2 +-
 .../stm32h7/boards/stm/nucleo-h743zi/stm32h7-bspstarthooks.c   | 2 +-
 .../stm32h7/boards/stm/stm32h743i-eval/stm32h7-bspstarthooks.c | 2 +-
 .../boards/stm/stm32h747i-disco/stm32h7-bspstarthooks.c| 2 +-
 .../stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c | 2 +-
 .../stm32h7/boards/stm/stm32h7b3i-dk/stm32h7-bspstarthooks.c   | 2 +-
 cpukit/score/cpu/arm/include/rtems/score/armv7m.h  | 3 ++-
 7 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/bsps/arm/imxrt/start/bspstarthooks.c 
b/bsps/arm/imxrt/start/bspstarthooks.c
index 684c263152..482300a1bc 100644
--- a/bsps/arm/imxrt/start/bspstarthooks.c
+++ b/bsps/arm/imxrt/start/bspstarthooks.c
@@ -46,7 +46,7 @@ BSP_START_TEXT_SECTION void bsp_start_hook_0(void)
 SCB_EnableDCache();
   }
 
-  _ARMV7M_MPU_Setup(imxrt_config_mpu_region, imxrt_config_mpu_region_count);
+  _ARMV7M_MPU_Setup(ARMV7M_MPU_CTRL_DEFAULT, imxrt_config_mpu_region, 
imxrt_config_mpu_region_count);
 }
 
 BSP_START_TEXT_SECTION void bsp_start_hook_1(void)
diff --git a/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/stm32h7-bspstarthooks.c 
b/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/stm32h7-bspstarthooks.c
index eda503925f..636a124d64 100644
--- a/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/stm32h7-bspstarthooks.c
+++ b/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/stm32h7-bspstarthooks.c
@@ -62,7 +62,7 @@ void bsp_start_hook_0(void)
 SCB_EnableDCache();
   }
 
-  _ARMV7M_MPU_Setup(stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
+  _ARMV7M_MPU_Setup(ARMV7M_MPU_CTRL_DEFAULT, stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
 #endif
 }
 
diff --git 
a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-bspstarthooks.c 
b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-bspstarthooks.c
index 8d34e357ee..0a25253215 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-bspstarthooks.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/stm32h7-bspstarthooks.c
@@ -63,7 +63,7 @@ void bsp_start_hook_0(void)
 SCB_EnableDCache();
   }
 
-  _ARMV7M_MPU_Setup(stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
+  _ARMV7M_MPU_Setup(ARMV7M_MPU_CTRL_DEFAULT, stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
 #endif
 }
 
diff --git 
a/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-bspstarthooks.c 
b/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-bspstarthooks.c
index 8d34e357ee..0a25253215 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-bspstarthooks.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/stm32h7-bspstarthooks.c
@@ -63,7 +63,7 @@ void bsp_start_hook_0(void)
 SCB_EnableDCache();
   }
 
-  _ARMV7M_MPU_Setup(stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
+  _ARMV7M_MPU_Setup(ARMV7M_MPU_CTRL_DEFAULT, stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
 #endif
 }
 
diff --git 
a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c 
b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
index 1bb81e3b60..1fa8563477 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/stm32h7-bspstarthooks.c
@@ -79,7 +79,7 @@ void bsp_start_hook_0(void)
 SCB_EnableDCache();
   }
 
-  _ARMV7M_MPU_Setup(stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
+  _ARMV7M_MPU_Setup(ARMV7M_MPU_CTRL_DEFAULT, stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
 #endif
 }
 
diff --git a/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/stm32h7-bspstarthooks.c 
b/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/stm32h7-bspstarthooks.c
index 8d34e357ee..0a25253215 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/stm32h7-bspstarthooks.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/stm32h7-bspstarthooks.c
@@ -63,7 +63,7 @@ void bsp_start_hook_0(void)
 SCB_EnableDCache();
   }
 
-  _ARMV7M_MPU_Setup(stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
+  _ARMV7M_MPU_Setup(ARMV7M_MPU_CTRL_DEFAULT, stm32h7_config_mpu_region, 
stm32h7_config_mpu_region_count);
 #endif
 }
 
diff --git a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h 
b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
index 10b3955671..2b1e785cf7 100644
--- a/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
+++ b/cpukit/score/cpu/arm/include/rtems/score/armv7m.h
@@ -691,6 +691,7 @@ static inline void _ARMV7M_MPU_Disable_region(
 }
 
 static inline void _ARMV7M_MPU_Setup(
+  uint32_t ctrl,
   const ARMV7M_MPU_Region_config *cfg,
   size_t cfg_count
 )
@@ -726,7 +727,7 @@ static inline void _ARMV7M_MPU_Setup(
 _ARMV7M_MPU_Disable_region(mpu, region);
   }
 
-  mpu->ctrl = ARMV7M_MPU_CTRL_ENABLE | ARMV7M_MPU_CTRL_PRIVDEFENA;
+  mpu->ctrl = ctrl;
   scb->shcsr |=

[PATCH 1/2] spec: add MPU CTRL option to be usable on ARMV7M based BSPs

2023-03-16 Thread Karel Gardas

The patch also enables usage of the option on imxrt and stm32h7 based BSPs.

Sponsored-By:   Precidata
---
 spec/build/bsps/arm/imxrt/bspimxrt.yml |  2 ++
 spec/build/bsps/arm/optmpuctrl.yml | 25 +
 spec/build/bsps/arm/stm32h7/grp.yml|  2 ++
 3 files changed, 29 insertions(+)
 create mode 100644 spec/build/bsps/arm/optmpuctrl.yml

diff --git a/spec/build/bsps/arm/imxrt/bspimxrt.yml 
b/spec/build/bsps/arm/imxrt/bspimxrt.yml
index b666be5241..e05ceeccd9 100644
--- a/spec/build/bsps/arm/imxrt/bspimxrt.yml
+++ b/spec/build/bsps/arm/imxrt/bspimxrt.yml
@@ -165,6 +165,8 @@ links:
   uid: linkcmdsmemory
 - role: build-dependency
   uid: ../../bspopts
+- role: build-dependency
+  uid: ../optmpuctrl
 source:
 - bsps/arm/imxrt/console/console.c
 - bsps/arm/imxrt/dts/imxrt1050-evkb.c
diff --git a/spec/build/bsps/arm/optmpuctrl.yml 
b/spec/build/bsps/arm/optmpuctrl.yml
new file mode 100644
index 00..96f68968a6
--- /dev/null
+++ b/spec/build/bsps/arm/optmpuctrl.yml
@@ -0,0 +1,25 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-string: null
+- define-unquoted: null
+build-type: option
+copyrights:
+- Copyright (C) 2023 Karel Gardas
+description: |
+  Default value of the ARM MPU CTRL register
+default:
+- enabled-by:
+  - arm/imxrt1052
+  - arm/stm32h7
+  - arm/nucleo-h743zi
+  - arm/stm32h7b3i-dk
+  - arm/stm32h747i-disco
+  - arm/stm32h757i-eval
+  value: (ARMV7M_MPU_CTRL_ENABLE | ARMV7M_MPU_CTRL_PRIVDEFENA)
+- enabled-by: true
+  value: ARMV7M_MPU_CTRL_ENABLE
+enabled-by: true
+format: '{}'
+links: []
+name: ARMV7M_MPU_CTRL_DEFAULT
+type: build
diff --git a/spec/build/bsps/arm/stm32h7/grp.yml 
b/spec/build/bsps/arm/stm32h7/grp.yml
index 9735b6734c..c415a7a71d 100644
--- a/spec/build/bsps/arm/stm32h7/grp.yml
+++ b/spec/build/bsps/arm/stm32h7/grp.yml
@@ -24,6 +24,8 @@ links:
   uid: ../../objmem
 - role: build-dependency
   uid: optenmpualign
+- role: build-dependency
+  uid: ../optmpuctrl
 - role: build-dependency
   uid: optenuart4
 - role: build-dependency
-- 
2.25.1

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

Re: Help regarding Building x86_64 BSP

2023-03-07 Thread Karel Gardas


On 3/7/23 19:24, Karel Gardas wrote:

On 3/7/23 15:05, Siddharth Khattar wrote:

Hello all,
So I was aiming to make a project to improve the amd64 BSP for RTEMS 
(modify it according to ACPI standards along with other stuff) but 
first I would need to build it. Unfortunately there was no way to 
build it natively within RTEMS source. So, I needed to install QEMU 
and had to build the UEFI firmware,OVMF by Tianocore in order to build 
it. 


Indeed, they still list Ubutnu 16.04 LTS as a build OS. Hmm, I would go 
with VM for this. You need to build it just once...


Investigating more, it looks like qemu build those too, so there is no 
need to deal with TianoCore alone anymore. My 7.2.0 install contains:


$ find qemu-7.2.0/share/qemu/ -name 'edk2*'
qemu-7.2.0/share/qemu/edk2-arm-code.fd
qemu-7.2.0/share/qemu/edk2-x86_64-code.fd
qemu-7.2.0/share/qemu/edk2-arm-vars.fd
qemu-7.2.0/share/qemu/edk2-i386-secure-code.fd
qemu-7.2.0/share/qemu/edk2-x86_64-secure-code.fd
qemu-7.2.0/share/qemu/edk2-aarch64-code.fd
qemu-7.2.0/share/qemu/edk2-i386-code.fd
qemu-7.2.0/share/qemu/edk2-i386-vars.fd
qemu-7.2.0/share/qemu/edk2-licenses.txt

Ditto for Qemu build by RSB. Will send you tarball of scripts I'm using 
for building and running rtems.exe on those...


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

Re: Help regarding Building x86_64 BSP

2023-03-07 Thread Karel Gardas


On 3/7/23 15:05, Siddharth Khattar wrote:

Hello all,
So I was aiming to make a project to improve the amd64 BSP for RTEMS 
(modify it according to ACPI standards along with other stuff) but first 
I would need to build it. Unfortunately there was no way to build it 
natively within RTEMS source. So, I needed to install QEMU and had to 
build the UEFI firmware,OVMF by Tianocore in order to build it. 


Indeed, they still list Ubutnu 16.04 LTS as a build OS. Hmm, I would go 
with VM for this. You need to build it just once...


Karel

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

[PATCH] tester/bsps: change stm32h7-stlink to handle SIGTRAP as a nostop

2023-03-24 Thread Karel Gardas

The ST-Link GDB server throws spurious SIGTRAP into the GDB sometimes.
When this happen, the gdb exits immediately as it's run in batch/script
manner. Unfortunately this may be while testcase itself is still running
and does not have enough time to print all the required output.
Such testcase is then marked as failed although otherwise it may run
well to its end.
Adding handle of SIGTRAP as a nostop means that GDB will not exit
after receiving SIGTRAP but rather be forced to continue as nothing
would happen and the running testcase will have a chance to finish
its business.
---
 tester/rtems/testing/bsps/stm32h7-stlink.ini | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tester/rtems/testing/bsps/stm32h7-stlink.ini 
b/tester/rtems/testing/bsps/stm32h7-stlink.ini
index bf57bee..2c375f5 100644
--- a/tester/rtems/testing/bsps/stm32h7-stlink.ini
+++ b/tester/rtems/testing/bsps/stm32h7-stlink.ini
@@ -40,4 +40,5 @@ gdb_script = bsp_gdb_script
 requires   = bsp_tty_dev, bsp_gdb_script, target_pretest_command, 
target_posttest_command
 bsp_gdb_script = target extended-remote :61234
  load
+ handle SIGTRAP nostop
  cont
-- 
2.25.1

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

Re: [PATCH] score/arm: make MPU setup more generic

2023-03-16 Thread Karel Gardas


On 3/16/23 10:19, Sebastian Huber wrote:

On 16.03.23 10:14, Karel Gardas wrote:

This patch makes MPU setup more generic by adding capability to set
also control register. This way BSPs are allowed to enable MPU
also for hard faults by simply not setting PRIVDEFENA attribute
to control register. Compatibility with previous behavior and API
is preserved.


Is this really a BSP-specific choice or more a user option which should 
be controlled by a BSP option (through config.ini)?


config.ini would be even more generic and probably more elegant too. 
However for upstreaming I took a more conservative approach to have a 
chance.


Let me ask what do you prefer and what will you support? I'm happy to 
write that as long as it is reasonable simple and makes chance to 
upstream higher.


My goal is simple:
I'm working on BSP for Precidata SL-3011 board. The board is using 
STM32H747. Board firmware responsible for hardware management runs on 
CM4 while RTEMS and app code will run on CM7 and will be using firmware 
services by calling some API. For communication between both domains we 
use SRAM4. To be able to print hard fault from RTEMS on CM7 I need either:


- keep cache disabled for SRAM4 region even for hard fault (hence MPU 
change proposed)


or

- disable cache in print exception frame directly which involves quite a 
bit of hacking around and looks to be more source code invasive than MPU 
change.


Thanks!
Karel


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

Re: [PATCH 1/2] spec: add MPU CTRL option to be usable on ARMV7M based BSPs

2023-03-16 Thread Karel Gardas


On 3/16/23 14:34, Sebastian Huber wrote:

On 16.03.23 14:28, Karel Gardas wrote:

+description: |
+  Default value of the ARM MPU CTRL register
+default:
+- enabled-by:
+  - arm/imxrt1052
+  - arm/stm32h7
+  - arm/nucleo-h743zi
+  - arm/stm32h7b3i-dk
+  - arm/stm32h747i-disco
+  - arm/stm32h757i-eval
+  value: (ARMV7M_MPU_CTRL_ENABLE | ARMV7M_MPU_CTRL_PRIVDEFENA)
+- enabled-by: true
+  value: ARMV7M_MPU_CTRL_ENABLE


The patch set looks good, but please make the current value 
(ARMV7M_MPU_CTRL_ENABLE | ARMV7M_MPU_CTRL_PRIVDEFENA) the default value.


Done. I also fixed imxrt by moving mpu opt before bspopts in order to 
get define generated into the bspopts.h.


Thanks for the review and suggestion on this!
Karel

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

[PATCH] bsps/stm32h7: fix propagation of configured HSE freq. value into the code

2023-03-09 Thread Karel Gardas

Sponsored-By:   Precidata
---
 .../arm/stm32h7/boards/stm/nucleo-h743zi/system_stm32h7xx.c | 4 
 .../stm32h7/boards/stm/stm32h743i-eval/system_stm32h7xx.c   | 4 
 .../stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c  | 6 ++
 .../stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c   | 4 
 .../arm/stm32h7/boards/stm/stm32h7b3i-dk/system_stm32h7xx.c | 4 
 5 files changed, 22 insertions(+)

diff --git a/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/system_stm32h7xx.c 
b/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/system_stm32h7xx.c
index a8a9ff0b4b..2d53f114c1 100644
--- a/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/system_stm32h7xx.c
+++ b/bsps/arm/stm32h7/boards/stm/nucleo-h743zi/system_stm32h7xx.c
@@ -49,6 +49,10 @@
 #include 
 #ifdef __rtems__
 #include 
+#include 
+
+#define HSE_VALUE STM32H7_HSE_FREQUENCY
+
 #endif /* __rtems__ */
 #if !defined  (HSE_VALUE)
 #define HSE_VALUE((uint32_t)2500) /*!< Value of the External 
oscillator in Hz */
diff --git a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/system_stm32h7xx.c 
b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/system_stm32h7xx.c
index a8a9ff0b4b..2d53f114c1 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/system_stm32h7xx.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h743i-eval/system_stm32h7xx.c
@@ -49,6 +49,10 @@
 #include 
 #ifdef __rtems__
 #include 
+#include 
+
+#define HSE_VALUE STM32H7_HSE_FREQUENCY
+
 #endif /* __rtems__ */
 #if !defined  (HSE_VALUE)
 #define HSE_VALUE((uint32_t)2500) /*!< Value of the External 
oscillator in Hz */
diff --git a/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c 
b/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c
index 2dc9542597..269288d2c0 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h747i-disco/system_stm32h7xx.c
@@ -91,7 +91,13 @@
 
 #include "stm32h7xx.h"
 #include 
+#ifdef __rtems__
+#include 
+#include 
+
+#define HSE_VALUE STM32H7_HSE_FREQUENCY
 
+#endif /* __rtems__ */
 #if !defined  (HSE_VALUE)
 #define HSE_VALUE((uint32_t)2500) /*!< Value of the External 
oscillator in Hz */
 #endif /* HSE_VALUE */
diff --git a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c 
b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c
index 1260694d8b..59e66e133e 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h757i-eval/system_stm32h7xx.c
@@ -93,6 +93,10 @@
 #include 
 #ifdef __rtems__
 #include 
+#include 
+
+#define HSE_VALUE STM32H7_HSE_FREQUENCY
+
 #endif /* __rtems__ */
 #if !defined  (HSE_VALUE)
 #define HSE_VALUE((uint32_t)2500) /*!< Value of the External 
oscillator in Hz */
diff --git a/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/system_stm32h7xx.c 
b/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/system_stm32h7xx.c
index db11aa19b1..52e8eaafc4 100644
--- a/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/system_stm32h7xx.c
+++ b/bsps/arm/stm32h7/boards/stm/stm32h7b3i-dk/system_stm32h7xx.c
@@ -48,6 +48,10 @@
 #include 
 #ifdef __rtems__
 #include 
+#include 
+
+#define HSE_VALUE STM32H7_HSE_FREQUENCY
+
 #endif /* __rtems__ */
 #if !defined  (HSE_VALUE)
 #define HSE_VALUE((uint32_t)2400) /*!< Value of the External 
oscillator in Hz */
-- 
2.25.1

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

Re: [PATCH 0/1] Fix a typo in the stm32h7 BSP Documentation

2023-03-15 Thread Karel Gardas




Thanks! Applied with a slightly modified commit message.

Karel

On 3/15/23 05:38, Ruturaj Nanoti wrote:

Hi,

I found a small typo while going through the BSP documentation for
stm32h7 and fixed it in this commit.

Thank You

Ruturaj Nanoti (1):
   Fixed a typo in the /user/bsps/arm/stm32h7.rst file.

  user/bsps/arm/stm32h7.rst | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)



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

Re: Jetson Nano BSP

2023-02-23 Thread Karel Gardas

Hi Prakhar,

On 2/23/23 20:23, Prakhar Agrawal wrote:
I completely agree with all your points, but my rationale for
introducing the jetson nano or jetson AGX orin was because of their GPU
power.

it's really nice what Nvidia achieved here, right? Unfortunately this
GPU potential is fully locked up by binary driver NVidia provides only
for selected number of platforms --- if not just for the only one:
Linux. So very questionable how you would unlock that on RTEMS during
the limited time of GSoC. Just see what Nouveau folks are doing:
https://nouveau.freedesktop.org/ -- for years and they just barely got
to 3D acceleration. Just clone their git repo, see number of patches,
lines of code provided and number of people involved and I think you
will get an idea how mamooth task this is...

In the case of large hobby projects or maybe the initial days of a
startup(seed ones), a real-time system that can work with boards having
good GPU can do wonders.
For example, for an autonomous vehicle L2, L3 autonomy can be achieved
using a 60W Jetson AGX orin, hence if RTEMS support is added to the
board, it might help create an awesome system to handle all the critical
time constraints necessary for the vehicle and give it the ability to
coordinate a large number of concurrent activities.

If you are interested in machine vision based on AI and robotics, why
not to look around for more open-source friendly solution? Recently just
found i.MX 8M Plus and their claimed 2.3 TOPS NPU. Certainly not that
powerful like NVidia, but NXP is historically more friendly to 3rd party
OSes. Not sure about NPU, have not had a time to investigate that yet,
but perhaps you do?

Also, with i.MX 8M Plus you still do have a chance to use AI Vision in
non-real time manner running on top of Linux and run RTEMS real-time
tasks on built in Cortex-M7 -- I mean if you decide that this particular
BSP may be your GSoC. :-)

https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-applications-processors/i-mx-8m-plus-arm-cortex-a53-machine-learning-vision-multimedia-and-industrial-iot:IMX8MPLUS

Honestly I'd rather see a new BSP for a decent RISC-V board.

I was reading about RISC-V and their comparison with ARM SBC and in one
blog I read this - "ARM processors have benefited from a lot more
research, funding, and development than RISC-V. This means that it can
be argued that RISC-V is being left behind"

Do not worry about it. RISC-V is here and will stay. A lot was already
invested into it and much more will still be...

Karel

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

Re: Interested for GSoC 2023

2023-02-27 Thread Karel Gardas


On 2/27/23 02:16, Joel Sherrill wrote:
Another GCC related project could be Rust RTEMS Support but I don't know 
what that entails beyond turning it on and seeing what goes wrong. I 
tried to build it last year and got far enough to decide to wait before 
trying again.


Not sure how far you went. The process is generally:

(1) tune Rust compiler to cross-compile correctly for specific 
hardware/os platform. So basically you get no_std capable compiler


(2) review, patch and by using (1) cross-compile libc

(3) using sources from (1) and (2) build full stage (std enabled) rustc.

(4) tweak and tune tools (rustup/cargo etc.) whenever required to smooth 
sharp edges for RTEMS.


Here, I'm nearly finished with (1) for arm-rtems (e.g. cortex-aX not 
cortex-mX).


Karel

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

Rust for RTEMS [was: Re: Interested for GSoC 2023]

2023-02-27 Thread Karel Gardas




adjusting subject based on Jan request. Keeping whole Rust relevant 
comments in.


On 2/27/23 11:07, jan.som...@dlr.de wrote:




-Original Message-
From: devel  On Behalf Of Karel Gardas
Sent: Montag, 27. Februar 2023 09:16
To: j...@rtems.org; Vihas Makwana 
Cc: rtems-de...@rtems.org 
Subject: Re: Interested for GSoC 2023

On 2/27/23 02:16, Joel Sherrill wrote:

Another GCC related project could be Rust RTEMS Support but I don't
know what that entails beyond turning it on and seeing what goes
wrong. I tried to build it last year and got far enough to decide to
wait before trying again.


Not sure how far you went. The process is generally:

(1) tune Rust compiler to cross-compile correctly for specific hardware/os
platform. So basically you get no_std capable compiler

(2) review, patch and by using (1) cross-compile libc

(3) using sources from (1) and (2) build full stage (std enabled) rustc.

(4) tweak and tune tools (rustup/cargo etc.) whenever required to smooth
sharp edges for RTEMS.

Here, I'm nearly finished with (1) for arm-rtems (e.g. cortex-aX not cortex-
mX).



Hi Karel,

Very interesting work. I am currently trying to reach the same goal.
The steps I came up with are a bit different:
A.) Build working llvm toolchain for RTEMS (figure out all flags etc., maybe 
building RTEMS with llvm as a bonus)
B.) Build rustc with the "RTEMS-llvm" as backend


Honestly I'm not so sure (A) and (B) are necessary for rustc port. Or 
perhaps I do not precisely follow what you mean, but IMHO what you need 
is to get ABI and linking with RTEMS binaries right. And this applies 
also to RTEMS being build by GCC toolchain. This is objective of my (1) 
work.



C.) Start with no_std and then inch forward to building the stdlib

I work currently on step A (see my llvm experiments in the other thread) and 
started to look at the build stages for rustc.
If you have any tips for the configuration from your step (1), it would be 
greatly appreciated.
My hope is that with the results of step A I can reuse the libc from the 
standard rtems-gcc build environment as this is provided conveniently via rsb.


Not sure if I did not confused you with my (2) libc remark. I of course 
mean Rust's libc (that means rust code) to be build on top of 
RTEMS/Newlib/libbsd combination. It'll be interesting project especially 
if the requirement later would be to support both binary targets: e.g. 
RTEMS without libbsd (for smaller systems) and RTEMS with libbsd for 
full-blown configuration. Anyway, for now, I would start with libbsd as 
this should make project proceeding faster IMHO.



I am really looking forward to seeing rust supported on RTEMS.


Me too!

Karel

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

Re: [PATCH rtems-libbsd v2 0/2] Update the CGEM driver

2023-03-04 Thread Karel Gardas



One remark as an random observer here.
"branch 6-freebsd-12" has caught my eyes. Let me ask shouldn't 
development patches go into the master branch from which they may be 
later cherry-picked if needed and pushed into 6-freebsd-12 branch?


Just few weeks ago guys were having a discussion how to sync branches 
since they diverged due to patches pushed into both directions without a 
proper syncing...


Thanks,
Karel

On 3/3/23 21:35, Kinsey Moore wrote:

These patches look good to me. Thanks for this contribution!

Kinsey


On Fri, Mar 3, 2023 at 9:54 AM Padmarao Begari 
mailto:padmarao.beg...@microchip.com>> 
wrote:


Update the CGEM driver with adding the phy address and
the clock to read it from the device tree.

The patches are based upon latest rtems-libbsd tree at 6-freebsd-12
(https://git.rtems.org/rtems-libbsd.git
 branch 6-freebsd-12)
at commit id 1aa4cb8568594aa54238c9fbf2cc0f3ea4edec7f

v2:
- Add changes gated behind #ifdef __rtems__
- Use braces {} with if/else for a single line
- Drop weak symbol patch

Padmarao Begari (2):
   freebsd/cgem: Add phy address to read it from device tree
   freebsd/cgem: Read clock frequency from device tree

  freebsd/sys/dev/cadence/if_cgem.c | 72 +--
  1 file changed, 69 insertions(+), 3 deletions(-)

-- 
2.25.1


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



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


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

Re: Rust for RTEMS [was: Re: Interested for GSoC 2023]

2023-03-03 Thread Karel Gardas


On 2/27/23 12:00, Karel Gardas wrote:

On 2/27/23 02:16, Joel Sherrill wrote:

Another GCC related project could be Rust RTEMS Support but I don't
know what that entails beyond turning it on and seeing what goes
wrong. I tried to build it last year and got far enough to decide to
wait before trying again.


Not sure how far you went. The process is generally:

(1) tune Rust compiler to cross-compile correctly for specific 
hardware/os

platform. So basically you get no_std capable compiler

(2) review, patch and by using (1) cross-compile libc

(3) using sources from (1) and (2) build full stage (std enabled) rustc.

(4) tweak and tune tools (rustup/cargo etc.) whenever required to smooth
sharp edges for RTEMS.

Here, I'm nearly finished with (1) for arm-rtems (e.g. cortex-aX not 
cortex-

mX).


Something is running:

silence:/tmp$ cat hello-rtems.rs

#![no_std]
#![no_main]

use core::panic::PanicInfo;
use core::ffi::c_char;
use core::ffi::c_int;

extern "C" {
fn puts(str: *const c_char) -> c_int;
}

#[no_mangle]
pub fn main() -> ! {
unsafe {
puts(b"Rust says hello to hosting RTEMS\n\0".as_ptr() as *const 
i8);

}
loop {}
}

#[panic_handler]
fn panic(_: ) -> ! {
  loop {}
}

silence:/tmp$ /tmp/rustc-rtems-arm/bin/rustc -g -Z verbose 
--target=arm-rtems hello-rtems.rs -lrtemscpu -lrtemsbsp -lrtemsdefaultconfig


silence:/tmp$ file hello-rtems.exe
hello-rtems.exe: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), 
statically linked, with debug_info, not stripped


silence:/tmp$ ~rtems/sfw/qemu-7.2.0/bin/qemu-system-arm -serial null 
-serial mon:stdio -nographic -M xilinx-zynq-a9 -m 512M -kernel 
/tmp/hello-rtems.exe

Rust says hello to hosting RTEMS

QEMU 7.2.0 monitor - type 'help' for more information
(qemu) q
silence:/tmp$


Note: this is hacked rust-lang.org rust compiler, not gccrs project and 
soon to be released GCC 13.


The biggest problem and probably soon to be source of headaches is 
mixture of LLVM's compiler-rt and GCC's libgcc binaries. This means once 
you employ for example arithmetic you need to add
-C link-arg=-Wl,--allow-multiple-definition otherwise you would get 
multiple definitions symbols error.


Karel

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

Re: Rust for RTEMS [was: Re: Interested for GSoC 2023]

2023-02-27 Thread Karel Gardas

On 2/27/23 15:44, Joel Sherrill wrote:

On Mon, Feb 27, 2023 at 5:00 AM Karel Gardas  
wrote:

adjusting subject based on Jan request. Keeping whole Rust relevant
comments in.

On 2/27/23 11:07, jan.som...@dlr.de <mailto:jan.som...@dlr.de> wrote:
 >
 >
 >> -Original Message-
 >> From: devel mailto:devel-boun...@rtems.org>> On Behalf Of Karel Gardas
 >> Sent: Montag, 27. Februar 2023 09:16
 >> To: j...@rtems.org <mailto:j...@rtems.org>; Vihas Makwana
mailto:makvi...@gmail.com>>
 >> Cc: rtems-de...@rtems.org <mailto:rtems-de...@rtems.org>
mailto:devel@rtems.org>>
 >> Subject: Re: Interested for GSoC 2023
 >>
 >> On 2/27/23 02:16, Joel Sherrill wrote:
 >>> Another GCC related project could be Rust RTEMS Support but I don't
 >>> know what that entails beyond turning it on and seeing what goes
 >>> wrong. I tried to build it last year and got far enough to
decide to
 >>> wait before trying again.
 >>
 >> Not sure how far you went. The process is generally:
 >>
 >> (1) tune Rust compiler to cross-compile correctly for specific
hardware/os
 >> platform. So basically you get no_std capable compiler

You should be able to compile gcc rust NOW to target CPU-rtems. I would
expect minor tweaking of configuration both in configure scripting and 
likely

in the Rust run-time libraries. For example, with the Standard C++ Library
there are configuration settings for *-rtems which pick the threading and
synchronization model. Rust's run-time adapter with GCC should be similar.

There is a slight misunderstanding going here. I'm not talking about 
gccrs rust frond-end project which got merged into GCC to become part of 
GCC 13 in autumn last year to be released this spring probably. I'm 
talking and AFAIK Jan too about real Rust as distributed/provided by 
https://www.rust-lang.org/.

The messages from gccrs project are kind of mixed and clearly warns that 
even with GCC 13, the front-end would be good just for GCC rust ongoing 
development and not yet for let say Rust code in Linux kernel. I write 
that not to play that attempt down, in fact gccrs people work is 
outstanding, I write that just to remark that it may take some time 
before it's ready for general "consumption".

Hence, when investigating Rust for RTEMS, I went to rust-lang.org and 
investigated that because after all, this is still reference Rust 
implementation...

Not sure if I did not confused you with my (2) libc remark. I of course
mean Rust's libc (that means rust code) to be build on top of
RTEMS/Newlib/libbsd combination. It'll be interesting project
especially
if the requirement later would be to support both binary targets: e.g.
RTEMS without libbsd (for smaller systems) and RTEMS with libbsd for
full-blown configuration. Anyway, for now, I would start with libbsd as
this should make project proceeding faster IMHO.

You shouldn't need RTEMS or libbsd built until you link real executables
you want to run. All needed POSIX headers are present from newlib.

But I'm at the stage I'd like to link my Rust hello world with RTEMS 
BSP, that's what someone expects at the end anyway. :-)

I was test building rust just like C, C++, and Ada. Build the toolchain and
then build RTEMS.

So you liked rust + RTEMS well? Cool!

Karel

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

[PATCH 2/3] bsps/amd64: increase CPU alignment to 16

2023-04-21 Thread Karel Gardas

AMD64 requires SSE support which operates on 128bit data values.
---
 cpukit/score/cpu/x86_64/include/rtems/score/cpu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cpukit/score/cpu/x86_64/include/rtems/score/cpu.h 
b/cpukit/score/cpu/x86_64/include/rtems/score/cpu.h
index 2671c607a7..b26fb4c8ad 100644
--- a/cpukit/score/cpu/x86_64/include/rtems/score/cpu.h
+++ b/cpukit/score/cpu/x86_64/include/rtems/score/cpu.h
@@ -144,7 +144,7 @@ typedef struct {
 #define CPU_PROVIDES_ISR_IS_IN_PROGRESS FALSE
 #define CPU_STACK_MINIMUM_SIZE  (1024*4)
 #define CPU_SIZEOF_POINTER 8
-#define CPU_ALIGNMENT  8
+#define CPU_ALIGNMENT  16
 #define CPU_HEAP_ALIGNMENT CPU_ALIGNMENT
 #define CPU_STACK_ALIGNMENT16
 #define CPU_INTERRUPT_STACK_ALIGNMENT CPU_CACHE_LINE_BYTES
-- 
2.25.1

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

[PATCH 1/3] bsps/shared: import FreeBSD libefi library

2023-04-21 Thread Karel Gardas

The library is imported in minimalist version just to support future
amd64efi BSP.

The FreeBSD tree commit id with imported libefi version is:
ce7b20e5129cf0f269951b313d336a9c7d54d790
---
 bsps/shared/freebsd/stand/efi/include/README  |   36 +
 .../freebsd/stand/efi/include/amd64/efibind.h |  275 
 bsps/shared/freebsd/stand/efi/include/efi.h   |   87 ++
 .../shared/freebsd/stand/efi/include/efiapi.h | 1204 +
 .../shared/freebsd/stand/efi/include/eficon.h |  527 
 .../freebsd/stand/efi/include/eficonsctl.h|  134 ++
 .../shared/freebsd/stand/efi/include/efidef.h |  224 +++
 .../freebsd/stand/efi/include/efidevp.h   |  511 +++
 .../shared/freebsd/stand/efi/include/efierr.h |   68 +
 .../shared/freebsd/stand/efi/include/efigop.h |  121 ++
 .../shared/freebsd/stand/efi/include/efilib.h |  172 +++
 bsps/shared/freebsd/stand/efi/libefi/libefi.c |   63 +
 bsps/shared/freebsd/stand/efi/libefi/wchar.c  |   73 +
 13 files changed, 3495 insertions(+)
 create mode 100644 bsps/shared/freebsd/stand/efi/include/README
 create mode 100644 bsps/shared/freebsd/stand/efi/include/amd64/efibind.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efi.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efiapi.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/eficon.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/eficonsctl.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efidef.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efidevp.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efierr.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efigop.h
 create mode 100644 bsps/shared/freebsd/stand/efi/include/efilib.h
 create mode 100644 bsps/shared/freebsd/stand/efi/libefi/libefi.c
 create mode 100644 bsps/shared/freebsd/stand/efi/libefi/wchar.c

diff --git a/bsps/shared/freebsd/stand/efi/include/README 
b/bsps/shared/freebsd/stand/efi/include/README
new file mode 100644
index 00..bf821fae7e
--- /dev/null
+++ b/bsps/shared/freebsd/stand/efi/include/README
@@ -0,0 +1,36 @@
+/* $FreeBSD$ */
+/*-
+
+Files in this directory and subdirectories are subject to the following
+copyright unless superceded or supplemented by additional specific license
+terms found in the file headers of individual files.
+
+Copyright (c) 1998-2000 Intel Corporation
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions
+are met:
+
+Redistributions of source code must retain the above copyright
+notice, this list of conditions and the following disclaimer.
+
+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 ``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 INTEL 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 EFI SPECIFICATION AND ALL
+OTHER INFORMATION ON THIS WEB SITE ARE PROVIDED "AS IS" WITH NO
+WARRANTIES, AND ARE SUBJECT TO CHANGE WITHOUT NOTICE.
+
+*/
diff --git a/bsps/shared/freebsd/stand/efi/include/amd64/efibind.h 
b/bsps/shared/freebsd/stand/efi/include/amd64/efibind.h
new file mode 100644
index 00..97b4a04865
--- /dev/null
+++ b/bsps/shared/freebsd/stand/efi/include/amd64/efibind.h
@@ -0,0 +1,275 @@
+/* $FreeBSD$ */
+/*++
+
+Copyright (c)  1999 - 2003 Intel Corporation. All rights reserved
+This software and associated documentation (if any) is furnished
+under a license and may only be used or copied in accordance
+with the terms of the license. Except as permitted by such
+license, no part of this software or documentation may be
+reproduced, stored in a retrieval system, or transmitted in any
+form or by any means without the express written consent of
+Intel Corporation.
+
+Module Name:
+
+efefind.h
+
+Abstract:
+
+EFI to compile bindings
+
+
+
+
+Revision History
+
+--*/
+
+#pragma pack()
+
+
+#ifdef __FreeBSD__
+#include 
+#elif __rtems__
+#include 
+#else
+//
+// Basic int types of various widths
+//
+
+#if (__STDC_VERSION__ < 199901L )
+
+// No ANSI C 1999/2000 stdint.h integer width declarations 
+
+#ifdef _MSC_EXTENSIONS
+
+// Use Microsoft C compiler integer width declarations 
+
+typedef unsigned __int64uint64_t;
+typedef __int64

Re: Qemu and missing dynamic libraries

2023-04-24 Thread Karel Gardas


On 4/24/23 21:33, Joel Sherrill wrote:



On Mon, Apr 24, 2023, 2:11 PM Karel Gardas  wrote:


What have you done to this poor FBSD? ;-)

Anyway, I've just pkg update; pkg upgrade and result is:

karel@rtems:/usr/local/lib $ ls -la libglib-2.0.*
-rw-r--r--  1 root  wheel  2434866 Apr  2 03:18 libglib-2.0.a
lrwxr-xr-x  1 root  wheel       16 Apr  2 03:19 libglib-2.0.so
<http://libglib-2.0.so> ->
libglib-2.0.so.0
lrwxr-xr-x  1 root  wheel       23 Apr  2 03:19 libglib-2.0.so.0 ->
libglib-2.0.so.0.7600.1
-rwxr-xr-x  1 root  wheel  1332424 Apr  2 03:19 libglib-2.0.so.0.7600.1
karel@rtems:/usr/local/lib $ ls -la libintl.*
-rw-r--r--  1 root  wheel  115868 Jan  3 02:12 libintl.a
lrwxr-xr-x  1 root  wheel      16 Jan  3 02:12 libintl.so ->
libintl.so.8.3.0
lrwxr-xr-x  1 root  wheel      16 Jan  3 02:12 libintl.so.8 ->
libintl.so.8.3.0
-rw-r--r--  1 root  wheel   2 Jan  3 02:12 libintl.so.8.3.0
karel@rtems:/usr/local/lib $ ldd libglib-2.0.so.0.7600.1
libglib-2.0.so.0.7600.1:
          libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x1385d09a2000)
          libintl.so.8 => /usr/local/lib/libintl.so.8 (0x1385d19dc000)
          libpcre2-8.so.0 => /usr/local/lib/libpcre2-8.so.0
(0x1385d23ff000)
          libutil.so.9 => /lib/libutil.so.9 (0x1385d27d9000)
          libthr.so.3 => /lib/libthr.so.3 (0x1385d2e51000)
          libc.so.7 => /lib/libc.so.7 (0x1385cdce8000)


so in the worst case you would need to do some house cleaning...


Just got this to repeat with someone in the class this week with Ubuntu 
22 in a VM. The needed dynamic libraries are installed with the RTEMS 
tools in lib64. Weird


This sounds strange. First of all, your original report was about FBSD 
13.1-p6. Obviously you have not been lucky and glib package maintainer 
published library requiring libintl.so.9 and then probably reverted to 
.8. So high chance is pkg update; pkg upgrade may solve the issue.


W.r.t. RTEMS tools installing glib/libintl ? Never heard/seen anything 
like that and Ubuntu is pretty close to home call here...


Karel

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

Re: Qemu and missing dynamic libraries

2023-04-24 Thread Karel Gardas




What have you done to this poor FBSD? ;-)

Anyway, I've just pkg update; pkg upgrade and result is:

karel@rtems:/usr/local/lib $ ls -la libglib-2.0.*
-rw-r--r--  1 root  wheel  2434866 Apr  2 03:18 libglib-2.0.a
lrwxr-xr-x  1 root  wheel   16 Apr  2 03:19 libglib-2.0.so -> 
libglib-2.0.so.0
lrwxr-xr-x  1 root  wheel   23 Apr  2 03:19 libglib-2.0.so.0 -> 
libglib-2.0.so.0.7600.1

-rwxr-xr-x  1 root  wheel  1332424 Apr  2 03:19 libglib-2.0.so.0.7600.1
karel@rtems:/usr/local/lib $ ls -la libintl.*
-rw-r--r--  1 root  wheel  115868 Jan  3 02:12 libintl.a
lrwxr-xr-x  1 root  wheel  16 Jan  3 02:12 libintl.so -> 
libintl.so.8.3.0
lrwxr-xr-x  1 root  wheel  16 Jan  3 02:12 libintl.so.8 -> 
libintl.so.8.3.0

-rw-r--r--  1 root  wheel   2 Jan  3 02:12 libintl.so.8.3.0
karel@rtems:/usr/local/lib $ ldd libglib-2.0.so.0.7600.1
libglib-2.0.so.0.7600.1:
libiconv.so.2 => /usr/local/lib/libiconv.so.2 (0x1385d09a2000)
libintl.so.8 => /usr/local/lib/libintl.so.8 (0x1385d19dc000)
libpcre2-8.so.0 => /usr/local/lib/libpcre2-8.so.0 (0x1385d23ff000)
libutil.so.9 => /lib/libutil.so.9 (0x1385d27d9000)
libthr.so.3 => /lib/libthr.so.3 (0x1385d2e51000)
libc.so.7 => /lib/libc.so.7 (0x1385cdce8000)


so in the worst case you would need to do some house cleaning...

And while doing that, you may as well upgrade 13.1 -> 13.2.

Good luck!
Karel

On 4/24/23 20:28, Joel Sherrill wrote:

Hi

It looks like something has broken recently with building qemu via the 
RSB and dynamic libraries. All invocations of qemu are failing


https://lists.rtems.org/pipermail/build/2023-April/044792.html 



Not sure what to do. Maybe LD_LIBRARY_PATH but that wasn't needed before

--joel

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


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

Re: RSB repo commits need approval

2023-04-27 Thread Karel Gardas


On 4/27/23 08:13, Sebastian Huber wrote:
Why 
don't we use a Git pull request workflow with CI pipelines in the RTEMS 
Project?


I don't know, but certainly github.com is not available as an 
open-source solution which may be seen as a major roadblock. Am I right 
assuming that GitLab Community is the most close to that and available 
for running by anyone?
As an observer on another project with GitLab (GHC Haskell compiler) 
I've seen this solution is not free as a work free, but requires some 
man-hours investments...


So the question after "yes" to migrate (if the consensus is found!) is 
"who will pay the price and do the job"...


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

Re: Change build specification files from YAML to JSON?

2023-04-25 Thread Karel Gardas


On 4/25/23 12:32, Sebastian Huber wrote:

On 25.04.23 12:10, Karel Gardas wrote:

On 4/25/23 11:03, Sebastian Huber wrote:



On 25.04.23 11:00, Karel Gardas wrote:

On 4/25/23 09:35, Sebastian Huber wrote:
The change from YAML to JSON for the build specification files is 
just an implementation detail of the new build system. For the 
users of the new build system nothing changes.


Let me ask for clarification. Does this yaml -> json transition 
include (or not) files in RTEMS spec directory, e.g. files here:


https://git.rtems.org/rtems/tree/spec


It would affect all YAML files in this directory and no other files.


Oh. Let me ask, what is your future plan with the spec files? 
Considering you would like to move them to JSON, would you also like 
to provide some DSL + compiler which would generates those? Or would 
you just like to keep JSON and have developers editing those?


I would keep the JSON and have developer editing those.

An alternative to changing the format could be to use the CSafeLoader of 
the system yaml module if it is available. It is not as fast as the JSON 
loader, but acceptable (0.65s to 0.2s on my machine for loading the items).


Sorry for perhaps silly question, but why do you invest that much energy 
in optimizing build speed -- by fraction of seconds here? I so far fail 
so to see driving motivation force hence my question...


Thanks,
Karel




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

Re: Change build specification files from YAML to JSON?

2023-04-25 Thread Karel Gardas


On 4/25/23 11:03, Sebastian Huber wrote:



On 25.04.23 11:00, Karel Gardas wrote:

On 4/25/23 09:35, Sebastian Huber wrote:
The change from YAML to JSON for the build specification files is 
just an implementation detail of the new build system. For the users 
of the new build system nothing changes.


Let me ask for clarification. Does this yaml -> json transition 
include (or not) files in RTEMS spec directory, e.g. files here:


https://git.rtems.org/rtems/tree/spec


It would affect all YAML files in this directory and no other files.


Oh. Let me ask, what is your future plan with the spec files? 
Considering you would like to move them to JSON, would you also like to 
provide some DSL + compiler which would generates those? Or would you 
just like to keep JSON and have developers editing those?


Thanks,
Karel

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

Re: Change build specification files from YAML to JSON?

2023-04-25 Thread Karel Gardas


On 4/25/23 09:35, Sebastian Huber wrote:
The change from YAML to JSON for the build specification files is just 
an implementation detail of the new build system. For the users of the 
new build system nothing changes.


Let me ask for clarification. Does this yaml -> json transition include 
(or not) files in RTEMS spec directory, e.g. files here:


https://git.rtems.org/rtems/tree/spec

Thanks!
Karel

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

< 1 2 3 4 >

201 - 300 of 383 matches

Mail list logo