Hi Adolfo,
I'm look for the same tool (eepromARMtool) i need to program my new hardware with i210 into SerDes Mode could you email the tool also.
Thanks,
Pawel
链接已复制
Hello pattiwack
I sent you the eepromARMTool to your e-mail.
You might want to check the following resources:
https://www-ssl.intel.com/content/www/us/en/embedded/products/networking/i210-ethernet-controller-datasheet.html I210 Datasheet
/message/10363 I210 detection issues under embedded linux -- (i211)
Hope this is useful to you.
Best regards,
Adolfo
Thanks Adolfo,
We tried compiling and running the program but its failing with a bus error. See below:
[root@alarm eepromARMTool_0.6.7]# ./eepromARMtool
Intel(R) Eeprom ARM Tool ARM OTP Programming Tool
Provided under Unhandled fault: external abort on non-linefetch (0x1018) at 0x36e5f010
Slave unsupported request
the terms of a CNDA. Do Not Distribute.
Copyright(C) 2013 by Intel(R) Corporation
NIC BUS DEV FUN Silicon Memory Type Present
=== === === === ===== ======================
Bus error (core dumped)
[root@alarm eepromARMTool_0.6.7]#
Here's the lspci display of the i210's along with the PCIe switch they are attached to and the root complex (Xilinx Zynq SoC).
[root@alarm eepromARMTool_0.6.7]# lspci
00:00.0 PCI bridge: Xilinx Corporation Device 7012
01:00.0 PCI bridge: PLX Technology, Inc. PEX 8605 PCI Express 4-port Gen2 Switch (rev ab)
02:02.0 PCI bridge: PLX Technology, Inc. PEX 8605 PCI Express 4-port Gen2 Switch (rev ab)
02:03.0 PCI bridge: PLX Technology, Inc. PEX 8605 PCI Express 4-port Gen2 Switch (rev ab)
03:00.0 Ethernet controller: Intel Corporation Device 1531 (rev 03)
04:00.0 Ethernet controller: Intel Corporation Device 1531 (rev 03)
[root@alarm eepromARMTool_0.6.7]#
Any ideas why the ARMtool is failing in this way?
-Matt
Hello pattiwack
Sorry for the delay
Our Intel engineers suggest two possibilities:
1) A conflict because mixing endians, as suggested in the user's guide from the eepromARMtool:
Another thing to consider is that ARM systems can be Bi-Endian. Therefore, you should verify the Endianness being used, especially when programming values at the bit level.This document does not cover verifying Endianness. However, you should be aware that eepromARMtool reflects a Little Endian implementation to match the hardware datasheets.
2) There is a possibility that for certain hardware the Operating System locks the page after it was allocated.
Check the following thread that could be useful to you:/message/10363 I210 detection issues under embedded linux -- (i211)
Best Regards,
Adolfo
So we preprogrammed one of the flash parts and then put it back on our board and then eepromARMtool would work. Shouldn't the tool be able to identify and program a blank flash attached to a i210?
Regardless, we still can't bring up the ethernet interface. We see the following error when we do:
[root@alarm ~]# ifconfig enp3s0 up
igb 0000:03:00.0: Error -22 getting interrupt
SIOCSIFFLAGS: Invalid argument
When we look at dmesg when linux is booting and loading the ethernet driver we see the following:
[ 0.842985] e1000e: Intel(R) PRO/1000 Network Driver - 2.3.2-k
[ 0.847423] e1000e: Copyright(c) 1999 - 2014 Intel Corporation.
[ 0.852178] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.2.13-k
[ 0.857830] igb: Copyright (c) 2007-2014 Intel Corporation.
[ 0.862168] igb 0000:03:00.0: enabling device (0140 -> 0142)
[ 0.866457] igb 0000:03:00.0: enabling bus mastering
[ 0.899828] igb 0000:03:00.0: added PHC on eth0
[ 0.902993] igb 0000:03:00.0: Intel(R) Gigabit Ethernet Network Connection
[ 0.908527] igb 0000:03:00.0: eth0: (PCIe:unknown:unknown) 00:a0:c9:00:00:00
[ 0.914356] igb 0000:03:00.0: eth0: PBA No: 000300-000
[ 0.918110] igb 0000:03:00.0: Using legacy interrupts. 1 rx queue(s), 1 tx queue(s)
[ 0.924519] igb 0000:04:00.0: enabling device (0140 -> 0142)
[ 0.928804] igb 0000:04:00.0: enabling bus mastering
[ 0.961952] igb 0000:04:00.0: added PHC on eth1
[ 0.965143] igb 0000:04:00.0: Intel(R) Gigabit Ethernet Network Connection
[ 0.970711] igb 0000:04:00.0: eth1: (PCIe:unknown:unknown) 00:a0:c9:00:aa:aa
[ 0.976460] igb 0000:04:00.0: eth1: PBA No: 000300-000
[ 0.980225] igb 0000:04:00.0: Using legacy interrupts. 1 rx queue(s), 1 tx queue(s)
.............
[ 301.965208] igb 0000:03:00.0: Error -22 getting interrupt
[ 309.444858] igb 0000:04:00.0: Error -22 getting interrupt
[ 327.846029] igb 0000:04:00.0: Error -22 getting interrupt
[ 328.093721] igb 0000:04:00.0: Error -22 getting interrupt
Any idea what might cause the driver to complain with the interrupt error message?
-Matt
So when the flash parts were blank we could see the parts via lspci but their device id was 1531 (which I believe is correct for an unprogrammed i210). However the eepromARMtool would not run. We took the flash parts off the board and programmed them with a 3rd party programmed using one of intel's example binary images and then we saw the device id change to an i210 and the eepromARMtool then would work. We would prefer to use the eepromARMtool to program blank parts so we wouldn't have to remove them (or preprogram them).
Regardless of this, with the flash parts now programmed we can not bring up the ethernet interface. The driver complains with "Error -22 getting interrupt". As result we are currently blocked with getting this working. Any ideas with might be causing this or how to further debug this problem?
Regards,
Matt
Adolfo,
Here is some more info on our problem.
Once the EEPROM is programmed and re-soldered to the board the igb driver loads and we are able to read and write to the EEPROM with eepromARMtool tool. But the driver doesn't configure correctly. The PCIe root complex supports MSI interrupts (not MSI-X), but the driver loaded using legacy interrupts:
[ 1.159680] pci 0000:00:00.0: enabling device (0144 -> 0147)
[ 1.164007] pci 0000:01:00.0: enabling device (0140 -> 0143)
[ 1.168325] pci 0000:02:02.0: enabling device (0140 -> 0143)
[ 1.172663] igb 0000:03:00.0: enabling device (0140 -> 0142)
[ 1.210435] igb 0000:03:00.0: added PHC on eth0
[ 1.213606] igb 0000:03:00.0: Intel(R) Gigabit Ethernet Network Connection
[ 1.219137] igb 0000:03:00.0: eth0: (PCIe:unknown:unknown) 00:a0:c9:00:00:00
[ 1.224967] igb 0000:03:00.0: eth0: PBA No: 000300-000
[ 1.228719] igb 0000:03:00.0: Using legacy interrupts. 1 rx queue(s), 1 tx queue(s)
[ 1.235130] pci 0000:02:03.0: enabling device (0140 -> 0143)
[ 1.239423] igb 0000:04:00.0: enabling device (0140 -> 0142)
[ 1.277118] igb 0000:04:00.0: added PHC on eth1
[ 1.280260] igb 0000:04:00.0: Intel(R) Gigabit Ethernet Network Connection
[ 1.285838] igb 0000:04:00.0: eth1: (PCIe:unknown:unknown) 00:a0:c9:00:aa:aa
[ 1.291626] igb 0000:04:00.0: eth1: PBA No: 000300-000
[ 1.295394] igb 0000:04:00.0: Using legacy interrupts. 1 rx queue(s), 1 tx queue(s)
Then when we try to connect the Ethernet port we get an error 22:
[root@alarm ~]# ifconfig enp4s0 up
igb 0000:04:00.0: Error -22 getting interrupt
SIOCSIFFLAGS: Invalid argument
Using modprobe with MSI option
[root@alarm ~]# modprobe igb IntMode=1
igb: unknown parameter 'IntMode' ignored
igb: Intel(R) Gigabit Ethernet Network Driver - version 5.2.13-k
igb: Copyright (c) 2007-2014 Intel Corporation.
igb 0000:03:00.0: added PHC on eth3
<span style="font-size: ...
Here's the latest from the engineer working on debugging the driver...
"I'm can build the IGB driver locally on the picoZed now (Linux alarm 3.17.0-xilinx # 1 SMP PREEMPT Mon Feb 16 20:34:22 PST 2015 armv7l GNU/Linux). Below is the driver and loading information from several visions. All are showing the same error -22 when connecting the network interface. With debug level set to 16, both the 5.2.9.4 and 5.2.15 drivers are showing: Failed to initialize MSI interrupts. Falling back to legacy interrupts.
Please pass along to intel
Van"
Printout from the 5.2.9.4 driver:
[root@alarm src]# modinfo igb
filename: /lib/modules/3.17.0-xilinx/kernel/drivers/net/igb/igb.ko
version: 5.2.9.4
license: GPL
description: Intel(R) Gigabit Ethernet Network Driver
author: Intel Corporation, <<a href="mailto:e1000-devel@lists.sourceforge.net" target="_blank">e1000-devel@lists.sourceforge.net>
srcversion: E377200391EBF74638FEDA2
alias: pci:v00008086d000010D6sv*sd*bc*sc*i*
alias: pci:v00008086d000010A9sv*sd*bc*sc*i*
alias: pci:v00008086d000010A7sv*sd*bc*sc*i*
alias: pci:v00008086d000010E8sv*sd*bc*sc*i*
alias: pci:v00008086d00001526sv*sd*bc*sc*i*
alias: pci:v00008086d0000150Dsv*sd*bc*sc*i*
alias: pci:v00008086d000010E7sv*sd*bc*sc*i*
alias: pci:v00008086d000010E6sv*sd*bc*sc*i*
alias: pci:v00008086d00001518sv*sd*bc*sc*i*
alias: pci:v00008086d0000150Asv*sd*bc*sc*i*
alias: pci:v00008086d000010C9sv*sd*bc*sc*i*
alias: pci:v00008086d00000440sv*sd*bc*sc*i*
alias: pci:v00008086d0000043Csv*sd*bc*sc*i*
alias: pci:v00008086d0000043Asv*sd*bc*sc*i*
alias: pci:v00008086d00000438sv*sd*bc*sc*i*
alias: pci:v00008086d00001516sv*sd*bc*sc*i*
alias: pci:v00008086d00001511sv*sd*bc*sc*i*
alias: pci:v00008086d00001510sv*sd*bc*sc*i*
alias: pci:v00008086d00001527sv*sd*bc*sc*i*
alias: pci:v00008086d0000150Fsv*sd*bc*sc*i*
alias: pci:v00008086d0000150Esv*sd*bc*sc*i*
alias: pci:v00008086d00001524sv*sd*bc*sc*i*
alias: pci:v00008086d00001523sv*sd*bc*sc*i*
alias: pci:v00008086d00001522sv*sd*bc*sc*i*
alias: pci:v00008086d00001521sv*sd*bc*sc*i*
alias: pci:v00008086d00001539sv*sd*bc*sc*i*
alias: pci:v00008086d0000157Csv*sd*bc*sc*i*
alias: pci:v00008086d0000157Bsv*sd*bc*sc*i*
alias: pci:v00008086d00001538sv*sd*bc*sc*i*
alias: pci:v00008086d00001537sv*sd*bc*sc*i*
alias: pci:v00008086d00001536sv*sd*bc*sc*i*
alias: pci:v00008086d00001533sv*sd*bc*sc*i*
alias: pci:v00008086d00001F45sv*sd*bc*sc*i*
<p...Hello pattiwack
We are still working on your issue, we need the following information:
- A schematic and a block diagram of your design.
- The dmesg when the I210 fails with a Blank NVM.
- The core dump of when the eepromARMtool gives you the Bus Error with a Blank NVM.
Best Regards,
Adolfo Sanchez.
