public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
* RE: [ECOS] Multiple non-consecutive RAM regions
@ 2001-06-29  1:52 Tord.Andersson
  2001-06-29  3:08 ` Robin Farine
  0 siblings, 1 reply; 4+ messages in thread
From: Tord.Andersson @ 2001-06-29  1:52 UTC (permalink / raw)
  To: ecos-discuss

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/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ECOS] Multiple non-consecutive RAM regions
  2001-06-29  1:52 [ECOS] Multiple non-consecutive RAM regions Tord.Andersson
@ 2001-06-29  3:08 ` Robin Farine
  0 siblings, 0 replies; 4+ messages in thread
From: Robin Farine @ 2001-06-29  3:08 UTC (permalink / raw)
  To: Tord.Andersson; +Cc: ecos-discuss

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [ECOS] Multiple non-consecutive RAM regions
  2001-06-27 23:27 Tord.Andersson
@ 2001-06-28 10:45 ` Jonathan Larmour
  0 siblings, 0 replies; 4+ messages in thread
From: Jonathan Larmour @ 2001-06-28 10:45 UTC (permalink / raw)
  To: Tord.Andersson; +Cc: ecos-discuss

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/

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [ECOS] Multiple non-consecutive RAM regions
@ 2001-06-27 23:27 Tord.Andersson
  2001-06-28 10:45 ` Jonathan Larmour
  0 siblings, 1 reply; 4+ messages in thread
From: Tord.Andersson @ 2001-06-27 23:27 UTC (permalink / raw)
  To: ecos-discuss

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2001-06-29  3:08 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-06-29  1:52 [ECOS] Multiple non-consecutive RAM regions Tord.Andersson
2001-06-29  3:08 ` Robin Farine
  -- strict thread matches above, loose matches on Subject: below --
2001-06-27 23:27 Tord.Andersson
2001-06-28 10:45 ` Jonathan Larmour

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).