Migrating to i210 - BAR0 has zero address. Did we miss a step?

[mjhammel]

My company has a board with an i211-AT.  We're migrating it to an i210-AT.  The i210 is reported to work with no flash and I don't think there is one on this board. 

The Linux igb driver (kernel 5.4.44, but it's the same with 5.15.21) probe fails in the pci_iomap() call.  The failure is because BAR0 has no address reported.  If you dump pci for this device you can see that there is nothing in that register space.

$ lspci -vv -s 04:00.0 -xxx | tail -17
00: 86 80 31 15 40 01 10 00 03 00 00 02 10 00 00 00
10: 00 00 00 00 00 00 00 00 01 10 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 00 00
30: 00 00 00 00 40 00 00 00 00 00 00 00 29 01 00 00
40: 01 50 23 c8 08 20 00 00 00 00 00 00 00 00 00 00
50: 05 70 80 01 00 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 11 a0 04 00 03 00 00 00 03 20 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff ff
a0: 10 00 02 00 c2 8c 00 10 10 28 10 00 11 7c 42 02
b0: 00 00 11 10 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 1f 08 08 00 00 00 00 00 00 00 00 00
d0: 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Checking the upstream 6.12.1 kernel it appears that the driver still expects pci_iomap() to not return 0 (or NULL).  So a non-zero BAR0 address appears to be a required thing for igb devices.

This failure appears to happen before any board identification is done in the driver as far as I can tell, so I don't think the flash vs no-flash question has been tested at this point. 

My question is:  is there some bit of fw programming that we've missed on this configuration?  I've not been given any .bin and did not see anything in the upstream Linux git firmware repo, but I have found some Linux tools for programming various similar Intel chips (i226-LM, i210-AT, possibly some others).  My team is questioning whether we can run without some additional firmware programming.

Any tips would be appreciated.

[mjhammel]

I forgot to mention that the board in question is an Arm7 board:

processor       : 1
model name      : ARMv7 Processor rev 10 (v7l)
BogoMIPS        : 7.54
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc09
CPU revision    : 10

We also have a copy of intel_eeprom_access that appears to support I210 (based on the BrandingStrings in main.c) NVM programming and which compiles for this board and does see the NICs, but it complains about the missing BAR0 address.

$ ./intel_eeprom_access 

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
===     ===     ===     ===     =====   ======================
No Memeory BAR resources supplied by OS/BIOS.
Tool will not work correctly without it.
 1      4        0       0      I210         INVM+FLASH
No Memeory BAR resources supplied by OS/BIOS.
Tool will not work correctly without it.
 2      5        0       0      I210         INVM+FLASH

A PCI device should not need a DTS file so I'm curious why BIOS would be needed to supply the Memory Bar.    I don't know if this tool is supposed to work on the I210, just that is reports to support it. 

I've seen reports that the following is required on I210's under Linux:

eeupdate64e /nic=2 /invmupdate /file=I210_Invm_Copper_NoAPM_v0.6.txt

However, I can't find the eeupdate64e program anywhere, nor it's 32bit cousin for Arm7.  I do have the I210_Invm_Copper_NoAPM_v0.6.txt file.  I'm hesitant to try it with intel_eeprom_access without knowing I can undo anything that doesn't work.

[mjhammel]

More info:

We found the eeupdate[64/32] programs in the file 348742_Quartzville Tools_710913.zip but they are prebuilt for either Intel or ARM64 or Solaris/FreeBSD, etc.  We need a static ARM32 build or the source to build ourselves.

That said, we also found forum discussions (a coworker with privileged access to Intel stuff which I don't have) that suggest the  intel_eeprom_access utility that we have actually comes from Intel.  We have source for version 0.8.0.  It seems that MIGHT work to program the iNVM, but it fails because of the NULL field in BAR0. 

So it seems we MUST have an address in BAR0.  But we don't.  The error message from intel_eeprom_access

No Memeory BAR resources supplied by OS/BIOS.

suggests that the BIOS would setup that address.  Since this is ARM7 that would need to be done in a DTS file.  I'll google around to find out the proper syntax for pcie configs in dts files, but it won't tell me the proper address to use.  Since this is a flash-less implementation we'll be using the iNVM, correct?  So I need the address of the iNVM for BAR0?  Is that correct?  Where do I get that from?

I've also downloaded the latest (that I can find - July 2024) driver packages for Linux.  They seem to have the same issue - that pci_iomap() requires a BAR0 address before any PCI ID checks are done.  So even if you're using flash-less mode for the i210 it seems we need a non-zero BAR0 address.

I just don't know exactly where that is supposed to come from, or what form it should take (DTS, hard coded, etc.).  Again, any help would be appreciated.