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.

AM62L-PROCESSOR-SDK: ADIN Phy Detection in U-Boot

Part Number: AM62L-PROCESSOR-SDK
Other Parts Discussed in Thread: AM62L

Tool/software:

Hi team,

When i was testing the first release sdk in u-boot level i was able to properly detect the adin phy in my board.But with the same changes done in the u-boot source in the new released sdk version i was unable to get that automatic detection .Adin Phy gets detected only after i give the command dhcp.

With the  11.00.15.05 SDK 




With the 11.00.05.02  SDK



Net: ADIN1300 PHY detected at addr 4

I want this to automatically detect as it was in the old sdk.Where should i have to make the changes.

Regards,
Dheeraj K

  • Hi , 

    I have made the changes in the ethernet driver and this issue got solved.



    Could you please let me know will this change effect in any other way.What was the reason for this change in new sdk?

  • Hi Team,

    I have seen many changes regarding the ethernet driver in the linux source comapared to old sdk and the new one ,which is currently creating some conflict in adin phy initialization sequence.

    Previous SDK Flow:
    U-Boot -> Ethernet -> ADIN PHY LED-OFF-->kernel---> Ethernet driver-->LED OFF --> Adin PHY LED OFF-->LED Will glow only if link (cable) is connected.

    New SDK Flow:
    U-Boot->Ethernet -> ADIN PHY LED ON-->dhcp(manually )--loads adin driver ---LED OFF-->kernel--> Ethernet driver LED ON--->Adin PHY LED off--->Glows when cable is connected.

    LED:LINK ACTIVE LED

    Previous SDK (Old Flow):

    1. U-Boot Stage:

      • Ethernet initialization happens.

      • ADIN PHY LED is turned OFF after initialization.

    2. Kernel Stage:

      • Kernel Ethernet driver loads.

      • ADIN PHY LED remains OFF by default.

      • The LED only turns ON when an Ethernet cable is physically connected (link is established).

    New SDK (Current Flow):

    1. U-Boot Stage:

      • Ethernet initialization happens.

      • ADIN PHY LED turns ON immediately (even when no cable is connected).

    2. Manual DHCP (in U-Boot):

      • During DHCP attempt, the ADIN driver loads internally, and as part of this, the LED turns OFF.

    3. Kernel Stage:

      • Kernel Ethernet driver loads and LED Turns ON 

      • ADIN PHY LED turns OFF again during Adin driver probe/initialization.

      • When the link is established (cable connected), the LED behavior aligns back to normal (LED ON when link is up).


    I wanted the flow to be as in the old sdk .What changes has to be done could anyone let me know?

  • Hi Dheeraj,

    Could you please let me know will this change effect in any other way.What was the reason for this change in new sdk?

    I believe that the commit in the following link explains the reason for this change. Please let us know if you have follow up questions about it. https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/drivers?h=ti-u-boot-2025.01&id=b26d4477bc5e386179266219511c66e5df255e38 

    I wanted the flow to be as in the old sdk .What changes has to be done could anyone let me know?

    Is specifically what you are looking for are what modifications you need to make ensure the flow is the same as what you observed on the older SDK?

    While I check internally on this, is there a particular reason you are moving from the old SDK to the newer SDK if the old SDK implements the flow you expected to have?

    Additionally, do you see a similar initialization flow difference when using the TI AM62L EVM which uses a DP83867 PHY instead of the ADIN PHY on your custom board? I need to ask this to see if the same difference is reproducible on an TI EVM.

    -Daolin

  • Hi Daolin, 

    Thank you for your support.

    I have decided to proceed with the current flow using the new SDK. In case I need to revert to the old SDK, I will reach out to this thread again.

    For now, it would be preferable not to spend additional time on this until my internal team finalizes and confirms the expected workflow. Once it is confirmed, I will update you accordingly.

    Regards,
    Dheeraj K

  • Hi Dheeraj, 

    Sounds good, once you confirm, please do let us know if this issue is something we need to look into from TI side.

    -Daolin