From Andreas Dannenberg (TI K3 architect) [1]:
"HS-FS should be the default for all TI AM6x devices. This is our
"production silicon" and what's used for (almost) all projects,
especially new projects. This being said having support for GP device
variants still is desirable for existing boards/projects, such as the
current BeaglePlay boards (amongst earlier version of TI starter kit
EVMs for AM6x)."
See further details on e2e Forum [2]:
"Unfortunately with this transition any existing GP device based AM62x
(and AM64x) boards will no longer boot with MMC/SD card images generated"
For such existing GP device based AM62x (and AM64x) boards, users have
to provide the tiboot3.bin name using BR2_TARGET_TI_K3_R5_LOADER_TIBOOT3_BIN.
[1] http://lists.busybox.net/pipermail/buildroot/2024-February/685821.html
[2] https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1210443/faq-am625-generating-sitara-am62x-am62ax-am64x-gp-device-bootable-mmc-sd-card-images-using-sdk-v8-6-and-yocto
Reviewed-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Since all AM62 and AM64 defconfig has been updated to use binman
and ti-k3-image-gen has been removed, binman is now mandatory
for all TI K3 SoC. So remove BR2_TARGET_TI_K3_R5_LOADER_USE_BINMAN
option since since it can't be disabled anymore.
We can remove BR2_TARGET_TI_K3_R5_LOADER_USE_BINMAN without
legacy handling since this option is not part of any Buildroot
release.
While at it, add one more like to binman dependencies in comments.
Reviewed-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
ti-k3-image-gen tool is deprecated an replaced by binman [1].
All defconfig that was using it have been updated to use U-boot
binman tool instead.
So, we can safely remove ti-k3-image-gen package.
[1] https://git.yoctoproject.org/meta-ti/commit/?id=835811cf8586926cf78a961d090f4e6150432235
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Xuanhao Shi <X15000177@gmail.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Reviewed-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Previoulsy (without binman), when a TI K3 SoC using Combined binary
with a split firmware boot method was used (am62ax or am62x) [1], the
user had to select BR2_TARGET_UBOOT_NEEDS_TI_K3_DM in the defconfig
to provide Device Manager firmware provided by ti-k3-boot-firmware.
With binman, this option is no longer necessary since
ti-k3-boot-firmware package is already in the u-boot dependency and the
path to DM and SYSFW binaries are provided by BINMAN_INDIRS.
We are going to remove ti-k3-image-gen, so binman is now mandatory on
all TI K3 SoCs.
[1] 52ce606c05
Reviewed-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
The 2024.01 version of U-Boot for the am64x-sk board has introduced two
major changes:
- The device tree k3-am642-sk.dtb is no longer searched in /boot, but in
/boot/dtb/ti. Hence, the disabling of BR2_LINUX_KERNEL_INSTALL_TARGET
and the use of extlinux.conf for the proper loading of the device tree.
Furthermore, the parameter BR2_ROOTFS_POST_SCRIPT_ARGS was used to
auto-generate the extlinux.conf file so that developers can change the
kernel loading options by modifying the .config.
- U-Boot is capable of building tiboot3.bin using Binman. So it's no longer
necessary to use custom tools like ti-k3-image-gen.
- Use a custom tiboot3.bin since the default is "hs-fs",
but the ti_am64x_sk_defconfig expect the "gp" one.
Tested-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Tested-by: Michael Trimarchi <michael@amarulasolutions.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Tested-by: Gero Schwäricke <gero.schwaericke@grandcentrix.net>
Tested-by: Bryan Brattlof <bb@ti.com>
Reviewed-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
The patch makes it clear that the moved script can be used by the
am6{2,4}x platforms.
Reviewed-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Removing any explicit reference to the ti_am62x_sk_defconfig
configuration, the script can also be used by other configurations or at
least by ti_am64x_sk_defconfig.
Reviewed-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
The 2024.01 version of U-Boot for the am62x-sk board has introduced two
major changes:
- The device tree k3-am625-sk.dtb is no longer searched in /boot, but in
/boot/dtb/ti. Hence, the disabling of BR2_LINUX_KERNEL_INSTALL_TARGET
and the use of extlinux.conf for the proper loading of the device tree.
Furthermore, the parameter BR2_ROOTFS_POST_SCRIPT_ARGS was used to
auto-generate the extlinux.conf file so that developers can change the
kernel loading options by modifying the .config.
- U-Boot is capable of building tiboot3.bin using Binman. So it's no longer
necessary to use custom tools like ti-k3-image-gen.
- Use a custom tiboot3.bin since the default is "hs-fs",
but the ti_am62x_sk_defconfig expect the "gp" one
Tested on SK-AM62B-P1.
Tested-by: Alexander Sverdlin <alexander.sverdlin@gmail.com>
Tested-by: Michael Trimarchi <michael@amarulasolutions.com>
Tested-by: Andreas Dannenberg <dannenberg@ti.com>
Tested-by: Gero Schwäricke <gero.schwaericke@grandcentrix.net>
Tested-by: Bryan Brattlof <bb@ti.com>
Reviewed-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
With binman support enabled, u-boot for k3 r5 core (ti-k3-r5-loader)
install different target image (tiboot3*.bin) depending on the K3
SoC boot ROM:
- General Purpose devices (gp)
- High Security - Field Securable devices (hs-fs)
- High Security - Security Enforcing devices (hs)
An additional firmware binary is required on certain TI K3 devices such
as AM65 and J721e due to the "Split binary" boot flow [1]:
- Split binary with a combined firmware: (eg: AM65)
- Combined binary with a combined firmware: (eg: AM64)
- Split binary with a split firmware: (eg: J721E)
- Combined binary with a split firmware: (eg: AM62)
K3 SoC using Split Binary Boot Flow also requires sysfw-*.itb file
to boot (eg: am65, j721e). Only tiboot3*.bin is needed for other
boot flow.
From [1]:
"It's important to rename the generated tiboot3.bin and sysfw.itb
to match exactly tiboot3.bin and sysfw.itb as ROM and the wakeup
UBoot SPL will only look for and load the files with these names."
See the (not exhaustive) list of all tiboot3*.bin and sysfw*.itb file
variant found in meta-ti:
meta-ti-bsp/conf/machine/beaglebone-ai64-k3r5.conf:UBOOT_IMAGE = "tiboot3-${MAINMACHINE}-${PV}-${PR}.${UBOOT_SUFFIX}"
meta-ti-bsp/conf/machine/beaglebone-ai64-k3r5.conf:UBOOT_SYMLINK = "tiboot3-${MAINMACHINE}.${UBOOT_SUFFIX}"
meta-ti-bsp/conf/machine/include/am62axx.inc:IMAGE_BOOT_FILES += "tiboot3-am62ax-hs-fs-evm.bin"
meta-ti-bsp/conf/machine/include/am62axx.inc:IMAGE_BOOT_FILES += "tiboot3-am62ax-gp-evm.bin"
meta-ti-bsp/conf/machine/include/am62axx.inc:IMAGE_BOOT_FILES += "tiboot3-am62ax-hs-evm.bin"
meta-ti-bsp/conf/machine/include/am62pxx.inc:IMAGE_BOOT_FILES += "tiboot3-am62px-hs-fs-evm.bin"
meta-ti-bsp/conf/machine/include/am62xx.inc:IMAGE_BOOT_FILES += "tiboot3-am62x-hs-fs-evm.bin"
meta-ti-bsp/conf/machine/include/am62xx.inc:IMAGE_BOOT_FILES += "tiboot3-am62x-gp-evm.bin"
meta-ti-bsp/conf/machine/include/am62xx.inc:IMAGE_BOOT_FILES += "tiboot3-am62x-hs-evm.bin"
meta-ti-bsp/conf/machine/include/am64xx.inc:IMAGE_BOOT_FILES += "tiboot3-am64x_sr2-hs-fs-evm.bin"
meta-ti-bsp/conf/machine/include/am64xx.inc:IMAGE_BOOT_FILES += "tiboot3-am64x-gp-evm.bin"
meta-ti-bsp/conf/machine/include/am64xx.inc:IMAGE_BOOT_FILES += "tiboot3-am64x_sr2-hs-evm.bin"
meta-ti-bsp/conf/machine/include/am65xx.inc:IMAGE_BOOT_FILES += "tiboot3-am65x_sr2-gp-evm.bin"
meta-ti-bsp/conf/machine/include/am65xx.inc:IMAGE_BOOT_FILES += "tiboot3-am65x_sr2-hs-evm.bin"
meta-ti-bsp/conf/machine/include/j7200.inc:IMAGE_BOOT_FILES += "tiboot3-j7200-gp-evm.bin"
meta-ti-bsp/conf/machine/include/j7200.inc:IMAGE_BOOT_FILES += "tiboot3-j7200_sr2-hs-fs-evm.bin"
meta-ti-bsp/conf/machine/include/j7200.inc:IMAGE_BOOT_FILES += "tiboot3-j7200_sr2-hs-evm.bin"
meta-ti-bsp/conf/machine/include/j721e.inc:IMAGE_BOOT_FILES += "tiboot3-j721e-gp-evm.bin"
meta-ti-bsp/conf/machine/include/j721e.inc:IMAGE_BOOT_FILES += "tiboot3-j721e_sr2-hs-fs-evm.bin"
meta-ti-bsp/conf/machine/include/j721e.inc:IMAGE_BOOT_FILES += "tiboot3-j721e_sr1_1-hs-evm.bin"
meta-ti-bsp/conf/machine/include/j721s2.inc:IMAGE_BOOT_FILES += "tiboot3-j721s2-gp-evm.bin"
meta-ti-bsp/conf/machine/include/j721s2.inc:IMAGE_BOOT_FILES += "tiboot3-j721s2-hs-fs-evm.bin"
meta-ti-bsp/conf/machine/include/j722s.inc:IMAGE_BOOT_FILES += "tiboot3-j722s-hs-fs-evm.bin"
meta-ti-bsp/conf/machine/include/j784s4.inc:IMAGE_BOOT_FILES += "tiboot3-j784s4-gp-evm.bin"
meta-ti-bsp/conf/machine/include/j784s4.inc:IMAGE_BOOT_FILES += "tiboot3-j784s4-hs-fs-evm.bin"
meta-ti-bsp/conf/machine/include/k3r5.inc:SPL_BINARY = "tiboot3-${SYSFW_SOC}-${SYSFW_SUFFIX}-${SYSFW_CONFIG}.${SPL_SUFFIX}"
meta-ti-bsp/conf/machine/include/am65xx.inc:IMAGE_BOOT_FILES += "sysfw.itb"
meta-ti-bsp/conf/machine/include/am65xx.inc:IMAGE_BOOT_FILES += "sysfw-am65x_sr2-gp-evm.itb"
meta-ti-bsp/conf/machine/include/am65xx.inc:IMAGE_BOOT_FILES += "sysfw-am65x_sr2-hs-evm.itb"
meta-ti-bsp/conf/machine/include/j721e.inc:IMAGE_BOOT_FILES += "sysfw.itb"
meta-ti-bsp/conf/machine/include/j721e.inc:IMAGE_BOOT_FILES += "sysfw-j721e-gp-evm.itb"
meta-ti-bsp/conf/machine/include/j721e.inc:IMAGE_BOOT_FILES += "sysfw-j721e_sr2-hs-fs-evm.itb"
meta-ti-bsp/conf/machine/include/j721e.inc:IMAGE_BOOT_FILES += "sysfw-j721e_sr1_1-hs-evm.itb"
This firmware list can also be verified with the firmware name used in
the u-boot devicetree k3-*-binman.dtsi files.
On the SK-AM62B-P1, three tiboot3 binaries are built, one for each boot
ROM variant:
tiboot3-am62x-gp-evm.bin
tiboot3-am62x-hs-evm.bin
tiboot3-am62x-hs-fs-evm.bin
A tiboot3.bin symlink is provided as default choice:
tiboot3.bin -> tiboot3-am62x-hs-fs-evm.bin
On this board, the tiboot3.bin symlink links to the hs-fs variant
but it not always de case for all TI K3 devices.
(ex: J721e use gp variant by default).
The tiboot3.bin symlink links the -gp, -hs-fs, -hs tiboot3 binary
according to where "symlink = "tiboot3.bin";" line is located in
k3-*binman.dtsi.
As reported by Michael Walle [2], such firmware name can also be
customized by a SBC vendor [3], so we can't always be sure which
firmware to use.
If required, let the user provide a custom tiboot3 or sysfw firmware
name from the defconfig. Otherwise use the default firmware choice
by copying tiboot3.bin and sysfw.itb symlinks.
[1] https://source.denx.de/u-boot/u-boot/-/blob/v2024.01/doc/board/ti/k3.rst
[2] http://lists.busybox.net/pipermail/buildroot/2024-April/688943.html
[3] https://elixir.bootlin.com/u-boot/v2024.04/source/arch/arm/dts/k3-am625-phycore-som-binman.dtsi#L14
Reviewed-by: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Since crucible commit 7fe0bb96da65 ("move to BSD style license") the
license has been changed to BSD-3. This changed happened for the
2023.11.02 release of crucible, to which the Buildroot package was
bumped in Buildroot commit be3f95ed14.
Change the license type and hash accordingly.
Fixes:
- http://autobuild.buildroot.net/results/14dfa0a47be54929c527c12fe9b95f34c1d8c7f5/
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
- Support i.MX91
- Fix a crash with -d option when change back file.
Release notes:
https://github.com/nxp-imx/mfgtools/releases/tag/uuu_1.5.177
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Drop patches (already in version) and so also drop autoreconf
https://github.com/networkupstools/nut/releases/tag/v2.8.2
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
tests are enabled by default since the addition of the package in commit
5d74d39cb4
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Although -Wmain-return-type is not considered as error (unlike
-Wimplicit-int), but just a warning, let's fix it for the future.
<stdin>:1:1: warning: return type of 'main' is not 'int' [-Wmain-return-type]
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Recent version of U-Boot use binman to provide a mechanism for building
images, from simple SPL + U-Boot combinations, to more complex
arrangements with many parts.
This tool uses additional host python modules that must be provided by
Buildroot. So introduce a new option BR2_TARGET_UBOOT_USE_BINMAN to
add additional host packages in U-Boot build dependency to use binman.
The binman requirement is directly included in buildman dependency
(tools/buildman/requirements.txt) since within U-Boot, binman is
invoked by the build system, here buildman [1].
[1] https://docs.u-boot.org/en/v2024.01/develop/package/binman.html#invoking-binman-within-u-boot
Co-developed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Recent version of U-Boot use binman to provide a mechanism for building
images, from simple SPL + U-Boot combinations, to more complex
arrangements with many parts.
This tool uses additional host python modules that must be provided by
Buildroot. So introduce a new option
BR2_TARGET_TI_K3_R5_LOADER_USE_BINMAN to add additional host packages
in U-Boot build dependency to use binman.
When BR2_TARGET_TI_K3_R5_LOADER_USE_BINMAN is set, BINMAN_INDIRS
environment variable to provide the directory to search for binary
blobs and select the packages required by binman. Make sure that
ti-k3-boot-firmware package has been installed before building
ti-k3-r5-loader in order to provide such firmwares.
The BR2_TARGET_TI_K3_R5_LOADER_USE_BINMAN option is currently needed
since we are in the middle of the process to switch TI AM62 and AM64
board defconfig to binman. Keep BR2_TARGET_TI_K3_R5_LOADER_USE_BINMAN
disabled for them until the u-boot/ti-k3-r5-loader version bump to
2024.01.
The dependency of binman is not really easy to follow. First we have
the packages list from binman.rst [1] then we have to install
additional python modules [2]. Maybe in the future it will be
necessary to add host-lzma and host-lz4 in the dependencies list.
[1] https://source.denx.de/u-boot/u-boot/-/blob/v2024.01/tools/binman/binman.rst?plain=1#L377
[2] https://source.denx.de/u-boot/u-boot/-/blob/v2024.01/tools/buildman/requirements.txt
Co-developed-by: Michael Trimarchi <michael@amarulasolutions.com>
Signed-off-by: Michael Trimarchi <michael@amarulasolutions.com>
Co-developed-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
BR2_TARGET_UBOOT_NEEDS_TI_K3_DM option has been introduced initially to
support certain TI K3 devices such as AM62x and AM62Ax that require a
Device Manager (DM) firmware.
This option needs to be renamed to use a more generic name in order
to cover further TI K3 SoCs support along with the new u-boot binman
tool that will be added in followup patch. With binman enabled in
u-boot on TI K3 SoC, ti-k3-boot-firmware is needed at buildtime to
provide ti-sysfw (System Firmware) for all TI K3 SoC along with Device
Manager (DM) firmware for AM62x and AM62Ax devices.
With binman support enabled, we don't need to provide the path of the
Device Manager firmware anymore (see [2]).
We can remove DM="<DM firmware>.xer5f" from UBOOT_MAKE_OPTS.
It also means that we can also remove BR2_TARGET_UBOOT_TI_K3_DM_SOCNAME
used to define DM path.
DM=$(BINARIES_DIR)/ti-dm/$(UBOOT_TI_K3_DM_SOCNAME)/ipc_echo_testb_mcu1_0_release_strip.xer5f
For now, keep BR2_TARGET_UBOOT_TI_K3_DM_SOCNAME and DM only when
ti-k3-image-gen is used. We need to update ti_am62x_sk_defconfig
to use binman before removing them along with ti-k3-image-gen.
[1] 52ce606c05
[2] https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/09_01_00_08/exports/docs/linux/Foundational_Components/U-Boot/UG-General-Info.html
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
We are going to enable BR2_DOWNLOAD_FORCE_CHECK_HASHES by default
to enforce downloads to have at least one valid hash including
those that use a custom version.
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
The patch removes the hash for version 2022.10 of ti-k3-r5-loader
(i. e. U-Boot). Instead, it is added to a custom hash file in the
global patch dir of the ti_am6{2,4]x_sk_defconfig configurations.
Link: https://patchwork.ozlabs.org/project/buildroot/patch/20240304153253.732708-6-dario.binacchi@amarulasolutions.com
Suggested-by: Yann E. Morin <yann.morin.1998@free.fr>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
openssl is optional, not mandatory since the addition of the package in
commit 8aaa7ecbce
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Fix the following build failure with gcc >= 13:
In file included from ../src/basic/macro.h:446,
from ../src/basic/alloc-util.h:10,
from ../src/shared/install.c:12:
../src/shared/install.c: In function ‘install_changes_dump’:
../src/shared/install.c:444:64: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
444 | err = log_error_errno(changes[i].type, "Failed to %s unit, unit %s does not exist.",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/e0d6b7d41fefec539a17a3ef5c89c192ce29fd04
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
- Fix a potential denial of service caused by accepting arbitrary
length primes as potential elliptic curve parameters in ASN.1
encodings. With very large inputs the primality verification
can become computationally expensive. Now any prime field larger
than 1024 bits is rejected immediately.
https://botan.randombit.net/news.html#version-3-3-0-2024-02-20
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Vulnerabilities
- [High] CVE-2024-0901 Potential denial of service and out of bounds
read. Affects TLS 1.3 on the server side when accepting a connection
from a malicious TLS 1.3 client. If using TLS 1.3 on the server side
it is recommended to update the version of wolfSSL used.
- [Med] CVE-2024-1545 Fault Injection vulnerability in
RsaPrivateDecryption function that potentially allows an attacker
that has access to the same system with a victims process to perform
a Rowhammer fault injection.
- [Med] Fault injection attack with EdDSA signature operations. This
affects ed25519 sign operations where the system could be susceptible
to Rowhammer attacks.
No official tarball provided so switch to github and set autoreconf
https://github.com/wolfSSL/wolfssl/releases/tag/v5.7.0-stable
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Fix the following build failure with kernel >= 6.8:
/home/autobuild/autobuild/instance-8/output-1/build/dahdi-linux-3.3.0/drivers/dahdi/xpp/card_global.c: In function ‘parse_chip_command’:
/home/autobuild/autobuild/instance-8/output-1/build/dahdi-linux-3.3.0/drivers/dahdi/xpp/card_global.c:345:9: error: implicit declaration of function ‘strlcpy’; did you mean ‘strscpy’? [-Werror=implicit-function-declaration]
345 | strlcpy(buf, cmdline, MAX_PROC_WRITE); /* Save a copy */
| ^~~~~~~
| strscpy
Fixes:
- http://autobuild.buildroot.org/results/a0d2dcd10af9bf465ded2da83eccf2d137187477
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
The LIBS environment variable is ignored since bump to version 1.0.1 and
switch to cmake build system in commit
203725a46b resulting in the following
build failure:
/home/buildroot/autobuild/run/instance-3/output-1/host/opt/ext-toolchain/bin/../lib/gcc/arm-buildroot-linux-musleabihf/12.3.0/../../../../arm-buildroot-linux-musleabihf/bin/ld: CMakeFiles/clamonacc.dir/inotif/hash.c.o: in function `onas_ht_add_hierarchy':
hash.c:(.text+0xa84): undefined reference to `fts_open'
Fixes: 203725a46b
- http://autobuild.buildroot.org/results/fe71ab29d02caeed609f1a181fccbd46b6feff65
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
This bump will fix the following build failure with gcc 5 raised since
bump to version 57 in commit 65c8a9b662
thanks to
4e618f77d4:
In file included from /home/buildroot/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/mips-linux-gnu/include/c++/5.3.0/cstdint:35:0,
from ../cpp/INIReader.h:17,
from ../cpp/INIReader.cpp:16:
/home/buildroot/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/mips-linux-gnu/include/c++/5.3.0/bits/c++0x_warning.h:32:2: error: #error This file requires compiler and library support for the ISO C++ 2011 standard. This support is currently experimental, and must be enabled with the -std=c++11 or -std=gnu++11 compiler options.
#error This file requires compiler and library support for the \
^
https://github.com/benhoyt/inih/releases/tag/r58
Fixes: 65c8a9b662
- http://autobuild.buildroot.org/results/7a5ba516cde536e103669a0422d336dd8a3b1dbc
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Use official tarball and so drop autoreconf
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
QorIQ processors family also includes LS Series wich are based on aarch64
Signed-off-by: David Gouarin <dgouarin@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Only the 32bit ARM blob provides the framebuffer backend. This is
apparently independent of which imx8 derivate is used, so changed
the condition for the config option accordingly.
Signed-off-by: Andreas Naumann <anaumann@ultratronik.de>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
dmraid is a very old package from 2010 with an awkward configure script
which doesn't honor CFLAGS:
ac_cv_env_CFLAGS_set=set
ac_cv_env_CFLAGS_value='-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os -g0 '
[...]
## ----------------- ##
## Output variables. ##
## ----------------- ##
AWK='gawk'
CC='/home/autobuild/autobuild/instance-3/output-1/host/bin/sh4a-buildroot-linux-musl-gcc'
CFLAGS='-O2'
resulting in the following build failure with musl >= 1.2.4 and
25e6fee27f
because _LARGEFILE64_SOURCE is not set:
/home/autobuild/autobuild/instance-3/output-1/host/lib/gcc/sh4a-buildroot-linux-musl/12.3.0/../../../../sh4a-buildroot-linux-musl/bin/ld: misc/file.o: in function `rw_file':
file.c:(.text+0x150): undefined reference to `lseek64'
To fix this issue, pass TARGET_CONFIGURE_OPTS through DMRAID_MAKE_OPTS
Fixes:
- http://autobuild.buildroot.org/results/5c7c82959ce92db908d3ca20e2c1137509c2f981
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
This version allows to build with Linux 6.8
Signed-off-by: Giulio Benetti <giulio.benetti@benettiengineering.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Set -std=gnu99 to fix the following uclibc build failure raised since
the addition of the package in commit
2f6b1b8e68:
../draw.c:37:23: error: 'CLOCK_REALTIME' undeclared (first use in this function)
37 | clock_gettime(CLOCK_REALTIME, &ts);
| ^~~~~~~~~~~~~~
Fixes: 2f6b1b8e68
- http://autobuild.buildroot.org/results/4b9db67fb444ec35d741e5d3e74263ac0c4d4a7d
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
sortGrid()'s handling of git hashes and other large hex numbers
has been inconsistent, they can be detected as strings or numbers
depending on what type of character they start with.
This patch fixes the behaviour by using a regex to capture everything
that looks like a big hex number and treat it as a string.
This means when you sort by current version ascending all the version
strings with big hex numbers should show up first, sorted 0-9,a-f.
First we check for a string length >= 39, and then apply a regex
to return an array with every char from that string that matched
the regex. If the length of this array is still >= 39 we can assume
we are looking at something containing a git hash.
The reason why the length is defined as ">= 39" and not "40" or
"39 or 40" is twofold:
Firstly, 39 was chosen as a minimum to match stuff with 39 char git
hashes, like the rockchip-mali package.
Secondly, there is no max because we actually want to catch not
just explicitly git hashes, but any verson string with big gnarly
hex numbers in it.
Stuff like: "1.4.2-168-ged3039cdbeeb28fc0011c3585d8f7dfb91038292"
Why? Well, the idea is less about git hashes and sorting
and more about grouping similarly formatted version strings.
It would be impossble (or at least annoyingly complicated) and of
dubious utility to get a real sequential sort out of the
current version column, so the attempt here is to at the very
least collect all the similarly formatted things together.
This isn't perfect, but it's a (arguably) more useful sorted
output than before.
A demo is available here:
https://sen-h.codeberg.page/pkg-stats-demos/@pages/fix-improve-git-hash-sorting.html
Signed-off-by: Sen Hastings <sen@hastings.org>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
