+Andy Hi Simon,
On Tue, Feb 21, 2023 at 3:49 AM Simon Glass <[email protected]> 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@changeid/ > > Signed-off-by: Simon Glass <[email protected]> > --- > > 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." So maybe somehow we should parse the SPCR ACPI table instead? Regards, Bin
