[coldfire-gnu-discuss] gcc-4.1-30 & SRAM

[Nathan Sidwell]

Eric BENARD wrote:
 > Hi,
 >
 > I'm using a MCF5208 Coldfire which has 16kB of SRAM.
 > I'm using the uclinux tools from Codesourcery on x86 :
 > $ m68k-uclinux-gcc -v
 > gcc version 4.1.1 (CodeSourcery Sourcery G++ 4.1-30)
 >
 > I'm trying to move parts of the code into SRAM without success until now.
 >
 > I've prefixed the test function I want to put in SRAM as follows :
 > int __attribute__((__section__(".sramcode"))) func()
 >
 > In elf2flt.ld, I've added :
 > MEMORY {
 > 	flatmem : ORIGIN = 0x0, LENGTH = 0x1000000
 > 	sram  : ORIGIN = 0x80000000, LENGTH = 12k
 > }


Thanks for using our downloads.  What you're trying to do is not supported in 
this way.  The FLT binary has to consist of text and data segments, along with a 
relocation table.  You cannot add additional segments.  All the relocations must 
be to symbols within the text or data (or bss) segments.  This is a fundamental 
design of the FLT format.

If you want to place code into sram, you will need to copy it there explicitly 
from within your application.  The management of the SRAM is straying into OS 
issues that I am unfamiliar with -- perhaps uclinux has a mechanism to avoid 
multiple applications using that memory.

Accessing objects in the sram region you define is going to be tricky.  The most 
straight forward mechanism will be via a pointer to that memory.  You may be 
able to produce a linker script that loads the sram image into the data segment, 
but keeps it's VMA as you desire.  You'll have to adjust the FLT file creation 
to remove relocations against that segment (normally relocations are kept). 
I've not thought hard about this though.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::         CodeSourcery
nathan at codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk