- 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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, Jason.Bean:
Thank you for contacting Intel Embedded Community.
In order to better understand this situation, could you please try to reproduce this situation using one of the Operating Systems listed on page 3 of the http://www.intel.com/content/dam/www/public/us/en/documents/platform-briefs/atom-processor-e3800-platform-brief.pdf Platform Brief: Intel® Atom™ Processor E3800 Product Family and let us know the results in a detailed way?
We really appreciate your cooperation.
Best regards,
Carlos_A.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jason.Bean,
I have not seen this problem but i would definitely try loading a MAC address. I have seen issues with eeupdate not behaving as expected without a mac address loaded.
Hope it helps
RobH
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tried to update the MAC address of the blank Flash an got a "Failed" error. My next step is to boot to a different OS, but I'm curious if anyone has had success with the bit-banging access mentioned in 3.3.1 of the datasheet "For the first programming of a blank Flash, it is the host's responsibility to remove the write protection from the Flash part via bit-banging access"
It seems similar to the discussion in:
I didn't see a solution other than the fact that the tool should be doing the bit-banging already.
I confirmed that my flash supports all the same OpCodes referenced on pg. 53 of the datasheet.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, Jason.Bean:
Could you please tell us if you have tried our last suggestion? In case that your answer is affirmative, please let us know the results.
Thanks again for your cooperation to solve this situation.
Best regards,
Carlos_A.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Carlos,
Just got my board back and booted up with Fedora and got identical timeout error. It failed with EEUPDATE and also failed with updating just the MAC address. Any other suggestions?
Writing SHARED FLASH. PLEASE DO NOT INTERRUPT THIS PROCESS.
2: Shared Flash image update FAILED! Timeout Error
NIC Bus Dev Fun Vendor-Device Branding string
=== === === === ============= =================================================
1 4 00 00 8086-1533 Intel(R) I210 Gigabit Network Connection
2 2 00 00 8086-1531 Intel(R) I210 Blank NVM Device
2: Updating Mac Address to 00209D23C751...Failed!
Enjoy,
Jason
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, Jason.Bean :
We really appreciate your reply.
Based on your previous messages, we would like yo address the following questions:
Could you please verify that the cited flash memory fulfills with the I2C timing parameters of the Intel i-210? It can be reviewed with the assistance of the Flash memory manufacturer. These parameters information is stated in section 11.6.2.3, on page 785 of the http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/i210-ethernet-controller-datasheet.pdf Intel(R) Ethernet Controller I210 Datasheet document # 333016.
Could you please confirm that the NVM flash is designed with the i210 correctly?
Could you please clarify if the affected design has been reviewed by Intel? In case that your answer is negative, you can use this service following the steps stated at the https://edc.intel.com/Tools/Design-Review/Default.aspx?language=en Design Review Services website.
Please give us the answers to these questions in order to have a better idea of this inconvenience.
Best regards,
Carlos_A.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Carlos,
I'll start the design review because that has not been done. Regarding your first question about I2C/SMBus, I'm confused what this has to do with Flash. The SMBus communicates with the processor. Flash has a SPI interface to the i210. Please elaborate as my brain is moving slow
I've double/triple checked the Flash/i210 interface. I'm also able to read/write to a non-empty Flash. This same chip also worked with the 82574 in my previous design.
Thanks,
Jason
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, Jason.Bean :
Thanks for your reply.
We apologize for the confusion, the proper section is 1.6. 2.4, specifically the Table 11-11, on page 786 of the cited Datasheet. There you can find the Flash I/F Timing Parameters.
We hope that this clarification may help you.
Best regards,
Carlos_A.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I swapped out my Flash with a faster chip that meets/exceeds the specs in the datsaheet and got the same error. One a second board I duplicated the process of programming my Flash externally and then putting on the board. After doing this, the part has not problem getting reprogrammed with an update checksum or all new binary.
Based on all the tests, it appears that the bit-banging process referenced earlier is not happening correctly to enable writing to a blank flash. Is there a different tool that is capable of doing this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, Jason.Bean :
Thanks for your update.
We have the idea that the Lanconf tool cannot recognize the JEDEC id of the NVM. By the way, it ignores the command opcodes to send to delete/write the chip when it is blank.
By the way, could you please verify if the cited condition happens with any of the devices listed in section 11.8, on pages 793, 794, and 795 of the http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/i210-ethernet-controller-datasheet.pdf Intel(R) Ethernet Controller I210 Datasheet document # 333016?
Also, could you please give us all the information of the Flash device that you are using?
We really appreciate your help.
Best regards,
Carlos_A.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Carlos. I've ordered some new Flash chips from the datasheet: Atmel/Adesto AT25DF081A-SSH-T)
The one's I've tested are the Winbond W25Q64FVSSIG (meets speed requirements, never tested with external programmer) and On Semi LE25U40CMC (didn't meet the max speed but works fine after external programming). I'll let you know the results when the new Flash arrives.
Enjoy,
Jason
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, Jason.Bean :
Thanks for your update.
It is important to let you know that the Lanconf will not complain about any flash device out of the list mentioned in our previous communication, as long as it is compatible with Intel's generic algorithm.
We hope that this information may help you.
Best regards,
Carlos_A.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I installed the Atmel/Adesto AT25DF081A-SSH-T from the I210 datasheet and got the same results. I have also run signal integrity analysis with Hyperlynx on the signals between the I210 and the Flash and all looks good. Have you encountered an issue like mine that required terminations or anything like that? I keep coming back to the issue of bit banging the write enable being the issue since the tool works find on a non-empty flash.
Enjoy,
Jason
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, Jason.Bean :
We appreciate your reply.
Based on your previous communications, could you please tell us if the affected implementations have been reviewed by Intel? In case that your answer is negative, feel free to send them using the procedures stated at the https://edc.intel.com/Tools/Design-Review/Default.aspx?language=en Design Review Services website.
We hope that this information may help you.
Best regards,
Carlos_A.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Greetings,
I've gotten feedback from the Intel Design Review services. I've implemented on the changes related to the Flash with no change in results. In addition, I pulled down pin 12 but LANCONFIG still claims the blank part is protected. The Flash menu shows Secured Flash Options at the top with the part type Flash: Protected Flash
Do you have any suggestions on how to get a part that is detected as blank to not be treated as protected?
Thanks,
Jason
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, Jason.Bean:
Thanks for your replies.
In order to be on the same page, could you please double check that the pins are pulled high/low and connected correctly? because it should not happen if the device is blank, it will not be protected by firmware. For more details please review the answer to the question 2.23, on page 9 of the http://www.intel.com/content/dam/www/public/us/en/documents/faqs/ethernet-controller-i210-i211-faq.pdf Intel® Ethernet Controller I210/I211 Frequently Asked Questions (FAQs) document # 335346.
Waiting for your update.
Best regards,
Carlos_A.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dear Jason,
We had endless problems trying to get EEUPDATE to work with
the i210 parts. We just gave up and pre-program the Flash parts before
we solder them to the board. It's a pain for us because we
have two i210s and we want them to have consecutive MAC addresses
related to the board serial number, so it's organizationally inconvenient.
It was still less painful than trying to get the obviously broken EEUPDATE
fixed though.
Thanks, Paul.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Additional Results
I put the CS, SI, SO, & CLK on the scope during boot up. I see an active CS and SK (at 3.125 MHz). SI stays low the entire time (PD resistor). Sounds like a bug with EEUPDATE that won't work with multiple controllers?? Currently the SI is pulled low, but I've also tried it pulled high. Since it has no problem reading an externally programmed Flash we know that SO is working fine. I know that the SI & PCB are good because EEUPDATE can update a non-blank flash to update MAC and checksum. Guess I'll see what iNVM is capapble of to determine if that option is better than external programming.
Thanks,
Jason
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In an effort to test out the iNVM I tried to program and got the Error code - 0x13 : INVM content can't be merged. I tried the suggested /invmislocked and got the "UNLOCKED" response but still no luck. For fun, I removed the external Flash and get the same results. I still have pin 12 pulled low and am using the stock I210_Invm_Copper_NoAPM_v0.6.txt
Any fresh ideas? I've spent months with an 82574L/I210 combo before being told they couldn't work together because of hardware addressing on the SMBus, and now with a pair of I210s it seems that none of the tools want to program a blank device, even when the blank device is the I210's own internal memory.
Verify if INVM is locked ... INVM content is UNLOCKED !
done.
---------------------------------------------
root@# ./eeupdate64e /nic=1 /invmupdate /file=I210_Invm_Copper_NoAPM_v0.6.txt
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
Update INVM content ... Verify autoload configuration ...
Error code - 0x13 : INVM content can't be merged.
NOT done !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jason,
Did you install a pull-up to the SO line (i210, pin 14), as stated in the datasheet, before attemting to program the iNVM ?
I've successfully used eeupdate to program both an empty external Flash (AT25DF081A-SSH-B) and the iNVM from Linux:
- The External flash was kind of a pain in the *** getting programmed. Took me a couple of Days experimenting with different procedures before I found one that consistently worked: I have to first program the template BIN-file + MAC-adreess, then power-cycle the device and re-program only the MAC-address, then reboot the device. Not sure if some other procedure may also work but this is the only way I successfully manage to program empty an extenral Flash.
- The iNVM was programmed succesfully at first try! First disconnected the external Flash by removing series resistor from SO, then mounted a pull-up to the SO line, then programmed with the following commands:
./eeupdate32 /nic=1 /invmupdate /file=I210_Invm_Copper_NoAPM_v0.6.txt
./eeupdate32 /nic=1 /mac=AABBCCDDEEFF
...then rebooted the device and - voila!
Our board setup seems quite similar to your's (?), having dual I210i Ethernet controllers; one located on a COM-Express Processor Module (I210i Flash pre-programmed by the module manufaturer) and the other located on the motherboard manufactured by us. As a plan-C we also prepared the PCB with test-points to allow programming the external Flash during production using an external SPI programmer (Aardvark or similar) with the I210 chip tri-stated (by pulling DEV_OFF_N pin low) - though this route has not yet been verified, it will require either generating uniquie BIN-files with MAC-address and checksum merged, or flashing only the template binary through test-points then the MAC-address with eeupdate in a later stage. A similar approach could be using JTAG/Baoundary Scan to program external Flash from the I210-controller), though an external SPI-programmer should be much faster considering the amount of data to be flashed.
Hope things will work out for you!
Regards
Anton
![](/skins/images/D3C0B914909A6564BBB97F4AD1ED1973/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