On 19.01.21 09:30, Ard Biesheuvel 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.
In U-Boot you can use the serial console and keyboard/video in parallel.
It is not defined how we should decide which of the consoles shall be
used for the Linux kernel messages and rescue console.
Even if you detect a monitor via the EDID I2C interface you would not be
able to tell if the user is sitting in front of the system or remote
controlling via the serial port.
Furthermore GRUB interferes with the console. I had to set
GRUB_TERMINAL_OUTPUT="console"
to get serial output on a system without a monitor attached.
Best regards
Heinrich
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
