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

[Sean Anderson <seanga2@gmail.com>]

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:
>>>
>>   > I'm looking to extract the board's MAC address from serial I2C EEPROM at boot time, so
>>   > I'm trying to work out how I can tell if U-Boot is actually able to communicate with this
>>   > EEPROM, outside of manual i2c commands.
>>   >
>>   > I have set CONFIG_ZYNQ_MAC_IN_EEPROM and CONFIG_ZYNQ_MAC_IN_EEPROM
>>   > however I'm not completely sure that this is working with UltraScale+ Zynq MPSoC
>>   > boards - I'm using a ZCU208. There's no log message on the U-Boot console to say
>>   > that there was an attempt to read the MAC address, and with ethaddr unset, this
>>   > variable is set by U-Boot to the value taken from the device tree rather than EEPROM:
>>   >
>>   > ethernet@ff0e0000 {
>>   >      ...
>>   >      local-mac-address = [00 0a 35 00 22 01];
>>   >      ...
>>   >
>>   > I would expect it to be 00 0a 35 07 60 1c based on the contents of the EEPROM.
>>   >
>>   > I would like to understand how to debug this. I read that the command "eeprom" has been
>>   > deprecated for some time (I don't have it enabled), with some I2C serial EEPROM devices
>>   > now supported by the "Driver Model" - aka DM.
>>   >
>>   > Thus I did find:
>>   >
>>   >> dm uclass
>>   > ...
>>   > uclass 39: i2c_eeprom
>>   > 0     eeprom@54 @ 7dd21420
>>   > ...
>>   >
>>   > And I'm able to communicate with the device via commands like:
>>   >
>>   > ZynqMP> i2c md 54 0.2 40 200000
>>   > 0000: 5a 43 55 32 30 38 ff ff ff ff ff ff ff ff ff ff    ZCU208..........
>>   > 0010: ff 41 30 32 38 33 32 32 30 34 31 34 33 33 32 38    .A02832204143328
>>   > 0020: 31 2e 33 00 0a 35 07 60 1c 00 0a 35 07 60 1d 00    1.3..5.`...5.`..
>>   > 0030: 0a 35 07 60 1e 00 0a 35 07 60 1f 41 08 ff ff ff    .5.`...5.`.A....
>>   >
>>   > The MAC address is 6 bytes starting at offset 0x23 (00 0a 35 07 60 1c).
> 
> [snip]
> 
>>   > The EEPROM device in question is an M24128.
>>   >
>>   > CONFIG_SYS_I2C_EEPROM_ADDR=0x54
>>   > CONFIG_SYS_I2C_EEPROM_BUS=6
>>   > CONFIG_SYS_EEPROM_SIZE=16384
>>   > CONFIG_SYS_I2C_EEPROM_ADDR_LEN=2
>>   > CONFIG_ZYNQ_GEM_I2C_MAC_OFFSET=0x23
>>   > CONFIG_ZYNQ_MAC_IN_EEPROM=y
>>   >
>>   > U-Boot 2021.01 (Xilinx fork: git://github.com/Xilinx/u-boot-xlnx.git)
> 
> [snip]
> 
>>   This doesn't directly address your question, but have you tried using nvmem-cells?
>>   
>>   You enable CONFIG_NVMEM and CONFIG_I2C_EEPROM, and modify your device tree like
>>   
>>   i2c {
>>           eeprom@54 {
>>                   #address-cells = <1>;
>>                   #size-cells = <1>;
>>                   compatible = "atmel,24c08";
>>                   reg = <0x54>;
>>   
>>                   mac_address: mac-address@23 {
>>                           reg = <0x23 6>;
>>                   };
>>           };
>>   };
>>   
>>   ethernet {
>>           nvmem-cells = <&mac_address>;
>>           nvmem-cell-names = "mac-address";
>>   };
>>   
>>   You'll need 2022.07 for this I think. This is the same method which
>>   Linux uses. I added this specificly to be able to load MAC addresses
>>   from EEPROMs without needing to hard code stuff into Kconfig.
> 
> Hi Sean,
> 
> Apologies for bringing this thread back to life more than 6 months later, but I'm not
> quite getting this to work.
> 
> I have finally had the opportunity to upgrade to U-Boot 2023.1, and the first thing I
> noticed was that the old way of retrieving the MAC address from the EEPROM fails,
> as is expected as I understand that support was removed sometime after 2021.
> 
> 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.

> 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:
> 
>      axi {
> 
>          /* .... */
> 
>          i2c@ff030000 {
>                  power-domains = <0x11 0x26>;
>                  pinctrl-names = "default\0gpio";
>                  #address-cells = <0x01>;
>                  pinctrl-0 = <0x1a>;
>                  interrupts = <0x00 0x12 0x04>;
>                  clocks = <0x04 0x3e>;
>                  #size-cells = <0x00>;
>                  interrupt-parent = <0x05>;
>                  clock-frequency = <0x61a80>;
>                  compatible = "cdns,i2c-r1p14";
>                  pinctrl-1 = <0x1b>;
>                  status = "okay";
>                  reg = <0x00 0xff030000 0x00 0x1000>;
>                  phandle = <0x6c>;
>                  scl-gpios = <0x19 0x10 0x00>;
>                  sda-gpios = <0x19 0x11 0x00>;
>          
>                  i2c-mux@74 {
>                          #address-cells = <0x01>;
>                          i2c-mux-idle-disconnect;
>                          #size-cells = <0x00>;
>                          compatible = "nxp,pca9548";
>                          reg = <0x74>;
>          
>                          i2c@0 {
>                                  #address-cells = <0x01>;
>                                  #size-cells = <0x00>;
>                                  reg = <0x00>;
>                                  phandle = <0x6d>;
>          
>                                  eeprom@54 {
>                                          compatible = "atmel,24c128";
>                                          reg = <0x54>;
>                                          phandle = <0x36>;
>          
>                                          mac-address@23 {
>                                                  reg = <0x23 0x06>;
>                                                  phandle = <0x15>;
>                                          };
>                                  };
>                          };
> 
>          /* ... */
> 
>          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?

>                  resets = <0x13 0x20>;
>                  interrupts = <0x00 0x3f 0x04 0x00 0x3f 0x04>;
>                  clocks = <0x04 0x1f 0x04 0x6b 0x04 0x30 0x04 0x34 0x04 0x2c>;
>                  #size-cells = <0x00>;
>                  interrupt-parent = <0x05>;
>                  compatible = "xlnx,zynqmp-gem\0cdns,gem";
>                  status = "okay";
>                  nvmem-cell-names = "mac-address";
>                  reg = <0x00 0xff0e0000 0x00 0x1000>;
>                  phandle = <0x67>;
>                  phy-handle = <0x14>;
>                  reset-names = "gem3_rst";
>                  xlnx,ptp-enet-clock = <0x00>;
>          
>                  mdio {
>                          #address-cells = <0x01>;
>                          #size-cells = <0x00>;
>                          phandle = <0x68>;
>          
>                          ethernet-phy@c {
>                                  ti,dp83867-rxctrl-strap-quirk;
>                                  ti,tx-internal-delay = <0x0a>;
>                                  #phy-cells = <0x01>;
>                                  reset-gpios = <0x16 0x06 0x01>;
>                                  compatible = "ethernet-phy-id2000.a231";
>                                  ti,fifo-depth = <0x01>;
>                                  ti,rx-internal-delay = <0x08>;
>                                  reg = <0x0c>;
>                                  phandle = <0x14>;
>                          };
>                  };
>          };
> 
> The full tree is here: https://pastebin.com/WQKBxK7x
> 
> I feel like I'm close, but must be missing something.
> 
> -- David.

You can also #define DEBUG in drivers/misc/nvmem.c

--Sean