[PATCH 06/13] x86: Allow locating UARTs by device ID

[Simon Glass]

Hi Bin,

On Mon, 20 Mar 2023 at 20:56, Bin Meng <bmeng.cn at gmail.com> wrote:
>
> +Andy
>
> Hi Simon,
>
> On Tue, Feb 21, 2023 at 3:49 AM Simon Glass <sjg at chromium.org> wrote:
> >
> > When coreboot does not pass a UART in its sysinfo struct, there is no
> > easy way to find it out. Add a way to specify known UARTs so we can
> > find them without needing help from coreboot.
> >
> > Since coreboot does not actually init the serial device when serial is
> > disabled, it is not possible to make it add this information to the
> > sysinfo table.
> >
> > Also, we cannot use the class information, since we don't know which
> > UART is being used. For example, with Alder Lake there are two:
> >
> > 00.16.00   0x8086     0x51e0     Simple comm. controller 0x80
> > 00.1e.00   0x8086     0x51a8     Simple comm. controller 0x80
> >
> > In our case the second one is the right one, but thre is no way to
> > distinguish it from the first one without using the device ID.
> >
> > If we have Adler Lake hardware which uses a different UART, we could
> > perhaps look at the ACPI tables, or the machine information passed in
> > the SMBIOS tables.
> >
> > This was discussed previously before: [1]
> >
> > [1] https://patchwork.ozlabs.org/project/uboot/patch/
> >   20210407163159.3.I967ea8c85e009f870c7aa944372d32c990f1b14a at changeid/
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> > ---
> >
> >  arch/x86/dts/coreboot.dts        |  4 ++
> >  drivers/serial/serial_coreboot.c | 69 ++++++++++++++++++++++++++++----
> >  include/pci_ids.h                |  3 ++
> >  3 files changed, 68 insertions(+), 8 deletions(-)
> >
>
> Last time we discussed this, both Andy and I thought this was a hack.
> I cited Andy's point below:
>
> "What coreboot should do is either provide serial information or SPCR
> ACPI table. Otherwise if it does not provide it, I think it's on
> purpose, and we have to respect this."

We cannot change what coreboot does. I have written up a design for it
but it seems unlikely that anything will happen there in the short
term, perhaps ever. I will keep pushing.

In the meantime U-Boot cannot be used as a coreboot payload in this
(common) situation. So we do need a solution.

>
> So maybe somehow we should parse the SPCR ACPI table instead?

I don't see that table present, but there is DBG2 so I will take a look.

Regards,
Simon