Open gearhead opened 3 years ago
Update. I went through the package again and re-built a patch from scratch according to the instructions in the archive then fixed the rejected patch pieces and re-built. This also seems to work and is probably a 'cleaner' patch. 0002-brcmfmac-2020-0925.patch.gz The firmware bits still must be installed to get it to work.
@gearhead - Can you update your patch for 5.10.39?
I think this is related to https://github.com/raspberrypi/linux/issues/3619
I am no longer working on this as my immediate problem was resolved by patches to iwd. The way I made that patch file was to follow the instructions for 5.4.18 but on the latest kernel after 'git update' instead of a untar of the zip. :
#1. Download Linux stable kernel source
wget https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/snapshot/linux-5.4.18.tar.gz
tar zxvf linux-5.4.18.tar.gz
#2. In Linux root folder, untar/apply cypress patches with below bash commands
cd linux-5.4.18
tar zxvf cypress-patch*.tar.gz
for i in cypress-patch/*.patch; do patch -p1 < $i; done
#3. Set kernel .config and enable below options, then compile kernel image
# CONFIG_BRCMUTIL=y
# CONFIG_BRCMFMAC=y
# CONFIG_BRCMFMAC_SDIO=y
# CONFIG_BRCMFMAC_PROTO_BCDC=y
# CONFIG_BRCMFMAC_PCIE=y
# CONFIG_BRCMFMAC_PROTO_MSGBUF=y
then created a new patch with git. When I ran this script, many of the patches failed because they were already 'in', but others patched. I did a kernel git update today and then applied the patch to the latest RPi kernel. I made a txt file of the batch script output to show which ones failed due to either already being 'in' or whatever. log The resulting patch is here: 20200925_patch I have not built or tested this patch, just followed the recipe from cypress. Make sure that the .config settings are as listed from cypress (I think they already are for rpi3/4). If this helps development, I am glad to be of assistance. Please post back if this helped. edit: looking through the rejected patches, it may require duplicating my efforts as outlined here then examining each reject to see if something needs to be added/adjusted. tedious. Apparently, I did this back in January, but do not have time right now to do so.
I am no longer working on this as my immediate problem was resolved by patches to iwd.
Interesting that all the kernel, firmware, etc. patches are needed when iwd just works with the existing kernel and firmware. I tried just patching wpa_supp and found that it did not work. Perhaps iwd is the way to go.
@graysky2 I have been running iwd/connman for a while and it is been stable for me. Currently running 5.10.39-2-ARCH. There was recent dev work on IWD that fixed an fmac ap mode issue so it now works. There is so much more info online about wpa_supplicant and wifi setup and so little on iwd that suggesting iwd only for RPi may be premature. Also the trick of putting a wpa config in /boot and rebooting only works with wpa_supplicant, IIRC. This is merely my opinion. If you want me to go through the *.rej files and try again, I can, but it will take me a bit to do so and my edits are merely guesses as to what it should be and not really informed as to what is needed...
Thanks for the reply. I tested iwd
on Arch ARM and it connected fine. I don't want to patch the kernel to make it work with wpa_supp if iwd works as-is.
Well, I reviewed the patch *.rej files and I am pretty sure it is OK. Some of the patches had been applied and the rejects had been applied in other ways as they all appeared to be there. I tested the patch by building an aarch64 kernel for Arch and it builds. I am not running wpa_supplicant, but could test if it is needed.
When installed, it runs and I connect using iwd w/o problems to a 5GHz wpa2 SSID. I have not configured wpa3_sae.
# modinfo brcmfmac
filename: /lib/modules/5.10.39-2-ARCH/kernel/drivers/net/wireless/broadcom/brcm80211/brcmfmac/brcmfmac.ko.gz
license: Dual BSD/GPL
description: Broadcom 802.11 wireless LAN fullmac driver.
author: Broadcom Corporation
firmware: brcm/brcmfmac43012-sdio.bin
firmware: brcm/brcmfmac4373-sdio.bin
firmware: brcm/brcmfmac4359-sdio.bin
firmware: brcm/brcmfmac4356-sdio.bin
firmware: brcm/brcmfmac4354-sdio.bin
firmware: brcm/brcmfmac43456-sdio.bin
firmware: brcm/brcmfmac43455-sdio.bin
firmware: brcm/brcmfmac43436-sdio.bin
firmware: brcm/brcmfmac43430-sdio.bin
firmware: brcm/brcmfmac43430a0-sdio.bin
firmware: brcm/brcmfmac4339-sdio.bin
firmware: brcm/brcmfmac43362-sdio.bin
firmware: brcm/brcmfmac4335-sdio.bin
firmware: brcm/brcmfmac43341-sdio.bin
firmware: brcm/brcmfmac43340-sdio.bin
firmware: brcm/brcmfmac4334-sdio.bin
firmware: brcm/brcmfmac4330-sdio.bin
firmware: brcm/brcmfmac4329-sdio.bin
firmware: brcm/brcmfmac43241b5-sdio.bin
firmware: brcm/brcmfmac43241b4-sdio.bin
firmware: brcm/brcmfmac43241b0-sdio.bin
firmware: brcm/brcmfmac43143-sdio.bin
firmware: brcm/brcmfmac4373.bin
firmware: brcm/brcmfmac43569.bin
firmware: brcm/brcmfmac43242a.bin
firmware: brcm/brcmfmac43236b.bin
firmware: brcm/brcmfmac43143.bin
alias: usb:v04B4p0BDCd*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0A5Cp0BDCd*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v043Ep3101d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v04B4pBD29d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v13B1p0039d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0A5CpBD27d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0A5CpBD1Fd*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0A5CpBD17d*dc*dsc*dp*ic*isc*ip*in*
alias: usb:v0A5CpBD1Ed*dc*dsc*dp*ic*isc*ip*in*
alias: sdio:c*v02D0d4355*
alias: sdio:c*v02D0dA804*
alias: sdio:c*v02D0d4373*
alias: sdio:c*v02D0d4359*
alias: sdio:c*v02D0d4356*
alias: sdio:c*v02D0d4354*
alias: sdio:c*v02D0dA9BF*
alias: sdio:c*v02D0d4345*
alias: sdio:c*v02D0dA9A6*
alias: sdio:c*v02D0d4339*
alias: sdio:c*v02D0d4335*
alias: sdio:c*v02D0dA9A4*
alias: sdio:c*v02D0dA962*
alias: sdio:c*v02D0dA94D*
alias: sdio:c*v02D0dA94C*
alias: sdio:c*v02D0d4334*
alias: sdio:c*v02D0d4330*
alias: sdio:c*v02D0d4329*
alias: sdio:c*v02D0d4324*
alias: sdio:c*v02D0dA887*
depends: brcmutil,cfg80211
intree: Y
name: brcmfmac
vermagic: 5.10.39-2-ARCH SMP preempt mod_unload aarch64
parm: txglomsz:Maximum tx packet chain size [SDIO] (int)
parm: debug:Level of debug output (int)
parm: p2pon:Enable legacy p2p management functionality (int)
parm: feature_disable:Disable features (int)
parm: alternative_fw_path:Alternative firmware path (string)
parm: fcmode:Mode of firmware signalled flow control (int)
parm: roamoff:Do not use internal roaming engine (int)
parm: iapp:Enable partial support for the obsoleted Inter-Access Point Protocol (int)
parm: ignore_probe_fail:always succeed probe for debugging (int)
Thanks for confirming. I tried just patching wpa_supplicant (using current rpi-5.10 kernel) on RPi4B and connection to pure WPA3 was not possible. In contrast, using iwd on the very same box, connected to pure WPA3. I am concluding the issue lies with wpa_supplicant.
No issue on my end:
/etc/wpa_supplicant/wpa_supplicant.conf
:
update_config=1
network={
ssid="ssid"
key_mgmt=WPA-PSK-SHA256
psk=psk
ieee80211w=2
}
I am trying to get the RPi with onboard wifi to play nice with iwd and connman. The latest driver in the tree is a couple years old and does not like to reconnect if the radio on the router is restarted. It will mostly reconnect if the router is rebooted, but sometimes just sits there. Last year, cypress provided at least 2 updates to this module but the archive they provided did not lend itself to immediate insertion as a patch to the current RPi kernel tree. I spent some time on it yesterday and got it to compile and load on the kernel I am running. It connects to my wpa2 Wifi and so far seems to work fine. The latest update I found was from 20200925: https://community.cypress.com/t5/Resource-Library/Cypress-Linux-WiFi-Driver-Release-FMAC-2020-09-25/ta-p/251089
The patch I used to get it to build with the kernel is attached.
To get the module to work, the firmware patches from the same archive must be used. Copy the firmware files and rename the text file from the broadcom firmware dir and build and install the module. I put the cyfmac43430-sdio. and cyfmac43455-sdio. files from the archive in the firmware directory (I use Arch, so it is /usr/lib/firmware/cypress/ I think RaspiOS is different). When I rebooted the Pi it loaded firmware and the module and connected to my SSID! Still testing to see if the 43430 works similarly. I did need to copy the broadcom txt file from the broadcom firmware directory to the cypress firmware directory and rename it as well.
-rw-r--r-- 1 root root 1947 Jul 17 2019 brcmfmac43455-sdio.txt
copied and renamed '-rw-r--r-- 1 root root 1947 Jul 17 2019 cyfmac43455-sdio.txt'this is the modinfo:
0001-brcmfmac-2020-0925.patch.gz
Is there a reason this is not in the kernel tree, yet? It seems to support wpa3 and 4 way handshake. I have not yet tested to see if it will reconnect when the SSID radio is re-started, the problem I am trying to resolve, but will do today.