linux/poky.git/meta/conf, branch 5.2_M2

u-boot: kernel-fitimage: Fix dependency loop if UBOOT_SIGN_ENABLE and UBOOT_ENV enabled

2025-01-22T13:20:29+00:00

In case both UBOOT_SIGN_ENABLE and UBOOT_ENV are enabled and kernel-fitimage.bbclass is in use to generate signed kernel fitImage, there is a circular dependency between uboot-sign and kernel-fitimage bbclasses . The loop looks like this: kernel-fitimage.bbclass: - do_populate_sysroot depends on do_assemble_fitimage - do_assemble_fitimage depends on virtual/bootloader:do_populate_sysroot - virtual/bootloader:do_populate_sysroot depends on virtual/bootloader:do_install => The virtual/bootloader:do_install installs and the virtual/bootloader:do_populate_sysroot places into sysroot an U-Boot environment script embedded into kernel fitImage during do_assemble_fitimage run . uboot-sign.bbclass: - DEPENDS on KERNEL_PN, which is really virtual/kernel. More accurately - do_deploy depends on do_uboot_assemble_fitimage - do_install depends on do_uboot_assemble_fitimage - do_uboot_assemble_fitimage depends on virtual/kernel:do_populate_sysroot => do_install depends on virtual/kernel:do_populate_sysroot => virtual/bootloader:do_install depends on virtual/kernel:do_populate_sysroot virtual/kernel:do_populate_sysroot depends on virtual/bootloader:do_install Attempt to resolve the loop. Pull fitimage configuration options into separate new configuration file image-fitimage.conf so these configuration options can be shared by both uboot-sign.bbclass and kernel-fitimage.bbclass, and make use of mkimage -f auto-conf / mkimage -f auto option to insert /signature node key-* subnode into U-Boot control DT without depending on the layout of kernel fitImage itself. This is perfectly valid to do, because the U-Boot /signature node key-* subnodes 'required' property can contain either of two values, 'conf' or 'image' to authenticate either selected configuration or all of images when booting the fitImage. For details of the U-Boot fitImage signing process, see: https://docs.u-boot.org/en/latest/usage/fit/signature.html For details of mkimage -f auto-conf and -f auto, see: https://manpages.debian.org/experimental/u-boot-tools/mkimage.1.en.html#EXAMPLES Fixes: 5e12dc911d0c ("u-boot: Rework signing to remove interdependencies") Reviewed-by: Adrian Freihofer (From OE-Core rev: 259bfa86f384206f0d0a96a5b84887186c5f689e) Signed-off-by: Marek Vasut Signed-off-by: Richard Purdie

base: Switch virtual/cross-XXX to be under recipe specific providers

2025-01-21T23:09:34+00:00

Currently, providers are set on a global config basis. This change allows for a select set of providers to be configured using BB_RECIPE_VIRTUAL_PROVIDERS on a per recipe basis. This would allow for the selection of virtual/cross-cc as gcc or clang for example. The PROVIDERS are removed from the recipes so that if a version of the dependency accidentally slips through, the build will fail and the user can correct the issue. (From OE-Core rev: 6eeab1a5d7f23917b94c130e417d59afb757b546) Signed-off-by: Richard Purdie

classes/recipes: Switch virtual/XXX-gcc to virtual/cross-cc (and c++/binutils)

2025-01-21T23:09:33+00:00

The idea of the base class dependency is to say "yes, I need a C cross compiler" and this was never meant to be gcc specific. Looking at the codebase, whilst we code triplets into this, it does overcomplicate things as there are only ever limited, "target", "sdk" and the class extended versions like mutlilib. After much thought, we can simplify this to virtual/cross-cc and virtual/nativesdk-cross-cc. This lets us remove the "gcc" specific element as well as removing the over complicated triplet usage. At the same time, change the much less widely used "g++" variant to "c++" for similar reasons and remove the triplet from virtual/XXX-binutils too. Backwards compatibility mappings could be left but are just going to confuse things in future so we'll just require users to update. This simplification, whilst disruptive for any toolchain focused layers, will make improved toolchain selection in the future much easier. Since we no longer have overlapping variables, some code for that can just be removed. The class extension code does need to start remapping some variables but not the crosssdk target recipe names. This patch is in two pieces, this one handles the renaming with the functional changes separate in a second for easier review even if this breaks bisection. (From OE-Core rev: 4ccc3bc8266c327bcc18c9a3faf7536210dfb9f0) Signed-off-by: Richard Purdie

rust: Upgrade 1.80.1->1.81.0

2025-01-14T11:57:52+00:00

https://blog.rust-lang.org/2024/09/05/Rust-1.81.0.html Drop the following backported patches which is addressed with rust v1.81.0 upgrade. 0001-cargo-do-not-write-host-information-into-compilation.patch https://github.com/rust-lang/cargo/commit/2db0bab16139d094f689587b73539aae386a1919 hardcodepaths.patch https://github.com/rust-lang/rust/commit/28503d69ac204ff208d115aea30dc09d6fca8728 (From OE-Core rev: 611ec9ffbac974f472a828277ba7f3e344e99ca3) Signed-off-by: Deepesh Varatharajan Signed-off-by: Richard Purdie

multilib.conf: overwrite conf files for debs

2025-01-11T18:37:14+00:00

Similar to OPKG, overwrite conf files for APT (deb files). (From OE-Core rev: b1d29b8b05ea7ebdb04f53afc0003bc04d8e71ec) Signed-off-by: Benjamin Bara Signed-off-by: Richard Purdie

qemu/machine: rename QEMU_EXTRAOPTIONS for consistency

2025-01-11T18:34:15+00:00

The per-tune qemu options variable is QEMU_EXTRAOPTIONS_${TUNE_PKGARCH}, but this doesn't follow the pattern of all of the other tune-specific variables in the machine configuration which is VARIABLE:tune-[name]. Rename QEMU_EXTRAOPTIONS_${TUNE_PKGARCH} to QEMU_EXTRAOPTIONS:tune-${TUNE_PKGARCH} for consistency. Note that this will mean that BSPs need to update any assignments of this variable. (From OE-Core rev: 7f981d074442b901f7e64dbdb9db851ff31c3733) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

classes/qemu: move QEMU_EXTRAOPTIONS for PPC to the relevant tunes

2025-01-11T18:34:15+00:00

Every other architecture has the QEMU_EXTRAOPTIONS assignments in the tune files, so move the PPC ones too. (From OE-Core rev: ba05251c89d8cc243e861886124573c83197e949) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

blktool: remove the recipe

2025-01-10T11:10:00+00:00

It was created in 2004 as an alternative to hdparm and never updated since (while hdparm remains in active development). (From OE-Core rev: 54c1243a259a2f6407c0202d03414fc5272b2d90) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie

conf/distro/defaultsetup: Use include_all for maintainers.inc

2025-01-08T13:25:11+00:00

Being able to set maintainers is really a "per layer" configuraiton item. Use include_all so that such maintainer information would be added for all configured layers, if the layer chooses to have such information in a conf/distro/include/maintainers.inc file in a given layer. (From OE-Core rev: d6b9dc4629642a4bf0d8f34a90bd8e3291c87501) Signed-off-by: Richard Purdie

bitbake.conf: Drop obsolete and misleading comment

2025-01-08T12:37:20+00:00

"packaged staging" is obsolete and now we have sstate. Multimachine is just the norm now, I doubt people remember how things used to be! Drop the comment as it is misleading and obsolete. (From OE-Core rev: 808d2a526e3dd6d77c524d8faa0af3e78cf0bed6) Signed-off-by: Richard Purdie