Page MenuHomeFreeBSD

loader.efi: implement comconsole with UEFI SerialIO protocol
Needs ReviewPublic

Authored by tsoome on Oct 24 2019, 8:16 AM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 23 2024, 12:14 PM
Unknown Object (File)
Feb 8 2024, 10:52 PM
Unknown Object (File)
Jan 10 2024, 1:44 AM
Unknown Object (File)
Nov 25 2023, 11:02 AM
Unknown Object (File)
Nov 22 2023, 11:50 PM
Unknown Object (File)
Nov 22 2023, 3:08 PM
Unknown Object (File)
Nov 13 2023, 7:18 PM
Unknown Object (File)
Nov 12 2023, 1:21 PM

Details

Reviewers
imp
Test Plan

set console=comconsole in loader

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 28004
Build 26163: arc lint + arc unit

Event Timeline

I'll take a look at this... It looks OK.

But, the "port" changes from the I/O port to the UID if I'm reading things right, which is effectively a random number (on a machine it's stable, but it varies from machine to machine)

stand/efi/loader/conf.c
84–85

This is a flag-day kind of change, so I'd recommend a different name. We already have comconsole configured one way and this would make it configured a different way.

In D22139#483902, @imp wrote:

I'll take a look at this... It looks OK.

But, the "port" changes from the I/O port to the UID if I'm reading things right, which is effectively a random number (on a machine it's stable, but it varies from machine to machine)

Are you sure it is random?, because we found out the handle order is not fixed and acpi uid seems to give better results - haven't heard unexpected port order so far.

In D22139#483902, @imp wrote:

I'll take a look at this... It looks OK.

But, the "port" changes from the I/O port to the UID if I'm reading things right, which is effectively a random number (on a machine it's stable, but it varies from machine to machine)

Are you sure it is random?, because we found out the handle order is not fixed and acpi uid seems to give better results - haven't heard unexpected port order so far.

For any given machine, the numbers are fixed, per the ACPI standard (they require the UID numbers to be stable, modulo config changes). However, UID 0 might be COM1 on some systems and COM3 on others depending on the make and model of the motherboard and sometimes the BIOS settings on it. Hence my characterization of it being 'random'. while these numbers can be obtained from devinfo -v, they aren't as 'fixed' as the IOPORT value which is always fixed for COM1 at 0x3f8.

So for my supermicro X9 system, UID1 is COM1. But on the X10 system UID0 is COM1. I have another system that UID0 is COM2 and UID1 is COM1, I think, but can't access it to confirm. This makes it hard to write docs to tell people how to configure it. That's where I'm headed with these comments here.

In D22139#483935, @imp wrote:
In D22139#483902, @imp wrote:

I'll take a look at this... It looks OK.

But, the "port" changes from the I/O port to the UID if I'm reading things right, which is effectively a random number (on a machine it's stable, but it varies from machine to machine)

Are you sure it is random?, because we found out the handle order is not fixed and acpi uid seems to give better results - haven't heard unexpected port order so far.

For any given machine, the numbers are fixed, per the ACPI standard (they require the UID numbers to be stable, modulo config changes). However, UID 0 might be COM1 on some systems and COM3 on others depending on the make and model of the motherboard and sometimes the BIOS settings on it. Hence my characterization of it being 'random'. while these numbers can be obtained from devinfo -v, they aren't as 'fixed' as the IOPORT value which is always fixed for COM1 at 0x3f8.

So for my supermicro X9 system, UID1 is COM1. But on the X10 system UID0 is COM1. I have another system that UID0 is COM2 and UID1 is COM1, I think, but can't access it to confirm. This makes it hard to write docs to tell people how to configure it. That's where I'm headed with these comments here.

ok, that is simple then - we need array of uids and we index that array:) this way we have 0 for first port. Thanks for bringing this to my attention!

Rename comconsole.c to efiserialio.c to avoid issues with libi386/comconsole.c.
On x86, use libi386/comconsole because we still can not ensure the proper order
of serial ports and there is known issue on some systems with input on serial.

Enable comconsole (based on SIO) for arm.

Would it be possible to also support memory-mapped UART this way? Intel >=Skylake and all aarch64 systems use mmio.

I've added an SPCR table to my Kaby Lake laptop to configure the UART, but it would be nice if it could auto configure without SPCR.

In D22139#496705, @greg_unrelenting.technology wrote:

Would it be possible to also support memory-mapped UART this way? Intel >=Skylake and all aarch64 systems use mmio.

I've added an SPCR table to my Kaby Lake laptop to configure the UART, but it would be nice if it could auto configure without SPCR.

Assuming the SIO does provide the handle, yes. There is still the issue that we would need to be able to have proper device <-> handle mapping. For time being, the one possible thing we can do is to add pluggable interface for console, so we could replace console module with alternate one.

Looks like this has been committed as ebe8cd79d29ee6788396d1fa84d9d566945544bf — someone forgot the Differential Revision: thing ;)