Page MenuHomeFreeBSD

libfdt: Make an internal FDT library available
AcceptedPublic

Authored by markj on Jul 12 2023, 1:52 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Feb 8, 12:36 PM
Unknown Object (File)
Dec 11 2023, 4:30 AM
Unknown Object (File)
Nov 26 2023, 2:49 AM
Unknown Object (File)
Nov 21 2023, 4:00 AM
Unknown Object (File)
Nov 21 2023, 3:33 AM
Unknown Object (File)
Nov 20 2023, 9:50 PM
Unknown Object (File)
Nov 16 2023, 7:29 PM
Unknown Object (File)
Oct 22 2023, 1:47 AM

Details

Reviewers
jhb
corvink
andrew
Summary

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

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 52587
Build 49478: arc lint + arc unit

Event Timeline

markj requested review of this revision.Jul 12 2023, 1:52 PM
This revision is now accepted and ready to land.Jul 12 2023, 6:46 PM

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

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.