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

[Hante Meuleman]

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? 


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