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


On Fri, 26 Nov 2010, Michael Bergandi wrote:
> 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))
 
Yep, I refer you exactly to this point. On some stages of build process
eCos the arm.ld (which includes your ldi file) will be processed and it
becomes install/lib/target.ld and vector.S (which includes your platform
startup code -- hal_platform_setup.h) becomes install/lib/vector.o.  So,
these both files (arm.ld, vectors.S) are important for you if you want
to know more things and if you want to do something smart.

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

You forced this (see own ldi above) with

  SECTION_sram (ram, 0x8000, FOLLOWING (.gcc_except_table))

As .gcc_except_table starts and ends at 0xa1f06b44, you "said" early, -
SECTION_sram, follow it (.gcc_except_table). And what do you want to do?

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

I do not understand. Did you expect to get 32M binary? In past email I
did mention the PROGBITS which relocate itself in your ASM code. Look
at a section headers in got main *ELF* file

  % arm-eabi-readelf -h main

You will see that .bss section has a size, *but* it marked as 'NOBITS'!
BSS comes from "BLOCK STARTED by SYMBOL". No magic here. Look on it as
on a label.

NOTE: objdump, readelf and other GNU binutils help you to get a lot of
information at once and save your eyes from observing the got map file.

In brief about sizes

  % arm-eabi-size -Ax main

And so on. Investigate your time in a learning those great tools and you
will get a power.

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

I guess that your question about ROMRAM programs which some of them
relocate itself on bottom of RAM and some of them relocate itself on top
of RAM. For the first ones you do not need shrink actual RAM size in ldi
file, because .bss section follows .text section and heap can grow until
the physical RAM limit; for the second ones .bss section starts before
relocated on top of RAM the .text section. Right? You have to "shrink"
actual RAM size to prevent overlapping/ruin the .text section (program
code) from, for example, a) zeroing .bss section from early startup code
(it can be done); b) from overlapping .text by a growing heap then. So,
the first ROMRAM programs are protected by natural order the sections in
the linked stuff and the seconds are protected by such a "shrinking".

I see such a advantage for top based ROMRAM programs. Such the ROMRAM
monitors (RedBoot[ROMRAM] is relocated on top of RAM is good example for
this) still can load RAM applications like that has been done with [ROM]
monitors, because for the both kind of monitor (ROM and ROMRAM monitors)
a "label" %{FREEMEMLO} (if you know what is it) can be the same (and no
need to have the different versions of RAM programs to load).

If you talk about ROMRAM user application (no ROMRAM monitor) that does
not matter where to keep such an application on top or bottom of RAM.
FYI: RedBoot[ROMRAM] code never use 2M. As monitor is small a designer
would shrink only 128 or 256K on top of RAM, but other hypothetical
ROMRAM applications can be bigger. So, they can reserve a size is equal
whole size of ROM parts (2M in your case). Decision is yours.

Sergei

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