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.
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.
Kinsey
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
