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>
Fix a problem with `devtool modify` as suggested by Marcus Flyckt on
the mailing list:
```
I encountered an issue with `do_config` when using `devtool modify`
on `u-boot-imx`.
```
[...]
| cp: cannot stat '[...]/u-boot-imx/2024.04/build/imx8mp_wl400s_defconfig/.config': No such file or directory
| WARNING: exit code 1 from a shell command.
ERROR: Task ([...]/sources/poky/../meta-freescale/recipes-bsp/u-boot/u-boot-imx_2024.04.bb:do_configure) failed with exit code '1'
NOTE: Tasks Summary: Attempted 963 tasks of which 962 didn't need to be rerun and 1 failed.
Summary: 1 task failed:
[...]/sources/poky/../meta-freescale/recipes-bsp/u-boot/u-boot-imx_2024.04.bb:do_configure
Summary: There was 1 ERROR message, returning a non-zero exit code
```
The issue seems to originate from the following lines in
`workspace/appends/u-boot-imx_2024.04.bbappend`:
```
do_configure:append() {
if [ ${@oe.types.boolean(d.getVar("KCONFIG_CONFIG_ENABLE_MENUCONFIG"))} = True ]; then
cp ${KCONFIG_CONFIG_ROOTDIR}/.config ${S}/.config.baseline
ln -sfT ${KCONFIG_CONFIG_ROOTDIR}/.config ${S}/.config.new
fi
}
```
For some reason `KCONFIG_CONFIG_ROOTDIR` does not point to the
correct directory. It gets its value in `uboot-config.bbclass`:
```
if len(ubootconfig) == 1:
d.setVar('KCONFIG_CONFIG_ROOTDIR', os.path.join(d.getVar("B"), d.getVar("UBOOT_MACHINE").strip()))
```
So the main issue is that B gets expanded in this expression, and
then later B gets changed by `externalsrc.bbclass`.
`d.getVar("B", False)` does not solve the issue, however the
proposed change does.
```
- https://lists.yoctoproject.org/g/yocto/topic/109254298#msg64152]
Fixes [YOCTO #15603]
Suggested-by: Marcus Flyckt <marcus.flyckt@gmail.com>
(From OE-Core rev: 57b21065a25100c31515b32fd7c77bde3355d684)
Signed-off-by: Tom Hochstein <tom.hochstein@oss.nxp.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
How to reproduce:
- UBOOT_CONFIG must be used. With UBOOT_MACHINE it works fine.
A simple example based on oe-core is to modify the
beaglebone-yocto.conf file like this:
-UBOOT_MACHINE = "am335x_evm_defconfig"
+UBOOT_CONFIG = "foo"
+UBOOT_CONFIG[foo] = "am335x_evm_defconfig"
- A build configuration which inherits the kernel-fitimage.bbclass is
needed. For example:
MACHINE = "beaglebone-yocto"
KERNEL_IMAGETYPE = "Image"
KERNEL_IMAGETYPES += " fitImage "
KERNEL_CLASSES = " kernel-fitimage "
devtool modify linux-yocto
devtool build linux-yocto
...
| cp: cannot stat '.../linux-yocto-6.6.21+git/am335x_evm_defconfig/.config':
No such file or directory
| WARNING: .../linux-yocto/6.6.21+git/temp/run.do_configure.2081673:172 exit 1
from 'cp .../linux-yocto-6.6.21+git/am335x_evm_defconfig/.config
.../build/workspace/sources/linux-yocto/.config.baseline'
The reason for this problem is that the uboot-config.bbclass sets the
variable KCONFIG_CONFIG_ROOTDIR to a path that makes sense for u-boot,
but not for other recipes. However, the kernel-fitimage.bbclasse, for
example, inherits the uboot-config.bbclass, which brings the
u-boot-specific path into the kernel build context.
This change removes the uboot-specific KCONFIG_CONFIG_ROOTDIR path from
recipes other than u-boot itself.
(From OE-Core rev: b23581a22619c52724c8e078f29e871e2ee74259)
Signed-off-by: Adrian Freihofer <adrian.freihofer@siemens.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Commit cc6c3e31526d ("u-boot: Move definitions to common locations") moved
UBOOT_INITIAL_ENV to uboot-config.bbclass, but it should be kept at u-boot.inc
because it encodes ${PN} in it, which should be set by the U-Boot recipe.
Currently, whatever inherits uboot-config bbclass will fill-in its own PN,
which would change the content of UBOOT_INITIAL_ENV per-package.
Cc: Klaus Heinrich Kiwi <klaus@linux.vnet.ibm.com>
Cc: Marek Vasut <marex@denx.de>
Fixes: cc6c3e31526d ("u-boot: Move definitions to common locations")
(From OE-Core rev: 0b0c4b37d318b86f100512476ffd861e0ce1f47e)
Signed-off-by: Fabio Estevam <festevam@denx.de>
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>
Currently, uboot do_menuconfig task is breaking when UBOOT_CONFIG is
chosen rather than UBOOT_MACHINE, it simply fails with the following
errors:
| make: *** No rule to make target 'menuconfig'. Stio.
| Command failed.
| Press any key to continue...
this is due to the work directory of do_menuconfig is set to ${B} but
not ${B}/$config.
We should distinguish two situations:
1) When there is only one config item in UBOOT_CONFIG, do_menuconfig
should work just like how it works for UBOOT_MACHINE.
2) When there are multiple config items in UBOOT_CONFIG, do_menuconfig
should print out some information saying it's not supported other
than just failing.
This patch mainly aims to fix that by introducing a extra variable
KCONFIG_CONFIG_ENABLE_MENUCONFIG, it would be set to 'false' for
situation 2), and when it's set to 'true', then set
KCONFIG_CONFIG_ROOTDIR correctly in uboot-config.bbclass to let
do_menuconfig task work.
DEVTOOL_DISABLE_MENUCONFIG could be replaced by this new variable
KCONFIG_CONFIG_ENABLE_MENUCONFIG.
(From OE-Core rev: f9e834e317880cf47dbb4f8285bc36d743beae5e)
Signed-off-by: Ming Liu <liu.ming50@gmail.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>
Previously we had the support to build multiple u-boot configs for a
machine, but after the change in the commit 801a27d73b10
("uboot-config.bbclass: Raise error for bad key"), this anonymous
function would bail out after handling the first config in UBOOT_CONFIG.
This is definitely not what we want. Fix it by making sure all the
configs are handled.
Fixed: 801a27d73b10 ("uboot-config.bbclass: Raise error for bad key")
(From OE-Core rev: 372798afe028569b07ac55e0dc1ff377d83d18bf)
Signed-off-by: Kevin Hao <kexin.hao@windriver.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>
