Hi So we need another issue in the EBBR tracker:
console guidance (serial or graphical) from firmware to OS in both DT and ACPI. The firmware may use programatic or runtime advanced techniques such as HDMI monitor presence and use a "to be specified" method to signal the right selection. When it comes to the issue I added, we can say it is targeted at system that we know in advance the console is on serial. so with DT:/chosen/stdout-path and ACPI:/SPCR (without AML interpreter) we have simple ways to detect the device to use. Is it a safe first step to add to EBBR ? Cheers FF On Tue, 19 Jan 2021 at 09:30, Ard Biesheuvel <a...@kernel.org> wrote: > On Tue, 19 Jan 2021 at 05:54, Dong Wei <dong....@arm.com> wrote: > > > > There is also the SPCR table > https://docs.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table?redirectedfrom=MSDN > > This is the primary serial console > > > > One of the issues we still have not fixed in Linux is the > inconsistency in interpretation of what 'serial console' actually > means. > > On Windows, the serial console is a low-level admin interface that may > be exposed in addition to the full blown graphical user interface, > which is always available. The SPCR describes how this admin interface > is exposed, but does not affect what happens on the GUI. > > In Linux, the console *is* the primary interface, either graphical or > serial. Currently, the mere presence of a SPCR is taken as an > indication that only the serial console should be enabled; for this > reason, the UEFI ports we have for platforms with PCIe expansion carry > a driver that removes the SPCR again if UEFI detects the presence of a > graphical interface. > > Unfortunately, this is not something we can easily change without > breaking existing systems. Note that annotating device objects in the > DSDT is probably not the right approach here, given that this requires > the AML interpreter to be up and running before we can decide where > the console lives. > > As Heinrich points out, we have a similar problem today when it comes > to the graphical interface on DT systems, i.e., it is not clear how to > convey that the user expects the interaction with the system to occur > via the graphical UI and not via a serial port. For a bootloader such > as u-boot, it should be fairly easy to suppress the stdout-path if > u-boot itself is running on the graphical display, but it would be > better to communicate the presence of this GUI *in addition to* a > serial port serving as a console. > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
