[ECOS] Elf to Bin format

[ECOS] Elf to Bin format

[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

Re: [ECOS] Elf to Bin format

[Jonathan Larmour]

"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/

RE: [ECOS] Elf to Bin format

[Gary Thomas]

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?

Re: [ECOS] Elf to Bin format

[Grant Edwards]

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

RE: [ECOS] Elf to Bin format

[Narayana, Venkat A.]

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

Re: [ECOS] Elf to Bin format

[Mark Salter]

>>>>> 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

Re: [ECOS] Elf to Bin format

[Jonathan Larmour]

"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/

RE: [ECOS] Elf to Bin format

[Narayana, Venkat A.]

[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

Re: [ECOS] Elf to Bin format

[Mark Salter]

>>>>> 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

RE: [ECOS] Elf to Bin format

[Narayana, Venkat A.]

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/

RE: [ECOS] Elf to Bin format

[Narayana, Venkat A.]

-----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