Re: Setting MAC address from I2C EEPROM - debug / commands? (Xilinx)

[David Antliff <d.antliff@unsw.edu.au>]

Hi Sean, thanks for getting back to me.

On 6/11/23 Sean Anderson wrote:
> On 6/11/23 23:25, David Antliff wrote:
> > On 11/23/22 Sean Anderson wrote:
> >>   On 11/22/22 20:23, David Antliff wrote:

[snip]

> > So I took up your suggestion, enabled CONFIG_NVMEM & CONFIG_I2C_EEPROM, and
> > with some trial and error I have got as far as added the following to my device tree:
> > 
> >      axi {
> >          i2c@ff030000 {
> >              i2c-mux@74 {
> >                  i2c@0 {
> >                      eeprom@54 {
> >                          mac_address: mac-address@23 {
> >                              reg = <0x23 6>;
> >                          };
> >                      };
> >                  };
> >              };
> >          };
> > 
> >          ethernet@ff0e0000 {
> >              nvmem-cells = <&mac_address>;
> >              nvmem-cell-names = "mac-address";
> >          };
> >      };
> > 
> > (This is part of a user .dtsi so it's added by Yocto to the existing DT provided by the vendor's board
> > definition).
> > 
> > The tree builds OK and I can view the correct nodes from U-Boot / fdt command.
> > 
> >  From a little debugging, I see that the call in eth-uclass.c around line 515 returns a null pointer:
> > 
> >        p = dev_read_u8_array_ptr(dev, "mac-address", ARP_HLEN);
> 
> This is expected. If (local-)mac-address is defined then nvmem_cell_get_by_name/nvmem_cell_read will not be used.

Yeah, so, I think I shot myself in the foot when writing this email, because although I am using the U-Boot device tree
for my efforts (the one appended to the U-Boot binary, a la CONFIG_OF_SEPARATE), I actually used the Linux one in
my email, which was a mistake because the "local-mac-address" has been populated with a valid address by that point.
I'm actually not sure where that address comes from, because in the U-Boot device tree, I have:

        local-mac-address = [ff ff ff ff ff ff];

So to be clear, I do not have a valid local-mac-address in the U-Boot device tree at the time U-Boot is looking for the MAC address.

> > And this results in U-Boot assigning the FF:FF:FF:FF:FF:FF address instead.
> > 
> > Yet, if I boot Linux, this device now appears in sysfs as /sys/bus/nvmem/devices/6-00544/nvmem,
> > and I can read/write to it, so something is working. Linux ends up with the wrong MAC though
> > (76:1b:db:1f:78:12, and I'm not sure where that comes from).
> > 
> > I think I have the right Ethernet device, as U-Boot reports:
> > 
> >      ZYNQ GEM: ff0e0000, mdio bus ff0e0000, phyaddr 12, interface rgmii-id
> > 
> > Do you have any thoughts as to why U-Boot is not picking up the MAC address from the EEPROM,
> > in this case, please?
> > 
> > The full sections of the relevant parts of the DT now look like this:

[snip]

> >          ethernet@ff0e0000 {
> >                  power-domains = <0x11 0x20>;
> >                  iommus = <0x12 0x877>;
> >                  #address-cells = <0x01>;
> >                  phy-mode = "rgmii-id";
> >                  nvmem-cells = <0x15>;
> >                  clock-names = "pclk\0hclk\0tx_clk\0rx_clk\0tsu_clk";
> >                  local-mac-address = [76 1b db 1f 78 12];
> 
> This will prevent the nvmem-cells from being used. Is this your U-Boot device tree? Or is it from /sys/firmware?

Yes, this is from /sys/firmware - my mistake, as mentioned above. The U-Boot device tree looks like this:

ZynqMP> fdt print /axi/ethernet@ff0e0000
ethernet@ff0e0000 {
        compatible = "xlnx,zynqmp-gem", "cdns,gem";
        status = "okay";
        interrupt-parent = <0x00000005>;
        interrupts = <0x00000000 0x0000003f 0x00000004 0x00000000 0x0000003f 0x00000004>;
        reg = <0x00000000 0xff0e0000 0x00000000 0x00001000>;
        clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk";
        #address-cells = <0x00000001>;
        #size-cells = <0x00000000>;
        iommus = <0x00000012 0x00000877>;
        power-domains = <0x00000011 0x00000020>;
        resets = <0x00000013 0x00000020>;
        reset-names = "gem3_rst";
        clocks = <0x00000004 0x0000001f 0x00000004 0x0000006b 0x00000004 0x00000030 0x00000004 0x00000034 0x00000004 0x0000002c>;
        phy-handle = <0x00000014>;
        phy-mode = "rgmii-id";
        xlnx,ptp-enet-clock = <0x00000000>;
        local-mac-address = [ff ff ff ff ff ff];
        nvmem-cells = <0x00000015>;
        nvmem-cell-names = "mac-address";
        phandle = <0x00000067>;
        mdio {
                #address-cells = <0x00000001>;
                #size-cells = <0x00000000>;
                phandle = <0x00000068>;
                ethernet-phy@c {
                        #phy-cells = <0x00000001>;
                        compatible = "ethernet-phy-id2000.a231";
                        reg = <0x0000000c>;
                        ti,rx-internal-delay = <0x00000008>;
                        ti,tx-internal-delay = <0x0000000a>;
                        ti,fifo-depth = <0x00000001>;
                        ti,dp83867-rxctrl-strap-quirk;
                        reset-gpios = <0x00000016 0x00000006 0x00000001>;
                        phandle = <0x00000014>;
                };
        };
};

I've noticed in some online examples that there's a compatible = "nvmem-cells" at the EEPROM level, so I tried:

ZynqMP> fdt print /axi/i2c@ff030000/i2c-mux@74/i2c@0
i2c@0 {
        #address-cells = <0x00000001>;
        #size-cells = <0x00000000>;
        reg = <0x00000000>;
        phandle = <0x0000006d>;
        eeprom@54 {
                compatible = "atmel,24c128", "nvmem-cells";
                reg = <0x00000054>;
                phandle = <0x00000036>;
                mac-address@23 {
                        reg = <0x00000023 0x00000006>;
                        phandle = <0x00000015>;
                };
        };
};

However this does not work either. Is this compatibility declaration required?

[snip]
 
> You can also #define DEBUG in drivers/misc/nvmem.c

Thank you, I will try that.
 
-- David.