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???
Martin Thomas wrote:
> Please show the linker-script.
Oh, yes, sorry...
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...
I currently can not help with "file offset".
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?
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.