- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Greetings,
I have a new design that includes my prototype baseboard which has an i210-it and a Qseven CoM that includes an E3815 Atom and an i210. I'm following the directions from document 513655 to program the blank flash for my baseboard's i210. Running EEUPDATE shows my two i210 controllers (one working, and one blank). Using both EEUPDATE & LANConf to attempt to program the blank flash results in a timeout error that occurs after 5+ minutes of the tool claiming that it is writing to flash.
LANCOnf gives the following: c86a0004 - "Timeout Error" when programming i210 blank flash
I'm using the following versions on an Intel Atom E3815 processor on Ubuntu 16.04.2
eeupdate64e: EEUPDATE v5.26.17.11
lanconfig64e: LANConf v1.26.17.11
lshw shows the driver as: driver=igb driverversion=5.3.0-k
I've tried flashing with multiple 4Mb files onto a 4Mb flash On Semi LE25U40CMC
Below is the eeupdate log:
_________________________________________________________
root@ubuntu-serv-slim:/# ./eeupdate64e /NIC=1 /DATA Dev_Start_I210_Copper_NOMNG_4Mb_A2_3.25_0.03.bin
Using: Intel (R) PRO Network Connections SDK v2.26.17
EEUPDATE v5.26.17.11
Copyright (C) 1995 - 2015 Intel Corporation
Intel (R) Confidential and not for general distribution.
Driverless Mode
NIC Bus Dev Fun Vendor-Device Branding string
=== === === === ============= =================================================
1 2 00 00 8086-1531 Intel(R) I210 Blank NVM Device
2 4 00 00 8086-1533 Intel(R) I210 Gigabit Network Connection
Writing SHARED FLASH. PLEASE DO NOT INTERRUPT THIS PROCESS.
1: Shared Flash image update FAILED! Timeout Error
_____________________________________________________
Things I've learned in debugging:
1) I can program the flash off board and then the I210 is recognized.
2) After flashing off board, EEUPDATE can reprogram the flash using the same file that timed out originally including update the check sum.
Is there some bit that needs to be set or a flag to allow for programming blank flash? Does is need a MAC address first? I'm sure it's something simple/stupid but any help you can provide is appreciated.
Enjoy,
Jason
p.s. This was originally posted in "Wire Ethernet" and was requested to move to embedded.
Link Copied
- « Previous
-
- 1
- 2
- Next »
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Anton,
Great info. I implied from Table 2-1 Pull-Up Resistors that there was an internal pull-up on NVM_SO but I'll add an external and give it a try. I'll try the bin + MAC as well ordering as well. What OS did you use? Did you only try 32-bit or did both 32 & 64 bit work?
Thanks!
Jason
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jason,
Yes the documentation is not perfectly clear on the pull-ups. You are right that the datasheet Table 2.1 actually states that an external pull-up is not required but the design checklist states: "If a Flash is not used add a 3.3 KΩ pull-up to NVM_SO(14).". Not sure if it makes a difference but I added it just in case.
The CPU is an Intel Atom E3826 Dual Core and I'm currently running a custom Yocto BSP, Linux 3.14.4 where only the 32-bit version eeupdate can execute, but I also used the Linux_x64 version with Ubuntu 16.04 and the DOS version from a bootable USB-stick and they all work fine if I remember correct.
Regards
Anton
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, AntonN:
Thanks for your reply.
Based on your previous communication, could you answer our communication of the past March 10th, 2017 8:58 AM?
Waiting for your answer.
Best regards,
Carlos_A.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Additional results...I finally bit the bullet and erased the Flash and EEPROM of the COTS Qseven I210. To this point all testing was done on my carrier board I210. Rerunning EEUPDATE on the Qseven with blank Flash resulted in the same timeout error. I moved the Qseven to the vendor's development board that has no other Ethernet controllers and got the same timeout error. This debunks my theory that the tool didn't like dual I210s, but makes EEUPDATE look more like the source of the failure, or at least the 64-bit version. I plan to test the 32-bit install when I get my development board back from my coworkers.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jason,
I have had very similar experience to you. I have a COM Express module with an i210 and my carrier board also has an i210.
I have actually gotten the external flash to program; but not quite sure how.
it was some combination of running in
- 'driver mode' vs. 'driverless mode'
- running eeupdate64e with .bin file then running directly afterwards the same command string but with the .hex file.
- or maybe running with the .hex file and power cycling
I did a lot of experimenting, rebooting, power cycling, mucking with lanconf64e
I have a few more boards to process; to see if I can establish a method.
Maybe Intel can comment on when one should use .hex versus .bin ?
In my screen shots below i have renamed
For ease of typing I renamed Dev_Start_I210_Copper_NOMNG_4Mb_A2_3.25_0.03.bin to CTII210.bin
-Matt
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, matt.l.ferraro and Jason.Bean :
Thanks for your updates.
In order to help you, could you please try to reproduce this situation with a /debug to the end of the command line and let us know the results? i.e. ./eeupdate64e /nic=3 /d image.bin /debug
Waiting for your reply.
Best regards,
Carlos_A.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Carlos,
I tried with debug option and got the following immediately after running the command:
1: The update cannot be performed. Adapter do not support Debug mode flash write.
I also tried the bin/hex combo with power cycling and haven't been successful yet either.
Thanks,
Jason
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, Jason.Bean and matt.l.ferraro:
Thanks for your update.
For i210 device '/debug' cmd option is unavailable, so the error message is expected here. It should, however, work in the blank mode without this switch.
On the other hand, in order to better understand this situation, could please update process be decoupled from setting MAC addresses? Also, could you give us both images (dumped from the adapter and the one to be updated too)?
We really appreciate your help to solve this inconvenience.
Best regards,
Carlos_A.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Carlos,
Attached is the dumped bin and the one I've attempted to upload. Both files work once put on the Flash, but neither file works using EEUPDATE on a blank NVM. I've tried the commands with the MAC option and without and not seen any difference in performance.
Enjoy,
Jason
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, Jason.Bean and matt.l.ferraro:
Thanks for your reply.
We notice that 2 images seem to be incompatible:
We mean these are dedicated for different Flash size (0,5 MB vs 2 MB) and also FPA pointers are significantly different, which in the case of the 0,5MB image (jab_I210 seems unreasonable).
We hope that this information may help you to solve this inconvenience.
Best regards,
Carlos_A.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Carlos_A,
Thanks for the review. I'm not surprised that my edited file has issues, but I've tried all the stock Intel binaries for 4Mb files with no luck. I've also programmed my edited file using an external controller and gotten great results. The theme of this thread is that a lot of us are having problems with the Intel tool. Please don't let my edited binary file distract from the larger issue that Intel should be addressing. If you followed my notes earlier (4/25/2017), you would also see that I erased the Adlink I210 controller and was not able to reload it's original flash onto the blank NVM. This tells me that the root of the problem is not in the binary files (or the OS, or the speed of the flash, or the inclusion/exclusion of MAC addresses, or board layout, or number of controllers), but in the tool.
Thanks for sticking with this and helping get a solution for all of us.
Enjoy,
Jason
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jason,
I had the same issue trying to program a blank flash w/eeupdate and what I found is that the driver iqvlinux that I used was not compatible with the kernel.
I tried an old version I had available with the following command:
insmod iqvlinux.ko
The old version I had of the iqvlinux solved the problem. Unfortunately, I can't give you more details about the version I tried since I'm an electrical engineer with limited knowledge in SW but I hope this can give you a good hint.
Best regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Leonardo_saldivar. I'm not using that driver, but this gives me a new path to explore that I hadn't yet. I'll see if I can roll back versions and get different results.
Enjoy,
Jason
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Jason,
I have finally gotten eeupdate64e to program to boards consistently.
The latest version seems to have fixed the problems I was having. As well as a 1K pulldown on NVM_SI
It is part of part of 348742_Quartzville_Tools_460903.zip
See below console output below.
Hope this helps
-Matt
root@type7ubuntu:/usr/cti/software/intel/OEM_Mfg2# ./eeupdate64e /nic=3 /d CTII210.bin /MAC=000C8B7173FA
Using: Intel (R) PRO Network Connections SDK v2.29.5
EEUPDATE v5.29.05.02
Copyright (C) 1995 - 2017 Intel Corporation
Intel (R) Confidential and not for general distribution.
NIC Bus Dev Fun Vendor-Device Branding string
=== === === === ============= =================================================
1 4 00 00 8086-15AC Intel(R) Ethernet Connection X552 10 GbE SFP+
2 4 00 01 8086-15AC Intel(R) Ethernet Connection X552 10 GbE SFP+
3 9 00 00 8086-1531 Intel(R) I210 Blank NVM Device
4 10 00 00 8086-1533 Intel(R) I210 Gigabit Network Connection
Writing SHARED FLASH. PLEASE DO NOT INTERRUPT THIS PROCESS.
3: Shared Flash image updated successfully.
3: Updating Mac Address to 000C8B7173FA...Done.
3: Updating Checksum and CRCs...Done.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, matt.l.ferraro:
Thanks for your update.
We are glad that your problem has been fixed and you have shared this information.
Best regards,
Carlos_A.
![](/skins/images/B7BA37F9CE4B52FF7CAE1FB0388839C8/responsive_peak/images/icon_anonymous_message.png)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »