Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raspberry Pi 3 and later onboard Wi-Fi is not working #35

Closed
simonvanderveldt opened this issue Nov 18, 2019 · 8 comments
Closed

Raspberry Pi 3 and later onboard Wi-Fi is not working #35

simonvanderveldt opened this issue Nov 18, 2019 · 8 comments
Assignees
Milestone

Comments

@simonvanderveldt
Copy link
Owner

@simonvanderveldt simonvanderveldt commented Nov 18, 2019

For some reason the onboard onboard Wi-Fi for the Raspberry Pi 3 and later isn't working.
Need to figure out why and fix it.

@simonvanderveldt simonvanderveldt added this to the 0.1.0 milestone Nov 18, 2019
@simonvanderveldt simonvanderveldt self-assigned this Nov 18, 2019
@simonvanderveldt simonvanderveldt changed the title Raspberry Pi 3 and later onboard Wi-Fi driver is missing Raspberry Pi 3 and later onboard Wi-Fi is not working Dec 21, 2019
@simonvanderveldt
Copy link
Owner Author

@simonvanderveldt simonvanderveldt commented Dec 21, 2019

The driver used is brcmfmac. It's included in the kernel, but

  1. For some reason it's not loaded
  2. When manually loading it using modprobe brcmfmac nothing really happens apart from the following message in the kernel log [ 5495.912975] usbcore: registered new interface driver brcmfmac.

So it seems like that for some reason the device itself isn't there.

@simonvanderveldt
Copy link
Owner Author

@simonvanderveldt simonvanderveldt commented Dec 21, 2019

Some more info. The built in Wi-Fi chips are connected to SD1 according to this
https://github.com/raspberrypi/documentation/blob/master/hardware/raspberrypi/bootmodes/gpio.md#boot-flow

And SD1 is an alt3 mode for pins 34 35 36 37 38 39, see
https://github.com/raspberrypi/linux/blob/rpi-4.19.y/arch/arm/boot/dts/bcm2710-rpi-3-b.dts#L49

It seems like these are SoC pins which are not exposed on the RPis GPIO header so it seems unlikely there's a collision with the pins of the shield.

Also the SDIO bus shows as empty on the device

# ls -ahl /sys/bus/sdio/devices/
total 0
drwxr-xr-x 2 root root 0 Feb 14  2019 .
drwxr-xr-x 4 root root 0 Feb 14  2019 ..

I'm going to compare this vs Raspbian and see what/where the differences are.

@okyeron
Copy link

@okyeron okyeron commented Dec 22, 2019

A couple of curious data points...

I got a shield up and running tonight and wanted to see if I could make one of my Fates installs work with it (stock buster-lite with changes for display, etc.). I only changed overlays for monome-snd, buttons-encoders and the display. After first boot with the shield, wifi stopped working (which worked just fine prior to this).

After disconnecting the shield, I needed to go to nmtui and reconnect to wifi.

So then just got the shield image and poked around on that.

I did find this reference which is not entirely helpful (to me):
raspberrypi/linux#2105

Does that mean anything in context here?

@simonvanderveldt
Copy link
Owner Author

@simonvanderveldt simonvanderveldt commented Dec 22, 2019

@okyeron Tbh I'm not entirely sure what's causing the wifi to not work yet.
Did a bunch more investigation today, it seems like there's no collision with GPIO pins between the shield and the wlan chip, which is connected to SD1 via pins 34-39. It seems like these pins aren't exposed on the Raspberry Pi's header. The highest number GPIO pin I could find on the header is 26, see image below from https://pinout.xyz/
image
Assuming that's correct there's no hardware issue with double pin usage. I also booted the RPi without the shield connected and the wifi still didn't work, which seems to confirm this.

Then I removed all our dts/overlay config from config.txt but the wifi chip still didn't work/activate when loading the module. So I'm starting to suspect that our kernel is somehow the cause of this issue. This doesn't entirely seem to match with your experiences though. Or did you change the kernel as well?

Also, I just did two different buildroot builds for stock Rapsberry Pi 3 one with kernel 4.19 (buildroot 2019.08.3) and one with kernel 4.9 (buildroot 2018.02.12). Both worked fine.
This again seems to hint at our kernel being the culprit. I'll start bisecting our changes to the kernel to figure out where the issue is coming from.

@simonvanderveldt
Copy link
Owner Author

@simonvanderveldt simonvanderveldt commented Dec 23, 2019

Some more tests done today. Using our norns config with the stock (ie default for the Raspberry Pi 3 buildroot config) kernel and the bcm2709 defconfig works, as does our kernel with the bcm2709 defconfig.
This seems to suggest that it's caused by our kernel config. Will take a bit of time to figure out where the problem is, but seems doable :)

@simonvanderveldt
Copy link
Owner Author

@simonvanderveldt simonvanderveldt commented Dec 24, 2019

Found the culprit

There are 2 MMC/SDIO interfaces on the Raspberry Pi 3/BCM2835 and both are supported by two mutually exclusive drivers:

  • Broadcom SDHOST interface, used for SD card
    • Upstream driver: CONFIG_MMC_BCM2835/bcm2835.ko
    • Downstream driver: CONFIG_MMC_BCM2835_SDHOST/bcm2835-sdhost.ko
  • Arasan MMC, used for onboard Wi-Fi
    • Upstream driver CONFIG_MMC_SDHCI_IPROC/sdhci-iproc.ko
    • Downstream driver CONFIG_MMC_BCM2835_MMC/bcm2835-mmc.ko

Upstream means the main Linux kernel, downstream means the Raspberry Pi modified/specific kernel.
The downstream drivers are modified for the Raspberry Pi by the Raspberry Pi devs and are the ones that generally should be used because they should offer better performance.

Our kernel config had the upstream SDHOST driver enabled, which can be removed and it had no Arasan MMC drivers enabled at all. So the fix is to enable the downstream Arasan MMC driver using CONFIG_MMC_BCM2835_MMC.
This is fixed in this PR in our kernel repo monome/linux#43

For more info see
https://lb.raspberrypi.org/forums/viewtopic.php?p=1404116&sid=d6da13c52fd86e4624d9687604c0b9e0#p1404116
The important bit from that thread is the following:

Each of the two BCM2835 MMC/SD interfaces has two drivers in the downstream tree. For the Arasan MMC interface we have "sdhci-iproc" (upstream), and "bcm2835-mmc" (downstream), while for the Broadcom SDHOST interface there is "bcm2835" (upstream) and "bcm2835-sdhost" (downstream). These drivers could be consolidated so that, assuming we still want to keep the dowstream-specific features (mainly overclocking support and Device-Tree controlled debugging), the downstream drivers becomes patched versions of the standard upstream ones.

@okyeron
Copy link

@okyeron okyeron commented Dec 24, 2019

Wow - great work tracking that down!

@simonvanderveldt
Copy link
Owner Author

@simonvanderveldt simonvanderveldt commented Dec 24, 2019

Wow - great work tracking that down!

Yeah, was a bit of a journey 😛
Glad it's fixed now :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

2 participants