On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
On 05/12/2023 10:45, Sumit Garg wrote:
- 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?
We already added them and we already maintain them. DTS describes the hardware, not the OS-subset of the hardware.
Let look at some numbers if your statement is justified or not for the example I gave:
u-boot$ git grep -nr bootph-* arch/arm* | wc -l 4079
linux$ git grep -nr bootph-* arch/arm* | wc -l 267
It looks like there is always going to be a catch up game regarding DT properties which either Linux kernel or u-boot or any other firmware/bootloader project don't care about.
However, DT bindings are something which should be common, the hardware description of a device should be universal. IMO, splitting
Both DT bindings and DTS should be common. I don't see the difference.
If we really care about DTS to be common then the contribution model has to change where there is a single repo hosting DT bindings and DTS. All other projects whether it is Linux kernel or u-boot or any other OS/firmware/bootloader are just consuming DTS files from that single repo. I suppose this is something that Linux DT maintainers have objected to in the past for ease of maintenance. I am not sure if you folks are willing to change that stance.
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.
It's not really explained there. You can pick up DTS from any project and validate it against the repo Rob mentioned or against kernel. Whether DTS is in that repo or not, does not matter for your validation.
It is similar to your earlier argument to use the whole mainline kernel repo. What is the real benefit to keep DT bindings and DTS together when every project has to maintain a copy of DTS in its own source tree? It will be just a source of confusion for developers: - One DTS coming from devicetree-rebasing repo - One DTS coming from local project
-Sumit
On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg sumit.garg@linaro.org wrote:
On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
On 05/12/2023 10:45, Sumit Garg wrote:
- 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?
We already added them and we already maintain them. DTS describes the hardware, not the OS-subset of the hardware.
Let look at some numbers if your statement is justified or not for the example I gave:
u-boot$ git grep -nr bootph-* arch/arm* | wc -l 4079
linux$ git grep -nr bootph-* arch/arm* | wc -l 267
I have no control over whether anyone has submitted the other 3812 instances.
It looks like there is always going to be a catch up game regarding DT properties which either Linux kernel or u-boot or any other firmware/bootloader project don't care about.
As long as dts files in u-boot are manually sync'ed, yes. That is the problem and it doesn't matter if we have a standalone repository or not.
If you want to move in that direction, start automating what u-boot imports. You need to do that for bindings if you want to run validation, so why not dts files too?
However, DT bindings are something which should be common, the hardware description of a device should be universal. IMO, splitting
Both DT bindings and DTS should be common. I don't see the difference.
If we really care about DTS to be common then the contribution model has to change where there is a single repo hosting DT bindings and DTS. All other projects whether it is Linux kernel or u-boot or any other OS/firmware/bootloader are just consuming DTS files from that single repo.
Really, only the kernel and u-boot matter. No, I don't mean I don't care about other projects, but those are the 2 with the widest h/w support by far and which have a major effort to sync copies of dts files in both projects. The rest are just noise in terms of this problem.
I suppose this is something that Linux DT maintainers have objected to in the past for ease of maintenance. I am not sure if you folks are willing to change that stance.
The issue is no one steps up to help maintain such a repository while there is lots of review and maintainer work on what goes into the kernel tree. I'm happy to direct my binding review attention to wherever the majority of the bindings go. But the work on the DTS side is mostly SoC tree maintainers and sub-maintainers.
Assume for a minute we have this standalone repo. What happens next? We start with an empty repo and then merge and move platforms 1 by 1? How many years will that take? What do we do with platforms no one is interested in moving? Or do we start with devicetree-rebasing instead (That was the plan at one time) and sync u-boot back to that?
All the work needed to get u-boot and kernel dts files in sync has virtually no dependency on a standalone repo. If the dts files aren't already kept in sync, someone has to figure the differences and eliminate them. Maybe some platforms are in good shape, but it is still a manual process. Fix that part, because a standalone repo does nothing for you until you do.
DT bindings alone would ease the compliance process for u-boot drivers in quite similar manner to Linux drivers.
There's no compliance of drivers really beyond checking if compatible strings used by drivers have a schema.
Why is extracting the bindings out a problem? SystemReady has no issue doing just that for its compliance test.
Rob
Le 6 déc. 2023 à 21:42, Rob Herring robh+dt@kernel.org a écrit :
On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg sumit.garg@linaro.org wrote:
On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
On 05/12/2023 10:45, Sumit Garg wrote:
- 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?
We already added them and we already maintain them. DTS describes the hardware, not the OS-subset of the hardware.
Let look at some numbers if your statement is justified or not for the example I gave:
u-boot$ git grep -nr bootph-* arch/arm* | wc -l 4079
linux$ git grep -nr bootph-* arch/arm* | wc -l 267
I have no control over whether anyone has submitted the other 3812 instances.
It looks like there is always going to be a catch up game regarding DT properties which either Linux kernel or u-boot or any other firmware/bootloader project don't care about.
As long as dts files in u-boot are manually sync'ed, yes. That is the problem and it doesn't matter if we have a standalone repository or not.
If you want to move in that direction, start automating what u-boot imports. You need to do that for bindings if you want to run validation, so why not dts files too?
However, DT bindings are something which should be common, the hardware description of a device should be universal. IMO, splitting
Both DT bindings and DTS should be common. I don't see the difference.
If we really care about DTS to be common then the contribution model has to change where there is a single repo hosting DT bindings and DTS. All other projects whether it is Linux kernel or u-boot or any other OS/firmware/bootloader are just consuming DTS files from that single repo.
Really, only the kernel and u-boot matter. No, I don't mean I don't care about other projects, but those are the 2 with the widest h/w support by far and which have a major effort to sync copies of dts files in both projects. The rest are just noise in terms of this problem.
I suppose this is something that Linux DT maintainers have objected to in the past for ease of maintenance. I am not sure if you folks are willing to change that stance.
The issue is no one steps up to help maintain such a repository while there is lots of review and maintainer work on what goes into the kernel tree. I'm happy to direct my binding review attention to wherever the majority of the bindings go. But the work on the DTS side is mostly SoC tree maintainers and sub-maintainers.
Assume for a minute we have this standalone repo. What happens next? We start with an empty repo and then merge and move platforms 1 by 1?
What about leveraging SystemReady-IR compliant board maintainers and start with a core of motivated people ?
How many years will that take?
Should all platforms following that organization be a goal?
What do we do with platforms no one is interested in moving? Or do we start with devicetree-rebasing instead (That was the plan at one time) and sync u-boot back to that? All the work needed to get u-boot and kernel dts files in sync has virtually no dependency on a standalone repo. If the dts files aren't already kept in sync, someone has to figure the differences and eliminate them. Maybe some platforms are in good shape, but it is still a manual process. Fix that part, because a standalone repo does nothing for you until you do.
DT bindings alone would ease the compliance process for u-boot drivers in quite similar manner to Linux drivers.
There's no compliance of drivers really beyond checking if compatible strings used by drivers have a schema.
Why is extracting the bindings out a problem? SystemReady has no issue doing just that for its compliance test.
Rob _______________________________________________ boot-architecture mailing list -- boot-architecture@lists.linaro.org To unsubscribe send an email to boot-architecture-leave@lists.linaro.org
On Thu, 7 Dec 2023 at 02:12, Rob Herring robh+dt@kernel.org wrote:
On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg sumit.garg@linaro.org wrote:
On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
On 05/12/2023 10:45, Sumit Garg wrote:
- 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?
We already added them and we already maintain them. DTS describes the hardware, not the OS-subset of the hardware.
Let look at some numbers if your statement is justified or not for the example I gave:
u-boot$ git grep -nr bootph-* arch/arm* | wc -l 4079
linux$ git grep -nr bootph-* arch/arm* | wc -l 267
I have no control over whether anyone has submitted the other 3812 instances.
It looks like there is always going to be a catch up game regarding DT properties which either Linux kernel or u-boot or any other firmware/bootloader project don't care about.
As long as dts files in u-boot are manually sync'ed, yes. That is the problem and it doesn't matter if we have a standalone repository or not.
If you want to move in that direction, start automating what u-boot imports. You need to do that for bindings if you want to run validation, so why not dts files too?
However, DT bindings are something which should be common, the hardware description of a device should be universal. IMO, splitting
Both DT bindings and DTS should be common. I don't see the difference.
If we really care about DTS to be common then the contribution model has to change where there is a single repo hosting DT bindings and DTS. All other projects whether it is Linux kernel or u-boot or any other OS/firmware/bootloader are just consuming DTS files from that single repo.
Really, only the kernel and u-boot matter. No, I don't mean I don't care about other projects, but those are the 2 with the widest h/w support by far and which have a major effort to sync copies of dts files in both projects. The rest are just noise in terms of this problem.
I suppose this is something that Linux DT maintainers have objected to in the past for ease of maintenance. I am not sure if you folks are willing to change that stance.
The issue is no one steps up to help maintain such a repository while there is lots of review and maintainer work on what goes into the kernel tree. I'm happy to direct my binding review attention to wherever the majority of the bindings go. But the work on the DTS side is mostly SoC tree maintainers and sub-maintainers.
Assume for a minute we have this standalone repo. What happens next? We start with an empty repo and then merge and move platforms 1 by 1? How many years will that take? What do we do with platforms no one is interested in moving? Or do we start with devicetree-rebasing instead (That was the plan at one time) and sync u-boot back to that?
Thanks Rob for sharing further insights. So I have given this approach a try here [1]. Lets see how it can serve u-boot community needs and thereby bring DT bindings compliance in u-boot.
U-boot community, maintainers, custodians,
Feel free to play out with this DT bindings compliance idea here [1] and let us know if this approach helps to reduce DT maintainence burden alongside increasing compliance.
[1] https://github.com/u-boot/u-boot/pull/451
-Sumit
All the work needed to get u-boot and kernel dts files in sync has virtually no dependency on a standalone repo. If the dts files aren't already kept in sync, someone has to figure the differences and eliminate them. Maybe some platforms are in good shape, but it is still a manual process. Fix that part, because a standalone repo does nothing for you until you do.
DT bindings alone would ease the compliance process for u-boot drivers in quite similar manner to Linux drivers.
There's no compliance of drivers really beyond checking if compatible strings used by drivers have a schema.
Why is extracting the bindings out a problem? SystemReady has no issue doing just that for its compliance test.
Rob
On Thu, Dec 7, 2023 at 2:08 AM ff ff@shokubai.tech wrote:
Le 6 déc. 2023 à 21:42, Rob Herring robh+dt@kernel.org a écrit :
On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg sumit.garg@linaro.org wrote:
On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
On 05/12/2023 10:45, Sumit Garg wrote:
- 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?
We already added them and we already maintain them. DTS describes the hardware, not the OS-subset of the hardware.
Let look at some numbers if your statement is justified or not for the example I gave:
u-boot$ git grep -nr bootph-* arch/arm* | wc -l 4079
linux$ git grep -nr bootph-* arch/arm* | wc -l 267
I have no control over whether anyone has submitted the other 3812 instances.
It looks like there is always going to be a catch up game regarding DT properties which either Linux kernel or u-boot or any other firmware/bootloader project don't care about.
As long as dts files in u-boot are manually sync'ed, yes. That is the problem and it doesn't matter if we have a standalone repository or not.
If you want to move in that direction, start automating what u-boot imports. You need to do that for bindings if you want to run validation, so why not dts files too?
However, DT bindings are something which should be common, the hardware description of a device should be universal. IMO, splitting
Both DT bindings and DTS should be common. I don't see the difference.
If we really care about DTS to be common then the contribution model has to change where there is a single repo hosting DT bindings and DTS. All other projects whether it is Linux kernel or u-boot or any other OS/firmware/bootloader are just consuming DTS files from that single repo.
Really, only the kernel and u-boot matter. No, I don't mean I don't care about other projects, but those are the 2 with the widest h/w support by far and which have a major effort to sync copies of dts files in both projects. The rest are just noise in terms of this problem.
I suppose this is something that Linux DT maintainers have objected to in the past for ease of maintenance. I am not sure if you folks are willing to change that stance.
The issue is no one steps up to help maintain such a repository while there is lots of review and maintainer work on what goes into the kernel tree. I'm happy to direct my binding review attention to wherever the majority of the bindings go. But the work on the DTS side is mostly SoC tree maintainers and sub-maintainers.
Assume for a minute we have this standalone repo. What happens next? We start with an empty repo and then merge and move platforms 1 by 1?
What about leveraging SystemReady-IR compliant board maintainers and start with a core of motivated people ?
I think there are 2 ATM. Synquacer and i.MX8 variants. Synquacer only has a DT in u-boot, so not really anything to do there. I'm pretty sure the certified DTBs for i.MX8 don't match what's in u-boot or the kernel tree. Hopefully, it's just a subset, but still, there's a gap. I don't know that there is motivation there either.
Note that SystemReady currently only requires every node with 'compatible' have a schema. It does not yet require no schema warnings. If we went with a 1 by 1 approach, I would push that platforms have to be free of warnings.
How many years will that take?
Should all platforms following that organization be a goal?
You mean should all platforms be moved? Absolutely. I don't think we want to solve the problem of having DTS files in 2 places by creating a 3rd place.
I don't really think 1 by 1 is the right approach. I was just enumerating how this could work. It's not that useful to say we need a standalone repo without working thru the logistics of how exactly that will work.
Rob
Le 7 déc. 2023 à 19:51, Rob Herring robh+dt@kernel.org a écrit :
On Thu, Dec 7, 2023 at 2:08 AM ff ff@shokubai.tech wrote:
Le 6 déc. 2023 à 21:42, Rob Herring robh+dt@kernel.org a écrit :
On Tue, Dec 5, 2023 at 11:05 PM Sumit Garg sumit.garg@linaro.org wrote:
On Tue, 5 Dec 2023 at 15:39, Krzysztof Kozlowski krzysztof.kozlowski@linaro.org wrote:
On 05/12/2023 10:45, Sumit Garg wrote: + 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?
We already added them and we already maintain them. DTS describes the hardware, not the OS-subset of the hardware.
Let look at some numbers if your statement is justified or not for the example I gave:
u-boot$ git grep -nr bootph-* arch/arm* | wc -l 4079
linux$ git grep -nr bootph-* arch/arm* | wc -l 267
I have no control over whether anyone has submitted the other 3812 instances.
It looks like there is always going to be a catch up game regarding DT properties which either Linux kernel or u-boot or any other firmware/bootloader project don't care about.
As long as dts files in u-boot are manually sync'ed, yes. That is the problem and it doesn't matter if we have a standalone repository or not.
If you want to move in that direction, start automating what u-boot imports. You need to do that for bindings if you want to run validation, so why not dts files too?
However, DT bindings are something which should be common, the hardware description of a device should be universal. IMO, splitting
Both DT bindings and DTS should be common. I don't see the difference.
If we really care about DTS to be common then the contribution model has to change where there is a single repo hosting DT bindings and DTS. All other projects whether it is Linux kernel or u-boot or any other OS/firmware/bootloader are just consuming DTS files from that single repo.
Really, only the kernel and u-boot matter. No, I don't mean I don't care about other projects, but those are the 2 with the widest h/w support by far and which have a major effort to sync copies of dts files in both projects. The rest are just noise in terms of this problem.
I suppose this is something that Linux DT maintainers have objected to in the past for ease of maintenance. I am not sure if you folks are willing to change that stance.
The issue is no one steps up to help maintain such a repository while there is lots of review and maintainer work on what goes into the kernel tree. I'm happy to direct my binding review attention to wherever the majority of the bindings go. But the work on the DTS side is mostly SoC tree maintainers and sub-maintainers.
Assume for a minute we have this standalone repo. What happens next? We start with an empty repo and then merge and move platforms 1 by 1?
What about leveraging SystemReady-IR compliant board maintainers and start with a core of motivated people ?
I think there are 2 ATM. Synquacer and i.MX8 variants.
Based on https://www.arm.com/architecture/system-architectures/systemready-certificat... roughly 30 boards.
Synquacer only has a DT in u-boot, so not really anything to do there. I'm pretty sure the certified DTBs for i.MX8 don't match what's in u-boot or the kernel tree. Hopefully, it's just a subset, but still, there's a gap. I don't know that there is motivation there either. Note that SystemReady currently only requires every node with 'compatible' have a schema. It does not yet require no schema warnings. If we went with a 1 by 1 approach, I would push that platforms have to be free of warnings.
How many years will that take?
Should all platforms following that organization be a goal?
You mean should all platforms be moved? Absolutely. I don't think we want to solve the problem of having DTS files in 2 places by creating a 3rd place. Actually, if we limit he DTS in the third place for SystemReady-IR, there should be no DTB in the Linux distribution. It would be the equivalent as ACPI boards . So is it still an issue ? A reference to the the third repo may be hinted in a text file.
I don't really think 1 by 1 is the right approach. I was just enumerating how this could work. It's not that useful to say we need a standalone repo without working thru the logistics of how exactly that will work.
Rob
boot-architecture@lists.linaro.org
-
ff -
Rob Herring -
Sumit Garg