On 28/3/19 5:40 pm, Sebastian Huber wrote: > On 27/03/2019 20:26, Chris Johns wrote: >> 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. > > So even if we implement the set attributes we have the problem to figure out > in > which state the UART is during initialization?
I cannot figure out what the default for RTEMS should be and then how that matches the bootloader and SystemZ settings. > My hope was eventually someone will implement it. Yes it would be good however we need a user who uses the UART for something other than a console. > Since nobody requested the set attributes function in a > couple of years, I think it is all right to just remove it and return no > error. Yeap. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
