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:ra...@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<zaj...@gmail.com> wrote: > > > >> On 20 April 2015 at 11:27, Arend van Spriel<ar...@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@lists.openwrt.org > > > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > > > > _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel