From: Fiona Klute via buildroot <buildroot@buildroot.org>
To: Edgar Bonet <bonet@grenoble.cnrs.fr>,
Romain Naour <romain.naour@smile.fr>,
Buildroot development <buildroot@buildroot.org>
Cc: Michael Walle <mwalle@kernel.org>,
Chris Packham <judge.packham@gmail.com>,
Sergey Matyukevich <geomatsi@gmail.com>
Subject: Re: [Buildroot] [PATCH v2 1/1] linux: make out-of-tree DTS work with newest kernels
Date: Tue, 28 Jan 2025 14:33:31 +0100 [thread overview]
Message-ID: <f6d14b70-cf74-4a03-80fd-5e4fc4325a47@gmx.de> (raw)
In-Reply-To: <4e691513-04a1-4f6f-ad3a-df18f653a6b7@grenoble.cnrs.fr>
Am 24.12.24 um 13:22 schrieb Edgar Bonet:
> Hello!
>
> On 2024-12-18, Romain Naour wrote:
>> Hello Edgar,
>>
>> Le 17/12/2024 à 10:55, Edgar Bonet a écrit :
>>> Since Linux 6.12 (commit e7e2941300d2, "kbuild: split device tree build
>>> rules into scripts/Makefile.dtbs"), the kernel build process does not
>>> build the DTBs from the source files listed in
>>> BR2_LINUX_KERNEL_CUSTOM_DTS_PATH.[1] This is because it expects all the
>>> DTS files to live in vendor-specific subdirectories of
>>> arch/$ARCH/boot/dts/ , whereas Buildroot drops them in the top dts
>>> directory.
>>
>> Maybe we could add some additional explanation:
>>
>> BR2_LINUX_KERNEL_CUSTOM_DTS_PATH was introduced in Buildroot 2012.08 [1] at the
>> time the kernel didn't have any vendor-specific subdirectory in
>> arch/$ARCH/boot/dts/.
>>
>> vendor-specific subdirectory was introduced in kernel v3.19 [2] for ARM64 and in
>> kernel v6.5 for ARM [3]. Note, other arch than ARM and ARM64 doesn't actually
>> use a vendor-specific subdirectory (not even powerpc).
>
> I hadn't noticed that this varies among archs. Now that I look at it, it
> appears mips and riscv also use vendor-specific subdirectories.
>
>> Your comment doesn't seems to apply for non ARM{,64} arch:
>> "This is because it expects all the DTS files to live in vendor-specific
>> subdirectories of arch/$ARCH/boot/dts/"
>
> Indeed, it is architecture-dependent.
>
>> [1]
>> https://gitlab.com/buildroot.org/buildroot/-/commit/69fc497df0ae51bcc8a067c849447abdeb3cb2be
>> [2]
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=ca5b34100c571658e605c5554aac374649593327
>> [3]
>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=724ba6751532055db75992fc6ae21c3e322e94a7
>>
>>
>>>
>>> Fulfilling this kernel expectation would require a new configuration
>>> parameter for the name of the appropriate vendor subdirectory. It would
>>> also require changing the relative paths to included .dtsi files.
>>>
>>> Let's add instead a rule to the top dts/Makefile for each DTB we want to
>>> build. This avoids breaking user's out-of-tree configurations.
>>>
>>> [1] https://lists.buildroot.org/pipermail/buildroot/2024-October/765463.html
>>
>> Note: Yocto doesn't rely on the kernel build infrastructure to build user
>> provided devicetree [4].
>>
>> Maybe we should consider adding a new package infrastructure like kernel-module?
>
> This seems like an interesting option. It is, however, beyond my
> capabilities.
Bit late to the party, but: I currently have a package in an external
tree that takes a list of .dts/.dtso files from config and calls cpp &
dtc to build .dtb/.dtbo files, with include paths into the Linux build
dir added. The build commands are naturally modeled on how the kernel
build builds DTBs, but it doesn't rely on the kernel Makefiles.
Would something like that be interesting for Buildroot, whether as a
generic DTB build package or infrastructure?
Best regards,
Fiona
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2025-01-28 13:33 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-17 9:55 [Buildroot] [PATCH v2 1/1] linux: make out-of-tree DTS work with newest kernels Edgar Bonet
2024-12-18 14:55 ` Romain Naour via buildroot
2024-12-24 12:22 ` Edgar Bonet
2025-01-28 13:33 ` Fiona Klute via buildroot [this message]
2025-01-29 10:10 ` Romain Naour via buildroot
2025-01-30 10:30 ` Niklas Cassel
2025-01-30 18:12 ` Romain Naour via buildroot
2025-02-03 15:48 ` Fiona Klute via buildroot
2025-02-04 14:47 ` Bryce Johnson
2025-02-04 18:27 ` Fiona Klute via buildroot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f6d14b70-cf74-4a03-80fd-5e4fc4325a47@gmx.de \
--to=buildroot@buildroot.org \
--cc=bonet@grenoble.cnrs.fr \
--cc=fiona.klute@gmx.de \
--cc=geomatsi@gmail.com \
--cc=judge.packham@gmail.com \
--cc=mwalle@kernel.org \
--cc=romain.naour@smile.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox