- Ask a related questionWhat is a related question?A related question is a question created from another question. When the related question is created, it will be automatically linked to the original question.
Tool/software:
Hi TI Experts,
We are discussing offline about the support of ethernet primary boot & backup boot. As following your suggestion, I also created E2E thread here to involve customer together so that we could stay on the same page.
In the last email thread, customer followed the below steps to see if the ethernet backup boot is working properly on their board.
Customer got the Wireshark screenshot below.
Customer is pretty sure the MAC address 88:0C:E0:67:D6:18 is for the AM2431 on their board, since the Ethernet port of the board is directly connected to their computer’s Ethernet port with a cable, and their computer’s MAC is totally different.
By the way, customer notices that for the backup boot, AM2431 only sends BOOTP request about 117s after power up. It is a little bit too long.
If Ethernet Boot program/tools is ready, customer will change the Ethernet as Primary boot (with mode change switch) in next board spin.
So please make sure the Ethernet boot tool we are working on can work for both Primary boot as well as backup boot.
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,
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 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 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:
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
Hi Vaivhav,
Thanks for your reply.
This is information printed by uart, with offset being 0x80000, hello word appimage should be flashed at 0x60080000:
Also please be noted this function returns -1:
status = Bootloader_uniflashProcessFlashCommands(&uniflashConfig, &respHeader);
I tried to enable DAC before memory browser and this is what I got:
Data seems do not match hello word appimage.
Yours,
Ellen
Hi Ellen,
I have check the datasheet for the flash part and it mentions that the clock frequency should be no more than 133 MHz/120 MHz for the dummy cycle configuration of 8.
Here we have the dummy clock reads as 8, so the frequency should be changed, in your case, the frequency is set to 200 MHz in OSPI section from SysConfig.
Once you have the OSPI section opened, your clock frequency should be set to 133 MHz = 133333333, Clock Divider: 4, Disable DMA, Disable Phy Mode.
Please let me know, if you can see the hello world flashed correctly upon enabling DAC mode with the above changes.
NOTE:
If not, then we can do a sanity checking by switching mode of operation to 1S-1S-1S and then checking if the hello world is flashed correctly.
Regards,
Vaibhav
Hi Vaibhav,
thank you for the detailed suggestion, here are my results:
Clock divider: 4, Disable DMA, Disable PHY, mode: 1S-1S-4S, clock 133MHz/120MHz:
Clock divider: 4, Disable DMA, Disable PHY, mode: 1S-1S-1S, clock 133MHz/120MHz:
data at location 0x70090000 keeps consistent for all scenarios as:
Can you please help and check the data?
Many thanks!
Yours,
Ellen
Hi Ellen,
Thanks for your response.
1S-1S-1S
When you switched this mode of operation did you make sure to change the SysConfig Flash other settings as well? Or you just went ahead and selected the dropdown as 1S-1S-1S from 1S-1S-4S(earlier one)?
The other settings I am talking about is:
FYI, the value from flash as seen with 1s-1s-4s is incorrect and the value for 1s-1s-1s(hello world seems to be not flashed at all, and the bootloader image we need to confirm). Can you please check the hex dump of bootloader image and compare it with the 0x60000000 in 1s-1s-1s mode.
Looking forward to your response.
Regards,
Vaibhav
