obtain the FDT from UEFI?

[Mis012]

I'm not familiar with Windows driver development, so I'm not sure if there is something preventing this, but presumably the ideal way to obtain the FDT would be from UEFI as described here: https://github.com/ARM-software/ebbr/commit/d1a413d1530d0996fa4900b3fb02ad6d8009b588 .

https://github.com/aarch64-laptops/edk2/tree/dtbloader-app can be used to augment an existing uefi implementation with the ability to pass an FDT in this way.

Note: the spec states that only one of ACPI/FDT should be passed, which might conflict with "Hide certain devices/nodes that are not applicable in PnP context, such as Interrupt Controller, Architectural Timer and PSCI information (they can be trivially translated to static ACPI tables)", but hopefully the triviality of the translation would allow for doing it programmatically as opposed to having the firmware pass pre-translated tables.

[steev]

Wouldn't that assume that the FDT is in the UEFI? Ideally, this would be the case, but it isn't always c.f. Flex 5G or C630 devices, which do not have any fdt in their uefi bios, and also are EOL and not getting any sort of updates anymore.

[Mis012]

I only just noticed that https://github.com/aarch64-laptops/edk2/tree/dtbloader-app is stored inside an edk2 tree, which might lead you to believe you need to bundle it inside the UEFI, but it's just an EFI driver, you can see the Installation section in the README to see how to install it on any device with UEFI

[steev]

Yes, but if the FDT is not bundled in, where is it supposed to load it from? Ideally you would get the FDT from UEFI, but if it doesn't exist in there, then you are SOL with what you are suggesting.

[Mis012]

you need to put it in the right place on the ESP yourself, but the point is that from the perspective of this project, it's much cleaner to just ask UEFI for the FDT, and not care about how UEFI itself gets it, than for this project itself to have to invent it's own non-standard way of obtaining the FDT (which would obviously not work ANYWHERE without manual intervention)

[Mis012]

also, my understanding is that this project is made for use in cases where there are no ACPI tables present, so for example chromebooks which usually have mainline Linux support including a nice working devicetree, whether that exact devicetree is passed by the stock fw or a downstream-ish one is passed instead isn't particularly relevant because afaik anyone wanting to run Windows on that device would port EDKII to it anyway (the stock fw is not EDKII for chromebooks, and in the case of phones even though it is EDKII it's not typically possible to change the bootloader or make it not exit boot services before booting the OS, so people who wish to run windows on said device will chainload their own EDKII)