Add Trustfence support for signing imx-boot images:
- Install a different U-Boot signing script for images with U-Boot SPL.
- Store mkimage log for later use in the signing script
- make 'print_hab_log' and store its log for later use in the signing script
https://jira.digi.com/browse/DEL-7023
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
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
This is the version used in meta-fsl-bsp-release branch sumo-4.14.98-2.0.0_ga.
https://jira.digi.com/browse/DEL-6603
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
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>
Every task in this recipe is already supported in the same way in the
meta-freescale layer, so just keep the .bbappend file to select SRCBRANCH and
SRCREV.
The DDR patch can be removed since that source code is now included into the
SCFW project.
https://jira.digi.com/browse/DUB-881
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
This is a new intermediate file that will be reused in every iteration if it's
not removed, causing all imx-boot images to have the same U-Boot binary.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This reflects the fact that the firmware is customized for Digi platforms. The
versioning still follows the one used by NXP in their recipe.
https://jira.digi.com/browse/DEL-6158
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
These patches were originally introduced in the recipe because the DCD files
were needed by mkimage to create the final imx-boot binaries. Now they are
in the SCFW source code instead.
https://jira.digi.com/browse/DEL-6158
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
The "sha384sum" tool included in the coreutils package is needed by mkimage
when creating the imx-boot image.
https://jira.digi.com/browse/DEL-6158
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Otherwise, the default imx-boot images will include the Cortex M4 demo.
https://jira.digi.com/browse/DEL-6158
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
These adaptations include changing the mkimage targets and removing any
handling of the DCD files, since they are now included in the SCFW. Note that
these changes break support for step A0 of the silicon.
The md5sum of the imx-sc-firmware tarball will be updated once the step B0 CPUs
are ready.
https://jira.digi.com/browse/DEL-6158
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
When the imx-boot recipe is added in EXTRA_IMAGEDEPENDS the
license file is being referenced in image postcommand
write_deploy_manifest, but the licenses of the dependant
packages are missing. This leads to the license files of the
recipes to be missing when write_deploy_manifest runs,
causing build errors to appear.
https://jira.digi.com/browse/DEL-6251
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Generalize DCD patch to be agnostic of the platform and modify the imx-boot
recipe to depend only on the memory configuration instead of the platform name.
https://jira.digi.com/browse/DEL-6205
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This way, customers are less likely to flash the plain u-boot by accident
instead of imx-boot. Also, have the imx-boot recipe look for the u-boot files
in the imx-boot-tools directory.
https://jira.digi.com/browse/DEL-6185
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Since this binary (u-boot-atf.bin) wasn't being deleted, the mkimage makefile
was using the one from the previous iteration, causing the 1GB imx-boot to
contain the 2GB U-Boot.
https://jira.digi.com/browse/DEL-6094
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Also, move all of the recipe's patches from the .bbappend file to the .bb file,
because the .bb file's modifications depend greatly on said patches.
https://jira.digi.com/browse/DEL-6085
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This package is the combination of U-Boot and the other i.MX firmware binaries.
In our case, these binaries are: the SCFW, the ATF and the DCD.
The recipe has been ported from the meta-fsl-bsp-release repo, with a couple of
important changes:
* Support for our platform (based on the mx8qxpa0, which uses A0-specific
parameters for mkimage and appends the DCD explicitly)
* Support for multiple UBOOT_CONFIG values (NXP only uses one UBOOT_CONFIG
string per platform; so the compile, install and deploy functions had to
be tweaked to build both 1GB and 2GB variants for our platform).
Our DCD patch used in imx-mkimage is also used, since both packages share the
same repo and imx-boot is the one responsible for generating the final,
bootable image.
https://jira.digi.com/browse/DEL-6085
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
In order for Yocto to append all the necessary firmware binaries to the U-Boot
image, this recipe needs to be up to date.
Also, remove the older hardcoded SRCREV in our .bbappend file. The file that
gets patched hasn't been modified since beta1, so our patch apllies cleanly to
beta2.
https://jira.digi.com/browse/DEL-6085
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This was done using Excel aid sheet:
MX8QXP_LPDDR4_register_programming_aid_ValidationBoard_1.2GHz_v7_DBI_enabled.xlsx
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
This recipe builds the Device Configuration Data (DCD) that
configures DRAM controller before the bootloader.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Arturo Buzarra
Gonzalo Ruiz
Hector Palacios
Mike Engel
Gabriel Valcazar