Re: [ECOS] Guidance on ROMRAM ldi

[Michael Bergandi <mbergandi at gmail dot com>]

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