Support loading devicetree from target ESP

[craftyguy]

When u-boot is EFI booting from some other ESP (e.g. on external media), it would be nice if it was able to find and use a device tree from that ESP. There's precedent for this upstream in u-boot: https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-snapdragon/board.c?ref_type=heads#L389

Currently the UEFI-only image from the Asahi installer is from Dec. 2023, and the dtbs in the stage 2 m1n1+u-boot loader do not work for me on my M2 macbook with recent Asahi linux kernels. This means that I'm unable to boot from the ESP created by the Asahi installer. If u-boot could load devicetrees from the ESP on the external media I'm booting from, then it wouldn't matter that the devicetrees in the UEFI-only ESP image are outdated.

[kcxt]

if the compatible properties can be consistently converted to filenames this should work, and i think that's the case here?

[jannau]

Yes, creating the path should be:

soc = ofnode_read_string_index(of_root, "compatible", 1).split(',')[1];
device = ofnode_read_string_index(of_root, "compatible", 0).split(',')[1];
dtb_path = f"apple/{soc}-{device}.dtb"

The problem is that all dynamic information from m1n1's kboot.c, kboot_atc.c and kboot_gpu.c would have to be transferred from the firmware provided DT to the DT u-boot loads. The fixups from kboot_t6020_compat.c could be skipped as the DT would match the kernel.

We decided not to maintain this code in two places. This follows the principle that the device tree is supposed to come from firmware. I rather ensure that the uefi-only boot.bin is kept up to date.

I'm inclined to close this as not planned.