Re: SBSA UART bug report and questions

[Andrew Jones]

On Mon, Aug 01, 2016 at 02:24:53PM +0100, Andre Przywara wrote:
> Hi Drew,
> 
> (CC:ing Dave)
> 
> On 01/08/16 13:50, Andrew Jones wrote:
> > 
> > Hi Andre,
> > 
> > I have a couple questions and a bug report regarding the SBSA UART.
> > 
> > When AArch64 Linux is boot with QEMU and UEFI (AAVMF) we can enable
> > the use of ACPI. When we do that the PL011 model QEMU provides is
> > exposed via the _HID ARMH0011. The Linux driver (amba-pl011.c)
> > only associates this _HID with the SBSA UART. Is that _HID supposed
> > to be specifically the SBSA UART? The '11' in the ID makes me think
> > a full PL011 would be more appropriate.
> 
> The SBSA UART is a subset of the PL011 UART, so any PL011 hardware can
> be accessed by a SBSA UART driver, given that the UART has been properly
> initialized before.
> At least some months ago the ACPI spec wasn't powerful enough to
> describe the required clock the PL011 needs, so the "clock-less" SBSA
> was used to have a console on ACPI systems. I don't know if the ACPI ID
> is meant to describe a fully-features PL011 in the future as well.
> 
> > My second question is about the SBSA UART specification. The spec
> > doesn't provide any registers to reset the FIFOs. Section 6.4 says
> > the FIFOs should be enabled by hardware-specific software. However,
> > even if that's done, then, if Linux does a driver-level shutdown of
> > the UART, and then starts it back up again, it seems a FIFO reset is
> > in order. Is there any way to reset the SBSA UART FIFOs that I don't
> > see?
> 
> The SBSA spec does (deliberately) not specify the registers needed to
> initialize the UART, it is expected that this is done by firmware in an
> implementation defined way (which could be using the respective PL011
> way of setting things up).
> So I am afraid there is no way of resetting the FIFOs.
> 
> > The bug report is just my second question formulated differently;
> > 
> > While Linux is booting the UART is started and stopped a few times.
> > If the user sends characters to the UART during boot (just types on
> > the terminal), then when the boot completes, and a login is presented,
> > the user cannot input any characters and log in (Note, this is with
> > QEMU's PL011 model. I don't know the status of boots with hardware,
> > and it doesn't appear kvmtool emulates the PL011.) This is only seen
> > when booting with ACPI (or a modified QEMU mach-virt DT that claims
> > the UART is compatible with "arm,sbsa-uart"), as the problem is only
> > with the SBSA UART implementation, which doesn't toggle the enable bit
> > of the FIFO (UARTLCR_H.FEN) on startup/shutdown. When that bit is
> > toggled by the PL011 driver the QEMU PL011 model resets its read FIFO
> > and has no problem.
> 
> As mentioned above the UARTLCR register is not part of the SBSA spec -
> on purpose. The FIFO is always meant to be turned on.
> 
> > Patching the model to reset the read FIFO when UARTIMSC=0 and UARTICR
> > is being written as 0xffff, appears to resolve this issue, but it's a
> > hack.
> 
> I don't fully get why an always-on FIFO would create a problem. I guess
> this is due to the Linux PL011 driver way of getting things going, which
> had issues with initial FIFO triggering the in past. I think Dave tried
> hard to find a way to make it work with the SBSA - please don't tell us
> now that this one has issues as well ;-)
> 
> Just checking: Is it possible that the QEMU model does not do the full
> initialization that the SBSA UART requires? I guess it does (since you
> said that it works initially, but breaks later on), but it could be
> worth to check.

Just to make sure it does, I added code to the PL011 model's init

 LCR_H |= 0x70 // WLEN=3, FEN=1
 CR |= 0x301   // RXE|TXE|UARTEN

and modified mach-virt's DT, added "arm,sbsa-uart", allowing me to
take AAVMF out of the boot. But the bug persists.

Thanks,
drew