[PATCH v2] bsps: Add BSP_FLUSH_KERNEL_CHAR_OUTPUT BSP option

Chris Johns chrisj at rtems.org
Tue Mar 19 17:44:35 UTC 2024


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


More information about the devel mailing list