Please help me...

[Charles Lepple]

Brendan J Simon wrote:
> >  Sections:
> > Idx Name          Size      VMA       LMA       File off  Algn
> > 0 .text         00004870  ff801000  ff801000  00001000  2**2
> >                    CONTENTS, ALLOC, LOAD, READONLY, CODE
> >    1 .rodata       00000470  ff805870  ff805870  00005870  2**4
> >                    CONTENTS, ALLOC, LOAD, READONLY, DATA
> >    2 .data         00000300  ff806000  ff806000  00006000  2**2
> >                    CONTENTS, ALLOC, LOAD, DATA
> >    3 .bss          0000bbac  ff807000  ff807000  00007000  2**2
> >                    ALLOC
> >    4 image         00061104  ff807000  ff807000  00007000  2**0
> >                    CONTENTS, ALLOC, LOAD, DATA

       ^^^^^^^ This section (image) could be your problem if you use a
vxWorks bootloader.

Although the vxWorks loader is written with ELF images in mind,
experience (with a DY4 SVME-177 board) tells me that it ignores ELF
sections that would not be present in a vxWorks executable. I did not
have time to investigate this completely, but the indication that tipped
me off was that the sizes of the sections added up to be much larger
than the sum of the numbers that the boot loader reports. All other test
programs (those without added sections) were loaded correctly.

If the sum of the numbers printed on the screen is significantly less
than the size of the file, then you can assume that anything you need to
load should be in either '.text' or '.data'. If you have the whole
vxWorks toolchain, you can try to find out what other section names are
used in executables loaded by the bootloader (maybe a debugging
section?), or you can work on building a special zImage file.

You can get around this limitation by having the zipped kernel image
inserted directly into the data segment of a wrapper program (see
arch/ppc/chrpboot/, especially piggyback.c).

-- 
Charles Lepple
clepple at mitre.org


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/