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>
David Escalona
Gabriel Valcazar
Javier Viguera
Mike Engel
Hector Palacios
Arturo Buzarra
Francisco Gil
Gonzalo Ruiz
Hector Bujanda