Okay. Thank you very much.
I'll take your advice and test.
Let's see the chardev maintainers reply.
Best,
Huan
2017年3月21日 19:28，"Peter Maydell" <peter.mayd...@linaro.org>写道：
> On 21 March 2017 at 18:11, Jiahuan Zhang <jiahuanzhan...@gmail.com> wrote:
> > What do you mean "RXFE will be cleared"?
> > Here RXFE is
> > #define PL011_RXFE 0x10
>
> I mean that as soon as 1 byte of data is ready to read the
> RXFE bit will be cleared in the FR register. So you need:
>
> /* probably you want to actually detect EOF somehow but let's
> * just read 16 bytes
> */
> for (i = 0; i < 16; i++) {
> while (*UART_FR & PL011_RXFE) {
> /* loop until data available */
> }
> /* now read 1 byte, that's all we can be certain is there */
> data[i] = *UART_DR;
> /* ...and then go back and check RXFE again */
> }
>
> >> Are you saying that QEMU is looping round indefinitely calling
> >> pl011_can_receive() and never running the guest at all?
> >
> >
> > Yes, exactly when fifo is full, s->count = 16. pl011_can_recieve keeps
> > returning 0.
> > The guest program is blocked.
>
> Right, but if can_receive returns 0, then QEMU should decide
> "OK, can't do anything here" and run the guest.
>
> > I am using a windows named pipe to get the data from a window
> > host program, which uses ReadFile () in char_win.c
>
> OK, bugs in the windows-specific char backend would be
> unsurprising.
>
> I'm not entirely sure how the chardev layer works, but
> at the pl011 end if we return 0 from our can_receive
> function then the chardev layer should decide it has
> nothing to do until the pl011 later calls
> qemu_chr_fe_accept_input(), I think.
>
> I've cc'd Paolo and Marc-André Lureau as the chardev
> maintainers.
>
> thanks
> -- PMM
>
