On 28/3/19 5:28 am, Joel Sherrill wrote: > On Wed, Mar 27, 2019 at 1:10 AM Sebastian Huber > <sebastian.hu...@embedded-brains.de > <mailto:sebastian.hu...@embedded-brains.de>> > wrote: > On 26/03/2019 15:17, Lou Woods wrote: > > From: Lou Woods <lou.wo...@oarcorp.com> > > > > --- > > bsps/arm/xilinx-zynq/console/zynq-uart.c | 16 +++++++++++----- > > 1 file changed, 11 insertions(+), 5 deletions(-) > > > > diff --git a/bsps/arm/xilinx-zynq/console/zynq-uart.c > b/bsps/arm/xilinx-zynq/console/zynq-uart.c > > index fa91f3f..9c21f6f 100644 > > --- a/bsps/arm/xilinx-zynq/console/zynq-uart.c > > +++ b/bsps/arm/xilinx-zynq/console/zynq-uart.c > > @@ -262,12 +262,16 @@ static void zynq_uart_write_support( > > #endif > > } > > > > +/* > > + * Disable this because the initialization is done by code generated > > + * by the Xilinx code generator. > > + */ > > The main purpose of the set attributes function is to apply the settings > specified by the user via the Termios interface. Returning false just > indicates that this function is not implemented. If you want to hide > this fact from the user, then you can simply return true ...
This assumes all UART hardware supports all possible options. There are many UARTs that do not. I am not sure if there are errno's that could determine the nature of the failure. > We discussed this alternative with Chris and this was the end result. > > git blame shows that Chris added the if 0 and then you added the return false > which broke the callers. From that point forward, no interactive test ran > successfully. The driver provides no attribute functionality so removing the function means the default behavior in termios is used to manage the error. It was decided having the default behavior was best until the driver provided the functionality. The Zynq is sort of strange in relation to default settings for UARTs. The SystemZ component in the Xilinx design tool provides settings for the UART and this ends up in the ps7_init.c file generated by the SDK and built into the FSBL bootloader. This code paints all registers including the UART at boot time. Adding UART attribute setting code to the RTEMS driver would result in the SystemZ settings being overridden by RTEMS which is confusing. I am not sure how this can be handled without there being some conflict. RTEMS would need to set the baudrate to 115200 to match the SystemZ default. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel