• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 362 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:

AM5728: DP83869 : RGMII -1000BASEX not working

AM5728: AM5728 MDIO interface: how to validate useraccex contents with a specific Phyadd/regadd combination

Petru Lupas
Prodigy 40 points

Part Number: AM5728

Hello,

 We have a few questions regarding the operation of the MDIO interface in Sitara AM5728 CPU. We have the CPU MDIO interface connected to a

Marvel switch SMI interface.

 

In order to stress test the MDIO interface, we are sending read/write accesess, with preamble enabled, to an switch chipset,

into the device ID and the scratch pad registers (one 16bit register where we are writing an incremental pattern and

read back for verification).  These tests are done on our own port of Debian Linux, but, maybe we could have a look at TI SDK

driver code, to verify the implementation. Please provide some pointers.

 

After roughly 70 cycles (74 in the case of this particular test) successful accesses, our Software driver reports that bad data

was received (0xFFFF, which would mean no response from the switch). However, with an external debugger on the SMI bus,

we are seeing that the switch responded correctly with the 0x004B expected data, but the driver missed the “good” data from

the useraccess0 register, and, instead, read the data from the next Phy transaction, which went to an undefined phy, which

would explain the 0xFFFF data. The next Phy transaction was initiated automatically by the Phy polling unit.

 

The question would be: what mechanisms are in place so that the software driver would be able to corelate data read back

from the useraccess0 register with a specific Phyadd/Regadd combination where the data actually came from?

Or, to formulate it in a different way, what would be the best method of synchronizing a CPU register read access

to useraccessx registers with the actual SMI transactions so that, with a high probability of success, I can guarantee that

the data that I read back from useraccessx is actually coming from my initiated read access, and not from some subsequent

Phy accesses which are automatically initiated by the Phy polling state machines.

Thank you,

Petru

  • 0
    Prodigy 40 points

    Hello,

    Or, another way that we could address this is by disabling the Phy polling state machine.

    Could someone, please, provide so instructions on how to do that?

    Thank you so much,

    Petru

  • 0 in reply to Petru Lupas
    TI__Genius 14680 points

    Petru,

    TI does not directly support integrating external switches on the CPSW port though we do have customers who have been able to implement external switches

    The connection between the MAC and the switch needs to be defined as a fixed link. Grep in the Documentation/devicetree/bindings/net/ for “fixed-link”, this will return information on how to implement a fixed link. You will want to at fixed-link.txt. With this, the link status, speed and duplex are statically fixed and always present.

    We would recommend looking at Documentation/devicetree/bindings/net/dsa/dsa.txt, this might also be a solution you can leverage but is not something TI supports directly in the Processor SDK.

    Best regards,

    Dave

  • 0 in reply to Dave Bell
    Prodigy 40 points

    Hi Dave,

    Thank you for your answer, but it does not address my question.

    We have multiple Phys and the switch connected to the SMI interface.

    We need to be able to perform configurations on all the devices connected to the SMI

    interface.

    From an SMI perspective, there is not much of a difference between an switch

    ASIC or a Phy ASIC, if the SMI controller would function properly.

    The problem is that, the SMI controller that is available on the AM5728 has a lot

    of  issues:

    # the lack of flexibility in turning on/off the automatic Phy polling unit, without losing the SMi functionality;

    # even the Phy polling function for link status detection does not work properly;

    # the data validation information, on read cycles, to specify what Phy address/register address is the data

       coming from, especually with a Phy polling unit that goes and accesses undefined Phy addresses;

    # the option to specify a Phy address range that the user would want to have in polling mode;

    These would be just a small subset of missing functions, which basically makes this MDIO controller pretty

    much unusable ...

    Sorry for my bluntness,

    Petru

  • 0 in reply to Petru Lupas
    Prodigy 40 points

    I believe that the answers in this thread kinda solved my question ... there is no fix,

    but a bit-bang driver of the GPIOs, if they are convertible to do that ... depending what

    other GPIOs in the bank are used ...

    Thanks,

    Petru