Pi3 brcmfmac driver force-loaded on non Pi3

[macmpi]

raspberryconfig.sh statements that creates wifistart.sh unconditionally sets Raspi3-specific driver load commands, which are therefore applied equally for all Raspi at runtime. This force load an irrelevant driver for all Pis (except raspi3): see here lines 496, 518 & al. on PiZero.

Most probably wifistart.sh Raspi3 statement should be created conditionally, or for more generic image deployment, it should execute modprobe commands conditionally (preferred probably).

Any thought?

[macmpi]

Some more thought which may need to be factored-in for RPi3 (seems specific).

[macmpi]

With the advent of Pi Zero W using same wifi chip, condition should not be linked to Pi3 model name, but rather to relevant CYW43438 (BCM43438) chip availability.

[macmpi]

It turns-out that brcmfmac (+ brcmutil marginally) eats significant chunks of memory (and even leaks), so it would really be great NOT to load it on Pis that do not have it (and have limited memory).

So, how can we detect presence of bcm4343x chipset in a Pi?
Anything that can be reliably checked in device-tree or something? (I do not have a Pi3 or PiZeroW at hand to figure this out).
@skikirkwood, it seems you have a Pi3: would you mind exploring /proc/device-tree/ to see if you can cat or ls sth that would reveal some info related to bcm4343x chipset (in sdio part maybe)?

Thanks for any hint, so that we can optimize wifistart.sh.

[skikirkwood]

Hi @macmpi, happy to help, not sure what I'm looking for. Here's some browsing around:

volumio@volumio2:~$ cd /proc/device-tree
volumio@volumio2:/proc/device-tree$ ls
#address-cells chosen compatible interrupt-parent memreserve name serial-number soc system
aliases clocks cpus memory model overrides #size-cells symbols
volumio@volumio2:/proc/device-tree$ ls system
linux,revision linux,serial name
volumio@volumio2:/proc/device-tree$ ls model
model
volumio@volumio2:/proc/device-tree$ cat model
Raspberry Pi 3 Model B Rev 1.2volumio@volumio2:/proc/device-tree$ cat compatible
brcm,bcm2710brcm,bcm2709volumio@volumio2:/proc/device-tree$
volumio@volumio2:/proc/device-tree$ cd soc
volumio@volumio2:/proc/device-tree/soc$ ls
#address-cells fb i2s@7e203000 phandle smi@7e600000 timer
arm-pmu firmware interrupt-controller@7e00b200 power sound uart@7e201000
audio gpio@7e200000 leds pwm@7e20c000 spi@7e204000 uart@7e215040
aux@0x7e215004 gpiomem local_intc ranges spi@7e215080 usb@7e980000
compatible i2c@7e205000 mailbox@7e00b800 rng@7e104000 spi@7e2150C0 vchiq
cprman@7e101000 i2c@7e804000 mmc@7e300000 sdhost@7e202000 syscon@40000000 virtgpio
dma@7e007000 i2c@7e805000 name #size-cells thermal watchdog@7e100000

[macmpi]

Thanks. Trying to find clues of wifi chipset (BCM43430 or BCM43438) within device tree, so that we have a mean to identify the board (different than indirectly by the Pi name).
Could not find it in your trace unfortunately

[macmpi]

@volumio I'm concerned these brcmfmac and brcmutil driver modprobe are relaunched every-time wireless service is restarted (throughwifistart.sh script): this may cause unnecessary driver load (and memory waste at least) for all Pi devices (and sudo /sbin/iw dev wlan0 set power_save off gets duplicated).

If I understand correctly, the original intent of all this is to let connected external wifi dongle eventually take precedence over built-in RPi3 (and other bcm) wifi, correct?
Then we should probably do it somewhere else to make sure wlan0 is properly set, only once, at startup.

[macmpi]

Tried to solve the issue in referred PR #167: thanks for any comment.

(note: baseline wifistart.sh is kept for power save issue on wifi)

[macmpi]

fixed with PR. closing