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