UPP on OMAP-L138, received data integrity problem

Hi Bruno ,

I have just started building an driver for LINUX for OMPA L138.

Since in UPP the RECEIVE part is under the control of slave [ considering UPP as master for Transmission , but slave for RECEIVE part]

try to check the slave device which drives the START and ENABLE signal for receive mode 

You can also try the below test :-

a)  Just send all zero from MASTER and monitor the RECEIVED data .

     This will give you the behavior for DATA transmission with external world . 

b) Now configure the UPP in LOOP back mode [ If possible with SLAVE device not in picture] 

     Now again check the received data . If the issue is due to slave device you will not see data corruption in loop back mode. 

Also , 

-> Can you let me know how have you initialized the SOURCE buffer that needs to be send to UPP. 

    1. Currently i am doing an kmalloc 

    2. Passing the PHYSICAL ADDRESS of this buffer to UPP configuration. 

        I am facing problem how to initilize this PHYSICAL address with KNOWN pattern and retrieved back data from physical address of destination buffer

Thanks ,

Ashish .K Mishra

[Banglore /India ] 

Hi Ashish,

Thanks for your response.

I have already check the slave device with a digital analyser :

• The control signals (STAT, ENABLE, WAIT) are correct
• The data sent to the device are correct
• The data send by the device are correct

a)  Just send all zero from MASTER and monitor the RECEIVED data =>

Received data are equal to 1 : the bit D0 is always 1.

b) Now configure the UPP in LOOP back mode [ If possible with SLAVE device not in picture]  =>

There is no data corruption in LOOP back mode : received data and sent data are the same. 

So I expected my program is correct.

I have measured the signal D0 with oscilloscope, and also verified PINMUX configuration.

I have no more  ideas, except a hardware problem on the OMAP. Is it Possible ?

-> Can you let me know how have you initialized the SOURCE buffer that needs to be send to UPP. 

    1. Currently i am doing an kmalloc 

I am doing also a kmalloc with GFP_DMA flag (the buffer must be aligned for DMA transfert) : buffer = kmalloc(length, GFP_DMA);

Note that the buffer must occupy contiguous pages in physical memory, so length should not exceed 128K.

For larger buffer you have to use another kernel api like dma_map_single...

    2. Passing the PHYSICAL ADDRESS of this buffer to UPP configuration. 

        I am facing problem how to initilize this PHYSICAL address with KNOWN pattern and retrieved back data from physical address of destination buffer

You just have to fill your buffer with your known pattern and write the buffer adress (return by kmalloc) in the UPID0 (or UPQD0) register : iowrite32(buffer, base_address + UPQD0);

Hope this help.

Regards.

Bruno

Hi Bruno , 

a) I have no more  ideas, except a hardware problem on the OMAP. Is it Possible ?

     No , I don't think  your OMAP is having some hardware problem ,reason's are stated below. 

b) Now configure the UPP in LOOP back mode [ If possible with SLAVE device not in picture] =>

   "..There is no data corruption inLOOP back mode : received data and sent data are the same. .."

    1. In digital LOOPBACK MODE as you know the DATA pins are internally looped back . 

        So as you said that IN LOOP BACK mode there is no data LOSS . It shows that UPP is fine

        [ I mean to say all the configuration and individual SIGNAL's of UPP including D0 Pin is fine ]

        Had the data got corrupted , we could have clearly said that the UPP hardware is faulty. 

c. Just send all zero from MASTER and monitor the RECEIVED data =>

    Received data are equal to 1 : the bit D0 is always 1.

 This case shows that DATA is getting corrupted only when it is driven from EXTERNAL WORLD.

  As for Internal LOOP Back you are not getting error. 

So i think the issue  may be due to  :-

a) Slave Device [ Generating wrong O/P data which is reflected on to UPP Bus ] 

     This gets ruled out as you said you have cross-verified the DATA coming out of slave 

b) Cabling of SLAVE device with UPP DATA pins

     [So even if SLAVE is driving proper data and internally UPP is fine , we would get wrong value ]

d. write the buffer adress (return by kmalloc) in the UPID0 (or UPQD0) register : iowrite32(buffer, base_address + UPQD0);

    This was my concern . Is it not that we should enter PHYSICAL ADDRESS  of source buffer rather VIRTUAL ADDRESS to any DMA engine . 

     I will check with giving virtual address directly and will update you. I was writing PHYSICAL address rather than VIRTUAL 

 Ashish . K. Mishra

[Banglore / INDIA]

Hi Ashish,

a) Slave Device [ Generating wrong O/P data which is reflected on to UPP Bus ]

I have verified with a digital analyser => Slave device generate right data

b) Cabling of SLAVE device with UPP DATA pins

I have verified the cabling between the slave device and the OMAP directly on the board => seems correct

I suspect PINMUX and PullUp/PullDown configuration  and still investigate on this.

This was my concern . Is it not that we should enter PHYSICAL ADDRESS  of source buffer rather VIRTUAL ADDRESS to any DMA engine . 

I will check with giving virtual address directly and will update you. I was writing PHYSICAL address rather than VIRTUAL

Tell me if it 's work now with Physical Address.

I don't need large buffer for now, but I will need certainly later, and I will have to use another allocating system.

Regards

Bruno

Hi Bruno , 

1. For KMALLOC i tried using VIRTUAL ADDRESS , and it is working fine for some very small iterations. 

    After that UPP operations occur but there is some data corruption in the received data . 

    I am working for the same , hence could not evaluate with giving PHYSICAL address 

2. Initially i tried giving PHYSICAL address , but the buffer allocation was from dma_alloc_noncoherent.

    With this i was getting GARBAGE.

Will update you shorlty for PHYSICAL address stuff.

Also please do let us know if you have resolved your issue !!!! 

Ashish .K. Mishra

[Banglore / India] 

Hi Bruno , 

Based on further evaluation of UPP on LINUX , following are the outcome :-

a. Don't use KMALLOC better you use dma_alloc_coherent. And pass the PHYSICAL ADDRESS thus obtained directly to UPP Configuration

     The data corruption issue was resolved .

b. Presently i my slave is XILINX SPARTAN FPGA , the BRAM i have for now is 1 KB. 

   So i am doing WRITE / READ on the same BRAM continuously .

   Now the system is already completed 1Hour of continuous test without data corruption . 

c. Once the 1k is cleared , our FPGA team will chnage the BRAM size to much deeper

    [ We are targeting somewhere 40-45K BRAM depth with UPP at higher frequency and WAIT ENABLED]

Did you figure out what was the reason for DO bit always high ?

Ashish K Mishra

[Banglore / India ]