I can't get the flash attached to an I210 to program

[PWilc1]

I am trying to program the Flash attached to an I210 part.

The flash device is the Intel validated W25Q16DWSSIG.If I try setting the MAC address, I get the following message.

4: Updating Mac Address to 382C4AC86400...Failed!

If I write to word 0 and then read it back, value remains

there, but if I do a MAC_DUMP, it shows zero. I can loadthe other data using /D and can read that back. However,if I cycle power, all the data returns to zero.

I have done some basic hardware checks, like verifying that clocks

go to the Flash device and that it's powered up and that WriteProtect is not asserted.

Anyone have any idea what could be wrong here?

Thanks in anticipation!

The text from the actual commands is listed below.

C:\>eeupdate /NIC=4 /MAC=382c4ac86400

I get:

Using: Intel (R) PRO Network Connections SDK v2.25.20

EEUPDATE v5.25.20.03Copyright (C) 1995 - 2015 Intel CorporationIntel (R) Confidential and not for general distribution.NIC Bus Dev Fun Vendor-Device Branding string=== === === === ============= ================================================= 1 0 25 00 8086-153A Intel(R) Ethernet Connection I217-LM 2 1 00 00 8086-10D8 Intel(R) 82599EB Dual 10 Gigabit Ethernet Connec 3 1 00 01 8086-10D8 Intel(R) 82599EB Dual 10 Gigabit Ethernet Connec 4 9 00 00 8086-1531 Intel(R) I210 Blank NVM Device

4: Updating Mac Address to 382C4AC86400...Failed!

C:\>

C:\>eeupdate /NIC=4 /WW 0 cf

Using: Intel (R) PRO Network Connections SDK v2.25.20

EEUPDATE v5.25.20.03Copyright (C) 1995 - 2015 Intel CorporationIntel (R) Confidential and not for general distribution.NIC Bus Dev Fun Vendor-Device Branding string=== === === === ============= ================================================= 1 0 25 00 8086-153A Intel(R) Ethernet Connection I217-LM 2 1 00 00 8086-10D8 Intel(R) 82599EB Dual 10 Gigabit Ethernet Connec 3 1 00 01 8086-10D8 Intel(R) 82599EB Dual 10 Gigabit Ethernet Connec 4 9 00 00 8086-1531 Intel(R) I210 Blank NVM Device

4: Successfully wrote word 0x0000 -> 0x00CF

4: Updating Checksum and CRCs...Done.

C:\>

C:\>eeupdate /NIC=4 /MAC_DUMP

Using: Intel (R) PRO Network Connections SDK v2.25.20

EEUPDATE v5.25.20.03Copyright (C) 1995 - 2015 Intel CorporationIntel (R) Confidential and not for general distribution.NIC Bus Dev Fun Vendor-Device Branding string=== === === === ============= ================================================= 1 0 25 00 8086-153A Intel(R) Ethernet Connection I217-LM 2 1 00 00 8086-10D8 Intel(R) 82599EB Dual 10 Gigabit Ethernet Connec 3 1 00 01 8086-10D8 Intel(R) 82599EB Dual 10 Gigabit Ethernet Connec 4 9 00 00 8086-1531 Intel(R) I210 Blank NVM Device

4: LAN MAC Address is 000000000000.

C:\>eeupdate /NIC=4 /RW 0

Using: Intel (R) PRO Network Connections SDK v2.25.20

EEUPDATE v5.25.20.03Copyright (C) 1995 - 2015 Intel CorporationIntel (R) Confidential and not for general distribution.NIC Bus Dev Fun Vendor-Device Branding string=== === === === ============= ================================================= 1 0 25 00 8086-153A Intel(R) Ethernet Connection I217-LM 2 1 00 00 8086-10D8 Intel(R) 82599EB Dual 10 Gigabit Ethernet Connec 3 1 00 01 8086-10D8 Intel(R) 82599EB Dual 10 Gigabit Ethernet Connec 4 9 00 00 8086-1531 Intel(R) I210 Blank NVM Device

4: Word 0x0 = 0x00CF

C:\>eeupdate /NIC=4 /D 4ac86492.eep

Using: Intel (R) PRO Network Connections SDK v2.25.20

EEUPDATE v5.25.20.03Copyright (C) 1995 - 2015 Intel CorporationIntel (R) Confidential and not for general distribution.NIC Bus Dev Fun Vendor-Device Branding string=== === === === ============= ================================================= 1 0 25 00 8086-153A Intel(R) Ethernet Connection I217-LM 2 1 00 00 8086-10D8 Intel(R) 82599EB Dual 10 Gigabit Ethernet Connec 3 1 00 01 8086-10D8 Intel(R) 82599EB Dual 10 Gigabit Ethernet Connec 4 9 00 00 8086-1531 Intel(R) I210 Blank NVM Device

Writing EEPROM. PLEASE DO NOT INTERRUPT THIS PROCESS.

4: EEPROM image (excluding MAC Address) updated successfully. 4: Updating Checksum and CRCs...Done.C:\>eeupdate /NIC=4 /RW B

Using: Intel (R) PRO Network Connections SDK v2.25.20

EEUPDATE v5.25.20.03Copyright (C) 1995 - 2015 Intel CorporationIntel (R) Confidential and not for general distribution.NIC Bus Dev Fun Vendor-Device Branding string=== === === === ============= ================================================= 1 0 25 00 8086-153A Intel(R) Ethernet Connection I217-LM 2 1 00 00 8086-10D8 Intel(R) 82599EB Dual 10 Gigabit Ethernet Connec 3 1 00 01 8086-10D8 Intel(R) 82599EB Dual 10 Gigabit Ethernet Connec 4 9 00 00 8086-1531 Intel(R) I210 Blank NVM Device

4: Word 0xB = 0x8557

C:\>

paul@adax:~/packetrunnerI/letters>

[Gabriel_T_Intel]

Hello Paul,

Welcome to the Intel Embedded Community.

We are checking your case and we will contact you as soon as possible with additional information.

Regards,

Gabriel Thomas.

[Adolfo_S_Intel]

Hello PVWB

As you can check on the I210 datasheet: http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/i210-ethernet-controller-datasheet.pdf http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/i210-ethernet-controller-datasheet.pdf section Supported Flash Parts, the model that you are using is not supported by the I210. Checking the electrical characteristics your model is 1.8V while the recommended models work between the 2.5-3.6V range.

Please make sure to use one of the supported components.

Best Regards,

Adolfo Sanchez

[CarlosAM_INTEL]

Hello paulwilcox-baker,

Thank you for contacting the Intel Embedded Community.

In order to better understand this situation, could you please confirm that are following the guidelines stated in the answers to the questions 2.9, 2.10, 2.14, 2.15, 2.18, 2.19, 2.23, and 2.25; on pages from 8 to 11 of the http://www.intel.com/content/dam/www/public/us/en/documents/faqs/ethernet-controller-i210-i211-faq.pdf Intel(R) Ethernet Controller I210/I211 Frequently Asked Questions (FAQs)?

Thanks in advance for your cooperation to find a solution to this situation.

Best Regards,

Carlos_A.

[PWilc1 · Accepted solution]

Dear Carlos and Adolpho,

Thank you for your comments.

The flash seems to be working fine at 3.3V, so let me recheck the part number.

I thought that was the part number listed by Intel as actually tested

and that was the reason we ordered them.

It turns out that the major problem was I was using the XXX.hex files to

program the part in a programmer. The FAQ document says you have to

use the .bin file. It didn't occur to me that the XXX.hex and XXX.bin files

would actually have different contents but the same XXX name. It would have been

extra, extra helpful if Intel could have included the FAQ document along

the file package!

After programming the .bin file into the Flash, it does ID correctly and

EEUPDATE allows the MAC address to be changed and the change

"sticks" after a power cycle. I haven't tried EEUPDATE for a code

change yet. So it looks as if we will have to program all the Flash

parts with one of the standard .bin files and then change the MAC

address with EEUPDATE.

Thank you for your help. However I am anticipating a range of additional

things to be solved. The other part on this this board doesn't ID at all for

some reason.

Thanks, Paul

[PWilc1]

Dear All,

Thank you very much for your help so far.

Now I get the right PCI device ID, I am having

problems with the Linux driver loading. Thedriver is the igb driver that comes as part ofSuSE linux 13.2. This driver works with the i210 inRJ45 copper mode on motherboards that we have.

As part of the Linux dmesg output I get:

[ 6.009780] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.0.5-k

[ 6.009783] igb: Copyright (c) 2007-2014 Intel Corporation.[ 6.695789] igb: probe of 0000:09:00.0 failed with error -2

The only return code of -2 is -E1000_ERR_PHY, which occurs in line 58

of the attached code. I could find this used in any other part ofthe I210 code. I would attach the routine as an separate file ,but I can't

figure out how this is done, so I'll just include it below. The other odd

thing is that in SGMII mode, the PHY is external to the I210, so why is

the code looking at the internal PHY? Thanks, Paul.

s32 igb_pll_workaround_i210(struct e1000_hw *hw)

{ s32 ret_val; u32 wuc, mdicnfg, ctrl, ctrl_ext, reg_val; u16 nvm_word, phy_word, pci_word, tmp_nvm; int i; /* Get and set needed register values */ wuc = rd32(E1000_WUC); mdicnfg = rd32(E1000_MDICNFG); reg_val = mdicnfg & ~E1000_MDICNFG_EXT_MDIO; wr32(E1000_MDICNFG, reg_val); /* Get data from NVM, or set default */ ret_val = igb_read_invm_word_i210(hw, E1000_INVM_AUTOLOAD, &nvm_word); if (ret_val) nvm_word = E1000_INVM_DEFAULT_AL; tmp_nvm = nvm_word | E1000_INVM_PLL_WO_VAL; for (i = 0; i < E1000_MAX_PLL_TRIES; i++) { /* check current state directly from internal PHY */ igb_read_phy_reg_gs40g(hw, (E1000_PHY_PLL_FREQ_PAGE | E1000_PHY_PLL_FREQ_REG), &phy_word); if ((phy_word & E1000_PHY_PLL_UNCONF) != E1000_PHY_PLL_UNCONF) { ret_val = 0; break; } else { ret_val = -E1000_ERR_PHY; } /* directly reset the internal PHY */ ctrl = rd32(E1000_CTRL); wr32(E1000_CTRL, ctrl|E1000_CTRL_PHY_RST); ctrl_ext = rd32(E1000_CTRL_EXT); ctrl_ext |= (E1000_CTRL_EXT_PHYPDEN | E1000_CTRL_EXT_SDLPE); wr32(E1000_CTRL_EXT, ctrl_ext); wr32(E1000_WUC, 0); reg_val = (E1000_INVM_AUTOLOAD << 4) | (tmp_nvm << 16);<p>  wr32(E1000_EEARBC_I210, reg_val); igb_read_pci_cfg(hw, E1000_PCI_PMCSR, &pci_word); pci_word |= E1000_PCI_PMCSR_D3; igb_write_pci_cfg(hw, E1000_PCI_PMCSR, &pci_word); usleep_range(1000, 2000); pci_word &= ~E1000_PCI_PMCSR_D3; igb_write_pci_cfg(hw, E1000_PCI_PMCSR, &pci_word); reg_val = (E1000_INVM_AUTOLOAD << 4) | (nvm_word << 16);<p>  wr32(E1000_EEARBC_I210, reg_val); /* restore WUC register */ wr32(E1000_WUC, wuc); } /* restore MDICNFG setting */ wr32(E1000_MDICNFG, mdicnfg); return ret_val;}

[Adolfo_S_Intel]

Hello PVWB

What is the name of the .bin file that you are programming into the I210?

Is it possible for you to test if the system works on a Microsoft Windows distribution?

Can you test a different Linux distribution preferably with newer kernel and drivers?

Best Regards,

Adolfo

[PWilc1]

Dear Adolfo,

Thank you for your reply.

I'm using the Images/I210/SGMII/Dev_Start_I210_Sgmii_NOMNG_16Mb_A2_3.25_0.03.bin

file. The SGMII connections go to a Marvell 88E1512 on another board. We have

versions of this other board that 88E1111 parts on them, if that is a better match.

We should be able to test with a newer Linux distribution. I'm not sure that we

can run Windows on the machine under test. In order to keep BIOS costs down,

we left out any Windows specific features in the BIOS.

Thanks, Paul.

[PWilc1]

Dear Adolfo,

We have loaded the latest Linux driver and turned on some of the

debugging output. We now get a "no PHY attached" message.

I'll look at the 'scope to see if we are gettting any data from the PHY.

Also, this PHY doesn't have the MDIO interface connected, so this

might be part of the problem. Looking at the web, there seem to be

some claims that SGMII has in-band signalling of the data rate it

uses, but all the applications I see have the processor read the PHY

to determine the data rate and then set up the MAC part appropriately.

Do you know what the i210 uses in this respect?

Thanks ,Paul.

[Adolfo_S_Intel]

Hello PVWB

This is from the I210 datasheet, section 1.4.7 MDIO/I2C 2-Wire Interfaces

The I210 implements a management Interface to control an optional external PHY. The interface can be either a 2-wire Standard-mode I2C interface used to control an SFP module or an MII Management Interface (also known as the Management Data Input/Output or MDIO Interface) for control plane connection between the MAC and PHY devices (master side). This interface provides the MAC and software with the ability to monitor and control the state of the external PHY. The I210 supports the data formats defined in IEEE 802.3 clause 22.

According to some research I have done error 2 on igb can be caused by an unsupported PYH device, (it doesn't recognize the phy->id)

So my recomendation is:

1) First make sure that you are using the most recent driver: https://downloadcenter.intel.com/download/13663/Network-Adapter-Driver-for-82575-6-82580-I350-and-I210-211-Based-Gigabit-Network-Connections-for-Linux- Download Network Adapter Driver for 82575/6, 82580, I350, and I210/211-Based Gigabit Network Connections for Linux*

2) You might also test with the following patch: https://patchwork.ozlabs.org/patch/501290/ https://patchwork.ozlabs.org/patch/501290/ it seems to be fairly recent, so there is a possibility that the igb driver doesn't support the Marvell 88E1512 by default, it might be worth checking it.

Best Regards,

Adolfo.

[PWilc1]

Dear Adolo,

It looks as if our code already has the 88E1512 patch in it.

We have 5.3.3.2

I have turned on the debug messages, and looks as if the

inability to access the PHY by MDIO or I2c is what causes

the failure. So I will work on getting an MDIO connection

to the PHY and see how we do.

Thanks, for all the help

[PWilc1]

Dear Adolfo,

I have changed to using a part with the MDIO lines

wired to pull-ups and a PHY. However, I never seeany transitions on these lines.

I have enabled the Intel debugging, which prints out the routine

names as they are executed. I went and looked at the routinee1000_sgmii_uses_mdio_82575, which appeared relevant as itcan set a parameter called "ext_mdio". I added a debugline to print what was being read. This shows thatregister 0xE04 contained zero, which indicates externalMDIO is not in use. How does data get into this register?I chose the SGMII version of the Flash and the part identifiesas 8086:1538, which is the correct ID for SGMII operation,so I would expect the MDIO bit to be set. Even if the Flashselected I2C operation, I would expect to see clock transitionson the dual purpose MDIO/I2C lines.

Thanks, Paul.

In routine e1000_sgmii_uses_mdio_82575 in file e1000_82575.c

There is this code with my added printf:

case e1000_i210:

case e1000_i211: reg = E1000_READ_REG(hw, E1000_MDICNFG); ext_mdio = !!(reg & E1000_MDICNFG_EXT_MDIO); DEBUGFUNC("Read reg 0x%0X, got 0x%0X", E1000_MDICNFG, reg); break;

The debug output shows that register 0xE04 contains zero.

[PWilc1]

Dear Adolfo,

I think I have discovered why the MDIO interface is

not working and why the MDICNFG bit isn't set. On page 196 on the i210 hardwaremanual, the format for Initialization Control 3 (Word 0x24)is shown. I would expect bit 2 to be set, indicating useof MDIO. If I look at the Dev_Start_I210_Sgmii_NOMNG_8Mb_A2_3.25_0.03.bin file,word 24 (address 48) is 0x4220, which doesn't have the"External MDIO" bit set. Can I change just this 16-bit word with EEUPDATE using WW and not mess up the "signing"of the binary? Would the value of 0x0824 be correct formy application?

Thanks, Paul.

[Adolfo_S_Intel]

Hello PVWB

I find it strange that the SGMII images come with the MDIO disabled, perhaps it assumes that customer is using I2C as the default interface, but I'm not sure about this point. I will ask our next support level about it.

Here are a few things that you could check before performing changes to the default image:

1) Study this reference schematic: https://www-ssl.intel.com/content/www/us/en/embedded/products/networking/i210-is-reference-design-schematic.html I210-AS/IS Reference Design: Schematic and check if you omitted any important connection

2) Also there is this checklist that could be useful for you:https://www-ssl.intel.com/content/www/us/en/secure/intelligent-systems/privileged/gbe-i210-is-layout-review-checklist.html Intel® Ethernet Controller I210-IS: Layout Review Checklist (it requires privileged account to access it)

3) Have you tried using the 88E1111 from Marvell? If yes, what were the results?

Regarding your questions about the I210 signature, please refer to section 3.3.2.1 Protected Areas and Words, of the I210's datasheet for more information. The only areas that are secured by the Signature are there, also Table 1-6 list all the configuration registers, just RO registers can't be altered.

I hope this information is useful for you.

Best Regards,

Adolfo

[PWilc1]

Dear Adolfo,

I changed word 0x24 in the flash from 0x4220 to 0x4824.

I now get different output from the driver. Notethat I now get "MDI Error"; before, I was also gettingcalls to i2ccmd routines (spelling of the latter routinemay be wrong - I'm going from memory)

However, I'm still having the problem that I am not

seeing any transitions on either the clock or data lines.

There is one other oddity. Page four of the schematics state

that the I2C lines have internal pull-ups. The I2C pins arethe same pins used for the MDIO interface. When I startedchecking the MDIO interface, these signals were at a low level.So I added a 4k pull-up for each line to 3.3V. The oddthing is that the lines only go up to about 1.6 Volts, soI guess there is a clamp inside the i210 part somewhere.

I have compared our schematics with the reference schematics

in your earlier message. The only significant difference I see,

apart from the MDIO/I2C difference, is that their design uses

the RX_LOS signal from the SFP. I wouldn't expect this to

affect PHY access, as this is needed at all times. I will look

into control bits for this in Flash area that I might require later

Thanks, Paul.

Driver output follows:

[ 385.531704] Intel(R) Gigabit Ethernet Network Driver - version 5.3.2

[ 385.531707] Copyright (c) 2007-2015 Intel Corporation.[ 385.531975] e1000_set_mac_type[ 385.531977] e1000_init_mac_ops_generic[ 385.531978] e1000_init_phy_ops_generic[ 385.531978] e1000_init_nvm_ops_generic[ 385.531979] e1000_init_function_pointers_82575[ 385.531980] e1000_init_mac_params_82575[ 385.531983] e1000_sgmii_uses_mdio_82575[ 385.531989] e1000_init_nvm_params_i210[ 385.531992] e1000_init_nvm_params_82575[ 385.531993] e1000_get_flash_presence_i210[ 385.531996] e1000_init_phy_params_82575[ 385.531998] e1000_reset_mdicnfg_82580[ 385.531999] e1000_sgmii_uses_mdio_82575[ 385.532001] e1000_get_phy_id_82575[ 385.532002] e1000_sgmii_uses_mdio_82575[ 385.532007] e1000_get_phy_id[ 385.532007] e1000_read_phy_reg_gs40g[ 385.532008] e1000_acquire_phy_82575[ 385.532009] e1000_acquire_swfw_sync_i210[ 385.532009] e1000_get_hw_semaphore_i210[ 385.532018] e1000_put_hw_semaphore_generic[ 385.532021] e1000_write_phy_reg_mdic[ 385.532074] e1000_read_phy_reg_mdic[ 385.532127] e1000_release_phy_82575[ 385.532127] e1000_release_swfw_sync_i210[ 385.532128] e1000_get_hw_semaphore_i210[ 385.532137] e1000_put_hw_semaphore_generic[ 385.532160] e1000_read_phy_reg_gs40g[ 385.532160] e1000_acquire_phy_82575[ 385.532161] e1000_acquire_swfw_sync_i210[ 385.532162] e1000_get_hw_semaphore_i210[ 385.532171] e1000_put_hw_semaphore_generic[ 385.532174] e1000_write_phy_reg_mdic[ 385.532226] e1000_read_phy_reg_mdic[ 385.532279] MDI Error[ 385.532280] e1000_release_phy_82575[ 385.532280] e1000_release_swfw_sync_i210[ 385.532281] e1000_get_hw_semaphore_i210[ 385.532290] e1000_put_hw_semaphore_generic[ 385.532293] PHY Initialization Error[ 385.532295] igb 0000:09:00.0: Hardware Initialization Failure[ 385.532343] igb: probe of 0000:09:00.0 failed with error -5

[PWilc1]

Dear Adolfo,

I am still not getting anywhere with the MDIO accesses on

the i210. I don't get any transitions on the MDIO clock orMDIO data pins. I also do not see any activity on the SGMIIoutput pins. The MDIO clock and data pins appear to be clamped at1.5V with the Marvell PHYS connected or disconnected. The MDIOclock and MDIO data lines have 4.0k pull-up resistors to 3.3V.There are no other components connected to these signals.

I changed word 0x24 of the Flash from the original 0x4220 to

0x4824. This should enable MDIO mode, instead of the previousI2C protocol. However, I didn't see any transitions on theclock or data pins before doing this change.

Word 0x20 is 0xA20C (as delivered in the SGMII binary) This

has I2C_ON_SDP-EN off, as it should be for this application.If I set this bit and the MDIO enable bit, should I be able toget MDIO operation on SDP lines 0 and 2?

I am using the official Intel supplied Linux 5.3.2 source for

the driver. I have enabled debug messages and added a few ofmy own. This shows that the MDI read and write routines arebeing called and show an error in the read case.

Would it be useful to send our schematics of the i210 circuit?

If so, can you give me an e-mail address to send them to orsuggest another method?

Here is part of the debug output. If you need more, I can do

that easily.

[ 8297.847572] e1000_write_phy_reg_mdic

[ 8297.847625] e1000_read_reg read 0x14160000 from 0x15480020[ 8297.847626] e1000_read_phy_reg_mdic[ 8297.847679] e1000_read_reg read 0x5803FFFF from 0x15480020[ 8297.847680] MDI Error[ 8297.847681] e1000_release_phy_82575[ 8297.847681] e1000_release_swfw_sync_i210[ 8297.847682] e1000_get_hw_semaphore_i210[ 8297.847685] e1000_read_reg read 0x0 from 0x15485B50[ 8297.847688] e1000_read_reg read 0x1 from 0x15485B50[ 8297.847691] e1000_read_reg read 0x3 from 0x15485B50[ 8297.847694] e1000_read_reg read 0x2 from 0x15485B5C[ 8297.847695] e1000_put_hw_semaphore_generic[ 8297.847697] e1000_read_reg read 0x3 from 0x15485B50[ 8297.847698] e1000_get_phy_id - phy->ops.read_reg returned 0xFFFFFFFE[ 8297.847699] PHY Initialization Error[ 8297.847702] igb 0000:09:00.0: Hardware Initialization Failure[ 8297.847758] igb: probe of 0000:09:00.0 failed with error -5

Thanks, Paul.

[PWilc1]

O.K. I think I have finally discovered what the problem is.

Although you would never guess this from the i210 manual,

There are actually two DIFFERENT i210 parts for copper and

SGMII operation. This explains the 1.5V clamp on the supposed

MDIO lines. Only the checklist mentions that there are two

different parts for the two modes of operation.

Thanks, Paul

[Adolfo_S_Intel]

Hello

Yes indeed there are two different parts

The I210-IT/AT contains the MAC and PHY on the same package while the I210-IS/AS contains MAC on the chip and uses an external PHY layer.

This is also mentioned on thehttp://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 .

I'm glad that your issue was solved.

Best Regards,

Adolfo.

[PWilc1]

Dear Adolfo,

I have discussed the i210 part with you in the

past.

I have finally got a working board with the right

type of I210 part installed. Our board has aMarvell 88E1512 PHY on a daughter card attached tothe I210.

I guess a good starting question is has the I210 and

the 88E1512 PHY been tested with this driver? It must

be a rather unusual combination.

I have got the latest 5.3.3.5 drivers installed.

A lot more seems to be working now.

ifconfig -a shows an enp8s0

I get what look like SGMII transitions on the I210

inputs and outputs. When I plug an Ethernet cableinto the RJ45 side of the PHY, I do not get linkup. The daughter card has been tested working witha different processor card.

I can't tell if the SGMII connection between the

parts is working correctly.

I turned on the DEBUGFUNC and DEBUGOUT defines in

e1000_osdep.h. This produces about 6000 linesof output, so I am only going to include the relevantparts. The output implies that the Marvell PHY was found.We got:

[Fri Feb 12 16:43:06 2016] e1000_initialize_M88E1512_phy

Then around line 6024 I get

[Fri Feb 12 16:55:21 2016] e1000_put_hw_semaphore_generic

[Fri Feb 12 16:55:21 2016] Phy info is only valid if link is up[Fri Feb 12 16:55:21 2016] igb 0000:08:00.0: added PHC on eth0[Fri Feb 12 16:55:21 2016] igb 0000:08:00.0: Intel(R) Gigabit Ethernet Network Connection[Fri Feb 12 16:55:21 2016] igb 0000:08:00.0: eth0: (PCIe:2.5GT/s:Width x1)[Fri Feb 12 16:55:21 2016] igb 0000:08:00.0 eth0: MAC: 00:a0:c9:00:00:00[Fri Feb 12 16:55:21 2016] e1000_read_pba_string_generic

Later on I see several

[Fri Feb 12 16:55:21 2016] e1000_host_interface_command[Fri Feb 12 16:55:21 2016] Hardware doesn't support host interface command.[Fri Feb 12 16:55:21 2016] e1000_calculate_checksum

Followed by the last three lines of output:

[Fri Feb 12 16:55:21 2016] e1000_put_hw_semaphore_generic

[Fri Feb 12 16:55:21 2016] igb 0000:08:00.0: LRO is disabled[Fri Feb 12 16:55:21 2016] igb 0000:08:00.0: Using MSI-X interrupts. 1 rx queue(s), 1 tx queue(s)

Are any of these likely to be causing the part not to work or the

"eth0" device not to be created. I tried this driver on a motherboardwith the RJ45 copper version of the I210. It works. It createsa device of enp5s0, although the debug output still refers to"eth0". I did see some of the same "Hardware doesn't supporthost interface command." lines, so I guess these aren't necessarilybad!

If you have any ideas about what might be wrong, I would be very

interested.

Thanks, Paul.

[CarlosAM_INTEL]

Hello paulwilcox-baker,

Thank you for contacting the Intel Embedded Community.

We suggest you to follow the suggestions provided to you in the Forum /message/17892# 17892 I210 DC Specification # 2.

Best Regards,

Carlos_A.