AM623: Read Extended OTP from linux application

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.
Best,
-Hong

Hi.

When you say access is via TISCI API, I'm trying to wrap my head around how to use that, what needs to be built for which CPU. I have a linux commandline application which I guess needs to use the TISCI API to read extended OTP data. I'm trying to figure out how to add the relevant source files and include the proper header files, but I'm not sure exactly how to go about it. When I look at some of the code in the MCU PLUS SDK for sciclient etc I get the impression this is code meant for the R5 and/or the M4. The code layout and structure isn't clear to me and I'm just not sure how to get started trying to read extended OTP from a linux application running on the A53. Is there a more specific guide for this?

Is there any example just showing how to use TISCI API from a linux application?

Linux kernel TISCI driver code for your reference, you'll have to add code for accessing extended OTP.
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/firmware/ti_sci.c?h=09.02.00.010
https://git.ti.com/cgit/ti-linux-kernel/ti-linux-kernel/tree/drivers/firmware/ti_sci.h?h=09.02.00.010
Best,
-Hong

I interpret this as that there is a TISCI driver, but it has no support for Extended OTP messages. Looking at it I can not find any reference to Extended OTP.

The issue is that we don't know how the existing TISCI driver works and how it's being used from userspace at the moment. Once we have an idea of the existing usage and what is not supported, we can start trying to use it ourselves to test basic things that are supported, then start looking at what needs to be added for Extended OTP.
It would be highly valuable for us if there was a more hands-on introduction to TISCI driver use from linux userspace.

In your original post
"As I see it's possible to read e.g. the MAC_ID0 register from an application by doing an mmap to 43000200h,..."
I also received the offline email from TI field team on your question
"... At the moment it is not a Secure Boot thing, I think it’s more about a serial number..."
Will you elaborate your user case? Are you looking for a unique serial number?
Best,
-Hong

Hi,
Yes. We have programmed a custom 16-byte persistent non-secure sequence of data to OTP using the Keywriter and tiboot3.img approach (we think, because we haven't been able to verify it yet). We then want to read it back from a linux userspace application once that has been flashed and booted.
The existing driver code hasn't given a lot of hints on how it's used or from where.

We did recently find an application called k3conf which does use TISCI. However it appears k3conf is not using secure channels (seems required for the OTP messages), so we're trying to modify it until we can read the Extended OTP data using it. From what we can tell though, that application isn't using any of the tisci drivers and it has a lot of support code for generating headers and transferring data etc.

Do you know this application and does this seem like a reasonable way forward, or is there a good example of how to use the tisci driver you pointed to earlier?

The standalone k3conf might be an option, where some TISCI APIs (mainly on clock) are supported as listed
https://git.ti.com/cgit/k3conf/k3conf/tree/include/tisci_protocol.h?id=85a7433202aafafbccea8a7b2491f4df8b1ecd80#n42
One caveat is calling these clock related TISCI APIs doesn't requires from "secure host".
But calling the TISCI APIs for the extended OTP WR/RD requires "secure host".
https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/security/extended_otp.html#sec-api-ext-otp-read-otp-mmr

Peter Mörck said:

We have programmed a custom 16-byte persistent non-secure sequence of data to OTP

Do you want to provision the same customer 16-byte data to all SoC?

There's SoC generated SoC_UID (32-bytes) which is unique per each SoC, and one of SoC_UID usage is using it as a unique serial number.
SoC_UID is accessible several ways, and one option is reading SoC_UID via TISCI API
https://software-dl.ti.com/tisci/esd/latest/6_topic_user_guides/secure_debug.html#retrieving-the-soc-uid-via-tisci
https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/security/runtime_debug.html#get-soc-uid
where the TISCI API "TISCI_MSG_GET_SOC_UID" is callable from "any host".

If SoC_UID is applicable to your requirement/user case, it is possible to add calling "TISCI_MSG_GET_SOC_UID" in k3conf.

Best,
-Hong

Hi,

We've managed to change the sec-cfg.yaml in u-boot to allow reads of the first 4 "words" (that should be 4x32 bits = 16 bytes) as I understand they are handled as word length, not OTP row length.

We also changed k3conf and added a security header to the tisci message with all zeros before the regular header. We also changed the soc id to 10 (instead of 13, to use secure host id). It seems all code we find related to reading and writing the checksum of the security header say "todo", so presumably nothing is checked anywhere... 

After adding the new message id for otp read and the proper stuctures, we do manage to make ONE read request. It returns the expected first 4 bytes from the OTP.

However all subsequent read requests sent return a NAK. Is there an extra step that is required between secure reads? The other examples in k3conf seem to perform a series of reads without issue, so I'm wondering if there's anything extra that needs to happen after a secure data transaction.

K3conf is developed for calling TISCI APIs (clock etc...) from "non-secure host".
It might require more code changes in K3conf to enable calling TISCI APIs from "secure host".
Is SoC_UID applicable for your use case?
Best,
-Hong

Again, we were able to successfully read the first word (4 bytes), i.e. index 0, of the Extended OTP and the first response returned the first 4 bytes I programmed with OTP Writer.

However, reading any other index causes a NAK response. It doesn't matter if we loop through the index range backwards from 31 to 0. It's always index 0 that works, regardless if it's the first or last one read.

So we can only assume that our attempts at applying the security changes work, since we DO get a valid response with the correct data for Extended OTP index 0, but NAK for others. Do you know if this actually works in the API and on the "other side" ? I mean considering the checksum functionality hasn't been implemented (all 0s) I'm wondering if reading the Extended OTP is also perhaps not properly implemented yet, or is it? It just seems weird that it works for index 0, but no other...

Also, regarding SOC UID. Where is that value generated? We need a value that is persistent even if the device is reflashed. So if it's randomly generated at compile or flash time, it's not good enough. Or is it something we have to supply once we start switching to secure boot and using x509 certificate?
We basically just need a persistent 16-byte number that is unique to each individual device.

BR,
Peter

Peter Mörck said:

We basically just need a persistent 16-byte number that is unique to each individual device.

I'd recommend to consider SOC_UID. Using SOC_UID eliminates extended OTP programming process which I think is not easy task for SW to manage OTP programming a unique number per SoC.

I added a new FAQ which gives an example on how to read SOC_UID from OPTEE.
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1383076/faq-am625-how-to-read-soc_uid-on-am6x-soc
The TISCI API for read SOC_UID is callable by any "host" - secure or non-secure.
Hopefully the FAQ is helpful to port it to K3conf...
Best,
-Hong