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