This commit adds u-boot swupdate support for all platforms.
Now u-boot can be updated with all our supported update
options. Currently it will only update first partition
u-boot partition.
https://onedigi.atlassian.net/browse/DEL-8749
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
LVGL is a free and open-source embedded graphics library that is able to run
in environments with limited resources.
This image includes a desktop environment and an LVGL widget demo (lvgl_demo)
https://onedigi.atlassian.net/browse/DEL-8740
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
If the system is send to suspend mode, the bluetooth core is reconfigured.
Therefore, restart the service if it is running, to configure the ble
service.
https://onedigi.atlassian.net/browse/DEL-8694
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
There was a missmatch between the configuration file and the
correct adc in the ccmp15 platform.
Also a whitespace is removed from ccmp13 configuration file.
https://onedigi.atlassian.net/browse/DEL-8702
Signed-off-by: Francisco Gil <francisco.gilmartinez@digi.com>
ConnectCore Cloud Services examples are included in 'dey-examples' repository
so they can be built from here and also imported in Eclipse/Digi Application
Development Environment for Linux with the samples wizard.
The example 'upload_file' has been removed since currently there is no support
for binary data points in the CCCS daemon/client model.
https://onedigi.atlassian.net/browse/DEL-8628
Signed-off-by: Tatiana Leon <Tatiana.Leon@digi.com>
This recipe generates several packages:
* 'cccs' includes the CCCS shared library
* 'cccs-daemon' includes the binary and resources to execute the CCCS daemon
(daemon, service and init scripts, configuration file)
* 'cccs-cert' includes the required certificate to use CCCS daemon
* 'cccs-gs-demo' includes the binary and resources to execute the CCCS get
started demo (binary, service and init scripts)
* 'cccs-legacy' includes the binary (all-in-one) application to execute
the legacy CCCS application (aka cloud-connector) and the configuration
file
* 'cccs-legacy-dev' includes resources to develop legacy CCCS applications
(all-in-one) (header files inside 'cloud-connector' and 'cloudconnector.pc'
pkg config file)
* 'cccs-legacy-staticdev' includes static resources to develop legacy CCCS
applications (all-in-one) (static library)
This commit also renames:
* 'CLOUDCONNECTOR_PKGS' variable to 'CCCS_PKGS'.
* 'CC_DEVICE_TYPE' variable to 'CCCS_DEVICE_TYPE'.
https://onedigi.atlassian.net/browse/DEL-8628
Signed-off-by: Tatiana Leon <Tatiana.Leon@digi.com>
Now we can't determine if the rootfs is ubifs/squashfs
in the ccmp1X platforms, so we need to add again the rootfstype
parameter but only for ccmp1X platforms.
Signed-off-by: Francisco Gil <francisco.gilmartinez@digi.com>
The CCIMX6 platform is the only one that will keep using the 'bootcount' value stored in the environment.
For this reason, that is the only platform requiring the 'upgrade_available' flag to be set after a
firmware update. For the rest of the platforms, remove it.
https://onedigi.atlassian.net/browse/DEL-8506
Signed-off-by: David Escalona <david.escalona@digi.com>
While on it, remove the block of the 'dualboot' script that was taking care of this action.
https://onedigi.atlassian.net/browse/DEL-8506
Signed-off-by: David Escalona <david.escalona@digi.com>
Add a user space application to manage the bootcount from the running system. This application
allows to read, reset and set the bootcount:
Usage: bootcount [options]
-r --read Read the current bootcount value (Default action)
-s <value> --set=<value> Set current bootcount to a specific value.
-x --reset Reset bootcount value to zero.
The binary checks the running platform underneath to perform the correct system access.
While on it, add a service to automatically execute the binary on boot to reset the bootcount value.
https://onedigi.atlassian.net/browse/DEL-8506
Signed-off-by: David Escalona <david.escalona@digi.com>
This commit adds sha256 entry for the script files into
the sw-descrition. It is necessary for the Trustfence
authentication to have the included script files signed.
https://onedigi.atlassian.net/browse/DEL-8649
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
This variable is only needed in the cc6ul, that's the reason
to create another sw-description only for the ccimx6ul.
Signed-off-by: Francisco Gil <francisco.gilmartinez@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>
fill_description copies some artifacts to the images deploy directory,
so that should be created beforehand. Otherwise it may fail on the
'do_unpack' task depending on how bitbake schedules the tasks.
Signed-off-by: Javier Viguera <javier.viguera@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>
Enable scripting support during the installation of system images with SWU. A new shell
script is included by default in all the SWU update packages that will be executed just
before the update starts and just after it finishes. The script is empty and contains two
place-holders that will be called in the two scenarios mentioned before.
Users can customize this script to execute specific actions based on their final product
needs or provide their own one by setting its location in the 'SWUPDATE_SCRIPT' variable.
While on it, rename the 'sw-description_template' file to 'sw-description-images_template'
as it is more accurate with the update mechanism it is used for.
Signed-off-by: David Escalona <david.escalona@digi.com>
In a squashfs the mount points are different and the current logic
wasn't working.
It's more reliable to check the /proc/cmdline to determine if
the system is a nand or an emmc.
Added also logic to get the active partition in nand devices
when the rootfs is squashfs.
https://onedigi.atlassian.net/browse/DEL-8558
Signed-off-by: Francisco Gil <francisco.gilmartinez@digi.com>
When a squashfs image is flashed we need to delete the compression
field in the swupdate descriptor.
Also the rootfstype u-boot variable needs to be set to squashfs.
https://onedigi.atlassian.net/browse/DEL-8558
Signed-off-by: Francisco Gil <francisco.gilmartinez@digi.com>
The fact of including both storage types (mtd and mmc) in the same 'sw-description' file is not providing any kind
of benefit. Instead, it makes the file larger, complex and harder to maintain. Additionally, most of the images
entries share the same structure and contents, changing only names and mount points. This commit simplifies the
'sw-description' file by configuring the storage type and the images to include in the SWU package at build
time, using a generic 'sw-description' template and template files for 'mmc' and 'mtd' images.
While on it, use the new 'DEY_FIRMWARE_VERSION' variable for SWU package version and fix the recipe to not include
all 'SRC_URI' files in the SWU update image, but only the required files for the update. Also, make use of variable
substitution provided by SWU class in the 'sw-description' file.
Note: SWU U-Boot update will be broken after this change. Waiting for official support with a robust implementation.
https://onedigi.atlassian.net/browse/DEL-8537https://onedigi.atlassian.net/browse/DEL-8538
Signed-off-by: David Escalona <david.escalona@digi.com>
While on it, rename the old "Firmware" variable to "DEY version", as it refers explicity to the DEY
distribution version.
https://onedigi.atlassian.net/browse/DEL-8539
Signed-off-by: David Escalona <david.escalona@digi.com>
If 'CC_DEVICE_TYPE' is not defined or it is empty use 'MACHINE' as the device
type in the Cloud Connector configuration file.
This commit also limits its length to a maximum of 255 characters.
https://onedigi.atlassian.net/browse/DEL-8531
Signed-off-by: Tatiana Leon <Tatiana.Leon@digi.com>
In a squashfs the mount points are different and the current logic
wasn't working.
It's more reliable to check the /proc/cmdline to determine if
the system is a nand or an emmc.
Added also logic to get the active partition in nand devices
when the rootfs is squashfs.
https://onedigi.atlassian.net/browse/DEL-8558
Signed-off-by: Francisco Gil <francisco.gilmartinez@digi.com>
When a squashfs image is flashed we need to delete the compression
field in the swupdate descriptor.
Also the rootfstype u-boot variable needs to be set to squashfs.
https://onedigi.atlassian.net/browse/DEL-8558
Signed-off-by: Francisco Gil <francisco.gilmartinez@digi.com>
The root file system requires the public key to authenticate SWU files.
For NXP platforms, the public key is extracted from the certificate.
For STM platforms, simply copy the public key over to the rootfs.
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>
dualboot and recovery recipes may require to use the keys so they must
depend on the recipe that installs the script that generates them.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
This commit syncs the device request code to match with the latest 'cc_api'
layer implementation.
See commit 99a2ff39b771f0e36af8d15d40f970462352e0b6 in 'cc_api' repository and
commit d8c848fc2f516a6c2197181f7540c9c23feaf44f in 'cc_dey' repository.
Signed-off-by: Tatiana Leon <Tatiana.Leon@digi.com>
Connector creates detached threads and calling to 'wait_for_ccimp_threads()' is
not required.
See commit d34ddfb719932ae59774b388579b7d6a77472c4f in 'cc_dey' repository.
Signed-off-by: Tatiana Leon <Tatiana.Leon@digi.com>
* Remove 'MAX_RESPONSE_SIZE' define and allocate required memory in
'device_request_listener' example.
* Create 'free_timestamp()' function in 'upload_data_points' example.
* Use some sorter variable names.
* Use '__func__' to log function names.
* Remove line feed from log messages.
* Remove not required curly braces for single line loops.
Signed-off-by: Tatiana Leon <Tatiana.Leon@digi.com>
Mike Engel
Gabriel Valcazar
Francisco Gil
Arturo Buzarra
Isaac Hermida
David Escalona
Tatiana Leon
Hector Palacios
Javier Viguera