We're converting an IAR project over to gnuarm (processor is
STR912FW44). We've gotten most parts of the startup code converted in a
reasonable manner, but one anomaly remains.
In the IAR project, when we generate a listing from the ELF output, we
see at the beginning:
//*******************************************
ODU.elf: file format elf32-littlearm
Sections:
Idx Name Size VMA LMA File off Algn
0 INTVEC,ICODE,CODE,INITTAB 000012ac 00000000 00000000 00000034
2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 DATA_Z 0000003a 04000000 04000000 000012e0 2**0
ALLOC
And the vector table begins at offset 0 in Idx0, which looks reasonable.
Note that Idx0 has "File offset" as 0.
However, when we build with gnuarm, we see:
//*******************************************
odu.elf: file format elf32-littlearm
Sections:
Idx Name Size VMA LMA File off Algn
0 .flashtext 00000050 00000000 00000000 00008000 2**0
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .text 0002c144 00000050 00000050 00008050 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
The vector table still begins at offset 0 in Idx0, but notice that "File
offset" is 0x8000 ... Why is this happening?? It almost looks it's
mapped the secondary (boot) rom in front of the main 512K rom, but we
never told it to do that. What causes this to occur???
Dan Miller wrote:
> Martin Thomas wrote:>> Please show the linker-script.>> Oh, yes, sorry...
Bump??
The only thing I need to understand here, is what defines that "file
offset" field, and what it actually means?
When I look at the .elf file (objdump -f odu.elf), it says:
odu.elf: file format elf32-littlearm
architecture: arm, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x00000000
But I don't really think the cpu is starting at 0. Also, if I load
the .elf file into arm-elf-insight, it starts at offset 0x1464C, which
is in the middle of main(), and doesn't correlate (as far as I can
detect) to any address, size, or offset anywhere in my code!?!? I'm
very confused...
Dan Miller wrote:
> The only thing I need to understand here, is what defines that "file> offset" field, and what it actually means?
Can not help here. Never needed hat to work on this value.
>> When I look at the .elf file (objdump -f odu.elf), it says:>> odu.elf: file format elf32-littlearm> architecture: arm, flags 0x00000112:> EXEC_P, HAS_SYMS, D_PAGED> start address 0x00000000>> But I don't really think the cpu is starting at 0.
I only know controllers where the start-addresse is fixed of can be
configured by hardware. You should find out at which addresse the
conroller starts and link at least the reset-vector to this address.
Don't know enough about STR9 to help.
> Also, if I load> the .elf file into arm-elf-insight, it starts at offset 0x1464C, which> is in the middle of main(), and doesn't correlate (as far as I can> detect) to any address, size, or offset anywhere in my code!?!? I'm> very confused...
- First check the map-file for addresses of vectors, init-code, .text,
.data, .bss and maybe special sections. Are those addresses reasonable
is everything in the expected link-section?
- Check the symbol-file if symbols from linker and maybe from
startup-code are
set correctly
- Does a minimal applicaiton without interrupts work?
- Does a minimal applicaiton with interrupts-work?
- Is some kind of remapping used?