[coreboot] Servo debug uart in Linux?

[Duncan Laurie]

On Thu, Oct 6, 2016 at 11:08 AM, Duncan Laurie <dlaurie at chromium.org> wrote:

> On Thu, Oct 6, 2016 at 10:56 AM, Trammell Hudson <hudson at trmm.net> wrote:
>
>> Is it possible to use the Skylake Servo debug UART in Linux or Xen?
>> It doesn't show up as a normal 16550 (setserial reports "uart type
>> unknown"), which is making debugging the payload kernel a little
>> frustrating.
>>
>> I've added lots of "outb $0x80" calls to trace the Xen hypervisor and
>> have figured out that the Skylake doesn't work with the x2apic, the xsave
>> instruction or the MCE handler, but would prefer a higher bandwidth way
>> to report progress/errors.
>>
>>
> The debug UART on Skylake is 32bit MMIO based, so it does not work with
> most existing serial drivers.  It should work in recent Linux kernels and
> come up as ttyS2, but you can also force it with earlyprintk using the
> 'mmio32' directive and the base address.
>
>

I may be mis-remembering and this might come up as ttyS0 in linux for
skylake.  (it is ttyS2 on apollolake...)  Or just use a custom command line
like console=uart,mmio32,0xd1134000,115200n8

-duncan




> The device can be put into 16550/8-bit compatible mode, there is some code
> to do this on broadwell at soc/intel/skylake/broadwell/romstage/uart.c
> but on Skylake we left it in 32bit mode as putting it in compatible mode
> made it unable to suspend properly.
>
> I *think* for skylake you can set the device PchSerialIoIndexUart2 to
> PchSerialIoLegacyUart (in devicetree.cb) and FSP will configure it for
> 16500 byte mode.  You will then need to update coreboot to use the uart in
> 8-bit mode instead of 32bit mode.
>
> That still leaves the issue that it is mmio based and not IO based, so it
> will still have a hard time in things like seabios.  However I think Xen
> does support MMIO UART so it might work there...
>
> -duncan
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20161006/552d43f5/attachment.html>