We have designed a PCB with an I210 controller (in flash-less mode) connecting via PCIe/SMbus to an E3950 (running Ubuntu 18.04).
But Linux is unable to fully see the I210 device. It shows up in 'lspci' with ID=0x1531 but it's config space is all '0xFF':
>> 02:00.0 Ethernet controller: Intel Corporation Device 1531 (rev ff) (prog-if ff)
>> !!! Unknown header type 7f
>> 00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> 10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> 20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
>> 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
We have also tried some Intel tools such as eeupdate64 and lanconf64e but they do not see the I210 at all. So we are unable to program the iNVM.
Using another Intel tool 'EepromAccessTool' v0.7.7, it sees the I210 but trying to dump that nic (-dump -nic=1) hangs trying to read from the device:
# sudo ./EepromAccessTool
Intel(R) EEPROM Access Tool NVM/OTP Programming Example Tool Version 0.7.7
Provided under the terms of a CNDA. Do Not Distribute.
Copyright(C) 2017-2018 by Intel(R) Corporation
NIC BUS DEV FUN Silicon Memory Type Present
=== === === === ===== ======================
1 2 0 0 I210 INVM+FLASH
2 3 0 0 I211 INVM
It seems the PCIe interface is not coming up, so we are renting a scope w/ PCIe decode to debug.
In the meantime, my question:
1) We would like to dump some SMbus registers to help debug, but in Linux the SMbus and I2C use same function call. It seems Linux treats the two protocols as the same. So we don't know how to write out the dedicated HW SMbus port to the I210. Can you advise how to query SMbus registers?
Thank you for contacting Intel Embedded Community.
Could you please verify if this situation persists in any of the following Operating System (OS)?
- Windows* 10 Enterprise (64-bit).
- Windows* IoT Core (32/64-bit).
- Wind River 8 Linux distribution (64-bit).
- Yocto Project* BSP tool-based embedded Linux distribution (64-bit).
- Android (64-bit) Marshmallow PV April 17.
- Android O ETA target Q2 ’18.
- Wind River VxWorks* 7.
We appreciate your cooperation.
At this point we suspect an electrical issue is preventing the PCIe bus from coming up correctly - we have rented a scope and are investigating.
My question is related to the SW side though:
* We would like to dump some SMbus registers, but in Linux the SMbus and I2C use the same function call. It seems Linux treats the two protocols as the same. So we don't know how to write out the dedicated HW SMbus port to the I210. Can you advise how to query SMbus registers?
In our design, the I210 SMbus interface is routed to the Atom SMbus port. The Atom I2C bus in our design is routed to other IC sensors, etc. We are able to read those sensors on I2C bus.
We would like to read SMbus registers from I210 from Atom, but don't know how in Linux. Can you recommend some example code showing how read from the SMbus?
We are also considering running the clear linux project, and wanted to check if you support that OS as well for the E3950? From a support standpoint.
Thanks for your clarification.
Please verify using the channels listed in the following websites as a reference if the cited OS fulfills with the requirements of the Operating Systems suggested in the provided product brief:
Thanks for your reply.
We suggest you use any of the validated OS for the processor that you are using. The OS list is stated on page 4 of the Apollo Lake Product Brief that can be found at:
Ok thanks, we will put yocto on the E3950 to continue debug.
* Does Intel provide any documentation for installing Yocto on Atom, or should I just follow the directions on Yocto site?
* For Yocto configure, is the E3950 info contained in the 'meta-intel' layer? Are there other layers I also need to clone before build?
Thanks for your reply.
We suggest as a reference review the following websites:
We were not able to get a flash-less solution working with the i210. As above, we were not able to talk to it with Intel's tools eventhough it showed up on the PCIe bus as ID=1531. Our conjecture was that the i210 internal NVM probably needs to be initially programmed before it fully shows up on the PCIe bus. If true, kind of a chicken-and-egg problem for us since we need the Intel tools to program it in system, but it can't see it until the NVM is programmed.
So we abandoned flash-less operation and added a flash. However, we still got the same above situation. We could see it as ID=1531 but Intel tools couldn't program it. Finally we re-soldered in a flash programmed with one of the Intel provided hex images (Dev_Start_I210_Copper_SMB_8Mb_A2_3.25_0.03.hex in our case) and then were able to see the i210 with Intels like lanconf and eeupdate. We then could program the internal NVM.
Now our issue is programming the MAC address to the NVM is producing an incorrect checksum, detected when linux boots so it does not enable the interface. But we can see Linux is using the 'igb' driver for the PCIe device so this is great progress. But if needed I will open another ticket concerning the incorrect NVM checksum