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 <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEEDINFO CC| |[email protected] Ever Confirmed|0 |1 --- Comment #6 from John Dallaway <[email protected]> 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.
