1. What is the OTP hardware unique key field?
>> A unique value that customer can program. This can be used for customers to identify the part with a key they programmed solely for that purpose.
2. What is the OTP endorsement key field?
>> It is meant to be used with ARM trusted platform. The BOOT process or the part as such does not use it and it is purely an application dependent key.
3. What is the stage ID OTP field?
>> This is a space left in the OTP for the customer to define their platform either as Release mode, evaluation mode etc. Boot kernel does not touches this space. So programming this will have no impact on booting and is entirely left for the user to decide on how they want to use this space.
4. What is Public and Encryption (Private) Key in OTP Space?
>> There are two instances of public keys and four instances of encryption keys in the OTP space available. By default, the public_key0 field and the pvt_128key0 field are used for authentication and decryption of the secure boot stream. In order to use the other instances of the keys, like public_key1 and pvt_128key1, the previous instances need to be invalidated in the OTP space by setting the pubkey0Inv and privkey0Inv bits in the OTP space using the OTP Program API.
All the public and private keys can be invalidated using the various key*Inv fields provided in the ADI_ROM_OTP_BOOT_INFO structure, which is useful when a new key is required, as the boot ROM will always use the lowest valid key enumeration. If key0 is valid, then it is used, if key0 is invalid and key1 is valid, then key1 is used.
Once a key is invalidated, it cannot be used again
5. Does the boot ROM do anything to protect against memory-mapped I/O access of the OTP or OTP controller in order to bypass use of the OTP API when locked?
>> No, OTP access will always be there, though only core can access. Other peripherals or bus masters cannot access it.
6. Can all OTP fields be read via the OTP API by a booted program when the locked bit is set? If not, which fields can be read?
>> All the fields in customer area can be read.
7. Can unprogrammed OTP fields be written via the OTP API by a booted program when the OTP is locked?
>>Yes. Booted program can still write via API.
8. What OTP fields are accessible via the emulator when in the OTP is locked but the emulator has entered the correct password and the status is reported as unlocked?
>> Once part is successfully connected to debugger with security keys matched, all resources can be accessed.
9. Can the public and private key invalidate bits be set after the OTP is locked? If not, then what is the purpose of the redundant/replacement keys? If so, loss of power or system reset anytime when software is signed or encrypted with a key that is not active will result in a bricked unit (there is a window of vulnerability between the time that an invalidate bit is set and a program is stored in flash that is signed/encrypted with the right keys).
>> Its actually part lock. Program first the new available key out of 4 private keys. Then program invalidate bit. Even if invalidate bit is screwed during supply loss, there can be 2 cases. Either 1 or 0. If 1, use new key, if 0, use old key. But beyond that, there is no specific hardware detection for OTP programming during power loss.
10. Are the factory serial number and general purpose areas considered part of the "customer" data that can be read via the API even when the OTP lock bit is set?
>> Factory Serial Number is not a part of Customer OTP space. General purpose area is a part of customer data.
11. What can you do from the emulator when the OTP is locked and the correct password has NOT been entered? (Can you read anything from the OTP such as the factory serial number?)
>> Without password, the JTAG will not allow access to a locked part at all.
12. Can we program individual words of a field at different times (by setting the values to zero for words to avoid programming)? For example, can we program some but not all of the general purpose area 1 words and later program the previously unprogrammed words?
>> Yes this is possible. You have to make sure, the from the offset of the GP space, each 32 bit data is programmed at once. That way other spaces can be left as 0, and can be programmed later. So the write to the OTP space needs to passed as 32 bit value.
13. The public authentication keys occupy 16 32-bit words each in OTP though only 7 words are used. If the unused words are programmed to non-zero values will it interfere with authentication or are the unused words ignored by the boot ROM for the purposes of authenticating the signature on a boot stream?
>>The public authentication key comprises of two parts(Qx and Qy) each of 224 bit. So total 14 , 32 bit space will get programmed in the space allocated for public key in OTP space. It is not recommended to use the left over 2 , 32 bit words for some other purpose and it should be left as zero only.
14. Is anything done in the secure boot ROM to prevent inadvertent access to the OTP controller or memory mapped locations between OTP API calls? In other words, could a bug in a program inadvertently cause a write to OTP and possibly corrupt a key or set a key disable bit so that the current program in flash is no longer bootable?
>>The API to program the OTP space provided takes care to not program the OTP space again if it was previously programmed with some non-zero value. So any inadvertent access to the already programmed OTP space will not cause any issue. Care must be taken in programming the OTP space for the first time.
15. Do we need to program the SPI boot command (i.e., 0x207) into the OTP for the ROM to successfully boot a secure stream from SPI flash? Or are there methods that will allow this to happen without programming the OTP (such as default settings in the ROM or embedded settings in the boot stream)?
>> By default the SPI2 master boot happens with dbootcommand 0x207 irrespective of whether it is a normal boot or secure boot. The user need not program the dbootcommand in the OTP if they are fine with the default configuration.
16. What are the default clock settings for initial secure booting from external flash? Will we have to program the CGU to get anything other than running at the external crystal rate for the initial boot (of our secondary loader)?
>> The default clock is CCLK:100MHz, SysClk:50Mhz and SCLK:25MHz. So for this case, if booting is done via SPI2 master boot in Quad mode, the SPI CLK will be 12.5MHz. In order to increase the clock, the OTP space corresponding to CGU can be programmed in order to boost the processor boot speed.