MFC r321305:

Fix printf format warning in zfs_module.c

Clang 5.0.0 got better warnings about print format strings using %zd,
and this leads to the following -Werror warning on e.g. arm:

sys/boot/efi/boot1/zfs_module.c:186:18: error: format specifies type 'ssize_t' (aka 'int') but the argument has type 'off_t' (aka 'long long') [-Werror,-Wformat]
"(%lu)\n", st.st_size, spa->spa_name, filepath, EFI_ERROR_CODE(status));
^~~~~~~~~~

Fix this by casting off_t arguments to intmax_t, and using %jd instead.

Reviewed by: tsoome
Differential Revision: https://reviews.freebsd.org/D11678

MFC r309412,r316109,r316132:

r309412 (by imp):

dd is currently a bootstrap tool. It really doesn't have any business
being a bootstrap tool. However, for reproducible build output,
FreeBSD added dd status=none because it was otherwise difficult to
suppress the status information, but retain any errors that might
happen. There's no real reason that dd has to be a build tool, other
than we use status=none unconditional. Remove dd from a bootstrap tool
entirely by only using status=none when available. This may also help
efforts to build the system on non-FreeBSD hosts as well.

r316109:

Don't hardcode input files for stage 1/2 bootloaders; use .ALLSRC instead

This is a better pattern to follow when creating the bootloaders and doing
the relevant space checks to make sure that the sizes aren't exceeded (and
thus, copy-pasting is a bit less error prone).

r316132:

Parameterize out 7680 (15 * 512) as BOOT2SIZE, similar to sys/boot/i386/zfsboot/...

This is being done to make it easier to change in the future--this action might be
needed sooner rather than later because of gcc 6.3.0 bailing, stating that there
is negative free space left (deficit) in the boot2 bootloader.

MFC r316103:

Remove redundant declarations

They're already defined in libstand.h

MFC: 314547, 314770, 314828, 314891, 314956, 314962, 315235

r314547
loader.efi: reduce the size of the staging area if necessary

The loader assumes physical memory in [2MB, 2MB + EFI_STAGING_SIZE)
is Conventional Memory, but actually it may not, e.g. in the case
of Hyper-V Generation-2 VM (i.e. UEFI VM) running on Windows
Server 2012 R2 host, there is a BootServiceData memory block at
the address 47.449MB and the memory is not writable.

Without the patch, the loader will crash in efi_copy_finish():
see PR 211746.

The patch verifies the end of the staging area, and reduces its
size if necessary. This way, the loader will not try to write into
the BootServiceData memory any longer.

Thank Marcel Moolenaar for helping me on this issue!

The patch also allocates the staging area in the first 1GB memory.
See the comment in the patch for this.

Reviewed by: marcel, kib, sephe
Approved by: sephe (mentor)
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D9686

r314770
loader.efi: fix recent UEFI-boot regression on physical machines

This patch fixes my recent patch
"loader.efi: reduce the size of the staging area if necessary", which
causes EFI-boot failure on physical machines since Mar 2:
on the host there is a 1MB LoaderData memory range, which splits
the big Conventional Memory range into a small one (15MB) and a
big one: the small one is too small to hold the staging area.

We can actually use the LoaderData range safely, because when
amd64_tramp -> efi_copy_finish() starts to run, we're almost at
the very end of the efi loader code and we're going to "return"
to the kernel entry, so we're pretty sure we won't access any loader
data any more.

For people who are interested in the details: please see
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746#c22

PS, some people also reported the regression happened to FreeBSD VM
running on Bhyve in EFI mode. This patch should resolve it too,
though I don't have such a setup to test.

Reviewed by: sephe
Approved by: sephe (mentor)
Sponsored by: Microsoft
Differential Revision: https://reviews.freebsd.org/D9904

r314828
loader.efi: fix an off-by-one bug in efi_verify_staging_size()

Also remove the warning message: it may not be unusual to see
the memory range containing 2MB is not of EfiConventionalMemory.

Sponsored by: Microsoft

r314891
loader.efi: finally fix the off-by-one bug in efi_verify_staging_size()

r314828(loader.efi: fix an off-by-one bug in efi_verify_staging_size())
doesn't really fix the bug and this patch adds the missing part.

It's a shame that I didn't make everything correct at the very beginning...

Sponsored by: Microsoft

r314956
loader.efi: only reduce the size of the staging area on Hyper-V

Doing this on physical hosts turns out to be problematic, e.g. see comment
24 and 28 in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211746.

To fix the real underlying issue correctly & thoroughly, IMO we need
a relocatable kernel, but that would require a lot of complicated long
term work: https://reviews.freebsd.org/D9686?id=25414#inline-56969

For now, let's only apply efi_verify_staging_size() to VMs running on
Hyper-V, and restore the old behavior on physical machines since that
has been working for people for a long period of time, though that's
potentially unsafe...

Sponsored by: Microsoft

r314962
loader.efi: only include the machine/ header files on x86

The 2 files may not exist on other archs like aarch64 and hence we
can have a build failure there.

Reported by: lwhsu
Sponsored by: Microsoft

r315235
loader.efi: use stricter check for Hyper-V

Some other hypervisors like Xen can pretend to be Hyper-V but obviously
they can't implement all Hyper-V features. Let's make sure we're genuine
Hyper-V here.

Also fix some minor coding style issues.

Sponsored by: Microsoft

PR: 211746

MFC r311933:

Use proper prototypes in struct boot_module_t

With clang 4.0.0, we are getting the following warnings about struct
boot_module_t in efi's boot_module.h:

In file included from sys/boot/efi/boot1/ufs_module.c:41:
sys/boot/efi/boot1/boot_module.h:67:14: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes]
void (*init)();
^
void
sys/boot/efi/boot1/boot_module.h:92:16: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes]
void (*status)();
^
void
sys/boot/efi/boot1/boot_module.h:95:24: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes]
dev_info_t *(*devices)();
^
void
3 errors generated.

Fix this by adding 'void' to the parameter lists. No functional change.

Reviewed by: emaste, imp, smh
Differential Revision: https://reviews.freebsd.org/D9144

MFC r311932:

Make EFI_RESERVED_SERVICE a proper prototype

With clang 4.0.0, the EFI API header causes the following warning:

In file included from sys/boot/efi/loader/bootinfo.c:43:
In file included from sys/boot/efi/loader/../include/efi.h:52:
sys/boot/efi/include/efiapi.h:534:32: error: this function declaration is not a prototype [-Werror,-Wstrict-prototypes]
(EFIAPI *EFI_RESERVED_SERVICE) (
^

Add VOID to make it into a real prototype.

Reviewed by: imp, emaste, tsoome
Differential Revision: https://reviews.freebsd.org/D9132

MFC 304018: Add defines needed to export SMBIOS serial numbers

Some defines needed for exporting serial numbers from the SMBIOS were
missed during integration of SMBIOS support in the EFI boot loader (r281138).
This is needed for getting the hostid set from the system hardware UUID.

PR: 206031

MFC r297871: boot1.efifat: provide a fallback startup.nsh

In case the firmware falls through to executing startup.sh, populate it
with the name of our boot loader. In normal operation this should not be
necessary but may allow the system to boot if it would otherwise just
remain at a shell prompt.

Sponsored by: The FreeBSD Foundation

MFC r302335: boot1.efi: fix assignment / comparison expression

PR: 210706
Submitted by: David Binderman <dcb314@hotmail.com>

MFC r296769: boot/efi: Prefer nm to objdump

Both objdump and nm are equally capable of reporting undefined symbols.

This gets us a step closer to building without binutils as we have an nm
implementation from ELF Tool Chain.

Sponsored by: The FreeBSD Foundation

MFC: r292563

loader.efi: strip trailing whitespace

MFC: r293244 (remainder missing in r294275)

Introduce and use new EFI_ERROR_CODE macro for EFI errors

MFC: r287299 [1]

Add a gop command to help diagnose VT efifb problems. The gop
command has the following sub-commands:
list - list all possible modes (paged)
get - return the current mode
set <mode> - set the current mode to <mode>

MFC: r287317, r287422, r287475, r287489, r287538 [2]

Add support for the UGA draw protocol. This includes adding a
command called 'uga' to show whether UGA is implemented by the
firmware and what the settings are. It also includes filling
the efi_fb structure from the UGA information when GOP isn't
implemented by the firmware.

PR: 207313 [1], 202730 [2]
Approved by: re (gjb)

Merge from current r294767,294769,295408

r294767: Parse command line arguments in loader.fi
r294769: Allow newlines to be treated as whitespace when parsing args
r295408: Implement -P command line option in for EFI booting.

Approved by: re@ (gjb@)

MFC r295320, r295356 (Partial)

Fix EFI multi device boot support

Approved by: re (marius)
Sponsored by: Multiplay

MFC r294768:

Process /boot/config and /boot.config during EFI boot

Approved by: re (marius)
Sponsored by: Multiplay

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

Catch the EFI loader up to the latest ZFS Boot Environment Menu features

MFC: r294072
Move init_zfs_bootenv to sys/boot/zfs/zfs.c instead of having a copy in each loader

MFC: r294073
Connect the ZFS boot environment menu to the UEFI loader

MFC: r295357
Do not set vfs.root.mountfrom unnecessarily when initializing ZFS BE menu

Approved by: re (marius)
Relnotes: yes
Sponsored by: ScaleEngine Inc.

MFC boot loader path and RBX constant deduplication

r294765 (imp)

Move all the separate copies of the same strings into paths.h. There's
nothing machine specific about these.

r294765 (imp)

RBX_ defines are in rbx.h, move it there.

r294847 (imp)

Remove static from these two. They slipped through the cracks.

r294925 (imp)

Fix mistake when transitioning to the new defines with ZFS loader. I
hate adding yet another define, but it is the lessor of the evil
choices available. Kill another evil by removing PATH_BOOT3 and
replacing it with PATH_LOADER or PATH_LOADER_ZFS as appropriate.

Approved by: re (gjb)

Fix clean target for sys/boot/efi

Fix clean target breakage of sys/boot/efi introduced by r294981
specifically the MFC of r294029 without the related change introduced by
r281114.

This is direct commit to stable/10 as head uses src.opts.mk.

Approved by: re (glebius)
Sponsored by: Multiplay

MFC r294068, r294265

MFC r294068:
Add EFI ZFS boot support

MFC r294265:
Fix broken DPRINTF and wire up EFI_DEBUG so -DEFI_DEBUG to make works.

Relnotes: Yes
Sponsored by: Multiplay

MFC r281060, r294060, r294291, r294493, r294284:

MFC r281060:
Remove an unnecessary space in a printf call

MFC r294060:
Modularise EFI boot loader

MFC r294291 (by andrew):
Reset the filesystem cache

MFC r294493:
Fix EFI UFS caching

MFC r294284 (by emaste):
boot1: correct typo in error message

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 r293460:

Switch EFT boot1 to use libstand

This includes a change to the Makefile comment to correct it due to the
lack of arm and i386 support in 10.x.

Sponsored by: Multiplay

MFC r293422 (partial):

Update generated EFI boot image templates.

This is a partial MFC as stable/10 only has EFI boot support for amd64,
and there are no plans to change this, so the other platform images
aren't included.

Sponsored by: Multiplay

MFC r293461:

Remove hidden "Not ufs" printfs from boot code

Sponsored by: Multiplay

MFC r293274:

style(9) fixes for EFI boot

Sponsored by: Multiplay

MFC r281059 (by rpaulo):

boot1 EFI: reset the screen and select the best mode.

Sponsored by: Multiplay

MFC r293268:

Fix _MSC_EXTENSIONS checks

Sponsored by: Multiplay

MFC r293245: loader.efi style(9) cleanup

Submitted by: smh

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 r292584:

Set env vars from values on the efi loader command line.

Examine each cmdline arg and if it contains an '=' convert it to ascii and
pass it to putenv(). This allows var=value settings to come in on the
command line.

This will allow overriding dhcp server-provided data in loader(8), as
discussed in PR 202098

PR: 202098
Relnotes: Yes (this goes together with r294343)

MFC r281058: Remove whitespace.

MFC r293244: Introduce and use new EFI_ERROR_CODE macro for EFI errors

MFC r293165: loader.efi: support non-contiguous console modes

MFC r281117: Move boot1.efi to the global CLEANFILES list

It's not x86 specific.

MFC r287930: Various small cleanups to EFI loader Makefiles.

MFC r286967 by imp: use -mno-aes and -mno-avx flags only with Clang

The flags -mno-aes -mno-avx only exist for clang, not [base] gcc, so
add them only to the clang CFLAGS.

Move -msoft-float compiler flag into x86/i386 cases to fix ia64

Direct commit to stable/10 as ia64 support does not exist in HEAD.

MFC r281027: Clean up more x86 only options in the efi code.

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.

loader.efi: combine GetMemoryMap and ExitBootServices and retry on error

MFC r292338: UEFI: combine GetMemoryMap and ExitBootServices and retry on error

The EFI memory map may change before or during the first
ExitBootServices call. In that case ExitBootServices returns an error,
and GetMemoryMap and ExitBootServices must be retried.

Glue together calls to GetMemoryMap(), ExitBootServices() and storage of
(now up-to-date) MODINFOMD_EFI_MAP metadata within a single function.

That new function - bi_add_efi_data_and_exit() - uses space previously
allocated in bi_load_efi_data() to store the memory map (it will fail if
that space is too short). It handles re-calling GetMemoryMap() once to
update the map key if necessary. Finally, if ExitBootServices() is
successful, it stores the memory map and its header as MODINFOMD_EFI_MAP
metadata.

ExitBootServices() calls are now done earlier, from within arch-
independent bi_load() code.

MFC r292442: loader.efi: show EFI error number, not full status value

EFI return values set the high bit to indicate an error. The log
messages changed here are printed only in the case of an error,
so including the error bit is redundant. Also switch to decimal to
match the error definitions (in sys/boot/efi/include/efierr.h).

MFC r292515: loader.efi: refresh size in GetMemoryMap retry loop

If ExitBootServices fails due to a changed efi_mapkey then GetMemoryMap
must be called again. In this case it is also possible for the memory
map to grow, so repeat the initial GetMemoryMap call to fetch the new
size.

Also roll bi_add_efi_data_and_exit into bi_load_efi_data as there's no
need for it to be a separate function.

PR: 202455
Relnotes: Yes
Sponsored by: The FreeBSD Foundation

MFC r281138: SMBIOS support for EFI

Restore smbios support lost in r293297

MFC r288372: Use EFI page size constants instead of hardcoding 4096

MFC r287934: Increase EFI staging size from 32MB to 48MB

The EFI boot loader allocates a single chunk of contiguous memory to
hold the kernel, modules, and any other loaded data. This memory block
is relocated to the kernel's expected location during the transfer of
control from the loader to the kernel.

PR: 201679

MFC r292576: boot1.efi: show EFI error number, not full status value

EFI return values set the high bit to indicate an error. The log
messages changed here are printed only in the case of an error,
so including the error bit is redundant. Also switch to decimal to
match the error definitions (in sys/boot/efi/include/efierr.h).

MFC r281000: Move i386/efi files to new home in efi/loader/arch/i386

This was not (and still is not) connected to the build, but the EFI
loader is in the process of being built for other than amd64 so these
files ought to live in their eventual MD location.

MFC r280950: Move the efi loaders to be under sys/boot/efi

In HEAD this was done to support UEFI on arm64. Merging to stable/10 to
facilitate the merging of later UEFI changes.

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 r278234: EFI: print more information about EFI Tables.

This adds the GUIDs for DXE, HOB, Memory Type Information and Debug
Image Info.

MFC r274439: Add the FDT table GUID.

This is used to pass the device tree blob from UEFI to the loader
in a similar way to the ACPI tables.

This will be used on arm64 but is not specific to the architecture.

Sponsored by: The FreeBSD Foundation

MFC r285246: Avoid creating invalid UEFI device path

The UEFI loader on the 10.1 release install disk (disc1) modifies an
existing EFI_DEVICE_PATH_PROTOCOL instance in an apparent attempt to
truncate the device path. In doing so it creates an invalid device
path.

Perform the equivalent action without modification of structures
allocated by firmware.

PR: 197641
Submitted by: Chris Ruffin <chris.ruffin at intel.com>

MFC 279950:
Enable bzipfs support in the EFI loader.
- Add bzipfs to the list of supported filesystems in the EFI loader.
- Increase the heap size allocated for the EFI loader from 2MB to 3MB.

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 r272105: Remove duplicated header content

Approved by: re (gjb, kib)

MFC r271762: Switch to text mode in UEFI boot

The loader previously failed to display on MacBooks and other
systems where the UEFI firmware remained in graphics mode.

Submitted by: Rafael Espindola

Approved by: re

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

Copy head (r256279) to stable/10 as part of the 10.0-RELEASE cycle.

Approved by: re (implicit)
Sponsored by: The FreeBSD Foundation

Typo in a comment.

boot: use -march=i386 for both i386 and amd64 builds

.. so that consistent compilation algorithms are used for both
architectures as in practice the binaries are expected to be
interchangeable (for time being).
Previously i386 used default setting which were equivalent to
-march=i486 -mtune=generic.
The only difference is using smaller but slower "leave" instructions.

Discussed with: jhb, dim
MFC after: 29 days

Build a 32-bit EFI loader on amd64. This to match the rest of the
code that is used to construct a loader (e.g. libstand, ficl, etc).

There is such a thing as a 64-bit EFI application, but it's not
as standard as 32-bit is. Let's make the 32-bit functional (as in
we can load and actualy boot a kernel) before solving the 64-bit
loader problem.

MFaltix:
Add support for Pre-Boot Virtual Memory (PBVM) to the loader.

PBVM allows us to link the kernel at a fixed virtual address without
having to make any assumptions about the physical memory layout. On
the SGI Altix 350 for example, there's no usuable physical memory
below 192GB. Also, the PBVM allows us to control better where we're
going to physically load the kernel and its modules so that we can
make sure we load the kernel in memory that's close to the BSP.

The PBVM is managed by a simple page table. The minimum size of the
page table is 4KB (EFI page size) and the maximum is currently set
to 1MB. A page in the PBVM is 64KB, as that's the maximum alignment
one can specify in a linker script. The bottom line is that PBVM is
between 64KB and 8GB in size.

The loader maps the PBVM page table at a fixed virtual address and
using a single translations. The PBVM itself is also mapped using a
single translation for a maximum of 32MB.

While here, increase the heap in the EFI loader from 512KB to 2MB
and set the stage for supporting relocatable modules.

Revert previous commit: EFI_STATUS is a 64-bit integral on ia64. Fix the
compile warning on i386 (where EFI_STATUS is a 32-bit integral) by casting
the status argument to u_long instead.

Pointy hat: brucec
MFC after: 3 days

Handle memory allocation failures in include().

PR: i386/85652
Submitted by: Ben Thomas <bthomas at virtualiron.com>
MFC after: 3 days

Help static analysis by initializing variables that we know cannot be
used uninitialized, but which cannot be inferred from the code itself.

MF tbemd: move to using specific architecture makefiles

Remove file system support based on the simple file system protocol
as this only allows us to access file systems that EFI knows about.
With a loader that can only use EFI-supported file systems, we're
forced to put /boot on the EFI system partition. This is suboptimal
in the following ways:
1. With /boot a symlink to /efi/boot, mergemaster complains about
the mismatch and there's no quick solution.
2. The EFI loader can only boot a single version of FreeBSD. There's
no way to install multiple versions of FreeBSD and select one
at the loader prompt.
3. ZFS maintains /boot/zfs/zpool.cache and with /boot a symlink we
end up with the file on a MSDOS file system. ZFS does not have
proper handling of file systems that are under Giant.

Implement a disk device based on the block I/O protocol instead and
pull in file system code from libstand. The disk devices are really
the partitions that EFI knows about.

This change is backward compatible.

MFC after: 1 week

Enable GCC stack protection (aka Propolice) for userland:
- It is opt-out for now so as to give it maximum testing, but it may be
turned opt-in for stable branches depending on the consensus. You
can turn it off with WITHOUT_SSP.
- WITHOUT_SSP was previously used to disable the build of GNU libssp.
It is harmless to steal the knob as SSP symbols have been provided
by libc for a long time, GNU libssp should not have been much used.
- SSP is disabled in a few corners such as system bootstrap programs
(sys/boot), process bootstrap code (rtld, csu) and SSP symbols themselves.
- It should be safe to use -fstack-protector-all to build world, however
libc will be automatically downgraded to -fstack-protector because it
breaks rtld otherwise.
- This option is unavailable on ia64.

Enable GCC stack protection (aka Propolice) for kernel:
- It is opt-out for now so as to give it maximum testing.
- Do not compile your kernel with -fstack-protector-all, it won't work.

Submitted by: Jeremie Le Hen <jeremie@le-hen.org>

Major rework of the ia64 loaders. The two primary objectives are:
1. Make libefi portable by removing ia64 specific code and build
it on i386 and amd64 by default to prevent regressions. These
changes include fixes and improvements over previous code to
establish or improve APIs where none existed or when the amount
of kluging was unacceptably high.
2. Increase the amount of sharing between the efi and ski loaders
to improve maintainability of the loaders and simplify making
changes to the loader-kernel handshaking in the future.

The version of the efi and ski loaders are now both changed to 1.2
as user visible improvements and changes have been made.

Make this compile on EFI32. The EFI_PHYSICAL_ADDRESS type is always
64-bit, even when sizeof(void *) is 32-bit.

Sync the EFI headers with version 1.10.14.62 of the Intel sample EFI
implementation. This re-introduces C99 style comments that previously
were replaced by original C comments.

Extend struct devdesc with a unit field, called d_unit. Promote the
device (kind) specific unit field to the common field. This change
allows a future version of libefi to work without requiring anything
more than what is defined in struct devdesc and as such makes it
possible to compile said version of libefi for different platforms
without requiring that those platforms have identical derivatives
of struct devdesc.

Remove more Alpha bits from the boot code including fixing several
stale comments.

Add loader(8) variables for RB_DFLTROOT, RB_MUTE, and RB_PAUSE:
"boot_dfltroot", "boot_mute", and "boot_pause" respectively.

Don't try to use 'typedef struct foo' if just 'struct foo' makes more sense
and works on all compilers. This also removes the need for
__CC_SUPPORTS_FORWARD_REFERENCE_CONSTRUCT in <sys/cdefs.h>.

OK'ed by: marcel, dfr

Fix typos in a comment.

netchild's mega-patch to isolate compiler dependencies into a central
place.

This moves the dependency on GCC's and other compiler's features into
the central sys/cdefs.h file, while the individual source files can
then refer to #ifdef __COMPILER_FEATURE_FOO where they by now used to
refer to #if __GNUC__ > 3.1415 && __BARC__ <= 42.

By now, GCC and ICC (the Intel compiler) have been actively tested on
IA32 platforms by netchild. Extension to other compilers is supposed
to be possible, of course.

Submitted by: netchild
Reviewed by: various developers on arch@, some time ago

Start each of the license/copyright comments with /*-

Remove the last vestiges of the userconfig option. None of this actually
did anything, so this commit should be considered a NO-OP.

o Introduce efimd_va2pa() to translate addresses in efi_copy{in|out}()
and efi_readin(). This removes MD code from copy.c.
o Don't unconditionally add pal.S to SRCS. It's specific to ia64.

This file was repocopied to src/sys/boot/ia64/efi.

Unhook the loader subdirectory. The ia64 EFI loader is now build
under ../ia64/efi.

Remove struct ia64_itir and use a plain old uint64_t instead.

For variables that are only checked with defined(), don't provide
any fake value.

Redefine a PTE as a 64-bit integral type instead of a struct of
bit-fields. Unify the PTE defines accordingly and update all
uses.

Catch up with change to <machine/pte.h>.

o Support the REL32LSB relocation. It's in the ELF file from which
we construct the EFI image. It doesn't seem to actually end up
in the EFI image, AFAICT.
o Replace .quad, .long and .short with data8, data4 and data2 resp.
The former are gnuisms.
o Redefine _start_plabel as a data16 with @iplt(_start) as its
value. This is the preferred way to create user PLT entries.

Fix the creation of EFI images that got broken by the import of
binutils 2.15. The linker now creates a .rela.dyn section for
dynamic relocations, while our script created a .rela section.
Likewise, we copied the .rela section to the EFI image, but not
the .rela.dyn section. The fix is to rename .rela to .rela.dyn
in the linker script so that all relocations end up in the same
section again. This we copy into the EFI image.

Remove advertising clause from University of California Regent's license,
per letter dated July 22, 1999.

Approved by: core

Reset the text attributes when initializing the console. The EFI
loader typically doesn't do this so that we end up booting the
with whatever the EFI loader has set it to last.

Don't create a mapfile during link. It's not needed for the build.

o Don't build with -fpic. It's not needed and inconsistent with how
other constributions are compiled.
o Remove powerpc specific additions to CFLAGS.

Tidy up makefiles.

Tested by: marcel

Convert to __FBSDID.

Fix typo in comment.

Don't hardcode unit 0 for the current device if we're loaded from an
EFI file system. When booting from a CD and there's already an EFI
system partition on the disk, setting the current device to unit 0
will select the harddisk. This invariably breaks installing FreeBSD
when other operating systems have been installed before.

We obviously want to do the same when we're booting over the network.
Maybe later.

Based on a patch (from memory) from: arun

Have the linker script look more like the default linker script
on ia64. This fixes the breakage caused by the gcc upgrade that
resulted in a broken executable.

sys/ia64/ia64/pal.s has been repocopied to pal.S.

Approved by: marcel
Repocopied by: joe

Enable the i386 loader to load and run an amd64 kernel. If this puts
things over floppy size limits, I can exclude it for release builds or
something like that. Most of the changes are to get the load_elf.c file
into a seperate elf32_ or elf64_ namespace so that you can have two
ELF loaders present at once. Note that for 64 bit kernels, it actually
starts up the kernel already in 64 bit mode with paging enabled. This
is really easy because we have a known minimum feature set.

Of note is that for amd64, we have to pass in the bios int 15 0xe821
memory map because once in long mode, you absolutely cannot make VM86
calls. amd64 does not use 'struct bootinfo' at all. It is a pure loader
metadata startup, just like sparc64 and powerpc. Much of the
infrastructure to support this was adapted from sparc64.

Use __FBSDID rather than rcsid[].

Speed up debugging in the context of unexpected traps by printing
the address of the image base of the loader. Given cr.iip, we can
use the symbol table to figure out what function caused the trap.

Paranoia: Don't use the length of the option string alone to
determine whether we have command line options. We expect a
valid string pointer as well.

Increase the block size for reading and writing from 8KB to 1MB and
introduce a preprocessor define for it. The larger block size
significantly speeds up the loading of the kernel.

Submitted by: Arun Sharma <arun.sharma@intel.com>

Consistently use NOFORTH to control the usage of ficl.

Simplify page alignment.

Renamed the loader's zipfs to gzipfs. zipfs.c was repo-copied to gzipfs.c.

Add command `hcdp'. This command dumps the DIG64 HCDP table if one
exists.

Pass the HCDP table address to the kernel. If no such table exists,
NULL is passed. The address of the HCDP table can be found by
iterating over the configuration tables in the EFI system table.
To avoid more duplication, a function can be called with the GUID
of interest. The function will do the scanning. Use the function
in all places where we iterate over the configuration tables in
an attempt to find a specific one.

Bump the loader version number as the result of this.

Approved by: re (blanket)

The exit() function has been moved to libefi.c to better deal with
cleaning up after ourselves.

Approved by: re (blankoscheck)
German corrections: Alexander (both :-)

Change the startup code to fix a memory leak and to allow us to
accept load options (=command line options).

The call graph changes from *entry*->efi_main->efi_init, where
efi_main is the EFI equivalent of main to *entry*->efi_main->main,
where main is what you'd expect. efi_main now is what efi_init was.
The prototype of main follows that of C. The first argument is argc
and the second is argv. There is no third argument.
Allocation of heap pages is now handled by the EFI library and it
now deallocates the pages when main() returns or when exit() is
called. This allows us to safely return to the boot manager (or
EFI shell) without leaks. EFI applications are responsible to free
all memory themselves.

Handling of the load options is a bit tricky. There are either no
load options, load options in ASCII or load options in Unicode.
The EFI library will translate the ASCII options to Unicode options
as to simplify user code. Since the load options are passed as a
single string (if present) and main() accepts argc and argv, the
startup code also has to split the string into words and build the
argv vector. Here the trickiness starts. When the loader is started
from the EFI shell, argv[0] will automaticly load the program name.
In all other cases (ie through the boot manager), this is not the
case. Unfortunately, there's no trivial way to check. Hence, a
set of conditions is checked to determine if we need to fill in
argv[0] ourselves or not. This checking is not perfect. There are
known cases where it fails to do the right thing. The logic works
for most expected cases, though. This includes the case where no
options are given.

Approved by: re (blanket)

o Make all GUID variables global to maximize reuse.
o Recognize the HCDP configuration table.
o Dump the GUID of tables we don't recognize.

Approved by: re (carte blanche)

Build EFI with -fshort-wchar so that L"some string" works with the
EFI has defined CHAR16.

Remove _putchar, _puts and _puthex. These functions are unused.

Approved by: re (blanket)

Add the GUID of the DIG64 HCDP table.

The boot manager sets the watchdog timer to 5 minutes before invoking
a boot option. When the timer expires the machine is rebooted.
Disable the watchdog timer for 2 reasons:
o We're an interactive program. We cannot guarantee that we've
booted the kernel in the time available to us. There have been
situations where netbooting the right kernel took 2 tries and
more time than given. Not to speak of the normal behaviour to
have the loader sitting at the prompt while the user is off
doing other things (such as figuring out what to type next ;-)
o We may not boot a kernel at all. We may exit as the result of
the user typing quit (assuming it took less than 5 minutes to
type it :-). It is documented that loaders should have disabled
the watchdog timer if they return to the boot manager. Not doing
so would cause a reboot while in the boot manager. This appears
to be harmless, besides of course the actual reboot.

Approved by: re (weisse karte)

In efi_cons_poll we check if a key is present (pending) by checking
the signaled state of the apropriate event. As a side-effect of
checking the event, it's signaled state is cleared if it was set.
In efi_cons_getchar we used to wait for the apropriate event to be
signaled before reading a character. This however does not work if
we poll before reading the characteri, such as during autoboot. On
a more compliant EFI implementation this resulted in the behaviour
that hitting a key during autoboot would stop the countdown, but
would then wait for a new character to arrive instead of reading
the already pending key that stopped the countdown.

The correct behaviour for efi_cons_getchar is to try to read a key
and if none is pending, to wait for the apropriate event to signal
the arrival of a new key.

Note that with the previous behaviour, the second key would determine
how the autoboot was interrupted. This would indicate that the first
key got lost. This indicates that EFI does not necessarily maintain
a queue of pending keys. FWIW...

Approved by: re (carte blanche)
French corrected by: various people :-)

Remove a left-over virtual mapping of uncached I/O port space.
Previous kernels unwantingly depended on this mapping, but as
of version 1.123 of src/sys/ia64/ia64/machdep.c this dependency
has been removed. Consequently, one has to update the kernel
before updating the loader. The documented/recommended upgrade
will suffice in this case.

Due to a visible (from the kernels point of view) change in
behaviour, bump the loader version number from 0.3 to 1.0.

Approved by: re (carte blanc)

MFp4:
o Show the contents of the AP wakeup descriptor when dumping SAL
information.
o Increase S/N ratio when listing the itr and dtr. Only show valid
mappings and give the total number of TRs.

Approved by: re (blanket)

o Fix a size calculation based on a 8KB page, while under EFI
pages are 4KB.
o As a second order fix, don't assume we have enough space
after the bootinfo block left in a page to hold the memory
map.
o A third order fix as that we removed the assumption that a
bootinfo block fits in a single 8KB page.

PR: ia64/39415
submitted by: Espen Skoglund <esk@ira.uka.de>

Turn on -Wformat

Fix printf format errors

Work around some nasty bugs on the [beta] Itanium2's E1000 UNDI driver.

Bug#1: The GetStatus() function returns radically different pointers that
do not match any packets we transmitted. I think it might be pointing to
a copy of the packet or something. Since we do not transmit more than
one packet at a time, just wait for "anything".

Bug#2: The Receive() function takes a pointer and a length. However, it
either ignores the length or otherwise does bad things and writes outside
of ptr[0] through ptr[len-1]. This is bad and causes massive stack
corruption for us since we are receiving packets into small buffers on
the stack. Instead, Receive() into a large enough buffer and bcopy the
data to the requested area.

Disable loader ufs support. It causes the loader to crash on the Itanium2
box that I have. We have no EFI disk drivers yet anyway (maybe that is the
problem).

Fix printf format errors

Add boot_serial and boot_multicons variables to set RB_SERIAL and
RB_MULTIPLE since this seems to be the easiest way to add these flags
for non-forth loaders etc.

o Remove namespace pollution from param.h:
- Don't include ia64_cpu.h and cpu.h
- Guard definitions by _NO_NAMESPACE_POLLUTION
- Move definition of KERNBASE to vmparam.h

o Move definitions of IA64_RR_{BASE|MASK} to vmparam.h
o Move definitions of IA64_PHYS_TO_RR{6|7} to vmparam.h

o While here, remove some left-over Alpha references.

An almost mechanical sweep to replace C++ style comments with C
style comments. This is not an attempt to conform to style(9).
Such has lower priority.

More s/file system/filesystem/g

Removed now unused INTERNALSTATICLIB.
INTERNALLIB now implies NOPIC and NOPROFILE.
Removed gratuitous NOMAN.

Back out last commit. I expect our bsd.*.mk gods to remove the need for
defining so many extra things in addition to INTERNALLIB. We don't like
repetitive C code and we shouldn't for make code either.

NOPIC, NOPROFILE, NOMAN, and INTERNALSTATICLIB are redundant when using
INTERNALLIB now.

-ffreestanding is the word.
(also resort some CFLAGS such that the more "important" value are first so
they are easier to see)

Improve self-relocation:
o We don't expect the PLT relocations to follow the .rela section
anymore. We still assume that PLT relocations are long formed,
o Document register usage,
o Improve ILP,
o Fix the FPTR relocation by creating unique OPDs per function.
Comparing functions is valid now,
o The IPLT relocation naturally handles the addend. Deal with it.
We ignore the addend for FPTR relocations for now. It's not at
all clear what it means anyway.

Fix ABI misinterpretation:
o For Elf_Rela relocations, the addend is explicit and should not
be loaded from the memory address we're relocating. Only do that
for Elf_Rel relocations (ie the short form).
o DIR64LSB is not the same as REL64LSB. DIR64LSB applies to a
symbol (S+A), whereas REL64LSB applies to the base address (BD+A),

Allocate sufficient pages to hold the bootinfo block and stop
hardwiring the location.

Finally fix loader completely for IA64. efifs_stat() wasn't setting
the S_IFREG bit for regular files. This caused the path search code to
skip it when it finally did find the kernel (after the common/module.c
buffer overrun bug was fixed)

We must not let install(1) strip loader.efi when installing it, or the
resulting binary will be damaged and no longer work.

Set BINDIR

Add loader bootforth infrastructure and install it.

Try and tidy up some very loose ends with paths to various libraries etc.

Do not assume that ${OBJCOPY} variable exists. It was hidden by the
fact that the 'ia64-make' wrapper explicitly set it.

Fix self hosted loader building. When you use a self configured gcc, it
detects and uses the gas section merge support. As a result, a whole bunch
of new sections arrive, including .rodata.str1.8, which was not included
in our custom ldscript.ia64. The result was a loader binary that EFI
rejected.

While here, collect the loader shell commands linker set and include it
in the data area rather than having its own section.

/boot/loader.efi was the last holdout for having a 100% self built ia64
system.

Use a relative path to libstand.. /usr/src/lib/libstand may not exist
or may have the wrong header files.

Only install the help file if we can find it. Use ${BASE}.help
in both the condition and for the install. We expect to find
the help file in ${.OBJDIR}.

Pass the physical address of the bootinfo block to the kernel in
register r8. We continue to write the bootinfo block at the same
hardwired address, because the kernel still expects it there.
It is expected that future kernels use register r8 to get to the
bootinfo block and don't depend on the hardwired address anymore.

Bump the loader version once again due to the interface change.

Add a quick and dirty way to determine where we're loaded from. We
only care if it's network or not at this time. If we're loaded from
the network, we set currdev (=loaddev) so that the kernel is loaded
from the network as well. In all other cases we initialize to disk.
This makes netbooting more convenient and can easily be enhanced to
do more elaborate checking.

The EFI loader has been improved a lot since it was first added.
Most significantly (from an interfacing point of view) is the
support for the FPSWA pointer passing. Even though that was added
4 months ago, it's probably not a bad idea to bump the version
number to reflect this.

Fix the initialization of the protocol:
o Query the state field of the protocol mode to determine whether
we need to start and/or initialize the protocol. When we're
loaded across the network, the protocol has already been started
and is already initialized. When no networking has happened yet,
we have to start and initialize the protocol ourselves.
o After initialization, we have to set the receive filters. Not
doing this results in a deaf interface. We set the unicast and
broadcast filters. Multicast may not be supported. This specific
change fixes the problem we had that we could not netboot if
the loader was started from the EFI shell.
o To help future debugging, add a function that dumps the current
mode of the interface. It's conditional on EFINET_DEBUG.
o To help in runtime problems, emit a diagnostic message when we
could not initialize the protocol properly.

Don't blindly dereference f->f_devdata as if it's always a pointer to
an efi_devdesc structure. When we're netbooting, f->f_devdata holds
the address of the network socket variable. Dereferencing this caused
some very unpredictable behaviour, including proper functioning.
So, as a sanity check, we first make sure f->f_dev points to our
own devsw. If not, the open will fail before we use f->f_devdata.

This solves the netboot hangs I invariably got whenever I used the
latest toolchain to compile the EFI loader.

o Make efinet_put a blocking call by waiting for the protocol
layer to signal transmission of the packet. This resolves the
problem I'm seeing that an immediate call to net->Receive
after calling net->Transmit returns EFI_DEVICE_ERROR. This
condition seems to be sufficiently persistent that BOOTP and
RARP fail.
o While here, unify all functions to have 'nif' defined. Some
have it as arguments. The others now have them as locals. We
now always get the protocol interface by using the 'nif' var.

The current status of netbooting is that even though we now reliably
have BOOTP working (again), opening a file (ie loading a kernel)
across the network causes the loader to hang. I'm working on that now.

o Don't include sys/cdefs.h

o Add -L${DESTDIR}${LIBDIR} on the link line for -lstand.
o Add -j .dynstr to objcopy. This makes .efi binaries work
when built with a 3.x based toolchain.

Add EFI write support to loader

Add -ffreestanding to avoid printf/puts/putchar conversions

Boot from efifs first.

gcc-3.1 likes to have extra { } around the internal array initializers in
the GUID templates.

Lookup the EFI_FPSWA driver and pass the interface pointer through to the
kernel before we call ExitBootServices(). I've typed the definitions
in efifpswa.h from the Intel FPSWA manual (urk).

Remove bootinfo.bi_kernel. It isn't used by the kernel. struct bootinfo
should go away on ia64, we should be loader metadata based since that is
the only way we can boot (loader, skiload).

This is used in C, not C++. functions with no args have func(void) in our
kernel.

o Add new header <sys/stdint.h>.
o Make <stdint.h> a symbolic link to <sys/stdint.h>.
o Move most of <sys/inttypes.h> into <sys/stdint.h>, as per C99.
o Remove <sys/inttypes.h>.
o Adjust includes in sys/types.h and boot/efi/include/ia64/efibind.h
to reflect new location of integer types in <sys/stdint.h>.
o Remove previously symbolicly linked <inttypes.h>, instead create a
new file.
o Add MD headers <machine/_inttypes.h> from NetBSD.
o Include <sys/stdint.h> in <inttypes.h>, as required by C99; and
include <machine/_inttypes.h> in <inttypes.h>, to fill in the
remaining requirements for <inttypes.h>.
o Add additional integer types in <machine/ansi.h> and
<machine/limits.h> which are included via <sys/stdint.h>.

Partially obtain from: NetBSD
Tested on: alpha, i386
Discussed on: freebsd-standards@bostonradio.org
Reviewed by: bde, fenner, obrien, wollman

Set RB_MULTIPLE (multiple console support) if the kernel is booted
with the -D flag.

Call ExitBootServices and disable interrupts before we start hacking
the VM registers. This ought to make things slightly more reliable here.

Add the two sections used for PLT entries to the text and sdata sections
respectively. This makes IPLTLSB relocations work properly (these are
generated for weak symbols, particularly for _longjmp).

Try to get the self-relocator to work with IPLTLSB relocations. Doesn't
work right though - I can't figure out why.

Fix typo in comment.

s/alpha/${MACHINE_ARCH}/g

Calculate the valid flag for ITRs and DTRs correctly. Also fix a couple
of minor problems and remove some debugging code.

Add commands to dump the itrs and dtrs.

Return the mapkey which EFI gave us when we read the memory map - we need
it to call ExitBootServices.

Tidy up a little - don't try to print anything or enable interrupts after
we start changing translation registers. Also, call ExitBootServices
before we jump into the kernel.

Pick up pal.s from the kernel sources.

Add commands to dump the configuration tables and the SAL System Table.

Add EFI network support.

* Flesh out elf_exec and bootinfo.
* Add EFI network support.

Add getsecs() for the libstand network code.

Add a twiddle meter when reading from files. Gives me something to look
at when a kernel is loading from a floppy.

Plug in ELF backend.

Add ELF backend to the build.

Make this do the right thing (mostly). We should still reserve the pages
that the kernel loads into using the EFI AllocatePages call.

Add missing entry to memory type name table and adjust field widths.

Add a command 'memmap' to print out the EFI memory map.

Hook up the native EFI filesystem reader.

Set currdev and loaddev variables.

Add a libstand filesystem for accessing EFI native filesystems.

Reformat.

Merge linker set relocations with the rest.

Enable bootforth.

Make sure we copy over the linker set sections to the EFI executable.

Make this build again after breakage from previous commits.

style(9) and remove a left over Alpha comment

style cleanup

style police

This Intel derived file uses C++ style comments.
(I'll be we know which compiler and platform they developed this on...)
Minimally change them to C89 comments to make GCC happy. (this is kinda funny
as the file has piece derived from FreeBDS 3.2)

Also fix FreeBSD id style.

Fix FreeBSD id style.

style(9)

style(9) + fix FreeBSD id's.

Nuke old gensetdefs based linker sets with extreme prejudice

Move the first section up one page. The firmware bogusly uses the first
page of the image to load section headers and if we let the text section
start at zero, it corrupts the section table when its loaded. With this
change, the loader gets as far as the 'ok' prompt.

Remove a 'return' statement which I put in while I was trying to debug
the startup code.

First approximation of an ia64 EFI loader. Not functional.