PROCESSOR-SDK-AM62X: AM62X-SK

Hi Toby,

I have assigned your query to our expert. He is currently out for a customer visit, so expect delay in response.

Best Regards,

Suren

Hi Toby

Can you confirm what SK EVM you have. I am assuming it is SK-AM62B , please also share the ? Please confirm PROC number you see on the silkscreen. 

Regards

Mukul

Hi MuKul

Hi Toby

Please confirm which revision of the EVM you have. 

To understand the revision/naming scheme you can refer to the EVM user guide

https://www.ti.com/lit/ug/spruj40c/spruj40c.pdf

Section 1: 1 EVM Revisions and Assembly Variants 

My EVM version number is PROC114E2

Toby

Thanks for clarifying , to evaluate secure boot, key writer, you will need to purchase SK-AM62B or SK-AM62B-P1 EVMs. The SK-AM62 EVM  you have is a GP version EVM - and does not allow evaluation of HSFS. 

https://www.ti.com/tool/SK-AM62B

https://www.ti.com/tool/SK-AM62B-P1

Regards

Mukul 

I have seen some method online before that seems to be able to convert GP devices into HSFS devices. If there is such a method, can you tell me? Thank you!

Hi Toby 

On SK-62B and SK-62B-P1 the devices on the EVM are HSFS (field securable) , these can be converted to HS-SE (security enabled). You cannot convert GP to HSFS or HSSE 

You can  refer to following SDK documentation 

https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/08_06_00_42/exports/docs/linux/Foundational_Components_Migration_Guide.html

or and older E2E FAQ on HSFS migration for AM64 (same concept applies to AM62)

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1158018/faq-processor-sdk-am64x-am64x-am243x-sr-2-0-device-type-transition

I roughly understand what you mean. I have another question. Can I directly use the image of SK-AM62 on SK-62B and SK-62B-P1? Or do I need to recompile the SDK to generate exclusive images of SK-62B and SK-62B-P1?

The images are different

The default image for SDK9.0 (latest SDK) is HSFS 

https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/09_00_00_03/exports/docs/linux/Overview/Processor_SDK_Linux_create_SD_card.html

The documentation provides guidance on how you can generate image for GP

https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/09_00_00_03/exports/docs/linux/Foundational_Components_Migration_Guide.html

Upcoming versions of SDK will de-emphasis GP support and only HSFS will be supported. 

If you have more questions on image generation, I recommend opening a new E2E thread. 

For your query in this post on using OTP writer and evaluating secure boot, recommend migrating to the latest EVM. 

Regards

Mukul 

Can you inquire about the prices of SK-62B and SK-62B-P1？

Hi Toby

I believe these are $199 (USD) 

Regards

Mukul 

Toby,

As I  know, your company made GP based AM62 board already, you can replace with a security version AM62x device on your board to support security feature.  

Please contact your local contact window in TI for further clarification.

HI Tony
May I ask how to replace our company's board to support security boot?Is it a cup that has been replaced with SK-62B model?

Toby,

toby Tang said:

Is it a cup that has been replaced with SK-62B model?

I don't understand your question.

SK-AM62B is TI released board name. the major difference Vs SK-AM62, SK-AM62B mounted with security AM6254 device, SK-AM62 mounted with General purpose AM6254 device.

The device nomenclature in datasheet elaborates the part number

Hello

After trying again with the encryption chip, I encountered the following problem

When I switch to uart mode for transmitting tiboo3. bin, the serial port prints as follows

It seems like I ran the keywrite program, but there was no follow-up. What is the reason for this? Did I miss any operation

Which tiboot3.bin file you downloaded with xmodem?

On my side, the log as below:

SDK9.0: SK-AM62B

?2000000011a0000616d3632780000000000000048534653010001000100010002a6000000000000d68ecb2c055dff11ade95bd927e83
7d2a53bc23b0a2800cebce4f106bcf309df2213912d77a157a8b7c2df40672a06a918034aa4c7d603e462481475225d49b8ad0bc40b000
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
00000005daa24a20a39caa401ce063b897b24b9d34f88a1fb620ff51db193811002a3caCCCC
U-Boot SPL 2023.04-g24098ea90d (Jul 06 2023 - 12:59:40 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.5--v09.00.05 (Kool Koala)')
SPL initial stack usage: 13376 bytes
Trying to boot from UART
CCCLoaded 1138011 bytes
Starting ATF on ARM64 core...

NOTICE:  BL31: v2.8(release):v2.8-226-g2fcd408bb3-dirty
NOTICE:  BL31: Built : 00:42:57, Jan 13 2023

U-Boot SPL 2023.04-g24098ea90d (Jul 06 2023 - 12:59:40 +0000)
SYSFW ABI: 3.1 (firmware rev 0x0009 '9.0.5--v09.00.05 (Kool Koala)')
SPL initial stack usage: 1856 bytes
MMC: no card present
** Bad device specification mmc 1 **
Couldn't find partition mmc 1:1
Error: could not access storage.
Trying to boot from UART
CCCCCCCCCC

The Tiboo3. bin file I used in the following path has only one sentence printed without any follow-up

The following error occurs after annotating the keywriter_setVpp function

Starting Keywriting
Enabled VPP
keys Certificate found: 0x43c17f80
Keywriter Debug Response:0x2000000
Error occured...

Hi toby,

Have you made sure that you are meeting the VPP requirements. Please refer to the 1.3 VPP requirements section of the user guide for more info.

I wanted to change it to the gpio used by our board from the code, but some errors failed to achieve it. Then I modified the hardware to directly raise the foot by 1.8v, and the keywriter_setVpp function was commented in the code.

Hi toby,

toby Tang said:

Then I modified the hardware to directly raise the foot by 1.8v, and the keywriter_setVpp function was commented in the code.

I am not sure at the moment if this is ok. I will check and get back to you.

Meanwhile, I see that we are getting the following debug response:

Keywriter Debug Response:0x2000000

This error code on checking from TISCI documentation (http://downloads.ti.com/tisci/esd/latest/2_tisci_msgs/security/keywriter.html#otp-key-writer-error-codes) means we have some problem in programming MSV.

So, let us for now build a certificate without MSV and only try to program default SMPK & SMEK. The command would be:

./gen_keywr_cert.sh -t tifek/ti_fek_public.pem -s-def -s-ovrd --smek-def --smek-ovrd

This should generate a certificate with MSV disabled. Then follow the other commands to finally generate tiboot3.bin and try booting the same. Let me know if there is error in programming this also.

Regards,

Prashant

Print the following. Is that successful? Should I boot with tiboo3.bin SD card next

Hi toby,

This is indeed successful. However, please confirm which command you used to generate the certificate and then tiboot3.bin. Is it the command I shared in my last response?

toby Tang said:

Should I boot with tiboo3.bin SD card next

Please check the device type following the  Checking Device State (HS-FS/HS-SE) section of the user guide. If it shows HSSE then the device has been converted successfully from HS-FS to HS-SE and now enforce full secure boot. You would then need to resign the binaries including tiboot3.bin with the programmed SMPK.

Regards,

Prashant

thank you

Yes, I did. The command you shared with me worked.

In addition, I don't really understand what you said, "resign the binaries including tiboot3.bin with the programmed SMPK". Could you explain it a little more? I will try tomorrow.

Thanks again

I checked the device info and it looks like my device is not converted to an SE device. Is this due to the fact that I annotated keywriter_setVpp and used hardware boost 1.8

Is there a reply to this question?

Hi TI
Is there any update about this question?

Hi toby,

Sincere apologies for being unable to keep an eye on this thread. Let us start again on this thread and resolve it asap.

So, the last time I asked to try the following command for keywriting procedure

./gen_keywr_cert.sh -t tifek/ti_fek_public.pem -s-def -s-ovrd --smek-def --smek-ovrd

I would like you to please note that this command was only meant to test the keywriting by programming the default TI dummy keys. Since, the keywriting was successful, this asserted that the VPP workaround (diretcly raising the foot by 1.8v) is working.

-----------------

With the VPP working, the customer can move to generating their own custom certificate with their own keys and programming the same. For this, please refer to the section 3.2 Reference Commands in the User Guide. Please also pay attention to the "Warning" & "Note" available at the very start of this section as they warn about not programming certain fields as the action is not reversible and so the device may become unusable.

In case of any doubt, please let me know.

Regards,

Prashant

thank you

I was busy with other things before, and now I have time to deal with this problem. I am very sorry to bother you again

Because of my first exposure to security features, I do not know a lot of things, and ask for more advice

As for what you replied, can I understand that not all 3.2 Reference Commands need to be executed? I may try to execute all commands, which leads to irreversible operations, so the device cannot be used.

1. If so, can I create a new project directory and try to compile it?

2. Is it true that the equipment conversion is not hs-se is successful and can proceed to the next step

Thanks again

toby Tang said:

can I understand that not all 3.2 Reference Commands need to be executed?

Yes, you understand correctly. The reference commands are to demonstrate how to generate the certificates for different needs.

If you are just testing the secure boot & do not mind programming the TI dummy keys that comes with the OTP Keywriter installer, you can simply use the command as it is from 3.2.2 Program Everything in One Shot. This will program TI dummy keys & also program the KEYREV field. If the keywriting is successful, the device will then become HS-SE device.

If you want to create your own keys and program the same, simply generate new keys with

./gen_keywr_cert.sh -g

This will generate the keys in keys/ folder. Then modify the certificate generation command accordingly by giving the path to your own keys instead of the TI dummy keys present in the keys_devel/ folder.

Thank you. I will reinstall mcusdk and try again. If there is any problem, I will contact you

Thanks again