DMA2 and SYSCFG_MEMRMP relationship

[bmh]

Posted on September 17, 2016 at 23:25

Hello,

I have a STM32F469-DISCO board with an WL1835mod SDIO on it. I'm running linux on the board with all kernel, drives and fs. It was running properly with and without DMA enabled. So I decide to remap my external SDRAM Bank 1 memory to 0x00000000 cause the RM says: 

In remap mode at address 0x0000 0000, the CPU can access the external memory via 

ICode bus instead of System bus which boosts up the performance.

So I did it by writing 0x4 on the 

SYSCFG_MEMRMP and also changed my linux and bootloader to run from 0x00000000. It happens that the the system runs properly and I can still use my WL1835 mod without DMA. But when DMA is enabled I start to get a DMA error(TEIF

) in the first write from memory to device. My only conclusion it is caused by a BUS ERROR.

But I could not find anywhere that this configuration is not valid. Here is the dump of my registers from DMA controller:[  907.650000] dma dma1chan3: DMA_xISR:  0x00000000[  907.650000] dma dma1chan3: SCR[0x40026458]:   0x08a15474[  907.650000] dma dma1chan3: NDTR[0x4002645c]:  0x00001000[  907.650000] dma dma1chan3: SPAR[0x40026460]:  0x40012c80[  907.650000] dma dma1chan3: SM0AR[0x40026464]: 0x0076c000[  907.650000] dma dma1chan3: SM1AR[0x40026468]: 0x0076c000[  907.650000] dma dma1chan3: SFCR[0x4002646c]:  0x00000027[  907.650000] dma dma1chan3: SCR[0x40026458]:   0x08a15474[  907.650000] dma dma1chan3: NDTR[0x4002645c]:  0x0000ffff[  907.650000] dma dma1chan3: SPAR[0x40026460]:  0x40012c80[  907.650000] dma dma1chan3: SM0AR[0x40026464]: 0x0076c000[  907.650000] dma dma1chan3: SM1AR[0x40026468]: 0x0076c000[  907.650000] dma dma1chan3: SFCR[0x4002646c]:  0x00000027[  907.650000] mmci-pl18x 40012c00.sdio: irq0 (data+cmd) 00000000[  907.660000] dma dma1chan3: DMA_xISR:  0x02000000[  907.660000] dma dma1chan3: SCR[0x40026458]:   0x08a15474[  907.660000] dma dma1chan3: NDTR[0x4002645c]:  0x0000ffff[  907.660000] dma dma1chan3: SPAR[0x40026460]:  0x40012c80[  907.660000] dma dma1chan3: SM0AR[0x40026464]: 0x0076c000[  907.660000] dma dma1chan3: SM1AR[0x40026468]: 0x0076c000[  907.660000] dma dma1chan3: SFCR[0x4002646c]:  0x00000027 #sdio-dma-sysconfig

[Tesla DeLorean]

Posted on September 18, 2016 at 02:06

Can you write to this zero based memory region via the processor?

Can you recognize a DMA setup to this zero region and add back the real SDRAM address (it just shadows at zero as well as normal address)? I wouldn't imagine the ICode bus being writable.

[bmh]

Posted on September 18, 2016 at 05:22

I can read/write thru the processor. At first I was suspicious that was a SDRAM configuration/timming issue so I boot the kernel with memtest flag and it ran properly. In fact the system itself runs from the SDRAM, so rw is not a issue. 

Regarding the shadowing I would be just adding 0xC0000000 to it. I'll test, but my concern it can lead to other problems between bus sharing/conflict/concurrency.My guessing this is a limitation at STM32, but no documentation in this regard.

[Tesla DeLorean]

Posted on September 18, 2016 at 14:54

There is no caching of the SDRAM, so the coherency isn't going to span beyond the prefetch.

I'd worry more about the inherent slowness of the SDRAM, and keep temporal data within the Internal SRAM

[bmh]

Posted on September 21, 2016 at 04:23

Hi Clive, Thanks for the hint. Adding up the 0xC0000000 did solve the problem. I also got some help from Maxime Coquelin who was the STM32 maintainer at the Kernel. 

Wrapping up: the problem was the MCU was seeing the memory at address 0x0000.0000 (remapped address) while the DMA controller was seeing the memory at 0xC000.0000 (real physical address).  Linux kernel has a special property to handle this that is the dma-ranges.Thanks, this thread can be closed.