AM6422: linux ICSSG0 MII

Part Number: AM6422
Other Parts Discussed in Thread: DP83620, , AM6442

Tool/software:

Hi,

We are currently using our own hardware to make the MII interface Ethernet of ICSSG0. The PHY chip is DP83620. I think the PHY driver does not need special processing at present. We use emac0 as a network port. How should the corresponding device tree be modified? Can you provide an example? Thank you!

  • Why is the following information printed?

    [ 131.748943] Initializing XFRM netlink socket
    [ 132.846054] bridge: filtering via arp/ip/ip6tables is no longer available by default. Update your scripts to load br_netfil
    [ 132.862837] Bridge firewalling registered
    [ 134.250585] process 'docker/tmp/qemu-check368786963/check' started with executable stack

    What does it affect? ​​Do I need to do anything about it?

  • Hello Wanglili,

    I am sending your thread over to the PHY team to discuss the question about the PHY driver, and to see if they have any other suggestions. They'll reassign the thread to me once they're done with it.

    Regards,

    Nick

  • Hi,

    Is there nothing else to doubt at this point?I used the ifconfig command, and the corresponding sent and received data packets all had data, but the ping was unsuccessful.And also print “timeout waiting for command done”,also, are the tx-internal-delay-ps and rx-internal-delay-ps mentioned earlier valid in MII mode?When does the “xmit timeout” message appear?

  • Hello,

    We have a recently released app note detailing our PHY driver ecosystem. Perhaps this can help point you to determine what driver is being used.

    Sincerely,

    Gerome

  • Hi,

    I would like to confirm whether the DP83620 driver I am currently using supports it?The main problem is that Ethernet ping is not working.

  • Hello,

    If the Ethernet is not pinging, it could mean a lot of things. Ping is only a general overview of the signal chain, and it could be that the MAC interface is suspect, that there is no link, or that the issue is on the link partner's MAC interface as well. 

    Sincerely,

    Gerome

  • Hi,

    During the test, I used Ethernet to connect directly to the PC. I think it is OK to connect to the partner's MAC interface.According to what you said, if it is a MAC interface, where should I look for it?

  • Hello,

    I would advise checking the RX and TX signaling to ensure appropriate signals are obeying the timing specifications listed in datasheet. It is best practice to probe as close to the receiver as possible per line.

    Sincerely,

    Gerome

  • Hi,

    I used an oscilloscope to monitor the TX and RX clock signals.It is normal.Do I need to check the TX and RX data transmission pins again?

  • Hello,

    Yes, in order to check setup and hold times, it is important to check the data against the clock pins.

    Additionally, you can use IPERF if available to test unidirecitonal data transfer to understand if the RX or TX is being affected.

    Sincerely,

    Gerome

  • Hello,

    I will try,but I do not use IPERF ,can you tell me how to use it?Thank you !

    Regards,

    Wanglili

  • Hello,

    Please check out this link.

    https://iperf.fr/

    Sincerely,

    Gerome

  • I do not quite understand the test process. Is the hardware connected to the network port in the Linux environment? Is iperf used under Linux?Does the prerequisite hardware need to support this iperf tool?How to confirm?

  • Hello,

    IPERF is an application which can be installed, in which traffic can be sent and received by setting IP addresses. It is not part of regular application, but is a very useful tool to have for debugging.
    Sincerely,

    Gerome

  • This software is commonly used to test bandwidth, provided that the Ethernet can be connected, but I currently cannot ping the Ethernet.

  • Hello,

    I understand the constraint. In this case, the only other option would be to create a custom function to send traffic, have PHY be in MII loopback, and probe RX lines to understand if errors are happening there (indicating TX line), or if clean, then RX line might be suspect coming back to MAC.

    Sincerely,

    Gerome

  • Hi,

    How can I set the phy in MII loopback?Is that in dtbs?Can you provide a specific method?

  • Hi,

    Is there anything new?About PHY or others?

  • Hello,

    The PHY can be set into loopback by commanding Reg 0x0[14]. This can be done via PHYtool. For more information, please consult SNLA450 section 4.2.1.

    Sincerely,

    Gerome

  • Is there any news?We are anxiously waiting for the results.

  • Hello,

    I dont quite understand. I believed you were going to test to isolate which part of MAC interface is suspect.

    Sincerely,

    Gerome

  • Hi,

      Are you talking about verifying through loopback? I have not set it up yet, can you give me some help? For example, how to control using phytool command.

  • Hello,

    Please refer to SNLA450 section 4.2.1. for more information on using PHYtool and setting up.

    Sincerely,

    Gerome

  • Hi,

    I found a post link below

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1314903/am6442-icssg0-mii-doesn-t-work-in-sdk9-1-0-8/5451812#5451812

    I found out they are using AM6442,I checked the device tree file with them,found no big difference.According to his device tree, I modified and added it on my side“ti,pa-stats = <&icssg0_pa_stats>;”ti,mii-rt = <&icssg0_mii_rt>;”,when I compile, an error occurs. I cannot add ti in front of it. I wonder if my SDK version is inconsistent with his?

  • Hi,

    I used phytool to set phy to loopback mode. After the loopback mode setting was completed, I used the ifconfig command to check. The data corresponding to eth2 was sent and received as 0. What could be the reason?

    phytool read eth2/3/0
    0x3100
    root@am64xx-evm:~# phytool write eth2/3/0 0x6100

    root@am64xx-evm:~# phytool read eth2/3/16
    0x000d

    root@am64xx-evm:~# ifconfig
    eth0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 metric 1
    ether 12:e1:7d:f8:a3:e5 txqueuelen 1000 (Ethernet)
    RX packets 0 bytes 0 (0.0 B)
    RX errors 0 dropped 0 overruns 0 frame 0
    TX packets 0 bytes 0 (0.0 B)
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

    eth1: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500 metric 1
    ether 12:e1:7d:f8:a3:e6 txqueuelen 1000 (Ethernet)
    RX packets 0 bytes 0 (0.0 B)
    RX errors 0 dropped 0 overruns 0 frame 0
    TX packets 0 bytes 0 (0.0 B)
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

    eth2: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 metric 1
    inet 192.168.5.32 netmask 255.255.255.0 broadcast 192.168.5.255
    inet6 fe80::10e1:7dff:fef8:a3e7 prefixlen 64 scopeid 0x20<link>
    ether 12:e1:7d:f8:a3:e7 txqueuelen 1000 (Ethernet)
    RX packets 0 bytes 0 (0.0 B)
    RX errors 0 dropped 0 overruns 0 frame 0
    TX packets 37 bytes 4792 (4.6 KiB)
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

    lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 metric 1
    inet 127.0.0.1 netmask 255.0.0.0
    inet6 ::1 prefixlen 128 scopeid 0x10<host>
    loop txqueuelen 1000 (Local Loopback)
    RX packets 82 bytes 6220 (6.0 KiB)
    RX errors 0 dropped 0 overruns 0 frame 0
    TX packets 82 bytes 6220 (6.0 KiB)
    TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

    My network cable is never connected.

  • Hello,

    The purpose of register configuration/IPERF was to evaluate what portion of the MAC interface (which we suspect is contributing to the issue) is the culprit. Doing loopback itself won't expose the issue, but this combined with other steps would.

    The first goal is to understand if the TX communication is working. This can be done via IPERF where data is sent from the DUT board to a PC (which also has IPERF). If this is successful, the TX line is working. Thus the RX line may be suspect. This could also be checked by sending data from PC to DUT board's MAC. PHY is in default configuration in this test case.

    As a correlative datapoint, if PHY is put into MII loopback, you can scope out the TX and RX pins and check whether or not they are identical. If RX does not match with TX, it may be possible that the TX line is suspect.

    Sincerely,

    Gerome

  • Hi,

    Let me understand what you are saying. Can I check whether the TX and RX signals are consistent through the oscilloscope after I set it to loopback mode? Then configure the PHY to normal mode and verify TX and RX by using the IPERF tool. Am I right?

  • Hi,

    I still have a question, if I want to verify TX and I use the development board to ping my PC, is it unavailable to use Wireshark software to monitor? I used software to monitor and did not receive any TX packets. Can this explain the problem with the TX line?

    I also want to confirm with you that the SDK version number I am using is SDK8.06.00.42. Whether this version can support the mII interface Ethernet of ICSSG0?

    Waiting for your reply!

  • Hi,

    I used iperf to test, and the contents displayed on the evaluation board and virtual machine side are as follows:

    EVM:

    root@am64xx-evm:~# iperf -s
    ------------------------------------------------------------
    Server listening on TCP port 5001
    TCP window size: 128 KByte (default)
    ------------------------------------------------------------

    virtual:

    byf@byf-virtual-machine:~$ iperf -c 192.168.5.32
    connect failed: No route to host

    Does this result mean there is a problem with TX?I have three questions today. I hope you can see them and reply to me. Thank you very much!

  • Hello,

    Allow me to address your questions individually:

    1) Let me understand what you are saying. Can I check whether the TX and RX signals are consistent through the oscilloscope after I set it to loopback mode? Then configure the PHY to normal mode and verify TX and RX by using the IPERF tool. Am I right?

     - Yes, these are ways to correlate and determine what side is faulty; RX or TX side of MAC interface.

    2) I still have a question, if I want to verify TX and I use the development board to ping my PC, is it unavailable to use Wireshark software to monitor? I used software to monitor and did not receive any TX packets. Can this explain the problem with the TX line?

     - Wireshark should still work as it just sniffs to my knowledge, but IPERF would also help if you set static IP to bypass ARP (I believe this may be an obstacle especially dealing with communication working only in one way). However, this can point to TX line be suspect. I do think that checking the TX lines and ensuring setup/hold is being met, as well as confirming PHY is in correct operating mode would be good next steps.

    3) I also want to confirm with you that the SDK version number I am using is SDK8.06.00.42. Whether this version can support the mII interface Ethernet of ICSSG0?

     - I will allow Nick to comment on this. 

    Sincerely,
    Gerome

  •  - I will allow Nick to comment on this. 

    Nick is out of office this week. Feel free to ping the thread during the week of 14-Oct if you do not get a response.

    Regards, Andreas

  • Hi,

    Does have any answers?

  • Hi,

    Today is 15-Oct,is anything news?

  • Hi,

    I have been waiting for news from you for a few days. Is there any progress?

  • Hi,

    Does have any answers?For other hardware we designed, using the ICSSG0 of AM6422 to connect to DP83867 using the rgmii interface was also unsuccessful. Is it because the version I am using does not support it?Even if the network cable is plugged or unplugged, the connection status cannot be recognized. The following is the printed information.

    [    5.005259] davinci_mdio 30032400.mdio: Configuring MDIO in manual mode
    [    5.050256] davinci_mdio 30032400.mdio: davinci mdio revision 1.7, bus freq 1000000
    [    5.077721] davinci_mdio 30032400.mdio: phy[0]: device 30032400.mdio:00, driver TI DP83867
    [    5.092579] davinci_mdio 30032400.mdio: phy[1]: device 30032400.mdio:01, driver TI DP83867
    [    5.112754] k3-m4-rproc 5000000.m4fss: assigned reserved memory node m4f-dma-memory@a4000000
    [    5.186007] k3-m4-rproc 5000000.m4fss: configured M4 for remoteproc mode
    [    5.203488] k3-m4-rproc 5000000.m4fss: local reset is deasserted for device
    [    5.280771] remoteproc remoteproc0: 5000000.m4fss is available
    [    5.286772] platform 78000000.r5f: configured R5F for remoteproc mode
    [    5.304201] platform 78000000.r5f: assigned reserved memory node r5f-dma-memory@a0000000
    [    5.315396] remoteproc remoteproc1: 78000000.r5f is available
    [    5.327665] remoteproc remoteproc1: powering up 78000000.r5f
    [    5.333820] remoteproc remoteproc1: Booting fw image am64-main-r5f0_0-fw, size 86352
    [    5.333826] remoteproc remoteproc0: powering up 5000000.m4fss
    [    5.333840] remoteproc remoteproc0: Booting fw image am64-mcu-m4f0_0-fw, size 86084
    [    5.347652]  remoteproc1#vdev0buffer: assigned reserved memory node r5f-dma-memory@a0000000
    [    5.370865] virtio_rpmsg_bus virtio0: rpmsg host is online
    [    5.380261]  remoteproc1#vdev0buffer: registered virtio0 (type 7)
    [    5.390661] remoteproc remoteproc1: remote processor 78000000.r5f is now up
    [    5.406348] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev addr 0xe
    [    5.424837] remoteproc remoteproc2: 30034000.pru is available
    [    5.437564]  remoteproc0#vdev0buffer: assigned reserved memory node m4f-dma-memory@a4000000
    [    5.442572] platform 78400000.r5f: configured R5F for remoteproc mode
    [    5.450730] virtio_rpmsg_bus virtio1: rpmsg host is online
    [    5.452546] virtio_rpmsg_bus virtio1: creating channel ti.ipc4.ping-pong addr 0xd
    [    5.457932]  remoteproc0#vdev0buffer: registered virtio1 (type 7)
    [    5.474427] virtio_rpmsg_bus virtio1: creating channel rpmsg_chrdev addr 0xe
    [    5.480709] remoteproc remoteproc0: remote processor 5000000.m4fss is now up
    [    5.491402] remoteproc remoteproc4: 30004000.rtu is available
    [    5.501453] remoteproc remoteproc5: 3000a000.txpru is available
    [    5.509511] remoteproc remoteproc6: 30038000.pru is available
    [    5.544215] remoteproc remoteproc7: 30006000.rtu is available
    [    5.558462] platform 78400000.r5f: assigned reserved memory node r5f-dma-memory@a2000000
    [    5.584135] remoteproc remoteproc8: 3000c000.txpru is available
    [    5.618041] remoteproc remoteproc3: 78400000.r5f is available
    [    5.667186] remoteproc remoteproc9: 300b4000.pru is available
    [    5.713812] remoteproc remoteproc3: powering up 78400000.r5f
    [    5.719662] remoteproc remoteproc3: Booting fw image am64-main-r5f1_0-fw, size 93260
    [    5.739670]  remoteproc3#vdev0buffer: assigned reserved memory node r5f-dma-memory@a2000000
    [    5.748797] virtio_rpmsg_bus virtio2: rpmsg host is online
    [    5.749174] virtio_rpmsg_bus virtio2: creating channel rpmsg_chrdev addr 0xe
    [    5.765808]  remoteproc3#vdev0buffer: registered virtio2 (type 7)
    [    5.771981] remoteproc remoteproc3: remote processor 78400000.r5f is now up
    [    5.800326] remoteproc remoteproc10: 30084000.rtu is available
    [    5.845160] remoteproc remoteproc11: 3008a000.txpru is available
    [    5.864574] remoteproc remoteproc12: 300b8000.pru is available
    [    5.877761] remoteproc remoteproc13: 30086000.rtu is available
    [    5.901251] remoteproc remoteproc14: 3008c000.txpru is available
    [    7.651652] TI DP83867 30032400.mdio:00: attached PHY driver [TI DP83867] (mii_bus:phy_addr=30032400.mdio:00, irq=POLL)
    [    7.671468] TI DP83867 30032400.mdio:01: attached PHY driver [TI DP83867] (mii_bus:phy_addr=30032400.mdio:01, irq=POLL)
    [    7.692742] icssg-prueth icssg0-eth: TI PRU ethernet driver initialized: dual EMAC mode
    [    7.870014] usbcore: registered new interface driver usbfs
    [    7.877699] usbcore: registered new interface driver hub
    [    7.883292] usbcore: registered new device driver usb
    [  OK  ] Created slice system-systemd\x2dfsck.slice.
    [  OK  ] Found device /dev/mmcblk1p1.
    [  OK  ] Started udev Wait for Complete Device Initialization.
    [  OK  ] Started Hardware RNG Entropy Gatherer Daemon.
    [  OK  ] Reached target System Initialization.
    [  OK  ] Started Daily rotation of log files.
    [  OK  ] Started Timer service to update the IP on OLED each 10s.
    [  OK  ] Started Daily Cleanup of Temporary Directories.
    [  OK  ] Reached target Timers.
    [  OK  ] Listening on Avahi mDNS/DNS-SD Stack Activation Socket.
    [  OK  ] Listening on D-Bus System Message Bus Socket.
             Starting Docker Socket for the API.
    [  OK  ] Listening on dropbear.socket.
             Starting Reboot and dump vmcore via kexec...
             Starting File System Check on /dev/mmcblk1p1...
    [  OK  ] Listening on Docker Socket for the API.
    [  OK  ] Started Reboot and dump vmcore via kexec.
    [  OK  ] Reached target Sockets.
    [  OK  ] Reached target Basic System.
    [  OK  ] Started Job spooling tools.
    [  OK  ] Started Periodic Command Scheduler.
    [  OK  ] Started D-Bus System Message Bus.
             Starting Ethernet Bridge Filtering Tables...
             Starting Print notice about GPLv3 packages...
             Starting IPv6 Packet Filtering Framework...
             Starting IPv4 Packet Filtering Framework...
    [  OK  ] Started irqbalance daemon.
             Starting Matrix GUI...
             Starting startwlanap...
             Starting startwlansta...
             Starting System Logger Daemon "default" instance...
             Starting Login Service...
    [  OK  ] Started TEE Supplicant.
             Starting telnetd.service...
    [  OK  ] Started Ethernet Bridge Filtering Tables.
    [  OK  ] Started Matrix GUI.
    [  OK  ] Started IPv6 Packet Filtering Framework.
    [  OK  ] Started startwlansta.
    [  OK  ] Started startwlanap.
    [  OK  ] Started File System Check on /dev/mmcblk1p1.
    [  OK  ] Started IPv4 Packet Filtering Framework.
    [  OK  ] Started telnetd.service.
    [  OK  ] Reached target Network (Pre).
             Mounting /run/media/mmcblk1p1...
             Starting LSB: Expand Rootfs of boot device...
             Starting syslog.service...
             Starting Network Service...
    [  OK  ] Mounted /run/media/mmcblk1p1.
    [  OK  ] Listening on Load/Save RF …itch Status /dev/rfkill Watch.
    [    9.460619] cfg80211: Loading compiled-in X.509 certificates for regulatory database
    [    9.544984] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
    [  OK  ] Started System Logger Daemon "default" instance.
    [  OK  ] Started Login Service.
    [  OK  ] Started syslog.service.
    [  OK  ] Started Network Service.
             Starting Wait for Network to be Configured...
             Starting Network Name Resolution...
    [  OK  ] Started LSB: Expand Rootfs of boot device.
    [    9.966899] remoteproc remoteproc6: powering up 30038000.pru
    [    9.992735] remoteproc remoteproc6: Booting fw image ti-pruss/am65x-sr2-pru1-prueth-fw.elf, size 38496
    [   10.038261] remoteproc remoteproc6: unsupported resource 5
    [   10.053917] remoteproc remoteproc6: remote processor 30038000.pru is now up
    [   10.089591] remoteproc remoteproc7: powering up 30006000.rtu
    [   10.150037] remoteproc remoteproc7: Booting fw image ti-pruss/am65x-sr2-rtu1-prueth-fw.elf, size 30104
    [   10.225583] remoteproc remoteproc7: remote processor 30006000.rtu is now up
    [   10.266998] remoteproc remoteproc8: powering up 3000c000.txpru
    [   10.329497] remoteproc remoteproc8: Booting fw image ti-pruss/am65x-sr2-txpru1-prueth-fw.elf, size 35836
    [   10.396295] remoteproc remoteproc8: remote processor 3000c000.txpru is now up
    [   10.467277] icssg-prueth icssg0-eth: settime timeout
    [   10.500760] pps pps0: new PPS source ptp1
    [   10.541697] net eth1: started
    [   10.625939] remoteproc remoteproc2: powering up 30034000.pru
    [   10.663420] remoteproc remoteproc2: Booting fw image ti-pruss/am65x-sr2-pru0-prueth-fw.elf, size 38224
    [   10.722976] remoteproc remoteproc2: unsupported resource 5
    [   10.755533] remoteproc remoteproc2: remote processor 30034000.pru is now up
    [   10.790376] remoteproc remoteproc4: powering up 30004000.rtu
    [   10.823695] remoteproc remoteproc4: Booting fw image ti-pruss/am65x-sr2-rtu0-prueth-fw.elf, size 30872
    [   10.863689] remoteproc remoteproc4: remote processor 30004000.rtu is now up
    [   10.900971] remoteproc remoteproc5: powering up 3000a000.txpru
    [   10.935899] remoteproc remoteproc5: Booting fw image ti-pruss/am65x-sr2-txpru0-prueth-fw.elf, size 37328
    [   10.959693] remoteproc remoteproc5: remote processor 3000a000.txpru is now up
    [   10.979578] net eth0: started
    

  • Hello,

    For other hardware we designed, using the ICSSG0 of AM6422 to connect to DP83867 using the rgmii interface was also unsuccessful. Is it because the version I am using does not support it?

    For this RGMII interface issue, can you create a separate E2E thread share the result of "ethtool eth0", "ifconfig", and "dmesg | grep eth0" on that new thread? I want to keep these two issues (MII and RGMII) to keep the content clear on these E2E posts.

    And just to clarify, which Linux SDK version are you using in for this RGMII interface design?

    -Daolin

  • OK,I will create a new thread.I hope that relevant people can help with these two issues.Thank you!

  • Hello,

    Is there any progress on your side regarding the MII issue I mentioned?