Xilinx Zynq console rx not working

[Chris Johns]

On 16/8/21 6:38 pm, Chris Johns wrote:
> On 14/8/21 12:40 am, Kinsey Moore wrote:
>> On 8/13/2021 03:05, Chris Johns wrote:
>>> Hi,
>>>
>>> I am bring up a major app on RTEMS 6 and LibBSD on custom Zynq hardware and I am
>>> not getting any receive interrupts from the console UART. The same hardware
>>> works with RTEMS 4.11 and RTEMS 5.
>>>
>>> I also do not see any console input with qemu and I thought this was something
>>> in qemu but I am now not so sure.
>>>
>>> Anyone else seeing this issue?
>>>
>>> There has been a lot of playing with the Zynq UART driver recently.
>>
>> I just went through and backed out all those changes you mentioned back to when
>> the polled-only driver was split out and I still don't have functionality on
>> Zynq under QEMU. Testing using fileio.exe, things are partially functional until
>> I revert the change that enabled set_attributes. After the commit that enables
>> set_attributes for the zynq UART, fileio produces output waiting for user input
>> and will accept the first character to open the menu, but accepts no further
>> input. Before that commit, the fileio test doesn't produce the expected output.
>>
>> A full bisect would probably provide more accurate results, but this is what I
>> could do quickly.
>>
>> Note that ZynqMP fileio works on QEMU with current code and is fully
>> operational. It is almost certainly the exact same emulated peripheral in QEMU
>> and the hardware is supposed to be very close if not identical as well.
> 
> I have taken a closer look at the driver. I am receiving RX interrupts and the
> characters are being queued however the receive FIFO trigger interrupt is only
> raised when the FIFO reaches the set threshold of half the FIFO size. I suspect
> there is an assumption the RX timeout will fire but it is not.
> 

Doing this is questionable ....

https://git.rtems.org/rtems/tree/bsps/shared/dev/serial/zynq-uart.c#n222

You cannot send a character when touching the attributes. Where is this hardware
bug documented by Xilinx?

My application does this ...

    if (tcgetattr(fileno(stdout), &term) < 0)
        error_message();
    cfsetispeed (&term, B115200);
    cfsetospeed (&term, B115200);
    if (tcsetattr (fileno(stdout), TCSADRAIN, &term) < 0)
        error_message();
    if (tcgetattr(fileno(stdin), &term) < 0)
        error_message();
    cfsetispeed (&term, B115200);
    cfsetospeed (&term, B115200);
    if (tcsetattr (fileno(stdin), TCSADRAIN, &term) < 0)
        error_message();

and this kills the receive interrupts.

Chris