This fix systemd error on boot:
[ 6.974370] systemd[1]: /lib/systemd/system/connectcore-demo-example.service:3: Failed to add dependency on connectcore-demo-server, ignoring: Invalid argument
Signed-off-by: Tatiana Leon <Tatiana.Leon@digi.com>
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>
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>
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>
Commit 429125cce0 created a minimal version 'defconfig'
that doesn't include all the default configuration options
of swupdate.
However, an anonymous python function inside the swupdate
repository establishes dependencies basing on configuration
switches it finds (or not) in the 'defconfig' file and any
additional configuration fragments.
For this reason, a minimal 'defconfig' cannot be used in
this recipe and a full configuration file (that also includes
default options) must be used instead.
Reported-by: Stephan Klatt
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
Signed-off-by: Javier Viguera <javier.viguera@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>
Those bbappends are enabling 'examples' PACKAGECONFIG. This is now done
in the distro config file.
https://onedigi.atlassian.net/browse/DEL-8675
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
QT v6.5 is a long term support (LTS) and is the version used in newer
releases from NXP (based on Yocto 4.2 mickledore)
This commit basically backports the QT v6.5 from meta-freescale community
layer (mickledore) with some recipe's polishing from meta-imx.
https://onedigi.atlassian.net/browse/DEL-8675
Signed-off-by: Javier Viguera <javier.viguera@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 ccmp1 has two MTD partitions (UBI, UBI_2) with different system
volumes.
Previously, the fact of having two ubi devices was taken as proof of
being on a multi-MTD system (one that has one UBI volume per partition).
Instead, this commit reformulates the condition to having a partition of
the same name than the UBI volume.
For the case of the ccmp1, add a new for loop to iterate across any number
of UBI devices.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
The P2P interface may have a different name, for instance, in the ccimx93 it
is wfd (wifi direct).
Generalize Digi P2P scripts to use the name from the platform config file.
https://onedigi.atlassian.net/browse/DEL-8468
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
Make sure all packagegroups and examples needed for Qt6 support are accesible
to both NXP and STM-based platforms.
https://onedigi.atlassian.net/browse/DEL-8655
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@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>
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>
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>
There is a corner case in the cc6ul where the update from
recovery was failing.
If the u-boot variable rootfstype is set to squashfs u-boot
modify the bootargs adding "root=/dev/ubiblock1_0". The grep
of the command line was failing and detecting the device as
mmc and making the firmware update process fail.
Modify the grep to use the same system that we are using in
the update-firmware script.
Signed-off-by: Francisco Gil <francisco.gilmartinez@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>
This allows to set RTC configuration parameters. For example, the rv3028
RTC included in ccmp1 and ccimx93 has the "backup switching mode"
configuration in a register that is saved to an eeprom. By default the
BSM value is 00, which means backup switchover disabled. This means that
even if you connect a coin cell to our DVK, the RTC will ignore it.
With this commit, the BSM can be configured to direct switching mode
(DSM) or level switching mode (LSM) so the RTC uses the battery when the
device is powered off.
Signed-off-by: Javier Viguera <javier.viguera@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>
Writing directly into UBI volumes is not allowed, so a special 'rdiff' handler capable of
write data in UBI volumes is required. This commits adds the new handler and enables it in
MTD based systems.
https://onedigi.atlassian.net/browse/DEL-8624
Signed-off-by: David Escalona <david.escalona@digi.com>
The 'RDIFF' handler allows to apply incremental updates using rdiff delta files in the
swu update package. This functionallity is only recommended for read-only file systems,
where the source partition cannot be modified externally by users.
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>
Starting at kernel 6.1, the maxim98088 driver has been migrated
from the old imx-max98088.c driver to NXP’s new audio framework
fsl-asoc-card.c.
Update the sound stuff to match the new audio card and some of
the new controls.
https://onedigi.atlassian.net/browse/DEL-8596
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
Building swupdate with '-j1' fails with:
swupdate$ make -j1
scripts/kconfig/conf --silentoldconfig Kconfig
CC ipc/network_ipc.o
CC ipc/network_ipc-if.o
CC ipc/progress_ipc.o
LD ipc/built-in.o
LD libswupdate.so.0.1
Failed:
aarch64-dey-linux/11.3.0/ld: cannot find ipc-static/lib.a: No such file or directory
collect2: error: ld returned 1 exit status
That's due to trying to link a static library that has not been compiled
yet. That dependence seems spurious and we added it in a patch, so
remove it to fix non-parallel builds.
https://onedigi.atlassian.net/browse/DEL-8445
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
The btnxpuart driver uses internally the serial port to manage the chip, and
loads the BT FW independently of the WiFi subsystem.
While on it, add support in the bluetooth-init script to be able to power the
chip when the WiFi support is not present.
https://onedigi.atlassian.net/browse/DEL-8632
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
This reuses the same variable from sysvinit (USE_VT) to disable running
getty/login on virtual terminals.
Signed-off-by: Javier Viguera <javier.viguera@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>