The bluetooth FW for the IW612 is loaded together with WiFi FW, so there
is not BT FW file as in our other products.
In order to use the BT, it is a requirement to load the WiFi FW, so
ensure that the service is started after the load of the system
modules.
https://onedigi.atlassian.net/browse/DEL-8346
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
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>
Packages bluez5-init, cloudconnector, and connectcore-demo-example-webkit
provide a launcher script that is used regardless of the init system being
systemd or sysvinit. Those launcher scripts use the '/etc/init.d/functions'
file, which is provided by the 'initscripts-functions' runtime package,
so add that runtime dependence.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
Starting at Bluez 5.48, the battery characteristic was moved to the
DBUS org.bluez.Battery1 interface. This causes the device to try to
read information from iOS devices after establishing a connection,
triggering a reverse pairing request. This scenario causes random
disconnects in iOS devices unless a trust agent is registered in the
host to take care of the pairing. Removing the battery plugin at
startup fixes the issue.
Signed-off-by: David Escalona <david.escalona@digi.com>
Those variables are used to hold integer data parsed from bluetooth
config file. The parsing function "get_value_from_config" returns an INT,
so the variables cannot be unsigned.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
* Refresh the 5.56 patches on top of new version 5.64
* Separate the patches for 5.41 and 5.64. The code base has changed a
lot between those two releases, so having common patch files under
'bluez5' directory makes maintenance more cumbersome.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
This commit moves all the work related with the initialization process to a new
recipe to allow disgregate the init scripts from the bluez5 recipe.
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Some packages require different scripts, configuration files or installations
depending on the wireless chip assembled on the target. In general, the way
to support both chips in one image is to have the recipes install both
versions of the aforementioned files, then leave only the strictly necessary
version once the wireless chip can be deduced.
In the case of the init-ifupdown recipe, this involves installing temporary
configuration fragments that are later erased. In the case of the standby
script, the logic can be implemented in a single file.
https://onedigi.atlassian.net/browse/DEL-7661https://onedigi.atlassian.net/browse/DEL-7666
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This allows the packages to be included in the ccimx6sbc images. While at it,
include the Qualcomm bluez patches in ccimx6 builds. These patches aren't
destructive, they simply add functionality required by the Qualcomm chip, so
they shouldn't have any secondary effects when using the Atheros chip.
https://onedigi.atlassian.net/browse/DEL-7661https://onedigi.atlassian.net/browse/DEL-7666
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Simplify the structure of the recipe folder, if one version is not supported
we must use the COMPATIBLE_MACHINE overwrite
https://jira.digi.com/browse/DEL-7508
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
The 'distro_features_check' class has had its functionality expanded, as
a result the class has now been renamed to 'features_check'
https://jira.digi.com/browse/DEL-7508
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Use the same common files for both ConnectCore 8M platforms
https://jira.digi.com/browse/DEL-7397
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
This commit exports several internal headers and libraries
to allow link against them in user applications.
https://jira.digi.com/browse/DEL-6649
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Since the original .bb file is already in the meta-digi layer, bitbake will
look inside of the bluez5-5.41 folder by default, so this line isn't needed.
https://jira.digi.com/browse/DEL-6448
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
Modify bluetooth init script to use kernel module to power on/off
the bluetooth chip instead of managing it directly from sysfs.
https://jira.digi.com/browse/DEL-6615
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Soften the dependencies between the services and start the bluetooth stack
regardless of the existence of a bluetooth chip. Also, update the standby
script to reflect that there is no longer a strong dependency between the
services.
https://jira.digi.com/browse/DEL-6452
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
These changes are needed in order to achieve a behavior similar to our
bluetooth initscripts'.
https://jira.digi.com/browse/DEL-6415
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
This service acts as a systemd replacement for our bluetooth-init initscript.
All it does is call the initscript before starting the bluetooth stack.
Since initscripts dissapear from /etc/init.d when disabling sysvinit, move the
script to /etc/. Also, include bluez5-init as a packagegroup-dey-bluetooth
dependency regardles of whether systemd is enabled or not.
https://jira.digi.com/browse/DEL-6415
Signed-off-by: Gabriel Valcazar <gabriel.valcazar@digi.com>
The point of this recipe is to provide the version of Bluez5 that was
certified. Thes certification does not apply to the ConnectCore 8X, and the
recipe currently fails to build due to missing files. Hence filter out the
ConnectCore 8X from this recipe.
This clears the following warnings:
WARNING: meta-digi/meta-digi-dey/recipes-connectivity/bluez/bluez5_5.41.bb: Unable to get checksum for bluez5 SRC_URI entry bluetooth-init: file could not be found
WARNING: meta-digi/meta-digi-dey/recipes-connectivity/bluez/bluez5_5.41.bb: Unable to get checksum for bluez5 SRC_URI entry main.conf: file could not be found
Signed-off-by: Jose Diaz de Grenu <Jose.DiazdeGrenu@digi.com>
(cherry picked from commit bf9688fd08ac9e8823a5a253bdd1acacd1c0870e)
SOM v1 is not going to be released, so there's no need for a revision check.
Now that hw flow control is available, use it along with the highest baudrate
possible.
This reverts commit e4fbba3dde.
https://jira.digi.com/browse/DEL-6254
Initialize Bluetooth chip in HCI_H4 mode and provide a firmware binary
with the IBS and DEEP_SLEEP mode disabled by default. Also this firmware
enables an internal clock required to maintain the system on low power modes.
https://jira.digi.com/browse/DEL-3711
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
The Digi vendor kernel uses a dedicated HCI UART driver with support for
In-Band Sleep (IBS). This driver, when used with a QCA vendor ROME plugin
for hciattach, is able to upload a new firmware version to the Bluetooth
chipset, as well as set the MAC address directly on the firmware.
Mainline BSP uses the HCI H4 driver instead and the "qualcomm" hciattach
plugin which is not able to upload firmware to the QCA6564 chipset.
As such, when using mainline the chipset uses the ROM firmware and the
bluetooth init script has been adapted accordingly.
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
Set a lower baudrate of 115200bps for bluetooth on SOMv1 since
hardware flow control is not available.
Signed-off-by: Gonzalo Ruiz <Gonzalo.Ruiz@digi.com>
- The variable containing the list of patches has been renamed to a more
generic prefix QCA65XX_.
- The ConnectCore 8X uses GPIO3_10 (394) for BT_EN.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-5936
Firmware verification has a side effect in cc6ul sbc express platform
that affects to the bluetooth initialization.
https://jira.digi.com/browse/DEL-5802
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Rarely the bluetooth firmware is not loaded properly and causes
errors in the configuration steps. This verification makes sure
the firmware was loaded and is functional, if not we start the
retry mechanism with the default baudrate to avoid the firmware
corruption in the upload process.
https://jira.digi.com/browse/DEL-3711
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Bash v4.4 or higher warns when discarding NULL bytes in command substitution
output. Remove these bytes to avoid the undesired warnings.
https://jira.digi.com/browse/DEL-5588
Signed-off-by: Arturo Buzarra <arturo.buzarra@digi.com>
Currently the default bluez5 package installed is bluez-5.46, but we need this
locally for compiling bluez-5.41 (the stack using in the bluetooth
certification process), so we need to locally apply the same fix ("fix python3
core dependency for testtools") for the testtools and its dependency with
python3-code instead of python3.
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
There is not need to specify the testing flag for bluez5 compilation. That flag
is new starting at bluez5.44, and in the past it was called experimental. In
the past it made sense to pass that flag to compile specific services, but most
of them has been migrated to standard features, and experimental has been
renamed to testing, but we do not need any of those testing features.
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>