Fix ia64 build failures in EFI platform

The MFC of the recent EFI work to stable/10 caused build breakage
under ia64.

It was not apparent that there was EFI code outside the EFI tree as
this is not the case in HEAD, however in stable/10 there is for ia64.

This change does the following:
* Re-enables libefi for ia64 under gcc.
* Adds the ignore for unsupported pragma's when building libefi for ia64.
* Adds the missing parameter to efi_handle_lookup in the ia64 loader.

This is a direct commit as ia64 is no longer supported after 10.x

Approved by: re (marius)
Sponsored by: Multiplay

MFC r281169, r293724, r293796, r294029, r294041, r294058

MFC r281169 (by andrew):
Make global variabled only used in this file static

MFC r294058:
Make common boot file_loadraw name parameter const

MFC r294041:
Remove unused reg param from fdt_fixup_memory

MFC r293724:
Enable warnings in EFI boot code

MFC r293796:
Fix typo in libefi.c

MFC r294029:
Only build EFI components on supported compilers

Sponsored by: Multiplay

MFC r293233: loader.efi: add terminal emulation support

This is based on the vidconsole implementation.

Submitted by: Toomas Soome <tsoome@me.com>
Relnotes: Yes

MFC r281524 by andrew@: Use MACHINE in the efi loader when it is what we mean

It may not be the same as MACHINE_CPUARCH, it just happened to be the
case the architectures this code currently supports.

Fixes build failure reported by Oliver Pinter.

MFC r280047: build x86-specific files in amd64 loader.efi

This was originally done for the arm and arm64 loader.efi and is MFC'd
here to ease future UEFI loader MFCs.

Sponsored by: The FreeBSD Foundation

MFC 279949:
The System V ABI for amd64 allows functions to use space in a 128 byte
redzone below the stack pointer for scratch space and requires
interrupt and signal frames to avoid overwriting it. However, EFI uses
the Windows ABI which does not support this. As a result, interrupt
handlers in EFI push their interrupt frames directly on top of the
stack pointer. If the compiler used the red zone in a function in the
EFI loader, then a device interrupt that occurred while that function
was running could trash its local variables. In practice this happens
fairly reliable when using gzipfs as an interrupt during decompression
can trash the local variables in the inflate_table() function
resulting in corrupted output or hangs.

Fix this by disabling the redzone for amd64 EFI binaries. This
requires building not only the loader but any libraries used by the
loader without redzone support.

Thanks to Jilles for pointing me at the redzone once I found the stack
corruption.

MFC r271475 by ambrisko:

Add support for serial and null console to UEFI boot loader.

Approved by: re

MFC UEFI loader

This MFC consists of the following SVN revisions:
258741 261568 261603 261668 263115 263117 263968 264078 264087 264088
264092 264095 264115 264132 264208 264261 264262 264263 264319 265028
265057 268974

Detailed commit messages:

r258741: Note that libstand is 32-bit on amd64 and powerpc64

r261568: Build libstand as a 64-bit library on amd64

The 32-bit bootloaders now link against libstand.a in
sys/boot/libstand32, so there is no need to force /usr/lib/libstand.a
to be 32-bit.

r261603: Don't force efi to a 32-bit build on amd64

r261668: Build libstand as a 64-bit library on ppc64

The 32-bit bootloaders now link against libstand.a in
sys/boot/libstand32, so there is no need to force /usr/lib/libstand.a
to be 32-bit.

This is equivalent to r261568 for amd64.

r263115: Add amd64 EFI headers

r263117: Connect 64-bit boot ficl to the build

It is not yet used, but this will ensure it doesn't get broken.

r263968: Use EFI types for EFI values (silences warnings).

EFI UINTN is actually a 64-bit type on 64-bit processors.

r264078: Put each source file on a separate line

This will simplify rebasing the amd64 UEFI patch set.

r264087: Build boot/ficl as 64-bit library on amd64

The 32-bit bootloaders on amd64 now use the 32-bit version in ficl32,
as is done with libstand32. The native 64-bit ficl will be used by the
upcoming UEFI loader.

r264088: Merge efilib changes from projects/uefi

r247216: Add the ability for a device to have an "alias" handle.

r247379: Fix network device registration.

r247380: Adjust our load device when we boot from CD under UEFI.

The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points
at the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition".
The existing EFI partition code only looks for logical partitions and
so the CD filesystem was rendered invisible.

To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.

Something similar to this will be required for booting from other media
as well as the loader will live in the EFI system partition, not on the
partition containing the kernel.

r247381: Remove a scatalogical debug printf that crept in.

r264092: Add -fPIC for amd64

r264095: Support UEFI booting on amd64 via loader.efi

This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.

Specific revisions of note from projects/uefi:

r247380:

Adjust our load device when we boot from CD under UEFI.

The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.

To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.

Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.

r246231:

Add necessary code to hand off from loader to an amd64 kernel.

r246335:

Grab the EFI memory map and store it as module metadata on the kernel.

This is the same approach used to provide the BIOS SMAP to the kernel.

r246336:

Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.

r246608:

Rework copy routines to ensure we always use memory allocated via EFI.

The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.

r247214:

Fix a number of problems preventing proper handover to the kernel.

There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.

Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.

r246231:

Add necessary code to hand off from loader to an amd64 kernel.

r246335:

Grab the EFI memory map and store it as module metadata on the kernel.

This is the same approach used to provide the BIOS SMAP to the kernel.

r246336:

Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.

r246608:

Rework copy routines to ensure we always use memory allocated via EFI.

The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.

r247214:

Fix a number of problems preventing proper handover to the kernel.

There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.

Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.

r247216:

Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.

r264115: Fix printf format mismatches

r264132: Connect sys/boot/amd64 to the build

r264208: Do not build the amd64 UEFI loader with GCC

The UEFI loader causes buildworld to fail when building with (in-tree)
GCC, due to a typedef redefinition. As it happens the in-tree GCC
cannot successfully build the UEFI loader anyhow, as it does not support
__attribute__((ms_abi)). Thus, just avoid trying to build it with GCC,
rather than disconnecting it from the build until the underlying issue
is fixed.

r264261: Correct a variable's type for 64-bit Ficl

FICL_INT is long.

r264262: Fix printf args for 64-bit archs

r264263: Add explicit casts to quiet warnings in libefi

r264319: Fix EFI loader object tree creation on 9.x build hosts

Previously ${COMPILER_TYPE} was checked in sys/boot/amd64, and the efi
subdirectory was skipped altogether for gcc (since GCC does not support
a required attribute). However, during the early buildworld stages
${COMPILER_TYPE} is the existing system compiler (i.e., gcc on 9.x build
hosts), not the compiler that will eventually be used. This caused
"make obj" to skip the efi subdirectory. In later build stages
${COMPILER_TYPE} is "clang", and then the efi loader would attempt to
build in the source directory.

r265028 (dteske): Disable the beastie menu for EFI console ...

which doesn't support ANSI codes (so things like `at-xy', `clear', and
other commands don't work making it impossible to generate a living
menu).

r265057 (nwhitehorn): Turn off various fancy instruction sets...

as well as deduplicate some options. This makes the EFI loader build
work with CPUTYPE=native in make.conf on my Core i5.

r268974 (sbruno): Supress clang warning for FreeBSD printf %b and %D formats

Relnotes: Yes
Sponsored by: The FreeBSD Foundation

MFC 279949:
The System V ABI for amd64 allows functions to use space in a 128 byte
redzone below the stack pointer for scratch space and requires
interrupt and signal frames to avoid overwriting it. However, EFI uses
the Windows ABI which does not support this. As a result, interrupt
handlers in EFI push their interrupt frames directly on top of the
stack pointer. If the compiler used the red zone in a function in the
EFI loader, then a device interrupt that occurred while that function
was running could trash its local variables. In practice this happens
fairly reliable when using gzipfs as an interrupt during decompression
can trash the local variables in the inflate_table() function
resulting in corrupted output or hangs.

Fix this by disabling the redzone for amd64 EFI binaries. This
requires building not only the loader but any libraries used by the
loader without redzone support.

Thanks to Jilles for pointing me at the redzone once I found the stack
corruption.

MFC r271475 by ambrisko:

Add support for serial and null console to UEFI boot loader.

Approved by: re

MFC UEFI loader

This MFC consists of the following SVN revisions:
258741 261568 261603 261668 263115 263117 263968 264078 264087 264088
264092 264095 264115 264132 264208 264261 264262 264263 264319 265028
265057 268974

Detailed commit messages:

r258741: Note that libstand is 32-bit on amd64 and powerpc64

r261568: Build libstand as a 64-bit library on amd64

The 32-bit bootloaders now link against libstand.a in
sys/boot/libstand32, so there is no need to force /usr/lib/libstand.a
to be 32-bit.

r261603: Don't force efi to a 32-bit build on amd64

r261668: Build libstand as a 64-bit library on ppc64

The 32-bit bootloaders now link against libstand.a in
sys/boot/libstand32, so there is no need to force /usr/lib/libstand.a
to be 32-bit.

This is equivalent to r261568 for amd64.

r263115: Add amd64 EFI headers

r263117: Connect 64-bit boot ficl to the build

It is not yet used, but this will ensure it doesn't get broken.

r263968: Use EFI types for EFI values (silences warnings).

EFI UINTN is actually a 64-bit type on 64-bit processors.

r264078: Put each source file on a separate line

This will simplify rebasing the amd64 UEFI patch set.

r264087: Build boot/ficl as 64-bit library on amd64

The 32-bit bootloaders on amd64 now use the 32-bit version in ficl32,
as is done with libstand32. The native 64-bit ficl will be used by the
upcoming UEFI loader.

r264088: Merge efilib changes from projects/uefi

r247216: Add the ability for a device to have an "alias" handle.

r247379: Fix network device registration.

r247380: Adjust our load device when we boot from CD under UEFI.

The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points
at the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition".
The existing EFI partition code only looks for logical partitions and
so the CD filesystem was rendered invisible.

To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.

Something similar to this will be required for booting from other media
as well as the loader will live in the EFI system partition, not on the
partition containing the kernel.

r247381: Remove a scatalogical debug printf that crept in.

r264092: Add -fPIC for amd64

r264095: Support UEFI booting on amd64 via loader.efi

This is largely the work from the projects/uefi branch, with some
additional refinements. This is derived from (and replaces) the
original i386 efi implementation; i386 support will be restored later.

Specific revisions of note from projects/uefi:

r247380:

Adjust our load device when we boot from CD under UEFI.

The process for booting from a CD under UEFI involves adding a FAT
filesystem containing your loader code as an El Torito boot image.
When UEFI detects this, it provides a block IO instance that points at
the FAT filesystem as a child of the device that represents the CD
itself. The problem being that the CD device is flagged as a "raw
device" while the boot image is flagged as a "logical partition". The
existing EFI partition code only looks for logical partitions and so
the CD filesystem was rendered invisible.

To fix this, check the type of each block IO device. If it's found to
be a CD, and thus an El Torito boot image, look up its parent device
and add that instead so that the loader will then load the kernel from
the CD filesystem. This is done by using the handle for the boot
filesystem as an alias.

Something similar to this will be required for booting from other
media as well as the loader will live in the EFI system partition, not
on the partition containing the kernel.

r246231:

Add necessary code to hand off from loader to an amd64 kernel.

r246335:

Grab the EFI memory map and store it as module metadata on the kernel.

This is the same approach used to provide the BIOS SMAP to the kernel.

r246336:

Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.

r246608:

Rework copy routines to ensure we always use memory allocated via EFI.

The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.

r247214:

Fix a number of problems preventing proper handover to the kernel.

There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.

Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.

r246231:

Add necessary code to hand off from loader to an amd64 kernel.

r246335:

Grab the EFI memory map and store it as module metadata on the kernel.

This is the same approach used to provide the BIOS SMAP to the kernel.

r246336:

Pass the ACPI table metadata via hints so the kernel ACPI code can
find them.

r246608:

Rework copy routines to ensure we always use memory allocated via EFI.

The previous code assumed it could copy wherever it liked. This is not
the case. The approach taken by this code is pretty ham-fisted in that
it simply allocates a large (32MB) buffer area and stages into that,
then copies the whole area into place when it's time to execute. A more
elegant solution could be used but this works for now.

r247214:

Fix a number of problems preventing proper handover to the kernel.

There were two issues at play here. Firstly, there was nothing
preventing UEFI from placing the loader code above 1GB in RAM. This
meant that when we switched in the page tables the kernel expects to
be running on, we are suddenly unmapped and things no longer work. We
solve this by making our trampoline code not dependent on being at any
given position and simply copying it to a "safe" location before
calling it.

Secondly, UEFI could allocate our stack wherever it wants. As it
happened on my PC, that was right where I was copying the kernel to.
This did not cause happiness. The solution to this was to also switch
to a temporary stack in a safe location before performing the final
copy of the loaded kernel.

r247216:

Use the UEFI Graphics Output Protocol to get the parameters of the
framebuffer.

r264115: Fix printf format mismatches

r264132: Connect sys/boot/amd64 to the build

r264208: Do not build the amd64 UEFI loader with GCC

The UEFI loader causes buildworld to fail when building with (in-tree)
GCC, due to a typedef redefinition. As it happens the in-tree GCC
cannot successfully build the UEFI loader anyhow, as it does not support
__attribute__((ms_abi)). Thus, just avoid trying to build it with GCC,
rather than disconnecting it from the build until the underlying issue
is fixed.

r264261: Correct a variable's type for 64-bit Ficl

FICL_INT is long.

r264262: Fix printf args for 64-bit archs

r264263: Add explicit casts to quiet warnings in libefi

r264319: Fix EFI loader object tree creation on 9.x build hosts

Previously ${COMPILER_TYPE} was checked in sys/boot/amd64, and the efi
subdirectory was skipped altogether for gcc (since GCC does not support
a required attribute). However, during the early buildworld stages
${COMPILER_TYPE} is the existing system compiler (i.e., gcc on 9.x build
hosts), not the compiler that will eventually be used. This caused
"make obj" to skip the efi subdirectory. In later build stages
${COMPILER_TYPE} is "clang", and then the efi loader would attempt to
build in the source directory.

r265028 (dteske): Disable the beastie menu for EFI console ...

which doesn't support ANSI codes (so things like `at-xy', `clear', and
other commands don't work making it impossible to generate a living
menu).

r265057 (nwhitehorn): Turn off various fancy instruction sets...

as well as deduplicate some options. This makes the EFI loader build
work with CPUTYPE=native in make.conf on my Core i5.

r268974 (sbruno): Supress clang warning for FreeBSD printf %b and %D formats

Relnotes: Yes
Sponsored by: The FreeBSD Foundation