From mboxrd@z Thu Jan  1 00:00:00 1970
From: Jerry Van Baren <gvb.uboot@gmail.com>
Date: Sat, 20 Dec 2008 00:25:43 -0500
Subject: [U-Boot] [mpc8313] objcopy generates huge binary
In-Reply-To: <5ee96a840812171302h345584b0t1028d85519eb7cc5@mail.gmail.com>
References: <5ee96a840812171302h345584b0t1028d85519eb7cc5@mail.gmail.com>
Message-ID: <494C81D7.9090303@gmail.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Matthew L. Creech wrote:
> Using the latest toolchain from CodeSourcery (4.3-50), I can't seem to
> build U-Boot for the MPC8313 ERDB platform.  I've tried this with both
> 2008.10 and 2009.01-rc1.  Grabbing a fresh copy of U-Boot and doing
> "make MPC8313ERDB_33_config && make" seems to work at first, but near
> the end when it does:
> 
> powerpc-linux-gnu-objcopy --gap-fill=0xff -O binary u-boot u-boot.bin
> 
> things freeze as objcopy attempts to create a 4GB "u-boot.bin".  The
> output file looks legit until here:
> 
> 00008950  20 57 61 72 6e 69 6e 67  3a 20 52 54 43 20 6f 73  | Warning: RTC os|
> 00008960  63 69 6c 6c 61 74 6f 72  20 68 61 73 20 73 74 6f  |cillator has sto|
> 00008970  70 70 65 64 0a 00 ff ff  ff ff ff ff ff ff ff ff  |pped............|
> 00008980  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
> 00008990  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
> 000089a0  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
> 
> The file size is 4261653072 bytes - this is 0xFE03AA50, which is
> suspiciously close to the base NOR address of 0xFE000000, so I'm
> assuming that it's attempting to gap-fill the entire address space for
> some reason.  I'm not sure whether the issue lies with U-Boot or with
> binutils, though, or how to fix it - any ideas on what's wrong here?
> 
> Thanks
> 
> --
> Matthew L. Creech

Hi Matthew,

It is most likely a u-boot configuration problem where there is 
something (e.g. code) at a low address and a high address and objcopy is 
gap filling.

Use "objdump -h" to dump the sections and look at what sections and 
addresses are.  You will likely find loadable sections at both ends of 
your memory map.

HTH,
gvb