TMDS64EVM: Default SD card images from Linux HS EVM SDK do not boot on HSFS TMDS64EVM

On the "supported products and hardware" list for that SDK only the TMDS64GPEVM is listed. The TMDS64EVM (what I'm using) is not listed. Therefore, I thought I should be using the "HS" version of the SDK since my TMDS64EVM has an HS-FS processor. Is that supported hardware list wrong?

Grant Edwards said:

Is that supported hardware list wrong?

We have been battling this for over a month now. Ti even sent us a replacement board and it will not boot.

Its either they have a bad batch of boards or the software is not correct. We jumped through the tech support hoops and it still does not work. If you look at our other posts regarding the AM64B board we have the version of the board posted. It would be interesting if yours is from the same lot.

Do make sure you have changed the file name of ti3boot. You must explicitly change/rename the GP version to work. Docs say its autodetect, that is not correct with the AM62 board, so it is assumed similar for the AM64

The file tisdk-default-image-am64xx-evm.wic.xz from the page at https://www.ti.com/tool/download/PROCESSOR-SDK-LINUX-AM64X worked for my board.

After uncompressing, the file is

$ ls -l *.wic; md5sum *.wic
-rw-r--r-- 1 grante users 2776927232 Apr 24 17:47 tisdk-default-image-am64xx-evm.wic
65282e721ef22f390d39ebc28ecbbf0a tisdk-default-image-am64xx-evm.wic

However, that file on that page appears to have changed since yesterday when I downloaded it the first time. The one I downloaded today is shown below

$ ls -l *.wic; md5sum *.wic
-rw-r--r-- 1 grante users 2776927232 Apr 25 16:09 tisdk-default-image-am64xx-evm.wic
d39d3b8a87b9bf271c2786e0b67c174c tisdk-default-image-am64xx-evm.wic

$ cmp tisdk-default-image-am64xx-evm.wic tisdk-default-image-am64xx-evm.wic-old
tisdk-default-image-am64xx-evm.wic tisdk-default-image-am64xx-evm.wic-old differ: byte 1048614, line 1

Today's download boots up OK also.

The part on my board is an HS-FS XAM6442B (shown below)

PCA part/version show below:

Fred Fisher said:

Do make sure you have changed the file name of ti3boot. You must explicitly change/rename the GP version to work. Docs say its autodetect, that is not correct with the AM62 board, so it is assumed similar for the AM64

I did not need to rename any files to get my AM64EVM board to boot.

Thank you very much for sharing that with me. My board is red, it is SK-AM64B. Wonder what the difference is, I thought what I purchased is an EVM. I will try downloading that image and give it a try.

Update, just tried it and it does not boot.

Both of the AM64 boards do not work in UART boot mode, they are suppose to send  the letter C and that does not happen. The AM62 board will go into uart boot and send a string with the letter C. I thought about ordering another one, maybe the 3rd one will work?? Pretty sure if I do order another AM64 it will be the green EVM like you have not another SK board.

Just looked and the chip is the exact same markings  as yours so I would assume  all the numbers are the same so it would be from the same batch. So, if the board was okay it should boot using the exact same image.

Fred Fisher said:

Thank you very much for sharing that with me. My board is red, it is SK-AM64B. Wonder what the difference is, I thought what I purchased is an EVM. I will try downloading that image and give it a try.

TI's documentation and product naming is confusing and inconsistent.  There is a product called an "SK EVM"  in some places and just "SK" in others.  It's got 2 RJ45 Ethernet jacks. In some photos it's white, in some it's red. I don't know if there's any difference between the read and white versions, but it's different than the "EVM" (green board with 3 RJ45 Ethernet jacks). However, according to the docs, the same disk image is supposed to work for both the SK (aka SK EVM) and the (green) EVM:

https://dr-download.ti.com/software-development/software-development-kit-sdk/MD-yXgchBCk98/08.06.00.42/tisdk-default-image-am64xx-evm.wic.xz

Are you uncompressing it before writing to the SD card?  On my PC, the SD card shows up as /dev/sdc. Here's the command to write it to the SD card on my machine (run as root if your normal user account doesn't have write access to the SD-card device):

# xzcat tisdk-default-image-am64xx-evm.wic.xz | dd of=/dev/sdc bs=256k

The TI documentation does that in a different way that need extra tools installed, requires several steps, takes longer, uses up a lot of disk space, and destroys the original download file.  Dunno why....

Grant Edwards said:

Are you uncompressing it before writing to the SD card? 

I have been using pi-imager and have tried balena. Both uncompress as they install on SD.

Grant Edwards said:

TI's documentation and product naming is confusing and inconsistent. 

Yes, it is.

I will try it using your technique and see what happens.

Update, Just tried using DD as you suggested. Still dead. It still has a glowing red LED on the bottom, it must be something upstream from SoC that has failed. Never have seen a red LED on the AM62 board and it works, so my assumption is a failure indicator for something.

Hello Grant & Fred,

Thank you for yall's patience here. To provide a bit more information about the naming conventions, etc:

TMDS64GPEVM - this part uses the general purpose (GP) silicon that was originally available when the AM64x was first publicly announced. This is the "old" non-secure version of the processor. We will not be producing GP versions of silicon for production, so this can be used to start development, but you'll need to use the "new" version of silicon for your final products. The "new" version of silicon came out for the first time around SDK 8.4:

TMDS64EVM - this part uses the HS-FS silicon (think: "new" non-secure version of the processor). SDK 8.4 was the first time our software supported the "new" silicon version of the processor. The main point of the change is that now customers can use the same HS-FS board to develop for non-secure usecases (i.e., HS-FS), and secure usecases (i.e., HS-SR). Benefits include special EVMs just for security are not needed, and if you do a design in a non-secure context, and then need to release another product, it will be a lot easier to take your non-secure design and turn it into a secure design.

Note that there are two different AM64x boards, the general purpose EVM board (which is the two part numbers above), and the Starter Kit EVM (i.e., SK or SK-EVM)

I am not a security expert, so I'm going to send your thread over to our security expert to answer additional questions if you need it.

Regards,

Nick

Another note about boot behavior with regards to GP & HS-FS silicon, and using a fit image vs a separate Linux kernel & devicetree file: it did change between SDK 8.5 and SDK 8.6.

Variable boot_fit in uboot selects whether the fit image is used to boot, or the separate Linux image and devicetree file is used for boot. in SDK 8.4 & 8.5 it overwrote any settings to boot with the fit image every time the board booted. Starting in SDK 8.6, if the boot_fit variable has been set, then it is not re-set by uboot.

Steps to either generate a fitImage or separate Linux image and devicetree binaries are here: software-dl.ti.com/.../Foundational_Components_Kernel_Users_Guide.html

Regards,

Nick

Hi Nick,

Do you know who did the hardware layout on the board with the M2 tag on it, assembly # PROC100A(002). If we can verify the actual uart boot mode pin settings as stated in the TRM are correct that will help.

Per the docs

It should be send out the string to identify the device type, that does not work.

Hello Fred,

I have turned your latest response into a separate e2e thread here: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1221418/re-debugging-sk-am64b that thread has been assigned to our EVM owner.

This thread is still assigned to our security owner in case there are additional security-related questions.

Regards,

Nick

Hong Guan64 said:

A reference on booting "tiboot3.bin" with AM64x Linux SDK on different device type SoC (GP/HS-FS/HS-SE)
software-dl.ti.com/.../Foundational_Components_Migration_Guide.html

Hello Hong,

I have looked at that reference, but per the docs both boards do not output the string in UART boot mode.

Do you have the known and for fact boot switch settings for the exact boards we have.

Reading into this it seems that if the keys have been burned it will not send anything out to UART. The boards never did boot for us so was the key possibly burned during testing of boards while at the factory?

If it is none of that the board must be dead, just find it extremely hard to believe we got 2 dead boards. It almost seems like the security issue is causing the problems.

We really don't want to move forward with any thing until this is resolved.