From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17665 invoked by alias); 18 May 2011 11:04:37 -0000 Received: (qmail 17639 invoked by uid 22791); 18 May 2011 11:04:36 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00 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; Wed, 18 May 2011 11:04:21 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id 76FC92F78004 for ; Wed, 18 May 2011 12:04:20 +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 PgABaW9bG-XE; Wed, 18 May 2011 12:04:18 +0100 (BST) From: bugzilla-daemon@bugs.ecos.sourceware.org To: ecos-patches@ecos.sourceware.org Subject: [Bug 1001187] New port: Freescale Kinetis variant, Freescale TWR-K60N512, Freescale UART device driver 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: john@dallaway.org.uk X-Bugzilla-Status: NEEDINFO X-Bugzilla-Priority: low X-Bugzilla-Assigned-To: unassigned@bugs.ecos.sourceware.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Status CC Ever Confirmed 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: Wed, 18 May 2011 11:04:00 -0000 Message-Id: <20110518110417.CB31D2F78009@mail.ecoscentric.com> 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 X-SW-Source: 2011-05/txt/msg00017.txt.bz2 Please do not reply to this email. Use the web interface provided at: http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001187 John Dallaway changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEEDINFO CC| |john@dallaway.org.uk Ever Confirmed|0 |1 --- Comment #6 from John Dallaway 2011-05-18 12:04:14 BST --- Ilija Thank you for the contribution. (In reply to comment #5) > Topics for consideration: > > 1. FLASH sections: > > 1.1 Kinets controllers have a special area in FLASH at addr. 0x400..0x40F that > contains flash security configuration. > In order to meet this, a new section is ".flash_security" introduced in MLT > files. Currently this section is encoded in natural form in MLT files (in a > same way as for Freescale MAC7100 port). I tried with USER_SECTION but ld > garbage collector discars this section as it is not referenced - so needs KEEP > parameter. > > Comments/alternatives? As you point out, there is a precedent in the MAC7100 port. This is a quite specialized requirement so probably OK to code without a macro but including explanation in a comment. If we encounter other uses for a user-defined section with KEEP attribute then we can (and should) add a new macro definition to *.ld. > 1.2 As a consequence of 1.1 flash area (1 KiB) below 0x400 is cut-off from > main flash body. In order to utilize this memory the USER_SECTION > ".kinetis_misc" is introduced. It currently accomodates functions from > kinetis_misc.c (as well as platform misc) but still remains about half empty. > > Please suggest candidate (functions, etc.) to fill this area. Since you have 128KiB SRAM on chip, filling the remaining 0.5KiB of the .kinetis_misc section does not seem to be a high priority. I would leave this available to allow the platform code to grow a little in the future. > 2. SRAM Layout > > Kinetis SRAM consists of two equal-size banks that occupy (consecutive) memory > blocks above and below 0x20000000. Below is example of K60N512 (2 x 64KiB) > > 0x20010000 -------------- > | SRAM_U | <---> System Bus > 0x20000000 -------------------- > | SRAM_L | <---> Code bus > 0x1FFF0000 -------------- > > These blocks are being accessed by two separate Cortex-M buses (according to > Cortex-M architecture) allowing simultaneous access (by either Harward or > concurrent bus masters). On the other hand SRAM can also be used as flat area > allowing for better SRAM utilization. > > In order to provide user a choice, the CDL option > CYGHWR_HAL_CORTEXM_KINETIS_SRAM_UNIFIED and parallel MLT files with unified > and non-unified SRAM are provided. It looks like the "2x64" memory layouts just allocate into the upper 64KiB. How do you envisage eCos developers using the lower 64KiB when not unified? -- 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.