[Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12

[Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12

[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

[Buildroot] [PATCH 1/3] {toolchain, linux-headers}: add support for 6.12 headers

[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

[Buildroot] [PATCH 2/3] linux: bump latest version to 6.12

[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

[Buildroot] [PATCH 3/3] package/linux-headers: drop 6.11.x option

[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

Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12

[Edgar Bonet]

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

Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12

[Sergey Matyukevich]

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

Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12

[Edgar Bonet]

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

Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12

[Romain Naour via buildroot]

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

Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12

[Chris Packham]

[-- 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

Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12

[Romain Naour via buildroot]

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

Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12

[Sergey Matyukevich]

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

Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12

[Michael Walle via 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

Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12

[Michael Walle via 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

Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12

[Sergey Matyukevich]

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

Re: [Buildroot] [PATCH 0/3] {linux, linux-headers}: add support for 6.12

[Edgar Bonet]

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