AM625: tispl download u-boot

Hi Huy,

Download time is not affected by the device type. I don't have a GP device on an EVM at the moment, only HS/FS ones, so I am not able to test a GP build. I will work finding one here to test with.

Best Regards,

Schuyler

Hi Huy,

I did a comparison between the 8.6 SDK and the 9.1 we had been using here. There is a significant difference between the versions in the tftpboot process. There have two releases of the U-Boot since the 2021 release and there is a very much improved tftp performance. Here are some results of the comparison:

• 8.6
  • Used the base SDK eth boot config
  • Takes over 38 seconds to just load u-boot
  • Losing over 10 seconds just getting an ip address ack from the EVM
    • Between both tispl.bin download and the u-boot.img was a delay of 5-6 seconds.
  • Losing several seconds to tftp timeouts due to (assuming) missed packet reception.   
• 9.1
  • Used the base SDK eth boot config
  • Takes a little 13 seconds to load the u-boot images
    • the biggest delay here is the time u-boot spends performing the auto-negotiation setup of the PHY, about 5 seconds for each download of the tispl.bin and u-boot.img images.
  • The IP address assigning process is taking around a second, not 5-6 like the 8.6
  • Not seeing any packet timeouts with the limited test runs that I did. (this is where the T shows up during the tftp packer reception.)

The two SDK version tests were done using the same Ubuntu PC and TI EVM on an isolated network, they were directly connected to each other.

I need to highlight that a big part of this depends on how the tftp server reacts. Here the Ubuntu server was reliable. Therefore we recommend to achieve the improved performance upgrading to the latest U-boot.

Best Regards,

Schuyler

Hello TI expert,

Updating to sdk 9.x is risky for us because we need to update other related drivers.
So can you create a backport that changes from SDK 9.x to 8.6 ?

Thanks and Best Regards,

Huy

Huy Khuat said:

after fixing the timeout of spl.bin to reduce the timeout of 4 faulty frames, but it has slowed down the loading of kernel image at uboot,
so is there a way to both reduce the loading time of u-boot at tispl.bin, and not affect the loading of kernel image at u-boot?

Hello Huy, You can build tispl.bin and u-boot.img with the modified timeout value which is reducing the timeout of 4 faulty frames, use tispl.bin built from that change. After that undo those changes and use u-boot.img built without changes which will not affect the loading of kernel image at u-boot.

Hello  Chintan, 

I just fixed the timeout in SBL and it didn't improve download time,

and it seems that the first 4 bad frames make the tftp server respond slowly and it affects uboot downloading other files, so it improves in sbl but in uboot it is slow, so there is no improvement from this timeout adjustment workround, the best solution is still to solve the first 4 frames all as 0x0.

i want you guys to check if the first 4 frames received by spl are all 0x0?
because i checked on dev-kit and on our custom board, there is no reason that printing log can affect this, and on your wireshark log there is also a point when requesting IP from devkit 2 times and the board has no response, this proves that the board did not receive the frames, or it skipped because of wrong data, this coincides with the first frame being 0x0 when i put the log in.
i hope you guys can find the cause of this.

The image below is your log, the red circled area is the abnormal point.

Thanks,

Huy

Hello Huy, Can you share following details here:

1. DHCP configuration file that you are using to provide IP address to the DUT connected

2. Link speed between the system and DUT.

3. Is there any connection exist other than DUT and System you are using?

Regards,

Chintan.

Hello Chintan,

I share for you information below:

1. This DHCP configuration file dhcpd.zip

2. The speed of ETH we are setting is 100Mbps.

3. No, The system I'm using has only host PC(ubuntu 18.4) via USB to ETH connection to dev-kit-EVM.

Any questions let me know.

Thanks,

Huy

Hello Huy, The speed may be the reason that you are having a low throughput while transferring the file. Also it can cause timeout during DHCP request and response. Can you please try 1000Mbps and see whether issue is still there or not ?

Hello Chintan,

Our custom board using is PHY TJA1101B, it only support 100 Mbit/s. so change up 1000Mbps no effect with our

and we compare between tiboot3.bin loading tispl.bin and tispl.bin loading u-boot.img. tispl.bin load u-boot.img much slower with tiboot3.bin load tispl.bin.

We have printf debug log on the dev-kit and our custom board, both 4 frame firt is 0x0.

On our custom board hard static IP. So the board does not need to ask DHCP to provide IP and it will request to load the file immediately. but the first 4 frames are still 0x0, and that's what causes the 4s timeout. 

Can you focus on the first 4 frames and fix them?

Thanks,

Huy

Hello Huy, Can you provide full logs, and also ".config" files of both stages (i.e. R5 and A53 ) ?

Regards,

Chintan.

Hello Chintan, 

Log dev-kit: /cfs-file/__key/communityserver-discussions-components-files/791/test_5F00_devkit28_5F00_2_5F00_25.zip

Log custom board: /cfs-file/__key/communityserver-discussions-components-files/791/12.17.24_5F00_2.zip

Config file dev-kit i using default of SDK

Config file custom board: 

You can review other Logs in the comments section above this article.

Thanks,

Huy

Hello Chintan, 

I sent the wrong config, I will resend it here

Config file custom board: config_custom_2.zip

Thanks,

Huy

Hello Huy, Thank you for providing the config files, but I want generated config files which will be result after building the image. If you are following the same steps to build the image as we follow it will be in "/output_folder/r5/.config" and "/output_folder/a53/.config".

Regards,

Chintan.

Hello Chintan, 

Image configs file after building here.config_custom_3.zip

Thanks,

Huy

Hello Huy, Thank you for providing these files. I have gone through previous responses. I have few thing that you should try:

-> Can you please make TFTPBLOCKSIZE value to be 1468 instead of 65535 in config file, also you can use am62x_evm_a53_ethboot_defconfig from the latest releases.

-> Timeout value to be 5000UL instead of 1000UL. Based on your previous logs, I can see that there is timeout happening during transferring "u-boot.img".

-> Try to clear dhcplease files to avoid getting  ARP requests which is unnecessary in your case due to static IP assignment.

-> Last thing: try booting via ethernet with the same image on TI AM62 board with 1000Mbps speed, since 100Mbps is 10 times lower than what we follow, which can lead to timeout. Although in your logs I can see speed to be 1000, not sure whether that is correct one or not.

Regards,

Chintan.

Hello Chintan,

I send for you log of custom board here:  log.14_4_2025.zip

after trying to change timeout to 5 and value TFTPBLOCKSIZE  = 1468 

And I see no change of improving download times.

On the dev-kit, I sorry about mistake speed. We tried speed 1000Mbps, and the first 4 frames are still 0x0.

Thanks, Huy

Hello Huy,

I have few doubts after I saw the logs provided by you:

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

Why is it showing ETH RMII boot while we support Ethernet boot on AM62x with RGMII port 1, as described in the documentation here: https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/latest/exports/docs/linux/Foundational_Components/U-Boot/UG-Network-K3.html

Also I am confused with the logs provided by you, in the wireshark logs I am not able to find the packets with Ethertype 0x0, although it is seen in the debug prints.

Regards,

Chintan.

Hello Chintan,

"Why is it showing ETH RMII boot while we support Ethernet boot on AM62x with RGMII port 1, as described in the documentation here:"

=> TI has specifically designed for us to support ETH boot on AM62x with RMII port 1, We are currently using RMII boot on our custom board.

"Also I am confused with the logs provided by you, in the wireshark logs I am not able to find the packets with Ethertype 0x0, although it is seen in the debug prints."

=> You cannot see it in Wireshark because these are the first 4 frames that are received, not sent to the server.
Therefore, to see that the first 4 frames are 0x0, you need to add a log print in the source code when receiving the frames.
As for the analysis in Wireshark, please look at the frames I've highlighted in red.
When the server queried the MAC address of IP 192.168.1.2, it did not receive a response from the AM62x board until the 5th ARP request(highlighted in blue)
This matches the logs I previously printed out.

You should read this thread again to understand this problem clearly.

Thanks Huy

Hello Huy,

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index f40ee1b28bc..5aefabb2a78 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -141,7 +141,7 @@ struct am65_cpsw_priv {
 #ifdef PKTBUFSRX
 #define UDMA_RX_DESC_NUM PKTBUFSRX
 #else
-#define UDMA_RX_DESC_NUM 4
+#define UDMA_RX_DESC_NUM 1
 #endif
 
 #define mac_hi(mac)    (((mac)[0] << 0) | ((mac)[1] << 8) |    \

Can you please try this change in am65-cpsw-nuss.c driver and see whether the frames with EtherType 0x0 is reducing to 1 or not ?

Regards,

Chintan.

Hello Chintan,

I tried change as your patch. and it still has 4 frames = 0x0. I send you log below

17_4_2025.zip

Thanks, Huy

Hello Chintan,

I change follow your patch. and update all value of UDMA_RX_DESC_NUM =1

I see some differences compared to before.

highlighted read reducing to 2 no response from board

17_4_2025_2.zip

Thanks Huy

Hello Huy,

I am working on why we are not getting any response from the board when requested by the server. With the following change did you see the same four frames as Ethertype 0x0, or is it reduced to one faulty frame(Ethertype 0x0) ?

Regards,

Chintan.

Hello Chintan,

I see one faulty frame with Ethertype 0x0. 

17_4_2025_3.zip

Thanks, Huy

Hello Huy,

You can make below changes instead of changing "UDMA_RX_DESC_NUM" to 1, it will drain all packets inside RX buffers, and you won't see any faulty frames.

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index 9b69f36d04d..ba26c861e3f 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -494,7 +494,12 @@ static int am65_cpsw_send(struct udevice *dev, void *packet, int length)
       struct am65_cpsw_priv *priv = dev_get_priv(dev);
       struct am65_cpsw_common *common = priv->cpsw_common;
       struct ti_udma_drv_packet_data packet_data;
-      int ret;
+      uchar drain_rx_buffers[1530];
+      int ret = 0;
+
+      /* Drain existing packets */
+      while (ret==0)
+              ret = dma_receive(&common->dma_rx, (void **)&drain_rx_buffers, NULL);

       if (!common->started)
               return -ENETDOWN; 

Regards,

Chintan.

Hello Chintan,

I tried change as your patch. have 2 frame = 0x0.

17_4_2025_4.zip

Thanks, Huy

and I using Uboot of TI-SDK 8.6, this am65_cpsw_send() function seems different from the one you are using.

Hello Huy,

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index f40ee1b28bc..8ee6105b0a6 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -438,13 +438,26 @@ out:
        return ret;
 }
 
+static int am65_cpsw_free_pkt(struct udevice *dev, uchar *packet, int length);
+
 static int am65_cpsw_send(struct udevice *dev, void *packet, int length)
 {
        struct am65_cpsw_priv *priv = dev_get_priv(dev);
        struct am65_cpsw_common *common = priv->cpsw_common;
        struct ti_udma_drv_packet_data packet_data;
+       uchar drain_rx_buffers[1530];
        int ret;
 
+       /* Drain existing packets. In the presence of packets, the
+        * pkt_length is returned. When there are no packets, 'zero'
+        * is returned.
+        */
+       ret = dma_receive(&common->dma_rx, (void **)&drain_rx_buffers, NULL);
+       while (ret > 0) {
+               ret = am65_cpsw_free_pkt(dev, drain_rx_buffers, ret);
+               ret = dma_receive(&common->dma_rx, (void **)&drain_rx_buffers, NULL);
+       }
+
        packet_data.pkt_type = AM65_CPSW_CPPI_PKT_TYPE;
        packet_data.dest_tag = priv->port_id;
        ret = dma_send(&common->dma_tx, packet, length, &packet_data); 

Here is a diff based on SDK 8.6.

Regards,

Chintan.

Hello Chintan,

I tried your patch, and I still see zero frames,

please check  detail of log attached below :

4_22_2025.zip

Thanks, Huy

Hello Huy,

Can you please try adding the following to both R5 and A53 defconfig files for Ethernet Boot?

CONFIG_SYS_RX_ETH_BUFFER=64

Hello, Siddharth

I tried your CONFIG_SYS_RX_ETH_BUFFER=64 configuration to both R5 and A53 defconfig files,

It  is still zero frames

Please check  detail of log attached below :

4_23_2025.zip

Thanks,

Huy

Hello Huy,

Since there are still 4 'zero frames' and given that updating UDMA_RX_DESC_NUM to 1 had reduced the number of 'zero frames' to 1, it seems to me that setting CONFIG_SYS_RX_ETH_BUFFER=64 did not take effect. It should effectively result in the following section of the am65-cpsw-nuss.c driver being exercised:
#ifdef PKTBUFSRX
#define UDMA_RX_DESC_NUM PKTBUFSRX
and CONFIG_SYS_RX_ETH_BUFFER is used to set the value of PKTBUFSRX in:
include/net-common.h
which has:
#define PKTBUFSRX  CONFIG_SYS_RX_ETH_BUFFER

Alternatively, could you please try changing UDMA_RX_DESC_NUM to 64 similar to the change made earlier when it was set to 1? Please let me know if you start seeing 64 'zero frames' as a result of this. I am wondering if packets are being overwritten or if the issue lies elsewhere.

Regards,
Siddharth.

Hello Siddharth,

I Configured UDMA_RX_DESC_NUM to 64, it is failed to boot up. 

Thanks,

Huy

Hello Huy,

Please revert UDMA_RX_DESC_NUM back to 4 and apply the following diff:

@@ -460,9 +473,13 @@ static int am65_cpsw_recv(struct udevice *dev, int flags, uchar **packetp)
 {
        struct am65_cpsw_priv *priv = dev_get_priv(dev);
        struct am65_cpsw_common *common = priv->cpsw_common;
+       int ret;
 
        /* try to receive a new packet */
-       return dma_receive(&common->dma_rx, (void **)packetp, NULL);
+       ret = dma_receive(&common->dma_rx, (void **)packetp, NULL);
+       if (!ret)
+               return -ENODATA;
+       return ret;
 }
 
 static int am65_cpsw_free_pkt(struct udevice *dev, uchar *packet, int length)

Hello Siddharth,

I tried your patch and I send you log below:

4_23_2025_2.zip

Thanks,

Huy

Hello Huy,

Please test the following diff:

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index f40ee1b28bc..4f03f6c26ec 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -282,6 +282,8 @@ static void am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv *priv,
                        mode, reg);
 }
 
+static int am65_cpsw_free_pkt(struct udevice *dev, uchar *packet, int length);
+
 static int am65_cpsw_start(struct udevice *dev)
 {
        struct eth_pdata *pdata = dev_get_platdata(dev);
@@ -290,6 +292,7 @@ static int am65_cpsw_start(struct udevice *dev)
        struct am65_cpsw_port *port = &common->ports[priv->port_id];
        struct am65_cpsw_port *port0 = &common->ports[0];
        struct ti_udma_drv_chan_cfg_data *dma_rx_cfg_data;
+       uchar drain_rx_buffers[1530];
        int ret, i;
 
        ret = power_domain_on(&common->pwrdmn);
@@ -338,6 +341,12 @@ static int am65_cpsw_start(struct udevice *dev)
                goto err_dis_tx;
        }
 
+       ret = dma_receive(&common->dma_rx, (void **)&drain_rx_buffers, NULL);
+       while (ret > 0) {
+               ret = am65_cpsw_free_pkt(dev, drain_rx_buffers, ret);
+               ret = dma_receive(&common->dma_rx, (void **)&drain_rx_buffers, NULL);
+       }
+
        /* Control register */
        writel(AM65_CPSW_CTL_REG_P0_ENABLE |
               AM65_CPSW_CTL_REG_P0_TX_CRC_REMOVE |

Hello Siddharth,

I have sent you the log below. Please check it

4_24_2025.zip

Thanks,

Huy

Hello Huy,

Can you please enable DEBUG logs in net/net.c and net/tftp.c for tispl.bin and share the logs?

Regards,
Siddharth.

Hello Siddharth,

I enabled DEBUG logs in net/net.c by adding #define DEBUG_NET_PKT 1, and in net/tftp.c by replacing debug() with printf().

Here is full logs below:

4_24_2025_2.zip

Thanks,

Huy

Hello Siddharth,

Do you have any update on this issue?

Thanks,

Huy

Hello Huy,

Can you please try the following diff and share the logs corresponding to it? The following diff moves the section for draining packets within am65_cpsw_start() function to a place after the Host Port has been configured and enabled and also after the RX Flow ID has been programmed:

diff --git a/drivers/net/ti/am65-cpsw-nuss.c b/drivers/net/ti/am65-cpsw-nuss.c
index f40ee1b28bc..0d57dd7e82e 100644
--- a/drivers/net/ti/am65-cpsw-nuss.c
+++ b/drivers/net/ti/am65-cpsw-nuss.c
@@ -282,6 +282,8 @@ static void am65_cpsw_gmii_sel_k3(struct am65_cpsw_priv *priv,
 			mode, reg);
 }
 
+static int am65_cpsw_free_pkt(struct udevice *dev, uchar *packet, int length);
+
 static int am65_cpsw_start(struct udevice *dev)
 {
 	struct eth_pdata *pdata = dev_get_platdata(dev);
@@ -290,6 +292,7 @@ static int am65_cpsw_start(struct udevice *dev)
 	struct am65_cpsw_port *port = &common->ports[priv->port_id];
 	struct am65_cpsw_port *port0 = &common->ports[0];
 	struct ti_udma_drv_chan_cfg_data *dma_rx_cfg_data;
+	uchar drain_rx_buffers[1530];
 	int ret, i;
 
 	ret = power_domain_on(&common->pwrdmn);
@@ -373,6 +376,13 @@ static int am65_cpsw_start(struct udevice *dev)
 	writel(AM65_CPSW_ALE_DEFTHREAD_EN,
 	       common->ale_base + AM65_CPSW_ALE_THREADMAPDEF_REG);
 
+	ret = dma_receive(&common->dma_rx, (void **)&drain_rx_buffers, NULL);
+	while (ret > 0) {
+		dev_err(dev, "draining packet\n");
+		ret = am65_cpsw_free_pkt(dev, drain_rx_buffers, ret);
+		ret = dma_receive(&common->dma_rx, (void **)&drain_rx_buffers, NULL);
+	}
+
 	/* PORT x configuration */
 
 	/* Port x Max length register */

Regards,
Siddharth.

Hello Siddharth,

I don't see any major changes.

Please see log below:

5_12_2025.zip

Thanks,

Huy

Hello Huy,

Can you try enabling CONFIG_KEEP_SERVERADDR?

Regards,
Siddharth.

Hello Siddharth,

I enabled CONFIG_KEEP_SERVERADDR,

Here is the log of it: 5_13_2025.zip

Thanks,

Huy

Hello Huy,

In include/net.h, can you increase the value of ETH_PACKETS_BATCH_RECV from 32 to 36? This change will help us find out if the 4 0x0 packets being received are the ones from the previous transaction when eth_rx() was invoked. With this change, please check and let me know if you still see the 4 0x0 packets.

Regards,
Siddharth.

Hello Siddharth,

I still see the 4 0x0 packets.

Do you need full log?

Thanks,

Huy

Hello Huy,

Thank you for testing it out and sharing the logs. Can you please test the following diff?

diff --git a/net/tftp.c b/net/tftp.c
index 6fdb1a821a8..cc998ee203e 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -879,6 +879,9 @@ void tftp_start(enum proto_t protocol)
        tftp_tsize_num_hash = 0;
 #endif
 
+       /* Drain existing packets */
+       eth_rx();
+
        tftp_send();
 }

The above diff will let us know if the 0x0 frames are seen in response to tftp_send() packets or they were received before tftp started.

Regards,
Siddharth.

Hello Siddharth,

Here is its log.

Thanks,

Huy