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.
已解决! 转到解答。
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
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.
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
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.
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)
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
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.