Add the ability to set the "firmware" property in the FIT configuration node
by introducing the UBOOT_FIT_CONF_FIRMWARE variable.
This property defines the primary image to be executed during boot. If it is
set, its value will be written into the FIT configuration under the "firmware"
field. If not set, the bootloader will fall back to using the first entry in
the "loadables" list.
Using this property improves control over the boot sequence, especially in
multi-binary boot scenarios.
(From OE-Core rev: 82e1d7cbc855dbe4bec93f9b049851cbe376ea5e)
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>
An unintended "-e" string may be written into the generated ITS file when users
set the UBOOT_FIT_USER_SETTINGS variable to include custom binaries in the U-Boot
image.
This issue is caused by the use of 'echo -e', which behaves inconsistently across
different shells. While bash interprets '-e' as enabling escape sequences
(e.g., \n, \t), dash—the default /bin/sh on many systems—does not recognize
'-e' and treats it as a literal string. As a result, "-e" can be mistakenly
injected into the ITS file under certain build environments.
To ensure consistent and shell-agnostic behavior, replace 'echo -e' with
'printf', which is well-defined by POSIX and behaves reliably across all common
shells.
This change improves portability and prevents malformed ITS files caused by unintended
string injection.
Fixes: c12e013 ("uboot-sign: support to add users specific image tree source")
(From OE-Core rev: 1d5d22a38188f2c879e289a9732b620b0a6f7a6e)
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>
Some recipes might provide conf files produced during build phase or
simply tracked in the VCS instead of generating them with Yocto.
In such cases those conf files wouldn't be assigned to correct packages.
With this change, if user wants to generate a conf file they still can,
but not generating them won't prevent assigning the file to proper
package given the file exists.
(From OE-Core rev: c7faf141592d1e2a5cab32a83f7e1498ee498d65)
Signed-off-by: Michal Sieron <michalwsieron@gmail.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
/etc/os-release is a symlink to /usr/lib.
Symlink is retrieved as a dead link which points to nowhere if also the
original file is not accompanying it.
Fetch the real file in addition to this link.
Alternative could be to use "tar -h" (supported also by busybox tar),
however that could lose some important information if links are relevant
for failure analysis.
(From OE-Core rev: ed43f9ccb3c08845259e24440912631afd780d12)
Signed-off-by: Peter Marko <peter.marko@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Add the task dependency:
do_uboot_assemble_fitimage -> virtual/kernel:do_kernel_generate_rsa_keys
to ensure the kernel FIT image signing keys are available when creating
the U-Boot DTB. This is done only if the signing of the kernel FIT image
is enabled (UBOOT_SIGN_ENABLE="1").
The lack of the dependency causes build errors when executing a build
with no kernel FIT keys initially present in the keys directory. In such
cases one would see an output like this in the Bitbake logs:
Log data follows:
| DEBUG: Executing shell function do_uboot_assemble_fitimage
| Couldn't open RSA private key: '/workdir/build/keys/fit/dev.key': No such file or directory
| Failed to sign 'signature' signature node in 'conf-1' conf node
| FIT description: Kernel Image image with one or more FDT blobs
| ...
This issue was introduced by commit 259bfa86f384 where the dependency
between U-Boot and the kernel was removed (for good reasons). Before
that commit the dependency was set via DEPENDS so that, in terms of
tasks, one had:
u-boot:do_configure -> virtual/kernel:do_populate_sysroot
and the chain leading to the key generation was:
virtual/kernel:do_populate_sysroot -> virtual/kernel:do_install
virtual/kernel:do_install -> virtual/kernel:do_assemble_fitimage
virtual/kernel:do_assemble_fitimage -> virtual/kernel:do_kernel_generate_rsa_keys
With the removal of the first dependency, no more guarantees exist that
the keys would be present when assembling the U-Boot FIT image. That's
the situation we are solving with the present commit.
Fixes: 259bfa86f384 ("u-boot: kernel-fitimage: Fix dependency loop if UBOOT_SIGN_ENABLE and UBOOT_ENV enabled")
(From OE-Core rev: 036f20156b3c7d0a8b912e90aa29a9b986106d5a)
Signed-off-by: Rogerio Guerra Borin <rogerio.borin@toradex.com>
Cc: Marek Vasut <marex@denx.de>
Cc: Sean Anderson <sean.anderson@seco.com>
Cc: 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>
In testimage, the ptest-runner output parser expects test results to follow
a specific format,with lines beginning with PASS:, FAIL:, or SKIP:. ptest-cargo,
currently, does not emit any of those lines and the parser treats the test
section as having no results, causing a test failure with :
AssertionError:
ptests which had no test results:
['<package>']
This patch ensures that the recipes using ptest-cargo class explicitly emits
PASS: or FAIL: lines, making the results compatible with the test parser and
preventing test failures.
(From OE-Core rev: 6a9356346f13556a06d4a99bd7924992c7e29d66)
Signed-off-by: Ines KCHELFI <ines.kchelfi@smile.fr>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
-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>
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>
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>
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>
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 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.
6d2a3e9786
[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: e4ca11f87f
- Explicitly set float ABI for all ARM 32 bits targets.
Fix: a51fefcaab
- Rust v1.85.0 tarball doesn't ship gcc tree.
Drop "remove_gcc_directory" postfunc which removed it and prevented the bloat.
Fix: 13c3f9b949
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>
* 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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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] 507d1b22f4
[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>
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>
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>
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>
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>
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 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>
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>
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>
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>
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>
