• State
  • Locked Locked
  • Replies 19 replies
  • Subscribers 99 subscribers
  • Views 793 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

AM623: Cannot establish Ethernet RMII data communication(Tx/Rx) between MAC and PHY

AM623: [Re-open]Cannot establish Ethernet RMII data communication(Tx/Rx) between MAC and PHY

nakashima.bo
Prodigy 30 points
Part Number: AM623

Dear SoC experts,

This thread is a re-opening of the following thread.
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1269687/am623-cannot-establish-ethernet-rmii-data-communication-tx-rx-between-mac-and-phy/4841666#4841666

This is because I closed the following thread and asked PHY experts to investigate about the issue of the title, but as a result there was no problem on the PHY side and I was asked from them to re-investigate the SoC side.
It can be shown on around the end of this thread.
https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1275932/dp83825i-ephy-schematics-review

Would you please confirm whole of this thread, and consider about the causes of this issue in your team again?

Thanks,
Nakashima

  • 0
    TI__Mastermind 39380 points

    Hi,

    Thank you for the update, I will discuss with the HW apps team member and respond tomorrow.

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    Prodigy 30 points

    Schuyler-san,

    After your last comment, I have not received any response from you until today...
    Would you please inform us the result of the discussion and your progresses of investigation about this issue?

    Thanks,
    Nakashima

  • 0 in reply to nakashima.bo
    Prodigy 30 points

    Dear SoC experts,

    Please reply about the progresses of investigation about this issue in your team asap.
    It is OK that someone other than Mr. Schuyler Patton will reply, anyway I want to confirm that the investigation have not stopped.

    Regards,
    Nakashima

  • 0 in reply to nakashima.bo
    TI__Mastermind 39380 points

    Hi,

    One of HW apps team members reviewed the hardware information provided and the design looks correct. The concerning data point is that the data lines to the PHY are not showing any traffic. The MAC HW statistics are showing traffic both sent and received. There are also not any CRC errors reported.

    Please provide the part of the DTS that shows pin mux for all network ports. I looked through the e2e threads, I thought I saw a wireshark capture but I don't now. If possible please attach a wireshark capture from the PC perspective.

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    Prodigy 30 points

    Dear Schuyler-san,

    Thanks for your reply.
    Please confirm the attached DTS file.

    I will take Wireshark logs and send them to you tomorrow.

    Thanks,
    Nakashima
    k3-am625-sk (1).zip

  • 0 in reply to nakashima.bo
    TI__Mastermind 39380 points

    Hi,

    Please attach the boot log as well, I am interested to see if the driver is recognized by the kernel.

    After reviewing the DTS I noticed that one of the CPSW interfaces does not set it's status. Another think I noticed is the pin mux for the CPSW is inside of #if 0 block. There is a label difference between #if 0 and the else block, I am not sure this would have compiled. Is this the correct DTS?

    Could you also please attach a snippet of the schematic showing the CPSW ports?

    Thank you and Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    Prodigy 30 points

    Dear Schuyler-san,

    Thanks for your reply.

    For DTS configuration, I asked my colleagues to check about your notification.

    For boot log, please confirm the attached txt file. (boot-log231026.txt)

    For Wireshark logs, I took three log data as followings.
    IP address of PC is 192.168.39.5, that of PCB is 192.168.39.1.
     (1) After connect LAN cable between PC and PCB : wireshark-log1_231026.pcapng
     (2) Ping from PCB to PC : wireshark-log2_231026.pcapng
     (3) Ping from PC to PCB : wireshark-log3_231026.pcapng
    Please confirm them.

    For a snippet of the schematic showing the CPSW ports, please confirm the attached schematic diagram pdf. (EthernetCircuit20230914.pdf)


    Thanks,
    Nakashima

    boot-log231026.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    U-Boot SPL 2021.01-00003-g348dcefba7-dirty (Oct 03 2023 - 11:04:17 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill Capybar')
    SPL initial stack usage: 13424 bytes
    Trying to boot from MMC1
    1
    2
    3
    4
    5
    6
    mmc_start_init:0
    10 0
    111
    112
    113
    114
    11 0
    mmc_complete_init:0
    Loading Environment from MMC... OK
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    wireshark-log_231026.zip
    6177.EthernetCircuit20230914.pdf

  • 0 in reply to nakashima.bo
    TI__Mastermind 39380 points

    Hi,

    Thank you for the bootlog, wireshark capture files and the schematic. 

    My observations are:

    - I see the CPSW driver initializing and both PHYs are being identified during boot. I do not see a link up status. Is the cable connected after boot and after the boot log is not being captured anymore? This is odd since in the previous post the link the ethtool eth0 shows a link detected, this should have printed in the boot log somewhere. 

    - I only see in the second Wireshark capture an ARP message with this address coming from the PCB eth0 HWaddr 34:08:E1:87:A8:CA. This is eth0 on the PCB according to ifconfig from the previous thread. I do not see the PCB responding to the ARP message with a Ping request. Since the PCB continues to send broadcasts asking for who has the ping address indicates that the PCB is most likely not receiving the message from the PC. Also of note here is that since the PC is receiving an ARP message from the PCB this signals should be viewable on the scope.

    - I was comparing the HW stats between the earlier thread and this one. There are different IP addresses in use. I would like to ask for another test with the following, only one cable is attached to eth0 and a direct connect to the PC and use the current IP address for the PC and PCB. After booting the board please capture the results of ifconfig -a (after you have set the ip address), ethtool eth0 and also please capture ifconfig -S eth0 before issuing the ping command and then please capture ethtool -S eth0 after the Ping command is stopped. The reason I am asking for this is that the earlier thread showed at the MAC stats at the HW level showing both TX and RX packets. The data today implies the RX path is not working since the PCB keeps sending the ARP request. 

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    Prodigy 30 points

    Hello Schuyler-san,

    Thanks for your comments.
    Sorry, as you guess, connecting LAN cable between PCB and PC was after finished taking boot logs.

    I took the boot log and the wireshark log again.
    These logs include all of the following sequences.
     (1) PCB Start up
     (2) Run "ifconfig -a"
     (3) Run "ethtool eth0"
     (4) Run "ethtool -S eth0"
     (5) Ping from PCB to PC
     (6) Run "ethtool -S eth0" after (5)
     (7) Ping from PCB to PC
     (8) Run "ethtool -S eth0" after (7) 

    Please confirm these logs, I wish that they would include what is enough you want to confirm.

    And, for dts file, would you please confirm the attached dts file again?
    The attached dts file is the newest one, and not same with what I sent you before.
    After your comments, my colleagues have compared dts file between the one which I sent you and the newest one, then he find something different. I am sorry. 

    Thanks,
    Nakashima

    boot-log_all231027.txt
    wireshark-log_all231027.zip
    k3-am625-sk_231027.zip

  • 0 in reply to nakashima.bo
    TI__Mastermind 39380 points

    Hi,

    Thank you for the boot log, wireshark log and the DTS.

    Looking at the HW statistics I see the packets are being sent and received on eth0. The wireshark log show the pc responding to ARP requests from PCB  but the PCB while receiving packets is not acknowledging the Ping response from the PC. The PCB keeps sending the ARP request. It appears that the kernel is not processing the Ping response.

    So lets look for reasons why the kernel may not acknowledge of the ARP response. Please attach the results of these two commands:

    ip route show table local
    arp

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    Prodigy 30 points

    Hello Schuyler-san,

    I got the information from PCB by ip route command as the attached log, please confirm it.

    For arp command,  the command on your request was just "arp" and I run this command in the log, but I guess that it is not what you want...
    Please correctly tell me the command you want me to do.

    Thanks,
    Nakashima

    iproute-log231030.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    U-Boot SPL 2021.01-00003-g348dcefba7-dirty (Oct 03 2023 - 11:04:17 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill Capybar')
    SPL initial stack usage: 13424 bytes
    Trying to boot from MMC1
    1
    2
    3
    4
    5
    6
    mmc_start_init:0
    10 0
    111
    112
    113
    114
    11 0
    mmc_complete_init:0
    Loading Environment from MMC... OK
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to nakashima.bo
    TI__Mastermind 39380 points

    Hi,

    I apologize as I will need to respond to your answer tomorrow after I have time to review it in more detail.

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    Prodigy 30 points

    Schuyler-san,

    Appx a week have passed from your last comment on this thread.
    Please inform us about your progresses of reviewing as soon.

    Thanks,
    Nakashima

  • 0 in reply to nakashima.bo
    TI__Mastermind 39380 points

    Hi,

    At the moment I cannot see the reason for why the ARP packets are not being received by the Processor. The ARP table is empty, that is consistent since the ARP responses are not being received despite the HW stats showing packets are being received.

    Are there any IP tables rules being setup? Any packet filtering?

    Please run this command in the background and capture the data to file call eth0.pcap, example below. This could generate a lot of traffic data if left running too long. You can kill the capture after you stopped the ping command. You can look at the file using Wireshark but you will to move to a machine running Wireshark.

    &tcpdump -i eth0 -nn -s0 -vv > eth0.pcap

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    Prodigy 30 points

    Long time no see Schuyler-san,

    Thanks for your comments.

    I tried to do the procedure which you suggested.
    The attached files are boot-log and wireshark pcap file, but this wireshark file cannot be opened by Wireshark application in my PC so the format of this file may be incorrect.
    Please confirm them.

    Thanks,
    Nakashima

    teraterm-log231110.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    U-Boot SPL 2021.01-00003-g348dcefba7-dirty (Oct 03 2023 - 11:04:17 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill Capybar')
    SPL initial stack usage: 13424 bytes
    Trying to boot from MMC1
    1
    2
    3
    4
    5
    6
    mmc_start_init:0
    10 0
    111
    112
    113
    114
    11 0
    mmc_complete_init:0
    Loading Environment from MMC... OK
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    eth0.zip

  • 0 in reply to nakashima.bo
    TI__Mastermind 39380 points

    Hi,

    I apologize I said the wrong command to capture using the tcpdump command.

    Please try this command:

    tcpdump -i eth0 -s 65535 -w eth_debug.pcap &

    Run the ping command and then after a period of time (for about 30 seconds) use the ps command to find the tcpdump pid and then issue a kill -9 <tcpdump pid>.

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    Prodigy 30 points

    Hello Schuyler-san,

    Thanks for your feedback.

    I tried the commands which you asked me, and I got wireshark log data "eth_debug.pcap" from PCB as attached log file, which I can see on Wireshark application in my PC.
    And, another attached log file "EthernetLog231113_pc.pcapng" is the wireshark log captured on PC side, from PCB power-on to kill pcbdump command on SoC.

    Please confirm them.

    Thanks,
    Nakashima

    teraterm-log231113.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    U-Boot SPL 2021.01-00003-g348dcefba7-dirty (Oct 03 2023 - 11:04:17 +0900)
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.6.4--v08.06.04 (Chill Capybar')
    SPL initial stack usage: 13424 bytes
    Trying to boot from MMC1
    1
    2
    3
    4
    5
    6
    mmc_start_init:0
    10 0
    111
    112
    113
    114
    11 0
    mmc_complete_init:0
    Loading Environment from MMC... OK
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    eth_debug231113.zip

  • 0 in reply to nakashima.bo
    TI__Mastermind 39380 points

    Hi, 

    Thanks for both pcap captures. On the pcb there are not any ARP packets making it up the network stack.

    The statistics from the previous post show the packet are p0 good rx frames but not the good rx frames. I will to clarify with the ip designer regarding the difference between these statistics.

    If you are running a custom configured kernel could you please try a Ti default built kernel? 

    Unfortunately I am not able to explain this behavior. 

    Best Regards,

    Schuyler

  • 0 in reply to Schuyler Patton
    Prodigy 30 points

    Hello Schuyler-san,

    Thanks for your comments.

    Schuyler Patton said:
    If you are running a custom configured kernel could you please try a Ti default built kernel? 

    Yes, we are running a kernel we have customized, but my colleague says that the parts of kernel which we have only customized are DTS file I provide you before, and the attached configuration file.
    ".config_def" is Ti default file, and ".config_ngk" is what we have customized from ".config_def" and is using on our PCB now.

    Firstly, would you please confirm whether there is any strange point in this custom configuration?

    Thanks,
    Nakashima

    1106.config.zip