DM8148 MAC LoopBack not working

Hi Sivakumar,

For EMAC loopback, please refer to the example code from Mistral:

http://www.mistralsolutions.com/pes-support/support-downloads/tmdxevm8148.html

Diagnostics Software   Base Board

CCS_Test_code/Base_Board/rgmii_emac_0 and rgmii_emac_1

This CCS test application validates the EMAC0 for its ability to perform  write access; read access and data TX/RX ability. The test application writes  a known pattern into the TX Buffer and then reads back and verifies the same via a external loopback. The known pattern written into the memory is the incremental hexadecimal numbers. After transferring the entire memory area, this application reads them back and validates the data read. If the data read does not match the expected pattern, this test is declared failed. It is declared pass otherwise.

Best regards,
Pavel

Hi Pavel,

I got the diagnostics software from the link "http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/260398.aspx"

the code is for DM814X_RevD.

In emac rgmii test code registers and datasheet resgister are not matching.

Below code is from CCS_Test_code/Base_Board/rgmii_emac_0/emac.h

/* ------------------------------------------------------------------------ *
 *  EMAC Controller                                                         *
 * ------------------------------------------------------------------------ */
#define EMAC_BASE                   0x4A100000
#define EMAC_TXIDVER_BASE            EMAC_BASE + 0x100
#define EMAC_RXIDVER_BASE            EMAC_BASE + 0x110
#define EMAC_STATS_BASE                EMAC_BASE + 0x400
#define EMAC_ALE_BASE                EMAC_BASE + 0x600
#define EMAC_SWITCH_BASE            EMAC_BASE + 0x900
 
 
#define EMAC0_SLIVER_CTRL        *( volatile UINT32* )( EMAC_BASE + 0x704 ) // Per EMAC
#define EMAC1_SLIVER_CTRL        *( volatile UINT32* )( EMAC_BASE + 0x744 ) // Per EMAC
 
#define EMAC_STAT_PORT_EN        *( volatile UINT32* )( EMAC_BASE + 0x00C )
#define EMAC_P0_FLOW_THRESH        *( volatile UINT32* )( EMAC_BASE + 0x01C )
#define EMAC0_MACSRCADDRLO       *( volatile UINT32* )( EMAC_BASE + 0x02C )
#define EMAC0_MACSRCADDRHI       *( volatile UINT32* )( EMAC_BASE + 0x030 )
#define EMAC1_MACSRCADDRLO       *( volatile UINT32* )( EMAC_BASE + 0x04C )
#define EMAC1_MACSRCADDRHI       *( volatile UINT32* )( EMAC_BASE + 0x050 )
#define EMAC_P2_MAX_BLKS        *( volatile UINT32* )( EMAC_BASE + 0x054 )
#define EMAC_P2_TX_PRI_MAP        *( volatile UINT32* )( EMAC_BASE + 0x064 )
#define EMAC0_MACCONTROL         *( volatile UINT32* )( EMAC_BASE + 0x084 ) // Per EMAC
#define EMAC0_MACSTATUS          *( volatile UINT32* )( EMAC_BASE + 0x088 ) // Per EMAC
#define EMAC1_MACCONTROL         *( volatile UINT32* )( EMAC_BASE + 0x0C4 ) // Per EMAC
#define EMAC1_MACSTATUS          *( volatile UINT32* )( EMAC_BASE + 0x0C8 ) // Per EMAC

0x084 and 0x088 these two registers are not avilable in datasheet.

0x064 register is used for PRI_MAP but in datasheet it is a P1_TX_IN_CTL Tx fifo control register

Datasheet details which i referred

TMS320DM814x DaVinci Digital Video Processors Technical Reference Manual (Rev. D) -  Revised April 2013

Please clarify it.

Sivakumar,

sivakumar thirumoorthy said:

#define EMAC_P2_TX_PRI_MAP        *( volatile UINT32* )( EMAC_BASE + 0x064 )

sivakumar thirumoorthy said:

0x064 register is used for PRI_MAP but in datasheet it is a P1_TX_IN_CTL Tx fifo control register

sivakumar thirumoorthy said:

Datasheet details which i referred

TMS320DM814x DaVinci Digital Video Processors Technical Reference Manual (Rev. D) -  Revised April 2013

This emac.h file is from 2010, while the DM814x datasheet last update is from 14-Spet-2012 (not April 2013), check the below link:

http://www.ti.com/product/tms320dm8148 -> http://www.ti.com/lit/ds/symlink/tms320dm8148.pdf

Thus DM814x datasheet is more up-to-date, thus should be the correct one. And on address 0x4A100064, the register is P1_TS_CTL (not P1_TX_IN_CTL). Also DM814x TRM, states that at this address we have P1_TS_CTL register.

Regards,
Pavel

Hi Pavel,

Thanks for your immediate reply. THis is RAmesh continuing the thread on behalf of Mr. SIva.

In Technical Reference Manual Revision history there is no changes with respect to CPSW and EMAC Section.

So We went on assumption the test code need not to be updated,

Moreover the RGMII test application is for REV. D Board is available in DM814x evaluation  board vendor website.

If the test application is not for latest DM814x rev 3 silicon chip, can u provide latest test application for the same(RGMII loop back testing ).

This is the case which we are in our debugging phase.

Let me explain in brief about what were all we have tested so far.

We have configured EMAC0 as RGMII inour design and used Marvell's 88E1510 RGMII PHY in our board.

Whenever we power on, the link gets detected as 1.0Gbps and waits for few seconds and goes down. The PHY copper status register shows the Auto negotiation failed and no link partner visibility .

Then after some time the link gets up randomly and gets down. Every time the Auto negotiation seems to fail.

The circuit on the PHY side were verified and is correct. The same PHY chip we have used in some other processor boards and working fine. So, the circuit part of the PHY seems to have no issues.

The MDIO interface is brought up and we are able to access PHY registers. that is fine and the PHY configurations were done as per the drivers supported by Linux. SO, PHY configuration seems to be of not much issue.

Then coming to the MAC side, we have maintained the pin mux configuration for the EMAC0 port RGMII configuration as per the evaluation board of DM814x, gel files etc. So, no issues on pin mux side.

To debug step by step, we started with MAC level lopback. SInce it involves loopback at the MAC - TX/RX buffers level there should be no concern about the pin mux and IO's. The loopback configuration has to work as it is.But the MAC level loopback fails. This test is performed with the RGMII_EMAC0 applicaiton test file as discussed in the previous queries.

While debugging we found that the RGMII needs 250MHz clock exactly at the cpts_ref_clk input. This is sourced by any one among video0_pll, video_pll,McASP pll. by default the source is selected as video0_pll (Reg Addresss:0x481c52e8h) . Also the video0_pll outputs 54MHz clock for the AVDAC section. Since same clock is being routed to the cpts_ref_clk section, the RGMII interface cannot work properly. So, we configured to 250MHz. But still it is not working.

So, suggest any possible causes or solutions to debug the issue further.

Regards,

Ramesh.M & SIva.T

Hi Ramesh,

sivakumar thirumoorthy said:

So We went on assumption the test code need not to be updated

If you run the EMAC test, without modifications, does it work/pass or fail? Then if you align the EMAC test (emac.h) with the DM814x TRM, does it work/pass or fail?

sivakumar thirumoorthy said:

If the test application is not for latest DM814x rev 3 silicon chip, can u provide latest test application for the same(RGMII loop bac

The test application is for rev2.1 chip, but there are no differences in the EMAC subsystem between rev2.1 and rev3 chips. Thus the test application should work for rev3 also. See the DM814x silicon errata:
http://www.ti.com/lit/er/sprz343c/sprz343c.pdf

sivakumar thirumoorthy said:

We have configured EMAC0 as RGMII inour design and used Marvell's 88E1510 RGMII PHY in our board.

Please check that you are aligned with the guidelines below:
http://processors.wiki.ti.com/index.php/TI81xx_PSP_Porting_Guide#Ethernet_Driver_-_Adding_Custom_Ethernet_Phy

Please also check that you are aligned with the below silicon errata advisories:

Check also the below thread:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/214810/773522.aspx#773522

BR
Pavel

Hi Pavel,

If you run the EMAC test, without modifications, does it work/pass or fail?

    Fail

Then if you align the EMAC test (emac.h) with the DM814x TRM, does it work/pass or fail?

    Fail

Mentioned 3 advisory of 3.0.21, 3.0.29 and 3.0.30 is not suits to us. Because we are not using the ethernet peripheral for Booting.

For advisory 3.0.85 EMAC and switch subsystem: There is no transmitting data from host port even the warm reset is released.

Refer the EMAC register dump details,

P-0 R-0 V-20013140
P-0 R-1 V-2021796d
P-0 R-2 V-20410141
P-0 R-3 V-20610dd1
P-0 R-4 V-208101e1
P-0 R-5 V-20a145e1
P-0 R-6 V-20c10005
P-0 R-7 V-20e12801
P-0 R-8 V-21010000
P-0 R-9 V-21210300
P-0 R-10 V-21414000
P-0 R-13 V-21a10003
P-0 R-14 V-21c10000
P-0 R-15 V-21e13000
P-0 R-16 V-22013060
P-0 R-17 V-22216c48
P-0 R-18 V-22410000
P-0 R-19 V-22610000
P-0 R-20 V-22810020
P-0 R-21 V-22a10000
P-0 R-22 V-22c10000
P-0 R-23 V-22e10000
P-0 R-26 V-23410040
P-2 R-16 V-22014448
P-2 R-18 V-22410000
P-2 R-19 V-22610000
P-2 R-20 V-22810000
P-2 R-21 V-22a11076
P-2 R-22 V-23014707
P-2 R-25 V-23210013
P-2 R-26 V-23410000
P-3 R-16 V-2201101e
P-3 R-17 V-22214400
P-3 R-18 V-22414905
P-3 R-19 V-22610073

Thanks,

Sivakumar

Savikumar,

sivakumar thirumoorthy said:

If you run the EMAC test, without modifications, does it work/pass or fail?

    Fail

Could you provide me the CCS console output when you run the EMAC test?

BR
Pavel

I met the same problem. I think there is something wrong with the emac.h.

I am going to get the emac driver from SDK.

He Liang,

Please make sure you have the external loopback cable, see the below e2e thread:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/332085/1163313.aspx#1163313

Regards,
Pavel

I have made a loopback cable, and I got "Link Detected".

But it doesn't work yet.

Do you make it with the emac.h?

He Liang,

he liang said:

and I got "Link Detected".

But it doesn't work yet.

Could you please provide me the full CCS console output when you run this test?

Best regards,
Pavel

Test Suite version number is 1.0.
Build Date = Apr 21 2014 : Time = 09:59:14.
01 Testing RGMII loopback...
PHY found at address 0
PHY found at address 1
In RGMII mode
Waiting for link...
Link Detected
Enabling the R-GMII interface on DM814X.
In R-GMII mode
Packet verification failed!!
FAIL... error code 20... quitting

***ALL Tests Passed***

He Liang,

I see that you are using DM814x based custom board, not DM814x EVM. Thus I suspect this is EMAC hardware design issue. Can you try to run this test on the DM814x EVM?

Best regards,
Pavel

Unfortunately, I haven't EVM board.

I wonder if the test can be passed on the EVM.

But I can confirm there are wrong macro definitions in the emac.h.

#define EMAC_STAT_PORT_EN        *( volatile UINT32* )( EMAC_BASE + 0x00C )
#define EMAC_P0_FLOW_THRESH        *( volatile UINT32* )( EMAC_BASE + 0x01C )
#define EMAC0_MACSRCADDRLO       *( volatile UINT32* )( EMAC_BASE + 0x02C )
#define EMAC0_MACSRCADDRHI       *( volatile UINT32* )( EMAC_BASE + 0x030 )
#define EMAC1_MACSRCADDRLO       *( volatile UINT32* )( EMAC_BASE + 0x04C )
#define EMAC1_MACSRCADDRHI       *( volatile UINT32* )( EMAC_BASE + 0x050 )
#define EMAC_P2_MAX_BLKS        *( volatile UINT32* )( EMAC_BASE + 0x054 )
#define EMAC_P2_TX_PRI_MAP        *( volatile UINT32* )( EMAC_BASE + 0x064 )
#define EMAC0_MACCONTROL         *( volatile UINT32* )( EMAC_BASE + 0x084 ) // Per EMAC
#define EMAC0_MACSTATUS          *( volatile UINT32* )( EMAC_BASE + 0x088 ) // Per EMAC
#define EMAC1_MACCONTROL         *( volatile UINT32* )( EMAC_BASE + 0x0C4 ) // Per EMAC
#define EMAC1_MACSTATUS          *( volatile UINT32* )( EMAC_BASE + 0x0C8 ) // Per EMAC

you can check these in the sprugz8e.pdf.

He Liang,

This is the feedback from DM814x Mistral team:

He Liang,

he liang said:

#define EMAC_P2_TX_PRI_MAP        *( volatile UINT32* )( EMAC_BASE + 0x064 )

I agree we have a mismatch between the Mistral emac.h file (0x064 -> EMAC_P2_TX_PRI_MAP) and DM814x TRM (0x064 -> P1_TS_CTL), but this should not be fatal for the test, as in the Mistral EMAC test, EMAC_P2_TX_PRI_MAP is set to 0x0, while in DM814x EZSDK u-boot P1_TS_CTL is not used at all.

BR
Pavel

I have compared the emac.h with 814X TRM, and I think these three definations are important to the test and they

are different from TRM.

EMAC0_MACCONTROL
EMAC0_MACSRCADDRLO
EMAC0_MACSRCADDRHI

pls check this,.

#define EMAC_BASE                0x4A100000

#define EMAC0_MACCONTROL         *( volatile UINT32* )( EMAC_BASE + 0x084 ) // Per EMAC

#define EMAC0_MACSRCADDRLO       *( volatile UINT32* )( EMAC_BASE + 0x02C )

Finally, I made it by changing the macro defination of EMAC0_MACCONTROL.

#define EMAC_SL1IDVER_BASE   EMAC_BASE + 0x700

#define EMAC0_MACCONTROL         *( volatile UINT32* )( EMAC_SL1IDVER_BASE + 0x004 ) // Per EMAC
#define EMAC0_MACSTATUS          *( volatile UINT32* )( EMAC_SL1IDVER_BASE + 0x008 ) // Per EMAC

//#define EMAC0_MACCONTROL         *( volatile UINT32* )( EMAC_BASE + 0x084 ) // Per EMAC
//#define EMAC0_MACSTATUS          *( volatile UINT32* )( EMAC_BASE + 0x088 ) // Per EMAC

I try the mac level loopback and it is successful this time.

    EMAC0_MACCONTROL = 0
        | ( 0 << 9 )            // Round robin
        | ( 1 << 7 )            // Gigabit mode
        | ( 0 << 6 )            // TX pacing disabled
        | ( 0 << 5 )            // GMII RX & TX
        | ( 0 << 4 )            // TX flow disabled
        | ( 0 << 3 )            // RX flow disabled
        /* | ( 0 << 1 )*/         // Loopback disabled
       | ( 1 << 1 )             // Loopback enabled
        | ( 1 << 0 )           // full duplex
        | ( 1 << 22 )   // CEF
        | ( 1 << 23 );  // CSF

and the log,

He Liang,

I will report your findings to the Mistral team. Thanks for sharing this.

Best regards,
Pavel

Pavel,


We have changed the following Sliver register Offsets  

#define EMAC_SL1IDVER_BASE   EMAC_BASE + 0x700

#define EMAC0_MACCONTROL         *( volatile UINT32* )( EMAC_BASE + 0x084 ) // Per EMAC
#define EMAC0_MACSTATUS          *( volatile UINT32* )( EMAC_BASE + 0x088 ) // Per EMAC

changed as below .

#define EMAC0_MACCONTROL         *( volatile UINT32* )( EMAC_SL1IDVER_BASE + 0x004 ) // Per EMAC

#define EMAC0_MACSTATUS          *( volatile UINT32* )( EMAC_SL1IDVER_BASE + 0x008 ) // Per EMAC

Now, in CCS the Mac Level loopback test is working fine.So we have need to accommodate the same change in the linux kernel or u boot level.

Could you help us to update these changes in kernel or u boot level.

 
thanks

Sivakumar.T

Hi Savikumar,

Rajeshkumar R said:

So we have need to accommodate the same change in the linux kernel or u boot level.

Rajeshkumar R said:

Could you help us to update these changes in kernel or u boot level.

I have check the u-boot source code, and the EMAC sliver registers addresses are fine:

ti-ezsdk_dm814x-evm_5_05_02_00/board-support/u-boot-2010.06-psp04.04.00.01/drivers/net/cpsw.c

struct cpsw_regs {
    u32    id_ver; //0x000       CPSW_ID_VER
    u32    control; //0x004      CPSW_CONTROL
    u32    soft_reset; //0x008   CPSW_SOFT_RESET
    u32    stat_port_en; //0x00C CPSW_STAT_PORT_EN
    u32    ptype; //0x010        CPSW_PTYPE
};

struct cpsw_slave_regs {
    u32    max_blks; //0x050      P1_MAX_BLKS
    u32    blk_cnt;  //0x054      P1_BLK_CNT
    u32    flow_thresh; //0x058   P1_TX_IN_CTL
    u32    port_vlan; //0x5C      P1_PORT_VLAN    
    u32    tx_pri_map; //0X060    P1_TX_PRI_MAP
    u32     ts_ctl;  //0x064       P1_TS_CTL
    u32     ts_seq_ltype; //0x068  P1_TS_SEQ_LTYPE
    u32     ts_vlan; //0x06C       P1_TS_VLAN
    u32    sa_lo; //0x070         SL1_SA_LO
    u32    sa_hi; //0x074         SL1_SA_HI
};

struct cpsw_host_regs {
    u32    max_blks;     //0x028       P0_MAX_BLKS
    u32    blk_cnt;      //0x02C       P0_BLK_CNT
    u32    flow_thresh;  //0x030       P0_TX_IN_CTL
    u32    port_vlan;    //0x034       P0_PORT_VLAN
    u32    tx_pri_map;   //0x038       P0_TX_PRI_MAP
    u32    cpdma_tx_pri_map; //0x03C   CPDMA_TX_PRI_MAP
    u32    cpdma_rx_chan_map; //0x040  CPDMA_RX_CH_MAP
};

struct cpsw_sliver_regs {
    u32    id_ver;       //0x700   SL1_IDVER
    u32    mac_control;  //0x704   SL1_MACCONTROL
    u32    mac_status;   //0x708   SL1_MACSTATUS
    u32    soft_reset;   //0x70C   SL1_SOFT_RESET
    u32    rx_maxlen;    //0x710   SL1_RX_MAXLEN
    u32    __reserved_0; //0x714   SL1_BOFFTEST
    u32    rx_pause;     //0x718   SL1_RX_PAUSE
    u32    tx_pause;     //0x71C   SL1_TX_PAUSE
    u32    __reserved_1; //0x720   SL1_EMCONTROL
    u32    rx_pri_map;   //0x724   SL1_RX_PRI_MAP
};

I print all the EMAC registers offsets and I put a comment next to each register with it offset.

static void cpsw_slave_init(struct cpsw_slave *slave, struct cpsw_priv *priv)
{
    u32    slave_port;

printf("slave->sliver->id_ver addr is 0x%08x\n",&slave->sliver->id_ver);
printf("slave->sliver->mac_control addr is 0x%08x\n",&slave->sliver->mac_control);
printf("slave->sliver->mac_status addr is 0x%08x\n",&slave->sliver->mac_status);

Regards,
Pavel

Regarding the linux kernel, I see we have the same as in u-boot:

ti-ezsdk_dm814x-evm_5_05_02_00/board-support/linux-2.6.37-psp04.04.00.01/drivers/net/cpsw.c

struct cpsw_ss_regs {
    u32    id_ver;
    u32    soft_reset;
    u32    control;
    u32    int_control;
    u32    rx_thresh_en;
    u32    rx_en;
    u32    tx_en;
    u32    misc_en;
    u32    mem_allign1[8];
    u32    rx_thresh_stat;
    u32    rx_stat;
    u32    tx_stat;
    u32    misc_stat;
    u32    mem_allign2[8];
    u32    rx_imax;
    u32    tx_imax;
};

struct cpsw_regs {
    u32    id_ver;
    u32    control;
    u32    soft_reset;
    u32    stat_port_en;
    u32    ptype;
    u32    soft_idle;
    u32    thru_rate;
    u32    gap_thresh;
    u32    tx_start_wds;
    u32    flow_control;
};

struct cpsw_slave_regs {
    u32    max_blks;
    u32    blk_cnt;
    u32    flow_thresh;
    u32    port_vlan;
    u32    tx_pri_map;
    u32    ts_ctl;
    u32    ts_seq_ltype;
    u32    ts_vlan;
    u32    sa_lo;
    u32    sa_hi;
};

struct cpsw_host_regs {
    u32    max_blks;
    u32    blk_cnt;
    u32    flow_thresh;
    u32    port_vlan;
    u32    tx_pri_map;
    u32    cpdma_tx_pri_map;
    u32    cpdma_rx_chan_map;
};

struct cpsw_sliver_regs {
    u32    id_ver;
    u32    mac_control;
    u32    mac_status;
    u32    soft_reset;
    u32    rx_maxlen;
    u32    __reserved_0;
    u32    rx_pause;
    u32    tx_pause;
    u32    __reserved_1;
    u32    rx_pri_map;
};

struct cpsw_hw_stats {
    u32    rxgoodframes;
    u32    rxbroadcastframes;
    u32    rxmulticastframes;
    u32    rxpauseframes;
    u32    rxcrcerrors;
    u32    rxaligncodeerrors;
    u32    rxoversizedframes;
    u32    rxjabberframes;
    u32    rxundersizedframes;
    u32    rxfragments;
    u32    __pad_0[2];
    u32    rxoctets;
    u32    txgoodframes;
    u32    txbroadcastframes;
    u32    txmulticastframes;
    u32    txpauseframes;
    u32    txdeferredframes;
    u32    txcollisionframes;
    u32    txsinglecollframes;
    u32    txmultcollframes;
    u32    txexcessivecollisions;
    u32    txlatecollisions;
    u32    txunderrun;
    u32    txcarriersenseerrors;
    u32    txoctets;
    u32    octetframes64;
    u32    octetframes65t127;
    u32    octetframes128t255;
    u32    octetframes256t511;
    u32    octetframes512t1023;
    u32    octetframes1024tup;
    u32    netoctets;
    u32    rxsofoverruns;
    u32    rxmofoverruns;
    u32    rxdmaoverruns;
};

struct cpsw_slave {
    struct cpsw_slave_regs __iomem    *regs;
    struct cpsw_sliver_regs __iomem    *sliver;
    int                slave_num;
    u32                mac_control;
    struct cpsw_slave_data        *data;
    struct phy_device        *phy;
#ifdef CONFIG_TI_CPSW_DUAL_EMAC
    u32                port_vlan;
    struct net_device        *ndev;
    u32                open_stat;
#endif /* CONFIG_TI_CPSW_DUAL_EMAC */
};

/*
 * CPTS Regs
 */
struct cpts_regs {
    u32    id_ver;
    u32    control;
    u32    rftclk_sel;
    u32    ts_push;
    u32    ts_load_val;
    u32    ts_load_en;
    u32    mem_allign1[2];
    u32    intstat_raw;
    u32    intstat_masked;
    u32    int_enable;
    u32    mem_allign2;
    u32    event_pop;
    u32    event_low;
    u32    event_high;
};

You can print the full address to double check, in the same way as in the u-boot, but with printk instead of printf.

Regards,
Pavel