[PATCH] video: fix no display when serial console is disabled

[Simon Glass]

Hi Desapogu,

On 2026-06-03T13:29:53, Desapogu Jayaramudu <jayaramudu.desapogu at amd.com> wrote:
> video: fix no display when serial console is disabled
>
> When the serial console is disabled in coreboot configuration,
> no display output is observed during boot.
>
> This happens because DBG2 (Debug Port 2 table) configuration
> is required for proper UART initialization and affects the
> video initialization path.
>
> Fix this by ensuring DBG2 is correctly configured as a
> 16550-compatible UART, allowing video initialization to
> proceed independently of serial console settings.
>
> Signed-off-by: Desapogu Jayaramudu <jayaramudu.desapogu at amd.com>
>
> include/acpi/acpi_table.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Thanks for looking at this!

The commit message does not match the change. DBG2 is an ACPI table
produced by coreboot and consumed by U-Boot only as a fallback in
read_dbg2() when lib_sysinfo.serial is NULL; it is not on the video
init path. Please describe what actually happens. I suspect that when
the coreboot serial console is disabled, coreboot emits a DBG2 with
port_subtype 0x0012 (16550 with parameters defined in the GAS), the
check in serial_coreboot.c rejects it, the UART is not detected, and
that somehow prevents the video console from coming up. Please
describe the real chain of events and the observed symptom.

> diff --git a/include/acpi/acpi_table.h b/include/acpi/acpi_table.h
> @@ -667,7 +667,7 @@ struct __packed acpi_dmar {
>
>  /* Subtypes for port_subtype field */
>
> -#define ACPI_DBG2_16550_COMPATIBLE   0x0000
> +#define ACPI_DBG2_16550_COMPATIBLE   0x0012

Not quite. Per the Microsoft DBG2 specification (and Linux's
acpi/actbl1.h), 0x0000 is "Fully 16550-compatible" and 0x0012 is
"16550-compatible with parameters defined in the Generic Address
Structure", i.e. two distinct subtypes. Redefining the existing macro
silently changes the value written out by acpi_create_dbg2() in
lib/acpi/acpi_table.c and by spcr->interface_type in
acpi_write_spcr(), so every board that emits these tables now
advertises the wrong subtype to the OS.

Please leave ACPI_DBG2_16550_COMPATIBLE = 0x0000, add a new macro
(e.g. ACPI_DBG2_16550_GAS = 0x0012), and fix the real problem in
drivers/serial/serial_coreboot.c by accepting both subtypes:

    if (dbg->port_subtype != ACPI_DBG2_16550_COMPATIBLE &&
        dbg->port_subtype != ACPI_DBG2_16550_GAS) {

That way the coreboot fallback works whichever subtype coreboot emits,
and the tables U-Boot writes remain correct.

Please also include the coreboot output showing the actual
port_subtype in your DBG2 (a hex dump, or the log_debug from
read_dbg2()) so the reasoning is verifiable.

Also you might look at this series where I had a similar problem:

https://patchwork.ozlabs.org/project/uboot/list/?series=433605&state=*

IMO coreboot should provide the serial details regardless of whether
the console is enabled, but I was unable to get that change in, so
your approach is the best.

Also let me know if you are working with OpenSIL. I would be great to
see a coreboot + OpenSIL + U-Boot combination.

Regards,
Simon