Covering DT build in -next merge

Covering DT build in -next merge

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 653 bytes --]

Hi Stephen,

I was wondering if it might be possible to add DTB builds for relevant
architecutres to the -next merge checks (everything except x86 AFAIK)?
Some current experience suggested to me that it might be helpful for
bisecting problems found in testing, breakage building the DTBs causes
hassle since where they're used in tree DTs are required to boot the
kernel.

At least for arm and arm64 the DT build is quick enough to be negligable
in the context of building the kernel itself so hopefully it shouldn't
add too much load to do this - it's just adding a 'make dtbs' (with
appropriate cross build options) to the kernel build.

Thanks,
Mark

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Covering DT build in -next merge

[Palmer Dabbelt]

On Tue, 17 Oct 2023 13:16:21 PDT (-0700), broonie@kernel.org wrote:
> Hi Stephen,
>
> I was wondering if it might be possible to add DTB builds for relevant
> architecutres to the -next merge checks (everything except x86 AFAIK)?
> Some current experience suggested to me that it might be helpful for
> bisecting problems found in testing, breakage building the DTBs causes
> hassle since where they're used in tree DTs are required to boot the
> kernel.
>
> At least for arm and arm64 the DT build is quick enough to be negligable
> in the context of building the kernel itself so hopefully it shouldn't
> add too much load to do this - it's just adding a 'make dtbs' (with
> appropriate cross build options) to the kernel build.

Pretty sure we're in the same shape for RISC-V these days.  +Conor, who 
would know for sure (as he made it work).

>
> Thanks,
> Mark

Re: Covering DT build in -next merge

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]

On Tue, Oct 17, 2023 at 01:20:26PM -0700, Palmer Dabbelt wrote:
> On Tue, 17 Oct 2023 13:16:21 PDT (-0700), broonie@kernel.org wrote:
> > Hi Stephen,
> > 
> > I was wondering if it might be possible to add DTB builds for relevant
> > architecutres to the -next merge checks (everything except x86 AFAIK)?
> > Some current experience suggested to me that it might be helpful for
> > bisecting problems found in testing, breakage building the DTBs causes
> > hassle since where they're used in tree DTs are required to boot the
> > kernel.
> > 
> > At least for arm and arm64 the DT build is quick enough to be negligable
> > in the context of building the kernel itself so hopefully it shouldn't
> > add too much load to do this - it's just adding a 'make dtbs' (with
> > appropriate cross build options) to the kernel build.
> 
> Pretty sure we're in the same shape for RISC-V these days.

Yup, same deal on riscv pretty much. It takes less than 5 seconds to
build them all for riscv, and it would be a nice bare minimum check.
Certainly would be good to have it.

> +Conor, who
> would know for sure (as he made it work).

What I sorted out dtbs_check being warning central actually, and I
suppose it'd be nice to track new warnings added to dbts_check in next
automagically, but that build (single make job) takes 20 times longer
on riscv than just building the dtbs - and probably far longer on arm64.
It also requires keeping up fairly religiously with dt-schema, so
probably not a runner...



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Covering DT build in -next merge

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1200 bytes --]

Hi Mark,

On Tue, 17 Oct 2023 21:16:21 +0100 Mark Brown <broonie@kernel.org> wrote:
>
> I was wondering if it might be possible to add DTB builds for relevant
> architecutres to the -next merge checks (everything except x86 AFAIK)?
> Some current experience suggested to me that it might be helpful for
> bisecting problems found in testing, breakage building the DTBs causes
> hassle since where they're used in tree DTs are required to boot the
> kernel.
> 
> At least for arm and arm64 the DT build is quick enough to be negligable
> in the context of building the kernel itself so hopefully it shouldn't
> add too much load to do this - it's just adding a 'make dtbs' (with
> appropriate cross build options) to the kernel build.

Ummm, arm builds (and many others) select CONFIG_OF_EARLY_FLATTREE (in
the case of arm, only if CONFIG_OF is set), and the top level Makefile
does this:

ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),)
dtstree := arch/$(SRCARCH)/boot/dts
endif

ifneq ($(dtstree),)
	.
	.
	.
ifdef CONFIG_OF_EARLY_FLATTREE
all: dtbs
endif

endif

So won't this be the same as doing a separate "make dtbs"?
-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: Covering DT build in -next merge

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

On Wed, Oct 18, 2023 at 05:11:01PM +1100, Stephen Rothwell wrote:
> On Tue, 17 Oct 2023 21:16:21 +0100 Mark Brown <broonie@kernel.org> wrote:

> > I was wondering if it might be possible to add DTB builds for relevant
> > architecutres to the -next merge checks (everything except x86 AFAIK)?
> > Some current experience suggested to me that it might be helpful for
> > bisecting problems found in testing, breakage building the DTBs causes
> > hassle since where they're used in tree DTs are required to boot the
> > kernel.

> Ummm, arm builds (and many others) select CONFIG_OF_EARLY_FLATTREE (in
> the case of arm, only if CONFIG_OF is set), and the top level Makefile
> does this:

> ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),)
> dtstree := arch/$(SRCARCH)/boot/dts
> endif

> So won't this be the same as doing a separate "make dtbs"?

Huh, yes - then I'm not sure how we're managing to see such extensive
breakage with the bisects I'm running - I've been running into lerge
ranges of commits which don't build due to missing header files.  I'll
have to check into it, sorry for the noise.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]