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: Guidance on ROMRAM ldi


Sergei,

> Let's look on FOLLOWING macro in arm.ld. The above ldi script *force*
> two things: and section alingment and section order "manually", i.e. be
> alignment, follow that. I never see the famous MLT tool from RedHat, but
> my guess is: a user could just define sections in that user-friendly GUI
> (one by one) and could check: be aligned and could specify: follow this
> section. ?And voila, he/she got .mlt, .ldi, .h files! I never see the
> MLT screenshots (that is from my mind). My guess that "lazy" users got
> LMA_EQ_VMA-centric ldi scrits and experienced users made smart scripts.
> But that my guess only :-) Let's eCos veterans say what MLT was.
>
> I think you've got not very much information from me, but still...

I appreciate your input. You have helped me by guiding me to a few
more bits of information that I didn't have before. The above is an
example. I hadn't thought to look at the ld of the arch (arm.ld). I
found the following macro:

#define FOLLOWING(_section_) AT ((LOADADDR (_section_) + SIZEOF
(_section_) + ALIGN_LMA - 1) & ~ (ALIGN_LMA - 1))

Looking at what this macro does and by confirming with the map file,
this added a lot of valuable info. Here is a repost of my ldi file:

MEMORY
{
    ram : ORIGIN = 0, LENGTH = 0x2000000
    rom : ORIGIN = 0xA1E00000, LENGTH = 0x200000
}

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
}

Now, from the map file, I see pretty much what I expected for the
rom_vectors section through the gcc_except_table. The sections are
mapped from 0xA1E00000 through 0xA1F06B44 (gcc_except_table). However,
then things start to get cloudy for me. I know what is happening, but
I don't really know what it means. Here is a snip from the map file:

<snips from map file>
.gcc_except_table
                0xa1f06b44        0x0
.fixed_vectors  0x00000020      0x160
.sram           0x00008000     0x8100 load address 0xa1f06b44
.data           0x00010100     0x2c80 load address 0xa1f0ec44
.bss            0x00012d80   0x3339cc load address 0xa1f118c4

I see a gcc_except_table of size 0 mapped to 0xa1f06b44. Ok, no
problem. I see fixed_vectors of size 0x160 mapped to 0x00000020.
Bottom of ram with room for exception vectors...Ok, no problem. Then,
I see the sram section of size 0x8100 mapped to 0x00008000 (toward
bottom of ram), but then I see this 'load address 0xa1f0ec44' comment.
Now things get a bit cloudy.

As I understand it, the load address is the LMA. I think this means
that this section would be part of the rom image (main.bin), which
would get copied to the 'rom' memory start address in ram
(0xA1E00000). If so, then Ok, I get it.

Then, I see the same thing for the .data and .bss sections. Well, now
I don't get it. The .data section is 0x2c80 in size and ends at
0xa1f118c4. Ok, fine, we are still within the bounds of ram
(0xa2000000) and still within the size of rom (0x001118C4 <=
0x00200000). Then comes the bss section. The bss is 0x333933 in size.
The bss size alone is larger than my rom and the load address (LMA)
plus size would put its end well beyond my ram address space. This is
what I don't get. I can tell you that the main.bin (binary image for
flash) is 1.1MB, which is no where near the size of the bss. My app
also links and works fine with the above ldi. What am I missing?

My second unresolved question is in reference to the memory region. As
I have given examples of other ldi's, I pointed out that some of them
reduce the length of the ram region by the size of the rom region and
some do not. I consider these as non-overlapped and overlapped. If one
does the overlapped method, do they risk the heap growing into the rom
region? Or, conversely, does using the non-overlapped method prevent
the heap from growing into the rom region?

Thanks again for your time.

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


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