Sergei, > 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. >
Awesome! Yes, I forget about using those tools as I need them so infrequently. Thanks to these tools and your explanation, I now realize what is going on with the bss section. I guess I always thought of the bss as a thing, instead of what it really is. If my new knowledge is correct, then I just need to look at the start address of the bss. If (bss_start - rom_start) > rom_size, then my image has outgrown the region of memory that was set aside for the ROM copy. >> 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. Ours is a custom app. There is no reason that we have it at the top of RAM, other than that is the way it was done in the Freescale redboot code. I will leave it that way for now, since it works. I really appreciate your time and effort in guiding me on this exploration of the ROMRAM.ldi. Thank you again. -- 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