Re: Xilinx header files installed by BSP

[Kinsey Moore]

On Mon, Mar 25, 2024 at 3:34 PM Bernd Moessner 
wrote:

>
> On 25.03.2024 13:26, Sebastian Huber wrote:
> > Hello,
> >
> > the BSPs for the Xilinx Zynq/ZynqMP/Versal platforms use code from
> > Xilinx. They also install some header files from Xilinx in the
> > top-level include directory of the BSP, for example:
> >
> > sleep.h  xbasic_types.h  xil_assert.h  xil_cache.h xil_exception.h
> > xil_io.h  xil_mem.h  xil_printf.h  xil_smc.h xil_types.h
> > xparameters.h  xpseudo_asm_gcc.h  xpseudo_asm.h xreg_cortexa53.h
> > xstatus.h
> >
> > This can lead to conflicts if I would like to build software from
> >
> > https://github.com/Xilinx/embeddedsw
> >
> > because now some header files are duplicated and available through
> > different include paths. Why do we install these header files? I think
> > they should be only used internally to build the BSP provided drivers.
> > The RTEMS drivers should expose their interfaces not through the
> > Xilinx header files.
> >
> > Any objections to remove the installation of the Xilinx header files?
> >
> Dear Sebastian,
>
> Zynq 7000 is not using them. Rtems-lwip requires some of the headers. I
> provided a patch which added "objxilinxsupport.yml" to the Zynq 7000
> configurations. After a discussion on Discord my patch was rolled back
> (which I think was a good decision).
>
> Chris and Kinsey, please correct me if I misunderstood something, but as
> far as I understood it the headers will be removed from the kernel.
> Afaik, there are some drivers for the ZU require them. Thus, it will
> require some time / planning to overwork the drivers and move the
> required headers to rtems-lwip.
>
> Long story short, Chris and Kinsey should be able to give some more
> detailed information on the strategy and timeline.
>

The eventual goal is that the installed Xilinx headers will no longer be
installed to prevent conflicts as Sebastian suggested. Currently, use of
the QSPI/NOR and NAND drivers in RTEMS requires access to those headers in
the installed BSP. Those drivers need to be wrapped to remove dependency on
installed Xilinx headers. It's on my todo list to wrap these drivers
properly.

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

Re: [PATCH rtems6] Fix: type-cast to wrong type

[Sebastian Huber]

On 25.03.24 21:44, berndmoessne...@gmail.com wrote:

From: Bernd Moessner 

---
  bsps/include/bsp/irq-generic.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/include/bsp/irq-generic.h b/bsps/include/bsp/irq-generic.h
index 5ed9cac688..31f345486f 100644
--- a/bsps/include/bsp/irq-generic.h
+++ b/bsps/include/bsp/irq-generic.h
@@ -417,7 +417,7 @@ static inline void bsp_interrupt_entry_store_release(
  #if defined(RTEMS_SMP)
_Atomic_Store_uintptr(
  (Atomic_Uintptr *) ptr,
-(Atomic_Uintptr) value,
+(uintptr_t) value,
  ATOMIC_ORDER_RELEASE
);
  #else


Thanks, I checked it in.

--
embedded brains GmbH & Co. KG
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: Xilinx header files installed by BSP

[Sebastian Huber]

On 25.03.24 21:36, Bernd Moessner wrote:


On 25.03.2024 13:26, Sebastian Huber wrote:

Hello,

the BSPs for the Xilinx Zynq/ZynqMP/Versal platforms use code from 
Xilinx. They also install some header files from Xilinx in the 
top-level include directory of the BSP, for example:


sleep.h  xbasic_types.h  xil_assert.h  xil_cache.h xil_exception.h 
xil_io.h  xil_mem.h  xil_printf.h  xil_smc.h xil_types.h xparameters.h 
 xpseudo_asm_gcc.h  xpseudo_asm.h xreg_cortexa53.h xstatus.h


This can lead to conflicts if I would like to build software from

https://github.com/Xilinx/embeddedsw

because now some header files are duplicated and available through 
different include paths. Why do we install these header files? I think 
they should be only used internally to build the BSP provided drivers. 
The RTEMS drivers should expose their interfaces not through the 
Xilinx header files.


Any objections to remove the installation of the Xilinx header files?


Dear Sebastian,

Zynq 7000 is not using them. Rtems-lwip requires some of the headers. I 
provided a patch which added "objxilinxsupport.yml" to the Zynq 7000 
configurations. After a discussion on Discord my patch was rolled back 
(which I think was a good decision).


Chris and Kinsey, please correct me if I misunderstood something, but as 
far as I understood it the headers will be removed from the kernel. 
Afaik, there are some drivers for the ZU require them. Thus, it will 
require some time / planning to overwork the drivers and move the 
required headers to rtems-lwip.


Long story short, Chris and Kinsey should be able to give some more 
detailed information on the strategy and timeline.


Maybe one option is to install the BSP-provided Xilinx headers in bsp/, 
for example:


#include 

--
embedded brains GmbH & Co. KG
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

[PATCH v2] RTEMS: Add multilib configuration for aarch64

[Sebastian Huber]

Add a multilib with workarounds for Cortex-A53 errata.

gcc/ChangeLog:

* config.gcc (aarch64-*-rtems*): Add target makefile fragment
t-aarch64-rtems.
* config/aarch64/t-aarch64-rtems: New file.
---
 gcc/config.gcc |  1 +
 gcc/config/aarch64/t-aarch64-rtems | 42 ++
 2 files changed, 43 insertions(+)
 create mode 100644 gcc/config/aarch64/t-aarch64-rtems

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 648b3dc2110..c3b73d05eb7 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1139,6 +1139,7 @@ aarch64*-*-elf | aarch64*-*-fuchsia* | aarch64*-*-rtems*)
 ;;
aarch64-*-rtems*)
tm_file="${tm_file} aarch64/rtems.h rtems.h"
+   tmake_file="${tmake_file} aarch64/t-aarch64-rtems"
;;
esac
case $target in
diff --git a/gcc/config/aarch64/t-aarch64-rtems 
b/gcc/config/aarch64/t-aarch64-rtems
new file mode 100644
index 000..11f8c380222
--- /dev/null
+++ b/gcc/config/aarch64/t-aarch64-rtems
@@ -0,0 +1,42 @@
+# Machine description for AArch64 architecture.
+#  Copyright (C) 2024 Free Software Foundation, Inc.
+#
+#  This file is part of GCC.
+#
+#  GCC is free software; you can redistribute it and/or modify it
+#  under the terms of the GNU General Public License as published by
+#  the Free Software Foundation; either version 3, or (at your option)
+#  any later version.
+#
+#  GCC is distributed in the hope that it will be useful, but
+#  WITHOUT ANY WARRANTY; without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+#  General Public License for more details.
+#
+#  You should have received a copy of the GNU General Public License
+#  along with GCC; see the file COPYING3.  If not see
+#  .
+
+MULTILIB_OPTIONS  =
+MULTILIB_DIRNAMES =
+
+MULTILIB_OPTIONS  += mabi=ilp32
+MULTILIB_DIRNAMES += ilp32
+
+MULTILIB_OPTIONS  += mno-outline-atomics
+MULTILIB_DIRNAMES += nooa
+
+MULTILIB_OPTIONS  += mcpu=cortex-a53
+MULTILIB_DIRNAMES += a53
+
+MULTILIB_OPTIONS  += mfix-cortex-a53-835769
+MULTILIB_DIRNAMES += fix835769
+
+MULTILIB_OPTIONS  += mfix-cortex-a53-843419
+MULTILIB_DIRNAMES += fix843419
+
+MULTILIB_REQUIRED =
+
+MULTILIB_REQUIRED += mabi=ilp32
+MULTILIB_REQUIRED += 
mabi=ilp32/mno-outline-atomics/mcpu=cortex-a53/mfix-cortex-a53-835769/mfix-cortex-a53-843419
+MULTILIB_REQUIRED += 
mno-outline-atomics/mcpu=cortex-a53/mfix-cortex-a53-835769/mfix-cortex-a53-843419
-- 
2.35.3

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

[PATCH rtems-docs] user/zynqmp-rpu: Add load and debug information

[Kinsey Moore]

This adds some information about loading the RPU TCMs from A53 u-boot
and additional information about debugging the RPU within QEMU since it
is non-standard.
---
 user/bsps/arm/xilinx-zynqmp-rpu.rst | 35 ++---
 1 file changed, 27 insertions(+), 8 deletions(-)

diff --git a/user/bsps/arm/xilinx-zynqmp-rpu.rst 
b/user/bsps/arm/xilinx-zynqmp-rpu.rst
index a29cb84..0dfb77e 100644
--- a/user/bsps/arm/xilinx-zynqmp-rpu.rst
+++ b/user/bsps/arm/xilinx-zynqmp-rpu.rst
@@ -35,14 +35,13 @@ it is recommended to use Cortex-A53 u-boot to avoid 
repeated BOOT.bin
 generation since the provided Cortex-R5 u-boot is highly limited and has no
 network or MMC/SD access.
 
-Note that if the RPU image is started by the Cortex-A53 u-boot, the BSP
-configuration must be updated to move ZYNQMP_RPU_RAM_INT_0_ORIGIN and
-ZYNQMP_RPU_RAM_INT_1_ORIGIN into DDR since the TCMs are not directly available
-to the Cortex-A53 cores at their Cortex-R5 internal addresses. Alternatively,
-those sections could be copied to the TCMs using their global addresses, but
-this must be done using additional commands within u-boot. If this is not taken
-into account, the Cortex-R5 CPU will fail to boot correctly since execution
-will jump into uninitialized TCM.
+Note that if the RPU image is started by the Cortex-A53 u-boot, the program
+sections located at ZYNQMP_RPU_RAM_INT_0_ORIGIN and ZYNQMP_RPU_RAM_INT_1_ORIGIN
+must be manually relocated from DDR to TCM since the TCMs are not directly
+available to the Cortex-A53 cores at their Cortex-R5 internal addresses. This
+can be accomplished by disabling dcache in u-boot and using u-boot's "cp"
+command. Once this is done, the program can be started at 0x0 by using u-boot's
+"cpu" command to first disable core 4 and then release it in split mode.
 
 Hardware Boot Image Generation
 --
@@ -74,3 +73,23 @@ following command:
-device loader,addr=0xff9a,data=0x8218,data-len=4 \
-hw-dtb /xlnx-qemu-devtrees-path/LATEST/SINGLE_ARCH/board-zynqmp-zcu102.dtb 
\
-m 4096 -display none
+
+Debugging Executables on QEMU
+-
+
+Debugging the RPU cores under QEMU presents unique challenges due to requiring
+the AArch64 QEMU to emulate the entire processing subsystem. Debugging requires
+a multi-arch GDB which can be created by adding "--enable-targets=all" to the
+normal GDB configure line and then building as normal.
+
+To attach to the RPU core once QEMU is started with "-s -S", The following 
steps
+are required:
+
+.. code-block:: shell
+
+  aarch64-rtems6-gdb
+  (gdb) tar ext :1234
+  (gdb) add-inferior
+  (gdb) inferior 2
+  (gdb) file example.exe
+  (gdb) attach 2
-- 
2.39.2

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

[PATCH rtems6] Fix: type-cast to wrong type

[berndmoessner80]

From: Bernd Moessner 

---
 bsps/include/bsp/irq-generic.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/bsps/include/bsp/irq-generic.h b/bsps/include/bsp/irq-generic.h
index 5ed9cac688..31f345486f 100644
--- a/bsps/include/bsp/irq-generic.h
+++ b/bsps/include/bsp/irq-generic.h
@@ -417,7 +417,7 @@ static inline void bsp_interrupt_entry_store_release(
 #if defined(RTEMS_SMP)
   _Atomic_Store_uintptr(
 (Atomic_Uintptr *) ptr,
-(Atomic_Uintptr) value,
+(uintptr_t) value,
 ATOMIC_ORDER_RELEASE
   );
 #else
-- 
2.34.1

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

Re: Xilinx header files installed by BSP

[Bernd Moessner]

On 25.03.2024 13:26, Sebastian Huber wrote:

Hello,

the BSPs for the Xilinx Zynq/ZynqMP/Versal platforms use code from 
Xilinx. They also install some header files from Xilinx in the 
top-level include directory of the BSP, for example:


sleep.h  xbasic_types.h  xil_assert.h  xil_cache.h xil_exception.h 
xil_io.h  xil_mem.h  xil_printf.h  xil_smc.h xil_types.h  
xparameters.h  xpseudo_asm_gcc.h  xpseudo_asm.h xreg_cortexa53.h  
xstatus.h


This can lead to conflicts if I would like to build software from

https://github.com/Xilinx/embeddedsw

because now some header files are duplicated and available through 
different include paths. Why do we install these header files? I think 
they should be only used internally to build the BSP provided drivers. 
The RTEMS drivers should expose their interfaces not through the 
Xilinx header files.


Any objections to remove the installation of the Xilinx header files?


Dear Sebastian,

Zynq 7000 is not using them. Rtems-lwip requires some of the headers. I 
provided a patch which added "objxilinxsupport.yml" to the Zynq 7000 
configurations. After a discussion on Discord my patch was rolled back 
(which I think was a good decision).


Chris and Kinsey, please correct me if I misunderstood something, but as 
far as I understood it the headers will be removed from the kernel. 
Afaik, there are some drivers for the ZU require them. Thus, it will 
require some time / planning to overwork the drivers and move the 
required headers to rtems-lwip.


Long story short, Chris and Kinsey should be able to give some more 
detailed information on the strategy and timeline.


Regards







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

[PATCH rtems-lwip] Add C++ include guard

[berndmoessner80]

From: Bernd Moessner 

---
 rtemslwip/include/netstart.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/rtemslwip/include/netstart.h b/rtemslwip/include/netstart.h
index 807183a..82cefce 100644
--- a/rtemslwip/include/netstart.h
+++ b/rtemslwip/include/netstart.h
@@ -30,6 +30,10 @@
 #include 
 #include 
 
+#ifdef __cplusplus
+extern "C" {
+#endif
+
 int start_networking(
   struct netif  *net_interface,
   ip_addr_t *ipaddr,
@@ -40,4 +44,8 @@ int start_networking(
 
 rtems_status_code start_networking_shared(void);
 
+#ifdef __cplusplus
+}
+#endif
+
 #endif
-- 
2.34.1

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

Re: aarch64: -mno-outline-atomics

[Kinsey Moore]

On Mon, Mar 25, 2024 at 3:40 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Hello,
>
> I noticed that the aarch64/xilinx-zynqmp BSPs use -mno-outline-atomics.
> However, we don't have a corresponding multilib for this. So for
> example, the C++ standard library still uses -moutline-atomics. I
> suggest to add this option to a Cortex-A53 specific multilib. See also:
>
> http://devel.rtems.org/ticket/5003
>
> Do we need an ILP32 multilib for Cortex-A53?
>

I agree. I had not considered that the C++ standard library might need
these extra flags as well when I was building support for this BSP. ILP32
would need a Cortex-A53 multilib as well.

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

Xilinx header files installed by BSP

[Sebastian Huber]

Hello,

the BSPs for the Xilinx Zynq/ZynqMP/Versal platforms use code from 
Xilinx. They also install some header files from Xilinx in the top-level 
include directory of the BSP, for example:


sleep.h  xbasic_types.h  xil_assert.h  xil_cache.h  xil_exception.h 
xil_io.h  xil_mem.h  xil_printf.h  xil_smc.h  xil_types.h  xparameters.h 
 xpseudo_asm_gcc.h  xpseudo_asm.h  xreg_cortexa53.h  xstatus.h


This can lead to conflicts if I would like to build software from

https://github.com/Xilinx/embeddedsw

because now some header files are duplicated and available through 
different include paths. Why do we install these header files? I think 
they should be only used internally to build the BSP provided drivers. 
The RTEMS drivers should expose their interfaces not through the Xilinx 
header files.


Any objections to remove the installation of the Xilinx header files?

--
embedded brains GmbH & Co. KG
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

[GCC] RTEMS: Add multilib configuration for aarch64

[Sebastian Huber]

gcc/ChangeLog:

* config.gcc (aarch64-*-rtems*): Add target makefile fragment
t-aarch64-rtems.
* config/aarch64/t-aarch64-rtems: New file.
---
 gcc/config.gcc |  1 +
 gcc/config/aarch64/t-aarch64-rtems | 41 ++
 2 files changed, 42 insertions(+)
 create mode 100644 gcc/config/aarch64/t-aarch64-rtems

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 648b3dc2110..c3b73d05eb7 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -1139,6 +1139,7 @@ aarch64*-*-elf | aarch64*-*-fuchsia* | aarch64*-*-rtems*)
 ;;
aarch64-*-rtems*)
tm_file="${tm_file} aarch64/rtems.h rtems.h"
+   tmake_file="${tmake_file} aarch64/t-aarch64-rtems"
;;
esac
case $target in
diff --git a/gcc/config/aarch64/t-aarch64-rtems 
b/gcc/config/aarch64/t-aarch64-rtems
new file mode 100644
index 000..88e07f54551
--- /dev/null
+++ b/gcc/config/aarch64/t-aarch64-rtems
@@ -0,0 +1,41 @@
+# Machine description for AArch64 architecture.
+#  Copyright (C) 2024 Free Software Foundation, Inc.
+#
+#  This file is part of GCC.
+#
+#  GCC is free software; you can redistribute it and/or modify it
+#  under the terms of the GNU General Public License as published by
+#  the Free Software Foundation; either version 3, or (at your option)
+#  any later version.
+#
+#  GCC is distributed in the hope that it will be useful, but
+#  WITHOUT ANY WARRANTY; without even the implied warranty of
+#  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+#  General Public License for more details.
+#
+#  You should have received a copy of the GNU General Public License
+#  along with GCC; see the file COPYING3.  If not see
+#  .
+
+MULTILIB_OPTIONS  =
+MULTILIB_DIRNAMES =
+
+MULTILIB_OPTIONS  += mabi=ilp32
+MULTILIB_DIRNAMES += ilp32
+
+MULTILIB_OPTIONS  += mno-outline-atomics
+MULTILIB_DIRNAMES += nooa
+
+MULTILIB_OPTIONS  += mcpu=cortex-a53
+MULTILIB_DIRNAMES += a53
+
+MULTILIB_OPTIONS  += mfix-cortex-a53-835769
+MULTILIB_DIRNAMES += fix835769
+
+MULTILIB_OPTIONS  += mfix-cortex-a53-843419
+MULTILIB_DIRNAMES += fix843419
+
+MULTILIB_REQUIRED =
+
+MULTILIB_REQUIRED += mabi=ilp32
+MULTILIB_REQUIRED += 
mno-outline-atomics/mcpu=cortex-a53/mfix-cortex-a53-835769/mfix-cortex-a53-843419
-- 
2.35.3

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

aarch64: -mno-outline-atomics

[Sebastian Huber]

Hello,

I noticed that the aarch64/xilinx-zynqmp BSPs use -mno-outline-atomics. 
However, we don't have a corresponding multilib for this. So for 
example, the C++ standard library still uses -moutline-atomics. I 
suggest to add this option to a Cortex-A53 specific multilib. See also:


http://devel.rtems.org/ticket/5003

Do we need an ILP32 multilib for Cortex-A53?

--
embedded brains GmbH & Co. KG
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: RFC: Add API to get and set interrupt priorities for interrupt vectors

[Sebastian Huber]

On 21.03.24 20:28, Gedare Bloom wrote:

Two basic questions:

Does the priority field type need to be Architecture- or BSP-defined
or is uint32_t always going to be fine.


In theory, the priority range depends on the interrupt controller 
implementation. However, an uint32_t should be more than enough. The 
maximum priority value defines also the maximum interrupt nesting depth. 
So, even 256 interrupt priority levels would be quite a lot.




Does changing (increasing) the priority of a vector from within
interrupt context possibly cause a pending interrupt to post that was
previously at a lower priority than the currently masked priority
level? In that case, it would cause a preemption to occur. I'm
guessing this behavior could be architecture-specific.


This behaviour is entirely interrupt-controller specific. Changing the 
priority while an interrupt is active is usually a bad idea since this 
can confuse the hardware interrupt priority stack. I guess we have to 
add some interrupt-controller specific information to the notes, for 
example:


For the Armv7-M NVIC, there are 256 priority levels supported.  The 
granularity of the priority levels depends on the interrupt controller 
configuration.  Some lower bits of a priority value may be read-as-zero. 
Interrupts with a priority value less than 128 are not disabled by the 
RTEMS interrupt disable directive. Such interrupts shall not use 
operating system services.


For the Arm GICv2, ...

For the Arm GICv3, ...



I added those questions to the ticket also.
Gedare

On Wed, Mar 20, 2024 at 2:59 AM Sebastian Huber
 wrote:


Hello,

I added a ticket for a proposal for an API to get and set interrupt
priorities for interrupt vectors:

https://devel.rtems.org/ticket/5002

I would like to implement this API at least for the BSPs using the
ARM/AArch64 GIC.

--
embedded brains GmbH & Co. KG
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


--
embedded brains GmbH & Co. KG
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 2/3] dev/serial: Add ZYNQ_UART_[01]_BASE_ADDR

[Sebastian Huber]

On 22.03.24 16:10, Kinsey Moore wrote:
Putting these UART addresses in BSP options suggests that they're 
user-configurable when they aren't. ZynqMP can use the ZYNQMP_UART0/1 
from bsps/include/peripheral_maps/xilinx_zynqmp.h, but Zynq would need 
its own peripheral map to reference.


This UART support is used by four BSP families. Currently a lot of copy 
and past is involved. Defining the two UART base addresses though a BSP 
option was the easiest approach I found to do this. I would remove the 
xilinx_zynqmp.h header file since normally you use the xparameters.h for 
your application depending on the system configuration.


--
embedded brains GmbH & Co. KG
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 5/5] bsps: Add xilinx_zynqmp_lp64_a53 BSP variant

[Sebastian Huber]

On 22.03.24 20:57, Gedare Bloom wrote:

In some other architectures we have had "generic" BSP targets. It
would be good to have something following the lp64 part.  I'm not
quite clear on what the purpose of this generic BSP target is here.


For this platform, there is no need for having specific BSPs. The 
customization can be done through BSP options and a device tree. The 
only thing we need are the right compiler options.


--
embedded brains GmbH & Co. KG
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 5/5] bsps: Add xilinx_zynqmp_lp64_a53 BSP variant

[Sebastian Huber]

On 22.03.24 16:48, Kinsey Moore wrote:
This patch looks good. I would suggest dropping the a53 from the BSP 
name since all AArch64 ZynqMP BSPs will run on the A53 cores.


We should keep this name. Maybe Xilinx provides a Zynq variant with 
other cores in the future and for the Cortex-A53 we have to enable some 
errata workarounds:


https://devel.rtems.org/ticket/5003

--
embedded brains GmbH & Co. KG
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 0/1] x86_64: Fix stack aligment for x86-64 SysV ABI

[Matheus Pecoraro]

Thanks! Just for clarification, should I create a new ticket for this
specific bug and then add "Closes #" to the commit message?


On Sat, Mar 23, 2024 at 12:08 PM Joel Sherrill  wrote:

> This is a great explanation. Would you mind filing a ticket with this
> explanatino and referencing the ticket in the commit message of the patch?
>
> When someone wonders about the change in the future, the ticket
> explanation will be useful
>
> On Fri, Mar 22, 2024 at 9:24 PM Matheus Pecoraro 
> wrote:
>
>> I kept getting a general protection fault whenever attempting to
>> execute the amd64 BSP while preparing for my GSOC proposal.
>>
>> The GPF was being caused by an instruction attempting to move an SSE
>> register to an address on the stack not aligned to 16 bytes. After
>> some debugging I noticed that the code for setting up the stack frame
>> for a context would result in it being misaligned by 8 bytes as to
>> what is expected by the x86-64 SysV ABI, thus leading the compiler to
>> unknowingly cause the exception (when control is transferred to the
>> function entry point RSP+8 is supposed to be a multiple of 16, without
>> this patch RSP itself was a multiple of 16).
>>
>> After the fix I was able to run the hello test on the amd64 BSP both
>> while booting through the FreeBSD bootloader with no EFI boot services
>> as well as through GRUB with multiboot2 and EFI boot services.
>>
>> Matheus Pecoraro (1):
>>   x86_64: Fix stack aligment for x86-64 SysV ABI
>>
>>  bsps/x86_64/amd64/clock/eficlock.c| 28 ++-
>>  bsps/x86_64/amd64/start/start.S   |  1 -
>>  .../cpu/x86_64/x86_64-context-initialize.c|  4 +--
>>  3 files changed, 5 insertions(+), 28 deletions(-)
>>
>> --
>> 2.43.0
>> ___
>> 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] mqopen: Add support for 'mode' argument in mq_open

[Abhinav Srivastava]

Fixes #1977: Previously, the 'mode' argument in
`mq_open` was accepted but not utilized.
---
 cpukit/posix/src/mqueueopen.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/cpukit/posix/src/mqueueopen.c b/cpukit/posix/src/mqueueopen.c
index d01421a0c1..8f8c1c8634 100644
--- a/cpukit/posix/src/mqueueopen.c
+++ b/cpukit/posix/src/mqueueopen.c
@@ -154,6 +154,7 @@ mqd_t mq_open(
   POSIX_Message_queue_Control *the_mq;
   size_t   name_len;
   Objects_Get_by_name_errorerror;
+  mode_t   mode;
   mqd_tstatus;
 
   _Objects_Allocator_lock();
@@ -185,6 +186,7 @@ mqd_t mq_open(
 va_start( ap, oflag );
 va_arg( ap, mode_t );
 attr = va_arg( ap, const struct mq_attr * );
+mode = va_arg( ap, mode_t );
 va_end( ap );
 
 if ( attr == NULL ) {
@@ -196,7 +198,7 @@ mqd_t mq_open(
  *  checked. We should go ahead and create a message queue.
  */
 
-status = _POSIX_Message_queue_Create( name, name_len, oflag, attr );
+status = _POSIX_Message_queue_Create( name, name_len, oflag, attr, mode );
   } else {
 
 /*
-- 
2.34.1

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

Re: [PATCH 0/1] x86_64: Fix stack aligment for x86-64 SysV ABI

[Joel Sherrill]

This is a great explanation. Would you mind filing a ticket with this
explanatino and referencing the ticket in the commit message of the patch?

When someone wonders about the change in the future, the ticket explanation
will be useful

On Fri, Mar 22, 2024 at 9:24 PM Matheus Pecoraro  wrote:

> I kept getting a general protection fault whenever attempting to
> execute the amd64 BSP while preparing for my GSOC proposal.
>
> The GPF was being caused by an instruction attempting to move an SSE
> register to an address on the stack not aligned to 16 bytes. After
> some debugging I noticed that the code for setting up the stack frame
> for a context would result in it being misaligned by 8 bytes as to
> what is expected by the x86-64 SysV ABI, thus leading the compiler to
> unknowingly cause the exception (when control is transferred to the
> function entry point RSP+8 is supposed to be a multiple of 16, without
> this patch RSP itself was a multiple of 16).
>
> After the fix I was able to run the hello test on the amd64 BSP both
> while booting through the FreeBSD bootloader with no EFI boot services
> as well as through GRUB with multiboot2 and EFI boot services.
>
> Matheus Pecoraro (1):
>   x86_64: Fix stack aligment for x86-64 SysV ABI
>
>  bsps/x86_64/amd64/clock/eficlock.c| 28 ++-
>  bsps/x86_64/amd64/start/start.S   |  1 -
>  .../cpu/x86_64/x86_64-context-initialize.c|  4 +--
>  3 files changed, 5 insertions(+), 28 deletions(-)
>
> --
> 2.43.0
> ___
> 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 0/1] x86_64: Fix stack aligment for x86-64 SysV ABI

[Matheus Pecoraro]

I kept getting a general protection fault whenever attempting to
execute the amd64 BSP while preparing for my GSOC proposal.

The GPF was being caused by an instruction attempting to move an SSE
register to an address on the stack not aligned to 16 bytes. After
some debugging I noticed that the code for setting up the stack frame
for a context would result in it being misaligned by 8 bytes as to
what is expected by the x86-64 SysV ABI, thus leading the compiler to
unknowingly cause the exception (when control is transferred to the
function entry point RSP+8 is supposed to be a multiple of 16, without
this patch RSP itself was a multiple of 16).

After the fix I was able to run the hello test on the amd64 BSP both
while booting through the FreeBSD bootloader with no EFI boot services
as well as through GRUB with multiboot2 and EFI boot services.

Matheus Pecoraro (1):
  x86_64: Fix stack aligment for x86-64 SysV ABI

 bsps/x86_64/amd64/clock/eficlock.c| 28 ++-
 bsps/x86_64/amd64/start/start.S   |  1 -
 .../cpu/x86_64/x86_64-context-initialize.c|  4 +--
 3 files changed, 5 insertions(+), 28 deletions(-)

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

[PATCH 1/1] x86_64: Fix stack aligment for x86-64 SysV ABI

[Matheus Pecoraro]

Makes the code in bsp/x86_64/amd64/start/start.S and the stack frame
setup by _CPU_Context_Initialize align the stack properly according to
what is expected by the x86-64 SysV ABI
---
 bsps/x86_64/amd64/clock/eficlock.c| 28 ++-
 bsps/x86_64/amd64/start/start.S   |  1 -
 .../cpu/x86_64/x86_64-context-initialize.c|  4 +--
 3 files changed, 5 insertions(+), 28 deletions(-)

diff --git a/bsps/x86_64/amd64/clock/eficlock.c
b/bsps/x86_64/amd64/clock/eficlock.c
index f5ff9278f6..aece19aa35 100644
--- a/bsps/x86_64/amd64/clock/eficlock.c
+++ b/bsps/x86_64/amd64/clock/eficlock.c
@@ -41,35 +41,13 @@ Clock_isr( void* );
 #error "EFIAPI not defined!"
 #endif

-
-/* no-sse attribute helps with enforcing GCC to generate code which
does not use
-   SSE instructions requiring 16 byte alligned access on unaligned data hence
-   producing perfect GP fault. The code with SSE enabled looks:
-
-EFIAPI void
-efi_clock_tick_notify(EFI_EVENT e, VOID* ctx)
-{
-  10b2ba:   55  push   rbp
-  10b2bb:   48 89 e5movrbp,rsp
-  10b2be:   57  push   rdi
-  10b2bf:   56  push   rsi
-  10b2c0:   48 81 ec a0 00 00 00subrsp,0xa0
-  10b2c7:   8b 02   moveax,DWORD PTR [rdx]
-->10b2c9:   0f 29 b5 50 ff ff ffmovaps XMMWORD PTR [rbp-0xb0],xmm6
-  10b2d0:   0f 29 bd 60 ff ff ffmovaps XMMWORD PTR [rbp-0xa0],xmm7
-  10b2d7:   83 c0 01addeax,0x1
-
-and we get GP @ 10b2c9.
-
-CAVEAT: This function is to be called from the UEFI which means it
needs to callable
-by using MS ABI!
-
+/*
+ * CAVEAT: This function is to be called from the UEFI which means it
+ * needs to be callable by using MS ABI!
  */
-__attribute__((target("no-sse")))
 EFIAPI void
 efi_clock_tick_notify(EFI_EVENT e, VOID* ctx);

-__attribute__((target("no-sse")))
 EFIAPI void
 efi_clock_tick_notify(EFI_EVENT e, VOID* ctx)
 {
diff --git a/bsps/x86_64/amd64/start/start.S b/bsps/x86_64/amd64/start/start.S
index b8120473be..f1f2f059b9 100644
--- a/bsps/x86_64/amd64/start/start.S
+++ b/bsps/x86_64/amd64/start/start.S
@@ -40,7 +40,6 @@
 _start:
  .cfi_startproc
  movabsq $_ISR_Stack_area_end, %rsp
- subq $8, %rsp
  .cfi_def_cfa_offset 16
  xorl %edi, %edi
 #ifdef BSP_MULTIBOOT_SUPPORT
diff --git a/cpukit/score/cpu/x86_64/x86_64-context-initialize.c
b/cpukit/score/cpu/x86_64/x86_64-context-initialize.c
index ee25fcfa2d..0df7cff1bc 100644
--- a/cpukit/score/cpu/x86_64/x86_64-context-initialize.c
+++ b/cpukit/score/cpu/x86_64/x86_64-context-initialize.c
@@ -87,8 +87,8 @@ void _CPU_Context_Initialize(

   _stack  = ((uintptr_t) stack_area_begin) + stack_area_size;
   _stack &= ~(CPU_STACK_ALIGNMENT - 1);
-  _stack -= sizeof(uintptr_t); /* fake return address for entry_point's frame;
-* this allows rsp+8 to be an aligned
boundary */
+  _stack -= CPU_STACK_ALIGNMENT; /* fake return address for
entry_point's frame;
+  * this allows rsp+8 to be an
aligned boundary */
   *((void (**)(void)) _stack) = entry_point;

   the_context->rbp = (void *) 0;
-- 
2.43.0
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 5/5] bsps: Add xilinx_zynqmp_lp64_a53 BSP variant

[Gedare Bloom]

In some other architectures we have had "generic" BSP targets. It
would be good to have something following the lp64 part.  I'm not
quite clear on what the purpose of this generic BSP target is here.

On Fri, Mar 22, 2024 at 9:48 AM Kinsey Moore  wrote:
>
> This patch looks good. I would suggest dropping the a53 from the BSP name 
> since all AArch64 ZynqMP BSPs will run on the A53 cores.
>
> Kinsey
>
> On Mon, Mar 18, 2024 at 11:30 AM Sebastian Huber 
>  wrote:
>>
>> Add a BSP variant without a board-specific name.
>> ---
>>  .../bsps/aarch64/xilinx-zynqmp/bspa53lp64.yml | 21 +++
>>  .../bsps/aarch64/xilinx-zynqmp/optloadoff.yml |  1 +
>>  .../bsps/aarch64/xilinx-zynqmp/optramori.yml  |  1 +
>>  spec/build/bsps/objxilinxsupportlp64.yml  |  1 +
>>  spec/build/bsps/optxilsupportpath.yml |  1 +
>>  5 files changed, 25 insertions(+)
>>  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/bspa53lp64.yml
>>
>> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/bspa53lp64.yml 
>> b/spec/build/bsps/aarch64/xilinx-zynqmp/bspa53lp64.yml
>> new file mode 100644
>> index 00..42316db4d3
>> --- /dev/null
>> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/bspa53lp64.yml
>> @@ -0,0 +1,21 @@
>> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>> +arch: aarch64
>> +bsp: xilinx_zynqmp_lp64_a53
>> +build-type: bsp
>> +cflags: []
>> +copyrights:
>> +- Copyright (C) 2024 embedded brains GmbH
>> +cppflags: []
>> +enabled-by: true
>> +family: xilinx-zynqmp
>> +includes: []
>> +install: []
>> +links:
>> +- role: build-dependency
>> +  uid: grp
>> +- role: build-dependency
>> +  uid: linkcmds_lp64
>> +- role: build-dependency
>> +  uid: objfdtzynqmp
>> +source: []
>> +type: build
>> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optloadoff.yml 
>> b/spec/build/bsps/aarch64/xilinx-zynqmp/optloadoff.yml
>> index 869181a95e..3a78b9af38 100644
>> --- a/spec/build/bsps/aarch64/xilinx-zynqmp/optloadoff.yml
>> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optloadoff.yml
>> @@ -9,6 +9,7 @@ copyrights:
>>  - Copyright (C) 2020 On-Line Applications Research (OAR)
>>  default:
>>  - enabled-by:
>> +  - aarch64/xilinx_zynqmp_lp64_a53
>>- aarch64/xilinx_zynqmp_ilp32_zu3eg
>>- aarch64/xilinx_zynqmp_lp64_cfc400x
>>- aarch64/xilinx_zynqmp_lp64_zu3eg
>> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml 
>> b/spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
>> index c4d33094fb..33f0946532 100644
>> --- a/spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
>> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
>> @@ -9,6 +9,7 @@ copyrights:
>>  - Copyright (C) 2020 On-Line Applications Research (OAR)
>>  default:
>>  - enabled-by:
>> +  - aarch64/xilinx_zynqmp_lp64_a53
>>- aarch64/xilinx_zynqmp_ilp32_zu3eg
>>- aarch64/xilinx_zynqmp_lp64_cfc400x
>>- aarch64/xilinx_zynqmp_lp64_zu3eg
>> diff --git a/spec/build/bsps/objxilinxsupportlp64.yml 
>> b/spec/build/bsps/objxilinxsupportlp64.yml
>> index 330ffc34fd..252851a5aa 100644
>> --- a/spec/build/bsps/objxilinxsupportlp64.yml
>> +++ b/spec/build/bsps/objxilinxsupportlp64.yml
>> @@ -7,6 +7,7 @@ cppflags: []
>>  cxxflags: []
>>  enabled-by:
>>  - bsps/aarch64/xilinx_versal
>> +- aarch64/xilinx_zynqmp_lp64_a53
>>  - aarch64/xilinx_zynqmp_lp64_cfc400x
>>  - aarch64/xilinx_zynqmp_lp64_qemu
>>  - aarch64/xilinx_zynqmp_lp64_zu3eg
>> diff --git a/spec/build/bsps/optxilsupportpath.yml 
>> b/spec/build/bsps/optxilsupportpath.yml
>> index 298f9d5286..a90e6d3418 100644
>> --- a/spec/build/bsps/optxilsupportpath.yml
>> +++ b/spec/build/bsps/optxilsupportpath.yml
>> @@ -20,6 +20,7 @@ default:
>>- aarch64/xilinx_zynqmp_ilp32_zu3eg
>>value: arm/ARMv8/32bit
>>  - enabled-by:
>> +  - aarch64/xilinx_zynqmp_lp64_a53
>>- aarch64/xilinx_zynqmp_lp64_cfc400x
>>- aarch64/xilinx_zynqmp_lp64_qemu
>>- aarch64/xilinx_zynqmp_lp64_zu3eg
>> --
>> 2.35.3
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] rtems: Avoid -Wundef warnings in API header

[Gedare Bloom]

ok

On Fri, Mar 22, 2024 at 3:32 AM Sebastian Huber
 wrote:
>
> ---
>  cpukit/include/rtems/score/basedefs.h | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/cpukit/include/rtems/score/basedefs.h 
> b/cpukit/include/rtems/score/basedefs.h
> index 4f28e6a525..010728d795 100644
> --- a/cpukit/include/rtems/score/basedefs.h
> +++ b/cpukit/include/rtems/score/basedefs.h
> @@ -168,9 +168,9 @@ extern "C" {
>   *
>   * @return Returns the alignment requirement of the type.
>   */
> -#if __cplusplus >= 201103L
> +#if defined( __cplusplus ) && __cplusplus >= 201103L
>#define RTEMS_ALIGNOF( _type_name ) alignof( _type_name )
> -#elif __STDC_VERSION__ >= 201112L
> +#elif defined( __STDC_VERSION__ ) && __STDC_VERSION__ >= 201112L
>#define RTEMS_ALIGNOF( _type_name ) _Alignof( _type_name )
>  #else
>#define RTEMS_ALIGNOF( _type_name ) sizeof( _type_name )
> @@ -376,9 +376,9 @@ extern "C" {
>   * @brief Tells the compiler in a function declaration that this function 
> does
>   *   not return.
>   */
> -#if __cplusplus >= 201103L
> +#if defined( __cplusplus ) && __cplusplus >= 201103L
>#define RTEMS_NO_RETURN [[noreturn]]
> -#elif __STDC_VERSION__ >= 201112L
> +#elif defined( __STDC_VERSION__ ) && __STDC_VERSION__ >= 201112L
>#define RTEMS_NO_RETURN _Noreturn
>  #elif defined(__GNUC__)
>#define RTEMS_NO_RETURN __attribute__(( __noreturn__ ))
> @@ -833,9 +833,9 @@ extern "C" {
>   *
>   * @param _msg is the error message in case the static assertion fails.
>   */
> -#if __cplusplus >= 201103L
> +#if defined( __cplusplus ) && __cplusplus >= 201103L
>#define RTEMS_STATIC_ASSERT( _cond, _msg ) static_assert( _cond, # _msg )
> -#elif __STDC_VERSION__ >= 201112L
> +#elif defined( __STDC_VERSION__ ) && __STDC_VERSION__ >= 201112L
>#define RTEMS_STATIC_ASSERT( _cond, _msg ) _Static_assert( _cond, # _msg )
>  #else
>#define RTEMS_STATIC_ASSERT( _cond, _msg ) \
> --
> 2.35.3
>
> ___
> 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] bsp-howto: Document clock driver arg parameter

[Gedare Bloom]

LGTM, thanks!

On Fri, Mar 22, 2024 at 1:11 AM Sebastian Huber
 wrote:
>
> Update #4862.
> ---
>  bsp-howto/clock.rst | 34 ++
>  1 file changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/bsp-howto/clock.rst b/bsp-howto/clock.rst
> index 043083f..ed83472 100644
> --- a/bsp-howto/clock.rst
> +++ b/bsp-howto/clock.rst
> @@ -139,6 +139,9 @@ Simple Timecounter Variant
>
>  For an example see the `ERC32 clock driver
>  `_.
> +The argument parameter of ``Clock_driver_timecounter_tick( arg )`` is the
> +argument used to install the clock interrupt handler.  Device drivers may use
> +this argument to access their control state.
>
>  .. code-block:: c
>
> @@ -165,9 +168,9 @@ For an example see the `ERC32 clock driver
>);
>  }
>
> -static void some_tc_tick( void )
> +static void some_tc_tick( rtems_timecounter_simple *tc )
>  {
> -  rtems_timecounter_simple_downcounter_tick( _tc, some_tc_get );
> +  rtems_timecounter_simple_downcounter_tick( tc, some_tc_get );
>  }
>
>  static void some_support_initialize_hardware( void )
> @@ -193,8 +196,8 @@ For an example see the `ERC32 clock driver
>
>  #define Clock_driver_support_initialize_hardware() \
>some_support_initialize_hardware()
> -#define Clock_driver_timecounter_tick() \
> -  some_tc_tick()
> +#define Clock_driver_timecounter_tick( arg ) \
> +  some_tc_tick( arg )
>
>  #include "../../../shared/dev/clock/clockimpl.h"
>
> @@ -224,15 +227,20 @@ Install Clock Tick Interrupt Service Routine
>  
>
>  The clock driver may provide a function to install the clock tick interrupt
> -service routine via ``Clock_driver_support_install_isr()``.  The clock tick
> -interrupt service routine is passed as the one and only parameter to this
> -macro.  The default implementation will do nothing.
> +service routine via ``Clock_driver_support_install_isr( isr )``.  The clock
> +tick interrupt service routine is passed as the one and only parameter to 
> this
> +macro.  The default implementation will do nothing.  The argument parameter 
> (in
> +the code below ``_instance``) for the installed interrupt handler is
> +available in the ``Clock_driver_support_at_tick( arg )`` and
> +``Clock_driver_support_initialize_hardware( arg )`` customization macros.
>
>  .. code-block:: c
>
>  #include 
>  #include 
>
> +static some_control some_instance;
> +
>  static void some_support_install_isr( rtems_interrupt_handler isr )
>  {
>rtems_status_code sc;
> @@ -241,7 +249,7 @@ macro.  The default implementation will do nothing.
>  "Clock",
>  RTEMS_INTERRUPT_UNIQUE,
>  isr,
> -NULL
> +_instance
>);
>if ( sc != RTEMS_SUCCESSFUL ) {
>  bsp_fatal( SOME_FATAL_IRQ_INSTALL );
> @@ -257,17 +265,19 @@ Support At Tick
>  ===
>
>  The hardware-specific support at tick is specified by
> -``Clock_driver_support_at_tick()``.
> +``Clock_driver_support_at_tick( arg )``.  The ``arg`` is the argument used to
> +install the clock interrupt handler.  Device drivers may use this argument to
> +access their control state.
>
>  .. code-block:: c
>
> -static void some_support_at_tick( void )
> +static void some_support_at_tick( some_control *arg )
>  {
>/* Clear interrupt */
>  }
>
> -#define Clock_driver_support_at_tick() \
> -  some_support_at_tick()
> +#define Clock_driver_support_at_tick( arg ) \
> +  some_support_at_tick( arg )
>
>  #include "../../../shared/dev/clock/clockimpl.h"
>
> --
> 2.35.3
>
> ___
> 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 5/5] bsps: Add xilinx_zynqmp_lp64_a53 BSP variant

[Kinsey Moore]

This patch looks good. I would suggest dropping the a53 from the BSP name
since all AArch64 ZynqMP BSPs will run on the A53 cores.

Kinsey

On Mon, Mar 18, 2024 at 11:30 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Add a BSP variant without a board-specific name.
> ---
>  .../bsps/aarch64/xilinx-zynqmp/bspa53lp64.yml | 21 +++
>  .../bsps/aarch64/xilinx-zynqmp/optloadoff.yml |  1 +
>  .../bsps/aarch64/xilinx-zynqmp/optramori.yml  |  1 +
>  spec/build/bsps/objxilinxsupportlp64.yml  |  1 +
>  spec/build/bsps/optxilsupportpath.yml |  1 +
>  5 files changed, 25 insertions(+)
>  create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/bspa53lp64.yml
>
> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/bspa53lp64.yml
> b/spec/build/bsps/aarch64/xilinx-zynqmp/bspa53lp64.yml
> new file mode 100644
> index 00..42316db4d3
> --- /dev/null
> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/bspa53lp64.yml
> @@ -0,0 +1,21 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +arch: aarch64
> +bsp: xilinx_zynqmp_lp64_a53
> +build-type: bsp
> +cflags: []
> +copyrights:
> +- Copyright (C) 2024 embedded brains GmbH
> +cppflags: []
> +enabled-by: true
> +family: xilinx-zynqmp
> +includes: []
> +install: []
> +links:
> +- role: build-dependency
> +  uid: grp
> +- role: build-dependency
> +  uid: linkcmds_lp64
> +- role: build-dependency
> +  uid: objfdtzynqmp
> +source: []
> +type: build
> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optloadoff.yml
> b/spec/build/bsps/aarch64/xilinx-zynqmp/optloadoff.yml
> index 869181a95e..3a78b9af38 100644
> --- a/spec/build/bsps/aarch64/xilinx-zynqmp/optloadoff.yml
> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optloadoff.yml
> @@ -9,6 +9,7 @@ copyrights:
>  - Copyright (C) 2020 On-Line Applications Research (OAR)
>  default:
>  - enabled-by:
> +  - aarch64/xilinx_zynqmp_lp64_a53
>- aarch64/xilinx_zynqmp_ilp32_zu3eg
>- aarch64/xilinx_zynqmp_lp64_cfc400x
>- aarch64/xilinx_zynqmp_lp64_zu3eg
> diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
> b/spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
> index c4d33094fb..33f0946532 100644
> --- a/spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
> +++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
> @@ -9,6 +9,7 @@ copyrights:
>  - Copyright (C) 2020 On-Line Applications Research (OAR)
>  default:
>  - enabled-by:
> +  - aarch64/xilinx_zynqmp_lp64_a53
>- aarch64/xilinx_zynqmp_ilp32_zu3eg
>- aarch64/xilinx_zynqmp_lp64_cfc400x
>- aarch64/xilinx_zynqmp_lp64_zu3eg
> diff --git a/spec/build/bsps/objxilinxsupportlp64.yml
> b/spec/build/bsps/objxilinxsupportlp64.yml
> index 330ffc34fd..252851a5aa 100644
> --- a/spec/build/bsps/objxilinxsupportlp64.yml
> +++ b/spec/build/bsps/objxilinxsupportlp64.yml
> @@ -7,6 +7,7 @@ cppflags: []
>  cxxflags: []
>  enabled-by:
>  - bsps/aarch64/xilinx_versal
> +- aarch64/xilinx_zynqmp_lp64_a53
>  - aarch64/xilinx_zynqmp_lp64_cfc400x
>  - aarch64/xilinx_zynqmp_lp64_qemu
>  - aarch64/xilinx_zynqmp_lp64_zu3eg
> diff --git a/spec/build/bsps/optxilsupportpath.yml
> b/spec/build/bsps/optxilsupportpath.yml
> index 298f9d5286..a90e6d3418 100644
> --- a/spec/build/bsps/optxilsupportpath.yml
> +++ b/spec/build/bsps/optxilsupportpath.yml
> @@ -20,6 +20,7 @@ default:
>- aarch64/xilinx_zynqmp_ilp32_zu3eg
>value: arm/ARMv8/32bit
>  - enabled-by:
> +  - aarch64/xilinx_zynqmp_lp64_a53
>- aarch64/xilinx_zynqmp_lp64_cfc400x
>- aarch64/xilinx_zynqmp_lp64_qemu
>- aarch64/xilinx_zynqmp_lp64_zu3eg
> --
> 2.35.3
>
> ___
> 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 4/5] bsps: Add xilinx_zynq_rpu BSP variant

[Kinsey Moore]

This patch looks good.

Kinsey

On Mon, Mar 18, 2024 at 11:30 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Add a BSP variant without a board-specific name.
> ---
>  .../arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml   | 87 +--
>  .../bsps/arm/xilinx-zynqmp-rpu/bsprpu.yml | 17 
>  spec/build/bsps/arm/xilinx-zynqmp-rpu/grp.yml | 69 +++
>  spec/build/bsps/arm/xilinx-zynqmp-rpu/obj.yml | 42 +
>  4 files changed, 132 insertions(+), 83 deletions(-)
>  create mode 100644 spec/build/bsps/arm/xilinx-zynqmp-rpu/bsprpu.yml
>  create mode 100644 spec/build/bsps/arm/xilinx-zynqmp-rpu/grp.yml
>  create mode 100644 spec/build/bsps/arm/xilinx-zynqmp-rpu/obj.yml
>
> diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
> b/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
> index 3fa210d8e7..f6c228c79d 100644
> --- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
> +++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
> @@ -8,89 +8,10 @@ copyrights:
>  cppflags: []
>  enabled-by: true
>  family: xilinx-zynqmp-rpu
> -includes:
> -- bsps/include/xil/
> -- bsps/include/xil/${XIL_SUPPORT_PATH}/
> -install:
> -- destination: ${BSP_INCLUDEDIR}
> -  source:
> -  - bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
> -- destination: ${BSP_INCLUDEDIR}/bsp
> -  source:
> -  - bsps/arm/xilinx-zynqmp-rpu/include/bsp/irq.h
> -- destination: ${BSP_INCLUDEDIR}/peripheral_maps
> -  source:
> -  - bsps/include/peripheral_maps/xilinx_zynqmp.h
> +includes: []
> +install: []
>  links:
>  - role: build-dependency
> -  uid: ../grp
> -- role: build-dependency
> -  uid: ../start
> -- role: build-dependency
> -  uid: abi
> -- role: build-dependency
> -  uid: optclkfastidle
> -- role: build-dependency
> -  uid: optclkuart
> -- role: build-dependency
> -  uid: optconirq
> -- role: build-dependency
> -  uid: ../../optconminor
> -- role: build-dependency
> -  uid: optint0len
> -- role: build-dependency
> -  uid: optint0ori
> -- role: build-dependency
> -  uid: optint1len
> -- role: build-dependency
> -  uid: optint1ori
> -- role: build-dependency
> -  uid: optramlen
> -- role: build-dependency
> -  uid: optramori
> -- role: build-dependency
> -  uid: optresetvec
> -- role: build-dependency
> -  uid: optnocachelen
> -- role: build-dependency
> -  uid: ../../obj
> -- role: build-dependency
> -  uid: ../../objirq
> -- role: build-dependency
> -  uid: ../../objdevserialzynq
> -- role: build-dependency
> -  uid: ../../objdevspizynq
> -- role: build-dependency
> -  uid: ../../objdevspixil
> -- role: build-dependency
> -  uid: ../../objmem
> -- role: build-dependency
> -  uid: ../../opto0
> -- role: build-dependency
> -  uid: linkcmds
> -- role: build-dependency
> -  uid: ../../bspopts
> -- role: build-dependency
> -  uid: ../../objxilinxsupport
> -source:
> -- bsps/shared/cache/nocache.c
> -- bsps/arm/shared/cp15/arm-cp15-set-exception-handler.c
> -- bsps/arm/shared/cp15/arm-cp15-set-ttb-entries.c
> -- bsps/arm/shared/start/bsp-start-memcpy.S
> -- bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
> -- bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c
> -- bsps/arm/xilinx-zynqmp-rpu/start/bspstart.c
> -- bsps/arm/xilinx-zynqmp-rpu/start/bspstarthooks.c
> -- bsps/arm/xilinx-zynqmp-rpu/start/bspstartmpu.c
> -- bsps/shared/dev/clock/xil-ttc.c
> -- bsps/shared/dev/btimer/btimer-cpucounter.c
> -- bsps/shared/dev/getentropy/getentropy-cpucounter.c
> -- bsps/shared/dev/irq/arm-gicv2.c
> -- bsps/shared/dev/irq/arm-gicv2-zynqmp.c
> -- bsps/shared/dev/serial/console-termios.c
> -- bsps/shared/irq/irq-default-handler.c
> -- bsps/shared/start/bspfatal-default.c
> -- bsps/shared/start/gettargethash-default.c
> -- bsps/shared/start/sbrk.c
> -- bsps/shared/start/stackalloc.c
> +  uid: grp
> +source: []
>  type: build
> diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/bsprpu.yml
> b/spec/build/bsps/arm/xilinx-zynqmp-rpu/bsprpu.yml
> new file mode 100644
> index 00..d4073d8248
> --- /dev/null
> +++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/bsprpu.yml
> @@ -0,0 +1,17 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +arch: arm
> +bsp: xilinx_zynqmp_rpu
> +build-type: bsp
> +cflags: []
> +copyrights:
> +- Copyright (C) 2024 embedded brains GmbH
> +cppflags: []
> +enabled-by: true
> +family: xilinx-zynqmp-rpu
> +includes: []
> +install: []
> +links:
> +- role: build-dependency
> +  uid: grp
> +source: []
> +type: build
> diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/grp.yml
> b/spec/build/bsps/arm/xilinx-zynqmp-rpu/grp.yml
> new file mode 100644
> index 00..b886948d47
> --- /dev/null
> +++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/grp.yml
> @@ -0,0 +1,69 @@
> +SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> +build-type: group
> +cflags: []
> +copyrights:
> +- Copyright (C) 2023 Reflex Aerospace GmbH
> +cppflags: []
> +cxxflags: []
> +enabled-by: true
> +includes:
> +- bsps/include/xil
> +- bsps/include/xil/${XIL_SUPPORT_PATH}
> +install: []
> +ldflags: []
> 

Re: [PATCH 2/5] bsps: Use bsps/arm/xilinx-zynqmp-rpu

[Kinsey Moore]

This patch looks good.

Kinsey

On Mon, Mar 18, 2024 at 11:30 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> ---
>  spec/build/bsps/objxilinxsupportr5.yml | 3 +--
>  spec/build/bsps/optxilsupportpath.yml  | 2 +-
>  2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/spec/build/bsps/objxilinxsupportr5.yml
> b/spec/build/bsps/objxilinxsupportr5.yml
> index d800b83247..25221c5e0d 100644
> --- a/spec/build/bsps/objxilinxsupportr5.yml
> +++ b/spec/build/bsps/objxilinxsupportr5.yml
> @@ -5,8 +5,7 @@ copyrights:
>  - Copyright (C) 2022 On-Line Applications Research (OAR)
>  cppflags: []
>  cxxflags: []
> -enabled-by:
> -- arm/xilinx_zynqmp_mercuryxu5_rpu
> +enabled-by: bsps/arm/xilinx-zynqmp-rpu
>  includes: []
>  install:
>  - destination: ${BSP_INCLUDEDIR}
> diff --git a/spec/build/bsps/optxilsupportpath.yml
> b/spec/build/bsps/optxilsupportpath.yml
> index 85bcc7e059..298f9d5286 100644
> --- a/spec/build/bsps/optxilsupportpath.yml
> +++ b/spec/build/bsps/optxilsupportpath.yml
> @@ -7,7 +7,7 @@ copyrights:
>  - Copyright (C) 2022 On-Line Applications Research (OAR)
>  default:
>  - enabled-by:
> -  - arm/xilinx_zynqmp_mercuryxu5_rpu
> +  - bsps/arm/xilinx-zynqmp-rpu
>value: arm/cortexr5
>  - enabled-by: bsps/microblaze/microblaze_fpga
>value: microblaze
> --
> 2.35.3
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

[PATCH] rtems: Avoid -Wundef warnings in API header

[Sebastian Huber]

---
 cpukit/include/rtems/score/basedefs.h | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/cpukit/include/rtems/score/basedefs.h 
b/cpukit/include/rtems/score/basedefs.h
index 4f28e6a525..010728d795 100644
--- a/cpukit/include/rtems/score/basedefs.h
+++ b/cpukit/include/rtems/score/basedefs.h
@@ -168,9 +168,9 @@ extern "C" {
  *
  * @return Returns the alignment requirement of the type.
  */
-#if __cplusplus >= 201103L
+#if defined( __cplusplus ) && __cplusplus >= 201103L
   #define RTEMS_ALIGNOF( _type_name ) alignof( _type_name )
-#elif __STDC_VERSION__ >= 201112L
+#elif defined( __STDC_VERSION__ ) && __STDC_VERSION__ >= 201112L
   #define RTEMS_ALIGNOF( _type_name ) _Alignof( _type_name )
 #else
   #define RTEMS_ALIGNOF( _type_name ) sizeof( _type_name )
@@ -376,9 +376,9 @@ extern "C" {
  * @brief Tells the compiler in a function declaration that this function does
  *   not return.
  */
-#if __cplusplus >= 201103L
+#if defined( __cplusplus ) && __cplusplus >= 201103L
   #define RTEMS_NO_RETURN [[noreturn]]
-#elif __STDC_VERSION__ >= 201112L
+#elif defined( __STDC_VERSION__ ) && __STDC_VERSION__ >= 201112L
   #define RTEMS_NO_RETURN _Noreturn
 #elif defined(__GNUC__)
   #define RTEMS_NO_RETURN __attribute__(( __noreturn__ ))
@@ -833,9 +833,9 @@ extern "C" {
  *
  * @param _msg is the error message in case the static assertion fails.
  */
-#if __cplusplus >= 201103L
+#if defined( __cplusplus ) && __cplusplus >= 201103L
   #define RTEMS_STATIC_ASSERT( _cond, _msg ) static_assert( _cond, # _msg )
-#elif __STDC_VERSION__ >= 201112L
+#elif defined( __STDC_VERSION__ ) && __STDC_VERSION__ >= 201112L
   #define RTEMS_STATIC_ASSERT( _cond, _msg ) _Static_assert( _cond, # _msg )
 #else
   #define RTEMS_STATIC_ASSERT( _cond, _msg ) \
-- 
2.35.3

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

[PATCH 1/3] dev/serial: Simplify some Zynq UART functions

[Sebastian Huber]

Make the initialization and polled functions independent of the Termios
context.  This helps to implement the kernel I/O support without a dependency
on the Termios framework.
---
 bsps/aarch64/xilinx-zynqmp/console/console.c  | 23 ---
 bsps/arm/xilinx-zynq/console/debug-console.c  | 15 ++
 .../console/console-config.c  | 23 ---
 .../xilinx-zynqmp/console/console-config.c| 23 ---
 bsps/include/dev/serial/zynq-uart-regs.h  | 20 +
 bsps/include/dev/serial/zynq-uart.h   | 23 ---
 bsps/shared/dev/serial/zynq-uart-polled.c | 28 ++-
 bsps/shared/dev/serial/zynq-uart.c| 18 
 8 files changed, 62 insertions(+), 111 deletions(-)

diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c 
b/bsps/aarch64/xilinx-zynqmp/console/console.c
index 9ce0b1da63..1e5df997e8 100644
--- a/bsps/aarch64/xilinx-zynqmp/console/console.c
+++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
@@ -45,6 +45,7 @@
 #include 
 
 #include 
+#include 
 
 #include 
 #include 
@@ -236,42 +237,30 @@ rtems_status_code console_initialize(
 
 void zynqmp_debug_console_flush(void)
 {
-  zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
+  zynq_uart_reset_tx_flush(zynqmp_uart_instances[BSP_CONSOLE_MINOR].regs);
 }
 
 static void zynqmp_debug_console_out(char c)
 {
-  rtems_termios_device_context *base =
-_uart_instances[BSP_CONSOLE_MINOR].base;
-
-  zynq_uart_write_polled(base, c);
+  zynq_uart_write_char_polled(zynqmp_uart_instances[BSP_CONSOLE_MINOR].regs, 
c);
 }
 
 static void zynqmp_debug_console_init(void)
 {
-  rtems_termios_device_context *base =
-_uart_instances[BSP_CONSOLE_MINOR].base;
-
-  zynq_uart_initialize(base);
+  zynq_uart_initialize(zynqmp_uart_instances[BSP_CONSOLE_MINOR].regs);
   BSP_output_char = zynqmp_debug_console_out;
 }
 
 static void zynqmp_debug_console_early_init(char c)
 {
-  rtems_termios_device_context *base =
-_uart_instances[BSP_CONSOLE_MINOR].base;
-
-  zynq_uart_initialize(base);
+  zynq_uart_initialize(zynqmp_uart_instances[BSP_CONSOLE_MINOR].regs);
   BSP_output_char = zynqmp_debug_console_out;
   zynqmp_debug_console_out(c);
 }
 
 static int zynqmp_debug_console_in(void)
 {
-  rtems_termios_device_context *base =
-_uart_instances[BSP_CONSOLE_MINOR].base;
-
-  return zynq_uart_read_polled(base);
+  return 
zynq_uart_read_char_polled(zynqmp_uart_instances[BSP_CONSOLE_MINOR].regs);
 }
 
 BSP_output_char_function_type BSP_output_char = 
zynqmp_debug_console_early_init;
diff --git a/bsps/arm/xilinx-zynq/console/debug-console.c 
b/bsps/arm/xilinx-zynq/console/debug-console.c
index d398ca7988..4c636038af 100644
--- a/bsps/arm/xilinx-zynq/console/debug-console.c
+++ b/bsps/arm/xilinx-zynq/console/debug-console.c
@@ -44,24 +44,18 @@
 
 static void zynq_debug_console_out(char c)
 {
-  rtems_termios_device_context *base =
-_uart_instances[BSP_CONSOLE_MINOR].base;
-
-  zynq_uart_write_polled(base, c);
+  zynq_uart_write_char_polled(zynq_uart_instances[BSP_CONSOLE_MINOR].regs, c);
 }
 
 static void zynq_debug_console_early_init(char c);
 
 static void zynq_debug_console_init(void)
 {
-  rtems_termios_device_context *base =
-_uart_instances[BSP_CONSOLE_MINOR].base;
-
   if (BSP_output_char != zynq_debug_console_early_init) {
 return;
   }
 
-  zynq_uart_initialize(base);
+  zynq_uart_initialize(zynq_uart_instances[BSP_CONSOLE_MINOR].regs);
   BSP_output_char = zynq_debug_console_out;
 }
 
@@ -73,10 +67,7 @@ static void zynq_debug_console_early_init(char c)
 
 static int zynq_debug_console_in(void)
 {
-  rtems_termios_device_context *base =
-_uart_instances[BSP_CONSOLE_MINOR].base;
-
-  return zynq_uart_read_polled(base);
+  return 
zynq_uart_read_char_polled(zynq_uart_instances[BSP_CONSOLE_MINOR].regs);
 }
 
 BSP_output_char_function_type BSP_output_char = zynq_debug_console_early_init;
diff --git a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c 
b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
index f52e008f2b..eacf6ddcce 100644
--- a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
+++ b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
@@ -37,6 +37,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -81,41 +82,29 @@ rtems_status_code console_initialize(
 
 void zynqmp_debug_console_flush(void)
 {
-  zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
+  zynq_uart_reset_tx_flush(zynqmp_uart_instances[BSP_CONSOLE_MINOR].regs);
 }
 
 static void zynqmp_debug_console_out(char c)
 {
-  rtems_termios_device_context *base =
-_uart_instances[BSP_CONSOLE_MINOR].base;
-
-  zynq_uart_write_polled(base, c);
+  zynq_uart_write_char_polled(zynqmp_uart_instances[BSP_CONSOLE_MINOR].regs, 
c);
 }
 
 static void zynqmp_debug_console_init(void)
 {
-  rtems_termios_device_context *base =
-_uart_instances[BSP_CONSOLE_MINOR].base;
-
-  zynq_uart_initialize(base);
+  

[PATCH 3/3] dev/serial: Add Zynq UART kernel I/O support

[Sebastian Huber]

Replace the BSP_CONSOLE_MINOR BSP option for the Xilinx Zynq BSPs with the new
BSP option ZYNQ_UART_KERNEL_IO_BASE_ADDR.  Move the kernel I/O support to a
shared file.
---
 bsps/aarch64/xilinx-zynqmp/console/console.c  | 41 ++
 bsps/arm/xilinx-zynq/console/console-config.c | 50 -
 bsps/arm/xilinx-zynq/console/console-init.c   | 20 ++-
 bsps/arm/xilinx-zynq/include/bsp.h|  3 --
 bsps/arm/xilinx-zynq/start/bspreset.c |  6 ++-
 .../console/console-config.c  | 40 ++
 .../xilinx-zynqmp/console/console-config.c| 40 ++
 .../dev/serial/zynq-uart-kernel-io.c} | 53 +++
 spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml |  2 -
 spec/build/bsps/arm/xilinx-zynq/grp.yml   |  2 -
 spec/build/bsps/arm/xilinx-zynq/obj.yml   |  2 -
 spec/build/bsps/arm/xilinx-zynqmp-rpu/grp.yml |  2 -
 .../arm/xilinx-zynqmp/bspxilinxzynqmp.yml |  2 -
 spec/build/bsps/objdevserialzynq.yml  |  3 ++
 spec/build/bsps/optconminor.yml   | 21 
 spec/build/bsps/optzynquartkernbase.yml   | 22 
 16 files changed, 89 insertions(+), 220 deletions(-)
 delete mode 100644 bsps/arm/xilinx-zynq/console/console-config.c
 rename bsps/{arm/xilinx-zynq/console/debug-console.c => 
shared/dev/serial/zynq-uart-kernel-io.c} (60%)
 delete mode 100644 spec/build/bsps/optconminor.yml
 create mode 100644 spec/build/bsps/optzynquartkernbase.yml

diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c 
b/bsps/aarch64/xilinx-zynqmp/console/console.c
index ce031a914e..4023d5c6f3 100644
--- a/bsps/aarch64/xilinx-zynqmp/console/console.c
+++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
@@ -35,7 +35,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -208,6 +207,7 @@ rtems_status_code console_initialize(
   rtems_termios_initialize();
 
   for (i = 0; i < RTEMS_ARRAY_SIZE(zynqmp_uart_instances); ++i) {
+zynq_uart_context *ctx = _uart_instances[i];
 char uart[] = "/dev/ttySX";
 
 uart[sizeof(uart) - 2] = (char) ('0' + i);
@@ -215,10 +215,10 @@ rtems_status_code console_initialize(
   [0],
   _uart_handler,
   NULL,
-  _uart_instances[i].base
+  >base
 );
 
-if (i == BSP_CONSOLE_MINOR) {
+if (ctx->regs == (zynq_uart *) ZYNQ_UART_KERNEL_IO_BASE_ADDR) {
   link([0], CONSOLE_DEVICE_NAME);
 }
   }
@@ -237,38 +237,5 @@ rtems_status_code console_initialize(
 
 void zynqmp_debug_console_flush(void)
 {
-  zynq_uart_reset_tx_flush(zynqmp_uart_instances[BSP_CONSOLE_MINOR].regs);
+  zynq_uart_reset_tx_flush((zynq_uart *) ZYNQ_UART_KERNEL_IO_BASE_ADDR);
 }
-
-static void zynqmp_debug_console_out(char c)
-{
-  zynq_uart_write_char_polled(zynqmp_uart_instances[BSP_CONSOLE_MINOR].regs, 
c);
-}
-
-static void zynqmp_debug_console_init(void)
-{
-  zynq_uart_initialize(zynqmp_uart_instances[BSP_CONSOLE_MINOR].regs);
-  BSP_output_char = zynqmp_debug_console_out;
-}
-
-static void zynqmp_debug_console_early_init(char c)
-{
-  zynq_uart_initialize(zynqmp_uart_instances[BSP_CONSOLE_MINOR].regs);
-  BSP_output_char = zynqmp_debug_console_out;
-  zynqmp_debug_console_out(c);
-}
-
-static int zynqmp_debug_console_in(void)
-{
-  return 
zynq_uart_read_char_polled(zynqmp_uart_instances[BSP_CONSOLE_MINOR].regs);
-}
-
-BSP_output_char_function_type BSP_output_char = 
zynqmp_debug_console_early_init;
-
-BSP_polling_getchar_function_type BSP_poll_char = zynqmp_debug_console_in;
-
-RTEMS_SYSINIT_ITEM(
-  zynqmp_debug_console_init,
-  RTEMS_SYSINIT_BSP_START,
-  RTEMS_SYSINIT_ORDER_LAST_BUT_5
-);
diff --git a/bsps/arm/xilinx-zynq/console/console-config.c 
b/bsps/arm/xilinx-zynq/console/console-config.c
deleted file mode 100644
index 42e64ee4dd..00
--- a/bsps/arm/xilinx-zynq/console/console-config.c
+++ /dev/null
@@ -1,50 +0,0 @@
-/* SPDX-License-Identifier: BSD-2-Clause */
-
-/**
- * @file
- *
- * @ingroup RTEMSBSPsARMZynq
- *
- * @brief This source file contains the definition of ::zynq_uart_instances.
- */
-
-/*
- * Copyright (C) 2013, 2017 embedded brains GmbH & Co. KG
- *
- * 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, 

[PATCH 2/3] dev/serial: Add ZYNQ_UART_[01]_BASE_ADDR

[Sebastian Huber]

This helps to provide a shared implementation of the kernel I/O support.
---
 bsps/aarch64/xilinx-zynqmp/console/console.c  |  4 ++--
 bsps/arm/xilinx-zynq/console/console-config.c |  5 +++--
 .../console/console-config.c  |  4 ++--
 .../xilinx-zynqmp/console/console-config.c|  4 ++--
 spec/build/bsps/objdevserialzynq.yml  |  6 +-
 spec/build/bsps/optzynquart0base.yml  | 19 +++
 spec/build/bsps/optzynquart1base.yml  | 19 +++
 7 files changed, 52 insertions(+), 9 deletions(-)
 create mode 100644 spec/build/bsps/optzynquart0base.yml
 create mode 100644 spec/build/bsps/optzynquart1base.yml

diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c 
b/bsps/aarch64/xilinx-zynqmp/console/console.c
index 1e5df997e8..ce031a914e 100644
--- a/bsps/aarch64/xilinx-zynqmp/console/console.c
+++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
@@ -188,11 +188,11 @@ RTEMS_SYSINIT_ITEM(
 static zynq_uart_context zynqmp_uart_instances[2] = {
   {
 .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 0" ),
-.regs = (volatile struct zynq_uart *) 0xff00,
+.regs = (volatile zynq_uart *) ZYNQ_UART_0_BASE_ADDR,
 .irq = ZYNQMP_IRQ_UART_0
   }, {
 .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 1" ),
-.regs = (volatile struct zynq_uart *) 0xff01,
+.regs = (volatile zynq_uart *) ZYNQ_UART_1_BASE_ADDR,
 .irq = ZYNQMP_IRQ_UART_1
   }
 };
diff --git a/bsps/arm/xilinx-zynq/console/console-config.c 
b/bsps/arm/xilinx-zynq/console/console-config.c
index d22ceb557d..42e64ee4dd 100644
--- a/bsps/arm/xilinx-zynq/console/console-config.c
+++ b/bsps/arm/xilinx-zynq/console/console-config.c
@@ -35,15 +35,16 @@
 
 #include 
 #include 
+#include 
 
 zynq_uart_context zynq_uart_instances[2] = {
   {
 .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 0" ),
-.regs = (volatile struct zynq_uart *) 0xe000,
+.regs = (volatile zynq_uart *) ZYNQ_UART_0_BASE_ADDR,
 .irq = ZYNQ_IRQ_UART_0
   }, {
 .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 1" ),
-.regs = (volatile struct zynq_uart *) 0xe0001000,
+.regs = (volatile zynq_uart *) ZYNQ_UART_1_BASE_ADDR,
 .irq = ZYNQ_IRQ_UART_1
   }
 };
diff --git a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c 
b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
index eacf6ddcce..13eaa269c5 100644
--- a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
+++ b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
@@ -44,11 +44,11 @@
 static zynq_uart_context zynqmp_uart_instances[2] = {
   {
 .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 0" ),
-.regs = (volatile struct zynq_uart *) 0xff00,
+.regs = (volatile zynq_uart *) ZYNQ_UART_0_BASE_ADDR,
 .irq = ZYNQMP_IRQ_UART_0
   }, {
 .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 1" ),
-.regs = (volatile struct zynq_uart *) 0xff01,
+.regs = (volatile zynq_uart *) ZYNQ_UART_1_BASE_ADDR,
 .irq = ZYNQMP_IRQ_UART_1
   }
 };
diff --git a/bsps/arm/xilinx-zynqmp/console/console-config.c 
b/bsps/arm/xilinx-zynqmp/console/console-config.c
index ea148836a5..787ee05dd6 100644
--- a/bsps/arm/xilinx-zynqmp/console/console-config.c
+++ b/bsps/arm/xilinx-zynqmp/console/console-config.c
@@ -44,11 +44,11 @@
 static zynq_uart_context zynqmp_uart_instances[2] = {
   {
 .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 0" ),
-.regs = (volatile struct zynq_uart *) 0xff00,
+.regs = (volatile struct zynq_uart *) ZYNQ_UART_0_BASE_ADDR,
 .irq = ZYNQMP_IRQ_UART_0
   }, {
 .base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 1" ),
-.regs = (volatile struct zynq_uart *) 0xff01,
+.regs = (volatile struct zynq_uart *) ZYNQ_UART_1_BASE_ADDR,
 .irq = ZYNQMP_IRQ_UART_1
   }
 };
diff --git a/spec/build/bsps/objdevserialzynq.yml 
b/spec/build/bsps/objdevserialzynq.yml
index deb3c83a33..ec61f7f545 100644
--- a/spec/build/bsps/objdevserialzynq.yml
+++ b/spec/build/bsps/objdevserialzynq.yml
@@ -12,7 +12,11 @@ install:
   source:
   - bsps/include/dev/serial/zynq-uart-regs.h
   - bsps/include/dev/serial/zynq-uart.h
-links: []
+links:
+- role: build-dependency
+  uid: optzynquart0base
+- role: build-dependency
+  uid: optzynquart1base
 source:
 - bsps/shared/dev/serial/zynq-uart-polled.c
 - bsps/shared/dev/serial/zynq-uart.c
diff --git a/spec/build/bsps/optzynquart0base.yml 
b/spec/build/bsps/optzynquart0base.yml
new file mode 100644
index 00..1da4e2d1ea
--- /dev/null
+++ b/spec/build/bsps/optzynquart0base.yml
@@ -0,0 +1,19 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+actions:
+- get-integer: null
+- format-and-define: null
+build-type: option
+copyrights:
+- Copyright (C) 2024 embedded brains GmbH & Co. KG
+default:
+- enabled-by: bsps/arm/xilinx-zynq
+  value: 0xe000
+- enabled-by: true
+  value: 0xff00
+description: |
+  This option defines the Xilinx Zynq 

[PATCH 0/3] Add shared Zynq UART kernel I/O support

[Sebastian Huber]

Sebastian Huber (3):
  dev/serial: Simplify some Zynq UART functions
  dev/serial: Add ZYNQ_UART_[01]_BASE_ADDR
  dev/serial: Add Zynq UART kernel I/O support

 bsps/aarch64/xilinx-zynqmp/console/console.c  | 58 +++
 bsps/arm/xilinx-zynq/console/console-config.c | 49 
 bsps/arm/xilinx-zynq/console/console-init.c   | 20 ++-
 bsps/arm/xilinx-zynq/include/bsp.h|  3 -
 bsps/arm/xilinx-zynq/start/bspreset.c |  6 +-
 .../console/console-config.c  | 57 +++---
 .../xilinx-zynqmp/console/console-config.c| 57 +++---
 bsps/include/dev/serial/zynq-uart-regs.h  | 20 +++
 bsps/include/dev/serial/zynq-uart.h   | 23 
 .../dev/serial/zynq-uart-kernel-io.c} | 58 +--
 bsps/shared/dev/serial/zynq-uart-polled.c | 28 +++--
 bsps/shared/dev/serial/zynq-uart.c| 18 --
 spec/build/bsps/aarch64/xilinx-zynqmp/grp.yml |  2 -
 spec/build/bsps/arm/xilinx-zynq/grp.yml   |  2 -
 spec/build/bsps/arm/xilinx-zynq/obj.yml   |  2 -
 spec/build/bsps/arm/xilinx-zynqmp-rpu/grp.yml |  2 -
 .../arm/xilinx-zynqmp/bspxilinxzynqmp.yml |  2 -
 spec/build/bsps/objdevserialzynq.yml  |  9 ++-
 spec/build/bsps/optconminor.yml   | 21 ---
 spec/build/bsps/optzynquart0base.yml  | 19 ++
 spec/build/bsps/optzynquart1base.yml  | 19 ++
 spec/build/bsps/optzynquartkernbase.yml   | 22 +++
 22 files changed, 180 insertions(+), 317 deletions(-)
 delete mode 100644 bsps/arm/xilinx-zynq/console/console-config.c
 rename bsps/{arm/xilinx-zynq/console/debug-console.c => 
shared/dev/serial/zynq-uart-kernel-io.c} (61%)
 delete mode 100644 spec/build/bsps/optconminor.yml
 create mode 100644 spec/build/bsps/optzynquart0base.yml
 create mode 100644 spec/build/bsps/optzynquart1base.yml
 create mode 100644 spec/build/bsps/optzynquartkernbase.yml

-- 
2.35.3

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

[PATCH] bsp-howto: Document clock driver arg parameter

[Sebastian Huber]

Update #4862.
---
 bsp-howto/clock.rst | 34 ++
 1 file changed, 22 insertions(+), 12 deletions(-)

diff --git a/bsp-howto/clock.rst b/bsp-howto/clock.rst
index 043083f..ed83472 100644
--- a/bsp-howto/clock.rst
+++ b/bsp-howto/clock.rst
@@ -139,6 +139,9 @@ Simple Timecounter Variant
 
 For an example see the `ERC32 clock driver
 `_.
+The argument parameter of ``Clock_driver_timecounter_tick( arg )`` is the
+argument used to install the clock interrupt handler.  Device drivers may use
+this argument to access their control state.
 
 .. code-block:: c
 
@@ -165,9 +168,9 @@ For an example see the `ERC32 clock driver
   );
 }
 
-static void some_tc_tick( void )
+static void some_tc_tick( rtems_timecounter_simple *tc )
 {
-  rtems_timecounter_simple_downcounter_tick( _tc, some_tc_get );
+  rtems_timecounter_simple_downcounter_tick( tc, some_tc_get );
 }
 
 static void some_support_initialize_hardware( void )
@@ -193,8 +196,8 @@ For an example see the `ERC32 clock driver
 
 #define Clock_driver_support_initialize_hardware() \
   some_support_initialize_hardware()
-#define Clock_driver_timecounter_tick() \
-  some_tc_tick()
+#define Clock_driver_timecounter_tick( arg ) \
+  some_tc_tick( arg )
 
 #include "../../../shared/dev/clock/clockimpl.h"
 
@@ -224,15 +227,20 @@ Install Clock Tick Interrupt Service Routine
 
 
 The clock driver may provide a function to install the clock tick interrupt
-service routine via ``Clock_driver_support_install_isr()``.  The clock tick
-interrupt service routine is passed as the one and only parameter to this
-macro.  The default implementation will do nothing.
+service routine via ``Clock_driver_support_install_isr( isr )``.  The clock
+tick interrupt service routine is passed as the one and only parameter to this
+macro.  The default implementation will do nothing.  The argument parameter (in
+the code below ``_instance``) for the installed interrupt handler is
+available in the ``Clock_driver_support_at_tick( arg )`` and
+``Clock_driver_support_initialize_hardware( arg )`` customization macros.
 
 .. code-block:: c
 
 #include 
 #include 
 
+static some_control some_instance;
+
 static void some_support_install_isr( rtems_interrupt_handler isr )
 {
   rtems_status_code sc;
@@ -241,7 +249,7 @@ macro.  The default implementation will do nothing.
 "Clock",
 RTEMS_INTERRUPT_UNIQUE,
 isr,
-NULL
+_instance
   );
   if ( sc != RTEMS_SUCCESSFUL ) {
 bsp_fatal( SOME_FATAL_IRQ_INSTALL );
@@ -257,17 +265,19 @@ Support At Tick
 ===
 
 The hardware-specific support at tick is specified by
-``Clock_driver_support_at_tick()``.
+``Clock_driver_support_at_tick( arg )``.  The ``arg`` is the argument used to
+install the clock interrupt handler.  Device drivers may use this argument to
+access their control state.
 
 .. code-block:: c
 
-static void some_support_at_tick( void )
+static void some_support_at_tick( some_control *arg )
 {
   /* Clear interrupt */
 }
 
-#define Clock_driver_support_at_tick() \
-  some_support_at_tick()
+#define Clock_driver_support_at_tick( arg ) \
+  some_support_at_tick( arg )
 
 #include "../../../shared/dev/clock/clockimpl.h"
 
-- 
2.35.3

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

Re: [PATCH v2] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT BSP option

[Chris Johns]

On 21/3/2024 5:39 pm, Sebastian Huber wrote:> On 21.03.24 00:28, Chris Johns 
wrote:
>> On 21/3/2024 2:11 am, Sebastian Huber wrote:
>>> On 19.03.24 18:44, Chris Johns wrote:
 On 20/3/2024 2:03 am, Sebastian Huber wrote:
> On 19.03.24 14:50, Kinsey Moore wrote:
>> The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the 
>> spec
>> file for the new option. Its family differs from the arm/xilinx-zynqmp 
>> BSP
>> family with a -rpu suffix.
> Yes, but this BSP is quite new. I would prefer to let it not flush 
> anything by
> default to carry out a reset.
>
>> I'd be fine with this being enabled for the AArch64 BSPs as well, but I
>> imagine that's better as a separate patch.
> Why should it be enabled by default? The arm/xilinx-zynq and 
> arm/xilinx-zynqmp
> BSPs were the only ones doing an UART flush in the general termination
> procedure. It probably was done to address a specific use case (maybe test
> runs).
 Is the issue the flush is before an infinite loop which means the UART FIFO
 should drain?
>>
>> What is the issue you are wanting to solve removing the flush?
> 
> The bsp_reset() function should reset the system and do nothing more. Doing
> additional things like flushing an UART device may not make sense for all
> applications. Some applications may not use the UART device, so it may not be
> initialized and powered off.  Some applications may use it with an
> application-specific protocol which doesn't like the additional four '\r' 
> during
> reset. Doing a UART flush takes some time and some applications may prefer a
> fast reset time. The bsp_reset() is the wrong place to do add specific cleanup
> functions. Applications can customize the termination procedure with their own
> fatal error extension, destructors, and exit handlers.

This makes sense however the console needs this. Removing the code as my reading
of this changes does breaks those systems where the console is in use and relies
on the UART being flushed. A solution that addresses the console side of things
would be more acceptable. You present some valid cases for making a change but a
user should be able to enter reset in a shell and see all output or invoke a
fatal error and expect to see the full error message.

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

Re: [PATCH] bsps: Avoid unused argument in clock interrupt

[Gedare Bloom]

Generally this looks ok to me, but please update
https://docs.rtems.org/branches/master/bsp-howto/clock.html#initialization
https://docs.rtems.org/branches/master/bsp-howto/clock.html#support-at-tick
to explain how this arg works.

On Wed, Mar 20, 2024 at 8:29 AM Sebastian Huber
 wrote:
>
> Pass the parameter of the clock interrupt handler to
> Clock_driver_support_at_tick() and Clock_driver_timecounter_tick().  This 
> makes
> it possible to use the interrupt handler argument in clock drivers.
>
> Use the interrupt handler provided by Clock_driver_support_install_isr() to
> avoid local delarations of Clock_isr().
>
> Update #4862.
> ---
>  bsps/arm/beagle/clock/clock.c |  2 +-
>  bsps/arm/csb336/clock/clockdrv.c  |  2 +-
>  bsps/arm/csb337/clock/clock.c |  2 +-
>  bsps/arm/edb7312/clock/clockdrv.c |  6 +--
>  bsps/arm/gumstix/clock/clock.c|  2 +-
>  bsps/arm/raspberrypi/clock/clockdrv.c | 27 +-
>  bsps/arm/rtl22xx/clock/clockdrv.c |  2 +-
>  bsps/arm/shared/clock/clock-a9mpcore.c| 28 ++
>  bsps/arm/shared/clock/clock-nxp-lpc.c | 17 -
>  bsps/arm/smdk2410/clock/clockdrv.c|  2 +-
>  bsps/arm/tms570/clock/clock.c | 20 +-
>  bsps/i386/pc386/clock/ckinit.c|  2 +-
>  bsps/lm32/shared/clock/ckinit.c   |  2 +-
>  bsps/lm32/shared/milkymist_clock/ckinit.c |  2 +-
>  bsps/m68k/av5282/clock/clock.c|  2 +-
>  bsps/m68k/gen68360/clock/clock.c  |  2 +-
>  bsps/m68k/genmcf548x/clock/clock.c|  2 +-
>  bsps/m68k/mcf52235/clock/clock.c  |  2 +-
>  bsps/m68k/mcf5225x/clock/clock.c  |  2 +-
>  bsps/m68k/mcf5235/clock/clock.c   |  2 +-
>  bsps/m68k/mcf5329/clock/clock.c   |  2 +-
>  bsps/m68k/mrm332/btimer/btimer.c  |  2 -
>  bsps/m68k/uC5282/clock/clock.c|  2 +-
>  bsps/microblaze/microblaze_fpga/clock/clock.c |  8 ++--
>  bsps/mips/csb350/clock/clockdrv.c |  4 +-
>  bsps/mips/rbtx4925/clock/clockdrv.c   |  2 +-
>  bsps/mips/rbtx4938/clock/clockdrv.c   |  2 +-
>  bsps/mips/shared/clock/clockdrv.c |  2 +-
>  bsps/nios2/nios2_iss/clock/clock.c|  2 +-
>  bsps/or1k/generic_or1k/clock/clockdrv.c   |  2 +-
>  bsps/powerpc/mpc55xxevb/clock/clock-config.c  | 24 ++--
>  bsps/powerpc/qoriq/clock/clock-config.c   | 14 +++
>  bsps/riscv/griscv/clock/clockdrv.c|  2 +-
>  bsps/riscv/riscv/clock/clockdrv.c | 13 +++
>  bsps/shared/dev/clock/arm-generic-timer.c | 19 --
>  bsps/shared/dev/clock/clockimpl.h | 37 +--
>  bsps/shared/dev/clock/xil-ttc.c   | 32 ++--
>  bsps/shared/grlib/btimer/tlib_ckinit.c|  4 +-
>  bsps/sparc/erc32/clock/ckinit.c   |  8 ++--
>  bsps/sparc/leon2/clock/ckinit.c   |  2 +-
>  bsps/sparc/leon3/clock/ckinit.c   |  2 +-
>  bsps/sparc64/shared/clock/ckinit.c|  2 +-
>  42 files changed, 137 insertions(+), 178 deletions(-)
>
> diff --git a/bsps/arm/beagle/clock/clock.c b/bsps/arm/beagle/clock/clock.c
> index d42b051c98..a32dde86bf 100644
> --- a/bsps/arm/beagle/clock/clock.c
> +++ b/bsps/arm/beagle/clock/clock.c
> @@ -290,7 +290,7 @@ static void 
> beagle_clock_handler_install(rtems_interrupt_handler isr)
>clock_isr = isr;
>  }
>
> -#define Clock_driver_support_at_tick() beagle_clock_at_tick()
> +#define Clock_driver_support_at_tick(arg) beagle_clock_at_tick()
>  #define Clock_driver_support_initialize_hardware() beagle_clock_initialize()
>  #define Clock_driver_support_install_isr(isr) \
>beagle_clock_handler_install(isr)
> diff --git a/bsps/arm/csb336/clock/clockdrv.c 
> b/bsps/arm/csb336/clock/clockdrv.c
> index 58f98d87be..6af507a877 100644
> --- a/bsps/arm/csb336/clock/clockdrv.c
> +++ b/bsps/arm/csb336/clock/clockdrv.c
> @@ -38,7 +38,7 @@ rtems_irq_connect_data clock_isr_data = {
>   *- clear the interrupt bit?
>   *- restart the timer?
>   */
> -#define Clock_driver_support_at_tick()   \
> +#define Clock_driver_support_at_tick(arg)\
>do {   \
>  uint32_t reg;\
>   \
> diff --git a/bsps/arm/csb337/clock/clock.c b/bsps/arm/csb337/clock/clock.c
> index 69a3dafd81..ee05387baa 100644
> --- a/bsps/arm/csb337/clock/clock.c
> +++ b/bsps/arm/csb337/clock/clock.c
> @@ -94,7 +94,7 @@ static void Clock_driver_support_initialize_hardware(void)
>ST_REG(ST_PIMR) = value;
>  }
>
> -#define Clock_driver_support_at_tick() \
> +#define Clock_driver_support_at_tick(arg) \
>do { \
>  uint32_t st_str; \
>  \
> diff --git a/bsps/arm/edb7312/clock/clockdrv.c 
> b/bsps/arm/edb7312/clock/clockdrv.c
> index 

Re: RFC: Add API to get and set interrupt priorities for interrupt vectors

[Gedare Bloom]

Two basic questions:

Does the priority field type need to be Architecture- or BSP-defined
or is uint32_t always going to be fine.

Does changing (increasing) the priority of a vector from within
interrupt context possibly cause a pending interrupt to post that was
previously at a lower priority than the currently masked priority
level? In that case, it would cause a preemption to occur. I'm
guessing this behavior could be architecture-specific.

I added those questions to the ticket also.
Gedare

On Wed, Mar 20, 2024 at 2:59 AM Sebastian Huber
 wrote:
>
> Hello,
>
> I added a ticket for a proposal for an API to get and set interrupt
> priorities for interrupt vectors:
>
> https://devel.rtems.org/ticket/5002
>
> I would like to implement this API at least for the BSPs using the
> ARM/AArch64 GIC.
>
> --
> embedded brains GmbH & Co. KG
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [Docs] c-user: Clarify CONFIGURE_TICKS_PER_TIMESLICE

[Joel Sherrill]

On Thu, Mar 21, 2024 at 9:06 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> On 21.03.24 15:05, Joel Sherrill wrote:
> > Isn't this content generated from rtems-central?
>
> Yes, it is generated.
>
> >
> > Shouldn't there also be a change there?
>
> It should be there:
>

OK. Just didn't see a patch posted.

>
> Module:rtems-central
> Branch:master
> Commit:f5e42e5d9fae95e50f41a2ed71ee94e9908612c0
> Changeset:
>
> http://git.rtems.org/rtems-central/commit/?id=f5e42e5d9fae95e50f41a2ed71ee94e9908612c0
>
> Author:Sebastian Huber 
> Date:  Thu Mar 21 11:55:22 2024 +0100
>
> spec: Fix CONFIGURE_TICKS_PER_TIMESLICE constraint
>
> Update #4986.
>
> --
> embedded brains GmbH & Co. KG
> 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: [Docs] c-user: Clarify CONFIGURE_TICKS_PER_TIMESLICE

[Sebastian Huber]

On 21.03.24 15:05, Joel Sherrill wrote:

Isn't this content generated from rtems-central?


Yes, it is generated.



Shouldn't there also be a change there?


It should be there:

Module:rtems-central
Branch:master
Commit:f5e42e5d9fae95e50f41a2ed71ee94e9908612c0
Changeset: 
http://git.rtems.org/rtems-central/commit/?id=f5e42e5d9fae95e50f41a2ed71ee94e9908612c0


Author:Sebastian Huber 
Date:  Thu Mar 21 11:55:22 2024 +0100

spec: Fix CONFIGURE_TICKS_PER_TIMESLICE constraint

Update #4986.

--
embedded brains GmbH & Co. KG
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: [Docs] c-user: Clarify CONFIGURE_TICKS_PER_TIMESLICE

[Joel Sherrill]

Isn't this content generated from rtems-central?

Shouldn't there also be a change there?

--joel

On Wed, Mar 20, 2024 at 9:24 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Close #4986.
> ---
>  c-user/config/general.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/c-user/config/general.rst b/c-user/config/general.rst
> index 5ff79e7..61bfa1e 100644
> --- a/c-user/config/general.rst
> +++ b/c-user/config/general.rst
> @@ -1017,7 +1017,7 @@ configured, see
> :ref:`CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER`.
>
>  The following constraints apply to this configuration option:
>
> -* The value of the configuration option shall be greater than or equal to
> zero.
> +* The value of the configuration option shall be greater than or equal to
> one.
>
>  * The value of the configuration option shall be less than or equal to
>`UINT32_MAX `_.
> --
> 2.35.3
>
> ___
> 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 v2] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT BSP option

[Sebastian Huber]

On 21.03.24 00:28, Chris Johns wrote:

On 21/3/2024 2:11 am, Sebastian Huber wrote:

On 19.03.24 18:44, Chris Johns wrote:

On 20/3/2024 2:03 am, Sebastian Huber wrote:

On 19.03.24 14:50, Kinsey Moore wrote:

The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the spec
file for the new option. Its family differs from the arm/xilinx-zynqmp BSP
family with a -rpu suffix.

Yes, but this BSP is quite new. I would prefer to let it not flush anything by
default to carry out a reset.


I'd be fine with this being enabled for the AArch64 BSPs as well, but I
imagine that's better as a separate patch.

Why should it be enabled by default? The arm/xilinx-zynq and arm/xilinx-zynqmp
BSPs were the only ones doing an UART flush in the general termination
procedure. It probably was done to address a specific use case (maybe test
runs).

Is the issue the flush is before an infinite loop which means the UART FIFO
should drain?


What is the issue you are wanting to solve removing the flush?


The bsp_reset() function should reset the system and do nothing more. 
Doing additional things like flushing an UART device may not make sense 
for all applications. Some applications may not use the UART device, so 
it may not be initialized and powered off.  Some applications may use it 
with an application-specific protocol which doesn't like the additional 
four '\r' during reset. Doing a UART flush takes some time and some 
applications may prefer a fast reset time. The bsp_reset() is the wrong 
place to do add specific cleanup functions. Applications can customize 
the termination procedure with their own fatal error extension, 
destructors, and exit handlers.


--
embedded brains GmbH & Co. KG
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

[PATCH 0/1] This is the task for GSOC'24

[Abhinav Srivastava]

Screenshot: https://i.ibb.co/NTxGCj6/Screenshot-2024-03-20-22-41-54.png - 
Modified the sample hello world to print the popular dialogue "Oh, Hi Mark" 
from the movie "The Room" by Tommy Wiseau.

Abhinav Srivastava (1):
  Modify hello world sample for GSoC task

 testsuites/samples/hello/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
2.34.1

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

[PATCH 1/1] Modify hello world sample for GSoC task

[Abhinav Srivastava]

---
 testsuites/samples/hello/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c
index 83f6342ab3..f1c5983ad2 100644
--- a/testsuites/samples/hello/init.c
+++ b/testsuites/samples/hello/init.c
@@ -41,7 +41,7 @@ static rtems_task Init(
 {
   rtems_print_printer_fprintf_putc(_test_printer);
   TEST_BEGIN();
-  printf( "Hello World\n" );
+  printf( "Oh, Hi Mark.\n" );
   TEST_END();
   rtems_test_exit( 0 );
 }
-- 
2.34.1

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

gprof Support

[Joel Sherrill]

Hi

Did gprof support some along as a side-effect of gcov support?

Any hints on getting it working appreciated.

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

Re: [PATCH v2] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT BSP option

[Chris Johns]

On 21/3/2024 2:11 am, Sebastian Huber wrote:
> On 19.03.24 18:44, Chris Johns wrote:
>> On 20/3/2024 2:03 am, Sebastian Huber wrote:
>>> On 19.03.24 14:50, Kinsey Moore wrote:
 The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the spec
 file for the new option. Its family differs from the arm/xilinx-zynqmp BSP
 family with a -rpu suffix.
>>> Yes, but this BSP is quite new. I would prefer to let it not flush anything 
>>> by
>>> default to carry out a reset.
>>>
 I'd be fine with this being enabled for the AArch64 BSPs as well, but I
 imagine that's better as a separate patch.
>>> Why should it be enabled by default? The arm/xilinx-zynq and 
>>> arm/xilinx-zynqmp
>>> BSPs were the only ones doing an UART flush in the general termination
>>> procedure. It probably was done to address a specific use case (maybe test
>>> runs).
>> Is the issue the flush is before an infinite loop which means the UART FIFO
>> should drain?

What is the issue you are wanting to solve removing the flush?

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

[PATCH] GSoC Hello World

[Samuel Pires]

---
 testsuites/samples/hello/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/testsuites/samples/hello/init.c b/testsuites/samples/hello/init.c
index 83f6342ab3..5ebcdc9ef2 100644
--- a/testsuites/samples/hello/init.c
+++ b/testsuites/samples/hello/init.c
@@ -41,7 +41,7 @@ static rtems_task Init(
 {
   rtems_print_printer_fprintf_putc(_test_printer);
   TEST_BEGIN();
-  printf( "Hello World\n" );
+  printf( "Hello World from GSoC!\n" );
   TEST_END();
   rtems_test_exit( 0 );
 }
-- 
2.34.1

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

[PATCH] bsps: Move declarations to

[Sebastian Huber]

Move declarations of bsp_interrupt_get_affinity() and
bsp_interrupt_set_affinity() to .  Canonicalize the
 includes.

Implement bsp_interrupt_get_affinity() and bsp_interrupt_set_affinity() only if
needed (usually RTEMS_SMP).

Provide stub implementations for i386 to fix build errors.
---
 bsps/aarch64/raspberrypi/include/bsp/irq.h | 28 
 bsps/arm/raspberrypi/include/bsp/irq.h | 28 
 bsps/arm/raspberrypi/irq/irq.c | 23 +-
 bsps/i386/shared/irq/irq.c | 33 ++
 bsps/include/bsp/irq-generic.h | 52 +-
 bsps/include/dev/irq/arm-gic-irq.h | 11 -
 bsps/powerpc/qoriq/clock/clock-config.c|  2 +-
 bsps/powerpc/qoriq/include/bsp/irq.h   | 11 -
 bsps/powerpc/qoriq/irq/irq.c   |  1 -
 bsps/powerpc/t32mppc/include/bsp/irq.h | 23 --
 bsps/powerpc/t32mppc/irq/irq.c | 22 +
 bsps/riscv/griscv/clock/clockdrv.c |  2 +-
 bsps/riscv/griscv/include/bsp/irq.h| 13 --
 bsps/riscv/griscv/irq/irq.c|  1 -
 bsps/riscv/noel/include/bsp/irq.h  | 13 --
 bsps/riscv/riscv/include/bsp/irq.h | 13 --
 bsps/riscv/riscv/irq/irq.c |  1 -
 bsps/shared/dev/irq/arm-gicv2.c|  3 +-
 bsps/shared/dev/irq/arm-gicv3.c|  3 +-
 bsps/shared/irq/irq-affinity.c |  1 -
 bsps/sparc/erc32/include/bsp/irq.h | 22 +
 bsps/sparc/leon3/clock/ckinit.c|  3 +-
 bsps/sparc/leon3/include/bsp/irq.h | 11 -
 bsps/sparc/leon3/include/tm27.h|  2 +-
 bsps/sparc/leon3/start/bspsmp.c|  2 +-
 bsps/sparc/leon3/start/eirq.c  |  1 -
 bsps/sparc/shared/irq/irq-shared.c | 22 +
 27 files changed, 160 insertions(+), 187 deletions(-)

diff --git a/bsps/aarch64/raspberrypi/include/bsp/irq.h 
b/bsps/aarch64/raspberrypi/include/bsp/irq.h
index effec1b040..1ff6ae80de 100644
--- a/bsps/aarch64/raspberrypi/include/bsp/irq.h
+++ b/bsps/aarch64/raspberrypi/include/bsp/irq.h
@@ -23,14 +23,8 @@
 #ifndef ASM
 
 #include 
-#include 
-#include 
 #include 
 
-#if defined(RTEMS_SMP)
-#include 
-#endif
-
 /**
  * @defgroup raspberrypi_interrupt Interrrupt Support
  *
@@ -83,27 +77,5 @@
 
 #define BSP_IRQ_COUNT   (BCM2835_INTC_TOTAL_IRQ)
 
-#if defined(RTEMS_SMP)
-static inline rtems_status_code bsp_interrupt_set_affinity(
-  rtems_vector_number   vector,
-  const Processor_mask *affinity
-)
-{
-  (void) vector;
-  (void) affinity;
-  return RTEMS_UNSATISFIED;
-}
-
-static inline rtems_status_code bsp_interrupt_get_affinity(
-  rtems_vector_number  vector,
-  Processor_mask  *affinity
-)
-{
-  (void) vector;
-  _Processor_mask_From_index( affinity, 0 );
-  return RTEMS_UNSATISFIED;
-}
-#endif
-
 #endif /* ASM */
 #endif /* LIBBSP_ARM_RASPBERRYPI_IRQ_H */
diff --git a/bsps/arm/raspberrypi/include/bsp/irq.h 
b/bsps/arm/raspberrypi/include/bsp/irq.h
index 6801b01d84..895b268dfe 100644
--- a/bsps/arm/raspberrypi/include/bsp/irq.h
+++ b/bsps/arm/raspberrypi/include/bsp/irq.h
@@ -22,12 +22,6 @@
 #ifndef ASM
 
 #include 
-#include 
-#include 
-
-#if defined(RTEMS_SMP)
-#include 
-#endif
 
 /**
  * @defgroup raspberrypi_interrupt Interrrupt Support
@@ -78,27 +72,5 @@
 
 #define BSP_IRQ_COUNT   (BCM2835_INTC_TOTAL_IRQ)
 
-#if defined(RTEMS_SMP)
-static inline rtems_status_code bsp_interrupt_set_affinity(
-  rtems_vector_number   vector,
-  const Processor_mask *affinity
-)
-{
-  (void) vector;
-  (void) affinity;
-  return RTEMS_UNSATISFIED;
-}
-
-static inline rtems_status_code bsp_interrupt_get_affinity(
-  rtems_vector_number  vector,
-  Processor_mask  *affinity
-)
-{
-  (void) vector;
-  _Processor_mask_From_index( affinity, 0 );
-  return RTEMS_UNSATISFIED;
-}
-#endif
-
 #endif /* ASM */
 #endif /* LIBBSP_ARM_RASPBERRYPI_IRQ_H */
diff --git a/bsps/arm/raspberrypi/irq/irq.c b/bsps/arm/raspberrypi/irq/irq.c
index 30e10e5aec..7177cd2c05 100644
--- a/bsps/arm/raspberrypi/irq/irq.c
+++ b/bsps/arm/raspberrypi/irq/irq.c
@@ -19,7 +19,6 @@
 #include 
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -207,6 +206,28 @@ rtems_status_code 
bsp_interrupt_vector_disable(rtems_vector_number vector)
   return RTEMS_SUCCESSFUL;
 }
 
+#if defined(RTEMS_SMP)
+rtems_status_code bsp_interrupt_get_affinity(
+  rtems_vector_number  vector,
+  Processor_mask  *affinity
+)
+{
+  (void) vector;
+  _Processor_mask_From_index( affinity, 0 );
+  return RTEMS_UNSATISFIED;
+}
+
+rtems_status_code bsp_interrupt_set_affinity(
+  rtems_vector_number   vector,
+  const Processor_mask *affinity
+)
+{
+  (void) vector;
+  (void) affinity;
+  return RTEMS_UNSATISFIED;
+}
+#endif
+
 void bsp_interrupt_handler_default(rtems_vector_number vector)
 {
 printk("spurious interrupt: %" PRIdrtems_vector_number "\n", vector);
diff --git a/bsps/i386/shared/irq/irq.c b/bsps/i386/shared/irq/irq.c
index fe43bc1d7c..57753c2f77 100644
--- 

[PATCH] Mark parameters as intentionally unused

[Sebastian Huber]

The parameters are unused due to API constraints.  The functions are
used through function pointers.  Alternative implementations may use the
parameters.

Close #4862.
---
 bsps/sparc/leon3/start/bspclean.c   | 1 +
 cpukit/score/src/threadchangepriority.c | 1 +
 cpukit/score/src/threadq.c  | 2 ++
 cpukit/score/src/threadqenqueue.c   | 1 +
 cpukit/score/src/threadqops.c   | 2 ++
 cpukit/score/src/threadqtimeout.c   | 1 +
 cpukit/score/src/threadrestart.c| 1 +
 cpukit/score/src/userextiterate.c   | 2 ++
 8 files changed, 11 insertions(+)

diff --git a/bsps/sparc/leon3/start/bspclean.c 
b/bsps/sparc/leon3/start/bspclean.c
index 0324c45326..d624ec74c8 100644
--- a/bsps/sparc/leon3/start/bspclean.c
+++ b/bsps/sparc/leon3/start/bspclean.c
@@ -46,6 +46,7 @@ void bsp_fatal_extension(
 {
   rtems_interrupt_level level;
 
+  (void) always_set_to_false;
   rtems_interrupt_local_disable(level);
   (void) level;
 
diff --git a/cpukit/score/src/threadchangepriority.c 
b/cpukit/score/src/threadchangepriority.c
index ca49f6f417..78291b7798 100644
--- a/cpukit/score/src/threadchangepriority.c
+++ b/cpukit/score/src/threadchangepriority.c
@@ -111,6 +111,7 @@ static void _Thread_Priority_action_change(
   void *arg
 )
 {
+  (void) arg;
   _Thread_Set_scheduler_node_priority(
 priority_aggregation,
 priority_group_order
diff --git a/cpukit/score/src/threadq.c b/cpukit/score/src/threadq.c
index e694029a46..3c6d72bd14 100644
--- a/cpukit/score/src/threadq.c
+++ b/cpukit/score/src/threadq.c
@@ -179,5 +179,7 @@ void _Thread_queue_MP_callout_do_nothing(
 )
 {
   /* Do nothing */
+  (void) the_proxy;
+  (void) mp_id;
 }
 #endif
diff --git a/cpukit/score/src/threadqenqueue.c 
b/cpukit/score/src/threadqenqueue.c
index e43efd925b..038c483f65 100644
--- a/cpukit/score/src/threadqenqueue.c
+++ b/cpukit/score/src/threadqenqueue.c
@@ -400,6 +400,7 @@ void _Thread_queue_Deadlock_status( Thread_Control 
*the_thread )
 
 void _Thread_queue_Deadlock_fatal( Thread_Control *the_thread )
 {
+  (void) the_thread;
   _Internal_error( INTERNAL_ERROR_THREAD_QUEUE_DEADLOCK );
 }
 
diff --git a/cpukit/score/src/threadqops.c b/cpukit/score/src/threadqops.c
index 511d1e4d00..9a09b4c442 100644
--- a/cpukit/score/src/threadqops.c
+++ b/cpukit/score/src/threadqops.c
@@ -156,6 +156,8 @@ static void _Thread_queue_FIFO_do_initialize(
 {
   Scheduler_Node *scheduler_node;
 
+  (void) queue;
+  (void) queue_context;
   scheduler_node = _Thread_Scheduler_get_home_node( the_thread );
 
   _Chain_Initialize_node( _node->Wait.Priority.Node.Node.Chain );
diff --git a/cpukit/score/src/threadqtimeout.c 
b/cpukit/score/src/threadqtimeout.c
index acb3c1d048..e30a2ffded 100644
--- a/cpukit/score/src/threadqtimeout.c
+++ b/cpukit/score/src/threadqtimeout.c
@@ -53,6 +53,7 @@ void _Thread_queue_Add_timeout_ticks(
 {
   Watchdog_Interval ticks;
 
+  (void) queue;
   ticks = queue_context->Timeout.ticks;
 
   if ( ticks != WATCHDOG_NO_TIMEOUT ) {
diff --git a/cpukit/score/src/threadrestart.c b/cpukit/score/src/threadrestart.c
index d1c4b283fb..72326682ca 100644
--- a/cpukit/score/src/threadrestart.c
+++ b/cpukit/score/src/threadrestart.c
@@ -83,6 +83,7 @@ static Thread_Control *_Thread_Join_flush_filter(
 {
   Thread_Join_context *join_context;
 
+  (void) queue;
   join_context = (Thread_Join_context *) queue_context;
 
   the_thread->Wait.return_argument = join_context->exit_value;
diff --git a/cpukit/score/src/userextiterate.c 
b/cpukit/score/src/userextiterate.c
index 6f6790082a..cae76d173c 100644
--- a/cpukit/score/src/userextiterate.c
+++ b/cpukit/score/src/userextiterate.c
@@ -118,6 +118,8 @@ void _User_extensions_Thread_begin_visitor(
 {
   User_extensions_thread_begin_extension callout = callouts->thread_begin;
 
+  (void) arg;
+
   if ( callout != NULL ) {
 (*callout)( executing );
   }
-- 
2.35.3

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

Re: [PATCH v2] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT BSP option

[Sebastian Huber]

On 19.03.24 18:44, Chris Johns wrote:

On 20/3/2024 2:03 am, Sebastian Huber wrote:

On 19.03.24 14:50, Kinsey Moore wrote:

The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the spec
file for the new option. Its family differs from the arm/xilinx-zynqmp BSP
family with a -rpu suffix.

Yes, but this BSP is quite new. I would prefer to let it not flush anything by
default to carry out a reset.


I'd be fine with this being enabled for the AArch64 BSPs as well, but I
imagine that's better as a separate patch.

Why should it be enabled by default? The arm/xilinx-zynq and arm/xilinx-zynqmp
BSPs were the only ones doing an UART flush in the general termination
procedure. It probably was done to address a specific use case (maybe test 
runs).

Is the issue the flush is before an infinite loop which means the UART FIFO
should drain?


I don't really like the new bsp_flush_kernel_char_output() function. Another
approach could be an API change of

/**
  * @ingroup RTEMSAPIKernelCharIO
  *
  * @brief Polled character output functions shall have this type.
  */
typedef void ( *BSP_output_char_function_type )( char );

to something like this

typedef int ( *BSP_output_char_function_type )( int action );

If action in {0, ..., 255}, then print out the character. If 0x100 is set, then
flush the output device. If 0x200 is set, then do Y... The return value could be
used to give a status indication.

This could then be use for example by test runs, to flush the test output after
the end of the test.

This also requires a code change so is a flush function that bad an option?


You can change the character output handler since this is only a global 
variable (BSP_output_char). So, this bsp_flush_kernel_char_output() may 
not flush the device used by BSP_output_char. Doing a flush through the 
output handler lets you do the flush for the currently used device.


If we change the function type to

typedef int ( *BSP_output_char_function_type )( int action );

then we can add more features later if needed. Another feature which 
could be useful is: Output char immediately if possible and return 0, 
otherwise do nothing and return -1. This can be used to implement a 
full-duplex transfer in polling mode for the kernel I/O stream.


--
embedded brains GmbH & Co. KG
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

[PATCH] bsps: Avoid unused argument in clock interrupt

[Sebastian Huber]

Pass the parameter of the clock interrupt handler to
Clock_driver_support_at_tick() and Clock_driver_timecounter_tick().  This makes
it possible to use the interrupt handler argument in clock drivers.

Use the interrupt handler provided by Clock_driver_support_install_isr() to
avoid local delarations of Clock_isr().

Update #4862.
---
 bsps/arm/beagle/clock/clock.c |  2 +-
 bsps/arm/csb336/clock/clockdrv.c  |  2 +-
 bsps/arm/csb337/clock/clock.c |  2 +-
 bsps/arm/edb7312/clock/clockdrv.c |  6 +--
 bsps/arm/gumstix/clock/clock.c|  2 +-
 bsps/arm/raspberrypi/clock/clockdrv.c | 27 +-
 bsps/arm/rtl22xx/clock/clockdrv.c |  2 +-
 bsps/arm/shared/clock/clock-a9mpcore.c| 28 ++
 bsps/arm/shared/clock/clock-nxp-lpc.c | 17 -
 bsps/arm/smdk2410/clock/clockdrv.c|  2 +-
 bsps/arm/tms570/clock/clock.c | 20 +-
 bsps/i386/pc386/clock/ckinit.c|  2 +-
 bsps/lm32/shared/clock/ckinit.c   |  2 +-
 bsps/lm32/shared/milkymist_clock/ckinit.c |  2 +-
 bsps/m68k/av5282/clock/clock.c|  2 +-
 bsps/m68k/gen68360/clock/clock.c  |  2 +-
 bsps/m68k/genmcf548x/clock/clock.c|  2 +-
 bsps/m68k/mcf52235/clock/clock.c  |  2 +-
 bsps/m68k/mcf5225x/clock/clock.c  |  2 +-
 bsps/m68k/mcf5235/clock/clock.c   |  2 +-
 bsps/m68k/mcf5329/clock/clock.c   |  2 +-
 bsps/m68k/mrm332/btimer/btimer.c  |  2 -
 bsps/m68k/uC5282/clock/clock.c|  2 +-
 bsps/microblaze/microblaze_fpga/clock/clock.c |  8 ++--
 bsps/mips/csb350/clock/clockdrv.c |  4 +-
 bsps/mips/rbtx4925/clock/clockdrv.c   |  2 +-
 bsps/mips/rbtx4938/clock/clockdrv.c   |  2 +-
 bsps/mips/shared/clock/clockdrv.c |  2 +-
 bsps/nios2/nios2_iss/clock/clock.c|  2 +-
 bsps/or1k/generic_or1k/clock/clockdrv.c   |  2 +-
 bsps/powerpc/mpc55xxevb/clock/clock-config.c  | 24 ++--
 bsps/powerpc/qoriq/clock/clock-config.c   | 14 +++
 bsps/riscv/griscv/clock/clockdrv.c|  2 +-
 bsps/riscv/riscv/clock/clockdrv.c | 13 +++
 bsps/shared/dev/clock/arm-generic-timer.c | 19 --
 bsps/shared/dev/clock/clockimpl.h | 37 +--
 bsps/shared/dev/clock/xil-ttc.c   | 32 ++--
 bsps/shared/grlib/btimer/tlib_ckinit.c|  4 +-
 bsps/sparc/erc32/clock/ckinit.c   |  8 ++--
 bsps/sparc/leon2/clock/ckinit.c   |  2 +-
 bsps/sparc/leon3/clock/ckinit.c   |  2 +-
 bsps/sparc64/shared/clock/ckinit.c|  2 +-
 42 files changed, 137 insertions(+), 178 deletions(-)

diff --git a/bsps/arm/beagle/clock/clock.c b/bsps/arm/beagle/clock/clock.c
index d42b051c98..a32dde86bf 100644
--- a/bsps/arm/beagle/clock/clock.c
+++ b/bsps/arm/beagle/clock/clock.c
@@ -290,7 +290,7 @@ static void 
beagle_clock_handler_install(rtems_interrupt_handler isr)
   clock_isr = isr;
 }
 
-#define Clock_driver_support_at_tick() beagle_clock_at_tick()
+#define Clock_driver_support_at_tick(arg) beagle_clock_at_tick()
 #define Clock_driver_support_initialize_hardware() beagle_clock_initialize()
 #define Clock_driver_support_install_isr(isr) \
   beagle_clock_handler_install(isr)
diff --git a/bsps/arm/csb336/clock/clockdrv.c b/bsps/arm/csb336/clock/clockdrv.c
index 58f98d87be..6af507a877 100644
--- a/bsps/arm/csb336/clock/clockdrv.c
+++ b/bsps/arm/csb336/clock/clockdrv.c
@@ -38,7 +38,7 @@ rtems_irq_connect_data clock_isr_data = {
  *- clear the interrupt bit?
  *- restart the timer?
  */
-#define Clock_driver_support_at_tick()   \
+#define Clock_driver_support_at_tick(arg)\
   do {   \
 uint32_t reg;\
  \
diff --git a/bsps/arm/csb337/clock/clock.c b/bsps/arm/csb337/clock/clock.c
index 69a3dafd81..ee05387baa 100644
--- a/bsps/arm/csb337/clock/clock.c
+++ b/bsps/arm/csb337/clock/clock.c
@@ -94,7 +94,7 @@ static void Clock_driver_support_initialize_hardware(void)
   ST_REG(ST_PIMR) = value;
 }
 
-#define Clock_driver_support_at_tick() \
+#define Clock_driver_support_at_tick(arg) \
   do { \
 uint32_t st_str; \
 \
diff --git a/bsps/arm/edb7312/clock/clockdrv.c 
b/bsps/arm/edb7312/clock/clockdrv.c
index 8c7cc4f26a..79289366da 100644
--- a/bsps/arm/edb7312/clock/clockdrv.c
+++ b/bsps/arm/edb7312/clock/clockdrv.c
@@ -18,9 +18,7 @@
   #define CLOCK_DRIVER_USE_FAST_IDLE 1
 #endif
 
-void Clock_isr(void * arg);
-
-#define Clock_driver_support_at_tick()\
+#define Clock_driver_support_at_tick(arg) \
   do {\
 *EP7312_TC1EOI = 0x;  \
   } while(0)
@@ -32,7 +30,7 @@ void Clock_isr(void 

[Docs] c-user: Clarify CONFIGURE_TICKS_PER_TIMESLICE

[Sebastian Huber]

Close #4986.
---
 c-user/config/general.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/c-user/config/general.rst b/c-user/config/general.rst
index 5ff79e7..61bfa1e 100644
--- a/c-user/config/general.rst
+++ b/c-user/config/general.rst
@@ -1017,7 +1017,7 @@ configured, see 
:ref:`CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER`.
 
 The following constraints apply to this configuration option:
 
-* The value of the configuration option shall be greater than or equal to zero.
+* The value of the configuration option shall be greater than or equal to one.
 
 * The value of the configuration option shall be less than or equal to
   `UINT32_MAX `_.
-- 
2.35.3

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

Re: [PATCH] Do not define CONFIGURE_TICKS_PER_TIMESLICE to 0

[Sebastian Huber]

On 20.03.24 15:14, Joel Sherrill wrote:
This is generally ok but it contradicts the documented behavior 
for CONFIGURE_TICKS_PER_TIMESLICE which states "The value of the 
configuration option shall be greater than or equal to zero."


This is the problem of the referenced ticket:

https://devel.rtems.org/ticket/4986



If zero is to be an error, then that needs to change.


This is what the patch does.



Further, this series of changes has made me realize that 
CONFIGURE_TICKS_PER_TIMESLICE and CONFIGURE_MICROSECONDS_PER_TICK should 
not be defined if the application has not defined 
CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER. Currently the documentation 
just says it has no effect.


This is a different topic. I would like to first fix the undefined 
behaviour if some uses:


#define CONFIGURE_TICKS_PER_TIMESLICE 0



Also the formatting of the text in the description is inconsistent. 
Could a ref be used for all of this?


The application shall define exactly one of the following configuration 
options


* :ref:`CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER`,
* ``CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER``, or
* :ref:`CONFIGURE_APPLICATION_NEEDS_TIMER_DRIVER`,


Sorry, were is this in the patch?

--
embedded brains GmbH & Co. KG
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] Do not define CONFIGURE_TICKS_PER_TIMESLICE to 0

[Joel Sherrill]

This is generally ok but it contradicts the documented behavior
for CONFIGURE_TICKS_PER_TIMESLICE which states "The value of the
configuration option shall be greater than or equal to zero."

If zero is to be an error, then that needs to change.

Further, this series of changes has made me realize that
CONFIGURE_TICKS_PER_TIMESLICE and CONFIGURE_MICROSECONDS_PER_TICK should
not be defined if the application has not defined
CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER. Currently the documentation just
says it has no effect.

Also the formatting of the text in the description is inconsistent. Could a
ref be used for all of this?

The application shall define exactly one of the following configuration
options

* :ref:`CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER`,
* ``CONFIGURE_APPLICATION_DOES_NOT_NEED_CLOCK_DRIVER``, or
* :ref:`CONFIGURE_APPLICATION_NEEDS_TIMER_DRIVER`,

--joel

On Wed, Mar 20, 2024 at 2:28 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Unconditionally make a CONFIGURE_TICKS_PER_TIMESLICE value less than or
> equal
> to zero an error.
>
> Update #4986.
> ---
>  cpukit/doxygen/appl-config.h  | 2 +-
>  cpukit/include/rtems/confdefs/clock.h | 3 +--
>  testsuites/ada/tmtests/tm01/init.c| 1 -
>  testsuites/ada/tmtests/tm02/init.c| 1 -
>  testsuites/ada/tmtests/tm03/init.c| 1 -
>  testsuites/ada/tmtests/tm04/init.c| 1 -
>  testsuites/ada/tmtests/tm05/init.c| 1 -
>  testsuites/ada/tmtests/tm06/init.c| 1 -
>  testsuites/ada/tmtests/tm07/init.c| 1 -
>  testsuites/ada/tmtests/tm08/init.c| 1 -
>  testsuites/ada/tmtests/tm09/init.c| 1 -
>  testsuites/ada/tmtests/tm10/init.c| 1 -
>  testsuites/ada/tmtests/tm11/init.c| 1 -
>  testsuites/ada/tmtests/tm12/init.c| 1 -
>  testsuites/ada/tmtests/tm13/init.c| 1 -
>  testsuites/ada/tmtests/tm14/init.c| 1 -
>  testsuites/ada/tmtests/tm15/init.c| 1 -
>  testsuites/ada/tmtests/tm16/init.c| 1 -
>  testsuites/ada/tmtests/tm17/init.c| 1 -
>  testsuites/ada/tmtests/tm18/init.c| 1 -
>  testsuites/ada/tmtests/tm19/init.c| 1 -
>  testsuites/ada/tmtests/tm20/init.c| 1 -
>  testsuites/ada/tmtests/tm21/init.c| 1 -
>  testsuites/ada/tmtests/tm22/init.c| 1 -
>  testsuites/ada/tmtests/tm23/init.c| 1 -
>  testsuites/ada/tmtests/tm24/init.c| 1 -
>  testsuites/ada/tmtests/tm25/init.c| 1 -
>  testsuites/ada/tmtests/tm28/init.c| 1 -
>  testsuites/ada/tmtests/tm29/init.c| 1 -
>  testsuites/ada/tmtests/tmck/init.c| 1 -
>  testsuites/rhealstone/rhdeadlockbrk/deadlockbrk.c | 1 -
>  testsuites/rhealstone/rhilatency/ilatency.c   | 1 -
>  testsuites/rhealstone/rhmlatency/mlatency.c   | 1 -
>  testsuites/rhealstone/rhtaskpreempt/taskpreempt.c | 1 -
>  testsuites/rhealstone/rhtaskswitch/taskswitch.c   | 1 -
>  testsuites/tmtests/tm01/system.h  | 1 -
>  testsuites/tmtests/tm02/system.h  | 1 -
>  testsuites/tmtests/tm03/system.h  | 1 -
>  testsuites/tmtests/tm04/system.h  | 1 -
>  testsuites/tmtests/tm05/system.h  | 1 -
>  testsuites/tmtests/tm06/system.h  | 1 -
>  testsuites/tmtests/tm07/system.h  | 1 -
>  testsuites/tmtests/tm08/system.h  | 1 -
>  testsuites/tmtests/tm09/system.h  | 1 -
>  testsuites/tmtests/tm10/system.h  | 1 -
>  testsuites/tmtests/tm11/system.h  | 1 -
>  testsuites/tmtests/tm12/system.h  | 1 -
>  testsuites/tmtests/tm13/system.h  | 1 -
>  testsuites/tmtests/tm14/system.h  | 1 -
>  testsuites/tmtests/tm15/system.h  | 1 -
>  testsuites/tmtests/tm16/system.h  | 1 -
>  testsuites/tmtests/tm17/system.h  | 1 -
>  testsuites/tmtests/tm18/system.h  | 1 -
>  testsuites/tmtests/tm19/system.h  | 1 -
>  testsuites/tmtests/tm20/system.h  | 1 -
>  testsuites/tmtests/tm21/system.h  | 1 -
>  testsuites/tmtests/tm22/system.h  | 1 -
>  testsuites/tmtests/tm23/system.h  | 1 -
>  testsuites/tmtests/tm24/system.h  | 1 -
>  testsuites/tmtests/tm25/system.h  | 1 -
>  testsuites/tmtests/tm26/system.h  | 1 -
>  testsuites/tmtests/tm27/system.h  | 1 -
>  testsuites/tmtests/tm28/system.h  | 1 -
>  testsuites/tmtests/tm29/system.h  | 1 -
>  testsuites/tmtests/tmck/system.h  | 1 -
>  65 files changed, 2 insertions(+), 66 deletions(-)
>
> 

Re: utf32 support

[Frank Kühndel]

Hello John,

On 3/19/24 16:53, John Howard wrote:

P.S.: UTF32 exists for Unicode in 2012 after consolidation from ISO 10646-2012. 
The two standards merged.


Oops. I am apparently outdated ...
Frank

--
embedded brains GmbH & Co. KG
Herr Frank KÜHNDEL
Dornierstr. 4
82178 Puchheim
Germany
email: frank.kuehn...@embedded-brains.de
phone:  +49-89-18 94 741 - 23
mobile: +49-176-15 22 06 - 11

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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

RFC: Add API to get and set interrupt priorities for interrupt vectors

[Sebastian Huber]

Hello,

I added a ticket for a proposal for an API to get and set interrupt 
priorities for interrupt vectors:


https://devel.rtems.org/ticket/5002

I would like to implement this API at least for the BSPs using the 
ARM/AArch64 GIC.


--
embedded brains GmbH & Co. KG
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

[PATCH] Do not define CONFIGURE_TICKS_PER_TIMESLICE to 0

[Sebastian Huber]

Unconditionally make a CONFIGURE_TICKS_PER_TIMESLICE value less than or equal
to zero an error.

Update #4986.
---
 cpukit/doxygen/appl-config.h  | 2 +-
 cpukit/include/rtems/confdefs/clock.h | 3 +--
 testsuites/ada/tmtests/tm01/init.c| 1 -
 testsuites/ada/tmtests/tm02/init.c| 1 -
 testsuites/ada/tmtests/tm03/init.c| 1 -
 testsuites/ada/tmtests/tm04/init.c| 1 -
 testsuites/ada/tmtests/tm05/init.c| 1 -
 testsuites/ada/tmtests/tm06/init.c| 1 -
 testsuites/ada/tmtests/tm07/init.c| 1 -
 testsuites/ada/tmtests/tm08/init.c| 1 -
 testsuites/ada/tmtests/tm09/init.c| 1 -
 testsuites/ada/tmtests/tm10/init.c| 1 -
 testsuites/ada/tmtests/tm11/init.c| 1 -
 testsuites/ada/tmtests/tm12/init.c| 1 -
 testsuites/ada/tmtests/tm13/init.c| 1 -
 testsuites/ada/tmtests/tm14/init.c| 1 -
 testsuites/ada/tmtests/tm15/init.c| 1 -
 testsuites/ada/tmtests/tm16/init.c| 1 -
 testsuites/ada/tmtests/tm17/init.c| 1 -
 testsuites/ada/tmtests/tm18/init.c| 1 -
 testsuites/ada/tmtests/tm19/init.c| 1 -
 testsuites/ada/tmtests/tm20/init.c| 1 -
 testsuites/ada/tmtests/tm21/init.c| 1 -
 testsuites/ada/tmtests/tm22/init.c| 1 -
 testsuites/ada/tmtests/tm23/init.c| 1 -
 testsuites/ada/tmtests/tm24/init.c| 1 -
 testsuites/ada/tmtests/tm25/init.c| 1 -
 testsuites/ada/tmtests/tm28/init.c| 1 -
 testsuites/ada/tmtests/tm29/init.c| 1 -
 testsuites/ada/tmtests/tmck/init.c| 1 -
 testsuites/rhealstone/rhdeadlockbrk/deadlockbrk.c | 1 -
 testsuites/rhealstone/rhilatency/ilatency.c   | 1 -
 testsuites/rhealstone/rhmlatency/mlatency.c   | 1 -
 testsuites/rhealstone/rhtaskpreempt/taskpreempt.c | 1 -
 testsuites/rhealstone/rhtaskswitch/taskswitch.c   | 1 -
 testsuites/tmtests/tm01/system.h  | 1 -
 testsuites/tmtests/tm02/system.h  | 1 -
 testsuites/tmtests/tm03/system.h  | 1 -
 testsuites/tmtests/tm04/system.h  | 1 -
 testsuites/tmtests/tm05/system.h  | 1 -
 testsuites/tmtests/tm06/system.h  | 1 -
 testsuites/tmtests/tm07/system.h  | 1 -
 testsuites/tmtests/tm08/system.h  | 1 -
 testsuites/tmtests/tm09/system.h  | 1 -
 testsuites/tmtests/tm10/system.h  | 1 -
 testsuites/tmtests/tm11/system.h  | 1 -
 testsuites/tmtests/tm12/system.h  | 1 -
 testsuites/tmtests/tm13/system.h  | 1 -
 testsuites/tmtests/tm14/system.h  | 1 -
 testsuites/tmtests/tm15/system.h  | 1 -
 testsuites/tmtests/tm16/system.h  | 1 -
 testsuites/tmtests/tm17/system.h  | 1 -
 testsuites/tmtests/tm18/system.h  | 1 -
 testsuites/tmtests/tm19/system.h  | 1 -
 testsuites/tmtests/tm20/system.h  | 1 -
 testsuites/tmtests/tm21/system.h  | 1 -
 testsuites/tmtests/tm22/system.h  | 1 -
 testsuites/tmtests/tm23/system.h  | 1 -
 testsuites/tmtests/tm24/system.h  | 1 -
 testsuites/tmtests/tm25/system.h  | 1 -
 testsuites/tmtests/tm26/system.h  | 1 -
 testsuites/tmtests/tm27/system.h  | 1 -
 testsuites/tmtests/tm28/system.h  | 1 -
 testsuites/tmtests/tm29/system.h  | 1 -
 testsuites/tmtests/tmck/system.h  | 1 -
 65 files changed, 2 insertions(+), 66 deletions(-)

diff --git a/cpukit/doxygen/appl-config.h b/cpukit/doxygen/appl-config.h
index 77c89dabf3..81150af066 100644
--- a/cpukit/doxygen/appl-config.h
+++ b/cpukit/doxygen/appl-config.h
@@ -3685,7 +3685,7 @@
  * The following constraints apply to this configuration option:
  *
  * * The value of the configuration option shall be greater than or equal to
- *   zero.
+ *   one.
  *
  * * The value of the configuration option shall be less than or equal to https://en.cppreference.com/w/c/types/integer;>UINT32_MAX.
diff --git a/cpukit/include/rtems/confdefs/clock.h 
b/cpukit/include/rtems/confdefs/clock.h
index d35757561d..e57daa899b 100644
--- a/cpukit/include/rtems/confdefs/clock.h
+++ b/cpukit/include/rtems/confdefs/clock.h
@@ -70,8 +70,7 @@
   #warning "The clock ticks per second is not an integer"
 #endif
 
-#if defined(CONFIGURE_APPLICATION_NEEDS_CLOCK_DRIVER) \
-  && defined(CONFIGURE_TICKS_PER_TIMESLICE) \
+#if defined(CONFIGURE_TICKS_PER_TIMESLICE) \
   && CONFIGURE_TICKS_PER_TIMESLICE <= 0
   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
 #endif
diff --git 

Re: [PATCH v2] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT BSP option

[Chris Johns]

On 19/3/2024 7:39 pm, Sebastian Huber wrote:
> Make the kernel I/O output character device flushing configurable.  The
> bsp_reset() function should reset the unit and do nothing else.

This changes existing behaviour. RTEMS is poor at cleanly handling the console
output on reset. Working with the powerpc/mvme2700 and EPICS is hard because the
output is lost on reset and assert and crash output is corrupted.

As an OS I think we should be heading other way and if you want just a reset you
provide it.

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

Re: [PATCH v2] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT BSP option

[Chris Johns]

On 20/3/2024 2:03 am, Sebastian Huber wrote:
> On 19.03.24 14:50, Kinsey Moore wrote:
>> The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the spec
>> file for the new option. Its family differs from the arm/xilinx-zynqmp BSP
>> family with a -rpu suffix.
> 
> Yes, but this BSP is quite new. I would prefer to let it not flush anything by
> default to carry out a reset.
> 
>> I'd be fine with this being enabled for the AArch64 BSPs as well, but I
>> imagine that's better as a separate patch.
> 
> Why should it be enabled by default? The arm/xilinx-zynq and arm/xilinx-zynqmp
> BSPs were the only ones doing an UART flush in the general termination
> procedure. It probably was done to address a specific use case (maybe test 
> runs).

Is the issue the flush is before an infinite loop which means the UART FIFO
should drain?

> I don't really like the new bsp_flush_kernel_char_output() function. Another
> approach could be an API change of
> 
> /**
>  * @ingroup RTEMSAPIKernelCharIO
>  *
>  * @brief Polled character output functions shall have this type.
>  */
> typedef void ( *BSP_output_char_function_type )( char );
> 
> to something like this
> 
> typedef int ( *BSP_output_char_function_type )( int action );
> 
> If action in {0, ..., 255}, then print out the character. If 0x100 is set, 
> then
> flush the output device. If 0x200 is set, then do Y... The return value could 
> be
> used to give a status indication.
> 
> This could then be use for example by test runs, to flush the test output 
> after
> the end of the test.

This also requires a code change so is a flush function that bad an option?

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

Re: [PATCH 1/5] bsps: Use bsps/aarch64/xilinx-zynqmp

[Sebastian Huber]

On 19.03.24 18:34, Chris Johns wrote:

I will build the BSPs for each commit today.

Thanks. The reason I raised this is GitLab can squash merges to `main` and the
reason is always being able to bisect `main` so it is an issue being considered.
This patch set made me wonder what we do now?


I would definitely not squash commits when they are merged. This would 
make the history more difficult to review and would also complicate 
things if a specific commit breaks something. The more commits you have 
the easier it is to single out the trouble maker.


--
embedded brains GmbH & Co. KG
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 1/5] bsps: Use bsps/aarch64/xilinx-zynqmp

[Chris Johns]

On 19/3/2024 5:59 pm, Sebastian Huber wrote:
> On 19.03.24 03:21, Chris Johns wrote:
>> Does this patch series build at the per commit level?
> 
> I used
> 
> ./waf bspdefaults > a.txt
> apply patch
> ./waf bspdefaults > b.txt
> diff a.txt b.txt
> 
> to check that the defaults don't change.

Great.

> I will build the BSPs for each commit today.

Thanks. The reason I raised this is GitLab can squash merges to `main` and the
reason is always being able to bisect `main` so it is an issue being considered.
This patch set made me wonder what we do now?

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

Re: [PATCH 3/5] xilinx-zynqmp-rpu: Remove URLs from copyrights

[Chris Johns]

On 19/3/2024 5:52 pm, Sebastian Huber wrote:
> On 19.03.24 03:20, Chris Johns wrote:
>> On 19/3/2024 3:30 am, Sebastian Huber wrote:
>>> ---
>>>   spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml    | 2 +-
>>>   spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml  | 2 +-
>>>   spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml   | 2 +-
>>>   spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml | 2 +-
>>>   4 files changed, 4 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
>>> b/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
>>> index ba70c44d7d..06795eb416 100644
>>> --- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
>>> +++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
>>> @@ -5,7 +5,7 @@ actions:
>>>   - env-append: null
>>>   build-type: option
>>>   copyrights:
>>> -- Copyright (C) 2023 Reflex Aerospace GmbH 
>>> (https://www.reflexaerospace.com/  )
>>> +- Copyright (C) 2023 Reflex Aerospace GmbH
>> Why this change?
> 
> When I updated our company name to embedded brains GmbH & Co. KG, I removed 
> the
> URLs from our copyright statements since we were basically the only ones doing
> this. If you don't have an issue with the URLs, then I will discuss internally
> if we would like to add them again to our copyright statements.

This is fine. I was wondering if there was some technical reason which there is 
not.

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

Re: [PATCH 3/5] xilinx-zynqmp-rpu: Remove URLs from copyrights

[Philip Kirkpatrick]

Sebastian,

Looks good with me.  Stanislav also gave approval.

-Phil

From: Stanislav Pankevich 
Sent: Tuesday, March 19, 2024 5:45 PM
To: Philip Kirkpatrick 
Subject: WG: [PATCH 3/5] xilinx-zynqmp-rpu: Remove URLs from copyrights



Von: Sebastian Huber 
Gesendet: Dienstag, 19. März 2024 16:46
An: Stanislav Pankevich 
Betreff: Fwd: [PATCH 3/5] xilinx-zynqmp-rpu: Remove URLs from copyrights

Hello Stanislav,

it would be nice if you could approve or disapprove this change on the
RTEMS mailing list.

I guess you used our old copyright statement as a template, but we
removed the URL since it was quite uncommon to do this.

 Forwarded Message 
Subject: [PATCH 3/5] xilinx-zynqmp-rpu: Remove URLs from copyrights
Date: Mon, 18 Mar 2024 17:30:04 +0100
From: Sebastian Huber 
To: devel@rtems.org

---
  spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml| 2 +-
  spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml  | 2 +-
  spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml   | 2 +-
  spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml | 2 +-
  4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
b/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
index ba70c44d7d..06795eb416 100644
--- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
+++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
@@ -5,7 +5,7 @@ actions:
  - env-append: null
  build-type: option
  copyrights:
-- Copyright (C) 2023 Reflex Aerospace GmbH (
https://www.reflexaerospace.com/ )
+- Copyright (C) 2023 Reflex Aerospace GmbH
  default:
  - enabled-by: true
value:
diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
b/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
index d08f048060..3fa210d8e7 100644
--- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
+++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
@@ -4,7 +4,7 @@ bsp: xilinx_zynqmp_mercuryxu5_rpu
  build-type: bsp
  cflags: []
  copyrights:
-- Copyright (C) 2023 Reflex Aerospace GmbH (
https://www.reflexaerospace.com/ )
+- Copyright (C) 2023 Reflex Aerospace GmbH
  cppflags: []
  enabled-by: true
  family: xilinx-zynqmp-rpu
diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml
b/spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml
index a3654f3f42..9c8a6d1cd6 100644
--- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml
+++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml
@@ -38,7 +38,7 @@ content: |
_stack_end = bsp_section_stack_end;
__undef_stack = bsp_section_stack_begin;
  copyrights:
-- Copyright (C) 2023 Reflex Aerospace GmbH (
https://www.reflexaerospace.com/ )
+- Copyright (C) 2023 Reflex Aerospace GmbH
  enabled-by: true
  install-path: ${BSP_LIBDIR}
  links: []
diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml
b/spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml
index 09a3965906..d684f5a06d 100644
--- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml
+++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml
@@ -4,7 +4,7 @@ actions:
  - define-condition: null
  build-type: option
  copyrights:
-- Copyright (C) 2023 Reflex Aerospace GmbH (
https://www.reflexaerospace.com/ )
+- Copyright (C) 2023 Reflex Aerospace GmbH
  default:
  - enabled-by: true
value: true
--
2.35.3

___
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: utf32 support

[John Howard]

A 32 bit character type is supported by FreeBSD.

Unicode 2012 says utf32 must be a 32 bit signed integer. Unicode only defines 
the Codepoint character attribute.

RTEMS now uses libBSD and newlib. Need kernel to support the Codepoint range of 
values. Applications can then use additional user-defined character attributes.

— John

P.S.: UTF32 exists for Unicode in 2012 after consolidation from ISO 10646-2012. 
The two standards merged.

On Mar 19, 2024, at 6:20 AM, Frank Kühndel  
wrote:

Hello John,

just a side node:

Strictly speaking UTF32 does not exist [1]. The correct name is UCS-4 (i.e 
store each character in four bytes). "Current plans are that there will never 
be characters assigned outside the 21-bit code space from 0x00 to 0x10" 
[2].

References:

[1] Section "Unicode encodings" in 
https://tldp.org/HOWTO/Unicode-HOWTO-1.html#ss1.2

[2] Section "What are UCS and ISO 10646?" in 
https://www.cl.cam.ac.uk/~mgk25/unicode.html

Greetings,
fk

> On 3/18/24 19:02, Gedare Bloom wrote:
> I think it would be wchar_t support in newlib.
>> On Mon, Mar 18, 2024 at 11:56 AM Joel Sherrill  wrote:
>> What does support for UTF-32 entail? Do you have an idea what software 
>> functions you are looking for?
>> 
>> I see the International Components for Unicode (ICU) has a converter 
>> (https://icu.unicode.org/download) which looks it might be part of a 
>> solution.
>> 
>> Multibyte character methods defined by POSIX would be in newlib.
>> 
>> I'm not well versed in this area so have questions but I think it basically 
>> comes down to what software libraries an application needs and porting those 
>> to RTEMS -- assuming the license is ok.
>> 
>> --joel
>> 
>>> On Mon, Mar 18, 2024 at 12:15 PM John Howard  wrote:
>>> I want to add utf32 support.
>>> 
>>> Where do I start?
>>> 
>>> — John
>>> ___
>>> 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

-- 
embedded brains GmbH & Co. KG
Herr Frank KÜHNDEL
Dornierstr. 4
82178 Puchheim
Germany
email: frank.kuehn...@embedded-brains.de
phone:  +49-89-18 94 741 - 23
mobile: +49-176-15 22 06 - 11

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

[PATCH] dev/irq: Optional arm_gic_irq_processor_count()

[Sebastian Huber]

Provide arm_gic_irq_processor_count() only in SMP configurations.
---
 bsps/include/dev/irq/arm-gic-irq.h | 2 ++
 bsps/shared/dev/irq/arm-gicv2.c| 2 ++
 bsps/shared/dev/irq/arm-gicv3.c| 2 ++
 3 files changed, 6 insertions(+)

diff --git a/bsps/include/dev/irq/arm-gic-irq.h 
b/bsps/include/dev/irq/arm-gic-irq.h
index 3c875917df..b3487176f6 100644
--- a/bsps/include/dev/irq/arm-gic-irq.h
+++ b/bsps/include/dev/irq/arm-gic-irq.h
@@ -113,9 +113,11 @@ static inline rtems_status_code 
arm_gic_irq_generate_software_irq(
   return sc;
 }
 
+#ifdef RTEMS_SMP
 uint32_t arm_gic_irq_processor_count(void);
 
 void arm_gic_irq_initialize_secondary_cpu(void);
+#endif
 
 #ifdef __cplusplus
 }
diff --git a/bsps/shared/dev/irq/arm-gicv2.c b/bsps/shared/dev/irq/arm-gicv2.c
index 49d6e60634..e0abf4c96d 100644
--- a/bsps/shared/dev/irq/arm-gicv2.c
+++ b/bsps/shared/dev/irq/arm-gicv2.c
@@ -402,9 +402,11 @@ void arm_gic_trigger_sgi(rtems_vector_number vector, 
uint32_t targets)
 | GIC_DIST_ICDSGIR_SGIINTID(vector);
 }
 
+#ifdef RTEMS_SMP
 uint32_t arm_gic_irq_processor_count(void)
 {
   volatile gic_dist *dist = ARM_GIC_DIST;
 
   return GIC_DIST_ICDICTR_CPU_NUMBER_GET(dist->icdictr) + 1;
 }
+#endif
diff --git a/bsps/shared/dev/irq/arm-gicv3.c b/bsps/shared/dev/irq/arm-gicv3.c
index 4772ff5db4..108d64348a 100644
--- a/bsps/shared/dev/irq/arm-gicv3.c
+++ b/bsps/shared/dev/irq/arm-gicv3.c
@@ -280,6 +280,7 @@ void arm_gic_trigger_sgi(rtems_vector_number vector, 
uint32_t targets)
   gicv3_trigger_sgi(vector, targets);
 }
 
+#ifdef RTEMS_SMP
 uint32_t arm_gic_irq_processor_count(void)
 {
   volatile gic_dist *dist = ARM_GIC_DIST;
@@ -306,3 +307,4 @@ uint32_t arm_gic_irq_processor_count(void)
 
   return cpu_count;
 }
+#endif
-- 
2.35.3

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

Re: [PATCH v2] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT BSP option

[Sebastian Huber]

On 19.03.24 14:50, Kinsey Moore wrote:
The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the 
spec file for the new option. Its family differs from the 
arm/xilinx-zynqmp BSP family with a -rpu suffix.


Yes, but this BSP is quite new. I would prefer to let it not flush 
anything by default to carry out a reset.


I'd be fine with this 
being enabled for the AArch64 BSPs as well, but I imagine that's better 
as a separate patch.


Why should it be enabled by default? The arm/xilinx-zynq and 
arm/xilinx-zynqmp BSPs were the only ones doing an UART flush in the 
general termination procedure. It probably was done to address a 
specific use case (maybe test runs).


I don't really like the new bsp_flush_kernel_char_output() function. 
Another approach could be an API change of


/**
 * @ingroup RTEMSAPIKernelCharIO
 *
 * @brief Polled character output functions shall have this type.
 */
typedef void ( *BSP_output_char_function_type )( char );

to something like this

typedef int ( *BSP_output_char_function_type )( int action );

If action in {0, ..., 255}, then print out the character. If 0x100 is 
set, then flush the output device. If 0x200 is set, then do Y... The 
return value could be used to give a status indication.


This could then be use for example by test runs, to flush the test 
output after the end of the test.


--
embedded brains GmbH & Co. KG
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 v2] user: Add docu for use of Rust with RTEMS

[Frank Kühndel]

Hi Chris,

On 3/19/24 03:24, Chris Johns wrote:

On 16/3/2024 1:14 am, Frank Kühndel wrote:

Ping!

The last discussion of this patch was
https://lists.rtems.org/pipermail/devel/2024-February/077289.html

Does the fact that I recive no further comments to this patch mean it can be
pushed to the RTEMS User Manual as it is?

Sorry Frank, I have been busy with other changes. It is on my list but I have
will need to reread the thread when I have time.


No problem. This can wait.

Greetings,
Frank

--
embedded brains GmbH & Co. KG
Herr Frank KÜHNDEL
Dornierstr. 4
82178 Puchheim
Germany
email: frank.kuehn...@embedded-brains.de
phone:  +49-89-18 94 741 - 23
mobile: +49-176-15 22 06 - 11

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

Re: [PATCH v2] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT BSP option

[Kinsey Moore]

The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the spec
file for the new option. Its family differs from the arm/xilinx-zynqmp BSP
family with a -rpu suffix. I'd be fine with this being enabled for the
AArch64 BSPs as well, but I imagine that's better as a separate patch.

Kinsey

On Tue, Mar 19, 2024 at 3:39 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> Make the kernel I/O output character device flushing configurable.  The
> bsp_reset() function should reset the unit and do nothing else.
>
> The arm/xilinx-zynq and arm/xilinx-zynqmp BSPs were the only ones doing an
> UART
> flush in bsp_reset().  The bsp_reset() function should reset the system
> and do
> nothing more.  Doing additional things like flushing an UART device may not
> make sense for all applications.  Some applications may not use the UART
> device, so it may not be initialized and powered off.  Some applications
> may
> use it with an application-specific protocol which doesn't like the
> additional
> four '\r' during reset.  Doing a UART flush takes some time and some
> applications may prefer a fast reset cycle.  The bsp_reset() is the wrong
> place
> to do specific cleanup functions.
>
> Flushing the kernel I/O output character device is now optionally done in
> bsp_fatal_extension() depending on the new BSP option
> BSP_FLUSH_KERNEL_CHAR_OUTPUT.
> ---
>  bsps/aarch64/xilinx-zynqmp/console/console.c  |  3 ++-
>  bsps/aarch64/xilinx-zynqmp/include/bsp.h  |  2 --
>  bsps/arm/xilinx-zynq/console/debug-console.c  | 10 +
>  bsps/arm/xilinx-zynq/start/bspreset.c |  4 
>  .../console/console-config.c  |  3 ++-
>  bsps/arm/xilinx-zynqmp-rpu/include/bsp.h  |  2 --
>  bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c   |  3 ---
>  .../xilinx-zynqmp/console/console-config.c|  2 +-
>  bsps/arm/xilinx-zynqmp/include/bsp.h  |  2 --
>  bsps/arm/xilinx-zynqmp/start/bspreset.c   |  4 +---
>  bsps/include/bsp/bootcard.h   |  5 +
>  bsps/shared/start/bspfatal-default.c  |  4 
>  spec/build/bsps/bspopts.yml   |  2 ++
>  spec/build/bsps/optflushkerncharout.yml   | 22 +++
>  14 files changed, 49 insertions(+), 19 deletions(-)
>  create mode 100644 spec/build/bsps/optflushkerncharout.yml
>
> diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c
> b/bsps/aarch64/xilinx-zynqmp/console/console.c
> index 9ce0b1da63..d1b2850952 100644
> --- a/bsps/aarch64/xilinx-zynqmp/console/console.c
> +++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
> @@ -41,6 +41,7 @@
>  #include 
>
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -234,7 +235,7 @@ rtems_status_code console_initialize(
>return RTEMS_SUCCESSFUL;
>  }
>
> -void zynqmp_debug_console_flush(void)
> +void bsp_flush_kernel_char_output(void)
>  {
>zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
>  }
> diff --git a/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> index 0ccca8b196..d36abde415 100644
> --- a/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> +++ b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> @@ -86,8 +86,6 @@ BSP_START_TEXT_SECTION void
> zynqmp_setup_mmu_and_cache(void);
>   */
>  BSP_START_TEXT_SECTION void zynqmp_setup_secondary_cpu_mmu_and_cache(
> void );
>
> -void zynqmp_debug_console_flush(void);
> -
>  uint32_t zynqmp_clock_i2c0(void);
>
>  uint32_t zynqmp_clock_i2c1(void);
> diff --git a/bsps/arm/xilinx-zynq/console/debug-console.c
> b/bsps/arm/xilinx-zynq/console/debug-console.c
> index d398ca7988..67fcbdf4a1 100644
> --- a/bsps/arm/xilinx-zynq/console/debug-console.c
> +++ b/bsps/arm/xilinx-zynq/console/debug-console.c
> @@ -38,10 +38,20 @@
>  #include 
>
>  #include 
> +#include 
>  #include 
> +#include 
>
>  #include 
>
> +void bsp_flush_kernel_char_output(void)
> +{
> +  rtems_termios_device_context *base =
> +_uart_instances[BSP_CONSOLE_MINOR].base;
> +
> +  zynq_uart_reset_tx_flush(base);
> +}
> +
>  static void zynq_debug_console_out(char c)
>  {
>rtems_termios_device_context *base =
> diff --git a/bsps/arm/xilinx-zynq/start/bspreset.c
> b/bsps/arm/xilinx-zynq/start/bspreset.c
> index f8cc3b6999..fcdb1b8ded 100644
> --- a/bsps/arm/xilinx-zynq/start/bspreset.c
> +++ b/bsps/arm/xilinx-zynq/start/bspreset.c
> @@ -33,17 +33,13 @@
>   * POSSIBILITY OF SUCH DAMAGE.
>   */
>
> -#include 
>  #include 
> -#include 
>
>  void bsp_reset(void)
>  {
>volatile uint32_t *slcr_unlock = (volatile uint32_t *) 0xf808;
>volatile uint32_t *pss_rst_ctrl = (volatile uint32_t *) 0xf8000200;
>
> -  zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
> -
>while (true) {
>  *slcr_unlock = 0xdf0d;
>  *pss_rst_ctrl = 0x1;
> diff --git a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
> b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
> index f52e008f2b..196b2dec58 100644
> --- a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
> +++ 

AW: bsps: xilinx-zynqmp-rpu: fix the integer truncation in Triple Timer Counter clock driver

[Stanislav Pankevich]

Hello Sebastian,

I have also reviewed the other changes that we now have since the original BSP 
patch, and it looks like our current queue for Zynq RPU is empty.

We are curious to see which changes/rework for RPU you are preparing.

Thanks,
Stanislav


Von: Sebastian Huber 
Gesendet: Dienstag, 19. März 2024 11:50
An: Stanislav Pankevich ; devel@rtems.org 

Betreff: Re: bsps: xilinx-zynqmp-rpu: fix the integer truncation in Triple 
Timer Counter clock driver

[Sie erhalten nicht häufig E-Mails von sebastian.hu...@embedded-brains.de. 
Weitere Informationen, warum dies wichtig ist, finden Sie unter 
https://aka.ms/LearnAboutSenderIdentification ]

Hello Stanislav,

that is a nice coincidence. I started to work with this BSP last week
and I also fixed this issue, but I had some other patches in the queue.
I reworked this driver a bit. I will check in your patch first.

On 19.03.24 10:54, Stanislav Pankevich wrote:
> Dear RTEMS developers,
>
> Here is a follow-up patch to our previous work on the Zynq US+ RPU BSP.
>
> In fact, we had fixed this issue a few months ago but didn't find a good
> time to upstream it since then.
>
> P.S. It is great to see that the migration to GitLab is happening.
>
> Thanks,
> Stanislav
>
> ---
>
> Author: Stanislav Pankevich 
> Date:   Tue Mar 19 10:34:57 2024 +0100
>
>  bsps: xilinx-zynqmp-rpu: fix the integer truncation in Triple Timer
> Counter clock driver
>  We observed a strange behavior of the 1Hz timer when running cFS on
> Zynq RPU. After some investigation, we reduced the error to the
> truncation issue. This patch fixes the issue.
>
> diff --git a/bsps/shared/dev/clock/xil-ttc.c
> b/bsps/shared/dev/clock/xil-ttc.c
> index 2c47684045..5121773a6f 100644
> --- a/bsps/shared/dev/clock/xil-ttc.c
> +++ b/bsps/shared/dev/clock/xil-ttc.c
> @@ -126,7 +126,7 @@ static void
> zynqmp_ttc_clock_driver_support_initialize_hardware(void)
> /* Setup match register to generate tick IRQ */
> ttc_clock_instance.irq_match_interval =
> -(uint32_t) ((frequency * microsec_per_tick) / 100);
> +(uint32_t) (((uint64_t)frequency * microsec_per_tick) / 100);
> XTtcPs_WriteReg(BSP_SELECTED_TTC_ADDR, XTTCPS_MATCH_0_OFFSET,
> ttc_clock_instance.irq_match_interval);
> /* Clear interupts (clear on read) */
>
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel

--
embedded brains GmbH & Co. KG
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: utf32 support

[Frank Kühndel]

Hello John,

just a side node:

Strictly speaking UTF32 does not exist [1]. The correct name is UCS-4 
(i.e store each character in four bytes). "Current plans are that there 
will never be characters assigned outside the 21-bit code space from 
0x00 to 0x10" [2].


References:

[1] Section "Unicode encodings" in 
https://tldp.org/HOWTO/Unicode-HOWTO-1.html#ss1.2


[2] Section "What are UCS and ISO 10646?" in 
https://www.cl.cam.ac.uk/~mgk25/unicode.html


Greetings,
fk

On 3/18/24 19:02, Gedare Bloom wrote:

I think it would be wchar_t support in newlib.

On Mon, Mar 18, 2024 at 11:56 AM Joel Sherrill  wrote:

What does support for UTF-32 entail? Do you have an idea what software 
functions you are looking for?

I see the International Components for Unicode (ICU) has a converter 
(https://icu.unicode.org/download) which looks it might be part of a solution.

Multibyte character methods defined by POSIX would be in newlib.

I'm not well versed in this area so have questions but I think it basically 
comes down to what software libraries an application needs and porting those to 
RTEMS -- assuming the license is ok.

--joel

On Mon, Mar 18, 2024 at 12:15 PM John Howard  wrote:

I want to add utf32 support.

Where do I start?

— John
___
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



--
embedded brains GmbH & Co. KG
Herr Frank KÜHNDEL
Dornierstr. 4
82178 Puchheim
Germany
email: frank.kuehn...@embedded-brains.de
phone:  +49-89-18 94 741 - 23
mobile: +49-176-15 22 06 - 11

Registergericht: Amtsgericht München
Registernummer: HRA 117265
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: bsps: xilinx-zynqmp-rpu: fix the integer truncation in Triple Timer Counter clock driver

[Sebastian Huber]

Hello Stanislav,

that is a nice coincidence. I started to work with this BSP last week 
and I also fixed this issue, but I had some other patches in the queue. 
I reworked this driver a bit. I will check in your patch first.


On 19.03.24 10:54, Stanislav Pankevich wrote:

Dear RTEMS developers,

Here is a follow-up patch to our previous work on the Zynq US+ RPU BSP.

In fact, we had fixed this issue a few months ago but didn't find a good 
time to upstream it since then.


P.S. It is great to see that the migration to GitLab is happening.

Thanks,
Stanislav

---

Author: Stanislav Pankevich 
Date:   Tue Mar 19 10:34:57 2024 +0100

     bsps: xilinx-zynqmp-rpu: fix the integer truncation in Triple Timer 
Counter clock driver
     We observed a strange behavior of the 1Hz timer when running cFS on 
Zynq RPU. After some investigation, we reduced the error to the 
truncation issue. This patch fixes the issue.


diff --git a/bsps/shared/dev/clock/xil-ttc.c 
b/bsps/shared/dev/clock/xil-ttc.c

index 2c47684045..5121773a6f 100644
--- a/bsps/shared/dev/clock/xil-ttc.c
+++ b/bsps/shared/dev/clock/xil-ttc.c
@@ -126,7 +126,7 @@ static void 
zynqmp_ttc_clock_driver_support_initialize_hardware(void)

    /* Setup match register to generate tick IRQ */
    ttc_clock_instance.irq_match_interval =
-    (uint32_t) ((frequency * microsec_per_tick) / 100);
+    (uint32_t) (((uint64_t)frequency * microsec_per_tick) / 100);
    XTtcPs_WriteReg(BSP_SELECTED_TTC_ADDR, XTTCPS_MATCH_0_OFFSET,
                    ttc_clock_instance.irq_match_interval);
    /* Clear interupts (clear on read) */


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


--
embedded brains GmbH & Co. KG
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

bsps: xilinx-zynqmp-rpu: fix the integer truncation in Triple Timer Counter clock driver

[Stanislav Pankevich]

Dear RTEMS developers,

Here is a follow-up patch to our previous work on the Zynq US+ RPU BSP.

In fact, we had fixed this issue a few months ago but didn't find a good time 
to upstream it since then.

P.S. It is great to see that the migration to GitLab is happening.

Thanks,
Stanislav

---

Author: Stanislav Pankevich 
Date:   Tue Mar 19 10:34:57 2024 +0100

bsps: xilinx-zynqmp-rpu: fix the integer truncation in Triple Timer Counter 
clock driver

We observed a strange behavior of the 1Hz timer when running cFS on Zynq 
RPU. After some investigation, we reduced the error to the truncation issue. 
This patch fixes the issue.

diff --git a/bsps/shared/dev/clock/xil-ttc.c b/bsps/shared/dev/clock/xil-ttc.c
index 2c47684045..5121773a6f 100644
--- a/bsps/shared/dev/clock/xil-ttc.c
+++ b/bsps/shared/dev/clock/xil-ttc.c
@@ -126,7 +126,7 @@ static void 
zynqmp_ttc_clock_driver_support_initialize_hardware(void)

   /* Setup match register to generate tick IRQ */
   ttc_clock_instance.irq_match_interval =
-(uint32_t) ((frequency * microsec_per_tick) / 100);
+(uint32_t) (((uint64_t)frequency * microsec_per_tick) / 100);
   XTtcPs_WriteReg(BSP_SELECTED_TTC_ADDR, XTTCPS_MATCH_0_OFFSET,
   ttc_clock_instance.irq_match_interval);
   /* Clear interupts (clear on read) */

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

[PATCH v2] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT BSP option

[Sebastian Huber]

Make the kernel I/O output character device flushing configurable.  The
bsp_reset() function should reset the unit and do nothing else.

The arm/xilinx-zynq and arm/xilinx-zynqmp BSPs were the only ones doing an UART
flush in bsp_reset().  The bsp_reset() function should reset the system and do
nothing more.  Doing additional things like flushing an UART device may not
make sense for all applications.  Some applications may not use the UART
device, so it may not be initialized and powered off.  Some applications may
use it with an application-specific protocol which doesn't like the additional
four '\r' during reset.  Doing a UART flush takes some time and some
applications may prefer a fast reset cycle.  The bsp_reset() is the wrong place
to do specific cleanup functions.

Flushing the kernel I/O output character device is now optionally done in
bsp_fatal_extension() depending on the new BSP option
BSP_FLUSH_KERNEL_CHAR_OUTPUT.
---
 bsps/aarch64/xilinx-zynqmp/console/console.c  |  3 ++-
 bsps/aarch64/xilinx-zynqmp/include/bsp.h  |  2 --
 bsps/arm/xilinx-zynq/console/debug-console.c  | 10 +
 bsps/arm/xilinx-zynq/start/bspreset.c |  4 
 .../console/console-config.c  |  3 ++-
 bsps/arm/xilinx-zynqmp-rpu/include/bsp.h  |  2 --
 bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c   |  3 ---
 .../xilinx-zynqmp/console/console-config.c|  2 +-
 bsps/arm/xilinx-zynqmp/include/bsp.h  |  2 --
 bsps/arm/xilinx-zynqmp/start/bspreset.c   |  4 +---
 bsps/include/bsp/bootcard.h   |  5 +
 bsps/shared/start/bspfatal-default.c  |  4 
 spec/build/bsps/bspopts.yml   |  2 ++
 spec/build/bsps/optflushkerncharout.yml   | 22 +++
 14 files changed, 49 insertions(+), 19 deletions(-)
 create mode 100644 spec/build/bsps/optflushkerncharout.yml

diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c 
b/bsps/aarch64/xilinx-zynqmp/console/console.c
index 9ce0b1da63..d1b2850952 100644
--- a/bsps/aarch64/xilinx-zynqmp/console/console.c
+++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
@@ -41,6 +41,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -234,7 +235,7 @@ rtems_status_code console_initialize(
   return RTEMS_SUCCESSFUL;
 }
 
-void zynqmp_debug_console_flush(void)
+void bsp_flush_kernel_char_output(void)
 {
   zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
 }
diff --git a/bsps/aarch64/xilinx-zynqmp/include/bsp.h 
b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
index 0ccca8b196..d36abde415 100644
--- a/bsps/aarch64/xilinx-zynqmp/include/bsp.h
+++ b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
@@ -86,8 +86,6 @@ BSP_START_TEXT_SECTION void zynqmp_setup_mmu_and_cache(void);
  */
 BSP_START_TEXT_SECTION void zynqmp_setup_secondary_cpu_mmu_and_cache( void );
 
-void zynqmp_debug_console_flush(void);
-
 uint32_t zynqmp_clock_i2c0(void);
 
 uint32_t zynqmp_clock_i2c1(void);
diff --git a/bsps/arm/xilinx-zynq/console/debug-console.c 
b/bsps/arm/xilinx-zynq/console/debug-console.c
index d398ca7988..67fcbdf4a1 100644
--- a/bsps/arm/xilinx-zynq/console/debug-console.c
+++ b/bsps/arm/xilinx-zynq/console/debug-console.c
@@ -38,10 +38,20 @@
 #include 
 
 #include 
+#include 
 #include 
+#include 
 
 #include 
 
+void bsp_flush_kernel_char_output(void)
+{
+  rtems_termios_device_context *base =
+_uart_instances[BSP_CONSOLE_MINOR].base;
+
+  zynq_uart_reset_tx_flush(base);
+}
+
 static void zynq_debug_console_out(char c)
 {
   rtems_termios_device_context *base =
diff --git a/bsps/arm/xilinx-zynq/start/bspreset.c 
b/bsps/arm/xilinx-zynq/start/bspreset.c
index f8cc3b6999..fcdb1b8ded 100644
--- a/bsps/arm/xilinx-zynq/start/bspreset.c
+++ b/bsps/arm/xilinx-zynq/start/bspreset.c
@@ -33,17 +33,13 @@
  * POSSIBILITY OF SUCH DAMAGE.
  */
 
-#include 
 #include 
-#include 
 
 void bsp_reset(void)
 {
   volatile uint32_t *slcr_unlock = (volatile uint32_t *) 0xf808;
   volatile uint32_t *pss_rst_ctrl = (volatile uint32_t *) 0xf8000200;
 
-  zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
-
   while (true) {
 *slcr_unlock = 0xdf0d;
 *pss_rst_ctrl = 0x1;
diff --git a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c 
b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
index f52e008f2b..196b2dec58 100644
--- a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
+++ b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -79,7 +80,7 @@ rtems_status_code console_initialize(
   return RTEMS_SUCCESSFUL;
 }
 
-void zynqmp_debug_console_flush(void)
+void bsp_flush_kernel_char_output(void)
 {
   zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
 }
diff --git a/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h 
b/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
index e386bd4b26..060147967c 100644
--- a/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
+++ b/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
@@ -83,8 +83,6 @@ extern "C" {
 

Re: [PATCH 1/5] bsps: Use bsps/aarch64/xilinx-zynqmp

[Sebastian Huber]

On 19.03.24 03:21, Chris Johns wrote:

Does this patch series build at the per commit level?


I used

./waf bspdefaults > a.txt
apply patch
./waf bspdefaults > b.txt
diff a.txt b.txt

to check that the defaults don't change. I will build the BSPs for each 
commit today.


--
embedded brains GmbH & Co. KG
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] improved error checking in ticks per timeslice

[Sebastian Huber]

On 18.03.24 21:31, Kinsey Moore wrote:
Sorry, I didn't realize I had tests turned off in my local build when I 
checked this. The test is now gated behind NEEDS_CLOCK_DRIVER as well.


This is fine for fixing the build, but I would rather fix the tests. 
Applications may have there own clock driver for example.


--
embedded brains GmbH & Co. KG
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] xilinx-zynqmp-rpu: Remove URLs from copyrights

[Sebastian Huber]

On 19.03.24 03:20, Chris Johns wrote:

On 19/3/2024 3:30 am, Sebastian Huber wrote:

---
  spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml| 2 +-
  spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml  | 2 +-
  spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml   | 2 +-
  spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml | 2 +-
  4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml 
b/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
index ba70c44d7d..06795eb416 100644
--- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
+++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
@@ -5,7 +5,7 @@ actions:
  - env-append: null
  build-type: option
  copyrights:
-- Copyright (C) 2023 Reflex Aerospace GmbH (https://www.reflexaerospace.com/  )
+- Copyright (C) 2023 Reflex Aerospace GmbH

Why this change?


When I updated our company name to embedded brains GmbH & Co. KG, I 
removed the URLs from our copyright statements since we were basically 
the only ones doing this. If you don't have an issue with the URLs, then 
I will discuss internally if we would like to add them again to our 
copyright statements.


--
embedded brains GmbH & Co. KG
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] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT option

[Sebastian Huber]

On 19.03.24 03:16, Chris Johns wrote:

On 19/3/2024 3:49 am, Sebastian Huber wrote:

Make the kernel I/O output character device flushing configurable.  The
bsp_reset() function should reset the unit and do nothing else.
---
  bsps/aarch64/xilinx-zynqmp/console/console.c  |  3 ++-
  bsps/aarch64/xilinx-zynqmp/include/bsp.h  |  2 --
  .../console/console-config.c  |  3 ++-
  bsps/arm/xilinx-zynqmp-rpu/include/bsp.h  |  2 --
  bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c   |  3 ---
  .../xilinx-zynqmp/console/console-config.c|  2 +-
  bsps/arm/xilinx-zynqmp/include/bsp.h  |  2 --
  bsps/arm/xilinx-zynqmp/start/bspreset.c   |  4 +---
  bsps/include/bsp/bootcard.h   |  5 +
  bsps/shared/start/bspfatal-default.c  |  4 
  spec/build/bsps/bspopts.yml   |  2 ++
  spec/build/bsps/optflushkerncharout.yml   | 20 +++
  12 files changed, 37 insertions(+), 15 deletions(-)
  create mode 100644 spec/build/bsps/optflushkerncharout.yml

diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c 
b/bsps/aarch64/xilinx-zynqmp/console/console.c
index 9ce0b1da63..d1b2850952 100644
--- a/bsps/aarch64/xilinx-zynqmp/console/console.c
+++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
@@ -41,6 +41,7 @@
  #include 
  
  #include 

+#include 
  #include 
  #include 
  
@@ -234,7 +235,7 @@ rtems_status_code console_initialize(

return RTEMS_SUCCESSFUL;
  }
  
-void zynqmp_debug_console_flush(void)

+void bsp_flush_kernel_char_output(void)
  {
zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
  }
diff --git a/bsps/aarch64/xilinx-zynqmp/include/bsp.h 
b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
index 0ccca8b196..d36abde415 100644
--- a/bsps/aarch64/xilinx-zynqmp/include/bsp.h
+++ b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
@@ -86,8 +86,6 @@ BSP_START_TEXT_SECTION void zynqmp_setup_mmu_and_cache(void);
   */
  BSP_START_TEXT_SECTION void zynqmp_setup_secondary_cpu_mmu_and_cache( void );
  
-void zynqmp_debug_console_flush(void);

-
  uint32_t zynqmp_clock_i2c0(void);
  
  uint32_t zynqmp_clock_i2c1(void);

diff --git a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c 
b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
index f52e008f2b..196b2dec58 100644
--- a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
+++ b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
@@ -35,6 +35,7 @@
  #include 
  #include 
  
+#include 

  #include 
  #include 
  
@@ -79,7 +80,7 @@ rtems_status_code console_initialize(

return RTEMS_SUCCESSFUL;
  }
  
-void zynqmp_debug_console_flush(void)

+void bsp_flush_kernel_char_output(void)
  {
zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
  }
diff --git a/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h 
b/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
index e386bd4b26..060147967c 100644
--- a/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
+++ b/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
@@ -83,8 +83,6 @@ extern "C" {
   */
  BSP_START_TEXT_SECTION void zynqmp_setup_mpu_and_cache(void);
  
-void zynqmp_debug_console_flush(void);

-
  #ifdef __cplusplus
  }
  #endif /* __cplusplus */
diff --git a/bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c 
b/bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c
index eecb4da838..a894f55f6e 100644
--- a/bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c
+++ b/bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c
@@ -30,13 +30,10 @@
   * POSSIBILITY OF SUCH DAMAGE.
   */
  
-#include 

  #include 
  
  void bsp_reset(void)

  {
-  zynqmp_debug_console_flush();


Why remove the call here?


-
while (true) {
  /* Wait */
}


This BSP is rather new. Flushing the UART followed by an infinite loop 
doesn't really make sense. I did a full test run for this BSP and there 
are some more things to fix.



diff --git a/bsps/arm/xilinx-zynqmp/console/console-config.c 
b/bsps/arm/xilinx-zynqmp/console/console-config.c
index eadd7f11a2..360d193ba2 100644
--- a/bsps/arm/xilinx-zynqmp/console/console-config.c
+++ b/bsps/arm/xilinx-zynqmp/console/console-config.c
@@ -81,7 +81,7 @@ rtems_status_code console_initialize(
return RTEMS_SUCCESSFUL;
  }
  
-void zynqmp_debug_console_flush(void)

+void bsp_flush_kernel_char_output(void)
  {
zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
  }
diff --git a/bsps/arm/xilinx-zynqmp/include/bsp.h 
b/bsps/arm/xilinx-zynqmp/include/bsp.h
index a08a5feee9..2785e4c2e0 100644
--- a/bsps/arm/xilinx-zynqmp/include/bsp.h
+++ b/bsps/arm/xilinx-zynqmp/include/bsp.h
@@ -79,8 +79,6 @@ extern "C" {
   */
  BSP_START_TEXT_SECTION void zynqmp_setup_mmu_and_cache(void);
  
-void zynqmp_debug_console_flush(void);

-
  #ifdef __cplusplus
  }
  #endif /* __cplusplus */
diff --git a/bsps/arm/xilinx-zynqmp/start/bspreset.c 
b/bsps/arm/xilinx-zynqmp/start/bspreset.c
index b43b19b05f..ed2f4da83a 100644
--- a/bsps/arm/xilinx-zynqmp/start/bspreset.c
+++ b/bsps/arm/xilinx-zynqmp/start/bspreset.c
@@ -30,12 +30,10 @@
   * POSSIBILITY OF SUCH 

Re: [PATCH v2] user: Add docu for use of Rust with RTEMS

[Chris Johns]

On 16/3/2024 1:14 am, Frank Kühndel wrote:
> Ping!
> 
> The last discussion of this patch was
>    https://lists.rtems.org/pipermail/devel/2024-February/077289.html
> 
> Does the fact that I recive no further comments to this patch mean it can be
> pushed to the RTEMS User Manual as it is?

Sorry Frank, I have been busy with other changes. It is on my list but I have
will need to reread the thread when I have time.

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

Re: RTEMS 7 GDB Build Failure on FreeBSD 13

[Chris Johns]

On 19/3/2024 1:27 am, Joel Sherrill wrote:
> I am going through the logs on the test sweep VMs to see why some builds are
> failing. This is due to gdb's requirement for GMP and MPFR. What's the
> recommended way to address this? Load native packages?

No, we need to add support to build them. We have to because other hosts like
MacOS do not have a standard package system.

Chris

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

Re: [PATCH 1/5] bsps: Use bsps/aarch64/xilinx-zynqmp

[Chris Johns]

Does this patch series build at the per commit level?

Chris

On 19/3/2024 3:30 am, Sebastian Huber wrote:
> ---
>  spec/build/bsps/dev/irq/optarmgic-icc-bpr0.yml| 6 +-
>  spec/build/bsps/dev/irq/optarmgic-icc-igrpen0.yml | 6 +-
>  spec/build/cpukit/optsmp.yml  | 6 +-
>  3 files changed, 3 insertions(+), 15 deletions(-)
> 
> diff --git a/spec/build/bsps/dev/irq/optarmgic-icc-bpr0.yml 
> b/spec/build/bsps/dev/irq/optarmgic-icc-bpr0.yml
> index 5338538de0..44d2671eb6 100644
> --- a/spec/build/bsps/dev/irq/optarmgic-icc-bpr0.yml
> +++ b/spec/build/bsps/dev/irq/optarmgic-icc-bpr0.yml
> @@ -15,11 +15,7 @@ default:
>- aarch64/xilinx_versal_aiedge
>- aarch64/xilinx_versal_qemu
>- aarch64/xilinx_versal_vck190
> -  - aarch64/xilinx_zynqmp_ilp32_qemu
> -  - aarch64/xilinx_zynqmp_ilp32_zu3eg
> -  - aarch64/xilinx_zynqmp_lp64_cfc400x
> -  - aarch64/xilinx_zynqmp_lp64_qemu
> -  - aarch64/xilinx_zynqmp_lp64_zu3eg
> +  - bsps/aarch64/xilinx-zynqmp
>value: null
>  - enabled-by: true
>value: 0x0002
> diff --git a/spec/build/bsps/dev/irq/optarmgic-icc-igrpen0.yml 
> b/spec/build/bsps/dev/irq/optarmgic-icc-igrpen0.yml
> index fbc2dd9227..9b552c3f96 100644
> --- a/spec/build/bsps/dev/irq/optarmgic-icc-igrpen0.yml
> +++ b/spec/build/bsps/dev/irq/optarmgic-icc-igrpen0.yml
> @@ -15,11 +15,7 @@ default:
>- aarch64/xilinx_versal_aiedge
>- aarch64/xilinx_versal_qemu
>- aarch64/xilinx_versal_vck190
> -  - aarch64/xilinx_zynqmp_ilp32_qemu
> -  - aarch64/xilinx_zynqmp_ilp32_zu3eg
> -  - aarch64/xilinx_zynqmp_lp64_cfc400x
> -  - aarch64/xilinx_zynqmp_lp64_qemu
> -  - aarch64/xilinx_zynqmp_lp64_zu3eg
> +  - bsps/aarch64/xilinx-zynqmp
>value: null
>  - enabled-by: true
>value: 0x0001
> diff --git a/spec/build/cpukit/optsmp.yml b/spec/build/cpukit/optsmp.yml
> index 45d41299da..f78558d6eb 100644
> --- a/spec/build/cpukit/optsmp.yml
> +++ b/spec/build/cpukit/optsmp.yml
> @@ -13,11 +13,6 @@ default:
>  description: |
>Enable the Symmetric Multiprocessing (SMP) support
>  enabled-by:
> -- aarch64/xilinx_zynqmp_ilp32_qemu
> -- aarch64/xilinx_zynqmp_ilp32_zu3eg
> -- aarch64/xilinx_zynqmp_lp64_cfc400x
> -- aarch64/xilinx_zynqmp_lp64_qemu
> -- aarch64/xilinx_zynqmp_lp64_zu3eg
>  - arm/altcycv_devkit
>  - arm/fvp_cortex_r52
>  - arm/imx7
> @@ -33,6 +28,7 @@ enabled-by:
>  - arm/xilinx_zynq_picozed
>  - arm/xilinx_zynq_pynq
>  - arm/xilinx_zynq_microzed
> +- bsps/aarch64/xilinx-zynqmp
>  - i386/pc386
>  - i386/pc486
>  - i386/pc586
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH 3/5] xilinx-zynqmp-rpu: Remove URLs from copyrights

[Chris Johns]

On 19/3/2024 3:30 am, Sebastian Huber wrote:
> ---
>  spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml| 2 +-
>  spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml  | 2 +-
>  spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml   | 2 +-
>  spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml | 2 +-
>  4 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml 
> b/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
> index ba70c44d7d..06795eb416 100644
> --- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
> +++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
> @@ -5,7 +5,7 @@ actions:
>  - env-append: null
>  build-type: option
>  copyrights:
> -- Copyright (C) 2023 Reflex Aerospace GmbH ( 
> https://www.reflexaerospace.com/ )
> +- Copyright (C) 2023 Reflex Aerospace GmbH

Why this change?

Chris

>  default:
>  - enabled-by: true
>value:
> diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml 
> b/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
> index d08f048060..3fa210d8e7 100644
> --- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
> +++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
> @@ -4,7 +4,7 @@ bsp: xilinx_zynqmp_mercuryxu5_rpu
>  build-type: bsp
>  cflags: []
>  copyrights:
> -- Copyright (C) 2023 Reflex Aerospace GmbH ( 
> https://www.reflexaerospace.com/ )
> +- Copyright (C) 2023 Reflex Aerospace GmbH
>  cppflags: []
>  enabled-by: true
>  family: xilinx-zynqmp-rpu
> diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml 
> b/spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml
> index a3654f3f42..9c8a6d1cd6 100644
> --- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml
> +++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml
> @@ -38,7 +38,7 @@ content: |
>_stack_end = bsp_section_stack_end;
>__undef_stack = bsp_section_stack_begin;
>  copyrights:
> -- Copyright (C) 2023 Reflex Aerospace GmbH ( 
> https://www.reflexaerospace.com/ )
> +- Copyright (C) 2023 Reflex Aerospace GmbH
>  enabled-by: true
>  install-path: ${BSP_LIBDIR}
>  links: []
> diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml 
> b/spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml
> index 09a3965906..d684f5a06d 100644
> --- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml
> +++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml
> @@ -4,7 +4,7 @@ actions:
>  - define-condition: null
>  build-type: option
>  copyrights:
> -- Copyright (C) 2023 Reflex Aerospace GmbH ( 
> https://www.reflexaerospace.com/ )
> +- Copyright (C) 2023 Reflex Aerospace GmbH
>  default:
>  - enabled-by: true
>value: true
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT option

[Chris Johns]

On 19/3/2024 3:49 am, Sebastian Huber wrote:
> Make the kernel I/O output character device flushing configurable.  The
> bsp_reset() function should reset the unit and do nothing else.
> ---
>  bsps/aarch64/xilinx-zynqmp/console/console.c  |  3 ++-
>  bsps/aarch64/xilinx-zynqmp/include/bsp.h  |  2 --
>  .../console/console-config.c  |  3 ++-
>  bsps/arm/xilinx-zynqmp-rpu/include/bsp.h  |  2 --
>  bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c   |  3 ---
>  .../xilinx-zynqmp/console/console-config.c|  2 +-
>  bsps/arm/xilinx-zynqmp/include/bsp.h  |  2 --
>  bsps/arm/xilinx-zynqmp/start/bspreset.c   |  4 +---
>  bsps/include/bsp/bootcard.h   |  5 +
>  bsps/shared/start/bspfatal-default.c  |  4 
>  spec/build/bsps/bspopts.yml   |  2 ++
>  spec/build/bsps/optflushkerncharout.yml   | 20 +++
>  12 files changed, 37 insertions(+), 15 deletions(-)
>  create mode 100644 spec/build/bsps/optflushkerncharout.yml
> 
> diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c 
> b/bsps/aarch64/xilinx-zynqmp/console/console.c
> index 9ce0b1da63..d1b2850952 100644
> --- a/bsps/aarch64/xilinx-zynqmp/console/console.c
> +++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
> @@ -41,6 +41,7 @@
>  #include 
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -234,7 +235,7 @@ rtems_status_code console_initialize(
>return RTEMS_SUCCESSFUL;
>  }
>  
> -void zynqmp_debug_console_flush(void)
> +void bsp_flush_kernel_char_output(void)
>  {
>zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
>  }
> diff --git a/bsps/aarch64/xilinx-zynqmp/include/bsp.h 
> b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> index 0ccca8b196..d36abde415 100644
> --- a/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> +++ b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> @@ -86,8 +86,6 @@ BSP_START_TEXT_SECTION void 
> zynqmp_setup_mmu_and_cache(void);
>   */
>  BSP_START_TEXT_SECTION void zynqmp_setup_secondary_cpu_mmu_and_cache( void );
>  
> -void zynqmp_debug_console_flush(void);
> -
>  uint32_t zynqmp_clock_i2c0(void);
>  
>  uint32_t zynqmp_clock_i2c1(void);
> diff --git a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c 
> b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
> index f52e008f2b..196b2dec58 100644
> --- a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
> +++ b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -79,7 +80,7 @@ rtems_status_code console_initialize(
>return RTEMS_SUCCESSFUL;
>  }
>  
> -void zynqmp_debug_console_flush(void)
> +void bsp_flush_kernel_char_output(void)
>  {
>zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
>  }
> diff --git a/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h 
> b/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
> index e386bd4b26..060147967c 100644
> --- a/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
> +++ b/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
> @@ -83,8 +83,6 @@ extern "C" {
>   */
>  BSP_START_TEXT_SECTION void zynqmp_setup_mpu_and_cache(void);
>  
> -void zynqmp_debug_console_flush(void);
> -
>  #ifdef __cplusplus
>  }
>  #endif /* __cplusplus */
> diff --git a/bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c 
> b/bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c
> index eecb4da838..a894f55f6e 100644
> --- a/bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c
> +++ b/bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c
> @@ -30,13 +30,10 @@
>   * POSSIBILITY OF SUCH DAMAGE.
>   */
>  
> -#include 
>  #include 
>  
>  void bsp_reset(void)
>  {
> -  zynqmp_debug_console_flush();

Why remove the call here?

> -
>while (true) {
>  /* Wait */
>}
> diff --git a/bsps/arm/xilinx-zynqmp/console/console-config.c 
> b/bsps/arm/xilinx-zynqmp/console/console-config.c
> index eadd7f11a2..360d193ba2 100644
> --- a/bsps/arm/xilinx-zynqmp/console/console-config.c
> +++ b/bsps/arm/xilinx-zynqmp/console/console-config.c
> @@ -81,7 +81,7 @@ rtems_status_code console_initialize(
>return RTEMS_SUCCESSFUL;
>  }
>  
> -void zynqmp_debug_console_flush(void)
> +void bsp_flush_kernel_char_output(void)
>  {
>zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
>  }
> diff --git a/bsps/arm/xilinx-zynqmp/include/bsp.h 
> b/bsps/arm/xilinx-zynqmp/include/bsp.h
> index a08a5feee9..2785e4c2e0 100644
> --- a/bsps/arm/xilinx-zynqmp/include/bsp.h
> +++ b/bsps/arm/xilinx-zynqmp/include/bsp.h
> @@ -79,8 +79,6 @@ extern "C" {
>   */
>  BSP_START_TEXT_SECTION void zynqmp_setup_mmu_and_cache(void);
>  
> -void zynqmp_debug_console_flush(void);
> -
>  #ifdef __cplusplus
>  }
>  #endif /* __cplusplus */
> diff --git a/bsps/arm/xilinx-zynqmp/start/bspreset.c 
> b/bsps/arm/xilinx-zynqmp/start/bspreset.c
> index b43b19b05f..ed2f4da83a 100644
> --- a/bsps/arm/xilinx-zynqmp/start/bspreset.c
> +++ b/bsps/arm/xilinx-zynqmp/start/bspreset.c
> @@ -30,12 +30,10 @@
>   * POSSIBILITY OF SUCH DAMAGE.
>   */
>  
> 

Re: [PATCH] improved error checking in ticks per timeslice

[Joel Sherrill]

No. Just a lesson to remember -- Everyone along the path should have built
rtems with all tests enabled.

This is something that should never happen after the upcoming transition to
GitLab. It definitely shows we need to build at least one BSP with tests
enabled.


On Mon, Mar 18, 2024, 7:45 PM zack leung  wrote:

>  Do I need to do anything?
>
>
> On Mon, 18 Mar 2024 at 16:38, Kinsey Moore 
> wrote:
>
>> Sorry, I didn't realize I had tests turned off in my local build when I
>> checked this. The test is now gated behind NEEDS_CLOCK_DRIVER as well.
>>
>> Kinsey
>>
>> On Mon, Mar 18, 2024 at 4:15 AM Sebastian Huber <
>> sebastian.hu...@embedded-brains.de> wrote:
>>
>>> This patch breaks the build:
>>>
>>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>>   from
>>> ../../../testsuites/rhealstone/rhdeadlockbrk/deadlockbrk.c:215:
>>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>>> zero"
>>>|^
>>>
>>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>>   from
>>> ../../../testsuites/rhealstone/rhmlatency/mlatency.c:158:
>>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>>> zero"
>>>|^
>>>
>>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>>   from
>>> ../../../testsuites/rhealstone/rhtaskswitch/taskswitch.c:122:
>>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>>> zero"
>>>|^
>>>
>>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>>   from
>>> ../../../testsuites/rhealstone/rhilatency/ilatency.c:29:
>>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>>> zero"
>>>|^
>>>
>>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>>   from
>>> ../../../testsuites/rhealstone/rhtaskpreempt/taskpreempt.c:120:
>>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>>> zero"
>>>|^
>>>
>>> --
>>> embedded brains GmbH & Co. KG
>>> 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
>>
>> ___
> 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] improved error checking in ticks per timeslice

[zack leung]

 Do I need to do anything?


On Mon, 18 Mar 2024 at 16:38, Kinsey Moore  wrote:

> Sorry, I didn't realize I had tests turned off in my local build when I
> checked this. The test is now gated behind NEEDS_CLOCK_DRIVER as well.
>
> Kinsey
>
> On Mon, Mar 18, 2024 at 4:15 AM Sebastian Huber <
> sebastian.hu...@embedded-brains.de> wrote:
>
>> This patch breaks the build:
>>
>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>   from
>> ../../../testsuites/rhealstone/rhdeadlockbrk/deadlockbrk.c:215:
>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>> zero"
>>|^
>>
>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>   from
>> ../../../testsuites/rhealstone/rhmlatency/mlatency.c:158:
>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>> zero"
>>|^
>>
>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>   from
>> ../../../testsuites/rhealstone/rhtaskswitch/taskswitch.c:122:
>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>> zero"
>>|^
>>
>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>   from
>> ../../../testsuites/rhealstone/rhilatency/ilatency.c:29:
>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>> zero"
>>|^
>>
>> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>>   from
>> ../../../testsuites/rhealstone/rhtaskpreempt/taskpreempt.c:120:
>> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
>> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
>> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
>> zero"
>>|^
>>
>> --
>> embedded brains GmbH & Co. KG
>> 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
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH] improved error checking in ticks per timeslice

[Kinsey Moore]

Sorry, I didn't realize I had tests turned off in my local build when I
checked this. The test is now gated behind NEEDS_CLOCK_DRIVER as well.

Kinsey

On Mon, Mar 18, 2024 at 4:15 AM Sebastian Huber <
sebastian.hu...@embedded-brains.de> wrote:

> This patch breaks the build:
>
> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>   from
> ../../../testsuites/rhealstone/rhdeadlockbrk/deadlockbrk.c:215:
> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
> zero"
>|^
>
> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>   from
> ../../../testsuites/rhealstone/rhmlatency/mlatency.c:158:
> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
> zero"
>|^
>
> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>   from
> ../../../testsuites/rhealstone/rhtaskswitch/taskswitch.c:122:
> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
> zero"
>|^
>
> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>   from
> ../../../testsuites/rhealstone/rhilatency/ilatency.c:29:
> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
> zero"
>|^
>
> In file included from ../../../cpukit/include/rtems/confdefs.h:64,
>   from
> ../../../testsuites/rhealstone/rhtaskpreempt/taskpreempt.c:120:
> ../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error
> "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
> 74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than
> zero"
>|^
>
> --
> embedded brains GmbH & Co. KG
> 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
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: utf32 support

[Gedare Bloom]

I think it would be wchar_t support in newlib.

On Mon, Mar 18, 2024 at 11:56 AM Joel Sherrill  wrote:
>
> What does support for UTF-32 entail? Do you have an idea what software 
> functions you are looking for?
>
> I see the International Components for Unicode (ICU) has a converter 
> (https://icu.unicode.org/download) which looks it might be part of a solution.
>
> Multibyte character methods defined by POSIX would be in newlib.
>
> I'm not well versed in this area so have questions but I think it basically 
> comes down to what software libraries an application needs and porting those 
> to RTEMS -- assuming the license is ok.
>
> --joel
>
> On Mon, Mar 18, 2024 at 12:15 PM John Howard  wrote:
>>
>> I want to add utf32 support.
>>
>> Where do I start?
>>
>> — John
>> ___
>> 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: utf32 support

[Joel Sherrill]

What does support for UTF-32 entail? Do you have an idea what software
functions you are looking for?

I see the International Components for Unicode (ICU) has a converter (
https://icu.unicode.org/download) which looks it might be part of a
solution.

Multibyte character methods defined by POSIX would be in newlib.

I'm not well versed in this area so have questions but I think it basically
comes down to what software libraries an application needs and porting
those to RTEMS -- assuming the license is ok.

--joel

On Mon, Mar 18, 2024 at 12:15 PM John Howard  wrote:

> I want to add utf32 support.
>
> Where do I start?
>
> — John
> ___
> 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

utf32 support

[John Howard]

I want to add utf32 support.

Where do I start?

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

[PATCH] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT option

[Sebastian Huber]

Make the kernel I/O output character device flushing configurable.  The
bsp_reset() function should reset the unit and do nothing else.
---
 bsps/aarch64/xilinx-zynqmp/console/console.c  |  3 ++-
 bsps/aarch64/xilinx-zynqmp/include/bsp.h  |  2 --
 .../console/console-config.c  |  3 ++-
 bsps/arm/xilinx-zynqmp-rpu/include/bsp.h  |  2 --
 bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c   |  3 ---
 .../xilinx-zynqmp/console/console-config.c|  2 +-
 bsps/arm/xilinx-zynqmp/include/bsp.h  |  2 --
 bsps/arm/xilinx-zynqmp/start/bspreset.c   |  4 +---
 bsps/include/bsp/bootcard.h   |  5 +
 bsps/shared/start/bspfatal-default.c  |  4 
 spec/build/bsps/bspopts.yml   |  2 ++
 spec/build/bsps/optflushkerncharout.yml   | 20 +++
 12 files changed, 37 insertions(+), 15 deletions(-)
 create mode 100644 spec/build/bsps/optflushkerncharout.yml

diff --git a/bsps/aarch64/xilinx-zynqmp/console/console.c 
b/bsps/aarch64/xilinx-zynqmp/console/console.c
index 9ce0b1da63..d1b2850952 100644
--- a/bsps/aarch64/xilinx-zynqmp/console/console.c
+++ b/bsps/aarch64/xilinx-zynqmp/console/console.c
@@ -41,6 +41,7 @@
 #include 
 
 #include 
+#include 
 #include 
 #include 
 
@@ -234,7 +235,7 @@ rtems_status_code console_initialize(
   return RTEMS_SUCCESSFUL;
 }
 
-void zynqmp_debug_console_flush(void)
+void bsp_flush_kernel_char_output(void)
 {
   zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
 }
diff --git a/bsps/aarch64/xilinx-zynqmp/include/bsp.h 
b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
index 0ccca8b196..d36abde415 100644
--- a/bsps/aarch64/xilinx-zynqmp/include/bsp.h
+++ b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
@@ -86,8 +86,6 @@ BSP_START_TEXT_SECTION void zynqmp_setup_mmu_and_cache(void);
  */
 BSP_START_TEXT_SECTION void zynqmp_setup_secondary_cpu_mmu_and_cache( void );
 
-void zynqmp_debug_console_flush(void);
-
 uint32_t zynqmp_clock_i2c0(void);
 
 uint32_t zynqmp_clock_i2c1(void);
diff --git a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c 
b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
index f52e008f2b..196b2dec58 100644
--- a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
+++ b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -79,7 +80,7 @@ rtems_status_code console_initialize(
   return RTEMS_SUCCESSFUL;
 }
 
-void zynqmp_debug_console_flush(void)
+void bsp_flush_kernel_char_output(void)
 {
   zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
 }
diff --git a/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h 
b/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
index e386bd4b26..060147967c 100644
--- a/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
+++ b/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
@@ -83,8 +83,6 @@ extern "C" {
  */
 BSP_START_TEXT_SECTION void zynqmp_setup_mpu_and_cache(void);
 
-void zynqmp_debug_console_flush(void);
-
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
diff --git a/bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c 
b/bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c
index eecb4da838..a894f55f6e 100644
--- a/bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c
+++ b/bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c
@@ -30,13 +30,10 @@
  * POSSIBILITY OF SUCH DAMAGE.
  */
 
-#include 
 #include 
 
 void bsp_reset(void)
 {
-  zynqmp_debug_console_flush();
-
   while (true) {
 /* Wait */
   }
diff --git a/bsps/arm/xilinx-zynqmp/console/console-config.c 
b/bsps/arm/xilinx-zynqmp/console/console-config.c
index eadd7f11a2..360d193ba2 100644
--- a/bsps/arm/xilinx-zynqmp/console/console-config.c
+++ b/bsps/arm/xilinx-zynqmp/console/console-config.c
@@ -81,7 +81,7 @@ rtems_status_code console_initialize(
   return RTEMS_SUCCESSFUL;
 }
 
-void zynqmp_debug_console_flush(void)
+void bsp_flush_kernel_char_output(void)
 {
   zynq_uart_reset_tx_flush(_uart_instances[BSP_CONSOLE_MINOR]);
 }
diff --git a/bsps/arm/xilinx-zynqmp/include/bsp.h 
b/bsps/arm/xilinx-zynqmp/include/bsp.h
index a08a5feee9..2785e4c2e0 100644
--- a/bsps/arm/xilinx-zynqmp/include/bsp.h
+++ b/bsps/arm/xilinx-zynqmp/include/bsp.h
@@ -79,8 +79,6 @@ extern "C" {
  */
 BSP_START_TEXT_SECTION void zynqmp_setup_mmu_and_cache(void);
 
-void zynqmp_debug_console_flush(void);
-
 #ifdef __cplusplus
 }
 #endif /* __cplusplus */
diff --git a/bsps/arm/xilinx-zynqmp/start/bspreset.c 
b/bsps/arm/xilinx-zynqmp/start/bspreset.c
index b43b19b05f..ed2f4da83a 100644
--- a/bsps/arm/xilinx-zynqmp/start/bspreset.c
+++ b/bsps/arm/xilinx-zynqmp/start/bspreset.c
@@ -30,12 +30,10 @@
  * POSSIBILITY OF SUCH DAMAGE.
  */
 
-#include 
+#include 
 
 void bsp_reset(void)
 {
-  zynqmp_debug_console_flush();
-
   while (true) {
 /* Wait */
   }
diff --git a/bsps/include/bsp/bootcard.h b/bsps/include/bsp/bootcard.h
index 5f339d65f8..dfdc3ae7e0 100644
--- a/bsps/include/bsp/bootcard.h
+++ b/bsps/include/bsp/bootcard.h
@@ -94,6 +94,11 @@ struct Per_CPU_Control;
  */
 void 

[PATCH] arm: Move _CPU_ISR_install_vector()

[Sebastian Huber]

The use of this function is optional. Newer BSPs do not use it.
---
 .../score/cpu/arm/armv4-isr-install-vector.c  | 75 +++
 cpukit/score/cpu/arm/cpu.c| 28 +--
 spec/build/cpukit/cpuarm.yml  |  1 +
 3 files changed, 77 insertions(+), 27 deletions(-)
 create mode 100644 cpukit/score/cpu/arm/armv4-isr-install-vector.c

diff --git a/cpukit/score/cpu/arm/armv4-isr-install-vector.c 
b/cpukit/score/cpu/arm/armv4-isr-install-vector.c
new file mode 100644
index 00..739b02f8bf
--- /dev/null
+++ b/cpukit/score/cpu/arm/armv4-isr-install-vector.c
@@ -0,0 +1,75 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/**
+ * @file
+ *
+ * @ingroup RTEMSScoreCPUARM
+ *
+ * @brief This source file contains the ARM-specific _CPU_ISR_install_vector().
+ */
+
+/*
+ *  COPYRIGHT (c) 2000 Canon Research Centre France SA.
+ *  Emmanuel Raguet, mailto:rag...@crf.canon.fr
+ *
+ *  Copyright (c) 2002 Advent Networks, Inc
+ *  Jay Monkman 
+ *
+ *  Copyright (C) 2009, 2017 embedded brains GmbH & Co. KG
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#ifdef HAVE_CONFIG_H
+#include "config.h"
+#endif
+
+#include 
+
+#ifdef ARM_MULTILIB_ARCH_V4
+
+void _CPU_ISR_install_vector(
+  uint32_t vector,
+  CPU_ISR_handler  new_handler,
+  CPU_ISR_handler *old_handler
+)
+{
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Warray-bounds"
+  /* Redirection table starts at the end of the vector table */
+  CPU_ISR_handler volatile  *table = (CPU_ISR_handler *) (MAX_EXCEPTIONS * 4);
+
+  CPU_ISR_handler current_handler = table [vector];
+
+  /* The current handler is now the old one */
+  if (old_handler != NULL) {
+*old_handler = current_handler;
+  }
+
+  /* Write only if necessary to avoid writes to a maybe read-only memory */
+  if (current_handler != new_handler) {
+table [vector] = new_handler;
+  }
+#pragma GCC diagnostic pop
+}
+
+#endif /* ARM_MULTILIB_ARCH_V4 */
diff --git a/cpukit/score/cpu/arm/cpu.c b/cpukit/score/cpu/arm/cpu.c
index 65f1ad2014..c27f4de9f9 100644
--- a/cpukit/score/cpu/arm/cpu.c
+++ b/cpukit/score/cpu/arm/cpu.c
@@ -8,8 +8,7 @@
  * @brief This source file contains static assertions to ensure the consistency
  *   of interfaces used in C and assembler and it contains the ARM-specific
  *   implementation of _CPU_Initialize(), _CPU_ISR_Get_level(),
- *   _CPU_ISR_Set_level(), _CPU_ISR_install_vector(),
- *   _CPU_Context_Initialize(), and _CPU_Fatal_halt().
+ *   _CPU_ISR_Set_level(), _CPU_Context_Initialize(), and _CPU_Fatal_halt().
  */
 
 /*
@@ -160,31 +159,6 @@ uint32_t _CPU_ISR_Get_level( void )
   return ( level & ARM_PSR_I ) != 0;
 }
 
-void _CPU_ISR_install_vector(
-  uint32_t vector,
-  CPU_ISR_handler  new_handler,
-  CPU_ISR_handler *old_handler
-)
-{
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Warray-bounds"
-  /* Redirection table starts at the end of the vector table */
-  CPU_ISR_handler volatile  *table = (CPU_ISR_handler *) (MAX_EXCEPTIONS * 4);
-
-  CPU_ISR_handler current_handler = table [vector];
-
-  /* The current handler is now the old one */
-  if (old_handler != NULL) {
-*old_handler = current_handler;
-  }
-
-  /* Write only if necessary to avoid writes to a maybe read-only memory */
-  if (current_handler != new_handler) {
-table [vector] = new_handler;
-  }
-#pragma GCC diagnostic pop
-}
-
 void _CPU_Initialize( void )
 {
   /* Do nothing */
diff --git a/spec/build/cpukit/cpuarm.yml b/spec/build/cpukit/cpuarm.yml
index 5b140e46bb..88f84fd361 100644
--- a/spec/build/cpukit/cpuarm.yml
+++ b/spec/build/cpukit/cpuarm.yml
@@ -41,6 +41,7 @@ source:
 - cpukit/score/cpu/arm/arm_exc_interrupt.S
 - 

[PATCH 4/5] bsps: Add xilinx_zynq_rpu BSP variant

[Sebastian Huber]

Add a BSP variant without a board-specific name.
---
 .../arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml   | 87 +--
 .../bsps/arm/xilinx-zynqmp-rpu/bsprpu.yml | 17 
 spec/build/bsps/arm/xilinx-zynqmp-rpu/grp.yml | 69 +++
 spec/build/bsps/arm/xilinx-zynqmp-rpu/obj.yml | 42 +
 4 files changed, 132 insertions(+), 83 deletions(-)
 create mode 100644 spec/build/bsps/arm/xilinx-zynqmp-rpu/bsprpu.yml
 create mode 100644 spec/build/bsps/arm/xilinx-zynqmp-rpu/grp.yml
 create mode 100644 spec/build/bsps/arm/xilinx-zynqmp-rpu/obj.yml

diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml 
b/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
index 3fa210d8e7..f6c228c79d 100644
--- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
+++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
@@ -8,89 +8,10 @@ copyrights:
 cppflags: []
 enabled-by: true
 family: xilinx-zynqmp-rpu
-includes:
-- bsps/include/xil/
-- bsps/include/xil/${XIL_SUPPORT_PATH}/
-install:
-- destination: ${BSP_INCLUDEDIR}
-  source:
-  - bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
-- destination: ${BSP_INCLUDEDIR}/bsp
-  source:
-  - bsps/arm/xilinx-zynqmp-rpu/include/bsp/irq.h
-- destination: ${BSP_INCLUDEDIR}/peripheral_maps
-  source:
-  - bsps/include/peripheral_maps/xilinx_zynqmp.h
+includes: []
+install: []
 links:
 - role: build-dependency
-  uid: ../grp
-- role: build-dependency
-  uid: ../start
-- role: build-dependency
-  uid: abi
-- role: build-dependency
-  uid: optclkfastidle
-- role: build-dependency
-  uid: optclkuart
-- role: build-dependency
-  uid: optconirq
-- role: build-dependency
-  uid: ../../optconminor
-- role: build-dependency
-  uid: optint0len
-- role: build-dependency
-  uid: optint0ori
-- role: build-dependency
-  uid: optint1len
-- role: build-dependency
-  uid: optint1ori
-- role: build-dependency
-  uid: optramlen
-- role: build-dependency
-  uid: optramori
-- role: build-dependency
-  uid: optresetvec
-- role: build-dependency
-  uid: optnocachelen
-- role: build-dependency
-  uid: ../../obj
-- role: build-dependency
-  uid: ../../objirq
-- role: build-dependency
-  uid: ../../objdevserialzynq
-- role: build-dependency
-  uid: ../../objdevspizynq
-- role: build-dependency
-  uid: ../../objdevspixil
-- role: build-dependency
-  uid: ../../objmem
-- role: build-dependency
-  uid: ../../opto0
-- role: build-dependency
-  uid: linkcmds
-- role: build-dependency
-  uid: ../../bspopts
-- role: build-dependency
-  uid: ../../objxilinxsupport
-source:
-- bsps/shared/cache/nocache.c
-- bsps/arm/shared/cp15/arm-cp15-set-exception-handler.c
-- bsps/arm/shared/cp15/arm-cp15-set-ttb-entries.c
-- bsps/arm/shared/start/bsp-start-memcpy.S
-- bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
-- bsps/arm/xilinx-zynqmp-rpu/start/bspreset.c
-- bsps/arm/xilinx-zynqmp-rpu/start/bspstart.c
-- bsps/arm/xilinx-zynqmp-rpu/start/bspstarthooks.c
-- bsps/arm/xilinx-zynqmp-rpu/start/bspstartmpu.c
-- bsps/shared/dev/clock/xil-ttc.c
-- bsps/shared/dev/btimer/btimer-cpucounter.c
-- bsps/shared/dev/getentropy/getentropy-cpucounter.c
-- bsps/shared/dev/irq/arm-gicv2.c
-- bsps/shared/dev/irq/arm-gicv2-zynqmp.c
-- bsps/shared/dev/serial/console-termios.c
-- bsps/shared/irq/irq-default-handler.c
-- bsps/shared/start/bspfatal-default.c
-- bsps/shared/start/gettargethash-default.c
-- bsps/shared/start/sbrk.c
-- bsps/shared/start/stackalloc.c
+  uid: grp
+source: []
 type: build
diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/bsprpu.yml 
b/spec/build/bsps/arm/xilinx-zynqmp-rpu/bsprpu.yml
new file mode 100644
index 00..d4073d8248
--- /dev/null
+++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/bsprpu.yml
@@ -0,0 +1,17 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+arch: arm
+bsp: xilinx_zynqmp_rpu
+build-type: bsp
+cflags: []
+copyrights:
+- Copyright (C) 2024 embedded brains GmbH
+cppflags: []
+enabled-by: true
+family: xilinx-zynqmp-rpu
+includes: []
+install: []
+links:
+- role: build-dependency
+  uid: grp
+source: []
+type: build
diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/grp.yml 
b/spec/build/bsps/arm/xilinx-zynqmp-rpu/grp.yml
new file mode 100644
index 00..b886948d47
--- /dev/null
+++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/grp.yml
@@ -0,0 +1,69 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+build-type: group
+cflags: []
+copyrights:
+- Copyright (C) 2023 Reflex Aerospace GmbH
+cppflags: []
+cxxflags: []
+enabled-by: true
+includes:
+- bsps/include/xil
+- bsps/include/xil/${XIL_SUPPORT_PATH}
+install: []
+ldflags: []
+links:
+- role: build-dependency
+  uid: ../grp
+- role: build-dependency
+  uid: ../start
+- role: build-dependency
+  uid: abi
+- role: build-dependency
+  uid: optclkfastidle
+- role: build-dependency
+  uid: optclkuart
+- role: build-dependency
+  uid: optconirq
+- role: build-dependency
+  uid: ../../optconminor
+- role: build-dependency
+  uid: optint0len
+- role: build-dependency
+  uid: optint0ori
+- role: 

[PATCH 1/5] bsps: Use bsps/aarch64/xilinx-zynqmp

[Sebastian Huber]

---
 spec/build/bsps/dev/irq/optarmgic-icc-bpr0.yml| 6 +-
 spec/build/bsps/dev/irq/optarmgic-icc-igrpen0.yml | 6 +-
 spec/build/cpukit/optsmp.yml  | 6 +-
 3 files changed, 3 insertions(+), 15 deletions(-)

diff --git a/spec/build/bsps/dev/irq/optarmgic-icc-bpr0.yml 
b/spec/build/bsps/dev/irq/optarmgic-icc-bpr0.yml
index 5338538de0..44d2671eb6 100644
--- a/spec/build/bsps/dev/irq/optarmgic-icc-bpr0.yml
+++ b/spec/build/bsps/dev/irq/optarmgic-icc-bpr0.yml
@@ -15,11 +15,7 @@ default:
   - aarch64/xilinx_versal_aiedge
   - aarch64/xilinx_versal_qemu
   - aarch64/xilinx_versal_vck190
-  - aarch64/xilinx_zynqmp_ilp32_qemu
-  - aarch64/xilinx_zynqmp_ilp32_zu3eg
-  - aarch64/xilinx_zynqmp_lp64_cfc400x
-  - aarch64/xilinx_zynqmp_lp64_qemu
-  - aarch64/xilinx_zynqmp_lp64_zu3eg
+  - bsps/aarch64/xilinx-zynqmp
   value: null
 - enabled-by: true
   value: 0x0002
diff --git a/spec/build/bsps/dev/irq/optarmgic-icc-igrpen0.yml 
b/spec/build/bsps/dev/irq/optarmgic-icc-igrpen0.yml
index fbc2dd9227..9b552c3f96 100644
--- a/spec/build/bsps/dev/irq/optarmgic-icc-igrpen0.yml
+++ b/spec/build/bsps/dev/irq/optarmgic-icc-igrpen0.yml
@@ -15,11 +15,7 @@ default:
   - aarch64/xilinx_versal_aiedge
   - aarch64/xilinx_versal_qemu
   - aarch64/xilinx_versal_vck190
-  - aarch64/xilinx_zynqmp_ilp32_qemu
-  - aarch64/xilinx_zynqmp_ilp32_zu3eg
-  - aarch64/xilinx_zynqmp_lp64_cfc400x
-  - aarch64/xilinx_zynqmp_lp64_qemu
-  - aarch64/xilinx_zynqmp_lp64_zu3eg
+  - bsps/aarch64/xilinx-zynqmp
   value: null
 - enabled-by: true
   value: 0x0001
diff --git a/spec/build/cpukit/optsmp.yml b/spec/build/cpukit/optsmp.yml
index 45d41299da..f78558d6eb 100644
--- a/spec/build/cpukit/optsmp.yml
+++ b/spec/build/cpukit/optsmp.yml
@@ -13,11 +13,6 @@ default:
 description: |
   Enable the Symmetric Multiprocessing (SMP) support
 enabled-by:
-- aarch64/xilinx_zynqmp_ilp32_qemu
-- aarch64/xilinx_zynqmp_ilp32_zu3eg
-- aarch64/xilinx_zynqmp_lp64_cfc400x
-- aarch64/xilinx_zynqmp_lp64_qemu
-- aarch64/xilinx_zynqmp_lp64_zu3eg
 - arm/altcycv_devkit
 - arm/fvp_cortex_r52
 - arm/imx7
@@ -33,6 +28,7 @@ enabled-by:
 - arm/xilinx_zynq_picozed
 - arm/xilinx_zynq_pynq
 - arm/xilinx_zynq_microzed
+- bsps/aarch64/xilinx-zynqmp
 - i386/pc386
 - i386/pc486
 - i386/pc586
-- 
2.35.3

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

[PATCH 3/5] xilinx-zynqmp-rpu: Remove URLs from copyrights

[Sebastian Huber]

---
 spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml| 2 +-
 spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml  | 2 +-
 spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml   | 2 +-
 spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml 
b/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
index ba70c44d7d..06795eb416 100644
--- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
+++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/abi.yml
@@ -5,7 +5,7 @@ actions:
 - env-append: null
 build-type: option
 copyrights:
-- Copyright (C) 2023 Reflex Aerospace GmbH ( https://www.reflexaerospace.com/ )
+- Copyright (C) 2023 Reflex Aerospace GmbH
 default:
 - enabled-by: true
   value:
diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml 
b/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
index d08f048060..3fa210d8e7 100644
--- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
+++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/bspmercuryxu5.yml
@@ -4,7 +4,7 @@ bsp: xilinx_zynqmp_mercuryxu5_rpu
 build-type: bsp
 cflags: []
 copyrights:
-- Copyright (C) 2023 Reflex Aerospace GmbH ( https://www.reflexaerospace.com/ )
+- Copyright (C) 2023 Reflex Aerospace GmbH
 cppflags: []
 enabled-by: true
 family: xilinx-zynqmp-rpu
diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml 
b/spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml
index a3654f3f42..9c8a6d1cd6 100644
--- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml
+++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/linkcmds.yml
@@ -38,7 +38,7 @@ content: |
   _stack_end = bsp_section_stack_end;
   __undef_stack = bsp_section_stack_begin;
 copyrights:
-- Copyright (C) 2023 Reflex Aerospace GmbH ( https://www.reflexaerospace.com/ )
+- Copyright (C) 2023 Reflex Aerospace GmbH
 enabled-by: true
 install-path: ${BSP_LIBDIR}
 links: []
diff --git a/spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml 
b/spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml
index 09a3965906..d684f5a06d 100644
--- a/spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml
+++ b/spec/build/bsps/arm/xilinx-zynqmp-rpu/optprocunitrpu.yml
@@ -4,7 +4,7 @@ actions:
 - define-condition: null
 build-type: option
 copyrights:
-- Copyright (C) 2023 Reflex Aerospace GmbH ( https://www.reflexaerospace.com/ )
+- Copyright (C) 2023 Reflex Aerospace GmbH
 default:
 - enabled-by: true
   value: true
-- 
2.35.3

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

[PATCH 5/5] bsps: Add xilinx_zynqmp_lp64_a53 BSP variant

[Sebastian Huber]

Add a BSP variant without a board-specific name.
---
 .../bsps/aarch64/xilinx-zynqmp/bspa53lp64.yml | 21 +++
 .../bsps/aarch64/xilinx-zynqmp/optloadoff.yml |  1 +
 .../bsps/aarch64/xilinx-zynqmp/optramori.yml  |  1 +
 spec/build/bsps/objxilinxsupportlp64.yml  |  1 +
 spec/build/bsps/optxilsupportpath.yml |  1 +
 5 files changed, 25 insertions(+)
 create mode 100644 spec/build/bsps/aarch64/xilinx-zynqmp/bspa53lp64.yml

diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/bspa53lp64.yml 
b/spec/build/bsps/aarch64/xilinx-zynqmp/bspa53lp64.yml
new file mode 100644
index 00..42316db4d3
--- /dev/null
+++ b/spec/build/bsps/aarch64/xilinx-zynqmp/bspa53lp64.yml
@@ -0,0 +1,21 @@
+SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
+arch: aarch64
+bsp: xilinx_zynqmp_lp64_a53
+build-type: bsp
+cflags: []
+copyrights:
+- Copyright (C) 2024 embedded brains GmbH
+cppflags: []
+enabled-by: true
+family: xilinx-zynqmp
+includes: []
+install: []
+links:
+- role: build-dependency
+  uid: grp
+- role: build-dependency
+  uid: linkcmds_lp64
+- role: build-dependency
+  uid: objfdtzynqmp
+source: []
+type: build
diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optloadoff.yml 
b/spec/build/bsps/aarch64/xilinx-zynqmp/optloadoff.yml
index 869181a95e..3a78b9af38 100644
--- a/spec/build/bsps/aarch64/xilinx-zynqmp/optloadoff.yml
+++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optloadoff.yml
@@ -9,6 +9,7 @@ copyrights:
 - Copyright (C) 2020 On-Line Applications Research (OAR)
 default:
 - enabled-by:
+  - aarch64/xilinx_zynqmp_lp64_a53
   - aarch64/xilinx_zynqmp_ilp32_zu3eg
   - aarch64/xilinx_zynqmp_lp64_cfc400x
   - aarch64/xilinx_zynqmp_lp64_zu3eg
diff --git a/spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml 
b/spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
index c4d33094fb..33f0946532 100644
--- a/spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
+++ b/spec/build/bsps/aarch64/xilinx-zynqmp/optramori.yml
@@ -9,6 +9,7 @@ copyrights:
 - Copyright (C) 2020 On-Line Applications Research (OAR)
 default:
 - enabled-by:
+  - aarch64/xilinx_zynqmp_lp64_a53
   - aarch64/xilinx_zynqmp_ilp32_zu3eg
   - aarch64/xilinx_zynqmp_lp64_cfc400x
   - aarch64/xilinx_zynqmp_lp64_zu3eg
diff --git a/spec/build/bsps/objxilinxsupportlp64.yml 
b/spec/build/bsps/objxilinxsupportlp64.yml
index 330ffc34fd..252851a5aa 100644
--- a/spec/build/bsps/objxilinxsupportlp64.yml
+++ b/spec/build/bsps/objxilinxsupportlp64.yml
@@ -7,6 +7,7 @@ cppflags: []
 cxxflags: []
 enabled-by:
 - bsps/aarch64/xilinx_versal
+- aarch64/xilinx_zynqmp_lp64_a53
 - aarch64/xilinx_zynqmp_lp64_cfc400x
 - aarch64/xilinx_zynqmp_lp64_qemu
 - aarch64/xilinx_zynqmp_lp64_zu3eg
diff --git a/spec/build/bsps/optxilsupportpath.yml 
b/spec/build/bsps/optxilsupportpath.yml
index 298f9d5286..a90e6d3418 100644
--- a/spec/build/bsps/optxilsupportpath.yml
+++ b/spec/build/bsps/optxilsupportpath.yml
@@ -20,6 +20,7 @@ default:
   - aarch64/xilinx_zynqmp_ilp32_zu3eg
   value: arm/ARMv8/32bit
 - enabled-by:
+  - aarch64/xilinx_zynqmp_lp64_a53
   - aarch64/xilinx_zynqmp_lp64_cfc400x
   - aarch64/xilinx_zynqmp_lp64_qemu
   - aarch64/xilinx_zynqmp_lp64_zu3eg
-- 
2.35.3

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

[PATCH 2/5] bsps: Use bsps/arm/xilinx-zynqmp-rpu

[Sebastian Huber]

---
 spec/build/bsps/objxilinxsupportr5.yml | 3 +--
 spec/build/bsps/optxilsupportpath.yml  | 2 +-
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/spec/build/bsps/objxilinxsupportr5.yml 
b/spec/build/bsps/objxilinxsupportr5.yml
index d800b83247..25221c5e0d 100644
--- a/spec/build/bsps/objxilinxsupportr5.yml
+++ b/spec/build/bsps/objxilinxsupportr5.yml
@@ -5,8 +5,7 @@ copyrights:
 - Copyright (C) 2022 On-Line Applications Research (OAR)
 cppflags: []
 cxxflags: []
-enabled-by:
-- arm/xilinx_zynqmp_mercuryxu5_rpu
+enabled-by: bsps/arm/xilinx-zynqmp-rpu
 includes: []
 install:
 - destination: ${BSP_INCLUDEDIR}
diff --git a/spec/build/bsps/optxilsupportpath.yml 
b/spec/build/bsps/optxilsupportpath.yml
index 85bcc7e059..298f9d5286 100644
--- a/spec/build/bsps/optxilsupportpath.yml
+++ b/spec/build/bsps/optxilsupportpath.yml
@@ -7,7 +7,7 @@ copyrights:
 - Copyright (C) 2022 On-Line Applications Research (OAR)
 default:
 - enabled-by:
-  - arm/xilinx_zynqmp_mercuryxu5_rpu
+  - bsps/arm/xilinx-zynqmp-rpu
   value: arm/cortexr5
 - enabled-by: bsps/microblaze/microblaze_fpga
   value: microblaze
-- 
2.35.3

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

RTEMS 7 GDB Build Failure on FreeBSD 13

[Joel Sherrill]

Hi

I am going through the logs on the test sweep VMs to see why some builds
are failing. This is due to gdb's requirement for GMP and MPFR. What's the
recommended way to address this? Load native packages?

checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... no
configure: error: Building GDB requires GMP 4.2+, and MPFR 3.1.0+.
Try the --with-gmp and/or --with-mpfr options to specify
their locations.  If you obtained GMP and/or MPFR from a vendor
distribution package, make sure that you have installed both the libraries
and the header files.  They may be located in separate packages.
shell cmd failed: /bin/sh -ex
 /usr/home/tester/rtems-cron-7/rtems-source-builde

Thanks.

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

Re: [PATCH] improved error checking in ticks per timeslice

[Sebastian Huber]

This patch breaks the build:

In file included from ../../../cpukit/include/rtems/confdefs.h:64,
 from 
../../../testsuites/rhealstone/rhdeadlockbrk/deadlockbrk.c:215:
../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error 
"CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"

   74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
  |^

In file included from ../../../cpukit/include/rtems/confdefs.h:64,
 from 
../../../testsuites/rhealstone/rhmlatency/mlatency.c:158:
../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error 
"CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"

   74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
  |^

In file included from ../../../cpukit/include/rtems/confdefs.h:64,
 from 
../../../testsuites/rhealstone/rhtaskswitch/taskswitch.c:122:
../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error 
"CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"

   74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
  |^

In file included from ../../../cpukit/include/rtems/confdefs.h:64,
 from 
../../../testsuites/rhealstone/rhilatency/ilatency.c:29:
../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error 
"CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"

   74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
  |^

In file included from ../../../cpukit/include/rtems/confdefs.h:64,
 from 
../../../testsuites/rhealstone/rhtaskpreempt/taskpreempt.c:120:
../../../cpukit/include/rtems/confdefs/clock.h:74:4: error: #error 
"CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"

   74 |   #error "CONFIGURE_TICKS_PER_TIMESLICE shall be greater than zero"
  |^

--
embedded brains GmbH & Co. KG
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

GSOC2024_Yang_Adding SPI, Watchdog and SD card support to Raspberry Pi 4B BSP

[Ning Yang]

Hello everyone,

I have included the SD card support part in my proposal, please let me know how 
I can continue to improve it. 
The SD card support is complex, any suggestions would be very appreciated.

https://docs.google.com/document/d/1NjlUSWhqwUvrsQPBISU05ah0I0IGkEuq6BIThrkMBsg/edit?usp=sharing
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: Hello World

[Muhammad Hamdy]

Thanks Gedare done.On Mar 15, 2024, at 8:04 PM, Gedare Bloom  wrote:Thanks, please send the patch for your commit, and then add yourself to the proposal tracking table at https://devel.rtems.org/wiki/GSoC/2024#ContributorsProposalsOn Thu, Mar 14, 2024, 2:03 PM Muhammad Hamdy  wrote:Hello,It's Mohamed "7amzy" on discord, I'm a master student in robotics from Egypt. I just finished the Hello World example, then I changed the message as requested. I'm interested in open-source contribution, embedded software, and RTEMS in particular. -- Regards,
___
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

Subject: [PATCH] changing the hello world message.

[Muhammad Hamdy]

---
 hello.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/hello.c b/hello.c
index 622a9da..d78f5dd 100644
--- a/hello.c
+++ b/hello.c
@@ -9,6 +9,6 @@ rtems_task Init(
   rtems_task_argument ignored
 )
 {
-  printf( "\nHello From Cairo, its me Hamzy\n" );
+  printf( "\nHello From Cairo, its Hamzy\n" );
   exit( 0 );
 }
-- 
2.34.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [RFC] Adding RISC-V Vector support to RTEMS

[Sebastian Huber]

Hello Ken,

On 14.03.24 18:33, ken.un...@microchip.com wrote:

Hello RTEMS experts,

We’re in the process of implementing support for RTEMS on a new RISC-V 
platform.  Among other things, our processor core supports the RISC-V 
Vector ISA (RVV), with its 32 vector registers which in our case are 512 
bits (VLEN) deep.   RVV is used by applications to accelerate a variety 
of code/algorithms utilizing either the auto-vectorizer in GCC/Clang, or 
through C intrinsics or direct assembly coding.


My query here is regarding context saving, and options for 
optimization.  Before I get to that, here’s a few points of background.


#1. Use of RVV by the compiler (GCC/Clang) is dictated by the ISA string 
provided, e.g -march=rv64imadcv,  where v is for vector.  The compiler 
preprocessor symbol "__riscv_vector" can then be used for conditionally 
compiled code, similar to what is done for floating point.


#2. Enablement of RVV can be controlled via a machine status CSR.   This 
allows one to disable RVV entirely (triggering an exception if RVV 
instructions are executed), but also allows one to track the dirty/clean 
state of the vector register file.  
(https://github.com/riscv/riscv-v-spec/blob/master/v-spec.adoc#vector-context-status-in-mstatus ).  So, one can conditionally save/restore the registers, although the 2KB of stack space (32 x (512b / 8)) would need to be allocated.


#3. The C ABI specifies that vector registers are Caller saved.  So, any 
system call (or any function call for that matter) does not need to 
preserve these registers.


A relatively straightforward approach is to say that RTEMS + Application 
is built with vectors enabled (i.e  -march=rv64imadcv).  One does not 
need to save/restore the vector registers within Context_Control because 
of #3, however,


Yes, in this case you don't have to save/restore the vector registers in 
_CPU_Context_switch(). This is similar to the SPARC architecture. For 
SPARC, we implemented a lazy floating point switch 
(cpukit/score/cpu/sparc/include/rtems/score/cpu.h):


/*
 * The SPARC ABI is a bit special with respect to the floating point 
context.
 * The complete floating point context is volatile.  Thus, from an ABI 
point

 * of view nothing needs to be saved and restored during a context switch.
 * Instead the floating point context must be saved and restored during
 * interrupt processing.  Historically, the deferred floating point 
switch was

 * used for SPARC and the complete floating point context is saved and
 * restored during a context switch to the new floating point unit owner.
 * This is a bit dangerous since post-switch actions (e.g. signal handlers)
 * and context switch extensions may silently corrupt the floating point
 * context.
 *
 * The floating point unit is disabled for interrupt handlers.  Thus, 
in case
 * an interrupt handler uses the floating point unit then this will 
result in a

 * trap (INTERNAL_ERROR_ILLEGAL_USE_OF_FLOATING_POINT_UNIT).
 *
 * In uniprocessor configurations, a lazy floating point context switch is
 * used.  In case an active floating point thread is interrupted 
(PSR[EF] == 1)
 * and a thread dispatch is carried out, then this thread is registered 
as the

 * floating point owner.  When a floating point owner is present during a
 * context switch, the floating point unit is disabled for the heir thread
 * (PSR[EF] == 0).  The floating point disabled trap checks that the 
use of the
 * floating point unit is allowed and saves/restores the floating point 
context

 * on demand.
 *
 * In SMP configurations, the deferred floating point switch is not 
supported

 * in principle.  So, use here a synchronous floating point switching.
 * Synchronous means that the volatile floating point context is saved and
 * restored around a thread dispatch issued during interrupt 
processing.  Thus

 * post-switch actions and context switch extensions may safely use the
 * floating point unit.
 */
#if SPARC_HAS_FPU == 1
  #if defined(RTEMS_SMP)
#define SPARC_USE_SYNCHRONOUS_FP_SWITCH
  #else
#define SPARC_USE_LAZY_FP_SWITCH
  #endif
#endif

For simplicity, we disabled this optimization in SMP configurations. It 
could be probably used also in SMP configurations, however, this is a 
bit more complicated if threads move to other cores.


because we are now building RTEMS with V enabled, we 
need to add this save/restore to the CPU_Interrupt_frame and incur that 
cost on all interrupts and stack space for all tasks.   (A small 
secondary effect is that CPU_INTERRUPT_FRAME_SIZE is now larger than the 
immediate addressing range).


Is there an alternative to consider?   Might one build RTEMS itself 
without V, leaving that only for Applications/Tasks, perhaps adding a 
Task attribute, and thereby taking the vector save/restore penalty only 
when switching into or out of a vector enabled task?  (Perhaps similar 
to HW 

Re: [PATCH v2] user: Add docu for use of Rust with RTEMS

[Frank Kühndel]

Ping!

The last discussion of this patch was
   https://lists.rtems.org/pipermail/devel/2024-February/077289.html

Does the fact that I recive no further comments to this patch mean it 
can be pushed to the RTEMS User Manual as it is?


Greetings
Frank

On 2/23/24 17:29, Frank Kuehndel wrote:

From: Frank Kühndel

---
  user/index.rst   |   3 +-
  user/overview/index.rst  |   2 +
  user/rust/bare-metal.rst | 548 +++
  user/rust/index.rst  |  64 +
  4 files changed, 616 insertions(+), 1 deletion(-)
  create mode 100644 user/rust/bare-metal.rst
  create mode 100644 user/rust/index.rst

diff --git a/user/index.rst b/user/index.rst
index 5b7f3ce..0cc6b2c 100644
--- a/user/index.rst
+++ b/user/index.rst
@@ -18,7 +18,7 @@ RTEMS User Manual (|version|).
  ||copy|  2018 Shashvat Jain
  ||copy|  2018 Vidushi Vashishth
  ||copy|  2017 Tanu Hari Dixit
-||copy|  2016, 2019 embedded brains GmbH & Co. KG
+||copy|  2016, 2024 embedded brains GmbH & Co. KG
  ||copy|  2016, 2019 Sebastian Huber
  ||copy|  2012, 2022 Chris Johns
  ||copy|  2012, 2020 Gedare Bloom
@@ -51,5 +51,6 @@ RTEMS User Manual (|version|).
  
  tools/index

  rsb/index
+rust/index
  
  glossary/index

diff --git a/user/overview/index.rst b/user/overview/index.rst
index 16389d9..cc292e1 100644
--- a/user/overview/index.rst
+++ b/user/overview/index.rst
@@ -66,6 +66,8 @@ RTEMS provides the following basic feature set:
  
  - Python and MicroPython
  
+- :ref:`Rust `

+
  - Parallel languages
  
  - :ref:term:`EMB²`

diff --git a/user/rust/bare-metal.rst b/user/rust/bare-metal.rst
new file mode 100644
index 000..b1c3980
--- /dev/null
+++ b/user/rust/bare-metal.rst
@@ -0,0 +1,548 @@
+.. SPDX-License-Identifier: CC-BY-SA-4.0
+
+.. Copyright (C) 2024 embedded brains GmbH & Co. KG
+
+.. _RustBareMetal:
+
+Bare Metal Rust with RTEMS
+==
+
+To develop with Rust and RTEMS together, you must find a Rust bare metal
+target which matches an RTEMS BSP. The instructions in this section
+are for a SPARC and a Risc-V*hello world*  program. These examples use
+the combinations shown in the table below:
+
+++--++--+
+| RTEMS Architecture | RTEMS BSP| Rust Target| Rust 
CPU |
+++==++==+
+| rtems-sparc| sparc/leon3  | sparc-unknown-none-elf | leon3   
 |
+++--++--+
+| rtems-riscv| riscv/rv64imafdc | riscv64gc-unknown-none-elf | 
generic-rv64 |
+++--++--+
+
+The following sources may be helpful to find a matching BSP and target:
+
+- ``./waf bsplist`` -- executed in an RTEMS git clone
+- ``source-builder/sb-set-builder --list-bsets`` -- executed in an
+  RTEMS source builder git clone
+- `RTEMS Supported 
Architectures`_
+- `RTEMS Board Support 
Packages`_
+- ``rustc --print target-list``
+- ``rustc --target=riscv64gc-unknown-none-elf --print target-features``
+- ``rustc --target=riscv64gc-unknown-none-elf  --print target-cpus``
+- `Rust Platform 
Support`_
+
+The sample instructions which follow build two executables using the
+same source code for the RTEMS configuration ``init.c`` and the Rust
+hello-world application ``lib.rs``. Only the configuration as well as
+the compile and link commands differ for SPARC Leon3 and RISC-V
+64 bit. The Rust application uses ``printk()`` from RTEMS to print
+text to the console.
+
+After building the RTEMS BSP and installing Rust, the basic steps are:
+
+1. Compile the RTEMS configuration in ``init.c`` into an object
+   file using the GNU C compiler from the RTEMS tool chain.
+2. Compile the Rust code containing ``main()`` into a
+   static library using the Rust compiler.
+3. Link the static library with the Rust code,
+   the RTEMS configuration and the RTEMS OS libraries
+   together into one single executable.
+4. Finally run the executable on a simulator.
+
+You can build the examples in a container. This is optional. If you
+prefer to follow these instructions directly on your machine simply
+skip the section*Build a Container*. Just make sure that you machine
+meets all prerequisites to build the RTEMS tools and install the Rust
+tools.
+
+.. _RustBareMetal_Container:
+
+Build a Container
+-
+
+The container must be able to execute the RTEMS source builder and to
+install and run the Rust tools. In an empty directory of your choice
+create the following ``Dockerfile``.
+
+.. code-block:: shell
+
+cat >Dockerfile <<"EOF"
+#