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);
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]; 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.