In UEFI mode expose the SMBIOS anchor base address via kenv so the kernel
etc. can find out where the SMBIOS entry point is located. In pure
UEFI mode the BIOS is not mapped into the standard address space so the
SMBIOS table might not appear between 0xf0000 and 0xfffff. The
UEFI environment can report this the location of the anchor. If it is
reported then expose it as hint.smbios.0.mem. This can then be used
by other tools. However, we should make smbios(4) useful and have it
take this value and provide accesor function so ipmi(4) etc. don't
have to parse and figure things about the SMBIOS table. I have some
simple patches to smbios(4) to expose this address as sysctl and
for ipmi(4) to get the base address. However, the real fix is to
have ipmi(4) ask smbios(4) for what it wants and have smbios(4)
parse it out and return it. This would make smbios(4) useful and reduce
duplicated code. If this address doesn't point to the anchor then
finding SMBIOS info. will fail as if this didn't exist. So there should
be no harm.

With this change and the following hack, dmidecode works on a bunch of
UEFI machines that I tested:

if kenv hint.smbios.0.mem > /dev/null
then
      mkdir -p /sys/firmware/efi
      mount -t tmpfs -o size=8k tmpfs /sys/firmware/efi
      echo "SMBIOS=`kenv hint.smbios.0.mem`" > /sys/firmware/efi/systab
fi

Linux exposes this information via the /sys/firmware/efi/systab file which
dmidecode looks at. We should update dmidecode to do this the FreeBSD
way when we determine what that is!

Reviewed by: jhb