1

I have a Murata 1FX evaluation kit, and I'm attempting to use it to get WiFi working on a Compute Module 3 (with the CMIO board). It uses the Broadcom BCM43364 chipset, which is similar to what the RPi 3 uses and is supported in theory by the brcmfmac driver. I'm running an up-to-date Raspbian install.

The evaluation kit provides a full-sized SD card breakout (it's meant for i.MX6 boards which have a slot for it), so I've soldered wires to the pads and hooked them up to the CMIO board GPIO, and wired a resistor to pull the WL_REG_ON pin high. I've got it hooked up to GPIO 22-27 (suggested by this thread).

I've added this line to the config.txt file:

dtoverlay=sdio,poll_once=off

The device does seem to get detected during boot, this is dmesg:

$ dmesg | grep mmc1

[    1.963612] mmc1: queuing unknown CIS tuple 0x80 (2 bytes)
[    2.040350] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    2.049793] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    2.060346] mmc1: queuing unknown CIS tuple 0x80 (7 bytes)
[    2.102246] mmc1: queuing unknown CIS tuple 0x80 (3 bytes)
[    2.112453] mmc1: queuing unknown CIS tuple 0x80 (6 bytes)
[    2.339903] mmc1: new high speed SDIO card at address 0001

Trawling through the web, I came across a bug report that suggested a few things to try, so I've run this:

$ cd /sys/class/mmc_host/mmc1/mmc1:0001; find . -type f -exec grep -H . {} \;

./mmc1:0001:1/vendor:0x02d0
./mmc1:0001:1/device:0xa9a4
./mmc1:0001:1/power/runtime_suspended_time:0
grep: ./mmc1:0001:1/power/autosuspend_delay_ms: Input/output error
./mmc1:0001:1/power/runtime_active_time:0
./mmc1:0001:1/power/control:auto
./mmc1:0001:1/power/runtime_status:unsupported
./mmc1:0001:1/class:0x00
./mmc1:0001:1/modalias:sdio:c00v02D0dA9A4
./mmc1:0001:1/uevent:SDIO_CLASS=00
./mmc1:0001:1/uevent:SDIO_ID=02D0:A9A4
./mmc1:0001:1/uevent:MODALIAS=sdio:c00v02D0dA9A4
./power/runtime_suspended_time:0
grep: ./power/autosuspend_delay_ms: Input/output error
./power/runtime_active_time:0
./power/control:auto
./power/runtime_status:unsupported
./type:SDIO
./mmc1:0001:2/vendor:0x02d0
./mmc1:0001:2/device:0xa9a4
./mmc1:0001:2/power/runtime_suspended_time:0
grep: ./mmc1:0001:2/power/autosuspend_delay_ms: Input/output error
./mmc1:0001:2/power/runtime_active_time:0
./mmc1:0001:2/power/control:auto
./mmc1:0001:2/power/runtime_status:unsupported
./mmc1:0001:2/class:0x00
./mmc1:0001:2/modalias:sdio:c00v02D0dA9A4
./mmc1:0001:2/uevent:SDIO_CLASS=00
./mmc1:0001:2/uevent:SDIO_ID=02D0:A9A4
./mmc1:0001:2/uevent:MODALIAS=sdio:c00v02D0dA9A4
./uevent:MMC_TYPE=SDIO
./uevent:MMC_NAME=
./uevent:MODALIAS=mmc:block

The report suggests that it looks like there isn't a driver being loaded, and indeed dmesg | grep brcmfmac gives no results. I tried the following to get the MODALIAS to load the brcmfmac driver, but it doesn't seem to do anything.

$ grep sdio /lib/modules/`uname -r`/modules.alias

alias sdio:c*v02D0dA9A4* brcmfmac    <- added by me
alias sdio:c*v02D0d4373* brcmfmac
alias sdio:c*v02D0d4356* brcmfmac
alias sdio:c*v02D0d4354* brcmfmac
alias sdio:c*v02D0dA9BF* brcmfmac
alias sdio:c*v02D0d4345* brcmfmac
alias sdio:c*v02D0dA9A6* brcmfmac
alias sdio:c*v02D0d4339* brcmfmac
alias sdio:c*v02D0d4335* brcmfmac
alias sdio:c*v02D0dA962* brcmfmac
alias sdio:c*v02D0dA94D* brcmfmac
alias sdio:c*v02D0dA94C* brcmfmac
alias sdio:c*v02D0d4334* brcmfmac
alias sdio:c*v02D0d4330* brcmfmac
alias sdio:c*v02D0d4329* brcmfmac
alias sdio:c*v02D0d4324* brcmfmac
alias sdio:c*v02D0dA887* brcmfmac

It looks like I can't get the brcmfmac driver to load. What else should I be trying to do?

0

I've managed to get it working, by slightly modifying the Linux kernel for Raspbian. I had to modify it to have a definition for SDIO_DEVICE_ID_BROADCOM_43364 with the value 0xA9A4. I'm not really sure where this value is coming from, the Cypress page says it should be 0xA9A6 - but nonetheless it makes the chip work and load the drivers.

Follow the Kernel building guide to obtain the source and set up the build environment. Before compiling, modify the files include/linux/mmc/sdio_ids.h to have the line #define SDIO_DEVICE_ID_BROADCOM_43364 0xa9a4 and drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c to have BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43364) in the appropriate location (see the diff below):

diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
index cd58732..b072fc9 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c
@@ -1098,6 +1098,7 @@ static const struct sdio_device_id brcmf_sdmmc_ids[] = {
        BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43340),
        BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43341),
        BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43362),
+       BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43364),
        BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4335_4339),
        BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_4339),
        BRCMF_SDIO_DEVICE(SDIO_DEVICE_ID_BROADCOM_43430),
diff --git a/include/linux/mmc/sdio_ids.h b/include/linux/mmc/sdio_ids.h
index cdd66a5..0a7abe8 100644
--- a/include/linux/mmc/sdio_ids.h
+++ b/include/linux/mmc/sdio_ids.h
@@ -35,6 +35,7 @@
 #define SDIO_DEVICE_ID_BROADCOM_4335_4339      0x4335
 #define SDIO_DEVICE_ID_BROADCOM_4339           0x4339
 #define SDIO_DEVICE_ID_BROADCOM_43362          0xa962
+#define SDIO_DEVICE_ID_BROADCOM_43364          0xa9a4
 #define SDIO_DEVICE_ID_BROADCOM_43430          0xa9a6
 #define SDIO_DEVICE_ID_BROADCOM_4345           0x4345
 #define SDIO_DEVICE_ID_BROADCOM_43455          0xa9bf

On my setup I have the WL_REG_ON pin pulled high, so the module is not reset when rebooting (i.e. no WiFi after a sudo reboot) - it only works on a hard power off and reboot. I'll change my layout to attach this pin to a GPIO, and control it that way.


I'll also go and check if there's anything like this in the upstream source that will eventually trickle down - if not I'll see about submitting this patch to upstream so that it doesn't always need to be done manually.


Update: The patch has been submitted upstream: https://patchwork.kernel.org/patch/10380047/

I suppose it'll trickle down to some future kernel version, although in the meantime the patch will still need to be manually applied.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.