topic Re: OCOTP Shadow register reload in i.MX Processors

OCOTP Shadow register reload

andreacelani — Mon, 18 Feb 2019 10:44:49 GMT

I have modified the OCOTP driver "fsl_otp.c" and I have added the support to the IMX8M.

Now I can write and read the OCOTP register from Linux user space with simple command like this:

$ cat /sys/fsl_otp/HW_OCOTP_TESTER0
0xf0609912

Anyway, I have a problem after a write operation. For example, if I try to write "0xaa" to the HW_OCOTP_GP10, I got a strange result, as in the followings:

$ cat /sys/fsl_otp/HW_OCOTP_GP10
0x0
$ echo 0xaa > /sys/fsl_otp/HW_OCOTP_GP10
$ cat /sys/fsl_otp/HW_OCOTP_GP10
0xd503201f

Anyway, if I power off and power on again the board, I can be able to see the following result:

$ cat /sys/fsl_otp/HW_OCOTP_GP10
0xaa

So the write operation was success, but there was a problem reloading a register after a write operation.

Finally, I have found the problem in the shadows register reload code:

    /* Reload all the shadow registers */
   __raw_writel(BM_OCOTP_CTRL_RELOAD_SHADOWS,
             otp_base + HW_OCOTP_CTRL_SET);
   udelay(1);
   ret = otp_wait_busy(BM_OCOTP_CTRL_RELOAD_SHADOWS);
   if (ret){
       printk("Reload all the shadow registers failed\n");
   }

This code is executed in the function fsl_otp_store(...) just after the write operation. The code try to reload all

the shadows register, so that any subsequent read operation gets the correct value from the shadow area.

After this code is executed, all the shadows register index are shifted by one, as you can see from the

following result, where all registers have a progressive index:

$cat /sys/fsl_otp/HW_OCOTP_ROM_PATCH6
0x83b8
$cat /sys/fsl_otp/HW_OCOTP_ROM_PATCH7
0xd503201f
$cat /sys/fsl_otp/HW_OCOTP_GP10
0x0
$cat /sys/fsl_otp/HW_OCOTP_GP11
0x0

$echo 0xaa > /sys/fsl_otp/HW_OCOTP_GP10

$cat /sys/fsl_otp/HW_OCOTP_ROM_PATCH6
0x55000801
$cat /sys/fsl_otp/HW_OCOTP_ROM_PATCH7
0x83b8
$cat /sys/fsl_otp/HW_OCOTP_GP10
0xd503201f
$cat /sys/fsl_otp/HW_OCOTP_GP11
0xaa

I have found a workaround for this issue. I added a FIX_IMX8M_OFFSET_INDEX_AFTER_RELOAD define, that add an offset to the register index after a write operation. With this workaround the driver works as expected:

$ cat /sys/fsl_otp/HW_OCOTP_GP10
0x0
$ echo 0xaa > /sys/fsl_otp/HW_OCOTP_GP10
$ cat /sys/fsl_otp/HW_OCOTP_GP10
0xaa

So, the OCOTP shadow register reload does not work correctly. Is it a known issue of IMX8M?

Re: OCOTP Shadow register reload

Yuri — Tue, 19 Feb 2019 07:49:33 GMT

Hello,

There are no public bugs about the OCOTP shadow register in the Errata.

Section 6.3.3.1 (Operation) of the i.MX8M Reference Manual (Rev. 0, 01/2018)

describes fuse operations. Please check it.

Have a great day,

Yuri

------------------------------------------------------------------------------

Note: If this post answers your question, please click the Correct Answer

button. Thank you!

Re: OCOTP Shadow register reload

andreacelani — Tue, 19 Feb 2019 09:39:15 GMT

I have checked the Section 6.3.3.1 (Operation) of the i.MX8M Reference Manual (Rev. 0, 01/2018) that describes the fuse operations. It seems that the fsl_otp.c driver does the correct operations in order to reload the shadows register. The problem is that the shadows register are reloaded from the fuse bank array in the wrong order, basically shifted by one.

I think this an hardware bug of IMX8M, but I cannot be sure because there could be something wrong in the driver.

Re: OCOTP Shadow register reload

andreacelani — Wed, 12 Jun 2019 14:38:57 GMT

A few days ago, I found a solution in the following thread:

https://community.nxp.com/message/1161432?commentID=1161432&et=watches.email.thread#comment-1161432

So I have imported the suggested patch into the fsl_otp.c driver (basically I have changed the imx8m_set_otp_timing function). I have tested the new fsl_otp driver on IMX8MQ and on IMX8M-MINI cpu. The driver works properly, so I can be able to read and write fuse from linux user space by using the filesystem files /sys/fsl_otp/HW_OCOTP*.

I have attached the new fsl_otp.c driver (I have tested it on bsp 4.14.78_1.0.0_ga).