Setting MAC address from I2C EEPROM - debug / commands? (Xilinx)
Sean Anderson
seanga2 at gmail.com
Mon Jun 12 06:01:32 CEST 2023
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 at 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 at 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 at 54 {
>> #address-cells = <1>;
>> #size-cells = <1>;
>> compatible = "atmel,24c08";
>> reg = <0x54>;
>>
>> mac_address: mac-address at 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 at ff030000 {
> i2c-mux at 74 {
> i2c at 0 {
> eeprom at 54 {
> mac_address: mac-address at 23 {
> reg = <0x23 6>;
> };
> };
> };
> };
> };
>
> ethernet at 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 at 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 at 74 {
> #address-cells = <0x01>;
> i2c-mux-idle-disconnect;
> #size-cells = <0x00>;
> compatible = "nxp,pca9548";
> reg = <0x74>;
>
> i2c at 0 {
> #address-cells = <0x01>;
> #size-cells = <0x00>;
> reg = <0x00>;
> phandle = <0x6d>;
>
> eeprom at 54 {
> compatible = "atmel,24c128";
> reg = <0x54>;
> phandle = <0x36>;
>
> mac-address at 23 {
> reg = <0x23 0x06>;
> phandle = <0x15>;
> };
> };
> };
>
> /* ... */
>
> ethernet at 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 at 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
More information about the U-Boot
mailing list