This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: memory maps, linker control files, etc.


>> This lack of information stands in the way of my understand basic things
>> like how Redboot and an ECOS application can both use system memory
>without
>> stepping on each other - an issue that I've handled manually in other
>> situations. 
>> 
>> Even figuring out how to generate a linker map file involved poring
>through
>> the giant man page for arm-elf-gcc.
>
>Normally it is not necassary to change anything. The only time you do
>is when you are porting to different hardware, adding or removing
>memory etc.
>
>Generally each port has two setups, ROM and RAM. Redboot use the ROM
>setup and the application uses the RAM setup. Generally the lower part
>of RAM is reserved for the ROM redboot to put its stack, bss, etc. The
>size of this is hard coded. 
>
>So take for example the ebsa285....

So the ROMRAM or RAM versions of redboot cannot be used to load and debug
ECOS programs? I don't remember reading that anywhere. But of course I've
been reading so much new stuff, I may have not have noticed it.

If this is true, it would be consistent with my observation that the .ldi
files for configurations derived from the Redboot ROMRAM template and the
"default" ROMRAM template seem to be identical.

This brings up a couple more questions, one of which has been rattling
around in my brain for a bit:

1. What is the purpose of the ROMRAM and RAM versions of Redboot, if they
cannot be used for loading and running ECOS programs?

2. Why use the GDB stubs in Redboot to debug ECOS programs, when you can
just have the ECOS program take over completely and have their own GDB
stubs? That seems a simpler model, without the complexity of the VVTs,
Ethernet port sharing, etc. When one is finished debugging, one can simply
press the reset switch on the eval board to restart Redboot. Or, in the case
where the program exits itself, one could trigger a hard system reset from
ROM via software. The only reason I can think of to leave Redboot around
while an ECOS program is running is to use its other capabilities during the
operation of an ECOS program. It strikes me that this capability is not
needed very often. What am I missing?

- Andy



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]