AM3352 RMII ethernet: no data sent or received

Do you seen different behavior in uBoot vs Linux?

Please ensure that the PAD configuration for RMII_REFCLK is set for RECEIVER_ENABLED.

Please ensure that RMII(n)_IO_CLK_EN is set.

Please ensure that GMII(n)_SEL is set for RMII (0x01)

If all these are found to be correct, please capture and post a RMII_REFCLK waveform.

Hi DK,

Yes, we do see different behavior in U-boot. The Ethernet interface does work in U-boot.

The pad configuration is set for receiver enabled, here are the lines for RMII1 and RMII2:

{ "rmii1_refclk.rmii1_refclk", OMAP_MUX_MODE0 | AM33XX_INPUT_EN },

and

{ "mii1_col.rmii2_refclk", OMAP_MUX_MODE1 | AM33XX_INPUT_EN },

The IO_CLK_EN is set, and GMII_SEL is set to RMII:

Register 0x44e10650 is set to 0xC5.

Attached is the RMII_REFCLK waveform.

Did you read the 0xC5 from u-boot or when the kernel was booted?

Steve K.

Hi Steve,

I read the 0xC5 after the kernel was booted, using 'devmem'. We modified the code in arch/arm/mach-omap2/device.c to set the 0xC0 in addition to the 0x05 that it put in when we set RMII mode operation, as we couldn't find a function/API to set up the clocks where the RMII mode was an input. All of the EVM modes seem to use the phy clock as an output, despite the errata. Or at least, board-am335x.c doesn't seem to have any code which sets up the clocks as inputs.

Thanks,

Ben

Hi Ben,

That's what I was looking for - to make sure you modified devices.c in the kernel source.

Steve K.

Ben,

What frequency is your master oscillator running at?

Hi DK,

I wasn't sure whether you meant the main clock for the board, or the main clock for the RMII interface, so here's the information for both. For the main clock for the board, we are using the same setup as the EVM, a 24MHz crystal.

For the RMII clock, we are using a 25Mhz crystal attached to a Micrel PHY (p/n KSZ8081RNAIA) which by default outputs a 50Mhz clock on a REFCLK output pin from the PHY. This is connected via a 22.1 ohm series resistor to the AM3352 RMII-REFCLK1 pin. 

Thanks,

Ben

OK...can you dump MACCONTROL in both CPSW_SL registers? (14.5.7 in the TRM) and post the values here?

Hi DK,

The MACCONTROL register at CPSW_SL1 (0x4a10_0D84) is 0x0.

The MACCONTROL register at CPSW_SL2 (0x4a10_0DC4) is also 0x0.

In u-Boot these registers also seem to be 0x0 and 0x0. 

Looking at the TRM definitions for MACCONTROL, those values seem not entirely correct (half-duplex and 10 Mbit on our full-duplex 100Mbit link), but not like anything that would prevent data transfer. The fact that data transfer works in u-boot despite the same MACCONTROL values seems to corroborate this.

Thanks,

Ben

One interesting note - after pinging a destination in u-boot, both registers change to 0x8021. This is interesting because the 0x20 seems to imply GMII is released from reset, which then would be different from the Linux version.

Yes, that's what I was looking for.

Bit 5 must be set or the interface is held in reset. I tried this on my board and uBoot and Linux both have MACCONTROL set to 0x8021, which is the expected value for a full-duplex 100mbps connection.

Something in your Linux distro is either not setting MACCONTROL correctly, or it is, and something comes along later and clears it.

Hi DK,

Setting this register to 0x8021 and then pinging another destination, I see no effect. The ping still does not send data, ifconfig still shows 0 packets transmitted, and the packet count for the loopback interface goes up by 1. Is there some other action I'd need to take other than setting the register to 0x8021 after I'm booted into Linux?

Thanks,

Ben

Additional info: we've found that upon bringing the interface up, this register is cleared. If things are set up correctly at any point, this seems to be when those settings are overwritten. I'm not entirely sure why this register would be cleared on an up, but I'm going to see if I can find the code related to that, it might have some other hints about things that might be going wrong.

Hi Ben,

I remember from a different thread on MDIO that you were posting to that mentioned you had your own linux distro that is different from the distro provided with the SDK for the AM335x. From what you are describing the cpsw interface is not being  initialized.

There is a function called am33xx_cpsw_init in the file devices.c that was mentioned in an earlier post in this thread. Is this function being called? Or perhaps just this function below?

 pdev = omap_device_build("cpsw", -1, oh, &am33xx_cpsw_pdata,
                        sizeof(am33xx_cpsw_pdata), NULL, 0, 0);

Hi Schuyler,

Your recollection is correct. I've actually been working on a second build derived from TI's base code to try and get around any issues related to the custom distribution we're working with, but so far this build is also not working, and in a very similar fashion. I looked at the code in our custom version first, and found that this code:

pdev = omap_device_build("davinci_mdio", 0, oh, &am33xx_cpsw_mdiopdata, sizeof(am33xx_cpsw_mdiopdata), NULL, 0, 0);

<...>

pdev = omap_device_build("cpsw", -1, oh, &am33xx_cpsw_pdata, sizeof(am33xx_cpsw_pdata), NULL, 0, 0);

seems to have been replaced with this code:

platform_device_register(&am33xx_cpsw_mdiodevice);

platform_device_register(&am33xx_cpsw_device);

clk_add_alias(NULL, dev_name(&am33xx_cpsw_mdiodevice.dev), NULL, &am33xx_cpsw_device.dev);

This replacement appears to be intentional. Here is the content of am33xx_cpsw_mdiodevice:

static struct platform_device am33xx_cpsw_mdiodevice = {

.name = "davinci_mdio",

.id = 0,

.num_resources = ARRAY_SIZE(am33xx_cpsw_mdioresources)

.resource = am33xx_cpsw_mdioresources

.dev.platform_data = &am33xx_cpsw_mdiopdata,

};

I had a look at am33xx_cpsw_mdiopdata, and the content is the same as it is on the EVM. This looks like it might just be a difference between the 3.2.0 kernel used in the EVM and the 3.2.2 kernel used in our custom version.

In the interest of science, I recompiled our custom version with the calls to build the omap device in before the calls to platform_device_register. What I found was that the call:

oh = omap_hwmod_lookup("mdio")

fails. This causes the whole thing to exit without registering the devices.

I'm hoping to follow both debugging tracks, seeing if I can get my SDK-derived kernel up and running today. At this point, I've got it booting and it's showing Ethernet interfaces, but I believe it's not registering the PHYs correctly. I'm also going to make sure to check on the GMII enable which someone suggested above, to see that that's not causing the problem.

My thought here is that if I can get it working in an SDK-derived kernel, I can probably puzzle out the differences between that and the custom kernel, and if I can't get it working in an SDK-derived kernel, you all will probably be a lot more comfortable helping with that.

Re-reading this, I realized I'd been unclear. When I said that the omap_hwmod_lookup caused the whole thing to exit without registering the devices, that is NEW behavior that only happens after changing to code to try and register the devices the old way.

Previously, the platform_device_register calls were happening and did not appear to fail, so it seemed to be registering the CPSW.

Hi all,

Just an update here. I've not made any progress on the custom kernel side, but I've got my TI-SDK build up and booted onto the board. On the SDK, I see that the "davinci_mdio" probe checks the PHY_ALIVE register, finds 0 results, and bails out. Our PHY driver then doesn't init because it doesn't see any PHYs to latch onto.

This is similar to what I originally saw on the custom kernel when I had a Fixed MDIO enabled, but I've checked and that's not enabled in the SDK build. I've also checked the registers, and everything that you had me check for the custom kernel is in the same state as it was there... including the CPSW MDIOCONTROL registers being 0x0 instead of 0x8021. This may be because the MDIO is not working correctly here, instead of the CPSW not working properly in the custom build.

I'm going to see if I can capture data on the MDIO lines to verify that MDIO/MDC are both operating correctly, but our hardware engineer is gone for the week, so it may take me some time. However, the pin muxing should be the same as it was using the custom build.

One last update on this:

There was an issue with our PHY where both of the PHYs were responding to packets set to PHY address 0. This is apparently known as "broadcast mode" and on these PHYs you have to turn it off. The CPSW switch wasn't active because the PHYs were returning a link state of 1 and 0, which apparently coalesced to a 0, making the switch think they were off.

I'm not sure why eth0 was reporting as "up" despite this.

After turning the broadcast mode off, the PHYs reported their proper status, the ethernet interface got an IP address, and ping began working. Thanks for all the help.

Hi Ben,

Thank you for your advice.
I think I'll follow it.