Hi Heinrich, On Sun, Sep 10, 2017 at 11:18 PM, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > On 09/10/2017 06:36 AM, Heinrich Schuchardt wrote: >> export BUILD_ROM=y >> make mrproper >> make qemu-x86_64_defconfig >> make >> >> results in a file u-boot-spl-nodtb.bin of 4,293,642,704 bytes >> for git HEAD. >> >> The problematic statement is >> >> objcopy -O binary -R .start16 -R .resetvec \ >> spl/u-boot-spl spl/u-boot-spl-nodtb.bin >> >> spl/u-boot-spl has 2,385,168 bytes. >> >> My system is Debian Stretch x86_64. >> GNU objcopy (GNU Binutils for Debian) 2.28 >> >> objdump -h spl/u-boot-spl >> shows that the section .start16 and .resetvec exist. >> >> I have created an upstream bug report >> https://sourceware.org/bugzilla/show_bug.cgi?id=22120 >> >> Best regards >> >> Heinrich >> > > This seems not to be a bug in objcopy: > > --- Comment #2 from Andreas Schwab <sch...@linux-m68k.org> --- > This is not a bug. The sections to be copied cover an address range from > 00120000 to FFFDC9D0, and the binary format cannot represent holes. > > 3 .data 00000510 fffdc4c0 fffdc4c0 0000e4c0 2**5 > CONTENTS, ALLOC, LOAD, RELOC, DATA > 4 .got 00000004 00120000 00120000 00001000 2**2 > CONTENTS, ALLOC, LOAD, DATA
So does this mean: upgrading to objcopy v2.28 will break qemu-x86_64? Could you talk to them why does the objcopy behavior change between versions? Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
