On 19/8/21 10:45 pm, Kinsey Moore wrote: > On 8/18/2021 18:02, Chris Johns wrote: >> On 19/8/21 5:49 am, Kinsey Moore wrote: >>> On 8/18/2021 13:20, Chris Johns wrote: >>>> On 19/8/21 3:41 am, Kinsey Moore wrote: >>>>> This is functional on the ZynqMP board I currently have setup for testing >>>>> and on >>>>> ZynqMP QEMU except for the data corruption/loss caused by the removal of >>>>> the >>>>> post-baud-set null write. >>>> Thanks for the testing. >>>> >>>> I am not sure if you are saying both the ZyncMP hardware and qemu need the >>>> write >>>> or just qemu. The write may work but it does not make sense because at some >>>> point the software will print a character and achive the same thing? >>> QEMU works fine either way. The ZynqMP hardware is what has issues without >>> the >>> null write. >> OK >> >>> The problem is that it's picky about which characters will actually fix the >>> data >>> loss/corruption. >>> I've seen that both space and null will do it while letters and numbers >>> won't. >>> Null was chosen specifically because it's not printable. >> It shows up on Zynq consoles I have running a a junk character. >> >>> Without this null print, I see garbage >>> output and it eventually starts printing text correctly. >> How many characters? It smells like a clock is hunting. I suggest you ask >> Joel >> to raise this with Xilinx to see if there is any known errata. > The number varies depending on the text being output. It continues spewing bad > characters until > it encounters a character that resets whatever internal mechanism is causing > this. I'll see if we can get some information from Xilinx.
Interesting. A nul character means a single level on the line and that implies a signal filtering issue, ie a low freq signal. >> Another suggestion is downloading the Xilinx SDK and looking over the bare >> metal >> console support to see what they do there. > The sticking point here seems to be baud rate manipulation and the TX/RX reset > that must occur. > The bare metal driver has code for this, but it is never called as far as I > can > tell. I still haven't found > the startup sequence that initializes the UART, but I'll take another look. Ok and thanks. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel