On Mon, Feb 22, 2021 at 6:41 AM <jan.som...@dlr.de> wrote: > > > > > -----Original Message----- > > From: Chris Johns <chr...@rtems.org> > > Sent: Saturday, February 20, 2021 11:57 PM > > To: Gedare Bloom <ged...@rtems.org>; Sommer, Jan > > <jan.som...@dlr.de> > > Cc: devel@rtems.org > > Subject: Re: [PATCH rtems-docs] user/bsps: Mention fixed console baud rate > > for zynq > > > > On 20/2/21 3:59 am, Gedare Bloom wrote: > > > On Fri, Feb 19, 2021 at 1:21 AM Jan Sommer <jan.som...@dlr.de> wrote: > > >> > > >> --- > > >> user/bsps/arm/xilinx-zynq.rst | 14 ++++++++++++++ > > >> 1 file changed, 14 insertions(+) > > >> > > >> diff --git a/user/bsps/arm/xilinx-zynq.rst > > >> b/user/bsps/arm/xilinx-zynq.rst index 365c336..dcc0649 100644 > > >> --- a/user/bsps/arm/xilinx-zynq.rst > > >> +++ b/user/bsps/arm/xilinx-zynq.rst > > >> @@ -37,6 +37,20 @@ to return the peripheral clock. Normally this is > > >> half the CPU clock. This function is declared ``weak`` so you can > > >> override the default behaviour by providing it in your application. > > >> > > >> +Console > > >> +------- > > >> + > > >> +The console driver for the UARTs will always be set to a baud rate > > >> +of 115200 with 8 bit characters, 1 stop bit and no parity bits > > >> +during start up. > > >> +Previous configurations programmed into the hardware by the Xilinx > > >> +tools or a bootloader will be overwritten. > > >> + > > >> +The settings for parity and stop bits can be changes by the user > > >> +application. The baud rate is hard coded to 115200 and can not be > > >> +changed. > > >> + > > >> + > > > Only 1 blank line here please. Chris to approve the content, I think > > > he has the most to say on this topic :) > > > > It is OK for master because it is what we have. Joel and I have been > > discussing the issue of the hardcoded baudrate and the issues it presents. > > If > > we decide something needs to change this documentation can change. > > > > The issue is there are 2 UARTs on the zync and if one is used for the > > console > > the fixed rate is fine however if one is used for another purpose not being > > able to set the baudrate is a bug in RTEMS. > > > > That actually is a use case for us. > I have taken a closer look at the source and I don't see any reason why the > baud rate should hard coded. > It looks like it is only missing the switch-case for the termios Baud options. > I will prepare a patch. > Can you update this patch to reflect the baud rate selection?
> Best regards, > > Jan > > > Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel