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

[Eric BENARD]

Nathan Sidwell wrote :
> Thanks for using our downloads. 

Thanks for your work on these tools ;-)

> 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.
> 
That's what I was afraid of ...

> 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.
> 
uClinux doesn't use the internal SRAM. In my case I already manage to
use 4kB for data with malloc/free functions reworked by Gerg Ungerer in
it's mp3player. For code, there will be only one application using it so
the management of thje SRAM should be pretty simple ... once I manage to
link code into it !

> 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.
> 
OK, I'll let you know if I find a way to do this.

Many thanks and best regards
Eric