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

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

PWilc1
New Contributor I
7,295 Views

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 load

 

the 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 Write

 

Protect 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.03

 

Copyright (C) 1995 - 2015 Intel Corporation

 

Intel (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.03

 

Copyright (C) 1995 - 2015 Intel Corporation

 

Intel (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.03

 

Copyright (C) 1995 - 2015 Intel Corporation

 

Intel (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.03

 

Copyright (C) 1995 - 2015 Intel Corporation

 

Intel (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.03

 

Copyright (C) 1995 - 2015 Intel Corporation

 

Intel (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.03

 

Copyright (C) 1995 - 2015 Intel Corporation

 

Intel (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>

0 Kudos
1 Solution
PWilc1
New Contributor I
2,190 Views

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

View solution in original post

19 Replies
Gabriel_T_Intel
Employee
2,190 Views

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.

0 Kudos
Adolfo_S_Intel
Moderator
2,190 Views

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

0 Kudos
CarlosAM_INTEL
Moderator
2,190 Views

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.

0 Kudos
PWilc1
New Contributor I
2,191 Views

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
New Contributor I
2,190 Views

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. The

 

driver is the igb driver that comes as part of

 

SuSE linux 13.2. This driver works with the i210 in

 

RJ45 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 of

 

the 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;

 

}
0 Kudos
Adolfo_S_Intel
Moderator
2,190 Views

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

0 Kudos
PWilc1
New Contributor I
2,190 Views

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.

0 Kudos
PWilc1
New Contributor I
2,190 Views

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.

0 Kudos
Adolfo_S_Intel
Moderator
2,190 Views

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.

0 Kudos
PWilc1
New Contributor I
2,190 Views

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

0 Kudos
PWilc1
New Contributor I
2,190 Views

Dear Adolfo,

I have changed to using a part with the MDIO lines

 

wired to pull-ups and a PHY. However, I never see

 

any 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 routine

 

e1000_sgmii_uses_mdio_82575, which appeared relevant as it

 

can set a parameter called "ext_mdio". I added a debug

 

line to print what was being read. This shows that

 

register 0xE04 contained zero, which indicates external

 

MDIO is not in use. How does data get into this register?

 

I chose the SGMII version of the Flash and the part identifies

 

as 8086:1538, which is the correct ID for SGMII operation,

 

so I would expect the MDIO bit to be set. Even if the Flash

 

selected I2C operation, I would expect to see clock transitions

 

on 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.

0 Kudos
PWilc1
New Contributor I
2,190 Views

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 hardware

 

manual, the format for Initialization Control 3 (Word 0x24)

 

is shown. I would expect bit 2 to be set, indicating use

 

of 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 for

 

my application?

Thanks, Paul.

0 Kudos
Adolfo_S_Intel
Moderator
2,190 Views

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

0 Kudos
PWilc1
New Contributor I
2,190 Views

Dear Adolfo,

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

 

I now get different output from the driver. Note

 

that I now get "MDI Error"; before, I was also getting

 

calls to i2ccmd routines (spelling of the latter routine

 

may 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 are

 

the same pins used for the MDIO interface. When I started

 

checking the MDIO interface, these signals were at a low level.

 

So I added a 4k pull-up for each line to 3.3V. The odd

 

thing is that the lines only go up to about 1.6 Volts, so

 

I 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
0 Kudos
PWilc1
New Contributor I
2,190 Views

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 or

 

MDIO data pins. I also do not see any activity on the SGMII

 

output pins. The MDIO clock and data pins appear to be clamped at

 

1.5V with the Marvell PHYS connected or disconnected. The MDIO

 

clock 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 previous

 

I2C protocol. However, I didn't see any transitions on the

 

clock 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 to

 

get 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 of

 

my own. This shows that the MDI read and write routines are

 

being 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 or

 

suggest 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.

0 Kudos
PWilc1
New Contributor I
2,190 Views

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
Moderator
2,190 Views

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.

0 Kudos
PWilc1
New Contributor I
2,190 Views

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 a

 

Marvell 88E1512 PHY on a daughter card attached to

 

the 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 cable

 

into the RJ45 side of the PHY, I do not get link

 

up. The daughter card has been tested working with

 

a 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 lines

 

of output, so I am only going to include the relevant

 

parts. 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 motherboard

 

with the RJ45 copper version of the I210. It works. It creates

 

a device of enp5s0, although the debug output still refers to

 

"eth0". I did see some of the same "Hardware doesn't support

 

host interface command." lines, so I guess these aren't necessarily

 

bad!

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

 

interested.

Thanks, Paul.

0 Kudos
CarlosAM_INTEL
Moderator
2,190 Views

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.

0 Kudos
Reply