- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I am trying to get the i210 to work with the existing driver for the 82574 on VxWorks 5.5.1 which is built on the original 82643 driver. Everything looks good (to me) but no data is actually transmitted. The device appears to be able to receive ok as there is evidence in the counters and these match reasonably well with the counters in the Cisco switch for the port it is connected to. We have a link at both ends and auto-negotiation is successful.
The VxWorks driver uses queue 0 only and it creates the context on each send.
Below are the main registers of interest - VxWorks only modifies registers 0, 4 and 9 in the PHY.
10:02:38 gei82543EndStart:Link is up
10:02:38 phy reg 0: 00001000
10:02:38 phy reg 1: 0000796d
10:02:38 phy reg 2: 00000141
10:02:38 phy reg 3: 00000c00
10:02:38 phy reg 4: 00000de1
10:02:38 phy reg 5: 000043e1
10:02:38 phy reg 6: 00000005
10:02:38 phy reg 7: 00002001
10:02:38 phy reg 8: 00000000
10:02:38 phy reg 9: 00000300
10:02:38 phy reg 10: 00004000
10:02:38 phy reg 15: 00003000
10:02:38 phy reg 17: 00007c08
10:02:38 gei82543EndStart: TCTL is: a40400fa
10:02:38 gei82543EndStart: STATUS is: 00280743
10:02:38 gei82543EndStart: CTRL_EXT is: 101c0000
10:02:38 gei82543EndStart: CTRL is: 00001941
10:02:38 gei82543EndStart: IPCNFG is: 0000000f
10:02:38 gei82543EndStart: PHPM is: 0000019d
10:02:38 gei82543EndStart: TXDCTL is: 02010000
I would appreciate any ideas as to what may cause this behaviour.
Thank you.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Xu Xiong,
The most important thing is that the receiver queue 0 must be enabled before writing to the RDT register (INTEL_82543GC_RDT). The VxWorks driver can only use queue 0 and writes to RDT are ignored if the queue is not enabled first.
You also need to enable the receive filter on queue zero in function gei82543EtherRxAdrSet
The i210 has a different interrupt delay timer. I set EITR to 175us (175 << 2).
Hope this helps.
Best regards,
DJL
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello DJL,
Thank you for contacting the Intel Embedded Community.
The VXWorks drivers are generally supported by their developer. You can confirm this information as a reference on page 3 of the http://www.intel.com/content/dam/www/public/us/en/documents/platform-briefs/atom-processor-e3800-platform-brief.pdf Intel(R) BayTrail Product Brief.
By the way, this Operating System (OS) is unlisted as a supported by the Intel(R) Ethernet Controller I210 and Intel(R) 82574L/82574IT Gigabit Ethernet Controller. You can confirm this information at their Product Briefs that can be found at the following web sites:
http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/i210-ethernet-controller-family-brief.pdf http://www.intel.com/content/dam/www/public/us/en/documents/product-briefs/i210-ethernet-controller-family-brief.pdf
http://www.intel.com/content/dam/doc/product-brief/82574l-82574it-gbe-controller-brief.pdf http://www.intel.com/content/dam/doc/product-brief/82574l-82574it-gbe-controller-brief.pdf
Due to these facts, we suggest you contact the manufacturer of the cited driver to received further answers to your questions of this kind.
On the other hand, could you please confirm that the 82643 part number is related to an Intel product? In case that your answer is affirmative, could you please send us documentation related to this device?
Thanks in advance for your collaboration to solve this inconvenience.
Best Regards,
Carlos_A.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Carlos_A,
Thank you for the information.
The version of VxWorks that we are using in obsolete and no longer supported, hence the reason I am looking at adapting the existing driver to support the i210.
The driver that we have is based on the original 82543 (not 82643 which was a typo) and has been developed (by Windriver) to include many Intel devices. The source code for the drivers is supplied with the kernel to enable users to add to and modify as required. Therefore, it is up to me get it working.
I have now succeeded in transmitting (ARP requests) but for an as yet unknown reason the received data isn't populating the receive descriptor. The VxWorks driver only uses legacy descriptors, so the devices are very similar. I just need to find the write "spell" to complete the loop. I had hoped that the Intel embedded community would be the best place to look for advice getting the i210 configured.
Best regards,
DJL
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello DJL,
Thanks for your update.
In this instance, since you are trying to adapt an old driver on an unsupported OS to a new part, all we can suggest is that you look at the Linux driver that supports the i210 and compare to the driver you are attempting to modify as we have suggested. It's fairly well documented within the code itself.
We suggest to address the questions related to this forum at the following mail list: mailto:e1000-devel@lists.sourceforge.net e1000-devel@lists.sourceforge.net, where they may help you.
Please let us know if this information is useful to you.
Best Regards,
Carlos_A.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Carlos_A,
Thank you for the information. I have now succeeded in getting the driver to transmit and receive, but unfortunately the driver doesn't send FTP messages (critical for loading the kernel and software at run time). It handles TCP, UDP and ICMP just fine, but I have no idea at the moment as to why it singles out FTP. I guess I'll just keep digging and compare the config to the Linux driver as you suggest.
Best regards,
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Carlos_A,
Just as a final update, I have today configured the driver to operate with the i210. There wasn't very much to do in the end, but all the bits need to be in the right place!
Best regards,
DJL
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Carlos_A
I got the same problem like DJL,my i210 netcard can not receive,and when I send data to it, it can not cause trigger receive interrupt.
but i210 can trigger link and send interrupt.
can you solve the problem for me, thanks a lot!
Best Regards.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, DJL
Thank you for your update. I am now trying to make the mpc8241 work with 82574 on the Vxworks5.5. The probem I am facing to is simliar to you. the status of phy and mac is ok. the software have writed packet into the Context Transmit Descriptor, the STA.DD is set by 82574. but the packet isn't transmitted. How can you slove you probem.
Thank you !
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello daiwei@0701,
Firstly I apologise for this delayed response - I have been a bit busy.
I am using x86 architecture so the driver I have may be different, although it does have a big endian option so could be the same.
For me the main problem for transmitting was the descriptor type definition - the i210 is completely different.
I don't think this is your problem, however.
One thing I noticed in our driver is that the driver uses extended transmit descriptors, but the check sum offload is
disabled (there is a typedef missing so it can never by enabled!) and therefore no context descriptors were ever setup.
This could be an issue for you, but it didn't seem to have a detrimental affect for us.I tried it in legacy mode and it worked just fine.
The 82574 looks to be pretty much identical to the 82573, so if your driver supports this then you could try this option.
Adlink Technology did have a BSP for their (now obsolete) cPCI6870. It may be possible to download it from their website - just a thought.
Best regards,
DJL
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello DJL,
I am doing the similar works like you.The OS is vxworks5.5,original driver is 82574.Now, the driver with i210 can transmit data,but it can not receive data.
The key problem is that,i210 can't go to interrupt model when I send data to it. I set interrupt register IMS,receive register RXDCTL.But it can't cause interrupt.
I sure PCI interrupt is good,because link and send interrupt are both good.
SO, can you tell me if there is some other register need to be set. How do you configure the i210 register.
Best regards,
Xu Xiong
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Xu Xiong,
The most important thing is that the receiver queue 0 must be enabled before writing to the RDT register (INTEL_82543GC_RDT). The VxWorks driver can only use queue 0 and writes to RDT are ignored if the queue is not enabled first.
You also need to enable the receive filter on queue zero in function gei82543EtherRxAdrSet
The i210 has a different interrupt delay timer. I set EITR to 175us (175 << 2).
Hope this helps.
Best regards,
DJL
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi DJL,
Thank you very much.My problem has been solved according to your advise. The receiver queue 0 must be enabled before writing to the RDT register.
Thanks again.
Best regards,
Xu Xiong
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi DJL,
I got a problem again.When I test i210 dirver for TCP socket,it can't communicate with PC server correctly.
The client use connect() function connect to server.
Wireshark capture tcp packet sent by i210 successfully. but it just can't connect.
I guess I set the TCP/IP Context TX descriptor incorretly.
Below is my configure.
IPLEN : 20
MACLEN :14
Both values are got from mBlk structrue.
L4T:1
IPV4:1
DTYP: 0010b
DEXT:1
IDX,L4LEN,MSS are not set.Because I don't use TCP Segmentation
If I miss something else important for configuring the Context TX descriptor.
Can you solve the problem for me.
Thanks a lot
Best regards,
Xu Xiong
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Xu Xiong,
Sorry for the delay in response, but I have been away.
You have to use the legacy tx data descriptor (DTYP = 0x3) as the Advanced descriptors are not supported by the rather old driver. The 82574L uses Extended descriptors but these are completely different to the Advanced i210 descriptors and are not compatible.
You need to modify "LOCAL void gei82543LoanTransmit" . You will need to set TX_CMD_IFCS at the start too and there is no need to set TXD_CMD_IDE or TXD_CMD_DEXT either for the i210.
At the end of this function you will need to set TXD_CMD_EOP and ensure that TXD_CMD_RS is set too.
I set the TCTL_PSP_BIT in INTEL_82543GC_TCTL but not TCTL_MULR_BIT or TX_COLLISION_THRESHOLD as the i210 does not have these.
Hope this helps,
DJL
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello DJL,
I just use software checksum ,but I found that net card speed is slower,so I try to solve it again.
Firstly,by reading i210 datasheet ,I can't found legacy tx data descriptor (DTYP = 0x3),there are three types of descriptor:Legacy Transmit descriptor, Advanced Transmit Context descriptor and Advanced Transmit Data descriptor.
Could you Tell me where is legacy tx data descriptor.
Secondly,If I don't set TXD_CMD_DEXT,Does that means I use Legacy Transmit descriptor?
Looking forward to your reply!
Thanks.
Xu Xiong
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Xu Xiong,
Section 7.2.2 has a good description of the transmit descriptors.
Yes, you do not set TXD_CMD_DEXT and you need to create a new version of TXD_DTYP_BIT,say TXD_CMD_DEXT_I210, for the i210 with a value of 0x03. So I found that you need to set TXD_CMD_IFCS, TXD_CMD_RS and TXD_CMD_DEXT_I210 for the i210 which is quite different to the 82574L. The bit shifts are the same however.
To help with working all this out I turned on the driver debug macro and added loads of additional output and printed the addresses of the descriptors. Then I used the vxWorks d() command to display the memory and was able to pick through the descriptors. What I found before I got it working fully was that packets that spanned just one descriptor worked perfectly, but failed when the packets spanned more than one descriptor. So I'd definitely recommend doing this if you are still stuck.
Good luck,
DJL
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello DJL
Now,I'm trying to use Legacy Transmit Descriptor Format, but there are also some problems that I can't solve.
When If I set IC BIT in Legacy Transmit Descriptor Format , it seems that the net card can't send the tcp packet data, Wireshake also can't capture tcp packet too.
If I did't set IC(Insert Checksum) Bit , the net card can send tcp packet.
Please give me some ideas ,thanks.
Xu Xiong
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello DJL
where are you?
Please show up,I really need you help
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Xu Xiong,
I have been unable to login to the community do to a password reset problem.
The only thing I can think of is in "LOCAL STATUS gei82543LoanTransmit()" you set TXD_CMD_IFCS in dataCtx at the top for the i210 (not for the other standards) before the forever loop and then OR dataCtx with (TXD_CMD_EOP) << 24 after the lastseg: goto tag.
The other devices OR in TXD_CMD_IFCS at this point - seems odd but that's how it is.
If this doesn't work for you I'm not sure that there is much more I can add I'm afraid, as I am running out of ideas.
Best of luck,
DJL
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page