public inbox for ecos-bugs@sourceware.org help / color / mirror / Atom feed
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 Date: Sat, 03 Nov 2012 15:31:00 -0000 [thread overview] Message-ID: <20121103153119.6E8952F78005@mail.ecoscentric.com> (raw) In-Reply-To: <bug-1001606-13@http.bugs.ecos.sourceware.org/> Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001606 Ilija Kocho <ilijak@siva.com.mk> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #1966|0 |1 is obsolete| | Attachment #1967|0 |1 is obsolete| | --- Comment #36 from Ilija Kocho <ilijak@siva.com.mk> 2012-11-03 15:31:16 GMT --- Created an attachment (id=1973) --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1973) Kinetis variant - separate DCACHE-ICACHE 121103 (In reply to comment #35) > Finally I reply.... Many thanks... > > First of all, to follow up a specific question you asked: > > (In reply to comment #25) > > (In reply (addendum) to comment #23) > > > > > Bus arbitration tweak for copy-back DDRAM 121008 > > > > > > > Another consideration: It is possible to swap PC and PS priorities permanently > > for RAM startup. Then cache control macros will be shorter and there's no risk > > of preemption.. The drawback, if any, is that crossbar arbitration priorities > > for DDRAM will be different than the reset default. If implemented, this > > inversion could be fixed or configurable with CDL. > > Comments? > > I don't have a very good feel for what the effects of this would be. > Specifically, can you imagine a situation when someone really would want the PC > priority to be higher than the PS one? I can't see it making a big difference > either way in the end, so I'm thinking a permanent change would be ok (although > if so, why wasn't it the reset default?). If PC priority is lower there shouldn't be danger of stale since soon after instruction fetch is pre-empted by data access (from previous instruction), it will cause the data transfer to seize (previous instruction ends) that will unblock instruction fetch. Therefore, the set-up where PC has lower priority than PS looks inherently more stable than the opposite. However, I assume that it is most probable for users to expect reset-default priorities upon start-up so I have left them unchanged. Also I can imagine situation where user has set up PC higher priority then PS - then the protective macro will be still necessary. > > As for the main patches.... I'm glad that the split cache scheme has made such > a great improvement in measured performance, as per our private email exchange. > It shows it was worth the effort! Indeed. I redid the tests and new results for old scheme are not as low (now I have used different mirror, but there's still 30% boost. > > One thing that strikes me as odd is the addition of CYG_HAL_STARTUP_DEF_ROM to > define CYG_HAL_STARTUP_ROM for RAM startup types. This seems potentially risky. > What problem was it intended to solve? It shouldn't be there :(. I t is a ghost from my test to use technique from FLASH start-up [Bug 1001623] - ROM start-up emulation. It was working but copying initialized data from RAM to RAM makes little sense. Actually this cdl_option was removed, but somehow re-appeared. Now I have removed (patch attached) it again and retested everything. > > Other than that, I've reviewed everything already written in this issue, and > been through the current patches, and I don't see any reason not to commit the > patches. There might be a few essentially cosmetic things (spelling, typos, > etc.) that I could change, but minor touch-ups like that can be done after the > commit rather than going round the loop again. > So now I am going to commit, but I will leave this bug open for a while as a reminder. Thanks again 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.
next prev parent reply other threads:[~2012-11-03 15:31 UTC|newest] Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-06-02 16:03 [Bug 1001606] New: " bugzilla-daemon 2012-06-03 4:03 ` [Bug 1001606] " bugzilla-daemon 2012-06-03 20:10 ` bugzilla-daemon 2012-06-06 19:31 ` bugzilla-daemon 2012-06-10 0:05 ` bugzilla-daemon 2012-06-10 0:08 ` bugzilla-daemon 2012-06-10 20:35 ` bugzilla-daemon 2012-06-11 22:38 ` bugzilla-daemon 2012-06-11 22:43 ` bugzilla-daemon 2012-06-14 12:32 ` bugzilla-daemon 2012-06-16 1:14 ` bugzilla-daemon 2012-06-18 21:16 ` bugzilla-daemon 2012-06-23 5:58 ` bugzilla-daemon 2012-06-23 22:27 ` bugzilla-daemon 2012-06-26 20:54 ` bugzilla-daemon 2012-09-04 20:36 ` bugzilla-daemon 2012-09-04 21:19 ` bugzilla-daemon 2012-09-30 15:04 ` bugzilla-daemon 2012-10-03 20:21 ` bugzilla-daemon 2012-10-03 20:27 ` bugzilla-daemon 2012-10-07 17:24 ` bugzilla-daemon 2012-10-08 19:11 ` bugzilla-daemon 2012-10-08 19:15 ` bugzilla-daemon 2012-10-13 9:28 ` bugzilla-daemon 2012-10-16 20:53 ` bugzilla-daemon 2012-10-26 10:57 ` bugzilla-daemon 2012-10-26 11:01 ` bugzilla-daemon 2012-10-26 11:03 ` bugzilla-daemon 2012-10-27 7:56 ` bugzilla-daemon 2012-10-27 11:48 ` bugzilla-daemon 2012-10-27 11:58 ` bugzilla-daemon 2012-10-27 12:15 ` bugzilla-daemon 2012-10-27 12:58 ` bugzilla-daemon 2012-11-03 6:43 ` bugzilla-daemon 2012-11-03 15:31 ` bugzilla-daemon [this message] 2013-03-12 22:37 ` bugzilla-daemon 2012-06-02 16:03 [Bug 1001606] New: " bugzilla-daemon 2012-06-03 4:03 ` [Bug 1001606] " bugzilla-daemon 2012-06-03 20:10 ` bugzilla-daemon 2012-06-06 19:31 ` bugzilla-daemon 2012-06-09 9:35 ` bugzilla-daemon 2012-06-10 0:05 ` 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=20121103153119.6E8952F78005@mail.ecoscentric.com \ --to=bugzilla-daemon@bugs.ecos.sourceware.org \ --cc=ecos-bugs@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: linkBe 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).