Do not evaluate TRUSTFENCE_SIGN_MODE on conditions where the sign mode
is not relevant:
1) U-Boot binary file should be signed directly after building it when simple
U-Boot images are used, but it should not be signed when imx-boot bundled
images are used.
For those, the signing process is performed later over the whole imx-boot
bundled binary file on a different recipe.
We use BOOTLOADER_IMAGE_RECIPE variable to evaluate this distinction.
BOOTLOADER_IMAGE_RECIPE is set to "u-boot" by default and is set to "imx-boot"
on ccimx8x and ccimx8mn machine configuration files.
2) For signing imx-boot images we should treat differently those images that
include the RAM configuration in their name and those that don't, as we do
for the rest of the tasks in the same recipe. We can ignore the sign mode
method in this case.
https://jira.digi.com/browse/DEL-7023
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
There is no need to generate PV-PR revision of this file
since it's the same for any version.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
The recipe needs to create a copy of the sign.sh script to be used by
other recipes, but the file is the same whether you use it for HAB or AHAB
images. This is determined through the use of an exported variable with
the mode. There is no need to have the script duplicated.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
This binary is required for signing the U-Boot scripts generated
by the U-Boot recipe but it wasn't available because this recipe
was not installing it anywhere.
At the same time, remove the installation from imx-boot, to avoid a
conflict between the two (imx-mkimage is a dependency from imx-boot
anyway).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
* prefix TRUSTFENCE_ to variable SIGN_MODE for DEY
* prefix CONFIG_ to variable SIGN_MODE for script
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Although the recipe was updated with the modifications in meta-fsl-bsp-release,
the revision was still pointing to the sumo-4.14.98-2.2.0 version of
imx-mkimage, which is incompatible with our recently updated patch.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Update SRCREV and SRCBRANCH, change the names of the m4 demos that are
installed into imx-boot, change the name of the SECO firmware (ahab container)
and update our patch so it applies over the newest revision of imx-mkimage.
For the time being, use the B0 SECO firmware for all i.MX8QXP platforms and add
the changes needed for C0 support in comments.
https://jira.digi.com/browse/DEL-6932
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This imx-seco recipe manages now the NXP IMX SECO firmware, it was removed
from the firmware-imx recipe.
https://jira.digi.com/browse/DEL-6823
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
These images were broken in many ways, including ethernet not working and Linux
not booting. For now, revert back to the build command that was used in
DEY-2.6-r1.
https://jira.digi.com/browse/DEL-6677
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
The existing loops were iterating through all RAM_CONFIGS, but
they must only iterate over those that match the RAM size on the
platform's UBOOT_CONFIG.
This commit adds a Python class 'boot-artifacts' to get the list of matching
combinations of RAM_CONFIGS and UBOOT_CONFIG so that the iteration
is easier to do than nesting loops inside one another.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6641
The recipe was creating a variable with the value of another one from
the main recipe, just to refer to the bootable artifact prefix.
We can now use instead the new UBOOT_PREFIX variable.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Similar to the way the u-boot recipe does, create a symlink to the default
bootable artifact.
Since they are overwritten on every loop, this requires that the default
RAM configuration is set the last on the list of RAM_CONFIGS (same
convention than the one used on UBOOT_CONFIGS).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6641
With the rework to support variants, the machine name (actually the
UBOOT_CONFIG) was removed from the filename. Re-add it using
${MACHINE_NAME} which is more appropriate than the ${UBOOT_CONFIG} which
contains the RAM size (now present in ${ramc}).
While on it, remove one of the two symlinks on DEPLOYDIR. Only one makes
sense.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6641
There are several U-Boot binaries, depending on RAM size, at the moment:
- u-boot.bin-ccimx8x_sbc_pro512MB
- u-boot.bin-ccimx8x_sbc_pro1GB
- u-boot.bin-ccimx8x_sbc_pro2GB
and several SCFW files, depending on frequency, size, bus width, at the
moment:
- scfw_tcm.bin-1.2GHz_512B_16bit
- scfw_tcm.bin-1.2GHz_1GB_16bit
- scfw_tcm.bin-1.2GHz_1GB_32bit
- scfw_tcm.bin-1.2GHz_2GB_32bit
From these, we need to combine those that match the RAM size, to produce
bootable images for the different variants.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6641
These dependencies went missing when we deleted our first .bb file and replaced
it with a .bbappend. Without these dependencies, the build can sometimes fail.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Most of the support has been added to the meta-freescale layer, so
substitute our recipe for a .bbappend and redefine the tasks to build
U-Boot images for our two variants (1GB and 2GB).
https://jira.digi.com/browse/DUB-881
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
Gonzalo Ruiz
Hector Palacios
Mike Engel
Gabriel Valcazar
Arturo Buzarra