[Bug 1001187] New port: Freescale Kinetis variant, Freescale TWR-K60N512, Freescale UART device driver

[bugzilla-daemon@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.