With the introduction of the production silicon Icicle Kit comes the
need to support multiple board device trees. The HSS puts a minimal dtb
in it's payload's ancillary-data immediately after U-Boot in memory.
CONFIG_OF_BOARD will use this dtb that the HSS carries with the bare
minimum of nodes enabled. It allows for firmware to provide the address
of the devicetree in memory using the `a1` register.
Use the device tree compatible from the hart software services to
essentially "detect" which board is in use and therefore select the
appropiate device tree for the board.
Add a fdt production node to the .its referencing the production Icicle
Kit DTB with appropriate attributes. Introduce matching configuration
entries to enable selection of the production Icicle kit FDT blob for
the MPFS Icicle Production Silicon board.
Update the configuration names to match the device tree compatibles for
each board configuration. With these updates, change image node and
configuration node names with more appropriate names.
Signed-off-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Following Microchip's Linux 2025.07 release, update the assets to the
latest versions, this includes a Linux version bump and addditional
U-Boot drivers and functionality. Update the Linux headers to support
the updated v6.12 kernel. Update the corresponding package hashes.
Signed-off-by: Jamie Gibbons <jamie.gibbons@microchip.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Buildroot commit d6c3257e93 bumped the
package from 0.21 to 0.23. Upstream release 0.22 includes commit
d7c7c53c06
which uses CLOCK_MONOTONIC without including time.h.
Fixes:
https://autobuild.buildroot.net/results/41b/41b25ee8e66e34323eca011e4b5fe479ece9ed76/
Two minimal defconfigs to reproduce the build error:
BR2_TOOLCHAIN_BUILDROOT_UCLIBC=y
BR2_PTHREADS_NONE=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PACKAGE_ATF=y
BR2_TOOLCHAIN_BUILDROOT_UCLIBC=y
BR2_PTHREADS_NONE=y
BR2_GCC_VERSION_13_X=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PACKAGE_ATF=y
All defconfigs of the build errors recorded by the buildroot autobuilders
contain BR2_PTHREADS_NONE=y.
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Update to the latest version of the gcnano-binaries blobs, which are
compatible with the last v6.6-stm32mp-r2 kernel from the
STMicroelectronics BSP.
Signed-off-by: Kory Maincent <kory.maincent@bootlin.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The Vulkan option was appended to QT6BASE_CONFIGURE_OPTS instead of
QT6BASE_CONF_OPTS, which is the variable actually used during CMake
configuration. This prevented the feature from being enabled/disabled
as expected.
Fixes: 1c27f3a12d ("package/qt6base: add vulkan option")
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This commit adds "kibi" a configurable text editor with UTF-8 support,
incremental search, syntax highlighting, line numbers and more, written
in less than 1024 lines of Rust with minimal dependencies.
https://github.com/ilai-deutel/kibi
Signed-off-by: Alexander Shirokov <shirokovalexs@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since the introduction of duktape in [1]. This package has been present
under the "JavaScript" sub-menu.
This sub-menu was mostly used for JS libraries and programs so duktape
should have been under the "Interpreter languages and scripting"
submenu.
Since duktape is now the only entry in the JavaScript submenu, move this
package to a better suited place and remove the JavaScript submenu.
[1] 387ff26b6d duktape: new package
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch adds information on how to provides static JS libraries in
Buildroot with the release of the 2025.08.x version.
Because the way JavaScript project development is working the chances that your
project is using the same version of the buildroot package, and you provide
this library from `/var/www` to your users is actually really low ...
If you want to bundle JavaScript libraries in your project you should probably
either use a cdn, handle the package version and location of your choice in
your external or overlay, or just bundle it in your assets from a NPM workflow
to benefit from some minifications from your bundler.
Historically many of those JavaScript libraries were added in the 2010 eras
where it could make sense for them to be part of Buildroot.
Most of them are also way outdated/not maintained.
For more informations see https://elinux.org/Buildroot:DeveloperDaysELCE2025
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Due to the increasing number of patches applied for this package and the
lack of updates to fix the build issues as well as updating the version
to newer release. This patch removes softether from buildroot package
list.
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch add several upstream patches that fix build error we are
experiencing on the autobuilder related to host-gcc15 and gcc14.
- 0010-use-bool-from-stdbool.patch
Fix a host-gcc15 error with C23 bool reserved keyword when building
host-softether package. This appeared on the autobuilder.
```
from Cfg.c:116:
../../src/Mayaqua/MayaType.h:257:33: error: 'bool' cannot be defined via 'typedef'
257 | typedef unsigned int bool;
| ^~~~
../../src/Mayaqua/MayaType.h:257:33: note: 'bool' is a keyword with '-std=c23' onwards
../../src/Mayaqua/MayaType.h:257:1: warning: useless type name in empty declaration
257 | typedef unsigned int bool;
| ^~~~~~~
```
- 0011-fix-implicit-declaration-of-function-getch.patch
Fix an implicit function declaration.
- 0012-vlanunix-fix-implicit-declaration-of-function-freetap.patch
Fix an implicit function declaration.
- 0013-fix-build-on-freebsd-version-140091.patch
Incompatible pointer type which appeared on the autobuilder as well:
```
Unix.c: In function 'UnixIgnoreSignalForThread':
Unix.c:324:25: error: assignment to 'void (*)(int, siginfo_t *, void *)' from incompatible pointer type 'void * (*)(int, siginfo_t *, void *)' [-Wincompatible-pointer-types]
324 | sa.sa_sigaction = signal_received_for_ignore;
| ^
```
- 0014-cedar-hub-properly-set-value-for-hub-admin-options.patch
Fix an incompatible pointer type error.
- 0015-adjust-types-of-variables.patch
Fix an incompatible pointer type error which appeared on the autobuilder as
well.
```
Secure.c: In function 'OpenSec':
Secure.c:1829:56: error: passing argument 3 of 'sec->Api->C_GetSlotList' from incompatible pointer type [-Wincompatible-pointer-types]
1829 | if ((err = sec->Api->C_GetSlotList(true, NULL, &sec->NumSlot)) != CKR_OK || sec->NumSlot == 0)
| ^~~~~~~~~~~~~
| |
| UINT * {aka unsigned int *}
```
- 0016-Cedar-Proto_IKE-fix-too-many-arguments-to-function-N.patch
Fix a function call.
Fixes: https://autobuild.buildroot.org/results/c43/c43a9a221896d37ee8a9d34c5b8e2725351c6eb5
Fixes: https://autobuild.buildroot.org/results/751/7517bb4d32c38d475d901769b0b2fd2c2f3dd543
Signed-off-by: Thomas Perale <thomas.perale@mind.be>
Acked-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
An advanced terminal multiplexer with batteries included. Supports
layouts, floating and stacked panes, plugins, and customization.
Provides rich functionality out of the box.
Zellij is aimed at developers, operations-oriented users, and anyone who
loves the terminal.
https://github.com/zellij-org/zellij
Signed-off-by: Alexander Shirokov <shirokovalexs@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The license is actually LGPL-2.1+.
Fixes: 006aab8d64 ("package/libplacebo: add libplacebo package")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This patch adds libplacebo package that is used
by mpv player.
libplacebo is the core rendering algorithms and
ideas of mpv rewritten as an independent library
and contains a large assortment of video processing
shaders, focusing on both quality and performance.
Signed-off-by: Javad Rahimipetroudi <javad.rahimipetroudi@mind.be>
Tested-by: Sen Hastings <sen@hastings.org>
[Bernd:
- bumped to v7.351.0
- moved Kconfig option to Multimedia (Sen)
- rebased patch 0001 after version bump
- added project URL to Config.in helptext
- removed redundancy in Config.in comment
- added comment to hash file
- switched _SITE to official repo
- added patch to fix build error with latest python3]
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
