On most embedded Linux products the kernel carries the description of the board. Under Arm's SystemReady Devicetree band it does not: the platform firmware supplies the device tree, the kernel arrives as an ordinary UEFI application, and firmware update stops being a product choice and becomes a requirement. This is real and already shipping, but it is partial. The compatibility rules that would make a firmware-provided device tree durable across kernel versions are unfinished, and EBBR says so about itself.
If you build embedded Linux products, the device tree is something you keep in the kernel. The source sits under arch/arm64/boot/dts/, the DTB is built alongside the kernel, and when the hardware changes you patch the kernel tree. On a growing set of Arm platforms that is no longer where it lives: the firmware owns the description of the board, and the kernel is handed one at boot like any other UEFI payload. A firmware-provided device tree is not a proposal. It is what the Arm SystemReady Devicetree band already requires of certified platforms.
This is not happening everywhere at once, and nothing forces a shipping product to move. But the direction is set by a certification programme with published requirements rather than by a trend, which makes it a planning question rather than a prediction. And the reason to pay attention is commercial rather than architectural: it changes which team owns the board description, which release cadence it follows, what your update mechanism has to do, and who owns a hardware-description defect when a later kernel release fails on the same board.
