0

We are migrating from Buildroot 2018.02.9 (linux-4.14.85) to Buildroot 2020.02.2 (linux-5.4.40), and have found that we can no longer read the MAC address on an I.MX7s SoC. The following indicates why:

https://community.nxp.com/t5/i-MX-Processors/IMX6UL-sys-fsl-otp-HW-OCOTP-LOCK-is-not-found-in-5-4-kernel/m-p/1079342

Unfortunately OTP driver is not supported anymore, it was moved to NVMEM framework. imx-ocotp.c\nvmem\drivers - linux-imx - i.MX Linux kernel 

ie. https://source.codeaurora.org/external/imx/linux-imx/tree/drivers/nvmem/imx-ocotp.c?h=imx_5.4.24_2.1.0

We are trying to read the MAC address using a standard Linux DTS & device driver approach, ie. without writing extra code. And the aim is for the MAC to be read by the Ethernet driver.

Our Buildroot 20.20 ‘DSM1_kernel_defconfig’ includes:

CONFIG_NVMEM_IMX_OCOTP=y
CONFIG_NVMEM_IMX_IIM=y

The DTS entries for ocotp are assembeled from 2 files:

  • linux-5.4.40/arch/arm/boot/dts/imx7s.dtsi :
            ocotp: ocotp-ctrl@30350000 {
                #address-cells = <1>;
                #size-cells = <1>;
                compatible = "fsl,imx7d-ocotp", "syscon";
                reg = <0x30350000 0x10000>;
                clocks = <&clks IMX7D_OCOTP_CLK>;

                tempmon_calib: calib@3c {
                    reg = <0x3c 0x4>;
                };

                tempmon_temp_grade: temp-grade@10 {
                    reg = <0x10 0x4>;
                };

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

  • our local file ‘device-tree/DSM1.dts’ with 2 parts relating to this issue:

a) nvmem-cells and nvmem-cell-names are added to &fec1 as suggested by @alexandre-belloni:

&fec1 {

    nvmem-cells = <&MAC0>;
    // nvmem-consumer.yaml:
    nvmem-cell-names = "mac-address";

    pinctrl-names = "default";
    pinctrl-0 = <&pinctrl_enet1>;
    phy-mode = "rgmii";
    status = "okay";
    fixed-link {
        speed = <1000>;
        full-duplex;
    };
};

b) The following '&ocotp' entry:

    &ocotp {    
        // Subnodes:
        MAC0:mac_add0@640{
            reg=<0x640 0x4>;
        };
    
        MAC1:mac_add1@650{
            reg=<0x650 0x4>;
        };
    
        MAC2:mac_add2@660{
            reg=<0x660 0x4>;
        };
    };

Links for the above comments:

From the console:

[    0.547384] fuse: init (API version 7.31)

[    1.706205] fec 30be0000.ethernet: Invalid MAC address: 00:00:00:00:00:00
[    1.713049] fec 30be0000.ethernet: Using random MAC address: 3e:ba:4a:d6:f9:60
[    1.756676] libphy: fec_enet_mii_bus: probed
[    1.763270] fec 30be0000.ethernet eth0: registered PHC device 0

[    2.534219] imx_ocotp 30350000.efuse: can't request region for resource [mem 0x30350000-0x3035ffff]
[    2.543780] imx_ocotp: probe of 30350000.efuse failed with error -16

[    1.706205] fec 30be0000.ethernet: Invalid MAC address: 00:00:00:00:00:00
[    1.713049] fec 30be0000.ethernet: Using random MAC address: 3e:ba:4a:d6:f9:60

KSZ8794 VLAN configuration complete
OK
Reading MAC address fuses...
MAC Address fuses not found
Starting network: [    6.976948] Generic PHY fixed-0:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=fixed-0:00, irq=POLL)
[    7.007287] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off

The MAC on this board is currently unset. We would like to prove that the unset zero value can be successfully read, before moving on to using the MAC in the Ethernet driver. Eventually we will be setting the MAC during production.

Digging around in the Device Tree fails to find anything which we believe to be the unset zero MAC:

ls -l /sys/firmware/devicetree/base/soc/aips-bus@30000000/ocotp-ctrl@30350000

total 0
-r--r--r--    1 root     root             4 Oct  5 16:39 #address-cells
-r--r--r--    1 root     root             4 Oct  5 16:39 #size-cells
drwxr-xr-x    2 root     root             0 Oct  5 16:39 calib@3c
-r--r--r--    1 root     root             8 Oct  5 16:39 clocks
-r--r--r--    1 root     root            23 Oct  5 16:39 compatible
drwxr-xr-x    2 root     root             0 Oct  5 16:39 mac_add0@640
drwxr-xr-x    2 root     root             0 Oct  5 16:39 mac_add1@650
drwxr-xr-x    2 root     root             0 Oct  5 16:39 mac_add2@660
-r--r--r--    1 root     root            11 Oct  5 16:39 name
-r--r--r--    1 root     root            18 Oct  5 16:39 nvmem-cell-names
-r--r--r--    1 root     root             4 Oct  5 16:39 nvmem-cells
-r--r--r--    1 root     root            12 Oct  5 16:39 nvmem-cells-names
-r--r--r--    1 root     root             8 Oct  5 16:39 reg
drwxr-xr-x    2 root     root             0 Oct  5 16:39 speed-grade@10
drwxr-xr-x    2 root     root             0 Oct  5 16:39 temp-grade@10

Subnodes:

MAC0: ls -la /sys/firmware/devicetree/base/soc/aips-bus@30000000/ocotp-ctrl@30350000 /mac_add0@640/

total 0
drwxr-xr-x    2 root     root             0 Oct  6 08:01 .
drwxr-xr-x    8 root     root             0 Oct  6 08:00 ..
-r--r--r--    1 root     root             9 Oct  6 08:01 name
-r--r--r--    1 root     root             4 Oct  6 08:01 phandle
-r--r--r--    1 root     root             8 Oct  6 08:01 reg

hexdump /sys/firmware/devicetree/base/soc/aips-bus@30000000/ocotp-ctrl@3035000 0/mac_add0@640/name

0000000 616d 5f63 6461 3064 0000
0000009

hexdump /sys/firmware/devicetree/base/soc/aips-bus@30000000/ocotp-ctrl@3035000 0/mac_add0@640/phandle

0000000 0000 2000
0000004

hexdump /sys/firmware/devicetree/base/soc/aips-bus@30000000/ocotp-ctrl@3035000 0/mac_add0@640/reg

0000000 0000 4006 0000 0400
0000008

MAC1: ls -la /sys/firmware/devicetree/base/soc/aips-bus@30000000/ocotp-ctrl@30350000 /mac_add1@650/

total 0
drwxr-xr-x    2 root     root             0 Oct  6 08:01 .
drwxr-xr-x    8 root     root             0 Oct  6 08:00 ..
-r--r--r--    1 root     root             9 Oct  6 08:01 name
-r--r--r--    1 root     root             8 Oct  6 08:01 reg

hexdump /sys/firmware/devicetree/base/soc/aips-bus@30000000/ocotp-ctrl@3035000 0/mac_add1@650/name

0000000 616d 5f63 6461 3164 0000
0000009

hexdump /sys/firmware/devicetree/base/soc/aips-bus@30000000/ocotp-ctrl@3035000 0/mac_add1@650/reg

0000000 0000 5006 0000 0400
0000008

MAC2:

ls -la /sys/firmware/devicetree/base/soc/aips-bus@30000000/ocotp-ctrl@30350000 /mac_add2@660/

total 0
drwxr-xr-x    2 root     root             0 Oct  6 08:01 .
drwxr-xr-x    8 root     root             0 Oct  6 08:00 ..
-r--r--r--    1 root     root             9 Oct  6 08:01 name
-r--r--r--    1 root     root             8 Oct  6 08:01 reg

hexdump /sys/firmware/devicetree/base/soc/aips-bus@30000000/ocotp-ctrl@3035000 0/mac_add2@660/name

0000000 616d 5f63 6461 3264 0000
0000009

hexdump /sys/firmware/devicetree/base/soc/aips-bus@30000000/ocotp-ctrl@3035000 0/mac_add2@660/reg

0000000 0000 6006 0000 0400
0000008

Properties:

  • pre-move to fec1:

hexdump /sys/firmware/devicetree/base/soc/aips-bus@30000000/ocotp-ctrl@3035000 0/nvmem-cells

0000000 0000 2000
0000004

hexdump /sys/firmware/devicetree/base/soc/aips-bus@30000000/ocotp-ctrl@3035000 0/nvmem-cells-names

0000000 616d 2d63 6461 7264 7365 0073
000000c

hexdump /sys/firmware/devicetree/base/soc/aips-bus@30000000/ocotp-ctrl@3035000 0/nvmem-cell-names

0000000 6f6c 6163 2d6c 616d 2d63 6461 7264 7365
0000010 0073
0000012
  • post-move to fec1:

Edit: following the nvmem-cells & nvmem-cell-names edits as suggested by @alexandre-belloni:

find /sys -name "nvmem" -print

/sys/devices/platform/soc/30800000.aips-bus/30a20000.i2c/i2c-0/0-0068/ds1307_nvram0/nvmem
/sys/devices/platform/soc/30000000.aips-bus/30350000.ocotp-ctrl/imx-ocotp0/nvmem
/sys/firmware/devicetree/base/soc/aips-bus@30800000/ethernet@30be0000/nvmem-cells
/sys/firmware/devicetree/base/soc/aips-bus@30800000/ethernet@30be0000/nvmem-cell-names
/sys/firmware/devicetree/base/cpus/cpu@0/nvmem-cells
/sys/firmware/devicetree/base/cpus/cpu@0/nvmem-cell-names
/sys/firmware/devicetree/base/tempmon/nvmem-cells
/sys/firmware/devicetree/base/tempmon/nvmem-cell-names
/sys/bus/nvmem

hexdump /sys/devices/platform/soc/30800000.aips-bus/30a20000.i2c/i2c-0/0-0068/ds1307_nvram0/nvmem

0000000 9000 b1ae 02e1 4e10 1078 5a12 6444 c5a4
0000010 9a02 e488 c851 69a8 9902 22d3 1e2c 78a8
0000020 21ed ce14 c649 4422 22a9 0360 2b55 c93a
0000030 088a 4234 0ca4 8c88
0000038

hexdump /sys/devices/platform/soc/30000000.aips-bus/30350000.ocotp-ctrl/imx-ocotp0/nvmem

hexdump: /sys/devices/platform/soc/30000000.aips-bus/30350000.ocotp-ctrl/imx-ocotp0/nvmem: Invalid argument
0000000 0103 a003 886a 8ebf 0297 0000
000000c

ls -l /sys/firmware/devicetree/base/soc/aips-bus@30800000/ethernet@30be0000/nvmem-cells

-r--r--r--    1 root     root             4 Oct  6 14:18 /sys/firmware/devicetree/base/soc/aips-bus@30800000/ethernet@30be0000/nvmem-cells

hexdump /sys/firmware/devicetree/base/soc/aips-bus@30800000/ethernet@30be0000/nvmem-cells

0000000 0000 4600
0000004

hexdump /sys/firmware/devicetree/base/soc/aips-bus@30800000/ethernet@30be0000/nvmem-cell-names

0000000 616d 2d63 6461 7264 7365 0073
000000c

hexdump /sys/firmware/devicetree/base/cpus/cpu@0/nvmem-cells

0000000 0000 0400
0000004

hexdump /sys/firmware/devicetree/base/cpus/cpu@0/nvmem-cell-names

0000000 7073 6565 5f64 7267 6461 0065
000000c

hexdump /sys/firmware/devicetree/base/tempmon/nvmem-cells

0000000 0000 0c00 0000 0d00
0000008

hexdump /sys/firmware/devicetree/base/tempmon/nvmem-cell-names

0000000 6163 696c 0062 6574 706d 675f 6172 6564
0000010 0000
0000011

So, were’re obviously doing something wrong, any ideas? All suggestions gratefully received.

1 Answer 1

0

nvmem-cells and nvmem-cell-names are for the consumer node, i.e the ethernet node. You put them in the provider node. Simply move those properties to the fec1 node

6
  • Thanks Alexandre, We are hoping to see a sensible result from the '&ocotp' section before working on the Ethernet node. For now we've removed the Properties from '&ocotp'.
    – Geoff
    Commented Oct 6, 2020 at 13:40
  • Dumping anything in /sys/firmware/devicetree/ is simply showing what is in your device tree so I'm not sure what you are trying to see there. You should probably trace of_get_mac_addr_nvmem instead. Commented Oct 6, 2020 at 17:43
  • Point taken ;-) In fact we had spotted that it's just dumping the devicetree.
    – Geoff
    Commented Oct 7, 2020 at 8:05
  • We are however trying to prove that we can read the MAC 'manually' before getting into the Ethernet side of the issue. kernel.org/doc/Documentation/nvmem/nvmem.txt However we get: # hexdump /sys/bus/nvmem/devices/imx-ocotp0/nvmem hexdump: /sys/bus/nvmem/devices/imx-ocotp0/nvmem: Invalid argument 0000000 0103 a003 886a 8ebf 0297 0000 000000c
    – Geoff
    Commented Oct 7, 2020 at 8:20
  • Another example of using hexdump (without "Invalid argument" - perhaps this is the actual problem?): community.nxp.com/t5/i-MX-Processors/…
    – Geoff
    Commented Oct 7, 2020 at 8:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .