• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 33 subscribers
  • Views 1768 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.

Original question:

Linux/DP83822I: device tree configuration for TI DP838xx drivers

Linux/DP83822I: DP83822 driver issue delaying production run with >200k TI parts

John Boyd15
Prodigy 135 points
Part Number: DP83822I

Tool/software: Linux

Hi, my company is launching a new product with several TI parts in the design, including a DP83822 ethernet PHY. We have had issues in the past months of design getting Linux drivers configured properly to work with this PHY. At this point, the rest of our design is nearing ready for production, but this DP83822 driver issue is beginning to stress our design schedule and will quickly lead to production delays. We have tried going through the forums for support on this chip, but our post seems not to be getting much attention from TI support. Is there an official support channel we can go through to get quick resolution of this driver issue?

Here is the forum post we are currently working with: e2e.ti.com/.../747135

As a precaution, we have begun re-designing our ethernet subsystem to accommodate a PHY from a different chip vendor. We would prefer to use this TI part, but if we are not able to resolve these driver issues soon, then the cost of production delays will force us to go with an alternate vendor.

  • 0
    TI__Mastermind 23675 points
    Hi John,

    Can you please send me the schematic for the PHY portion?
    Have you tried attaching a cable to the MDI to see if LINK can be established with a partner?
    This will help in the debug effort.
    Also, is there any internal pull that you are aware of for the attached MAC?
    Can you please probe each bootstrap pin when you hold the device in RESET?
    This will help let us know what mode the PHY is getting configured in.
  • 0 in reply to Ross Pimentel
    Prodigy 135 points

    Thank you for the quick reply, Ross. Please see my responses to your questions below:

    Ross Pimentel said:
    Can you please send me the schematic for the PHY portion?


    I cannot share these files publicly. Can you provide me a TI email so I can share the schematics with you privately?

    Ross Pimentel said:
    Have you tried attaching a cable to the MDI to see if LINK can be established with a partner?

    We have tried connecting a cable. With no cable inserted, LED_0 is on indicating "good link". When a cable is inserted, LED_0 remains on indicating "good link" still. This seems counter-intuitive to me. I expected the LED to be off with no cable present and on when an active network cable is inserted.

    Ross Pimentel said:
    Also, is there any internal pull that you are aware of for the attached MAC?

    The attached MAC has no internal pulls according to the datasheet. For reference, we are connecting the DP83822 PHY directly to the MAC pins of a Samsung Artik 530. Datasheet here.

    Ross Pimentel said:
    Can you please probe each bootstrap pin when you hold the device in RESET?

    I will take these measurements and reply back shortly.

    Thanks,

    John

  • 0 in reply to Ross Pimentel
    Prodigy 135 points

    In response to your last question, here are the measured values on the strap pins, with the PHY held in reset:

    COL (29)	= PU 40K
RX_D0 (30)	= PD 7.73K
RX_D1 (31)	= PD 7.73K
RX_D2 (32)	= PD 7.83K
RX_D3 (1)	= PD 9.38K
LED_0 (17)	= PU 22K
CRS (27)	= PU 17.2K
RX_ER (28)	= PD 1.8K + PU 880K
RX_DV (26)	= PD 7.61K

  • 0 in reply to Ross Pimentel
    Prodigy 135 points

    Ross,

    Could you also point me to a reference Linux device tree configuration for the DP83822?

  • 0 in reply to John Boyd15
    TI__Mastermind 23675 points
    Hi John,

    Sorry for the delay.
    I was ooo for US holiday.

    Thank you for the bootstrap values above and the datasheet of the processor.
    For your your application, can you confirm that you are trying to operate in RGMII?
    Is there internal delay implemented in the processor?
    With the combination on RX_ER, it looks like you will bootstrap to MII operation with Auto-MDIX disabled.

    I have sent you a message over E2E. Please send me an email with your schematic attached.

    Here is the linux tree:
    path: root/drivers/net/phy/dp83822.c
    git.kernel.org/.../dp83822.c
  • 0 in reply to Ross Pimentel
    Prodigy 135 points
    Hi Ross,

    I hope your holiday went well!

    Yes, we are operating in RGMII.

    We have attempted to configure a sufficient delay on the host, but we are not confident in our device-tree configuration for this driver. We have looked through the driver source (same as what you linked, above), but that does not provide any documentation about proper device-tree configuration. Is there a reference linux system that uses this PHY, for us to inspect the Linux device-tree?

    I have just emailed you our schematics.

    Thanks,
    John
  • 0 in reply to John Boyd15
    TI__Mastermind 23675 points
    Hi John,

    I will take this offline with you and review your schematics.
    I'll also discuss this with our Linux expert to resolve the device tree issue.
  • 0 in reply to Ross Pimentel
    Prodigy 135 points

    I am updating this public thread, in-case anyone in the community is able to offer assistance with regards to Linux configuration for this PHY. Ross has been very helpful in reviewing the schematics and hardware configuration, but we would also greatly appreciate help from anyone familiar with the Linux side this problem.

    Currently, we are able to manually communicate to the PHY from the the Linux host, using 'mdio read' in u-boot. This confirms that the PHY is electrically available to the host. The confusion we are having, is why the TI PHY driver is unable to communicate with the PHY. This points to a Linux driver or kernel configuration issue, and we really need assistance diagnosing this issue from the Linux side.

    For example, we have an alternate design using a Realtek PHY. Realtek provides a reference driver and a device-tree configuration (which we were able to adapt for our design). This alternate design works, and we are now in the process of updating our final design to use this Realtek part. We would really prefer to use the TI part, but unfortunately at this point we do not have the information we need to configure our Linux build to communicate with this TI PHY. Is anyone able to provide a reference Linux build, so that we can examine the device-tree configuration and adapt that to our design?
    Thanks,
    John