[PATCH 1/1] zynq-uart: Fix set_attributes implementation

Chris Johns chrisj at rtems.org
Tue Feb 9 23:08:21 UTC 2021


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 varied.

Maybe something explaining this in the user manual ...

https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html#xilinx-zynq

so we have provided information on what to change?

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.

Chris


More information about the devel mailing list