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>
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>
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>
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>
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>
This reverts commit 0d14e99aa18ee38293df63d585fafc270a4538be.
The patch removed logic required for correct handling of
UBOOT_SUFFIX=img or UBOOT_SUFFIX=rom. We need to find a better way to
handle the fix for [YOCTO #15649].
(From OE-Core rev: 5e82d33451b5662df1e7fe2518a50644d18aa70d)
Signed-off-by: Ryan Eatmon <reatmon@ti.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Without unsetting `j` and `k` for each `UBOOT_MACHINE`, `j` and `k`
are incremented in the same frequency as `i` and therefore `$j -eq $i`
and `$k -eq $i` is always true for the first `type` from `UBOOT_CONFIG`
and the first `binary` from `UBOOT_BINARIES`.
(From OE-Core rev: 3aef55c7ceb654b0012f20618bfd6ead1ef578b6)
Signed-off-by: Paul Gerber <paul.gerber@ew.tq-group.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
When using multiple u-boot configurations in UBOOT_CONFIG, the helper
function uboot_assemble_fitimage_helper() was not called with all
combinations of type & binary, due to a copy-n-paste indexing error.
(From OE-Core rev: 2d338548a4b745a71eaf6c29231adc93c4165778)
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
It does not verify the signed FIT image of kernel and uboot.
To catch the unexpected errors as far as possible at the build time,
add uboot-fit-check-sign tool which is provided by u-boot to
verify the signed FIT image.
(From OE-Core rev: 17d3c8315e7a7adbe27183e11e1b6d588c1a1784)
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
According to the design of uboot-sign.bbclass and kernel-fitimage.bbclass,
both of them use an UBOOT_LOADADDRESS variable to set the load address of
kernel and u-boot image and use an UBOOT_ENTRYPOINT variable to set the entry address of
kernel and u-boot image.
However, users may want to set the different load address of u-boot
and kernel image. Therefore, adds UBOOT_FIT_UBOOT_LOADADDRESS
and UBOOT_FIT_UBOOT_ENTRYPOINT variables to set the
load address and entry point of u-boot image, respectively.
The value of UBOOT_FIT_UBOOT_ENTRYPOINT is UBOOT_LOADADDRESS by default.
The value of UBOOT_FIT_UBOOT_ENTRYPOINT is UBOOT_ENTRYPOINT by default.
(From OE-Core rev: 2060691a56b45f746efdd04ccdae3fb74df60cb5)
Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.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 support 32bits address for uboot FIT image.
However, some platforms may want to support 64bits address of
UBOOT_LOADADDRESS and UBOOT_ENTRYPOINT.
Therefore, add variables to support both 64bits and 32bits address.
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: b4e46cdbd0727d97d13c2b8e9e4ce19c5c693f51)
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 prepended code with the i and j variables clash with similar code in uboot.inc, so they need to be unset once we are done using them.
This commit fixes the issue that was introduced in d6858c9 "u-boot: Rework signing to remove interdependencies".
(From OE-Core rev: 6f668f85d7e5b0a9d36198db865cf1e1a012b2e1)
Signed-off-by: David Bagonyi <david.bagonyi@gmail.com>
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>
uboot_fitimage_assemble is called from one place with the same
arguments. Instead of using shell variables as intermediaries, simplify
the function by using the bitbake variables directly. Removing a layer
of indirection makes it easier to determine what values are being
substituted in. Some variables can't be fully converted, but they will
be addressed in the a few commits.
(From OE-Core rev: 27f42c9b9a91742d3ee358aa8dc29627379b2539)
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>
When generating our SPL-verifying certificate, we use FIT_KEY_REQ_ARGS,
which is intended for the U-Boot-verifying certificate. Instead, use
UBOOT_FIT_KEY_REQ_ARGS.
Fixes: 0e6b0fefa0 ("u-boot: Use a different Key for SPL signing")
(From OE-Core rev: a2d939ccb182a1ad29280d236b9f9e1d09527af1)
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>
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>
