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.


On Wed, Sep 28, 2005 at 08:52:49AM -0700, Andrew Voelkel wrote:
> 
> This is another newbie question, I'm afraid. As a veteran embedded systems
> programmer, I am used to carefully crafting linker control files in order to
> control the memory layout of programs, monitors, and other loadable
> entities. I am having a hard time find the information I need to understand
> how to do this within the ECOS environment.
> 
> Massa's book talks about using the configtool, but then mentions that only
> older config tools support a memory layout tool. And besides, I've learned
> that I can't rely on the configtool. Elsewhere in the ECOS docs, I found a
> page or two talking about .ldi files, but it seems to indicate that these
> control files only need to change when your hardware changes. And the .ldi
> files I've found ominously tell me that they are generated and that I should
> not edit them. I haven't found anything anywhere that discusses the
> mechanisms ECOS uses to generate the linker control files, or how I can
> modify the process to suit my needs if I have to.

The .ldi and .h files were origionally generated using the v1 config
tool. But this tool has been dead for a long time. So people ignore
the warning and edit them. 

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


MEMORY
{
    ram : ORIGIN = 0, LENGTH = 0x1000000
    rom : ORIGIN = 0x41000000, LENGTH = 0x400000
}

SECTIONS
{
    SECTIONS_BEGIN
    SECTION_rom_vectors (rom, 0x41000000, LMA_EQ_VMA)
    SECTION_text (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fini (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata1 (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixup (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_gcc_except_table (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixed_vectors (ram, 0x20, LMA_EQ_VMA)
    SECTION_data (ram, 0x8000, FOLLOWING (.gcc_except_table))
    SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)
    CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
    CYG_LABEL_DEFN(__pci_window) = 0xf00000; . = CYG_LABEL_DEFN(__pci_window) + 0x100000;    SECTIONS_END
}

The data and bss are placed at 0x8000. (For this target the
Translation lookaside buffers for the MMU are placed at 0x4000-0x8000,
hence that section of RAM is not used here. The fixed vectors are the
vectors used for interrupt handling. They should be the same for ROM
and RAM so that if the RAM eCos does not take control of a vector it
will default back to the ROM version. This allows for example the gdb
stub to be called if there is a memory exception.

Now the RAM version

SECTIONS
{
    SECTIONS_BEGIN
    SECTION_fixed_vectors (ram, 0x20, LMA_EQ_VMA)
    SECTION_rom_vectors (ram, 0x30000, LMA_EQ_VMA)
    SECTION_text (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fini (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata1 (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixup (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_gcc_except_table (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_data (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)
    CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
    CYG_LABEL_DEFN(__pci_window) = 0xf00000; . = CYG_LABEL_DEFN(__pci_window) + 0x100000;    SECTIONS_END
}

Here you can see that the application code is placed at 0x30000. So
the ROM version of eCos has been allocated 0x00000-0x30000.

Its virtually as simple as that. Just make sure your .h and .ldi file
agree and it should all work.

        Andrew

-- 
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]