Re: [PATCH v2] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT BSP option
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
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
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
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
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
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
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()
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
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
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
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
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
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
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
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
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
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
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
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
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
