On Wed, 2015-04-22 at 12:50 +0000, Hante Meuleman wrote: > Found the problem for the "lost" nvram. The nvram user > space app build from directory package/utils/nvram/src > uses a maximum size of 32KB for nvram. As a result when > writing it will not write all entries. Once rebooted and the > CFE doesn’t detect certain critical nvram entries then it > will erase the complete nvram contents and put in a > default set. Changing the define NVRAM_SPACE from > 0x8000 into 0x10000 in the nvram.h fixes this problem. > A similar change was already made in the kernel driver, > though I don’t think that in this case it can be done > without breaking backwards compatibility with older > devices.
Oh, wow, so now we know why, that's a big step in resolving it, good catch. > > Now to the switch problems. > > Regards, > Hante > > -----Original Message----- > From: Hante Meuleman > Sent: woensdag 22 april 2015 13:45 > 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 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 > > 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
