* [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12
@ 2024-12-08 21:46 Sergey Matyukevich
2024-12-08 21:46 ` [Buildroot] [PATCH 1/3] {toolchain, linux-headers}: add support for 6.12 headers Sergey Matyukevich
` (4 more replies)
0 siblings, 5 replies; 15+ messages in thread
From: Sergey Matyukevich @ 2024-12-08 21:46 UTC (permalink / raw)
To: buildroot
Cc: Giulio Benetti, Romain Naour, Thomas Petazzoni, Bernd Kuhls,
Sergey Matyukevich
Hi Thomas, Bernd, and all
I have been waiting for the new LTS Linux v6.12 in Buildroot to start
sending Christmas updates for some of my OrangePi boards. Now v6.12.3
is already available, but the latest kernel is still have 6.11.x.
So I decided to undertake a copy-paste exercise using the latest kernel
and headers update series by Bernd. Hope I didn't miss a thing taking
into account that this is a new LTS.
Regards,
Sergey
Sergey Matyukevich (3):
{toolchain, linux-headers}: add support for 6.12 headers
linux: bump latest version to 6.12
package/linux-headers: drop 6.11.x option
Config.in.legacy | 7 +++++++
linux/Config.in | 6 +++---
linux/linux.hash | 2 +-
package/linux-headers/Config.in.host | 16 ++++++++++------
toolchain/Config.in | 5 +++++
.../toolchain-external-custom/Config.in.options | 6 +++++-
6 files changed, 31 insertions(+), 11 deletions(-)
--
2.47.1
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
^ permalink raw reply [flat|nested] 15+ messages in thread* [Buildroot] [PATCH 1/3] {toolchain, linux-headers}: add support for 6.12 headers 2024-12-08 21:46 [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 Sergey Matyukevich @ 2024-12-08 21:46 ` Sergey Matyukevich 2024-12-08 21:46 ` [Buildroot] [PATCH 2/3] linux: bump latest version to 6.12 Sergey Matyukevich ` (3 subsequent siblings) 4 siblings, 0 replies; 15+ messages in thread From: Sergey Matyukevich @ 2024-12-08 21:46 UTC (permalink / raw) To: buildroot Cc: Giulio Benetti, Romain Naour, Thomas Petazzoni, Bernd Kuhls, Sergey Matyukevich And add (and default to) 6.12 to linux-headers. Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com> --- linux/linux.hash | 1 + package/linux-headers/Config.in.host | 13 +++++++++++-- toolchain/Config.in | 5 +++++ .../toolchain-external-custom/Config.in.options | 6 +++++- 4 files changed, 22 insertions(+), 3 deletions(-) diff --git a/linux/linux.hash b/linux/linux.hash index 6002478854..67bdc32372 100644 --- a/linux/linux.hash +++ b/linux/linux.hash @@ -1,4 +1,5 @@ # From https://www.kernel.org/pub/linux/kernel/v6.x/sha256sums.asc +sha256 c89809cc777d50f1ea484a118630281a26383707a0e752c96fd834f6e765deae linux-6.12.3.tar.xz sha256 62148e7e17f54c4a5ab5e75ad4882682c54bee818948be61a5963234fc0849fc linux-6.11.11.tar.xz sha256 d1054ab4803413efe2850f50f1a84349c091631ec50a1cf9e891d1b1f9061835 linux-6.6.63.tar.xz sha256 aecdaf39d0a844a81ce4c67d9daff8979e938bb690df4f679fbbb494fe423278 linux-6.1.119.tar.xz diff --git a/package/linux-headers/Config.in.host b/package/linux-headers/Config.in.host index e8f7515894..0b517534c7 100644 --- a/package/linux-headers/Config.in.host +++ b/package/linux-headers/Config.in.host @@ -3,7 +3,7 @@ comment "Kernel Header Options" choice prompt "Kernel Headers" default BR2_KERNEL_HEADERS_AS_KERNEL if BR2_LINUX_KERNEL - default BR2_KERNEL_HEADERS_6_11 + default BR2_KERNEL_HEADERS_6_12 help Select the kernel version to get headers from. @@ -51,6 +51,10 @@ config BR2_KERNEL_HEADERS_6_6 config BR2_KERNEL_HEADERS_6_11 bool "Linux 6.11.x kernel headers" select BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_11 + +config BR2_KERNEL_HEADERS_6_12 + bool "Linux 6.12.x kernel headers" + select BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_12 select BR2_KERNEL_HEADERS_LATEST config BR2_KERNEL_HEADERS_VERSION @@ -129,8 +133,12 @@ choice If your kernel headers are more recent than the latest version in the choice, then select the latest version. +config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_12 + bool "6.12.x or later" + select BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_12 + config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_11 - bool "6.11.x or later" + bool "6.11.x" select BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_11 config BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_10 @@ -435,6 +443,7 @@ config BR2_DEFAULT_KERNEL_HEADERS default "6.1.119" if BR2_KERNEL_HEADERS_6_1 default "6.6.63" if BR2_KERNEL_HEADERS_6_6 default "6.11.11" if BR2_KERNEL_HEADERS_6_11 + default "6.12.3" if BR2_KERNEL_HEADERS_6_12 default BR2_DEFAULT_KERNEL_VERSION if BR2_KERNEL_HEADERS_VERSION default "custom" if BR2_KERNEL_HEADERS_CUSTOM_TARBALL default BR2_KERNEL_HEADERS_CUSTOM_REPO_VERSION \ diff --git a/toolchain/Config.in b/toolchain/Config.in index c2522aca7f..87160af3d7 100644 --- a/toolchain/Config.in +++ b/toolchain/Config.in @@ -660,6 +660,10 @@ config BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_10 config BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_11 bool select BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_10 + +config BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_12 + bool + select BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_11 select BR2_TOOLCHAIN_HEADERS_LATEST # This should be selected by the latest version, above, to indicate that @@ -673,6 +677,7 @@ config BR2_TOOLCHAIN_HEADERS_LATEST # stops affecting a value on the first matching default. config BR2_TOOLCHAIN_HEADERS_AT_LEAST string + default "6.12" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_12 default "6.11" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_11 default "6.10" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_10 default "6.9" if BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_9 diff --git a/toolchain/toolchain-external/toolchain-external-custom/Config.in.options b/toolchain/toolchain-external/toolchain-external-custom/Config.in.options index fcffeb6b77..2dc04747b3 100644 --- a/toolchain/toolchain-external/toolchain-external-custom/Config.in.options +++ b/toolchain/toolchain-external/toolchain-external-custom/Config.in.options @@ -166,8 +166,12 @@ choice If your toolchain uses headers newer than the latest version in the choice, then select the latest version. +config BR2_TOOLCHAIN_EXTERNAL_HEADERS_6_12 + bool "6.12.x or later" + select BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_12 + config BR2_TOOLCHAIN_EXTERNAL_HEADERS_6_11 - bool "6.11.x or later" + bool "6.11.x" select BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_11 config BR2_TOOLCHAIN_EXTERNAL_HEADERS_6_10 -- 2.47.1 _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply related [flat|nested] 15+ messages in thread
* [Buildroot] [PATCH 2/3] linux: bump latest version to 6.12 2024-12-08 21:46 [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 Sergey Matyukevich 2024-12-08 21:46 ` [Buildroot] [PATCH 1/3] {toolchain, linux-headers}: add support for 6.12 headers Sergey Matyukevich @ 2024-12-08 21:46 ` Sergey Matyukevich 2024-12-08 21:46 ` [Buildroot] [PATCH 3/3] package/linux-headers: drop 6.11.x option Sergey Matyukevich ` (2 subsequent siblings) 4 siblings, 0 replies; 15+ messages in thread From: Sergey Matyukevich @ 2024-12-08 21:46 UTC (permalink / raw) To: buildroot Cc: Giulio Benetti, Romain Naour, Thomas Petazzoni, Bernd Kuhls, Sergey Matyukevich Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com> --- linux/Config.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/linux/Config.in b/linux/Config.in index 63078d686e..f537dd7adf 100644 --- a/linux/Config.in +++ b/linux/Config.in @@ -28,8 +28,8 @@ choice prompt "Kernel version" config BR2_LINUX_KERNEL_LATEST_VERSION - bool "Latest version (6.11)" - select BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_11 if BR2_KERNEL_HEADERS_AS_KERNEL + bool "Latest version (6.12)" + select BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_12 if BR2_KERNEL_HEADERS_AS_KERNEL config BR2_LINUX_KERNEL_LATEST_CIP_VERSION bool "Latest CIP SLTS version (5.10.162-cip24)" @@ -134,7 +134,7 @@ config BR2_LINUX_KERNEL_CUSTOM_REPO_GIT_SUBMODULES config BR2_LINUX_KERNEL_VERSION string - default "6.11.11" if BR2_LINUX_KERNEL_LATEST_VERSION + default "6.12.3" if BR2_LINUX_KERNEL_LATEST_VERSION default "5.10.162-cip24" if BR2_LINUX_KERNEL_LATEST_CIP_VERSION default "5.10.162-cip24-rt10" if BR2_LINUX_KERNEL_LATEST_CIP_RT_VERSION default BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE \ -- 2.47.1 _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply related [flat|nested] 15+ messages in thread
* [Buildroot] [PATCH 3/3] package/linux-headers: drop 6.11.x option 2024-12-08 21:46 [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 Sergey Matyukevich 2024-12-08 21:46 ` [Buildroot] [PATCH 1/3] {toolchain, linux-headers}: add support for 6.12 headers Sergey Matyukevich 2024-12-08 21:46 ` [Buildroot] [PATCH 2/3] linux: bump latest version to 6.12 Sergey Matyukevich @ 2024-12-08 21:46 ` Sergey Matyukevich 2024-12-09 8:11 ` [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 Edgar Bonet 2024-12-11 13:43 ` Romain Naour via buildroot 4 siblings, 0 replies; 15+ messages in thread From: Sergey Matyukevich @ 2024-12-08 21:46 UTC (permalink / raw) To: buildroot Cc: Giulio Benetti, Romain Naour, Thomas Petazzoni, Bernd Kuhls, Sergey Matyukevich The 6.11.x series is now EOL upstream, so drop the linux-headers option and add legacy handling for it. Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com> --- Config.in.legacy | 7 +++++++ linux/linux.hash | 1 - package/linux-headers/Config.in.host | 5 ----- 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/Config.in.legacy b/Config.in.legacy index 2ef1e19516..56b8d407ee 100644 --- a/Config.in.legacy +++ b/Config.in.legacy @@ -146,6 +146,13 @@ endif comment "Legacy options removed in 2025.02" +config BR2_KERNEL_HEADERS_6_11 + bool "kernel headers version 6.11.x are no longer supported" + select BR2_LEGACY + help + Version 6.11.x of the Linux kernel headers are no longer + maintained upstream and are now removed. + config BR2_PACKAGE_FCONFIG bool "fconfig has been removed" select BR2_LEGACY diff --git a/linux/linux.hash b/linux/linux.hash index 67bdc32372..d37188b4b2 100644 --- a/linux/linux.hash +++ b/linux/linux.hash @@ -1,6 +1,5 @@ # From https://www.kernel.org/pub/linux/kernel/v6.x/sha256sums.asc sha256 c89809cc777d50f1ea484a118630281a26383707a0e752c96fd834f6e765deae linux-6.12.3.tar.xz -sha256 62148e7e17f54c4a5ab5e75ad4882682c54bee818948be61a5963234fc0849fc linux-6.11.11.tar.xz sha256 d1054ab4803413efe2850f50f1a84349c091631ec50a1cf9e891d1b1f9061835 linux-6.6.63.tar.xz sha256 aecdaf39d0a844a81ce4c67d9daff8979e938bb690df4f679fbbb494fe423278 linux-6.1.119.tar.xz # From https://www.kernel.org/pub/linux/kernel/v5.x/sha256sums.asc diff --git a/package/linux-headers/Config.in.host b/package/linux-headers/Config.in.host index 0b517534c7..826320c96e 100644 --- a/package/linux-headers/Config.in.host +++ b/package/linux-headers/Config.in.host @@ -48,10 +48,6 @@ config BR2_KERNEL_HEADERS_6_6 bool "Linux 6.6.x kernel headers" select BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_6 -config BR2_KERNEL_HEADERS_6_11 - bool "Linux 6.11.x kernel headers" - select BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_11 - config BR2_KERNEL_HEADERS_6_12 bool "Linux 6.12.x kernel headers" select BR2_TOOLCHAIN_HEADERS_AT_LEAST_6_12 @@ -442,7 +438,6 @@ config BR2_DEFAULT_KERNEL_HEADERS default "5.15.173" if BR2_KERNEL_HEADERS_5_15 default "6.1.119" if BR2_KERNEL_HEADERS_6_1 default "6.6.63" if BR2_KERNEL_HEADERS_6_6 - default "6.11.11" if BR2_KERNEL_HEADERS_6_11 default "6.12.3" if BR2_KERNEL_HEADERS_6_12 default BR2_DEFAULT_KERNEL_VERSION if BR2_KERNEL_HEADERS_VERSION default "custom" if BR2_KERNEL_HEADERS_CUSTOM_TARBALL -- 2.47.1 _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 2024-12-08 21:46 [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 Sergey Matyukevich ` (2 preceding siblings ...) 2024-12-08 21:46 ` [Buildroot] [PATCH 3/3] package/linux-headers: drop 6.11.x option Sergey Matyukevich @ 2024-12-09 8:11 ` Edgar Bonet 2024-12-10 20:43 ` Sergey Matyukevich 2024-12-11 13:43 ` Romain Naour via buildroot 4 siblings, 1 reply; 15+ messages in thread From: Edgar Bonet @ 2024-12-09 8:11 UTC (permalink / raw) To: buildroot Hello everybody! Sergey Matyukevich wrote: > I have been waiting for the new LTS Linux v6.12 in Buildroot to start > sending Christmas updates for some of my OrangePi boards. Now v6.12.3 > is already available, but the latest kernel is still have 6.11.x. So I > decided to undertake a copy-paste exercise using the latest kernel and > headers update series by Bernd. Nice! Note, however, that there is an issue with Linux v6.12: the kernel build process won't build the device trees provided by Buildroot. The issue has been raised by Chris Packham both on the Buildroot mailing list[1] and on the kernel mailing list.[2] I think this should be fixed before bumping "latest kernel" to v6.12. In the kernel thread, there is this solution suggested by Masahiro Yamada: > I have [the yet-to-upstream device tree files] in the proper directory > location, and add > > dtb-$(CONFIG_ARCH_FOO) += foo-downstream-custom1.dtb > dtb-$(CONFIG_ARCH_FOO) += foo-downstream-custom2.dtb > ... > > just like how they would look when they were upstreamed. Maybe this approach could be adapted to Buildroot? Regards, Edgar. [1] https://lists.buildroot.org/pipermail/buildroot/2024-October/765463.html [2] https://lore.kernel.org/all/20241016194149.4178898-1-chris.packham@alliedtelesis.co.nz/T/#u _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 2024-12-09 8:11 ` [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 Edgar Bonet @ 2024-12-10 20:43 ` Sergey Matyukevich 2024-12-11 11:34 ` Edgar Bonet 2024-12-13 10:11 ` Michael Walle via buildroot 0 siblings, 2 replies; 15+ messages in thread From: Sergey Matyukevich @ 2024-12-10 20:43 UTC (permalink / raw) To: Edgar Bonet; +Cc: buildroot Hi Edgar, On Mon, Dec 09, 2024 at 09:11:40AM +0100, Edgar Bonet wrote: > Hello everybody! > > Sergey Matyukevich wrote: > > I have been waiting for the new LTS Linux v6.12 in Buildroot to start > > sending Christmas updates for some of my OrangePi boards. Now v6.12.3 > > is already available, but the latest kernel is still have 6.11.x. So I > > decided to undertake a copy-paste exercise using the latest kernel and > > headers update series by Bernd. > > Nice! > > Note, however, that there is an issue with Linux v6.12: the kernel build > process won't build the device trees provided by Buildroot. The issue > has been raised by Chris Packham both on the Buildroot mailing list[1] > and on the kernel mailing list.[2] I think this should be fixed before > bumping "latest kernel" to v6.12. > > In the kernel thread, there is this solution suggested by Masahiro > Yamada: > > > I have [the yet-to-upstream device tree files] in the proper directory > > location, and add > > > > dtb-$(CONFIG_ARCH_FOO) += foo-downstream-custom1.dtb > > dtb-$(CONFIG_ARCH_FOO) += foo-downstream-custom2.dtb > > ... > > > > just like how they would look when they were upstreamed. > > Maybe this approach could be adapted to Buildroot? IIUC at the moment Buildroot includes the following configurations that make use of BR2_LINUX_KERNEL_CUSTOM_DTS_PATH: - acmesystems_acqua_a5_256mb_defconfig (v6.6) - acmesystems_acqua_a5_512mb_defconfig (v6.6) - octavo_osd32mp1_brk_defconfig (v5.10) - octavo_osd32mp1_red_defconfig (v5.10) - s6lx9_microboard_defconfig (v4.4.7) Kernel version from each config is specified in parentheses. Adding new v6.12 kernel is not going to break any of those boards right away. However if the build rule for drop-in dtbs will not be re-enabled (which seems likely), migration to new kernels will be a problem for those boards. I don't see how BR2_LINUX_KERNEL_CUSTOM_DTS_PATH can be supported in this case w/o patching new kernels. Probably it makes sense to convert those out-of-tree dts files into proper kernel patches ? Regards, Sergey _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 2024-12-10 20:43 ` Sergey Matyukevich @ 2024-12-11 11:34 ` Edgar Bonet 2024-12-11 18:26 ` Chris Packham 2024-12-13 10:11 ` Michael Walle via buildroot 1 sibling, 1 reply; 15+ messages in thread From: Edgar Bonet @ 2024-12-11 11:34 UTC (permalink / raw) To: Sergey Matyukevich; +Cc: buildroot, Chris Packham Hello! About the incompatibility between Linux 6.12 and BR2_LINUX_KERNEL_CUSTOM_DTS_PATH, Sergey Matyukevich wrote: > IIUC at the moment Buildroot includes the following configurations > that make use of BR2_LINUX_KERNEL_CUSTOM_DTS_PATH: [only 5 of them] Oh, I hadn't noticed there were so few of them! > Adding new v6.12 kernel is not going to break any of those boards > right away. However if the build rule for drop-in dtbs will not be > re-enabled (which seems likely), migration to new kernels will be a > problem for those boards. Indeed, this is my concern: I maintain the defconfigs of the Acqua boards (acmesystems_acqua_a5_*), and I would like to upgrade them to Linux 6.12 before the Buildroot 2025.02 release. However, this issue will also affect users that build (or customize) their own configurations with `make nconfig` or similar. If they select [x] Linux Kernel [x] Build a Device Tree Blob (DTB) (some_file) Out-of-tree Device Tree Source file paths and leave `Kernel version' to its default (which is "Latest version"), they would end up with a non-functional configuration. > I don't see how BR2_LINUX_KERNEL_CUSTOM_DTS_PATH can be supported in > this case w/o patching new kernels. Probably it makes sense to convert > those out-of-tree dts files into proper kernel patches ? I see two options for patching the kernel: 1. Use Chris Packham's patch "kbuild: Restore the ability to build out of tree dtbs".[1] This works for me: if I drop the patch into board/acmesystems/acqua-a5/patches/linux/, I can change the kernel version to 6.12.4 and it just works. It seems like the path of least resistance for individual defconfigs, but I don't see this becoming Buildroot's blessed way of supporting custom DTSes. 2. Create a patch that adds the DTS to the kernel tree _and_ the DTB target to the relevant Makefile. I guess this is what you are suggesting. If we go for the second option, then we would be saying that a kernel patch is the canonical way of providing a custom DTS. The BR2_LINUX_KERNEL_CUSTOM_DTS_PATH option would then have to be deprecated and eventually removed, which would be a breaking change for some users. I would persoanlly prefer updating the implementation of BR2_LINUX_KERNEL_CUSTOM_DTS_PATH in order to make it compatible with 6.12+ kernels. Maybe Buildroot could, in addition to copying the DTS to the kernel tree, add the relevant target to the Makefile. Basically do what the patch in method 2 is supposed to do. I could try to implement this approach, but it can take me some time (the `make' language is not my cup of tea). In the meantime, I suggest that, in your patch series, you update the help text of BR2_LINUX_KERNEL_CUSTOM_DTS_PATH in order to warn about this option being incompatible with kernels 6.12 and up. Regards, Edgar. [1] https://lore.kernel.org/all/20241015212830.3899891-1-chris.packham@alliedtelesis.co.nz/T/#u _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 2024-12-11 11:34 ` Edgar Bonet @ 2024-12-11 18:26 ` Chris Packham 2024-12-13 10:09 ` Michael Walle via buildroot 0 siblings, 1 reply; 15+ messages in thread From: Chris Packham @ 2024-12-11 18:26 UTC (permalink / raw) To: Edgar Bonet; +Cc: Sergey Matyukevich, buildroot [-- Attachment #1.1: Type: text/plain, Size: 3492 bytes --] On Thu, 12 Dec 2024, 12:34 am Edgar Bonet, <bonet@grenoble.cnrs.fr> wrote: > Hello! > > About the incompatibility between Linux 6.12 and > BR2_LINUX_KERNEL_CUSTOM_DTS_PATH, Sergey Matyukevich wrote: > > IIUC at the moment Buildroot includes the following configurations > > that make use of BR2_LINUX_KERNEL_CUSTOM_DTS_PATH: [only 5 of them] > > Oh, I hadn't noticed there were so few of them! > > > Adding new v6.12 kernel is not going to break any of those boards > > right away. However if the build rule for drop-in dtbs will not be > > re-enabled (which seems likely), migration to new kernels will be a > > problem for those boards. > > Indeed, this is my concern: I maintain the defconfigs of the Acqua > boards (acmesystems_acqua_a5_*), and I would like to upgrade them to > Linux 6.12 before the Buildroot 2025.02 release. > > However, this issue will also affect users that build (or customize) > their own configurations with `make nconfig` or similar. If they select > > [x] Linux Kernel > [x] Build a Device Tree Blob (DTB) > (some_file) Out-of-tree Device Tree Source file paths > > and leave `Kernel version' to its default (which is "Latest version"), > they would end up with a non-functional configuration. > > > I don't see how BR2_LINUX_KERNEL_CUSTOM_DTS_PATH can be supported in > > this case w/o patching new kernels. Probably it makes sense to convert > > those out-of-tree dts files into proper kernel patches ? > > I see two options for patching the kernel: > > 1. Use Chris Packham's patch "kbuild: Restore the ability to build out > of tree dtbs".[1] This works for me: if I drop the patch into > board/acmesystems/acqua-a5/patches/linux/, I can change the kernel > version to 6.12.4 and it just works. It seems like the path of least > resistance for individual defconfigs, but I don't see this becoming > Buildroot's blessed way of supporting custom DTSes. > > 2. Create a patch that adds the DTS to the kernel tree _and_ the DTB > target to the relevant Makefile. I guess this is what you are > suggesting. > For what it's worth I implemented Masahiro's suggestion (basically option 2) for our internal build tool at $dayjob. It's just a bit of sed-ing. It works reasonably well. The trickiest part is avoiding repatching the Makefile but for buildroot that's just a flag file. > If we go for the second option, then we would be saying that a kernel > patch is the canonical way of providing a custom DTS. The > BR2_LINUX_KERNEL_CUSTOM_DTS_PATH option would then have to be deprecated > and eventually removed, which would be a breaking change for some users. > > I would persoanlly prefer updating the implementation of > BR2_LINUX_KERNEL_CUSTOM_DTS_PATH in order to make it compatible with > 6.12+ kernels. Maybe Buildroot could, in addition to copying the DTS to > the kernel tree, add the relevant target to the Makefile. Basically do > what the patch in method 2 is supposed to do. > > I could try to implement this approach, but it can take me some time > (the `make' language is not my cup of tea). In the meantime, I suggest > that, in your patch series, you update the help text of > BR2_LINUX_KERNEL_CUSTOM_DTS_PATH in order to warn about this option > being incompatible with kernels 6.12 and up. > > Regards, > > Edgar. > > [1] > https://lore.kernel.org/all/20241015212830.3899891-1-chris.packham@alliedtelesis.co.nz/T/#u > [-- Attachment #1.2: Type: text/html, Size: 4452 bytes --] [-- Attachment #2: Type: text/plain, Size: 150 bytes --] _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 2024-12-11 18:26 ` Chris Packham @ 2024-12-13 10:09 ` Michael Walle via buildroot 2024-12-13 13:30 ` Sergey Matyukevich 0 siblings, 1 reply; 15+ messages in thread From: Michael Walle via buildroot @ 2024-12-13 10:09 UTC (permalink / raw) To: Chris Packham, Edgar Bonet; +Cc: Sergey Matyukevich, buildroot [-- Attachment #1.1: Type: text/plain, Size: 4121 bytes --] On Wed Dec 11, 2024 at 7:26 PM CET, Chris Packham wrote: > On Thu, 12 Dec 2024, 12:34 am Edgar Bonet, <bonet@grenoble.cnrs.fr> wrote: > > > Hello! > > > > About the incompatibility between Linux 6.12 and > > BR2_LINUX_KERNEL_CUSTOM_DTS_PATH, Sergey Matyukevich wrote: > > > IIUC at the moment Buildroot includes the following configurations > > > that make use of BR2_LINUX_KERNEL_CUSTOM_DTS_PATH: [only 5 of them] > > > > Oh, I hadn't noticed there were so few of them! > > > > > Adding new v6.12 kernel is not going to break any of those boards > > > right away. However if the build rule for drop-in dtbs will not be > > > re-enabled (which seems likely), migration to new kernels will be a > > > problem for those boards. > > > > Indeed, this is my concern: I maintain the defconfigs of the Acqua > > boards (acmesystems_acqua_a5_*), and I would like to upgrade them to > > Linux 6.12 before the Buildroot 2025.02 release. > > > > However, this issue will also affect users that build (or customize) > > their own configurations with `make nconfig` or similar. If they select > > > > [x] Linux Kernel > > [x] Build a Device Tree Blob (DTB) > > (some_file) Out-of-tree Device Tree Source file paths > > > > and leave `Kernel version' to its default (which is "Latest version"), > > they would end up with a non-functional configuration. > > > > > I don't see how BR2_LINUX_KERNEL_CUSTOM_DTS_PATH can be supported in > > > this case w/o patching new kernels. Probably it makes sense to convert > > > those out-of-tree dts files into proper kernel patches ? > > > > I see two options for patching the kernel: > > > > 1. Use Chris Packham's patch "kbuild: Restore the ability to build out > > of tree dtbs".[1] This works for me: if I drop the patch into > > board/acmesystems/acqua-a5/patches/linux/, I can change the kernel > > version to 6.12.4 and it just works. It seems like the path of least > > resistance for individual defconfigs, but I don't see this becoming > > Buildroot's blessed way of supporting custom DTSes. > > > > 2. Create a patch that adds the DTS to the kernel tree _and_ the DTB > > target to the relevant Makefile. I guess this is what you are > > suggesting. > > > > For what it's worth I implemented Masahiro's suggestion (basically option > 2) for our internal build tool at $dayjob. It's just a bit of sed-ing. It > works reasonably well. The trickiest part is avoiding repatching the > Makefile but for buildroot that's just a flag file. Are you sure you need to patch the Makefile? I've tested both compiling a dtso and a dts on the latest next. I've tried it on arm64 and copying it to a proper subdir in dts/ is working with $ make <subdir>/test.dtb To me, it looks like only the flat hierarchy isn't working anymore. But IMHO it was already wrong to copy a device tree to dts/ if there was a subdir structure in the first place. -michael > > If we go for the second option, then we would be saying that a kernel > > patch is the canonical way of providing a custom DTS. The > > BR2_LINUX_KERNEL_CUSTOM_DTS_PATH option would then have to be deprecated > > and eventually removed, which would be a breaking change for some users. > > > > I would persoanlly prefer updating the implementation of > > BR2_LINUX_KERNEL_CUSTOM_DTS_PATH in order to make it compatible with > > 6.12+ kernels. Maybe Buildroot could, in addition to copying the DTS to > > the kernel tree, add the relevant target to the Makefile. Basically do > > what the patch in method 2 is supposed to do. > > > > I could try to implement this approach, but it can take me some time > > (the `make' language is not my cup of tea). In the meantime, I suggest > > that, in your patch series, you update the help text of > > BR2_LINUX_KERNEL_CUSTOM_DTS_PATH in order to warn about this option > > being incompatible with kernels 6.12 and up. > > > > Regards, > > > > Edgar. > > > > [1] > > https://lore.kernel.org/all/20241015212830.3899891-1-chris.packham@alliedtelesis.co.nz/T/#u > > [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 297 bytes --] [-- Attachment #2: Type: text/plain, Size: 150 bytes --] _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 2024-12-13 10:09 ` Michael Walle via buildroot @ 2024-12-13 13:30 ` Sergey Matyukevich 2024-12-13 15:40 ` Edgar Bonet 0 siblings, 1 reply; 15+ messages in thread From: Sergey Matyukevich @ 2024-12-13 13:30 UTC (permalink / raw) To: Michael Walle; +Cc: Chris Packham, Edgar Bonet, buildroot Hi Michael, On Fri, Dec 13, 2024 at 11:09:45AM +0100, Michael Walle wrote: > On Wed Dec 11, 2024 at 7:26 PM CET, Chris Packham wrote: > > On Thu, 12 Dec 2024, 12:34 am Edgar Bonet, <bonet@grenoble.cnrs.fr> wrote: > > > > > Hello! > > > > > > About the incompatibility between Linux 6.12 and > > > BR2_LINUX_KERNEL_CUSTOM_DTS_PATH, Sergey Matyukevich wrote: > > > > IIUC at the moment Buildroot includes the following configurations > > > > that make use of BR2_LINUX_KERNEL_CUSTOM_DTS_PATH: [only 5 of them] > > > > > > Oh, I hadn't noticed there were so few of them! > > > > > > > Adding new v6.12 kernel is not going to break any of those boards > > > > right away. However if the build rule for drop-in dtbs will not be > > > > re-enabled (which seems likely), migration to new kernels will be a > > > > problem for those boards. > > > > > > Indeed, this is my concern: I maintain the defconfigs of the Acqua > > > boards (acmesystems_acqua_a5_*), and I would like to upgrade them to > > > Linux 6.12 before the Buildroot 2025.02 release. > > > > > > However, this issue will also affect users that build (or customize) > > > their own configurations with `make nconfig` or similar. If they select > > > > > > [x] Linux Kernel > > > [x] Build a Device Tree Blob (DTB) > > > (some_file) Out-of-tree Device Tree Source file paths > > > > > > and leave `Kernel version' to its default (which is "Latest version"), > > > they would end up with a non-functional configuration. > > > > > > > I don't see how BR2_LINUX_KERNEL_CUSTOM_DTS_PATH can be supported in > > > > this case w/o patching new kernels. Probably it makes sense to convert > > > > those out-of-tree dts files into proper kernel patches ? > > > > > > I see two options for patching the kernel: > > > > > > 1. Use Chris Packham's patch "kbuild: Restore the ability to build out > > > of tree dtbs".[1] This works for me: if I drop the patch into > > > board/acmesystems/acqua-a5/patches/linux/, I can change the kernel > > > version to 6.12.4 and it just works. It seems like the path of least > > > resistance for individual defconfigs, but I don't see this becoming > > > Buildroot's blessed way of supporting custom DTSes. > > > > > > 2. Create a patch that adds the DTS to the kernel tree _and_ the DTB > > > target to the relevant Makefile. I guess this is what you are > > > suggesting. > > > > > > > For what it's worth I implemented Masahiro's suggestion (basically option > > 2) for our internal build tool at $dayjob. It's just a bit of sed-ing. It > > works reasonably well. The trickiest part is avoiding repatching the > > Makefile but for buildroot that's just a flag file. > > Are you sure you need to patch the Makefile? I've tested both > compiling a dtso and a dts on the latest next. I've tried it on > arm64 and copying it to a proper subdir in dts/ is working with > > $ make <subdir>/test.dtb > > To me, it looks like only the flat hierarchy isn't working anymore. > But IMHO it was already wrong to copy a device tree to dts/ if there > was a subdir structure in the first place. > > -michael > > > > If we go for the second option, then we would be saying that a kernel > > > patch is the canonical way of providing a custom DTS. The > > > BR2_LINUX_KERNEL_CUSTOM_DTS_PATH option would then have to be deprecated > > > and eventually removed, which would be a breaking change for some users. > > > > > > I would persoanlly prefer updating the implementation of > > > BR2_LINUX_KERNEL_CUSTOM_DTS_PATH in order to make it compatible with > > > 6.12+ kernels. Maybe Buildroot could, in addition to copying the DTS to > > > the kernel tree, add the relevant target to the Makefile. Basically do > > > what the patch in method 2 is supposed to do. > > > > > > I could try to implement this approach, but it can take me some time > > > (the `make' language is not my cup of tea). In the meantime, I suggest > > > that, in your patch series, you update the help text of > > > BR2_LINUX_KERNEL_CUSTOM_DTS_PATH in order to warn about this option > > > being incompatible with kernels 6.12 and up. > > > > > > Regards, > > > > > > Edgar. > > > > > > [1] > > > https://lore.kernel.org/all/20241015212830.3899891-1-chris.packham@alliedtelesis.co.nz/T/#u > > > Thanks for sharing the results of your tests. Indeed, if drop-in dts files are still allowed in vendor subdirectories, then it should be possible to keep BR2_LINUX_KERNEL_CUSTOM_DTS_PATH functionality w/o converting dts files into patches or sed magic. I tried to implement a quick PoC using one of the acmesystems boards maintained by Edgar Bonet. Here is v0 which seems to be working (see at the bottom of this email). It looks like it can also be implemented w/o additional configuration option, e.g. drop-in dts files can be kept in appropriately named subdirectories: - board/acmesystems/acqua-a5/microchip/at91-sama5d3_acqua.dts Regards, Sergey P.S. example patch v0 that allows to successfully build acqua-a5 with updated kernel and out-of-tree dts: diff --git a/board/acmesystems/acqua-a5/at91-sama5d3_acqua.dts b/board/acmesystems/acqua-a5/at91-sama5d3_acqua.dts index 411d1942f5..60be8a67cd 100644 --- a/board/acmesystems/acqua-a5/at91-sama5d3_acqua.dts +++ b/board/acmesystems/acqua-a5/at91-sama5d3_acqua.dts @@ -9,7 +9,7 @@ * Licensed under GPLv2 or later. */ /dts-v1/; -#include "microchip/sama5d31.dtsi" +#include "sama5d31.dtsi" / { model = "Acme Systems Acqua SOM"; diff --git a/configs/acmesystems_acqua_a5_256mb_defconfig b/configs/acmesystems_acqua_a5_256mb_defconfig index b102dde0ba..c7025dc234 100644 --- a/configs/acmesystems_acqua_a5_256mb_defconfig +++ b/configs/acmesystems_acqua_a5_256mb_defconfig @@ -2,7 +2,7 @@ BR2_arm=y BR2_cortex_a5=y BR2_ARM_ENABLE_VFP=y BR2_ARM_INSTRUCTIONS_THUMB2=y -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_6=y +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_12=y BR2_GLOBAL_PATCH_DIR="board/acmesystems/acqua-a5/patches" BR2_DOWNLOAD_FORCE_CHECK_HASHES=y BR2_SYSTEM_DHCP="eth0" @@ -10,10 +10,11 @@ BR2_ROOTFS_POST_IMAGE_SCRIPT="support/scripts/genimage.sh" BR2_ROOTFS_POST_SCRIPT_ARGS="-c board/acmesystems/acqua-a5/genimage.cfg" BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_CUSTOM_VERSION=y -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.6.30" +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.12.3" BR2_LINUX_KERNEL_DEFCONFIG="sama5" BR2_LINUX_KERNEL_DTS_SUPPORT=y BR2_LINUX_KERNEL_CUSTOM_DTS_PATH="board/acmesystems/acqua-a5/at91-sama5d3_acqua.dts" +BR2_LINUX_KERNEL_CUSTOM_DTS_VENDOR="microchip" BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y BR2_TARGET_ROOTFS_EXT2=y BR2_TARGET_ROOTFS_EXT2_4=y diff --git a/linux/Config.in b/linux/Config.in index f537dd7adf..1b5d042782 100644 --- a/linux/Config.in +++ b/linux/Config.in @@ -425,6 +425,11 @@ config BR2_LINUX_KERNEL_CUSTOM_DTS_PATH will be copied to the kernel sources and the .dts files will be compiled from there. +config BR2_LINUX_KERNEL_CUSTOM_DTS_VENDOR + string "In-tree vendor for out-of-tree dts" + help + TBD + config BR2_LINUX_KERNEL_DTB_KEEP_DIRNAME bool "Keep the directory name of the Device Tree" help diff --git a/linux/linux.mk b/linux/linux.mk index 1d3d8fffa6..afc3c9ad2b 100644 --- a/linux/linux.mk +++ b/linux/linux.mk @@ -208,7 +208,7 @@ LINUX_DTS_NAME += $(call qstrip,$(BR2_LINUX_KERNEL_INTREE_DTS_NAME)) # and .dtsi files in BR2_LINUX_KERNEL_CUSTOM_DTS_PATH. Both will be # copied to arch/<arch>/boot/dts, but only the .dts files will # actually be generated as .dtb. -LINUX_DTS_NAME += $(basename $(filter %.dts,$(notdir $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH))))) +LINUX_DTS_NAME += $(addprefix $(BR2_LINUX_KERNEL_CUSTOM_DTS_VENDOR)/, $(basename $(filter %.dts,$(notdir $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH)))))) LINUX_DTBS = $(addsuffix .dtb,$(LINUX_DTS_NAME)) @@ -468,7 +468,7 @@ define LINUX_INSTALL_DTB # dtbs moved from arch/<ARCH>/boot to arch/<ARCH>/boot/dts since 3.8-rc1 $(foreach dtb,$(LINUX_DTBS), \ install -D \ - $(or $(wildcard $(LINUX_ARCH_PATH)/boot/dts/$(dtb)),$(LINUX_ARCH_PATH)/boot/$(dtb)) \ + $(or $(wildcard $(LINUX_ARCH_PATH)/boot/dts/$(dtb)),$(LINUX_ARCH_PATH)/boot/dts/$(dtb),$(LINUX_ARCH_PATH)/boot/$(dtb)) \ $(1)/$(if $(BR2_LINUX_KERNEL_DTB_KEEP_DIRNAME),$(dtb),$(notdir $(dtb))) ) endef @@ -516,7 +516,7 @@ endif define LINUX_BUILD_CMDS $(call KCONFIG_DISABLE_OPT,CONFIG_GCC_PLUGINS) $(foreach dts,$(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH)), \ - cp -f $(dts) $(LINUX_ARCH_PATH)/boot/dts/ + cp -f $(dts) $(LINUX_ARCH_PATH)/boot/dts/$(BR2_LINUX_KERNEL_CUSTOM_DTS_VENDOR)/ ) $(LINUX_MAKE_ENV) $(BR2_MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) all $(LINUX_MAKE_ENV) $(BR2_MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) $(LINUX_TARGET_NAME) _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 2024-12-13 13:30 ` Sergey Matyukevich @ 2024-12-13 15:40 ` Edgar Bonet 0 siblings, 0 replies; 15+ messages in thread From: Edgar Bonet @ 2024-12-13 15:40 UTC (permalink / raw) To: buildroot Hello! On 13/12/2024 14:30, Sergey Matyukevich wrote: > Hi Michael, > > On Fri, Dec 13, 2024 at 11:09:45AM +0100, Michael Walle wrote: >> On Wed Dec 11, 2024 at 7:26 PM CET, Chris Packham wrote: >>> On Thu, 12 Dec 2024, 12:34 am Edgar Bonet, <bonet@grenoble.cnrs.fr> wrote: >>> >>>> Hello! >>>> >>>> About the incompatibility between Linux 6.12 and >>>> BR2_LINUX_KERNEL_CUSTOM_DTS_PATH, Sergey Matyukevich wrote: >>>>> IIUC at the moment Buildroot includes the following configurations >>>>> that make use of BR2_LINUX_KERNEL_CUSTOM_DTS_PATH: [only 5 of them] >>>> >>>> Oh, I hadn't noticed there were so few of them! >>>> >>>>> Adding new v6.12 kernel is not going to break any of those boards >>>>> right away. However if the build rule for drop-in dtbs will not be >>>>> re-enabled (which seems likely), migration to new kernels will be a >>>>> problem for those boards. >>>> >>>> Indeed, this is my concern: I maintain the defconfigs of the Acqua >>>> boards (acmesystems_acqua_a5_*), and I would like to upgrade them to >>>> Linux 6.12 before the Buildroot 2025.02 release. >>>> >>>> However, this issue will also affect users that build (or customize) >>>> their own configurations with `make nconfig` or similar. If they select >>>> >>>> [x] Linux Kernel >>>> [x] Build a Device Tree Blob (DTB) >>>> (some_file) Out-of-tree Device Tree Source file paths >>>> >>>> and leave `Kernel version' to its default (which is "Latest version"), >>>> they would end up with a non-functional configuration. >>>> >>>>> I don't see how BR2_LINUX_KERNEL_CUSTOM_DTS_PATH can be supported in >>>>> this case w/o patching new kernels. Probably it makes sense to convert >>>>> those out-of-tree dts files into proper kernel patches ? >>>> >>>> I see two options for patching the kernel: >>>> >>>> 1. Use Chris Packham's patch "kbuild: Restore the ability to build out >>>> of tree dtbs".[1] This works for me: if I drop the patch into >>>> board/acmesystems/acqua-a5/patches/linux/, I can change the kernel >>>> version to 6.12.4 and it just works. It seems like the path of least >>>> resistance for individual defconfigs, but I don't see this becoming >>>> Buildroot's blessed way of supporting custom DTSes. >>>> >>>> 2. Create a patch that adds the DTS to the kernel tree _and_ the DTB >>>> target to the relevant Makefile. I guess this is what you are >>>> suggesting. >>>> >>> >>> For what it's worth I implemented Masahiro's suggestion (basically option >>> 2) for our internal build tool at $dayjob. It's just a bit of sed-ing. It >>> works reasonably well. The trickiest part is avoiding repatching the >>> Makefile but for buildroot that's just a flag file. >> >> Are you sure you need to patch the Makefile? I've tested both >> compiling a dtso and a dts on the latest next. I've tried it on >> arm64 and copying it to a proper subdir in dts/ is working with >> >> $ make <subdir>/test.dtb >> >> To me, it looks like only the flat hierarchy isn't working anymore. >> But IMHO it was already wrong to copy a device tree to dts/ if there >> was a subdir structure in the first place. >> >> -michael >> >>>> If we go for the second option, then we would be saying that a kernel >>>> patch is the canonical way of providing a custom DTS. The >>>> BR2_LINUX_KERNEL_CUSTOM_DTS_PATH option would then have to be deprecated >>>> and eventually removed, which would be a breaking change for some users. >>>> >>>> I would persoanlly prefer updating the implementation of >>>> BR2_LINUX_KERNEL_CUSTOM_DTS_PATH in order to make it compatible with >>>> 6.12+ kernels. Maybe Buildroot could, in addition to copying the DTS to >>>> the kernel tree, add the relevant target to the Makefile. Basically do >>>> what the patch in method 2 is supposed to do. >>>> >>>> I could try to implement this approach, but it can take me some time >>>> (the `make' language is not my cup of tea). In the meantime, I suggest >>>> that, in your patch series, you update the help text of >>>> BR2_LINUX_KERNEL_CUSTOM_DTS_PATH in order to warn about this option >>>> being incompatible with kernels 6.12 and up. >>>> >>>> Regards, >>>> >>>> Edgar. >>>> >>>> [1] >>>> https://lore.kernel.org/all/20241015212830.3899891-1-chris.packham@alliedtelesis.co.nz/T/#u >>>> > > Thanks for sharing the results of your tests. Indeed, if drop-in dts > files are still allowed in vendor subdirectories, then it should be > possible to keep BR2_LINUX_KERNEL_CUSTOM_DTS_PATH functionality w/o > converting dts files into patches or sed magic. > > I tried to implement a quick PoC using one of the acmesystems boards > maintained by Edgar Bonet. Here is v0 which seems to be working (see > at the bottom of this email). It looks like it can also be implemented > w/o additional configuration option, e.g. drop-in dts files can be kept > in appropriately named subdirectories: > - board/acmesystems/acqua-a5/microchip/at91-sama5d3_acqua.dts > > Regards, > Sergey > > P.S. example patch v0 that allows to successfully build acqua-a5 with > updated kernel and out-of-tree dts: > > diff --git a/board/acmesystems/acqua-a5/at91-sama5d3_acqua.dts b/board/acmesystems/acqua-a5/at91-sama5d3_acqua.dts > index 411d1942f5..60be8a67cd 100644 > --- a/board/acmesystems/acqua-a5/at91-sama5d3_acqua.dts > +++ b/board/acmesystems/acqua-a5/at91-sama5d3_acqua.dts > @@ -9,7 +9,7 @@ > * Licensed under GPLv2 or later. > */ > /dts-v1/; > -#include "microchip/sama5d31.dtsi" > +#include "sama5d31.dtsi" > > / { > model = "Acme Systems Acqua SOM"; > diff --git a/configs/acmesystems_acqua_a5_256mb_defconfig b/configs/acmesystems_acqua_a5_256mb_defconfig > index b102dde0ba..c7025dc234 100644 > --- a/configs/acmesystems_acqua_a5_256mb_defconfig > +++ b/configs/acmesystems_acqua_a5_256mb_defconfig > @@ -2,7 +2,7 @@ BR2_arm=y > BR2_cortex_a5=y > BR2_ARM_ENABLE_VFP=y > BR2_ARM_INSTRUCTIONS_THUMB2=y > -BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_6=y > +BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_6_12=y > BR2_GLOBAL_PATCH_DIR="board/acmesystems/acqua-a5/patches" > BR2_DOWNLOAD_FORCE_CHECK_HASHES=y > BR2_SYSTEM_DHCP="eth0" > @@ -10,10 +10,11 @@ BR2_ROOTFS_POST_IMAGE_SCRIPT="support/scripts/genimage.sh" > BR2_ROOTFS_POST_SCRIPT_ARGS="-c board/acmesystems/acqua-a5/genimage.cfg" > BR2_LINUX_KERNEL=y > BR2_LINUX_KERNEL_CUSTOM_VERSION=y > -BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.6.30" > +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.12.3" > BR2_LINUX_KERNEL_DEFCONFIG="sama5" > BR2_LINUX_KERNEL_DTS_SUPPORT=y > BR2_LINUX_KERNEL_CUSTOM_DTS_PATH="board/acmesystems/acqua-a5/at91-sama5d3_acqua.dts" > +BR2_LINUX_KERNEL_CUSTOM_DTS_VENDOR="microchip" > BR2_LINUX_KERNEL_NEEDS_HOST_OPENSSL=y > BR2_TARGET_ROOTFS_EXT2=y > BR2_TARGET_ROOTFS_EXT2_4=y > diff --git a/linux/Config.in b/linux/Config.in > index f537dd7adf..1b5d042782 100644 > --- a/linux/Config.in > +++ b/linux/Config.in > @@ -425,6 +425,11 @@ config BR2_LINUX_KERNEL_CUSTOM_DTS_PATH > will be copied to the kernel sources and the .dts files will > be compiled from there. > > +config BR2_LINUX_KERNEL_CUSTOM_DTS_VENDOR > + string "In-tree vendor for out-of-tree dts" > + help > + TBD > + > config BR2_LINUX_KERNEL_DTB_KEEP_DIRNAME > bool "Keep the directory name of the Device Tree" > help > diff --git a/linux/linux.mk b/linux/linux.mk > index 1d3d8fffa6..afc3c9ad2b 100644 > --- a/linux/linux.mk > +++ b/linux/linux.mk > @@ -208,7 +208,7 @@ LINUX_DTS_NAME += $(call qstrip,$(BR2_LINUX_KERNEL_INTREE_DTS_NAME)) > # and .dtsi files in BR2_LINUX_KERNEL_CUSTOM_DTS_PATH. Both will be > # copied to arch/<arch>/boot/dts, but only the .dts files will > # actually be generated as .dtb. > -LINUX_DTS_NAME += $(basename $(filter %.dts,$(notdir $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH))))) > +LINUX_DTS_NAME += $(addprefix $(BR2_LINUX_KERNEL_CUSTOM_DTS_VENDOR)/, $(basename $(filter %.dts,$(notdir $(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH)))))) > > LINUX_DTBS = $(addsuffix .dtb,$(LINUX_DTS_NAME)) > > @@ -468,7 +468,7 @@ define LINUX_INSTALL_DTB > # dtbs moved from arch/<ARCH>/boot to arch/<ARCH>/boot/dts since 3.8-rc1 > $(foreach dtb,$(LINUX_DTBS), \ > install -D \ > - $(or $(wildcard $(LINUX_ARCH_PATH)/boot/dts/$(dtb)),$(LINUX_ARCH_PATH)/boot/$(dtb)) \ > + $(or $(wildcard $(LINUX_ARCH_PATH)/boot/dts/$(dtb)),$(LINUX_ARCH_PATH)/boot/dts/$(dtb),$(LINUX_ARCH_PATH)/boot/$(dtb)) \ > $(1)/$(if $(BR2_LINUX_KERNEL_DTB_KEEP_DIRNAME),$(dtb),$(notdir $(dtb))) > ) > endef > @@ -516,7 +516,7 @@ endif > define LINUX_BUILD_CMDS > $(call KCONFIG_DISABLE_OPT,CONFIG_GCC_PLUGINS) > $(foreach dts,$(call qstrip,$(BR2_LINUX_KERNEL_CUSTOM_DTS_PATH)), \ > - cp -f $(dts) $(LINUX_ARCH_PATH)/boot/dts/ > + cp -f $(dts) $(LINUX_ARCH_PATH)/boot/dts/$(BR2_LINUX_KERNEL_CUSTOM_DTS_VENDOR)/ > ) > $(LINUX_MAKE_ENV) $(BR2_MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) all > $(LINUX_MAKE_ENV) $(BR2_MAKE) $(LINUX_MAKE_FLAGS) -C $(@D) $(LINUX_TARGET_NAME) Thanks! This works for me. After trying this patch (and with no `make clean'), I tried a couple other approaches that do not require the new configuration option BR2_LINUX_KERNEL_CUSTOM_DTS_VENDOR. They both seem to work: 1. Use "buildroot" as the vendor name. This requires creating a suitable Makefile in the new vendor directory, and patching the parent Makefile in order to include the new subdirectory: # update the defconfig and set # BR2_LINUX_KERNEL_CUSTOM_DTS_VENDOR="buildroot" # update the include path in the dts file dts_dir="output/build/linux-v6.12.3/arch/arm/boot/dts" make linux-dirclean make linux-extract mkdir $dts_dir/buildroot echo 'dtb-y += at91-sama5d3_acqua.dtb' > $dts_dir/buildroot/Makefile echo 'subdir-y += buildroot' >> $dts_dir/Makefile make linux 2. Drop the DTS to the top level DTS dir, as Buildroot used to do so far. This requires patching the top-level DTS Makefile, but the change is almost trivial: # remove BR2_LINUX_KERNEL_CUSTOM_DTS_VENDOR from the defconfig # update the include path in the dts file dts_dir="output/build/linux-v6.12.3/arch/arm/boot/dts" make linux-dirclean make linux-extract echo 'dtb-y += at91-sama5d3_acqua.dtb' >> $dts_dir/Makefile make linux Regards, Edgar Bonet. _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 2024-12-10 20:43 ` Sergey Matyukevich 2024-12-11 11:34 ` Edgar Bonet @ 2024-12-13 10:11 ` Michael Walle via buildroot 1 sibling, 0 replies; 15+ messages in thread From: Michael Walle via buildroot @ 2024-12-13 10:11 UTC (permalink / raw) To: Sergey Matyukevich, Edgar Bonet; +Cc: buildroot [-- Attachment #1.1: Type: text/plain, Size: 613 bytes --] Hi, > IIUC at the moment Buildroot includes the following configurations that > make use of BR2_LINUX_KERNEL_CUSTOM_DTS_PATH: > - acmesystems_acqua_a5_256mb_defconfig (v6.6) > - acmesystems_acqua_a5_512mb_defconfig (v6.6) > - octavo_osd32mp1_brk_defconfig (v5.10) > - octavo_osd32mp1_red_defconfig (v5.10) > - s6lx9_microboard_defconfig (v4.4.7) > > Kernel version from each config is specified in parentheses. Adding new > v6.12 kernel is not going to break any of those boards right away. What about buildroot externals? I'd presume they'll make extensive use of this very feature. -michael [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 297 bytes --] [-- Attachment #2: Type: text/plain, Size: 150 bytes --] _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 2024-12-08 21:46 [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 Sergey Matyukevich ` (3 preceding siblings ...) 2024-12-09 8:11 ` [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 Edgar Bonet @ 2024-12-11 13:43 ` Romain Naour via buildroot 2024-12-11 19:06 ` Romain Naour via buildroot 4 siblings, 1 reply; 15+ messages in thread From: Romain Naour via buildroot @ 2024-12-11 13:43 UTC (permalink / raw) To: Sergey Matyukevich, buildroot Cc: Giulio Benetti, Romain Naour, Thomas Petazzoni, Bernd Kuhls Hello Sergey, Le 08/12/2024 à 22:46, Sergey Matyukevich a écrit : > Hi Thomas, Bernd, and all > > I have been waiting for the new LTS Linux v6.12 in Buildroot to start > sending Christmas updates for some of my OrangePi boards. Now v6.12.3 > is already available, but the latest kernel is still have 6.11.x. > So I decided to undertake a copy-paste exercise using the latest kernel > and headers update series by Bernd. Hope I didn't miss a thing taking > into account that this is a new LTS. Everything seems good so far :) Applied to master, thanks. Best regards, Romain > > Regards, > Sergey > > Sergey Matyukevich (3): > {toolchain, linux-headers}: add support for 6.12 headers > linux: bump latest version to 6.12 > package/linux-headers: drop 6.11.x option > > Config.in.legacy | 7 +++++++ > linux/Config.in | 6 +++--- > linux/linux.hash | 2 +- > package/linux-headers/Config.in.host | 16 ++++++++++------ > toolchain/Config.in | 5 +++++ > .../toolchain-external-custom/Config.in.options | 6 +++++- > 6 files changed, 31 insertions(+), 11 deletions(-) > _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 2024-12-11 13:43 ` Romain Naour via buildroot @ 2024-12-11 19:06 ` Romain Naour via buildroot 2024-12-11 19:41 ` Sergey Matyukevich 0 siblings, 1 reply; 15+ messages in thread From: Romain Naour via buildroot @ 2024-12-11 19:06 UTC (permalink / raw) To: Sergey Matyukevich, buildroot Cc: Giulio Benetti, Romain Naour, Thomas Petazzoni, Bernd Kuhls Hello All, Le 11/12/2024 à 14:43, Romain Naour a écrit : > Hello Sergey, > > Le 08/12/2024 à 22:46, Sergey Matyukevich a écrit : >> Hi Thomas, Bernd, and all >> >> I have been waiting for the new LTS Linux v6.12 in Buildroot to start >> sending Christmas updates for some of my OrangePi boards. Now v6.12.3 >> is already available, but the latest kernel is still have 6.11.x. >> So I decided to undertake a copy-paste exercise using the latest kernel >> and headers update series by Bernd. Hope I didn't miss a thing taking >> into account that this is a new LTS. > > Everything seems good so far :) Except I missed the discussion about the out of tree DTBs issue reported by Chris Packham and Edgar Bonet [1] :-( [1] https://lore.kernel.org/buildroot/dcbd3f77-e737-41a2-9f23-87141d0bdf9b@grenoble.cnrs.fr/ Best regards, Romain > > Applied to master, thanks. > > Best regards, > Romain > > >> >> Regards, >> Sergey >> >> Sergey Matyukevich (3): >> {toolchain, linux-headers}: add support for 6.12 headers >> linux: bump latest version to 6.12 >> package/linux-headers: drop 6.11.x option >> >> Config.in.legacy | 7 +++++++ >> linux/Config.in | 6 +++--- >> linux/linux.hash | 2 +- >> package/linux-headers/Config.in.host | 16 ++++++++++------ >> toolchain/Config.in | 5 +++++ >> .../toolchain-external-custom/Config.in.options | 6 +++++- >> 6 files changed, 31 insertions(+), 11 deletions(-) >> > _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 2024-12-11 19:06 ` Romain Naour via buildroot @ 2024-12-11 19:41 ` Sergey Matyukevich 0 siblings, 0 replies; 15+ messages in thread From: Sergey Matyukevich @ 2024-12-11 19:41 UTC (permalink / raw) To: Romain Naour Cc: buildroot, Giulio Benetti, Romain Naour, Thomas Petazzoni, Bernd Kuhls Hi Romain, On Wed, Dec 11, 2024 at 08:06:42PM +0100, Romain Naour wrote: > Hello All, > > Le 11/12/2024 à 14:43, Romain Naour a écrit : > > Hello Sergey, > > > > Le 08/12/2024 à 22:46, Sergey Matyukevich a écrit : > >> Hi Thomas, Bernd, and all > >> > >> I have been waiting for the new LTS Linux v6.12 in Buildroot to start > >> sending Christmas updates for some of my OrangePi boards. Now v6.12.3 > >> is already available, but the latest kernel is still have 6.11.x. > >> So I decided to undertake a copy-paste exercise using the latest kernel > >> and headers update series by Bernd. Hope I didn't miss a thing taking > >> into account that this is a new LTS. > > > > Everything seems good so far :) > > Except I missed the discussion about the out of tree DTBs issue reported by > Chris Packham and Edgar Bonet [1] :-( > > [1] > https://lore.kernel.org/buildroot/dcbd3f77-e737-41a2-9f23-87141d0bdf9b@grenoble.cnrs.fr/ IIUC this out-of-tree DTB issue can be handled separately. As we discussed previously in this email thread, updating latest Linux version to v6.12 and further does not break those 5 boards now. Regards, Sergey > >> Regards, > >> Sergey > >> > >> Sergey Matyukevich (3): > >> {toolchain, linux-headers}: add support for 6.12 headers > >> linux: bump latest version to 6.12 > >> package/linux-headers: drop 6.11.x option > >> > >> Config.in.legacy | 7 +++++++ > >> linux/Config.in | 6 +++--- > >> linux/linux.hash | 2 +- > >> package/linux-headers/Config.in.host | 16 ++++++++++------ > >> toolchain/Config.in | 5 +++++ > >> .../toolchain-external-custom/Config.in.options | 6 +++++- > >> 6 files changed, 31 insertions(+), 11 deletions(-) > >> > > > _______________________________________________ buildroot mailing list buildroot@buildroot.org https://lists.buildroot.org/mailman/listinfo/buildroot ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2024-12-13 15:40 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-12-08 21:46 [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 Sergey Matyukevich
2024-12-08 21:46 ` [Buildroot] [PATCH 1/3] {toolchain, linux-headers}: add support for 6.12 headers Sergey Matyukevich
2024-12-08 21:46 ` [Buildroot] [PATCH 2/3] linux: bump latest version to 6.12 Sergey Matyukevich
2024-12-08 21:46 ` [Buildroot] [PATCH 3/3] package/linux-headers: drop 6.11.x option Sergey Matyukevich
2024-12-09 8:11 ` [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12 Edgar Bonet
2024-12-10 20:43 ` Sergey Matyukevich
2024-12-11 11:34 ` Edgar Bonet
2024-12-11 18:26 ` Chris Packham
2024-12-13 10:09 ` Michael Walle via buildroot
2024-12-13 13:30 ` Sergey Matyukevich
2024-12-13 15:40 ` Edgar Bonet
2024-12-13 10:11 ` Michael Walle via buildroot
2024-12-11 13:43 ` Romain Naour via buildroot
2024-12-11 19:06 ` Romain Naour via buildroot
2024-12-11 19:41 ` Sergey Matyukevich
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox