From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14667 invoked by alias); 3 May 2013 09:05:13 -0000 Mailing-List: contact ecos-patches-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-patches-owner@ecos.sourceware.org Received: (qmail 14613 invoked by uid 89); 3 May 2013 09:05:12 -0000 X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 03 May 2013 09:05:11 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id CE93C4680006 for ; Fri, 3 May 2013 10:05:08 +0100 (BST) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOL1bwNOltrf; Fri, 3 May 2013 10:05:03 +0100 (BST) 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: Patches and contributions X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: ilijak@siva.com.mk X-Bugzilla-Status: NEW X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-05/txt/msg00004.txt.bz2 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 --- 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.