Post #1539648
2026-04-01 15:52 UTC
@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.
Replies (1)
-
@samueldr@ap.samueldr.com 2026-04-01 15:52
@daandemeyer I'm also wondering how this ends-up working with non-headless systems where either there is no GOP in the EFI implementation, or where simple-framebuffer is being handed down to the kernel, but without the actual GOP protocol being available... If the desired outcome is that "when the kernel can output to the display, put the console on the display", this implementation may pick serial while the kernel would have previously used the display.