qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Questions regarding emulated UART in VersatilePB board


From: Peter Maydell
Subject: Re: [Qemu-devel] Questions regarding emulated UART in VersatilePB board
Date: Mon, 4 Sep 2017 09:50:38 +0100

On 4 September 2017 at 01:27, Ramy Sameh <address@hidden> wrote:
> *My 2 questions are:*
>
> *First:*
> Are interrupts activated in the emulated pl011 ?
> I mean, if I enabled the interrupt bits for UARTTXINTR, will this trigger
> an interrupt when the FIFO reaches a certain level?

Yes, we implement interrupts.

> *Second:*
> Another problem is that I can't find some of the UART registers (which are
> in the data sheet PrimeCell UART (PL011)), in QEMU's emulated UART pl011.
>
> *These are the registers which I can't find their matches in the structure
> PL011State:*
>
> 1.) Interrupt FIFO level select register, UARTIFLS
> 2.) Raw interrupt status register, UARTRIS
> 3.) Masked interrupt status register, UARTMIS
> 4.) Interrupt clear register, UARTICR
> 5.) Peripheral identification registers, UARTPeriphID0-3
> 6.) PrimeCell identification registers, UARTPCellID0-3

All these registers are implemented. You can find the code that
implements them in the pl011_read() and pl011_write() functions.

> *This is the structure where I get pl011 emulated registers:*
> typedef struct PL011State

This structure defines (among other things) fields which
hold the underlying state of the device (in hardware terms,
usually information which is in a flipflop or otherwise
stored). This is not the same as a guest-visible register,
although there is very often overlap. For instance, the
ID registers are constant and read-only, so they do not
have any modifiable state that we need to put in the struct
(in hardware, they'll be implemented by just tying off
lines to 0 or 1, not with flops). Sometimes a register
value as seen by the guest is just a logical combination
of state used by other registers, eg UARTMIS is just the
logical OR of UARTRIS and UARTIMSC, so it doesn't need
any extra state in the struct.

Some of the state fields have names that don't correspond
to the register names for historical reasons (eg UARTIFLS
is in s->ifl); you should always start with the read and
write functions to look at how the register behaviour
is implemented, which will show you which state fields
if any are involved.

thanks
-- PMM



reply via email to

[Prev in Thread] Current Thread [Next in Thread]