Re: [PATCH v2] kbuild: Restore the ability to build out of tree dtbs

Re: [PATCH v2] kbuild: Restore the ability to build out of tree dtbs

[Chris Packham]

+cc devicetree

Hi Masahiro,

On 19/10/24 00:19, Masahiro Yamada wrote:
> On Thu, Oct 17, 2024 at 4:59 AM Chris Packham
> <chris.packham@alliedtelesis.co.nz> wrote:
>> A build pattern to handle out of tree dtbs is to copy the .dts file into
>> the kernel source tree and run `make myboard.dtb`. This is supported by
>> the wildcard %.dtb rule in the Makefile but recent changes to split the
>> dtb handling out of scripts/Makefile.build stopped this from working.
>> Restore this functionality by looking for .dtb in $(MAKECMDGOALS) as
>> well as $(targets).
>>
>> Fixes: e7e2941300d2 ("kbuild: split device tree build rules into scripts/Makefile.dtbs")
>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>> ---
> This is not a use-case in upstream.
>
> If you drop-in your downstream DT to the kernel tree,
> you need to associate it with Makefile.

I agree that this is Hyrum's Law at work.  I still feel that handling 
out-of-tree dtbs is something that would be in the best interest of the 
Linux kernel. It doesn't necessarily need to be done by allowing copying 
arbitrary .dts files into the tree, a mechanism like the way out of tree 
kernel modules are handled would be workable.

Often supporting a new hardware platform is just a matter of writing a 
dts that describes the board. Particularly when that board is based on 
an existing one. The way most dts/dtsi files are arranged in-tree 
requires a non trivial amount of handling by the C processor. So while 
one could produce a dtb file by invoking cc -E and dtc with the right 
options pointing at the right paths, having the kernel build system 
provide something that abstracts that would be beneficial for developers 
and even end users.

>> Notes:
>>      Changes in v2:
>>      - keep $(target) and search for .dtb in $(MAKECMDGOALS)
>>
>>   scripts/Makefile.build | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
>> index 8f423a1faf50..78763a4bc58a 100644
>> --- a/scripts/Makefile.build
>> +++ b/scripts/Makefile.build
>> @@ -449,7 +449,7 @@ ifneq ($(userprogs),)
>>   include $(srctree)/scripts/Makefile.userprogs
>>   endif
>>
>> -ifneq ($(need-dtbslist)$(dtb-y)$(dtb-)$(filter %.dtb %.dtb.o %.dtbo.o,$(targets)),)
>> +ifneq ($(need-dtbslist)$(dtb-y)$(dtb-)$(filter %.dtb %.dtb.o %.dtbo.o,$(targets))$(filter %.dtb,$(MAKECMDGOALS)),)
>>   include $(srctree)/scripts/Makefile.dtbs
>>   endif
>>
>> --
>> 2.47.0
>>
>>
>
> --
> Best Regards
> Masahiro Yamada

Re: [PATCH v2] kbuild: Restore the ability to build out of tree dtbs

[Masahiro Yamada]

On Mon, Oct 21, 2024 at 7:57 AM Chris Packham
<chris.packham@alliedtelesis.co.nz> wrote:
>
> +cc devicetree
>
> Hi Masahiro,
>
> On 19/10/24 00:19, Masahiro Yamada wrote:
> > On Thu, Oct 17, 2024 at 4:59 AM Chris Packham
> > <chris.packham@alliedtelesis.co.nz> wrote:
> >> A build pattern to handle out of tree dtbs is to copy the .dts file into
> >> the kernel source tree and run `make myboard.dtb`. This is supported by
> >> the wildcard %.dtb rule in the Makefile but recent changes to split the
> >> dtb handling out of scripts/Makefile.build stopped this from working.
> >> Restore this functionality by looking for .dtb in $(MAKECMDGOALS) as
> >> well as $(targets).
> >>
> >> Fixes: e7e2941300d2 ("kbuild: split device tree build rules into scripts/Makefile.dtbs")
> >> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
> >> ---
> > This is not a use-case in upstream.
> >
> > If you drop-in your downstream DT to the kernel tree,
> > you need to associate it with Makefile.
>
> I agree that this is Hyrum's Law at work.  I still feel that handling
> out-of-tree dtbs is something that would be in the best interest of the
> Linux kernel. It doesn't necessarily need to be done by allowing copying
> arbitrary .dts files into the tree, a mechanism like the way out of tree
> kernel modules are handled would be workable.
>
> Often supporting a new hardware platform is just a matter of writing a
> dts that describes the board. Particularly when that board is based on
> an existing one. The way most dts/dtsi files are arranged in-tree
> requires a non trivial amount of handling by the C processor. So while
> one could produce a dtb file by invoking cc -E and dtc with the right
> options pointing at the right paths, having the kernel build system
> provide something that abstracts that would be beneficial for developers
> and even end users.



I also handle a bunch of yet-to-upstream device tree files.


I have them in the proper directory location, and add

  dtb-$(CONFIG_ARCH_FOO)  += foo-downstream-custom1.dtb
  dtb-$(CONFIG_ARCH_FOO)  += foo-downstream-custom2.dtb
    ...

jutt like how they would look when they were upstreamed.



I do not understand why the drop-in way is supported.











> >> Notes:
> >>      Changes in v2:
> >>      - keep $(target) and search for .dtb in $(MAKECMDGOALS)
> >>
> >>   scripts/Makefile.build | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/scripts/Makefile.build b/scripts/Makefile.build
> >> index 8f423a1faf50..78763a4bc58a 100644
> >> --- a/scripts/Makefile.build
> >> +++ b/scripts/Makefile.build
> >> @@ -449,7 +449,7 @@ ifneq ($(userprogs),)
> >>   include $(srctree)/scripts/Makefile.userprogs
> >>   endif
> >>
> >> -ifneq ($(need-dtbslist)$(dtb-y)$(dtb-)$(filter %.dtb %.dtb.o %.dtbo.o,$(targets)),)
> >> +ifneq ($(need-dtbslist)$(dtb-y)$(dtb-)$(filter %.dtb %.dtb.o %.dtbo.o,$(targets))$(filter %.dtb,$(MAKECMDGOALS)),)
> >>   include $(srctree)/scripts/Makefile.dtbs
> >>   endif
> >>
> >> --
> >> 2.47.0
> >>
> >>
> >
> > --
> > Best Regards
> > Masahiro Yamada
>


-- 
Best Regards
Masahiro Yamada