On Thu, Dec 09, 2010 at 03:57:44PM +0530, Dinesh Guleria wrote:
> I am bit confused about VMA & LMA address for AVR.
> Virtual memory address & Load Memory Address.
> 1> What actually does it means ???????
The VMA is actually the runtime-address of the section. e.g. If code is
to be loaded into ROM, copied to RAM. and then executed, then VMA !=
LMA. That does not happen on the AVR, but non-zero initialised data does
experience this transfer.
> What i got from reading is that VMA is passed to linker & .ELF is created.
Please note that every section has both VMA and LMA. (Though they may be
the same.) All sections can be expected to be loaded to their LMA.
> While avr-objcopy read .elf & creats the .hex in this hex file .crt code
> will place the data variable to LMA. & .eep file in this file epprom
> variables are placed to LMA.
The LMA to VMA copying performed by .crt code is only non-zero initialised
variables. Note: .crt code copies _from_ LMA.
If you're using unmodified AVR toolchain linker scripts, then it is
likely that everything will work fine, and you can happily observe what
VMA and LMA are set to.
> Because of harvard architectue to avoid confusion related to memory
> address ( because EEPROM, RAM & Flash all will start from 0x0000 i.e
> ZERO address) GCC does following :--- Add 0x800000 the to real SRAM
> --- if you want the .data section to start at 0x1100, pass 0x801100 at
> the address Add 0x810000 the to real EEPROM 2> What does it add for
> the ROM address, i am bit confused --- ???????? 3> Also why this
> typical number series are chosen 0x800000 .... ???????
These offsets exist only to allow gcc to handle the harvard architectue
when it was never designed to do so. i.e. It is a workaround. Once you
realise that the offsets are there to fool gcc, it is easier not to
fooled as well.
The numbers only need to be large enough to avoid section overlap in all
anticipated future AVR devices. ;-)
> This operation produces VMA. This is only my understanding &
> assumption.
Nah. ;-)
Here you can see that both LMA and VMA are subject to the offsets:
$ avr-objdump -h test.elf
test.elf: file format elf32-avr
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 0000003a 00000000 00000000 00000094 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 00000000 00800100 0000003a 000000ce 2**0
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000000 00800100 0000003a 000000ce 2**0
ALLOC
3 .noinit 00000000 00800100 00800100 000000ce 2**0
CONTENTS
4 .eeprom 00000000 00810000 00810000 000000ce 2**0
CONTENTS
You can also see that "What does it add for the ROM address"? is zero.
(For .data, it may appear that only VMA is affected by offset, but that
is only because the offset for ROM is zero.)
There are enough hints in this reply to guide further repeated
reading of whatever documentation you can find. (I've not come across a
lot, but the gnu ls "info" page can be mined for understanding, with
repeated reading, interspersed by experiments.)
The best way to learn, I've found, is to write linker scripts, and tweak
them until they do what you want. (Admittedly, other targets than AVR
provide more scope for fiddling with VMA != LMA)
>
> Please correct me for the above three question.
These few answers will hopefully help toward clearing the confusion.
At least they'll shatter a few false assumptions, which will allow
clearer understanding of what you read.
It is all confusing at first.
Erik
_______________________________________________
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
