[OpenWrt-Devel] ar934x+ar8327v4

David Hutchison dhutchison at bluemesh.net
Mon Dec 8 13:13:07 EST 2014


Hello,

I did some more poking around. I don't know if I am way off course or
not, but I hope these findings trigger some ideas.

Firstly, I contacted Mikrotik and actually received a response:

"Hello,

that patch will not help you much. However, you can try to debug your FW on
RB2011 as it uses same CPU and same Gbit switch chip as RB951G-2HPnD. You have
to correctly initialize MAC address of switch chip to make it work. You have to
do that via driver so that switch is not forwarding packets when OS is still
booting.

Regards,
Janis K." -- Mikrotik Support

I requested access to there kernel patches, instead they gave me
something to look into.

Since the Routerboard 2011 and the RB951G use the same processor, I
took code to expose the SPI config partitions. This way I could
confirm the MAC Address was indeed the same that was inside
"hard_config":

Looking at "routerboot.h" I saw the "4" id inside hard_config is the
RB_ID_MAC_ADDRESS_PACK.

root at OpenWrt:/dev# cat /dev/mtd1 | hexdump -C
00000000  64 72 61 48 00 04 00 1a  00 00 00 00 00 08 00 04  |draH............|
00000010  4c 5e 0c 6d 24 43 00 00  00 04 00 0e 00 00 00 06  |L^.m$C..........|

That is the same MAC that is written on the board ( The bottom of the
951G has "4c 5e 0c 6d 24 43" ... "4c 5e 0c 6d 24 48" ). I then checked
that MAC against eth0:

root at OpenWrt:/dev# ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 4C:5E:0C:6D:24:43
          inet addr:10.128.41.249  Bcast:10.128.41.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:144 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:8996 (8.7 KiB)  TX bytes:1292 (1.2 KiB)
          Interrupt:4

It all lines up. It's obviously not a MAC initialization problem. The
ag71xx driver must be working correctly since RX/TX packets are
showing. Since eth0 see's packets, that must mean communication
between the ar8327 + ar934x is somewhat working. I'm wondering what we
are missing...

-- Davey

On Fri, Dec 5, 2014 at 12:39 PM, David Hutchison
<dhutchison at bluemesh.net> wrote:
> Here is a test I did by setting up swconfig manually. As you can see I
> put ports 1 and 2 into vlangroup 1. Traffic from port 2 can ping
> 10.128.41.1 which is a device on port 1. However eth0.1 which as
> address 10.128.41.249 cannot ping 10.128.41.1 device on port 1.
> Attached is the swconfig setup, and a dmesg.
>
> Here is the arp result as well:
> root at OpenWrt:/# arp -n
> IP address       HW type     Flags       HW address            Mask     Device
> 10.128.41.1      0x1         0x0         00:00:00:00:00:00     *        eth0.1
>
> I used to be able to do:
> root at OpenWrt:/# swconfig dev eth0 show
> Failed to connect to the switch
> root at OpenWrt:/# swconfig list
> Found: switch0 - ag71xx-mdio.0
>
> Do you not think this is an issue with ag71xx? Do you it is something
> in user-space?
>
> On Fri, Dec 5, 2014 at 12:18 PM, David Hutchison
> <dhutchison at bluemesh.net> wrote:
>> I am using a very simple test setup with no vlans for now:
>>
>> root at OpenWrt:/# cat /etc/config/network
>>
>> config interface 'loopback'
>>         option ifname 'lo'
>>         option proto 'static'
>>         option ipaddr '127.0.0.1'
>>         option netmask '255.0.0.0'
>>
>> config globals 'globals'
>>         option ula_prefix 'fd26:7dae:48cb::/48'
>>
>> config interface 'lan'
>>         option ifname 'eth0'
>>         option type 'bridge'
>>         option proto 'static'
>>         option ipaddr '192.168.1.1'
>>         option netmask '255.255.255.0'
>>         option ip6assign '60'
>>
>> root at OpenWrt:/# swconfig dev switch0 show
>> Global attributes:
>>         enable_vlan: 0
>>         enable_mirror_rx: 0
>>         enable_mirror_tx: 0
>>         mirror_monitor_port: 0
>>         mirror_source_port: 0
>> Port 0:
>>         mib: Port 0 MIB counters
>> RxBroad     : 5
>> RxPause     : 0
>> RxMulti     : 6
>> RxFcsErr    : 0
>> RxAlignErr  : 0
>> RxRunt      : 0
>> RxFragment  : 0
>> Rx64Byte    : 0
>> Rx128Byte   : 3252
>> Rx256Byte   : 3
>> Rx512Byte   : 4
>> Rx1024Byte  : 0
>> Rx1518Byte  : 0
>> RxMaxByte   : 0
>> RxTooLong   : 0
>> RxGoodByte  : 223169
>> RxBadByte   : 0
>> RxOverFlow  : 0
>> Filtered    : 0
>> TxBroad     : 151
>> TxPause     : 0
>> TxMulti     : 324
>> TxUnderRun  : 0
>> Tx64Byte    : 208
>> Tx128Byte   : 93
>> Tx256Byte   : 99
>> Tx512Byte   : 57
>> Tx1024Byte  : 12
>> Tx1518Byte  : 3260
>> TxMaxByte   : 0
>> TxOverSize  : 0
>> TxByte      : 4960741
>> TxCollision : 0
>> TxAbortCol  : 0
>> TxMultiCol  : 0
>> TxSingleCol : 0
>> TxExcDefer  : 0
>> TxDefer     : 0
>> TxLateCol   : 0
>>
>>         pvid: 0
>>         link: port:0 link:up speed:1000baseT full-duplex txflow rxflow
>> Port 1:
>>         mib: Port 1 MIB counters
>> RxBroad     : 151
>> RxPause     : 0
>> RxMulti     : 324
>> RxFcsErr    : 0
>> RxAlignErr  : 0
>> RxRunt      : 0
>> RxFragment  : 0
>> Rx64Byte    : 208
>> Rx128Byte   : 93
>> Rx256Byte   : 99
>> Rx512Byte   : 57
>> Rx1024Byte  : 12
>> Rx1518Byte  : 3260
>> RxMaxByte   : 0
>> RxTooLong   : 0
>> RxGoodByte  : 4960741
>> RxBadByte   : 0
>> RxOverFlow  : 0
>> Filtered    : 0
>> TxBroad     : 5
>> TxPause     : 0
>> TxMulti     : 6
>> TxUnderRun  : 0
>> Tx64Byte    : 0
>> Tx128Byte   : 3252
>> Tx256Byte   : 3
>> Tx512Byte   : 4
>> Tx1024Byte  : 0
>> Tx1518Byte  : 0
>> TxMaxByte   : 0
>> TxOverSize  : 0
>> TxByte      : 223169
>> TxCollision : 0
>> TxAbortCol  : 0
>> TxMultiCol  : 0
>> TxSingleCol : 0
>> TxExcDefer  : 0
>> TxDefer     : 0
>> TxLateCol   : 0
>>
>>         pvid: 0
>>         link: port:1 link:up speed:1000baseT full-duplex auto
>> Port 2:
>>         mib: Port 2 MIB counters
>> RxBroad     : 0
>> RxPause     : 0
>> RxMulti     : 0
>> RxFcsErr    : 0
>> RxAlignErr  : 0
>> RxRunt      : 0
>> RxFragment  : 0
>> Rx64Byte    : 0
>> Rx128Byte   : 0
>> Rx256Byte   : 0
>> Rx512Byte   : 0
>> Rx1024Byte  : 0
>> Rx1518Byte  : 0
>> RxMaxByte   : 0
>> RxTooLong   : 0
>> RxGoodByte  : 0
>> RxBadByte   : 0
>> RxOverFlow  : 0
>> Filtered    : 0
>> TxBroad     : 0
>> TxPause     : 0
>> TxMulti     : 0
>> TxUnderRun  : 0
>> Tx64Byte    : 0
>> Tx128Byte   : 0
>> Tx256Byte   : 0
>> Tx512Byte   : 0
>> Tx1024Byte  : 0
>> Tx1518Byte  : 0
>> TxMaxByte   : 0
>> TxOverSize  : 0
>> TxByte      : 0
>> TxCollision : 0
>> TxAbortCol  : 0
>> TxMultiCol  : 0
>> TxSingleCol : 0
>> TxExcDefer  : 0
>> TxDefer     : 0
>> TxLateCol   : 0
>>
>>         pvid: 0
>>         link: port:2 link:down
>> Port 3:
>>         mib: Port 3 MIB counters
>> RxBroad     : 0
>> RxPause     : 0
>> RxMulti     : 0
>> RxFcsErr    : 0
>> RxAlignErr  : 0
>> RxRunt      : 0
>> RxFragment  : 0
>> Rx64Byte    : 0
>> Rx128Byte   : 0
>> Rx256Byte   : 0
>> Rx512Byte   : 0
>> Rx1024Byte  : 0
>> Rx1518Byte  : 0
>> RxMaxByte   : 0
>> RxTooLong   : 0
>> RxGoodByte  : 0
>> RxBadByte   : 0
>> RxOverFlow  : 0
>> Filtered    : 0
>> TxBroad     : 0
>> TxPause     : 0
>> TxMulti     : 0
>> TxUnderRun  : 0
>> Tx64Byte    : 0
>> Tx128Byte   : 0
>> Tx256Byte   : 0
>> Tx512Byte   : 0
>> Tx1024Byte  : 0
>> Tx1518Byte  : 0
>> TxMaxByte   : 0
>> TxOverSize  : 0
>> TxByte      : 0
>> TxCollision : 0
>> TxAbortCol  : 0
>> TxMultiCol  : 0
>> TxSingleCol : 0
>> TxExcDefer  : 0
>> TxDefer     : 0
>> TxLateCol   : 0
>>
>>         pvid: 0
>>         link: port:3 link:down
>> Port 4:
>>         mib: Port 4 MIB counters
>> RxBroad     : 0
>> RxPause     : 0
>> RxMulti     : 0
>> RxFcsErr    : 0
>> RxAlignErr  : 0
>> RxRunt      : 0
>> RxFragment  : 0
>> Rx64Byte    : 0
>> Rx128Byte   : 0
>> Rx256Byte   : 0
>> Rx512Byte   : 0
>> Rx1024Byte  : 0
>> Rx1518Byte  : 0
>> RxMaxByte   : 0
>> RxTooLong   : 0
>> RxGoodByte  : 0
>> RxBadByte   : 0
>> RxOverFlow  : 0
>> Filtered    : 0
>> TxBroad     : 0
>> TxPause     : 0
>> TxMulti     : 0
>> TxUnderRun  : 0
>> Tx64Byte    : 0
>> Tx128Byte   : 0
>> Tx256Byte   : 0
>> Tx512Byte   : 0
>> Tx1024Byte  : 0
>> Tx1518Byte  : 0
>> TxMaxByte   : 0
>> TxOverSize  : 0
>> TxByte      : 0
>> TxCollision : 0
>> TxAbortCol  : 0
>> TxMultiCol  : 0
>> TxSingleCol : 0
>> TxExcDefer  : 0
>> TxDefer     : 0
>> TxLateCol   : 0
>>
>>         pvid: 0
>>         link: port:4 link:down
>> Port 5:
>>         mib: Port 5 MIB counters
>> RxBroad     : 0
>> RxPause     : 0
>> RxMulti     : 0
>> RxFcsErr    : 0
>> RxAlignErr  : 0
>> RxRunt      : 0
>> RxFragment  : 0
>> Rx64Byte    : 0
>> Rx128Byte   : 0
>> Rx256Byte   : 0
>> Rx512Byte   : 0
>> Rx1024Byte  : 0
>> Rx1518Byte  : 0
>> RxMaxByte   : 0
>> RxTooLong   : 0
>> RxGoodByte  : 0
>> RxBadByte   : 0
>> RxOverFlow  : 0
>> Filtered    : 0
>> TxBroad     : 0
>> TxPause     : 0
>> TxMulti     : 0
>> TxUnderRun  : 0
>> Tx64Byte    : 0
>> Tx128Byte   : 0
>> Tx256Byte   : 0
>> Tx512Byte   : 0
>> Tx1024Byte  : 0
>> Tx1518Byte  : 0
>> TxMaxByte   : 0
>> TxOverSize  : 0
>> TxByte      : 0
>> TxCollision : 0
>> TxAbortCol  : 0
>> TxMultiCol  : 0
>> TxSingleCol : 0
>> TxExcDefer  : 0
>> TxDefer     : 0
>> TxLateCol   : 0
>>
>>         pvid: 0
>>         link: port:5 link:down
>> Port 6:
>>         mib: Port 6 MIB counters
>> RxBroad     : 0
>> RxPause     : 0
>> RxMulti     : 0
>> RxFcsErr    : 0
>> RxAlignErr  : 0
>> RxRunt      : 0
>> RxFragment  : 0
>> Rx64Byte    : 0
>> Rx128Byte   : 0
>> Rx256Byte   : 0
>> Rx512Byte   : 0
>> Rx1024Byte  : 0
>> Rx1518Byte  : 0
>> RxMaxByte   : 0
>> RxTooLong   : 0
>> RxGoodByte  : 0
>> RxBadByte   : 0
>> RxOverFlow  : 0
>> Filtered    : 0
>> TxBroad     : 0
>> TxPause     : 0
>> TxMulti     : 0
>> TxUnderRun  : 0
>> Tx64Byte    : 0
>> Tx128Byte   : 0
>> Tx256Byte   : 0
>> Tx512Byte   : 0
>> Tx1024Byte  : 0
>> Tx1518Byte  : 0
>> TxMaxByte   : 0
>> TxOverSize  : 0
>> TxByte      : 0
>> TxCollision : 0
>> TxAbortCol  : 0
>> TxMultiCol  : 0
>> TxSingleCol : 0
>> TxExcDefer  : 0
>> TxDefer     : 0
>> TxLateCol   : 0
>>
>>         pvid: 0
>>         link: port:6 link:down
>>
>> On Fri, Dec 5, 2014 at 9:37 AM, Felix Fietkau <nbd at openwrt.org> wrote:
>>> On 2014-12-05 17:15, David Hutchison wrote:
>>>> Hello,
>>>>
>>>> Yes the problem remains when enable_vlan is set to 0
>>>>
>>>> I don't think it's related to your changes either. I synced with trunk
>>>> in hope that your changes made a difference with my problem. However
>>>> that does not seem to be the case.
>>>>
>>>> I was hoping someone could point me in the right direction. Does this
>>>> sound more like an issue with ag71xx since that is what exposes the
>>>> "eth0" interface? Could it be as simple as the switch just isn't
>>>> recognized? Perhaps the switch interconnect is no longer RGMII and
>>>> should be GMII?
>>>>
>>>> If I knew where in those drivers to start looking, I could probably
>>>> help fix this problem. I enjoy tinkering with the drivers, and
>>>> learning how to fix them :)
>>>>
>>>> I was hoping you had some knowledge about how the interface becomes
>>>> tied with the switch itself, and if there were any specifics for the
>>>> ar8327 that must be set before the communication between the CPU +
>>>> Switch Chip can happen.
>>>>
>>>> Felix, would you by chance have any ideas as to what to check next?
>>>> The switch0 interface works fine, the eth0 interface tied to the
>>>> switch. Does not.
>>>>
>>>> The other thing to note ( and i'm not sure if this is by design ).. I
>>>> used to be able to do "swconfig dev eth0 show" and show the switch the
>>>> eth0 was connected to. Now I must use "swconfig dev switch0 show" to
>>>> configure the switch. When you do "swconfig dev eth0 show" it says it
>>>> Failed to connect to the switch. In the past, I have always used eth0
>>>> to configure the switch however that may have been incorrect.
>>> Please post your network/switch configuration, and the output of
>>> swconfig dev switch0 show
>>>
>>> - Felix
_______________________________________________
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