- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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>
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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;
}
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page