We have a board that is being adapted for a new product.
The platform is Windows 7 Embedded.
Previously the i210 was programmed with I210_Invm_SerDesKX_APM_v0.6.txt for a direct SGMII connection to a Vitesse VSC7438YIH switch.
We are now adapting this to a new setup using an external PHY (the DP83867). Our prototype was originally programmed with the I210_Invm_SerDesKX_APM_v0.6.txt as for other products.
Subsequently I have modified the file to:
After this the device driver in Windows claims the device has an error.
I tried subsequently to change the Device ID to 0x15F6 but am not getting a "unable to merge error" with eeUpdate.
What file do we need to program for this extranl PHY setup?
What is causing the "Unable to merge error" with the device as I cannot even put back the original file into the device.
All help appreciated.
Thank you for contacting Intel Embedded Community.
Could you please let us know if the design related to this thread has been developed by you or it is a third-party device? In case that it is a third-party unit, please let us know the part number, model, name of the manufacturer, and where is stated the information related to it. On the other hand, in case that it is your design , please inform the sources that you have used to develop it.
We are waiting for your reply.
PS Answer to your question below: But the lanconf is unable to initialize the adapter at this stage (after I programmed in the modified iNVM value. Is there a way to bring the adapter back to default or undo the iNVM settings?
Reading other replies I understand that the iNVM is OTP and limited rewirtes.
So I am switching to another board.
What I need know is the SKU and other settings for an external PHY using a flashless i210.
Would I use the SKU of 0x1538 even though it is flash less. 0x15F6 doesn't mention i210IS even though it is flashless.
What other settings apart from the link CTRL_EXT.Link_Mode being set to SGMII (10b)?
Any urgent help appreciated to avoid burning out iNVM on more boards.
This is our own design based on BeyTrail based on the Valley Island design from Intel.
We have the basic design of this motherboard is already in use in a product for at least a year now. The I210 SGMII interface goes off to a daughter board from this common motherboard.
The previous daughter board was an SGMII to SGMII interface. This new daughter board is an SGMII to PHY interface. The PHY is a DP83867.
Thus the circuity from the CPU to the i210 is the same .
Thanks for your update.
Could you please verify if your implementation fulfills the suggestions stated at the following thread mentioned as a reference?
In case that there are discrepancies you should contact the PHY manufacturer as a reference at the channels listed at:
We are waiting for your answer.
We are using magnetics so the thread does not relate to out situation too much.
Also we are after the firmware settings.
Currently we believe that the connection between the PHY and the i210 is working as we can read the PHT registers (using lanconf) and see the default values of the registers.
Furthermore when we connect the PHY to a LAN port on a computer we can see (through the PHY registers that is has negotiated a connection and the link is up.
So the main issue that remains is that Windows is not able to initialize the driver when we setup this PHY connection using device id 0x1538. Everything else seems to be working (although requires through testing once the driver is working).
Please see the file attached that we used to program the iNVM. This is where I believe there may be an issue.
We have used the Device ID 0x1538 (register 0x2). Is this correct or do we need to use 0x15F6 since it is a a flashless device. 0x15F6 is not mentioned in the main datasheet but in the I210 Specification Update (April 2019: Revision 2.6
Or are there other issues with out iNVM settings.
I have tried the latest 24.1 release of the drivers for Windows7 x64 (the target OS for this device).
Please answer this firmware question as we can only test the hardware once we have this configured properly.
Firstly I will update with the progress I have made in case it helps others: Then I will answer your question in the next comment @Mæcenas_INTEL
Thanks for your updates.
Could you please give all the information related to the driver associated to the cited condition? Please mention where you find it, the name of the developer, and the details that you consider important.
We are waiting for your clarification.
We are using drivers and firmware iNVM files from Intel.
The driver (Windows 7) is:
The firmware iNVM programming details are above but we initially programmed:
This file was modified to the file attached above to setup to use and External PHY. I have attached our modifed iNVM file above twice but will attach yet again to this post.
I will request again to
Thanks for your clarification.
Based on your previous communication, could please try to reproduce the reported problem after run Intel(R) Driver & Support Assistant [Intel(R) DSA] and let us know the results? It can be found at:
Could you please let us know the name, document #, and version of the tools that you used to program the iNVM? By the way, please give also this information for the iNVM.
By the way, could you please list the sources that you use to design your project as we requested the past July 12th, 2019?
We are waiting for your answer.
Please see answers to you queries below. I will replay with some follow up question too after these.
Intel(R) Driver & Support Assistant [Intel(R) DSA]
iNVM Programming Tools
Project Design Source:
Please not this is now an urgent issue specially if we may need to change designs.
Thanks: So is there an error in the specs and specs update below?
Please also provide a list of i210's available with the same footprint so we may see what we may able able to replace with.
Thanks for your updates.
All of the i210 chips have the same pins footprint, the CS/CL model add 4 solder points at the 4 corners.
The SGMII implementation is designed for talking to a SFP cage, as it adds in I2C control signals.
For backplane/chip to chip communications, we suggest using the Serdes KX protocol, which is already available in the iNVM file package.