Add Wifi Firmware for Raspbery Pi

[darkdrgn2k]

Still need to clean up unneeded firmware, any suggestions on how to gut it

IE brcm is 4 megs but only ~370k is needed (brcmfmac43430-sdio.bin and brcmfmac43430-sdio.txt)

root@ramdisk-0a27945f:~# ls -lah /lib/firmware/brcm/
total 4.2M
drwxr-xr-x 2 root root  320 Aug  9  2017 .
drwxr-xr-x 5 root root  480 Jan 23  2018 ..
-rw-r--r-- 1 root root  94K Aug  9  2017 bcm43xx-0.fw
-rw-r--r-- 1 root root  180 Aug  9  2017 bcm43xx_hdr-0.fw
-rw-r--r-- 1 root root 377K Aug  9  2017 brcmfmac43143-sdio.bin
-rw-r--r-- 1 root root 388K Aug  9  2017 brcmfmac43143.bin
-rw-r--r-- 1 root root 446K Aug  9  2017 brcmfmac43241b0-sdio.bin
-rw-r--r-- 1 root root 395K Aug  9  2017 brcmfmac43241b4-sdio.bin
-rw-r--r-- 1 root root 248K Aug  9  2017 brcmfmac4329-sdio.bin
-rw-r--r-- 1 root root 217K Aug  9  2017 brcmfmac4330-sdio.bin
-rw-r--r-- 1 root root 441K Aug  9  2017 brcmfmac4334-sdio.bin
-rw-r--r-- 1 root root 556K Aug  9  2017 brcmfmac4335-sdio.bin
-rw-r--r-- 1 root root 215K Aug  9  2017 brcmfmac43362-sdio.bin
-rw-r--r-- 1 root root 364K Aug  9  2017 brcmfmac43430-sdio.bin
-rw-r--r-- 1 root root 1014 Aug  9  2017 brcmfmac43430-sdio.txt
-rw-r--r-- 1 root root 496K Aug  9  2017 brcmfmac4354-sdio.bin

[darkdrgn2k]

Maybe there is a better way to do this. Here is one way to remove unneeded brcm drivers saving about 3 megs

find lib/firmware/brcm -maxdepth 1 -type f ! -name "brcmfmac43430-sdio.*" -delete; \

Commit: 68297de998e5ebf7b707369e892b1efce7ee97b3

[benhylau]

Just built this branch and confirmed that the hostap is working on a Raspberry Pi 3. Internet access for connected clients is working exiting through the ethernet connection.

Consistent with what @darkdrgn2k has reported, and expectedly from 85-wlan-mesh.network, when I have the following USB adapters plugged in:

• TP-Link TL-WN722N v1 (ath9k_htc) gets brought up in Access Point mode
• Toplinkst TOP-GS07 (rt2800usb) gets brought up in Mesh Point mode

How does @hamishcoleman feel about adding an extra file in debian-minimal-builder to bring up ath9k_htc as Mesh Point as well? This is in the short-term, as all these files will be held outside of debian-minimal-builder in some node profile eventually.

Since this is now working for Raspberry Pi 3, and assuming it did not break Raspberry Pi 2 and is expected to work with Raspberry Pi 1, shall we rename the target raspberrypi2 -> raspberrypi?

If we do this, ~it means we will support less devices, so I am leaning towards not doing this to save the 3 MB that we currently don't need.~ (Edit: Actually no, I think I misread this. It looks like there is no need for the other files. Do you know what those are for?)

find lib/firmware/brcm -maxdepth 1 -type f ! -name "brcmfmac43430-sdio.*" -delete; \

[darkdrgn2k]

If we do this, it means we will support less devices, so I am leaning towards not doing this to save the 3 MB that we currently don't need. (Edit: Actually no, I think I misread this. It looks like there is no need for the other files. Do you know what those are for?)

Thats correct, the package that holds the firmware is a general broadcom package including firmware for most broadcom devices. The only one we need for RPI3 is the are those two file. RPI 2 and 1 Do not use any.

We COULD spin out a new board setup for rpi 3 but at some point it seems silly to do, Maybe at some point in the future we can do a openwrt like installer that you can turn on or of certain boards but for now i think were way to far from that point.

I also think hamish will refactor things a bit beter at some point in the future.

How does @hamishcoleman feel about adding an extra file in debian-minimal-builder to bring up ath9k_htc as Mesh Point as well? This is in the short-term, as all these files will be held outside of debian-minimal-builder in some node profile eventually.

I'm thinking production here - I'm wondering at what point we need to look at separate the CONFIG files settings from the base. I'm not a fan of having a blanket "this drive is mesh point" setup because what if you plug in two mesh points, all of a sudden you get a loop between the two adapters.

Correct me if I'm wrong but i cant think of a SINGLE reason why you would want to run TWO access points with the same settings, or TWO mesh points with the same settings but both would yield node problems.

Perhaps what we can do is do a "first boot" script that will create a config directory if one is not found and prep some config files the sd card using mac addresses? thoughts?

Since this is now working for Raspberry Pi 3, and assuming it did not break Raspberry Pi 2 and is expected to work with Raspberry Pi 1, shall we rename the target raspberrypi2 -> raspberrypi?

I have a pi1 ill run the node and see what happens to confirm.

[hamishcoleman]

I cannot recommend renaming the subdir - it clearly will never work for all raspberry pi devices. Perhaps the documentation to that fact inside boards/raspberrypi2/Makefile should be moved in to a boards/raspberrypi2/README file

[hamishcoleman]

wrt the ath9k_htc stuff, I have not had a chance to look or think about it - propose a patch, then its clearer