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

[David Brown]

Here's a possible way to cheat -

int __attribute__((__section(".data"))) func(void) { ... }

I haven't tried it with the ColdFire tools or the flt format (I've only 
used elf files, and then it's easy to add extra sections), but I've used 
it with gcc on the msp430 to get the same effect without having to 
modify linker files or startup code.  Basically, the function 
implementation gets copied into ram along with initialised data.  You 
will probably get assembler or linker warnings about changes to the 
sections attributes (suddenly the ".data" section is executable as well 
as read/write).

You probably already know this, but when putting functions into ram like 
this (such as for flash programming routines), be very careful that any 
other functions (including library functions) that might be called are 
also in ram, and that interrupts are disabled before calling it - 
otherwise the processor will jump back to the flash.

mvh.,

David


Nathan Sidwell wrote:
> 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
>