We have been using the 32-bit version of eeupdate (eeupdate32 from the Quartzville tools package) for programming the MAC addresses in our Intel 82574L NICs for a while now.
After updating the OS to 64 bit (CentOS 6), I get an error running the
64 bit version of the tool:
================
$ uname -a
Linux test0 2.6.32-696.28.1.el6.x86_64 # 1 SMP Wed May 9 23:09:02 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
$ sudo /usr/local/bin/eeupdate64e /d /home/test/intel/tools/quartzville/TOOLS/Linux32/OEM_Mfg/82574_APT_A1_EE.eep /mac=00a069020d3\
b /nic=2
Using: Intel (R) PRO Network Connections SDK v2.28.1
EEUPDATE v5.28.01.06
Copyright (C) 1995 - 2016 Intel Corporation
Intel (R) Confidential and not for general distribution.
Driverless Mode
NIC Bus Dev Fun Vendor-Device Branding string
=== === === === ============= =================================================
1 0 25 00 8086-1502 Intel(R) 82579LM Gigabit Network Connection
2 2 00 00 8086-10D3 Intel(R) 82574L Gigabit Network Connection
3 3 00 00 8086-10D3 Intel(R) 82574L Gigabit Network Connection
4 4 00 00 8086-10D3 Intel(R) 82574L Gigabit Network Connection
5 5 00 00 8086-10D3 Intel(R) 82574L Gigabit Network Connection
Unable to initialize adapter 2 code c86a2002
Adapter initialization failed
The kernel log messages show:
kernel: Program eeupdate64e tried to access /dev/mem between f7000000->f7020000.
kernel: Program eeupdate64e tried to access /dev/mem between f7020000->f7024000.
================
That was the 20161005 version of the quartzville tools that we've been using
successfully (32 bit version). I downloaded the 20180202 version of
the tools (23.0) and got the same result with the 64 bit flavor
(eeupdate64e):
Using: Intel (R) PRO Network Connections SDK v2.30.25
EEUPDATE v5.30.25.06
Copyright (C) 1995 - 2017 Intel Corporation
It also added another complaint:
Connection to QV driver failed - please reinstall it!
But I've had success in the past running in "QV Driverless Mode". Why not now (if that is part of the problem)?
Anyone have an explanation of that error code spewed by eeupdate? Why does the 32 bit version of eeupdate32 work and the 64 bit does not?
链接已复制
Hello, JohnH :
Thank you for contacting Intel Embedded Community.
In order to be on the same page, could you please clarify us if the affected design has been designed by you or it is a third-party vendor device? In case that it is a third-party project, please let us know all the information related to it. On the other hand, if the design has been developed by you please let us know if it has been reviewed by Intel.
Please let us know the requested information.
Best regards,
Carlos_A.
Designed by us. I don't know if it was reviewed by Intel.
I don't suspect the meaning of code c86a2002 will change in any case. What does it mean?
Hello, JohnH:
Thanks for your update.
Could you please send your design to be reviewed following the procedure stated on the following website? Please let us know the results.
https://edc.intel.com/Tools/Design-Review/Default.aspx?language=en&r=443163996 https://edc.intel.com/Tools/Design-Review/Default.aspx?language=en&r=443163996
Waiting for your reply.
Best regards,
Carlos_A.
I understand why you would like to verify the hardware design in order to be helpful. I don't understand why the error code can't be explained regardless of the schematic review. If this source code is available, I could just look myself. But I _think_ it's not, so I have to rely on the tool author's documentation to define error codes. If the source is available, then I'm sorry I missed it - point me at it, and I'll figure it out myself.
By the way, I got an email outside the forum...
Carlos_A wrote at 09:09 -0700 on May 22, 2018:
> Could you please confirm us if the problem persists with the Intel I210, I211, and X550 EEPROM Access Tool (EAT) document # 572162?
Yes, EAT works. I had to add # include to the eeprom source file (PciEeprom.c) to get the tool (EepromAccessTool) to fully build.
It does trigger some warnings, but they don't seem to prevent the tool from working:
May 23 23:46:43 localhost kernel: Program EepromAccessToo tried to access /dev/mem between f7000000->f7020000.
May 23 23:46:43 localhost kernel: Program EepromAccessToo tried to access /dev/mem between f7020000->f7040000.
Those warnings occur whether iqvlinux.ko is loaded or not. Not a surprise necessarily - just thought I'd mention it.
Also there is no -mac=XXXXXXXXXXXX option for EAT, however, so I had to edit the .eep file, noticing / guessing that the MAC is in the first 6 bytes. Fortunately the EAT will compute the right checksum, so I didn't have to manually fix that before writing to the eeprom with the modified image file. So the lack of -mac is just a minor inconvenience.
Unlike eeupdate64e, however, it seems to be quite happy writing to the NVM.
So EAT works. eeupdate32 works when the OS is 32 bit. And we've been using this design for years with no problems reading/writing to the NVM. Kinda seems like the hardware design is fine (although it could be a unique hardware problem on a particular unit). I'll still work on getting the schematic from our hardware engineers so it can be reviewed, but in the mean time, understanding what the error code means would be pretty helpful.
I also met this error c86a2002 (eeupdatew64e.exe in Windows 10), but there is no problem using another windows system (Windows To Go USB etc.) with same software (eeupdatew64e.exe in Windows 10). However, I didnot find out the different between the systems. Maybe some limitation from other software.
Hello, @yeziqiang:
Thank you for contacting Intel Embedded Community.
We suggest using the updated version of the EEupdate tool that can be found included in the Intel(R) Network Connections Tools 24.0 PV LAN Software Tools document # 348742. You can find it when you are logged into your Resource & Design Center (RDC) privileged account on the following website:
http://www.intel.com/cd/edesign/library/asmo-na/eng/348742.htm
The RDC Account Support form is the channel to process your account update request or report any inconveniences with the provided website. It can be found at:
https://www.intel.com/content/www/us/en/forms/support/my-intel-sign-on-support.html
Best regards,
@CarlosAM_INTEL Thanks Carlos, with the updated tool (348742_Quartzville_Tools_596815), the error code disappeared.
Hello, @yeziqiang:
Thank you for contacting Intel Embedded Community.
We are glad that our suggestion helps you.
Please do not hesitate to contact us again if you have any questions related to Intel Embedded products.
Best regards,
I am getting the same error. Design is unchanged for the last couple of years. Using linux eeupdate64 and now some cards return the following when trying to set copper mode and a MAC address:
Using: Intel (R) PRO Network Connections SDK v2.32.6
EEUPDATE v5.32.06.06
Copyright (C) 1995 - 2018 Intel Corporation
Intel (R) Confidential and not for general distribution.
Driverless Mode
NIC Bus Dev Fun Vendor-Device Branding string
=== === === === ============= =================================================
1 1 00 00 8086-1531 Intel(R) I210 Blank NVM Device
Unable to initialize adapter 1 code c86a2002
Adapter initialization failed
What does the code c86a2002 mean? We've been successful configuring other cards of the same design.
Hello, @WWebb:
Thank you for contacting Intel Embedded Community.
You should use the latest version of the cited that can be found in the Intel(R) Network Connections Tools PV LAN Software Tools document # 348742. You can find it when you are logged into your Resource and Design Center (RDC) privileged account on the following website:
https://cdrdv2.intel.com/v1/dl/getContent/348742
You should fill out the form stated on the following website when you have problems with the provided websites or want to update your RDC account:
https://www.intel.com/content/www/us/en/forms/support/my-intel-sign-on-support.html
Best regards,
The c86a2002 also happens when the configuration in the chip is wrong. E.g., I set the device from 1532 (Intel(R) I211 Blank OTP Device) to 1539 (Intel(R) I211 Gigabit Network Connection), and then set the MAC as "000000000000" using EEUPDATEW64e.exe in windows 10. After restart, the chip will be detected as 1539 and uses the driver for example C:\Windows\System32\drivers\e1i63x64.sys. At this time, EEUPDATEW64e.exe or lanconfw64e.exe works not more.
We can delete/rename the driver file as temporary solution, to make sure the chip was not detected as others.
