Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1453193 > unrolled thread

SBSA UART bug report and questions

Back to article view | Back to linux.kernel

Contents

  SBSA UART bug report and questions Andrew Jones <drjones@redhat.com> - 2016-08-01 15:00 +0200
    Re: SBSA UART bug report and questions Andre Przywara <andre.przywara@arm.com> - 2016-08-01 15:30 +0200
      Re: SBSA UART bug report and questions Andrew Jones <drjones@redhat.com> - 2016-08-01 15:50 +0200

#1453193 — SBSA UART bug report and questions

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.

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 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.

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.

Please let me know your thoughts on this.

Thanks,
drew

[toc] | [next] | [standalone]

#1453210

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.

Cheers,
Andre.

[toc] | [prev] | [next] | [standalone]

#1453218

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web