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>
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>
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>
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>
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>
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 <adrian.freihofer@siemens.com>
(From OE-Core rev: 259bfa86f384206f0d0a96a5b84887186c5f689e)
Signed-off-by: Marek Vasut <marex@denx.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
If EXTERNAL_KERNEL_DEVICETREE and dtb_image_sect are empty variables
dtb_path ends up as "/" which is available on most Unix systems but
probably not the dtb_path which is needed here. Checking for a file
makes more sense and also solves the issue with the "/".
(From OE-Core rev: c8f629b6991449cc6726f48a607d9e1bd50807ee)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
white space changes only.
- python part should be 4 spaces, not 8.
- use tabs for shell
(From OE-Core rev: 000079a973e8c97d496ca721259437880a7ea70d)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Fix error in run.do_assemble_fitimage_initramfs.2779256:
line 238: [: =: unary operator expected
if FIT_CONF_DEFAULT_DTB is empty.
(From OE-Core rev: 19a6eea0951404403dcb5d0deeda8558b1337f82)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without this commit the configuration node includes the compatible
line 'compatible = [00];' if EXTERNAL_KERNEL_DEVICETREE is not
defined, i.e. if PREFERRED_PROVIDER_virtual/dtb is not used.
This prevents u-boot from using this configuration and it prints the
message "Could not find configuration node".
An additional check also ensures that the written compatible line
never contains an empty compatible.
The functionality to add the compatible line was added in commit
f4c82fb6da89 ("kernel-fitImage: add machine compatible to config
section").
(From OE-Core rev: f8f3a52b2f924789552e6a3f889162ff07e0887f)
Signed-off-by: Christian Taedcke <christian.taedcke@weidmueller.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Machines that have added subdirectires to the KERNEL_DEVICETREE
recently, such as arm32 boards that were moved under subdirectories in
Linux 6.5, will have that subdirectory in the node name of the FIT. This
breaks existing systems that select a configuration in u-boot by it's
name.
Strip off the directory component from the device tree to preserve
compatibility.
(From OE-Core rev: 941ba1a132bafa9c9be855fb91fec96d8b06299f)
Signed-off-by: Joel Stanley <joel@jms.id.au>
Signed-off-by: Ninad Palsule <ninad@linux.ibm.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The default value of address-cells is "1", so the generated "its" file
only supports 32bits address for kernel FIT image.
However, some platforms may want to support 64bits address
of UBOOT_LOADADDRESS and UBOOT_ENTRYPOINT.
Therefore, adds a variable to support both 64bits and 32bits address cells.
By default, the address-cell is "1" which is used for 32bits load address.
If users would like to use 64bits load address, users are able to
set as following for "0x400000000" 64bits load address.
1. FIT_ADDRESS_CELLS = "2"
2. UBOOT_LOADADDRESS= "0x04 0x00000000"
(From OE-Core rev: 8ce15c76c50d5d61524fea585d19989baefb5df2)
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The current check for default dtb image checks if the file exists and is
not empty but appends a slash to the path due to which the file is never
found. It also doesn't replace slash in filename with _ as done when
populating the DTB variable. A better way to check the existence of the
device tree would be from the list of DTBs since this is used during
compilation.
(From OE-Core rev: e8e31e11b158837804d029e85f5f8ed3c219a4ea)
Signed-off-by: Arslan Ahmad <arslan_ahmad@mentor.com>
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Allow user to select the default DTB for FIT image when multiple
dtb's exists.
From machine.conf or local.conf user can specify the default dtb
for FIT image as shown below.
FIT_CONF_DEFAULT_DTB = "board-default.dtb"
Also fallback to avaialable dtb when FIT_CONF_DEFAULT_DTB doesn't
exits or empty.
(From OE-Core rev: 160f2c58d68a049a87ddc7aedb2055152ac6ff4e)
Signed-off-by: Sandeep Gundlupet Raju <sandeep.gundlupet-raju@amd.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The dtb files must be before the dtbo files, otherwise the overlays may
not be applied correctly.
From Bruce Ashfield:
We can split between dtbs and dtbos, they just need to be sorted
for reproducibility reasons.
Of course, this was only working by luck previously (before the
sort), since it has always been gathering dtbs and dtbo's with
find, depending on filesystem ordering for the order in the
fitimage).
(From OE-Core rev: bcb3c0272f6ab846c3232548df1e1182bcc67486)
Signed-off-by: Sandeep Gundlupet Raju <sandeep.gundlupet-raju@amd.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This reverts commit ef0d0734866505c1c6e0528a0423e7248afb3ff8.
We can't do this since the initramfs needs to use DEPLOY_DIR_IMAGE which isnt
ready until do_image_complete.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
In order to build a fitimage, we don't need the image to be "complete"
but we need the cpio portion of it built since the cpio is what ends
up inside the FIT. By reducing the dependency to `do_image_cpio` we
are able to include an image's rootfs as the ramdisk for a FIT and
then bundle that FIT into a larger SPI flash layout.
(From OE-Core rev: ef0d0734866505c1c6e0528a0423e7248afb3ff8)
Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When building a FIT image with device trees, each device tree lands in a
FIT section and is referenced by a FIT configuration node.
FIT images however also allow referencing the same device tree from
multiple configurations. This can be useful to reduce FIT image size
while staying compatible with existing bootloaders. Allow
kernel-fitimage.bbclass users to take advantage of this by mapping
each symlink to a regular device tree included in the FIT to a
configuration that references a common device tree section.
(From OE-Core rev: 21e240da63239826f3ef50ceef40c9519e9030d8)
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This introduces no functional change, but will come in handy in a later
commit where a file lookup will have us using the device tree name. If
we keep it like it's now, we will lose the information whether an
underscore is an original underscore or a mangled slash.
(From OE-Core rev: 8bea426ca59d17715a3b32f7e3caf3e4b6db5ce9)
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The U-Boot signing code is a bit of a mess. The problem is that mkimage
determines the public keys to embed into a device tree based on an image
that it is signing. This results in all sorts of contortions: U-Boot has to
be available to the kernel recipe so that it can have the correct public
keys embedded. Then, the signed U-Boot has to be made available to U-Boot's
do_deploy. This same dance is then repeated for SPL. To complicate matters,
signing for U-Boot and U-Boot SPL is optional, so the whole process must be
seamlessly integrated with a non-signed build.
The complexity and interdependency of this process makes it difficult to
extend. For example, it is not possible to install a signed U-Boot binary
into the root filesystem. This is first because u-boot:do_install must run
before linux:do_assemble_fitimage, which must run before u-boot:do_deploy.
But aside from infrastructure issues, installing a signed U-Boot also can't
happen, because the kernel image might have an embedded initramfs
(containing the signed U-Boot).
However, all of this complexity is accidental. It is not necessary to embed
the public keys into U-Boot and sign the kernel in one fell swoop. Instead,
we can sign the kernel, stage it, and sign the staged kernel again to embed
the public keys into U-Boot [1]. This twice-signed kernel serves only to
provide the correct parameters to mkimage, and does not have to be
installed or deployed. By cutting the dependency of
linux:do_assemble_fitimage on u-boot:do_install, we can drastically
simplify the build process, making it much more extensible.
The process of doing this conversion is a bit involved, since the U-Boot
and Linux recipes are so intertwined at the moment. The most major change
is that uboot-sign is no longer inherited by kernel-fitimage. Similarly,
all U-Boot-related tasks have been removed from kernel-fitimage. We add a
new step to the install task to stage the kernel in /sysroot-only. The
logic to disable assemble_fitimage has been removed. We always assemble it,
even if the final fitImage will use a bundled initramfs, because U-Boot
will need it.
On the U-Boot side, much of the churn stems from multiple config support.
Previously, we took a fairly ad-hoc approach to UBOOT_CONFIG and
UBOOT_MACHINE, introducing for loops wherever we needed to deal with them.
However, I have chosen to use a much more structured approach. Each task
which needs to use the build directory uses the following pseudocode:
do_mytask() {
if ${UBOOT_CONFIG}; then
for config, type in zip(${UBOOT_CONFIG}, ${UBOOT_MACHINE}); do
cd ${config}
mytask_helper ${type}
done
else
cd ${B}
mytask_helper ""
fi
}
By explicitly placing the work in mytask_helper, we make it easier to
ensure that everything is covered, and we also allow bbappends files to
more easily extend the task (as otherwise they would need to reimplement
the loop themselves).
[1] It doesn't particularly matter what we sign. Any FIT will do, but I
chose the kernel's because we already went to the trouble of setting it up
with the correct hashes and signatures. In the future, we could create a
"dummy" image and sign that instead, but it would probably have to happen
in the kernel recipe anyway (so we have access to the appropriate
variables).
(From OE-Core rev: 5e12dc911d0c541f43aa6d0c046fb87e8b7c1f7e)
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
We have a specific variable for the path to the boot directory. Use it
instead of open-coding this path.
(From OE-Core rev: 725b75e83bc2b2111f2ab5103b7e7f60d6d3f34e)
Signed-off-by: Sean Anderson <sean.anderson@seco.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The KERNEL_DEVICETREE and related variables could potentially have a device
tree listed multiple times and this works okay for most scenarios. However,
when we create FIT entries for these we get duplicate nodes and uboot-mkimage
fails with
fit-image-initramfs-image.its:219.58-229.19: ERROR (duplicate_node_names): /images/fdt-freescale_imx8mp-evk-ecspi-slave.dtb: Duplicate node name
fit-image-initramfs-image.its:307.50-317.19: ERROR (duplicate_node_names): /images/fdt-freescale_imx8mp-evk-ndm.dtb: Duplicate node name
fit-image-initramfs-image.its:362.54-372.19: ERROR (duplicate_node_names): /images/fdt-freescale_imx8mp-evk-rm67199.dtb: Duplicate node name
fit-image-initramfs-image.its:417.56-427.19: ERROR (duplicate_node_names): /images/fdt-freescale_imx8mp-evk-usdhc1-m2.dtb: Duplicate node name
fit-image-initramfs-image.its:648.59-658.19: ERROR (duplicate_node_names): /configurations/conf-freescale_imx8mp-evk-ecspi-slave.dtb: Duplicate node name
fit-image-initramfs-image.its:744.51-754.19: ERROR (duplicate_node_names): /configurations/conf-freescale_imx8mp-evk-ndm.dtb: Duplicate node name
fit-image-initramfs-image.its:804.55-814.19: ERROR (duplicate_node_names): /configurations/conf-freescale_imx8mp-evk-rm67199.dtb: Duplicate node name
fit-image-initramfs-image.its:864.57-874.19: ERROR (duplicate_node_names): /configurations/conf-freescale_imx8mp-evk-usdhc1-m2.dtb: Duplicate node name
ERROR: Input tree has errors, aborting (use -f to force output)
uboot-mkimage: Can't open arch/arm64/boot/fitImage.tmp: No such file or directory
We fix this by tracking the DTBs we're compiling in the FIT and only picking
up unique ones.
(From OE-Core rev: 98acfea1e82a90c920bdd636033f930ac034b318)
Signed-off-by: Awais Belal <awais_belal@mentor.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move classes to classes-global or classes-recipe as appropriate to take
advantage of new bitbake functionality to check class scope/usage.
(From OE-Core rev: f5c128008365e141082c129417eb72d2751e8045)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
