[PATCH rtems] arm/xilinx: Fix zynq-uart interrupt receive

[Kinsey Moore]

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