Current pattern does not match the SRKs generated for the ccimx93. The
ccimx93 does not support subordinated SGK certs, so the name of the SRKs
do not contain the "_ca_" pattern. So relax the expression used in the
trustfence bbclass to match the SRKs generated for both platforms.
# For the ccimx93
$ ls -1 crts/SRK1*crt.pem
crts/SRK1_sha512_secp521r1_v3_usr_crt.pem
# For the ccimx8x
$ ls -1 crts/SRK1*crt.pem
crts/SRK1_sha512_secp521r1_v3_ca_crt.pem
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Some platforms do not support signing external artifacts (kernel, dtb,
etc.) yet, so we need to decouple the signing of the bootloader from the
signing of the external artifacts.
This commit generalizes the code, so instead of having platform exceptions
scattered along the recipes, we create a new variable used conditionally
to sign or not the external artifacts.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Bitbake was always copying the public key 1 to the rootfs, no matter what the value specified in
the 'TRUSTFENCE_KEY_INDEX' variable was. This commit fixes the issue by enclosing the variable
between curly braces so that bitbake is able to expand it and calculate the correct key index.
Signed-off-by: David Escalona <david.escalona@digi.com>
PKI tree generation for the STM32MP15 cpu provides the undesired file
"publicKeysHashHashes.bin", which is only required by STM32MP13. This commit
generates the PKI tree according to the KeyGen tool documentation to avoid
generate this extra file and avoid confusing the end user.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
In the context of the class, we must use ${IMAGE_ROOTFS} instead of ${D}.
Change the calling of the function to POSTPROCESS (after the rootfs has
been created) instead of POSTINSTALL (after the packages have been
installed).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
When TrustFence is enabled, a PKI tree is generated.
In the case of NXP platforms, the PKI contains public certificates
from which the public key needs to be extracted using an openssl
command.
In the case of STM platforms, the PKI contains directly the
public key.
In all cases, we need the public key to be installed in the
rootfs /etc/ssl/certs/ folder, so that it can be used by
swupdate to authenticate signed SWU packages.
Up to now, this was being done on the dualboot recipe, but the
installation of the public key should really be only dependant
on the fact of TF being enabled.
This commit:
- Removes the generation of the public key from dualboot.bb.
- Generates a patch to extract the public key from the certificate
as part of the PKI tree generation (on NXP platforms).
- Installs the public key during a post install function after
the final rootfs has been created.
- For NXP platforms, extracts the public key using openssl if
it does not exist (for backwards compatibility).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Implement a new mechanism to allow users to create update packages based on differences for read-only
systems. The update mechanism requires full knowledge of the current software running on the device in order
to compute a sensitive patch. For this reason, only systems without user modifications in the rootfs/boot
partitions are eligible for this kind of updates. At the moment, only the 'rootfs' partition supports the
read-only squashfs file system type, so it is the only partition supporting incremental updates. The 'boot'
partition will still be updated but as a full image.
This new feature is done making use of the SWUpdate 'rdiff' handler, which applies binary deltas with the
functionallity provided by the rsync library. During the update process, the contents of the active 'rootfs'
partition are read as the base and written to the inactive 'rootfs' partition applying the delta binary patch
on-the-fly. To ensure the delta file is applied using the correct base, the firmware update process verifies
the contents of the 'rootfs' base partition before applying the update.
The binary delta file is automatically generated by the DEY build system using the resulting 'rootfs' squashfs
image as target and the user specified file as source. The file is then packaged with the rest of components in
the SWU update image. Users must specify the base source file in their project configuration file using the
new variable 'SWUPDATE_RDIFF_ROOTFS_SOURCE_FILE'. Also, 'read-only-rootfs' image feature should be set in the
project to generate this new SWU update package.
Since a base and a target 'rootfs' partition is required during the update, only 'dualboot' systems can benefit
from this new feature.
Note: If variable 'SWUPDATE_RDIFF_ROOTFS_SOURCE_FILE' is configured in the project but any of 'SWUPDATE_FILES_LIST'
or 'SWUPDATE_FILES_TARGZ_FILE' variables is also set, the build system will prioritize a SWU update package
based on files instead of a differences package.
https://onedigi.atlassian.net/browse/DEL-8624
Signed-off-by: David Escalona <david.escalona@digi.com>
We expect new types of SWU update packages to be created in the future. To avoid splitting
all the code in different classes based on the update type, create the generic class
'dey-swupdate' to hold all the custom code and the 'dey-swupdate-common' class to hold all
the required variables. This basically renames the old 'swupdate-files' and 'swupdate-files-common'
classes.
While on it, reorganize the 'swupdate-images' recipe to move variable declarations and
functionallity to the correct place:
- Move all variable declarations to 'swupdate-digi-common' class and organize them in
functional groups.
- Improve the way files are included in the 'SWUPDATE_IMAGES' by using the update type
variables.
- Move the update script copy to the 'do_swuimage' prepend function. Until now, the copy
process was executed in the 'fill_description' method, which should only touch the
'sw-description' file.
- Rename some variables to use 'SWUPDATE' prefix.
- Minor cosmetic changes.
https://onedigi.atlassian.net/browse/DEL-8624
Signed-off-by: David Escalona <david.escalona@digi.com>
Create a new script for the generation of PKI tree for STM platforms
and leave the trustfence-sign-artifact script exclusively for signing.
The new gen-pki script only requires the platform as an argument and the
path to where to save the tree (if it doesn't exist) in
CONFIG_SIGN_KEYS_PATH.
This commit also reverts commit 13c136dbc5 by getting rid of the
trustfence-genpki-native.bb recipe and moving back the PKI generation
functions into trustfence.bbclass. This recipe didn't quite guarantee
that the PKI was generated on time for the recipes that required the
keys to exist, anyway.
Instead, the PKI generation function must be called right after
do_compile() of recipe tf-a-stm32mp to be ready for do_deploy() where
the key is used.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Implement a new mechanism to allow users to create update packages based on files and folders to modify
the active system.
This is done through the new class 'swupdate-files', which creates a tar.gz update file in the image
distribution output directory containing all the files and directories to create/update. The 'tar.gz'
file is used later by the 'swu-images' recipe to generate the final SWUpdate package. The SWU package
installation process extracts the tar.gz file in the root folder ("/") of the active system.
Users can specify the list of files and directories to include in the update package using the
'SWUPDATE_FILES_LIST' variable. These files will be directly copied from the generated system rootfs and
placed in the tar.gz archive. Additionally, users can provide their custom 'tar.gz' file to use in the update
by specifying its location in the 'SWUPDATE_FILES_TARGZ_FILE' variable. In any case, all the paths to include
in the update package must be relative to "/", as it is the base directory where tar.gz file contents are
extracted.
The update process for dual boot systems sets a new u-boot flag so that active bank is not swapped once
installation is complete and system reboots.
The SWU update mechanism based on files provides a custom update script which takes care of preparing the
system for the installation process. Just like in the SWU updates based on images, users can customize this
script or override it with the 'SWUPDATE_SCRIPT' variable, specifying the location of the new script to use.
If both the 'SWUPDATE_FILES_LIST' and 'SWUPDATE_FILES_TARGZ_FILE' variables are empty, a standard images
SWUpdate package will be generated instead.
Signed-off-by: David Escalona <david.escalona@digi.com>
We used to use BAD_RECOMMENDATIONS to remove this package in ccimx6 builds,
we enable the imx-gpu-viv driver as built-in in our kernel, but this method
isn't working anymore. Instead, undo the specific RRECOMMENDS that pulls the
module in.
Apply the change for the aarch32 version of the package only, since this change
is only needed for the ccimx6 platforms.
https://onedigi.atlassian.net/browse/DEL-8540
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This commits changes the CONFIG_CONSOLE_ENABLE_GPIO_NAME to be a string
and not an integer.
https://onedigi.atlassian.net/browse/DEL-8520
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
Sometimes, it may be desired that the DEY project does not sign the
artifacts, for example, if they are going to be externally signed on a
secure server. In this case, the user sets TRUSTFENCE_SIGN="0".
On STM platforms, all the variables were being set if TRUSTFENCE_SIGN="1"
and authentication support is not enabled on TF_A otherwise.
Set TF_A_SIGN_ENABLE (which adds authentication support to TF_A) always
for STM platforms (as long as the project inherits the trustfence class)
and set FIP_SIGN_ENABLE="0" if its sibling TRUSTFENCE_SIGN="0", so that
DEY doesn't sign the FIP image either.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
For the moment, do not sign aditional artifacts, such as the ramdisk,
the kernel or the boot scripts for STM platforms.
In the specific case of the ramdisk, simply copy it over with the
expected filename extension.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Several recipes depend on the PKI creation.
Create a small recipe to just run this function which
is moved from the trustfence.bbclass.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Set TRUSTFENCE_DEK_PATH to "0" for CCMP1 (not using dek.bin), as if this
was disabled.
Set temporarily TRUSTFENCE_ENCRYPT_ENVIRONMENT to "0" for CCMP1 until
environment encryption is fully supported.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
The stand-alone signing script 'trustfence-sign-artifact.sh' checks
if a valid PKI tree exists (by checking the existance of four SRK
files) and if they don't, it calls trustfence-gen-pki.sh (which is
a wrapper over different generators (for HAB or AHAB) to create one.
Recipes such as 'dualboot' or 'recovery-initramfs' may need to call
openssl functions over the PKI tree. These recipes do not currently
generate the PKI tree; they expect it to be already in place.
This might not be the case if the trustfence-sign-artifact.sh script
has not been called yet.
Originally, a fake dependency on virtual/kernel recipe was made to
force it, but it doesn't quite work since the calling only happens
on deploy() while regular DEPENDS doesn't wait for this task.
If the PKI does not exist, a recipe that requires the PKI tree will
fail.
The solution is to create a function on the trustfence.bbclass that
allows any recipe to check for the existance of a PKI tree and
generate it if it doesn't exist. This is repeated inside the
trustfence-sign-artifact.sh, but it needs to be in both places
because this script must work stand-alone.
The generation of the PKI tree takes some seconds so this commit
adds a lock dir to prevent race conditions when called from
different recipes.
It also removes the fake dependency on virtual/kernel and adds a
dependency on trustfence-cst-native (which is the recipe that
provides the PKI generation tool).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://onedigi.atlassian.net/browse/DEL-8430
(cherry picked from commit 6a8bf7afff)
The stand-alone signing script 'trustfence-sign-artifact.sh' checks
if a valid PKI tree exists (by checking the existance of four SRK
files) and if they don't, it calls trustfence-gen-pki.sh (which is
a wrapper over different generators (for HAB or AHAB) to create one.
Recipes such as 'dualboot' or 'recovery-initramfs' may need to call
openssl functions over the PKI tree. These recipes do not currently
generate the PKI tree; they expect it to be already in place.
This might not be the case if the trustfence-sign-artifact.sh script
has not been called yet.
Originally, a fake dependency on virtual/kernel recipe was made to
force it, but it doesn't quite work since the calling only happens
on deploy() while regular DEPENDS doesn't wait for this task.
If the PKI does not exist, a recipe that requires the PKI tree will
fail.
The solution is to create a function on the trustfence.bbclass that
allows any recipe to check for the existance of a PKI tree and
generate it if it doesn't exist. This is repeated inside the
trustfence-sign-artifact.sh, but it needs to be in both places
because this script must work stand-alone.
The generation of the PKI tree takes some seconds so this commit
adds a lock dir to prevent race conditions when called from
different recipes.
It also removes the fake dependency on virtual/kernel and adds a
dependency on trustfence-cst-native (which is the recipe that
provides the PKI generation tool).
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://onedigi.atlassian.net/browse/DEL-8430
True is the default since long time ago, and thus not necessary. This
follows similar changes done in other layers.
Command used:
sed -e 's|\(d\.getVar \?\)( \?\([^,()]*\), \?True)|\1(\2)|g' -i $(git grep -E 'getVar ?\( ?([^,()]*), ?True\)' | cut -d':' -f1 | sort -u)
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Remove the 'qt5-layer' hardcoded dependence for 'digi-dey' and
dynamically get whether QT5 is being used in the project. This is done
with a new class _qt-version.bbclass_ that is able to get that
information from the project.
https://onedigi.atlassian.net/browse/DEL-8347
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
The class 'boot-artifacts.bbclass' was created to generate a
list of the bootable artifacts that must be copied from the
deploy dir to the installer ZIP file, so that the installer
has all the possible bootloader files to update any variant
of the hardware.
The class was somewhat over-engineered to produce the list,
specially for the cc8x, with the variants of SoC revision,
RAM size and width. With the arrival of ST family, it got
more complex, as the artifacts don't even come from U-Boot
recipe.
To remove complexity, this commit removes the bbclass and
moves the list to the platform config file.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Instead of overriding the whole do_compile function, just to reconfigure
u-boot for Trustfence, create a do_configure pre-function that takes care
of that. This allows the removal of duplicated code.
Also, disable the generation of u-boot environment artifacts. We are
not using them and so many u-boot artifacts in the deploy directory
are confusing.
Finally, adjust the names of the TF u-boot artifacts in the do_deploy
append function.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
The ccmp1 build generates ubifs images for the NAND on the device and vfat and
ext4 images for the SD card. This commit reuses the already implemented
mechanism to match only ubifs images for the ccmp1 platforms.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
The new DVKs of the cc8mn, cc8mm and ccmp1 have a new ftdi
usb to serial chip that is recognized as a thermal device by default.
With the install_usb_driver.sh script this driver is replaced
to a USB to serial driver.
This script is included for the needed platforms in the zip
installer provided in the getting started.
https://onedigi.atlassian.net/browse/DEL-8126
Signed-off-by: Francisco Gil <francisco.gilmartinez@digi.com>
- create dualboot.bbclass that
- sets DUALBOOT_ENABLED variable
- defines partition names and function for changing the sw-description
for swupdate
- move files from layer into meta-digi
https://onedigi.atlassian.net/browse/DEL-7962
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Signed-off-by: Francisco Gil <francisco.gilmartinez@digi.com>
It's just a waste of space as we already have the kernel image in the
'linux' partition and that gets mounted under /mnt/linux.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Signed image support in U-Boot has been split into two separate configurations:
one that adds artifact authentication support and another that signs the U-Boot
binary at the end of the build. Reflect this change in meta-digi.
https://onedigi.atlassian.net/browse/DEL-7862
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This package was originally being added via RDEPENDS, and its removal was
missing when porting the newer file from NXP's meta-imx. Re-incorporate the
removal to avoid including the package in our images, but do so by adding it
to our images' BAD_RECOMMENDATIONS.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
SQUASHFS read-only rootfs cannot be unencrypted on-the-fly
so skip encryption if read-only-rootfs is active.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
When TrustFence and a read-only rootfs are enabled, U-Boot must
authenticate the SQUASHFS root file system. Add config switch to force
U-Boot to authenticate this image.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Since these images are highly compressable, this greatly reduces the amount of
space taken up by build artifacts.
Modify the code used to generate the .sdcard and .installer.zip files so that
they contain the decompressed .ext4 image.
https://onedigi.atlassian.net/browse/DEL-7582
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This initramfs only makes sense in platforms with an eMMC as the internal
storage, due to how the partition encryption support is implemented. In
plaatforms that use NAND instead, ths initramfs offers no functionality and
increases the recovery image size, so remove it.
https://onedigi.atlassian.net/browse/DEL-7534
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Previously, TRUSTFENCE_INITRAMFS_IMAGE was the only variable used to configure
rootfs encryption. Now that any partition can be encrypted and the rootfs
encryption still needs to be handled differently, use two variables instead.
* TRUSTFENCE_ENCRYPT_PARTITIONS to control partition encryption in general
* TRUSTFENCE_ENCRYPT_ROOTFS to control rootfs encryption
As with most trustfence functionality, enable both by default. Leave
TRUSTFENCE_INITRAMFS_IMAGE as an internal variable only.
https://onedigi.atlassian.net/browse/DEL-7174
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
In order to revoke SRKs in platforms with AHAB we need to set a mask
during the signing/encryption process.
Create new TRUSTFENCE_SRK_REVOKE_MASK variable to export the
SRK_REVOKE_MASK variable required by the imx-boot signing script.
The revoke mask is not necessary for signing/encryption of other artifacts,
so set it by default to 0x0.
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
Create scripts to install DEY firmware using a USB stick.
https://jira.digi.com/browse/DEL-6802
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Includes:
xserver-xorg: Upgrade to 1.20.8 version [YOCIMX-4697]
Backport the recipes from poky master as the xserver is already upgraded to 1.20.8.
Signed-off-by: Neena Busireddy <neenareddy.busireddy@nxp.com>
xserver-xorg: Remove comment that is no longer valid
Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
xserver-xorg: Fix patch fuzz
Signed-off-by: Tom Hochstein <tom.hochstein@nxp.com>
Signed-off-by: Hector Bujanda <Hector.Bujanda@digi.com>
Added FILESEXTRAPATHS_prepend to reuse some recipes from poky layer.
Patches refreshed with devtool finish --force-patch-refresh
Signed-off-by: Hector Bujanda <Hector.Bujanda@digi.com>
This commit replaces the hardcoded text from the readme file by the environment
variables adding from this way the release version to the file content.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Commit 3418d1326c ("populate_sdk_base: provide options to set sdk type")
in poky layer introduces a new mechanism to create different archive types
for the sdk, and the function tar_sdk was renamed to archive_sdk.
This commit updates the custom SDK_POSTPROCESS_COMMAND variable with the new
function name.
https://jira.digi.com/browse/DEL-7013
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This configuration is required to sign and encrypt U-Boot images during
build time, as it is done for ccimx6ul platform.
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
This commit adds a installation script that uses fastboot support to
update the target firmware.
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
https://jira.digi.com/browse/DEL-6845
Environment encryption is not yet supported in U-Boot.
Unset TRUSTFENCE_ENCRYPT_ENVIRONMENT on the machine configuration
and remove the platform conditional on the class.
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>
Some configuration files inside of the SDK make use of the default SDK
installation path, so some tools might break unless the SDK is installed in said
default path.
Recently, we modified the default installation path to include the platform and
the image type, but the image type was added after the SDK was created, so even
though the environment script's paths include the image type, the "original"
default path in the config files inside of the SDK doesn't include the image
type. A side effect of this is that Qt5 apps cannot be built, since the qmake
and Qt configuration files are pointing to the "original" SDK path.
Remove the image type from the path so that the paths in the SDK's config files
match the real default installation path.
This partially reverts commit be0fe088e3.
https://jira.digi.com/browse/DEL-6972
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Since the final image name is not available in a global scope, append it to the
default installation path in the SDK extraction script once it has been
packaged.
The new default installation path format is:
/opt/dey/<version>/<platform>/<image>
https://jira.digi.com/browse/DEL-5264
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Trustfence is not yet fully supported for the CC8X.
Retore the warning.
This reverts commit 78534ca779.
Signed-off-by: Hector Palacios <hector.palacios@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
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>
The generate_installer_zip() function had a hardcoded "u-boot" filename when adding
the bootloader to the list of files that are put in the installer .zip.
https://jira.digi.com/browse/DEL-6174
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Rename recipe and fix the path of the progress binary. Also on the
rocko branch of meta-swupdate several signing mechanisms are
supported, and the value is used as a string to determine which one
to use.
Signed-off-by: Jose Diaz de Grenu <Jose.DiazdeGrenu@digi.com>
This commit creates a new file called 'dey-version-${REAL_MULTIMACH_TARGET_SYS}'
(for example, 'dey-version-cortexa7hf-neon-dey-linux-gnueabi') at the same level
as 'version-${REAL_MULTIMACH_TARGET_SYS}',
'site-config-${REAL_MULTIMACH_TARGET_SYS}', and
'environment-setup-${REAL_MULTIMACH_TARGET_SYS}' files.
The file contains the following parameters:
* Machine. The name of the platform the toolchain was built for (ccimx6sbc,
ccimx6ulsbc, ccimx6ulstarter).
* Version: A versioning system for the generated toolchains. Currently is the
distro version followed by the timestamp on which the current build started.
* Image: The name of the image that triggered the population of the SDK
(core-image-base, dey-image-aws, dey-image-qt-${GRAPHICAL_BACKEND})
The purpose of the 'dey-version-*' file is to be parsed by Eclipse so toolchains
can be autodetected.
This file is packaged with the rest of SDK/toolchain resources ('version-*',
'site-config-*', and 'environment-setup-*' files, and 'sysroots' directory)
when creating the SDK tarball and later the installation script.
The 'dey-version-*' file could also be created in a 'meta-environment.bbappend'
appending to the 'create_sdk_files()'. But from this recipe there is no access
to the name of the image that triggers the creation of the SDK (core-image-base,
dey-image-aws, dey-image-qt, etc.).
Currently, we are redefining 'SDK_POSTPROCESS_COMMAND' (from
'poky/meta/classes/populate_sdk_base.bbclass') to insert the generation of the
'dey-version-*' file just before creating the SDK tarball.
https://jira.digi.com/browse/DEL-5074
Signed-off-by: Tatiana Leon <tatiana.leon@digi.com>
If values are provided in the local.conf, the package will have the
'config.json' file preconfigured.
https://jira.digi.com/browse/DEL-4274
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Rename the class so it's not specific to the C version of the AWS IoT
Device SDK, and can be used for anything related with AWS IOT (for
example Greengrass).
https://jira.digi.com/browse/DEL-4274
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Variable 'AWS_IOT_LOGGING_LEVEL' can be used from the project 'local.conf' to
establish the logging level of the AWS IoT Device SDK.
There are 6 incremental levels: none, error, warn, info, debug, and trace.
Default is 'debug'.
https://jira.digi.com/browse/DEL-4101
Signed-off-by: Tatiana Leon <tatiana.leon@digi.com>
With the migration to Morty, some of the paths to the artifacts (boot
and rootfs images) need to be updated.
While on it, also remove the temporary README.txt file which is not
needed after it has been packed in the zip installer.
https://jira.digi.com/browse/DEL-4013
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
- Trying to set the complete SWU packages signature key in the
TrustFence class was causing a build error when keys were not
yet generated. To avoid this, set only the key wildcard in the
TrustFence class and expand the variable in the SWU packages
recipes, when keys already exist.
https://jira.digi.com/browse/DEL-3913
Signed-off-by: David Escalona <david.escalona@digi.com>
- Enabled signing support while generating the swupdate
packages for 'core-image-base' and 'dey-image-qt'. The
signing support is only enabled when 'TUSTFENCE_SIGN=1'
and requires the recipe to set the private key that will
be used to generate the signature.
- Enabled hash support while generating the swupdate
packages for 'core-image-base' and 'dey-image-qt'. The
hash support requires the sw-description files to include
a new line for each image and/or file that will be added
to the update package. The hash is automatically calculated
and replaced in the sw-description files.
https://jira.digi.com/browse/DEL-3774
Signed-off-by: David Escalona <david.escalona@digi.com>
It's not enabled by default. It's controlled by DEY_IMAGE_INSTALLER
variable in the project's local.conf.
https://jira.digi.com/browse/DEL-3591
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
When encryption is enabled, the signed U-Boot image will be used for the uSD.
This allows the uSD image to boot the device and recover it from the U-Boot
console, which is its main purpose. Nevertheless, the uSD image will not be
able to boot Linux.
https://jira.digi.com/browse/DEL-2877
This reverts commit 2e13e194d9.
Currently we don't support booting encrypted images from an SDCARD, so
just disable the generation of such images.
https://jira.digi.com/browse/DEL-2876
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
By default, on closed devices you cannot revoke any key. To do so, it is
required to compile a U-Boot which instructs the HAB not to set the sticky
bit which write protects that field in the OCOTP controller.
This patch introduces a Yocto macro which allows to configure U-Boot in
that way.
In the ConnectCore 6, the value of this settings is ignored, because HAB never
sets the sticky bit which write protects that field.
https://jira.digi.com/browse/DUB-665
Signed-off-by: Diaz de Grenu, Jose <Jose.DiazdeGrenu@digi.com>
While performing usability testing on the TrustFence documentation, it has
been noted that in order to follow the secure boot instructions the
console needs to be enabled.
We have now moved the secure console section to the end of the
documentation so that disabling the console is the last configuration to
make in a secure system.
Signed-off-by: Alex Gonzalez <alex.gonzalez@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>
The TRUSTFENCE_UBOOT_DEK_SIZE Yocto macro maps to the UBOOT_DEK_SIZE U-Boot
Kconfig entry, which is defined as a choice entry. This makes necessary
to explicitly define the choice Kconfig entry for the configuration to
work.
Signed-off-by: Diaz de Grenu, Jose <Jose.DiazdeGrenu@digi.com>
There are several possible values for TRUSTFENCE_UBOOT_ENV_DEK:
* Not defined: if the trustfence support is not included.
Should not include the feature.
* 32 characters: when defining a valid key.
Should include the feature.
* "0": when explicitly disabling the feature.
Should not include the feature
* <other>: Invalid value, should trigger the error.
This commits fixes the logic so that 'None' (no defined) is taken as a valid
value.
Signed-off-by: Diaz de Grenu, Jose <Jose.DiazdeGrenu@digi.com>
This commit changes the CONFIG_CCIMX6SBC_CONSOLE_ENABLE_GPIO_NR define
into a platform independent setting.
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
https://jira.digi.com/browse/DEL-2641
https://jira.digi.com/browse/DEL-2603
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
Signed-off-by: Jose Diaz de Grenu de Pedro <Jose.DiazdeGrenudePedro@digi.com>
Arturo Buzarra
Javier Viguera
David Escalona
Francisco Gil
Hector Palacios
Mike Engel
Gabriel Valcazar
Gonzalo Ruiz
Hector Bujanda
Jose Diaz de Grenu
Tatiana Leon
Alex Gonzalez
Jose Diaz de Grenu de Pedro