[ECOS] Multiple non-consecutive RAM regions

[ECOS] Multiple non-consecutive RAM regions

[Tord.Andersson]

Hi,

I have the following problem. Our ARM7 based target system has two
non-consecutive RAM areas.
Is there some way to make the linker utilize these two areas without
dividing the sections 
manually between these two areas?
I have tried to make a large RAM area covering the two RAMs with an absolute
reserved_empty section in 
between, but it doesnt seem to work. 
Any ideas?

Regards,

Tord

Re: [ECOS] Multiple non-consecutive RAM regions

[Jonathan Larmour]

Tord.Andersson@combitechsystems.com wrote:
> 
> Hi,
> 
> I have the following problem. Our ARM7 based target system has two
> non-consecutive RAM areas.
> Is there some way to make the linker utilize these two areas without
> dividing the sections
> manually between these two areas?
> I have tried to make a large RAM area covering the two RAMs with an absolute
> reserved_empty section in
> between, but it doesnt seem to work.
> Any ideas?

You'll have to add a new memory region - right now there is "rom" and
"ram", but you could add "ram2". But the linker still can't split any
individual sections over both regions, nor work out by itself which
sections should go in which regions. If you need that level of control,
then if you have an MMU you should map the region to be contiguous in the
virtual address space. If you don't have an MMU, I don't know :-).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/

RE: [ECOS] Multiple non-consecutive RAM regions

[Tord.Andersson]

Jonathan,

thanks for your reply. We'll go for a non-MMU solution (ARM7). 
A couple of more questions came up after reading your answer.
Is it possible to use the graphical config tool to add new 
regions or should I make these changes manually to any of the 
ECOS files?
I plan to instruct the linker to place some of the object files 
text in a new text2 segment. Would target.ld be the right file to modify 
with something like this:

SECTIONS {
.text2 : { Gr*(.text) }
... 


Regards,

Tord

-----Original Message-----
From: Jonathan Larmour [ mailto:jlarmour@redhat.com ]
Sent: den 28 juni 2001 19:46
To: Andersson Tord
Cc: ecos-discuss@sources.redhat.com
Subject: Re: [ECOS] Multiple non-consecutive RAM regions


Tord.Andersson@combitechsystems.com wrote:
> 
> Hi,
> 
> I have the following problem. Our ARM7 based target system has two
> non-consecutive RAM areas.
> Is there some way to make the linker utilize these two areas without
> dividing the sections
> manually between these two areas?
> I have tried to make a large RAM area covering the two RAMs with an
absolute
> reserved_empty section in
> between, but it doesnt seem to work.
> Any ideas?

You'll have to add a new memory region - right now there is "rom" and
"ram", but you could add "ram2". But the linker still can't split any
individual sections over both regions, nor work out by itself which
sections should go in which regions. If you need that level of control,
then if you have an MMU you should map the region to be contiguous in the
virtual address space. If you don't have an MMU, I don't know :-).

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/

Re: [ECOS] Multiple non-consecutive RAM regions

[Robin Farine]

Tord.Andersson@combitechsystems.com writes:

[...]

> I plan to instruct the linker to place some of the object files 
> text in a new text2 segment. Would target.ld be the right file to modify 
> with something like this:
> 
> SECTIONS {
> .text2 : { Gr*(.text) }
> ... 

If you do this, I think you'll get problems when converting your ELF image into
a binary image because the gap between the two regions will appear in the binary
image. If you can fit every output sections with the LOAD flag in your first
memory region (and the .bss section if it fits too), then you can just modify the
definition of your __heap1 symbol to start at the beginning of your second RAM
region. The configuration tool should let you do this.

If your .bss section doesn't fit in your first RAM region then move it to your
second RAM region and the __heap1 symbol will follow it automatically.

All this implies that at least the .rom_vectors, .text, .rodata and .data sections
must fit in your first RAM region.

Robin