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

Problems with eeprom access tool on a raspberry pi cm4 and i210

ep1dmn
Beginner
3,726 Views

Hello,

we have our own board based on an ARM raspberry pi 4 and an I210.

We have a programmed i210 and an unprogrammed i210.

The programmed i210 was programmed on an x86 and works fine.

The unprogrammed i210 needs to be programmed with "eeprom access tool".

But this does not work.

EAT detects i210 correctly

# ./EepromAccessTool             

Intel(R) EEPROM Access Tool NVM/OTP Programming Example Tool   Version 0.8.0
Provided under the terms of a CNDA.  Do Not Distribute.
Copyright(C) 2017-2020 by Intel(R) Corporation 
NIC	BUS	DEV	FUN	Silicon	Memory Type Present
===	===	===	===	=====	======================
 1	1	 0	 0	I210	     INVM

 

Dumping iNVM seems working, but file seems strange:

# ./EepromAccessTool -nic=1 -dump

Intel(R) EEPROM Access Tool NVM/OTP Programming Example Tool   Version 0.8.0
Provided under the terms of a CNDA.  Do Not Distribute.
Copyright(C) 2017-2020 by Intel(R) Corporation 
Using FW mode
# cat I210NIC1.otp 
6162696C 696D6F74 6F732E63 0000312E 00001904 070C0014 6162696C 2E727474
312E6F73 00001907 01180020 6162696C 69686176 6D6F632D 2E6E6F6D 332E6F73
342E352E 00001908 07120064 6162696C 69686176 726F632D 6F732E65 0000372E
00001909 01160020 6162696C 69686176 726F632D 6F732E65 312E372E 0000302E
0000190D 011F0028 6262696C 6C656261 63617274 74632D65 65742D66 732E7478
2E312E6F 00302E30 00001918 07130068 6262696C 6C656261 63617274 732E3265
00302E6F 00001922 070B004C 6262696C 732E327A 00312E6F 0000192D 01150020
6362696C 6E2D6674 6466626F 2E6F732E 2E302E30 00000030 0000192F 010F0018

 

After every reboot the "dump" command gives me another output.

Seems that EAT can not read iNVM correctly.

 

Sometimes the command says that iNVM is blank.

So I try to write a .bin file to it and EAT says writing was successful.

But after a reboot there is no programmed i210 and dumping iNVM gives values which makes no sense.

 

We exclude a hardware issue because we have same electric components on a x86 architecture and there it works.

 

I changed "dev->FlashSize = 0x200000;"  because we have a 32Mbit SPI Flash.

BIN file I want to program is same as on x86 architecture.

 

Any help would be appreciated

Kind regards

0 Kudos
17 Replies
CarlosAM_INTEL
Moderator
3,713 Views

Hello, @ep1dmn:

Thank you for contacting Intel Embedded Community.

We sent an email to the address associated with this account with information that may help you.

Best regards,

@CarlosAM_INTEL.

0 Kudos
ep1dmn
Beginner
3,701 Views

Dear @CarlosAM_INTEL ,

thanks for your reply. I repeated the steps you suggested with no success.

It's strange that after a shutdown the iNVM is not programmed anymore.

$ sudo lspci 
00:00.0 PCI bridge: Broadcom Limited Device 2711 (rev 20)
01:00.0 Ethernet controller: Intel Corporation I210 Gigabit Unprogrammed (rev 03)
$ sudo setpci -s 01:00.0 COMMAND=0007
$ sudo ./EepromAccessTool 

Intel(R) EEPROM Access Tool NVM/OTP Programming Example Tool   Version 0.8.0
Provided under the terms of a CNDA.  Do Not Distribute.
Copyright(C) 2017-2020 by Intel(R) Corporation 
NIC	BUS	DEV	FUN	Silicon	Memory Type Present
===	===	===	===	=====	======================
 1	1	 0	 0	I210	     INVM

$ sudo ./EepromAccessTool -nic=1 -dump

Intel(R) EEPROM Access Tool NVM/OTP Programming Example Tool   Version 0.8.0
Provided under the terms of a CNDA.  Do Not Distribute.
Copyright(C) 2017-2020 by Intel(R) Corporation 
Using no FW mode
Device is BLANK!

$ sudo ./EepromAccessTool -nic=1 -f=hex_files/I210_Invm_Copper_NoAPM_v0.6.HEX -mac=00e071340003

Intel(R) EEPROM Access Tool NVM/OTP Programming Example Tool   Version 0.8.0
Provided under the terms of a CNDA.  Do Not Distribute.
Copyright(C) 2017-2020 by Intel(R) Corporation 
Using no FW mode
Programming successful!
$ sudo ./EepromAccessTool -nic=1 -dump
[...]
$ cat I210NIC1.otp
16E80002 00001541 038D0002 0B403C21 402F1411 34003611 1C605011 157B1A11
05844211 02804811 73431E19 0000001A 08100241 16D10002 00FF00A8 16D00002
5E000090 E0000019 34710219 03000419 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
$ sudo shutdown now
$ sudo ./EepromAccessTool -nic=1 -dump

Intel(R) EEPROM Access Tool NVM/OTP Programming Example Tool   Version 0.8.0
Provided under the terms of a CNDA.  Do Not Distribute.
Copyright(C) 2017-2020 by Intel(R) Corporation 
Updating command word..... Done!
Using no FW mode
Device is BLANK!
$ cat I210NIC1.otp
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
OTP is BLANK!

After writing hex file to iNVM it looks very good. I can see hex file and MAC address I wanted to program.
But after a shutdown it says BLANK!

I do not want to lock iNVM as described in user guide except this is the solution. But I do not think that.

Any other solution?

 

Kind regards,

dmn

0 Kudos
CarlosAM_INTEL
Moderator
3,688 Views

Hello, @ep1dmn:

Thanks for your update.

We sent another email with information that may help you.

Best regards,

@CarlosAM_INTEL.

0 Kudos
paul04
Beginner
2,512 Views

Hello @CarlosAM_INTEL could you please send me the information you sent to @ep1dmn . We are having the exact problem and it seems the information you send, which is unfortunately not available for us, seems to to work.

By the way, we have all the tools in their newest versions.

 

Thanks in advance

0 Kudos
Diego_INTEL
Moderator
2,499 Views

Hello @paul04,

 

Thank you for contacting Intel Embedded Community.

 

Yes, it can be a bug with the version files that you are using.

You can check this FAQ: https://www.intel.com/content/www/us/en/content-details/334026/

 

And the following documentation in RDC:

#634290 - EEPROM Access Tool User’s Guide

#513655 - Intel® Ethernet Controller I210 and I211- AT Production NVM Images

#348742 - Intel® Network Connections Tools 28.2 PV LAN Software Tools

 

In order to get access to the documentation, you will require a Premier account or you may ask to any Intel Sales Representative near your zone to get help.

 

Best regards,

 

@Diego_INTEL 

0 Kudos
paul04
Beginner
2,490 Views

Hello @Diego_INTEL ,

 

We already have access to the documentation you mentioned but we still have the same problem. This is what we get after a reboot everytime we try to programm the iNVM of the i210:

CmdLine_Output_i210.png

 

We have followed everything described in the documentation and faqs for programming the i210 and nothing works for us. Is there a possibility that programming the iNVM is not possible when the i210 sits behind a PCIe switch (Raspberry Pie -> PCIe Switch -> i210), or are there some special considerations?

Thanks in advance

0 Kudos
Diego_INTEL
Moderator
2,466 Views

Hello @paul04,

 

Thank you very much for the details, you have a blank device or it has been programmed beforehand and it appears as blank?

 

May be the case that you are saying, because the error in putty about the "No Memeory (Memory) BAR resources" message. Can you try with another system?

 

I will ask if there is a known solution for this.

 

Best regards,

 

@Diego_INTEL 

0 Kudos
paul04
Beginner
2,417 Views

Hello @Diego_INTEL ,

 

we have a blank device, which had never been programmed before.

Concerning the Memory Bar issue, it was an adjustment we did on our kernel because of some notifications we got while booting. Checking with the original kernel looks as follows:

paul04_0-1692624271573.jpeg

 

And here some messages we see while booting up the system:

...
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.757711] brcm-pcie fd500000.pcie: host bridge /scb/pcie@7d500000 ranges:
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.757724] brcm-pcie fd500000.pcie:   No bus range found for /scb/pcie@7d500000, using [bus 00-ff]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.757761] brcm-pcie fd500000.pcie:      MEM 0x0600000000..0x063fffffff -> 0x00c0000000
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.757796] brcm-pcie fd500000.pcie:   IB MEM 0x0000000000..0x007fffffff -> 0x0400000000
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.787570] brcm-pcie fd500000.pcie: link up, 5.0 GT/s PCIe x1 (SSC)
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.787962] brcm-pcie fd500000.pcie: PCI host bridge to bus 0000:00
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.787969] pci_bus 0000:00: root bus resource [bus 00-ff]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.787975] pci_bus 0000:00: root bus resource [mem 0x600000000-0x63fffffff] (bus address [0xc0000000-0xffffffff])
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.788011] pci 0000:00:00.0: [14e4:2711] type 01 class 0x060400
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.788126] pci 0000:00:00.0: PME# supported from D0 D3hot
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.790004] PCI: bus0: Fast back to back transfers disabled
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.790011] pci 0000:00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.790233] pci 0000:01:00.0: [1b21:1184] type 01 class 0x060400
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.790314] pci 0000:01:00.0: enabling Extended Tags
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.790429] pci 0000:01:00.0: PME# supported from D0 D3hot D3cold
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.816973] PCI: bus1: Fast back to back transfers disabled
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.816980] pci 0000:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.817258] pci 0000:02:01.0: [1b21:1184] type 01 class 0x060400
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.817342] pci 0000:02:01.0: enabling Extended Tags
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.817450] pci 0000:02:01.0: PME# supported from D0 D3hot D3cold
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.817923] pci 0000:02:03.0: [1b21:1184] type 01 class 0x060400
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.818007] pci 0000:02:03.0: enabling Extended Tags
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.818120] pci 0000:02:03.0: PME# supported from D0 D3hot D3cold
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.818579] pci 0000:02:05.0: [1b21:1184] type 01 class 0x060400
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.818663] pci 0000:02:05.0: enabling Extended Tags
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.818769] pci 0000:02:05.0: PME# supported from D0 D3hot D3cold
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.819230] pci 0000:02:07.0: [1b21:1184] type 01 class 0x060400
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.819314] pci 0000:02:07.0: enabling Extended Tags
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.819421] pci 0000:02:07.0: PME# supported from D0 D3hot D3cold
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.820972] PCI: bus2: Fast back to back transfers disabled
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.820978] pci 0000:02:01.0: bridge configuration invalid ([bus 00-00]), reconfiguring
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.820992] pci 0000:02:03.0: bridge configuration invalid ([bus 00-00]), reconfiguring
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.821006] pci 0000:02:05.0: bridge configuration invalid ([bus 00-00]), reconfiguring
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.821020] pci 0000:02:07.0: bridge configuration invalid ([bus 00-00]), reconfiguring
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.821258] pci 0000:03:00.0: [1912:0014] type 00 class 0x0c0330
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.821312] pci 0000:03:00.0: reg 0x10: [mem 0x00000000-0x00001fff 64bit]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.821566] pci 0000:03:00.0: PME# supported from D0 D3hot D3cold
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.823469] PCI: bus3: Fast back to back transfers disabled
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.823477] pci_bus 0000:03: busn_res: [bus 03-ff] end is updated to 03
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.823730] pci 0000:04:00.0: [8086:1531] type 00 class 0x020000
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.823770] pci 0000:04:00.0: reg 0x10: [mem 0x00000000-0x007fffff]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.823806] pci 0000:04:00.0: reg 0x18: [io  0x0000-0x001f]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.823825] pci 0000:04:00.0: reg 0x1c: [mem 0x00000000-0x00003fff]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.824071] pci 0000:04:00.0: PME# supported from D0 D3hot D3cold
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.846968] PCI: bus4: Fast back to back transfers disabled
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.846976] pci_bus 0000:04: busn_res: [bus 04-ff] end is updated to 04
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.848581] PCI: bus5: Fast back to back transfers enabled
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.848587] pci_bus 0000:05: busn_res: [bus 05-ff] end is updated to 05
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850194] PCI: bus6: Fast back to back transfers enabled
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850200] pci_bus 0000:06: busn_res: [bus 06-ff] end is updated to 06
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850212] pci_bus 0000:02: busn_res: [bus 02-ff] end is updated to 06
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850222] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 06
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850247] pci 0000:00:00.0: BAR 8: assigned [mem 0x600000000-0x600dfffff]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850257] pci 0000:01:00.0: BAR 8: assigned [mem 0x600000000-0x600dfffff]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850261] pci 0000:01:00.0: BAR 7: no space for [io  size 0x1000]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850265] pci 0000:01:00.0: BAR 7: failed to assign [io  size 0x1000]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850274] pci 0000:02:03.0: BAR 8: assigned [mem 0x600000000-0x600bfffff]
Aug 21 07:59:56 DC-Pi user.info CONSOLE: done.
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850281] pci 0000:02:01.0: BAR 8: assigned [mem 0x600c00000-0x600cfffff]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850286] pci 0000:02:03.0: BAR 7: no space for [io  size 0x1000]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850289] pci 0000:02:03.0: BAR 7: failed to assign [io  size 0x1000]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850301] pci 0000:03:00.0: BAR 0: assigned [mem 0x600c00000-0x600c01fff 64bit]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850329] pci 0000:02:01.0: PCI bridge to [bus 03]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850339] pci 0000:02:01.0:   bridge window [mem 0x600c00000-0x600cfffff]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850359] pci 0000:04:00.0: BAR 0: assigned [mem 0x600000000-0x6007fffff]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850372] pci 0000:04:00.0: BAR 3: assigned [mem 0x600800000-0x600803fff]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850382] pci 0000:04:00.0: BAR 2: no space for [io  size 0x0020]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850386] pci 0000:04:00.0: BAR 2: failed to assign [io  size 0x0020]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850391] pci 0000:02:03.0: PCI bridge to [bus 04]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850400] pci 0000:02:03.0:   bridge window [mem 0x600000000-0x600bfffff]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850416] pci 0000:02:05.0: PCI bridge to [bus 05]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850437] pci 0000:02:07.0: PCI bridge to [bus 06]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850457] pci 0000:01:00.0: PCI bridge to [bus 02-06]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850466] pci 0000:01:00.0:   bridge window [mem 0x600000000-0x600dfffff]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850481] pci 0000:00:00.0: PCI bridge to [bus 01-06]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850488] pci 0000:00:00.0:   bridge window [mem 0x600000000-0x600dfffff]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850732] pcieport 0000:00:00.0: enabling device (0140 -> 0142)
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.851067] pcieport 0000:00:00.0: PME: Signaling with IRQ 46
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.851452] pcieport 0000:00:00.0: AER: enabled with IRQ 46
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.851823] pcieport 0000:01:00.0: enabling device (0140 -> 0142)
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.852419] pcieport 0000:02:01.0: enabling device (0140 -> 0142)
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.853110] pcieport 0000:02:03.0: enabling device (0140 -> 0142)
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.854833] pci 0000:03:00.0: enabling device (0140 -> 0142)
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.858402] Serial: 8250/16550 driver, 1 ports, IRQ sharing enabled
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.860207] iproc-rng200 fe104000.rng: hwrng registered
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.860351] vc-mem: phys_addr:0x00000000 mem_base=0x3ec00000 mem_size:0x40000000(1024 MiB)
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.861266] gpiomem-bcm2835 fe200000.gpiomem: Initialised: Registers at 0xfe200000
…

For some reason, assigning BAR 2 memory fails:

Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850359] pci 0000:04:00.0: BAR 0: assigned [mem 0x600000000-0x6007fffff]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850372] pci 0000:04:00.0: BAR 3: assigned [mem 0x600800000-0x600803fff]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850382] pci 0000:04:00.0: BAR 2: no space for [io  size 0x0020]
Aug 21 07:59:56 DC-Pi user.info kernel: [    0.850386] pci 0000:04:00.0: BAR 2: failed to assign [io  size 0x0020]

Each time the device is booted the contents of the dump are different. Sometimes the tool says the device is programmed and can't be changed, but most of the time it says, the device is blank. After programming with the file I210_Invm_Copper_NoAPM_v0.6.HEX the tool says, the device is programmed. But after a reboot or after power cut-off the programmed values are gone. It seems that the memory mapping does not get the correct memory area for the device so the data lies somewhere in the normal memory. We use linux kernel version 5.19.15 with rt-patch at the moment if this can help

Thanks once more in advance

0 Kudos
Diego_INTEL
Moderator
2,396 Views

Hello @paul04,

 

Have you tested it in another unit?

 

What is the driver that you are using?

Here is a list of compatibility of the Ethernet Controllers and their supported operating systems:

https://www.intel.com/content/www/us/en/support/articles/000055236/ethernet-products/gigabit-ethernet-controllers-up-to-2-5gbe.html

 

Also, I checked about the email sent that you have asked at first and is referred to creating a ticket using Premier Support.

My apologies for the confusion that could cause.

 

Best regards,

 

@Diego_INTEL 

0 Kudos
paul04
Beginner
2,361 Views

Hello @Diego_INTEL ,

We have tested it with 3 different units with all unprogrammed i210s but we have the same behaviour. Since the i210s are not programmed, we do not even come to the point where a driver is loaded, so the problem surely has nothing to do with the driver.

 

Yesterday we added an empty Flash (from the recommended list of supported flash devices) but the EAT only finds the iNVM. Since we have PCIe cards with the i210 and programmed flash, we took the programmed chip from one of these PCIe cards and replaced it and everything worked. We were able to programm a mac address. Our guess here, is that the EAT for Arm doesn't work with empty flash.

 

Our conclusion is that there should be a problem with the EAT for ARM or in the way the EAT for ARM accesses/reads/writes the memory areas via PCI in both the iNVM and/or flash.

As mentioned before, we use mainline Linux kernels on Raspian, Debian and Ubuntu as well.

 

We are aware, that these issues might not be present on the windows operating plattform, but since our operating systems are all Linux-based, there's no way for us to change. Could you please have an in depth look into this or point us maybe to the appropriate person, who could help us?

 

Thanks in advance

0 Kudos
AliUS
Beginner
3,003 Views

Hello @CarlosAM_INTEL 

We are currently facing the same problem stated in this post. We designed our own board based on an Raspberry CM4 interfacing with I210. We tried to program I210 using EepromAccessTool and it seemed to have been programmed when we execute "./EepromAccessTool -nic=1 -dump" command. However, after a power cycle, the same command returns a blank INVM. Do you have any information that may help to solve our problem?

Best regards,

0 Kudos
Diego_INTEL
Moderator
2,973 Views

Hello @AliUS,

 

Thank you for contacting Intel Embedded Community.

 

Which NVM version do you have actually? I will check if there are any related errors.

 

Best regards,

 

@Diego_INTEL 

0 Kudos
AliUS
Beginner
2,963 Views

Hello @Diego_INTEL  

Thank you for the reply. We are trying to program the integrated NVM of I210, which have a size of 8Mb.

Best regards,

0 Kudos
AliUS
Beginner
2,905 Views

Hello @Diego_INTEL

Is there any update on this issue?

Best regards,

0 Kudos
Diego_INTEL
Moderator
2,889 Views

Hello @AliUS,

 

I was checking information regarding what may be causing this issue and found that this may be related to the driver. You can try to unload the driver before using EEPROM Access Tool again with non blank devices.

 

You may check in RDC the document #634290 - EEPROM Access Tool User’s Guide, you will need a Premier account to get access to it.

 

Best regards,

 

@Diego_INTEL 

0 Kudos
Markus6
Beginner
2,649 Views

Hello @Diego_INTEL ,

we have the same problems that @AliUS described in his post. We have a own board using the Raspberry CM4 and interfacing an i210 flashless i210 chip. When using the eepromArmTool programming the integrated iNVM it looks all fine and the dump shows the previous written data. But after powercycle the chip still shows the device ID 1531 for blank i210 devices and isn't recognized from linux igb driver. Can you send me the latest eeprom tools for arm and give me some hint what's going wrong ?

Best Regards,

Markus

 

 

0 Kudos
Diego_INTEL
Moderator
2,599 Views

Hello @Markus6,

 

Thank you for contacting Intel Embedded Community.

 

Yes, can be a bug with the version files that you are using.  This is a recommended documentation list for the i210, but they will require a Premier account to get access to them or you may ask to any Intel Sales Representative near your zone, this way you can get help in getting access to these documents.

 

#634290 - EEPROM Access Tool User’s Guide

#513655 - Intel® Ethernet Controller I210 and I211- AT Production NVM Images

#348742 - Intel® Network Connections Tools 28.0 PV LAN Software Tools

You can check this FAQ if needed: https://www.intel.com/content/www/us/en/content-details/334026/

 

Best regards,

 

@Diego_INTEL 

0 Kudos
Reply