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.

DRA829V: J721E: adding PHY support for CPSW9G

Part Number: DRA829V

Hi TI Team,

We are looking to support a use-case in Linux where we need to use the CPSW9G (8 port switch in the main domain) for providing connectivity using a specific PHY.

With the information provided in the related ticket we got some idea that the current implementation makes use of ethfw (app_remoteswitchcfg_server) running on the r5f0_0 and only supports the GESI expansion board that has the dp83867 PHY. I've multiple questions here

  1. Are there any plans to support CPSW9G directly under Linux, rather than through the r5f0_0?
  2. The dp83867 PHY does not support RMII mode but support for the mode is claimed in SDK documentation, is that correct? if not, how can it be tested?
  3. Is there a way with ethfw to support PHY configuration through Linux?
  4. Is there a guide which tells how to add additional PHY support in ethfw?
  • Hi Awais,

    Here are the replies to your questions

    1. Are there any plans to support CPSW9G directly under Linux, rather than through the r5f0_0?

    No, as per current architecture, EthFW owns and controls the CPSW. All requests are routed to it. May I know what problems you anticipate with this model ?

    2. The dp83867 PHY does not support RMII mode but support for the mode is claimed in SDK documentation, is that correct? if not, how can it be tested?

    That is correct. However the CPSW IP supports RMII, that's what it refers to. It cannot be tested on the EVM but on a custom board.

    3. Is there a way with ethfw to support PHY configuration through Linux?

    I don't think so because Eth Firmware will first bring up the PHY through it's driver, until then Linux cannot do anything with the interface. But I will check with experts. Can you provide your usecase ?

    4. Is there a guide which tells how to add additional PHY support in ethfw?

    Please refer to the PHY integration guide here

    Regards

    Vineet

  • Hi Vineet,

    Vineet Roy said:

    1. Are there any plans to support CPSW9G directly under Linux, rather than through the r5f0_0?

    No, as per current architecture, EthFW owns and controls the CPSW. All requests are routed to it. May I know what problems you anticipate with this model ?

    I don't have a strong case against the current architecture but a multi function device (e.g. a desrializer with Video interface and Ethernet PHY) might need to provide functionality to Linux (essentially the A72 cores) and in such cases device management would become rather complex.

    Vineet Roy said:

    2. The dp83867 PHY does not support RMII mode but support for the mode is claimed in SDK documentation, is that correct? if not, how can it be tested?

    That is correct. However the CPSW IP supports RMII, that's what it refers to. It cannot be tested on the EVM but on a custom board.

    Noted.

    Vineet Roy said:

    3. Is there a way with ethfw to support PHY configuration through Linux?

    I don't think so because Eth Firmware will first bring up the PHY through it's driver, until then Linux cannot do anything with the interface. But I will check with experts. Can you provide your usecase ?

    As stated in response to 1. I have a deserializer that provides video interface and an ethernet PHY for the main domain. The video interface is to be implemented in Linux and hence the control interface (SPI) for the device resides with Linux. Controlling the ethernet PHY in this case would require to setup a remoteproc bridge and patching the ethfw so the cores can communicate in order to setup the ethernet PHY properly. Do you think there's a simpler approach to this?

    Vineet Roy said:

    4. Is there a guide which tells how to add additional PHY support in ethfw?

    Please refer to the PHY integration guide here

    The guide is pretty helpful thanks. However, if I understand this correctly, the ethfw and the cpsw driver makes an assumption that every PHY would have an MDIO interface which isn't the case with the ethernet PHY that I have to integrate i.e. it does not have an MDIO interface. What sort of implications do you see here?

  • Hi Team,

    Can I get a response here?

  • Hello Team,

    Any updates?

  • Hi Awais,

    Sorry for the delay, I have forwarded the question to Ethernet experts

    Regards

    Vineet

  • Hi Vineet,

    Any updates?

  • Since this comment answered most of my questions I am marking this as resolved and opening up a new ticket with more refined information/questions.