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