Thread (5 messages) 5 messages, 3 authors, 2021-12-08

Re: [PATCH v2] kbuild: Enable DT schema checks for %.dtb targets

From: Chris Packham <Chris.Packham@alliedtelesis.co.nz>
Date: 2021-12-08 22:37:56
Also in: linux-kbuild

On 9/12/21 10:31 am, Rob Herring wrote:
On Mon, Dec 6, 2021 at 1:34 AM Chris Packham
[off-list ref] wrote:
quoted
Hi Rob,

On 14/09/21 2:51 am, Rob Herring wrote:
quoted
It is possible to build a single dtb, but not with DT schema validation
enabled. Enable the schema validation to run for %.dtb and %.dtbo
targets. Anyone building a dtb for a specific platform *should* pay
attention to schema warnings.

This could be supported with a separate %.dt.yaml target instead.
However, the .dt.yaml format is considered an intermediate format and
could possibly go away at some point if schema checking is integrated
into dtc. Also, the plan is to enable the schema checks by default once
platforms are free of warnings, and this is a move in that direction.
Just started building 5.16-rc4 and hit the following error

/usr/src/linux/scripts/dtc/Makefile:23: *** dtc needs libyaml for DT
schema validation support. Install the necessary libyaml development
package..  Stop.
make: *** [/usr/src/linux/Makefile:1405: scripts_dtc] Error 2
make: *** Waiting for unfinished jobs....

I tracked it back to this patch and I gather that the "error" is very
much intended. Fixing it means I need to get a native libyaml into my
cross toolchain, which is doable but a bit of a hassle. This probably
affects other meta build systems like buildroot and yocto.
Yes. I'm going to revert this for now.

Are python dependencies any easier? The libyaml dtc dependency may
actually go away, but dtschema and it's dependencies will remain.
Probably no worse that non python dependencies.

Our particular special in-house build system might be a bit trickier as 
we can't just spin up a vitrualenv but that's our problem not yours. We 
do manage to build other packages that have build-time python 
dependencies so I'm sure we could make that work for the kernel. I'm not 
sure how much push-back you'd get from others if python became a 
dependency for building the kernel.
quoted
I think I understand what you're getting at but is it possible to have
some kind of escape hatch to avoid having to add a build time tool
dependency (or even bundling libyaml next to scripts/dtc)?
My current thought is to make it a kconfig option. I assume that would
work for you?
An option would work for us. It could also be the kind of thing that 
kicks in with make C=1/2.

I presume that you would want people to run this kind of thing when 
submitting new bindings or board.dts. For us we can do those builds 
manually outside our full build system.
quoted
I also notice that when I do supply a toolchain with libyaml the build
times are impacted by a noticable factor.
How many dtbs are you building?
Nothing excessive. Something in the order of 7 depending on the 
architecture. It's avoided on most re-builds so generally it's just a 
one-off cost but it would affect any type of CI system that builds from 
clean.
Rob
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help