TFTP issues in u-boot on AM5K2E Keystone2

I have tried switching the TFTP server to several different programs and computers (Windows and Linux) and it still happens with the same frequency.

Have you tried with static IP configuration like connect the ethernet cable PC to target then try TFTP ?
Not getting any issues for small transfer ?
If its frozen or hang ? its never come back to shell with timeout error ?

Please share the console log of the issue. How about ping command response, is it success always?

I have tried static IP config and connected directly to a computer, and also tried a switch, and I still have the same issue on both.
I'm not sure whether it's frozen or hung, but it never get a timeout or return to a shell. Ctrl+C doesn't exit the command.

No issue with small transfers. This only occurs at some point during long transfers, like there's a cycle that catches the long transfers but the small transfers are short enough to not get caught.

I will grab console output and post it.

Ping behaves the same way it does on our eval boards. Which don't have this issue. We can ping out from the board just fine.

Here is an example where I'm trying to transfer a 4MB file. It just stops...
TFTP error Console output:


U-Boot SPL 2013.01-gde29995-dirty (Apr 26 2016 - 18:19:18)
SF: Detected N25Q128A with page size 64 KiB, total 16 MiB


U-Boot 2013.01-gde29995 (Apr 26 2016 - 18:19:18)

I2C: ready
Skipping get_dimm_params_from_spd
DDR3 speed 0
DRAM: 4 GiB

Reseting entire DDR3 memory to 0 ...
DRAM: 512 MiB
NAND: 2048 MiB
Using default environment

In: serial
Out: serial
Err: serial
Smart Reflex Class 0 temperature compensation enabled
tps544_init i2c write error
Smart Reflex Class 0 temperature compensation disabled
Net: BOARD_EMAC0
Warning: BOARD_EMAC0 using MAC address from net device
, BOARD_EMAC1, BOARD_EMAC2, BOARD_EMAC3
Hit any key to stop POST: 0
Hit any key to stop autoboot: 0

BOARD Rev A # tftp 80100000 vxWorks.bin
Using BOARD_EMAC2 device
TFTP from server 192.168.20.200; our IP address is 192.168.20.199
Filename 'vxWorks.bin'.
Load address: 0x80100000
Loading: T #################################################################
################################################################

I do not have any suggestion for this. I will check with factory team on this.

Do you see this behavior with all of your custom boards or few boards?

Thank you

Hi, Samuel,

I am not sure what the issue is but why is your DRAM only 512MB?

Reseting entire DDR3 memory to 0 ...
DRAM: 512 MiB
NAND: 2048 MiB
Using default environment

Compared to TI's:

Reseting entire DDR3 memory to 0 ...
DRAM:  2 GiB
NAND:  512 MiB
Net:   K2E_EMAC0, K2E_EMAC1, K2E_EMAC2, K2E_EMAC3, K2E_EMAC4, K2E_EMAC5, K2E_EMAC6, K2E_EMAC7
Hit any key to stop autoboot:  0
K2E EVM #

Have you noticed where the limit is for small size file transfer?

Rex

Hi, Samuel,

The more I think about the issue, the more I am toward it's u-boot. 2 things you modified, the ethernet configuration which seems to work, and the u-boot which seems to be the only culprit.

Could you use the release branch instead for your changes? I also noticed that in your logs, the DDR3 speed is 0, but TI EVM shows 1600

I2C:   ready
SPD csum OK; in SPD: 33 CC; computed 00000033 CC
DDR3A Speed will be configured for 1600 Operation.
Detected SO-DIMM [18KSF51272HZ-1G6K2]
DDR3 speed 1600
DRAM: 4 GiB

Rex

Samuel Smith said:

1. The SGMII Serdes clock runs at 125 instead of 156.25, so we had to edit the driver/net/keystone_serdes.c registers for that.

I had to go through quite a rigamarole to switch the SGMII Serdes clock from 156.25 to 125; I ended up sucking a large portion of the CSL into U-Boot (a ghastly hack, I admit, but it got me off the dime). 

How much did you change in keystone_serdes.c?  Where did you get the magick numbers for this thing:

/**

* Array to hold all possible serdes configurations.
* Combination for 5 clock settings and 6 baud rates.
*/
static struct cfg_entry cfgs[] = {

Thank you for trying to help me with this!

I only changed the cfg_cmu_156p25m_5g, cfg_comlane_156p25m_5g, and cfg_lane_156p25mhz_5g arrays to match a file from the PDK_Keystone2 for the 125 clock speed. That file is installed at C:\ti\pdk_keystone2_3_01_04_07\packages\ti\csl\src\ip\serdes_sb\V0\csl_wiz8_sb_refclk125MHz_10bit_5Gbps.c.

So now they look like this:

static struct serdes_cfg cfg_cmu_156p25m_5g[] = {
{0x0000, 0x00800000, 0xffff0000},
{0x0014, 0x00008282, 0x0000ffff},
{0x0060, 0x00132c48, 0x00ffffff}, /*changed*/
{0x0064, 0x00c3c700, 0x00ffff00},
{0x0078, 0x0000c000, 0x0000ff00}
};

static struct serdes_cfg cfg_comlane_156p25m_5g[] = {
{0x0a00, 0x00000800, 0x0000ff00},
{0x0a08, 0x37720000, 0xffff0000}, /*changed*/
{0x0a30, 0x00777700, 0x00ffff00}, /*changed*/
{0x0a84, 0x00000700, 0x0000ff00}, /*changed*/
{0x0a94, 0x10000000, 0xff000000},
{0x0aa0, 0x81000000, 0xff000000},
{0x0abc, 0xff000000, 0xff000000},
{0x0ac0, 0x0000008b, 0x000000ff},
{0x0b08, 0x583f0000, 0xffff0000},
{0x0b0c, 0x0000004e, 0x000000ff},
{0x0a48, 0x00fd8c00, 0x00ffff00}, /*changed*/
{0x0a54, 0x002fec72, 0x00ffffff}, /*changed*/
{0x0a58, 0x00f92100, 0xffffff00}, /*changed*/
{0x0a5c, 0x00040060, 0xffffffff}, /*changed*/
{0x0a60, 0x00008000, 0xffffffff}, /*changed*/
{0x0a64, 0x0c581220, 0xffffffff}, /*changed*/
{0x0a68, 0xe13b0602, 0xffffffff}, /*changed*/
{0x0a6c, 0xb8074cc1, 0xffffffff}, /*changed*/
{0x0a70, 0x3f02e989, 0xffffffff}, /*changed*/
{0x0a74, 0x00000001, 0x000000ff}, /*changed*/
{0x0b20, 0x00370000, 0x00ff0000}, /*changed*/
{0x0b1c, 0x37000000, 0xff000000}, /*changed*/
{0x0b20, 0x0000005d, 0x000000ff}, /*changed*/
{0x0000, 0x00000003, 0x000000ff}, /*changed*/
{0x0a00, 0x0000005f, 0x000000ff}, /*changed*/
};

static struct serdes_cfg cfg_lane_156p25mhz_5g[] = {
{0x0004, 0x78000080, 0xff0000ff}, /*changed*/
{0x0008, 0x00010020, 0x00ff00ff}, /*changed*/
{0x000c, 0x02000000, 0xff000000},
{0x0010, 0x1b000000, 0xff000000},
{0x0014, 0x00006e78, 0x0000ffff}, /*changed*/
{0x0018, 0x758000e4, 0xffff00ff},
{0x00ac, 0x00004400, 0x0000ff00},
{0x002c, 0x00300800, 0x00ffff00}, /*changed*/
{0x0080, 0x00700070, 0x00ff00ff}, /*changed*/
{0x0084, 0x1d0f0385, 0xffffffff}
};

My DDR3 differences may be affecting this. Also, the u-boot image is being built with the linaro cross-compiler, being flashed into SPI, then being copied into DDR3 to run. Since this problem is intermittent, it has been hard to pinpoint where the problem lies.

Rex Chang said:

I also noticed that in your logs, the DDR3 speed is 0, but TI EVM shows 1600

I do not have an I2C EEPROM to read the DDR3 information from (which is how the K2E EVM code populates this print statement). I have to manually enter all the info about the DDR3. I have 8 bank of 512MB. The array that is supposed to store this info I don't think gets populated correctly either, which is why it is printing 512MB during u-boot init.

There is a fresher version of U-Boot available from

git://git.ti.com/ti-u-boot/ti-u-boot.git

but it also has the limitation that the only available serdes configuration is for a 156.25 MHz clock. You could try adding your configuration (above) to that u-boot and see if it makes any difference.

Rex Chang said:

Have you noticed where the limit is for small size file transfer?

I have not noticed a limit. The tftp transfers can freeze at any point. Sometimes it stops after 10 '#' symbols, other times after 200. The largest file I have successfully transferred using tftp is the Linux filesystem at 33MB. Eventually I will be transferring larger amounts of data into NAND, using either tftp or ftp.

Charles Coldwell said:

There is a fresher version of U-Boot available from

git://git.ti.com/ti-u-boot/ti-u-boot.git

but it also has the limitation that the only available serdes configuration is for a 156.25 MHz clock. You could try adding your configuration (above) to that u-boot and see if it makes any difference.

I started using this version, rather than the upstream/k2e-evm branch, but I ran into problems with it trying to setup ethernet with the new drivers, instead of the legacy. This caused a bunch of dead-ends trying to debug it. When I started using the older branch (without the new driver), I found in the code where to control serdes and the PHY addresses. I haven't gone back, but I could as a last resort.

I unset CONFIG_DM_ETH in my defconfig so that I could use the old drivers with the new u-boot.