[PATCH 06/13] x86: Allow locating UARTs by device ID
bmeng.cn at gmail.com
Mon Mar 20 08:56:06 CET 2023
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: 
>  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."
So maybe somehow we should parse the SPCR ACPI table instead?
More information about the U-Boot