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

Thu Apr 23 21:57:46 EDT 2015

On Thu, 2015-04-23 at 14:48 +0000, Hante Meuleman wrote:
> Thank you for the information Ian, that was very helpful. Just found 
> part of the problem. My R8000 used to work quite well, till I upgraded 
> to new Netgear firmware. The old Netgear firmware is using this nvram 
> entry:
> 
> vlan1ports=3 2 1 0 5 7 8*
> 
> Newer firmware will update this nvram entry to
> 
> vlan1ports=0 1 2 3 5 7 8*

My device had this setting from the beginning.

> 
> So depending on when you bought the AP you will have one of these 
> entries in the nvram. Both strings indicate that port 8 is the cpu port, 
> however, somehow the application (or script, not sure what is doing 
> this) that generates the file /etc/config/network at first boot will 
> generate different results for the entry:
> 
> option ports
> 
> vlan1ports=3 2 1 0 5 7 8* -> option ports '0 1 2 3 5t'
> vlan1ports=0 1 2 3 5 7 8* -> option ports '0 1 2 3 5 7 8t'
> 
> So when you have newer Netgear FW in your AP then you'll have a 
> different setting for vlan1ports in /etc/config/network then with older 
> firmware. This setting determines whether or not the switch is going to 
> work (as you already figured out).
> 
> Still investigating to as of why this setting doesn't work with b53 driver.

> 
> -----Original Message-----
> 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