search

simonvanderveldt / norns-image

5 stars 2 forks source link

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

Closed simonvanderveldt closed 4 years ago

simonvanderveldt commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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): https://github.com/raspberrypi/linux/issues/2105

Does that mean anything in context here?

simonvanderveldt commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

Found the culprit

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

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 https://github.com/monome/linux/pull/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 commented 4 years ago

Wow - great work tracking that down!

simonvanderveldt commented 4 years ago

Wow - great work tracking that down!

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