We are using I210 blank chip along with imx6 dual lite processor in embedded Linux environment. The device is detected in the U boot with device ID 1532.
(So i assume HW wise the chip works and is connected properly) But when linux kernel loads it hangs in the screen "Loading kernel".. We have enabled the following in the menuconfig.
PCI bus support and PCI debugging enabled
Under Kernel LL debug
Under Device Drivers > Network device support > Ethernet driver support
Intel(R) PRO/1000 PCI-Express Gigabit Ethernet support
Bus support > PCI host controller drivers
Freescale i.MX6 PCIe controller
EP and EC mode are not selected
If we don't enable PCI support then the Kernel and RFS boots up properly. Even though PCI and early printk are enabled i don't see any error dbg mssgs from the kernel nor failure dbg mssgs before the kernel hangs. Do i have to enable any more modules in the kernel. Am I missing some configuration in the kernel?? Only if the device is listed i can use the eeupdate tool and configure the iNVM.
Welcome to the Embedded Community.
The PCI ID of 0X1532 is the hardware default for the i211 Controller. Probably you have somehow programmed the i210 controller with a device ID that it should never be programmed for, or it is actually an i211 that has simply not been programmed. None of our drivers will load on that device ID, since it is not a supported device ID.
Our software tools will recognize it as an unprogrammed device, but since you are running an ARM processor none of our regular tools will work.
I send you a tool that might be useful, please check your e-mail and confirm if you received it, I hope this helps.
Thanks for the quick response. Sorry that was a typo its a blank i211 chip that we have. For the tool to work it must first be listed under PCI right? (in lspci) thats were I'm stuck. if i enable PCI support then the kernel hangs. So i want to know if I'm missing something in the kernel config. Once i resolve the issue i hope i can use the tool to program the PHY and then the kernel driver will load for this interface
Stanly, we are checking on this for you. I also understand that an Intel sales representative has contacted you. This person may also be able to help you in where to buy.
Stanly - I understand that Calvin our sales rep has been in contact with you. Although a pre-programmed i211AT controller is not available, I am glad that he was able to offer an alternate solution. Thank you for placing your question in the Embedded Community. Thanks gabriel.thomas and AdolfoS for helping SStanly , too!
An unprogrammed i211 controller should show up in PCIe config space. If it doesn't, there is something fundamentally wrong. This could be due to a PCIe bridge configuration issue, or some hardware issue. Even if the i211 crystal is not running, the PCIe clock would allow it to show up in PCIe config space, although as a non-functional device. This issue has to be resolved before we can continue to troubleshoot.
Please double check the configuration and if you have a second controller you can try that too, just to discard damage on the device.
We were able to enumerate this PCIe from the uBoot with a device ID of 0X1532.
For us this is the only device that resides on the bus.
The i211 should show up in the PCIe configuration space. Even if the i211 crystal is not running, the PCIe clock would allow it to show up in the PCIe configuration space although as a non-functional device. This could be due to a PCIe bridge configuration issue, or some hardware issue.
-Is this the only device that you have available? If not, have you tried with other controller?
-I would suggest looking advices in the http://www.arm.com/community/ ARM® Community
Also it could be a hardware problem with your ARM device, so you might want to contact your vendor.
Hope this information is useful to you.
Will check on the ARM community as well as with the vendor to figure out if there are any configuration or hardware issues.
We were able to resolve the device detection issue in the linux kernel. There was a conflict between U boot and Kernel and hence the device was detected properly in Uboot but not in Linux kernel. Now the device is properly listed under lspci tool all the time. When we run the arm eeprom update tool we get a bus error and it doesn't list the device. I have provided the issue details and the error screen shot below
The tool is trying to mmap() the i211 registers, but the mmap() call fails with the error.
This is the code that does the mmap
Mapped1Address = mmap(NULL, 4096*32, PROT_WRITE | PROT_READ, MAP_SHARED, FileDescriptor, (off_t)WordLocation );
We are using linux-imx kernel v3.10.17r2 with Yocto BSP for freescale ARM.
Could you please add the line
printf("Error code: %d\n", Mapped1Address)
to the PciEeprom.c file, this will allow us to see what error the mmap returns.
We debugged the issue further. Actually the mmap call is passing and allocating memory. When the tool tries to access the memory later the crash happens
"return (u32) *((u32 *) Reg);" is executed bus error occurs, in file PciEeprom.c function ReadReg. Please let us know how to debug this further?
We were able to get the tool working. We had to do modification on the Linux kernel driver to get the memory mapping to work. We were able to successfully download the hex file and the controller is now enumerating as i211 properly and the ethernet driver got loaded. We are still yet to get the ethernet stack up and running for this port. Will provide a update once we sort it out.
Is great to hear that. I'm glad that you could solve this issue.
We really appreciate when we receive feedback from the Intel Embedded Community members.
Thanks for letting us now.
I got feedback from one of our experts; I think his advice could be useful to you or to other developers.
One of the possibilities when this kind of this happens is that and Endian conflict, ARM processors allow mixed Endian modes, so it is possible that a user is not really accessing what the memory addresses that he think he is accessing. The eepromARMtool documentation have useful info about this issue.
Other possibility is that for certain hardware or Operative System, the Operative System locks the page after it was allocated.
We have one more issue in getting the i211 controller up and running i have explained the issue below.we were able to get the tool working and we downloaded the binary file to the PHY controller and the ethernet driver got loaded. But we are not able to get the ethernet stack working. The ethernet driver is not able to get the correct MAC address from the iNVM. The tool writes the MAC address at a particular offset whereas the ethernet driver looks for the MAC adds at a different offset. I have provided the problem details below.
From the eepromtool, the offset value at which we are writing our hex data is 0x12120, The first data we write is the MAC address
code snippet of intel eeprom tool# define INVM_DATA_REG(_n) (0x12120 + 4 * (_n)) // Represent register offsets using this equation
In Intel igb driver we are reading the MAC adds from 0x54XX regionFile e1000_nvm.c
* igb_read_mac_addr - Read device MAC address
* @hw: pointer to the HW structure
* Reads the device MAC address from the EEPROM and stores the value.
* Since devices with two ports use the same EEPROM, we increment the
* last bit in the MAC address for the second port.
s32 igb_read_mac_addr(struct e1000_hw *hw)
rar_high = rd32(E1000_RAH(0));rar_low = rd32(E1000_RAL(0));
# define E1000_RAL(_i) (((_i) <= 15) ? (0x05400 + ((_i) * 8)) : \<p> (0x054E0 + ((_i - 16) * 8))) # define E1000_RAH(_i) (((_i) <= 15) ? (0x05404 + ((_i) * 8)) : \</strong> (0x054E4 + ((_i - 16) * 8))) We are using driver v5.0.3-k that came with linux-imx kernel v3.10.17r2 as part of the Yocto build system from iMX. From Intel's website where igb drivers are available for download, I am not able to locate a 5.0.3-k version. I also see that the current version of igb driver in Intel's website is 184.108.40.206. When we compare the source code of this version with the 5.0.3-k version we have, they are way too different. What is the correct version of the driver that we need to use to be compatible with the data written by the eeprom tool.
I appears that another person from your company is also working with Intel regarding this issue. The response to your coworker was:
I do not know about the driver v5.0.3-k that came with linux-imx kernel v3.10.17r2 or the Yocto kernel release details. I know Yocto is something some groups are working on within Intel in embedded space and need to do some internal consulting to get you a meaningful answer. My hunch though is this is an embedded driver and might need some work to port it into the ARM platform. But in the meantime as a step forward as I find out more about Yocto, is it possible to use a regular kernel with the latest driver on your system?
I can give you some debugging tips on how to get the device and driver working if you run into a road block with the latest driver with a supported kernel. But remember, our drivers are for x86 architecture and you will most likely have to do some massaging to get it working in ARM.
Hi, SStanly! I understand that we have good news and your issue is resolved once the MAC address was programmed properly. Glad to see that working together drives resolution! Have a great day and we look forward to seeing you again sometime in the Embedded Community! LynnZ. ...and thanks Sourav for your assistance, too!
I'm glad that this issue has been resolved
It would be possible for you to share the details of the modification of the linux kernel driver that you made to get the memory mapping to work?
That could be very useful as a reference for future developers that might to face the same problem.
If your company policies don't allow you to do so, I completely understand.
It has been a pleasure working with you