Hi Bin, On Mon, 20 Mar 2023 at 20:56, Bin Meng <bmeng...@gmail.com> wrote: > > +Andy > > Hi Simon, > > On Tue, Feb 21, 2023 at 3:49 AM Simon Glass <s...@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 <s...@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