[Bug 1001837] Rich FlexBus RAM layout

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

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

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

--- Comment #6 from Ilija Kocho <ilijak@siva.com.mk> ---
Hi Mike

(In reply to comment #5)

The current CVS version of FlexBus memory is not partitioned so it is all
either cached or non cached. Here I apply partitioning scheme that was
developed for DDRAM (Bug 1001606). This support is generic, it works on all
Kinetis devices with FlexBus but caching schemes effectively apply only on
devices with on-chip cache. At present only K70 and 120/150MHz K60 lines have
cache.

> I am trying to understand the memory layout. It appears that:
> 
> 0x60C00000 Non-Cached Data RAM 4MB
> 0x60400000 Cached Data RAM 8MB
> 0x60000000 Code RAM 4MB
> 
> Stacks seem to be in the middle one, because a variable on the stack is at
> 0x604008D8.

All data, for Platform startup types that employ FXM normally resides in the
middle partition: stack, static, global, heap.
Code for RAM startup resides in "Code RAM".

> This is the variable getting corrupted as discussed in #101764,
> the MMC/SPI patch.
> 

I assume you are still with 100MHz K60 which hasn't cache.


> From CDL comments, it appears you can't DMA to cached data.

Not necessarily. You can DMA but then you must sync/invalidate cache lines on
every transaction. Non-cached memory is a convenience when you have freedom
where to store the buffers. 

> If the SPI
> driver uses DMA, I believe it will DMA to arrays on the stack in the cached
> area.

With current drivers employing eDMA (that'd DSPI) the Transfer Control
Descriptors (TCD) must not be in cached memory. For performance reasons best
place is internal SRAM. On TWR-K60N512-FXM with the old scheme they reside in
FXM because CYGHWR_HAL_NONCACHED is not active unless system has cache memory
(which is fixed with this bug). However, assuming that you have 100MHz K60 this
will not break your code and will only affect SPI/MMC performance. Besides
TCDs, the DSPI driver has internal transmit buffer which also must not be
cached. There are no other limitations regarding caching.

> 
> Do you think this could be the source of my SPI problems that only occur on
> FXM? That DMA to the stack area is messing up the stack leading to the bad
> address pointers.

Having in mind previous consideration the cache should be excluded as
non-existent. But if you are using stack (AKA automatic variables) for buffers
it very likely may be the problem.

> 
> Is there a way to disable this cache? 
> There is a value CYGSEM_HAL_ENABLE_DCACHE_ON_STARTUP, but I am guessing that
> is not for the 8MB cached data.

Yes it is, (provided that you have one). Here is the scheme:
      Partition                    |   Cache control
-----------------------------------+------------------------------------       
0x60C00000 Non-Cached Data RAM 4MB | non applicable
0x60400000 Cached Data RAM 8MB     | CYGSEM_HAL_ENABLE_DCACHE_ON_STARTUP
0x60000000 Code RAM 4MB            | CYGSEM_HAL_ENABLE_ICACHE_ON_STARTUP

-- 
You are receiving this mail because:
You are the assignee for the bug.