i.MX ProcessorsのトピックRe: OCOTP write support on i.mx8m

OCOTP write support on i.mx8m

richard_hu — Wed, 18 Jul 2018 08:57:04 GMT

Hello, Sir:

We'd like to burn MAC address after booting into linux system.
I check there is an ocotp node added in "fsl-imx8mq.dtsi".

    ocotp: ocotp-ctrl@30350000 {
       compatible = "fsl,imx8mq-ocotp", "fsl,imx7d-ocotp", "syscon";
       reg = <0 0x30350000 0 0x10000>;
       clocks = <&clk IMX8MQ_CLK_OCOTP_ROOT>;
       /* For nvmem subnodes */
       #address-cells = <1>;
       #size-cells = <1>;
   };

But i check fsl_otp.c

There is no corresponding ocotp register mapping table for i.mx8m to be added.

So, i make an experiment to enable FSL_OTP driver in kernel configuration.

Symbol: FSL_OTP [=n]                                                                                                                         │
│ Type : tristate                                                                                                                             │
│ Prompt: Freescale On-Chip OTP Memory Support                                                                                                 │
│   Location:                                                                                                                                  │
│     -> Device Drivers                                                                                                                        │
│ (1)   -> Character devices                                                                                                                   │
│   Defined at drivers/char/Kconfig:94                                                                                                         │
│   Depends on: HAS_IOMEM [=y] && OF [=y]

And i use following command to burn MAC address into HW_OCOTP_MAC_ADDR1 and HW_OCOTP_MAC_ADDR0.

Then this board can only boot from serial downloand mode. (I think the fuses of boot mode are changed).
It explans the register mapping is wrong in fsl_otp.c .

My question is that fsl_otp.c doesn't support i.mx8m, why ocotp node is still added in fsl-imx8mq.dtsi?
Is there any plan to support fsl_otp.c for i.mx8m?

BR,

Richard

Re: OCOTP write support on i.mx8m

igorpadykov — Thu, 19 Jul 2018 00:04:39 GMT

Hi Richard

for i.MX8M seems this is linux/drivers/nvmem/imx-ocotp.c
imx-ocotp.c\nvmem\drivers - linux-imx - i.MX Linux kernel

Also one can use uboot to program the fuse values (below example

enabling secure more with programming SEC_CONFIG[1]).
fuse prog 1 3 0x2000000

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

Re: OCOTP write support on i.mx8m

richard_hu — Fri, 20 Jul 2018 03:34:39 GMT

Hello, igor:

Thanks for your reply.

We will take a look on it.

BR,

Richard

Re: OCOTP write support on i.mx8m

caleb_pentecost — Tue, 04 Dec 2018 00:04:58 GMT

Hello,

I am having a very similar issue on an imx8mq device. I would like to write a value to the MAC_ADDR0 and MAC_ADDR1 fuses, but am unable to do so with the fsl_otp driver in linux.

I can write these fuses manually via uBoot with the commands:

fuse prog 9 0 12345678
fuse prog 9 1 000090ab

And I can even successfully read these mac addresses back out in linux with the fsl_opt driver:

root@imx8mq:/sys/fsl_otp# cat HW_OCOTP_MAC_ADDR0
0x12345678
root@imx8mq:/sys/fsl_otp# cat HW_OCOTP_MAC_ADDR1
0x90ab

However, I am unable to burn any fuses with this driver:

root@imx8mq:/sys/fsl_otp# echo "0x00000001" > HW_OCOTP_MAC_ADDR2
root@imx8mq:/sys/fsl_otp# cat HW_OCOTP_MAC_ADDR2
0x0

Is there perhaps something that I am doing wrong? Is the fsl_otp driver unable to burn fuses on the imx8mq? Is there another driver that can be used that supports this functionality?

Thank you,

~Caleb

Re: OCOTP write support on i.mx8m

caleb_pentecost — Tue, 04 Dec 2018 00:19:45 GMT

For reference, it appears that this driver is being loaded to expose the virtual files:

drivers/char/fsl_otp.c · 72c6f89cb0e8df491c2708d4b71e73fe8539da39 · Librem5 / linux-emcraft · GitLab

That driver is included as dictated by the FSL_OTP flag:

drivers/char/Makefile · 72c6f89cb0e8df491c2708d4b71e73fe8539da39 · Librem5 / linux-emcraft · GitLab

And the driver is being loaded as if the device was an "imx7" device since that is how the .dtsi is enumerating the otp resources:
arch/arm64/boot/dts/freescale/fsl-imx8mq.dtsi · 72c6f89cb0e8df491c2708d4b71e73fe8539da39 · Librem5 / linux-emcraft · Git…

(Keep in mind, the Git repository linked is not the same one I am using, but the source files appear identical)

Thank you,

~Caleb

Re: OCOTP write support on i.mx8m

igorpadykov — Wed, 05 Dec 2018 00:52:55 GMT

one can try with fuse programming in uboot nxp L4.14.62_1.0.0

uboot-imx - i.MX U-Boot

Best regards
igor

Re: OCOTP write support on i.mx8m

joussen — Sat, 26 Jan 2019 00:03:49 GMT

Hi Igor,

any update on this topic? We need to program some fuses from Linux using the 4.9.51 SDK.

Kind regards, Mario

Re: OCOTP write support on i.mx8m

igorpadykov — Mon, 28 Jan 2019 23:31:43 GMT

one can look on linux ocotp driver:
https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/nvmem/imx-ocotp.c?h=imx_4.9.51_imx8m_ga

Best regards
igor

Re: OCOTP write support on i.mx8m

joussen — Tue, 29 Jan 2019 13:51:37 GMT

Can you share some more information on how to use it?

Right now our kernel is compiled with

CONFIG_NVMEM_IMX_OCOTP=y
CONFIG_NVMEM_IMX_SCU_OCOTP=y

and the device tree contains

 ocotp: ocotp-ctrl@30350000 {
 compatible = "fsl,imx8mq-ocotp", "fsl,imx7d-ocotp", "syscon";
 reg = <0 0x30350000 0 0x10000>;
 clocks = <&clk IMX8MQ_CLK_OCOTP_ROOT>;
 /* For nvmem subnodes */
 #address-cells = <1>;
 #size-cells = <1>;
 };

so we get /sys/devices/platform/30350000.ocotp-ctrl/imx-ocotp0/nvmem.

But what do we do with it?

Kind regards, Mario

Re: OCOTP write support on i.mx8m

marius_grigoras — Thu, 07 Feb 2019 22:07:03 GMT

Hi Mario,

I'm Marius (from NXP) - working for SE (Systems Engineering) Security group.

First of all, please use your private community group.

Secondly, indeed, there is a big change with the OTP driver from Linux. This was working just fine (both read/write operations) for i.mx6/7 and but starting with 4.14 GA release we support only read operations for all i.MX families.

Currently there is no plan to extend the functionality of the nvmem driver past read support.

The 4.14 kernel currently only supports reads even for the mx6 and mx7 families through the NVMEM driver.

Customers should use only u-boot level to program the fuses.

We never recommended in our i.MX8M (secure boot at least) documentation to use the Linux driver or the commands from Linux user-space to program the fuses.

Maybe there is somebody recommended them this way..or they just are familiar with the old way from i.mx6/7 families in the previous Linux BSPs.

But I have also some good news, you can use uuu (aka mfgtool 3.0) if you want a more powerful tool (if u-boot is not enough) and to automate the fuses programming. A snapshot from some internal uuu doc – (is working also with your chip):

2.1.2 - Programing eFuses using UUU (Universal Update Utility)

The UUU (Universal Update Utility) is a SDP protocol flash programming tool:

Github - UUU (Universal Update Utility) - mfgtools 3.0

The uuu.auto file contains a set of commands used for properly flashing the targeted device:

Wiki - UUU Sample Scripts

Users can add U-Boot commands to program a set of eFuses depending on their specific use case. The command lines below added in i.MX8QXP uuu.auto file can be used as an example on how to program the MAC1_ADDR[47:00] fuses in i.MX8QXP:

SDPS: boot -f imx-boot-imx8qxpmek-sd.bin-flash
+FB: ucmd fuse prog -y 0 708 0xa295fc11
+FB: ucmd fuse prog -y 0 709 0x000017b4
FB: ucmd setenv fastboot_dev mmc
FB: ucmd setenv mmcdev ${emmc_dev}
FB: ucmd mmc dev ${emmc_dev}

Thank you,

Marius

Re: OCOTP write support on i.mx8m

joussen — Thu, 07 Feb 2019 22:15:32 GMT

Hi Marius,

unfortunately I don't think that we can use UUU. Does UUU supports the 4.9.51 SDK? Additionally we need a process that can be initiated from a running Linux system.

What are the plans to bring write access from Linux back?

Kind regards, Mario

Re: OCOTP write support on i.mx8m

marius_grigoras — Mon, 11 Feb 2019 21:01:24 GMT

Hi Mario,

Unfortunately, I have negative answers for both of the questions.

Thank you,

Marius

Re: OCOTP write support on i.mx8m

andreacelani — Wed, 20 Feb 2019 10:18:51 GMT

Hello,

I have added the IMX8M support to the fsl_otp.c driver, so it is possible to read and write IMX8M fuse from the Linux user space, with simple command like this:

$ cat /sys/fsl_otp/HW_OCOTP_TESTER0
0xf0609912

I have posted the source code into a separate thread (OCOTP Shadow register reload ) because I have a problem with the OCOTP shadows reload function. It will be very useful if someone can check the new driver.

Kind regards,

Andrea.

Re: OCOTP write support on i.mx8m

marius_grigoras — Thu, 06 Jun 2019 12:54:17 GMT

Hi everyone,

I'm really sorry for delay here.

Finally we have a solution which is upstreamed already.

The following patch from Linux community seems to fix nvmem fuse write for 8m/8MMini.

https://patchwork.kernel.org/cover/10928999/

The above changes are made for 4.14.y branch so we ported them on our latest release 4.14.98_2.0.0_ga (attached patch) - special thanks to Irina Patru.

So this should fix the write operation for both mx8m/mm.

We validated this by writing to the register corresponding to MAC address:

from struct import pack

f = open('/sys/devices/platform/30350000.ocotp-ctrl/imx-ocotp0/nvmem', 'br+')

f.seek(0x90) # SRK0 position

f.write(pack('<L', 0xffffffff))

f.close()

There is not deadlock and fuse value is preserved after reboot:

# hexdump /sys/devices/platform/30350000.ocotp-ctrl/imx-ocotp0/nvmem

[…]

0000090 ffff ffff 0004 0000 0000 0000 0000 0000

00000a0 bada bada bada bada bada bada bada bada

[…]

Thank you,

Marius

Re: OCOTP write support on i.mx8m

craig_chen — Mon, 13 Mar 2023 02:37:17 GMT

@marius_grigoras

Use sysfs node(/sys/devices/platform/30350000.ocotp-ctrl/imx-ocotp0/nvmem) write MAC address the actual offset is mapping as below? which is correct or all not?

offset 0x90 mapping OTP Bank9 Word0

offset 0x91 mapping OTP Bank9 Word1

offset 0x92 mapping OTP Bank9 Word2

from offset 0x90 direct write 12bytes is mapping two eth MAC address

Best Regards

Craig