[PATCH rtems6] Fix: type-cast to wrong type
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
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
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
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
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
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
+#
aarch64: -mno-outline-atomics
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
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
