T4240 U-boot ping "Tx buffer not ready"

dannygale · ‎08-07-2014

We're trying to bring up the interface to a 100M/1G PHY. The SGMII physical interface is up and toggling, but the software interface is not working properly.

Our PHY has 4 ports, each of which is connected by a single SGMII lane at 1.25 Gbps. We are using lanes A-D in configuration 27, so FM2@DTSEC5, FM2@DTSEC6, FM2@DTSEC10 and FM2@DTSEC9 are the MACs in use, respectively for lanes A - D.

You can see below what happens when we try to ping. You can also see my environment variables defined below.

Looking in the DPAA manual, it's not very clear to me how to debug this issue. What can cause this "Tx buffer not ready" error?

Note that the MAC addresses are just filler right now -- they should be unique to our network and are temporary, since the actual MAC addresses haven't officially been assigned yet.

Thanks

=> ping 192.168.1.53

Using FM2@DTSEC6 device

FM2@DTSEC6: Tx buffer not ready. txbd->status = 0x8800

ping failed; host 192.168.1.53 is not alive

=> pri

baudrate=115200

bdev=sda3

bootcmd=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;setenv ramdiskaddr 0x02000000;setenv fdtaddr 0x00c00000;setenv loadaddr 0x1000000;bootm $loadaddr $ramdiskaddr $fdtaddr

bootdelay=10

bootfile=uImage

consoledev=ttyS0

eth1addr=7E:7E:7E:7E:7E:04

eth2addr=7E:7E:7E:7E:7E:06

eth3addr=7E:7E:7E:7E:7E:08

eth4addr=7E:7E:7E:7E:7E:0a

eth5addr=7E:7E:7E:7E:7E:0c

eth6addr=7E:7E:7E:7E:7E:0e

ethact=FM2@DTSEC6

ethaddr=7E:7E:7E:7E:7E:02

ethprime=FM2@DTSEC6

fdtaddr=c00000

fdtfile=t4240qds/t4240qds.dtb

fman_ucode=7fb55ef8

hwconfig=fsl_ddr:ctlr_intlv=3way_4KB,bank_intlv=auto;usb1:dr_mode=host,phy_type=utmi

ipaddr=192.168.1.230

loadaddr=1000000

netdev=eth0

nfsboot=setenv bootargs root=/dev/nfs rw nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip:$gatewayip:$netmask:$hostname:$netdev:off console=$consoledev,$baudrate $othbootargs;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr - $fdtaddr

ramboot=setenv bootargs root=/dev/ram rw console=$consoledev,$baudrate $othbootargs;tftp $ramdiskaddr $ramdiskfile;tftp $loadaddr $bootfile;tftp $fdtaddr $fdtfile;bootm $loadaddr $ramdiskaddr $fdtaddr

ramdiskaddr=2000000

ramdiskfile=t4240qds/ramdisk.uboot

rootpath=/opt/nfsroot

stderr=serial

stdin=serial

stdout=serial

tftpflash=tftpboot $loadaddr $uboot && ddr_interactive=1 && protect off $ubootaddr +$filesize && erase $ubootaddr +$filesize && cp.b $loadaddr $ubootaddr $filesize && protect on $ubootaddr +$filesize && cmp.b $loadaddr $ubootaddr $filesize

uboot="u-boot.bin"

ubootaddr=0x00201000

Environment size: 1618/8188 bytes

=>

yipingwang · ‎08-11-2014

Hello Danny,

Which version u-boot are you using? From SDK 1.6?

Would you please also provide u-boot log including RCW information?

Have a great day,
Yiping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

dannygale · ‎08-11-2014

Since we are developing a custom board, we are using u-boot 2014.07, rolled into our build system rather than the Yocto build.

Here's a boot log:

U-Boot 2014.07 (Aug 08 2014 - 19:29:05)

CPU0: T4240E, Version: 1.0, (0x82480010)

Core: e6500, Version: 1.0, (0x80400010)

Clock Configuration:

CPU0:1600 MHz, CPU1:1600 MHz, CPU2:1600 MHz, CPU3:1600 MHz,

CPU4:1600 MHz, CPU5:1600 MHz, CPU6:1600 MHz, CPU7:1600 MHz,

CPU8:1600 MHz, CPU9:1600 MHz, CPU10:1600 MHz, CPU11:1600 MHz,

CCB:500 MHz,

DDR:666.667 MHz (1333.333 MT/s data rate) (Asynchronous), IFC:125 MHz

FMAN1: 500 MHz

FMAN2: 500 MHz

QMAN: 250 MHz

PME: 250 MHz

L1: D-cache 32 KiB enabled

I-cache 32 KiB enabled

Reset Configuration Word (RCW):

00000000: 0a140010 10101010 00000000 00000000

00000010: 70382020 00d50000 ec184000 15000000

00000020: 00680000 00000000 00000000 00029000

00000030: 00000100 00000000 00000000 00000028

Board: START Processor

CPU: T4240, I2C: ready

SPI: ready

DRAM: 3 GiB (DDR3, 64-bit, CL=10, ECC off)

L2: 2 MiB enabled

enable l2 for cluster 1 fec60000

enable l2 for cluster 2 feca0000

Corenet Platform Cache: 1.5 MiB enabled

Using SERDES1 Protocol: 28 (0x1c)

Using SERDES2 Protocol: 28 (0x1c)

Using SERDES3 Protocol: 4 (0x4)

Using SERDES4 Protocol: 4 (0x4)

CPU up timeout. CPU up mask is 1 should be fff

NAND: 512 MiB

PCIe1: Endpoint, Outbound memory range: e0000000:100000000

PCICSRBAR @ 0xdf000000

R0 bus_start: 0 phys_start: 0 size: c0000000

R64 bus_start: 1000000000 phys_start: 0 size: 100000000

PCI reg:0 0000000c00000000:00000000e0000000 0000000020000000 00000000

PCI reg:1 0000000ff8000000:0000000000000000 0000000000010000 00000001

PCI reg:2 0000000ffe000000:00000000df000000 0000000001000000 00000100

PCI reg:3 0000000000000000:0000000000000000 00000000c0000000 00000108

PCI reg:4 0000000000000000:0000001000000000 0000000100000000 00000108

no link, regs @ 0xfe240000

PCIe1: Bus 00 - 00

PCIe2: Root Complex, Outbound memory range: e0000000:100000000

PCICSRBAR @ 0xdf000000

R0 bus_start: 0 phys_start: 0 size: c0000000

R64 bus_start: 1000000000 phys_start: 0 size: 100000000

PCI reg:0 0000000c20000000:00000000e0000000 0000000020000000 00000000

PCI reg:1 0000000ff8010000:0000000000000000 0000000000010000 00000001

PCI reg:2 0000000ffe000000:00000000df000000 0000000001000000 00000100

PCI reg:3 0000000000000000:0000000000000000 00000000c0000000 00000108

PCI reg:4 0000000000000000:0000001000000000 0000000100000000 00000108

no link, regs @ 0xfe250000

PCIe2: Bus 01 - 01

In: serial

Out: serial

Err: serial

Net: Fman1: Uploading microcode version 106.4.9

Fman2: Uploading microcode version 106.4.9

FM2@DTSEC1, FM2@DTSEC2, FM2@DTSEC3, FM2@DTSEC4, FM2@DTSEC6 [PRIME], FM2@DTSEC9, FM2@DTSEC10

Hit any key to stop autoboot: 0

=>

yipingwang · ‎08-12-2014

Hello Danny Gale,

Please check whether this problem is caused by RCW.

Please refer to the following information from T4240RM http://cache.freescale.com/files/32bit/doc/ref_manual/T4240RM.pdf.

In addition, since the u-boot which your are using is not provided by Freescale, I am not sure whether there is problem in u-boot source, so I suggest you verify other Ethernet ports and verify FM2@DTSEC6 in Linux Kernel. It's better to use the latest FMAN ucode from Freescale Linux SDK.

Have a great day,
Yiping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

dannygale · ‎08-13-2014

OK, I've corrected those fields in the RCW and updated to the latest FMan ucode but the behavior remains the same.

How would you recommend verifying the ethernet ports?

The plan was to flash the linux kernel, DTB, and root filesystem using tftp from u-boot. Without u-boot networking functioning, we haven't been able to load the kernel and root filesystem.

lunminliang · ‎08-24-2014

Have you checked the PHY status? Or you find other root cause?

lunminliang · ‎08-15-2014

Can you please check if the Ethernet physical link is up or not? Please check this in U-boot.

yipingwang · ‎08-13-2014

Hello Danny,

For RCW, you need to configure ECx as SGMII operation.

I suggest you check whether other Ethernet port could work or not, for exampleFM2@DTSEC1.

Since you are bringing up new board, I think you should have CodeWarrior TAP or similar tool, so you could use CodeWarrior to flash images into NOR Flash, or deploy images to SD card,please refer to P1010RDB, u-boot and SD Cards?.

My purpose is just let you exclude u-boot 2014.07 source problem, because this problem could be caused by hardware or u-boot source itself.

Have a great day,
Yiping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

dannygale · ‎08-13-2014

Hi Yiping,

I changed EC1 and EC2 in the RCW so that they are now GPIO.

I've tried the other ethernet controllers (FM2@DTSEC5, FM2@DTSEC6, FM2@DTSEC9, and FM2@DTSEC10 are active using SERDES2 protocol 27). The others behave the same way.

We have a CodeWarrior USB TAP. However, our main flash is a 16-bit NAND that is not supported by the flash programming utility.

I just compared upstream u-boot 2014.07 against the latest Freescale SDK's u-boot from git://git.freescale.com/ppc/sdk/u-boot.git. We're using the NAND flash boot mechanism in the T4240, with the RCW, PBI code source, and main code storage n the NAND flash. This configuration is supported in upstream u-boot 2014.07, but is NOT supported in the Freescale SDK version.

Additionally, the board target "T4240QDS_NAND" in u-boot 2014.07 works properly, including ethernet, on our T4240QDS development system, so the core u-boot 2014.07 source is not likely the problem but rather our particular configuration for the new board.

yipingwang · ‎08-14-2014

Hello Danny,

According to TxBD data structure, txbd->status = 0x8800, this error indicates "Last buffer in a frame", so it seems that there is initialization problem with FMAN, I suggest you use CodeWarrior to debug u-boot FMAN driver.

If there is problem with transmission clocks, and no packages transmitted out, also could cause buffers exhaust.

Have a great day,
Yiping

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------