[uClinux-dev] m68k : gcc-4.1-30 & SRAM

Eric BENARD ebenard at free.fr
Thu Jan 18 13:18:09 EST 2007


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


More information about the uClinux-dev mailing list