Possible minor bug in ARM A startup code. Clearing res1 instead of I bit in SCTLR.
While I was cleaning up the ZynqMP RPU port for a revised patch (should be ready in a few hours) I noticed a possible minor bug in `bsps/arm/shared/start/start.S` affecting ARM A profile parts. Someone familiar with ARM A parts, please check this. Also for my own knowledge, why is this done with 2 bic instructions instead of one? Reference A53 TRM SCTLR register: https://developer.arm.com/documentation/ddi0500/e/BABJAHDA At line 401: --- #if (__ARM_ARCH >= 7 && __ARM_ARCH_PROFILE == 'A') || __ARM_ARCH >= 8 /* * Set VBAR to the vector table in the start section and make sure * SCTLR[M, I, A, C, V] are cleared. Afterwards, exceptions are * handled by RTEMS. */ ldr r0, =bsp_start_vector_table_begin dsb mcr p15, 0, r0, c12, c0, 0 mrc p15, 0, r0, c1, c0, 0 --- // Is 0x2800, clear V[13] and res1[11] // Should be 0x3000, clear V[13] and I[12] --- bic r1, r0, #0x2800 bic r1, r1, #0x7 // Clear C[2] A[1] and M[0] (this is fine) mcr p15, 0, r1, c1, c0, 0 isb --- -Phil ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Possible minor bug in ARM A startup code. Clearing res1 instead of I bit in SCTLR.
On 29.06.23 15:44, Philip Kirkpatrick wrote:> While I was cleaning up the ZynqMP RPU port for a revised patch (should be ready in a few hours) I noticed a possible minor bug in `bsps/arm/shared/start/start.S` affecting ARM A profile parts. Someone familiar with ARM A parts, please check this. Yes, this looks like a bug. Also for my own knowledge, why is this done with 2 bic instructions instead of one? You have a limited number of one bits for the intermediate value in the BIC instructions. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: bsps/xilinx-zynqmp : Add BSP for RPU
Took a while to get to but here is a new patch incorporating the feedback.
Sorry to drop this and run but I'm on vacation for a week as soon as I send
this. So don't expect to see responses from me until July 10th or later.
Once I'm back and this is through, expect to see some follow-on patches for
enabling MPU, cache, and lwip support. I have that working and tested but
it needs some cleanup before I'll feel good about a patch.
---
diff --git a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
new file mode 100644
index 00..469178fd86
--- /dev/null
+++ b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
@@ -0,0 +1,128 @@
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2013, 2017 embedded brains GmbH
+ *
+ * Copyright (C) 2019 DornerWorks
+ *
+ * Written by Jeff Kubascik
+ *and Josh Whitehead
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF
THE
+ * POSSIBILITY OF SUCH DAMAGE.
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+
+#include
+
+static zynq_uart_context zynqmp_uart_instances[2] = {
+ {
+.base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 0" ),
+.regs = (volatile struct zynq_uart *) 0xff00,
+.irq = ZYNQMP_IRQ_UART_0
+ }, {
+.base = RTEMS_TERMIOS_DEVICE_CONTEXT_INITIALIZER( "Zynq UART 1" ),
+.regs = (volatile struct zynq_uart *) 0xff01,
+.irq = ZYNQMP_IRQ_UART_1
+ }
+};
+
+rtems_status_code console_initialize(
+ rtems_device_major_number major,
+ rtems_device_minor_number minor,
+ void *arg
+)
+{
+ size_t i;
+
+ for (i = 0; i < RTEMS_ARRAY_SIZE(zynqmp_uart_instances); ++i) {
+char uart[] = "/dev/ttySX";
+
+uart[sizeof(uart) - 2] = (char) ('0' + i);
+rtems_termios_device_install(
+ &uart[0],
+ &zynq_uart_handler,
+ NULL,
+ &zynqmp_uart_instances[i].base
+);
+
+if (i == BSP_CONSOLE_MINOR) {
+ link(&uart[0], CONSOLE_DEVICE_NAME);
+}
+ }
+
+ return RTEMS_SUCCESSFUL;
+}
+
+void zynqmp_debug_console_flush(void)
+{
+ zynq_uart_reset_tx_flush(&zynqmp_uart_instances[BSP_CONSOLE_MINOR]);
+}
+
+static void zynqmp_debug_console_out(char c)
+{
+ rtems_termios_device_context *base =
+&zynqmp_uart_instances[BSP_CONSOLE_MINOR].base;
+
+ zynq_uart_write_polled(base, c);
+}
+
+static void zynqmp_debug_console_init(void)
+{
+ rtems_termios_device_context *base =
+&zynqmp_uart_instances[BSP_CONSOLE_MINOR].base;
+
+ zynq_uart_initialize(base);
+ BSP_output_char = zynqmp_debug_console_out;
+}
+
+static void zynqmp_debug_console_early_init(char c)
+{
+ rtems_termios_device_context *base =
+&zynqmp_uart_instances[BSP_CONSOLE_MINOR].base;
+
+ zynq_uart_initialize(base);
+ zynqmp_debug_console_out(c);
+}
+
+static int zynqmp_debug_console_in(void)
+{
+ rtems_termios_device_context *base =
+&zynqmp_uart_instances[BSP_CONSOLE_MINOR].base;
+
+ return zynq_uart_read_polled(base);
+}
+
+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-zynqmp-rpu/include/bsp.h
b/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
new file mode 100644
index 00..9b71487999
--- /dev/null
+++ b/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
@@ -0,0 +1,93 @@
+/**
+ * @file
+ * @ingroup RTEMSBSPsARMZynqMP
+ * @brief Global BSP definitions.
+ */
+
+/*
+ * SPDX-License-Identifier: BSD-2-Clause
+ *
+ * Copyright (C) 2013, 2014 embedded brains GmbH
+ *
+ * Copyright (C) 2019 DornerWorks
+ *
+ * Written by Jeff Kubascik
+ *and Josh Whitehead
+ *
+
[PATCH] bsps/stm32h7: disable MPU alignment for M4-based BSP variants
There is no point in wasting precious memory space on enforced section alignment for the purpose of MPU which is not implemented on M4 core anyway. --- spec/build/bsps/arm/stm32h7/optenmpualign.yml | 4 1 file changed, 4 insertions(+) diff --git a/spec/build/bsps/arm/stm32h7/optenmpualign.yml b/spec/build/bsps/arm/stm32h7/optenmpualign.yml index 874385956c..60e45c708d 100644 --- a/spec/build/bsps/arm/stm32h7/optenmpualign.yml +++ b/spec/build/bsps/arm/stm32h7/optenmpualign.yml @@ -7,6 +7,10 @@ build-type: option copyrights: - Copyright (C) 2020 embedded brains GmbH & Co. KG default: +- enabled-by: + - arm/stm32h747i-disco-m4 + - arm/stm32h757i-eval-m4 + value: false - enabled-by: true value: true description: | -- 2.25.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-central v2] spec/wake-after: Update references to intervals
On 28.06.23 20:30, Kinsey Moore wrote: rtems_task_wake_after takes a parameter in terms of a count of clock ticks and not a measure in a subunit of seconds. This updates documentation to reflect that and recommends clock_nanosleep() for applications requiring sleep for a time-based duration instead of a count of clock ticks. Updates #4772 Looks good. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [RSB 2/4] 6: Update GCC 10 and 12
On 29.06.23 02:20, Chris Johns wrote: On 28/6/2023 3:33 pm, Sebastian Huber wrote: On 28.06.23 04:37, Chris Johns wrote: Can you please provide something other than update in the commit message? If it is to pick up patches on these gcc release branches then please say so. This update has no particular reason. I just had a bit of time to run my update script. Ideally there would be an automatic update process in place. If you don't want to follow the upstream release branches, then please say so. However, this work helps to identify RTEMS related issues in the upstream development. Working tools for RTEMS need maintenance. It is not that release versions of GCC magically work on RTEMS. This sounds great. Would it be possible to add a simple comment in the commit message this is a housekeeping update to the latest? It makes it easier reviewing the commit log to understand changes of interest verses such as things we need or make in newlib verses housekeeping. Ok, makes sense. I added this sentence: Keep RTEMS up to date with the upstream development. Are these versions of the compiler tracking tarfile packages? No, the configurations track the release branches. For newlib this makes sense during development and releases because of newlib's long release period. It also works for binutils, gcc and gdb when we are in development however I am not sure it does with releases. Should we look to tarfiles for releases for the binutils, gcc and gdb tools? For RTEMS releases it makes sense to use upstream releases for the tools with as few patches as possible. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Tool versions for RTEMS 6.1 release?
Hello, it seems the RTEMS 6.1 release is getting closer. We should think about the tool versions for the release. For GCC, my preferred choice would be GCC 13.2: https://gcc.gnu.org/pipermail/gcc/2023-June/241838.html In GCC 12 a big change was enabling the vectorization support with -O2. This should have stabilized in GCC 13. GCC 13 contains some RTEMS-specific improvements for Ada. For Binutils and GDB I would just use the latest release available at the RTEMS 6 branch point. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@embedded-brains.de phone: +49-89-18 94 741 - 16 fax: +49-89-18 94 741 - 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
