This is required to update firmware-imx which uses the new license, but
we leave the EULA unchanged since scarthgap is still using NXP BSP
LF6.6.52-2.2.0.
Signed-off-by: Ernest Van Hoecke <ernest.vanhoecke@toradex.com>
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>
(cherry picked from commit f79a6de90e)
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>
(cherry picked from commit ef8b4c41cf)
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>
(cherry picked from commit 3a26a0b27f)
Fixes: d7e13f19fb ("fsl-u-boot-localversion.bbclass: fix SRCREV_machine and AUTOREV use cases")
Signed-off-by: Piotr Wojtaszczyk <piotr.wojtaszczyk@timesys.com>
(cherry picked from commit 8c5fbbce4d)
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>
The fix to allow the user to override the IMAGE_FSTYPES setting for
mfgtool-initramfs-image [1] does break the default behavior by turning
the setting into a no-op:
```
# $IMAGE_FSTYPES [6 operations]
# set? /.../sources/meta-freescale/conf/machine/include/imx-base.inc:463
# "${SOC_DEFAULT_IMAGE_FSTYPES}"
# set /.../sources/poky/meta/conf/documentation.conf:214
# [doc] "Formats of root filesystem images that you want to have created."
# set? /.../sources/poky/meta/conf/bitbake.conf:832
# "tar.gz"
# set? /.../sources/meta-freescale/classes/mfgtool-initramfs-image.bbclass:16
# "cpio.zst.u-boot"
# override[mxs-generic-bsp]:set? /.../sources/meta-freescale/classes/mfgtool-initramfs-image.bbclass:17
# "cpio.gz.u-boot"
# pre-expansion value:
# "${SOC_DEFAULT_IMAGE_FSTYPES}"
IMAGE_FSTYPES="wic.bmap wic.gz"
```
The layer uses an extra variable SOC_DEFAULT_IMAGE_FSTYPES to override
IMAGE_FSTYPES [2], so use it here.
[1] 0a29050 classes: IMAGE_FSTYPES as weak variable in mfgtool-initramfs-image
[2] 541b8b8 imx-base.inc: Move IMAGE_FSTYPES override to a SoC variable
Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
Upstream TF-A and downstream TF-A fork uses different deployment
locations for results binaries, which leads to failures during image
build when switching between upstream and downstream versions.
Drop the custom TF-A deployment location, which is only specific to NXP
downstream deployment, allowing the TF-A binaries from upstream and
downstream to be picked up from the same location, namely - image
deployment folder.
Signed-off-by: Andrey Zhizhikin <andrey.z@gmail.com>
TF-A package can have several providers: upstream TF-A implementation,
or NXP downstream fork. Functionality to switch this provider, and to
select which package shall be included into the target image is missing
in the layer however, defaulting the usage of the layer to NXP
downstream fork only.
Introduce the Default TF-A Provider define, make it overridable, and
default it to NXP downstream fork. This allows user to re-define the
package name later shall they choose to integrate upstream TF-A package
instead.
Current upstream TF-A version (v2.7) does not support HAB feature of
i.MX8M family, see [1]. If the upstream TF-A version is chosen, then
HAB will not be available for all SoCs that are opting-in. This is
indicated in the comment where default TF-A provider variable is set.
This might change with future TF-A release, so later it can be revised
and statement in include file can be potentially removed.
Signed-off-by: Andrey Zhizhikin <andrey.z@gmail.com>
Link: [1]: https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.org/message/5UYYI4CNLQ5OWWHU466JBK6I5QIQ2VRS/
