This generates an installer.zip image with all the firmware
images, including install scripts for UUU, SD card, and USB.
This is helpful to share the artifacts with manufacturing
or for deploying to external media such as microSD or USB stick.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Our new dey-toolchain recipe was missing the logic needed to create the
"dey-version" file in the SDK's installation path. Move this logic from the
dey-image bbclass to a new bbclass meant exclusively for SDK logic, and inherit
it where needed. While at it, move other common SDK modifications to this
class.
https://onedigi.atlassian.net/browse/DEL-9297
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Commit 998598415a moved this logic to the
trustfence.bbclass file, but in doing so, it removed the TRUSTFENCE_SIGN check
it used to have. The check is needed for two reasons:
* The signing of SWU packages only occurs when TRUSTFENCE_SIGN is enabled, so
there's no need to copy the key if it's disabled
* When building a project from scratch that has Trustfence enabled but
TRUSTFENCE_SIGN disabled, a PKI is never generated and the key doesn't exist.
Because of this, the key won't be found and an error will occur. Note that
if your project is already pointing to a populated PKI, the error won't
happen, only if there's no PKI to begin with.
Although the PKI is guaranteed to exist by the time the rootfs is populated,
make sure to check that it has been properly generated and create it if it
doesn't exist. This logic depends on the trustfence-gen-pki.sh from
trustfence-sign-tools-native, so add it as a dependency for
dey-image-recovery-initramfs. The dependency is already there for another
feature in the dey-image recipes, so simply reflect this new dependency in a
comment.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
(cherry picked from commit 8e52c27d5a8e8071c3a17754e91c1819bcceee15)
When it comes to inheriting this qt bbclass, we used to do so for every image
inheriting the "dey-image" bbclass that had "dey-qt" in its IMAGE_FEATURES. In
theory, only dey-image-qt follows these requirements.
However, starting in DEY 3.0, we added support for multiple graphical images,
all of them sharing the same characteristics save for a defining IMAGE_FEATURE.
To implement this, all images have the IMAGE_FEATURE "dey-${GRAPHICAL_CORE}",
with GRAPHICAL_CORE having a default value of "qt" and being overwritten in
each image recipe with its respective value: "qt", "webkit", "crank" or "lvgl".
The problem is that, when checking whether to inherit populate_sdk_qt[5/6] or
not, it's still very early in the recipe parsing process and GRAPHICAL_CORE
still has its default value of "qt", meaning the "dey-qt" IMAGE_FEATURE is
considered present for all graphical images. In turn, this results in qt
packages being included in all graphical image SDKs.
Move the inherit clause to the dey-image-qt recipe and remove the check so
that the qt packages only get installed in the dey-image-qt SDK.
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
(cherry picked from commit 593ff866578e6d341ec4d8a09581922c6390e2a4)
Commit 99f1425340 ("image-buildinfo: Improve and extend to SDK coverage too")
in the Poky layer changes the name of the default build information file from
"build" to "buildinfo", so this commit reflects this change by adapting the
sysinfo script.
Signed-off-by: Arturo Buzarra <arturo.buzarra@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>
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>
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>
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>
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>
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>
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>
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>
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>
The meta-qt5 layer provides a 'populate_sdk_qt5' class with all what's
needed to build a SDK based on an image recipe.
Inherit the class here so it's available for all DEY image recipes
depending on 'dey-qt' image feature.
https://jira.digi.com/browse/DEL-1973
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
This simplifies the code and as an extra allows to override the default
root password from the project's local.conf (setting MD5_ROOT_PASSWD
variable)
https://jira.digi.com/browse/DEL-1558
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Poky added a new class that provides the same functionality we
implemented in our 'dey-image' class. So just use that class instead
of reimplementing it in our layer.
https://jira.digi.com/browse/DEL-1558
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Remove 'dey-test' image feature and create a SARES bbclass with the
same functionality. This makes easier the creation of images suitable
for SARES testing just adding:
INHERIT += "sares-image"
to your project's local.conf
https://jira.digi.com/browse/DEL-1558
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
After the upstream commit in d63c8a1597c9bd0a838cb59ca461ac432b630a90,
bitbake checks to see if the image feature has a valid packagegroup
associated.
For this check to work dey features need to be defined for all images,
not only dey images, so the definitions need to move to the distro
configuration file.
https://jira.digi.com/browse/DEL-852
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
SERIAL_CONSOLE variable has been deprecated in poky. The new
SERIAL_CONSOLES allows to configure multiple devices.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
The final product will be called "Digi Embedded for Yocto" or DEY for
short.
This commit renames all relevant files.
https://jira.digi.com/browse/DEL-474
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
Hector Palacios
Gabriel Valcazar
Arturo Buzarra
David Escalona
Javier Viguera
Mike Engel
Jose Diaz de Grenu
Tatiana Leon
Alex Gonzalez