Embedded Connectivity
Intel network controllers, Firmware, and drivers support systems
848 Discussions

Programming i210 Blank Flash w/ EEUPDATE & LANConf

JBean1
Novice
20,260 Views

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.

0 Kudos
35 Replies
JBean1
Novice
2,787 Views

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

0 Kudos
ANord3
Beginner
2,787 Views

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

0 Kudos
CarlosAM_INTEL
Moderator
2,787 Views

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.

0 Kudos
JBean1
Novice
2,787 Views

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.

0 Kudos
MFerr12
Beginner
2,787 Views

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

0 Kudos
CarlosAM_INTEL
Moderator
2,787 Views

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.

0 Kudos
JBean1
Novice
2,787 Views

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

0 Kudos
CarlosAM_INTEL
Moderator
2,787 Views

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.

0 Kudos
JBean1
Novice
2,787 Views

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

0 Kudos
CarlosAM_INTEL
Moderator
2,787 Views

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.

0 Kudos
JBean1
Novice
2,787 Views

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

LSald1
Beginner
2,787 Views

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

0 Kudos
JBean1
Novice
2,787 Views

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

0 Kudos
MFerr11
Beginner
2,787 Views

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.

0 Kudos
CarlosAM_INTEL
Moderator
2,787 Views

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.

0 Kudos
Reply