On Wed, 5 Jun 2019 at 00:41, Tom Rini trini@konsulko.com wrote:
...
It depends on what you mean by "OS provided". The DTS files come from the Linux Kernel sources, full stop.
That is the mistake we should try to fix.
We have DT bindings, which define the contract between the OS on one side, and the platform on the other side. This means it is the platform's job to present a DT description that adheres to those [stable] bindings.
Today's development model of developing DT bindings in lockstep with the drivers, and then bundling DT files with the OS is completely unsustainable, since it doesn't scale, and it demonstrably results in DT bindings that get modified without any regard for devices that are already in the field (MacchiatoBin is a good example).
So it doesn't really matter where the kernel *sources* come from, as long as the platform provides its own DT, which does not change just because the kernel changes.
It is already defined how the platform provides this DT on a UEFI system, i.e., via a configuration table with a known GUID. How the firmware popiulates this memory is an implementation detail: if it wants to load it from a signed file in the file system, that is fine, as long as it is not the OS providing this file to the firmware.
That doesn't mean they're embedded within the kernel image. They're usually going to be pulled from the filesystem.
-- Tom
On Wed, 5 Jun 2019 at 07:36, Ard Biesheuvel ard.biesheuvel@linaro.org wrote:
On Wed, 5 Jun 2019 at 00:41, Tom Rini trini@konsulko.com wrote:
...
It depends on what you mean by "OS provided". The DTS files come from the Linux Kernel sources, full stop.
That is the mistake we should try to fix.
We have DT bindings, which define the contract between the OS on one side, and the platform on the other side. This means it is the platform's job to present a DT description that adheres to those [stable] bindings.
Today's development model of developing DT bindings in lockstep with the drivers, and then bundling DT files with the OS is completely unsustainable, since it doesn't scale, and it demonstrably results in DT bindings that get modified without any regard for devices that are already in the field (MacchiatoBin is a good example).
So it doesn't really matter where the kernel *sources* come from, as long as the platform provides its own DT, which does not change just because the kernel changes.
It is already defined how the platform provides this DT on a UEFI system, i.e., via a configuration table with a known GUID. How the firmware popiulates this memory is an implementation detail: if it wants to load it from a signed file in the file system, that is fine, as long as it is not the OS providing this file to the firmware.
I agree, people seem to be conflating where DT is stored in source control over where it should be supplied to OS.
Just because the DT is in linux kernel git does not mean you can't build it into the u-boot for your board.
In fact I bet u-boot maintainer would love patches for updates ;-)
Graeme
On Wed, Jun 05, 2019 at 08:36:25AM +0200, Ard Biesheuvel wrote:
On Wed, 5 Jun 2019 at 00:41, Tom Rini trini@konsulko.com wrote:
...
It depends on what you mean by "OS provided". The DTS files come from the Linux Kernel sources, full stop.
That is the mistake we should try to fix.
We have DT bindings, which define the contract between the OS on one side, and the platform on the other side. This means it is the platform's job to present a DT description that adheres to those [stable] bindings.
Today's development model of developing DT bindings in lockstep with the drivers, and then bundling DT files with the OS is completely unsustainable, since it doesn't scale, and it demonstrably results in DT bindings that get modified without any regard for devices that are already in the field (MacchiatoBin is a good example).
Nod. We're *way* past the time where this should have stopped. How on earth do we get to common DT useful for all bootloaders, OSes (etc.) if people still consider the bundled, changing sources in the Linux tree to be canonical?
boot-architecture@lists.linaro.org
-
Ard Biesheuvel -
Graeme Gregory -
Steve McIntyre