summaryrefslogtreecommitdiffstats
path: root/meta/classes-recipe
Commit message (Collapse)AuthorAgeFilesLines
* bitbake.conf/pseudo: Switch from exclusion list to inclusion listRichard Purdie2025-05-123-7/+5
| | | | | | | | | | | | | | | | | Currently, pseudo tracks all files referenced within its presence unless they're listed in an exclusion list. The exclusion list has grown to be fairly unwieldy. This patch swaps PSEUDO_IGNORE_PATHS for PSEUDO_INCLUDE_PATHS which in theory should be easier and more explicit to maintain. This change does drop many directories from pseudo coverage including /home and /tmp. There may be adapatations needed for recipes/classes using pseudo in specific ways. (From OE-Core rev: 2502da81709f25de499277b28d33c915638c45f6) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* toolchain-scripts: Export meson settings for SDK buildsTom Hochstein2025-05-121-1/+9
| | | | | | | | | | | | | | | | | | | | | Create a new set of exports for the Meson `host_machine` cross settings. This allows the target cross file to be created correctly from meson.cross.template and aligns with meson.bbclass. Note, one might think that HOST_OS and HOST_ARCH would be appropriate as inputs here, aligning nicely with the Meson naming. That turns out to be incorrect since the script is generated in a native/nativesdk build with HOST_OS and HOST_ARCH set for the "build machine", not the "host machine", using the Meson terminology. See https://mesonbuild.com/Cross-compilation.html. Fixes: [YOCTO #15485] (From OE-Core rev: 9e742a0a9078f4a19a5edbfa51f22f7b71992188) (From OE-Core rev: f2f898e36feb3bd489edda451e71b11bf69940b9) Signed-off-by: Tom Hochstein <tom.hochstein@oss.nxp.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* toolchain-scripts: Add Meson settings for Yocto build SDKTom Hochstein2025-05-121-0/+2
| | | | | | | | | | | | The Meson settings for the standalone SDK also need to be available for the Yocto build SDK, a.k.a. meta-ide-support. (From OE-Core rev: 6287114bf10718fe49f7c1ed211f3d99f0933bc4) (From OE-Core rev: d69d049e9a7114323a1e1b8da4999e9e3f08ad03) Signed-off-by: Tom Hochstein <tom.hochstein@oss.nxp.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* testsdk: allow user to specify which tests to runRoss Burton2025-05-121-0/+3
| | | | | | | | | | | | | | Following the usage of TEST_SUITES in testimage, add TESTSDK_SUITES to specify the list of tests to execute. By default the variable is empty, which means to run all discovered tests. This makes it easier to work on a single test without having to run all of the tests. (From OE-Core rev: 28d437c52c77889b2ede0fc2f2d6777c5b0a553d) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-yocto: allow annotated options to be modifiedBruce Ashfield2025-05-081-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bumping the kern-tools SRCREV to pickup the following commits: tools: allow fixups to conditionally change options Sometimes we have options that should either be =y or =m depending on the use case. Rather than force the options into multiple parallel and very similar fragments (which is error prone and labour intensive), we can allow an annotation in the configuration fragment that allows the default value to be overriden by a variable. The variable in question comes from a -D<var>=<value> on the scc or spp command line. If the define evaluates to a non-zero value a fixup is created that will modify the value when scc finishes gathering meta-data. An example of a notation would be: CONFIG_INET_TUNNEL=y # OVERRIDE:$MODULE_OR_Y CONFIG_INET_TUNNEL will be =y when standard tools (like merge-config) are used. But when scc/spp see this notation, they check the value of the variable MODULE_OR_Y, if that variable evalutes to a non-zero value, a fixup is created that will change CONFIG_INET_TUNNEL to that value before the kernel is configured. To use the annotations, scc needs to be passed a value that is used in the override expression. This has always been possible with defines (-Dx=y), so we leverage that to control these conditional overrides. In kernel-yocto, we now have a variable: KMETA_CONFIG_FEATURES KMETA_CONFIG_FEATURES ?= "" Which defaults to empty, the only feature that is currently implemented is "prefer-modules". When prefer-modules is detected in the kmeta config features, the following define is passed to scc: -DMODULE_OR_Y=m Which as you can see from the above INET_TUNNEL example, will evaluate to "m" and will override the default of "y". (From OE-Core rev: 4eb24e85e815cee0e310e98ce4384d4cdeeba69f) Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* module.bbclass: add KBUILD_EXTRA_SYMBOLS to installAlon Bar-Lev2025-05-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Symbols are used during install as well, adding KBUILD_EXTRA_SYMBOLS enables successful installation. | DEBUG: Executing shell function do_install | NOTE: make -j 22 KERNEL_SRC=xxx/kernel-source -C xxx/drivers KDIR=xxx/kernel-source DEPMOD=echo MODLIB=xxx/image/lib/modules/6.6.75-yocto-standard-00189-g530c419bc9db INSTALL_FW_PATH=xxx/image/lib/firmware CC=aarch64-poky-linux-gcc -fuse-ld=bfd -fcanon-prefix-map LD=aarch64-poky-linux-ld.bfd OBJCOPY=aarch64-poky-linux-objcopy STRIP=aarch64-poky-linux-strip O=xxx/kernel-build-artifacts modules_install | make: Entering directory 'xxx/drivers' | make -C xxx/kernel-source M=xxx/drivers modules | make[1]: Entering directory 'xxx/kernel-source' | make[2]: Entering directory 'xxx/kernel-build-artifacts' | MODPOST xxx/drivers/Module.symvers | ERROR: modpost: "xxx" [xxx/xxx.ko] undefined! (From OE-Core rev: 0ef80eeda967a9e04ff91c3583aabbc35c9868e8) Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meson: correct bindgen_clang_argmentsDmitry Baryshkov2025-05-081-1/+9
| | | | | | | | | | | | | | | | Follow the changes in Clang search paths and specify sysroot via the TOOLCHAIN_OPTIONS, otherwise clang will fail to find system headers when executed by bindgen. For SDK packages TOOLCHAIN_OPTIONS don't contain full sysroot path, so specify the correct directory explicitly. (From OE-Core rev: a647a0ff4c4eb7a7c1f6ec84a574f7d7796b6178) Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* lib/classes/conf: refactor qemu.bbclass functions into library functionsChen Qi2025-05-011-39/+3
| | | | | | | | | | | | | | | | | Move the functions in qemu.bbclass to meta/lib/oe/qemu.py as they are generally useful. The qemu.bbclass is still kept, and recipes can continue to use functions from it, though they have become wrapper functions on qemu.py functions. Note that the QEMU_OPTIONS settings are still kept in qemu.bbclass. This sets a clear barrier for people to use qemu user mode. (From OE-Core rev: 7b3563b3b3901c96c3e498799a83ab8cabcf84b4) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-arch.bbclass: Do not use weak assignment for TOOLCHAINKhem Raj2025-05-011-1/+1
| | | | | | | | | | | | If a distro sets TOOLCHAIN with ?= or = then it overrides this too, however, we demand GCC to be in there due to KERNEL_CC etal Make it hard assignment, it can still be overturned via a bbappend in that case it is intentional to use non-gcc compiler for kernel (From OE-Core rev: 307902aa05c4537cb34fffe768df1547fb6a12d8) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: Enhance to emit a native toolchain cmake fileKhem Raj2025-05-011-0/+58
| | | | | | | | | | | | | | | | Some components e.g. clang and its runtime needs the native toolchain defines especially when doing nativesdk builds it uses CROSS_TOOLCHAIN_FLAGS_NATIVE to pass native toolchain file, which is then used to build native llvm tools needed during nativesdk builds Moreover this would enable using OE built native toolchain e.g. clang-native to build cmake based packages. e.g. libcxx and other llvm runtime plus it can be used for build native packages which require clang (From OE-Core rev: 79dc6a23234a34403157dec10d0cdd839ca76b3e) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* ptest-cargo: fix incorrect FAIL count when multiple tests are runInes KCHELFI2025-04-291-4/+5
| | | | | | | | | | | | | | | | | | | | When using the ptest-cargo class with multiple Rust test binaries, ptest-runner may report FAIL: 0 even if one of the tests fails, as long as the last test passes. This happens because the run-ptest script, as generated by the class, does not track failures and simply returns the exit code of the last test. To fix this, each test binary is checked individually for failure. If any test fails, a non-zero exit code is returned. This ensures that test failures are not silently ignored and are properly reported by ptest-runner in multi-test scenarios. (From OE-Core rev: 039708d2aa578da755d5b6eadd6f549121a93186) Signed-off-by: Ines KCHELFI <ines.kchelfi@smile.fr> Reviewed-by: Yoann Congal <yoann.congal@smile.fr> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* ptest-cargo: refactor run-ptest generation to remove redundancyInes KCHELFI2025-04-291-9/+11
| | | | | | | | | | | | This refactoring simplifies the generation of the run-ptest script by removing redundant logic and improving readability. (From OE-Core rev: 287614a847651f8bd528597b7d6ccb8ad8262367) Signed-off-by: Ines KCHELFI <ines.kchelfi@smile.fr> Reviewed-by: Yoann Congal <yoann.congal@smile.fr> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* ptest-cargo: handle packageconfig argumentsPeter Marko2025-04-241-1/+2
| | | | | | | | | | | | | | | | | | | | Align cargo options between ptest-cargo and cargo classes. After oe-core commit 16745b20452de60ae2474433cc1a2fb1ed9f6a64 there is a discrepancy between cargo arguments in compile and compile-ptest-cargo steps when packageconfig is used for cargo based recipes. Currently we have to do something like following code to build ptest enabled cargo based recipe: CARGO_BUILD_FLAGS:append:task-compile-ptest-cargo = " ${PACKAGECONFIG_CONFARGS}" Otherwise the options are either doubled in compile step or completely missing in compile-ptest-cargo step. (From OE-Core rev: 98d03d31de4010534b1a00d29409d3486a0ab0b9) Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* image/populate_sdk.bbclass: drop qemuwrapper-cross from DEPENDSChen Qi2025-04-242-2/+2
| | | | | | | | | | | | | | | | For packages that need qemuwrapper-cross, they should have it in PAKAGE_WRITE_DEPS. Now that we've used 'qemuwrapper-cross' to replace 'qemu-native' for recipes that need qemu-native for their postinsts, and we've now mapped PACKAGE_WRITE_DEPS for nativesdk recipes, these qemuwrapper-cross dependencies can be dropped from image.bbclass and populate_sdk.bbclass. (From OE-Core rev: fbac8d025585fe704f79ccdf00f376f677e3a89d) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meson: pass -target and -I to bindgen callsDmitry Baryshkov2025-04-231-0/+1
| | | | | | | | | | | | In order to properly generate Rust bindings for the target systems, we need to pass '-taget foo-linux-gnueabi' flags and a correct include target include path (${STAGING_INCDIR}) to the bindgen. Add those flags to the generated meson target file. (From OE-Core rev: 40008d55c01681c60088e5b7defb0b8513a4ed1c) Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* bitbake.conf: Switch prefix mapping to use -ffile-prefix-mapKhem Raj2025-04-231-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | -ffile-prefix map is more comprehensive when it comes to reproducible builds and its superset of all prefix-mapping options in compilers This makes is cleaner and workable across gcc and clang, clang does not support -fcanon-prefix-map and it has to be explicitly omitted when using clang. There are lambdas generated in templates by clang which still get the absolute paths despite -fdebug-prefix-map, this helps with that as well. nasm is an outlier and we have fixed it by adding -fdebug-prefix-map option luckily we do not pass DEBUG_PREFIX_MAP to nasm, in all recipes which use nasm either pass -fdebug-prefix-map explicitly to nasm or they rewrite it to use nasm flags syntax. We have discussed this in past [1] [1] https://patchwork.yoctoproject.org/project/oe-core/patch/20230428032030.2047920-1-raj.khem@gmail.com/#10281 (From OE-Core rev: ff73fa7ef7666a6dbe34f15515bc3ab6e574c5b0) Signed-off-by: Khem Raj <raj.khem@gmail.com> Cc: Jacob Kroon <jacob.kroon@gmail.com> Cc: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* nativesdk.bbclass: handle PACKAGE_WRITE_DEPSChen Qi2025-04-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | We want nativesdk packages to depend on correct recipes introduced by PACKAGE_WRITE_DEPS, so do the same mapping just as we do for DEPENDS. Before this change: nativesdk-glib-2.0 -> qemuwrapper-cross After this change: nativesdk-glib-2.0 -> nativesdk-qemuwrapper-cross This can fix do_populate_sdk failure complaining missing of nativesdk-qemuwrapper. Error message is like below: NOTE: > Executing update_gio_module_cache-nativesdk intercept ... NOTE: Exit code 127. Output: /xxx/lib32-core-image-sato/1.0/intercept_scripts-xxxx/ update_gio_module_cache-nativesdk: 13: nativesdk-qemuwrapper: not found (From OE-Core rev: 89ac78e68c4be6e6163223c99e140e7530a61e8e) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/recipes: remove unnecessary qemu inherit and use qemuwrapper-crossChen Qi2025-04-235-12/+5
| | | | | | | | | | | | | | | These classes/recipes inherit qemu.bbclass but do not use anything from it. What they use is qemuwrapper-cross, which is needed at do_rootfs time and needs to be pulled-in by PACKAGE_WRITE_DEPS. Also, in meta/conf/layer.conf, exclude qemuwrapper-cross deps for all arch recipes that depend on it. This it ensure allarch recipes have the same signature across different machines. (From OE-Core rev: 6f3ce94f4c03e7b26f1fcdf78ea969f57717ec56) Signed-off-by: Chen Qi <Qi.Chen@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uki.bbclass: drop serial console from kernel command lineMikko Rapeli2025-04-171-1/+1
| | | | | | | | | | | | | The kernel will continue using console from firmware which is much better on HW when we may not know at build time which console HW and drivers are available, e.g. like on genericarm64 machine. (From OE-Core rev: cf2ed52a94f5fa57cc6d93418dfb49b30e2240cc) Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes-recipe: npm: Complain immediately if npm-shrinkwrap.json is too oldMike Crowe2025-04-101-0/+3
| | | | | | | | | | | | | | | | | | | | | | Rather than emitting: Exception: KeyError: 'packages' and a stack trace, let's fail immediately if lockfileVersion implies that the npm-shrinkwrap.json file isn't compatible. The documentation[1] doesn't make it clear which lockfileVersions are guaranteed to contain "packages". I have lockfileVersion 1 files without. Running npm 7.5.2 generates npm-shrinkwrap.json files with lockfileVersion 2 and "packages", so I've set the minimum to be 2. [1] https://docs.npmjs.com/cli/v7/configuring-npm/package-lock-json (From OE-Core rev: 4d3cbd11bc9cc0bf5a8571ecd3ce6e5e5c6ef6eb) Signed-off-by: Mike Crowe <mac@mcrowe.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* rust: Upgrade 1.84.1->1.85.0Yash Shinde2025-04-011-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rust stable version updated to 1.85.0 https://blog.rust-lang.org/2025/02/20/Rust-1.85.0.html Some of the major updates: - Update LIC_FILES_CHKSUM in libstd-rs and rust recipes. License-Update: Unicode license text is updated to Unicode-3.0 License. https://github.com/rust-lang/rust/commit/6d2a3e9786ec43a0e0af20386e7046328296ac86 [RP: Update LICENSE to reference Unicode-3.0] - Pass '-Zforce-unstable-if-unmarked' to RUSTFLAGS in libstd-rs.bb Fix: https://github.com/rust-lang/rust/issues/133857#issuecomment-2526341227 - Downgrade bootstrap cc version causing bootstrap to fail on custom targets. (Backported from v1.85.1) Fix: https://github.com/rust-lang/rust/pull/137460/commits/e4ca11f87ffca8c63aa56d45b46e62b6acc58bd7 - Explicitly set float ABI for all ARM 32 bits targets. Fix: https://github.com/rust-lang/rust/commit/a51fefcaab835b310e2e26005b50982d0049d905 - Rust v1.85.0 tarball doesn't ship gcc tree. Drop "remove_gcc_directory" postfunc which removed it and prevented the bloat. Fix: https://github.com/rust-lang/rust/commit/13c3f9b9498013837782b46120085ea19ca75518 Adapted the patch changes with v1.85.0: repro-issue-fix-with-cc-crate-hashmap.patch revert-link-std-statically-in-rustc_driver-feature.patch rust-oe-selftest.patch rv32-cargo-rustix-0.38.40-fix.patch Dropped patches: fix-tidy-check-failure.patch since it's merged with v1.85.0. (From OE-Core rev: 3130069fdebb92f20b962fa8074564a27c3fb6b9) Signed-off-by: Yash Shinde <Yash.Shinde@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cargo.bbclass: show PACKAGECONFIG_CONFARGS in bbnoteMartin Jansa2025-03-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | * PACKAGECONFIG_CONFARGS was added in: https://git.openembedded.org/openembedded-core/commit/?id=16745b20452de60ae2474433cc1a2fb1ed9f6a64 but it wasn't added in bbnote above which might lead to confusing errors like I got now: NOTE: cargo build -v --frozen --target aarch64-webos-linux-gnu --release --manifest-path=.../git//Cargo.toml error: unexpected argument '--cfg' found Usage: cargo build --verbose... --frozen --target [<TRIPLE>] --release --manifest-path <PATH> and was wondering where --cfg came from. * it was from recipe where we already use: RUSTFLAGS:append = " ${PACKAGECONFIG_CONFARGS}" it will be difficult to use PACKAGECONFIG for RUSTFLAGS and prevent them to be used here for cargo as well, what about the recipes which need them to explicitly append them to CARGO_BUILD_FLAGS ? (From OE-Core rev: 38d953b2ffd4e0cee9e77f97988e44be105023c6) Signed-off-by: Martin Jansa <martin.jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cargo: pass PACKAGECONFIG_CONFARGS to cargo buildJean-Pierre Geslin2025-03-201-1/+1
| | | | | | | | | | | | In order to allow rust packages to define PACKAGECONFIG options, append the contents of PACKAGECONFIG_CONFARGS to the build command. This patch was already submitted by Bartosz Golaszewski on older version but was never merged. It will be really usefull for Rust recipes. (From OE-Core rev: 16745b20452de60ae2474433cc1a2fb1ed9f6a64) Signed-off-by: Jean-Pierre Geslin <jarsoper@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* autotools: require that a configure script existsRoss Burton2025-03-181-5/+2
| | | | | | | | | | There's no point inheriting autotools if you're not actually going to run a configure script, so make a missing configure script fatal. (From OE-Core rev: 6d327a39befae44a88a812bdf4acde800dcee57b) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* native: Drop export statements that aren't neededRichard Purdie2025-03-181-14/+14
| | | | | | | | These are already exported by bitbake.conf, no need to export them again. (From OE-Core rev: 92e52f5afac4877366c1ee2e6c6f0d1f5df84410) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* native: follow BUILD_* definitions for OBJCOPY, OBJDUMP and READELFAntonin Godard2025-03-181-0/+3
| | | | | | | | | | | | | | Set the host OBJCOPY, OBJDUMP, and READELF variables to be derived from their corresponding BUILD_* definitions. This makes the native class match the build-gcc.inc file 1 to 1, as these were the only missing. Currently these variables get their definitions from gcc.inc, which uses HOST_PREFIX, and that works because the native class sets HOST_PREFIX to BUILD_PREFIX, but this doesn't seem correct. (From OE-Core rev: 87a6ffe21b706e6aeeeb77891565cbd7730ca163) Signed-off-by: Antonin Godard <antonin.godard@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uboot, kernel: use hex address for UBOOT_ENTRYPOINTAdrian Freihofer2025-03-112-2/+2
| | | | | | | | | | | | | | | | | | Compiling a FIT image with this default values and dump it with dumpimage shows decimal converted values. For example the default value 20008000 looks like this: Image 0 (kernel-1) ... Load Address: 0x01314c40 Entry Point: 0x01314c40 With this change the expected value is printed by dumpimage. (From OE-Core rev: e6f2ca9135ef7da8f8b5925957532734c06e55cc) Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* linux-fitimage: sign setup sectionsAdrian Freihofer2025-03-111-0/+13
| | | | | | | | | | | | | | | | | | If FIT_SIGN_INDIVIDUAL is set to “1”, a signature section is added to all screen sections, but not to the setup section. To match the setup section with all other sections, the signature is also added. This also helps to implement the associated tests generically. This change is intended to make the code more consistent. However, it is not intended to make the FIT_SIGN_INDIVIDUAL function more popular. Technically, it would be better to remove the signature from all other image sections and discard the FIT_SIGN_INDIVIDUAL function, the use of which is no longer recommended anyway. (From OE-Core rev: 8bf6a9c07cdde8fc8bbd4bb61a4886ccc02a570f) Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes-recipe: Consolidate machine-id handlingVyacheslav Yurkov2025-03-092-15/+19
| | | | | | | | | | | | Whenever Systemd is used as an init manager, it requires a machine-id file to be present / initialized / or have the RW rootfs. This change does not introduce a new functionality, but rather merges everything we do with machine-id in one place. (From OE-Core rev: 890b81cdfadc427189eff4bbd2c24e32eb286126) Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake.bbclass: remove whitespaceVictor J. Hansen2025-03-081-1/+1
| | | | | | | (From OE-Core rev: 219c7c4954c649a1a0c284bb5f35eee533db41c3) Signed-off-by: Victor J. Hansen <victor.hansen@remarkable.no> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-arch: add macro-prefix-map in KERNEL_CCStefan Mueller-Klieser2025-03-081-1/+7
| | | | | | | | | | | | | | | When building external modules, macros can include absolute names of kernel headers. The macro-prefix-map for the STAGING_KERNEL_DIR is currently missing. Add it in the same way as its done in bitbake.conf. This fixes reproducible builds and following build error: ERROR: cryptodev-module-1.14-r0 do_package_qa: QA Issue: File <..> cryptodev.ko <..> contains reference to TMPDIR [buildpaths] (From OE-Core rev: a741e11751bfb8f52be58cf51abeddca4559e5e9) Signed-off-by: Stefan Müller-Klieser <s.mueller-klieser@phytec.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* go: Check if GO_IMPORT is set in recipe and error if notChristos Gavros2025-03-031-0/+3
| | | | | | | | | | | | | | | | | | | | Check if the variable GO_IMPORT is set in the recipe. If not generate an error. Test building go-helloworld when GO_IMPORT assigned Test building go-helloworld when GO_IMPORT is not assigned, generate error about GO_IMPORT Test building any other recipe(e.g bash) when GO_IMPORT is not assigned, generate error about GO_IMPORT Test creating a GO recipe with recipetool (not affected) Test selftest test_recipetool_create_go (not affected) Test selftest test_recipetool_create_go_replace_modules (not affected) [YOCTO #15763] CC: Yoann Congal <yoann.congal@smile.fr> CC: Randy MacLeod <randy.macleod@windriver.com> (From OE-Core rev: 374a91204bdaf44067f6b0ae89ed60934751efaa) Signed-off-by: Christos Gavros <gavrosc@yahoo.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* go: remove support for GOROOT_FINALHongxu Jia2025-03-031-1/+0
| | | | | | | | | | | | | | | | | After upstream go applied commit [cmd: remove support for GOROOT_FINAL][1], GOROOT_FINAL variable is dropped and use option -trimpath to instead [2] The option -trimpath has already been added to GOBUILDFLAGS in go.bbclass [1] https://github.com/golang/go/commit/507d1b22f4b58ac68841582d0c2c0ab6b20e5a98 [2] https://github.com/golang/go/issues/62047 (From OE-Core rev: 791ab77ac05f658ecd61525a3d9b1afaf8ac6e06) Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cml1.bbclass: use consistent make flags for menuconfigEnrico Jörns2025-03-032-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The class called 'make menuconfig' without any of the make variables and options set in EXTRA_OEMAKE, resulting in a quite different build environment than actually intended. For the kernel.bbclass this was fixed in commit 8c616bc0 ("kernel: Use consistent make flags for menuconfig") by appending ${EXTRA_OEMAKE} to KCONFIG_CONFIG_COMMAND. Instead of fixing this individually for additional recipes, we simply include ${EXTRA_OEMAKE} in KCONFIG_CONFIG_COMMAND by default. For most class users, this change is directly visible in the generated .config file: * For barebox and u-boot, the CONFIG_GCC_VERSION erroneously reflected the host GCC version before where it now correctly reflects the target toolchain's GCC. * For u-boot, also the "Compiler: " line at the beginning of the .config now prints the target toolchain instead of the host ones. * The kernel had this already set. * busybox did not produce any difference. Note that these projects might base some compile-time decisions on e.g. the actual compiler version used. Having the wrong one in the menuconfig-generated .config affects at least the visibility and consistency. Reported-by: Ulrich Ölmann <u.oelmann@pengutronix.de> (From OE-Core rev: 1b6ddd452837e67b500a84455a234f5edc8250a9) Signed-off-by: Enrico Jörns <ejo@pengutronix.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uboot-sign: support to add users specific image tree sourceJamin Lin2025-02-271-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, uboot-sign.bbclass only supports to create Image Tree Source(ITS) for "u-boot" and "flat_dt". However, users may want to add their private images into u-boot FIT image for specific application and purpose. To make this bbclass more flexible and support to add users specific snippet ITS, creates a new "UBOOT_FIT_USER_SETTINGS" variable. Users can add their specific snippet ITS into this variable. Example: ``` UBOOT_FIT_MY_ITS = '\ myfw {\n\ description = \"MY Firmware\";\n\ data = /incbin/(\"myfw.bin\");\n\ type = \"mytype\";\n\ arch = \"myarch\";\n\ os = \"myos\";\n\ load = <0xb2000000>;\n\ entry = <0xb2000000>;\n\ compression = \"none\";\n\ };\n\ ' UBOOT_FIT_USER_SETTINGS = "${UBOOT_FIT_MY_ITS}" ``` The generated ITS ``` myfw { description = "My Firmware"; data = /incbin/("myfw.bin"); type = "mytype"; arch = "myarch"; os = "myos"; load = <0xb2000000>; entry = <0xb2000000>; compression = "none"; }; ``` Add a variable "UBOOT_FIT_CONF_USER_LOADABLES" to load users specific images and it is an empty by default. (From OE-Core rev: c12e013453689697a8680f1c7de3e625a0ff28ec) Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uboot-sign: support to create TEE and ATF image tree sourceJamin Lin2025-02-271-1/+79
| | | | | | | | | | | | | | | | | | | | | | | Currently, uboot-sign.bbclass only supports to create Image Tree Source(ITS) for "u-boot" and "flat_dt". However, users may want to support multiple images such as ARM Trusted Firmware(ATF), Trusted Execution Environment(TEE) and users private images for specific application and purpose. To make this bbclass more flexible and support ATF and TEE, creates new functions which are "uboot_fitimage_atf" and "uboot_fitimage_tee" for ATF and TEE ITS file creation, respectively. Add a variable "UBOOT_FIT_ARM_TRUSTED_FIRMWARE" to enable ATF ITS generation and it is disable by default. Add a variable "UBOOT_FIT_TEE" to enable TEE ITS generation and it is disable by default. (From OE-Core rev: c14641a964b5b802e995e574a599c5b4937fb488) Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cml1.bbclass: do not escape the exit valueSven Kalmbach2025-02-271-1/+1
| | | | | | | | | | | Remove incorrectly escaped exit value, which causes error handling logic not to run. [YOCTO #15731] (From OE-Core rev: 5c44a9154f0cd4252d4840d836e6936393b5d3a3) Signed-off-by: Sven Kalmbach <Sven.Kalmbach@loewensteinmedical.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* autotools: don't try and find in-tree macrosRoss Burton2025-02-271-12/+2
| | | | | | | | | | | | | | | | | | | | autotools has improved a lot since this class was written, and there's now no need to search the source tree for m4 files and add them to the include path. If packages have macros in subdirectories the idiom is to tell aclocal via an assignment in Makefile.am: ACLOCAL_AMFLAGS = -I gl/m4 -I m4 If, for example, a package isn't autoreconfable out of the box (because it has a non-trivial autogen.sh or similar, say) then the required -I statements can be added to EXTRA_AUTORECONF. (From OE-Core rev: e718d1be2c4fb54cf363c23f929358e1be68c724) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* u-boot: kernel-fitimage: Restore FIT_SIGN_INDIVIDUAL="1" behaviorMarek Vasut2025-02-251-9/+51
| | | | | | | | | | | | | | | | | | | | | | | | | | OE FIT_SIGN_INDIVIDUAL is implemented in an unusual manner, where the resulting signed fitImage contains both signed images and signed configurations, possibly using different keys. This kind of signing of images is redundant, but so is the behavior of FIT_SIGN_INDIVIDUAL="1" and that is here to stay. Adjust the process of public key insertion into u-boot.dtb such that if FIT_SIGN_INDIVIDUAL==1, the image signing key is inserted into u-boot.dtb first, and in any case the configuration signing key is inserted into u-boot.dtb last. The verification of the keys inserted into u-boot.dtb against unused.itb is performed only for FIT_SIGN_INDIVIDUAL!=1 due to mkimage limitation, which does not allow mkimage -f auto-conf to update the generated unused.itb, and instead rewrites it. Fixes: 259bfa86f384 ("u-boot: kernel-fitimage: Fix dependency loop if UBOOT_SIGN_ENABLE and UBOOT_ENV enabled") (From OE-Core rev: 0106e5efab99c8016836a2ab71e2327ce58a9a9d) Signed-off-by: Marek Vasut <marex@denx.de> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cargo_common: use 'config.toml' instead of plain 'config'Enrico Scholz2025-02-251-10/+10
| | | | | | | | | | | | | | | | | | | cargo configuration has been renamed from plain 'config' to 'config.toml' in rust-1.38. Using the old name is still supported but creates warnings like | $ cargo | warning: `/sdk.../home/cargo/config` is deprecated in favor of `config.toml` | note: if you need to support cargo 1.38 or earlier, you can symlink `config` to `config.toml` Use the new name. (From OE-Core rev: 94b7d1a6cdb44949f8a96213ff2e45fafd759442) Signed-off-by: Enrico Scholz <enrico.scholz@sigma-chemnitz.de> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel.bbclass: Handle possible multiconfig.Sebastian Zenker2025-02-251-1/+1
| | | | | | | | | | | When specifying the dependencies of do_bundle_initramfs the current multiconfig might not be the default. This fixes the dependencies between the multiconfigs if the current differs to default. (From OE-Core rev: 2e40466af83a3c66aef878e3f08a891405199ebe) Signed-off-by: Mueller, Daniel <daniel.mueller@karlstorz.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* setuptools3-base.bbclass: override default subprocess timeoutHongxu Jia2025-02-181-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | The environment variable SETUPTOOLS_SCM_SUBPROCESS_TIMEOUT allows to override the subprocess timeout. The default is 40 seconds and should work for most needs.[1] However, it was not enough while using git shallow tarball and starting multiple Yocto world builds in one host. |   File "tmp/work/x86_64-linux/python3-scancode-native/32.1.0/recipe-sysroot- native/usr/lib/python3.13/subprocess.py", line 1263, in _check_timeout |     raise TimeoutExpired( |     ...<2 lines>... |             stderr=b''.join(stderr_seq) if stderr_seq else None) | subprocess.TimeoutExpired: Command '['git', '--git-dir', 'tmp/work/x86_64- linux/python3-scancode-native/32.1.0/git/.git', 'status', '--porcelain', '--untracked-files=no']' timed out after 40 seconds Explicitly set variable SETUPTOOLS_SCM_SUBPROCESS_TIMEOUT to 600s in bbclass, and we could override it in local.conf [1] https://github.com/pypa/setuptools-scm/blob/main/docs/overrides.md (From OE-Core rev: a3a2edbf7139b7f8c665c2b0b13e094a334e4441) Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meson.bbclass: Add an option to specify install tagsVyacheslav Yurkov2025-02-111-1/+7
| | | | | | | | | | The feature is available since meson 0.60.0. You can specify comma-separated list of install tags (not targets). (From OE-Core rev: a61ec67cb6f240c7593c9dd1b9a1ef5fff87c855) Signed-off-by: Vyacheslav Yurkov <uvv.mail@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-fitImage: Remove dependeny on initramfs image when bundled.Weisser, Pascal.ext2025-02-111-1/+1
| | | | | | | | | | | | In case the initramfs image is bundled into the kernel there's no need to specify a dependeny on the do_image_complete task of the initramfs image from the do_assemble_fitimage_initramfs task since the task won't access the image. (From OE-Core rev: af6cde746f72be761550ee28b017719fba26ea65) Signed-off-by: Weisser, Pascal <pascal.weisser.ext@karlstorz.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-fitImage: Take possible multiconfig into account.Weisser, Pascal.ext2025-02-111-2/+6
| | | | | | | | | | | | | | When specifying the dependencies of do_assemble_fitimage_initramfs the initramfs image might be built with another multiconfig. This needs to be taken into account. The path of the initramfs image also needs to be adapted to handle the case when it's built with another multiconfig. (From OE-Core rev: 891d58e9dc00e52f17ddecd4f12fc81c8a3c1bce) Signed-off-by: Weisser, Pascal <pascal.weisser.ext@karlstorz.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-fitimage.bbclass: do not use the UBOOT_ENV variableAdrian Freihofer2025-02-111-13/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The kernel-fitimage.bbclass evaluates the UBOOT_ENV variable from the u-boot recipe. Based on this variable an u-boot script might be added to the fitImage. However, the UBOOT_ENV variable is also used to install the script as an old u-boot image, usually named boot.scr into the /boot directory of the target device. This dual usage of one variable leads to several strange side effects. Some examples: - If UBOOT_ENV_SUFFIX is set to the default value scr, the boot.cmd script gets added as a legacy uImage to the fitImage. That does not look useful. - If the UBOOT_ENV_SUFFIX is set to e.g. txt the script is not converted into a legacy uImage and a usable plain text script gets added to the fitImage. But the same script ends up redundant in /boot. Another strange detail is that the UBOOT_ENV_BINARY gets set to e.g. boot.txt for this configuration. - Appending the script to the u-boot recipe and then hand it over to the kernel recipe via the staged /boot directory looks like over complicated. Such kind of over complications and u-boot kernel inter-dependencies lead to an almost unmaintainable kernel-fitimage.bbclass. - A single variable does not allow you to add a text file to the fitImage and at the same time place boot.scr file in the /boot directory of the target device. - It is not documented or obvious how the UBOOT_ENV variable should be used together with the kernel-fitimage.bbclass. The commit which introduced this feature (among other features...) is: https://git.yoctoproject.org/poky/commit/?id=8a2f4e143b52109fbd0ee8d792e327d460b8c1e6 This commit is going to remove the u-boot script part of it. The removal of this function requires a note in the migration guide. The migration should be straightforward: If UBOOT_ENV and the kernel-fitimage.bbclass are used, the u-boot script must now be appended to the kernel recipe and the new FIT_UBOOT_ENV variable must be used. (From OE-Core rev: ab7f0b5e3d3612c43f9aab9ea2b7bd554d02859d) Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* kernel-fitimage.bbclass: introduce FIT_UBOOT_ENVAdrian Freihofer2025-02-111-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a new variable FIT_UBOOT_ENV, which allows to add a u-boot script as a text file to the fitImage. Such a script can be sourced from the u-boot shell, as documented here: https://docs.u-boot.org/en/latest/usage/cmd/source.html#fit-image The kernel-fitimage.bbclass also evaluates the existing UBOOT_ENV variable and adds the corresponding script to the fitImage. However, the UBOOT_ENV variable is also used to install the script as an old u-boot image, usually named boot.scr into the /boot directory of the target device. These are different use cases which should be handled independently. Appending the script to the u-boot recipe and then hand it over to the kernel recipe via the staged /boot directory leads to complicated task dependencies. Decoupling the two use cases will also allow to simplify the implementation by dropping the evaluation of the UBOOT_ENV variable in the kernel-fitimage.bbclass. But this commit is supposed to be backward compatible. (From OE-Core rev: 269605ed053fd8dc7bcbcc04a46c308188115f66) Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com> Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cmake: apply parallel build settings to ptest tasksPeter Marko2025-02-101-0/+2
| | | | | | | | | | | | | | | ptest compile and install tasks do not have parallel build settings for cmake. On powerful build machines this can cause overload situations and oomkills. Observed when building qtgrpc with ptest generally enabled in distro. Having this in ptest class is suboptimal, but creating ptest-cmake class just for these two variables is probably overkill. (From OE-Core rev: 3c311fbf0c2090268e9b83123d762b05b61b4074) Signed-off-by: Peter Marko <peter.marko@siemens.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uki.bbclass: remove duplicate d.getVar('DEPLOY_DIR_IMAGE')Koen Kooi2025-02-101-2/+0
| | | | | | | | | | | This class calls d.getVar('DEPLOY_DIR_IMAGE') twice within the same method, but DEPLOY_DIR_IMAGE variable won't change during the run of this class, so only retrieve it once. (From OE-Core rev: 6866da9f3a273ed7217e9edfca299fc2e68b2f75) Signed-off-by: Koen Kooi <koen.kooi@oss.qualcomm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* uki.bbclass: capture ukify command stdout and stderrMikko Rapeli2025-02-101-1/+2
| | | | | | | | | | ukify tool can show important warnings and even errors if it fails so capture the logs. (From OE-Core rev: 6ac326a4f9d19fa154c9ce172a264f55ebe5b1ef) Signed-off-by: Mikko Rapeli <mikko.rapeli@linaro.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>