public inbox for
 help / color / mirror / Atom feed
Subject: [Bug 1001837] Rich FlexBus RAM layout
Date: Fri, 03 May 2013 16:51:00 -0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

--- Comment #7 from Mike Jones <> ---
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


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

  parent reply	other threads:[~2013-05-03 16:51 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
2013-05-03 16:51 ` bugzilla-daemon [this message]
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:

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

  git send-email \ \ \ \

* 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).