[Bug 1001837] Rich FlexBus RAM layout

[bugzilla-daemon@bugs.ecos.sourceware.org]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001837

--- Comment #7 from Mike Jones <mjones@linear.com> ---
I assume from Ilija's comments that DMA bypasses the cache, hence the need to
invalidate it.

When I disable CYGSEM_HAL_ENABLE_DCACHE_ON_STARTUP, I get a conflict saying
startup mode must be WRITETHRU, which it is , but is also disabled (conflict
comes from CYGPKG_HAL_FREESCALE_EDMA). Perhaps this is a bug. My purpose in
disabling it to make it consistent with the 100Mhz device's behavior, and make
sure there is no side effect from enabling a feature the device does not
support. The conflict did not prevent my app from running.

I assume the TCD limitation is because the eDMA logic in the device is
connected tightly with the memory bus logic and can't route through the cache,
similar to how DMA works directly on memory without the cache.

I put breakpoints in the SPI dma setup to see where the buffers reside in
memory and they reside in Cache Data RAM just above 0x60400000. I will attach a
couple of screen shots with the location. I assume some code will need to be
added to invalidate the cache if the code is not already present somewhere,
move to another segment without cache, or require turning off caching. Perhaps
someone knows if there is cache invalidation code already. For now, I am ok
because there is no caching for my 100Mhz device.

I believe that whatever is overwriting the device variable is not related to
FXM based on what I learned here. There is also evidence that the stack is
corrupt in other places because the debugger is not giving a complete stack
trace. So I will take the discussion back to the MCC/SPI bug if I discover
more.

Thanks

-- 
You are receiving this mail because:
You are on the CC list for the bug.