From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7086 invoked by alias); 19 May 2011 10:30:03 -0000 Received: (qmail 6967 invoked by uid 22791); 19 May 2011 10:30:01 -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; Thu, 19 May 2011 10:29:47 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id A3CF22F78004 for ; Thu, 19 May 2011 11:29:45 +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 qyKIrUGw1yqN; Thu, 19 May 2011 11:29:43 +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: ilijak@siva.com.mk 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: 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: Thu, 19 May 2011 10:30:00 -0000 Message-Id: <20110519102941.DDAFE2F78007@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/msg00021.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 --- Comment #7 from Ilija Kocho 2011-05-19 11:29:38 BST --- (In reply to comment #6) > Ilija > > Thank you for the contribution. Thank you for your comments John. > > (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. > There is a comment on Kinetis flash security accompanying code in kinetis_misc.c. In ldi I can reference it. > > 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. > Good approach. Platform HAL is growing indeed. > > 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? ROM 2x64 True, ROM 2x64 startup SRAM_L does not utilize by eCos directly. The idea is, since SRAM_L is in Cortex-M code area, to use it as a fast extension of flash where user could upload a code that needs fast execution (Present Kinetis run up to 100Mhz, but maximum flash frequency is 25MHz. Some Kinetis members do have cache, but some do not). SRAM 2x64 SRAM startup 2x64 is trying to simulate ROM startup where SRAM_L emulates flash and SRAM_U ram. In order to make behavior closer to ROM startup, even the vectors are being copied. Naturally, this is not efficient usage of memory, but is good way for user to simulate/learn ROM startup without burning flash (Maybe I could put some word on this in description.) To sum up, Kinetis memory configuration offers some flexibility and offered memory configurations are attempt to reflect it in eCos and at the same time point out eCos' configurability. -- 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.