On Tue, Sep 29, 2026 at 00:10:05 +0100, Heinrich Schuchardt wrote: Hi Heinrich, > Why should a "firmware-owned" device-tree live on an OS owned block > device? > > This lack of separation of duties is bound to lead to total failure > once I reinstall my OS which typically starts with repartitioning the > block device. > > Please, put anything that is firmware owned on a storage device that > is firmware owned and not OS owned.
I mean, we are really not enforcing anything here. The block backend does not require the firmware DT to reside on the OS device: the source explicitly references its backing device, independently of where the OS boots from. That said, you are right that sharing an OS-repartitionable disk leaves the firmware partitions vulnerable, but my idea is that the platform must arrange storage ownership/protection so that replacing the OS does not destroy firmware data. As I said in my previous reply to E, think about booting an OS image from SD while the DT is shipped at provision time on the eMMC. > The topic of constructing a firmware device-tree seems to be > completely independent of the way the boot binary is invoked. > > The easiest way to make such a device-tree available for other boot > methods would be providing an environment variable that can be used > instead of $fdtcontroladdr. > > The construction should only occur once and not repeatedly for each of > the EFI binaries that is executed. ok, not in order: DT construction is already independent of EFI through firmware_fdt_load(), the EFI paths are its first consumers. Successful loading, verification and assembly are cached, so they repeat only when the partition/configuration selectors change. Now about the new environment variable, that is something I thought about and I'm open to it if the general consensus is that it is a better way forward for this problem. The idea would be that we introduce a preparation step that loads `fdt.itb`, verifies it, applies overlays, and publishes the resulting address in an environment variable. The preparation step would also return a status, so callers can distinguish an absent source from a configured source that failed to load or verify. I'm probably missing 100 complications but this is the basic idea, just to check if we are on the same page about this. Thanks, -- Carlo Caione
