has anyone faced an issues while wrtining fuses ?

cancel
Showing results for 
Search instead for 
Did you mean: 

has anyone faced an issues while wrtining fuses ?

Jump to solution
601 Views
vadimlomovtsev
Contributor II

I've tried to burn SRK, OTPM and MEM0 fuses according to documents "i.MX 6 Linux High Assurance Boot (HAB) User's Guide, Rev L3.0.35_4.1.0, 09/2013" in order to enable Secure Boot feature.

The SRKs burned well. However while burning and checking OTPM and MEM0 I've faced following issues:

issue #1 .

When trying to burn OTPMKn with following comman:

      # echo 0x975b69a7 > HW_OCOTP_OTPMK0

the board seems to be waiting for reply or something forever and nothing happens.

Still the "Ctrl-C" returns me into back to shell but it looks like no data written into fuse since I've got following:
      # cat HW_OCOTP_OTPMK0
      #


Issue #2.

When reading the SRKn or MEM0 fuses just after reboot I got correct values. Readings are always fine until I tried to read OTPMKn.

The only first read of OTPMKn (n could be any) provides following:

     # cat HW_OCOTP_OTPMK0

     0xbadabada

After that all further attempts to read values from OTP provides nothing:

     # cat HW_OCOTP_OTPMK1

     # cat HW_OCOTP_OTPMK2

     # cat HW_OCOTP_SRK*

     #


Has anyone faced this issues and may be there some fix for that?

Thanks.


My board is "Utilite" (by Compulab) CM-FX6 board, based on i.MX6 Dual-Core processor.

Tags (2)
0 Kudos
1 Solution
103 Views
PeterChan
NXP Employee
NXP Employee

Please check bit 17 (DCP) in HW_OCOTP_LOCK register if it is set. This is the OTP read & write lock for the otpmk region. If it is st, all read & write of otpmk region's shadow register will be blocked.

As I understand, the OTPMK registers are pre-programmed with random values and the DCP bit in HW_OCOTP_LOCK register is set to avoid further change.

View solution in original post

0 Kudos
3 Replies
103 Views
vadimlomovtsev
Contributor II

one more update related to Issue #1:

only first write to OTPMKn completes all further writing attempts waits forever. dmesg doesn't contain any messages related to OTP problems or whatever suspicious.

So it looks like that accessing to OTPMKn makes OTP interface inaccessible. Only system reboot helps to get rid off this. Untill next acess to OTPMKn.

0 Kudos
104 Views
PeterChan
NXP Employee
NXP Employee

Please check bit 17 (DCP) in HW_OCOTP_LOCK register if it is set. This is the OTP read & write lock for the otpmk region. If it is st, all read & write of otpmk region's shadow register will be blocked.

As I understand, the OTPMK registers are pre-programmed with random values and the DCP bit in HW_OCOTP_LOCK register is set to avoid further change.

View solution in original post

0 Kudos
103 Views
vadimlomovtsev
Contributor II

Thanks Peter.

I've check register and found that 17-th bit is set.

0 Kudos