tibluetooth: Handle errors intead of relying on abritrary delay

There is no guarantee that a fix delay is actually enough, because with
the BT_EN gpio, we only control activation of bluetooth on the chip. But
we don't know the status of the whole chip.

Also hciattach has anyway a timeout of 5 seconds, so 0.1 seconds does
probably not make a big difference in this regard.

So in order to make it the safest possible, we can only rely a failure
handling and retrying. The number 5 for retries has been defined since
repeated restart of the service with only 3 retries leads to failure
pretty quickly. At 4 there is no failure anymore. So with 5 we are sure
the risk of failure is really low.

BugzID: 70195

recipes-connectivity/tibluetooth/tibluetooth/tibluetooth.sh

@@ -3,18 +3,40 @@
 PIDFILE_GPIO=/run/bluetooth0-gpio.pid
 PIDFILE_HCI=/run/bluetooth0-hci.pid
 
-if [ "$1" = "start" ]; then
+enable_bt_chip() {
         BT_EN=$(gpiofind BT_EN)
         gpioset -m signal ${BT_EN}=1 &
         PID_GPIO=$!
         echo $PID_GPIO > $PIDFILE_GPIO
-        sleep 0.1 # Wait to allow the bt-module to start up
+}
-        hciattach -n /dev/bluetooth0 texas 3000000 flow &
+
-        PID_HCI=$!
+disable_bt_chip() {
-        echo $PID_HCI > $PIDFILE_HCI
+        kill $(<$PIDFILE_GPIO)
+}
+
+if [ "$1" = "start" ]; then
+        retries=0
+        while [ $retries -lt 5 ]
+        do
+                enable_bt_chip
+                if HCI_LOG=$(hciattach -p /dev/bluetooth0 texas 3000000 flow ); then
+                        # Writing PID
+                        echo "$HCI_LOG" | tail -n 1 > $PIDFILE_HCI
+                        exit 0
+                fi
+
+                echo "$HCI_LOG"
+                disable_bt_chip
+                ((retries++))
+                sleep 1
+        done
+
+        echo "Could not start hciattach"
+        exit -1
+
 elif [ "$1" = "stop" ]; then
         kill $(<$PIDFILE_HCI)
-        kill $(<$PIDFILE_GPIO)
+        disable_bt_chip
 else
         echo "Unknown command"
         exit -1