built-in BLE on rpi 3

[craigmulligan]

version: 2.0.0-beta.1
Has anyone tested built-in wifi on rpi3 with resinos?

@cskiraly has reported Agile-IoT/agile-stack#9 that it is not working.

The linked resinOS image is not handling the RPi3 BLE adapter. hciconfig shows nothing. Otherwise, with an external dongle, bluetooth works fine.

I'll try test later today when I have a device on hand. Unless @agherzan @floion are already aware potential problems?

[agherzan]

I know @josephroberts did some work on this.

[jbaldwinroberts]

@craig-mulligan @agherzan this works fine on managed resinOS 2.0 and I expect it would be the same on unmanaged.

@agherzan why can't we include the bluetooth stuff by default in our base images?

[craigmulligan]

Ah yes, I remember it needed a patch. Thanks @josephroberts

[cskiraly]

In other words, the magic command is /usr/bin/hciattach /dev/ttyAMA0 bcm43xx 921600 noflow -
Thanks!

I think this should be part of the base image.

[cskiraly]

@agherzan was this already included in https://github.com/resin-os/resin-raspberrypi ?

[agherzan]

I'm not sure what's the problem. Can someone clarify what's the problem and/or what's expected?

[craigmulligan]

@agherzan the problem is anytime you want to use the built-in ble on rpi3 you have to run /usr/bin/hciattach /dev/ttyAMA0 bcm43xx 921600 noflow -a sometimes a couple times before it works.

I think @josephroberts is suggesting we put that command in our base images and @cskiraly is suggesting adding it to the host?

[agherzan]

The serial device /dev/ttyAMA0 is dependent what what serial is used for bluetooth. It can be either AMA0 or S0 depending on the overlay used.

[lurch]

I believe in the official Raspbian distro, "some mechanism" (dunno whether this is firmware / kernel / devicetree / udev) is in place that sets up /dev/serial0 and /dev/serial1 as 'persistent' serial aliases that dynamically point to either AMA0 or S0 as appropriate, depending on which overlay you're using.
(Can't remember the exact details, as it's not something I've looked at in depth)

[agherzan]

Sure, we can definitely do that too.

[mihalski]

I'm currently using hassio which is built on top of resinos and I'm running into a/the bluetooth problem. No hci0 device. I've tried the instructions here but didn't get very far.

root@hassio:~# /usr/bin/hciattach /dev/ttyAMA0 bcm43xx 921600 noflow -
bcm43xx_init
Flash firmware /lib/firmware/brcm/BCM43430A1.hcd
Set Controller UART speed to 921600 bit/s
Device setup complete
root@hassio:~# hcitool scan
Device is not available: No such device

I tried running it again as suggested but then I just got:

/usr/bin/hciattach /dev/ttyAMA0 bcm43xx 921600 noflow -
bcm43xx_init
Failed to write reset command
Can't initialize device: Success

I'm hoping to use bluetooth inside the docker container running on this system (if that it as all possible).

Also, not at all clear whether the https://github.com/resin-os/resin-raspberrypi link is relevant to my situation.

Thank you in advance.

Regards,
Michal

[shaunmulligan]

Hi @mihalski
How are you running the containers from hassio. I believe in order to use BLE from within a container, you need to make sure the container runs with host networking, or that the bluetooth interface is included in the network namespace of the container.

On resin.io we currently run the containers with the --net=host option, so bluetooth works.

[mihalski]

Yes they run with --net=host.

The problem is the host doesn't have working bluetooth by default. I found that I could get it working with the following commands:

modprobe btusb
/usr/bin/hciattach /dev/ttyAMA0 bcm43xx 921600 noflow -
hciconfig hci0 up

Is there any chance that this could be integrated within resinos for raspberrypi3?

[cskiraly]

@mihalski I never needed the modprobe. Otherwise I agree, +1 for having this already on in the image!

[mihalski]

@cskiraly For me the btusb module is not loading automatically. It loads for you or you have a different type of bluetooth? Or a different device?

[cskiraly]

@mihalski I don't have an SD with resin.os with me, but looking at a device with an other OS, I see hci0 up, and the following modules: bluetooth, bnep, btbcm, hci_uart.
I think you don't need btusb for the integrated BLE on the Raspberry Pi 3.

[mihalski]

@cskiraly I think you are right. It's just the

/usr/bin/hciattach /dev/ttyAMA0 bcm43xx 921600 noflow -
hciconfig hci0 up

that is required.

[mihalski]

Any word on this? Could it be integrated into the next resinos release?

[agherzan]

@shaunmulligan @lurch From 2.0.2, raspberrypi images provide device symlinks (https://github.com/resin-os/resin-raspberrypi/blob/master/CHANGELOG.md#v202rev1---2017-04-24) .

[mihalski]

Does that mean that the above mentioned commands can be performed WITHIN a container to provide bluetooth functionality?

[agherzan]

@craig-mulligan , this sounds to me like an issue when using bluetooth on resinOS unmanaged. Did you manage to get to any conclusion since you opened this bug?

@mihalski No. That would help if we decide to bring in the hostOS the bluetooth initialisation.

[andreipopovici]

Just like @mihalski, I'm a hassio user with a similar problem, although slightly different.

I'm disabling BT using an overlay (pi3-disable-bt) in config.txt, because I'm using a RaZberry board that needs to access the UART on GPIO pins 14-15. The overlay frees the pins and I can see /dev/ttyAMA0' on the host (hassio). However, inside the Alpine-based docker container, I see nothing except /dev/tty`.

What am I missing here? Do I need to mount /dev/ttyAMA0 when running the container?

[shaunmulligan]

@andreipopovici yeah, I think you would need to do something like docker run <imageId> --device /dev/ttyAMA0 assuming you are running unprivileged and that /dev/ttyAMA0 exists in the hostOS /dev

[andreipopovici]

@shaunmulligan That's what the hassio developer (@pvizeli) did in release 0.35. It allows mounting a device into the homeassistant docker image and works great.

[pvizeli]

We create now a hass.io docker that are able to manage bluetooth from a container to other containers: https://github.com/home-assistant/hassio-addons/tree/master/bluetooth_bcm43xx . I think this topic os now close for hassio users. Thanks for giving support to us.

[floion]

Hi all, can this be closed now? Is there any further action needed here @pvizeli @andreipopovici @mihalski @cskiraly @craig-mulligan ?

[cskiraly]

@floion the topic is not hassio specific, therefore no, it is not solved. We know there are workarounds. The question is whether resinOS wants to expose the hci0 directly when it is available on the platform, or prefers to leave this to the user. As an OS user, I would expect hci0 to be exposed directly by the OS.

[agherzan]

In the past we have't done this because the serial device for Bluetooth could have been configured though a dtb overlay. Now we are using udev aliases which are persistent no matter the actual serial device is the Bluetooth working on (serial0/serial1). I think given this, we can start having this provided by the OS. @shaunmulligan @petrosagg Any comments against this? Otherwise, @cskiraly would you be able to push a PR towards resin-raspberrypi?

[petrosagg]

@agherzan why doesn't the presence of the DTB automatically trigger loading of the kernel module and enablement of hci0?

[agherzan]

The hciattach binary attaches a serial device to the Bluez Stack. I don't think you can do that from a dtb automatically.

[petrosagg]

could we use a udev rule then?

[lurch]

Presumably such a udev rule would need to query the loaded DTBs, to determine whether either of the UARTs are connected to the Bluetooth module or not?

[cskiraly]

@shaunmulligan @agherzan Just adding /usr/bin/hciattach /dev/ttyAMA0 bcm43xx 921600 noflow - to https://github.com/resin-os/resin-raspberrypi/blob/master/layers/meta-resin-raspberrypi/recipes-support/resin-init/files/resin-init-board works for me. The only thing I miss is a check for the RPi version, since this is only needed on RRi3.
Is there any reason not to apply this solution?

[cskiraly]

@shaunmulligan @agherzan Just adding /usr/bin/hciattach /dev/ttyAMA0 bcm43xx 921600 noflow - to https://github.com/resin-os/resin-raspberrypi/blob/master/layers/meta-resin-raspberrypi/recipes-support/resin-init/files/resin-init-board works for me. The only thing I miss is a check for the RPi version, since this is only needed on RRi3.
Is there any reason not to apply this solution?

[floion]

We will have ble enabled by default for rpi3 in the near future

[agherzan]

@floion was this change committed?

[floion]

No. Once this gets fixed this ticket will get updated

[curcuz]

@floion any update on this?

[floion]

not yet

[dfsnow]

I'm having the exact issue as @mihalski:

/usr/bin/hciattach /dev/ttyAMA0 bcm43xx 921600 noflow -
bcm43xx_init
Failed to write reset command
Can't initialize device: Success

[floion]

We will have this hopefully fixed in the following week or two

[floion]

Should be fixed by balena-os/balena-raspberrypi#156

[LubergAlexander]

@floion is this already available in production? if not - do you know when?

[floion]

Not yet deployed to production. A conservative estimate would be sometimes next week

[shaunmulligan]

@floion this has now been deployed in resinOS 2.9.3 on the rpi3 correct?

[floion]

Yes @shaunmulligan