[ECOS] Guidance on ROMRAM ldi

Sergei Gavrikov sergei.gavrikov@gmail.com
Sat Nov 20 09:54:00 GMT 2010


On Fri, 19 Nov 2010, Michael Bergandi wrote:
> Hi all,
>
> I am trying to learn more about the linker file used in a ROMRAM
> configuration. I have looked at several other ROMRAM ldi files for the
> ARM, but I can't seem to find much agreement as to the proper way to
> set up the SECTIONS section.
>
> Our board has 2MB ROM and 32MB RAM and uses an iMX27 (ARM9) processor.
> The current ldi file is adapted from a Freescale Redboot port to the
> iMX27 LiteKit and looks like this:
>
> MEMORY
> {
>    ram : ORIGIN = 0, LENGTH = 0x02000000
>    rom : ORIGIN = 0xA1E00000, LENGTH = 0x00200000
> }
>
> SECTIONS
> {
>    SECTIONS_BEGIN
>    SECTION_rom_vectors (rom, 0xA1E00000, 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_sram (ram, 0x8000, FOLLOWING (.gcc_except_table))
>    SECTION_data (ram, ALIGN (0x4), LMA_EQ_VMA)
>    SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)
>    CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
>    SECTIONS_END
> }

It looks like ROM LDI.

> If I understand correctly, the lengths provided from rom and ram in
> the MEMORY section should be the actual size without concession for a
> copy of ROM that would consume a portion of the RAM.
>
> The rom ORIGIN is an offset into the RAM (which is mapped to both
> 0x00000000 and 0xA0000000). We want our app to be loaded to the end of
> the RAM.

The MEMORY block contains lines describing the address (ORIGIN) and the
size (LENGTH) of each memory region.[1]

----
[1] http://ecos.sourceware.org/docs-latest/user-guide/modifying-the-memory-layout.html

> In some of the other ROMRAM ldi files I looked at, the SECTION
> declarations use only 'ram' and not 'rom'. I'm thinking this may not
> matter depending on the order and SECTION declaration options
> (assuming you are only working with a single chunk off RAM). Is this
> thinking correct?

In contrast, the most the linker script includes uses only ram! For
the linker's view a ROMRAM startup should be like RAM startup.

   grep -I -r -l --include *romram.ldi rom, $ECOS_REPOSITORY | wc -l
   5

   grep -v -I -r -l --include *romram.ldi rom, $ECOS_REPOSITORY | wc -l
   33

It was a discovery for me what there are 5 such files in the trunk. But,
those are auto-generated .ldi files with Memory Layout Tool in old good
years. Use patterns from those 33 romram.ldi. Necessarily look on the
target's startup code to get it. There is a piece of code in asm which
does relocation.

For references how it works look on hal_platform_setup.h or for non-ARM
targets on its target.S sources.

> I have also seen some discussion in the archives suggesting that using
> LMA_EQ_VMA is not the right thing to use. Is there  a final word on
> this? Should I use only FOLLOWING, as I have seen elsewhere?

In 99% cases for embedded world it is used LMA_EQ_VMA.  If you know
LMA_EQ_VMA, SECTION_xxx are macros are defined in platform .ld file,
for example, for ARM:

   $ECOS_REPOSITORY/hal/arm/arch/*/src/arm.ld

> Is there some general rules of thumb on setting up the SECTION
> declarations to avoid common mistakes/problems?
> 
> Any advice is welcome.

Unfortunately, I have not seen a good guide on a design the eCos .ldi
files.

UTSL. Use those .ldi, asm sources as prototypes, and investigate.

Although, this guide http://sourceware.org/binutils/docs-2.20/ld/ is the
LD Biblio.

Sergei

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

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



More information about the Ecos-discuss mailing list