This is the mail archive of the
ecos-patches@sourceware.org
mailing list for the eCos project.
[Bug 1001187] New port: Freescale Kinetis variant, Freescale TWR-K60N512, Freescale UART device driver
- From: bugzilla-daemon at bugs dot ecos dot sourceware dot org
- To: ecos-patches at ecos dot sourceware dot org
- Date: Wed, 18 May 2011 12:04:17 +0100
- Subject: [Bug 1001187] New port: Freescale Kinetis variant, Freescale TWR-K60N512, Freescale UART device driver
- Auto-submitted: auto-generated
- References: <bug-1001187-104@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=1001187
John Dallaway <john@dallaway.org.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEEDINFO
CC| |john@dallaway.org.uk
Ever Confirmed|0 |1
--- Comment #6 from John Dallaway <john@dallaway.org.uk> 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.