[U-Boot] [mpc8313] objcopy generates huge binary

[U-Boot] [mpc8313] objcopy generates huge binary

[Matthew L. Creech]

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

[U-Boot] [mpc8313] objcopy generates huge binary

[Jerry Van Baren]

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

[U-Boot] [mpc8313] objcopy generates huge binary

[Matthew L. Creech]

On Sat, Dec 20, 2008 at 12:25 AM, Jerry Van Baren <gvb.uboot@gmail.com> wrote:
>
> 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.
>

Thanks for the reply Jerry.  FYI, I just saw your comments in a
previous thread here:

http://www.mail-archive.com/u-boot-users at lists.sourceforge.net/msg07496.html

I haven't found a reference for what changed to make GCC start using
".rodata.str1.1", and I don't know anything about linker scripts.
However, adding that section to the script fixes the build issues for
me, and doesn't seem to adversely affect the build when using an older
GCC (I tested with 4.3.2 and 4.2.1).  The attached one-liner works for
us on the 83xx; if there are no ill effects, perhaps all of the PPC
link scripts could do something like this to fix any similar issues.

-- 
Matthew L. Creech
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ppc-83xx-link-fix.patch
Type: application/octet-stream
Size: 355 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20081229/3cfa9a58/attachment.obj