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.

AM6411: AM64x Boot over ethernet on Custom board, how MDIO scan with multiple PHY on the same MDIO bus ?

Part Number: AM6411
Other Parts Discussed in Thread: TPS65220, SK-AM64B

Hello i would like to better understand what it is mandatory for having Boot over ethernet supported on AM64x cpu if we are using PMIC TPS65220 and 2xPHY DP83822 with RMII config on same MDIO bus. 

I understand that PHY should be power-up and out of reset before the BOOTROM code execution. 

I also understand that only boot over RMII2 connect to CPSW3G is supported (following Table 4-24. RMII Pin Usage).

We have configured the BOOTMODE pins to support boot over Ethernet on the secondary boot option. (B10 = 0, B11 = 0, B12 = 1,  B13 = 1 (RMII with external clock source))

What is not clear for me is the MDIO phy scan sequence. Inside the AM64x TRV manual, info given is:

"4.4.5.1.1 Ethernet Initialization Process"

When Link Info = 0, the link parameters are read using MDIO scan. This is the typical setting when using an
external PHY. When Link Info = 1, no MDIO scan is performed, and the link parameters are programmed by the
ROM based on the RGMII status register.

I have try to look the SK-AM64B schematic board and my understand is that we will be in same situation on my custom board schematics, when ROMBOOT will execute its Ethernet initialization process, the both PHY are power-up and out of reset and are on the same MDIO bus.

So how the ROMBOOT know which PHY address to use on the MDIO Bus ?

Thanks in advance for the clarification. 

  • Hello Tangi COLIN

    Thank you for the query.

    Please refer to the below errata for the Ethernet boot 

    i2329 MDIO: MDIO interface corruption (CPSW and PRU-ICSS)

    Regards,

    Sreenivasa

  • Hello,
    Thanks for your replies, i have check the i2329 that say : 

    For boot mode (only CPSW if supported), there is no workaround to guarantee the primary ethernet boot is successful. If this exception occurs during primary boot, the boot may possibly initiate retries which may or may not be successful. If the retries are unsuccessful, this would result in an eventual timeout and transition to the backup boot mode (if one is selected). If no backup boot mode is selected, then such failure will result in a timeout and force device reset via chip watchdog after which the complete boot process will restart again.

    In my use case the Ethernet boot will be the backup boot mode so should be ok for me. 

    This errata does not answer to my question. If i have two PHY power-up and out of reset on the same MDIO bus so with 2 diffirent address on this MDIO bus of course.  During the BOOTRom ethernet boot process, how the BootRom know which PHY address to use ? 

  • Hello Tangi COLIN

    Thank you for the inputs.

    I would believe the MDIO related issue would be applicable for all Ethernet Boot configuration. The above is an use case explanation. 

    This errata does not answer to my question. If i have two PHY power-up and out of reset on the same MDIO bus so with 2 diffirent address on this MDIO bus of course.  During the BOOTRom ethernet boot process, how the BootRom know which PHY address to use ? 

    https://software-dl.ti.com/processor-sdk-linux/esd/AM64X/09_02_00_08/exports/docs/linux/Foundational_Components/U-Boot/UG-Network-K3.html#:~:text=AM64x%20family%20of%20SoCs%20supports,field%20specified%20in%20the%20request.

    Note

    • Ethernet RGMII boot is supported over RGMII2 (Second port) on AM64x SoC.

    • RGMII boot is only supported on AM64x SK EVM and not supported on AM64x GP EVM as port is muxed to ICSSG by default

    • CPSW PHYs should be strapped as per ROM’s expectation described in part’s TRM.

    • Link info Bootmode pin needs to be ON along with RGMII boot mode selection Bootmode pins.

    As i understand the MDIO polls all the 32 address. I would guess the EPHY expected to boot should be placed on the lowest address.

    Can you try setting to the lowest address and test. 

    Regards,

    Sreenivasa

  • Hello Tangi COLIN

    I checked with the expert on the MDIO EPHY polling.

    The Boot takes information from the first EPHY that connects over MDIO. Pls configure the PHY address of the EPHY that is configured for boot to the lowest ID (address) value in the chain or EPHY loop.

    Regards,

    Sreenivasa

     

  • Hello Tangi COLIN

    Were you able to perform some tests and did you have any additional queries?

    Regards,

    Sreenivasa