openembedded core renamed the build directory to include the build type.
commit 22e96b32b0be ("u-boot: Make sure the build dir is unique for
each UBOOT_CONFIG")
Follow that.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
The series [1] changed the way sources are fetched/unpacked and
S needs to follow that. Additionally for git repos it moved away from
having 'git/' as the checkout directory.
This has been partly tested by building weston based image for
imx6/imx6ull/imx7/imx8/imx8mm/imx8mp/imx95 based images.
E.g. none of the recipes specific for qoriq is built time tested.
As walnascar is no longer compatible with master/whinlatter drop
it from LAYERSERIES_COMPAT.
[1] https://lore.kernel.org/openembedded-core/20250616095000.2918921-1-alex.kanavin@gmail.com/
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
After commit commit 015483904c52 ("arm: imx8m: add OP-TEE node") in
upstream U-Boot, Binman complains if building imx8mp_evk with
CONFIG_OPTEE=y because tee.bin is missing:
Image 'image' is missing external blobs and is non-functional: tee-os
/binman/section/nxp-imx8mcst@1/fit/images/tee/tee-os (tee.bin):
See the documentation for your board. You may need to build Open Portable
Trusted Execution Environment (OP-TEE) and build with TEE=/path/to/tee.bin
Image 'image' has faked external blobs and is non-functional: tee.bin
Some images are invalid
make: *** [Makefile:1135: .binman_stamp] Error 103
This commit ensures that ${OPTEE_BOOT_IMAGE}, for example, tee.bin for
imx8mp-evk, is copied to the build folder if the optee feature is
enabled.
Add the SECO FW file name for i.MX 91. It is based on
imx-6.6.52_2.2.0 NXP BSP release.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Using the UUU-tagged bootloader image directly with UUU can cause UUU
to hang. The bootloader image is split on a certain transmit size, and
the hang occurs if the tag does not fit with the final bytes of the
bootloader image and must be split into a new transmit package.
The UUU tag is needed by UUU only in the SD Card image file itself so
that UUU can find the end of the boot partition.
Rework the design so the default bootloader and the default imx-boot
binaries are not tagged.
Also, extend the UUU tagging to fslc so it can gain the same benefit.
Fixes: https://github.com/Freescale/meta-freescale/pull/1762
Fixes: https://github.com/nxp-imx/mfgtools/issues/416
Co-authored-by: Otavio Salvador <otavio@ossystems.com.br>
Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
This fixes regression done in the mentioned commit.
Fixes: d7e13f19fb ("fsl-u-boot-localversion.bbclass: fix SRCREV_machine and AUTOREV use cases")
Signed-off-by: Piotr Wojtaszczyk <piotr.wojtaszczyk@timesys.com>
Fixes: d7e13f19fb ("fsl-u-boot-localversion.bbclass: fix SRCREV_machine and AUTOREV use cases")
Signed-off-by: Piotr Wojtaszczyk <piotr.wojtaszczyk@timesys.com>
Use UUU_BOOTLOADER_TAGGED variable instead of UUU_BOOTLOADER in the stat
function to make the code more specific and easy to read.
Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
Add UUU_BOOTLOADER_UNTAGGED flag to add the possibility to deploy a
imx-boot binary without the tagged footer
'UUUBURNXXOEUZX7+A-XY5601QQWWZ%sEN' at the end.
The addition of the footer 'UUUBURNXXOEUZX7+A-XY5601QQWWZ%sEN' at the end
causes issues when the binary is loaded into RAM memory, this footer may
cause issues where the binary size exceeds the typical USB package size
used by UUU (1021 bytes).
As example, if the footer is split across two distinct USB packages,
such as sending 'UUUBURNXXXOE' in the last packet and
'UZX7+A-XY5601QQWWZ%sEND' in the next one, it can lead to UUU halting
while waiting for a response in SDPS mode.
After sending 'UUUBURNXXXOE', iMX8MP's boot room starts SPL, not waiting
for the next packet ('UZX7+A-XY5601QQWWZ%sEND'), leading to UUU
breaking.
Therefore, deploy both binaries separately (-tagged and -untagged) to
allow users to choose the appropriate binary.
Signed-off-by: Hiago De Franco <hiago.franco@toradex.com>
This change makes no sense. MACHINE_SOCARCH must include the suffix
that makes the value SOC-specific. Otherwise, errors such as this occur:
```
ERROR: imx-dpu-g2d-2.1.12-r0 do_create_spdx_setscene: Recipe imx-dpu-g2d is trying to install files into a shared area when those files already exist. The files and the manifests listing them are:
tmp/deploy/spdx/armv8a/packages/libg2d-dev.spdx.json
(matched in manifest-armv8a-imx-pxp-g2d.create_spdx)
tmp/deploy/spdx/armv8a/packages/libg2d2.spdx.json
(matched in manifest-armv8a-imx-pxp-g2d.create_spdx)
```
This reverts commit 6579ce9b77.
The sstate manifest for populate_sysroot was not being named
properly for firmware-sentinel and imx-boot-firmware-files, raising the
following error:
The sstate manifest for task 'firmware-sentinel:populate_sysroot'
(multilib variant '') could not be found.
The pkgarchs considered were: microej_imx93, armv7ahf-neon-vfpv4-mx93,
armv7ahf-neon-mx93, (and so on...)
But none of these manifests exists:
...build/tmp-glibc/sstate-control/manifest-microej_imx93-imx-boot-firmware-files.populate_sysroot
...build/tmp-glibc/sstate-control/manifest-armv7ahf-neon-vfpv4-mx93-imx-boot-firmware-files.populate_sysroot
... and so on.
All the other packages were suffixed with TUNE_PKGARCH only, so I couldn't
see the reason why only some specific packages from meta-freescale were using
that.
Remove MACHINE_SOCARCH_SUFFIX so as the sstate manifest is compatible
with what's expected in populate_sysroot.
Signed-off-by: Joao Marcos Costa <joaomarcos.costa@bootlin.com>
Depending on how one uses the Yocto kernel classes the kernels hash
is defined in either "SRCREV_machine" or "SRCREV". If "SRCREV_machine"
is in use, "SRCREV" stays at its bitbake default "INVALID".
If the "SRCREV_machine" or "SRCREV" is set to "AUTOREV" that value is
replaced by "AUTOINC".
If using "SRCREV_machine" and/or "AUTOREV" do_kernel_localversion fails
| run.do_kernel_localversion:158 exit 128 from 'head=`git --git-dir=.../.git rev-parse --verify --short INVALID 2> /dev/null`'
Cope with both use cases.
Fixes: 41537394 ("classes: make localversion classes deterministic")
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
The localversion string built into the kernel and u-boot should be
deterministic. With OpenEmbedded it is common practice to apply patches
to the sources. The commit id of HEAD will differ each time the patching
step is rerun. With the previous implementation of the fsl-{kernel,u-
boot}-localversion classes this produced non-deterministic commit ids to
be used. This is undesireable, because the commit-id read from the
version string during runtime is not present in the sources. It also
caused problems when building out-of-tree kernel-modules if the kernel
itself was taken from sstate cache but the kernel-module needed to be
rebuild and retriggered the kernels do_patch task (see #961).
Rework to produce a deterministic string that will use the commit id
given as SRCREV and count the number of patches applied on top.
With e.g. commit id 11aabbcc and 5 patches this will result in a version
string
+g11aabbcc+p5
Fixes: https://github.com/Freescale/meta-freescale/issues/961
Signed-off-by: Daniel Wagenknecht <dwagenknecht@emlix.com>
Only the first UBOOT_CONFIG generate a imx-boot and flash.bin symlink.
Every UBOOT_CONFIG creates a flash.bin-${MACHINE}-${type} binary.
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
Rework imx-boot and use-imx-security-controller-firmware.bbclass with a
generic SOC revision design implemented in imx-base.inc. This does
replace the machine feature design using `soc-rev*`, but maintains
backwards compatibility by incorporating that design into the default
settings.
Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
CONFIG_LOCALVERSION is a string setting. It needs to go between quotes in
the .config file.
$ grep CONFIG_LOCALVERSION= .config
CONFIG_LOCALVERSION="-dey"
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@foundries.io>
Eventually, multiple `uuu` script may install same binaries. We need to
ensure we install them once, otherwise it'll fail as it might try to
override a existing binary.
This commit ensure all dependencies and binaries are mentioned once,
removing duplication.
Fixes: ae7af6f8 ("classes/image_populate_mfgtool: init")
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
The initramfs image doesn't use the U-Boot binaries so there is no
reason for a dependency on it.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
The class provides the infrastructure for MFGTOOL generation and is tied
to images. To generate the bundle, the task populate_mfgtool must be
called. For example:
,----[ Running populate_mfgtool for core-image-minimal image ]
| $: bitbake core-image-minimal -c populate_mfgtool
`----
The class behavior is controlled through the MFGTOOLCONFIG (analogous to
PACKAGECONFIG) variable. The MFGTOOLCONFIG variable itself specifies a
space-separated list of the script to enable. Following the script, you
can determine the behavior of each script by providing up to two
order-dependent arguments, which are separated by commas. You can omit
any argument you like but must retain the separating commas. The order
is important and specifies the following:
1. Extra dependencies that should be added to the do_populate_mfgtool
task, if the script is enabled.
2. Extra binaries that should be added to the bundle, if the script is
enabled.
For example:
,----[ Defining foo.uuu.in and bar.uuu script ]
| MFGTOOLCONFIG = "foo.uuu.in bar.uuu"
| MFGTOOLCONFIG[foo.uuu.in] = "dep-foo1:do_deploy dep-foo2:do_deploy,file-foo1"
| MFGTOOLCONFIG[bar.uuu] = "dep-bar1:do_deploy,file-bar1 file-bar2"
`----
The dep-foo1:do_deploy, dep-foo2:do_deploy, and dep-bar1:do_deploy are
added to do_populate_mfgtool dependencies. In addition, file-foo1,
file-bar1, and file-bar2 are copied to the bundle, only if the script is
enabled.
During the mfgtool bundle generation, the uuu.in files are processed and
some variables replaced. The variables are:
- MACHINE
- UBOOT_BINARY
- SPL_BINARY
- IMAGE_BASENAME
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
Moving the override from the <machine>.conf files to the common
imx-base.inc and setting the use of imx-boot-container unconditionally
on the used SoC makes the use of an extra override obsolete.
Simply set UBOOT_PROVIDES_BOOT_CONTAINER depending on the used SoC
is enough. Both the U-Boot recipe and the class implementing the logic
don't need the override but only look at the variable.
This also simplifies overriding the value set in imx-base.inc
in an individual <machine>.conf should that be needed.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
SECO/SC FW/HDMI FW and friends should not be restricted to imx-nxp-bsp.
If one wants to build machines for a mainline kernel / user space these
would be required to build the boot container too.
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
It add SECO_FIRMWARE_NAME for mx93-nxp-bsp.
It is based on 5.15.71_2.2.0 NXP BSP release.
Signed-off-by: Daiane Angolini <daiane.angolini@foundries.io>
- Currently only the DDR firmware files are copied
- i.MX 8MQ SoC also requires either HDMI or DP firmware
- Refactor the copy from deploydir to the U-Boot build folder to be
generic to all firmware files
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Currently, the class doesn't support multilib image/SDK generation for packages
built for MACHINE_SOCARCH with MULTILIB support and this commit fixes this.
To reproduce the error, add to local.conf:
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE:virtclass-multilib-lib32 = "armv7athf-neon-vfpv4"
IMAGE_INSTALL_append = "lib32-libusb1"
Build image with: 'bitbake core-image-minimal'
The build will fail during do_rootfs/do_populate_sdk on lib32-wayland-protocols package.
Make fsl-kernel-localversion devtool-compatible, avoiding to depend on
${WORKDIR}/defconfig to be present. Two approaches are taken:
- for recipes inheriting kernel-yocto, LINUX_VERSION_EXTENSION is set to
LOCALVERSION; in this way, the do_kernel_configme task will use it to
set CONFIG_LOCALVERSION once the .config file is generated;
- for recipes not inheriting kernel-yocto, CONFIG_LOCALVERSION is simply
appended to the .config file contained inside the build directory.
The do_kernel_localversion is being made executed after do_kernel_configme
rather than do_kernel_metadata; in this way, modifications are applied
after the config-by-fragments step has already been performed.
Signed-off-by: Francesco Valla <valla.francesco@gmail.com>
We shouldn't force `imx-boot` dependency for i.MX8 SoCs as many can use
U-Boot mainline and those use `imx-boot-container` to generate the
binary blob.
We moved the backward-compatibility note, about 'imx-boot' to the
'imx-boot-container' class.
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
