* 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>
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>
Port the bluez5 qca6564 support based on 5.19 to the current version 5.33.
The ported version is based on qualcomm tag r110048.3.
https://jira.digi.com/browse/DEL-2581
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
The script toggles the BT power GPIO regardless of the value being
undefined.
Check that the GPIO is defined before trying to toggle it.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
The BT power GPIOgpio was determined basing on machine name on device tree.
This corresponds to the name of the board, and might be changed by a user
that designs his own carrier board to use the module on.
Besides, the BT power GPIO is a pin that's routed on the module (both on
the ConnectCore 6 and on the ConnectCard for i.MX28) not on the carrier
board.
This commit determines the BT power GPIO basing on the module string inside
the 'compatible' property. This must exactly match the module name and is
a required property for using Digi module's BSP.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-2109
If the bluetoothd daemon is launched before the interface is ready
RFCOMM/L2CAP listening socket connections fail (apparently because
the channel is not ready) with BlueZ 5.
Signed-off-by: Hector Palacios <hector.palacios@digi.com>
https://jira.digi.com/browse/DEL-2042
btfilter (abtfilt) and bluetoothd are two independent services. Break the
relationship between them and split the support in independent init scripts
https://jira.digi.com/browse/DEL-1933
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
The script was basing on the variant coded in the HWID to determine
if the variant had bluetooth, by comparing to an array of hard-coded variants.
This required the script to be updated with every new variant that supported
Bluetooth.
The patch checks instead if the node 'bluetooth' exists at all in the device tree
to determine if the variant supports Bluetooth.
https://jira.digi.com/browse/DEL-1933
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
We want to unlink the script from abtfilt application, so moved to a different
recipe (that includes hciattach).
https://jira.digi.com/browse/DEL-1933
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
Javier Viguera
Arturo Buzarra
Mike Engel
Hector Palacios
Gabriel Valcazar
Francisco Gil
Hector Bujanda
Isaac Hermida