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

[Chris Johns]

On 17/2/21 11:47 pm, Jan.Sommer at dlr.de wrote:
>> -----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
>> 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?
>>
> 
> Do I understand it correctly, that a patch adding something like the following would be sufficient?

Sort of. The baudrate is now hard coded to 115200 so I it is not clear to me the
purpse of this is other than letting a test pass. It appears we know only
support one console set up.

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

Initialised or always set to 115200? The rate is hard coded.

> Previous configurations from , e.g., a bootloader will be overwritten.

Previous configurations programmed into the hardware by the Xilinx tools or 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.

All except the baudrate.

Chris