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

Wed Apr 22 22:10:45 EDT 2015

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: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