In u-boot for AM3352 ZCE based custom board, ethernet fails to receive

What is the u-boot version you are using ?

The following Sitara ARM microprocessors are supported with this SDK version.

I am using u-boot 2013.1 as for the AM335xEVM ver 5.07.

Are you using RMII or MII ?

I'm using MII.

I have added some printf statments for debugging and found that the cpdma_process() function, in the cpsw.c file, always returns -EBUSY. The chan_write() function is never called by cpdma_process().

We are using MII so I have modified the board/ti/am335x/board.c file to select MII mode for our board.

Another discovery is that in the cpdma_process function, the CPDMA_DESC_OWNER bit is never set in the descriptor for the received packets. I wonder why.

Maybe this patch is causes your problem, you may try to remove it.

 https://gitorious.org/am335x/u-boot-am33x/commit/93c05158992ffb0e6ce68f5f8ee3ff691694db7b?format=patch

A very rough guess is that the return packets are not getting to the cpsw driver.

Did you set up the pin mux for MII?

Depending on how you did the board port you will need call the pin mux configuration for MII mode. The Beagle Bone board uses MII for it's ethernet interface. Here is a code snippet, the highlighted shows how the MII interface is enabled on Beagle Bone board,

from board/ti/am335x/mux.c:

void enable_board_pin_mux(struct am335x_baseboard_id *header)
{
        /* Do board-specific muxes. */
        if (!strncmp(header->name, "A335BONE", HDR_NAME_LEN)) {
                /* Beaglebone pinmux */
                configure_module_pin_mux(i2c1_pin_mux);
                configure_module_pin_mux(mii1_pin_mux);
                configure_module_pin_mux(mmc0_pin_mux);
                configure_module_pin_mux(mmc1_pin_mux);

The TI boards use a eeprom to enable distinguishing between different boards for the same code load. The code snippet is expecting this eeprom information in the header passed to this function, which your design probably does not have. Please just concentrate on the code used to enable MII and not how it was determined to call this particular function.

Schuyler, thanks for the tip. I think I have the board.c and mux.c files ok. I call the following two pinmux functions:

configure_module_pin_mux(nand_pin_mux);
configure_module_pin_mux(mii1_pin_mux);

I have modified board.c to not bother with the EEPROM.

Everything in the SPL and ordinary u-boot seems to work ok except for the Ethernet.

Right now it would seem that the CPU doesn't hear the incoming Ethernet packages. The cpsw_recv() function never seems to get any packages.

Lets look at the ethernet stats and see if the hardware is seeing any receive traffic, this address is the start of the cpsw stats registers, specifically we want to see offset 0x0 which the Good RX Frames increasing in value. If offset x10 or 0x14 are increasing that means bad things are happening. 

These registers start at 0x4A10_0900 and the full description of the registers is found in section 14.3.2.20 of the TRM.

Next please take a look 0x44e1_0650, section 9.3.31 of the TRM, gmii_sel Register, this the mode select pins for ports, what value do you have here?

Ok. First I issued the "dhcp" command in u-boot to get some packets sent to the board.

U-Boot# dhcp link up on port 0, speed 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
Abort

Here's the result of using the "md" command in u-boot:

U-Boot# md 0x4a100900 1
4a100900: 00000000 ....
U-Boot# md 4a100900 2
4a100900: 00000000 00000000 ........
U-Boot# md 4a100910 1
4a100910: 00000000 ....
U-Boot# md 4a100914 1
4a100914: 00000000 ....
U-Boot# md 44e10650 1
44e10650: 00000000 ....

The STATS registers must be implicitly enabled before they can be used. Please refer to the STAT_PORT_EN register (TRM 14.5.8.4).

So, I wrote 3 into the STAT_PORT_EN register with command "mw 4a10000c 3" but the status registers are still all 0 after anther try with the dhcp command.

Please dump all of the stats before and after transmitting some packets.  0x00-0x8c.

Since you are seeing packets getting transmitted out on the wire, you should at least be able to confirm that the good TX packets are being incremented.  

Before dhcp:

U-Boot# md 4a100900 24
4a100900: 00000000 00000000 00000000 00000000 ................
4a100910: 00000000 00000004 00000000 00000000 ................
4a100920: 00000000 00000004 00000000 00000000 ................
4a100930: 00000000 00000000 00000000 00000000 ................
4a100940: 00000000 00000000 00000000 00000000 ................
4a100950: 00000000 00000000 00000000 00000000 ................
4a100960: 00000000 00000000 00000000 00000004 ................
4a100970: 00000000 00000000 00000000 00000000 ................
4a100980: 00000294 00000000 00000000 00000000 ................

After dhcp:

U-Boot# md 4a100900 24
4a100900: 00000000 00000000 00000000 00000000 ................
4a100910: 00000000 00000000 00000000 00000000 ................
4a100920: 00000000 00000000 00000000 00000000 ................
4a100930: 00000000 00000000 00000000 00000000 ................
4a100940: 00000000 00000000 00000000 00000000 ................
4a100950: 00000000 00000000 00000000 00000000 ................
4a100960: 00000000 00000000 00000000 00000000 ................
4a100970: 00000000 00000000 00000000 00000000 ................
4a100980: 00000000 00000000 00000000 00000000 ................

I see that the STAT_PORT_EN register gets cleared after I have aborted the DHCP command.

I think the stat enabling is getting cleared as part of the command and not the abort of it.

In the file  drivers/net/cpsw.c in the function cpsw_init(...) is the line below,

       /* enable statistics collection only on the host port */
        __raw_writel(BIT(priv->host_port), &priv->regs->stat_port_en);

My initial guess is this is the problem in that it is resetting rather than enabling, try commenting out line, setting the bits manually before doing the dhcp command.

I just tried commenting that line out but it didn't help. Same situation as before. The STAT_PORT_EN is cleared when I check it after the DHCP command. And the stats are all 0 still.

The stats registers don't show any good packets, so you need to take a step back and verify several basic things:

- Dump the PHY registers via MDIO and compare the PHY settings to the MAC settings. Make sure the PHY and MAC are in agreement with regard to link speed, duplex, interface mode (MII/RMII/RGMII), etc. It's possible that the PHY is latching an incorrect mode due to pin strapping issues. Review section 3.7.3 of the SMSC8710 datasheet for details while keeping in mind that many of the pins used by the PHY for strapping are also connected to AM335x which may be driving/pulling them after POR.

- Verify that RX and TX clocks look good.

As I suspected, it seems that u-boot clears the statistics and the STAT_PORT_EN register contents after commands has been issued.

By setting the STAT_PORT_EN to 3 and just leaving the board listening, then after a while I can actually see some statistics when dumping the stats. Like below.

U-Boot# mw 4a10000c 3
U-Boot# md 4a100900 24
4a100900: 00000000 00000000 00000000 00000000 ................
4a100910: 00000001 00000002 00000000 00000000 ................
4a100920: 00000000 00000027 00000000 00000000 ....'...........
4a100930: 00000000 00000000 00000000 00000000 ................
4a100940: 00000000 00000000 00000000 00000000 ................
4a100950: 00000000 00000000 00000000 00000000 ................
4a100960: 00000000 00000000 00000000 00000000 ................
4a100970: 00000001 00000001 00000001 00000000 ................
4a100980: 00000bb6 00000000 00000000 00000000 ................
U-Boot# md 4a100900 24
4a100900: 00000000 00000000 00000000 00000000 ................
4a100910: 00000051 00000080 00000000 00000000 Q...............
4a100920: 00000000 000003cb 00000000 00000000 ................
4a100930: 00000000 00000000 00000000 00000000 ................
4a100940: 00000000 00000000 00000000 00000000 ................
4a100950: 00000000 00000000 00000000 00000000 ................
4a100960: 00000000 00000000 00000002 00000073 ............s...
4a100970: 00000037 00000024 00000001 00000000 7...$...........
4a100980: 00013cec 00000000 00000000 00000000 .<..............
U-Boot# md 4a100900 24
4a100900: 00000000 00000000 00000000 00000000 ................
4a100910: 000001c1 000000c0 00000000 00000000 ................
4a100920: 00000000 000006ce 00000000 00000000 ................
4a100930: 00000000 00000000 00000000 00000000 ................
4a100940: 00000000 00000000 00000000 00000000 ................
4a100950: 00000000 00000000 00000000 00000000 ................
4a100960: 00000000 00000000 00000005 000000c2 ................
4a100970: 00000191 00000028 00000001 00000000 ....(...........
4a100980: 00031839 00000000 00000000 00000000 9...............

Regarding the RX and TX clocks. According to the oscilloscope they look fine.

The port in used in Hardware is GEMAC_CPSW/MII1 accordingly to table 2-47 in the datasheet , ZCE package.

Table 2-47. GEMAC_CPSW/MII1 Signals Description

 SIGNAL NAME [1] DESCRIPTION [2] TYPE   ZCE BALL [4] 

 gmii1_col           MII Colision                     I          J19 
 gmii1_crs           MII Carrier Sense           I          J18 
 gmii1_rxclk        MII Receive Clock          I           M19 
 gmii1_rxd0        MII Receive Data bit 0    I           P18 
 gmii1_rxd1        MII Receive Data bit 1    I           P19 
 gmii1_rxd2        MII Receive Data bit 2    I           N16 
 gmii1_rxd3        MII Receive Data bit 3    I          N17 
gmii1_rxdv         MII Receive Data Valid   I           L19 
gmii1_rxer         MII Receive Data Error   I           K19  

All traces has been verified on the PCB and signal looks correct out from the LAN8710A circuit.

Axel,

Were you able to dump the MAC/PHY registers?

-Dump the PHY registers via MDIO and compare the PHY settings to the MAC settings. Make sure the PHY and MAC are in agreement with regard to link speed, duplex, interface mode (MII/RMII/RGMII), etc. It's possible that the PHY is latching an incorrect mode due to pin strapping issues. Review section 3.7.3 of the SMSC8710 datasheet for details while keeping in mind that many of the pins used by the PHY for strapping are also connected to AM335x which may be driving/pulling them after POR.

U-Boot# mii dump 0 0-5
0. (3100) -- PHY control register --
(8000:0000) 0.15 = 0 reset
(4000:0000) 0.14 = 0 loopback
(2040:2000) 0. 6,13 = b01 speed selection = 100 Mbps
(1000:1000) 0.12 = 1 A/N enable
(0800:0000) 0.11 = 0 power-down
(0400:0000) 0.10 = 0 isolate
(0200:0000) 0. 9 = 0 restart A/N
(0100:0100) 0. 8 = 1 duplex = full
(0080:0000) 0. 7 = 0 collision test enable
(003f:0000) 0. 5- 0 = 0 (reserved)

1. (782d) -- PHY status register --
(8000:0000) 1.15 = 0 100BASE-T4 able
(4000:4000) 1.14 = 1 100BASE-X full duplex able
(2000:2000) 1.13 = 1 100BASE-X half duplex able
(1000:1000) 1.12 = 1 10 Mbps full duplex able
(0800:0800) 1.11 = 1 10 Mbps half duplex able
(0400:0000) 1.10 = 0 100BASE-T2 full duplex able
(0200:0000) 1. 9 = 0 100BASE-T2 half duplex able
(0100:0000) 1. 8 = 0 extended status
(0080:0000) 1. 7 = 0 (reserved)
(0040:0000) 1. 6 = 0 MF preamble suppression
(0020:0020) 1. 5 = 1 A/N complete
(0010:0000) 1. 4 = 0 remote fault
(0008:0008) 1. 3 = 1 A/N able
(0004:0004) 1. 2 = 1 link status
(0002:0000) 1. 1 = 0 jabber detect
(0001:0001) 1. 0 = 1 extended capabilities

2. (0007) -- PHY ID 1 register --
(ffff:0007) 2.15- 0 = 7 OUI portion

3. (c0f1) -- PHY ID 2 register --
(fc00:c000) 3.15-10 = 48 OUI portion
(03f0:00f0) 3. 9- 4 = 15 manufacturer part number
(000f:0001) 3. 3- 0 = 1 manufacturer rev. number

4. (01e1) -- Autonegotiation advertisement register --
(8000:0000) 4.15 = 0 next page able
(4000:0000) 4.14 = 0 reserved
(2000:0000) 4.13 = 0 remote fault
(1000:0000) 4.12 = 0 reserved
(0800:0000) 4.11 = 0 asymmetric pause
(0400:0000) 4.10 = 0 pause enable
(0200:0000) 4. 9 = 0 100BASE-T4 able
(0100:0100) 4. 8 = 1 100BASE-TX full duplex able
(0080:0080) 4. 7 = 1 100BASE-TX able
(0040:0040) 4. 6 = 1 10BASE-T full duplex able
(0020:0020) 4. 5 = 1 10BASE-T able
(001f:0001) 4. 4- 0 = 1 selector = IEEE 802.3

5. (45e1) -- Autonegotiation partner abilities register --
(8000:0000) 5.15 = 0 next page able
(4000:4000) 5.14 = 1 acknowledge
(2000:0000) 5.13 = 0 remote fault
(1000:0000) 5.12 = 0 (reserved)
(0800:0000) 5.11 = 0 asymmetric pause able
(0400:0400) 5.10 = 1 pause able
(0200:0000) 5. 9 = 0 100BASE-T4 able
(0100:0100) 5. 8 = 1 100BASE-X full duplex able
(0080:0080) 5. 7 = 1 100BASE-TX able
(0040:0040) 5. 6 = 1 10BASE-T full duplex able
(0020:0020) 5. 5 = 1 10BASE-T able
(001f:0001) 5. 4- 0 = 1 selector = IEEE 802.3

Are the respective conf_<module>_<pin> register for each of these terminals configured for pin mux mode "0" by setting bits [2:0] to 000b?

Is the input enable for each of these terminals been enabled by by setting bit [5] to 1b?

Have you selected MII mode in the gmii_sel register by setting bits [1:0] to 00b?

Regards,
Paul

This is how it's done. It's actually a copy of what i found in board/ti/am335x_evm/mux.c

static struct module_pin_mux mii1_pin_mux[] = {
{OFFSET(mii1_rxerr), MODE(0) | RXACTIVE}, /* MII1_RXERR */
{OFFSET(mii1_txen), MODE(0)}, /* MII1_TXEN */
{OFFSET(mii1_rxdv), MODE(0) | RXACTIVE}, /* MII1_RXDV */
{OFFSET(mii1_txd3), MODE(0)}, /* MII1_TXD3 */
{OFFSET(mii1_txd2), MODE(0)}, /* MII1_TXD2 */
{OFFSET(mii1_txd1), MODE(0)}, /* MII1_TXD1 */
{OFFSET(mii1_txd0), MODE(0)}, /* MII1_TXD0 */
{OFFSET(mii1_txclk), MODE(0) | RXACTIVE}, /* MII1_TXCLK */
{OFFSET(mii1_rxclk), MODE(0) | RXACTIVE}, /* MII1_RXCLK */
{OFFSET(mii1_rxd3), MODE(0) | RXACTIVE}, /* MII1_RXD3 */
{OFFSET(mii1_rxd2), MODE(0) | RXACTIVE}, /* MII1_RXD2 */
{OFFSET(mii1_rxd1), MODE(0) | RXACTIVE}, /* MII1_RXD1 */
{OFFSET(mii1_rxd0), MODE(0) | RXACTIVE}, /* MII1_RXD0 */
{OFFSET(mdio_data), MODE(0) | RXACTIVE | PULLUP_EN}, /* MDIO_DATA */
{OFFSET(mdio_clk), MODE(0) | PULLUP_EN}, /* MDIO_CLK */
{-1},
};

And this is how a use it:

configure_module_pin_mux(mii1_pin_mux);

Also, in board.c I do:

writel(MII_MODE_ENABLE, &cdev->miisel);

where MII_MODE_ENABLE is defined as 0x00.

Regarding the table... I see that for a AM335x EVM one should use PSP 04.06.00.19.

I have not been able to find this PSP. Any clue where it is?