set console=comconsole in loader
Details
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. |
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.
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 ;)