Setting MAC address from I2C EEPROM - debug / commands? (Xilinx)
Hi,
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).
My question is - is the 'i2c' command now the accepted and best way to interact with an I2C EEPROM? Or is there another command I can enable (other than "eeprom") that will provide a generic interface for accessing EEPROMs and prove that U-Boot can "see" this device?
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)
P.S. if this is better directed to Xilinx or the Xilinx community then I'm happy to do that, but in case it's a more generic U-Boot issue I thought it best to ask here first. Please don't flame me for using Xilinx, I'm trying to do my best with what I'm given.
-- David.
On 11/22/22 20:23, David Antliff wrote:
Hi,
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).
My question is - is the 'i2c' command now the accepted and best way to interact with an I2C EEPROM? Or is there another command I can enable (other than "eeprom") that will provide a generic interface for accessing EEPROMs and prove that U-Boot can "see" this device?
I don't think such an API exists.
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)
P.S. if this is better directed to Xilinx or the Xilinx community then I'm happy to do that, but in case it's a more generic U-Boot issue I thought it best to ask here first. Please don't flame me for using Xilinx, I'm trying to do my best with what I'm given.
-- David.
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.
--Sean
On 11/23/22 04:14, Sean Anderson wrote:
On 11/22/22 20:23, David Antliff wrote:
Hi,
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:
That was the old way how to this was achieve and based on DTS in the mainline it is not used on any existing board because none defined xlnx,eeprom property.
I just sent the patch to remove also Kconfig entries which we forget to clean up.
But the way how it is working now is that eeprom is referenced by nvmem alias. You can find conversion here 531abcb71e60 ("xilinx: Convert xlnx,eeprom property to nvmem alias")
Then you have nvmem link to eeprom which can be used.
In board_init() you can see calling xilinx_read_eeprom() which reads this link.
This structure was added for FRU format decoding also with supporting legacy format used on zcu1xx boards.
IIRC zcu208 is not using legacy format used on zcu1xx boards xilinx_read_eeprom_legacy() and there is one more legacy format which is not currently supported by this code. But it shouldn't be that complicated to add support for it because it is pretty much just different layout.
That's why I am suggesting you to create that nvmem0 link and take a look at that format to support.
Then mac address is saved to environment variables and used by ethernet driver.
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).
My question is - is the 'i2c' command now the accepted and best way to interact with an I2C EEPROM? Or is there another command I can enable (other than "eeprom") that will provide a generic interface for accessing EEPROMs and prove that U-Boot can "see" this device?
I don't think such an API exists.
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)
P.S. if this is better directed to Xilinx or the Xilinx community then I'm happy to do that, but in case it's a more generic U-Boot issue I thought it best to ask here first. Please don't flame me for using Xilinx, I'm trying to do my best with what I'm given.
-- David.
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.
This looks good and I see Sean wired it in the U-Boot already. It should work fine with all Xilinx formats but on boards just for MAC address. (FRU format is also designed in a way that the same boards have MAC address at the same location). The code I described above is also checking in FRU format that checksums are correct and also reading more information from it for other use cases.
Thanks, Michal
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.
This looks good and I see Sean wired it in the U-Boot already. It should work fine with all Xilinx formats but on boards just for MAC address. (FRU format is also designed in a way that the same boards have MAC address at the same location). The code I described above is also checking in FRU format that checksums are correct and also reading more information from it for other use cases.
You might also be interested in the new NVMEM layout patch series: https://lore.kernel.org/lkml/20221118185118.1190044-1-michael@walle.cc/
-michael
On 11/23/22 14:27, Michael Walle wrote:
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.
This looks good and I see Sean wired it in the U-Boot already. It should work fine with all Xilinx formats but on boards just for MAC address. (FRU format is also designed in a way that the same boards have MAC address at the same location). The code I described above is also checking in FRU format that checksums are correct and also reading more information from it for other use cases.
You might also be interested in the new NVMEM layout patch series: https://lore.kernel.org/lkml/20221118185118.1190044-1-michael@walle.cc/
This is interesting. But how can you use the nvmem-cell description for mac address reading which Sean mentioned above?
Also DT description is saying that you are particular format but it doesn't mean that data is correct. I see that pretty much you can in add_cells refuse to create description if CRCs fails but maybe any format autodetection would be good to have. AFAIK Xilinx is using 3 formats now where 2 are legacy and FRU which is very similar to onie-tlv.
Thanks, Michal
On 11/23/22 10:11, Michal Simek wrote:
On 11/23/22 14:27, Michael Walle wrote:
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.
This looks good and I see Sean wired it in the U-Boot already. It should work fine with all Xilinx formats but on boards just for MAC address. (FRU format is also designed in a way that the same boards have MAC address at the same location). The code I described above is also checking in FRU format that checksums are correct and also reading more information from it for other use cases.
You might also be interested in the new NVMEM layout patch series: https://lore.kernel.org/lkml/20221118185118.1190044-1-michael@walle.cc/
This is interesting. But how can you use the nvmem-cell description for mac address reading which Sean mentioned above?
Hasn't been implemented yet. I personally don't have such a layout, so I haven't added it.
--Sean
Also DT description is saying that you are particular format but it doesn't mean that data is correct. I see that pretty much you can in add_cells refuse to create description if CRCs fails but maybe any format autodetection would be good to have. AFAIK Xilinx is using 3 formats now where 2 are legacy and FRU which is very similar to onie-tlv.
Thanks, Michal
Hi Michal,
On 23 Nov 2022, Michal Simek wrote:
On 11/23/22 04:14, Sean Anderson wrote:
On 11/22/22 20:23, David Antliff wrote: Hi,
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:
That was the old way how to this was achieve and based on DTS in the mainline it is not used on any existing board because none defined xlnx,eeprom property.
I just sent the patch to remove also Kconfig entries which we forget to clean up.
But the way how it is working now is that eeprom is referenced by nvmem alias. You can find conversion here 531abcb71e60 ("xilinx: Convert xlnx,eeprom property to nvmem alias")
Then you have nvmem link to eeprom which can be used.
In board_init() you can see calling xilinx_read_eeprom() which reads this link.
This structure was added for FRU format decoding also with supporting legacy format used on zcu1xx boards.
IIRC zcu208 is not using legacy format used on zcu1xx boards xilinx_read_eeprom_legacy() and there is one more legacy format which is not currently supported by this code. But it shouldn't be that complicated to add support for it because it is pretty much just different layout.
That's why I am suggesting you to create that nvmem0 link and take a look at that format to support.
Then mac address is saved to environment variables and used by ethernet driver.
Thank you for your advice - if I were using a newer version of U-Boot I would certainly look into this. Please see my reply to Sean for what I ended up doing, which is obviously prior to any nvmem-cells support, and uses the old Kconfig options and xlnx,eeprom.
I'm using PetaLinux 2021.2, but I note that in the 2022.1 changelog there is this:
U-Boot: Added support for reading MAC address from multi-record FRU data in EEPROM
Unfortunately until I have a chance to update my version of PetaLinux, I am unable to test or contribute to the head of U-Boot. Thank you for your help though. This all adds context to what I'm doing, and makes me think I really should figure out how to update to a newer version of U-Boot sooner rather than later.
-- David.
Hi Sean, thank you for your reply.
On 23 Nov 2022, Sean Anderson wrote:
On 11/22/22 20:23, David Antliff wrote:
My question is - is the 'i2c' command now the accepted and best way to interact with an I2C EEPROM? Or is there another command I can enable (other than "eeprom") that will provide a generic interface for accessing EEPROMs and prove that U-Boot can "see" this device?
I don't think such an API exists.
Ok, that's not a problem, I can use the i2c commands to retrieve/write what I need. It's mostly for debugging at this point.
This doesn't directly address your question, but have you tried using nvmem-cells?
[snip]
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.
Thanks for the suggestion however at the moment I am stuck with an older version of U-Boot that does not support nvmem-cells. It looks like a good approach though!
For the record, and in case it helps anyone else in a similar situation with an older U-Boot, was able to get U-Boot 2021.01 (part of PetaLinux 2021.2) to read the MAC address from EEPROM with the following settings:
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
# This is a PetaLinux config thing - has to be "invalid": CONFIG_SUBSYSTEM_ETHERNET_PSU_ETHERNET_3_MAC="ff:ff:ff:ff:ff:ff"
# PetaLinux / yocto: meta-user/recipes-bsp/device-tree/files/system-user.dtsi /include/ "system-conf.dtsi" / { chosen { xlnx,eeprom = &eeprom; }; };
This corresponds to an existing alias in the default PetaLinux device tree:
eeprom = "/axi/i2c@ff030000/i2c-mux@74/i2c@0/eeprom@54";
Which is already present as:
i2c-mux@74 { compatible = "nxp,pca9548"; #address-cells = <0x00000001>; #size-cells = <0x00000000>; reg = <0x00000074>; i2c-mux-idle-disconnect; i2c@0 { #address-cells = <0x00000001>; #size-cells = <0x00000000>; reg = <0x00000000>; phandle = <0x0000006b>; eeprom@54 { compatible = "atmel,24c128"; reg = <0x00000054>; phandle = <0x0000006c>; }; };
I'll definitely look to use nvmem-cells when I am able to update to a newer version of U-Boot though. Thank you for your help.
-- David.
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.
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-idDo 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
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.
On 6/11/23 David Antliff wrote:
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]
> > 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.
This was the hint I needed to solve this - thank you.
Turns out that PetaLinux (sigh) was injecting the ff:ff:ff... MAC address into the device-tree build, which is where local-mac-address was coming from. As you mentioned, and as I can now see in eth-uclass.c, the NVMEM subsystem isn't used if either of these nodes are defined.
Although PetaLinux's own config insists on setting a MAC address, I was able to set it to a blank string which results in a DT node, but with no value. This seems sufficient to get past the checks for "{local-,}mac-address" and call the NVMEM functions instead.
project-spec/configs/config:
CONFIG_SUBSYSTEM_ETHERNET_PSU_ETHERNET_3_MAC=""
For anyone else coming across this, here's my final DT snippet:
axi { i2c@ff030000 { i2c-mux@74 { i2c@0 { eeprom@54 { #address-cells = <1>; #size-cells = <1>; compatible = "atmel,24c128"; reg = <0x54>;
mac_address: mac-address@23 { reg = <0x23 6>; }; }; }; }; };
ethernet@ff0e0000 { nvmem-cells = <&mac_address>; nvmem-cell-names = "mac-address"; }; };
Also, it appears that 'compatible = ... , "nvmem-cells";' on the EEPROM node is not required.
Thank you for the hints!
-- David.
participants (4)
-
David Antliff -
Michael Walle -
Michal Simek -
Sean Anderson