+ 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