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

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

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

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@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.
participants (2)
-
Jerry Van Baren
-
Matthew L. Creech