* 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).