This reverts commit 3123085e72.
we revert this commit because the patch was already applied on mm-1.6.4
Signed-off-by: Salvador Penalva <salvador.penalva@digi.com>
This commit adds mdev support into the recovery ramdisk to
mount/unmount storage devices for the firmware up tool.
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
https://jira.digi.com/browse/DEL-3692
The main purpose is to improve our kits usability. This way users do not need
to follow the steps in the documentation to change from static to DHCP IPs.
https://jira.digi.com/browse/DEL-3821
Signed-off-by: Tatiana Leon <tatiana.leon@digi.com>
udhcpc's '-n' option means 'Exit if lease is not obtained'.
We want to keep udhcp client alive if lease is not obtained, so when it is
possible, an IP is assigned.
https://jira.digi.com/browse/DEL-3821
Signed-off-by: Tatiana Leon <tatiana.leon@digi.com>
udhcpc options added to 'network/interfaces':
* '-S' to log to syslog too.
* Redirect the output to '/dev/null' not to show messages of the tool running
in background (for example when executing 'ifup').
* '&' to send the udhcp client to background.
https://jira.digi.com/browse/DEL-3821
Signed-off-by: Tatiana Leon <tatiana.leon@digi.com>
The amount of patches to this driver maintained in meta-digi is
substantial, so we are moving to a git repository release model.
https://jira.digi.com/browse/DEL-3710
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
This is to avoid the following QA error:
ERROR: fbtest-1.0-r0 do_package_qa: QA Issue: No GNU_HASH in the elf binary: '/usr/local/ssd/dey-2.2/workspace/ccimx6ulstarter/tmp/work/cortexa7hf-neon-dey-linux-gnueabi/fbtest/1.0-r0/packages-split/fbtest/usr/bin/fbtest' [ldflags]
ERROR: fbtest-1.0-r0 do_package_qa: QA run found fatal errors. Please consider fixing them.
ERROR: fbtest-1.0-r0 do_package_qa: Function failed: do_package_qa
ERROR: Logfile of failure stored in: /usr/local/ssd/dey-2.2/workspace/ccimx6ulstarter/tmp/work/cortexa7hf-neon-dey-linux-gnueabi/fbtest/1.0-r0/temp/log.do_package_qa.6755
ERROR: Task (/usr/local/ssd/dey-2.2/sources/meta-digi/meta-digi-dey/recipes-digi/fbtest/fbtest.bb:do_package_qa) failed with exit code '1'
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
Reviewing the patches while updating the QCA firmware to a new release,
I encountered this patch. On the original PR it says:
"Do not use hcitattach to reconfigure the baudrate but set it directly in the
Bluetooth FW file; this save us from some syncronism problems if we are not
using HW flow control."
Current spins of the module already use hw flow control. Also, not allowing
hciattach to override the baudrate does not seem right to me. It would be
enough with passing a 3M baudrate to hciattach to match the firmware
default.
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
This commit fixes an issue with ModemManager to return the correct
error code when an invalid QMI command is send to the modem.
There are two ways to get the UIM/SIM status, one with the "DMS"
service that works on most devices from 2015 and earlier, and a
new way with the "UIM" service that works on many 2015+ devices.
Perhaps the EC21 is new enough that it requires the UIM service,
but ModemManager doesn't recognize the error code that it's returning.
There are two ways to get the UIM/SIM status, one with the "DMS"
service that works on most devices from 2015 and earlier, and a
new way with the "UIM" service that works on many 2015+ devices.
Perhaps the EC21 is new enough that it requires the UIM service,
but ModemManager doesn't recognize the error code that it's returning.
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
https://jira.digi.com/browse/DEL-3748
This commit fixes an issue with the Quectel EC21/EC25 due to a wrong
reported DMS version which will cause ModemManager not to read the
SIM card.
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
https://jira.digi.com/browse/DEL-3748
Implement:
* support to start, stop and restart interface
* states machine and retries system to recover from command failures
* overall simplification and code clean-up
https://jira.digi.com/browse/DEL-3858
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>
- Instead of trying to generate the TrustFence keys in this recipe
when they are not present, depend on the 'virtual/kernel' to
ensure they are already generated. This solves a concurrency problem
when two recipes try to generate TrustFence keys at the same time.
https://jira.digi.com/browse/DEL-3913
Signed-off-by: David Escalona <david.escalona@digi.com>
Allowing to boot a non-encrypted rootfs when encryption is enable is a security
hole: if an attacker can somehow write (offline) to the media, he could flash a
custom unencrypted rootfs and break into the system.
If the system is configured to use encryption, only encrypted rootfs will boot.
Trying to boot a non-encrypted rootfs will fail and power off the device.
https://jira.digi.com/browse/DEL-3829
Signed-off-by: Tatiana Leon <tatiana.leon@digi.com>
The recovery ramdisk already contains functionality for encrypted rootfs
installation. The goal is to centralize all this functionality in the recovery
ramdisk.
https://jira.digi.com/browse/DEL-3829
Signed-off-by: Tatiana Leon <tatiana.leon@digi.com>
- Instead of using a different boot script when booting from linux
and from recovery, merge them into one script that checks the
boot source.
https://jira.digi.com/browse/DEL-3836
Signed-off-by: David Escalona <david.escalona@digi.com>
For CC6UL, when setting a new key, an "enc" flag must be added to the rootfs in
the "mtdparts" U-Boot variable.
After that a reboot is needed, so the recovery command must be modified to
remove the encryption key and proceed with the rest of commands in the next
boot.
When updating the firmware, a format of the rootfs partition is always
performed, independently if a new encryption key has just been configured.
In case only the encryption key is being configured, we also need to reboot to
format the rootfs properly.
https://jira.digi.com/browse/DEL-3685
Signed-off-by: Tatiana Leon <tatiana.leon@digi.com>
For CC6UL, when not using rootfs encryption, the "enc" flag must be removed from
the "mtdparts" U-Boot variable.
https://jira.digi.com/browse/DEL-3685
Signed-off-by: Tatiana Leon <tatiana.leon@digi.com>
Software update recipes ('core-image-base-swu' and 'dey-image-qt-swu') are able
to set default or customized values for:
* In the CC6, the proper path for:
* linux partition (default to '/dev/mmcblk0p1')
* rootfs partition (default to '/dev/mmcblk0p3' if no encrypted, always
'/dev/mapper/cryptroot' otherwise)
* In the CC6UL, the proper volume name for
* linux partition (default to 'linux')
* rootfs partition (default to 'rootfs')
https://jira.digi.com/browse/DEL-3666https://jira.digi.com/browse/DEL-3686
Signed-off-by: Tatiana Leon <tatiana.leon@digi.com>
This commit verifies that the wlan1 interface is not already created
and will skip creating the virtual interface if it already exist.
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
https://jira.digi.com/browse/DEL-3917
Seems that this is needed for the bluetooth interface to work. Without
this options, the interface is not able to initialice (hciattach command
fails).
https://jira.digi.com/browse/DEL-3855
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
With the upgrade to Morty, there is a new bootscript that is provided
by Poky. This bootscript is just launching the generic bluetooth daemon,
but it's not doing any hardware initialization.
The fix is to split the hardware initialization to a different
bootscript 'bluetooth-init' and launch it also on boot.
https://jira.digi.com/browse/DEL-3855
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
If you try to use libmbim (the API is used at least by mbim-network,
mbimcli and ModemManager applications) you get the following error:
ModemManager: Error converting string: Conversion from character
set 'utf-8' to 'utf-16le' is not supported
In order to solve this we need to integrate glibc gconv UTF16le library
in the build (and its dependencies).
Signed-off-by: Mike Engel Mike.Engel@digi.comhttps://jira.digi.com/browse/DEL-3830
This commit changes the concurrent mode script to enable always the
AP interface through the wireless device but will warn the use
if the virtual MAC addresses used are the default once.
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
https://jira.digi.com/browse/DEL-3900
The flash_eraseall busybox utility is not used in the ccimx6 and ccimx6ul
platforms. Its corresponding patch (and the library it depends on) can be
removed from the busybox recipe.
https://jira.digi.com/browse/DEL-1320
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This commit adds the wireless concurrent mode as a default
configuration to the CC6UL machine.
Signed-off-by: Mike Engel <Mike.Engel@digi.com>
https://jira.digi.com/browse/DEL-3818
- 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>
- While trying to update the system using signed swupdate packages, the
swupdate binary requires a new parameter (-k) to specify the location
of the public key that will be used to verify the update package. At
the moment there is no way to check if a package is signed or not, so
we asume that the existence of the public key in the recovery initramfs
is enough to determine that we want to update the system using signed
packages.
https://jira.digi.com/browse/DEL-3775
Signed-off-by: David Escalona <david.escalona@digi.com>
- The swupdate binary included in the recovery partition when the
images to build are trustfence enabled performs a verification
of the swupdate package. For this verification to suceed, it is
mandatory to provide to the swupdate binary the public key that
will be used to verify the swupdate package. This public key must be
included in the recovery initramfs only when 'TRUSTFENCE_SIGN=1'.
https://jira.digi.com/browse/DEL-3772
Signed-off-by: David Escalona <david.escalona@digi.com>
- The 'sign/verify' feature of swupdate can only be enabled/disabled at
compile time, it cannot be configured at run time.
- The 'sign/verify' defconfig file is only used when the images to
build are configured with 'TRUSTFENCE_SIGN=1'
- This change implies that all swupdate packages generated will have a
hash for the images to install and will be verified. Sign support is
only enabled for trustfence images.
https://jira.digi.com/browse/DEL-3773
Signed-off-by: David Escalona <david.escalona@digi.com>
- In Jethro, swupdate recipe was using 'swupdate_git.bb' as the main recipe to
build. In morty that recipe has been disabled and the '2017.01' one is used
instead, so we have to append to this new recipe by renaming our existing one.
- Our bbappend will now point to the same SHA1 that is being used, so we can
remove the SRCREV.
- The new code already includes the progress client patch, so it has been removed.
Signed-off-by: David Escalona <david.escalona@digi.com>
Loading firmware by userspace helpers has been deprecated from device
managers (like udev, eudev, etc). Firmware loading is supposed to be
performed by the kernel.
This fixes the loading of an external kernel module (qualcomm wlan.ko)
that was failing to load because of a missing firmware file.
In that case the kernel was requesting the firmware load from userspace:
ar6k_wlan mmc0:0001:1: Direct firmware load for qsetup30.bin failed with error -2
ar6k_wlan mmc0:0001:1: Falling back to user helper
The device manager we are using in DEY-2.2 (eudev) does not support
firmware loading and is not giving an error return value to the kernel
either, so at one point the kernel throws an oops:
Hardware name: Freescale i.MX6 Ultralite (Device Tree)
task: 88228000 ti: 88cbe000 task.ti: 88cbe000
PC is at 0x7f183758
LR is at request_firmware+0x38/0x40
pc : [<7f183758>] lr : [<802f80bc>] psr: 600f0013
sp : 88cbfdb8 ip : 00000000 fp : 88644c00
r10: 0000dac0 r9 : 88cbfefc r8 : 0000000c
r7 : 00007d08 r6 : 88cbfde4 r5 : 88644ea2 r4 : 00000005
r3 : 88cbfde4 r2 : 00000080 r1 : 00000000 r0 : fffffff5
and the wireless driver is not loaded.
https://jira.digi.com/browse/DEL-3856
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
There is now a WLAN user guide with configuration examples so there is
no need to pollute the default file with comments.
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Patches added in 'meta-swupdate' (backported from U-Boot) broke our
layer. We also had those patches, so remove them and make sure the
rest or our patches are applied after the ones from 'meta-swupdate'
by using an anonymous python function instead of appending to the
SRC_URI variable.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
The way the kernel artifacts are generated has change as of Yocto 2.2.
Also some of the variables (e.g. KERNEL_IMAGE_SYMLINK_NAME) have changed
their default values.
Thus the trustfence_sign function needed some tweaks to continue working
properly.
https://jira.digi.com/browse/DEL-3834
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Salvador Penalva
Mike Engel
Tatiana Leon
Alex Gonzalez
Javier Viguera
Sebastian Pastor
David Escalona
Diaz de Grenu, Jose
Gabriel Valcazar