On 21.03.24 00:28, Chris Johns wrote:
On 21/3/2024 2:11 am, Sebastian Huber wrote:
On 19.03.24 18:44, Chris Johns wrote:
On 20/3/2024 2:03 am, Sebastian Huber wrote:
On 19.03.24 14:50, Kinsey Moore wrote:
The xilinx-zynqmp-rpu bsp_reset() is modified, but not included in the spec
file for the new option. Its family differs from the arm/xilinx-zynqmp BSP
family with a -rpu suffix.
Yes, but this BSP is quite new. I would prefer to let it not flush anything by
default to carry out a reset.
I'd be fine with this being enabled for the AArch64 BSPs as well, but I
imagine that's better as a separate patch.
Why should it be enabled by default? The arm/xilinx-zynq and arm/xilinx-zynqmp
BSPs were the only ones doing an UART flush in the general termination
procedure. It probably was done to address a specific use case (maybe test
runs).
Is the issue the flush is before an infinite loop which means the UART FIFO
should drain?
What is the issue you are wanting to solve removing the flush?
The bsp_reset() function should reset the system and do nothing more.
Doing additional things like flushing an UART device may not make sense
for all applications. Some applications may not use the UART device, so
it may not be initialized and powered off. Some applications may use it
with an application-specific protocol which doesn't like the additional
four '\r' during reset. Doing a UART flush takes some time and some
applications may prefer a fast reset time. The bsp_reset() is the wrong
place to do add specific cleanup functions. Applications can customize
the termination procedure with their own fatal error extension,
destructors, and exit handlers.
--
embedded brains GmbH & Co. KG
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
