AM625: Ethernet Backup Boot Mode

I should have mentioned that I used the am62x_evm_r5_ethboot_defconfig & am62x_evm_a53_ethboot_defconfig with the change to use Micrel Phys.

I also modified the DTS/DTSI file to set the phy-mode=rmii and the phy addresses to be 1 & 3 as per our board wiring.

Hello Neil,

The subject owner is out of office for the next couple of days. Feel free to ping the thread if you have not received a response by the middle of next week.

Regards,

Nick

Neil Wilson said:

On power up I can see the initial TFTP for tiboot.bin work and the SPL executes.

So tiboot3.bin is loaded successfully, and once u-boot runs BOOTP broadcasts do not work? I'm also assuming the Ethernet ports works fine if you booted in some other manner. 

Can you attach a wireshark packet capture of the traffic? Either wireshark, tcpdump or better yet a wire tap like Profishark. All the way from the beginning showing the successful tiboot3.bin loading.

What SW are you using as your DHCP and BOOTP server?

  Pekka

Hi Pekka,

Thanks. Ethernet works fine if I boot from SD or eMMC.

I'm using a standard Ubuntu DHCP/BOOTP installation.

I'll attach the Wireshark capture when I work out how to do so on the forum.

Hi Pekka,

PCAP attached.

5460.AM62x-tftp1.pcapng.zip

Thanks, so your server is IP address 10.0.0.1, MAC address c8:a3:62:2c:3d:8c . The AM625 is IP address 10.0.0.5, MAC address 04:25:e8:3d:9d:15
On quick look the ROM part is fine loading tiboot3.bin without any issues:

Once this completes in about a second, no frames for 5 seconds, at six seconds c8:a3:62:2c:3d:8c sends ARP requests to ask where is IP address 10.0.0.5

At the very beginning c8:a3:62:2c:3d:8c gave 04:25:e8:3d:9d:15 the IP address 10.0.0.5 but six seconds later frame 1215 it is sending out ARP requests asking for who has 10.0.0.5 (copied below) even though the previous frame it just sent to 10.0.0.5.

1215 6.011378538 c8:a3:62:2c:3d:8c Broadcast ARP 42 Who has 10.0.0.5? Tell 10.0.0.1

I do not see the BOOTP messages from 04:25:e8:3d:9d:15, so not clear why the Ubuntu machine would be trying to send something to 10.0.0.5. But then again it should have the MAC address already, so why would it send ARP requests.

How did you capture the pcap? I'm thinking some frames are not being shown? Other thing to check is MAC address 04:25:e8:3d:9d:15 is a TI OUI number (used by ROM), are you reprogramming the MAC address with your own on the AM625 in u-boot?

 Pekka

 04:25:e8 is a TI OUI and we are not reprogramming the address.

I assume the server is ARPing as the last TFTP packet was not acked by the ROM code.

I would focus on what is going on after frame 1214, all seems fine up to there, including the final frame being delivered. I agree there is no ack in the capture for the very last frame, which seems weird. The console printout looks like u-boot was still able to start. Is it always the case you don't see and ack to the final frame. That ack from ROM should go out before u-boot starts. So somehow before the ack goes out the tiboot3.bin is authenticated and runs including PHY auto negotiation in a way which prevents any Ethernet from working (including the ack sent by ROM before tiboot3.bin even started to run).

Is the capture with a wiretap or from the Ubuntu machine using tcpdump?

Are there any error counters in the interface?

  Pekka

Packet capture was from Wireshark on the server.

I do not see and ack from the AM62 for the last TFTP packet after multiple power cycles.

There are no Ethernet error counts showing for that interface.

The tiboot3.bin file you load over Ethernet, is it exactly the same file you use in the SD card boot? One theory is that it is not the right version, if signature verification fails it might look like nothing happens.

  Pekka

It's not exactly the same as the defconfig used to generate it is am62x_evm_r5_ethboot_defconfig

The SD card boot uses am62x_evm_r5_defconfig to produce it's tiboot3.bin

Why is the last TFTP data packet not acknowledged is I guess the first thing that goes wrong. After the data packet is sent by the TFTP server there does not seem to be any Ethernet frames. This would be good the verify with a network wire tap like Profishark.

The tiboot3.bin file does seem quite large >1200 data packets sized ~500Bytes, so around 600kB. I checked a tiboot3.bin I'm using with AM62x and it looks like ~290kB. I'm wondering if that is causing some issue and not fitting in where boot ROM is placing it. Can you confirm the tiboot3.bin is around this size?

Last angle is RMII vs RGMII, on the TI EVMs we always have RGMII based PHY's (RMII is verified using special limited volume boards) so there would have to be something unique to RMII and boot ROM that somehow shows up as no ack to the last data packet.

Neil Wilson said:

U-Boot SPL 2024.04-00002-gbaa288e477f-dirty (Mar 27 2025 - 09:38:30 +0000)

Can you confirm this printout is from the files you generated and had to have come over TFTP? So would have to be in the tiboot3.bin file for which no acknowledgement was sent?

The expert assigned to this area will be back Monday, so expect a few days of delay as she ramps up on this.

  Pekka

Hi Pekka,

tiboot3.bin is approx 309KB

ll /tftpboot/tiboot3.bin
-rw-rw-r-- 1 neil neil 309342 Mar 28 13:26 /tftpboot/tiboot3.bin

The file (I rebuilt it) today contains that string:

strings /tftpboot/tiboot3.bin | rg dirty
U-Boot SPL 2024.04-00002-gbaa288e477f-dirty (Mar 28 2025 - 13:26:11 +0000)

RMII is listed as one of the backup ethernet boot modes in the AM62x TRM.

Thanks.

Neil

Hi, any update on this problem please?

Thanks

Hello Neil,

Neil Wilson said:

I'm using a standard Ubuntu DHCP/BOOTP installation.

Which TFTP server are you using (e.g. xinetd, tftp-hpa etc)?

Can you please share what your isc-dhcp-server /etc/dhcp/dhcpd.conf file contains? Specifically, I want to check if you have entered the correct vendor-class-identifiers for each U-boot binary.

Neil Wilson said:

I have created the 3 files needed files from ti-u-boot-2024.04 and copied them to my DHCP/TFP server which is connected to the AM62 via a USB Ethernet port i.e. a dedicated port.

Additionally, can you clarify if this was tested using SDK 10.1? Were you able to test Ethernet boot to be working on the AM62x TI EVM?

-Daolin

Hi Daolin,

1. I am using xinetd

2. DHCP config is below, however I don't see the BOOTP on the Ethernet output : 

subnet 10.0.0.0 netmask 255.0.0.0
{
range dynamic-bootp 10.0.0.2 10.0.0.16;
if substring (option vendor-class-identifier, 0, 16) = "TI K3 Bootp Boot"
{
filename "tiboot3.bin";
} elsif substring (option vendor-class-identifier, 0, 24) = "AM62X U-Boot R5 SPL"
{
filename "tispl.bin";
} elsif substring (option vendor-class-identifier, 0, 25) = "AM62X U-Boot A53 SPL"
{
filename "u-boot.img";
}

range 10.0.0.17 10.0.0.25;
default-lease-time 60000;
max-lease-time 720000;
next-server 10.0.0.1;
}

3. I am currently using SDK version 10.0.07.04 

4. I saw Ethernet boot as the primary boot working using the SK-AM62-LP EVM

This issue I am seeing now on our own kit is for Ethernet backup boot.

Regards

Neil

Hi Neil,

Thanks for sharing these details.

There doesn't seem to be any specific issues with your dhcp configuration that I notice. 

Can you also share what the contents of your "am62x_evm_r5_ethboot_defconfig" and "am62x_evm_a53_ethboot_defconfig" are?

Neil Wilson said:

This issue I am seeing now on our own kit is for Ethernet backup boot.

You mention this issue is observed when Ethernet is used as backup boot for your custom board, do you see the same issue when Ethernet is used for the primary boot mode?

-Daolin

Hi Daolin,

The defconfigs are attached - I use the evm as a base.

I see the same behaviour with the board configured for Ethernet as the primary boot mode.

Regards

Neil

8080.Archive.zip

I will be trying another board where I can get to the boot mode resistors a bit more easily.

As I am out for the office for the next week my response will be delayed.

Hi Neil,

I have two suggestions:

1. Change the DHCP config vendor-class-identifier from "24" to "19" for the "AM62X U-Boot R5 SPL" string and "25" to "20" for the "AM62X U-Boot A53 SPL" string, similar to the below DHCP config.

2. Increase the range of the IP addresses listed in the DHCP config, you can use the below DHCP config as a reference.

subnet 192.168.0.0 netmask 255.255.255.0
{
range dynamic-bootp 192.168.0.2 192.168.0.30;
if substring (option vendor-class-identifier, 0, 16) = "TI K3 Bootp Boot"
{
filename "tiboot3.bin";
} elsif substring (option vendor-class-identifier, 0, 19) = "AM69 U-Boot R5 SPL"
{
filename "tispl.bin";
} elsif substring (option vendor-class-identifier, 0, 20) = "AM69 U-Boot A72 SPL"
{
filename "u-boot.img";
}
range 192.168.0.31 192.168.0.63;
default-lease-time 60000;
max-lease-time 30;
next-server 192.168.0.1;
}

Additionally, can you share the exact part number inscribed on the AM625 chip? I want to check if this is a GP or HS-FS part.

-Daolin

Hi Daolin,

AM6232A SCGHAALW 45P053S

Hi Neil,

Neil Wilson said:

AM6232A SCGHAALW 45P053S

Thanks for sharing so quickly, this appears to be an HS-FS part. When you built the U-boot binaries (tiboot3.bin, tispl.bin, u-boot.img) did you make sure to use the hs-fs version rather than the gp version?

Daolin Qiu said:

1. Change the DHCP config vendor-class-identifier from "24" to "19" for the "AM62X U-Boot R5 SPL" string and "25" to "20" for the "AM62X U-Boot A53 SPL" string, similar to the below DHCP config.

2. Increase the range of the IP addresses listed in the DHCP config, you can use the below DHCP config as a reference.

When you get the chance, please let me know if this changes the issue you are observing.

-Daolin

Hi Daolin,

I apologise for the delay in answering this was due to vacations in the UK.

Changes as suggested above for the DHCP config did not cause any different behaviour.

I managed to modify the boot resistors on our board to have Ethernet as the primary boot mode, I see the same behaviour as backup boot mode.

I reverted the DHCP config change and re-verified that the SK-AM62-LP eval board could boot correctly with my DHCP/TFTP servers.

Are you able to confirm if TI has been able to use RMII as the phy type for either primary or back up boot mode with the AM62x ?

Regards

Neil

Hi Neil,

Neil Wilson said:

Are you able to confirm if TI has been able to use RMII as the phy type for either primary or back up boot mode with the AM62x ?

Although Ethernet boot with RMII is listed as a boot option from the TRM, to my knowledge, I don't think we have specifically tested RMII Ethernet boot as our AM62x SK-EVMs are all by default using RGMII interface mode. 

Neil Wilson said:

I reverted the DHCP config change and re-verified that the SK-AM62-LP eval board could boot correctly with my DHCP/TFTP servers.

As I understand, SK-AM62-LP is using RGMII by default. 

Pekka Varis said:

I do not see the BOOTP messages from 04:25:e8:3d:9d:15

Neil Wilson said:

U-Boot SPL 2024.04-00002-gbaa288e477f-dirty (Mar 27 2025 - 09:38:30 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
SPL initial stack usage: 13392 bytes
Trying to boot from eth device
ethernet@8000000port@1 connected to Micrel KSZ804 mode rmii
eth0: ethernet@8000000port@1
ethernet@8000000port@1 Waiting for PHY auto negotiation to complete..... done
link up on port 1, speed 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10
BOOTP broadcast 11
BOOTP broadcast 12
BOOTP broadcast 13
BOOTP broadcast 14
BOOTP broadcast 15
BOOTP broadcast 16
BOOTP broadcast 17

Retry time exceeded; starting again
udma_stop_mem2dev: peer not stopped TIMEOUT !
Problem booting with BOOTP
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

Looking back at your Wireshark capture and your console log, I'm seeing that your board looks to be sending BOOTP requests but the Wireshark doesn't show these requests being received on the host PC side. Have you been able to test your RMII interface with a regular transmission test? I.e. no Ethernet boot, just fully boot up your device, connect via Ethernet to Host, and do a ping or iperf test (if using Linux) and see if there are no corrupted received packets on the Host? You can check this with "ethtool -S <interface name" on the Host if the Host is a Linux PC.

-Daolin

Hello Neil,

I can see from the logs that your board is not able to get an IP address from DHCP server. Can you please keep your DHCP configuration as original one and clear all the entries from dhcp.leases file which has blocked the IP addresses which were assigned before, then restart your DHCP server and try again. If you don't want to clear dhcp.leases file, you can update the line "range dynamic-bootp 10.0.0.2 10.0.0.16" to "range dynamic-bootp 10.0.0.2 10.0.0.60", restart your DHCP server again and try to boot, also to avoid this issue in future update "max-lease-time" value to some lower value, I keep "10" for my DHCP server.

Regards,

Chintan.

When I boot the board from an SD card into u-boot or Linux I can use the ethernet interface with no problems.

SSH, TFTP etc all work as expected.

It is only the boot modes in RMII where I see these issues.

Hi Chintan, it is not that the DHCP is failing, the BOOTP packets are not being generated on ethernet.

The TFTP access of tiboot3.bin works fine from ROM, but e subsequent BOOTP to access tispl.bin does not get transmitted.

Hello Neil,
Ethernet works fine in SD boot since CPSW is not enabled during SPL stage for SD boot, but we need CPSW to be initialized during SPL stage if we want to boot via Ethernet.

Regards,
Chintan.

Hello Neil,

For downloading tispl.bin after tiboot3.bin is executed successfully, we need to get IP address again from the DHCP server and that's why board is requesting for IP address to the server. In wireshark logs we can see that server is broadcasting "who has 192.168.0.5" which was acquired by board during it was fetching tiboot3.bin file and not released since then, also I am doubting that all of the IP address in the range provided by you is acquired and not release, and that's why BOOTP request is not served by DHCP server. Can you please give a try to what I asked ?

Regards,
Chintan.

Hi Chintan, that made no difference.

I don't believe the issue is with the servers.

I think the ARP from the server is because the last TFTP data packet is not being acked by the ROM code.

This makes the server think the client has gone away and it is trying to locate it again.

tiboot3 output:

U-Boot SPL 2024.04-00002-gbaa288e477f-dirty (Mar 28 2025 - 16:05:56 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
Trying to boot from eth device
ethernet@8000000port@1 connected to Generic PHY mode rmii
eth0: ethernet@8000000port@1
ethernet@8000000port@1 Waiting for PHY auto negotiation to complete.... done
link up on port 1, speed 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10

Hello Neil,

Can you please provide following files as a zip:

1) Your DHCP configuration file: dhcpd.conf

2) Your DHCP leases file: dhcpd.leases

Regards,

Chintan.

3757.Archive.zip

Hi Chintan, attached zipfile. Thanks

Hi Neil,

Thanks for sharing the attached files. Chintan is out of office for the next week so I'll be supporting this issue. 

I took a look at Wireshark and console log of a working Ethernet boot (using RGMII) as a comparison to the Wireshark and console log of what you shared. 

1. Your AM625 board is failing to bind to a DHCP assigned address. See below console log as a comparison of what is expected after the "BOOTP broadcast" messages

eth0: ethernet@8000000port@1
ethernet@8000000port@1 Waiting for PHY auto negotiation to complete....... done
link up on port 1, speed 1000, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
DHCP client bound to address 172.168.1.170 (1760 ms)
Using ethernet@8000000port@1 device
TFTP from server 172.168.1.1; our IP address is 172.168.1.170

2. It looks like what is expected to appear after the last packet of tiboot3.bin are the DHCP packets to acquire an IP address for your AM625 board according to what I see from a working Ethernet boot Wireshark capture (below). 

Can you share what the status of isc-dhcp-server is after the issue occurs (after last packet of tiboot3.bin)? You can use "systemctl status isc-dhcp-server".

-Daolin

Hi Daolin,

The problem is not that the DHCP request is failing but that the BOOTP packet is not being transmitted on RMII.

It is seen on the console trace but not seen on Wireshark.

I keep asking - have TI proved that the RMII boot mode works correctly with the AM62X ROM ?

I feel that we keep going around the same question regarding the server response/configuration without answering why the initial TFTP of tiboot3.bin does not get acknowledged for the last data packet from the server and why the BOOTP frames are not getting transmitted.

Regards

Neil

Neil Wilson said:

I keep asking - have TI proved that the RMII boot mode works correctly with the AM62X ROM ?

RMII is tested but because it is not used in any evaluation board it is not tested in regular nightly tests or SDK releases. But from your logs we can see the ROM part is done, tiboot3.bin is loaded using RMII. The issues are post ROM, when that image (tiboot3.bin) starts to run. At this stage the software on AM625 is not reusing anything the ROM code did.

  Pekka

Hi Neil,

Neil Wilson said:

I feel that we keep going around the same question regarding the server response/configuration without answering why the initial TFTP of tiboot3.bin does not get acknowledged for the last data packet from the server and why the BOOTP frames are not getting transmitted.

As I indicated in my last response, from looking at a working Ethernet Boot Wireshark capture, when the console is showing "BOOTP broadcast" messages, the Wireshark shows DHCP packets. I observed that BOOTP packets show on Wireshark only prior to loading the tiboot3.bin. Afterwards, prior to loading tispl.bin, the BOOTP requests from the DUT does not show up (even on a working Ethernet Boot Wireshark capture). Instead, based on observation, DHCP packets should be seen on Wireshark to obtain an IP address on the DUT. See below for an example working Ethernet Boot Wireshark capture. 

Additionally, I observe that even on the working example, there is no TFTP acknowledgement of the final data packet of tiboot3.bin.

Working Ethernet Boot Wireshark capture: https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/am62x_5F00_working_5F00_eth_5F00_boot.pcapng

-Daolin

I found one hardware issue with the phy reset from power up - our circuit was not implementing the recommended method, I have fixed that now.

I confirm that the ROM + RMII is working because tiboot3.bin is being loaded and executed.

What should I look for regarding the failure to transmit any packets from tiboot3.bin?

I put some debug prints in the SPL and can see that am65_cpsw_send and udma_send are being called.

The data looks plausible:

ff ff ff ff ff ff 04 25 e8 3d 9d 0b 08 00 45 00 01 78 00 00 40 00 ff 11 7a 75 00 00 00 00 ff ff ff ff 00 44 00 43 01 64 00 00 01 01 06 00 e8 3d a4 f6 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 25 e8 3d 9d 0b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 63 82 53 63 3c 13 41 4d 36 32 58 20 55 2d 42 6f 6f 74 20 52 35 20 53 50 4c 01 04 00 00 00 00 03 04 00 00 00 00 06 04 00 00 00 00 0c 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 11 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff 

What should I look for to help debug why no transmission happens?

Thank you.

Hi Neil,

Daolin Qiu said:

Can you share what the status of isc-dhcp-server is after the issue occurs (after last packet of tiboot3.bin)? You can use "systemctl status isc-dhcp-server".

Based on comparison with a working Ethernet boot Wireshark capture and boot log, it appears that an IP address needs to be obtained prior to send tispl.bin packets. From your Wireshark log and console log, it doesn't look like an IP address has been assigned to your board. We first want to make sure your DHCP server on your host PC is working properly. If you are using isc-dhcp-server, can you check "systemctl status isc-dhcp-server"?

-Daolin

Hi Daolin,

systemctl status isc-dhcp-server
● isc-dhcp-server.service - ISC DHCP IPv4 server
Loaded: loaded (/lib/systemd/system/isc-dhcp-server.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2025-05-06 09:14:41 BST; 1min 19s ago
Docs: man:dhcpd(8)
Main PID: 2712 (dhcpd)
Tasks: 4 (limit: 76506)
Memory: 4.6M
CPU: 23ms
CGroup: /system.slice/isc-dhcp-server.service
└─2712 dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf enxc8a3622c3d8c

May 06 09:14:41 caprica dhcpd[2712]: Wrote 0 leases to leases file.
May 06 09:14:41 caprica dhcpd[2712]: Listening on LPF/enxc8a3622c3d8c/c8:a3:62:2c:3d:8c/10.0.0.0/8
May 06 09:14:41 caprica sh[2712]: Listening on LPF/enxc8a3622c3d8c/c8:a3:62:2c:3d:8c/10.0.0.0/8
May 06 09:14:41 caprica sh[2712]: Sending on LPF/enxc8a3622c3d8c/c8:a3:62:2c:3d:8c/10.0.0.0/8
May 06 09:14:41 caprica sh[2712]: Sending on Socket/fallback/fallback-net
May 06 09:14:41 caprica dhcpd[2712]: Sending on LPF/enxc8a3622c3d8c/c8:a3:62:2c:3d:8c/10.0.0.0/8
May 06 09:14:41 caprica dhcpd[2712]: Sending on Socket/fallback/fallback-net
May 06 09:14:41 caprica dhcpd[2712]: Server starting service.
May 06 09:15:12 caprica dhcpd[2712]: BOOTREQUEST from 04:25:e8:3d:9d:0b via enxc8a3622c3d8c
May 06 09:15:12 caprica dhcpd[2712]: BOOTREPLY on 10.0.0.2 to 04:25:e8:3d:9d:0b via enxc8a3622c3d8c

I also ran journalctl -fu isc-dhcp-server -fu xinetd while rebooting the board:

May 06 09:14:42 caprica xinetd[2756]: Reading included configuration file: /etc/xinetd.d/discard-udp [file=/etc/xinetd.d/discard-udp] [line=25]
May 06 09:14:42 caprica xinetd[2756]: Reading included configuration file: /etc/xinetd.d/echo [file=/etc/xinetd.d/echo] [line=14]
May 06 09:14:42 caprica xinetd[2756]: Reading included configuration file: /etc/xinetd.d/echo-udp [file=/etc/xinetd.d/echo-udp] [line=26]
May 06 09:14:42 caprica xinetd[2756]: Reading included configuration file: /etc/xinetd.d/servers [file=/etc/xinetd.d/servers] [line=14]
May 06 09:14:42 caprica xinetd[2756]: Reading included configuration file: /etc/xinetd.d/services [file=/etc/xinetd.d/services] [line=13]
May 06 09:14:42 caprica xinetd[2756]: Reading included configuration file: /etc/xinetd.d/tftp [file=/etc/xinetd.d/tftp] [line=13]
May 06 09:14:42 caprica xinetd[2756]: Reading included configuration file: /etc/xinetd.d/time [file=/etc/xinetd.d/time] [line=12]
May 06 09:14:42 caprica xinetd[2756]: Reading included configuration file: /etc/xinetd.d/time-udp [file=/etc/xinetd.d/time-udp] [line=28]
May 06 09:14:42 caprica xinetd[2756]: 2.3.15.3 started with libwrap loadavg labeled-networking options compiled in.
May 06 09:14:42 caprica xinetd[2756]: Started working: 1 available service
May 06 09:15:12 caprica dhcpd[2712]: BOOTREQUEST from 04:25:e8:3d:9d:0b via enxc8a3622c3d8c
May 06 09:15:12 caprica dhcpd[2712]: BOOTREPLY on 10.0.0.2 to 04:25:e8:3d:9d:0b via enxc8a3622c3d8c
May 06 09:15:12 caprica tftpd[2760]: tftpd: trying to get file: tiboot3.bin
May 06 09:15:12 caprica tftpd[2760]: tftpd: serving file from /tftpboot

As far as I can tell the DHCP is working fine, with the address being allocated for the initial TFTP of tiboot3.bin 

Regards

Neil

From what I can see the DHCP/TFTP server work fine for the transfer of tiboot3.bin - as seen on Wireshark

I then see tiboot3.bin execute, it is then supposed to load tispl.bin ?

I don not see any ethernet packets from tispl.bin exiting the board, however I added debug prints that show the packets are being created internally to the AM62X but not being transmitted.

I do not believe this to be an issue with the servers as they do not see any packets i.e. the BOOTP from tiboot3.bin

Where should I be looking for new debug to help understand why the packets are not being transmitted ?

Thank you

Hi Neil,

Neil Wilson said:

As far as I can tell the DHCP is working fine, with the address being allocated for the initial TFTP of tiboot3.bin 

Chintan Vankar said:

For downloading tispl.bin after tiboot3.bin is executed successfully, we need to get IP address again from the DHCP server and that's why board is requesting for IP address to the server.

Although an IP address is obtained prior to tiboot3.bin, for fetching tispl.bin, the IP address needs to be obtained again. From the DHCP status log I'm not seeing any DHCP requests or offers for obtaining an IP address prior to tispl.bin.

What I expect to see:

$ sudo systemctl status isc-dhcp-server
● isc-dhcp-server.service - ISC DHCP IPv4 server
    Loaded: loaded (/lib/systemd/system/isc-dhcp-server.service; enabled; vendor preset: enabled)
    Active: active (running) since Tue 2025-05-06 11:33:35 CDT; 2min 20s ago
      Docs: man:dhcpd(8)
  Main PID: 86889 (dhcpd)
     Tasks: 4 (limit: 18644)
    Memory: 4.7M
       CPU: 26ms
    CGroup: /system.slice/isc-dhcp-server.service
            └─86889 dhcpd -user dhcpd -group dhcpd -f -4 -pf /run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf enp3s0

May 06 11:35:35 a0500327ws dhcpd[86889]: DHCPOFFER on 172.168.1.170 to 1c:63:49:0f:61:14 () via enp3s0
May 06 11:35:35 a0500327ws dhcpd[86889]: reuse_lease: lease age 1026369 (secs) under 25% threshold, reply with unaltered, existing lease for 172.168.1.170
May 06 11:35:35 a0500327ws dhcpd[86889]: DHCPDISCOVER from 1c:63:49:0f:61:14 () via enp3s0
May 06 11:35:35 a0500327ws dhcpd[86889]: DHCPOFFER on 172.168.1.170 to 1c:63:49:0f:61:14 () via enp3s0
May 06 11:35:36 a0500327ws dhcpd[86889]: reuse_lease: lease age 1026370 (secs) under 25% threshold, reply with unaltered, existing lease for 172.168.1.170
May 06 11:35:36 a0500327ws dhcpd[86889]: DHCPDISCOVER from 1c:63:49:0f:61:14 () via enp3s0
May 06 11:35:36 a0500327ws dhcpd[86889]: DHCPOFFER on 172.168.1.170 to 1c:63:49:0f:61:14 () via enp3s0
May 06 11:35:36 a0500327ws dhcpd[86889]: reuse_lease: lease age 1026370 (secs) under 25% threshold, reply with unaltered, existing lease for 172.168.1.170
May 06 11:35:36 a0500327ws dhcpd[86889]: DHCPREQUEST for 172.168.1.170 (172.168.1.1) from 1c:63:49:0f:61:14 () via enp3s0
May 06 11:35:36 a0500327ws dhcpd[86889]: DHCPACK on 172.168.1.170 to 1c:63:49:0f:61:14 () via enp3s0

Daolin Qiu said:

Working Ethernet Boot Wireshark capture: am62x_working_eth_boot.pcapng

Additionally, if you take a look at the working Wireshark capture, prior to being able to TFTP tispl.bin, DHCP packets (not BOOTP) are required to obtain an IP address again. 
In this particular example, the IP address changed from 172.168.1.169 when TFTP tiboot3.bin to 172.168.1.170 when TFTP tispl.bin. 

Neil Wilson said:

I then see tiboot3.bin execute, it is then supposed to load tispl.bin ?

Neil Wilson said:

I do not believe this to be an issue with the servers as they do not see any packets i.e. the BOOTP from tiboot3.bin

From https://lore.kernel.org/all/20240112064759.1801600-1-s-vadapalli@ti.com/, tiboot3.bin is responsible for transmitting the VCI string. 
Either the tiboot3.bin is built with the incorrect VCI string (which shouldn't be the case as long as you are using the default SDK provided am62x_evm_r5_ethboot_defconfig) or the DHCP or TFTP server is not working properly.
6. "tiboot3.bin" is configured to transmit "AM62X U-Boot R5 SPL" as its
NET_VCI_STRING, thereby implying that the DHCP server and TFTP server
need to be configured to transfer "tispl.bin" to the device.
7. "tiboot3.bin" loads and executes "tispl.bin" provided by the TFTP
server.

In general, it looks like tiboot3.bin is responsible for fetching tispl.bin and should be transmitting that VCI string. 
I'm wondering if your tiboot3.bin might be built with something missing.  
Can you give this tiboot3.bin a try to see if it changes the behavior? This tiboot3.bin (built from SDK version 10.0.07.04) was working on my SK-AM62B-P1 board (with RGMII Ethernet boot).

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/791/1376.tiboot3.bin

-Daolin

"Although an IP address is obtained prior to tiboot3.bin, for fetching tispl.bin, the IP address needs to be obtained again. From the DHCP status log I'm not seeing any DHCP requests or offers for obtaining an IP address prior to tispl.bin."

I agree - because no ethernet is being transmitted from tiboot3.bin, so no DHCP address is being re-requested.

I don't know how else to phrase the question - what should I be looking for in debugging tiboot3.bin to find out why the ethernet traffic is not transmitted ?

I do not believe this problem has anything to do with the server or the VCI string - the fundamental issue is that ethernet is not being transmitted from the board when tiboot3.bin is executing.

Your tiboot3 did not work, the phy was not found - likely because I have RMII

Regards

Neil

Hi Neil,

Neil Wilson said:

I don't know how else to phrase the question - what should I be looking for in debugging tiboot3.bin to find out why the ethernet traffic is not transmitted ?

I do not believe this problem has anything to do with the server or the VCI string - the fundamental issue is that ethernet is not being transmitted from the board when tiboot3.bin is executing.

Daolin Qiu said:

Either the tiboot3.bin is built with the incorrect VCI string (which shouldn't be the case as long as you are using the default SDK provided am62x_evm_r5_ethboot_defconfig)

Could you share the defconfig you used to build your tiboot3.bin?

-Daolin

Hi Daolin,

R5 config attached.

However as there are zero ethernet packets being transmitted by the tiboot3.bin on the board then the VCI string is irrelevant.

Regards

Neil

r5_ethboot_defconfig.zip

Hi Neil,

Neil Wilson said:

However as there are zero ethernet packets being transmitted by the tiboot3.bin on the board then the VCI string is irrelevant.

I did a rough comparison between your r5 ethboot defconfig and the SDK provided am62x_evm_r5_ethboot_defconfig and it looks like there are some differences between your defconfig and the SDK provided defconfig (not counting the ones that are different due to a different PHY used and configuring for RMII instead of RGMII). Since the tiboot3.bin itself is built with the r5 ethboot defconfig, it might be worth tracing which config/combination of configs in your r5 ethboot defconfig could be causing the issue.

An idea I have (but may not be the most efficient way) is to brute force tracing which config is causing the issue by starting with the SDK provided r5 ethboot defconfig (which we know works for RGMII), apply ONLY the configs needed for your custom board (different PHY and RMII mode), leaving everything else the same and see if the issue persists. If you don't see the issue, you can try to apply each additional config, one at a time, and test to see if there is some config/combination of configs causing the issue to show up.

-Daolin

Building from ti-processor-sdk-linux-am62xx-evm-10.01.10.04 with these mods:

diff --git a/configs/am62x_evm_r5_ethboot_defconfig b/configs/am62x_evm_r5_ethboot_defconfig
index 853e5176..2719fdc4 100644
--- a/configs/am62x_evm_r5_ethboot_defconfig
+++ b/configs/am62x_evm_r5_ethboot_defconfig
@@ -14,7 +14,10 @@ CONFIG_SPL_SYSCON=y
CONFIG_DMA_CHANNELS=y
CONFIG_TI_K3_NAVSS_UDMA=y
CONFIG_DM_I2C=y
-CONFIG_PHY_TI_DP83867=y
+CONFIG_PHY_TI_DP83867=n
+CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ8XXX=y
+CONFIG_RMII=y
CONFIG_TI_AM65_CPSW_NUSS=y
CONFIG_MMC=n
CONFIG_SPL_MMC=n

diff --git a/arch/arm/dts/k3-am62x-sk-common.dtsi b/arch/arm/dts/k3-am62x-sk-common.dtsi
index 59ee4961..2351f104 100644
--- a/arch/arm/dts/k3-am62x-sk-common.dtsi
+++ b/arch/arm/dts/k3-am62x-sk-common.dtsi
@@ -478,7 +478,7 @@

&cpsw_port1 {
bootph-all;
- phy-mode = "rgmii-rxid";
+ phy-mode = "rmii";
phy-handle = <&cpsw3g_phy0>;
};

@@ -488,9 +488,9 @@
pinctrl-names = "default";
pinctrl-0 = <&main_mdio1_pins_default>;

- cpsw3g_phy0: ethernet-phy@0 {
+ cpsw3g_phy0: ethernet-phy@1 {
bootph-all;
- reg = <0>;
+ reg = <1>;
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
ti,min-output-impedance;

U-Boot SPL 2024.04-dirty (May 08 2025 - 10:18:42 +0100)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.8--v10.01.08 (Fiery Fox)')
SPL initial stack usage: 13392 bytes
Trying to boot from eth device
eth0: ethernet@8000000port@1
ethernet@8000000port@1 Waiting for PHY auto negotiation to complete.... done
link up on port 1, speed 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10
BOOTP broadcast 11
BOOTP broadcast 12
BOOTP broadcast 13
BOOTP broadcast 14
BOOTP broadcast 15
BOOTP broadcast 16
BOOTP broadcast 17

Retry time exceeded; starting again
udma_stop_mem2dev: peer not stopped TIMEOUT !
Problem booting with BOOTP
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

I still see no ethernet packets being transmitted from the downloaded tiboot3.bin

Regards

Neil

Hi Neil,

Neil Wilson said:

Building from ti-processor-sdk-linux-am62xx-evm-10.01.10.04 with these mods:

Could you please give it a try with SDK 10.00.07.04? From some past testing I've done with SDK 10.01.10.04, I saw some issues with Ethernet boot but I do know that with SDK 10.00.07.04, Ethernet boot worked on TI AM62x EVMs. 

Another idea is to try on SDK 11.0 

-Daolin

Hi Daolin,

Same beaviour - no ethernet packets transmitted from tiboot3.bin once it has been downloaded.

U-Boot SPL 2024.04-dirty (May 09 2025 - 09:43:32 +0100)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.0.8--v10.00.08 (Fiery Fox)')
SPL initial stack usage: 13392 bytes
Trying to boot from eth device
eth0: ethernet@8000000port@1
ethernet@8000000port@1 Waiting for PHY auto negotiation to complete.... done
link up on port 1, speed 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10
BOOTP broadcast 11
BOOTP broadcast 12
BOOTP broadcast 13
BOOTP broadcast 14
BOOTP broadcast 15
BOOTP broadcast 16
BOOTP broadcast 17

Retry time exceeded; starting again
udma_stop_mem2dev: peer not stopped TIMEOUT !
Problem booting with BOOTP
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

U-Boot SPL 2025.01-gcd91d7360181-dirty (May 09 2025 - 09:53:26 +0100)
SYSFW ABI: 4.0 (firmware rev 0x000b '11.0.7--v11.00.07 (Fancy Rat)')
Changed A53 CPU frequency to 1000000000Hz (S grade) in DT
SPL initial stack usage: 13424 bytes
Trying to boot from eth device
Loading Environment from nowhere... OK
eth0: ethernet@8000000port@1
ethernet@8000000port@1 Waiting for PHY auto negotiation to complete....... done
link up on port 1, speed 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
BOOTP broadcast 3
BOOTP broadcast 4
BOOTP broadcast 5
BOOTP broadcast 6
BOOTP broadcast 7
BOOTP broadcast 8
BOOTP broadcast 9
BOOTP broadcast 10
BOOTP broadcast 11
BOOTP broadcast 12
BOOTP broadcast 13
BOOTP broadcast 14
BOOTP broadcast 15
BOOTP broadcast 16
BOOTP broadcast 17

Retry time exceeded; starting again
udma_stop_mem2dev: peer not stopped TIMEOUT !
Problem booting with BOOTP
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

Hi Neil,

I will need some time to check internally on if there is any information we may have on enabling RMII Ethernet boot. As was mentioned before, while RMII Ethernet boot is listed as supported in the AM62x TRM, to my knowledge RMII Ethernet boot has not been officially tested before so I'm guessing there are some missing configurations that is necessary to build a tiboot3.bin that initiates DHCP messages. 

Neil Wilson said:

diff --git a/configs/am62x_evm_r5_ethboot_defconfig b/configs/am62x_evm_r5_ethboot_defconfig
index 853e5176..2719fdc4 100644
--- a/configs/am62x_evm_r5_ethboot_defconfig
+++ b/configs/am62x_evm_r5_ethboot_defconfig
@@ -14,7 +14,10 @@ CONFIG_SPL_SYSCON=y
CONFIG_DMA_CHANNELS=y
CONFIG_TI_K3_NAVSS_UDMA=y
CONFIG_DM_I2C=y
-CONFIG_PHY_TI_DP83867=y
+CONFIG_PHY_TI_DP83867=n
+CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ8XXX=y
+CONFIG_RMII=y
CONFIG_TI_AM65_CPSW_NUSS=y
CONFIG_MMC=n
CONFIG_SPL_MMC=n

Can you also try enabling CONFIG_CMD_DHCP to see if the behavior changes. While the SDK provided ethboot r5 defconfig has CONFIG_CMD_DHCP disabled, I'm wondering if enabling it might be needed for RMII mode?

-Daolin

Hi Neil,

Neil Wilson said:

ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_00_NS>;
ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;

Additionally, since you are not using the DP83867 PHY, I don't think you should have the above configured in your device tree. Not sure if this will change the issue but still something to fix.

-Daolin