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.

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.

really check the device node type. Free unused devpaths by calling
efi_close_devpath().

need to handle usb luns

left over debug printf.

Seems ok.
Note, the issue about the staging size is not really if we can or can not allocate specific size, but if we have enough target space to copy it. I have starting to port other change (https://reviews.freebsd.org/D22309), the idea there is that we should determine if the target location has enough space. The bios version is simple as there we own the memory and we can not load directly to target address, in UEFI case we need to allocate, load and after switching off the BS, only then we can copy.

Wrong place for efi_devpath_trim.
No need to walk partitions in efipart_find_parent.
No need for local variable.

In D20562#484088, @danfe wrote:

@tsoome wrote:

Hope this helps.

It does, thanks! However, I'm still not sure if I need to create startup.nsh or not. Quick googling suggests that one might get boot problems in some environments if this file is missing. Wiki page does not mention it.

In D20562#484086, @danfe wrote:

I've stumbled upon this just few days ago when make delete-old suggested to remove the old trusty /boot/boot1.efifat (which I had to refuse). I know this differential is closed, but I have some questions and don't want to spam the mailing lists.

@imp wrote:

I'd like to see this die in fire.

My I ask what's wrong with it? I've been dding this image to my p1 ever since I had switched to GPT/UEFI on my drives, and it always worked just fine.

In D22139#483935, @imp wrote:

In D22139#483929, @tsoome 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.

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)

In D22037#481405, @delphij wrote:

I like the direction in general.
By the way, (unrelated to this change itself), have you considered updating lz4 code with the upstream ( https://github.com/lz4/lz4 )? I'm mostly concerned about getting more diverged from the upstream would make it harder for us to re-sync the code in the future, especially when we have already missed some of the optimization that happened upstream. There are also some other interesting changes upstream, for example, it used a set of macros to avoid downstream consumers to make changes like #ifdef _KERNEL in the code that would spread all over places, and that would make it easier for future upgrade too.
The change looks good to me as-is, but please consider these comments.

update the header for lz4.h, rebase on latest current.

In D21733#475785, @imp wrote:

In D21733#475782, @ryan_freqlabs.com wrote:

while we've transitioned to teken, it looks like it eats the ESC c

Ok, that looks pretty tough to deal with. Now that you mention it, I'm not seeing colors on the EFI serial console either, and under bhyve the scroll region is broken after the loader hands off to the kernel as well. It's everything I wanted to fix, still broken! Ugh! I thought I had tested that, but I guess I only tested a video output with the EFI console.

It is the most maddening part to get right... It's why I never upstreamed my hacks that I knew didn't work.

One way of dealing with this could be to add a variable to bypass teken for users of serial EFI consoles. A more challenging but perhaps more flexible option would be to implement a driver for the EFI serial protocol and either expose it as something like "efiserial" console or maybe add special handling to the existing EFI console driver to duplicate ANSI sequences to the serial port.

I actually think that's quite hard and involved. The current code doesn't differentiate, unfortunately. It would take a little while to understand a good path forward. At the moment, I see parsing ConOut, looking up handles and using that in something complicated, but there may be something simpler...

I don't think solving that problem with the EFI console/teken is within the scope of this change, though I am certainly hoping it gets fixed. I've only learned of teken's existence a few days ago. Can someone more familiar with that piece provide their input on the issue?

This can really only work for comconsole. And even there it can only be imperfect. And people will complain and expect me to fix it, so I'm reluctant to sign off until we have a better notion of a path forward...

In D21733#474205, @kevans wrote:

Hmm... on second thought, this might need tested with a black-on-white xterm. I seem to recall having to spit out color.default() because we couldn't cope with the different background color and kept screwing up @emaste's xterm. I'm assuming this will put us back into that state, and we'll need to have the color.default() back after the reset.