Hi Board designers, 

Refer below inputs for the VPP supply related queries.

1. When is VPP required

The VPP is used to program the eFuse when HS-FS devices are used.

SoC devices come in two types: General Purpose (GP) & High Security (HS). All GP devices can leave the VPP domains unconnected per DM. Pre-programmed HS devices can also leave VPP supply unconnected if no additional eFuse programming is needed. If it is required to do on-board eFuse programming, VPP supply is required.

2. Difference between GP and HS-FS hardware design

The key difference is the SOC and the VPP configuration. You need to supply the VPP supply rail during the time that eFuses are programmed,

3. What are the VPP voltage and current specs?

Refer section in the datasheet: 7.9.1 Recommended Operating Conditions for OTP eFuse Programming. 

4. What is the recommended VPP supply solution?

An LDO low-dropout with fast transient response, quick output discharge and capability to enable to output is recommended.  PMIC with LDO output meeting the datasheet ROC (Recommended operating conditions) can be used.

A fixed output LDO is recommended. When an adjustable LDO is used, consider adding an external zener based over voltage protection at the LDO output and provide a provision to isolate the LDO output connected to the processor VPP supply pin. Test the LDO output performance before connecting the LDO output to the VPP supply pin.  

5. Can I use a load switch or FET to switch the supply?

Given the high load current transient requirement during eFuse programming, load switch or FET switch may not be a recommended approach, It is recommend using a 400mA LDO.  A load switch is likely to have too much voltage drop that can't be compensated like when using an LDO.

6. LDO specs to consider?

The 1.8V source for VPP should have an internal active discharge function that gets turned on when the source is disabled to ensure VPP is held to 0V during normal operation.

7. Should i use a dedicated supply?

The VPP voltage is not recommended to be supplied when the eFuse write is not being done.

VPP should only be powered while security key programming is done.  It should be powered off during all other times, including normal active use of the SoC.  This is the reason for VPP supply not being shared with other peripherals, which are required to be powered at all times.

8. eFuse programming steps

An OTP (One Time Programmable) Keywriter (software tool) is used to program the eFuse. The keywriter  controls the On-Board LDO that is used to generate the VPP supply voltage via a GPIO output.

An alternative way to source the VPP is to use an external supply. The required caps and termination/Discharge resistor are recommended to be placed near to the SoC VPP pin. 

A custom VPP Programming board using an LDO similar to the On-Board LDO used in the EVM can be designed and the LDO can be enabled via the GPIO output. 

https://www.ti.com/lit/zip/sprr275 

(refer to file VPPPROGRAMMINGBOARD_3J0002_REV1_0A.PDF).  

Recommended LDO

https://www.ti.com/product/TLV755P/part-details/TLV75518PDQNR

In case an external power supply is used, The GPIO output can be used to control or time the external power supply output.

 Programming sequence for OTP eFuses:
• Power on the board per the power-up sequencing. No voltage should be applied on the VPP terminal during power up and normal operation.
• Load the OTP write software required to program the eFuse (contact your local TI representative for the OTP software package).
• Apply the voltage on the VPP terminal (according to the specification in Section 7.9.1 of the datasheet).
• Run the software that programs the OTP registers.
• After validating the content of the OTP registers, remove the voltage from the VPP terminal.

Reference: Section 7.9.3 Programming Sequence of datasheet

9. How should I terminate the VPP supply pin for GP devices?

Do not connect the SOC VPP pin. Leave it open. Alternatively, you could terminate to ground externally.

10. How should I terminate the VPP supply pin for HS-FS device used as a GP device?

Used as GP device and could be used as HS-FS device in the future

Provide a provision to add a discharge resistor 1K.  The pull-down value needs to be to select such that it doesn't allow any leakage path through the LDO to source a potential greater than 0V when disabled.

Provide provision for low loop inductance bulk (2.2 uF) + decoupling (0.1 uF) capacitor(s) located near the VPP pin.

Populate the discharge resistor and DNI the capacitors.

Used as only GP device (no HS-FS)

The VPP pin can be left open or a 1K resistor can be added with a TP for Just in case usage.

11. How should I terminate the supply for HS-FS devices when not programming the eFuse

The VPP power rail is required to be powered during the programming of the eFuse array.  It should not be powered during normal operation. An always VPP supply is not allowed or recommended. 

Device reliability was never evaluated for an operating condition where the VPP power rail was connected to an always on power source.  Take care to connect the LDO to a GPIO such that it defaults to the off state and the TI keywriter software will apply power to VPP when appropriate.

12. Any suggestions for Reducing OTP write failures.

The VPP power rail requires  load current transients to blow the metal fuses in the eFuse array, so it would be almost impossible to maintain the ROC voltage range on the VPP pin without providing a very low loop inductance bulk decoupling capacitor(s) located near the VPP pin.  It is important the customer validate VPP never drops below the min ROC value during programming to ensure the fuses are burned properly. The fuses may appear to be blown but could be marginal if the VPP is allowed to drop below the min ROC value even for the shortest period of time during programming. VPP supply has to be characterized to ensure they are within the ROC during programming.

13. Do you have Any additional recommendations?

Refer the below section of the device specific datasheet.

7.9 VPP Specifications for One-Time Programmable (OTP) eFuses

      14. Does the above guidelines apply for AM64x, AM62A7, AM62A3, AM62P and AM62Px devices?

It is Ok to follow the described guidelines/recommendations for the above-mentioned devices

     15. On the SK TLV75518PDQNR is used. Is there an LDO recommendation for automotive applications?

Load Transient characteristics is required to be comparable to the power supply used in the SK (TLV75518PDQNR).

or other automotive LDOs another recommendation would be TPS7A21-Q1 which showcases good transient response.

Currently, we are sampling the 1.8V output option of this LDO, P7A2118PQWDRBRQ1. The full release MPN of this LDO will be TPS7A2118PQWDRBRQ1.

Note on LDO selection 

TLV75518PDQNR is  device in DQN Package, 4-Pin X2SON

Refer below device outline 

There is a likely chance of assembly error due to the LOD outline, pins orientation 

and the land pattern (pads and pitch)

Note: An alternate package could be selected based on the space availability can be chosen. Alternative be sure to include the LDO assembly caution note during board assembly. 

eFuse programming supply use case summary 

The VPP pin is only allowed to be powered during programming.  So the system design must provide a way for software to only apply power during programming of the eFuse array. We do not recommend a load switch or a DC/DC source due to the high transient currents required to blow the fuses. We recommend the VPP pin be sourced directly from a dedicated LDO that has good transient response.  Even then the system designer needs to validate their specific solution doesn’t allow the VPP pin on the processor to ever drop (not even for a very short period of time) below the minimum ROC voltage while programming the eFuse array. They may need to minimize trace inductance and/or increase decoupling capacitors as necessary to ensure this operating condition.  This is the reason it is not possible to power VPP from a shared power source.

Additional References 

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1352842/am625-am625-am623---vpp-usecase

Regards,

Sreenivasa

Hi Board designers, 

Refer below additional inputs for the VPP supply related queries.

16. We need to supply all the power of SOC while we're writing, right? Or should we just supply VPP power?

HI Board designers,

Refer below additional queries answered

1. The VPP is supplied during factory process, can this cause any OTP writing failure?

Using external supply should not be a concern. it is important to follow the power sequencing requirements. The SOC supplies should have ramped up and be stable before applying the VPP. It is recommended to switch off the VPP before switching off the SOC supply. Since an external voltage source is used, a 2.2 uF + 0.1 uF cap is recommended near to the SOC VPP pin due to the load current transient requirements.

Also note the below inputs i received from the device expert:

All customers must validate their VPP source impedance and confirm it never allows the AM62x VPP pin to drop below the min value defined in the ROC table for any period of time during eFuse programming.  The VPP load current transient  is very high short duration pulses so this validation is very important to ensure the fuses in the eFuse array are properly burned.

1. How close in time should the VPP supplied before the OTP writing starts? The idea here is to drive the VPP by a external source before we download the keywriter routine then remove the supply after the keywriting is complete. We would not be using any internal trigger signal from the soc.

The recommendation is to use an SOC IO to time since this ensure the power sequence in additional to the ON time. It should be OK to have the VPP supply ON for few seconds before the key writer routine is executed and switch off a few seconds after the key writing routine is executed. The key is the VPP supply should be within the ROC all the time and also the supply sequencing is followed.

Note on Keeping VPP on for longer than required time:

The biggest concern with apply a potential to VPP when not programming the eFuse array is an increased probability that the eFuse array could accidently be programmed if something unexpected happens and rouge code writes to the eFuse array.  There should not be any problem if they ensure this never happens.

AM62A3-Q1: VPP while writing

①If we interrupt writing in the middle, is it possible to start writing again from the beginning?

→No. It is impossible.

→In case of power failure of VPP/SoC during the function Sciclient_service() execution, the consequence is unexpected, and most likely, it is impossible to re-run key programming again.

②What kind of problems can be expected if there is a power loss in the middle of writing?

→ In case of power failure of VPP/SoC during the function Sciclient_service() execution, the consequence is unexpected

③How can we check if the writing was successful? Is there a register to store the write results?

→***I should ask another thread.***

④We need to supply all the power of SOC while we're writing, right? Or should we just supply VPP power?

→SOC is expected to be supplied with all supplies. the supplies are expected to be ramped and stable.

⑤Is it possible to control the GPIO of the AM62A while writing?

→Yes. the LDO EN is controlled by the GPIO.

→Yes. R5 SRC code is owned and re-buildable by user, and it is possible to configure peripheral, i.e. GPIO in R5 code.

Regards,

Sreenivasa

HI Board designers,

Refer below additional queries answered

For functional safety, is monitoring eFuse supply required.

I suspect NO as the only time VPP needs to be applied is during OTP programming, so a security update related
Step like firmware anti-rollback or key revocation – and I would not expect these tasks to be triggered at the same time
the application is performing a safety function. We should confirm that w. the customer but likely they can mark as not
safety related in the FMEDA.
Are we recommending that the customer switches VPP on only when programming OTP or are we just telling them to connect it always on?
Only when programming the eFuse array.
Monitoring of VPP supply is not required.
There is an underlying assumption that should go into the Safety Manual if it’s not there – and that is basically that
Any operations involving OTP programming are not carried out when the safety task has started, as we consider
OTP programming as not safety related.

Regards,

Sreenivasa

HI Board designers,

Refer below an example of the Key writer timing for a specific use case (could be used as an indication of the timing):

 The keywriting take about 250-300 ms. The keywriter size is 296KB with the Key blob and the above doesn`t include time needed to transfer the keywriter from host. Keywriter loading time from host to target depends on the boot media eg UART will be slow (115.2kbps) while USB DFU will be fast (400 MBps)

AM623: Duration of programming OTP in factory :How long (milliseconds?) does it take during production to program the OTP-values with the key writer app?

Regards,

Sreenivasa

HI Board designers,

Additional inputs on the VPP supply slew rate

Refer device specific data sheet section related to VPP 

7.9 VPP Specifications for One-Time Programmable (OTP) eFuses
This section specifies the operating conditions required for programming the OTP eFuses.
7.9.1 Recommended Operating Conditions for OTP eFuse Programming

Note:  The "VPP Slew Rate" parameter name is changed to to "VPP Power-up Slew Rate" to clarify the limit associated with this parameter only applies during power-up.

(+) [FAQ] AM623: Power-Up Sequencing for VPP? - Processors forum - Processors - TI E2E support forums

Regards,

Sreenivasa

Hi All,

Inputs regarding Key Write 

VPP keywrite
https://e2e.ti.com/support/processors-group/processors---internal/f/processors---internal-forum/1330047/faq-am64x---steps-to-build-key-writer

https://e2e.ti.com/support/processors-group/processors---internal/f/processors---internal-forum/1218339/am6442-questions-about-key-writer-etc

https://www.ti.com/lit/an/spracz6/spracz6.pdf

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1344678/sk-am62-lp-keywriter-debug-response-0x2000800-custom-keys

Processors_Security_Overview_v1.PDF

Regards,

Sreenivasa

HI Board designers,

Inputs regarding Key Write changes when an IO that is not similar to the IO used on the EVM or SK 

We enable the voltage via a GPIO pin from main. We can drive the GPIO pin in Linux code via gpiochip command and confirm that VPP pin is at 1.8V. 
When we use the GPIO code shown above by Hema, we CANNOT drive the GPIO pin high.

We understand that the eval board schematics uses a GPIO via a port expander to enable VPP. Our use case is much simpler, we just need to configure a pin to be an output and drive it high.

For any board revision, please follow the below procedure for controlling the VPP via the GPIO.

• The relevant GPIO pin is configured in the Sysconfig. This is required for auto generation of the pinmuxing code.
• The relevant GPIO is used in the `keywriter_setVpp` function.

FYI, please refer to the following response where a customer successfully controlled VPP via GPIO

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1339680/processor-sdk-am62x-am6231-hs-fs-varinant-otp-keywritter-support-for-convert-hs-fs-device-into-secure-device/5127460#5127460

Regards,

Sreenivasa

HI Board designers,

Here are some additional information on the use of LDOs FET switch 

I compared the behavior with the TLV75518 and TPS7A21-Q1 LDOs that we have been recommending.

The voltage seems to be within the ROC and the slew rate matches the data sheet requirement.

Kallikuppa Sreenivasa said:

They need to characterize their system by measuring the voltage on the processor VPP pin during programming and make sure it never drops below the ROC min limit for even the shortest period of time.  There are too many variables in the path of VPP to be sure without characterizing their implementation.

Regards,

Sreenivasa

HI Board designers,

AM623: Problem if VPP for OTP always on?

I recommends only applying power to the VPP pin during eFuse programming.

The GPIO controlled LDO adds another layer of protection for preventing rouge software from accidently burning fuses. Software would only need to write a few registers in the eFuse controller module to accidently burn fuses if VPP were always powered. When using a GPIO controlled LDO to source VPP, software would also need to write the appropriate value into the PADCONFIG register of the control module to enable the IO cell output function and also write appropriate values into multiple GPIO module registers to enable VPP. The GPIO controlled LDO VPP source significantly reduces the risk of rouge software accidently burning fuses.

Regards,

Sreenivasa

HI Board designers,

Refer below on using FET for VPP supply

e2e.ti.com/.../faq-am625-pmic-fet-to-control-1-8-vpp
AM625: PMIC + FET to control 1.8 VPP

My customer has a question about using an output from the TPS6593 PMIC + a FET to control ON/OFF for 1.8V VPP on the processor? They are trying to see if they can get by without using a dedicated LDO for 1.8V VPP.

It is very important for the AM62x VPP pin to remain in the Recommended Operating Condition (ROC) voltage range during efuse programming.

The VPP pin will have high current transients which can be problematic when trying to use a FET to source this pin from a fixed 1.8V supply. We recommend an LDO powered from a higher voltage supply because the LDO will be able to compensate for the voltage drop through its series pass transistor and maintain the correct operating voltage during the high current transients. Local bulk capacitors are likely needed near the VPP pin to assist the LDO transient response. We recommend customers characterize their specific VPP implementation and update their circuit design as necessary to ensure the AM62x VPP pin never drops below the min ROC value.

Note: The 1.8V source for VPP should have an internal active discharge function that gets turned on when the source is disable to ensure VPP is held to 0V during normal operation.

Regards,

Sreenivasa

HI Board designers,

FAQ supporting key write

(1) Is the GP device delivered with the X product number different from the HS-FS device as a silicon chip?

(2) Is it HS-FS or HS-SE shipped from the TI factory?

(3) In the HS device that TI is going to mass produce, in which mode will the eFuses be set/not set?

　　set eFuse: HS-FS?

　　no set eFuse: HS-SE?

(4) Is the eFuse set using VPP as described in DATASHEET 7.8?

(5) Is the HS-FS device fully compatible(hardware specification) with the GP device?

A1 GP is different from HS-FS
A2 Starting from AM64x SR2.0, only HS-FS is orderable by customers
A3 HS-FS
A4 Yes, "7.8 VPP Specifications for One-Time Programmable (OTP) eFuses" is VPP electrical specification. OTP Keywriter tool is provided by TI for customers to program customer's key set on HS-FS to convert it to HS-SE to enforce secure boot.
A5 HS-FS "functions" as GP if no customer's key set is programmed.

The reading list on AM64x SR2.0
1. FAQ
e2e.ti.com/.../faq-processor-sdk-am64x-am64x-am243x-sr-2-0-device-type-transition
2. Linux SDK
software-dl.ti.com/.../Foundational_Components_Migration_Guide.html

(1') Is the GP SR2.0 different from the HS-FS SR2.0 as a silicon chip?
   （Is the base silicon chip the same?)

No, it is the same silicon.

There’re essentially two different OTP efuse farm:
1. The security key material: programed by user with OTP keywriter tool at factory time, and used by boot rom during boot time as an ancho to enable root-of-trust secure boot. The security key are specified in the K3 Security TRM addendum which is accessible from the AM62x security resource download link which was shared in my last e2e post.
2. The extended OTP area: programmed by user with either OTP keywriter tool at factory time, or TIFS TISCI API during run-time. For AM62x, the extended OTP efuse farm is 1024 bits.

We have AM62x security resource download portal, where security collaterals/links/tools... are hosted
User may request access to AM62x security resource download portal with the link
https://www.ti.com/drr/opn/AM62X-RESTRICTED-SECURITY

There're dedicated on-chip OTP efuse for storing customer key materials plus additional general extended OTP efuse area.
You'll find more details in "Chapter 8 One-Time Programmable Security Keys and Values" in K3 Security Hardware Architecture TRM.
dr-download.ti.com/.../SPRUIM0C-C-windows-installer.exe

We have AM62x security resource download portal, where security collaterals/links/tools... are hosted
You'll find more details in "Chapter 8 One-Time Programmable Security Keys and Values" in K3 Security Hardware Architecture TRM
software-dl.ti.com/.../SPRUIM0C-C-windows-installer.exe

User may request access to AM62x security resource download portal
https://www.ti.com/licreg/docs/swlicexportcontrol.tsp?form_id=337827&prod_no=AM62X-RESTRICTED-SECURITY&ref_url=ep_processors_Sitara-MPU

The extended OTP efuse is primary designed for customer optional usage, and they're not used by on-chip secure rom code in RoT (Root-of-Trust) secure boot flow.

AM623: Problem if VPP for OTP always on?

TI recommends only applying power to the VPP pin during eFuse programming.

The GPIO controlled LDO adds another layer of protection for preventing rouge software from accidently burning fuses. Software would only need to write a few registers in the eFuse controller module to accidently burn fuses if VPP were always powered. When using a GPIO controlled LDO to source VPP, software would also need to write the appropriate value into the PADCONFIG register of the control module to enable the IO cell output function and also write appropriate values into multiple GPIO module registers to enable VPP. The GPIO controlled LDO VPP source significantly reduces the risk of rouge software accidently burning fuses.

"TI recommends only applying power to the VPP pin during eFuse programming."
Please refer to AM62xx datasheet for more details.
7.9.2 Hardware Requirements
The following hardware requirements must be met when programming keys in the OTP eFuses:
• The VPP power supply must be disabled when not programming OTP registers.
• The VPP power supply must be ramped up after the proper device power-up sequence (for more details, see
Section 7.11.2.2, Power Supply Sequencing).
7.9.3 Programming Sequence
Programming sequence for OTP eFuses:
• Power on the board per the power-up sequencing. No voltage should be applied on the VPP terminal during
power up and normal operation.
• Load the OTP write software required to program the eFuse (contact your local TI representative for the OTP
software package).
• Apply the voltage on the VPP terminal according to the specification in Section 7.9.1.
• Run the software that programs the OTP registers.
• After validating the content of the OTP registers, remove the voltage from the VPP terminal.

1. Do you have to program the whole thing at once or can it be split into blocks?
2. Is the main purpose for the security keys or can they store some other information in there as well?

1. It is possible to program keys in one-shot or incrementally.
2. There're extended OTP area for user's own usage...
e2e.ti.com/.../faq-how-to-program-the-extended-otp-efuse-on-am6x-soc
e2e.ti.com/.../faq-how-to-update-ids-usb-pcie-pid-vid-mac-id-by-programming-extended-otp-on-am6x

We have AM62x security resource download portal, where security collaterals/links/tools (i.e. OTP keywriter)... are hosted
software-dl.ti.com/.../AM62x_HS_index_FDS.html
User may request access to AM62x security resource download portal
www.ti.com/.../swlicexportcontrol.tsp

AM62P5-Q1: UART used and related pins for OTP key writer?

User has choice of using any ROM supported boot mode/media to boot OTP keywriter binary.
Yes, you're right UART0_RXD (A22) & UART0_TXD (B22) are needed for UART boot mode.

The device transitions from HS-FS to HS-SE only if Customer Keys Revision register is non-zero and Customer Keys Count register is non-zero. Writing of the EFUSE keys Secondary Master Public Key (SMPK)/Back-up Master Public Key (BMPK) will not change the HS-FS to HS-SE.

Yes, both KEY_REV and KEY_CNT need to be non-zero.

There're dedicated on-chip OTP efuse for storing customer key materials plus additional general extended OTP efuse area.

(+) [FAQ] How to program the extended OTP efuse on AM6x SoC - Processors forum - Processors - TI E2E support forums

There're two options to program the extended OTP efuse:
1. OTP keywriter
- It is used in the factory for programming the user's secure RoT keys, key revision and key count on a HS-FS (High Security - Field Securable) device
- It can be used to program the extended OTP efuse at the same time
- a HS-FS is converted to HS-SE (High Security - Security Enforced) once the key revision and key count are programmed on HS-FS
- It runs ONLY on a HS-FS device, but not HS-SE

2. SYSFW (System Firmware)
- SYSFW provides API that can be used to access and modify the extended OTP efuse on HS-FS and HS-SE device
- SYSFW is not a standalone executable and must be used along with software running on another core to access or modify the extended OTP efuse.
- SYSFW runs on HS-FS and HS-SE

VPP
- VPP electrical specifications in datasheet
7.7 VPP Specifications for One-Time Programmable (OTP) eFuses in AM62A datasheet
7.8 VPP Specifications for One-Time Programmable (OTP) eFuses in AM64x datasheet
7.9 VPP Specifications for One-Time Programmable (OTP) eFuses in AM62x datasheet

VPP=1.8v "ON/OFF" needs to be user’s SW controllable whenever OTP efuse programming is required. Depending on VPP is from LDO or PMIC, VPP "ON/OFF" can be controlled or configured by GPIO...in user's SW. For example, VPP circuitry on TI AM6x reference boards:
- LDO output from TLV75518 on AM64x EVM, AM64x-SK, and AM62x-SK
- VOUT_LDO2 of PMIC TPS6593 on AM62A-SK

The extended OTP efuse read/write access by SYSFW
software-dl.ti.com/.../extended_otp.html

The extended OTP TISCI APIs
software-dl.ti.com/.../extended_otp.html
Note that
- The extended OTP efuse TISCI API message type is "Secure" on "Secure Queue Only" as noted below
Message Type | Secure
Secure Queue Only? | Yes
- The secure message and queue is essentially equivalent to extended OTP efuse TISCI API needs to be called by "virtual secure host" as listed in
AM64x
software-dl.ti.com/.../hosts.html
AM62x
software-dl.ti.com/.../hosts.html
AM62A
software-dl.ti.com/.../hosts.html

Note#1: User may request access to AM64x/AM62x/AM62A security resource download portal (i.e. including OTP keywriter tool) via
- AM64x security resource portal request
www.ti.com/.../swlicexportcontrol.tsp
- AM62x/AM62A security resource portal request
www.ti.com/.../swlicexportcontrol.tsp

(+) AM625: Migration from non-secure to secure devices - Processors forum - Processors - TI E2E support forums

Can a non-secure device be replaced by a secure device without any hardware design changes by designing the VPP to be powered when programming the OTP keys after the proper device power-up sequence?yes

Are the configurations of Boot Mode Pins the same between non-secure and secure devices?yes.

How to check if device type is HS-SE, HS-FS or GP?

(+) [FAQ] [AM6XX]: How to check if device type is HS-SE, HS-FS or GP? - Processors forum - Processors - TI E2E support forums

Here is the link of the OTP Keywriter tutorial as well: https://dev.ti.com/tirex/explore/node?node=A__AagJ-8QGXM582KzTgxFZbA__AM62-ACADEMY__uiYMDcq__LATEST

(+) PROCESSOR-SDK-AM62X: [AM6231][HS-FS Varinant] [OTP keywritter] Support for Convert HS-FS device into secure device - Processors forum - Processors - TI E2E support forums

(+) AM623: How to hard reboot after revoking key - Processors forum - Processors - TI E2E support forums

It is good to know you're able to perform key revoke by adding OPTEE applicant (user TA and PTA).
The physical OTP efuse farm requires one-time SoC Power-On-Reset (POR) to have the OTP efuse auto-scan functional.
I think it is a common practice to power-cycle any electronic devices after firmware update.

AM62P has the same customer programmable efuse area as AM62x/AM62A 

 Customer is asking question for OTP key writer.

(+) AM623: efuse - Processors forum - Processors - TI E2E support forums

I would like to ask if I use keywriter to write SMPK to efuse, but KEYREV and KEYCNT are not written to efuse at this time, so am62x is still an HS-FS device.

Can I write a new SMPK value to efuse again next time? In other words, can efuse be programmed repeatedly in the HS-FS state, and similarly, can 1024-bit OTP be programmed repeatedly?

You'll find more details on OTP efuse in "Chapter 8 One-Time Programmable Security Keys and Values" in K3 Security Hardware Architecture TRM
software-dl.ti.com/.../SPRUIM0C-C-windows-installer.exe

li weiyu said:

After programming, can the data inside OTP be read multiple times?"

1. Re-enable JTAG 
   1. Is it possible to enable JTAG by eFUSE after disabled JTAG by eFUSE?  (I think it impossible due to one time memory. But allow me to double check with expert)  
2. OSPI boot
   1. Is it possible to boot and run OTP key writer from OSPI boot?  (According to user's guide, it looks possible)
3. Call from user's application
   1. Is it possible to call OTP key writer from user application? 
   2. If the above is yes, how customer should implement OTP key writer in their application and call it?

1) No, it's not possible to enable JTAG after permanently disabling it.

2) Yes, the OTP Keywriter can be booted from any ROM supported boot media.

3) No. The keywriting procedure must be done with the provided standalone keywriter package.

Does the Key writer binary use DDR memory?

I need information necessary for manufacturing H/W equipment related to Key fusing at the production facility.

I think the S/W module is assumed to use internal memory. The Key writer is using the platform module included in the TI SDK as is.

Keywirter get loaded to OCMC RAM, no involvement of DDR. You can look refer to memory map for the same.

I don't see otp key writer and user guide for AM243x in secure resource page. Is it available?

It is available at the following secure portal

https://www.ti.com/secureresources/AM243X-RESTRICTED-SECURITY

The access to it have to be requested using the following link:

www.ti.com/.../AM243X-RESTRICTED-SECURITY

Is it possible to include both OTP keywriter together with boot loader, RTOS and Linux rootfs? When boot up 1st time, OTP keywirter runs and program keys. 2nd time or after, boot Linux and RTOS runs. Is it possible to support this use-case?

As another way, is it possible to program keys in OTP using JTAG? After OTP is programmed, JTAG is disabled, so there is no security risk for the path to program OTP keywriter.  This is ideal case for Muratec. After that, only boot loader, RTOS and Linux runs.

1) It is not possible.

2) Yes, the keywriter can be run over JTAG as well.

Do you have any document which shows how to run OTP keywriter over JTAG?

This is mentioned in the OTP Keywriter user guide. If the customer doesn't have access to the keywriter package, they may request the same with: https://www.ti.com/drr/opn/AM64X-HS-RESTRICTED-SW

Once the access is granted, the resources would be available at: www.ti.com/.../AM64X-HS-RESTRICTED-SW

(+) AM62A7: SecureBoot - OTP Key Writer - Processors forum - Processors - TI E2E support forums

We have found the answer, it is the problem with version.

the version of otp_keywriter_am62ax-linux-installer.run is 09.00, and it recommends the mcu sdk version is 09.00

Now, we can run otp key writer successfully

(+) SK-AM62A-LP: Key Storage - Processors forum - Processors - TI E2E support forums

AM62A Linux SDK supports OPTEE, where the OPTEE secure storage is supported with the HUK enabled with AM62A SoC KEK key (unique per device).

You may explore further how to use the OPTEE secure storage to enhance LUKS cryptsetup utility for key management, and here're some reference.
https://docs.foundries.io/95/reference-manual/linux/linux-disk-encryption.html
https://static.linaro.org/connect/san19/presentations/san19-413.pdf

(+) [FAQ] How to update IDs (USB & PCIe PID/VID, MAC ID) by programming extended OTP on AM6x - Processors forum - Processors - TI E2E support forums

How to update IDs (USB & PCIe PID/VID, MAC ID) by programming extended OTP on AM6x

Below diagram shows ROM's interpretation of extended OTP region for IDs. Upon SoC RESET, ROM reads extended OTP array from the end to determine if various device IDs (USB VID/PID, PCIe VID/PID, MAC ID) are programmed into the extended OTP efuse. If the extended OTP data matches the ID update magic word then ROM will process the values from the extended OTP efuse, and updates these values into control MMRs (See TRM for control MMRs for USB, PCIe, MAC ID).

Fig.1 AM62x/AM62A with 1024 bits extended OTP efuse

Fig.2 AM64x with 384 bits extended OTP efuse

LOCK ECU TO HSSE Questions

Q1 : If I locked the ECU to HSSE using TI key , Is there anyway to write another key (customer key ) on the same ECU?

Q2:If I locked the ECU to HSSE using Customer key , What shall be the steps to can flash the ECU again using DFU?

1/. Once HS-FS is converted to HS-SE after programming the OTP key (either the TI testing key or the customer key) with the OTP key programming tool, it is impossible to run OTP key programming tool on HS-SE to program OTP key further.
2/. On HS-SE, it is possible to boot the binary which is signed with the matching key set (programmed to OTP efuse) from any rom supported boot mode, i.e. USB-DFU, eMMC, xSPI...

we are using the USB-DFU mode , and using the files below for flashing the ECU in factory.

tiboot3.bin -> tispl.bin -> u-boot.img

Which one of these image need to be signed with the matching customer key ?

I think the images that we have already signed by TI Key , so can you please share with us the unsigned image? or any further steps needed ?

This is the Linux SDK link on how to sign/boot the signed binary for your reference
https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/10_01_10_04/exports/docs/linux/Foundational_Components_Migration_Guide.html

(+) AM6412: Read/Write to Extended OTP from Linux - Processors forum - Processors - TI E2E support forums

It is  good to know you had the extended OTP read/write via OPTEE working on your setup.
Yes, it is required to power-cycle SoC to autoload/scan the OTP efuse to MMR registers after the OTP write operation.

(+) Factory occupancy of external otp efuse space - Processors forum - Processors - TI E2E support forums

1/. The extended OTP area on AM62x is 1024 bits available for customer to use.
refer to <Table 8-4. Extended OTP Physical Row Bit Mapping - Devices with SMS> in K3 HW Security TRM on the extended OTP physical row layout
2/. The extended OTP area is not programmed at TI fab, and is not used by ROM.

This is the link for K3 HW security TRM on AM62x security resource download portal.
dr-download.ti.com/.../SPRUIM0C-C-windows-installer.exe

(+) PROCESSOR-SDK-AM64X: What is the purpose of aes256.key? - Processors forum - Processors - TI E2E support forums

(+) AM623: Read Extended OTP from linux application - Processors forum - Processors - TI E2E support forums

In general, extended OTP RD/WR access is via TISCI API
https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/extended_otp.html
https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/security/extended_otp.html

On the special IDs (USB & PCIe PID/VID, MAC ID) which are optionally programmable in the extended OTP
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1235880/faq-how-to-update-ids-usb-pcie-pid-vid-mac-id-by-programming-extended-otp-on-am6x
"The default ID values can be optionally updated by programming the extended OTP efuse. If the ID update magic word is programmed by user and found from the extended OTP area by ROM then ROM process and update the ID register values with the programed ID values from the extended OTP area."

These special IDs are RD/WR accessible via CM MMR once autoloaded by ROM after RESET.

we want to write One-Time Programmable (OTP) efuses in the factory for programming the our secure RoT keys

How can we check if the writing was successful?

 Is there a register to store the write results?

There's a return status when programming RoT keys with OTP Keywriter via calling TISCI API "TISCI_MSG_KEY_WRITER"
https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/security/keywriter.html#sec-api-keywr-program-keys

AM625: OTP and Extended OTP

• It says in the AM62x security overview that general OTP writes 1024-bits. What is it writing?

• What is extended OTP and what does it do in addition to the regular OTP?
  • Is there a difference in VPP need for OTP vs extended OTP?

You'll find more details in "Chapter 8 One-Time Programmable Security Keys and Values" in K3 Security Hardware Architecture TRM
software-dl.ti.com/.../SPRUIM0C-C-windows-installer.exe

Some reference on programming extended OTP efuse area:
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1235859/faq-how-to-program-the-extended-otp-efuse-on-am6x-soc

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1235880/faq-how-to-update-ids-usb-pcie-pid-vid-mac-id-by-programming-extended-otp-on-am6x 

(+) SK-AM62-LP: sequence for enabling secure boot using custom keys - Processors forum - Processors - TI E2E support forums

I use the AM62X EVM and want to enable HS-SE with custom keys.

I was able to build the tiboot3.bin from the SDK and using the TI development keys. I have NOT run it on the board, so no eFuses are burnt yet.

Moving forward with custom keys, this are my steps:

# 1 Generate a new set of keys:
./gen_keywr_cert.sh -g

# 2 In the keys folder I get:
aes256.key bmek.key bmpk.pem smek.key smpk.pem

# 3 Make the One Shot certificate, specifying SMPK as the certificate for secure boot
./gen_keywr_cert.sh -t tifek/ti_fek_public.pem -a keys/aes256.key --msv 0xC0FFE --bmpk keys/bmpk.pem -b-wp --bmek keys/bmek.key --bmek-wp --smpk keys/smpk.pem --smek keys/smek.key --keycnt 2 --keyrev 1

# Output:
1668 secondary_cert.bin
5380 primary_cert.bin
7048 ../../x509cert/final_certificate.bin

# 4 Convert the bin, produce the keycert.h:
python3 ~/ti/mcu_plus_sdk_am62x_09_01_00_39/tools/bin2c/bin2c.py final_certificate.bin keycert.h KEYCERT

# 5 Build the tiboot3.bin
ti-arm-clang$ make -sj clean PROFILE=debug
ti-arm-clang$ make -sj PROFILE=debug

# Output:
ti-arm-clang/sbl_keywriter.debug.tiimage Done !!!
ti-arm-clang$ md5sum tiboot3.bin
db3eca1de8d2e0ccb811016691a265c8 tiboot3.bin

# 6 Install the custom signing key in the u-boot source tree, replacing the TI development key:
copy keys/smpk.pem to board/ti/keys/custMpk.pem

# 7 Rebuild u-boot, now signed with the new custom key.

# 8 The tiboot3.bin is loaded by dfu boot, it is executed and burning the eFuses.

# 9 After a board reset the CPU state is now HS-SE and only my new signed u-boot will execute.

Is this procedure complete and valid?

Additional questions:
Q1. Two sets of keys are loaded, my keyrev specifies 1 (SMPK). When is the BMPK used then?
Q2. Should I leave board/ti/keys/custMpk.crt and board/ti/keys/custMpk.key untouched?

Your summarized steps for programming OTP efuse and signing u-boot looks good.

Some reference on your questions:
https://e2e.ti.com/e2eprivate/processors-security/processsors_security_support/f/processsors-security-support---forum/1202686/faq-am6442-how-to-use-the-tisci-apis-read_keycnt_keyrev-write_keyrev-to-activate-the-backup-key-set
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1294191/am625-what-is-the-function-of-custmpk-crt-file-how-to-generate-this-file-using-customer-own-key
Fyi, I sent an invitation for you to join the special security e2e forum to discuss security related questions.

Here is a summary on authentication flow on HS-SE (Security Enforced)
1a/. hash(SMPK) check against SMPK-H programmed in OTP eFUSE
1b/. the self-signed x.509 certificate is verified with the SMPK embedded in the x.509 certificate
2/. the hash(binary blob) is checked against the hash in the x.509 certificate

On HS-FS, 1a/ is skipped which makes the self-signed x.509 certificate verification pass on HS-FS as expected.

I want to know how to disable debug port ohter than JTAG.

Is AM62P possible to phycically disable debug UART and other interfaces used for debugging?

It means the same as disabling with eFuse, like JTAG for example.

It is feasible to have peripheral not functional in SW by not providing clock to the peripheral.
But it is impossible to physically disable peripherals (i.e. UART port) via OTP efuse.

(+) AM6442: How to Lock the JTAG without enabling Secure Boot? - Processors forum - Processors - TI E2E support forums

It is impossible to lock JTAG on HS-FS device.

On K3 HS-SE
A. JTAG debug port is disabled/locked by default.
B. JTAG debug port is unlockale using the JTAG unlock certificate

In addition, there is a programmable eFuse field that will permanently disable JTAG unlock process on HS-SE [#B above]
=> this is not applicable for HS-FS.

(+) [FAQ] AM623: AM623 Efuses - Processors forum - Processors - TI E2E support forums

On K3 SoC, user needs to program the user's own key set on HS-FS to convert HS-FS to HS-SE to enable secure boot.

To summarise: customer needs to blow the e-fuses, TI cannot do it for you.

Have I got that right?

Yes, you’re right

Additional information

Jacinto7 High Security Device Development

https://www.ti.com/lit/an/sprad04/sprad04.pdf

Regards,

Sreenivasa