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

c45 phy support on AM62A

ren ranxi
Prodigy 100 points
Part Number: AM62A7

Tool/software:

Translation

TI Engineer,

I am using TJA110 C45  on AM62A7 ,the driver is

board-support/ti-linux-kernel-6.6.32+git-ti/drivers/net/phy/nxp-c45-tja11xx.c

Encountered the following issue:

Environment:
ti-processor-sdk-linux-edgeai-am62a-evm-10_00_00_08

Device Tree

&cpsw3g_mdio {
        status = "okay";
        pinctrl-names = "default";
        pinctrl-0 = <&main_mdio1_pins_default>;

        cpsw3g_phy1: ethernet-phy@1 {
                compatible = "ethernet-phy-ieee802.3-c45";
                reg = <1>;
                //ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
                //ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
                ti,min-output-impedance;
        };
};

Error
get_phy_device

  • get_phy_c45_ids
    • get_phy_c45_devs_in_pkg
      • mdiobus_c45_read // returns -22

How should I resolve this issue?

Best regards,
ranxi ren

  • 0
    TI__Genius 15665 points

    Hello Ranxi,

    ren ranxi said:
    mdiobus_c45_read // returns -22

    First, I took a look at the get_phy_c45_devs_ids function (drivers/net/phy/phy_device.c) and it seems that the only expected return values are 0, -EIO (-5), or -ENODEV (-19). A return value of -22 (-EINVAL) would indicate some sort of invalid argument. https://elixir.bootlin.com/linux/v6.12.4/source/include/uapi/asm-generic/errno-base.h

    On AM62Ax devices, the ethernet driver should be am65-cpsw-nuss.c and the mdio driver is davinci_mdio.c. Within davinci_mdio.c (drivers/net/ethernet/ti/davinci_mdio.c), there is a function callback davinci_mdiobb_read_c45 that is needed for reading clause 45 registers via mdio bitbang/manual mode. 

    https://lore.kernel.org/all/20221227-v6-2-rc1-c45-seperation-v3-6-ade1deb438da@walle.cc/ 

    Reading c45 registers using davinci_mdiobb_read_c45 requires your MDIO to be operating in bitbang/manual mode. By default, on our TI Linux SDK, MDIO should already be configured in bitbang/manual mode: https://lore.kernel.org/netdev/20220810111345.31200-1-r-gunasekaran@ti.com/T/ 

    1. Can you check if your MDIO running in bitbang/manual mode? 

    2. Does the davinci_mdiobb_read_c45 function get called when your PHY device is initializing?

    3. Can you insert a boot log of your device booting up? (Paste the log with Insert->Code)

    -Daolin

  • 0
    Prodigy 100 points

    Hi Daolin,

    Last Friday I was able to complete the communication in C22 mode by modifying the 1103 driver file, but there may still be potential problems.

    The cause of previous C45 failure should be located. In 10.0SDK, davinci_mdio_probe, the following branch is not entered, and the C45-related functions are empty, so there is a problem with c45 matching.

    1. Can you check if your MDIO running in bitbang/manua? 

        Yes, I think it should be checked.

    2. Does the davinci_mdiobb_read_c45 function get called when your PHY device is initializing?

        Not called.

    3. Can you insert a boot log of your device booting up? (Paste the log with Insert->Code)

        I will check it according to the above ideas first, and if there is any problem, I will reply and attach the log.

    The questions are as follows:

    1. How to check the bitbang/manua pattern
    2. 0806 Is the same situation on the development environment? Due to algorithmic limitations, we end up using 0806's environment.
  • 0 in reply to ren ranxi
    TI__Genius 15665 points

    Hi Ranxi,

    ren ranxi said:
    How to check the bitbang/manua pattern

    One way to check is to add a print statement in the davinci_mdio driver to see if data->manual_mode is true.

    Another way to check is to probe the MDIO clock signal on your board to see if the clock signal is not a continuous signal. The first method with the print statement is probably easier as a quick check if bitbang/manual mode is even configured or not.

    ren ranxi said:
    0806 Is the same situation on the development environment? Due to algorithmic limitations, we end up using 0806's environment.

    Can you clarify what you mean by "0806"?

    -Daolin

  • 0 in reply to Daolin Qiu
    Prodigy 100 points

    Hi Daolin,

    Daolin Qiu said:
    One way to check is to add a print statement in the davinci_mdio driver to see if data->manual_mode is true.

    I previously printed this value and found that during the C45 registration process, the callback function was null. I traced the process of this function's registration.

    [    0.187079] davinci_mdio 8000f00.mdio: === data->manual_mode =0

    Daolin Qiu said:
    Can you clarify what you mean by "0806"?

    ti-processor-sdk-linux-am62axx-evm-08.06.00.45.

    Ranxi Ren

  • 0 in reply to ren ranxi
    TI__Genius 15665 points

    Hi Ranxi,

    ren ranxi said:
    0806 Is the same situation on the development environment? Due to algorithmic limitations, we end up using 0806's environment.
    ren ranxi said:
    ti-processor-sdk-linux-am62axx-evm-08.06.00.45.

    The Linux SDK 08.06.00.45 uses Linux kernel 5.10 and the workaround (MDIO bitbang/manual mode) for the MDIO errata was first applied on that Linux Kernel version, so it should already be applied on SDK 08.06.00.45

    https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/commit/drivers/net/ethernet/ti/davinci_mdio.c?h=ti-linux-5.10.y&id=7fc3c8b9ad3952915b3bbba748f4d32a3622d325 

    ren ranxi said:
    [    0.187079] davinci_mdio 8000f00.mdio: === data->manual_mode =0

    Based on this output, it appears that your MDIO configuration is not in manual mode, which is a problem to reading the C45 registers (i.e. getting davinci_mdiobb_read_c45 to run). Can you check if socdata->manual_mode is also 0? (See below link)

    https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/net/ethernet/ti/davinci_mdio.c?h=ti-linux-5.10.y&id=7fc3c8b9ad3952915b3bbba748f4d32a3622d325#n550 

    -Daolin

  • 0 in reply to Daolin Qiu
    Prodigy 100 points

    Hi Daolin:

    Daolin Qiu said:
    Can you check if socdata->manual_mode is also 0? (See below link)

    [ 0.198956] davinci_mdio 8000f00.mdio: === soc_match_data->data->manual_mode
    [ 0.198971] davinci_mdio 8000f00.mdio: === data->manual_mode =0

    The issue now lies in the return value of the soc_device_match function.

    Ranxi Ren

  • +1 in reply to Daolin Qiu
    Prodigy 100 points

    Hi Daolin，

    I have resolved this issue. I'm not sure why TI did not add a match for AM62AX in the davinci_mdio.c file.

    The modification is as follows:

    The questions are as follows:

    1. If so, I'd like to know why it wasn't added？

    2. Why is there a problem with driver initialization?

    Ranxi Ren

  • +1 in reply to ren ranxi
    TI__Genius 15665 points

    Hi Ranxi,

    ren ranxi said:
    I have resolved this issue. I'm not sure why TI did not add a match for AM62AX in the davinci_mdio.c file.

    Glad to hear you have resolved the issue!

    ren ranxi said:
    1. If so, I'd like to know why it wasn't added？

    My understanding is that the MDIO workaround was implemented in 2022, at that time AM62Ax was not yet released (it was released early 2023), so it may have simply not been included because the soc itself was not available.

    I've noticed that even on the latest kernel release (ti-linux-6.6-y or SDK 10.0), AM62Ax was also not added to k3_mdio_socinfo[]. Based on this and your findings, it appears that AM62Ax MDIO was always running without MDIO bitbang/manual mode. This has been working without any issue because AM62Ax itself does not have an MDIO corruption errata (AM62x and AM64x does have this errata). 

    However, the missing AM62Ax in k3_mdio_socinfo you discovered was exposed due to trying to read clause 45 registers which appears to require MDIO bitbang/manual mode. I will take steps to add AM62Ax in k3_mdio_socinfo for further SDK releases.

    ren ranxi said:
    2. Why is there a problem with driver initialization?

    To clarify, are you asking about the NXP TJA110 PHY driver or davinci_mdio driver? I see your screenshot of the NXP PHY driver so if you are talking about a problem with that driver I won't be able to help much because that is a part that TI doesn't support. You might consider contacting NXP directly about the driver initialization.

    -Daolin