AM3359 ethernet phy strange behavior / not working

Wireshark?

>> there just doesn't seem to be any communication between the AM3359 and the LAN8710

I'd use an oscilloscope to get assured, or checked pinmux carefully.

Nick,

A couple of things...

- Are you using MII or RMII? You say you are using a 50MHz clock, but the Ethtool output says MII mode* [EDIT: See below] which leads me to believe that the AM335x GMII_SEL register is not set correctly. For RMII+REF_CLK_IN this should be set to 0xF5.

- Double check that you are strapping the MODE and ADDR pins on the PHY correctly. BeagleBone has a schematic bug in which one of the MODE pins is mis-named;  page 8 of the current A6A schematic has a note reflecting this. Keep in mind that AM335x is pulling down several of these signals after POR, so a 10K pull-up is not sufficient. 1.5K is a good place to start. If RMII, you need to do the same for the PHY RMIISEL pin.

*I tested this and found that Ethtool shows 'Port = MII' regardless of MII or RMII. Still worth checking GMII_SEL to see if == 0xC5 or 0xF5.

There is definitely zero communication between the processor and the phy on the RMII bus.

From CCS5 physical memory view:

Address 0x44E10650 = 0xF5 = 11110101b

RMII_SEL on the LAN8710 is pulled high with a 1.5k resistor. I measured it, and it is low normally, but it is high for 200ms when the board is powered up. Eth0, which works fine, reports that it is in MII mode in ethtool, but it is also bootstrap configured for RMII mode. I believe this is functioning as it should, though I have no way to verify this. Just to be safe, I shorted the LAN8710 RMIISEL pin to +3.3V. That keeps it high, so I know it is set right.

I am thinking about the clock signal. I have a TTL 3.3V, 50MHz clock hooked up to pin H16 (RMII2_REFCLK) on the AM3359, and pin 5 (CLKIN) on the LAN8710. Once again, I can observe that things appear to be hooked up right, but I don't know how to verify this in software.

Is there a way to verify that the processor is seeing the clock signal? Is there a way to check the LAN8710 configuration registers? There must be some way to verify the RMII bus.

What else might be wrong?

Nick,

Which pinmux are you using?

The PHY address changing between boots sounds like the PHY address pins are not being latched correctly after POR. The MDIOUSERACCESSn (AM335x TRM section 14.5.10) register can be used to access the PHY directly via MDIO. The  PHY Special Modes Register (PHY register index 18) will report not only the latched mode, but also the latched address.

The mdio address switching was due to a short between rmii_ref_clk and the phyaddress 1 signals near the lan8710. Still cannot send or receive data throug the rmii port though.

I will investigate the mdiouseraccess and special modes register today, and report back what I find.

I did verify that the only valid pinmux for RMII1+RMII2 is IOSET 14. Please ensure this what you are configured for.

Here is my pinmux configuration. I checked the corresponding registers in the control module, and mode numbers there match what I expect them to be.

These are correct.

How did you do the pad configuration? Could you check that the pad configuration is correct for all pins in the RMII2 interface?

I have a board.c file, and that has data structures which refer to definitions from a mux33xx file.

An example looks like this (lab development machine is not allowed on the internet at my work, so I can't just cut and paste :():

static struct pinmux config_rmii2_pin_mux[] = {

    {"gpmc_wait0.rmii2_crs_dv", OMAP_MUX_MODE3 | AM33XX_PIN_INPUT_PULLDOWN},

    ...

    ...

    {NULL, 0}

};

With the XDS100 jtag debugger I can check the control module while the processor is running and see that the pins are in the correct mux mode, and they do appear to be.

If I turn off eth0 by disconnecting it, typing "ifconfig eth0 down", and then bring up eth1 "ifconfig eth1 192.168.1.2 up" "route add default gateway 192.168.1.1 eth1" I can send packets out eth1 with a ping. When I ping my router (192.168.1.1), I can use an oscilloscope to see the packets going out on the TX lines, and roughly 250us later, there is something coming in on the RX lines.

Ifconfig keeps a count of the packets are going out, and tcpdump shows the packets going out "ARP, Request who-has 192.168.1.1 tell 192.168.1.2, length 28".

But I still cannot see packets coming back in in linux. It's like it is ignoring them.

I ran a test with the ping command and tcpdump, using a Beaglebone and my custom board.

Ping Beaglebone from Custom Board:

root@CustomBoard~ ping 192.168.1.145

TCPDump from custom board:

root@CustomBoard~ tcpdump -i eth1

00:09:58.690086 ARP, Request who-has 192.168.1.145 tell 192.168.1.105, length 28

Beaglebone receives ARP request and replies. TCPDump from beaglebone:

root@beaglebone~ tcpdump -i eth0

00:05:38.954340 ARP, Request who-has beaglebone tell 192.168.1.105, length 50
00:05:38.954401 ARP, Reply beaglebone is-at d4:94:a1:96:cc:28 (oui Unknown), length 28

Back at the custom board, the RxD lines show data on them coming from the lan8710, and the CRS_DV line is high during the transmission in. RXER does not trigger. I can take oscilloscope screenshots, in case exact timing needs to be analyzed.

TCPDump on the custom board does not show any ICMP echo request or reply packets, so the Custom board is not receiving the ARP packets that say the layer 2 address of the beaglebone. There are several forum posts with similar issues, but I have tried the proposed solutions and they don't seem to work for me:

http://e2e.ti.com/support/arm/sitara_arm/f/791/t/262854.aspx

http://e2e.ti.com/support/arm/sitara_arm/f/791/t/260419.aspx?pi239031349=2

http://e2e.ti.com/support/arm/sitara_arm/f/791/t/243088.aspx

My clock is a 50Mhz, 50ppm TTL oscillator from ECS: ECS-3953M-500-BN-TR, connected to refclk on AM335x (ZCZ package pin H16) and lan8710. The GMII_SEL register (0x44E10650) is 0xF5.

My pinmux is set like this:

Is there something else I can check? What am I missing?

Nick,

What is the full value of your Pad Control Register for RMII2_REFCLK?

From the previous post, where describing about about bring down eth0 caused traffic to start working on eth1. If I am understanding the topology I think you are hitting a Linux limitation for lack of a better description of not being able to have 2 ports on the same subnet. Both of the addresses  I see have 192.168.1.x subnets. To run both eth ports they must be on different subnets, ex: eth0 :192.168.1.x and eth1 192.168.2.x.

According to the reference manual, the register for mii1_col/rmii2_refclk is 0x44E10908. Its value it 0x21h, or [7:0]=00100001.

Corresponds to (page 9.3.50): Receiver enabled, pin mux mode 1.

I tried putting eth0 on 192.168.2.11. I changed the address in the interfaces file, and the network config variables in barebox/uboot2.0. Shutting down eth0 should work too, so I did that. Still no luck getting eth1 to receive packets.

Could there be something wrong with the cpsw settings? The reference is hard to understand where it describes the cpsw register settings. Could it be set to drop packets going to mac 2?

I checked the CPSW_STATS register, 0x4A_0900, and the register is 0. There should be something there if the packets are perceived by the cpsw at all. That leads me to believe that there is a hardware or pinmux problem, but the pinmux appears to be correct, and the oscilloscope shows data going into the AM3359.

Nick,

Did you enable stats collection via STATS_PORT_EN? By default, stats collection is disabled.

The cpsw initialization process is very confusing to me. I browsed through the cpsw.c driver, and I see where it fills the various registers detailed in the reference manual, very hard to find the files where those functions get called. I basically go to /linux3.2 and have to grep -r '' for everything.

For example, there is a case select statment in cpsw.c called: 'CONFIG_SWITCH_PORT_STATISTICS_ENABLE'. That is called from an "enum{" statement in a file named "net_switch_config.h". I think that means the port statistics are enabled. I can see port staticstics on eth0.

Similarly, there is a number of '#ifdef CONFIG_TI_CPSW_DUAL_EMAC' statements in the cpsw.c. There is a "#define CONFIG_TI_CPSW_DUAL_EMAC" stement in autoconf.h. Does that mean my OS is correctly configured for dual emac mode?

What other statements are important to check?

having some of the same problem bring up Ethernet with RMII2. could you take a look and see if I'm missing any thing.

http://e2e.ti.com/support/arm/sitara_arm/f/791/t/296246.aspx