Shadow Registers Read/Write

cancel
Showing results for 
Search instead for 
Did you mean: 

Shadow Registers Read/Write

2,105 Views
fmajeric
Contributor III


Hi everybody,

I'm trying to deal with the fuses (OTP) and Shadows Registers of the i.MX6S processor.

I've already read a lot of documentation, but I'm not still an expert and it's the reason of this post :smileysad:...

But if this discussion can help other one it a good thing and I'm happy :smileylaugh: .

So I ever read:

I'm working on two development boards that embed the i.MX6 SoC:

The first manipulation I want to do is :

  1. Read a shadow register.
  2. override its value.
  3. Read its value again.
  4. Reload all Shadows registers.
  5. Check the value is reloaded (by reading it).

So I consider the following registers :

AddressRegister Name
0x21B_C000OTP Controller Control Register (OCOTP_CTRL)
0x21B_C580

Shadow Register for OTP Bank3 Word0 (SRK Hash)

(OCOTP_SRK0)

I want to to this manipulation by two ways :

  • A JTAG debugger
  • The u-boot user interface with the command "fuse"

fuse.png

On the SabreLite I've no problem:

  1. I read the value of OCOTP_SRK0 register : 0x0000_0000
  2. I write a value on it : 0x0011_2233
  3. I read its value again : 0x0011_2233
  4. Write '1' in OCOTP_OCTRL[10] in order to reload register
  5. And then when I read OCOTP_SRK0 I've the reinitialized value : 0x0000_0000

Everything are well, by the JTAG or by the u-boot. Even, I can mix the JTAG and u-boot manipulation, when I modify on one, the other stay coherent with the modification.

On the RIoTboard, and here is the problem, when I want to proceed the same manipulation I can't.

  1. I can read the value of  OCOTP_SRK0 register : 0x0000_0000.
  2. But I can't write on it and so overwrite with the value 0x0011_2233
  3. It seems  can't also write on the OCOTP_OCTRL[10]. (I'm not sure because I can't change any value so I can't check if I can't reload it).

Because I'm like Mulder and wan't to believe :smileyhappy:, I compare all the shadows register of the 2 boards.

I think a security configuration lock me and the difference will highlight it :

AddressSabreLite (hex)RIoTboard (hex)Register Name

0x21B_C000

0000_02000000_0000OCOTP_CTRL

0x21B_C004

0000_00000000_0000OCOTP_CTRL_SET

0x21B_C008

0000_00000000_0000OCOTP_CTRL_CLR

0x21B_C00C

0000_00000000_0000OCOTP_CTRL_TOG

0x21B_C010

0146_12990146_1299OCOTP_TIMING

0x21B_C020

0000_00000000_0000OCOTP_DATA

0x21B_C030

0000_00000000_0000OCOTP_READ_CTRL

0x21B_C040

BADA_BADA0000_0000OCOTP_READ_FUSE_DATA

0x21B_C050

0000_001C0000_0018OCOTP_SW_STICKY

0x21B_C060

8000_00000000_0000OCOTP_SCS

0x21B_C064

0000_00000000_0000OCOTP_SCS_SET

0x21B_C068

0000_00000000_0000OCOTP_SCS_CLR

0x21B_C06C

0000_00000000_0000OCOTP_SCS_TOG
0x21B_C0900200_00000000_0000OCOTP_VERSION
...
0x21B_C4002022_00022022_0002OCOTP_LOCK

0x21B_C410

D819_1856D72D_78A9OCOTP_CFG0

0x21B_C420

0613_71D40D29_41D4OCOTP_CFG1

0x21B_C430

2000_0098A650_007BOCOTP_CFG2

0x21B_C440

002A_03020042_0702OCOTP_CFG3

0x21B_C450

1800_00300000_0000OCOTP_CFG4

0x21B_C460

0000_00100000_0000OCOTP_CFG5

0x21B_C470

0000_00000000_0000OCOTP_CFG6

0x21B_C480

0000_00C00000_0000OCOTP_MEM0

0x21B_C490

0000_00400000_0040OCOTP_MEM1

0x21B_C4A0

0000_00A20000_0033OCOTP_MEM2

0x21B_C4B0

0000_00000000_0000OCOTP_MEM3

0x21B_C4C0

0000_00000000_0000OCOTP_MEM4

0x21B_C4D0

0000_00000000_0000OCOTP_ANA0

0x21B_C4E0

5884_C77D58E5_0C5FOCOTP_ANA1
0x21B_C4F00000_00000000_0000OCOTP_ANA2
...

0x21B_C580

0000_00000000_0000OCOTP_SRK0

0x21B_C590

0000_00000000_0000OCOTP_SRK1

0x21B_C5A0

0000_00000000_0000OCOTP_SRK2

0x21B_C5B0

0000_00000000_0000OCOTP_SRK3

0x21B_C5C0

0000_00000000_0000OCOTP_SRK4
0x21B_C5D00000_00000000_0000OCOTP_SRK5

0x21B_C5E0

0000_00000000_0000OCOTP_SRK6

0x21B_C5F0

0000_00000000_0000OCOTP_SRK7

0x21B_C600

0000_00000000_0000OCOTP_RESP0

0x21B_C610

0000_00000000_0000OCOTP_HSJC_RESP1

0x21B_C620

0000_00000000_0000OCOTP_MAC0

0x21B_C630

0000_00000000_0000OCOTP_MAC1

0x21B_C660

0000_00000000_0000OCOTP_GP1

0x21B_C670

0000_00000000_0000OCOTP_GP2

0x21B_C6D0

0000_00000000_0000OCOTP_MISC_CONF

0x21B_C6E0

0000_00000000_0000OCOTP_FIELD_RETURN
0x21B_C6F00000_00000000_0000OCOTP_SRK_REVOKE

Firstly I thought I can't write the shadow fuses because the OCOTP_LOCK is not configured as on the SabreLite.

BUT, on the both board this register has the same value ... So I start to read in detail the features of each fuse in order to understand what stops me to write some shadow registers.

Because it's a long, complicated work and I'm not sure to succeed, I ask the question here.

Q: Does someone have an idea about why I can't proceed the the manipulation as the SabreLite on the RIoTboard ?? Does the problem come from the fuses ?

Don't hesitate to ask me more information,

Thank you for your help.

Fabien.

Labels (1)
2 Replies

660 Views
Yuri
NXP TechSupport
NXP TechSupport

Hello,

   Perhaps the problem relates to different U-boot versions for

the SabreLite and  the RIoTboard. Please try using  recent NXP

U-boot  version. 

Have a great day,
Yuri

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

660 Views
fmajeric
Contributor III

Hello,

Thank you for your answer.

I will try it as soon as possible.

I think you are right because the last time I want to use the CAAM through its registers but I can with JTAG.

Then I change the U-boot and the CAAM registers were mapped in the RAM memory.

I come back to give the result.

Have a nice day,

Fabien.