Hi, we have been redirected here from this thread in the embedded community: https://embedded.communities.intel.com/message/21897# 21897 ARM tools for 82574 |Embedded Community
To summarize the important parts of our previous discussion, we have an Intel EXPI9301CT Gigabit CT PCI-e Desktop Adapter, which has an 82574 controller and a Winbond W25X40BVNIG flash. We are trying to use the eepromARMtool to reprogram the MAC address in the flash.
Running ./eepromARMtool -dump -NIC=1 gives us a file whose first line is:
8888 8888 8887 0C20 F746 2014 FFFF FFFF
We want to change the MAC address, so we edit the file that was dumped and change the first line to:
70B3 D501 C307 0C20 F746 2014 FFFF FFFF
Then we run ./eepromARMtool -write -NIC=1 -f=new_mac.otp. If we run the dump command again, the flash appears to have the correct contents. However, if we reboot or power cycle the machine and dump again, the output has returned to its original contents. This seems to imply that our changes were not actually flushed to the flash.
Do you have any advice for how to fix this problem? Thank you!
Thank you for posting in Wired Communities. We will need to further check on this as this is relevant to design of the ethernet controller 82574 on the CT desktop adapter.
Please share additional information below for us to better assist you.
1. GbE NVM dump file (GbE dump using the two options in Lanconfig, the Raw EEPROM dump and the dump file under Flash option)
2. Please ensure the system is properly rebooted to ensure the new MAC address become valid. This is usually the reason why EEupate can still see old MAC address. The key is to reboot systems whenever you use EEudpate to change any value in GbE NVM.
3. What are the environment you are using? EFI shell, Windows or Linux environment? Please make sure you are using the latest LAN driver and LAN tools if you are using Windows or Linux environment, please provide the LAN driver version.
4. Can you share the version off the GbE NVM, we want to make sure the correct version is being used.
To be clear, we are trying to use the eepromARMtool provided to us by Carlos in the discussion that I linked to previously. I've plugged the NIC into an x86 machine so that I can answer all of your questions, but we need a solution that works with eepromARMtool.
1. I've attached the two files you requested, as well as the file that we get from running `./eepromARMtool -dump -NIC=1` on an ARM machine.
2. We've been sure to reboot the system each time we try to update the flash.
3. On our Arch Linux (ARM) environment, we use the eepromARMtool provided to us by Carlos, which we presume is the most recent. That machine is a Jetson TK1 running NVIDIA's Linux for Tegra version R21.5; we are using the e1000e driver provided by that distribution.
4. According to LANConf, our NVM version is 2.1.
Something that I noticed in answering your questions is that we are unable to write to the flash using LANConf. If we go to EEPROM/FLASH --> NVM Image --> Update Image and give it a binary file it gives the message "Shared flash write not supported!" Is that expected?
Thank you for your help!
Please provide additional information below:
1) Is this design new?
2) Please check the power up and down sequence timing of 3.3v, 1.9v, and 1.05v with a scope or logic analyzer and provide us the result.
Looking forward to your reply.
To clarify again, this is a board that we purchased (you can see it here: https://www.amazon.com/Intel-EXPI9301CT-Gigabit-Desktop-Adapter/dp/B001CXWWBE/ref=sr_1_1?rps=1&ie=UTF8&qid=1526499880&sr=8-1&keywords=intel+82574&refinements=p_85:2470955011 Amazon.com: Intel EXPI9301CT Gigabit CT PCI-e Desktop Adapter: Electronics). It is not our own design, so we don't know how new it is. Given this information, please let us know if you would still like us to check the power up/down sequence.