OTP MAC, OTP Serial Number Topic is solved

If you have a simple question and just want an answer.
User avatar
Sebastian
Active Member
Posts: 39
Joined: Wed Jul 20, 2016 9:15 am

OTP MAC, OTP Serial Number

Post by Sebastian »

Hello,

I have a little misunderstanding with OTP memory.

First I used xburn to programm the MAC Adr.

xbrun --target XEF232-1024-FB374-C40 --mac-address 00:10:zz:40:00:01

With
otp_board_ifno_get_mac,
I was able to read out the MAC Adr. So all fine.

Then I programmed a serial number with

xburn --target XEF232-1024-FB374-C40 --serial-number 106954753

Now I wasn't able to read out the MAC Adr. still the Serial Number.

The xburn --read prints:
Core 8:
*
0x000007fd: 0xzz400001
0x000007fe: 0x06600011
0x000007ff: 0x4007ffff
SR : 0x00000080
Core 9:
*
0x000007fd: 0xzz400001
0x000007fe: 0x06600011
0x000007ff: 0x4007ffff
SR : 0x00000080
Core 10:
*
0x000007fd: 0xzz400001
0x000007fe: 0x06600011
0x000007ff: 0x4007ffff
SR : 0x00000080
Core 11:
*
0x0000077e: 0x20000000
*
0x000007fd: 0xzz400001
0x000007fe: 0x06600011
0x000007ff: 0x4007ffff
SR : 0x00000080

Could I use xburn only one time?
xburn target --mac-address mac --serial-number serial


Best Regards,
Sebastian


View Solution
User avatar
Sebastian
Active Member
Posts: 39
Joined: Wed Jul 20, 2016 9:15 am

Post by Sebastian »

Hi everyone,

I'm really sorry for this stupid questions, and my post above.
But I could not found enough information about the OTP.
Maby someone knows where I could find an datasheet for it?
I only find information in the datasheet of the XEF232 device, OTP reading library, xburn command-line and Design Advisory: xCORE-200 eXplorer Kit MAC address programming.

I really want to understand it.

1) Means OTP, one time programable for one memory cell/row like 0x000007fe, or the
whole OTP range of an tile?

I have analyzed the OTP content before burn the Serial Number, and after that.

zz is always the same number.
First I burn the MAC ADR with:
xburn --target XEF232-1024-FB374-C40 --mac-address 00:10:zz:40:00:01
0x000007fd: 0xzz400001
0x000007fe: 0x00000010
0x000007ff: 0x4847ffff
SR : 0x00000000
So it looks like row 7fd contains the mac_adr[2] .. mac_adr[5].
And row 7fe contains mac_adr[0] .. mac_adr[1].
Row 7ff, the header: (header >> 22) &0x7 = one mac address saved. All fine.

On next Step I use:
xburn --target XEF232-1024-FB374-C40 --serial-number 106954753
106954753 is 0x6600001
Now the content of the OTP is:
0x000007fd: 0xzz400001
0x000007fe: 0x06600011
0x000007ff: 0x4007ffff
SR : 0x00000080
So row 7fd look the same like above.
Row 7fe contains the Serial Number + parts of the mac ADR.
--serial-number | Writes a 32-bit serial number to the end of the OTP
The Row 7fe makes sense with this description.
Mac_adr[0 .. 1] and the LSBs Serial Number looks combined. Overwritten?

2) Could it be, that the order of the xburn commands is neccesary?
On the other hand. Is it the better way to generate an xe-file with --make-exec
and then burn the whole OTP memory at once?

3) SR: 0x00000080 means that the Enables redundant rows in OTP is active.
What is the meaning about this bit?


I'm really sorry for my bad english and stupid queastions. But currently I want to use the OTP for Serial Number, MAC adr and crypto++.
I think I have "crashed" the OTP of that board. And after this failure, I really want to understand what I have done wrong.

So If someone could give me some advice, it would be absolutely nice.


Best Regards,
Sebastian
henk
Respected Member
Posts: 347
Joined: Wed Jan 27, 2016 5:21 pm

Post by henk »

Hi Sebastian,

xburn programs OTP without state; i.e., it does not know what is in OTP, and writes the data. If you program a serial number at the end of OTP, it will do so. If you program a mac address, it will probably write that at the same location, and fail. I imagine that a run with both parameters will write both a serial number and a mac address one after the other, in the order in which they appear; this is also a method used to write multiple mac addresses when required.

On a more fundamental level: how OTP is used is up to the end-user, i.e., yourself. You can store a serial number in it, mac addresses, a JPG, or other things; a bit like RAM, you decide on the contents. The only constraint is that *if* you boot from OTP, the bootrom expects a boot image at address 0x000 of OTP.

We use some internal conventions for MAC addresses and serial numbers, but there is no reason for you to stick to those; other than that you may be able to reuse some code that reads out the MAC address.

Hope this helps,
Henk
User avatar
Sebastian
Active Member
Posts: 39
Joined: Wed Jul 20, 2016 9:15 am

Post by Sebastian »

Hi Henk,

thank you.

I always thougt --mac-address and --serial-number write to a unique OTP address.

Best regards,
Sebastian
henk
Respected Member
Posts: 347
Joined: Wed Jan 27, 2016 5:21 pm

Post by henk »

Yeah so there is two reasons why they aren't unique. One is that you can write any number of Mac addresses. The second is that not all boards need all of these; so we don't want to create a Swiss cheese of data with a lot of wasted space. OTP is limited.

You can use the board that you have by now writing a [Mac address, Serial number, Mac address] - that should hopefully create a proper Mac address and Serial number in the top, followed by some corrupt data that you somehow have to skip.
User avatar
Sebastian
Active Member
Posts: 39
Joined: Wed Jul 20, 2016 9:15 am

Post by Sebastian »

Yeah so there is two reasons why they aren't unique. One is that you can write any number of Mac addresses. The second is that not all boards need all of these; so we don't want to create a Swiss cheese of data with a lot of wasted space. OTP is limited.
Absolutely understandable.


[Mac address, Serial number, Mac address]
Nice idea.
At play a little bit around with --outfile at the moment.
It is very helpful for understanding the xburn commands and the otp content.


Great thank you, henk
User avatar
Sebastian
Active Member
Posts: 39
Joined: Wed Jul 20, 2016 9:15 am

Post by Sebastian »

Hello everyone,

maybe someone could help me with the lib_otb.


My next step was, to use --lock for secure booting.

So I used a new board without the "damaged" OTB.

First I used the command:
xburn --lock keyfile --target-file xxx.xn --enalbe-jtag --disable-master-lock --mac-address xxx --serial-number xxx

Second Step:
xflash xxx.xe --keyfile

The device is booting, but could not read out the mac Adr. from OTB.

Third Step:
xrun xxx.xe

Tada, the device is running, and read out the Mac Adr. from OTB.


Has someone an advice for me? Use an other lib_otb for crypted flash?
I really looked carefully all informations I found but could not find much about OTB.

Best Regards,
Sebastian
henk
Respected Member
Posts: 347
Joined: Wed Jan 27, 2016 5:21 pm

Post by henk »

I am surprised it boots; I had expected you would need --enable-otp-boot.

However, I just realised you used --lock, this overwrites a set of options (see Figure 1 of the xburn manual), including the option that enables you to subsequently read from OTP.

Given that you have managed to keep JTAG open, can you read out the security register with xburn?

Cheers,
Henk
User avatar
Sebastian
Active Member
Posts: 39
Joined: Wed Jul 20, 2016 9:15 am

Post by Sebastian »

I have it done, like the Safeguard IP and device authenticity descripted it in section 2.3
0x000007fe: 0x00000010
0x000007ff: 0x4867ffff
SR : 0x00000000
Could it be that the OTB Boot bit isn't set?
But why is it "working" with
flash --key ?


Are there any possibilities to read out the OTB in a file?
like xburn --target xxx --read otb_read.txt

If I used this cmd like that, I have found it in another topic, I get an failure:
xburn: Input file file.txt not found
in option 'infile': invalid option value
I use xTime Version: 14.2.4
colin
Experienced Member
Posts: 74
Joined: Mon Dec 16, 2013 12:14 pm

Post by colin »

Hi Sebastian,

What you have done to lock the OTP looks correct and the MAC address and Serial number data should be there at the end of the OTP. You can do xburn --read --target-file=xxx.xn to see the entire contents of the OTP and confirm this is the case.

Presumably the XE that you xrun is the same XE that you programmed into flash with xflash? Therefore in both instances, the XE is compiled with the same XN (for pll and ref clock settings) and the same version of lib_otp from the tools, so I'd expect you to be able to read back your MAC address and serial number no matter if you are using XRUN or booting the XE from flash (albeit the boot from flash goes through a process of decryption).

Colin
Post Reply