linux/poky.git/meta/classes-recipe/kernel-fitimage.bbclass, branch master

kernel-fitimage.bbclass: remove it

2025-06-05T10:02:22+00:00

The integration of the FIT image-related build steps into the kernel recipe has proven to be not very good. The new implementation with kernel-fit-image.bbclass fixes some design issues: * sstate does not work well when a fitImage contains an initramfs. The kernel is rebuilt from scratch if the build runs from an empty TMPDIR. * A fitImage kernel is not available as a package, but all other kernel image types are. * The task dependencies in the kernel are very complex and difficult to debug if something goes wrong. As a separate, downstream recipe, this is now much easier. The long storry about this issue is here: [YOCTO #12912] (From OE-Core rev: deb6bc3bea30dadabdb580a7a58a3b2e277af400) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie

kernel-fitimage: re-write its code in Python

2025-06-05T10:02:22+00:00

Rewrite the kernel-fitimage.bbclass file in Python. This allows the reuse of the new fitimage Python library and a clear alignment of the two implementations. Actually, the motivation for an implementation in Python was different. During the transition from the kernel-fitimage.bbclass to the new linux-yocto-fitimage.bb, the existing shell code was rewritten in Python so that the fitimage.py library could be extracted. The new kernel-fit-image.bbclass and linux-yocto-fitimage.bb were then developed on this basis. This approach makes it possible to run the same tests for all different implementations: - kernel-fitimage.bbclass in Shell - kernel-fitimage.bbclass in Python - linux-yocto-fitimage.bb Changing the commit order now enables a smooth transition. The two implementations can coexist. Maintenance and testing should be feasible for a few months with reasonable effort as they share most of the code. But of course, the goal is to remove the kernel-fitimage.bbclass as soon as possible. This commit opens the path for different strategies going forward: - Just replace the old implementations with the new one and ignoring this commit. - Add the new implementation and keep the old implementation without any change. - Add the new implementation and this commit and support the old architecture sharing most of the code with the new architecture and implementatiion. (From OE-Core rev: 6b513a530fcc6d99463fd824bb7208043f59414b) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie

kernel-fitimage: refactor order in its

2025-06-05T10:02:21+00:00

When the ITS file is created, the mandatory properties are written first before the optional properties are written. This is not really useful for the current implementation. But it is a preparation for a new Python-based implementation that will expect mandatory properties first. This change makes it possible to run the tests with both the old and the new implementation. (From OE-Core rev: 1044366a32d544af53307a03d7d3b0aaf4519990) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie

kernel-signing-keys-native: refactor key generation into a new recipe

2025-06-05T10:02:21+00:00

The do_kernel_generate_rsa_keys function from kernel-fitimage.bbclass is moved to a new recipe, kernel-signing-keys-native.bb. This refactoring introduces no functional changes. Intention this change: - Remove the dependency of uboot-sign.bbclass on kernel-fitimage.bbclass. - Simplify the use of custom key generation implementations by isolating the functionality into a separate recipe. Known limitations of this (and also the previous) implementation: - When generating from an existing TMPDIR, the existing key is reused. However, when generating from an empty TMPDIR or an SDK using the sstate-cache, a new key is generated, which may lead to inconsistencies. - The use of random keys (via FIT_GENERATE_KEYS) is convenient for experiments but unsuitable for production environments requiring deterministic and secure key management. Future improvements to consider: - Ensure reproducibility, even when using the sstate-cache. However, simply storing the private key in a potentially shared sstate artifact may not always be ideal from a security perspective. - Support encrypted keys via `SRC_URI` for reliable key updates. - Enable signing with an HSM (Hardware Security Module) through mechanisms like PKCS#11 or post-processing scripts. (From OE-Core rev: 88736bb53fd2f0ffa1d249fc1a37897d10c8be18) Signed-off-by: Adrian Freihofer Signed-off-by: Richard Purdie

linux-fitimage: sign setup sections

2025-03-11T11:20:34+00:00

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 Signed-off-by: Richard Purdie

kernel-fitImage: Remove dependeny on initramfs image when bundled.

2025-02-11T11:44:19+00:00

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 Signed-off-by: Richard Purdie

kernel-fitImage: Take possible multiconfig into account.

2025-02-11T11:44:19+00:00

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 Signed-off-by: Richard Purdie

kernel-fitimage.bbclass: do not use the UBOOT_ENV variable

2025-02-11T11:44:19+00:00

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 Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

kernel-fitimage.bbclass: introduce FIT_UBOOT_ENV

2025-02-11T11:44:19+00:00

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 Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

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