Debugging custom U-boot

The clocks on my custom design are as follows:

- SYSCLK is 153.6 MHz
- ARMCLK is 122.88 MHz
- DDR3A and DDR3B are 100 MHz
- SRIOSGMIICLK is 156.25 MHz

Right now I am debugging the ethernet interface, in the Uboot environment. We are using the same Marvell 88E1111 PHY and SRIOSGMIICLK values in our design as the EVM. As such, I left the CONFIGs the same:

/* Network Configuration */
#define CONFIG_ETH_PHY_MARVEL_88E1111
#define CONFIG_DRIVER_TI_KEYSTONE_NET
#define CONFIG_MII
#define CONFIG_BOOTP_DEFAULT
#define CONFIG_BOOTP_DNS
#define CONFIG_BOOTP_DNS2
#define CONFIG_BOOTP_SEND_HOSTNAME
#define CONFIG_NET_RETRY_COUNT 32
#define CONFIG_NET_MULTI
#define CONFIG_GET_LINK_STATUS_ATTEMPTS 5
#define CONFIG_SYS_SGMII_REFCLK_MHZ 312
#define CONFIG_SYS_SGMII_LINERATE_MHZ 1250
#define CONFIG_SYS_SGMII_RATESCALE 2

One difference is I am using the SGMII2 interface instead of 0 or 1 like the EVM. What changes might I have to make for this difference? I noticed the addition of eth2 and eth3 in eth_priv_t eth_priv_cfg[] which is in board.c and one difference is .sgmii_link_type =SGMII_LINK_MAC_MAC_FORCED versus .sgmii_link_type = SGMII_LINK_MAC_PHY. But I'm not sure what the differences between those two are in relation to my issue. Uboot seems to initialize all 4 interfaces just fine and gets to the command prompt, but if I try to do something like "ping", there is no response.

Any thoughts on how to attack this?

After gaining a bit of understanding on the setup this is where I am at:

In custom/board.c:

eth_priv_cfg[] = {
{
.int_name = "K2HK_EMAC2",
.rx_flow = 24,
.phy_addr = 0,
.slave_port = 3,
.sgmii_link_type = SGMII_LINK_MAC_PHY,
}
}

In ./drivers/net/keystone_net.c I changed which port reads the internal MACID:

if (eth_priv->slave_port == 3) {
maca = __raw_readl(MAC_ID_BASE_ADDR);
macb = __raw_readl(MAC_ID_BASE_ADDR + 4);
}

So now things are looking reasonable. Let's read back the Port 3 SGMII registers:

02090400: 4ec20101 00000000 00000000 00000000 ...N............
02090410: 00000001 0000003d 00000001 00000000 ....=...........
02090420: 0000d801 00000000 00000000 00000000 ................
02090430: 00000000 00000000 00000000 00000000 ................
02090440: 00000000 00000000 00000ee9 00000000 ................

The MR_LP_ADV_ABILITY indicates a successful autoneg. These also match the same regs for port 0 of the EVM when it's connected.

But when I look at the STATS regsiters is where the problem is:

02090b00: 00000000 00000000 00000000 00000000 ................
02090b10: 00000000 00000000 00000000 00000000 ................
02090b20: 00000000 00000000 00000000 00000000 ................
02090b30: 00000000 00000000 00000000 00000000 ................
02090b40: 00000000 00000000 00000000 00000000 ................
02090b50: 00000000 00000000 00000000 00000000 ................
02090b60: 00000000 00000000 00000000 00000000 ................
02090b70: 00000000 00000000 00000000 00000000 ................
02090b80: 00000000 00000000 00000000 00000000 ................
02090b90: 00000000 00000000 00000000 00000000 ................
02090ba0: 00000000 00000000 00000000 00000000 ................
02090bb0: 00000000 00000000 00000000 00000000 ................
02090bc0: 00000000 00000000 00000000 00000000 ................
02090bd0: 00000000 00000000 00000000 00000000 ................
02090be0: 00000000 00000000 00000000 00000000 ................
02090bf0: 00000000 00000000 00000000 00000000 ................
02090c00: 00000000 00000000 00000000 00000000 ................
02090c10: 00000000 00000000 00000000 00000000 ................
02090c20: 00000000 00000000 00000000 00000000 ................
02090c30: 00000000 00000000 00000000 00000000 ................
02090c40: 00000000 00000000 00000000 00000000 ................
02090c50: 00000000 00000000 00000000 00000000 ................
02090c60: 00000000 00000000 00000000 00000000 ................
02090c70: 00000000 00000000 00000000 00000000 ................
02090c80: 00000000 00000000 00000000 00000000 ................
02090c90: 00000000 00000000 00000000 00000000 ................
02090ca0: 00000000 00000000 00000000 00000000 ................
02090cb0: 00000000 00000000 00000000 00000000 ................
02090cc0: 00000000 00000000 00000000 00000000 ................
02090cd0: 00000000 00000000 00000000 00000000 ................
02090ce0: 00000000 00000000 00000000 00000000 ................
02090cf0: 00000000 00000000 00000000 00000000 ................

There are no RX/TX STATS, after trying to ping, or dhcp, or connecting a laptop directly to the board and sending traffic.

Hi,

Have you configured the the u-boot to use correct port to ping or dhcp?

If not configure the ethact and ethaddr u-boot environment variables correctly. Then try ping or dhcp commands.

Example for port 1:

setenv ethact ____#1

setenv ethaddr1 12:34:45:xx:xx:xx

Rajasekaran,

Thanks for the reply. Those ARE set. 

For what it's worth, I also enabled the POST for the post_eth_loopback_test and it comes back "FAILED".

See debug prints:

POST EMAC TEST for port 2 ... + emac_open
- emac_open
{post_eth_loopback_test}: PHY REG0=0x1140
{post_eth_loopback_test}: PHY REG2=0x0141
{post_eth_loopback_test}: PHY REG3=0x0CC2
{post_eth_loopback_test}: tci6614_eth_phy_read ret=0 from phy_addr=0
{post_eth_loopback_test}: PHY REG0=0x0140
{post_eth_loopback_test}: writing 0x4140 to phy_addr=0
{post_eth_loopback_test}: PHY REG0=0x4140
{init_mac}: port=0, mac[0]=0x7C,mac[1]=0x66{init_mac}: port=1, mac[0]=0x7C,mac[1]=0x66{init_mac}: port=2, mac[0]=0x7C,mac[1]=0x66{tci6614_eth_send_packet}: loopback_test=1
{tci6614_eth_send_packet}: Sending packet...
{tci6614_eth_send_packet}: Returning=270
We havn't received the packet back
+ emac_close
- emac_close
FAILED

As you can see it is putting the PHY in loopback mode, and trying to send a packet, but it fails. Thanks.

Hi Justin,

I have reviewed your u-boot code changes, i have a suggestion to verify at your end.

1. Instead of having only EMAC2 configuration on eth_priv_cfg[], could you add EMAC2 configurations to the existing EMAC configuration as below and try.

eth_priv_t eth_priv_cfg[] = {
        {
                .int_name       = "TCI6638_EMAC",
                .rx_flow        = 22,
                .phy_addr       = 0,
                .slave_port     = 1,
                .sgmii_link_type = SGMII_LINK_MAC_PHY,
        },

        {
                .int_name       = "TCI6638_EMAC1",
                .rx_flow        = 23,
                .phy_addr       = 1,
                .slave_port     = 2,
                .sgmii_link_type = SGMII_LINK_MAC_PHY,
        },

        {
                .int_name       = "TCI6638_EMAC2",
                .rx_flow        = 24,
                .phy_addr       = 2,
                .slave_port     = 3,
                .sgmii_link_type = SGMII_LINK_MAC_PHY,
        },
};

2. Please try ping or dhcp with below environment variables set. I have verified this in EVM  for TCI6638_EMAC1(default it uses TCI6638_EMAC).

setenv ethact TCI6638_EMAC2
setenv eth2addr 11:22:33:44:55:66
setenv ipaddr xx.xx.xx.xx
setenv gatewayip xx.xx.xx.xx
saveenv
reset

Rajasekaran,

Thanks for the reply. I had already put those fields back in the array because I noticed that the POST code needed it that way as it used the index into eth_priv_cfg as synonymous with the slave port number. 

Going from a different angle. I tried the SGMII loopback test but I wasn't sure what to expect besides seeing that it showed the  Link indicator bit in SGMII 3 status as "UP".  I'm working on trying the MAC Loopback now.

Q1. Which loopback test would you suggest to help isolate whether this is truly a software issue, or perhaps a hardware issue.

Q2. By the way, I'm curious how the SGMII Status register showing Autonegotiation is complete and the Link Partner Advertised Ability Register (MR_LP_ADV_ABILITY) are filled if MDIO is disabled (has_mdio=0). Does this indicate that the PHY is talking to the Keystone on some level via the SGMII lines?

Thanks.

This has turned into an interesting DDR3 issue instead of a SGMII Ethernet one. Please see this post: http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/t/340504.aspx

The MAC and SGMII loopbacks were a good test that demonstrated it worked on the EVM but not our board with Uboot running from DDR3. Once I moved Uboot to the Shared Memory SRAM it worked just fine!

Hi Justin,

Good to hear that the u-boot worked fine. 

My very first suggestion is, to run the u-boot on SRAM. Hope to resolve the DDR issue soon.

http://e2e.ti.com/support/dsp/c6000_multi-core_dsps/f/639/p/339435/1186114.aspx#1186114

Thank you for the update.

Rajasekaran , I'm sorry to reject your Verification but the original question in this post hasn't been answered. I was using the method in your link from the very beginning. I make uboot, copy the .bin into memory, use Load Symbols on the "u-boot" file, but no symbols are loaded it seems.