* RE: [ECOS] Elf to Bin format
@ 2001-06-04 11:49 Narayana, Venkat A.
2001-06-04 12:00 ` Gary Thomas
0 siblings, 1 reply; 11+ messages in thread
From: Narayana, Venkat A. @ 2001-06-04 11:49 UTC (permalink / raw)
To: 'Mark Salter'; +Cc: 'ecos-discuss@sources.redhat.com'
Hi Friends,
Thanks you very much for helping me a learn a lot.
The problem i encountered is both with my experimentation
and with the convert tool i am using.This tool,by default,
will convert elf sections based on Virtual addresses,
not on physical addresss. This means that the bin file
will not contain any sections, whose reloc addresses are
different from load address. To compound the matters,
the bin file size this tool created is same as objcopy's
bin file, hence the confusion.
Thanks for your patience and help.
Thanks to Mark, Jonathan, Gary and others.
Best Regards,
Venkat
>>>>> Narayana, Venkat A writes:
> objdump of redboot.elf
> arm-elf-objdump -h redboot.elf | more
> redboot.elf: file format elf32-littlearm
> Sections:
> Idx Name Size VMA LMA File off Algn
> 0 .debug_aranges 000005a0 00000000 00000000 0003a7d4 2**0
> CONTENTS, READONLY, DEBUGGING
> 1 .debug_pubnames 000027b0 00000000 00000000 0003ad74 2**0
> CONTENTS, READONLY, DEBUGGING
> 2 .debug_info 000303df 00000000 00000000 0003d524 2**0
> CONTENTS, READONLY, DEBUGGING
> 3 .debug_abbrev 00004794 00000000 00000000 0006d903 2**0
> CONTENTS, READONLY, DEBUGGING
> 4 .debug_line 000184ab 00000000 00000000 00072097 2**0
> CONTENTS, READONLY, DEBUGGING
> 5 .rom_vectors 00000040 a0000000 00000000 00008000 2**0
> CONTENTS, ALLOC, LOAD, CODE
> 6 .text 000274b4 00002000 00002000 0000a000 2**14
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 7 .fini 00000000 000294b4 000294b4 0008a542 2**0
> CONTENTS
> 8 .rodata 00006e38 000294b4 000294b4 000314b4 2**2
> CONTENTS, ALLOC, LOAD, DATA
> 9 .rodata1 00000000 000302ec 000302ec 0008a542 2**0
> CONTENTS
> 10 .fixup 00000000 000302ec 000302ec 0008a542 2**0
> CONTENTS
> 11 .gcc_except_table 00000000 000302ec 000302ec 0008a542 2**0
> CONTENTS
> 12 .fixed_vectors 00000160 a1f00020 a1f00020 0008a560 2**5
> CONTENTS
^^^^^^^^^^^^^^^^^^
This looks worng. You mentioned earlier that you moved .fixed_vectors.
This may be triggering a objcopy bug. Objcopy would try to put the
.fixed_vectors at offset 0xa1f00020 in the binary file which would
make the file ~2.7G long. Objcopy might be giving up at this point
so it doesn't get to .data.
It looks like you missed something when moving the .fixed_vectors
around.
> 13 .data 000007d4 a000a000 000302ec 0003a000 2**2
> CONTENTS, ALLOC, LOAD, DATA
> 14 .bss 00006c38 a000a7d4 a000a7d4 0003a7d4 2**4
> ALLOC
--Mark
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [ECOS] Elf to Bin format
2001-06-04 11:49 [ECOS] Elf to Bin format Narayana, Venkat A.
@ 2001-06-04 12:00 ` Gary Thomas
0 siblings, 0 replies; 11+ messages in thread
From: Gary Thomas @ 2001-06-04 12:00 UTC (permalink / raw)
To: Narayana, Venkat A.; +Cc: ecos-discuss, Mark Salter
On 04-Jun-2001 Narayana, Venkat A. wrote:
> Hi Friends,
> Thanks you very much for helping me a learn a lot.
> The problem i encountered is both with my experimentation
> and with the convert tool i am using.This tool,by default,
> will convert elf sections based on Virtual addresses,
> not on physical addresss. This means that the bin file
> will not contain any sections, whose reloc addresses are
> different from load address. To compound the matters,
> the bin file size this tool created is same as objcopy's
> bin file, hence the confusion.
>
> Thanks for your patience and help.
>
> Thanks to Mark, Jonathan, Gary and others.
>
This note implies that you are using a tool other than objcopy.
Is this true? If so, why?
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [ECOS] Elf to Bin format
@ 2001-06-04 8:57 Narayana, Venkat A.
2001-06-04 9:20 ` Mark Salter
0 siblings, 1 reply; 11+ messages in thread
From: Narayana, Venkat A. @ 2001-06-04 8:57 UTC (permalink / raw)
To: 'Mark Salter'; +Cc: 'ecos-discuss@sources.redhat.com'
[snip]
> As was previously stated in this thread, my bin
> file, when i flashed it into a flash, does not contain
> .data section.
What makes you think this?
Because,after i load the bin file into flash,i am using
windriver's visionclick to view the contents of flash,
and i find that the contents are correct till .rodata
section,i.e upto address 302ec.
.data section follows rodata section. i,e .data section
begins at 302ec,which is rom_data_start and goes up to
0x7d4 bytes. Now,the tool shows me that from 302ec onwards
there's no data. The tool could be wrong, so when i single
steeped, i got to the same conclusion, when i am at this
piece of code:( this is in vectors.S )
// Relocate [copy] data from ROM to RAM
// .__ram_data_start is same as __ram_data_start
// this is because of the way PTR defines them.
ldr r3,.__rom_data_start
ldr r4,.__ram_data_start
ldr r5,.__ram_data_end
cmp r4,r5 // jump if no data to move
% ls -l redboot.bin
-rwxr-xr-x 1 root root 199360 Jun 1 13:49 redboot.bin
objdump of redboot.elf
arm-elf-objdump -h redboot.elf | more
redboot.elf: file format elf32-littlearm
Sections:
Idx Name Size VMA LMA File off Algn
0 .debug_aranges 000005a0 00000000 00000000 0003a7d4 2**0
CONTENTS, READONLY, DEBUGGING
1 .debug_pubnames 000027b0 00000000 00000000 0003ad74 2**0
CONTENTS, READONLY, DEBUGGING
2 .debug_info 000303df 00000000 00000000 0003d524 2**0
CONTENTS, READONLY, DEBUGGING
3 .debug_abbrev 00004794 00000000 00000000 0006d903 2**0
CONTENTS, READONLY, DEBUGGING
4 .debug_line 000184ab 00000000 00000000 00072097 2**0
CONTENTS, READONLY, DEBUGGING
5 .rom_vectors 00000040 a0000000 00000000 00008000 2**0
CONTENTS, ALLOC, LOAD, CODE
6 .text 000274b4 00002000 00002000 0000a000 2**14
CONTENTS, ALLOC, LOAD, READONLY, CODE
7 .fini 00000000 000294b4 000294b4 0008a542 2**0
CONTENTS
8 .rodata 00006e38 000294b4 000294b4 000314b4 2**2
CONTENTS, ALLOC, LOAD, DATA
9 .rodata1 00000000 000302ec 000302ec 0008a542 2**0
CONTENTS
10 .fixup 00000000 000302ec 000302ec 0008a542 2**0
CONTENTS
11 .gcc_except_table 00000000 000302ec 000302ec 0008a542 2**0
CONTENTS
12 .fixed_vectors 00000160 a1f00020 a1f00020 0008a560 2**5
CONTENTS
13 .data 000007d4 a000a000 000302ec 0003a000 2**2
CONTENTS, ALLOC, LOAD, DATA
14 .bss 00006c38 a000a7d4 a000a7d4 0003a7d4 2**4
ALLOC
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] Elf to Bin format
2001-06-04 8:57 Narayana, Venkat A.
@ 2001-06-04 9:20 ` Mark Salter
2001-06-04 11:54 ` Grant Edwards
0 siblings, 1 reply; 11+ messages in thread
From: Mark Salter @ 2001-06-04 9:20 UTC (permalink / raw)
To: NarayVA; +Cc: ecos-discuss
>>>>> Narayana, Venkat A writes:
> objdump of redboot.elf
> arm-elf-objdump -h redboot.elf | more
> redboot.elf: file format elf32-littlearm
> Sections:
> Idx Name Size VMA LMA File off Algn
> 0 .debug_aranges 000005a0 00000000 00000000 0003a7d4 2**0
> CONTENTS, READONLY, DEBUGGING
> 1 .debug_pubnames 000027b0 00000000 00000000 0003ad74 2**0
> CONTENTS, READONLY, DEBUGGING
> 2 .debug_info 000303df 00000000 00000000 0003d524 2**0
> CONTENTS, READONLY, DEBUGGING
> 3 .debug_abbrev 00004794 00000000 00000000 0006d903 2**0
> CONTENTS, READONLY, DEBUGGING
> 4 .debug_line 000184ab 00000000 00000000 00072097 2**0
> CONTENTS, READONLY, DEBUGGING
> 5 .rom_vectors 00000040 a0000000 00000000 00008000 2**0
> CONTENTS, ALLOC, LOAD, CODE
> 6 .text 000274b4 00002000 00002000 0000a000 2**14
> CONTENTS, ALLOC, LOAD, READONLY, CODE
> 7 .fini 00000000 000294b4 000294b4 0008a542 2**0
> CONTENTS
> 8 .rodata 00006e38 000294b4 000294b4 000314b4 2**2
> CONTENTS, ALLOC, LOAD, DATA
> 9 .rodata1 00000000 000302ec 000302ec 0008a542 2**0
> CONTENTS
> 10 .fixup 00000000 000302ec 000302ec 0008a542 2**0
> CONTENTS
> 11 .gcc_except_table 00000000 000302ec 000302ec 0008a542 2**0
> CONTENTS
> 12 .fixed_vectors 00000160 a1f00020 a1f00020 0008a560 2**5
> CONTENTS
^^^^^^^^^^^^^^^^^^
This looks worng. You mentioned earlier that you moved .fixed_vectors.
This may be triggering a objcopy bug. Objcopy would try to put the
.fixed_vectors at offset 0xa1f00020 in the binary file which would
make the file ~2.7G long. Objcopy might be giving up at this point
so it doesn't get to .data.
It looks like you missed something when moving the .fixed_vectors
around.
> 13 .data 000007d4 a000a000 000302ec 0003a000 2**2
> CONTENTS, ALLOC, LOAD, DATA
> 14 .bss 00006c38 a000a7d4 a000a7d4 0003a7d4 2**4
> ALLOC
--Mark
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] Elf to Bin format
2001-06-04 9:20 ` Mark Salter
@ 2001-06-04 11:54 ` Grant Edwards
0 siblings, 0 replies; 11+ messages in thread
From: Grant Edwards @ 2001-06-04 11:54 UTC (permalink / raw)
To: Mark Salter; +Cc: NarayVA, ecos-discuss
On Mon, Jun 04, 2001 at 12:26:44PM -0400, Mark Salter wrote:
> >>>>> Narayana, Venkat A writes:
>
> > objdump of redboot.elf
>
> > arm-elf-objdump -h redboot.elf | more
>
> > redboot.elf: file format elf32-littlearm
>
> > Sections:
> > Idx Name Size VMA LMA File off Algn
> > 0 .debug_aranges 000005a0 00000000 00000000 0003a7d4 2**0
> > CONTENTS, READONLY, DEBUGGING
> > 1 .debug_pubnames 000027b0 00000000 00000000 0003ad74 2**0
> > CONTENTS, READONLY, DEBUGGING
> > 2 .debug_info 000303df 00000000 00000000 0003d524 2**0
> > CONTENTS, READONLY, DEBUGGING
> > 3 .debug_abbrev 00004794 00000000 00000000 0006d903 2**0
> > CONTENTS, READONLY, DEBUGGING
> > 4 .debug_line 000184ab 00000000 00000000 00072097 2**0
> > CONTENTS, READONLY, DEBUGGING
> > 5 .rom_vectors 00000040 a0000000 00000000 00008000 2**0
> > CONTENTS, ALLOC, LOAD, CODE
> > 6 .text 000274b4 00002000 00002000 0000a000 2**14
> > CONTENTS, ALLOC, LOAD, READONLY, CODE
> > 7 .fini 00000000 000294b4 000294b4 0008a542 2**0
> > CONTENTS
> > 8 .rodata 00006e38 000294b4 000294b4 000314b4 2**2
> > CONTENTS, ALLOC, LOAD, DATA
> > 9 .rodata1 00000000 000302ec 000302ec 0008a542 2**0
> > CONTENTS
> > 10 .fixup 00000000 000302ec 000302ec 0008a542 2**0
> > CONTENTS
> > 11 .gcc_except_table 00000000 000302ec 000302ec 0008a542 2**0
> > CONTENTS
> > 12 .fixed_vectors 00000160 a1f00020 a1f00020 0008a560 2**5
> > CONTENTS
> ^^^^^^^^^^^^^^^^^^
>
> This looks worng. You mentioned earlier that you moved .fixed_vectors.
> This may be triggering a objcopy bug. Objcopy would try to put the
> .fixed_vectors at offset 0xa1f00020 in the binary file which would
> make the file ~2.7G long. Objcopy might be giving up at this point
> so it doesn't get to .data.
Won't objcopy just skip that section if it doesn't have the
"LOAD" flag set?
--
Grant Edwards
grante@visi.com
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [ECOS] Elf to Bin format
@ 2001-06-04 8:21 Narayana, Venkat A.
2001-06-04 8:34 ` Mark Salter
0 siblings, 1 reply; 11+ messages in thread
From: Narayana, Venkat A. @ 2001-06-04 8:21 UTC (permalink / raw)
To: 'ecos-discuss@sources.redhat.com'
Hi,
Can you pls help me in figuring out
what happens when we convert ELF to a Bin format,
using objdump tool. I mean, how can i be sure
that all sections of elf file got dumped into
bin file? Is there any tool/utility which will allow
me to look into bin file and decipher the contents?
As was previously stated in this thread, my bin
file, when i flashed it into a flash, does not contain
.data section.
Thanks,
Venkat
"Narayana, Venkat A." wrote:
>
> Hi,
> When i convert my redboot.elf file to redboot.bin file,
> the .data section is not getting into bin file.How do i know this?
[snip]
That's not our experience, almost needless to say! Which target? Which
version of the tools? And have you customized or changed the linker script
in any way?
Jifl
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions http://www.redhat-techworld.com/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] Elf to Bin format
2001-06-04 8:21 Narayana, Venkat A.
@ 2001-06-04 8:34 ` Mark Salter
0 siblings, 0 replies; 11+ messages in thread
From: Mark Salter @ 2001-06-04 8:34 UTC (permalink / raw)
To: NarayVA; +Cc: ecos-discuss
>>>>> Narayana, Venkat A writes:
> Hi,
> Can you pls help me in figuring out
> what happens when we convert ELF to a Bin format,
> using objdump tool. I mean, how can i be sure
^^^^^^^
You did mean objcopy, right?
> that all sections of elf file got dumped into
> bin file? Is there any tool/utility which will allow
> me to look into bin file and decipher the contents?
There is nothing to decipher. The binary file contains only
the raw section contents at appropriate offsets. There is no
information to decipher.
> As was previously stated in this thread, my bin
> file, when i flashed it into a flash, does not contain
> .data section.
What makes you think this?
Please post the results of:
% objdump -h redboot.elf
and
% ls -l redboot.bin
--Mark
^ permalink raw reply [flat|nested] 11+ messages in thread
* RE: [ECOS] Elf to Bin format
@ 2001-06-04 7:34 Narayana, Venkat A.
2001-06-04 9:17 ` Jonathan Larmour
0 siblings, 1 reply; 11+ messages in thread
From: Narayana, Venkat A. @ 2001-06-04 7:34 UTC (permalink / raw)
To: 'Jonathan Larmour'; +Cc: 'ecos-discuss@sources.redhat.com'
-----Original Message-----
"Narayana, Venkat A." wrote:
>
> Hi,
> When i convert my redboot.elf file to redboot.bin file,
> the .data section is not getting into bin file.How do i know this?
[snip]
That's not our experience, almost needless to say! Which target? Which
version of the tools? And have you customized or changed the linker script
in any way?
The target is Xscale board. The gcc version is 3.0.
ld's version is 2.11.90
I changed the linker script just to put fixed_vectors at A1F00000
and nothing else.
venkat N
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] Elf to Bin format
2001-06-04 7:34 Narayana, Venkat A.
@ 2001-06-04 9:17 ` Jonathan Larmour
0 siblings, 0 replies; 11+ messages in thread
From: Jonathan Larmour @ 2001-06-04 9:17 UTC (permalink / raw)
To: Narayana, Venkat A.; +Cc: 'ecos-discuss@sources.redhat.com'
"Narayana, Venkat A." wrote:
>
> -----Original Message-----
> "Narayana, Venkat A." wrote:
> >
> > Hi,
> > When i convert my redboot.elf file to redboot.bin file,
> > the .data section is not getting into bin file.How do i know this?
> [snip]
>
> That's not our experience, almost needless to say! Which target? Which
> version of the tools? And have you customized or changed the linker script
> in any way?
>
> The target is Xscale board. The gcc version is 3.0.
> ld's version is 2.11.90
> I changed the linker script just to put fixed_vectors at A1F00000
> and nothing else.
Hmm... what's the output of arm-elf-objdump -h on the ELF executable?
Jifl
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions http://www.redhat-techworld.com/
^ permalink raw reply [flat|nested] 11+ messages in thread
* [ECOS] Elf to Bin format
@ 2001-06-01 9:18 Narayana, Venkat A.
2001-06-01 16:07 ` Jonathan Larmour
0 siblings, 1 reply; 11+ messages in thread
From: Narayana, Venkat A. @ 2001-06-01 9:18 UTC (permalink / raw)
To: 'ecos-discuss@sources.redhat.com'; +Cc: Narayana, Venkat A.
Hi,
When i convert my redboot.elf file to redboot.bin file,
the .data section is not getting into bin file.How do i know this?
Because,after i flashed the bin file, i used the tool(from windriver)
to see the contents of flash memory and i found that the code got into
it till the start of the data section or till the end of the rodata section.
After some digging i found that the bin file size corresponds to the
end of rodata section or to the start of data section.
The following are various section starts and ends:
_stext = 2000H
_etext = 294b4H
rom_data_start = 302ecH -> Till here the code is in Bin file and
corresponds to the size of bin file.
ram_data_start = a000a000H
ram_data_end = a000a7d4H
The following are my Program Headers:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
LOAD 0x008000 0xa0000000 0x00000000 0x00040 0x00040 RWE 0x8000
LOAD 0x00a000 0x00002000 0x00002000 0x2e2ec 0x2e2ec RWE 0x8000
LOAD 0x03a000 0xa000a000 0x000302ec 0x007d4 0x007d4 RW 0x8000
LOAD 0x040180 0xa1f00180 0xa1f00180 0x00000 0x06c2c RW 0x8000
Looking at Program Headers and then what is in bin file( using windrivers
visionclick tool), i figured that, whenever my Load address( in target.ld
script)
is diffrent from my relocation address, then, that section is ignored by
objcopy, while it is converting from elf format to bin format.
I tried tha 'add-section' option of objcopy, but that didn't work.
Where could be the problem? Is my understanding of the stuff correct or am i
becoming Sherlock-homeless;-)
I would really appreciate your help on this.Btw, i read somewhere that when
we convert ELF file to another format we loose some data, is that what's
happeing here? How to overcome this. Because without .data section, i cannot
get ahead.
Regards
Venkat N
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [ECOS] Elf to Bin format
2001-06-01 9:18 Narayana, Venkat A.
@ 2001-06-01 16:07 ` Jonathan Larmour
0 siblings, 0 replies; 11+ messages in thread
From: Jonathan Larmour @ 2001-06-01 16:07 UTC (permalink / raw)
To: Narayana, Venkat A.; +Cc: 'ecos-discuss@sources.redhat.com'
"Narayana, Venkat A." wrote:
>
> Hi,
> When i convert my redboot.elf file to redboot.bin file,
> the .data section is not getting into bin file.How do i know this?
[snip]
That's not our experience, almost needless to say! Which target? Which
version of the tools? And have you customized or changed the linker script
in any way?
Jifl
--
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions http://www.redhat-techworld.com/
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2001-06-04 12:00 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-06-04 11:49 [ECOS] Elf to Bin format Narayana, Venkat A.
2001-06-04 12:00 ` Gary Thomas
-- strict thread matches above, loose matches on Subject: below --
2001-06-04 8:57 Narayana, Venkat A.
2001-06-04 9:20 ` Mark Salter
2001-06-04 11:54 ` Grant Edwards
2001-06-04 8:21 Narayana, Venkat A.
2001-06-04 8:34 ` Mark Salter
2001-06-04 7:34 Narayana, Venkat A.
2001-06-04 9:17 ` Jonathan Larmour
2001-06-01 9:18 Narayana, Venkat A.
2001-06-01 16:07 ` Jonathan Larmour
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).