Using PLATFORM=k3 can leads to a runtime boot crash on some K3 SoC (e.g.
j721e) because the optee flavor is missing.
We could use BR2_TARGET_OPTEE_OS_PLATFORM=k3 and
BR2_TARGET_OPTEE_OS_PLATFORM_FLAVOR=am64x but we actually can use
BR2_TARGET_OPTEE_OS_PLATFORM=k3-am64x as explained in the optee-os
Makefile [1]:
# If $(PLATFORM) is defined and contains a hyphen, parse it as
# $(PLATFORM)-$(PLATFORM_FLAVOR) for convenience
This is how meta-ti set the optee-os platform:
meta-ti]$ git grep OPTEEMACHINE
meta-ti-bsp/conf/machine/am437x-hs-evm.conf:OPTEEMACHINE = "ti-am43xx"
meta-ti-bsp/conf/machine/am57xx-hs-evm.conf:OPTEEMACHINE = "ti-am57xx"
meta-ti-bsp/conf/machine/beagleplay.conf:OPTEEMACHINE = "k3-am62x"
meta-ti-bsp/conf/machine/dra7xx-hs-evm.conf:OPTEEMACHINE = "ti-dra7xx"
meta-ti-bsp/conf/machine/include/am62axx.inc:OPTEEMACHINE = "k3-am62x"
meta-ti-bsp/conf/machine/include/am62pxx.inc:OPTEEMACHINE = "k3-am62x"
meta-ti-bsp/conf/machine/include/am62xx.inc:OPTEEMACHINE = "k3-am62x"
meta-ti-bsp/conf/machine/include/am64xx.inc:OPTEEMACHINE = "k3-am64x"
meta-ti-bsp/conf/machine/include/am65xx.inc:OPTEEMACHINE = "k3-am65x"
meta-ti-bsp/conf/machine/include/j7200.inc:OPTEEMACHINE = "k3-j721e"
meta-ti-bsp/conf/machine/include/j721e.inc:OPTEEMACHINE = "k3-j721e"
meta-ti-bsp/conf/machine/include/j721s2.inc:OPTEEMACHINE = "k3-j784s4"
meta-ti-bsp/conf/machine/include/j722s.inc:OPTEEMACHINE = "k3-am62x"
meta-ti-bsp/conf/machine/include/j784s4.inc:OPTEEMACHINE = "k3-j784s4"
meta-ti uses the OPTEEMACHINE to set optee-os platform [2].
[1] https://github.com/OP-TEE/optee_os/blob/4.0.0/Makefile#L37
[2] https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-security/optee/optee-os.inc?h=4.0.3#n23
Suggested-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Using PLATFORM=k3 can leads to a runtime boot crash on some K3 SoC (e.g.
j721e) because the optee flavor is missing.
We could use BR2_TARGET_OPTEE_OS_PLATFORM=k3 and
BR2_TARGET_OPTEE_OS_PLATFORM_FLAVOR=am62x but we actually can use
BR2_TARGET_OPTEE_OS_PLATFORM=k3-am62x as explained in the optee-os
Makefile [1]:
# If $(PLATFORM) is defined and contains a hyphen, parse it as
# $(PLATFORM)-$(PLATFORM_FLAVOR) for convenience
This is how meta-ti set the optee-os platform:
meta-ti]$ git grep OPTEEMACHINE
meta-ti-bsp/conf/machine/am437x-hs-evm.conf:OPTEEMACHINE = "ti-am43xx"
meta-ti-bsp/conf/machine/am57xx-hs-evm.conf:OPTEEMACHINE = "ti-am57xx"
meta-ti-bsp/conf/machine/beagleplay.conf:OPTEEMACHINE = "k3-am62x"
meta-ti-bsp/conf/machine/dra7xx-hs-evm.conf:OPTEEMACHINE = "ti-dra7xx"
meta-ti-bsp/conf/machine/include/am62axx.inc:OPTEEMACHINE = "k3-am62x"
meta-ti-bsp/conf/machine/include/am62pxx.inc:OPTEEMACHINE = "k3-am62x"
meta-ti-bsp/conf/machine/include/am62xx.inc:OPTEEMACHINE = "k3-am62x"
meta-ti-bsp/conf/machine/include/am64xx.inc:OPTEEMACHINE = "k3-am64x"
meta-ti-bsp/conf/machine/include/am65xx.inc:OPTEEMACHINE = "k3-am65x"
meta-ti-bsp/conf/machine/include/j7200.inc:OPTEEMACHINE = "k3-j721e"
meta-ti-bsp/conf/machine/include/j721e.inc:OPTEEMACHINE = "k3-j721e"
meta-ti-bsp/conf/machine/include/j721s2.inc:OPTEEMACHINE = "k3-j784s4"
meta-ti-bsp/conf/machine/include/j722s.inc:OPTEEMACHINE = "k3-am62x"
meta-ti-bsp/conf/machine/include/j784s4.inc:OPTEEMACHINE = "k3-j784s4"
meta-ti uses the OPTEEMACHINE to set optee-os platform [2].
[1] https://github.com/OP-TEE/optee_os/blob/4.0.0/Makefile#L37
[2] https://git.yoctoproject.org/meta-arm/tree/meta-arm/recipes-security/optee/optee-os.inc?h=4.0.3#n23
Suggested-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Dario Binacchi <dario.binacchi@amarulasolutions.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
poco needs C++17 and gcc >=8 since bump to version 1.13.2 in commit
433c4fd38b and
78234857bf10f41c06d9
resulting in the following build failure with gcc 7:
In file included from src/Thread.cpp:28:0:
src/Thread_POSIX.cpp: In member function 'void Poco::ThreadImpl::setNameImpl(const string&)':
src/Thread_POSIX.cpp:162:56: error: no matching function for call to 'std::__cxx11::basic_string<char>::append(const string&, std::__cxx11::basic_string<char>::size_type)'
truncName.append(threadName, threadName.size() - half);
^
Fixes: 433c4fd38b
- http://autobuild.buildroot.org/results/7b1c144f39a8be4ce8f964aa13a52d0bf62dd0aa
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Pass -std=c++17 to fix the following build failure with host gcc 10
raised since bump to version 6.6 in commit
c13199c932:
/usr/bin/g++ -O2 -I/home/buildroot/instance-0/output-1/host/include -o cf_gen ./cf_gen.cc -I. -I../include/ -I../src
./cf_gen.cc: In function 'int main(int, char**)':
./cf_gen.cc:268:63: error: forming reference to void
268 | auto &newEntry = entries.emplace_back(name);
| ^
Fixes:
- http://autobuild.buildroot.org/results/613fee008c77f8dbbe04df9a4ce4347e43de9ef9
- https://bugs.buildroot.org/show_bug.cgi?id=15997
Reported-by: Roland Franke
Suggested-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Codescape mips toolchains are old (2018) and use glibc 2.20 which is not
compatible with 64-bit time_t raising the following build failure with
libselinux since commit 1c2dbcdcf0:
In file included from selinux_restorecon.c:17:0:
/home/buildroot/autobuild/instance-1/output-1/host/mipsel-buildroot-linux-gnu/sysroot/usr/include/fts.h:41:3: error: #error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"
# error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"
^~~~~
Fixes: 1c2dbcdcf0
- http://autobuild.buildroot.org/results/a4d38af627a42a2c55d60129787c51353d5883bf
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
bump to latest version because previous version did not work with python 3.11
Signed-off-by: Jeremy J. Peper <jeremy@jeremypeper.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
bump to latest version because previous version did not work with python 3.11
Signed-off-by: Jeremy J. Peper <jeremy@jeremypeper.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
bump to latest version because previous version did not work with python 3.11
corrected version mismatch with my first submission
Signed-off-by: Jeremy J. Peper <jeremy@jeremypeper.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Without python-gobject, we get the following runtime error:
ModuleNotFoundError: No module named 'gi'
Add python-gobject and propagate its dependencies.
While we're at it, split the DEPENDENCIES over several line and sort
them alphabetically.
Signed-off-by: Jeremy J. Peper <jeremy@jeremypeper.com>
Reviewed-by: Adam Duskett <adam.duskett@amarulasolutions.com>
[Arnout: reorder everything alphabeticall, split DEPENDENCIES over
several lines.]
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Bump the kernel version to 6.6.21.
Also pass the nxp/imx/ path due to the devicetree reorganization
in kernel 6.6.
Signed-off-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
While fixing a build error
../src/egl/drivers/dri2/platform_x11.c: In function 'dri2_x11_get_msc_rate':
../src/egl/drivers/dri2/platform_x11.c:1229:44:
error: 'struct dri2_egl_display' has no member named 'screen_resources'
with this defconfig:
BR2_x86_64=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_GALLIUM_DRIVER_IRIS=y
BR2_PACKAGE_MESA3D_OPENGL_GLX=y
BR2_PACKAGE_MESA3D_OPENGL_EGL=y
BR2_PACKAGE_MESA3D_OPENGL_ES=y
BR2_PACKAGE_XORG7=y
(crocus and i915 drivers are also affected) it turns out that we can
assume the need for dri3 support when X.org is enabled as a hard depen-
dency even if mesa3d's configure does not throw errors when missing,
like for the Intel drivers.
Before this patch these Config.in options were used:
config BR2_PACKAGE_MESA3D_DRI3
select BR2_PACKAGE_XLIB_LIBXSHMFENCE
select BR2_PACKAGE_MESA3D_DRI3 if BR2_PACKAGE_XORG7
which can be translated into:
select BR2_PACKAGE_XLIB_LIBXSHMFENCE if BR2_PACKAGE_XORG7
and used at option BR2_PACKAGE_MESA3D_DRIVER.
Configure option -Ddri3=enabled is passed to mesa3d when at least one
driver is enabled along with X.org:
ifeq ($(BR2_PACKAGE_MESA3D_DRIVER)$(BR2_PACKAGE_XORG7),yy)
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Fix the following build failure in Thumb mode:
/tmp/ccdzbA2E.s:845: Error: selected processor does not support `mcr p15,0,r2,c7,c10,5' in Thumb mode
Fixes:
- http://autobuild.buildroot.org/results/08be1fa0fee0f05818cd78d4718caa3476c570ae
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Reviewed-by: André Zwing <nerv@dawncrow.de>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Additionally, add an upstream patch that fixes the configuration for
"NONE" toolchain variant in libspdm. That is, where the build
environment provides compile/link options.
Reviewed-by: Alistair Francis <alistair.francis@wdc.com>
Signed-off-by: Wilfred Mallawa <wilfred.mallawa@wdc.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Contains a single fix for a regression since 1.11.0.
https://github.com/rauc/rauc/releases/tag/v1.11.3
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
codesourcery arm/aarch64 toolchains are old (2014) and use glibc
2.18/2.20 which are not compatible with 64-bit time_t raising the
following build failure with libcgroup since commit
1c2dbcdcf0:
In file included from ./libcgroup-internal.h:25:0,
from parse.y:21:
/home/buildroot/autobuild/run/instance-3/output-1/host/arm-buildroot-linux-gnueabi/sysroot/usr/include/fts.h:41:3: error: #error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"
# error "<fts.h> cannot be used with -D_FILE_OFFSET_BITS==64"
^
Fixes: 1c2dbcdcf0
- http://autobuild.buildroot.org/results/e28f955f2b360f6e7bb231a5a3800cfbd17a23d7
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[Peter: add Config.in.legacy entries]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Passing ip=dhcp to the kernel will cause it to try to configure the network
interface using DHCP and wait up to 120s for the interface to detect a link,
slowing down boots without a network cable a lot.
Instead use the "normal" BR2_SYSTEM_DHCP, E.G. trigger ifup to run the DHCP
client in the background.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The kernel build now requires FIT support in mkimage:
ITB arch/mips/boot/vmlinux.gz.itb
/home/peko/source/buildroot/output-ci20/host/bin/mkimage: unsupported type Flat Device Tree
So enable that.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Removed all patches, they are included in this release.
Bumped gcc dependency to >= 8 according to changelog:
https://wiki.znc.in/ChangeLog/1.9.0
Signed-off-by: Bernd Kuhls <bernd@kuhls.net>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fixes the following security issues:
- CVE-2024-24575 (infinite loop DoS on revision lookup) and
- CVE-2024-24577 (heap out of bound write on index update)
https://github.com/libgit2/libgit2/releases/tag/v1.7.2
Signed-off-by: Nicolas Cavallari <nicolas.cavallari@green-communications.fr>
[Peter: mark as security bump]
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Disable -Werror to fix the following build failure with esp-hosted
raised at least since commit a382a7d554:
In function ‘destroy_cmd_wq’,
inlined from ‘esp_commands_teardown’ at /home/autobuild/autobuild/instance-4/output-1/build/esp-hosted-ce3c50a33fa4bc562a1b6cbcee292c1ae0b0a404/esp_hosted_ng/host/esp_cmd.c:1467:2:
./include/linux/workqueue.h:639:9: error: call to ‘__warn_flushing_systemwide_wq’ declared with attribute warning: Please avoid flushing system-wide workqueues. [-Werror=attribute-warning]
639 | __warn_flushing_systemwide_wq(); \
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/autobuild/autobuild/instance-4/output-1/build/esp-hosted-ce3c50a33fa4bc562a1b6cbcee292c1ae0b0a404/esp_hosted_ng/host/esp_cmd.c:408:17: note: in expansion of macro ‘flush_scheduled_work’
408 | flush_scheduled_work();
| ^~~~~~~~~~~~~~~~~~~~
Fixes:
- http://autobuild.buildroot.org/results/6ac7a4601938d3296ed1657c06f8cdf433757d73
- http://autobuild.buildroot.org/results/7997cc8a67645a6e1cf4e24d172c6feae459dcfb
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
cf_gen.cc is compiled by host compiler and unconditionally uses auto
since bump to version 6.6 in commit
c13199c932 and
09835feb25
resulting in the following build failure with host gcc < 8:
/usr/bin/g++ -O2 -I/home/buildroot/autobuild/run/instance-1/output-1/host/include -o cf_gen ./cf_gen.cc -I. -I../include/ -I../src
./cf_gen.cc: In function 'int main(int, char**)':
./cf_gen.cc:268:63: error: forming reference to void
auto &newEntry = entries.emplace_back(name);
^
So add a dependency on host gcc >= 8 and gcc >= 8 as advocated by
upstream in
9d3433c4ac/doc/release-notes/release-6.sgml.in:
This release adds a dependency on C++17 support in any compiler used to build Squid.
GCC 8+ and Clang 8+ support C++17.
While at it, drop BR2_TOOLCHAIN_HAS_GCC_BUG_64735 which is always false
with gcc >= 7
Fixes: c13199c932
- http://autobuild.buildroot.org/results/f1766d1a3b2ce7745fa23cdeae1101806cd97aea
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Fix the following uclibc build failure raised since bump to version
3.506 in commit 57008d384b:
/home/buildroot/autobuild/run/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/mipsel-buildroot-linux-uclibc/12.3.0/../../../../mipsel-buildroot-linux-uclibc/bin/ld: iozone_linux-noaio.o: in function `read_perf_test':
iozone.c:(.text+0x11a74): undefined reference to `end_async'
Fixes:
- http://autobuild.buildroot.org/results/31a4f0ac9eeb71df5d2f40ffe9f1f256cb58e399
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Select libucontext if the toolchain doesn't support ucontext to allow
building php on musl
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
