[OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.

[Ian Kent]

On Thu, 2015-04-23 at 13:19 +0000, Hante Meuleman wrote:
> Can you tell a bit more about:
> 
> "switch to use port 8 for the cpu, the way the Broadcom source does,
> doesn't work so I'm missing something with that for sure."
> 
> Is that something you tried with the by Rafał suggested changes to 
> fix the cpu port to 8 in the struct, as described on the forum? 

This goes back to quite a while before you had a look at the switch
problem.

Essentially I was not able to get the switch to work at all so here's
probably a lot more info. than you really want but ....

I was sure I had tried what you ultimately described as working and
which does work now so that was a bit of a surprise. That probably
changed along the way and I never returned to trying what you found to
work.

The fact that the nvram settings indicate that switch port 8 is set as
the cpu port is what lead to the belief that it should be used rather
than port 5, but also ports 5 and 7 are related to port 8 in some way as
well (judging by the nvram setting).

I located GPL released source that looked like what the bgmac driver
originated from and tried to find any new changes. I didn't find any
except perhaps the endian order of the mac address when setting it. That
made no difference.

The next thing was to go through the same process for the b53 driver but
it doesn't have a real parallel in the Broadcom source. The closest is
bcmrobo.c which I used for the comparison.

The patch I posted in the forum, when you started looking at the switch
problem, is the result of that comparison and essentially configures
switch port 8 and switch ports 5 and 7 as is done in bcmrobo.c in order
to try and use port 8 as the switch cpu port. It doesn't work for me.

I believe that there's some other device, perhaps a Flow Accelerator,
that lives on the third pcie device that bgmac ignores which needs to be
configured to provide the link between ports 5 and 7 to port 8. But that
looks like it's also related to the cut through forward proprietary code
so is probably something we can't use.

The bottom line is, in light of you pointing out that using switch port
5 as the cpu port does now work, we probably need to ignore the fact
that the nvram setting uses port 8 and just use port 5.

For a long time the switch configuration in /etc/config/network set at
install used port 5 as the cpu. But this recently changed to use port 8
if the nvram setting used port 8 which actually breaks the switch until
it is set back to use port 5.

Rafał has asked me to try only setting the cpu port to 8 in the b53
driver code for this switch device and try that to see if it works. I
haven't done that yet but will get to it.

> 
> 
> On Wed, 2015-04-22 at 11:45 +0000, Hante Meuleman wrote:
> > Today I wrote the original firmware back on the device 
> > (using the latest from netgear). This worked and the device
> >  was working fine. Then I flashed openwrt again, now the 
> > switch didn’t work anymore. So I checked the ports 
> > configuration and it had changed. So I reverted that 
> > using the nvram userspace program. This killed the 
> > nvram contents completely and after reboot I only had 
> > the bare minimum nvram contents and it was the same 
> > as before. However, now I cannot get the switch to work 
> > anymore. 
> > 
> > So doing an nvram set "xxx=yyy", followed by nvram commit
> > appears to be killing my nvram contents. 
> > 
> > I've no idea why my switch is not working anymore. The 
> > problems with this switch is starting to get frustrating
> 
> Yes, the switch is frustrating and all I can do is describe what I've
> seen, maybe it will help.
> 
> A fairly recent change to setting the switch configuration
> in /etc/config/network at install sets the switch ports to "0 1 2 3 5 7
> 8t" and "4 8t" for the respective vlans.
> 
> But the b53 driver still uses port 5 as the cpu and does the setup that
> you've previously described as working (using port 5 as cpu).
> 
> The switch configuration in network is done once at firmware install so
> it needs to be changed by hand.
> 
> What's more annoying is doing the heavy lifting in b53 to setup the
> switch to use port 8 for the cpu, the way the Broadcom source does,
> doesn't work so I'm missing something with that for sure.
> 
> So we do need to stick to using port 5 for the cpu consistently
> throughout for now.
> 
> > 
> > Regards,
> > Hante
> > 
> > -----Original Message-----
> > From: Hante Meuleman 
> > Sent: dinsdag 21 april 2015 17:22
> > To: 'Ian Kent'; Arend Van Spriel
> > Cc: 'Jonas Gorski'; 'mailinglist'
> > Subject: RE: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
> > 
> > Today I managed to update brcmfmac to load the data
> >  directly from bcm47xx_nvram but it will require an additional
> > api in this module. I will post my version of bcm47xx_nvram
> >  later this week. Also the patch for brcmfmac will be posted 
> > later this week. With proper NVRAM the device is now booting 
> > fine and all wireless devices get detected properly and are
> >  working fine. 
> > 
> > I still do not know why I lost the complete contents of the nvram. 
> > I do know that the CFE holds a very small default set which get 
> > programmed if nothing is available from the nvram mtd block 
> > device. As I dumped the nvram initially I was able to restore the 
> > nvram completely and after that I was not able to get in the 
> > situation where the nvram would be cleared and only hold the
> > default set of keys.
> > 
> > We do have another r8000, but that one needs to be "recoverable". 
> > So I will spent some time to see if I can make sure that I can restore
> >  the r8000 with the original firmware and the original nvram 
> > contents and once I'm sure I can I will try to update the other 
> > r8000 as well. Then I can see if nvram gets perhaps erased on 
> > the initial flashing of the OpenWRT. It's just a guess, but I really 
> > don’t know what cleared the nvram contents on my device and 
> > as long as that isn’t clear I wouldn’t recommend anybody to flash 
> > an openwrt image on it.
> > 
> > Regards,
> > Hante
> > 
> > -----Original Message-----
> > From: Hante Meuleman 
> > Sent: dinsdag 21 april 2015 10:29
> > To: 'Ian Kent'; Arend Van Spriel
> > Cc: 'Jonas Gorski'; 'mailinglist'
> > Subject: RE: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
> > 
> > It is something else, the CFE appears to override the
> > nvram for some reason with some default data. Don’t
> > know yet what is reason for CFE to determine that nvram 
> > is invalid but it appears to be within the CFE that NVRAM
> > gets erased and defaulted to something minimal.
> > 
> > Regards,
> > Hante
> > 
> > -----Original Message-----
> > From: Hante Meuleman 
> > Sent: dinsdag 21 april 2015 9:36
> > To: 'Ian Kent'; Arend Van Spriel
> > Cc: Jonas Gorski; mailinglist
> > Subject: RE: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
> > 
> > Well, I found that the cause is within openwrt. 
> > I thought that CFE would still show the original 
> > contents, but that is incorrect. So I reprogrammed 
> > the nvram (via CFE, using created script, as I still 
> > had the original nvram contents) then booted openwrt,
> > gave the command "nvram show" then rebooted and 
> > the contents was suddenly very minimal. I'm still
> > investigating if it is some kernel driver which is 
> > doing this, or the nvram userspace app. As this
> >  userspace app is capable of printing (all) entries
> >  I suspect it is this app. I hope people who did this
> >  still have the original content. May also be something 
> > else, but the original contents got cleared for some
> >  reason and is not available on the device anymore.
> > 
> > Regards,
> > Hante
> > 
> > -----Original Message-----
> > From: Ian Kent [mailto:raven at themaw.net] 
> > Sent: dinsdag 21 april 2015 3:43
> > To: Arend Van Spriel
> > Cc: Jonas Gorski; Hante Meuleman; mailinglist
> > Subject: Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
> > 
> > On Mon, 2015-04-20 at 19:28 +0200, Arend van Spriel wrote:
> > > On 04/20/15 13:50, Jonas Gorski wrote:
> > > > Hi,
> > > >
> > > > On Mon, Apr 20, 2015 at 1:29 PM, Rafał Miłecki<zajec5 at gmail.com>  wrote:
> > > >> On 20 April 2015 at 11:27, Arend van Spriel<arend at broadcom.com>  wrote:
> > > >>>> Following an "nvram erase" none of the needed<key, value>   pairs remain
> > > >>>> in nvram. So we probably can't use nvram in a reliable way to create the
> > > >>>> wireless configuration.
> > > >>>
> > > >>>
> > > >>> So why do "nvram erase"? The assumption that it is not needed because you
> > > >>> are running an OpenWRT image is wrong or at least only partially true, ie.
> > > >>> for the user-space settings.
> > > >>
> > > >> I agree with Arend. If you're are erasing sensitive wireless info from
> > > >> your device, expect problems. The same will happen if you'll overwrite
> > > >> standard Broadcom PCI device SPROM (which contains the same kind of
> > > >> data).
> > > >
> > > > At least on older bcm47xx/MIPS devices nvram was also used for (user
> > > > changable) configuration like lan ip address, and consequently erasing
> > > > nvram caused CFE to restore the default values, which should include
> > > > the right wifi configuration values. Several devices even do so when
> > > > holding down reset for a long time at power up*. Does this not happen
> > > > anymore with bcm53xx/ARM? Are user values now stored in a different
> > > > partition?
> > > 
> > > Hi Jonas,
> > > 
> > > I was hoping that the firmware specific wifi config would indeed be in a 
> > > separate MTD partition. However, Hante has been looking at the MTD 
> > > partitions and none match up with what CFE dumps upon 'nvram show'. So 
> > > we are going through our CFE code, but no clues (yet) whether R8000 
> > > specific changes have been made. There is also an spiflash device 
> > > configured in DT but the bcm53xxspiflash driver does not seem to be 
> > > working for it.
> > 
> > Yes, that's what I see too.
> > Last time I looked I got the impression the device used isn't known to
> > the kernel.
> > 
> > > 
> > > Regards,
> > > Arend
> > > _______________________________________________
> > > openwrt-devel mailing list
> > > openwrt-devel at lists.openwrt.org
> > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> > 
> > 
> 
> 
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel