AM6548: Custom board is booting into Uboot but cannot ping host computer.

Hello, 

May I ask the ethernet being tested here is CPSW ethernet or PRU_ICSSG ethernet? This is important to direct you to the right expert for this issue.

Additionally, are you running Linux or RTOS/Baremetal on your platform? Which SDK version are you using?

Are you running ping from your custom board to host PC or from host PC to custom board? If ping from host PC to custom board, do you get a response?

-Daolin

Hi,

It's the CPSW ethernet.

We're running VxWorks, however the SD card is set up using the 07.00.01.06 version of the Linux SDK and no changes were made to the files regarding uboot, only the OS itself. We've tested a totally unmodified Linux SDK SD card, and that couldn't ping from uboot either. Additionally, the EVM board that works fine has an identical SD card to our custom board, so I'm relatively confident that it isn't an issue caused by VxWorks.

We're pinging a host PC from the board in both cases. Pinging from the board from the host PC has no response for either the EVM or our custom board.

What complicates matters further is that the custom board successfully pinged the host PC from uboot last Friday, but it hasn't worked since, and there's nothing that I can think of that changed about our software or hardware configurations over the weekend to cause it to stop working.

Hope that helps,

-Elias

Hi Elias,

Let's troubleshoot the EVM ping issue first before the custom board.

First, can you verify there is a basic link establishment when the ethernet cable is connected between the EVM and the host PC (before any ping testing)? You can check this in U-boot by using the mii tool. For instance "mii dump 0 1" will dump the PHY registers at address 0, register address 1. Look for the "link status" entry to be "1". 

Is your host PC a Linux PC? If so, can you check the results of "ethtool -S <interface name>" on the host PC after a ping test? I'm looking for any indication of dropped or erroneous ethernet frames. 

Additionally, you may want to do a Wireshark capture on the ping packets to give more insight into what is happening when the host PC does not respond.

-Daolin

Hi Daolin,

The EVM isn't having issues pinging the host PC. I made a typo and left an additional "from" in the sentence. I meant to say that I cannot ping the board from the host PC, but that's never worked, and hasn't caused any issues.

That being said, I called "mii dump 0 1" on both boards and got an identical response from both of them:

1.     (796d)                 -- 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:0100) 1. 8    =     1     extended status
  (0080:0000) 1. 7    =     0     (reserved)
  (0040:0040) 1. 6    =     1     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

Both are reporting that there is indeed ta basic link established.

As for the host, it's a Linux VM running on a windows machine with a bridged ethernet connection. When I run "ethtool -S" on the host PC, it responds with "no stats available", whether it be before or after a ping test.

I did also do a wireshark capture on the ping, however, I didn't learn much from it.

When I ping the PC from the EVM, I see the ARP request from the EVM, followed by the responce from the host, and then the ping request and reply packets like normal. However when I ping the PC from the custom board, I see nothing, no ARP request, no ping request, no traffic that I can identify as from the board at all.

Going the other direction and pinging the boards from the PC, I see the ARP request going out from the PC, and no response from either, but again, that hasn't caused any issues for us with the EVM, so I don't think it'll be a problem for the custom board either.

-Elias

Hi Elias,

Thanks for clarifying the issue, let's focus on the issue of ping PC from custom board since EVM is known working with this use case. Out of curiosity, the fact that going in the other direction to ping EVM from PC results in no response from the EVM does seem concerning, but you mention it hasn't caused issues... what you mean the fact it hasn't caused issues?

Since it looks like from mii dump a link partner is detected through the connection from the custom board to the PC, the next step is to look at whether the IP address of the custom board ethernet is on the same subnet as the PC. Are you setting the IP address statically (env.txt, saved environment, or setenv ipaddr, etc) or dynamically through DHCP?

Are you able to share the console log of the custom board when you run ping in U-boot and the corresponding wireshark screenshot? Perhaps, we can provide some insight on the results. 

-Daolin

Hi Daolin,

The reason I say that not being able to ping the EVM from the PC hasn't caused an issue is because we're still able to connect to the EVM via the ethernet port once it's booted into an OS just fine. The only thing it doesn't respond to is pings, but it can communicate using UDP or TCP just fine. Not sure why that's the case, but if it works, that's good enough for me.

I'm setting the IP addresses of both boards statically via setenv ippaddr. I set the EVM to 10.10.61.144 and the custom board to 10.10.61.142. The ethernet adapter for the VM has a statically set IP address of 10.10.61.223, and I have an external ethernet dongle on the windows side set to 10.10.61.197 so that I have something on the windows side on that same subnet.

Here's the console log from the custom board ping to both the Linux VM and the windows dongle.

U-Boot SPL 2020.01-gf9b0d030d3 (Aug 10 2020 - 17:47:39 +0000)
SYSFW ABI: 3.0 (firmware rev 0x0014 '20.04.1-v2020.04a (Terrific Lla')
Reading on-board EEPROM at 0x50 failed -1
i2c_write: error waiting for data ACK (status=0x116)
Trying to boot from MMC2
i2c_write: error waiting for data ACK (status=0x116)
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.3():07.00.00.005-dirty
NOTICE:  BL31: Built : 17:03:45, Aug 10 2020

U-Boot SPL 2020.01-gf9b0d030d3 (Aug 10 2020 - 17:11:07 +0000)
SYSFW ABI: 3.0 (firmware rev 0x0014 '20.04.1-v2020.04a (Terrific Lla')
Reading on-board EEPROM at 0x50 failed -1
i2c_write: error waiting for data ACK (status=0x116)
Error reading output register
Trying to boot from MMC2


U-Boot 2020.01-gf9b0d030d3 (Aug 10 2020 - 17:11:07 +0000)

SoC:   AM65X SR2.0
Model: Texas Instruments AM654 Base Board
Reading on-board EEPROM at 0x50 failed -1
Board: AM6-COMPROCEVM rev E3
DRAM:  4 GiB
MMC:   sdhci@4f80000: 0, sdhci@04FA0000: 1
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Reading on-board EEPROM at 0x50 failed -1
i2c_write: error waiting for data ACK (status=0x116)
Error reading output register
Net:   eth0: cpsw_nuss@046000000
Hit any key to stop autoboot:  0 
=> ping 10.10.61.197
link up on port 1, speed 1000, full duplex
Using cpsw_nuss@046000000 device

ARP Retry count exceeded; starting again
ping failed; host 10.10.61.197 is not alive
=> ping 10.10.61.223
link up on port 1, speed 1000, full duplex
Using cpsw_nuss@046000000 device

ARP Retry count exceeded; starting again
ping failed; host 10.10.61.223 is not alive
=> 

I'd also include a wireshark screenshot, but there's nothing when doing it from the custom board.

Here's the same things from the EVM.

U-Boot SPL 2020.01-gf9b0d030d3 (Aug 10 2020 - 17:47:39 +0000)
SYSFW ABI: 3.0 (firmware rev 0x0014 '20.04.1-v2020.04a (Terrific Lla')
Trying to boot from MMC2
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.3():07.00.00.005-dirty
NOTICE:  BL31: Built : 17:03:45, Aug 10 2020

U-Boot SPL 2020.01-gf9b0d030d3 (Aug 10 2020 - 17:11:07 +0000)
SYSFW ABI: 3.0 (firmware rev 0x0014 '20.04.1-v2020.04a (Terrific Lla')
Detected: AM6-IDKAPPEVM rev A
Detected: SER-PCIE2LEVM rev A
Trying to boot from MMC2


U-Boot 2020.01-gf9b0d030d3 (Aug 10 2020 - 17:11:07 +0000)

SoC:   AM65X SR2.0
Model: Texas Instruments AM654 Base Board
Board: AM6-COMPROCEVM rev A
DRAM:  4 GiB
MMC:   sdhci@4f80000: 0, sdhci@04FA0000: 1
Loading Environment from MMC... OK
In:    serial
Out:   serial
Err:   serial
Detected: AM6-IDKAPPEVM rev A
Detected: SER-PCIE2LEVM rev A
Net:   eth0: cpsw_nuss@046000000
Hit any key to stop autoboot:  0 
=> ping 10.10.61.197
link up on port 1, speed 1000, full duplex
Using cpsw_nuss@046000000 device
host 10.10.61.197 is alive
=> ping 10.10.61.223
link up on port 1, speed 1000, full duplex
Using cpsw_nuss@046000000 device
host 10.10.61.223 is alive
=> 

- Elias

Hi,

Reviewing the thread I want to make a comment on the Ping discussion. U-Boot does not run any daemons or background threads. To respond to a Ping request a ICMP server must be running waiting for the Ping requests that it can respond to. U-Boot is a single threaded stateless application, all commands assume no state so any interfaces used are completely re-initialized every time they are used.

There are some error codes in the above log from the custom board related to reading the eeprom, this is where the MAC addresses are stored.

The log file indicates link up and then the ARP tries are exhausted. This at the moment could point to a pin mux or phy mode being incorrect. If the CPSW driver thinks there is a link then packets will be sent and you are not seeing any being transmitted from wireshark. Please verify the pin mux and PHY interfaces modes.

Best Regards,

Schuyler

Hi, the pin mux should be the same because the pins in which the signals are going to are unchanged from the EVM design. The custom board is using a different transceiver, however. The custom board is using a DP83869HMRGZT, whereas the EVM uses DP83867IRRGZ. Could this cause an issue? 

Also, if the MAC address is stored in the EEPROM, does this mean any OS running on the board will pick up the MAC address from there? We are able to successfully ping from the target to the host within Linux.

Hi,

The EEPROM is used to store the MAC address on TI EVMs. The EEPROMs are programmed at the time of manufacture. As U-Boot prepares to boot the Linux kernel the Linux Board DTB file is modified after loading into memory with the MAC addresses read by U-Boot from the EEPROM. As the kernel initializes, if the default value for MAC addresses is not changed from all 0s then a random MAC address is assigned by Linux. A random MAC address is not recommended. How do you plan to store MAC addresses for your product?

Earlier in the thread it was mentioned that VxWorks is the high level OS and Linux is mentioned in this post. Which HLOS is planned for your product?

I will need to consult with the development team for additional debug suggestions. Since the EEPROM read is failing this could be impacting U-Boot's network functionality.

Best Regards,

Schuyler 

Hi,

Uboot says that there is a MAC address (stored in the environment variable ethaddr) that was set when I initially set up the board. This MAC address isn't all zeros, and also is different from the EVM's.

Here's the full list of environment variables in uboot, in case that's helpful.

addr_fit=0x90000000
arch=arm
args_all=setenv optargs earlycon=ns16550a,mmio32,0x02800000 ${mtdparts}
args_mmc=run finduuid;setenv bootargs console=${console} ${optargs} root=PARTUUID=${uuid} rw rootfstype=${mmcrootfstype}
args_ubi=setenv bootargs console=${console} ${optargs} rootfstype=ubifs root=ubi0:rootfs rw ubi.mtd=ospi.rootfs
baudrate=115200
board=am65x
board_name=am65x
boot=mmc
boot_fit=0
boot_rprocs=if test ${dorprocboot} -eq 1 && test ${boot} = mmc; then rproc init;run boot_rprocs_mmc;fi;
boot_rprocs_mmc=env set rproc_id;env set rproc_fw;for i in ${rproc_fw_binaries} ; do if test -z "${rproc_id}" ; then env set rproc_id $i;else env set rproc_fw $i;run rproc_load_and_boot_one;env set rproc_id;env set rproc_fw;fi;done
bootcmd=run tftp_bootargs; run sd_get_image; run sd_get_dtb; run sd_get_dtbo1; run tftp_setup_dtbo; run sd_get_dtbo2; run tftp_setup_dtbo; run tftp_boot
bootdelay=2
bootdir=/boot
bootenvfile=uEnv.txt
bootpart=1:2
bootscript=echo Running bootscript from mmc${mmcdev} ...; source ${loadaddr}
console=ttyS2,115200n8
cpu=armv8
dfu_alt_info_emmc=rawemmc raw 0 0x800000 mmcpart 1;rootfs part 0 1 mmcpart 0;tiboot3.bin.raw raw 0x0 0x400 mmcpart 1;tispl.bin.raw raw 0x400 0x1000 mmcpart 1;u-boot.img.raw raw 0x1400 0x2000 mmcpart 1;u-env.raw raw 0x3400 0x100 mmcpart 1;sysfw.itb.raw raw 0x3600 0x800 mmcpart 1
dfu_alt_info_mmc=boot part 1 1;rootfs part 1 2;tiboot3.bin fat 1 1;tispl.bin fat 1 1;u-boot.img fat 1 1;uEnv.txt fat 1 1;sysfw.itb fat 1 1
dfu_alt_info_ospi=tiboot3.bin raw 0x0 0x080000;tispl.bin raw 0x080000 0x200000;u-boot.img raw 0x280000 0x400000;u-boot-env raw 0x680000 0x020000;sysfw.itb raw 0x6c0000 0x100000;rootfs raw 0x800000 0x3800000
dfu_bufsiz=0x20000
dorprocboot=0
envboot=mmc dev ${mmcdev}; if mmc rescan; then echo SD/MMC found on device ${mmcdev};if run loadbootscript; then run bootscript;else if run loadbootenv; then echo Loaded env from ${bootenvfile};run importbootenv;fi;if test -n $uenvcmd; then echo Running uenvcmd ...;run uenvcmd;fi;fi;fi;
ethact=cpsw_nuss@046000000
ethaddr=34:08:e1:5b:cc:b7
fdtaddr=0x82000000
fdtcontroladdr=fdec7598
fileaddr=90000000
filesize=11516
findfdt=setenv name_fdt k3-am654-base-board.dtb;setenv fdtfile ${name_fdt}
finduuid=part uuid mmc ${bootpart} uuid
gatewayip=10.10.0.0
get_fdt_mmc=load mmc ${bootpart} ${fdtaddr} ${bootdir}/${name_fdt}
get_fdt_ubi=ubifsload ${fdtaddr} ${bootdir}/${name_fdt}
get_fit_mmc=load mmc ${bootpart} ${addr_fit} ${bootdir}/${name_fit}
get_kern_mmc=load mmc ${bootpart} ${loadaddr} ${bootdir}/${name_kern}
get_kern_ubi=ubifsload ${loadaddr} ${bootdir}/${name_kern}
get_overlay_mmc=fdt address ${fdtaddr};fdt resize 0x100000;for overlay in $name_overlays;do;load mmc ${bootpart} ${overlayaddr} ${bootdir}/${overlay};fdt apply ${overlayaddr};done;
get_overlaystring=for overlay in $name_overlays;do;setenv overlaystring ${overlaystring}'#'${overlay};done;
importbootenv=echo Importing environment from mmc${mmcdev} ...; env import -t ${loadaddr} ${filesize}
init_mmc=run args_all args_mmc
init_ubi=run args_all args_ubi; sf probe; ubi part ospi.rootfs; ubifsmount ubi:rootfs;
ipaddr=10.10.61.142
loadaddr=0x80080000
loadbootenv=fatload mmc ${mmcdev} ${loadaddr} ${bootenvfile}
loadbootscript=load mmc ${mmcdev} ${loadaddr} boot.scr
loadfdt=load ${devtype} ${bootpart} ${fdtaddr} ${bootdir}/${fdtfile}
loadimage=load ${devtype} ${bootpart} ${loadaddr} ${bootdir}/${bootfile}
mmcboot=mmc dev ${mmcdev}; devnum=${mmcdev}; setenv devtype mmc; if mmc rescan; then echo SD/MMC found on device ${mmcdev};if run loadimage; then run args_mmc; if test ${boot_fit} -eq 1; then run run_fit; else run mmcloados;fi;fi;fi;
mmcdev=1
mmcloados=if test ${boot_fdt} = yes || test ${boot_fdt} = try; then if run loadfdt; then bootz ${loadaddr} - ${fdtaddr}; else if test ${boot_fdt} = try; then bootz; else echo WARN: Cannot load the DT; fi; fi; else bootz; fi;
mmcrootfstype=ext4 rootwait
mtdids=nor0=47040000.spi.0
mtdparts=mtdparts=47040000.spi.0:512k(ospi.tiboot3),2m(ospi.tispl),4m(ospi.u-boot),128k(ospi.env),128k(ospi.env.backup),1m(ospi.sysfw),-@8m(ospi.rootfs)
name_fit=fitImage
name_kern=Image
name_overlays=k3-am654-idk.dtbo k3-am654-pcie-usb2.dtbo
netmask=225.225.225.0
overlayaddr=0x83000000
partitions=name=rootfs,start=0,size=-,uuid=${uuid_gpt_rootfs}
rd_spec=-
rproc_fw_binaries=0 /lib/firmware/am65x-mcu-r5f0_0-fw 1 /lib/firmware/am65x-mcu-r5f0_1-fw
rproc_load_and_boot_one=if load mmc ${bootpart} $loadaddr ${rproc_fw}; then if rproc load ${rproc_id} ${loadaddr} ${filesize}; then rproc start ${rproc_id};fi;fi
run_fit=bootm ${addr_fit}#${fdtfile}${overlaystring}
run_kern=booti ${loadaddr} ${rd_spec} ${fdtaddr}
sd_get_dtb=fatload mmc 1 0x90000000 k3-am654-base-board-sr1.dtb
sd_get_dtbo1=fatload mmc 1 0x91000000 k3-am654-idk-sr1.dtbo
sd_get_dtbo2=fatload mmc 1 0x91000000 k3-am654-pcie-usb2.dtbo
sd_get_image=fatload mmc 1 0x93000000 uVxWorks
serverip=10.10.61.223
soc=k3
stdin=serial,usbkbd
tftp_boot=bootm 0x93000000 - 0x90000000
tftp_bootargs=setenv bootargs cpsw(0,0)host:vxWorks h=${serverip} e=${ipaddr}:ffffff00 u=target pw=vxTarget f=0x1
tftp_get_dtb=tftpboot 0x90000000 k3-am654-base-board-sr1.dtb
tftp_get_dtbo1=tftpboot 0x91000000 k3-am654-idk-sr1.dtbo
tftp_get_dtbo2=tftpboot 0x91000000 k3-am654-pcie-usb2.dtbo
tftp_get_image=tftpboot 0x93000000 uVxWorks
tftp_setup_dtbo=fdt address 0x90000000; fdt resize 0x100000; fdt apply 0x91000000
update_to_fit=setenv loadaddr ${addr_fit}; setenv bootfile ${name_fit}
vendor=ti

Environment size: 5615/131067 bytes

VxWorks is our high level OS, we used Linux to test some things and make sure that it wasn't an issue with VxWorks or the way the SD card was set up.

Thanks,

Elias

Hi,

Thank you for the info, I will discuss with our developer for some ideas as mentioned in my previous post. I will respond on Tuesday next week.

The challenge here might be if u-boot is examining the environment variable. Is this one you set being passed to Linux? If you manually set the ethaddr for this phase of your project how are you planning to set the ethaddr?

Best Regards,

Schuyler

Hi,

ethaddr was set automatically, I didn't have to set it manually myself using setenv.

And yes, it did get passed onto Linux, checking the arp cache on the host showed that the physical address of the ping from Linux was the same as the one saved as ethaddr.

Thanks,

Elias

Hi,

Thanks for the update. I will post a response on Tuesday regarding some next debug steps. 

Best Regards,

Schuyler

Hi,

After discussing with the development team the EEPROM is coming from U-Boot's attempt to read the Board ID from the EEPROM. This is used to load the correct DTB for booting to the kernel.

Since the messages are timing out this indicates that the DMA portion of the TX process is working.

The next step is to look at the MAC HW statistics. U-Boot does not have an easy way like Linux (ethtool -S) to look at the statistics. You will have to use a mem display command. This is the relevant section in the TRM 12.2.1.6.7 MCU_CPSW0_STATS0 Registers. These are the registers that are of interest:

• 0003A000h CPSW_STAT0_RXGOODFRAMES Ethernet Port N Total Number of Good Frames Received 4603 A000h
  • md.l 0x3A000
• 0003A034h CPSW_STAT0_TXGOODFRAMES Ethernet Port N Good Transmit Frames Register
  • md.l 0x3A034

There are several registers in the statistics. The TX Good Frames is of interest since this shows if the packets are leaving the processor.

Pin mux may be an issue but earlier in the thread there is mention of using Linux earlier in the thread, I would like to confirm that ping worked at the Linux level and the DTS pin mux is the same?

Since you are using a VM to run Linux I would like to suggest to just try Wireshark on Windows, no need to worry about IP address assignment. We just want to see a packet leave the device, Do these commands and see if the packets show up on Wireshark:

setenv autoload no

dhcp

Best Regards,

Schuyler 

=> dhcp
k3-navss-ringacc ringacc@2b800000: Ring Accelerator probed rings:286, gp-rings[96,32] sci-dev-id:195
k3-navss-ringacc ringacc@2b800000: dma-ring-reset-quirk: enabled
am65_cpsw_nuss_port ethernet@46000000port@1: K3 CPSW: rflow_id_base: 2
ethernet@46000000port@1 Waiting for PHY auto negotiation to complete......... TIMEOUT !
am65_cpsw_nuss_port ethernet@46000000port@1: phy_startup failed
am65_cpsw_nuss_port ethernet@46000000port@1: am65_cpsw_start end error
=>

Hi,

We tested a ping test in the following way:

Our custom board running VxWorks pinged an evaluation AM65x running Linux. We used ethtools to view packet statistics. I am attaching the statistics before the ping test, after the ping test, and another ping test. From VxWorks, we observe that "1 packets transmitted, 0 received, 100% packet loss, time 1016 ms". Do you have any insight?

NIC statistics:
     p0_rx_good_frames: 46
     p0_rx_broadcast_frames: 11
     p0_rx_multicast_frames: 35
     p0_rx_crc_errors: 0
     p0_rx_oversized_frames: 0
     p0_rx_undersized_frames: 0
     p0_ale_drop: 0
     p0_ale_overrun_drop: 0
     p0_rx_octets: 8452
     p0_tx_good_frames: 0
     p0_tx_broadcast_frames: 0
     p0_tx_multicast_frames: 0
     p0_tx_octets: 0
     p0_tx_64B_frames: 0
     p0_tx_65_to_127B_frames: 22
     p0_tx_128_to_255B_frames: 10
     p0_tx_256_to_511B_frames: 14
     p0_tx_512_to_1023B_frames: 0
     p0_tx_1024B_frames: 0
     p0_net_octets: 8452
     p0_rx_bottom_fifo_drop: 0
     p0_rx_port_mask_drop: 0
     p0_rx_top_fifo_drop: 0
     p0_ale_rate_limit_drop: 0
     p0_ale_vid_ingress_drop: 0
     p0_ale_da_eq_sa_drop: 0
     p0_ale_block_drop: 0
     p0_ale_secure_drop: 0
     p0_ale_auth_drop: 0
     p0_ale_unknown_ucast: 0
     p0_ale_unknown_ucast_bytes: 0
     p0_ale_unknown_mcast: 0
     p0_ale_unknown_mcast_bytes: 0
     p0_ale_unknown_bcast: 0
     p0_ale_unknown_bcast_bytes: 0
     p0_ale_pol_match: 0
     p0_ale_pol_match_red: 0
     p0_ale_pol_match_yellow: 0
     p0_ale_mcast_sa_drop: 0
     p0_ale_dual_vlan_drop: 0
     p0_ale_len_err_drop: 0
     p0_ale_ip_next_hdr_drop: 0
     p0_ale_ipv4_frag_drop: 0
     p0_tx_mem_protect_err: 0
     p0_tx_pri0: 0
     p0_tx_pri1: 0
     p0_tx_pri2: 0
     p0_tx_pri3: 0
     p0_tx_pri4: 0
     p0_tx_pri5: 0
     p0_tx_pri6: 0
     p0_tx_pri7: 0
     p0_tx_pri0_bcnt: 0
     p0_tx_pri1_bcnt: 0
     p0_tx_pri2_bcnt: 0
     p0_tx_pri3_bcnt: 0
     p0_tx_pri4_bcnt: 0
     p0_tx_pri5_bcnt: 0
     p0_tx_pri6_bcnt: 0
     p0_tx_pri7_bcnt: 0
     p0_tx_pri0_drop: 0
     p0_tx_pri1_drop: 0
     p0_tx_pri2_drop: 0
     p0_tx_pri3_drop: 0
     p0_tx_pri4_drop: 0
     p0_tx_pri5_drop: 0
     p0_tx_pri6_drop: 0
     p0_tx_pri7_drop: 0
     p0_tx_pri0_drop_bcnt: 0
     p0_tx_pri1_drop_bcnt: 0
     p0_tx_pri2_drop_bcnt: 0
     p0_tx_pri3_drop_bcnt: 0
     p0_tx_pri4_drop_bcnt: 0
     p0_tx_pri5_drop_bcnt: 0
     p0_tx_pri6_drop_bcnt: 0
     p0_tx_pri7_drop_bcnt: 0
     rx_good_frames: 0
     rx_broadcast_frames: 0
     rx_multicast_frames: 0
     rx_pause_frames: 0
     rx_crc_errors: 0
     rx_align_code_errors: 0
     rx_oversized_frames: 0
     rx_jabber_frames: 0
     rx_undersized_frames: 0
     rx_fragments: 0
     ale_drop: 0
     ale_overrun_drop: 0
     rx_octets: 0
     tx_good_frames: 46
     tx_broadcast_frames: 11
     tx_multicast_frames: 35
     tx_pause_frames: 0
     tx_deferred_frames: 0
     tx_collision_frames: 0
     tx_single_coll_frames: 0
     tx_mult_coll_frames: 0
     tx_excessive_collisions: 0
     tx_late_collisions: 0
     rx_ipg_error: 0
     tx_carrier_sense_errors: 0
     tx_octets: 8452
     tx_64B_frames: 0
     tx_65_to_127B_frames: 22
     tx_128_to_255B_frames: 10
     tx_256_to_511B_frames: 14
     tx_512_to_1023B_frames: 0
     tx_1024B_frames: 0
     net_octets: 8452
     rx_bottom_fifo_drop: 0
     rx_port_mask_drop: 0
     rx_top_fifo_drop: 0
     ale_rate_limit_drop: 0
     ale_vid_ingress_drop: 0
     ale_da_eq_sa_drop: 0
     ale_block_drop: 0
     ale_secure_drop: 0
     ale_auth_drop: 0
     ale_unknown_ucast: 0
     ale_unknown_ucast_bytes: 0
     ale_unknown_mcast: 0
     ale_unknown_mcast_bytes: 0
     ale_unknown_bcast: 0
     ale_unknown_bcast_bytes: 0
     ale_pol_match: 0
     ale_pol_match_red: 0
     ale_pol_match_yellow: 0
     ale_mcast_sa_drop: 0
     ale_dual_vlan_drop: 0
     ale_len_err_drop: 0
     ale_ip_next_hdr_drop: 0
     ale_ipv4_frag_drop: 0
     iet_rx_assembly_err: 0
     iet_rx_assembly_ok: 0
     iet_rx_smd_err: 0
     iet_rx_frag: 0
     iet_tx_hold: 0
     iet_tx_frag: 0
     tx_mem_protect_err: 0
     tx_pri0: 46
     tx_pri1: 0
     tx_pri2: 0
     tx_pri3: 0
     tx_pri4: 0
     tx_pri5: 0
     tx_pri6: 0
     tx_pri7: 0
     tx_pri0_bcnt: 8452
     tx_pri1_bcnt: 0
     tx_pri2_bcnt: 0
     tx_pri3_bcnt: 0
     tx_pri4_bcnt: 0
     tx_pri5_bcnt: 0
     tx_pri6_bcnt: 0
     tx_pri7_bcnt: 0
     tx_pri0_drop: 0
     tx_pri1_drop: 0
     tx_pri2_drop: 0
     tx_pri3_drop: 0
     tx_pri4_drop: 0
     tx_pri5_drop: 0
     tx_pri6_drop: 0
     tx_pri7_drop: 0
     tx_pri0_drop_bcnt: 0
     tx_pri1_drop_bcnt: 0
     tx_pri2_drop_bcnt: 0
     tx_pri3_drop_bcnt: 0
     tx_pri4_drop_bcnt: 0
     tx_pri5_drop_bcnt: 0
     tx_pri6_drop_bcnt: 0
     tx_pri7_drop_bcnt: 0
root@am65xx-evm:~#

NIC statistics:
     p0_rx_good_frames: 45
     p0_rx_broadcast_frames: 10
     p0_rx_multicast_frames: 35
     p0_rx_crc_errors: 0
     p0_rx_oversized_frames: 0
     p0_rx_undersized_frames: 0
     p0_ale_drop: 0
     p0_ale_overrun_drop: 0
     p0_rx_octets: 8114
     p0_tx_good_frames: 0
     p0_tx_broadcast_frames: 0
     p0_tx_multicast_frames: 0
     p0_tx_octets: 0
     p0_tx_64B_frames: 0
     p0_tx_65_to_127B_frames: 22
     p0_tx_128_to_255B_frames: 10
     p0_tx_256_to_511B_frames: 13
     p0_tx_512_to_1023B_frames: 0
     p0_tx_1024B_frames: 0
     p0_net_octets: 8114
     p0_rx_bottom_fifo_drop: 0
     p0_rx_port_mask_drop: 0
     p0_rx_top_fifo_drop: 0
     p0_ale_rate_limit_drop: 0
     p0_ale_vid_ingress_drop: 0
     p0_ale_da_eq_sa_drop: 0
     p0_ale_block_drop: 0
     p0_ale_secure_drop: 0
     p0_ale_auth_drop: 0
     p0_ale_unknown_ucast: 0
     p0_ale_unknown_ucast_bytes: 0
     p0_ale_unknown_mcast: 0
     p0_ale_unknown_mcast_bytes: 0
     p0_ale_unknown_bcast: 0
     p0_ale_unknown_bcast_bytes: 0
     p0_ale_pol_match: 0
     p0_ale_pol_match_red: 0
     p0_ale_pol_match_yellow: 0
     p0_ale_mcast_sa_drop: 0
     p0_ale_dual_vlan_drop: 0
     p0_ale_len_err_drop: 0
     p0_ale_ip_next_hdr_drop: 0
     p0_ale_ipv4_frag_drop: 0
     p0_tx_mem_protect_err: 0
     p0_tx_pri0: 0
     p0_tx_pri1: 0
     p0_tx_pri2: 0
     p0_tx_pri3: 0
     p0_tx_pri4: 0
     p0_tx_pri5: 0
     p0_tx_pri6: 0
     p0_tx_pri7: 0
     p0_tx_pri0_bcnt: 0
     p0_tx_pri1_bcnt: 0
     p0_tx_pri2_bcnt: 0
     p0_tx_pri3_bcnt: 0
     p0_tx_pri4_bcnt: 0
     p0_tx_pri5_bcnt: 0
     p0_tx_pri6_bcnt: 0
     p0_tx_pri7_bcnt: 0
     p0_tx_pri0_drop: 0
     p0_tx_pri1_drop: 0
     p0_tx_pri2_drop: 0
     p0_tx_pri3_drop: 0
     p0_tx_pri4_drop: 0
     p0_tx_pri5_drop: 0
     p0_tx_pri6_drop: 0
     p0_tx_pri7_drop: 0
     p0_tx_pri0_drop_bcnt: 0
     p0_tx_pri1_drop_bcnt: 0
     p0_tx_pri2_drop_bcnt: 0
     p0_tx_pri3_drop_bcnt: 0
     p0_tx_pri4_drop_bcnt: 0
     p0_tx_pri5_drop_bcnt: 0
     p0_tx_pri6_drop_bcnt: 0
     p0_tx_pri7_drop_bcnt: 0
     rx_good_frames: 0
     rx_broadcast_frames: 0
     rx_multicast_frames: 0
     rx_pause_frames: 0
     rx_crc_errors: 0
     rx_align_code_errors: 0
     rx_oversized_frames: 0
     rx_jabber_frames: 0
     rx_undersized_frames: 0
     rx_fragments: 0
     ale_drop: 0
     ale_overrun_drop: 0
     rx_octets: 0
     tx_good_frames: 45
     tx_broadcast_frames: 10
     tx_multicast_frames: 35
     tx_pause_frames: 0
     tx_deferred_frames: 0
     tx_collision_frames: 0
     tx_single_coll_frames: 0
     tx_mult_coll_frames: 0
     tx_excessive_collisions: 0
     tx_late_collisions: 0
     rx_ipg_error: 0
     tx_carrier_sense_errors: 0
     tx_octets: 8114
     tx_64B_frames: 0
     tx_65_to_127B_frames: 22
     tx_128_to_255B_frames: 10
     tx_256_to_511B_frames: 13
     tx_512_to_1023B_frames: 0
     tx_1024B_frames: 0
     net_octets: 8114
     rx_bottom_fifo_drop: 0
     rx_port_mask_drop: 0
     rx_top_fifo_drop: 0
     ale_rate_limit_drop: 0
     ale_vid_ingress_drop: 0
     ale_da_eq_sa_drop: 0
     ale_block_drop: 0
     ale_secure_drop: 0
     ale_auth_drop: 0
     ale_unknown_ucast: 0
     ale_unknown_ucast_bytes: 0
     ale_unknown_mcast: 0
     ale_unknown_mcast_bytes: 0
     ale_unknown_bcast: 0
     ale_unknown_bcast_bytes: 0
     ale_pol_match: 0
     ale_pol_match_red: 0
     ale_pol_match_yellow: 0
     ale_mcast_sa_drop: 0
     ale_dual_vlan_drop: 0
     ale_len_err_drop: 0
     ale_ip_next_hdr_drop: 0
     ale_ipv4_frag_drop: 0
     iet_rx_assembly_err: 0
     iet_rx_assembly_ok: 0
     iet_rx_smd_err: 0
     iet_rx_frag: 0
     iet_tx_hold: 0
     iet_tx_frag: 0
     tx_mem_protect_err: 0
     tx_pri0: 45
     tx_pri1: 0
     tx_pri2: 0
     tx_pri3: 0
     tx_pri4: 0
     tx_pri5: 0
     tx_pri6: 0
     tx_pri7: 0
     tx_pri0_bcnt: 8114
     tx_pri1_bcnt: 0
     tx_pri2_bcnt: 0
     tx_pri3_bcnt: 0
     tx_pri4_bcnt: 0
     tx_pri5_bcnt: 0
     tx_pri6_bcnt: 0
     tx_pri7_bcnt: 0
     tx_pri0_drop: 0
     tx_pri1_drop: 0
     tx_pri2_drop: 0
     tx_pri3_drop: 0
     tx_pri4_drop: 0
     tx_pri5_drop: 0
     tx_pri6_drop: 0
     tx_pri7_drop: 0
     tx_pri0_drop_bcnt: 0
     tx_pri1_drop_bcnt: 0
     tx_pri2_drop_bcnt: 0
     tx_pri3_drop_bcnt: 0
     tx_pri4_drop_bcnt: 0
     tx_pri5_drop_bcnt: 0
     tx_pri6_drop_bcnt: 0
     tx_pri7_drop_bcnt: 0
root@am65xx-evm:~#

NIC statistics:
     p0_rx_good_frames: 57
     p0_rx_broadcast_frames: 20
     p0_rx_multicast_frames: 37
     p0_rx_crc_errors: 0
     p0_rx_oversized_frames: 0
     p0_rx_undersized_frames: 0
     p0_ale_drop: 0
     p0_ale_overrun_drop: 0
     p0_rx_octets: 11642
     p0_tx_good_frames: 0
     p0_tx_broadcast_frames: 0
     p0_tx_multicast_frames: 0
     p0_tx_octets: 0
     p0_tx_64B_frames: 0
     p0_tx_65_to_127B_frames: 24
     p0_tx_128_to_255B_frames: 10
     p0_tx_256_to_511B_frames: 23
     p0_tx_512_to_1023B_frames: 0
     p0_tx_1024B_frames: 0
     p0_net_octets: 11642
     p0_rx_bottom_fifo_drop: 0
     p0_rx_port_mask_drop: 0
     p0_rx_top_fifo_drop: 0
     p0_ale_rate_limit_drop: 0
     p0_ale_vid_ingress_drop: 0
     p0_ale_da_eq_sa_drop: 0
     p0_ale_block_drop: 0
     p0_ale_secure_drop: 0
     p0_ale_auth_drop: 0
     p0_ale_unknown_ucast: 0
     p0_ale_unknown_ucast_bytes: 0
     p0_ale_unknown_mcast: 0
     p0_ale_unknown_mcast_bytes: 0
     p0_ale_unknown_bcast: 0
     p0_ale_unknown_bcast_bytes: 0
     p0_ale_pol_match: 0
     p0_ale_pol_match_red: 0
     p0_ale_pol_match_yellow: 0
     p0_ale_mcast_sa_drop: 0
     p0_ale_dual_vlan_drop: 0
     p0_ale_len_err_drop: 0
     p0_ale_ip_next_hdr_drop: 0
     p0_ale_ipv4_frag_drop: 0
     p0_tx_mem_protect_err: 0
     p0_tx_pri0: 0
     p0_tx_pri1: 0
     p0_tx_pri2: 0
     p0_tx_pri3: 0
     p0_tx_pri4: 0
     p0_tx_pri5: 0
     p0_tx_pri6: 0
     p0_tx_pri7: 0
     p0_tx_pri0_bcnt: 0
     p0_tx_pri1_bcnt: 0
     p0_tx_pri2_bcnt: 0
     p0_tx_pri3_bcnt: 0
     p0_tx_pri4_bcnt: 0
     p0_tx_pri5_bcnt: 0
     p0_tx_pri6_bcnt: 0
     p0_tx_pri7_bcnt: 0
     p0_tx_pri0_drop: 0
     p0_tx_pri1_drop: 0
     p0_tx_pri2_drop: 0
     p0_tx_pri3_drop: 0
     p0_tx_pri4_drop: 0
     p0_tx_pri5_drop: 0
     p0_tx_pri6_drop: 0
     p0_tx_pri7_drop: 0
     p0_tx_pri0_drop_bcnt: 0
     p0_tx_pri1_drop_bcnt: 0
     p0_tx_pri2_drop_bcnt: 0
     p0_tx_pri3_drop_bcnt: 0
     p0_tx_pri4_drop_bcnt: 0
     p0_tx_pri5_drop_bcnt: 0
     p0_tx_pri6_drop_bcnt: 0
     p0_tx_pri7_drop_bcnt: 0
     rx_good_frames: 0
     rx_broadcast_frames: 0
     rx_multicast_frames: 0
     rx_pause_frames: 0
     rx_crc_errors: 0
     rx_align_code_errors: 0
     rx_oversized_frames: 0
     rx_jabber_frames: 0
     rx_undersized_frames: 0
     rx_fragments: 0
     ale_drop: 0
     ale_overrun_drop: 0
     rx_octets: 0
     tx_good_frames: 57
     tx_broadcast_frames: 20
     tx_multicast_frames: 37
     tx_pause_frames: 0
     tx_deferred_frames: 0
     tx_collision_frames: 0
     tx_single_coll_frames: 0
     tx_mult_coll_frames: 0
     tx_excessive_collisions: 0
     tx_late_collisions: 0
     rx_ipg_error: 0
     tx_carrier_sense_errors: 0
     tx_octets: 11642
     tx_64B_frames: 0
     tx_65_to_127B_frames: 24
     tx_128_to_255B_frames: 10
     tx_256_to_511B_frames: 23
     tx_512_to_1023B_frames: 0
     tx_1024B_frames: 0
     net_octets: 11642
     rx_bottom_fifo_drop: 0
     rx_port_mask_drop: 0
     rx_top_fifo_drop: 0
     ale_rate_limit_drop: 0
     ale_vid_ingress_drop: 0
     ale_da_eq_sa_drop: 0
     ale_block_drop: 0
     ale_secure_drop: 0
     ale_auth_drop: 0
     ale_unknown_ucast: 0
     ale_unknown_ucast_bytes: 0
     ale_unknown_mcast: 0
     ale_unknown_mcast_bytes: 0
     ale_unknown_bcast: 0
     ale_unknown_bcast_bytes: 0
     ale_pol_match: 0
     ale_pol_match_red: 0
     ale_pol_match_yellow: 0
     ale_mcast_sa_drop: 0
     ale_dual_vlan_drop: 0
     ale_len_err_drop: 0
     ale_ip_next_hdr_drop: 0
     ale_ipv4_frag_drop: 0
     iet_rx_assembly_err: 0
     iet_rx_assembly_ok: 0
     iet_rx_smd_err: 0
     iet_rx_frag: 0
     iet_tx_hold: 0
     iet_tx_frag: 0
     tx_mem_protect_err: 0
     tx_pri0: 57
     tx_pri1: 0
     tx_pri2: 0
     tx_pri3: 0
     tx_pri4: 0
     tx_pri5: 0
     tx_pri6: 0
     tx_pri7: 0
     tx_pri0_bcnt: 11642
     tx_pri1_bcnt: 0
     tx_pri2_bcnt: 0
     tx_pri3_bcnt: 0
     tx_pri4_bcnt: 0
     tx_pri5_bcnt: 0
     tx_pri6_bcnt: 0
     tx_pri7_bcnt: 0
     tx_pri0_drop: 0
     tx_pri1_drop: 0
     tx_pri2_drop: 0
     tx_pri3_drop: 0
     tx_pri4_drop: 0
     tx_pri5_drop: 0
     tx_pri6_drop: 0
     tx_pri7_drop: 0
     tx_pri0_drop_bcnt: 0
     tx_pri1_drop_bcnt: 0
     tx_pri2_drop_bcnt: 0
     tx_pri3_drop_bcnt: 0
     tx_pri4_drop_bcnt: 0
     tx_pri5_drop_bcnt: 0
     tx_pri6_drop_bcnt: 0
     tx_pri7_drop_bcnt: 0
root@am65xx-evm:~#

Hi Akm,

Schuyler is out of office this week. In the meantime, what I'm understanding from these results is that no ethernet frames are received by the AM65x EVM as the below RX statistics counters remain 0 for all ping tests you shared. 

rx_good_frames: 0
rx_broadcast_frames: 0
rx_multicast_frames: 0
rx_pause_frames: 0
rx_crc_errors: 0
rx_align_code_errors: 0
rx_oversized_frames: 0
rx_jabber_frames: 0
rx_undersized_frames: 0
rx_fragments: 0

>>>From VxWorks, we observe that "1 packets transmitted, 0 received, 100% packet loss, time 1016 ms"

Based on this information, ping on VxWorks appears to be reporting that 1 packet is transferred, but I'm not sure that really means an ethernet frame actually got transmitted out to the cable (could just be software reporting it has) - transmitted out of the MAC interface --> PHY --> physical port --> the cable. 

I'm not sure if you have a way to directly read memory in VxWorks? If so, could you try reading the following registers as a start to confirm if ethernet frames are actually being transmitted out of the MAC?

• 0003A000h CPSW_STAT0_RXGOODFRAMES Ethernet Port N Total Number of Good Frames Received 4603 A000h
  • md.l 0x3A000
• 0003A034h CPSW_STAT0_TXGOODFRAMES Ethernet Port N Good Transmit Frames Register
  • md.l 0x3A034

-Daolin

Hi, 

I have run an ifconfig command on both the custom and development boards. I have noticed cpsw0 is in a tentative state on the custom board, and automatic in the development board. The ethernet link is also running on the dev board, but not the custom board. Do you have any clue as to what is causing this, and how to change the state of the link?

-> ifconfig
lo0     Link type:Local loopback
        inet 127.0.0.1  mask 255.255.255.255
        inet6 unicast fe80::1%lo0  prefixlen 64  automatic
        inet6 unicast ::1  prefixlen 128
        UP RUNNING LOOPBACK MULTICAST NOARP ALLMULTI
        MTU:1500  metric:1  VR:0  ifindex:1
        RX packets:19 mcast:0 errors:0 dropped:0
        TX packets:19 mcast:0 errors:0
        collisions:0 unsupported proto:0
        RX bytes:1428  TX bytes:1428

cpsw0   Link type:Ethernet  HWaddr 34:08:e1:5b:cc:b7
        capabilities: VLAN_MTU
        inet 10.10.61.100  mask 255.255.255.0  broadcast 10.10.61.255
        inet6 unicast fe80::3608:e1ff:fe5b:ccb7%cpsw0  prefixlen 64  tentative  automatic
        UP SIMPLEX BROADCAST MULTICAST
        MTU:1500  metric:1  VR:0  ifindex:2
        RX packets:0 mcast:0 errors:0 dropped:0
        TX packets:0 mcast:0 errors:0
        collisions:0 unsupported proto:0
        RX bytes:0  TX bytes:0

value = 0 = 0x0
->

-> ifconfig
lo0     Link type:Local loopback
        inet 127.0.0.1  mask 255.255.255.255
        inet6 unicast fe80::1%lo0  prefixlen 64  automatic
        inet6 unicast ::1  prefixlen 128
        UP RUNNING LOOPBACK MULTICAST NOARP ALLMULTI
        MTU:1500  metric:1  VR:0  ifindex:1
        RX packets:19 mcast:0 errors:0 dropped:0
        TX packets:19 mcast:0 errors:0
        collisions:0 unsupported proto:0
        RX bytes:1428  TX bytes:1428

cpsw0   Link type:Ethernet  HWaddr 34:08:e1:70:a3:fd
        capabilities: VLAN_MTU
        inet 10.10.61.223  mask 255.255.255.0  broadcast 10.10.61.255
        inet6 unicast fe80::3608:e1ff:fe70:a3fd%cpsw0  prefixlen 64  automatic
        UP RUNNING SIMPLEX BROADCAST MULTICAST
        MTU:1500  metric:1  VR:0  ifindex:2
        RX packets:0 mcast:0 errors:0 dropped:0
        TX packets:7 mcast:5 errors:0
        collisions:0 unsupported proto:0
        RX bytes:0  TX bytes:832

value = 0 = 0x0
->

Hi,

From what I am able to research quickly this is a higher level protocol flag used by DHCP servers. I am not able to find exact examples but the ones I am seeing can be summarized as the IP address received from the DHCP server is tentative or not confirmed. It may be an indication that the DHCP server thinks there is a duplicate IP address on the network which might come from a duplicate MAC addresses or served an IP address that was not recently renewed. This might mean a crowded network.  There maybe other reasons as well.

Best Regards,

Schuyler