Re: [uClinux-dev] ARNEWSH MCF5206 - what addr. to load linux image?

From: Andrew Kohlsmith (akohlsmith@benshaw.com)
Date: Sat Mar 17 2001 - 11:43:11 EST


> Be sure to get the new tools we put up on:

> It should help.  Most of the coldfire 2.4 work has been done with the
> uClibc sources from CVS, so that may be useful to get as well.

I'm using the new elf-tools and the CVS versions of uClinux-2.4.x and
uClibc.  That was actually the easiest part of the entire process.  :-)

> You need to look at your linker script.  This determines the location the

Got it.  Is there any reason why the 2.4.x kernels use a size of 7e0000?
The 2.0.38 version uses a size of ff00 IIRC but I think all my problems are
stemming from elf2flt, as I'll try to demonstrate.

I notice that if I take a simple "Hello, World" program and compile it with
$ m68k-elf-gcc -o hello hello.c -lc
and then run
$ elf2flt -o hello.flt hello

I get a 64 *byte* "program" which appears to be just the 64 byte flat file
header.  Now if I compile the test program with -Wl,-elf2flt:

$ m68k-elf-gcc -Wl,-elf2flt -o hello hello.c -lc

my hello program is (obviously) a flat file 4020 bytes long and seems to
actually have a program there.  If I take the intermediary hello.elf file
and run elf2flt on it manually I get the exact same 4020 byte output
program.

In the same vein, if I do a "make" of the linux kernel I get an approximate
1M m68k kernel.  Running elf2flt gives me a roughly 950k kernel but the
warning "No relocations in code!" is generated.  If I run elf2flt with the
verbose option I see the following:

$ elf2flt -v -o linux.flt linux
TEXT -> vma=20000 len=9eb6c
        lma=20000 clen=9eb6c oo=0 ap=2 fp=2000
DATA -> vma=beb6c len=29494
        lma=beb6c clen=29494 oo=0 ap=2 fp=a0b6c
WARNING: data=beb6c does not directly follow text=9eb6c
BSS  -> vma=ed334 len=3434a
        lma=ed334 clen=3434a oo=0 ap=4 fp=cf334
WARNING: bss=ed334 does not directly follow text=beb6c + data=29494(e8000)
SECTION: .text [80c944c]: flags=233 vma=20000
 RELOCS: .text [80c944c]: flags=233 vma=20000
SECTION: .data [80c958c]: flags=243 vma=beb6c
 RELOCS: .data [80c958c]: flags=243 vma=beb6c
SECTION: .init [80c96cc]: flags=223 vma=e8000
SECTION: .bss [80c980c]: flags=1 vma=ed334
SECTION: .comment [80c994c]: flags=210 vma=0
SECTION: .stab [80c9a8c]: flags=10210 vma=2568
SECTION: .stabstr [80c9bcc]: flags=10210 vma=36cc
No relocations in code!
SIZE: .text=0xbeb6c, .data=0xed334, .bss=0x3434a

So I guess all my questions really center around elf2flt:
- How come ext2flt is not relocating anything with the kernel?
- Why does -Wl,-elf2flt give a differnet (intermediary) elf format file
which I can run to get the proper flat file?
- Why do I get a "header-only" file when I run elf2flt on a "normal"
m68k-elf-gcc run?
- Is it normal that I have to remove the 64 byte header of the resulting
flat file to get it to run properly?

Just for kicks I kludged in the -elf2flt option in the LINKFLAGS of the
5206/Rules.make.  I really didn't expect anything to come of it since that
was a kludge at best.  I ended up getting an error "ERROR: bad_reloc size=2
for symbol=ret_from_interrupt" followed by the "No reloations in code!"  If
I verbosely run elf2flt on the linux.elf file I get a whole ton of
relocations, the "No reloations in code!" error (?!) and a
larger-than-the-elf-version flat kernel file.  Same kinds of problems with
running it, but I didn't expect this one to work.  :-)

It feels like I'm missing one or two critical steps and that's preventing
the whole thing from working.  It's a good feeling (I'm guess I'm not a
total idiot <g>) and frustrating at the same time.  As a learning tool I'm
doing some cursory documentation (primarily for myself but later for
everyone I hope) which I hope to polish up in time.

Regards,
Andrew


This message resent by the uclinux-dev@uclinux.org list server http://www.uClinux.org/


This archive was generated by hypermail 2.1.4 : Thu Sep 19 2002 - 13:19:35 EDT