[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

--- Comment #7 from Ilija Kocho <ilijak@siva.com.mk> 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.