The 6.14.x series is now EOL upstream, so drop the linux-headers
option and add legacy handling for it.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The 6.13.x series is now EOL upstream, so drop the linux-headers
option and add legacy handling for it.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Since Linux 6.12, the Buildroot option BR2_LINUX_KERNEL_CUSTOM_DTS_PATH
does not work as expected on arm, arm64, mips and riscv[1]. These are
the architectures that store the in-tree DTS files in vendor-specific
subdirectories of arch/$ARCH/boot/dts/.
BR2_LINUX_KERNEL_CUSTOM_DTS_PATH was introduced in Buildroot 2012.08
(commit 69fc497df0 "Rework support for the device tree"). At the time,
the kernel kept all in-tree DTS files directly in arch/$ARCH/boot/dts/,
and this is where Buildroot drops the user's custom DTS. Vendor-specific
subdirectories appeared in Linux v3.19 for the arm64 architecture, and
this scheme was later adopted by mips, riscv and arm.
For these architectures, Linux 6.12 (commit e7e2941300d2, "kbuild: split
device tree build rules into scripts/Makefile.dtbs") made the DTB build
infrastructure incompatible with the way
BR2_LINUX_KERNEL_CUSTOM_DTS_PATH is implemented. This infrastructure now
expects all DTS files to be in vendor-specific subdirectories on the
architectures that use this scheme.
We can't update easily the current behavior of
BR2_LINUX_KERNEL_CUSTOM_DTS_PATH since it expect a list of files but
can also be used "unexpectedly" with directories [2].
BR2_LINUX_KERNEL_INTREE_DTS_NAME="st/stm32mp135f-dk-mx"
BR2_LINUX_KERNEL_CUSTOM_DTS_PATH="$(BR2_EXTERNAL_ST_PATH)/[...]/linux-dts/st"
In this case, the st directory is copied into the arch/$ARCH/boot/dts/
and BR2_LINUX_KERNEL_INTREE_DTS_NAME is used to build stm32mp135f-dk-mx dtb
as if it was intree.
Introduce BR2_LINUX_KERNEL_CUSTOM_DTS_DIR configuration
parameter to specify a list of directories that are copied as-is over
the arch/<arch>/boot/dts/ directory before building the device tree
blob:
board/acmesystems/acqua-a5/dts/
└── microchip
└── at91-sama5d3_acqua.dts
defconfig:
BR2_LINUX_KERNEL_CUSTOM_DTS_DIR="board/acmesystems/acqua-a5/dts"
Each dts file found is automatically added to the list of devicetree
to build.
BR2_LINUX_KERNEL_CUSTOM_DTS_DIR can also be used for external
devicetree overlays files:
board/ti/am574x-idk/dts/
└── ti
└── omap
└── am57xx-evm.dtso
With this new option, BR2_LINUX_KERNEL_CUSTOM_DTS_PATH is now deprecated.
Note: We want to create a list of dts files (LINUX_DTS_LIST) present in
diectrories listed by BR2_LINUX_KERNEL_CUSTOM_DTS_DIR. But
LINUX_DTS_LIST must not contain BR2_LINUX_KERNEL_CUSTOM_DTS_DIR
paths. Use GNU 'find' print format %P to print each dts file path
without their respective dts overlay directory path.
Do the same for LINUX_DTSO_LIST.
Thanks to Edgar Bonet for the initial contribution [3].
[1] https://lists.buildroot.org/pipermail/buildroot/2024-October/765463.html
[2] 541ba7d963/configs/st_stm32mp135f_dk_demo_defconfig (L21)
[3] https://lore.kernel.org/buildroot/93f83afb-6987-441c-8e06-dab4d43b828f@grenoble.cnrs.fr/
Cc: Michael Walle <michael@walle.cc>
Cc: Gaël PORTAY <gael.portay+rtone@gmail.com>
Reported-by: Chris Packham <judge.packham@gmail.com>
Signed-off-by: Edgar Bonet <bonet@grenoble.cnrs.fr>
[Romain:
- Rework the initial contribution by Edgar Bonet by
BR2_LINUX_KERNEL_CUSTOM_DTS_DIR following
Michael Walle comments and Gaël PORTAY review.
- Reword the commit log accordingly.
]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The linux kernel can build device tree overlays (.dtbo) itself. Add
support to build and copy them along with the actual device trees.
These can either be in-tree device tree overlays
(BR2_LINUX_KERNEL_INTREE_DTSO_NAMES) or they can be provided outside of
the kernel (BR2_LINUX_KERNEL_CUSTOM_DTS_PATH). In the latter case, the
overlay source files will be copied into the kernel tree first.
Signed-off-by: Michael Walle <michael@walle.cc>
Reviewed-by: Niklas Cassel <niklas.cassel@wdc.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The handling of BR2_LINUX_KERNEL_USE_ARCH_DEFAULT_CONFIG is currently
not doing a proper job: it is selecting ppc64le_defconfig if
BR2_powerpc64le, and using the default of "defconfig" for everything
else.
However:
- Since upstream commit 22f17b02f88b48c01d3ac38d40d2b0b695ab2d10,
which landed in Linux 6.8, the default defconfig is
ppc64le_defconfig and no longer ppc64_defconfig. This means that
despite the condition in linux.mk, we are in fact now always
building ppc64le_defconfig.
- It doesn't handle the 32-bit case, as a 64-bit defconfig gets used
by default. This causes build failures in the autobuilders.
To fix this we explicitly handle BR2_powerpc64le, BR2_powerpc64 and
BR2_powerpc, and use appropriate defconfigs for each case.
Fixes:
http://autobuild.buildroot.net/results/c15eaf2e7455aa265cc045e6d8be7cac5348d925/ (powerpc)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
In the latest kernel, U-Boot images are always generated when building
a kernel for NIOS2. Note that we build the kernel with:
make all
make <selected-image>
so the selected image through Buildroot options doesn't matter: a
U-Boot image is always generated.
Therefore, in order to fix autobuilder issues, make sure
host-uboot-tools are always selected when building the latest kernel
version. We do not select it in general as custom versions may be
different.
Fixes:
http://autobuild.buildroot.net/results/1d4c249887bdd78dab40152ad3a4fcef16458a1a/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
The 4.19.x series is now EOL upstream, so drop the linux-headers option
and add legacy handling for it.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Julien Olivain <ju.o@free.fr>
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>
Signed-off-by: Romain Naour <romain.naour@smile.fr>