AM6548: UDMA with CPSW debugging guidelines

Hello TI,

Can you please help me here? I am blocked on my driver development.

Umair

Muhammad,

Can you confirm if you've seen the supplemental UDMA material included to the PDK? This may help at least with the high-level architecture and connectivity, as well as migration from previous architectures. It's included in <pdk>\packages\ti\drv\udma\docs

In terms of your CPSW driver, are you starting from scratch, or working from the PDK examples in <pdk>\packages\ti\drv\cpsw\examples? There is a baremetal loopback example, and we are allocating/configuring UDMA resources to service the CPSW.

I'll see if I can pull some additional pointers that will be of help to you in your development.

Best regards,

Dave

Hi Dave,

Thank you very much for your response. Yes I did take a look at the supplementary material and that too only has high-level information not sufficient for low-level driver development. I tried running several examples from the PDK but all of them failed for some reason. Below is the output of baremetal loopback test that I tried:

Select CPSW type:
0: CPSW2G
0
Select loopback type:
0: Internal (CPSW MAC port)
1: External (PHY)
0
Select MAC interface type:
0: RGMII
1: RMII
0
Enabling clocks for CPSW_2G!
=================================
Cpsw Loopback app: Iteration 0
=================================
CPSW_2G Test on MCU NAVSS
initQs() txFreePktInfoQ initialized with 128 pkts
CpswAppUtils_allocRxFlow() failed : -8
Assertion @ Line: 1831 in cpsw_apputils.c: status == CPSW_SOK : failed !!!

For your second question, yes. I am writing a driver from scratch that does not use the PDK. I have heavily used u-boot to debug and find out how the UDMA works with the CPSW. I have replicated exactly the same steps in my setup but for some reason, it is not working for me.

I have noticed another point that may be helpful for you in determining the problem. When I start the transfer by pushing a host descriptor to the Tx ring and by writing to the doorbell register, the hardware index of the Tx ring moves to 1 showing that it detected something. But the descriptor I submitted in the Tx ring doesn't come back in the transmit complete ring even though I have setup a transmit complete ring. I have used the TISCI firmware to setup Tx channel, Tx ring, Tx complete ring etc. Below are my UDMASS_UDMAP0_CFG_TCHAN Registers (I am using channel 0 for transmit):

UDMA_TCFG_0 = 0x00020014
UDMA_TCREDIT_0 = 0x00000000
UDMA_TCQ_0 = 0x00000060
UDMA_TOES_0 = 0x0000FFFF
UDMA_TEOES_0 = 0x0000FFFF
UDMA_TPRI_CTRL_0 = 0x00000000
UDMA_THREAD_0 = 0x0000F000
UDMA_TFIFO_DEPTH_0 = 0x00000400
UDMA_TST_SCHED_0 = 0x00000000

I would appreciate if you can provide additional information. And also, if you need any additional memory dumps, I can provide those as well.

Thanks,
Muhammad Umair Khan

Muhammad,

Is it possible for you to share any code reflecting your implementation so far and showing the issue?

Best regards,

Dave

Hi Dave,

Please find the attached zip. I can't share complete code due to proprietary reasons but I have added all the relevant snippets there. The zip also contains a few pictures showing the input parameter structures for the TISCI functions and I have added references to the pictures in the code where needed/applicable2671.archive.zip.

Thanks,
Umair Khan

Umair

As i understand you have tried to replicate the DMA programming model for CPSW as we have in u-boot, is my understanding correct.

I would suggest the following as next steps

1. Confirm that the call for allocating ring, UDMA channels and steps to configure them all pass without errors
2. Please check if on your system the virtual address space vs physical address space is mapped one to one or is there a translation required between the two
3. All addresses seen by the DMA should be physical addresses - you will need to convert from virtual to physical when submitting to DMA and convert back when later CPU wants to access the descriptor
4. Also, check if the transactions are configured to pass through an IOMMU - we have PVU on AM65 and selection is based on programmed atype value for the DMA channel. Default is to use physical address and by-pass PVU, so if you have not setup atype-=1 , you should be ok
5. If the descriptor, ring memory are cached, ensure you handle updates with right cache maintenance operations

Can you also confirm if the link status is up and also review dump of CPSW stats registers

Hello Umair,

Let me know if you have further queries. We can have WebEx if needed.

Hi Prasad,

Thanks for the response. We are booting our system from SD-card prepared through the TI SDK. The boot process is stopped at u-boot autoboot delay prompt and then our proprietary code is loaded through JTAG. We have observed that when the card is prepared from TI processor SDK 06.03.00.106, our Ethernet driver works fine. However, it doesn't work when we prepare SD card from the SDK 07_00_01_06, even though, the u-boot's driver works fine. Can you help us better understand what are the possible differences between these two SDK releases that can affect Ethernet functionality?

Thanks,
Umair Khan

Hello Umair,

I understand this query is different from original UDMA query. Can you please start new thread for this? 

Starting new thread will help us assign it to domain (uboot/Linux) expert so he can help. 

Hi Prasad,

This query is, indeed, the continuation of the same problem. We continued the investigation on our part when you guys couldn't take it up and this u-boot related finding is a result of that effort. If you still think this is outside the scope of the current ticket, I can create a new one.

Thanks,
Umair Khan

Hello Umair,

Understand. 

Can you please share terminal logs for failing and working case? It would help compare and find if any incorrect configuration.

Please note that the system firmware is re-architecture changes are done in SDK7.1 requiring different boot flow.

u-boot from SDK 06.03.00.106 (working case):

Hi Umair,

I do see one additional interface in non-working case. Though it might be causing issues.

Net: eth2: pruss0_eth, eth0: cpsw_nuss@046000000, eth1: pruss2_eth

Net: eth3: pruss1_eth, eth2: pruss0_eth, eth0: cpsw_nuss@046000000, eth1: pruss2_eth

I will continue having deeper look.

Hi Prasad,

Just to mention that we are only concerned about the cpsw_nuss@046000000 Ethernet interface. We are not using any other interface.

Thnks,

Umair Khan

Hi Umair,

I believe CPSW Ethernet interface still works at U-Boot prompt with SDK 07_00_01_06 release with U-Boot driver. Could you confirm the same?

For issues with your custom UDMA + CPSW driver, could you compare the follow registers with that of U-Boot configuration:
UDMASS_UDMAP0_CFG_TCHAN (for the selected TX CHAN)
UDMASS_UDMAP0_CFG_TCHANRT (for the selected TX CHAN)
NAVSS0_UDMASS_RINGACC0_CFG (for the chosen TX ring and TX completion ring)
NAVSS0_UDMASS_RINGACC0_CFG_RT (for the chosen TX ring and TX completion ring)

Have you also compared CPSW register settings with that of U-Boot?

If that does not provide a clue. Please provide full dumps of following region regions, before and after queuing UDMA TX register.
I suggest you use debugger to dump these register.

UDMASS_UDMAP0_CFG_TCHAN (for the selected TX CHAN)
UDMASS_UDMAP0_CFG_TCHANRT (for the selected TX CHAN)
NAVSS0_UDMASS_RINGACC0_CFG (for the chosen TX ring and TX completion ring)
NAVSS0_UDMASS_RINGACC0_CFG_RT (for the chosen TX ring and TX completion ring)

Please dump  the descriptor that is being queued in the TX ring.

From CPSW point of view, could enable statistics in CPSW_STAT_PORT_EN_REG and dump MCU_CPSW0_STATSx register?

Regards
Vignesh

Thank you Vignesh for your response. The information, indeed, is helpful. I'll get back to you as soon as I have the register dumps. BTW did you get time to see the code snippets I attached to this thread earlier? That may help find if there are any obvious issues in the code by eyeballing them. Moreover, the source code package I attached already had pictures of the descriptors IIRC.

Thanks,
Umair Khan

I looked at the pictures attached and I could not find desc dump.  TISCI msgs look correct but, I would like to see the actual configurations of UDMA registers rather than TISCI msg.

Also RT Registers would indicate actual progress of the transfer which is very helpful for debugging.

Regards
Vignesh 

Hi Vignesh,

Here is the zip archive containing the register dumps.

Thanks,
Umair Khan

regdumps for TI.zip

Hi Umair Khan,

Sorry for the delay.. 

I am assuming "regdump_after_chan_config.pdf" is after your custom driver configured DMA and sent a packet out of CPS.

Looking at the dumps in that file:
0x2aa02400 -> 0x00000001
0x2aa02408 -> 0x00000166
0x2aa02410 0x00000166

which means 1 Packet of 166 bytes was sent successfully...
Also from Ring RT dumps NAVSS0_UDMASS_RINGACC0_CFG_RT(TX Comp. Ring | #96):

0x2b86001c -> 0x00000001
0x2b860020 -> 0x00000000
0x2b860024 -> 0x00000001

There is one desc returned to the Completion queuing indicating one packet was sent successfully to CPSW. Looks like UDMA configs are alright...

From STATS0 (in "regdump_after_chan_config.pdf"). Again I am assuming you had somehow cleared STATS registers before you attempt sending out packet using custom driver (regdump_before_chan_config.pdf has non zero values):

0x4603a000 -> 0x00000001 -> RX GOOD FRAMES has 1 which means CPSW received one packet via UDMA-PSIL path.

STATS1
0x4603a234 -> 0x00000001 -> TX GOOD FRAMES of 1 indicates one packet was sent out...
0x4603a238 -> 0x00000001  

So, Ideally you should be seeing one packet on the wire... Could you verify same with packet sniffers like wireshark?

If there is still no packet on the wire originating from EVM, then I would check pinmux of RGMII lines and also PHY configuration...

One other way to confirm CPSW functionality is to set CPSW port in internal loopback (along with ALE BYPASS and GMII mode)  using CPSW_PN_MAC_CONTROL_REG  LOOPBACK field.
With this packet sent out on external port will loopback and received back on RX path of port1. SW should see the packet back if RX DMA channel is configured appropriately... Alternately if CPSW STATS1 stats are reset before experiment you should see both TX GOOD FRAMES and RX GOOD FRAMES increment by the number of packets sent (and received back via loopback path)

Regards
Vignesh

Hi

From you descriptor dump you seems incorrectly filling word 2 pkt_info2.[15:0] Packet Return Queue/Ring Num.

pkt_info2 = 0x38000000, try 0x38000060 (96 TX_CQ)

Hi Vignesh:

Thanks for your support. Yes, I did use Wireshark but nothing comes out on the wire and this is the main pain-point for us, that despite all register dumps indicating correct operation, no frame appears on the wire. But now, I think with your assistance, we have narrowed it down to the pin mux and PHY settings. I'll try getting them double-checked and will get back to you. For your later comment about the pkt_info2, I am extremely sorry, that was a typo. The driver is indeed setting the correct value which is 0x38000060.

Thanks again for your support,
Umair Khan

So, DMA is actually working and you're receiving completion, right?

You seems also missing CPSW_PN_MAC_CONTROL_REG configuration (from your code).

Hi Vignesh,

For the very first frame, we don't get interrupt even though the descriptor is successfully returned back in the completion ring. However, for subsequent transfers, the interrupt gets fired too. But for both of these cases, nothing appears on the physical layer.

For the CPSW_PN_MAC_CONTROL_REG, I think I forgot to share that part. that is indeed being configured as follows:

/* Read the MAC control register. */
reg32 = MEM_READ32(CTRL_PN_MAC_CONTROL_REG);

/* Clear Gigabit mode, duplexity and speed selection bits. */
reg32 &= ~(CTRL_PORT_MAC_CONTROL_FULLDUPLEX | CTRL_PORT_MAC_CONTROL_GIG |
CTRL_PORT_MAC_CONTROL_IFCTL_A | CTRL_PORT_MAC_CONTROL_IFCTL_B |
CTRL_PORT_MAC_CONTROL_CTL_EN);

/* Check if PHY negotiated at 1000Mbps */
if (speed == SPEED_1000_MBPS)
{
    reg32 |= CTRL_PORT_MAC_CONTROL_GIG;
}

/* Check if PHY negotiated at 100Mbps */
else if (speed == SPEED_100_MBPS)
{
    reg32 |= CTRL_PORT_MAC_CONTROL_IFCTL_A | CTRL_PORT_MAC_CONTROL_IFCTL_B;
}

else if (speed == SPEED_10_MBPS)
{
    /* Enable In-band mode */
    reg32 |= CTRL_PORT_MAC_CONTROL_CTL_EN;
}

/* Check for full-duplex mode. */
if (duplex == FULL_DUPLEX)
{
    reg32 |= CTRL_PORT_MAC_CONTROL_FULLDUPLEX;
}

reg32 |= CTRL_PORT_MAC_CONTROL_GMII_EN;

/* Program the updated parameters. */
MEM_WRITE32(CTRL_PN_MAC_CONTROL_REG, reg32);

Thanks,
Umair Khan

hi

The code looks more less good, but things are really depends on context. So

1) Have you tried loopback PN_MAC_CONTROL = FULLDUPLEX | LOOPBACK | GMII_EN | GIG

and can send packet, get TX completion, receive back the same packet through loopback? Be sure to reset MAC before programming PN_MAC_CONTROL.

2) Could you provide CPSW registers dump exactly before sending packet (push TX desc) including

- CPSW_CONTROL_REG, CPSW_P0_CONTROL_REG, CPSW_PN_CONTROL_REG, CPSW_P0_FLOW_ID_OFFSET_REG, CPSW_Pn_RX_MAXLEN_REG

- CPSW_P0_FLOW_ID_OFFSET_REG (!! what RX flow ID is allocated for you by TI SCI FW? !!)

- CPSW_PN_MAC_CONTROL_REG, CPSW_PN_MAC_STATUS_REG

- full ALE registers dump

- CPSW_SS_RGMII_STATUS_REG

Option. You can try to disable networking in u-boot to avoid interference with your SW.

- grygorii

Hi Grygorii,

Thanks for the response. I'll get back to you once I have all these details.

Thanks,
Umair Khan

Hi Umair,

Anything open in this thread? Else we can close the thread.

Regards,

Prasad

Hi Prasad,

I was just about to write to you. We have been able to resolve the reported issue. The exact cause is still unknown but it seems like the a problem with the local network. For some reason, the Ethernet worked with the older u-boot while it didn't with the latest one. I am investigating the issue and if I find something worth sharing, I'll start a new thread. You can close this thread. Thank you for your support. Much appreciated.

Thanks,
Umair Khan