AM2431: Support of Ethernet Primary Boot & Backup Boot

Hi Jianyu,

Jianyu Wang said:

I have rebuilt the SDK, now the phy can correctly bind to 83826.

This is good, can you build the example in release mode and test again.

Please make sure you have added the static ARP entry in your PC as mentioned in the guide.

Also, you should monitor the port through wireshark and see if any packets are received from the board. This will help pin-point what exactly is not working.

Regards,

Nitika

Hi Nitika,

The log is different if built in release,

DMSC Firmware Version 10.0.8--v10.00.08 (Fiery Fox)
DMSC Firmware revision 0xa
DMSC ABI revision 4.0


[ ENETSBL ] Starting Ethernet Transfer ...
Enabling clocks!
EnetAppUtils_reduceCoreMacAllocation: Reduced Mac Address Allocation for CoreId:1 From 4 To 2
Open MAC port 2
EnetPhy_bindDriver:1873
PHY 7 is alive
EnetMod_ioctl:1608
Cpsw_registerIoctlHandler:1844
EnetPer_ioctl:1394
Enet_ioctl:1057
Failed to set dscp Priority map for Port 1 - -1
[ ENETSBL ] initQs() txFreePktInfoQ initialized with 8 pkts
[ ENETSBL ] EVM MAC address: 88:0c:e0:67:d6:2d

[ ENETSBL ] PHY 7 is alive
[ ENETSBL ] Please wait for Linkup ...

[2024-12-12 02:01:34.926]
RX：Cpsw_handleLinkUp:1450

[2024-12-12 02:01:36.927]
RX：[ ENETSBL ] Linkup Done!

[2024-12-12 02:01:52.995]
RX：[ ENETSBL ] Status:0
[ ENETSBL ERROR ] Uniflash timeout error.
Cpsw_handleLinkDown:1476
Disabling clocks for ENET: 5, inst:0!
Flashing failed!!
Skipped boot-up!

The package is as follows,

CD3E_sbl_package.zip

Note that "Uniflash timeout error. " is triggered whether I executed uniflash.py or not. The network package is the one that I executed the py file.

Jianyu

Hi Jianyu,

Jianyu Wang said:

The log is different if built in release,

This is expected, in release mode the ENET logs are optimised which is why you are seeing numbers in place of the actual message that was present in Debug mode.

"Uniflash timeout error" occurs when the appimage is not received.

The SBL is working as expected, can you let me know what IP addresses have you set? So I can understand the wireshark logs better.

Regards,

Nitika

Hi Nitika,

Thanks for your reply.

Customer sets the IP according to your example.

The local IP is 192.168.0.136, MAC 00-1b-21-8a-20-11

The DHCP IP given to the board is 192.168.0.137

The MAC address before running the SBL is 88-0c-e0-67-d6-08

The MAC address after running the SBL is 88-0c-e0-67-d6-2d

Thanks,

Kevin

Hi,

Have the System integration settings been modified? I expect the EVM mac address to be either of the 2 below:

From the wireshark logs, the board is sending the linkup complete packet to the PC (board IP address after SBL runs is 192.168.0.195) but the response is not reaching the board.

Few things to verify:

1. The macro ENET_HOST_PC_MAC_ADDRESS in the file sbl_enet.h should have the MAC address of the ethernet interface of Host PC.

2. The Gateway is set to 192.168.0.195 on the ethernet interface of the Host PC.

3. New-NetNeighbor command to add the static ARP entry should have the MAC address of the EVM (the address printed in the UART terminal after SBL runs)

Can you try to run the python script once you see "[ ENETSBL ] Please wait for Linkup ..." message on the terminal, you should get the "Received." message since the linkup packet has been sent out from the board.

Regards,

Nitika

Hi Nitika,

I have updated the variable.

Nitika Verma said:

1. The macro ENET_HOST_PC_MAC_ADDRESS in the file sbl_enet.h should have the MAC address of the ethernet interface of Host PC.

It seems that I am able to connect to the SBL program. However, the time window is a little bit too small between after the wait for linkup.

Jianyu Wang said:

[ ENETSBL ] PHY 7 is alive
[ ENETSBL ] Please wait for Linkup ...

[2024-12-12 02:01:34.926]
RX：Cpsw_handleLinkUp:1450

[2024-12-12 02:01:36.927]
RX：[ ENETSBL ] Linkup Done!

So I managed once to run the script as soon as I saw Linkup Done. The console return the follows,

D:\CD3E-AP\Ethernet\Ethernet_boot>python enet_uniflash.py --cfg=default_sbl_enet_app.cfg
[LOG] Parsing config file ...
[LOG] Ensure that sbl_qspi_enet has already been sent over before running this script.
[LOG] Found 1 command(s) !!!
[LOG] Creating socket
Starting Linkup ...
Received.
('192.168.0.195', 5001)

[LINKUP] (SUCCESS) EVM Linked up. Starting transfer ...

Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  15%|▏| 8872/61139 [00:00<00:00, 593566.Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  17%|▏| 10344/61139 [00:00<00:00, 431962Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  19%|▏| 11816/61139 [00:00<00:00, 455279Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  22%|▏| 13288/61139 [00:00<00:00, 492875Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  24%|▏| 14760/61139 [00:00<00:00, 527486Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  27%|▎| 16232/61139 [00:00<00:00, 560188Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  29%|▎| 17704/61139 [00:00<00:00, 590607Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  31%|▎| 19176/61139 [00:00<00:00, 618939Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  34%|▎| 20648/61139 [00:00<00:00, 645489Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  36%|▎| 22120/61139 [00:00<00:00, 670540Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  39%|▍| 23592/61139 [00:00<00:00, 694098Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  41%|▍| 25064/61139 [00:00<00:00, 696664Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  43%|▍| 26536/61139 [00:00<00:00, 718222Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  46%|▍| 28008/61139 [00:00<00:00, 738073Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  48%|▍| 29480/61139 [00:00<00:00, 756183Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  51%|▌| 30952/61139 [00:00<00:00, 774234Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  53%|▌| 32424/61139 [00:00<00:00, 791964Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  55%|▌| 33896/61139 [00:00<00:00, 827918Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  58%|▌| 35368/61139 [00:00<00:00, 842869Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  60%|▌| 36840/61139 [00:00<00:00, 857809Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  63%|▋| 38312/61139 [00:00<00:00, 799125Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  65%|▋| 39784/61139 [00:00<00:00, 812463Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  67%|▋| 41256/61139 [00:00<00:00, 842524Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  70%|▋| 42728/61139 [00:00<00:00, 855152Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  72%|▋| 44200/61139 [00:00<00:00, 867317Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  75%|▋| 45672/61139 [00:00<00:00, 879100Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  77%|▊| 47144/61139 [00:00<00:00, 890419Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  80%|▊| 48616/61139 [00:00<00:00, 918221Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  82%|▊| 50088/61139 [00:00<00:00, 928094Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  84%|▊| 51560/61139 [00:00<00:00, 938051Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  87%|▊| 53032/61139 [00:00<00:00, 947904Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  89%|▉| 54504/61139 [00:00<00:00, 974214Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  92%|▉| 55976/61139 [00:00<00:00, 965991Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  94%|▉| 57448/61139 [00:00<00:00, 974080Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  96%|▉| 58920/61139 [00:00<00:00, 951137Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs:  99%|▉| 60392/61139 [00:00<00:00, 959119Sending ./hello_world_am243x-lp_r5fss0-0_freertos_ti-arm-clang.appimage.hs_fs: 61146packets [00:00, 971093.84packets/s]Traceback (most recent call last):
  File "D:\CD3E-AP\Ethernet\Ethernet_boot\enet_uniflash.py", line 461, in <module>
    status, part_time = transceive(sock, partial_file, len(partial_file), args.boardIP, args.boardPort,filecfg.cfgs[index].filename, total_size)
  File "D:\CD3E-AP\Ethernet\Ethernet_boot\enet_uniflash.py", line 410, in transceive
    data, addr = sock.recvfrom(8)
socket.timeout: timed out

The UART still returns 

Jianyu Wang said:

2024-12-12 02:01:52.995]
RX：[ ENETSBL ] Status:0
[ ENETSBL ERROR ] Uniflash timeout error.
Cpsw_handleLinkDown:1476
Disabling clocks for ENET: 5, inst:0!
Flashing failed!!
Skipped boot-up!

And I think PC might still be transfering the data after the board time out.

CD3E_sbl_package2.zip

Hi Jianyu,

Jianyu Wang said:

However, the time window is a little bit too small between after the wait for linkup.

You can start the python script before also as long as it doesn't timeout before the board linkup happens. We can increase the timeout by increasing the value from 5 in the below line of the python script - 

Hello_world has a relatively small appImage, I do not expect this timeout. Still we can try again by increasing the socket timeout.

Can you increase the value from 5 to 10 in this line of the enet_uniflash.py file -     sock.settimeout(5)

Regards,

Nitika

Hi Nitika,

This time I started the script before SBL starts. The output is same. The firmware I used is Hello_world demo, the size of wich is 60KB.

I am pretty sure the board prints time out before the transfer finish.

Hi Jianyu,

The Uniflash timeout print is also seen if there is an error while processing the flash commands, specifically if an error is returned from the Bootloader_uniflashProcessFlashCommands() function indicating that it could be a Flash issue.

/* Process the flash commands and return a response */
status = Bootloader_uniflashProcessFlashCommands(&uniflashConfig, &respHeader);

/* Exit if error or timeout; Send response to host */
if (status != SystemP_SUCCESS)
{
    DebugP_log("[ ENETSBL ERROR ] Uniflash timeout error.\r\n");
    done = 1U;
    status = SystemP_FAILURE;
}

Can you confirm that you have modified the example with the requirements of your on-board flash device.

Regards,

Nitika

Hi Nitika,

I have added status = SystemP_SUCCESS after Bootloader_uniflashProcessFlashCommands, and the result returns success.

I'll look into the flash issue next week.

Thanks,

Jianyu

Hi Jianyu,

Thanks for the info, do let me know if you need any help later.

Regards,

Nitika

Hi Jianyu,

Any updates on the progress here?

Regards,

Nitika

Hi Nitika,

Sorry I was assigned with another task this week. Maybe we can close this thread, and add another if new issue occurred.

Thanks,

Jianyu

Hi Nitika,

The current situation is that if customer adding "status = SystemP_SUCCESS" as mentioned above, the Ethernet boot is successful. However, they still have not resolved the flash problem yet.

Customer has another engineer also tried to resolve the flash issue last week but did not success.

I just have discussed with customer to fully close this topic, they will still look at this flash issue this week.

Currently the fail log for this flash issue is shown below.

May I know do you have some suggestions for customer to debug with?

Thanks,

Kevin 

Hi Kevin, 

With "status = SystemP_SUCCESS" change, once the Ethernet boot SBL completes. Can you ask the customer to switch to OSPI boot mode and check if the Hello world application runs?

I do not expect it to run as the uniflash issue might have led to the appImage not being flashed properly, still I would like to check this once.

I will loop in our Flash expert as well to provide any debug suggestions.

Regards,

Nitika 

Hi Kevin,

One additional question, on which board is the customer testing this example - AM243x-lp or their custom board?

Regards,

Nitika

Hi Nitika,

Thanks for your help.

Customer is testing the example on their custom board.

Will update the result of running "Hello World" application later.

Thanks,

Kevin

Hi Nitika,

Customer just double check that after using "status = SystemP_SUCCESS" to avoid the flash issue, the result is not actually successful, it still has a problem shown in the last log below.

After digging into details, we found that this fail comes from below code line, and the status is -1.

status = Bootloader_parseMultiCoreAppImage(bootHandle, &bootImageInfo);

Do you think this problem is also due to the flash is not actually successful?

Thanks,

Kevin

Hi Kevin,

Kevin Peng said:

After digging into details, we found that this fail comes from below code line, and the status is -1.

status = Bootloader_parseMultiCoreAppImage(bootHandle, &bootImageInfo);

This aligns with my suspicion above - Bootloader_uniflashProcessFlashCommands function fails possibly even before flashing completes, which is why the appImage is not found in proper integrity and the example fails.

As a next step, we can check where exactly inside the Bootloader_uniflashProcessFlashCommands function does the failure come from with the steps below:

1. There is a loop_forever() function defined in main.c file. Add a call to this function before the below line in main.c:

Hi Kevin,

I am reading through this thread and I can provide my inputs in sometime.

Regards,

Vaibhav

Hi Kevin,

We can carry forward the debug from this point onwards: https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1423298/am2431-support-of-ethernet-primary-boot-backup-boot/5581232#5581232

Apart from this can you tell me the following:

1. Name of the QSPI flash part.
2. Which mode is it running in? For example: 4S-4D-4D
3. Please share the screenshot of the OSPI tab from the application's SysConfig.

Regards,

Vaibhav

Hi Vaibhav,

flash we are using is GD25Q64ESIG in 1S-1S-4S mode.

I find certLen = Bootloader_getX509CertLen(x509Header) = 0, which leads to a fail state of function Bootloader_parseMultiCoreAppImage(bootHandle, &bootImageInfo); by looking deeper I find value of x509_cert_ptr is 0x1F instead of 0x30, this gives certLen = 0:

Here is configuration from SysConfig:

Hi Nitika & Vaibhav,

We seem could narrow down this problem by figuring out why x509_cert_ptr returns value 0x1F instead of 0x30.

Could you help suggest some clue for us please?

Thanks,

Kevin

Kevin Peng said:

x509_cert_ptr returns value 0x1F instead of 0x30.

Firstly we need to see if the appimage being flashes is correct or not, then the verification would be right.

So, a typical HS FS appimage is going to look like this: 

So we need to first confirm from memory browser if the image is starting as following: 0x30 0x82 and so on.

Can you do so and let me know?

Regards,

Vaibhav

Hi Vaibhav,

I checked the following 3 locations in memory browser, all showing 0:

0x60000000, 0x60080000, 0x60088000

Thanks,

Ellen