TDA4VM: Cannot transfer data via UDMA to PCIe memory space

Hi Marina,

Is PCIe space mapped and powered on by Linux? The crash might be coming because it is not powered on. Are you running just this udma memory copy example? If then, can you please first boot Linux and then try it?

Regards,

Brijesh

Hi Brijesh,

We are not using Linux, we are implementing everything baremetal. And I am testing with our full software on the board.

The access to the PCIe memory space works with an external DMA, but it is not working with UDMA-P.

Regards,

Marina

Hi Marina,

I did not get it. can you please elaborate on how you are able to access PCIe memory using external DMA? What is external DMA?

What is running on A72? Are you using released uboot from SDK? 

Regards,

Brijesh

Hi Brijesh,

We currently use PCIe to communicate with a FPGA, and we use the FPGA DMA. A description of our use case is this thread: TDA4VM: Unable to access PCIe Endpoint - Processors forum - Processors - TI E2E support forums

What we want to implement is using UDMA to copy the data from the PCIe Buffer to MCU R5 OCRAM, and currently we cannot access this PCIe buffer with the UDMA to either read or write operations (Similar threads: TDA4VM: How can we use DMA to transfer data from NVM e.g. SSD(PCIe) to DDR in tda4vh or tda4vm? - Processors forum - Processors - TI E2E support forums and TMS320C6657: PCIe Memory read/write process - Processors forum - Processors - TI E2E support forums). I am using the memcpy example in PDK (baremetal) with minimum alterations, are there any more implementations that are needed from either side of the PCIe controller or the UDMA driver?

Regards,

Marina

Hi Marina,

Can you please confirm that you have referred the above application note for PCIe address translation? Also i am wondering how PCIe module is enabled with just UDMA memory copy example. Without enabling it and probably even configuring it, we may not be able to access this region.

Regards,

Brijesh

Hi Brijesh,

as I wrote before I am testing with our full application in the board and this includes a PCIe driver wich is being initialized and configured(including the address translation) before the UDMA memcopy.

I am using the functions in the UDMA memcopy example to try to read/write to the PCIe memory space, and it is leading to an exception that is not possible to access this memory space.

When I do a memory copy without DMA it works: lPCIeMemSpace_p = lData_ip;

But when I try to do using UDMA it doesn't: App_udmaMemcpy(chHandle,lPCIeMemSpace_p,lData_ip,length);

The UDMA is being configured before, and a memcopy from MCU OCRAM to MCU OCRAM works, but not to/from the PCIe.

Is this an issue on UDMA or PCIe side?

Regards,

Marina

Hi Marina,

ok, i understood the issue now. Let me check with the team if/how UDMA can read from PCIe address space. 

Regards,

Brijesh

Hi Marina,

Which PCIe address are you using? Are you using below addresses in UDMA for accessing PCIe data space?

Regards,

Brijesh

Hi Brijesh,

I am using PCIEx_DAT0 and currently read/write to PCIE3.

Since we are using MCU R5F, we use the RAT module to map the 48 bit address range to 32 bit address range and reallocate from PCIE2/3 to the lower half of PCIE0/1. So the PCIE Region addresses are the following:

Regards,

Marina

Hi Marina,

But which RAT are you using? If you are using R5F RAT, then UDMA will not go via this RAT, so for UDMA, i would suggest using address starting from 0x4xxxxxxxxxx.

Regards,

Brijesh 

Hi Brijesh,

I am using the csl_rat from the PDK (implementaion based on: TDA4VM: TDA4VM - How to config RAT on R5F core - Processors forum - Processors - TI E2E support forums). If I use the 48 bit address starting at 0x4xxxxxxxxx the R5F processor truncates the address to 32 bit (0x4410000000 -> 0x10000000) even when I use the UDMA, leading to the same memory access exception.

Regards,

Marina

Hi Marina,

This seems to be local RAT of R5F. This mapped address should only be used when doing memcpy on R5F. But when you are using UDMA for copy, DMA descriptor should be configured with 0x4xxxxxxx location. This is because UDMA can't go via RAT of R5F. 

Regards,

Brijesh

Hi Brijesh,

I am configuring the DMA descriptor with the 48 bit address and there is no more data exception, but the transfer is not being completed: trRespStatus returns CSL_UDMAP_TR_RESPONSE_STATUS_TRANSFER_ERR (1U).

Regards,

Marina

Hi Marina,

ok atleast, there is no crash now. Can you please share the complete TR response value to better understand the error?

Regards,

Brijesh  

Hi Brijesh,

The complete TR response (pTrResp) was 0x00250091

Regards,

Marina

Hi Marina,

For the DATA0 memory space, i think the first 128MB memory space in the system memory map. I see below entry in the Main domain memory map. It mean the addresses 0x0010000000 and 0x0018000000 can directly be used even R5F and on DMA engine. Can you please check if you are able to use these memory location directly in DMA engine, atleast for 128MB memory? 

If possible, can you please also share your test example? We want to recreate this issue on EVM and see what's missing, in case above also does not work.

Regards,

Brijesh

Hi Brijesh,

I will test with the PCIE0_DAT0 and PCIE1_DAT0 and let you know.

But on our hardware the PCIe 3 is connected to the FPGA, which we are trying to communicate with. So we would need to access the PCIE3_DAT0 (0x4410000000 to 0x441FFFFFFF). Would be possible to also access this memory? Is there an alternative to RAT?

Regards,

Marina

Hi Marina,

No, for R5F access, we need to configure RAT. This address is beyond 32bit address, so we need to use RAT and access this memory in 32bit memory location using RAT. 

In the UDMA, are you using 0x441xxxxxxx location?  

Regards,

Brijesh

Hi Brijesh,

Yes, I am using the 0x441xxxxxxx location for UDMA

Regards,

Marina

Hi Marina,

Atleast, it seems to be working in the Linux. Linux also uses TR for copying to/from PCIe data location. I am not sure about PCIe3, but PCIe0 and PCIe1 seem working fine. So can you please check PCIe0 or PCIe1 ?

Regards,

Brijesh