search

ARM-software / ebbr

Embedded Base Boot Requirements Specification
Creative Commons Attribution Share Alike 4.0 International
115 stars 37 forks source link

EBBR provisions for UART console #70

Closed fozog closed 1 year ago

fozog commented 3 years ago

Intent

When a system uses an UART for console, hardware description must unambiguously designate such a device so that an Operating System can use it without requiring a manual configuration.

Specification update

/ this is only a discussion to conclude on outline changes, and give hints on the contents / The 2.4.2 is specifying how tables (GUID, memory attributes...) are passed. As there may be more than stdout-path considerations for the hardware description tables,I would favor addition of a 2.4.3 configuration table requirements. 2.4.3.1 UART console / only the Linux documentation refers to stdout-path, we should elevate this to any OS by inclusion in EBBR /

2.4.3.1.1 Device Tree based systems stdout-path, as defined in the Linux kernel documentation must be present and allow the OS to operate the UART.

2.4.3.1.2 ACPI based systems There is apparently no standard mechanism for that. SPCR table may be an actual solution. Alternatively, a standard object such as _SB_.COM0 could be given the the same semantics as DT stdout-path.

hrw commented 3 years ago

iirc SPCR is now used on many platforms to show which serial post is console one.

samerhaj commented 3 years ago

Agree for ACPI SPCR is the standard solution to describe the console. This has been an SBBR requirement for a long time. Using an _SB.COM0 object to "look like a DT stdout-path" is not preferred.

kettenis commented 3 years ago

Interesting discussion. OpenBSD uses stdout-path on systems that use the DT and SPCR on systems that use ACPI.

The problem with ACPI SPCR is that the on many systems that table is present even if a framebuffer console is in use. On arm64 systems, OpenBSD will use a serial console by default if SPCR is present, but on amd64 systems we don't since a lot of users of x86 server hardware would be unhappy with that choice as KVM switches are very popular in that space.

In theory the ConIn and ConOut EFI variables could/should be used. These variables are supposed to specify a device path for the default console input and output device. In practice that doesn't seem to work since:

Personally I've always liked the behaviour that Sun workstation implemented. If you plugged in a keyboard, it would default to using the framebuffer console. If no keyboard was plugged in, it would use the default serial console. There were OpenFirmware nvram variables that could be used to override this behaviour, or at least force the use of the serial console even if you plugged in a keyboard. I tried to implement this in the OpenBSD bootloader, but I couldn't find a way to detect the actual presence of a keyboard using standard EFI protocol interfaces.

vstehle commented 1 year ago

Devicetree requirements should be sufficient for console after https://github.com/ARM-software/ebbr/commit/685aae26d583a214b4425956eb7c5e7baf2c398b.