i.MX6ULL NVMEM OCOTP read values

[SCordibella]

Dear community,

    I am trying to read values from NVMEM from bash (ie: MAC address) using hexdump on i.MX6ULL running kernel 5.4.91.

root@colibri-imx6ull:~# hexdump -C /sys/devices/soc0/soc/2100000.aips-bus/21bc000.ocotp-ctrl/imx-ocotp0/nvmem 
00000000  03 00 32 00 46 c2 44 60  d2 c9 31 2f c6 00 31 71  |..2.F.D`..1/..1q|
00000010  02 00 43 00 90 00 00 00  10 00 00 00 00 00 00 00  |..C.............|
00000020  00 00 00 00 00 00 00 00  1e 00 00 00 00 00 00 00  |................|
00000030  00 00 00 00 00 00 00 00  5f ac 34 52 00 00 00 00  |........_.4R....|
00000040  da ba da ba da ba da ba  da ba da ba da ba da ba  |................|
*
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000090  00 00 00 00 da ba da ba  00 00 00 00 00 00 00 00  |................|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  00 00 00 00 40 00 00 00  02 00 00 00 00 00 00 00  |....@...........|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100
root@colibri-imx6ull:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,DYNAMIC,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:14:2d:63:92:cb brd ff:ff:ff:ff:ff:ff
root@colibri-imx6ull:~# 

I guess to see the MAC address in the NVMEM, but there isn't.

Am I missing something?

Best regards,

Stefano.

[SCordibella]

Update

I run the latest nxp kernel on a imx6ull evk and here is the result:

root@imx6ul7d:~# hexdump -C /sys/bus/nvmem/devices/imx-ocotp0/nvmem 
00000000  03 00 32 00 57 f4 a1 c2  bb 29 12 2e ee 00 30 71  |..2.W....)....0q|
00000010  02 00 41 00 00 00 00 00  00 00 00 00 00 00 00 00  |..A.............|
00000020  00 00 00 00 00 00 00 00  58 00 00 00 00 00 00 00  |........X.......|
00000030  00 00 00 00 00 00 00 00  5f e2 c4 55 00 00 00 00  |........_..U....|
00000040  da ba da ba da ba da ba  da ba da ba da ba da ba  |................|
*
00000060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000080  00 00 00 00 00 00 00 00  00 f7 04 9f 04 00 01 f7  |................|
00000090  04 9f 04 00 da ba da ba  00 41 00 00 00 00 00 00  |.........A......|
000000a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
000000b0  00 00 00 00 40 00 00 00  02 00 00 00 00 00 00 00  |....@...........|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100
root@imx6ul7d:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:04:9f:04:f7:01 brd ff:ff:ff:ff:ff:ff
3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000
    link/ether 00:04:9f:04:f7:00 brd ff:ff:ff:ff:ff:ff
4: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
    link/sit 0.0.0.0 brd 0.0.0.0
5: can0: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
    link/can 
6: can1: <NOARP,ECHO> mtu 16 qdisc noop state DOWN group default qlen 10
    link/can 

Here we have the two ethernet MAC address.

Since the kernel is the same my question is: why the NXP evk has the right information and the other module no? Who is the responsible that write the nvmem? I supposed that it was NXP that drive this process during the CHIP production.

Best regards,

Stefano.

[igorpadykov · Accepted solution]

Hi Stefano

> I supposed that it was NXP that drive this process during the CHIP production.

sorry NXP does not program MAC addresses during chip production. It is resposibility of customer

to obtain those adresses and properly progam them: 

https://standards.ieee.org/products-services/regauth/index.html

Best regards
igor

[SCordibella]

Thank you for the answer @igorpadykov .

How about the hardware key written in NVMEM? Also that key should be written by customer or it is managed by NXP?

Our goal is to use that key to implement security feature on our product.

Best regards,

Stefano.

[igorpadykov]

if you are speaking about OTPMK fuses, OTPMK fuses are programmed by NXP during the device manufacturing flow.

Best regards
igor

[SCordibella]

Yes @igorpadykov I mean the OTPMK fuses.

Thank you for your answer,

Stefano.

[igorpadykov]

Hi Stefano

one can try with latest nxp linux Linux 5.10.9_1.0.0​ (as kernel 5.4.91 is not supported by nxp)

https://www.nxp.com/design/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applicat...

nvmem usage can be found on

https://www.digi.com/resources/documentation/digidocs/embedded/dey/3.0/cc6/bsp_r_otp_cc6cc6qp

Best regards
igor

[SCordibella]

Hi @igorpadykov , thank you for your reply.

Even if I use kernel 5.10.9 as you point in your previous comment I read the same values from the nvmem. I try to use the different hexdump format as suggested in the digi post, but nothing changes.

Where I can find more documentation about the data written in the nvmem? If I look in the dts I can't find anything that refers to the MAC:

   ocotp: ocotp-ctrl@21bc000 {
    #address-cells = <1>;
    #size-cells = <1>;
    compatible = "fsl,imx6ul-ocotp", "syscon";
    reg = <0x021bc000 0x4000>;
    clocks = <&clks 165>;

    tempmon_calib: calib@38 {
     reg = <0x38 4>;
    };

    tempmon_temp_grade: temp-grade@20 {
     reg = <0x20 4>;
    };

    cpu_speed_grade: speed-grade@10 {
     reg = <0x10 4>;
    };
   };

Do I need to add MAC mapping here in dtb?

Best regards,

Stefano.