[PATCH v2] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT BSP option

[Chris Johns]

On 21/3/2024 5:39 pm, Sebastian Huber wrote:> 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.

This makes sense however the console needs this. Removing the code as my reading
of this changes does breaks those systems where the console is in use and relies
on the UART being flushed. A solution that addresses the console side of things
would be more acceptable. You present some valid cases for making a change but a
user should be able to enter reset in a shell and see all output or invoke a
fatal error and expect to see the full error message.

Chris