Hi Tom,
On Sun, 10 Dec 2023 at 03:33, Tom Rini trini@konsulko.com wrote:
On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote:
[snip]
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.
I will have more / other things to say but I want to chime in here. That U-Boot cannot validate the DTS files is a bug, not a feature. I would very much appreciate if someone(s) with time and skills to do so would re-sync us with the kernel Kbuild again so that we can both stay in sync again and have the validation targets / functionality available here too.
Agree, the Kbuild changes to add dtbs_check was the first thing I implemented after importing devicetree-rebasing repo in u-boot (see commit [1] for details). Usage with PR [2] included:
While building any u-boot target, just add make target: "dtbs_check" and you will see the DT schema checks being performed. Steps:
$ make <target>_defconfig $ make -j`nproc` dtbs_check
Currently there are a lot of incompatibility warnings I have seen for the platforms I built. This shows how much difficult it has been to keep DT in sync with upstream DT bindings.
TBH, this was the only motivation for me to get into discussion with DT bindings maintainers for a separate repo. But since with devicetree-rebasing, we get devictree files bundled along and then I got into reusing them for building DTBs in u-boot. This has the other benefit of reducing maintainer's pain to keep DT in sync with Linux kernel major releases (see amlogic platforms to be the first migrator [3]).
[1] https://github.com/u-boot/u-boot/pull/451/commits/7ea2dc2477992a603fa881d0da... [2] https://github.com/u-boot/u-boot/pull/451 [3] https://github.com/u-boot/u-boot/pull/451/commits/38c2ac62e9134604d1a56179d5...
-Sumit
-- Tom
On Mon, Dec 11, 2023 at 11:47 PM Sumit Garg sumit.garg@linaro.org wrote:
Hi Tom,
On Sun, 10 Dec 2023 at 03:33, Tom Rini trini@konsulko.com wrote:
On Mon, Dec 04, 2023 at 11:02:57AM +0530, Sumit Garg wrote:
[snip]
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.
I will have more / other things to say but I want to chime in here. That U-Boot cannot validate the DTS files is a bug, not a feature. I would very much appreciate if someone(s) with time and skills to do so would re-sync us with the kernel Kbuild again so that we can both stay in sync again and have the validation targets / functionality available here too.
Agree, the Kbuild changes to add dtbs_check was the first thing I implemented after importing devicetree-rebasing repo in u-boot (see commit [1] for details). Usage with PR [2] included:
While building any u-boot target, just add make target: "dtbs_check" and you will see the DT schema checks being performed. Steps:
$ make <target>_defconfig $ make -j`nproc` dtbs_check
Currently there are a lot of incompatibility warnings I have seen for the platforms I built. This shows how much difficult it has been to keep DT in sync with upstream DT bindings.
The versions in the Linux tree generally still have lots of warnings too. It's a mountain of warnings. The warnings get amplified when there are N boards for 1 SoC. Some platforms are more active than others to get rid of them. Newer platforms like Apple are warning free (or nearly so). If you want an overview of the state of platforms, I have a CI job[1] doing just that. Look at platform-warnings.log in the artifacts. It does some deduplicating of the warnings. Linux-next and Linus' master are built daily.
Fixing the warnings alone will not solve potential incompatibility issues. The schemas can and do change (and in turn the dts files). We try to catch that in review, but the rule is that the platform must be okay with the ABI change (recent mistake, early stages, limited users, etc.) and the commit message must spell out 'this is an ABI change'. That's all manual and not easily identifiable. I'm working on a tool[2] to compare versions of the schema to identify some ABI changes. Though it is limited by thinking of what schema changes are ABI changes and my ability to write python code to parse those cases. Right now it looks for new required properties, removed properties, and changed number of entries. I'm interested in any ideas for other checks.
Rob
[1] https://gitlab.com/robherring/linux-dt/-/jobs [2] https://github.com/robherring/dt-schema/tree/abi-check
boot-architecture@lists.linaro.org
-
Rob Herring -
Sumit Garg