RaspberryPi 3 Compatibility With RedBear IoT pHAT


#1

Nb. I updated the post to reflect the same content as what I posted on the raspberrypi forums. https://www.raspberrypi.org/forums/viewtopic.php?f=45&t=185371

G’day Forum Members,

I bought the RedBear IoT pHAT (https://redbear.cc/product/iot-phat.html) to use with a Raspberry Pi 3 (RPi3). I wanted to use the combination for a side project, where I route a mobile phones traffic through the RedBear IoT pHAT WLAN (my access point) and forward it out of the RPi3´s onboard WLAN that is connected to an open access point.

Setup

I am currently running Raspbian Jessie with Pixel April 2017:

cat /proc/version

Linux version 4.9.24-v7+ ([email protected]) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #993 SMP Wed Apr 26 18:01:23 BST 2017

My RedBear IoT pHAT has the latest firmware:

more /proc/device-tree/hat/product

IoT pHAT w/eep_v0.4

Background

I note on RedBear’s GitHub page (https://github.com/redbear/IoT_pHAT) they do NOT/NOT specifically mention the RPi3, but they say:

The IoT pHAT will also work on other 40-pin RPi boards such as RPi Model A+ and RPi 2

I came across this post on the raspberrypi forums (https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=180624&p=1148351&hilit=iot+phat+rpi3#p1148351) where ‘summersab’ said s/he reached out to RedBear and reported this as their response:

Unfortunately, we do not support using our IoT pHAT together with the built-in WiFi of Pi3 or Zero W. We are using the same RF chipset as them.

Looking through RedBear’s IoT pHAT forum threads I originally found this post (IoT pHAT with RPi3) which suggested that the onboard WLAN will be deactivated. It’s not deactivated as such, but there is a clash with the devices as reported by dmesg:

dmesg | grep brcmfmac

[ 4.422477] usbcore: registered new interface driver brcmfmac
[ 4.700169] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: May 27 2016 00:13:38 version 7.45.41.26 (r640327) FWID 01-df77e4a7
[ 4.719978] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[ 5.533067] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[ 8.972004] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
[ 8.972020] brcmfmac: brcmf_add_if: ignore IF event
[ 8.976716] brcmfmac: power management disabled
[ 9.493332] brcmfmac: brcmf_add_if: ERROR: netdev:wlan0 already exists
[ 9.493350] brcmfmac: brcmf_add_if: ignore IF event

Observations/Troubleshooting

When the IoT pHAT is connected, it would appear that it is always the device that comes up everytime. This is confirmed through checking the MAC address.

Noting each WLAN has a different MAC address, I thought I would try assigning them different interface addresses using udev rules:

vi /etc/udev/rules.d/70-persistent-net.rules

ACTION==“add”, SUBSYSTEM==“net”, DRIVER==“brcmfmac”, ATTR{address}==“b8:27:eb:XX:XX:XX”, NAME=“wlan0”
ACTION==“add”, SUBSYSTEM==“net”, DRIVER==“brcmfmac”, ATTR{address}==“44:2c:05:XX:XX:XX”, NAME=“wlan1”

I believe it pretty much does the same as udev, but I also tried using systemd settings:

vi /etc/systemd/network/25-wireless.link

[MATCH]
MACAddress=b8:27:eb:XX:XX:XX
Driver=brcmfmac
[LINK]
Name=wlan0

[MATCH]
MACAddress=44:2c:05:XX:XX:XX
Driver=brcmfmac
[LINK]
Name=wlan1

However this did not bring both up.

I also used udevadm to do a compare of their entries for uniqueness:

udevadm info --attribute-walk -p /sys/class/net/wlan0

Onboard wlan

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

looking at device ‘/devices/platform/soc/3f300000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/net/wlan0’:
KERNEL==“wlan0”
SUBSYSTEM==“net”
DRIVER==""
ATTR{addr_assign_type}==“0”
ATTR{addr_len}==“6”
ATTR{address}==“b8:27:eb:XX:XX:XX”
ATTR{broadcast}==“ff:ff:ff:ff:ff:ff”
ATTR{carrier}==“0”
ATTR{carrier_changes}==“1”
ATTR{dev_id}==“0x0”
ATTR{dev_port}==“0”
ATTR{dormant}==“0”
ATTR{flags}==“0x1003”
ATTR{gro_flush_timeout}==“0”
ATTR{ifalias}==""
ATTR{ifindex}==“3”
ATTR{iflink}==“3”
ATTR{link_mode}==“1”
ATTR{mtu}==“1500”
ATTR{netdev_group}==“0”
ATTR{operstate}==“down”
ATTR{proto_down}==“0”
ATTR{tx_queue_len}==“1000”
ATTR{type}==“1”

looking at parent device ‘/devices/platform/soc/3f300000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1’:
KERNELS==“mmc1:0001:1”
SUBSYSTEMS==“sdio”
DRIVERS==“brcmfmac_sdio”
ATTRS{class}==“0x00”
ATTRS{device}==“0xa9a6”
ATTRS{vendor}==“0x02d0”

looking at parent device ‘/devices/platform/soc/3f300000.mmc/mmc_host/mmc1/mmc1:0001’:
KERNELS==“mmc1:0001”
SUBSYSTEMS==“mmc”
DRIVERS==""
ATTRS{type}==“SDIO”

looking at parent device ‘/devices/platform/soc/3f300000.mmc/mmc_host/mmc1’:
KERNELS==“mmc1”
SUBSYSTEMS==“mmc_host”
DRIVERS==""

looking at parent device ‘/devices/platform/soc/3f300000.mmc’:
KERNELS==“3f300000.mmc”
SUBSYSTEMS==“platform”
DRIVERS==“mmc-bcm2835”
ATTRS{driver_override}=="(null)"

looking at parent device ‘/devices/platform/soc’:
KERNELS==“soc”
SUBSYSTEMS==“platform”
DRIVERS==""
ATTRS{driver_override}=="(null)"

looking at parent device ‘/devices/platform’:
KERNELS==“platform”
SUBSYSTEMS==""
DRIVERS==""

RedBear IoT pHAT

Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.

looking at device ‘/devices/platform/soc/3f300000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/net/wlan0’:
KERNEL==“wlan0”
SUBSYSTEM==“net”
DRIVER==""
ATTR{addr_assign_type}==“0”
ATTR{addr_len}==“6”
ATTR{address}==“44:2c:05:XX:XX:XX”
ATTR{broadcast}==“ff:ff:ff:ff:ff:ff”
ATTR{carrier}==“1”
ATTR{carrier_changes}==“46”
ATTR{dev_id}==“0x0”
ATTR{dev_port}==“0”
ATTR{dormant}==“0”
ATTR{flags}==“0x1003”
ATTR{gro_flush_timeout}==“0”
ATTR{ifalias}==""
ATTR{ifindex}==“3”
ATTR{iflink}==“3”
ATTR{link_mode}==“1”
ATTR{mtu}==“1500”
ATTR{netdev_group}==“0”
ATTR{operstate}==“up”
ATTR{proto_down}==“0”
ATTR{tx_queue_len}==“1000”
ATTR{type}==“1”

looking at parent device ‘/devices/platform/soc/3f300000.mmc/mmc_host/mmc1/mmc1:0001/mmc1:0001:1’:
KERNELS==“mmc1:0001:1”
SUBSYSTEMS==“sdio”
DRIVERS==“brcmfmac_sdio”
ATTRS{class}==“0x00”
ATTRS{device}==“0xa9a6”
ATTRS{vendor}==“0x02d0”

looking at parent device ‘/devices/platform/soc/3f300000.mmc/mmc_host/mmc1/mmc1:0001’:
KERNELS==“mmc1:0001”
SUBSYSTEMS==“mmc”
DRIVERS==""
ATTRS{type}==“SDIO”

looking at parent device ‘/devices/platform/soc/3f300000.mmc/mmc_host/mmc1’:
KERNELS==“mmc1”
SUBSYSTEMS==“mmc_host”
DRIVERS==""

looking at parent device ‘/devices/platform/soc/3f300000.mmc’:
KERNELS==“3f300000.mmc”
SUBSYSTEMS==“platform”
DRIVERS==“mmc-bcm2835”
ATTRS{driver_override}=="(null)"

looking at parent device ‘/devices/platform/soc’:
KERNELS==“soc”
SUBSYSTEMS==“platform”
DRIVERS==""
ATTRS{driver_override}=="(null)"

looking at parent device ‘/devices/platform’:
KERNELS==“platform”
SUBSYSTEMS==""
DRIVERS==""

A work colleaugue suggested modifying my persistent rules to something other than wlan0 as it might be expecting wlan0. I updated it to wifi0 and wifi1 however still get the same effect with my dmesg error:

[ 4.495496] usbcore: registered new interface driver brcmfmac
[ 4.757582] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: May 27 2016 00:13:38 version 7.45.41.26 (r640327) FWID 01-df77e4a7
[ 4.778553] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[ 5.441063] brcmfmac_sdio mmc1:0001:1 wifi1: renamed from wlan0
[ 5.548324] brcmfmac: brcmf_cfg80211_reg_notifier: not a ISO3166 code
[ 9.012857] brcmfmac: brcmf_add_if: ERROR: netdev:wifi1 already exists
[ 9.012876] brcmfmac: brcmf_add_if: ignore IF event
[ 9.017502] brcmfmac: power management disabled
[ 9.455715] brcmfmac: brcmf_add_if: ERROR: netdev:wifi1 already exists
[ 9.455733] brcmfmac: brcmf_add_if: ignore IF event

Is there anyone on the forum that might be able to suggest other things that I should be looking into. What I do not understand is why they would both utilise the same device path? I would have thought that these would be different.

Thank you for your time and assistance responding to my post.


Using pHAT for dual Bluetooth on RPi3
#2

I too would be interested in Pi 3 or Pi Zero W builtin WiFi compatibility. I bought one hoping to have 2 wlan interfaces on a Pi Zero W.