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

[Chris Johns]

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