• State Resolved
  • Locked Locked
  • Replies 20 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 813 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.

DP83867CR: DP83867

Mahesh Gaikwad
Prodigy 30 points
Part Number: DP83867CR

I am trying to interface DP83867 with Jetson ORIN.

I see error as below

Fullscreen
1
2
3
[ 20.163987] mdio_bus 2310000.ethernet: MDIO device at address 0 is missing.
[ 20.172251] nvethernet 2310000.ethernet: failed to connect PHY
[ 20.179193] net eth0: ether_open: Cannot attach to PHY (error: -19)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

My DTS file update is as below

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
ethernet@2310000 {
status = "okay";
nvidia,mac-addr-idx = <0>;
nvidia,max-platform-mtu = <8000>;
nvidia,pause_frames = <0>;
local-mac-adress = [1a 2b 3c 4d 5e 6f];
nvidia,phy-reset-gpio = <&tegra_main_gpio TEGRA234_MAIN_GPIO(G, 5) 0>;
phy-handle = <&phy>;
phy-mode = "rgmii-id";
mdio {
compatible = "nvidia,eqos-mdio";
#address-cells = <1>;
#size-cells = <0>;
phy: phy@0 {
reg = <0>;
compatible = "ethernet-phy-ieee802.3-c22";
tx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
rx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
ti,max-output-impedance;
// ti,clk-output-sel = <DP83867_CLK_O_SEL_CHN_A_RCLK>;
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Hillman Lin
    Prodigy 30 points

    Thanks for providing the document,

    We followed the document and still see issues. 

    We see following message on dmesg

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    orin@orin-desktop:~$ sudo dmesg | grep ethernet
    [ 10.852563] nvethernet 2310000.ethernet: Adding to iommu group 51
    [ 10.859607] nvethernet 2310000.ethernet: failed to read skip mac reset flag, default 0
    [ 10.868401] nvethernet 2310000.ethernet: failed to read MDIO address
    [ 10.875561] nvethernet 2310000.ethernet: setting to default DMA bit mask
    [ 10.883101] nvethernet 2310000.ethernet: missing nvidia,pad_auto_cal_pu_offset, setting default 0
    [ 10.892849] nvethernet 2310000.ethernet: missing nvidia,pad_auto_cal_pd_offset, setting default 0
    [ 10.911517] nvethernet 2310000.ethernet: Ethernet MAC address: 48:b0:2d:94:ac:db
    [ 10.920071] nvethernet 2310000.ethernet: macsec param in DT is missing or disabled
    [ 10.928472] nvethernet 2310000.ethernet: Macsec not supported/Not enabled in DT
    [ 10.937803] nvethernet 2310000.ethernet: eth0 (HW ver: 53) created with 8 DMA channels
    [ 12.921233] using random self ethernet address
    [ 12.926362] using random host ethernet address
    [ 13.646843] using random self ethernet address
    [ 13.652101] using random host ethernet address
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Attaching waveforms we montiored, one if on Reset Pin [reset-pin-dp83867.jhpg ]and another is on rx-clk and rx-do on DP83867 [rx-clk-andrx-d0.jpg]

    We also see SCLK and SDA toggle on MDIO lines at bootup post that it stops

    Please advice

  • 0 in reply to Mahesh Gaikwad
    Prodigy 30 points

    Based on response for NVIDIA we hear that the errors we see arent fatal.

    But we still dont see any transactions on PHY....no interrupts incrementing when we do ifconfig eth0 up/down

  • 0 in reply to Hillman Lin
    Prodigy 30 points

    I ran mdio utility available at https://github.com/wkz/mdio-tools [this was suggested in ti-forum]

    Attaching the outcome post running that utility in target 

    mdio-tool-out.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    orin@orin-desktop:~/tools/mdio-utils/mdio-tool/build$ sudo ./mdio-tool -e eth0 -r -a 0 -l 50
    Probed phyaddr: 0
    PHY: 0|REG: 0 ---> 0x1140
    PHY: 0|REG: 1 ---> 0x7949
    PHY: 0|REG: 2 ---> 0x2000
    PHY: 0|REG: 3 ---> 0xa231
    PHY: 0|REG: 4 ---> 0x01e1
    PHY: 0|REG: 5 ---> 0x0000
    PHY: 0|REG: 6 ---> 0x0064
    PHY: 0|REG: 7 ---> 0x2001
    PHY: 0|REG: 8 ---> 0x0000
    PHY: 0|REG: 9 ---> 0x0300
    PHY: 0|REG: 10 ---> 0x0000
    PHY: 0|REG: 11 ---> 0x0000
    PHY: 0|REG: 12 ---> 0x0000
    PHY: 0|REG: 13 ---> 0x401f
    PHY: 0|REG: 14 ---> 0x0000
    PHY: 0|REG: 15 ---> 0x3000
    PHY: 0|REG: 16 ---> 0x5048
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I am now analyzing these registers and would appreciate your views and input on this

  • 0 in reply to Mahesh Gaikwad
    TI__Mastermind 25745 points

    Hi Mahesh,

    Regarding to the register above 0x0031, it is an extended registers. Please follow the instruction below to read those extended regsiters:

    --

    Regards,

    Hillman LIn

  • 0 in reply to Hillman Lin
    Prodigy 30 points

    Thanks!

    Probably a novice question.

    Why do i read these extended registers, just trying to understand is there something on those extended registers that needs to be checked/wrote.

    Do you see any issues with regsiters reads from 0x00 0x1F are contents of those right.

    What i heard from my hardware engineers is they have disabled Auto-Negotiations on HW, not sure how they did that but do we do anything specific on SW to manage this.

    Will read those extended registers and revert.

  • 0 in reply to Mahesh Gaikwad
    TI__Mastermind 25745 points

    Hi Mahesh,

    Extended register are required for register above 0x001F. Those registers are store in the different library that is why extended register access is required. I will wait for your response on the extended register access.

    --

    Regards,

    Hillman Lin

  • 0 in reply to Hillman Lin
    Prodigy 30 points

    We are reading extended registers.

    As a first step we tried reading register 0x0170 and wanted to verify if we get consistent reads.

    We see varying results with each read.

    Can you please have a look and advice if we are missing something here.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    orin@orin-desktop:~/tools/mdio-utils/mdio-tool/build$ sudo ./mdio-tool -e eth0 -w -a 0x0D -v 0x001F
    Probed phyaddr: 0
    PHY: 0|REG: 13 <--- 0x001f
    orin@orin-desktop:~/tools/mdio-utils/mdio-tool/build$ sudo ./mdio-tool -e eth0 -w -a 0x0E -v 0x0170
    Probed phyaddr: 0
    PHY: 0|REG: 14 <--- 0x0170
    orin@orin-desktop:~/tools/mdio-utils/mdio-tool/build$ sudo ./mdio-tool -e eth0 -w -a 0x0D -v 0x401F
    Probed phyaddr: 0
    PHY: 0|REG: 13 <--- 0x401f
    orin@orin-desktop:~/tools/mdio-utils/mdio-tool/build$ sudo ./mdio-tool -e eth0 -r -a 0x0E
    Probed phyaddr: 0
    PHY: 0|REG: 14 ---> 0x0000
    orin@orin-desktop:~/tools/mdio-utils/mdio-tool/build$ sudo ./mdio-tool -e eth0 -w -a 0x0D -v 0x001F
    Probed phyaddr: 0
    PHY: 0|REG: 13 <--- 0x001f
    orin@orin-desktop:~/tools/mdio-utils/mdio-tool/build$ sudo ./mdio-tool -e eth0 -w -a 0x0E -v 0x0170
    Probed phyaddr: 0
    PHY: 0|REG: 14 <--- 0x0170
    orin@orin-desktop:~/tools/mdio-utils/mdio-tool/build$ sudo ./mdio-tool -e eth0 -w -a 0x0D -v 0x401F
    Probed phyaddr: 0
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Hillman Lin
    Prodigy 30 points

    Hello Hillman Lin,  Any advice, please

  • 0 in reply to Mahesh Gaikwad
    TI__Mastermind 25745 points

    Hi Mahesh,

    Based on the register read, it seems like the PHY is not linking up based on register 0x0001.

    Let look at the hardware standpoint to understand why the PHY is not linking up. If possible, could you send us the schematic around the MDI lines or the connector side?

    --

    Regards,

    Hillman Lin

  • 0 in reply to Mahesh Gaikwad
    Prodigy 30 points

    Shared just the schematics page, would appreciate your insights

  • 0 in reply to Hillman Lin
    Prodigy 30 points

    Strap details i got from our HW engineer

  • 0 in reply to Mahesh Gaikwad
    Prodigy 30 points

    Hi Hillaman Lin, any advice?

  • 0 in reply to Mahesh Gaikwad
    TI__Mastermind 25745 points

    Hi Mahesh,

    Based on the schematic I have couple questions want to confirm with the customer:

    • Is customer using integrated RJ45 connection? (transformer are internally inside the transformer)
    • Is there any DC isolation on the MDI lines?
    • If possible, may I ask what is the MDI traces lengths?

    Have customer try it with another DP83867PHY and see if they are able to get a link up?

    --

    Regards,

    Hillman Lin

  • 0 in reply to Hillman Lin
    Prodigy 130 points

    Hi Hillman,

    Please find details below-

     

    • Is customer using integrated RJ45 connection? (transformer are internally inside the transformer)

    HW Engineer- Yes, we used 7499111614A which is having internal transformer. see page 2 

    www.we-online.com/.../7499111614A.pdf

    • Is there any DC isolation on the MDI lines?

    HW Engineer- No, from PHY it is directly connected to RJ45 connector which is having internal transformer.

    • If possible, may I ask what is the MDI traces lengths?

    Min is 893.11mils max is 895.02mils

    One more observation - GTX CLK Pin#29 we are getting 125MHz while RX_CLK pin#32 we are getting 2.5MHz.

    Thanks

    Sagar

  • +1 in reply to Sagar kumar
    TI__Mastermind 25745 points

    Hi Kumar,

    If the PHY has no link up, the PHY will default in 10Mbps therefore the RX_CLK is generating 2.5MHz.

    The main issue should be around the MDI lines. 

    One more thing I would like to confirm is the different link partner. Is customer able to try using this board to another DP83867PHY board and see if they are able to link up? It is easier to debug based on two DP83867PHY so that we can tune the registers on both side.

    We also have DP83867 troubleshooting guide that might be helpful:

    --

    Regards,

    Hillman Lin

  • 0 in reply to Hillman Lin
    Prodigy 130 points

    Hi Hillman,

    Thanks for your support. 1G is working now. we found Mirror enable strap on Mode 3 after changing to Mode1 it is start working.

    Thanks

    Sagar

  • 0 in reply to Hillman Lin
    Prodigy 30 points

    Thanks for you support, we have our interface up and running.

    Appreciate you insights and guidance in make this possible.

    -maheshG

  • +1 in reply to Mahesh Gaikwad
    TI__Mastermind 25745 points

    Hi Kumar and Gaikwad,

    Glad that it works. I will close this tread for now.

    --

    Regards,

    Hillman Lin