Enormous linux kernel after objcopy

[David Goodlad <david at goodlad dot ca>]

Hi all

(I don't subscribe to this list, so please CC any replies to me)

I am cross-compiling a linux kernel for an ARM9 processor, and have
encountered some weird behavior, and have reached the limits of my
knowledge (and apparently google's, too).

Using any version of binutils compiled locally (2.16, 2.17, 2.18*) using
crosstool-ng, and gcc 4.2.2, I end up with a kernel image that is far
too large. The file arch/arm/boot/Image ends up being 3.1-3.2 GB!
However, this is a bit of a trick, since there is only about 200 bytes
of 'data' at the beginning of that file, then 0s until 0xc0008000 (the
kernel's base address on my architecture - RAM starts at 0xc0000000).
This seems to be a result of the objcopy from vmlinux, which is only a
couple of megs in size.

If I use the cross toolchain installed via pacman in Arch
(cross-arm-elf-[gcc-base|binutils]), the Image file ends up being about
2 megs, zImage only about 1.1 megs.

So, as I mentioned, I've reached the limits of my knowledge - is there a
switch for objcopy to force it not to pad the Image file out all the way
to 0xc0008000? The kernel built with my distro's cross toolchain
mentioned above boots just fine, so I know that it's possible, but I've
been unable to figure out what causes the difference.

Thanks for any hints!
Dave

PS - hopefully this is a reasonable place to post this question, if not,
could someone point me to a more appropriate list?

-- 
David Goodlad

email:        david@goodlad.ca
blog:  http://david.goodlad.ca