From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2987 invoked by alias); 4 Sep 2012 21:19:39 -0000 Received: (qmail 2956 invoked by uid 22791); 4 Sep 2012 21:19:39 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,TW_XF X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Sep 2012 21:19:25 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 50EFD2F78006 for ; Tue, 4 Sep 2012 22:19:24 +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 jcNh0lXkvc94; Tue, 4 Sep 2012 22:19:22 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-bugs@ecos.sourceware.org Subject: [Bug 1001606] Enable the cache on Kinetis in RAM startup mode X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: eCos X-Bugzilla-Component: HAL X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: ilijak@siva.com.mk X-Bugzilla-Status: NEEDINFO X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: jifl@ecoscentric.com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: In-Reply-To: References: X-Bugzilla-URL: http://bugs.ecos.sourceware.org/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Tue, 04 Sep 2012 21:19:00 -0000 Message-Id: <20120904211922.210762F78001@mail.ecoscentric.com> Mailing-List: contact ecos-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-bugs-owner@sourceware.org X-SW-Source: 2012/txt/msg01244.txt.bz2 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001606 --- Comment #17 from Ilija Kocho 2012-09-04 22:19:19 BST --- Hi Jifl It's been a long time... Finally I got some time to revisit this bug. (In reply to comment #15) I did some experiments regarding Unified/Separate caching issue. Here are the results and my observations. Other discussions are snipped off but not rejected. > Hi Ilija, > > (In reply to comment #14) > > (In reply to comment #11) > > > So what we should be doing is saying that the standard behaviour for Kinetis > > > ports is for all code to run at addresses from 0x0 - 0x1fffffff in order to go > > > via the PC bus; and all data is accessed from 0x20000000 - 0xffffffff to go via > > > the PS bus. Then we can say that HAL_ICACHE macros correspond to the code > > > addresses, and HAL_DCACHE macros correspond to the data. > > > > Then I would consider the following: > > > > 1. Separate cacheing is only applicable to mlt_*sram2s* memory layouts. I'd > > expect the majority of users to be happier with mlt_*unisram*, especially on > > devices with smaller SRAM. > > Admittedly I have only been looking at the K70 so maybe things are different > elsewhere, but SRAM isn't cacheable anyway (as per 3.5.4.1 Local memory > controller region assignment, page 126 of the K70 Ref manual) - presumably > because SRAM is as fast as cache. So we can ignore SRAM when it comes to > caching. I don't recall in what context I wrote the above?! Pse disregard. > > For the other regions, they are available mirrored, e.g. with one DRAM alias > writethrough at 0x08000000 - 0x0FFFFFFF, which is in the PC range and clearly > aimed at code, and DRAM higher up in the PS range which can also be writeback > mode, and is clearly aimed at data. I tried to utilize this mirror memory in hope that caching code and data in different caches will boost the Harvard. In Attachment #1929 the region "program" placed at 0x08000000 is supposed to contain /code/ sections while /data/ sections reside in "ram" region. The system crashes/resets when it comes to initialization of .bss section. I was able to single-step but when I try to run with full speed it doesn't work. My suspect is the collision between two cache units over RAM, it looks like Harvard is trying to simultaneous instruction fetch and data access. > > So I don't see the need to do things different with the cache, though it's > still reasonable to have the two layouts because of the difficulty in spreading > memory between regions - this could be solved with a little more linker > intelligence, so I've now submitted this for the future, not that it helps us > now: ). > > > 2. The internal FLASH is only accessible at base address 0x0 i.e. from PC bus. > > This implies that .rodata has to be relocated in either SRAM_U or external RAM > > (for systems that have external RAM). > > It doesn't have to really. Being read-only means you don't have to worry about > the data changing though, so I don't believe it makes any difference to my > suggestion on the memory layout and therefore caches. It's true the flash > driver would have to invalidate both caches, but then that's standard practice > for any flash driver. > Considering above, I think that we could conclude that for both RAM and FLASH it is hard (or not possible) to effectively enforce caching of instructions and data in separate caches. If you agree I would keep unified caches and look after your other remarks. Ilija -- Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.