2011-03-09 04:28:17     Simultaneous use of NFC and MDMA1 on EBIU

Document created by Aaronwu Employee on Aug 27, 2013
Version 1Show Document
  • View in full screen mode

2011-03-09 04:28:17     Simultaneous use of NFC and MDMA1 on EBIU

Jerome BRUNEAUX (FRANCE)

Message: 98762   

 

Hi,

 

Is it possible to use the Nand Flash Controller (through the bf5xx_nand.c driver) and to use the MDMA1 to output datas on EBIU port on the same project (we are using a nand flash and a lcd screen, both wired to the EBIU port).

 

Regards, Jerome

QuoteReplyEditDelete

 

 

2011-03-09 14:55:02     Re: Simultaneous use of NFC and MDMA1 on EBIU

Mike Frysinger (UNITED STATES)

Message: 98787   

 

the MDMA channels are not bound to any peripheral.  they are always available.

 

the BF54x HRM (especially chapter 5) talks about the sharing of data pins between the EBIU, NAND, and ATAPI controllers.  there is an APCM module which arbitrates contention between them on the fly.

 

there is however an anomaly related to contention on the bus between the EBIU and NAND which you might hit.  so it'd be best if you hooked the LCD up to a peripheral designed for driving things like that such as one of the PPIs.

QuoteReplyEditDelete

 

 

2011-03-10 04:16:01     Re: Simultaneous use of NFC and MDMA1 on EBIU

Jerome BRUNEAUX (FRANCE)

Message: 98843   

 

Hi,

 

 

 

Our board is already designed with the LCD and the NAND wired on the EBIU port. However, I'm facing a problem using the Nand driver and the MDMA1 driver.

 

The LCD driver periodically (every 100ms at the moment) use MDMA1 to transfer the datas to the LCD. It's really basic, enable the MDMA source and destination, and on IRQ, disable the DMAs channel.

 

The Nand driver used is the bf5xx_nand driver.

 

The problem I have is that if I try to use the nand driver when the LCD driver works, then I got some issues :

 

1/ When using the 'flash_eraseall' tool, I've got periodically " MTD Erase failure: Input/output error"

 

2/ When I use the 'nandwrite' tool, I've got some lock up and after 61s, kernel crashes.

 

 

 

I've made some more tests and I think the 1st problem is caused by the Nand driver not using the DMA when writing to the spare area of the NAND (if the transfer size is bellow 256 bytes, then the driver use the NFC directly, not through the NFC DMA channel). I think there's a conflict between the use of the EBIU port through NFC and the use of EBIU port at the same time through the MDMA DMA. The arbitrer should grant access to either the MDMA (higher priority by default) or the NFC.

 

The second problem is more complex. I've made some traces and found that the lock up happens because the processor generates continuous interrupts on IVG8, which is redirected to the Nand driver ( 'bf5xx_nand_dma_irq' ), even after that the NFC DMA tranfer has ended (it comes a first time in 'bf5xx_nand_dma_irq, which clears the irq_stat of the NFC DMA then disable it). The interesting thing it that it locks up when the screen driver (thus, the MDMA1) is enabled (at least triggered by enable_dma() ), in the same time that a NFC DMA is running.

 

 

 

Here is a small 'trace' that may be more clear than my explaintations. The trace has been made with a screen driver refreshing every 30ms, and a small script that writes a small file into nand (size of the file is a few bytes long, so that it involve only on page write call) continuously.

 

In the trace : 'f' are the screen driver 'enable_dma()' calls, '/' are the screen MDMA1 transfer irq, 'm' are the DMA NFC write transfer 'enable_dma()' calls, 'n' are the non DMA nand writes, '\' are the NFC DMA transfer irq, '+' are when the driver is in the "while ((bfin_read_NFC_IRQSTAT() & WR_DONE) != WR_DONE)" loop after NFC DMA transfer has completed (in the 'bf5xx_nand_dma_rw' routine) )  :

 

 

 

[boot time]

 

f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/f/ (only screen 'enable_dma' & interrupts occurs)

 

[after the nand write script has started]

 

f/f/f/m\m\nm\m\nm\m\nm\m\nf/m\m\nm\m\nm\m\nm\m\nm\m\nm\m\nf/m\m\nm\m\nm\m\nm\m\nm\mf\++\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

 

[(tons of '\' then kernel crash because of 61s lock up)]

 

 

 

During the NFC DMA irq that locks up, the irq_stat of the NFC DMA returns 0, but the MDM1 DMA irq_stat return 0x8 (DMA_RUN).

 

 

 

Please, let me know if you need me to write a simple driver to reproduce the problem (I also have a couple of kernel traces that show that the NFC DMA irqs at the end are triggered by the _EVT_EVT8 entry, which is the IVG8 irq vector).

 

 

 

Regards, Jerome

QuoteReplyEditDelete

 

 

2011-03-10 23:53:19     Re: Simultaneous use of NFC and MDMA1 on EBIU

Sonic Zhang (CHINA)

Message: 98869   

 

Which blackfin chip do you use in your desing? Why not connect LCD to the PPI port?

QuoteReplyEditDelete

 

 

2011-03-11 03:55:33     Re: Simultaneous use of NFC and MDMA1 on EBIU

Jerome BRUNEAUX (FRANCE)

Message: 98890   

 

Chip used is BF548. I don't know exactly why LCD is not connected to EPPI but since I'm working on that project, it's connected on the EBIU. Anyway, design is already made and some boards have already been produced. Up to now, we did a dirty workaround by copying the whole flash content to the RAM then disable nand to use the screen, but it waste a lot of RAM and we can't cope with it.

 

From the reading of the BF54x datasheet, there shouldn't be any problem using the NAND flash controller and the MDMA1 to output datas on the EBIU port, as the DMA controllers / arbitrers should grant acces to either the NFC or the MDMA, and the ASYNC PIN controller should control the pins access.

 

The problem seems more related to the Interrupts than to the DMA access.

 

Did you tried to reproduce the bug ? Do you have any clue about it (hardware bug in the arbitrers, software bug in the interrupt controller, ...) ? Do you need the screen driver sources so that you can easily reproduce the problem ?

QuoteReplyEditDelete

 

 

2011-03-11 06:03:37     Re: Simultaneous use of NFC and MDMA1 on EBIU

Sonic Zhang (CHINA)

Message: 98892   

 

I remember there is a anomaly in bf548 NAND flash controller. See this thread   ez.analog.com/message/11319

QuoteReplyEditDelete

 

 

2011-03-14 04:53:12     Re: Simultaneous use of NFC and MDMA1 on EBIU

Jerome BRUNEAUX (FRANCE)

Message: 98916   

 

Thansk for the link. So this problem is known but I didn't saw any solution (except to put some spinlocks in the drivers, but this solution is quite dirty). Why does this issue isn't listed in the anomaly list (it seems related to hardware, not to software, ain't it ?).

 

 

 

Anyway, I'm going to make a change in the drivers to make a workaround but if it was clearly mentionned either in datasheet or in the anomaly list, then, it could save developpers tons of time (trying to track down such bug takes lot of time, especially when you have to go up to the assembly code of the IRQs...)

 

 

 

Regards, Jerome

QuoteReplyEditDelete

 

 

2011-03-14 06:59:05     Re: Simultaneous use of NFC and MDMA1 on EBIU

Sonic Zhang (CHINA)

Message: 98920   

 

This issue was tracked as anomaly 05000500 in ADI internal tracking system since Jan. 27, 2011. It is just not published in open anomaly list. You may contact your local ADI FAE for a latest list.

QuoteReplyEditDelete

 

 

2011-03-14 09:32:39     Re: Simultaneous use of NFC and MDMA1 on EBIU

Jerome BRUNEAUX (FRANCE)

Message: 98921   

 

Thanks again. Do you know if there will be any workaround for this anomaly in the next uclinux-dist releases ?

 

Jerome

QuoteReplyEditDelete

 

 

2011-06-18 17:26:19     Re: Simultaneous use of NFC and MDMA1 on EBIU

Mike Frysinger (UNITED STATES)

Message: 101434   

 

as soon as design gives us information on how to workaround it, we'll implement it.  atm, they have no workaround other than "dont use the two devices at the same time" which isnt feasible under Linux.

QuoteReplyEditDelete

Attachments

    Outcomes