[PATCH] tools/gnu: Enable LTO in RSB tools

[chrisj]

From: Chris Johns 

---
 source-builder/config/binutils-2-1.cfg |  6 +-
 source-builder/config/gcc-common-1.cfg | 10 +++---
 2 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/source-builder/config/binutils-2-1.cfg 
b/source-builder/config/binutils-2-1.cfg
index a49fa2a..6de33ae 100644
--- a/source-builder/config/binutils-2-1.cfg
+++ b/source-builder/config/binutils-2-1.cfg
@@ -26,14 +26,11 @@ URL:   http://sources.redhat.com/binutils
 %define allow_cxc
 
 #
-# Default gold and LTO to disable.
+# Default gold to disable.
 #
 %ifn %{defined with_gold}
  %define with_gold 0
 %endif
-%ifn %{defined with_lto}
- %define with_lto 0
-%endif
 
 #
 # Source
@@ -72,7 +69,6 @@ URL: http://sources.redhat.com/binutils
 %{?with_deterministic_archives:--enable-deterministic-archives} \
 %{?with_64_bit_bfd:--enable-64-bit-bfd} \
 %{?with_gold:--enable-gold=yes} \
-%{?with_lto:--enable-lto --enable-plugins}%{!?with_lto:--disable-lto} \
 --without-included-gettext \
 --disable-win32-registry \
 --disable-werror \
diff --git a/source-builder/config/gcc-common-1.cfg 
b/source-builder/config/gcc-common-1.cfg
index 05e0e3c..694a1f3 100644
--- a/source-builder/config/gcc-common-1.cfg
+++ b/source-builder/config/gcc-common-1.cfg
@@ -34,7 +34,7 @@ URL: http://gcc.gnu.org/
 # Default LTO to off.
 #
 %ifn %{defined with_lto}
- %define with_lto 0
+ %define enable_lto 1
 %endif
 
 #
@@ -165,11 +165,8 @@ URL:  http://gcc.gnu.org/
 %if %{enable_fortran}
   languages="$languages,fortran"
 %endif
-%if %{enable_java}
-  languages="$languages,java"
-%endif
-%if %{enable_objc}
-  languages="$languages,objc"
+%if %{enable_lto}
+  languages="$languages,lto"
 %endif
 
   %{host_build_flags}
@@ -193,7 +190,6 @@ URL:   http://gcc.gnu.org/
 --disable-win32-registry \
 --disable-werror \
 --enable-version-specific-runtime-libs \
-%{?with_lto:--enable-lto}%{!?with_lto:--disable-lto} \
 --enable-newlib-io-c99-formats \
 %{?disable_MAKEINFO:MAKEINFO=missing} \
 %{?with_iconv:--enable-newlib-iconv} \
-- 
2.24.1

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

Enable LTO support in RTEMS tools

[chrisj]

This patch enables LTO support in RTWMS tools. It is not
used unless you build and link apps with LTO options and link.

I will look at adding a config.ini option to build RTEMS with
the LTO options.

Chris


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

Re: [PATCH] tools/gnu: Enable LTO in RSB tools

[Joel Sherrill]

What's the problem with enabling LTO support in the tools by default?

Using it is a different matter.

--joel

On Wed, Jun 15, 2022, 7:20 AM  wrote:

> From: Chris Johns 
>
> ---
>  source-builder/config/binutils-2-1.cfg |  6 +-
>  source-builder/config/gcc-common-1.cfg | 10 +++---
>  2 files changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/source-builder/config/binutils-2-1.cfg
> b/source-builder/config/binutils-2-1.cfg
> index a49fa2a..6de33ae 100644
> --- a/source-builder/config/binutils-2-1.cfg
> +++ b/source-builder/config/binutils-2-1.cfg
> @@ -26,14 +26,11 @@ URL:   http://sources.redhat.com/binutils
>  %define allow_cxc
>
>  #
> -# Default gold and LTO to disable.
> +# Default gold to disable.
>  #
>  %ifn %{defined with_gold}
>   %define with_gold 0
>  %endif
> -%ifn %{defined with_lto}
> - %define with_lto 0
> -%endif
>
>  #
>  # Source
> @@ -72,7 +69,6 @@ URL: http://sources.redhat.com/binutils
>  %{?with_deterministic_archives:--enable-deterministic-archives} \
>  %{?with_64_bit_bfd:--enable-64-bit-bfd} \
>  %{?with_gold:--enable-gold=yes} \
> -%{?with_lto:--enable-lto --enable-plugins}%{!?with_lto:--disable-lto}
> \
>  --without-included-gettext \
>  --disable-win32-registry \
>  --disable-werror \
> diff --git a/source-builder/config/gcc-common-1.cfg
> b/source-builder/config/gcc-common-1.cfg
> index 05e0e3c..694a1f3 100644
> --- a/source-builder/config/gcc-common-1.cfg
> +++ b/source-builder/config/gcc-common-1.cfg
> @@ -34,7 +34,7 @@ URL: http://gcc.gnu.org/
>  # Default LTO to off.
>  #
>  %ifn %{defined with_lto}
> - %define with_lto 0
> + %define enable_lto 1
>  %endif
>
>  #
> @@ -165,11 +165,8 @@ URL:  http://gcc.gnu.org/
>  %if %{enable_fortran}
>languages="$languages,fortran"
>  %endif
> -%if %{enable_java}
> -  languages="$languages,java"
> -%endif
> -%if %{enable_objc}
> -  languages="$languages,objc"
> +%if %{enable_lto}
> +  languages="$languages,lto"
>  %endif
>
>%{host_build_flags}
> @@ -193,7 +190,6 @@ URL:   http://gcc.gnu.org/
>  --disable-win32-registry \
>  --disable-werror \
>  --enable-version-specific-runtime-libs \
> -%{?with_lto:--enable-lto}%{!?with_lto:--disable-lto} \
>  --enable-newlib-io-c99-formats \
>  %{?disable_MAKEINFO:MAKEINFO=missing} \
>  %{?with_iconv:--enable-newlib-iconv} \
> --
> 2.24.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] sppps01: Add test case for early returns of pps_event()

[Gabriel Moyano]

---
 testsuites/sptests/sppps01/init.c | 42 +++
 1 file changed, 42 insertions(+)

diff --git a/testsuites/sptests/sppps01/init.c 
b/testsuites/sptests/sppps01/init.c
index 996a3a1e16..ee3fe1645b 100644
--- a/testsuites/sptests/sppps01/init.c
+++ b/testsuites/sptests/sppps01/init.c
@@ -76,6 +76,48 @@ T_TEST_CASE( WaitPPSEventDefaultHandler )
   T_eq_int( status, ETIMEDOUT );
 }
 
+static int wokenup = 0;
+
+static void fake_wakeup(struct pps_state *pps)
+{
+wokenup++;
+}
+
+T_TEST_CASE( PPSEventEarlyReturns )
+{
+  struct test_pps_device pps_dev;
+
+  wokenup = 0;
+  pps_dev.task_waiting = RTEMS_INVALID_ID;
+
+  memset( &pps_dev.pps, 0, sizeof( pps_dev.pps ) );
+  pps_dev.pps.ppscap = PPS_CAPTUREBOTH;
+  pps_init_abi( &pps_dev.pps );
+  pps_dev.pps.wakeup = fake_wakeup;
+  pps_dev.pps.ppsparam.mode = PPS_CAPTUREASSERT;
+
+  pps_capture( &pps_dev.pps );
+  /* Trigger event with a different event than the one previously selected */
+  pps_event( &pps_dev.pps, PPS_CAPTURECLEAR );
+  T_eq_int( wokenup, 0 );
+
+  pps_dev.pps.ppsparam.mode = PPS_CAPTURECLEAR;
+
+  /* Wait th_generation to be updated */
+  rtems_task_wake_after(1);
+  pps_event( &pps_dev.pps, PPS_CAPTURECLEAR );
+  T_eq_int( wokenup, 0 );
+
+  /* Save current timecounter in pps_state object */
+  pps_capture( &pps_dev.pps );
+  pps_event( &pps_dev.pps, PPS_CAPTURECLEAR );
+  T_eq_int( wokenup, 0 );
+
+  pps_capture( &pps_dev.pps );
+  pps_event( &pps_dev.pps, PPS_CAPTURECLEAR );
+  T_eq_int( wokenup, 1 );
+}
+
 static void wakeup(struct pps_state *pps)
 {
   struct test_pps_device *pps_dev;
-- 
2.25.1

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

Re: [PATCH 2/3] bsp/versal: Support more than 4G of RAM

[Gedare Bloom]

This was copied from the ZynqMP, should that also use a 64-bit value
for the ram length?

Probably any 64-bit architecture should do so?

On Tue, Jun 14, 2022 at 6:40 PM Chris Johns  wrote:
>
> On 15/6/2022 2:43 am, Joel Sherrill wrote:
> > OK but the commit message could be a bit more enlightening.
>
> What about:
>
>  bsp/versal: Make RAM base 64bit to support more than 4G of RAM
>
> > It took me a minute to realize that all this did was change the type
> > of the memory length parameter. It actually does not change any
> > lengths to > 4 GB.
>
> Yes it is a constraint on the value and not the value.
>
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 3/3] aarch64/gicv3: Remove accesses to secure registers

[Gedare Bloom]

On Tue, Jun 14, 2022 at 6:56 PM Chris Johns  wrote:
>
> On 14/6/2022 11:44 pm, Gedare Bloom wrote:
> > On Mon, Jun 13, 2022 at 7:39 PM  wrote:
> >>
> >> From: Chris Johns 
> >>
> >> ---
> >>  bsps/include/dev/irq/arm-gicv3.h | 18 +++---
> >>  1 file changed, 15 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/bsps/include/dev/irq/arm-gicv3.h 
> >> b/bsps/include/dev/irq/arm-gicv3.h
> >> index 0d3ef9a1c1..a79368ebdf 100644
> >> --- a/bsps/include/dev/irq/arm-gicv3.h
> >> +++ b/bsps/include/dev/irq/arm-gicv3.h
> >> @@ -300,12 +300,25 @@ static void gicv3_init_dist(volatile gic_dist *dist)
> >>}
> >>  }
> >>
> >> +/*
> >> + * A better way to access these registers than special opcodes
> >> + */
> >> +#define isb() __asm __volatile("isb" : : : "memory")
> >> +
> >> +#define  WRITE_SPECIALREG(reg, _val)\
> >> +  __asm __volatile("msr  " __STRING(reg) ", %0" : : "r"((uint64_t)_val))
> >> +
> >> +#define  gic_icc_write(reg, val)\
> >> +do {\
> >> +  WRITE_SPECIALREG(icc_ ##reg ##_el1, val); \
> >> +  isb();\
> >> +} while (0)
> >> +
> >>  static void gicv3_init_cpu_interface(uint32_t cpu_index)
> >>  {
> >>uint32_t sre_value = 0x7;
> >>WRITE_SR(ICC_SRE, sre_value);
> >>WRITE_SR(ICC_PMR, GIC_CPUIF_ICCPMR_PRIORITY(0xff));
> >> -  WRITE_SR(ICC_BPR0, GIC_CPUIF_ICCBPR_BINARY_POINT(0x0));
> > This appears unrelated?
>
> The binary pointer effects the secure interrupts and so cannot be touched on
> EL1. It traps into EL3. It makes sense to me it is protected. There is no code
> in Petalinux or FreeBSD writing to this register.
>
> >>volatile gic_redist *redist = gicv3_get_redist(cpu_index);
> >>uint32_t waker = redist->icrwaker;
> >> @@ -322,8 +335,7 @@ static void gicv3_init_cpu_interface(uint32_t 
> >> cpu_index)
> >>}
> >>
> >>/* Enable interrupt groups 0 and 1 */
> >> -  WRITE_SR(ICC_IGRPEN0, 0x1);
> >> -  WRITE_SR(ICC_IGRPEN1, 0x1);
> >> +  gic_icc_write(IGRPEN1, 1);
> > Removed the write to IGRPEN0?
>
> The write I replaced is touching a secure register and so traps into EL3 when
> your TF-A has enabled a secure mode.
>
> The enable is replaced with a write to the EL1 accessible register. This is 
> how
> FreeBSD does it so I copied that method rather than the binary opcode approach
> which I found complicated.
>
> You need a suitably configured TF-A to run on aarch64. I would be questioning
> any TF-A that lets this code run without these changes. The Xilinx 2020.2
> vck-190 build of TF-A lets our code run without this patch however 2021.2 had
> tightened things. Xilinx and I looked into the history of their TF-A source 
> and
> how they build it and came to the conclusion the change in the secure mode has
> come from ARM and their TF-A code.
>
OK, thanks for the explanation. This looks ok to me.

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

Re: [PATCH 3/5] cpukit/libmd/md5.c: fix warning

[Gedare Bloom]

On Thu, Jun 9, 2022 at 12:09 AM Sebastian Huber
 wrote:
>
> On 08/06/2022 18:09, Joel Sherrill wrote:
> >
> > On Wed, Jun 8, 2022, 10:45 AM Gedare Bloom  > > wrote:
> >
> > Does this code have an upstream?
> >
> >
> > I tried to find it. Maybe whoever added it has memory of the source.
> >
> > As best I can tell, it is lightly or not maintained reference code.
>
> Maybe we should replace the libmd stuff with the latest code from
> OpenBSD or FreeBSD.
>
That would be good.

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.hu...@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

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

[Gedare Bloom]

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?

> +#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*)&QSPinit, 0, sizeof(BSP_QSPI_Init_t));
> +BSP_QSPI_Init(0, &QSPinit);
> +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
___
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

[Gedare Bloom]

On Wed, Jun 15, 2022 at 9:00 AM 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?
>
> > +#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?

> > +{
> > +#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*)&QSPinit, 0, sizeof(BSP_QSPI_Init_t));
> > +BSP_QSPI_Init(0, &QSPinit);
> > +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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Porting PPS API support to RTEMS 5

[Gedare Bloom]

This may be a better question to pose to users@ ml

On Mon, Jun 13, 2022 at 8:10 AM  wrote:
>
> Hello everyone,
>
>
>
> I ported the PPS API support from RTEMS 6 to RTEMS 5 and wanted to ask if 
> somebody is interest to have the changes in the upstream. If yes, I can 
> submit the patches.
>
>
>
> Best regards,
>
> Gabriel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 2/3] bsp/versal: Support more than 4G of RAM

[Kinsey Moore]

On 6/15/2022 09:48, Gedare Bloom wrote:

This was copied from the ZynqMP, should that also use a 64-bit value
for the ram length?

Probably any 64-bit architecture should do so?


I'd agree with that.


Kinsey

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

Re: [PATCH 3/3] aarch64/gicv3: Remove accesses to secure registers

[Kinsey Moore]

On 6/15/2022 09:51, Gedare Bloom wrote:

On Tue, Jun 14, 2022 at 6:56 PM Chris Johns  wrote:

On 14/6/2022 11:44 pm, Gedare Bloom wrote:

On Mon, Jun 13, 2022 at 7:39 PM  wrote:

From: Chris Johns 

---
  bsps/include/dev/irq/arm-gicv3.h | 18 +++---
  1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/bsps/include/dev/irq/arm-gicv3.h b/bsps/include/dev/irq/arm-gicv3.h
index 0d3ef9a1c1..a79368ebdf 100644
--- a/bsps/include/dev/irq/arm-gicv3.h
+++ b/bsps/include/dev/irq/arm-gicv3.h
@@ -300,12 +300,25 @@ static void gicv3_init_dist(volatile gic_dist *dist)
}
  }

+/*
+ * A better way to access these registers than special opcodes
+ */
+#define isb() __asm __volatile("isb" : : : "memory")
+
+#define  WRITE_SPECIALREG(reg, _val)\
+  __asm __volatile("msr  " __STRING(reg) ", %0" : : "r"((uint64_t)_val))
+
+#define  gic_icc_write(reg, val)\
+do {\
+  WRITE_SPECIALREG(icc_ ##reg ##_el1, val); \
+  isb();\
+} while (0)
+
  static void gicv3_init_cpu_interface(uint32_t cpu_index)
  {
uint32_t sre_value = 0x7;
WRITE_SR(ICC_SRE, sre_value);
WRITE_SR(ICC_PMR, GIC_CPUIF_ICCPMR_PRIORITY(0xff));
-  WRITE_SR(ICC_BPR0, GIC_CPUIF_ICCBPR_BINARY_POINT(0x0));

This appears unrelated?

The binary pointer effects the secure interrupts and so cannot be touched on
EL1. It traps into EL3. It makes sense to me it is protected. There is no code
in Petalinux or FreeBSD writing to this register.


volatile gic_redist *redist = gicv3_get_redist(cpu_index);
uint32_t waker = redist->icrwaker;
@@ -322,8 +335,7 @@ static void gicv3_init_cpu_interface(uint32_t cpu_index)
}

/* Enable interrupt groups 0 and 1 */
-  WRITE_SR(ICC_IGRPEN0, 0x1);
-  WRITE_SR(ICC_IGRPEN1, 0x1);
+  gic_icc_write(IGRPEN1, 1);

Removed the write to IGRPEN0?

The write I replaced is touching a secure register and so traps into EL3 when
your TF-A has enabled a secure mode.

The enable is replaced with a write to the EL1 accessible register. This is how
FreeBSD does it so I copied that method rather than the binary opcode approach
which I found complicated.

You need a suitably configured TF-A to run on aarch64. I would be questioning
any TF-A that lets this code run without these changes. The Xilinx 2020.2
vck-190 build of TF-A lets our code run without this patch however 2021.2 had
tightened things. Xilinx and I looked into the history of their TF-A source and
how they build it and came to the conclusion the change in the secure mode has
come from ARM and their TF-A code.


OK, thanks for the explanation. This looks ok to me.


This set of changes makes sense given our previous discussion and the above.


Kinsey

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

Re: [PATCH 1/3] bsp/aarch64: Flush the cache before invalidating it

[Kinsey Moore]

Looks good.

On 6/13/2022 20:39, chr...@rtems.org wrote:

From: Chris Johns 

- Any page tables need to be flushed if the cache is enabled.
   Disabling the cache may only be available in secure mode.
---
  bsps/aarch64/include/bsp/aarch64-mmu.h | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/bsps/aarch64/include/bsp/aarch64-mmu.h 
b/bsps/aarch64/include/bsp/aarch64-mmu.h
index b1a471d534..6e589cd6cd 100644
--- a/bsps/aarch64/include/bsp/aarch64-mmu.h
+++ b/bsps/aarch64/include/bsp/aarch64-mmu.h
@@ -362,7 +362,8 @@ aarch64_mmu_enable( void )
  
/* CPUECTLR_EL1.SMPEN is already set on ZynqMP and is not writable */
  
-  /* Invalidate cache */

+  /* Flush and invalidate cache */
+  rtems_cache_flush_entire_data();
rtems_cache_invalidate_entire_data();
  
/* Enable MMU and cache */

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

Re: [PATCH] tools/gnu: Enable LTO in RSB tools

[Chris Johns]

On 15/6/2022 10:58 pm, Joel Sherrill wrote:
> What's the problem with enabling LTO support in the tools by default?

None that I know of and this patch enables the support by default. The RSB
incorrectly supported the configure `--enable-lto` option. That option controls
the host build and when enabled the built host executables are built with LTO.

For RTEMS building LTO support is via the languages option, ie it is treated as
a language. This patch provides that support and enables it.

> Using it is a different matter.

Yes. I comments were an attempt to highlight this. I would like to see LTO
support available but it is not something all users will use.

FYI Xilinx use to build the Microblaze firmware for the PMC/PMS cores in the 
Versal.

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

Re: [PATCH] tools/gnu: Enable LTO in RSB tools

[Joel Sherrill]

On Wed, Jun 15, 2022 at 5:29 PM Chris Johns  wrote:

> On 15/6/2022 10:58 pm, Joel Sherrill wrote:
> > What's the problem with enabling LTO support in the tools by default?
>
> None that I know of and this patch enables the support by default. The RSB
> incorrectly supported the configure `--enable-lto` option. That option
> controls
> the host build and when enabled the built host executables are built with
> LTO.
>
> For RTEMS building LTO support is via the languages option, ie it is
> treated as
> a language. This patch provides that support and enables it.
>

I'm happy with that. If it is going to cause a problem building the tools,
it would
be better to know it and then disable it for an architecture until that's
resolved.

>
> > Using it is a different matter.
>
> Yes. I comments were an attempt to highlight this. I would like to see LTO
> support available but it is not something all users will use.
>
> FYI Xilinx use to build the Microblaze firmware for the PMC/PMS cores in
> the Versal.
>

 Interesting. I wonder if we have any examples that would show
a real benefit from it. I think it would take a real application to
see an advantage.

--joel


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

Re: [PATCH] tools/gnu: Enable LTO in RSB tools

[Chris Johns]

On 16/6/2022 8:41 am, Joel Sherrill wrote:
> On Wed, Jun 15, 2022 at 5:29 PM Chris Johns  > wrote:
> 
> On 15/6/2022 10:58 pm, Joel Sherrill wrote:
> > What's the problem with enabling LTO support in the tools by default?
> 
> None that I know of and this patch enables the support by default. The RSB
> incorrectly supported the configure `--enable-lto` option. That option 
> controls
> the host build and when enabled the built host executables are built with 
> LTO.
> 
> For RTEMS building LTO support is via the languages option, ie it is 
> treated as
> a language. This patch provides that support and enables it.
> 
> I'm happy with that. If it is going to cause a problem building the tools, it 
> would
> be better to know it and then disable it for an architecture until that's 
> resolved. 

Is that a catch-22? We will not know until we enable it? :)

> > Using it is a different matter.
> 
> Yes. I comments were an attempt to highlight this. I would like to see LTO
> support available but it is not something all users will use.
> 
> FYI Xilinx use to build the Microblaze firmware for the PMC/PMS cores in 
> the
> Versal.
> 
>  Interesting. I wonder if we have any examples that would show
> a real benefit from it. I think it would take a real application to 
> see an advantage.

I do not know. It should help with C++ applications.

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