+ Linux kernel DT bindings maintainers, EBBR ML
On Thu, 30 Nov 2023 at 20:05, Tom Rini trini@konsulko.com wrote:
On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote:
On Wed, 29 Nov 2023 at 22:06, Neil Armstrong neil.armstrong@linaro.org wrote:
On 29/11/2023 16:34, Caleb Connolly wrote:
On 23/11/2023 07:04, Sumit Garg wrote:
On Wed, 22 Nov 2023 at 21:34, Caleb Connolly caleb.connolly@linaro.org wrote:
On 22/11/2023 14:27, Tom Rini wrote: > On Wed, Nov 22, 2023 at 07:44:09PM +0530, Sumit Garg wrote: >> On Wed, 22 Nov 2023 at 19:31, Tom Rini trini@konsulko.com wrote: >>> >>> On Wed, Nov 22, 2023 at 11:51:29AM +0530, Sumit Garg wrote: >>>> Hi Caleb, >>>> >>>> On Tue, 21 Nov 2023 at 22:39, Caleb Connolly caleb.connolly@linaro.org wrote: >>> [snip] >>>>> == DT loading == >>>>> >>>>> Previously, boards used the FDT blob embedded into U-Boot (via >>>>> OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary >>>>> bootloader, so we can instead rely on the first-stage bootloader to >>>>> populate some useful FDT properties for us (notably the /memory node and >>>>> KASLR seed) and fetch the DTB that it provides. Combined with the memory >>>>> map changes above, this let's us entirely avoid configuring the memory >>>>> map explicitly. >>>> >>>> Since with this change, we don't need to embed FDT blob in the u-boot >>>> binary, so I was thinking if we really need to import DTs from Linux >>>> for different platforms and then play a catchup game?
For now, yes.
But why? Is there any value added by larger u-boot specific DT (most of the nodes being unused by u-boot) than what currently u-boot supports? The more important part is to get alignment with Linux DT bindings. If you need to have memory/reserved-memory nodes in u-boot DT for generalization purposes then you should import those particular nodes only.
I've been thinking about and hacking on this for the last week or so, sorry for the delayed reply here.
The value is in preventing any of the existing bindings from regressing,
That is actually best addressed in Linux by checking the DTS against yaml DT bindings. We don't have that testing available in u-boot and only depend on careful reviews.
I would absolutely love for someone to make another attempt at updating our kbuild infrastucture so that we can run the validation targets.
Given that EBBR requires [1] the platform (firmware/bootloader) and not OS to supply the devicetree, it becomes evident that firmware/bootloaders import DTS from Linux kernel (where it is maintained).
But currently u-boot doesn't have a proper way to validate those DTS against DT bindings (maintained in Linux kernel). Although there are Devicetree schema tools available here [2], there isn't a versioned release package of DT bindings which one should use to validate DTS files.
@DT bindings maintainers,
Given the ease of maintenance of DT bindings within Linux kernel source tree, I don't have a specific objection there. But can we ease DTS testing for firmware/bootloader projects by providing a versioned release package for DT bindings? Or if someone else has a better idea here please feel free to chime in.
[1] https://arm-software.github.io/ebbr/#guiding-principles [2] https://github.com/devicetree-org/dt-schema
-Sumit
-- Tom
Hi Summit,
Here are additional elements that you may want to consider.
This topic should be thought of with « who provides what » question in mind.
For quite a long time, one single entity was providing secure firmware, firmware, boot loader (I think of Grub when I use this overloaded term), and OS. This explains why the Linux kernel community has been maintaining DT (not justifying it is now still a good model).
For Software Defined Vehicle and many other scenarios this supply chain is not working. In the context of this separation, OS/Hypervisor supplying any DTB is a non-sense. (Translated in real life: as a French driver, my DTB description of a car is that the steering wheel is on the left hand side. If I get on a UK car, I will complain that my hardware description does not match reality. Conclusion: better use DTB given from the platform!). If I am not mistaken Fedora IOT 39 does not come with any DTBs: that was a theme hinted by Peter Robinson a while ago (Peter you may want to comment on this).
My understanding is that SystemReady was proposed and developed to address such a different supply chain where: - the OS may be supplied by a party not controlling the underlying layers - have standard contract between OS and previous entities - The entity controlling the hardware is not an OS but a type-1 hypervisor
In all this context, the DT should be consumed by OSes (Linux, Zephyr, Eclipse ThreadX (donated by Microsoft), commercial ones…) and hypervisors. The "DT » passed to a Linux (be it equivalent to Dom0) may not be the definitive vision of the whole platform. You may want to talk with the System Device Tree folks. So there is no such a thing as « THE » device tree of the platform. There can be a DT for BL33 firmware, a DT for OS/Hypervisor, a DT for TrustZone (highly decorated with clocks and power nodes that are often irrelevant to BL33 and OS/Hypervisor).
The BL33 and OS/Hypervisor DTs location is not defined by EBBR but my view is that the OS/Hypervisor DT can be located in the HW_CONFIG section of a FIP (this section is made for holding the OS DT). The FIP can come from the SoC vendor, later updated by the Board vendor:
fiptool --hw-config <OS-DTB>
With a separate signing key.
So, you should take into account which markets are targeted by the SoC for which you posted your message. If it is traditional embedded, one-entity provides all. You can surely choose any scheme you want. If it is automotive and other markets where there will be separation in the firmware/OS/Hypervisor supply chain, then you should clearly attach the DT to Secure Firmware.
Cheers
FF
PS1: I see an analogy with Google project Trebble which set clear responsibilities in who can provide/modify what. Before it, it was the jungle and pushing a security fix required months of delays. Now a Google security fix can make its way to smartphones in matter of days. Constraining a little bit the Linux driver developers to what should they focus on (nice drivers and not hardware description) will just make things better. Failure to do so will just push for ACPI and its horrible complex, fragile virtual machine to push out DT from those markets... PS2: By « nice" drivers I mean, for instance, drivers that do not assume they are alone in the world and can do whatever they want with clocks that feed the device: they should use proper clock control such as SCMI (trouble for device assignment to a VM for instance).
Le 4 déc. 2023 à 06:32, Sumit Garg sumit.garg@linaro.org a écrit :
+ Linux kernel DT bindings maintainers, EBBR ML
On Thu, 30 Nov 2023 at 20:05, Tom Rini trini@konsulko.com wrote:
On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote: On Wed, 29 Nov 2023 at 22:06, Neil Armstrong neil.armstrong@linaro.org wrote:
On 29/11/2023 16:34, Caleb Connolly wrote:
On 23/11/2023 07:04, Sumit Garg wrote: On Wed, 22 Nov 2023 at 21:34, Caleb Connolly caleb.connolly@linaro.org wrote:
On 22/11/2023 14:27, Tom Rini wrote: On Wed, Nov 22, 2023 at 07:44:09PM +0530, Sumit Garg wrote: On Wed, 22 Nov 2023 at 19:31, Tom Rini trini@konsulko.com wrote:
On Wed, Nov 22, 2023 at 11:51:29AM +0530, Sumit Garg wrote: Hi Caleb,
On Tue, 21 Nov 2023 at 22:39, Caleb Connolly caleb.connolly@linaro.org wrote: [snip] == DT loading ==
Previously, boards used the FDT blob embedded into U-Boot (via OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary bootloader, so we can instead rely on the first-stage bootloader to populate some useful FDT properties for us (notably the /memory node and KASLR seed) and fetch the DTB that it provides. Combined with the memory map changes above, this let's us entirely avoid configuring the memory map explicitly.
Since with this change, we don't need to embed FDT blob in the u-boot binary, so I was thinking if we really need to import DTs from Linux for different platforms and then play a catchup game?
For now, yes.
But why? Is there any value added by larger u-boot specific DT (most of the nodes being unused by u-boot) than what currently u-boot supports? The more important part is to get alignment with Linux DT bindings. If you need to have memory/reserved-memory nodes in u-boot DT for generalization purposes then you should import those particular nodes only.
I've been thinking about and hacking on this for the last week or so, sorry for the delayed reply here.
The value is in preventing any of the existing bindings from regressing,
That is actually best addressed in Linux by checking the DTS against yaml DT bindings. We don't have that testing available in u-boot and only depend on careful reviews.
I would absolutely love for someone to make another attempt at updating our kbuild infrastucture so that we can run the validation targets.
Given that EBBR requires [1] the platform (firmware/bootloader) and not OS to supply the devicetree, it becomes evident that firmware/bootloaders import DTS from Linux kernel (where it is maintained).
But currently u-boot doesn't have a proper way to validate those DTS against DT bindings (maintained in Linux kernel). Although there are Devicetree schema tools available here [2], there isn't a versioned release package of DT bindings which one should use to validate DTS files.
@DT bindings maintainers,
Given the ease of maintenance of DT bindings within Linux kernel source tree, I don't have a specific objection there. But can we ease DTS testing for firmware/bootloader projects by providing a versioned release package for DT bindings? Or if someone else has a better idea here please feel free to chime in.
[1] https://arm-software.github.io/ebbr/#guiding-principles [2] https://github.com/devicetree-org/dt-schema
-Sumit
-- Tom _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote:
- Linux kernel DT bindings maintainers, EBBR ML
On Thu, 30 Nov 2023 at 20:05, Tom Rini trini@konsulko.com wrote:
On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote:
On Wed, 29 Nov 2023 at 22:06, Neil Armstrong neil.armstrong@linaro.org wrote:
I've been thinking about and hacking on this for the last week or so, sorry for the delayed reply here.
The value is in preventing any of the existing bindings from regressing,
That is actually best addressed in Linux by checking the DTS against yaml DT bindings. We don't have that testing available in u-boot and only depend on careful reviews.
I would absolutely love for someone to make another attempt at updating our kbuild infrastucture so that we can run the validation targets.
Given that EBBR requires [1] the platform (firmware/bootloader) and not OS to supply the devicetree, it becomes evident that firmware/bootloaders import DTS from Linux kernel (where it is maintained).
But currently u-boot doesn't have a proper way to validate those DTS against DT bindings (maintained in Linux kernel). Although there are Devicetree schema tools available here [2], there isn't a versioned release package of DT bindings which one should use to validate DTS files.
The kernel is regularly released in multiple forms (including git tags and tarball). Why isn't the kernel itself sufficient to be a versioned release of the DT bindings directory?
Daniel.
On Mon, 4 Dec 2023 at 16:30, Daniel Thompson daniel.thompson@linaro.org wrote:
On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote:
- Linux kernel DT bindings maintainers, EBBR ML
On Thu, 30 Nov 2023 at 20:05, Tom Rini trini@konsulko.com wrote:
On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote:
On Wed, 29 Nov 2023 at 22:06, Neil Armstrong neil.armstrong@linaro.org wrote:
I've been thinking about and hacking on this for the last week or so, sorry for the delayed reply here.
The value is in preventing any of the existing bindings from regressing,
That is actually best addressed in Linux by checking the DTS against yaml DT bindings. We don't have that testing available in u-boot and only depend on careful reviews.
I would absolutely love for someone to make another attempt at updating our kbuild infrastucture so that we can run the validation targets.
Given that EBBR requires [1] the platform (firmware/bootloader) and not OS to supply the devicetree, it becomes evident that firmware/bootloaders import DTS from Linux kernel (where it is maintained).
But currently u-boot doesn't have a proper way to validate those DTS against DT bindings (maintained in Linux kernel). Although there are Devicetree schema tools available here [2], there isn't a versioned release package of DT bindings which one should use to validate DTS files.
The kernel is regularly released in multiple forms (including git tags and tarball). Why isn't the kernel itself sufficient to be a versioned release of the DT bindings directory?
The Linux kernel may come in various forms (upstream vs stable vs vendor). It's difficult to decide from where the DT bindings should come from. Should they come from upstream or should they come from the kernel which is actually booted onto a particular device?
IOW, as of now which kernel version should u-boot pick up for DT validation checks?
If we can have a separate release cadence for DT bindings then the platform (firmware/bootloader) can attest the DTB against that. Later one should be able to boot any kernel with the DTB provided by platform.
-Sumit
Daniel.
Le 4 déc. 2023 à 14:25, Sumit Garg sumit.garg@linaro.org a écrit :
On Mon, 4 Dec 2023 at 16:30, Daniel Thompson daniel.thompson@linaro.org wrote:
On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote:
- Linux kernel DT bindings maintainers, EBBR ML
On Thu, 30 Nov 2023 at 20:05, Tom Rini trini@konsulko.com wrote:
On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote:
On Wed, 29 Nov 2023 at 22:06, Neil Armstrong neil.armstrong@linaro.org wrote:
> I've been thinking about and hacking on this for the last week or so, > sorry for the delayed reply here. > > The value is in preventing any of the existing bindings from regressing,
That is actually best addressed in Linux by checking the DTS against yaml DT bindings. We don't have that testing available in u-boot and only depend on careful reviews.
I would absolutely love for someone to make another attempt at updating our kbuild infrastucture so that we can run the validation targets.
Given that EBBR requires [1] the platform (firmware/bootloader) and not OS to supply the devicetree, it becomes evident that firmware/bootloaders import DTS from Linux kernel (where it is maintained).
But currently u-boot doesn't have a proper way to validate those DTS against DT bindings (maintained in Linux kernel). Although there are Devicetree schema tools available here [2], there isn't a versioned release package of DT bindings which one should use to validate DTS files.
The kernel is regularly released in multiple forms (including git tags and tarball). Why isn't the kernel itself sufficient to be a versioned release of the DT bindings directory?
The Linux kernel may come in various forms (upstream vs stable vs vendor). It's difficult to decide from where the DT bindings should come from. Should they come from upstream or should they come from the kernel which is actually booted onto a particular device?
Looks bad from organizing forward portability standpoint .
IOW, as of now which kernel version should u-boot pick up for DT validation checks?
If we can have a separate release cadence for DT bindings then the platform (firmware/bootloader) can attest the DTB against that. Later one should be able to boot any kernel with the DTB provided by platform.
That seems a very good step!
-Sumit
Daniel.
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
Le 4 déc. 2023 à 12:00, Daniel Thompson daniel.thompson@linaro.org a écrit :
On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote:
- Linux kernel DT bindings maintainers, EBBR ML
On Thu, 30 Nov 2023 at 20:05, Tom Rini trini@konsulko.com wrote: On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote:
On Wed, 29 Nov 2023 at 22:06, Neil Armstrong neil.armstrong@linaro.org wrote:
I've been thinking about and hacking on this for the last week or so, sorry for the delayed reply here.
The value is in preventing any of the existing bindings from regressing,
That is actually best addressed in Linux by checking the DTS against yaml DT bindings. We don't have that testing available in u-boot and only depend on careful reviews.
I would absolutely love for someone to make another attempt at updating our kbuild infrastucture so that we can run the validation targets.
Given that EBBR requires [1] the platform (firmware/bootloader) and not OS to supply the devicetree, it becomes evident that firmware/bootloaders import DTS from Linux kernel (where it is maintained).
But currently u-boot doesn't have a proper way to validate those DTS against DT bindings (maintained in Linux kernel). Although there are Devicetree schema tools available here [2], there isn't a versioned release package of DT bindings which one should use to validate DTS files.
The kernel is regularly released in multiple forms (including git tags and tarball). Why isn't the kernel itself sufficient to be a versioned release of the DT bindings directory?
The Linux kernel may not see all devices. For instance it could see a PCI port while the firmware sees a SERDES that is configured to match the board implementation and touting. The firmware shall be responsible to, statically or dynamically make those things available to the kernel. An OS distribution (not necessarily Linux) should not embedded all possible combinations and know all derived boards.
Daniel. _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
On Sun, Dec 3, 2023 at 11:33 PM Sumit Garg sumit.garg@linaro.org wrote:
- Linux kernel DT bindings maintainers, EBBR ML
On Thu, 30 Nov 2023 at 20:05, Tom Rini trini@konsulko.com wrote:
On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote:
On Wed, 29 Nov 2023 at 22:06, Neil Armstrong neil.armstrong@linaro.org wrote:
On 29/11/2023 16:34, Caleb Connolly wrote:
On 23/11/2023 07:04, Sumit Garg wrote:
On Wed, 22 Nov 2023 at 21:34, Caleb Connolly caleb.connolly@linaro.org wrote: > > > > On 22/11/2023 14:27, Tom Rini wrote: >> On Wed, Nov 22, 2023 at 07:44:09PM +0530, Sumit Garg wrote: >>> On Wed, 22 Nov 2023 at 19:31, Tom Rini trini@konsulko.com wrote: >>>> >>>> On Wed, Nov 22, 2023 at 11:51:29AM +0530, Sumit Garg wrote: >>>>> Hi Caleb, >>>>> >>>>> On Tue, 21 Nov 2023 at 22:39, Caleb Connolly caleb.connolly@linaro.org wrote: >>>> [snip] >>>>>> == DT loading == >>>>>> >>>>>> Previously, boards used the FDT blob embedded into U-Boot (via >>>>>> OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary >>>>>> bootloader, so we can instead rely on the first-stage bootloader to >>>>>> populate some useful FDT properties for us (notably the /memory node and >>>>>> KASLR seed) and fetch the DTB that it provides. Combined with the memory >>>>>> map changes above, this let's us entirely avoid configuring the memory >>>>>> map explicitly. >>>>> >>>>> Since with this change, we don't need to embed FDT blob in the u-boot >>>>> binary, so I was thinking if we really need to import DTs from Linux >>>>> for different platforms and then play a catchup game? > > For now, yes.
But why? Is there any value added by larger u-boot specific DT (most of the nodes being unused by u-boot) than what currently u-boot supports? The more important part is to get alignment with Linux DT bindings. If you need to have memory/reserved-memory nodes in u-boot DT for generalization purposes then you should import those particular nodes only.
I've been thinking about and hacking on this for the last week or so, sorry for the delayed reply here.
The value is in preventing any of the existing bindings from regressing,
That is actually best addressed in Linux by checking the DTS against yaml DT bindings. We don't have that testing available in u-boot and only depend on careful reviews.
I would absolutely love for someone to make another attempt at updating our kbuild infrastucture so that we can run the validation targets.
Given that EBBR requires [1] the platform (firmware/bootloader) and not OS to supply the devicetree, it becomes evident that firmware/bootloaders import DTS from Linux kernel (where it is maintained).
But currently u-boot doesn't have a proper way to validate those DTS against DT bindings (maintained in Linux kernel). Although there are Devicetree schema tools available here [2], there isn't a versioned release package of DT bindings which one should use to validate DTS files.
@DT bindings maintainers,
Given the ease of maintenance of DT bindings within Linux kernel source tree, I don't have a specific objection there. But can we ease DTS testing for firmware/bootloader projects by providing a versioned release package for DT bindings? Or if someone else has a better idea here please feel free to chime in.
This doesn't work for you?:
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi...
Note that I would like to revamp this repo to use some modern CI job, use git_filter_repo python module rather than git-filter-branch, and move to devicetree.org GH, but if projects aren't relying on this repo, I'm not motivated to do that work.
Rob
On Mon, 4 Dec 2023 at 22:31, Rob Herring robh+dt@kernel.org wrote:
On Sun, Dec 3, 2023 at 11:33 PM Sumit Garg sumit.garg@linaro.org wrote:
- Linux kernel DT bindings maintainers, EBBR ML
On Thu, 30 Nov 2023 at 20:05, Tom Rini trini@konsulko.com wrote:
On Thu, Nov 30, 2023 at 01:02:25PM +0530, Sumit Garg wrote:
On Wed, 29 Nov 2023 at 22:06, Neil Armstrong neil.armstrong@linaro.org wrote:
On 29/11/2023 16:34, Caleb Connolly wrote:
On 23/11/2023 07:04, Sumit Garg wrote: > On Wed, 22 Nov 2023 at 21:34, Caleb Connolly caleb.connolly@linaro.org wrote: >> >> >> >> On 22/11/2023 14:27, Tom Rini wrote: >>> On Wed, Nov 22, 2023 at 07:44:09PM +0530, Sumit Garg wrote: >>>> On Wed, 22 Nov 2023 at 19:31, Tom Rini trini@konsulko.com wrote: >>>>> >>>>> On Wed, Nov 22, 2023 at 11:51:29AM +0530, Sumit Garg wrote: >>>>>> Hi Caleb, >>>>>> >>>>>> On Tue, 21 Nov 2023 at 22:39, Caleb Connolly caleb.connolly@linaro.org wrote: >>>>> [snip] >>>>>>> == DT loading == >>>>>>> >>>>>>> Previously, boards used the FDT blob embedded into U-Boot (via >>>>>>> OF_SEPARATE). However, most Qualcomm boards run U-Boot as a secondary >>>>>>> bootloader, so we can instead rely on the first-stage bootloader to >>>>>>> populate some useful FDT properties for us (notably the /memory node and >>>>>>> KASLR seed) and fetch the DTB that it provides. Combined with the memory >>>>>>> map changes above, this let's us entirely avoid configuring the memory >>>>>>> map explicitly. >>>>>> >>>>>> Since with this change, we don't need to embed FDT blob in the u-boot >>>>>> binary, so I was thinking if we really need to import DTs from Linux >>>>>> for different platforms and then play a catchup game? >> >> For now, yes. > > But why? Is there any value added by larger u-boot specific DT (most > of the nodes being unused by u-boot) than what currently u-boot > supports? The more important part is to get alignment with Linux DT > bindings. If you need to have memory/reserved-memory nodes in u-boot > DT for generalization purposes then you should import those particular > nodes only.
I've been thinking about and hacking on this for the last week or so, sorry for the delayed reply here.
The value is in preventing any of the existing bindings from regressing,
That is actually best addressed in Linux by checking the DTS against yaml DT bindings. We don't have that testing available in u-boot and only depend on careful reviews.
I would absolutely love for someone to make another attempt at updating our kbuild infrastucture so that we can run the validation targets.
Given that EBBR requires [1] the platform (firmware/bootloader) and not OS to supply the devicetree, it becomes evident that firmware/bootloaders import DTS from Linux kernel (where it is maintained).
But currently u-boot doesn't have a proper way to validate those DTS against DT bindings (maintained in Linux kernel). Although there are Devicetree schema tools available here [2], there isn't a versioned release package of DT bindings which one should use to validate DTS files.
@DT bindings maintainers,
Given the ease of maintenance of DT bindings within Linux kernel source tree, I don't have a specific objection there. But can we ease DTS testing for firmware/bootloader projects by providing a versioned release package for DT bindings? Or if someone else has a better idea here please feel free to chime in.
This doesn't work for you?:
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasi...
Thanks, this is certainly a good step which I wasn't aware of. Further simplification can be done to decouple devicetree source files from DT bindings. AFAIK, DT bindings should be forwards and backwards compatible. So if you pick up DTS or DTB from any project tree (upstream kernel or stable kernel or u-boot) then DT schema validation would ensure that corresponding DTS or DTB doesn't regress the DT bindings.
Ideally, it should be more user/CI friendly if DT bindings can be easily installed alongside devicetree schema tools [1].
[1] https://github.com/devicetree-org/dt-schema
Note that I would like to revamp this repo to use some modern CI job, use git_filter_repo python module rather than git-filter-branch, and move to devicetree.org GH, but if projects aren't relying on this repo, I'm not motivated to do that work.
As Tom has shown interest in this, I think we should be able to add the DT validation checks during normal u-boot builds hidden behind a Makefile option (dtbs_check).
-Sumit
Rob
boot-architecture@lists.linaro.org
-
Daniel Thompson -
ff -
Rob Herring -
Sumit Garg