On 17/2/21 11:47 pm, jan.som...@dlr.de wrote: >> -----Original Message----- >> From: Chris Johns <chr...@rtems.org> >> Sent: Wednesday, February 10, 2021 12:08 AM >> To: Sommer, Jan <jan.som...@dlr.de>; devel@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.mo...@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 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel