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 r277215, r277291, r277418, r280953 and r280954:

loader: implement multiboot support for Xen Dom0

Note that only the subset of the multiboot specification needed in order to
boot a Xen Dom0 is implemented.

Sponsored by: Citrix Systems R&D

MFC r279275: Fix potential NULL dereference.

Submitted by: Dmitry Luhtionov <dmitryluhtionov@gmail.com>

MFC r278032:

Do not skip setting the memory 'reg' property if the fdt data already
contains one.

MFC 273927:

Move the definitions of the fdt functions from a uboot header to a new fdt
header. There is nothing in the fdt spec that ties it to U-Boot.

While here sort and fix the signature of fdt_setup_fdtp.

MFC 273934:

Start to allow platforms other than U-Boot to use the FDT code in loader by
moving U-Boot specific code from libfdt.a to a new libuboot_fdt.a. This
needs to be a new library for linking to work correctly.

Differential Revision: https://reviews.freebsd.org/D1054
Reviewed by: ian, rpaulo (earlier version)

MFC r273913:

Clean up the types of a few strings to make them const when they are never
written to.

MFC r273914:

The command name is a constant, use the correct type.

MFC r273298:

The U-Boot README says fdt_addr_r is the right env var for fdt data
loaded into ram, but vendors also use fdtaddr and fdt_addr. Check the
recommended variable first and fall back to the others.

MFC r262664, r262694:

Prevent fdt data loaded from a file from overwriting the kernel environment,
by having uboot_autoload() do the fdt setup (which may load a file) rather
than waiting until we're actually in the process of launching the kernel.

As part of making this happen...
- Define LOADER_FDT_SUPPORT on the uboot/lib compile command line when
MK_FDT is set.
- Make fdt_setup_fdtb() public.
- Declare public fdt_whatever() functions in a header instead of using
scattered extern decls in .c files.

MFC r262340, r262345, r262347, find and load an appropriate dtb file.

The search order for a usable dtb in fdt_setup_fdtp() is now

- A dtb loaded with an explicit "load -t dtb" command.
- A dtb already loaded into memory somehow[*] and pointed to by fdt_to_load.
- A dtb in the memory pointed to by the u-boot env vars fdtaddr or fdt_addr.
- A file named by the u-boot env vars fdtfile or fdt_file.
- A static dtb compiled into the kernel.

* Presumably by some arch-specific command or code.

MFC r262326 (white space) and r262327 (fdt_addr).

This change was supposed to be whitespace only, but a functional change
snuck in, as follows:

Look for both fdtaddr and fdt_addr env var names. Grepping the u-boot
source shows that board vendors seem to be about evenly split on this.
The added lines were:

/* Board vendors use both fdtaddr and fdt_addr names. Grrrr. */

if (s == NULL)
s = ub_env_get("fdt_addr");

MFC r261819 & r262242: Actually validate the header of a loaded dtb file.

MFC r279275: Fix potential NULL dereference.

Submitted by: Dmitry Luhtionov <dmitryluhtionov@gmail.com>

MFC r278032:

Do not skip setting the memory 'reg' property if the fdt data already
contains one.

MFC 273927:

Move the definitions of the fdt functions from a uboot header to a new fdt
header. There is nothing in the fdt spec that ties it to U-Boot.

While here sort and fix the signature of fdt_setup_fdtp.

MFC 273934:

Start to allow platforms other than U-Boot to use the FDT code in loader by
moving U-Boot specific code from libfdt.a to a new libuboot_fdt.a. This
needs to be a new library for linking to work correctly.

Differential Revision: https://reviews.freebsd.org/D1054
Reviewed by: ian, rpaulo (earlier version)

MFC r273913:

Clean up the types of a few strings to make them const when they are never
written to.

MFC r273914:

The command name is a constant, use the correct type.

MFC r273298:

The U-Boot README says fdt_addr_r is the right env var for fdt data
loaded into ram, but vendors also use fdtaddr and fdt_addr. Check the
recommended variable first and fall back to the others.

MFC r262664, r262694:

Prevent fdt data loaded from a file from overwriting the kernel environment,
by having uboot_autoload() do the fdt setup (which may load a file) rather
than waiting until we're actually in the process of launching the kernel.

As part of making this happen...
- Define LOADER_FDT_SUPPORT on the uboot/lib compile command line when
MK_FDT is set.
- Make fdt_setup_fdtb() public.
- Declare public fdt_whatever() functions in a header instead of using
scattered extern decls in .c files.

MFC r262340, r262345, r262347, find and load an appropriate dtb file.

The search order for a usable dtb in fdt_setup_fdtp() is now

- A dtb loaded with an explicit "load -t dtb" command.
- A dtb already loaded into memory somehow[*] and pointed to by fdt_to_load.
- A dtb in the memory pointed to by the u-boot env vars fdtaddr or fdt_addr.
- A file named by the u-boot env vars fdtfile or fdt_file.
- A static dtb compiled into the kernel.

* Presumably by some arch-specific command or code.

MFC r262326 (white space) and r262327 (fdt_addr).

This change was supposed to be whitespace only, but a functional change
snuck in, as follows:

Look for both fdtaddr and fdt_addr env var names. Grepping the u-boot
source shows that board vendors seem to be about evenly split on this.
The added lines were:

/* Board vendors use both fdtaddr and fdt_addr names. Grrrr. */

if (s == NULL)
s = ub_env_get("fdt_addr");

MFC r261819 & r262242: Actually validate the header of a loaded dtb file.