• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 101 subscribers
  • Views 570 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TDA4VM: cannot send complete package via Marvell PHY 88E1512

Xie Jack
Prodigy 50 points
Part Number: TDA4VM

Hello, TI:

  We are developing a custom platform with a  TDA4 SoC.

  Processor SDK version: 08_01_00_13

  We use marvell phy 88E1512 connected to mcu_cpsw0。
  The mode of operation is RGMII TO Copper。
  
  Problem：Packets are normally received in the rx direction, but only short packets can be  send in the tx direction.
  1.Even if we try to send long packets, the phy only sends part of the packet(about first 70 bytes of the packet).
  
  
  2.We set phy to packet generation mode，and we can receive full generated packege on the copper side。
  3.We found that when we send long packets, the phy has Copper FIFO Over/Underflow Error。
 
  
  Modification:
  We only motified the phy-mode in the Linux device tree as follows:
&cpsw_port1 {
phy-mode = "rgmii-id";
phy-handle = <&phy0>;
};
  
   Have you used marvell phy with TDA4VM?  What modifications do we need to make in the SDK？
   We don't know what caused this problem, can you help us?

Regards.

  • 0
    TI__Mastermind 34010 points

    Hi,

    Not sure if this is the cause but CPSW MAC only support Rx internal delay mechanism while "rgmii-id" is for adding internal delay in both tx and rx. 

    Can you try with phy-mode = "rgmii-rxid"

    Regards,
    Tanmay

  • 0 in reply to Tanmay Patil
    Prodigy 50 points

    Hi，

      Thanks for your reply.

      We tried with phy-mode = "rgmii-rxid", but it also didn't work. 

      Do we need set something of phy or cpsw0?

    Regards.

  • 0 in reply to Tanmay Patil
    Prodigy 50 points

    Hi，TI

       We found that the clock of RGMII TX is 120MHz instead of 125 MHz, and it is generated by soc.

       Can you tell us what clock does the RGMII TXC reference? 

       How can we get clock tree tool of TDA4, and how can we get the clock frequencies report of soc, do you some instructions?

    Regards.

  • 0 in reply to Xie Jack
    TI__Mastermind 34010 points

    Hi,

    You can use `k3conf` utility to check clocks set-up on board during run-time. run `k3conf --help` for help on how to use the tool.

    For dumping the clocks for mcu_cpsw, you can use this command : ` k3conf dump clock 18`

    For details on clocks and devices on TDA4VM, you can see this page.

    Regards,
    Tanmay

  • 0 in reply to Tanmay Patil
    Prodigy 50 points

    Hi,

    Thanks for your reply.

    We found that the default PLL value of MCU_CPSW (PLLFRAC2_SSMOD_16FFT_MCU_2) is wrong.Our input crystal Frequency is 19.2 MHz, but the default PLL configurations is set as table of 20Mhz input crystal frequency.

    We noticed  that "The crystal frequency is understood by the ROM from the BOOTPINS" in TISCI documents(https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/j721e/pll_data.html), so what the BOOTPINS means?

    We think some errors occurs when ROM understands  the crystal frequency.

    Regards.

  • +1 in reply to Tanmay Patil
    Prodigy 50 points

    Hi,

    We found that one of the boot mode pin of our board is pull up incorrectly.

    We have solved this problem, thanks.

    Regards.