| Message ID | 5A8FE4D9.80608@broadcom.com (mailing list archive) |
|---|---|
| State | RFC |
| Delegated to: | Kalle Valo |
| Headers | show |
On Fri, Feb 23, 2018 at 12:54 PM, Arend van Spriel <arend.vanspriel@broadcom.com> wrote: > Yup. Windows firmware talks NDIS. If you run 'strings 4345r6rtecdc.bin | > tail -1' you can see the firmware build target and it likely has 'ndis' in > it. 43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf Yes, ndis. So no easy way to run the same firmware on the 2 OSes. > Now are you using BT as well on this device? Another suggestion I got is to > disable transmit beamforming which brcmfmac enables by default. Not sure if > this device supports it, but could you try the patch below. Thanks for the ideas. I had already tried with the bluetooth disabled - no change there. Also reproduced the problem after applying your patch. Daniel
On 2/23/2018 2:49 PM, Daniel Drake wrote: > On Fri, Feb 23, 2018 at 12:54 PM, Arend van Spriel > <arend.vanspriel@broadcom.com> wrote: >> Yup. Windows firmware talks NDIS. If you run 'strings 4345r6rtecdc.bin | >> tail -1' you can see the firmware build target and it likely has 'ndis' in >> it. Hi Daniel, Bit late response. Sorry. > 43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf > > Yes, ndis. So no easy way to run the same firmware on the 2 OSes. Indeed. I could try building nearly same firmware target. Can you provide the firmware version as well. Now reading over your orignal email again: > If I place both antenna terminals inside the Linux MiniPC case, the > Linux pings are bad but the Windows pings are fine. > > If I place both antenna terminals inside the Windows MiniPC case, it > is the same: Linux pings are bad, but the Windows pings are fine. > > And when the Linux antenna is placed outside of both cases, the Linux > pings are fine. I've repeated these tests a handful of times in quick > succession to make sure that I'm not going crazy and that this is not > a case of the problem intermittency causing misleading results. These > findings appear very solid. So it picks up something in the PC. Some sources of interference that I have seen before are USB3 and HDMI. Maybe try to shield those if present and see if that helps. The nvram contains sensitivity parameters, but as you stated you are using the same nvram for windows and linux for now we can rule it out for debugging the issue. Regards, Arend
On Thu, Mar 8, 2018 at 2:47 AM, Arend van Spriel <arend.vanspriel@broadcom.com> wrote: > On 2/23/2018 2:49 PM, Daniel Drake wrote: >> >> On Fri, Feb 23, 2018 at 12:54 PM, Arend van Spriel >> <arend.vanspriel@broadcom.com> wrote: >>> >>> Yup. Windows firmware talks NDIS. If you run 'strings 4345r6rtecdc.bin | >>> tail -1' you can see the firmware build target and it likely has 'ndis' >>> in >>> it. > > > Hi Daniel, > > Bit late response. Sorry. > >> >> 43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf >> >> Yes, ndis. So no easy way to run the same firmware on the 2 OSes. > > > Indeed. I could try building nearly same firmware target. Can you provide > the firmware version as well. > > Now reading over your orignal email again: > >> If I place both antenna terminals inside the Linux MiniPC case, the >> Linux pings are bad but the Windows pings are fine. >> >> If I place both antenna terminals inside the Windows MiniPC case, it >> is the same: Linux pings are bad, but the Windows pings are fine. >> >> And when the Linux antenna is placed outside of both cases, the Linux >> pings are fine. I've repeated these tests a handful of times in quick >> succession to make sure that I'm not going crazy and that this is not >> a case of the problem intermittency causing misleading results. These >> findings appear very solid. > > So it picks up something in the PC. Some sources of interference that I have > seen before are USB3 and HDMI. Maybe try to shield those if present and see > if that helps. The nvram contains sensitivity parameters, but as you stated > you are using the same nvram for windows and linux for now we can rule it > out for debugging the issue. > Hi Daniel, I'll jump in here too... Did you check the Bluetooth? I don't know if this chip has it or if it's an independent chip on this board, but if Linux is leaving it powered up but not properly configured you could have issues. And in some designs, the BT and WiFi will share a single antenna. Note that I'm not saying you've configured BT to run, I'm actually suggesting that the pin that enables it is on, but you might not be loading the BT drivers and firmware and so the thing is just in a wonky uninitialized state. Or you do have it enabled and should try turning it off. Either way. And WiFi/BT coex has always been a bit of a problem (speaking generally, I don't know the status with this particular chip) in Linux. I see WiFi and BT interfering with each other frequently in my testing setups with my dev boards. Often I can magically make problems go away by simply pulling the enable line high (which is "off"). - Steve -- Steve deRosier Cal-Sierra Consulting LLC https://www.cal-sierra.com/
On 3/8/2018 4:54 PM, Steve deRosier wrote: > On Thu, Mar 8, 2018 at 2:47 AM, Arend van Spriel > <arend.vanspriel@broadcom.com> wrote: >> On 2/23/2018 2:49 PM, Daniel Drake wrote: >>> >>> On Fri, Feb 23, 2018 at 12:54 PM, Arend van Spriel >>> <arend.vanspriel@broadcom.com> wrote: >>>> >>>> Yup. Windows firmware talks NDIS. If you run 'strings 4345r6rtecdc.bin | >>>> tail -1' you can see the firmware build target and it likely has 'ndis' >>>> in >>>> it. >> >> >> Hi Daniel, >> >> Bit late response. Sorry. >> >>> >>> 43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf >>> >>> Yes, ndis. So no easy way to run the same firmware on the 2 OSes. >> >> >> Indeed. I could try building nearly same firmware target. Can you provide >> the firmware version as well. >> >> Now reading over your orignal email again: >> >>> If I place both antenna terminals inside the Linux MiniPC case, the >>> Linux pings are bad but the Windows pings are fine. >>> >>> If I place both antenna terminals inside the Windows MiniPC case, it >>> is the same: Linux pings are bad, but the Windows pings are fine. >>> >>> And when the Linux antenna is placed outside of both cases, the Linux >>> pings are fine. I've repeated these tests a handful of times in quick >>> succession to make sure that I'm not going crazy and that this is not >>> a case of the problem intermittency causing misleading results. These >>> findings appear very solid. >> >> So it picks up something in the PC. Some sources of interference that I have >> seen before are USB3 and HDMI. Maybe try to shield those if present and see >> if that helps. The nvram contains sensitivity parameters, but as you stated >> you are using the same nvram for windows and linux for now we can rule it >> out for debugging the issue. >> > > Hi Daniel, > > I'll jump in here too... > > Did you check the Bluetooth? I don't know if this chip has it or if > it's an independent chip on this board, but if Linux is leaving it > powered up but not properly configured you could have issues. And in > some designs, the BT and WiFi will share a single antenna. Note that > I'm not saying you've configured BT to run, I'm actually suggesting > that the pin that enables it is on, but you might not be loading the > BT drivers and firmware and so the thing is just in a wonky > uninitialized state. Or you do have it enabled and should try turning > it off. Either way. > > And WiFi/BT coex has always been a bit of a problem (speaking > generally, I don't know the status with this particular chip) in > Linux. I see WiFi and BT interfering with each other frequently in my > testing setups with my dev boards. Often I can magically make problems > go away by simply pulling the enable line high (which is "off"). Thanks, Steve Disabling BT was indeed suggested, but indeed pulling BT_REG_ON high will ensure there is nothing active on BT side. In BT the firmware is generally speaking on-chip with possibility to download firmware patch to the device. However, if no driver does hci initialization I would expect BT to be passive/silent, but I guess your magic proves otherwise ;-) Regards, Arend
On Thu, Mar 8, 2018 at 9:54 AM, Steve deRosier <derosier@gmail.com> wrote: > Did you check the Bluetooth? I don't know if this chip has it or if > it's an independent chip on this board, but if Linux is leaving it > powered up but not properly configured you could have issues. I had already disabled it via hciconfig, without any effect on the problem. Based on your suggestion I also checked BT_REG_ON, which was not being affected by hciconfig. On AP6255 I believe it is active high, so I brought it low to disable bluetooth, confirmed with a scope, and the problem is still there. Thanks for the suggestion anyway! Daniel
On Thu, Mar 8, 2018 at 4:47 AM, Arend van Spriel <arend.vanspriel@broadcom.com> wrote: >> 43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf >> >> Yes, ndis. So no easy way to run the same firmware on the 2 OSes. > > Indeed. I could try building nearly same firmware target. Can you provide > the firmware version as well. Full string is: 43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf Version: 7.45.87.0 CRC: 7cb2470e Date: Thu 2016-04-21 22:31:44 PDT Ucode Ver: 1043.2070 FWID: 01-f68ec182 If you could build that config but for Linux instead of ndis I would love to try it. Also, here is the string for the current one in linux-firmware: 43455c0-roml/sdio-ag-p2p-pno-aoe-pktfilter-keepalive-mchan-pktctx-proptxstatus-ampduhostreorder-lpc-pwropt-txbf-wnm-okc-ccx-ltecx-wfds-wl11u-mfp-tdls-ve Version: 7.45.18.0 CRC: d7226371 Date: Sun 2015-03-01 07:31:57 PST Ucode Ver: 1026.2 FWID: 01-6a2c8ad4 I note that the Version and UcodeVer in the linux-firmware version are lower than the windows one. If it's possible to also rebuild the linux-firmware config but with those newer versions (or even the latest, if there is something newer), I will test that too. > So it picks up something in the PC. Some sources of interference that I have > seen before are USB3 and HDMI. Maybe try to shield those if present and see > if that helps. The nvram contains sensitivity parameters, but as you stated > you are using the same nvram for windows and linux for now we can rule it > out for debugging the issue. Yeah, there are some options here which we can try to explore. What's still unknown though is why windows appears immune to this exact same interference. A software fix would be much more convenient... :) Daniel
On 3/28/2018 8:43 PM, Daniel Drake wrote: > On Thu, Mar 8, 2018 at 4:47 AM, Arend van Spriel > <arend.vanspriel@broadcom.com> wrote: >>> 43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf >>> >>> Yes, ndis. So no easy way to run the same firmware on the 2 OSes. >> >> Indeed. I could try building nearly same firmware target. Can you provide >> the firmware version as well. > > Full string is: > 43455c0-roml/sdio-ag-ndis-vista-pktfilter-d0c-pno-aoe-p2p-dhdoid-ndoe-gtkoe-mfp-proptxstatus-dmatxrc-keepalive-ap-ampduretry-pclose-txbf > Version: 7.45.87.0 CRC: 7cb2470e Date: Thu 2016-04-21 22:31:44 PDT > Ucode Ver: 1043.2070 FWID: 01-f68ec182 > > If you could build that config but for Linux instead of ndis I would > love to try it. > > Also, here is the string for the current one in linux-firmware: > 43455c0-roml/sdio-ag-p2p-pno-aoe-pktfilter-keepalive-mchan-pktctx-proptxstatus-ampduhostreorder-lpc-pwropt-txbf-wnm-okc-ccx-ltecx-wfds-wl11u-mfp-tdls-ve > Version: 7.45.18.0 CRC: d7226371 Date: Sun 2015-03-01 07:31:57 PST > Ucode Ver: 1026.2 FWID: 01-6a2c8ad4 > > I note that the Version and UcodeVer in the linux-firmware version are > lower than the windows one. If it's possible to also rebuild the > linux-firmware config but with those newer versions (or even the > latest, if there is something newer), I will test that too. Thanks for the version info. I will look if we could use similar version as window version, but typically they spin from different branches. >> So it picks up something in the PC. Some sources of interference that I have >> seen before are USB3 and HDMI. Maybe try to shield those if present and see >> if that helps. The nvram contains sensitivity parameters, but as you stated >> you are using the same nvram for windows and linux for now we can rule it >> out for debugging the issue. > > Yeah, there are some options here which we can try to explore. What's > still unknown though is why windows appears immune to this exact same > interference. A software fix would be much more convenient... :) Obviously ;-) And the immunity seems to justify that path. Regards, Arend
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c index 9be0b05..512ea57 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/common.c @@ -363,9 +363,6 @@ int brcmf_c_preinit_dcmds(struct brcmf_if *ifp) goto done; } - /* Enable tx beamforming, errors can be ignored (not supported) */ - (void)brcmf_fil_iovar_int_set(ifp, "txbf", 1); - /* do bus specific preinit here */ err = brcmf_bus_preinit(ifp->drvr->bus_if); done: