public inbox for ecos-patches@sourceware.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugs.ecos.sourceware.org
To: ecos-patches@ecos.sourceware.org
Subject: [Bug 1001837] Rich FlexBus RAM layout
Date: Fri, 03 May 2013 09:05:00 -0000	[thread overview]
Message-ID: <bug-1001837-104-gkrSOL7ckf@http.bugs.ecos.sourceware.org/> (raw)
In-Reply-To: <bug-1001837-104@http.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 #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 on the CC list for the bug.

  parent reply	other threads:[~2013-05-03  9:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-30 13:22 [Bug 1001837] New: " bugzilla-daemon
2013-04-30 13:24 ` [Bug 1001837] " bugzilla-daemon
2013-04-30 13:25 ` bugzilla-daemon
2013-05-02  8:44 ` bugzilla-daemon
2013-05-02  8:45 ` bugzilla-daemon
2013-05-03  5:40 ` bugzilla-daemon
2013-05-03  9:05 ` bugzilla-daemon [this message]
2013-05-03 16:51 ` bugzilla-daemon
2013-05-03 16:52 ` bugzilla-daemon
2013-05-03 16:52 ` bugzilla-daemon
2013-05-03 16:53 ` bugzilla-daemon
2013-05-03 17:10 ` bugzilla-daemon
2013-05-03 17:24 ` bugzilla-daemon
2013-05-03 17:48 ` bugzilla-daemon
2013-05-03 18:00 ` bugzilla-daemon
2013-05-03 18:01 ` bugzilla-daemon
2013-05-03 18:06 ` bugzilla-daemon
2013-05-04 16:20 ` bugzilla-daemon
2013-05-05 16:16 ` bugzilla-daemon
2013-05-18 19:14 ` bugzilla-daemon
2013-06-01 22:46 ` bugzilla-daemon
2013-06-01 22:50 ` bugzilla-daemon
2013-06-01 22:54 ` bugzilla-daemon
2013-06-02 17:12 ` bugzilla-daemon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-1001837-104-gkrSOL7ckf@http.bugs.ecos.sourceware.org/ \
    --to=bugzilla-daemon@bugs.ecos.sourceware.org \
    --cc=ecos-patches@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).