AM625: tispl download u-boot

Hi,

Could you please attach the full console sequence? 

Is this a custom board or a TI EVM?

What was the default block size that tftp was using?

Best Regards,

Schuyler

Hello Schuyler,

Thanks for your response,

This is a custom board.

Below is our config related to Block size

CONFIG_IP_DEFRAG=y
CONFIG_NET_MAXDEFRAG=65535
CONFIG_TFTP_BLOCKSIZE=65535

and timeout is down from 10s to 1s

#define TIMEOUT 1000UL

We attach the full console: 

02000000011a0000616d3632780000000000000048535345010001000100010002a6000002000200d68ecb2c055dff11ade95bd927e837d2a53bc23b0a2800cebce4f106bcf309df2213912d77a157a8b7c2df40672a06a918034aa4c7d603e462481475225d49b839109fc8da497caaca402cdb8566ccee2e94a6514077f4253513d2c9eabf277294ba87b257ba58d8bff4fb1797d5e6b6d2c6df8c07a210045e4ad37505f5be34e7f9a0180a54b90a2841c73f268690ad53a4a3a5be07c9e2dcb2e2cb90896a42C
U-Boot R5 SPL 2021.01-00015-gaa48999c6a (Oct 14 2024 - 10:02:03 +0700)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.5--v09.00.05 (Kool Koala)')
Switching: UART -> ETH RMII boot...
SPL initial stack usage: 13424 bytes
Trying to boot from eth device
eth0: ethernet@8000000port@1
ethernet@8000000port@1 PHY link status . is up(done)
ethernet@8000000port@1:100BASE-T1 100 Mbit/s
link up on port 1, speed 100, full duplex
Using ethernet@8000000port@1 device
TFTP from server 192.168.1.20; our IP address is 192.168.1.2
Filename 'tispl.bin'.
Load address: 0x82000000
Loading: #################
         1.6 MiB/s
done
Bytes transferred = 869192 (d4348 hex)
Authenticating image at address 0x9e780000
Authenticating image of size 49897 bytes
Authentication passed
Authenticating image at address 0x9e800000
Authenticating image of size 442065 bytes
Authentication passed
Authenticating image at address 0x89000000
Authenticating image of size 151589 bytes
Authentication passed
Authenticating image at address 0x80080000
Authenticating image of size 203721 bytes
Authentication passed
Authenticating image at address 0x800b1580
Authenticating image of size 20555 bytes
Authentication passed
init_env from device 4 not supported!
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.8(release):v2.8-226-g2fcd408bb3-dirty
NOTICE:  BL31: Built : 00:42:57, Jan 13 2023

U-Boot A53 SPL 2021.01-00015-gaa48999c6a (Oct 14 2024 - 10:01:54 +0700)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.5--v09.00.05 (Kool Koala)')
Trying to boot from eth device
eth0: ethernet@8000000port@1
ethernet@8000000port@1 PHY link status  is up(done)
ethernet@8000000port@1:100BASE-T1 100 Mbit/s
link up on port 1, speed 100, full duplex
Using ethernet@8000000port@1 device
TFTP from server 192.168.1.20; our IP address is 192.168.1.2
Filename 'u-boot.img'.
Load address: 0x82000000
Loading: T ##############
         93.8 KiB/s
done
Bytes transferred = 668712 (a3428 hex)
Authenticating image at address 0x80800000
Authenticating image of size 634353 bytes
Authentication passed
Authenticating image at address 0x8089a780
Authenticating image of size 33358 bytes
Authentication passed


U-Boot 2021.01-00015-gaa48999c6a (Oct 14 2024 - 10:01:54 +0700)

SoC:   AM62X SR1.0 HS-SE
Model: Texas Instruments AM625 SK
DRAM:  512 MiB
MMC:
Error, wrong i2c adapter 0 max 0 possible
In:    serial@2800000
Out:   serial@2800000
Err:   serial@2800000
Net:   eth0: ethernet@8000000port@1
Hit any key to stop autoboot:  0
jedec_spi_nor flash@0: Issue 0xB7, This changes CFR2V[7] to 1 (4-byte addr mode)
CFR5N: 40 40
CFR4N: a8 a8
CFR3N: 08 00
CFR2N: 88 88
CFR1N: 00 04
STR1N: 00 00
The hybrid sector is already enabled (CFR3N[3]=0) of die-2
Already setting top 4KB (CFR1N[2]=1) of die-2
params->page_size:512
CFR3V: 18 10
non_uniform---> done
CFR3V: 38 30---> done
The 1rst die is already in DDR mode!!!
The 2nd die is already in DDR mode!!!
SF: Detected s28hs02gt with page size 512 Bytes, erase size 256 KiB, total 256 MiB
ethernet@8000000port@1 PHY link status  is up(done)
ethernet@8000000port@1:100BASE-T1 100 Mbit/s
link up on port 1, speed 100, full duplex
Using ethernet@8000000port@1 device
TFTP from server 192.168.1.20; our IP address is 192.168.1.2
Filename 'debrick.scr'.
Load address: 0x80000000
Loading: #
         834 KiB/s
done
Bytes transferred = 3419 (d5b hex)
## Executing script at 80000000

Thanks.

Cong.

I'd like to add more info:

Package capture from WireShark show that there are 2 timeout with Read Request package.

the time between 2 data packet is not greater than downloading of tispl.

Why the average speed is much smaller than? Does it calculate all the time that include ARP packet?

Thanks,

Cong.

Hi,

Could you please attach individual wireshark captures of the downloads for tiboot3.bin, tispi.bin and u-boot.img. We do not see the timeouts that you are experiencing. This possibly could be a DHCP server issue.

Best Regards,

Schuyler

Hello Schuyler,

Thanks for your response,

I cannot upload file here, so please see the attached file on the email.

Thanks.

Cong.

Could you please provide your email or guide me how to upload file here. It is *.pcapng file.

Hello Cong,

Could you please zip/compress the *.pcapng file and try to re-upload it here?

Regards,
Krithika

Download_Uboot.zip

Hello Schuyler, Krithika,

Zip file is put here.

Please help us check.

Thanks,

Cong.

What is your network architecture or topology. Is there a DHCP server? 192.168.1.20 is the TFTP server, 192.168.1.2 is the AM625? A Linux server running TFTP server connected in a dedicated LAN to the AM625 device? Or is it connected using some enterprise network?

Looking at the packet capture in wireshark couple things jump out.

1. TFTP looks to be using 512 byte frames, could there be some setting in the TFTP server limiting to such small MTU? I would have expected ~1500 bytes. This is probably minor.

2. At the very beginning it looks like it takes 30s or so to get a ARP response. 192.168.1.20 is looking for 192.168.1.0 (default gateway) but does not get a response for a long time. Then loading tispl to 192.168.1.2 begins. This points to some issue with default gateway settings?

3. Just from the wireshark the bandwidth of loading tispl.bin looks to be (start at 66.872 seconds into capture, end at 67.403) 0.53 seconds. While the u-boot.img is (start 73.334, end at 76.231) is 2.9 seconds. File sizes are 869kB and 666kB so bandwidth should be around 1.6MB/s and 0.23MB/s. This does not match your screenshot printout of 2.2MB/s and 44kB/s? Are those bandwidth calculated by your SW? Wireshark shows bandwidth delta of 6-7x not 50x.

4. Based on the item 3 it looks like loading u-boot.img image acknowledging each TFTP frame takes 3-5x as long as each frame of tispl.bin. Is the TFTP client software, cache settings and memory map identical?

  Pekka

Pekka Varis said:

1. TFTP looks to be using 512 byte frames, could there be some setting in the TFTP server limiting to such small MTU? I would have expected ~1500 bytes. This is probably minor.

Ok, looks like 512 bytes is the TFTP default, so that explains it.

Hello Pekka,

Thanks for your analysis.
I am following this ticket, and I will be answer the question below.

Is there a DHCP server?
=> No
192.168.1.20 is the TFTP server, 192.168.1.2 is the AM625?
=> Yes
A Linux server running TFTP server connected in a dedicated LAN to the AM625 device? Or is it connected using some enterprise network?
=> No, Personal computer with OS Windows10 running TFTP server connected in a LAN to the AM625 device. below is my configure TFTP server.

2. I tried configure static IP without default IP, the speed at which it downloads data does not change, so i think it is not the cause of slowness.

3. Log from SW and Wireshark get at the same time.
Bandwidth is calculated in SW which is the default code in the kernel.

The way to calculate bandwidth in SW is when SW is ready to receive data, and the way to calculate in wireshark is when data between TFTP server has received a request to send data, so these two values ​​cannot be compared.

I got some new information when debugging inside the kernel and noticed that initially there was no data available.

this is where i put log in kernel

I observed the two logs simultaneously, and found that these two points were at the same time.

From here we can see that the cause lies in the initialization process and connection to the TFTP server.

I attach the log here 6428.Log_debug.zip

Regards,

Huy

huy khuat said:

From here we can see that the cause lies in the initialization process and connection to the TFTP server.

I'd tend to agree. It looks like there is 5 seconds of trying to figure out IP addresses when loading u-boot.img. Your screenshot has that 5s (starts at around 32s from the capture start), where nothing is transferred but the Windows machine and the board being loaded send ARP messages to figure out which MAC address has which IP (looks like Windows is sending at least three ARPs, messages 3408, 3409, 3410 one second apart). In the loading of tispl.bin at the very beginning there is no multiple ARP messages. So if you include this 5s of nothing going because the TFTP server and the board asking for the image have not completed ARP on in the bandwidth calculation that could explain the lower throughput.

Your debug print log seems to be in the Ethernet driver printing the Ethertype, 0x800 is IPv4, 0x806 is ARP. So it is probably message 3412, which Wireshark says is ARP from Windows to the AM62x.

What are you using for the packet capture / wireshark? Do you have a network tap like https://www.profitap.com/profishark-1g/ or are you using Wireshark in the Windows machine?

Are you able to run a Linux machine as the TFTP server, I'm not familiar with Windows networking stack and what could be causing multiple ARP messages. 

  Pekka

Hello Pekka,

We do not have a network tap, we are using Wireshark in the Windows machine

Additional information: We use this Media Converter to convert from standard ethernet to Automotive ethernet.

I attached the zip file that included log file and pcap file when we run a Linux machine as TFTP server.

Please help me check

Download_Uboot_Ubuntu_0412.zip

Thanks.

Cong.

From all three wireshark logs, one screenshot at the beginning and then the two from the zip files (one Windows, one Linux) there looks to be a repeating pattern. Loading of tispl.bin, which happens with the boot rom seems to be fine. Sequence is ARP request sent as broadcast from the TI device (beginning of the MAC address 28:B5:e8, OUI registered to TI), response from 192.168.1.20, then the download starts. tispl.bin is loaded quick. Then the second image download (u-boot.bin) using TFTP with probably SPL running has 4-10s of ARP messages before addressing is figured out and download starts. See messages arounf number 3406 in both logs. Once it starts the speed is fine (maybe 2s to download). This MAC and IP address sorting out is why the downloading of u-boot.img appears slow. The logs also have a third file being downloaded where there does not seem to be any addressing issues but the TFTP server says no such file.

So the issue is sorting out the interaction of the networking stack and ARP resolution/cache in SPL software, media converter, and the TFTP server. What could explain this is some hacks on MAC address, or some dropped Ethernet frames. In the Windows packet capture, the MAC address of the TFTP server seems to be the Gopel Electronic (OUI is 00:06:81), in the Ubuntu one it is an unregistered one (OUI is b6:c3:97). What might fit here is that the SPL misses the ARP response (no 3406 in Ubuntu log), something (the adapter? PHY configuration?) drops the frame. Note the wireshark you capture is from the TFTP server, so shows what leaves and arrives there, not what makes it to the TI device.

3405	44.230910243	28:b5:e8:cd:57:95	Broadcast	ARP	60	Who has 192.168.1.20? Tell 192.168.1.2
3406	44.230930572	b6:c3:97:fe:e3:f3	28:b5:e8:cd:57:95	ARP	42	192.168.1.20 is at b6:c3:97:fe:e3:f3
3407	48.091626906	b6:c3:97:fe:e3:f3	28:b5:e8:cd:57:95	ARP	42	Who has 192.168.1.2? Tell 192.168.1.20
3408	49.115611308	b6:c3:97:fe:e3:f3	28:b5:e8:cd:57:95	ARP	42	Who has 192.168.1.2? Tell 192.168.1.20
3409	49.231214758	28:b5:e8:cd:57:95	Broadcast	ARP	60	Who has 192.168.1.20? Tell 192.168.1.2
3410	49.231232546	b6:c3:97:fe:e3:f3	28:b5:e8:cd:57:95	ARP	42	192.168.1.20 is at b6:c3:97:fe:e3:f3
3411	50.139626816	b6:c3:97:fe:e3:f3	28:b5:e8:cd:57:95	ARP	42	Who has 192.168.1.2? Tell 192.168.1.20
3412	50.139890824	28:b5:e8:cd:57:95	b6:c3:97:fe:e3:f3	ARP	60	192.168.1.2 is at 28:b5:e8:cd:57:95
3413	54.232190870	28:b5:e8:cd:57:95	Broadcast	ARP	60	Who has 192.168.1.20? Tell 192.168.1.2
3414	54.232311369	b6:c3:97:fe:e3:f3	28:b5:e8:cd:57:95	ARP	42	192.168.1.20 is at b6:c3:97:fe:e3:f3
3415	54.232538042	192.168.1.2	192.168.1.20	TFTP	71	Read Request, File: u-boot.img, Transfer type: octet, timeout=1

So need is to sort out the ARP traffic or possible dropped frames after tispl.bin was loaded, when loading u-boot.img is requested.

  Pekka