Post #1539647

2026-04-01 15:52 UTC

@daandemeyer how does that work with the /chosen/stdout-path semantics already in place in the kernel for DT platforms? This may be a simplefb node, or a serial device. https://github.com/torvalds/linux/blob/9147566d801602c9e7fc7f85e989735735bf38ba/Documentation/devicetree/bindings/display/simple-framebuffer.yaml#L41https://github.com/torvalds/linux/blob/9147566d801602c9e7fc7f85e989735735bf38ba/Documentation/admin-guide/kernel-parameters.txt#L1431-L1432

Replies (1)

@samueldr@ap.samueldr.com 2026-04-01 15:52

@daandemeyer Correct my if I'm missing something, but AFAICT the detection for serial output first relies on the EFI_SERIAL_IO_PROTOCOL count, which means that it will only count serial consoles exposed for I/O by the EFI runtime. The available serial devices may not all necessarily be exposed "faithfully" as I/O. First situation is the protcol not being implemented, or having no serial I/O devices exposed... That specific situation is fine as that will fallback to the existing kernel semantics. Where it's not fine is if a single serial I/O device is exposed, and that device is either not the correct device index (0), or not the correct hardcoded device type (i.e. on ARM ttyAMA0). For ARM, the device (ttyAMA0) is a very arbitrary decision that will only be true on systems that use the PL011 peripheral for their "debugging" console. Otherwise this AFAICT fails if for example ttyS2 is the debugging console, but the EFI_SERIAL_IO_PROTOCOL exposes only a single I/O device.

Open ##1539648