+ U-boot custodians list
On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
On 05/12/2023 08:13, Sumit Garg wrote:
@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.
Why?
I suppose you are already aware that Linux DTS files are a subset of what could be supported by devicetree schemas. There can be firmware/bootloader specific properties (one example being [1]) which Linux kernel can simply ignore. Will you be willing to add all of those DT properties to Linux DTS files and maintain them?
However, DT bindings are something which should be common, the hardware description of a device should be universal. IMO, splitting DT bindings alone would ease the compliance process for u-boot drivers in quite similar manner to Linux drivers.
[1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/bootp...
AFAIK, DT bindings should be forwards and backwards compatible.
The same with DTS.
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.
And why is this argument to decouple DTS from bindings?
See above.
Ideally, it should be more user/CI friendly if DT bindings can be easily installed alongside devicetree schema tools [1].
Does it mean you will work on this?
I am happy to collaboratively work with DT bindings maintainers and the u-boot community once we can reach a consensus on the above. Basically the main motive here is to validate DTS files present in the u-boot tree and be able to reliably pass them to whichever Linux kernel version you are trying to boot. IOW, make Linux distros to reliably boot with devicetree supplied by u-boot.
-Sumit
Best regards, Krzysztof
Le 5 déc. 2023 à 10:46, Sumit Garg sumit.garg@linaro.org a écrit :
+ U-boot custodians list
On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
On 05/12/2023 08:13, Sumit Garg wrote:
@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.
Why?
I suppose you are already aware that Linux DTS files are a subset of what could be supported by devicetree schemas. There can be firmware/bootloader specific properties (one example being [1]) which Linux kernel can simply ignore. Will you be willing to add all of those DT properties to Linux DTS files and maintain them?
A pre-existing effort to solve the same problem as [1] is System Device Tree, discussed in the context of Linaro supported OpenAMP project. It is not just about cherry picking devices that have bindings in Linux but also information about clock and power domains or devices that are not seen by Linux. It is obvious that the resulting bindings should be maintained upstream in the DT repo regardless of the communities adopted solution.
However, DT bindings are something which should be common, the hardware description of a device should be universal. IMO, splitting DT bindings alone would ease the compliance process for u-boot drivers in quite similar manner to Linux drivers.
I remember a discussion with ST on that topic related to Framebuffer. U-Boot can need a very different representation of the same device to use it while Linux need an in-depth description of all shaders and « stuff » (another reason why [1] is addressing only a portion of the problem) So even if there is a single frame buffer binding, there should be two (at least) conformance tests.
[1] https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/bootp...
AFAIK, DT bindings should be forwards and backwards compatible.
The same with DTS.
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.
And why is this argument to decouple DTS from bindings?
See above.
Ideally, it should be more user/CI friendly if DT bindings can be easily installed alongside devicetree schema tools [1].
Does it mean you will work on this?
I am happy to collaboratively work with DT bindings maintainers and the u-boot community once we can reach a consensus on the above. Basically the main motive here is to validate DTS files present in the u-boot tree and be able to reliably pass them to whichever Linux kernel version you are trying to boot. IOW, make Linux distros to reliably boot with devicetree supplied by u-boot.
-Sumit
Best regards, Krzysztof
boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
On Tue, Dec 05, 2023 at 10:36:28AM +0000, ff wrote:
Le 5 déc. 2023 à 10:46, Sumit Garg sumit.garg@linaro.org a écrit :
+ U-boot custodians list
On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
On 05/12/2023 08:13, Sumit Garg wrote:
@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.
Why?
I suppose you are already aware that Linux DTS files are a subset of what could be supported by devicetree schemas. There can be firmware/bootloader specific properties (one example being [1]) which Linux kernel can simply ignore. Will you be willing to add all of those DT properties to Linux DTS files and maintain them?
A pre-existing effort to solve the same problem as [1] is System Device Tree, discussed in the context of Linaro supported OpenAMP project. It is not just about cherry picking devices that have bindings in Linux but also information about clock and power domains or devices that are not seen by Linux. It is obvious that the resulting bindings should be maintained upstream in the DT repo regardless of the communities adopted solution.
This seems to be artificially linking two topics: system DT and DT schema validation within u-boot. They are somewhat related but one of not a precondition of the other.
However, DT bindings are something which should be common, the hardware description of a device should be universal. IMO, splitting DT bindings alone would ease the compliance process for u-boot drivers in quite similar manner to Linux drivers.
I remember a discussion with ST on that topic related to Framebuffer. U-Boot can need a very different representation of the same device to use it while Linux need an in-depth description of all shaders and « stuff » (another reason why [1] is addressing only a portion of the problem) So even if there is a single frame buffer binding, there should be two (at least) conformance tests.
I don't follow this, for two reasons.
1. DT describes the hardware, not how it is driven. Having a relationship between u-boot and linux DTs with different representation would imply that the hardware changes between u-boot and the kernel.
2. Even if we were to accept that there must be two device tree instances (beyond transient workarounds for missing features), why would there need to be two conformance tests rather than one conformance test run on the two DTs?
Daniel.
Le 5 déc. 2023 à 13:48, Daniel Thompson daniel.thompson@linaro.org a écrit :
On Tue, Dec 05, 2023 at 10:36:28AM +0000, ff wrote: Le 5 déc. 2023 à 10:46, Sumit Garg sumit.garg@linaro.org a écrit :
+ U-boot custodians list
On Tue, 5 Dec 2023 at 12:58, Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
On 05/12/2023 08:13, Sumit Garg wrote: @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.
Why?
I suppose you are already aware that Linux DTS files are a subset of what could be supported by devicetree schemas. There can be firmware/bootloader specific properties (one example being [1]) which Linux kernel can simply ignore. Will you be willing to add all of those DT properties to Linux DTS files and maintain them?
A pre-existing effort to solve the same problem as [1] is System Device Tree, discussed in the context of Linaro supported OpenAMP project. It is not just about cherry picking devices that have bindings in Linux but also information about clock and power domains or devices that are not seen by Linux. It is obvious that the resulting bindings should be maintained upstream in the DT repo regardless of the communities adopted solution.
This seems to be artificially linking two topics: system DT and DT schema validation within u-boot. They are somewhat related but one of not a precondition of the other.
Agreed. I am mentioning this because it relates to binding and conformance testing: DT consumers such as OP-TEE , OSes and hypervisors should be considered equally as U-Boot and Linux. Hence it makes sense that all those are decoupled from any consumer and live « standalone ».
However, DT bindings are something which should be common, the hardware description of a device should be universal. IMO, splitting DT bindings alone would ease the compliance process for u-boot drivers in quite similar manner to Linux drivers.
I remember a discussion with ST on that topic related to Framebuffer. U-Boot can need a very different representation of the same device to use it while Linux need an in-depth description of all shaders and « stuff » (another reason why [1] is addressing only a portion of the problem) So even if there is a single frame buffer binding, there should be two (at least) conformance tests.
I don't follow this, for two reasons.
1. DT describes the hardware, not how it is driven. Having a relationship between u-boot and linux DTs with different representation would imply that the hardware changes between u-boot and the kernel.
2. Even if we were to accept that there must be two device tree instances (beyond transient workarounds for missing features), why would there need to be two conformance tests rather than one conformance test run on the two DTs?
Let’s say U-Boot only cares and use legacy SGVA frame buffer, while Linux community only cares and use the full fledged GPU. You end-up with two communities maintaining the conformance test part it cares/need. Isn’t splitting the tests responsibilities a way to get people feel more « empowered » and thus more active?
Daniel.
boot-architecture@lists.linaro.org
-
Daniel Thompson -
ff -
Sumit Garg