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

2024-03-27 Thread 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 v2] RTEMS: Add multilib configuration for aarch64

2024-03-27 Thread 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

Re: Xilinx header files installed by BSP

2024-03-27 Thread 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

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

2024-03-27 Thread 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

2024-03-27 Thread 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

PowerPC e7400 executable is type powerpc:e500 making debug difficult

2024-03-27 Thread Peter Dufault 
The PowerPC e7400 executables I built for the PowerPC-Beatnik BSP have an 
architecture of "powerpc:e500".  I assume it is like this for any powerpc 
target that includes "ppc_exc_initialize.c". This causes "GDB" to use the wrong 
size register set in remote debugging, and I couldn't figure out how to 
convince "gdb" to do something different.  I tried multiple settings but the 
"bfd_arch_info" wouldn't change from "powerpc:e500" (seen with "maint print 
architecture") and "gdb" continued to use the wrong register set size.

(gdb) set powerpc vector-abi altivec
(gdb) set arch powerpc:7400
The target architecture is set to "powerpc:7400".
(gdb) set gnutarget powerpc:7400
(gdb) target remote 192.168.240.3:2159
Remote debugging using 192.168.240.3:2159
Remote 'g' packet reply is too long (expected 292 bytes, got 412 bytes): 
003a5914007a0ae0007a7b60006577e00052af140052af1c007a0ac80a010014003764ec2062885000645760007a0ae00037265c0202b03240376508003764ecfff8
(gdb) maint print architecture
gdbarch_dump: GDB_NM_FILE = 
gdbarch_dump: bfd_arch_info = powerpc:e500
gdbarch_dump: byte_order = 0
gdbarch_dump: byte_order_for_code = 0
(...)

This is because "ppc_exc_initialize.o" has a ".PPC.EMB.apuinfo" section that 
says it needs the "E500 SPE APU".  Here's what is in that section.

0 | 0008 | 8 bytes in "APUinfo\0"
4 | 0008 | 8 bytes (2 words) of APU information.
8 | 0002 | Section type is rev 2.
12 | "APUinfo\0"
16 | 0101 | APU 0x100 "e500 SPE APU" revision 1
20 | 00410001 | APU 0x041 "Motorola Book E Performance Monitor APU" revision 1.

The resultant linked output is the superset of all requirements, so the linked 
output is also "powerpc:e500".

This is because "ppc_exc_initialize.c" includes instructions for different 
targets that it avoids at run time.

These code lines cause the ".o" to be "powerpc:e500":

ppc_mtivor(32, ppc_exc_vector_address(ASM_E500_SPE_UNAVAILABLE_VECTOR, 
vector_base));
ppc_mtivor(33, ppc_exc_vector_address(ASM_E500_EMB_FP_DATA_VECTOR, 
vector_base));
ppc_mtivor(34, ppc_exc_vector_address(ASM_E500_EMB_FP_ROUND_VECTOR, 
vector_base));

This line causes the ".o" to be "powerpc:titan" (if the above E500 lines are 
removed):

ppc_mtivor(35, ppc_exc_vector_address(ASM_E500_PERFMON_VECTOR, vector_base));

I "#ifdef'd" them out to get it to "work" but unless someone can figure out how 
to get rid of that section in the output "ppc_exc_initialize.c" needs to be 
changed to be conditionally compiled.

If no one has any good ideas I'll open a bug with this.

Peter
-
Peter Dufault
HD Associates, Inc.  Software and System Engineering



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

[PATCH] bsps/xilinx-zynqmp-rpu: Avoid constant UART reinit

2024-03-27 Thread Kinsey Moore 
Constant reinitializations for BSP_output_char causes loss of output
data on QEMU. This change only initializes the UART once.
---
 bsps/arm/xilinx-zynqmp-rpu/console/console-config.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c 
b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
index f52e008f2b..67e1e92c62 100644
--- a/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
+++ b/bsps/arm/xilinx-zynqmp-rpu/console/console-config.c
@@ -108,6 +108,7 @@ static void zynqmp_debug_console_early_init(char c)
 
   zynq_uart_initialize(base);
   zynqmp_debug_console_out(c);
+  BSP_output_char = zynqmp_debug_console_out;
 }
 
 static int zynqmp_debug_console_in(void)
-- 
2.39.2

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

Re: [PATCH] bsps/xilinx-zynqmp-rpu: Avoid constant UART reinit

2024-03-27 Thread Sebastian Huber 

On 27.03.24 18:34, Kinsey Moore wrote:

Constant reinitializations for BSP_output_char causes loss of output
data on QEMU. This change only initializes the UART once.


This is also fixed by my recent UART patch set. I would prefer to clean 
up this copy and paste nightmare.


--
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 1/3] dev/serial: Simplify some Zynq UART functions

2024-03-27 Thread 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(&zynqmp_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 =
-&zynqmp_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 =
-&zynqmp_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 =
-&zynqmp_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 =
-&zynqmp_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 =
-&zynq_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 =
-&zynq_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 =
-&zynq_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(&zynqmp_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 =
-&zynqmp_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 =
-&zynqmp_uart_instances[BSP_CONSOLE_MINOR].base;
-
-  zynq_uart_initiali

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

2024-03-27 Thread Sebastian Huber 
This helps to provide a shared implementation of the kernel I/O support.
---
 bsps/aarch64/xilinx-zynqmp/console/console.c  |  4 +-
 bsps/aarch64/xilinx-zynqmp/include/bsp.h  |  2 +
 bsps/arm/xilinx-zynq/console/console-config.c |  5 +-
 bsps/arm/xilinx-zynq/include/bsp.h|  1 +
 .../console/console-config.c  |  4 +-
 bsps/arm/xilinx-zynqmp-rpu/include/bsp.h  |  2 +
 .../xilinx-zynqmp/console/console-config.c|  4 +-
 bsps/arm/xilinx-zynqmp/include/bsp.h  |  2 +
 bsps/include/dev/serial/zynq-uart-zynq.h  | 66 +++
 bsps/include/dev/serial/zynq-uart-zynqmp.h| 66 +++
 10 files changed, 148 insertions(+), 8 deletions(-)
 create mode 100644 bsps/include/dev/serial/zynq-uart-zynq.h
 create mode 100644 bsps/include/dev/serial/zynq-uart-zynqmp.h

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/aarch64/xilinx-zynqmp/include/bsp.h 
b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
index 0ccca8b196..38a9fad768 100644
--- a/bsps/aarch64/xilinx-zynqmp/include/bsp.h
+++ b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
@@ -55,6 +55,8 @@
 #include 
 #include 
 
+#include 
+
 #ifdef __cplusplus
 extern "C" {
 #endif /* __cplusplus */
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-zynq/include/bsp.h 
b/bsps/arm/xilinx-zynq/include/bsp.h
index 3311a99b50..5ffd5f573a 100644
--- a/bsps/arm/xilinx-zynq/include/bsp.h
+++ b/bsps/arm/xilinx-zynq/include/bsp.h
@@ -55,6 +55,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef __cplusplus
 extern "C" {
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-rpu/include/bsp.h 
b/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
index e386bd4b26..d80cedbd0d 100644
--- a/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
+++ b/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
@@ -61,6 +61,8 @@
 #include 
 #include 
 
+#include 
+
 #ifdef __cplusplus
 extern "C" {
 #endif /* __cplusplus */
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_

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

2024-03-27 Thread 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  |  5 +-
 spec/build/bsps/optconminor.yml   | 21 
 spec/build/bsps/optzynquartkernbase.yml   | 22 
 16 files changed, 90 insertions(+), 221 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 = &zynqmp_uart_instances[i];
 char uart[] = "/dev/ttySX";
 
 uart[sizeof(uart) - 2] = (char) ('0' + i);
@@ -215,10 +215,10 @@ rtems_status_code console_initialize(
   &uart[0],
   &zynq_uart_handler,
   NULL,
-  &zynqmp_uart_instances[i].base
+  &ctx->base
 );
 
-if (i == BSP_CONSOLE_MINOR) {
+if (ctx->regs == (zynq_uart *) ZYNQ_UART_KERNEL_IO_BASE_ADDR) {
   link(&uart[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

GSOC x86_64 BSP Proposal

2024-03-27 Thread Matheus Pecoraro 
Hey,

Here is the first draft of my proposal, I appreciate the feedback.

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

[PATCH] Added screenshot of output

2024-03-27 Thread the-m3chanic 
---
 hello.c   |   2 +-
 output_screenshot.png | Bin 0 -> 111964 bytes
 2 files changed, 1 insertion(+), 1 deletion(-)
 create mode 100755 output_screenshot.png

diff --git a/hello.c b/hello.c
index 72d1dd4..1d6fa3e 100644
--- a/hello.c
+++ b/hello.c
@@ -9,6 +9,6 @@ rtems_task Init(
   rtems_task_argument ignored
 )
 {
-  printf( "\nHello World\n" );
+  printf( "\nthe.m3chanic can work with RTEMS! And hello from the dark side :) 
\n" );
   exit( 0 );
 }
diff --git a/output_screenshot.png b/output_screenshot.png
new file mode 100755
index 
..1066d1a7f5a23fd02a89165c3d795eca2e552326
GIT binary patch
literal 111964
zcmZs?cU)7;7B-BcpwdKCn!rI6P(VtM(4zuDM8Hb#C4lq}0tpBL(vc=zDT2~_Clm=C
z3@9B!4>cjQ1QL=ro^#&&-uwN&KiKS<>^*yC&6+i9J?ohd&$QKc2A{FVr8=lnvk5pcc;AKGb?hLsJ>YK(aVbEnjqfY~Vpd
zbH($|-aIudd=f15#9&1iSt`|Ha_ce<1
zq)Zw-!oeDoo`UiD7(;pc*R}(%DSK&~QEsk1tUJjN|001UioixJX*~5NgHcF@rjiWVv`Nx|pn}q-?lacrz3c^<4V&(O5I*
z4;&bMfArgP!EwcGUTxY&;E70#e?2E*K92m>sRolph%*I?L!aw>3r?%h_fTt03>Of5<7*cGgZJ#mHh^-gd|
zh!m{(+N&#j(9QbL&kEEJL51kjV%j9lX*P71UEnXDK(F&lnBlEkUj+T!V>foz>`(pa
z`%Nt8kb^_Y;@3PaO2_aDU&WEx=-B70mB!$;wKD>Omj&TY)|39}OoBz1^nfcxdeI3v
zF+5D;%C#28drH?QzPw5<|HcsGrD+xZ_t5{o6otle2R&Dv8f0aR)vjePY9*cxY+D^Hb?xNo?r=Vm%aAl!LJURl5k#gk;c{87ur}kj{Z1wB?
zl{7E$vJu-nsE-{Nt|fV(w!8!`&JdlcwggBPJbd!8qr#@UEv>9`6Dk?uV^j+WU$`KXNE)0kGkjpm5(;3gbneCptDR}*!9F^n{{0<
zauaR@l-)WDj<%om=xz59@QE3jq4p}U&CNW3Yv-QY7BnW;p*^d+Xe5SX7dJ<77$KyQJz08eLm*u99tgMZi6)3Rq>r8mb
z1=V)U{9qP~z#`$m%hw+qs|OIHl_3i*p?*Iaz@O%wN&3hOTkKpTyh@h~Lp=`P9lA-s
zfg@VkxJDc$ZyMs)9&mjbRQ-TyYsLZ9mre4Wt}G3Tu}+!~vA7EpxE47puer(XViIzk
zGJ#IU`)$A9f5RyZ!Jl0U2OtXWA4eUyggX7Gi>YvKQ7&omnfpjsqg$Cscu7DYP!VuM
zy_x_wUb-wqg!?6sRAX9-3EI?=OV+??~HTF1m-$7=fy
zCN*oUXi+u077nj9KpV(!ZfNtg3+(5T4=VAi!D*Q`y@Vh#K~h|eiR>r_ZnBmkHiyRm
zr4RgK)7dNHqjm50zSyL~Uhl{(IXNjut&=mo+`qu|Vp*ZefZ2kF&5EWg^kTrU@C)*H
zJMnAwc)~fQiN`$&3iq>Zz#?8xm!BRR5bXq%rAT+WzspAd=u)3@GjH(L&YNXbZoB=4
zq>?Sr13b}**_-GMsaPBTvNL|mxm`!aIeNMya^W)Q|Jt6*k0PEF1+pwiKZ_`B^D^07hb7tOG0*NAq@-7;
zbHNI=IzK<+S(_^!i1i&=rUE%=j@OMvCa
zP9DUcJA7P3gKq!9GPj-yuP%^iq4Cw^+VS-6s*%E&$$#W%*)aMj>Lt_GC%I3vLQbne
zSGdnlt51{+8K1I_1PGnG}>^G3oU{n9Cpw=lp9E}aAhVbQr(Q?4cN{z0(3V|?AUj(K;2W&=r@
z25mb&|A~jXT(~V-Z!47yf}g&7kI^}}naIQgTgXZ)oV+vkt=y~=-y*lcb*ljGYnekLD^(4^lp
zxVBSpbB8x49?hY;h<5UUy~ib3AM!ZRcLHVH{VS~29qEqW%g4GrPI(BtkpCXXt_z&j
zXs<8zyG0~_-@G>Sa;mksv&k?1(q1i~#2;anZExGe@bCV2`4OYuo3t~cP2mv0K75P`z)GLVY3>uM+`@o~+`}{~8-H-pXqB
z=R>L!6}TSn*t$uyCUQ@Ya=Y#3XT9asvFhvK8D2ka={MV7k#IP{F5vYA{&4}he@3Z_
zm9Xp#y|`srZ`Y9;XMF9{Vp+ecnPpCzTi>F3q%*3>CNnkUcaRx3MePFrNn$CK2vVEjAyVY=89t}=
z>pK*p&#;&(@LhrjddybcO3;bD)bIpy(3z~>4cidSx~J~9Y*UU^nup4eF4?CjWHDubWU086e>kGKwpdqH{B#u-txP%`z?p?!whV%}cUl|rxC387
z>ohT!{vIE)w3o&>s4*3K*-6gL#B(H%TMgz#MBsiOA+^YTG@_f3UuOhzk%h4lFg0Yj
zS?U?t(EH0@!Now(bfY?DjUHKaZA7mA@?87ZX1*&pQWJOQZ4*zD5{9oQyRPvaWdsj~Yz
za-}bEP5}|ivsI?F+fIuyzV>DD1_&BZGjOlDp{Al@RU=$GS1HKDoe<0?w=7KBPoz!D
z%{pj?4Yiv)&?DAcLY0M@67TDjM2#ye#0yO*mbu;iQo>ywc!133#I#eVvl1uMteSy6
z_5V{6?;6yJcHyAu!R~H6ysad`ofI&PO5C00WuITp-cLSg_kXrPr0aG*bDl!f%=X0K
zvngK`qDZ)R9UaWkcd|lT!k^Pi+>ON8$o|UUfF>j>z;@o^vwGF`3RjVfs=(hObGL*Z
zt=g`8{JoyC&W0?13Fqb7sqEoZiG~NA*$3ntM*|>&i;W{N@;*im0}v3R##j8)_Jvuq
zsN&p96bX|12wE90=L6>q8v1E?-lns!n*N4sP;(E<%WBVcx_6B2(&YU|Xsdo8S^bM`
zQ$ijHpP&FDk0FsGrp}c4hEq(=Wk14tn3wY!cC+#C8CrLip$sO3M0zs@mCt#9cqs)B
zST+cudq{5UZtIb+uN+#ml~Ysx9KQzjkL5I#*l1ri$!MA(Ou&!R8MZ`F#6&`5kZDw^
z2K^26@XE`bjXUxe_i${5#sFbWJvjUqQ@;Mm4^UHDL063PcfDIe{}|!$sjnP@i^+PX
zAD{<$d}=jhDKTyw9V#+u@pU^$%pv_SDSjulNcvT%ygF)mxcM8&Al_2(P~Q9%B4WtVPwcKMh
zSr06f<@ti-AZ+B)>gCzR1XQKx3vdmf8i*gR3wn4HECl9mPGfv@V1kj4+yjzvQs^)(
z?|Gm%Q@d0;hwQWMWtr|Ke+(bF*aNWTFortG^k8^?`(S6Vy=ME{F-BBX=z+S#G0Q#g
zy;vnkLV@V<;Dg8sEUAvDG`pViR?YoyJ;?=B+>i`=#+clYDrU4+<^esL3f>X>)Gcp6
z`t!HD#C5Cu72nNog}G*@n|c`ek<)EkkcV?ozqtVd6g`ncEzbFTa!bCQBS~5+bGKjp
z>3Rj65=aMlN;{&2`@wc^cK3r$KxbC-htEnul1ox~smL5p)lrG%@)*U#FDiKQN1|W?pVH@4WB{
z$yQfA9Mde1H*NDHS@o?^NPM7Zs-;rE#zvS@4tv)NHNk2qxX;so`+R<+eLM}hRHr0{
zdD5fSNb2ozKP%EBN?i@M&tjEpCZ@%w6BK+LiaHifuj)$gu=#36`Q5u74&t4YDnZF^
zbgdVu&_RT%YdlOJWzRrHr`O}+jPBpc{L#mfGbMad82;Vt1((X=F**m-u%_5TSc=ka
zpMw&2sE|WA@7vxigOkN~4EG|wYGqt^s_GL&QYZPc5`NYL`CHG7r}c2$2$NkEeO#S@
zj0hVv+}~}oTM+`w;+s&a$W0?|IEY&pX2;;K9fu{&_Vcu!ay{>aNso+;P6biZppHMBJZG`;x>jcB8ai!+rZH)g2XuFJdC%k2Vd7Aj~
zbHwaP#aI@q?gl@=aNg)(7)Z*sw%nD!-SHw=s$xDHDTe1RzKSD-|EPan$hN8tU2BN#Hre(
zHR(m^knM*1@V0tATg=Qaf*JT@3li$W&Fz}F{q}6Hj0!Zumio=aKFq^#m7UedM|kxb
zbXC8KF#qxU2CF{gtsi|+dMty?1GzH;36vYF9YV*$cbCtT(1}pn1kv(?0f`HNOCoyB
zgrN*Gj$Z@*hVN^&k3W_O`BJ{yxPS-Djx`{STXlQc?>C3GNtS-B62_3^}{z3vnt!(L?Q-`
zgaQ=OJ=^(YeGIcJNSd6+Qs@Jw(Y&YffBd#wK){BknY%4xhT73VEn1>V22f#HZw?Wu
zHkS0fXV#`j)|5;?u17(MOk8@Bo*B>UF6=NDw(@;Cj9Q%NX*)w1f{uxu6FcJ+qrr7(
z4+tJ2D7@{wURKGX7-IR3nTAI|K4yDMMZhydVAvh+DZp`FGWKj(yC@k|UJ^~-?R_1B
zFq`zRzmL=iFORI7k)Lr*zEuuWa8@|T;t<8fNs#dSd$zkRWX_zaz!*SDdax&H(hGA8
zqAVv?uL=b3a8i7Nz)2T?N&c4BQ3K|dc+%UR*Av(jQZHn{K
z5P_i?+ve|iG-ay}upN#r&ksq!73IacBg_^CnC$X{jSC+zfqNTFJv7q
z8aRBeP6ad^H=KE_fAm2EZ@%uF&5z(IACO|)$1At53)9pyt0`Zm3+I!c$trlnI
zf?4b!6x56BkZL}7b%>+Ex2)b$$s^B;Dlaetx_*qk)A`Ms>rA$h(0C;o18
z=rA4;^n5fL9$Ic<^ZM{f+uPga

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

2024-03-27 Thread Chris Johns 
On 28/3/2024 6:43 am, Sebastian Huber wrote:
> This helps to provide a shared implementation of the kernel I/O support.
> ---
>  bsps/aarch64/xilinx-zynqmp/console/console.c  |  4 +-
>  bsps/aarch64/xilinx-zynqmp/include/bsp.h  |  2 +
>  bsps/arm/xilinx-zynq/console/console-config.c |  5 +-
>  bsps/arm/xilinx-zynq/include/bsp.h|  1 +
>  .../console/console-config.c  |  4 +-
>  bsps/arm/xilinx-zynqmp-rpu/include/bsp.h  |  2 +
>  .../xilinx-zynqmp/console/console-config.c|  4 +-
>  bsps/arm/xilinx-zynqmp/include/bsp.h  |  2 +
>  bsps/include/dev/serial/zynq-uart-zynq.h  | 66 +++
>  bsps/include/dev/serial/zynq-uart-zynqmp.h| 66 +++
>  10 files changed, 148 insertions(+), 8 deletions(-)
>  create mode 100644 bsps/include/dev/serial/zynq-uart-zynq.h
>  create mode 100644 bsps/include/dev/serial/zynq-uart-zynqmp.h
> 
> 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/aarch64/xilinx-zynqmp/include/bsp.h 
> b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> index 0ccca8b196..38a9fad768 100644
> --- a/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> +++ b/bsps/aarch64/xilinx-zynqmp/include/bsp.h
> @@ -55,6 +55,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #ifdef __cplusplus
>  extern "C" {
>  #endif /* __cplusplus */
> 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-zynq/include/bsp.h 
> b/bsps/arm/xilinx-zynq/include/bsp.h
> index 3311a99b50..5ffd5f573a 100644
> --- a/bsps/arm/xilinx-zynq/include/bsp.h
> +++ b/bsps/arm/xilinx-zynq/include/bsp.h
> @@ -55,6 +55,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #ifdef __cplusplus
>  extern "C" {
> 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-rpu/include/bsp.h 
> b/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
> index e386bd4b26..d80cedbd0d 100644
> --- a/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
> +++ b/bsps/arm/xilinx-zynqmp-rpu/include/bsp.h
> @@ -61,6 +61,8 @@
>  #include 
>  #include 
>  
> +#include 
> +
>  #ifdef __cplusplus
>  extern "C" {
>  #endif /* __cplusplus */
> 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

Re: Xilinx header files installed by BSP

2024-03-27 Thread Chris Johns 
On 27/3/2024 7:14 am, Kinsey Moore wrote:
> 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.


Reduced exposure and/or removal would benefit us long term. The upstream repo is
a company over wall one and forced pushes and bulk updates happen based on the
internal Xilinx release cycle for their tools.

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