When the Bootloader is an 'imx-boot', select the correct imx-boot
signed image to compose the sdcard artifact.
https://jira.digi.com/browse/DEL-7024
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
The signing script is used for signing multiple artifacts, not just the
kernel, so rename it for a broader use.
https://jira.digi.com/browse/DEL-7047
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
imx-mkimage is a host recipe to provide the mkimage_imx8 binaries, required
for the trustfence support with platform based on AHAB (ccimx8x). Since
these binaries are required to the sign process we need to export it in the
SDK to allow the standalone sign mode, and with that we can simplify the
mechanism to share these binaries with another recipes (u-boot, linux).
Also the do_deploy() from imx-mkimage recipe was removed to avoid overriding
the implementation from the native class and allow populating the mkimage
binaries.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
The scripts need to know the SOC's revision to be able to select the correct
imx-boot image. Modify the boot-artifacts bbclass so the renamed imx-boot files
are included in the installation .zip.
Also, bypass the SECO fw check in the uSD script so it can install future
versions that aren't recognized by U-Boot's SECO fw checking logic. The UUU
script doesn't require this bypass, since it doesn't use the Digi update
command to flash the bootloader.
https://jira.digi.com/browse/DEL-7069
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@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>
The bootable artifacts that must go inside the installer ZIP image, are defined
in the variable BOOTABLE_ARTIFACTS. For platforms without RAM_CONFIGS, these
artifacts are obtained from the UBOOT_CONFIG variable.
This commit fixes the final artifact name added to the BOOTABLE_ARTIFACTS that
for some platform is not strictly the same that the UBOOT_CONFIG name.
For example for the U-Boot configuration "ccimx8mn_dvk", corresponds the
bootable artifact "ccimx8mn-dvk"
https://jira.digi.com/browse/DEL-6974
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This commit fixes the copy of the initramfs final image with the extension
*.tf when Trustfence is disabled. This was introduced by commit
5beec04b ("trustfence: Add Trustfence support for CCMX8X")
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
Commit 5beec04b ("trustfence: Add Trustfence support for CCMX8X") introduces
a dependency when the imx-mkimage recipe and the SIGN_MODE is equal to AHAB.
However this dependency should be added only when the TRUSTFENCE_SIGN is equal
to 1 and when the SIGN_MODE is equal to AHAB, not only when the SIGN_MODE is
equal to AHAB. This commit introduces this double check.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
The artifacts that must go inside the installer ZIP image are not anymore
the ones in UBOOT_CONFIG. For CC8X, the artifacts are combinations of
UBOOT_CONFIG and RAM_CONFIGS.
This commit adds a function 'get_bootable_artifacts()' to boot-artifacts class
to generate a new variable BOOTABLE_ARTIFACTS with the list of bootable
artifacts DEY produces.
The installer recipe can then simply iterate on that list, rather than
needing to calculate it by itself.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6641
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
A variable called IMAGE_BOOTLOADER was being used without distinction for
referring to two different things:
- the recipe that builds the bootable artifacts
- the prefix of those artifacts
The value of this is "u-boot" for most platforms, but "imx-boot" for the
CC8X based platforms.
The name of the variable is misleading, so this commit splits it into two:
- BOOTLOADER_IMAGE_RECIPE, to refer to the recipe
- UBOOT_PREFIX, to refer to the prefix of the bootable artifact
With the separation, the variable UBOOT_SYMLINK becomes a generic formed
one, so it is moved to digi-defaults.inc.
While on it, fix the image_types_digi.bbclass which was not making use of
the original variable to establish all the dependencies.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Update NXP's .bbclass files with the ones 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>
Device tree names don't use KERNEL_IMAGETYPE as a prefix anymore,
since in this version, there are different variable names to generate
device tree files.
https://jira.digi.com/browse/DEL-6443
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This allows for other platforms to use different bootloaders (like imx-boot),
while leaving the default behaviour intact.
https://jira.digi.com/browse/DEL-6159
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
The boot.(ext) image class was looping over ${KERNEL_DEVICETREE}
variable which is normally the list of device tree filenames.
The loop however does not take into account the possibility that
this list of files are within a sub-folder, as it happens with
ARM64 device tree files in the kernel tree.
Use 'basename' to remove any potential subfolder on the iterations.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-6060
These are required for the imx-m4-demos. The classes exist in
meta-fsl-bsp-release but will eventually be moved to meta-freescale
so, presumably, they could be removed in the future.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
As per Yocto 2.4, do_image_<type>[depends] has replaced IMAGE_DEPENDS_<type>.
The previous trick to propagate *boot* dependencies from *boot.[vfat|ubifs]*
is no longer needed.
https://jira.digi.com/browse/DEL-5518
Signed-off-by: Jose Diaz de Grenu <Jose.DiazdeGrenu@digi.com>
- Instead of using a different boot script when booting from linux
and from recovery, merge them into one script that checks the
boot source.
https://jira.digi.com/browse/DEL-3836
Signed-off-by: David Escalona <david.escalona@digi.com>
* Transfer dependences from base types 'boot' and 'recovery' to the
actual image types 'boot.vfat', 'boot.ubifs', 'recovery.vfat' and
'recovery.ubifs' using IMAGE_TYPEDEP variable.
* Now the images are created in a per image recipe deploy directory
(IMGDEPLOYDIR), so use that instead of the final DEPLOY_DIR_IMAGE.
* Remove manual creation of symbolic links and let Poky create them. For
this, we need to remove the default 'rootfs' image suffix using the
imgsuffix variable flag for the corresponding do_image_* functions.
https://jira.digi.com/browse/DEL-3451
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
As of Yocto 2.2, the way to generate images has changed. Now the image
fstypes have a basetype and then conversion types that define functions
that apply sequentially.
So implement the TrustFence initramfs sign process as a conversion type
of the base initramfs type (cpio).
This fixes following build issue:
mv: cannot stat ‘dey-image-recovery-initramfs-ccimx6ulstarter-20170220152625.rootfs.cpio.gz.u-boot’
https://jira.digi.com/browse/DEL-3451
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
- Added the new image type 'recovery.vfat' to the DEY images
generation process. This new image is a clone of the 'boot.vfat'
but including the recovery ramdisk and the recovery boot script.
- Added the new image type 'recovery.ubifs' to the DEY images
generation process. This new image is similar to the 'boot.ubifs'
but including the recovery ramdisk and the recovery boot script.
Signed-off-by: David Escalona <david.escalona@digi.com>
It is desirable to keep the name of the initramfs images the same regardless of
the sign and encryption configuration.
https://jira.digi.com/browse/DEL-3141
Signed-off-by: Diaz de Grenu, Jose <Jose.DiazdeGrenu@digi.com>
Also change the image type of dey-image-trustfence-initramfs.
https://jira.digi.com/browse/DUB-615
Signed-off-by: Diaz de Grenu, Jose <Jose.DiazdeGrenu@digi.com>
When TRUSTFENCE_SIGN is enabled, the u-boot binary for the SDCARD image
needs to be the "signed" one.
https://jira.digi.com/browse/DEL-2876
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
To build the CC6UL boot image, the u-boot and linux images need to be
already deployed. Also the native mtd-utils package needs to be
available in the sysroot.
Make all this dependences explicit for deterministic reproducibility.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
When Trustfence is enabled, this adds a dependence on the TF initramfs,
so it's built and added to the boot image.
It also modifies the u-boot boot script on the fly, to boot correctly
using the Trustfence initramfs.
https://jira.digi.com/browse/DEL-2278
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
This creates a UBIFS file with the kernel, device tree files, and U-Boot
bootscripts generated by Digi Embedded Yocto.
The resulting image can be then programmed into the boot (linux) partition.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-2697
ARCH is not a documented variable in yocto, use the documented
TARGET_ARCH instead.
https://jira.digi.com/browse/DEL-2032
Signed-off-by: Jose Diaz de Grenu de Pedro <Jose.DiazdeGrenudePedro@digi.com>
This is needed in the context of CC6 variants 0x7 and 0x9 (EMMC-less).
Changes:
* Do not use 'meta-fsl-arm' image generation class: removed include and
override SDCARD generation function
* Use same VFAT boot image for EMMC and SD card. The u-boot bootscript
has been adapted to be able to boot Linux from both SD and EMMC.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
(cherry picked from commit 8b8456b8fd90facd92dfc87632effa582ca60475)
This will allow in following commit to use the same VFAT boot image for
EMMC and SD. Until now we were creating different boot images for EMMC
and SD card images.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
(cherry picked from commit 13e9ec7608d42430c2a01a728d030752a71f7948)
Notes:
* This version of u-boot does not support comments in scripts
* Enabled EXT4 in kernel config (for the SDCARD rootfs)
https://jira.digi.com/browse/DEL-197
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
We inherited from DEL the requirement to build more than one flash image
for the same rootfs contents depending on the EBS of the flash chip.
Yocto does not have support to generate more than one flash image so we
had to create functions in the image_types_digi bbclass to provide this
feature.
This commit removes that functionality and uses the standard yocto
support to generate ubifs and jffs2 flash images. The way to customize
the flash parameters is via EXTRA_IMAGECMD_jffs2 and MKUBIFS_ARGS
variables. In our case those variables are already set depending on the
different hardware variants.
https://jira.digi.com/browse/DEL-232
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Add possibility for other layers to add additional features for UBIFS creation,
e.g. "-R <rp_size>" for super-user reserved pool.
Signed-off-by: Robert Hodaszi <robert.hodaszi@digi.com>
Gonzalo Ruiz
Arturo Buzarra
Gabriel Valcazar
Mike Engel
Hector Palacios
Jose Diaz de Grenu
Javier Viguera
David Escalona
Alex Gonzalez
Jose Diaz de Grenu de Pedro
Robert Hodaszi