Thread (5 messages) flat view 5 messages, 3 authors, 2018-01-31

Handling of chars received while a UART is not open

From: Dave.Martin@arm.com (Dave Martin)
Date: 2018-01-31 13:32:14
Also in: linux-serial

On Wed, Jan 31, 2018 at 01:12:15PM +0000, Peter Maydell wrote:
On 31 January 2018 at 12:06, Dave Martin [off-list ref] wrote:
quoted
Now, Qemu has a facility for stuffing some input to an emulated UART
immediately on boot, and wouldn't work in case (2) above.  OTOH, that
may be a mistaken approach: it's unlikely to work reliably on hardware
due to the problem of knowing when a physical UART is actually ready to
receive input.  So maybe Qemu should be waiting for a prompt to be
transmitted before stuffing input.  In case (1) or (3), qemu probably
needs to do something like that.
FWIW, there isn't a QEMU "facility" for doing this particularly:
we just don't take any trouble to stop the user from providing
input whenever the user likes. (If the user is an automatic test
script then it's that script's job to wait for suitable prompts
from the guest before feeding input into the emulated serial port
if it wants to be reliable, the same way you'd have to if you
were feeding the data to a real serial line.)
Fair enough.  I misunderstood slightly there.
(I think) wouldn't affect the behaviour here, though, because the
data will just get held in QEMU's input buffer until the guest
driver sets UARTEN and then immediately fill the FIFO.
On the Linux side, I guess we nonetheless need to cope with input
stuffed early for the SBSA UART case, but if you're saying that
qemu (or software talking to qemu) shouldn't assume that input
stuffed at boot will actually be received (unless it qemu waits for
UARTEN) then we have some flexibility in the amba-pl011 driver here.

Based on Russell's comments, I guess the fix for the SBSA UART case
would be to read and discard the contents of the RX FIFO on UART open.
It seems harmless to do that for pl011 also, so I would suggest putting
it on the common code path.  This likely minimises the chance of being
tripped up by vendor-specific quirks.
What QEMU doesn't do and probably should fix is that we allow data
into the FIFO even if UARTCR.UARTEN is 0 ("UART disabled"). This
That probably does makes sense, providing qemu models a pl011.
A real pl011 wouldn't receive anything while that bit is clear.

SBSA UART doesn't have this control (or most of the others): it's
just always on.


Cheers
---Dave
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help