MFC uftdi(4) driver changes...
  r264010: Support speeds up to 12mbaud on newer chips.
  r264031: Use 2K IO buffers for improved throughput.
  r264149: Add ioctl(2) calls to access bitbang, MPSSE, CPU_FIFO,
           and other modes.
MFC r264800: fixes for problems found by Coverity scan...
  - Get transmit loop more in line with the other serial drivers.
  - Add a comment about FTDI and ZLPs.
  - Correctly check odditiy of baud rate divisor.
  - Correct IOCTL handling for "error" and "event" char.
MFC r264018: update list of supported FTDI chips.
MFC r257210, r258527: No hardfloat in ubldr, save/restore r9 for api calls.
MFC r261819 & r262242: Actually validate the header of a loaded dtb file.
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 r262337: Allow the boot device to be choosen by a u-boot env variable.

  If a "loaderdev=<device>" env variable is set and the named device
  exists, it is used.  If the device doesn't exist, fall back to the
  historic "probe" loop that prefers disk devices over network devices.
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 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 r262666: exit with code 0xbadab1 if the u-boot API support is missing.
MFC r263052, r263124, r263265, r263267...  Enhance loaderdev env var.

Enhance the mechanism that lets you configure the ubldr boot device by
setting the u-boot environment variable loaderdev=.  It used to accept only
'disk' or 'net'.  Now it allows specification of unit, slice, and partition
as well.  In addition to the generic 'disk' it also accepts specific
storage device types such as 'mmc' or 'sata'.

If there isn't a loaderdev env var, the historical behavior is maintained.
It will use the first storage device it finds, or a network device if
no working storage device exists.

99% of the work on this was done by Patrick Kelsey, but I made some
changes, so if anything goes wrong, blame me.

(Indeed, the 3 followup commits fixed things I got wrong on the first.)
MFC r264436:
Fix some off-by-one errors. The kve_end and rdl_eaddr fields contain the
first address after the end of the map entry and should therefore be
excluded.
MFC r262775:
Log the name of the file that we failed to open rather than an
uninitialized buffer.
MFC r265015:
Setting the IMOD value below 0x3F8 can cause IRQ lockups in the Intel
LynxPoint USB 3.0 controllers found in MacBookPro 2013's.