Sponsored by:	Netflix

what was tested...

loader.conf for uboot have this in the list, but the default one
didn't. Since there's no harm and it's a failsafe, add it to the list.

Sponsored by: Netflix

loader.conf is also different between machines. On arm it's a minimal
one that's not quite compatible with the default one. On arm it's
minimal for speed, which is good, but there's also extra things in it
relative to the default on which break loading FDT which is bad. This
doesn't address that issue, but instead ensures the minimal one for
arm is used.

A similar issue for mips exists, but since we can have a beri variant
of /boot/loader and a uboot variant, I'm leaving that mess alone for
the moment.

Sponsored by: Netflix

There were two things wrong. First, the wrong path was listed in .PATH
statement. Second, BOOTSRC wasn't yet defined for the .PATH, so it
didn't properly add it. Third, even if these were right, . was in the
path before, so it wouldn't have worked. Replace this with a simple
loop so the proper loader.rc gets selected.

Noticed by: dhw@ (menus stopped working on boot)
Sponsored by: Netflix

Also, move generation of loader.help into loader.mk. Set HELP_FILES=
to disable this (so we only install one help file, for now). At the
same time remove some duplicate -I lines. Fix several FILES= and
CLEANFILES= into the += form since we're touching both of those in the
.mk files. Make sure we only build one loader.help file per platform
in a unified way (we were building many on some, with the last to
install winning, though often they were the same text).

Also, we're now installing loader.rc and menu.rc everywhere. arm and
mips uboot installed these as menu.rc.sample, but there's no need
since the loader.rc for those platforms doesn't do menu.rc processing
by default. pcibios.4th is now installed everywhere, but will failsafe
on non x86 platforms (it isn't loaded by default anywhere).

These changes are too intertwined to do separately since aspects of
each are required to have a bug-free commit.

Sponsored by: Netflix

AMD Family 17h CPUs have an internal network used to communicate between
the host CPU and the PSP and SMU coprocessors.  It exposes a simple
32-bit register space.

Reviewed by:	avg (no +1), mjoras, truckman
Sponsored by:	Dell EMC Isilon
Differential Revision:	https://reviews.freebsd.org/D12217

Implement simple chain loader in loader; this update does add chain command,
taking device or file as argument to load and start new boot loader.

In case of BIOS, the chain will read the boot block to address 0000:7c00 and
jumps on it. In case of UEFI, the chain command is to be used with efi
application, typically stored in EFI System Partition.

The update also does add simple menu entry, if the variable chain_disk is set.
The value of the variable chain_disk is used as argument for chain loading.

Relnotes:	yes
Differential Revision:	https://reviews.freebsd.org/D5992

in /boot/defaults/loader.conf to something that's actually commonly used,
"mdroot".  It's arbitrary, but it's easier to find this way.

MFC after:	2 weeks

patm(4) devices.

Maintaining an address family and framework has real costs when we make
infrastructure improvements.  In the case of NATM we support no devices
manufactured in the last 20 years and some will not even work in modern
motherboards (some newer devices that patm(4) could be updated to
support apparently exist, but we do not currently have support).

With this change, support remains for some netgraph modules that don't
require NATM support code. It is unclear if all these should remain,
though ng_atmllc certainly stands alone.

Note well: FreeBSD 11 supports NATM and will continue to do so until at
least September 30, 2021.  Improvements to the code in FreeBSD 11 are
certainly welcome.

Reviewed by:	philip
Approved by:	harti