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.