[OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
Hante Meuleman
meuleman at broadcom.com
Wed Apr 29 07:40:33 EDT 2015
Created some more logging, it is probably a configuration error
in the switch when port 8 is part of the vlan configuration. It
appears there is an offset in the data being received by bgmac,
strangely enough, the log appears to show valid data, but that
data is not accepted while the working configuration gives
debug data like this:
[ 23.955731] bgmac: ETH, len=64, flags=0x05, protocol=0x0081
[ 23.962731] bgmac: 00 01 08 00 46 c0 00 20 00 00 40 00 01 02 40 72
[ 23.970811] bgmac: c0 a8 02 02 e0 00 00 fb 94 04 00 00 16 00 09 04
Which appears to be incorrect (wrong protocol) and data has offset
of 4. But this data does get accepted and is working.
-----Original Message-----
Status report: spent lots of time trying to figure out how to use cpu
port 8 and use vlan1ports "0 1 2 3 5 7 8t", and found that I got fooled
by the way I tried to determine if it was working or not. To see if the
switch configuration was working I used to type "ifconfig" and then
see if there were and rx packets. Today I added logging in bgmac to
see if there are any rx interrupts, and to my surprise there are. So it
is possible to get it to work with cpu port 8 but the data is being
dropped by the stack (nothing visible in the counters). This is sample
data that gets received:
[ 32.759614] bgmac: ETH, len=324, flags=0x01, protocol=0x0008
[ 32.766714] bgmac: 45 00 01 36 bc f2 40 00 ff 11 19 8a c0 a8 02 96
[ 32.774796] bgmac: e0 00 00 fb 14 e9 14 e9 01 22 b5 86 00 00 84 00
[ 32.782892] bgmac: ETH, len=344, flags=0x01, protocol=0xdd86
[ 32.789989] bgmac: 60 00 00 00 01 22 11 ff fd 1b 72 e5 79 5c 00 00
[ 32.798077] bgmac: 75 58 39 77 51 db f7 b2 ff 02 00 00 00 00 00 00
The ip addres of the ipv4 packet is of one of the connected PCs. These
packets get dropped somehow and it is related to the config
vlan1ports "0 1 2 3 5 7 8t". I can use cpu port 8 and config
vlan1ports "0 1 2 3 5t" without a problem. So there might be an issue
in the switch code, but there are more problems with this configuration
in other areas.
-----Original Message-----
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
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list