Second ethernet port does not work (335x cpsw)

Hi,

I'm facing the same problem.

I searched this forum and get some infomation for this. there is a new BSP which support daul MAC. I'm down loading it but it hasn't finished yet.

Is there a document describe how to configure daul MAC interfaces? I can't find in the TRM. BTW, I'm using RMII.

Thank you.

Lihua

>>Is there a document describe how to configure daul MAC interfaces?

The AM335x platform for dual MAC has been the Starter Kit documented here: http://processors.wiki.ti.com/index.php/AM335x_Starter_Kit#Linux

 We did some extensive work with AM335xSDK 05_05_00_00 last year on the EVM-SK, but from above AM335xSDK 05_06_00_00 seems to work similarily i.e. 2 IP addresses on the different sub nets on the different adaptors.

>>eth0 Link encap:Ethernet HWaddr 00:18:30:FA:EC:AF inet addr:192.168.1.26 Bcast:192.168.1.255 Mask:255.255.255.0

>>eth1 Link encap:Ethernet HWaddr 00:18:30:FA:EC:B0 inet addr:10.0.0.124 Bcast:10.255.255.255 Mask:255.0.0.0

I was able to ping between those addresses to and from other devices/PC's on the TI network in a dual MAC mode ("Enable eth1 ").  And even run in "IP phone" mode where the EVM-SK acted as a switch ("Enable eth1 to eth0 nat ")

Sorry I'm no networking expert, but what is not functioning here?

(And in all fairness we probably need to add "Networking UG" documentation here:

http://processors.wiki.ti.com/index.php/Sitara_Linux_Software_Developer%E2%80%99s_Guide)

Thanks!

After serious testing today, I found the problem: it seams that the ports for mii1 and mii2 does not behave exactly the same with regard to their internal pull. The mii2 made my phy believe that it should go into a special mode by pulling COL & CRS high when coming out of reset, which the mii1 port did not.

Well I guess I should have figured this out earlier, but your answers led me into this direction.  A good end of the Friday for me now.. :)

Regards,

 Micael

Hi Micael,

I'm facing the same problem. What changes did you make in mii1 and mii2 pin configuration to make them working?

Thanks,

Abhay

Hi Abhay,

I had to add external pull resistors, since my second phy went into special mode directly after coming out of reset. (the pins attached to the Sitara are doubling as configuration pins at startup) At that point in time, the pin mapping has not yet started, so there's no fix to be done in software. If you are seeing the same problem, check which phy pins that are vital for getting the phy up in normal working mode, and pull them up/down as needed. I am using Micrel KSZ8051MNL phy's.

Regards,

  Micael

Hi Micael,

Key Question is:

Is there a method by which we can determine what pull up/downs are needed to get the PHY into “normal working mode”? That will be of immense help

Thanks.

Best Regards,

Feroz

Well, basically, you will need to put your board into reset, and while there, measure the traces interconnecting the AM225x to the PHY, getting the level of each pin, and then compare this to the data sheet of the particular phy that you are using.

Regards,

 Micael

Dear,

    Did you solve the problem?

Can you tell me how to solve the problem?

thanks!!

How do you know you are having the same problem? Can you verify that your ethernet transceiver is in the correct mode?

I have a very similar problem, but it's different, because my ethernet transceiver is definitely in RMII mode. It sends and receives data at 50MHz on RMII TxD/RxD 0 and 1 only, which it wouldn't do if it were in MII mode. Yet, the AM3359 mac 2 never sees incoming packets. I don't know how to verify if that data is getting into the AM3359 RMII receive buffer.

Hi jack,

The problem in my case was just about some hardware soldering PCB related...

Another issue was that the customer had identical logic readings for both PHYs. Clearly both PHY modules have the EXACT same address on the MDIO bus. So when Linux tries to soft reset the PHY on bootup only one of them will reset....

Best Regards

Feroz

Hi,

and to clarify my issue even more, it was my phy that went into a mode (called "back to back" if I remember correctly, or possibly "ISO" mode) since the pins are multi function (sampled when coming out of reset). From this point on, the Sitara could no longer have a meaningful conversation with the phy. The phy looked to be working just fine, by it self though.

 Micael

My problem was an issue in the hardware. The RXDV pin was muxed with another signal (for boot control I think), and the mux chip was not installed by the assembler.

I discovered this by checking each signal going into the AM3359 as close to the chip as possible. I was able to verify the clock, the data lines, and all of the outgoing signals, but RXDV never made it to the AM3359.

If you think you have a software configuration problem, one way you can check it is if you brought out the JTAG pins. You can use the TI JTAG device to directly browse the configuration registers, using the Technical Reference Manual as a guide. 

Nick Wernicke,

thanks for the fast reply!

My physics KSZ8041 in RMII mode. I checked his connection schematics for technical documentation. I have connected via JTAG and checked trace the signal flow on lines TXD0, TXD1, TXEN, RXDO, RXD1, RXER, CRS to the processor. I run an example Startervare EnetLwip for EVMSK in dual MAC mode. First port work fine. Second port have a problem. Transmit packets are sent is good - I see them in Wireshark. Reception packages are not accepted. No interrupt CPSW hardware. RMII signals on lines when receiving packets visible is good. Packages are sent is good, hence clocking RMII to the side the processor correctly.

My pin MUX code is shown below:

/*Pin Mux for RMII2  */
    HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_A(5)) = 3;  //RMII2_TXD0
    HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_A(4)) = 3;  //RMII2_TXD1
    HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_A(0)) = 3;  //RMII2_TXEN
    HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_CSN(3)) = 0x22; //RMII2_CRS
    HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_A(11)) = 0x23; //RMII2_RXD0
    HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_A(10)) = 0x23; //RMII2_RXD1
    HWREG(SOC_CONTROL_REGS + CONTROL_CONF_GPMC_WPN) = 0x23;   //RMII2_RXERR
    HWREG(SOC_CONTROL_REGS + CONTROL_CONF_MII1_COL) = (1
        	| (1 << CONTROL_CONF_RMII1_REFCLK_CONF_RMII1_REFCLK_PUTYPESEL_SHIFT)
        	| (1 << CONTROL_CONF_RMII1_REFCLK_CONF_RMII1_REFCLK_RXACTIVE_SHIFT));   //RMII2_REFCLK

I dont know where to find cause of the problem. Any suggestions

I had EXACTLY the same symptoms. Took me weeks to figure out the crs/rxdv signal was not going into the processor.