[PATCH 1/1] zynq-uart: Fix set_attributes implementation
Jan.Sommer at dlr.de
Jan.Sommer at dlr.de
Wed Feb 17 12:47:06 UTC 2021
> -----Original Message-----
> From: Chris Johns <chrisj at rtems.org>
> Sent: Wednesday, February 10, 2021 12:08 AM
> To: Sommer, Jan <Jan.Sommer at dlr.de>; devel at rtems.org
> Subject: Re: [PATCH 1/1] zynq-uart: Fix set_attributes implementation
> On 9/2/21 11:42 pm, Jan Sommer wrote:
> > From: Kinsey Moore <kinsey.moore at oarcorp.com>
> > The zynq-uart set_attributes implementation was configured to always
> > return false which causes spconsole01 to fail. This restores the
> > disabled implementation which sets the baud rate registers
> > appropriately and allows spconsole01 to pass. This also expands the
> > set_attributes functionality to allow setting of the stop bits,
> > character width, and parity.
> Hmmm I missed this change.
> Sebastian changed the Zynq driver to return an error. Returning an error is
> correct because the attributes are not being set however we have a couple
> of design approaches clashing.
> The issue pulls right back to the Xilinx SystemZ design dialogue box. The
> hardware designer has the ability to set the serial port defaults. These
> settings form part of the ps7init data the FSBL paints into the hardware very
> early in the boot process. Also in this data are parallel port pin settings, AXI
> clocks, memory and more so lots of important stuff. The Xilinx bootloader
> and ones I have created (I do not know about uboot) do not touch the UART
> hardware on purpose so the system designer has control. Then in 2017
> Sebastian pushed a change to force the baudrate to a BSP specific default.
> This is normally all OK because all Zynq designs I know of use the default of
> 115200,8,n,1 for the configuration. A problem arises when these defaults are
> Maybe something explaining this in the user manual ...
> so we have provided information on what to change?
Do I understand it correctly, that a patch adding something like the following would be sufficient?
The console driver for the UARTs of the Zynq SoC will be initialized to a baud rate
of 115200 with 8 bit characters, 1 stop bit and no parity bits.
Previous configurations from, e.g., a bootloader will be overwritten.
If a different setting is required, the user application can configure the console device
through the standard termios API, e.g. in the init task.
> The other approach is not to touch the defaults in hardware and allow a get
> attributes to discover them? Does termios drivers have a low level get? I can
> see a set but no get in the zynq uart driver.
More information about the devel