libfdt: Make an internal FDT library available

[markj]

Summary

This will be used by bhyve to build a device tree.

[andrew]

I'd prefer we pass ACPI tables to the guest. FDT support was only ever a hack to get something working.

[markj]

In D40994#933420, @andrew wrote:

I'd prefer we pass ACPI tables to the guest. FDT support was only ever a hack to get something working.

From my reading of QEMU, it always creates an FDT, then optionally creates ACPI tables and exposes them to the guest via fwcfg. I also had a look at EDK2's ArmVirtPkg, which I presume is what we'd want to use as the platform firmware when booting from ACPI (I don't really understand how Ovmf and ArmVirt overlap). From what I can see, ArmVirtPkg assumes that a FDT is present: the first thing that the module entry point is save a pointer to the FDT to copy later. The FDT is exposed to the rest of the firmware using a UEFI protocol, and fwcfg nodes are used to decide whether to pass ACPI tables to the guest.

So, assuming that we want to target edk2 on arm64, I think we probably need to keep the FDT builder even if bhyve is configured to supply ACPI tables to the guest.