NDK Port 2 support

Hi John,

This looks like an issue in the driver.  I'll bring this thread to the driver team's attention.

Steve

Hey Steve,

     Thank you. I'll be waiting. Currently trying to track how the Transmit DMA queues operate in the AM335x switch.

John C.

John,

         The NDK stack and the CPSW driver  is tested over two ports. The default driver configures the CPSW in switch mode (use single mac address). But we don't support Dual mac mode as if now (Both ports with separate mac address).

I think the issue you are facing is related to using the second port alone as mentioned in the post

 http://e2e.ti.com/support/embedded/tirtos/f/355/p/361927/1272774.aspx#1272774 

i guess you are using only one port  now. So you must ensure you configuring the driver to configure one port only and make sure you are configuring the correct PHY address.

Please let me know if you have more queries

Thanks,

Prajith

Hey Prajith,

     I'm having an issue using that link.

Thanks,

     John C.

hmm

It's just some foru/post problem click here:

http://e2e.ti.com/support/embedded/tirtos/f/355/p/361927/1272774.aspx#1272774

But it seems to be another post made by you, so I'm not sure if this was what Prajith really meant to post.

BR

J

Thanks for the reply

     We have seen that the current NDK CPSW code is very close to the lwip implementation as far as register programming on the AM335x. The one distinct difference is that the lwip does use the CPSW_DUAL_MAC_MODE by programming the 3PSW vlan registers so that the connections only go between port 0--1 and port 0--2(never port 1--2). There is also driver code that puts/uses the port number in the cpdma "buffer descriptors-->flags_pktlen" field.

     We need to either try this valn method or take one last attempt of using a single port that is not the first port. So is there something specific about how the NDK drivers currently work that would prevent us from using the same vlan method? Is there any internal TI code that might have the CPSW_DUAL_MAC_MODE implemented (like the lwip port is done?)

Thanks,

     John C.

While I'm adding questions,

     In the file cpsw_ethdriver.c, function Cpsw_HwPktPoll(). The for loop is going from 0 to the number of mac ports(which is normally one) minus 1. The first thing it looks at in the loop is the ALE port state and the mac phy mode. The question with this is that the loop starts at zero, instead of one. We believe ALE port 0 is referring to the CPSW port 0 which would be the port that is connected to the ARM. So why are looking at the ARM port of the ALE and and the port phy mode (which is not related to the ARM port, but ports 1 or 2) when the phy's are connected to different CPSW ports?

     We understand that the code is running for other customers, but for us to modify it for our application we need to clearly understand this.

Thanks,

     John C. 

John,

Dual Mac Mode is something that the Industrial SDK does not support. To achieve this, modification is required right at the icss_nimu_eth.c layer . A separate interface will have to be added to NIMUDeviceTable(In AddNetifEntryFn)

The LWIP example(Starterware) can be used as a reference to implement this.

On the second question, I think you are right. As per the TRM, the PORTCTL registers have instances 0, 1 and 2. HwPktPoll check the states of the ports and updates the internal phy structures, and 0 looks irrelevant here. However, will have to do some tests before verifying.

Regards,
Vinesh

Hey Vinesh,

     I am trying to see why my modifications to the NDK have not worked on our board. We are running the lwip in dual mac mode just fine. As I mentioned lwip uses dual mac mode by setting up vlan's to insure port 0-1 and 0-2 are the only connections between ports. It also hides the port numbers in a local cpdma struct to track them. Because of the vlan use to insure the packets never get forwarded between ports 1 and 2, I don't see how the NDK code would ever work without it also needing to use vlan's. So adding another interface to the NIMUDeviceTable without the accompanying vlan code does not seem like it would be successful. 

     I have modified the code to use only the second port in a single port configuration, but there are no packets being transmitted or received. My last guess as to why it might not be working is the cpdma channels. The cpdma uses a two dimensional array with the first element representing the transmit or receive direction(0-transmit, 1-receive.) The second element carries the buffer descriptors. It seems that only [0][0] and [1][0] have descriptors, and because the TRM has no description of what the second elements 0-7 index means, I have no way of trying to follow a transmit operation through. Can you tell me what the 0-7 index of the cpdma channel descriptor is attached to?

Thanks,

     John C.

     Still can not get any packets to transmit. We have been focused on using a single NDK port, with that port being number 2 instead of 1. We did notice that when the lwip implementation was not using "dual mac mode" it populated the ALE table with a multicast entry for ports 0, 1 and 2. It also put in the active port mac address as a unicast address table entry. We implemented this ALE table population but outgoing DHCP request packets still did not make it to the wire (but the CPSW_STATS (0x4A100900) looked a bit better than if the ALE table was not populated.)

     The table below shows that the Ethernet subsystem thinks that it is transmitting the packet with the receive direction having a lot of CRC and/or Alignment errors. We have concerns that without the ALE table being populated (which is the NDK default) it would not direct the packets to the proper CPSW ports.

1. Is there someplace to look to see why the CRC/Alignment errors are happening?
2. Has the NDK code ever been run using CPSW ?

Thanks,

John C.

We have found a piece of the issue. During the NIMUPacketServiceCheck()-->CpswEmacPoll-->Cpsw_HwPktPoll-->cpsw_MDIO_Tic-->cpsw_MDIO_FoundState call tree, the Ehternet phy is getting reset. This sequence happens when the system is already running and trashes our phy settings which are custom to fix an errata on our Micrel KS8721BL phy. When we skip over the phy reset, we are able to transmit a DHCP request packet onto the network. We still can not receive any packets due to CRC/Fragment errors.

There are also some issues with the cpsw_MDIO_FoundState() function. The code that checks for

1. A phy reset
2. Programing auto-negotiation into the Ethernet phy

     Both if statements which use flags that are never modified and don't make any sense (the checks of auto_neg1 and auto_neg2 will always be the same.) Has this code ever been run on a board and if so, why would you always reset the phy chip?

Thanks,

     John C.

Still cannot receive any Ethernet packets. After fixing the phy reset, we verified all the Micrel KS8721BL phy registers are set correctly, but we are still getting 'Rx Align/Code Errors' and 'Rx Fragments'. If you look at the CPSW stats register 0x4A100900:

Gives the following table:

    So the broadcast frames are making it to the wire, but the Receive errors are still there. We can bring the system up under sys/bios lwip and everything is fine and the phy registers are the same. What else could be causing these receive errors? The ALE changes do not effect anything that we can see, so we think that it must be some other configuration of the CPSW.

     Any ideas?

Thanks,

     John C.

Went back to the original code base (which can only use port 2 if you have two mac addresses) and insured the phy was advertising only 10/100 speed (no 1G). We are finally able to get the DHCP client to get an IP address.

John C.