* 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>
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>
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>
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>
This is the stack covered by the Bluetooth certification. We will keep
it even though the newer bluez 5.46 will be used by default.
https://jira.digi.com/browse/DEL-5518
Signed-off-by: Jose Diaz de Grenu <Jose.DiazdeGrenu@digi.com>
* 'experimental' has been renamed to 'testing' in Bluez 5.44
* Several patches (0004..0011) are now upstream and can be removed
* QCA specific patches have been refreshed
https://jira.digi.com/browse/DEL-5518
Signed-off-by: Jose Diaz de Grenu <Jose.DiazdeGrenu@digi.com>
Subset of commits to fix the pairing for dual mode devices. Main
commit that fixes is 2d3685252a21cda4b918ad1cc4dd0572bd5c6d3c, but some
previous commits are required as well.
"""
For dual mode devices we need to pass address type used in pairing
events to reply with correct one on agent reply. Otherwise reply for
BR/EDR pairing of dual mode device would use address type (which is
valid only for LE address) resulting in reply being ignored by kernel
and eventually pairing timeout.
"""
https://jira.digi.com/browse/DEL-5226
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
For avoid compilation error due to platform specific patches, first apply
the common patches and later apply platform specific patches.
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
Create a multiple patch file with the original qualcomm code that adds
support for the qca6564 chip (hcitattach_rome)
Signed-off-by: Isaac Hermida <isaac.hermida@digi.com>
Avoid splitting the boot script message in two different lines:
Starting bluetooth hardware: [OK]
done.
Signed-off-by: Javier Viguera <javier.viguera@digi.com>
The following changes have been made to the bluetooth-init script:
* Remove "hciconfig hci0 up/down" and this is now deprecated and likely
to fail. We use the AutoEnable feature of bluetoothd for this now.
* Move setting the MAC address to hciattach instead of using hcitool.
* Remove resets performed by hcitool and hciconfig. The hciattach
application already performs a reset and that should suffice.
* Remove hciattach retries.
https://jira.digi.com/browse/DEL-3711https://jira.digi.com/browse/DEL-3436https://jira.digi.com/browse/DEL-3636https://jira.digi.com/browse/DEL-3955
Signed-off-by: Alex Gonzalez <alex.gonzalez@digi.com>
This commits adds patches to hciattach for the following:
* Strict flow control setting
The hciattach application has a flow | noflow command line argument that is
currently only applied on the first configuration of the uart port. The
hciattach_rome plugin ignores this setting and assumes hardware flow
control is always supported. This commits makes hciattach obey the user flow
control indication.
* Modify hciattach_rome to set MAC address. The MAC address setting
feature in the rome plugin now works with the command line specified
MAC.
* Reduce verbosity. hciattach now accepts a "-v" verbose flag. By
default verbose output it omitted.
https://jira.digi.com/browse/DEL-3711https://jira.digi.com/browse/DEL-3436https://jira.digi.com/browse/DEL-3636https://jira.digi.com/browse/DEL-3955
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>
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>
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>
Javier Viguera
Gabriel Valcazar
Alex Gonzalez
Arturo Buzarra
Jose Diaz de Grenu
Sebastian Pastor
Isaac Hermida