• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 2460 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM335x Ethernet with Cisco router

George Chiao
Intellectual 420 points

Hi,

I am not sure how to start with my question but I will give it a try...

I have two identical customized PCB with AM3352b processor and I configured the CPSW ethernet running on dual-mac mode.

The first device has its network configured to

eth0: 192.168.0.1/24

eth1: 192.168.1.1/24

The second device has its network configured to

eth0: 192.168.0.2/24

eth1: 192.168.1.2/24

I connected both devices' eth0 to a switch. I could ping each other via the switch, i.e. I could ping 192.168.0.1 from 192.168.0.2, and vise versa.

The problem I am having is that when I connected both devices' eth0 to a Cisco router (e.g. cisco WS-C3750-48P) I couldn't ping each other anymore.

The cisco router is configured correctly to the best of my knowledge I have also swapped the two PCB with laptops and configured them with the same ip configuration and the two laptops could ping each other.  I have the other customized PCB with other processor type and it worked fine as well.

I tried to wireshark to see what could be the cause.  I saw that when pinging from 192.168.0.1 to 192.168.0.2,

(1) a ARP was sent from 192.168.0.1 to the Cisco router, the Cisco router correctly forwarded to 192.168.0.2

(2) 192.168.0.2 then sent a ARP reply (its MAC address) back to the router correctly

(3) the router did not forward that ARP to 192.168.0.1!

I have no clue what the cause might be at this point I could only guess it has something Cisco router doesn't like already as I couldn't find anything wrong in ARP (layer 3) I start thinking the problem might be in layer 2 or even layer 1.   I checked the mac-address list on the Cisco router and found that only the two laptops are shown and not the two AM3352b processors, which seems to suggest something has gone unrecognizable already.  Any possible suggestion for me to take? 

Many thanks


George

  • 0
    TI__Guru**** 393215 points
    Hi,

    I will ask the Ethernet experts to comment.
  • 0 in reply to Biser Gatchev-XID
    Intellectual 420 points
    Thank you.

    Further investigation by comparing the off-shelf AM335x EVM Starter Kit, which worked just fine with the router.

    I had a look at dmesg

    [ 12.673512] net eth0: initializing cpsw version 1.12 (0)
    [ 12.756211] net eth0: phy found : id is : 0x4dd074

    And our customized board is

    [ 19.521464] net eth0: initializing cpsw version 1.12 (0)
    [ 19.528699] net eth0: phy found : id is : 0x7c0f1
    [ 19.542869] 8021q: adding VLAN 0 to HW filter on device eth0

    I could see for some reason VLAN tag was added to eth0. I then checked the kernel configuration and found

    <*> 802.1Q VLAN Support
    [*] GVRP (GARP VLAN Registration Protocol) support

    I will remove these, build the kernel and try again before I get back here but at the moment I am almost certain that it is the issue. Thanks
  • 0 in reply to George Chiao
    Intellectual 420 points
    Hi Biser,

    I have removed the VLAN Support and GVRP from the Kernel option. I could see the difference; before was

    [ 19.521464] net eth0: initializing cpsw version 1.12 (0)
    [ 19.528699] net eth0: phy found : id is : 0x7c0f1
    [ 19.542869] 8021q: adding VLAN 0 to HW filter on device eth0

    and now it is like

    [ 19.521464] net eth0: initializing cpsw version 1.12 (0)
    [ 19.528699] net eth0: phy found : id is : 0x7c0f1

    However it still didn't work with Cisco's router, I then went into the Cisco router and set up to allow vlan 0 tag (by default Cisco router not allowing vlan 0)

    i.e. 'switchport voice vlan dot1p'

    and then it started working again. It seems that regardless the VLAN Support option was enabled or not from the Kernel, packets sent by the CPSW still contain vlan headers.

    Further investigation shows that the vlan 0 tag is actually being added only when in *dual-emac* mode, i.e. if I remove *dual-emac* from the device tree, then the eth0 started working with the Cisco router, however I would loss eth1 I need in that case.

    Is it a way to remove vlan 0 tag from the packages when running in dual-emac? or is it a way I can have both eth ports and packages from eth0 not contain vlan tag 0? or have I missed something?

    Many thanks

    George
  • 0 in reply to George Chiao
    TI__Mastermind 41510 points

    Earlier versions of the kernel had an issue with the vlan tagging. This has been fixed in later kernels. Which kernel version are you using?

  • 0 in reply to Schuyler Patton
    Intellectual 420 points

    Hi Schuyler,

    Thanks for the reply.  Could you provide me the fix you mentioned was first introduced on which kernel version? 

    The version I have was built from version 3.2

    processors.wiki.ti.com/.../AM335x-PSP_04.06.00.10_Release_Notes

    Many thanks

    George

  • 0 in reply to George Chiao
    Intellectual 420 points
    Hi,

    I have just come across this post and it seemed pretty much describing my issue i.e. vlan 0 tagging on dual-emac

    e2e.ti.com/.../380274

    Could you confirm whether it's what you meant by the fix in later kernel? And what version of kernel has the fix first been introduced?

    The post said it might just fix my issue by 'setting the NO_SA_UPDATE and the NO_LEARN bits both to 1 in the PORTCTL1 and PORTCTL2 registers'. but I have no clue how. Could you help please?

    Many thanks

    George